- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] ruby 1.9.1 enters [testing] - breaks gvim
by Emmanuel Benisty 09 Jun '09

09 Jun '09

On Sun, Jun 7, 2009 at 11:47 AM, Allan McRae<allan(a)archlinux.org> wrote: > Hi all, > > I have built ruby-1.9.1 for [testing]. As far as I can tell, the only > thing that is broken is gvim. A dev who uses that will want to look into > fixing it... I hear there is a patch floating around for ruby-1.9 support > but not sure if it is now included upstream. You can always use IgnorePkg > until it is fixed. > > (Lets see if gvim users complain more than the ruby users have...) FTR, it breaks vim too here. vim: error while loading shared libraries: libruby.so.1.8: cannot open shared object file: No such file or directory

3 3

[arch-general] Light-weight SMTP "server"
by Magnus Therning 08 Jun '09

08 Jun '09

Any good suggestions for a light-weight SMTP server? All email goes off-box to my ISP for remote delivery, I don't require any local delivery. Things like exim/sendmail/postfix feels like overkill. It would even be enough if all that's available is something like an /usr/lib/sendmail executable. Is there something suitable and light-weight? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

6 14

[arch-general] ArchWiki TOC translated to pt_BR
by Lucas Salies Brum 08 Jun '09

08 Jun '09

I translate this page, but I'm beginner, I would like to review. http://wiki.archlinux.org/index.php/Table_of_Contents_(Portugu%C3%AAs_do_Br… Thank you.

1 0

Re: [arch-general] [arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3
by Gerardo Exequiel Pozzi 08 Jun '09

08 Jun '09

Thomas Bächler wrote: > Going into testing in a few minutes: > > mkinitcpio changes: > - Finally fix a bug where required HID modules were missing > - Add a new COMPRESSION option that accepts gzip, lzma and bzip2 > parameters (gzip is the default, the others are only supported on > 2.6.30 and later) > - Add a new poll_device function that waits for a block device to > appear. This is used in the init function and the resume hook, with > rootdelay as a maximum timeout (default to 10 seconds) > - Remove the unmaintained and untested modload hook > - Remove the runtime filesystems hook > - Rework the code that checks whether a root device has been found, > don't reboot when exiting the emergency shell, but try to continue. > - Due to the new poll_device behaviour, the usb and fw runtime hooks > are no longer required, remove them > - Parse arguments to init properly, using the "$@" parameter from the > commandline the kernel generated - also needs the new fix in the > latest kinit from testing (this allows us to use init=/bin/sh again) > - Adjust for the latest filesystem/module-init-tools changes > - Fix an autodetection bug that would sometimes omit some filesystems > Many thanks. The tests was done on VirtualBox (both i686 and x86_64 architectures), because in my real machine use a custom kernel without initramfs. * Images generations are OK. * Boot OK normal and fallback images (default config). * Also boot fine with the "init=/bin/bash" argument and "init=/sbin/init" > cryptsetup changes: > - Use poll_device when waiting for the encrypted device and the > (optional) key container device (default to rootdelay), added > conflicts=(mkinitcpio<0.5.25) > - Add a warning if the deprecated root= syntax is used on the commandline > Not tested it. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

[arch-general] File conflicts upgrading licenses
by Zé Ninguém 07 Jun '09

07 Jun '09

Hi there. I am having some file conflicts when upgrading the licenses package, and I don't understand why? Here is the error: resolving dependencies... looking for inter-conflicts... Targets (1): licenses-2.5-1 Total Download Size: 0.00 MB Total Installed Size: 0.46 MB Proceed with installation? [Y/n] checking package integrity... (1/1) checking for file conflicts [####################################################################################################] 100% error: could not prepare transaction error: failed to commit transaction (conflicting files) licenses: /usr/share/licenses/common/FDL exists in filesystem licenses: /usr/share/licenses/common/GPL exists in filesystem licenses: /usr/share/licenses/common/GPL2/license.txt exists in filesystem licenses: /usr/share/licenses/common/LGPL exists in filesystem Errors occurred, no packages were upgraded. But the files it is complaining about belong to "licenses" already. /usr/share/licenses/common/GPL2/license.txt is owned by licenses 2.4-1 So my question is, why are this errors hapening? Regards.

2 1

Re: [arch-general] [arch-dev-public] [signoff] xz-utils and libarchive-2.7.0-2
by Grigorios Bouzakis 07 Jun '09

07 Jun '09

On Sun, Jun 7, 2009 at 4:57 PM, Allan McRae<allan(a)archlinux.org> wrote: > Roman Kyrylych wrote: >> >> On Sun, May 31, 2009 at 16:41, Dan McGee<dpmcgee(a)gmail.com> wrote: >> >>> >>> On Sun, May 31, 2009 at 7:30 AM, Pierre Schmitz <pierre(a)archlinux.de> >>> wrote: >>> >>>> >>>> Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz: >>>> >>>>> >>>>> If everything is OK we can move both to core and remove lzma-utils from >>>>> extra. >>>>> >>>> >>>> tpowa just asked me but I am not sure about it: Should cz-utils be part >>>> of the >>>> base group? It'll be installed anyway because libarchive depends on it. >>>> O the >>>> other hand we might want to have a base group which does not depend on >>>> anything which is not a group member. >>>> >>> >>> Yes, it should. When I originally asked about adding lzma support, we >>> brought up the fact that it would have to be in the base group. >>> >> >> Hm, I don't really see a reason for this, can you explain the reason for >> me? >> Here's my logic: >> a group should not be required to have all dependencies in a group, >> reason: when installing a group pacman installs all packages as >> 'explicitly installed' >> which makes it harder to find no-more-needed dependency in future. >> Please correct me if I'm wrong about this, since I could forgot something >> about >> pacman while being inactive for so long time. >> > > I agree. It would also make the list of "base" and "base-devel" packages to > select from in the installer much smaller. > This reminds me of my comment http://bugs.archlinux.org/task/12890#comment43722 with pacman. I dont know if this would make things more complex (from a packager point of view for the most part ) but it will certainly make the list smaller. Please, if any developers feel like moving towards this, take part in the discussion, or even start moving towards this. I dont know if have discussed any of these in the private list, etc. -- Greg

1 0

[arch-general] PKBUILD update after bug fix
by Baho Utot 06 Jun '09

06 Jun '09

How long does it take for the updated PKGBUILD to hit abs after a bug report is closed For example if the PKGBUILD is missing a dependency? Thanks

2 2

Re: [arch-general] [arch-dev-public] subversion rebuild needed for i686
by Gerardo Exequiel Pozzi 04 Jun '09

04 Jun '09

Douglas Soares de Andrade wrote: > Em Domingo 31 Maio 2009, às 09:37:27, Firmicus escreveu: > >>> Succeeded now. >>> (Thanks in good part to Gerardo who made me realize that the javac >>> binary was unable to find libjli.so, even though it was where it should >>> be. Symlinking to /usr/lib solved the problem. So this was some LIBPATH >>> problem in my supposedly pristine chroot.) >>> >> Dammit!!! My new package happens to have the same GD problem Douglas >> originally had: see FS#14738 >> >> Folks, I am no longer sure to understand the subtleties of "building in >> a clean chroot" ... >> >> Now that I know that this package belongs to Douglas, I'll happily let >> him deal with it ;D >> >> On the other hand, I'd be grateful to be a bit more enlightened about >> all this. Has anyone experienced any similar issues whilst building >> packages in a chroot? >> > > Me too, till then i will build packages in my working enviroment, i really did > not understood why the package buillt in the chroot had problems, any ideas ? > > Thanks > > > The FIX is currently in the bugtracker, patch agains the svn trunk. The explication is in the comments. (My fault) http://bugs.archlinux.org/task/14738#comment44808 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0

[arch-general] PKGBUILD: depends and ranges of versions?
by Magnus Therning 04 Jun '09

04 Jun '09

I couldn't find anything definitive on this. Say I have a package A that depends on package B, but A can only be built against version 2.x of B (i.e. not against 1.x and not 3.x). Is it allowed to do something like depends=('B>=2' 'B<3') /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 1

[arch-general] gstreamer naming
by Lukáš Jirkovský 04 Jun '09

04 Jun '09

Hello, I've a question - why are gstreamer packages named gstreamer0.10 and not gstreamer? I can see it also in Debian, but I don't see any sense in appending version to the package name. Lukas "stativ"

2 2