Bug#1007913: What news with wine 7.0?
Hi, So wine 7 is not going to be packaged anytime soon? Regards, Le ven. 1 avr. 2022 à 15:28, Antoine Le Gonidec a écrit : > Le 31/03/2022 à 14:39, Jérôme Marant a écrit : > > Is wine 7 been week-end on? > > It looks like 6.x are been uploaded instead. What's the point? > > The point is not to burn out the package maintainer with one huge messy > changeset, and to provide us users with a mostly bug-free package thanks to > incremental updates that are easier to review. > > I advise either patience, or using WineHQ packages if you really can not > wait. Keeping in mind that if Michael keeps the upload rate he had lately, > we can expect him to reach 7.0 in less than 2 weeks from now. >
Bug#1003147: Guitarix maintenance
Hi, Does the team plan to keep maintaining Guitarix please? Regards,
Bug#1007913: What news with wine 7.0?
Hi, Is wine 7 been week-end on? It looks like 6.x are been uploaded instead. What's the point? Regards,
Bug#1003148: guvcview: New upstream release 2.0.7
Package: guvcview Version: 2.0.6+debian-1+b3 Severity: wishlist Dear Maintainer, Guvcview 2.0.7 has been released. It provided better compatibility with pipewire. Regards, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages guvcview depends on: ii libc6 2.33-1 ii libglib2.0-0 2.70.2-1 ii libgtk-3-0 3.24.30-4 ii libguvcview-2.0-2 2.0.6+debian-1+b3 Versions of packages guvcview recommends: ii uvcdynctrl 0.2.4-1.1+b2 guvcview suggests no packages. -- no debconf information
Bug#1003147: guitarix: New upstream release 0.43.1
Package: guitarix Version: 0.42.1+dfsg1-3 Severity: wishlist Dear Maintainer, Guitarix 0.43.1 has been released last december. Regards, -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages guitarix depends on: ii fonts-roboto 2:0~20170802-3 ii guitarix-common 0.42.1+dfsg1-3 ii guitarix-ladspa 0.42.1+dfsg1-3 ii guitarix-lv2 0.42.1+dfsg1-3 ii libatkmm-1.6-1v5 2.28.2-1 ii libavahi-common3 0.8-5 ii libavahi-gobject0 0.8-5 ii libbluetooth3 5.62-1 ii libboost-iostreams1.74.0 1.74.0-13 ii libc6 2.33-1 ii libcairomm-1.0-1v51.12.2-4 ii libcurl3-gnutls 7.79.1-2 ii libfftw3-single3 3.3.8-2 ii libgcc-s1 11.2.0-12 ii libglib2.0-0 2.70.2-1 ii libglibmm-2.4-1v5 2.66.2-1 ii libgtk-3-03.24.30-4 ii libgtkmm-3.0-1v5 3.24.5-1 ii libgxw0 0.42.1+dfsg1-3 ii libgxwmm0 0.42.1+dfsg1-3 ii libjack0 [libjack-0.125] 1:0.125.0-3+b1 ii liblilv-0-0 0.24.12-2 ii liblrdf0 0.6.1-2 ii libpangomm-1.4-1v52.46.1-1 ii libsigc++-2.0-0v5 2.10.4-2 ii libsndfile1 1.0.31-2 ii libstdc++611.2.0-12 ii libzita-convolver44.0.3-2 ii libzita-resampler11.8.0-2 Versions of packages guitarix recommends: ii gvfs-backends 1.48.1-2 ii jack-capture 0.9.73-3 ii lame 3.100-3 ii vorbis-tools 1.4.2-1 guitarix suggests no packages. -- no debconf information
Bug#892512: scribus: Eyedropper tool is not working
Hi, I'm still experiencing the problem. I purged the package, removed my configuration and reinstalled it but it doesn't change anything. Regards, Jérôme. - Mail original - De: "Mattia Rizzolo" À: "Jérôme Marant" , 892...@bugs.debian.org Envoyé: Lundi 11 Février 2019 15:33:54 Objet: Re: Bug#892512: scribus: Eyedropper tool is not working Control: tag -1 moreinfo unreproducible Hi, I'm sorry for leaving this bug unattended for nearly a whole year. On Fri, Mar 09, 2018 at 10:54:07PM +0100, Jérôme Marant wrote: > The eyedropper tool currently does not work. > Clicking on it should show a dialog asking for a new color > name. > > It used to work one year ago. It is quite strange since the package has > not been updated since october 2016. Could it be possible that some > libraries it depends on be broken? I've just tried, and using the eyedropper tool does ask me for a colour name. Could you please try again? I'm not sure what could have happened... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Bug#892512: scribus: Eyedropper tool is not working
Package: scribus Version: 1.4.6+dfsg-4+b1 Severity: normal Dear Maintainer, The eyedropper tool currently does not work. Clicking on it should show a dialog asking for a new color name. It used to work one year ago. It is quite strange since the package has not been updated since october 2016. Could it be possible that some libraries it depends on be broken? Regards, Jérôme. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages scribus depends on: ii ghostscript 9.22~dfsg-2 ii libc62.27-1 ii libcairo21.15.10-2 ii libcups2 2.2.6-5 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-2 ii libgcc1 1:8-20180218-1 ii libhyphen0 2.8.8-5 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-1 ii libpodofo0.9.5 0.9.5-9 ii libpython2.7 2.7.14-6 ii libqt4-network 4:4.8.7+dfsg-11 ii libqt4-xml 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui44:4.8.7+dfsg-11 ii libstdc++6 8-20180218-1 ii libtiff5 4.0.9-4 ii libxml2 2.9.4+dfsg1-6.1 ii python-tk2.7.14-2 ii scribus-data 1.4.6+dfsg-4 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages scribus recommends: ii cups-bsd2.2.6-5 ii fonts-dejavu2.37-1 ii fonts-liberation1:1.07.4-5 ii hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-5 ii icc-profiles-free 2.0.1+dfsg-1 ii xfonts-scalable 1:1.0.3-1.1 Versions of packages scribus suggests: ii icc-profiles 2.1-2 pn scribus-doc pn scribus-template ii texlive-latex-recommended 2017.20180305-1 -- no debconf information
Bug#781014: RFP: xfce4-pulseaudio-plugin -- Xfce PulseAudio Panel Plugin
Package: wnpp Version: N/A; reported 2015-03-23 Severity: wishlist * Package name : xfce4-pulseaudio-plugin Version : 0.2.1 Upstream Author : Andrzej Radecki ndrwr...@gmail.com Guido Berhoerster guido+x...@berhoerster.name Simon Steinbeiss och...@xfce.org * URL : http://archive.xfce.org/src/panel-plugins/xfce4-pulseaudio-plugin/ * License : GPL V2 Description : Xfce PulseAudio Panel Plugin The Xfce PulseAudio Plugin is a plugin for the Xfce panel which provides a convenient way to adjust the audio volume of the PulseAudio sound system and to an auto mixer tool like pavucontrol. It can optionally handle multimedia keys for controlling the audio volume. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702657: grafx2: New release available
- Mail original - De: Gürkan Sengün gur...@phys.ethz.ch À: Jérôme Marant jer...@marant.org, 702...@bugs.debian.org Cc: Debian Bug Tracking System sub...@bugs.debian.org Envoyé: Mercredi 13 Mars 2013 10:12:03 Objet: Re: Bug#702657: grafx2: New release available Dear Jerome Thanks, I know. You can find that version here if you can't wait: http://sid.ethz.ch/debian/grafx2/ Great! Thank you. Jérôme. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702657: grafx2: New release available
Package: grafx2 Version: 2.3-1.1 Severity: wishlist Dear Maintainer, Version 2.4 has been released last october. Regards, -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grafx2 depends on: ii libc62.13-38 ii liblua5.1-0 5.1.5-4 ii libpng12-0 1.2.49-3 ii libsdl-image1.2 1.2.12-2 ii libsdl-ttf2.0-0 2.0.11-2 ii libsdl1.2debian 1.2.15-5 ii libx11-6 2:1.5.0-1 grafx2 recommends no packages. grafx2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693122: wordpress: Minor mistake in apache configuration example
Package: wordpress Version: 3.4.2+dfsg-1 Severity: wishlist Dear Maintainer, There is a minor mistake in /usr/share/doc/wordpress/examples/apache.conf. In the configuration without virtual hosts, you need change the order of the following lines, from : Alias /blog /usr/share/wordpress Alias /blog/wp-content /var/lib/wordpress/wp-content to: Alias /blog/wp-content /var/lib/wordpress/wp-content Alias /blog /usr/share/wordpress otherwise apache will detect a conflict. Ragards, Jérôme. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wordpress depends on: ii apache2-mpm-prefork [httpd] 2.2.22-12 ii dpkg 1.16.9 ii libapache2-mod-php5 5.4.4-9 ii libjs-cropper1.2.2-1 ii libjs-prototype 1.7.0-2 ii libjs-scriptaculous 1.9.0-2 ii libphp-phpmailer 5.1-1 ii libphp-snoopy1.2.4-2 ii mysql-client 5.5.28+dfsg-1 ii mysql-client-5.5 [mysql-client] 5.5.28+dfsg-1 ii php5 5.4.4-9 ii php5-gd 5.4.4-9 ii php5-mysql 5.4.4-9 ii tinymce 3.4.8+dfsg0-1 Versions of packages wordpress recommends: ii wordpress-l10n 3.4.2+dfsg-1 Versions of packages wordpress suggests: pn mysql-server none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681390: O: gregorio -- command-line tool to typeset Gregorian chant
Package: wnpp Severity: normal I intend to orphan the gregorio package. The package description is: Gregorio is a project with a lot of functionalities. The main interest is gabc, a very simple and fast language to describe a Gregorian chant score. The project is for now a command-line tool to convert gabc files into real score, like for example OpusTeX or GregorioTeX. But it also handles a XML format: GregorioXML. You can use the tool to read or write gabc and GregorioXML, and to write OpusTeX and GregorioTeX. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662231: chromium: Fails to decode iso-8859-15 encoded pages
Package: chromium Version: 17.0.963.56~r121963-1 Severity: normal Dear Maintainer, Chromium fails to decode iso-8859-15 encoded pages. For example, browsing http://makeart.goto10.org/2007, triggers: error on line 1 at column 41: Unsupported encoding iso-8859-15 Apparently, Chrome does not have this problem. There is a bug about this in Chrome's bug tracker. http://code.google.com/p/chromium/issues/detail?id=28748 Regards, -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chromium depends on: ii chromium-inspector 17.0.963.56~r121963-1 ii libasound2 1.0.25-2 ii libavcodec534:0.8-1+b1 ii libavformat53 4:0.8-1+b1 ii libavutil51 4:0.8-1+b1 ii libbz2-1.0 1.0.6-1 ii libc6 2.13-27 ii libcairo2 1.10.2-6.2 ii libcups21.5.2-5 ii libdbus-1-3 1.4.18-1 ii libevent-2.0-5 2.0.17-stable-1 ii libexpat1 2.0.1-7.2 ii libflac81.2.1-6 ii libfontconfig1 2.8.0-3.1 ii libfreetype62.4.8-1 ii libgcc1 1:4.6.2-16 ii libgconf2-4 3.2.3-3 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.24.1-1 ii libglib2.0-02.30.2-6 ii libgtk2.0-0 2.24.10-1 ii libjpeg88d-1 ii libnspr4-0d 4.9-1 ii libnss3-1d 3.13.3-1 ii libpango1.0-0 1.29.4-2 ii libpng12-0 1.2.47-1 ii libpulse0 1.1-3 ii libspeex1 1.2~rc1-3 ii libstdc++6 4.6.2-16 ii libv8-3.7.12.22 3.7.12.22-3 ii libwebp20.1.3-3 ii libx11-62:1.4.4-4 ii libxext62:1.3.0-3 ii libxfixes3 1:5.0-4 ii libxml2 2.7.8.dfsg-7 ii libxrender1 1:0.9.6-2 ii libxslt1.1 1.1.26-8 ii libxss1 1:1.2.1-2 ii xdg-utils 1.1.0~rc1+git20111210-6 ii zlib1g 1:1.2.6.dfsg-2 chromium recommends no packages. Versions of packages chromium suggests: ii chromium-l10n 17.0.963.56~r121963-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621334: gregorio: diff for NMU version 2.0-1.1
Sorry. Please NMU. Thanks. Jérôme. - Luk Claes l...@debian.org a écrit : tags 621334 + patch tags 621334 + pending thanks Dear maintainer, I've prepared an NMU for gregorio (versioned as 2.0-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520751: Fails to burn an audio CD
Works fine now. Thanks. - Mail Original - De: Emilio Pozuelo Monfort poch...@gmail.com À: Jérôme Marant jerome.mar...@free.fr, 520...@bugs.debian.org Envoyé: Lundi 3 Août 2009 23:58:19 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: Bug#520751: Fails to burn an audio CD Jérôme Marant wrote: Package: brasero Version: 0.8.0-3 Severity: normal Hi, I'm trying to provide Brasero a set of FLAC files, in order to burn it on a 700Mb CD-R. After clicking on Burn, it blocks at the Normalizing tracks step. Can you check with brasero 2.26? Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517005: Info received (Still problematic)
Please ignore my previous mail. The culprit is libdrm2. Regards, - Mail Original - De: Debian Bug Tracking System ow...@bugs.debian.org À: Jérôme Marant jerome.mar...@free.fr Envoyé: Samedi 28 Mars 2009 18:24:02 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Bug#517005: Info received (Still problematic) Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Fglrx packaging team pkg-fglrx-de...@lists.alioth.debian.org If you wish to submit further information on this problem, please send it to 517...@bugs.debian.org, as before. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 517005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517005 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521720: Lastest libdrm2 breaks Xorg
Package: libdrm2 Version: 2.4.5-2 Severity: serious Hi, After upgrading from 2.3.1-2 to 2.4.5-2, my Xorg failed to work properly. After downgrading to 2.3.1-2, situation is normal again. I do use latest Xorg from unstable along with fglrx non-free drivers, and kernel 2.6.26. Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517005: Still problematic
Hi, I recenlty updated my system and Xorg won't start. It looks like the problem is still around. Regard, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520751: Fails to burn an audio CD
Package: brasero Version: 0.8.0-3 Severity: normal Hi, I'm trying to provide Brasero a set of FLAC files, in order to burn it on a 700Mb CD-R. After clicking on Burn, it blocks at the Normalizing tracks step. Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#431311: ICE1724 sound device does not work properly
Hi, I don't use such hardware any more. Regards, - Mail Original - De: Moritz Muehlenhoff j...@inutil.org À: Jérôme Marant jerome.mar...@free.fr Cc: 431...@bugs.debian.org, j...@debian.org Envoyé: Dimanche 21 Décembre 2008 01:50:28 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: ICE1724 sound device does not work properly On Sun, Jul 01, 2007 at 05:52:08PM +0200, Jérôme Marant wrote: Package: linux-image-2.6.21-2-686 Version: 2.6.21-5 Severity: normal --- Please enter the report below this line. --- Hi, Since 2.6.21, sound on my Shuttle SN25P system (with ICE1724 sound device), stopped working properly. I have to use 2.6.20 in order for it to work. Any sound seems to gets played at a very low frequency. At boot-time, I can see alsactl complaining but I could not find the logs. Current pre-2.6.22 trees don't work either. Does this error still occur with more recent kernel versions? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#444594: totem icon don't show up in Audio and Video section
No, I don't. You can close it. Thanks. Selon Sven Arvidsson [EMAIL PROTECTED]: On Sun, 2007-09-30 at 14:26 +0200, Jérôme Marant wrote: The totem icon is missing in the 'Audio and Video' section. I'm not sure but I suspect GNOME is looking for a 48x48 totem icon and there isn't any. Hi, Are you still having this problem with Totem 2.22? -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22 -- Jérôme Marant
Bug#431311: ICE1724 sound device does not work properly
Le Sunday 01 July 2007 23:04:08 maximilian attems, vous avez écrit : On Sun, Jul 01, 2007 at 05:52:08PM +0200, Jérôme Marant wrote: Hi, Since 2.6.21, sound on my Shuttle SN25P system (with ICE1724 sound device), stopped working properly. I have to use 2.6.20 in order for it to work. Any sound seems to gets played at a very low frequency. At boot-time, I can see alsactl complaining but I could not find the logs. Current pre-2.6.22 trees don't work either. hmm in that case, please notify alsa upstream bug tracking system. otherwise this bug report will just bitrot here. Thanks. This is bug #0003093 at alsa-project.org. Cheers,
Bug#431311: ICE1724 sound device does not work properly
Package: linux-image-2.6.21-2-686 Version: 2.6.21-5 Severity: normal --- Please enter the report below this line. --- Hi, Since 2.6.21, sound on my Shuttle SN25P system (with ICE1724 sound device), stopped working properly. I have to use 2.6.20 in order for it to work. Any sound seems to gets played at a very low frequency. At boot-time, I can see alsactl complaining but I could not find the logs. Current pre-2.6.22 trees don't work either. Thanks in advance. Regards, --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-2-686 Debian Release: lenny/sid 990 unstablewww.debian-multimedia.org 990 unstablenightlies.videolan.org 990 unstableftp.fr.debian.org 1 experimentalftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ===-+-=== module-init-tools (= 0.9.13) | 3.3-pre11-3 initramfs-tools (= 0.55) | 0.88 OR yaird(= 0.0.12-8) | OR linux-initramfs-tool| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329092: emacs21 now builds so close bug? (was: emacs21_21.4a-2(m68k/unstable/vault13): FTBFS on m68k)
close 329092 thanks Done. Thanks. Selon Drew Scott Daniels [EMAIL PROTECTED]: It seems emacs21_21.4a+1-3 has built on m68k (see http://buildd.debian.org/fetch.cgi?pkg=emacs21ver=21.4a%2B1-3arch=m68kstamp=1167934529file=log ) Shall we close this bug? This version also seems to be in etch (and I expect future versions will too). Thanks, Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html -- Jérôme Marant
Bug#401665: #401665
Hi Andreas, I want to let you know I'm unable to work on #401665. I don't have the necessary hardware, nor the knowledge about such an architecture, nor the support from Ryan Murray I asked for (he runs the autobuilder but never replies to mails). I also did not work on the port myself and applied patches that used to work. Regards, -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le samedi 16 décembre 2006 21:09, Rob Browning a écrit : Jérôme Marant [EMAIL PROTECTED] writes: Shall we contact Ryan? Sounds like a good idea. Though I suppose there's another difference between vaughan and the buildd. On vaughan I wasn't building from a clean chroot. Rob, are you taking care of this, or should I? Thanks. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le jeudi 21 décembre 2006 21:34, Rob Browning a écrit : Jérôme Marant [EMAIL PROTECTED] writes: Rob, are you taking care of this, or should I? Please do, if you have the time. I will only available till next Saturday so I guess someone will have to take care of it if both of us are unavailable. -- Jérôme Marant
Bug#401665: [HELP] Re: Bug#401665: FTBFS on mipsel
Hi Ryan, We would like to find out why latest version of emacs21 (21.4+1-2) failed to build on mipsel. 21.4+1-1 used to build fine and no change related to the C code nor autoconf files has been made in 21.4+1-2. Since we don't have a clean sid chroot on vaughan (the only developer mipsel machine which seems to be available), could you please help us investigating the problem? Thanks in advance. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le samedi 16 décembre 2006 04:18, Rob Browning a écrit : [EMAIL PROTECTED] writes: Do you know how to use an etch chroot on vaughan? (I guess this is the only mipsel machine available to developers?) Thanks in advance. I just started a build in the vaughan sid chroot, and it's well past sysdep.c now, so I'm not sure what the problem is, but I'm wondering if it might be something on the buildd or something that was broken in etch that has since been fixed in etch (or sid). It looks like it has been rescheduled for building yesterday and it is still failing. Please note that vaughan is not the build machine. It is rem which is maitained by Ryan Murray. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le samedi 16 décembre 2006 19:08, Rob Browning a écrit : Jérôme Marant [EMAIL PROTECTED] writes: It looks like it has been rescheduled for building yesterday and it is still failing. Please note that vaughan is not the build machine. It is rem which is maitained by Ryan Murray. Right, but it is a mipsel machine, so the fact that it works in a sid chroot on vaughan suggests to me that something's probably wrong on the other machine. Shall we contact Ryan? -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 11:38, Andreas Barth a écrit : * Jérôme Marant ([EMAIL PROTECTED]) [061215 11:35]: Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit : As described in the developers reference: http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot However, apt sources don't seem to be too current there. If there is anything I can help you on my mipsel-machine, please say so. Andreas, Have you tried anything yet w.r.t. my last reply? Not yet, because my mipsel machine started to segfault, and currently I cannot ssh into it. I hope to be able to test it in the next 24 hours, though. Alright. Please keep us informed as soon as you have something working again. Thanks. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit : As described in the developers reference: http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot However, apt sources don't seem to be too current there. If there is anything I can help you on my mipsel-machine, please say so. Andreas, Have you tried anything yet w.r.t. my last reply? -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 12:52, Martin Michlmayr a écrit : fakeroot debian/rules autofiles-sync gives: ... test $(QUILT_PATCHES=debian/patches quilt top) = autofiles.diff QUILT_PATCHES=debian/patches quilt pop Removing patch autofiles.diff Restoring aclocal.m4 Restoring configure Now at patch ldapsearch-output.diff mkdir -p debian/tmp-autofiles/old tar cpSf - --exclude ./debian --exclude ./.pc . | tar -C debian/tmp-autofiles/old -xpSf - cp -a debian/tmp-autofiles/old debian/tmp-autofiles/new # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it # so ./Makefile won't be upset if it's not recreated (b/c not needed). cd debian/tmp-autofiles/new rm -f aclocal.m4 cd debian/tmp-autofiles/new touch aclocal.m4 cd debian/tmp-autofiles/new aclocal cd debian/tmp-autofiles/new autoconf autoconf: Undefined macros: configure.in:1351:AC_SYS_LARGEFILE configure.in:1442:AC_C_PROTOTYPES configure.in:1443:AC_C_VOLATILE configure.in:2040:AC_FUNC_MKTIME configure.in:2047:AC_FUNC_FSEEKO configure.in:29:AC_CONFIG_LIBOBJ_DIR(src) make: *** [autofiles-sync] Error 1 zsh: exit 2 fakeroot debian/rules autofiles-sync Hmm, some package might be missing. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 14:38, Andreas Barth a écrit : autoconf: Undefined macros: configure.in:1351:AC_SYS_LARGEFILE configure.in:1442:AC_C_PROTOTYPES configure.in:1443:AC_C_VOLATILE configure.in:2040:AC_FUNC_MKTIME configure.in:2047:AC_FUNC_FSEEKO configure.in:29:AC_CONFIG_LIBOBJ_DIR(src) make: *** [autofiles-sync] Error 1 zsh: exit 2 fakeroot debian/rules autofiles-sync Hmm, some package might be missing. Any hint which one that could be? What auto* do you use yourself? Those macros are part of autoconf. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 15:22, Stephen Gran a écrit : This one time, at band camp, Martin Michlmayr said: * Stephen Gran [EMAIL PROTECTED] [2006-12-15 14:10]: autoconf 2.60a-4 and autoconf2.13 2.13-58 are installed on my machine. Which one does /usr/bin/autoconf point to? autoconf --version Autoconf version 2.13 --- Autoconf 2.13 chosen by Debian wrapper script. Do you mind repointing it to the newer one, and seeing if it still FTBFS? FYI, it is not proper FTBFS. The autofiles-sync rule is run manually before building the package. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 15:56, Martin Michlmayr a écrit : * Martin Michlmayr [EMAIL PROTECTED] [2006-12-15 15:28]: Okay, it works after removing autoconf2.13. Let's see whether the package compiles... No, fails in the same way. Then I don't know. Why does it fail only on mipsel? As I said no patch has been applied to the C code nor anything related to it (like autotools). Dare I question the toolchain? -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le vendredi 15 décembre 2006 16:45, Martin Michlmayr a écrit : * Jérôme Marant [EMAIL PROTECTED] [2006-12-15 16:08]: Then I don't know. Why does it fail only on mipsel? As I said no patch has been applied to the C code nor anything related to it (like autotools). Dare I question the toolchain? I don't know. We're going to need to remove emacs from the mipsel release candidate package list then. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le mardi 12 décembre 2006 16:46, Andreas Barth a écrit : As described in the developers reference: http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot However, apt sources don't seem to be too current there. If there is anything I can help you on my mipsel-machine, please say so. Could you please perform a fresh unpacking of the package, and then try: cd emacs21-21.4a+1 fakeroot debian/rules autofiles-sync and build the package. Thanks in advance. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le jeudi 07 décembre 2006 02:20, Rob Browning a écrit : I suppose it's possible that that changing the series order might have broken something if I didn't re-run autofiles-sync after the move, but I thought I did. Hi Rob, Are you working on it ? -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le mardi 05 décembre 2006 10:18, Andreas Barth a écrit : Package: emacs21 Version: 21.4a+1-2 Severity: serious Hi, the build of emacs failed on mipsel. Please see http://buildd.debian.org/fetch.cgi?pkg=emacs21ver=21.4a%2B1-2arch=mipselstamp=1165216366file=log for the full build log. Rob, Didn't you break the autofiles, by chance? You told me you changed something in the autodiff patch? I'm just asking because on mipsel, X libraries fail to be autodetected from the configure script. The breakage could come from somewhere else though because it looks file on other architectures. -- Jérôme Marant
Bug#401665: FTBFS on mipsel
Le mardi 05 décembre 2006 10:18, Andreas Barth a écrit : Package: emacs21 Version: 21.4a+1-2 Severity: serious Hi, the build of emacs failed on mipsel. Please see http://buildd.debian.org/fetch.cgi?pkg=emacs21ver=21.4a%2B1-2arch=mipselstamp=1165216366file=log for the full build log. Hi, Nothing changed in that part of the code nor in build option or anything related and I was building just fine in 21.4a+1-1. -- Jérôme Marant
Bug#396875: tagging 396875
Selon Andreas Barth [EMAIL PROTECTED]: * Jérôme Marant ([EMAIL PROTECTED]) [061106 07:07]: [...] When do you plan to upload a fix for this bug? Or should I rather upload an NMU? I've already prepared a fix plus other fixes. Rob wants to upload the package himself, so I provided the necessary changes. I pinged him and I'm now waiting for him to do the upload. This is how it works. Cheers, -- Jérôme Marant
Bug#382686: Any news?
Hi, Is there any reason why this bug has not been fixed yet? Would it possible to fix it? Thanks in advance. -- Jérôme Marant
Bug#373253: Cause of g-i crashing on AMD64 at VT switch found
Le vendredi 24 novembre 2006 15:01, Attilio Fiandrotti a écrit : Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Try this by yourself - boot an amd64 image with DEBIAN_FRONTEND=newt - proceed with installation process until full libc6 is unpacked - wget libgcc_s.so.1 into the installer - export DEBIAN_FRONTEND=gtk - debian-installer now you should be able to chvt without crashing anymore. Thanks for finding this bug! I didn't know that you could change the frontend on the fly. So you interrupted it right after installing the libc and restarted after changing the frontend? -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le jeudi 09 novembre 2006 16:22, Attilio Fiandrotti a écrit : this is exactly what i do in order not to regenrate the iso every time i have to pull in something new and should work easily. Sorry if I'm late on this, but I'm not sure if I did it properly. Since I have to boot with the newt interface to run the snippet, I don't get the necessary libraries installed (gdk, directfb and so on). So, I mounted partitions of the system where I built it and ran it from this chroot. I switched VT's while the bar was progressing without any crash. Was it a correct procedure? -- Jérôme Marant
Bug#397159: Fwd: Re: Fwd: Problem with non-bmp unicode
Hi, Here is the reply from emacs developers. Cheers, -- Message transmis -- Subject: Re: Fwd: Problem with non-bmp unicode Date: dimanche 12 novembre 2006 03:32 From: Kenichi Handa [EMAIL PROTECTED] To: Jérôme Marant [EMAIL PROTECTED] Cc: emacs-devel@gnu.org In article [EMAIL PROTECTED], Jérôme Marant [EMAIL PROTECTED] writes: Do you have any clue about this? Sorry for the late reponse on this thread. Subject: Problem with non-bmp unicode Date: mercredi 08 novembre 2006 09:26 [...] An UTF-8 file (attached) with these three characters: U+0022 U+00010380 U+0022 shows with emacs -nw: \360\220\216\200 which is not usable at all. The file displays correctly if I cat it. I tried a bunch of other characters outside the BMP, all of which fail in the same way. Characters in the BMP work nicely. Emacs 22 still doesn't support Unicode characters over BMP. If you really need to handle them, please use the CVS branch emacs-unicode-2. Apparently, emacs 22 shows a question mark instead of \360\220\216\200 but trying to delete the question mark character with backspace turn it into \360\220\216. This is written in the comment of utf-8.el. ;; We compose the untranslatable sequences into a single character, ;; and move point to the next character. ;; This is infelicitous for editing, because there's currently no ;; mechanism for treating compositions as atomic, but is OK for ;; display. They are composed to U+FFFD with help-echo which ;; indicates the unicodes they represent. This function GCs too much. I tried to fix this editting problem by using modification-hooks text property, but couldn't accomplish a good result. --- Kenichi Handa [EMAIL PROTECTED] ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --- -- Jérôme Marant
Bug#340211: ADA-Mode: Symbol's function definition is void: ada-indent
Le vendredi 10 novembre 2006 03:11, Stephen Leake a écrit : The bug does not occur with the current version of ada-mode, available at http://stephe-leake.org/emacs/ada-mode/emacs-ada-mode.html I'm working on merging that into Emacs CVS, for the next release. Thank you! -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 19:01, Attilio Fiandrotti a écrit : Unfortunately, nothing changed. I can try to provide a new strace output, as soon as someone unbreaks rootskel. So far we stated this bug - cannot be reproduced on a regular debian system - does not look like it's related to the way DFB handles VT switching One more test: could you please compile the attached gtk application (which simply runs a progressbar), pull into the d-i, run it and switch VT while the progressbar runs to see if crashes? So, I need to boot the d-i with the newt installer, switch to another VT and run the program, right? BTW, how do you easily add a binary to the d-i? Thanks. -- Jérôme Marant
Bug#397159: emacs21: non-bmp unicode broken
Le mardi 07 novembre 2006 22:47, Taneli Vähäkangas a écrit : It has been fixed in Emacs 22. Sorry, I was too fast in my previous reply. When I try to delete the character in emacs 22, it will go back into old behavior and change the funny question mark back to four octets and delete one of them. I don't know if this is a debian issue any longer, but I don't think it is actually fixed-upstream. You are right. I removed the tag. I also forwarded your bug report upstream. Regards, -- Jérôme Marant
Bug#369355: emacs21: Please suggest python-mode
Le lundi 29 mai 2006 12:41, Moritz Muehlenhoff a écrit : Package: emacs21 Version: 21.4a-6 Severity: normal emacs21 should have a Suggests: python-mode Hi, I'd like to close this bug because I see no reason why it would suggest python-mode, since it does not suggest any other more either. Cheers, -- Jérôme Marant
Bug#397159: emacs21: non-bmp unicode broken
tags 397159 + fixed-upstream thanks Le lundi 06 novembre 2006 22:02, Taneli Vähäkangas a écrit : On Mon, Nov 06, 2006 at 04:15:17PM +0100, Jérôme Marant wrote: Le dimanche 05 novembre 2006 16:29, Taneli Vahakangas a écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal An UTF-8 file (attached) with these three characters: U+0022 U+00010380 U+0022 shows with emacs -nw: \360\220\216\200 which is not usable at all. The file displays correctly if I cat it. What do you mean with not usable? What would you expect? It should show the character U+00010380, like cat does. (See also: http://www.unicode.org/charts/PDF/U10380.pdf ) It is not usable, because I can't for example erase that character by pressing backspace once; instead I need to know that the character is represented by four octets, and remove all those. Given a string of such characters, it becomes impossible to tell where one character ends and another starts. It has been fixed in Emacs 22. Cheers, -- Jérôme Marant
Bug#355874: Bug #355874
Hi, This does not look a bug to me. # shall not be interpreted within a double redirection section. Cheers, -- Jérôme Marant
Bug#381484: Bug #381484
Le mardi 07 novembre 2006 15:14, Henrik Holmboe a écrit : Jérôme_Marant [EMAIL PROTECTED] wrote: Henrik, Does the patch you posted works better than this new ldap.el? If so, I intend to apply it ASAP. It does work better for me, but it is not clear to me why. I have tried to merge small changesets back and forth between the patches to figure out what is causing this. Unfortunately I havent been lucky to find the problem yet. I tried both your patch and the new ldap.el and ldap-search always return (nil). It tried with the parameters as described at http://people.debian.org/~aba/bts2ldap/ What did you get in your experiments? I intend to have a look at this further as time permits. On wednesday at earliest. Do as you see fit if you need to push this change earlier. I'd prefer to apply your patch since you reported it to work. At least, it would be better than the current broken ldap. -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 14:30, Attilio Fiandrotti a écrit : Jérôme Marant wrote: Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : Jerome, if i provide a simple patch for DFB 0.9.25, could you please rebuild the libdirectfb-udeb and see if the crash is fixed? In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: would this be possible if fixes this chash? Of course. hi jerome Attached to this mail you will find a patch that moves DFB's 0.9.25.1 signal handling to different signals than SIGUSR1/2 (during my tests, those were replaced to signals number 41 and 42 and everything worked correctly). thanks in anticipation for testing. I rebuilt libdirectfb udeb with your patch and re-generated the miniiso. Unfortunately, nothing changed. I can try to provide a new strace output, as soon as someone unbreaks rootskel. -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le mercredi 01 novembre 2006 12:02, Attilio Fiandrotti a écrit : Hi Jerome Hello, Sorry for the late reply, I've been away for few days. First, thank you for spending time working on the crash at VT switch on AMD64: fixing this bug is really important for the g-i project. You're welcome. I'm pleased if I can help. I've just cloned your original BR as bug 396520 [1] to separate from the french keyboard issue, retitled it, assigned to the directfb package and merged with one by davide. Thanks. I've cc'ed d-boot this time, but feel free to drop them in future replies. ... While an application is running, please switch to vt1 (ctrl-alt-f1) and then back to vt7 to see if you can crash your AMD64 system with a pure DirectFB (no gtk) application. What kind of crash are you expecting? Are you expecting the whole system to be down? In the case you should succeed in crashing the application and the console should become unresonding, you can connect from ssh and issue a chvt 7 to get back to X. I ran a lot of them and I could switch back and forth from vt1 to vt7. Nothing crashed at all. BTW, Looking at the strace output, the problem could come from signal usage, like you said. I hope this helps. Regards, -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : Jerome, if i provide a simple patch for DFB 0.9.25, could you please rebuild the libdirectfb-udeb and see if the crash is fixed? In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: would this be possible if fixes this chash? Of course. Using different signals for cdebconf db saving and DFB vt switching is good, but still cdebconf's signal handling mechanism may need to be fixed. How does it need to be fixed? Won't using different signal fix the issue? -- Jérôme Marant
Bug#381484: Bug #381484
Le samedi 28 octobre 2006 13:51, Henrik Holmboe a écrit : Jérôme Marant [EMAIL PROTECTED] writes: Could you please test if this upstream version would work for you? http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/emacs/lisp/net/ldap.el?rev=1.24 I have now tried the new ldap.el and it seems to not parse results correctly from the LDAP-server. When I search for henrik* from Gnus, it returns no match. According to the logfile from slapd it does find 1 match on both givenName and mail. Henrik, Does the patch you posted works better than this new ldap.el? If so, I intend to apply it ASAP. Thanks. -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 14:51, Attilio Fiandrotti a écrit : How does it need to be fixed? Won't using different signal fix the issue? Using different signals should fix up this specific crash, but basing on this BR [1] by colin watson cdebconf's signal handling mechanism is not very robus and needs to be fixed. If you have some time, could you please boot textual and send to cdebconf SIGUSR1 and SIGUSR2 signals, to see if it crashes? It crashes on SIGUSR2. It is OK with SIGUSR1. Regards, -- Jérôme Marant
Bug#396616: emacs21: Upgrade stops me quitting Emacs; gives invalid bytecode error
Le mercredi 01 novembre 2006 16:04, Reuben Thomas a écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal After the last upgrade of emacs21 in testing, and as on several previous occasions, I couldn't quit my running Emacs because of an invalid bytecode error. I presume there's some generic underlying problem here (bytecode file versioning?) which I don't expect Debian to solve, but having a debconf warning when Emacs is upgraded that I should first shut down running Emacsen would be nice. Hi, I've never experienced that. Could you please try after re-installing it? Thanks. -- Jérôme Marant
Bug#397159: emacs21: non-bmp unicode broken
Le dimanche 05 novembre 2006 16:29, Taneli Vahakangas a écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal An UTF-8 file (attached) with these three characters: U+0022 U+00010380 U+0022 shows with emacs -nw: \360\220\216\200 which is not usable at all. The file displays correctly if I cat it. What do you mean with not usable? What would you expect? Thanks -- Jérôme Marant
Bug#396616: emacs21: Upgrade stops me quitting Emacs; gives invalid bytecode error
Le lundi 06 novembre 2006 16:13, Reuben Thomas a écrit : On Mon, 6 Nov 2006, Jérôme Marant wrote: I've never experienced that. Could you please try after re-installing it? I'm not quite clear what you want me to do. Do you mean start emacs, reinstall emacs21, try to quit emacs? What happens when you quit emacs21 and re-install emacs21 and run it again? Because it is the right thing to do. Upgrading it while running will have unexpected results. -- Jérôme Marant
Bug#396854: emacs21-common-non-dfsg
close 396854 thanks The bug report can be closed then. Regards, Le lundi 06 novembre 2006 15:45, Valery V. Vorotyntsev a écrit : It was a problem with my Debian mirror. (As far as I understand, the list of non-free packages was missing but no error was returned to apt-get update.) Sorry for inconvenience. Thank you, Rob. VVV -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mardi 24 octobre 2006 13:30, Davide Viti a écrit : Whenever you change something, you regenerate th udeb then the mini iso and boot it, right? yes FYI, I sent a message to the directfb ML: http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html Since I can't use dead keys with i386 either , i used this version so I can switch to a VT at least. I got the following error after trying to use dead keys: DirectFB/FBDev: Panning display failed! -- Invalid argument Google does not give any concrete answers but bug reports. BTW, I think it does not matter if directfb makes use of MEDIUMRAW mode. What matters is how gdk-directfb converts it to UTF-8. Regards, -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le lundi 30 octobre 2006 18:05, Attilio Fiandrotti a écrit : Yesterday, talking with fjp, we noticed that the AltGr-o key combination correctly produces an o+^ character, which is something correct [EMAIL PROTECTED]:~$ zcat /usr/share/keymaps/i386/azerty/fr-latin9.kmap.gz |more # Copyright (c) 1997, 1998 Guylhem Aznar guylhem @ oeil.qc.ca : GPL # Copyright (c) 1997 Pierre-Charles David pcdavid @ club-internet.fr # # Les accents circonflexes des principales voyelles sont obtenus avec # la touche Alt_Gr, les trémas sont obtenus par Alt_Gr + Shift. Jerome, could you please test if AltGr-o under fr-latin9 produces a o+^ letter with your keyboard too ? Yes, it works. I used it while dead keys where not working. But it is a work around right? Dead keys should be working. -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le dimanche 29 octobre 2006 17:06, Frans Pop a écrit : But it does not work either. Am I doing something wrong? One possibility is that the code after starting the menu is not run for some reason. I think it is because I get the reboot few seconds after hitting C-A-F2. Did you also include the drivers needed to access the USB stick in the image? I didn't. I'm going to. It's probably easier to mount the partition before starting the strace and writing the log directly to it. The problem is that /dev entries need to be available in order for the partition to be mounted, hence the problem. When are they created? One other thing to be aware of is that the frontend will be restarted by inittab after a crash and possibly that could overwrite an earlier trace. You may want to disable that. Well, I already thought about this. I was first writing to cdebconf.trace.$$ so the trace won't get overwritten. Then, I added an entry to finish-install dedicated at moving all traces to the partition. Unfortunately, it made the installer freeze, even before hitting C-A-F2: I guess traces filled the ramdisk till out of space far before reaching the end of the install. Note that you should be able to tweak things by booting the installer with BOOT_DEBUG=3. This will give you two debug shells before init is run. Thanks. -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mercredi 25 octobre 2006 20:47, Davide Viti a écrit : On Tue, Oct 24, 2006 at 02:27:52PM +0200, Jérôme Marant wrote: http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html OK. Does it give clues? I'm not really skilled in this field. not much since I'm not very skilled in this either BTW, I was told not being able to switch to another VT2 on amd64 is caused by a segfault. Where does it happen? refer to #373253 ; noone has provided backtrace logs or such yet I tried that but I can't find a way to save traces. So I did in rootskel/src/lib/debian-installer/menu: -- strace -f -s 4096 -o /tmp/cdebconf.trace debconf -o d-i $MENU modprobe ext3 mount -t ext3 -o rw /dev/sda1 /mnt cp /tmp/cdebconf.trace /mnt umount /mnt reboot -- My /dev/sda1 is a ext3 partition. I added the ext3 udeb to installer/build/pkg-lists/netboot/gtk/amd64.cfg But it does not work either. Am I doing something wrong? Thanks. -- Jérôme Marant
Bug#381484: Bug #381484
Le samedi 28 octobre 2006 13:51, vous avez écrit : Jérôme Marant [EMAIL PROTECTED] writes: Could you please test if this upstream version would work for you? http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/emacs/lisp/net/ldap.el?rev=1.24 I have now tried the new ldap.el and it seems to not parse results correctly from the LDAP-server. When I search for henrik* from Gnus, it returns no match. According to the logfile from slapd it does find 1 match on both givenName and mail. This is clearly not a problem with binding and so on. I have tried to adapt the parsing inside the code at 589, but no solution found. I will try some more, though if you can spot the problem please say. Thanks for testing. Does your patch work better? If so, I'll apply it instead using the one from the CVS trunk. Cheers, -- Jérôme Marant
Bug#395501: emacs21: M-x yow signals an error
Le vendredi 27 octobre 2006 14:20, vous avez écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal M-x yow signals an error, here is the backtrace: Debugger entered--Lisp error: (args-out-of-range [Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED!] 1) cookie(/usr/share/emacs/21.4/etc/yow.lines Am I CONSING yet?... I have SEEN the CONSING!!) yow(nil) * call-interactively(yow) execute-extended-command(nil) * call-interactively(execute-extended-command) Seems emacs21' yow.el is not compatible with emacs-snapshot's yow.lines. Hopefully emacs-snapshot's yow.el is not radically different from emacs21's so it should be fairly easy to patch. Thanks Sven! -- Jérôme Marant
Bug#395501: emacs21: M-x yow signals an error
Le vendredi 27 octobre 2006 14:20, vous avez écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal M-x yow signals an error, here is the backtrace: Debugger entered--Lisp error: (args-out-of-range [Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED!] 1) cookie(/usr/share/emacs/21.4/etc/yow.lines Am I CONSING yet?... I have SEEN the CONSING!!) yow(nil) * call-interactively(yow) execute-extended-command(nil) * call-interactively(execute-extended-command) Seems emacs21' yow.el is not compatible with emacs-snapshot's yow.lines. Well, at first glance it looked obvious but it's not. How can I go further than cookie in the backtrace? Thanks. -- Jérôme Marant
Bug#395501: emacs21: M-x yow signals an error
Le vendredi 27 octobre 2006 14:20, vous avez écrit : Package: emacs21 Version: 21.4a+1-1 Severity: normal M-x yow signals an error, here is the backtrace: Debugger entered--Lisp error: (args-out-of-range [Yow! Legally-imposed CULTURE-reduction is CABBAGE-BRAINED!] 1) cookie(/usr/share/emacs/21.4/etc/yow.lines Am I CONSING yet?... I have SEEN the CONSING!!) yow(nil) * call-interactively(yow) execute-extended-command(nil) * call-interactively(execute-extended-command) Seems emacs21' yow.el is not compatible with emacs-snapshot's yow.lines. Err, me again :-P It is a combination of both cookie1.el and yow.el updates. Sorry for the noise. -- Jérôme Marant
Bug#395501: emacs21: M-x yow signals an error
Le vendredi 27 octobre 2006 15:23, vous avez écrit : Sven Joachim [EMAIL PROTECTED] writes: M-x yow signals an error, here is the backtrace: [...] Seems emacs21' yow.el is not compatible with emacs-snapshot's yow.lines. It probably needs this patch, which was installed upstream at the time: It is exactly what I did. -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le lundi 23 octobre 2006 23:35, Davide Viti a écrit :
I see; you can use the very same iso and boot using install
DEBIAN_FRONTEND=newt and
eventually append also priority=medium
I just had to hit Return because it makes use of newt by default.
BTW, I can help debugging that VT issue if you tell me where
I shall look into.
well, it's not yet clear what is going on;
I've noticed the following :
when loading the keymap using the graphical frontend, you get the
following warnings:
INFO: kbd_chooser: setting keymap fr-latin9
WARNING **: : assuming iso-8859-1 cedilla
WARNING **: : assuming iso-8859-1 acute
WARNING **: : assuming iso-8859-1 diaeresis
WARNING **: : assuming iso-8859-1 brokenbar
WARNING **: : assuming iso-8859-1 threequarters
WARNING **: : assuming iso-8859-1 currency
WARNING **: : assuming iso-8859-1 onehalf
WARNING **: : assuming iso-8859-1 onequarter
and those are printed only if kbd_mode is different from 3
(K_UNICODE, from linux/kd.h); using some extra logs I noticed that
kbd_mode is 2 (K_MEDIUMRAW) when running the graphical frontend
and looking at the directfb sources (inputdrivers/keyboard/keyboard.c)
if (ioctl( dfb_fbdev-vt-fd, KDSKBMODE, K_MEDIUMRAW ) 0) {
D_PERROR( DirectFB/Keyboard: K_MEDIUMRAW failed!\n );
...
info-desc.max_keycode = 127;
I've tried to change that into K_UNICODE and s/127/255/
the warnings disappear, but I can't get the accented letters I get on VT2
(for example [+e give me ê when I use fr-latin9 on my italian keyboard)
Whenever you change something, you regenerate th udeb then the mini iso
and boot it, right?
--
Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Le mardi 24 octobre 2006 13:30, vous avez écrit : Whenever you change something, you regenerate th udeb then the mini iso and boot it, right? yes FYI, I sent a message to the directfb ML: http://mail.directfb.org/pipermail/directfb-dev/2006-October/002394.html OK. Does it give clues? I'm not really skilled in this field. BTW, I was told not being able to switch to another VT2 on amd64 is caused by a segfault. Where does it happen? -- Jérôme Marant
Bug#394871: cdebconf-gtk-udeb: Dead keys do not work with French keyboard (fr-latin9)
Package: cdebconf-gtk-udeb Severity: normal Hi, With latest debian-installer netinst iso (20061023), I could not manage to get dead keys work to type accents (especially ô) in the user name, before entering the login. I tried other dead keys without any success. I was using a fr-latin9 keymap. Regards, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Jérôme Marant
Bug#381484: Bug #381484
Hi, Could you please test if this upstream version would work for you? http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/emacs/lisp/net/ldap.el?rev=1.24 Otherwise, I'll send your changes upstream. Thanks. -- Jérôme Marant
Bug#392547: konqueror crash
Le jeudi 12 octobre 2006 23:56, Marc Haber a écrit : On Thu, Oct 12, 2006 at 11:49:30PM +0200, Jérôme Marant wrote: FYI, you can install kde*-dbg packages, which allow you to get more informative backtraces. They are installed. My assumption was wrong then. Your backtraces looked less informative than mine, this is why. -- Jérôme Marant
Bug#392547: konqueror crash
Hi Marc, With konqueror 3.5.5a I got the following backtrace. Same symptom, but not crashing at the same location. FYI, you can install kde*-dbg packages, which allow you to get more informative backtraces. Cheers, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47794041415520 (LWP 9497)] 0x2b77e92d77f8 in QGDict::look_ascii (this=0x506230, key=0x2b77e93b54cf cleanupEventFilter(QObject*), d=0x0, op=0) at tools/qgdict.cpp:371 371 tools/qgdict.cpp: Aucun fichier ou répertoire de ce type. in tools/qgdict.cpp (gdb) bt #0 0x2b77e92d77f8 in QGDict::look_ascii (this=0x506230, key=0x2b77e93b54cf cleanupEventFilter(QObject*), d=0x0, op=0) at tools/qgdict.cpp:371 #1 0x2b77e8fec66f in QAsciiDictQMetaData const::find (this=0x506230, k=0x2b77e93b54cf cleanupEventFilter(QObject*)) at ../include/qasciidict.h:71 #2 0x2b77e8fe9ec5 in QMetaObject::findSlot (this=0x5061c0, n=0x2b77e93b54cf cleanupEventFilter(QObject*), super=true) at kernel/qmetaobject.cpp:454 #3 0x2b77e8fe9f55 in QMetaObject::findSlot (this=0x5605e0, n=0x2b77e93b54cf cleanupEventFilter(QObject*), super=true) at kernel/qmetaobject.cpp:459 #4 0x2b77e8fe9f55 in QMetaObject::findSlot (this=0x7440f0, n=0x2b77e93b54cf cleanupEventFilter(QObject*), super=true) at kernel/qmetaobject.cpp:459 #5 0x2b77e8ffa8f7 in QObject::connect (sender=0xac6710, signal=0x2b77e9459565 destroyed(QObject*), receiver=0x7011ff0, member=0x2b77e93b54cf cleanupEventFilter(QObject*)) at kernel/qobject.cpp:1775 #6 0x2b77e8ffb243 in QObject::installEventFilter (this=0x7011ff0, obj=0xac6710) at kernel/qobject.cpp:1388 #7 0x2b77ecc3408a in KHTMLView::eventFilter (this=0xac6710, o=0xac6e70, e=0x7030ae0) at /tmp/buildd/kdelibs-3.5.5a/./khtml/khtmlview.cpp:1837 #8 0x2b77e8ff7e49 in QObject::activate_filters (this=0xac6e70, e=0x7030ae0) at kernel/qobject.cpp:903 #9 0x2b77e8ff7ec2 in QObject::event (this=0xac6e70, e=0x7030ae0) at kernel/qobject.cpp:735 #10 0x2b77e902cceb in QWidget::event (this=0xac6e70, e=0x7030ae0) at kernel/qwidget.cpp:4678 #11 0x2b77e8f93f52 in QApplication::internalNotify (this=0x7fffc49824f0, receiver=0xac6e70, e=0x7030ae0) at kernel/qapplication.cpp:2635 #12 0x2b77e8f9680b in QApplication::notify (this=0x7fffc49824f0, receiver=0xac6e70, e=0x7030ae0) at kernel/qapplication.cpp:2523 #13 0x2b77e814b6de in KApplication::notify (this=0x7fffc49824f0, receiver=0xac6e70, event=0x7030ae0) at /tmp/buildd/kdelibs-3.5.5a/./kdecore/kapplication.cpp:550 #14 0x2b77e8f277b2 in QApplication::sendEvent (receiver=0xac6e70, event=0x7030ae0) at ../include/qapplication.h:520 #15 0x2b77e8f94f65 in QApplication::sendPostedEvents (receiver=0xac6e70, event_type=70) at kernel/qapplication.cpp:3299 #16 0x2b77e902f51c in QWidget::show (this=0x7011ff0) at kernel/qwidget.cpp:3978 #17 0x2b77eccead72 in khtml::RenderLayer::showScrollbar (this=0x1195360, o=Qt::Vertical, show=value optimized out) at /tmp/buildd/kdelibs-3.5.5a/./khtml/rendering/render_layer.cpp:616 #18 0x2b77ecd423f1 in khtml::RenderLayer::checkScrollbarsAfterLayout (this=0x1195360) at /tmp/buildd/kdelibs-3.5.5a/./khtml/rendering/render_layer.cpp:759 -- Jérôme Marant
Bug#389409: emacs21: problem loading utf-8 files
Le lundi 25 septembre 2006 17:03, Jiri Palecek a écrit : Package: emacs21 Severity: minor Hello, when I upgraded my emacs, loading utf-8 files stopped working. I use Czech language environment. When I chose describe language environment from the menu, utf-8 is listed far in the back of coding systems list, even below binary (!). Isn't that a problem? Hi, Sorry for the late reply. What does your $LANg look like? If it is not an UTF-8 locale, I guess you need the following in your .emacs: (prefer-coding-system 'utf-8) I also have this in my .emacs: (set-language-environment UTF-8) (set-terminal-coding-system 'utf-8) (set-keyboard-coding-system 'utf-8) I hope this help, -- Jérôme Marant
Bug#378427: removal of bluez-pin? (was Re: Bug#378427: needs to be updated to libbluetooth2)
Le samedi 30 septembre 2006 23:28, Filippo Giunchedi a écrit : On Fri, Sep 29, 2006 at 10:01:33PM +0200, JJJrrrme Marant wrote: Hi, Is anyone taking care of this? bluez-pin is now obsoleted by the new bluez (=3.x) which uses a dbus interface to request pin. See my ITP for bluez-gnome which is going to provide a replacement. bluez-pin should be removed from unstable. Thanks. -- Jérôme Marant
Bug#378427: needs to be updated to libbluetooth2
Hi, Is anyone taking care of this? Thanks. -- Jérôme Marant
Bug#352368: gnat-gps: AMD64 port?
Le mardi 29 août 2006 14:58, Ludovic Brenta a écrit : Hi Jérome, The good news is that I'm almost finished with the packaging of libgtkada2 2.8.1; gnat-gps is next in my priority list. Good! The bad news is that I'm out of ADSL until Sept 11 at least, possibly a few days after that. I'll upload in september. Thank you for giving an update! It is no problem for me to wait :-) Take care, -- Jérôme Marant
Bug#352368: gnat-gps: AMD64 port?
Hi Ludovic, I wanted to give GPS a try but I realized it was not available on amd64. Could you please add it to the architecture list please, so it gets build on amd64? At least, the sooner we find problems with it, the better for etch. It dependencies (like gtkada2) will have to be built for amd64 as well (I tried to build gtkada2 but #380587 stuck me). Thanks in advance! -- Jérôme Marant
Bug#379231: klibido: Build failures with GCC 4.1
close 379231 thanks Jerome Marant [EMAIL PROTECTED] writes: Package: klibido Version: 0.2.5-2 Severity: important Hi, Klibido fails to build with gcc 4.1. I'm sorry it has already been fixed but I built klibido from upstream source while debugging #379232, so I did not notice the previous upload fixed it. Cheers, -- Jérôme Marant
Bug#366235: Kaffeine crashes when trying to read .asx file
Fathi Boudra [EMAIL PROTECTED] writes: tags 366235 moreinfo unreproducible thank... hi, i tried the asx file that you provided and kaffeine played it without crashing. Could you provide more infos to reproduce the bug ? It seems to work again. I suspect some KDE libs have been updated since the bug report. Thanks. -- Jérôme Marant
Bug#207932: To be fixed, truce, peace
Quoting Janusz S. Bieñ [EMAIL PROTECTED]: Self-Documentating has nothing to do with info manuals. It is about docstrings: they will still be around, within the DOC file. You are of course right in the technical and literal sense. However I still believe that separating the info files from the program is against the spirit of Emacs. Removing manuals is always a loss. I also think it is not satisfactory. Bear in mind that many projects provide GFDL docs with no invariant sections, and those docs will thus be kept in main. If only we were allowed to remove those invariant sections (not necessarily to be able to modify them since they are essays), manuals would stay in main. -- Jérôme Marant
Bug#207932: Consequences of moving Emacs Manuals to non-free
Quoting Sven Joachim [EMAIL PROTECTED]: [ CC'ing debian-emacsen, as this should be of interest for Emacs users and developers. Also, I would like to read other people's opinion about this.] JÃ(c)rôme Marant wrote: Since the FDL documents contain invariant sections, they will have to be moved to non-free very soon. When you do this, please consider the consequences for Emacs' usability. The Project has decided that invariant sections were unacceptable. You could help us by talking to GNU people and asking them to remove those invariant sections from their documentation. Removing the manual leaves only a bare minimum for learning Emacs (the tutorial, basically) and has a great impact even for experienced users Newbies usually don't use Emacs. Experienced users are smart enough to add non-free to their source.list APT file, and grab docs from there. Were are talking about the info documentation. who know how to get information out of docstrings and the like. I would go as far as saying that Emacs is unusable without the manual. If you agree with that, you should make the emacs21 packages depend on (or at least, recommend) the non-free manual; of course, that implies moving the emacs21 package and everything that depends on it (rather than on emacsen) to contrib. I would prefer a dependency over a recommendation, to ensure that users are not left stuck with an undocumented Emacs. I think that docs are going to be moved to an emacs-docs package and emacs21 will suggest it. I don't think it should go to contrib. Note that the same consideration applies to emacs-snapshot and the upcoming emacs22 release. So, I'll propose to move those essays to non-free as well at the same time in order to avoid changing the orig tar as much as possible. If you disagree with my above reasoning that emacs21 should depend on the non-free bits, this calls for a modification of help.el and startup.el, i.e. the functions `describe-project' and `startup-echo-area-message'. Otherwise, people might be in for a nasty surprise when they type C-h C-p. Oh, and several commands that look up documentation in the manual will not work at all. Does C-h C-p points to the documentation (info documentation) or to the DOC file ? I guess some patches will have to be added to handle such cases, yes. I'm sorry you don't like this. I'm not really fond of it either, but I have the choice of either do what the Project decided or resign from the Project. I've chosen the former. -- Jérôme Marant
Bug#207932: To be fixed, truce, peace
[EMAIL PROTECTED] (Janusz S. Bień) writes: Removing one of the very first free programs from Debian would be definitely a milestone in Debian history. Yes, it is. However, the doc will still be around, in non-free. or to remove the maintainer from the package. It's a pity that Debian project seems now to be dominated by fanatics. I've already commented on this, and probably been to harsh about it (I'm talking about the essays, not the GFDL docs) I'd like to move on now. Since the FDL documents contain invariant sections, they will have to be moved to non-free very soon. Again, a pity. Debian decided that invariant sections were not acceptable. So, I'll propose to move those essays to non-free as well at the same time in order to avoid changing the orig tar as much as possible. Shall we make a truce, a peace even, Or make Emacs package unofficial :-). Personally I wouldn't care. Best regards and thanks for your work on Emacs packaging. Will grabbing documentation from non-free will be a mjor inconvenience for you? I'm not so sure. -- Jérôme Marant
Bug#207932: To be fixed, truce, peace
Quoting Janusz S. Bieñ [EMAIL PROTECTED]: On Tue, 14 Mar 2006 Jérôme Marant [EMAIL PROTECTED] wrote: [...] Will grabbing documentation from non-free will be a mjor inconvenience for you? I'm not so sure. I will manage, but the integration of documentation with the program seems to me an intrinsic feature of Emacs. Remember this is The Extensible, Customizable, *Self-Documenting* Display Editor. Self-Documentating has nothing to do with info manuals. It is about docstrings: they will still be around, within the DOC file. -- Jérôme Marant
Bug#207932: To be fixed, truce, peace
Nathanael, I noticed this comment from in debian-release: Package: emacs21 (optional; Rob Browning) [emacs21/21.4a-3 ; =] [add/edit comment] 207932 [ ] [NONFREE-DOC:UNMODIFIABLE] emacs21: Includes non-free documents These are not FDL documents, they're just plain unmodifiable documents, and it's quite clear they're intended to be that way. The maintainer here has so far refused to address the bug at all. I believe it is past time to remove emacs21 from etch, or to remove the maintainer from the package. Since the FDL documents contain invariant sections, they will have to be moved to non-free very soon. So, I'll propose to move those essays to non-free as well at the same time in order to avoid changing the orig tar as much as possible. Shall we make a truce, a peace even, and move on? -- Jérôme Marant
Bug#207932: Time to fix this bug.
Quoting Nathanael Nerode [EMAIL PROTECTED]: Jérôme Marant wrote: Sooner or later, Debian will have to decide if it definitely wants to leave the project in the hands of extremists. I hope the GR will lead us to the right path, that is getting rid of fundamentalists. If Debian goes down your we don't give a damn about freedom path, I plan to introduce lots of exciting non-modifiable software to main. That would be fun. I would not be surprised. You are constantly trying to undermine the Debian project. -- Jérôme Marant
Bug#207932: Time to fix this bug.
Quoting Nathanael Nerode [EMAIL PROTECTED]: You don't have any kind of authority, as far as I know. I didn't say I did. I quoted like debian-legal tells me it needs to be done, and noted that debian-legal had in fact said that. A clear majority at any rate. That's all. debian-legal is no majority. there's a successful General Resolution passed on a relevant topic, That's happened. Do you need another, even more specific, one? If you do, I'll be happy to oblige if I ever get through NM. I notice your lack of comment on this. Because I don't owe you a comment on this. or they're removed from the upstream... Well, that's not happening right now it looks like. :-P Please remove these from 'main' ASAP. Thank you. They can be placed in a package in non-free if you wish, as they appear to have licenses which make them distributable. It would be good to get this done as soon as possible, so that there is a releaseable version of emacs in etch. It is already releasable, thanks. Sorry, it's not. Please note that it has an RC bug filed against it. You do know what RC means, right? This bug shall be closed because it is irrelevant, whether it is RC or not. So, there's not point arguing. Alternatively, you could initiate a GR to overrule the Social Contract with respect to these works. Oh, FYI, don't pay too much attention to Michael Edwards. He has misinterpreted the meaning of the integrity of the work provisions in We do pay attention to Michael. We even agree with him. Sad. 'Cause he's propounding bad legal advice. He's not an extremist at least. I trust him for this reason. .. I stand that removing those documents will not make Emacs more free than it is nowdays. Well, you can stand by whatever you want, but not having any arguments to back it up makes it rather unconvincing. I'll repeat that I don't owe you any argument. It is all about common sense, but you don't seem to get it. Extremists and ideologists have never known anything about common sense and _this_ is _proven_. I'm not ready to leave Debian in the hands of ideologists and extremists, partisants of my way or the highway and such kind of Free software morality crusaders. I'm all against the dictatorship of minorities. You are an extremist, a fundamentalist, with no bits of common sense at all. OK, that's both an ad hominem attack, and was given with no evidence. I'm sad I have to use such words but I don't think there is anything else to say. It is based on your interventions on debian-legal. I don't have to give evidence, you already have. You aren't helping anyone, not even the Debian Project. OK, that's partly an ad hominem attack, but worse, it is provably false. I am not the only one who gains direct benefit from having a clear, obvious division -- main exclusive of license texts -- between material satisfying the DFSG and that which doesn't. It is an extreme view of the DFSG, I call this fundamentalism. -- Jérôme Marant
Bug#207932: Time to fix this bug.
Quoting Nathanael Nerode [EMAIL PROTECTED]: Romain Francoise wrote: Nathanael Nerode [EMAIL PROTECTED] writes: Please remove these from 'main' ASAP. Don't: URL: http://www.debian.org/vote/2006/vote_001 That's not directly relevant, since it's about the GFDL, and this bug isn't. I suppose it would be sort of relevant if the Invariant Sections are Just Fine option passes, since this is about unmodifiable stuff. Trust me, if that passes, you'll see a lot of unmodifiable stuff going into main. I seriously doubt it will pass; if you really want to wait to see, however, fine with me. Sooner or later, Debian will have to decide if it definitely wants to leave the project in the hands of extremists. I hope the GR will lead us to the right path, that is getting rid of fundamentalists. -- Jérôme Marant
Bug#207932: Time to fix this bug.
Nathanael Nerode [EMAIL PROTECTED] writes: And for whatever it's worth, as long as I'm maintaining the packages, these files will almost certainly not be removed unless there's some overwhelmingly convincing reason, like debian-legal tells me it needs to be done, We've done that. You don't have any kind of authority, as far as I know. there's a successful General Resolution passed on a relevant topic, That's happened. Do you need another, even more specific, one? If you do, I'll be happy to oblige if I ever get through NM. or they're removed from the upstream... Well, that's not happening right now it looks like. :-P Please remove these from 'main' ASAP. Thank you. They can be placed in a package in non-free if you wish, as they appear to have licenses which make them distributable. It would be good to get this done as soon as possible, so that there is a releaseable version of emacs in etch. It is already releasable, thanks. Alternatively, you could initiate a GR to overrule the Social Contract with respect to these works. Oh, FYI, don't pay too much attention to Michael Edwards. He has misinterpreted the meaning of the integrity of the work provisions in We do pay attention to Michael. We even agree with him. Jerome Marant's claim that the articles are logically non modifiable without the consent of their author is wrong, and is apparently due to the same point of confusion which also comes up when we discuss making standards documents modifiable: you can't modify the original, but you should be allowed to create a derivative work, a modified copy. Consider the Declaration of Independence and these famous modified versions: the Declaration of Sentiments, and the Declaration of the Rights of Man. The modifications did not change the original Declaration of Independence. Modified versions of these essays and speeches would likewise not change RMS's words, and would not pretend to be RMS's words. They would be different essays which used some of RMS's rhetoric and style. I stand that removing those documents will not make Emacs more free than it is nowdays. You are an extremist, a fundamentalist, with no bits of common sense at all. You aren't helping anyone, not even the Debian Project. So just please go away and find yourself another sandbox. -- Jérôme Marant
Bug#343114: Menu files for eclipse
Michael Koch [EMAIL PROTECTED] writes: tag 343114 confirmed pending thanks On Sat, Dec 17, 2005 at 08:49:21PM +0100, J?r?me Marant wrote: Michael Koch [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 07:24:05PM +0100, J?r?me Marant wrote: Hi, Here are the necessary files. Thanks, this helps a lot. I will commit a fix for this bug to our CVS later and tag this bug accordingly. The fix will then be included in the 3.1.1-7 upload of eclipse. Thank you! I just installed Eclipse today. You all did very good job. The fix is commited to our CVS now. I think it would be wise to keep the desktop entry as well because people using either Gnome or KDE make use of such entries in favour of the Debian menu entry. The Debian menu entry is necessary for anyone not using a desktop environment because there is no desktop entry available. -- Jérôme Marant
Bug#343114: Menu files for eclipse
Hi, Here are the necessary files. Regards, eclipse-platform-common.menu Description: Binary data eclipse32.xpm Description: X pixmap -- Jérôme Marant
Bug#343114: Menu files for eclipse
Michael Koch [EMAIL PROTECTED] writes: On Sat, Dec 17, 2005 at 07:24:05PM +0100, J?r?me Marant wrote: Hi, Here are the necessary files. Thanks, this helps a lot. I will commit a fix for this bug to our CVS later and tag this bug accordingly. The fix will then be included in the 3.1.1-7 upload of eclipse. Thank you! I just installed Eclipse today. You all did very good job. Regards, -- Jérôme Marant
Bug#335712: sh-script.el: coloring inconsistency with a zsh script
Hi, (Sorry for the late reply, again) The then keyword is being colored differently because you forgot the ; after ]]. I don't know why the two x are colored differently though. Going to ask upstream. Regards, -- Jérôme Marant
Bug#165814: #165814
Hi Frank, Shall we consider #165814 (and maybe #150374 and #284216) as closed? Thanks in advance. Regards, -- Jérôme Marant
Bug#290006: emacs21: view-emacs-FAQ doesn't work
Hi, C-h F seems to work fine and properly shows the Emacs FAQ. /usr/share/info/dir contains (emacs-21/efaq) as expected. Do you still have the problem? Thanks. Regards, -- Jérôme Marant
Bug#335712: sh-script.el: coloring inconsistency with a zsh script
Vincent Lefevre [EMAIL PROTECTED] writes: On 2005-12-11 14:33:54 +0100, Jérôme Marant wrote: The then keyword is being colored differently because you forgot the ; after ]]. I didn't forget it since the ; is useless after ]]. [[ ... ]] is a special syntax recognized by zsh, with its own rules (patterns inside [[ ... ]] are handled differently and so on). But note that this is not the case of [ ..., as [ is a normal command (though also implemented as a builtin). It is not specific to zsh since bash supports it as well (man bash documents it) but the difference is that zsh does not require the ; after ]] which bash does. I'm going to report it upstream. Thanks. Regards, -- Jérôme Marant
