[00:04] <asac> mconnor: ok managed to test the patch and attached to bug
[00:04] <asac> https://bugzilla.mozilla.org/show_bug.cgi?id=515232
[00:05] <asac> hmm. guess the autostring should be moved directly above where its used for first time ;)
[00:09] <andv> asac, if tomorrow gnomefreak will ask about ubuntu-it-menu tell him I gonna do it tomorrow afternoon / evening
[00:10] <asac> andv: you think he will jump on it?
[00:10] <andv> asac, lol
[00:10] <andv> asac, maybe he asks you to sponsor it
[00:10] <asac> k
[00:10] <andv> I first need to fix the extra license file
[00:10] <andv> then it's ready
[00:11] <andv> but now I'm a bit tired, so commenting two more bugs than I'm off
[00:11] <asac> thx
[00:11] <asac> sleep well
[00:11] <andv> ty :)
[00:23] <andv> asac, ok, done, I'm off for night
[00:24] <andv> asac, see ya tomorrow, good night
[01:26] <asac> micahg: quick question before i leave. did things go well with the patch merging? ;)
[01:26] <asac> micahg: also not happy i couldnt follow here - was kind of dragged through something ;)
[01:28] <fta> asac, i thought you did a session about that during the summer..
[01:28] <asac> that session was kind of half awake ;)
[01:28] <asac> i cant remember it anymore
[01:28] <asac> was like 0400 UTC ;)
[01:29] <asac> i think i actually explained the way we do things
[01:29] <fta> wow
[01:29] <asac> yes
[01:29] <asac> thats what i am thinking now
[01:29] <asac> i was like 2 minutes awake when the session started ;)
[02:16] <fta> just tested peacekeeper, ff trunk scored 1340, chromium 2086
[02:18] <asac> fta: does chromium work on arm?
[02:19] <fta> not sure it's ready, i saw some patches recently
[02:19] <asac> ok
[02:24] <fta> http://www.sofaraway.org/ubuntu/tmp/peacekeeper-090709.png
[02:29] <fta> asac, well, no, it will sure fail for sure on the other arches, that's why i kept it like that
[02:29] <fta> -sure
[02:31] <asac> fta: yes.
[02:31] <asac> but its wrong ;)
[02:31] <asac> you dont put specific archs in it unless the app is inheritently arch-specific
[02:34] <asac> the idea is: you upload, build fails. porters start working on it ;)
[02:34] <asac> in debian its only an important bug and nor a RC bug if a package fails to build somewhere where it never built before
[02:34] <asac> so a bit the "always try ... maybe it starts to work" approach ;)
[02:34] <asac> ok off
[02:35] <asac> ttyt
[08:53] <eagles0513875> mornign guys
[08:53] <eagles0513875> andv: got your response on the bug of ubuntu-it-menu and its not a problem at all
[11:11] <asac> jdstrand: so is going to be today ;) ... let me know when awake
[11:11] <asac> so, release is going ...
[11:11] <asac> ;)
[11:43] <gnomefreak> is there a sound channel?
[11:57] <asac> gnomefreak: ubuntu-sound ;)
[11:57] <asac> no clue
[12:01] <fta2> asac, the chromium really wants us to stick with in-source sqlite
[12:01] <fta2> the preload patch is a perf killer
[12:01] <asac> yes
[12:02] <fta2> but upstream seems to have rejected the patch
[12:04] <gnomefreak> asac: no i tried that. im think #ubuntu-pulseaudio but not sure. i will check in a few minutes
[12:07] <fta2> asac, as expected, ff3.7 refuses to start once again
[12:08] <fta2> asac, any idea where i can set a breakpoint?
[12:10] <asac> well. if it exists cleanly, so it seems it thinks all is fine ;)
[12:11] <asac> hard to tell where in the startup sequence it goes crazy
[12:17] <asac> needs lots of debug prints i would think
[12:17] <fta2> gasp
[12:17] <asac> fta2: what firefox does is: it queries the X tree to find firefox windows
[12:17] <asac> then selects the one with the right version+profile
[12:17] <asac> and sends a command
[12:18] <fta2> no ff at all
[12:18] <asac> yes. but thats what it does
[12:18] <asac> now you get all those bandaid errors
[12:18] <asac> which on its own is a bad thing, because that means that the query of x tree failed
[12:19] <asac> but the code is supposed to assume that no window is running if thats the case
[12:19] <asac> might be a bug in that
[12:19] <asac> but doesnt explain why it works once
[12:19] <asac> fta2: have you tried to remove plugins etc.?
[12:19] <asac> there were issues with flash at some point that caused similar issues
[12:20] <fta2> with NSPR_LOG_MODULES all:5 http://paste.ubuntu.com/267869/
[12:20] <gnomefreak> new kernel doesnt promt for restart. is this grub or something else im missing?
[12:22] <asac> 207996688[7f670b362150]: nsNativeModuleLoader::Init()
[12:22] <asac> i assume thats in the forked process?
[12:23] <asac> 207996688[7f670b362150]: DOCSHELL 7f670b2bc000 created
[12:23] <asac> 207996688[7f670b362150]: nsWindow::Destroy [7f670b3df8f0]
[12:23] <asac> no clue why something like that would happen
[12:23] <asac> fta2: what was the strace -f -eopen firefox again?
[12:26] <fta2> asac, http://paste.ubuntu.com/267871/
[12:30] <asac> fta2: nightly.xpt?
[12:30] <asac> nightly tester tools?
[12:30] <fta2> yes
[12:30] <asac> -safe-mode?
[12:31] <asac> and/or fresh profile?
[12:31] <fta2> both are ok
[12:32] <fta2> hm, and now it starts
[12:32] <fta2> like with a --reinstall
[12:44] <gnomefreak> i erally wish mozilla would have kept the release schedule icals
[12:44] <gnomefreak> really*
[12:44]  * gnomefreak reboots
[13:07] <asac> fta2: yeah. track down the extension causing this. maybe refractor?
[13:07] <asac> fta2: does fresh profile start two times in a row?
[13:34] <gnomefreak> asac: are we removing ${misc:Depends} from control
[13:34] <gnomefreak> from non-transitional entry
[13:38] <asac> no. thats ok to have
[13:39] <jdstrand> asac: hi, I'm here. firefox testing today?
[13:42] <asac> jdstrand: yep ;)
[13:43] <gnomefreak> asac: ok cool
[13:43] <jdstrand> asac: I'm on it. can you ping me when you are satisfied with your testing and it's ok for me to publish?
[13:44] <asac> yesa
[13:44] <asac> jdstrand: release is as usually late though
[13:45] <jdstrand> asac: btw, that is ff3 3.0.14 and xl19 <IP_ADDRESS> (hardy-karmic), ff35 3.5.3 and xl191 <IP_ADDRESS> (karmic only)?
[13:52] <asac> fta2: is chromium using GL as skia backend?
[13:55] <fta2> asac, http://code.google.com/p/chromium/wiki/LinuxGraphicsPipeline
[13:58] <gnomefreak> bug 425715
[14:06] <gnomefreak> andv: are you around yet. just finished with mozgest debdiff is on bug above and no lintian warnings/errors
[14:08] <gnomefreak> ok branch is pushed as well
[14:13] <asac> gnomefreak: he said to tell you that he will do mozgest today
[14:13] <gnomefreak> asac: already done :(
[14:31] <eagles0513875> hey guys
[14:32] <gnomefreak> hi eagles0513875
[14:33] <eagles0513875> if i can help out wiht packaging ill help you guys out
[14:33] <eagles0513875> put my quad to good use lol
[14:34] <gnomefreak> and bug 425695 is done and branch pushed to extension team
[14:34] <gnomefreak> my quota is met for the day now email before it gets too late in morning
[14:40] <gnomefreak> Subject:  You can say ?good-bye? to your old ugly watch.  << my damn watches are fine
[14:56] <eagles0513875> ahhah viva la sapm
[14:56] <eagles0513875> :spam
[14:56] <eagles0513875> :) i got news for u guys :)
[14:56] <bdrung_> gnomefreak: lp: #... is missing in http://bazaar.launchpad.net/~mozilla-extensions-dev/firefox-extensions/adblock-plus.ubuntu/revision/49
[14:57] <gnomefreak> bdrung_: yeah i keep forgetting to add that in there. on all extensions so far. i will fix it mostlikely tomorrow or if i have time after email ill do it real fast
[14:58] <gnomefreak> asac: ok bug 107247 since all gecko browsers see it wouldnt it be against xulrunner instead of firefox?
[15:09] <asac> gnomefreak: is sunbird 0.9 ready?
[15:09] <asac> i think i failed completely on that?
[15:11] <mac_v> asac: any reason why the nm-applet does not animate for wired connections? it constantly uses only the network-idle icon , while the netwrk-send, *-transmit , *-send-receive are not used?
[15:12] <asac> mac_v: not sure what you mean
[15:12] <asac> you want traffic indication in the applet?
[15:14] <mac_v> yeah
[15:16] <asac> that does not work for any type of connection
[15:16] <asac> also blinking in the tray is not what we will do
[15:16] <asac> a statistic  info somewhere we are planning
[15:16] <asac> especially for 3g etc. so users can see the costs
[15:17] <mac_v> asac: /status/24/network-idle.svg /status/24/network-receive.svg /status/24/network-transmit.svg /status/24/network-transmit-receive.svg
[15:17] <mac_v> these icons exist , ^
[15:17] <mac_v> which is the icon that is going to be used?
[15:22] <asac> mac_v: no icons
[15:22] <mac_v> asac: they are in the /usr/share/icons/THEMENAME
[15:22] <asac> the tray will not be animated
[15:22] <mac_v> thats not a problem
[15:23] <asac> thats why we dont need new icons ;)
[15:23] <mac_v> asac: i wanted to know which icon will be used :)
[15:23] <asac> not sure i understand the question
[15:23] <asac> fo what?
[15:23] <mac_v> for the notification area
[15:23] <asac> as i said: "the tray will  not be animated". so none of those
[15:23] <asac> yes. not sure how to answer that different from what i said
[15:24] <mac_v> asac: hehe , ok , so which icon is going to be assigned , could you pls have a look  :) we are making icons for humanity
[15:25] <asac> can you please read what i wrote
[15:25] <asac> the (icon in the) tray will not be animated == will not show activity indication
[15:26] <mac_v> asac: thats fine , but it will use an icon , right? a non animated one?
[15:26] <asac> network manager already uses an icon
[15:27] <asac> http://paste.ubuntu.com/267971/
[15:27] <asac> it uses the one of the devbice type of the primary route
[15:28] <mac_v> asac: ah those , ,thanks :)
[15:28] <mac_v> we were confused over the icons
[15:30] <mac_v> asac: because the icons we had assigned were those listed above , the status icons and nm was using only the idle one , so testers reported it :) , just wanted to know which icon to assign... thanks for clearing that up :)
[15:31] <asac> it might feel like its the old idle icon
[15:32] <asac> but NM uses complete different set
[15:32] <asac> than the old network indicator
[15:32] <mac_v> oh... ok
[15:39] <gnomefreak> asac: yes sunbird .9 is ready its version ubuntu3 as i recall
[15:49] <gnomefreak> bdrung_: fixed the changelog in adblock-plus and mozgest.
[15:49] <bdrung_> good
[15:50] <gnomefreak> i forgot those are not being pushed to Debian (or at least doesnt have to be) might be a good idea unless they already have them
[15:51] <gnomefreak> asac: seamonkey 1.1.18 is going to have to wait until after honeymoon ( 1 week to 2 weeks) not sure how much longer than a week we are staying
[15:52] <gnomefreak> unless someone gets energetic and wants to go for it ( im thinking a bit hard for eagles0513875) but since mike pushed 1.1.18 we should beable to take patches/fixes from there and add it to ours and build
[15:53] <gnomefreak> updates -> meetings -> bed -> start next day
[16:18] <gnomefreak> ok i will try to be here tomorrow for a little bit, i have to pack rest of stuff tomorrow and hit airport Friday morning.
[16:26] <fta2> asac, d'oh! chromium-browser (<IP_ADDRESS>~svn20090908r25615 -> <IP_ADDRESS>~svn20090909r25716) [88.76MB (+18850kB, +21.23%)]
[16:27] <asac> sigh
[16:27] <fta2> icu42
[16:27] <asac> maybe we should prepare the first upload based on yesterdays package
[16:27] <fta2> there are 2 icu now
[16:36] <fta2> transition
[16:37] <fta2> fta@cube:/data/bot/upstream/chromium-browser.svn/src/third_party $ du -sm icu*
[16:37] <fta2> 298     icu
[16:37] <fta2> 268     icu38
[16:48] <asac> fta2: is that a transitional situation?
[16:48] <fta2> yes
[16:49] <asac> any known timeline?
[17:04] <fta2> i will ask
[17:16] <micahg> asac: ff3.5 is the hugday target...
[17:16] <asac> today?
[17:16] <micahg> tomorrow
[17:16] <asac> ah ... yeah. pedro mentioned it ;)
[17:18] <micahg> well, I'm subscribed to the package, so I'll try to keep an eye on it
[17:18] <micahg> ttyl
[17:34] <asac> thx
[17:44] <mac_v> asac:  " wpa_supplicant[3125]: CTRL-EVENT-SCAN-RESULTS " was this what you were talking about the other day? to reduce the auto-refresh of the nm-applet?
[17:44] <asac> you mean background scanning?
[17:44] <mac_v> yup
[17:44] <asac> you see that because of background scanning ... yes.
[17:45] <mac_v> that is occurring every 2 mins! seems an over kill :/
[17:45] <asac> no
[17:45] <asac> ;)
[17:45] <asac> for the sake of connectivity yes.
[17:45] <asac> but for the sake of other things ... no.
[17:45] <mac_v> ;p , well it floods the log  ;)
[17:47] <mac_v>  does it have to log *every* scan? wouldnt it be better when a scan has an error :)
[17:48] <asac> the log can be improved. at least there should be timestamps... feel free to submit it ;)
[17:49] <asac> personally i dont have many problems with that log
[17:49] <asac> but if folks dont like it we can address is on contribution base
[17:49] <andv> asac, hello alex
[17:49] <andv> asac, what happened to the extension wiki page? It lists just few of them now
[17:49] <mac_v> asac: well i have other errors , hence this seems to add to the haystack :(
[17:55] <asac> andv: look at the changes log
[17:56] <asac> https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview
[17:56] <asac> andv: ^^ please figure what gnomefreak did ;)
[17:56] <asac> i am out for dinner now for 1-2h
[17:56] <asac> revision 11 looks ok
[17:56] <asac> most likely some mess happened then ;)
[17:57] <asac> https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview?action=info
[17:57] <asac> ok out
[17:57] <asac> thats what imeant
[17:57] <andv> oki
[18:54] <micahg> asac: can the fix for bug 404827 make it into xul<IP_ADDRESS> on jaunty?
[18:56] <andv> asac, I've cleaned the page a bit, fixed links et all
[18:56] <andv> asac, let me know if it's fine now
[19:16] <asac> micahg: todays security update is supposed to fix that. please verify in -security ppa
[19:18] <asac> hmm
[19:18] <asac> seems was forgotten
[19:18] <asac> too bad
[19:18] <micahg> yeah, I checked the security ppa first :)
[19:19] <micahg> it's not worth another rebuild?
[19:20] <fta> asac, are the FAILED emails clear enough (see o3d today)
[19:20]  * asac checks
[19:21] <andv> asac, wiki page updated, let me know when checked
[19:21] <asac> jdstrand: can you check the xul 1.9.1 for jaunty in security ppa and tell me if that is actually ok with you?
[19:22] <fta> http://launchpadlibrarian.net/31543792/buildlog_ubuntu-karmic-i386.xulrunner-1.9.2_1.9.2~a2~hg20090909r31589%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[19:22] <asac> jdstrand: and if that is ok, also tell me if its ok to add --enable-safe-browsing for this update still (bug 404827)
[19:22] <fta> http://launchpadlibrarian.net/31546555/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20090909r32341%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[19:22] <asac> we have that in karmic now for a while and should be safe
[19:22] <asac> its universe
[19:22] <asac> but its clearly not directly related to this security update
[19:22] <asac> (mor so for the geolocation thing thats in the current ppa version)
[19:23] <asac> fta: maybe thats alrewady fixed upstream?
[19:23] <asac> looks like they should get a red on tinderbox for that ;)
[19:24] <asac> i mean the test failure
[19:24] <asac> sigh ... gnomeshell .. sigh
[19:24] <asac> need to get upstreamred
[19:24] <asac> somehow :(
[19:24] <asac> micahg: ^^
[19:24] <asac> ;)
[19:24] <asac> you wanted to work on that, right ;)?
[19:24] <asac> patching file browser/components/shell/src/nsGNOMEShellService.h
[19:24] <asac> Patch lp185622_system_path_default_browser.patch does not apply (enforce with -f)
[19:26] <micahg> I was
[19:26] <micahg> I can try again tonight
[19:26] <asac> micahg: did you end up in problems yesterday while trying to adjust that patch?
[19:26] <asac> or is this a new build failure?
[19:27] <micahg> I couldn't get quilt to give me a .rej file
[19:27] <asac> hmm
[19:27] <asac> ok
[19:27] <asac> cd build-tree/mozilla ... ln -s ../../debian/patches; quilt push -a
[19:27] <asac> quilt push -f
[19:27] <asac> remove your quiltrc ;)
[19:28] <micahg> mayeb that was it
[19:28] <micahg> I'll try again tonight unless you are going to take care of it now
[19:28] <asac> just tell me when you dont get it done ;)
[19:29] <micahg> ok
[19:29] <asac> so we have it fixed tomorrow at least .... otherwise fta will harangue us about his build-failed ratio ;)
[19:29] <fta> yeah!
[19:30] <fta> Total builds:  	11676
[19:30] <fta> Failed 	1538
[19:30] <fta> Pending 	8
[19:30] <fta> Superseded 	484
[19:30] <fta> Succeeded 	9646
[19:30] <asac> andv: i think it looks good now. thx
[19:30] <micahg> ah
[19:30] <asac> now continue with all the other extensions ;)
[19:30] <micahg> now I get the rejects :0
[19:30] <micahg> :)
[19:30] <andv> asac, np, everything was messed up
[19:30] <andv> asac, like links done with bug ID set as xxxxx
[19:30] <asac> yeah. but at least the general content was ok
[19:30] <asac> i am not botherred about the right links. having them right is of course nice ;)
[19:31] <andv> asac, yeah, finishing the check on ubuntu-it-menu
[19:31] <andv> asac, do you know if gnomefreak finished working on any other extension?
[19:31] <andv> today?
[19:31] <micahg> asac: I don't get the reject files though
[19:32] <asac> micahg: does it complain?
[19:32] <asac> i think you had something about "unified reject" in your quiltrc. not sure what that means in practice as i dont have any quiltrc ;)
[19:33] <asac> micahg: maybe your reject is just inside those files?
[19:33] <asac> like conflict markers inside?
[19:33] <fta> asac, i didn't change the way tests are done in xul*, they should not be fatal
[19:33] <asac> or there was not a problem ;)
[19:33] <asac> fta: well.  the test build failure is an upstream build failure
[19:33] <asac> make does not find the target
[19:34] <asac> thats why i think its either already fixed or they have red flag atm ;)
[19:34] <micahg> asac: http://pastebin.com/f5c0157ac
[19:35] <asac> micahg: thats quilt push, right?=
[19:35] <micahg> push -f
[19:35] <fta> reed is never here when we need him :P
[19:35] <asac> so first: can be reverse-applied means that either exactly that patch landed upstream
[19:35] <asac> or you have a busted build tree
[19:35] <asac> where you alreawdy have that patch applied
[19:35] <asac> i would think the latter as the firefox-profilename patch is unlikely to ever get upstreamed
[19:35] <asac> micahg: start from a clean tree again
[19:35] <asac> then use the link for patches
[19:35] <asac> and do what you tried to do
[19:35] <asac> i am sure all will be good
[19:36] <micahg> how do I start from a clean tree again?  ./debian/rules patch?
[19:37] <asac> micahg: if you dont want to start with bzr bd --merge -e you can first clean it completely:
[19:37] <asac> fakeroot ./debian/rules clean
[19:37] <asac> then do what you said
[19:40] <fta> asac, it won't advise to call patch, clean or even pre-build (like in my dpatch script), it's easy to start the build (dpkg-buildpackage, or debuild), and fix from there
[19:42] <asac> fta: patch works well nowadays. whats the problem with that?
[19:43] <fta> embedded tarballs, or tweaked build dirs
[19:43] <fta> or custom unpack rules
[19:43] <fta> a real build would always work
[19:44] <fta> er, well, fail ;)
[19:48] <asac> fta: it works for embedded tarballs ... at least fo rus
[19:49] <asac> for us
[19:49] <asac> i hope we dont use custom unpack rules taht dont properly hook into the appropriate cdbs rules in moz and chrome etc. rules ;)
[19:49] <asac> if others do that, so be it :) ... but for those you cannot even say that you can properly work on packages ;)
[19:49] <asac> some are so busted that you have to trash the build tree and start from .dsc on every modification
[19:50] <asac> some even make the build tree dirty during clean::
[20:09] <fta> asac, remember my dquilt? http://paste.ubuntu.com/268145/
[20:11] <asac> yes
[20:15] <fta> several times, it caused me pain, creating the patches/ dir in the current dir instead of using the one in DEBIAN_PATCHES
[20:15] <fta> i'm no longer using it, i build and make the symlink
[20:16] <Pavlov> asac: can do it here
[20:16] <asac> hi
[20:16] <asac> Pavlov: so to tell you what to do at best i have to know some things:
[20:16] <Pavlov> ok
[20:16] <asac> 1. are you aiming to distribute a one package per language?
[20:17] <asac> also are you shipping xulrunner separated?
[20:17] <Pavlov> we're aiming to make the installation process simple for end users, and would like to avoid having to have seperate repos per language
[20:17] <Pavlov> so yeah, we have a fennec debian package and a xulrunner ones
[20:18] <asac> you want to provide "upstream" debian packages? or in some distro?
[20:19] <Pavlov> probably both.  we've been working with the maemo community to push our packages to their "maemo-extras" repository
[20:19] <Pavlov> it would be great to eventually get source package files so we could more easily spin builds in distros
[20:19] <Pavlov> but right now, we're ok doing the builds.  we've got things to the point where we can do repacks similar to how we do on the desktop, but we end up with a ton of seperate packages
[20:20] <Pavlov> which is ok, except we don't want to present the user with 50 fennecs to choose from
[20:20] <asac> sure.
[20:21] <asac> so the general approach that we use is that we ship the .xpi's in the unified language package we have in the distro
[20:21] <asac> so basically ubuntu has language-pack-de ... with all the translations for software in main
[20:21] <asac> when user switches language in our language selector, we install the appropriate language-pack if its not installed yet and switch the system locale
[20:22] <Pavlov> ah, so most of that work is done by the locale switcher?
[20:22] <asac> not sure if maemo has a similar unified language pack ... if it does, it would make sense to have that in there
[20:22] <asac> Pavlov: yes. but we try to not ship per-language-per-application packages. just one big package for "german" where all the translations are in ...
[20:22] <Pavlov> right
[20:23] <asac> Pavlov: so its different way you would ship in maemo (distro) or as upstream .debs
[20:23] <Pavlov> right
[20:23] <asac> for upstream you could ship one package for each locale and ask the user to install it
[20:23] <asac> that package would basically just have the .xpi
[20:23] <Pavlov> right
[20:23] <Pavlov> hmm
[20:23] <asac> or - if the amount of languages is small - you could make one big package
[20:23] <asac> with all the .xpis
[20:23] <Pavlov> right
[20:23] <asac> i wouldnt do that if its more than 8 languages
[20:24] <asac> startup time ... and addons manager bustage come to my mind
[20:24] <Pavlov> yeah, it almost certainly will be
[20:24] <Pavlov> maybe not 75 or whatever firefox is up to yet
[20:24] <asac> so ... technically using this approach requires you to use "matchOS"
[20:24] <asac> which is something we just discussed yesterday here ;)
[20:25] <asac> matchOS=true works pretty good ... except that it has a few bugs because its not the default way firefox builds are translated
[20:25] <asac> it think almost all distros use that (if not all)
[20:25] <asac> matchOS selects the chrome locale by the system LANG environment
[20:25] <asac> like when you run locale
[20:26] <micahg> asac: maybe that's why I had trouble with the alpha 5 CD dictionary?
[20:26] <asac> micahg: i am not sure why you had that problem ... did anyone report a dupe yet?
[20:26] <micahg> nope
[20:26] <asac> micahg: maybe we can ask someone during tomorrows hug day to test and confirm that?
[20:26] <micahg> ok
[20:27] <Pavlov> asac: i see
[20:27] <Pavlov> so witch matchOS set, and the right xpi installed, things just work?
[20:28] <asac> Pavlov: there are a few tiny details.
[20:28] <asac> Pavlov: 1. if you have a xulrunner split you can either just ship full fennec langpacks or the partial ones next to general xulrunner ones
[20:28] <asac> that comes handy if you want to use translated xulrunner somewhere else
[20:28] <asac> the trick is to use<EMAIL_ADDRESS>as the target application and split the xpi
[20:28] <asac> thats what we do in ubuntu
[20:29] <asac> 2. there are a few bugs sourrounding matchOS ... and its ways to mitigate those
[20:29] <asac> the most important one is: useragent will not be right if you switch locale
[20:29] <asac> to workaround you need to make a localized pref out of general.useragent.locale
[20:29] <asac> but that triggers a few bugs in xulrunner/firefox code base
[20:30] <asac> and can cause extensions that rely on general.useragent.locale being a char pref
[20:30] <asac> to fail
[20:30] <asac> we ship it with that localized prefs and i think the proper useragent locale is more important than the regressions that exists
[20:30] <asac> due to that
[20:31] <asac> if you have questions while doing this, we are here ;)
[20:31] <asac> just shoot and i will reply when i see it :)
[20:31] <asac> Pavlov: ^^
[20:33] <Pavlov> ok
[20:33] <Pavlov> im going to see what we can do
[20:33] <Pavlov> thanks for your help!
[20:33] <asac> welcome
[20:38] <andv> asac, ubuntu-it-menu pushed
[20:39] <fta> asac, the new icu: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google
[20:39] <andv> asac, we should add as 'checklist' to remove all extra license files with the  MOZ_XPI_DOCUMENTED_LICENSE_FILES feature
[20:40] <andv> asac, together with the other changes
[20:42] <andv> asac, do you know if gnomefreak worked on any other package today I should look at?
[20:49] <BUGabundo> olá friends
[20:49] <andv> hello
[20:50] <BUGabundo> hey andv
[20:50] <andv> how you doing?
[20:57] <asac> andv: go ahead
[20:57] <asac> add that column
[20:57] <andv> k
[20:57] <asac> and the checklist item on top
[20:57] <andv> k
[20:58] <andv> asac, do you know if john updated another ext yet?
[20:58] <andv> asac, I saw his ping for me before
[21:01] <BUGabundo> andv: fine, thanks
[21:02] <BUGabundo> asac: did you catch my bug last night?
[21:02] <asac> BUGabundo: sorry. i missed you.
[21:02] <asac> what was it?
[21:02] <asac> modemmanager breakage?
[21:08] <BUGabundo> more or less
[21:08] <BUGabundo> won't see modem if plugged on boot
[21:08] <BUGabundo> no probs if plugged after login
[21:09] <BUGabundo> or if it is resuming from hibernation, asac
[21:09] <BUGabundo> I guess I can file a bug with lshal
[21:12] <asac> BUGabundo: yes.
[21:12] <asac> do the ttys get created for your modem in /dev/ ?
[21:13] <BUGabundo> no idea
[21:13] <BUGabundo> I just see it from an user POV
[21:13] <asac> BUGabundo: please plug in before boot... log in ... restart mm
[21:14] <asac> does it detect the modem then?
[21:14] <BUGabundo> ill check on next boot then asac
[21:16] <asac> thx
[21:19] <andv> asac, I've broke up something in the title table
[21:19] <andv> asac, can find what it is
[21:19] <andv> * can't
[21:20] <andv> asac, https://wiki.ubuntu.com/MozillaTeam/Karmic/ExtensionReview
[21:26] <asac> andv: fixed
[21:27] <asac> whitespace at EOL
[21:27] <asac> cancel your edit
[21:27] <asac> it was locked by you
[21:27] <asac> the column is not matching though
[21:27] <andv> asac, right tables are wrong
[21:27] <asac> please move the new column one to the left
[21:27] <asac> so we have the checklist items next to each other
[21:28] <andv> asac, edit removed
[21:28] <andv> asac, let me move the column
[21:37] <andv> asac, done
[21:37] <andv> asac, sorry for the delay, but I lagged while hitting the preview button and they said me I did too many changes
[21:39] <asac> 22:27 < asac> please move the new column one to the left
[21:39] <asac> 22:27 < asac> so we have the checklist items next to each other
[21:39] <asac> andv: ^^
[21:39] <asac> also add a "verify that works with ffxo 3.5"
[21:39] <asac> thx
[21:39] <asac> andv: ^^
[21:39] <asac> (5 lines)
[21:40] <andv> asac, I should put new column at the end?
[21:40] <andv> after assignee?
[21:46] <andv> asac, 'works with ffox3.5' column added
[21:48] <asac> andv: do you listen?
[21:48] <asac> 2:39 < asac> 22:27 < asac> please move the new column one to the left
[21:48] <asac> 22:39 < asac> 22:27 < asac> so we have the checklist items next to each other
[21:48] <asac> ;)
[21:48] <andv> asac, don't get what you mean
[21:48] <asac> thats now the third time i said that and you always sid: ok ;)
[21:48] <andv> lol
[21:48] <asac> if you dont understand something say so
[21:49] <andv> nope, I said ok for adding the ffox column
[21:49] <asac> still i need to repeat myself ;)
[21:49] <asac> you can also say: no i dont do that ... i dont get what you mean ;) ... thats perfectly fine ;)
[21:49] <andv> you didnt specify which new column
[21:49] <asac> when i said that the first time you had only one column added
[21:50] <andv> and checklist is above
[21:50] <asac> when i said that the second time there was still only one column added
[21:50] <asac> also i explained the concept:
[21:50] <asac> 22:39 < asac> 22:27 < asac> so we have the checklist items next to each other
[21:50] <asac> 22:39 < asac> 22:27 < asac> so we have the checklist items next to each other
[21:50] <asac> the items match the checklist if you look closely ;)
[21:51] <andv> so I should move works with ffox3.5
[21:51] <andv> one left
[21:51] <andv> to look like
[21:51] <andv> bugs filed works with ffox3.5 no extra license files assigne
[21:53] <andv> asac, ^^
[21:54] <andv> asac, moving ffox3.5 to the left should fix it
[21:54] <andv> e.g checklist items should match the items
[21:57] <andv> asac, you look a bit nervous this evening, slept bad? :)
[21:58] <BUGabundo> LOLOL
[22:39] <BUGabundo> asac: uploading logs now
[22:39] <BUGabundo> asac: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/427046
[22:40] <asac> checking
[22:41] <asac> Sep  9 22:19:53 BluBUG modem-manager: Could not acquire the org.freedesktop.ModemManager service as it is already taken. Return: 3
[22:42] <asac> ah last attempt it is
[22:42] <asac> there he is gone
[22:42] <asac> BUGabundo: more coming?
[22:43] <BUGabundo> nope
[22:43] <BUGabundo> all done now
[22:43] <BUGabundo> unless I file a canon bug on pulseaudio
[22:44] <BUGabundo> keeps eating all cpu
[22:44] <asac> BUGabundo: http://launchpadlibrarian.net/31555146/WifiSyslog.txt
[22:44] <asac> explain that log to me
[22:44] <asac> at the bottom there is a successful connect
[22:44] <asac> thats a boot without plugged in?
[22:44] <BUGabundo> I'm not using wifi
[22:44] <asac> well
[22:45] <asac> dont interpret the name ;)
[22:45] <BUGabundo> errr bad trace in ther
[22:45] <BUGabundo> getting a few of those latelly
[22:45] <asac> well
[22:45] <BUGabundo> asac: yeah im online NOW
[22:45] <BUGabundo> after restarting nm
[22:45] <asac> what are the relevant pieces. i asked for a syslog of a boot wiuth plugged in
[22:45] <BUGabundo> and re-connencting the modem 5 times
[22:45] <asac> BUGabundo: so you booted with device plugged in?
[22:46] <asac> and restarted NM because it didnt see the modem?
[22:46] <BUGabundo> for some reason I got stuck on those connected but no net, 4 times
[22:46] <BUGabundo> asac: lets get back :)
[22:46] <BUGabundo> using net, lost connection, would not connecte
[22:46] <BUGabundo> had to reboot
[22:46] <BUGabundo> modem always plugged
[22:47] <BUGabundo> after I rebooted and got to desktop
[22:47] <BUGabundo> NM-applet was not showing it
[22:47] <BUGabundo> nor was lshal
[22:47] <BUGabundo> I restarted NM and it appeard
[22:47] <asac> ok
[22:47] <asac> checking
[22:47] <BUGabundo> I tried to connected, seemed to have success , but no net, 4 times
[22:47] <BUGabundo> the 5 worked
[22:48] <asac> BUGabundo: ok .... so you had a NM crash
[22:49] <asac> did the applet say: "network manager not running ..." ?
[22:49] <asac> wait
[22:50] <asac> did you restart modem-manager?
[22:50] <asac> or just NM?
[22:51] <BUGabundo> never saw any warning from applet
[22:51] <BUGabundo> and I just restart NM, after boot
[22:51] <BUGabundo> I did restart NM and MM before booting
[22:51] <BUGabundo> to try to reconect, but failed to
[22:51] <asac> feels a bit racy
[22:52] <asac> thx
[22:53] <fta> asac, do you know where this "XRemoteClient Error" logs are coming from?
[22:54] <asac> fta: yes. i spit them out in our bandaid so we have a start to debug the happenings when something odd happens
[22:54] <asac> withtout that bandaid each client error would cause the process to instantly get signal 5
[22:55] <asac> BUGabundo: ok i think we can fix that.
[22:55] <BUGabundo> asac: which one?
[22:55] <BUGabundo> the lossing connection or not detected?
[22:55] <asac> modem 3g not seen on boot
[22:56] <asac> thats obviously a race
[22:56] <asac> we will take care of it asap
[22:56] <asac> i pasted the relevant log part
[22:56] <asac> in the bug
[22:57] <asac> Sep  9 22:25:59 BluBUG NetworkManager: <WARN>  stage1_prepare_done(): GSM modem connection failed: Sending command failed: device is connected
[22:57] <asac> BUGabundo: isnt that fixed in todays dailies?
[22:57] <asac> either its fixed or at least fix committed
[22:57] <asac> please file a bug for that
[22:57] <asac> say: reconnect fails because "device is connected" ;)
[22:58] <asac> Sep  9 22:26:13 BluBUG NetworkManager: <info>  Activation (ttyUSB0) Stage 5 of 5 (IP Configure Commit) complete.
[22:58] <asac> Sep  9 22:26:44 BluBUG kernel: [  265.880865] gdl_indexer[5926] general protection ip:7f53c3fcdc29 sp:13eaed0 error:0 in ld-2.10.1.so[7f53c3fbf000+1f000]
[22:58] <asac> Sep  9 22:27:03 BluBUG NetworkManager: <info>  (ttyUSB0): device state change: 8 -> 3 (reason 0)
[22:58] <asac> what has happened there?
[22:59] <BUGabundo> asac: say: reconnect fails because "device is connected" ;) is another bug
[22:59]  * BUGabundo issss ssoooooo confused by now
[22:59] <BUGabundo> asac: be gentle with me
[22:59] <asac> one sec
[22:59] <asac> phone
[22:59] <BUGabundo> I'm toooo tired
[22:59] <BUGabundo> :\\ ok
[23:04] <asac> BUGabundo: the log lines i posted.
[23:04] <asac> please open a new bug for that
[23:05] <asac> 3:57 < asac> Sep  9 22:25:59 BluBUG NetworkManager: <WARN>  stage1_prepare_done(): GSM modem connection failed: Sending command  failed: device is connected
[23:05] <asac> just paste that line
[23:05] <asac> and say: "reconnect fails because device is already connected" ;)
[23:05] <asac> actually dont do that. i wanted to get this verified ;)
[23:05] <asac> but its already fixed in git
[23:05] <BUGabundo> decide your self :D
[23:06] <BUGabundo> asac: network-manager:  Installed: 0.8~a~git.20090820t182117.cb60390-0ubuntu2
[23:09] <asac> i would think you should check the latest dailes ;)
[23:09] <asac> but you dont want to do that anymore?
[23:09] <asac> i will roll a new set of stuff to archive tomorrow i think
[23:17] <BUGabundo> asac: I think I'm running NM trunk PPA
[23:17] <BUGabundo> or not
[23:17] <BUGabundo> :(
[23:17] <BUGabundo> something changed
[23:17] <BUGabundo> let me check my sources
[23:17] <BUGabundo> # deb http://ppa.launchpad.net/network-manager/ppa/ubuntu karmic
[23:17] <BUGabundo> # deb http://ppa.launchpad.net/modemmanager/ppa/ubuntu karmic main
[23:17] <BUGabundo> # deb http://ppa.launchpad.net/network-manager/trunk/ubuntu karmic main
[23:17] <BUGabundo> doh
[23:18] <BUGabundo> enabled
[23:18] <BUGabundo> and upgrading
[23:31] <BUGabundo> asac: The following packages will be upgraded:   gnome-applets-data libnm-glib-dev libnm-glib0 libnm-util-dev libnm-util1 modemmanager network-manager network-manager-dev   network-manager-gnome
[23:31] <asac> BUGabundo: dist-upgrade?
[23:31] <asac> run dist-upgrade
[23:32] <asac> there should be libnm-glib2 et al coming iirc
[23:32] <BUGabundo> asac: aptitude full-upgrade
[23:32] <asac> no clue about aptitude
[23:34] <BUGabundo> stupid PA
[23:34] <BUGabundo> :(
[23:36] <BUGabundo> asac: anything else?
[23:37] <asac> if you have the latest then its good
[23:37] <asac> but you need libnm-glib2 now
[23:37] <asac> otherwise you dont have latest iirc
[23:37] <asac> ii  libnm-glib2                0.8~a~git.20090904t224209. network management framework (GLib shared library)
[23:37] <asac> not the latest
[23:38] <asac> but thats the package you need with todays day
[23:39] <BUGabundo> libnm-glib2:
[23:39] <BUGabundo>   Installed: 0.8~a~git.20090904t224209.bee58e3-0ubuntu1~nmt1
[23:39] <BUGabundo>   Candidate: 0.8~a~git.20090904t224209.bee58e3-0ubuntu1~nmt1
[23:39] <asac> jdstrand: hardy and intrepid are done
[23:40] <jdstrand> asac: ok
[23:41] <asac> hmm. do we want the 24h wait period?
[23:41] <asac> that would mean we release tomorrow ;)
[23:42] <jdstrand> asac: it is up to you. I've been working on the testing. I have some i386 testing to do still
[23:48] <jdstrand> asac: how serious are the vulnerabilities?
[23:48] <jdstrand> asac: we could theoretically wait on karmic and universe stuff (which I haven't tested much)
[23:49] <asac> karmic stuff is in the ppa
[23:49] <asac> heard of nothign really scary
[23:49] <asac> will check now
[23:50] <fta>   - chromium-browser (<IP_ADDRESS>~svn20090909r25716 -> <IP_ADDRESS>~svn20090909r25796) [72.60MB (-16165kB, -22.26%)]
[23:50] <asac> thx
[23:53] <asac> jdstrand: bounced you advisories
[23:54] <asac> also bounced a "sed" ;)
[23:57] <asac> jdstrand: so i think its ok to do tomorrow
[23:58] <asac> also bounds CVE ids
[23:59] <asac> ok lets do that tomorrow. i will finish up with QA for jaunty then too. better than getting no sleep and you hitting reload until its released ;)


[01:26] <thetrav> https://maas.ubuntu.com/docs1.9/configure.html#ssl-support <- the docs tell me to set the maas url to a non standard https port on localhost... is that legit?
[01:51] <sharef> hello guys,  I wonder if you guys might be able to point me toward a fix or reason why I can't use "maas my_login nodes accept-all" when working from the instructions from maas.ubuntu.com
[01:52] <sharef> brand new install, ubuntu 16.04, trying to learn maas from the top
[03:13] <thetrav> so I followed the docs for getting maas to use ssl
[03:13] <thetrav> however now my node can't access the cloud init metadata
[03:23] <thetrav> so is the entire maas team UK based?  or some other similar time zone?  I never seem to find anyone online here
[05:55] <mup> Bug #1536604 changed: IntegrityError while uploading leases - when there are reserved IP's on the dynamic range <landscape> <MAAS:Fix Released by lamont> <https://launchpad.net/bugs/1536604>
[05:55] <mup> Bug #1576194 changed: Enlistment via DHCP fails because DNS has bogus PTR record <landscape> <MAAS:Fix Released> <https://launchpad.net/bugs/1576194>
[05:55] <mup> Bug #1580712 changed: 1.9: dhcp update error: str object has no attribute mac <MAAS:Fix Released by lamont> <https://launchpad.net/bugs/1580712>
[10:24] <johnnnn> hello, do you know why my nodes stack at -maas enlisting node- ?
[10:41] <brendand> johnnnn, i think it was a bug in an earlier version. what's your version?
[10:48] <johnnnn> its 1.7.6
[10:48] <johnnnn> in the maas it says "node added but never seen" wtf ;D
[11:06] <brendand> ah ok
[11:06] <brendand> i didn't mean that early
[11:07] <brendand> johnnnn, which release is it enlisting with?
[11:08] <johnnnn> i tried ubuntu amd 14.04 but something failed and now I try ubuntu 16 amd
[11:08] <johnnnn> brendand
[11:11] <brendand> johnnnn, i assume the maas-server is trusty?
[11:12] <johnnnn> y
[11:15] <Guest_74744> Allah is doing
[11:16] <Guest_74744> sun is not doing Allah is doing
[11:16] <Guest_74744> moon is not doing Allah is doing
[11:16] <Guest_74744> stars are not doing Allah is doign
[11:16] <johnnnn> brendand, is this a bug?
[11:16] <Guest_74744> stars are not doing Allah is doing
[11:16] <johnnnn> and the point ?    I have a configuration question with MAAS (Latest stable version).  My network setup is that there is a switch per cabinet.  Each switch contains a /24 IP space.  However my MAAS host has a single interface to one of those switches.
[17:36] <jwitko> How can I make it so that MAAS in the one cabinet can provide DHCP and provisioning for servers searching a DHCP lease in the other cabinet
[17:41] <jmmills> jwitko: vlans
[17:41] <jwitko> jmmills my network engineer refuses to implement vlans  ;\
[17:42] <jwitko> jmmills, I know we can set up a dhcp relay.  but then I don't think i can differentiate between the servers right ?
[17:42] <jmmills> Well in order to provde DHCP lease another cabinet with another switch you are going to have to have layer 2 adjacency
[17:42] <jwitko> so i would have no way to identify which server is from which cabinet and therefore can not assign an appropriate IP
[17:42] <jmmills> You could use a DHCP relay
[17:42] <jwitko> so if the switch in each cabinet hosts a /24 address range
[17:42] <jwitko> how would I be able to say, for example
[17:42] <jwitko> "ok you're coming from cabinet2,  therefore you get <IP_ADDRESS>/24 IP"
[17:43] <jwitko> normally this would be done via vlan or interface in MAAS
[17:43] <jwitko> not sure if there is a way to make that work without dedicated physical interface into each switch or vlan tagging ?
[17:43] <jmmills> interface alias for dhcpd?
[17:44] <jwitko> sorry?
[17:44] <jmmills> Set up an interface alias on your maas host, then setup a dhcpd on that interface, then relay to that interface
[17:45] <jmmills> I'm just guessing off the top of my head here
[17:45] <jwitko> jmmills sorry but I fail to see how that solves the above issue?  How would the alias interface be able to tell what cabinet a server was coming in on
[17:46] <jmmills> because each dhcpd instance+alias maps to a specific cabinet and hands out the correct address space
[17:47] <jwitko> so you're saying you set up two DHCP managed interfaces in MAAS and set one up with info for cabinet2.  Then point the DHCP relay on the network side to that interface IP ?
[17:47] <jwitko> The only issue there is MAAS only allows one interface per physical interface to be managed
[17:47] <jmmills> You can add multiple interfaces to MAAS,  no?
[17:48] <jwitko> yes but they must be connected to a physical interface
[17:48] <jmmills> oh yeah, layer 2
[17:48] <jwitko> and only one virtual interface per physical interface can be managed by MAAS at a time
[17:48] <jmmills> vlans
[17:48] <jmmills> tell your network engineer to do his job :)
[17:49] <jwitko> "Another cluster interface already connects network interface p2p2 to an IPv4 network."
[17:50] <jwitko> thats the error MAAS gives when attempting to manage two interfaces connected to the same physical
[17:54] <jwitko> jmmills maybe if i install a second cluster I can do that?
[17:55] <jmmills> Well you could institute policy and say only one MaaS node per switch
[18:01] <mup> Bug #1582836 opened: use http for stream mirror, not https <MAAS:Triaged> <https://launchpad.net/bugs/1582836>
[23:53] <mrhillsman> hey, does rackspace metrics use an openstack project under the hood? if so which one?
[23:54] <mrhillsman> bah, wrong server


[00:08] <mup> PR snapcraft#2968 opened: git: always fetch specified source-commit before using <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2968>
[04:18] <mup> Bug #1857358 changed: Not yet operational on Fedora systems <fedora> <Snappy:Expired> <https://launchpad.net/bugs/1857358>
[06:20] <mborzecki> morning
[06:20] <mvo> hey mborzecki
[06:20] <mup> PR snapd#8240 closed: tests: just remove user when the system is not managed on create-user-2 test (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8240>
[06:35] <mvo> mborzecki: a second review for 8231 would be great
[06:37] <mborzecki> mvo: wow, that AARE for nvme is scary ;)
[06:38] <mup> PR snapd#8231 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8231>
[06:40] <mborzecki> school run, back in 30
[06:40] <mvo> mborzecki: aare?
[07:07] <mup> PR snapd#8243 closed: o/snapstate: set base in SnapSetup on snap revert <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8243>
[07:08] <mborzecki> re
[07:08] <mborzecki> mvo: apparmor regular expressions
[07:10] <mvo> mborzecki: aha, right
[07:11] <mborzecki> and with the latest regulations, parents can no longer enter school buildings, at least in my area
[07:12] <mborzecki> wouldn't be surprised if they close down all schools for a week or so
[07:14] <mvo> mborzecki: that's likely to happen
[07:14] <mvo> I think
[07:20] <mborzecki> hm the failures in 8185 that pedronis saw yday is probably services-watchdog test state leaking into subsequen tests
[07:28] <mup> PR snapd#8185 closed: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8185>
[07:48] <mup> PR snapd#8238 closed: many: fix a pair of ineffectual assignments <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8238>
[07:52] <mvo> mborzecki: I think 8206 is ready for a review too and hopefully an easy win
[07:52] <mvo> mborzecki: we are at 52 now, maybe we can hit 50!
[07:53] <mup> PR snapd#8237 closed: interfaces/{docker,kubernetes}-support: updates for lastest k8s - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8237>
[07:53] <mvo> mborzecki: we have some simple ones like 8220 pending (unfortunately I think this one needs a security review)
[07:53] <mborzecki> mvo: ha, so it was a hanging sleep command
[07:55] <mvo> mborzecki: yes
[07:58] <zyga> good morning
[07:58] <zyga> how are things?
[07:58] <mborzecki> mvo: maybe we should set Ptdeahtsig to syscall.SIGKILL for most commands, not sure we use it at all
[07:59] <mborzecki> zyga: morning
[08:02] <mvo> mborzecki: I think we don't
[08:02] <mvo> hey zyga
[08:06] <pstolowski> morning
[08:06] <mborzecki> pstolowski: hey
[08:07] <mborzecki> mvo: #8206 is green!
[08:07] <mup> PR #8206: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
[08:21] <mvo> zyga: want to double check 8100 ? it got your +1 already but it changed a bit since (more abstractions mostly)
[08:22] <zyga> yeah sure
[08:22] <mvo> zyga: shoudl be simple
[08:22] <zyga> I am in despair
[08:22] <zyga> found my gpg key
[08:22] <zyga> and it's locked
[08:22] <zyga> and I don't recall the password :)
[08:26] <mup> PR snapd#8206 closed: travis.yml: run unit tests on arm64 as well <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8206>
[08:26] <mvo> one more and we are down to 50! maybe 8197? no code change just a refactor for snap downloads via snapd?
[08:27] <mvo> zyga: oh no!
[08:33] <zyga> some heavy rain today
[08:46] <mborzecki> mvo: i'm not dropping SetRecoverySystemEnv from uboot struct yet, for now i've updated ExtractedRecoveryKernelImage.. iface
[08:47] <mborzecki> mvo: although i don't expect needing to use SetRecoverySystemEnv, we'll know for sure after the meeting with the foundations
[08:54] <mvo> mborzecki: +1
[08:55] <mvo> mborzecki: I also added samuele as optional, not sure if he wants to join or not
[08:55] <mborzecki> ok
[08:58] <mborzecki> pedronis: hi, #8224 has conflicts now
[08:58] <mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[08:59] <pedronis> mborzecki: yes, saw that, will try to merge master and address at least partially the XXXs soon
[08:59] <pedronis> mborzecki: thx
[09:01] <mvo> pstolowski: thanks for your update to 8201!
[09:01] <pstolowski> mvo: np. i'm nervous to see if it passes
[09:02] <mvo> pstolowski: heh :)
[09:02] <mvo> pstolowski: *fingers crossed*
[09:02] <zyga> mvo: can you please refresh my memory
[09:02] <zyga> how is snap-repair updated?
[09:04] <mvo> zyga: snap-repair is part of the snapd snap and gets updated when snapd gets updated, was that the question?
[09:04] <zyga> yes, that's mostly it
[09:04] <zyga> I recall we had a copy of snap-repair in core16 systems
[09:04] <zyga> somewhere in writable
[09:05] <zyga> is that the case?
[09:05] <mvo> zyga: I think we talked about it, I don't recall we did it
[09:06] <pedronis> mvo: it's still a todo
[09:06] <zyga> ok, that's what I was curious about thanks
[09:07] <pedronis> mvo: there are still current todos:  https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/39 and https://forum.snapcraft.io/t/repair-capability-emergency-fixes/311/42
[09:08] <pedronis> so the packaging bits, the task for this cycle, plus consider how early it can be run
[09:10] <mvo> yeah :/
[09:11] <zyga> I wonder if snap-repair makes sense in core 20 world
[09:14] <pedronis> it has a role, going through a recovery reboot is not always acceptable especially if there are other solutions
[09:14] <pedronis> otoh it hasn't been used yet for real, so hard to judge
[09:18] <zyga> mvo: reviewed
[09:20] <pedronis> pstolowski: I reviewed 8201, it needs a 2nd review
[09:22] <pstolowski> pedronis: ty
[09:41] <mvo> pedronis, pstolowski I did a pass on 8201
[09:42] <pstolowski> mvo: thanks!
[09:43] <mvo> pstolowski: hope it's not too annoying
[09:43] <pstolowski> mvo: no worries
[09:54] <pedronis> mvo: the extra ticks might be do go through Ensure as well
[09:54] <pedronis> it's not just about prune
[09:54] <pstolowski> yes. but i'll add a comment
[10:03] <mvo> pedronis: thanks, could be, I am just puzzled because AIUI we only mock the ticks for the pruneC and that calls st.Prune() directly, so not sure how Ensure() comes into play. but it's fine, it's so much nicer than before, just tried to get a good understanding what is going on
[10:04] <pedronis> mvo: aborting might need two passes through Ensure
[10:04] <pedronis> mvo: each time we tick prune we also go throgh Ensure
[10:04] <pedronis> or something like that
[10:05] <mvo> pedronis: ok
[10:10] <mvo> cachio: good morning! if you still see this failure of importing the user assertion on uc20 even in the second boot, could you please pastebin/take-a-picture of "journalctl -u systemd-udevd" from the second boot in run mode?
[10:22]  * zyga feels so so and goes for some tea/coffee upstairs
[10:22] <zyga> pedronis: when I'm back I'll attack env again
[10:22] <zyga> pedronis: I read your comments and I'll go and simplify the expression logic and combine it all into Apply
[10:35] <cachio> mvo, sure
[10:35] <cachio> mvo, good morning, I just triggered a new run
[10:36] <cachio> mvo, yesterday it was not goind the run mode, just install mode
[10:36] <cachio> I was waiting for the new core snap that should help on that
[10:37] <mvo> cachio: ok
[10:37] <mvo> cachio: thank you
[10:41] <cachio> mvo, today it is going into the run mode
[10:41] <cachio> https://paste.ubuntu.com/p/n6GJpXNjwQ/
[10:41] <cachio> but still it is not importing the user assertion
[10:42] <pedronis> zyga: I added some more comments about further simplifications I would like to see for now
[10:42] <zyga> pedronis: ok
[10:42] <zyga> I'll read them now
[10:44] <pedronis> zyga: let me know if you have questions
[10:44] <zyga> ack
[10:44] <mvo> cachio: can you do a reboot once it's in run mode and paste me the output of "journalctl -u systemd-udevd" please?
[10:45] <zyga> weird
[10:45] <cachio> yes, waiting for the reboot
[10:45] <zyga> github comments I mean
[10:45] <zyga> I can respond to some of your comments but not all
[10:45] <zyga> pedronis: I was thinking and I'm very happy with []osutil.ExpandableEnv
[10:45] <zyga> because that removes the need for some extra glue logic
[10:46] <zyga> and expresses more naturally what is really going on
[10:46] <pedronis> mvo: do we have a formatting problem in interfaces/policy/basedeclaration_test.go or it's just different go versions
[10:46] <cachio> mvo, https://paste.ubuntu.com/p/GZsNPyNRCC/
[10:46] <mvo> pedronis: I'm not aware of one, but it could be go version screw
[10:47] <zyga> pedronis: I ony edit that file in nano
[10:47] <pedronis> zyga: as far as I know there's no way to "merge" those envs before applying them, that would do what we need
[10:47] <zyga> pedronis: yeah, I came to the same conclusion
[10:47] <zyga> pedronis: I'll get to it :)
[10:48] <pedronis> zyga: we can probably also leave out the Overrides bit from those methods, and just call them Envs() []osutil.ExpandableEnv
[10:49] <zyga> pedronis: I just wanted something that is distinct from the field (Environment)
[10:49] <zyga> pedronis: perhaps we don't need a real method after all
[10:50] <zyga> pedronis: if we change the type to ExpandableEnv
[10:50] <zyga> we can just reach out to app.Snap.Environment and app.Environment
[10:50] <zyga> but we'll see
[10:50] <zyga> first some of the big moves
[10:51] <pedronis> mborzecki: I merged master and updated #8224, the last changes need a new pass
[10:51] <mup> PR #8224: many: clean separation of bootenv mocking vs mock bootloader kinds  <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[10:53] <mvo> cachio: thanks, do you see /lib/udev/rules.d/66-snapd* in your image?
[10:54] <cachio> I cant login to the image
[10:55] <cachio> but let me check if I can unsquash it
[10:55] <mvo> cachio: oh, so the journal output is also not from inside the image?
[10:55] <cachio> no
[10:55] <cachio> the journal output is from the host machine
[10:56] <cachio> in that case let me try to shell on it
[10:57] <mvo> cachio: ok, we probably need to somehow create an image that you can add "systemd.debug-shell=1" to the kernel commandline so that you get a root-shell
[10:57] <mvo> cachio: the output of the udevd would be great to have, that hopefully gives us clues what is brekaing
[10:57]  * mvo needs to leave for a wee bit
[10:58] <cachio> {
[10:58] <cachio> ok
[11:01] <zyga> kid invasion
[11:01] <zyga> silly stuff is lucyasd=ad
[11:01] <zyga> 4WT~WWW
[11:03] <pstolowski> noo, #8201 failed on google:ubuntu-core-20-64:tests/core/snapd-failover. and on prepare for fedora. and on google-unstable:opensuse-15.1-64:tests/main/session-tool
[11:03] <mup> PR #8201: tests: mock prune ticker in overlord tests to reduce wait times <Squash-merge> <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[11:04] <pstolowski> ^ zyga
[11:04] <pstolowski> zyga: https://api.travis-ci.org/v3/job/660982235/log.txt
[11:04] <zyga> pstolowski: ack,
[11:05] <zyga> pstolowski: there must be something I'm missing there
[11:05] <zyga> as it only fails infrequently, there must be some kind of race that makes PAM module which sets up XDG_RUNTIME_DIR fail
[11:07] <pstolowski> zyga: grab the log if you need it, i'm going to restart the tests soon
[11:07] <zyga> done
[11:19] <cachio> mvo, https://pastebin.com/Gh8rrwNP
[11:20] <cachio> for some reason it is getting stuck in that line
[11:20] <cachio> the shell never appeards
[11:20] <mborzecki> hmm arm64 unit tests still hanging?
[11:20] <cachio> mvo, could you chekc pleaseif I did it correctly?
[11:20] <cachio> mvo, https://paste.ubuntu.com/p/fHTdPT2j6Q/
[11:22] <mvo> cachio: please try setting it in  �*Run Ubuntu Core 20                                                         �
[11:22] <mvo> cachio: so when the second grub screen is there you need to press "e" for edit
[11:22] <mvo> cachio: and it in the line with the chainload...kernel.efi there
[11:22] <mvo> cachio: does that make sense?
[11:23] <cachio> mvo, ok, thanks
[11:23] <mvo> cachio: not sure if it gives you a debug shell on the serial console though, gives you one on vt9 for sure
[11:26] <cachio> mvo, I did what you said but it is getting stuck in the same line
[11:27] <cachio> mvo, https://paste.ubuntu.com/p/S8gQq64WPq/
[11:37] <mvo> cachio: oh no! maybe you just don't get a debug shell on the serial port :/ that's sad
[11:41] <cachio> mvo, do you want to connect?
[11:41] <mvo> cachio: not right now, I need to ponder a bit, I will probably need to try to run this locally in qemu to have the full vritual console access :/
[11:42] <cachio> ok, just ping me in case you need the image
[11:46] <mvo> mborzecki: I pushed https://github.com/snapcore/pi-gadget/pull/34
[11:46] <mup> PR pi-gadget#34: gadget.yaml: move ubuntu-boot to VFAT <Created by mvo5> <https://github.com/snapcore/pi-gadget/pull/34>
[11:55] <mup> PR snapd#8100 closed: httputil: add support for extra snapd certs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8100>
[12:07] <mup> PR snapd#8244 opened: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8244>
[12:21] <zyga> mvo: commented on the pi-gadget PR
[12:24]  * pstolowski lunch
[12:25] <mup> PR snapcraft#2963 closed: project: add fallbacks for os.sched_getaffinity <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2963>
[12:27] <mvo> zyga: thanks
[12:44] <cachio> mvo, hey
[12:44] <cachio> I am trying from serial port and I get this
[12:44] <cachio> https://paste.ubuntu.com/p/6RkcpYd4TV/
[12:49] <cachio> mvo, the following run I did't see tha terror https://paste.ubuntu.com/p/Cfkv2w7mfT/
[12:53] <mvo> cachio: this looks like a OVMF bug, I wonder what version is available in gce
[12:56] <cachio> ovmf:
[12:56] <cachio>   Installed: 0~20191122.bd85bf54-2
[12:56] <cachio>   Candidate: 0~20191122.bd85bf54-2
[12:56] <cachio>   Version table:
[12:56] <cachio>  *** 0~20191122.bd85bf54-2 500
[12:56] <cachio>         500 http://us-east1.gce.archive.ubuntu.com/ubuntu focal/main amd64 Packages
[12:56] <cachio>         100 /var/lib/dpkg/status
[12:57] <cachio> mvo, is it ok?
[13:04] <pedronis> mvo: can we turn off arm tests again, they timeout: https://travis-ci.org/github/snapcore/snapd/jobs/661020356?utm_medium=notification&utm_source=github_status
[13:04] <pedronis> sometimes
[13:17] <zyga> pedronis: type Foo *Bar behaves in odd ways in go
[13:17] <zyga> that hides the entire method set of Bar
[13:17] <zyga> is there any way to "reach" it?
[13:21] <pedronis> zyga: that's annoying, I missed this detail, or forgot it
[13:22] <mup> PR snapcraft#2969 opened: snap: re-add xml development packages for non x86 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
[13:23] <pedronis> zyga: anyway the text here https://golang.org/ref/spec#Method_sets has that implication
[13:30] <zyga> thanks
[13:30] <pedronis> zyga: so embedding the OrderedMap seems the only solution
[13:30] <zyga> yeah, I see that
[13:31] <zyga> I think type a = b would be nicer
[13:31] <zyga> but we cannot for now
[13:31] <zyga> ok, I'm not blocked, thank you
[13:49] <zyga> suspend resume on linux with fractional scaling in gnome resizes everything, clipping parts of windows
[13:49] <zyga> oh well
[13:57] <mvo> pedronis: sure, let me do that
[13:59] <mup> PR snapd#8245 opened: travis: disable arm64 again <Created by mvo5> <https://github.com/snapcore/snapd/pull/8245>
[14:40] <mup> PR snapd#8244 closed: [RFC] config: add system.certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8244>
[14:40] <mup> PR snapd#8246 opened: client, daemon, overlord/devicestate: structures and stubs for systems API <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8246>
[14:40] <mborzecki> pedronis: ^^
[14:52] <mup> PR snapd#8245 closed: travis: disable arm64 again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8245>
[14:52]  * cachio lunch
[15:03]  * zyga lunch as well
[15:03] <zyga> and small break to fix backup server
[15:04] <mup> PR snapd#8247 opened: .travis.yml: enable arm64 again as unstable <Skip spread> <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8247>
[15:59] <pedronis> mborzecki: I queued it
[15:59] <pedronis> thx
[16:07]  * zyga is back to finish work
[16:08] <mvo> pstolowski: 8201 is green, do you want to squash merge it and edit the description? I will cherry pick to 2.44 then
[16:09] <zyga> offtopic, firefox is really really fast
[16:13] <pstolowski> mvo: yes, let's squash merge
[16:14] <pstolowski> mvo: doing
[16:14] <mvo> pstolowski: thank you!
[16:15] <mup> PR snapd#8201 closed: tests: mock prune ticker in overlord tests to reduce wait times <Reviewed> <Squash-merge> <⚠ Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8201>
[16:21] <mup> PR snapd#8248 opened: snap: introduce Container.RandomAccessFile <Created by pedronis> <https://github.com/snapcore/snapd/pull/8248>
[16:33] <pedronis> zyga: I looked at the uio fix, one question, also I notice that one of jdstrand comment isn't addressed, it didn't sound just a nice to have from him, in one form or the other
[17:06] <mup> PR snapd#8249 opened: interfaces: make gpio robust against not-existing gpios in /sys <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
[17:07] <zyga> pedronis: hmm, which comment was that?
[17:07] <zyga> pedronis: the one about ordering?
[17:07]  * zyga looks
[17:07] <pedronis> yes
[17:09] <zyga> pedronis: I would not do that in this PR, as I explained in my response that's not a new property and doing anything better (for auditing) would require a smaller dive into the apparmor backend. Doable but not for 2.44 IMO
[17:10] <mup> PR snapd#8250 opened: tests: mock prune ticker in overlord tests to reduce wait times (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8250>
[17:10] <pedronis> zyga: I understand, let's see what he says
[17:11] <zyga> ok
[17:12] <zyga> if needed I can probably implement that ordering tomorrow if I didn't take the swap day
[17:12] <pedronis> is he around today?
[17:12] <zyga> I haven't seen him yet, let me check mail
[17:13] <zyga> no mail about absence (which he carefully sends each time) so I would assume he's around
[17:16] <mup> PR snapd#8251 opened: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251>
[17:25] <zyga> so
[17:25] <zyga> pedronis: env question
[17:25] <zyga> pedronis: snap run --shell foo
[17:25] <zyga> I guess we should apply the environment then, right?
[17:25] <zyga> I guess we should
[17:26] <zyga> I didn't look there deeply, just realized we do that "late" in snap-exec
[17:26] <zyga> and not in snap-confine
[17:44] <jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/8241#pullrequestreview-372983889
[17:44] <mup> PR #8241: interfaces: work around apparmor_parser slowness affecting uio <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8241>
[17:44] <zyga> jdstrand: checking
[17:44] <jdstrand> zyga: conditional ack provided one small change. while doing that, you might do: s/clariry/clarity/
[17:45] <zyga> jdstrand: sure
[17:45] <zyga> jdstrand: I get it, that's sensible,
[17:45] <jdstrand> thanks!
[17:46]  * zyga needs to apologize to everyone, school is cancelled across the country and kids got crazy and are really bothering me all the time now
[17:50] <pedronis> zyga: we should apply the enviroment yes, don't we atm ?
[17:50] <zyga> pedronis: I _hope_ so :)
[17:50] <zyga> I'll get there soon
[17:50] <zyga> pedronis: just thinking about this
[17:51] <zyga> there's some discrepancy between hook and app environment
[17:51] <zyga> specifically we don't perform the save-restore across setuid-lost environment
[17:51] <zyga> though _perhaps_ that's okay, but there's no comment to account for why
[17:52] <pedronis> zyga: as I mentioned, we should move that logic to osutil I think, though it's a bit of an orthogonal problem
[17:52] <pedronis> and not something I would try in this PR
[17:52] <zyga> ok
[17:55] <pedronis> zyga: basically ForExec and OSEnviroment should grow flags or variants to deal with that
[17:55] <zyga> mmm
[17:55] <zyga> I'll stash that as a follow up, close to finishing the changes for the comments in the PR so far
[17:57] <pedronis> zyga: it's relates to this comment here: https://github.com/snapcore/snapd/pull/8242#discussion_r390880508
[17:57] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[18:27] <zyga> pedronis: so env, all but Transform is now done
[18:28] <zyga> I had to invent a method name EnvStack() so please look if you like it
[18:28] <zyga> in any case it's just an implementation detail and doesn't change the big picture
[18:29] <zyga> I'll go after Transform and try to wrap up for today
[18:29] <zyga> mvo: I'll send the paperwork tomorrow
[18:29] <zyga> it's late today
[18:36] <mvo> zyga: sure, see you
[18:37] <cachio> mvo, quick question, I am working tieh the snapd-failover16 test which fails randomly
[18:37] <cachio> mvo, I see this line Mar 11 18:36:27 localhost.localdomain systemd[1]: Started Failure handling of the snapd snap.
[18:37] <cachio> but the service cant fix the dydtem
[18:38] <cachio> is any other source of information to take alook why?
[18:38] <mvo> cachio: hm, journalctl -u snapd.failure  should have some info
[18:39] <cachio> I got that info from there
[18:39] <cachio> I just see that it tries to fix it but no mere info
[18:40] <mvo> cachio: oh, so it tries to fix and fails :(
[18:40] <mvo> cachio: snapd and snapd.failure are the relevant sources
[18:40] <cachio> mvo, right
[18:40] <mvo> cachio: can you pastebin those two when the failure happens?
[18:41] <cachio> mvo, snapd https://paste.ubuntu.com/p/W67D9yf7PG/
[18:42] <cachio> snapd-failure https://paste.ubuntu.com/p/SxGVRzn8YH/
[18:42] <cachio> mvo, it happens right after it installs the snapd broken snap
[18:43] <mvo> cachio: interessting, is it random, i.e. does it sometimes work? or always failing currently?
[18:45] <cachio> first time worked, and 2nd failed
[18:45] <cachio> iwht this vm
[18:45] <cachio> I'll run again
[18:45] <mvo> cachio: so it's essentially random?
[18:45] <mvo> cachio: the logs are really not giving clues, that's a bit sad
[18:45] <cachio> mvo, not happening 100% of the times for sure
[18:46] <cachio> but can't say if it random or not
[18:46] <mvo> cachio: aha, could be another test polluting it?
[18:46] <cachio> mvo, yes, but still trying to figure out that
[18:47] <mvo> cachio: thanks
[18:48] <zyga> pedronis: done
[18:51] <zyga> mvo: if you want to get https://github.com/snapcore/snapd/pull/8242 in to 2.44 please organize some review tomorrow
[18:51] <mup> PR #8242: many: improve environment handling, fixing duplicate entries <Bug> <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8242>
[18:51] <mvo> zyga: is it blocking someone
[18:51] <zyga> mvo: I think it's affecting micro k8s
[18:52] <mvo> zyga: ok,, I need to find out how badly
[18:52] <mvo> zyga: I'm a bit worried that we delay too much
[18:52] <mvo> zyga: but I will look at it tomorrow with fresh eyes and an open mind :)
[18:54] <pedronis> zyga: did you change SetExpandEnv to take multiple ExpandableEnvs ?
[18:54] <zyga> no
[18:54] <zyga> because it's not needed now, it's just applied in chain with the same result
[18:54] <zyga> have a look
[18:54] <zyga> it's also simple, really just a thin wrapper to os.Expand
[18:54] <zyga> I did that briefly but it was just noisier
[18:55] <pedronis> ok
[18:55] <pedronis> I'll look, the diff is smaller, there might be some naming stuff to tweak
[18:55] <zyga> yeah, please feel free to push name tweaks directly to the PR
[18:55] <zyga> I believe everything essential is addressed
[18:56] <zyga> if you want it to take a list or varadic list strongly I don't mind
[18:56] <pedronis> also I thought you weren't going to move the last bit to env
[18:56] <zyga> which last bit?
[18:56] <pedronis> (transform), that might need some tweaks as well
[18:56] <zyga> I killed transform
[18:56] <pedronis> I know
[18:56] <zyga> and made it into a simple pair of helpers to escape/unescape
[18:56] <pedronis> I know
[18:56] <zyga> do you mean that this was supposed to be in ForExec() ?
[18:56] <pedronis> I'm just not sure that the standalone helpers are the best way to encapsulate that
[18:56] <pedronis> but I'll see
[18:57] <zyga> I see
[18:57] <pedronis> they really matter at the process boundary
[18:57] <zyga> it's interesting because look where we escape
[18:57] <zyga> (in snap/snapenv)
[18:57] <zyga> and where we use that (in cmd/snap/cmd_run)
[18:57] <zyga> we'd have to move that logic
[18:57] <pedronis> I know, I thought exactly about that
[18:57] <zyga> that's okay but that's a bigger change than just shoving a function around
[18:57] <pedronis> it's unclear that is placed right in the first place
[18:57] <zyga> yeah
[18:58] <zyga> I think I'm too tired to give useful advice at this time
[18:58] <zyga> I tried to make both uio and exec env branches good today
[18:58] <zyga> and I think exec env should be re-reviewed with fresh head
[18:58] <pedronis> thank you, mostly saying that it might need some small tweaks
[18:58] <zyga> ack
[18:58] <zyga> ok, I'll EOD now
[18:58] <pedronis> that we can do, I think most pieces are there, mostly a matter how to call them
[18:58] <pedronis> where they fit
[18:58] <zyga> this was a good day :)
[18:59] <zyga> yeah
[18:59] <zyga> I think it's also interesting that we are not giving snap-confine the environment that we set in snap-exec
[18:59] <zyga> perhaps we should?
[18:59] <zyga> and snap-exec would not need to read that part of yaml at all
[19:00] <zyga> we could really move those few lines from snap-exec to snap-run with probably, no change at all
[19:00] <zyga> but perhaps that's simplistic, there's some extra interaction with non-run modes of snap-exec
[19:00] <zyga> like strace/gdb and the like
[19:00] <pedronis> yes, I wouldn't do that
[19:00] <zyga> anyway, something to ponder over
[19:00] <zyga> I think it's better than before :)
[19:00] <pedronis> I fear it would need jdstrand input
[19:00] <pedronis> it's a bit unclear what the consequences are
[19:00] <pedronis> also with linker related stuff
[19:00] <pedronis> for example
[19:00] <zyga> we escape those anyway
[19:00] <zyga> so linker would not see it
[19:01] <pedronis> that is true
[19:01] <zyga> but it's indeed interesting
[19:01] <zyga> because some things might affect snap-confine (perhaps) in ways we were not expecting
[19:01] <zyga> e.g. SNAP_CONFINE_DEBUG: true
[19:01] <zyga> so perhaps we should document why we are not setting them outright
[19:01] <zyga> snap/snapexec has some silly copying because I kept the existing structure
[19:01] <pedronis> anyway that's not  a change I want to try right now :)
[19:01] <zyga> but nothing terrible, it's just a few keys anyway
[19:02] <zyga> yes, agreed :)
[19:04] <zyga> jdstrand: FYI I'm off till the end of the week
[19:04]  * zyga waves
[19:10]  * jdstrand is back from meetings and reads scrollback
[19:10] <jdstrand> zyga: have a nice rest of the week!
[19:16] <jdstrand> I don't see anything specifically required of me but I've read the context for if a PR comes though
[19:51] <mup> PR snapd#8224 closed: many: clean separation of bootenv mocking vs mock bootloader kinds  <Reviewed> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8224>
[19:51] <mup> PR snapd#8252 opened: tests: Update test to make snapd snap fixed twice <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8252>
[20:09] <mup> PR snapcraft#2969 closed: snap: re-add xml development packages for non x86 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2969>
[20:10] <pedronis> jdstrand: I marked a new PR for you to review, not related to the env stuff, I think there are some behavior changes in the env stuff, but nothing that effects the overall security design of what we had so far
[20:11] <pedronis> we set the same king of env vars from the same places, and do the same kind of mangling/unmangling of some
[20:11] <jdstrand> pedronis: ok, is this urgent for 2.44?
[20:11] <pedronis> jdstrand: is this one https://github.com/snapcore/snapd/pull/8249
[20:11] <mup> PR #8249: interfaces: make gpio robust against not-existing gpios in /sys <Security-High> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8249>
[20:12] <jdstrand> pedronis: I see, it is small
[20:12] <jdstrand> ok, let me look
[20:26] <jdstrand> pe
[20:26] <jdstrand> meh
[20:26] <jdstrand> pedronis: done
[20:30] <pedronis> thanks
[21:58] <mup> PR snapd#8253 opened: snap-bootstrap: expand data partition on install <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8253>


[01:53] <kalikatz> from what i read so far, client krdc connects to server krfb.  is said server packaged with kubuntu 18.04?
[02:20] <Dragnslcr> kalikatz- yes, the krfb package is available
[02:23] <kalikatz> is it not a defalt install anymore?  (a desktop server?)
[02:29] <kalikatz> i mean, i didnt see a server, and wouldnt want to install one, if one already exists.  As a long time user of "ubuntu", desktop sharing both client and server were default installs
[03:31] <kalikatz> installed krfb: 20s,    Learn of the bug: 1hr,     fix the bug: 2m.   Install is easy, using curve is not
[03:31] <Dragnslcr> Heh, good job ubottu
[03:31] <Dragnslcr> I haven't used krfb in a few years, so I don't really know the state of it at this point
[03:31] <kalikatz> lol did i break the bot?  hehe
[03:32] <Dragnslcr> It just thought you were asking about bug #1
[03:33] <kalikatz> no i wanted to access my laptop from my iphone to check on running screen.  krfb was chosen.  the said problem is that is unable to save its own settings
[03:34] <kalikatz> to compress 1 hr to the time it takes you to read this.   edit the settings in the kwallet
[10:42] <BluesKaj> Hi folks
[12:37] <dsealius> hi
[23:33] <alekksander> h


[00:34] <Gralco> bdmurray who should i assign this bug too? https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/243073
[00:35] <bdmurray> Gralco: nobody - people assign bugs to themselves when they are going to work on them for the most part
[00:36] <Gralco> bdmurray then how do i know i triaged the bug correctly?
[00:37] <bdmurray> You could ask somebody here or stay subscribed to the bug
[00:37] <Gralco> oh okay
[00:38] <Gralco> but there are time when i need to assign bugs to a certain team right
[00:38] <bdmurray> Yes, only for kernel bugs.
[00:38] <Gralco> okay, thank you
[00:39] <Gralco> I haven't been able to triage any bugs recently
[02:55] <wgrant> bdmurray: Wow, that's a bit of an importance definition change!
[02:55] <wgrant> I've been wondering why it wasn't like that already.
[03:19] <persia> I like it.  In addition to reducing the requirement to gauge the general impact on the distribution, it aligns Importance with SRU guidelines.
[03:39] <mrooney> me too, I thought that would be a nice way to do it
[03:40]  * greg-g nods
[03:42] <mrooney> it probably makes life for package devs much better
[03:45] <persia> I suspect it makes life easier for everyone: package maintainers, triagers, QA people, developers, QC people, the stable release team, etc.
[03:48] <mrooney> I don't quite get how it makes it easier for people tracking critical bugs in ubuntu
[03:48] <mrooney> they can milestone and such but how do bugs within a milestone have importances relative to the milestone?
[03:49] <persia> Doesn't matter.  If it's milestoned, it ought get done.  If it isn't getting done in time, the release managers have broad powers of persuasion.  If that also fails, it ought be deferred.
[03:51] <mrooney> I see, fair enough
[11:11] <james_w> Apport session starting now in #ubuntu-classroom if anyone is interested.
[11:17] <\sh> bdmurray: we have to reopen bug #188018 of py-lp-bugs
[11:18] <\sh> argl...I'll file a new one
[11:35] <\sh> fix for bug #243193 <- new edge , py-lp-bugs crashing
[13:01] <james_w> persia: nice work on bug 243211
[13:04] <persia> james_w: Mind you, it could be an encoding issue :)
[13:14] <Igorot> persia: i doubt it's an encoding issue. seems like the reporters' testing out launchpad.
[13:14] <Igorot> or at least trying to submit a test bug report.
[13:17] <persia> Igorot: Very likely.  I just try to avoid assumptions.
[13:34] <safiyyah> is anyone there
[14:19] <pschulz01> Evening.. just joined 5-a-day, and was looking at the untriaged list.
[14:20] <james_w> hi pschulz01
[14:20] <pschulz01> If someone has added a patch (eg. incorrect strings) and it's still in the 'new' state and I can confirm that the patch hasn't been applied yet.. should I cnahe the status to confirmed?
[14:21] <pschulz01> Bug number 65995
[14:21] <techno_freak> bug $65995
[14:21] <techno_freak> bug #65995
[14:23] <james_w> pschulz01: that should be confirmed, yes.
[14:23] <pschulz01> Ta
[14:24] <Hobbsee> pschulz01: is that upstream still dead?
[14:24] <pschulz01> Hobbsee: Hobbsee!!
[14:24] <Hobbsee> heya!
[14:24] <pschulz01> Hobbsee: No idea
[14:25] <pschulz01> Hobbsee: I though I'd use the '5-a-day' to get back into the bug busting business.
[14:25] <pschulz01> (This is my first)
[14:25] <Hobbsee> pschulz01: ahh.  i've not been using it, although i've done about 8 today.
[14:26] <Hobbsee> pschulz01: just poked the debian maintainer, he says he'll do it today, and will file a sync request for it (or will poke me to file one)
[14:26] <pschulz01> Hobbsee: heh it works :-)
[14:27] <Hobbsee> it does.
[14:29]  * Hobbsee does another one.
[14:33] <pschulz01> Hobbsee: bug #65304
[14:42] <pschulz01> If I find that a bug can no longer be duplicated, do I mark it as 'Fix Released'?
[14:42] <pschulz01> bug #68914
[14:42] <pschulz01> (I've done that)
[14:55] <persia> pschulz01: Not every bug that cannot be reproduced is Fix Released, although some are.  Just be sure you have a test case (as you do with that bug).
[14:56] <persia> It's also a good idea to try to check with the version the reported used (if reported) to verify that you could reproduce the failure previously
[15:00] <JohnPhys> Will the fix for bug #55273 be released to hardy?
[15:00] <pschulz01> Does 'Incomplete' mean something like 'More information required'?
[15:00] <pschulz01> persia: This is for another.. bug #70648
[15:00] <pschulz01> persia: bug #70648
[15:01] <persia> "Incomplete" means that the bug doesn't contain sufficient informtion to either confirm or reject.  It can be interpreted as "More Information Required", but should not be assumed to mean that directly.
[15:02] <persia> When a bug is set to "Incomplete", it is essential that the person adjusting it identify what information they believe would be required in order to proceed with triage.
[15:03] <pschulz01> persia: I think I've done that. (Thanks)
[16:39] <bdmurray> gnomefreak: ping
[16:43] <gnomefreak> bdmurray: pong
[16:55] <bliZZardz> hello!
[17:05] <bdmurray> asac: is there a process for needs-packaging extension bugs?
[17:07] <asac> bdmurray: yes. add it to the firefox3extensions page .... fill in the information
[17:07] <asac> and add a firefox-extension project task
[17:07] <bdmurray> asac: which page is that?
[17:07] <asac> bdmurray: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions
[17:08] <asac> bdmurray: Extensions that need a maintainer (Ubuntu QA contact)
[17:08] <asac> bdmurray: or if not all info is available:
[17:08] <asac> "Suggested extensions missing details"
[17:09] <bdmurray> hmm, this is neat thanks!
[17:16] <jkary> Hello.  Can someone please tell me what this error message means?  E: Could not open file /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dist_universe_source_Sources - open (2 no such file or directory)
[17:17] <jkary> I am running Hardy
[17:17] <jkary> I am trying to install some source code using apt-src so I can verify a patch
[17:18] <james_w> jkary: hi, did you just add a "deb-src" line to your sources.list?
[17:19] <james_w> if so did you run "sudo apt-get update" afterwards?
[17:20] <jkary> hmmm.  let me look. one sec.
[17:22] <jkary> I have the follow lines at the top of my sources.list file.
[17:22] <jkary> deb http://ubuntu.media.mit.edu/ubuntu/ hardy main restricted multiverse
[17:22] <jkary> deb-src http://ubuntu.media.mit.edu/ubuntu/ hardy restricted main multiverse universe #Added by software-properties
[17:23] <kenkku> is the source package you are trying to download in that repository?
[17:24] <jkary> aha
[17:24] <jkary> I think I just needed to run apt-get update.
[17:24] <kenkku> yep
[17:24] <kenkku> if you didn't run it, that's what's wrong
[17:24] <jkary> yup.  that was the trick!  Thanks!
[17:42] <thekorn> hello bughunters!
[17:47] <Iulian> G'evening thekorn.
[17:49] <james_w> hey thekorn, Iulian
[17:49] <thekorn> hi Iulian
[17:49] <thekorn> and James
[17:51]  * thekorn wonders why xchat does not show join/part actions anymore
[17:57] <thekorn> james_w, persia : thanks for organizing and presenting the apport-retracer session, I'm reading the log now and it is very informative
[17:58] <bdmurray> thekorn: hello
[17:58] <thekorn> hi bdmurray, thanks for testing py-lp-bugs
[17:58] <persia> thekorn: I'm glad you found it useful.
[18:03] <bdmurray> thekorn: the datereported_test.py script in bug 185357 fails for me with the intrepid.merge branch
[18:04] <thekorn> bdmurray, hmm, looking
[18:08] <thekorn> bdmurray, okay, can reproduce it, seems there was an issue with the thounds merges I did,
[18:08] <thekorn> I missed sometthing
[18:15] <thekorn> bdmurray, false alarm, sorry the sript is wrong, it has to use the +text interface for the Bug-object
[18:15] <thekorn> so line 11 has to be Bug = ConnectBug("text")
[18:16] <thekorn> parsing of the date where a task was created was never implemented in the html mode
[18:17] <bdmurray> thekorn: that makes sense, thanks
[18:22] <geser> thekorn: is it possible to unsubscribe someone (e.g. a team) from a bug with py-lp-bugs?
[18:23] <thekorn> geser, yes, only if the team or user is direct subscribed to this bug
[18:23] <thekorn> geser, let me find an example of code
[18:24] <geser> thekorn: thanks, that was exactly my next question :)
[18:24] <thekorn> :)
[18:27] <thekorn> geser, http://paste.ubuntu.com/23161/
[18:27] <thekorn> very same for teams
[18:29] <geser> thekorn: thanks