[00:24] Is it normal for debug symbols from ddebs.ubuntu.com to not match with what is in hirsute? [00:25] I guess anything synced to hirsute hasn't been synced to the ddebs yet? [00:29] ItzSwirlz: Ah, the retriever is crashing, bleh [00:29] Okay. Was creating a QA script for Ubuntu Cinnamon Remix to install debug symbols. [00:34] 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] Been crashing for a week unnoticed apparently :( [00:36] ItzSwirlz: Thanks for the report [00:39] It's likely to take a few hours to catch up, but I'll check in on it in my morning [02:22] yw, thanks [02:50] i wouldn't say it's "normal" to be behind, but it's not unusual sadly === thegodfather is now known as fabbione [07:13] ararargh my rustc build ran out of disk === sunweave1 is now known as sunweaver === pieq__ is now known as pieq_ [10:14] 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] 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] ItzSwirlz: Took a while, but looks like it caught up about 5-6 hours ago [10:23] (and its processing is a bit faster now due to that fix, as expected) === icey_ is now known as icey [11:41] hum, what's the right way to get a source version using python-apt? [11:41] $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].versions)' [11:41] that gives the binary version (which is different when looking a Debian version for a package which has a binNMU) [11:45] 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] e.g. package.candidate.source_version should do it; for binNMUs the source version is in the Source: field [11:47] 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] Package: znc [11:47] Version: 1.8.2-2+b1 [11:47] Source: znc (1.8.2-2) [11:48] Ah. Good to know - thanks. [11:48] root@tough-lacewing:~# python3 -c 'import apt; cache = apt.Cache(); print(cache["znc"].candidate.source_version)' [11:48] Laney, that works, thanks [11:48] $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["gnome-recipes"].candidate.source_version)' [11:48] 2.0.2-5 [11:48] 1.8.2-2 [11:48] 👍 [11:49] this is where julian_k arrives to tell me that's wrong :p [11:50] :-) [12:06] rbasak: [12:06] $ apt-cache show grub-efi-amd64-signed | grep -e Package: -e Version: -e Source: [12:06] Package: grub-efi-amd64-signed [12:06] Version: 1.155.4+2.04-1ubuntu35.4 [12:06] Source: grub2-signed (1.155.4) [12:06] Yeah L_aney pointed that out above - thanks [12:06] note that binary version != source version for a few packages, because they assemble magic versions. [12:06] mwhudson: hiya, the switch to -O2/-O3 succeeded, which is awesome! [12:06] rbasak: ok cool! [12:07] Interesting that it's an edge case where an exact match on the Source header will fail. [12:07] (which is what I usually do) [12:11] rbasak: also checkout gcc-defaults [12:13] I'm aware that there are many examples. mysql-defaults too, for example :) [12:14] I just couldn't accurately recall how it manifested in metadata, that's all :) [12:25] 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] 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] i find it odd that we do that. === tomreyn_ is now known as tomreyn [13:41] Laney: I love you for this: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/1455 [13:41] That problem has caused so many headaches. Thanks. [14:08] hum, why is that not reliable / working? :-( [14:08] $ python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].candidate)' [14:09] where apt/etc/apt/sources.list has an unstable source entry [14:09] doing the same command again and it works [14:09] the first time it gave a 'KeyError: "The cache has no package named 'nautilus'"' [14:23] tsimonq2: heh, thanks for the thanks [14:31] seb128: rootdir is a weird option [14:32] seb128: it can't work twice in a row, correctly, as it reads the options from that dir [14:33] and it can't clear the config space first because then all hell breaks loose [14:34] 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] Global state woohoo [14:45] juliank, I will try that, thanks === sem2peie- is now known as sem2peie [15:13] juliank, should that work? [15:13] $ 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] No [15:14] juliank, it's not downloading the cache corresponding to the sources.list but seems to just query from the host [15:14] yes the init() call overrides that option [15:15] you gotta call init() first, and then set the sources.list file [15:15] and also you gotta clear("Dir::Etc::sourceparts") [15:15] But you could [15:15] import apt_pkg, apt_pkg.config.set("Dir", "aptconfigs/unstable/"); apt_pkg.init() [15:16] Or not [15:16] No that should work [15:16] That avoids reading _any_ config from the host [15:16] which may or may not be what you want [15:17] it is what I want [15:17] well, it's just a script where I want to collect package versions from Debian [15:17] the script is run from an ubuntu host [15:17] sounds right [15:18] seb128: You heard about apt-venv? [15:18] no [15:19] seb128: It sounds like you're trying to rewrite it, it's packaged, and manages virtual apt environments for inspecting other distros [15:19] https://github.com/LeoIannacone/apt-venv [15:19] thx [15:19] but basically that works [15:19] python3 -c 'import apt; cache=apt.Cache(rootdir="./apt"); cache.update(); print(cache["nautilus"].candidate)' [15:19] I don't need more, just a reliable version of that :p [15:19] right [15:20] I still don't understand why it's unreliable [15:20] should the cache.update() do the equivalent of an apt update [15:20] then we can query things? [15:20] it does create the indexes etc [15:20] yes [15:21] I guess actually I misread things and thought you called apt.Cache() twice in one process [15:22] Calling that python script twice should IMO produce the same results [15:22] no, I just have that apt/etc/apt/sources.list and do ^ [15:23] juliank, the issue is that when called for the first time it creates the cache & co [15:23] but [15:23] File "/usr/lib/python3/dist-packages/apt/cache.py", line 283, in __getitem__ [15:23] raise KeyError('The cache has no package named %r' % key) [15:23] KeyError: "The cache has no package named 'nautilus'" [15:24] then if I call it again it works [15:24] seb128: Ah right, you gotta call cache.open() after cache.update() [15:24] does it fork apt or something which means the index is not done by the time I query? [15:24] juliank, and, that fixes it indeed, thanks! [15:26] k, the documentation cover that [15:26] '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] juliank, thanks again for the help! [16:01] seb128: are you still working on https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libzip.html ? === rharper_ is now known as rharper === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie [16:30] doko, no, I'm not on +1 rotation anymore this week [16:37] seb128: starting a transition as a desktop engineer, and then not completing the no-change uploads is at least odd ... [16:38] 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] 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] also 'no-change uploads' I don't know, could be, it requires test building things first to see if they still build... [16:41] ahh, confused with libdeflate [16:42] anyway, doing the no-change uploads. I'm not doing +1 this week either [16:42] good luck, hopefully things still build :) [16:48] 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] sorry. that sounds nitpicky. not intended to be. I just remembered that is all [16:51] RikMills, I know that, unsure it's helpful outside of trying to fuel a bit more IRC arguing though :/ [16:51] I will step away from it [16:51] I happened to merge that one, or rather drop an Ubuntu delta which wasn't needed anymore [16:51] we could as well have it autosynced [16:52] seb128: sorry. certainly not trying to argue. [16:52] what was the purpose of that comment? [16:52] I'm not sure to follow where you are going there [16:54] 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] RikMills, no worry! [16:59] bah, in that python-apt calls I forgot that it was checking binaries and not sources :-( [18:59] utkarsh2102: hooray for spidey senses [18:59] (things you learn by reading the changes mailing list for several years) [19:16] mwhudson: yay, indeed! and now I know who to contact whenever I run into weird bugs ;) [19:19] 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] LocutusOfBorg, that's going to eat cpu cycles from builders and trigger a bunch of autopkgtests for 0 content... [19:30] juliank, is there a python-apt cache of source packages rather than binary ones? [19:39] juliank, unping, found apt.apt_pkg.SourceRecords [19:40] heh [19:40] only saw the unping :D [19:40] :) [19:40] making cinnamon rolls [19:40] sounds nice, enjoy! [20:23] utkarsh2102: wait, isc dhcp has a bugtracker now? [20:23] astonishing [20:24] 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] in any case hopefully we avoided the tests on next opening [20:29] utkarsh2102: 50/50 on whether it's a isc-dhcp bug or a gcc bug though [22:39] 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:39] Launchpad bug 1918270 in grub2-signed (Ubuntu) "package grub-efi-amd64-signed 1.164+2.04-1ubuntu42 failed to install/upgrade: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1" [Undecided,New] [22:49] sarnold, he is on vac [22:50] LocutusOfBorg: oh :) thanks, good for him :D [22:50] (cfr what somebody answered me 24h ago on -release) [22:51] (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 :)