Re: [arch-general] Automatizing makepkg
On Sun, 22 Feb 2015 at 16:42:18, Neven Sajko wrote: > It seems srcpac, aura and yaourt all have functionality like this, > but they use ABS for the PKGBUILD, which sadly lags behind official > distro packages which means you'll often be building outdated packages > if you use them. > I couldn't find something which uses archlinux SVN instead. > You might want to try asp [1, 2]. [1] https://github.com/falconindy/asp [2] https://aur.archlinux.org/packages/asp-git/
Re: [arch-general] changelogs (was Re: postgresql 9.3 -> 9.4)
On Thu, 29 Jan 2015 at 17:06:43, Georg Altmann wrote:
> [...]
> On 29.01.2015 14:22, Bardur Arantsson wrote:
> > If the problem here is that it would be a chore to do this for
> > maintainers for every X.Y -> X.(Y+1) upgrade, then maybe Arch
> > package descriptions could grow a field or flag to handle such
> > things semi-automatically? Maybe something as simple as "if the
> > version number is about to change in *this way*, then warn loudly
> > using *this message*".
>
> Wouldn't that be a sensible way? The increased overhead for the
> maintainer would be to tick a flag in addition to the version bump.
> In the case of postgresql this would be a as simple as
>
> if (oldMajor < newMajor ||
> ((oldMajor == newMajor) && (oldMinor < newMinor)) {
> printUpgradeWarning();
> }
>
> Of course the condition would have to be serialized in the package
> meta-data some way. I have only very limited knowledge on the pacman
> internals. Maybe someone can come up with an estimate how big the
> effort would be to implement this.
> [...]
It isn't that easy. You cannot simply tick a flag, you need to maintain
a variable that keeps track of the last version that caused a warning.
Otherwise, there's no way to warn a user who upgrades straight from
1.0.0 to 2.1.0 when there were intermediate releases 1.1.0 and 2.0.0 and
some change between 1.1.0 and 2.0.0 that is worth a warning. And as a
matter of fact, that is what we already do in a lot of packages. You can
have a look at the install scriptlets of btrfs-progs, cups, dhcp,
dmraid, dovecot, ebtables, intel-ucode, linux, lirc, lvm2, mariadb,
nginx, openvpn, systemd, varnish, just to get an idea of what it looks
like. As I mentioned before, adding a similar check to PostgreSQL might
be a good idea but I, as a non-PostgreSQL user, cannot judge whether
that works and is worthwhile.
Re: [arch-general] changelogs (was Re: postgresql 9.3 -> 9.4)
On Thu, 29 Jan 2015 at 16:08:02, Carl Schaefer wrote: > The thread about the postgresql update reminded me of one of the few > things about Ubuntu that I miss: package updates usually included a > useful changelog entry describing what was fixed and/or new. Perhaps I > assume too much, but I imagine Arch package maintainers would generally > be aware of the changes in an update they're making, and so it wouldn't > be much additional work to include that information in a changelog > entry. > It actually *is* much additional work. Bumping the package version usually takes ~5 seconds. That does not include the time to build and test the package but we don't need to watch the build process and packages are often tested by using them in production. So, compared to those five seconds, looking up every single change and coming up with a change log is a lot of time -- and it usually doesn't pay off, apart from corner cases. Please examine the mailing lists, this story has been discussed several times already. Keeping bureaucracy to a minimum is one of the reasons we can provide updates much faster than other distributions. While I agree that warnings and front page news should be given where appropriate, I cannot comment on PostgreSQL, which I don't use. As it seems to be a similar process on every major update and there even seems to be a script to warn you, I don't see any need for another notice, though. As a database administrator, you should be aware of what happens when you update the DBMS. Maybe some post-upgrade message would be helpful... > When I first started using Arch I'd hoped "pacman -Qc" would do this, > but at this point only three of the 867 packages on my system have a > changelog, and most of those entries are just "version bump" or > equivalent. > Carl > >
Re: [arch-general] imagemagick 6.8.9.8-1 is slower than 6.8.9.7-1
On Fri, 17 Oct 2014 at 20:58:22, Lukas Fleischer wrote: > [...] > Anatol and I were able to reproduce this issue. It seems to be related > to __memcpy_avx_unaligned() in glibc which means that it only occurs on > architectures with the AVX extension. > > If you have a look at the memcpy-avx-unaligned.S source code [1], you > will notice that there are several branches that copy blocks of > different sizes. Now, for some reason, 6.8.9.8-1 always (or almost > always) picks the L(less_32bytes) branch which means that only small > blocks are copied, while 6.8.9.7-1 copies larger blocks. I do not have > the time to debug this in detail but maybe you can add this information > to the upstream report? > After a more thorough analysis by Jan, we found out that the issue is caused by a bug in the new OpenCL benchmark code. On modern CPUs, the benchmark is executed on every start of ImageMagick which leads to huge number of __memcpy_avx_unaligned() calls with a small block size. Jan prepared a patch and he will submit it upstream. > Regards, > Lukas > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S;hb=HEAD > >
Re: [arch-general] imagemagick 6.8.9.8-1 is slower than 6.8.9.7-1
On Fri, 17 Oct 2014 at 04:39:33, Matthew Wynn wrote: > After upgrading to imagemagick 6.8.9.8-1, I've found it to be a lot slower > than 6.8.9.7-1. I only get this issue when downloading from the repositories > or using the PKGBUILD, not when compiling using the instructions at > imagemagic.org. > > I've discussed the issue with the ImageMagick developers, which you can find > at > http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26369&sid=a29400f51bd723e98da6b74c0819e9b3. > Even when trying to convert a 500x500 image to 100x100, it appears that an > image that is 2048x1536 is created. > > I've tried this on multiple Arch machines with the same result. > Anatol and I were able to reproduce this issue. It seems to be related to __memcpy_avx_unaligned() in glibc which means that it only occurs on architectures with the AVX extension. If you have a look at the memcpy-avx-unaligned.S source code [1], you will notice that there are several branches that copy blocks of different sizes. Now, for some reason, 6.8.9.8-1 always (or almost always) picks the L(less_32bytes) branch which means that only small blocks are copied, while 6.8.9.7-1 copies larger blocks. I do not have the time to debug this in detail but maybe you can add this information to the upstream report? Regards, Lukas [1] https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S;hb=HEAD
Re: [arch-general] libgcrypt.so.20 missing
On Mon, 13 Jan 2014 at 21:30:53, guns wrote: > On Mon 13 Jan 2014 at 03:12:33PM -0500, Mark Lee wrote: > > > > I don't have encrypt in my mkinitcpio hooks. > > Regardless, the sync state of the mirrors we pulled from > are inconsistent. In my case, my top mirrors are all listed > under "Successfully Syncing Mirrors" with 100% completion at > https://www.archlinux.org/mirrors/status/ > > guns Mh, libgcrypt was moved separately [1] quite some time after the other packages [2] have been migrated from [testing]. So I it think it is a "packaging" issue, not a mirror issue. [1] https://projects.archlinux.org/svntogit/packages.git/commit/?id=2646d69 [2] https://projects.archlinux.org/svntogit/packages.git/commit/?id=11f6154
Re: [arch-general] Glibc 2.16.0-2 and /lib problem : the answer ;)
On Sat, Jul 07, 2012 at 08:32:36PM +0100, Jonathan Hudson wrote: > On Sat, 7 Jul 2012 21:15:50 +0200, Lukas Fleischer wrote: > > >On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote: > >> On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote: > >> > >> >On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote: > >> >> On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote: > >> >> >You used --force (-f) again. http://i.imgur.com/5Zd1w.png > >> >> > >> >> > >> >> I did NOT. > >> > > >> > > >> >Was /lib your current working dir when you ran pacman? > >> >Or did any other process have it open so it could not be removed? > >> > > >> > > >> > Geert > >> > > >> > >> Post event it's hard to tell. I previously removed obsolete > >> firmware, modules and udev directories, then ran the commands from a > >> previous thread (cut and paste, no --force). > >> > >> # pacman -Syu --ignore glibc > >> # pacman -S glibc > >> > >> The current directory was NOT /lib, and as the system is now pretty > >> much as loaded as prior, fuser /usr/lib (or /lib) shows no results. > > > >What's the output of `grep '^lib' /var/lib/pacman/local/*/files`? > > > /var/lib/pacman/local/glibc-2.16.0-2/files:lib > /var/lib/pacman/local/glibc-2.16.0-2/files:lib64 > /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/ > /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/ > /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/ > /var/lib/pacman/local/libguestfs-1.18.1-1/files:lib/systemd/system/guestfsd.service > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/ > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/ > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/ > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/systemd/system/multipathd.service > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/ > /var/lib/pacman/local/multipath-tools-git-20120526-1/files:lib/udev/kpartx_id > See. Both libguestfs and multipath-tools-git own files in "/lib". You should have dealt with that (i.e. rebuild these and put stuff in "/usr/lib" instead of "/lib") before upgrading.
Re: [arch-general] Glibc 2.16.0-2 and /lib problem : the answer ;)
On Sat, Jul 07, 2012 at 06:53:21PM +0100, Jonathan Hudson wrote: > On Sat, 7 Jul 2012 19:32:57 +0200, Geert Hendrickx wrote: > > >On Sat, Jul 07, 2012 at 17:21:24 +0100, Jonathan Hudson wrote: > >> On Sat, 7 Jul 2012 18:18:28 +0200, Jan Steffens wrote: > >> >You used --force (-f) again. http://i.imgur.com/5Zd1w.png > >> > >> > >> I did NOT. > > > > > >Was /lib your current working dir when you ran pacman? > >Or did any other process have it open so it could not be removed? > > > > > > Geert > > > > Post event it's hard to tell. I previously removed obsolete > firmware, modules and udev directories, then ran the commands from a > previous thread (cut and paste, no --force). > > # pacman -Syu --ignore glibc > # pacman -S glibc > > The current directory was NOT /lib, and as the system is now pretty > much as loaded as prior, fuser /usr/lib (or /lib) shows no results. What's the output of `grep '^lib' /var/lib/pacman/local/*/files`? > > -jh > >
Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages
On Tue, Mar 20, 2012 at 05:15:50PM -0400, Kaiting Chen wrote: > On Tue, Mar 20, 2012 at 4:15 PM, Lukas Fleischer > wrote: > > > On Mon, Mar 05, 2012 at 04:40:25PM +0100, Lukas Fleischer wrote: > > > On Mon, Mar 05, 2012 at 01:01:03AM +0100, Pierre Schmitz wrote: > > > > Am 24.02.2012 17:06, schrieb Lukas Fleischer: > > > > > Apart from that, +1 to this idea. I already checked the list of > > unneeded > > > > > orphans and there's >20 packages I'd like to maintain if they aren't > > > > > picked up in [extra]... > > > > > > > > Send me a list of these packages. But ensure they are still orphan and > > > > are not a dep or makedep of any package in core/extra. > > > > > > Well, there's only a few packages left (others have already been moved > > > or are required by another [core]/[extra] package): > > > > > > * bluez-firmware > > > * cmus > > > * evilwm > > > * fortune-mod > > > * id3v2 > > > * jhead > > > * libofx > > > * libofx-doc > > > * lirc > > > * lzo > > > * msmtp > > > * ncftp > > > * pdksh > > > * perl-timedate > > > * pidgin-encryption > > > > Status? Only bluez-firmware has been adopted yet. > > > > > > > > Note that fortune-mod is an optdep of xfce4-session and id3v2 is an > > > optdep of gtkpod (I can also maintain gtkpod if no one else wants to but > > > I don't use it, so this might not be in the sense of this cleanup). > > > > > > I'm not sure about lirc either, I'd prefer if someone could adopt both > > > lirc and lirc-utils and maintain them in [extra] (lirc-utils is required > > > by a bunch of [extra] packages). > > > > > > > > > > > Greetigns, > > > > > > > > Pierre > > > > > > > > -- > > > > Pierre Schmitz, http://pierre-schmitz.com > > > > Ooh I'll take vsftpd if that's available. I use it all the time. --Kaiting. vsftpd is in [community] and is maintained by Bartłomiej... > > -- > Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages
On Mon, Mar 05, 2012 at 04:40:25PM +0100, Lukas Fleischer wrote: > On Mon, Mar 05, 2012 at 01:01:03AM +0100, Pierre Schmitz wrote: > > Am 24.02.2012 17:06, schrieb Lukas Fleischer: > > > Apart from that, +1 to this idea. I already checked the list of unneeded > > > orphans and there's >20 packages I'd like to maintain if they aren't > > > picked up in [extra]... > > > > Send me a list of these packages. But ensure they are still orphan and > > are not a dep or makedep of any package in core/extra. > > Well, there's only a few packages left (others have already been moved > or are required by another [core]/[extra] package): > > * bluez-firmware > * cmus > * evilwm > * fortune-mod > * id3v2 > * jhead > * libofx > * libofx-doc > * lirc > * lzo > * msmtp > * ncftp > * pdksh > * perl-timedate > * pidgin-encryption Status? Only bluez-firmware has been adopted yet. > > Note that fortune-mod is an optdep of xfce4-session and id3v2 is an > optdep of gtkpod (I can also maintain gtkpod if no one else wants to but > I don't use it, so this might not be in the sense of this cleanup). > > I'm not sure about lirc either, I'd prefer if someone could adopt both > lirc and lirc-utils and maintain them in [extra] (lirc-utils is required > by a bunch of [extra] packages). > > > > > Greetigns, > > > > Pierre > > > > -- > > Pierre Schmitz, http://pierre-schmitz.com
Re: [arch-general] Erlang R15B
On Sat, Mar 17, 2012 at 08:23:22PM -0700, Kevin Arthur wrote: > Hello! > > I noticed that Erlang recently got moved from extra to community, and > was flagged as out-of-date. I think someone mentioned R15B, the latest > release, on this list about a month ago, but it doesn't look like it > went anywhere. > > I've attached a patch that will update the PKGBUILD to the latest > version. The ejabberd package will need to be rebuilt, but doesn't > require any other changes (I've tested it, and it's working fine). The > couchdb and yaws packages will probably have to be rebuilt too, although > they've both been marked out-of-date as well. > > Could one of the developers update the package? I will take care of that soon. I just didn't update it yet because I was very busy with exams and because there are a couple of bugs to fix, also. > > Thanks! > > Kevin Arthur
Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages
On Mon, Mar 05, 2012 at 05:49:57PM +0100, Tom Gundersen wrote: > On Mon, Mar 5, 2012 at 4:40 PM, Lukas Fleischer > wrote: > > * bluez-firmware > > I take this one. Thanks! > > > * lzo > > If nothing is depending on this, it might simply mean that all users > have moved to lzo2 and that lzo can be dropped. partimage (which is in [community]) still depends on it. Not sure if it can be easily patched to use lzo2. > > > I'm not sure about lirc either, I'd prefer if someone could adopt both > > lirc and lirc-utils and maintain them in [extra] (lirc-utils is required > > by a bunch of [extra] packages). > > In particular: > > kradio > mplayer > mythtv > rhythmbox > rosegarden > xawtv > xine-ui > > Maybe worth investigating if it can be made an opt-depend, like it is > for some packages: > > pulseaudio (optional) > totem (optional) > vlc (optional) It's not that easy, I tested this before: $ readelf -d $(which mplayer) | grep lirc 0x0001 (NEEDED) Shared library: [liblirc_client.so.0] $ pacman -Rdd --noconfirm lirc-utils >/dev/null $ mplayer mplayer: error while loading shared libraries: liblirc_client.so.0: cannot open shared object file: No such file or directory > > Cheers, > > Tom
Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages
On Mon, Mar 05, 2012 at 01:01:03AM +0100, Pierre Schmitz wrote: > Am 24.02.2012 17:06, schrieb Lukas Fleischer: > > Apart from that, +1 to this idea. I already checked the list of unneeded > > orphans and there's >20 packages I'd like to maintain if they aren't > > picked up in [extra]... > > Send me a list of these packages. But ensure they are still orphan and > are not a dep or makedep of any package in core/extra. Well, there's only a few packages left (others have already been moved or are required by another [core]/[extra] package): * bluez-firmware * cmus * evilwm * fortune-mod * id3v2 * jhead * libofx * libofx-doc * lirc * lzo * msmtp * ncftp * pdksh * perl-timedate * pidgin-encryption Note that fortune-mod is an optdep of xfce4-session and id3v2 is an optdep of gtkpod (I can also maintain gtkpod if no one else wants to but I don't use it, so this might not be in the sense of this cleanup). I'm not sure about lirc either, I'd prefer if someone could adopt both lirc and lirc-utils and maintain them in [extra] (lirc-utils is required by a bunch of [extra] packages). > > Greetigns, > > Pierre > > -- > Pierre Schmitz, http://pierre-schmitz.com
Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages
On Fri, Feb 24, 2012 at 04:19:25PM +0100, Pierre Schmitz wrote:
> Hi all,
>
> while the rebuild of unsigned packages is about to be finished we
> should start to think about our orphaned packages. ATM there about 430
> of them in core and extra 1); some of them are 8probably) not needed by
> any other package 2)
>
> Here is my proposal:
> * Everybody please review the list and adopt packages that you use and
> might be willing to maintain.
> * If you maintain a package that depends on an orphan, please adopt it.
> It does not make sense to depend on an maintained package. Note that
> packages can have mroe than one maintainer; so you should share the
> workload.
> * If a TU wants to maintain an orphan that is currently in [extra],
> please let us know.
I remember that some packages were hold back and weren't moved to
[community] on former [extra] cleanups, even though they didn't have a
maintainer (I'm not sure about the reasons anymore; I remember some of
them were used on gerolde or so, not sure if that is still relevant).
You should probably double-check these.
Apart from that, +1 to this idea. I already checked the list of unneeded
orphans and there's >20 packages I'd like to maintain if they aren't
picked up in [extra]...
> * Maybe we can also have a small team that adopts all orphans that
> nobody wants to adopt on their own but is needed.
Sounds like a good idea as well, at least for packages that are easy to
maintain ("easy" meaning that upstream releases don't require much more
work than bumping the pkgver and updating checksums). Packages that
require a packager, who actually uses them, can still be dropped/moved.
>
> The goal should be to adopt all needed/wanted orphans and remove
> everything else.
>
> Greetings,
>
> Pierre
>
>
> 1)
> https://www.archlinux.org/packages/?sort=&arch=any&arch=x86_64&repo=Core&repo=Extra&q=&maintainer=orphan&last_update=&flagged=&limit=50
> 2) https://www.archlinux.org/devel/reports/unneeded-orphans/
>
> --
> Pierre Schmitz, http://pierre-schmitz.com
Re: [arch-general] Best way to adjust cron.daily or updatedb execution time? (root's crontab?)
On Wed, Feb 22, 2012 at 05:54:49PM -0600, David C. Rankin wrote: > On 02/22/2012 03:49 PM, Lukas Fleischer wrote: > > > > `man 5 anacrontab`. > > > > [17:51 providence:/home/david/tde/bld/trinity-tqtinterface] # man 5 anacrontab > No manual entry for anacrontab in section 5 > > Bummer :) > > This box still has dcron on it. This happens if you don't provide all the necessary information when starting a thread. > > -- > David C. Rankin, J.D.,P.E.
Re: [arch-general] Best way to adjust cron.daily or updatedb execution time? (root's crontab?)
On Wed, Feb 22, 2012 at 03:26:40PM -0600, David C. Rankin wrote: > Guys, > > What is the best way to set the cron.daily items to run at 3 am. > Currently they run at 3 pm which is a pain. I have checked the > cron.daily entries and the other /etc/cron.x directories, but I > can't find a time setting anywhere. I have checked man crond and > crontab, but I didn't find a reference to setting the execution time > globally for cron.daily stuff. I have added an entry to root's > crontab: > > 0 3 * * * /root/cron/cron-daily > > Is this where this needs to go? `man 5 anacrontab`. > > -- > David C. Rankin, J.D.,P.E.
Re: [arch-general] Start a daemon, show a syntax error
On Fri, Feb 17, 2012 at 03:03:21PM +0100, SanskritFritz wrote: > On Fri, Feb 17, 2012 at 12:18 PM, Lukas Fleischer > wrote: > >> a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever). > >> b) You built bash manually and disabled process substitution support. > >> c) You're running bash in POSIX mode. > >> d) Something else happened. > > > > e) Someone hacked into your system and changed the shebang of all daemon > > scripts to "#!/bin/sh". > > Maybe > f) Your default shell is not bash? That doesn't matter unless he invokes the "rc.d" script in a pretty stupid way. The most likely reason is that the script in question has a "#!/bin/sh" shebang (even though the OP claimed that it happens with all daemon scripts)...
Re: [arch-general] Start a daemon, show a syntax error
On Fri, Feb 17, 2012 at 12:03:24PM +0100, Lukas Fleischer wrote:
> On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
> > 2012/2/17 Lukas Fleischer :
> > > On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
> > >> 在 2012年2月17日 下午2:57，Lukas Fleischer 写道：
> > >>
> > >> > On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
> > >> > > 2012/2/17 大熊 :
> > >> > > > No matter I manual start any a daemon, I always see a error shown
> > >> > > > on
> > >> > > > console:
> > >> > > >
> > >> > > > /etc/rc.d/functions: line 506: syntax error near unexpected token
> > >> > > > `('
> > >> > > > /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo
> > >> > > > TARGET,FSTYPE,OPTIONS /)
> > >> > > >
> > >> > > > But it seem that the daemon can run correctly, so should I need to
> > >> > > > fix
> > >> > it
> > >> > > > and how to fix it ?
> > >> > >
> > >> > > I don't know why this bug is always occur again and again.
> > >> > >
> > >> > > The fix is to edit /etc/rc.d/functions, change line 506 to the
> > >> > > following:
> > >> > >
> > >> > > done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
> > >> >
> > >> > Nope. Don't do that. Post the output of `bash --help | head -1`, `which
> > >> > bash` and `pacman -Qo /bin/bash`.
> > >> >
> > >>
> > >> ➜ ~ bash --help|head -1
> > >> GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu)
> > >> ➜ ~ which bash
> > >> /bin/bash
> > >> ➜ ~ pacman -Qo /bin/bash
> > >> /bin/bash is owned by bash 4.2.020-1
> > >> ➜ ~
> > >
> > > Weird... Did you enforce POSIX-compatibility somewhere? How do you start
> > > the daemons? Do you use something broken like `sh rc.d start $foo` or
> > > `sh /etc/rc.d/$foo start`?
> > >
> > > If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1
> > > /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as
> > > well.
> >
> > I have the same problem.It is all happened at codes like "done <
> > <(some stuff)",but after I changed it to "done < $(some stuff)", all
> > going well.I don't know bash has such a syntax usage?
>
> "done < $(foo)" isn't the same thing as "done < <(foo)". You break
> scripts by changing that (see "Command Substitution" vs. "Process
> Substitution" in the bash(1) man page). Sounds like process substitution
> support is broken for you which might have occurred because
>
> a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever).
> b) You built bash manually and disabled process substitution support.
> c) You're running bash in POSIX mode.
> d) Something else happened.
e) Someone hacked into your system and changed the shebang of all daemon
scripts to "#!/bin/sh".
Re: [arch-general] Start a daemon, show a syntax error
On Fri, Feb 17, 2012 at 05:58:31PM +0800, 郑文辉(Techlive Zheng) wrote:
> 2012/2/17 Lukas Fleischer :
> > On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
> >> 在 2012年2月17日 下午2:57，Lukas Fleischer 写道：
> >>
> >> > On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
> >> > > 2012/2/17 大熊 :
> >> > > > No matter I manual start any a daemon, I always see a error shown on
> >> > > > console:
> >> > > >
> >> > > > /etc/rc.d/functions: line 506: syntax error near unexpected token `('
> >> > > > /etc/rc.d/functions: line 506: ` done < <(findmnt -mrunRo
> >> > > > TARGET,FSTYPE,OPTIONS /)
> >> > > >
> >> > > > But it seem that the daemon can run correctly, so should I need to
> >> > > > fix
> >> > it
> >> > > > and how to fix it ?
> >> > >
> >> > > I don't know why this bug is always occur again and again.
> >> > >
> >> > > The fix is to edit /etc/rc.d/functions, change line 506 to the
> >> > > following:
> >> > >
> >> > > done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
> >> >
> >> > Nope. Don't do that. Post the output of `bash --help | head -1`, `which
> >> > bash` and `pacman -Qo /bin/bash`.
> >> >
> >>
> >> ➜ ~ bash --help|head -1
> >> GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu)
> >> ➜ ~ which bash
> >> /bin/bash
> >> ➜ ~ pacman -Qo /bin/bash
> >> /bin/bash is owned by bash 4.2.020-1
> >> ➜ ~
> >
> > Weird... Did you enforce POSIX-compatibility somewhere? How do you start
> > the daemons? Do you use something broken like `sh rc.d start $foo` or
> > `sh /etc/rc.d/$foo start`?
> >
> > If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1
> > /etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as
> > well.
>
> I have the same problem.It is all happened at codes like "done <
> <(some stuff)",but after I changed it to "done < $(some stuff)", all
> going well.I don't know bash has such a syntax usage?
"done < $(foo)" isn't the same thing as "done < <(foo)". You break
scripts by changing that (see "Command Substitution" vs. "Process
Substitution" in the bash(1) man page). Sounds like process substitution
support is broken for you which might have occurred because
a) You're not using bash (e.g. running rc.d(8) in sh(1)/$whatever).
b) You built bash manually and disabled process substitution support.
c) You're running bash in POSIX mode.
d) Something else happened.
Re: [arch-general] Start a daemon, show a syntax error
On Fri, Feb 17, 2012 at 05:32:33PM +0800, 大熊 wrote:
> 在 2012年2月17日 下午2:57，Lukas Fleischer 写道：
>
> > On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
> > > 2012/2/17 大熊 :
> > > > No matter I manual start any a daemon, I always see a error shown on
> > > > console:
> > > >
> > > > /etc/rc.d/functions: line 506: syntax error near unexpected token `('
> > > > /etc/rc.d/functions: line 506: `done < <(findmnt -mrunRo
> > > > TARGET,FSTYPE,OPTIONS /)
> > > >
> > > > But it seem that the daemon can run correctly, so should I need to fix
> > it
> > > > and how to fix it ?
> > >
> > > I don't know why this bug is always occur again and again.
> > >
> > > The fix is to edit /etc/rc.d/functions, change line 506 to the following:
> > >
> > > done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
> >
> > Nope. Don't do that. Post the output of `bash --help | head -1`, `which
> > bash` and `pacman -Qo /bin/bash`.
> >
>
> ➜ ~ bash --help|head -1
> GNU bash, version 4.2.20(2)-release-(i686-pc-linux-gnu)
> ➜ ~ which bash
> /bin/bash
> ➜ ~ pacman -Qo /bin/bash
> /bin/bash is owned by bash 4.2.020-1
> ➜ ~
Weird... Did you enforce POSIX-compatibility somewhere? How do you start
the daemons? Do you use something broken like `sh rc.d start $foo` or
`sh /etc/rc.d/$foo start`?
If you don't, the outputs of `pacman -Qo /etc/rc.d/functions`, `head -1
/etc/rc.d/functions` and `head -1 /usr/sbin/rc.d` might be helpful as
well.
Re: [arch-general] Start a daemon, show a syntax error
On Fri, Feb 17, 2012 at 12:35:03PM +0800, 郑文辉(Techlive Zheng) wrote:
> 2012/2/17 大熊 :
> > No matter I manual start any a daemon, I always see a error shown on
> > console:
> >
> > /etc/rc.d/functions: line 506: syntax error near unexpected token `('
> > /etc/rc.d/functions: line 506: `done < <(findmnt -mrunRo
> > TARGET,FSTYPE,OPTIONS /)
> >
> > But it seem that the daemon can run correctly, so should I need to fix it
> > and how to fix it ?
>
> I don't know why this bug is always occur again and again.
>
> The fix is to edit /etc/rc.d/functions, change line 506 to the following:
>
> done < $(findmnt -mrunRo TARGET,FSTYPE,OPTIONS /)
Nope. Don't do that. Post the output of `bash --help | head -1`, `which
bash` and `pacman -Qo /bin/bash`.
>
> /etc/bash_completion.d/git has the same issue before.
Re: [arch-general] [arch-dev-public] broken PKGDEST?
On Tue, Feb 14, 2012 at 04:05:52PM +0100, Tobias Powalowski wrote: > Am 14.02.2012 15:58, schrieb Tobias Powalowski: > >> i don't quite understand your workflow. can you describe them in simple > >> steps and point where is failing and how? > >> > > > ok I think we come a bit closer, > Problem is that both chroots use different PKGDEST, > the devtools before didn't use PKGDEST and just checked for the symlinks > which are working. > Can we change that back, do I need to change my config? Well, changing that back would mean that we would probably have to drop "$PKGDEST" support and rely on the symlinks (or fall back to the current working directory if the package file cannot be found in "$PKGDEST" or something). Does makechrootpkg create these symlinks at all? I don't think so. > > Thanks greetings > tpowa > > -- > Tobias Powalowski > Archlinux Developer & Package Maintainer (tpowa) > http://www.archlinux.org > tp...@archlinux.org > >
Re: [arch-general] [arch-dev-public] broken PKGDEST?
On Tue, Feb 14, 2012 at 03:58:31PM +0100, Tobias Powalowski wrote: > > > i don't quite understand your workflow. can you describe them in simple > > steps and point where is failing and how? > > > - Build kernel for x86_86, > - chroot into i686 build i686 kernel > - leave chroot > - testingpkg in trunk does only upload x86_64 and not both. Are you sure, you put both package files into the right location (trunk or "$PKGDEST", if used)? Does commitpkg display the "Skipping [...]: failed to locate package file" warning? There were two changes since the last devtools release that might have caused that [1], [2]. We probably need more details to figure out what's going wrong here, though. [1] http://projects.archlinux.org/devtools.git/commit/?id=b763788b [2] http://projects.archlinux.org/devtools.git/commit/?id=06a681ca
Re: [arch-general] [arch-dev-public] broken PKGDEST?
On Tue, Feb 14, 2012 at 02:10:50PM +0100, Tobias Powalowski wrote: > Hi, > since quite some time, PKGDEST breaks testingpkg etc. > It only can upload the arch package and not the other, eg. x64_64 is not > able to upload the i686 package. > Any ideas or fix for this? It really breaks my workflow. I'm not sure what you want to do... Are you trying to release to a architecture that isn't specified in the PKGBUILD's "arch" array? Or does commitpkg fail to upload an architecture you actually specified? Just to be sure, commitpkg currently behaves as follows: 1. Iterates over all architectures that you specified in your PKGBUILD (unless you use "$commit_arch"). 2. Searches for package files for each of these architectures (and it looks in "$PKGDEST" if that is used). If it cannot find a package file for one architecture, it displays something like "Skipping $_pkgname-$fullver-$_arch: failed to locate package file" and skips that architecture. 3. Searches for signature files, bails out if one of them cannot be found or is invalid. 4. archreleases to all remaining architectures. 5. Uploads package and signature files. If it doesn't behave like that for you, you should probably file a devtools bug. If it behaves like that and you need another feature, file a feature request :) > > greetings > tpowa > > -- > Tobias Powalowski > Archlinux Developer & Package Maintainer (tpowa) > http://www.archlinux.org > tp...@archlinux.org > >
Re: [arch-general] ntp settings
On Sun, Feb 05, 2012 at 05:21:47PM -0500, Sébastien Leblanc wrote: > Myself being a non-vi user, I find that visudo is hard for people used > to nano. Besides, use of visudo is only critical for systems where no > one knows the root password (default Ubuntu for example). If you know > the root password and are on a generally single user system where > there is no risk that two people would be modifying the sudoers file > at the same time, don't be afraid to edit /etc/sudoers with nano. If > you manage to break sudo, you can always fix it with su -c "nano > /etc/sudoers" and by typing the root password. visudo(8) does more than locking. It performs basic syntax checks after editing and tells you if (and where) any errors were found. It's the right tool for this job, so why bother with workarounds if using another editor is as simple as setting "$VISUAL" or "$EDITOR" (which you should do in your shell rc file anyway if you're not used to using vi(1))? Furthermore, it's pretty usual that only very few (to none) users know the root password, even if there's a larger number of privileged users. > > -- > Sébastien Leblanc
Re: [arch-general] ntp settings
On Sun, Feb 05, 2012 at 08:57:06PM +, P Nikolic wrote: > On Sunday 05 Feb 2012 21:48:54 Lukas Fleischer wrote: > > On Sun, Feb 05, 2012 at 08:31:11PM +, P Nikolic wrote: > > > On Sunday 05 Feb 2012 21:01:04 Ralf Mardorf wrote: > > > > On Sun, 2012-02-05 at 18:37 +, P Nikolic wrote: > > > > > Hi . > > > > > > > > > > I am trying to set the timezone up correctly and setup ntp to run . > > > > > > > > > > I have tried using System Settings in KDE but for some reason it does > > > > > not > > > > > accept the password . If i enter the password (root password) it > > > > > reply's > > > > > failed to Authenticate and greys everyting out for a few seconds > > > > > i > > > > > have sudo installed as that was suggeted as the problem on the > > > > > previous > > > > > install that crashed and burned what else is missing ntp is > > > > > installed > > > > > as well .. > > > > > > > > > > > > > > > Pete . > > > > > > > > Are you member of the group wheel? Did you setup sudo using visudo? > > > > > > Yes to wheel and no to visudo as i dont do vi now if you can joesudo or > > > nanosudo then i can get there but vi no hope > > > > `VISUAL=nano visudo`. `VISUAL=joe visudo`. > > > > > Pete . > > yep sorted thanksjust me and vi do not mix at all never have never will > same as i could never hang with edlin either i always use a TSR editor on > dos Sidekickand joe on Linux Anyway, please consider consulting the appropriate man page (visudo(8) in this case) next time... Oh, and please read [1]. No offense, but this will help you get more feedback for sure. > > Pete . > > -- > Linux 7-of-9 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET 2012 x86_64 > AMD Phenom(tm) 9600B Quad-Core Processor AuthenticAMD GNU/Linux [1] http://tinyurl.com/4qcee
Re: [arch-general] ntp settings
On Sun, Feb 05, 2012 at 08:31:11PM +, P Nikolic wrote: > On Sunday 05 Feb 2012 21:01:04 Ralf Mardorf wrote: > > On Sun, 2012-02-05 at 18:37 +, P Nikolic wrote: > > > Hi . > > > > > > I am trying to set the timezone up correctly and setup ntp to run . > > > > > > I have tried using System Settings in KDE but for some reason it does not > > > accept the password . If i enter the password (root password) it reply's > > > failed to Authenticate and greys everyting out for a few secondsi > > > have sudo installed as that was suggeted as the problem on the previous > > > install that crashed and burned what else is missing ntp is installed > > > as well .. > > > > > > > > > Pete . > > > > Are you member of the group wheel? Did you setup sudo using visudo? > > Yes to wheel and no to visudo as i dont do vi now if you can joesudo or > nanosudo then i can get there but vi no hope `VISUAL=nano visudo`. `VISUAL=joe visudo`. > > Pete . > > -- > Linux 7-of-9 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET 2012 x86_64 > AMD Phenom(tm) 9600B Quad-Core Processor AuthenticAMD GNU/Linux
Re: [arch-general] [arch-dev-public] ChangeLog usage ..
On Sat, Jan 14, 2012 at 09:18:06AM +1000, Allan McRae wrote: > On 14/01/12 08:51, Lukas Fleischer wrote: > > On Fri, Jan 13, 2012 at 07:44:31PM +0100, Seblu wrote: > >> On Fri, Jan 13, 2012 at 4:02 PM, Lukas Fleischer > >> wrote: > >>> On Fri, Jan 13, 2012 at 11:49:39AM -0300, Angel Velásquez wrote: > >>> I'm all for writing useful (and detailed, if necessary) commit messages > >>> instead of writing ChangeLog entries. We use a VCS for some reason. > >>> Using proper commit messages makes changes damn easy to follow without > >>> having to maintain these inconvenient ChangeLog files. > >> It's more easy to read a human changelog, (shipped with packages which > >> don't needs to connect to archlinux.org), than developer oriented > >> commits. > > > > I don't really see any big difference here. Commit messages should be > > detailed and comprehensible as well. I'm not sure what you mean by > > "developer oriented" but if your commit messages cannot be understood by > > any user, you're probably doing something wrong :) > > > > Check [1] for an example of how a commit message should look like. > > While I agree that a good commit message should be used, that is a side > point to the original email. > > What was being asked was that if someone chooses to maintain a ChangeLog > for their package, then you should also update the ChangeLog file if you > make an update to that package. Agreed, and I'm also for keeping the maintainer's PKGBUILD formatting if you update a package (unless it breaks something, of course). Sorry for being slightly off-topic and turning this into a "ChangeLog vs. commit log" discussion. > > Allan
Re: [arch-general] [arch-dev-public] ChangeLog usage ..
On Fri, Jan 13, 2012 at 07:44:31PM +0100, Seblu wrote: > On Fri, Jan 13, 2012 at 4:02 PM, Lukas Fleischer > wrote: > > On Fri, Jan 13, 2012 at 11:49:39AM -0300, Angel Velásquez wrote: > > I'm all for writing useful (and detailed, if necessary) commit messages > > instead of writing ChangeLog entries. We use a VCS for some reason. > > Using proper commit messages makes changes damn easy to follow without > > having to maintain these inconvenient ChangeLog files. > It's more easy to read a human changelog, (shipped with packages which > don't needs to connect to archlinux.org), than developer oriented > commits. I don't really see any big difference here. Commit messages should be detailed and comprehensible as well. I'm not sure what you mean by "developer oriented" but if your commit messages cannot be understood by any user, you're probably doing something wrong :) Check [1] for an example of how a commit message should look like. > We can make the synthesis of several commit in the changelog to make > it more understandable. And still try to make atomic commits. Yes, separate changelogs make sense if we do summarize changes that are spread over a lot of commits (like the "NEWS" file in pacman). We usually don't have such changes to our packages, though (99% of changes are made in a single commit). Please let me know if I'm wrong... > > In addition separates VCS message and package history, let's it > independant from vcs tools (svn/git/hg) we choose at a time. Proper VCS support importing history from others (check git-svn(1) and git-cvsimport(1) for Git). And even if it cannot not be done, we could still convert commit history to a text file later. > -- > Sébastien Luttringer > www.seblu.net [1] http://projects.archlinux.org/svntogit/community.git/commit/?id=77c0210bce1365115811f4cbb37485dc64b7f15f
Re: [arch-general] [arch-dev-public] ChangeLog usage ..
On Fri, Jan 13, 2012 at 11:49:39AM -0300, Angel Velásquez wrote: > Hi, > > For some packages that i've been maintaining over months I have to > keep a ChangeLog .. since it's supported with pacman, and give us > (devs and tus) some resume, also this resume give to our users the > idea of what is being applied in this release/version of a package. > > I usually do that on critical packages, and packages that have a > previous ChangeLog file. > > So, a good practice is, if you're doing the favour to other dev to > maintain or rebuild his package, and this guy added a ChangeLog .. the > correct way to proceed is to write something in it, maybe this can > sound you like zomfg this is not kiss! .. but stuff like this bring us > quality IMHO. For example, I have been busy those months, and maybe i > will continue to be busy a few months more, but trust me, in my real > spare time, i dedicate sometime to the project, and when I saw that my > packages were updated I would like to know who and what change he did > instead to diff + look at the bugtracker + look at the rebuilds + look > at the mailing list .. as i've said, sometimes the free time is like 2 > hours or less per day, so i loose some much time just seing commit > logs and checking the bug tracker, having the changelog that I've been > using will help me for sure. > > Again, i'm not criticizing anybody, i'm just in favour of start doing > the things better and better, and i've had several packages that were > updated by someother devs/tus (and I am grateful with them) but, they > miss the part to fill the ChangeLog which makes me wonder what they > did on the packages (for sure, i've read a lot and now i'm confident > of what they did, but this makes me waste a whole morning reading > mails, bugtracker, and reading the logs of the svn). I'm all for writing useful (and detailed, if necessary) commit messages instead of writing ChangeLog entries. We use a VCS for some reason. Using proper commit messages makes changes damn easy to follow without having to maintain these inconvenient ChangeLog files. > > That said, Have a nice weekend, i will try to smash bugs and update > some of my packages in order to be up to date the next week. P.S.: You should probably CC mails to aur-general if they affect TUs as well. > > > -- > Angel Velásquez > angvp @ irc.freenode.net > Arch Linux Developer / Trusted User > Linux Counter: #359909 > http://www.angvp.com
Re: [arch-general] signoff linux-3.1.5-1
On Fri, Dec 16, 2011 at 08:17:24PM +0100, Karol Blazewicz wrote: > On Fri, Dec 16, 2011 at 8:14 PM, David C. Rankin > wrote: > > All, > > > > I haven't seen tpowa's normal kernel signoff > > Maybe it's because > http://mailman.archlinux.org/pipermail/arch-dev-public/2011-November/021972.html > ? Correct. You can still reply to signoff reports if you want to leave a comment.
Re: [arch-general] Fwd: [aur-general] Dropping tango-icon-theme{, -extras}
On Tue, Nov 22, 2011 at 11:43:17AM +0200, Ionut Biru wrote:
> On 11/22/2011 11:23 AM, Lukas Fleischer wrote:
> > Forwarding this to arch-general to get some developers' attention on
> > this (I failed at entering the mail address the first time).
> >
> > ----- Forwarded message from Lukas Fleischer
> > -
> >
> > Date: Tue, 22 Nov 2011 10:17:47 +0100
> > From: Lukas Fleischer
> > To: arch-general@archlinux, aur-gene...@archlinux.org
> > Subject: [aur-general] Dropping tango-icon-theme{,-extras}
> > User-Agent: Mutt/1.5.21 (2010-09-15)
> >
> > Hi!
> >
> > All sources hosted at tango.freedesktop.org became inaccessible [1] a
> > couple of days ago, probably due to some software upgrade on
> > freedesktop.org.
> >
> > I contacted upstream yesterday and was told that tango-icon-theme,
> > tango-icon-theme-extras and icon-naming-utils are dead and that we
> > shouldn't rely on upstream sources being available (they even mentioned
> > they probably won't care about the 404). It has been suggested to use
> > gnome-icon-theme and gnome-icon-theme-extras instead.
> >
> > Given that xfce4-settings seems to be the only package depending on
> > tango-icon-theme, I'd suggest to:
> >
> > * Remove the "tango-icon-theme" dependency from xfce4-settings (this
> > shouldn't break anything, does it?)
> >
>
> is broken from the time we remove the icon theme. Xfce is going to miss
> all those icons until somebody installs a new icon theme. We have to
> replace with something.
Well, xfce4-settings already depends on gnome-icon-theme and
uninstalling tango-icon-theme (`pacman -Rdd tango-icon-theme`) didn't
break xfce4-settings for me. Not sure if it uses a few icons specific to
tango-icon-theme, though. I doubt so.
Debian lists tango-icon-theme as a recommendation for xfce4-settings
also, so it probably only is a matter of having one or another icon
theme.
>
> did somebody talked with xfce about this or at least with xfce maintainers?
>
> > * Move both tango-icon-theme and tango-icon-theme-extras to
> > [unsupported].
> >
> > * Think about what to do with icon-naming-utils. We seem to need those
> > for gnome-icon-theme and gnome-icon-theme-symbolic, so putting the
> > source tarball on our source mirror might be the best thing to do
> > (unless there's a proper alternative, of course).
> >
>
>
> gentoo distfiles are useful for something. I'll take care of
> icon-naming-utils.
Thanks!
>
>
> > Objections and other suggestions welcome.
> >
> > Cheers,
> > Lukas
> >
> > [1] http://tango.freedesktop.org/Tango_Icon_Library#Download
> >
> > - End forwarded message -
>
>
> --
> Ionuț
>
P.S.: The related bug report I created yesterday [1] has just been
reopened by Ionut. Thanks for that.
[1] https://bugs.archlinux.org/task/27208
[arch-general] Fwd: [aur-general] Dropping tango-icon-theme{, -extras}
Forwarding this to arch-general to get some developers' attention on
this (I failed at entering the mail address the first time).
- Forwarded message from Lukas Fleischer -
Date: Tue, 22 Nov 2011 10:17:47 +0100
From: Lukas Fleischer
To: arch-general@archlinux, aur-gene...@archlinux.org
Subject: [aur-general] Dropping tango-icon-theme{,-extras}
User-Agent: Mutt/1.5.21 (2010-09-15)
Hi!
All sources hosted at tango.freedesktop.org became inaccessible [1] a
couple of days ago, probably due to some software upgrade on
freedesktop.org.
I contacted upstream yesterday and was told that tango-icon-theme,
tango-icon-theme-extras and icon-naming-utils are dead and that we
shouldn't rely on upstream sources being available (they even mentioned
they probably won't care about the 404). It has been suggested to use
gnome-icon-theme and gnome-icon-theme-extras instead.
Given that xfce4-settings seems to be the only package depending on
tango-icon-theme, I'd suggest to:
* Remove the "tango-icon-theme" dependency from xfce4-settings (this
shouldn't break anything, does it?)
* Move both tango-icon-theme and tango-icon-theme-extras to
[unsupported].
* Think about what to do with icon-naming-utils. We seem to need those
for gnome-icon-theme and gnome-icon-theme-symbolic, so putting the
source tarball on our source mirror might be the best thing to do
(unless there's a proper alternative, of course).
Objections and other suggestions welcome.
Cheers,
Lukas
[1] http://tango.freedesktop.org/Tango_Icon_Library#Download
- End forwarded message -
Re: [arch-general] [arch-dev-public] Package signoffs page
On Thu, Nov 03, 2011 at 10:16:19AM -0500, Dan McGee wrote: > Devs, > > This seems like a good time to get the ball fully rolling on the > package signoffs page: https://www.archlinux.org/packages/signoffs/ > > I and a few others would like to make this the goto for signoffs- > fewer emails, easier to see at a glance what signoffs are pending, > etc. Given we have a large set of packages in [testing] right now for > some [core] signature rebuilds, this seems like an ideal time to get > some feedback so we can fully migrate to using this page. > > So this is a call for (constructive) feedback on what more I need to > implement to make it useful to all of you. A list below is things > already on the todo list that definitely need to be done; if there are > other things that *need* to be done, please let me know. If there are > other things that would be nice, let me know too, but that might be > worth a feature request that can be worked on after we switch. > > Must haves: > * A way to cancel a signoff > * Signoff "blacklist" or modification- basically say "this package > doesn't need signoffs, just remove it from display" > * A daily summary email saying "hey gang, here are today's pending signoffs" +1. And +1 to a "red flag"/block feature to ensure packages that nuked someone's system won't be moved until this is resolved. By the way, are TUs encouraged to give their sign-offs as well or is this a dev-only thing? Oh, how will we handle user sign-offs in the future (I remember that these were asked for a few times)? Replies to the daily summary mails?
Re: [arch-general] Any suggestions on frequently rebuilding a git package?
On Tue, Sep 20, 2011 at 06:02:21PM +0800, XeCycle wrote: > Lukas Fleischer writes: > > [...] > > >> > 2. Comment line 47 and 48 (PKGBUILD-git.proto), uncomment if you want a > >> > clean build. > >> > >> Well, this is my PKGBUILD-git.proto: > >> > >> 43 # > >> 44 # BUILD HERE > >> 45 # > >> 46 ./autogen.sh > >> 47 ./configure --prefix=/usr > >> 48 make > >> > >> Do you mean commenting 46 & 47? > > > > > > $ sed -n '47,48p' /usr/share/pacman/PKGBUILD-git.proto > > rm -rf "$srcdir/$_gitname-build" > > git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build" > > > > > > You should upgrade abs to 2.4.3-1. > > $ LC_ALL=C pacman -Qo /usr/share/pacman/PKGBUILD-git.proto > /usr/share/pacman/PKGBUILD-git.proto is owned by abs 2.4.3-1 > > What's up? You either modified that file (use `pacman -S abs` to reinstall the package in that case) or use a weird editor with weird line numbering.
Re: [arch-general] Any suggestions on frequently rebuilding a git package?
On Tue, Sep 20, 2011 at 05:01:58PM +0800, XeCycle wrote: > Many thanks to all of you, I'm trying them out. > > So the point is to never clean the code tree, nor cleaning those > compiled objects. > > However I think re-configuring is not always needed, which results in > lots of rebuilding. So It's better to decide myself when it's needed? > > Philipp Überbacher writes: > > > Excerpts from XeCycle's message of 2011-09-18 17:33:56 +0200: > >> Hi, I build Emacs from git quite frequently, about twice a month or so. > >> However the PKGBUILD from AUR rebuilds everything each time, which takes > >> too many time I think. Perhaps Emacs is small, but I think there should > >> be a way to prevent too many rebuilds --- is that possible? > > > > 1. Don't use -c (clean) > > I already did it. > > > 2. Comment line 47 and 48 (PKGBUILD-git.proto), uncomment if you want a > > clean build. > > Well, this is my PKGBUILD-git.proto: > > 43 # > 44 # BUILD HERE > 45 # > 46 ./autogen.sh > 47 ./configure --prefix=/usr > 48 make > > Do you mean commenting 46 & 47? $ sed -n '47,48p' /usr/share/pacman/PKGBUILD-git.proto rm -rf "$srcdir/$_gitname-build" git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build" You should upgrade abs to 2.4.3-1.
Re: [arch-general] [arch-dev-public] Git for the repos
On Thu, Aug 25, 2011 at 11:35:47AM -0300, Ángel Velásquez wrote: > 2011/8/24 Florian Pritz : > > So it came up in IRC again and I'll try to sum up the discussion: > > > > SVN checkouts tend to break, some people only use it for our repos and > > not anywhere else, it's slow. > > > > We agreed on one git repo per package because you can't do partial > > checkouts in git and you hardly need the history of all packages anyway. > > > > To keep track of released packages, dbscripts maintains it's own (git?) > > meta database which contains only the package version and pacman repo of > > the package. The version corresponds to a tag in the package's git repo. > > > > We can't use tags like "testing-i686" because you can't reuse tags in git. > > > > I'd like to hear some comments about this. > > > > -- > > Florian Pritz > > > > > > First I need to ask some questions (understant that I don't get why is > this getting proposed) > > Well, why are us needing of git? what goal we want to achieve? .. > > Devtools have some complications (X number of commits for package i.e) > but, this will change with git? how? .. it will git increase the speed > or the workflow of our devtools? why git, not hg, darcs or another > DVCS? Dan and me worked on some patches to reduce the number of commits recently [1], [2], [3] and devtools-git only commits twice per commitpkg invocation. First commit to push changes to trunk, second commit to release to the repositories. Note that this has some impacts on speed. This is mostly related to SVN and the way we need to create tags when releasing to the repositories with a single commit. I pointed that out in a separate thread on arch-projects [4] but I sadly didn't get any feedback yet. Maybe this should be considered, also. Not that I have a strong feeling about it. I just thought I should mention it. [1] http://projects.archlinux.org/devtools.git/commit/?id=8384ad84 [2] http://projects.archlinux.org/devtools.git/commit/?id=6ef4d5f3 [3] http://projects.archlinux.org/devtools.git/commit/?id=61010062 [4] http://mailman.archlinux.org/pipermail/arch-projects/2011-August/001748.html
Re: [arch-general] [arch-dev-public] Git for the repos
On Thu, Aug 25, 2011 at 01:41:50PM -0400, Eric Bélanger wrote: > On Thu, Aug 25, 2011 at 1:38 PM, Andreas Radke wrote: > > Am Wed, 24 Aug 2011 22:53:55 +0200 > > schrieb Florian Pritz : > > > >> So it came up in IRC again and I'll try to sum up the discussion: > >> > >> SVN checkouts tend to break, some people only use it for our repos and > >> not anywhere else, it's slow. > > > > Latest devtools changes break some commits not copying files into the > > repos directories. > > > > There is a patch in arch-project ML to fix that. Pierre pushed that patch some hours ago [1], so this should be fixed with the next devtools release. [1] http://projects.archlinux.org/devtools.git/commit/?id=c2420902
Re: [arch-general] [arch-dev-public] removing cryptsetup from base group
On Tue, Aug 09, 2011 at 03:37:15PM +0300, Ionut Biru wrote: > Hi, > > this package brings in our clean chroots libgcrypt dependency. > > Until recently, gnutls had libcrypt as dependency but now it relies > on nettle. That means that packages linked to gnutls and relied on > libgcrypt dependency from it, will be broken. > > We have a gnutls 3.0.0 rebuild in progress in staging and because > libgcrypt is in our clean chroots, everything is fine, functionality > wise but I noticed that we skipped adding ligcrypt to dependency > mostly because namcap and us assume that everybody have base group > installed. > > Please check your packages to see if they link to libgcrypt and add > it to dependency if they do. -1 to removing cryptsetup from base. Note that cryptsetup is an essential tool for setups with system encryption enabled and is required during boot time. It should also stay on our CDs (not only as available package but also installed on the root-image to allow for using the CD as a Live CD, even if partitions are encrypted; AIF probably depends on it as well). Additionally, removing cryptsetup from base will require users to install it manually when using mkinitcpio's "encrypt" hook. If you decide to remove it anyway, keep in mind to: * Keep it on our Live CDs. * Add a note to our default "/etc/mkinitcpio.conf". * Maybe also add some note in AIF.
Re: [arch-general] More urls in PKGBUILD or on package details page
On Mon, Aug 08, 2011 at 10:27:29PM +0400, Sergej Pupykin wrote: > Hi All, > > what if we add somehow direct links to "report upstream bug" and may > be link for easier checking new version (RSS link, > sf.net/project/..., another download page or something else)? > > I think direct link to upstream bugtracker should be usefull. Who will manage these links? There isn't any PKGBUILD field that allows for fetching the location of the upstream bug tracker, so we would need an extra form/field and add this information via archweb (or some other interface).
Re: [arch-general] Enforcing CFLAGS in PKGBUILDs
On Fri, Aug 05, 2011 at 10:54:41AM +0200, Jan de Groot wrote: > On Fri, 2011-08-05 at 15:23 +0800, Ray Rashif wrote: > > > For eg. some developers like to enforce -O3, so they should first get > > the system CFLAGS and override it's -O*, if any. > > > > But in general, I agree. We shouldn't enforce anything either unless > > we're trying to fix something. The ardour PKGBUILD does this [1], > > maybe it shouldn't, but I assume the -O3 becomes redundant when we > > pass system CFLAGS to the build as a configuration flag. > > > > [1] > > http://projects.archlinux.org/svntogit/packages.git/tree/ardour/trunk/PKGBUILD > > Looking at ardour, I see it's also patched to support gcc 4.6. Now let's > say something about -O3: -O3 optimization can be very bad and the > results are extremely dependent on the compiler version. Something that > works optimal with gcc 4.4 and -O3 can break completely with gcc 4.6 and > -O2. You should file a bug report if it does. Given the number of PKGBUILDs that patch optimization levels, I would also say that this is only true for a minority of cases. > Just adding -O3 to CFLAGS without knowing which compiler is used is > plain stupid. Check this blog for example: > http://glandium.org/blog/?p=1975 > There someone from Mozilla claims they're finally able to build with O3 > +PGO with GCC 4.5. This was at the time we were already doing O2+PGO > from our PKGBUILD with 4.5 and now 4.6.
Re: [arch-general] Enforcing CFLAGS in PKGBUILDs
On Fri, Aug 05, 2011 at 03:23:44PM +0800, Ray Rashif wrote: > On 5 August 2011 07:35, Lukas Fleischer wrote: > > My own opinion is that we shouldn't patch anything here. While using the > > same optimization flags for all packages might result in some kind of > > consistency, one of our main guidelines - not to do any unnecessary > > modifications - is kind of violated here. We should trust upstream > > having chosen any explicit optimization flags with care (in some cases, > > enforcing optimization flags might even lead to heavy performance > > impacts - although this is unlikely to happen). I am aware that there > > are some corner cases for sure, for which I'd say overriding CFLAGS is > > okay. However, this shouldn't be common practice, imho. > > > > Opinions? > > I have wondered about this before. Upstream developers should include > in their code/buildsystem proper conditional CFLAGS, i.e append to > system CFLAGS, override _only_ what they want to override, and don't > append anything already part of the system CFLAGS. > > For eg. some developers like to enforce -O3, so they should first get > the system CFLAGS and override it's -O*, if any. Well, just appending their own flags (which is what most Makefiles do) is no problem here as only the last "-O" option will matter (check my reply to Allan). > > But in general, I agree. We shouldn't enforce anything either unless > we're trying to fix something. +1. > The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume > the -O3 becomes redundant when we pass system CFLAGS to the build as a > configuration flag. Yeah, I agree that patching is okay if it's necessary in order to build a package (or in order not to break anything). That's what I mentioned above.
Re: [arch-general] Enforcing CFLAGS in PKGBUILDs
On Fri, Aug 05, 2011 at 03:02:17PM +1000, Allan McRae wrote: > On 05/08/11 09:35, Lukas Fleischer wrote: > >In the course of a discussion with the xwax [1] developer, I was asked > >the question why we would override CFLAGS (optimization levels, in > >particular) if upstream already provides them. Given that there are in > >fact loads of packages in our repositories that seem to follow this > >practice (`grep -- '-O[0-9]' /var/abs/*/*/PKGBUILD` reveals some of > >those), I'm forwarding this question to the ML. > > > >My own opinion is that we shouldn't patch anything here. While using the > >same optimization flags for all packages might result in some kind of > >consistency, one of our main guidelines - not to do any unnecessary > >modifications - is kind of violated here. We should trust upstream > >having chosen any explicit optimization flags with care (in some cases, > >enforcing optimization flags might even lead to heavy performance > >impacts - although this is unlikely to happen). I am aware that there > >are some corner cases for sure, for which I'd say overriding CFLAGS is > >okay. However, this shouldn't be common practice, imho. > > > >Opinions? > > > > My opinion is that the upstream Makefile should add their CFLAGS and > not override the ones provided by the environment unless there is a > very good reason to do so. That way everybody gets the CFLAGS they > want. Agreed. Just appending CFLAGS will effectively result in overriding some options, though. Quoting the gcc(1) manpage: If you use multiple -O options, with or without level numbers, the last such option is the one that is effective. That is probably the reason some of us patch Makefiles to enforce our optimization flags.
[arch-general] Enforcing CFLAGS in PKGBUILDs
In the course of a discussion with the xwax [1] developer, I was asked the question why we would override CFLAGS (optimization levels, in particular) if upstream already provides them. Given that there are in fact loads of packages in our repositories that seem to follow this practice (`grep -- '-O[0-9]' /var/abs/*/*/PKGBUILD` reveals some of those), I'm forwarding this question to the ML. My own opinion is that we shouldn't patch anything here. While using the same optimization flags for all packages might result in some kind of consistency, one of our main guidelines - not to do any unnecessary modifications - is kind of violated here. We should trust upstream having chosen any explicit optimization flags with care (in some cases, enforcing optimization flags might even lead to heavy performance impacts - although this is unlikely to happen). I am aware that there are some corner cases for sure, for which I'd say overriding CFLAGS is okay. However, this shouldn't be common practice, imho. Opinions? Link to the original thread (for clarification) [2]. [1] http://www.xwax.co.uk/ [2] http://sourceforge.net/mailarchive/forum.php?thread_name=1108042258340.847%40localhost&forum_name=xwax-devel
Re: [arch-general] makepkg and its dependencies, how to create a good build chroot?
On Thu, Jul 21, 2011 at 09:59:16PM +0200, Magnus Therning wrote:
> For a while now I've been using some scripts to handle the details for
> creating build chroots, updating them, and triggering builds in them.
> It's all part of my work with building Haskell packages for Arch.
>
> To create a chroot I used this line:
>
> mkarchroot -f -C ${pacman_conf} \
> -M /usr/share/devtools/makepkg-${arch}.conf ${CHROOT_ROOTDIR} \
> util-linux-ng pacman sudo wget file grep base-devel ghc
>
> Well, that is, I used that line up until yesterday, and it worked fine
> until then. Yesterday I ran into the problem that the command `find`,
> which is used by `makepkg`, was missing in the chroot. A little while
> later I found the same to be true for `gzip`. So, I added `findutils`
> and `gzip` to the list of packages to be installed.
>
> Now, `makepkg` comes in the `pacman` package, and it doesn't have any
> dependencies on either of these packages, not even an optional
> dependency.
>
> This leaves me with three questions:
>
> 1. Why does `pacman` (the package) not depend on `findutils` and
>`gzip`, when `makepkg` clearly needs both those packages to
>function properly?
Because both findutils and gzip are part of the "base" group and
supposed to be installed on every Arch Linux setup.
>
> 2. Are there any other packages I ought to install in a build chroot
>besides those I've listed above?
Yeah, you can take the easy way out by just installing everything from
base (and maybe base-devel if you intend to build stuff and need those
utilities).
>
> 3. Dependencies of packages change over time, so is there a shortcut
>to making sure I always create a good build chroot (a group maybe)?
See above.
Re: [arch-general] [PATCH] Change pacman calls with -Sd flags to -Sdd
On Fri, May 13, 2011 at 01:07:58PM +0200, Jakob Gruber wrote: > The old pacman -d flag is now -dd since commit 111e07d0be44b7. > > Signed-off-by: Jakob Gruber > --- > checkpkg |2 +- > mkarchroot |2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > You should probably rather send this to the arch-projects mailing list.
Re: [arch-general] Change Arch's default crond
On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote: > On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin < > drankina...@suddenlinkmail.com> wrote: > > > On 04/06/2011 10:34 PM, Heiko Baums wrote: > > > >> Upstream stability makes sense. If redhat is behind cronie, then that > >>> > seems like the logical choice. > >>> > >> Why is this logical? Is it the developer what makes a software good or > >> is it the features and the stability? If Redhat's cronie has less > >> features than fcron then fcron is the logical choice, of course. > >> > > > > You are correct. The long term stability was just my thought. Like I said > > earlier in my message -- It doesn't matter to me which cron we have -- as > > long as we have one that works :) I have no say in the matter, so I will, > > of course, defer to whatever decision you guys reach. I just want to make > > sure we have a cron by default :) > > > So what's the status here? I pulled cronie into [community-testing] a couple > of days ago and will probably merge it into [community] soon. So that's the > one I vote. > > But regardless of which one we choose in my opinion the sooner we get rid of > dcron the better. --Kaiting. I don't want to be pedantic, but what's the point of that? Moving arbitrary cron daemons that no one uses to [community] is nonsense (according to the TU guidelines, you shouldn't even have moved it without prior discussion and consensus on aur-general at all - but as I said before, I don't want to be pedantic here...) Adding yet another cron daemon to our repositories makes sense as soon as there's a clear decision to switch default daemons. Just moving low usage stuff to [community] because you're able to do so definitely doesn't...
Re: [arch-general] Can't connect to WEP-protected network
On Thu, Mar 17, 2011 at 11:51:17AM -0400, John Albright wrote: > Sorry, I accidentally clicked the wrong reply link in Gmail. > > On Thu, Mar 17, 2011 at 11:47 AM, Jan de Groot wrote: > > > On Thu, 2011-03-17 at 11:41 -0400, John Albright wrote: > > > The channel is 11, and I just realized that I can only specify 1-4 in > > > my > > > connection settings. So maybe that's the issue. However, I'm just > > > going to > > > skirt around the issue and change the network to WPA instead. I didn't > > > at > > > first because it's not my network, but I've been given the go-ahead. > > > > Check your wireless regulatory domain in /etc/conf.d/wireless-regdom. > > > > BTW: top posting is annoying. > > > > Double fail.
Re: [arch-general] xorg upgrade - error: failed to commit transaction (conflicting files)
On Tue, Mar 15, 2011 at 02:44:25PM -0500, David C. Rankin wrote:
> On 03/15/2011 02:25 PM, David C. Rankin wrote:
> >On 03/15/2011 01:42 PM, Cédric Girard wrote:
> >>The useful thing to do in that case is to run a "pkgfile -s" (provided by
> >>pkgtools) on those files to see which package own them.
> >>
> >>Regards,
> >
> >(smacks self)
> >
> >Thanks Cédric,
> >
> >I have a bunch more boxes to update, so I'll get the information and report
> >back :)
> >
>
> This must be a fluke due to something I can't explain on this one
> box. I have now upgraded 4 more boxes and I can't reproduce it.
> Strange. I've got a few more boxes to go, so I'll let you know if I
> see this again. The big issue on this one box is the PKGBUILD
> depends=('xorg') reinstalling everything. I'll follow up on that in
> the other thread. It may just be something with this one box as
> well.
Well, this is probably related to FS#23271, isn't it? [1]
[1] https://bugs.archlinux.org/task/23271
Re: [arch-general] Dropping Oracle OpenOffice
On Mon, Mar 14, 2011 at 10:59:20AM +0100, Ondřej Kučera wrote: > Hello, > > On 7.3.2011 18:45, Andreas Radke wrote: > >LibreOffice has recently proved to be a solid replacement for Oracle > >OpenOffice. I'm about to drop all Oracle OOo packages from our repos. > > I have a small concern. I regularly need to do a batch conversion of > ODS files to CSV. For a long time I've been using JODConverter [1] > to do so. However, with (Arch Linux's) LibreOffice it doesn't seem > to work. I've found users claiming that JODConverter works with > LibreOffice for them [2] (they don't mention their distribution > though), I've also found an open bug report about connecting to > LibreOffice [3] but I don't think it applies here. > > Anyway this is the error I'm getting: > java.net.ConnectException: connection failed: > 'socket,host=127.0.0.1,port=2002,tcpNoDelay=1'; > java.net.ConnectException: Connection refused > With openoffice-base everything works fine. I've tried to look at > PKGBUILDs of both packages to see if there isn't a visible > difference in configure options that might be a culprit but the > PKGBUILDs are a bit too complicated for me to understand them well. > > Is there anyone who would be able to help me make this work? I'd > really appreciate it, this is the last reason that forces me to use > Oracle's OpenOffice. I'd guess that LibreOffice is probably just listening at the wrong port. Did you check [1]? Looks kinda related. [1] https://bbs.archlinux.org/viewtopic.php?id=110406
[arch-general] Adding AUR packages to [community] packages' provides
Well, I'm addressing current blacklisting issues with the AUR [1]. I noticed that some of the packages in the official repos have AUR packages as provides, some of them (well, at least one of them, didn't search for more) were even added due to FRs [2]. Donnu if this applies to [core] and [extra] as well. Is that regular practice? Imho, we shouldn't do that. The AUR is something to be considered separately. If we start to care about provides/conflicts with AUR packages, we'll need to add all "-devel"/"-svn"/"-git"/"-beta" packages in the AUR to the official packages conflicts and provides as well. And we'll need to start searching for alternative repos to ensure there's no conflict with our official packages. Seriously, we should be consistent here. [1] http://mailman.archlinux.org/pipermail/aur-general/2011-February/013811.html [2] https://bugs.archlinux.org/task/16495
Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]
On Tue, Feb 22, 2011 at 11:41:12AM -0600, David C. Rankin wrote: > On next reboot/restart, I got the kdesktop.kcrash (attached). So then I > downgraded glibc (2.13-4 -> 2.13-3), restarted Trinity -> perfect No > kdesktop,kcrash. It looks like this is a glibc issue, so I'll follow up > (below) > with Arch to make sure it looks like glibc and not a package issue. Thanks for > your help. > > cc: arch-general > > Arch devs - Do you think this could be a packaging/patch issue with Arch, or > do you think is going to be glibc itself? It looks like glibc to me, but I > thought I'd ask first before going to the glibc folks. Allan broke it! No, seriously... glibc 2.13-4 introduced a patch from the Fedora glibc branch that is not included in mainline glibc and fixes issues with prelink [1]. Obviously, this has some side effects. Seems like it requires some more investigation. [1] https://bugs.archlinux.org/task/22656
Re: [arch-general] new build of mutt in [testing]
On Wed, Feb 16, 2011 at 01:15:08PM +0100, Gaetan Bisson wrote: > Hi everyone, > > I have made a new build of mutt with two significant changes: > > 1. Use ncurses rather than slang. (Slang made sense before, but ncurses > supports Unicode now, is more featureful and popular, and MuttWiki > recommends it as a solution to many slang-related problems.) > > 2. Use libidn for internationalized domain name support. > > As emails are important, the build is now in [testing] and I will wait a > few days before moving it to [extra]. Feedback is welcome! Works fine for me. And I have the feeling that it somehow takes much less time to open large mailboxes now (about 5-10 times faster) :)
Re: [arch-general] Why does v4l-utils package exists both in [extra] and [multilib]?
On Wed, Jan 12, 2011 at 10:24:34AM +0500, Kirill Churin wrote: > Why does v4l-utils package exists both in [extra] and [multilib]? > > Found it while updating Skype wiki page. It doesn't. There's v4l-utils in [extra] for both i686 and x86_64 architectures and lib32-v4l-utils in [multilib] for 32-bit applications running on x86_64 (e.g. Skype).
Re: [arch-general] How to get colorized output during prog compilation? ( Colorgcc doesn't color gcc output )
On Sun, Jan 02, 2011 at 06:36:40PM +0100, János Illés wrote: > Obviously. > You have to modify the Makefile. You can also use symlinks. By default, colorgcc creates symlinks in "/bin" without informing the user (created a bug ticket [1] concerning this issue btw as I don't like that way of automatically creating wrapper symlinks somewhere). You can either change that or try to fix your "$PATH". [1] https://bugs.archlinux.org/task/22279
Re: [arch-general] what happened to nut (network-ups-tools)?
On Mon, Nov 29, 2010 at 08:03:28PM -0600, David C. Rankin wrote: > Where did nut go? I just checked and network-ups-tools is no longer > available. > Did it change names? I must have missed it. Thanks. It has been moved to the AUR [1] on 2010-09-21. [1] https://aur.archlinux.org/packages.php?ID=5379
Re: [arch-general] [aur-general] [extra] repository cleanup
On Wed, Nov 10, 2010 at 12:43:28PM +0100, Heiko Baums wrote: > You should really think about that. There are many of the most > important, oldest and best known packages in this list like dia, ding, > xboard, eboard, epdfview, slmodem etc. > > In other words, your list is likely the half of the distro. > > If you would put all of them to AUR then you could give up Arch Linux, > because then it has almost no advantage over Gentoo, that is, then will > Arch Linux become a second Gentoo, because the users will have to > compile a lot of (most of the) important packages manually. Erm. There's still a chance all those packages will be moved to [community] instead of unsupported. E.g. dia, xboard, epdfview and slmodem are still marked as candidates to [community] and will not be moved to the AUR.
Re: [arch-general] How to do this
On Sun, Oct 24, 2010 at 05:38:35PM +0300, jesse jaara wrote: > I think i miss understoid you, if you wang the output og make to file you > can put >/file/path to end if iy ">" won't work since errors are printed to stderr (not stdout) in most cases. "2>" should do the trick. If there are some errors printed to stdout, you could use `make 2>&1 >foo`.
Re: [arch-general] How to do this
On Sun, Oct 24, 2010 at 04:33:10PM +0200, Christian wrote: > I know that I have to use piping for this, but I want to output the > errors I get while compiling a program into atext file. > What to type after make then? `make 2> foobar` will put them errors in a text file called "foobar".
Re: [arch-general] Question about installing libraries
On Fri, Oct 22, 2010 at 01:26:37AM +0200, Christian wrote: > Many thanks, will have a look. > But lets say I can't find a particular library and I only have a .deb file > with it, what to do then? You can write a PKGBUILD that automates the process of unpacking the ".deb" package and installing the libraries into "/usr/lib/". If you build and install a package (e.g. using `makepkg -i`) instead of copying them manually, all libraries will be tracked by pacman(8). If you never created a PKGBUILD before, you might wanna read something about it in the wiki ([1], [2]). If you want an example how to do create a package suitable for installation with pacman(8) from a dpkg, you can check [1] (even tho this PKGBUILD isn't the best I've ever seen). [1] http://wiki.archlinux.org/index.php/Creating_Packages [2] http://wiki.archlinux.org/index.php/Arch_Packaging_Standards [3] https://aur.archlinux.org/packages.php?ID=12819
Re: [arch-general] Odd message on boot
On Wed, Oct 20, 2010 at 01:26:26PM -0400, David Rosenstrauch wrote: > So, it's helpful to know that one of the message buses is the source > of the issue. Do you know if there's any way to narrow it down more > than that? i.e., find out which config file is causing this? It's caused by the avahi-daemon, check [1]. And if you're not sure which configuration file contains a reference to this group, you can always do something like `grep -R 'netdev' /etc/` to find out. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385495
Re: [arch-general] "$startdir/src", "$startdir/pkg" and "|| return 1" in official packages
On Fri, Sep 17, 2010 at 09:18:41AM -0500, Dan McGee wrote: > I wouldn't object to doing this to everything in trunk/, but we > shouldn't push those changes out to the repos/ unless the package > actually gets rebuilt. Those should reflect the current state of the > package as much as possible. I agree. And imho replacing deprecated "$startdir" and "|| return 1" statements are the kind of things people always tend to forget... Even when rebuilding packages. So I don't see any reason why this shouldn't be done automatically if it's that easy...
Re: [arch-general] "$startdir/src", "$startdir/pkg" and "|| return 1" in official packages
> Well, it would need to be done on SVN trunk and released to the repo
> branches... so it is not just a simple sed.
Mh, yeah. But that shouldn't be too difficult to script either (e.g.
using a for loop and running scp(1) and archrelease for every package).
> Anyway, whats the rush? They will change eventually. There should
> be no (or very few) $startdir/{src,pkg} in [core].
As I already said at the beginning:
> Although this isn't really significant... I was just curious :)
Just thought that might be an easy way to clean up and unify packages a
bit.
[arch-general] "$startdir/src", "$startdir/pkg" and "|| return 1" in official packages
Although this isn't really significant... I was just curious :)
`grep '${\?startdir}\?/src' /var/abs/*/*/PKGBUILD | wc -l` - "648"
`grep '${\?startdir}\?/pkg' /var/abs/*/*/PKGBUILD | wc -l` - "1385"
`fgrep '|| return 1' /var/abs/*/*/PKGBUILD | wc -l` - "9274"
Isn't that something that could be fixed easily using sed(1)/awk(1)?
E.g. using:
`find . -name 'PKGBUILD' -exec sed -i 's/$startdir\/src/$srcdir/g;
s/${startdir}\/src/${srcdir}/g; s/$startdir\/pkg/$pkgdir/g;
s/${startdir}\/pkg/${pkgdir}/g' {} ';'`
... to replace all that "$startdir/[...]" stuff?
Re: [arch-general] Kernel panic after installing avr tools
On Mon, Jun 28, 2010 at 07:58:36PM +0200, John Black wrote: > mhh is there a way to install package onto a non-bootable system > using pacman? Yes, just boot from a live CD, mount your root partition and either chroot into it or use the live CD's pacman(8) binary (and the "--root" argument) if the non-bootable system's pacman doesn't work. > I remember that binutils and glibc was updated, so if I could > reverse that I would not have to reload the OS. I'm not sure if downgrading binutils and glibc only will result in a running system but give it a try :>
Re: [arch-general] perl help missing DateTime::Format::ISO8601
On Mon, Jun 28, 2010 at 07:27:27PM +0300, Ionu?? Bîru wrote: > is this not the package that i need or the building is wrong? This is another package. I quickly built a perl-datetime-format-iso8601 package [1]. Didn't have any time to test it but I hope somehow it works anyway. [1] http://aur.archlinux.org/packages.php?ID=38529
Re: [arch-general] Do I need HAL?
On Mon, Jun 21, 2010 at 09:21:39PM +0200, "Jérôme M. Berger" wrote: > > After an upgrade, it will remain on your system if you do a pacman -Qdt > > > According to that rule, I don't need xorg-server !??? Some packages > are missing a dep here, I think... That's correct. Only few packages actually depend on xorg-server (blackbox, enter, grass, hacburn, lwm, nvidia-utils, perl-x11-protocol, windowlab and xkbsel). As a workaround you can either mark xorg-server as installed explicitly by uninstalling/reinstalling the package or by using `pacman -D --asexplicit` (the latter only works with pacman>=3.4.0) or create a meta package with xorg-server as dependency.
Re: [arch-general] Do I need HAL?
On Mon, Jun 21, 2010 at 06:46:13AM -0400, Matthew Monaco wrote: > >How can I know if I still need HAL? > [...] > After an upgrade, it will remain on your system if you do a pacman -Qdt ... which will, however, only work if hal hasn't been installed explicitly and will also disregard optdeps. If you're not sure whether to remove hal or net, it's best to check packages for hal optdeps and disable hal for a while (remove it from the "DAEMONS" line in your "/etc/rc.conf"). If everything still works as expected you can most likely remove it.
Re: [arch-general] Building packages and more
On Tue, May 25, 2010 at 09:06:34AM -0400, Keith Hinton wrote: > I wonder who the author of the UnrealIRCd package presently Is? `pacman -Si unrealircd | grep ^Packager` "Packager : Evangelos Foutras " > What do you folks think? > I'd like to see the Anope stable/Citadle packages someday included in Arch. There are PKGBUILDs for both Anope [1] and Citadel [2] in the AUR. You can download the necessary files from there and use makepkg(1) to build packages. You might also want to read the wiki article about the AUR [3]. Regards, Lukas [1] http://aur.archlinux.org/packages.php?ID=23353 [2] http://aur.archlinux.org/packages.php?ID=24865 [3] http://wiki.archlinux.org/index.php/Arch_User_Repository
Re: [arch-general] VirtualBox
On Wed, Apr 14, 2010 at 10:11:54AM -0400, Carlos Mennens wrote: > Just for VirtualBox I have installed: > > sudo pacman -S libxcursor > sudo pacman -S sdl > sudo pacman -S fontconfig > > And now it's still complaining about "libXi.so.6"...Is there no way > just to resolve everything or locate all required dependencies? How did you install X? All those packages get installed automatically if you install X via `pacman -S xorg` as described in the wiki [1]. [1] http://wiki.archlinux.org/index.php/Xorg#Installing
Re: [arch-general] VirtualBox
On Wed, Apr 14, 2010 at 09:44:58AM -0400, Carlos Mennens wrote:
> ##
> [code][r...@ghost ~]# /etc/rc.d/vboxdrv start
> -bash: /etc/rc.d/vboxdrv: No such file or directory[/code]
> ##
This PKGBUILD currently doesn't use any scripts in "/etc/rc.d/" - that
might be changed in future releases. In the meantime, you can (un)load
the module manually using modprobe(8) - just as Guilherme said.
> Now when I try to start VirtualBox I get the following error:
>
> ##
> [code][cmenn...@ghost virtualbox_bin]$ VirtualBox
> VirtualBox: supR3HardenedMainGetTrustedMain:
> dlopen("/opt/VirtualBox/VirtualBox.so",) failed: libSDL-1.2.so.0:
> cannot open shared object file: No such file or directory[/code]
> ##
You need to install sdl if you want to use the VirtualBox GUI, have a
look at the optional deps.
Re: [arch-general] Trying to get Brother HL2035 to work...
On Sun, Apr 11, 2010 at 12:32:10PM +0200, f...@kokkinizita.net wrote: > Apr 11 12:33:51 zita1 kernel: usb 3-1: usbfs: interface 0 claimed by usblp > while 'usb' sets config #1 > Apr 11 12:33:56 zita1 kernel: usb 3-1: usbfs: interface 0 claimed by usblp > while 'usb' sets config #1 > Apr 11 12:34:01 zita1 kernel: usb 3-1: usbfs: interface 0 claimed by usblp > while 'usb' sets config #1 > Apr 11 12:34:07 zita1 kernel: usb 3-1: usbfs: interface 0 claimed by usblp > while 'usb' sets config #1 > Apr 11 12:34:12 zita1 kernel: usb 3-1: usbfs: interface 0 claimed by usblp > while 'usb' sets config #1 Did you blacklist the "usblp" module as described in the wiki [1]? Do you use a custom kernel? [1] http://wiki.archlinux.org/index.php/CUPS#Blacklisting_usblp
