- Arch-general - lists.archlinux.org

[arch-general] Fwd: Re: [hylafax-users] Error building 6.0.5 on Arch Linux /sys/stat.h:299:47: error: declaration of ‘int fchmod(int, __mode_t) throw ()’ throws different exceptions
by David C. Rankin 07 Apr '11

07 Apr '11

Just FYI Arch Devs - Hylafax needs a patch to build with gcc 4.5. You may want to wait for 6.0.6 for the next version update. Details from the ifax devs below: -------- Original Message -------- Subject: Re: [hylafax-users] Error building 6.0.5 on Arch Linux /sys/stat.h:299:47: error: declaration of ‘int fchmod(int, __mode_t) throw ()’ throws different exceptions Date: Fri, 1 Apr 2011 08:52:50 -0400 From: Aidan Van Dyk <aidan(a)ifax.com> To: David C. Rankin <drankinatty(a)suddenlinkmail.com> CC: hfax <hylafax-users(a)hylafax.org> You'll want to apply this: http://git.hylafax.org/HylaFAX?a=commitdiff;h=b0d873c950a72aa568d2fcfe7dbc8… I still believe this is a bug in GCC 4.5+, where they turned something every other compiler handles a fatal error, causing configure not to find the declaration for fchmod (and thus declare it's own in port.h). I doubt anyone will be able to convince GCC of this ;-) See: http://bugs.hylafax.org/show_bug.cgi?id=924 configure has been changed in HylaFAX to not tickle that particular property of GCC. That fix was applied to the 6.0 branch after 6.0.5 was released, but no distros were based on GCC 4.5+ yet at that time. I guess it's time for 6.0.6 release... a. On Thu, Mar 31, 2011 at 10:24 PM, David C. Rankin <drankinatty(a)suddenlinkmail.com> wrote: > Guys, > > I was working with hylafax in Arch updating the package from 6.0.4 to 6.0.5 > and I ran into a strange error related to "throws different exceptions": > > <snip> > 86-64 -mtune=generic -O2 -pipe -c Dispatcher.c++ > In file included from Sys.h:34:0, > from Dispatcher.c++:27: > /usr/include/sys/stat.h:299:47: error: declaration of ‘int fchmod(int, > __mode_t) throw ()’ throws different exceptions > ../port.h:32:12: error: from previous declaration ‘int fchmod(int, mode_t)’ > make[3]: *** [Dispatcher.o] Error 1 > make[3]: Leaving directory > `/home/david/arch/pkg/bld/hylafax/src/hylafax-6.0.5/libhylafax' > make[2]: *** [default] Error 2 > make[2]: Leaving directory > `/home/david/arch/pkg/bld/hylafax/src/hylafax-6.0.5/libhylafax' > make[1]: *** [dirs] Error 2 > make[1]: Leaving directory > `/home/david/arch/pkg/bld/hylafax/src/hylafax-6.0.5' > make: *** [default] Error 2 > ==> ERROR: A failure occurred in build(). > Aborting... > > I'm getting better at sorting this stuff out, but exception handling > problems are the exception... no pun intended. What says the experts. I > wanted a clean install to look at permissions again on the bin/notify.php > and bin/faxrcvd.php issue and thought I might as well try 6.0.5. > > What say the experts? What is the probable cause of throwing different > exceptions? The stat.h file on Arch is available on my server here: > > http://www.3111skyline.com/dl/bugs/hylafax/stat.h > > -- > David C. Rankin, J.D.,P.E. > > > ____________________ HylaFAX(tm) Users Mailing List _______________________ > To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi > On UNIX: mail -s unsubscribe hylafax-users-request(a)hylafax.org < /dev/null > *To learn about commercial HylaFAX(tm) support, mail sales(a)ifax.com.* > > -- David C. Rankin, J.D.,P.E.

2 3

[arch-general] What happened to Powerpill?
by Marek Otahal 07 Apr '11

07 Apr '11

Hi, anyone knows what happened to Xyne's powerpill [1] pacman wrapper? I started using it recently for it's aria2c multithreaded downloads but a couple of days it disappeared from community/aur and there's no trace. Thanks, marek [1] https://wiki.archlinux.org/index.php/Powerpill -- Marek Otahal :o)

11 15

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.37.6-1
by Meyithi 07 Apr '11

07 Apr '11

On 6 April 2011 20:25, Tobias Powalowski <t.powa(a)gmx.de> wrote: > Am Donnerstag 31 März 2011 schrieb Tobias Powalowski: > > Upstream update. This package is NOT in testing (2.6.38 currently > > resides there), but at: > > http://dev.archlinux.org/~tpowa/kernel26/ > > > > please signoff for both arches. > > > > greetings > > tpowa > bump anyone, seems .38 still cannot move due to issues. > > greetings > tpowa > User signoff i686, running since 31 Mar no problems as yet. -- Jason Steadman http://www.meyithi.com/ http://twitter.com/meyithi

1 0

[arch-general] Where should system-wide vim files go?
by Oon-Ee Ng 07 Apr '11

07 Apr '11

I installed vim-peaksea from the AUR the other day and couldn't use it, because it installed in /usr/share/vim/colors/peaksea.vim. This seems a fairly standard directory, but its not in runtimepath on a fresh install (AFAIK). Checked out some other vim colour-themes on the AUR, the majority seem to install to the same location. Some choose /usr/share/vim/vim** instead, but that breaks when vim updates. Perhaps /usr/share/vim/vimfiles makes more sense (only found one PKGBUILD using that so far). So what's the 'correct' behaviour? The vim split package doesn't seem to do any patches affecting runtimepath, so probably I assume runtimepath is an upstream default. In that case, should AUR packages correct their location? Posting to arch-general because it overlaps and isn't solely an AUR issue.

6 9

[arch-general] Gnome 3 and gcc 4.6 in Fedora 15
by Bernardo Barros 06 Apr '11

06 Apr '11

I just look at the list of new Features for Fedora 15.. It will have Gnome 3 and gcc 4.6 and a bunch of other things. This means that those projects are reaching a "stable" phase now? They are currently considered unstable and/or in testing on Arch Any predictions on the current and near future status of these projects in Arch? cheers, Bernardo

13 18

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