[08:40] <snadge> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/770283
[08:40] <snadge> *bump* ;)
[10:05] <gord> didrocks, lp:~gordallott/unity/fix-sc-integration should fix #963718 if you want to cherry pick it now for beta 2, will take quite some time yet before i can get it in trunk because of tests
[10:07] <didrocks> gord: ah excellent! thanks :)
[10:19] <snadge> i havnt seen that issue yet
[10:19] <snadge> no description in the bug :(
[12:31] <htorque> hi all! how can rebuilding libindicator (apt-get source, debuild) cause X to crash? i get this on two systems, nothing from apport.
[12:34] <seb128> htorque, what do you have in /var/log/Xorg.0.log(.old)?
[12:35] <htorque> seb128: that's the last output: http://paste.ubuntu.com/900358/ - let me check the X log
[12:36] <htorque> seb128: looks like a clean exit? http://paste.ubuntu.com/900360/ (same on the second system)
[12:37] <seb128> htorque, what about syslog?
[12:37] <seb128> htorque, could be gnome-session hitting an issue
[12:37] <htorque> caused by a test?
[12:38] <seb128> htorque, well, you never know
[12:38] <seb128> bugs have to be caused by something
[12:38] <seb128> tests tend to be harder stress cases than normal use
[12:38] <seb128> they are less laggy than users :p
[12:38] <htorque> yeah, that was a real question, not a "i don't think so" ;)
[12:53] <mhall119> davidcalle: ping
[12:53] <davidcalle> mhall119, pong
[12:56] <mhall119> davidcalle: hey, any update on your lenses/scopes for Oneiric?
[12:57] <davidcalle> mhall119, I have to change a lot of code, to simplify the apparmor profiles. People are reporting that the Graphic Design lens and scopes in USC are crashing because of a wrong profile. I'm trying to make things clearer in the code for the arb review.
[12:58] <mhall119> davidcalle: did they give you the apparmor profile, or did you have to make it yourself?
[12:58] <davidcalle> mhall119, no, they created and integrated it.
[12:58] <mhall119> ok
[12:59] <htorque_> seb128: i'm not finding any interesting output. this is from .xsession-errors: http://paste.ubuntu.com/900393/ - building it in a VT also causes a logout.
[12:59] <mhall119> I see that Teester had some apparmor issues too
[12:59] <mhall119> with  his music scopes
[12:59] <davidcalle> mhall119, oh ok
[12:59] <mhall119> the ARB is working on fixing his, they can probably help you with yours too
[13:00] <seb128> htorque_, nothing in /var/log/syslog?
[13:04] <htorque_> seb128: at least i don't see anything. should be in this snippet: http://paste.ubuntu.com/900406/
[13:05] <seb128> htorque_, got to a vt, attach gdb to gnome-session
[13:05] <seb128> htorque_, go to another vt, attach gdb to X
[13:05] <seb128> htorque_, then trigger the bug and check the bts
[13:05] <seb128> vts
[13:07] <htorque> seb128: that somehow locked up the system. trying to do this remotely.
[13:07] <seb128> htorque: just type "c" in gdb
[13:07] <seb128> that should lock the xsession for sure
[13:07] <seb128> until you do "c"
[13:07] <seb128> since the blocks xorg and the session
[13:08] <htorque> i did that for both gdbs, couldn't go back to VT7 (or do anything else)
[13:08] <seb128> weird
[13:11] <htorque> seb128: meh, "Connection to chaos closed by remote host."
[13:12] <seb128> htorque, seems like your kernel is unhappy
[13:12] <seb128> or you get oomed
[13:12] <mhall119> you named your box 'chaos'?
[13:12] <htorque> :-)
[13:12] <mhall119> well there's your problem
[13:14] <htorque> dmesg shows: do_trap: 45 callbacks suppressed
[13:14] <htorque> Xorg[10700] trap int3 ip:... sp:... error:0
[13:19] <jussi> hrm, was it "design" or "not yet implemented" that I cant drag some content (copy text, a file etc) to hover over a launcher, wait until that window pops up and drop it into that window?
[13:20] <jussi> ie. I have a picture in nautilus, I grab it, hover over skype chat window, wait until it pops up and drop it there to send to the person on skype? (I do this on kde regularly)
[13:40] <jussi> Also, I had a thought. for the launcher icon size setting thats currently in ccsm experimental settings, perhaps it is more useful to be a percentage of screen size rather than a pixel number?
[14:18] <htorque> seb128: i managed to get a crash file, but the backtrace just shows 77 frames of "??" (i have all the xorg dbg packages installed)
[14:18] <seb128> htorque, was it xorg segfaulting?
[14:18] <seb128> htorque, do you have the filename where it did segfault?
[14:19] <htorque> seb128: unfortunately it's "signal 5, trace/breakpoint trap"
[14:22] <seb128> htorque, no filename on the gdb lines?
[14:22] <seb128> like "?? in driver.so"
[14:23] <htorque> seb128:  no, it's just "?? ()"
[14:24] <seb128> htorque, :-(
[14:24] <mgedmin> dpkg -S driver.so; apt-get install whateverdpkgfound-dbgsym sometimes helps
[14:24] <htorque> at least the package builds without the tests
[14:24] <seb128> htorque, well you can try to compare the addresses to /proc/$(pidof process)/maps
[14:25] <htorque> pidof which process?
[14:26] <seb128> htorque, the one which did signal 5 and that you have in gdb
[14:28] <htorque> seb128: so X, but i don't find anything in there. :-(
[14:28] <seb128> htorque, you mean?
[14:28] <htorque> in the maps file
[14:29] <seb128> htorque, it's empty?
[14:29] <htorque> oh, wait, i grepped with leading zeros
[14:30] <htorque> hm, no, i don't find, e.g. frame address #0 in there.
[14:31] <htorque> aren't they different each time i start X?
[14:34] <htorque> seb128: oh, you mean ProcMaps in the crash file. sorry, misunderstanding. :-)
[14:34] <seb128> htorque, well the goal was to map the gdb lines address to the procmaps to see in what binary the code is
[14:35] <seb128> htorque, but if you got address #0 things are really screwed up
[14:35] <htorque> no that's frame 0 ;)
[14:36] <htorque> seb128: first two frames map to ld-2.15.so, the following to "/drm mm object (deleted)"
[14:40] <htorque> anyways, libindicator builds without the tests, so one of those tests triggers the problem. i obviously don't have enough experience to help, should i at least make this an upstream bug report?
[14:44] <seb128> htorque, well the deleted seems to indicate your issue is an xorg or driver issue
[15:21] <mhr3_> davidcalle, you seem to be using special actor uri in ulv, can you change that to more standard dbus://unique.name.service ?
[15:22] <mhall119> what's the correct capitalization, NUX or Nux?
[15:22] <mhr3_> davidcalle,  including the ".service"
[15:25] <davidcalle> mhr3_, what do you mean by special actor uri?
[15:25] <mhr3_> davidcalle, i saw lens://unity-lens-videos uri in a log
[15:26] <mhall119> also, does anybody have something that maps Unity components/features to code files?
[15:26] <mhall119> something that says "If you want to change the Launcher, you'll do it in files X, Y and Z"?
[15:27] <davidcalle> oh, right.  What kind of names do other data sources use?
[15:27] <mhr3_> they're usually apps, so they use application://desktop_id
[15:27] <mhr3_> services use dbus:// as mentioned above
[15:28] <davidcalle> mhr3_, would dbus://unity.lens.video make you happy ? :)
[15:29] <mhr3_> .service
[15:29] <davidcalle> .service
[15:29] <mhr3_> actually, no
[15:29] <mhr3_> it's not unique dbus name
[15:29] <mhr3_> use the same thing you pass to the RequestName call
[15:30] <davidcalle> mhr3_, ok
[15:31] <mhr3_> btw any progress on the flickering issue?
[15:34] <davidcalle> mhr3_, didn't have any time to work on it, and I probably won't until friday. Shouldn't be a big deal to fix it, though.
[15:37] <rye> It looks like i have reproduced bug #943851 in firefox now, after it is fix released :(
[15:39] <mhall119> thomi: ping
[15:40] <rye> testcase: http://paste.ubuntu.com/900641/
[15:40] <rye> :(
[15:56] <mhr3_> davidcalle, don't underestimate async issues ;)
[16:03] <BEC> I don't use Unity yet, but Im wondering about two things:
[16:03] <BEC> 1) how to restart Unity (in gnome I use killall gnome-panel)?
[16:03] <BEC> 2) where is the boot men located?
[16:06] <mhall119> BEC: "unity --replace" to restart it
[16:06] <BEC> there's a thread on the forums about that but it didnt help its poster
[16:06] <bjf> i have a dual-monitor precise configuration (just recently re-installed from scratch). I am getting the launcher on both monitors. How can I configure it to only the primary screen?
[16:06] <mhall119> the boot menu, I assume you mean Grub2, I'm not sure where that is, but it's got nothign to do with Unity
[16:07] <BEC> mhall119, in 10.04 it used to be under the name menu.lst
[16:07] <mhall119> bjf: check the Displays settings
[16:07] <BEC> can't find it in 12.04
[16:07] <mhall119> BEC: yeah, it changed between Grub 1 and Grub 2, I don't know where it is now, but again it's not a Unity thing
[16:08] <BEC> mhall119, ok thx
[16:08] <mhall119> BEC: you can try asking in #ubuntu, or maybe see if there's a specific channel for grub
[16:08] <mhall119> bjf: did you find it?
[16:08] <bjf> mhall119: thanks, did the trick (though i got a couple error dialogs popup)
[16:08] <mhall119> bjf: report any bugs you find please
[16:09] <bjf> mhall119: ack
[16:24] <bjf> mhall119: bug 965455 and bug 965461
[16:33] <htorque> charles: oops, g_clear_error()... thanks! i probably should stay away from mem leaks for now. ;-)
[17:13] <om26er> davidcalle, hey
[17:14] <om26er> videos lens say "sorry, there's nothing that matches your search" but at the same time I see online videos in the lens :/
[17:23] <davidcalle> om26er, that's not nice. Is there a bug opened for it?
[17:23] <kklimonda> huh, so the weird bug when I try to switch between applications that are on a different workspaces is back
[17:24] <kklimonda> most of the time I end up moving windows around :(
[17:29] <davidcalle> mhr3_, the remote vids scope triggers a queue search changed when it's opened, to refresh it's recommendations (results from the server without a search). The "no results" hint is displayed, on top of these results, when the lens is opened.
[17:29] <davidcalle> Any idea?
[17:32] <davidcalle> mhr3_, then, when a search has been typed, and erased, it works fine.
[17:34] <om26er> davidcalle, will report a bug the next time I see it. so I have a screenshot as well
[17:35] <davidcalle> om26er, ty, apparently, it only happens if no search string has been typed in the lens during the session.
[17:38] <om26er> gord, hey! see bug 964061
[17:40] <om26er> https://launchpadlibrarian.net/98183404/hudbug.png
[17:48] <zgreg> the looking glass isn't centered correctly, too
[17:48] <zgreg> should be moved a bit to the right, equal to the dash search
[18:45] <bkerensa> popey: Do you know why Thunderbird's icon in the Unity Launcher would be defunct for me? It will launch Thunderbird but once TB is launched if I click the icon it doesnt bring it to front or do anything... I cannot even close the app from launcher
[19:23] <mhall119> bkerensa: did you do an upgrade without a restart?
[19:24] <charles> htorque: no, don't stay away from mem leak patches... keep 'em coming, they're great
[19:25] <dakira> hi. are ubuntus default key binding on-topic here?
[19:25] <bkerensa> mhall119: Nope this has been since a upgrade.... all other apps work fine in the launcher except Thunderbird
[19:25] <bkerensa> sometimes the Thunderbird icon wont even show up in the launcher at all
[19:30] <thomi> mhall119: pong
[19:32] <mhall119> thomi: oh, geez, I don't even remember what I was pinging about now...
[19:32] <thomi> mhall119: haha, ok.  There is currently no way out of this zoom. hitting super+r again does nothing. Users hitting super+r by accident will be stuck.
[19:35] <mhall119> thomi: oh, I was asking about NUX vs. Nux, but om26er answered me already
[19:35] <mhall119> jussi: the content was there, just prior to the ping ;)
[19:36] <jussi> hehe
[19:36] <thomi> :)
[19:39] <popey> damnit, I just pressed super+r
[19:39] <dakira> popey: switch to an empty desktop, click on the background and press super+r again
[19:39] <popey> i restarted unity ☺
[19:39] <popey> dakira: is there a bug filed?
[19:40] <dakira> popey: yeah.. I even fixed it already.. I'm just not sure how to proceed
[19:40] <dakira> https://bugs.launchpad.net/ubuntu/+source/compiz-plugins-main/+bug/953278
[19:42] <dakira> popey: I have never worked directly with ubuntu packages and couldn't quickly find out about the expected bug-fixing workflow.. people on #bzr told me it is different from just proposing a merge with a regular launchpad project.
[20:02] <thomi> wow, what is super+r supposed to do, and how can I undo it?
[20:03] <spenen> haha thomi, seems like I want to know that too
[20:04] <spenen> I can't read a command without trying it
[20:04] <mhall119> what is super+r?
[20:04] <spenen> oh, I pressed it again a feew times and then it zoomed out
[20:04] <spenen> mhall119: everything gets zoomed
[20:04] <mhall119> oh
[20:08] <dakira> thomi, mhall119 as I wrote above.. super+r zooms to the currently active window. You can undo it by "selecting" the desktop and hitting super+r again (LP: #953278)
[20:13] <mhall119> wow, that's weird
[20:13] <mhall119> I hope it's intended that super+r again will undo it
[20:14] <dakira> mhall119: there's no code in compiz or the plugin that supports this being a toggle. I commited a fix to disable this..
[20:28] <mhall119> very nice review of Unity 5.8: http://www.techrepublic.com/blog/opensource/ubuntu-unity-58-seriously-impresses/3514
[20:44] <jussi> how do I add more lenses, and where do I get them?
[20:45] <jussi> mhall119: I read that one, was spot on I think, though not overly detailed
[20:45] <mhall119> jussi: one Oneiric or Precise?
[20:45] <jussi> mhall119: precise
[20:45] <mhall119> jussi: on Oneiric there are more available in the 'extras' repository, but they haven't opened that up for Precise yet
[20:46] <zgreg> who's familiar with the unity dash code?
[20:46] <jussi> oh, ok :/ got a deb or 2 for me?
[20:46] <mhall119> jussi: yeah, one second
[20:46] <dakira> jussi: check out https://launchpad.net/~scopes-packagers/+archive/ppa
[20:46] <mhall119> jussi: https://launchpad.net/~scopes-packagers/+archive/ppa
[20:46] <mhall119> heh
[20:46] <zgreg> the dash seems to jump through many hoops for blurring the background, and it's slower than it should be
[20:48] <jussi> mhall119: when is the extras going to be opened? (and why are they there and not in universe?)
[20:49] <mhall119> jussi: it's easier to get them into extras than into Universe
[20:49] <mhall119> plus they can be added to extras after the release date
[20:50] <mhall119> extras is going to be opened a few weeks before release, IIRC, so sometime soon
[20:50] <dakira> jussi: I'd really use the PPA. the lenses break often (when the sites they search change behavior). With the PPA you could get an update within an hour, with official repositories it'll take way longer.
[20:51] <jussi> dakira: yes, I suppose, I just dont want to taint my system for bug reporting
[20:52] <dakira> jussi: the ppa only adds extra lenses that don't change behavior outside of those lenses/scopes. And there's always ppa-purge if you're unsure about a bug.
[20:53]  * jussi eyes dakira...
[20:53] <jussi> hrm, ok then
[20:53] <jussi> ppa added :)
[20:53] <jussi> what are the standout ones?
[20:55] <jussi> also, is there a shorcut key for changing which lense Im in.. ?
[20:56] <dakira> jussi: ctrl+tab is the new shortcut
[20:56] <dakira> jussi: when dash is open, I mean.
[20:56]  * jussi notes that mhall119 fails at naming lens packages ;)
[20:57] <jussi> dakira: ahh, yes
[20:57] <jussi> hey wait, whats the difference between a lens and a scope?
[20:59] <dakira> jussi: think of scopes as search engines and lenses as the representation of the results
[20:59] <jussi> ok, thanks. Ill look more in the morning. now is sleep time :)
[20:59] <dakira> jussi: the graphic-design-lens has many different scopes (like deviantart, flickr and more) to pull results from
[20:59] <dakira> jussi: I love the torrent scope ;)
[21:00] <jussi> :D
[21:00]  * jussi really goes to bed now. nini all
[21:02] <mhall119> jussi: naming has never been my strong-suit
[21:11] <dakira> mhall119: oh. you ARE the onehundredscopes guy ;) great stuff! Have you ever thought about joining forces with the atareao lenses guy?
[21:16] <mhall119> dakira: no, davidcalle is the onehundredscopes guy
[21:17] <mhall119> I'm the "hand full of scopes" guy :)
[21:17] <davidcalle> mhall119, lol
[21:19] <dakira> mhall119: just saw your name on the ppa ;)
[21:19] <dakira> davidcalle: so from a user perspective it would be great to have one ppa for all your scopes and lenses needs. Have you ever talked to atareao?
[21:20] <davidcalle> dakira, the atareao team is really great, indeed. Scopes are really new stuff, so we are all trying our own ways to work on them. Hopefully next cycle, with standardization, guidelines and such, collaboration will come.
[21:21] <dakira> I see.
[21:23] <davidcalle> dakira, but one PPA for testers, before pushing the packages to the Software Center, would be nice, I agree.
[21:26] <dakira> davidcalle: the problem with scopes in the software center is that they are broken for a long time if the sites they query change behavior
[21:27] <dakira> davidcalle: that is why I like PPAs. I fixed a small thing in the piratebay-scope a couple of days ago and I was just impressed by the new package being available 2h later ;)
[21:27] <davidcalle> dakira, I very much agree. I had the problem this week-end on a lens. The process to go to the Software Center and update is quite long, but things are getting better.
[21:28] <davidcalle> dakira, oh, it was you ? :)
[21:28] <dakira> yup ;)
[21:28] <dakira> I should use my launchpad username on freenode i guess
[21:28] <davidcalle> I don't ^^
[21:42] <bschaefer> thumper, ping, I have a question about expected behavior concerning the dash and alt+f1
[22:33] <bschaefer> thomi, I have an autopilot test for you to review :)
[22:33] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/disable-alt-f1-dash/+merge/99440
[22:33] <bschaefer> when you get a chance
[22:33] <thomi> cool, I'll check it out
[22:33] <bschaefer> thank you


[02:01] <infinity> LoganCloud: When you sync -f over Ubuntu FTBFS fixes and then the package fails to build, the least you could do it bring back the patch in a merge. :P
[02:15] <LoganCloud> infinity: Link paz
[02:15] <LoganCloud> *Plz
[02:16] <infinity> LoganCloud: openimageio ... I'm re-fixing it now, don't worry.  Just wanted to vent.
[02:16] <infinity> LoganCloud: If we have a delta, it would be nice to check WHY we have a delta, and not just sync over.
[02:17] <Noskcaj> doanac, Mind if i merge sqlite3? It fixes an ftbfs in python-apsw
[02:17] <Noskcaj> oops. doko_^
[02:21] <Logan_> infinity: Oh right. I had no way of testing on powerpc, so I synced to see if the new upstream release would fix it. I didn't get a build failed message for powerpc because I didn't do the latest changelog entry, so I forgot to go and check. Powerpc had a decent backlog at the time, so it didn't build immediately. My apologies.
[02:22] <Logan_> If I could have it my way, people who copied over would get e-mail notification for failed builds as well.
[02:22] <infinity> Logan_: You could have noted that my patches still applied cleanly and blindly merged.  Or, better yet, just asked me about it.
[02:22] <infinity> (I thought the uploader did get FTBFS notifications for copies...)
[02:22] <infinity> wgrant: ^
[02:23] <Logan_> I don't like blindly merging unless I know that the delta is necessary.
[02:23] <infinity> If they don't, that should be trivial to fix.
[02:23] <Logan_> We definitely don't.
[02:23] <infinity> Logan_: Sure, so the "ask me" bit would have worked.
[02:23] <Logan_> Understood.
[02:23] <Logan_> infinity: http://cl.ly/image/2f1b1g041g22
[02:23] <infinity> Logan_: I'm re-testing both my patches now.  I know -latomic is needed (and will be pretty much forever, though I might convince the Debian maintainer to take my patch instead of his), the -ldl one might not be.
[02:24] <Logan_> It doesn't appear that the -ldl is necessary anymore, given that it built on all architectures except for armhf and powerpc, and armhf is a carryover from last time.
[02:25] <infinity> Logan_: Yeahp, looks like my build here is finishing off with just the atomic fix.
[02:26] <infinity> dpkg-shlibdeps: warning: symbol dlopen used by debian/libopenimageio1.2/usr/lib/libOpenImageIO.so.1.2.3 found in none of the libraries
[02:26] <infinity> No, it's still underlinked.  Just not FTBFS.  Adding back both patches. :P
[02:27] <Logan_> Alright, touché. You got me. :P
[02:27] <Logan_> Although I still want build notifications for packages that I copy over. That seems like a no-brainer to me.
[02:27] <infinity> Yeah, I agree.
[02:27] <infinity> We'll see about sorting that.
[02:27] <Logan_> Can I file a bug somewhere?  I didn't realize you were doing that against the launchpad project.
[02:33] <infinity> I wasn't trying to be funny, I just can't type to save my life. :P
[02:35] <Logan_> infinity: Bug 1262952
[02:36] <Logan_> infinity: Also can we get powerpc PPAs? :P (Or PPAs that feed into the main buildds?)
[02:36] <infinity> Logan_: No, and no, but for the first, in the next year or so, maybe (no promises).  Never the second.
[02:37] <Logan_> :(
[02:37] <infinity> Public PPAs require a sane virtualization story, which we may have soonish on powerpc.  And we'll never let public PPAs build on the distro builders, cause any twit with an email address can register a public PPA, they're impossible to audit.
[02:37] <infinity> So, naturally, I don't want that code running on the distro buildds.   Awkward.
[02:47] <infinity> Well, the last uploader of substance it the better person to ask. :)
[02:47] <xnox> Logan_: if we had binNMUs in launchpad, there wouldn't be no-change rebuilds, so do skip over those.
[02:47] <Logan_> Can we have those?
[02:47] <Logan_> That would make transitions less of a pain in the ass.
[02:47] <xnox> Logan_: also note that e.g. if one tried to do syncrequest, it explicetely states the reason why the delta is dropped.
[02:47] <infinity> We can argue about them some more.
[02:48] <Logan_> By the flagpole?
[02:48] <xnox> Logan_: "i don't understand this delta" or "i don't know if it's still needed" are never the right answer to drop something, or apply.
[02:49] <Logan_> I never said that. Well, I kind of said the latter. But I had no way of testing the latter. But I should've asked Adam. So I'm silly.
[02:50] <infinity> xnox: I think he's been appropriately chastised by me, I don't need backup. :P
[02:50] <Logan_> I feel victimized. :'(
[02:51] <xnox> Logan_: i'm sorry.
[02:51] <Logan_> I'm going to go contribute to Debian instead. They'll be more forgiving, right? :P
[02:51] <Logan_> xnox: Haha, it was my fault. No worries.
[02:51] <Logan_> Hold up, updating the firmware on my router. brb
[02:52] <xnox> LoganCloud: Logan_: you do a lot of work, and it's mostly correct.  For the upx-ucl package, I was actually proactive and e-mailed the person who introduced a certain arm delta because I wasn't sure if it was necessary. But he never wrote back. What should I do?
[02:58] <Logan_> I built the package myself in my armhf PPA, and it built successfully, but I'm not sure if it's just for optimization.
[02:58] <Logan_> *the Debian package
[02:58] <Logan_>     - debian/rules: [arm] needs porting to thumb2; use -marm as the code does a lot of low level hacking not yet ready for thumb2.
[02:59] <Logan_> ^ that's the delta that's been carried over for a good number of revisions, and I'm not sure if it's still necessary.
[03:00] <infinity> Logan_: You asked asac?
[03:00] <Logan_> Correct.
[03:00] <Logan_> And he never wrote back. It was sad.
[03:00] <infinity> Logan_: So, note that it has "ifeq (armel,$(DEB_BUILD_ARCH))"
[03:01] <Logan_> > I noticed that you made this change to the upx-ucl package in 2010. I was wondering if it is still necessary, as I did a test build with the Debian package in my ARM PPA, and it built successfully. Or is this change deeper than just making the package build? Just trying to get rid of old deltas wherever possible. :)
[03:01] <infinity> Logan_: Which doesn't match any arch we build for. ;)
[03:01] <Logan_> Okay well.
[03:01] <Logan_> Go away. :P
[03:01] <infinity> So, if the patch is still necessary, it's wrong anyway.
[03:01]  * infinity looks at the original bug.
[03:02] <infinity> That's the most useless bug ever.  Nice.
[03:02] <infinity> Logan_: If it currently builds on armhf and no one's complaining, just drop the delta.
[03:02] <Logan_> Like what is thumb2.
[03:02] <Logan_> Okay.
[03:03] <infinity> Logan_: thumb2 is an ARM instruction set.
[03:03] <Logan_> The reason I thought it was for optimization purposes was because it built successfully on armel before asac's upload. So I don't know.
[03:03] <Logan_> Okay, I will sync.
[03:03] <Logan_> ...after I test build again, of course! :P
[03:05] <infinity> Logan_: Of course, while you're in there, I wonder if it might be trivial to port to arm64. :P
[03:06] <Logan_> It doesn't look terribly trivial. At least, we'll see with this new upstream release.
[03:07] <Logan_> infinity: This is probably a dumb question, but what is the endianness of arm64 in Ubuntu?
[03:08] <infinity> Logan_: little.
[03:08] <infinity> Logan_: Looking at src/miniacc.h, I imagine it's just a question of following all the ifdef trees and updating for a new arch.
[03:09] <infinity> If you know all the right values. :P
[03:09] <Logan_> I think I'd trust you more with that.
[03:09] <Logan_> Hi Noskcaj.
[03:09] <Noskcaj> hey Logan_
[03:09] <Noskcaj> I'll probably disconnect soon so i can play dota.
[03:10] <Logan_> Sounds reasonable.
[03:16] <StevenK> Ah, another dota player
[03:20] <Logan_> Where should you call dh_autoreconf in a traditional debhelper rules file? Configure or build?
[03:22] <Logan_> I guess it would be where I would call dh_autotools-dev_updateconfig, which varies...
[03:29] <Logan_> infinity: Okay, so if I see something like "dpkg-shlibdeps: warning: debian/gtk2-engines-equinox/usr/lib/gtk-2.0/2.10.0/engines/libequinox.so contains an unresolvable reference to symbol floor: it's probably a plugin," that means it's underlined?
[03:29] <Logan_> *underlinked
[03:36] <Logan_> ^ Or someone else.
[03:37] <infinity> Logan_: Well, in that case, it actually is a plugin, so if the thing it plugs into has that symbol, you're okay.
[03:37] <infinity> Logan_: But it could just as easily be underlinked (probably wants -lm)
[03:38] <Logan_> How do I determine if something is a plugin or not?
[03:38] <infinity> If it's not a proper shared library in the library path, with an SONAME.
[03:38] <infinity> Then it's PROBABLY being dlopened by something else as a plugin.
[03:38] <Logan_> So, if it doesn't provide a package for it, I'm good?
[03:39] <dobey> if i have a package that is i386-only, what's the proper way to have a dependency satisfied by any architecture (such as wget), versus requiring the i386 one?
[03:39] <Logan_> Like a lib*# package.
[03:39] <infinity> Doesn't have anything to do with the packaging, really.  Some packages have dozens of proper libraries in a single package.
[03:39] <Logan_> arch:any I think
[03:39] <infinity> dobey: That was a little too genericized for me to be sure what you want.  What's the exact thing going on here?
[03:40] <Logan_> package:any actually
[03:40] <dobey> infinity: my package is i386-only, and i need to depend on wget, but don't want to require wget:i386, when installed on amd64.
[03:40] <dobey> no, foo:any doesn't work
[03:40] <Logan_> Oh. :(
[03:42] <infinity> dobey: Oh yes, then Logan_ is right.  If wget is multi-arch:allowed
[03:42] <dobey> infinity: so i want the installed wget:amd64 to be able to satisfy the dep on wget
[03:42] <dobey> eh i get dependency errors when trying to install, when depending on wget:any
[03:43] <Logan_> infinity: I'm still confused about where to put dh_autoreconf in an old debhelper rules file, lol. The only logical place (to me) is build-stamp for the package I'm dealing with, and it complains about being run more than once.
[03:43] <infinity> Yeah, because wget is m-a:foreign, not allowed.  Which is probably correct.
[03:43] <infinity> Logan_: Right before you run configure.
[03:43] <Logan_> Well, ./configure is in build-stamp.
[03:43] <infinity> Logan_: And dh_autoreconf_clean before dh_clean.
[03:44] <infinity> Logan_: Does build-stamp get run more than once due to wildcard funkiness or something?
[03:44] <dobey> infinity: so i can't do it, or just having "wget" as the dep will work as i hope?
[03:44] <Logan_> infinity: Apparently.
[03:44] <infinity> Logan_: If so, you'll want to make build-stamp depend on an autoreconf rule and put it in there.
[03:45] <Logan_> ...I have no idea. Is depending like: build: build-arch build-indep
[03:45] <infinity> Logan_: Which package?
[03:45] <infinity> dobey: So, this could be a minor failing of the multi-arch spec.  With a :foreign wget, I can't quite sort out how to say "any old one is good enough".
[03:45] <infinity> slangasek: ^
[03:45] <Logan_> infinity: leptonlib. I just did a config.{sub,guess} update with autotools-dev, but ppc64el needs the libtool fix.
[03:46] <infinity> dobey: One wonders why your package is i386 only. :)
[03:46] <dobey> infinity: because it's installing a proprietary thing that is only built as i386, and no 64-bit binary available
[03:46] <infinity> dobey: Fair enough.
[03:51] <infinity> Logan_: So, it seems to autoreconf fine here.
[03:51] <Logan_> Really? Is it because I put it at the top of build-stamp instead of directly before ./configure?
[03:51]  * infinity waits for the build to finish...
[03:52] <infinity> Oh, lolz.
[03:52] <infinity> No, it's because this debian/rules is broken.  Sec.
[03:55] <infinity> Logan_: I'll see if you can spot the error before I upload. :P
[03:55] <Logan_> Ooh, I like that game
[03:56] <infinity> My laptop is grinding on a glibc build, so my pre-upload test-build could take a while.
[03:56] <infinity> You have a few minutes.
[03:56]  * infinity starts watch.
[03:58] <Logan_> infinity: Is it because install depends on build?
[03:58] <infinity> Logan_: Sort of, but not really.
[03:59] <infinity> (It has to)
[03:59] <Logan_> "touch builond-stamp"
[03:59] <infinity> Time's up, my build fi...
[03:59] <infinity> And you got there.
[04:00] <infinity> So, there's one other minor complaint I have with the rules file, but that's the glaring bug. :)
[04:00] <Logan_> What's your minor complaint?
[04:00] <Logan_> Other than it not being a dh sequencer? :P
[04:00] <infinity> http://paste.ubuntu.com/6603472/
[04:00] <infinity> The other minor complaint is running dh_ commands before testdir completely defeats the purpose of running testdir. :)
[04:01] <Logan_> infinity: Wait. Don't you not need the autotools commands if you're running autoreconf?
[04:01] <infinity> Logan_: That depends on if the project is using automake.  Oh, which it is.
[04:01] <infinity> So, in this case, probably don't need both.
[04:02] <infinity> Logan_: Easiest way to check is to run dh_autoreconf and see if all copies of config.* got updated.
[04:03] <infinity> Logan_: In this case, they do, so yes, you can and should drop dh_autotools-dev
[04:03] <Logan_> Do you want me to, or do you?
[04:03] <infinity> Logan_: Want me to upload this so I own it, or do you want the honors?
[04:03] <infinity> Hah.
[04:03] <Logan_> I'll thank you in the upload.
[04:04] <infinity> Heh.
[04:06] <infinity> Logan_: So, your final diff looks like http://paste.ubuntu.com/6603500/ ?
[04:06] <Logan_> Yessir.
[04:07] <infinity> Logan_: Shiny.  Upload away.  I can't wait for the glorious praise in your changelog.
[04:12] <Logan_> infinity: https://launchpad.net/ubuntu/trusty/+source/leptonlib/1.69-4ubuntu3
[04:13] <Logan_> LOL, I misspelled the typo in the changelog. Whatever.
[04:14] <Logan_> I had one job...
[04:15] <infinity> Logan_: Oh, the irony. :)
[04:16] <Logan_> I give up. Fedora, here I come. :P
[04:16] <StevenK> You'll be back.
[04:23] <infinity> Logan_: On the plus side, it fixed ppc64el, so you win in the end.
[04:24] <Logan_> Yay!
[04:24] <Logan_> Oh, by the way, be prepared to get an onslaught of uploads from a bored Logan over winter break. :P
[05:20] <pitti> Good morning
[05:54] <Noskcaj> Why isn't the qa.ubuntuwire.com debcheck working?
[06:29] <pitti> roaksoax: hey, how are you?
[06:29] <pitti> roaksoax: any chance we can sort out bug 1254053 soon?
[06:30] <pitti> roaksoax: -9.1 dependencies are down to two, maas and glom
[06:30] <pitti> and the removal of 9.1 is waiting in trusty-proposed
[08:09] <pitti> RAOF: ah, still one failure :/ http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console
[08:10] <pitti> RAOF: sorry, https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-colord/26/ARCH=i386,label=adt/console
[08:10] <pitti> RAOF: not very useful output though, no cookies for the automake parallel runner :/
[08:11] <RAOF> No, it actually did manage some useful output
[08:11] <RAOF> libcolord:ERROR:cd-self-test.c:3585:colord_icc_save_func: assertion failed (cd_icc_get_version (icc) == 4.09): (4.08 == 4.09)
[08:12] <pitti> ah
[08:12] <RAOF> Also, grr?
[08:12] <RAOF> That test works fine in my run-adt-tests VM
[08:13] <pitti> RAOF: did you run with proposed? (-P)
[08:13] <pitti> maybe there's some newer ICC stuff in -proposed
[08:13] <RAOF> Maybe.
[08:13] <pitti> (nothing apparent, though)
[08:13]  * RAOF runs with -P
[08:13] <pitti> RAOF: also, does this actually test the installed colord, or the one from the build tree?
[08:13] <pitti> RAOF: (I probably already asked, but I forgot)
[08:13] <ara_> good morning!
[08:14] <RAOF> It tests the installed colord, and the libs from the build tree.
[08:14] <ara_> this grub2 precise-proposed upload has all its bugs verified: https://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.14
[08:14] <ara_> can we get it uploaded to -updates now, please?
[08:16] <jamesh> sil2100: hi.  Sorry I missed your reply yesterday: it got a bit late for me.
[09:00] <dholbach> good morning
[09:15] <mlankhorst> morning
[09:21] <pitti> jibel: FYI, filed python-docutils failure as debian bug 732679; apparently some change (regression?) in 2to3 in python 3.3.3
[10:27] <ara_> cjwatson, hey! could you upload grub2 to precise-updates, please? all the bugs are now marked as verified. thanks!
[10:36] <cjwatson> ara_: we don't normally release SRUs on Fridays, and I don't know if I'll be around over the weekend in case it explodes; can it wait until Monday?
[10:36] <cjwatson> (I'll be around a bit, but kind of hoping not to be pulled into a firefight)
[10:37] <ara_> cjwatson, sure, it can, I will let people waiting on it know, thanks!
[10:37] <ara_> :)
[10:37] <cjwatson> I can probably even do it on Sunday evening or something, will see
[10:38] <cjwatson> ara_: (thanks for the reminder though)
[10:41] <ara_> cjwatson, I think Monday should be OK, thanks!
[10:45] <doko> ev, xnox: any idea about https://launchpad.net/ubuntu/+source/whoopsie/<IP_ADDRESS> ?
[10:55] <dholbach> robru, charles, Saviq: can one of you have a look at https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194?
[10:55] <dholbach> (you all seem to be here and have done some work or review work on it before)
[10:57] <infinity> doko: The glibc strstr fix is in, BTW.  You can un-gimp java.
[11:03] <ev> doko: what about it? :)
[11:04] <ev> oh
[11:04] <ev> I see the failed builds ow
[11:04] <doko> ev: the ftbfs
[11:04] <Saviq> dholbach, I'll leave it to charles, I've not enough domain knowledge
[11:05] <ev> not sure offhand. I wonder if glib has broken
[11:05] <ev> apols, I don't have time to dig deeper at the moment
[11:06] <dholbach> Saviq, gotcha, thanks
[11:06] <dholbach> Saviq, it got a positive review from the security team already, so I hope we can get this in soon :)
[11:07] <Saviq> dholbach, indeed, would be pretty useful
[11:07] <dholbach> yep
[11:10] <darkxst> dholbach, sorry, got a bit confused with epiphany-browser-webkit2 package, never actaully made it into the archives, have dropped it from the debdiff now
[11:10] <dholbach> darkxst, cool
[11:11] <dholbach> darkxst, I'll take a look at it later on, if nobody of the #ubuntu-desktop guys beats me to it
[11:11] <Laney> ev: it's okay, I think I know the fix
[11:11] <Laney> doko: ^
[11:11] <ev> Laney: star! Thank you so much
[11:12] <darkxst> dholbach, thanks
[11:40] <mlankhorst> doko: wrt MIR for lcov and libjsoncpp, I think for llvm-3.3 we had the same issue and just disabled lcov and the external libjsoncpp copy
[11:42] <mlankhorst> doko: https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1218220
[11:42] <xnox> infinity: what is the waitid linux/libc header mismatch issue? is there pointer to debian-bug or upstream discussion about it?
[12:08] <Laney> if I comment out the g_timeout_add_seconds it just sits there indefinitely - something wrong with the monitor_directory callback
[12:28] <RAOF> pitti: Bah. Can't reproduce the adt failure, even with -P
[12:28] <pitti> RAOF: so, you have no idea where the unexpected 4.09 comes from?
[12:31] <RAOF> No.
[12:31] <RAOF> I wonder if that's i386 only?
[12:32] <RAOF> ie: Is this actually a testcase bug to do with float precision?
[12:32] <pitti> 4.08 and 4.09 are very far apart even in float terms -- looks more like a version number?
[12:33] <pitti> RAOF: no, fails on both arches
[12:35] <doko> pitti, are all the autopkg tests really running, e.g. for eglibc?
[12:35] <pitti> doko: what do you mean with "really"?
[12:35] <pitti> doko: for eglibc we ran maybe 40 or 50 tests
[12:35] <RAOF> pitti: The relevant code is “cd_icc_set_version (icc, 4.09);”… “g_assert_cmpfloat (cd_icc_get_version (icc), ==, 4.09);”
[12:35] <pitti> doko: but they fell off excuses.html (known bug, jibel is on it)
[12:36] <pitti> i. e. only a display problem mostly
[12:36] <pitti> RAOF: o_O
[12:36] <doko> ok
[12:36] <RAOF> pitti: (For reference, before the cd_icc_set_version call the version in 3.40, so it's not simply failing to set the version or failing to write the test file)
[12:36] <pitti> doko: so yeah, when eglibc 2.18 landed, pretty much all the tests ran, that was a nice queue on Monday morning
[12:37] <pitti> RAOF: does qemu emulate Pentium FPUs? :-)
[12:37] <RAOF> :P
[12:46] <mdeslaur> doko: mind if I merge gnupg?
[12:46] <doko> mdeslaur, not at all
[12:46] <mdeslaur> doko: thanks
[12:47] <mdeslaur> Is there anyone here running trusty on a cpu with rdrand that could test an openssl package for me?
[12:47] <mdeslaur> I'm not cool enough to have one of those yet
[12:49] <jamespage> mdeslaur: I appear to have that feature
[12:50] <stgraber> mdeslaur: I do too
[12:51] <mdeslaur> jamespage, stgraber: could one of you please try this debdiff just as a sanity check to make sure openssl still works on rdrand hardware before I upload it? http://paste.ubuntu.com/6605510/
[12:52] <mdeslaur> I believe the output of "openssl engine" should show rdrand without it, and should not with the patch
[12:52] <jamespage> mdeslaur: trying now
[12:52] <mdeslaur> jamespage: awesome, thanks
[12:53] <jamespage> mdeslaur: I get rejects applying the patch
[12:53] <jamespage> mdeslaur: ignore me - copy paste whitespace issue
[12:54] <mdeslaur> jamespage: use the "download as text" link
[12:55] <stgraber> mdeslaur: so I take it openssl doesn't know to mix sources of entropy then?
[12:55] <mdeslaur> stgraber: unfortunately not
[12:55] <mdeslaur> if you have rdrand, it's all that will be used
[12:55] <stgraber> though I guess if it fallbacks to one of the random char device provided by the kernel, then it'll get rrand indirectly from there but mixed with some other sources
[12:56] <stgraber> I have rngd running here mixing entropy from rrand, tpm and kernel generated random, that gives me a ton of entropy which is very very convenient when you're running test suites that generate a dozen of 4096bit rsa keys ;)
[12:57] <mdeslaur> heh, yes, that would be sufficient :)
[13:07] <pitti> so if rdrand is already put into /dev/random, it seems that openssl reading it directly might actually be counter-productive?
[13:09] <stgraber> pitti: I "think" the kernel now mixes it into /dev/random but that's all fairly new and that's why on my laptop I'm using a userspace tool to seed rrand and my TPM prng into the /dev/random pool
[13:09] <pitti> $ cat /proc/sys/kernel/random/entropy_avail
[13:09] <pitti> 151
[13:10] <stgraber> I vagueely remember some discussions on whether it was the kernel's job to integrate those other sources or if it was a userspace thing and that distros (as Fedora is currently doing) should provide rngd
[13:10] <pitti> I have rdrand, but that doesn't seem to be particularly much
[13:10] <stgraber> stgraber@castiana:~$ cat /proc/sys/kernel/random/entropy_avail
[13:10] <stgraber> 3096
[13:10] <stgraber> that's with rngd running
[13:10] <pitti> hm, how would that not be a kernel thing?
[13:10] <mdeslaur> I haven't looked at the code in a while, but I believe openssl only seeds it's prng with stuff from /dev/random
[13:11] <stgraber> yeah, I don't know, seems a bit counterintuitive having the kernel provide userspace with a way to access that stuff just for userspace to then seed /dev/random, but well...
[13:16] <jdstrand> @pilot in
[13:18] <jamespage> mdeslaur: I see rdrand both with and without the patch
[13:18] <mdeslaur> jamespage: ok, that may be fine. Does openssl appear to work?
[13:40] <mdeslaur> jamespage: ?
[13:40] <jamespage> mdeslaur: sorry - got presented with a baby part way through testing - multiarch mismatch is causing me niggles for install
[13:41] <mdeslaur> oh, hehe, np
[13:57] <xnox> pitti:  postgresql-server-dev-9.3 wants to get demoted to universe, is that correct?
[13:58] <pitti> xnox: hm, not really; -server-dev-all ought to depend on it
[13:59] <pitti> xnox: oh wait, yes; seems we don't have any packaged extension in main, so that's fine
[13:59] <xnox> ah, ack.
[13:59] <pitti> postgresql-server-dev-9.1 | 9.1.11-1              | trusty           | amd64, arm64, armhf, i386, powerpc, ppc64el
[13:59] <pitti> I wonder what holds that in main
[14:05] <xnox> xnox@sochi:~$ reverse-depends -c main postgresql-server-dev-9.1
[14:05] <xnox> No reverse dependencies found
[14:05] <xnox> xnox@sochi:~$ reverse-depends -b -c main postgresql-server-dev-9.1
[14:05] <xnox> Reverse-Build-Depends
[14:05] <xnox> [14:05] <pitti> xnox: ah, bacula builds against server-dev-9.1 (how strange..)
[14:05] <xnox> * bacula
[14:05] <xnox> xnox@sochi:~$
[14:05] <xnox> =)
[14:05] <pitti> so, that needs transitioning, too
[14:06]  * xnox ponders if i should change my machine naming skim from "obscure large cities in russia" to "winter olympics hosting locations"
[14:07] <dholbach> can we try to get http://reqorts.qa.ubuntu.com/reports/sponsoring/ down to something closer to 0 before the break? :)
[14:19] <jamespage> mdeslaur: OK - no baby now so re-trying :-)
[14:20] <jamespage> mdeslaur: a brief sniff looks OK
[14:32] <mdeslaur> jamespage: great, thanks!
[14:50] <jamespage> sergiusens, creating golang packages was worringly easy
[14:59] <sergiusens> jamespage, yeah, no complications with it at all
[15:13] <dobey> is there a reasonably good way to to say in a source package that a resulting binary package should own a file, and what the hash for that file is, without the file actually being in the binary package, but installed later (ie installed how flashplugin-installer installs flash)?
[15:14] <xnox> dobey: no, that would be wrong. but e.g. relevant pre/post-rm maintainer scripts should remove those files.
[15:14] <dobey> :(
[15:15] <xnox> dobey: it's similar to "non-conffile configuration files", just like one manually generates them (in e.g. pre/post-inst) one is responsible to clean them up (in pre/post-rm). Typically it's postinst & postrm.
[16:56]  * Laney does some festive sponsoring
[16:56] <Laney> ho ho hupload
[16:58] <mdeslaur> lol
[17:34] <jdstrand> @pilot out
[17:36] <dobey> weird. i just got an e-mail about trusty-adt-u1db being fixed now (i never got any e-mails about it breaking, and there haven't been any changes since the last version that was uploaded to saucy, which was copied to trusty)
[17:40] <stgraber> dobey: some of those tests are re-triggered when a rdepend changes
[17:40] <stgraber> and we had e-mail problems in the QA lab for a couple of weeks I believe
[17:40] <stgraber> so that can account for why you didn't get the failure notification and why the tests were run when you didn't upload something
[17:42] <dobey> stgraber: right. the weird thing is that i have NEVER got any failure notifications, ever. even when i know they were failing
[17:43] <stgraber> odd, though I know e-mail notifications were broken for quite a while and for various reasons (missing bits from IS, network re-org, ...) so in practice I only ever got a couple of those since the beginning of the cycle (so maybe just a 10th of what I should have got ;))
[17:46] <dobey> ah
[19:26] <tedg> jodh, Looking at upstart-dconf-bridge and it seems like it only emits events on values changing, is that correct?
[19:27] <tedg> jodh, Could it emit an event when the job is added to get the initial value?
[19:27] <tedg> Hmm, but that might not work.  If a job runs, does that reset all the conditions?
[19:30] <tedg> Oops, seems I broke him.
[19:30] <Logan_> Hello all.
[19:33] <xnox> tedg: i think the "typical" mode is that current values are emitted on the bridge start, for those events that jobs are sensitive to.
[19:33] <xnox> tedg: so if you have a job which is "start on dconf...." stopping and starting the dconf-bridge should emit the dconf event and thus start your job.
[19:33] <xnox> tedg: if that's not the case, it's a bug =) please file one.
[19:34] <xnox> tedg: as far as i know dconf bridge is not used yet ;-)
[19:34] <tedg> xnox, What happens after the job runs.  Can it run again?
[19:34] <tedg> i.e. would the condition stay satisfied
[19:34] <xnox> tedg: is it a task or a daemon? events are fired, and are gone.....
[19:34] <xnox> tedg: there is no state information.
[19:35] <tedg> task
[19:35] <xnox> tedg: well, it will run again, if the event is ever emitted, which would be the case when dconf value changes, or dconf bridge starts a fresh.
[19:35] <tedg> Seems state is useful for somethings like this.  Also xsession.
[19:37] <xnox> tedg: i know, but we don't have states. E.g. "start on started A and started B", "stop on stopped A or stopped B" does not do what one wants: after a & b started, the job is started, b stops, and the job stops. b starts again, the job is stuck in "waiting" for "started A" event which will never arrive, since A is already running.
[19:37] <xnox> tedg: so you cannot have a task which "run while dbconf", as there is no information provided for such thing.
[19:37] <xnox> tedg: "Also xsession" what do you mean?
[19:38] <tedg> xnox, So like "start on dbus-activation org.freedesktop.notification and xsession=foo" so then you could have multiple jobs do the dbus activation for a particular thing depending on the xsession.
[19:38] <tedg> xnox, But since it's not a state, that'd only work the first time.
[19:39] <tedg> Sorry "xession SESSION=foo"
[19:39] <xnox> dconf keys, I thought, were for things like "onboard" if a11y key is on, start onboard on desktop login, and stop it if dconf key disabled or desktop shutsdown.
[19:40] <xnox> tedg: don't do "and xsession=foo", do a prestart script checking the value of XDG_CURRENT_DESKTOP.
[19:40] <xnox> tedg: cause that environment variable does convey state.
[19:40] <xnox> (across all jobs, through the lifecycle of the session)
[19:40] <tedg> xnox, So, it can be used for that as well.  I wanted to have a task run only if the user allowed it (i.e. could disable the task running with a dconf key)
[19:41] <tedg> So I'll check the key in the pre-start, that's fine.  I was just expecting to use the dconf-bridge.
[19:41] <xnox> tedg: sure "start on dconf key", "pre-start check XDG_CURRENT_DESKTOP". or reverse, start on xsession, and check for dconf key in the pre-start.
[19:42] <xnox> tedg: bridges generate events only, and they are short-lived (fire once).
[19:43] <xnox> tedg: e.g. when one creates a new job, during a session, it will not see "xsession event" and thus doesn't auto-start straight away, one needs to poke it manually "$ start foo" or re-emit the event it's sensitive to.
[19:44] <tedg> That works.  Just not what I was expecting.
[19:45] <tedg> Thanks for the explanation xnox!
[19:45] <xnox> tedg: also "start foo" by-passes "start on" conditions so you can't use it as a check, and make sure the job is not-started, whilst user disabled it via dconf. =/
[19:45] <xnox> no worries, i do wish upstart could provide states.
[19:45] <xnox> it was proposed as  a feature, but hasn't been at all started to be implemented. It is desired to have "while ...." instead of start-on/stop-on.
[20:26] <infinity> xnox: http://sourceware.org/bugzilla/show_bug.cgi?id=15544
[20:42] <xnox> infinity: sys/wait.h is confusing, on freebsd implementation it does not expose (include) definitions from signal.h and thus is at times useless by itself.
[20:44] <infinity> Ugh, the 1SS network explosion must have hung up all those jenkins jobs...
[20:44] <infinity> jibel: Can you sort out why it seems that all the autopkgtest jobs started by me glibc upload are still "running"?
[20:44] <infinity> jibel: Cause that doesn't seem reasonable.
[20:45] <infinity> jibel: (Also, can you restart the failed eglibc test itself, the failure is transient).
[20:46] <infinity> xnox: Or, if you have the VPN magic required to retry it?
[20:46]  * infinity has never bothered to get that going...
[20:46] <xnox> infinity: i have vpn magic to view the private jenkins, i have no magic loginz to push the buttons
[20:47] <xnox> also my fingers are in honey and it's hard to type
[20:47] <infinity> Heh.
[20:48] <cjwatson> I should have it - give me a moment
[20:48] <cjwatson> iz running
[20:49] <infinity> Tempted to just skiptest that eglibc upload, given that everything passed on the buildds, and the changes were very isolated.
[20:49] <xnox> now my fingers are clean, but some of the keyboard keys are in honey.
[20:49] <infinity> And I have on idea how all those autopkgtests could legitimately have been "running" for the last 12h, even with the 1SS network sadness.
[20:49] <cjwatson> now you have oasfyuiosdoasufyoa problems
[20:49] <infinity> s/on/no/
[20:49] <cjwatson> infinity: they probably weren't, the britney integration often lies about running status
[20:50] <infinity> cjwatson: Will that magically clear up?
[20:50] <cjwatson> jenkins had the amd64 one down as failing, i386 passed
[20:50] <cjwatson> infinity: good question, I'm glad you asked that question
[20:50] <cjwatson> (quite possibly not, it's wonky)
[20:50]  * xnox internal compiler error at "oasfyuiosdoasufyoa"
[20:51] <infinity> cjwatson: Oh, eglibc/amd64 legitimately did fail, I was referring to all the rdep tests being "running" still.
[20:51] <infinity> cjwatson: Like, a couple dozen of them.
[20:51] <cjwatson> if jibel isn't around to investigate it properly then maybe just force-skiptest it once they go green in jenkins
[20:51] <infinity> Maybe I just broke jibel's jenkins. :P
[21:35] <jibel> infinity, cjwatson networking issue this morning broke autopkgtest in jenkins. And earlier this evening jenkins was marked for shutdown. I'll re-run the tests with an invalid status once the queue is empty.
[21:41] <infinity> jibel: Kay, figured it might be something like that.  The network oops causes a lot of havoc for me too.
[21:45] <xnox> infinity: a 30minute switch reboot =)
[21:49] <slangasek> xnox: why was the switch not running upstart!?
[21:50] <xnox> slangasek: it is a cisco router, so i think it is running upstart. It's just it was a firmware upgrade reboot as well =)
[21:50] <xnox> slangasek: dunno, el mo dispatched someone onsite and by the time the person arrived, it finished rebooting.
[21:53] <slangasek> do ciscos run upstart? :)
[21:53] <sarnold> they run quagga, don't they? :)
[21:54] <xnox> slangasek: yeah, or so jodh was told at Plumbers / LinuxCon.
[21:54] <slangasek> dunno, it's been years since I touched a cisco router
[21:58] <infinity> IOS runs upstart?  That's a new one on me.
[21:58] <infinity> I'd need verfication of this claim before I believe it.
[21:59] <Logan_> Is someone here able to add things to the Ubuntu transition tracker?
[22:01] <Logan_> xnox: I think you did for me last time.
[22:02] <Logan_> Please copy this one to Ubuntu: http://release.debian.org/transitions/html/suitesparse.html
[22:02] <Logan_> I'll pay you back in doges or something.
[22:02] <sarnold> wow. much coin!
[22:03] <Logan_> I never said dogecoin. :P
[22:03] <xnox> Logan_: do you really need a tracker :P =)
[22:03] <xnox> ok, will add.
[22:04] <Logan_> I like trackers. They're pretty.
[22:04] <Logan_> And I still want cjwatson to add me to the team. :P
[22:05] <xnox> Logan_: meh,... added.
[22:05] <Logan_> <3
[22:06] <xnox> infinity: upstart 0.5.0 reference: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/release/note/Open_Source_used_in_IOS_Rls_1512SG_.pdf
[22:06] <sarnold> nice!
[22:06] <xnox> infinity: probably better to find more recent references / firmwares.
[22:07] <infinity> xnox: Huh.  Crazy.  Though, yeah, that's pretty old.
[22:09] <Logan_> Why is there some random guy at the top of that?
[22:09] <slangasek> I've never been sure about the package suitesparse.  Is it a sparse suite?  something that parses suites?  a suit with a sparse error?
[22:10] <sarnold> suite sp arse ...
[22:10] <Logan_> " SuiteSparse is a single archive that contains all packages that I have authored or co-authored that are available at this site. This gives you a simple way of getting and installing all of my software packages."
[22:11] <Logan_> So, basically, random shit.
[22:11] <slangasek> sarnold: ITYM 'suit esp arse'
[22:11] <sarnold> haha ;)
[22:11] <Logan_> xnox: Liar. https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker
[22:25] <xnox> Logan_: stop looking at obsolete tracker ;-)
[22:25] <Logan_> Where's the new branch?
[22:25] <xnox> Logan_: lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/
[22:26] <xnox> Logan_: and you can do merge proposals to it ;-)
[22:26] <Logan_> Oh, good, it's a proper branch now.
[22:27] <xnox> Logan_: also that old one doesn't have openmpi, yet the tracker is up. should have been a clue ;-)
[22:27] <Logan_> Why isn't http://people.canonical.com/~ubuntu-archive/transitions/html/dh-python2.html working correctly? I've definitely fixed some packages, but they're still marked as unknown...
[22:27] <Logan_> Like, including b-d'ing on dh-python.
[22:27] <xnox> Logan_: no idea, can you give me an example?
[22:28] <xnox> Logan_: oh, untick "unkown" it's catching too-wide things, which later do not match neither bad nor good.
[22:28] <xnox> Logan_: thus unknown it pointless on that tracker.
[22:28] <Logan_> Yeah, but "good" is not getting nothing.
[22:28] <Logan_> *anything
[22:29] <xnox> Logan_: hm..... I see.
[22:29] <xnox> yeah, it's borked.
[22:29] <Logan_> https://launchpad.net/ubuntu/+source/dockmanager/0.1.0-0ubuntu2 http://launchpadlibrarian.net/157445049/dockmanager_0.1.0-0ubuntu1_0.1.0-0ubuntu2.diff.gz
[22:29] <xnox> Logan_: right, updated tracker. let's wait for next regeneration.
[22:30] <Logan_> Marked as "unknown," even though I converted to dh_python2 and build-depended on dh-python.
[22:30] <Logan_> Okay.
[22:31] <Logan_> xnox: But you got rid of the build-depends completely... they all **should** build-depend on dh-python.
[22:31] <xnox> Logan_: correct.
[22:31] <xnox> Logan_: one can use dh_python2 with or without the dependency.
[22:31] <xnox> Logan_: and e.g. python-central has been removed in Debian, but we still have it in Ubuntu =(
[22:32] <Logan_> I guess. But that rule should've stayed, I think. But working.
[22:32] <Logan_> I think it's eventually going to be a policy that all packages that use dh_python2 should build-depend on dh-python.
[22:32] <xnox> Logan_: well, it clearly didn't work. And the tracker used to be without it, when it was first setup.
[22:32] <Logan_> Hmm, alright.
[22:35] <c_korn> one question: trying to install fontforge:i386 on amd64 there is the error fontforge:i386 : Depends: fontforge-common:i386 (= 20120731.b-3ubuntu1) but it is not installable . well, but there is no i386 version of the package. fontforge-common is Architecture: all
[22:43] <xnox> c_korn: an odd corner case where potentially fontforge-common needs a multiarch declaration.
[22:43] <xnox> c_korn: can you first install fontforge-common by itself?
[22:44] <xnox> c_korn: same way I had to mark ubuntu fonts Multi-Arch: foreign.
[22:46] <c_korn> is this multiarch declaration a bug? I do not even find a mention of multiarch in the package
[22:46] <xnox> c_korn: yeap. confirmed locally.
[22:47] <xnox> c_korn: when dpkg resolves transient dependencies, there are cases where it does not know how to deal with arch:all package in the dependency chain.
[22:49] <xnox> c_korn: without a multi-arch hint.
[22:50] <c_korn> so, does this need to be fixed in dpkg or in fontforge?
[22:52] <xnox> c_korn: fontforge. I'm building a test fix locally already.
[22:53] <xnox> c_korn: why do you need i386 version, if amd64 exists?
[22:55] <c_korn> I try to install the i386 dependencies of wine: sudo apt-get build-dep -a i386 wine1.4
[22:55] <c_korn> this is where I get the error, xnox
[22:55] <xnox> c_korn: _don't do it on the host_ !
[22:55] <xnox> c_korn: only do it in chroot!
[22:55] <c_korn> xnox: yeah, I have a schroot here.
[22:56] <xnox> c_korn: i386 chroot righ?
[22:56] <xnox> c_korn: mk-sbuild --arch i386 trusty
[22:56] <xnox> c_korn: schroot -u root -c trusty-i386
[22:56] <xnox> or whichever release you need?
[22:56] <c_korn> I have a amd64 schroot here (saucy)
[22:57] <xnox> c_korn: i don't think you can compile wine1.4 on amd64.
[22:57] <xnox> or install it's deps.
[22:57] <c_korn> hum, ok.
[22:57] <xnox> c_korn: well, cross-compile / multilib compile it.
[22:58] <xnox> c_korn: if you want full wine build, use i386 chroot (your host can be amd64) and build arch:all & arch:i386 packages. And then using amd64 chroot build the amd64 packages.
[22:59] <slangasek> in that case, you really want fontforge itself marked Multi-Arch: foreign, so the host version of fontforge can be used
[22:59] <xnox> c_korn: mk-sbuild saucy; mk-sbuild --arch i386 saucy; sbuild -d saucy --arch i386 wine*.dsc; sbuild -d saucy --arch amd64 wine*.dsc
[22:59] <xnox> slangasek: possibly true, will help wine case, but I don't believe it will resolve all of the wine deps.
[23:00] <slangasek> xnox: right, a cross-arch chroot is better
[23:02] <xnox> slangasek: let's cross-compile fonts! how useful, given they all are arch:all ;-)
[23:02] <c_korn> ok, I will build it in a i386 schroot then. thanks, xnox and slangasek !
[23:03] <xnox> slangasek: well, get's us one step closer to cross-compile libreoffice package, i guess.
[23:12] <Noskcaj> Can someone help me with the gnome-packagekit merge?
[23:12] <Noskcaj> Do we really need to keep a bumped glib2.0 version and remove gtk-doc-utils and libapt-pkg-dev from the build-depends?
[23:21] <xnox> Noskcaj: yes.
[23:21] <Noskcaj> ok
[23:22] <xnox> Noskcaj: have you talked to last uploader or the last sponsor about that package?
[23:26] <Noskcaj> xnox, I have been told jbicha left the project and the uploader hasn't had any ubuntu work in the last two months
[23:26] <xnox> Noskcaj: ok, fair enough. didn't know that.
[23:29] <Noskcaj> xnox, Mind if i merge argyll? I'd nearly finished the work a few days ago then forgot
[23:30] <xnox> Noskcaj: yeah, go ahed. it's all just transition fixes.
[23:38] <Noskcaj> infinity, Any chance of you merging xscreensaver soon? bug 1261863
[23:38] <Noskcaj> If you don't want to, i could try
[23:40] <infinity> Noskcaj: Oh sure, yeah.  I hadn't noticed that the Debian maintainer woke up and uploaded new versions finally.
[23:41] <Noskcaj> :)


[00:47] <Noskcaj> pleia2, is that enough or do you want bits copied from the wiki?
[00:49]  * pleia2 has a look and makes some notes
[05:14] <pleia2> oh, I was made admin of the G+ community
[05:14] <pleia2> https://plus.google.com/u/1/communities/108369189560969273265
[05:14] <pleia2> so we can probably officialize this one too (this is a community, vs a page which we already had)
[10:38] <knome> pleia2, good good. let me tell if/what logo sizes/artwork you need
[10:38] <knome> and yes, we should sort out the deviantart group artwork too
[10:55] <ochosi> ah right...
[10:55] <ochosi> forgot a bit about that one
[10:56] <knome> me too
[11:10] <bluesabre> micahg, it might be easier to get an FFe for catfish, since the one that is currently in the raring repos is broken
[11:10] <bluesabre> (doesn't start)
[11:16] <adnan> long time no see
[11:27] <ochosi> hey adnan
[11:27] <ochosi> true true
[11:32] <adnan> :)
[11:45] <ochosi> madderni1k: ping
[11:45] <madderni1k> ochosi: png
[11:45] <madderni1k> +o*
[11:46] <ochosi> is it possible to test plymouth's fsck check animation in the testbinary somehow?
[11:46] <madderni1k> yes
[11:46] <madderni1k> I dont remember how, lemme check my scripts
[11:46] <ochosi> have you tested that with the circular spinner?
[11:47] <madderni1k> I've tested all features
[11:48] <ochosi> ah good
[11:48] <madderni1k> ochosi: okay, so pass the command
[11:48] <madderni1k> --command, option
[11:49] <madderni1k> basically it looks for fsck being given to the status handler
[11:50] <ochosi> ok, i'll just quickly wait for bluesabre to return
[11:50] <madderni1k> so i supposed i lied, its --status=fsck
[11:50] <ochosi> he does a real-install check now
[11:50] <madderni1k> (problem is I dont have access to the laptops tests scripts :()
[11:59] <ochosi> madderni1k: so yeah, the spinner and the progressbar overlap
[12:01] <bluesabre> is it possible to hide the spinner if fsck needs to run?
[12:01] <ochosi> i think it's easier to just change the coordinates of the progressbar tbh
[12:01] <knome> yes
[12:01] <ochosi> madderni1k: how do i run plymouth again in testmode? (forgot the commandline you gave me once)
[12:04] <madderni1k> sudo plymouthd --debug --debug-file=/tmp/plymouth-debug-out ; sudo plymouth --show-splash ; sleep 5 ;  sudo plymouth --quit
[12:04] <madderni1k> define overlap?
[12:05] <madderni1k> iirc its 25px between them
[12:06] <ochosi> the new spinner is circular and larger and further south
[12:07] <ochosi> if you remember the latest changes
[12:07] <madderni1k> oh ye, we moved it down
[12:09] <ochosi> strange, the --status=fsck doesn't work
[12:09] <ochosi> i added it after --show-splash
[12:13] <madderni1k> think you need to do --update aswell
[12:13] <madderni1k> i dont really remember the exact command
[12:13] <ochosi> no, that also didn't help
[12:16] <madderni1k> ochosi: found it
[12:16] <madderni1k> sudo plymouthd --debug --debug-file=/tmp/plymouth-debug-out ; sudo plymouth --show-splash ; sleep 1 ; sudo plymouth --update=fsck: ; sleep 2 ; sudo plymouth --quit
[12:16] <madderni1k> ofc the animation will be fubar, since one needs to send update integers along with it if you want the real thing
[12:16] <madderni1k> but for positioning thats fine
[12:17] <ochosi> weird, doesn't show anything here...
[12:18] <madderni1k> try increasing the sleeps
[12:18] <madderni1k> the second sleep to many 5 seconds
[12:18] <madderni1k> it shows "Routine disk check" and the bar
[12:18] <madderni1k> about 10px to high up
[12:19] <ochosi> the progressbar goes straight through the circle
[12:19] <ochosi> http://www.zimagez.com/zimage/screenshot-03092013-011928pm.php
[12:20] <madderni1k> fsck_progress_meter_sprite.SetPosition((screen_width / 2) - (progress_meter_image.GetWidth() / 2), (screen_height / 2) + (logotype_image.GetHeight() / 2) + 25);
[12:20] <madderni1k> fsck_progress_fade_sprite.SetPosition((screen_width / 2) - (progress_meter_image.GetWidth() / 2), (screen_height / 2) + (logotype_image.GetHeight() / 2) + 25);
[12:21] <ochosi> i know
[12:21] <ochosi> i'm already tinkering with it
[12:21] <ochosi> but i need to move everything along
[12:21] <ochosi> incl. the password box
[12:24] <ochosi> http://www.zimagez.com/zimage/screenshot-03092013-012420pm.php
[12:24] <ochosi> madderni1k: any way i can show the password-box too?
[12:26] <ochosi> awesome... http://www.zimagez.com/zimage/screenshot-03092013-012614pm.php
[12:26] <madderni1k> sudo plymouthd --debug --debug-file=/tmp/plymouth-debug-out ; sudo plymouth --show-splash ; sleep 1 ; sudo plymouth --update=fsck: ; sleep 1 ; sudo plymouth ask-for-password --prompt "spify password: " ; sleep 5 ; sudo plymouth --quit
[12:27] <madderni1k> tbh, i didnt even think about this
[12:27] <ochosi> is there an easy way to hide the spinner for fsck?
[12:27] <madderni1k> i knew all the individual features worked
[12:27] <madderni1k> ochosi: yes
[12:28] <madderni1k> SetOpacity(100)
[12:28] <ochosi> if ((fsck_running == 1) && (fsck_done_fading == 0)) { ?
[12:28] <ochosi> you mean SetOpacity(0)?
[12:28] <madderni1k> oh ye
[12:35] <ochosi> meh, in which functions do i have to hide the spinner?
[12:35] <madderni1k> ochosi: do you want to hide it when the password appears?
[12:36] <ochosi> yes, and when fsck is running too
[12:36] <ochosi> those two might coincide i guess
[12:36] <ochosi> so just to be sure, always hide it
[12:37] <madderni1k> in the showPasswordHandler and statusHandler when status_array[0] is equal to "fsck"
[12:37] <madderni1k> reset possible in displayNormalhandler
[12:37] <ochosi> do you have time to try this now?
[12:38] <ochosi> cause i have a few more things i have to get fixed on the weekend
[12:38] <ochosi> lightdm-gtk-greeter and a few more icons
[12:38] <madderni1k> do you have the changes you've made?
[12:38] <ochosi> they're not too great tbh, i mostly changed the coordinates of the fsck-bar
[12:39] <madderni1k> ok
[12:39] <ochosi> which won't be necessary in the end (hopefully)
[12:39] <ochosi> and i added SetOpacity for the spinner in a few places
[12:40] <madderni1k> i suppose i can just make the changes
[12:40] <madderni1k> and upl
[12:40] <ochosi> yeah
[12:40] <ochosi> you can also pastebin them so we can test them in advance
[12:40] <madderni1k> ok
[12:41] <ochosi> thanks!
[12:49] <madderni1k> ochosi: should i move password thing down
[12:50] <ochosi> is it overlaying anything?
[12:51] <madderni1k> if password is there
[12:51] <ochosi> yeah, we don't want anything to overlap :)
[12:52] <madderni1k> its just that
[12:52] <madderni1k> im not sure that can happen
[12:52] <ochosi> that means we should move it iguess
[12:52] <ochosi> as long as we're not sure
[12:57] <madderni1k> ochosi: http://paste.ubuntu.com/5598756/
[12:57] <madderni1k> that seems to do it on all accounts
[12:57] <madderni1k> it even restores states if it comes to that
[12:57] <madderni1k> So the spinner can come back, if you are done with fsck and password
[12:59] <ochosi> ok cool
[12:59] <ochosi> i'll test that in a second
[13:03] <ochosi> madderni1k: that gives me a black screen
[13:04] <madderni1k> ochosi: odd, it does not here
[13:04] <madderni1k> no errors encountered in the log either
[13:05] <ochosi> hmm
[13:06] <madderni1k> ochosi: perhaps the pastebin corrupted something
[13:06] <madderni1k> want me to upl to my server for fetching?
[13:06] <ochosi> ok, why not
[13:09] <ochosi> madderni1k: thanks, looking good now!
[13:09] <ochosi> bluesabre: you still around?
[13:10] <madderni1k> ochosi: THhere are 2 possible problems
[13:10] <madderni1k> one of them is: the msgs one can get
[13:10] <madderni1k> The "last 5 msgs" feature
[13:10] <madderni1k> Might be overlapping something
[13:11] <ochosi> can we test that?
[13:11] <madderni1k> ye im trying to figure out how :P
[13:11] <ochosi> ok :)
[13:11] <bluesabre> hm what huh?
[13:11] <bluesabre> :)
[13:11] <ochosi> mind to quickly test the plymouth script?
[13:12] <bluesabre> with my install?
[13:12] <ochosi> i'd mail it to you, you save it in /lib/plymouth/themes/xubuntu-logo and then run sudo shutdown -rF now
[13:12] <ochosi> yup
[13:12] <bluesabre> sure thing
[13:13] <ochosi> sent
[13:15] <madderni1k> ochosi: i think msgs are okay
[13:17] <madderni1k> it always uses the bottom
[13:17] <madderni1k> So its fine
[13:17] <madderni1k> :)
[13:18] <ochosi> ok
[13:18] <ochosi> good
[13:18] <ochosi> what is the second possible problem?
[13:19] <madderni1k> well, the spinner_sprite doesnt technically have a sprite at first
[13:19] <madderni1k> but its not a problem
[13:19] <madderni1k> since it will have it before fsck or passw can appear
[13:19] <madderni1k> Its just not very clean
[13:20] <madderni1k> im concidering adding it for "being clean" purposes
[13:20] <ochosi> i guess that's up to you, i haven't looked into plymouth enough to be able to judgew
[13:21] <madderni1k> okay, tell me how testing goes, i need to do my workout and eat now
[13:22] <ochosi> sure
[13:25] <pjotr> Hello, does anyone know if Synaptic will be a default part of Xubuntu 13.04?
[13:28] <ochosi> i'm pretty sure it won't
[13:30] <pjotr> ochosi: Too bad.... I think it's an essential tool and deserves a place in the iso. Is there no more room in the iso, in spite of the new maximum of 1 GB?
[13:36] <bluesabre> ochosi: that works
[15:15] <mr_pouit> knome: micahg: I set up translation support for the two desktop files you uploaded https://translations.launchpad.net/xubuntu-default-settings/trunk/+pots/xds-desktop-files
[15:16] <mr_pouit> (please do it when you add new "visible" strings next time, as my life seems meaningless each time I have to fight against translations.lp.net ;-)
[15:31] <knome> mr_pouit, thanks, did the finnish translations
[17:52] <ochosi> bluesabre, madderni1k: i'll push the updated plymouth script then
[17:57] <madderni1k> roger that
[17:58] <ochosi> ok, pushed
[17:59] <pleia2> ochosi: did you want a spot in the magazine for an article? what topic? https://wiki.ubuntu.com/Xubuntu/Marketing/Magazine2013 has current ideas
[18:00] <ochosi> hey pleia2
[18:00] <pleia2> good morning :)
[18:00] <ochosi> haven't really given that any thought tbh
[18:00] <ochosi> it's 7pm here ;)
[18:00] <pleia2> 10am!
[18:00] <ochosi> what magazine is that?
[18:01] <pleia2> a special flavors edition published by linuxidentity.com
[18:01] <pleia2> in English (not French)
[18:02] <ochosi> french is only my third language, so that's fine ;)
[18:04] <ochosi> pleia2: at the moment i'm rather busy and the topics you still have there seem quite easy to cover, so if you can find someone else, that'd be great
[18:04] <ochosi> beta1 is approaching and there's still artwork to fix and our greeter needs more updates
[18:04] <pleia2> ochosi: those are just ideas people proposed, we're trying to find other ideas
[18:05] <ochosi> ah
[18:05] <ochosi> i see
[18:05] <ochosi> hm, it's dinner time for me now
[18:05] <ochosi> i'll think a bit about it and add topics if i get ideas, k?
[18:06] <pleia2> thanks :)
[18:07] <ochosi> great, bbl
[20:01] <mr_pouit> knome: first ffe, Bug #1153038
[20:02] <mr_pouit> freeze on thursday are really a pain since I've only time to work on ubuntu during week-ends these days...
[21:25] <knome> mr_pouit, great... i assume i don't need to file the exception ? ;)


[17:17] <shtylman> what is the proceedure for backporting fixes to the lucid installer?
[17:17] <shtylman> bug 584074
[17:17] <ubot2> Launchpad bug 584074 in ubiquity (Ubuntu) "The dialog to to select partition mount point should automatically select the current partition type (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/584074
[17:50] <shtylman> ev: do you have a working branch for this massive overhaul? or will it be happening in trunk?