Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
Lennart Weller wrote: > Currently zshs VCS_INFO function wrongly detects svn repositories if > an .svn directory exists in the current path. Which also applies to > home directories containing for example a ~/.svn/authors file. That's a good point... > Instead of checking only for the directory it would be smarter to > check for an important svn repository file. Like .svn/entries. Which > is done through my patch. That sounds reasonable. Do you know how stable the "entries" file is within the .svn directories with respect to versions? Ie. Does it exist in old versions as well as in recent ones? (My knowledge of subversion's directory contents are rather limited.) > I suggest to check the other revison control systems as well. The other backends should not suffer from this problems. All others that look for a directory to detect a VCS already look for a file in addition to the directory. I don't remember why we didn't do this for svn earlier, too. Probably because nobody complained. :) Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925 -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrlqcp97@ft.bewatermyfriend.org
Bug#611273: wmii: needs Depends: dash
Package: wmii Version: 3.9.2+debian-2 Severity: important Without dash installed, /etc/X11/wmii/wmiirc does nothing, wmii does almost nothing, and there are no obvious clues as to why it's not doing anything. -- System Information: Debian Release: 5.0.8 APT prefers lenny APT policy: (1001, 'lenny'), (700, 'stable'), (600, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wmii depends on: ii libc6 2.7-18lenny7 GNU C Library: Shared libraries ii libx11-62:1.3.3-4X11 client-side library ii libxext62:1.0.4-2X11 miscellaneous extension librar ii libxft2 2.1.12-3 FreeType-based font drawing librar ii libxinerama12:1.0.3-2X11 Xinerama extension library ii libxrandr2 2:1.2.3-1X11 RandR extension library ii libxrender1 1:0.9.4-2X Rendering Extension client libra ii suckless-tools 38-1 simple commands for minimalistic w Versions of packages wmii recommends: ii wmii-doc 1:1-9 lightweight tabbed and tiled X11 w wmii suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127155700.28861.35177.report...@grip.corp.neospire.net
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
Lennart Weller wrote: > On 27.01.2011 16:58, Frank Terbeck wrote: >> That sounds reasonable. Do you know how stable the "entries" file is >> within the .svn directories with respect to versions? Ie. Does it exist >> in old versions as well as in recent ones? (My knowledge of subversion's >> directory contents are rather limited.) >> > I don't use svn frequently either but I just happend to have a > ~/.svn/authors file which caused the bug. I found this: > http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version > > So checking: > [[ -f ".svn/entries" || -f ".svn/format" ]] && return 0 > should be sufficient for all versions. Great. I'll commit this upstream as soon as I can. Thanks. I suggest, debian does the same (maybe you could update your patch for debian's convenience). One nit: you reported this against version 4.3.6-6; however vcs_info was shipped with zsh 4.3.7 for the first time. ...so unless debian's 4.3.6-6 package ships it on its own, I doubt that's correct. :) Anyway, debian's maintainers will know how to handle this. Regards, Frank -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqricn63@ft.bewatermyfriend.org
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
On 27.01.2011 16:58, Frank Terbeck wrote: > That sounds reasonable. Do you know how stable the "entries" file is > within the .svn directories with respect to versions? Ie. Does it exist > in old versions as well as in recent ones? (My knowledge of subversion's > directory contents are rather limited.) > I don't use svn frequently either but I just happend to have a ~/.svn/authors file which caused the bug. I found this: http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version So checking: [[ -f ".svn/entries" || -f ".svn/format" ]] && return 0 should be sufficient for all versions. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d419f10.2060...@ring0.de
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
On 27.01.2011 17:43, Frank Terbeck wrote:
> I suggest, debian does the same (maybe you could update your patch for
> debian's convenience).
>
> One nit: you reported this against version 4.3.6-6; however vcs_info was
> shipped with zsh 4.3.7 for the first time. ...so unless debian's 4.3.6-6
> package ships it on its own, I doubt that's correct. :)
I forgot to check for a version mismatch. I just send the report from an
older debian box with mail setup for reportbug. The actual version was
4.3.10 but that doesn't really matter anyway.
--- a/VCS_INFO_detect_svn 2011-01-27 17:50:51.0 +0100
+++ b/VCS_INFO_detect_svn 2011-01-27 17:51:09.0 +0100
@@ -7,5 +7,5 @@
[[ $1 == '--flavours' ]] && return 1
VCS_INFO_check_com ${vcs_comm[cmd]} || return 1
-[[ -d ".svn" ]] && return 0
+[[ -f ".svn/entries" || -f ".svn/format" ]] && return 0
return 1
Bug#478762: Bug#543907: Netbeans 6.9 and Dependencies Ready for Upload
On Wed, Jan 26, 2011 at 6:23 PM, Damien Raude-Morvan wrote: > Le lundi 24 janvier 2011 23:48:32, Andres Mejia a écrit : >> netbeans is in contrib because of jruby. Once jruby goes into main, >> netbeans can follow. > > Agreed. > >> >> felix-framework >> > >> > I've just reviewed felix-framework. >> > I've commited some changes to felix-framework GIT repository like : >> > >> > * Add myself as Uploaders. >> >> Ah great, the more the merrier! > > I'm interrested in all felix-* stuff so I've added myself (with some bonus > fixes > :) to those packages. > >> > * d/copyright: Update to DEP-5 r166 format. >> >> If you or anyone else wants to switch copyrights to this format, be my >> guest. I'll switch once this format becomes finalized and a part of >> official debian policy (if that ever happens). > > As a side note, I've just updated this d/copyright to a "pre-candidate-DEP5" > to "final-DEP5". > > I've also started reviewing others packages and add an issue with "bsaf". > When running under a chroot/cowbuilder, got failures during test phase : Works for me with sbuild. Must be that pbuilder/cowbuilder doesn't sanatize environment variables like sbuild does. I've been using sbuild for building packages. DISPLAY is one of the variables that don't get passed when building through sbuild, since the buildd machines wouldn't have any displays to use. I would try with sbuild. Or you can file a bug against pbuilder/cowbuilder. > test: > [junit] Running org.jdesktop.application.AbstractBeanTest > [junit] Testsuite: org.jdesktop.application.AbstractBeanTest > [junit] No protocol specified > [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.041 sec > [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.041 sec > [junit] > [junit] Testcase: fireOnEdtTest(org.jdesktop.application.AbstractBeanTest): > Caused an ERROR > [junit] Can't connect to X11 window server using ':0' as the value of the > DISPLAY variable. > [junit] java.lang.InternalError: Can't connect to X11 window server using > ':0' as the value of the DISPLAY variable. > [junit] at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > [junit] at > sun.awt.X11GraphicsEnvironment.access$100(X11GraphicsEnvironment.java:62) > [junit] at > sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:166) > [junit] at java.security.AccessController.doPrivileged(Native Method) > [junit] at > sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:142) > [junit] at java.lang.Class.forName0(Native Method) > [junit] at java.lang.Class.forName(Class.java:186) > [junit] at > java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82) > [junit] at sun.awt.X11.XToolkit.(XToolkit.java:112) > [junit] at java.lang.Class.forName0(Native Method) > [junit] at java.lang.Class.forName(Class.java:186) > [junit] at java.awt.Toolkit$2.run(Toolkit.java:849) > [junit] at java.security.AccessController.doPrivileged(Native Method) > [junit] at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:841) > [junit] at java.awt.Toolkit.getEventQueue(Toolkit.java:1698) > [junit] at java.awt.EventQueue.isDispatchThread(EventQueue.java:810) > [junit] at > javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1364) > [junit] at > javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:90) > [junit] at > java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:229) > [junit] at > org.jdesktop.application.AbstractBean.firePropertyChange(Unknown Source) > [junit] at > org.jdesktop.application.AbstractBeanTest$TestBean.fire(Unknown Source) > [junit] at > org.jdesktop.application.AbstractBeanTest.fireOnEdtTest(Unknown Source) > [junit] > [junit] > > BUILD FAILED > /tmp/buildd/bsaf-1.9/build.xml:68: Test > org.jdesktop.application.AbstractBeanTest failed > > Could you please have a look ? Maybe disable this testsuite or start a xvfb > server before running tests. > > Cheers, > -- > Damien - Debian Developper > http://wiki.debian.org/DamienRaudeMorvan > -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimswgacyvb0zdm0zafgw6jkpc8w6f2xp71eg...@mail.gmail.com
Bug#586605: firmware-b43-installer: do not fail on kernel version mismatch
Hi, > firmware-b43-installer currently fails in postinst script on kernel versions < > 2.6.25. This makes impossible to install firmware-b43-installer in the > deboostrapped environment, since it may not have a kernel at all, but the host > system has 2.6.18 or similar. postinst script should ask if it's ok to install > firmware-b43-installer anyway (like udev does). > > from NEWS file: ... b43-fwcutter (1:011-5) unstable; urgency=high * This version of the package installs the firmware suitable for kernels >= 2.6.25. It will do so unconditionally on upgrades and this break usage with 2.6.24. If you for some reason still want to use 2.6.24, please backup your "old" /lib/firmware/b43. A kernel greater than (or equal) 2.6.25 is required otherwise the firmware will not work. My suggest is to close this bug. Thanks Fabrizio. signature.asc Description: This is a digitally signed message part
Bug#586605: firmware-b43-installer: do not fail on kernel version mismatch
2011/1/27 Fabrizio Regalli > Hi, > > > firmware-b43-installer currently fails in postinst script on kernel > versions < > > 2.6.25. This makes impossible to install firmware-b43-installer in the > > deboostrapped environment, since it may not have a kernel at all, but the > host > > system has 2.6.18 or similar. postinst script should ask if it's ok to > install > > firmware-b43-installer anyway (like udev does). > > > > > > from NEWS file: > > ... > b43-fwcutter (1:011-5) unstable; urgency=high > > * This version of the package installs the firmware suitable for > kernels >= 2.6.25. It will do so unconditionally on upgrades and this > break usage with 2.6.24. If you for some reason still want to use > 2.6.24, please backup your "old" /lib/firmware/b43. > > A kernel greater than (or equal) 2.6.25 is required otherwise the > firmware will not work. > > My suggest is to close this bug. > Nope, one again: installation of firmware-b43-installer will fail in a debootstrapped environment (NOT a host system). For example, host system has 2.6.18, debootstrapped system doesn't have kernel at all. At this time I cannot install firmware-b43-installer in debootstrapped system. Postinst script should determine the debootstrapped system (based on comparing root inodes like it's done in udev's postinst) and bypass kernel check in such system, and (probably) show a warning that it fail to work on < 2.6.25, so it will be my headache to provide a suitable kernel for my debootstrapped system. > > Thanks > Fabrizio. > -- Regards, Krasu
