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:36 |
---|---|---|
mwhudson | oh no, it's from before that | 00:40 |
mwhudson | uh maybe the testsuite has never been run on build | 00:46 |
mwhudson | i guess lots of them need root, maybe more appropriate as an autopkgtest | 00:49 |
sarnold | yikes | 00:51 |
mwhudson | yeah, pretty much | 00:55 |
mwhudson | # FAIL: 9 | 02:02 |
cjwatson | mwhudson: 3.1-1 didn't change that, which is why it's not mentioned - that was just the dh conversion | 08:28 |
cjwatson | mwhudson: Quite a few tests do work as non-root, so it's probably worth improving | 08:29 |
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:54 |
cjwatson | There's a bug in an fdasd patch which I just fixed on master | 08:55 |
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:56 |
cjwatson | Yes | 08:57 |
mwhudson | yeah | 08:57 |
mwhudson | cool | 08:57 |
mwhudson | cjwatson: fwiw my d/tests/control looks like this | 09:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
mwhudson | some of the failures appear to be device nodes for partitions not showing up | 09:08 |
* cjwatson gives up on trying to run it as non-root, too annoying | 09:10 | |
cjwatson | the tiny gpt test segfault looks worth tracking down | 09:16 |
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:20 |
mwhudson | today has been quite the sausage factory experience | 09:21 |
mwhudson | i tried to file a bug | 09:23 |
cjwatson | upstream is theoretically in the process of releasing 3.3, which might be a more rewarding baseline | 09:28 |
cjwatson | 3.2 is really crusty :( | 09:29 |
mwhudson | yeah i noticed the pattern of many commits being cherrypicked into the package | 09:31 |
mwhudson | ah apparently i successfully filed a bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853 | 09:57 |
marcoagpinto | mwhudson: could you explain to me what is "cherrypick"? | 10:14 |
marcoagpinto | I notice it when I commit things to Gerrit using the browser | 10:15 |
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:23 |
marcoagpinto | ohhhhh | 10:27 |
LocutusOfBorg | enyc, fixed with later releases | 10:27 |
marcoagpinto | Buaaa | 10:27 |
marcoagpinto | :( | 10:27 |
marcoagpinto | it doesn't explain anything | 10:28 |
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:34 |
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:36 |
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:37 |
rbasak | rafaeldtinoco: nice, thanks! | 10:40 |
=== not_phunyguy is now known as phunyguy | ||
enyc | LocutusOfBorg: i know, but oint bein that is asother support of updating | 11:41 |
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:54 |
cjwatson | I never got a satisfactory explanation for that approach | 13:56 |
cjwatson | (Despite talking to the person who set it up, more or less at the time) | 13:57 |
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:58 |
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). | 13:59 |
* rbasak needs to type harder | 14:00 | |
ahasenack | ok, dh_installman doesn't support [arch] flags in d/foo.manpages | 14:42 |
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:43 |
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:45 |
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:46 |
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:47 |
ahasenack | will try | 14:48 |
ahasenack | :q | 14:48 |
ahasenack | ops | 14:48 |
ahasenack | hm, got a globbing error now, in another manpage of that same file | 14:57 |
* ahasenack investigates | 14:58 | |
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 | 16:37 |
=== rsalveti_ is now known as rsalveti | ||
=== davidkrauser_ is now known as davidkrauser | ||
rbasak | ahasenack: https://ci.debian.net/packages/s/squid/unstable/amd64/ - linked to from the tracker under "debci" | 16:56 |
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:57 |
nacc | it's not clear to me, tbh; just seems a bit weird | 16:58 |
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? | 16:59 |
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:00 |
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:01 |
ahasenack | and I wanted to check what happened in debian ci with that change | 17:02 |
tumbleweed | yeah, it simply hasn't run, yet. presumably because fo the binary upload | 17:03 |
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:07 |
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:08 |
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:09 |
ahasenack | Laney: how can you tell squid 4.8-1 won't migrate, and why? | 17:18 |
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:19 |
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:22 |
* Laney is uploading some self built binaries to Debian right now, as it happens (still have to do that for the NEW queue) | 17:24 | |
mwhudson | cjwatson: parted upstream said no to more wiping, btw: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36853 | 22:37 |
cjwatson | OK | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!