=== Kamilion|ZNC is now known as Kamilion
=== gschanuel0 is now known as gschanuel
[05:05] <bryceh> autopkgtest framework is busted due to linux-firmware issue (LP: #1964814)
[05:05] <ubottu> Launchpad bug 1964814 in linux-firmware (Ubuntu Jammy) "linux-firmware fails to upgrade to 20220314.gitcd01f857-0ubuntu1" [Critical, Confirmed] https://launchpad.net/bugs/1964814
[05:06] <bryceh> I was wondering why my fixed symfony upload resulted in *more* breakage rather than less.  Hopefully linux-firmware fix doesn't take too long...
[06:20] <cpaelzer> good morning
[08:53] <mirespace> good morning
[09:35] <gnuoy> jamespage, fwiw I've commented on https://bugs.launchpad.net/ubuntu/+source/ceph-iscsi/+bug/1883112 suggesting we go with the minimal fix
[09:35] <ubottu> Launchpad bug 1883112 in ceph-iscsi (Ubuntu Focal) "rbd-target-api crashes with python TypeError" [High, Triaged]
[09:36] <jamespage> gnuoy: ok thanks :)
[09:36] <jamespage> gnuoy: if you want to throw a patch my way I'll sponsor that today
[09:36] <gnuoy> kk
[10:09] <athos> good morning!
[10:11] <gnuoy> jamespage, I've attached another deb diff to the bug with the minimal fix
[10:11] <jamespage> great
[10:20] <jamespage> gnuoy: I guess the other way to fix this would be to just decode the result of the check_output call
[10:21] <jamespage> but I'm also fine with twiddling the checks to be byte's based
[10:21] <gnuoy> tip top
[10:28] <jamespage> gnuoy: I've done both impish and focal - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4054/+packages
[10:29] <jamespage> I'll upload them shortly for the SRU team to review
[10:29] <gnuoy> excellent, ty
[10:34] <athos> Would anyone mind retriggering some tests? It's a long list, so I got them all here: https://paste.ubuntu.com/p/TRzxwNbwkt/plain/
[10:35] <athos> this is related to the issue bryceh was pointing out yesterday with linux-firmware (lots of php test failures)
[10:37] <jamespage> gnuoy: ok both uploaded again
[10:38] <jamespage> rbasak: thanks for the feedback on the ceph-iscsi SRU's - I've uploaded revised more minimal changes for focal and impish as supplied by gnuoy
[10:49] <rbasak> jamespage: thanks - accepted
[10:56] <schopin> athos: are the clicks still needed ?
[11:00] <athos> schopin: yes :)
[11:01] <schopin> Allright, will do :)
[11:01] <athos> thanks!
[11:04] <schopin> done
[11:04] <athos> \o/
[12:02] <ahasenack> hmm, wanted to update haproxy, but they had to sneak in a new feature... amidst all those bugfixes
[12:02] <ahasenack> +    - MINOR: pools: add a new global option "no-memory-trimming"
[12:03] <ahasenack> +no-memory-trimming
[12:03] <ahasenack> +  Disables memory trimming ("malloc_trim") at a few moments where attempts are
[12:03] <ahasenack> +  made to reclaim lots of memory (on memory shortage or on reload).
[12:30] <mirespace> hi, I need to do autopkgtest for a package in one of my personal ppa and also versus other packages in other ppa 
[12:30] <athos> kanashiro: there are also lots of failures in that ruby3.0 change migration as well due to the linux-firmware issue Bryce pointed out yesterday
[12:31] <mirespace> I did    
[12:31] <mirespace> autopkgtest -U -s --apt-pocket=proposed  --setup-commands="sudo add-apt-repository -y -u -s ppa:mirespace/cpc-docker.io-cve-2021-41190-focal" --setup-commands="sudo add-apt-repository -y -u -s ppa:cloud-images/gke-1.20-proposed"  -B docker.io  -- qemu ~/Working/Images/autopkgtest-focal-amd64.img
[12:31] <ubottu> The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone was used to determine the type of document during push and pull operations. Documents that contain both &#8220;manifests&#8221; and &#8220;layers&#8221; fields could be i... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41190>
[12:32] <mirespace> but not sure if that will trigger test for the nonexpecified packages, I mean, I'm only specifying docker.io
[12:36] <athos> mirespace: it will not trigger the tests for other packages, but it should use the packages from those PPAs as dependencies, if such deps are required
[12:38] <athos> kanashiro: waiting for linux-firmware to migrate or appending &trigger=linux-firmware/20220314.gitcd01f857-0ubuntu2 to those retrial urls should do the trick... We do have lots of test failures due to that error now though
[12:39] <mirespace> athos: I thought mor or less the same, but utkarsh give the command for doing locally on that way, so I was wondering if it can be done aso with ppas
[12:39] <mirespace> athos: I can't try locally because the package doesn't build locally but it does in the ppa ( I can research why doesn't build locally)
[12:59] <athos> mirespace: maybe you could try bileto (you'd need a core-dev to trigger tests for you though)?
[13:56] <kanashiro> oh crap, I was not getting notifications of messages here
[13:57] <kanashiro> athos, thanks for the heads-up re ruby3.0, I noticed that earlier today, If until this afternoon this is not fixed I'll retry all the failing tests with the triggered you mentioned
=== MJCD is now known as JusSupaSaiyan
[14:47] <ahasenack> mirespace: taking a look at your autopkgtest command line
[14:48] <ahasenack> mirespace: I usually put all commands in one --setup-commands= bit, separated by ":"
[14:48] <ahasenack> and this command-line will trigger just the docker.io tests, that's the source package you specified
[14:49] <ahasenack> regarding the local vs ppa build, did you enable proposed in the ppa too?
[14:49] <mirespace> ahasenack: good to know about the ":"
[14:49] <mirespace> ahasenack: I forgot to do that .. doing now
[14:50] <ahasenack> then it will probably fail to build there too, but ok :)
[14:50] <ahasenack> do you need proposed?
[14:50] <mirespace> The command line that utkarsh recommend me was:
[14:50] <mirespace> run the autopkgtest of docker.io against runc and containerd which is in the PPA (use the following command: autopkgtest -U -s --apt-pocket=proposed -B ../*.deb ../../containerd/*.deb ../../runc/*.deb -- qemu ~/ubuntu/images/autopkgtest-focal-amd64.img)
[14:50] <mirespace> can I do the same without build it locally, using the debs form the differents ppas?
[14:57] <sergiodj> mirespace: you can run autopkgtest without building the package locally, yes.  you have to add the PPA using the --setup-commands (like you were doing before), and you need to specify the exact .changes file that you used when uploading the package
[14:59] <mirespace> ook ... lets try :) thanks @sergiodj ahasenack... what confuses me is the container*.deb runc deb part on the above command, because it complaint about only can check the package I'm testing/building (oth, it seems pretty logical to me)
[15:00] <ahasenack> if you use -B, then it will not build the package
[15:00] <ahasenack> and I saw you using that
[15:00] <ahasenack> but I hadn't seen your *.deb bits, that's wrong
[15:01] <ahasenack> you have to specify a source package (one dsc), or a directory (if it's a git ubuntu checkout, for example), or just a source package name, that it will the do "apt-get source <name>"
[15:02] <sergiodj> you don't need the *.deb bits, indeed.  that's not the right way to do it
[15:02] <mirespace> ook... so I can't do the requested with the given command... so the ionly way would be bileto, as athos suggested?
=== JusSupaSaiyan is now known as MJCd
[15:59] <ahasenack> mirespace: you can test docker.io incuding packages from other dependencies, but autopkgtest (the tool) will only run the tests of the specified package (docker.io in your first example)
[16:01] <mirespace> ahasenack: thanks for confirming, I'l check with Utkarsh the requested
=== pizzaiolo is now known as pizza
[16:12] <ahasenack> and bileto isn't working so well lately. It builds the packages, but I couldn't get it to actually run the tests. Last time I tried was a month ago or more, though
[16:12] <ahasenack> but bileto would run the tests on the dependencies, like the real migration
[16:22] <mirespace> ook ... thanks a lot! ahasenack athos sergiodj
[16:23] <sergiodj> mirespace: np!  let us know if you need more help :)
[16:31] <mirespace> I think I'll review with him tomorrow this
[16:31] <mirespace> sergiodj: oth, how much expert about clang are you ? 
[16:32] <sergiodj> mirespace: hmm, about clang internals?
[16:33] <mirespace> yes, compiling using clang
[16:33] <sergiodj> mirespace: ah, using clang.  what's the problem?  I haven't used it a lot but I can try to help
[16:36] <mirespace> sergiodj: oh, sorry ... I was remebering you saying something about clang in a 1:2 meeting ... anyway, my problem is a test on a cmake configure is not passing, but manually it does... and also is starnge, because if you use package clang it tries to do the test, but if you specify clang package, i.e. clang-13, it states it doen't found the compiler at all
[16:37] <mirespace> _it seems I'm hungry as I'm eating letters, sorry_
[16:37] <sergiodj> heh :)
[16:38] <sergiodj> mirespace: I'd need to see some logs showing the error, and also the d/rules snippet (I'm assuming this is happening with a package)
[16:40] <mirespace> sergiodj: You're assuming well. Ok, of course  
[16:40] <bryceh> for those (coredevs) needing to retrigger tests now that linux-firmware is in -proposed, and want to avoid manually creating URLs, this is how I'm doing it for all the php retriggers:
[16:40] <bryceh> excuses-kicker -t linux-firmware php-symfony-mercure
[16:41] <bryceh> replace the php package with whatever needs retriggered.  It does pretty good at figuring out what other -proposed packages also need triggers included, and you can add more -t's for anything it forgets
[16:42] <bryceh> (https://code.launchpad.net/~bryce/+git/excuses-kicker)
[17:35] <ahasenack> kanashiro: sergiodj is debian in hard freeze now?
[17:35] <ahasenack> """
[17:35] <ahasenack> 2022-03-12      - Milestone 3 - Hard Freeze - for key packages and
[17:35] <ahasenack>                                 packages without autopkgtests
[17:35] <ahasenack> To be announced - Milestone 4 - Full Freeze
[17:35] <ahasenack> """
[17:40] <sarnold> ahasenack: I think that was a typo
[17:43] <ahasenack> the #topic in #debian-devel says 2023
[17:43]  * ahasenack checks debian-devel-announce@!
[17:43] <sarnold> the two irc channels I saw it discussed yesterday had the general conclusion it was an off-by-one, but nothing really copy-and-pasteable, hehe
[17:44] <ahasenack> https://lists.debian.org/debian-devel-announce/2022/03/msg00006.html
[17:47] <ahasenack> looks like he sent an updated email, but to debian-devel@ only, not -announce
[17:51] <sarnold> ah!
[18:03] <ahasenack> I checked the archive and didn't see it
[18:03] <ahasenack> just a bunch of replies from people as confused as I
[18:05] <sarnold> ahasenack: https://lists.debian.org/debian-devel/2022/03/msg00251.html
[18:17] <ahasenack> thx
[18:42] <genii> Has a patch in Ubuntu been supplied yet for https://nvd.nist.gov/vuln/detail/CVE-2022-0778  ? There was an openssl update today on my Focal but new version seems 1.1.1f-1ubuntu2.12  and not 1.1.1n-some-ubuntu-string
[18:42] <ubottu> The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite lo... <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0778>
[18:43] <sarnold> genii: https://ubuntu.com/security/notices/USN-5328-1
[18:44] <genii> sarnold: So yes, patched... thanks!
[18:45] <sarnold> genii: yup :)'
[18:45] <ahasenack> update--initramfs takes *minutes* in my jammy vms... :/
[18:45] <ahasenack> 20900 root      20   0  325180 223768   2300 S  99.0  22.5   3:38.68 zstd  
[18:45] <sarnold> brutal
[18:45] <ahasenack> zstd -q -19 -T0 -c /var/tmp/mkinitramfs-MAIN_pUEGb1 <-- are those the cmd line parameters we expect?
[18:46] <ahasenack> I'm a bit lost in that initramfs compression discussion
[18:46] <ahasenack> 19 compression level?
[18:47] <sarnold> yeah that seems silly imho
[18:47] <ahasenack> initramfs.conf doesn't specify a level, just "zstd"
[18:49] <sbeattie> ahasenack: yes, same, even worse when linux-firmware and a new kernel are in your update set, so an initramfs gets rebuilt for all your old kernels plus your new one.
[18:49] <sarnold> god I hate that so much
[18:49] <ahasenack> I just installed linux-image-virtual-extra to get some extra modules (why are the quota modules in the extra package...?)
[18:49] <ahasenack> and it's still running
[18:49] <ahasenack> and it was running for minutes already before I posted here
[18:50] <sarnold> ten minutes then?
[18:50] <ahasenack> about so
[18:50] <sbeattie> ¯\_(ツ)_/¯
[18:50] <ahasenack> i7, nvme disk, virtio, etc
[18:50] <ahasenack> but 1Gb for the vm only
[18:50] <sergiodj> ahasenack: nope!  too soon for hard freeze :)
[18:50] <ahasenack> sergiodj: :)
[18:51] <ahasenack> sarnold: finished now
[18:51] <sarnold> sheeesh
[18:51] <ahasenack> that was painful
[18:51] <sarnold> I hope that's the only one that gets built for you
[18:52] <ahasenack> oh, there were 2
[18:52] <ahasenack> so maybe divide that time, 5min each
[18:52] <ahasenack> no, it only updated one initramfs
[18:52] <ahasenack> but there are two kernels installed
[18:59] <sbeattie> mmm, nice, my jammy vm somehow died in the middle of its update
[19:00] <ahasenack> new initramfs with -1 compression level is in proposed \po/
[19:00] <ahasenack> \o/*
[19:00] <ahasenack> jammy release notes: "faster kernel updates"
[19:29] <genii> sarnold: I set my bot now to announce the USN rss feed in the channel where I test things
[19:30] <sarnold> genii: woot :)
[19:30] <lotuspsychje> genii: if you like, i got a linux rss feed at #techrss
[19:31] <genii> lotuspsychje: I'm already suffering information overload lately but I'll keep it in mind
[19:31] <lotuspsychje> ok, just a proposal : )
[19:31]  * genii gets a fresh pot of coffee brewing for the channel regulars
[20:17]  * ahasenack discovers `quota` is an ubuntu server package
[20:59] <mason> ahasenack: Appears in Bullseye with a Debian maintainer as well, FWIW. Does it originate in Ubuntu or somesuch?
[21:00] <ahasenack> mason: sorry, what does?
[21:00] <mason> ahasenack: quota
[21:00] <mason> re: 16:17  * ahasenack discovers `quota` is an ubuntu server package
[21:00] <ahasenack> the ubuntu package is a sync from debian, no changes
[21:01] <mason> kk, was just curious
[21:01] <ahasenack> I meant that I found out it's the ubuntu server team who is responsible for it
[21:01] <mason> Ah!
[21:01] <ahasenack> and that surprised me, I though it would be foundations, because it's closely tied to filesystems
[21:02] <mason> I'm often surprised by the ownership of various packages at work.
[21:02] <ahasenack> I'm trying to figure out how rpc.rquotad ties into quotas when nfs is serving a glusterfs volume (!)
[21:02] <ahasenack> oh, did I mentioned clustered nfs? :)
[21:02] <mason> heh
[21:02] <ahasenack> ctdb-clustered nfs server with backing glusterfs, I'm going a bit nuts
[21:03] <mason> It looks at first glance like rpc.quotad exists for that kind of thing.
[21:03] <ahasenack> I set quotas in the gluster volume with gluster tooling, and that is respected on the client, no issues
[21:03] <ahasenack> even in the nfs client
[21:03] <mason> I'm going to guess (sans context) that rpc.quotad won't care or be impacted by the backing store.
[21:03] <ahasenack> without rpc.rquotad in the way
[21:03] <ahasenack> so I'm not yet sure what it adds to the mix
[21:03] <mason> hrm
[21:03] <ahasenack> I think it's just reporting
[21:04] <ahasenack> so that quota tools work on the client perhaps? Not sure yet
[21:04] <mason> That would make sense. Might be "apt source to the rescue"
[21:04] <ahasenack> and then I discovered ext4 has "native" quota support, without those quota files in the root of the mount point
[21:05] <ahasenack> tune2fs -O quota -Q usrquota:grpquota
[21:05] <mason> rpc.quotad also evidently sets quotas, although it might just know what knobs to spin.
[21:11] <mason> So far, xdr_getquota_rslt -> xdr_getquota_rslt -> xdr_rquota
[21:12] <mason> um, s/xdr_getquota_rslt/rquota.c/
[21:18] <ahasenack> I think it's just a way for local quota tools to extract quota information from the fs that is being exported by the nfs server, provided said nfs server is running rpc.rquotad
[21:19] <ahasenack> so the quota tools, instead of checking the local fs, where aquota.group and aquota.user reside, will do this over an rpc call
[21:19] <ahasenack> I just wonder if the quota(8) tool will try the rpc call on its own
[21:20] <ahasenack> https://pastebin.ubuntu.com/p/sFR3qyfh5B/
[21:20] <ahasenack> tomorrow I'll export that over nfs
[21:20] <ahasenack> and see what quota(1) tells me on the nfs client side
[21:20] <ahasenack> with and without rpc.rquotad running on the server
[21:21] <ahasenack> cya, have a nice evening all
[21:23] <sergiodj> cya ahasenack
[21:25] <mason> o/
[21:31]  * kanashiro waves
[21:38] <bryceh> I think something may still be wrong with some of the autopkgtest hw.  arm64 specifically seems maybe returning failures where there should be none.  Not sure what's wrong with it.