Re: [arch-general] Is there a burning tool able to replace K3b?
On Tuesday 21 January 2014 12:28:35 Joerg Schilling wrote: cdrtools - last release: yesterday ;-) Speaking of cdrtools, do you have some git or svn or something similar repository of cdrtools so people can monitor development or do you simply do release tarballs every so often? signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] licensing issues with DB 6.0
On Friday 09 August 2013 11:31:22 Pierre Schmitz wrote: Hi all, we just finished the db 6.0 rebuild in staging. I was pointed* to an issue with it's license though. It seems Oracle switched the license to AGPL with version 6.0. I am not an expert, but afaik this makes it only compatible with GPL3 clients and also enforces the AGPL terms on those. Debian had a similar discussion https://lists.debian.org/debian-legal/2013/07/msg0.html If you think this is indeed a problem, I suggest to drop the rebuild for now and keep db-5. We could introduce a db6 package if packages really need that and are license-compatible. We might also want to try to disable db-functionality if possible and switch to alternative implementations. Greetings, Pierre *) https://bugs.php.net/bug.php?id=65426 Out of the applications I have installed that use db 5.3, bogofilter can be linked against sqlite3 instead if it is configured with --with-database=sqlite3
Re: [arch-general] [arch-dev-public] Adding !staticlibs to our default makepkg.conf
On Wednesday 29 May 2013 11:31:11 Allan McRae wrote: We discussed removing static libraries for most packages back in March [1]. Now makepkg for pacman-4.1 has an option staticlibs that automatically removes them. Should I make that the default in our makepkg.conf? Allan [1] https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024552.ht ml Why not check first which applications build with --disable-static? A few packages like libpng, etc.. can be compiled with --disable-static which feels like a more neat approach then deleting the static libraries.
Re: [arch-general] Sound broken, using pulse audio
On Friday 17 May 2013 06:04:01 Carlos Alegria Galicia wrote: Hi all, After the last kernel upgrade, my sound is not working after weaking up from hibernate. The device PulseAudio is shown in alsamixer, PulseAudio is up and running, the channels are shown in pavucontrol and even the level sound bar is showing the audio levels, but there is no sound. Everything works after shutting down - starting up again my system (not even using restart). I am using systemd to hibernate / restart my laptop. Thanks in advance, A quick google search suggests you are fix that by restarting the pulse audio daemon. Try this in a terminal window: pulseaudio -k pulseaudio -D
Re: [arch-general] about the removal of that systemd symlink...
On Sunday 12 May 2013 22:32:03 David Benfell wrote: Hi all, I was alarmed, I think unnecessarily, when I saw the message that a symlink for systemd was removed on an upgrade. As near as I can tell, the boot sequence still relies on init, which links to the right place. Is there a better way to keep track of changes like this so I'm not surprised? Thanks! -- David Benfell / benf...@parts-unknown.org Please see https://parts-unknown.org/node/2 for GnuPG information (or the attachment you don't understand) There was a post installation message.
Re: [arch-general] libxml2 out of date
On Tuesday 23 April 2013 09:05:33 Ross Lagerwall wrote: Hi, Is there a reason (other than lack of time) that libxml2 has not been updated from 2.8 to 2.9 (now 2.9.1)? Regards As far as I can tell, it breaks a lot of applications.
Re: [arch-general] Gnome - blank dialog when resuming from suspend
On Sat, 2010-05-22 at 00:03 -0400, Matthew Monaco wrote: I'm having trouble finding a bug report on this but I've experienced it on 4 different computers. When I suspend (pm-utils) though System - Shut Down - Suspend (button), the shut down dialog is still on the screen and blank, when I resume. Anyone know exactly what's responsible for this? gnome-screensaver, pm-utils, gdm, ...? And if it's upstream or a distribution thing? (I think upstream). Thanks That's the shutdown / suspend dialog that gets stuck for a bit. So maybe a gnome-session problem gnome-session-save --shutdown-dialog
Re: [arch-general] [arch-commits] Commit in (libgcrypt/trunk/PKGBUILD libgpg-error/trunk/PKGBUILD)
# keep static lib for crypsetup ./configure --prefix=/usr There's no need to keep static lib now that cryptsetup is only dynamically linked.
Re: [arch-general] kernel 2.6.33.3 freezes on boot
On Wed, 2010-04-28 at 09:43 +0200, didier gaumet wrote: Hi list, Since todays's update of the kernel (2.6.33.2 - 2.6.33.3) my Dell inspiron 1012-9118 (new mini 10) netbook freezes on boot (after displaying loading modules. I have to poweroff. It is an Atom N450 proc and an x86_64 Archlinux (up-to-date). Has anyone a similar problem? Happened on first boot after upgrade here. but it hasn't happened since. I rebooted 5 times to check
Re: [arch-general] gstreamer0.10-good-plugins need a whole load of GNOME stuff?
On Tue, 2010-04-20 at 15:34 +0100, Ananda Samaddar wrote: Is there some reason that the gstreamer good plugins set needs a whole load of GNOME crap? http://www.archlinux.org/packages/extra/x86_64/gstreamer0.10-good-plugins/ I've recently switched to XFCE and I'd like to avoid GNOME dependencies. Is it possible to recompile from abs without all these dependencies? thanks, Ananda Won't xfce be switching to GNOME crap like gvfs? :P
Re: [arch-general] gstreamer0.10-good-plugins need a whole load of GNOME stuff?
On Wed, 2010-04-21 at 19:28 +1000, Allan McRae wrote: On 21/04/10 19:25, Ananda Samaddar wrote: On Wed, 21 Apr 2010 12:14:56 +0300 Hussam Al-Tayebht990...@gmail.com wrote: Won't xfce be switching to GNOME crap like gvfs? :P That's only an optional dependency for Thunar if I remember correctly. I'm still trying to find out about that as I don't want to end up with a whole bunch of GNOME libs to run XFCE. If that's the case I might as well go back to GNOME. My main beef with GNOME though is the Shell. Going off topic... but if you do not want GNOME shell, then do not install it. It sounds like the old GNOME panel will still be available as an alternative. Allan gnome-panel no longer uses libgnome(ui) in gnome 2.30 Another good news there is a branch in git that replaces libbonobo(ui) with dbus. I see your point now. gnome-shell isn't usable so you're looking into XFCE. But rest assure gnome-panel/metacity are going nowhere. And it's only going to get better and faster when libbonobo(ui) is out of the window. Gconf is going to be replaced with dconf but not for gnome 3.0
Re: [arch-general] Bad attitude in flyspray again!
On Thu, 2010-03-11 at 14:59 -0600, Aaron Griffin wrote: On Thu, Mar 11, 2010 at 2:19 PM, Dimitrios Apostolou ji...@gmx.net wrote: My primary complaint against flyspray is that it doesn't allow comments to be added after the bug is closed. The only way is by doing a request to reopen the bug, and even in that case your comment is not added to the comment list. Wouldn't this functionality remedy the closing bugs early situation? Is it supported in flyspray? Commenting on bugs after they are closed will just annoy the developer. If you have an issue with the fix or something, reopening is the right action. If you have information to add, then add it to the wiki, as THAT is the source of documentation, not flyspray You should consider moving to bugzilla. mozilla and gnome use it. it's an excellent bug tracker. I've used it to report literally hundreds or gnome or mozilla bugs. not only is it easier on developers but it is also better for users. flyspray is not as smart as bugzilla. this won't work of course if there is no converter.
Re: [arch-general] Problems with Xorg
On Mon, 2010-02-15 at 16:57 +0100, Aaron Griffin wrote: Am Montag, 15. Februar 2010 16:53:14 schrieb Aaron Griffin: WTF is this shit? You should go see a doctor; or use psf, dkim etc. ;-) PS: No, that wasn't me. As much as I hate spam, this is way too funny. Somewhere some drunk spammer has too much free time on his hand :(
Re: [arch-general] resume from suspend no longer works after new mkinitcpio 0.6
On Fri, 2010-02-12 at 09:28 +0100, Thomas Bächler wrote: Am 12.02.2010 08:52, schrieb Hussam Al-Tayeb: At boot, it no longer does the check for the resume image or data and directly boots from new. That is because you didn't configure the resume hook into your initramfs image. Thanks. It didn't cross my mind because it always worked without it. Is there a specific order for the hooks or will HOOKS=base udev autodetect pata scsi sata encrypt filesystems resume work? I'll try that now.
[arch-general] new mkinitcpio / harmless error message at boot
After doing a pacman -Syu and installed the mkinitcpio 0.6 , I'm getting an error insmoding padlock-sha just after I enter the root device luks encryption passphrase. I'm assuming there is an easy solution to this. Any idea?
[arch-general] encrypt hook
Why does /lib/initcpio/hooks/encrypt say /sbin/cryptsetup but the actual installed file is /sbin/cryptsetup.static?
Re: [arch-general] encrypt hook
On Fri, 2010-02-12 at 01:17 +0100, Adrian C. wrote: On Thu, 11 Feb 2010, Hussam Al-Tayeb wrote: Why does /lib/initcpio/hooks/encrypt say /sbin/cryptsetup but the actual installed file is /sbin/cryptsetup.static? But you did not read /lib/initcpio/install/encrypt which explains it. ok, thanks. it seems to be using the dynamically linked crytpsetup now
[arch-general] resume from suspend no longer works after new mkinitcpio 0.6
At boot, it no longer does the check for the resume image or data and directly boots from new.
Re: [arch-general] core/linux-api-headers?
On Sun, 2010-01-31 at 15:22 -0600, Daniel Griffiths wrote: On 01/31/2010 03:05 PM, richard terry wrote: Hi List, Just went to do a system upgrade and noticed this and unsure what it means or if I should so Yes: :: Replace kernel-headers with core/linux-api-headers? [Y/n] n Any comments? Thanks in anticipation. Richard This has been discussed several times. A quick search of the forums should give you an idea. Or simply tell him the the package kernel-headers was renamed to linux-api-headers?
[arch-general] udev and/or device-mapper problem
I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway. After fsck fails, it dropped me to a shell. I downgraded udev and device-mapper, recreated the kernel image and I can boot now. Any ideas?
Re: [arch-general] udev and/or device-mapper problem
On Thu, 2010-01-28 at 18:25 +0100, Thomas Bächler wrote: Am 28.01.2010 18:00, schrieb Hussam Al-Tayeb: I updated to udev, cryptsetup and device mapper from testing the installed kernel 2.6.32.6 and rebooted. now /dev/mapper/root and /dev/dm-0 are not there but /etc/mtab mentions /dev/mapper/root /dev/mapper/home and /dev/dm-1 exist The computer boots till the fsck part then stops because there is no /dev/mapper/root to fsck. I'm trying not to touch any libpng/libjpeg stuff in testing but non of those messes up booting anyway. You need the latest initscripts too, otherwise it will definitely fail. Thank you. updating initscripts fixed it. :) signature.asc Description: This is a digitally signed message part
Re: [arch-general] [signoff] kernel 2.6.32.4-1
On Tue, 2010-01-19 at 07:42 +0100, Tobias Powalowski wrote: Hi guys, bump to latest bugfix version. Please signoff both arches, greetings tpowa Everything working perfectly as usual. 32bit kernel with nvidia kernel module. signature.asc Description: This is a digitally signed message part
Re: [arch-general] Inkscape maintainer MIA?
On Mon, 2009-12-14 at 12:01 +0200, Marti Raudsepp wrote: Hi arch-general, I'd like to point your attention to the Inkscape package: Inkscape version 0.47 was released on November 25. This is a very significant release that many Inkscape users have been waiting patiently. However, the Arch Linux Inkscape maintainer, Tobias Kieslich, seems to be missing in action. Looking at his FlySpray activity, his last comment seems to be dated November 18. Can anyone please look into resolving this? Regards, Marti 0.47 fails to build with a poppler error :/
[arch-general] suggestion for pacman: Recommended packages.
The current case for many packages that use optdepends is as follows. Let's say a package called package1 installs some extra binaries or plugins. Those extra not so used binaries or plugins have extra dependencies (let's call them libsomething) marked as optdepends. so on installation pacman will say something: optional dependency: libsomething needed for package1 plugins to work. How about instead those extra binary files or plugins are split into another package called package1-plugins and have libsomething as plain dependency? Then on package1 installation, pacman should say something like: Recommended packages: package1-plugins for blah blah functionality. A good example is the pacman package itself which has an optional dependency on python for rankmirrors script. Maybe we could split it into a separate pacman-rankmirrors which depends on python the when a user installs/upgrades pacman package, he/she is prompted for recommended package pacman-rankmirrors for blah blah functionality. pacman-rankmirrors would depend on python. I think this is a better and cleaner approach. Obviously not every package can use that approach but it will clean some optdepends and remove some ldd errors because of uninstalled optdepends. Another thing, anyway to make pacman -Rns somepackage also remove optional dependencies that no other package uses?
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 22:29 +1100, James Rayner wrote: On Fri, 11 Dec 2009 10:40 +0200, Hussam Al-Tayeb ht990...@gmail.com wrote: The current case for many packages that use optdepends is as follows. Let's say a package called package1 installs some extra binaries or plugins. Those extra not so used binaries or plugins have extra dependencies (let's call them libsomething) marked as optdepends. so on installation pacman will say something: optional dependency: libsomething needed for package1 plugins to work. How about instead those extra binary files or plugins are split into another package called package1-plugins and have libsomething as plain dependency? Then on package1 installation, pacman should say something like: Recommended packages: package1-plugins for blah blah functionality. This is known as 'debian'. I think it's overkill and offers no practical benefit. There is a benefit. You quoted part of my email. Did you read the rest? It also better then downsteam deciding which goes to depends and which goes to optdepends
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: Hussam Al-Tayeb wrote: The current case for many packages that use optdepends is as follows. snip I think some of this would be solved if/when we implement this: http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends Thanks Allan. this is a good solution especially optdepends can be removed with -Rs and optdepends are not orphans unless a flag is specified. Thank you :)
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 2009-12-11 at 16:02 +0100, Xavier wrote: On Fri, Dec 11, 2009 at 1:54 PM, Hussam Al-Tayeb ht990...@gmail.com wrote: On Fri, 2009-12-11 at 22:45 +1000, Allan McRae wrote: Hussam Al-Tayeb wrote: The current case for many packages that use optdepends is as follows. snip I think some of this would be solved if/when we implement this: http://wiki.archlinux.org/index.php/User:Allan/Pacman_OptDepends Thanks Allan. this is a good solution especially optdepends can be removed with -Rs and optdepends are not orphans unless a flag is specified. Thank you :) Your proposal is not stupid, it would indeed make the optdepends problems obsolete by getting rid of most of the optdepends, and provide cleaner packages and dependencies. Nagy had the same thought in a private discussion we had a while ago. Of course then there is also an increased complexity of packaging with a lot of splitting and a much bigger number of packages. And with that example of pacman and rankmirrors, rankmirrors is a 190 lines python script. I don't think it deserved a package on its own. Anyway for that specific example, some people were not happy about the python dependency and rewrote rankmirrors in bash. pacman package may have been a bad example but you get the general idea.
Re: [arch-general] [arch-dev-public] kernel 2.6.32-1
On Sat, 2009-12-05 at 09:31 +0100, Pierre Schmitz wrote: Am Samstag 05 Dezember 2009 09:00:38 schrieb Tobias Powalowski: - splitted kernel-headers to extra package If you want to build external modules please install: pacman -S kernel26-headers Please change your PKGBUILDS to makedepend on this package. Was this done to reduce the kernel package size? It's a little confusing to have kernel26-headers and kernel-headers. Isn't it against Arch philosophy to split packages it binary and header packages?
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
solsTiCe d'Hiver schrieb: i am beginning to think there really is a problem. i have a luks encrypted partition that i automatically mount at boot via /etc/crypttab with a *keyfile* so this has never failed and it can't fail except if the keyfile is damaged. and today the luks partition failed to be opened for the *first* time *ever* by cryptsetup because of a password problem. once i rebooted it worked. so the keyfile is not wrong. and i double check it with my backup keyfile this looks like your problem Hussam. it sometimes fails sometimes works. When did any of you guys upgrade to cryptsetup 1.0.7? Can you grep this from pacman.log please? [2009-07-25 20:43] upgraded cryptsetup (1.0.6-3 - 1.0.7-1)
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Tue, 2009-10-13 at 20:10 +0200, Thomas Bächler wrote: solsTiCe d'Hiver schrieb: it has been sometime ago # grep cryptsetup /var/log/pacman.log [2008-07-16 11:03] upgraded cryptsetup (1.0.6-1 - 1.0.6-1) [2008-10-08 14:29] upgraded cryptsetup (1.0.6-1 - 1.0.6-2) [2009-06-19 21:52] upgraded cryptsetup (1.0.6-2 - 1.0.6-3) [2009-08-10 14:52] upgraded cryptsetup (1.0.6-3 - 1.0.7-1) So that's not it. 1.0.7 should be working better anyway. Sadly, a viable debug option has only been introduced in 1.1.0rc1 afaik, 1.0.7 doesn't have anything that will help here. We need to find out where exactly it fails. Maybe I could write an email to Milan Broz about this, because I am out of ideas. I compiled 1.1.0rc2 then copied cryptsetup libcryptsetup.so libcryptsetup.so.1 libcryptsetup.so.1.0.0 to /tmp/testfolder then cd /tmp/testfolder then LD_LIBRARY_PATH=./ ./cryptsetup --debug luksOpen /dev/sdb1 home and it unlocks it correctly everytime!
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Tue, 2009-10-13 at 23:27 +0200, Xavier wrote: On Tue, Oct 13, 2009 at 11:04 PM, Hussam Al-Tayeb ht990...@gmail.com wrote: Nice. I suggest you upgrade to 1.1.0rc2 then (changes to the PKGBUILD should be trivial). I hope it won't break anything for you further. If the problem stays away with 1.1.0, that is solution enough for me. If it returns, we need to really find out what's wrong. Done! I updated to 1.1.0-rc2 then I also upgraded to kernel 2.6.31.4 After rebooting, things are still fine. /dev/sdb1 unlocked correctly :) Could you check the upstream issues to find if one matches your case ? http://code.google.com/p/cryptsetup/issues/list?can=1q=colspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles It seems there are a few issues related to udev and some locking or racing conditions : http://code.google.com/p/cryptsetup/issues/list?can=1q=udevcolspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles I looked at all your mails, and it seems you never showed exactly what the output of cryptsetup was when it failed. It's good to know it's fixed in 1.1.0-rc2 but it would be better to know why. It just didn't accept the passphrase as if I entered it correctly.
[arch-general] can't unlock a luks encrypted partition. (urgent).
Hi, I'm having a problem with disk encryption using luks. I have my /home disk (on a separate disk 'sdb') encrypted using luks. I have this in /etc/cryptsetup home/dev/sdb1 ASK and this in /etc/fstab /dev/mapper/home /home ext4 defaults,user_xattr 0 1 Suddenly today, it won't accept the passphrase on boot. I'm sure that I'm entering it correctly. It took me 32 tries the first time and many more the second reboot after kernel 2.6.31.3 update. The annoying thing is that archlinux only takes three tries then fails and I have to reboot to try again. Any idea please? I'm 100% sure I'm entering the passphrase correctly. I don't have another operating system installed or anything and I go back to work in a few days so looking for a new distribution or operating system is not a favorable option. I really need help please :/ [r...@lars hussam]# cryptsetup status /dev/mapper/home /dev/mapper//dev/mapper/home is active: cipher: aes-cbc-essiv:sha256 keysize: 128 bits device: /dev/sdb1 offset: 1032 sectors size:156295290 sectors mode:read/write
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Fri, 2009-10-09 at 13:21 -0400, David Rosenstrauch wrote: On 10/09/2009 01:06 PM, Hussam Al-Tayeb wrote: Hi, I'm having a problem with disk encryption using luks. I have my /home disk (on a separate disk 'sdb') encrypted using luks. Could your disk be failing? If so, then maybe try dumping the partition to another disk and see if that helps. HTH, DR I don't think so. I tried unlocking it using an old opensuse live cd and it worked every time.
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Fri, 2009-10-09 at 19:48 +0200, Thomas Bächler wrote: Hussam Al-Tayeb schrieb: Hi, I'm having a problem with disk encryption using luks. I have my /home disk (on a separate disk 'sdb') encrypted using luks. I have this in /etc/cryptsetup home/dev/sdb1 ASK and this in /etc/fstab /dev/mapper/home /home ext4 defaults,user_xattr 0 1 Suddenly today, it won't accept the passphrase on boot. I'm sure that I'm entering it correctly. It took me 32 tries the first time and many more the second reboot after kernel 2.6.31.3 update. I don't really know what's happening right now. However, you should comment out that crypttab line, mark /home as noauto in fstab, boot your system and try unlocking there manually. That way, it will be much easier to investigate the problem. Ok, I did that. and manually run 'cryptsetup luksOpen /dev/sdb1 home' It literally took over 97 tries before it worked. How do I investigate what's happening? cryptsetup -v doesn't give extra output?
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Sat, 2009-10-10 at 00:56 +0200, Heiko Baums wrote: Am Sat, 10 Oct 2009 00:08:00 +0200 schrieb Thomas Bächler tho...@archlinux.org: It is very unlikely to be kernel related. And 2.6.31 has been in testing far too long, it should really be moved. I just installed kernel26 2.6.31.3 from testing and can't reproduce this issue. I have encrypted my whole system except of the /boot partition of course. I can unlock every partition by reading the keys from USB stick and by entering the passphrases. So I also don't think that this is kernel related. Heiko my root partition passphrase (arch asks for at initramfs stage) always works and it accepts it correctly. This issue happens when you try to unlock a partition later on. This means that if you don't have an encrypted /home on a different partition, you won't see this problem.
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Sat, 2009-10-10 at 01:14 +0200, Heiko Baums wrote: Am Fri, 9 Oct 2009 22:00:15 +0200 schrieb Xavier shinin...@gmail.com: After a quick google (less than 1 minute), it seems that some ubuntu users are affected too : https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/433051 I have an idea. I'm not really sure, if this can be the reason, and I haven't tested it yet. But can this probably be an issue with the keymap? Hussam, do you have keymap in the HOOKS in /etc/mkinitcpio.conf? Maybe you could try to remove it and enter the passphrase with the standard us keymap. You should of course write down the correct keys you have to press, if you don't use a US keyboard. Heiko Nope, I don't have keymap in HOOKS. HOOKS=base udev autodetect pata scsi sata encrypt filesystems
Re: [arch-general] can't unlock a luks encrypted partition. (urgent).
On Sat, 2009-10-10 at 01:45 +0200, Heiko Baums wrote: Am Sat, 10 Oct 2009 02:15:35 +0300 schrieb Hussam Al-Tayeb ht990...@gmail.com: my root partition passphrase (arch asks for at initramfs stage) always works and it accepts it correctly. This issue happens when you try to unlock a partition later on. This means that if you don't have an encrypted /home on a different partition, you won't see this problem. Just another thought. I know that this is also pretty improbable. I don't know the filesystem of your / partition. Can this be an issue with ext4 in kernel 2.6.31 and LUKS? Have you checked your harddisk with smartctl, badblocks or something similar? Maybe it is indeed dying. Of course it's also improbable if this issue appeared only after upgrading from kernel 2.6.30 to 2.6.31 but maybe worth a try. Otherwise I don't have any other ideas. Heiko I did a fsck and badblocks. nothing wrong there. I don't think it is failing because cryptsetup on an old opensuse live cd successfully unlocks /dev/sdb1 eventhough it doesn't support ext4. I'm reading manpage for smarctl and will run a test and post results.
Re: [arch-general] libsoup 2.26.0-1 dependencies in [testing]
On Thu, 2009-04-23 at 20:33 +0200, JM wrote: On Thu, Apr 23, 2009 at 5:20 PM, Jan de Groot j...@jgc.homeip.net wrote: On Thu, 2009-04-23 at 17:17 +0200, JM wrote: On Mon, Mar 30, 2009 at 11:29 PM, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2009-03-30 at 22:48 +0200, JM wrote: Hello, I noticed that libsoup in [testing] depends on gconf, is that really necessary? Libsoup is a dependency for some desktop-agnostic applications such as Midori (through its dependency on libwebkit) or hardinfo (currently in AUR). Regards, JM This is a temporary bugfix. At this moment the libproxy code in libsoup is unstable, so the libsoup developers decided to disable libproxy and use gconf instead for proxy detection. The changelog states that it's a temporary solution that will be worked out for 2.26.0. With 2.26.1, the dependencies will be the same as we had with the 2.25.x release which was in testing for a while. libsoup 2.26.1-1 still carries the dependency on gconf. Has the situation changed? Regards, JM No it hasn't, as this needs to be fixed inside libproxy. Libproxy is not threadsafe when it calls into gconf, so libsoup calls into GConf itself to get the proxy information and passes the information to libproxy. Until libproxy is fixed to do threadsafe calls into GConf, the dependency on GConf will stay. I mistakenly assumed that the problem had lied within libsoup not libproxy. Thanks for clarifying that. Regards, JM gconf only depends on orbit2=2.14.17 gtk2=2.16.0 libxml2=2.7.3 policykit=0.9 libldap=2.3.43 It has no dependencies on ugly gnome libs (libgnome, libbonobo) so non gnome users shouldn't have problem with it.
Re: [arch-general] libsoup 2.26.0-1 dependencies in [testing]
On Sat, 2009-04-25 at 02:28 +0200, hollun...@gmx.at wrote: On Fri, 24 Apr 2009 23:01:24 +0300 Hussam Al-Tayeb ht990...@gmail.com wrote: On Thu, 2009-04-23 at 20:33 +0200, JM wrote: On Thu, Apr 23, 2009 at 5:20 PM, Jan de Groot j...@jgc.homeip.net wrote: On Thu, 2009-04-23 at 17:17 +0200, JM wrote: On Mon, Mar 30, 2009 at 11:29 PM, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2009-03-30 at 22:48 +0200, JM wrote: Hello, I noticed that libsoup in [testing] depends on gconf, is that really necessary? Libsoup is a dependency for some desktop-agnostic applications such as Midori (through its dependency on libwebkit) or hardinfo (currently in AUR). Regards, JM This is a temporary bugfix. At this moment the libproxy code in libsoup is unstable, so the libsoup developers decided to disable libproxy and use gconf instead for proxy detection. The changelog states that it's a temporary solution that will be worked out for 2.26.0. With 2.26.1, the dependencies will be the same as we had with the 2.25.x release which was in testing for a while. libsoup 2.26.1-1 still carries the dependency on gconf. Has the situation changed? Regards, JM No it hasn't, as this needs to be fixed inside libproxy. Libproxy is not threadsafe when it calls into gconf, so libsoup calls into GConf itself to get the proxy information and passes the information to libproxy. Until libproxy is fixed to do threadsafe calls into GConf, the dependency on GConf will stay. I mistakenly assumed that the problem had lied within libsoup not libproxy. Thanks for clarifying that. Regards, JM gconf only depends on orbit2=2.14.17 gtk2=2.16.0 libxml2=2.7.3 policykit=0.9 libldap=2.3.43 It has no dependencies on ugly gnome libs (libgnome, libbonobo) so non gnome users shouldn't have problem with it. But isn't gconf a daemon? There's an app in development I might want to use that uses vala and gconf, and I don't know how bad that gconf daemon is.. regards, Philipp It's perfectly safe and very well designed. It's job is to notify applications when their settings have been changed. For example, if you edit the configuration of gedit externally (not from inside gedit options dialog) but from gconf-editor for example, gconf daemon tells gedit that the settings have been changed without the need to restart gedit.
Re: [arch-general] [arch-dev-public] [signoff] rp-pppoe 3.10-1
On Thu, 2008-07-24 at 10:31 -0500, Aaron Griffin wrote: On Thu, Jul 24, 2008 at 8:50 AM, Daniel Isenmann [EMAIL PROTECTED] wrote: On Thu, 24 Jul 2008 14:27:51 +0200 Thomas Bächler [EMAIL PROTECTED] wrote: Aaron Griffin schrieb: On Tue, Jul 15, 2008 at 12:34 PM, Daniel Isenmann [EMAIL PROTECTED] wrote: Hi, above package is in testing for both archs. Please signoff. I can't test the package because I don't use it, I have a router and not connected directly on the line. If no one uses this, you can take my awesome blame me if crap be broken signoff I wonder why this is in core anyway. PPPoE connections can be established with the pppd package alone. The only advantages this package has are: 1) A fancy configuration script. With pppd only, you'd have to read http://wiki.archlinux.org/index.php/PPPoE_Setup_with_pppd and set it up. We could include some example configuration like this in the pppd package though. 2) A PPPoE server. We don't need that in core. With pppd, the PPPoE protocol is handled in the kernel (while rp-pppoe does it in userspace), so pppd probably has less overhead anyway. I vote for db-move rp-pppoe core extra. I can't give any comments on that. I really don't use it and have never used it. I trust your statement. Any complains about moving to extra? If no, you can move it. Maybe we should ask the users who actually use it - see if there is any rational reason they *depend* on it as opposed to pppd Hi, Please keep this package in core. It's very easy to use and helps a lot when you need connection from cd. Direct pppd usage is harder if you have no internet access to get documentation. Keeping rp-pppoe in core cd is very convenient so please consider keeping it. Thank you in advance, Hussam. smime.p7s Description: S/MIME cryptographic signature
Re: [arch-general] resurrecting srcpac
On Wed, 2008-06-04 at 20:38 -0700, Jason Chu wrote: On Sun, Jun 1, 2008 at 1:31 PM, Michael Klier [EMAIL PROTECTED] wrote: Jason Chu wrote: On Sun, Jun 1, 2008 at 10:14 AM, Michael Klier [EMAIL PROTECTED] wrote: Jason Chu wrote: Yeah, put those in your public repo too and then I'll release a new version of srcpac. Ok, almost finished, though one problem remains. Using nobody actually doesn't work because when you su nobody -c command the system will enforce a password change. That leaves 3 options: a) we use a dedicated srcpac user in case srcpac was invoked by root or b) make the user configurable in /etc/srcpac.conf or c) invoke makepkg using sudo -u nobody, that however will add sudo as dependency to srcpac. Personally I think c) is the best of them. Other than that I've added the changes, but because of that missing bit the version in my repo is not 100% functional at the moment. What do you think? Michael I don't mind sudo as a dependency: c) is fine. OK then, I've applied that as well and updated the man page too. Now sudo is used when invoked by root to drop privileges to nobody and su is used to drop privilegs to the user who called srcpac via sudo (using su here to get the environment right). From the tests I've done so far everything seems to work well (though again, it wouldn't harm if someone maybe checked it too). I also haven't touched the version number ;). Regards Michael -- Michael Klier I'm happy with these changes. Now the only real question that needs to be answered should this be srcpac 0.6 or srcpac 1.0? Jason Can you have it run su -c '/path/to/command something' instead of sudo? Not all of us are willing to have to use sudo. If sudo is that necessary, then it is still fine. This is just a small opinion. Thanks. smime.p7s Description: S/MIME cryptographic signature
Re: [arch-general] keyboard indicator lights not working
On Tue, 2008-05-13 at 20:19 +0300, Scott Weisman wrote: Hello, At some point, the keyboard indicator lights stopped working. I know they aren't broken (and I've even used three separate keyboards). They used to work, but stopped at some point, but I don't remember when. Does anyone have any suggestion for this? Thanks, Scott I remember this was a bug in xorg-server. It works in 1.4.0.90-10 in testing. signature.asc Description: This is a digitally signed message part
[arch-general] Status of linux 2.6.25 kernel
What's the status of the 2.6.25 kernel in testing? Any showstoppers left? Regards, Hussam Al-Tayeb. signature.asc Description: This is a digitally signed message part
Re: [arch-general] cairo and cairo-lcd conflict preventing me from getting updates
On Mon, 2008-04-21 at 17:13 -0400, Alec Hussey wrote: Hey everyone, Ive been kind of frustrated lately because I haven't been able to update any of my pacakges because of a conflict between cairo and cairo-lcd. Here is the output from pacman. [EMAIL PROTECTED] ~]$ sudo pacman -Syu :: Synchronizing package databases... core is up to date extra is up to date community is up to date :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... :: cairo conflicts with cairo-lcd. Remove cairo-lcd? [Y/n] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: cairo: conflicts with cairo-lcd I obviously want to keep that package and I even entered it in pacman.conf under HoldPkg and seems to have no affect. I dont know what I should do. Thanks! Alec Hussey My personal opinion is instead of installing an unofficial package name cairo-lcd, just rebuild the cairo package with any extra patches you want. signature.asc Description: This is a digitally signed message part
Re: [arch-general] ClamAV should be update to 0.93
On Wed, 2008-04-16 at 18:38 +0200, Tino Reichardt wrote: Hello list, clamav should be updated. I filed a bug with the two CVE links for the two security issues fixed by clamav 0.93 here http://bugs.archlinux.org/task/10214 signature.asc Description: This is a digitally signed message part
Re: [arch-general] ClamAV should be update to 0.93
On Wed, 2008-04-16 at 18:38 +0200, Tino Reichardt wrote: Hello list, clamav should be updated. I read about this in the news today. http://www.computerworlduk.com/technology/security-products/prevention/news/index.cfm?RSSnewsid=8536 0.93 fixes a security bug. Tino Reichardt, can you please file a bug in bugs.archlinux.org? Set Category to 'Security' Regards, Hussam Al-Tayeb signature.asc Description: This is a digitally signed message part
Re: [arch-general] [English] New Distro - Can't Read German
On Mon, 2008-03-31 at 20:21 -0400, pyther wrote: I need you guys to recommend a new distro. Unfortunately I made a terrible mistake by taking Spanish two years ago (didn't learn much, but still...). This means I do not know German I will be unable to read man pages and what not! I am looking for an ENGLISH distro that is as similar to Arch Linux as possible. Any help would be great! Thank you, Pyther Almost all distributions including ArchLinux use English as the default language in man pages in applications. If you are really looking to switch to another distribution, I would recommend Fedora. The last time I tried it was when they released Fedora Core 3, but I think it is still a great distribution. Still I doubt you will find anything that resembles ArchLinux a lot. signature.asc Description: This is a digitally signed message part
Re: [arch-general] [English] New Distro - Can't Read German
On Mon, 2008-03-31 at 19:32 -0500, Dan McGee wrote: On Mon, Mar 31, 2008 at 7:21 PM, pyther [EMAIL PROTECTED] wrote: I need you guys to recommend a new distro. Unfortunately I made a terrible mistake by taking Spanish two years ago (didn't learn much, but still...). This means I do not know German I will be unable to read man pages and what not! I am looking for an ENGLISH distro that is as similar to Arch Linux as possible. Any help would be great! We are not dropping internationalization support- we have long been one of the best distros for this. You will still have English-language manpages and everything else. However, our site will be primarily in German from this point out, so you may have a bit more help when troubleshooting problems, etc. Just as de_DE was available before, en_US will still be available to most programs. -Dan Oh, I wasn't aware that this is what pyther referring too. he didn't explain much and I hadn't checked the main website yet today. signature.asc Description: This is a digitally signed message part
Re: [arch-general] signoff kernel26-2.6.24.3-6
On Wed, 2008-03-26 at 15:46 +0100, olivier bordes wrote: Hi, exact same for me. old timer, don't want to be babied, don't want hidden nasty things to be done in my back. I love the simplicity and straightforward way of Arch. This is the perfect definition for Arch, and 100% adhere to it (extract from wiki): Arch Linux defines simplicity as a lightweight base structure without unnecessary additions, modifications, or complications, that allows an individual user to shape the system according to their own needs. In short; an elegant, minimalist approach. Btw, could be nice to put it in on top of the archlinux.org home page. Olivier Guys, childish comments only interrupt developers from getting work done. I believe Roman already told people not to panic. So please just drop it. Regards, Hussam. signature.asc Description: This is a digitally signed message part
Re: [arch-general] Name change on crypto modules for kernel26-2.6.24?
On Thu, 2008-01-31 at 11:46 +, Neil Darlow wrote: Hi, To clarify. Neil Darlow wrote: Too me, it looks like these modules have undergone a name change in 2.6.24. I think the required modules are actually being loaded but cryptsetup complains about missing modules. It appears the following name changes have occurred: * padlock_aes.ko -- padlock-aes.ko * padlock_sha.ko -- padlock-sha.ko Regards, Neil Darlow Same issue here. If possible, can one of the developers please take a look at this? signature.asc Description: This is a digitally signed message part
Re: [arch-general] Mailing list rename
On Fri, 2007-11-30 at 14:37 +0200, Grigorios Bouzakis wrote: I would prefer keeping at least one line Greg Yes, please keep at least one line that indicates the mailing list. It will look more elegant that way. signature.asc Description: This is a digitally signed message part
