[07:15] <pitti> Good morning
[07:21] <ajmitch> morning pitti
[07:25] <TheMuso> Hey pitti.
[07:32] <pitti> hey guys! had a nice weekend?
[07:33] <TheMuso> Yes thanks.
[07:36] <pitti> dobey: can you please fix your upstream ubunutone-client bzr/tarballs license-wise and do a new upload to REVU (or just point me to the source package)?
[09:57] <crevette> heya
[10:01] <crevette> hello pitti
[10:02]  * crevette looked at GDM upstream bugs list and cried
[10:03] <crevette> 55 patches unreviewed
[10:33] <huats> morning
[10:34] <seb128_> hey there
[10:34] <seb128_> GUADEC internet is not so good
[10:35] <crevette> hello seb128
[11:18]  * asac has focus issues in karmic
[11:19] <asac> seb128_: hi. hope you enjoy the conference (and the beach ;))
[11:19] <asac> seb128_: wonder if we should file a bug about apt-get upgrade resetting/crashing X - or is that even fixed?
[11:43] <Keybuk> pitti: I have the *best* gdm bug EVAH
[11:43] <Keybuk> it logs me out after 5-10 minutes ;)
[11:45] <pochu> that's the new typing-break from gnome-keyboard-properties :-)
[12:02] <crevette> Keybuk, me too
[12:03] <crevette> could you look on TT1 if you have weird caracters on the console?
[12:03] <Keybuk> yes
[12:04] <crevette> Keybuk, are you logged you or the session has crashed?
[12:06] <Keybuk> crevette: ?
[12:09] <crevette> Keybuk, are you only logged off or the session has crashed?
[12:10] <Keybuk> crevette: what's the difference?
[12:10] <Keybuk> it looks like a crash to me because I get bailed to the console
[12:11] <crevette> when you logged off, you can connect to your existing session (with you applications running ), when it has crashed, a new session is created
[12:12] <Keybuk> there are no apps running as my user
[12:12] <crevette> okay so I think we have the same problem, for me I can stay more than 5 minutes, it seesm it happened when I open a web browser and type some text in the url bar
[12:12] <Keybuk> once it's happened once, it doesn't happen again
[12:15] <geser> Keybuk: welcome to bug 395595
[12:16] <crevette> thanks geser
[12:17] <geser> asac: the upgrade problem is already filed as bug 395313
[12:25] <asac> geser: thanks
[12:46] <pitti> geser, Keybuk: I'm currently tackling bug 395313
[12:46] <pitti> but I didn't see 395595
[12:59] <asac> thats low prio?
[13:00] <pitti> asac: I'll fix the "always restarts gdm/kills session on upgrade" bug
[13:00] <pitti> I also have a handle on bug 395595 I think
[13:00] <asac> great
[13:01] <pitti> give me an hour or two, I'm on gdm bug fixing rave :)
[13:01] <asac> rock on.
[13:01] <asac> i already wondered how to start debugging this ;)
[13:06] <mvo> they ArneGoetje - would you mind if I convert language-selector from glade to gtkbuilder? you will probably not notice anything, its just a exchange of the object that wraps it (SimpleGtkbuilder instead of SmpleGladeApp) and adding a .ui file that is done with glade-3 ?
[13:08] <TheMuso> mvo: How much work/what is the process to change an app from glade to GTK builder?
[13:08] <TheMuso> Is it documented anywhere?
[13:09] <pochu> TheMuso: have a look at http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder
[13:09] <TheMuso> pochu: Thanks
[13:14] <mvo> TheMuso: its pretty painless in my experience
[13:14] <mvo> TheMuso: most of my stuff uses a small wrapper called SimpleGladeApp and I ported that to gtkbuilder. so it mostly .glade->.ui and exchanging that file :)
[13:14] <TheMuso> ah ok
[13:39] <pitti> mvo: current gdm's prerm file is really bad
[13:39] <pitti> mvo: I fixed init script handling in gdm 0ubuntu3
[13:40] <pitti> is there a way for 0ubuntu3 to say "don't call 0ubuntu2's prerm on upgrade"?
[13:40] <pitti> since that will kill gdm install and your X session, leaving you with a broken gdm
[13:42] <mvo> pitti: uh, that is tricky, the old-prerm is called first, so if that kills X ...
[13:42] <pitti> mvo: ah, so no chance to do something in preinst?
[13:42] <pitti> ok, then we have to live with that, I guess
[13:43] <pitti> the next dist-upgrade will screw your system, and then you need to reinstall gdm
[13:43] <mvo> my initial thought was to rm the old-prerm in the preinst, but I don't think it will work
[13:43] <pitti> I'll write to u-d-a@ then
[13:43] <pitti> mvo: I only need to disable invoke-rc.d, so I wouldn't even need to rm
[13:44] <mvo> its the invoke-rc.d gdm stop that kills it?
[13:44] <mvo> we could hack invoke-rc.d so that it has a check for gdm stop, but that would be a heavy hammer
[13:45] <geser> pitti: looking at http://women.debian.org/wiki/English/MaintainerScripts there seems to be no way to do something before the old prerm gets executed
[13:45] <pitti> ok, thanks guys
[13:46] <mvo> aptdaemon will make it all better, a crashing frontend will not affect the install (or at least it should not)
[14:30] <dobey> pitti, Riddell: is there any sane reason why I can't do "blah blah blah, here is the full text of the license: " with CC-By-SA while I can with GPL?
[14:31] <pitti> dobey: I thought the problem was that the orig.tar.gz doesn't ship a copy of the CC license?
[14:31] <pitti> or was it in debian/copyright?
[14:31] <dobey> COPYING.icons
[14:31] <pitti> perhaps he just overlooked that
[14:31] <dobey> pitti: Riddell was saying i needed the full text in debian/copyright
[14:32] <pitti> ah, because we don't ship CC in /usr/share/common-licenses
[14:32] <pitti> for GPL, BSD, etc. we do, thus a reference to those is enough
[14:32] <dobey> pitti: should i put the COPYING.icons in debian/docs then?
[14:32] <pitti> no, the license into debian/copyright
[14:32] <pitti> (verbatim)
[14:32] <dobey> sigh
[14:38] <rickspencer3> pitti: hi ... I suppose we may was well cancel the team meeting for tomorrow ... thoughts/
[14:55] <dobey> E: ubuntuone-client source: not-binnmuable-any-depends-any ubuntuone-client-gnome -> ubuntuone-client
[14:55] <dobey> pitti: what does that even mean?
[14:55] <crevette> http://lintian.debian.org/tags/not-binnmuable-any-depends-any.html
[14:56]  * crevette is a google bot
[15:00] <pitti> dobey: you can ignore it, it doesn't apply for Ubuntu
[15:00] <pitti> dobey: technically, you should't use exact version dependencies for an arch:all pacakge to an arch:any pacakge
[15:01] <pitti> binNMUs are a Debianism only (right now anyway), so don't worry
[15:02] <Laney> lintian -i will give you a full description of what the errors mean too
[15:03] <Laney> dobey: ^
[15:03] <dobey> pitti: it was because one of the packages was any but should have been all, it seems :)
[15:03] <pitti> rickspencer3: not sure, are there so many people on the summit? I thought about having one, even if it's short
[15:03] <rickspencer3> pitti: ok
[15:03] <pitti> dobey: even better, if they don't have arch dependent stuff
[15:04] <pitti> rickspencer3: how are you and how's DS?
[15:04] <dobey> pitti: nope, it's just python and config files
[15:04] <rickspencer3> pitti: you'll need to drive it though ... I have time to cancel it, but not organize it ;)
[15:04] <rickspencer3> we are having fun, and learning, and meeting a lot of people
[15:04] <pitti> rickspencer3: of course, I planned to
[15:04] <rickspencer3> and no one is sunburned ;)
[15:05]  * pitti uploads a "fix me harder" gdm
[15:06] <rickspencer3> pitti: fyi - I'm going to be out the rest of this week
[15:06] <rickspencer3> I'm gong through and deleting meetings
[15:06] <pitti> :)
[15:09] <dobey> pitti, Riddell: just uploaded new ubuntuone-client with those fixes to REVU
[15:19] <pitti> dobey: cool
[15:31] <asac> pitti: last ffox 3.5 proposed bug was now verified: 331654
[15:32] <pitti> asac, bryce, ArneGoetje, ccheney: fancy having a meeting tomorrow or shall we just skip it? (half of the team is on the desktop summit)
[15:35] <asac> either way is fine for me
[15:59] <ccheney> pitti: i'm off tomorrow
[15:59] <pitti> ok, sounds like we should just skip it
[15:59] <ccheney> pitti: or at least i requested off rickspencer3 hasn't approved it yet
[15:59] <pitti> and discuss stuff by mail
[16:00]  * ccheney thinks he is probably pretty busy in gran canaria
[16:00] <pitti> ccheney: right, should be fine to retroactively approve it later :)
[16:00] <rickspencer3> ccheney: i ok'ed it, but notice it didn't go through
[16:00] <rickspencer3> no worries
[16:00] <ccheney> rickspencer3: ok
[16:01] <pitti> dobey: u1-client uploaded, thanks for fixing
[16:01] <rickspencer3> yeah!
[16:02] <pitti> asac: marked as v-done
[16:03] <pitti> asac: so this should go to jaunty-security or -updates?
[16:03] <asac> pitti: to -security and then to -updates i guess (as we usually do for -security)
[16:04] <asac> thx
[16:05] <pitti> ok, I guess the security team needs to do that then, for USN and all?
[16:05] <dobey> pitti: thanks for all the help :)
[16:06] <pitti> dobey: thanks for bearing with us :)
[16:08] <asac> pitti: its universe, so there is no USN
[16:08] <asac> but i will poke jdstrand
[16:08] <pitti> ah, ok
[16:09] <asac> pitti: i think he wants your ack
[16:09] <asac> pitti: maybe he wanted to see this in -updates first and then copy it to -security ;)
[16:09] <asac> but let me check
[16:09] <pitti> asac: sent my ack, and let me know how he wants this to be handled
[16:09] <asac> yep
[16:10] <pitti> see #u-devel
[16:13] <kenvandine> hey pitti
[16:13] <pitti> hey kenvandine
[16:13] <kenvandine> so trying to package this stuff up created by quickly
[16:14] <pitti> kenvandine: empathy dependency trail never ends :(
[16:14] <kenvandine> it isn't including the python files :)
[16:14] <kenvandine> oh crap
[16:14] <kenvandine> geoclue was axed... what now?
[16:14] <pitti> kenvandine: which python files?
[16:14] <pitti> kenvandine: I updated the bug; butterfly
[16:14] <kenvandine> the ones in the python subdir
[16:14] <pitti> not sure wheter we want it
[16:14] <kenvandine> oh... pymsn?
[16:14] <kenvandine> we do...
[16:14] <kenvandine> imho
[16:14] <pitti> kenvandine: can you please file a bug against p-distutils-extra about it with a test case?
[16:14] <kenvandine> that is where the attention is
[16:14] <kenvandine> yeah
[16:14] <kenvandine> actually
[16:14] <kenvandine> maybe i am not up2date :)
[16:15] <pitti> kenvandine: does that subdir have an __init__.py?
[16:15] <kenvandine> doh!
[16:15] <pitti> (also, it sholdn't be called "python", but like the python package name)
[16:15] <kenvandine> i know
[16:15] <kenvandine> just explained that to rick
[16:15] <pitti> but python packages need an __init__.py
[16:16]  * kenvandine should have noticed
[16:16] <pitti> python modules are currently searched only in the source root
[16:16] <pitti> if we want p-d-e to look for modules (not packages) in subdirs, we need to establish a convention
[16:31] <rickspencer3> pitti: hey
[16:32] <rickspencer3> what does this mean:
[16:32] <rickspencer3>    gtk ... [dpkg -S found more than one package: python-gtk2, python-apt, language-selector, apturl, software-properties-gtk; ignoring] [not found]
[16:32] <rickspencer3> ?
[16:32] <pitti> rickspencer3: it means that it cannot figure out the dependency for the "gtk" python module
[16:33] <pitti> rickspencer3: I thought I fixed that in version 2.4?
[16:33] <rickspencer3> pitti: perhaps I need to update
[16:35] <rickspencer3> pitti: it looks like I'm running 2.4
[16:38] <pitti> rickspencer3: did you install from karmic or build from my branch?
[16:38] <rickspencer3> pitti: your branch
[16:39] <pitti> rickspencer3: ok, sounds like a bug then; mind filing one with that output and the code you are building?
[16:39] <rickspencer3> pitti: n/p
[16:39] <rickspencer3> asap, maybe tonight or tomorrow though
[16:40] <rickspencer3> pitti: before I do that, I should install from your last known good
[16:40] <pitti> rickspencer3: you should have the current version
[16:41] <pitti> rickspencer3: doesn't really matter for now, it should work anyway
[16:41] <rickspencer3> https://edge.launchpad.net/%7Epitti/+archive/ppa/+sourcepub/663833/+listing-archive-extra
[16:41] <pitti> rickspencer3: assuming that you have python-gtk installed
[16:47] <robert_ancell> bryce, Is there any pending uploads for -ati drivers and the latest kernel?  I'm getting "(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch."
[17:52] <didrocks> chrisccoulson: (hi!) out of curiosity, how did you find the renamed option in gnome-screensaver?
[18:06] <pitti> good night everyone!
[18:34] <jbarnes> pitti: ping
[18:35] <jbarnes> pitti: just wondering if you can gdb your i915.o and do a "list *intel_update_watermarks+0xcf"
[19:47] <macvr> hi... does the desktop team/mailing list also involve in the usability issues of UNR?
[19:57] <macvr> ah...just now i was reminded about the mobile team!
[20:17] <chrisccoulson> hi didrocks
[20:18] <chrisccoulson> i just ran gnome-screensaver --debug and watched the console output. gnome-screensaver-dialog pipes its output back to gnome-screensaver, which made debugging a bit easier than i expected
[20:18] <chrisccoulson> when i volunteered to debug it, i was expecting to spend an entire weekend on it ;)
[20:19] <chrisccoulson> i was pleasantly surprised
[21:14] <SiDi> pitti: hello. Do you know what happened to this bug : https://bugs.launchpad.net/gnome-power/+bug/329296 ?
[23:27] <james_w> gdm calling ck-history --frequent isn't pretty IMO


[04:39] <JonHanDin> Question to those who are much more in the knowledge. I by default use UFW for desktop. For server I use IPTABLES but its configured using a GUI provided by my server mgmt GUI - Are there any IPTABLES cheatsheets. I'm a noob, it seems like a lot of work. Is it as much work as it looks or am i missing something?
[05:07] <lotuspsychje> !firewall | JonHanDin
[06:01] <lordievader> Good morning
[06:15] <blackflow> The zombieload PoC is scary. If this is not the final coffin in the public "cloud"/VPS industry's coffin, I don't know what is. We dropped all public clouds like hot potato back in 2017.
[06:55] <ducasse> JonHanDin: you can use a frontend, like 'ferm' - it makes rules easier to write
[07:22] <JonHanDin> ducasse:You are a star! that is exactly what i have been looking for. Thank you very much
[07:23] <lotuspsychje> !cookie | ducasse
[07:23] <ducasse> JonHanDin: you're very welcome :)
[11:34] <cpaelzer> jamespage: coreycb: please see the question in #ubuntu-hardened when MDS arrived in UCA PPAs
[11:36] <jamespage> cpaelzer: I've joined but can't see
[11:36] <cpaelzer> I'll repeat the question jamespage
[11:37] <cpaelzer> umm I didn't see you joining
[11:37] <cpaelzer> let me check if I mistyped the chan
[11:37] <cpaelzer> no seems fine
[15:58] <rbasak> ahasenack: any action needed on bug 1827041?
[16:25] <ahasenack> rbasak: research where the regression was fixed between samba 4.7.6 and 4.8.4
[16:50] <rbasak> ahasenack: thanks. So just leave in the backlog?
[16:51] <ahasenack> yep, you can add a comment stating the above, but otherwise, that's it
[16:51] <ahasenack> we have enough to search for a fix: reproduced, and where it happens and doesn't happen
[16:52] <rbasak> Commented. Thank you!


[00:14] <psanchez_> hmm, ok, not a good start for snappy and docker ... -1 ... I'll ask again tomorrow.
[07:16] <fgimenez> good morning
[07:28] <davidcalle> Morning o/
[07:35] <clobrano> good morning
[09:01] <JamesTait> Good morning all; happy Friday, and happy Respect Day! 😃
[09:07] <clobrano> A basic question: how do you test changes in snappy itself? how can I install it?
[09:08] <mvo> clobrano: if you modify snappy itself you can just copy in into our snappy system and run it via sudo ./snappy something
[09:11] <clobrano> mvo: doesn't snappy need any particular permission? Can I run it just like that?
[09:12] <ogra_>  sure
[09:12] <clobrano> ok, thank you
[09:13] <mvo> clobrano: one nice property is that its a single binary so for the most part this method of just copyign will work
[09:13] <clobrano> mvo: great :)
[09:14] <ogra_> if you want to test it deeper in the system you can also make the filesystem writable, copy it in place and switch back to readonly
[09:14] <ogra_> i.e. to test something that happens during boot or so
[09:15] <ogra_> the base system is still just a normal linux system ... just without traditional package manager
[09:15] <clobrano> ogra_: how do I make the fs writable?
[09:15] <ogra_> sudo mount -o remount,rw /
[09:15] <ogra_> sudo mount -o remount,ro /
[09:16] <clobrano> ogra_: oh sure, I was expecting something special :D
[09:16] <ogra_> heh
[09:17] <mvo> yeah, ogra_ made great suggestions. some stuff can only be tested by copying (snappy booted for example which is run by a startup job)
[09:17] <clobrano> perfect
[09:24] <davidcalle> mvo, ogra_, I need to do a small doc fix in the 15.04 branch, should I merge to snappy/trunk first, then snappy/15.04?
[09:25] <mvo> davidcalle: easiest is probably to just do it 15.04 and then we merge the 15.04 change to trunk
[09:25] <mvo> davidcalle: i.e. just do it on 15.04 and we will take care of the rest :)
[09:28] <davidcalle> mvo, sounds good :) https://code.launchpad.net/~davidc3/snappy/oem-docs-formatting/+merge/271624
[09:29] <davidcalle> mvo, ty
[10:04] <longsleep> Hey folks, i noticed that my ODROID-C image does not have most of the firmware files in /lib/firmware - is that expected when a device tarball with system/.. tree is used?
[10:28] <ogra_> longsleep, you need to ship it in the device tarball
[10:28]  * ogra_ has the same issue on rpi
[10:37] <ogra_> davidcalle, *next' release will bring official RPi support ...
[10:37] <ogra_> we'Re not there yet :)
[10:39]  * davidcalle adds a "don't open before christmas" label on the email
[10:40] <davidcalle> ogra_, alright then :)
[11:01] <longsleep> ogra_: sorry i got distracted, you say i have to ship all the firmware in the device tarball right?
[11:01] <ogra_> yeah ... just unpack linux-firmware in the tree when you create it
[11:02] <longsleep> ogra_: ok cool, thanks!
[11:42] <asac> o/
[11:42] <asac> my pi is on #5 :)
[11:42] <asac> feels faster
[11:43] <ogra_> heh
[11:43] <ogra_> i bet thats subjective
[11:43] <asac> guess thats just the excitement because i had to invest to get tehre
[11:43] <asac> :)
[11:43] <ogra_> yeah
[11:43] <asac> and snappy list bails very quickly
[11:43] <asac> https://bugs.launchpad.net/snappy/+bug/1497245
[11:44] <ogra_> you and your exotic packages :P
[11:45] <asac> well, vendor field wasnt mandatory no?
[11:45]  * ogra_ isnt sure
[11:45] <ogra_> probably it is now
[11:45] <asac> in any case, think for list and in particular remove we should be super robust against anything
[11:46] <asac> i think its mandatory for 16.04 ... but not for 15.04
[11:46] <ogra_> we backported trunk ...
[11:55] <sergiusens> asac, vendor was always mandatory
[11:56] <sergiusens> asac, the store at least booted you because of that, did you manually install?
[11:56] <asac> sure
[11:56] <asac> my beloved zigbee gateway :(
[11:57] <asac> lol
[11:57]  * asac goes and manually removes the app from /apps and the other prominent places
[11:57] <sergiusens> asac, why didn't you upload it to the store ? sounds like an interesing app ;-)
[11:58] <asac> yay what i love about snappy is that there is no cache/meta files
[11:58] <asac> sergiusens: like most of our apps they are customer related as they prep for launching big devices :P
[11:59] <asac> thats why in store we have like 2% of the existing snappy apps at best
[11:59] <sergiusens> I was just punning :-)
[11:59] <asac> i know
[11:59] <asac> sergiusens: good that you are awake again
[11:59] <asac> the call is cancelled...
[11:59] <asac> NOT :)
[11:59] <asac> lol
[11:59] <sergiusens> asac, well, meetings! ;-)
[11:59] <asac> will be there in 1 minute
[12:00] <ogra_> huh ?
[12:00] <ogra_> why the heck is the clinic a hangout
[12:00] <ogra_> thats nonsense
[12:01] <asac> ogra_: its a meeting
[12:01] <asac> you coming?
[12:02] <ogra_> asac, what for ?
[12:03] <ogra_> asac, if we want to do a clinic it should be on IRC ... i.e. a special time where we help with specific developer problems
[12:05] <zyga> ogra_: moar hangouts
[12:28] <dholbach> I think https://code.launchpad.net/~zyga/snapcraft/gitignore/+merge/271313 and https://code.launchpad.net/~dholbach/snapcraft/1496789/+merge/271444 can be landed, right? :)
[12:32] <ogra_> asac, mvo_, so i dont think there is any solution to the Pi update issue without actually releasing a stable #6 ...
[12:32] <ogra_> i guess we should just release-note it that you have to manually copy the kernel pieces
[12:33] <mvo_> ogra_: yeah, its really really hard :/ will the generic kernel not boot at all? or what will happen?
[12:34] <ogra_> it hangs hard at "Starting kernel ..."
[12:34] <mvo_> meh
[12:34] <ogra_> doesnt even unpack it completely
[12:35] <mvo_> yeah, that does not give us many options :(
[12:35] <ogra_> right
[12:35] <ogra_> we could hack something into the s-i process or some such ... but that would still require a #6 release
[12:37] <ogra_> (at least for armhf)
[12:37] <ogra_> we could indeed do an armhf only release ... at the cost of gettin the image numbers out of sync
[12:40] <dholbach> thanks sergiusens
[12:47] <mvo_> ogra_: yeah, I really have no good idea either, lets create the device thing on the server so that we are safe for the future, I talk to sil
[12:48] <ogra_> yup. i see that :)
[12:49] <ogra_> mvo_, the other question is ... why is there a kernel in /boot at all :) i thought we added code to remove it in livecd-rootfs
[12:50]  * ogra_ wonders if that only went into rolling
[12:52] <ogra_> ah, so it did
[12:55] <plars> ogra_: heya, quick rpi2 question for you if you have a moment - We're seeing that our ethernet hwaddress changes on every boot, I'm guessing because it has the serial as all 0s in proc cpuinfo. Is there any way you know of to have it configure a serial or come up with a static hwaddress?
[12:55] <ogra_> plars, seems you are using an outdated image
[12:55] <ogra_> that was fixed a while ago
[12:56] <plars> ogra_: well, I'm not booting to snappy yet, this is just an ubuntu image as a base, and we'll boot snappy from there. What was the fix?
[12:57] <ogra_> changing uboot and reading the binary blob data into the kernel cmdline
[12:57] <ogra_> the binary blob provides the actual MAC in a variable
[12:58] <plars> ogra_: which binary blob is it reading, and how does it get passed?
[13:00] <ogra_> the binary blob that boots your board
[13:00] <ogra_> i.e. the graphics driver that acts as bootloader :)
[13:02] <zyga> ogra_: we're all waiting for our nvidia overlords to boot our x86 pc
[13:02] <ogra_> plars, i dont remember exactly, iirc you need to crate a cmdline.txt next to the config.txt
[13:02] <ogra_> it needs to contain something ... then the args get handed over to the uboot env
[13:03] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /boot/uboot/cmdline.txt
[13:03] <ogra_> elevator=deadline
[13:03] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^args
[13:03] <ogra_> args=dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2709.boardrev=0xa01041 bcm2709.serial=0x8b04db1c smsc95xx.macaddr=B8:27:EB:04:DB:1C bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  elevator=deadline
[13:03] <ogra_> that is how my Pi expands the cmdline
[13:03]  * ogra_ forgot if there were additional steps required
[13:04] <plars> ogra_: weird, I actually copied the boot directory from snappy
[13:04] <ogra_> from image #4 ?
[13:04] <plars> ogra_: so I'm not sure what could be missing
[13:04] <ogra_> that only landed in the last image
[13:04] <plars> ogra_: from one I downloaded last night
[13:04] <plars> ogra_: how recent was that?
[13:05] <plars> ogra_: I just grabbed the prebuilt one
[13:05] <mvo_> ogra_: yeah, that puzzles me too, on armhf we really do not need that in /boot
[13:05] <ogra_> well, if it is the one from ~/platform thats the most recent one
[13:05] <ogra_> mvo_, i think we just didnt pull the change into the PPA
[13:05] <mvo_> ogra_: oh, ok
[13:05] <mvo_> ogra_: that makes sense
[13:05] <plars> ogra_: yes, that's the one
[13:05] <ogra_> i see the right code in live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary in wily
[13:06] <ogra_> plars, weird
[13:06] <asac> ogra_: its fine
[13:06] <ogra_> should definitely work then
[13:06] <asac> ogra_: can you reply to the release thread explaining the workaround?
[13:06] <ogra_> asac, will do
[13:06] <asac> or togetyher with your release announce when the pi2 is there
[13:06] <ogra_> there too
[13:06] <ogra_> cant mention it often enough ;)
[13:06] <asac> just say "becauyse pi2 is not officially consumed from channels you need to do these copies after snappy update
[13:06] <asac> and done
[13:07] <asac> yep
[13:11] <ogra_> sergiusens, i'm looking at package.yaml for pi and BBB oem snaps ... i dont see where it would define generic_armhf vs raspi2_armhf
[13:11] <asac> i think sergio forgot to add that optioon to the yaml
[13:11] <asac> was an oversight. we discussed a while back to have another field
[13:11] <ogra_> "architecture: armhf" is what i see in both currently
[13:11] <asac> beyond architecture
[13:11] <asac> channel:
[13:11] <asac> or somethign
[13:11] <asac> generic
[13:11] <asac> pi2
[13:11] <asac> etc.
[13:11] <ogra_> i see platform ... but that only defines the default dtb
[13:12] <asac> does the azure have an oem snap?
[13:12] <asac> if so it might have that info
[13:12] <asac> but guess it still is created with manual
[13:12] <ogra_> if azure does it isnt in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
[13:12] <asac> that much i know
[13:12] <asac> but doesnt mean there isnt one
[13:13] <ogra_> right
[13:13] <asac> anyway, i know it was a missing field before 15.04 release and most likely we just didnt add it
[13:13] <plars> ogra_: weird, I don't see it in the uboot environment, but I do see usbethaddr there, but I don't see it get used
[13:13] <ogra_> plars, usbethaddr is wrong
[13:13] <asac> but adding a new field with default "generic" shouldnt be a problem
[13:13] <ogra_>  smsc95xx.macaddr is what you need
[13:13] <asac> just remember to add cards etc.
[13:13] <plars> ogra_: it's the one I ended up with when I booted snappy
[13:14] <plars> ogra_: but not when I boot something else - then it's random even though I copied all the bootloader files and uboot from the snappy image
[13:14] <ogra_> do you have uboot.env ?
[13:15] <sergiusens> asac, ogra_ since we don't want to expose s-i in snappy so high up; it was never there; you can build with u-d-f passing --device with the channel (like for azure); but it might only work for azure (as we don't want to make it easy to go down a path we can't support)
[13:15] <plars> ogra_: I do
[13:17] <asac> sergiusens: platform: ?
[13:17] <asac> that doesnt feel like surfacing something from si if we use that
[13:17] <ogra_> plars, and is it used ?
[13:17] <plars> ogra_: yes
[13:17] <sergiusens> ogra_, http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/view/head:/ubuntu-device-flash/snappy.go#L123
[13:17] <ogra_> (do you see it pload properly in the serial log)
[13:17] <asac> architecture: + platform: (optional, default: generic)
[13:17] <sergiusens> asac, we had platform; but in the end this would be in the kernel snap
[13:18] <plars> reading uboot.env
[13:18] <ogra_> sergiusens, deviceChannel ?
[13:18] <plars> ogra_: yep :)
[13:18] <sergiusens> ogra_, --device
[13:18] <asac> sergiusens: wait, in OEM snap specifying what platform this is for makes sense
[13:18] <asac> hmm
[13:18] <ogra_> ah, s.device ... right
[13:18] <asac> oor we just say kernel: pi2
[13:18]  * ogra_ looked to far down
[13:18] <asac> default: generic
[13:18] <asac> doesbnt matter for OEM snap... we will revisit those fields for 16.04 anyway then
[13:18] <sergiusens> asac, ok; makes sense
[13:21] <plars> ogra_: surely it's pulling the serial from the board somehow and not from the image though, right?
[13:21] <ogra_> plars, yeah, same thing
[13:21] <ogra_> bcm2709.serial=0x8b04db1c
[13:21] <ogra_> cmdline option
[13:21] <ogra_> seeded from the binary blob
[13:22] <ogra_> plars, if you intercept the boot, do you see "args" ?
[13:22] <ogra_> in printenv
[13:23] <plars> ogra_: no
[13:23] <plars> ogra_: was there something in the kernel needed for this?
[13:23] <ogra_> no
[13:23] <ogra_> thats pre-kernel
[13:23] <ogra_> but ...
[13:23] <ogra_> mmcargs=setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot}"
[13:24] <ogra_> and snappy_boot calls "run mmcargs" on first boot
[13:25] <ogra_> plars, ah, and:
[13:25] <ogra_> loadfdt=fdt addr 0x100; fdt get value args /chosen bootargs
[13:25] <ogra_> try running that line
[13:25] <ogra_> and then see if args= exists
[13:25] <ogra_> if so, add it to your non snappy boot
[13:26]  * ogra_ forgot you have to pull te dtb from ram in to have the values
[13:26] <plars> ogra_: just "args"? no still not set
[13:26] <ogra_> that was the bit :)
[13:26] <plars> ah, I see
[13:26] <plars> get value args /chosen bootargs
[13:26] <plars> hang on let me try that
[13:26] <ogra_> fdt addr 0x100
[13:27] <ogra_> you need that first
[13:27] <plars> ogra_: running loadfdt did it, thanks!
[13:27] <ogra_> cool
[13:27] <mvo_> ogra_: we have a raspi2_armhf platform now!
[13:27] <ogra_> mvo_, yeah, i see that !!
[13:28] <ogra_> mvo_, i'll triger an edge build to see of it imports fine
[13:28] <asac> on rolling? nice ;)
[13:28] <ogra_> no
[13:28] <ogra_> https://system-image.ubuntu.com/ubuntu-core/15.04/edge/
[13:28] <ogra_> on 15.04 edge :)
[13:29] <ogra_> build running
[13:30] <mvo_> I added it to rolling and 15.04 so we should be fine
[13:30] <mvo_> now I guess we just update reference image and the upgrade problem is solved for good
[13:30]  * mvo_ is happy
[13:33] <ogra_> mvo_, the importer will now run 5min longer
[13:33] <ogra_> or so
[13:33] <ogra_> new arch means moar diffing
[13:34] <mvo_> meh
[13:35] <clobrano> I saw an unexpected (for me) behavior in hw-assign: each call to hw-assign overwrite the udev rule for the <snap>, while the list of write_path in <snap>.apparmor.json.additional is just updated
[13:36] <clobrano> so that udev rule only contains 1 device node at a time
[13:37] <asac> hmmm
[13:37] <asac> http://paste.ubuntu.com/12448771/
[13:37] <asac> Chipaca: mvo_: the above looks pretty garbled formatting wise
[13:38] <asac> is it possible to improve the way we present multi-line yaml?
[13:38] <asac> like the content: one for the network interface looks much nicer
[13:39] <asac> jdstrand: see clobrano's questiona bout hw-assign... feels like a bug
[13:39] <asac> 6 lines above
[13:41] <jdstrand> yes, it does
[13:42] <clobrano> http://paste.ubuntu.com/12448814/
[13:42] <mvo_> asac: I think the problem is the \t it can only represented in the "" form. looks at the startup above, this is what it should look like
[13:42] <jdstrand> clobrano: can you file a bug at https://bugs.launchpad.net/snappy/+filebug ? you might add a comment that it is (perhaps) hindering on your progress on the other bug
[13:43] <clobrano> sure
[13:43] <clobrano> well, it is not really hindering, I just saw that I had to change device name at each try :D
[13:46] <dholbach> fgimenez, I'm not sure this helps a whole lot, but I thought I'd share what I was playing around with: https://code.launchpad.net/~dholbach/snapcraft/examples-tests/+merge/271649
[13:46] <dholbach> fgimenez, great work on adding the examples test
[13:46] <dholbach> tedg, the qmldemo example is still broken on wily - do you know how to fix it?
[13:46] <fgimenez> dholbach, i'm looking into it right now, thanks a lot :)
[13:47] <dholbach> <3
[13:48] <sergiusens> pitti, you once told me, iirc, that we can enable autopackage tests on PPAs?
[13:48] <pitti> sergiusens: that's the plan, yes
[13:49] <pitti> not implemented yet because too many diversions and kernel testing having higher prio
[13:49] <pitti> sergiusens: but I definitely want this too; might still be a few weeks, though
[13:49] <sergiusens> pitti, oh, still on paper :-) ah, but sooner than I thought :-)
[13:50]  * sergiusens puts a 1 month away reminder
[13:50] <pitti> sergiusens: is this something important/critical for snappy development?
[13:50] <tedg> dholbach: I think so, I just need to get a wily VM setup
[13:51] <sergiusens> pitti, we just added lots of tests; we run them before merging but would be nice to run on package build as well
[13:51] <sergiusens> pitti, so important, but not critical
[13:51] <pitti> sergiusens: i. e. next week I need to work on prototyping the "run deb chroot on snappy" thingy for the snappy sprint the following week; if this is important, I'm happy to work on that on the sprint and have you test it :)
[13:51] <sergiusens> pitti, I will defer to elopio on that ;-)
[13:51] <sergiusens> pitti, sounds good!
[13:52] <pitti> sergiusens: the mere act of running them is actually fairly simple; it's mostly how to trigger them and what to do with the results which is the interesting bit there
[13:54] <tedg> jdstrand: Is there a permission to read/write the user's home directory?
[13:54] <sergiusens> yeah, I hear you, integrating it all together is what mostly blocks things from getting done
[13:55] <sergiusens> tedg, wrt question, I was thinking that the wrapper for binaries should cd to $SNAP_APP_DATA_PATH (the one in $HOME)
[13:55] <clobrano> jdstrand: here it is https://bugs.launchpad.net/snappy/+bug/1497299
[14:04] <tedg> sergiusens: Why?
[14:06] <sergiusens> tedg, there was a docker bug that affected that; but yeah; I guess it will break badly in most occasions
[14:06] <sergiusens> tedg, although no binary can read outside its containment either
[14:06] <tedg> sergiusens: I think we should probably have a conversation about how we expect UAL to work with core launcher.
[14:07] <tedg> sergiusens: I'm curious if we want to seperate out "run as a user" and "run as root"
[14:07] <tedg> sergiusens: For instance, setting the XDG* variables so that most things will "just work" with that being their only writable directory
[14:11] <kickinz1> tedg, sergiusens docker is not allowed by apparmor to read data outside its own $HOME/apps/docker/version directory.
[14:13] <tedg> sergiusens: mvo_: Do we have an idea how to finish off this branch? https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831
[14:15] <sergiusens> tedg, I like it already, we just need to trim manifest.txt
[14:24] <sergiusens> tedg, my brain will explode with this one https://code.launchpad.net/~ted/snapcraft/inception/+merge/271656 :-P
[14:24] <tedg> sergiusens: Yeah, it's kinda fun. We should run all our tests in the snappy CI service :-)
[14:25] <sergiusens> tedg, hah, this is rather useless though as we depend on build tools still but rather interesting in itself
[14:25] <sergiusens> tedg, if we get rid of build tools we can certainly cater for this
[14:26] <tedg> sergiusens: Yeah, it feels like something we should do. If we want other people to include a snapcraft.yaml in their repos.
[14:33] <elopio> ev: can we talk about jenkins?
[14:33] <ev> elopio: sure!
[14:34] <elopio> ev: I played with the svn config sync plugin and it needs to push to git. For that we need to put the ssh public key of jenkins on launchpad.
[14:34] <elopio> ev: is that ok for you?
[14:41] <ev> elopio: I'm confused; what's the security risk you're eluding to?
[14:42] <elopio> ev: no security risk. Just to push the config to the git branch in launchpad we need the key.
[14:43] <ev> elopio: and while we're talking about Jenkins, can I ask that you guys focus on getting your Canonistack Jenkins driving daily testing of Snappy through SPI before all the time gets eaten up transitioning to Jenkins as a service?
[14:43] <ev> I didn't realise this was going to require so much work for you guys, otherwise I wouldn't have suggested Jenkins as a service until we saw a steady stream of results in SPI.
[14:44] <ev> elopio: can't you have a separate ssh key that you generate for the purpose?
[14:44] <ev> something like http://superuser.com/a/232406
[14:45] <ev> oh, I guess when we're dealing with public keys it really doesn't matter
[14:45] <ev> so yeah, I think it's reasonable for you to put the public key in LP
[14:45] <ev> +1 :)
[14:46] <elopio> ev: I'm not sure if I can tell the plugin to use a different key.
[14:46] <ev> yup, that's fine
[14:46] <elopio> ev: ok, let me ask for it on an RT.
[14:46] <ev> cool
[14:46] <ev> please do CC me
[14:46] <elopio> ev: what's taking long is that we had a release this week, and we have another next week.
[14:46] <elopio> so we actually didn't touch ci at all this week.
[14:47] <ev> elopio: is there anything I can do to help you guys get your tests running daily on SPI?
[14:48] <elopio> ev: I think not, this was the last question I had. Let me give it another try after the snapcraft release.
[14:48]  * ev nods
[14:48] <Chipaca> asac: mvo_: tbh the file-contents-as-value-of-key thing is rather nasty, and i'd change it if we're going to do that long term
[14:49] <Chipaca> asac: mvo_: ie treat values that are files differently, e.g. yaml points to /1.0/packages/{pacakge}/config/{uuid}, and you GET/POST to .../uuid to operate on the file
[14:52] <tedg> pitti: Have you talked to the libertine container folks about running deb containers?
[14:52] <pitti> tedg: libertine? no, I didn't (I don't even know what that is)
[14:53] <pitti> tedg: running it as an actual container is fine; but AFAIUI sabdfl suggested running them in a chroot with shared processes
[14:53] <mvo_> Chipaca: I don't follow, sorry. but I'm in a meeting rightnow so maybe I just need to re-parse this
[14:53] <pitti> so that from within that you can "admin" snappy
[14:53] <tedg> pitti: It does both, depending on kernel version
[14:53] <pitti> this comes at quite a high cost and loss of reliability, though
[14:53] <tedg> pitti: Basically it is the same feature for phones
[14:53] <tedg> pitti: It would be nice if we had one set of this code :-)
[14:53] <asac> Chipaca: yeah sounds reasonable
[14:54] <asac> Chipaca: like a resource:// thingy
[14:54] <asac> is there any yamnl extension that is standard for such?
[14:55] <pitti> tedg: ah, https://launchpad.net/libertine ? thanks for the pointer, I'll look at that
[14:55] <tedg> pitti: You should chat with ChrisTownsend about it some
[14:55] <tedg> pitti: I think they're basically the same goals, it'd be nice if we converged on one solution for phone/snappy
[14:56] <ChrisTownsend> pitti: tedg: Yeah, I'm here.  bregma too
[14:56] <pitti> tedg: not sure -- this sounds like you actually want to containerize and isolate this
[14:56] <pitti> tedg: but either way, I'll look at this and talk to ChrisTownsend, thanks
[14:57] <tedg> pitti: It started more with containers, but because of the old kernels on the phones it grew chroot. So the description might not match the implementation in that regard.
[14:58] <ChrisTownsend> tedg: Libertine supports both chroot and lxc.
[15:00] <Chipaca> dunno
[15:03] <ChrisTownsend> pitti: FYI, I'll be around today, but off next week.  bregma can definitely help too.
[15:14] <pitti> ChrisTownsend: does this do anything like discovering sysv init and systemd jobs in the chroot and start them from the host, but properly chrooted?
[15:15] <pitti> ChrisTownsend: that seems to be the most brittle/heuristic aspect of all
[15:16] <pitti> ChrisTownsend: for what Michael and Mark have in mind, it's probably better to actually start the deb env as a proper container with all services and its own init, but then provide a mode to just chroot into it if you want to do snappy admin/devel
[15:16] <pitti> that's the model which seems most robust to me and still reasonably fulfill the requirements
[15:16] <ChrisTownsend> pitti: Wouldn't we want to use LXC instead of a chroot?
[15:17] <ChrisTownsend> pitti: The chroot is only intended for kernels that don't support unprivileged LXC's.
[15:17] <pitti> ChrisTownsend: with LXC you can't see/admin the host processes and bits; AFAIK this was the raison d'être for this
[15:17] <pitti> ChrisTownsend: oh, and it's certainly a privileged container
[15:17] <dholbach> fgimenez, I could imagine that the problem has to do with the fact that the examples directory is not mentioned in setup.py anywhere, but I'm not 100% sure yet
[15:18] <tedg> pitti: I was wondering if we could setup snappy-remote to make it so that it would know it is in an embedded situation.
[15:18] <ChrisTownsend> pitti: Hmm, ok.  I really don't have any sense of your requirements, so I may be off base in my replies:)
[15:18] <tedg> pitti: So then you could manage your snappy system, but it'd actually be using REST.
[15:18] <pitti> ChrisTownsend: the idea of that was not to treat some debs as an "app", but to provide a "classic ubuntu" like environment for development and admin'ing snappy
[15:18] <pitti> mvo_: ^ right?
[15:18] <tedg> pitti: I think that sabdfl's concern was being able to manage the core system from the container.
[15:18] <pitti> ChrisTownsend: well, neither have I, I'll mostly come to this as a consultant :)
[15:19] <mvo_> pitti: yes, right, its a full environment to "sh" into
[15:19] <ChrisTownsend> pitti: lol, ok
[15:19] <pitti> tedg: right; so it can't be a container when you get a shell into it
[15:19] <tedg> pitti: It could if the snappy tool used the REST interface transparently.
[15:19] <pitti> tedg: that doesn't preclude actually booting it as a container, so that you have the .deb services running properly
[15:19] <dholbach> fgimenez, or integration-tests/manage.py maybe
[15:19] <mvo_> pitti: and one use case if e.g. install and run tcpdump on snappy
[15:19] <mvo_> pitti: or install strace/gdb etc
[15:19] <pitti> right
[15:20] <tedg> Hmm, strace is trickey
[15:20] <pitti> so for that mode you'd chroot into the root fs; you would see the snappy pids, but can't do /etc/init.d/apache2 restart (you need a "container shell" for that)
[15:20] <tedg> mvo_: So it would have to be completely unconfined
[15:20] <pitti> so it's always a bit weird
[15:20] <pitti> yes, this isn't a security thingy -- you want full access
[15:21] <tedg> mvo_: Is the concern that you'd need gdb/strace for things already installed as snaps, or for building debugging them?
[15:22] <pitti> both I think
[15:22] <ChrisTownsend> I'm thinking the way we make libertine containers may be too confining for this purpose.
[15:23] <pitti> yeah, it's two rather different use cases
[15:23] <ChrisTownsend> We make an unprivileged chroot and only bind mount a few necessary host dirs.
[15:23] <mvo_> tedg: worth clarifying in budapest, but my understanding was that it is intended to troubleshoot a existing system
[15:23] <pitti> ChrisTownsend: libertine basically is a snap for a bunch of debs, treated as an "app", right?
[15:24] <tedg> pitti: Well the idea is that it maintains a container long term, so you end up apt-get'ing more over time.
[15:24] <tedg> pitti: So it's not a one-shot type thing.
[15:24] <pitti> well, I'll take a look at it either way
[15:25] <pitti> I don't feel that this "deb env on snap" thing will be a lot of code, it's just getting the concept right
[15:25] <pitti> thanks for your input! /me needs to leave now
[15:34] <tedg> 'night pitti !
[15:34] <elopio> sergiusens: tedg: could there be a way for a snapcraft.yaml to include another snap?
[15:34] <tedg> Man I hate my wifi
[15:35] <tedg> Oh, oh! An inception2 branch!
[15:35] <sergiusens> elopio, crazy talk
[15:35] <sergiusens> elopio, just use reusable parts ;)
[15:35] <sergiusens> elopio, the snap as a binary or the snap layed out as an overlay?
[15:36] <tedg> I mean we could decompress it and just copy the same files into the new snap.
[15:36] <tedg> The potential use I could see is that someone wants to include a particular version of a framework.
[15:37] <elopio> sergiusens, tedg: I don't know. I'm just thinking. Lets say I want to test hello-world.snap. Maybe I don't want to put the test binaries in the production snap because they import testtools and a lot of other stuff.
[15:37] <elopio> so, maybe I could write a test snap that includes the production snap.
[15:37] <elopio> then I install hello-world-test.snap. And it has both the production and test binaries.
[15:38] <tedg> I was thinking that perhaps we could have a plugin you could add to your snapcraft that would do some testing things. Like run the bins under gdbserver.
[15:38] <tedg> That's kinda how QtCreator does things. It builds a new click that has the gdbserver connection setup.
[15:38] <tedg> Then it connects to that.
[15:39] <elopio> that sounds cool. But not what I'm after here. I want a test that runs the binary and checks the output. And a test that starts the service and makes requests to it.
[15:41] <tedg> Hmm, would you want that to be an external package then?
[15:41] <tedg> foo.snap and foo-tests.snap
[15:42] <elopio> tedg: maybe. For small tests that don't have a lot of dependencies, I can just add a binary foo-test to foo.snap.
[15:43] <elopio> but for complex things, like a full suite on the docker snap. We probably want to import a testing framework, and testing helpers. For that I would like a docker-tests.snap.
[15:43] <tedg> I wonder if we just make it super easy to make that foo-tests.snap and then you don't care how small/big it is.
[15:44] <elopio> but that docker-tests.snap should have access to everything docker.snap has. And we don't have dependencies to say docker-test.snap depends on docker.snap, so I'm thinking we should bundle docker.snap inside docker-tests.snap, somehow.
[15:45] <elopio> tedg: that foo-tests.snap it's super easy to make with snapcraft already, just a python project gives us everything we can possibly need.
[15:45] <elopio> but how to call foo from foo-tests.snap?
[15:46] <tedg> foo-tests.run
[15:46] <tedg> It would have to export its own binary
[15:46] <fgimenez> dholbach, mmm i think it has to do with the examples directory not being available from plainbox's ${PLAINBOX_PROVIDER_DATA}, the symlink at http://bazaar.launchpad.net/~fgimenez/snapcraft/build-examples-test/view/head:/integration-tests/runtests.sh#L40 is not properly created
[15:48] <elopio> tedg: right, how to call foo.run from foo-tests.run if foo.snap is not installed.
[15:48] <elopio> oh wait, I'm sorry. You are working on the release. I forgot I said we will discuss about this next week.
[15:48] <elopio> tedg: sergiusens: I'll add a meeting to the calendar.
[15:48] <tedg> elopio: Wait, why don't you install foo.snap ?
[15:48] <dholbach> fgimenez, my last hypothesis was that the examples directory was missing because it wasn't mentioned in neither setup.py nor integration-tests/manage.py, but that might be my lack of understanding of plainbox
[15:49]  * tedg wants to install all the foo's!
[15:49] <dholbach> I need to go now though, dinner with the whole family
[15:49] <dholbach> have a great weekend everyone!
[15:50] <elopio> tedg: the runner would have to know that if you install foo-test.snap, you also need foo.snap installed. That maybe is not a big deal, but sounds like old world dependencies.
[15:50] <elopio> tedg: and one thing I don't know is if foo-test.snap would be able to access the data files of foo.snap. And would it have permission to call foo.run?
[15:53] <tedg> elopio: It wouldn't by default, but I think that foo-test.snap could be unconfined.
[15:54] <tedg> elopio: We really don't need confinement there.
[15:55] <elopio> tedg: we have used unconfined tests in nice ways on the phone. I like that.
[15:55] <elopio> on the other hand, if you are confined to the same things that your test subject is, that will give you a view closer to the consumer of that subject. And you could push the tests to the store.
[15:57] <tedg> Sure, I guess I feel the most important part is that the foo.snap stays in its natural confinment. Even if we peak in, we want it to run as closely to the real world as possible.
[15:57] <tedg> As soon as we adjust its snap in anyway, we're getting away from that.
[15:59] <elopio> that's true.
[16:00] <elopio> and bundling it into another snap doesn't leave it untouched at all.
[16:00] <sergiusens> elopio, tedg I would make snap testing at this stage more like blackbox testing in any case; check snappy [config|service|...]
[16:02] <elopio> sergiusens: I want this to be blackbox, always. But how would you install those blackbox tests into the snappy board?
[16:04] <elopio> ev: we don't know where the public ssh key is. Can you please give us a hand?
[16:07] <sergiusens> elopio, composing the snap is not a good idea; you will most likely need to change apparmor rules and such
[16:07] <sergiusens> elopio, drive it externally; use ciaas?
[16:07] <elopio> sergiusens: yes, tedg made good points about that. I don't like it now.
[16:08] <elopio> sergiusens: do you mean like we do for snappy? Use something like adt-run that will copy the tests into the testbed?
[16:09] <elopio> or do you mean to write the tests using only snappy-remote and ssh?
[16:09] <tedg> barry: So we want to be able to set "sys.executable" before running setup.py. Is there a good way to do that?
[16:09] <tedg> barry: I was hoping I could use python3 -c, but that doesn't seem to get the order of operations right.
[16:10] <tedg> I probably should use "right" since this is kinda a hack :-)
[16:16] <plars> ogra_: https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2 is still correct on building rpi2 images? the oem and device bits especially?
[16:16] <ogra_> plars, well, ther versions are outdated, but the rest is fine
[16:16] <ogra_> http://people.canonical.com/~platform/snappy/raspberrypi2/ has the bits
[16:17] <plars> ogra_: do you know when those will be in the store?
[16:17] <ogra_> this will stay valid for another week or two until we start building automatically
[16:17] <ogra_> the pi2 snap is in the store already
[16:17] <ogra_> you can use that one as well (but it is the same)
[16:17] <plars> ogra_: so you don't need to download them separately now?
[16:18] <ogra_> the snap
[16:18] <ogra_> you still need the device tarball ... we commited the first bits to system-image today for that bit
[16:18] <plars> ogra_: ah, so that will still be needed for a while I guess? :(
[16:19] <ogra_> well, next stable release will be fully integrated
[16:19] <plars> cool
[16:21] <barry> tedg: sys.executable gets set from argv0.  on linux i don't believe there's an easy way to override that before the runtime starts up (there is on osx)
[16:22] <tedg> barry: Can I do it in some sort of wrapper script?
[16:22] <tedg> barry: I'm looking at the import stuff and it seems to be all for importing modules.
[16:22] <tedg> barry: Where I just want to import a script.
[16:23] <barry> tedg: right, importlib is all about importing modules.  i think you could do it in a wrapper that calls exec with the intended argv0
[16:23] <barry> tedg: but, why do you want to set sys.executable?  usually that just comes from the shebang line or the prompt
[16:24] <tedg> barry: The problem is that setuptools is pulling it when we're building the snap, which then is the path to the build version and we want to to be the path of the installed version when on the final system.
[16:25] <barry> tedg: did you see that setuptools supports --executable (iirc) which lets you set that explicitly?
[16:26] <tedg> barry: In theory, but I couldn't get it to work really. It seems to be building the cmdline tools at install time instead of build time, and the parameter only works on build.
[16:26] <tedg> barry: I don't get anything in usr/bin of the build directory
[16:27] <barry> tedg: ah.  well, that's less than helpful ;)
[16:28]  * barry thinks
[16:29] <tedg> Hmm, doesn't seem subprocess allows setting arg0 to a different value.
[16:29] <barry> tedg: right, i think you need to use os.exec*()
[16:30]  * tedg takes the kid gloves off
[16:31]  * barry digs through setuptools
[16:38] <barry> tedg: http://stackoverflow.com/questions/28575431/setuptools-entry-points-console-scripts-have-specific-python-version-in-shebang
[16:38] <barry> i haven't tried it but that's a new one for me
[16:39] <sergiusens> barry, fwiw, I saw the sys.executable trick in a debian bug
[16:40] <barry> sergiusens: "sys.executable trick"?  means setting that attribute early enough?
[16:41] <sergiusens> barry, yeah, import sys\nimport setuptools\nsys.executable = 'path_to_exec'\nsetup(...)
[16:41] <sergiusens> barry, here it is http://stackoverflow.com/questions/17237878/changing-console-script-entry-point-interpreter-for-packaging
[16:42] <barry> sergiusens: oh that's cute
[16:43] <sergiusens> tedg, btw, seem pyversions -r would solve the python3.4/3.5 issue
[16:43] <barry> py3versions
[16:43] <barry> but that doesn't take a -r
[16:44] <sergiusens> -i I guess then
[16:44] <barry> would you want the default python3 version? or will you allow people to select 3.4/3.5?  (note that wily can have both installed, and 3.4 is going away for X)
[16:44] <tedg> Cool, good. That was next on my list of things to fix.
[16:45] <tedg> barry: If they grab the default python3 plugin we'll grab what ever is default.
[16:45] <barry> tedg: ack
[16:45] <tedg> barry: But we allow people to grab any package they want, so eh, whatevs
[16:47] <tedg> I really don't want to be writing a shell script to call a python script to call python.
[16:47] <barry> tedg: i think writing/amending the setup.py is probably the better way
[16:47] <barry> not great, but better
[16:48] <barry> tedg: this seems like a possible upstream related bug: the
[16:48] <barry> https://bitbucket.org/pypa/setuptools/issues/204/support-for-interpreter-argument-in
[16:48] <tedg> Yeah, that seems related.
[16:49] <tedg> console scripts is slightly out of the fold.
[16:49] <asac> sergiusens: around?
[16:51] <barry> tedg: https://bitbucket.org/pypa/setuptools/issues/272/generated-script-shebang-line
[16:52] <tedg> Cool, thanks barry
[16:54] <barry> tedg: jaraco is a local python dev and we've got a hackathon next week.  i'll ping him personally about it (if i can remember :)
[16:59] <tedg> barry: We should be landing most of the python snapcraft bits today/early next week. It'd be interesting to get some feedback at the hackfest about it.
[16:59] <tedg> barry: Those are the people we want to delight :-)
[17:00] <barry> tedg: awesome!  i'd love to take a closer look.  will you be sending more details to the mailing lists, or is there a wiki i can look at?
[17:00] <tedg> barry: We're working on docs. I think when those get real we'll spam the world.
[17:00] <tedg> barry: As an example you can kinda see things with the examples
[17:00] <barry> tedg: sounds great.  i will help spread the word
[17:01] <tedg> barry: Heh, that was bad English
[17:01] <tedg> barry: We have examples :-)
[17:01] <barry> :)
[17:04] <tedg> barry: I think the other thing that will be interesting for Python folks is that we're going to allow builds in LP, but that can pull deps from non-archive sources. So using pip or whatever.
[17:05] <tedg> That's in progress, but a big change that folks have wanted.
[17:07] <barry> tedg: that's *very* interesting
[17:08] <tedg> Yeah, I'm super excited about it. But really cjwatson did all the work. I'm just being a fan boy.
[17:09] <barry> we're all cjwatson fanboys here :)
[17:09] <fgimenez> nice weekend everyone o/
[17:16] <elopio> sergiusens: do you mean run clean twice in integration tests?
[17:16] <elopio> or in unit tests?
[17:17] <sergiusens> elopio, either or both ;-)
[17:17] <sergiusens> elopio, just add snapcraft clean to the make-clean test
[17:17] <elopio> sergiusens: I don't like this many mocks, so I'll do it in integration.
[17:17] <elopio> sergiusens: yes, on it.
[17:21] <elopio> sergiusens: pushed. Thanks for the suggestion.
[17:24] <elopio> ¿dónde están hablando de eso? No veo ninguna discución en IRC.
[17:24] <elopio> *discusión
[17:25]  * beuno blinks
[17:25] <elopio> wrong channel.
[17:25] <beuno> :)
[17:25] <sergiusens> elopio, who was that for :-P
[17:26] <elopio> sergiusens: balloons. He's learning spanish.
[17:26] <sergiusens> elopio, ah :-)
[17:28] <tedg> We should have a snappy-es channel. I really need an excuse to have better Spanish.
[17:29] <beuno> tedg, I think the plan of record is to slowly just start speaking in spanish and make english look out of place
[17:29] <tedg> beuno: si, me gusta snappy
[17:30] <tedg> Is their something similar to "our Spanish snappy overlords"? ;-)
[17:31] <tedg> Never thought about it, but are their different memes for non-English languages? There must be.
[17:32] <elopio> https://translations.launchpad.net/snappy
[17:32] <elopio> galician is winning
[17:33] <elopio> tedg: this is a good one for you https://s-media-cache-ak0.pinimg.com/736x/1c/ed/4c/1ced4cd96aef0fe01a4a240f9edeb606.jpg
[17:33] <tedg> Heh, I always find most interesting what doesn't get translated. Like "2fa"
[17:35] <tedg> elopio: I'm not sure what that woman has to do with the mob.
[17:35]  * tedg is probably missing some context
[17:35] <sergiusens> tedg, our standups have mostly spanish speaking people in them anyways ;-)
[17:36] <sergiusens> we can switch from german to spanish every other day
[17:36] <tedg> Ha, that won't be confusing.
[17:37] <tedg> If there's one thing I can say, it is that my Spanish is better than my German.
[17:37] <elopio> tedg: "that woman" https://en.wikipedia.org/wiki/List_of_El_Chavo_characters#Do.C3.B1a_Florinda
[17:40] <tedg> Interesting, I had no idea.
[17:43] <ev> elopio: the system public ssh key? You'll want to file an RT to get that
[17:43] <elopio> ev: yes, look at the rt CCed to you. They don't know where it is either.
[17:44] <ev> ha, having a look
[17:53] <elopio> sergiusens: is this python config part going to be in the wiki?
[17:55] <sergiusens> elopio, if it can, yes
[18:01] <elopio> sergiusens: tedg: am I doing something stupid here? http://paste.ubuntu.com/12451892/
[18:02] <elopio> I'm getting FileNotFoundError: [Errno 2] No such file or directory: '/tmp/socat/snap/./bin/snapd-socat.wrappe│
[18:02] <elopio> r'
[18:12] <elopio> got it, I was missing my binary in the snap:
[18:15] <elopio> now, what kind of apparmor should I put in this to work?
[18:30] <sergiusens> elopio, that is an iteration ;-)
[18:31] <sergiusens> tedg, you don't need the filename stuff for python2/3 plugins themselves?
[18:34] <sergiusens> elopio, do you mind rechecking this one https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798 ?
[18:50] <elopio> sergiusens: that one is not ready.
[19:05] <tedg> sergiusens: ?
[19:07] <sergiusens> tedg, I saw your MP; is it possible for pip installed things to provide scripts and us not taking care of that?
[19:08] <tedg> sergiusens: They won't be binaries, right?
[19:08] <tedg> sergiusens: It's only the first binary executed that needs it.
[19:09] <sergiusens> tedg, ah, I can have my snapcraft.yaml be an integrator one that just has a requirements.txt and it installs a binary and and and
[19:10] <sergiusens> tedg, it is a harder problem to solve though
[19:10] <tedg> sergiusens: But then you don't have setup.py redoing the shebang
[19:10] <sergiusens> well, at least not with this mechanism
[19:10] <sergiusens> tedg, so when using pip the shebang thing is clean?
[19:12] <tedg> sergiusens: Seems to be
[19:13] <sergiusens> tedg, ok then; finally some good news :-)
[19:13] <sergiusens> with python
[19:13] <sergiusens> ;-)
[19:13] <tedg> At least for the ones in nova, it seems most of the modules just don't have a shebang.
[19:14] <sergiusens> btw, if you want to look https://code.launchpad.net/~sergiusens/snapcraft/organize/+merge/271702
[19:14] <sergiusens> elopio, maybe too ^
[19:15] <tedg> K, should it delete the copy plugin?
[19:17] <sergiusens> tedg, not sure we want to yet, do we?
[19:18] <sergiusens> tedg, if we remove the copy plugin we need to drive everything through a makefile
[19:18] <sergiusens> tedg, or of what type would the project be?
[19:18] <tedg> Hmm, yeah... not sure.
[19:19] <sergiusens> this was the question that I accidentally skipped from my notes earlier today
[19:19] <tedg> Was thinking the non-specified type, but we kinda play tricks with that right now.
[19:19] <sergiusens> tedg, yeah, no type means something different now
[19:19] <sergiusens> tedg, we can have the 'nothing' type ;-)
[19:19] <tedg> 'notnull'
[19:20] <sergiusens> hmm, 'nop'
[19:20] <sergiusens> :-)
[19:20]  * tedg gets with the program 'nada'
[19:21] <sergiusens> nada is good :-)
[19:23] <sergiusens> tedg, hmm, moot to remove the copy plugin though; as we move, not copy


[00:01] <prawnsalad20> kaniini has invited you to join #litepub
[00:01] <irv24> kaniini has invited you to join #litepub
[02:02] <Texou1> kaniini has invited you to join #litepub
[02:40] <nyuszika7h2> kaniini has invited you to join #litepub
[02:41] <SailorHaumea13> kaniini has invited you to join #litepub
[03:03] <jeggott9> kaniini has invited you to join #litepub
[03:04] <JonathanD> kaniini has invited you to join #litepub
[04:18] <Cisien3> kaniini has invited you to join #litepub
[04:44] <bitch10> watch the live defcon show https://www.youtube.com/watch?v=y-NgAB1RcPo
[04:44] <ubrl> bitch10: ⇪ L0DE RADIO HOUR - LIVE FROM DEATHCON - Live IRC call in show! - YouTube
[07:06] <Razesdark> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[07:06] <Razesdark> "All told, Handshake aims to give $250 worth of its tokens to *each* user of the websites the company has partnerships with – GitHub, the P2P Foundation and *FREENODE*, a chat channel for peer-to-peer projects. As such, developers who have existing accounts on each could receive up to $750 worth of Handshake tokens."
[07:06] <ubrl> Razesdark: ⇪ Handshake Revealed: VCs Back Plan to Give Away $100 Million in Crypto - CoinDesk
[07:32] <bast-anon> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[14:13] <berndj8> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[14:32] <Guest69370> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[14:42] <Liara-> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[15:38] <lkoranda17> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[16:10] <nug700> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[16:10] <nug700> "All told, Handshake aims to give $250 worth of its tokens to *each* user of the websites the company has partnerships with – GitHub, the P2P Foundation and *FREENODE*, a chat channel for peer-to-peer projects. As such, developers who have existing accounts on each could receive up to $750 worth of Handshake tokens."
[18:18] <__idiot__> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[18:33] <shentino> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[18:44] <jesse2> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/
[20:07] <profall19> After the acquisition by Private Internet Access, Freenode is now being used to push ICO scams https://www.coindesk.com/handshake-revealed-vcs-back-plan-to-give-away-100-million-in-crypto/


[12:47] <AlanBell> I tested the install quickly yesterday and it does let me run orca and proceed through with the keyboard without crashing
[23:28] <Fudge> yay


[13:27] <ZachGibbens> I saw a post on the new Ubuntu LTS release
[13:28] <ZachGibbens> Hard to be excited about it after switching over to rolling releases
[16:17] <JackFrost> Did the post mention anything interesting?


[04:21] <Lure> @schedule ljubljana
[04:21] <ubotu> Schedule for Europe/Ljubljana: 05 Apr 18:00: Ubuntu Development Team | 10 Apr 22:00: Technical Board | 11 Apr 22:00: Edubuntu | 12 Apr 22:00: MOTU | 12 Apr 23:00: Ubuntu Development Team | 13 Apr 22:00: Forum Council
[04:24] <zul> @schedule montreal
[04:24] <ubotu> Schedule for America/Montreal: 05 Apr 12:00: Ubuntu Development Team | 10 Apr 16:00: Technical Board | 11 Apr 16:00: Edubuntu | 12 Apr 16:00: MOTU | 12 Apr 17:00: Ubuntu Development Team | 13 Apr 16:00: Forum Council
[04:49] <mdz> good afternoon
[04:50] <kwwii> hi mdz
[04:52] <mdz> cjwatson: here?
[04:52] <cjwatson> yes
[04:52] <dholbach> hiya
[04:54] <pitti> hi
[04:56] <Riddell> hi
[04:58] <mdz> 2 minutes, everyone here?
[05:01] <bdmurray> howdy
[05:02] <mdz> cjwatson,Keybuk: everyone accounted for?
[05:02] <cjwatson> I think I have the list of people on holiday complete
[05:02] <mdz> thanks Riddell
[05:02] <Keybuk> mdz: accounting now
[05:02] <cjwatson> waiting for rtg
[05:02] <cjwatson> (already pinged)
[05:03] <Keybuk> mdz: not expecting iwj, he's off sick
[05:03] <cjwatson> asac: here?
[05:03] <asac> yes
[05:04] <cjwatson> ok, I was just about to say that this was one of your usual unavailable times, so you might not be :)
[05:04] <cjwatson> ok, everyone accounted for for me
[05:04] <mdz> Keybuk: likewise?
[05:05] <asac> cjwatson: i would apologize in that case ... was just confused because of @schedule :)
[05:05] <Keybuk> mdz: yup
[05:05] <mdz> ok, good, let's get started
[05:05] <mdz> some of you may have heard that we're releasing in two weeks :-)
[05:06] <cjwatson> EASY
[05:06] <mdz> Mithrandir's last email said we had 140 release-critical issues
[05:06] <pitti> and we don't even know the name of feisty+1 yet :(
[05:06] <mdz> but that was a week ago
[05:06] <mdz> pitti: I sit next to Mark now and will ask every day until that changes :-)
[05:06] <Keybuk> pitti: we're trying our hardest
[05:06] <mdz> won't be long now
[05:06] <cjwatson> I haven't done a bug count today yet
[05:06] <mdz> strike that, it said "about 140"
[05:07] <cjwatson> (give me two minutes)
[05:07] <mvo> I think we have ~90 milestoned currently
[05:07] <pitti> 113
[05:07] <seb128> what do you count release-critical?
[05:07] <seb128> anything using a 7.04 milestone?
[05:07] <Mithrandir> milestoned and in main+restricted
[05:07] <mdz> I count 131
[05:07] <seb128> I tend to use milestone with low importance for things I want to work on, that doesn't mean they are r-c
[05:07] <mdz> oh, I counted universe+multiverse
[05:08] <cjwatson> 131> ditto
[05:08] <pitti> weird, I see 113 milestone bugs; anyway, lots
[05:08] <mdz> this being our sixth release, it's about time we had an agreement about how release-critical issues are recorded
[05:08] <Mithrandir> so 109 now.
[05:08] <cjwatson> seb128: regardless, they all need to be unmilestoned or fixed before release
[05:08] <heno> note that some of these may be dupes of already fixed bugs such as bug 89070
[05:08] <ubotu> Malone bug 89070 in casper "Can't eject cdrom (dup-of: 84592)" [Medium,Unconfirmed]  https://launchpad.net/bugs/89070
[05:09] <ubotu> Malone bug 84592 in casper "feisty shutdown eject doesn't" [Undecided,Fix released]  https://launchpad.net/bugs/84592
[05:09] <mdz> I think it makes most sense to reserve the ubuntu-7.04 milestone for truly critical issues
[05:09] <heno> I plan to look for more such cases
[05:09] <cjwatson> 131> that figure counts duplicates and bugs with multiple tasks
[05:09] <seb128> cjwatson: right, I already dropped some of the list but I still have a bunch of bugs I want to work on and that's the best way I've found to keep track of them
[05:09] <mdz> we can create a second milestone for things which we want to remember to look at, if that's needed
[05:09] <pitti> that should be 'in progress' state
[05:09] <Mithrandir> mdz: we have one (which is *cough*, part of edgy), later.
[05:09] <mdz> we're unlikely to fix all 109 of those bugs during freeze
[05:10] <pitti> seb128: why not assign to you/set in progress? that works very well for me and is more natural to the LP workflow
[05:10] <Mithrandir> heno: 89070 isn't on the list of RC bugs.
[05:10] <mdz> mvo: do you still have 25 targeted bugs?
[05:10] <seb128> well, I though r-c was > importance bugs
[05:10] <heno> Mithrandir: sorry
[05:10] <seb128> pitti: because I list them for desktop team and I'm not working on them, dholbach work on some also, etc
[05:10] <mvo> mdz: no, my count should be much less, around 5
[05:10] <Mithrandir> heno: don't use +milestone/ubuntu-7.04, use https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=Unconfirmed&field.status%3Alist=Needs+Info&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.milestone%3Alist=200&field.component=1&field.component=2&field.component-empty-marke
[05:11] <mdz> mvo: you have many marked fix committed
[05:11] <mdz> mvo: did you forget to change them to fix released?
[05:11] <seb128> pitti: that's a "would be nice to fix those desktop bugs" list and anybody is welcome to give a hand ;)
[05:11] <mvo> mdz: most likely I will go over them
[05:11] <mdz> Mithrandir: is there a link to that from UbuntuDevelopment?
[05:11] <mdz> mvo: we're very close
[05:11] <mdz> I spoke with kiko about it on Monday
[05:11] <Mithrandir> mdz: I don't think so, no.  I can put it on my list of things to do next week.
[05:12] <mdz> it is reportedly BjornT's next focus
[05:12] <mvo> mdz: cool! sorry, but my milestone search exclude fix-commited so I haven't noticed
[05:12] <mdz> and kiko has given him some code for the soyuz bit
[05:12] <mdz> Mithrandir: please do; that's a list all developers should be able to find easily
[05:12] <mdz> Keybuk: do you know what's happening with this critical evms bug?
[05:12] <Keybuk> mdz: there's a new one?
[05:13] <Keybuk> what #?
[05:13] <mdz> Keybuk: the one at the top of Mithrandir's url
[05:13] <mdz> bug 74317
[05:13] <ubotu> Malone bug 74317 in evms "race with devmapper" [Critical,Unconfirmed]  https://launchpad.net/bugs/74317
[05:13] <Keybuk> mdz: that's the first time I've seen that one
[05:13] <cjwatson> bug 63175 and bug 89069 are likely the same thing, but it's difficult
[05:13] <ubotu> Malone bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Needs info]  https://launchpad.net/bugs/63175
[05:13] <ubotu> Malone bug 89069 in ubiquity "problem with time" [Medium,Unconfirmed]  https://launchpad.net/bugs/89069
[05:14] <Keybuk> and it is likely that wasabi is correct in the fix
[05:15] <mdz> cjwatson: it's not clear to me why that would change since warty
[05:15] <mdz> Keybuk: can you chase it up and fix it in ian's absence if necessary?
[05:16] <cjwatson> it doesn't surprise me that it changed around dapper/edgy due to certain internal installer changes
[05:16] <Keybuk> mdz: yup
[05:16] <mdz> mvo: bug 99171 is not a real bug, but it does need to get done
[05:16] <ubotu> Malone bug 99171 in update-manager "Reminder: disable "useDevelopmentRelease=True" before final release in CD self upgrader" [Critical,Confirmed]  https://launchpad.net/bugs/99171
[05:16] <mdz> mvo,Mithrandir: when is the right time to throw that switch?
[05:16] <mvo> mdz: after RC
[05:16] <mdz> mvo: surely before RC, no?
[05:17] <pitti> mvo: why would it hurt to do it earlier?
[05:17] <pitti> mvo: after all, there's no feisty+1 yet to upgrade to
[05:17] <mdz> (unfortunately)
[05:18] <mvo> after the last image that we consider "not-yet-released"
[05:18] <mvo> otherwise people will not get a updated dist-upgrader (if we issue one)
[05:18] <mvo> but we need to turn it off before final release
[05:18] <mdz> RC should have all of the trimmings for final; that's the point
[05:19] <mdz> version numbers and all
[05:19] <Mithrandir> mvo: you mean people who run the dist-upgrader from RC to final won't get the updated one?
[05:19] <mvo> Mithrandir: if we have a updated one on the net, then no. if we don't it does not matter
[05:19] <mdz> upgrading to RC should give the same experience as upgrading to final, so we can test the final process
[05:20] <Mithrandir> I agree with mdz, while we're updating langpacks after RC, I'd like to avoid changing code at all possible after RC is out.
[05:20] <Mithrandir> that's kinda the point of RC.
[05:20] <Riddell> cjwatson: the release notes URL link should be turned on in ubiquity?
[05:20] <cjwatson> Riddell: it already is
[05:20] <mvo> fair enough, then we need to turn it off before the weekend
[05:20] <mdz> mvo: would this be a good item to add to the checklists?
[05:21] <mdz> rather than filing a bug
[05:21] <cjwatson> Riddell: oh, argh, maybe it isn't, I'll check
[05:21] <mvo> mdz: good point! I used a bug because I wanted to be 100% certain that I don't forget it
[05:21] <Riddell> cjwatson: it's a file that needs putting on the CD as I remember, maybe Mithrandir knows
[05:21] <cjwatson> Riddell: no, it's my problem
[05:22] <cjwatson> it's supposed to have been on the CD for ages but apparently fell off due to a slight code bug
[05:22] <Riddell> cjwatson: where does it point to (for Kubuntu)?
[05:22] <cjwatson> -> #ubuntu-devel
[05:22] <Riddell> yep
[05:23] <mdz> mvo: thanks
[05:23] <mdz> cjwatson: is that on the checklist as well?
[05:24] <mdz> Mithrandir: have you given up on bug 45696?
[05:24] <ubotu> Malone bug 45696 in network-manager "NetworkManager can't find interface on resume from suspend" [High,Confirmed]  https://launchpad.net/bugs/45696
[05:24] <cjwatson> mdz: it's supposed to be on the CD throughout release, so no. it's just a bug.
[05:24] <mdz> Mithrandir: bug 58503 has a safe+sane-looking fix
[05:24] <ubotu> Malone bug 58503 in usplash "No response to keyboard input at prompt after ejecting CD-ROM" [High,Confirmed]  https://launchpad.net/bugs/58503
[05:25] <cjwatson> mdz: (updating the mapping table is on the checklist, but that's not what Riddell's talking about)
[05:25] <Mithrandir> mdz: 45696 has gone away by itself for me, I used to see it all the time, but no longer.
[05:26] <mdz> Keybuk: thoughts on bug 66637?
[05:26] <ubotu> Malone bug 66637 in util-linux "After running mkswap, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  https://launchpad.net/bugs/66637
[05:26] <mdz> Mithrandir: it just happened to me today
[05:26] <mdz> so it's still around
[05:26] <mvo> Mithrandir: I have it here too
[05:26] <mdz> mvo: do you get the connection limit message?
[05:26] <Keybuk> mdz: isn't that the old "mkswap discards the previous UUID" bug?
[05:26] <mdz> Keybuk: yes
[05:26] <bdmurray> I've seen that some recently too
[05:26] <Keybuk> mdz: I had a mostly finished patch for that
[05:26] <mdz> Keybuk: with 13 duplicates
[05:26] <mvo> mdz: I haven't checked
[05:27] <Keybuk> except we had new information that sometimes fsck changes the UUID too, so I was investigating that
[05:27] <Keybuk> but got side-tracked by the evms/md/lvm/devmapper stuff
[05:27] <Keybuk> it's next on my list to fix
[05:27] <mdz> ok
[05:27] <Mithrandir> mdz: 58503, I haven't looked at that lately, I've spent time on trying to fix NM to work beter.
[05:27] <Mithrandir> better, even.
[05:27] <mdz> BenC: how about the kernel bugs on that list?
[05:28] <mdz> Mithrandir: I have never seen that one, but it's fairly serious for folks who do (and can't be fixed in an update)
[05:28] <BenC> mdz: We're reviewing things
[05:29] <BenC> checking to see what we want to target for RC and release
[05:29] <mdz> cjwatson: bug 85612 -> agreed
[05:29] <ubotu> Malone bug 85612 in kde-systemsettings "Edgy/Kubuntu update broke access to display settings on 4 separate systems (dup-of: 38692)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/85612
[05:29] <ubotu> Malone bug 38692 in kde-systemsettings "systemsettings doesn't load Display, Disk and Filesystems control module" [High,Confirmed]  https://launchpad.net/bugs/38692
[05:29] <mdz> er
[05:29] <Keybuk> mdz: that fix is inspired
[05:29] <mdz> bug 85162, that is
[05:29] <ubotu> Malone bug 85162 in localechooser "installer doesn't permit to set little countries" [High,Confirmed]  https://launchpad.net/bugs/85162
[05:29] <Keybuk> and really would explain why it doesn't work
[05:29] <cjwatson> yeah, too risky
[05:29] <BenC> mdz: At this point, I don't thing any of our bugs are real showstoppers, but we have some that would be worth fixing for release
[05:29] <mdz> Keybuk: which?
[05:30] <Keybuk> mdz: 58503 ... if the keyboard is in the wrong mode, that'd explain why previous attempts to debug have failed
[05:30] <mdz> BenC: worth fixing why?
[05:30] <Keybuk> we were assuming the keyboard was attached to the wrong VT/etc.
[05:30] <mdz> BenC: if they can be fixed via updates instead, it's time to start thinking about that
[05:30] <mdz> Keybuk: ah, right
[05:31] <mdz> seb128: what about the panel crash with 8972342 duplicates?
[05:31] <pitti> BenC: I think the nvidia vs. legacy one will hurt upgraders badly
[05:31] <BenC> mdz: The only patches I'm considering at this point have to be non-ABI changes, and pretty trivial (meaning we can review it and see that it will fix things, without a lot of testing)
[05:31] <seb128> mdz: I've just uploaded another gtk+2.0 fix 30 seconds ago, might fix it
[05:31] <heno> Mithrandir: can we fix bug 91868 ? it should be a trivial casper script change
[05:31] <doko> we're down to 98 RC reports, lets continue 4hours, and we're done =)
[05:31] <ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Medium,Confirmed]  https://launchpad.net/bugs/91868
[05:31] <BenC> pitti: That's still in progress, and I will have it before RC
[05:31] <seb128> mdz: another invalid read to icon code I've caught with valgrind
[05:31] <pitti> BenC: cool
[05:32] <Mithrandir> heno: yes.
[05:32] <mvo> BenC: rock!
[05:32] <heno> cool
[05:32] <mdz> kylem: bug 88219?
[05:32] <ubotu> Malone bug 88219 in lilo "lilo won't add the new kernel 2.6.20" [High,Fix committed]  https://launchpad.net/bugs/88219
[05:32] <mdz> seb128: so there's a fix on the way?
[05:32] <seb128> mdz: not easy to debug, we get ziliion of dups but nobody able to get a valgrind log of it crashing
[05:32] <mdz> seb128: oh, I thought you meant you had caught a log of it
[05:32] <seb128> mdz: I'm not sure that's "the fix", it stopped the incorrect read to icon code I was getting
[05:33] <seb128> mdz: right, not sure that's the only bug though
[05:33] <seb128> though I'm confident this one is good
[05:33] <mdz> asac: bug 89071 doesn't sound release-critical
[05:33] <ubotu> Malone bug 89071 in firefox "Can't allow sites for adding extensions" [High,Confirmed]  https://launchpad.net/bugs/89071
[05:33] <seb128> I'm running gnome-panel under valgrind for some hours and I've get no error on package installations, upgrades, etc
[05:33] <asac> mdz: yes we can untarget that
[05:34] <kylem> mdz, i'll have to look at it again. i thought i fixe dit.
[05:34] <mvo> seb128: have you tried theme changes as well?
[05:34] <asac> mdz: done
[05:34] <mvo> seb128: I got some crashes in synaptic from people changing themes during downloads
[05:34] <seb128> mvo: it's not happening on theme change, it's happening on upgrades
[05:34] <mvo> seb128: ok
[05:34] <seb128> mvo: might be a different one :/
[05:34] <mvo> seb128: yeah :/ joy!
[05:35] <mdz> mvo: do you have any fix committed bugs which *shouldn't* be fix released? (any pending uploads?)
[05:36] <mvo> mdz: I don't think so, I was careful to make sure that everything went in before the freeze today, but I will double check
[05:36] <tkamppeter> seb128, your non-optimized version for bug 91218 seems still not be a good workaround.
[05:36] <ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]  https://launchpad.net/bugs/91218
[05:36] <mdz> Keybuk: bug 96777?
[05:36] <ubotu> Malone bug 96777 in upstart "ttyS0 not migrated properly on upgrades from edgy to feisty" [High,Confirmed]  https://launchpad.net/bugs/96777
[05:36] <mvo> mdz: some of the obvious ones I closed already
[05:36] <tkamppeter> someone has installed your package and got the same crash.
[05:36] <mdz> mvo: there are a bunch on the list; I'll reload
[05:37] <mdz> mvo: the update-manager bugs are really cluttering the list
[05:37] <Keybuk> mdz: err, I thought I uploaded that before I came here
[05:37] <seb128> tkamppeter: the change to build with -O0 on amd64 didn't work apparently, I'll have an another look
[05:37] <Keybuk> mdz: but I don't see it in the archive -- will look when I get home :)
[05:37] <mdz> Keybuk: last upstart was 11 mar
[05:37] <Keybuk> yeah, weird, there's a newer one
[05:38] <Keybuk> 0.3.8-2
[05:38] <Keybuk> but LP knows nothing
[05:38] <mdz> Mithrandir: re: bug 102105, LSB 3.1 was not a release goal
[05:38] <ubotu> Malone bug 102105 in lsb "Issues of Ubuntu's LSB compliance - Login shell startup" [High,Unconfirmed]  https://launchpad.net/bugs/102105
[05:39] <mdz> Mithrandir: have you been in contact with mdke regarding bug 103308?
[05:39] <Mithrandir> mdz: iirc, tkamppeter milestoned it.  And I think LSB is on crack there, since they can't mandate changes to what POSIX sh should support.
[05:39] <ubotu> Malone bug 103308 in ubuntu-docs "newtoubuntu documents has link to English version of user-guide rather than localised version" [High,Confirmed]  https://launchpad.net/bugs/103308
[05:39] <mdz> Mithrandir: oh, it was only reported 2 hours ago. urgh
[05:40] <Mithrandir> mdz: so, no, I haven't.  I'm on vacation. :-P
[05:40] <mdz> seems worthy of a freeze exception if the fix is simple
[05:40] <doko> mdz: the wording is "shall" in both cases
[05:40] <Keybuk> doko: what does that mean for LSB?
[05:40] <tkamppeter> Mithrandir, so POSIX does not require -l and /etc/profile.d for sh?
[05:40] <Keybuk> shall implies required?
[05:40] <Keybuk> tkamppeter: right
[05:41] <mdz> doko: in 3.0 as well, you mean?
[05:41] <mdz> we passed the 3.0 validation tests at some point
[05:41] <doko> looking ...
[05:41] <tkamppeter> If "shall" would not require anything, why are such terms in the LSB?
[05:41] <cjwatson> http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html <- POSIX sh
[05:41] <Mithrandir> and while I think that LSB support would be nice, LSB should not try to change behaviour of /bin/sh and similar interfaces.
[05:42] <mdz> doko: what were the two cases?
[05:42] <Mithrandir> and profile.d has been rejected from Debian policy multiple times.
[05:42] <mdz> that's all of the interesting high-priority milestoned bugs, at a glance
[05:42] <cjwatson> sounds like they got it into LSB by the back door
[05:43] <doko> mdz: "The shell shall support an additional option -l" and "The sh utility shall read and execute commands ..."
[05:43] <cjwatson> I think the swap formatting control thing in ubiquity should be done if at all possible
[05:43] <Keybuk> doko: so they're both required by the LSB?
[05:43] <cjwatson> just haven't quite had time yet
[05:43] <Keybuk> (note we're nowhere near LSB compliance according to the letter of the spec, so I don't think more non-compliance matters)
[05:43] <cjwatson> I'm doing bug 91868
[05:43] <ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Medium,Fix committed]  https://launchpad.net/bugs/91868
[05:43] <heno> cjwatson: thanks
[05:44] <cjwatson> ok, pending agenda items?
[05:44] <cjwatson> there are only a couple
[05:44] <cjwatson> (ogra) Edubuntu is RC blocked on bug #100021 (or on removing NM from the Edubuntu seeds) at the moment.
[05:44] <ubotu> Malone bug 100021 in ltsp "[Feisty]  LTSP fails on multi-homed server due to network manager touching predefined static interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/100021
[05:44] <Mithrandir> it doesn't seem like "shall" is defined in the LSB spec.
[05:44] <cjwatson> can somebody who knows n-m give advice or fixes as necessary?
[05:44] <mdz> ogra: how is it that this was only discovered 2 weeks before release?
[05:45] <Mithrandir> but they use shall and must.
[05:45] <Keybuk> Mithrandir: those are both "required" things, Englishishwise
[05:45] <tkamppeter> Mithrandir, then the LSB spec is broken.
[05:45] <Keybuk> "should" is normally used in specs to mean "recommended"
[05:45] <Keybuk> and "may" for optional
[05:46] <pitti> ogra: not sure whether this is fixable ATM; n-m's very concept is 'one active device at a time' :(
[05:46] <doko> Keybuk: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/def.html so yes, it's must.
[05:46] <doko> mdz: 3.0 has the same wording
[05:47] <tkamppeter> Keybuk, if they are required, this bug needs to get fixed.
[05:47] <Keybuk> tkamppeter: *shrug* if it isn't part of their test suite, it's not that important
[05:47] <mdz> pitti: network-manager may not be appropriate for servers with multiple network interfaces
[05:47] <Keybuk> I'd argue that they're trying to change POSIX-defined interfaces there, so the LSB needs to be fixed
[05:47] <mdz> this is an odd situation because desktop packages get installed on edubuntu servers
[05:47] <pitti> mdz: right, neither for desktop machines with the same situation (mine, for example)
[05:48] <Mithrandir> pitti: I am adding a concept of "manual" devices devices to NM which it knows about and assumes that are always online (but doesn't touch)
[05:48] <mdz> pitti: on desktops, it's usually the right thing, and folks who are doing something funny can remove it :-)
[05:48] <pitti> mdz: right, I wasn't complaining
[05:48] <Mithrandir> so if you have interfaces which are on some kind of manual, NM won't touch them.
[05:48] <pitti> mdz: well, I'd correct it to 'on laptops it's the right thing', but anyway
[05:48] <mdz> but in this case, we know that it's not the right thing because we're installing a server
[05:48] <mdz> ogra: are you here?
[05:49] <tkamppeter> Keybuk, I think following the LSB wording and not only the test suite is important, as people who make distribution-independent packages, read the specs and do not analyse the source of the test suite.
[05:49] <pitti> but at this time I guess it's too late to install it on laptops only
[05:49] <mdz> it doesn't seem that ogra is here, so I suppose we'll move on
[05:49] <mdz> (pitti) Confirm decision about apport in final release.
[05:49] <cjwatson> tkamppeter: I think it's a bug, but not a release-critical one
[05:49] <Keybuk> tkamppeter: *shrug* nobody produces distribution-independent packages and nobody like that cares about the LSB
[05:49] <Keybuk> tkamppeter: for the first point, the LSB mandates RPM not DEB :p
[05:49] <mdz> pitti: the consensus seemed clear on the mailing list; what's the question?
[05:49] <cjwatson> Keybuk: (tkamppeter does, for printing)
[05:49] <pitti> mdz: right, just getting a bunch of 'ok' from folks like bdmurray who didn't report back on the ML
[05:50] <tkamppeter> Yes, that is true, cjwatson, perhaps I am the first user of the LSB?
[05:50] <mdz> pitti: you have the floor :-)
[05:50] <asac> pitti: you have my ok :)
[05:50] <pitti> bdmurray: are you fine with disabling crash reports by default, only keep it on the live CD?
[05:50] <pitti> and asac?
[05:51] <bdmurray> pitti: yes
[05:51] <pitti> ah, asac beat me to it
[05:51] <pitti> great, I'm done then, thanks
[05:51] <mdz> tkamppeter: you may be the first to rely on this feature and notice it...I assume you know the right people to talk to at FSG about this issue :-)
[05:51] <mdz> ok, that's the end of the agenda
[05:51] <mdz> friday and monday are holidays in the UK, so some of us may not be online much
[05:51] <doko> what about demoting libstdc++5 and ia32-libs?
[05:52] <Mithrandir> doko: please. :-)
[05:52] <mdz> Mithrandir: when are you back at work?
[05:52] <tkamppeter> Yes, I have already reported on the lsb-discuss mailing list of the Linux Foundation that there are these issues with sh.
[05:52] <pitti> demoting++
[05:52] <doko> ok, doing that
[05:52] <Riddell> any progress on having more people to admin NEW queue?
[05:52] <pitti> doko: i. e. you'll unseed this?
[05:52] <doko> pitti: yes
[05:52] <Mithrandir> mdz: Tuesday, but I'll look at IRC for freeze exceptions, etc at least daily.
[05:52] <pitti> doko: great, ping me, I'll care for the demotion
[05:52] <asac> doko: there are some that use upstream firefox ... though i don't care maybe they want it.
[05:52] <mdz> Mithrandir: who is your backup while you are away?
[05:53] <doko> asac: it's still available in universe
[05:53] <pitti> asac: they have to manually install it anyway
[05:53] <Mithrandir> mdz: AIUI, most of the distro team is away for Easter already, so nobody with the access rights is around.
[05:53] <pitti> asac: it would make a difference if we shipped it in -desktop, or on the CDs, but we don't
[05:54] <cjwatson> Riddell: there were four items in NEW last I looked
[05:54] <cjwatson> I'm not concerned
[05:54] <asac> doko: pitti fine
[05:54] <cjwatson> (I realise three of them are yours)
[05:54] <mdz> Mithrandir: that's going to put us in a bit of a crunch for RC, I think
[05:54] <pitti> yes, I spent a fair amount of time on source new last week
[05:54] <cjwatson> I am available although not on a much more regular basis than Mithrandir
[05:55] <mdz> RS/ES/LT/England/AU/DK/NO are mentioned as having holidays
[05:55] <Mithrandir> hm, not .de?
[05:55] <kwwii> and DE
[05:55] <seb128> I'll be around and reading mail every now and then if anything is required
[05:55] <mdz> kwwii,Mithrandir: not on the wiki
[05:55] <pitti> see the copious warthogs mails
[05:55] <seb128> FR as well
[05:55] <mdz> but it seems so, yes
[05:55] <doko> I'll be skiing, so not reading email
[05:55] <Mithrandir> seb128: you don't have access to lithium, do you?
[05:56] <seb128> Mithrandir: not that I know, no
[05:56] <seb128> Mithrandir: nop
[05:56] <mdz> Mithrandir: given that we still have bugs to fix, and that most folks won't be working until Tuesday, it seems unlikely that we'll be able to start building candidates on schedule, don't you think?
[05:56] <doko> Mithrandir: can I remove the milestone from bug 88486 ?
[05:56] <ubotu> Malone bug 88486 in openoffice.org "impress hangs when opening Canonical template presentation [regression from edgy] " [Undecided,Needs info]  https://launchpad.net/bugs/88486
[05:56] <Mithrandir> doko: yes, I think that makes sense.
[05:57] <cjwatson> (rtg had to go due to battery)
[05:57] <Mithrandir> mdz: I'd like to see if we can compress it and evaluate on Tuesday afternoon or Wednesday whether we need to postpone it one day.
[05:58] <mdz> it sounds like there is a day's worth of bugs to fix, so wednesday would be the earliest to start
[05:58] <mdz> whereas the schedule calls for it to start Monday
[05:58] <seb128> mdz: GNOME 2.18.1 tarball will be rolled on monday and tuesday ...
[05:59] <seb128> tarballs
[05:59] <mdz> seb128: that's not ideal either
[05:59] <seb128> well, nothing we can change there
[06:00] <mdz> seb128: we could do them as -updates or selectively
[06:00] <seb128> mdz: I think that would be a mistake
[06:00] <seb128> we would drop one month of bug fix
[06:00] <mdz> seb128: we could delay the release
[06:01] <seb128> hum?
[06:01] <ogra> @schedule
[06:01] <ubotu> Schedule for Etc/UTC: Current meeting: Ubuntu Development Team | 10 Apr 20:00: Technical Board | 11 Apr 20:00: Edubuntu | 12 Apr 20:00: MOTU | 12 Apr 21:00: Ubuntu Development Team | 13 Apr 20:00: Forum Council
[06:01] <cjwatson> mdz: ... you mean the release candidate?
[06:01] <seb128> mdz: there is 10 days between GNOME 2.18.1 and 7.04, you think that's not enough?
[06:02] <mdz> seb128: I count 9, and about 3 days of that are supposed to be RC testing :-)
[06:02] <cjwatson> can anyone reproduce bug 96958?
[06:02] <ubotu> Malone bug 96958 in ubiquity "[feisty]  Kubuntu timezone page broken" [Undecided,Needs info]  https://launchpad.net/bugs/96958
[06:02] <pitti> seb128: will there be any intrusive soname bumps and the like, anything that could screw and delay buildds/archive consistency?
[06:02] <mdz> cjwatson: I meant the release, but only half seriously
[06:02] <Riddell> cjwatson: I've only heard of it from heno on virtual box as I say
[06:02] <seb128> pitti: no, GNOME 2.18.1 is only bug fix, stable branch has still UI, string, API, ABI, etc freezes
[06:03] <mdz> seb128: I think we should try to avoid this conflict for feisty+1, it puts unnecessary pressure on you for packaging, and on all of us for CD testing
[06:03] <ogra> err, did you guys reschedule the meeting ? its supposed to start now, no ?
[06:03] <Mithrandir> mdz: I'm fine with delaying the RC, but not release, I believe we can get a good release out
[06:03] <asac> ogra: schedule is wrong ... i almost fell for it as well.
[06:03] <seb128> ogra: 15UTC was 1 hour ago
[06:04] <heno> Riddell, cjwatson: virtual box is still a bit raw on graphics. Most likely the problem
[06:04] <Riddell> ogra: like last week it was rescheduled by an hour, poke Keybuk to tell fridge to update
[06:04] <ogra> seb128, my evo says 18:00 CEST
[06:04] <ogra> which is exactly now
[06:04] <Keybuk> Riddell: how do I tell fridge?
[06:04] <Keybuk> ogra: your evo is wrong
[06:04] <ogra> seb128, and the fridge seems to agree
[06:04] <seb128> ogra: Keybuk's mail said 15UTC
[06:04] <mdz> ogra: the distro team calendar is authoritative
[06:04] <Riddell> Keybuk: #ubuntu-marketing, fridge-devel@
[06:04] <dholbach> Keybuk<EMAIL_ADDRESS>[06:04] <ogra> gah
[06:04] <pitti> mdz: that's even more wrong
[06:04] <Keybuk> ogra: I mailed you explictitly, with the reminder, with the fact the time was different in capitals
[06:04] <mdz> pitti: it's correct here
[06:04] <Keybuk> Riddell: well voluntold, could you let them know :)
[06:04] <pitti> mdz: it says 8 am for me
[06:05] <ogra> please keep the fridge updated ...
[06:05] <Riddell> nixternal: fancy editing fridge calendar?
[06:05] <cjwatson> please don't use the fridge for this
[06:05] <seb128> mdz: I'm confident GNOME 2.18.1 will be no problem, it's the same timing every time, but right, an extra week next time could be nice
[06:05] <nixternal> Riddell: sure!
[06:05] <cjwatson> -> distro team + ogra anyway. it's useful for others
[06:05] <mdz> seb128: yes, I know.  we've managed in the past and we will manage this time also
[06:05] <nixternal> meeting, date, time, agenda?
[06:05] <mdz> seb128: but I think it would be better to have a little more time
[06:05] <Riddell> nixternal: devel team meetings back an hour (UTC)
[06:05] <seb128> mdz: agreed
[06:05] <ogra> cjwatson, i use the fridge for all dates ... why must this one differ ?
[06:06] <cjwatson> ogra: if you're using a calendar which is consistently not updated for this meeting, you should use something else and deal ...
[06:06] <ogra> :/
[06:06] <cjwatson> it is clearly mailed out to everyone, and blaming the calendar isn't good
[06:06] <Keybuk> Til managed to turn up on time
[06:07] <Keybuk> +l
[06:07] <mdz> ogra: we don't even have the ability to change the fridge calendar; it's run by a different team and sometimes lags
[06:07] <mdz> (directly)
[06:07] <ogra> i know
[06:07] <Keybuk> and we change the times of this meeting, and whether they even happen, regularly
[06:08] <mdz> ok, we're over time
[06:08] <mdz> is there any other business for the meeting?
[06:08] <Keybuk> I could cc fridge-devel on the reminders the day before, but I suspect they'd get sick of that
[06:08] <ogra> but other teams manage it as well ... having a centralized calendar seems pointless if its not used
[06:08] <pitti> the distro team google calendar would be nice, if that wouldn't fail so hideously on time zones
[06:09] <mdz> quibbling about meeting times ->elsewhere
[06:09] <mdz> meeting adjourned
[06:09] <mdz> thanks, everyone
[06:09] <pitti> thanks everyone
[06:09] <mvo> thanks
[06:09] <pitti> and happy bug squashing
[06:09] <mdz> and enjoy your holidays!
[06:09] <kwwii> thanks all
[06:09] <nixternal> what day and time do you guys want the devel team meeting to be posted on the Fridge?
[06:09] <pitti> happy easter!
[06:09] <doko> bye
[06:09] <asac> thanks ... nice holidays everyone
[06:09] <ogra> grmbl,
[06:09] <ogra> yes i had other stuff
[06:09] <nixternal> I have the Fridge open and ready to add :)
[06:09] <ogra> :/
[06:09] <mdz> nixternal: it's moved back 1 hour due to DST
[06:09] <seb128> thanks
[06:09] <cjwatson> nixternal: alternates between 1500 UTC and 2000 UTC on Thursdays
[06:10] <nixternal> cjwatson: 1500 starting next Thursday then?
[06:10] <nixternal> or 2000?
[06:10] <Riddell> 20:00
[06:10] <cjwatson> well, it was 1500 today, which should be a clue ;-)
[06:10] <nixternal> rock on!
[06:10] <nixternal> cjwatson: gahah, damn I am sl o o o w
[06:10] <nixternal> ;P
[06:11] <nixternal> I am not a noob
[06:11] <nixternal> is there a dev team agenda wiki page?
[06:12] <Riddell> https://wiki.kubuntu.org/DevelTeamMeeting2007XXXX for date
[06:12] <nixternal> rock on
[06:13] <ogra> mdz, so you didnt discuss bug 100021 ?
[06:13] <ubotu> Malone bug 100021 in ltsp "[Feisty]  LTSP fails on multi-homed server due to network manager touching predefined static interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/100021
[06:15] <cjwatson> ogra: we tried, but you weren't there ... see scrollback/logs
[06:15] <ogra> yeah, just reading
[06:16] <nixternal> OK, I have the 12th (20:00) and the 19th (15:00) setup for you all
[06:16] <nixnoob1> so herd6 is cancelled?
[06:16] <cjwatson> nixternal: thanks
[06:16] <cjwatson> nixnoob1: yes
[06:16] <nixternal> no problem
[06:17] <cjwatson> (See ubuntu-devel-announce where this was announced)
[06:17] <nixnoob1> yea rt61 is supposed to work buti think wpa doesnt work
[06:17] <nixnoob1> i have rt61 also
[06:18] <nixnoob1> i cant even boot he beta live cd so i cant test it
[06:18] <nixnoob1> yes slimey
[06:34] <ogra> mdz, the bug is well known and i discussed it with Mithrandir various times before it was filesd as a bug ... thats why the report is only two weeks old, what was important from my POV was that it gets milestoned, which didnt happen even though i requested it
[06:35] <ogra> thats why i brought it up ...
[06:45] <cjwatson> the correct way to get a bug milestoned is not to request it, but just to do it
[06:46] <ogra> thats what i did
[06:46] <cjwatson> it can and will be unmilestoned if necessary
[06:46] <ogra> LP only sets a requested tag
[06:46] <ogra> and a release manager needs to approve
[06:46] <cjwatson> no, you used the wrong widget
[06:47] <cjwatson> actually, no, you appear to have used the right one, the "Milestone" combo box
[06:47] <cjwatson> that does not need release manager approval
[06:47] <ogra> hmm
[06:47] <cjwatson> you're thinking of the "target to release" thing, which should only be used for stable releases
[06:47] <ogra> but it doesnt show up on the milestone list
[06:48] <ogra> oh, it does now
[06:48] <ogra> it didnt this morning ...
[06:48] <ogra> then i'm all set ...