- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] new vi/vim/gvim
by Tobias Kieslich 28 Apr '09

28 Apr '09

> > Has anything been decided with this? Apparently vim needs a patch to > build against the latest ruby which I was going to attempt updating soon. I'm just trying to give it a whirl on a testing box. The main issue is that the old package created a symlink that is not tracked by the version control at all. So before people can update to the new packages, they will have to remove one or two symlinks manually, which is ugly. -T

5 5

[arch-dev-public] [signoff] e2fsprogs 1.41.5-1
by Ronald van Haren 28 Apr '09

28 Apr '09

please signoff for both architectures. Changelog: - Upstream bugfix release http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.41.5 - fix install scriplet - Add MIT & BSD licenses Ronald

2 4

[arch-dev-public] Mplayer in two separate packages
by Hugo Doria 28 Apr '09

28 Apr '09

There is an old feature request for mplayer [1]: create it using two separate packages, one with only the CLI version and one for the GUI. There are some reasons for this: 1) By default the GUI is not enabled on mplayer 2) The package will not depend on gtk2 3) The user will be able to choose which GUI he wants to use. Now gmplayer is installed, even when the user wants to use another GUI, or do not use a GUI at all. Obviously there are some points that need to be discussed: 1) We do not usually split packages. Maybe this case is not a real division of packages because, by default, the GUI is not compiled. Don't know. 2) What do we do with the GUI version? Keep it on [extra] or move to community/AUR? I would like to hear your opinions. [1] http://bugs.archlinux.org/task/10220 [2] http://aur.archlinux.org/packages.php?ID=18516 -- Hugo

10 26

[arch-dev-public] python-2.6.2 and files in /usr/lib/python2.5
by Allan McRae 28 Apr '09

28 Apr '09

Hi all, I have just put python-2.6.2-1 into [testing]. This remove the python-2.5 compatibility sitepath so anything not rebuilt since python-2.6 was release will be broken. The list of broken packages as of yesterday is in FS#13831 (http://bugs.archlinux.org/task/13831?getfile=3375) Note that these don't need built against the python in [testing] to be fix, just rebuilt against an python-2.6 package. Allan

2 3

[arch-dev-public] Developers are now flyspray project managers
by Aaron Griffin 28 Apr '09

28 Apr '09

I just set all developers to be project managers on the bug tracker. That means you can all see the PM queue of bugs with closure requests or reopen requests. Let me know if this causes any issues. If email volume goes up, I could do something about that. Cheers, Aaron

2 1

Re: [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages
by Andreas Radke 27 Apr '09

27 Apr '09

To me it seems new gcc is more restrictive with missing headers. Go-OOo failed with a missing printf inclusion. Don't push the toolchain too fast to core. Give us and the upstream devs enough time to find fixes. example: http://cvs.fedoraproject.org/viewvc/rpms/openoffice.org/devel/openoffice.or… -Andy

2 1

Re: [arch-dev-public] [arch-commits] Commit in htdig/trunk (PKGBUILD)
by Pierre Schmitz 26 Apr '09

26 Apr '09

Am Samstag, 25. April 2009 16:29:03 schrieb Giovanni Scafora: > ln -s /srv/http/cgi-bin/htsearch ${pkgdir}/usr/bin || return 1 I thnik it should be the other way round. Imho no package should install anything into /srv. What do you guys think about this? -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

6 11

Re: [arch-dev-public] [arch-general] [arch-commits] Commit in htdig/trunk (PKGBUILD)
by Daenyth Blank 26 Apr '09

26 Apr '09

On Sat, Apr 25, 2009 at 15:01, Abhishek Dasgupta <abhidg(a)gmail.com> wrote: > 2009/4/25 Pierre Schmitz <pierre(a)archlinux.de>: >> Am Samstag, 25. April 2009 17:36:19 schrieb Dan McGee: >>> Installing into srv is no different than installing into /home/, >>> IMO. It might be worse as it presents a relatively big security risk >>> for those that do run public facing services, and suddenly a new >>> script has been made available for web site users to run. >> >> If we agree to this we should add such a rule to namcap. >> > > Removing 'srv/' in Namcap/directoryname.py will make namcap > issue a warning about a file in a non-standard directory. > > -- > Abhishek > +1 to this change.

1 0

[arch-dev-public] [signoff] openssl 0.9.8k-2
by Pierre Schmitz 25 Apr '09

25 Apr '09

Removing the rpath as suggested in http://bugs.archlinux.org/task/14367 The previous rpath was /usr/lib; so afaik no security problem. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

3 2

[arch-dev-public] Integrity Check x86_64 24-04-2009
by repomaint＠archlinux.org 24 Apr '09

24 Apr '09

======================================== = Integrity Check x86_64 of core,extra = ======================================== Performing integrity checks... ==> parsing pkgbuilds ==> checking mismatches ==> checking archs ==> checking dependencies ==> checking makedepends ==> checking for circular dependencies Missing Dependencies ---------------------- archboot --> 'netkit-telnet>=0.17-8' archboot --> 'wlan-ng26>=0.2.9-2' archboot --> 'atl2>=2.0.5-2' Missing Makedepends --------------------- v86d --> 'kernel26<2.6.29' gnome-speech --> 'espeak' Repo Hierarchy for Makedepends -------------------------------- core/crda depends on extra/python-m2crypto core/iputils depends on extra/opensp core/iputils depends on extra/libxslt core/iputils depends on extra/docbook-xsl core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/syslog-ng depends on extra/libcap core/sqlite3 depends on extra/tcl core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils Circular Dependencies ----------------------- gcc-gcj>eclipse-ecj>gcc-gcj Summary --------- Missing PKGBUILDs: 0 Invalid PKGBUILDs: 0 Mismatching PKGBUILD names: 0 Duplicate PKGBUILDs: 0 Invalid archs: 0 Missing (make)dependencies: 5 Repo hierarchy problems: 10 Circular dependencies: 1

1 0