[00:24] <ItzSwirlz> Is it normal for debug symbols from ddebs.ubuntu.com to not match with what is in hirsute?
[00:25] <ItzSwirlz> I guess anything synced to hirsute hasn't been synced to the ddebs yet?
[00:29] <cjwatson> ItzSwirlz: Ah, the retriever is crashing, bleh
[00:29] <ItzSwirlz> Okay. Was creating a QA script for Ubuntu Cinnamon Remix to install debug symbols.
[00:34] <cjwatson> ItzSwirlz: https://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/186 had been sitting around uncommitted on my disk for ages.  I've deployed it and killed the current doomed run, so it should actually be able to catch up now.
[00:36] <cjwatson> Been crashing for a week unnoticed apparently :(
[00:36] <cjwatson> ItzSwirlz: Thanks for the report
[00:39] <cjwatson> It's likely to take a few hours to catch up, but I'll check in on it in my morning
[02:22] <ItzSwirlz> yw, thanks
[02:50] <mwhudson> i wouldn't say it's "normal" to be behind, but it's not unusual sadly
[07:13] <mwhudson> ararargh my rustc build ran out of disk
[10:14] <utkarsh2102> mwhudson: oh no, I didn't try the switch yet, but I'll do so now! and yeah, it's definitely not a long-term solution, I've filed the bug upstream already; cf: https://gitlab.isc.org/isc-projects/dhcp/-/issues/170.
[10:16] <utkarsh2102> mwhudson: as for enjoying chasing toolchain bugs, not much but it depends, really. At the end, I mostly tend to do it (since what needs to be done, needs to be done) :)
[10:22] <cjwatson> ItzSwirlz: Took a while, but looks like it caught up about 5-6 hours ago
[10:23] <cjwatson> (and its processing is a bit faster now due to that fix, as expected)
[11:41] <seb128> hum, what's the right way to get a source version using python-apt?
[11:41] <seb128> $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].versions)'
[11:41] <seb128> that gives the binary version (which is different when looking a Debian version for a package which has a binNMU)
[11:45] <rbasak> I'm not sure about python-apt. But thinking about apt's data model, is there _any_ way of getting a source version from a binary version if they're not assumed to be the same? I'm not sure there is.
[11:47] <Laney> e.g. package.candidate.source_version should do it; for binNMUs the source version is in the Source: field
[11:47] <Laney> laney@nightingale> GET https://deb.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz | xzcat | grep-dctrl -FPackage -sPackage,Version,Source -X znc                                                                       ~
[11:47] <Laney> Package: znc
[11:47] <Laney> Version: 1.8.2-2+b1
[11:47] <Laney> Source: znc (1.8.2-2)
[11:48] <rbasak> Ah. Good to know - thanks.
[11:48] <Laney> root@tough-lacewing:~# python3 -c 'import apt; cache = apt.Cache(); print(cache["znc"].candidate.source_version)'
[11:48] <seb128> Laney, that works, thanks
[11:48] <seb128> $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["gnome-recipes"].candidate.source_version)'
[11:48] <seb128> 2.0.2-5
[11:48] <Laney> 1.8.2-2
[11:48] <Laney> 👍
[11:49] <Laney> this is where julian_k arrives to tell me that's wrong :p
[11:50] <seb128> :-)
[12:06] <xnox> rbasak:
[12:06] <xnox> $ apt-cache show grub-efi-amd64-signed | grep -e Package: -e Version: -e Source:
[12:06] <xnox> Package: grub-efi-amd64-signed
[12:06] <xnox> Version: 1.155.4+2.04-1ubuntu35.4
[12:06] <xnox> Source: grub2-signed (1.155.4)
[12:06] <rbasak> Yeah L_aney pointed that out above - thanks
[12:06] <xnox> note that binary version != source version for a few packages, because they assemble magic versions.
[12:06] <utkarsh2102> mwhudson: hiya, the switch to -O2/-O3 succeeded, which is awesome!
[12:06] <xnox> rbasak:  ok cool!
[12:07] <rbasak> Interesting that it's an edge case where an exact match on the Source header will fail.
[12:07] <rbasak> (which is what I usually do)
[12:11] <xnox> rbasak:  also checkout gcc-defaults
[12:13] <rbasak> I'm aware that there are many examples. mysql-defaults too, for example :)
[12:14] <rbasak> I just couldn't accurately recall how it manifested in metadata, that's all :)
[12:25] <xnox> rbasak:  i think the worst thing is actually nvidia drivers, as they have binary packages taking over debs from previous sources. and sometimes all of them are still published in launchpad.
[12:26] <xnox> hence i had weird queries where nvidia-drivers-XXX exists from both src:nvidia-XXX and src:nvidia-YYY at the same time, with both binaries published, but obviously only one winning.
[12:26] <xnox> i find it odd that we do that.
[13:41] <tsimonq2> Laney: I love you for this: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1455
[13:41] <tsimonq2> That problem has caused so many headaches. Thanks.
[14:08] <seb128> hum, why is that not reliable / working? :-(
[14:08] <seb128> $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].candidate)'
[14:09] <seb128> where apt/etc/apt/sources.list has an unstable source entry
[14:09] <seb128> doing the same command again and it works
[14:09] <seb128> the first time it gave a 'KeyError: "The cache has no package named 'nautilus'"'
[14:23] <Laney> tsimonq2: heh, thanks for the thanks
[14:31] <juliank> seb128: rootdir is a weird option
[14:32] <juliank> seb128: it can't work twice in a row, correctly, as it reads the options from that dir
[14:33] <juliank> and it can't clear the config space first because then all hell breaks loose
[14:34] <juliank> Chances are you want to clear apt_pkg.config, set Dir option to target dir, call apt_pkg.init_config(), and then create the Cache object
[14:36] <juliank> Global state woohoo
[14:45] <seb128> juliank, I will try that, thanks
[15:13] <seb128> juliank, should that work?
[15:13] <seb128> $ python3 -c 'import apt_pkg; apt_pkg.config.set("Dir::Etc::sourcelist", "aptconfigs/unstable/etc/apt/sources.list");  apt_pkg.init(); cache=apt_pkg.Cache(); print(cache["nautilus"].version_list)'
[15:14] <juliank> No
[15:14] <seb128> juliank, it's not downloading the cache corresponding to the sources.list but seems to just query from the host
[15:14] <juliank> yes the init() call overrides that option
[15:15] <juliank> you gotta call init() first, and then set the sources.list file
[15:15] <juliank> and also you gotta clear("Dir::Etc::sourceparts")
[15:15] <juliank> But you could
[15:15] <juliank> import apt_pkg, apt_pkg.config.set("Dir", "aptconfigs/unstable/"); apt_pkg.init()
[15:16] <juliank> Or not
[15:16] <juliank> No that should work
[15:16] <juliank> That avoids reading _any_ config from the host
[15:16] <juliank> which may or may not be what you want
[15:17] <seb128> it is what I want
[15:17] <seb128> well, it's just a script where I want to collect package versions from Debian
[15:17] <seb128> the script is run from an ubuntu host
[15:17] <juliank> sounds right
[15:18] <juliank> seb128: You heard about apt-venv?
[15:18] <seb128> no
[15:19] <juliank> seb128: It sounds like you're trying to rewrite it, it's packaged, and manages virtual apt environments for inspecting other distros
[15:19] <juliank> https://github.com/LeoIannacone/apt-venv
[15:19] <seb128> thx
[15:19] <seb128> but basically that works
[15:19] <seb128> python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].candidate)'
[15:19] <seb128> I don't need more, just a reliable version of that :p
[15:19] <juliank> right
[15:20] <seb128> I still don't understand why it's unreliable
[15:20] <seb128> should the cache.update() do the equivalent of an apt update
[15:20] <seb128> then we can query things?
[15:20] <seb128> it does create the indexes etc
[15:20] <juliank> yes
[15:21] <juliank> I guess actually I misread things and thought you called apt.Cache() twice in one process
[15:22] <juliank> Calling that python script twice should IMO produce the same results
[15:22] <seb128> no, I just have that apt/etc/apt/sources.list and do ^
[15:23] <seb128> juliank, the issue is that when called for the first time it creates the cache & co
[15:23] <seb128> but
[15:23] <seb128>   File "/usr/lib/python3/dist-packages/apt/cache.py", line 283, in __getitem__
[15:23] <seb128>     raise KeyError('The cache has no package named %r' % key)
[15:23] <seb128> KeyError: "The cache has no package named 'nautilus'"
[15:24] <seb128> then if I call it again it works
[15:24] <juliank> seb128: Ah right, you gotta call cache.open() after cache.update()
[15:24] <seb128> does it fork apt or something which means the index is not done by the time I query?
[15:24] <seb128> juliank, and, that fixes it indeed, thanks!
[15:26] <seb128> k, the documentation cover that
[15:26] <seb128> 'You probably want to call open() afterwards, in order to utilise the new cache. Otherwise, the old cache will be used which can lead to strange bugs.'
[15:26] <seb128> juliank, thanks again for the help!
[16:01] <doko> seb128: are you still working on https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libzip.html ?
[16:30] <seb128> doko, no, I'm not on +1 rotation anymore this week
[16:37] <doko> seb128: starting a transition as a desktop engineer, and then not completing the no-change uploads is at least odd ...
[16:38] <seb128> doko, I don't understand that 'starting a transition as a desktop engineer', it's an universe package which was failing to build due to Bsymbolic for a while which I fixed during my +1 rotation
[16:39] <seb128> is there yet another rule that on +1 if you fix a build you become in charge of dealing with the rdepends of the package you fixed?
[16:39] <seb128> also 'no-change uploads' I don't know, could be, it requires test building things first to see if they still build...
[16:41] <doko> ahh, confused with libdeflate
[16:42] <doko> anyway, doing the no-change uploads. I'm not doing +1 this week either
[16:42] <seb128> good luck, hopefully things still build :)
[16:48] <RikMills> seb128: with respect, you force-synced libzip 1.7.3-1 at the beginning of February. I recall asking you about it https://irclogs.ubuntu.com/2021/02/04/%23ubuntu-devel.html#t12:24
[16:49] <RikMills> sorry. that sounds nitpicky. not intended to be. I just remembered that is all
[16:51] <seb128> RikMills, I know that, unsure it's helpful outside of trying to fuel a bit more IRC arguing though :/
[16:51] <seb128> I will step away from it
[16:51] <seb128> I happened to merge that one, or rather drop an Ubuntu delta which wasn't needed anymore
[16:51] <seb128> we could as well have it autosynced
[16:52] <RikMills> seb128: sorry. certainly not trying to argue.
[16:52] <seb128> what was the purpose of that comment?
[16:52] <seb128> I'm not sure to follow where you are going there
[16:54] <RikMills> just adding extra info. did not come out with the right tone. which is why I immediately added "sorry. that sounds nitpicky. not intended to be. I just remembered that is all"
[16:58] <seb128> RikMills, no worry!
[16:59] <seb128> bah, in that python-apt calls I forgot that it was checking binaries and not sources :-(
[18:59] <mwhudson> utkarsh2102: hooray for spidey senses
[18:59] <mwhudson> (things you learn by reading the changes mailing list for several years)
[19:16] <utkarsh2102> mwhudson: yay, indeed! and now I know who to contact whenever I run into weird bugs ;)
[19:19] <seb128> LocutusOfBorg, hey, what's the point of http://launchpadlibrarian.net/527034392/vala_0.48.14-1~fakesync_0.48.14-1.diff.gz ? it feels like burning resources for nothing...
[19:20] <seb128> LocutusOfBorg, that's going to eat cpu cycles from builders and trigger a bunch of autopkgtests for 0 content...
[19:30] <seb128> juliank, is there a python-apt cache of source packages rather than binary ones?
[19:39] <seb128> juliank, unping, found apt.apt_pkg.SourceRecords
[19:40] <juliank> heh
[19:40] <juliank> only saw the unping :D
[19:40] <seb128> :)
[19:40] <juliank> making cinnamon rolls
[19:40] <seb128> sounds nice, enjoy!
[20:23] <mwhudson> utkarsh2102: wait, isc dhcp has a bugtracker now?
[20:23] <mwhudson> astonishing
[20:24] <LocutusOfBorg> seb128, it was bothering me because I look usually for "fakesyncs" or auto-sync log (because they need to be manually done). and that package was "12 references" in the auto-sync.log
[20:24] <LocutusOfBorg> in any case hopefully we avoided the tests on next opening
[20:29] <mwhudson> utkarsh2102: 50/50 on whether it's a isc-dhcp bug or a gcc bug though
[22:39] <sarnold> vorlon: do I remember that you were trying to interact with bug reporters on grub updates that trip efi firmware bugs? https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1918270  has some "warning: efivarfs_set_variable: writing to fd 8 failed: Invalid argument" errors in the terminal log
[22:49] <LocutusOfBorg> sarnold, he is on vac
[22:50] <sarnold> LocutusOfBorg: oh :) thanks, good for him :D
[22:50] <LocutusOfBorg> (cfr what somebody answered me 24h ago on -release)
[22:51] <sarnold> (now I'm all the more glad that the whole thing fit in one irc message, so /lastlog will actually be useful if he cares :)