Bug#772273: unblock: upgrade-system/1.7.2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package upgrade-system
As reported in Bug#772271, packages that skip their DPKG triggers make DPKG
leave their status as partially configured. This, in turn, prevents 'deborphan'
(which this package leverages) from working and it exits with an error. The
attach patch (see debdiff) traps such an error and tells the administrator how
to fix it.
unblock upgrade-system/1.7.2.1
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (1001, 'testing'), (1001, 'oldstable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru upgrade-system-1.7.1.1/debian/changelog upgrade-system-1.7.2.1/debian/changelog
--- upgrade-system-1.7.1.1/debian/changelog 2014-09-25 07:42:30.0 +0300
+++ upgrade-system-1.7.2.1/debian/changelog 2014-12-06 14:34:14.0 +0200
@@ -1,3 +1,13 @@
+upgrade-system (1.7.2.1) unstable; urgency=medium
+
+ * upgrade-system:
++ Added exit code to the orphan purging loop. This has become necessary
+ because some packages skip their DPKG triggers, which then makes DPKG
+ mark those packages as partially configured, in turn making deborphan
+ exit with an error.
+
+ -- Martin-Éric Racine Sat, 06 Dec 2014 14:33:38 +0200
+
upgrade-system (1.7.1.1) unstable; urgency=medium
* debian/control:
diff -Nru upgrade-system-1.7.1.1/upgrade-system upgrade-system-1.7.2.1/upgrade-system
--- upgrade-system-1.7.1.1/upgrade-system 2014-09-25 07:41:59.0 +0300
+++ upgrade-system-1.7.2.1/upgrade-system 2014-12-02 01:06:49.0 +0200
@@ -141,6 +141,11 @@
do
DEBORPHANS_OLD=$DEBORPHANS
DEBORPHANS=$(deborphan $ORPHANOPTS)
+ if [ $? != 0 ]
+ then
+ echo "${RED}E: Checking failed unexpectedly. Run 'dpkg --configure --pending' as root.${RESET}"
+ exit 3
+ fi
##DEPENDS: deborphan (universe/optional).
ORPHANS=${REMOVABLE:+$REMOVABLE }$DEBORPHANS
REMOVABLE=""
@@ -217,7 +222,7 @@
if [ $? != 0 ]
then
echo "${RED}E: Some dependencies could not be installed.${RESET}"
- exit 3
+ exit 4
fi
;;
esac
Bug#772273: unblock: upgrade-system/1.7.2.1
2014-12-06 18:59 GMT+02:00 Ivo De Decker : > Control: tags -1 moreinfo > > On Sat, Dec 06, 2014 at 03:02:53PM +0200, Martin-Éric Racine wrote: >> Please unblock package upgrade-system > >> unblock upgrade-system/1.7.2.1 > > This package is not in unstable, so it can't be unblocked. Don't the unblocking instructions say "already in unstable or planning to upload" IIRC? Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-release
Bug#772273: unblock: upgrade-system/1.7.2.1
2014-12-06 19:44 GMT+02:00 Ivo De Decker : > On Sat, Dec 06, 2014 at 07:37:43PM +0200, Martin-Éric Racine wrote: >> > This package is not in unstable, so it can't be unblocked. >> >> Don't the unblocking instructions say "already in unstable or planning >> to upload" IIRC? > > I don't know what instructions you are referring to, but we cannot unblock > packages that are not in unstable. It is possible to ask for pre-approval for > changes, but in that case, you should mention that in the bug report. > > The change you proposed looks reasonable, but based on the timing, it can only > be accepted if you upload this version soon. http://mentors.debian.net/debian/pool/main/u/upgrade-system/upgrade-system_1.7.2.1.dsc Cheers! Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-release
Bug#772273: unblock: upgrade-system/1.7.2.1
2014-12-06 19:44 GMT+02:00 Ivo De Decker : > The change you proposed looks reasonable, but based on the timing, it can only > be accepted if you upload this version soon. Thanks! Uploaded. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-release
Re: Bug#775471: xserver-xorg-video-geode-dbg: copyright file missing after upgrade (policy 12.5)
Wait. Got it: DPKG won't squash a previous directory.
Fixed in maintainer script. Patch attached.
Release Team:
Is this something worth getting a freeze exception for? If yes, should
it be introduced via unstable, jessies-update, or something else?
Cheers!
Martin-Éric
2015-01-16 14:48 GMT+02:00 Martin-Éric Racine :
> Hey Andreas,
>
> debian/rules uses this:
>
> override_dh_installdocs:
> dh_installdocs --link-doc=xserver-xorg-video-geode NEWS README TODO
>
> Surely that would link the -dbg package's /usr/share/doc/foo-dbg to
> .../foo, wouldn't it?
>
> Martin-Éric
>
>
> 2015-01-16 5:21 GMT+02:00 Andreas Beckmann :
>> Package: xserver-xorg-video-geode-dbg
>> Version: 2.11.16-5
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> Hi,
>>
>> a test with piuparts revealed that your package misses the copyright
>> file after an upgrade, which is a violation of Policy 12.5:
>> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
>>
>> After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
>>
>> This was observed on the following upgrade paths:
>>
>> wheezy -> jessie
>>
>> >From the attached log (scroll to the bottom...):
>>
>> 3m56.0s ERROR: WARN: Inadequate results from running adequate!
>> xserver-xorg-video-geode-dbg: missing-copyright-file
>> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
>>
>> 3m59.5s DUMP:
>> MISSING COPYRIGHT FILE:
>> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
>> # ls -lad /usr/share/doc/xserver-xorg-video-geode-dbg
>> drwxr-xr-x 2 root root 40 Jan 15 11:43
>> /usr/share/doc/xserver-xorg-video-geode-dbg
>> # ls -la /usr/share/doc/xserver-xorg-video-geode-dbg/
>> total 0
>> drwxr-xr-x 2 root root 40 Jan 15 11:43 .
>> drwxr-xr-x 185 root root 3840 Jan 15 11:43 ..
>>
>>
>> Additional info may be available here:
>> https://wiki.debian.org/MissingCopyrightFile
>>
>> Note that dpkg intentionally does not replace directories with symlinks
>> and vice versa, you need the maintainer scripts to do this.
>> See in particular the end of point 4 in
>> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>>
>> It is recommended to use the dpkg-maintscript-helper commands
>> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
>> to perform the conversion, ideally using d/$PACKAGE.mainstscript.
>> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
>> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
>>
>>
>> cheers,
>>
>> Andreas
diff -Nru xserver-xorg-video-geode-2.11.16/debian/changelog
xserver-xorg-video-geode-2.11.16/debian/changelog
--- xserver-xorg-video-geode-2.11.16/debian/changelog 2014-11-11
01:12:48.00000 +0200
+++ xserver-xorg-video-geode-2.11.16/debian/changelog 2015-01-16
15:11:33.0 +0200
@@ -1,3 +1,12 @@
+xserver-xorg-video-geode (2.11.16-6) unstable; urgency=medium
+
+ * debian/xserver-xorg-video-geode-dbg.maintscript:
++ New file. Handles dir_to_symlink for 2.11.13-5 (Closes: # 775471).
+ * debian/control:
++ xserver-xorg-video-geode-dbg: Pre-Depends: dpkg (>= 1.17.14)
+
+ -- Martin-Éric Racine Fri, 16 Jan 2015 15:10:36
+0200
+
xserver-xorg-video-geode (2.11.16-5) unstable; urgency=medium
* debian/control:
diff -Nru xserver-xorg-video-geode-2.11.16/debian/control
xserver-xorg-video-geode-2.11.16/debian/control
--- xserver-xorg-video-geode-2.11.16/debian/control 2014-11-11
00:33:21.0 +0200
+++ xserver-xorg-video-geode-2.11.16/debian/control 2015-01-16
15:10:27.0 +0200
@@ -40,6 +40,7 @@
Architecture: any-i386
Section: debug
Priority: extra
+Pre-Depends: dpkg (>= 1.17.14)
Depends: xserver-xorg-core-dbg,
xserver-xorg-video-geode (= ${binary:Version}),
${misc:Depends},
diff -Nru
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
---
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
1970-01-01 02:00:00.0 +0200
+++
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
2015-01-16 15:02:13.0 +0200
@@ -0,0 +1 @@
+dir_to_symlink /usr/share/doc/xserver-xorg-video-geode-dbg
/usr/share/doc/xserver-xorg-video-geode 2.11.13-5
Bug#846022: nmu: mozvoikko_2.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nmu mozvoikko_2.0.1-1 . ANY . stretch . -m "Rebuild to drop iceweasel Depends and migrate to firefox-esr (Closes: #819457)." - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (, 'testing'), (1011, 'stable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -BEGIN PGP SIGNATURE- iHgEARECADgWIQQ0UNMMeTbhfuC5+Dp5evnrHgy5zQUCWDtSChocbWFydGluLWVy aWMucmFjaW5lQGlraS5maQAKCRB5evnrHgy5zeJNAJ43qIdxdtYb7OAaUo3YjnKt 6JNwsQCgmGdNBonsLY5IByNAZfSRhLSi+cs= =LOxH -END PGP SIGNATURE-
Bug#808735: Heads up: transition: xserver 1.18
2015-12-22 23:15 GMT+02:00 Emilio Pozuelo Monfort : > On 22/12/15 21:53, Martin-Éric Racine wrote: >> Just a pointer: >> >> 2015-12-22 22:46 GMT+02:00 Emilio Pozuelo Monfort : >>> I didn't check the drivers that don't build on x86: >>> >>> xserver-xorg-video-freedreno >>> xserver-xorg-video-geode >>> xf86-video-omap >> >> You have your facts backwards. Geode ONLY builds on x86. :) > > Heh, right. It wasn't available on x86_64 and just assumed those three were > ARM* > or whatever. Anyway if you can verify it still builds / works that'd be great. Geode builds fine in my experimental chroot, but I haven't been able to verify whether the driver actually works as expected. Martin-Éric
Bug#683323: unblock: python-apt/0.8.7
2012/9/3 Michael Vogt : > On Mon, Aug 27, 2012 at 01:24:24PM +0200, Julian Andres Klode wrote: >> On Mon, Aug 27, 2012 at 02:10:17PM +0300, Martin-Éric Racine wrote: >> > ke, 2012-08-08 kello 01:50 +0200, Cyril Brulebois kirjoitti: >> > >> > > Julian Andres Klode (30/07/2012): >> > > > Since the version of testing, this contains mostly bug fixes and >> > > > many translation updates, but also (starting with 0.8.5) one new >> > > > module (apt.auth) which is a cleaned up version of an internal >> > > > software-properties module (and not used by any code in unstable >> > > > AFAIK). >> > > >> > > Then I'm not sure we need or want this new module in wheezy… >> > >> > Should this new module be rolled back and a new python-apt release >> > produced just for Wheezy, then? >> >> How about adding a warning to the module that it is experimental? I'd >> like to avoid rolling back stuff we already have in newer. Otherwise, >> we could upload a 0.8.8 with a disabled module as well, but that might >> create problems later on with merging Ubuntu packages that depend on >> python-apt (>= 0.8.5) and expect apt.auth to be there. >> >> We could also create a 0.8.4.1 release for testing, by branching off >> unstable's 0.8.7, merging the changelog entries for 0.8.5, 0.8.6, >> and 0.8.7 into 0.8.4.1, and removing apt.auth mentions, and disabling >> or removing that module. But that is a bit more work. We could also >> name 0.8.4.1 as 0.8.4+wheezy1, but given that unstable is past 0.8.4 >> already, just using 0.8.4.X instead of 0.8.4+wheezyX seems a bit >> nicer. > > I created a branch at > http://anonscm.debian.org/bzr/bzr/apt/python-apt/debian-wheezy/ that > is based on the debian-sid branch but disables auth.py. I am happy to > upload this to wheezy if that approach is approved by the release > team. Release Team: A separate branch was created for Wheezy and a debdiff submitted. Is there anything else missing to move this issue forward and achieve a concensus about what will be allowed into Testing? Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqfl645_hax3aem5tdxaksqbgm0nppp0vcn4bsbfpda...@mail.gmail.com
Re: Bug#692569: xserver-xorg-video-geode: some GTK widgets would randomly display unreadable "smeared" text labels
reassign 692569 release.debian.org retitle 692569 unblock: xserver-xorg-video-geode/2.11.13-7 thanks 2012/11/7 guenter : > Package: xserver-xorg-video-geode > Version: 2.11.13-3 > Severity: important > > Dear Maintainer, > > when running > > xserver-xorg-video-geode 2.11.13-3 > > some GTK widgets (e.g. xfce's main menu, but also Iceweasel's > address bar) would randomly display unreadable "smeared" text labels. > > Looked like a transient problem as triggering a redraw would fix the issue > temporarily. > > Anyway, upgrading to > > xserver-xorg-video-geode_2.11.13-7 > > from unstable/sid fixed the problem permanently for me. Please consider using > this revision in Debian 7 ? Reassigning this bug to release.debian.org and requesting the Release Team's permission. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqf8g7y+usefwrpftevwgu2ox7wfpv-pgueoshqpgyx...@mail.gmail.com
Re: Bug#692569: xserver-xorg-video-geode: some GTK widgets would randomly display unreadable "smeared" text labels
2012/11/7 Adam D. Barratt : > reassign 692569 xserver-xorg-video-geode > found 692569 2.11.13-3 > clone 692569 -1 > retitle 692569 xserver-xorg-video-geode: some GTK widgets would randomly > display unreadable "smeared" text labels > reassign -1 release.debian.org > severity -1 normal > user release.debian@packages.debian.org > usertag -1 unblock > thanks > > > On 07.11.2012 16:36, Martin-Éric Racine wrote: >> >> 2012/11/7 guenter : >>> >>> Package: xserver-xorg-video-geode >>> >>> Anyway, upgrading to >>> >>> xserver-xorg-video-geode_2.11.13-7 >>> >>> from unstable/sid fixed the problem permanently for me. Please consider >>> using this revision in Debian 7 ? >> >> >> Reassigning this bug to release.debian.org and requesting the Release >> Team's permission. > > > That's not how to file an unblock request. :-( #692569 relates to your > package and needs to stay there. I've reassigned it back and cloned a copy > for release.d.o, but that's still a bit of a stretch. Thanks for cloning the bug! I'm not sure how useful it is to keep the original bug attached to the package, though, as it's essentially reporting a resolved state, rather than a new bug. > Please follow-up to the cloned bug including the information requested in > the freeze policy / reportbug template - at the very minimum a full source > debdiff between the current wheezy version and the version you're requesting > an unblock for. Noted. If you could point me to the number of the cloned bug, I'll gladly continue the procedure there. :) [ It might be useful for the BTS to automatically add the maintainer of whichever package is concerned by an unblock request in the loop, since it might have been filed by someone else. Right now, the maintainer might not even be aware of such a request, since the BTS only mails the maintainer of "package" release.debian.org ] > From a very quick look, I suspect that debdiff will actually fail to mail it > to the mailing list, due to the presence of > > patches/0003-Whitespace-cleanup-using-.-modular-x-indent.sh.patch > |37926 ++ Right, this was pulled from our upstream Git, since it's needed to apply later fixes. While it *is* a huge diff, it's essentially harmless, since the pretty-printing was performed with an X release macro. > That doesn't look hugely appropriate for an update to a package during > freeze. Please strip it from the debdiff when sending it, but mention that > you've done so. Right and seeing what happened with python-apt, I'm starting to think that debdiff's are best attached to the bug itself and merely mentioned in the debian-release thread, so as to avoid clogging the mailing list. :) Thanks for your help! Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQd_aZ9PEO7KJvZRE9smE-HtnX7sVbOLFucs0WYOh0=n...@mail.gmail.com
Bug#692600: Bug#692569: xserver-xorg-video-geode: some GTK widgets would randomly display unreadable "smeared" text labels
2012/11/9 Adam D. Barratt : >>> Please follow-up to the cloned bug including the information requested in >>> the freeze policy / reportbug template - at the very minimum a full >>> source debdiff between the current wheezy version and the version you're >>> requesting an unblock for. debdiff attached to bug 692600 as requested. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQf4fF7g4w==kuS4-EG1CHrb4k5FfqzRedUa4-=z7pg...@mail.gmail.com
Bug#692600: unblock: xserver-xorg-video-geode/2.11.13-7
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package xserver-xorg-video-geode: The version in unstable fixes outstanding rendering bugs caused by recent Cairo versions. Feedback had been requested from reporters of existing bugs but remained unanswered and instead came now via brand new bug #692569 as a confirmation that the issue is fixed in unstable. The debdiff was e-mailed directly to the bug report, because it would have been rejected by the Debian list server, due to a large diff (0003-Whitespace-cleanup-using-.-modular-x-indent.sh.patch) that is a prerequisite to applying recent changes necessary to fix the issue. While this particular change is indeed intrusive, it was produced using a standard X.org release macro so I would consider it as safe. unblock xserver-xorg-video-geode/2.11.13-7 Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352472314.3887.10.ca...@tupla.lan
Bug#692600: unblock: xserver-xorg-video-geode/2.11.13-7
2012/11/9 Martin-Éric Racine : > 2012/11/9 Adam D. Barratt : >> On Fri, 2012-11-09 at 16:45 +0200, Martin-Éric Racine wrote: >>> The debdiff was e-mailed directly to the bug report, because it would >>> have been rejected by the Debian list server, due to a large diff >>> (0003-Whitespace-cleanup-using-.-modular-x-indent.sh.patch) that is a >>> prerequisite to applying recent changes necessary to fix the issue. >> >> Which is precisely why I requested that you filter it out before sending >> it, so that it *would* reach the list. Never mind... > > Sorry, I had misunderstood your intention with this request. Here is a > stripped version. ... which, even then, got rejected by the list with a warning that it exceeded the maximum size allowed. It however correctly reached the bug report itself. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqfpmpjao8lfxn3fulzqc0vwvl9kv7d0waoalthuruq...@mail.gmail.com
Bug#683323: unblock: python-apt/0.8.7
2012/11/14 Michael Vogt : > I don't have a strong opinion either way, I'm happy to remove the > apt.auth module and upload that to wheezy or use the updated one from > 0.8.8 - but I would really like to get the bugfixes from 0.8.8.1 in if > possible. In any case, the current FTBFS has to be fixed in unstable. :) Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQfiuPW7gsCmNQ2=vaqxe=g0fhcsy8zvpuwvkfgnjzl...@mail.gmail.com
Bug#692600: xf86-video-geode: debdiff -3 to -8 (without patch 0003)
Here is the main long-standing issue that 2.11.13-8 (a.k.a. 2.11.14 minus the documentation changes) would fix: https://bugs.freedesktop.org/show_bug.cgi?id=51360 Unless I'm mistaken, this corresponds to Debian bugs #692569 and #570637. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqcxph7v-omgc22_kfh_9mdrt97mboxkzxfrgpi8mya...@mail.gmail.com
Bug#692600: Geode 2.11.14 released
Upstream went ahead and released as Geode 2.11.14 what had been pushed over the past few months into Debian/unstable as a patched 2.11.13 source. I've already prepared a 2.11.14-1 package for Debian/unstable. Sponsors are welcome to perform the upload. Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQf+zpOO=NkWbrodNszZv-sCs9-acDdtdetn=y1ctky...@mail.gmail.com
Bug#692600: fixes 591364 and 692569
As confirmed by the users who reported the respective bugs against xserver-xorg-video-geode: #591364 was fixed in 2.11.14-1 #692569 was fixed in 2.11.13-7 I'm still waiting for confirmation whether #570637 was also fixed by uploads since 2.11.13-3 or not. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqcn4vhtzvz5syy9xppjce1r+amukb2driej1-pgcud...@mail.gmail.com
Bug#692600: Geode 2.11.14 released
2012/12/3 Julien Cristau : > On Sun, Nov 25, 2012 at 13:24:50 +0200, Martin-Éric Racine wrote: > >> Upstream went ahead and released as Geode 2.11.14 what had been pushed >> over the past few months into Debian/unstable as a patched 2.11.13 >> source. >> >> I've already prepared a 2.11.14-1 package for Debian/unstable. >> Sponsors are welcome to perform the upload. >> > So, err... > 112 files changed, 18739 insertions(+), 11535 deletions(-) > > I'm afraid that's nowhere near suitable for a freeze exception. You'll notice that most of this is essentially whitespace cleanup performed using the standard X-indent macro. In practice, there's very few changes to the code's functionality itself. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQd=kzcxyzmfkqpkhrhjwvvm49ro3x56q6thogrehqz...@mail.gmail.com
Bug#692600: Geode 2.11.14 released
2012/12/4 Julien Cristau : > On Tue, Dec 4, 2012 at 00:34:54 +0200, Martin-Éric Racine wrote: > >> 2012/12/3 Julien Cristau : >> > On Sun, Nov 25, 2012 at 13:24:50 +0200, Martin-Éric Racine wrote: >> > >> >> Upstream went ahead and released as Geode 2.11.14 what had been pushed >> >> over the past few months into Debian/unstable as a patched 2.11.13 >> >> source. >> >> >> >> I've already prepared a 2.11.14-1 package for Debian/unstable. >> >> Sponsors are welcome to perform the upload. >> >> >> > So, err... >> > 112 files changed, 18739 insertions(+), 11535 deletions(-) >> > >> > I'm afraid that's nowhere near suitable for a freeze exception. >> >> You'll notice that most of this is essentially whitespace cleanup >> performed using the standard X-indent macro. In practice, there's very >> few changes to the code's functionality itself. >> > No, I won't notice that, because I'm not even looking at such a diff. http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/log/ This should make it fairly obvious at exactly which commit the biggest amount of noise took place. :) Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqcdqezzc6ppyfq_whnn43l6zd9ipsmmzinonlfjgmt...@mail.gmail.com
Re: Advice needed: update-manager in wheezy considered dangerous
2013/3/12 Julian Andres Klode : > Dear release team, I report this problem as we have switched our package > management > stack in wheezy from update-manager and other components to PackageKit. Those > old components are still in wheezy however, and especially update-manager can > be considered to be horribly dangerous: It might break systems or contain > extreme > security issues as it has not seen someone really care about it since 2 years. > > We cannot simply remove update-manager however, as there are reverse > dependencies. The most important ones appear to be: > > * upgrade-system > * update-notifier > > We could simply drop upgrade-system from testing. For update-notifier, we > cannot > do this, as update-notifier-kde depends on update-notifier-common, and there > are > no other notifiers for KDE AFAIK. I could however upload an empty > update-notifier > package (for GNOME) that switches the user to the PackageKit notifier, thus > removing that reverse dependency. > > Summary of the proposed solution: > 1. Remove upgrade-system from testing I really don't see the point in removing upgrade-system from Testing, since the dependency relationship is merely a Suggests. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQdVB=9wsowbwzrljimvbtfqom8pesfdyvwmyo1crp0...@mail.gmail.com
Re: Advice needed: update-manager in wheezy considered dangerous
As stated a few months in this discussion, upgrade-system merely Suggests update-notifier. It therefore doesn't need to be removed. Martin-Éric 2013/5/10 Julian Andres Klode > On Fri, May 10, 2013 at 11:14:21AM +0200, Emilio Pozuelo Monfort wrote: > > Hi Julian, > > > > On 12/03/13 00:42, Julian Andres Klode wrote: > > >Dear release team, I report this problem as we have switched our > package management > > >stack in wheezy from update-manager and other components to PackageKit. > Those > > >old components are still in wheezy however, and especially > update-manager can > > >be considered to be horribly dangerous: It might break systems or > contain extreme > > >security issues as it has not seen someone really care about it since 2 > years. > > > > > >We cannot simply remove update-manager however, as there are reverse > > >dependencies. The most important ones appear to be: > > > > > > * upgrade-system > > > * update-notifier > > > > > >We could simply drop upgrade-system from testing. For update-notifier, > we cannot > > >do this, as update-notifier-kde depends on update-notifier-common, and > there are > > >no other notifiers for KDE AFAIK. I could however upload an empty > update-notifier > > >package (for GNOME) that switches the user to the PackageKit notifier, > thus > > >removing that reverse dependency. > > > > > >Summary of the proposed solution: > > > 1. Remove upgrade-system from testing > > > 2. Replace update-notifier binary package with a package > transitioning > > >users to gnome-packagekit > > > 3. Remove update-manager from testing or transition users to > PackageKit > > > > I think it's time to do something like this in unstable. > > Yes. We need: > (a) transitional packages for > - update-notifier > - update-notifier-kde > - update-manager > > (b) Breaks and Provides in gnome-packagekit / apper > gnome-packagekit on update-notifier, update-manager > apper on update-notifier-kde > > > I already uploaded a new version of update-notifier, called > 0.99.3debian11+perrm1 that makes update-notifier a transitional > package; and requested update-managers removal from unstable. > > I kept the update-notifier-common package the way it is now, > so update-notifier-kde keeps working until it is replaced by > a transitional package to apper. After that happened, > update-notifier-common will be dropped. > > -- > Julian Andres Klode - Debian Developer, Ubuntu Member > > See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. >
Bug#684450: unblock: python-apt/0.8.7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python-apt Testing has 0.8.4 while newer releases close several bugs, among them, removal of numerous obsolete dependencies such as python2.6 unblock python-apt/0.8.7 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (1001, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120810061318.21830.61601.report...@henna.lan
Bug#683323: unblock: python-apt/0.8.7
ke, 2012-08-08 kello 01:50 +0200, Cyril Brulebois kirjoitti: > Julian Andres Klode (30/07/2012): > > Since the version of testing, this contains mostly bug fixes and > > many translation updates, but also (starting with 0.8.5) one new > > module (apt.auth) which is a cleaned up version of an internal > > software-properties module (and not used by any code in unstable > > AFAIK). > > Then I'm not sure we need or want this new module in wheezy… Should this new module be rolled back and a new python-apt release produced just for Wheezy, then? > > The versions 0.8.5 and 0.8.6 FTBFS due to this new module, as it did > > not pass the test suite due to two bugs: (1) missing build-time > > dependency on version 0.9.6 of apt (and outdated buildds) [fixed in > > 0.8.6], and (2) because it combined the stderr and stdout of the > > apt-key command it calls which fails to work on kFreeBSD if > > LD_PRELOAD is set, as gpg (which is run by apt-key) is setuid there > > [and we use fakeroot for the apt.auth tests, so it fails]. The > > latter was fixed in 0.8.7. > > Especially when it took that long to get it to basically work. :( > > I'll leave the pythonish review to some other python-fluent release > team members anyway; just a bit astonished to see new code at this > point. At the very least, we need ASAP a new python-apt that removes the deprecated dependencies on Python 2.6 and that incorporates fixes to bugs that existed prior to the freeze. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346065817.8083.3.ca...@henna.lan
Bug#683323: unblock: python-apt/0.8.7
ma, 2012-08-27 kello 13:24 +0200, Julian Andres Klode kirjoitti: > On Mon, Aug 27, 2012 at 02:10:17PM +0300, Martin-Éric Racine wrote: > > ke, 2012-08-08 kello 01:50 +0200, Cyril Brulebois kirjoitti: > > > > > Julian Andres Klode (30/07/2012): > > > > Since the version of testing, this contains mostly bug fixes and > > > > many translation updates, but also (starting with 0.8.5) one new > > > > module (apt.auth) which is a cleaned up version of an internal > > > > software-properties module (and not used by any code in unstable > > > > AFAIK). > > > > > > Then I'm not sure we need or want this new module in wheezy… > > > > Should this new module be rolled back and a new python-apt release > > produced just for Wheezy, then? > > How about adding a warning to the module that it is experimental? I'd > like to avoid rolling back stuff we already have in newer. Otherwise, > we could upload a 0.8.8 with a disabled module as well, but that might > create problems later on with merging Ubuntu packages that depend on > python-apt (>= 0.8.5) and expect apt.auth to be there. I might be wrong but I think that Cyril's point in not accepting 0.8.7 into Testing was that it introduces new features after the freeze. > We could also create a 0.8.4.1 release for testing, by branching off > unstable's 0.8.7, merging the changelog entries for 0.8.5, 0.8.6, > and 0.8.7 into 0.8.4.1, and removing apt.auth mentions, and disabling > or removing that module. But that is a bit more work. We could also > name 0.8.4.1 as 0.8.4+wheezy1, but given that unstable is past 0.8.4 > already, just using 0.8.4.X instead of 0.8.4+wheezyX seems a bit > nicer. Either one of 0.8.4.1 or 0.8.4+wheezyX could be introduced via testing-security. Which of these two numbering scheme makes more sense is another question. Cyril might have preferences for that. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1346067663.8083.7.ca...@henna.lan
Bug#769043: unblock: xserver-xorg-video-geode/2.11.16-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package xserver-xorg-video-geode
2.11.16-4 mistakenly dropped a (Provides: xorg-driver-video). Without it, on
hosts without any other X.Org video driver installed, this results in an APT
decision to remove the whole X.Org stack and most desktop applications.
debdiff (minus changelog.dch, which somehow shipped with 2.11.16-4 unnoticed):
diff -Nru xserver-xorg-video-geode-2.11.16/debian/changelog
xserver-xorg-video-geode-2.11.16/debian/changelog
--- xserver-xorg-video-geode-2.11.16/debian/changelog 2014-09-14
13:41:27.0 +0300
+++ xserver-xorg-video-geode-2.11.16/debian/changelog 2014-11-11
01:12:48.0 +0200
@@ -1,3 +1,12 @@
+xserver-xorg-video-geode (2.11.16-5) unstable; urgency=medium
+
+ * debian/control:
++ Provides: xorg-driver-video
+ This reverses part of the previous changes. Without this, APT uninstalls
+ the whole X.Org if no other video driver is installed (Closes: #769042).
+
+ -- Martin-Éric Racine Tue, 11 Nov 2014 01:07:59
+0200
+
xserver-xorg-video-geode (2.11.16-4) unstable; urgency=medium
* debian/control,debian/rules; Gotten one step closer to XSF:
diff -Nru xserver-xorg-video-geode-2.11.16/debian/control
xserver-xorg-video-geode-2.11.16/debian/control
--- xserver-xorg-video-geode-2.11.16/debian/control 2014-09-14
14:00:15.0 +0300
+++ xserver-xorg-video-geode-2.11.16/debian/control 2014-11-11
00:33:21.0 +0200
@@ -23,7 +23,8 @@
Depends: ${misc:Depends},
${shlibs:Depends},
${xviddriver:Depends}
-Provides: xserver-xorg-video-amd,
+Provides: xorg-driver-video,
+ xserver-xorg-video-amd,
${xviddriver:Provides}
Breaks: xserver-xorg-video-amd (<< ${binary:Version})
Description: X.Org X server -- Geode GX2/LX display driver
unblock xserver-xorg-video-geode/2.11.16-5
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (1001, 'testing'), (1001, 'oldstable')
Architecture: i386 (i686)
Kernel: Linux 3.16-3-686-pae (SMP w/1 CPU core)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-release
unblock request: krb5
Greetings, Would it be possible to unblock krb5 and allow it to transit to Testing? We need CUPS 1.3.10-5 to go into Testing ASAP to compensate for changes in dependencies resulting from the recent repackaging of necessary Ghostcript's PPD components into a separate ghostscript-cups package. This new GS package's introduction has generate a lot of bug reports from people whose printer requires raster support that was previously provided by the main ghostscript package and is now provided by ghostscript-cups instead, simply because the components they need are not a dependency of the 1.3.10-2 that is currently sitting in Testing, which momentarily broke support for their printer. Allowing 1.3.10-5 into Testing fixes this issue, but this is dependent upon krb5 being allowed into Testing first. Please don't hesitate in contacting me if you have any additional question about this request. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: unblock request: krb5
2009/7/6 Jurij Smakov : > On Mon, Jul 06, 2009 at 03:19:18PM +0300, Martin-Éric Racine wrote: >> Greetings, >> >> Would it be possible to unblock krb5 and allow it to transit to >> Testing? We need CUPS 1.3.10-5 to go into Testing ASAP to compensate >> for changes in dependencies resulting from the recent repackaging of >> necessary Ghostcript's PPD components into a separate ghostscript-cups >> package. >> >> This new GS package's introduction has generate a lot of bug reports >> from people whose printer requires raster support that was previously >> provided by the main ghostscript package and is now provided by >> ghostscript-cups instead, simply because the components they need are >> not a dependency of the 1.3.10-2 that is currently sitting in Testing, >> which momentarily broke support for their printer. >> >> Allowing 1.3.10-5 into Testing fixes this issue, but this is dependent >> upon krb5 being allowed into Testing first. >> >> Please don't hesitate in contacting me if you have any additional >> question about this request. > > krb5 transition is almost done, as you can see at > > https://buildd.debian.org/transitions/summary.html > > with only 3 problematic packages remaining. We attempted to resolve them > over the weekend, with partial success. Once they are fixed, krb5 will > propagate to testing. Thanks for the explanation on the current situation. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Pending removal of deborphan
On Wed, Aug 11, 2010 at 9:45 PM, Neil McGovern wrote: > As per bug 592071, it seems that deborphan shoudn't be in squeeze > without a maintainer who'll take care of it. I'm ccing the maintainers > of the depending packages to see if they'd be interested in taking it > over. If I don't hear anything in a week, I'll go ahead and remove it > from testing. A week seems to be a rather short amount of time to expect feedback from people, especially during summer. Surely there is no life threatening situation affecting this package that would impose such a hasty decision? At any rate, if no one else is willing to maintain it, I would gladly pick it up. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimznpfe2q+=ramuabilygdisczmjxrxv5mwm...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Fri, Aug 27, 2010 at 9:42 PM, Otavio Salvador
wrote:
> I am adding Martin-Eric to CC so he can address those issues.
>
> On Fri, Aug 27, 2010 at 3:00 PM, Julien Cristau wrote:
>> On Fri, Aug 27, 2010 at 09:51:39 -0300, Otavio Salvador wrote:
>>> Please unblock it since it fixes many critical issues for users.
>>>
>> -Provides: ${xviddriver:Provides}, xserver-xorg-video-amd
>> +Provides: ${xserver:Provides}, xserver-xorg-video-amd
>>
>> Please add xorg-driver-video to Provides.
>
> Agreed.
Come again?
--
Martin-Éric
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktimxnfqr3pormewou9zqe1=fqu6afcda-sx...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
2010/8/28 Martin-Éric Racine :
> On Fri, Aug 27, 2010 at 9:42 PM, Otavio Salvador
> wrote:
>> I am adding Martin-Eric to CC so he can address those issues.
>>
>> On Fri, Aug 27, 2010 at 3:00 PM, Julien Cristau wrote:
>>> On Fri, Aug 27, 2010 at 09:51:39 -0300, Otavio Salvador wrote:
>>>> Please unblock it since it fixes many critical issues for users.
>>>>
>>> -Provides: ${xviddriver:Provides}, xserver-xorg-video-amd
>>> +Provides: ${xserver:Provides}, xserver-xorg-video-amd
>>>
>>> Please add xorg-driver-video to Provides.
>>
>> Agreed.
>
> Come again?
Ah, right. Isn't that Provides a ghost from the past? :) Anyhow, done
and uploaded to mentors.
Martin-Éric
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinznn0ok_enmqpdkggsrzpaodrkoe-=3ui2k...@mail.gmail.com
unblock request: upgrade-system
Greetings, I was wondering why src:upgrade-system hadn't entered Testing after 10 days and only noticed now that we have already entered The Freeze. Hurray! On the other hand, this means that I hereby need to request a freeze unblock for this recent upload. Most changes are mere polishing of what was already started in 1.6.2.0 (cleaning up debian/copyright and using --long-options for everything). There is exactly one new feature in the cron job and even then it's a minor one. Looking forward to the Release Team's response. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPZXPQeT=sdfkky18z_p4har8gttpdwjtg7vo-_26bbk4m-...@mail.gmail.com
Re: unblock request: upgrade-system
Hello again, 2012/7/16 Cyril Brulebois : > Martin-Éric Racine (16/07/2012): >> Most changes are mere polishing of what was already started in 1.6.2.0 >> (cleaning up debian/copyright and using --long-options for >> everything). There is exactly one new feature in the cron job and even >> then it's a minor one. > > even if the diff is indeed tiny, I don't think it matches the rules > described at: http://release.debian.org/wheezy/freeze_policy.html > (linked from the freeze announcement). 6. as above, important changes that the maintainer feels are needed before release. Those changes were done with the specific goal of covering oversights from 1.6.2.0 on time for the release, thus why I feel they are needed for Wheezy. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capzxpqeajjmbikbo1xcyt0qp1hl5g6zxzttw3vevmptenrr...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Fri, Aug 27, 2010 at 9:42 PM, Otavio Salvador
wrote:
> On Fri, Aug 27, 2010 at 3:00 PM, Julien Cristau wrote:
>> On Fri, Aug 27, 2010 at 09:51:39 -0300, Otavio Salvador wrote:
>>> Please unblock it since it fixes many critical issues for users.
>>>
>> -Provides: ${xviddriver:Provides}, xserver-xorg-video-amd
>> +Provides: ${xserver:Provides}, xserver-xorg-video-amd
>>
>> Please add xorg-driver-video to Provides.
>
> Agreed.
Done and uploaded.
Is there any other issue left that prevents 2.11.9's transition to Squeeze?
Martin-Éric
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikxmnkent+ctcbkqtgacobknsm-4e_=tn16e...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Tue, Aug 31, 2010 at 11:32 AM, Julien Cristau wrote: > On Tue, Aug 31, 2010 at 00:56:00 +0300, Martin-Éric Racine wrote: > >> Is there any other issue left that prevents 2.11.9's transition to Squeeze? >> > Yes, see my previous mail. Can you point to specific aspects? I haven't been included in CC right from the begining, so I probably missed the relevant parts. It would also be desirable to keep the AMD developers in CC, if the remaining issues involve upstream changes since 2.11.8. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=epntpwoqfroqgjltm92cdqcbae-+_10p82...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Fri, Sep 3, 2010 at 11:46 AM, Julien Cristau wrote: > On Fri, Sep 3, 2010 at 09:33:19 +0800, Huang, FrankR wrote: > >> Otavio, >> >> I saw this thread from top to the end. >> Is it because the patch >> >> http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=e9447f5335681a78cf87ebf8c9659a6fecfc9746 >> block the geode driver to be accepted? >> If that is so, can we agree with the suggestion from Julien? >> if ((pGeode->Output & (OUTPUT_PANEL | OUTPUT_DCON)) == >> (OUTPUT_PANEL | OUTPUT_DCON)) >> > Well, or you could make it if (pGeode->Output == (OUTPUT_PANEL | > OUTPUT_DCON)). Or alternatively, explain why the existing code is > correct. We'll discuss this particular one with Otavio and let him comment on the solution. > Another question is whether your EXA composite paths are reliable enough > now, or whether we'd better disable them for release. I would say that they are a million times better than they were in 2.11.8 but I don't discount the fact that a few issues remain to iron out. At the very least, a large number of rendering issues that had been bugging users for the last two years are finally resolved and this, IMHO, is a good enough reason to allow 2.11.9 into Squeeze. This being said, it could very well be that a few issues that Julien brought up need to be addressed before it happens. Conversely, we'd appreciate if bug #567909 would finally be resolved on time for Squeeze. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=j-comz7n=r3bcsozncn7s-vt+fjwjedsuh...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Fri, Sep 3, 2010 at 3:10 PM, Julien Cristau wrote: > On Fri, Sep 3, 2010 at 14:38:21 +0300, Martin-Éric Racine wrote: >> On Fri, Sep 3, 2010 at 11:46 AM, Julien Cristau wrote: >> > Another question is whether your EXA composite paths are reliable enough >> > now, or whether we'd better disable them for release. >> >> I would say that they are a million times better than they were in >> 2.11.8 but I don't discount the fact that a few issues remain to iron >> out. At the very least, a large number of rendering issues that had >> been bugging users for the last two years are finally resolved and >> this, IMHO, is a good enough reason to allow 2.11.9 into Squeeze. This >> being said, it could very well be that a few issues that Julien >> brought up need to be addressed before it happens. > > I'd be ok with allowing 2.11.9 in squeeze once the above is clarified or > fixed, with the understanding that exa composite acceleration will be > disabled if more issues are reported before release. Does that work for > you? If that happened, what configuration option would you use? And what basis would you use for deciding whether this is necessary or not? The appearance of RC bugs against the driver or something else? >> Conversely, we'd appreciate if bug #567909 would finally be resolved >> on time for Squeeze. >> > Fixed in git. Guess it slipped through the cracks. Thanks! -- Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimv=kuno34ffgm=ykkgmm3ca9wipy+lsxw9q...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
2010/9/3 Martin-Éric Racine : > On Fri, Sep 3, 2010 at 11:46 AM, Julien Cristau wrote: >> On Fri, Sep 3, 2010 at 09:33:19 +0800, Huang, FrankR wrote: >> >>> I saw this thread from top to the end. >>> Is it because the patch >>> >>> http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=e9447f5335681a78cf87ebf8c9659a6fecfc9746 >>> block the geode driver to be accepted? >>> If that is so, can we agree with the suggestion from Julien? >>> if ((pGeode->Output & (OUTPUT_PANEL | OUTPUT_DCON)) == >>> (OUTPUT_PANEL | OUTPUT_DCON)) >>> >> Well, or you could make it if (pGeode->Output == (OUTPUT_PANEL | >> OUTPUT_DCON)). Or alternatively, explain why the existing code is >> correct. > > We'll discuss this particular one with Otavio and let him comment on > the solution. Otavio, we're still waiting for your explanation on this issue. Julien, is there any other issue left to address, before this unblock request can be approved? Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimbg+hj6ocgw=sbvh37app--4obmsjvsag...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
2010/9/18 Martin-Éric Racine : > 2010/9/3 Martin-Éric Racine : >> On Fri, Sep 3, 2010 at 11:46 AM, Julien Cristau wrote: >>> On Fri, Sep 3, 2010 at 09:33:19 +0800, Huang, FrankR wrote: >>> >>>> I saw this thread from top to the end. >>>> Is it because the patch >>>> >>>> http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=e9447f5335681a78cf87ebf8c9659a6fecfc9746 >>>> block the geode driver to be accepted? >>>> If that is so, can we agree with the suggestion from Julien? >>>> if ((pGeode->Output & (OUTPUT_PANEL | OUTPUT_DCON)) == >>>> (OUTPUT_PANEL | OUTPUT_DCON)) >>>> >>> Well, or you could make it if (pGeode->Output == (OUTPUT_PANEL | >>> OUTPUT_DCON)). Or alternatively, explain why the existing code is >>> correct. >> >> We'll discuss this particular one with Otavio and let him comment on >> the solution. > > Otavio, we're still waiting for your explanation on this issue. Andres Salomon submitted a simple fix for this issue. Basically, we no longer check the panel bit. Instead, we only check if we're running on DCON-equipped hardware to make an exact match for the OLPC XO-1 configuration which, if found, will set the display to the XO-1's unique resolution. This has been committed upstream and could be added to the current 2.11.9 package as a patch and pushed as 2.11.9-3. Is there any other issue left to address, before this unblock request can be approved? Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim17mnzjpgh6qceuya6ovhz=rv2jveuqhrgw...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
2010/9/21 Martin-Éric Racine : > Andres Salomon submitted a simple fix for this issue. Basically, we no > longer check the panel bit. Instead, we only check if we're running on > DCON-equipped hardware to make an exact match for the OLPC XO-1 > configuration which, if found, will set the display to the XO-1's > unique resolution. This has been committed upstream and could be added > to the current 2.11.9 package as a patch and pushed as 2.11.9-3. > > Is there any other issue left to address, before this unblock request > can be approved? The updated package has been sitting in unstable for a couple of days with no new issue reported. At this point, I really cannot think of any remaining issue to address. Can we please get this unblocked now? Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=rt1b9gemvuzrwjctshy8qevbdxinxzlm8q...@mail.gmail.com
Re: Unblock xserver-xorg-video-geode
On Thu, Sep 23, 2010 at 9:06 PM, Julien Cristau wrote: > On Thu, Sep 23, 2010 at 17:05:46 +0300, Martin-Éric Racine wrote: > >> The updated package has been sitting in unstable for a couple of days >> with no new issue reported. At this point, I really cannot think of >> any remaining issue to address. Can we please get this unblocked now? >> > I don't see where you need xutils-dev. The configure script complained about a missing file that according to packages.d.o is provided by xutils-dev. Adding that Build-Depends indeed made the message disappear. > + /* Allocates shadow memory, and allocating a new space for Rotatation. > > it's spelled "rotation". Where was this again? It's only a typo in the comment, but I could at least fix it in GIT. > + return MODE_BAD; > > it might be nice to return one of the more descriptive errors. Sounds good to me too. Where exactly would you add it? Again, I could fix it in GIT. > 2.11.9-3 unblocked. Thanks! Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimri_kdqsc-u6f86ggp7rgitzy_sgknxrmh=...@mail.gmail.com
Unblock xserver-xorg-video-geode
Greetings, Would it be possible to unblock xserver-xorg-video-geode 2.11.9-5 that is currently sitting in unstable? Compared to 2.11.9-3, this package contains two fixes for hardware support issues, plus it introduces native support for one laptop vendor's non-standard LCD resolution. I was gonna wait until the 10 day period was over before requesting the unblock but noticing that we keep on getting closer to the release, I figured that I might as well ask now. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikdvykea4xxcwf+axt+7k7m35d10-=wg8rbp...@mail.gmail.com
unblock request: xserver-xorg-video-geode
Greetings,
I realize that we are pretty deep into the freeze, but since the
unstable package includes some hardware support fixes, some of which
specifically affect the OLPC, I figured that I might as well ask
anyway, just in case. The changes between 2.11.9-5 and 2.11.9-7 are as
follow:
+ * Merged patch from upstream GIT:
+- Move eCafe EC800 support to panel-only BIOS-dependant feature.
Not essential, but given how we've been trying to properly support
this laptop for ages (see #591364 for instance), might be worth
including.
+- Replace custom Geode offscreen allocation with standard EXA calls.
Long requested by X core developers and finally implemented by AMD developers.
+- Add lx_output_get_crtc to prevent driver reset with unknown CRTC.
+- Prevent OLPC DCON from sleeping when it's in frozen state.
Both changes specifically aim at fixing OLPC issues, although the
first one benefits others too.
The debdiff is attached. It includes one patch that was renamed
between these two releases.
Best Regards,
Martin-Éric
diff -u xserver-xorg-video-geode-2.11.9/debian/changelog
xserver-xorg-video-geode-2.11.9/debian/changelog
--- xserver-xorg-video-geode-2.11.9/debian/changelog
+++ xserver-xorg-video-geode-2.11.9/debian/changelog
@@ -1,3 +1,19 @@
+xserver-xorg-video-geode (2.11.9-7) unstable; urgency=low
+
+ * Merged patch from upstream GIT:
+- Move eCafe EC800 support to panel-only BIOS-dependant feature.
+
+ -- Martin-Éric Racine Thu, 28 Oct 2010 13:01:52 +0300
+
+xserver-xorg-video-geode (2.11.9-6) unstable; urgency=low
+
+ * Merged patches from upstream GIT:
+- Replace custom Geode offscreen allocation with standard EXA calls.
+- Add lx_output_get_crtc to prevent driver reset with unknown CRTC.
+- Prevent OLPC DCON from sleeping when it's in frozen state.
+
+ -- Martin-Éric Racine Wed, 27 Oct 2010 19:00:17 +0300
+
xserver-xorg-video-geode (2.11.9-5) unstable; urgency=low
* Merged patches from upstream GIT:
reverted:
--- xserver-xorg-video-geode-2.11.9/debian/patches/003_sync_mode_typo.patch
+++ xserver-xorg-video-geode-2.11.9.orig/debian/patches/003_sync_mode_typo.patch
@@ -1,24 +0,0 @@
-From becaa0ae375e996c2f83192bb84a5c89f94933dd Mon Sep 17 00:00:00 2001
-From: Frank Huang
-Date: Wed, 29 Sep 2010 08:45:42 +
-Subject: Fix a typo on resolution parameter
-
-*change from 1028 to 1280
-
-Signed-off-by: Frank Huang
-diff --git a/src/lx_panel.c b/src/lx_panel.c
-index f1d0686..2e076d4 100644
a/src/lx_panel.c
-+++ b/src/lx_panel.c
-@@ -63,7 +63,7 @@ DisplayModeRec lx_panel_modes[] = {
- {MODEPREFIX, 81600, 1152, 1216, 1336, 1520, 0, 864, 865, 868, 895, 0,
- V_NHSYNC | V_NVSYNC, MODESUFFIX}
- ,/* 1152x...@60 */
--{MODEPREFIX, 108000, 1028, 1328, 1440, 1688, 0, 1024, 1025, 1028, 1066, 0,
-+{MODEPREFIX, 108000, 1280, 1328, 1440, 1688, 0, 1024, 1025, 1028, 1066, 0,
- V_NHSYNC | V_NVSYNC, MODESUFFIX}
- ,/* 1280x1...@60 */
- {MODEPREFIX, 162000, 1600, 1664, 1856, 2160, 0, 1200, 1201, 1204, 1250, 0,
---
-cgit v0.8.3-6-g21f6
reverted:
--- xserver-xorg-video-geode-2.11.9/debian/patches/001_fix_DCON_detection.patch
+++
xserver-xorg-video-geode-2.11.9.orig/debian/patches/001_fix_DCON_detection.patch
@@ -1,33 +0,0 @@
-Date: Mon, 20 Sep 2010 11:31:29 -0700
-From: Andres Salomon
-Subject: fix the DCON verification loop for LX output
-
-This is pretty clearly a bug. This should fix it (after all, that
-check is merely to see if the panel is a DCON; we don't care at
-all about the panel bit). This also adds an extra parenthesis in
-the following if() statement for clarity.
-
-I'm resisting the temptation to change GeodeRec's Output member to
-an unsigned long (for now). Bitfields should really be unsigned.
-
-Signed-off-by: Andres Salomon
-
a/src/lx_output.c 2010-09-20 18:03:52.0 +
-+++ b/src/lx_output.c 2010-09-20 18:23:41.0 +
-@@ -156,13 +156,13 @@
- GeodeRec *pGeode = GEODEPTR(pScrni);
-
- /* DCON Panel specific resolution - OLPC's one */
--if (pGeode->Output & (OUTPUT_PANEL | OUTPUT_DCON)) {
-+if (pGeode->Output & OUTPUT_DCON) {
- if (pGeode->panelMode->HDisplay == 1200 &&
- pGeode->panelMode->VDisplay == 900)
- return MODE_OK;
- }
-
--if (pGeode->Output & OUTPUT_PANEL &&
-+if ((pGeode->Output & OUTPUT_PANEL) &&
- gfx_is_panel_mode_supported(pGeode->panelMode->HDisplay,
- pGeode->panelMode->VDisplay,
- pMode->HDisplay,
-
only in patch2:
unchanged:
---
xserver-xorg-video-geode-2.11.9.orig/debian/patches/006_replace_custom_with_EXA.patch
+++
xserver-xorg-video-geode-2.11.9/debian/patches/006_replace_custom_with_EXA.patch
@@ -0,0 +1,168 @@
+From 5e72a00ad26f2052bb48fef041
Bug#988714: unblock: xserver-xorg-video-geode/2.11.20-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please unblock package xserver-xorg-video-geode This is a small documentation fix. It patches the upstream README to add information about what cdmline option is needed to be able to use this legacy X driver on a Linux kernel newer than 3.xx without having to disable vesafb. This has been a long-standing issue and was finally resolved via info provided by the Debian kernel maintainers. The bug was reassigned to this package and fix as shown in the debdiff. The package still builds with what's in Unstable and runs as before on Testing. debdiff attached. Thanks! unblock xserver-xorg-video-geode/2.11.20-6 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmCjzB4ACgkQrh+Cd8S0 17byiQ/9GvJUzR/mc4nTzKgTr9YhgsG8Tro6rkmfkgr/lQ0kA2vZAYyQUfzqgLP7 3n6KIKSouTs+w/bomoATMR72oNRzw3fvZgzl6VXLmONHOf8XtoN0CC2u224Evx6+ Gnu7pW+fHGYXahbP+/kotPNqYg8EkWYBE9oTf7BhjWvcP4+AgV1En2g8ZF2KKRff l3G4mnVp6BWl/OeBxZj/2mWRApx5BsWj0CgE5Gmn10qjIx5crxxsSlS0FIamVbFp SkXo7toLY2XQVPKfNZV4tUkTL+dyGTmhsf9e8FHvu74/73xtM1FKQEPmnCr/pIVS H3d88xnEwm1zffodWj0v1H4klgiaYHxD9d3586vDE2THlUneXvi9euAe6YJWmjhh Q5aUpEsrb0xRxXKYwxnbG8cbM4qYg2PE+h9qv5dqjDuQbaqplpCioWhbMsadXcor wUSIQZlMln2OW/OZZf1PdjxcnuurXzd/KUsn+4vKEUcbh/5mqOnxjQq/Fwh0yrZr su59lz9tBI6Lr4adxewfZls+DQm5aO+/wES12dEV8xz103ZshItCcxyYvqS+6R6t BiWZ7KT06AFdmSLKK9xH5e4b7oaLkMoIqYJvqDUseds6WWq6SlrOUyYUHNerqpk1 G7zR0bUBNd6n47bKEp6fesHYBQh2YCUH2Mk5oKmULCq27mFVk1E= =Pc5U -END PGP SIGNATURE- diff -Nru xserver-xorg-video-geode-2.11.20/debian/changelog xserver-xorg-video-geode-2.11.20/debian/changelog --- xserver-xorg-video-geode-2.11.20/debian/changelog 2021-01-03 17:11:43.0 +0200 +++ xserver-xorg-video-geode-2.11.20/debian/changelog 2021-05-17 21:58:21.0 +0300 @@ -1,3 +1,18 @@ +xserver-xorg-video-geode (2.11.20-6) unstable; urgency=medium + + * Merged patch from Git (Closes: #822112): +03_Mention-iomem-relaxed.patch + +Fixes a long-standing issue that prevents this legacy X driver from booting +with stock Linux kernels version 4 or newer. Merely adding a cmdline option +makes vesafb and legacy X drivers like this one coexist peacefully again. + +This short patch to the upstream README mentions iomem=relaxed as the fix. + +Thanks to Ben Hutchings for figuring this one out. + + -- Martin-Éric Racine Mon, 17 May 2021 21:58:21 +0300 + xserver-xorg-video-geode (2.11.20-5) unstable; urgency=medium * [watch] diff -Nru xserver-xorg-video-geode-2.11.20/debian/patches/03_Mention-iomem-relaxed.patch xserver-xorg-video-geode-2.11.20/debian/patches/03_Mention-iomem-relaxed.patch --- xserver-xorg-video-geode-2.11.20/debian/patches/03_Mention-iomem-relaxed.patch 1970-01-01 02:00:00.0 +0200 +++ xserver-xorg-video-geode-2.11.20/debian/patches/03_Mention-iomem-relaxed.patch 2021-05-17 21:55:02.0 +0300 @@ -0,0 +1,37 @@ +From ae82f4b2746eb24295389f184bc18a9cb6c8f31c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Martin-=C3=89ric=20Racine?= +Date: Mon, 17 May 2021 21:50:23 +0300 +Subject: [PATCH] Mention iomem=relaxed in the README FAQ for Linux 4.x+ + requirements +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Thanks to Ben Hutchings for pointing out that vesafb and legacy X +drivers can peacefully coexist if iomem=relaxed gets added to the +Linux kernel cmdline options. + +Signed-off-by: Martin-Éric Racine +--- + README | 5 - + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/README b/README +index e3ec6ee..111f9a6 100644 +--- a/README b/README +@@ -94,7 +94,10 @@ A: Since kernel 4.x Linux has strong memory protection. If the kernel is + +GRUB_GFXPAYLOAD_LINUX=text + +- Once this option has been added and the GRUB configuration refreshed, ++ Alternately, adding iomem=relaxed to GRUB_CMDLINE_LINUX_DEFAULT will ++ allow the video memory to be accessed by vesafb and the GEODE driver. ++ ++ Once either option has been added and the GRUB configuration refreshed, +the GEODE driver will launch on recent kernels as previously. + + Q: Why doesn't the GEODE driver work at WXGA (wide screen) resolutions? +-- +2.20.1 + diff -Nru xserver-xorg-video-geode-2.11.20/debian/patches/series xserver-xorg-video-geode-2.11.20/debian/patches/series --- xserver-xorg-video-geode-2.11.20/debian/patches/series 2020-12-15 20:27:27.0 +0200 +++ xserver-xorg-video-geode-2.11.20/debian/patches/series 2021-05-17 21:57:57.0 +0300 @@ -1,2 +1,3 @@ 01_fno-common.patch 02_Updated-the-README.patch +03_Mention-iomem-relaxed.patch
Fwd: Bug#900108: xserver-xorg-video-geode: FTBFS with xserver 1.20
Greetings, It ought to be noted that: 1) FTBFS #900108 was fixed ages ago. 2) It only concerns building against Xserver 1.20, which has been stuck in unstable for ages. 3) Basically, the version in testing works as expected with the Xserver that is in testing. Despite this, xf86-video-geode has been slated for removal. I'd really like to know why. Martin-Éric 2018-05-26 12:28 GMT+03:00 Emilio Pozuelo Monfort : > Source: xserver-xorg-video-geode > Version: 2.11.19-3 > Severity: serious > Tags: patch > > geode fails to build with xserver 1.20. There is a patch available > upstream but no release at this time: > > https://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=8382e6bb0c76a8029493eae3f2d7a3dbfd0cfc12 > > Emilio
in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW. Since Etch will be Debian's first UTF-8 release - implying a migration from legacy encodings for those upgrading from Sarge, which is precisely what this tool tackles - it would be nice to approve it for Etch. -- Martin-Éric Racine http://q-funk.iki.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: in NEW: utf8-migration-tool -- Debian UTF-8 migration wizard
su, 2006-12-31 kello 20:42 +0500, Alexander E. Patrakov kirjoitti:
> Martin-Éric Racine wrote:
> > su, 2006-12-31 kello 18:55 +0500, Alexander E. Patrakov kirjoitti:
> >> Martin-Éric Racine wrote:
> >>> Having merged Vincent's patch, I uploaded utf8-migration-tool to NEW.
> >>>
> >>> Since Etch will be Debian's first UTF-8 release - implying a migration
> >>> from legacy encodings for those upgrading from Sarge, which is precisely
> >>> what this tool tackles - it would be nice to approve it for Etch.
> >> Hello,
> >>
> >> 1) [EMAIL PROTECTED]:~$ utf8migrationtool
> >> Unexpected error: exceptions.IOError
> >> Traceback (most recent call last):
> >>File "/usr/bin/utf8migrationtool", line 40, in ?
> >> dmrc = getconfig()
> >>File "/usr/bin/utf8migrationtool", line 34, in getconfig
> >> config.readfp(open(os.path.expanduser('~/.dmrc')))
> >> IOError: [Errno 2] No such file or directory: '/home/patrakov/.dmrc'
> >
> > Works fine here, so no comment.
>
> This is because you have the .dmrc file. I don't (I created an empty file to
> get past this error when writing my first mail). This file presumably
> belongs to gdm, but I don't have gdm (I use "startx"), and your package
> installs fine without gdm. Missing dependency?
I don't see why it would depend upon GDM, though, since Ubuntu (which is
where the package originates from) also supports KDE and XFCE.
> >> 2) The tool must handle the already-migrated case better (e.g., by adding
> >> a
> >> line about that onto the second screen).
> >
> > It does. Here, it says that the locale is already migrated. It also says
> > that it cannot find any files utilizing a legacy encoding.
>
> Yes, it does, in the case when the old locale is from .dmrc.
It's starting to look that way. :(
> >> 3) The legacy locale for Russia is ru_RU.KOI8-R, not ru_RU, and the
> >> migration tool must handle this special case.
> >
> > Russian is a messy case. Too many encodings, more than half of which are
> > OS-specific or otherwise standards that never gained momentum. This is
> > further complicated by usage cases: while Unices tend to go for KOI8-R,
> > users that need to interact with Windows use CP1251 instead. Still, it's
> > up to Russian developers to add support for this; upstream simply cannot
> > anticipate every possible exception.
>
> OK, I temporarily take this back (because the old report was based on empty
> .dmrc - but anyway, you could take the .KOI8-R part from $LANG). However, I
> replace my old report with this: when the old .dmrc contains
>
> [Desktop]
> Language=ru_RU.KOI8-R
>
> the migration tool migrates this to ru_RU.KOI8-R.UTF-8 which is wrong. Also
> it migrates [EMAIL PROTECTED] to [EMAIL PROTECTED]
>
> The locale names generally have the form:
>
> [EMAIL PROTECTED] (where .CODESET and @MODIFIERS may or may not be
> present). The old codeset and the @euro modifier (but probably not other
> modifiers) must be stripped out.
Noted.
> >> 4) migration of encodings is only a part of the game. The most important
> >> part is to deal with packages that do not work correctly in UTF-8 locales
> >> and cannot be fixed (e.g., a2ps). Since this part cannot be automated (as
> >> nobody has created such blacklist), I suggest mentioning this obstacle in
> >> the manual page and on the welcome screen.
> >
> > Remaining UCS issues really belong in Etch's release notes, since it is
> > Debian's first release claiming UTF-8 support.
>
> Yes, they do. However, not everyone reads the release notes,
Which then becomes the user's own problem.
> >> Thus, I cannot recommend migration of this package to Etch in its current
> >> shape.
>
> And I still say this.
Sadly, I'm starting to agree. :(
However, this also means that users will need to manually upgrade their
system, which his far from ideal.
If anyone would care to contribute code towards fixing the above, it
would still be highly relevant for Etch. At any rate, this software's
usefulness post-Etch would essentially be zero, so it's pretty much a
now-or-never case.
--
Martin-Éric Racine
http://q-funk.iki.fi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unblock request: gaim-irchelper
Only a documentation fix, but it could be worth including for Etch: gaim-irchelper (0.13-5) unstable; urgency=low * Added missing IDEAS and PHILOSOPHY documents (Closes: #404360). -- Martin-Éric Racine http://q-funk.iki.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
unblock request: utf8-migration-tool
utf8-migration-tool is a GTK2 druid to help desktop users migrate to a fully UTF-8 environment. Since Etch will be our first UTF-8 by default release, this is pretty much the last time when users upgrading from earlier Debian releases will need such a tool. bubulle and the i18n team tested it thoroughly and helped fix all known bugs. fjp supports inclusion into Etch. -- Martin-Éric Racine http://q-funk.iki.fi
unblock request: cups-pdf
Closes an RC bug and makes the package Policy compliant again. PS: utf8-migration-tool also needs unblocking. -- Martin-Éric Racine http://q-funk.iki.fi
unblock request: cups-pdf
It seems that there is a gotcha with chmod and chown that makes the whole postinst content order-sensitive. This was broken in cups-pdf 2.4.2-2 and is now fixed in 2.4.2-3. -- Martin-Éric Racine http://q-funk.iki.fi
Re: unblock request: cups-pdf
On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote: On Tue, Feb 20, 2007 at 03:36:52AM +0200, Martin-Éric Racine wrote: > It seems that there is a gotcha with chmod and chown that makes the > whole postinst content order-sensitive. This was broken in cups-pdf > 2.4.2-2 and is now fixed in 2.4.2-3. And has 2.4.2-3 been tested in Debian, given that 2.4.2-2 clearly wasn't? kmuto tested it on his system. It works for him. -- Martin-Éric Racine http://q-funk.iki.fi
Re: unblock request: cups-pdf
On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote: On Wed, Feb 21, 2007 at 04:56:00AM +0200, Martin-Éric Racine wrote: > On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote > >And has 2.4.2-3 been tested in Debian, given that 2.4.2-2 clearly wasn't? > kmuto tested it on his system. It works for him. Ok, unblocked. Thanks! Btw, I'm curious, about what the situation regarding utf8-migration-tool is. My understanding was that fjp and bubulle support including this one with Etch to help users migrating from earlier releases, but earlier requests to this list on this issue remain unanswered. -- Martin-Éric Racine http://q-funk.iki.fi
Re: unblock request: cups-pdf
On 2/21/07, Steve Langasek <[EMAIL PROTECTED]> wrote: On Wed, Feb 21, 2007 at 07:49:47AM +0200, Martin-Éric Racine wrote: > Btw, I'm curious, about what the situation regarding > utf8-migration-tool is. My understanding was that fjp and bubulle > support including this one with Etch to help users migrating from > earlier releases, but earlier requests to this list on this issue > remain unanswered. Frans and Christian have supported the *principle* of having such a tool included in etch, but neither has indicated that they're able to speak for the quality of this *particular* tool. That makes it difficult to judge that allowing this new package in is a safe change that improves Debian, because there's a lack of information available, and this is precisely the sort of tool that screams "will cause data loss if anything goes wrong." That affirmation is unsubstanciated. Successful use reports from folks using this package in Debian might tip the balance; but in the absence of bug reports, "works good" is indistinguishable from "no one's using it". There's been plenty of bug reports early on and all issues brought up were fixed. Tests were also made with a variety of locales. At worst, in a few rare cases, the tool reported being unable to process the input files. So, no, it doesn't cause data loss. As for "no one's using it", there's ample Popularity Contest" data to disqualify that statement. -- Martin-Éric Racine http://q-funk.iki.fi
freeze exception request: xserver-xorg-video-geode
Greetings, A bug has been found that only affects some of the hardware supported by xserver-xorg-video-geode and causes a hardware freeze during X launch, because of a hard-coded value in the DDC probing code. It only affects GX2 variants of the Geode; LX variants are not affected. Upstream is aware of the issue and has a fix in mind, but currently little time to produce it and is asking until when can Debian allow a freeze exception for Lenny. Two possible fixes for this issue: 1) Release a patched GEODE 2.10.0 package e.g. debian/patches usage produced using only that GIT commit, as soon as it's available. 2) Wait until the GEODE 2.12.0 including that fix is released (mid-September, according to upstream milestone) and package that for Lenny. Awaiting RM team's verdict on how to best proceed. Best Regards, -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/7/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Wed, 06 Aug 2008 17:53:31 +0300]: > > 2) Wait until the GEODE 2.12.0 including that fix is released > > No, this is not possible at all. Zero chances. > > > 1) Release a patched GEODE 2.10.0 package > > This would be acceptable if the fix is targetted and not invasive. http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.10.0-4.1.dsc The proper version to use is unclear to me, because this is an update, but not an NMU. I cannot use -5 since we already have -6 in experimental and the experimental version is needed to test build against newer X servers that won't go into unstable until after Lenny is out. Also note that I haven't been able to test this on GX2/CS5535 since I don't have access to such hardware. However, I have been able to verify that it doesn't introduce any regression on already supported LX/CS5536. -- Martin-Éric Racine http://q-funk.iki.fi
Re: [Pkg-cups-devel] Bug#489554: cups-pdf: bashism in /bin/sh script
Unless I'm mistaken, the enclosed patch could fix this. If this looks good to RM team, I'd request a freeze exception to upload a new package with this fix. On 7/6/08, Martin-Éric Racine <[EMAIL PROTECTED]> wrote: > If you examine the upstream tarball more closely, you'll notice that > those sample scripts are not supported by upstream or by Debian. > Instead, they were contributed by third-parties and are included only > as a convenience to help users who need to configure cups-pdf for > non-default usage cases. -- Martin-Éric Racine http://q-funk.iki.fi --- contrib/SELinux-HOWTO/update-module.orig 2007-05-04 14:47:43.0 +0300 +++ contrib/SELinux-HOWTO/update-module 2008-08-13 12:44:21.0 +0300 @@ -16,25 +16,25 @@ SEMODULE=`which semodule` echo "" -if [ "x$SELINUXENABLED" == "x" ]; then +if [ "x$SELINUXENABLED" = "x" ]; then echo "Cannot locate executable 'selinuxenabled' (via 'which' command)." echo "Script '$0' terminated (exit code 1)." exit 1 fi -if [ x"$GETENFORCE" == "x" ]; then +if [ x"$GETENFORCE" = "x" ]; then echo "Cannot locate executable 'getenforce' (via 'which' command)." echo "Script '$0' terminated (exit code 2)." exit 2 fi -if [ x"$GETSEBOOL" == "x" ]; then +if [ x"$GETSEBOOL" = "x" ]; then echo "Cannot locate executable 'getsebool' (via 'which' command)." echo "Script '$0' terminated (exit code 3)." exit 3 fi -if [ x"$CHECKMODULE" == "x" ]; then +if [ x"$CHECKMODULE" = "x" ]; then echo "Cannot locate executable 'checkmodule' (via 'which' command)." echo "The following command will correct this (re-run this script afterward):" echo "$ sudo yum install checkpolicy" @@ -42,13 +42,13 @@ if [ x"$CHECKMODULE" == "x" ]; then exit 4 fi -if [ x"$SEMODULE_PACKAGE" == "x" ]; then +if [ x"$SEMODULE_PACKAGE" = "x" ]; then echo "Cannot locate executable 'semodule_package' (via 'which' command)." echo "Script '$0' terminated (exit code 5)." exit 5 fi -if [ x"$SEMODULE" == "x" ]; then +if [ x"$SEMODULE" = "x" ]; then echo "Cannot locate executable 'semodule' (via 'which' command)." echo "Script '$0' terminated (exit code 6)." exit 6 @@ -68,7 +68,7 @@ if [ `$GETENFORCE` != "Enforcing" ]; the exit 12 fi -if [ "`$GETSEBOOL cupsd_disable_trans`" == "cupsd_disable_trans --> on" ]; then +if [ "`$GETSEBOOL cupsd_disable_trans`" = "cupsd_disable_trans --> on" ]; then echo "Security policy ignored for cupsd transactions; this script is unnecessary." echo "The following command will correct this (re-run this script afterward):" echo "$ sudo setsebool -P cupsd_disable_trans 0"
freeze exception request: rus-ispell
Greetings, The last time upstream produced an update to this Russian wordlist for ispell/myspell/aspell was 2 years ago. An update would be very desirable, as I've gotten plenty of user feedback that Debian's writing aids for Russian are of very poor quality, because they don't nearly cover enough words for daily usage yet. -- Martin-Éric Racine http://q-funk.iki.fi
Re: [Pkg-cups-devel] Bug#489554: cups-pdf: bashism in /bin/sh script
On 8/14/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Wed, 13 Aug 2008 12:51:43 +0300]: > > > Unless I'm mistaken, the enclosed patch could fix this. If this looks > > good to RM team, I'd request a freeze exception to upload a new > > package with this fix. > > > If you care about this issue, I'm ok with approving it. I generally care about the health of my packages and about meeting release goals, so yes. While this particular file indeed is third-party contributed (not coded by upstream or resulting from my packaging work either), it is nonetheless included by upstream in the tarball, so I'm trying my best to clean it up. FWIW, I had already contact the contributor of this script, when that bug initially appeared, offering him an opportunity to fix the issue himself, but he never responded. I suppose it would be nice if either Russell or Manoj could check that the fix doesn't break the script when operating under SELinux, before this gets uploaded, but this is not mandatory. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/9/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Sat, 09 Aug 2008 10:03:56 +0300]: > > > > On 8/7/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > > > * Martin-Éric Racine [Wed, 06 Aug 2008 17:53:31 +0300]: > > > > 1) Release a patched GEODE 2.10.0 package > > > > This would be acceptable if the fix is targetted and not invasive. > > > > http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.10.0-4.1.dsc > > > Diff looks fine to me, it would be accepted. Please mail again when you > have uploaded to unstable. Upstream is making a minor bugfix release (2.10.1) to address this issue and another one, tomorrow. If it's okay, I'd rather package and upload that to unstable, rather than hand-pick patches. > > Also note that I haven't been able to test this on GX2/CS5535 since I > > don't have access to such hardware. However, I have been able to > > verify that it doesn't introduce any regression on already supported > > LX/CS5536. > > Ok. If you could get somebody with GX2/CS5535 to test, that'd be > perfect, but if not, knowing that there are no regressions with the > previously functioning hardware should be enough. Someone at Ubuntu just tested the fix and confirmed that it works on their GX2/CS5535 platform. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: rus-ispell
On 8/14/08, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: > ""=?UTF-8?Q?Martin-=C3=89ric_Racine?="" <[EMAIL PROTECTED]> writes: > > The last time upstream produced an update to this Russian wordlist for > > ispell/myspell/aspell was 2 years ago. > > > > An update would be very desirable, as I've gotten plenty of user > > feedback that Debian's writing aids for Russian are of very poor > > quality, because they don't nearly cover enough words for daily usage > > yet. > > > A wordlist is something like documentation, so just upload and we will > upload. Noted. Asking for a sponsor now. http://mentors.debian.net/debian/pool/main/r/rus-ispell/rus-ispell_0.99g5-1.dsc -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/15/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Thu, 14 Aug 2008 11:30:31 +0300]: > > > > Upstream is making a minor bugfix release (2.10.1) to address this > > issue and another one, tomorrow. If it's okay, I'd rather package and > > upload that to unstable, rather than hand-pick patches. > > > If the minor issue has minor code changes as well, should be fine. You > may want to send the diff first for review, your pick. http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.10.1-1.dsc -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/16/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Fri, 15 Aug 2008 15:25:09 +0300]: > > > > On 8/15/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > > > * Martin-Éric Racine [Thu, 14 Aug 2008 11:30:31 +0300]: > > > > > > Upstream is making a minor bugfix release (2.10.1) to address this > > > > issue and another one, tomorrow. If it's okay, I'd rather package and > > > > upload that to unstable, rather than hand-pick patches. > > > > > If the minor issue has minor code changes as well, should be fine. You > > > may want to send the diff first for review, your pick. > > + * Transitioned debian/control to XSF dependency versioning files. > +This breaks backportability for Debian/Etch and Ubuntu/Gutsy, but > +it makes bin-NMU and a whole bunch of other things MUCH easier. > > It's not the time to do this. Also, I lack the knowledge to review this, > so if you want to /make your case/ this should be included, you'll have > to get some knowledgeable pkg-xorg person to review the changes and > comment here first. Actually, now is precisely the right time to do this. It had been requested for a long time, but I had postponed doing this until Lenny would be close to release, so as to avoid breaking backportability. Now that Lenny is about to become the stable release, it's no longer an issue. Anyhow, it reproduces what the standard XSF scripts do and, yes, very much needs to be included to enable bin-NMU and automated X server version bumps. > +xserver-xorg-video-geode (2.10.0-6) experimental; urgency=low > + > + * Bumped Build-Depends on X core to >= 2:1.4.99 for experimental. > + > + -- Martin-Éric Racine <[EMAIL PROTECTED]> Tue, 22 Jul 2008 07:40:34 +0300 > + > +xserver-xorg-video-geode (2.10.0-5) experimental; urgency=low > + > + * Bumped Provides to server-2.9 for upcoming X.org 1.5 core ABI. > + > + -- Martin-Éric Racine <[EMAIL PROTECTED]> Tue, 08 Jul 2008 14:16:50 +0300 > > Please don't include changelog entries for changes that are not included > on the package. Replaced by the above transition and necessary to show what happened between -4 and -7. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/16/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Sat, 16 Aug 2008 10:21:11 +0300]: > > > > Actually, now is precisely the right time to do this. It had been > > requested for a long time, but I had postponed doing this until Lenny > > would be close to release, so as to avoid breaking backportability. > > Now that Lenny is about to become the stable release, it's no longer > > an issue. > > > Sure, you are free to ignore the freeze guidelines if that's your wish, > but I'm afraid I'm not unblocking this, see below. The guidelines were followed. This change is not intrusive. > > Anyhow, it reproduces what the standard XSF scripts do and, yes, very > > much needs to be included to enable bin-NMU and automated X server > > version bumps. > > > We're not doing more X server version bumps in this release cycle, so > the fix above is irrelevant for Lenny and can be done the day after > Lenny is released without any inconvenience. It's also relevant for bin-NMU, which can be necessary whenever there is a security release for X core. That is precisely why this was requested. Again, I had only held this off until the very end because too may people depend upon this being backportable to whatever is the latest stable release. > > > +xserver-xorg-video-geode (2.10.0-6) experimental; urgency=low > > > + > > > + * Bumped Build-Depends on X core to >= 2:1.4.99 for experimental. > > > + > > > + -- Martin-Éric Racine <[EMAIL PROTECTED]> Tue, 22 Jul 2008 07:40:34 > +0300 > > > + > > > +xserver-xorg-video-geode (2.10.0-5) experimental; urgency=low > > > + > > > + * Bumped Provides to server-2.9 for upcoming X.org 1.5 core ABI. > > > + > > > + -- Martin-Éric Racine <[EMAIL PROTECTED]> Tue, 08 Jul 2008 14:16:50 > +0300 > > > > Please don't include changelog entries for changes that are not included > > > on the package. > > > Replaced by the above transition and necessary to show what happened > > between -4 and -7. > > > That is so wrong. If you include those changelog entries, you have to > explicitly mention that you are reverting them. Making this more explicit can be easily done. It's only a question of how I word the changelog entry about migrating to XSF ways for shlibs, versus updating them manually in debian/control. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On 8/16/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: > Dude, the guidelines say "changes for release goals, if they're not > invasive", not "not invasive changes, for $whatever they are". I still haven't heard in what way this change constitutes something invasive. It's a simple two-liner and its consequences are safe. > I'm pretty much done with this discussion; 2.10.1 continues to be ok for > lenny if you drop that change. See above. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On Sat, Aug 16, 2008 at 10:37 PM, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Sat, 16 Aug 2008 22:01:50 +0300]: > >> On 8/16/08, Adeodato Simó <[EMAIL PROTECTED]> wrote: >> > Dude, the guidelines say "changes for release goals, if they're not >> > invasive", not "not invasive changes, for $whatever they are". > >> I still haven't heard in what way this change constitutes something >> invasive. It's a simple two-liner and its consequences are safe. > > Oh god. I haven't said the changes are invasive: I'm NOT the one one who wrote the above «Dude, the guidelines say "changes for release goals, if they're not invasive", not "not invasive changes, for $whatever they are".», you did. >> > I'm pretty much done with this discussion; 2.10.1 continues to be ok for >> > lenny if you drop that change. Well, whatever. I could create a 2.10.1-1lenny1, just for the sake of reverting those changes and even though reverting them is pointless, then push that somewhere else. lenny-update-proposed? -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: rus-ispell
On Thu, Aug 14, 2008 at 1:28 PM, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: > ""=?UTF-8?Q?Martin-=C3=89ric_Racine?="" <[EMAIL PROTECTED]> writes: >> The last time upstream produced an update to this Russian wordlist for >> ispell/myspell/aspell was 2 years ago. >> >> An update would be very desirable, as I've gotten plenty of user >> feedback that Debian's writing aids for Russian are of very poor >> quality, because they don't nearly cover enough words for daily usage >> yet. > > A wordlist is something like documentation, so just upload and we will > upload. Uploaded to unstable. Waiting for freeze exception. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: xserver-xorg-video-geode
On Mon, Aug 18, 2008 at 9:03 PM, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Sun, 17 Aug 2008 00:59:46 +0300]: > >> Well, whatever. I could create a 2.10.1-1lenny1, just for the sake of >> reverting those changes and even though reverting them is pointless, >> then push that somewhere else. lenny-update-proposed? > > Uploading to unstable is preferred. Done. Awaiting unblocking. -- Martin-Éric Racine http://q-funk.iki.fi
Re: HPPA still *ed...
On Sun, 21 Sep 2003, Colin Watson wrote: > On Sun, Sep 21, 2003 at 04:17:50PM +0200, Josip Rodin wrote: > > On Sat, Sep 20, 2003 at 10:08:41PM -0400, Nathanael Nerode wrote: > > > HPPA doesn't have updated glibc yet (still). No ETA. > > > That means that the fixed GCC 3.3 won't build on HPPA, so it can't go > > > into 'testing'. > > > > The new glibc went into testing despite hppa, so it's probably safe to > > assume that the new gcc will follow suit. Correct me if I'm wrong, but aren't essential packages from main supposed to stay forever in unstable, until they build for all architectures, at which point it is cuatiously allowed to move to testing? Why was glibc allowed to slide down to testing when hppa (assuming that hppa is the only case) didn't build? -- Martin-Éric Racine http://www.pp.fishpool.fi/~q-funk/
Re: Some observations regardig the progress towards Debian 3.1
I'm glad to see that at least one person in the whole Debian project defends the interests of the end-user, by reminding everyone that the end-user is the most important person, as stated in the Debian project goals. Thanks Adrian! This being said, back to the the proposed improvements: Someone was recommending the creation of a pre-testing stage, where packages would be built and verified as "ready to transit down to testing". Unless I misunderstood, this stage already exists and that would be the current Unstable branch. The core of the problem, IMHO, is how unstable has become a playground that really belongs to Experimental. One example of this is, while Gnome 2.2 has made it to testing, most GTK2/Gnome2 killer apps, like Evolution, are still stuck in Unstable. Why? Two reasons: 1) Ximian cranks out more releases than the Debian maintainer can keep up with, in addition to having to fix bugs reported by Debian users. 2) New Debian builds of whichever release are built against whatever libs are in unstable. Point 1 is easy to fix: don't try to keep up, we are still at the Testing stage, at this point, so no need to be on the bleeding edge and, most of all, no need to force users to run Unstable just to get access to packages that every other distro out there has included for a few months already. * In relation to this, Mozilla 1.3 (IMHO, the last rock-solid built we've had on Debian) was good enough for Testing and should have been allowed to trickle down, instead of being constantly replaced by progressively buggier 1.4 and 1.5 releases. While the novelty factor of 1.4 and 1.5 might be fun to some, replacing packages that are just about ready to reach their 14 days without RC and go into Testing, by a newer version, is pretty much amounting to mental cruelty. I mean, did anyone even look at what Mozilla version is currently in Testing? That would be 2:1.0.0-0.woody.1, a package that should not even belong to Testing since it was built for Stable. Point 2 is more complicated to fix, because Evolution's dependencies, if we look at them recursively, always turn out to depend upon a lower level package that keeps on seeing more uploads, which means that this particular dependency never reaches Testing without divine intervention. Let's say (hypothetically - I haven't looked at Evo's dependencies) that Evolution depends upon GNU TLS, which is built against whatever version of glibc that is in Unstable. An RC bug is found in glibc, so another upload is made, which means that GNU TLS and then other dependencies must be rebuilt against the purportedly fixed version of glbic... until another series of RC bugs are found and fixed, which results in yet another upload. It never ends. My solution to this is as follow: 1) Only build packages against dependencies that already are in Testing, always. If a new package (e.g. a new Evolution from upstream) depends upon libraries or a version thereof not yet in testing, build the said library against the glibc and other dependencies in Testing, then build Evolution against that, then uploaded them both to Unstable for their 14-day processing. This should guarantee that Testing always is in a releasable state, since everything in it is only built against the libraries it offers. 2) As a result, developers of glibc, XFree or any other major package only try their new tricks in Experimental. If and only if it looks like a given version has reached a point where it's ready to use, attempt an upload to Unstable, then move on to debugging and packaging the next upstream release, within the realms of Experimental. In other words, I propose that the scope of the current 4 branches be refocused as follow: 1) experimental The hacker playground. Dodgy uploads allowed. No guarantees to anyone on the sanity of anything there. 2) unstable * Whatever was thoroughly tested by developpers in experimental and is considered ready for the masses, is cautiously uploaded here. New glibc versions that have been thoroughly debugged would fit this category. * Trusted packages entering Debian for the first time and which were built against Testing dependencies also enter the release chain here. New releases of Evolution based upon GTK2 would fit into this category. Architectures don't have to be in sync, although an attempt is made to build on all of Debian's supported architectures, as a first exercise in QA on the package; RC bugs are fixed and a new build is uploaded, until the package has passed the usual 14-day rule and finally builds on all architectures, at which point it trickles down to Testing. 3) testing Whatever passed the 14-day rule AND builds on all architectures (and no exception allowed - we don't want another gblic 2.3.2-9 going in sans hppa, thank you) trickles down to here. By doing this, Testing is ALWAYS in a releasable st
Re: Some observations regardig the progress towards Debian 3.1
On Wed, 19 Nov 2003, Adrian Bunk wrote: > On Wed, Nov 19, 2003 at 05:34:53PM +0200, Martin-Éric Racine wrote: > > * In relation to this, Mozilla 1.3 (IMHO, the last rock-solid built > > we've had on Debian) was good enough for Testing and should have been > > allowed to trickle down, instead of being constantly replaced by > > progressively buggier 1.4 and 1.5 releases. While the novelty factor of > > How do you back your statement that 1.4 and 1.5 are "progressively > buggier" than 1.3? Slower starts, clunkier and more sluggish operation, quickly slows the whole systme to a crawl because of its ever increasin memory usage over a session. > > My solution to this is as follow: > > > > 1) Only build packages against dependencies that already are in > > Testing, always. If a new package (e.g. a new Evolution from upstream) > > depends upon libraries or a version thereof not yet in testing, build > > the said library against the glibc and other dependencies in Testing, > > then build Evolution against that, then uploaded them both to Unstable > > for their 14-day processing. This should guarantee that Testing always > > As said above, there is no "14-day processing"... Whatever. It could be 50-20-5, I could care less about the exact timeframe. You still haven't commented on the overall idea of always building upon libs and other dependencies already in Testing, instead of building on, say, a glibc that is in unstable, preventing a few hundred of packages from sliding into testing, as it happened a few months ago. > > is in a releasable state, since everything in it is only built against > > the libraries it offers. > > Besides other problems, one RC bugs in the chain of packages will cause > your proposal to fail. Actually, no. > > 2) unstable > >... > > * Trusted packages entering Debian for the first time and which were > > built against Testing dependencies also enter the release chain here. > > New releases of Evolution based upon GTK2 would fit into this category. > > The way testing works, this might effectively make it impossible for new > so-version of libraries to ever enter testing... This was a proposal to _change_ the way it works. > > 4) stable > > > > Remains as conservative as before. Only receives uploads that fix RC > > bugs on its existing packages. > > That's wrong. > > The rules for stable are stricter than "fix RC bugs". Except selected > exceptions, only security fixes are allowed. This was a proposal to _improve_ the way it works. Allowing RC fixes, not just critical security advisories, would still be highly conservative, but would allow for a more robust Stable as well. > > Hopefully, the above made sense. > > No. Then you might as well stop complaining that nobody has any solutions to improve things, if you focus on nitpicking where people missed a spot on how the actual system currently works, instead of hearing out what solutions they have. You should also move to have the "end-users matter" part crossed out of Debian project, instead officially calling it for the hackers-only user-hostile bloat that it really is, and issue a press release about that. Then spend the next 10 years wondering why the masses still ignore Debian and prefered switching from Red Hat to Fedora (despite the FUD about its future) or continue choosing other distributions over Debian. Spend the same amount of time wondering why the average user would feel better if Debian developpers had added support for non-Intel architectures to Anaconda or to PGI, instead of spending 3 years _trying_ to reinvent the wheel and still coming up with something that is barely any better than Woody's floppies, from an end-user's perspective. Anyhow, I don't intend on wasting any further time on this thread. I read what I needed to know and got to notice, once again, what makes Debian so despicable. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Some observations regardig the progress towards Debian 3.1
On Thu, 20 Nov 2003, Graham Wilson wrote: > On Wed, Nov 19, 2003 at 05:34:53PM +0200, Martin-Éric Racine wrote: > > 1) experimental > > > > The hacker playground. Dodgy uploads allowed. No guarantees to anyone > > on the sanity of anything there. > > > > 2) unstable > > > > * Whatever was thoroughly tested by developpers in experimental and is > > considered ready for the masses, is cautiously uploaded here. New glibc > > versions that have been thoroughly debugged would fit this category. > > > > * Trusted packages entering Debian for the first time and which were > > built against Testing dependencies also enter the release chain here. > > New releases of Evolution based upon GTK2 would fit into this category. > > > > Architectures don't have to be in sync, although an attempt is made to > > build on all of Debian's supported architectures, as a first exercise > > in QA on the package; RC bugs are fixed and a new build is uploaded, > > until the package has passed the usual 14-day rule and finally builds > > on all architectures, at which point it trickles down to Testing. > > > > [...] > > > > Hopefully, the above made sense. > > I don't know if I agree with the idea of building against testing > (though I believe that is not exactly what you said). I indeed said exactly that: always build against what has already made it to Testing. > However, I really like your ideas about unstable and experimental. Maybe > experimental should be used more often to decrease the churn in unstable. Of > course, there are some issues with using testing, namely, the lack of > autobuilders, and difficulty with pinning. Lack of autobuilders can be remedied. Pinning is of course difficult when package versions are in constant flux. > The first could be addressed by individuals committing time and machines > to build for experimental. I can volunteer to build for alpha, i386, > mips (soon), and powerpc. Why can't everything just be cross-compiled on a _really_ fast 64-bit host belonging to the Debian project? Couldn't e.g. IBM or HP (who both support Debian in some way or another) allocate some hosts for that, for instance? > The second could be addressed by someone writing a short howto on how to set > up the preferences file for pulling certain packages from experimental. ...or to safeguard oneself against unfortunate incidents. I use the following preferences, by default, on all my hosts and on those I install for others: Package: * Pin: release a=stable Pin-Priority: 1001 Package: * Pin: release a=testing Pin-Priority: 101 Package: * Pin: release a=unstable Pin-Priority: 99 Package: * Pin: release a=experimental Pin-Priority: 9 This ensures that selected packages can be easily pulled from Testing and that others can be also pulled from Unstable, if they don't require any dependencies that cannot be satisfied by Testing. IMHO, these defaults should be installed by debootstrap, on a virgin system. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Upload of GNOME 2.6 to unstable
On Sun, 18 Apr 2004, Martin Schulze wrote: > James Curbo wrote: > > >Does Debian do "point" releases? > > > > Yes, and as a matter of fact a new revision of woody is about to come > > out. (3.0r3) > > Please take into account that there is no way we would update an entire > GNOME system in such an update. The updates are only meant to suck up > all those security patches, fix a few very critical bugs and correct > license issues. That policy really ought to be relaxed to at least include important, but not necessarily critical updates (e.g. fixes annoying, but not destructive, should become an acceptable reason. See #221404 for an example of what SHOULD become an acceptable revision item. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Upload of GNOME 2.6 to unstable
On Sun, 18 Apr 2004, Andreas Barth wrote: > * Martin-Éric Racine ([EMAIL PROTECTED]) [040418 20:10]: > > On Sun, 18 Apr 2004, Martin Schulze wrote: > > > Please take into account that there is no way we would update an entire > > > GNOME system in such an update. The updates are only meant to suck up > > > all those security patches, fix a few very critical bugs and correct > > > license issues. > > > That policy really ought to be relaxed to at least include important, but > > not > > necessarily critical updates (e.g. fixes annoying, but not destructive, > > should > > become an acceptable reason. See #221404 for an example of what SHOULD > > become an > > acceptable revision item. > > I agree that we should try to get rid of annoying bugs. But - the way > to do this is not to break our point releases, but to release Debian > quite more often. If we really manage to release Debian about once a > year, such bugs are not so bad as it seems now. > > But: Definitly point releases are _not_ the right way to get a new > gnome version in. No way. Depends. I would not have a problem with e.g. getting in a minor GNOME release, as long as it has been properley tested. For example, if 2.4.2 were to to in Sarge, but someone packaged a 2.4.3 bugfixing release after Sarge hits stable, it really should go in 3.1 r1. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Upload of GNOME 2.6 to unstable
On Sun, 18 Apr 2004, Steve Langasek wrote: > As long as the upload to unstable is clean, we can make a final decision on > GNOME 2.6's inclusion closer to the freeze. I find this answer quite acceptable and rather wise indeed: pointless to declare that package X won't go in when we clearly have no idea yet when the freeze has officialy started. Perfect. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
GNOME 2.6 definitely not ready for unstable
Today, Rhythmbox 0.8.4 entered unstable, with rather unpleasant consequences: I cannot use it, because it insists upon trying to access /dev/dsp directly. Why can't it access it directly? Because Esound is running. Why can't Rhythmbox be configured to use gstreamer0.8-esd? Because gstreamer-properties is still the old version from GNOME 2.4's gnome-media package, which means that none of the Gstreamer 0.8 options can be configured at this stage, only Gstream 0.6 can, since gnome-media 2.6 is still not available in unstable. This is a tiny example, but it clearly shows that transition from GNOME 2.4 to GNOME 2.6 is not sufficiently rehearsed to know which packages can enter unstable in what order. Back to the drawing board! -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: GNOME 2.6 definitely not ready for unstable
On Sun, 23 May 2004, Michael Banck wrote: > On Sun, May 23, 2004 at 01:36:15AM +0300, Martin-Éric Racine wrote: > > Today, Rhythmbox 0.8.4 entered unstable, with rather unpleasant > > consequences: I > > cannot use it, because it insists upon trying to access /dev/dsp directly. > > [...] > > > This is a tiny example, but it clearly shows that transition from GNOME 2.4 > > to > > GNOME 2.6 is not sufficiently rehearsed to know which packages can enter > > unstable in what order. Back to the drawing board! > > What does a new upstream release of rhythmbox have to do with GNOME 2.6? unstable != upstream. The new release requires a GNOME 2.6 a component (gnome-media) which has not yet entered unstable, for configuration, yet it was allowed to enter unstable anyhow. This just goes to show that Rhythmbox 0.8.4 should not have been allowed to enter unstable until the 2.6 gnome-core did. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Keep non-gnome2.6 package out of the discussion please [was: GNOME 2.6 definitely not ready for unstable]
On Sun, 23 May 2004, Sebastien Bacher wrote: > Le dim, 23/05/2004 à 01:36 +0300, Martin-Éric Racine a écrit : > > Today, Rhythmbox 0.8.4 entered unstable, with rather unpleasant consequences > > rhythmbox is not related to gnome2.6 at all, That's incorrect. Configuration of the audio sink used by Rhythmbox requires gnome-media 2.6.x, which is definitely a part of GNOME 2.6. Seb: I realize you're anxious to get GNOME 2.6 into unstable, but Rhythmbox proved that you want to go too far too fast. Soon, but not now. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Keep non-gnome2.6 package out of the discussion please [was: GNOME 2.6 definitely not ready for unstable]
[let's Reply-To the gnome-gtk list, as this is clearly starting to exceeed debian-release issues, as Sebastian pointed out] On Sun, 23 May 2004, Martin Schulze wrote: > Martin-Éric Racine wrote: > > > Le dim, 23/05/2004 à 01:36 +0300, Martin-Éric Racine a écrit : > > > > Today, Rhythmbox 0.8.4 entered unstable, with rather unpleasant > > > > consequences > > > > > > rhythmbox is not related to gnome2.6 at all, > > > > That's incorrect. Configuration of the audio sink used by Rhythmbox > > requires > > gnome-media 2.6.x, which is definitely a part of GNOME 2.6. > > If Rhythmbox is a third-party-program from the point of view of > GNOME, why does it mean that GNOME 2.6 is not suited for unstable > when in fact the new Rhythmbox is not suited for unstable since > it doesn't work with the packages in unstable but only with the > ones from GNOME 2.6? > > Did I miss something? What you probably meant to say is that Rhythmbox is not considered a part of gnome-core, which is indeed technically correct. However, from an end-user's point of view, something that requires upgrading core components from a newer release, IS related to that new thing, because it requires upgrading something else besides the application itself. > > Seb: I realize you're anxious to get GNOME 2.6 into unstable, but Rhythmbox > > proved that you want to go too far too fast. Soon, but not now. > > I'd rather say that Rhythmbox was too fast and should have been > uploaded to experimental instead of unstable. For me it looks > more like a bug or Rhythmbox/its maintainer than of GNOME 2.6. If I'm not mistaken, it had been there for a while. The maintainers just decided that it was finally ready to enter unstable yesterday. In practice, even once I manually fixed things following Sebastian's e-mail (something which an end-user should NEVER be expect to do - it either works right out of the box, or it doesn't), it turned out that the newer Rhythmbox has lost the ability to play several types of mp3 files and streams. This is NOT a critic of Sebastian's otherwise excellent work as a maintainer, but it is yet another proof that Rhythmbox was not ready. That and, given how Sebastian is the one that replied to my Rhythmbox bug and how he also is the one advocating entry of GNMOE 2.6 into unstable, I indeed have every reasons to beleive that a few more corners might have been cut in GNOME 2.6, the same way as Rhythmbox was released a tad too hastily. Again, I'm quite confident that every bug will eventualy be nailed down, but this butched Rhythmbox release makes me really nervous about seeing GNOME 2.6 enter unstable at _this_ stage. It just feels like it needs more testing. Getting replies along the lines of "maybe you're just too stupid to use gconf-editor" when gconfd's lack of ability to respun flawlessly and quickly after a schema has been upgraded is clearly something that happens out of no fault on the user's part, was downright rude on Sebastian's part. Given this, I was entirely in my right to yell back at him. Anyhow, the Rhythmbox situation results in two regressions: 1) configuration keys whose values are the same (esdsink is still called esdsink in gstreamer 0.8, it just resides in a different subfolder in gconf-editor), but who belong to different releases of gstreamer, need to be manually upgraded by the user, using arcane tools. This should have been automatically copied from the 0.6 keys, the first time a 0.8.x Rhythmbox version is run. 2) Gstreamer itself clearly has lost the ability to playback certain types of mp3 files and streams. This cripples Rhythmbox and, if the Gstreamer backend was selected, also affects Totem and possibly other applications that are quite likely being recompiled to use release 0.8. This is somewhat more serious, because it affects the quality of several end-user applications. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: Upload of GNOME 2.8 to unstable
On Wed, 10 Nov 2004, Jordi Mallach wrote: > The GNOME team have been talking about what the chances are of having > GNOME 2.8 uploaded to unstable since it was released upstream early in > September. > > While two months ago we never consider this to be a real possibility for > various reasons, today things have changed enough that we need to > reconsider. [...] > If we get your OK to do the upload, my personal opinion is that once 2.8 > is in unstable, it'd be difficult to not end up shipping with GNOME 2.8 > in sarge, as the new shlibs will trickle to not-so-gnome-ish packages > like Firefox and so. Others may think that it should be possible to work > as KDE packages are doing it. Again, I'm confident that it'll go > smoothly. I've been helping with building PPC packages and testing the upgrade path. I can attest that with 2.8.1 being released, plus 2.8.2 and 2.8.3 packages starting to appear, GNOME 2.8 is more than ready to enter unstable. I also agree that it resolves a lot of issues that were pending in 2.6 and, as such, wholeheartedly support releasing GNOME 2.8 with Sarge. -- Martin-Éric Racine, ICT Consultant http://www.iki.fi/q-funk/
Re: Upload of GNOME 2.8 to unstable
On Mon, 15 Nov 2004, Colin Watson wrote: > * Please make sure to get all the libraries through as quickly as > possible to reduce the impact on the rest of the distribution. > Upload with urgency=low to start with, but we may be willing to > speed things up once we see that things are going well. Coordinate > any necessary hints on #debian-release for speed. This point is self-contradictory and spells disaster: 1) You cannot have a rapid deployment with urgency=low as a priority. 2) Asking people to use urgency=low can only result in Sarge freezing exactly when this 2.6 to 2.8 transition is incomplete, which could be seriously messy. I therefore recommend using urgency=medium instead. Other than that, the rest of your release conditions make perfect sense. -- Martin-Éric Racine, ICT Consultant http://www.iki.fi/q-funk/
numlockx: package adopted and new upload in unstable
Greetings, This package (numlockx) was slated for removal. I have adopted it and uploaded a newer version that fixes most current bugs. Tonight, it has spread to unstable. Given this, would it be possible to remove it from the Sarge blacklist and allow it to trickle down to Testing in its own time? Thanks! Regards, -- Martin-Éric Racine, ICT Consultant http://www.iki.fi/q-funk/
freeze exception request: rus-ispell and ispell-et
Greetings, A user reported a small packaging mistake that somewhat hampers utilization of two of my dictionary packages: ispell-et rus-ispell The mistake is that Hash-Name should use the syntax "2-letter language code" or "2-letter language_2-LETTER COUNTY", instead of the language's name in plain English. The diff would be really small and it would restore expected behavior for calling a language-specific dictionary using aspell's command -l option. I am thus inquiring whether a freeze could be granted for Lenny to include the above fix for both packages. -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: rus-ispell and ispell-et
On Sun, Aug 24, 2008 at 9:16 PM, Luk Claes <[EMAIL PROTECTED]> wrote: > Martin-Éric Racine wrote: >> Greetings, >> >> A user reported a small packaging mistake that somewhat hampers >> utilization of two of my dictionary packages: >> >> ispell-et >> rus-ispell >> >> The mistake is that Hash-Name should use the syntax "2-letter language >> code" or "2-letter language_2-LETTER COUNTY", instead of the >> language's name in plain English. >> >> The diff would be really small and it would restore expected behavior >> for calling a language-specific dictionary using aspell's command -l >> option. >> >> I am thus inquiring whether a freeze could be granted for Lenny to >> include the above fix for both packages. > > Yes, that would be fine. > > Contact us again once it's uploaded. Uploaded. I noticed a similar breakage and other discrepancies in the ispell files, which I also fixed. -- Martin-Éric Racine http://q-funk.iki.fi
Re: [Pkg-cups-devel] Bug#489554: Bug#489554: cups-pdf: bashism in /bin/sh script
Hello Manoj, Have you had a chance to look at this issue? On Fri, Aug 15, 2008 at 5:19 AM, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > Hi, > > >I'll be happy to look at this, but I am on a business trip after > debconf, and I will not be back home until the 25th of this month. And > since my laptop charger is currently fried, I can' lookt at it while at > debconf. > >manoj -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: rus-ispell and ispell-et
On Fri, Aug 29, 2008 at 1:00 PM, Martin-Éric Racine <[EMAIL PROTECTED]> wrote: > On Sun, Aug 24, 2008 at 9:16 PM, Luk Claes <[EMAIL PROTECTED]> wrote: >> Martin-Éric Racine wrote: >>> A user reported a small packaging mistake that somewhat hampers >>> utilization of two of my dictionary packages: >>> >>> ispell-et >>> rus-ispell >>> >>> The mistake is that Hash-Name should use the syntax "2-letter language >>> code" or "2-letter language_2-LETTER COUNTY", instead of the >>> language's name in plain English. >>> >>> The diff would be really small and it would restore expected behavior >>> for calling a language-specific dictionary using aspell's command -l >>> option. >>> >>> I am thus inquiring whether a freeze could be granted for Lenny to >>> include the above fix for both packages. >> >> Yes, that would be fine. >> >> Contact us again once it's uploaded. > > Uploaded. > > I noticed a similar breakage and other discrepancies in the ispell > files, which I also fixed. It turns out that I had to partially roll-back the changes in ispell. The new ispell-et is uploaded, but the new rus-ispell still awaits sponsoring at: http://mentors.debian.net/debian/pool/main/r/rus-ispell/rus-ispell_0.99g5-4.dsc -- Martin-Éric Racine http://q-funk.iki.fi
Re: freeze exception request: rus-ispell and ispell-et
On Thu, Sep 11, 2008 at 11:05 PM, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: > Holger Levsen <[EMAIL PROTECTED]> writes: >> On Tuesday 09 September 2008 13:20, Martin-Éric Racine wrote: >>> It turns out that I had to partially roll-back the changes in ispell. >>> >>> http://mentors.debian.net/debian/pool/main/r/rus-ispell/rus-ispell_0.99g5-4 >>>.dsc >> uploaded to ftp-master. > > Unblocked. Thanks! Could the same be done for ispell-et? -- Martin-Éric Racine http://q-funk.iki.fi
Re: Bug#499269: dictionaries-common-dev: produces non Policy compliant maintainer scripts
On Wed, Sep 17, 2008 at 6:39 PM, Agustin Martin <[EMAIL PROTECTED]> wrote: > reassign 499269 dictionaries-common > retitle 499269 Should not use full paths in maintainer scripts > thanks > > On Wed, Sep 17, 2008 at 03:04:00PM +0300, Martin-Éric Racine wrote: >> Package: dictionaries-common-dev >> Severity: important >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> As found while looking at the Lintian report for my dictionary packages: >> >> iestonian >> >> * W command-with-path-in-maintainer-script >> o postrm:5 /usr/sbin/remove-default-ispell >> >> aspell-et >> >> * W command-with-path-in-maintainer-script >> o postrm:6 /usr/sbin/update-dictcommon-aspell >> >> aspell-lv >> >> * W command-with-path-in-maintainer-script >> o postrm:6 /usr/sbin/update-dictcommon-aspell >> >> irussian >> >> * W command-with-path-in-maintainer-script >> o postrm:5 /usr/sbin/remove-default-ispell >> >> aspell-ru >> >> * W command-with-path-in-maintainer-script >> o postrm:6 /usr/sbin/update-dictcommon-aspell >> >> All those Lintian warnings are the result of dictionaries-common-dev >> generating maintainer scripts that are not Policy-compliant. >> >> As per Debian Policy: >> >> Commands that reside in standard system paths should not have >> the full path prepended to them. > > Yes, I am aware of this, but this lintian check is recent (Early August), > so I noticed its effects once lenny was frozen. dictionaries-common > maintainer scripts suffer from the same problem, so I am reassigning this > bug report to the basic package. > > Will be fixed once lenny is released. I think that RM would have no problem allowing a freeze exception to make dictionaries-common Policy-compliant, followed by a bin-NMU trigger to rebuild all dictionaries. Would the RM team please comment on this issue? Cheers! -- Martin-Éric Racine http://q-funk.iki.fi
Re: please unblock myspell 1:3.0+pre3.1-22 (was: Re: Bug#499271: verified to be caused by myspell-tools)
On Thu, Sep 18, 2008 at 5:23 PM, Rene Engelhard <[EMAIL PROTECTED]> wrote: > Hi, > > Agustin Martin wrote: >> I have been reviewing original patch and seems I found the problem. tmpfiles >> are created in the midle of a pipe. Original program uses implicit >> continuation lines, and there was the tmpfile creation. Seems that with >> attached patch in myspell tools a russian dict can be created with a non >> void aff file. >> >> See attached patch. >> >> Rene, let me know if you will do the upload or I should NMU. > > I don't mind; I just uploaded it though. Thanks for the patch. > > release team: can you please unblock myspell 1:3.0+pre3.1-22 which fixes > a regression e.g. in rus-ispell (#499236) caused by the "symlink attack" > patch. > > Almost identical ( I just changed the version, me on the uploader and > thanked Agustin) patch like to what I uploaded is this: Thanks for fixing this! Could someone please schedule a bin-NMU trigger in 2 days for src:rus-ispell, to implement the fix and rebuild the faulty dictionaries? -- Martin-Éric Racine http://q-funk.iki.fi
Re: please unblock myspell 1:3.0+pre3.1-22
On Sun, Sep 21, 2008 at 1:47 AM, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote: > Rene Engelhard <[EMAIL PROTECTED]> writes: >> release team: can you please unblock myspell 1:3.0+pre3.1-22 which fixes >> a regression e.g. in rus-ispell (#499236) caused by the "symlink attack" >> patch. > > Unblocked. We'd also need a bin-NMU on rus-ispell to actually use the fixed myspell-tools and rebuild the dictionary files. Just to be safe, I'd also like the same to be done for ispell-et and myspell-lv. -- Martin-Éric Racine http://q-funk.iki.fi
Re: Bug#499236: aspell-ru: does not recognise flexional word forms any longer
On Thu, Sep 25, 2008 at 10:51 PM, Johannes Rohr <[EMAIL PROTECTED]> wrote: >> As a test, could you check documents that you normally work on with >> Gedit using e.g. Nano or VI in a terminal with irussian? >> >> If proof reading works with irussian, then we'll know that the problem >> is with the tools used to generate myspell-ru (which would also affect >> aspell-ru). [...] > So, something about the build process must be broken. Yes, myspell-tools was broken. A fixed version has been uploaded, but this now means that all packages who Build-Depend on myspell-tools must be rebuilt via bin-NMU. This is a process that requires the intervention of release managers. -- Martin-Éric Racine http://q-funk.iki.fi
Re: 499...@bugs.debian.org
2008/10/4 Dmitry Astapov > Hi, > > I've been tracking the progress of this bug with great interest and I'm > happy to say that with ver. 0.99g5-5 of aspell-ru (and myspell-ru) russian > spelling for flexional came back to norm. Thank you for your efforts! > > The only minor annoyance that is left is that aspell indeed insist on using > "yo" (ё) instead of "ye" (е), and I vivdly remember the time when that was > not the case. From the discussion here I gather that it is a matter of some > build-time switch to enable or disable this behavoir. Could it be turned off > by default or both alternatives provided (a-la w_accents/wo_accents for > other languages)? The only thing we do at built time is to generate all yo variants from ye-only words as per upstream Makefile. We do not force usage of one spelling over the other. Anyhow, this bug's issue was about inflections being broken and, based on Dmitry's above report, I will now close this bug. RM: this means that the package may now safely be unblocked. I'll produce similar no-change uploads for my other ispell-generated dictionaries later this weekend. -- Martin-Éric Racine http://q-funk.iki.fi
Re: [EMAIL PROTECTED]
On Thu, Oct 9, 2008 at 1:02 PM, Adeodato Simó <[EMAIL PROTECTED]> wrote: > * Martin-Éric Racine [Sat, 04 Oct 2008 07:50:20 +0300]: >> RM: this means that the package may now safely be unblocked. I'll >> produce similar no-change uploads for my other ispell-generated >> dictionaries later this weekend. > > Unblocked rus-ispell/0.99g5-5, please mail again when the other packages > have been uploaded. ispell-et 1:20030606-11 was uploaded today. Martin-Éric
freeze exception: src:rus-ispell
Greetings, The following package needs both sponsoring and a freeze exception: http://mentors.debian.net/debian/pool/main/r/rus-ispell/rus-ispell_0.99g5-7.dsc To put the bug in context, some recent changes in the way some building tools work under encodings other than the C locale have resulted in a partially broken build. The result are 3 Russian dictionaries (ispell/aspell/myspell) that are mostly useless for everyday usage. To give you a sense of scale of the problem, this is the same as if English dictionaries were produced from a source package called eng-ispell, from which American and British spelling variants would be generated using some build script magic. Now, imagine a situation where, because of some changes in basic binary tools (tr, grep, uniq), the build targets would produce dictionaries that only included the British spelling, in a situation where the American spelling is obviously the most widespread worldwide. This is precisely the situation that currently plagues the Russian dictionaries. There is essentially two spelling variants for many Russian words, one with a specific vowel accented (traditional spelling, mostly used by academicians, these days) and a contemporary form with that same vowel unaccented. During the last few months, debian/rules scripts that had worked just fine as-is for ages suddenly started producing dictionaries that only included the traditional variant, in a context where the modern variant is obviously more useful in contemporary usage. This issue had gone mostly unnoticed for several months, since I myself prefer to use the traditional spelling. It took the work of several contributors to find a clean way of fixing this and we just barely got around finding a method that produces usable dictionaries in a repeatable way, which is how this request came so close to the Lenny release. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: freeze exception: src:rus-ispell
On Thu, Feb 5, 2009 at 2:55 PM, Adeodato Simó wrote: > * Stepan Golosunov [Wed, 04 Feb 2009 00:37:06 +0400]: > >> Martin-Éric Racine writes: > >> > The following package needs both sponsoring and a freeze exception: > >> > http://mentors.debian.net/debian/pool/main/r/rus-ispell/rus-ispell_0.99g5-7.dsc > >> > To put the bug in context, some recent changes in the way some >> > building tools work under encodings other than the C locale have >> > resulted in a partially broken build. The result are 3 Russian >> > dictionaries (ispell/aspell/myspell) that are mostly useless for >> > everyday usage. > >> I don't think broken 0.99g5-6 reached testing. > >> And the "bug" #511290 it was trying to fix is controversial. The >> purpose of the changes is to allow some obsolete spelling variants to >> be considered as valid. > > Okay, I'll take this as an indication that no action from the release > team is needed unless further notice. Actually, Stepan's got that one backwards: 0.99g5-7 *restores* support for the contemporary spelling. Support for the traditional spelling never disappeared. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: freeze exception: src:rus-ispell
On Thu, Feb 5, 2009 at 4:54 PM, Adeodato Simó wrote: > * Martin-Éric Racine [Thu, 05 Feb 2009 16:34:29 +0200]: > >> >> I don't think broken 0.99g5-6 reached testing. > >> >> And the "bug" #511290 it was trying to fix is controversial. The >> >> purpose of the changes is to allow some obsolete spelling variants to >> >> be considered as valid. > >> > Okay, I'll take this as an indication that no action from the release >> > team is needed unless further notice. > >> Actually, Stepan's got that one backwards: 0.99g5-7 *restores* >> support for the contemporary spelling. Support for the traditional >> spelling never disappeared. > > That's not really relevant. What is interesting is whether Stepan's > assessment that 0.99g5-5 is not affected by this issue is correct or > not. As far as I've been told by users, it is affected too. Again, I myself use traditional spellings, so I've never been affected by this issue. Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#1040951: Bug#1037190: closed by Debian FTP Masters (reply to Martin-Éric Racine ) (Bug#1037190: fixed in dhcpcd 10.0.1-1)
On Sun, Jul 16, 2023 at 7:07 PM Martin-Éric Racine wrote: > > On Fri, Jul 14, 2023 at 9:59 AM Martin-Éric Racine > wrote: > > > > On Thu, Jul 13, 2023 at 8:15 AM Martin-Éric Racine > > wrote: > > > > > > On Thu, Jul 13, 2023 at 8:01 AM Martin-Éric Racine > > > wrote: > > > > > > > > On Thu, Jul 13, 2023 at 3:21 AM Andreas Beckmann > > > > wrote: > > > > > > > > > > On 11/07/2023 07.05, Martin-Éric Racine wrote: > > > > > >> This is what I would push to stable-proposed-updates (see > > > > > >> attachment). > > > > > >> Would this do the trick? If yes, I can upload to Mentors. If not, > > > > > >> please explain. > > > > > > > > > > > > Package waiting on Mentors. > > > > > > > > > > Looks good. Minor nitpicks: > > > > > - in d/changelog: use "bookworm" instead of "stable-proposed-updates" > > > > > - close the bug #1037190 > > > > > > > > > > Can you put the commits in a new debian/bookworm branch on salsa, > > > > > starting from tag debian/9.4.1-24? > > > > > > > > > > I'll sponsor that upload for you. > > > > > > > > E: dhcpcd5 changes: bad-distribution-in-changes-file bookworm > > > > > > > > Re-uploaded to Mentors. > > > > > > Scratch that. Mentors doesn'r know about any release newer than > > > Bullseye and rejected the upload. Debdiff attached. > > > > > > Martin-Éric > > > > > > PS: I don't know how to fork a branch on Git. My Git skills are minimal. > > > > It seems that they finally fixed Mentors. Upload accepted. > > > > https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-24+deb12u1.dsc > > https://release.debian.org/proposed-updates/stable.html > > Indicates concerns about the version number. The answer is clear: In > Testing, dhcpcd5 9.4.1 is superced by dhcpcd 10.0.1 (same binary > targets, but src:package drops the 5). > > The other concern is whether all changes are suitable. They are. It also seems that the above page somehow missed bug #1040951 for the request. Martin-Éric
Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1
On Sat, Jul 22, 2023 at 4:57 PM Jonathan Wiltshire wrote: > > Control: tag -1 confirmed > > On Sat, Jul 22, 2023 at 02:54:18PM +0300, Martin-Éric Racine wrote: > > Since <https://release.debian.org/proposed-updates/stable.html> posed > > some reservations about the suitability of changes since 9.4.1-22, > > here's the debdiff compared to that. > > > > It should also be noted that src:dhcpcd5 has been replaced by > > src:dhcpcd in testing/unstable, which ships a newer upstream release, > > thus the version of this bookworm update is not higher. > > > > Martin-Éric > > > diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog > > --- dhcpcd5-9.4.1/debian/changelog2023-05-24 15:03:22.0 +0300 > > +++ dhcpcd5-9.4.1/debian/changelog2023-07-13 07:56:52.0 +0300 > > @@ -1,3 +1,31 @@ > > +dhcpcd5 (9.4.1-24+deb12u1) bookworm; urgency=medium > > With the version as 9.4.1-24~deb12u1, please go ahead. The existing upload > will be rejected. Alright. Uploading again with corrected version. Thanks. Matin-Éric
Bug#1041712: RM: dhcpcd5/9.4.1-24; ROM; replaced by src:dhcpcd in testing/unstable
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: dhcp...@packages.debian.org Control: affects -1 + src:dhcpcd5 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please remove src:dhcp5 from testing/unstable. It is replaced by src:dhcpcd starting with Trixie. Thanks! Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmS75aYACgkQrh+Cd8S0 17Zhpg//VHDct8WT3fH5HsZorpF3NCgeV5cMrM9cI303l/Of1Ns0vtCqb4t5eYcX 4pipEjKY24fdRCOhQOqyUJzx5TV+HT26g2eG5nsNOwj04UyCPDSX2qyy8r4gwAr1 JQxqaEi4sDJVtSw7kfp/LMCCbt+s2cMJduAwtXIUxxFYKwxjcEygpj60ctyd57mf vFRSBOBG7bGXfHJYumHlamQL9VpdnNuOiP/PO8TOOkdGgpm51lBJPnGy5H6F9VI7 tixOWPxDtEbs8Gi6KbMND5Fk3utZPeYi1URnUZDUsxhJz0jCv0mcyeKpxaUsNkGL 4yBP2t8HIOFyNi69FXl0NZsRONxe4l0GJHhNkm9JDqrLLL3pxTNSiaTf2L8Oo5QI YgghHA+o9lhtyMGnZ4gZQoQfNOwt+kjhiNkziPiNvcbNby5UtBzqeYGZDwcsZW8X tN+yckTDKJ/8sd/7WD8cBuG03ZgIkjRfKJmCsMdxONyx+Cnlqc5ph7zS2BzSiEzY S9EuBYmRuz/qvCyBzL/IfUFhICkOfqvgNWM8CBhrj5N2Gwc0F9JctCSGz2pqLjiH howD48RhlV1iXcQIyyU/lEaDC+QG88rB3ZsNKRAC8ydhjc8OJGrmWH05RdFUpT2S EgItznhpzTS+XXA8XohDGPjlyRMQ6iNWzXQx2JN1T+CZUR81+UM= =UquD -END PGP SIGNATURE-
Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1
On Sat, Jul 22, 2023 at 5:07 PM Adam D. Barratt wrote: > > On Sat, 2023-07-22 at 14:57 +0100, Jonathan Wiltshire wrote: > > Control: tag -1 confirmed > > > > On Sat, Jul 22, 2023 at 02:54:18PM +0300, Martin-Éric Racine wrote: > > > Since <https://release.debian.org/proposed-updates/stable.html> > > > posed > > > some reservations about the suitability of changes since 9.4.1-22, > > > here's the debdiff compared to that. > > > > > > It should also be noted that src:dhcpcd5 has been replaced by > > > src:dhcpcd in testing/unstable, which ships a newer upstream > > > release, > > > thus the version of this bookworm update is not higher. > > > > > For the record, it has *not* been replaced, at least at this point in > time. Both source packages still exist in both testing and unstable. > > dhcpcd | 1:10.0.1-3| unstable | source > dhcpcd | 1:10.0.2-1| testing| source, all > dhcpcd | 1:10.0.2-1| unstable | source, all > dhcpcd | 1:10.0.2-1| unstable-debug | source > > dhcpcd5| 9.4.1-24 | testing| source, all > dhcpcd5| 9.4.1-24 | unstable | source > dhcpcd5| 9.4.1-24 | unstable-debug | source > dhcpcd5| 9.4.1-24+deb12u1 | stable-new | source > dhcpcd5| 1:10.0.1-3 | unstable | all Bug#1041712: RM: dhcpcd5/9.4.1-24; ROM; replaced by src:dhcpcd in testing/unstable Martin-Éric
Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1
On Sat, Jul 22, 2023 at 5:25 PM Martin-Éric Racine
wrote:
>
> On Sat, Jul 22, 2023 at 5:07 PM Adam D. Barratt
> wrote:
> >
> > On Sat, 2023-07-22 at 14:57 +0100, Jonathan Wiltshire wrote:
> > > Control: tag -1 confirmed
> > >
> > > On Sat, Jul 22, 2023 at 02:54:18PM +0300, Martin-Éric Racine wrote:
> > > > Since <https://release.debian.org/proposed-updates/stable.html>
> > > > posed
> > > > some reservations about the suitability of changes since 9.4.1-22,
> > > > here's the debdiff compared to that.
> > > >
> > > > It should also be noted that src:dhcpcd5 has been replaced by
> > > > src:dhcpcd in testing/unstable, which ships a newer upstream
> > > > release,
> > > > thus the version of this bookworm update is not higher.
> > > >
> >
> > For the record, it has *not* been replaced, at least at this point in
> > time. Both source packages still exist in both testing and unstable.
> >
> > dhcpcd | 1:10.0.1-3| unstable | source
> > dhcpcd | 1:10.0.2-1| testing| source, all
> > dhcpcd | 1:10.0.2-1| unstable | source, all
> > dhcpcd | 1:10.0.2-1| unstable-debug | source
> >
> > dhcpcd5| 9.4.1-24 | testing| source, all
> > dhcpcd5| 9.4.1-24 | unstable | source
> > dhcpcd5| 9.4.1-24 | unstable-debug | source
> > dhcpcd5| 9.4.1-24+deb12u1 | stable-new | source
> > dhcpcd5| 1:10.0.1-3 | unstable | all
>
> Bug#1041712: RM: dhcpcd5/9.4.1-24; ROM; replaced by src:dhcpcd in
> testing/unstable
Sure enough, I had forgotten to change the version used in
dhcpcd.preinst to the tilde one. Fixed as per attachment.
Martin-Éric
diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
--- dhcpcd5-9.4.1/debian/changelog 2023-05-24 15:03:22.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog 2023-07-22 17:56:49.0 +0300
@@ -1,3 +1,37 @@
+dhcpcd5 (9.4.1-24~deb12u2) bookworm; urgency=medium
+
+ * Fixed dhcpcd.preinst with the tilde version.
+
+ -- Martin-Éric Racine Sat, 22 Jul 2023 17:56:49
+0300
+
+dhcpcd5 (9.4.1-24~deb12u1) bookworm; urgency=medium
+
+ * Backported Wheezy upgrade mitigation from unstable (Closes: #1037190).
++ Include /usr/share/dpkg/pkg-info.mk needed for target version mingling.
++ Add epoch to bin:dhcpcd via override_dh_gencontrol.
+ Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target.
++ Add dhcpcd.preinst by Andreas Beckmann to clean up upgrade leftovers.
+
+ -- Martin-Éric Racine Sat, 22 Jul 2023 17:00:48
+0300
+
+dhcpcd5 (9.4.1-24) unstable; urgency=medium
+
+ * Upload to unstable.
+
+ -- Martin-Éric Racine Mon, 29 May 2023 15:45:31
+0800
+
+dhcpcd5 (9.4.1-23) experimental; urgency=medium
+
+ [ Martin-Éric Racine ]
+ * Migrate both VCS addresses to 5-less ones.
+
+ [ Shengjing Zhu ]
+ * Drop Conflicts/Replaces dhcp-client (Closes: #1036085).
+ * Drop deprecated ntpd integration (Closes: #1036092).
+No longer working since ntpd was superseded by ntpsec.
+
+ -- Martin-Éric Racine Sun, 28 May 2023 06:02:59
+0300
+
dhcpcd5 (9.4.1-22) unstable; urgency=medium
[ Martin-Éric Racine ]
diff -Nru dhcpcd5-9.4.1/debian/control dhcpcd5-9.4.1/debian/control
--- dhcpcd5-9.4.1/debian/control2023-05-24 15:03:22.0 +0300
+++ dhcpcd5-9.4.1/debian/control2023-05-28 05:57:38.0 +0300
@@ -8,15 +8,13 @@
pkg-config
Rules-Requires-Root: no
Standards-Version: 4.6.2
-Vcs-Browser: https://salsa.debian.org/debian/dhcpcd5
-Vcs-Git: https://salsa.debian.org/debian/dhcpcd5.git
+Vcs-Browser: https://salsa.debian.org/debian/dhcpcd
+Vcs-Git: https://salsa.debian.org/debian/dhcpcd.git
Package: dhcpcd-base
Architecture: any
-Conflicts: dhcp-client
Provides: dhcp-client
-Replaces: dhcp-client,
- dhcpcd5 (<< 9.4.1-2)
+Replaces: dhcpcd5 (<< 9.4.1-2)
Breaks: dhcpcd5 (<< 9.4.1-2)
Depends: adduser,
${misc:Depends},
diff -Nru dhcpcd5-9.4.1/debian/copyright dhcpcd5-9.4.1/debian/copyright
--- dhcpcd5-9.4.1/debian/copyright 2023-05-24 15:03:22.0 +0300
+++ dhcpcd5-9.4.1/debian/copyright 2023-07-09 22:09:15.0 +0300
@@ -4,7 +4,7 @@
Upstream-Contact: Roy Marples
Files: *
-Copyright: 2006-2018 Roy Marples
+Copyright: 2006-2023 Roy Marples
1999, 2016 The NetBSD Foundation, Inc.
2005 Colin Percival
2005 The DragonFly Project. All rights reserved.
@@ -68,6 +68,7 @@
2015 Daniel Echeverry
2018 Scott Leggett
2022-2023 Martin-Éric Racine
+ 2023 Andreas Beckmann
License: BSD-2
Files: debian/hooks/*
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst
dhcpcd5-9
