| xnox | i managed to trace some of them to Keybuk! | 00:58 |
|---|---|---|
| xnox | and understand some other bits | 00:58 |
| xnox | many are still quite a puzzle | 00:58 |
| vicamo | hi, anyone has some time to help upload https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 to focal? | 08:49 |
| vicamo | this contains fix for https://launchpad.net/bugs/1855825, current in -proposed kernel may cause all systems using backport-iwlwifi dkms to hang at connecting to WiFi base stations | 08:50 |
| ubottu | Launchpad bug 1855825 in backport-iwlwifi-dkms (Ubuntu Focal) "When connecting to wifi with the proposed linux-oem kernel , the system hangs" [Critical,In progress] | 08:50 |
| vicamo | this is quite critical actually | 08:51 |
| vicamo | hi, anyone has some time to help upload https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1855825 to focal? | 11:23 |
| cpaelzer | rbalint: the patch that you asked only has 2 chunks left that we need for current master | 12:43 |
| cpaelzer | rbalint: submitted as https://github.com/systemd/systemd/pull/14323 | 12:43 |
| seb128 | vicamo, hey, I sponsored your iwl fix now, I just changed the priority back to normal since I don't think that change anything for Ubuntu uploads, also would probably be good to get it reviewed/merged upstream before doing the SRU | 12:52 |
| vicamo | seb128: thank you | 13:01 |
| rbalint | cpaelzer, thanks! | 13:48 |
| cpaelzer | np | 13:49 |
| cpaelzer | if you have any eta on a 244 upload that would be great | 13:49 |
| cpaelzer | not like "please let it be asap" but like "I wonder when it would happen" | 13:49 |
| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| doko | seb128: I see you touched unity-gtk-module to port from py2 to py3 ... are you working on autopilot portage to python3? asking because foundations thinks it should be just removed | 16:57 |
| ahasenack | rbasak: in debian one can file bugs against binary packages, right? What is the best form? In my case, the bug is in the "Depends" of a binary package, but that is of course fixed in the source's d/control | 17:25 |
| ahasenack | in other words, is filing bugs against binary packages just something to help beginners? | 17:25 |
| rbasak | No filing bugs against binary packages is the norm in Debian | 17:27 |
| rbasak | It's a little more granular | 17:27 |
| rbasak | I would file against the binary package that has the problem Depends line | 17:27 |
| rbasak | And usually I only file against a source package if there is no obvious binary package to file it against | 17:27 |
| xnox | ahasenack: all my life i've been filing bugs against source packages only and nobody ever tried to reassign them from source to binary, and vice versa, or tell me off to file agains binary or source package | 17:28 |
| xnox | apart from how bugs.debian.org renders things, it makes no difference for closing them, or operating them by mail =) | 17:28 |
| ahasenack | I prever against the source too, it always annoys me when searching for debian bugs that I have to remember and search for bugs against the binary packages | 17:29 |
| xnox | well, one can search against source package too, it then renders _all_ bugs for source and all of its binaries | 17:30 |
| ahasenack | doesn't it just list the binary package names at the top and you have to click through them? | 17:31 |
| cjwatson | No if you go to e.g. bugs.debian.org/src:groff then it aggregates them all | 17:31 |
| ahasenack | "you might also want to look for bugs in ....." something like that | 17:31 |
| xnox | ie. https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=boost1.67 | 17:31 |
| xnox | ahasenack: yes, that english can be misunderstood, it's subfiltered pages | 17:32 |
| xnox | strict subsets | 17:32 |
| ahasenack | ah, I see | 17:32 |
| ahasenack | thanks, saves me some time and removes the annoyance :) | 17:32 |
| seb128 | doko, no, I'm not, autopilot or autopilot-legacy? | 17:32 |
| seb128 | doko, I didn't suggest removing because I'm not sure it's not used in the daily iso automated testing job/jenkins, should check with jibel before doing anything | 17:33 |
| * xnox ponders to name next project i create one of: autopilot.io autopilot.ng autopilot autopilot-classic autopilot-legacy | 17:33 | |
| xnox | seb128: ubiquity might still be using it! | 17:34 |
| seb128 | xnox, could be yes :) | 17:34 |
| * ahasenack hrms landscape used to have an autopilot | 17:35 | |
| xnox | seb128: i see it is using python3-autopilot | 17:35 |
| xnox | ahasenack: that's a different product, from us, also called autopilot | 17:35 |
| xnox | there is juju/openstack autopilot, there is landscape autopilot, and a11y testing framework autopilot | 17:35 |
| ahasenack | I just still twitch when I read "autopilot" in an ubuntu channel | 17:37 |
| Laney | core | 17:38 |
| juliank | xnox: it's not just canonical, though, eh? - tesla also has one of these | 17:48 |
| juliank | I heard that even planes have those things | 17:49 |
| rafaeldtinoco | andersk: so | 18:29 |
| ahasenack | ahasenack | 18:29 |
| rafaeldtinoco | andersk: sorry | 18:29 |
| rafaeldtinoco | ahasenack: lol | 18:29 |
| bryce | :-) | 18:29 |
| rafaeldtinoco | ahasenack: so.. | 18:29 |
| rafaeldtinoco | im doing a huge rebase now | 18:29 |
| rafaeldtinoco | ive done the split and logical | 18:29 |
| rafaeldtinoco | using git-ubuntu | 18:29 |
| rafaeldtinoco | now im the debian merge phase | 18:29 |
| ahasenack | merge onto new/debian, right? | 18:29 |
| rafaeldtinoco | my doubt is about doing all the initial merge without dropping the patches | 18:29 |
| rafaeldtinoco | ahasenack: yep | 18:30 |
| rafaeldtinoco | i think finishing the rebase | 18:30 |
| rafaeldtinoco | and revisiting each patch from series | 18:30 |
| ahasenack | I find it easier to finish the rebase, and taking notes while doing it (in the commit messages even) | 18:30 |
| rafaeldtinoco | might be easier | 18:30 |
| ahasenack | and then revisiting things and reorganizing | 18:30 |
| rafaeldtinoco | then you drop | 18:30 |
| rafaeldtinoco | if neede | 18:30 |
| rafaeldtinoco | correct ? | 18:30 |
| ahasenack | yes | 18:30 |
| rafaeldtinoco | ok | 18:30 |
| rafaeldtinoco | sounds good, let me try | 18:30 |
| rafaeldtinoco | u said u take notes | 18:30 |
| ahasenack | if it needs changing, then I do that during the rebase, ther eis no other way I think | 18:30 |
| rafaeldtinoco | i see | 18:31 |
| rafaeldtinoco | and then you do a quilt push -af | 18:31 |
| rafaeldtinoco | and check failures | 18:31 |
| rafaeldtinoco | and go rebasing | 18:31 |
| rafaeldtinoco | one by one | 18:31 |
| ahasenack | yes | 18:31 |
| rafaeldtinoco | ok | 18:31 |
| rafaeldtinoco | i was doing the same | 18:31 |
| rafaeldtinoco | but i was afraid there was something faster | 18:31 |
| rafaeldtinoco | which is not the case | 18:31 |
| rafaeldtinoco | lol | 18:31 |
| ahasenack | my largest rebase had I think 47 commits | 18:31 |
| ahasenack | and each one was conflicting | 18:31 |
| rafaeldtinoco | im glad you had snmp before | 18:31 |
| ahasenack | I almost lost my hair | 18:31 |
| rafaeldtinoco | u had lots of commits already | 18:31 |
| rafaeldtinoco | i had to rebase only the last fixes | 18:32 |
| rafaeldtinoco | =) | 18:32 |
| ahasenack | nice | 18:32 |
| rafaeldtinoco | but upstream dropped a bunch of your stuff | 18:32 |
| rafaeldtinoco | cause it went upstream | 18:32 |
| ahasenack | even better | 18:32 |
| rafaeldtinoco | now ill find those | 18:32 |
| rafaeldtinoco | yep | 18:32 |
| rafaeldtinoco | cool tks! | 18:32 |
| ahasenack | more work to find them, but less changes in the end | 18:32 |
| rafaeldtinoco | definitely! | 18:32 |
| rafaeldtinoco | but sometimes they dont give author | 18:32 |
| rafaeldtinoco | to the merge in debian :P | 18:32 |
| rafaeldtinoco | you have to track them down | 18:32 |
| rafaeldtinoco | I saw some of your pushes losing author in another package | 18:33 |
| rafaeldtinoco | tsc tsc | 18:33 |
| rafaeldtinoco | tks a lot | 18:33 |
| ahasenack | good luck | 18:34 |
| kanashiro | mwhudson, re runc test failure: I just added a comment to the bug I filled, when you have some time could you please check it out and see if it rings a bell for you? | 21:05 |
| kanashiro | btw I tried to rebuild it in eoan and faced the same problem | 21:06 |
| mwhudson | kanashiro: oh you are running the autopkgtest in the lxd backend? | 21:07 |
| mwhudson | not completely surprised that doesn't work, i guess | 21:08 |
| kanashiro | mwhudson, yes | 21:08 |
| mwhudson | time for some isolation-machine in debian/tests/control maybe | 21:08 |
| kanashiro | right, let me try to run it in a vm to check if they pass | 21:09 |
| kanashiro | mwhudson, you're right, it works fine in a vm and probably in a privileged container. Should I submit a MP for you adding this restriction? | 21:44 |
| mwhudson | kanashiro: yes please | 22:02 |
| kanashiro | mwhudson, I just figured out the the basic-smoke test it has already have isolation-machine restriction, the one which runs the unit tests is generated by Testsuite: autopkgtest-pkg-go via autodep8 | 22:13 |
| kanashiro | I am not sure if there is a way to add a restriction to auto generated tests | 22:13 |
| mwhudson | kanashiro: ah hm | 22:32 |
| mwhudson | kanashiro: i think the deal with autodep8 tests is that if the automatically generated one doesn't work you should just write it by hand | 22:32 |
| mwhudson | kanashiro: but i might be wrong about that! | 22:32 |
| kanashiro | mwhudson, as reference: https://sources.debian.org/src/autodep8/0.21/support/go/generate/ and https://sources.debian.org/src/dh-golang/1.43/script/dh_golang_autopkgtest/ | 23:08 |
| kanashiro | we can depend on dh-golang and run dh_golang_autopkgtest as they do and just add isolation-machine restriction | 23:10 |
| mwhudson | kanashiro: +1 | 23:10 |
| kanashiro | mwhudson, should I let the target in d/changelog as UNRELEASED? or do you want to upload it with just this change? | 23:20 |
| mwhudson | kanashiro: leave it UNRELEASED for now | 23:21 |
| kanashiro | ack | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!