http://blog.gmane.org/gmane.linux.arch.tur.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.arch.tur.user/29975 <pre>---------------------------------------- I don't think anyone's suggesting just removing them en mass, but removing them if upstream is gone, they don't build, and haven't been updated in a long time. In that situation, what would the reason be to keep them? </pre> Doug Newgard 2013-06-19T21:49:59 http://permalink.gmane.org/gmane.linux.arch.tur.user/29974 <pre> How can I get the sources? If you provide a mirror, I think it's OK. When talking about ded upstream, I'm not talking about upstream website being 404, I'm talking about the sources for the package being gone. BTW, please don't top-post. </pre> Karol Blazewicz 2013-06-19T21:48:52 http://permalink.gmane.org/gmane.linux.arch.tur.user/29973 <pre> According to the sources, it pulls blender 2.49b (and not 2.6), which is available from A.R.M. anyway. </pre> Karol Blazewicz 2013-06-19T21:45:24 http://permalink.gmane.org/gmane.linux.arch.tur.user/29972 <pre>I am against removing "dead upstream" packages, unless upstream is completely gone, i.e. there is no way to obtain necessary files. I am maintaining at least two packages with upstream long dead, but (after my patches, of course) they're still working and are used by some people. On 19 June 2013 22:49, Connor Behan &lt;connor.behan-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Karol Woźniak 2013-06-19T21:44:44 http://permalink.gmane.org/gmane.linux.arch.tur.user/29971 <pre> I would only submit such packages for deletion if their PKGBUILDs do a simple ./configure &amp;&amp; make &amp;&amp; make install. If there are non-trivial patches, even if they are long broken, I would leave it in the AUR. When someone comes along and says "I want to make this dead package work again" patches that once work can be a useful starting point. </pre> Connor Behan 2013-06-19T20:49:29 http://permalink.gmane.org/gmane.linux.arch.tur.user/29970 <pre> See the comments for https://aur.archlinux.org/packages/haskell-binary/ - is it enough to remove it? If ghc provides it and it clashes with the virtual package ..? https://aur.archlinux.org/packages/haskell-implicit/ Comment by the submitter: "This package was an accident and should be deleted from the AUR. The replacement is implicitcad. " https://aur.archlinux.org/packages/implicitcad/ is maintained by him. </pre> Karol Blazewicz 2013-06-19T20:29:14 http://permalink.gmane.org/gmane.linux.arch.tur.user/29969 <pre> AUR lacks 'mark package as broken' feature, I guess I can leave a comment that says it's broken + post compile errors etc. Maybe somebody will post a fix ... With regard to dead upstream, do I have to Google around to see if they moved it somewhere or is it OK to lazily submit for deletion? I'm talking about orphaned packages w/o an updated PKGBUILD in the comments or at least a comment that says upstream moved to a different place. I know, I didn't expect it tow work, but I have no idea what kind of presentations are they talking about. </pre> Karol Blazewicz 2013-06-19T19:53:32 http://permalink.gmane.org/gmane.linux.arch.tur.user/29968 <pre>1. 4dtris-git has been renamed by the developer to ntris 2 months ago (see comment in https://aur.archlinux.org/packages/4dtris-git/ ). https://aur.archlinux.org/packages/4dtris-git/ returns 404 for the source while https://aur.archlinux.org/packages/ntris/ looks maintained. Please remove 4dtris-git https://aur.archlinux.org/packages/4dtris-git/ (no votes, single comment) 2. acpi-handle-hack-lenovo-git and hack-lenovo have become obsolete as the fix has been included upstream - see comments on https://aur.archlinux.org/packages/hack-lenovo/ Does it mean both these packages should be removed from the AUR? They need to be updated to work with the current kernel but there seems to be no need for them. https://aur.archlinux.org/packages/acpi-handle-hack-lenovo-git/ https://aur.archlinux.org/packages/hack-lenovo/ </pre> Karol Blazewicz 2013-06-19T19:52:29 http://permalink.gmane.org/gmane.linux.arch.tur.user/29967 <pre>On 2013-06-19 19:28 +0200 Karol Blazewicz wrote: The ones that lack sources should be removed. I have deleted haskell-warp. Feel free to report others. Thanks </pre> Xyne 2013-06-19T19:09:22 http://permalink.gmane.org/gmane.linux.arch.tur.user/29966 <pre>On 2013-06-19 17:00 +0200 Edoardo Maria Elidoro wrote: deleted, thanks p.s. ♥ aurtomatic ♥ </pre> Xyne 2013-06-19T19:06:29 http://permalink.gmane.org/gmane.linux.arch.tur.user/29965 <pre>On 2013-06-19 16:55 +0200 Edoardo Maria Elidoro wrote: I think they should both be deleted. Do we need an old version in the AUR? Given that there are no votes, I would say no. Does anyone disagree? Regards, Xyne </pre> Xyne 2013-06-19T19:02:13 http://permalink.gmane.org/gmane.linux.arch.tur.user/29964 <pre>On 2013-06-18 20:02 +0200 Andre Bartke wrote: There were no votes nor relevant comments, so I have just deleted it. Thanks. </pre> Xyne 2013-06-19T18:59:09 http://permalink.gmane.org/gmane.linux.arch.tur.user/29963 <pre>On 2013-06-18 13:48 +0200 Karol Blazewicz wrote: Packages should only be removed if they conflict with policy (copies of official repo packages, malware, illegal packages) or if upstream is dead. Even if the PKGBUILD is an ancient relic from the age of Judd in need of a complete rewrite, we tend to leave them as placeholders. .odp is a Libre-/OpenOffice file extension btw. Regards, Xyne </pre> Xyne 2013-06-19T18:57:37 http://permalink.gmane.org/gmane.linux.arch.tur.user/29962 <pre> Since there was no reply from either party, we can ditch rtmpdump-svn ;) Please remove it from AUR </pre> Rob Til Freedmen 2013-06-19T18:11:39 http://permalink.gmane.org/gmane.linux.arch.tur.user/29961 <pre>There's over 200 packages submitted by arch-haskell that are marked out of date and are not maintained anymore. Some of them have been updated in the past year, so maybe there's no need to remove them, I'm just reporting something I noticed. Some packages were hosting their source on github e.g. https://aur.archlinux.org/packages/haskell-warp/ and they now returns 404. </pre> Karol Blazewicz 2013-06-19T17:28:40 http://permalink.gmane.org/gmane.linux.arch.tur.user/29960 <pre>Hi everyone, I noticed that almost every Cinnamon theme in AUR have the same comment made by the former maintainer (now they're orphan): "Themes can be downloaded directly from cinnamon-settings. It is no longer necessary to maintain this package". Should we remove all those packages? https://aur.archlinux.org/packages/cinnamon-theme-facebook/ https://aur.archlinux.org/packages/cinnamon-theme-grayscale/ https://aur.archlinux.org/packages/cinnamon-theme-sunset/ https://aur.archlinux.org/packages/cinnamon-theme-tout/ https://aur.archlinux.org/packages/cinnamon-theme-ics/ https://aur.archlinux.org/packages/cinnamon-theme-nightfall/ https://aur.archlinux.org/packages/cinnamon-theme-helios/ https://aur.archlinux.org/packages/cinnamon-theme-bluebird/ https://aur.archlinux.org/packages/cinnamon-theme-delorean-dark/ https://aur.archlinux.org/packages/cinnamon-theme-holo/ Thanks, have a nice day! Edoardo </pre> Edoardo Maria Elidoro 2013-06-19T15:00:36 http://permalink.gmane.org/gmane.linux.arch.tur.user/29959 <pre>Hi everyone, I think this package ( https://aur.archlinux.org/packages/blender2.6-bin/ ) should be removed from AUR because it won't install Blender 2.6. Also, there's a package that works and provides Blender 2.6: https://aur.archlinux.org/packages/blender2.62-bin/ Have a nice day, Edoardo </pre> Edoardo Maria Elidoro 2013-06-19T14:55:06 http://permalink.gmane.org/gmane.linux.arch.tur.user/29958 <pre>=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 6 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 8 packages missing signoffs * 2 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (6 total) == * libraw-0.15.2-1 (i686) * luminancehdr-2.3.1-3 (i686) * shotwell-0.14.1-4 (i686) * libraw-0.15.2-1 (x86_64) * luminancehdr-2.3.1-3 (x86_64) * shotwell-0.14.1-4 (x86_64) == Incomplete signoffs for [community] (8 total) == * libraw-0.15.2-1 (i686) 0/1 signoffs * luminancehdr-2.3.1-3 (i686) 0/1 signoffs * shapelib-1.3.0-2 (i686) 0/1 signoffs * shotwell-0.14.1-4 (i686) 0/1 signoffs * libraw-0.15.2-1 (x86_64) 0/2 signoffs * luminancehdr-2.3.1-3 (x86_64) 0/2 signoffs * shapelib-1.3.0-2 (x86_64) 0/2 signoffs * shotwell-0.14.1-4 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (2 total) == * shapelib-1.3.0-2 (i686), since 2013-05-28 * shapelib-1.3.0-2 (x86_64), since 2013-05-28 == Top five in signoffs in last 24 hours == </pre> Arch Website Notification 2013-06-19T08:07:04 http://permalink.gmane.org/gmane.linux.arch.tur.user/29957 <pre>that's what I first thinking thank for anwsering 2013/6/18 Dave Reisner &lt;d&lt; at &gt;falconindy.com&gt; </pre> Mo0O mo0ofier 2013-06-18T18:45:47 http://permalink.gmane.org/gmane.linux.arch.tur.user/29956 <pre>You may merge aksusb [1] into aksusbd [2] The latter one is correctly named, is up-to-date and provides a systemd service file instead of initscripts. [1] https://aur.archlinux.org/packages/aksusb/ [2] https://aur.archlinux.org/packages/aksusbd/ </pre> Andre Bartke 2013-06-18T18:02:11 http://permalink.gmane.org/gmane.linux.arch.tur.user/29955 <pre> Removed, thanks. Regards, Felix Yan</pre> Felix Yan 2013-06-18T16:10:40 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.arch.tur.user