[09:14] tsimonq2: debian/patches? === ogra_ is now known as ogra [12:12] -queuebot:#ubuntu-release- Unapproved: network-manager-openconnect (bionic-proposed/universe) [1.2.4-1 => 1.2.4-1ubuntu1] (no packageset) === pleia2_ is now known as pleia2 [16:41] -queuebot:#ubuntu-release- New binary: cpdb-libs [amd64] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:41] -queuebot:#ubuntu-release- New binary: cpdb-libs [s390x] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:41] -queuebot:#ubuntu-release- New binary: cpdb-libs [ppc64el] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:42] -queuebot:#ubuntu-release- New binary: cpdb-libs [armhf] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:43] -queuebot:#ubuntu-release- New binary: cpdb-libs [arm64] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:43] -queuebot:#ubuntu-release- New binary: cpdb-libs [i386] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset) [16:43] mwhudson: I need a config variable set in a native package via /etc/xdg/xdg-Lubuntu/lxqt/panel.conf [16:43] It should be on the live system only. [17:11] wxl: Heya. [17:11] o/ [17:12] wxl: You've read through https://wiki.ubuntu.com/ProposedMigration or at least skimmed it? [17:12] yep [17:12] Cool. [17:13] So, with transitions as big as ours, there's gotta be something failing an autopkgtest. [17:13] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has a full list, and you can access specific packages via http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src [17:13] well there's only one of 5 possibilites so you've got a 20% chance of being right :) [17:14] hahahaha [17:14] wxl: We want it to say "Valid candidate" at the bottom. [17:14] From there, that part of the testing has passed, and then it goes to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt [17:15] @tsimonq2: ignore the ignored failures i assume? [17:15] wxl: Right. [17:15] All of the "hints", or known failures, are available here: https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files [17:15] We [17:15] grr [17:16] We're trying to move it over to team files, such as "ubuntu-release" instead of e.g. "vorlon" [17:16] looks like there's a handful of always failed. shouldn't be too difficult [17:17] wxl: So, if you know an autopkgtest is bad, you can either make an MP there or ask someone here. [17:17] But right. [17:17] *Usually* it's annotated with a comment. [17:18] wxl: What isn't documented though, is there's an update_output.txt that's *before* all the tests are passed. [17:18] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt [17:18] So what I typically do, for e.g. Qt to migrate, is search for the first entry in the file for qtbase-opensource-src where it's grouped in with a bunch of other packages. [17:19] From then on, it tries to separate it into different migratable chunks. [17:20] like the one that begins with qtserialport-opensource-src and ends with khangman? [17:20] Right. [17:20] So, with these, you can sometimes diff the listing in update_output.txt with the listing in update_output_notest.txt. [17:21] Because the latter is with tests *not* considered. [17:22] Either way, if you're in update_output.txt and the "got" stanza does not contain any other -proposed packages in it, you might want to try looking at Ben: https://people.canonical.com/~ubuntu-archive/transitions/ [17:22] Ben is a graphical representation of some of these transitions; I would encourage you to look into it. [17:23] The trick is to try to make A) Ben happy for a transition. B) All autopkgtests passable. C) Make everything installable. [17:23] ok so let's work on an example. walk me through it step by step. [17:24] So, that big one you mentioned before starting with qtserialport and ending with khangman. [17:24] ok [17:24] The only reason why it can't all migrate now is because of these lines: [17:24] got: 32+0: a-3:a-2:a-4:i-2:p-19:s-2 [17:24] * ppc64el: emacs25, emacs25-lucid, libsbml5-octave, octave-lhapdf, octave-ocs, octave-odepkg, octave-plplot, paraview, paraview-dev, paraview-python, performous, rbdoom3bfg, ring, ring-daemon, tupi, vcmi, vdr-plugin-softhddevice [17:25] So, when these packages are installed, upgrading that whole stack shown in "trying" breaks all of these *somehow*. [17:25] -queuebot:#ubuntu-release- New source: cpdb-backend-file (cosmic-proposed/primary) [1.0.0-0ubuntu1] [17:25] and it's only affecting ppc64el? [17:26] It cycles through all of the architectures in every run. [17:26] So this run it'll be ppc64el, next run should be s390x, etc. [17:26] oic [17:27] In Ubuntu, unlike Debian, we don't split arch:all and amd64, so amd64 could(!) yield more results. [17:27] we need a vim plugin with custom folding [17:27] Oh? :) [17:27] I don't catch your drife. [17:27] *drift [17:27] so you could fold away the lines that are irrelevant and focus only on the important bits [17:27] anyways carry on [17:28] So, that's what is uninstallable. Often times within that you can find a dep tree. [17:29] I personally scan Ben next to see if there's something that corresponds to any of these packages. [17:29] https://people.canonical.com/~ubuntu-archive/transitions/ [17:30] I see Octave. [17:31] i'm with you [17:31] Indeed: https://launchpad.net/ubuntu/+source/emacs25/25.2+1-6build2 [17:31] So the goal with all of these is to find source packages and what's wrong with them. [17:31] That's a bit of a unique error, so I'll look into it. [17:32] INFO Upload was rejected: [17:32] INFO emacs25-lucid_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10 [17:32] INFO emacs25-nox_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10 [17:32] INFO emacs25_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10 [17:32] what about octave? [17:32] INFO Committing the transaction and any mails associated with this upload. [17:32] Fun. [17:32] wxl: Well, Ben needs to be looked at for that it seems. [17:33] emacs took over emacs25 package + friends [17:33] acheronuk: Got it, so that probably needs AA processing if I'm not wrong? [17:33] [23:44] emacs needed a binary promotion (because emacs stole emacs25 source) [17:34] Bingo. [17:34] wxl: So, that's part of what's blocking it; an Archive Admin such as slangasek (there's a few more victims^Mpeople you can poke) needs to press buttons. [17:34] Otherwise, I'll look at Octave. [17:35] let's find an "easy" one for me and i'll leave the hard ones for you [17:35] octave is not on the last update_output for i386 [17:35] * i386: emacs25, emacs25-lucid, paraview, paraview-dev, paraview-python, performous, pfsglview, pfstools, pfsview, rbdoom3bfg, ring, ring-daemon, tupi, vcmi, vdr-plugin-softhddevice [17:36] Hmm. [17:36] Oh, I was looking at notest, hah. [17:36] wxl: So, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#octave is an example of a package with failing tests. [17:37] Since Debian started testing for those, you can usually(!) find a corresponding Debian bug. [17:38] Looks like octave-ocs is not in Testing, so it might need a demotion: https://tracker.debian.org/pkg/octave-ocs [17:38] (Demotion to -proposed.) [17:39] wxl: This demonstrates the general point that this is a rabbit hole. :P [17:39] yes [17:40] and at this point i'm starting to wonder how i'm going to be helpful because it's going to take half the time to explain to me what it is i'm even looking at [17:40] Once you learn what you're looking at, it's easy enough to understand what you're dealing with. [17:41] wxl: If you want, I can continue to hunt the transition on my own, but it'd be cool if you could continue to stick around for the ride. :) [17:41] don't think we need octave for Qt though. normal output where it's not grouped due to the failing tests would migrate Qt without it [17:41] i'm here to help [17:42] acheronuk: Right. [17:43] Fixing https://launchpad.net/ubuntu/+source/ring/20180712.2.f3b87a6~ds1-1build1 is needed it seems. [17:43] * tsimonq2 hunts for upstream patches... [17:45] -queuebot:#ubuntu-release- New source: cpdb-backend-file (cosmic-proposed/primary) [1.0.1-0ubuntu1] [17:53] so going back to octave.. it's passing in excuses, so i guess that's what you mean about the tests before the tests? [17:53] Yeah, kinda. [17:53] What our real concern right now is is ring. [17:54] https://launchpad.net/ubuntu/+source/ring/20180712.2.f3b87a6~ds1-1build1 [17:54] The build passes in Debian but not in Ubuntu. I'm trying a fresh build locally. [17:54] If it FTBFS in a fresh Sid chroot, I'll file a bug there and it'll be their problem. ;) [17:57] that may be so, but it's still OUR problem as it's blocking OUR transition [17:58] You're not *wrong*. :P [17:59] I just mean more may be required from us than just 'passing the ball' [18:00] if we want our transition through this year! [18:13] Oh, that's probably why. [18:13] It's FTBFS with the new boost! [18:13] grr [18:15] * tsimonq2 wonders why doko switched our default Boost to 1.67 while Debian's is still at 1.62... [18:18] For these FTBFS packages, I'm going to switch the build dep to explicitly pull in 1.62 (even though it's in Universe, it's still default in Debian) and file bugs there that it FTBFS with 1.67... eventually once those are solved we should be able to sync. [18:18] Because some of these don't even have patches upstream yet. [18:22] tsimonq2: boost 1.65 was default for bionic, and debian didn't have that either [18:22] ginggs: Ah, got it. [18:23] ginggs: Where's the source package for 1.65? I can't seem to find it under the normal naming scheme. [18:23] https://launchpad.net/ubuntu/+source/boost1.65.1 [18:23] ack [18:24] apparently ftp-master weren't happy with debian/copyright in boost [18:25] With which one? [18:25] all of them [18:27] Oh. :P [18:30] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906690 [18:31] Debian bug 906690 in ring "ring: FTBFS with Boost 1.67" [Important,Open] [18:40] doko, xnox: Since Boost 1.67 was something you both were involved in, could you please solve the ring FTBFS? I don't know enough about Boost. [18:54] Trying a new version of yaml-cpp from Debian's Git repo. [18:57] tsimonq2: missing include? [18:57] acheronuk: New yaml-cpp drops depends on boost 😆 [18:58] acheronuk: So if this works, I call it a workaround. :P [18:58] It doesn't help that the maintainer is MIA though. [18:58] can we easily get a list of all the ones that require boost? [18:59] What do you mean? [19:02] well we have could generate a list of potentially problematic packages, then iterate through them checking to see if they have depends on boost [19:04] wxl: Right, that's just grepping excuses :) [19:04] Aww, yaml-cpp is FTBFS :( [19:51] There, I'm thinking that yaml-cpp upload will fix it. [19:51] We shall see...... [19:56] slangasek: Could you please demote vdr-plugin-softhddevice to cosmic-proposed? There's been an open bug in Debian since January about fixing support with ffmpeg, which hasn't been solved. Debian bug 888331. [19:56] Debian bug 888331 in src:vdr-plugin-softhddevice "vdr-plugin-softhddevice: FTBFS with FFmpeg 4.0" [Serious,Open] http://bugs.debian.org/888331 [20:13] NICE, yaml-cpp does fix it. [20:14] slangasek, it turned out to be relatively simple to do, and fixing a build failure gave me 12 hours of "good work" in fixing what was left to do, instead of seeing aways the same useless stuff in update_output... so not entirely a waste of time [20:14] :) [20:23] wxl: A good challenge is to find yaml-cpp rdeps with `reverse-depends [-b]` and give me a list to retry :) [20:25] paraview... anybody has hints? [20:25] I rebuilt the last two xorg packages [20:25] I was looking at that and couldn't quite figure it out. [20:25] we probably missed them because they are arch:arm* only [20:25] I even tried a build with no-parallel... [20:25] LocutusOfBorg: Tag team you in? :) I will be mostly AFK for the next 6 hours. [20:25] nothing changes [20:26] tsimonq2, paraview FTBFS in debian too [20:26] so you can open an RC bug there [20:26] ack [20:26] I can do that later unless you want to now. [20:26] I can give you a link to build log [20:26] Please do, pastebin? [20:27] http://debomatic-amd64.debian.net/distribution#unstable/paraview/5.4.1+dfsg4-3/buildlog [20:27] there [20:27] various MB of logs... [20:47] @teward: doesn't look like it. you're it. [20:48] heh, was merely curious, since nginx is now tracking Mainline at least for 18.10 and 19.04 [20:48] ... and I may have implemented something to stop the "Can't start nginx, something's already on port 80" "not-a-bug" bug reports that keep getting filed [20:49] not going to start the release notes yet though :p [20:49] an apport-hook that looks for "80" in the report and rejects it? :) [20:51] wxl: preemots even that [20:51] preempts* [20:51] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1782226 [20:51] Ubuntu bug 1782226 in nginx (Ubuntu Bionic) "Allow NGINX to install but not start during postinst if another process is bound to port 80" [Wishlist,Triaged] [20:51] oh my [20:53] mhm [20:53] wxl: preempts those issues by addressing the problem in the postinst [20:54] if it's a new install but something else is bound to port 80 it doesn't attempt to start nginx at all, but spits a note out into the logs [20:54] Not my favorite approach, but... [20:54] i'm tired of 20+ "I just installed nginx and it won't start idk why" bugs which are really "Something else is bound to Port 80, go find it and shut it off" Invalid NotABugs. [20:55] to be honest i think everyone is :P [21:42] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (cosmic-proposed/universe) [18.10] (personal-fossfreedom, ubuntu-budgie) [22:05] tsimonq2: oh, live system only hacks might be more appropriate in livecd-rootfs i guess [23:42] -queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.6 => 18.04.14.7] (core) [23:48] -queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.1 => 10.1ubuntu2.2] (core)