Bug#484121: tasksel: let's sync on the GNOME task
Joey Hess wrote: > Josselin Mouette wrote: >> * serpentine: we set it as the default application to burn audio >> CDs. > [in gnome-desktop task] >> * gnomebaker: its functionality is mostly covered by having both >> nautilus-cd-burner and serpentine. > > Ok, if this combo is best now, I'm happy to follow your lead and drop > gnomebaker and add serpentine. Or add brasero and drop serpentine. brasero is really nice and intuitive IMHO. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Unblock glib2.0
Hi, glib2.0 has been in unstable for 41 days, according to [1] Could it be unblocked so that it migrates to testing? Thanks, Emilio [1] http://qa.debian.org/excuses.php?package=glib2.0 signature.asc Description: OpenPGP digital signature
Re: (Temptative) list of udebs for X11-based d-i
On 19/03/10 15:32, Cyril Brulebois wrote: > (I failed to include pkg-gnome in my first mail, I've bounced it > anyway; adding them for real now. Adding pkg-sdl as well.) > > Frans Pop (19/03/2010): >>> | libgtk-directfb-2.0-0-udeb >> >> This package should be dropped now. Hasn't that been done yet? I'd >> consider migrating gtk+2.0 without dropping that package first an RC >> bug. > > Gnome folks were discussing it this very afternoon, and I think they > agreed to drop it. Would it seem acceptable to force the current > package as is, and then fix this right afterward? Of course it doesn't exist in the last version. Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba4369a.8040...@debian.org
Re: Bug#753781: transition: xserver 1.16
On 06/07/14 22:22, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2014-07-05): >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> Control: forwarded -1 >> https://release.debian.org/transitions/html/xserver1.16.html >> >> We'd like to ship Jessie with xserver 1.16. It is already available in >> experimental and built everywhere, and a few of us are already running >> it without any major issues. >> >> I have done a rebuild of all the drivers (input and video) and only >> xf86-video-glamo failed to build; all the others build fine against >> the new xserver. There are no conflicts for the transition, so we >> could start this right away, though since 1.16 final isn't out yet, it >> may be wise to wait for that. > > FWIW I've quickly toyed with: > - the server udeb fetched from experimental; > - the -input-evdev udeb built from the debian-experimental branch >against current libevdev-dev package (see attached patch, not sure >it's needed to apply it, your call) and experimental's server The patch looks good, feel free to apply it. >development package; > - the -video-fbdev udeb built from the debian-unstable branch >against experimental's server development package. > > The resulting netboot-gtk amd64 image seems to work just fine. Great! Thanks for checking. Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ba58e3.1050...@debian.org
Re: Reverting to GNOME for jessie's default desktop
On 08/08/14 00:29, Don Armstrong wrote: > On Thu, 07 Aug 2014, Jordi Mallach wrote: >> Well, it's roughly that time. :) So I'd like to plainly request GNOME >> is reinstated as the default desktop environment for a number of >> reasons. > > One of the reasons put forward for switching to Xfce was size on the > installation images; could you (and/or debian-cd) address this? > > Specifically: > 1) Would you want the default CD/DVD image to use a GNOME > even if GNOME was unable to fit on a single image? I think the first CD/DVD should have whatever we choose as the default. > 2) Would the GNOME > team consider a less-complete DE for cases where image size is a > restriction? Yes. If there wasn't enough space, we could drop some not very important modules (e.g. a few games), try a stronger compression ratio, symlink /usr/share/doc directories... We'd need some numbers here but we could work something out. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e49467.5010...@debian.org
Re: Bug#757575: transition: libgcrypt20
On 10/08/14 16:39, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2014-08-10): >> Control: forwarded -1 >> https://release.debian.org/transitions/html/libgcrypt20.html >> Control: tags -1 confirmed pending >> >> On 09/08/14 15:48, Andreas Metzler wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Hello, >>> >>> I would like to make sure that we only ship one gcrypt version in >>> jessie and am therefore opening the transition tracker now. >>> >>> libgcrypt20 is mostly API compatible to libgcrypt11. The main reason >>> why we have versioned -dev packages is that libgnutls26 is one of the >>> packages which cannot work with the old API. libgnutls26 should not be >>> shipped in jessie so I envision that it should be possible to make >>> major parts of this transition by bin-NMUs since I will be able to >>> make libgcrypt11-dev a dummy package depending on libgcrypt20-dev >>> after libgnutls26 has been dropped. >>> >>> libgcrypt11's upstream support will end on 2016-12-31. >>> >>> I will do some test builds to find out more. >>> >>> Ben file: >>> >>> title = "libgcrypt20"; >>> is_affected = .depends ~ "libgcrypt11" | .depends ~ "libgcrypt20" | >>> .depends ~ "libgcrypt11-dev" | .depends ~ "libgcrypt20-dev" | .depends ~ >>> "libgcrypt-dev"; >>> is_good = .depends ~ "libgcrypt20"; >>> is_bad = .depends ~ "libgcrypt11"; >> >> I have added a tracker for this (with minor tweaks). Let us know >> when you have more information on this. > > Hello people, > > please delay this until d-i beta 1 is out. I see we have at least this > involved: > | Package: libcryptsetup4-udeb > | Source: cryptsetup > | Depends: libc6-udeb (>= 2.18), libdevmapper1.02.1-udeb (>= 2:1.02.83), > libgcrypt11-udeb (>= 1.5.0-0), libuuid1-udeb (>= 2.16) > > Not having more moving pieces before this release happens would be nice. Ok, no problem. > [Cute bug bumber BTW. ;)] :D -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e7855b.2020...@debian.org
Bug#757693: RM: ttf-indic-fonts -- RoQA; Packages Built from Other Sources
Package: ftp.debian.org Severity: normal Hi, It looks like ttf-indic-fonts was split over a year ago, but the old source (and the old binaries) haven't been removed because the cruft report didn't notice this. I just noticed it because of the release-team auto-transition tracker. All the binaries are built from other sources, except for two: ttf-tamil-fonts-udeb ttf-indic-fonts | 1:0.5.14 | http://ftp.debian.org/debian/ unstable/main Sources ttf-telugu-fonts-udeb ttf-indic-fonts | 1:0.5.14 | http://ftp.debian.org/debian/ unstable/main Sources I'm Cc'ing debian-boot@ so they can confirm if this is OK from a d-i POV. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810151050.21694.76341.reportbug@titan
Re: Summary from the d-i / debian-cd BoF at DC14
On 09/09/14 17:51, Steve McIntyre wrote: > Discussion about trying to make desktops fit on 1 CD. XFCE and LXDE > both fit on 1 CD, Gnome and KDE basically don't fit any more. We > need to work out what to do there. > > Should we still build Gnome or KDE CDs at all? Not clear. Let's have > the discussion. Do you have numbers about this? Perhaps we could do something to make GNOME fit on a CD. Thanks, Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541f0e14.5010...@debian.org
Bug#718855: network-manager-gnome -> full gnome recommends chain
On 07/10/13 19:38, Joey Hess wrote: > network-manager-gnome recommnds gnome-bluetooth recommends > gnome-control-center recommends gnome-session > > Not sure what to do about this. gnome-bluetooth seems to have > that recommends because its control panel was moved into > gnome-control-center and is presumably used by its UI. > > Perhaps gnome-control-center does not need to recommend gnome-session? We talked about exactly this issue on irc this weekend and we didn't see a reason for g-c-c to recommend gnome-session, so that can be dropped. I've gone ahead and applied that in svn for the next upload. Cheers, Emilio Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5252fdc5.5020...@debian.org
Bug#718855: [Pkg-xfce-devel] network-manager-gnome -> full gnome recommends chain
On 09/10/13 10:29, Per Olofsson wrote: > Hi, > > On Tue, Oct 08, 2013 at 23:54 +0200, Michael Biebl wrote: >> Both recommends are there for a reason. gnome-bluetooth relies heavily >> on gnome-control-center when you try to pair / manage devices and >> network-manager-applet relies on gnome-bluetooth for DUN and PAN >> connections. So no, I don't see those recommends go away. > > According to policy, "The Recommends field should list packages that > would be found together with this one in all but unusual > installations". > > Is it really unusual to use Network Manager without bluetooth? Doesn't > most people use Network Manager to connect to wifi and ethernet? So what? This is just a recommends, you can install NM without gnome-bluetooth if you so desire. But in the general case, we want users to also get PAN/DUN support, so recommends is very appropriate. I have dropped the gnome-session recommends from gnome-control-center, isn't that enough to stop all of gnome from being installed when xfce is selected in tasksel? Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525518c6.1080...@debian.org
Re: Bug#709683: libpango1.0-udeb: Depends on libharfbuzz0
On 25/05/13 03:31, Michael Biebl wrote: For completeness sake: Am 25.05.2013 02:54, schrieb Cyril Brulebois: (echo-ing what was discussed on IRC in to the BTS.) this udeb is currently uninstallable, breaking the netboot-gtk d-i build: libpango1.0-udeb:amd64 Depends on libharfbuzz0 [ amd64 ] < none > ( none ) can't be satisfied! This dependency should be optional (even if no flag exists for that yet), so that libharfbuzz0 goes away from this udeb's Depends field. A udeb package has been added for harfbuzz and it's currently going through NEW [1]. The version in NEW does currently have the following dependencies: libc6-udeb (>=2.17), libfreetype6-udeb (>=2.4.0), libgcc1, libglib2.0-udeb (>=2.36.1), libicu48 (>=4.8-1), libstdc++6 After talking to pango/harfbuzz upstream, he recommended to build harfbuzz without ICU support. This will get us rid of the libgcc1, libicu48 and libstdc++ dependency. That's all done now. After that, libpango1.0-udeb is installable again. binNMUs for pango1.0 requested. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51aa1689.8060...@debian.org
Re: Bug#709683: libpango1.0-udeb: Depends on libharfbuzz0
Version: 1.32.5-5+b1 On 01/06/13 17:43, Emilio Pozuelo Monfort wrote: > On 25/05/13 03:31, Michael Biebl wrote: >> After talking to pango/harfbuzz upstream, he recommended to build >> harfbuzz without ICU support. This will get us rid of the libgcc1, >> libicu48 and libstdc++ dependency. > > That's all done now. > >> After that, libpango1.0-udeb is installable again. > > binNMUs for pango1.0 requested. pango built fine everywhere, so did harfbuzz and graphite2. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ac4561.9000...@debian.org
Bug#895949: lintian: warn about packages with udebs but no udeb line in shlibs
Package: lintian Version: 2.5.82 Severity: wishlist Hi, (d-i's RM / debian-boot@ Cc'ed.) A package that builds a udeb and ships a shared library ought to include that udeb in the respective shared libraries' shlibs. This is achieved by passing the --add-udeb option to dh_makeshlibs. A broken package could look like this: Package: libxft2 Source: xft contents: -rw-r--r-- root/root 89544 2018-04-17 20:11 ./usr/lib/x86_64-linux-gnu/libXft.so.2.3.2 shlibs: libXft 2 libxft2 (>> 2.1.1) And the respective udeb: Package: libxft2-udeb Source: xft contents: -rw-r--r-- root/root 89416 2018-04-17 20:11 ./usr/lib/libXft.so.2.3.2 lrwxrwxrwx root/root 0 2018-04-17 20:11 ./usr/lib/libXft.so.2 -> libXft.so.2.3.2 This is broken because udebs that depend on libXft.so.2 will gain a dependency on libxft2 rather than libxft2-udeb, making that udeb uninstallable. To fix that, with the --add-udeb=libxft2-udeb option, libxft2's shlibs would look like this: libXft 2 libxft2 (>> 2.1.1) udeb: libXft 2 libxft2-udeb (>> 2.1.1) Note that the deb and the udeb don't need to match 1:1. There may be several debs with different shared libraries, and one udeb with all of them. In that case, for each library in the udeb, the corresponding package that ships it in a deb needs to have an appropriate udeb line. See src:pango1.0 for an example. A lintian error could save some problems in d-i by preventing these problems (that error could be turned into an archive auto-reject). Cheers, Emilio
Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1
On 18/04/18 01:30, Cyril Brulebois wrote: > That's another perfect example why udeb additions should get reviewed: > we would have noticed another buggy package, and its bugginess might not > have been copied over to another package. I'm sure people don't request those reviews because they don't know or because they forget. A lintian warning could help, or ftp-masters enforcing an ack. Though I'd prefer the former as I wouldn't like NEW to have another bottleneck. > If someone wants to drive an effort to make -V a must for udebs in > policy, that's probably fine. It doesn't strike me as ultimately needed > (we've lived without it for quite some time because maintainers tend to > just do the right thing), but if people have spare time, go for it. It's not in policy (but I don't think it has to be), but following the conversation on #-ftp yesterday I opened: #895949 lintian: warn about packages with udebs but no udeb line in shlibs #895953 lintian: check that shlibs-version >= higher-version-symbols-file The latter wouldn't enforce -V, but would check that we at least get a high enough version in shlibs as compared to the .symbols file (and would have solved the zstd problem). Cheers, Emilio
Re: Debian Jessie - Incorrect permissions on /bin directory
On 02/03/16 12:46, Yves-Alexis Perez wrote: > On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote: >> [Context: packages shipping /bin with “funny” permissions, seen in stable.] >> >> Yves-Alexis Perez (2016-02-03): >>> >>> On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote: I didn't check the whole archive, but doing so might be interesting. >>> I did a quick check on a local mirror (which might be incomplete), and >>> found >>> three packages with errors: >>> >>> dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$ >>> drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/ >>> dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ >>> drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/ >>> dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep >>> bin/$ >>> drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/ >>> >>> Note that lintian complains a lot about them: >>> >>> lintian sed_4.2.2-4+b1_amd64.deb >>> W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key >>> Binary-only - copying to XS-Binary-only" >>> W: sed: latest-debian-changelog-entry-without-new-date >>> E: sed: control-file-has-bad-permissions md5sums 0664 != 0644 >>> W: sed: description-synopsis-starts-with-article >>> W: sed: non-standard-dir-perm bin/ 0775 != 0755 >>> W: sed: package-contains-timestamped-gzip >>> usr/share/doc/sed/changelog.Debian.gz >>> W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755 >>> W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz >>> W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755 >>> W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all >>> (or pipe to a file/program) >>> W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz >>> >>> It looks like an umask problem at package build time. Right now it doesn't >>> seem to have obvious security issues (like world writable /bin) but I'm >>> not >>> too sure there are not other stuff hidden. >>> >>> I guess it'd make sense to do an archive-wide lintian run to look for that >>> kind of mistakes, and then ask for stable binNMUs of the relevant >>> packages. >> It seems to me that lintian looks at testing/unstable (at least looking >> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6), >> so I'm not sure this would help for stable. >>> >>> >>> What do you think? >> I think debian-release@ needs to be in the loop, doing so. >> > Hey, > > so as far as I can tell there was no reaction from -release (although I can > understand noone's really sure what to do here). Is it at least possible to > schedule binNMUs in stable for those affected packages so future installs > don't end up with bad permissions like these? Would it make sense to start autorejecting packages that have this tag? Emilio
Re: Please dak copy-installer 20160516
On 20/05/16 19:46, Cyril Brulebois wrote: > Release team: since that's a binNMU, the source is already in > testing, so no action needed AFAICT? Right. Cheers, Emilio
Re: Next d-i release
On 19/10/16 15:33, Cyril Brulebois wrote: > Hi, > > Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare > a new d-i release soonish. I'll probably freeze udebs in the upcoming > hours or days, and try to figure out what to do with packages sitting > in unstable for the time being. > > Feel free to mention packages you want to see in testing, in case I go > for a conservative approach (and only hand-pick a few packages); feel > free to cc me explicitly to make sure I read your replies. Since the transition freeze is in a couple of weeks, I don't want to hold from doing any work on that front now. I don't mind if you block stuff from migrating for a few days, but I'm mentioning it since IIRC you build d-i from unstable. Cheers, Emilio
Re: Next d-i release
On 20/10/16 13:25, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2016-10-20): >>> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare >>> a new d-i release soonish. I'll probably freeze udebs in the upcoming >>> hours or days, and try to figure out what to do with packages sitting >>> in unstable for the time being. >>> >>> Feel free to mention packages you want to see in testing, in case I go >>> for a conservative approach (and only hand-pick a few packages); feel >>> free to cc me explicitly to make sure I read your replies. >> >> Since the transition freeze is in a couple of weeks, I don't want to >> hold from doing any work on that front now. I don't mind if you block >> stuff from migrating for a few days, but I'm mentioning it since IIRC >> you build d-i from unstable. > > d-i is built within unstable, but fetches udebs from testing during its > build; the block-udeb hints are here to control what we're fetching from > testing during the build. That makes a lot of sense! Then we should be good for now. Cheers, Emilio
Re: Please dak copy-installer 20151023
On 23/10/15 23:51, Cyril Brulebois wrote: > Release team, please hint it into testing: > > urgent debian-installer/20151023 Done. Cheers, Emilio
Re: Tentative last d-i release for 2015?
On 13/12/15 21:12, Cyril Brulebois wrote: > Hi, > > I'm not entirely sure I'll manage to get that to work but I'd like to > consider performing a last d-i release for 2015. I haven't been paying > attention closely enough over the past few days but if things are in shape > somewhat, and if image builds can be performed, then maybe… Would debian-cd > people be available say next week-end (2015-12-19/20)? > > Release people, would a global block-udeb disrupt anything going on on your > side? We're getting close to start the Perl transition. I guess there are packages in there building udebs, and I guess the transition won't be over by the weekend (so the block may be alright, and in any case we could wait a couple of days if things happened to be ready). Cheers, Emilio
Re: Bug#808090: unblock: glibc/2.21-4
On 15/12/15 23:45, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > glibc 2.21-4 has now been for 5 days in unstable, with no RC bug no > major error reported. It doesn't differ a lot from version 2.21-2 which > has also spent some time in unstable without major issue besides the > pt_chown one. Therefore, could you please unblock the package glibc? > Thanks in advance.? > > (include/attach the debdiff against the package in testing) > > Sorry that would be too bug ;-) > > unblock glibc/2.21-4 udebs are temporarily blocked because a d-i release is being prepared. Cc'ing -boot / Cyril. Emilio
Re: Bug#808090: unblock: glibc/2.21-4
On 16/12/15 00:30, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2015-12-16): >> On 15/12/15 23:45, Aurelien Jarno wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: unblock >>> >>> glibc 2.21-4 has now been for 5 days in unstable, with no RC bug no >>> major error reported. It doesn't differ a lot from version 2.21-2 which >>> has also spent some time in unstable without major issue besides the >>> pt_chown one. Therefore, could you please unblock the package glibc? >>> Thanks in advance.? >>> >>> (include/attach the debdiff against the package in testing) >>> >>> Sorry that would be too bug ;-) >>> >>> unblock glibc/2.21-4 > > FWIW you want an unblock-udeb instead of unblock. > >> udebs are temporarily blocked because a d-i release is being prepared. >> Cc'ing -boot / Cyril. > > Coincidences… See: > https://lists.debian.org/debian-release/2015/12/msg00323.html I just read that on my inbox... I was looking at the debian-release folder first :O > I didn't cc glibc maintainers since the package looked in a good shape > and ready to migrate; I'm glad they agree. :) :) Thanks, Emilio
Re: Bug#808090: unblock: glibc/2.21-4
On 16/12/15 00:32, Emilio Pozuelo Monfort wrote: > On 16/12/15 00:30, Cyril Brulebois wrote: >> Emilio Pozuelo Monfort (2015-12-16): >>> On 15/12/15 23:45, Aurelien Jarno wrote: >>>> Package: release.debian.org >>>> Severity: normal >>>> User: release.debian@packages.debian.org >>>> Usertags: unblock >>>> >>>> glibc 2.21-4 has now been for 5 days in unstable, with no RC bug no >>>> major error reported. It doesn't differ a lot from version 2.21-2 which >>>> has also spent some time in unstable without major issue besides the >>>> pt_chown one. Therefore, could you please unblock the package glibc? >>>> Thanks in advance.? >>>> >>>> (include/attach the debdiff against the package in testing) >>>> >>>> Sorry that would be too bug ;-) >>>> >>>> unblock glibc/2.21-4 >> >> FWIW you want an unblock-udeb instead of unblock. >> >>> udebs are temporarily blocked because a d-i release is being prepared. >>> Cc'ing -boot / Cyril. >> >> Coincidences… See: >> https://lists.debian.org/debian-release/2015/12/msg00323.html > > I just read that on my inbox... I was looking at the debian-release folder > first :O Closing this since the unblock-udeb has been added. Cheers, Emilio
Re: Tentative last d-i release for 2015?
On 17/12/15 18:02, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2015-12-13): >> We're getting close to start the Perl transition. I guess there are packages >> in >> there building udebs, and I guess the transition won't be over by the weekend >> (so the block may be alright, and in any case we could wait a couple of days >> if >> things happened to be ready). > > It would have been nice to leave me a chance to upload d-i before starting > perl… My apologies. I didn't think this through... I guess we've been waiting for this transition for so long that I just was too happy to be able to start it. I guess I also thought you were building d-i out of testing, and that's why I said we could wait (for the migration) to happen until the block was lifted. My bad. Not sure if it helps, but at this rate, we will have rebuilt everything on the "fast" architectures (everywhere except mips*) by the end of today. Migration to testing will take longer as there are issues to sort out, though again I don't know if that is a problem for you or if having an installable sid is enough. Again, sorry for the trouble this has caused you. Cheers, Emilio
Re: Bug#853809: unblock: e2fsprogs/1.43.4-2
On 01/02/17 04:48, Theodore Y. Ts'o wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package e2fsprogs > > 1.43.4 is the new upstream version of e2fsprogs which fixes a RC bug > (#840733: e2fsprogs contains non-free file). n.b., the non-free file is > only used in a regression test and isn't actually included in any > binary. There are also a number of important bug fixes that I'd really > like to get into stretch. See the debian changelog or [1] for more > details. > > [1] http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43.4 > > Note: there is a udeb involved since this will also require a d-i > release manager unblock. I'm unclear whether there is a separate > process for requesting that particlar unblock. Please advise. > > I just uploaded 1.43.4-2 to sid today, so it will be five days old when > the Stretch Freeze hits. So I'm filing this bug now as a heads up, > since unless the release schedule slips, this isn't going to meet the > mandatory 10 day delay which was announced in December. This seems fine to me, unblocked. Cc'ing debian-boot@/Cyril for the udeb unblock. Cheers, Emilio
Re: Bug#853809: unblock: e2fsprogs/1.43.4-2
On 08/02/17 17:44, Theodore Ts'o wrote: > On Fri, Feb 03, 2017 at 10:34:09PM +0100, Emilio Pozuelo Monfort wrote: >> >> This seems fine to me, unblocked. Cc'ing debian-boot@/Cyril for the udeb >> unblock. >> > > Hi, I've since found a regression that I would like to fix via a > cherry pick from upstream. The e2fsprogs/1.43.4-2 package hasn't > transitioned into testing yet (it will in 3 more days). > > Enclosed please find the source debdiff. Would you prefer that I wait > for 1.43.4-2 to transition into testing, and then upload 1.43.4-3 and > then file a new unblock request? It's 9/10 days now and would migrate tonight, so I've aged it so it migrates in ~30 mins. Please wait for that and upload your additional fixes afterwards - you can check if it migrated with rmadison. Cheers, Emilio
Re: Bug#854968: unblock: ntfs-3g
On 12/02/17 18:08, Laszlo Boszormenyi (GCS) wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > > Hi Release Team, > > Please unblock ntfs-3g 2016.2.22AR.1-4 as it fixes CVE-2017-0358. > The debdiff is attached for your convenience. Unblocked, but needs a d-i RM ack for the udeb. Cheers, Emilio
Re: Bug#854968: unblock: ntfs-3g
On 12/02/17 22:17, Cyril Brulebois wrote: > Hi, > > Emilio Pozuelo Monfort (2017-02-12): >> On 12/02/17 18:08, Laszlo Boszormenyi (GCS) wrote: >>> Package: release.debian.org >>> User: release.debian@packages.debian.org >>> Usertags: unblock >>> >>> Hi Release Team, >>> >>> Please unblock ntfs-3g 2016.2.22AR.1-4 as it fixes CVE-2017-0358. >>> The debdiff is attached for your convenience. >> >> Unblocked, but needs a d-i RM ack for the udeb. > > I really hope this doesn't break d-i. :) (If it does, we'll fix.) > > So feel free to go ahead, thanks. Thanks. Done. Cheers, Emilio
Bug#854801: No network after netinst Stretch RC2
On 10/02/17 17:17, Cyril Brulebois wrote: > Paul Schlüter (2017-02-10): >> * The touchpad behaves strange: I can move the mouse pointer but cannot >> click. However, this may be a hardware problem. > > We've had several such reports but bug triaging still needs to happen… :/ Are you doing tap-to-click, or actual clicks on physical buttons? If the former, this may be related to #853869, which I intend to fix soon. Cheers, Emilio
Re: Bug#854155: unblock: openssl/1.1.0d-2
On 04/02/17 15:20, Sebastian Andrzej Siewior wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > Severity: normal > > Please unblock package openssl. It contains a redo of the rules file > among other packaging related changes which did not migrate in time due > to the new release of the d version which fixes 3 CVE bugs. The d-2 > version fixes a regression discovered by perl and FTBFS of openssl > itself if arch-any and arch-all were built in one go. > > unblock openssl/1.1.0d-2 That includes some changes we don't like during the freeze, but given those were done before the freeze and I wouldn't want them reverted this early in the freeze, I would be happy to unblock this... but can you attach a binary debdiff (e.g. debdiff an old and new .changes file) to make sure things are still looking good? Also please make minimal changes from now on (e.g. for 1.1.0e). Cyril, does this look fine from a d-i perspective at this stage? Cheers, Emilio
Re: Bug#854155: unblock: openssl/1.1.0d-2
On 13/02/17 21:37, Sebastian Andrzej Siewior wrote: > On 2017-02-13 18:01:34 [+0100], Emilio Pozuelo Monfort wrote: >> On 04/02/17 15:20, Sebastian Andrzej Siewior wrote: >>> Package: release.debian.org >>> User: release.debian@packages.debian.org >>> Usertags: unblock >>> Severity: normal >>> >>> Please unblock package openssl. It contains a redo of the rules file >>> among other packaging related changes which did not migrate in time due >>> to the new release of the d version which fixes 3 CVE bugs. The d-2 >>> version fixes a regression discovered by perl and FTBFS of openssl >>> itself if arch-any and arch-all were built in one go. >>> >>> unblock openssl/1.1.0d-2 >> >> That includes some changes we don't like during the freeze, but given those >> were >> done before the freeze and I wouldn't want them reverted this early in the >> freeze, I would be happy to unblock this... but can you attach a binary >> debdiff >> (e.g. debdiff an old and new .changes file) to make sure things are still >> looking good? > > sure. I've build c-2 and d-2 with _all an amd64 in todays sid to get the > changes files and this the resulting debdiff: > > [The following lists of changes regard files as different if they have > different names, permissions or owners.] > > Files in second .changes but not in first > - > -rw-r--r-- root/root > /usr/lib/debug/.build-id/2b/578462762f19aca2fce5f18f02136a0e040ffa.debug > -rw-r--r-- root/root > /usr/lib/debug/.build-id/54/06ecde81b1cb2ef22ddd54e5dfe2e17a6484ce.debug > -rw-r--r-- root/root > /usr/lib/debug/.build-id/83/ab63854f485098aabd85de0468f307bc3223e9.debug > -rw-r--r-- root/root > /usr/lib/debug/.build-id/8a/753d613f23da52c564ce14f8dc406baaf34a8f.debug > -rw-r--r-- root/root > /usr/lib/debug/.build-id/cd/a94b3e615e2dd7c14de4c2d600e020c765a6d3.debug > -rw-r--r-- root/root /usr/share/doc/openssl/NEWS.Debian.gz > -rw-r--r-- root/root /usr/share/lintian/overrides/openssl > -rw-r--r-- root/root /usr/share/man/man3/X509_digest.3ssl.gz > lrwxrwxrwx root/root /usr/share/doc/libssl1.1-dbgsym -> libssl1.1 > lrwxrwxrwx root/root /usr/share/man/man3/BIO_callback_fn.3ssl.gz -> > BIO_set_callback.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/BIO_callback_fn_ex.3ssl.gz -> > BIO_set_callback.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/BIO_get_callback_ex.3ssl.gz -> > BIO_set_callback.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/BIO_set_callback_ex.3ssl.gz -> > BIO_set_callback.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/CRYPTO_secure_used.3ssl.gz -> > OPENSSL_secure_malloc.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/DH_check_params.3ssl.gz -> > DH_generate_parameters.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/ERR_FATAL_ERROR.3ssl.gz -> > ERR_GET_LIB.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/EVP_PKEY_gen_cb.3ssl.gz -> > EVP_PKEY_keygen.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/EVP_blake2b512.3ssl.gz -> > EVP_DigestInit.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/EVP_blake2s256.3ssl.gz -> > EVP_DigestInit.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/EVP_chacha20.3ssl.gz -> > EVP_EncryptInit.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/EVP_chacha20_poly1305.3ssl.gz -> > EVP_EncryptInit.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/GEN_SESSION_CB.3ssl.gz -> > SSL_CTX_set_generate_session_id.3ssl.gz > lrwxrwxrwx root/root > /usr/share/man/man3/PKCS7_ISSUER_AND_SERIAL_digest.3ssl.gz -> > X509_digest.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/SSL_COMP_get0_name.3ssl.gz -> > SSL_COMP_add_compression_method.3ssl.gz > lrwxrwxrwx root/root > /usr/share/man/man3/SSL_COMP_get_compression_methods.3ssl.gz -> > SSL_COMP_add_compression_method.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/SSL_COMP_get_id.3ssl.gz -> > SSL_COMP_add_compression_method.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/SSL_verify_cb.3ssl.gz -> > SSL_CTX_set_verify.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/X509_CRL_digest.3ssl.gz -> > X509_digest.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/X509_NAME_digest.3ssl.gz -> > X509_digest.3ssl.gz > lrwxrwxrwx root/root /usr/share/man/man3/X509_REQ_digest.3ssl.gz -> > X509_digest.3ssl.gz > lrwxrwxrwx root/root > /usr/share/man/man3/X509_STORE_CTX_cert_crl_fn.3ssl.gz -> > X509_STORE_set_verify_cb_func.3ssl.gz > lrwxrwxrwx root/roo
Re: Various unblock-udebs
On 14/02/17 03:48, Cyril Brulebois wrote: > Hello, > > Emilio asked me on IRC to have a look at a bunch of packages which both > have block-udeb and RC bug fixes. Here's a list with comments, I'm OK > with unblock-udeb'ing most of them (which doesn't mean you shouldn't > review as usual for the unblock part), except hw-detect and wpa, which > have commented out unblock-udeb lines. Thanks. I'll review them in the evening if noone beats me to it. > ,---[ review as of 2017-02-14 ]--- > > # lots of noise due to git-dpm; l10n + Sledge-changes, trusting him: > unblock-udeb grub2/2.02~beta3-5 > > # lots of noise due to .gitignore removal (included in a previous > # upload by error), plus l10, plus dpkg-maintscript-helper fix: > unblock-udeb console-setup/1.160 > > # compile-time option change, shouldn't be an issue for d-i: > unblock-udeb bind9/1:9.10.3.dfsg.P4-11.1 > > # RC bug fix (FTBFS): > unblock-udeb installation-locale/1.7 > > # fix for multipath support, but some more work is needed anyway, > # maybe wait until related unblocks are put together? > # unblock-udeb hw-detect/1.123 > > # doesn't seem to have udev/udeb changes, basic testing is fine, and > # the RC/seccomp bug fix is most welcome: > unblock-udeb systemd/232-18 > > # trivial bug fix, successfully tested by submitter: > unblock-udeb grub-installer/1.137 > > # trivial bug fix, succesfully run-tested: > unblock-udeb clock-setup/0.132 > > # can't comment, just too huge: > # unblock-udeb wpa/2.6-3 Unfortunately this one has some regressions: Updating wpa introduces new bugs: #849077, #849122 Updating wpa fixes old bugs: #828601, #854719 Cheers, Emilio
Re: Various unblock-udebs
On 14/02/17 10:20, Emilio Pozuelo Monfort wrote: > On 14/02/17 03:48, Cyril Brulebois wrote: >> Hello, >> >> Emilio asked me on IRC to have a look at a bunch of packages which both >> have block-udeb and RC bug fixes. Here's a list with comments, I'm OK >> with unblock-udeb'ing most of them (which doesn't mean you shouldn't >> review as usual for the unblock part), except hw-detect and wpa, which >> have commented out unblock-udeb lines. > > Thanks. I'll review them in the evening if noone beats me to it. Some more: #854474 src:alsa-libalsa-lib: FTBFS when built with dpkg-buildpackage -A #854616 scdaemonscdaemon cannot access yubikey using ccid driver without pcscd #855489 lilo-installer lilo-installer: fails in postinst: sfdisk: invalid option -- '1' #855520 src:bind9 bind9: CVE-2017-3135: Assertion failure when using DNS64 and RPZ can lead to crash #855540 src:bind9 bind9: CVE-2016-8864 causes more regressions Thanks, Emilio
Re: Various unblock-udebs
On 22/02/17 00:29, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2017-02-22): >> #854616 scdaemonscdaemon cannot access yubikey using ccid >> driver without pcscd > > Not sure it's d-i related? ftr: as said on irc, that's from src:gnupg2. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Bug#853917: debian-installer: missing glyphs for Korean / broken rendering
On 28/02/17 08:56, Cyril Brulebois wrote: > Hi, > > Cyril Brulebois (2017-02-02): >> Source: debian-installer >> Version: 20160516 >> Severity: important >> Tags: l10n >> >> (debian-l10n-kor...@lists.debian.org in X-Debbugs-Cc for informational >> purposes; maybe someone there will find out what happened before someone >> from the installer team does.) >> >> Spotted by victory and mentioned on IRC: we're currently lacking support >> for Korean in the installer, since both the menu entry for Korean at the >> language selection step and later prompts are only showing the usual >> boxes for unknown glyphs. :( >> >> I've just tracked this down as a regression from Stretch Alpha 5 to >> Stretch Alpha 6. I'll try and investigate further in a few hours. > > It's been tracked as a regression in the fonts-android package, filed as > #853921. The fix hasn't reached testing yet since it needs a unblock, > which I didn't ask because I wanted to give it more testing. > > I've just successfully tested that a basic install in Japanese doesn't > suffer from any regression when switching from the version in testing to > the one in unstable, so I think it's safe to unblock/unblock-udeb it: > > unblock fonts-android/1:6.0.1r16-1.1 > unblock-udeb fonts-android/1:6.0.1r16-1.1 > > (This took a while since I wanted to finish an automation proof of > concept which lets me record an installation process and replay it > later with a different image; but I'm finally there…) > > > Adding the release team to the loop since I'm slightly reluctant to > unblocking an upload of mine (for a package that isn't maintained by > debian-boot). The (attached) source debdiff shouldn't be too scary > though. Unblocked. Cheers, Emilio
Re: Various unblock-udebs
On 14/02/17 03:48, Cyril Brulebois wrote: > Hello, A few more ;) # 20170301 unblock nbd/1:3.15.2-1 # : Confirm with d-i RM #unblock-udeb nbd/1:3.15.2-1 age-days 5 nbd/1:3.15.2-1 # big debdiff, but the important stuff is in pango/, the rest are autogenerated # docs and the windows build bits moving from build/win32/ to win32/ # 20170301 unblock pango1.0/1.40.4-1 # : Confirm with d-i RM #unblock-udeb pango1.0/1.40.4-1 # 20170305 unblock libxdmcp/1:1.1.2-3 # : Confirm with d-i RM #unblock-udeb libxdmcp/1:1.1.2-3 age-days 3 libxdmcp/1:1.1.2-3 Thanks, Emilio
Re: Various unblock-udebs
On 05/03/17 11:40, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2017-03-05): >> # big debdiff, but the important stuff is in pango/, the rest are >> autogenerated >> # docs and the windows build bits moving from build/win32/ to win32/ >> # 20170301 >> unblock pango1.0/1.40.4-1 >> # : Confirm with d-i RM >> #unblock-udeb pango1.0/1.40.4-1 > > I'd like to give it a few test runs first. Will try to get that done > before monday. Sure thing. BTW there's no rush in getting this into testing, so if that takes a bit longer that's alright. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Various unblock-udebs
Hi Cyril, here's another one. New xserver point release, with some minor security fixes: # 20170306 unblock xorg-server/2:1.19.2-1 # : Confirm with d-i RM #unblock-udeb xorg-server/2:1.19.2-1 age-days 5 xorg-server/2:1.19.2-1 Cheers, Emilio
Re: Various unblock-udebs
On 10/03/17 17:21, Cyril Brulebois wrote: > Hi, > > Emilio Pozuelo Monfort (2017-03-10): >> New xserver point release, with some minor security fixes: >> >> # 20170306 >> unblock xorg-server/2:1.19.2-1 >> # : Confirm with d-i RM >> #unblock-udeb xorg-server/2:1.19.2-1 >> age-days 5 xorg-server/2:1.19.2-1 > > Tests I've conducted over the last few days (esp. for pango1.0) were with that > version, and everything looked fine, so no objections. Thanks, unblocked. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Bug#857539: unblock: systemd/231-19
On 12/03/17 10:47, Martin Pitt wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > > Hello release team, > > The current systemd in unstable (232-19) fixes a bunch of bugs, mostly in > resolved (which we don't enable by default), but also in bits which do run by > default. Also some testing improvements. > > The package has been in unstable for 10 days now without any regression > reports, and of course passes upstream tests and our downstream autopkgtests. > > debdiff between -18 (in testing) and current -19 attached. I also put the > changelog and some annotations to it below. Ack from me, but needs a d-i ack. Cyril? Cheers, Emilio > > | systemd (232-19) unstable; urgency=medium > | > | [ Martin Pitt ] > | * debian/README.source: Update patch and changelog handling to current > | reality. > > Documentation only. > > | * root-unittests autopkgtest: Blacklist test-journal-importer. > | This got added in a recent PR, but running this requires using "make > | install-tests" which hasn't landed yet. > > Not relevant for stretch, just for upstream CI. No-op at runtime. > > | * fsckd: Fix format specifiers on 32 bit architectures. > > Should be mostly harmles at runtime, but fixes a warning and using correct > types is always good. > > | * resolved: Fix NSEC proofs for missing TLDs (Closes: #855479) > > Quite an important bug fix if you use resolved with DNSSEC. Not RC overall as > neither resolved as a whole nor the DNSSEC option is enabled by default, but > both become increasingly popular. > > | * boot-and-services autopkgtest: Skip CgroupsTest on unified hierarchy. > | * boot-smoke autopkgtest: Run in containers, too. > | * logind autopkgtest: Adjust to work in containers. > > Test fixes only. > > | [ Dimitri John Ledkov ] > | * Fix resolved failing to follow CNAMES for DNS stub replies (LP: > #1647031) > > Similarly to above, this is an even more important fix for resolved as it > affects quite a number of hosts out there (like resolving freedesktop.org > machines). > > | * Fix emitting change signals with a sessions property in logind > | (LP: #1661568) > > This doesn't affect systemd itself, but desktop clients which use libsystemd > to > track the active session. Not particularly urgent, but a nice and > straightforward fix. > > | [ Michael Biebl ] > | * If an automount unit is masked, don't react to activation anymore. > | Otherwise we'll hit an assert sooner or later. (Closes: #856035) > > This fixes a nasty crash of the entire system with automount units, so this > is > rather important. > > | [ Felipe Sateler ] > | * resolved: add the new KSK to the built-in resolved trust anchor. > | The old root key will be discarded in early 2018, so get this into > | stretch. > > We have to update the key at some point anyway, so let's rather do it now > before the release. > > | * Backport some zsh completion fixes from upstream (Closes: #847203) > > Low-risk, and nice for zsh users. > > Thanks for considering, > > Martin >
Re: Bug#857539: unblock: systemd/231-19
On 12/03/17 12:00, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2017-03-12): >> On 12/03/17 10:47, Martin Pitt wrote: >>> The current systemd in unstable (232-19) fixes a bunch of bugs, mostly in >>> resolved (which we don't enable by default), but also in bits which do run >>> by >>> default. Also some testing improvements. >>> >>> The package has been in unstable for 10 days now without any regression >>> reports, and of course passes upstream tests and our downstream >>> autopkgtests. >>> >>> debdiff between -18 (in testing) and current -19 attached. I also put the >>> changelog and some annotations to it below. >> >> Ack from me, but needs a d-i ack. Cyril? > > Doesn't seem to touch d-i-ish things, and testing over the past few days > showed no obvious issues with that version, so no objections. Thanks. Unblocked. Cheers, Emilio
Re: Bug#857741: unblock (pre-approval): openssh/1:7.4p1-8
On 15/03/17 16:40, Colin Watson wrote: > Control: tags -1 - moreinfo > > On Tue, Mar 14, 2017 at 08:09:00PM +, Niels Thykier wrote: >> Colin Watson: >>> unblock openssh/1:7.4p1-8 >> >> Please go ahead and let us know once it is uploaded + built. > > https://buildd.debian.org/status/package.php?pkg=openssh shows it in at > least the Uploaded state on all release architectures now. This needs a d-i RM ack. Cheers, Emilio
Re: Bug#857918: unblock: debian-edu-install/1.915
On 16/03/17 12:07, Holger Levsen wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package debian-edu-install, it fixes an important bug > (#856493), > which needs a oneliner fix in preseed-values/defaults.ltsp-server: > > +d-i ltsp-client-builder/server_packages string ltsp-server > > The other changes are debconf translations and switching the package to > source format > 3.0 (native). Changing the source format at this stage makes an RM unhappy... The rest of the changes look fine. > > As usual, this needs a "KiBi-ack", as debian-edu-install contains a udeb, > which is > not used in the default debian-installer… Cc'ing Cyril. Cheers, Emilio > > unblock debian-edu-install/1.915 > > The full debdiff is: > > $ debdiff debian-edu-install_1.913.dsc debian-edu-install_1.915.dsc > diff -Nru debian-edu-install-1.913/debian/changelog > debian-edu-install-1.915/debian/changelog > --- debian-edu-install-1.913/debian/changelog 2017-01-17 22:02:53.0 > +0100 > +++ debian-edu-install-1.915/debian/changelog 2017-03-05 17:21:09.0 > +0100 > @@ -1,3 +1,27 @@ > +debian-edu-install (1.915) unstable; urgency=medium > + > + [ Wolfgang Schweer ] > + * Adjust preseed-values/defaults.ltsp-server. > +Set 'ltsp-server' as value of server_packages instead of the default > +one (ltsp-server-standalone). (Closes: #856493) > + > + * Translation updates: > +- Greek, thanks to Παναγιώτης Γεωργακόπουλος. > +- Italian, thanks to Claudio Carboncini. > + > + -- Holger Levsen Sun, 05 Mar 2017 17:21:09 +0100 > + > +debian-edu-install (1.914) unstable; urgency=medium > + > + * Translation updates: > +- Czech, thanks to Miroslav Kure. (Closes: #852191) > + > + [ Holger Levsen ] > + * Switch to native source format 3.0, to easily avoid including .git into > +the source package. > + > + -- Holger Levsen Fri, 17 Feb 2017 17:48:48 +0100 > + > debian-edu-install (1.913) unstable; urgency=medium > >[ Wolfgang Schweer ] > diff -Nru debian-edu-install-1.913/debian/po/cs.po > debian-edu-install-1.915/debian/po/cs.po > --- debian-edu-install-1.913/debian/po/cs.po 2017-01-09 10:46:07.0 > +0100 > +++ debian-edu-install-1.915/debian/po/cs.po 2017-03-02 20:20:10.0 > +0100 > @@ -23,7 +23,7 @@ > "Project-Id-Version: debian-edu-install\n" > "Report-Msgid-Bugs-To: debian-edu-inst...@packages.debian.org\n" > "POT-Creation-Date: 2014-09-30 09:23+0200\n" > -"PO-Revision-Date: 2013-06-04 15:24+0200\n" > +"PO-Revision-Date: 2017-01-22 12:42+0100\n" > "Last-Translator: Miroslav Kure \n" > "Language-Team: Czech \n" > "Language: cs\n" > @@ -73,7 +73,7 @@ > #. __Choices: Main-Server, Workstation, Roaming-Workstation, LTSP-Server, > Standalone, Minimal > #: ../debian-edu-profile-udeb.templates:2001 > msgid "LTSP Server" > -msgstr "" > +msgstr "LTSP server" > > #. Type: multiselect > #. Choices > @@ -104,7 +104,6 @@ > #. Type: multiselect > #. Description > #: ../debian-edu-profile-udeb.templates:2002 > -#, fuzzy > msgid "" > " - Main Server: reserved for the Debian Edu server. It does not\n" > "include any GUI (Graphical User Interface). There\n" > @@ -257,7 +256,6 @@ > #. Description > #. Debian Edu ltsp server menu entry for partman recipe. > #: ../debian-edu-profile-udeb.templates:11001 > -#, fuzzy > msgid "Debian Edu LTSP Server" > msgstr "Debian Edu LTSP server" > > @@ -272,7 +270,6 @@ > #. Description > #. Debian Edu combo main+ltsp menu entry for partman recipe. > #: ../debian-edu-profile-udeb.templates:13001 > -#, fuzzy > msgid "Debian Edu Main Server and LTSP Server" > msgstr "Debian Edu Hlavní server a LTSP server" > > diff -Nru debian-edu-install-1.913/debian/po/el.po > debian-edu-install-1.915/debian/po/el.po > --- debian-edu-install-1.913/debian/po/el.po 2017-01-09 10:46:07.0 > +0100 > +++ debian-edu-install-1.915/debian/po/el.po 2017-03-02 20:21:14.0 > +0100 > @@ -16,7 +16,7 @@ > # George Papamichelakis , 2004. > # Emmanuel Galatoulas , 2004. > # quad-nrg.net , 2005, 2006. > -# Panagiotis Georgakopoulos , 2014 > +# Panagiotis Georgakopoulos , 2017 > msgid "" > msgstr "" > "Project-Id-Version: popularity_el\n" > @@ -97,7 +97,6 @@ > #. Type: multiselect > #. Description > #: ../debian-edu-profile-udeb.templates:2002 > -#, fuzzy > msgid "" > " - Main Server: reserved for the Debian Edu server. It does not\n" > "include any GUI (Graphical User Interface). There\n" > @@ -260,9 +259,8 @@ > #. Description > #. Debian Edu ltsp server menu entry for partman recipe. > #: ../debian-edu-profile-udeb.templates:11001 > -#, fuzzy > msgid "Debian Edu LTSP Server" > -msgstr "Εξυπηρετητής LTSP" > +msgstr "Debian Edu/Εξυπηρετητής LTSP του συστήματος" > > #. Type: text > #. Description > @@ -275,9 +273,8 @@ > #. Description > #. Debian Edu combo main+ltsp menu entry for partman recipe.
Re: Bug#857741: closed by Emilio Pozuelo Monfort (unblock openssh)
On 16/03/17 16:32, Colin Watson wrote:
> Control: reopen -1
> Control: retitle -1 unblock: openssh/1:7.4p1-9
>
> I'm afraid that 1:7.4p1-8 caused a CI failure, and on investigation this
> was a real problem easily reproduced in a local adt-run. Sorry for not
> noticing this earlier. I've uploaded 1:7.4p1-9 to fix this with the
> following diff. This will presumably need another d-i ack, and
> certainly an adjustment to the existing hint.
OK.
Explicitly Cc'ing Cyril.
Cheers,
Emilio
> diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm
> --- openssh-7.4p1/debian/.git-dpm 2017-03-14 13:41:39.0 +
> +++ openssh-7.4p1/debian/.git-dpm 2017-03-16 13:42:23.0 +
> @@ -1,6 +1,6 @@
> # see git-dpm(1) from git-dpm package
> -a0f9daa9c3cc2b37b9707b228263eb717d201371
> -a0f9daa9c3cc2b37b9707b228263eb717d201371
> +35b2ea77a74348b575d680061f35ec7992b26ec8
> +35b2ea77a74348b575d680061f35ec7992b26ec8
> 971a7653746a6972b907dfe0ce139c06e4a6f482
> 971a7653746a6972b907dfe0ce139c06e4a6f482
> openssh_7.4p1.orig.tar.gz
> diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog
> --- openssh-7.4p1/debian/changelog2017-03-14 13:49:14.0 +
> +++ openssh-7.4p1/debian/changelog2017-03-16 13:43:15.0 +
> @@ -1,3 +1,10 @@
> +openssh (1:7.4p1-9) unstable; urgency=medium
> +
> + * Fix null pointer dereference in ssh-keygen; this fixes an autopkgtest
> +regression introduced in 1:7.4p1-8.
> +
> + -- Colin Watson Thu, 16 Mar 2017 13:43:15 +
> +
> openssh (1:7.4p1-8) unstable; urgency=medium
>
>* Fix ssh-keygen -H accidentally corrupting known_hosts that contained
> diff -Nru openssh-7.4p1/debian/patches/series
> openssh-7.4p1/debian/patches/series
> --- openssh-7.4p1/debian/patches/series 2017-03-14 13:41:39.0
> +
> +++ openssh-7.4p1/debian/patches/series 2017-03-16 13:42:23.0
> +
> @@ -32,3 +32,4 @@
> restore-authorized_keys2.patch
> ssh-keygen-hash-corruption.patch
> ssh-keyscan-hash-port.patch
> +ssh-keygen-null-deref.patch
> diff -Nru openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch
> openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch
> --- openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch 1970-01-01
> 01:00:00.0 +0100
> +++ openssh-7.4p1/debian/patches/ssh-keygen-null-deref.patch 2017-03-16
> 13:42:23.0 +
> @@ -0,0 +1,31 @@
> +From 35b2ea77a74348b575d680061f35ec7992b26ec8 Mon Sep 17 00:00:00 2001
> +From: "dtuc...@openbsd.org"
> +Date: Mon, 6 Mar 2017 02:03:20 +
> +Subject: upstream commit
> +
> +Check l->hosts before dereferencing; fixes potential null
> +pointer deref. ok djm@
> +
> +Upstream-ID: 81c0327c6ec361da794b5c680601195cc23d1301
> +
> +Origin:
> https://anongit.mindrot.org/openssh.git/commit/?id=18501151cf272a15b5f2c5e777f2e0933633c513
> +Last-Update: 2017-03-16
> +
> +Patch-Name: ssh-keygen-null-deref.patch
> +---
> + ssh-keygen.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/ssh-keygen.c b/ssh-keygen.c
> +index 0833ee61..a7c1e80b 100644
> +--- a/ssh-keygen.c
> b/ssh-keygen.c
> +@@ -1082,7 +1082,7 @@ known_hosts_hash(struct hostkey_foreach_line *l, void
> *_ctx)
> + struct known_hosts_ctx *ctx = (struct known_hosts_ctx *)_ctx;
> + char *hashed, *cp, *hosts, *ohosts;
> + int has_wild = l->hosts && strcspn(l->hosts, "*?!") != strlen(l->hosts);
> +-int was_hashed = l->hosts[0] == HASH_DELIM;
> ++int was_hashed = l->hosts && l->hosts[0] == HASH_DELIM;
> +
> + switch (l->status) {
> + case HKF_STATUS_OK:
>
> unblock openssh/1:7.4p1-9
>
> Thanks,
>
Re: Bug#857741: closed by Emilio Pozuelo Monfort (unblock openssh)
On 16/03/17 19:48, Cyril Brulebois wrote: > Emilio Pozuelo Monfort (2017-03-16): >> On 16/03/17 16:32, Colin Watson wrote: >>> Control: reopen -1 >>> Control: retitle -1 unblock: openssh/1:7.4p1-9 >>> >>> I'm afraid that 1:7.4p1-8 caused a CI failure, and on investigation this >>> was a real problem easily reproduced in a local adt-run. Sorry for not >>> noticing this earlier. I've uploaded 1:7.4p1-9 to fix this with the >>> following diff. This will presumably need another d-i ack, and >>> certainly an adjustment to the existing hint. >> >> OK. >> >> Explicitly Cc'ing Cyril. > > Thanks and ack as well. Thanks. Unblocked. Cheers, Emilio
Re: Bug#858066: unblock: xfsprogs/4.9.0+nmu1
On 17/03/17 23:27, Michael Biebl wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package xfsprogs > > I contains a single fix to better support merged-usr systems. > This change had already been applied in 4.3.0+nmu1 but was dropped > accidentally by a followup maintainer upload. > I talked to Nathan, the maintainer, and he acked the change. > > Full debdiff is attached. Approved, but needs d-i ack, cc'ing Cyril. Cheers, Emilio > > diff -Nru xfsprogs-4.9.0/debian/changelog xfsprogs-4.9.0+nmu1/debian/changelog > --- xfsprogs-4.9.0/debian/changelog 2017-01-05 23:05:55.0 +0100 > +++ xfsprogs-4.9.0+nmu1/debian/changelog 2017-03-17 19:27:58.0 > +0100 > @@ -1,3 +1,11 @@ > +xfsprogs (4.9.0+nmu1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Remove code in include/buildmacros which creates bogus symlinks for > +libraries. (Closes: #766811) > + > + -- Michael Biebl Fri, 17 Mar 2017 19:27:58 +0100 > + > xfsprogs (4.9.0) unstable; urgency=low > >* New upstream release > diff -Nru xfsprogs-4.9.0/include/buildmacros > xfsprogs-4.9.0+nmu1/include/buildmacros > --- xfsprogs-4.9.0/include/buildmacros2017-01-05 23:05:55.0 > +0100 > +++ xfsprogs-4.9.0+nmu1/include/buildmacros 2017-03-17 19:27:58.0 > +0100 > @@ -75,13 +75,7 @@ > ../$(INSTALL) -m 644 -T old_lib $(LIBNAME).lai $(PKG_LIB_DIR); \ > ../$(INSTALL) -m 644 $(LIBNAME).lai $(PKG_LIB_DIR)/$(LIBNAME).la ; \ > ../$(INSTALL) -m 755 -d $(PKG_ROOT_LIB_DIR); \ > - ../$(INSTALL) -T so_base $(LIBNAME).lai $(PKG_ROOT_LIB_DIR); \ > - if [ "x$(shell readlink -f $(PKG_LIB_DIR))" != \ > - "x$(shell readlink -f $(PKG_ROOT_LIB_DIR))" ]; then \ > - ../$(INSTALL) -S $(PKG_LIB_DIR)/$(LIBNAME).a > $(PKG_ROOT_LIB_DIR)/$(LIBNAME).a; \ > - ../$(INSTALL) -S $(PKG_LIB_DIR)/$(LIBNAME).la > $(PKG_ROOT_LIB_DIR)/$(LIBNAME).la; \ > - ../$(INSTALL) -S $(PKG_ROOT_LIB_DIR)/$(LIBNAME).so > $(PKG_LIB_DIR)/$(LIBNAME).so; \ > - fi > + ../$(INSTALL) -T so_base $(LIBNAME).lai $(PKG_ROOT_LIB_DIR); > else > INSTALL_LTLIB_DEV = $(INSTALL_LTLIB_STATIC) > endif
Re: Bug#858478: unblock: lvm2/2.02.168-2
On 22/03/17 20:35, Bastian Blank wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package lvm2/2.02.168-2. It fixes a bunch of RC bugs.
Ack. Needs a kibi-ack.
Cheers,
Emilio
>
> diff --git a/debian/changelog b/debian/changelog
> index dd72cf181..0af409a67 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,11 @@
> +lvm2 (2.02.168-2) unstable; urgency=medium
> +
> + * Don't try to disable cluster locking on clvm purge. (closes: #856696)
> + * Drop symlinks for private libs. (closes: #857954)
> + * Deny writemostly/writebehind during raid1 resync. (closes: #855895)
> +
> + -- Bastian Blank Fri, 17 Mar 2017 17:29:47 +0100
> +
> lvm2 (2.02.168-1) unstable; urgency=medium
>
>* New upstream release.
> diff --git a/debian/clvm.prerm b/debian/clvm.prerm
> deleted file mode 100644
> index fc683cc7c..0
> --- a/debian/clvm.prerm
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -#!/bin/sh
> -
> -set -e
> -
> -case "$1" in
> -remove)
> -lvmconf --disable-cluster
> -;;
> -esac
> -
> -#DEBHELPER#
> -
> -exit 0
> diff --git a/debian/libdevmapper-dev.install b/debian/libdevmapper-dev.install
> index b02ef0b55..3cf999c4d 100644
> --- a/debian/libdevmapper-dev.install
> +++ b/debian/libdevmapper-dev.install
> @@ -1,3 +1,5 @@
> usr/include/libdevmapper*
> -usr/lib/*/libdevmapper*.so
> -usr/lib/*/pkgconfig/devmapper*
> +usr/lib/*/libdevmapper.so
> +usr/lib/*/libdevmapper-event.so
> +usr/lib/*/pkgconfig/devmapper.pc
> +usr/lib/*/pkgconfig/devmapper-event.pc
> diff --git
> a/debian/patches/0012-lvchange-reject-writemostly-writebehind-on-raid1-dur.patch
>
> b/debian/patches/0012-lvchange-reject-writemostly-writebehind-on-raid1-dur.patch
> new file mode 100644
> index 0..89b6801b4
> --- /dev/null
> +++
> b/debian/patches/0012-lvchange-reject-writemostly-writebehind-on-raid1-dur.patch
> @@ -0,0 +1,146 @@
> +From 27e1059ec6e67a4ac0faaf0f53cd086ac4ed0e35 Mon Sep 17 00:00:00 2001
> +From: Heinz Mauelshagen
> +Date: Thu, 23 Feb 2017 15:09:29 +0100
> +Subject: lvchange: reject writemostly/writebehind on raid1 during resync
> +
> +The MD kernel raid1 personality does no use any writemostly leg as the
> primary.
> +
> +In case a previous linear LV holding data gets upconverted to
> +raid1 it becomes the primary leg of the new raid1 LV and a full
> +resynchronization is started to update the new legs.
> +
> +No writemostly and/or writebehind setting may be allowed during
> +this initial, full synchronization period of this new raid1 LV
> +(using the lvchange(8) command), because that would change the
> +primary (i.e the previous linear LV) thus causing data loss.
> +
> +lvchange has a bug not preventing this scenario.
> +
> +Fix rejects setting writemostly and/or writebehind on resychronizing raid1
> LVs.
> +
> +Once we have status in the lvm2 metadata about the linear -> raid
> upconversion,
> +we may relax this constraint for other types of resynchronization
> +(e.g. for user requested "lvchange --resync ").
> +
> +New lvchange-raid1-writemostly.sh test is added to the test suite.
> +
> +Resolves: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855895
> +---
> + lib/metadata/metadata-exported.h | 1 +
> + lib/metadata/raid_manip.c| 8 ++-
> + test/shell/lvchange-raid1-writemostly.sh | 41
>
> + tools/lvchange.c | 15
> + 4 files changed, 64 insertions(+), 1 deletion(-)
> + create mode 100644 test/shell/lvchange-raid1-writemostly.sh
> +
> +diff --git a/lib/metadata/metadata-exported.h
> b/lib/metadata/metadata-exported.h
> +index cdd4984c1..080073925 100644
> +--- a/lib/metadata/metadata-exported.h
> b/lib/metadata/metadata-exported.h
> +@@ -1212,6 +1212,7 @@ int lv_raid_replace(struct logical_volume *lv, int
> force,
> + struct dm_list *remove_pvs, struct dm_list *allocate_pvs);
> + int lv_raid_remove_missing(struct logical_volume *lv);
> + int partial_raid_lv_supports_degraded_activation(const struct
> logical_volume *lv);
> ++int lv_raid_in_sync(const struct logical_volume *lv);
> + /* -- metadata/raid_manip.c */
> +
> + /* ++ metadata/cache_manip.c */
> +diff --git a/lib/metadata/raid_manip.c b/lib/metadata/raid_manip.c
> +index 7e591e988..00e5551a3 100644
> +--- a/lib/metadata/raid_manip.c
> b/lib/metadata/raid_manip.c
> +@@ -268,7 +268,7 @@ static int _deactivate_and_remove_lvs(struct
> volume_group *vg, struct dm_list *r
> + * Returns: 1 if in-sync, 0 otherwise.
> + */
> + #define _RAID_IN_SYNC_RETRIES 6
> +-static int _raid_in_sync(struct logical_volume *lv)
> ++static int _raid_in_sync(const struct logical_volume *lv)
> + {
> + int retries = _RAID_IN_SYNC_RETRIES;
> + dm_percent_t sync_percent;
> +@@ -299,6 +299,12 @@ static int _raid_in_sync(struct logical_volume *lv)
> + return (sync_percent == DM_PERCENT_100) ? 1 : 0;
> + }
> +
Re: Bug#858481: unblock: bind9/1:9.10.3.dfsg.P4-12.1
On 22/03/17 20:41, Bastian Blank wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package bind9. It just fixes the a bit illadviced and
> unconfigurable use of /dev/random in several critical parts of the named
> process.
Seems fine to me, but needs a kibi-ack for the udeb.
Emilio
>
> diff -Nru bind9-9.10.3.dfsg.P4/debian/changelog
> bind9-9.10.3.dfsg.P4/debian/changelog
> --- bind9-9.10.3.dfsg.P4/debian/changelog 2017-02-19 23:39:32.0
> +0100
> +++ bind9-9.10.3.dfsg.P4/debian/changelog 2017-03-17 19:07:16.0
> +0100
> @@ -1,3 +1,11 @@
> +bind9 (1:9.10.3.dfsg.P4-12.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Use /dev/urandom to avoid blocking in the server process.
> +(closes: #854243)
> +
> + -- Bastian Blank Fri, 17 Mar 2017 19:07:16 +0100
> +
> bind9 (1:9.10.3.dfsg.P4-12) unstable; urgency=high
>
>* Merge and accept the non-maintainer upload.
> diff -Nru bind9-9.10.3.dfsg.P4/debian/rules bind9-9.10.3.dfsg.P4/debian/rules
> --- bind9-9.10.3.dfsg.P4/debian/rules 2017-02-19 23:38:45.0 +0100
> +++ bind9-9.10.3.dfsg.P4/debian/rules 2017-03-17 17:56:39.0 +0100
> @@ -72,6 +72,7 @@
> --enable-filter- \
> --enable-native-pkcs11 \
>
> --with-pkcs11=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)/softhsm/libsofthsm2.so \
> + --with-randomdev=/dev/urandom \
> $(EXTRA_FEATURES)
>
> touch $@
>
> unblock bind9/1:9.10.3.dfsg.P4-12.1
>
> -- System Information:
> Debian Release: 9.0
> APT prefers unstable
> APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
>
Re: Various unblock-udebs
Another round: - pcre3 - screen - glib2.0 - dmraid - debootstrap Thanks, Emilio
Re: Scheduling 9.1, maybe 8.9
On 04/07/17 16:34, Charles Chambers wrote: > Might a lowly user propose taking an extra month so that more of the bugs > installing 9.0 can be worked out? > > It is summer, after all. There will be a 9.2 release. Whatever doesn't get included in 9.1 can be fixed in 9.2. If we applied that argument, we'd never do a point release. Emilio
Re: Please dak copy-installer 20181206
Hi Cyril, On 06/12/2018 18:40, Cyril Brulebois wrote: > Hi, > > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20181206 > > > Release team: FYI, I've urgented it. Can the udeb block be lifted now, or are there still things to do? Thanks, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
Hi Cyril,
On 17/12/2018 15:56, Simon McVittie wrote:
> On Thu, 13 Dec 2018 at 17:00:21 +0100, Emilio Pozuelo Monfort wrote:
>> On 13/12/2018 16:58, Emilio Pozuelo Monfort wrote:
>>> task-pkgs-are-installable-faux depends on task-gnome-desktop, which depends
>>> on
>>> gnome, which is removed from s390x. I'm not comfortable breaking that, you'd
>>> need an ack from Cyril for that. The alternative would be to keep building
>>> gnome from src:meta-gnome3 on s390x but removing the deps that are not
>>> available,
>>> or to apply the proposed mozjs patches from upstream to restore support on
>>> s390x
>>> if those are enough.
>>
>> Another option is to restrict the task-gnome-desktop check to !s390x. But
>> again
>> I'd like an ack from Cyril before doing that in case d-i needs to be updated
>> to
>> not offer that on s390x.
>
> For context for those newly Cc'd:
>
> We have this dependency chain:
>
> task-gnome-desktop -> gnome-core -> gnome-shell -> gjs -> mozjs{52,60}
>
> gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
> on s390x (#909536; about 80% of its tests fail, which means I have no
> confidence that the resulting binaries would be useful or usable if
> we ignored the test failures). As far as I know, the best patches we
> have for that are the ones Julien Cristau tested, which might be part
> of a solution but are not sufficient on their own to make a reasonable
> proportion of the tests pass. (Julien, please correct me if I'm wrong?)
>
> The GNOME team and the release team both seem to be willing to declare
> that the "full-fat" GNOME desktop will not be available on s390x
> machines, which are very conspicuously not available in a desktop or
> laptop form factor :-) I'm fairly sure that GNOME and Mozilla upstream
> have no interest in supporting s390x mainframes either. As a result we
> have arranged for all the JavaScript-based GNOME packages (most notably
> gnome-shell), and the gnome-core and gnome metapackages, to not be built
> on s390x. However, this leaves us with an important task package that
> isn't installable on a release architecture, causing migration to fail.
>
> I suspect gnome-shell may have never worked acceptably on s390x in any
> case, since mainframes are not noted for their 3D graphics hardware,
> and s390x is not currently whitelisted to build the llvmpipe software
> renderer in mesa's debian/rules (I believe the Mesa maintainers are
> willing to enable llvmpipe on new architectures after a porter has tested
> it and told them it works, so a s390x porter could usefully try that out).
>
> The options I can see are:
>
> * Accept that task-gnome-desktop is not going to be installable on s390x.
> Change the testing migration scripts to skip installability testing for
> that package on s390x, or ignore the fact that it fails. Optionally
> change tasksel to make task-gnome-desktop Architecture: any, and give it
> some Build-Depends-Arch that are not satisfiable on s390x so that it will
> not be built there.
> - s390x d-i users will not be able to install a GNOME desktop. Hopefully
> the menu item would not appear, and task-desktop would pick up the
> second-preference desktop instead, which currently seems to be XFCE?
> - Risk: is it possible to ignore uninstallability of task-gnome-desktop
> without ignoring uninstallability of other task packages?
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core installs something that is not
> the full GNOME 3 desktop used on other architectures, for example
> the GNOME-2-derived gnome-session-flashback instead of gnome-session and
> gnome-shell, and lightdm instead of gdm3.
> - s390x users will not get the same GNOME desktop everyone else does.
> - Risk: if GNOME Flashback becomes unsupportable in some future release
> (it's a GNOME 2 derivative a bit like MATE, although without using
> forks of the apps, and most upstream and downstream GNOME maintainers
> don't use or maintain it), we're back where we started.
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core doesn't install a whole desktop
> enviroment at all, just the GNOME applications.
> - s390x users will not get a GNOME desktop at all.
> - Risk: this is not what the user asked for or expected.
>
> * Require task-gnome-desktop to be installable on s390x, but modify
> either tasksel or meta-gnome3 so that on s390x, task-gnome-desktop
> installs some GNOM
Re: Bug#906016: transition: gjs built with mozjs60
Hi, On 05/02/2019 11:16, Simon McVittie wrote: > Please could we have a decision on this in plenty of time before the freeze? > Given the upstream GC improvements aimed at mitigating or solving "the memory > leak problem" in gjs 1.54.x, I am not comfortable with releasing buster with > gjs 1.52.x (which has a backport of those changes done by a developer who does > not have in-depth knowledge of gjs, namely me); so I would like to ask for a > freeze exception to complete this transition. Yes, it is my intention to finish this. > On Thu, 17 Jan 2019 at 10:25:01 +0100, Emilio Pozuelo Monfort wrote: >> On 17/12/2018 15:56, Simon McVittie wrote: >>> The options I can see are: >>> >>> * Accept that task-gnome-desktop is not going to be installable on s390x. >>> Change the testing migration scripts to skip installability testing for >>> that package on s390x, or ignore the fact that it fails. Optionally >>> change tasksel to make task-gnome-desktop Architecture: any, and give it >>> some Build-Depends-Arch that are not satisfiable on s390x so that it will >>> not be built there. >>> - s390x d-i users will not be able to install a GNOME desktop. Hopefully >>> the menu item would not appear, and task-desktop would pick up the >>> second-preference desktop instead, which currently seems to be XFCE? >>> - Risk: is it possible to ignore uninstallability of task-gnome-desktop >>> without ignoring uninstallability of other task packages? > > I would prefer this option if possible: the GNOME desktop is clearly not > intended for use on mainframes, and I doubt anyone is seriously trying to use > it there (as opposed to individual GNOME apps in a remote-desktop framework, > which might be something that people do). However, it requires action from the > release team and d-i maintainers. Cyril, can we do something to not offer task-gnome-desktop on s390x? Does that need changes in d-i or tasksel? >>> * Require task-gnome-desktop to be installable on s390x, but modify >>> meta-gnome3 so that on s390x, gnome-core installs something that is not >>> the full GNOME 3 desktop used on other architectures, for example >>> the GNOME-2-derived gnome-session-flashback instead of gnome-session and >>> gnome-shell, and lightdm instead of gdm3. >>> - s390x users will not get the same GNOME desktop everyone else does. >>> - Risk: if GNOME Flashback becomes unsupportable in some future release >>> (it's a GNOME 2 derivative a bit like MATE, although without using >>> forks of the apps, and most upstream and downstream GNOME maintainers >>> don't use or maintain it), we're back where we started. > > With the freeze approaching fast, if we can't have a solution that requires > action to be taken outside the GNOME team, this is probably the best thing > that > the GNOME team can do unilaterally. An untested git branch for this: > https://salsa.debian.org/gnome-team/meta-gnome3/merge_requests/3 Alternatively, this is probably the way to go. Cheers, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
On 08/02/2019 17:21, Simon McVittie wrote: > On Fri, 08 Feb 2019 at 16:48:52 +0100, Cyril Brulebois wrote: >> I'm not sure how to hide a particular entry on a particular arch; I'm >> not a tasksel expert and won't be one in the next 5 minutes. But it >> seems to me the immediate concern was about the default desktop anyway, >> which shouldn't be an issue in the first place because of this >> default_desktop shell function? > > The immediate concern is that gjs and friends don't migrate to testing, > because the release team's migration infrastructure asserts that all > task packages remain installable on all release architectures, and that > isn't true any more for task-gnome-desktop on s390x. > > Do you consider it to be OK that non-default desktops can be uninstallable > on s390x? If so, hopefully the release team can relax that check. My worry if I were to do that is that the installer would still offer to install GNOME on s390x, and I don't know what would happen if one chose that (I suppose apt would realise it's uninstallable and give a proper error, but maybe things would explode). So if we're going to make task-gnome-desktop uninstallable there, maybe the installer shouldn't offer to install it, and that needs changes somewhere in tasksel or d-i. Cheers, Emilio
Re: Bug#906016: transition: gjs built with mozjs60
On 08/03/2019 10:07, Simon McVittie wrote:
> Control: block -1 by 923694
>
> On Sat, 02 Mar 2019 at 22:21:31 +, Simon McVittie wrote:
>> On Tue, 05 Feb 2019 at 10:16:56 +, Simon McVittie wrote:
> * Require task-gnome-desktop to be installable on s390x, but modify
> meta-gnome3 so that on s390x, gnome-core installs something that is not
> the full GNOME 3 desktop used on other architectures, for example
> the GNOME-2-derived gnome-session-flashback
>>
>> In the absence of other progress, I've staged this in git. I'll release
>> it soon if nobody else in the team gets there first.
>
> This has now reached testing, but gjs is blocked by gnome-documents:
>
> trying: polari gjs gnome-shell gdm3 gnome-sushi
> skipped: polari gjs gnome-shell gdm3 gnome-sushi (0, 1, 25)
> got: 33+0: a-1:a-0:a-0:a-0:i-30:m-0:m-0:m-0:p-0:s-2
> * s390x: gnome-documents
>
> gnome-documents already has an unblock request.
>
> If that unblock is rejected or if the release team are not sure about
> it yet, the gnome-documents_3.30.0-1_s390x binary could be forcibly
> removed from testing, which I think would let the gjs family migrate.
> `dak rm -R -n -s testing -a s390x gnome-documents` says nothing else on
> s390x depends on gnome-documents any more.
I unblocked and aged gnome-{documents,books}, my britney test run has gjs
migrating now, so it should happen in the next few hours.
Cheers,
Emilio
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
On 17/04/15 13:51, Martin Pitt wrote: > BTW, 215-16 still didn't hit testing, so I didn't upload -17 yet. I'll > do as soon as it migrates. systemd| 215-16 | testing | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x systemd| 215-16 | unstable | source, amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x, sparc Emilio -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5530fa98.3060...@debian.org
Re: Bug#988083: unblock: micro-evtd/3.4-6
On 05/05/2021 07:26, Ryan Tandy wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package micro-evtd [ Reason ] One-line patch to fix FTBFS (#987631). Also taking the opportunity to update the Maintainer field; I hope that's OK. [ Impact ] The package currently in bullseye (same as buster) works, however it FTBFS with bullseye's glibc. [ Tests ] There are no automated tests. I have been running the updated daemon for a few days, and I tested an installation with the updated udeb (using a d-i daily image). [ Risks ] I built the package on buster with and without the patch, to see what would change. The disassembly (objdump -d) was the same before and after, so I think I can be confident the header was not actually used and the patch should not change its behaviour. However, the package had not been rebuilt since before buster was released, so there could be unknown risks arising from rebuilding with the newer toolchain. [ Checklist ] [✔] all changes are documented in the d/changelog [✔] I reviewed all changes and I approve them [✔] attach debdiff against the package in testing [ Other info ] Very low popcon. The package provides hardware support for a specific subset of armel/orion5x NAS devices with few remaining users. The package builds a udeb. I tested an installation using a daily d-i image that includes the update. Cyril, can you (n)ack for d-i? Thanks, Emilio
Re: Accepted wxwidgets3.2 3.2.2+dfsg-1 (source) into unstable
On 13/02/2023 22:40, Samuel Thibault wrote: Samuel Thibault, le lun. 13 févr. 2023 14:50:33 +0100, a ecrit: gregor herrmann, le lun. 13 févr. 2023 00:26:54 +0100, a ecrit: On Mon, 13 Feb 2023 00:09:20 +0100, Cyril Brulebois wrote: Debian FTP Masters (2023-02-11): Format: 1.8 Date: Sat, 11 Feb 2023 13:15:16 -0500 Source: wxwidgets3.2 Architecture: source Version: 3.2.2+dfsg-1 Distribution: unstable Urgency: medium Maintainer: wxWidgets Maintainers Changed-By: Scott Talbert Closes: 1028427 Changes: wxwidgets3.2 (3.2.2+dfsg-1) unstable; urgency=medium . * d/watch: fix download URL when using GitHub API * Update to new upstream release 3.2.2 * Add Breaks/Replaces to libwxgtk-gl3.2-1 (Closes: #1028427) This seems to have made libalien-wxwidgets-perl uninstallable, as seen in my devel chroot but also for any systems, as mentioned on tracker: https://tracker.debian.org/pkg/wxwidgets3.2 If we're lucky, a binNMU of libalien-wxwidgets-perl against libwxgtk3.2-dev,libwxgtk-media3.2-dev 3.2.2 (and later of libwx-perl against the rebuilt libalien-wxwidgets-perl) might be enough. A local rebuild of libalien-wxwidgets-perl runs through, including autopkgtests. (I haven't tried the second step with libwx-perl.) Building the two packages does fix the dependencies indeed. Can these binnmus be scheduled please? So working on d-i doesn't stay stuck on this. nmu libalien-wxwidgets-perl_0.69+dfsg-6 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.2+dfsg-1" Thanks for this one, now installed :) Now we need that one: nmu libwx-perl_0.9932-8 . ANY . unstable . -m "Rebuild against libwxgtk3.2-dev 3.2.2+dfsg-1" Scheduled. Cheers, Emilio
