[00:23] <sarnold> Phruis: this is a good starting point https://elixir.bootlin.com/linux/latest/source/kernel/power
[00:24] <sarnold> Phruis: each architecture is also going to have arch-specific code too https://elixir.bootlin.com/linux/latest/source/arch/x86/power
[00:50] <xnox> infinity:  thank you for your klibc upstream comments.
[02:00] <Phruis> sarnold, thanks
[11:34] <seb128> 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:42] <xnox> doko: thank you for removing the requested python2 django things
[11:43] <xnox> 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] <xnox> doko:  btw, i think to migrate mailer & piston, i need AA to remove _binaries only_ of python-django-mailer python-django-piston3
[11:46] <xnox> because they are now only python3-django-mailer and python3-django-piston3
[11:46] <xnox> (dropped python2 packages)
[11:52] <doko> xnox: django-piston3 ftbs in -proposed
[11:52] <xnox> ah
[11:53] <xnox> doko:  eh?! https://launchpad.net/ubuntu/+source/django-piston3/0.3~rc2-3ubuntu9
[11:53] <xnox> doko:  it was in error an arch:any package, changed to arch:all package
[11:53] <xnox> so it claims to be "missing" on all arches
[11:53] <xnox> but it totally did build
[11:53] <doko> ahh, I see
[11:54] <xnox> i don't know what AA need to do when a package goes from arch:any to arch:all
[11:54] <doko> silly britney
[11:54] <xnox> doko:  some of the packaging in these is beyond silly too. So never mind britney.
[11:55] <xnox> doko:  but python-django-piston3 binary needs to be removed, which was arch;any and now is fully gone
[11:55] <xnox> doko:  and that is the one that britney correctly complains about
[11:55] <xnox> (not the python3 one)
[11:56] <xnox> so actually it's complaining about the dropped arch:any python2 package
[11:56] <xnox> doko:  django-ratelimit is actually miss-upload, and should be removed src from -proposed just like you already removed from release.
[11:58] <doko> .
[12:01] <gpiccoli> hi rbasak, can we discuss LP #1847924 when you have some minutes? Thanks!
[12:05] <xnox> gpiccoli:  my biggesst worry about that one is "degraded boot" however that also makes no sence in raid0 case =)
[12:06] <gpiccoli> 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] <gpiccoli> in order to patch getting "triggered", raid0 must be already in a bad state
[12:26] <ddstreet> 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] <seb128> ddstreet, thanks!
[12:59] <ahasenack> infinity: hi, there is no verification tag to flip in bug https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1849665
[12:59] <ahasenack> I can of course add one, but did the script fail?
[12:59] <ahasenack> the sru script that adds the comment with instructions, I mean
[13:16] <rbasak> gpiccoli: o/
[13:17] <gpiccoli> o/ rbasak
[13:17] <rbasak> Thank you for your reply in the bug
[13:17] <gpiccoli> You're welcome, thank you for the valid concerns!
[13:18] <rbasak> 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] <rbasak> THat's documented at https://xdsports.uk/weight-belt
[13:19] <rbasak> Uh
[13:19] <rbasak> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[13:19] <rbasak> On the second point, I'm hoping to reduce the scope in worrying about the impact to consumers of mdadm
[13:20] <gpiccoli> hehe sure rbasak, I'll add the Regressions Potential! my bad not adding before
[13:20] <rbasak> 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] <rbasak> s/the same/exactly identical/
[13:21] <gpiccoli> 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] <gpiccoli> *add a comment
[13:22] <rbasak> gpiccoli: that would be useful - thanks!
[13:22] <gpiccoli> Just to speed up things,
[13:22] <gpiccoli> what if it changes?
[13:22] <rbasak> With that knowledge we can reduce the scope of what we need to consider.
[13:22] <gpiccoli> ok - perfect
[13:22] <rbasak> If it changes then we need to consider what consumes that
[13:22] <rbasak> Eg. will we break some tool that parses mdadm output, such as monitoring tools?
[13:22] <gpiccoli> great, makes sense!
[13:23] <gpiccoli> after adding regression potential and such comment, I will ping you again, thanks a lot !
[13:23] <rbasak> 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] <rbasak> I swear I pressed Ctrl-C, and that this happens to me more often than what would be explained by user error
[13:24] <rbasak> I suspect that Firefox has some condition when it doesn't actually copy.
[13:25] <gpiccoli> makes sense rbasak, thank you o/
[13:26] <xnox> rbasak:  i find that focus follows mouse interferes sometimes. I.e. copy only happens from a "focused" window.
[13:28] <rbasak> 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] <rbasak> 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] <rbasak> But I'd like that documented if so
[13:29] <gpiccoli> ok rbasak, thanks for the heads-up aboutthis
[13:30] <rbasak> 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.
[13:52] <slashd> teward, I have tested on focal with ipv6 disable using nginx '1.17.5-0ubuntu1', and everything went well to that regard.
[14:08] <seb128> 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] <xnox> 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] <xnox> 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] <coreycb> 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] <coreycb> xnox: upstream openstack should be getting 2.2.4 support this cycle
[14:18] <coreycb> xnox: bug 1842969 fyi. I'll fix that for manila-ui in focal and eoan though.
[14:24] <xnox> coreycb:  so it needs this cherrypick too https://github.com/openstack/manila-ui/commit/83a0e432fe475a263c2f5e5337511db96263c3b8.patch
[14:24] <xnox> coreycb:  but otherwise it builds..... i have a package ready and can just upload it.
[14:25] <coreycb> xnox: ah, ok great. thanks just let me know when you do and i'll apply your debdiff to our master branch.
[14:26] <xnox> coreycb: ack. If even that, cause it will not be needed with any new/next upstream release.
[14:26] <xnox> coreycb:  also less than 1:1.11 is pre-xenial, imho such a version constraint is a bit redundant.
[14:29] <coreycb> xnox:  i think you meant greater than, and I agree that's redundant
[14:30] <xnox> yes and yes
[14:33] <xnox> coreycb:  http://launchpadlibrarian.net/450008718/manila-ui_1%3A2.19.0-0ubuntu1_1%3A2.19.0-0ubuntu2.diff.gz if you must
[14:34] <coreycb> xnox: thanks
[15:06] <kanashiro> 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] <kanashiro> rbasak, ^
[15:11] <rafaeldtinoco> kanashiro: has the migration failed ?
[15:12] <rafaeldtinoco> sometimes branch was updated, archive has the source package but it hasnt migrated yet due to excuses
[15:14] <rbasak> mwhudson: pandas import done (at 12:19)
[15:15] <rbasak> 2019-11-02 18:46:53|python-tornado|1572720413.91573|error|20
[15:15] <rbasak> kanashiro: ^ looks like an import failure
[15:16] <rbasak> The cause is bug 1764814
[15:17] <rbasak> I'm working on that now as it happens, but I don't expect the fix to land for a few days
[15:18] <rbasak> kanashiro: you can do the merge without git-ubuntu, but in your case I suggest moving on to another package for now
[15:19] <kanashiro> rbasak, ack, I'll move to the next then
[15:34] <bdmurray> 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] <seb128> bdmurray, how much?
[15:35] <seb128> bdmurray, and thx :)
[15:38] <bdmurray> seb128: from 1G to 2G which while that is the recommended amount of RAM it was still surprising.
[15:38] <seb128> bdmurray, thx for pointing it out, I will have a look, that seems buggy
[15:40] <bdmurray> seb128: Thanks - I forgot to fill a bug during the flurry of the release sprint.
[15:40] <Eickmeyer> Oof.. bug 1851346 hitting Ubuntu Studio like a nasty ton of bricks.
[15:45] <Laney> 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] <Laney> alternatively: how can I conditionally act in clean based on whether I'm building indep packages or not?
[15:53] <Laney> or maybe I need to do something else altogether
[15:54] <Laney> 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] <teward> slashd: good, then we know that works fine now.  :)
[16:06] <slashd> teward, indeed
[18:08] <andrewsh> hi
[18:08] <andrewsh> can please someone look at https://answers.launchpad.net/launchpad/+question/685319?
[18:08] <andrewsh> at the moment there’s nobody to review and/or approve Slovak translations for a lot of things on Launchpad
[18:08] <andrewsh> I’d like to change that
[18:10] <cjwatson> andrewsh: Queued up but I can't look at it today as I have to finish up
[18:10] <andrewsh> thanks!
[18:11] <cjwatson> 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] <cjwatson> (if you can, of course)
[18:35] <GunnarHj> cjwatson: I'm not a member of "Launchpad Translations Coordinators" (only "Ubuntu Translations Coordinators").
[18:36] <GunnarHj> 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] <ahasenack> rafaeldtinoco: around?
[18:52] <rafaeldtinoco> ahasenack: yep, just saw your update
[18:52] <rafaeldtinoco> will dput
[18:52] <ahasenack> rafaeldtinoco: when building the source packages for the corosync and pacemaker upload,
[18:52] <rafaeldtinoco> thx!
[18:52] <ahasenack> rafaeldtinoco: use the right -v option
[18:52] <ahasenack> or use git ubuntu build-source -v --sign --for-merge
[18:52] <ahasenack> "--for-merge" being the thing that adds the correct -v parameter
[18:52] <rafaeldtinoco> ah good to know
[18:52] <ahasenack> it should be the previous ubuntu version
[18:52] <ahasenack> so that the changes file includes the debian releases up until this merge
[18:53] <ahasenack> you can open the changes file to take a look
[18:53] <ahasenack> it must start with the first non-ubuntu version, and go all the way up to the version you are uploading
[18:53] <ahasenack> rafaeldtinoco: --for-merge also takes care of fetching the correct orig tarball in the case it's a new upstream version
[18:54] <ahasenack> and also passes the right options to dpkg-buildpackage to include the orig tarball in the upload in that case
[18:54] <rafaeldtinoco> ahasenack: i dont use the git ubuntu build-source
[18:54] <rafaeldtinoco> but I do use dpkg-buildpackage
[18:54] <ahasenack> that's why I'm saying all of this :)
[18:54] <rafaeldtinoco> u know the exact flags it does ?
[18:55] <ahasenack> rafaeldtinoco: check dpkg-genchanges, it's -sa for the orig tarball
[18:55] <rafaeldtinoco> -sa <- for the new upstream
[18:55] <rafaeldtinoco> right ?
[18:55] <ahasenack> yes, but you need to have it locally
[18:55] <rafaeldtinoco> yep I do
[18:55] <ahasenack> it won't generate the tarball for you, it will just include it in the upload
[18:55] <rafaeldtinoco> I have generated the source packages already
[18:55] <rafaeldtinoco> i was mostly concerned on the signing
[18:55] <rafaeldtinoco> you mentioned
[18:55] <ahasenack> and -v
[18:56] <rafaeldtinoco> I use dpkg-buildpackage -S -k$MYKEY -sa
[18:56] <ahasenack> you need -v
[18:56] <rafaeldtinoco> ok
[18:56] <ahasenack> also a parameter that makes its way to dpkg-genchanges (via dpkg-buildpackage)
[18:56] <ahasenack> rafaeldtinoco: for pacemaker, for example
[18:57] <ahasenack> rafaeldtinoco: you would use -v2.0.1-4ubuntu2
[18:57] <rafaeldtinoco> ah gotcha
[18:57] <rafaeldtinoco> the previous one
[18:57] <ahasenack> rafaeldtinoco: then check the changes file, it should be listing 2.0.1-5 and 2.0.1-5ubuntu1
[18:57] <rafaeldtinoco> cool let me give it a try
[18:57] <ahasenack> as these are "all the changes in that package since the last time it was uploaded to ubuntu"
[18:57] <ahasenack> including debian changes
[18:58] <ahasenack> 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] <ahasenack> rafaeldtinoco: pacemaker is not a new upstream release, so no -sa needed
[18:59] <rafaeldtinoco> yep, only corosync
[18:59] <ahasenack> yep
[18:59] <rafaeldtinoco> I realized that when doing the source package locally
[18:59] <rafaeldtinoco> it complains about the missing .tar.gz
[18:59] <rafaeldtinoco> then I get it
[18:59] <ahasenack> yes
[19:00] <ahasenack> I suggest pull-debian-source -d
[19:00] <rafaeldtinoco> https://www.irccloud.com/pastebin/xoB688RL/
[19:00] <rafaeldtinoco> ahasenack: yep, i use pull-lp and pull-debian
[19:00] <rafaeldtinoco> pls check the pastebin
[19:00] <rafaeldtinoco> for the signed changes
[19:00] <ahasenack> 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] <rafaeldtinoco> if looks good
[19:00] <rafaeldtinoco> ahasenack: the version ddstreet did
[19:01] <rafaeldtinoco> supports debian and ubuntu iirc
[19:01] <rafaeldtinoco> but not sure if it was merged or not
[19:01] <ahasenack> rafaeldtinoco: hm, that changes is incorrect
[19:01] <ahasenack> rafaeldtinoco: where are the changelog changes we talked about yesterday?
[19:01] <rafaeldtinoco> oh wait
[19:01] <ahasenack> Launchpad-Bugs-Fixed: 1828228 <-- it's fixing that bug again, for example
[19:01] <ddstreet> rafaeldtinoco not yet, sorry, it's on my todo list
[19:01] <ddstreet> you can use ppa:ddstreet/ubuntu-dev-tools if you want
[19:02] <rafaeldtinoco> ahasenack: its wrong indeed, and it wasnt
[19:02] <rafaeldtinoco> i wonder if my cron did something to my local branch
[19:02] <rafaeldtinoco> let me fix that andreas
[19:02] <ahasenack> it's your first dput, be careful :)
[19:02] <rafaeldtinoco> yep yep
[19:02] <rafaeldtinoco> ddstreet: were your changes accepted ?
[19:02] <rafaeldtinoco> from that time... or not yet ?
[19:02] <rafaeldtinoco> its been what ? 2 years :P
[19:02] <ddstreet> rafaeldtinoco well...i gave up after over a year
[19:02] <rafaeldtinoco> lol
[19:02] <rafaeldtinoco> i remember there was some cool features
[19:03] <rafaeldtinoco> to download previous versions
[19:03] <ddstreet> but i am not painstakingly rebasing and splitting things up so i can open multiple merge requests to get it added
[19:03] <rafaeldtinoco> gotcha
[19:03] <ddstreet> it just is quite time-intensive since my code is really, really far from what's in git
[19:03] <ddstreet> yeah, you can even download deleted pkgs or from -security ppa
[19:04] <ddstreet> i'm going to add pulling from upload queues when i have a minute also
[19:04] <ddstreet> sorry i meant 'now ...rebasing' above, 'not' was a typo
[19:04] <rafaeldtinoco> ahasenack: wow, i was in the wrong computer
[19:05] <ahasenack> dude
[19:05] <rafaeldtinoco> ahasenack: #) that is the bad thing about having 2 or 3 computers
[19:05] <rafaeldtinoco> lol
[19:05] <rafaeldtinoco> ill delete my local branches from the one
[19:05] <rafaeldtinoco> im not using for this never to happen again
[19:05]  * rafaeldtinoco fear
[19:05] <ahasenack> double check the hash that was approved in the mp
[19:05] <ahasenack> otherwise the upload tag is useless
[19:05] <rafaeldtinoco> ddstreet: ill play with it
[19:05] <rafaeldtinoco> maybe i can help you out with the merges/split
[19:06] <rafaeldtinoco> ahasenack: it would not upload
[19:06] <rafaeldtinoco> relax
[19:06] <rafaeldtinoco> i would not force things for sure
[19:06] <rafaeldtinoco> but i wont have any "git ubuntu" local branches
[19:06] <rafaeldtinoco> in the machine I dont use for coding
[19:06] <rafaeldtinoco> that is a good thing to be done = )
[19:07] <ddstreet> 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] <rafaeldtinoco> ddstreet: i can see you rebasing things :o)
[19:07] <rafaeldtinoco> rebase-orig rebase-orig
[19:07] <rafaeldtinoco> lol
[20:03] <infinity> vorlon, mdeslaur, kees, stgraber: TB?
[20:05] <marcoagpinto> infinity: Thunderbird?
[20:05] <marcoagpinto> :p
[20:35] <rafaeldtinoco> ahasenack: ping
[20:35] <rafaeldtinoco> ahasenack: sorry got preempt here
[20:35] <rafaeldtinoco> https://www.irccloud.com/pastebin/7OqGRPY7/
[20:35] <rafaeldtinoco> just checking one more time before the 1st
[20:35] <rafaeldtinoco> then it will be smoother =)
[20:38] <rafaeldtinoco> ok, looks good, double checked, moving on