[08:51] <ppisati> ogra_: check your mbox
[08:53] <ogra_> damn, i dont have one
[08:53]  * ogra_ uses maildir :P
[08:53] <ppisati> :)
[08:54]  * XorA opens the gates to the religious mailbox format war
[08:54] <ppisati> jsalisbury tested Q/omap4 beta and he said the installer doe4sn't show up immediately, he needs to switch tty and back to get the screen
[08:55] <ppisati> ogra_: ^
[08:57] <ogra_> hmpf
[08:57] <ogra_> yeah, i see the mail
[08:57] <ogra_> i would suspect plymouth
[09:01] <ppisati> actually since we switched to a live installer we are already running unity dyring the install, right? so the pvr driver, right?
[09:01] <ppisati> *during
[09:04] <ogra_> we arent runing unity (ubiquity uses metacity and a simple gtk panel) but yeah. the pvr driver
[09:04] <ogra_> do we have a bug open for this ?
[09:05] <ppisati> no, because he just discovered it
[09:05] <ppisati> i can try daily image and fill a bug if you are too busy
[09:05] <ogra_> i heard something similar before and was alredy pondering to shipü an xorg.conf that forces fbdev during the installation
[09:06] <ppisati> shall i fill it against... plymouth? pvr?
[09:06] <ppisati> i'll try this one: http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap4.img
[09:14] <ogra_> pvr i guess
[09:29] <ppisati> ogra_: i've a blue screen
[09:29] <ppisati> ogra_: not smurf, really electric blue :)
[09:30] <ppisati> and indeed switching fixes it
[09:30]  * ppisati wonders if we have the same problem after the installation...
[09:32] <ppisati> ok, ubiquity exploded in my face so i couldn't finish the installation
[09:32] <LetoThe2nd> oO( *kaboom* )
[09:33] <xnox> ppisati: did you connect an external usb hard drive or the usb stick as installation target?
[09:33] <xnox> ppisati: which instructions did you use?
[09:33] <ppisati> xnox: installing on the sd card actually
[09:33] <xnox> ppisati: that won't work with 12.10 ;-)
[09:34] <ppisati> xnox: it did in the past iirc
[09:34] <xnox> ppisati: unless you pre-partitioned it.
[09:35] <xnox> ogra_: we need to update installation instructions on the wiki.
[09:35] <xnox> ogra_: as all the desktop install instructions talk about preinstalled tarballs, instead of live installer =/
[09:48] <ogra_> xnox, on my list :)
[09:50] <xnox> ogra_: on your list, yet it's me who gets the bugs assigned =)))))
[09:50] <ogra_> i'll try to get to it today
[09:50] <ppisati> lp 1065902
[09:50] <ubot2> Launchpad bug 1065902 in pvr-omap4 "black/blue screen before installer, tty switches fixes it" [Undecided,New] https://launchpad.net/bugs/1065902
[09:51] <ppisati> i'm doing a complete installation just to see if everything is ok after
[10:19] <ppisati> "an unrecoverable error... blablabla.. now a dekstop session will start so you can fix it"
[10:19] <ppisati> black screen again
[10:19] <ppisati> tty switch and there it is my desktop session
[10:24] <ppisati> rsalveti: i'm assigning the pvr part of 1065902 to you
[10:26] <ppisati> ogra_: you wanna take the plymouth part?
[10:50] <ogra_> infinity, hrm, the tegra driver ftbfs in dh_slibdeps now ... would you let the package in if i just completely override that step ?
[10:51] <ogra_> its not like it ever has done anything useful anyway
[10:51] <ogra_> (apart from moaning about the plugin libs)
[10:58] <infinity> ogra_: Or, you could tell it where to look for its libraries...
[10:59] <ogra_> well, it doesnt fail in a local precise build
[11:00] <ogra_> override_dh_shlibdeps:
[11:00] <ogra_>         dh_shlibdeps -l${PWD}/debian/nvidia-tegra/usr/lib/nvidia-tegra
[11:00] <ogra_> something like that ?
[11:00] <infinity> Indeed.
[11:00] <infinity> Should shut up all the warnings, and the two errors.
[11:00] <infinity> Or three, or however many there were.
[11:01]  * ogra_ tries
[11:01] <infinity> No need for the ${PWD}/ bit, though, you should always be relative to the package build dir.
[11:01] <infinity> -ldebian/foo/bar is enough.
[11:02] <ogra_> well, still warnings about the missing SONAMEs
[11:02] <ogra_> in the plugin libs
[11:03] <infinity> Hold on, let me look at this for a sec.
[11:04] <infinity> Gah, why is that in universe?
[11:04] <infinity> ogra_: Will your world explode if I move it where it belongs?
[11:05] <ogra_> not at all
[11:05] <ogra_> dunno why it landed there
[11:05] <ogra_> it used to be in restricted
[11:05] <infinity> It's in universe in precise too, so I guess someone just messed up way back when. :/
[11:05] <infinity> Oh well, moving it in Q.
[11:06] <infinity> To multiverse, not restricted.
[11:06] <ogra_> k
[11:07] <ogra_> i wonder if dh_shlibdeps got more strict in quantal
[11:07] <ogra_> i cant reproduce the error at all in precise
[11:09]  * infinity downloads some build-deps.
[11:09] <infinity> dpkg-shlibdeps may have gotten stricter, I wouldn't consider that a bad thing.
[11:10] <ogra_> i didnt say its bad :)
[11:16] <infinity> Right, -l/usr/lib/nvidia-tegra does the trick (no need for the leading debian/pkg at all)
[11:16] <ogra_> ah, k
[11:16]  * ogra_ adds that then
[11:16] <infinity> And the mess of warning about the missing SONAMEs seems like a nice reminder that it's broken. :P
[11:18]  * infinity tests with the override in debian/rules
[11:18] <infinity> Yup, perfect.
[11:19] <ogra_> k
[11:19] <infinity> As "useless" as it may seem, it's nice that it'll yell at you if you don't have the right build-deps (and thus don't get the right dependencies), so taking it out feels wrong.
[11:19] <infinity> And this DTRT.
[11:19] <ogra_> yeah
[11:19] <ogra_> and there is hope they fix it eventually :)
[11:24] <ogra_> meh, i should teach my finger memory to not always use -sa for dpkg-buildpackage
[11:24] <infinity> I always forget it when I need it.
[11:24] <infinity> Which is rarely.
[11:25] <ogra_> well, you need it for all native packages
[11:25] <ogra_> we used to have a lot of them when i started :)
[11:42] <infinity> ogra_: Eh?  No native package needs -sa
[11:43] <infinity> ogra_: You only need -sa on a new upstream version of a NON-native package (ie: with an orig) that dpkg doesn't auto-detect as a new upstream (so version doesn't have -0 or -1 on the end).
[11:44] <infinity> ogra_: So, commonly in Ubuntu when doing merges from, say, 1.2.3-4ubuntu1 to 1.2.4-2ubuntu1 instead of 1.2.4-0ubuntu1
[11:47] <ogra_> yeah, i thought it was also used to attach the native tarball ... seems i was wrong :P
[11:47] <ogra_> but that would be nonsense thinking about it :P
[11:48] <xranby> infinity: ogra_:  i would consider it a bug dch -i to not detect and use a  0ubuntu1 name when appropriate
[11:49] <ogra_> well, it never detects if i work on a native package
[11:49] <infinity> xranby: Hrm?  This isn't about dch.
[11:49] <ogra_> but always attaches -XubuntuX
[11:50] <infinity> xranby: I was talking about merging and intentionally versioning in a way that won't be -0 or -1 (which is common when merging to, say, Debian's 1.2.3-4)
[11:50] <xranby> infinity: ok i get it
[11:50] <infinity> ogra_: Really?  I thought dch was smart enough these days to version natively.
[11:50] <ogra_> doesnt for me
[11:50] <infinity> ogra_: If not, THAT is a bug for sure.
[11:50] <xranby> infinity: dch -i always increast the unmber, it never resets the number when the major version differs
[11:51] <ogra_> well, i might have some old dotfile somewhere with weird settings tr so
[11:51] <ogra_> *or
[11:51] <infinity> It sure works for me.
[11:51] <infinity> I just did a dch -i on apt (<IP_ADDRESS>) and got (<IP_ADDRESS>ubuntu1)
[11:52] <infinity> Which is right.
[11:53] <infinity> xranby: I'm a bit confused as to what you're on about. ;)
[11:53] <infinity> xranby: Up until just now, we were talking about dpkg-genchanges -sa, which has nothing to do with dch's versioning.
[11:53] <xranby> we are surely talking about different things,, yesterday i did a dch -i on avian_0.6+20121011   and got 0.6+20121011-0ubuntu2      instead of 0.6+20121011-0ubuntu1  http://bazaar.launchpad.net/~xranby/ubuntu/quantal/avian/avian_0.6+20121011/revision/4#debian/changelog
[11:54] <xranby> when switching from 0.6+20120911 to 0.6+20121011
[11:55] <infinity> That was driver error.
[11:55] <infinity> You did a uupdate or something first, then a dch -i
[11:55] <infinity> The first thing got the version right, then dch -i did what you asked (increased the version number).
[11:55] <xranby> no update
[11:55] <infinity> Then how did you update from 0.6+20120911 to 0.6+20121011?
[11:55] <infinity> dch doesn't autodetect upstream versions.
[11:56] <xranby> infinity: i got the new name 0.6+20121011  when i did a bzr branch avian.dev avian_0.6+20121011
[11:56] <xranby> and dch -i picked up that
[11:56] <xranby> based on the branch nam
[11:56] <xranby> e
[11:58] <infinity> Still sounds like something, somewhere, filled in a skeleton changelog entry first, and dch -i then increased it.
[11:58] <infinity> (I just did this to myself yesterday..)
[12:01] <xranby> hmm i have to double check next time i update
[12:02] <xranby> you might be right it might be one of those things you do without reflecting about it
[12:02] <xranby> I do
[12:04] <xranby> not to something completly different: When usability fail: The "mouse wiggler" a "new invention" used at a Swedish hospital to prevent inactivity auto-logout http://www.flickr.com/photos/henrikahlen/sets/72157631580658085/
[12:04] <xranby> now
[12:05] <infinity> ogra_: So, after all that pointless prattle, do I get a new upload? ;)
[12:05] <ogra_> err, yeah
[12:05] <ogra_> just noticed i missed to s/precise/quantal/ in my build
[12:06] <ogra_> lets do it without -sa this time :)
[13:37] <ogra_> bug 1065902
[13:37] <ubot2> Launchpad bug 1065902 in linux-ti-omap4 "black/blue screen before installer, tty switch fixes it" [Medium,New] https://launchpad.net/bugs/1065902
[18:45] <nOStahl> hi guys
[18:45] <nOStahl> whats going on with the ubuntu on android thing?
[18:45] <nOStahl> the page has not changed on ubuntu.com for a long time since I first seen it
[20:03] <GrueMaster> Given that unity-2D is dead, probably not much.  Not sure how well Unity runs on an Android system.
[20:04] <nOStahl> the site says it boots up full ubuntu
[20:05] <GrueMaster> Well, iirc it is more like an ubuntu chroot running on an android system.  That way, the two can communicate with each other.
[20:06] <nOStahl> ah ya that makes some sense
[20:06] <nOStahl> i'd love to have one device that I take with me and dock it in a workstation or in some form of lapop device
[20:08] <prpplague> GrueMaster: any idea who is in charge of u-boot/SPL for pandaboard at canonical right now? we have some memory change patches in the pipe for the next revision of the OMAP4 based pandaboard
[20:09] <ogra_> prpplague, jcrigby
[20:09] <prpplague> ogra_: ok thanks
[20:09] <ogra_> (unless that changed and i missed it)
[20:09] <GrueMaster> prpplague: I'm no longer at Canonical.
[20:09]  * prpplague makes a note
[20:09] <prpplague> GrueMaster: yea i keep forgetting
[20:09] <prpplague> GrueMaster: i don't know who is where these days in relationship to canonical/linaro/ubuntu
[20:10] <GrueMaster> It seems to be changing a bit lately.
[20:10] <ogra_> we're all ubuntu :)
[20:10] <ogra_> only few are linaor or canonical :(
[20:10] <ogra_> err
[20:10] <ogra_> :)
[20:11] <prpplague> jcrigby: ping
[20:11] <prpplague> jcrigby: need to start getting a plan together to handle questions / upgrades for u-boot
[20:30] <st3fan> i got Ubuntu 12.04 running on a Pandaboard \o/
[20:31] <st3fan> do i need special drivers now? or is it all included?
[20:31] <st3fan> also, is there a correct way to upgrade to 12.10?
[20:58] <ndec> prpplague: for uboot/spl patches please talk with sebjan too.
[20:58] <ndec> and send them upstream too ;-)
[20:59] <prpplague> ndec: yea, already working on the upstream, i am more concerned about people trying to use older ubuntu releases for pandaboard and it not working
[20:59] <ndec> for older release... it will be a problem since the bootloader is in the released image.
[21:00] <ndec> and new images aren't created after they are released...
[21:00] <ndec> so, if old uboot reallly doesn't boot on new board, 12.04 image will not boot.
[21:00] <ndec> and 12.10 either.
[21:01] <ndec> well, 12.10 there is a slight window to get that done before the release, though...
[21:01] <prpplague> ndec: yea, there was some update procedure that was documented for the pandaboard-es to update the bootloader , so i figured there would be something we could document
[21:01] <prpplague> ndec: yea totally different mem config, it won;t boot without the change
[21:01] <ndec> yep, we did that a couple of times indeed.
[21:01] <ndec> it's basically -> prepare SD, and copy the magic MLO on SD.
[21:02] <ndec> prpplague: what's this change about? and why?
[21:03] <prpplague> ndec: the memory that is currently used on the pandaboard and pandaboard-es is EOL'd as of the end of this month
[21:03] <prpplague> ndec: we have enough stock to last till mid feb
[21:03] <ndec> bummer.
[21:03] <prpplague> ndec: the only available configuration as a replacement is a totally different die/bank configuration
[21:04] <ndec> you can detect the config at runtime, right?
[21:04] <ndec> so that same MLO works on new and old, right?
[21:08] <prpplague> ndec: yes we can detect if it is a new board or old board, however the MLO(SPL) needs to be updated with the new EMIF/LISA configurations
[21:08] <prpplague> ndec: i thought you were gone for something called "weekend", hehe
[21:11] <GrueMaster> That sounds like a simple patch to a lookup table, and maybe some init code.  Should be fairly straight-forward.  YOu could always file a bug against MLO and file a patch with it.
[21:12] <ndec> prpplague: i should be gone indeed...
[21:12] <prpplague> GrueMaster: yea code wise it is trivial
[21:13] <prpplague> GrueMaster: my concern is the coming support issue, "i just got my pandaboard and it doesn't boot ubuntu 12.04"
[21:14] <GrueMaster> Since 12.04 is LTS, this fix should be able to be backported.  Not sure what the release schedule is for 12.04.2, but it will have to wait until then to show up in an image.
[21:16] <ndec> GrueMaster: that said, images weren't rebuilt for 12.04.01 for panda...
[21:17]  * ndec really starts weekend now ;-)
[21:18] <GrueMaster> They weren't?  sigh.  Slackers.
[23:03] <xnox> GrueMaster: ndec: the images were build, they failed testing hence could not be released.
[23:03] <xnox> no sign-off, no point release image.
[23:03] <xnox> image, per-image.
[23:04] <xnox> but boy 12.10 is so much better on Pandaboards =)
[23:07] <st3fan> xnox: how do i test 12.10 now? (i see no images)
[23:07] <xnox> st3fan: they are on cdimage
[23:08] <xnox> st3fan: http://cdimage.ubuntu.com/daily-live/current/
[23:08] <xnox> note you need USB storage to finish the install.
[23:08] <GrueMaster> Failed testing?
[23:09] <st3fan> xnox: ah yes i think i did try that .. i was unable to install it on SD card and was not sure how to fix that
[23:09] <st3fan> i'm currently using the preinstalled 12.04, which works great
[23:09] <xnox> it's slow on the IO though.
[23:10] <xnox> no more preinstalled images.
[23:10] <st3fan> yeah i notice that
[23:10] <xnox> hence you install from sd card onto usb stick or usb HDD
[23:10] <xnox> with quantal onwards.
[23:10] <xnox> you can "do preinstall"
[23:10] <st3fan> aha
[23:11] <st3fan> i was thinking of buying a small SSD and USB/SATA adapter
[23:11] <xnox> basically after creating sd card, create a new partition at the end.
[23:11]  * xnox uses 32 GB tiny pen drive ;-)
[23:11] <st3fan> is that faster than SD?
[23:11] <xnox> yeah.
[23:11] <GrueMaster> Hmm.  Doesn't look like 12.04.1 was even generated, according to http://iso.qa.ubuntu.com
[23:11]  * xnox has fast usb stick though ;-)
[23:12] <st3fan> how does a pandaboard boot from usb though? it needs help from a bootloader on SD right?
[23:12] <GrueMaster> st3fan: Bootloader stays on SD.
[23:12] <xnox> st3fan: so the sd card you used for the install .... becomes boot floppy as panda only boots from there.
[23:13] <st3fan> this sounds good :)
[23:13] <xnox> so you need both to install & both to continue running panda.
[23:13] <GrueMaster> Well, you could also drop a bootloader through the mini-usb from a host.
[23:13] <GrueMaster> It actually looks there first, SD second.
[23:14] <st3fan> do i need to configure the bootloader manually or will that happen as part of the installation?
[23:15] <GrueMaster> It will (should) just work.
[23:15] <st3fan> these are great hints. i'm going to try this after dinner with 12.10b2
[23:15] <GrueMaster> If not, file a bug.  If it doesn't install proeprly, it shouldn't be shipped.
[23:15] <st3fan> or daily?
[23:16] <xnox> st3fan: don't try b2, use daily. The current daily is frozen and is the testing candidate for quantal final.
[23:16] <st3fan> yay
[23:16] <xnox> st3fan: plus you will help testing quantal final =)
[23:16] <st3fan> ok
[23:16] <st3fan> i will bbl
[23:22] <infinity> xnox: You're misinformed.  12.04.1 ARM images weren't built at all, as we only build point-release images for LTS products, and only the netboot images are LTS for ARM.
[23:22] <infinity> xnox: Not that it would matter, the 12.04 images would work just fine, and one could apt-get upgrade.
[23:23] <xnox> infinity: ok. sorry.
[23:23] <infinity> xnox: Oh, I read more backscroll, I see.  So, the 12.04 images will stop working at some point. :P  But we can still build new d-i (and will), so that's the direction to point people in.
[23:23] <xnox> thanks.
[23:24] <infinity> xnox: And d-i is the direction I point people in anyway, since it's the only way to install directly to USB in precise.
[23:25] <xnox> i point people to quantal =)
[23:26] <infinity> Some people (like, I dunno, our buildds) have a legitimate use-case for wanting an LTS. :)
[23:26] <xnox> infinity: for whatever reason people are expecting a much higher volume of SRUs for precise.....
[23:27] <infinity> I don't mind the attempt to perfect LTSes, personally.
[23:28] <infinity> Maybe because I run them. :P
[23:29] <GrueMaster> infinity: I think the reason this came up was due to the expected change to the pandaboard memory, wich will need a new MLO.  If the images aren't respun, then they will fail.  Easy enough to download an updated MLO and drop it in place.
[23:29] <infinity> GrueMaster: Yeah, I caught that and commented on it.
[23:30] <infinity> GrueMaster: We still won't respin the preinstalled images, but debian-installer will get bumped for new netboot love.
[23:30] <infinity> (And, as you say, it's not rocket science to do surgery by hand on the preinstalled ones, if someone really prefers those)
[23:30] <GrueMaster> I'm...not going to comment.
[23:35] <infinity> GrueMaster: (If the whole new MLO thing happens, I could probably be talked into building a Panda/preinstalled image for 12.04.2 if someone communityish wanted to QA it)
[23:35] <infinity> GrueMaster: You could totally get them to send you a new-new-new Panda just for this, and expand your dusty collection. :)
[23:36] <GrueMaster> When is 12.04.2?
[23:37] <GrueMaster> And considering I had to personally buy the last 4 pandas I got, I doubt I will be motivated to do this.
[23:37] <GrueMaster> (note, I could have expensed them, but then I would have 0 dusty pandas and absolutely no reason to be here).


[01:29] <highvoltage> how is everyone doing?
[04:07] <nUboon2Age> akgraner, i just figured out what was causing the problem -- etherpad wants to set a cookie.  problem solved.
[04:14] <akgraner> nUboon2Age, great glad you got it figured out :-)
[04:16] <nUboon2Age> yeah it was puzzling, but then i realized i'd tightened my security on cookies and that' what was causing it.
[04:16] <zkriesse> wazup ya'll
[08:15] <alourie> good morning
[08:23] <akgraner> good morning!
[08:24] <akgraner> Hey all I am going to grab a few hours of sleep - If you all can check Issue 212 for spelling errors that would be great...
[08:24] <akgraner> I think I have all the content added and I have double checked the links all I need to do now is add the in this issue  - I'll do that when I get up in a few hours and get this published early in the am :-)
[08:25] <akgraner> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue212
[08:25] <akgraner> Feel free to make the spelling or camelcase fixes - for anything else let me know here and I'll look over it in a few hours
[08:25] <akgraner> thanks y'all
[08:26] <akgraner> alourie, I'll ping you after I've had some sleep and we can figure out where you can help :-)  (Thanks again!)
[08:31] <alourie> akgraner: thanks Amber
[08:31] <alourie> I'm her
[08:31] <alourie> e
[14:22] <akgraner> Good Morning :-)  Did anyone review Issue 212 yet?
[14:25] <highvoltage> it's ready for review already!? wow :)
[14:27] <highvoltage> akgraner: heh, I had some of those planet feed items in there but took them out since you said that the planet section should just be 6 items or so
[14:28] <akgraner> I know :-/
[14:28] <akgraner> people are writing some good stuff  - so I'll take the hit it people complain about it being to long
[14:29] <highvoltage> akgraner: I think the typical audience for UWN are people who are hungry for information and would rather have a bit too much than a bit too little
[14:29] <akgraner> IF it's too long people complain and if I don't opt to include stuff people complain - just look for a week with the least amount of complaints :-)
[14:31] <highvoltage> I think people who complain it's too long are just lazy. Reading just the headings takes less than 30s. If you're interested in something you can read more about it
[14:31] <akgraner> highvoltage, the audience is very varied and I have to balance it with where it is syndicated as well
[14:32] <akgraner> ie LWN
[14:33] <akgraner> I just have to not worry about the noise and listen to their points and see what's valid and what is just noise :-)
[14:33] <akgraner> So did anyone review it for spelling errors or camelcases?
[14:33] <akgraner> If not I need to do that now and get this published?
[14:33] <akgraner> App Developer Week Starts today so I need to get this out before then
[14:35] <highvoltage> akgraner: I gave it a quick read-over and didn't see anything that's glaringly wrong, I'm on phone with client atm so don't quite have the bandwidth to do it properly, but it looks good from what I can see
[14:35] <akgraner> highvoltage, thanks!
[14:35] <alourie> good morning akgraner
[14:35] <alourie> slept well?
[14:37] <akgraner> yep got 4 hours or so :-)
[14:37] <alourie> 4 hours of sleep??
[14:37] <alourie> wow
[14:37] <alourie> that even I do not do :-)
[14:38] <akgraner> usually I don't but I am try to get into a "normal" sleep cycle - whatever that may mean
[14:38] <alourie> 4 hours is normal?
[14:38] <akgraner> I was getting very cranky and not very nice - so I am trying to get a way for the computer and get more efficient with the time I do spend online
[14:39] <akgraner> nope but more normal than 2 or none
[14:39] <alourie> :-) indeed
[14:44] <alourie> akgraner: got coffee? I don't want you to get cranky and not nice :-)
[14:45] <akgraner> hehehe
[14:46] <akgraner> I do -  chocolate raspberry coffee  - yum-o
[14:46] <akgraner> give me just a few getting all the reminders out to the session leads for App Dev Week then when Pendulum gets through reviewing Issue 212 I'll publish it...
[14:51] <alourie> sure
[14:51] <alourie> take your time
[14:53] <Pendulum> akgraner: looks good to me
[14:55] <akgraner> Pendulum, thanks!
[16:08] <alourie> akgraner: so, got a sec?
[16:08] <akgraner> yep
[16:17] <alourie> this is regarding the help thing
[16:18] <alourie> I vaguely remember you posted something like that few weeks ago
[16:21] <akgraner> I did
[16:21] <akgraner> what areas of UWN interest you the most- like what stories do you tend to follow more than others
[16:22] <akgraner> alourie, ^^^ sorry was watching -classroom
[16:26] <alourie> akgraner: well, I like the press, blogosphere, other news and sneak peeks
[16:28] <akgraner> alourie, want to start out and work on In the Press - there is another guy internalkernel who helps with that section as well I am sure he would like to know someone else is helping with that section as well
[16:28] <akgraner> he travels a couple months so it gets tricky for him sometimes (like all of us)
[16:29] <alourie> akgraner: sure. How do we do that?
[16:30] <alourie> akgraner: I mean, is there a list of things we go through, or we just look for the information all around?
[16:30] <akgraner> alourie, can I email you?
[16:30] <alourie> akgraner: absolutely
[16:31] <alourie> akgraner: djay.il at gmail.com
[16:31] <akgraner> awesome - I'll get you all that in just a few hours  :-)
[16:31] <akgraner> If you don't have it by the am please nudge me :-)
[16:32] <alourie> akgraner: sure. I'll ping you :-)
[16:32] <alourie> thanks
[23:11] <akgraner> The new edition of the Ubuntu Weekly Newsletter is now available here:
[23:11] <akgraner> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue212
[23:38] <akgraner> Another awesome week you all!  Issue 212 has been published the -news mailing lists and the announcement that it is available has been sent to various mailing lists, posted in the various IRC channels, as well as The Fridge, The Planet, and The Forums and we are ready for a new week in Ubuntu News - Thanks agian!
[23:38] <akgraner> Issue 213 will cover September 26th-October 2nd, 2010
[23:38] <akgraner> Here are the links for working on next weeks issue:
[23:38] <akgraner> * etherpad for adding summaries -  http://pad.ubuntu-uk.org/UWN
[23:38] <akgraner> * etherpad for adding links and titles only - http://pad.ubuntu-uk.org/UWN-Ideas
[23:38] <akgraner> * googledoc - https://docs.google.com/Doc?docid=0AdKZelXU8Y2LZGNrcHRkYmhfODlkODNxNnRnZA&hl=en
[23:38] <akgraner> * wiki page - https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue213
[23:39] <akgraner> Many Many Thanks!


[00:16] <TheMuso`> robert_ancell_: Thats difficult, because its difficult to transition users from using one shortcut to another. The installer still offers both, although the desktop uses the newer shortcut, super + alt + s. Probably worth changing to be consistant.
[00:16] <robert_ancell_> TheMuso`, so should we make u-g do both in trusty?
[00:16] <robert_ancell_> seb128 was concerned about changing the existing key combo
[00:17] <TheMuso`> robert_ancell_: Is that hard to do? Afaik we offer the shortcut via the menu shortcut stuff atm.
[00:18] <TheMuso`> robert_ancell_: Particularly since the menu shows the shortcut as well.
[00:18] <robert_ancell_> TheMuso`, harder than backporting the fix but shouldn't be too hard to change the default to alt+ctrl+s and also support ctrl+s
[00:18] <TheMuso`> Alt + super + S, and yeah sounds good.
[00:18] <TheMuso`> as well as control + s.
[00:19] <robert_ancell_> yeah, that one :)
[04:56] <pitti> Good morning
[04:58] <desrt> hello pitti
[05:00] <pitti> hey desrt, how are you?
[05:00] <desrt> okay
[05:00] <desrt> just writing some NEWS
[06:04] <didrocks> good morning
[06:08] <pitti> bonjour didrocks, ça va ?
[06:15] <larsu> good morning!
[06:16] <didrocks> pitti: ça va bien, et toi ?
[06:16] <didrocks> good morning larsu !
[06:20] <didrocks> hum, keybindings don't work, restarting session
[06:20] <didrocks> and while I'm at it, rebooting under upstart for a test
[06:24] <larsu> good luck ;)
[06:24] <didrocks> interesting, pressing escape on plymouth even on upstart just shows a blank screen, we don't display /dev/console here, maybe only failing jobs…
[06:24] <didrocks> at least, I have my keybindings back now :)
[06:26] <didrocks> larsu: if you try to scroll the volume on the sound menu, don't you see weird behavior
[06:26] <didrocks> when dragging the slider?
[06:26] <larsu> didrocks: yep, it's broken (and on my list)
[06:26] <larsu> there's a bug about it iirc
[06:27] <didrocks> ok, I'm not dreaming then! :)
[06:27] <didrocks> I guess it's due to the 120% patch
[06:27] <larsu> sure?
[06:27] <larsu> I think it worked in U
[06:27]  * larsu wrote that patch and probably tried the slider
[06:28] <didrocks> I'm unsure, the offset seems to match a 20% missing :)
[06:28] <didrocks> like if a callback would reset from the % the slider is completed
[06:28] <larsu> hm, this might be a different issue
[06:28] <didrocks> I don't really know in utopic, most of the time, I'm using the multimedia keys for this
[06:29] <larsu> for me, it simply jumps back to 0
[06:29] <didrocks> … until they broke at login time :)
[06:29] <didrocks> ah
[06:29] <didrocks> try to drag until 80%
[06:29] <larsu> like some event translation problem (sometimes I can make it go to 1/3)
[06:29] <didrocks> right
[06:29] <didrocks> and if you go over 80%, it's setting at 100%
[06:29]  * larsu moves that up in his todo list. didrocks important.
[06:30] <didrocks> larsu: ahah, don't! I just noticed it this morning due to the multimedia keys :)
[06:30] <larsu> didrocks: interesting. I can't try that right now because I can't move it beyond 30%
[06:30] <didrocks> well, still to fix for vivid
[06:30] <larsu> right
[06:30] <didrocks> larsu: I think I will be a good candidate to test your patch then!
[06:31] <larsu> :)
[06:31] <pitti> didrocks: je vais bien, merci !
[06:31] <pitti> nous avons regardé un bon concert hier soir -- "Scrap Arts Music"
[06:32] <pitti> ah, http://scrapartsmusic.com/
[06:32]  * didrocks looks
[06:32] <pitti> they do drums and sounds on metal scrap, plastic pipes, isolation material and what not
[06:33] <didrocks> pitti: sounds interestering! Were they giving a show in your city?
[06:33] <pitti> didrocks: yeah, right in the "Parktheater" which is a 15 mins walk from here
[06:34] <pitti> I love that place -- it's a beautiful theater in "Jugendstil" and they have a lot of nice shows
[06:35] <didrocks> oh, nice! :)
[06:36] <didrocks> I guess that style goes very well with this arts music show :)
[06:36] <pitti> didrocks: well, let's say it's a nice contrast :)
[06:37] <pitti> didrocks: we've seen magic shows and Jazz concerts there, and of course more classical theater plays
[06:38] <pitti> https://de.wikipedia.org/wiki/Kurhaus_G%C3%B6ggingen
[06:39] <pitti> didrocks: would you have some minutes this morning for catching up on some systemd stuff?
[06:42] <seb128> good morning desktopers
[06:42] <seb128> hey pitti
[06:42] <pitti> bonjour seb128, ça va ?
[06:42] <desrt> word up seb
[06:42] <seb128> pitti, is using /lib/systemld
[06:42] <seb128> pitti, is using /lib/systemd/system a debian/ubuntu-ism?
[06:42] <seb128> rather than /usr/lib/systemd
[06:43] <seb128> pitti, oui, et toi ?
[06:43] <pitti> seb128: well, it's an -ism of distros which haven't merged /usr into / yet
[06:43] <pitti> s/yet//
[06:43] <seb128> desrt, good middle-of-the-night
[06:43] <desrt> :)
[06:43] <pitti> seb128: but upstream software isn't supposed to hardcode that path anyway
[06:43] <seb128> pitti, ok, I was reading a bit the systemd documentation to get more familiar with it and upstream documents /usr/lib/systemd so I was wondering
[06:44] <pitti> seb128: yeah, that's for Fedora which installs the entire OS into /usr/ now
[06:44] <seb128> k
[06:44]  * desrt wonders when the debian world will realise the wisdom of os-in-/usr
[06:45] <seb128> pitti, btw I noticed that you added some systemd job without having a Documentation=man:..., should we add that to the recommendations/template we use/...?
[06:45] <didrocks> pitti: 30 minutes? having family here
[06:45] <pitti> seb128: it's in the examples on https://wiki.ubuntu.com/SystemdForUpstartUsers and documented there
[06:46] <pitti> seb128: I added it to most stuff, but indeed I left it out where there are no manpages; did I forget one?
[06:46] <pitti> we might also add some URLs or README files
[06:46] <pitti> didrocks: sure, sounds fine!
[06:47] <didrocks> hey seb128, desrt!
[06:47] <desrt> didrocks: good morning
[06:48] <seb128> pitti, well, e.g ufw doesn't have one and has a manpage, but you did that earlier in the cycle
[06:48] <pitti> seb128: ah, I guess I was young and needed the ... education
[06:48] <seb128> :-)
[06:49] <pitti> seb128: yeah, that one certainly has manpages or other documents
[06:49] <seb128> pitti, I'm trying to educate myself as well
[06:49] <pitti> - debian/rulles: Call dh_systemd_{enable,start}.
[06:49] <pitti> go, pitti, go! spelling R us!
[06:49] <seb128> didrocks, pitti, btw do you have your sysgtemd catchup/discussion in public channels, or just over hangouts?
[06:49] <pitti> seb128: I don't know yet
[06:50] <pitti> seb128: the one I have in mind probably works better over IRC, but I'm fine with HO too
[06:50] <pitti> (i. e. the writing-to-thinking ratio is quite low)
[06:50] <seb128> if you do IRC I'm probably going to keep an eye on it
[06:50] <pitti> seb128: that said, I always enjoy hangouts to actually see my friends :)
[06:50] <seb128> trying to get a bit more involved with that side of things
[06:50]  * pitti hugs seb128
[06:51] <seb128> hehe
[06:51]  * seb128 hugs pitti
[06:52] <pitti> seb128: we got through most stuff, but especially on the phone there's still some bits to port if you are interested
[06:53] <seb128> pitti, yeah, I might have a look at helping there
[06:53] <seb128> and if not I'm going to try to help at least on bugs and maybe on the user session stuff next cycle
[07:12] <didrocks> pitti: as you prefer, we can go on IRC
[07:12] <didrocks> my family will live in a bit, but we can start chatting now
[07:12] <didrocks> leave*
[07:13] <pitti> didrocks: so, I was working on providing a counterpart for static-network-up
[07:13] <pitti> i. e. I want to make network-online.target wait until all "auto" interfaces in /e/network/interfaces are up
[07:13] <pitti> that's similar to NetworkManager-wait-online.service or systemd-networkd-wait-online.service which hook themselves there
[07:14] <didrocks> this is not the default of network-online.target?
[07:14] <didrocks> or is it when the first is up?
[07:14]  * didrocks remembers a wiki page about it, but quite rotten in my mind
[07:14] <pitti> n-o.t by itself does nothing, it just comes up when requested
[07:14] <pitti> you have to "implement" it by adding dependencies to it, such as NetworkManager-wait-online.service
[07:14] <didrocks> gotcha
[07:14] <pitti> but so far we don't have an implementation for ifupdown
[07:15] <didrocks> indeed
[07:15] <pitti> so, you know about our udev rule to activate<EMAIL_ADDRESS>[07:15] <pitti> grep net /lib/udev/rules.d/99-systemd.rules
[07:16] <pitti> that one will call<EMAIL_ADDRESS>which will call "ifup iface" once these interfaces appear
[07:16] <pitti> that is for catching interfaces which are hotplugged/slow to initialize and thus aren't covered by the /etc/init.d/networking run during boot
[07:16] <didrocks> with $name, corresponding to the newly detected device
[07:17] <pitti> so, my initial approach was to write a generator which adds<EMAIL_ADDRESS>to network-online.target, for XXX in all "auto" /e/n/i
[07:17] <pitti> that was http://paste.ubuntu.com/9792001/
[07:18] <didrocks> but this starts the services, due to Requires?
[07:18] <pitti> didrocks: but at that point I think the "dependencies" approach and the "hotplugged udev event" don't go well together
[07:18] <didrocks> even before they are ready
[07:18] <pitti> didrocks: right
[07:18] <didrocks> yeah, so dependency vs event :)
[07:19] <pitti> didrocks: so if you e. g. make whoopsie Requires/After=network-online.target (the standard way to say "start this service only after we have networking up")
[07:19] <didrocks> it will start network-online.target
[07:19] <pitti> didrocks: then whoopsie and network-online.target will fail with "dependency failure"
[07:19] <didrocks> which will starts all if@
[07:19] <didrocks> ifup@
[07:19] <didrocks> yep
[07:19] <didrocks> because the unit doesn't exist
[07:19] <pitti> if any of the /e/n/i interfaces aren't ready yet
[07:19] <didrocks> well, it exists, but not ready
[07:20] <pitti> didrocks: well, it works if /e/init.d/networking brings them all up
[07:20] <pitti> didrocks: in my experiment I added an "eth42" to /e/n/i which doesn't exist
[07:20] <pitti> but I can make it exist later with 'sudo ip link add name eth42 type veth peer name veth42'
[07:20] <didrocks> oh right, that's how "new ones" come up
[07:21] <pitti> didrocks: so that was my Q on the upstream mailing list -- can I somehow re-trigger the startup of network-oline.target and reverse deps
[07:21] <pitti> didrocks: yeah, that just simulates a hotplug event, or an interface being detected very late during boot
[07:21] <pitti> i. e. that ip link command will create an eth42 device, trigger the udev rule, trigger ifup eth42 through<EMAIL_ADDRESS>[07:22] <pitti> didrocks: so that's where in http://paste.ubuntu.com/9792001/ the last paragraph comes into play
[07:22] <didrocks> hum
[07:22] <pitti> didrocks: whenever an<EMAIL_ADDRESS>starts, it re-triggers network-online.target with the Wants=network-online.target
[07:22] <pitti> didrocks: so while that bit works fine, this doesn't propagate "upwards", i. e. everything *depending on* n-o.target won't start
[07:23] <pitti> i. e. it's the same problem one level up
[07:23] <didrocks> sure, as it's not an event
[07:23] <didrocks> it's just "that destination is reached"
[07:23] <pitti> because fundamentally, when you start a unit, it starts all of its deps, and if anything fails it fails itself too
[07:23] <didrocks> yep
[07:24] <pitti> so I was wondering if you have a clever idea about "try to re-start everything which depends on n-o.target" in n-o.target
[07:24] <pitti> which is arguably turning the design upside down, but I wondered if it's possible
[07:24] <pitti> as that's basically what you need to trigger units on hardware
[07:24] <didrocks> I guess from the dbus API, we can list all failed units and redo the logic…
[07:24] <didrocks> but then, you have the rdepends on the rdepends…
[07:24] <didrocks> and so on
[07:25] <didrocks> sounds hackish
[07:25] <didrocks> so, that would mean:
[07:25] <didrocks> - listing failed units, check the reason and that they Requires/Wants n-o.target
[07:25] <didrocks> - restarts them
[07:25] <pitti> didrocks: well, instead of re-triggering, it would be enough to not fail into dep-wait, but instead just wait (with a timeout) until your requirements become ready
[07:25] <didrocks> - check if there was no rdepends on those units
[07:25] <pitti> didrocks: yeah, doing all that is crazy, and a "you don't want to do that", I think
[07:25] <didrocks> so n-o.target waiting forever?
[07:25] <didrocks> yeah ;)
[07:26] <didrocks> the waiting would be better
[07:26] <pitti> didrocks: so, yesterday I finally gave up and opted for a very simple "waiting" solution
[07:26] <didrocks> as it's really what you want to express
[07:26] <pitti> didrocks: http://paste.ubuntu.com/9787017/
[07:26] <didrocks> the target isn't really ready until all interfaces are up
[07:26]  * didrocks looks
[07:26] <pitti> didrocks: it's basically what {NetworkManager,systemd-networkd}-wait-online.service do -- these services wait until the network is up, then exit, and then the unit is started
[07:27] <didrocks> +TimeoutStartSec=2min -> the issue of course, is that you have to quantify…
[07:27] <pitti> didrocks: ^ the 2 mins is to copy the  behaviour of /etc/init/networking
[07:27] <pitti> ... .conf
[07:28] <pitti> (default is 1.5min, which would certainly work too, but that's just a detail..)
[07:28] <didrocks> well, better to express it explicitely
[07:28] <didrocks> TBH, the wait solution is the less hackish to me
[07:29] <didrocks> as it's really what you want to express
[07:29] <pitti> didrocks: so, I don't find that very elegant, with the polling loop
[07:29] <pitti> but in essence, I think it fits the design best, and mirrors what the other "implementations" of n-o.t do
[07:29] <didrocks> pitti: can't we have a simple daemon receiving some udev events?
[07:29] <didrocks> instead of polling
[07:29] <pitti> didrocks: that's not enough
[07:29] <pitti> ifup'ing an interface doesn't send out uevents
[07:29] <pitti> ifup is ... special
[07:30] <didrocks> ah… :)
[07:30] <pitti> you actually have to ask ifquery whether an interface is up
[07:30] <pitti> that's the only guaranteed way
[07:30] <didrocks> ok, hence being bound to polling
[07:30] <pitti> you can't even rely on ifup's exit status (debian bug 773539), but that wouldn't help that much either
[07:32] <pitti> didrocks: so, I think it's an ok way to get the correct behaviour (I tested it in a VM pretty extensively), it's just not terribly elegant
[07:33] <didrocks> yeah, and we can't really get that in a dependency fashion to reevaluate it
[07:34] <pitti> now the only question is whether we want n-o.target to fail after two mins (by instsalling it into network-online.target.requires/) or to succeed after two mins (by installing it into network-online.target.wants/)
[07:34] <pitti> so far under upstart we have a "fallback mode" which boots the system anyway after 2 mins, so I went with wants/ for now
[07:35] <pitti> which means, whoopsie whould start after 2 mins if an interface fails
[07:35] <pitti> which for most applications is probably what we want -- the standard case is to wait for all ifaces so that you can bind on all network addresses
[07:35] <pitti> i. e. for old-skool servers which don't react to hotplugged interfaces
[07:36] <pitti> didrocks: so, if you don't have a better idea either, I guess I'll go with that ifupdown patch?
[07:36] <didrocks> I'm trying to think about it
[07:37] <didrocks> give me 15 minutes, I'm experimenting something
[07:38] <pitti> cat <<EOF | sudo tee /etc/network/interfaces.d/eth42.cfg
[07:38] <pitti> auto eth42
[07:38] <pitti> iface eth42 inet static
[07:38] <pitti>         address <IP_ADDRESS>
[07:38] <pitti> EOF
[07:38] <pitti> didrocks: ^ that's what I did to add a non-existing interface at boot
[07:38] <pitti> sudo ip link add name eth42 type veth peer name veth42
[07:38] <pitti> and that's how you bring it up after boot
[07:38] <didrocks> thanks! trying with this
[07:39] <pitti> (another day of yaying for super-quick throw-away VMs, thank you QEMU!)
[07:39] <didrocks> heh, indeed!
[07:42] <didrocks> pitti: yeah, forget about it, this isn't going to work…
[07:43] <didrocks> however, thinking about it, why wouldn't we create another target?
[07:43] <didrocks> like network-online.target -> at least, one interface is up
[07:43] <didrocks> network-online-all.target (or whatever)
[07:43] <pitti> didrocks: I had a version of the generator with creating ifup-all-auto.target and adding deps there, but that makes the problem worse
[07:43] <didrocks> that way, we don't delay the whoopsie startup
[07:43] <pitti> well, the problem isn't delaying the woopsie startup -- it's not starting it up at all if not all ifaces are ready at boot
[07:43] <didrocks> as most of services only need "some connexion"
[07:44] <pitti> of course whoopsie is just my usual test guinea pig -- whoopsie doesn't actually need a n-o.target dep
[07:44] <pitti> (i. e. you have to hack its .service to add this)
[07:44] <didrocks> hum, why would we want to start it without network connection?
[07:45] <pitti> didrocks: as for "why do services want to delay their startup until all interfaces are up", that's a different discussion
[07:45] <pitti> servers usually bind to all available interfaces during startup
[07:45] <pitti> and if you bring up an interface later, they won't automatically bind to that
[07:45] <pitti> unless they listen to udev and re-bind, etc.
[07:45] <didrocks> you think it's the majority? I would say it's the minority actually
[07:46] <pitti> didrocks: so whether to have different targets for both cases is of course also something which we can discuss
[07:46] <pitti> but it still has the same problem
[07:46] <didrocks> and if we explicitely divide that in 2 targets, we can have one succeeding, and the other one failing
[07:46] <pitti> a direct "hardware comes up" -> "start a unit" link is easy
[07:46] <pitti> add a SYSTEMD_WANTS=foo.service in an udev rule
[07:46] <pitti> but putting any indirection in between seems hard
[07:47] <pitti> like, make that uevent activate a service which implements a target
[07:47] <pitti> well, I guess I'll re-send that to the upstream ML
[07:47] <didrocks> I'm a little uneasy if we are making it failing if any interface doesn't come up to basically say "there is no network at all"
[07:48] <didrocks> but I can see you want to know it…
[07:48] <pitti> didrocks: well, that's how stuff has worked for years in Ubuntu with the upstart jobs
[07:48] <pitti> and they do time out after 2 mins and start anyway after that
[07:48] <pitti> stgraber wrote that as at early boot, when /etc/init/networking.conf (or /etc/init.d/networking) runs, often some interfaces aren't ready yet on big servers
[07:49] <didrocks> so, even on upstart, we didn't retrigger an event to say "there is more interfaces, please reevaluate"
[07:49] <didrocks> are*
[07:49] <pitti> didrocks: and this only applies to services which explicitly depend on network-online.target (which isn't actually a lot; but they did come up during porting)
[07:49] <pitti> didrocks: we did
[07:50] <pitti> net-device-up <NAME>
[07:50] <didrocks> ah, so, we restarted let's say apache… as a consequence (or reload)
[07:50] <pitti> but we already have that -- the uevent, plus the systemd .device unit
[07:50] <pitti> didrocks: correct; look at e. g. /etc/network/if-up.d/openssh-server
[07:51] <pitti> didrocks: that restarts openssh on new interfaces
[07:51] <pitti> and that's the correct way to do it
[07:51] <didrocks> ah, but we are getting that in a non systemd way
[07:51] <didrocks> but with those specific rules
[07:51] <didrocks> in /etc/network/if-up.d/
[07:51] <didrocks> yeah, kind of making sense
[07:51] <pitti> but we need the "static-networking-up" (upstart), respectively network-online.target for "old-skool" servers which aren't designed for hotplugging, but just for a server world of static interfaces
[07:52] <didrocks> yeah, I think your approach is good enough for most of the case anyway
[07:52] <pitti> i. e. where you just want to extend the notion of "boot" a bit
[07:52] <didrocks> right
[07:52] <pitti> it's not a clearly defined semantics anyway, I mostly wanted to mirror what we do on upstart
[07:53] <pitti> it gets you a little closer to the old "static" world where you define stuff in /e/n/i and assume it's there
[07:53] <pitti> for a desktop it's entirely a no-op
[07:53] <didrocks> I think that would be an interesting case, where "boot" isn't an answer for those, for the systemd hackfest
[07:53] <didrocks> we do have your solution which is mostly working (as you told, no-op on desktop, mirroring what we did on server)
[07:54] <didrocks> but maybe we can really look how to pull that further and be more dynamic
[07:54] <pitti> yeah
[07:54] <didrocks> did you discuss about it with Lennart already?
[07:54] <pitti> didrocks: only very quickly, but I think I explained it wrongly; I'll re-explain it on the ML
[07:55] <didrocks> yeah ;)
[07:55] <didrocks> tricky!
[07:55] <pitti> "how to make hardware activated targets" basically
[07:55] <didrocks> I think the "force reevaluating" is maybe an answer
[07:56] <pitti> didrocks: right, and that works fine for re-evaluating network-online.target itself, through the extra "Wants" in the<EMAIL_ADDRESS>[07:56] <pitti> but not for its rdepends
[07:56] <didrocks> yeah, I more "reevaluating all failed-units"
[07:56] <didrocks> meant*
[07:57] <didrocks> like, it can be a keyword as part of the transaction
[07:57] <didrocks> pitti: ok, I'll update you on plymouth/fsck, back in 5 if you don't mind?
[07:57] <pitti> didrocks: sure!
[07:57] <pitti> didrocks: I need to leave for a doctor appt. in ~ 20 mins FYI
[07:57] <pitti> takes about 30 mins
[07:58] <pitti> 1 min to get the allergy shot, and 30 mins sitting there reading the news, in case something goes wrong
[07:58] <pitti> (never happened, but oh well, they insist)
[07:59]  * pitti goes back to testing ubuntu CD insertion with update-notifier, to fix its upstart job
[07:59] <pitti> ugh CDs, who has them still?
[07:59]  * pitti plays with QEMU hot-adding virtual drives
[08:00] <darkxst> how does one plug a CD into qemu ;)
[08:00] <pitti> by squeezing really hard!
[08:01] <pitti> you can add an empty drive with -drive if=ide,index=1,media=cdrom
[08:01] <pitti> and send a monitor command to insert a "medium" (from an image), which I'm currently RTFMing about
[08:02] <darkxst> pitti, or just melt the CD and plug it into the USB port ;)
[08:02]  * didrocks back
[08:02] <pitti> actually, -drive media=cdrom is enough
[08:02] <didrocks> pitti: I really think that if systemd internals can reevaluate (not restart), but retry failing jobs and only try restarting one path that makes sense with the new state of the world…
[08:03] <didrocks> let's see what upstream thinks about it
[08:03] <didrocks> pitti: ok, so on fsck/plymouth
[08:03] <pitti> yeah, something for the hackfest
[08:03] <didrocks> I have multiple systemd-fsck process talking to one central systemd-fsckd
[08:03] <didrocks> and systemd-fsckd talking to plymouth
[08:04] <didrocks> I hacked our ubuntu logo theme to get those info
[08:04] <didrocks> which means:
[08:04] <didrocks> - systemd grows a dep on plymouth
[08:04] <didrocks> - I factorized plymouth communication in the shared static lib
[08:04] <didrocks> I have to update the text theme + xubuntu and such to this new protocol
[08:05] <didrocks> also, there are some fixes for some corner cases, like reconnecting if plymouth respawn
[08:05] <didrocks> I'm stuck on i18n though
[08:05] <pitti> didrocks: you mean libplymouth, right? or plymouth the daemon?
[08:05] <didrocks> libplymouth
[08:05] <mlankhorst> morning :P
[08:05] <pitti> didrocks: oh, plymouthd crashing in the middle of fsck'ing, and you can survive that?
[08:05] <pitti> hey mlankhorst, how are you?
[08:05] <didrocks> hey mlankhorst
[08:06] <mlankhorst> hey I'm good :-)
[08:06] <didrocks> pitti: yeah, right now, I survive, but I don't reconnect to the new one
[08:06] <pitti> ambitious!
[08:06] <didrocks> well, shouldn't be too hard, like a 20 minutes job testing included :)
[08:06] <didrocks> so yeah, then adding the .services, writing manpages…
[08:06] <didrocks> I'm just worried about this i18n
[08:07] <pitti> darkxst: ah, awesome! FTR: change ide0-cd0 /home/martin/Downloads/ubuntu/vivid-desktop-amd64.iso
[08:07] <didrocks> - the first version of plymouth theme (the code is still there, just not in use) did create the string shown to the user
[08:07] <darkxst> pitti, given I don't have a functioning cd drive, melting might work better ;)
[08:07] <didrocks> - then, mountall sent the translation as part of the message and that's what is used with upstart nowdays
[08:08] <pitti> darkxst: it's all virtual :) (I don't have a physical CD drive either)
[08:08] <didrocks> - systemd doesn't have any i18n facility…
[08:08] <pitti> didrocks: oh, you mean s-fsckd will already generate the strings, not the theme
[08:08] <didrocks> it seems it makes sense to do that on systemd-side, but maybe different themes wants different message to display and we just send the metadata?
[08:08] <pitti> didrocks: systemd does have i18n
[08:08] <didrocks> the theme doesn't support i18n either
[08:08] <didrocks> hum, really?
[08:09] <pitti> didrocks: yeah, mostly for the .policy files (polkit)
[08:09] <pitti> didrocks: but also for the CLI tools
[08:09] <darkxst> pitti, CD's are a physical media that can't be virtualised ;) iso's on the other can ;)
[08:09] <didrocks> pitti: I did only see the policy files, which is different, not the CLI tools
[08:09]  * didrocks looks
[08:09] <pitti> didrocks: oh right
[08:10] <didrocks> yeah, regrepped and nothing
[08:10] <pitti> didrocks: I guess there's something to be said to leave the representation to the theme
[08:10] <pitti> some themes might want this entirely graphical, or on really small screens or whatever
[08:10] <didrocks> pitti: I agree, that's the current implmentation
[08:10] <didrocks> but!
[08:11] <didrocks> .script doesn't seem to support i18n
[08:13] <didrocks> not an issue for the C themes of course, but our main one is a script…
[08:13] <pitti> didrocks: hmm, if themes don't suppor that, how do we i18n this today?
[08:13] <didrocks> pitti: as told, that was put into mountall which send the strings to the theme
[08:13] <pitti> eww, yes
[08:13] <didrocks> as part of the message
[08:14] <pitti> didrocks: and "script" can't call shell tools like "gettext", I suppose?
[08:14] <didrocks> which sounds wrong to me
[08:14] <pitti> yes, it is
[08:14] <didrocks> I didn't try, didn't see that in practice
[08:14]  * didrocks looks for example, but theme documentation is really thin
[08:17] <didrocks> yeah, nothing obvious at least
[08:18]  * pitti looks at themes/ubuntu-logo/ubuntu-logo.script
[08:19] <didrocks> pitti: btw, as told, I tried to be minimal in my patch in the theme, meaning, I don't touch most of the rest of the logic
[08:19] <didrocks> but there is a lot of already dead code due to design changes
[08:19] <didrocks> (like the progress bars)
[08:20] <didrocks> and all the fsck logic was there
[08:20] <pitti> didrocks: hm, I can't imagine why plymouth themes wouldn't have their own text/i18n, but maybe they did design it like that, that clients have to create the strings
[08:20] <pitti> didrocks: adding i18n to fsckd doesn't seem much of a problem really; add it to po/POTFILES.in and use glibc's gettext
[08:20] <pitti> but I wonder if that's the right design
[08:20] <pitti> well, obviously it's the current design
[08:21] <didrocks> pitti: I don't think it is as it means, we are forcing upon each themes our strings
[08:21] <didrocks> well, forcing/proposing :)
[08:21] <didrocks> (as we can keep, as of today, the metadata as well)
[08:24] <pitti> didrocks: need to run for appointment, back in 30; but I guess for now let's put the strings into fsckd then?
[08:24] <didrocks> pitti: yeah :/
[08:24] <didrocks> pitti: just to be complete on the fsck question: we won't implement the question about "your partition is broken, do you want to fix it?" as systemd-fsck force repair by default
[08:24] <didrocks> I need to implement the escape feedback though
[08:24] <pitti> at least with that themes don't have to copy&paste the fsck messages
[08:24] <didrocks> like you press escape -> cancel all fsck jobs
[08:24] <pitti> right
[08:24] <pitti> we mostly just need the "checking, NN%  done" and maybe the cancel
[08:24] <didrocks> right
[08:25] <didrocks> so, doing the escape first
[08:25] <didrocks> and text theme, should be easy
[08:25] <didrocks> i18n -> I'm quite "sad" :/
[08:32] <didrocks> hum, ubuntu-text never supported fsck messages
[08:32]  * didrocks wonders if it worths it to add that now (it's in C)
[09:02] <willcooke> good morning all
[09:03] <pitti> hey willcooke
[09:03] <pitti> didrocks: hm, we install that on servers, right?
[09:03] <pitti> didrocks: but if fsckd sends the messages, wouldn't -text get that automatically?
[09:04] <Laney> hallo
[09:04] <didrocks> pitti: we install that on the client as well, it's shown when you have nvidia cards
[09:04] <didrocks> pitti: and no, there is no room for "update" message into that theme
[09:05] <didrocks> (like no sprite placement)
[09:05] <pitti> oh, ok
[09:05] <willcooke> Laney, bad news...
[09:05] <willcooke> Laney, no tenner found.
[09:05] <didrocks> pitti: the one on the right: http://i.stack.imgur.com/EPKXz.png
[09:06] <Laney> willcooke: oh well, I'll take that raise then
[09:06] <willcooke> I might be in the office this week, I'll be sure to check down the back of the sofa in reception for your "raise"
[09:06] <Laney> :-)
[09:10] <didrocks> hum, can't get the disconnect signal from plymouth :/
[09:30] <didrocks> pitti: I'm unsure that we tested disconnection from plymouth in a long time
[09:30] <didrocks> the issue is that the even loop is stuck, and so is the daemon…
[09:31] <didrocks> I'm checking what we are doing in casper or mountall, and it seems to be the same though
[09:32] <seb128> Laney, hey, btw it seems the upower transition was a redherring on that sleep issue on the device
[09:32] <pitti> didrocks: I'm unsure that we tested anythign in plymouth recently :/
[09:32] <pitti> it's quite a bit of a bitrot case
[09:33] <pitti> didrocks: i. e. our current approach is to hope that plymouth won't crash? :/
[09:33] <didrocks> pitti: seems so, if it does, I'm pretty sure mountall or md5check is stuck
[09:33] <didrocks> pitti: we have a disconnect handler, bound
[09:33] <didrocks> but it's only trigger from plymouth code on ply_event_loop_process_pending_events()
[09:33] <didrocks> triggered*
[09:34] <Laney> seb128: oh yeah?
[09:34] <didrocks> which we already use of course to send the update to plymouth
[09:34] <didrocks> but if plymouth quits, ply_event_loop_process_pending_events() is stuck
[09:34] <didrocks> I guess I have to printf in plymouth to see where it's stuck…
[09:34] <seb128> Laney, yeah, apparently the issue is not easy to trigger and the testing is a bit flacky/make difficult to confirm what image is good or not
[09:34] <seb128> Laney, seems all images get the issue in some random ways
[09:35] <Laney> so we're not sure if it even got worse?
[09:35] <pitti> didrocks: erk, that's awful; i. e. whenever plymouth would crash (and it does that a lot), essentially the whole boot is stuck
[09:35] <seb128> Laney, seems not
[09:36] <didrocks> pitti: I'm still unsure, can be me not doing something right, but I can't see the immediate issue and the difference I would have with mountall or md5check
[09:36] <didrocks> so printf time!
[09:37] <pitti> didrocks: yuck! I hope it gets captured in the journal :)
[09:38] <didrocks> pitti: let's see… I feel it's going to be a "fun" day
[10:07] <pitti> didrocks: uploading ifupdown now; it's all static files, so we can always improve this stuff
[10:10]  * pitti documents that on https://wiki.ubuntu.com/SystemdForUpstartUsers
[10:18] <Laney> seb128: btw, you went offline when I tried to reply to you yesterday then I forgot - yes, taking care of poppler
[10:18] <seb128> Laney, great, thanks
[10:19] <seb128> yeah, I did some unity8 playing with which got me out of IRC for a while
[13:35] <didrocks> ah, I think I got the plymouth hangups
[13:35]  * didrocks tries something
[13:36] <didrocks> \o/
[13:36] <seb128> got to the bottom of it?
[13:37] <didrocks> yeah
[13:37] <didrocks> basically, you need to attach the event listener after you are connected to plymouth
[13:37] <didrocks> which may creates a race, and that's why I did the other way around
[13:37] <didrocks> but in that case, it doesn't reregister the disconnection handler
[13:37] <didrocks> and then, next listen on the queue just hangs
[13:38] <didrocks> it's tricky, because if you attach the listener before you connect to plymouth, all events are passed well
[13:38] <didrocks> apart from the disconnection…
[13:39] <didrocks> I see that casper-md5check does the same than I did btw
[13:39] <didrocks> so I guess the process would hang if plymouth crashes
[13:39]  * didrocks adds a TODO
[13:41] <didrocks> pitti: FYI ^
[13:43] <didrocks> seb128: the issue is that the plymouth code is copying the reference at attach time, instead of refering directly to the object
[13:44] <seb128> didrocks, is that still in context of the fsck integration to plymouth?
[13:45] <didrocks> yeah
[13:45] <didrocks> why?
[13:46] <seb128> just curious, I didn't follow closely the issue, trying to make sense of what you describe
[13:58] <pitti> didrocks: "other way round"? you can attach to a listener before connecting? anyway, I'm afraid I know next to nothing about it, so great that you found it!
[14:01] <didrocks> pitti: yep! Cleaning up the code base and then trying multiple plymouth reconnect
[14:03] <Sweet5hark> jcastro: I heard you do lobbying in europe now: https://cdt.org/staff/jorge-castro/
[14:03] <jcastro> hah, good to know
[14:16] <didrocks> ok, now, can reconnect to any new plymouth connexion and resend last update \o/
[14:16]  * pitti ^5s didrocks
[14:16]  * didrocks ^5s back
[14:17] <didrocks> ok, so control+C now
[14:17] <didrocks> then, will remain i18n and the "what to do with the text theme?"
[15:12] <Laney> seb128: poppler in NEW if you have a few minutes to look
[15:13] <willcooke> seb128, all - might be 5 mins late for the meeting again, school run.  Should be back in time though...
[15:23] <seb128> Laney, sure
[15:23] <seb128> wk
[15:23] <seb128> willcooke, k
[15:24] <Laney> ty
[15:31] <willcooke> back
[15:31] <desrt> mmmmmmm
[15:31] <desrt> mmmmmmmmmmmm
[15:31] <willcooke> #startmeeting Desktop Weekly Team Meeting 2015-01-20
[15:31] <meetingology> Meeting started Tue Jan 20 15:31:25 2015 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:31] <meetingology> Available commands: action commands idea info link nick
[15:31] <desrt> meeting!
[15:31] <willcooke> Roll call coming up....

[15:33] <qengho> DIALING...
[15:33] <willcooke> attente_, desrt, dgadomski_ didrocks, FJKong , happyaron , Laney larsu mlankhorst qengho seb128 Sweet5hark
[15:33] <dgadomski_> hello everyone o/
[15:34] <desrt> here :)
[15:34] <didrocks> hey!
[15:34] <FJKong> hey
[15:34] <seb128> _o/
[15:34] <Sweet5hark> o/
[15:34] <larsu> yep
[15:35] <willcooke> lets do this thing
[15:35] <willcooke> #topic attente_
[15:35] <attente_> hi
[15:35] <attente_> not much to report, did some more testing for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1408593 and https://bugs.launchpad.net/mir/+bug/1409133
[15:35] <attente_> tried switching over to using the new mir menu api, but blocked on lack of support in the demo shell, looked into adding it
[15:36] <desrt> attente_: did you see that popovers in gtk are using wayland subsurfaces now?
[15:36] <desrt> probably worth seeing if they can be done the same way on mir
[15:36] <desrt> would be nice to have a feature that works better in mir than it does in x11 ;)
[15:37] <attente_> you mean implementing subsurfaces in mir?
[15:37] <desrt> i was thinking that the menu positioning stuff is really just the same as subsurfaces, no?
[15:38] <desrt> ie: a new surface that is related to and has a relative position to another existing surface but is not necessarily clipped by it
[15:38] <attente_> the api adds some extra stuff to determine where to position the surface if it overflows outside of the screen though
[15:38] <larsu> attente_: I've started looking into gtk mir too. I'll help out starting very soon
[15:39] <larsu> attente_: let me know if you need something specific (if not, let's talk at the sprint)
[15:39] <desrt> attente_: ya... i'm sure it won't be 1:1 easy... but probably worth looking into it to see how it can be done... maybe it needs some more changes in mir, maybe not
[15:39] <desrt> would be good to know that ahead of the sprint week
[15:40] <larsu> mir has a "menu" api?
[15:40] <desrt> just an api for positioning menu-like windows
[15:40] <attente_> yeah
[15:40] <desrt> not gmenumodel or anything, if that's what you're thinking :)
[15:40] <attente_> but tbh i don't think gtk needs it
[15:40] <seb128> larsu, https://code.launchpad.net/~albaguirre/mir/add-menu-api/+merge/244632
[15:40] <attente_> because gtk seems to adjust the position inside the screen itself
[15:41] <larsu> desrt: no I wasn't thinking that. Just sounded a bit too specific for a window manager
[15:41] <larsu> seb128: thanks!
[15:41] <seb128> yw :-)
[15:41] <desrt> rule 1) window managers must not handle menus
[15:41] <desrt> rule 2) feel free to violate rule 1, as long as you write it in javascript
[15:42] <larsu> desrt: seems like gerry was against this (in addition to other people)
[15:42] <attente_> should we ask them to revert that api?
[15:42] <desrt> er wait what?
[15:43] <larsu> attente_: no, looks like there was quite a bit of discussion around it
[15:43]  * larsu trusts that they came to some kind of consensus
[15:43] <attente_> because gtk is already fixing the position of the menus itself
[15:43] <seb128> seems like the sort of topic better to discuss in Brussels
[15:43] <desrt> ya...
[15:43] <larsu> ya
[15:43]  * desrt is a bit surprised to be hearing this now
[15:43] <willcooke> ok cool
[15:44] <seb128> desrt, it landed less than a week ago
[15:44] <willcooke> I will add this topic to my list of Brussels things
[15:44] <desrt> seb128: ya.  i know.  i was kinda assuming that it didn't suck.
[15:44] <seb128> willcooke, good idea
[15:45] <willcooke> one sec while I add it....
[15:45] <willcooke> (otherwise I will forget)
[15:45]  * Sweet5hark is available as an adjutant for duels in bruessels
[15:46] <willcooke> #topic desrt
[15:46] <desrt> hi
[15:46] <desrt> not lots to say.  still working on file monitors
[15:46] <desrt> this turned into quite a large job
[15:47] <desrt> plus the usual bugs/reviewing/etc. stuff has been keeping me from it a bit
[15:47] <desrt> the good news is that they work.  the bad news is that the branch is in an ugly state and needs to be cleaned up and there are surely some bugs left to fix
[15:47] <desrt> that's all
[15:48] <willcooke> thanks desrt
[15:48] <willcooke> #topic dgadomski_
[15:48] <dgadomski_> This week in the widely understood around-desktop area it was:
[15:48] <dgadomski_> * established a working setup for testing bug #1104230, solved 2 problems, continuing debugging, new kernel build available in ppa:dgadomski/linux-mst
[15:48] <dgadomski_> * got positive feedback on fix to bug #1020210, got it sponsored, waiting for it being reviewed and land in -proposed
[15:48] <dgadomski_> * still working on implementation to fix bug #1337873
[15:48] <dgadomski_> * thanks to cyphermox I was able to move forward with bug #1410779, waiting for more feedback from the user
[15:48] <dgadomski_> * following upstream decisions regarding the future of bug #445333
[15:48] <dgadomski_> EOF
[15:49] <willcooke> thanks dgadomski_ - do you need anything from us right now?
[15:49] <dgadomski_> no, thanks, I'm ok currently :)
[15:50] <willcooke> cool
[15:50] <willcooke> #topic didrocks
[15:50] <didrocks> Ubuntu Make:
[15:50] <didrocks> * Reviewing IDEA (non community) edition integration into Ubuntu Make
[15:50] <didrocks> * Get jayatana installed by default (pulled by appmenu package)
[15:50] <didrocks> Systemd:
[15:50] <didrocks> * systemd sprint, continues converting a bunch of packages: powernap, lxc-android-config, conmux, bluetooth-touch, mosquitto, edubuntu-server
[15:50] <didrocks> * pair with Martin to get a crude version of Ubuntu Touch to be started under systemd. We can even ssh to it now and get Unity8 running \o/ Still some work needed for a lot of jobs to run.
[15:50] <didrocks> * discussed about the android property bridge and did some testing/debugging on it.
[15:50] <didrocks> * finish fsck daemons all connecting to fsckd, and get fsckd talking to plymouth + change plymouth (ubuntu logo) theme. Still some opened questions before integrating that to systemd upstream like where to put i18n… Need as well Ctrl+C integration.
[15:50] <didrocks> Misc:
[15:50] <didrocks> * Helped FJKong debugging some segfaults using qt.
[15:50] <didrocks> .
[15:51] <didrocks> (loosing right now some hairs on getting a nice systemd/plymouth integration)
[15:52] <willcooke> thx didrocks
[15:53] <desrt> didrocks: excellent job!
[15:53] <willcooke> #topic FJKong
[15:53] <FJKong> * bug tracking: change font size does't works in setting, can't reproduce on my computer
[15:53] <FJKong> * bug fixing: crash after clicking apply then clicking menu to change skin, fixed it this week
[15:53] <FJKong> * bug tracking: memory leak when using ImageProvider, processing it
[15:53] <FJKong> * streghthen skin structure
[15:54] <FJKong> mainly focusing on fix bugs about sogou
[15:54] <FJKong> that's all
[15:55] <willcooke> thanks FJKong
[15:55] <willcooke> #topic happyaron
[15:56] <willcooke> happyaron, might not be around - timeout set at 2 mins.  We can always come back around.
[15:56] <larsu> timeout. so much pressure.
[15:57] <qengho> His packets DO have to travel pretty far.
[15:57] <larsu> haha indeed
[15:58]  * Sweet5hark gets the pressure feels too.
[15:58] <willcooke> #topic Laney
[15:58] <Laney> • Split a-i-t. Need to move reverse-deps of gnome-icon-theme over
[15:58] <Laney> • Fix oslo-config upgrade SNAFU
[15:58] <Laney> • yelp crash fix
[15:58] <Laney> • evolution point release, SRU this to utopic too
[15:58] <Laney> • new vala, contains binding security fix so rebuild affected rdeps
[15:58] <Laney> • new webkitgtk, build problem, propose a fix upstream
[15:58] <Laney> • new gtk+3.0, also some chat about a security fix in trusty
[15:58] <Laney> • Get dose-distcheck deployed to the transition tracker to fix parsing error there
[15:59] <Laney> • poppler 0.30.0, will be a transition. also SRU a fix for some ligatures not displaying correctly to utopic and trusty
[15:59] <Laney> • Start DMB election nomination period
[15:59] <Laney> • Some poking flavours about alpha 2 which is meant to be this week, might cancel it due to lack of help
[15:59] <Laney> • Get sponsor queue to display ubuntu-desktop branches
[15:59] <Laney> ⚒
[15:59] <willcooke> thx Laney
[15:59] <desrt> Laney: new glib too
[15:59] <Laney> oh yes
[15:59] <desrt> with your NM Stuff...
[15:59] <Laney> https://packages.qa.debian.org/g/glib2.0/news/20150120T153405Z.html
[16:02] <willcooke> #topic larsu
[16:02] <larsu> hey!
[16:02] <larsu> * theme finally doesn't depend on unico anymore
[16:02] <didrocks> \o/
[16:02] <desrt> larsu just won the meeting
[16:03] <seb128> larsu, I've been running your branch, didn't notice any issue/difference
[16:03] <desrt> next he's going to tell us overlay scrollbars are dead or something
[16:03] <larsu> * more theme fixes for spinners, some backgrounds, etc
[16:03] <larsu> * also lots of cleanup (removed unused rules and files)
[16:03] <larsu> seb128: nice! There's another one as well. Would be cool if we could merge them soon
[16:03] <larsu> seb128: thanks
[16:03] <larsu> desrt: not yet, though I've played around backporting the upstream ones
[16:03] <seb128> great, we should probably put those in a silo when you feel like they are ready for landing
[16:04] <desrt> larsu: "we need to talk...."
[16:04] <larsu> desrt: I think we should just wait though. Just one cycle is not worth the hassle
[16:04] <larsu> seb128: can you please do that? You have the power ;)
[16:04] <larsu> desrt: _we_ do?
[16:04] <desrt> larsu: yes.  protocol violation here
[16:04] <seb128> larsu, if you are happy with your current work and want to land it, sure
[16:04] <desrt> don't waste time backporting when you're gonna see laney in a couple of weeks
[16:05] <desrt> just make sure you have enough money in your beer fund
[16:05] <larsu> seb128: yes please - thanks
[16:05] <Laney> correct
[16:05] <larsu> haha
[16:05] <larsu> slippy-finger time!
[16:05] <larsu> anyhow:
[16:06] <larsu> * started looking into gtk/mir to be able to jump into it at the hackfest
[16:06] <seb128> I'm happy to drink beers with you guys while Laney fixes the issue with the new GTK he just slipped in :p
[16:06] <desrt> sounds like we're gonna need a bigger beer fund...
[16:06] <willcooke> :)
[16:06] <larsu> * oh and looked into the volume slider event issue (thanks didrocks). Got a fix but don't know why it works
[16:06] <willcooke> I'll look down the back of the Canonical sofa
[16:06] <Laney> plenty of issues to go around guys
[16:06] <Laney> we can have a lucky dip
[16:06] <didrocks> larsu: that's the best fixes :)
[16:06] <willcooke> once Laney has his pay rise there should still be plenty to go around
[16:06] <seb128> haha
[16:07] <desrt> we're all going to need a pay raise to cover our keeping seb in a tranquil state
[16:07] <larsu> for some reason event coordinates don't need to be mapped to the slider's allocation anymore
[16:07] <Laney> he means because the numbers will start to overflow the bank's integers
[16:07] <seb128> didrocks, is the issue that the cursor is shifted from the actual position activated when you click?
[16:07] <larsu> I can't find a relevant commit in gtk
[16:07] <didrocks> seb128: right!
[16:07] <didrocks> when you drag as well…
[16:07] <seb128> didrocks, k, I noticed that as well
[16:07] <larsu> not sure if bisecting is needed or if we can just use the fix I have and dtop thinking about it
[16:08] <didrocks> which is even more puzzling to my brain ;
[16:08] <Laney> that's been on the pad for weeks already
[16:08] <didrocks> :)
[16:08] <Laney> why is random pinging necessary?
[16:08] <qengho> Laney: you hope they're unsigned types.
[16:08] <Laney> just as long as the cheques are signed
[16:09] <willcooke> larsu, ok to move on?
[16:09] <larsu> willcooke: yep, that's it
[16:09] <willcooke> thanks larsu
[16:09] <willcooke> #topic mlankhorst
[16:09] <mlankhorst> harassing people in #ubuntu-release without much success
[16:09] <mlankhorst> updating the vmware and intel packages in the x-staging ppa for 1.17 (waiting on fglrx)
[16:09] <mlankhorst> adding rotation and 2x option to xmir-standalone
[16:09] <mlankhorst> resend glamor patches to xorg-devel ml
[16:09] <mlankhorst> regression test and upload mesa 10.4.2 to vivid
[16:09] <mlankhorst> upload and verify xserver-xorg-video-intel sru's with rotation fixes
[16:09] <mlankhorst> upload new xserver-xorg-video-vmware to archive after testing
[16:10] <willcooke> great stuff, thanks mlankhorst.
[16:10] <willcooke> Any luck today with #ubuntu-release?
[16:10] <mlankhorst> nope :P
[16:10] <didrocks> mlankhorst: did you try direct ping as suggested?
[16:10] <mlankhorst> just a silent echo
[16:11] <mlankhorst> I 'll try that next, but usually that channel is more active
[16:11] <mlankhorst> raof accepted some packages, but I had some discussion about the ones not in yet though i havent had a reply rom him since
[16:12] <willcooke> he's on the other side of the world isn't he?
[16:14] <willcooke> mlankhorst, if you dont have any luck by EOD tomorrow, let's revisit
[16:14] <willcooke> #topic qengho
[16:16] <qengho> - In Cr, fixed bugs like search-suggestions and DRI3/sandbox backport.
[16:16] <qengho> - Worked on connecting Cr to mir. I may need help with today's problem. I'll ask here once I try some more.
[16:16] <qengho> And that's mostly it. Some debugging of a crash in unity8, but that got nowhere.
[16:16] <willcooke> thanks qengho
[16:17] <seb128> qengho, is chromium updated soon?
[16:17] <seb128> qengho, you said the next update would be around now and would adress that bug that tops e.u.c
[16:17] <qengho> seb128: I said in about two weeks, which is still a week away.
[16:18] <seb128> oh ok, I though it was 2 meetings ago
[16:18] <seb128> all good then ;-)
[16:19] <willcooke> #topic seb128
[16:19] <seb128> * had some vac days
[16:19] <seb128> * helped moving some SRUs forward (updated patches, triaged bugs, verified some fixes)
[16:19] <seb128> * a bit of sponsoring
[16:19] <seb128> * backported a fix to rtm to make the "reply" hint in indicator-message translated
[16:19] <seb128> * spent some time reading documentation and playing with unity8, current desktop-next session, systemd
[16:19] <seb128> * usual share of desktop related bugs triage and discussions

[16:20] <willcooke> thanks seb128
[16:20] <willcooke> #topic Sweet5hark
[16:20] <Sweet5hark> - checked prerequs. and submitted MIRs for libabw, libe-book, libeot, libetoneyek, libfreehand, libmwaw, libodfgen to ubuntu-mir team for approval -- bug 1410866 and bug 1410883
[16:20] <Sweet5hark> - blogged about the (small) writer performance improvements: https://skyfromme.wordpress.com/2015/01/15/swnodeindex-ludicious-speed/
[16:20] <Sweet5hark> - various trackers/issues grinding
[16:20] <Sweet5hark> - remerging from Debian (ongoing)
[16:20] <Sweet5hark> - new upstream LibreOffice 4.4.0~rc3 due this week (tag expected ~today)
[16:20] <Sweet5hark> - some upstream patch review
[16:20] <Sweet5hark> - upstream admistration tasks (meh)
[16:20] <Sweet5hark> EOF
[16:22] <willcooke> thx Sweet5hark
[16:22] <willcooke> #topic themuso
[16:22] <willcooke> * Exclusively been working on bug #1066157, and have determined that unity is using deprecated methods/signals in atk, so am now going through unity a11y code checking all methods/signals, and checking whether they are still valid. There may be more things to fix to resolve this bug, but I think this will go a long way to getting us there.
[16:22] <willcooke> #topic any other business
[16:22] <willcooke> Dont think there is much else
[16:23] <seb128> seems not
[16:23] <willcooke> #endmeeting
[16:23] <meetingology> Meeting ended Tue Jan 20 16:23:17 2015 UTC.
[16:23] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2015/ubuntu-desktop.2015-01-20-15.31.moin.txt
[16:23] <willcooke> thanks all
[16:23] <seb128> qengho, found back the IRC log btw, http://irclogs.ubuntu.com/2015/01/08/%23ubuntu-desktop.html#t16:37
[16:23] <seb128> qengho, that was not previous week but the week before ;-)
[16:24] <Sweet5hark> looking for forward to see you guys soon in cafe delirium ...
[16:25] <larsu> Sweet5hark: !
[16:25] <Laney> Was a bit busy for me last time ...
[16:25] <desrt> ya
[16:25] <desrt> i'm starting to get tired of going to this place :)
[16:25] <seb128> Sweet5hark, btw I lost track, but is there any libreoffice work I'm supposed to upload for you and that I didn't do?
[16:26] <didrocks> desrt: come on, it's your second venue to FOSDEM only IIRC :)
[16:26] <desrt> might be better to buy a case of beer from elsewhere and bring it to the alleyway :)
[16:26] <larsu> 3rd
[16:26] <larsu> desrt: wegbier!
[16:26] <desrt> 3rd?  seems more like 4th or 5th
[16:26] <larsu> desrt: at least 3rd (I was there the last two years and you were there)
[16:26] <Sweet5hark> seb128: rechecking ...
[16:26] <seb128> Sweet5hark, danke
[16:27] <desrt> codethink had some hackfests in brussels around fosdem time
[16:28] <qengho> seb128: I expect a upstream release in the next few days, but after patching/building/testing, it will be next week before it's ready to upload.
[16:28] <seb128> qengho, ok, fair enough, looking forward the update still ;-)
[16:28] <qengho> :)
[16:28] <qengho> Me too!
[16:29] <Sweet5hark> seb128: hmm, I dont see LibreOffice 4.2.8 in trusty-proposed nor in the trusty queue: http://people.canonical.com/~bjoern/trusty/4.2.8/
[16:30] <Sweet5hark> seb128: ... and I will throw some 4.4.0 rc at you in the next days, I guess.
[16:30] <seb128> Sweet5hark, ok, I think that's the one which was missing SRU info, you added those and I didn't have another look
[16:30] <seb128> k, sounds good
[16:31] <seb128> I'm going to have another look to the SRU one
[16:32] <Sweet5hark> seb128: great thanks so much! as for vivid -- no other upload. Precise: yeah, Id guess we need to do something there at some point -- lets talk in brussels on that if possible.
[16:32] <seb128> ok
[16:32] <Sweet5hark> seb128: yes, 4.2.8 now has a bug ID in the changes ...
[16:54] <didrocks> oh my! /me found a way easier way (and remove last hour of work :/)
[16:55] <desrt> didrocks: on the scale of replace-oneself-with-a-script experiences, an hour of wasted effort is actually pretty low :)
[16:57] <didrocks> desrt: indeed, especially counting that I remove many lines, a hashmap I was handling manually and so force in the process :)
[16:58] <didrocks> it's one of those things when you are writing code, thinking "it sucks", and suddenly, when you gave up on thinking on another solution, it just comes to your mind…
[17:34] <pitti> argh, Sweetshark is already gone ;/ wanted to say happy bday
[17:48]  * didrocks waves good evening
[18:56]  * willcooke EOD
[21:27] <tedg> robert_ancell, Am I correct to assume that you'll land the indicator-bluetooth bz5 MR when you've got the whole transition ready?
[21:28] <robert_ancell> tedg, yes
[21:29] <tedg> robert_ancell, Cool, any idea of time? Guessing it has to be relatively soon for FF coming up.
[21:30] <robert_ancell> tedg, I'm not sure what the plan is. didrocks was managing the transition. I'm just doing the grunt work for the indicator
[21:30] <tedg> Ah, okay.
[21:31] <tedg> Grunt away! ;-)
[23:18] <Sweet5hark> mterry: as a trusty main inclusion request man: do you see any obvious troubles with bug 1410883 or bug 1410966?
[23:19] <mterry> Sweet5hark, ah, I haven't looked at those yet.  It's near eod for me, mind if I look at them tomorrow?
[23:19] <Sweet5hark> mterry: no worries, not too urgent...


[06:02] <wxl> any reason why there are no download links the upgrades on bionic? e.g. http://iso.qa.ubuntu.com/qatracker/milestones/384/builds/163340/downloads
[06:04] <tsimonq2> hrm O_o?
[06:04] <valorie> I see none either
[06:09] <valorie> they are here: http://iso.qa.ubuntu.com/qatracker/milestones/384/builds/163339/testcases
[06:10] <wxl> no downloads
[06:10] <valorie> for an upgrade, you wouldn't use a download, would you?
[06:10] <wxl> with the (image) testcases, yes
[06:10] <valorie> ok
[06:10] <valorie> obv. I don't know enough
[06:11] <wxl> maybe the idea is you just get them from the regular testcase downloads?
[06:12] <valorie> when I tested upgrades - lts to lts for instance, I just used an iso I had for seeding
[06:13] <valorie> on real hardware
[06:13] <valorie> this was how my travel notebook lost windows
[06:13] <valorie> :-)
[06:13] <valorie> deliberately, because I didn't want to mess with it anymore
[07:42] <flocculant> wxl: don't think there ever has been
[07:45] <flocculant> I think a lot of this is - do we really need to spoonfeed people ...
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [amd64] (bionic-proposed) [1.0.16-2]
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [armhf] (bionic-proposed) [1.0.16-2]
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [ppc64el] (bionic-proposed) [1.0.16-2]
[12:30] -queuebot:#ubuntu-release- New: accepted unicode-cldr-core [amd64] (bionic-proposed) [31.0.1-1]
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [arm64] (bionic-proposed) [1.0.16-2]
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [s390x] (bionic-proposed) [1.0.16-2]
[12:30] -queuebot:#ubuntu-release- New: accepted libsodium [i386] (bionic-proposed) [1.0.16-2]
[23:07] <tsimonq2> flocculant: Well it helps for consistent documentation...
[23:10] -queuebot:#ubuntu-release- New binary: bullet [s390x] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: pastescript [amd64] (bionic-proposed/main) [2.0.2-1] (ubuntu-server)
[23:11] -queuebot:#ubuntu-release- New binary: bullet [i386] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: cyclograph [amd64] (bionic-proposed/universe) [1.9.1-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New: accepted cyclograph [amd64] (bionic-proposed) [1.9.1-1]
[23:12] -queuebot:#ubuntu-release- New: accepted pastescript [amd64] (bionic-proposed) [2.0.2-1]
[23:13] -queuebot:#ubuntu-release- New binary: bullet [ppc64el] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: bullet [amd64] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: bullet [armhf] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: simgrid [s390x] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: bullet [arm64] (bionic-proposed/universe) [2.87+dfsg-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [amd64] (bionic-proposed) [2.87+dfsg-2]
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [armhf] (bionic-proposed) [2.87+dfsg-2]
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [ppc64el] (bionic-proposed) [2.87+dfsg-2]
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [arm64] (bionic-proposed) [2.87+dfsg-2]
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [s390x] (bionic-proposed) [2.87+dfsg-2]
[23:19] -queuebot:#ubuntu-release- New: accepted bullet [i386] (bionic-proposed) [2.87+dfsg-2]
[23:22] -queuebot:#ubuntu-release- New binary: simgrid [ppc64el] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: simgrid [i386] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: simgrid [amd64] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: simgrid [armhf] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: simgrid [arm64] (bionic-proposed/universe) [3.18+dfsg-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [amd64] (bionic-proposed) [3.18+dfsg-1]
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [armhf] (bionic-proposed) [3.18+dfsg-1]
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [ppc64el] (bionic-proposed) [3.18+dfsg-1]
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [arm64] (bionic-proposed) [3.18+dfsg-1]
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [s390x] (bionic-proposed) [3.18+dfsg-1]
[23:51] -queuebot:#ubuntu-release- New: accepted simgrid [i386] (bionic-proposed) [3.18+dfsg-1]
[23:57] -queuebot:#ubuntu-release- New binary: keras [amd64] (bionic-proposed/universe) [2.1.1-1] (no packageset)


[19:33] <ibeardslee> morning
[20:10] <snail> mōrena koutou
[20:34] <ajmitch> morning
[20:35] <Atamira> morning
[20:38] <hads> morning
[20:49] <mwhudson> morning
[20:50] <chilts> morning
[21:08] <ojwb> morning
[23:51] <snail> I've just upgraded to 11.4 after a restart I now need 'ifdown --all; ifup --all' how do i fix that?
[23:52] <ojwb> do you mean 12.4?
[23:53] <ojwb> not that I know the answer for that either...
[23:53] <snail> no.
[23:53] <snail> i've got two more upgrades to go...
[23:53] <ojwb> ah
[23:54] <ojwb> hmm, i upgraded some servers from 10.04 to 11.10 and didn't hit that
[23:54] <ojwb> in 3 steps I mean
[23:55] <ojwb> which was good as I was ssh-ing to them
[23:56] <ojwb> i'd be tempted to just continue upgrading and see if it is fixed by the next one
[23:56] <ojwb> at least if you have physical access easily
[23:57] <snail> what's the command for doing it all at once?
[23:58] <ojwb> do-release-upgrade
[23:58] <ojwb> I think I used that rather than apt-get update && apt-get dist-upgrade


[00:32] <c_smith> heya
[00:32] <c_smith> bkerensa, you around?
[02:53] <c_smith> bkerensa, you around?
[03:40] <bkerensa> c_smith: I am now... Just a FYI everytime you say my nick I do get a push notification so I am aware you need me :)
[03:40] <c_smith> ah, ok
[03:41] <c_smith> bkerensa, I have an idea for the release party
[03:41] <c_smith> and that is inviting those of us who can't make it up to portland to join in IRC.
[03:41] <c_smith> I for sure will still be recovering from the operation that is shortly before that.
[03:45] <c_smith> oh, and JVLB was going to get in contact with you about some things.
[03:55] <bkerensa> c_smith: We always allow people to join on irc
[03:56] <bkerensa> c_smith: sure he can e-mail me
[13:29] <MaskilPDX> Good Morning
[15:32] <nathwill> congrats on getting the beta out with disk encryption working in ubiquity slangasek. :) big landmark, and super nice to see
[16:41] <slangasek> nathwill: thanks - though I did none of the work ;)
[17:09] <blkperl> slangasek: we deployed precise to our labs last week, we're crossing our fingers that we found all the workarounds needed :)
[17:10] <nathwill> blkperl, did the dconf + nfs home issue get resolved with that patch?
[17:22] <blkperl> nathwill: nah we pointed XDG_TEMP to /tmp
[17:22] <blkperl> dconf seems to accept that
[17:44] <slangasek> yay
[18:27] <bkerensa> nathwill: a Fedora Women needs some help with her Y Pipes
[18:28] <bkerensa> I asked he to ping u
[18:43] <nathwill> ok
[18:43] <nathwill> man, the more i play with rex, the more i like it :)
[18:44] <bkerensa> nathwill: rex?
[18:58] <nathwill> http://rexify.org/
[18:59] <bkerensa> nathwill: landscape
[18:59] <bkerensa> :D
[18:59] <nathwill> lol
[18:59] <nathwill> landscape do mass log-searches for you?
[19:00] <nathwill> like let me define groups and then grep a string in all of a particular log in a defined group?
[19:00] <nathwill> *without* running any extra software on each host?
[19:01] <nathwill> this is kinda like a cross between puppet and clusterssh
[19:05] <bkerensa> :D
[19:05] <bkerensa> nathwill: Release Party confirm Oct 20th 1:30 to 3:30pm Puppet is sponsoring Venue, Food, Beverage + Beer
[19:05] <bkerensa> it should be at there new bigger office too
[19:16] <nathwill> they have a new office?
[19:16] <nathwill> man...
[19:27] <bkerensa> uhh well yes
[19:27] <bkerensa> but its not open yet
[21:41] <tatica> hello :)
[21:48] <c_smith> hello
[21:49] <MaskilPDX> hello
[21:50] <tatica> bkerensa, thx for the invite
[22:03] <nathwill> hello!!!
[22:04] <c_smith> hello, nathwill
[22:06] <tatica> hello nathwill !
[22:06] <tatica> I was sent by the intergalactic powers to bother you nathwill and bkerensa about some yahoo pipes I'm trying to run
[22:06] <tatica> but real life (aka. work) got in the middle, so I will bother you guys later :)
[22:08] <MaskilPDX> Hya nathwill
[23:26] <nathwill> hey maskilpdx, how's things?
[23:26] <nathwill> ah hey tatica
[23:26] <nathwill> ah doh
[23:28] <MaskilPDX> Good
[23:29] <MaskilPDX> Writing up some proposals to change content filtering, backup solutions and av software
[23:31] <nathwill> niiice
[23:31] <nathwill> what're you looking at for solutions?
[23:33] <nathwill> (particularly interested in content filtering)
[23:39] <MaskilPDX> Currently they are running a openSUSE 11 box with squid and squidguard
[23:40] <MaskilPDX> I want to go to OpenDNS
[23:40] <MaskilPDX> For global filtering instead of having to adjust proxy settings
[23:41] <MaskilPDX> It's a school, and they are looking at maybe doing an open guest wireless
[23:41] <MaskilPDX> We can lock it way down, and have a bypass password for any site that teachers need to get to that is restricted to syudentd
[23:41] <MaskilPDX> students
[23:42] <MaskilPDX> Of that doesn't pass, I will put in an Ubuntu 12.04.1 server with dansquardian
[23:43] <nathwill> makes sense
[23:44] <nathwill> might even make sense to use both...
[23:44] <MaskilPDX> You can filer by name within Dansquardian, but it requires a clunky app called iDentD
[23:45] <nathwill> yeah, i don't know how grainy you're aiming for, but openDNS certainly gives you a good selection for types of content
[23:45] <MaskilPDX> It runds as a service on Windows, and passes on the user name. That name gets bassed through lists
[23:45] <nathwill> oh man...
[23:45] <nathwill> that sounds horrible
[23:45] <MaskilPDX> If the service stops or hicups for any reason (It's windows) it bonks, and is a pain in the butt
[23:46] <nathwill> so it's sending a user-name with every request?
[23:46] <MaskilPDX> I like Open DNS
[23:46] <MaskilPDX> Use it at home
[23:46] <MaskilPDX> Simple to set up and implement
[23:46] <nathwill> i take it that they're multi-tenant work stations?
[23:46] <MaskilPDX> Yes, evey request
[23:47] <MaskilPDX> There not realy multi tenant, it's just that Danguardian is ether on or off
[23:48] <MaskilPDX> There is no "bypass" button, other than that POS service
[23:48] <nathwill> hrm. seems like there'd be a way to know the client by the connection details instead of the request (easily forged)
[23:48] <MaskilPDX> You chnage the proxy settings to go through the Dans box, where there is nothing like that for OpenDNS
[23:49] <nathwill> yeah
[23:49] <MaskilPDX> But, there is the $$ and proactive vs reactive factor
[23:49] <MaskilPDX> OpenDNS $2000/year for 600 users (Great deal)
[23:49] <nathwill> well...
[23:49] <MaskilPDX> Sale right now $1200 year
[23:49] <nathwill> yeah, that's a good deal
[23:50] <MaskilPDX> Dans is free, but, you either are reacting when students find something, or you subscribe to a service for blacklists
[23:50] <nathwill> no volunteer-maintained lists as with opendns i take it?
[23:50] <MaskilPDX> Dan, fails open <sad trombone>
[23:51] <nathwill> i always hear about dansguardian, but haven't ever actually tried implementing it... though i will certainly be doing so once i get kids in the house
[23:51] <MaskilPDX> Nope, OpenDNS is pro-active in their lists, and are CIPA (Child Internet Protection Act) compliant
[23:52] <MaskilPDX> I was going to as well, but OpenDNS is better imo
[23:53] <MaskilPDX> Nothing is perfect
[23:53] <MaskilPDX> Dans is also in the Ubuntu repo
[23:53] <MaskilPDX> one click install