[arch-general] pdftk - almost build but died - need help figuring out if I can find a work-around
Guys,
I need pdftk for a script I use that does fax processing. I ran into
this
problem 6-7 months ago, but still had another server with pdftk on it so it
wasn't critical. Now, I need to solve it.
Currently pdftk in AUR is out of date due to it a dependency of gcc-gcj
requiring it to be built against gcc-4.3. The building gcc-4.3 and then gcc-gcj
part of the pdftk build goes fine (takes forever, but goes fine). The build
seems to crater on a java-lib issue. Here is the actual error with a few lines
of context:
patching file pdftk/Makefile.Base
patching file java_libs/com/lowagie/text/pdf/PdfEncryption.java
patching file java_libs/Makefile
make -C ../java_libs
make[1]: Entering directory
`/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs'
make -C
/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs/com/lowagie/text;
make[2]: Entering directory
`/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs/com/lowagie/text'
gcj -march=x86-64 -mtune=generic -O2 -pipe -w --encoding=UTF-8
--classpath=/usr/share/java/libgcj-4.3.jar:/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs
-c Anchor.java -o Anchor.o
Exception in thread main java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.so.9)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/share/java/eclipse-ecj.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at gnu.java.lang.MainThread.run(libgcj.so.9)
make[2]: *** [Anchor.o] Error 1
make[2]: Leaving directory
`/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs/com/lowagie/text'
make[1]: *** [itext] Error 2
make[1]: Leaving directory
`/home/david/arch/pkg/bld/pdftk/src/pdftk-1.41/java_libs'
make: *** [java_libs] Error 2
The problem is I am no good at figuring out what this is telling me I
need to
do to fix it. I know there was an exception thrown in thread main
java.lang.NoClassDefFoundError: what I don't know is whether this is
telling me there is a javalib version mismatch or something similar and whether
this is something I might work around by loading/building some alternative java
package, etc..
If you have any idea what is going on here, please pass along a pointer
or two.
If this is just one of those areas where I'm screwed and there isn't a way
around it -- well knowing that would be helpful too. Thanks.
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
[arch-general] Update register/log
Is there a register or log that lists the history of package updates. I need to know what versions of encfs and openssl were updated and when. I am still unable to mount my 1.5 year old volume because of broken encfs and openssl update. (I did read all the bug reports associated with this, they recommend downgrading to openssl 0.9.8l, which I already tried) Manne
Re: [arch-general] Update register/log
On Fri, Mar 12, 2010 at 11:07 AM, Manne Merak manneme...@gmail.com wrote: Is there a register or log that lists the history of package updates. I need to know what versions of encfs and openssl were updated and when. I am still unable to mount my 1.5 year old volume because of broken encfs and openssl update. (I did read all the bug reports associated with this, they recommend downgrading to openssl 0.9.8l, which I already tried) Manne I believe you want /var/log/pacman.log.
[arch-general] Security
Hi all, I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? Thanks in advance, Gordy
Re: [arch-general] Security
On Fri, Mar 12, 2010 at 11:49 AM, Gordon Campbell gordy2...@hotmail.co.uk wrote: Hi all, I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? Thanks in advance, Gordy For a home computer you don't need to have a firewall installed, since you're probably not running any services (e.g.: web, database or e-mail server) that would listen on certain ports. Your router most likely uses NAT [1] as well, and this means that incoming traffic won't reach any machines inside the local network, unless you've configured port forwarding [2]. [1] http://en.wikipedia.org/wiki/Network_address_translation [2] http://en.wikipedia.org/wiki/Port_forwarding
Re: [arch-general] Security
Am 12.03.2010 10:49, schrieb Gordon Campbell: Hi all, I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? Thanks in advance, Gordy You probably don't, but here is a link to some nice instructions for setting one up manually: http://wiki.archlinux.org/index.php/Simple_stateful_firewall_HOWTO I recommend to read section 1 and 2, but I am not very fond of subsections 2.7 and 2.8 (especially 2.8 seems like nonsense). Anyway, this will show you what kind of firewalling you can do in Linux without a good security concept. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Security
On Fri, Mar 12, 2010 at 09:49:17AM -, Gordon Campbell wrote: Hi all, I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? In Linux the actual firewall is part of the kernel, you just need to activate and configure it. Activting it requires the iptables package, and configuring it means writing 'rules'. If you run one of the fat desktops (KDE, Gnome) they will have a GUI tool to configure iptables. In the other case there are various tools available, see http://wiki.archlinux.org/index.php/Firewalls. Or you could learn the iptables rules syntax and do it manually - for the brave only but the most flexible. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
[arch-general] Customising arch iso
I was just wondering if there are there any up to date instructions available for customising the arch installer? I only need to upgrade the kernel to 2.6.32 in order to install (at least that is the first problem I have encountered). Thanks in advance, Damien
Re: [arch-general] Customising arch iso
On 03/12/2010 12:51 PM, Damien Churchill wrote: I was just wondering if there are there any up to date instructions available for customising the arch installer? I only need to upgrade the kernel to 2.6.32 in order to install (at least that is the first problem I have encountered). Thanks in advance, Damien you could test this isos: http://build.archlinux.org/isos/ -- Ionut
Re: [arch-general] Customising arch iso
On 12 March 2010 10:54, Ionut Biru biru.io...@gmail.com wrote: On 03/12/2010 12:51 PM, Damien Churchill wrote: I was just wondering if there are there any up to date instructions available for customising the arch installer? I only need to upgrade the kernel to 2.6.32 in order to install (at least that is the first problem I have encountered). Thanks in advance, Damien you could test this isos: http://build.archlinux.org/isos/ -- Ionut Excellent! Just what I was looking for, thanks a lot!
Re: [arch-general] Customising arch iso
On 12 March 2010 10:56, Damien Churchill dam...@gmail.com wrote: On 12 March 2010 10:54, Ionut Biru biru.io...@gmail.com wrote: On 03/12/2010 12:51 PM, Damien Churchill wrote: I was just wondering if there are there any up to date instructions available for customising the arch installer? I only need to upgrade the kernel to 2.6.32 in order to install (at least that is the first problem I have encountered). Thanks in advance, Damien you could test this isos: http://build.archlinux.org/isos/ -- Ionut Excellent! Just what I was looking for, thanks a lot! Ahh my mistake, I need 2.6.33, Heres the commit that adds support for my network card: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f5aac7070a01ec757ed243febe4fff7c944c4d2 Would I be able to just install kernel26 from testing on another arch and copy the resulting vmlinuz26 and kerne26.img files across to the new iso? Damien
Re: [arch-general] Customising arch iso
On Fri, 12 Mar 2010 11:49:36 + Damien Churchill dam...@gmail.com wrote: On 12 March 2010 10:56, Damien Churchill dam...@gmail.com wrote: On 12 March 2010 10:54, Ionut Biru biru.io...@gmail.com wrote: On 03/12/2010 12:51 PM, Damien Churchill wrote: I was just wondering if there are there any up to date instructions available for customising the arch installer? I only need to upgrade the kernel to 2.6.32 in order to install (at least that is the first problem I have encountered). Thanks in advance, Damien you could test this isos: http://build.archlinux.org/isos/ -- Ionut Excellent! Just what I was looking for, thanks a lot! Ahh my mistake, I need 2.6.33, Heres the commit that adds support for my network card: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f5aac7070a01ec757ed243febe4fff7c944c4d2 Would I be able to just install kernel26 from testing on another arch and copy the resulting vmlinuz26 and kerne26.img files across to the new iso? Damien you can also build your own iso's using archiso. it's pretty easy, although you need archiso from git and you must let it look in a repository that contains a 2.6.33 package (ie archlinux testing) Dieter
Re: [arch-general] Customising arch iso
On Fri, 12 Mar 2010 12:17:07 + Damien Churchill dam...@gmail.com wrote: On 12 March 2010 12:14, Dieter Plaetinck die...@plaetinck.be wrote: you can also build your own iso's using archiso. it's pretty easy, although you need archiso from git and you must let it look in a repository that contains a 2.6.33 package (ie archlinux testing) Dieter Ok cool, thanks! I'm just going to try installing using the core cd and then copying the kernel and firmware packages over via flash, if that fails too then I'll resort to creating my own cd! you could also try a netinstall cd and enable the testing repository in /tmp/pacman.conf. IIRC aif (the installer) uses pacman with that config file, so it might just work, although i never tried it myself. if you are not afraid of looking at bash scripts, look at the source code of aif then you'll see how exactly it works. Dieter
Re: [arch-general] Customising arch iso
On Fri, Mar 12, 2010 at 6:29 AM, Dieter Plaetinck die...@plaetinck.be wrote: you could also try a netinstall cd and enable the testing repository in /tmp/pacman.conf. IIRC aif (the installer) uses pacman with that config file, so it might just work, although i never tried it myself. if you are not afraid of looking at bash scripts, look at the source code of aif then you'll see how exactly it works. A netinstall using a kernel without the necessary network drivers might prove hard to use. :) -Dan
Re: [arch-general] Customising arch iso
On Fri, 12 Mar 2010 06:57:46 -0600 Dan McGee dpmc...@gmail.com wrote: On Fri, Mar 12, 2010 at 6:29 AM, Dieter Plaetinck die...@plaetinck.be wrote: you could also try a netinstall cd and enable the testing repository in /tmp/pacman.conf. IIRC aif (the installer) uses pacman with that config file, so it might just work, although i never tried it myself. if you are not afraid of looking at bash scripts, look at the source code of aif then you'll see how exactly it works. A netinstall using a kernel without the necessary network drivers might prove hard to use. :) -Dan don't laugh :P i realised it just after hitting submit ;) Dieter
Re: [arch-general] Security
Am Fri, 12 Mar 2010 09:49:17 - schrieb Gordon Campbell gordy2...@hotmail.co.uk: I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? Thanks in advance, Here's a good iptables tutorial with some good example firewall scripts: http://www.frozentux.net/documents/iptables-tutorial/ Greetings, Heiko
Re: [arch-general] Security
On Friday 12 March 2010 19:26:13 Heiko Baums wrote: Am Fri, 12 Mar 2010 09:49:17 - schrieb Gordon Campbell gordy2...@hotmail.co.uk: I am new to this list and fairly new to Arch Linux. My Question is do I need to install a firewall? if so which one? ufw is a good iptables frontend. Pretty easy to set up HTH -- Regards Shridhar
Re: [arch-general] Customising arch iso
On 12 March 2010 13:19, Dieter Plaetinck die...@plaetinck.be wrote: On Fri, 12 Mar 2010 06:57:46 -0600 Dan McGee dpmc...@gmail.com wrote: On Fri, Mar 12, 2010 at 6:29 AM, Dieter Plaetinck die...@plaetinck.be wrote: you could also try a netinstall cd and enable the testing repository in /tmp/pacman.conf. IIRC aif (the installer) uses pacman with that config file, so it might just work, although i never tried it myself. if you are not afraid of looking at bash scripts, look at the source code of aif then you'll see how exactly it works. A netinstall using a kernel without the necessary network drivers might prove hard to use. :) -Dan don't laugh :P i realised it just after hitting submit ;) Dieter Using the core installing then just upgrading kernel26 and kernel26-firmware to 2.6.33 worked just in case anyone was wondering. Got networking up finally :)
Re: [arch-general] Security
On 03/12/2010 05:22 AM, f...@kokkinizita.net wrote: If you run one of the fat desktops (KDE, Gnome) they will have a GUI tool to configure iptables. FYI - I've found firestarter to be a good, simple one for small home network use. DR
Re: [arch-general] Bad attitude in flyspray again!
On Thu, Mar 11, 2010 at 7:23 PM, Heiko Baums li...@baums-on-web.de wrote: Am Thu, 11 Mar 2010 17:58:12 -0600 schrieb Aaron Griffin aaronmgrif...@gmail.com: This sounds like throwing technology at a problem that basically boils down to a communication issue. Without specific examples, this isn't going to go anywhere, really. Would someone mind linking to the bugs in question? I didn't give the links to these bug reports and the names of the concerned developers because I didn't want to offend anyone personally with this thread. I just wanted to say, that such things happened at least twice. That such an early closing bug can easily seem arrogant or ignorant. I know in the meantime that the developer didn't mean it. So I think discussing how to avoid such things in general would be better. And yes, in the last case, it was indeed a communication issue and some misunderstandings on the developers and on my side. But I would say that the communication concerns in these special cases are clarified. But those communication issues could be avoided with some of the proposals already made here in this thread. Commenting on closed bugs is not doable in Flyspray. More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question
Re: [arch-general] Customising arch iso
On Fri, Mar 12, 2010 at 8:15 AM, Damien Churchill dam...@gmail.com wrote: On 12 March 2010 13:19, Dieter Plaetinck die...@plaetinck.be wrote: On Fri, 12 Mar 2010 06:57:46 -0600 Dan McGee dpmc...@gmail.com wrote: On Fri, Mar 12, 2010 at 6:29 AM, Dieter Plaetinck die...@plaetinck.be wrote: you could also try a netinstall cd and enable the testing repository in /tmp/pacman.conf. IIRC aif (the installer) uses pacman with that config file, so it might just work, although i never tried it myself. if you are not afraid of looking at bash scripts, look at the source code of aif then you'll see how exactly it works. A netinstall using a kernel without the necessary network drivers might prove hard to use. :) -Dan don't laugh :P i realised it just after hitting submit ;) Dieter Using the core installing then just upgrading kernel26 and kernel26-firmware to 2.6.33 worked just in case anyone was wondering. Got networking up finally :) Yeah, I was going to suggest just pulling the kernel updates onto a thumb drive or something
Re: [arch-general] security
Hi, Thanks for all your advice. So far I am enjoying my experience with Arch Linux since I changed my Distro over from Fedora about a month ago. Gordy
Re: [arch-general] Customising arch iso
Am 12.03.2010 16:37, schrieb Aaron Griffin: Using the core installing then just upgrading kernel26 and kernel26-firmware to 2.6.33 worked just in case anyone was wondering. Got networking up finally :) Yeah, I was going to suggest just pulling the kernel updates onto a thumb drive or something Someone (as in not me) should really make archiso easier to use and document it better. The ultimate goal would be the ability to run one single command to get an up to date ISO - without any more configuration or other tweaking. signature.asc Description: OpenPGP digital signature
Re: [arch-general] security
On Fri, Mar 12, 2010 at 12:43 PM, Gordon Campbell gordy2...@hotmail.co.uk wrote: Hi, Thanks for all your advice. So far I am enjoying my experience with Arch Linux since I changed my Distro over from Fedora about a month ago. Just one more opinion, it can't hurt :) I myself don't need a firewall beyond my router, but if I was in need of one, I would certainly use Firehol [1]. It is a clever bash script that pretends to be like a high level language for definitions of a firewall. When the system is booting, the script is converted to the real iptables rules. It may be a little less efficient in boot time, but the flexibility and elegance of the definition language pay it very well, IMHO. So, hope that helps you. [1] http://firehol.sourceforge.net/ -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto ---
Re: [arch-general] Customising arch iso
On 12.03.2010 16:48, Thomas Bächler wrote: Am 12.03.2010 16:37, schrieb Aaron Griffin: Using the core installing then just upgrading kernel26 and kernel26-firmware to 2.6.33 worked just in case anyone was wondering. Got networking up finally :) Yeah, I was going to suggest just pulling the kernel updates onto a thumb drive or something Someone (as in not me) should really make archiso easier to use and document it better. The ultimate goal would be the ability to run one single command to get an up to date ISO - without any more configuration or other tweaking. Just get my AUR package (http://aur.archlinux.org/packages.php?ID=25996) to get the utils installed on your system and clone git (git clone git://projects.archlinux.org/archiso.git) to get the scripts. Then go to archiso/configs/syslinux-iso/ and run make. This should get you an updated set of isos for your architecture. Also, I'm trying hard to keep the archiso wiki article (http://wiki.archlinux.org/index.php/Archiso) updated and in good shape to make it easier to make your own Arch-based distribution. Please let me know if there's anything else left to document until archiso becomes usuable to you. -- Sven-Hendrik
Re: [arch-general] Bad attitude in flyspray again!
Hi, On Fri, 12 Mar 2010, Aaron Griffin wrote: Commenting on closed bugs is not doable in Flyspray. I didn't know it, thanks for the info! So I guess every argument from now on is just for the sake of completion... More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question Once, on another project, I filed a feature request on Flyspray. I also attached some measurements that showed how slow was the current way of doing things. After some monts the feature got implemented and the bug closed. I liked the feature, the program was much faster, and I wanted to attach measurements from the same machine that showed the difference. I didn't because I felt a reopen request would bother the developers. But even for true reopen requests, IMHO the request itself should be logged as a comment so that others can see it, and why it was rejected. Dimitris
Re: [arch-general] Bad attitude in flyspray again!
Am Fri, 12 Mar 2010 09:34:01 -0600 schrieb Aaron Griffin aaronmgrif...@gmail.com: Commenting on closed bugs is not doable in Flyspray. Commenting on closed bugs isn't necessary. This is a matter of taste. Some bug trackers allow this, some not. More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question And that's the problem. Bugs shouldn't be closed at once. Usually such discussions should be done in the comments of a bug report not directly with the developer. And closing a bug without giving the reporter the chance to give reasons why the bug shouldn't be closed can seem really arrogant and ignorant as it was in my case. And this can happen due to a simple mistake as it was in my case. The reopening request and its comment is not a solution, because the user is forced to begging. This is why I opened this thread. Commenting on closed bugs don't need to be implemented, but the reporter must be given the chance to answer without having to beg. The best solution in my sight is that the developer first writes a normal comment that he can't reproduce it and ask for more details. Probably the developer can tell the reporter which information he needs. This should be done without closing the bug. If the reporter doesn't answer in a reasonable time, or the reporter confirms that the bug is invalid or there are other reasons for closing this bug the bug can still be closed. If the developer closes a bug he should first give the reason for closing the bug in a normal comment. This is where Ng Oon-Ee's suggestion comes into play to make it a bit easier for the developer, if this is possible with flyspray: I guess it would be good for a simple system where if a bug cannot be reproduced its marked/commented as 'cannot reproduce, please provide proof/details' and placed on a 7-day (arbitrary number) wait, where no more comments would automatically close the bug. But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Greetings, Heiko
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. -Dan
Re: [arch-general] Customising arch iso
On Fri, Mar 12, 2010 at 9:48 AM, Thomas Bächler tho...@archlinux.org wrote: Am 12.03.2010 16:37, schrieb Aaron Griffin: Using the core installing then just upgrading kernel26 and kernel26-firmware to 2.6.33 worked just in case anyone was wondering. Got networking up finally :) Yeah, I was going to suggest just pulling the kernel updates onto a thumb drive or something Someone (as in not me) should really make archiso easier to use and document it better. The ultimate goal would be the ability to run one single command to get an up to date ISO - without any more configuration or other tweaking. Well it *is* one command from a git checkout cd install-iso make
[arch-general] LTS kernel still boots but MPPC patched one does not after manual updates
Big problemo. Wanting to get access to my sons MS vpn server which needs MPPC, I found and installed an MPPC patched kernel26, and MPPC patched ppp. No problems so far, and both the LTS, and the MPPC patched kernels booted with no problems. My Arch install hadn't been updated since 20090928, and as accessing the vpn server and retrieving the shares still wasn't working, I did a pacman -Sy, and pacman -Su hoping that some update might resolve the problem. After saying yes to a bunch of stuff to do with klibc (replacing packages), pacman -Su failed saying kdelib needs phonon. Can't install phonon because it wants to remove qt (qt4). I have KDEmod3 so there is no need for phonon anyway. Not the best way to do a full system upgrade, but I went at it manually, working my way through starting at (A). Some packages wont upgrade, wanting to remove mkinitcpio, which you can't remove as it's needed by the kernels. Others didn't want to upgrade saying warning: provider package was selected (that was resolved later on during my manual upgrading). All went ok the first day 20090309, and the only thing I needed to say yes to was replacing kernel-headers with linux-api-headers. The next morning I booted with the MPPC patched kernel with no problems, just to see if any of the updates had resolved the vpn problem, but no. Rebooted with the LTS kernel, and continued with the updates, rebooting from time to time with the LTS kernel to make sure that nothing had broken. Got as far as ntp, then had a go at gdm, which I'd been putting off (I've had problems with that before). rebooted after that, and gdm failed with the below output. gdm (gdm-binary:2033) couldn't connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket No such file or directory Having already had the machine down one day, working in runlevel 1 to resolve the missing libpng12 problem (that was on the 8th march) I was a bit T'd off now, but startx worked, so I reinstalled the previous gdm which thankfully worked. I'd now had enough for the days work, so shut down. Day 20100311. Now the manure starts to hit the fan. Tried to boot the MPPC patched kernel, which failed with: cannot find /dev/sda7, device does not exist. Gave udev time, but nothing. Tried the MPPC failsafe kenel, but the same there. Tried the LTS kernel, and thankfully that booted ok. Googled a lot, and found references to the problem, but didn't see any fixes. One mentioned udev, and knowing that the udev update had been pulled in by one of the packages I'd updated, I looked at /etc/udev/rules.d, and udev.rules was showing as udev.rules.pacnew (I presume that is due to the new mkinitcpio and mkinitcpio-busybox using mdev, but mkinitcpio wont upgrade, claiming that a bunch of files still exist.). I renamed udev.rules.pacnew to udev.rules, and rebooted with the MPPC kernel, but it still wont boot. Tried reinstalling MPPC patched kernel, but no change. Original install output below (when it booted ok prior to my manual updating fiasco), followed by the install output from the reinstall (which still wont boot). Had to remove madwifi, and ndiswrapper to originally install this kernel. :: madwifi: requires kernel26=2.6.30 :: ndiswrapper: requires kernel26=2.6.30 [r...@myhost Archlinux-mppc-kernel]# pacman -U kernel26-2.6.24.3-3-i686.pkg.tar.gz loading package data... checking dependencies... (1/1) checking for file conflicts [#] 100% (1/1) upgrading kernel26[#] 100% If you use the LILO bootloader, you should run 'lilo' before rebooting. Updating module dependencies. Please wait ... MKINITCPIO SETUP If you use LVM2, Encrypted root or software RAID, Ensure you enable support in /etc/mkinitcpio.conf . More information about mkinitcpio setup can be found here: http://wiki.archlinux.org/index.php/Mkinitcpio Generating initial ramdisk, using mkinitcpio. Please wait... == Building image default == Running command: /sbin/mkinitcpio -k 2.6.24-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [autodetect] :: Parsing hook [pata] :: Parsing hook [scsi] :: Parsing hook [sata] :: Parsing hook [keymap] :: Parsing hook [filesystems] :: Generating module dependencies :: Generating image '/boot/kernel26.img'...SUCCESS == SUCCESS == Building image fallback == Running command: /sbin/mkinitcpio -k 2.6.24-ARCH -c /etc/mkinitcpio.d/kernel26-fallback.conf -g /boot/kernel26-fallback.img :: Begin build :: Parsing hook [base] :: Parsing hook [udev] :: Parsing hook [ide] ERROR: module 'ide[-_]gd[-_]mod' not found :: Parsing hook [pata] :: Parsing hook [scsi] :: Parsing hook [sata] :: Parsing hook [usbinput] :: Parsing hook [raid] :: Parsing hook [filesystems] :: Generating module dependencies :: Generating image '/boot/kernel26-fallback.img'...SUCCESS == SUCCESS
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 09:34 -0600, Aaron Griffin wrote: Commenting on closed bugs is not doable in Flyspray. More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question That's not always true. There have been instances where I've commented on closed bugs to point at an alternative solution or note where the bug had been fixed where the developer neglected to.
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote: On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. I think another problem is that the bug wranglers aren't necessarily involved in development and don't communicate with the developers before taking action on a bug. That's no fault of the developer, but is a fault with the bug wrangler.
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 2:12 PM, Loui Chang louipc@gmail.com wrote: On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote: On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. I think another problem is that the bug wranglers aren't necessarily involved in development and don't communicate with the developers before taking action on a bug. That's no fault of the developer, but is a fault with the bug wrangler. Err? This sounds like quite a broad generalization without specific examples. Do *you* have any examples you'd like to share?
Re: [arch-general] Bad attitude in flyspray again!
On Fri 12 Mar 2010 14:11 -0600, Aaron Griffin wrote: On Fri, Mar 12, 2010 at 2:12 PM, Loui Chang louipc@gmail.com wrote: On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote: On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums li...@baums-on-web.de wrote: But just closing a bug should not be done. There's usually a reason why a bug is reported even if it's invalid. Seriously, present some examples here, this talking in the abstract is stupid. We're all grown ups, no one is going to have their feelings hurt. Without them I'm sick of the back and forth on this- most devs leave bugs open for more than long enough to get feedback (and don't get it!), and we would all rather have bugs be either fixed or closed than hang around forever. I think another problem is that the bug wranglers aren't necessarily involved in development and don't communicate with the developers before taking action on a bug. That's no fault of the developer, but is a fault with the bug wrangler. Err? This sounds like quite a broad generalization without specific examples. Do *you* have any examples you'd like to share? Sure. On occasion Paul Mattal will close or edit bugs in the AUR bug tracker. He's no longer involved in development and hasn't communicated with me about any of the tickets he touches.
Re: [arch-general] Bad attitude in flyspray again!
Commenting on closed bugs is not doable in Flyspray. Actually it is doable, it's a configuration option per project. Check http://bugs.archlinux.org/pm/proj1/prefs More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers assuming malicious users up-front? - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question I see at least several good uses of allowing comments on closed bugs, sometimes even adding aditional reasons why the bug needs to *stay closed*. -- damjan
Re: [arch-general] Where to install python apps: /usr/lib/python2.6/site-packages/xyz??
On Thu, 11 Mar 2010 10:27:25 -0600 David C. Rankin drankina...@suddenlinkmail.com wrote: Guy, I know nothing about python other than what it is. I need to install repoview-0.6.5 on my arch server, but I'm not sure where. Looking at the other python apps like cairo, FusionIcon, etc.. thay seem to be installed as a subdirectory to: /usr/lib/python2.6/site-packages/ The repoview directory contains: drwxr-xr-x 3 david david 4096 Feb 19 13:31 templates -rw-r--r-- 1 david david 3457 Feb 19 13:31 ChangeLog -rw-r--r-- 1 david david 18009 Mar 3 2005 COPYING -rw-r--r-- 1 david david 708 Jul 19 2007 README -rw-r--r-- 1 david david 2634 Sep 27 2007 repoview.8 -rwxr-xr-x 1 david david 32932 Feb 19 13:31 repoview.py Do I just move the directory to /usr/lib/python2.6/site-packages/? Then is there something else I need to do to register (for lack of better words) repoview somewhere so python knows it is there? Then what about the man page? Anything special required to do I just move it to /usr/share/man or /usr/local/man? You should use makepkg for it unless you are doing it in virtualenv. There already is a PKGBUILD for repoview in aur. http://aur.archlinux.org/packages.php?ID=35377
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski gdam...@gmail.com wrote: Commenting on closed bugs is not doable in Flyspray. Actually it is doable, it's a configuration option per project. Check http://bugs.archlinux.org/pm/proj1/prefs More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers assuming malicious users up-front? - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question I see at least several good uses of allowing comments on closed bugs, sometimes even adding aditional reasons why the bug needs to *stay closed*. Thanks. I just turned this on for the pacman bug tracker because I do find comments after closing a feature that is a net positive (with some trolling drawbacks, of course). -Dan
Re: [arch-general] Where to install python apps: /usr/lib/python2.6/site-packages/xyz??
On Fri, Mar 12, 2010 at 10:06:59PM +0100, Øyvind Heggstad wrote: On Thu, 11 Mar 2010 10:27:25 -0600 David C. Rankin drankina...@suddenlinkmail.com wrote: Guy, I know nothing about python other than what it is. I need to install repoview-0.6.5 on my arch server, but I'm not sure where. Looking at the other python apps like cairo, FusionIcon, etc.. thay seem to be installed as a subdirectory to: /usr/lib/python2.6/site-packages/ The repoview directory contains: drwxr-xr-x 3 david david 4096 Feb 19 13:31 templates -rw-r--r-- 1 david david 3457 Feb 19 13:31 ChangeLog -rw-r--r-- 1 david david 18009 Mar 3 2005 COPYING -rw-r--r-- 1 david david 708 Jul 19 2007 README -rw-r--r-- 1 david david 2634 Sep 27 2007 repoview.8 -rwxr-xr-x 1 david david 32932 Feb 19 13:31 repoview.py Do I just move the directory to /usr/lib/python2.6/site-packages/? Then is there something else I need to do to register (for lack of better words) repoview somewhere so python knows it is there? Then what about the man page? Anything special required to do I just move it to /usr/share/man or /usr/local/man? You should use makepkg for it unless you are doing it in virtualenv. There already is a PKGBUILD for repoview in aur. http://aur.archlinux.org/packages.php?ID=35377 The directory /usr/lib/pythonX.Y/site-packages is where you install Python *modules*, which are extensions to the Python library to be used by Python programs. The normal way to install them there is using the Python distutils and a 'setup.py' script. Python *applications* must *not* be installed there. They should go in /usr/bin just as any other executable, and preferably not have the .py extension. The fact that they are Python programs is irrelevant to the user. If a package provides both a Python application and some modules required to run it then each part must be installed in the appropriate place. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] Bad attitude in flyspray again!
On Fri, 12 Mar 2010, Dan McGee wrote: On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski gdam...@gmail.com wrote: Commenting on closed bugs is not doable in Flyspray. Actually it is doable, it's a configuration option per project. Check http://bugs.archlinux.org/pm/proj1/prefs More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers assuming malicious users up-front? - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question I see at least several good uses of allowing comments on closed bugs, sometimes even adding aditional reasons why the bug needs to *stay closed*. Thanks. I just turned this on for the pacman bug tracker because I do find comments after closing a feature that is a net positive (with some trolling drawbacks, of course). Me thanks! I think it will generally be positive. And in any case you can turn it back off if it's abused. Dimitris -Dan
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski gdam...@gmail.com wrote: Commenting on closed bugs is not doable in Flyspray. Actually it is doable, it's a configuration option per project. Check http://bugs.archlinux.org/pm/proj1/prefs Well damn, looks like I was looking too high up.
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski gdam...@gmail.com wrote: More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers assuming malicious users up-front? Not at all. It is statistics. For a long time before the bug wranglers, I personally had to deal with 75% of the Project Manager requests from flyspray. These were all reopen requests, and many of them arguing with the actual choice a developer made. Something like: Developer: Won't Implement. We want patch in features like this Reopen #1: But it's a good feature and upstream says it will be included soon! Me: Deny. He said he won't implement. Wait for upstream Reopen #2: This should totally be done. Without this patch Arch Linux sucks! Me: Deny
Re: [arch-general] Customising arch iso
Am 12.03.2010 20:35, schrieb Aaron Griffin: Well it *is* one command from a git checkout cd install-iso make Let's make that 2: # pacman -S archiso # archiso-build-cd --arch i686 --format iso or something like that :) We have an archiso package from 2008 in extra. Any package is better than that one, no matter how buggy it is. And an easy-to-use wrapper with a manpage would be nice, so any end user can easily build an image. I definitely won't have time for that soon, but maybe someone else can make a patch. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Customising arch iso
On Fri, Mar 12, 2010 at 4:49 PM, Thomas Bächler tho...@archlinux.org wrote: Am 12.03.2010 20:35, schrieb Aaron Griffin: Well it *is* one command from a git checkout cd install-iso make Let's make that 2: # pacman -S archiso # archiso-build-cd --arch i686 --format iso This is just too complex to do in one command like that, unless it becomes just a wrapper for what the Makefile does, in which case you're going to be adding lots of frameworking for error checking and dependence whatnot (that make provides by default) As for the packages: I honestly think we should remove it and just have people checkout from git if they want to build a CD. /shrug
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
On Fri, Mar 12, 2010 at 11:39 PM, Allan McRae al...@archlinux.org wrote: On 13/03/10 08:35, Aaron Griffin wrote: Does anyone have an opinion on this? In my eyes, I imagine the kind of people who want this feature simply wish to argue about the closing. I've had to deal with enough PM requests in the past to know that this _does_ happen. Opinions? I really do not see the need. If a bug is wrongly closed - request a reopen. If you just want to confirm a bug has been fixed, there is no need... we already closed the bug report. If there is a better fix, reopen request or new bug report. Closing bugs should not be a race, I had several times the feeling that a bug was closed too fast and it can indeed be annoying. Ideally the one who opened the bug should give an ACK for having their bug closed. There is always something to say. At least a confirmation that the bug was fixed. Eventually a comment about how it was fixed. And you might have additional information / explanation / clarification that is mostly interesting for the people who followed that bug. It seems completely stupid to need a reopen request just to do that.
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
On 13/03/10 09:13, Xavier Chantry wrote: On Fri, Mar 12, 2010 at 11:39 PM, Allan McRaeal...@archlinux.org wrote: On 13/03/10 08:35, Aaron Griffin wrote: Does anyone have an opinion on this? In my eyes, I imagine the kind of people who want this feature simply wish to argue about the closing. I've had to deal with enough PM requests in the past to know that this _does_ happen. Opinions? I really do not see the need. If a bug is wrongly closed - request a reopen. If you just want to confirm a bug has been fixed, there is no need... we already closed the bug report. If there is a better fix, reopen request or new bug report. Closing bugs should not be a race, I had several times the feeling that a bug was closed too fast and it can indeed be annoying. Ideally the one who opened the bug should give an ACK for having their bug closed. There is always something to say. At least a confirmation that the bug was fixed. Eventually a comment about how it was fixed. And you might have additional information / explanation / clarification that is mostly interesting for the people who followed that bug. It seems completely stupid to need a reopen request just to do that. If we need a confirmation the bug is fixed, then the bug should not be closed straight away. But if a bug is definitely fixed and I close it, I really do not need further confirmation it is fixed. I fact, the only time I ever want to hear about the bug again is if it is not fixed. Given the useless reopen requests I have seen and denied repeatedly (such as patching in a new feature), I really would not like to continually be notified of such posts. So closing a bug becomes 1) remove yourself from assignees, 2) remove from notification, 3) close bug. Allan
Re: [arch-general] Bad attitude in flyspray again!
On 03/12/10 10:34, Aaron Griffin wrote: More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question Okay, here's my example (of a different reason to comment on a closed bug). I found bug #18022 that affected me, http://bugs.archlinux.org/task/18022 . It was marked closed with Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1. I requested to re-open, saying that I was running libdrm 2.4.17-4 and xf86-video-intel 2.10.0-1 and it was not fixed with those versions. I got an e-mail response from FlySpray saying that the assigned-to person (JGC) denied my request, with the justification being There's already an open bug for this. I didn't see any obvious polite way to respond ( -- which is a Flyspray issue. See below for what I did next/why.). Replying in another re-open request seemed rude. If bug #18022 was a duplicate, I couldn't see anywhere on the bug that said *which* open bug it was a duplicate of, so I couldn't go make a comment there instead. Also, I searched, and in my judgment no other bug in bugs.archlinux.org besides #18022 seemed to quite match my symptoms. Also, I could have opened yet another bug, but that seemed rude. (Also, it's an upstream bug, albeit a bug that makes one's machine unusable, so it isn't even one that I'd submit to Arch. But, the bug existed in bugs.archlinux.org with inaccurate information that would bother future bug seekers/reporters, so I wanted it to be marked some way that's accurate, and would have liked to update it with my progress at reporting the bug upstream.) So I poked around and found JGC's email address according to bugs.archlinux.org and e-mailed in response (although I didn't get a response to my e-mail, so I don't know if it got to JGC successfully). I wrote to JGC: (I hope e-mailing your archlinux address is an okay way to reply, since your reply to my reopen-request didn't appear anywhere on the Web that I could find) If this bug is a duplicate, can you mark it as such, and say clearly which bug it is a duplicate of? All I want to do is to leave a comment about my progress reporting the bug upstream, so that other people who search and find this archlinux bug will be less confused... This text is also a bit confusing given that the described bug is not fixed, (nor even affected by upgrading to the mentioned versions) Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1. thanks? -Isaac
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
On Fri, Mar 12, 2010 at 5:38 PM, Allan McRae al...@archlinux.org wrote: So closing a bug becomes 1) remove yourself from assignees, 2) remove from notification, 3) close bug. This is what worries me the most. If comments on old bugs are allowed, this will become the norm.
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 5:48 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 03/12/10 10:34, Aaron Griffin wrote: More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question Okay, here's my example (of a different reason to comment on a closed bug). I found bug #18022 that affected me, http://bugs.archlinux.org/task/18022 . It was marked closed with Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1. I requested to re-open, saying that I was running libdrm 2.4.17-4 and xf86-video-intel 2.10.0-1 and it was not fixed with those versions. I got an e-mail response from FlySpray saying that the assigned-to person (JGC) denied my request, with the justification being There's already an open bug for this. I didn't see any obvious polite way to respond ( -- which is a Flyspray issue. See below for what I did next/why.). Replying in another re-open request seemed rude. If bug #18022 was a duplicate, I couldn't see anywhere on the bug that said *which* open bug it was a duplicate of, so I couldn't go make a comment there instead. Also, I searched, and in my judgment no other bug in bugs.archlinux.org besides #18022 seemed to quite match my symptoms. Also, I could have opened yet another bug, but that seemed rude. (Also, it's an upstream bug, albeit a bug that makes one's machine unusable, so it isn't even one that I'd submit to Arch. But, the bug existed in bugs.archlinux.org with inaccurate information that would bother future bug seekers/reporters, so I wanted it to be marked some way that's accurate, and would have liked to update it with my progress at reporting the bug upstream.) So I poked around and found JGC's email address according to bugs.archlinux.org and e-mailed in response (although I didn't get a response to my e-mail, so I don't know if it got to JGC successfully). I wrote to JGC: (I hope e-mailing your archlinux address is an okay way to reply, since your reply to my reopen-request didn't appear anywhere on the Web that I could find) If this bug is a duplicate, can you mark it as such, and say clearly which bug it is a duplicate of? All I want to do is to leave a comment about my progress reporting the bug upstream, so that other people who search and find this archlinux bug will be less confused... This text is also a bit confusing given that the described bug is not fixed, (nor even affected by upgrading to the mentioned versions) Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1. thanks? -Isaac So you wanted to add a comment totally unrelated to the bug itself to the bug? Isn't that polluting the bug report? What happened here is exactly what I'd expect - you contacted the developer. Now, if it was difficult to find the email addresses, that's very different and something we SHOULD fix.
[arch-general] gbd missing from extra?
couldn't retreive the gnu debugger from pacman -S gdb, and looking in the extra repo it didn't seem to be present. any reason? Richard
Re: [arch-general] gbd missing from extra?
On 13/03/10 09:55, richard terry wrote: couldn't retreive the gnu debugger from pacman -S gdb, and looking in the extra repo it didn't seem to be present. any reason? It is definitely there. pacman -Syy may help and if not change your mirror and do it again. Allan
Re: [arch-general] Bad attitude in flyspray again!
Am Fri, 12 Mar 2010 16:38:36 -0600 schrieb Aaron Griffin aaronmgrif...@gmail.com: Not at all. It is statistics. For a long time before the bug wranglers, I personally had to deal with 75% of the Project Manager requests from flyspray. These were all reopen requests, and many of them arguing with the actual choice a developer made. Something like: Developer: Won't Implement. We want patch in features like this Reopen #1: But it's a good feature and upstream says it will be included soon! Me: Deny. He said he won't implement. Wait for upstream Reopen #2: This should totally be done. Without this patch Arch Linux sucks! Me: Deny This is slightly different. In this case the developer and you have given the reason for not implementing it, because you as downstream don't want to add a feature by patching the package. This is common and well known Arch policy. And this was not a bug report but a feature request. In my case - I still don't give the links. I don't want to blame a certain developer and I actually don't want to keep on at this certain issue. - a program has worked perfectly in the previous version. After the latest update it didn't work anymore, it was almost completely unusable, without changing the configuration. So it's most likely a bug, and I of course have searched the forums, wiki and the web before reporting the bug. The bug was closed as works for me without giving a reason as far as I remember (those comments are not added to the normal comments - should be changed). Something similar already happened with another bug. How do I understand it? What was my reaction? I felt being ignored by the developer. And that's why I sent a reopening request with a not quite friendly comment. Then this reopening request was denied with another unfriendly comment. How do I understand this? What's my reaction? The developer doesn't take my bugs (problems) seriously, isn't willing to look more precisely at the bug, doesn't care if a software is unusable etc. So from my (the reporter's) point of view it's just arrogant and ignorant. In the meantime I know that this all have been misunderstandings. The developer hasn't read my bug report precisely enough and thought that it was again such a bug report where the user hasn't configured his system correctly. I have missed, that my reopening request was denied by another developer to whom the bug wasn't assigned. And I of course know, that the developer in fact wasn't ignorant and arrogant. He rather looked again into this bug and found the problem. This all could have been avoided, if the bug hadn't been closed so early without giving me the chance to respond with a normal comment and if the reopening request would have been answered only by the developer to whom it was assigned. Such misunderstandings can always happen. And such reactions can be prevented by first writing a comment that the developer can't reproduce the bug and asking for more details, or asking if the reporter is sure that he already searched the forums, or whatever. Then I wouldn't have felt being ignored and would have explained in a much friendlier manner why I'm sure that this is a bug and not a configuration issue. I'm not talking about such conversations you mentioned above. But such conversations couldn't completely be avoided. Even if such bug reports can be annoying, a developer shouldn't first think about such users who don't read the documentations, search the forums, want other people to do the user's work, reports invalid bug reports etc. when reading a bug report. And - I repeat myself - think about how the reporter will understand it. So better keep bugs reports open a bit longer than closing them too early. I'm telling this again, because I just want to explain the user's/reporter's point of view, and that such cases could be at least reduced. Just think about it. ;-) Greetings, Heiko
Re: [arch-general] Bad attitude in flyspray again!
Am Fri, 12 Mar 2010 17:58:34 -0600 schrieb Aaron Griffin aaronmgrif...@gmail.com: So you wanted to add a comment totally unrelated to the bug itself to the bug? Isn't that polluting the bug report? What happened here is exactly what I'd expect - you contacted the developer. No, this is related to the bug, because it was the same bug, only for a different package version. And such an information or the request for this information (the other bug's number) should be added to the comments, so that other people who've got this issue, too, and only find this closed bug can find the current open bug report. Otherwise everyone would need to contact the developer directly by e-mail which could be much more annoying for the developer than one or two additional comments to the closed bug report and wouldn't help other people. It would of course be still better if the developer would give the bug number of the current bug to which he refers directly. Greetings, Heiko
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
Am Sat, 13 Mar 2010 08:39:05 +1000 schrieb Allan McRae al...@archlinux.org: I really do not see the need. If a bug is wrongly closed - request a reopen. If you just want to confirm a bug has been fixed, there is no need... we already closed the bug report. If there is a better fix, reopen request or new bug report. And this is forcing the reporter to begging for reopening and looking again at the bug. Closing a bug too early can in the reporter's sight mean: Hey! I'm the king and I decide if I'm willing to fix the bug. And if I don't want to, then you don't have to say anything. Your subject to my merci. Of course this is a bit exaggerated and of course in most cases the developer doesn't mean it, but this is how the reporter can easily understand it. And this can lead to such misunderstandings and to angry reactions. Don't see this only from your (the developer's) point of view. Try to see it from the reporter's point of view. Greetings, Heiko
Re: [arch-general] gbd missing from extra?
Typo? your subject on the mail states you searched for gbd instead of gdb maybe? -T On Sat, 13 Mar 2010, richard terry wrote: couldn't retreive the gnu debugger from pacman -S gdb, and looking in the extra repo it didn't seem to be present. any reason? Richard
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
What do other distros do on their bugtrackers? We should allow comments after closing to facilitate further user input. Lets not forget that Arch Linux would not be in it's current state without user/dev interaction. On Mar 12, 2010 7:19 PM, Heiko Baums li...@baums-on-web.de wrote: Am Sat, 13 Mar 2010 08:39:05 +1000 schrieb Allan McRae al...@archlinux.org: I really do not see the need. If a bug is wrongly closed - request a reopen. If you just ... And this is forcing the reporter to begging for reopening and looking again at the bug. Closing a bug too early can in the reporter's sight mean: Hey! I'm the king and I decide if I'm willing to fix the bug. And if I don't want to, then you don't have to say anything. Your subject to my merci. Of course this is a bit exaggerated and of course in most cases the developer doesn't mean it, but this is how the reporter can easily understand it. And this can lead to such misunderstandings and to angry reactions. Don't see this only from your (the developer's) point of view. Try to see it from the reporter's point of view. Greetings, Heiko
Re: [arch-general] gbd missing from extra?
On Saturday 13 March 2010 12:20:43 you wrote: Typo? your subject on the mail states you searched for gbd instead of gdb maybe? -T On Sat, 13 Mar 2010, richard terry wrote: couldn't retreive the gnu debugger from pacman -S gdb, and looking in the extra repo it didn't seem to be present. any reason? Richard your right, I figured that out 30mins ago. Dumb!!! Sorry for the useless post. Regards richard
Re: [arch-general] [arch-dev-public] Allow comments on closed bugs?
Am Fri, 12 Mar 2010 20:22:35 -0500 schrieb Robert Howard rjh0...@ecu.edu: What do other distros do on their bugtrackers? We should allow comments after closing to facilitate further user input. Lets not forget that Arch Linux would not be in it's current state without user/dev interaction. I used Gentoo for several years before I switched to Arch Linux a few years ago. On the Gentoo bug tracker I had the impression that every bug report is taken seriously. The developers are not so easily annoyed by invalid bug reports where a user just have missed an option in his system configuration, because this can happen to everyone, or hasn't enough knowledge. And the Gentoo Bugzilla isn't degenerated to a support forum. If it turns out that a bug report is just caused by a wrong configuration the developers or users who read the bug report usually just explain what is wrong and how to fix it. Or they point to the forums or the documentation and what to search for. If the reporter and the developer disagree the issue is discussed before a bug is just be closed as won't fix. How long the discussion takes or the result of the discussion depends on the bug. In not a few cases some or many other users and developers take part on such discussions. If a developer can't reproduce a bug he usually tells it in a comment without closing the bug. A bug is usually only closed if the bug is definitely fixed or if the fix or the invalidity is confirmed by the reporter or another user who has this issue, too. If the developer couldn't reproduce the bug he usually asks for testing the fix. There are still some bugs - at least one of mine - open since several years with several duplicates. Usually these are annoying but not the most important issues. If a bug is closed at once - usually this is only done by bug wranglers, but not by developers - the bug report can easily be reopened by the reporter. And if a bug is closed too early the bug wrangler usually gives a reason for this in the comments, and the reporter can easily reply with a comment. In the cases I know, then the bug was kept open and the developer to whom it was assigned deals with it and decides what to do. Well, Gentoo has a lot more developers than Arch Linux, so Gentoo has more manpower than Arch Linux. But I bet, this could be changed on Arch. I would sum it up a bit simplified that Gentoo is more user than developer driven while Arch Linux is currently more developer than user driven. It's not that the users can't file feature requests or take part on discussions with the Arch developers. And usually the Arch developers listen to the users. But I read too many times sentences like Arch is/was from developers for developers, the developers only maintain, what they want, etc. And too many times some developers speak openly that they don't like Arch's growing user community. This somehow keeps the users and their needs and wishes out. Yes, I know, this is not quite right, but sometimes I have a bit the impression. The early bug closing issue is one of the reasons for this impression. Also AUR is usually seen as unofficial by the developers, because the packages are merely made by usual users. Sometimes I'd prefer if AUR would be seen as unstable but official a bit like Gentoo's sunrise overlay. Of course the AUR maintainers don't need to and shouldn't get developer or TU status just because they maintain such a package. The user/dev interaction is, btw., the engine of the whole OpenSource community. Heiko
[arch-general] Btrfs more than twice as fast compared to ext4
Hi, Just wanted to share an interesting experience I had today. Check http://ghodechhap.net/btrfs.performance.txt -- Regards Shridhar
