[00:36] <mwhudson> cjwatson: is there a reason the parted build does not run the testsuite? seems it's been that way since 3.1-1 in 2014 but no mention of it in changelog
[00:40] <mwhudson> oh no, it's from before that
[00:46] <mwhudson> uh maybe the testsuite has never been run on build
[00:49] <mwhudson> i guess lots of them need root, maybe more appropriate as an autopkgtest
[00:51] <sarnold> yikes
[00:55] <mwhudson> yeah, pretty much
[02:02] <mwhudson> # FAIL:  9
[08:28] <cjwatson> mwhudson: 3.1-1 didn't change that, which is why it's not mentioned - that was just the dh conversion
[08:29] <cjwatson> mwhudson: Quite a few tests do work as non-root, so it's probably worth improving
[08:54] <mwhudson> cjwatson: of course when i add an autopkgtest to run the tests, a bunch of them fail
[08:54] <mwhudson> some for trivial reasons, some not
[08:55] <cjwatson> There's a bug in an fdasd patch which I just fixed on master
[08:56] <mwhudson> cjwatson: is that the one where vorser.c isn't added?
[08:56] <cjwatson> yes
[08:56] <mwhudson> great
[08:56] <mwhudson> the parted upstream git history is very confusing arond that
[08:56] <mwhudson> cjwatson: when you say 'master' you mean on salsa?
[08:56] <cjwatson> Two upstream patches with near-identical commit messages because upstream screwed up applying it the first time round
[08:57] <cjwatson> Yes
[08:57] <mwhudson> yeah
[08:57] <mwhudson> cool
[09:00] <mwhudson> cjwatson: fwiw my d/tests/control looks like this
[09:01] <mwhudson> https://paste.ubuntu.com/p/Mjm3hfnnNs/
[09:01] <mwhudson> cjwatson: all this interest came up because of https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1828558 fwiw
[09:01] <ubottu> Launchpad bug 1828558 in ubiquity (Ubuntu) "installing ubuntu on a former md raid volume makes system unusable" [Undecided,New]
[09:01] <cjwatson> bet you need at least dmidecode [amd64 i386] and udev [linux-any] at the moment too, although I'm adding those to Build-Depends in my current WIP
[09:02] <mwhudson> cjwatson: the tldr of which is that parted mklabel doesn't wipe mdraid 0.90 metadata
[09:02] <cjwatson> or we need to work out how to disable dmidecode for this because it isn't going to go well ...
[09:02] <mwhudson> cjwatson: flipflopping about doing something clever with libblkid or just hacking ped_disk_clobber to wipe bigger chunks of the disk
[09:03] <mwhudson> er can you have an ubuntu system without udev?
[09:03] <cjwatson> it's not build-essential
[09:03] <mwhudson> i suppose containers
[09:03] <cjwatson> mwhudson: partman-md already does mdadm --zero-superblock, so why doesn't ubiquity?
[09:03] <infinity> ^
[09:04] <infinity> I thought we decided that was the right answer.
[09:04] <mwhudson> cjwatson: is mdadm even there?
[09:04] <mwhudson> in the environment ubiquity runs in
[09:04] <cjwatson> maybe not
[09:04] <infinity> Asking any other tool to know where mdadm puts its superblocks is daft.
[09:04] <mwhudson> if so, that would probably be better
[09:04] <cjwatson> it could depend on it, if it doesn't already
[09:04] <infinity> Given that it has many different options.
[09:05] <mwhudson> i also couldn't really figure out where to jam the zero-superblock call
[09:05] <infinity> Front, middle, end, sort-of-front-but-not-quite, etc.
[09:05] <cjwatson> mwhudson: I don't think it would be wrong for ped_disk_clobber to put more effort into zeroing superblocks, maybe, but it should go via upstream
[09:05] <mwhudson> cjwatson: yeah that too
[09:06] <cjwatson> I mean it's certainly trying to, as you say
[09:06] <mwhudson> http://paste.ubuntu.com/p/JT4drXBX8r/ <- output from running that d/tests/control
[09:08] <mwhudson> some of the failures appear to be device nodes for partitions not showing up
[09:10]  * cjwatson gives up on trying to run it as non-root, too annoying
[09:16] <cjwatson> the tiny gpt test segfault looks worth tracking down
[09:20] <mwhudson> i found another segfault like that
[09:20] <mwhudson> https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1817267
[09:20] <ubottu> Launchpad bug 1817267 in parted (Ubuntu) "trying to name a partition on a device with no partition table crashes" [Undecided,New]
[09:21] <mwhudson> today has been quite the sausage factory experience
[09:23] <mwhudson> i tried to file a bug
[09:28] <cjwatson> upstream is theoretically in the process of releasing 3.3, which might be a more rewarding baseline
[09:29] <cjwatson> 3.2 is really crusty :(
[09:31] <mwhudson> yeah i noticed the pattern of many commits being cherrypicked into the package
[09:57] <mwhudson> ah apparently i successfully filed a bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853
[10:14] <marcoagpinto> mwhudson: could you explain to me what is "cherrypick"?
[10:15] <marcoagpinto> I notice it when I commit things to Gerrit using the browser
[10:23] <enyc> LocutusOfBorg: hrrm spotting this https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1803132
[10:23] <ubottu> Launchpad bug 1803132 in virtualbox (Ubuntu) "virtualbox 0day exploit" [Undecided,New]
[10:23] <cjwatson> marcoagpinto: https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Patching
[10:27] <marcoagpinto> ohhhhh
[10:27] <LocutusOfBorg> enyc, fixed with later releases
[10:27] <marcoagpinto> Buaaa
[10:27] <marcoagpinto> :(
[10:28] <marcoagpinto> it doesn't explain anything
[10:34] <cjwatson> I don't know how to explain it better than that.  You probably need to have at least a certain amount of git mental model first ...
[10:36] <rafaeldtinoco> morning o/
[10:36] <rafaeldtinoco> rbasak: i was able to make mysql8 <-> dbconfig <-> cacti to work
[10:36] <rafaeldtinoco> im finishing up an idea I had (setting $dbc_authplugin) as a debconf param
[10:37] <rafaeldtinoco> this way pkg using dbconfig-mysql is able to set auth plugin, and "default" does not set it
[10:37] <rafaeldtinoco> will finish up patches and push it
[10:40] <rbasak> rafaeldtinoco: nice, thanks!
=== not_phunyguy is now known as phunyguy
[11:41] <enyc> LocutusOfBorg: i know, but oint bein that is asother support of updating
[13:54] <rbasak> TIL: the Debian buildds invoke an entirely separate build for Arch: all, rather than doing it at the same time as one of the "any" architectures. That confused me for a while.
[13:56] <cjwatson> I never got a satisfactory explanation for that approach
[13:57] <cjwatson> (Despite talking to the person who set it up, more or less at the time)
[13:58] <rbasak> It might expose a different set of subtle packaging bugs, but I can't see that there's any reason to choose that set from our set.
[13:59] <rbasak> Today it just mean that I had to discover sbuild's --no-arch-any option to verify that there wasn't a subtle packaging bug causing the FTBFS for Ubuntu but not Debian (there wan't).
[14:00]  * rbasak needs to type harder
[14:42] <ahasenack> ok, dh_installman doesn't support [arch] flags in d/foo.manpages
[14:43] <ahasenack> should I work harder to fix this:
[14:43] <ahasenack> debian/pmdk-tools.install:[amd64] usr/bin/rpmemd
[14:43] <ahasenack> debian/pmdk-tools.manpages:doc/generated/rpmemd.1
[14:43] <ahasenack> i.e., one of the binaries isn't built in non-amd64. Should I work hard to not install the manpage in that case?
[14:43] <ahasenack> it came like this from debian
[14:45] <cjwatson> ahasenack: you could do that with dh-exec
[14:45] <ahasenack> remove this manpage from pmdk-tools.manpages, install it conditionally in pmdk-tools.install?
[14:45] <ahasenack> I don't think I get the free gzipped version then, do I?
[14:46] <cjwatson> #! /usr/bin/dh-exec at the top of debian/pmdk-tools.manpages, chmod +x debian/pmdk-tools.manpages, [amd64] at the start of that line in debian/pmdk-tools.manpages, Build-Depends: dh-exec
[14:46] <rbasak> I would spend the effort filing a bug against dh_installman and then forgetting about it :)
[14:46] <cjwatson> should work
[14:46] <rbasak> Or what Colin said
[14:46] <cjwatson> in fact I don't think dh_install supports architecture filtering directly either?
[14:46] <ahasenack> a foo.manpages can use dh-exec? I thought that was only for *.install files
[14:46] <cjwatson> so the package must already be using dh-exec
[14:47] <ahasenack> cjwatson: correct, the install file is using dh-exec already
[14:47] <cjwatson> I wouldn't file a bug on dh_installman for this because the settled answer is to use dh-exec for this kind of thing
[14:47] <rbasak> I didn't realise dh-exec had an arch filter feature
[14:47] <cjwatson> Unless it doesn't work for dh_installman for some reason, but try it
[14:48] <ahasenack> will try
[14:48] <ahasenack> :q
[14:48] <ahasenack> ops
[14:57] <ahasenack> hm, got a globbing error now, in another manpage of that same file
[14:58]  * ahasenack investigates
[16:37] <ahasenack> does anybody know where I can see the dep8 results for squid 4.8-1 in debian? The tracker says it was accepted into unstable: https://tracker.debian.org/pkg/squid
=== rsalveti_ is now known as rsalveti
=== davidkrauser_ is now known as davidkrauser
[16:56] <rbasak> ahasenack: https://ci.debian.net/packages/s/squid/unstable/amd64/ - linked to from the tracker under "debci"
[16:57] <nacc> i believe 4.8 was maybe manually uploaded
[16:57] <nacc> so it doesn't go through CI
[16:57] <nacc> 'not built on buildd'
[16:57] <rbasak> Oh, I see. Sorry.
[16:57] <nacc> https://tracker.debian.org/news/1046100/accepted-squid-48-1-source-amd64-all-into-unstable/
[16:58] <nacc> it's not clear to me, tbh; just seems a bit weird
[16:59] <ahasenack> <nacc> so it doesn't go through CI
[16:59] <ahasenack> wat?
[16:59] <ahasenack> what's a "manual upload", and why does it skip testing? Feature or loophole?
[17:00] <tumbleweed> a manual upload is a binary upload, built on the developer's machine
[17:00] <ahasenack> wow
[17:00] <ahasenack> ok
[17:00] <ahasenack> I had no idea this was possible
[17:00] <tumbleweed> debian is trying to get away from those, thus blocking testing migration
[17:01] <nacc> I'm not sure it bypasses testing, but if you mean the build-time tests, they obviously aren't run in a binary upload :)
[17:01] <ahasenack> I'm after the dep8 results, because this upload has a change in that area that I don't understand
[17:02] <ahasenack> and I wanted to check what happened in debian ci with that change
[17:03] <tumbleweed> yeah, it simply hasn't run, yet. presumably because fo the binary upload
[17:07] <Laney> I don't know if it is actually implemented, but you can see on tracker.d.o that this upload is not going to migrate
[17:07] <Laney> so you could argue that ci.d.n not running it is correct
[17:08] <tumbleweed> I assume britney is triggering the builds, and britney knows it won't migrate
[17:08] <tumbleweed> (there are also cron-triggered builds, that may eventually happen here)
[17:08] <Laney> it could happen like that
[17:08] <Laney> I'm not sure if it does, but it could
[17:08] <tumbleweed> I'd ask ivodd, but he's off wondering the island somewhere
[17:08] <Laney> britney has 'policies' and they can check the outcomes of the ones that ran before
[17:09] <Laney> so if it's like "were there manual uploads?" "run any autopkgtests", the second part could check if the first part had already vetoed the upload
[17:09] <Laney> that is called REJECTED_PERMENANTLY in britney terminology
[17:18] <ahasenack> Laney: how can you tell squid 4.8-1 won't migrate, and why?
[17:19] <Laney> ahasenack: https://tracker.debian.org/pkg/squid in the middle there
[17:19] <ahasenack> ah
[17:19] <ahasenack> not build on buildd, not considered
[17:19] <ahasenack> the former being the reason why it's not considered? it was a binary upload?
[17:22] <Laney> yeah I'm not actually sure, but maybe
[17:22] <Laney> if you're interested in finding out if that's true, suggest stopping by #debci and asking in there
[17:22] <Laney> or reading the britney code :p
[17:24]  * Laney is uploading some self built binaries to Debian right now, as it happens (still have to do that for the NEW queue)
[22:37] <mwhudson> cjwatson: parted upstream said no to more wiping, btw: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853
[22:43] <cjwatson> OK