- Arch-general - lists.archlinux.org

Re: [arch-general] GNUstep path
by Cédric Girard 06 Apr '11

06 Apr '11

Le 6 avr. 2011 18:40, "Lukáš Jirkovský" <l.jirkovsky(a)gmail.com> a écrit : > > On 6 April 2011 17:27, Sergej Pupykin <ml(a)sergej.pp.ru> wrote: > > At Wed, 6 Apr 2011 15:34:50 +0200, > > Cédric Girard <girard.cedric(a)gmail.com> wrote: > >> > >> Hello, > >> > >> Is there any particular reason why GNUstep (gnustep-base in [community]) get > >> installed in /opt/GNUstep? Especially libraries in > >> "/opt/GNUstep/Local/Library/Libraries/" cannot be found by binaries > >> depending on them unless "/opt/GNUstep/System/Library/Makefiles/GNUstep.sh" > >> is sourced. > >> > >> Or maybe I just have a bad understanding of how this works ... > > > > Hi, > > > > gnustep-make contains /etc/profile.d/GNUstep.sh, which should be > > sourced automatically. > > > > Cédric, I guess that's because you didn't log out and log in again, > because the files Sergej mentioned are sourced on login. > > Lukas Yes, you're right. I'll test that and give feedback. Thanks -- Cedric Girard

1 1

[arch-general] ftp://ftp.archlinux.org/extra/os/x86_64/packages
by Sergej Pupykin 06 Apr '11

06 Apr '11

Hi, what is this symlink: ftp://ftp.archlinux.org/extra/os/x86_64/packages/ ?

2 1

[arch-general] GNUstep path
by Cédric Girard 06 Apr '11

06 Apr '11

Hello, Is there any particular reason why GNUstep (gnustep-base in [community]) get installed in /opt/GNUstep? Especially libraries in "/opt/GNUstep/Local/Library/Libraries/" cannot be found by binaries depending on them unless "/opt/GNUstep/System/Library/Makefiles/GNUstep.sh" is sourced. Or maybe I just have a bad understanding of how this works ... -- Cédric Girard

3 2

[arch-general] Default Bootloader for AIF
by Matthew Gyurgyik 05 Apr '11

05 Apr '11

Arch Devs, In November Pierre wrote a mail to arch-dev-public about bootloaders in core. http://mailman.archlinux.org/pipermail/arch-dev-public/2010-November/018445… Pierre wrote: > Summing up my suggestion for some time in the future would be: > * move extlinux/syslinux to core/base > * move grub1 to extra/multilib and remove it from base group > * keep grub2 in extra > * maybe also move lilo to extra > * of course keep all of them on the install cd Now that there is Syslinux support in AIF, should AIF select Syslinux as the "Default" bootloader? Users are asked to select which bootloader package they would like to install. They can either pick from Grub or Syslinux. Since Grub is listed first it is selected as the "Default". ~pyther

8 18

Re: [arch-general] [arch-dev-public] [arch-dev] Packaging inconsistencies of python modules
by Evangelos Foutras 05 Apr '11

05 Apr '11

On 5 April 2011 16:37, Dan McGee <dpmcgee(a)gmail.com> wrote: > I'm facing this exact situation with python-pip and python-virtualenv > right now- both just became python 3 compatible, and as soon as I > rename them I am going to break a lot of people's stuff. It would be > fine if this all happened when we did the "great rebuild" as there > would only be one time of breakage, but the situation right now is > untenable- *every single time I see a python module being updated* I > have to be scared as I can't tell whether the one being installed is 2 > or 3, and whether I'm suddenly going to lose database connectivity or > something. Ah, had the same issue with my pygments package. But because only 3 packages depended on it, I just tweaked the dependencies in those. Now I'm thinking, couldn't we do: python-foo gets renamed to python2-foo and provides/conflicts/replaces=('python-foo') are introduced. python3-foo is added to the repo. The key detail here is the 'python3-' prefix, which allows us to replace python-foo with python2-foo. Looks like numpy [1] is using this approach. Another problem I noticed when I split pygments into Python 2 & 3 packages is command scripts that get installed to /usr/bin/; both versions use the same path, and will conflict. I chose to append a 2 to the command script installation path (/usr/bin/pygmentize -> /usr/bin/pygmentize2) in the Python 2 package. [1] http://projects.archlinux.org/svntogit/packages.git/tree/python-numpy/trunk…

1 0

[arch-general] gtk3-engines doesn't work
by Heiher 05 Apr '11

05 Apr '11

Hello, Could you tell me why gtk3-engines doesn't work? Seems the gtk3 not load it by 'strace'. -- Best regards! Heiher

3 2

[arch-general] [signoff] kernel26-2.6.38.2-1
by Tobias Powalowski 05 Apr '11

05 Apr '11

Hi guys, please signoff 2.6.38 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot - added additional i915 patch - added radeaon kms fix greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 16

[arch-general] [systemd] v23 released, heads up
by Dave Reisner 05 Apr '11

05 Apr '11

Hey all, A heads up for anyone using systemd, I've just pushed the latest tag to [community-testing]. It's going to be hanging out there until we at least see udev-167. More notably, there's been a fairly silly change [1] in place that will muck up the formatting of log facilities in dmesg and syslog [2] without a kernel patch [3] to accompany it. Understand that this is mostly cosmetic, but for anyone micromanaging their syslogs, this may have an impact unless you backport the patch to your kernel. regards, dave [1] http://cgit.freedesktop.org/systemd/commit/?id=7c3b203c5c69fc37c8d143851cd3… [2] http://sprunge.us/Hcjg [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=…

2 1

[arch-general] Packages for stable core EFL libraries?
by mathieu p 04 Apr '11

04 Apr '11

Hi, The current packages for eina, evas, ecore, etc in community are -svn, and since the enlightenment team released the 1.0 ( http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=28) and later the 1.0.1 (http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=29) version of their toolkit, I think it would be fitting to have at least the concerned packages in their stable version. Afaik, elementary is broken in the -svn packages, and it should work with the stable version (and with the latest revision).

1 0

[arch-general] deprecate grub (legacy) - opinion?
by KESHAV P.R. 04 Apr '11

04 Apr '11

Hi all, I want your opinion regarding whether grub-legacy (core/grub) package should be deprecated (downgrade it to extra/community/AUR) now that syslinux is in core. THe actual upstream has been dead for 4 years and every fork (grub4dos, super grub disk, grub-fedora) is either lacking in functionality (read: GPT and such support) or being deprecated themselves in favour of grub2. Although grub does support gpt via a patch (not currently in the grub package), syslinux and grub2's gpt support is much better. The background of this message is the 'Default Bootloader in AIF' topic in arch-releng. My views regarding grub-legacy and syslinux are at http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001609.html and Dieter's reply at http://mailman.archlinux.org/pipermail/arch-releng/2011-March/001610.html. I mainly want the opinion of Ronald Van Haren (pressh - i hope i got the name right) (core/grub maintainer), and also other devs and TU's regarding whether this should be done. If it is not a problem for any dev or TU to maintain patches, should any of the grub-legacy fork(s) be deprecated, then its okay to leave the package as it is. But if it is a problem to maintain the package, in the light of gpt, btrfs, nilfs2 and all other FS and partition table problems (with grub-legacy) it should be deprecated IMO. Most of the advantages listed for grub-legacy are true for syslinux too, except multi-partition booting support (syslinux is limited to the partition from which it is booted). The decision taken by dev regarding this will (to some extent) determine the default bootloader supported in aif, and subsequently the bug-reports etc. If multi-partition support if needed, the user can use grub2-bios>=1.99~rc1 which is superior to grub2<=1.98 and also includes a menu.lst to grub.cfg conversion utility (in grub2-common package). Regards. Keshav PS: This can be considered analogous to grnome3 replacing gnome2 in the repos although some people don't like it, since it is the policy of Arch to package the latest release versions, in which case grub should have been out of the repos a long time ago.

4 3