[00:10] -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:12] -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] 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:13] Cause it'll be past NA bedtime by the time all this stuff is happy and moving. [00:16] -queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu569 => 20101020ubuntu570] (core) [00:20] -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:34] -queuebot:#ubuntu-release- Unapproved: thunar (disco-proposed/universe) [1.8.4-1 => 1.8.4-1ubuntu1] (mythbuntu, ubuntustudio, xubuntu) [00:35] infinity: can you go ahead and approve the above thunar upload so it makes it into tomorrow's respin? :) [00:36] Including the (please) I forgot just now [00:37] I'll leave that to vorlon. [00:38] * infinity sleeps for a few hours. [00:38] looking [00:39] infinity, vorlon, much appreciated :) [00:39] bluesabre: rather large patch, and the header says it's 1/3. how sure are you this fixes the issue? [00:39] oh, it's 3 patches serialized in 1 file :P [00:39] 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:40] :) [00:40] bluesabre: so you've already tested this locally and confirmed it fixes? [00:40] 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] ok [00:41] -queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (disco-proposed) [1.8.4-1ubuntu1] [00:41] vorlon: thanks a bunch! [01:15] infinity: about to release the hopefuly final subiquity to stable btw [01:28] -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:31] -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:32] -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:35] -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:39] -queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset) [01:40] -queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset) [01:40] blugh [01:40] can someon reject those containerd uploads? forgot something [01:46] -queuebot:#ubuntu-release- Unapproved: containerd (cosmic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.10.1] (no packageset) [01:50] -queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [0.2.5-0ubuntu2 => 1.2.6-0ubuntu1~18.04.1] (no packageset) [01:52] -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:57] -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:59] -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) [02:01] -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) === s8321414_ is now known as s8321414 [02:36] infinity: released subiquity to stable now [02:36] should be ready for any iso testing people still have time for ... [02:39] mwhudson: does that happen to contain a fix for 1821966 and search domains? [02:39] just curious :P [02:39] teward: yes [02:39] teward: although you should test tomorrow's daily to make sure! [02:40] well then I'll test tomorrow's daily :P [02:40] tia! [02:46] mwhudson: any idea when the dailies generate? [02:46] so I know when tomorrow to test :p [04:41] teward: disco dailies are turned off AFAIK [06:26] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (disco-proposed/main) [64ubuntu6 => 64ubuntu7] (ubuntu-desktop) (sync) [06:51] -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) [06:52] doko, ^^ I tried to fix your kopanocore upload, but I'm not really sure about the fix... [06:53] maybe the fix should go in src:apport? [06:55] maybe juliank ^^ ? does apt need to read cputable? [06:56] LocutusOfBorg: yes, it does [06:56] does it have an apport profile? [06:56] I don't get why kopanocore fails testsuite in that way [06:57] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190305_224317_8d7c5@/log.gz [06:57] I don't think it does [06:58] 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] and in any case kopanocore doesn't directly access that file, so it might be a dpkg/apt bug hidden somewhere? [06:59] ^one more fix for the errors seen in disco and also fixing slowness in bionic [07:00] LocutusOfBorg: I'm not sure why it's not accessible [07:00] dpkg ships that file, and apt requires it being present [07:00] upstreadm review: https://github.com/mvo5/unattended-upgrades/pull/190 [07:00] mvo5 issue (Pull request) 190 in unattended-upgrades "Adjust only transitive dependencies in the fallback" [Open] [07:01] juliank, i really want to do pinning only and not adjustments in u-u [07:04] rbalint: well, then, do it I guess - I think the infra is there now, although a bit hacky [07:07] 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] DAMN [07:08] ^fun [07:08] juliank, also i measured u-u to be much slower [07:08] juliank, needs to move to low level apt api first, it seems [07:08] devil is hidden in the details [07:08] * LocutusOfBorg grabs coffee and prepares a big hammer [07:09] rbalint: You should add an action group around the adjustment loop I think [07:09] + signal (send) set=("term") peer=unconfined, [07:09] what is the problem on this? [07:09] rbalint: because this is wreaking havoc in recalculating installability each time you adjust one [07:10] oh no [07:12] juliank, the speed is not terrible and actiongroups caused problems with cache clear, thus i don't want to risk that now [07:12] Well, yes [07:12] juliank, the side effects of action groups are not crystal clear [07:13] -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) [07:13] Well, they are perfectly clear - the action group delays recalculating stuff in the dep cache [07:13] Obviously, you can't re-initialize the depcache while you're holding an action group [07:14] s/Obviously/It follows that/ [07:14] action groups should provide a drastic performance increase [07:14] switching to low-level should offer basically no performance [07:15] Probably should raise an exception when clearing a cache that has an action group [07:18] rbalint: Or to be more clear, action groups, when released, re-calculate which packages are autoremovable and which are not [07:20] rbalint: So, if you re-initialize the cache while holding the action group, you'll end up with wrong autoremovable states [07:22] rbalint: But yes it will require some restructuring of u-u to work with that model [07:23] though i do not understand _how_ it delays things [07:23] Ah I see [07:23] The code is super odd [07:24] e.g. MarkInstall() keeps an ActionGroup during its call [07:24] so, if there is no other action group, it will be released at the end [07:24] same for set candidate version [07:25] 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] which is, um, slow [07:25] juliank, yes i can see that [07:26] juliank, and rather than trying to sped this up a bit i'd like to drop adjustments and use pinning [07:26] 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:27] that would also be wonderful and speed up other clients as well [07:32] rbalint: oh, but you still have to release the action group before determining which packages are auto-removable [07:32] But I'm wondering if python-apt could not automatically manage an action group for you [07:33] basically, keep an action group until you are looking at autoremovable states [07:33] infinity u-u 1.10ubuntu5 autopkg passed locally in bionic vm [07:34] it's a bit fragile if actiongroup behavior changes in the future [07:35] how about not changing it and seeing how u-u performs using pinning and low level apt api? [07:36] maybe automatic action group would just slow it down [07:39] -queuebot:#ubuntu-release- Unapproved: base-files (disco-proposed/main) [10.1ubuntu8 => 10.1ubuntu9] (core) [07:43] -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] [07:43] 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] should be a nice gain for most users and avoid the need for action groups [07:44] 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:45] 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] juliank, ok, but can't i read autoremovable state of packages withot noticing the dirtyness? [07:45] rbalint: Well, I'd replace the fields in apt's cache with accessor methods [07:46] juliank, does not sound like a speedup... [07:46] that do bool Garbage() { if (dirty) MarkAndSweep(); return Garbage; } [07:46] rbalint: It certainly is not a speedup for those who use action groups now, yes [07:47] 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:48] It's also shorter than it looks because it's the same file two times [07:49] infinity: I did look at it yesterday in github, and it looks ok [07:49] - marking_succeeded = self.call_checked(function, pkg, **kwargs) [07:49] + self.call_checked(function, pkg, **kwargs) [07:49] is the only thing I'm confused about [07:50] "it looks okay" shouldn't be followed by "but..." on another line. :P [07:50] juliank, i made minor edits [07:50] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu5] [07:50] (already accepted it) [07:50] But please, talk amongst yourselves, and if you have something better to upload, I'd like it in ~30m. [07:51] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (disco-proposed) [10.1ubuntu9] [07:51] infinity: Well, it's OK, it just looks slightly odd, but the variable is not used afterwards, so it's technically fine [07:53] juliank, yep, it was an obsolete assignment [07:55] infinity, you mean the first or the second upload? [07:55] LocutusOfBorg: The seonc. [07:55] second, too. [07:56] - /etc/ssl/openssl.cnf r, [07:56] + /etc/ssl/openssl.cnf r [07:56] did you see the diff between -1 and -2 uploads? [07:56] I mean the good and the bad one [07:56] http://launchpadlibrarian.net/412007799/kopanocore_8.7.0-1build1_8.7.0-2.diff.gz [07:57] .... and? [07:58] -2 looks correct to me. [08:00] :( so I don't know... [08:00] LocutusOfBorg: ^^ seriously? 20:04 [08:00] vorlon we're in final freeze. *critical fixes only*, not "sync new upstream versions to be in sync" [08:01] ^^ vorlon I miss the context, I fixed other people syncs from experimental I didn't sync by myself from there [08:02] 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] 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] 14:05 -queuebot:#ubuntu-release- Unapproved: rejected mokutil [sync] (disco-proposed) [08:02] [0.3.0+1538710437.fb6250f-1] [08:03] 14:06 < vorlon> not even new upstream version; but regardless, no [08:03] LocutusOfBorg: ^ That was the context. [08:03] 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] LocutusOfBorg: And how does one blame someone else for your upload? [08:04] Perhaps don't upload cosmetic changes in final freeze. [08:04] yep sure, isn't VCS fields something end users care about? [08:04] Laney: I'll be in the office in ~30... Got distracted working from the hotel and didn't notice the time. :P [08:05] I mean, is debcheckout supposed to being run from ubuntu users? [08:05] it's not [08:05] I mean, think about it [08:05] "regular users" use binary packages. [08:05] infinity: I'mjust arriving into St PancrasinfI'm just arriving into St Pancras [08:05] FML [08:05] If this even sends [08:05] see if you can tell from that that I'm on a train [08:05] Laney: Hahaha. It sent. All the times. [08:06] The Vcs field is only useful for devel [08:06] if at all [08:06] infinity, good point :) I would say "regular users don't use linux" probably :p [08:06] WHICH STATION IS LANEY AT? [08:06] 'k, see you soon [08:06] Because the Vcs change often enough for a stable release to be outdated anyway, and we don't SRU Vcs field changes [08:07] And since we do not SRU Vcs field changes, it's also not appropriate for an upload during final freeze [08:07] 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:08] I could update the branch name in Vcs-Git for apt when doing stable releases, like I do debian/gbp.conf [08:08] but I never bothered [08:09] infinity, wrt apparmor you were right, that warning was from the previous upload, so yes you are right [08:09] so any idea for this kopanocore upload? [08:10] LocutusOfBorg: I haven't looked at the issue(s), just noted that removing that comma was wrong. :P [08:10] LocutusOfBorg: Maybe I can poke later, after respin o'clock. [08:10] http://launchpadlibrarian.net/419476735/kopanocore_8.7.0-2ubuntu1_8.7.0-2ubuntu2.diff.gz [08:10] maybe the first version of my upload in the queue was better... not sure if DebOMatic is enough to trigger this issue [08:11] -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] [08:13] So [08:13] I don't really feel like it makes sense for packages to include files needed by apport implementation details in their apparmor profile [08:14] Maybe we should move the files the python hook needs like cputable into the python abstractions [08:16] 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] LocutusOfBorg: ^ [08:18] juliank, so you can fix it? [08:19] and yes I agree that a general problem needs a general solution [08:20] I'm not entirely sure what we need [08:20] like we do know we need cputable [08:21] 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] jibel: morning o/ [08:21] jibel: did you notice LP: #1824905 during your testing so far? [08:21] Launchpad bug 1824905 in ubiquity (Ubuntu) "Long pause when selecting 3rd party drivers during install" [Undecided,Confirmed] https://launchpad.net/bugs/1824905 [08:22] 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] jibel: I wonder if that's reproducible only on specific hardware or maybe happens everytime [08:22] * sil2100 downloads an iso [08:22] It's unclear to me that just making the apport hook work (adding the file it needs) is the right approach [08:23] because under normal operation, it will not run, and you give the code access to files it does not _really_ need [08:26] sil2100, I commented on the bug report [08:26] sil2100, it's when ubuntu-drivers runs [08:26] So I think we should leave that up to security team [08:26] and now it runs every time [08:26] I'll report a launchpad bug for that [08:26] sil2100, because we want to install free drivers too for example when running on vmware [08:27] sil2100, I think the fix is to add some feedback [08:29] LocutusOfBorg: reported https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824961 [08:29] Ubuntu bug 1824961 in apparmor (Ubuntu) "Blocks apport python hook from working" [Undecided,New] [08:30] jibel: ah, hm, ok! Thanks [08:32] jibel: anyway, since it's doing what it's supposed to, not a blocker - carry on! [08:32] ;) [08:36] infinity, Laney - i am staying at home today, probably like until 2pm at least, because deliveries =( [08:37] ugh deliveries [08:37] * juliank has one tomorrow, already sad [08:43] xnox: aww [08:50] juliank, what if I say "it doesn't fail on my machine?" [08:50] infinity, https://code.launchpad.net/~xnox/ubuntu-cdimage/suru-fold-fix-offset-horizon/+merge/366092 better cdimage horizon (from the web team email) [08:51] 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] I think I got the issue [08:54] 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:57] * Laney pats xnox [08:58] LocutusOfBorg: hmm, does the profile not include [08:58] I mean, that's why it exists [08:58] it does contain [08:58] /usr/lib{,32,64}/python3.[0-9]/lib-dynload/*.so mr, [08:58] it does include yes [08:59] but then it should just work [09:00] you right [09:00] I got it [09:00] should I rerun that and ssh into it afterwards to see the dmesg? [09:00] apparmor issue [09:00] mmm no [09:01] -queuebot:#ubuntu-release- Unapproved: rejected mariadb-10.1 [source] (cosmic-proposed) [1:10.1.38-0ubuntu0.18.10.1] [09:06] LocutusOfBorg: On my local machine, I got an entirely different failure when running it. Something to do with python3-magic. :P [09:08] LocutusOfBorg: Are you testing any of these uploads, or just stabbing wildly in the dark? [09:09] on my ppa [09:09] https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages [09:09] but I'm having troubles running tests... [09:09] 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:10] is autopkgtestsuite having a sad day? [09:11] Maybe [09:11] if I put a wrong ubuntu3 version on the above link it answers "that version is not published in your ppa" [09:11] and meh, my link should be good [09:14] Again, if needed I can retrigger the autopkgtest and then ssh into it to debug why it failed [09:14] yes please :) [09:14] because so far, the fix attempts do not seem to make much sense [09:15] none of them, even the ubuntu1 version... [09:16] Indeed, I think doko's "fix" was misguided, but yours have been following down the same path so far. :) [09:16] Can you not reproduce locally and iterate? [09:16] LocutusOfBorg: should be fixed [09:16] I'm not able to... [09:17] please try, I didn't want to click your link for you [09:17] it worked [09:17] ^-- He means request.cgi [09:17] I'm running the test manually now with --shell-fail [09:17] thanks Laney I updated #launchpad to tell that :) [09:18] Dunno why, but rabbitmq had fallen over with no apparent output [09:20] I don't feel like it does anything, but I might be wrong [09:20] is "sudo autopkgtest-build-lxc ubuntu disco" still the correct command to run? [09:21] don't you want to use lxd? [09:21] or a VM? [09:21] "autopkgtest-build-lxd images:ubuntu/disco/amd64" [09:21] is this still the correct command to run? [09:21] :) [09:22] 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] I think ubuntu-daily:disco is nicer? [09:22] But the infra certainly uses the VMs [09:22] that is, autopkgtest-buildvm-ubuntu-cloud [09:23] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.21] [09:23] juliank, so just a "sudo autopkgtest-buildvm-ubuntu-cloud"? [09:23] and then, how I run a local test on that package? [09:24] -r disco, probably [09:24] it generates an .img file [09:24] LocutusOfBorg, -- qemu ~/.img/autopkgtest-disco-amd64.img [09:24] you then do autopkgtest -- qemu [09:25] * Laney is a bit concerned that LocutusOfBorg is only right now learning this [09:25] 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] Laney, our infra works so well you don't need to know how to run tests locally ;-) [09:25] I usually look at the debian/tests content, and run it manually [09:25] You could say that for test builds too [09:26] but I assume it's considered best practice for people to do those... [09:26] btw usually failures are not on amd64, so I have to know anyway how to run them on the infrastructure [09:26] Laney, trust me, I failed to find documentation for that... I'm sure there is, but I can't find it [09:26] https://manpages.debian.org/testing/autopkgtest/autopkgtest-buildvm-ubuntu-cloud.1.en.html [09:26] this is the best page I found so far, based on what you told me before [09:28] test is running now [09:28] and it worked fine [09:28] LocutusOfBorg: Looking at the test, this was from over a month ago, and all tests since then have passed [09:28] LocutusOfBorg, http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test is a good place to start imo [09:29] rbalint, sad that google doesn't return that page... [09:29] I googled "ubuntu autopkgtest wiki" and the results don't help [09:29] hmm, got kopano 8.7.0-1 [09:30] https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Local_deployment [09:30] this is what is returned [09:30] * juliank used wrong commandline [09:31] let's try again [09:31] from this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/k/kopanocore/20190304_165158_f8fa9@/log.gz [09:32] LocutusOfBorg, google knows me :-) i also looked for "autopkgtest local reproduce" [09:37] -queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (cosmic-proposed) [2.4.46+dfsg-5ubuntu1.2] [09:37] test's about to run [09:38] AttributeError: /usr/bin/python3: undefined symbol: magic_open [09:38] is the error now [09:38] also seeing a [09:38] [ 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:39] 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:40] setting the profile to complain makes it work [09:40] juliank: Yeah, the magic_open failure is what I got locally too. [09:41] So I guess it needs [09:41] /usr/sbin/ldconfig x, [09:41] /usr/bin/x86_64-linux-gnu-ld.bfd x, [09:41] with some proper flags [09:41] but not entirely sure why [09:42] Why is it running ldconfig? And why on earth is it running ld? [09:42] [ 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] infinity: that's a good question [09:42] [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] Oh python, you special. [09:43] I also see it attempting to run GCC in my ringbuffer. [09:43] I did not see that [09:43] [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] nice [09:44] some ctypes module? [09:44] or something like that [09:44] idk how that works [09:46] Not sure I see the value in attempting to make this migrate. [09:47] Also puzzled that -1 still works and -2 is a miserable failure. [09:47] But yes, "python -c "import magic"" definitely executes ldconfig [09:47] [pid 27144] execve("/sbin/ldconfig", ["/sbin/ldconfig", "-p"], 0x7f107a741ab0 /* 2 vars */) = 0 [09:47] magic! [09:48] If I make ldconfig fail, it fails [09:48] it then falls back to gcc and ld [09:48] so all we need in the profile is to allow ldconfig, really [09:48] why on earth is -1 happy? [09:49] oh got it [09:49] profile broken -> ignored [09:50] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824103 [09:50] Ubuntu bug 1824103 in linux (Ubuntu) "aplay record file failed always." [Critical,Incomplete] [09:50] infinity, ^ [09:50] LocutusOfBorg: should try reproducing this in Debian with AppArmor and then checking that it fails there and report an important (RC?) bug [09:51] 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] which means that -1 is less safe than -2 :D [09:52] I wonder if adding ldconfig Ix would be OK [09:52] I tried adding it, but I had no job control, and then pressed Ctrl+C, and it ended my shell... [09:53] juliank: Ahh. So updating -2 to warn would not be a regression over -1. :P [09:55] The fix is to set it to complain, run kopano-search --help [09:55] then run aa-logprof to update the profile [09:55] and then cleanup formatting again :D [09:56] /sbin/ldconfig Pix, [09:56] is what doko added to the profile [09:57] ah and that fails because usr is merged? [09:57] it needs to be {,/usr}/sbin/ldconfig [09:58] or maybe it was there before [09:58] anyhow, needs to account for /usr [09:59] -queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.6 => 2.27.1-6ubuntu3.7] (core) [10:01] juliank, yes. [10:02] So, I built a package with that change [10:02] I'll run autopkgtest on it, and upload it if it works fine [10:03] https://paste.ubuntu.com/p/N784NGD5Yt/ [10:03] if only apparmor would follow (some) symlinks when loading the profile [10:04] looks good [10:05] juliank, please also drop the patch [10:05] from doko [10:07] -queuebot:#ubuntu-release- Unapproved: ruby-concurrent (disco-proposed/universe) [1.0.5-2ubuntu1 => 1.0.5-3] (no packageset) (sync) [10:08] -queuebot:#ubuntu-release- Unapproved: ruby-oauth2 (disco-proposed/universe) [1.4.1-1ubuntu1 => 1.4.1-2] (no packageset) (sync) [10:08] LocutusOfBorg: I will, after verifying the change [10:17] x86_64-linux-gnu-g++: fatal error: Killed signal terminated program cc1plus [10:17] well, that's not what I expected [10:17] *snicker* [10:18] but let's give it 8 gigs of ram instead of 1 [10:18] I gave it 4 cores to compile with [10:18] so it ran out of memory I guess [10:19] 1 GB RAM for your autopkgtest vm is not a sensible default [10:19] 1 GB * CPU core might be [10:19] 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:20] -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:21] -queuebot:#ubuntu-release- Unapproved: rejected kopanocore [source] (disco-proposed) [8.7.0-2ubuntu2] [10:21] 4 cores, 8 threads; 24 gigs of ram [10:21] juliank: 2G/thread is my usual go-to for C++. [10:21] But 1G/thread is closer to what we do in the DC, I believe. [10:21] Not positive now. [10:22] 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:23] juliank, i'm most impressed my nvme's speed [10:23] that's nice too [10:23] 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:24] I don't think I could deal well with multiple machines [10:24] hence I'm on a laptop all the time [10:24] I live most of my life on laptops, but the desktop is much more comfortable for gaming. [10:25] I don't want to know what my first desktop had [10:25] 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] I only remember was an athlon [10:25] Wow, you're young. [10:26] I got my first Athlon 750 free at an AMD preview event in 1999. It was the best thing EVER. [10:26] And I was 22. [10:27] I think I got it like 2001/2002 with XP [10:27] prior to that we only had one family computer [10:28] it came with Windows 98 SE [10:28] 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] AMD* [10:28] Also, cartridges. Typing is hard. [10:28] My dad also had a laptop with Windows ME if I'm not mistaken [10:28] Oh, before that we had some other thing [10:29] Laney, does autopkgtest not pick up unattended-upgrades ubuntu5 or i'm not patient enough? [10:29] I just had to make do with a copy of Turing's thesis. [10:29] rbalint: check https://people.canonical.com/~ubuntu-archive/proposed-migration/log/ ? [10:29] I don't know if it was an Atari or an Amiga [10:29] or something like that [10:30] and there was another DOS/Windows < 3.1 machine [10:31] 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] tar: ./debian/build/ECtools/archiver/helpers/.libs/StoreHelper.o: Wrote only 8192 of 10240 bytes [10:31] hmm, I don't have any lucj [10:32] just running out of space trying to build kopanocore [10:32] and the other qemu seems stuck too [10:33] dh_dwz -O--builddirectory=debian/build [10:33] and nothing after that [10:34] -queuebot:#ubuntu-release- Unapproved: gitaly (disco-proposed/universe) [0.129.0+debian-3 => 1.20.0+debian-1] (no packageset) (sync) [10:35] -queuebot:#ubuntu-release- Unapproved: golang-gitaly-proto (disco-proposed/universe) [0.123.0+dfsg-2 => 1.14.0+dfsg-2] (no packageset) (sync) [10:37] -queuebot:#ubuntu-release- Unapproved: golang-google-cloud (disco-proposed/universe) [0.9.0-9 => 0.9.0-10] (ubuntu-mate) (sync) [10:37] this should fix some golang packages migration ^^ [10:37] damn ubuntu-mate why did you seed it [10:38] Laney, thanks, it says pending - there is a lot pending :-( [10:38] Maybe they got fubared when rabbitmq died earlier [10:38] lemme see [10:41] Building in https://launchpad.net/~juliank/+archive/ubuntu/kopanocore now [10:47] I do remember this joystick: https://www.c64-wiki.de/images/a/aa/Competition_pro_blau.jpg [10:48] but that does not help figuring out which machine it was back then [10:49] must have been mid 90s, and like 5-10 years old [10:49] (the machine that is) [10:53] Laney, thanks! [10:55] there you go [10:55] I skill shared the process to infinity :> [11:23] Laney: It worked! [11:23] um [11:23] LocutusOfBorg: It worked! [11:24] -queuebot:#ubuntu-release- Unapproved: spirv-llvm-translator (disco-proposed/universe) [8.0.0+git20190314-0ubuntu1 => 8.0.0+git20190314-0ubuntu2] (no packageset) [11:25] -queuebot:#ubuntu-release- Unapproved: kopanocore (disco-proposed/universe) [8.7.0-2ubuntu1 => 8.7.0-2ubuntu2] (no packageset) [11:27] LocutusOfBorg: Uploaded and forwarded to Debian [11:29] fwded to debian bug 927215 [11:29] Debian bug 927215 in kopanocore "kopano-search: AppArmor profile does not account for usrmerge" [Serious,Open] http://bugs.debian.org/927215 === s8321414_ is now known as s8321414 [11:39] -queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.7-0ubuntu1 => 1.1.7.1-0ubuntu1] (ubuntukylin) === RAOF is now known as Guest94052 [11:58] -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] [12:01]