[08:27] <mwhudson> sarnold: whee subiquity bugs with apport data!
[08:41] <cpaelzer> according to https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867 there should be a nmap-dbgsym
[08:41] <cpaelzer> I can see other dbgsym packages so ddebs are set up
[08:41] <cpaelzer> but I can't find nmap-dbgsym in focal
[08:42] <cpaelzer> could someone cross check this on another system so that I know it is just me ?
[08:43] <cpaelzer> second focal container, same behavior ...
[08:44] <cpaelzer> this isn't like just build to be populating the archive just now (from 2019-11-08)
[08:45] <cpaelzer> the direct link from the build info works https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867/+files/nmap-dbgsym_7.80+dfsg1-2_amd64.ddeb
[08:45] <cpaelzer> but why can't I see it in ddebs
[08:45] <cpaelzer> any hints appreciated if later one someone can take a look if it affects others as well
[08:59] <seb128> cpaelzer, hey. I'm trying to remember the details but basically the ddeb service is not built in in launchpad, it has a 'collector' job on some machine, it happens sometime that this job get stucked/hit a bug and than ddbes get 'losts'
[09:04] <cpaelzer> seb128: interesting, what are we supposed to do about it once we find such a case?
[09:04] <seb128> cpaelzer, I'm trying to remember where the job is and see if I can still ssh/poke to it
[09:05] <seb128> cpaelzer, but basically it's "find someone who can do that and ask them to look'
[09:05] <seb128> cpaelzer, and we might need to change uploads for packages which miss a ddeb and where we would like to get one
[09:06] <cpaelzer> ok, then lets ping the usual suspects who often know more about the secret sauce :-) vorlon apw infinity ^^
[09:07] <apw> seb128, not thatis true any more, i think ddebs became first class citizens quite some time ago, and now are in the librariant
[09:08] <seb128> cpaelzer, seems like I'm leaving on outdated info, sorry
[09:08] <cpaelzer> np
[09:09] <cpaelzer> I'll file a bug for proper handling
[09:09] <seb128> apw, good, so how can ddebs get missing in the new world? :)
[09:09] <cpaelzer> and assign it to archive admins as I think there the evalaution what is going on would start
[09:09] <apw> seb128, whatspecifically is missing
[09:09] <seb128> apw,
 according to https://launchpad.net/ubuntu/+source/nmap/7.80+dfsg1-2/+build/18072867 there should be a nmap-dbgsym
[09:09] <seb128>  I can see other dbgsym packages so ddebs are set up
[09:09] <seb128>  but I can't find nmap-dbgsym in focal
[09:10] <cpaelzer> yep that summarizes how I found it
[09:10] <cpaelzer> and it now has a bug https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1861387
[09:11] <amitprakash> Hi, bzr builddeb tells me "dpkg-gencontrol: warning: can't parse dependency xyz". What am I doing wrong if xyz is another package?
[09:12] <cpaelzer> amitprakash: is xyz listed in your packages debian/control and if so might that line have syntax issues?
[09:13] <amitprakash> cpaelzer: http://paste.ubuntu.com/p/j35rtBH8mN/ this is what my control looks like
[09:14] <cpaelzer> amitprakash: and xyz really is ...?
[09:14] <apw> seb128, cpaelzer, ok that ddeb is in main, presumably because its corresponding .deb is in main
[09:15] <cpaelzer> I can't find it anywhere - what do you mean by "ddeb is in main"?
[09:15] <apw> or are they, is it just older ones ... did this just move
[09:16] <apw> http://ddebs.ubuntu.com/pool/main/n/nmap/
[09:16] <cpaelzer> apw: was demoted in focal
[09:16] <apw> the previous .ddebs are in main for nmap
[09:16] <apw> cpaelzer, and how long ago was it demoted?
[09:16] <cpaelzer> http://ddebs.ubuntu.com/pool/universe/n/nmap/
[09:17] <cpaelzer> has all some but not the nmap-dbgsym
[09:17] <apw> if it was a while ago i suspect it is a bug
[09:17] <cpaelzer> I don't know when it was demoted
[09:17] <cpaelzer> apw: mid december
[09:18] <cpaelzer> by this https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=a77db6ce36654e456957034687cd597081c3db2d
[09:24] <RikMills> fossfreedom: in budgie-tools - debian/tests/control:Depends: pep8
[09:24] <RikMills> so tests fail, as that transitional is now gone
[09:27] <cpaelzer> apw: I put the insights above into the bug
[09:28] <cpaelzer> apw: what would be the next steps to take on this?
[09:28] <apw> cpaelzer, i've asked on #lauchpad-ops about ot
[09:30] <cpaelzer> ok, tracking it there
[09:30] <cpaelzer> thanks!
[09:32] <amitprakash> cpaelzer: Sorry, xyz are linux-firmware amd64-microcode
[09:33] <amitprakash> dpkg-gencontrol: warning: can't parse dependency linux-firmware amd64-microcode
[09:34] <amitprakash> dpkg-gencontrol: error: error occurred while parsing Replaces field: linux-firmware amd64-microcode
[09:37] <cpaelzer> amitprakash: you are missing a colon
[09:38] <cpaelzer> Replaces: linux-firmware, amd64-microcode
[09:38] <cpaelzer> and then maybe run wrap-and-sort
[09:38] <cpaelzer> that should get you going
[09:41] <fossfreedom> RikMills: good timing... will be uploading an update tonight so will fix at the same time. Thx
[09:44] <amitprakash> Ah!, thanks a lot cpaelzer
[11:04] <seb128> mwhudson, hey, I saw your comment about subiquity report with apport data earlier but didn't see the corresponding context. Could you comment about that on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1861082 ?
[11:06] <cjwatson> nmap> https://launchpad.net/ubuntu/focal/amd64/nmap-dbgsym shows the demotion on 2019-12-17, successful from LP's point of view.  ddeb-retriever must have got confused somehow
[11:06] <cjwatson> But it shouldn't need reuploads, as LP has the file
[11:15] <juliank> So something's getting confused in nautilus, udisks2 and snap
[11:15] <juliank> it shows snap squashfs as volumes in nautilus
[11:15] <seb128> doko, your alsa-lib sync reverted the '  * Make autopkgtests cross-test-friendly." from Steve and now it's failing i386 autopkgtests
[11:15] <juliank> or rather the loop devices
[11:17] <seb128> juliank, when did that start?
[11:17] <juliank> seb128: I don't know I just saw it today
[11:17] <juliank> But it could be older
[11:18] <juliank> seb128: Ah, it's showing deleted snap squashfs files that still have a loop device
[11:18] <seb128> juliank, how do you end up with deleted squasfs which still have a loop device?
[11:19] <juliank> I don't know, 5 of them are lxd snaps
[11:19] <juliank> (of 6)
[11:19] <juliank> https://paste.ubuntu.com/p/ry5ZKGqxCS/
[11:19] <GunnarHj> Hey sil2100! Looks like it will be the same disastrous lack of interest in testing the language packs as the last time the Xenial langpacks were updated. :( As regards the script you wrote, will you rely on it this time and update all the languages if nothing abnormal is detected?
[11:20] <juliank> Probably a snap bug where it failed to losetup -d them
[11:20] <juliank> Looking at udisksctl dump https://paste.ubuntu.com/p/Dhtrh3VpF3/, those deleted snap devices do not have x-gdu.hide set
[11:21] <juliank> But I guess it's more of a topic for #snappy
[11:21] <seb128> right
[11:28]  * cjwatson takes https://bugs.launchpad.net/ddeb-retriever/+bug/1861387
[11:39] <sil2100> GunnarHj: hey! Yeah, I guess not much interest in translations... I'll check the script results again later and see if it's really safeish or not
[11:40] <ogra> juliank, i see this all the time in unity7 on my 16.04 laptop ... there they clutter the dock ... one for each lxd update that happened since the last boot
[11:41] <ogra> i guess there was something sitting on top of the squashfs that lxd added when the saquashfs underneath went away (just guessing though)
[11:41] <ogra> it only happens for lxd stuff for me though
[11:42] <juliank> ogra: it's a bug in systemd or libmount, it was said in #snappy
[11:42] <ogra> well, it is very specific for lxd, i have never seen it with any other snap
[11:42] <ogra> (and i have a lot of snaps installed here)
[11:43] <juliank> ogra: Well, my pastebin also mentions telegram snap
[11:43] <ogra> seems zyga just agreed with me about the backing file being still sitting on top :)
[11:44] <ogra> oh, right, i also see a telegram mount here today ... (from todays telegram update) !!
[12:20] <amitprakash> will dh_build invoke make check only if something is built? I am trying to figure out why certain build commands are executed by bzr builddeb
[12:48] <sdhd-sascha> hi, i just to reinstall my server. Which daily ubuntu20.04 images is useable ?
[12:49] <sdhd-sascha> Do not need a stable version.
[12:52] <sdhd-sascha> I'm looking for ubuntu-server image.
[12:52] <cyphermox> sdhd-sascha: if you want to use 20.04, then you can look at the files in cdimage.ubuntu.com/ubuntu-server for the exact thing you want; but perhaps the best place to discuss that is in #ubuntu-server if you need help
[12:52] <cyphermox> 20.04 isn't released yet though, so things may break
[12:55] <sdhd-sascha> cyphermox: thank you. I already tried some images. But no luck. I will ask @ #ubuntu-server
[12:56] <cyphermox> usually you want daily-live
[13:26] <cpaelzer> ahasenack: use https://libvirt.org/formatdomain.html#elementsMemory
[14:46] <doko> tjaalton: could you have a look at https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=amd64&package=sfepy&trigger=python3-defaults%2F3.8.0-3 ? some change in the X stack?
[14:48] <tjaalton> doko: everything I've uploaded is still stuck in proposed :)
[15:38] <seb128> doko, unsure what changed with the pygobject update but autopkgtests are unhappy now with 'pytest.c:(.text+0x3c9): undefined reference to `Py_InitializeEx''
[15:39] <seb128> xnox, do you know what's the issue with software-properties autopkgtes ton armhf? 'The user named '~xnox' has no PPA named 'ubuntu/nonvirt'' ... is that a problem in your ppa? why is the test using a personal ppa? :)
[15:44] <xnox> seb128:  nonvirt does exist. The point is to test any PPA which has Unicode in the PPA name
[15:44] <xnox> seb128:  is there a proxy / networking resolution failure on armhf to launchpad api?
[15:45] <xnox> seb128:  possibly this test can go away, because basically it was crashing under python2 when locale was either unicode or non-unicode one. But it should all work fine under python3, irrespective of the environmnet locale
[15:45] <seb128> xnox, log is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/s/software-properties/20200130_123908_8f53c@/log.gz , I don't think any obvious infra error
[15:45] <xnox> seb128:  because obviously the key on my user account is generated with unicode name.
[15:46] <doko> seb128: I didn't change anything
[15:46] <seb128> doko, k, unsure what's the issue :/
[15:46] <doko> that's a Debian import, and I just merged gobject-introspection again becase of the tightened dependencies
[15:46] <seb128> xnox, maybe just some flakyness, I will retry
[15:47] <xnox> seb128:  the log looks really odd
[15:47] <xnox> seb128:  because xnox/nonvirt does exist, and does have things published in focal/armhf..... and yet it did find all other ppa's that i have =/
[15:48] <xnox> seb128:  do retry, and possibly open a bug report? i think we can drop the test case.... I just don't know how to make it non-remote, as i must try to add a ppa, for which launchpad generated a gpg key with unicode name
[15:48] <seb128> doko, yeah, it is a bit weird, http://autopkgtest.ubuntu.com/packages/p/pygobject/focal/amd64 it was green before and the diff only has (build-)depends changes
[15:48] <seb128> xnox, k
[15:48] <xnox> cause that was a regression that used to crash; got fixed up; and regressed multiple times; hence the autopkgtest
[15:49] <seb128> I see
[15:54] <Laney> if that PPA does still exist then it looks like a bug somewhere, either in software-properties or the LP API
[15:54] <Laney> Team PPA would seem like better practice than a personal one I guess
[15:57] <cjwatson> xnox: It's a bug in the test.  It should say ppa:xnox/ubuntu/nonvirt, not ppa:~xnox/ubuntu/nonvirt.
[15:57] <cjwatson> Extra tilde
[15:58] <apw> i do that about 10 times a year
[16:02] <seb128> cjwatson, xnox, I think it's rather a bug in the add-apt-repository output I think
[16:02] <seb128> the test does
[16:02] <seb128> debian/tests/add-apt-repository:    add-apt-repository ppa:xnox/nonvirt --yes --no-update
[16:02] <xnox> cjwatson:  oooooh
[16:02] <Laney> I think add-apt-repository is prefixing the tilde when it wasn't given
[16:02] <Laney> But it also does accept both forms AFAICS
[16:02] <seb128> also if that test was buggy it would never work I guess?
[16:02] <seb128> which isn't the case
[16:03] <apw> or apt-add-repository changed
[16:04] <cjwatson> So it could also be a bad response to something like a 503 I guess
[16:04] <Laney> Then it would have broken with a software-properties upload and remained broken
[16:04] <Laney> I would guess that it hit some transient problem and handled it badly
[16:17] <seb128> retry worked, so yeah transition issue...
[16:34] <tjaalton> doko: I don't have an issue installing python3-sfepy on focal, so I don't see what's the issue with that test
[18:18] <mdeslaur> cjwatson: any objection to me merging git?
[18:20] <cjwatson> mdeslaur: none
[18:20] <mdeslaur> cjwatson: thx
[18:56] <ahasenack> doko: the fix for the red smbmap under python3-defaults is https://github.com/ShawnDEvans/smbmap/commit/1b126a6bea48c2aa43ed3a8982398cc95c5722b3#diff-e5c95e36134a07972ecaec3a46c62b7b
[18:57] <ahasenack> I'll try to get to it today (simple one liner, sad to add a delta because of this)
[18:57] <ahasenack> I pinged the deb maintainer, no response
[18:57] <ahasenack> I'll propose there first perhaps (salsa)
[18:57] <doko> ahasenack: https://launchpad.net/ubuntu/+source/smbmap/1.1.0+git20191013-1ubuntu1
[18:57] <ahasenack> ..and we have the delta :)
[18:57] <ahasenack> n/m
[18:58] <doko> sorry
[18:58] <ahasenack> nothing else about samba/sssd in that list then
[18:58] <doko> yes, many thanks for tracking that
[18:59] <ahasenack> np
[19:00] <Eickmeyer[m]> Anybody here any good with systemd?
[19:18] <sarnold> mwhudson: I thought you'd like getting a lot more data back out of my install :) I was pretty surprised how many .crash files were left behind thuogh
[19:18] <sarnold> Eickmeyer[m]: probably best to ask a more specific question.. I'd rate my knowledge at around 5% but that might be the five percent you need, you know? :)
[19:19] <Eickmeyer[m]> sarnold: Yes, that's true. We're trying to figure out how to autostart a daemon inside the user session. OvenWerks has more details. We've been working on it the past few days in #ubuntustudio-devel.
[19:24] <sarnold> Eickmeyer[m]: very good question. for some reason systemctl list-units --user and systemctl --user list-units shows all kinds of services that are NOT user services. I'm super-confused..
[19:26] <Eickmeyer[m]> sarnold: With /etc/xdg/autostart going away (and processes launched from there not closing on session end anyhow), we're trying to figure this out.
[19:30] <CarlFK> Eickmeyer - you want to start a gui app after the user logs into X/desktop, right ?
[19:30] <Eickmeyer[m]> CarlFK: Not exactly. It's the daemon part of ubuntustudio-controls.
[19:34] <CarlFK> Eickmeyer - ok, so start daemon on login?
[19:34] <Eickmeyer[m]> CarlFK: Yes, and end on logout.
[19:35] <CarlFK> Eickmeyer - if it makes you feel better, I have been trying to figure out the 'right' way to do this for about a year
[19:36] <Eickmeyer[m]> CarlFK: While consoling, it's also a bit discouraging.
[19:37] <gQuigs> sarnold: interestingly they are different lists though.. so it's filtering some...
[19:39] <sarnold> gQuigs: oh strange
[19:40] <sarnold> gQuigs: I thought it'd be nice to see just the '*.service' entries and *that* is a lot more like what I expected: systemctl list-units --user '*.service' is a lot more like what I expected!
[19:40] <sarnold> jeeze
[19:40] <sarnold> redundancy department of redundancy
[19:41] <CarlFK> Eickmeyer - current solution "that depends on us tweaking lightdm" https://salsa.debian.org/debconf-video-team/ansible/blob/master/roles/xorg/tasks/lightdm.yml#L23
[19:42] <tumbleweed> hacky as hell
[19:43] <gQuigs> indeed.. also just noticed the --type=service option
[19:43] <tumbleweed> basically, there aren't well-defined targets for this
[19:43] <Eickmeyer[m]> Very hacky.
[20:08] <Eickmeyer[m]> So, CarlFK , that tells me it's a problem with lightdm? If we were to, say, switch to sddm would that work?
[20:17] <CarlFK> Eickmeyer: I would not say the DM is the problem.    I think we are trying to do things that aren't supported, because we are willing to compromise elegance in exchange for.. nice features?
[20:18] <CarlFK> Eickmeyer: this post is years old, but seems still relevant.  my search in October did not find anything new.   https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg
[20:19] <Eickmeyer[m]> CarlFK: Thanks, I'll pass that along.
[20:43] <sil2100> GunnarHj: hey! So uh, hm, my sanity testing suite has a small problem in testing the current situation, so I think I'll have to do some manual checks before deciding if we'll push all of those
[21:04] <ahasenack> doko: smbmap (1.1.0+git20191013-2) unstable; urgency=medium has the same fix, it can be synced again