[00:23] Phruis: this is a good starting point https://elixir.bootlin.com/linux/latest/source/kernel/power [00:24] Phruis: each architecture is also going to have arch-specific code too https://elixir.bootlin.com/linux/latest/source/arch/x86/power [00:50] infinity: thank you for your klibc upstream comments. [02:00] sarnold, thanks === seb128_ is now known as seb128 [11:34] ddstreet, hey, do you plan another bionic/n-m SRU? I need to do one for a fix but I saw you have bug #1850267 in progress [11:34] bug 1850267 in network-manager (Ubuntu Bionic) "autopkgtest 'nm' fails because it can't find dnsmasq" [Low,In progress] https://launchpad.net/bugs/1850267 [11:42] doko: thank you for removing the requested python2 django things [11:43] doko: i actually think there might be more to remove..... some of them smell like ex-Ubuntu1 team shipping things they use in production, which they don't anymore. [11:45] doko: btw, i think to migrate mailer & piston, i need AA to remove _binaries only_ of python-django-mailer python-django-piston3 [11:46] because they are now only python3-django-mailer and python3-django-piston3 [11:46] (dropped python2 packages) [11:52] xnox: django-piston3 ftbs in -proposed [11:52] ah [11:53] doko: eh?! https://launchpad.net/ubuntu/+source/django-piston3/0.3~rc2-3ubuntu9 [11:53] doko: it was in error an arch:any package, changed to arch:all package [11:53] so it claims to be "missing" on all arches [11:53] but it totally did build [11:53] ahh, I see [11:54] i don't know what AA need to do when a package goes from arch:any to arch:all [11:54] silly britney [11:54] doko: some of the packaging in these is beyond silly too. So never mind britney. [11:55] doko: but python-django-piston3 binary needs to be removed, which was arch;any and now is fully gone [11:55] doko: and that is the one that britney correctly complains about [11:55] (not the python3 one) [11:56] so actually it's complaining about the dropped arch:any python2 package [11:56] doko: django-ratelimit is actually miss-upload, and should be removed src from -proposed just like you already removed from release. [11:58] . [12:01] hi rbasak, can we discuss LP #1847924 when you have some minutes? Thanks! [12:01] Launchpad bug 1847924 in mdadm (Ubuntu Focal) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924 [12:05] gpiccoli: my biggesst worry about that one is "degraded boot" however that also makes no sence in raid0 case =) [12:06] hey xnox! Yeah, I don't think the patch could cause degraded boot, it could cause in worst case, for example, a failure in a parsing tool for raid0 status if that doesn't cope with broken state hehe [12:07] in order to patch getting "triggered", raid0 must be already in a bad state [12:26] seb128 i don't have anything else for nm, feel free to take that bug, i'm pretty sure it only needs dnsmasq-base added to the test/control file Depends: for that test. thanks! [12:27] ddstreet, thanks! [12:59] infinity: hi, there is no verification tag to flip in bug https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1849665 [12:59] Launchpad bug 1849665 in zfs-linux (Ubuntu Eoan) "zfs diff: Unable to determine path or stats for object " [Undecided,Fix committed] [12:59] I can of course add one, but did the script fail? [12:59] the sru script that adds the comment with instructions, I mean === ricab is now known as ricab|lunch [13:16] gpiccoli: o/ [13:17] o/ rbasak [13:17] Thank you for your reply in the bug [13:17] You're welcome, thank you for the valid concerns! [13:18] gpiccoli: so on the first point, I'd like the Regression Potential section to detail where regressions are most likely to occur in order to inform review and testing. [13:18] THat's documented at https://xdsports.uk/weight-belt [13:19] Uh [13:19] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure [13:19] On the second point, I'm hoping to reduce the scope in worrying about the impact to consumers of mdadm [13:20] hehe sure rbasak, I'll add the Regressions Potential! my bad not adding before [13:20] Is it possible/correct to state that, if an array is not in the new failed state, the observable behaviour for a user of mdadm will be the same in all cases following the patch? [13:20] s/the same/exactly identical/ [13:21] rbasak, it should, but to be completely accurate with you, I'll check all states and a comment in the bug, showing it doesn't change (except for broken), or, if changes, how so [13:22] *add a comment [13:22] gpiccoli: that would be useful - thanks! [13:22] Just to speed up things, [13:22] what if it changes? [13:22] With that knowledge we can reduce the scope of what we need to consider. [13:22] ok - perfect [13:22] If it changes then we need to consider what consumes that [13:22] Eg. will we break some tool that parses mdadm output, such as monitoring tools? [13:22] great, makes sense! [13:23] after adding regression potential and such comment, I will ping you again, thanks a lot ! [13:23] If the output is identical except in the new failed state, then that breakage would be limited to a failure that wasn't accounted for by the monitoring tool anyway, in which case arguably the new situation would be better anyway [13:23] * xnox ponders if X should have a "clear after timeout" or like "clear after one paste" for all of the copy&paste functionality. [13:24] I swear I pressed Ctrl-C, and that this happens to me more often than what would be explained by user error [13:24] I suspect that Firefox has some condition when it doesn't actually copy. [13:25] makes sense rbasak, thank you o/ [13:26] rbasak: i find that focus follows mouse interferes sometimes. I.e. copy only happens from a "focused" window. [13:28] gpiccoli: oh, one more point. On User Impact, right now it sounds like a theoretical bug only. Could you detail why we need an SRU? Are users hitting the problem in practice, for example? [13:29] It's OK if the answer is that it's theoretical but data loss is severe enough that you want to pre-emptively fix it. [13:29] But I'd like that documented if so [13:29] ok rbasak, thanks for the heads-up aboutthis [13:30] xnox: I think it does have something to do with focus change, though in my case I'm using pretty much entirely GNOME defaults on this. === fenris is now known as Guest81494 [13:52] teward, I have tested on focal with ipv6 disable using nginx '1.17.5-0ubuntu1', and everything went well to that regard. [14:08] bdmurray, hey, can you get the rygel/eoan SRU moved to -updates now rather than waiting for the full week period? the bug it fixes is rather important and it got properly verified [14:12] coreycb: hey, can you please explain to me the manila-ui 0ubuntu2 upload which says "d/control: Ensure python3-django is << 2:2.2.4." ? [14:12] coreycb: is there like a >> 2:2.2.X version that is also good? I'm trying to do migration to 2.2.6 in focal now. [14:16] xnox: hey, that should've been changed back to python3-django >= 1:1.11. it was an attempt that was later reverted but apparently not for manila-ui. [14:17] xnox: upstream openstack should be getting 2.2.4 support this cycle [14:18] xnox: bug 1842969 fyi. I'll fix that for manila-ui in focal and eoan though. [14:18] bug 1842969 in python-django (Ubuntu) "python-django 2.2.4 not for eoan" [Undecided,Fix released] https://launchpad.net/bugs/1842969 [14:24] coreycb: so it needs this cherrypick too https://github.com/openstack/manila-ui/commit/83a0e432fe475a263c2f5e5337511db96263c3b8.patch [14:24] coreycb: but otherwise it builds..... i have a package ready and can just upload it. [14:25] xnox: ah, ok great. thanks just let me know when you do and i'll apply your debdiff to our master branch. [14:26] coreycb: ack. If even that, cause it will not be needed with any new/next upstream release. [14:26] coreycb: also less than 1:1.11 is pre-xenial, imho such a version constraint is a bit redundant. [14:29] xnox: i think you meant greater than, and I agree that's redundant [14:30] yes and yes [14:33] coreycb: http://launchpadlibrarian.net/450008718/manila-ui_1%3A2.19.0-0ubuntu1_1%3A2.19.0-0ubuntu2.diff.gz if you must === ricab|lunch is now known as ricab [14:34] xnox: thanks [15:06] I git clone'd the python-tornado package using git-ubuntu and the content in ubuntu/devel branch is not the same in the archive (ubuntu/devel has 4.5.3-1 and in focal the version is 5.1.1-4ubuntu5 according to rmadison), did something go wrong here? [15:09] rbasak, ^ [15:11] kanashiro: has the migration failed ? [15:12] sometimes branch was updated, archive has the source package but it hasnt migrated yet due to excuses [15:14] mwhudson: pandas import done (at 12:19) [15:15] 2019-11-02 18:46:53|python-tornado|1572720413.91573|error|20 [15:15] kanashiro: ^ looks like an import failure [15:16] The cause is bug 1764814 [15:16] bug 1764814 in usd-importer "awscli import fails: package_creator.display_name results in HTTP error 410: Gone" [High,In progress] https://launchpad.net/bugs/1764814 [15:17] I'm working on that now as it happens, but I don't expect the fix to land for a few days [15:18] kanashiro: you can do the merge without git-ubuntu, but in your case I suggest moving on to another package for now [15:19] rbasak, ack, I'll move to the next then [15:34] seb128: Sure, that reminds me we noticed rygel uses a lot of memory during its postinst. We had to bump the automatic upgrade testing units memory allotment because it was hanging on rygel. [15:35] bdmurray, how much? [15:35] bdmurray, and thx :) [15:38] seb128: from 1G to 2G which while that is the recommended amount of RAM it was still surprising. [15:38] bdmurray, thx for pointing it out, I will have a look, that seems buggy [15:40] seb128: Thanks - I forgot to fill a bug during the flurry of the release sprint. [15:40] Oof.. bug 1851346 hitting Ubuntu Studio like a nasty ton of bricks. [15:40] bug 1851346 in ubiquity (Ubuntu) "Ubuntu Studio 19.10 Installer Causes Wanted Programs to be Removed" [Undecided,Confirmed] https://launchpad.net/bugs/1851346 [15:45] does anyone know if it is possible to use the output of dh_listpackages in the clean target? I'm just getting all packages, probably because it doesn't know if it's doing arch, arch+indep, indep at that point, I guess [15:45] alternatively: how can I conditionally act in clean based on whether I'm building indep packages or not? [15:53] or maybe I need to do something else altogether [15:54] basically: dh-sequence-foo doesn't work in B-D-I and is documented as such, and I don't know how to manually pass the --with= properly for the clean target if I specify the real package in B-D-I instead [15:59] slashd: good, then we know that works fine now. :) [16:06] teward, indeed [18:08] hi [18:08] can please someone look at https://answers.launchpad.net/launchpad/+question/685319? [18:08] at the moment there’s nobody to review and/or approve Slovak translations for a lot of things on Launchpad [18:08] I’d like to change that [18:10] andrewsh: Queued up but I can't look at it today as I have to finish up [18:10] thanks! [18:11] GunnarHj: ^- would be useful if you could verify that - I'm not totally sure on the conventions for the Ubuntu-specific vs. LP-wide translation teams [18:11] (if you can, of course) [18:35] cjwatson: I'm not a member of "Launchpad Translations Coordinators" (only "Ubuntu Translations Coordinators"). [18:36] andrewsh: How come you are not a member of ~ubuntu-l10n-sk? I'm asking because normally there are local procedures in place to approve new translators. [18:51] rafaeldtinoco: around? [18:52] ahasenack: yep, just saw your update [18:52] will dput [18:52] rafaeldtinoco: when building the source packages for the corosync and pacemaker upload, [18:52] thx! [18:52] rafaeldtinoco: use the right -v option [18:52] or use git ubuntu build-source -v --sign --for-merge [18:52] "--for-merge" being the thing that adds the correct -v parameter [18:52] ah good to know [18:52] it should be the previous ubuntu version [18:52] so that the changes file includes the debian releases up until this merge [18:53] you can open the changes file to take a look [18:53] it must start with the first non-ubuntu version, and go all the way up to the version you are uploading [18:53] rafaeldtinoco: --for-merge also takes care of fetching the correct orig tarball in the case it's a new upstream version [18:54] and also passes the right options to dpkg-buildpackage to include the orig tarball in the upload in that case [18:54] ahasenack: i dont use the git ubuntu build-source [18:54] but I do use dpkg-buildpackage [18:54] that's why I'm saying all of this :) [18:54] u know the exact flags it does ? [18:55] rafaeldtinoco: check dpkg-genchanges, it's -sa for the orig tarball [18:55] -sa <- for the new upstream [18:55] right ? [18:55] yes, but you need to have it locally [18:55] yep I do [18:55] it won't generate the tarball for you, it will just include it in the upload [18:55] I have generated the source packages already [18:55] i was mostly concerned on the signing [18:55] you mentioned [18:55] and -v [18:56] I use dpkg-buildpackage -S -k$MYKEY -sa [18:56] you need -v [18:56] ok [18:56] also a parameter that makes its way to dpkg-genchanges (via dpkg-buildpackage) [18:56] rafaeldtinoco: for pacemaker, for example [18:57] rafaeldtinoco: you would use -v2.0.1-4ubuntu2 [18:57] ah gotcha [18:57] the previous one [18:57] rafaeldtinoco: then check the changes file, it should be listing 2.0.1-5 and 2.0.1-5ubuntu1 [18:57] cool let me give it a try [18:57] as these are "all the changes in that package since the last time it was uploaded to ubuntu" [18:57] including debian changes [18:58] so if 2.0.1-5 for example closed an ubuntu bug, launchpad would auto-close it, since that version (and the mention of the bug) is included in the changes file [18:59] rafaeldtinoco: pacemaker is not a new upstream release, so no -sa needed [18:59] yep, only corosync [18:59] yep [18:59] I realized that when doing the source package locally [18:59] it complains about the missing .tar.gz [18:59] then I get it [18:59] yes [19:00] I suggest pull-debian-source -d [19:00] https://www.irccloud.com/pastebin/xoB688RL/ [19:00] ahasenack: yep, i use pull-lp and pull-debian [19:00] pls check the pastebin [19:00] for the signed changes [19:00] I don't know if pull-lp-source handles debs from debian, I guess it could, since they are also stored in lp [19:00] if looks good [19:00] ahasenack: the version ddstreet did [19:01] supports debian and ubuntu iirc [19:01] but not sure if it was merged or not [19:01] rafaeldtinoco: hm, that changes is incorrect [19:01] rafaeldtinoco: where are the changelog changes we talked about yesterday? [19:01] oh wait [19:01] Launchpad-Bugs-Fixed: 1828228 <-- it's fixing that bug again, for example [19:01] rafaeldtinoco not yet, sorry, it's on my todo list [19:01] you can use ppa:ddstreet/ubuntu-dev-tools if you want [19:02] ahasenack: its wrong indeed, and it wasnt [19:02] i wonder if my cron did something to my local branch [19:02] let me fix that andreas [19:02] it's your first dput, be careful :) [19:02] yep yep [19:02] ddstreet: were your changes accepted ? [19:02] from that time... or not yet ? [19:02] its been what ? 2 years :P [19:02] rafaeldtinoco well...i gave up after over a year [19:02] lol [19:02] i remember there was some cool features [19:03] to download previous versions [19:03] but i am not painstakingly rebasing and splitting things up so i can open multiple merge requests to get it added [19:03] gotcha [19:03] it just is quite time-intensive since my code is really, really far from what's in git [19:03] yeah, you can even download deleted pkgs or from -security ppa [19:04] i'm going to add pulling from upload queues when i have a minute also [19:04] sorry i meant 'now ...rebasing' above, 'not' was a typo [19:04] ahasenack: wow, i was in the wrong computer [19:05] dude [19:05] ahasenack: #) that is the bad thing about having 2 or 3 computers [19:05] lol [19:05] ill delete my local branches from the one [19:05] im not using for this never to happen again [19:05] * rafaeldtinoco fear [19:05] double check the hash that was approved in the mp [19:05] otherwise the upload tag is useless [19:05] ddstreet: ill play with it [19:05] maybe i can help you out with the merges/split [19:06] ahasenack: it would not upload [19:06] relax [19:06] i would not force things for sure [19:06] but i wont have any "git ubuntu" local branches [19:06] in the machine I dont use for coding [19:06] that is a good thing to be done = ) [19:07] rafaeldtinoco thnx, and my git for it is https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools, mostly in the 'work' and 'work_cp*' branches [19:07] ddstreet: i can see you rebasing things :o) [19:07] rebase-orig rebase-orig [19:07] lol [20:03] vorlon, mdeslaur, kees, stgraber: TB? [20:05] infinity: Thunderbird? [20:05] :p [20:35] ahasenack: ping [20:35] ahasenack: sorry got preempt here [20:35] https://www.irccloud.com/pastebin/7OqGRPY7/ [20:35] just checking one more time before the 1st [20:35] then it will be smoother =) [20:38] ok, looks good, double checked, moving on