Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Preserving the rather large CC list for now… On Thu, Jun 20, 2019 at 06:05:22AM -0400, Sam Hartman wrote: I feel very uncomfortable with a change as big as this revert happening this late in the release cycle. How big is big? The MR I raised resurrects a patch that changes one line of code, and was shipped in the last stable release. Although it looks like further work is needed to make the change as smooth as possible so this would grow. However, the patch certainly needs more testing. Is the issue that it results in a large change in terms of what software is executed by the user as a consequence, and what of that has been tested thus far in the freeze? How late is late? How would you have felt about it back in early April, when I first raised it? I was surprised to discover it then, and I felt it was late in the cycle even then. But mostly whats happened since is nothing. I absolutely do not blame the GNOME team here. Simon McVittie and Michael Biebl in particular have taken risks sticking their heads above the parapet to engage with me on this matter, and both have made it clear that it would be unreasonable for them to make the call given their respective levels of involvement. I respect that, and I am extremely grateful for them engaging with the issue. The others are either too busy or have taken a decision not to engage with a potentially toxic issue, and I respect that, too: we are all volunteers who have to make our own choices about what we are prepared to do and engage in. Besides, like many teams, the GNOME team is clearly under-resourced. I am a *little* disappointed that this does not seem to have been thought of as an important, project-wide issue. Regardless of whether one uses GNOME or Wayland oneself, the matter of the default desktop for the distribution we are all working to produce, and the experience that our users will get out of the box, I would have thought was important for all of us. It reinforces the idea, to me, that we are largely working in our own silos, and not concerned (enough) about the holistic distribution as a whole. And yet, the lack of a clear reconfirmation in this time line even given the wonderfully civil discussion is telling. I'm very pleased that the discussion has come across as civil. I've tried really hard from my end to achieve that, I know that issues around GNOME can result in some very toxic communications. My proposal--which again I have no power to implement--is that we go forward with the current default. However, we remain open to a revert in the first couple of buster point releases. There are caveats with switching the default in either direction. Let's say we go with Wayland now, and later decide to switch as per the criteria/process you sketch below. • users of the default, who got Wayland from Buster onwards and had no problems, would subsequently find themselves switched to Xorg by stable-updates, which IMHO would be unexpected (if noticed) and contrary to the expectations of a stable release. • A user who installed or upgraded and got Wayland by default but had problems, would have likely addressed them by switching to the Xorg session explicitly (assuming they could figure out that doing so mitigated their issues). Changing the default would only prevent *future* users from hitting the same problems. The criteria for that revert should be based on the actual severity and frequence of problems our users run into, but should specifically exclude the blanket reluctance to make a change like that in a point release. We would still need adequate testing of such a revert. My concern with this is it's a new set of policies and procedures, not codified anywhere, with a lot of detail to work out "on the hoof" (how do we measure frequency of problems? do we go with the existing bug severity guidelines? How much is adequate testing? etc.) So combined with the user experience above, I think we would be best not to change the default within a stable release cycle, unless there was some kind of enormous catastrophic issue with Wayland that we don't know about yet, and that's unlikely. I still argue that the traditional Debian conservative, when-its-ready approach would be the distribution status quo (Xorg), but I recognise the concerns about the proposed patch, further work needed, lack of testing etc.; and those are not issues I think I can resolve alone. -- Jonathan Dowland
Re: Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop
Hi Andrew So far as I am aware there is still radio silence from active GNOME packaging team members regarding this issue. No comment yet on the patch I adapted, positive or negative; this bug (#927667) remains at an RC severity. I've not yet read all the thread that Samuel linked to[1] but it looks like it leans in favour of preserving the current default (xorg). I'm copying -release team to see if they have any (new) opinions on the matter. Otherwise I guess it's up to someone to prepare an NMU upload, which I will *try* to look at in the next few days, but can't make any guarantees. Further testers of the patch on this bug would be most welcome. [1] https://lists.debian.org/debian-accessibility/2019/02/threads.html#4
appropriate priority for bugs under Wayland?
severity 904309 normal thanks Folks, I've seen a few occurences now of bugs like this which are being given RC severity because Wayland is currently the default desktop technology for Buster. The consequence of this is that the software (here tilda, elsewhere synaptic, and perhaps others) are at risk of being dropped from Buster entirely due to incompatibility under Wayland, despite working fine under X. I'm not sure that this is fair or the right way to address issues of Wayland compatibility with other (longer established) software. I'm directing this at -release to ask the Release Team whether they have a position on the matter. Thanks! Related I'm not sure that Wayland is a suitable choice for the default desktop technology yet either (see Bug #927667 for discussion of that, as well as a subset of these bugs[1]). Please direct any thoughts on *that* to #927667 rather than here. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=wayland=pkg-gnome-maintainers%40lists.alioth.debian.org Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#926455: mail_autoremovals: incorrect version number in email warning
Package: release.debian.org Severity: normal I received the following warning mail regarding an autoremoval: > Subject: duc is marked for autoremoval from testing > Date: Fri, 05 Apr 2019 04:39:19 + > > duc 1.4.3-6 is marked for autoremoval from testing on 2019-04-20 > > It is affected by these RC bugs: > 924473: duc: FTBFS (dh_installman: Cannot find "debian/build-nox/doc/duc.1") In fact, #924473 affected duc 1.4.3-5, and 1.4.3-6 contained the bug fix. (I got a separate, correct email for 1.4.3-5, earlier.) In terms of time frame, the wrong mail was received on 5th Apr, the fix was uploaded on 30 Mar and transitioned to testing on 5th Apr, it seems 6 seconds after this mail's Date header was generated: https://tracker.debian.org/news/1037367/duc-143-6-migrated-to-testing/ -- System Information: Debian Release: 9.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sat, Sep 29, 2018 at 05:05:17PM +0200, John Paul Adrian Glaubitz wrote: Well, I have had people from IBM fix 32-bit PowerPC code. There is naturally more involvement behind the 64-bit stuff because that's where the commercial interests are. The kernel itself dropped 32bit powerpc support years ago, IIRC. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#905385: stretch-pu: package weboob/1.2-1
Hello, On Wed, Aug 15, 2018 at 04:43:41PM +0900, Marc Dequènes wrote: Jonathan, if you still feel like giving a hand, then feel free to branch on the original repo with all the insult-removal patch needed, and please add the warning message as well. I've added the additional patch and disclaimer on top of this branch in my fork, which is branched from the stretch version of the package, and the changelog is set up ready for stretch-proposed-updates: https://salsa.debian.org/jmtd/weboob/tree/905299-stretch If you are happy with this, can I suggest you create a branch for stretch in the main repo and merge this in? I've done a source-only build and put it here for your convenience https://jmtd.net/tmp/weboob_1.2-1+deb9u1.dsc (signed with my key) However I have not yet managed to convince sbuild to set up a stretch chroot and build binaries successfully (some pyqt4/5 issue, probably unrelated to these changes). So basically I think if you can take a look at my changes and if you are happy the ball is then back in the release team's court. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Bug#905385: stretch-pu: package weboob/1.2-1
On Wed, Aug 15, 2018 at 04:43:41PM +0900, Marc Dequènes wrote: I finally found some spoons to upload a fixed package with insults removed and a warning in the description. I found an extra insult which is not in upstream master, so I added an extra patch; this might be needed for backporting too but better check with grep to avoid missing some around. Thanks! Jonathan, if you still feel like giving a hand, then feel free to branch on the original repo with all the insult-removal patch needed, and please add the warning message as well. Yes I do still want to help. So to be clear, I will rework the branches in my Salsa fork for stable and oldstable to backport the patch committed to sid, and do an additional grep-check for anything missing, then I'll ping you. Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Bug#905385: stretch-pu: package weboob/1.2-1
Hi Adam, Thank you for answering my questions and clarifying the finer points of s-p-u! On Fri, Aug 03, 2018 at 10:20:59PM +0100, Adam D. Barratt wrote: The metadata for that bug suggests that the issue still affects unstable. Assuming that's correct, that needs addressing first. (If it's not, the metadata should be updated with an appropriate fixed version.) That's right; sid is affected, and not fixed yet, but people are still recovering from DebConf I think :) As per the Dev Ref and (possibly too infrequent) dda reminders, the version should be (stable)+deb9u1, and the suite "stretch". Thank you. I didn't think to check dev ref, I consulted policy instead. I'd not use me as a benchmark as to whether the dda reminders are frequent enough, althoug I don't filter them so do theoretically read them, I've been slicing my Debian time very thin in recent times. oldstable (jessie) is no longer managed by the Release Team, but has been in the hands of the LTS team since mid-June, as per https://lists. debian.org/debian-security-announce/2018/msg00132.html Thank you, I'll investigate pursuing a jessie fix via LTS. There are no point releases for any release other than stretch at this point. oldoldstable (i.e. wheezy) has been entirely out of (LTS) support since the end of May this year Thank you. The guidance I was reading (policy possibly) only talked about whether the release was archived or not, and oldoldstable appears to not have been yet, despite it's LTS status. But in any case we shall just ignore oldoldstable for this bug. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄
Bug#905385: stretch-pu: package weboob/1.2-1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hello stable-release managers,
Filing this bug to open a dialogue with you about updating the weboob
package in Stretch to fix #905299 ("includes homophobic comments and
insults the user")
This has been fixed upstream. I've prepared an initial backported
patch[1], but it needs updating to close the right bug number (this
one), possibly change the version number (I used NMU scheme so far),
replace UNRELEASED with the correct suite (which is what for s-p-u?).
Once those are addressed, and assuming you approve in principle this
update, and also assuming the maintainers are in favour (CCed), I'll
attach the debdiff here.
Can/should we link this new bug with #905299 in some way (blocks:
relationship?)
This bug is also present in oldstable, and old-oldstable. I've done a
preliminary patch for oldstable too[2], the same caveats apply. I intend
to request an oldstable update in just the same way as I have here for
Stretch.
Is old-oldstable archived? It appears not, but, are there any plans for
another point release? In other words, should I file another bug to
manage an old-oldstable update to fix this?
[1]
https://salsa.debian.org/jmtd/weboob/commit/5feca16265b0ce689df1d1c0c4dd61f824af0c34
[2]
https://salsa.debian.org/jmtd/weboob/commit/1729299187743a45c08bf6c987d2f95581a9cad1
Thanks
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄
Bug#854457: unblock: chocolate-doom/2.3.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package chocolate-doom
The version in sid makes a very small package metadata change to improve the
experience of Debian users: the "zenity" package was suggested, and is now
recommended. We made some late adjustments to the chocolate-doom package to
work around an infrastructure bug[1] (heads-up to release[2]) which meant
this change is more important since the package include several binaries and
most users will not be able to run them all: with zenity installed, those
binaries will at least pop up a message explaining the situation.
I got my timings wrong when uploading this package and didn't expect to need to
request an unblock (I forgot that priority medium packages took 10 days in the
pre-freeze). Therefore some small unrelated source change is in the debdiff,
this is effectively a no-op.
Thanks
[1] http://bugs.debian.org/824169
[2] https://lists.debian.org/debian-release/2016/11/msg00372.html
unblock chocolate-doom/2.3.0-3
-- System Information:
Debian Release: 8.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru chocolate-doom-2.3.0/debian/changelog
chocolate-doom-2.3.0/debian/changelog
--- chocolate-doom-2.3.0/debian/changelog 2017-01-11 16:02:51.0
+
+++ chocolate-doom-2.3.0/debian/changelog 2017-01-27 07:37:30.0
+
@@ -1,3 +1,14 @@
+chocolate-doom (2.3.0-3) unstable; urgency=medium
+
+ * debian/rules: remove --parallel and --with=autoreconf, which are
+defaults for debhelper compat level >= 10
+ * Promote zenity from Suggests: to Recommends:. This ensures that error
+messages will be displayed when trying to launch the engines from
+a graphical menu system, such as when an IWAD is not detected.
+Closes: #850427.
+
+ -- Jonathan Dowland <j...@debian.org> Fri, 27 Jan 2017 07:37:30 +
+
chocolate-doom (2.3.0-2) unstable; urgency=medium
* Upload to unstable.
diff -Nru chocolate-doom-2.3.0/debian/control
chocolate-doom-2.3.0/debian/control
--- chocolate-doom-2.3.0/debian/control 2016-12-30 14:23:29.0 +
+++ chocolate-doom-2.3.0/debian/control 2017-01-27 07:37:30.0 +
@@ -26,8 +26,7 @@
${misc:Depends},
${shlibs:Depends}
Recommends:
- freedm | game-data-packager
-Suggests:
+ freedm | game-data-packager,
zenity
Provides:
chocolate-heretic,
diff -Nru chocolate-doom-2.3.0/debian/rules chocolate-doom-2.3.0/debian/rules
--- chocolate-doom-2.3.0/debian/rules 2016-12-29 22:20:55.0 +
+++ chocolate-doom-2.3.0/debian/rules 2017-01-23 15:16:17.0 +
@@ -3,7 +3,7 @@
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -Wl,-z,defs
%:
- dh $@ --parallel --with autoreconf,bash-completion
+ dh $@ --with bash-completion
override_dh_auto_configure:
dh_auto_configure -- \
heads up: packages blocked from testing due to infrastructure bugs
Hi, At least chocolate-doom and linux-wlan-ng are blocked from transitioning to testing due to a bug in "control-suite", part of the infrastructure on ftp.debian.org: #824169 As far as we are aware, there are no RC problems in these packages themselves. I just wanted to let -release know and see if we can get some kind of assurance that freeze "exceptions" might be granted for packages in this situation, as we do not know how long it will take to fix the problem and have no experience or expertise in the ftp.debian.org infrastructure scripts. Thanks, -- Jonathan Dowland Please do not CC me, I am subscribed to the list. signature.asc Description: Digital signature
unblock for chocolate-doom?
I'm a bit puzzled to be writing this since the freeze hasn't started, so apologies if I'm confused here, but it seems that chocolate-doom is blocked from migrating to testing due to two bugs which have been resolved in the version in unstable. https://tracker.debian.org/pkg/chocolate-doom 822845,822847 However, unrelated to the above, I see in https://release.debian.org/britney/hints/jcristau "# 20160508 # breaks dak block chocolate-doom" Is this still the case? It would be great if chocolate-doom could be unblocked. Thanks, -- Jonathan Dowland Please do not CC me, I am subscribed to the list. signature.asc Description: Digital signature
software-properties-gtk: #666869 (Ubuntu bits): stable backport?
Hi Julian/debian-release, Pleased to see that #666869 (mildly embarrassing presence of Notify me of a new Ubuntu version in the Debian package which got some exposure on reddit and other places) was fixed for sid (on Aug 23, my birthday no less ☺) Julian's fix is quite small/self-contained¹. I was wondering whether this could be a candidate for backporting to stable and releasing in a point release? Thanks ¹ http://bazaar.launchpad.net/~juliank/software-properties/debian/revision/676?start_revid=679 -- 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/20131018130755.gb24...@bryant.redmars.org
Re: ports and multiarch
On Mon, Sep 30, 2013 at 09:22:06PM +, Bill Allombert wrote: We should add official support for ppc64 and maybe sparc64 at least for use as a multiarch extension to ppc/sparc, even if we do not have time to make a full port. Otherwise the introduction of multiarch will likely result in a regression of functionnality on ppc system. Indeed, lib64* packages are superceded by multiarch and often are removed due to file conflict with the multi-arch equivalent. However this leads to a regression for nominally-32bit but 64bit-capable architectures that do not have a 64bit suit to draw from. I think a true 64 port may take the oxygen out of the 32 bit port, potentially, which would be a shame for powerpc 32 bit users (G4, like mac minis, powerbooks etc.). A multiarch solution would be nicer for them imho. Actually I wonder how many 32 bit powerpc users there are compared to 64 bit. IN the mac world, I'd wager more G4s than G5s (the mac pro or xserves), not sure about other powerpc worlds. -- 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/20131002115651.GB6224@debian
Re: Bug#702787: pre-approval: unblock: python-pyrrd/0.1.0-2
On Fri, Apr 05, 2013 at 11:55:17AM +0100, Steven Chamberlain wrote: I think this was the upload, still on mentors.d.o though: http://mentors.debian.net/package/pyrrd I know this is not -mentors, but CHECK_THIS_BEFORE_UPLOAD.txt looked suspicious. (I went looking to see what suite the changelog targetted as the original diff to -release was UNRELEASED. The package on mentors is unstable.) -- 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/20130405133705.GB25062@debian
Bug#692506: unblock: chocolate-doom/1.7.0-2 (but please see inside!)
On Tue, Feb 05, 2013 at 10:24:03PM +, Jonathan Wiltshire wrote: Yes, I'll take those too. Thanks Jonathan, upload made. -- 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/20130206104453.GB322@debian
