| jarnos | cjwatson, here is the ppa: https://launchpad.net/~jarnos/+archive/ubuntu/ppa-purge though apt update fails after you add it due to some signing issue. | 00:06 |
|---|---|---|
| cjwatson | jarnos: If you only just created it, give it a little bit - it takes a short while for some of the signing bits of entirely new PPAs to be generated. | 00:07 |
| cjwatson | You can see on https://launchpad.net/~jarnos/+archive/ubuntu/ppa-purge/+packages that your upload hasn't been published yet, so wait for that | 00:09 |
| jarnos | cjwatson, oh, I do not quite understand what is the meaning for the "Publish" setting in "Change details" dialog of the ppa. Currently I have it disabled. | 00:16 |
| cjwatson | jarnos: Why would you disable that? | 00:19 |
| cjwatson | I mean, it's on by default and you manually turned it off - why fiddle with a setting you don't understand? | 00:20 |
| cjwatson | It also says what it means in language that I think is fairly clear: "Whether or not to update the apt repository. If disabled, nothing will be published. If the archive is private then additionally no builds will be dispatched." | 00:21 |
| cjwatson | So if you want your uploads to be visible in an apt repository (as it sounds like you do), you need to turn it back on | 00:22 |
| jarnos | cjwatson, oh, it is on by default. I do not remember anymore, maybe because I created the ppa page, but was not able to create or upload packages. I also tried to change the setting, but it did not help right away. But as you said, I'll have to give it time to publish. | 00:23 |
| mwhudson | cjwatson: seeing as you are here, any idea when launchpad-buildd will be rolled out? | 00:24 |
| cjwatson | mwhudson: It's in IS's hands. https://portal.admin.canonical.com/C122831 | 00:25 |
| mwhudson | cjwatson: thanks | 00:25 |
| jarnos | cjwatson, apparently the setting does not affect to the visibility of the ppa in https://launchpad.net/ubuntu/+ppas?name_filter=ppa-purge | 00:26 |
| cjwatson | jarnos: Probably because you've never actually allowed Launchpad to publish packages there (the "publish" flag still appears to be off) so the PPA is empty. It shows up if you select "Including descriptions of empty PPAs" | 00:28 |
| cjwatson | jarnos: Oh, you mean that it doesn't make it invisible if you turn it off? | 00:28 |
| jarnos | cjwatson, something like that | 00:29 |
| cjwatson | jarnos: Right, so now that I look, a pending publication is enough to make the PPA search consider it non-empty. *shrug* | 00:29 |
| cjwatson | jarnos: Disabling the "Enabled" flag would make it invisible in the PPA search. But alternatively you could just check "Publish" and let it sort itself out ... | 00:31 |
| cjwatson | (Which will take a short while - publishing is a cron job that cycles through all PPAs that have changed since the last time) | 00:32 |
| jarnos | ok, I have enabled the flag. | 00:34 |
| jarnos | cjwatson, BTW. the I want to publish the ppa for many distributions, not just bionic. I suppose it can be done at https://launchpad.net/~jarnos/+archive/ubuntu/ppa-purge/+copy-packages | 00:39 |
| jarnos | cjwatson, ppa-purge is a shell script so maybe "Rebuild the copied sources" would do or is the other option better? I also had to do some settings in debian/compat and debian/control files that might restrict which distribution can be used, right? | 00:43 |
| jarnos | I had to put only "bionic" in the changelog, though, because otherwise I got some error when building. | 00:46 |
| jarnos | cjwatson, the publishing went fine for the bionic distribution. I copied it to some other distributions using "Copy existing binaries" option and will see, if they succeed, too. | 01:00 |
| === alan_g is now known as alan_g_ | ||
| === mfo_ is now known as mfo | ||
| === mdeslaur_ is now known as mdeslaur | ||
| === ricab is now known as ricab|lunch | ||
| cpaelzer | rafaeldtinoco: http://autopkgtest.ubuntu.com/packages/d/debci/bionic/armhf is odd | 13:25 |
| cpaelzer | rafaeldtinoco: it seems to ahve failed for about always and I'm sure a badtest is in place | 13:25 |
| * rafaeldtinoco checks | 13:25 | |
| cpaelzer | it is in place | 13:25 |
| cpaelzer | I guess something (tm) failed and made it detect the version as "unknown" | 13:26 |
| cpaelzer | since the badtest is only for 1.7.1 it didn't detect that | 13:26 |
| cpaelzer | I have restarted it | 13:26 |
| cpaelzer | hopefully it detects 1.7.1 properly and will then handle it as badtest as expected | 13:26 |
| rafaeldtinoco | but if it was already as bad test | 13:27 |
| rafaeldtinoco | why would it have failed before ? | 13:28 |
| rafaeldtinoco | 2019-11-15 18:06:33 UTC | 13:28 |
| rafaeldtinoco | for example ? | 13:28 |
| cpaelzer | rafaeldtinoco: result => fail, but badtest let it pass | 13:28 |
| rafaeldtinoco | gotcha | 13:28 |
| === ricab|lunch is now known as ricab | ||
| teward | cjwatson: raysession for Studio is still returning lintian fail on source-contains-unsafe-symlink in policy, which suggests that just putting in the .links file is not enough to 'solve' the core issue. Not sure what to do about that one, or whether we should handwave that for upload inclusion. It'll take another point release upstream for them to actually fix the unsafe symlink issue in the source code. | 14:58 |
| cjwatson | It should not be handwaved. Somebody should actually debug it | 14:58 |
| teward | cjwatson: that's what i thought. we know the cause though | 14:59 |
| teward | Upstream has a hardcoded link in 0.8.2 | 14:59 |
| cjwatson | It doesn't require an upstream release | 14:59 |
| cjwatson | I mean obviously that's ideal but it's not a requirement | 14:59 |
| === SuperKaramba is now known as BenderRodriguez | ||
| cjwatson | I gave a collection of possible tools you (plural) could use to deal with it | 14:59 |
| cjwatson | .links was just one of them | 14:59 |
| teward | you mean Eickmeyer can use :P | 14:59 |
| teward | Eickmeyer's the one managing this | 14:59 |
| cjwatson | Not my problem to assign work :) | 14:59 |
| teward | so I'm assuming then that this is NACKed then :P | 14:59 |
| teward | Eickmeyer: ^ NACK on the upload request until we *really* dig into this and fix it. Or upstream fixes it :P | 15:00 |
| cjwatson | Not that I'm particularly authoritative, but I would nack that, yes | 15:00 |
| teward | right now i walked into the workplace and discovered a literal ton of email evils I have to fix | 15:00 |
| teward | looks like the mail gateways stopped filtering spam :? | 15:00 |
| teward | (Bypass mode anyone? >.>) | 15:00 |
| rafaeldtinoco | cpaelzer: im finishing up ndctl "testcase" for the sru template | 15:05 |
| rafaeldtinoco | not sure if I can reproduce | 15:05 |
| rafaeldtinoco | i *think* recent qemus changed place where virtual nvdimm labels are placed, unsure if bug can be reproduced, will give a try a little bit more | 15:05 |
| rafaeldtinoco | best would be to have the user to verify :\ | 15:06 |
| cpaelzer | rafaeldtinoco: you mean new qemu will have it working while the bug as reported against xx ? | 15:10 |
| cpaelzer | old HW or old qemu? | 15:10 |
| rafaeldtinoco | cpaelzer: im trying to find out that, but, yes | 15:10 |
| rafaeldtinoco | QEMU v2.7.0 and later implement the label support for vNVDIMM devices. | 15:11 |
| cpaelzer | if we can't get it happen to us then sponsoring to the SRU queue should wait until the reporter checked the affected HW with the PPAs | 15:11 |
| rafaeldtinoco | basically im trying to have a label-size as big as 256k, that would trigger the error in some kernels afaik. | 15:11 |
| cpaelzer | I'd not want to bother the SRU team with an issue we can't confir on our side | 15:11 |
| rafaeldtinoco | cpaelzer: +1 on that | 15:11 |
| rafaeldtinoco | im not super confident if they can't say it fixed the issue | 15:11 |
| cpaelzer | ok, let me know later on how these tests turned out | 15:11 |
| rafaeldtinoco | and its not *that* important | 15:11 |
| cpaelzer | ack, you are free to require some participation of the reporter - especially for a universe package that you just want to kindly fix while coming along | 15:12 |
| rafaeldtinoco | failed to create namespace: Inappropriate ioctl for device | 15:13 |
| rafaeldtinoco | alright | 15:13 |
| rafaeldtinoco | its 3 bug in one | 15:13 |
| rafaeldtinoco | i can reproduce this one ^ | 15:13 |
| rafaeldtinoco | :o) | 15:13 |
| rafaeldtinoco | will comment in case after lunch, bbs | 15:13 |
| Eickmeyer | teward, cjwatson: Upstream fixed, will be working on this later. | 15:27 |
| cjwatson | Eickmeyer,teward: FYI the .links approach would have worked fine if you'd got the arguments the right way round. | 15:34 |
| cjwatson | Eickmeyer,teward: https://paste.ubuntu.com/p/hTvsCJ9dnD/ | 15:34 |
| teward | heh, indeed | 15:35 |
| cjwatson | (I ran the build with DH_VERBOSE=1, peered at the output for 10s or so, and it became clear) | 15:35 |
| teward | pushed that alteration, thanks cjwatson. Hopefully lintian won't explode this time :) | 15:37 |
| Eickmeyer | cjwatson: Cool. Though, probably all for not, upstream fixed the problem and did a 0.8.3 release. | 15:38 |
| cjwatson | Education for next time :) | 15:38 |
| teward | cjwatson: fun fact though... | 15:39 |
| teward | even with that change, it still triggers the same source-contains-unsafe-symlink Lintian error against the source package | 15:39 |
| Eickmeyer | cjwatson: Indeed. I'll pull what you've got and see what you did, because education is FUNdamental (tm). | 15:39 |
| teward | so while there's no issue in the generated binaries, it errors with source pkg's src/bin/ray_control because *that* symlink is still bad | 15:40 |
| teward | (in the orig tarball) | 15:40 |
| teward | at least AFAICT | 15:40 |
| Eickmeyer | Yes, that's exactly what I was running into as well. | 15:40 |
| teward | but since 0.8.3 was released and contains a fix, i'll wait for that | 15:40 |
| teward | then we can strip the .links file out and then make sure everything works | 15:40 |
| cjwatson | teward: If it were necessary to upload this before 0.8.3, then the source package error could be ignored | 15:42 |
| cjwatson | It's tolerable as long as the binary is correct | 15:42 |
| cjwatson | (It's still not great because the source package might do weird things if unpacked on some systems.) | 15:44 |
| Odd_Bloke | I just ran `ubuntu-bug /var/crash/...` for a focal crash I saw. I didn't get redirected to a Launchpad page (as `ubuntu-bug` does under normal/other operation), is that expected? If so, what should I expect to happen next? | 18:05 |
| === infinity1 is now known as infinity | ||
| rbasak | Is urgent action needed on bug 1853614? | 18:44 |
| ubottu | bug 1853614 in amd64-microcode (Ubuntu) "System stuck in reboot loop on AMD EPYC 7542 32-Core Processor" [Undecided,Confirmed] https://launchpad.net/bugs/1853614 | 18:44 |
| rbasak | I'm not sure how we handle microcode regressoins. | 18:44 |
| tjaalton | tyhicks: ^ | 19:10 |
| sarnold | tyhicks is out this week; as is sbeattie. we've only ever reverted a cpu microcode update in the past when intel asked us to. we don't know what issues are fixed or mitigated in this update nor what is broken. | 19:13 |
| infinity | sarnold: Given the "me toos" on the bug, seems pretty clear that (at least) the EPYC 7xxx series is just entirely broken by the update. | 19:36 |
| infinity | Do we have contacts at AMD to escalate to? | 19:37 |
| sarnold | infinity: I'm not sure; I've emailed the firmware uploader and amd's psirt team, hopefully they'll know someone who has some idea what's in that update | 19:37 |
| infinity | sarnold: I mean, even if we don't know what's in it, while "can't boot" is the most secure state of all, I'm pretty sure "can boot, but has some bugs" is more appealing to customers. :P | 19:38 |
| === led_dark_2 is now known as led_dark_1 | ||
| seb128 | hum, one autopkgtest question for the channel | 19:56 |
| seb128 | http://autopkgtest.ubuntu.com/packages/c/chiark-tcl/focal/amd64 | 19:56 |
| seb128 | the test use 'Restrictions: skip-not-installable' | 19:56 |
| seb128 | which I guess leads to the result being a code | 19:57 |
| seb128 | but then https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#tcl8.6 considers those as a fail | 19:57 |
| seb128 | what component is to blame? | 19:58 |
| seb128 | autopkgtest to return the wrong result? | 19:58 |
| seb128 | Laney, vorlon, juliank, ^ one of you might know? | 19:58 |
| juliank | I guess britney needs to learn about exit code 14, like it does for other exit codes | 20:02 |
| juliank | # allow some skipped tests, but nothing else | 20:02 |
| juliank | passed = exitcode in [0, 2, 8] | 20:02 |
| juliank | needs 14 in it | 20:02 |
| juliank | OTOH, 14 is listed as 14 erroneous package and at least one test skipped | 20:03 |
| juliank | seb128: There is a crypto--def FAIL badpkg | 20:03 |
| juliank | hence it's 14 | 20:03 |
| seb128 | juliank, ah, thanks | 20:04 |
| Odd_Bloke | Reupping my earlier question (with a different tool used): if I run `apport-cli /var/crash/_usr_bin_neomutt.1000.crash` and select send report, I get a bunch of dots on screen and then the program exits with no further output. Should I be being directed to a Launchpad bug report form, or is this expected behaviour? If this is the expected behaviour, how can I find out what happened to my crash report? | 20:58 |
| rbasak | Ah | 20:58 |
| rbasak | I do know the answer to that I think ;) | 20:58 |
| rbasak | Normally it uploads to LP and then you get a unique URL to go to to finish the report in the web UI | 20:59 |
| rbasak | And it also tries to open the URL using xdg-open or similar. | 20:59 |
| rbasak | Is it possible that your XDG link opening is broken? | 20:59 |
| rbasak | Does "xdg-open https://www.ubuntu.com" work | 21:00 |
| rbasak | ? | 21:00 |
| juliank | hmm standard monospace rendering seems broken, at least in gedit, it renders underscores as spaces | 21:00 |
| mwhudson | Odd_Bloke, rbasak: it should print the url too i think | 21:00 |
| rbasak | Yes but I'm wondering if it does that before or after attempting the XDG open | 21:01 |
| rbasak | If before, and that crashes, then that might explain this behaviour | 21:01 |
| mwhudson | i thought before, as in it prints the url then asks you if you want it to open the link\ | 21:01 |
| mwhudson | but let me check | 21:01 |
| Odd_Bloke | xdg-open is working fine. | 21:02 |
| mwhudson | Odd_Bloke: this is the output i get https://paste.ubuntu.com/p/tPGRK5bkYg/ | 21:02 |
| mwhudson | Odd_Bloke: can you pastebin yours? | 21:02 |
| Odd_Bloke | mwhudson: This time it just exited after I pressed "s". | 21:05 |
| mwhudson | Odd_Bloke: nice | 21:06 |
| Odd_Bloke | https://paste.ubuntu.com/p/9VwdCfrMsv/ | 21:06 |
| mwhudson | Odd_Bloke: $? | 21:06 |
| Odd_Bloke | mwhudson: Prompt. | 21:08 |
| mwhudson | Odd_Bloke: sorry i mean, is it exiting with code 0 or something else? | 21:21 |
| infinity | Odd_Bloke: Is this on a stable or devel release? | 21:32 |
| infinity | Or focal, which is still in stable mode... | 21:33 |
| Odd_Bloke | This is on focal, and it's exiting 0. | 21:33 |
| infinity | Pretty sure this behaviour is by design. | 21:34 |
| infinity | bdmurray: Say, should we make apport's bug reporting behaviour be based on distro-info telling us if we're stable or devel, instead of having to manually flip it around? | 21:35 |
| infinity | Odd_Bloke: OOI, try reverting the last hunk of http://launchpadlibrarian.net/446044154/apport_2.20.11-0ubuntu7_2.20.11-0ubuntu8.diff.gz and see if it behaves in a way you expect. | 21:35 |
| Odd_Bloke | infinity: Yep, that lets me go through the full flow I would expect. | 21:40 |
| bdmurray | infinity: Martin previously had opinions about enabling apport later on in the devel cycle and turning it off early but I think that's outdated and using distro-info might be better. | 21:58 |
| infinity | bdmurray: Well, one could use distro-info-data and parse the actual dates. | 22:01 |
| infinity | bdmurray: If we wanted to, say, delay by two weeks to allow the first auto-sync to settle, or whatever. | 22:01 |
| infinity | Although, one can synthesize that with distro-info too, by asking it about future/past dates. Which is probably the "correct" way. | 22:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!