| -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1004.4] (core, kernel) | 00:10 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1004.4] (core, kernel) | 00:10 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1004.4] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1004.4] | 00:12 | |
| infinity | Okay, the way things are looking, I think I'll just respin first thing in the morning instead of worrying about doing a hand-off, etc. | 00:12 |
|---|---|---|
| infinity | Cause it'll be past NA bedtime by the time all this stuff is happy and moving. | 00:13 |
| -queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu569 => 20101020ubuntu570] (core) | 00:16 | |
| -queuebot:#ubuntu-release- Unapproved: rejected linux-gcp [sync] (disco-proposed) [5.0.0-1004.4] | 00:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (disco-proposed) [20101020ubuntu570] | 00:20 | |
| -queuebot:#ubuntu-release- Unapproved: thunar (disco-proposed/universe) [1.8.4-1 => 1.8.4-1ubuntu1] (mythbuntu, ubuntustudio, xubuntu) | 00:34 | |
| bluesabre | infinity: can you go ahead and approve the above thunar upload so it makes it into tomorrow's respin? :) | 00:35 |
| bluesabre | Including the (please) I forgot just now | 00:36 |
| infinity | I'll leave that to vorlon. | 00:37 |
| * infinity sleeps for a few hours. | 00:38 | |
| vorlon | looking | 00:38 |
| bluesabre | infinity, vorlon, much appreciated :) | 00:39 |
| vorlon | bluesabre: rather large patch, and the header says it's 1/3. how sure are you this fixes the issue? | 00:39 |
| vorlon | oh, it's 3 patches serialized in 1 file :P | 00:39 |
| bluesabre | vorlon: yes, the patch submitted upstream was a 3-parter (parts 2 and 3 are in the same patch), https://bugzilla.xfce.org/attachment.cgi?id=8408 | 00:39 |
| bluesabre | :) | 00:40 |
| vorlon | bluesabre: so you've already tested this locally and confirmed it fixes? | 00:40 |
| bluesabre | as for how sure, I was 100% able to reproduce the issue before (was driving me nuts), and can no longer reproduce now | 00:40 |
| vorlon | ok | 00:40 |
| -queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (disco-proposed) [1.8.4-1ubuntu1] | 00:41 | |
| bluesabre | vorlon: thanks a bunch! | 00:41 |
| mwhudson | infinity: about to release the hopefuly final subiquity to stable btw | 01:15 |
| -queuebot:#ubuntu-release- Unapproved: runc (cosmic-proposed/universe) [1.0.0~rc4+dfsg1-6ubuntu0.18.10.1 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~18.10.1] (no packageset) | 01:28 | |
| -queuebot:#ubuntu-release- Builds: Netboot amd64 [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Builds: Netboot arm64 [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Builds: Netboot armhf [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Builds: Netboot i386 [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Builds: Netboot ppc64el [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Builds: Netboot s390x [Disco Final] has been updated (20101020ubuntu570) | 01:31 | |
| -queuebot:#ubuntu-release- Unapproved: runc (bionic-proposed/universe) [1.0.0~rc4+dfsg1-6ubuntu0.18.04.1 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.1] (no packageset) | 01:32 | |
| -queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.2 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.1] (no packageset) | 01:35 | |
| -queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset) | 01:39 | |
| -queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset) | 01:40 | |
| mwhudson | blugh | 01:40 |
| mwhudson | can someon reject those containerd uploads? forgot something | 01:40 |
| -queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset) | 01:46 | |
| -queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset) | 01:50 | |
| -queuebot:#ubuntu-release- Unapproved: containerd (xenial-proposed/universe) [0.2.5-0ubuntu1~16.04.1 => 1.2.6-0ubuntu1~16.04.1] (no packageset) | 01:52 | |
| -queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [18.09.2-0ubuntu1~18.10.1 => 18.09.5-0ubuntu1~18.10.1] (no packageset) | 01:57 | |
| -queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.09.2-0ubuntu1~18.04.1 => 18.09.5-0ubuntu1~18.04.1] (no packageset) | 01:59 | |
| -queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [18.09.2-0ubuntu1~16.04.1 => 18.09.5-0ubuntu1~16.04.1] (no packageset) | 02:01 | |
| === s8321414_ is now known as s8321414 | ||
| mwhudson | infinity: released subiquity to stable now | 02:36 |
| mwhudson | should be ready for any iso testing people still have time for ... | 02:36 |
| teward | mwhudson: does that happen to contain a fix for 1821966 and search domains? | 02:39 |
| teward | just curious :P | 02:39 |
| mwhudson | teward: yes | 02:39 |
| mwhudson | teward: although you should test tomorrow's daily to make sure! | 02:39 |
| teward | well then I'll test tomorrow's daily :P | 02:40 |
| mwhudson | tia! | 02:40 |
| teward | mwhudson: any idea when the dailies generate? | 02:46 |
| teward | so I know when tomorrow to test :p | 02:46 |
| acheronuk | teward: disco dailies are turned off AFAIK | 04:41 |
| -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (disco-proposed/main) [64ubuntu6 => 64ubuntu7] (ubuntu-desktop) (sync) | 06:26 | |
| -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) | 06:51 | |
| LocutusOfBorg | doko, ^^ I tried to fix your kopanocore upload, but I'm not really sure about the fix... | 06:52 |
| LocutusOfBorg | maybe the fix should go in src:apport? | 06:53 |
| LocutusOfBorg | maybe juliank ^^ ? does apt need to read cputable? | 06:55 |
| juliank | LocutusOfBorg: yes, it does | 06:56 |
| LocutusOfBorg | does it have an apport profile? | 06:56 |
| LocutusOfBorg | I don't get why kopanocore fails testsuite in that way | 06:56 |
| LocutusOfBorg | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190305_224317_8d7c5@/log.gz | 06:57 |
| juliank | I don't think it does | 06:57 |
| LocutusOfBorg | kopanocore fails because of that file being non accessable, the obviously fix is to add to the profile (looks like working on DebOMatic, but maybe that machine has no apport enforcement, not sure) | 06:58 |
| -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu4 => 1.10ubuntu5] (core) | 06:58 | |
| LocutusOfBorg | and in any case kopanocore doesn't directly access that file, so it might be a dpkg/apt bug hidden somewhere? | 06:58 |
| rbalint | ^one more fix for the errors seen in disco and also fixing slowness in bionic | 06:59 |
| juliank | LocutusOfBorg: I'm not sure why it's not accessible | 07:00 |
| juliank | dpkg ships that file, and apt requires it being present | 07:00 |
| rbalint | upstreadm review: https://github.com/mvo5/unattended-upgrades/pull/190 | 07:00 |
| gitbot | mvo5 issue (Pull request) 190 in unattended-upgrades "Adjust only transitive dependencies in the fallback" [Open] | 07:00 |
| rbalint | juliank, i really want to do pinning only and not adjustments in u-u | 07:01 |
| juliank | rbalint: well, then, do it I guess - I think the infra is there now, although a bit hacky | 07:04 |
| LocutusOfBorg | AppArmor parser error for /etc/apparmor.d/usr.sbin.kopano-search in /etc/apparmor.d/usr.sbin.kopano-search at line 39: missing an end of line character? (entry: /etc/ssl/openssl.cnf) | 07:07 |
| LocutusOfBorg | DAMN | 07:07 |
| juliank | ^fun | 07:08 |
| rbalint | juliank, also i measured u-u to be much slower | 07:08 |
| rbalint | juliank, needs to move to low level apt api first, it seems | 07:08 |
| LocutusOfBorg | devil is hidden in the details | 07:08 |
| * LocutusOfBorg grabs coffee and prepares a big hammer | 07:08 | |
| juliank | rbalint: You should add an action group around the adjustment loop I think | 07:09 |
| LocutusOfBorg | + signal (send) set=("term") peer=unconfined, | 07:09 |
| LocutusOfBorg | what is the problem on this? | 07:09 |
| juliank | rbalint: because this is wreaking havoc in recalculating installability each time you adjust one | 07:09 |
| LocutusOfBorg | oh no | 07:10 |
| rbalint | juliank, the speed is not terrible and actiongroups caused problems with cache clear, thus i don't want to risk that now | 07:12 |
| juliank | Well, yes | 07:12 |
| rbalint | juliank, the side effects of action groups are not crystal clear | 07:12 |
| -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) | 07:13 | |
| juliank | Well, they are perfectly clear - the action group delays recalculating stuff in the dep cache | 07:13 |
| juliank | Obviously, you can't re-initialize the depcache while you're holding an action group | 07:13 |
| juliank | s/Obviously/It follows that/ | 07:14 |
| juliank | action groups should provide a drastic performance increase | 07:14 |
| juliank | switching to low-level should offer basically no performance | 07:14 |
| juliank | Probably should raise an exception when clearing a cache that has an action group | 07:15 |
| juliank | rbalint: Or to be more clear, action groups, when released, re-calculate which packages are autoremovable and which are not | 07:18 |
| juliank | rbalint: So, if you re-initialize the cache while holding the action group, you'll end up with wrong autoremovable states | 07:20 |
| juliank | rbalint: But yes it will require some restructuring of u-u to work with that model | 07:22 |
| juliank | though i do not understand _how_ it delays things | 07:23 |
| juliank | Ah I see | 07:23 |
| juliank | The code is super odd | 07:23 |
| juliank | e.g. MarkInstall() keeps an ActionGroup during its call | 07:24 |
| juliank | so, if there is no other action group, it will be released at the end | 07:24 |
| juliank | same for set candidate version | 07:24 |
| juliank | rbalint: What this means is that each time you adjust the candidate, or mark something for install/remove, apt traverses the entire set of packages reachable from the installed ones and marks them as reachable | 07:25 |
| juliank | which is, um, slow | 07:25 |
| rbalint | juliank, yes i can see that | 07:25 |
| rbalint | juliank, and rather than trying to sped this up a bit i'd like to drop adjustments and use pinning | 07:26 |
| juliank | But we can fix apt, so that Init() works with an actiongroup hold actually works well, then you can clear the cache as often as you like | 07:26 |
| rbalint | that would also be wonderful and speed up other clients as well | 07:27 |
| juliank | rbalint: oh, but you still have to release the action group before determining which packages are auto-removable | 07:32 |
| juliank | But I'm wondering if python-apt could not automatically manage an action group for you | 07:32 |
| juliank | basically, keep an action group until you are looking at autoremovable states | 07:33 |
| rbalint | infinity u-u 1.10ubuntu5 autopkg passed locally in bionic vm | 07:33 |
| juliank | it's a bit fragile if actiongroup behavior changes in the future | 07:34 |
| rbalint | how about not changing it and seeing how u-u performs using pinning and low level apt api? | 07:35 |
| rbalint | maybe automatic action group would just slow it down | 07:36 |
| -queuebot:#ubuntu-release- Unapproved: base-files (disco-proposed/main) [10.1ubuntu8 => 10.1ubuntu9] (core) | 07:39 | |
| -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] | 07:43 | |
| juliank | rbalint: I just thought I'd have apt set a dirty bit instead when it makes the "autoremovable" cache dirty, rather than recalculating right then; and then when requesting autoremovable state, recalc it if it's dirty. | 07:43 |
| juliank | should be a nice gain for most users and avoid the need for action groups | 07:43 |
| rbalint | juliank, it would help a lot if there were info on action to not use https://apt-team.pages.debian.net/python-apt/library/apt.cache.html?highlight=actiongroup#apt.cache.Cache.actiongroup | 07:44 |
| -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [sync] (disco-proposed) [64ubuntu7] | 07:44 | |
| infinity | LocutusOfBorg: That kapanocore change doesn't look sane to me. At least, not from my reading of other apparmor profiles over the years. | 07:45 |
| rbalint | juliank, ok, but can't i read autoremovable state of packages withot noticing the dirtyness? | 07:45 |
| juliank | rbalint: Well, I'd replace the fields in apt's cache with accessor methods | 07:45 |
| rbalint | juliank, does not sound like a speedup... | 07:46 |
| juliank | that do bool Garbage() { if (dirty) MarkAndSweep(); return Garbage; } | 07:46 |
| juliank | rbalint: It certainly is not a speedup for those who use action groups now, yes | 07:46 |
| infinity | juliank: Can you review this u-u in the queue and give me a thumbs up or down? It's a bit long for my python-hating brain this morning. | 07:47 |
| juliank | It's also shorter than it looks because it's the same file two times | 07:48 |
| juliank | infinity: I did look at it yesterday in github, and it looks ok | 07:49 |
| juliank | - marking_succeeded = self.call_checked(function, pkg, **kwargs) | 07:49 |
| juliank | + self.call_checked(function, pkg, **kwargs) | 07:49 |
| juliank | is the only thing I'm confused about | 07:49 |
| infinity | "it looks okay" shouldn't be followed by "but..." on another line. :P | 07:50 |
| rbalint | juliank, i made minor edits | 07:50 |
| -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu5] | 07:50 | |
| infinity | (already accepted it) | 07:50 |
| infinity | But please, talk amongst yourselves, and if you have something better to upload, I'd like it in ~30m. | 07:50 |
| -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (disco-proposed) [10.1ubuntu9] | 07:51 | |
| juliank | infinity: Well, it's OK, it just looks slightly odd, but the variable is not used afterwards, so it's technically fine | 07:51 |
| rbalint | juliank, yep, it was an obsolete assignment | 07:53 |
| LocutusOfBorg | infinity, you mean the first or the second upload? | 07:55 |
| infinity | LocutusOfBorg: The seonc. | 07:55 |
| infinity | second, too. | 07:55 |
| infinity | - /etc/ssl/openssl.cnf r, | 07:56 |
| infinity | + /etc/ssl/openssl.cnf r | 07:56 |
| LocutusOfBorg | did you see the diff between -1 and -2 uploads? | 07:56 |
| LocutusOfBorg | I mean the good and the bad one | 07:56 |
| LocutusOfBorg | http://launchpadlibrarian.net/412007799/kopanocore_8.7.0-1build1_8.7.0-2.diff.gz | 07:56 |
| infinity | .... and? | 07:57 |
| infinity | -2 looks correct to me. | 07:58 |
| LocutusOfBorg | :( so I don't know... | 08:00 |
| LocutusOfBorg | LocutusOfBorg: ^^ seriously?20:04 | 08:00 |
| LocutusOfBorg | vorlonwe're in final freeze. *critical fixes only*, not "sync new upstream versions to be in sync" | 08:00 |
| LocutusOfBorg | ^^ vorlon I miss the context, I fixed other people syncs from experimental I didn't sync by myself from there | 08:01 |
| LocutusOfBorg | and if you mean mokutils a) its mostly a no change sync (modulo some maintainer field and vcs fields updated), and it is from unstable, and blame tsimonq2 for this :) | 08:02 |
| LocutusOfBorg | if you mean vala, I don't sync vala, for sure not from experimental :) | 08:02 |
| * LocutusOfBorg would like to forbid experimental syncs | 08:02 | |
| infinity | 14:05 -queuebot:#ubuntu-release- Unapproved: rejected mokutil [sync] (disco-proposed) | 08:02 |
| infinity | [0.3.0+1538710437.fb6250f-1] | 08:02 |
| infinity | 14:06 < vorlon> not even new upstream version; but regardless, no | 08:03 |
| infinity | LocutusOfBorg: ^ That was the context. | 08:03 |
| LocutusOfBorg | well, its a cosmetic change I sponsored for tsimonq2, in any case I don't think the end user will care about a wrong VCS field... | 08:03 |
| infinity | LocutusOfBorg: And how does one blame someone else for your upload? | 08:03 |
| Laney | Perhaps don't upload cosmetic changes in final freeze. | 08:04 |
| LocutusOfBorg | yep sure, isn't VCS fields something end users care about? | 08:04 |
| infinity | Laney: I'll be in the office in ~30... Got distracted working from the hotel and didn't notice the time. :P | 08:04 |
| LocutusOfBorg | I mean, is debcheckout supposed to being run from ubuntu users? | 08:05 |
| juliank | it's not | 08:05 |
| juliank | I mean, think about it | 08:05 |
| infinity | "regular users" use binary packages. | 08:05 |
| Laney | infinity: I'mjust arriving into St PancrasinfI'm just arriving into St Pancras | 08:05 |
| Laney | FML | 08:05 |
| Laney | If this even sends | 08:05 |
| Laney | see if you can tell from that that I'm on a train | 08:05 |
| infinity | Laney: Hahaha. It sent. All the times. | 08:05 |
| juliank | The Vcs field is only useful for devel | 08:06 |
| juliank | if at all | 08:06 |
| LocutusOfBorg | infinity, good point :) I would say "regular users don't use linux" probably :p | 08:06 |
| Laney | WHICH STATION IS LANEY AT? | 08:06 |
| Laney | 'k, see you soon | 08:06 |
| juliank | Because the Vcs change often enough for a stable release to be outdated anyway, and we don't SRU Vcs field changes | 08:06 |
| juliank | And since we do not SRU Vcs field changes, it's also not appropriate for an upload during final freeze | 08:07 |
| LocutusOfBorg | juliank, yep, I happen to use it on Ubuntu, because all my packages are in sync, so I don't care about it being a Debian tool, but meh, you are right | 08:07 |
| juliank | I could update the branch name in Vcs-Git for apt when doing stable releases, like I do debian/gbp.conf | 08:08 |
| juliank | but I never bothered | 08:08 |
| LocutusOfBorg | infinity, wrt apparmor you were right, that warning was from the previous upload, so yes you are right | 08:09 |
| LocutusOfBorg | so any idea for this kopanocore upload? | 08:09 |
| infinity | LocutusOfBorg: I haven't looked at the issue(s), just noted that removing that comma was wrong. :P | 08:10 |
| infinity | LocutusOfBorg: Maybe I can poke later, after respin o'clock. | 08:10 |
| LocutusOfBorg | http://launchpadlibrarian.net/419476735/kopanocore_8.7.0-2ubuntu1_8.7.0-2ubuntu2.diff.gz | 08:10 |
| LocutusOfBorg | maybe the first version of my upload in the queue was better... not sure if DebOMatic is enough to trigger this issue | 08:10 |
| -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] | 08:11 | |
| juliank | So | 08:13 |
| juliank | I don't really feel like it makes sense for packages to include files needed by apport implementation details in their apparmor profile | 08:13 |
| juliank | Maybe we should move the files the python hook needs like cputable into the python abstractions | 08:14 |
| juliank | because this does not affect only kopanocore - any crashing python app with a apparmor profile will fail to run the apport crash handler | 08:16 |
| juliank | LocutusOfBorg: ^ | 08:16 |
| LocutusOfBorg | juliank, so you can fix it? | 08:18 |
| LocutusOfBorg | and yes I agree that a general problem needs a general solution | 08:19 |
| juliank | I'm not entirely sure what we need | 08:20 |
| juliank | like we do know we need cputable | 08:20 |
| juliank | but we'll probably also need read access to /var/lib/dpkg/status and /var/lib/apt/lists, and configuration files from apt | 08:21 |
| sil2100 | jibel: morning o/ | 08:21 |
| sil2100 | jibel: did you notice LP: #1824905 during your testing so far? | 08:21 |
| ubot5` | Launchpad bug 1824905 in ubiquity (Ubuntu) "Long pause when selecting 3rd party drivers during install" [Undecided,Confirmed] https://launchpad.net/bugs/1824905 | 08:21 |
| juliank | LocutusOfBorg: FWIW, I don't think it's a huge issue, and I'd focus on finding out why kopanocore fails rather than making the apport hook work | 08:22 |
| sil2100 | jibel: I wonder if that's reproducible only on specific hardware or maybe happens everytime | 08:22 |
| * sil2100 downloads an iso | 08:22 | |
| juliank | It's unclear to me that just making the apport hook work (adding the file it needs) is the right approach | 08:22 |
| juliank | because under normal operation, it will not run, and you give the code access to files it does not _really_ need | 08:23 |
| jibel | sil2100, I commented on the bug report | 08:26 |
| jibel | sil2100, it's when ubuntu-drivers runs | 08:26 |
| juliank | So I think we should leave that up to security team | 08:26 |
| jibel | and now it runs every time | 08:26 |
| juliank | I'll report a launchpad bug for that | 08:26 |
| jibel | sil2100, because we want to install free drivers too for example when running on vmware | 08:26 |
| jibel | sil2100, I think the fix is to add some feedback | 08:27 |
| juliank | LocutusOfBorg: reported https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824961 | 08:29 |
| ubot5` | Ubuntu bug 1824961 in apparmor (Ubuntu) "Blocks apport python hook from working" [Undecided,New] | 08:29 |
| sil2100 | jibel: ah, hm, ok! Thanks | 08:30 |
| sil2100 | jibel: anyway, since it's doing what it's supposed to, not a blocker - carry on! | 08:32 |
| sil2100 | ;) | 08:32 |
| xnox | infinity, Laney - i am staying at home today, probably like until 2pm at least, because deliveries =( | 08:36 |
| juliank | ugh deliveries | 08:37 |
| * juliank has one tomorrow, already sad | 08:37 | |
| sil2100 | xnox: aww | 08:43 |
| LocutusOfBorg | juliank, what if I say "it doesn't fail on my machine?" | 08:50 |
| xnox | infinity, https://code.launchpad.net/~xnox/ubuntu-cdimage/suru-fold-fix-offset-horizon/+merge/366092 better cdimage horizon (from the web team email) | 08:50 |
| juliank | LocutusOfBorg: I don't see how that's relevant. There is an issue mapping the python .so file in the test case; that causes the apport hook to be loaded and fail, but it's not the apport failure causing the failure | 08:51 |
| LocutusOfBorg | I think I got the issue | 08:51 |
| LocutusOfBorg | infinity, ^^ looks like do ko updated the wrong apparmor profile in his patch | 08:54 |
| -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) | 08:54 | |
| * Laney pats xnox | 08:57 | |
| juliank | LocutusOfBorg: hmm, does the profile not include <abstractions/python> | 08:58 |
| juliank | I mean, that's why it exists | 08:58 |
| juliank | it does contain | 08:58 |
| juliank | /usr/lib{,32,64}/python3.[0-9]/lib-dynload/*.so mr, | 08:58 |
| LocutusOfBorg | it does include yes | 08:58 |
| juliank | but then it should just work | 08:59 |
| LocutusOfBorg | you right | 09:00 |
| LocutusOfBorg | I got it | 09:00 |
| juliank | should I rerun that and ssh into it afterwards to see the dmesg? | 09:00 |
| LocutusOfBorg | apparmor issue | 09:00 |
| LocutusOfBorg | mmm no | 09:00 |
| -queuebot:#ubuntu-release- Unapproved: rejected mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1] | 09:01 | |
| infinity | LocutusOfBorg: On my local machine, I got an entirely different failure when running it. Something to do with python3-magic. :P | 09:06 |
| infinity | LocutusOfBorg: Are you testing any of these uploads, or just stabbing wildly in the dark? | 09:08 |
| LocutusOfBorg | on my ppa | 09:09 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages | 09:09 |
| LocutusOfBorg | but I'm having troubles running tests... | 09:09 |
| LocutusOfBorg | for some reasons this link doesn't work https://autopkgtest.ubuntu.com/request.cgi?release=disco&arch=amd64&package=kopanocore&ppa=costamagnagianfranco/locutusofborg-ppa&trigger=kopanocore/8.7.0-2ubuntu4 | 09:09 |
| LocutusOfBorg | is autopkgtestsuite having a sad day? | 09:10 |
| infinity | Maybe | 09:11 |
| LocutusOfBorg | if I put a wrong ubuntu3 version on the above link it answers "that version is not published in your ppa" | 09:11 |
| LocutusOfBorg | and meh, my link should be good | 09:11 |
| juliank | Again, if needed I can retrigger the autopkgtest and then ssh into it to debug why it failed | 09:14 |
| LocutusOfBorg | yes please :) | 09:14 |
| juliank | because so far, the fix attempts do not seem to make much sense | 09:14 |
| LocutusOfBorg | none of them, even the ubuntu1 version... | 09:15 |
| infinity | Indeed, I think doko's "fix" was misguided, but yours have been following down the same path so far. :) | 09:16 |
| infinity | Can you not reproduce locally and iterate? | 09:16 |
| Laney | LocutusOfBorg: should be fixed | 09:16 |
| LocutusOfBorg | I'm not able to... | 09:16 |
| Laney | please try, I didn't want to click your link for you | 09:17 |
| LocutusOfBorg | it worked | 09:17 |
| infinity | ^-- He means request.cgi | 09:17 |
| juliank | I'm running the test manually now with --shell-fail | 09:17 |
| LocutusOfBorg | thanks Laney I updated #launchpad to tell that :) | 09:17 |
| Laney | Dunno why, but rabbitmq had fallen over with no apparent output | 09:18 |
| juliank | I don't feel like it does anything, but I might be wrong | 09:20 |
| LocutusOfBorg | is "sudo autopkgtest-build-lxc ubuntu disco" still the correct command to run? | 09:20 |
| juliank | don't you want to use lxd? | 09:21 |
| juliank | or a VM? | 09:21 |
| LocutusOfBorg | "autopkgtest-build-lxd images:ubuntu/disco/amd64" | 09:21 |
| LocutusOfBorg | is this still the correct command to run? | 09:21 |
| LocutusOfBorg | :) | 09:21 |
| LocutusOfBorg | juliank, if you have a link to the docs I'm happy to follow them, the commands I used in the past (artful) don't work anymore | 09:22 |
| juliank | I think ubuntu-daily:disco is nicer? | 09:22 |
| juliank | But the infra certainly uses the VMs | 09:22 |
| juliank | that is, autopkgtest-buildvm-ubuntu-cloud | 09:22 |
| -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.21] | 09:23 | |
| LocutusOfBorg | juliank, so just a "sudo autopkgtest-buildvm-ubuntu-cloud"? | 09:23 |
| LocutusOfBorg | and then, how I run a local test on that package? | 09:23 |
| juliank | -r disco, probably | 09:24 |
| juliank | it generates an .img file | 09:24 |
| rbalint | LocutusOfBorg, -- qemu ~/.img/autopkgtest-disco-amd64.img | 09:24 |
| juliank | you then do autopkgtest <dsc/package name> -- qemu <img file> | 09:24 |
| * Laney is a bit concerned that LocutusOfBorg is only right now learning this | 09:25 | |
| LocutusOfBorg | Laney, it didn't work and I started using the Ubuntu infra for this, and usually an sbuild/pbuilder chroot works just nicely, with manual test triggering | 09:25 |
| rbalint | Laney, our infra works so well you don't need to know how to run tests locally ;-) | 09:25 |
| LocutusOfBorg | I usually look at the debian/tests content, and run it manually | 09:25 |
| Laney | You could say that for test builds too | 09:25 |
| Laney | but I assume it's considered best practice for people to do those... | 09:26 |
| LocutusOfBorg | btw usually failures are not on amd64, so I have to know anyway how to run them on the infrastructure | 09:26 |
| LocutusOfBorg | Laney, trust me, I failed to find documentation for that... I'm sure there is, but I can't find it | 09:26 |
| LocutusOfBorg | https://manpages.debian.org/testing/autopkgtest/autopkgtest-buildvm-ubuntu-cloud.1.en.html | 09:26 |
| LocutusOfBorg | this is the best page I found so far, based on what you told me before | 09:26 |
| juliank | test is running now | 09:28 |
| juliank | and it worked fine | 09:28 |
| juliank | LocutusOfBorg: Looking at the test, this was from over a month ago, and all tests since then have passed | 09:28 |
| rbalint | LocutusOfBorg, http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test is a good place to start imo | 09:28 |
| LocutusOfBorg | rbalint, sad that google doesn't return that page... | 09:29 |
| LocutusOfBorg | I googled "ubuntu autopkgtest wiki" and the results don't help | 09:29 |
| juliank | hmm, got kopano 8.7.0-1 | 09:29 |
| LocutusOfBorg | https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Local_deployment | 09:30 |
| LocutusOfBorg | this is what is returned | 09:30 |
| * juliank used wrong commandline | 09:30 | |
| juliank | let's try again | 09:31 |
| juliank | from this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190304_165158_f8fa9@/log.gz | 09:31 |
| rbalint | LocutusOfBorg, google knows me :-) i also looked for "autopkgtest local reproduce" | 09:32 |
| -queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (cosmic-proposed) [2.4.46+dfsg-5ubuntu1.2] | 09:37 | |
| juliank | test's about to run | 09:37 |
| juliank | AttributeError: /usr/bin/python3: undefined symbol: magic_open | 09:38 |
| juliank | is the error now | 09:38 |
| juliank | also seeing a | 09:38 |
| juliank | [ 42.630778] audit: type=1400 audit(1555407497.911:45): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/sbin/ldconfig" pid=2746 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 09:38 |
| juliank | and [ 42.629021] audit: type=1400 audit(1555407497.911:42): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/bin/x86_64-linux-gnu-ld.bfd" pid=2745 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 09:39 |
| juliank | setting the profile to complain makes it work | 09:40 |
| infinity | juliank: Yeah, the magic_open failure is what I got locally too. | 09:40 |
| juliank | So I guess it needs | 09:41 |
| juliank | /usr/sbin/ldconfig x, | 09:41 |
| juliank | /usr/bin/x86_64-linux-gnu-ld.bfd x, | 09:41 |
| juliank | with some proper flags | 09:41 |
| juliank | but not entirely sure why | 09:41 |
| infinity | Why is it running ldconfig? And why on earth is it running ld? | 09:42 |
| juliank | [ 42.579760] audit: type=1400 audit(1555407497.859:38): apparmor="DENIED" operation="open" profile="/usr/sbin/kopano-search" name="/usr/sbin/" pid=2743 comm="kopano-search" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 09:42 |
| juliank | infinity: that's a good question | 09:42 |
| infinity | [119697.987051] audit: type=1400 audit(1555405334.972:218): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/kopano-search" name="/usr/lib/python3/dist-packages/magic/__pycache__/" pid=15645 comm="kopano-search" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 | 09:42 |
| infinity | Oh python, you special. | 09:42 |
| infinity | I also see it attempting to run GCC in my ringbuffer. | 09:43 |
| juliank | I did not see that | 09:43 |
| infinity | [119698.000187] audit: type=1400 audit(1555405334.985:222): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/bin/x86_64-linux-gnu-gcc-8" pid=15647 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 | 09:43 |
| juliank | nice | 09:43 |
| juliank | some ctypes module? | 09:44 |
| juliank | or something like that | 09:44 |
| juliank | idk how that works | 09:44 |
| infinity | Not sure I see the value in attempting to make this migrate. | 09:46 |
| infinity | Also puzzled that -1 still works and -2 is a miserable failure. | 09:47 |
| juliank | But yes, "python -c "import magic"" definitely executes ldconfig | 09:47 |
| juliank | [pid 27144] execve("/sbin/ldconfig", ["/sbin/ldconfig", "-p"], 0x7f107a741ab0 /* 2 vars */) = 0 | 09:47 |
| juliank | magic! | 09:47 |
| juliank | If I make ldconfig fail, it fails | 09:48 |
| juliank | it then falls back to gcc and ld | 09:48 |
| juliank | so all we need in the profile is to allow ldconfig, really | 09:48 |
| LocutusOfBorg | why on earth is -1 happy? | 09:48 |
| LocutusOfBorg | oh got it | 09:49 |
| juliank | profile broken -> ignored | 09:49 |
| willcooke | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824103 | 09:50 |
| ubot5` | Ubuntu bug 1824103 in linux (Ubuntu) "aplay record file failed always." [Critical,Incomplete] | 09:50 |
| willcooke | infinity, ^ | 09:50 |
| juliank | LocutusOfBorg: should try reproducing this in Debian with AppArmor and then checking that it fails there and report an important (RC?) bug | 09:50 |
| juliank | infinity: So the profile in -1 is not applied due to missing comma, and it thus works; and now the profile is applied, and it fails to execute ldconfig | 09:51 |
| juliank | which means that -1 is less safe than -2 :D | 09:51 |
| juliank | I wonder if adding ldconfig Ix would be OK | 09:52 |
| juliank | I tried adding it, but I had no job control, and then pressed Ctrl+C, and it ended my shell... | 09:52 |
| infinity | juliank: Ahh. So updating -2 to warn would not be a regression over -1. :P | 09:53 |
| juliank | The fix is to set it to complain, run kopano-search --help | 09:55 |
| juliank | then run aa-logprof to update the profile | 09:55 |
| juliank | and then cleanup formatting again :D | 09:55 |
| juliank | /sbin/ldconfig Pix, | 09:56 |
| juliank | is what doko added to the profile | 09:56 |
| juliank | ah and that fails because usr is merged? | 09:57 |
| juliank | it needs to be {,/usr}/sbin/ldconfig | 09:57 |
| juliank | or maybe it was there before | 09:58 |
| juliank | anyhow, needs to account for /usr | 09:58 |
| -queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.6 => 2.27.1-6ubuntu3.7] (core) | 09:59 | |
| xnox | juliank, yes. | 10:01 |
| juliank | So, I built a package with that change | 10:02 |
| juliank | I'll run autopkgtest on it, and upload it if it works fine | 10:02 |
| juliank | https://paste.ubuntu.com/p/N784NGD5Yt/ | 10:03 |
| juliank | if only apparmor would follow (some) symlinks when loading the profile | 10:03 |
| xnox | looks good | 10:04 |
| LocutusOfBorg | juliank, please also drop the patch | 10:05 |
| LocutusOfBorg | from doko | 10:05 |
| -queuebot:#ubuntu-release- Unapproved: ruby-concurrent (disco-proposed/universe) [1.0.5-2ubuntu1 => 1.0.5-3] (no packageset) (sync) | 10:07 | |
| -queuebot:#ubuntu-release- Unapproved: ruby-oauth2 (disco-proposed/universe) [1.4.1-1ubuntu1 => 1.4.1-2] (no packageset) (sync) | 10:08 | |
| juliank | LocutusOfBorg: I will, after verifying the change | 10:08 |
| juliank | x86_64-linux-gnu-g++: fatal error: Killed signal terminated program cc1plus | 10:17 |
| juliank | well, that's not what I expected | 10:17 |
| infinity | *snicker* | 10:17 |
| juliank | but let's give it 8 gigs of ram instead of 1 | 10:18 |
| juliank | I gave it 4 cores to compile with | 10:18 |
| juliank | so it ran out of memory I guess | 10:18 |
| juliank | 1 GB RAM for your autopkgtest vm is not a sensible default | 10:19 |
| juliank | 1 GB * CPU core might be | 10:19 |
| juliank | well, if it has to build the package | 10:19 |
| * juliank does have 24 gig of ram, so I don't really care about giving 8 of that to the VM | 10:19 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ruby-concurrent [sync] (disco-proposed) [1.0.5-3] | 10:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ruby-oauth2 [sync] (disco-proposed) [1.4.1-2] | 10:20 | |
| -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] | 10:21 | |
| juliank | 4 cores, 8 threads; 24 gigs of ram | 10:21 |
| infinity | juliank: 2G/thread is my usual go-to for C++. | 10:21 |
| infinity | But 1G/thread is closer to what we do in the DC, I believe. | 10:21 |
| infinity | Not positive now. | 10:21 |
| juliank | if you told me in like 2010 that I'd have that in my laptop in 2019 (or 2018 when I got it), I'd have been totally amazed | 10:22 |
| rbalint | juliank, i'm most impressed my nvme's speed | 10:23 |
| juliank | that's nice too | 10:23 |
| infinity | juliank: My modest desktop has 64G of RAM, and my brother reminded me that the "killer dual socket PPro workstation" we built in 1996 had 64MB. | 10:23 |
| juliank | I don't think I could deal well with multiple machines | 10:24 |
| juliank | hence I'm on a laptop all the time | 10:24 |
| infinity | I live most of my life on laptops, but the desktop is much more comfortable for gaming. | 10:24 |
| juliank | I don't want to know what my first desktop had | 10:25 |
| infinity | And desktop parts are cheap enough that it's not really a big deal building one that's pupose-built just for fun. | 10:25 |
| juliank | I only remember was an athlon | 10:25 |
| infinity | Wow, you're young. | 10:25 |
| infinity | I got my first Athlon 750 free at an AMD preview event in 1999. It was the best thing EVER. | 10:26 |
| infinity | And I was 22. | 10:26 |
| juliank | I think I got it like 2001/2002 with XP | 10:27 |
| juliank | prior to that we only had one family computer | 10:27 |
| juliank | it came with Windows 98 SE | 10:28 |
| infinity | That was also in the dark period when Intel and AMB both briefly thought that cartdiges were a good form-factor for CPUs. | 10:28 |
| infinity | AMD* | 10:28 |
| infinity | Also, cartridges. Typing is hard. | 10:28 |
| juliank | My dad also had a laptop with Windows ME if I'm not mistaken | 10:28 |
| juliank | Oh, before that we had some other thing | 10:28 |
| rbalint | Laney, does autopkgtest not pick up unattended-upgrades ubuntu5 or i'm not patient enough? | 10:29 |
| Laney | I just had to make do with a copy of Turing's thesis. | 10:29 |
| Laney | rbalint: check https://people.canonical.com/~ubuntu-archive/proposed-migration/log/ ? | 10:29 |
| juliank | I don't know if it was an Atari or an Amiga | 10:29 |
| juliank | or something like that | 10:29 |
| juliank | and there was another DOS/Windows < 3.1 machine | 10:30 |
| juliank | I fried that one by turning the switch to 110V on our 230V system | 10:31 |
| -queuebot:#ubuntu-release- Unapproved: redmine (disco-proposed/universe) [4.0.1-1 => 4.0.1-2] (no packageset) (sync) | 10:31 | |
| juliank | tar: ./debian/build/ECtools/archiver/helpers/.libs/StoreHelper.o: Wrote only 8192 of 10240 bytes | 10:31 |
| juliank | hmm, I don't have any lucj | 10:31 |
| juliank | just running out of space trying to build kopanocore | 10:32 |
| juliank | and the other qemu seems stuck too | 10:32 |
| juliank | dh_dwz -O--builddirectory=debian/build | 10:33 |
| juliank | and nothing after that | 10:33 |
| -queuebot:#ubuntu-release- Unapproved: gitaly (disco-proposed/universe) [0.129.0+debian-3 => 1.20.0+debian-1] (no packageset) (sync) | 10:34 | |
| -queuebot:#ubuntu-release- Unapproved: golang-gitaly-proto (disco-proposed/universe) [0.123.0+dfsg-2 => 1.14.0+dfsg-2] (no packageset) (sync) | 10:35 | |
| -queuebot:#ubuntu-release- Unapproved: golang-google-cloud (disco-proposed/universe) [0.9.0-9 => 0.9.0-10] (ubuntu-mate) (sync) | 10:37 | |
| LocutusOfBorg | this should fix some golang packages migration ^^ | 10:37 |
| LocutusOfBorg | damn ubuntu-mate why did you seed it | 10:37 |
| rbalint | Laney, thanks, it says pending - there is a lot pending :-( | 10:38 |
| Laney | Maybe they got fubared when rabbitmq died earlier | 10:38 |
| Laney | lemme see | 10:38 |
| juliank | Building in https://launchpad.net/~juliank/+archive/ubuntu/kopanocore now | 10:41 |
| juliank | I do remember this joystick: https://www.c64-wiki.de/images/a/aa/Competition_pro_blau.jpg | 10:47 |
| juliank | but that does not help figuring out which machine it was back then | 10:48 |
| juliank | must have been mid 90s, and like 5-10 years old | 10:49 |
| juliank | (the machine that is) | 10:49 |
| rbalint | Laney, thanks! | 10:53 |
| Laney | there you go | 10:55 |
| Laney | I skill shared the process to infinity :> | 10:55 |
| juliank | Laney: It worked! | 11:23 |
| juliank | um | 11:23 |
| juliank | LocutusOfBorg: It worked! | 11:23 |
| -queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1 => 8.0.0+git20190314-0ubuntu2] (no packageset) | 11:24 | |
| -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) | 11:25 | |
| juliank | LocutusOfBorg: Uploaded and forwarded to Debian | 11:27 |
| juliank | fwded to debian bug 927215 | 11:29 |
| ubot5` | Debian bug 927215 in kopanocore "kopano-search: AppArmor profile does not account for usrmerge" [Serious,Open] http://bugs.debian.org/927215 | 11:29 |
| === s8321414_ is now known as s8321414 | ||
| -queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.7-0ubuntu1 => 1.1.7.1-0ubuntu1] (ubuntukylin) | 11:39 | |
| === RAOF is now known as Guest94052 | ||
| -queuebot:#ubuntu-release- Unapproved: accepted kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] | 11:58 | |
| -queuebot:#ubuntu-release- Unapproved: accepted spirv-llvm-translator [source] (disco-proposed) [8.0.0+git20190314-0ubuntu2] | 11:58 | |
| infinity | handsome_feng: Your ukui-control-center breaks the indentation of the g_timeout_add() call. Did you want to undo that so it's still readable? | 12:01 |
| -queuebot:#ubuntu-release- Unapproved: accepted gitaly [sync] (disco-proposed) [1.20.0+debian-1] | 12:01 | |
| -queuebot:#ubuntu-release- Unapproved: accepted golang-google-cloud [sync] (disco-proposed) [0.9.0-10] | 12:01 | |
| -queuebot:#ubuntu-release- Unapproved: accepted golang-gitaly-proto [sync] (disco-proposed) [1.14.0+dfsg-2] | 12:01 | |
| -queuebot:#ubuntu-release- Unapproved: accepted redmine [sync] (disco-proposed) [4.0.1-2] | 12:01 | |
| xnox | infinity, may i upload casper? | 12:03 |
| infinity | xnox: Depends why. | 12:03 |
| xnox | infinity, systemd-sysusers fails to start on overlayfs /, because it doesn't like .pwd.lock file resulting in non-quiet & degraded live-session boot | 12:04 |
| xnox | with ugly messages on boot, on e.g. subiquity-live server image | 12:04 |
| infinity | xnox: What's the proposed fix for this? | 12:04 |
| xnox | rm /root/.pwd.lock; touch /root/.pwd.lock; touch /root/etc/passwd; touch /root/etc/passwd- | 12:05 |
| xnox | infinity, i.e. ensure all three are "on the upper layer" | 12:05 |
| xnox | aka safe fs, cause systemd cares | 12:05 |
| handsome_feng | infinity: oh, Sorry, I didn't notice that, can you reject that and I will adjust the format | 12:06 |
| infinity | xnox: Does this start before we create the ubuntu user (cause that should pull passwd up to the top layer) | 12:06 |
| infinity | Done. | 12:06 |
| infinity | handsome_feng: Done. | 12:06 |
| handsome_feng | infinity, Thanks! | 12:06 |
| xnox | we do: chroot /root /usr/lib/user-setup/user-setup-apply > /dev/null | 12:06 |
| xnox | so yeah, the passwd files should be in the upper layer already. let me double check things again, by rebooting with break-bottom again. | 12:07 |
| -queuebot:#ubuntu-release- Unapproved: rejected ukui-control-center [source] (disco-proposed) [1.1.7.1-0ubuntu1] | 12:07 | |
| xnox | systemd-sysusers sees i/o error and ???? in ls -a /etc/.pwd.lock file | 12:07 |
| infinity | xnox: I don't see why it would be seeing I/O errors there... | 12:08 |
| xnox | there are other errors too | 12:08 |
| xnox | infinity, http://people.canonical.com/~xnox/casper-bottom.png | 12:10 |
| xnox | cause like subiquity has no display-manager, and like probably not enough of polkit-1 stuff | 12:10 |
| xnox | cause enodesktop | 12:10 |
| mwhudson | those squashfs errors are faaaiiirly new | 12:11 |
| infinity | So some of that stuff needs [ -d ] and [ -f ] guards? | 12:11 |
| mwhudson | eep need to be asleep | 12:11 |
| xnox | mwhudson, yes, came with like v5 kernel. i do want kernel people to look at it... https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824407 | 12:12 |
| ubot5` | Ubuntu bug 1824407 in linux (Ubuntu) " why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather" [Undecided,Incomplete] | 12:12 |
| xnox | infinity, so .pwd.lock passwd passwd- are all in upper | 12:12 |
| infinity | xnox: Okay, so... What are you proposing fixing? :P | 12:13 |
| xnox | infinity, rm /root/etc/.pwd.lock i think now | 12:14 |
| infinity | ... | 12:14 |
| * xnox digs systemd code | 12:14 | |
| infinity | .pwd.lock is supposed to be there... | 12:15 |
| xnox | infinity, http://people.canonical.com/~xnox/pwd-lock-fail.png | 12:18 |
| xnox | that's how things look when booted. | 12:18 |
| xnox | infinity, i wonder if it is bad that we have .pwd.lock in filesystem.squashfs and our mount is lowerdir=installer.squashfs:filesystem.squashfs with an upper dir on top. | 12:20 |
| xnox | failing like everything. | 12:20 |
| xnox | i wonder if livecd-rootfs should have cleaned up .pwd.lock in filesystem.squashfs | 12:21 |
| xnox | hahhahahhaa | 12:21 |
| xnox | infinity, http://paste.ubuntu.com/p/NsMGVTr66Z/ | 12:22 |
| infinity | I genuinely have no idea what that means. | 12:22 |
| xnox | i wonder, if that's my squashfs errors too! | 12:22 |
| infinity | apw: ^ | 12:22 |
| apw | infinity, i think that error says "you tried to create a file over a directory of the same name and that won't work here" | 12:25 |
| xnox | so rm /root/etc/.pwd.lock definately "fixes" systemd-sysusers. But it feels like a bug in rootfs ontop of multi-lower squashfs | 12:25 |
| apw | infinity, or the other way round | 12:25 |
| xnox | i wonder if it would help if the middle layer would have had a /etc directory or the lock file, or like if the lowest layer didn't have .pwd.lock in it. | 12:26 |
| * xnox tries my fix by editing things from like break=top | 12:27 | |
| infinity | xnox: I assume desktop ISOs don't see this? | 12:27 |
| xnox | it maybe hidden by plymouth, let me check if they boot degraded or not | 12:27 |
| xnox | (possibly multilowerdir issue -> in which case desktop single-layer ubiquity should not be affected) | 12:28 |
| apw | xnox, yeah there is a directory on the lower layer and you are trying to copy-up-and-replace with a file | 12:28 |
| apw | xnox, so it is not clear it should not fail with ENOWAY anyhow | 12:28 |
| xnox | testing $ echo 'rm /root/etc/.pwd.lock' >> 25adduser => works like a charm, uploading casper. | 12:30 |
| xnox | and can figure out what's wrong with our squashfs with apw whilst that is in progress. | 12:31 |
| -queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.7-0ubuntu1 => 1.1.7.1-0ubuntu1] (ubuntukylin) | 12:31 | |
| -queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.5] | 12:34 | |
| -queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.404 => 1.405] (desktop-core, ubuntu-server) | 12:34 | |
| Laney | xnox: tseliot was wanting to upload casper too, please to coordinate | 12:45 |
| * xnox wishes we had an up todate repo for casper. | 12:46 | |
| * xnox nominates casper as a snap! | 12:46 | |
| cjwatson | ... | 12:46 |
| Laney | (rejected, pending such coordination) | 12:48 |
| -queuebot:#ubuntu-release- Unapproved: rejected casper [source] (disco-proposed) [1.405] | 12:48 | |
| -queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (disco-proposed) [1.1.7.1-0ubuntu1] | 12:53 | |
| handsome_feng | Thanks! | 12:55 |
| xnox | tseliot, this is my diff http://launchpadlibrarian.net/419512765/casper_1.404_1.405.diff.gz | 12:57 |
| tseliot | xnox: sure, let me apply that, and re-upload | 13:03 |
| xnox | infinity, Laney - on my way to the office. | 13:06 |
| tseliot | Laney, xnox: uploaded | 13:15 |
| -queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.404 => 1.405] (desktop-core, ubuntu-server) | 13:16 | |
| -queuebot:#ubuntu-release- Unapproved: curl (cosmic-proposed/main) [7.61.0-1ubuntu2.3 => 7.61.0-1ubuntu2.4] (core) | 13:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (disco-proposed) [1.405] | 13:25 | |
| cyphermox | Laney: tseliot: xnox: can we just all agree to use git-ubuntu's snapshot then? | 13:26 |
| cyphermox | (for next uploads) | 13:27 |
| -queuebot:#ubuntu-release- Unapproved: pulseaudio (disco-proposed/main) [1:12.2-2ubuntu1 => 1:12.2-2ubuntu2] (desktop-core, ubuntu-server) | 13:35 | |
| LocutusOfBorg | archive admins, ushare has never appeared in Debian, and its in proposed-only since a while... can we kick it out completely, or is anybody having a look? | 13:35 |
| LocutusOfBorg | (is it still needed?) | 13:36 |
| -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (disco-proposed) [1:12.2-2ubuntu2] | 13:40 | |
| -queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (cosmic-proposed/universe) [1:10.1.29-6ubuntu2 => 1:10.1.38-0ubuntu0.18.10.1] (no packageset) | 13:46 | |
| -queuebot:#ubuntu-release- Unapproved: pulseaudio (disco-proposed/main) [1:12.2-2ubuntu2 => 1:12.2-2ubuntu3] (desktop-core, ubuntu-server) | 13:58 | |
| -queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (disco-proposed) [1:12.2-2ubuntu3] | 14:00 | |
| === Eickmeyer is now known as Eickmeyer___ | ||
| tseliot | cyphermox: I'm all for using git. I always use git when I make changes to packages. I wish casper were hosted somewhere, and that the CVS were mentioned in the debian/control file | 14:25 |
| cyphermox | yeah, that's why I said that one; would just need to be listed in debian/control | 14:26 |
| -queuebot:#ubuntu-release- Unapproved: rejected mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1] | 14:31 | |
| === RAOF is now known as Guest32007 | ||
| rbasak | cyphermox, tseliot: casper is interesting for git-ubuntu, as it's never going to be in Debian and doesn't have an established VCS location | 14:34 |
| rbasak | You could point Vcs-* to git-ubuntu, but then you wouldn't be able to have any pre-upload "holding area" | 14:34 |
| rbasak | (which could be fine) | 14:34 |
| rbasak | xnox also: ^ | 14:35 |
| vorlon | morning | 14:35 |
| rbasak | Or if you want a holding area, that might have to be somewhere else eg. ~ubuntu-core-dev | 14:35 |
| vorlon | infinity, sil2100: anything you need from me today for release? | 14:35 |
| infinity | vorlon: All the testing ever, in about an hour. | 14:35 |
| rbasak | However you could keep that in sync with git-ubuntu's imports if you wished | 14:35 |
| infinity | Give or take. | 14:35 |
| vorlon | heh | 14:36 |
| cyphermox | rbasak: tbh I was just interested in taking the import as a basis; and then keeping the code under ~ubuntu-core-dev. | 14:36 |
| rbasak | cyphermox: that would work | 14:36 |
| cyphermox | infinity: so, spins coming up? | 14:36 |
| vorlon | infinity: so new images currently awaiting respin? what's the critical path on that? | 14:36 |
| rbasak | cyphermox: it might be a little painful if you get a non-VCS upload though. But no more painful than the same for any other package maintained in VCS. | 14:37 |
| infinity | vorlon: casper and pulseaudio are the only triggers in proposed, the rest is migrated. | 14:37 |
| vorlon | ok | 14:37 |
| cyphermox | rbasak: yeah, well, there's only so much we can do | 14:37 |
| rbasak | cyphermox: agreed, though my interest is: what can we do that will work and is better? :-) | 14:38 |
| rbasak | (for git-ubuntu and all packages generally I mean; not just casper) | 14:38 |
| rbasak | Finding best practice, etc. | 14:38 |
| cyphermox | rbasak: ok | 14:39 |
| tseliot | rbasak: I don't remember ever using git-ubuntu, but I'll have a look at the docs. Thanks | 14:39 |
| rbasak | tseliot: np. Sorry the docs are probably awful. It's still very experimental. | 14:40 |
| rbasak | Feel free to ask questions etc. | 14:40 |
| tseliot | rbasak: I found this: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow | 14:40 |
| tseliot | but sure, if I have any questions I will ask :) | 14:41 |
| tobikoch | sil2100: platonical and I are contacts for cloud-image related stuff during and after the upcoming release. | 14:41 |
| platonical | lol beat me to it | 14:41 |
| tobikoch | :P | 14:41 |
| -queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset) | 14:43 | |
| LocutusOfBorg | ^^ please accept the second version, I added in changelog the reference to the Debian RC bug I just opened | 14:46 |
| -queuebot:#ubuntu-release- Unapproved: golang-gopkg-sourcemap.v1 (disco-proposed/universe) [1.0.5-1 => 1.0.5-1ubuntu1] (no packageset) | 14:46 | |
| vorlon | kenvandine: hi, so, I just checked the latest disco desktop image build and I see that it's pulling in both core and core18 snaps; are we not fully transitioned to core18? | 14:48 |
| sil2100 | tobikoch, platonical: thanks! | 14:48 |
| kenvandine | vorlon: we are not | 14:48 |
| vorlon | well, that certainly won't help the bandwidth question any | 14:49 |
| kenvandine | vorlon: well all of our seeded snaps are core18 now | 14:49 |
| vorlon | kenvandine: what was left untransitioned? | 14:49 |
| platonical | sil2100, is there an ISO respin happening now, and do you know what triggered it? | 14:49 |
| kenvandine | but we didn't want to drop the core snap late in the cycle | 14:49 |
| kenvandine | which would require snapd + core18 snaps | 14:50 |
| kenvandine | that hadn't been tested yet | 14:50 |
| vorlon | kenvandine: what is pulling in core snap? | 14:50 |
| kenvandine | so we're still use snapd from the core snap | 14:50 |
| kenvandine | core is seeded to get snapd | 14:50 |
| vorlon | kenvandine: we HAVE landed changes in livecd-rootfs to pull in core18 and snapd snaps | 14:50 |
| vorlon | uh | 14:50 |
| vorlon | unseed that | 14:51 |
| kenvandine | oh | 14:51 |
| kenvandine | well maybe we aren't then :) | 14:51 |
| kenvandine | it was livecd-rootfs :) | 14:51 |
| vorlon | oh | 14:51 |
| kenvandine | great then | 14:51 |
| vorlon | right, we fixed that but something else is still pulling core in as a dep | 14:51 |
| vorlon | afaics | 14:51 |
| -queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (cosmic-proposed/universe) [1:10.1.29-6ubuntu2 => 1:10.1.38-0ubuntu0.18.10.1] (no packageset) | 14:51 | |
| kenvandine | cool, so that should be working then | 14:51 |
| vorlon | yeah, I pushed on the team to get all of that sorted out in livecd-rootfs for 19.04 | 14:51 |
| vorlon | /so that/ we wouldn't pull in two core snaps | 14:52 |
| vorlon | but the log shows we're still pulling in core, which means it's a dep of something | 14:52 |
| kenvandine | vorlon, willcooke: do we want to try to get gnome-3-28-1804 refreshed with the security fix for libxslt before you spin images? | 14:52 |
| vorlon | infinity: ^^ | 14:52 |
| vorlon | kenvandine: (I'm not in London, I was just proxying based on earlier discussion here in channel) | 14:52 |
| kenvandine | maybe gtk-common-themes? | 14:52 |
| kenvandine | that doesn't have base: core18 | 14:53 |
| vorlon | kenvandine: yes, likely | 14:53 |
| kenvandine | it doesn't stage packages and is arch all | 14:53 |
| vorlon | is that all data? | 14:53 |
| kenvandine | yeah | 14:53 |
| vorlon | could we make it base: none? | 14:53 |
| vorlon | (quickly?) | 14:53 |
| kenvandine | i can do a quick test of that | 14:53 |
| sil2100 | base: none would still make it pull in core I guess | 14:54 |
| vorlon | sil2100: why? does livecd-rootfs treat none specially? | 14:54 |
| vorlon | I thought base: none really means none :) | 14:54 |
| sil2100 | Ah, wait, maybe not, I know that snap-tool treats the lack of base: as core, but maybe base: none will do the trick? | 14:54 |
| sil2100 | nvm me then ;) | 14:54 |
| vorlon | right, or maybe it'll break the build because snap-tool /doesn't/ know how to handle base: none ;) | 14:55 |
| * sil2100 tries to check that quickly | 14:55 | |
| sil2100 | I guess snap-tool will be fine | 14:56 |
| vorlon | sil2100, kenvandine: ok I just checked snap-tool in livecd-rootfs, and I don't see that it knows how to handle base: none | 14:56 |
| vorlon | it will look for it as the name of a snap to preseed | 14:56 |
| kenvandine | :/ | 14:56 |
| vorlon | which AIUI is incorrect | 14:56 |
| sil2100 | Can't we switch it to base: core18 in this case? Since we anyway pull in core18 now from other snaps | 14:56 |
| vorlon | that would probably be better yeah | 14:57 |
| sil2100 | I wonder if that would be acceptable for the snap though | 14:57 |
| vorlon | and then we can make livecd-rootfs know about base: none at leisure | 14:57 |
| kenvandine | my only concern is other snaps that aren't using core18 but are using gtk-common-themes will now suddenly pull in core18 | 14:57 |
| kenvandine | but that number should be low | 14:57 |
| willcooke | kenvandine, do we have any data on that? | 14:58 |
| kenvandine | yeah | 14:58 |
| sil2100 | I can quickly prepare a fix for snap-tool, but I think it's a bit lateish for fast-tracking a livecd-rootfs | 14:58 |
| kenvandine | i can look at stats on gtk-common-themes to see which distros have installed devices | 14:58 |
| kenvandine | anything bionic and newer will have core18 already installed | 14:59 |
| vorlon | sil2100: I'm available to review (or maybe tobikoch is better) | 14:59 |
| vorlon | I think we should at least start down that path even if we can't get all the way for 19.04 | 14:59 |
| kenvandine | agreed | 15:00 |
| -queuebot:#ubuntu-release- Unapproved: libxslt (disco-proposed/main) [1.1.32-2 => 1.1.32-2ubuntu0.1] (desktop-core, ubuntu-server) (sync) | 15:00 | |
| willcooke | kenvandine, ^ libxslt | 15:01 |
| willcooke | so I think that yes, we should try and get the platform snap updated too. Is it a big job? | 15:02 |
| willcooke | kenvandine, i_nfinity said that time is short for the platform snap | 15:04 |
| kenvandine | vorlon: the numbers are low for other distros, won't be a big impact | 15:06 |
| kenvandine | i can kick off a build adding core18 | 15:06 |
| -queuebot:#ubuntu-release- Unapproved: accepted libxslt [sync] (disco-proposed) [1.1.32-2ubuntu0.1] | 15:06 | |
| sil2100 | kenvandine, vorlon: do we have some snap in the snapstore that has base: none already? | 15:10 |
| tobikoch | sil2100, vorlon: instead of hacking snap-tool, I would suggest special-casing "none" in _snap_preseed (live-build/functions l. 494). | 15:10 |
| sil2100 | tobikoch: well, depending if this is a 'hack' or 'per-design' | 15:10 |
| sil2100 | ;) | 15:11 |
| sil2100 | tobikoch: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/366124 | 15:11 |
| sil2100 | tobikoch: but yeah... | 15:11 |
| sil2100 | vorlon: is base: none a formal thing? I tried finding it somewhere in the docs, but couldn't | 15:11 |
| tobikoch | sil2100: i'd say it is probably not | 15:12 |
| tobikoch | sil2100: I think the change in that MP is not what we want. If base is reported as "" by snap-tool then livecd-rootfs assumes base core and pulls in core. | 15:13 |
| tobikoch | So we really want the hack in livecd-rootfs and maybe get this formally specified later. | 15:14 |
| sil2100 | tobikoch: oh, ok, since I thought that the way it's done is that when base is None (so not defined), then *snap-tool* defaults to core | 15:15 |
| sil2100 | And that livecd-rootfs doesn't have to do anythiing when seeing base: "", because if base is "" it should not pull in anything (as that means the snap is a base snap) | 15:15 |
| tobikoch | sil2100: that logic isn't in snap-tool. snap-tool is only used to ask the API for info about the snap including its base. The API will report "" for snaps that have base core. So livecd-rootfs treates that as having to pull in core. If you modify the snap that causes core to be pulled in to explicitly specify its base as "none", then that needs to be treated in _snap_preseed. | 15:16 |
| sil2100 | tobikoch: wait, what about snap-tool line 207 then? | 15:17 |
| sil2100 | tobikoch: that line basically does self.is_core_snap() and sets base to "", core snaps have no base at all through the API from what I see? | 15:18 |
| willcooke | kenvandine, re: snap(s) needing the new xslt - what can I do to help test? | 15:18 |
| sil2100 | tobikoch: and the next line sets "core" as the base of snaps that do not provide base at all | 15:19 |
| tobikoch | sil2100: slow down a sec | 15:19 |
| kenvandine | willcooke: refresh gnome-3-28-1804 from candidate and run the seeded snaps | 15:19 |
| kenvandine | make sure they behave | 15:19 |
| willcooke | doing.... | 15:19 |
| kenvandine | i'm testing on bionic now | 15:19 |
| kenvandine | gtk-common-themes with base:core18 is building and should be in candidate soon | 15:20 |
| kenvandine | we can verify that's sane soon | 15:20 |
| kenvandine | vorlon ^^ | 15:21 |
| tobikoch | sil2100: take a snap that has base "core" and ask the API which base it has, then you will get back *no result* for that attribute. So snap_data["snap"]["base"] would not be set and snap_data["snap"].get("base") would return the special None object not the string "None". So all this line does is to populate that attribute with an empty string. | 15:21 |
| willcooke | 🌽 | 15:22 |
| tobikoch | sil2100: but if gtk-common-themes now has core18 and that works as expected, I'd shelve the hack until this can be discussed with the snap people later. My two cents. | 15:22 |
| cjwatson | sil2100: https://bugs.launchpad.net/launchpad/+bug/1819196 has links | 15:25 |
| ubot5` | Ubuntu bug 1819196 in Launchpad itself "support for base: none and build-base" [High,Triaged] | 15:25 |
| cjwatson | may not completely help but ... | 15:25 |
| tobikoch | cjwatson: how is "none" reported by the API? | 15:26 |
| cjwatson | What API? | 15:26 |
| tobikoch | cjwatson: /v2/snaps/refresh when I ask for the "base" field to be included. | 15:27 |
| cjwatson | I would assume it passes it through literally because why would we change it ... | 15:27 |
| willcooke | kenvandine, calc chars system monitor and snap store snap all tested, seems fine to me | 15:28 |
| vorlon | cjwatson: ah, that blog of sergiusens's discusses it being supported in "upcoming releases" of snapcraft/snapd, do you know if that's landed? | 15:30 |
| cjwatson | vorlon: Don't know, sorry | 15:30 |
| kenvandine | willcooke: great, all good on bionic too | 15:30 |
| willcooke | kenvandine, oh, that was Bionic too | 15:30 |
| vorlon | (no harm in livecd-rootfs implementing that preemptively anyway) | 15:30 |
| willcooke | stand by | 15:30 |
| kenvandine | willcooke: oh, you tested both? | 15:30 |
| cjwatson | tobikoch: Right, as far as I can tell the store just passes that straight through unmodified | 15:31 |
| cjwatson | "none" as a string, not "None" or None | 15:31 |
| cjwatson | (or null) | 15:31 |
| tobikoch | cjwatson: actually, I get Python None, not "none" (e.g. snapd see https://pastebin.canonical.com/p/9K8jnKP27v/), but I also get that for snaps that have implicit base "core" (e.g. lpshipit see https://pastebin.canonical.com/p/CKnTZFCTVJ/). | 15:31 |
| cjwatson | core isn't a real base and should result in null | 15:31 |
| cjwatson | do not confuse the implicit core base with base: none | 15:32 |
| cjwatson | snapd does not have base: none | 15:32 |
| cjwatson | it has no base | 15:33 |
| cjwatson | not the same thing | 15:33 |
| cjwatson | (I didn't come up with this, just the messenger) | 15:33 |
| tobikoch | cjwatson: hehe, ok | 15:33 |
| tobikoch | cjwatson: know of a snap using "none" explicitly? | 15:34 |
| cjwatson | I'm not sure there are any yet | 15:34 |
| willcooke | kenvandine, same tests run on B & D. All fine | 15:34 |
| cjwatson | let me run a quick query | 15:34 |
| cjwatson | snaprevs_production_standby=> SELECT DISTINCT snap_id FROM snaprevision WHERE base = 'none'; | 15:35 |
| cjwatson | snap_id | 15:35 |
| cjwatson | --------- | 15:35 |
| cjwatson | (0 rows) | 15:35 |
| kenvandine | willcooke: ok, now do the same thing with gtk-common-themes from candidate :) | 15:35 |
| tobikoch | cjwatson: thanks :) | 15:35 |
| cjwatson | np. it's still in development I think so not too surprised | 15:35 |
| cjwatson | none on staging either | 15:36 |
| infinity | Or is it None on staging? | 15:36 |
| * infinity ducks. | 15:36 | |
| sil2100 | "none", none or None? | 15:37 |
| tobikoch | vorlon, sil2100: ^ so if a snap had base set to "none" explicitly, snap-tool should print base: none and we should special case livecd-rootfs to not do anything when it sees "none". So livecd-rootfs/live-build/functions line 494. Printing the empty string instead will make livecd-rootfs assume implicit "core". | 15:38 |
| tobikoch | sil2100: 'none' see cjwatson's sql above. | 15:39 |
| willcooke | kenvandine, tested - all good | 15:43 |
| kenvandine | willcooke: thanks | 15:44 |
| kenvandine | all good for me too | 15:44 |
| willcooke | kenvandine, so will you promote to stable? Should we ping snap store first? | 15:45 |
| kenvandine | willcooke: i've been talking to snapstore folks | 15:45 |
| kenvandine | roadmr just finished generating deltas | 15:45 |
| willcooke | kenvandine, super thanks! | 15:45 |
| kenvandine | almost ready to promote it | 15:46 |
| sil2100 | tobikoch: no, so I disagree here - an empty string will not make livecd-rootfs assume implicit core from what I see, the empty string will only cause the check in _snap_post_process() to happen but it will result as a no-op as the snap name is not core or core18 | 15:47 |
| kenvandine | vorlon: does livecd-rootfs only seed snapd if the core snap isn't seeded? | 15:47 |
| sil2100 | tobikoch: but anyway, since this is not on fire right now, let's take this discussion to the MP | 15:47 |
| vorlon | kenvandine: yes | 15:47 |
| kenvandine | cool | 15:47 |
| kenvandine | vorlon: i have gtk-common-themes ready with core18 | 15:47 |
| kenvandine | shall i promote it and see what the isos look like? | 15:48 |
| tobikoch | sil2100: yeah, you're right! I'm getting it all mixed up myself. The empty string would also do the right thing. | 15:48 |
| sil2100 | tobikoch: I'm not saying I'm against moving the change from snap-tool to livecd-rootfs functions, I just feel it's more of a preference thing - anyway, let's discuss it further there ;) | 15:48 |
| sil2100 | tobikoch: we can bikeshed a bit more there about it | 15:48 |
| tobikoch | ok, I'll add a comment | 15:48 |
| sil2100 | kenvandine: yes please o/ (hoping that won't break everything) | 15:49 |
| vorlon | kenvandine: if you're satisfied that this doesn't have adverse impact on snaps outside of the desktop that depend on gtk-common-themes | 15:49 |
| kenvandine | sil2100, vorlon: done | 15:49 |
| kenvandine | Wimpress: ^^ gtk-common-themes is now core18, should make you happy too :) | 15:50 |
| sil2100 | kenvandine: thanks! | 16:02 |
| kenvandine | sil2100: np, i'm anxiously awaiting isos to test :) | 16:04 |
| Laney | don't hold your breath :P | 16:05 |
| infinity | Go on. Hold your breath. I dare you. | 16:06 |
| -queuebot:#ubuntu-release- Unapproved: gedit (disco-proposed/main) [3.32.0-2 => 3.32.0-3] (ubuntu-desktop) | 16:28 | |
| sil2100 | kenvandine: hey, ummm | 16:32 |
| sil2100 | kenvandine: so | 16:32 |
| sil2100 | kenvandine: is it possible that you could revert your gtk-common-themes change ;p ? | 16:33 |
| sil2100 | kenvandine: we just learned from the snapd team that we *need* to have core right now *anyway* | 16:33 |
| sil2100 | kenvandine: since even if none of the snaps use core as its base, we've been told we *anyway* need the core snap because of some bugs in the snapd snap | 16:34 |
| sil2100 | ... | 16:34 |
| sil2100 | ;) | 16:34 |
| sil2100 | willcooke: ^ | 16:34 |
| sil2100 | infinity: ^ | 16:34 |
| sil2100 | grrrr | 16:34 |
| willcooke | do we need to revert though? Can we seed it? | 16:35 |
| sil2100 | willcooke: we could seed it, but vorlon said he'd prefer to revert the change instead | 16:36 |
| infinity | Why do we need core? | 16:37 |
| infinity | Gross. | 16:37 |
| infinity | Yo dawg, we heard you like root filesystems. | 16:37 |
| sil2100 | infinity: yeah, we need to have 2 base systems shipped on disco now, yay | 16:37 |
| infinity | I kinda feel like if we need core anyway, we shouldn't have anything using 18 yet. :/ | 16:37 |
| infinity | Oh well. | 16:37 |
| sil2100 | Moar..! | 16:37 |
| -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1016.16~18.04.1] (kernel) | 16:37 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1016.16] (kernel) | 16:37 | |
| sil2100 | infinity: yeah, it seems to have been a miscommunication somewhere | 16:38 |
| sil2100 | A big one | 16:38 |
| -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1016.16~18.04.1] | 16:38 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1016.16] | 16:38 | |
| vorlon | infinity, willcooke: yes, it seems that there are bugs that prevent snapd+core18 from being sufficient on a classic desktop system, so we still have to pull in core for now. I think reverting gtk-common-themes is the best option for now | 16:44 |
| infinity | vorlon: Right, and I think that also means we don't want the snapd snap yet. | 16:45 |
| vorlon | and core 19.04 the snapd team is supposed to remove the need for core snap | 16:45 |
| infinity | Since we'll have snapd from core. | 16:45 |
| sil2100 | vorlon: per infinity's question here, I guess it'd be good to actually remove the logic that pulls in snapd | 16:45 |
| vorlon | infinity: right, and I believe tobikoch's code is smart enough to figure this out | 16:45 |
| sil2100 | Yeah | 16:45 |
| infinity | Is it? Kay. | 16:45 |
| infinity | If core is there, it won't snapd? | 16:45 |
| vorlon | the log shows snapd snap being seeded to go along with core18, but it later un-seeds it again once core is pulled in | 16:45 |
| -queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.32.1-1ubuntu2 => 3.32.1-1ubuntu3] (ubuntu-desktop, ubuntugnome) | 16:45 | |
| sil2100 | Ah, good! | 16:45 |
| sil2100 | phew | 16:46 |
| vorlon | you should check the iso contents to confirm | 16:46 |
| willcooke | kenvandine will be back in about 20 mins. | 16:47 |
| -queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (disco-proposed) [3.32.1-1ubuntu3] | 16:49 | |
| platonical | vorlon, sil2100, I'm about to respin Disco bc I need to pull in a lxd fix. Is there anything else I should be waiting for? | 16:59 |
| sil2100 | platonical: so there's still a few packages that we're waiting to migrate before re-spinning | 17:01 |
| platonical | sil2100, ok, do you know how long you expect that to take? | 17:01 |
| vorlon | sil2100: which packages? casper should be migrated; do cloud images care about pulseaudio? | 17:03 |
| vorlon | seeded-in-ubuntu says no | 17:04 |
| vorlon | wait | 17:04 |
| vorlon | libpulse0 is in ubuntu-server daily | 17:04 |
| vorlon | .. which should only be the apt repo, not the server seed | 17:04 |
| vorlon | so that's ok | 17:04 |
| vorlon | but libxslt is a security fix and is on the server live seed | 17:06 |
| sil2100 | vorlon: we also have libxslt which is seeded in server, but on the other hand I indeed don't know what's up | 17:07 |
| vorlon | ok | 17:07 |
| vorlon | platonical: ^^ sounds like that's the blocker | 17:07 |
| sil2100 | *what's up with that | 17:07 |
| vorlon | is someone poking at asterisk/i386 autopkgtest failure? | 17:07 |
| platonical | vorlon, sil2100, ok thanks. ETA on that? | 17:07 |
| sil2100 | platonical: the tests are running, I'd suppose they won't take much longer, most are finished | 17:08 |
| vorlon | platonical: once the autopkgtest results have finished and are all green on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libxslt , plus ~20minutes | 17:08 |
| vorlon | (sorry, I don't have a good way to estimate completion of autopkgtests at a glance) | 17:08 |
| platonical | ok thanks | 17:08 |
| vorlon | uh libreoffice is in there | 17:09 |
| vorlon | we should probably skip waiting for libreoffice test results :P | 17:09 |
| sil2100 | ugh | 17:11 |
| vorlon | or else make the call to have this as a zero-day security update | 17:11 |
| sil2100 | vorlon: ok, so infinity will skip some tests for it to migrate soonish | 17:16 |
| sil2100 | vorlon: and I just confirmed that on the last image (which had both core18 and core) no snapd snap has been preseeded, so it's working as expected indeed | 17:22 |
| infinity | vorlon: Yeah, I skipped the rest of libxslt tests, it's tested enough. | 17:23 |
| kenvandine | sil2100: done | 17:27 |
| infinity | And I'm going to build images as soon as kenvandine gets his thingee reverted. | 17:27 |
| infinity | sil2100: Oh, was that "done" for the revert? | 17:28 |
| infinity | So, I guess I'm waiting on britney, not Ken. :P | 17:28 |
| vorlon | ok | 17:30 |
| kenvandine | yup :) | 17:32 |
| * infinity waits impatiently for gnome-initial-setup to publish. | 18:34 | |
| infinity | Guess I can start on base and server. | 18:34 |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Final] has been updated (20190416.1) | 18:50 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Final] has been updated (20190416.1) | 19:09 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Final] has been updated (20190416.1) | 19:09 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Final] has been updated (20190416.1) | 19:09 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Final] has been updated (20190416.1) | 19:09 | |
| -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Final] has been updated (20190416) | 19:15 | |
| -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Final] has been updated (20190416) | 19:17 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Final] has been updated (20190416) | 19:18 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Final] has been updated (20190416) | 19:20 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Final] has been updated (20190416) | 19:20 | |
| bdmurray | fossfreedom: Having a link to the errors bucket in bug 1824229 would be helpful so that SRU team members can know what you are talking about. | 19:21 |
| ubot5` | bug 1824229 in budgie-desktop (Ubuntu Cosmic) "[SRU] Cherrypick bug-fixes and usability issues for budgie-desktop" [Medium,In progress] https://launchpad.net/bugs/1824229 | 19:21 |
| fossfreedom | bdmurray, ok | 19:21 |
| -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Final] has been updated (20190416) | 19:22 | |
| -queuebot:#ubuntu-release- Unapproved: libsodium (xenial-updates/universe) [1.0.8-5 => 1.0.8-5] (kubuntu) (sync) | 19:22 | |
| -queuebot:#ubuntu-release- Unapproved: accepted libsodium [sync] (xenial-updates) [1.0.8-5] | 19:24 | |
| -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Final] has been updated (20190416) | 19:26 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been updated (20190416) | 19:41 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Final] has been updated (20190416) | 19:43 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Final] has been updated (20190416) | 19:43 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Final] has been updated (20190416) | 19:43 | |
| Eickmeyer | infinity: I'm assuming we'll be seeing a new RC email soon? | 19:48 |
| * valorie is waiting to link to it | 19:49 | |
| cyphermox | rcj: any idea about maas streamed images, if they're RC? | 19:55 |
| bdmurray | fossfreedom: given that there already is a bug for "Issue 1" in bug 1824229 why didn't you just use that? As an SRU team member its complicated for me to track multiple issues in one bug report. | 20:06 |
| ubot5` | bug 1824229 in budgie-desktop (Ubuntu Cosmic) "[SRU] Cherrypick bug-fixes and usability issues for budgie-desktop" [Medium,In progress] https://launchpad.net/bugs/1824229 | 20:06 |
| bdmurray | fossfreedom: for me to verify that the sru verification was done properly I'm going to have to look through the bug with a mental checklist of all 4 issues and look for verification of each part which is a pain | 20:07 |
| rcj | cyphermox: I'll defer to platonical as he's tracking release | 20:09 |
| vorlon | Eickmeyer, valorie: I don't assume that a respin of RC images results in a new email | 20:09 |
| platonical | rcj, cyphermox, what's RC? | 20:09 |
| Eickmeyer | RC = Release Candidate | 20:10 |
| Eickmeyer | vorlon: Thanks | 20:10 |
| cyphermox | platonical: yeah, I mean, if I deploy disco on a machine from MAAS, am I testing anything useful? | 20:13 |
| cyphermox | in case I can check off some test on the drive-by | 20:13 |
| platonical | cyphermox, there's currently a 20190416.1 disco build in progress, that will probably be better to test than 20190416, as we've pulled in some essential fixes | 20:15 |
| -queuebot:#ubuntu-release- Unapproved: rejected containerd [source] (cosmic-proposed) [1.2.6-0ubuntu1~18.10.1] | 20:15 | |
| -queuebot:#ubuntu-release- Unapproved: rejected containerd [source] (bionic-proposed) [1.2.6-0ubuntu1~18.04.1] | 20:16 | |
| rcj | cyphermox: missing from 20190416 is an apparmor fix needed for lxd | 20:17 |
| cyphermox | ok | 20:17 |
| cyphermox | what I have here appears to be snapshot-20190416-193741 right nw | 20:18 |
| cyphermox | that's probably 16, not 16.1 | 20:18 |
| cyphermox | I guess I answered my own question, this is the right ballpark timestamp to be testing very recent images | 20:19 |
| platonical | cyphermox, I don't follow the snapshot syntax, where are you getting that from? | 20:21 |
| -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Final] has been updated (20190416.2) | 20:24 | |
| cyphermox | platonical: straight from the filesystem on a MAAS rack server; in /var/lib/maas/boot-resources | 20:39 |
| platonical | cyphermox: ah. well I can let you know when 20190416.1 is finished building if you like | 20:41 |
| cyphermox | nah, it's fine, I'll watch what's on disk and in the logs | 20:41 |
| platonical | 👍 | 20:41 |
| cyphermox | it seems to be updating quickly enough | 20:41 |
| fossfreedom | bdmurray, hmm - ok. I can divide each issue into separate issue reports if that helps. | 20:51 |
| bdmurray | fossfreedom: I think it really would but I'm just one member of the team. Its possible somebody could disagree with me but I'd be surprised. :-) | 20:53 |
| fossfreedom | bdmurray, don't really mind. Can you please reject the bionic and cosmic uploads so that I can reupload with the new issue numbers? | 20:54 |
| bdmurray | fossfreedom: thanks, that'll help and sure I'll do the reject. | 20:58 |
| -queuebot:#ubuntu-release- Unapproved: rejected budgie-desktop [source] (cosmic-proposed) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2] | 21:03 | |
| -queuebot:#ubuntu-release- Unapproved: rejected budgie-desktop [source] (bionic-proposed) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2] | 21:04 | |
| -queuebot:#ubuntu-release- Unapproved: budgie-desktop (bionic-proposed/universe) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.1 => 10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2] (personal-fossfreedom, ubuntu-budgie) | 22:04 | |
| -queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.1 => 10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2] (personal-fossfreedom, ubuntu-budgie) | 22:05 | |
| -queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2018i-0ubuntu0.18.04 => 2019a-0ubuntu0.18.04] (core) | 22:12 | |
| -queuebot:#ubuntu-release- Unapproved: tzdata (cosmic-proposed/main) [2018i-0ubuntu0.18.10 => 2019a-0ubuntu0.18.10] (core) | 22:13 | |
| -queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2018i-0ubuntu0.16.04 => 2019a-0ubuntu0.16.04] (core) | 22:19 | |
| -queuebot:#ubuntu-release- Unapproved: tzdata (trusty-proposed/main) [2018i-0ubuntu0.14.04 => 2019a-0ubuntu0.14.04] (core) | 22:24 | |
| === Guest32007 is now known as RAOF | ||
| -queuebot:#ubuntu-release- Unapproved: gnome-software (disco-proposed/main) [3.30.6-2ubuntu3 => 3.30.6-2ubuntu4] (ubuntu-desktop) | 23:19 | |
| -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] has been marked as ready | 23:57 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
