[15:59]  * marjo waves
[16:00]  * ttx waves
[16:00] <pitti> hai
[16:00] <seb128> hey
[16:01] <jdstrand> o/
[16:01]  * slangasek waves
[16:01] <slangasek> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is slangasek.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <slangasek> [LINK] https://wiki.ubuntu.com/ReleaseTeam/Meeting/2010-04-16
[16:02] <MootBot> LINK received:  https://wiki.ubuntu.com/ReleaseTeam/Meeting/2010-04-16
[16:02]  * asac waves
[16:02] <slangasek> [TOPIC] Previous actions
[16:02] <MootBot> New Topic:  Previous actions
[16:02] <slangasek>   * rickspencer to ask designers about new Edubuntu logo
[16:02] <slangasek>   * doko to grep the archive for codecs.open in python code, to find other packages broken by http://bugs.python.org/issue691291
[16:02] <slangasek>   * ScottK, slangasek to review python sync/merge candidates (INPROGRESS)
[16:02] <slangasek>   * marjo to make sure the outstanding optional testcases for beta2 get tested this week
[16:02] <slangasek>   * ogasawara to triage bug #557429 for final (DONE)
[16:02] <slangasek>   * pitti to get discussion of SRU extension for GNOME, KDE, OOo, OpenJDK point releases on UDS agenda
[16:02] <slangasek>   * Riddell to investigate the lingering Kubuntu installer issues
[16:02] <slangasek>   * ScottK to put out a call for Kubuntu daily ISO testing
[16:02] <pitti> slangasek: SRU extension is on the agenda
[16:03] <slangasek> ok, thanks
[16:03] <pitti> https://wiki.ubuntu.com/DesktopTeam/10.10/BlueprintList
[16:03] <slangasek> how'd we do on the other action items?
[16:03] <marjo> slangasek: Ara working with dpm and ttx to cover some optional test cases.
[16:04] <slangasek> great
[16:04] <slangasek> ScottK, Riddell: how have we fared with the Kubuntu installer?
[16:06] <slangasek> [TOPIC] QA Team
[16:06] <MootBot> New Topic:  QA Team
[16:06] <marjo> HW Testing (automated)
[16:06] <marjo> http://people.canonical.com/~fader/hw-testing/current.html
[16:06] <marjo> Netbooks:
[16:06] <marjo>    passed:   13 (93%) failed:    0 ( 0%) untested:  1 ( 7%)
[16:06] <marjo> Laptops:
[16:06] <marjo>    passed:   39 (90%) failed:    3 ( 7%) untested:  1 ( 3%)
[16:06] <MootBot> LINK received:  http://people.canonical.com/~fader/hw-testing/current.html
[16:06] <marjo> Servers:
[16:06] <marjo>    passed:   64 (94%) failed:    0 ( 0%) untested:  4 ( 6%)
[16:06] <marjo> Desktops:
[16:06] <marjo>    passed:   13 (100%) failed:    0 (  0%) untested:  0 (  0%)
[16:06] <marjo> HW Testing (manual)
[16:06] <marjo> http://people.canonical.com/~fader/milestones/lucid/post-beta.html
[16:06] <MootBot> LINK received:  http://people.canonical.com/~fader/milestones/lucid/post-beta.html
[16:06] <marjo> passed: 45 (76%)    failed: 14 (24%)
[16:06] <marjo> Bugs will be reported on all failures
[16:07] <fader_> (Just to clarify, bugs have been reported for all failures; some just have not been triaged yet)
[16:07] <marjo> fader: thx for clarification
[16:08] <marjo> ISO Testing Bugs Status
[16:08] <marjo> http://people.canonical.com/~marjomercado/isotestingbugs.html
[16:08] <marjo> 558382	Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions - cjwatson to investigate
[16:08] <marjo> 557930	[Lucid Beta2] After first boot Live Kubuntu Netbook doesn't start X and fallback to a textual terminal - pedro to work with Riddell
[16:08] <marjo> 557807	Offers video resultions not actually supported on Lucid Intel 865G - brcye investigatin
[16:08] <MootBot> LINK received:  http://people.canonical.com/~marjomercado/isotestingbugs.html
[16:08] <marjo> 556962	kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/drm_fops.c:146! - jfo to triage
[16:09] <marjo> slangasek: that's it from QA team, unless there are questions
[16:10] <marjo> slangasek: thx
[16:11] <slangasek> marjo: what were the selection criteria for the 4 bugs you pasted?  there are several more bugs on the isotestingbugs page
[16:11] <marjo> slangasek: i just pointed out the "new" bugs
[16:11] <marjo> for emphasis
[16:12] <slangasek> ok
[16:13] <slangasek> no other questions here; anyone else?
[16:13] <slangasek> [TOPIC] Server Team
[16:13] <MootBot> New Topic:  Server Team
[16:14] <slangasek> marjo: thanks
[16:14] <slangasek> ttx: hi
[16:14] <ttx> o/
[16:14] <ttx> Updated team status at https://wiki.ubuntu.com/ServerTeam/ReleaseStatus
[16:14] <ttx> Bugs status:
[16:14] <ttx> Bugs targeted to release:
[16:14] <ttx> bug 563428 and bug 563434
[16:14] <ttx> This is about consistency in our cloud offering, will be fixed Monday at the latest
[16:15] <ttx> Other Lucid RC bugs :
[16:15] <ttx> bug 532733
[16:15] <ttx> lacking input from ogra and the reporter team
[16:15] <ttx> bug 513273
[16:15] <ttx> in progress
[16:16] <ogra> ttx, huh ?
[16:16] <ttx> https://bugs.launchpad.net/bugs/533029 -- new FFe review needed
[16:16] <ogra> i'm giving input the whole day
[16:16] <ttx> ogra: ah, recently ?
[16:16]  * ogra didnt do anything else but testing for that bug since he got up
[16:16] <ogra> yep
[16:16] <ttx> ah
[16:16] <ttx> sorry about that, I missed that
[16:16] <ogra> and i'm just done with the last combo of options
[16:16] <ttx> so it should msee movement now :)
[16:16] <ogra> doesnt fix anything
[16:17] <ttx> bug 552360 -- fix just committed
[16:17] <ttx> bug 563084 -- fix just committed
[16:17] <ttx> bug 563053 -- in progress, hopefully done today
[16:17] <pitti> ttx: I just reviewed that
[16:17] <ttx> the page also lists the identified lucid targets of opportunities
[16:17] <pitti> there are 4 remaining rdepends
[16:18] <pitti> two of which are mythtv, which I woudln't like to break without further coordination with superm
[16:18] <ttx> zul ^
[16:18] <ttx> On the specs side, a few work items left :
[16:18] <ttx> erver-lucid-uec-testing (31%) On track, not affected by freeze, mostly about testing RC and final milestones
[16:18] <zul> ttx: next on my list
[16:19] <ttx> server-lucid-apt-mirror-ec2 (0%) Blocked on IS (mirror deployment in progress), testing-only and not affected by freeze
[16:19] <ttx> server-lucid-puppet-uec-ec2-integration (44%) Hope to commit more testsuite fixes, remaining items are doc-only and not affected by freeze
[16:19] <ttx> RC Bugs affecting server, in other teams:
[16:19] <ttx> bug 559582
[16:20] <ttx> I think mvo is on top of this one
[16:20] <ttx> bug 563916 -- we'll probably releasenote it
[16:20] <ttx> which leaves bug 557429, that you put on the agenda
[16:21] <mvo> ttx: I think that is fixed now, may not be in the archive yet, haven't checked
[16:21] <slangasek> ttx: yes - can anyone on your team work on that, or does it need to be Foundations instead?
[16:21] <jdstrand> that one is possibly not as dire as it sounds
[16:21] <slangasek> jdstrand: oh?
[16:21] <ttx> slangasek: we kinda lost our last specialists recently, but if you're overworked, that's probably the one with the most overlap between our teams
[16:21] <jdstrand> at least the wording in release notes makes it seem a bigger failure
[16:22] <jdstrand> I reported that bug, so I get all the comments on it now
[16:22] <jdstrand> the issue is specifically that if you remove one disk, it comes up degraded (fine)
[16:22] <jdstrand> if you remove that disk, and add the other one, it comes up degraded (fine)
[16:22] <jdstrand> but if you add back the first, it comes up in sync
[16:22] <ttx> slangasek: I just doubt anyone in our team has sufficient expertise to fix mdadm
[16:23] <jdstrand> so you have two disks that were independently updated and removed, etc
[16:23] <jdstrand> there is obviously a bug, and it needs to be fixed, but it is probably not a common operation
[16:23] <ttx> jdstrand: is that a regression ?
[16:23] <jdstrand> (I don't have numbers to justify that statement)
[16:23] <jdstrand> ttx: actually, no
[16:24] <jdstrand> the guy who jumped on it and talked to updated linux-raid discovered it existed in karmic and earlier
[16:24] <jdstrand> s/updated/upstream/
[16:24] <ttx> ok, makes more sense to me
[16:24] <slangasek> jdstrand: not common, but as serious as I understood it to be...
[16:24] <cjwatson> we have very little mdadm expertise in foundations either, I fear
[16:24] <jdstrand> it just so happens that ext3 kinda scooted around it by happenstance
[16:24] <jdstrand> ext4 hits it though
[16:24] <slangasek> hmm? how is it filesystem-dependent?
[16:24] <ttx> cjwatson: yes, but you're overrall technically proficient :P
[16:24] <jdstrand> slangasek: oh, it is serious for sure-- total data loss
[16:25] <jdstrand> slangasek: it isn't technically fs independant-- there is something about ext3 that just by pure luck avoids it
[16:26] <slangasek> ttx: between the installer and plymouth/mountall, I think Foundations is quite busy until release; if someone on Server could take lead on this, I think that would be for the best
[16:26] <jdstrand> I don't have the details-- I'm not an mdadm expert-- I've just been following the bug
[16:26] <ttx> slangasek: ok, we'll do our best.
[16:26] <ttx> slangasek: I'll move it into our land at the top of that file
[16:27] <ttx> that's all for me
[16:27] <slangasek> ok, thanks
[16:27] <slangasek> anyone else have questions?
[16:28] <slangasek> [TOPIC] Mobile Team
[16:28] <MootBot> New Topic:  Mobile Team
[16:28] <slangasek> ttx: thanks
[16:28] <slangasek> asac: hi
[16:28] <asac> hi!
[16:28] <asac> [LINK] https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[16:28] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[16:28] <asac> so yeah. all specs done \o/ ... work item trackker is a bit lagging still
[16:29] <asac> already cleaned that up
[16:29] <asac> we uploaded openoffice with -marm and are hoping that that now works (we confirmed locally)
[16:29] <asac> main problem we are now facing is really just omap
[16:30] <asac> in particular "endless mountall+fsck loop on batteryless systems (e.g. beagle) see bug 563618"
[16:30] <asac> imx/dove are in great shape still ... so we are ready for release on that front
[16:30] <asac> besides a few RC bugs ;)
[16:31] <asac> we are waiting for archive to settle before we can try out potential workaround for "532733: qemu-kvm "apt/dpkg in qemu-system-arm hangs if a big task is installed" "
[16:31] <asac> maximus we havent found to investigate and are hoping for help on desktop team still
[16:31] <asac> bug 528887 and bug 522858
[16:32] <asac> and i am investigating our firefox rendering bug on armel my self (currently doing debug builds etc. ... that take a bit)
[16:32] <asac> bug 443147 that is
[16:32] <slangasek> I'm very unlikely to accept changes for 563618 in final - this code has flip-flopped far too many times for me to believe that someone is going to find a magic, regression-free solution to the problem in the next 2 weeks
[16:32] <asac> slangasek: hmm.
[16:32] <ogra> slangasek, i just posted a workaround this second :)
[16:32] <asac> slangasek: so in the bug there is a current workaround approach
[16:32] <asac> which does ugly stuff for BROKEN_CLOCK in initramfs ;)
[16:33] <asac> maybe check the bug
[16:33] <slangasek> if this is blocking validation of the OMAP images, I think ogra needs to hook up a battery as someone suggested on IRC
[16:33] <slangasek> ok, I'll take a look today, but I'm very hesitant to make changes here
[16:33] <ogra> slangasek, its not bugging me, i can edit fstab to not check
[16:33] <asac> ok. if you are aware of the current suggested approach and say no way, thats fine i guess
[16:33] <ogra> slangasek, it will bug all other users though
[16:34] <asac> right ... and we expect omap to be the first image that really gets good community
[16:34] <ogra> xactly
[16:34] <asac> so lets see if we can get the hacky workaround going. feels safe from what i see (if it works)
[16:34] <asac> but your say
[16:34] <ogra> indeed i can put up a wikipage that tells you how to edit /etc/fstab and /lib/init/fstab
[16:35] <asac> right. we probably can survive ;)
[16:35] <ogra> but danger is that people keep it that way and end up with corrupt filesystems
[16:35] <slangasek> asac: who have you reached out to for help on maximus?
[16:35] <asac> slangasek: desktop team through release meeting and didrocks directly
[16:35] <asac> i can poke harder
[16:36] <asac> or after firefox is fixed look on my own
[16:36] <pitti> right, this doesn't really sound like an arm specific problem, or is it?
[16:36] <pitti> (well, at least I never saw it myself)
[16:36] <asac> pitti: its not arm specific
[16:36] <slangasek> assigned the bugs to didrocks
[16:36] <pitti> right, I think he can help with this
[16:37] <asac> pitti: use the 2d launcher to see it ... if you dont have the bandwidth to help out on that it will fall back to us
[16:37] <pitti> we don't have so many RC bugs any more
[16:37] <asac> right. thats what i hoped ;)
[16:37] <pitti> asac: hm, I should try that again; last time I tried the 2d launcher it still crashed right away
[16:37] <asac> pitti: heh. that should work now. and all that dont have proper 3d get the 2d launcher now by default for netbook
[16:37] <asac> pitti: if you have problems let us know
[16:38] <asac> ... ok thats it from my side
[16:38] <asac> any questions?
[16:38] <ogra> just rip out your 3D chip from your netbook :)
[16:38] <slangasek> asac: no mention of bug #559301?
[16:38] <pitti> ogra: kvm! :-)
[16:38] <slangasek> oh, it's been marked invalid
[16:38] <asac> yes
[16:38] <slangasek> ok then
[16:38] <asac> thats what i found when preparing the report ;)
[16:38] <ogra> slangasek, no, you reviewed flash-kernel :)
[16:38] <asac> so i didnt want to raise that again ;)
[16:38] <ogra> slangasek, we dont fiddle with /boot anymore but use NAND
[16:39] <slangasek> no other questions here
[16:39] <asac> yay for NAND
[16:39] <slangasek> anyone else?
[16:39]  * ogra likes to note that omap might still show issues
[16:39] <ogra> while all pieces were tested separately there was no fully built image yet with the bits
[16:39] <asac> ogra: right. but they come as we go ;)
[16:40] <asac> no need to atlk about things that might happen ... even if we know that something is likely to happen ;)
[16:40] <ogra> if the buildds cope tonight should be the first one with all pieces in it
[16:40] <asac> right
[16:40] <ogra> just wanted to warn :)
[16:40] <asac> ok guess no other questions. thanks!
[16:41] <slangasek> [TOPIC] Kernel Team
[16:41] <MootBot> New Topic:  Kernel Team
[16:41] <slangasek> asac, ogra: thanks
[16:41] <apw> o/
[16:41] <slangasek> apw: hi
[16:41] <apw> Overall Kernel Team status is summarised at the first URL below, including the items called out in the agenda.  Most of the open work-items items are not release related at this time:
[16:41] <apw> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[16:41] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Lucid
[16:41] <apw> On the items pulled out on the agenda, the configuration review just waits the delivery of the final configuration annoucenement which has been delayed due to workload.  Of the bugs, the first one we have patches and testing is looking good, given the timing it is proposed we shoot for an early SRU for that.  The second we do not yet have root cause so I have also pushed that to lucid-updates.
[16:41] <apw> We have had to break the kernel freeze to pull in some KMS blacklist patches for a trio if i8xx graphics driver which work much better with UMS, and also for some ATI Radeon based server which were booting to blank screens.  These kernels are building now.  All (5!) others are in and built.
[16:41] <apw> We have one other more serious issue with Dell systems which overheat, patches for this have been evolving and the latest look good.  Testing on problematic MacBooks is ongoing to confirm the fix.  As we do not yet have confirmation of the fix and the machine affected boot well enough to perform an update we are proposing to SRU that fix when its complete.

[16:42] <slangasek> apw: what's the bug number for the dell heat problem?
[16:42]  * apw finds
[16:43] <apw> bug #526354
[16:43] <pitti> hm, TBH I'd rather try to squeeze that into final if possible (and resonable wrt. regression potential)
[16:43] <pitti> people run live CDs, or don't upgrade right away, etc.
[16:43] <apw> pitti, it only occurs following a s/r as far as i can tell, it took me ages to realise thats what it was
[16:43] <pitti> ah
[16:44] <apw> obviously its release teams call, but i don't think we'll have non-regression confidence on this one till early next week
[16:44] <pitti> apw: we might disable s/r on those machines as a workaround if the kernel fix doesn't land in final, perhaps?
[16:44] <pitti> (pm-utils hook)
[16:44] <apw> this is the aborted fix which broke thinkpads and macbooks so i am reticent to break them all again
[16:45] <pitti> oh, I see :)
[16:45] <slangasek> pitti: can you take an action for the pm-utils hook?
[16:45] <apw> yeah thats not a bad idea, i am not 100% sure of all the models affected
[16:45] <pitti> slangasek: I'm happy to do that once I'm told which models to blacklist it on
[16:46] <apw> i know of at least 3 dells which are affected, we could start with those i guess
[16:46] <slangasek> [ACTION] pitti to investigate pm-utils hook for final to disable s/r on dells affected by bug #526354
[16:46] <MootBot> ACTION received:  pitti to investigate pm-utils hook for final to disable s/r on dells affected by bug #526354
[16:46] <slangasek> alright - anything else?
[16:46] <apw> notihgn here
[16:47] <slangasek> apw: how soon after release are you expecting the first SRU to hit?  there are definitely some Bugs Of Interest in the list
[16:47] <apw> normally we aim for 7 days after so scoop up as much as possible of the instant bugs
[16:48] <slangasek> ok
[16:48] <apw> if you have BOI that you think should be in there, make sure i am aware of the numbers
[16:48] <slangasek> apw: they're all targeted and milestoned to lucid-updates - I'm not tracking them more specifically than that
[16:48] <apw> i will start uploading ~preN kernels shortly to the kernel preproposed PPA as they accumulate
[16:48] <apw> slangasek, good enough thanks
[16:49] <slangasek> [TOPIC] Desktop Team
[16:49] <MootBot> New Topic:  Desktop Team
[16:49] <slangasek> apw: thanks
[16:49] <slangasek> pitti: hi
[16:49] <pitti> usual weekly summary and details about RC bugs are on
[16:49] <pitti> [LINK] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:49] <MootBot> LINK received:  https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:49] <pitti> just two WIs left for final, of which one does not affect the distro (Launchpad bug filing page update) and the other is to disable the "File a bug" menu entry, which is prepared, but should happen only before the release candidate
[16:49] <pitti> this week we got a great number of RC and non-RC bugs fixed; there are two uploads in unapproved which fix a couple of bugs which really ought to hit final for a good first-time ubuntuone installation, and for fixing a rather embarrassing CD detection problem
[16:49] <pitti> the remaining open RC bugs (5) are good SRU targets and do no break installation, so I'm relatively positive that we will get a good release at this point
[16:50] <pitti> (I had one "except that one", but it just got fixed in bzr by the Kubuntu guys,  thanks!)
[16:50] <pitti> so, I think we just earned two more from this meeting, I'll add them to our page in due course
[16:51] <Riddell> Kubuntu?
[16:51] <pitti> please
[16:51] <Riddell>  * daily's looking in decent shape for RC
[16:51] <Riddell>  * New logo in and everyone happy
[16:51] <Riddell>  * tinyurl.com/yjybcx9 milestoned bugs down to three (once Ubiquity uploaded)
[16:52] <Riddell> some ubiquity bugs needs more checking though
[16:52] <cjwatson> which ones?
[16:52] <Riddell> bug 538505 amichair has said he'll look into, but we can live with it
[16:52] <cjwatson> yeah, I agree with your assessment
[16:52] <Riddell> bug 538505 I couldn't recreate on virtualbox 538505
[16:52] <Riddell> I'll try it on real hardware later
[16:52] <cjwatson><PHONE_NUMBER>05 538505
[16:53] <cjwatson> sorry :)
[16:53] <Riddell> bug 563309
[16:53] <Riddell> that's the one
[16:53] <slangasek> Riddell: on kdesdk, there's also a recommends: on optipng, same problem - do you want to look at that Recommends as well and decide which way to go before I accept kdesdk, and save us some build time?
[16:53] <cjwatson> I guess that's one I can look at
[16:53] <cjwatson> bit of an art to debugging those state machine assertions
[16:54] <Riddell> and bug 528678 I need to check although installing in French worked fine last I tried
[16:54] <Riddell> slangasek: oh fooey, will do
[16:54] <Riddell> we have uploads of kdepim and kdebase-workspace outstanding
[16:55] <slangasek> pitti: the ubuntuone-client upload in unapproved unfortunately breaks string freeze, dpm has nacked it and I agree with him; do you have time yet today to follow up with Chipaca, to get that change dropped?
[16:55] <cjwatson> hmm, I thought 528678 had been fixed somewhere down the road, but I agree it's worth checking
[16:55] <pitti> slangasek: not myself any more, but I'll delegate it to Ken
[16:55] <pitti> (in fact I already talked to him)
[16:57] <slangasek> pitti: was more looking for the release team side of it; ok, I'll circle around with Chipaca and Ken
[16:57] <pitti> slangasek: ah; sorry, not today any more from me
[16:57] <pitti> I can have a look at the queue tomorrow morning, though
[16:58] <slangasek> hopefully we'll have it done before that :)
[16:58] <slangasek> Riddell: when do you expect those uploads to happen?
[16:58] <Riddell> slangasek: imminently
[16:58] <slangasek> ok
[16:59] <slangasek> no other questions from me; anyone else
[16:59] <slangasek> ?
[16:59] <slangasek> [TOPIC] DX Team
[16:59] <MootBot> New Topic:  DX Team
[17:00] <slangasek> pitti, Riddell: thanks
[17:00] <slangasek> davidbarth: hi
[17:00] <davidbarth> slangasek: hi
[17:00] <davidbarth> (i'm on a call at the same time, but here is the list of bugs on our list)
[17:00] <davidbarth> https://bugs.launchpad.net/ayatana/+milestone/ubuntu-10.04
[17:00] <slangasek> davidbarth: I had put bug #522858 to you, thinking this was something njpatel worked on; but I guess you're off the hook for that one :)
[17:00] <slangasek> [LINK] https://bugs.launchpad.net/ayatana/+milestone/ubuntu-10.04
[17:00] <MootBot> LINK received:  https://bugs.launchpad.net/ayatana/+milestone/ubuntu-10.04
[17:00] <davidbarth> yeah, i've seen this one
[17:01] <davidbarth> i don't have an answer yet, but i'll action it for sure between njpatel and DBO
[17:01] <davidbarth> apart from that, so ted has been working on fixing some dbusmenu issues
[17:01] <davidbarth> there is one that is still not fixed and uploaded, being:
[17:01] <davidbarth> #549096	Duplicate Broadcast Icons in Indicator Applet
[17:02] <davidbarth> but he's on it and hopes to have a fix for this one today
[17:02] <davidbarth> seb128 has just pointed out a crasher also, we're just adding id to our bug roster
[17:03] <slangasek> alright
[17:03] <davidbarth> the auto-mnemonics one will be for an sru, too involved and late at this stage (that's #548652	menu mouse-scrolling broken, when themes enable gtk-auto-mnemonics)
[17:03] <davidbarth> and last
[17:03] <davidbarth> we've noticed an issue with the kmail patch that doesn't work great with the gnome desktop
[17:04] <davidbarth> agateau is on this one since this afternoon and rushing to get a proper fix
[17:04] <davidbarth> that's it for DX
[17:04] <slangasek> ok, thanks
[17:04] <slangasek> anyone have questions?
[17:05] <slangasek> [TOPIC] Foundations Team
[17:05] <MootBot> New Topic:  Foundations Team
[17:05] <slangasek> davidbarth: thanks again
[17:05] <slangasek> cjwatson: hi
[17:05] <pitti> kmail> I suggested to back that out, BTW
[17:06] <cjwatson> [LINK] https://wiki.ubuntu.com/FoundationsTeam/ReleaseStatus/Lucid
[17:06] <MootBot> LINK received:  https://wiki.ubuntu.com/FoundationsTeam/ReleaseStatus/Lucid
[17:06] <cjwatson> Bug 534743 needs a patch from a dmraid expert (possibly psusi?); we have suitable people for the other bugs there
[17:06] <cjwatson> (discussing on #ubuntu-devel, too)
[17:06] <cjwatson> Other issues that have arisen:
[17:06] <cjwatson>  * grub2 menuentry quoting change broke both pygrub and os-prober; both of those have been fixed, but it raises the possibility that there may be other programs parsing grub.cfg wrongly (e.g. GRUB menu editors?).  Unfortunately attempting to use double quotes and escape things properly appears to break grub2 for reasons as yet unclear, so we may have to live with this and fix programs like menu editors in SRUs.
[17:06] <cjwatson>  * Design requested changes to the CD boot splash screen; I want to check some details of that with Mark before making the changes
[17:06] <cjwatson>  * Marjo raised a partitioning constraint handling bug that seems to be still hanging around: bug 558382
[17:06] <cjwatson>  * Bug 563117 isn't milestoned at present, but seems concerning if reproducible
[17:06] <cjwatson> Good news: oem-config/server appears to actually work now; we're out from under most of the pile of customer priority bugs
[17:06] <cjwatson> --
[17:07] <slangasek> 534743 already has a branch linked, is that one not adequate?
[17:07] <cjwatson> Scott objected to it in comment 4
[17:07] <cjwatson> I'm trying to find out whether that objection still stands
[17:07] <slangasek> ok
[17:07] <Keybuk> I'm not sure it does
[17:08] <Keybuk> why is bug #563117 on mountall ?!
[17:08] <cjwatson> "but practically speaking, dmraid disks don't have any circumstances where they emit a change event other than this, AFAICS"
[17:09] <cjwatson> so that may not be an issue
[17:09] <persia> Keybuk: Because alvin chose that package, and nobody has been able to figure out where it belongs yet.
[17:09] <Keybuk> persia: why is it a bug?
[17:09] <cjwatson> Keybuk: because kirkland muttered on #ubuntu-server that that was where he thought it lived
[17:09] <Keybuk> that seems like deliberate behaviour to me
[17:09] <cjwatson> I commented that it probably belonged somewhere else
[17:09] <cjwatson> /dev/mapper/ names should be stable, and they're more explanatory than UUIDs
[17:09] <persia> Keybuk: Renders systems unbootable with snapshots of system partitions because they share the same UUID
[17:09] <Keybuk> yes, but that then wouldn't allow you to move the filesystem *off* RAID to a normal disk
[17:09] <cjwatson> we've long taken the approach that we don't UUIDify names that are already stable
[17:09] <Keybuk> which we want to support
[17:10] <Keybuk> persia: lies.  only one emits the UUID in its event
[17:10] <cjwatson> if that change was intentionally made, it might have been nice if somebody had informed the installer team
[17:10] <Keybuk> cjwatson: we changed that approach in karmic iirc
[17:10] <cjwatson> meanwhile, I think that upgrades should be consistent with installs
[17:10] <Keybuk> I'm pretty sure you were in the BOF at the time ;)
[17:10] <persia> Keybuk: OK.  Alvin tested quite a bit.
[17:10] <cjwatson> I have absolutely no memory of this
[17:10] <cjwatson> it is entirely new to me
[17:11] <cjwatson> anyway, what's making the change on upgrade?  I couldn't find the operative code
[17:11] <cjwatson> there used to be stuff in volumeid or something years ago
[17:11] <Keybuk> do-release-upgrade isn't it?
[17:11] <cjwatson> oh, it's in update-manager itself
[17:11] <cjwatson> ?
[17:11] <Keybuk> I thought we moved that stuff there, yeah
[17:12] <cjwatson> nope
[17:12] <cjwatson> no matches
[17:12] <Keybuk> you're right that nothing calls blkid or vol_id in postinst anymore
[17:12] <cjwatson> it was apparently there at one point for upgrades to hardy
[17:12] <Keybuk> maybe the reporter is hallucinating
[17:13] <Keybuk> and their fstab never had /dev/mapper entries <g>
[17:13] <cjwatson> two hallucinations, persia reproduced it
[17:13] <slangasek> I was checking an LVM-using desktop I just upgraded here and found that it has UUIDs in fstab, but the fstab is 2 years old
[17:14] <cjwatson> for the record, I'm not going to change the installer for this now - can't afford the retesting time :-/
[17:14] <slangasek> so that doesn't count
[17:14] <slangasek> Keybuk: only one emits the UUID - ok, but which one?
[17:14] <Keybuk> slangasek: whichever one kees thinks should this week, usually
[17:14] <Keybuk> he's changed it at least three times ;-)
[17:15] <persia> Regarding relesae-criticality: there are two trivial workarounds: a) don't snapshot system filesystems, b) edit fstab
[17:15] <Keybuk> cjwatson: I've checked my changelogs, I *deleted* the fstab migration script ages ago
[17:15] <slangasek> Keybuk: sure; further evidence that the /dev/mapper names are the stable ones we should use...
[17:15] <Keybuk> so I'm not aware of it existing anywhere
[17:15] <Keybuk> slangasek: those are set by the same rules
[17:16] <slangasek> Keybuk: er, snapshots have unique lvm names, so that shouldn't be an issue
[17:16] <Keybuk> anyway
[17:16] <Keybuk> this is LVM :)
[17:16] <Keybuk> you can make it do whatever broken things you want <g>
[17:17] <slangasek> persia: if you were able to reproduce this, do you mind sending an upgrade log to the bug?
[17:18] <persia> slangasek: I hadn't considered a bug when I reproduced it (some time ago), and only ack'd it when alvin was testing and reported it.  I'll see if I can get my test laptop to recognise it's HD again, and reproduce there (my test server doesn't play with LVM well).
[17:18] <slangasek> ok
[17:19] <persia> (if anyone with better current HW availability wants to do this before me, I shan't complain)
[17:20] <slangasek> alright - anything else on Foundations?
[17:20] <slangasek> [TOPIC] Security team
[17:20] <MootBot> New Topic:  Security team
[17:20] <slangasek> cjwatson: thanks
[17:20] <slangasek> jdstrand: hi
[17:21] <jdstrand> hi!
[17:22] <jdstrand> as always https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid
[17:22] <jdstrand> nothing really new there, so I probably won't reference it again
[17:22] <slangasek> [LINK] https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid
[17:22] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Lucid
[17:23] <jdstrand> I mentioned last week we'd be doing install audits. that didn't happen this week, but is planned for next
[17:23] <slangasek> ok
[17:23] <jdstrand> it seems bug #528274 stalled. I unmilestoned it-- it should probably be taken off the list
[17:23] <slangasek> ack
[17:24] <jdstrand> in other news, mvo disabled apparmor on hardy to lucid upgrades (but reenabled on reboot), to make sure that bugs in the Hardy with a new apparmor userspace and profiles won't affect the install
[17:24] <jdstrand> there was a bind9 bug that prompted this, but it is resolved now
[17:24] <jdstrand> (in update-manager)
[17:24] <jdstrand> Other than that, we are continuing to do bug fixing and make sure lucid is up to date on security updates.
[17:25] <ScottK> It's worth mentioning that yesterday was death day for clamav < 0.95 and I'm watching people in #clamav who run other distros scream and shout.  So far one Ubuntu user showed up and he'd kept the old clamd.conf by mistake.  Thanks for the security team's work on this.
[17:25] <jdstrand> we are going to go through our cve-tracker to make sure lucid is in excellent shape
[17:25] <slangasek> jdstrand: is it, or are you still in the process of making sure?
[17:26] <jdstrand> ScottK: well, we shoved it through with some testing, but thanks really should go to you (and cemc) for your testing and thoroughness on the upgrade process
[17:27] <ScottK> One Ubuntu bug to which the reply was "enable updates and upgrade."
[17:27] <ScottK> Thanks
[17:27] <jdstrand> slangasek: we are always triaging CVEs with up to date info, but we give a big push prior to release to make sure
[17:27] <slangasek> ok
[17:27] <jdstrand> slangasek: we are in the process of the big push
[17:27] <slangasek> sounds good
[17:27] <jdstrand> it is a little harder to keep up with the dev cycle since we don't see all the syncs and merges, etc
[17:28] <jdstrand> so our tracker can lag a bit at times
[17:28] <jdstrand> anyhoo, that is just a procedural thing our team does each cycle
[17:28]  * slangasek nods
[17:28] <slangasek> anything else for security?
[17:28] <jdstrand> and that is it for me, unless anyone has questions
[17:29] <slangasek> [TOPIC] MOTU
[17:29] <MootBot> New Topic:  MOTU
[17:29] <slangasek> jdstrand: thanks
[17:29] <jdstrand> ScottK: yeah, that was a funny bug :)
[17:29] <jdstrand> slangasek: sure! :)
[17:29] <ScottK> Hello.
[17:29] <slangasek> ScottK, sistpoty|work: hi
[17:29] <sistpoty|work> hi
[17:29] <ScottK> james_w get the NBS hero award.
[17:29] <ScottK> get/gets
[17:30] <ScottK> We're closing in on that.
[17:30] <slangasek> quite!
[17:30] <ScottK> I hope that main upload slow down at some point so the buildds can drain.
[17:31] <ScottK> sistpoty|work: Do you have anything to report?
[17:31] <ScottK> We need to keep up with FFe's, but I think things are in reasonable shape.
[17:31] <sistpoty|work> only that ghc6 made it on armel, and I keep the queue full with rebuilds of the haskell stack :)
[17:31] <pitti> the tetex NBS stuff is all removed now, too
[17:32] <pitti> the rest of NBS doesn't look that worrysome any more
[17:32] <sistpoty|work> others than that nothing from me
[17:32] <ScottK> We still need more push on FTBFS
[17:32] <sistpoty|work> s/rebuilds/give backs/
[17:34] <slangasek> ScottK: is lucas's build results page the active work list for FTBFS?
[17:34] <ScottK> slangasek: I think it's the best one to use.
[17:34] <ScottK> It will catch any that FTBFS due to removals.
[17:35]  * slangasek nods
[17:35] <slangasek> I still need to get the "freeze is on" mail out today, I'll include a pointer
[17:35] <ScottK> doko just delivered his list in #ubuntu-release and it's not as short as I'd hoped.
[17:36] <ScottK> We need a recipe for assessing those and trying to fix them.
[17:36] <slangasek> hmm, yes
[17:36] <slangasek> I'll follow up on that today as well
[17:37] <ScottK> Great.
[17:37] <slangasek> anything else before we adjourn?
[17:37] <ScottK> I don't think so.
[17:37] <slangasek> #endmeeting
[17:37] <MootBot> Meeting finished at 11:37.
[17:37] <slangasek> thanks, all!
[17:37] <pitti> thanks everyone
[17:37] <apw> slangasek, thanks


[13:36] <tsimonq2> guiverc_t: Urgh, you're right, I KNEW I was forgetting something >__<
[13:37] <guiverc_t> tsimonq2, it was caught, no harm done :)
[13:38] <tsimonq2> Done.
[23:35] <tsimonq2> 16.10 EOL announcement posted to Fridge
[23:36] <tsimonq2> http://fridge.ubuntu.com/2017/07/20/ubuntu-16-10-yakkety-yak-end-of-life-reached-on-july-20-2017/


[07:14] <lazyPower|Sprint> ChinnoDog: makes sense
[09:16] <rmg51> Morning
[12:14] <teddy-dbear> Morning peoples,dogs, turkeys, hamsters and everything else
[14:03] <ChinnoDog> morning
[14:04] <ChinnoDog> Windows 8.1 runs remarkably fast on KVM.
[19:00] <jthan> JonathanD: :-/ Figures
[22:00] <ChinnoDog> I am backing up my Windows drive from Ubuntu while Windows is running. That is neat.


[12:19] <wgrant> tjaalton: Are you likely to have time in the next few days for the property stuff, or shall I attempt to give some time to it this weekend?
[12:20] <tjaalton> wgrant: I should have time, yes.. last week turned out to be quite busy
[12:20] <wgrant> tjaalton: OK, thanks. I've got a lot of assignments on the go, but I can probably find time to look at it if necessary.
[12:25] <tjaalton> it should be brown-paper-bag'ish stuff, so hopefully won't take long to find out :)
[12:26] <wgrant> Yep.


[08:52] <wgrant> ec2 test didn't detach for me earlier. Is that known?
[09:07] <jml> wgrant, it's not unknown
[09:07] <jml> wgrant, but I don't think anyone knows the root cause
[09:08] <jml> wgrant, or how to reproduce the problem.
[09:55] <al-maisan> question: does the the owner of an object has permission="launchpad.Edit" by default?
[09:57] <wgrant> No.
[09:58] <al-maisan> wgrant: thanks !
[11:02] <jtv1> Oops while approving an MP :-(
[11:05] <jtv> Any Code folks left?
[11:05] <jtv> abentley, are you here?
[11:08] <jtv> guess not... rockstar maybe?
[11:11] <jtv> Seems I can still review, but I need to claim the review first.  Otherwise, oops.
[11:20] <jtv> adiroiban: err... did you break rosetta-admin permissions?  :-)
[11:21] <adiroiban> jtv: hi. yep
[11:22] <adiroiban> jtv: can you please point me to the bug report you are concerned about?
[11:22] <jtv> adiroiban: we don't have one yet... just getting word from dpm that he can't do his work.  :-)
[11:22] <adiroiban> jtv: hm.. the about about lucid being closed?
[11:23] <adiroiban> or other problems?
[11:23] <dpm> adiroiban, jtv, that's not blocking my work, so don't worry
[11:23] <jtv> adiroiban: completely different... we suddenly can't change the translation settings for a project any more
[11:25] <adiroiban> jtv: also a direct access to the url is not working?
[11:26] <jtv> adiroiban: permission denied.
[11:27] <dpm> jtv, what's the usual URL to change the translation permission settings?
[11:27] <adiroiban> jtv: can you please fill a bug report and I will try to fix it.
[11:28] <adiroiban> basicaly we just need to replace launchpad.Admin with launchpad.TranslationsAdmin
[11:28] <jtv> dpm: +changetranslators
[11:29] <jtv> adiroiban: that'd be great... but if you end up cleaning up a mess made by the rest of us, that'd be pretty embarrassing.  :-)
[11:29]  * jtv files bug
[11:31] <dpm> jtv, thanks. And do you know where that URL normally is accessible through the UI? Is it at https://translations.launchpad.net/project, under the Permissions section? (I'm thinking in terms of updating the help page)
[11:31] <jtv> dpm: right under where it says "is translated with <Open> permissions" there should be a "Change permissions" link
[11:31] <dpm> jtv, thanks!
[11:32] <jtv> dpm: btw can we still edit this for Ubuntu?
[11:32] <adiroiban> jtv: I can do that as a project owner
[11:33] <jtv> Wow...  there is a bug that *looks* like it's about this, but it's bug 127171
[11:33] <mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:Triaged> <https://launchpad.net/bugs/127171>
[11:33] <jtv> adiroiban: just trying to get an idea of the scope of the bug, but you bring up a good point: is rosetta-admins in utc?
[11:33] <adiroiban> jtv: nope
[11:34] <adiroiban> rosetta admin and distribution translations owners are two different groups
[11:34] <adiroiban> jtv: this looks like an old bug
[11:34] <jtv> indeed
[11:34] <adiroiban> my permission changes landed only a few days ago
[11:35] <dpm> adiroiban, jtv, are you talking in terms of LP teams? Rosetta admins is part of https://launchpad.net/~ubuntu-translations-coordinators/+members#active
[11:36] <jtv> that's what I meant... it means that we can't see in Ubuntu whether this affects distros as well
[11:36] <jtv> But yes, this looks like an old problem.  adiroiban: see, almost got into that embarrassing situation there :-)
[11:37] <jtv> sorry for impugning you.
[11:37] <adiroiban> jtv: the distribution translation group owners needs some more permission. Ex there is bug 347143
[11:37] <mup> Bug #347143: Distro translation group owners should be able to manage language packs <Launchpad Translations:Triaged by adiroiban> <https://launchpad.net/bugs/347143>
[11:38] <adiroiban> jtv: np. I have done some changes in the security.py and I should be able to fix those bugs
[11:39] <adiroiban> jtv: there is as a thread on launchpad-dev ML about the current mess from LP security system
[11:39] <jtv> "Where to put security-related code"?
[11:40] <adiroiban> yes
[11:41] <adiroiban> and the thread went beyond the subject with „how to write security classes”
[11:41] <adiroiban> and how we should handle security in LP cpde
[11:41] <adiroiban> code
[11:42] <henninge> adiroiban: the conclusion was *not* to use checkAuthenticated outside of security.py
[11:42] <adiroiban> henninge: yep
[11:43] <jtv> makes sense
[11:43] <jtv> although I'm not sure we can always avoid it... henning, didn't you work on one of those instances as part of the +translate rework?
[11:50] <henninge> adiroiban: I am about to land the branch that makes more use of permission_helpers.py. I will have to make another branch to remove it again. Just so you know.
[11:50] <henninge> jtv: I don't remember anything like tha.
[11:50] <henninge> t
[11:51] <jtv> henninge: it's a pretty vague memory, so never mind...  There was some spot or other where things got complex enough (translation team membership etc.) that we had a customized check.
[11:51] <henninge> jtv: customized checks are ok
[11:52] <henninge> jtv: adi had suggested to import the checker classes from security.py and call checkAuthenticated in model code.
[11:53] <henninge> or was it view code? no, we have check_permission for that.
[11:56] <jtv> ah I just had it the wrong way around... this is the kind of stuff I figure out when I need it, then forget again.  :)
[11:56] <jtv> anyway I'll read and archive that thread for next time.
[11:57] <adiroiban> henninge: I will not touch the model security code until we have the security_helper fixed
[11:57] <adiroiban> henninge: so I will wait for you changes
[11:57] <adiroiban> your
[12:00] <henninge> adiroiban: permission_helper is still in there. There is nothing that needs to be "fixed" as it is just a collection of helper method which are optional.
[12:00] <henninge> adiroiban: I am not sure I will get around to removing it very soon.
[12:01] <adiroiban> henninge: ah. my impression was that you were going to rename it to security_checker.py
[12:01] <henninge> adiroiban: no, that was just an idea.
[12:01] <adiroiban> and change isUser to canDoSomethibng
[12:01] <adiroiban> isRosettaAdmin to canAdministerRosetta
[12:01] <adiroiban> or something like that
[12:02] <henninge> adiroiban: no, what I am thinking of is an extension to Person objects so that they have attributes like "is_admin" for celebrity groups.
[12:03] <henninge> so, that would include is_rosetta_expert
[12:03] <adiroiban> henninge: ok. I am still fuzzy with permission handling in LP. so don't worry about me
[12:03] <henninge> adiroiban: but "can*" methods are specific to model classes, so they should appear there.
[12:04] <henninge> adiroiban: that's the concept that you didn't like, remember?
[12:04] <henninge> ;-)
[12:05] <adiroiban> yep
[12:21] <adiroiban> jtv, henninge: Right now launcpad.Edit is required for +changetranslators for IProduct and IProject. Adding rosetta admins to launchpad.Edit will also give other edit rigths (non related to translations). Should I use launchpad.TranslationsAdmin or just go with the current launchpad.Edit ?
[12:22] <henninge> adiroiban: I think lp.TranslationsAdmin is better.
[12:22] <jtv> adiroiban: this should definitely be limited to Translations settings
[12:22] <jtv> so what henning said.  :)
[12:23] <henninge> adiroiban, jtv, dpm, everybody else: Happy Holidays, enjoy any of them you might have, see you next year! :-)
[12:23] <adiroiban> jtv, henninge: OK.
[12:23] <jtv> henninge: happy holidays!
[12:23] <jtv> it was a pleasure working with you in 2009; see you in 2010
[12:23] <dpm> henninge, happy holidays to you as well!
[12:24] <adiroiban> henninge: ohohooo Happy holidays!
[12:24] <jtv> (or 2552 and 2553 respectively, here)
[12:24] <adiroiban> :)
[12:24] <henninge> jtv: same here
[12:24] <henninge> ;)
[12:45] <adiroiban> how can I create a project-group like https://edge.launchpad.net/unr
[12:45] <adiroiban> ?
[12:46] <adiroiban> ah... using partof
[12:48] <wgrant> Only admins can create them.
[12:49] <adiroiban> wgrant: thanks. I was a bit confused by IProduct and IProject
[12:51] <wgrant> product in the code == project in the UI. project in the code == project group in the UI.
[12:51] <wgrant> Yay for renaming things in the UI years ago, but not in the code.
[12:51] <adiroiban> yep
[12:52] <adiroiban> but still, a project is also somehow a product
[12:53] <wgrant> It's not.
[12:53] <wgrant> What gives you that idea?
[12:53] <adiroiban> well, I'm looking at registry/configure.zcml
[12:53] <adiroiban> for IProduct and IProject „translationpermission” attribute
[12:54] <adiroiban> I set the translationpermission attribut as requiring launchpad.TranslationsAdmin (RosettaAdmin)
[12:54] <wgrant> I don't see that for IProject.
[12:55] <adiroiban> and it's working for a project
[12:55] <adiroiban> but not for a project group
[12:55] <adiroiban> wgrant: right. me neither
[12:55] <wgrant> There's no TranslationsAdmin permission for IProject.
[12:57] <adiroiban> wgrant: True. That is the bug I am working on right now. bug 127171
[12:57] <mup> Bug #127171: Rosetta experts not allowed to "Change translators" <Launchpad Translations:In Progress by adiroiban> <https://launchpad.net/bugs/127171>
[12:58] <adiroiban> wgrant: Don't worry. I'll try to figure out what is wrong
[12:59] <wgrant> adiroiban: What do you see is wrong?
[12:59] <adiroiban> wgrant: I got this error: Unauthorized: (<Project at 0xd83934c>, 'translationpermission', 'launchpad.Edit')
[12:59] <wgrant> IProject.translationpermission comes from IHasTranslationGroup.
[13:00] <adiroiban> but in configure.zcml I have http://paste.ubuntu.com/345899/
[13:00] <wgrant> IProjectPublic inherits from IHasTranslationGroup
[13:00] <wgrant> And registry/configure.zcml requires launchpad.Edit to set IProjectPublic.
[13:00] <adiroiban> wgrant: thanks!
[13:16] <adiroiban> wgrant: and in this case how can I move translationpermission for Project from launchpad.Edit to launchpad.TranslationsAdmin ?
[13:16] <adiroiban> change IProjectPublic not to inherit from IHasTranslationGroup ?
[13:17] <wgrant> adiroiban: I think that might be best.
[13:17] <wgrant> adiroiban: Alter IProject to inherit directly from it.
[13:17] <adiroiban> wgrant: I am worried about the side effects
[13:17] <wgrant> adiroiban: Then make IHasTranslationGroup readable using launchpad.View, and writable with launchpad.TranslationsAdmin. You can probably then remove the explicit declarations about IProduct.
[13:17] <adiroiban> I see
[13:17] <wgrant> adiroiban: That's why we have a test suite.
[13:18] <wgrant> I don't think there should be a problem; those subclasses are meant to just be used for permissions.
[13:18] <adiroiban> ah. ok
[13:26] <adiroiban> wgrant: schema is for reading and set_schema for writing?
[13:26] <wgrant> adiroiban: interface for reading.
[13:28] <adiroiban> wgrant: thanks!
[13:31] <adiroiban> wgrant: instead of <require permission="launchpad.View" interface="x" />, can I just use <allow interface="X"/> ?
[13:31] <adiroiban> this is the current configuration for IProjectPublic
[13:31] <wgrant> adiroiban: Ah, yes, that makes sense for objects that don't have launchpad.View (because they're public)
[13:32] <wgrant> So, yes, <allow> is the right thing to use here.
[13:33] <adiroiban> what is the purpose/usage of launchpad.View or how it is different from zope.Public?
[13:35] <wgrant> It's used mostly for objects that can be private.
[13:35] <wgrant> zope.Public is always held.
[13:36] <adiroiban> Thanks!
[13:37] <adiroiban> the bug should be now fixed... will see what tests have to say
[14:44] <adiroiban> jtv: for distributions, +changetranslators is +settings ? I was thinking to have a single name for that view
[14:44] <jtv> adiroiban: makes sense... it's the same form, right?
[14:44] <adiroiban> yes
[14:44] <adiroiban> same attributes can be changed
[14:44] <adiroiban> translationgroup translationpermission
[14:45] <adiroiban> should I go with +settings ?
[14:45] <adiroiban> beside translators, translations policy is also set from this view
[14:53] <adiroiban> jtv: well... they have the same fields... but are different views
[14:53] <adiroiban> same template
[14:54] <adiroiban> ProjectChangeTranslatorsView , ProductChangeTranslatorsView and DistributionChangeTranslatorsView
[14:55] <adiroiban> maybe we can put them on the same IHasTranslationsGroupView
[14:55] <jtv> adiroiban: don't we already have a +settings for projects?
[14:55] <jtv> ah, that's for productseries
[14:56] <adiroiban> jtv: there is +translations-settings
[14:56] <adiroiban> hm...
[14:56] <jtv> but it's still for the series, not the project
[14:56] <adiroiban> nope... +translations-settins is for IProduct
[14:57] <adiroiban> sorry IProductSeries
[14:57] <jtv> that gives me a 404 though
[14:57] <jtv> right
[14:57] <jtv> So +settings makes sense to me... I'm just not sure why +translations-settings isn't called +settings as well
[14:58] <adiroiban> jtv: maybe , the one implementing it was worried not to owerwrite a general +settings page for „main”
[14:59] <adiroiban> jtv: but I could not find any other +settings page
[14:59] <jtv> adiroiban: that made sense a long time ago, before we had separate namespaces for our different hostnames...  but I don't see anything in there that's that old
[14:59] <adiroiban> other than in translations
[15:00] <adiroiban> jtv: then maybe I can also rename +translations-settings to +settings
[15:00] <jtv> (The stuff that's on +tranlsations-settings barely predates the source tree split)
[15:00] <jtv> adiroiban: bear in mind that it may involve updating the help site as well...
[15:00] <adiroiban> it is strage there are no other +settings view in the other lp components
[15:05] <adiroiban> jtv: those lines were last touched by Danilo, so maybe he can give us some hints
[15:05] <jtv> adiroiban: that may have been from the codebase split though
[15:05] <jtv> when we broke the source tree down by app (code, translations, bugs, etc)
[23:56] <_Groo_> hi/2 all


[03:28] <fairuz> helo2
[05:01] <ejat> ello
[06:36] <excalibr> aik fairuz
[07:03] <fairuz> excalibr: yo
[07:10] <excalibr> apa dah berlaku lol
[07:10] <excalibr> tiba2 hilang
[13:48] <fairuz> ejat: yo
[14:46] <ejat> elo govatent
[14:50] <govatent> hey ejat
[14:50] <govatent> how's it going?
[14:51] <ejat> flu + fever +cough
[14:51] <govatent> :( sorry to hear it. Hope it goes away quickly
[14:51] <ejat> yeah .. hopefully ..
[14:51] <ejat> sorry for the last wechat
[14:52] <ejat> got something else todo at the office
[14:52] <ejat> then forgot to reply
[14:53] <govatent> it's cool. I was telling chloric to add you on wechat as well
[14:53] <govatent> I'm going to see him next weekend. I am having an Ubuntu release party in Miami
[14:55] <ejat> c00l ...
[14:56] <ejat> i wish we can gather again !! and celebrate your "birthday"
[14:56] <ejat> hahahaha
[14:56] <govatent> LMAO
[14:56] <govatent> good times.
[14:56] <govatent> I still have that picture.
[14:56] <govatent> I miss you all.
[14:57] <ejat> yeah ... me too !!!
[14:57] <ejat> now ... vUDS ... dont know either i can meet chris anymore in the feature ...
[14:57] <govatent> Soon i will get to go to MY. If anything I could end up in singapore for work.
[14:58] <ejat> \0/
[14:59] <govatent> are you going to the next uds?
[15:01] <ejat> next should be vuds again right ?
[15:02] <govatent> i'm not sure
[15:03] <ejat> :)
[15:09] <govatent> oh ejat , I just got a 500 GB samsung SSD for my system76 ubuntu laptop.
[15:09] <govatent> I'm gonna install it next week cause I'm holding off to do a clean install of 13.04
[15:11] <ejat> what !!!!!!
[15:11] <ejat> got for free ?
[15:11] <ejat> system76 got ultrabook ?
[15:19] <govatent> no i bought the ssd. And i bought the system76 laptop last year. It's been the best ubuntu computer ever!
[15:19] <ejat> :)
[15:20] <ejat> now im using raring natively in my mbp
[15:20] <ejat> but its old mbp .. still cant make the nvidia work ..
[15:21] <ejat> so now im in kde .. unity ... not stable enough for me .. its will crash ...
[15:22] <mypapit> wow
[15:23] <mypapit> what kind of apps that  you are running  while in unity?
[15:38] <govatent> I saw your posts about that
[15:38] <govatent> Was there an update that caused it? Were you able to reset the nvidia drivers?
[15:39] <govatent> I ran into an issue with the installer for 13.04 and it won't let me install on my desktop. It's something that will be fixed soon.
[16:14] <ejat> nouvea
[16:14] <ejat> not using nvidia


[12:47] <mup> Bug #1645707 opened: DHCP is not responding to PXE boot requests <MAAS:New> <https://launchpad.net/bugs/1645707>
[13:34] <john75077> hello, i am looking to understand how to get multiple physical machines to communicate with lxc in 16.04. the directions seem to work out ok on a single machine, how do i enlist more lxc ?
[14:04] <roaksoax> john75077: juju registers lxc containers in MAAS, MAAS doesn't manage LXC containers at all
[14:05] <john75077> so i want to go down the road of using conjure-up?
[14:06] <roaksoax> john75077: you can use conjure-up with MAAS
[14:07] <john75077> so then how does that change how to commission nodes? or setup more lxc containers and have them 'spin up' like regular vm's?
[14:07] <roaksoax> john75077: conjure-up drives Juju
[14:08] <roaksoax> john75077: juju has many different providers to deploy services
[14:08] <roaksoax> juju can use MAAS as a provider to deploy physical machines
[14:08] <roaksoax> juju can use LXD to deploy containers in a single machine
[14:08] <roaksoax> juju can use AWS to deploy instances etc
[14:09] <john75077> right, im looking at starting with a small POC across 5 or 10 machines and if all goes well scale out
[14:09] <roaksoax> john75077: when you use MAAS as a provider, for example, juju can deploy a service on a physical machine, and can deploy other services inside a LXC container inside the physical machine that it previously deployed
[14:09] <roaksoax> john75077: when juju does that with MAAS, juju tells MAAS "hey, I created a new container, please register and give it an IP address"
[14:10] <roaksoax> john75077: i've not used conjure-up lately, but you can use conjure-up with MAAS
[14:10] <roaksoax> john75077: 'stokachu' is the best to help
[14:11] <john75077> the maas world has changed a lot, the last time i messed with this was in 12.04 and 14.04
[14:13] <roaksoax> john75077: yeah we've come a long way since 12.04 and 14.04
[14:13] <roaksoax> 12.04 MAAS sucked
[14:13] <roaksoax> 14.04 and 1.7 is where we started improving it quite a bit
[14:14] <john75077> i wrote some pretty good stuff in 'ask' a long time ago
[14:29] <john75077> using conjure-up on a clean install, what is it exactly looking for?
[14:35] <john75077> never mind - picked the wrong option
[14:50] <mup> Bug #1645707 changed: DHCP is not responding to PXE boot requests <MAAS:Invalid> <https://launchpad.net/bugs/1645707>
[16:57] <vmorris> does Mark Shuttleworth often respond to general questions that pop up on the MAAS mailing list? That impressed me :)
[17:14] <roaksoax> vmorris: he is very active across all products
[17:16] <vmorris> roaksoax, i wasn't aware.. that's neat
[17:17] <roaksoax> vmorris: hehe, it is indeed. He is very involved with the whole process
[17:42] <mup> Bug #1645807 opened: [web UI] Rename deployed and deploying statuses and add a column <docteam> <MAAS:New> <https://launchpad.net/bugs/1645807>
[17:43] <xopis> Hey guys, how's it going? I just installed maas with the objective to use it as a IPAM (IP address management) tool and I'm having problem to find any documentation on this feature. Can anyone give me some starting tips?
[17:48] <pmatulis> xopis, what specifically do you want to know? maas keeps track of all IP addresses being used
[17:49] <xopis> pmatulis, I wanted to use it only to control the IP address space.
[17:51] <xopis> Only to check what IPs are being used, what IPs I have available and so on.
[17:55] <xopis> with out using maas to manage and deploy those servers
[18:12] <mup> Bug #1645807 changed: [web UI] Rename deployed and deploying statuses and add a column <docteam> <MAAS:Won't Fix> <https://launchpad.net/bugs/1645807>
[18:13] <pmatulis> xopis, i guess you can give it a try
[19:34] <john75077> hi all, i am wanting to use the conjure up tool and wanting to deploy openstack through lxd. what is the best way to get this started?
[19:37] <pmatulis> john75077, get a big machine
[19:38] <john75077> ok, i have big machines
[19:40] <pmatulis> john75077, go to http://conjure-up.io/
[19:40] <john75077> i did that and now im here
[19:41] <john75077> the documentation isnt clear about what to do next
[19:42] <mmcc> hi john75077, I am happy to help you with conjure-up for a bit, would you mind moving to #ubuntu-solutions, as it sounds like this isn't really a maas question?
[19:42] <john75077> sure - i was going to use conjure-up for deploying maas via lxd
[19:43] <mmcc> deploying maas or openstack? earlier you said openstack
[19:44] <mmcc> to clarify, if you want to deploy maas, conjure-up doesn't help you there
[19:45] <mmcc> and if you want to deploy openstack on lxd containers on a single machine, you can do that by running conjure-up on that machine, and MAAS isn't involved
[19:45] <john75077> hmmm - ok i have an option to deploy openstack base for maas
[19:46] <mmcc> yes, that is the other option - you can deploy openstack onto full machines in a pre-existing MAAS using conjure-up
[19:46] <mmcc> but if you don't have a MAAS yet, conjure-up is not the place to start
[19:47] <john75077> ive been having too many issues with maas, it doesnt detect hard drives
[19:47] <john75077> and it seems that at some point in time WOL was removed
[19:48] <mmcc> well, that's not my personal area of expertise but this is certainly the right channel to ask about that.
[19:49] <john75077> whats your expertise? i like how maas and juju are supposed to work together but im doing a POC to show how to scale out servers
[19:49] <john75077> it doesnt matter if i use maas or openstack with novalxd
[19:52] <john75077> so ill move over to solutions
[19:53] <mmcc> john75077: sorry, I misremembered the right channel - it's #ubuntu-server.
[20:23] <junaidali> How can we update a subnet's fabric using cli? I tried the command $ maas <maas-profile> subnet update <sub-id> fabric=<fabric-id>
[20:24] <junaidali> but it's not updating the subnet's fabric
[21:04] <roaksoax> junaidali: update the VLAN
[21:07] <roaksoax> junaidali: maas admin subnet update <IP_ADDRESS>/24 vlan=5001
[21:07] <roaksoax> for example
[21:20] <JCharl> So, looking for some info on using MAAS 2.1.1 that came with Ubuntu 16.10.1.  Anyone able to give some help with basics?  The documentation I can find only seems to go up to 2.0.
[22:19] <mup> Bug #1645872 opened: Commissioning fails on NUCS previously loaded with coreos <MAAS:Incomplete> <https://launchpad.net/bugs/1645872>
[23:49] <mup> Bug #1611999 opened: [2.0] MAAS cannot power query with Cisco UCSM power driver <blocks-hwcert-server> <MAAS:In Progress by newell-jensen> <MAAS 2.1:New for newell-jensen> <MAAS trunk:In Progress by newell-jensen> <https://launchpad.net/bugs/1611999>


[15:13] <powersj> Reading the docs there is a "preserve_source_list" option to prevent sources.list from being modified. However, it looks like it does not have any effect.
[15:13] <powersj> Then I looked at a modified sources.list and at the top there is a comment about "apt_preserve_source_list", which is different thant he docs
[15:13] <powersj> 1) which "verb" should I use? 2) can I use it to prevent any changes? or only some?
[15:43] <jgrimm> powersj, i'm far from knowledgeable.. but the docs do say  "only  extra  source specifications will be written into /etc/apt/sources.list.d/* " even when preserve_source_list is true.    WRT you're question #2 (looks like only 'some' is the answer)
[15:45] <rharper> powersj: jgrimm:  recall that the base /etc/apt/sources.list is generated from a template
[15:45] <rharper> there's a default template built-in to cloud-init; or you have to provide your own template
[15:46] <rharper> combined with jgrimm comment, the preserve would only be for .d/ entries IIUC
[15:46] <rharper> cpaelzer might know more;  powersj also looking at curtin's vmtest for apt may be informative
[15:46] <jgrimm> rharper, good idea wrt curtin tests
[15:48] <jgrimm> powersj, i'm curious to know more by what you mean " there is a comment about "apt_preserve_source_list", which is different thant he docs"  .. sounds peculiar
[15:48] <powersj> rharper: jgrimm thanks, from the note in the docs made me think it would preserve sources.list not the .d/*
[15:49] <jgrimm> ah
[15:49] <jgrimm> if you think some clarification could improve things, please do submit fixup. :)
[15:49] <powersj> jgrimm: here is from a cloud-init generated source.list: https://paste.ubuntu.com/23324063/
[15:50] <powersj> so that mentions apt_preserve... but I don't see that mentioned anywhere else in the docs
[15:51] <magicalChicken> i think cloud-init should follow 'preserve_sources_list'. in cc_apt_configure.py at line 300 it checks if that's there before generating
[15:51] <rharper> powersj: that's if you snapshot and boot it in a different instance
[15:51] <rharper> then cloud-init won't re-create the templated file
[15:51] <rharper> powersj: are you seeing that sources.list is re-written when you switch instances ?
[15:52] <powersj> rharper: haven't tried that, just trying to understand all the options and which to actually use.
[15:53] <rharper> gotcha
[15:53] <magicalChicken> powersj: the apt_preserve_sources_list is rewritten to preserve_sources_list in cc_apt_configure.convert_v2_to_3_apt_format
[15:55] <powersj> magicalChicken: ah! so it is a legacy name so to speak
[15:55] <jgrimm> ah, apt_* version is old, so indeed maybe useful to fix up
[15:55] <jgrimm> yeah
[15:55] <powersj> "Convert old to new keys..."
[15:55] <magicalChicken> powersj: yeah, the new format is everything under a general apt: key
[15:56] <jgrimm> so looks like a minor cleanup bug for the emitted text
[16:22] <harlowja> smoser did u ever get my cla email ?
[16:24] <smoser> where did you send ? more contexst ?
[16:24] <harlowja> godaddy never got a copy of theres
[16:25] <harlowja> let me figure out where i sent it
[16:25] <harlowja> somewhere
[16:25] <harlowja> lol
[16:25] <harlowja> (canonical ccla for godaddy)
[16:26] <harlowja> Scott Moser<EMAIL_ADDRESS>[16:26] <harlowja> that one
[16:26] <harlowja> sent again :-P
[16:27] <smoser> k
[16:47] <harlowja> smoser so mdorman may have some resources for VMs :)
[16:47] <harlowja> if we can just figure out what we want :)
[16:47] <harlowja> we/canonical/us ...
[16:49] <mdorman> hello o/
[16:51] <harlowja> o/
[16:54] <harlowja> smoser is https://public.etherpad-mozilla.org/p/cloud-init-centos-unittest still the idea for rhel?
[16:55] <mdorman> so i am not totally up to speed with the whole discussion here, but we should be able to provide you N VMs to help with this.  but if you need an openstack api endpoint to hit as a way to dynamically spin up/down vms, that’s a little more complex and i’m not sure we can accommodate that (we don’t have an OS api exposed publically today)
[16:55] <harlowja> smoser is the one up to speed :-P
[16:56] <harlowja> haha
[16:57] <smoser> see the 'mostly now'
[16:57] <smoser> https://gist.github.com/smoser/19e65095b342e98fd4d6466e4d4fa1ac
[16:57] <smoser> that works last i checked
[16:58] <harlowja> so with that kind of stuff just VMs with LXC would be fine
[16:58] <harlowja> no need for API acccess
[16:58] <harlowja> just some VMs with ability to login (for certain keys)
[16:58] <harlowja> (perhaps?)
[16:58] <smoser> actually.. so using lxc i can npretty easily run unit tests as seen there.
[16:59] <smoser> and we can do that on existing canonical hardware.
[16:59] <harlowja> k
[16:59] <smoser> can/should
[16:59] <harlowja> canonical orange boxes?
[16:59] <mdorman> :)
[16:59] <harlowja> or whatever they were called :-P
[16:59] <smoser> so at the moment i guess i dont need anything
[16:59] <smoser> right, all our boxen are orange.
[16:59] <harlowja> just like the next president!
[16:59] <harlowja> lol
[16:59] <mdorman> ehe
[17:00] <mdorman> alright, cool.  well if that’s something we can assist with, feel free to reach out to me and/or via josh.  it’s pretty easy for us to stand up
[17:00] <smoser> ok.
[17:01] <harlowja> wfm


[02:10] <arraybolt3> juliank, mkukri: Looking at grub2/debian/grub-common.service. Is there any reason in particular this file embeds shell code and uses ExecStartPre, ExecStart, and ExecStartPost? Or is it acceptable to put all that into a script of some sort and have it called by ExecStart?
[02:11] <arraybolt3> Asking because I feel cramming the code to detect when grubenv is on the ESP into those lines is... decidedly non-ideal. I mean it's doable, but it will look like a disaster.
[04:13] <arraybolt3> At any rate, I have most of the code written (with some review help from mmikowski, thank you!) to enable putting grubenv on the ESP when running on an EFI system where grubenv wouldn't usually be writable. The last thing to fix is the grub-common.service. Anyway, going to go afk for probably the rest of the night, will catch up in the morning and see what needs done.
[07:53] <tjaalton> anyone else running noble and a thinkpad, and like to scroll with the middle-button pressed and using the nipple up/down, left/right? I'm seeing an infuriating issue where it send an extra middle-click when you stop scrolling, which means pasting whatever is on the buffer or opening new tabs in tbird or closing tabs on ffox..
[08:00] <mkukri> arraybolt3: did you take into consideration the case where multiple ESPs exist?
[08:01] <mkukri> for example when they are synced across two disks of a raid.  i believe that could cause problems because you dont know which one you booted from and which one contains the up to date grubenv
[08:32] <tjaalton> my scrolling issue seems to only happen with a thinkpad usb keyboard, not a real system, and it can be "fixed" for a while by unplugging the keyboard. but it comes back after some time.. and this started after upgrading to noble. dunno who to blame, kernel/libinput/gnome
[08:32] <tjaalton> "real system = thinkpad laptop"
[10:23] <tjaalton> or maybe it's just going bad, so sad.. an older model is working fine
[12:01] <bdrung> @pitot in
[12:01] <bdrung> @pilot in
[14:58] <xypron> \o
[15:00] <ginggs> xypron: ECHAN?
[15:05] <ogra_> ginggs, yoga fits every chan 😛
[15:35] <arraybolt3> mkukri: I did not take that into account, thanks for mentioning that! I figured this was going to be edge-case prone and was actually thinking of other edgecases (complex multiboot, what if the user wants to write grub.cfg manually, potential for grubenv file format to change, what if GRUB is in EFI/BOOT rather than EFI/ubuntu, etc.). Hopefully by the time I have a debdiff out it'll be close
[15:35] <arraybolt3> to usable.
[15:35] <mkukri> arraybolt3 please file this as a git MP instead of debdiff
[15:35] <mkukri> https://git.launchpad.net/~ubuntu-uefi-team/grub/+git/ubuntu
[15:36] <juliank> One note
[15:36] <juliank> We have a primary ESP, mounted to /boot/efi. We can record the uuid of that
[15:36] <juliank> then in the grub.cfg you can search --fs-uuid=<uuid of esp>
[15:36] <juliank> to then find the grubenv in that
[15:37] <juliank> If your primary ESP fails, you lose the environment but merh
[15:37] <arraybolt3> yep, that's what I'm doing
[15:37] <arraybolt3> juliank: oh, awesome
[15:37] <arraybolt3> mkukri: thanks for the git link, I wondered if one of those existed
[15:37] <arraybolt3> also, about grub-common.service - any reason to not yank that logic into its own script and just call that?
[15:37] <mkukri> there is also a repo under ~ubuntu-core-dev which is technically the official one, but for reviews that one is fine
[15:37] <arraybolt3> that will let me add the detection logic for when grubenv is on the ESP
[15:38] <arraybolt3> (There's already a script under /etc/init.d/grub-common that looks to do the same job, but that's apparently not being called by systemd since when I modified it, nothing happened in my test environment)
[15:38] <mkukri> i guess you can put a script in /usr/lib/grub/grub-your-script and call that
[15:38] <arraybolt3> kk
[15:39] <juliank> I think we removed /etc/init.d/grub-common
[15:40] <juliank> I thought we had removed it, anyway
[15:41] <mkukri> it exists on my noble vm, not 100% what package puts it there...
[15:41] <mkukri> i guess grub-common, but i think only the sd service works
[16:04] <sudip> can anyone please mark LP: #1970521 as affecting Jammy
[16:04] -ubottu:#ubuntu-devel- Launchpad bug 1970521 in boinc (Ubuntu) "boinc-client crashes when started with core dump on Xubuntu 22.04" [Undecided, Confirmed] https://launchpad.net/bugs/1970521
[16:05]  * sudip requested in #ubuntu-bugs yesterday but..  :(
[16:06] <arraybolt3> mkukri, juliank: running this idea by you - in the event of a multiboot scenario with multiple Ubuntu versions sharing the same ESP, every time one of the installed Ubuntu versions "takes over" the ESP, it will change the GRUB version there but *not* the grubenv file. That could potentially result in grubenv being too old or too new for the installed GRUB. The easiest way I can think of to
[16:06] <arraybolt3> get around this is to simply nuke and recreate grubenv on every update-grub event (which I assume will happen on every GRUB installation event, though I guess it might not, so perhaps the nuke-and-recreate has to be done in GRUB's postinstall too?).
[16:06] <arraybolt3> sudip: happens on Noble and Jammy?
[16:06] <sudip> nope, just Jammy please
[16:07] <arraybolt3> sudip: .
[16:07] <sudip> thanks arraybolt3
[16:07] <arraybolt3> glad to help :)
[16:10] <bdrung> @pilot out
[16:59] <kanashiro> @pilot in
[17:21] <arraybolt3> mkukri: well I think my patch is finished, *but* I can't get GRUB to build because of a Python unit test failure in test_grub_sort_version.py where grub-sort-version errors out with "ModuleNotFoundError: No module named 'apt_pkg'".
[17:21] <arraybolt3> smells like something transition-related to me, not exactly sure.
[17:24] <mkukri> arraybolt3 ah crap it's not, that repo has unpublished changes, and that's a bug not caught on my box, please add python3-apt to the build-depends in d/control and it should built (it's already in regular depends but in needs to be in both with those tests)
[17:25] <arraybolt3> aha, that makes sense (I didn't spot it because it was in Depends).
[17:27]  * mkukri has some hacky "speed up grub build" chroots that has the depends and build-depends preinstalled
[17:28] <arraybolt3> oooh nice, I'm over here just using plain-ol sbuild
[17:28] <arraybolt3> though I do make use of shm overlays
[17:28] <mkukri> it's a regular sbuild chroot that i just schroot into and preinstall stuff for re-running sbuild
[17:29] <arraybolt3> oooh nice
[18:06] <ahasenack> sudip: I'm really enjoying your SRU verifications
[18:06] <ahasenack> in a sea of ambiguous verifications that we see many times, yours are very precise
[18:42] <arraybolt3> It looks like my patch is working!
[19:21] <sudip> ahasenack: :)
[19:22]  * sudip still has some pending, which is in my weekend's todo list
[19:23] <sudip> and sagemath is still pending.. :(
[19:23]  * sudip wonders if waveform will want to enjoy another round of sagemath
[19:33] <arraybolt3> mkukri, juliank: https://code.launchpad.net/~arraybolt3/grub/+git/grub/+merge/462445
[20:10] <adrien> does anyone know how to edit a PPA's dependencies to include -proposed? I can see --ppa-dependencies but that seem to be only for dependencies to other PPAs
[20:10] <adrien> bryceh: ^
[20:13] <arraybolt3> adrien: https://ibb.co/S6k2NvD
[20:13] <adrien> arraybolt3: I'd like to do that from ppa-dev-tools instead
[20:14] <arraybolt3> ah, sorry
[20:14] <adrien> looking at the code, it doesn't seem possible but I'm not familiar with the code
[20:19] <kanashiro> @pilot out