[04:20] <mup> Bug #1835437 changed: Commission with "retain network configuration" wipes ip addresses <MAAS:Expired> <https://launchpad.net/bugs/1835437>
[04:20] <mup> Bug #1836398 changed: VMs composed from a POD are not properly deleted from the host when deleted from MAAS <MAAS:Expired> <https://launchpad.net/bugs/1836398>


[00:00] <MichealH> Muscovy: How do I fix this?
[00:04] <Muscovy> MichealH: I'm not sure, I only made that mistake once.
[00:04] <Muscovy> Maybe in the timezone settings, select auto or user or whatever.
[00:09] <MichealH> Muscovy: Make a new one I will delete the old one
[00:09] <MichealH> At least I know for next time
[00:11] <MichealH> Muscovy: Doing it now?
[00:13] <Muscovy> I'll do it shortly.
[00:13] <Muscovy> I'm fairly busy right now.
[00:13] <MichealH> I got rid of link
[04:21] <Muscovy> Just to check that I've done it right, what time of day does http://www.doodle.com/gq554tr82qie6xtw start with?
[07:32] <MichealH> 8:00
[07:32] <MichealH> :L


[00:24] <_com_> hi
[00:25] <_com_> i need support with the following problem: i've have no hdmi- ouput anymore.
[00:26] <_com_> tanks.
[00:33] <TheMuso> _com_: For starters, have you asked in #ubuntu? Secondly, you need to give us some more informatino. What form of HDMI is no longer working? Is it audio, video, or both?
[00:35] <_com_> themuso: yes, i've asked in #ubuntu, but no one has answered.  there is no video and audio.
[00:36] <_com_> the kernel is: 3.16.0-30-generic. i'm using gnome 14.10.
[00:38] <_com_> themuso: the problem appears since yesterday. but i don't know what happens. i've tried different cable and monitor.
[00:39] <TheMuso> _com_: Ok, did you install any updates recently? What GPU are you using, and do you have any proprietary video drivers installed? Do you get any splash screen or console messages?
[00:41] <_com_> themuso: no, i didn't install any updates. the gpu is an Intel Ivybridge Mobile. i don't use any proprietary video drivers. i don't get any splash screens or console messages.
[00:42] <TheMuso> Ok. Do you get any BIOS/boot activity on the screen?
[00:43] <_com_> themuso: no. i don't get any BIOS/boot activity on the hdmi connected screen.
[00:44] <_com_> themuso: i'm using ubuntu 14.10.
[00:52] <_com_> themuso: can you help me?
[00:57] <TheMuso> _com_: Do you have any other monitors you can test with, and is that the only monitor you are using with your machine?
[00:59] <_com_> themuso: i've tried the same monitor with another machine (also ubuntu 14.10, kernel: 3.16.0-30) and it works.
[01:00] <TheMuso> _com_: Well if you don't get any boot/BIOS screens, then it sounds like a hardware problem, unless of course the video card has multiple outputs, and boot screens/BIOS are being displayed via another port.
[01:03] <_com__> themuso: how can i proof it? is it a hardware problem or a driver problem?
[01:06] <TheMuso> _com__: If your machine has other video outputs, try connecting them to a monitor and see if you get anything from the BIOS or Ubuntu bootup.
[01:09] <_com__> themuso: with a vga cable it works. but with hmdi it doesn't work.
[01:10] <_com__> themuso: maybe is the hdmi output broken or could it be a driver probelm? thanks a lot!
[01:14] <_com__> themuso: i will try it  and will look in the bios settings.
[01:24] <_com_> themuso: thank you very much. i don't know what happens. after i did plug the vga cable in, i reboot the system and open the bios settings, and after all i plug in the hdmi cable and the bootscreen appears.
[01:42] <TheMuso> _com_: Good to hear.
[01:43] <_com_> themuso: thank you & bye,bye & have nice night.
[01:43] <TheMuso> _com_: You're welcome.
[05:33] <pitti> Good morning
[07:02] <didrocks> good morning
[07:07] <larsu> good morning!
[07:08] <seb128> good morning desktopers
[07:08] <seb128> hey didrocks larsu
[07:10] <didrocks> re guys :)
[07:12] <excalibr> Guys what is the password for login on ubuntu next iso?
[07:12] <seb128> excalibr, shouldn't have one
[07:13] <seb128> empty password rather
[07:13] <seb128> where does it ask for you?
[07:14] <excalibr> at the login screen
[07:15] <excalibr> Ive tried id/pass ubuntu/ubuntu, ubuntu/<empty>, <empty>/<empty>
[07:15] <excalibr> none works
[07:15] <excalibr> this is the newest iso build. just grabbed it few hours ago
[07:17] <seb128> should be "ubuntu-desktop-next" and empty
[07:17] <seb128> but lightdm shouldn't show
[07:17] <seb128> where do you try it?
[07:17] <excalibr> ohh..that did it :)
[07:17] <seb128> if you get the greeter it's likely because unity8/mir fails to start and you are bounced back there
[08:17] <mlankhorst> morning
[08:18] <mlankhorst> so why does the unity8 login greeter on desktop use Xorg instead of something relying on mir? :P
[08:20] <seb128> mlankhorst, there is no unity8 login greeter?
[08:21] <mlankhorst> perhaps, but unity7 in Xorg-mir is a login greeter :P
[08:21] <mlankhorst> so that could be used at least
[08:23] <willcooke> morning al ready
[08:23] <willcooke> already
[08:23] <mlankhorst> indeed!
[08:23] <willcooke> :)
[08:24] <willcooke> Media scanner has been busy recently.  Last few days I've found it spinning at 100% CPU
[08:24] <willcooke> in 300% in today's case
[08:24] <willcooke> s/in/or
[08:24] <didrocks> hey willcooke, mlankhorst
[08:32] <seb128> mlankhorst, not sure what you suggest? we intend to use an unity8 greeter the day we have one, our current one is the unity7 one though
[08:32] <mlankhorst> seb128: was curious if you could use the unity7 greeter with Xorg-mir :P
[08:32] <seb128> I guess we could
[08:33] <seb128> what would it bring us?
[08:33] <mlankhorst> unity-session-compositor doing what it should? :P
[08:37] <mlankhorst> and allowing me to replace /usr/bin/Xorg with Xmir for testing
[08:58] <seb128> mlankhorst, I don't see an issue with that, maybe email the desktop list to describe the suggested change so we get feedback on it?
[09:05] <willcooke> +1
[09:06] <willcooke> The installer guys were interested in switching to Mir, but maybe Xmir would make a suitable stepping stone?
[09:06] <willcooke> Actually, I don't know that they even use X
[09:06] <Laney> yo
[09:06] <willcooke> what up Laney
[09:10] <seb128> hey Laney
[09:10] <seb128> willcooke, the installer guys? do we still have some of those?
[09:10] <seb128> willcooke, also for what installer? mir currently doesn't work on VMs for example, that's not good for the installer (same for the greeter)
[09:10] <seb128> also does it work with all video drivers, included nvidia, etc?
[09:11]  * willcooke shuts up
[09:11] <seb128> I think that was an issue when we previously talked about using the system compositor by default
[09:11] <willcooke> It's a good job there is someone sane around here
[09:11] <seb128> lol
[09:11] <seb128> willcooke, don't shut up, those are interesting questions :-)
[09:11] <seb128> we just need to figure out the answers
[09:11] <willcooke> ha!
[09:32] <seb128> didrocks, do you remember what was the issue with enabling the system compositor by default? that was the support on some drivers right? do you know if that's still an issue?
[09:35] <didrocks> seb128: some driver support indeed, so the idea was to fallback and having a white list of driver known to work
[09:36] <didrocks> seb128: that's still an issue AFAIK, only intel (and maybe nouveau?) works on Mir
[09:36] <didrocks> so, if someone installs nvidia (blob) driver, we need to have a good story here
[09:36] <seb128> mlankhorst, ^ is that still true?
[09:36] <Laney> Noskcaj / darkxst: what's the grilo status?
[09:37] <darkxst> Laney, split is ready for sponsoring
[09:37] <darkxst> https://code.launchpad.net/~noskcaj/ubuntu/vivid/grilo-plugins/split
[09:38] <Laney> is it agreed?
[09:38] <mlankhorst> intel, radeon, and nouveau work?
[09:38] <seb128> mlankhorst, what happens is somebody install i.e nvidia binary drivers?
[09:38] <darkxst> Laney, was discussed with berto and seb128  in #debian IRC
[09:38] <Laney> 'yes'?
[09:38] <darkxst> and yes agreed
[09:38] <Laney> ok
[09:39] <seb128> i.e->e.g
[09:41] <mlankhorst> seb128: yo uwon't have unity8 anyway..
[09:41] <mlankhorst> in that case
[09:41] <mlankhorst> so my guess is 'unity-session-compositor will fail to start'
[09:42] <seb128> mlankhorst, ok, so that's out of question to do on the default image
[09:42] <seb128> we can probably do it on -next thouh
[09:42] <seb128> though
[09:44] <mlankhorst> yeah default image is u7 anyway, but for u8 image it might make sense
[09:44] <seb128> well, having xmir/system compositor tested around u7 would make sense
[09:44] <seb128> or could at least
[09:44] <seb128> what is needed to change -next to use the system compositor?
[09:45] <mlankhorst> I guess changes to lightdm mostly
[09:45] <seb128> configuration changes?
[09:45] <seb128> seems like something to discuss with robert_ancell
[09:45] <seb128> just email the desktop list and let's have the discussion there :-)
[09:51] <Laney> darkxst: are you going to sponsor it? (just noticed it's in gnome)
[09:51] <Laney> (the set)
[09:51] <darkxst> Laney, oh didnt realise that, ok will do
[09:54] <Laney> great!
[09:58] <darkxst> Laney, and I already reviewed it so uploading now
[10:02] <Laney> darkxst: doesn't seem to be an upgrade path
[10:03] <darkxst> Laney, since there are only 2 rdeps no much point of transitional package
[10:03] <darkxst> and pretty sure noskcaj also made updates for those 2 existing packages)
[10:04] <Laney> ok
[10:17] <darkxst> Laney, though not to sure we he put them
[10:17] <darkxst> were
[10:18] <Laney> just changing the dep right?
[10:19] <Laney> i'm sure we can handle that
[10:20] <darkxst> Laney, yes, and doing it now for gnome-music and gnome-online-miners, you can handle it for totem ;)
[10:21] <seb128> Laney, do you have an updated vivid? can you try to build u-s-s?
[10:22] <Laney> seb128: ya, ok, from where?
[10:22] <seb128> Laney, lp:u-s-s
[10:23] <Laney> did Mirv merge his changes there?
[10:23] <seb128> yes
[10:23] <jpds> So, something's been bugging me for the last few weeks but I can't figure out what's wrong - does anyone know what I need to do to get that little envolope in the indicators?
[10:23] <seb128> but somewhat it fails to build for me locally
[10:23] <seb128> jpds, run a software that uses that indicator (e.g empathy, pidgin, evolution, tb)
[10:24] <jpds> seb128: I'm always running thunderbird.
[10:24] <seb128> jpds, and the indicator is not showing? is it installed? (dpkg -l | grep indicator-messages)
[10:24] <jpds> seb128: Yes, and yes.
[10:24] <jpds> Hence my confusion.
[10:24] <Laney> seb128: indeed it fails
[10:25] <jpds> Looks like the extension for thunderbird is installed too.
[10:25] <seb128> Mirv, ^ how can that be the case? how did you build u-s-s?
[10:25] <seb128> jpds, it's not showing at all?
[10:25] <Laney> there's a diff to the archive
[10:25] <Laney> vs. bzr
[10:25] <jpds> seb128: Yep, never seen it.
[10:25] <seb128> Laney, how/why
[10:25] <jpds> seb128: Since my reinstall.
[10:25] <Laney> guess it wasn't committed
[10:25] <seb128> jpds, does it show if you run empathy?
[10:25] <seb128> Mirv, ^
[10:25] <Laney> it's basically the contents of my branch
[10:26] <jpds> seb128: Hmm, don't have it installed.
[10:26] <seb128> 1310 commit has
[10:26] <seb128> "  Fake-sync from archives 0.3+15.04.20150213-0ubuntu2. Does not include the work-in-progress branch.
[10:26] <seb128> "
[10:26] <seb128> that seems buggy
[10:26] <seb128> jpds, $ gsettings get com.canonical.indicator.messages applications
[10:27] <jpds> seb128: Nothing in there.
[10:27] <seb128> jpds, that's your issue
[10:27] <seb128> not sure why tb doesn't add itself though
[10:32] <Mirv> seb128: Laney: not committed as commented on the bug as it was a combination of laney's wip branch, my branch (enough to make it compile) and commenting out Storage.qml. I did a fakesync from archives and waited to know what kind of approach you want to have.
[10:32] <seb128> Mirv, trunk should be what is in the distro, especially that currently trunk doesn't build due to your incomplete commit :-/
[10:33] <seb128> Mirv, can you please fix the build issue in there? I'm hacking on bluetooth changes and I need trunk to keep building
[10:33] <Mirv> seb128: ok, as you wish. I gave the possibility of finishing the wip bramch properly, but I'll sync the trunk now then instead of fakesync.
[10:34] <Laney> In a minute I'll do a MP to bring back the storage panel with the copy of the function or similar
[10:34] <Laney> then we can work on a proper replacement over time
[10:34] <seb128> Laney, thanks
[10:35] <seb128> Mirv, yeah, ideally we wouldn't have merge half work, but having things still building is better so it doesn't block other fixes to land or people to work
[10:36] <seb128> Mirv, nice work on landing qt5.4 btw :-)
[10:39] <Mirv> seb128: Laney: trunk uptodate
[10:39] <Mirv> seb128: thanks :)
[10:42] <seb128> darkxst, you just uploaded gnome-music, have you seen that there is an update for it in the sponsoring queue? you might want to upload that one?
[10:43] <seb128> Mirv, btw, partial updates were a fail, e.g if you used update-manager to do a normal update, it would update part of the qt stack and let things not working on qt version mismatches
[10:43] <seb128> like settings would run until I dist-upgraded
[10:43] <darkxst> seb128, oh, didnt see that, will do
[10:44] <seb128> darkxst, thanks
[12:41] <didrocks> hum, notify-osd volume doesn't take into account the above 100% patch from larsu as the indicator
[12:42] <didrocks> it was before IIRC
[12:42] <didrocks> (like 100% is now less than the maximum volume you can set)
[12:42] <didrocks> anyone else seeing this?
[13:04] <Frugals> i havent read the TOS so im just gona STFU
[13:05] <Frugals> before they put me on some english prison
[13:11] <seb128> didrocks, not sure to understand what you mean, do you have the option enabled or not?
[13:12] <didrocks> seb128: I have the option enabled, the indicator is working as expected
[13:13] <didrocks> however, I'm using the media keys for volume up/down
[13:13] <didrocks> the notify-osd bar is at 100% way before I reach the "new" 100%
[13:16] <seb128> hum, unsure what handles those notifications, is that u-s-d?
[13:16] <seb128> that didn't change much in vivid :-/
[13:16] <seb128> didrocks, did you change the option during the session?
[13:17] <didrocks> seb128: I didn't change or update it
[13:17] <seb128> I wonder if that's another instance of being bitten by the gsettings get/subscribe to change bug
[13:17] <seb128> guess not then
[13:18] <didrocks> seb128: just noticed it today, not sure since when it started, but it didn't do that in the past, right?
[13:18] <seb128> no it didn't
[13:18] <didrocks> do you see it as well?
[13:19] <seb128> yeah, it's weird
[13:19] <seb128> it's like they were updating a second time
[13:20] <seb128> I can see one value and the bar changing
[13:20] <seb128> it's easier to see if you press several times, it can see the not regular changes
[13:20] <seb128> it seems to step forth and back
[13:21] <didrocks> exactly
[13:22] <seb128> I'm going to have a look
[13:22] <didrocks> the slider in the gtk app doesn't show the step back and force
[13:22] <seb128> or did you want to do that?
[13:22] <Frugals> didrocks: are you a cook?
[13:22] <didrocks> I can have a look, but later this week
[13:22] <seb128> k
[13:22] <didrocks> Frugals: ?
[13:22] <seb128> let's see if I beat you to it ;-)
[13:23] <didrocks> deal! :)
[13:23] <Frugals> do you cook meth?
[13:24] <Frugals> your nick saying you did rocks
[13:55] <willcooke> seb128, is guest U8 session on your U8 machine working?
[13:55] <willcooke> I just get a blank screen
[13:55] <willcooke> with a pointer
[13:56]  * willcooke upgrades
[14:03] <ChrisTownsend> willcooke: AFAIK, guest sessions have never worked on the U8 desktop: https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1307618
[14:03] <seb128> willcooke, let me upgrade as well, it's working but there was the qt5.4 transition yesterday
[14:04] <seb128> oh, guest
[14:04] <willcooke> ChrisTownsend, seb128 - oki - thanks!
[14:04] <ChrisTownsend> seb128: You had me worried there for a bit:)
[14:04] <seb128> ChrisTownsend, is the issue due to apparmor or...?
[14:05] <ChrisTownsend> seb128: Permissions on the Mir socket I believe.
[14:05] <ChrisTownsend> seb128: Or that is the first issue to overcome.
[14:05] <seb128> ChrisTownsend, but is the apparmor profile what blocks the access or...?
[14:06] <ChrisTownsend> seb128: Hmm, not sure.  I should probably investigate.
[14:06] <seb128> ChrisTownsend, I'm going to have a look
[14:06] <larsu> didrocks: uh? Works for me...
[14:06] <ChrisTownsend> seb128: For some reason, I thought it was a known issue by some other team, but it's been a while.
[14:06] <ChrisTownsend> seb128: Ok, cool, thanks!
[14:06] <didrocks> larsu: hum, maybe something racy? seb128 and I seem to see it
[14:07] <seb128> ChrisTownsend, could be, I'm just not aware of it
[14:07] <ChrisTownsend> seb128: Right
[14:07] <seb128> didrocks, larsu, it's indicator sound overwriting the value with a buggy one, stop it and things work
[14:07] <larsu> seb128, didrocks: I'll have a look. I guess the recent i-sound changes mess things up again
[14:08] <seb128> larsu, didrocks, I'm pondering reverting the recent indicator-sound changes
[14:08] <seb128> it makes it display notification when it shouldn't like
[14:08] <didrocks> seb128: confirmed
[14:08] <seb128> like any time the source changes
[14:08] <didrocks> seb128: works well once stopped and prevented to restart
[14:08] <seb128> which includes when starting the greeter
[14:08] <seb128> or plugin an headset
[14:09] <seb128> didrocks, you can just use "stop" with upstart to prevent restart :-)
[14:09] <didrocks> seb128: who uses upstart? :p
[14:09] <seb128> indicator-soundù!
[14:10] <didrocks> seb128: I need to get used to upstart in session one day :)
[14:14] <Laney> sbuild y u hang
[14:22] <larsu> didrocks, seb128: I can reproduce now. Apparently I didn't have the right version installed (or didn't log out in long enough)
[14:23] <seb128> larsu, don't bother anyway, bt works first I would say, let's ted look at that bug since he's the one who introduced it
[14:23] <larsu> seb128: ok, fair enough
[14:24] <didrocks> seb128: hop, bug #1422745
[14:24] <seb128> didrocks, thanks
[14:24] <didrocks> yw :)
[14:25] <seb128> tedg, hey, can you look at ^, seems a recent indicator-sound regression
[14:25] <larsu> hm, I also get a notification now when I toggle the "allow > 100%" checkbox
[14:25] <seb128> tedg, it overwrites the u-s-d notifications with buggy ones, which makes the bubbles have a visual glitch and being wrong
[14:25] <larsu> and also when changing the volume from system settings
[14:25] <larsu> this is all kinds of wrong...
[14:25] <seb128> larsu, yeah, that's part of the "notifications keep being displayed on any random revent"
[14:25] <seb128> tedg, why did we need to do that again?
[14:26] <larsu> seb128: ah, right
[14:26]  * seb128 feels like we should just revert the recent changes
[14:26] <larsu> tedg: I took a lot of care a couple of months ago to make sure notifications only happen when needed
[14:26] <didrocks> the over-spammification of notifications is indeed a user regression IMHO
[14:34] <seb128> bah, polkit refuses my user password on my test machine, wth?
[14:34] <seb128> same password works for login and in the greeter
[14:35] <tedg> larsu, The problem was the notifications got added into the volume control object when the streams code was added last minute.
[14:36] <tedg> So, then pulling them out of the volume control object has made things funky, as basically they weren't working there.
[14:36] <tedg> But, we should drop g-s-d sending notifications.
[14:37] <seb128> tedg, patches are welcome :-)
[14:37] <larsu> tedg: didn't I pull this out of the control object once? Why is it in there again?
[14:37] <seb128> tedg, also please make indicator-sound send non buggy ones
[14:37] <tedg> Fixing indicator-sound first :-)
[14:38] <tedg> larsu, it got readded with the streams code which is… needs reworking.
[14:38] <larsu> tedg: ugh :(
[14:38] <larsu> tedg: unity-settings-daemon only sends a notification in the media keys plugin - which it should
[14:39] <larsu> basically the idea should be this: send a notification not when the sound changes, but when the user does an action
[14:39] <tedg> larsu, Eh, no, I don't think so. As we really should start routing media keys the same in U7 and U8.
[14:39] <larsu> which is only in two places: (1) the media keys plugin and (2) the scroll-event over the indicator
[14:39] <tedg> larsu, So I think it should start using the actions we're using in U8.
[14:40] <larsu> tedg: sure, if you port the whole media keys thing to indicator-sound, we can drop the u-s-d plugin
[14:40] <larsu> I would very much welcome that
[14:41] <tedg> larsu, Well in the U8 world the media keys get caught by the compositor (U8) and then get forwarded to i-sound. So we'd still want usd to catch the keypresses, just pass them the same.
[14:43] <larsu> tedg: even better. We should also drop i-sound then ;)
[15:24] <Laney> bah
[15:24] <Laney> BAH I SAY
[15:24] <Laney> why can't we keep x-build-deps installable :(
[15:29] <seb128> because we don't have tests for those which block things that regress
[15:30] <Laney> haha
[15:30] <Laney> yes!
[15:30] <willcooke> alllllllllrighty
[15:30] <willcooke> #startmeeting Desktop Team Weekly Meeting 2015-02-17
[15:30] <meetingology> Meeting started Tue Feb 17 15:30:42 2015 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <qengho> ding ding!
[15:31] <willcooke> Roll call:  didrocks the operator, attente_, desrt, dgadomski, laney, larsu, mlankhorst, qengho, seb128, Sweet5hark,
[15:31] <seb128> _o/
[15:31] <desrt> hihi
[15:31] <willcooke> A sure way to get yourself at the top of the list didrocks
[15:31] <Sweet5hark> heya, reporting in
[15:31] <didrocks> -o/
[15:31] <dgadomski> o/
[15:31] <larsu> |o
[15:31] <desrt> didrocks: something weird is growing out of your right ear
[15:32] <didrocks> desrt: well, knees being broken, neck as well, now it's the ear! :)
[15:32] <didrocks> I guess I'm out of warranty
[15:32] <willcooke> FJKong_, happyaron, tkamppeter are our this week
[15:33] <willcooke> Before we start, Laney asked for a quick Q&A re Xmir, which we will do at the end of the round up.  Xmir is broken at the moment though.  It's complicated
[15:33] <willcooke> so let's kick off in the order of the roll call to make my life easier:
[15:33] <willcooke> #topic didrocks
[15:34] <didrocks> Short week (4 days)
[15:34] <didrocks> Ubuntu Make:
[15:34] <didrocks> - released 0.5 adding Idea Ultimate support, Android NDK, Dartlang and Firefox developer edition (work from last week): http://blog.didrocks.fr/post/Ubuntu-Make-0.5-adds-four-new-platforms
[15:34] <didrocks> - merged a new contributor work adding support for ruby, pycharm educational issue, pycharm professional edition, webstorm, phpstorm (and misc small fixes) + zsh support!
[15:34] <didrocks> - spent quite some time to add/fix medium and large tests for the above and rebase on master + some small functionalities issues. Also some pep8 and small tests enhancements.
[15:34] <didrocks> -> release planned tomorrow, *plenty* of time before feature freeze! (a whole day ;))
[15:34] <didrocks> Systemd:
[15:34] <didrocks> - some display-manager generator fixes for debian.
[15:34] <didrocks> - uploaded plymouth changes for fsckd and as the fsckd changes couldn't be in systemd 219, Martin distro-patched those fsckd changes and is now in ubuntu! Small usptream comments on it, addressed.
[15:34] <didrocks> Misc:
[15:34] <didrocks> - half patch piloting day, will do the other half tomorrow
[15:34] <didrocks> - fctix MIR rerereviewed and… approved!
[15:34] <didrocks> .
[15:35] <willcooke> thanks didrocks
[15:35] <didrocks> yw
[15:35] <willcooke> The latest Make release was well received, and thanks for all your work on systemd too (and everything else of course)
[15:35] <willcooke> #topic attente_
[15:35] <attente_> hi
[15:36] <attente_> need reviewers for i-k, u-s-d, u-c-c:
[15:36] <attente_> https://code.launchpad.net/~attente/indicator-keyboard/fcitx-transition/+merge/229737
[15:36] <attente_> https://code.launchpad.net/~attente/unity-settings-daemon/fcitx-transition/+merge/230289
[15:36] <attente_> https://code.launchpad.net/~attente/unity-control-center/fcitx-transition/+merge/249523
[15:36] <attente_> tried porting fcitx-qimpanel to Qt 5, needs a lot of work
[15:37] <willcooke> attente_, thanks. Any news/updates on Gtk Mir?  Just askin'
[15:38] <attente_> willcooke: not much. tried getting ibus working under the demo shell, but it's heavily x dependent
[15:38] <willcooke> attente_, sure.  Oki!  I think we'll need to kick start that work again once fcitx is dealt with
[15:39] <attente_> willcooke: sure! i just think we're still blocked on a lot of stuff from Mir
[15:40] <seb128> @reviews, I can help on u-s-d/u-c-c, would be nice if somebody more fluent in vala would look at the indicator though
[15:40] <meetingology> seb128: Error: "reviews," is not a valid command.
[15:40] <seb128> meetingology, shup up
[15:40] <meetingology> seb128: Error: "shup" is not a valid command.
[15:40] <seb128> shut
[15:40] <attente_> lol
[15:40] <willcooke> attente_, ack - hopefully we will start to see those requirements land soon.  I feel like I've taken my off it for too long.  We can sync in a couple of weeks
[15:40] <desrt> i'll look at the indicator
[15:40] <desrt> will be good since attente and i are meeting up later today anyway
[15:41] <seb128> desrt, thanks
[15:41] <willcooke> thanks chaps
[15:41] <willcooke> #topic desrt
[15:41] <desrt> hi
[15:41] <desrt> not a huge week in terms of actual code production
[15:42] <desrt> spent some time on reviews
[15:42] <desrt> had a lot of discussions about some feedback coming in on first uses of g_autoptr() and G_DECLARE_TYPE macros, with some suggested changes
[15:42] <desrt> did some code reviews
[15:42] <desrt> also did some trying out of pwithnall's work upstream for the new approach for m4 macros in gnome projects... trying to make sure that's usable and not entirely happy with the result yet, so more discussions there
[15:43] <desrt> started to create a new upstream m4macros module that will hopefully be a good compromise position on that
[15:43] <desrt> i fixed the potential deadlock in my mount-monitor branch and am awaiting reviews
[15:43] <desrt> i'm also probably finally merging the GSimpleIOStream branch today
[15:44] <desrt> i also wrote a neat new mode for dconf: 'dconf summary' which lists which apps are configured, which are in their default state and which dconf paths are orphans (ie: old settings left over from uninstalled apps)
[15:44] <willcooke> ooh, nice
[15:44] <desrt> and as a side project i'm working on a set of tools for mirroring bugzilla on my laptop, which is driving the development of some very interesting pieces of technology -- a streaming class for GVariant over sockets, and a sequence-number-based database storage mechanism
[15:44] <desrt> both of which i hope to use for dconf database syncing at some point in the future
[15:44] <desrt> that's about all
[15:45] <willcooke> thanks desrt, sounds like a lot of code production to me :)
[15:45]  * qengho recalls harrowing tales of putting configs in desktopcouch.
[15:45] <desrt> btw: http://fpaste.org/186581/
[15:46] <desrt> the 'unknown app' thing will make seb happy... it's a way to shame even more people into renaming their desktop files ;)
[15:46] <larsu> desrt: I gave it a quick review but need a walk through of the deadlock fixing thing
[15:46] <larsu> desrt: otherwise looks fine to me
[15:47] <desrt> larsu: cool.  let's talk about that after the meeting
[15:47] <willcooke> thanks chaps
[15:47] <willcooke> #topic dgadomski
[15:47] <dgadomski> hi
[15:47] <dgadomski> while working on a fix to bug #1104230 another problem occured - when using iface bonding with mode different from round-robin the mode sometimes fallbacks to round-robin. Investigating that.
[15:47] <dgadomski> talked to cyphermox about the network manager issue (bug #1421259), he is going to check it
[15:48] <dgadomski> finally have some time to get back to improving fix to bug #1125442
[15:48] <dgadomski> and that's it this week
[15:48] <willcooke> dgadomski, anything we can assist with?
[15:48] <dgadomski> no, thank you, everything looks ok
[15:49] <willcooke> I wonder if the iface issue is what I've seen on U8 V.  Where my network drops in and out if I'm connected to wifi and wired
[15:49]  * willcooke plays
[15:49] <willcooke> thanks dgadomski
[15:49] <willcooke> #topic Laney
[15:50] <Laney> hi cool cats
[15:50] <Laney> • Short week - day off on Friday
[15:50]  * desrt eagerly awaits some unicode
[15:50] <Laney> • Performance review & 360 feedback for others
[15:50] <Laney> • Patch piloted
[15:50] <Laney> • Worked on some more fixes required before updating totem to 3.14 (ppa:ubuntu-desktop/ppa, please test, needs grilo-plugins from NEW)
[15:50] <Laney> ∘ has weird pixelated icons in some places & we need to theme the OSD
[15:50] <Laney> • Some extra dialog headerbar fixes in nautilus
[15:50] <Laney> • Update glib to debian, test, sync
[15:50] <Laney> • Work a bit on u-s-s/Qt 5.4 StorageInfo removal mitigation, now yak shaving the xbuilddeps into working again & want to look at adding a test for this (one problem is that autopkgtests are only triggered for reverse binary deps, not reverse build deps but maybe it'll be enough)
[15:50] <Laney> ⚘
[15:51] <willcooke> :)
[15:51] <willcooke> thanks Laney
[15:51] <willcooke> we have to skip on to mlankhorst 'cos he's got to head out.. so get your Xmir questions ready... larsu we'll come back round to you shortly...
[15:51] <willcooke> #topic mlankhorst
[15:52] <mlankhorst> hey
[15:52] <mlankhorst> trying to get xmir running on other platforms
[15:52] <mlankhorst> and adding a sync egl mode to xmir to hopefully get rid of some crashes
[15:52] <mlankhorst> and some more xmir stuff, less important :P
[15:53] <mlankhorst> testing with mesa 10.5.0-rc1, may upload it to archive tomorrow depending on piglit results
[15:53] <mlankhorst> some debugging of utopic -> trusty xorg backport
[15:53] <mlankhorst> ^d
[15:53] <willcooke> mlankhorst, I wanted to say thanks again for all your help over with Xmir recently - it's been very reassuring to know you're there :)
[15:53] <willcooke> Laney, you want to ask some questions?
[15:55] <Laney> hmm, don't know, I was hoping for a high level overview of what we're doing with xmir
[15:55] <Laney> so that I might have an idea of questions after that :P
[15:56] <willcooke> so right now we're trying to get it to run reliably on Ubuntu Touch devices so that one can run X applications on Mir, on devices
[15:56] <willcooke> On the desktop, specifically Intel hw, it's working well
[15:57] <seb128> willcooke, I guess it's a bit non obvious how the pieces fit together, what is the system compositor, what is xmir and what's doing, why we need them, etc
[15:57] <willcooke> Things going on around Xmir include hooking up input events, getting socket activation set up so that X apps can request an Xmir instance
[15:58] <willcooke> mlankhorst can answer that better than I could, but...
[15:59] <willcooke> AIUI, the main system compositor is Unity8 sys comp. Xmir gets a surface from Mir to draw on, and passes that off to U8 sys. comp for placing in the right place
[16:00] <willcooke> as far as the X applications are concerned, it's business as usual
[16:00] <willcooke> and as far as U8 is concerned it's just another surface
[16:00] <attente_> are X apps affected by the bug of creating multiple surfaces?
[16:01] <willcooke> no, because at the Mir level it's one surface
[16:01] <Laney> does it work for apps with multiple windows?
[16:01] <willcooke> inside the Xmir session, at the moment, I have had more success when using, say, Metacity as a WM, so that things like file browser windows have controls
[16:01] <seb128> does dnd between apps work?
[16:02] <willcooke> Laney, @ multi windows - it;s like running X with out a window manager
[16:02] <willcooke> things pop up in the middle and look unstyled
[16:02] <willcooke> (in my experience anyway)
[16:02] <willcooke> running a WM makes a big difference
[16:03] <willcooke> dont know how we fix that long term yet
[16:03] <willcooke> maybe a small WM inside Xmir?
[16:03] <willcooke> (hence my questions about WM recently)
[16:03] <desrt> (maybe discuss after the meeting?)
[16:03] <seb128> (yeah, was supposed to be at the end of the meeting no?)
[16:03] <willcooke> yeah, but mlankhorst had to dash
[16:03] <Laney> I thought we did it now so that mlankhorst could be involved
[16:03] <Laney> but he seems to have gone anyway
[16:04] <Laney> so ya
[16:04] <willcooke> let's contine after the meeting and then I can collate questions for mlankhorst
[16:04] <seb128> oh, ok :-/
[16:04] <willcooke> #topic larsu
[16:04] <larsu> it's me!
[16:04] <seb128> well, we can also ask questions to mlankhorst another time
[16:04] <seb128> doesn't seem that useful to proxy through somebody for that ;-)
[16:05] <willcooke> fair point
[16:05] <willcooke> y'all do that
[16:05] <larsu> had a swap day as well and also did some administrative stuff (expenses, self review, 360s)
[16:05] <larsu> did some investigation for Laney on Wednesday - honestly forgot what it was
[16:05] <Laney> screenshot
[16:05] <larsu> ah right
[16:05] <larsu> thanks :)
[16:05] <larsu> gnome-screenshot's flash is broken
[16:06] <larsu> did you apply my patches?
[16:06]  * larsu wonders where he has them
[16:06] <Laney> no, because it works in 3.14
[16:06] <larsu> right
[16:06] <larsu> I should put them on a bug
[16:06] <Laney> ya
[16:06] <larsu> anyway: code reviews and some fly-by bugs
[16:07] <larsu> more app-id madness in gnome-terminal (blocked on a review from desrt)
[16:07] <desrt> larsu: bind busy property... (pair programming ftw)
[16:07] <larsu> a small detour on Friday renaming GtkSidebar, because really
[16:07] <larsu> desrt: that was on the weekend :)
[16:08] <larsu> got involved in a theming discussion and spoke in favor of css classes for title buttons
[16:08] <larsu>  - we got them in master and somebody already has a theme update for our headerbars
[16:08] <larsu> started working on the bluez5 transition
[16:09] <larsu> installed and tested what robert already had
[16:09] <larsu> which already works for the most part
[16:09] <larsu> have a couple of fixes on a branch for unity-control-center (working power button, yay)
[16:09] <larsu> did lots of testing of that and the indicator with my phone
[16:09] <seb128> (button not working?)
[16:10] <larsu> seb128: it was weirdly jumping back and forth in some cases
[16:10] <larsu> seb128: the switch in u-c-c for turning bt on/off
[16:10] <larsu> I also started backporting the old ui, because the new one is a bit too gnome-3 for our taste
[16:10] <larsu> (almost nothing in the panel and lots of dialogs)
[16:11] <larsu> on the weekend and some evenings I hacked on gnome-logs, which is much more usable now for big logs
[16:11] <larsu> I think we should include it instead of gnome-system-logs once we switch to systemd
[16:12] <larsu> that also led to some new gapplication api that I pair-programmd with desrt  (thanks again!)
[16:12] <larsu> I think that might be it for this week. As usual, I will have forgotten something.
[16:13] <willcooke> thanks larsu
[16:13] <willcooke> #topic qengho
[16:13] <qengho> * Some progress on fixing internal-/device-coordinate mapping in chromium aura.
[16:13] <qengho> * Several days vacation last week. National holiday yesterday. Two-day week.
[16:13] <qengho> * to-do: more on coordinate mapping. Should make high-DPI more usable. Probably some event-layer mapping to fix too.
[16:13] <qengho> EOF
[16:14] <willcooke> thanks qengho I think lots of people will be grateful for the hidpi fixes
[16:14] <willcooke> any progress on Mir backend?
[16:14] <qengho> Not in those days.
[16:15] <willcooke> more generally?
[16:15] <qengho> I have to figure out the protobuf double-static init crashes.
[16:16] <qengho> (Cr uses protobuf-lite. libmirclient uses protobuf. Version conflict or two usages or full library? Both have problems.)
[16:16] <desrt> yay protobuf
[16:17] <willcooke> desrt took the bait.  He's helping you with that now.
[16:17] <qengho> Yes!
[16:17] <qengho> You so sneaky, willcooke .
[16:17] <qengho> That's all for me.
[16:18] <mlankhorst> Laney: Xmir will run as a client inside mir, but runs a full X server.
[16:18] <willcooke> thanks qengho
[16:18] <willcooke> #topic seb128
[16:19] <seb128> hey
[16:19] <seb128> • resolved casper issue with my previous changes (incorrect permissions on .config)
[16:19] <seb128> • sponsoring (libreoffice update, gthumb, libspectre, langpack-locales, etckeeper, some syncs)
[16:19] <seb128> • hr review
[16:19] <seb128> • discussed mtp-server trying to run on desktop, reviewed changes to fix the issue
[16:19] <seb128> • reported some uitk bugs about handling of gettext domain by the MainView, including a documentation patch
[16:19] <seb128> • ubuntu-system-settings
[16:19] <seb128> ∘ spent a day to get to the bottom of a translation issue due to the uitk setting the translation domain for you, g_dgettext being called on that (buggy)value and deciding it shouldn't return translated string, before having the domain changed from the ui but glib staying on the "do not translate"
[16:19] <seb128> ∘ workarounded a bluetooth ssp pairing issue impacting some devices (due to bluez returning a buggy entered chars hint)
[16:19] <seb128> ∘ started looking at issue with bt discovery on the phone
[16:19] <seb128> • usual share of desktop related bugs triages and discussions

[16:19] <willcooke> thanks seb128
[16:19] <willcooke> #topic Sweet5hark
[16:19] <Sweet5hark> ☞ not much coding done, because of:
[16:19] <Sweet5hark> ☞ triaged nastiness of bug 1419836 down the whole long UNO rabbit hole
[16:19] <Sweet5hark> ☞ building with fix now, might also fix other weird issues with the 4.4 upload
[16:19] <Sweet5hark> ☞ build and released LibreOffice 4.3.6~rc2/Utopic to ppa (also as base for other backports), will be released as final upstream soonish
[16:20] <Sweet5hark> ☞ upstream foo: tools coordination and leadership, regressions, open source productivity suite consolidation politics
[16:20] <Sweet5hark> ☞ considering a "LibreOffice still" ppa to follow upstream branding. opinions on that?
[16:20] <Sweet5hark> EOF
[16:20] <willcooke> POW!
[16:21] <willcooke> what does still mean in this context?
[16:21] <Sweet5hark> willcooke: so "libreoffice fresh" is latest and greatest: 4.4.x as of today
[16:22] <Sweet5hark> willcooke: and "libreoffice still" it the older branch that still gets updates: as of today 4.3.x which just got 4.3.6 ...
[16:22] <willcooke> I see
[16:23] <willcooke> Having given it very little consideration, it sounds like a good plan.  Allowing people to stick with a version and still get updates
[16:24] <Sweet5hark> willcooke: upstream offers both for download, and I now get asked about doing the same for the ppas. ("libreoffice fresh" would be x.y.0 -> ~x.y.4, "libreoffice still" would be the older major with higher minors x.y.4 -> x.y.6)
[16:25] <willcooke> let's give it some more thought and see if anyone has any problems, otherwise +1
[16:25] <Sweet5hark> willcooke: kk
[16:25] <willcooke> #topic TheMuso
[16:25] <qengho> Sweet5hark: Sounds like a good reason to move version into the package name.
[16:25] <willcooke> * Packaged up pulseaudio 6.0, helping Debian with the process as well.
[16:25] <willcooke> * Build a set of pulse 6 packages against bluez 4 for armhf, which can be found at http://people.canonical.com/~themuso.
[16:25] <willcooke> * More unity a11y bugfix work
[16:25] <willcooke> #topic willcooke
[16:25] <willcooke> Xmir woes
[16:25] <willcooke> #topic any other business
[16:26] <willcooke> Anyone got anything else?
[16:26] <willcooke> Going one...
[16:26] <willcooke> *once
[16:26] <willcooke> oh..
[16:26] <willcooke> #topic tkamppeter
[16:26] <willcooke> - cups-filters: Added PPD generator for IPP Everywhere printers to cups-browsed. Now they set up automatically with PPD, so having options in all print dialogs.
[16:26] <willcooke> - cups: Added PPD generator for IPP Everywhere printers
[16:26] <willcooke> - Prepare for FF: system-config-printer 1.5.5, Ghostscript 9.15, cups-filters 1.0.65, foomatic-db 20150213.
[16:26] <willcooke> - Google Sumer of Code 2015: Set up project idea list for OpenPrinting, application of the Linux Foundation as a mentoring organization.
[16:26] <willcooke> - Performance review.
[16:26] <willcooke> - Bugs
[16:26] <willcooke> #topic any other business
[16:26] <willcooke> going twice
[16:27] <willcooke> #endmeeting
[16:27] <meetingology> Meeting ended Tue Feb 17 16:27:06 2015 UTC.
[16:27] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2015/ubuntu-desktop.2015-02-17-15.30.moin.txt
[16:27] <willcooke> thanks all
[16:27] <dgadomski> thanks
[16:27] <seb128> thanks
[16:27] <attente_> thanks
[16:27] <Sweet5hark> thanks
[16:27] <Laney> tHaNkS
[16:27] <larsu> ThAnKs
[16:27] <didrocks> thanks
[16:28] <seb128> willcooke, you didn't have an update from robert_ancell?
[16:28] <willcooke> not this week, he forgot
[16:28] <larsu> stupid time zone
[16:28] <Laney> summer over there, rite?
[16:28] <Laney> * went to the pool
[16:28] <larsu> would be cool to have him in the meeting
[16:28] <Laney> * had a bbq
[16:30] <willcooke> we could look to have a later meeting every so often, say 1930/2000 UTC if people are able
[16:30] <Sweet5hark> willcooke: FWIW, we already have the versions and builds in a PPA -- one for each series. But people wanting to use "libreoffice still" currently need to manually switch PPAs e.g. from ppa:libreoffice/libreoffice-4-2 to ppa:libreoffice/libreoffice-4-3.
[16:30] <larsu> can't he just get up early? :P
[16:31] <Sweet5hark> willcooke: Ill set the libreoffice still PPA up and maybe will postpone opening a "libreoffice-4-5" ppa next time around. If nobody complains ...
[16:32] <willcooke> larsu, that would be early :)
[16:32] <Bl4ckD34Th> sudo add-apt-repository ppa:
[16:33] <willcooke> Sweet5hark, cool
[17:14]  * didrocks waves good evening and good night
[18:04] <Laney> pancake time!
[18:04] <Laney> ttyl
[18:08]  * qengho thinks it's *always* pancake time.
[18:28] <mitya57> Here in russia it's pancake week :)
[18:30] <qengho> I guess for Swedes, it's only sweet-bun day.
[19:48] <desrt> attente leaves a valuable lesson today... don't make desrt review your patches
[19:48]  * desrt makes a review full of 'rename this variable' type comments
[19:49] <willcooke> I thought we just had to stamp everything WFM and approve it?
[19:49] <willcooke> Is that not policy now?
[19:49] <desrt> if it is, i'm happy to change my review :)
[19:50] <willcooke> hahaha
[19:50] <willcooke> I'm 97% sure Seb will be ok with that
[19:53]  * willcooke -< dinner


[00:03] <RAOF> SpamapS: With linux 3.1?
[00:12] <SpamapS> RAOF: been following this https://help.ubuntu.com/community/MacBookAir4-2
[00:13] <SpamapS> RAOF: not sure which magical thing it did to enable the graphics, but it disabled the touchpad :(
[00:13] <SpamapS> ahh
[00:13] <SpamapS> it patched bcm5974 for the 4,2
[00:14] <SpamapS> but the 4,1 only seems to work with the regular 3.0.0-12-generic version
[00:14] <SpamapS> all is well now
[00:14]  * SpamapS does a dance
[00:17] <SpamapS> XRANDR .. [check]
[00:18] <SpamapS> ooo suspend/resume even works
[00:18]  * SpamapS can actually consider *not* lugging his 15" MBP to UDS now
[00:19] <SpamapS> w00t
[00:25] <RAOF> @pilot in
[01:16] <RAOF> Bah.  It's really annoying that I can't change the status on any of these merge proposals.
[01:20] <micahg> RAOF: you need a tech board member most likely
[01:21] <RAOF> Yeah, I know.
[01:21] <broder> it's unfortunate that nobody actively working on udd is on ~ubuntu-branches
[01:21] <RAOF> Or to be a member of ubuntu-branches.
[01:21] <broder> otherwise i would advocate the "harass them until they fix it" approach
[01:22] <RAOF> James Westby's in ~ubuntu-branches :)
[01:22] <broder> i thought he was doing linaro stuff these dyas
[01:22] <RAOF> Oh, yeah.  He is, isn't he.  Damn!
[01:23] <ajmitch> that would make things a bit awkward
[01:24] <ajmitch> maybe the TB should be asked to look at the ownership of those branches
[01:48] <stgraber> RAOF: either poke me with the changes you want or make a list in your e-mail to ubuntu-devel (assuming you'll send one at the end of your shift)
[01:50] <RAOF> stgraber: Ta. I'll be sure to list them all in an email then.
[02:06] <smoser> how do i force debuild to create a .dsc that references the .orig file ?
[02:07] <micahg> smoser: -S -sa
[02:09] <smoser> thank you, kind sir.
[02:09] <micahg> you're welcome
[02:18] <wgrant> RAOF/micahg: Or escalate the bug.
[02:19] <RAOF> wgrant: Know what that bug is, offhand?
[02:19] <lifeless> broder: james_w is in online services now
[02:19] <wgrant> lifeless: Wha?
[02:19] <wgrant> When did that happen?
[02:19] <lifeless> danilo -> linaro
[02:19] <lifeless> james_w -> jml's offsider
[02:19] <wgrant> Ah, interesting.
[02:20] <wgrant> Makes sense, though :)
[02:20] <wgrant> RAOF: Bug #540250 looks relevant, but is meant to be fixed...
[02:21] <wgrant> Ahh.
[02:21] <wgrant> Now I remember.
[02:21] <wgrant> RAOF: What's an example merge proposal?
[02:21] <wgrant> Is it for a stable series?
[02:22] <RAOF> wgrant: Yes, I think they are.
[02:22] <RAOF>  is ahttps://code.launchpad.net/~om26er/ubuntu/natty/libdbusmenu/dbusmenu-fix-618587/+merge/71892n is an example.
[02:22] <wgrant> Right.
[02:22] <wgrant> That would be the problem.
[02:23] <wgrant> MP edit access is delegated to people with edit access on the branch. And upload permissions don't grant branch write access to stable series.
[02:23] <wgrant> Because those branches are meant to be frozen.
[02:23] <wgrant> I'm not sure if there is a bug for this...
[02:23] <RAOF> Aha.
[02:23] <micahg> smoser: you also want to use -vOLD_UBUNTU_VERSION when merging from Debian
[02:24] <wgrant> Bug #612391
[02:24] <wgrant> If you can escalate that, it might get done :)
[02:24] <smoser> micahg, thanks... too late though. i should have know that.
[02:25] <micahg> smoser: I try to remember to check the source.changes file to make sure the other entries are there before uploading
[02:26] <RAOF> wgrant: Sweet, thanks for that.
[02:53] <slangasek> YokoZar: multiarching -dev packages> that's not relevant, you don't get to build-depend on packages other than those for the current arch...
[02:53] <YokoZar> slangasek: Err yeah you're right, multiarch is the solution that works around that problem
[02:54] <YokoZar> slangasek: cause we build the 32-bit bits on 32 that have the 32 bit dev packages
[02:54] <slangasek> yep - at least, I hope it works around it :)
[02:55] <YokoZar> slangasek: do you know the status of OpenCL by chance?
[02:55] <RAOF> Just as long as the WoW64 stuff can use the 32bit build :)
[02:56] <YokoZar> RAOF: Yup.  I may have to do some weird copying in the package build script though, as we (unusually) want some files to be part of multiple packages here
[02:56] <YokoZar> RAOF: namely in the 32 bit package as well as the 32 bit foreign package
[02:56] <slangasek> the 32-bit package is not a different package than the 32-bit foreign package
[02:57] <slangasek> it's one package, built on i386 and installable on either i386 or amd64
[02:57] <YokoZar> slangasek: actually nevermind, that's the proper way to do it, have the 32 bit-only package depend on that too
[02:57] <slangasek> yep
[02:57] <slangasek> YokoZar: I don't think I know what opencl is
[02:58] <YokoZar> slangasek: It's the library for getting the graphics cards to do GPU tasks without actually being 3d rendering, if I remember right
[02:58] <slangasek> YokoZar: ok; not my department :)
[02:58] <micahg> slangasek: I thought that the amd64 buildds could use 32 bit packages, is that not correct?
[02:58] <YokoZar> Current Linux implementations may be driver specific (eg, only in the proprietary NVidia packages...despite the openness)
[02:59] <slangasek> micahg: nope
[02:59] <YokoZar> micahg: You can depend on a package that only has a 32 bit component, but you can't build-depend on that.
[02:59] <slangasek> micahg: there's no way to specify it in build-deps, for starters
[02:59] <micahg> slangasek: so how does one build a 64 bit app that has some 32 bit components?
[03:00] <YokoZar> micahg: The rationale for this that made the most sense when I was learning it to just imagine that each architecture has to be built separately and independently.  So things like cross-arch build-deps don't work, while binary dependencies do (unless your package itself is a reverse depends...)
[03:00]  * micahg thought wine was like that
[03:00] <slangasek> micahg: if it requires anything beyond the compiler and libc to build the 32-bit stuff, it should be done as an i386 package and use multiarch to install it
[03:01] <micahg> ok
[03:01] <YokoZar> micahg: This is why we're discussing Wine, as it needs some unusual splitting to make 64/32 mode work on 64.  The executive summary is the 32-bit parts are being built on 32.
[03:01] <YokoZar> whereas in oneiric they're built on 64 via ia32-libs
[03:02] <RAOF> YokoZar: What are you particularly interested in re: OpenCL?
[03:02] <micahg> I guess that makes sense, someone had a question a few weeks ago about pbuilder using the amd64 and i386 sources, I guess I gave the wrong answer (I thought that was normal for oneiric)
[03:02] <YokoZar> RAOF: Wine already has an implementation of it so any Windows app that uses it would need it to work
[03:04] <YokoZar> RAOF: I'm not sure what Windows apps use OpenCL off the top of my head though
[03:04] <RAOF> YokoZar: Ah, ok.  Currently there's no real solid open implementation standardised, which means there's no standard way to depend on it.  In the P+1 timeframe I'd expect us to have an open implementation, possibly even in precise.
[03:04] <YokoZar> RAOF: Well, I hope I can speed things along by being your use case then ;)
[03:08] <RAOF> Hm.  There doesn't seem to be a Khronos ABI for OpenCL.  Fundamentally it's likely that you'll end up wanting to Depend: or Recommend: libcl1 or somesuch.
[04:02] <pitti> Good morning
[04:02] <pitti> jcastro: right now it says "error updating", but will try later
[04:02] <ajmitch> morning pitti
[04:02] <pitti> hey ajmitch, how are you?
[04:02] <ajmitch> good, how are you?
[04:03] <pitti> pretty well, although still a bit tired, thanks!
[04:03]  * ajmitch wishes that the long weekend here was a few days longer :)
[04:23] <RAOF> @pilot out
[05:09] <pitti> doko_: FYI, keeping binutils in proposed queue, as the previous SRU hasn't been verified yet
[05:09] <pitti> doko_: if you want the second upload in -proposed now, please reupload with -v to include the previous changelog
[05:13] <pitti> slangasek: how did you build samba? http://launchpadlibrarian.net/83357418/samba_3.5.11~dfsg-1ubuntu2.1_source.changes doesn't have a Launchpad-Bugs-Fixed: header
[06:54] <micahg> pitti: FYI, bug 881250, SRU period might need to be truncated
[06:54] <pitti> micahg: yes, we generall move them to -updates right after verification, as they often tend to be urgent
[06:54] <pitti> there's a tzdata 2011m already
[06:55] <micahg> right, already in unstable
[07:07] <tkamppeter> pitti, are you not on the Sprint?
[07:07] <pitti> tkamppeter: no, I'll arrive on the weekend; only for UDS
[07:07] <tkamppeter> pitti, interesting, as technical lead of the desktop team.
[07:07] <dholbach> good morning! :)
[07:08] <pitti> tkamppeter: it's a DX sprint
[07:08] <pitti> tkamppeter: seb128 and didrocks are there
[07:08] <tkamppeter> pitti, OK, thought it was an all-Canonical Sprint.
[07:09] <tkamppeter> pitti, good to know to know who is in which time zone currently.
[07:46] <cjwatson> wgrant: I'm pretty sure it's not just that bug.  During the Oneiric release cycle, well after that bug was fixed, developers were unable to reject MPs for Oneiric branches.
[07:47] <wgrant> cjwatson: That's worrying. If you can find a current example, I would love to see it.
[07:47] <cjwatson> wgrant: Try bug 728012 instead.
[07:47] <micahg> cjwatson: he later added Bug #612391
[07:47] <wgrant> Let's see.
[07:47] <cjwatson> micahg: Indeed, but AFAIK this still happens for development series.
[07:48] <micahg> ah
[07:48] <cjwatson> wgrant: Unfortunately I have sufficient privilege that it's hard for me to hunt out an example myself, but I guess anything for precise on the sponsoring list should do it.
[07:49] <wgrant> The problem here is probably that upload permissions don't grant review privileges.
[07:50] <wgrant> And there's no review team set.
[07:50] <wgrant> So only ~ubuntu-branches has those superpowers... hm.
[07:50] <micahg> wgrant: here's an example: https://code.launchpad.net/~samuel-taylor/ubuntu/oneiric/pidgin-skype/fix-for-657125/+merge/75701
[07:51] <cjwatson> I think we'd like it to be keyed off upload permissions rather than setting a single team.
[07:51] <cjwatson> micahg: that's a released series
[07:51] <wgrant> cjwatson: Indeed.
[07:51] <micahg> I don't think I could've changed it before eitehr
[07:51] <wgrant> It currently checks for membership in one of (branch owner, branch reviewer, LP admin).
[07:51] <wgrant> Which made sense until package branches.
[07:51] <wgrant> Because branch editing was restricted to the branch owner and LP admins.
[07:52] <jamespage> does anyone know if there is a tool already in main that will convert markdown to html?
[07:52] <wgrant> So isPersonTrustedReviewer should probably just check if they can edit the branch or are in the review team.
[07:52] <micahg> I can change this one: https://code.launchpad.net/~barry/ubuntu/precise/ubuntu-dev-tools/bug-881049/+merge/80253
[07:53] <wgrant> micahg: To Approved/Rejected?
[07:53] <tumbleweed> jamespage: python-docutils
[07:53] <micahg> wgrant: no, but I don't think I can ever set those
[07:53] <wgrant> Right, that's the bug.
[07:53] <cjwatson> micahg: I can; that's the bug.
[07:53] <jamespage> tumbleweed: sweet - thanks for the pointer
[07:54] <micahg> cjwatson: wgrant: sorry for the noise
[07:54] <cjwatson> that's ok
[07:55] <cjwatson> man, switching from homegrown scripts to pull-lp-source and pull-debian-source has improved my life surprisingly much
[07:56] <pitti> I find them quite nice, saves having tons of deb-src lines
[07:56] <pitti> s/saves/avoids/
[08:22] <pitti> jcastro: guidebook seems better now, thanks!
[08:33] <jamespage> @pilot in
[08:34]  * dholbach hugs jamespage
[09:36] <\sh> doko_, do you mind when I take some of the  universe packages (from MoM) with your last uploader  name tag?
[09:36] <jamespage> why can I 'Reject' some merge proposal but not others?
[09:36]  * jamespage scratches his head
[09:46] <lifeless> jamespage: natty / not-natty
[09:46] <lifeless> jamespage: there is a bug.
[09:51] <doko_> \sh, not at all
[09:51] <doko> pitti, can we move the first one to -updates first?
[09:56] <pitti> doko: that's what happens by default if you don't want to replace the current SRU, yes
[09:56] <pitti> (still needs verification, as I said)
[09:59] <\sh> doko, thx
[09:59] <\sh> btw...are there any hints on how to fix format-security issues?
[09:59] <doko> pitti, done the verification
[10:05] <pitti> \sh: usually it's from something like printf(variable), i. e. handing a non-constant string to a function which evaluates % format codes
[10:05] <pitti> \sh: a common pattern is to prepend a "%s", if you really don't want interpolation
[10:07] <\sh> pitti: I just saw this error inside
[10:07] <\sh> pitti: I just saw this error inside a function which is using gtk_message_dialog_new
[10:08] <\sh> and I'm not sure if gtk_message_dialog_new(...,...,...,...,"%s",message) is enough
[10:08] <pitti> \sh: using "%s" for the message will work fine
[10:08] <pitti> \sh: as I said, it depends: if message is _supposed_ to have format strings in it, then this will break
[10:09] <pitti> but if it's not, then "%s" is fine; then any % characters in message will appear verbatim
[10:10] <\sh> pitti, kk :) thx :)
[11:48] <Daviey> !regression-alert
[11:48] <Daviey> bug 881361, impact not yet determined.  Non-default package.
[11:57] <Riddell> jasoncwarner_: can you approve the desktop-p-kubuntu specs for uds-p please https://blueprints.launchpad.net/sprints/uds-p?searchtext=kubuntu
[12:10] <jamespage> @pilot out
[12:10] <jdstrand> Daviey: mdeslaur is looking into it now
[12:17] <Daviey> jdstrand: yep, tracking in #ubuntu-server. Thanks.
[12:35] <mterry> @pilot in
[13:05] <sabdfl> hello folks
[13:06] <ogra_> hey sabdfl
[13:08] <pitti> hey sabdfl, how are you?
[13:08] <sabdfl> great thanks pitti, enjoying orlando already :-)
[13:09] <pitti> sabdfl: twisting^Wsprinting by the pool ♪ ♫ ?
[13:09] <ogra_> pitti, grrr, you implanted an earworm !
[13:09] <ogra_> :)
[13:09] <ion> Not to me.
[13:10]  * ogra_ guesses thats a matter of age :)
[13:10] <ogra_> or of musical taste
[13:33] <mdeslaur> pitti: it seems linux-ec2, linux-mvl-dove and linux-fsl-imx51 on lucid got binaries demoted to universe...was that intentional, or a script error?
[13:33] <mdeslaur> pitti: I got them moved now, but want to make sure it's not a script issue
[13:39] <GunnarHj> pitti: are you there?
[13:40] <jamespage> doko: OK if I pickup the jffi merge? its borked at the moment in precise
[13:42] <doko> jamespage, sure
[13:43] <jamespage> doko: ta
[14:25] <psusi> do I have to register for UDS if I'm not staying in the hotel ( I live nearby ), or can I just drop by?
[14:26] <ogra_> psusi, you should register in LP, so people know you are there and can i.e. subscribe you to sessions they want you to attend etc
[14:26] <ogra_> its not about the hotel, but about the automatic scheduler that needs to know you are there
[14:27] <psusi> ok
[14:27] <ogra_> 8unless you just want to hang out in corridors indeed :) )
[14:27] <jcastro> psusi: please register in LP, that's how they figure out the food and stuff
[14:28] <ogra_> oh, food, right :)
[14:28]  * ogra_ forgot about that unimportant bit
[14:30] <psusi> hehe.... I'm not sure how much time I can get away from work to get over there, but I definately want to do some meet and greet as long as everyone's in town
[14:30] <jcastro> that would be awesome
[14:37] <RoAkSoAx> is merges.u.c no longer been updated?
[14:37] <jbicha> I was surprised at my first UDS that lunch was included for all attendees, free OS and free food? sweet!
[14:39] <tumbleweed> RoAkSoAx: it should be. Don't forget we're syncing from testing
[14:39] <cjwatson> it's running right now, indeed
[14:39] <cjwatson> looks healthy to me
[14:39] <RoAkSoAx> tumbleweed: ahh right!!
[14:40] <RoAkSoAx> thought we were from unstable
[14:40] <tumbleweed> cjwatson: any opinions on bug 881288? you were vaguely around for that conversation...
[14:41] <cjwatson> I'm afraid I've been failing to get my head around the details of that thus far
[14:42] <cjwatson> it's probably better to bring it up with LP folks
[14:42] <tumbleweed> ok, I'll file a bug
[14:47] <hallyn> Was trying bzr merge-package again;  is there a reason why it doesn't first pop all quilt patches and rm -rf .pc in both trees?
[15:09] <slangasek> pitti: samba> oh, sorry, built it in a Debian env by mistake, forgot to watch out for the closure header
[15:10] <Daviey> slangasek: Hey!  Are you looking at the samba issue?
[15:10] <slangasek> Daviey: no
[15:11] <slangasek> I was looking at an unrelated samba issue
[15:12] <Daviey> slangasek: Would you be able to, please? :)
[15:12] <Daviey> over 100 dupes now :(
[15:33] <pitti> mdeslaur: no, of course not intentional -- it's the usual "LP picks random components" problem; I thought that would be uncovered during verification
[15:34] <mdeslaur> pitti: ok, cool, thanks
[15:54] <dobey> anyone notice any issues with builders? i uploaded something to my PPA 40 minutes ago, and LP is saying "Start 2011-10-26"
[15:55] <slangasek> Daviey: I certainly don't hold a maintainer lock on the Ubuntu package, I'm not sure why it waits on me - there seem to be several different proposals for addressing it, someone should just pick one and upload it?
[15:57] <Daviey> slangasek: Well, there reason i'm turning to you is because you were vocal in the discussion - and clearly understand the package and issue.
[15:58] <slangasek> Riddell: ScottK has a significant number of merges that he's TIL on for https://merges.ubuntu.com/main.html - with him taking a break, are these a concern for the Kubuntu team?
[15:58] <slangasek> Daviey: sorry, I probably should have just kept my mouth shut on the bug to begin with ;)  I was meaning only to provide a historical perspective of why the code is the way it is
[15:59] <rbasak> slangasek: this is also a Debian bug and you're a maintainer :-)
[15:59] <slangasek> rbasak: yeah, but the bug hasn't been tripped in Debian yet and I'm likely to be painfully slow about deciding how I want to fix it there
[16:00] <slangasek> so you guys should pick whatever fix that you think is appropriate to cover the gap now
[16:00] <Daviey> slangasek: Well, the frustrating thing is that we could have had 'a' fix before release, but we held back pending a better solution.
[16:00] <rbasak> slangasek: wouldn't it be nice if debian and ubuntu agreed how to fix it so we don't have to carry a delta and/or the delta gets carried upstream?
[16:00]  * Daviey launches a *sigh*
[16:01] <rbasak> slangasek: it's just a waste of effort if we fix it one way and then debian chooses to fix it another
[16:01] <slangasek> rbasak: it's easy enough to fix it twice and in the meantime it's causing pain for users
[16:01] <slangasek> so more effort is being wasted talking / worrying about it than would be wasted by implementing 2 different fixes
[16:02] <rbasak> Well I did submit a patch and it got rejected on the basis of being unsuitable. So I'm still waiting to hear from somebody what will be suitable.
[16:03] <Daviey> cjwatson: Do you have thoughts on this?
[16:03] <rbasak> Or should I just keep submitting patches without any feedback in the hope that one will be acceptable?
[16:03] <Daviey> It is really, really frustrating that we blocked on this for us to just throw anything into an SRU
[16:04] <infinity> rbasak: I don't think your patch would have fixed it anyway, after we investigated what was happening.
[16:06] <rbasak> infinity: fine, but that's not my point.
[16:06] <slangasek> Daviey, rbasak: frankly, I think the *right* fix is to make update-inetd more robust by not depending on perl-modules; but that's not quick, and won't necessarily help the current round of upgrade breakage
[16:06] <infinity> rbasak: Mangling update-inetd to not require perl-modules would certainly help, but it won't necessarily be upgraded before samba, which is irksome.
[16:07] <htorque_> hi all! i sent a mail to -devel which didn't yet come through. anything wrong with it?
[16:10] <cjwatson> Daviey: at this point I am not sure that adding another semi-informed opinion is going to help matters; too many cooks and all that
[16:11] <cjwatson> my opinion was to move update-inetd to the prerm, but AIUI slangasek had a reason not to do that
[16:11] <slangasek> I had a reason why I didn't think update-inetd in the prerm was actually the right thing to do
[16:11] <slangasek> doesn't mean it's not an appropriate workaround to fix users' upgrades in this case
[16:12] <infinity> Actually, it doesn't solve the upgrade issue.
[16:12] <slangasek> also, I'm still not sure update-inetd is guaranteed to be reliable in that case
[16:12] <infinity> It's not.
[16:12] <slangasek> because unpack perl -> unpack samba -> unpack perl-modules would still break
[16:12] <infinity> The real problem is that perl-modules is completely broken when it's half-configured during the 5.10->5.12 transition.
[16:13] <infinity> What's curious is that unpacking perl-modules 5.12 on a clean system allows update-inetd to work fine. :/
[16:13] <infinity> It's only the bizarre half-upgraded state that breaks.
[16:14] <infinity> Making the release upgrader forcefully re-order perl/perl-modules to upgrade as a unit might work around it, but it's obviously not the solution.
[16:15] <cjwatson> well, that's because the modules all move from /usr/lib/perl/5.10 to 5.12 ...
[16:15] <cjwatson> (isn't it perl-base/perl-modules that matters?)
[16:15] <infinity> Err, that.
[16:15] <slangasek> so as I look at the postrm, I'm actually not sure at all why the non-purge case is being handled here instead of in prerm
[16:16] <slangasek> and we probably should just move that
[16:16] <infinity> slangasek: Oh, I'm still convinced the maintainer scripts are a bit wrong, but either way, changing them won't actually make a difference here.
[16:17] <infinity> The synthetic reproduction of the bug isn't actually the bug that's being duped 100 times (the latter is an upgrade thing, not people removing/purging in weird orders)
[16:17] <Riddell> slangasek: we'll get them done right enough, although I'm on holiday for the two weeks after UDS so it may not be immediate
[16:17] <slangasek> yes
[16:18] <slangasek> Riddell: ok - no hurry, just thought I'd check if it's something on your radar
[16:18] <elgaton> Hi, I'm fixing a small bug (missing dependency in debian/control) and have a few questions: 1) should I generate the patch against the debian/ directory only (as explained in https://wiki.ubuntu.com/MOTU/Contributing) or a debdiff? 2) Since I need to get a sponsor for my patch and I'm working on the fix, is it right to subscribe ubuntu-sponsors and add the "patch" tag to the LP bug, but to set the bug status to "In Progress" and assign it to myself?
[16:18] <elgaton> Thanks.
[16:18] <slangasek> infinity: right - I just looked at tkamppeter's report, and see no perl, so perl-modules is already broken by that point
[16:21] <cjwatson> however, if it were in the prerm, then you could force things with Depends: perl, couldn't you?
[16:21] <slangasek> nope
[16:21] <infinity> Depends gives you unpacked, not configured.
[16:21] <slangasek> this is the "everything's ok, we're just upgrading and things are currently broken, don't mind our dust"
[16:21] <slangasek> infinity: er, no
[16:21] <rbasak> yeah I couldn't find a way to simulate what's happening during an upgrade as dpkg doesn't have an --unconfigure that I could find, so I had to do combinations of --purge and --unpack. So I triggered _a_ problem with the same root cause, but not the problem people are seeing
[16:22] <cjwatson> if you get the sequence of unpack/configure events, you could issue them by hand starting from a natty chroot
[16:22] <slangasek> infinity: depends is meant to give you configured; it's just that there are corner cases where configured doesn't mean usable. ;)
[16:22] <Daviey> (sorry for being absent, chairing a meeting)
[16:23] <slangasek> (because dpkg doesn't care that a dependency of an already-configured package has been removed)
[16:23] <cjwatson> slangasek: update-inetd configured doesn't mean usable in this case, but perl configured should
[16:23] <cjwatson> or maybe perl-modules configured
[16:23] <infinity> slangasek: Eh?  perl-modules is pretty clearly unconfigured in these upgrade logs.
[16:24] <slangasek> infinity: can you give me an example log?
[16:24] <slangasek> (that shows perl state)
[16:24] <Daviey> btw, there are two tracking bugs now
[16:25] <infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/856309
[16:25] <Daviey> bug 877852 is the second master bug (due to LP bug)
[16:26] <slangasek> infinity: oh, that's interesting; it shows both of perl and perl-modules unpacked at version 5.12
[16:26] <slangasek> and actually, at this stage there's no strong guarantee that the dependencies are even unpacked, let alone configured... only postinst gets that as a hard guarantee
[16:27] <slangasek> (but apt tries to DTRT)
[16:27] <slangasek> possibly the problem is perl-base not being unpacked yet?
[16:27] <infinity> slangasek: perl-base is configured.
[16:28] <slangasek> sure
[16:28] <slangasek> but not at the new version?
[16:28] <infinity> slangasek: Yes.
[16:28] <infinity> slangasek: Search through the terminal log.
[16:28] <slangasek> oh
[16:28] <slangasek> right, found it
[16:28] <infinity> slangasek: perl-modules is unpacked, perl-base is unpacked and configured, samba explodes, perl-modules is never configured.
[16:29] <slangasek> this is what we get for using unreliable interpreters like perl; let's rewrite update-inetd in python
[16:30] <infinity> I'm too sick to detect reliably if that was sarcasm.
[16:30] <slangasek> a pity
[16:34] <rbasak> I'm not sure it'd be that hard to rewrite update-inetd to not depend on perl-modules
[16:34] <rbasak> File::Copy: `cp`; File::Temp: `tempfile`. Well, close.
[16:36] <slangasek> infinity: right, I can't reproduce the problem by just plucking the relevant perl bits out of that log
[16:38] <infinity> slangasek: It's been a couple of weeks now, but ISTR it couldn't be reproduced by just unpacking perl-modules on a clean chroot, but could be reproduced by unpacking perl-modules 5.12 over perl-modules 5.10... Or something like that.
[16:38] <slangasek> infinity: I had perl-modules installed
[16:40] <infinity> Actually, what's responsible for setting @INC?
[16:41] <slangasek> dunno, but something clearly has it set to the old path
[16:43] <slangasek> the initial value appears to be embedded in libperl
[16:43] <slangasek> (where I would expect)
[16:43] <slangasek> so how can perl be 5.10.1 after perl-base 5.12.4 has been unpacked?
[16:43] <infinity> Except that libperl is unpacked at 5.12 at that point too.
[16:44] <slangasek> yeah, and if it wasn't, you'd get a linker error
[16:45] <infinity> Okay, so, perl-modules configuration is a red herring anyway, since perl-modules doesn't have a postinst.
[16:45] <infinity> unpacked == configured.
[16:49] <barry> jtaylor: ping
[16:58] <jtaylor> barry: pong
[16:58] <infinity> slangasek: Nevermind, I've gone crosseyed grepping that log.  libperl and perl-base are upgraded after samba's unpack failure.
[16:59] <infinity> slangasek: Which then leads to wondering why we get perl-modules upgraded so early, if it depends on perl (>= 5.12)
[16:59] <barry> jtaylor: hi.  i'm looking at merging m2crypto from wheezy and i have a few questions.  since you touched the package last i thought i'd ask you.  first, i don't want to step on your toes if you've already started working on this
[16:59] <infinity> slangasek: (Well, okay, perl gets unpacked early too, but libperl and perl-base don't come until much later -- after samba)
[17:01] <jtaylor> barry: with what do you ahve an issue?
[17:01] <jtaylor> I had actually hopped it could be synced for precise with the new debian maintainer
[17:02] <barry> jtaylor: second question: you removed proxylib.py because it was nonfree, but i don't see any bug report in ubuntu or debian about that.  wouldn't it be best to report that in debian and it get managed there?
[17:02] <barry> jtaylor: ultimately, that's my goal too
[17:02] <jtaylor> barry: yes it turned out to be free after all
[17:02] <barry> jtaylor: excellent, we can drop that delta
[17:02] <barry> jtaylor: i think we can also drop the dhpy2 and sslv2 deltas
[17:02] <jtaylor> I failed to remove it correctly (readded via a patch) but the debian maintainer asked the author who said it was free
[17:03] <infinity> slangasek: So, the reproduction steps would be "install perl 5.10 and update-inetd, unpack perl-modules 5.12, watch things (obviously) fail"
[17:03] <jtaylor> barry: one of the patches contains two seperate changesets
[17:03] <barry> cool.  so i just need to double check the d/control and d/rules changes you made and if those are in the debian version, then i think we can sync
[17:04] <barry> jtaylor: can you think of any other reason why we can't just sync?  (i'm guessing "no" since you suggested it above :)
[17:04] <jtaylor> does the debian package enable the tests?
[17:04] <barry> ah, maybe fix_kill_signal.patch too
[17:04] <barry> jtaylor: that's the d/rules change i need to double check
[17:04] <jtaylor> changelog does not mention it :/
[17:05] <jtaylor> bad, because 21.1-1 in debian was broken which would have been caught by the test
[17:05] <barry> yep, it doesn't run the tests
[17:05] <jtaylor> so no sync, the tests are important
[17:05] <barry> jtaylor: okay, i'll merge it and forward all the deltas to debian
[17:05] <barry> all *remaining* deltas
[17:05] <barry> jtaylor: thanks
[17:06] <jtaylor> this splits one patch into two http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/m2crypto/cosmetics/revision/25
[17:06] <infinity> And a cable guy is here.  Might lose internets intermittently for a while.
[17:06] <jtaylor> but I guess that should be in debian already
[17:08] <barry> jtaylor: i think so, but thanks for the link; i'll double check it all
[17:14] <slangasek> infinity: ah, right
[17:23] <hallyn> well this is odd.  I do a 'bzr merge-package', and it randomly removes some source files (which are all identical in both trees)
[17:24] <slangasek> hallyn: curious.  what branches?
[17:24] <hallyn> slangasek, lxc from precise and sid
[17:25] <hallyn> (I first did 'quilt pop -a; bzr remove .pc; bzr ci' in both)
[17:25] <hallyn> diff -Nrup src ../lxc-sid/src shows no differences before the merge-package attempt
[17:25] <hallyn> after, things like src/lxc/arguments.h go away
[17:27] <slangasek> hallyn: hmm, the 'bzr remove .pc' is going to cause problems later, given that you don't actually have access to push that change to the sid branch
[17:27] <hallyn> oh i dont want to push that to the sid branch :)  i just did 'bzr merge-package ../lxc-sid'
[17:28] <hallyn> then i'll quilt push -a; bzr add .pc'
[17:28] <hallyn> if i don't do that, then bzr gets all confuddled about the 'conflicts' in .pc
[17:28] <slangasek> right, but that means the branch you're merging doesn't match the UDD branch anymore
[17:28] <slangasek> so it will cause problems for future merges
[17:28] <hallyn> hm, it keeps track kof that?
[17:28] <slangasek> yes, the .pc conflicts are a horror, but doing it this way just defers the reckoning
[17:29] <hallyn> in the end i was probably going to just sling back a debdiff anyway :)
[17:29] <slangasek> ah
[17:29] <slangasek> if you're not pushing to *either* branch, then that's fine ;)
[17:29] <slangasek> but in that case, maybe MoM would be easier?
[17:30] <hallyn> i don't know, in the past bzr-mergepackage has don e agreat job (and now, apart from this glitch, debian/ is all settled for the sync)
[17:30] <hallyn> i've not used MoM though.  but purely by hand it was a bit hairy.
[17:31] <slangasek> bzr merge-package output (w/o munging .pc): The merge resulted in 28 conflicts. Please resolve these and commit the changes with "bzr commit".
[17:32] <slangasek> conflicts from MoM's merge: 14
[17:32] <hallyn> how does one run mom?
[17:32] <slangasek> 'grab-merge lxc'
[17:32] <slangasek> it downloads the pre-staged merge from merges.ubuntu.com
[17:32] <slangasek> (from ubuntu-dev-tools package)
[17:33] <hallyn> slangasek, ok, thanks - i'll try that for my next merge for practice.  For this one i think i'll just build the debdiff now and be done with it :)
[17:34] <slangasek> hallyn: and the Contents conflicts in src/lxc/ are because this is a new upstream version, meaning that there are *two* merges happening - first one for the upstream, then one for the packaging
[17:34] <hallyn> hm?  there shouldn't be a new upstream version
[17:34] <slangasek> hmm
[17:35] <slangasek> that's how the output reads to me, but I see that you're right
[17:35] <slangasek> ok, I don't know what's causing that conflict then
[17:35] <stgraber> hallyn: for LXC, the easiest is probably to just take the Debian package, re-apply the few patches we have on top of them (unless dlezcano feels like releasing ;)), re-add the upstart stuff and the cgroup-lite change (as I guess Debian doesn't have cgroup-lite yet), I guess that's pretty much it for LXC
[17:35] <slangasek> however, it is probably related to the 'criss-cross merge' warning at the top
[17:35] <hallyn> stgraber, yes, that's what it amounts to :)
[17:35] <hallyn> stgraber, i'll let you review if you don't mind
[17:36] <stgraber> hallyn: I guess we can probably convince Daniel to release a new LXC at the end of next week (assuming we'll push some more stuff to git at UDS), then our changes should be back to a minimal set
[17:36] <hallyn> stgraber, that'll be nice
[17:36] <stgraber> hallyn: sure, send me the debdiff and I'll review + upload if it looks good
[17:36] <hallyn> thx
[17:37] <hallyn> slangasek, i'll have to go read up on criss-cross merge later :)
[17:38] <slangasek> hallyn: summary: branch A merged into branch B, now you're merging branch B into branch A.  In this case, I think it's because the new upstream version was introduced separately on each branch
[17:38] <stgraber> hallyn: I also need to look at libnih again with James Hunt, once this one is ported to multiarch (he may have already done it on his laptop ;)), I'll commit support for containers using non-native architecture (using qemu + a multi-arch version of libnih and upstart)
[17:38] <slangasek> not an error at all, just means bzr's poor little brain sometimes gets confused about what it should do with such a merge
[17:38] <stgraber> hallyn: then we'll be able to use "-a armel" on x86 and get a working container
[17:39] <hallyn> cool
[17:39] <hallyn> i was meaning to look at libcap2 wrt multiarch.  haven't yet though.
[17:39] <slangasek> stgraber: yes, jhunt and I have multiarch libnih sorted out, I guess he'll be pushing soon
[17:40] <stgraber> slangasek: awesome! I might be able to show a working armel or powerpc container on x86 as a lightning talk on Friday then
[17:40] <stgraber> (unless I discover that something else than upstart heavily depends on ptrace() in our boot sequence :))
[17:40] <slangasek> heh
[17:41]  * slangasek thinks that over briefly
[17:41] <slangasek> nope, shouldn't be anything else
[17:42] <stgraber> well, obviously strace and gdb won't work in that container, but you already get that behaviour using a simple chroot with the qemu-<arch>-static stuff
[17:44]  * slangasek nods
[17:44] <slangasek> neither of those should be triggering at boot ;)
[17:55] <hallyn> stgraber, is linux-any a valid target in ubuntu debian/control?
[17:57] <hallyn> well, debuild doesn't warn me about it...
[17:58] <hallyn> vim syntax highlighting just doesn't like it maybe :)
[18:16] <geser> hallyn: yes, linux-any is valid and also supported by LP
[18:17] <hallyn> thx
[18:49] <mterry> @pilot out
[18:57] <adam_g> if i'm about to propose a merge for an SRU to a package that doesn't have an lp:ubuntu/$release-updates/pkg branch, do i just propose merge into lp:ubuntu/$release/pkg instead?
[18:58] <mterry> adam_g, yeah
[18:58] <mterry> adam_g, I think that's typical
[18:58] <adam_g> mterry: thanks
[19:05] <Daviey> adam_g: UDD is messed up for SRU's :/
[19:05] <Daviey> The target should be -proposed, but that would never have a -security upload in there, messing up the stacking.
[19:06]  * micahg wonders if one can branch from -updates and propose a merge against -proposed
[19:06] <maco> dont see why not
[19:07] <micahg> depends on how the branches are stacked on LP
[19:11] <slangasek> micahg: you can branch from -updates and propose a merge against -proposed *if there's already a -proposed branch to target*...
[19:12] <slangasek> it'd be really nice to be able to do UDD-driven SRUs - i.e., build-from-branch for all SRUs, so the SRU team just lands the branch to approve the upload
[19:12] <slangasek> but that's not high on the priority list, I think :)
[19:33] <hallyn> stgraber, our /etc/default/lxc has been storing MIRROR= for lxc-create (along with the RUN= for /etc/init.d/lxc).
[19:33] <hallyn> stgraber, with the new debian package, the pre-inst does 'rm /etc/default lxc' if that file has 'RUN=' in it
[19:34] <hallyn> stgraber, then it creates a new one in .postinst
[19:34] <hallyn> are we ok with that?
[19:35] <stgraber> hallyn: is it looking for ^RUN or for RUN? if it's simply looking for RUN, that means destroying a configuration file for everyone on upgrade which I really don't think we should do
[19:35] <stgraber> we could instead look at the md5 of the file or some similar approach to only replace it if it's indeed the exact same one that was shipped with the earlier version
[19:36] <hallyn>                 if grep -qs 'RUN=' /etc/default/lxc
[19:36] <hallyn> ok,
[19:36] <hallyn> so i'm thinking i'll just sed over the file to get rid of RUN ?
[19:36] <hallyn> i hate adding more delta from debian, but...
[19:36] <stgraber> why did he remove RUN= to start with?
[19:37] <hallyn> he switched to having /etc/lxc/local/ store data about autostart
[19:37] <hallyn> and now added LXC_AUTO=ture anyway
[19:37] <hallyn> true that is
[19:37] <hallyn> so really, i don't know
[19:37] <stgraber> fun...
[19:38] <hallyn> he's in #lxcontainers usually so we could ask him,
[19:38] <stgraber> I'm wondering why he's actually messing with it in postinst instead of just shipping the file as conffile and letting dpkg deal with it
[19:38] <hallyn> right.  dunno
[19:39] <hallyn> for that matter i don't know why he's changing the mechanism for choosing autostart containers anyway
[19:39] <stgraber> I'd much rather carry and extra delta with Debian than removing a user's configuration file without warning (or even changing it)
[19:39] <stgraber> *an
[19:39] <hallyn> ok.  so get rid of both?
[19:40] <hallyn> (pre+postinst)?
[19:40] <hallyn> maybe i should just push what i have to you, and let you decide :)
[19:40] <hallyn> it's all looking good aside from that bit
[19:40] <stgraber> yeah, I think the easiest is to get rid of that change and have the new init script check for RUN=yes instead of LXC_AUTO=true
[19:41] <hallyn> you think thta's better than shipping a new lxc.default with LXC_AUTO=true and letting the user decide (with comments inthe file to help)?
[19:41] <stgraber> oh, and that means that config files are no longer in /etc/lxc/auto/? what's that new /etc/lxc/local thing? ...
[19:42] <hallyn> iirc you symlink containers in there
[19:42] <hallyn> that you wnat autostarted
[19:42] <hallyn> no, wait
[19:42] <stgraber> hmm, in Oneiric I'd simply symlink their config into /etc/lxc/auto and they'll auto-start, that was working fine!
[19:43] <hallyn> no, debian/local is just for his own scripts
[19:44]  * stgraber starts to think we should just move the init script and all that stuff into the upstream branch and be done with it, no more distro delta ;)
[19:44] <hallyn> worth discussing at uds.  especially once we start introducing our own network bridge for default config :)
[19:47] <hallyn> stgraber, ok, LXC_AUTO defaults to true. but it's new.  so, should I just keep the same lxc.default we've had and avoid debconf questions, or should I add LXC_AUTO to our lxc.default so ppl know about it?
[19:47] <hallyn> in either case, I figure I'm nuking .preinst and .postinst
[19:47] <hallyn> (defaults to true if it's not in /etc/default/lxc, i mean)
[19:48] <hallyn> i'll add it in.
[19:53] <rbasak> slangasek: thanks, re: bug 862129
[19:58] <mwhudson> so my x220 completely reliably suspends and resumes
[19:58] <mwhudson> once
[19:58] <mwhudson> the second resume fails, 100% of the time
[19:58] <hallyn> stgraber, http://people.canonical.com/~serge/lxc-sync.debdiff is working for me
[20:03] <stgraber> mwhudson: do you have cgroup-bin installed? if so, replace it by cgroup-lite
[20:05] <mwhudson> $ dpkg-query -W cgroup-\*
[20:05] <mwhudson> No packages found matching cgroup-*.
[20:06] <mwhudson> although hm, now things are just being strange
[20:06] <mwhudson> i tried to reproduce using pm-suspend and it worked, but i'm on ac power now
[20:07] <soren> stgraber: If that were the problem, the second *suspend* would be failing, IIRC. Not the second resume.
[20:08] <mwhudson> and then i closed the lid and it didn't seem to suspend properly and when i opened the lid again it went to mirrored displays
[20:08]  * mwhudson filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881647
[20:08] <stgraber> soren: last I had this bug was a while ago, couldn't remember if it was the second suspend or resume that was hanging because of cgroup-bin :)
[20:09] <gord> my x220 suspends/resumes fine 100% of the time no matter how many times i do it =\
[20:09] <mwhudson> gord: oneiric?
[20:09] <mwhudson> hm
[20:09] <gord> yup
[20:09] <mwhudson> hm
[20:09]  * mwhudson remembers something else
[20:09] <mwhudson> gord: does shutdown/reboot work properly for you?
[20:10]  * hallyn doesn't have a single laptop, of many, that'll suspend/resume right now :(
[20:10] <gord> yeah all works fine
[20:11] <gord> saying that though the X220 has quite a few customisations you can make so we might just have different hardware
[20:11] <stgraber> hallyn: any reason you kept lxc.template and lxc.config?
[20:12] <mwhudson> gord: yeah, likely i guess -- i have i7, ssd, intel wifi
[20:12] <hallyn> the .template is just for his default/lxc tweaking script?  guess that can go.  I thought lxc.config had something to do with the -dbg or -dev package
[20:12] <gord> intel wifi here, i3 and hd
[20:12] <mwhudson> hm
[20:12]  * mwhudson plays around -- will probably drop off :)
[20:13] <hallyn> I see now
[20:13] <hallyn> my bad
[20:13] <hallyn> yeah both of those can go
[20:13] <stgraber> hallyn: lxc.config prompts the user for the debconf keys from lxc.templates, my understanding is that these two were used for the templating of the defaults file done by the scripts you removed
[20:14] <stgraber> hallyn: ok, removed and added a comment to the changelog, continuing the review :)
[20:14] <hallyn> stgraber: well, do you think we should rather keep the pre/postinst and add saving of MIRROR?
[20:14] <hallyn> I don't like all that code for something like that;  but ...
[20:16] <stgraber> hallyn: any reason not to move lxc-start-ephemeral to that new local directory?
[20:16] <hallyn> stgraber, no, and lxc-is-container coudl go there too
[20:16] <stgraber> ok, I'll move them
[20:16] <hallyn> is that location conventional?
[20:17] <stgraber> first time I saw that, I saw some others use debian/scripts/ too, I don't remember reading about a standard location
[20:18] <barry> any buildd admins around who can rescore a PPA build for me?
[20:18] <stgraber> I'm not too sure what to do with /etc/default/lxc to be honest, moving to debconf may be interesting but we need to make sure we don't end up prompting everyone who'll be upgrading from oneiric or lucid
[20:18] <stgraber> barry: link?
[20:18] <barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/2877224
[20:19] <barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/2877225
[20:19] <barry> (the first is amd64, second i386)
[20:19] <barry> stgraber: thanks!
[20:19] <stgraber> barry: there you go for a very small bump ;)
[20:20] <barry> stgraber: awesome, very nice! thanks
[20:20] <stgraber> hallyn: I'd be tempted to go without debconf for that initial merge, then if we feel the need, merge/extend that bit later in the cycle
[20:21] <hallyn> stgraber, if you don't want the user to be prompted, then we should undo the changes i made to lxc.default altogether?
[20:22] <stgraber> hallyn: I don't want to have them prompted when they didn't touch the config file. I'm fine with prompting them if they changed something
[20:22] <mwhudson> well that was a bit strange, it suspends and resumes fine on ac power
[20:23] <mwhudson> and pm-suspend is fine, but if i close the lid on battery power, then pm-suspend it oopses
[20:23] <hallyn> ok
[20:24] <stgraber> hallyn: any reason " debian/lxc.install - README gets (mis-)installed under --with-rootdir." isn't in Debian? doesn't that affect them too?
[20:25] <hallyn> no, bc they don't use --with-rootdir=/usr/lib/lxc/root
[20:25] <hallyn> which means, lxc-sshd wont' work for them
[20:26] <stgraber> ok
[20:26] <stgraber> hallyn: http://paste.ubuntu.com/719149/
[20:28] <hallyn> I assume lxcguest.install and lxc.install got updates reflecting the new locations for lxc-start-ephemeral and lxc-is-contaienr?
[20:28] <stgraber> I updated your section a bit and listed the changes I made
[20:28] <stgraber> yep, I dropped the lines from these two
[20:28] <stgraber> IIRC he simply copies everything from local to usr/bin
[20:28] <hallyn> great.  looks good, thanks.  regarding the README, of course I don't know WHY it ends up in .../root
[20:29] <hallyn> stgraber, thanks
[20:29] <stgraber> rest of the diff looks sane. I haven't looked at exactly what's changing in the diffs but that's what they have in Debian, so that should work :)
[20:30] <stgraber> I'll upload it now and will hopefully test it soon (need to upgrade a VM to precise, only have containers at the moment)
[20:30] <lifeless> hallyn: btw did I file a bug about rmmod working in containers ?
[20:30] <lifeless> [by default]
[20:31] <stgraber> lifeless: I'd be happy to +1 on that bug report ;) it's a major pain when upgrading containers
[20:31] <lifeless> stgraber: I have a rmmod iwlagn; modprobe iwlagn thing I run regularly.
[20:31] <lifeless> stgraber: my host is 64bit, containers 32bit.
[20:32] <lifeless> stgraber: finally I bind mount home into them, so I have a shared bash history...
[20:32] <lifeless> stgraber: guess what happened when I didn't check the host portion of my prompt, and my wifi did its 'I'm going to suck' thing.
[20:32] <stgraber> err, my eyes don't work today ;) I read mknod instead of rmmod which is a completely different issue though just as annoying :)
[20:32] <lifeless> stgraber: heh :)
[20:33] <stgraber> lifeless: oh, and what happened to the kernel when you did that? :)
[20:33] <lifeless> stgraber: anyhow, iwlagn was removed, then modprobe failed spectacularly
[20:33] <lifeless> I can't recall if it tried to insert the 32 bit version or quite what went wrong
[20:34] <stgraber> I've noticed something similar with my automated d-i testing in a container, d-i tries to modprobe/insmod quite a bunch of modules into my kernel ;)
[20:34] <lifeless> stgraber: yah, that will be similar
[20:34] <stgraber> for now I simply override modprobe and insmod with a simple "exit 0" ;)
[20:34] <lifeless> bug 850687
[20:34] <stgraber> hallyn: user namespaces will solve all that right? :)
[20:36] <hallyn> yup!
[20:36] <hallyn> they already solve that - you just can't then use the container :)
[20:38] <stgraber> hallyn: "can't then use the container", because of the VFS part?
[20:39] <hallyn> lifeless, stgraber, well if the modprobe/rmmod one seriously bugs you now, then we should push the fix into the package instead of wiating for an upstream release...
[20:39] <hallyn> i thought it ws just a security concern
[20:39] <lifeless> hallyn: bit of both
[20:39] <hallyn> stgraber, not just that, there are lots of places that we default to denying containers privilege to resources which they own anyway
[20:40] <hallyn> if i can get this last set of 8 patches into the kernel, then we can work on relaxing the security checks (and handling files)
[20:41] <stgraber> hallyn: did any of that patch that was written/pushed during the sprint make it to the kernel? I'd have thought the pid ns attach and reboot/shutdown one would be upstream by now...
[20:41] <hallyn> no, it didn't.
[20:41] <hallyn> daniel's laptop got stolen, and eric's been busy with his dayjob
[20:42] <hallyn> so both lxc-attach and reboot patches got lost
[20:42] <hallyn> i'm hoping we can push both again next week
[20:42] <slangasek> ouch
[20:43] <hallyn> yeah
[20:43] <stgraber> argh, didn't know for Daniel's laptop, that really sucks...
[20:43] <hallyn> that also postponed some merging of lxc patches
[20:43]  * hallyn tries hard to not be tied down to any one machine or phsyical location :)
[20:44] <stgraber> at least we have the patches on lkml/git, it's just going to be short if we want these upstream for 12.04
[20:44] <stgraber> unless we can convince our friend in the kernel team to carry these as an Ubuntu delta ;)
[20:44] <hallyn> a few 6-packs might help
[20:45] <hallyn> but, maybe I should see if we can prod to have those pushed this week
[20:45] <stgraber> if that's what it takes, I'm sure we can get some ARM server company to sponsor that :)
[20:45] <hallyn> excellent
[20:45] <stgraber> hallyn: lxc uploaded
[20:47] <barry> stgraber: that amd64 build is going in the wrong direction.  first 2 minutes, than 9 minutes, now 14 minutes 'til it builds :).  no need to change anything, i just thought it was funny.  the i386 build gave me the information i need.
[20:47] <hallyn> stgraber, great, thanks.
[20:48] <stgraber> barry: interesting ;) I'm guessing that's because the buildds are busy with long running builds
[20:49] <barry> stgraber: that, or there's a little robot on an exercise wheel behind lp's web ui, rolling dice and laughing at us.  your explanation seems more plausible, but i'm sticking to mine.
[20:50] <stgraber> :)
[20:53] <hallyn> stgraber, http://people.canonical.com/~serge/lxc-drop-sys_module.debdiff  (though that's against my tree, but apply against yours)  if you wanted to quickly push a fix for cap_sys_module too.
[20:55] <hallyn> (actually i wonder if dropping cap_mac_admin will end up breaking packages)
[20:55] <hallyn> (that'd be fun)
[20:55] <stgraber> hallyn: is cap_sys_module also restricting reading the module list  (lsmod)? just wondering as I think we want that change anyway, I'd just need to update my default config when doing d-i testing
[20:55] <hallyn> no. lsmod should still work
[20:56] <hallyn> i can lsmod as unprivileged user
[20:56] <stgraber> good
[20:57] <stgraber> what's cap_mac_admin doing? don't remember seeing that one before (do we have a list of all the cap_* somewhere? :))
[20:57] <hallyn> uh, sure - linux-2.6/include/linux/capability.h :)
[20:57] <hallyn> LSMs use that to gauge who can change policy
[20:58] <stgraber> got to love kernel documentation :)
[20:58] <hallyn> and mac_override, who can bypass it
[20:58] <hallyn> so I assume this will keep containers from loading apparmor policies.
[20:58] <hallyn> we need to talk to jjohansen at uds about apparmor namespaces and how to handle all of this, of course
[20:58] <hallyn> well, oneiric container starts up fine though (without those caps)
[20:58]  * hallyn installs apache2 as another test
[21:00] <stgraber> so we'd probably have to revert the cap_mac_* ones once we have the apparmor namespace change done in lxc or will that just work without the capability?
[21:00]  * stgraber has no clue how apparmor actually works (if that wasn't clear ;))
[21:01] <slangasek> in a way that is comically incompatible with how selinux works :)
[21:01]  * jjohansen reads back scroll
[21:01] <dobey> is there an update to make pbuilder/etc know about precise, on older Ubuntus yet?
[21:02] <barry> tumbleweed: rock.  thanks for the confirmation.
[21:02] <slangasek> (Debian bug #634081 is a beautiful thing)
[21:02] <tumbleweed> barry: you did make it nice and easy :)
[21:02] <sbeattie> stgraber: capabilities(7) contains an overview of what each capability is, though definitely not in enough detail.
[21:02] <barry> tumbleweed: :)
[21:02] <hallyn> stgraber, well, amusingly, cap_mac_admin will be targeted at the user namespace
[21:03] <hallyn> so we shouldn't have to relax the check *if* we can use them
[21:03] <hallyn> wait - no they wont
[21:03] <hallyn> so yes, probably :)
[21:04] <tumbleweed> dobey: running into any particular problems?
[21:05] <dobey> tumbleweed: i can't do pbuilder create to make a chroot for it?
[21:05] <tumbleweed> dobey: on what release?
[21:05] <dobey> on 11.04
[21:06] <tumbleweed> dobey: right. natty and maverick haven't got debootstrap backports
[21:07] <tumbleweed> I think there's also a ubuntu-dev-tools/distro-info thing I need to do for one or two of them
[21:08] <dobey> what's the best way to make a pbuilder chroot then? is there a base.tgz i can just download from somewhere?
[21:08] <geser> dobey: cd /usr/share/debootstrap/scripts && sudo ln -s gutsy precise
[21:08] <tumbleweed> what geser said :)
[21:09] <dobey> ah ok
[21:13] <stgraber> hallyn: I'm confused ;)
[21:21] <hallyn> stgraber, so yes, we may end up re-enabling mac_admin in containers
[21:22] <stgraber> hallyn: ok :)
[21:22] <stgraber> hallyn: I'll wait for LXC to build on everything, then push that extra change then
[21:22] <hallyn> depends on what we can do with apparmor namespaces
[21:22] <hallyn> stgraber, ok, thanks.  and hopefull i don't break anyone...
[21:23] <hallyn> (maybe libvirt in a container - but who'd do that? :)
[21:23] <stgraber> at least I seem to remember jjohansen being marked as essential for the LXC session at UDS, so we'll hopefully know more then
[21:24] <hallyn> yup
[21:24] <jjohansen> heh yeah I am planning on being there, but I can provide info now if you would like
[21:25] <jjohansen> currently apparmor need MAC_ADMIN to load policy
[21:26] <jjohansen> but I am more than open to discussion revisions/changes that maybe needed.
[21:30] <hallyn> jjohansen, are there any packages that will just fail to install or run without MAC_ADMIN?  or will they just not end up installing a policy?
[21:30] <jjohansen> hallyn: the packages shouldn't fail, but the policy will fail to load
[21:31] <hallyn> jjohansen, fwiw, if, when apparmor namespaces are done, a child namespace will be contained by an overall policy, then I think we can let containers have CAP_MAC_ADMIN.
[21:31] <hallyn> cool
[21:32] <jjohansen> right, even as they are right now the child namespace can't manipulate the parent's namespace with CAP_MAC_ADMIN, but that doesn't mean much as it has access to the rest of the system if it wants.
[21:48] <hallyn> jjohansen, i suppose i should check for any apparmor uds sessions too
[21:50] <jjohansen> hallyn: heh if your interested sure, but don't feel compelled, we can discuss lxc bits in lxc sessions, etc
[21:50] <hallyn> ok, great!
[22:24] <hallyn> hm, there seems to be a bug in tunctl.  'tunctl -u 1000' is *not* making 1000 own tapN