[00:00] <hallyn> jbernard: no, it's not.  because first it wants to create some subdirectories.  and that isn't allowed
[00:06] <psusi> hrm... what happened to external media being auto mounted with -o uid=,gid=?  I thought that had been working for some time to override the permissions on broken filesystems... where is that implemented these days?  udisks right?
[00:08] <persia> psusi, Yes.
[00:08] <hallyn> (sorry, didn't mean to sound harsh - libcg itself has just somehow never struck the right chord with me.  it *should*, except i prefer scripts to magic fragile configfiles)
[00:09] <psusi> hrm... I'll have to take a look at the code then.. I have been sorting through some old dvd+rw discs and I couldn't access this one because it wasn't mounted with the uid,gid options...
[00:16] <hallyn> jbernard: I'm waiting for confirmation from two bug reporters, but I expect to be doing a merge request for https://code.launchpad.net/~serge-hallyn/ubuntu/natty/libcgroup/upstart/
[00:17] <hallyn> jbernard: (or I can send it as a debian bug report?  dunno what you prefer)
[00:20] <\sh> moins
[00:23] <broder> hallyn: is this different from /dev/cgroup/cpu?
[00:24] <jbernard> hallyn: a bug would work well, but i don't have a strong perference
[01:10] <poolie> scottk, i will make the LEP and bug more clear re the celebrity thing
[01:10] <poolie> btw, dkim stuff is on the back burner but not totally cold
[01:10] <poolie> i hope to enable it for your domain soon
[01:10] <ScottK> OK.
[01:11] <ScottK> It seemed like a jargon term that would have been well understood by the LP people on the list and I didn't want to mis-guess what it meant.
[01:14] <poolie> sure
[01:14] <poolie> undoubtedly there will also be some ubuntu jargon that goes over my head too, or lp devs heads
[01:14] <poolie> biab
[01:15] <ScottK> Certainly, that's why it's important to check on such things and make sure we have a common understanding.
[01:48] <YokoZar> ScottK: I've been getting lots of spam from forged @ubuntu.com addresses...would you take it personally if Canonical wasn't running SPF on the ubuntu.com domain? ;)
[01:48] <ScottK> Not sure what you mean?
[01:49] <ScottK> YokoZar: There is no SPF record for ubuntu.com
[01:49] <YokoZar> Right
[01:50] <YokoZar> I vaguely remember a conversation at an airport with you about you having a big role in SPF
[01:50] <ScottK> I was involved in it's development.
[01:51] <ScottK> The trick is that to publish a useful SPF record, Canonical would have to give Ubuntu members a way to send through an authorized outbound relay.
[01:51] <YokoZar> And thus it seems silly that we don't use it ;)
[01:51] <ScottK> I doubt they're up for that.
[01:51] <maco> forging is how i send emails from my @ubuntu.com address
[01:51] <maco> kmail makes it easy!
[01:51] <YokoZar> Yeah, true
[01:51] <micahg> yep, me too :)
[01:51] <maco> (my dad was really really O_O when i said i could send an email from him from my computer instead of from his lotus
[01:51] <maco> )
[01:52] <broder> ScottK: wait, i thought there was a relay server i could send mail through for ubuntu.com...
[01:52] <ScottK> Is there?
[01:52] <broder> apparently not
[01:52] <broder> i thought i remembered configuring gmail with one, but i'm looking at it and i clearly didn't
[01:52] <maco> i use gmail as a relay
[01:52] <maco> nah all you're doing in the case you make gmail able to send from it is telling gmail to forge it
[01:52] <broder> right, right
[01:53] <maco> they at least check that you actually have access to the account (by sending a confirmation email) first
[01:53] <ScottK> We can use indium to send mail to LP, but that's all I know of.
[01:54] <broder> clearly we need an implementations of gmail's oauth sasl extension in postfix and major clients so we can authenticate against launchpad to an ubuntu.com MTA
[01:54] <persia> I'm not sure I'd like to see SPF for @ubuntu.com.  I don't mind as much if someone pretends to be me when there's no confirmation that they are indeed me.
[01:55] <persia> broder, Hrm.  I suppose that might work.
[01:55] <broder> persia: except for the part where client support is guaranteed to be awful for the next N years
[01:56] <ScottK> persia: SPF makes no assertion that mail is really from us, just that it came from a relay authorized by the domain owner.
[01:56] <ScottK> So your deniability is still secure.
[01:57] <persia> broder, All mail clients have been miserable and bad for the past 40 years.  I don't see why that would change.
[01:57] <broder> touche
[01:57] <persia> ScottK, I know that, and you know that, but being the sort of person who regularly needs to defend deniability, I prefer when there isn't even an implication.
[01:58] <ScottK> persia: If they ever corner you, you can also pull out DNS cache poisoning.
[01:58] <ScottK> (as an added reason why it wasn't you)
[01:59] <persia> Heh.  It won't come to that.  I just don't see the value in a relatively open SPF-certified relay.
[01:59] <ScottK> Also bad and miserable does have degrees.  If not, evolution wouldn't exist.
[01:59] <persia> Something like oauth could do it, but that's awkward to implement.
[02:00] <ScottK> I think it's not mostly interesting for the ones that might be OK, it's interesting for the ones that probably aren't.
[02:00]  * persia hugs bug #110840 and continues not to use evolution
[02:01] <maco> persia: is that a reference to how im able to grep my emails if i use evolution instea of waiting for it to load and search?
[02:01] <persia> maco, No, it's a reference about how I'm able to grep your mail in evolution without even pretending to be you.
[02:01] <maco> persia: if home dirs were 700 this wouldnt be a problem...
[02:03] <persia> ScottK, How do you mean (re: mostly interesting)?
[02:04] <ScottK> I rarely find "It passed SPF" very interesting except for a very restricted set of domains.
[02:04] <persia> Ah.  For those domains that are mostly-spam, it becomes an interesting way of identifying potential ham?
[02:04] <ScottK> OTOH, "It failed/didn't pass (those aren't quite the same thing) is broadly interesting.
[02:05] <persia> failed means it originated from a non-certified host, and didn't pass means that there are no certified hosts?
[02:05] <ScottK> Didn't pass includes Fail, Softfail, Neutral, and error results.
[02:06] <ScottK> So failed is a subset.
[02:06] <ScottK> Finding bad domains isn't very interesting.
[02:06] <persia> Ah.  That makes sense.  What's the difference between Fail and Softfail?
[02:07] <ScottK> Softfail is like "We think it's not authorized, but we're not ready to commit to the completness of our list yet"
[02:09] <ScottK> persia: The formal definition is http://www.openspf.org/RFC_4408#op-result-softfail
[02:09]  * persia was starting with http://www.openspf.org/FAQ/What_is_SPF :)
[02:09] <ScottK> Anyway, bad domains are boring because they send nothing but crap whether it passes or not.
[02:10] <ScottK> Good domains are interesting because threat/not threat tends to match very closely with SPF result.
[02:11] <persia> And most domains are neutral?
[02:11] <ScottK> The published statistics I've seen seem to say that ~half of email has an SPF record for it.
[02:12] <ScottK> Most large domains don't want to take the hard line of saying "If it's not from an authorized source, treat it badly" since they don't want complaints.
[02:12] <persia> That's interesting.  I read that as "most spammers have adopted SPF"
[02:13] <ScottK> A lot of people have on both sides of the fence.
[02:13] <ScottK> The nice thing about spammers adopting SPF is that it makes it possible to automatically construct reliable domain black lists.
[02:14] <ScottK> "Gee, all crap from that domain and it passes SPF, so they sent it - next time I'll just reject it after mail from"
[02:14] <persia> Indeed.  makes the construction of rule semantics that much richer.
[02:15] <ScottK> It you look at just SPF pass, domains tend to be either virtually all ham or all spam.  The middle ground is very small.
[02:15] <persia> Isn't that the point?
[02:16] <persia> I presume that domains without useful control over sending relays (e.g. @ubuntu.com) mostly choose not to participate currently.
[02:16] <ScottK> Yes.
[02:17] <ScottK> It also turns out to be hard for large entities to delpoy accurately just because they don't know their outbound architecture very well.
[02:48] <wgwinn> has ubuntu 10.10 removed kmalloc.h from the kernel source? i'm trying to install the hyper-v v2 drivers and it's failing on kmalloc , and i cant find the function defined anywhere
[02:57] <broder> wgwinn: looks like it's in <linux/slab.h>
[03:02] <wgwinn> i dont see it there, but i will reread it
[03:04] <Darxus> Where can I vote for Obnoxious Orangutan?  :)
[03:05] <ScottK> Can't vote on that.  This is not (mostly) a democracy.
[03:05] <persia> Darxus, We don't vote.  One of the privileges of the self-appointed benevolent dictator for life is the selection of the codenames for each release.
[03:08] <wgwinn> using linux-headers-2.6.35-22/include/linux/slab.h has references to kmalloc() but does not define it.
[03:09] <broder> wgwinn: well, there are lots of comments in the linux source tree to the effect of "#include <linux/slab.h> /* for kmalloc, kfree */", so i suspect it's included from there or something
[03:25] <Darxus> Yeah, I figured I couldn't actually vote, but I'd love to see that name happen.
[03:37] <Yanks> !ops
[03:37] <Yanks> you know ur motherboard has 250$ worth of gold in it?
[03:38] <Yanks> you know ur motherboard has 250$ worth of gold in it?
[03:38] <Yanks> !staff
[03:42] <hallyn> weird
[03:54] <psusi> hallyn, were those -part changes only for the symlinks in /dev/by-id, or did they also change the name in /dev/mapper?
[03:56] <achiang> any network-manager hackers around?
[03:57] <achiang> or for that matter, people who know how to debug dbus/python stuff?
[03:58] <persia> achiang, Try asking the question you would ask if someone said "yes"
[03:58] <Yanks> you know ur motherboard has 250$ worth of gold in it?
[03:59] <achiang> using maverick, playing around with the NetworkManager dbus api, and getting a rather basic error when trying to run some of the sample code --getting a dbus error: "ListConnections" with signature "" on interface "org.freedesktop.NetworkManagerSettings" doesn't exist
[03:59] <ohsix> mine has none, it has molybdenum :[
[04:00] <Yanks> you know ur motherboard has 250$ worth of gold in it?
[04:00] <Yanks> !ops
[04:00] <achiang> basically, i'm wondering if the NM in maverick presents that interface or not; it seems like it should, since we have NM 0.8+ and that is a 0.8 API
[04:00] <Yanks> !ops
[04:00] <Yanks> !ops
[04:00] <Yanks> !ops
[04:00] <Yanks> !ops
[04:39] <Darxus> QQ
[05:04] <broder> achiang: yeah, that should work. i'm pretty sure i've used it before. can you pastebin the command/code you're trying to call it with?
[05:05] <achiang> broder: i was just kinda playing around and fixed my own problem
[05:05] <achiang> broder: thanks though
[05:05] <broder> achiang: cool
[07:17] <didrocks> good morning
[08:22] <didrocks> ogra: I think the unity team will need your armel knowledge: bug #721118 :)
[08:57] <dholbach> good morning
[09:00] <didrocks> good morning Mr Holbach :)
[09:04] <dholbach> bdrung, pulled lp:ubuntu-sponsoring
[09:04] <dholbach> salut didrocks - comment ça va mon ami?
[09:05] <didrocks> dholbach: ça va très bien, merci! et toi?
[09:05] <dholbach> très bien aussi, merci beaucoup :)
[09:27] <tkamppeter> pitti, hi
[09:52] <jamespage> Morning
[09:53] <jamespage> any chance that a member of the MIR team could review bug 676904 for me
[10:32] <seb128> @pilot in
[10:36] <cjwatson> persia: can you update the developer-membership-board@ list membership when you have a chance?  I just realised I forgot to do this before resigning moderator access
[10:38] <ogra> didrocks, well, stop casting bigger types into smaller ones and it will build i'd say :)
[10:39] <didrocks> ogra: tell that to the dx team :p can you give them an help (not really confident with thoses)?
[10:39] <ogra> i havent looked at the code yet, only at te error, but its likely that the target type is simply smaller under arm
[10:41] <ogra> (int vs long or something like that)
[10:43] <ogra> janimo, didnt you fix that before ? (bug 721118) or was that something else
[10:44] <janimo> ogra, I fixed one instance, but there may be new ones. I'll check
[10:44] <Daviey> asac, kees, doko__ , didrocks: jamespage's MIR (bug 676904) is pertinent to other things he needs to work on for release, so if you could look at the MIR soonish - it would be appreciated.
[10:44] <Daviey> thanks :)
[10:44] <ogra> janimo, gracias :)
[10:47] <janimo> ogra, this is another issue. Sigh, nux reimplements a lot of stuff that is already handled by glib
[10:47] <ogra> oh my
[10:47] <ogra> do we know why ?
[10:47] <janimo> unicode, timers, threads
[10:48] <janimo> legacy
[10:48] <ogra> tsk
[10:48] <janimo> but mainatiner said they at least consider moving to glib
[10:48] <ogra> good
[10:48] <janimo> it started out as a from scratch project maybe without any external deps, so implements a lot of basic win/unix stuff
[10:49] <ogra> yeah, that should be fixed
[10:49] <ogra> reinventing the wheel doesnt really save time
[11:38] <seb128> hum, wth, on a fresh natty install I get no keyboard working on the gdm screen
[11:38] <seb128> but keyboard works in a vt and on the livecd image
[11:39] <RAOF> Uuuh, Xorg.0.log would be the first candidate for a debug hunt.
[11:40] <RAOF> That's a kinda important piece of functionality :)
[11:40] <seb128> startx returns
[11:40] <seb128> X: user not authorized to run the X server, aborting
[11:40] <seb128> wtf
[11:43] <RAOF> Run as root?
[11:43] <seb128> why do I need to?
[11:43] <RAOF> It needs root to do VT switching properly, at least.
[11:43] <seb128> startx always worked?
[11:43] <RAOF> But have we stopped installing it setuid, I wonder?
[11:43] <seb128> sudo startx works
[11:44] <RAOF> I have to admit to not testing startx very often.
[11:45] <seb128> RAOF, http://paste.ubuntu.com/568688/
[11:45] <seb128> that's the Xorg log
[11:47] <seb128> seems to configure the keyboard, wth
[11:48] <seb128> bah and the box crash on vt switch
[11:48] <RAOF> Hm.  Well, it certainly looks like it's loading evdev for what it believes to be the keyboard, so it's not that.
[11:49] <seb128> keyboard works in a sudo startx session, go figure
[11:50] <seb128> oh, the gdm log has some clue
[11:50] <seb128> "This incident has been reported.
[11:50] <seb128> Error: No Symbols named "oss" in the include "us""
[11:50] <seb128> seems like ubiquity did set up a broken keyboard config
[11:55] <seb128> ok, works now after tweaking the keyboard config
[12:56] <ogra> TheMuso, how does the alsa upgrade to new upstream go ?
[13:27] <PetrHH> Hello
[13:28] <PetrHH> I'm trying to package my program into deb. It is my first deb package ever. Package is creating without any problem but lintian utils still writes some errors. These errors: http://pastebin.com/HQPvL5UM
[13:29] <PetrHH> but I have no idea what does it means. Could anybody help me, please?
[13:31] <Laney> PetrHH: run lintian with --info and you'll get more explanation of each of those warnings
[13:34] <PetrHH> Laney, thank you!
[13:57] <shadeslayer> kees: sorry for pinging you again but, https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026/comments/6
[14:07] <PetrHH> Laney, do you know what file in debian directory is called maintainer script? I  have to add there #DEBHELPER#.
[14:09] <asac> PetrHH: typically debian/*.{post,pre}{inst,rm}
[14:09] <cjwatson> the term "maintainer script" is defined in the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[14:10] <PetrHH> asac, thank you! Now I solved all warnings of lintian util
[14:10] <asac> PetrHH: read what cjwatson gave you though
[14:10] <PetrHH> cjwatson, Thank you for link, I'll look at it.
[14:10] <asac> ;)
[14:10] <asac> np
[14:14] <ari-tczew> what do you think about version *ubuntu1b1 for rebuild?
[14:15] <dholbach> how about just ubuntu2?
[14:19] <Laney> dch --rebuild will give you a reasonable version string to use
[14:29] <cjwatson> oubiwann: whom should I talk to about a utouch packaging problem that's breaking debian-installer builds?
[14:29] <cjwatson> oubiwann: I can fix it, just want to make sure I'm not stepping on anyone's toes
[14:29] <oubiwann> oubiwann: cnd is the first person
[14:29] <oubiwann> which package?
[14:30] <oubiwann> cjwatson: er, don't know why I just called you myself...
[14:30] <cjwatson> utouch-frame - it needs to have a udeb added, then utouch-grail needs rebuilt against that
[14:30] <cnd> cjwatson, ahh yes
[14:30] <cnd> I thought we added one
[14:30] <cnd> oubiwann, is bregma free to handle it?
[14:30] <cjwatson> utouch-evemu and utouch-grail have udebs, but -frame doesn't
[14:31] <cnd> yeah
[14:31] <cnd> cjwatson, btw, I thought we didn't use d-i?
[14:31] <cjwatson> we do
[14:31] <cjwatson> (we had this discussion before :) )
[14:31] <ogra> oubiwann, thats because all of us want to be like cjwatson ;)
[14:31] <cjwatson> I can just submit a branch if that's easiest
[14:31] <oubiwann> ogra: hahaha
[14:31] <cnd> cjwatson, then my memory is failing :)
[14:31] <cnd> cjwatson, that's easy enough
[14:31] <bregma> what have I done this time?
[14:32] <cjwatson> 14:30 <cjwatson> utouch-evemu and utouch-grail have udebs, but -frame doesn't
[14:32] <cjwatson> breaks the debian-installer build - I think I'll just send you a branch for it
[14:32] <cnd> cjwatson, once you submit, we'll review and approve, then you can merge it and push to ubuntu proper
[14:32] <cnd> is that reasonable for you?
[14:33] <cnd> as a core dev you have write access to our packaging branch
[14:33] <cjwatson> np
[14:33] <bregma> hmpf, rydberg was asked to remove the udeb from utouch-frame to get it into universe
[14:33] <cjwatson> whoever asked him that was wrong
[14:33] <cnd> bregma, who told him to do that?
[14:34] <bregma> jeez, I can;t remember that, it was weeks ago
[14:34] <cnd> heh :)
[14:34] <cnd> we must have a witch hunt!
[14:34] <cnd> just throw out a name
[14:34] <cnd> any name
[14:34] <bregma> burnings!
[14:34] <cnd> as long as it's not me :)
[14:34] <oubiwann> hehe
[14:34] <oubiwann> no bus throwing!
[14:35] <oubiwann> we'll just make sure we'll share the good info next time :-)
[14:35] <bregma> as long as it gets fixed
[14:39] <cjwatson> bregma: looking at bzr history, the prior problem was that 'DEB_DH_MAKESHLIBS_ARGS_libutouch-frame1 = --add-udeb=libutouch-frame1-udeb' was in debian/rules, but there was no declaration for that package in debian/control
[14:39] <cjwatson> and no .install file for it
[14:39] <bregma> yeah, the udeb was removed prior to that but the packaging was not cleaned up properly
[15:22] <notch> hi, im trying to customize gajim package from ppa. In the rules file there is "ubuntu-prepare" target. I dont see any place where is it called. Is it standard target? Where can i find some documentation about it?
[15:36] <jibel> mvo, Hi, we receive lot of reports from users failing to upgrade from 10.04 to 10.10 because of xorg-xserver-video-nouveau like bug 721306. Usually purging xserver-xorg-video-nouveau does the trick. Can we do something with update-manager to fix that ?
[15:43] <ara> cjwatson, remember the testing that you asked us to do in a broad set of HW, looking for corruptions in the splash screen?
[15:44] <ara> is this still needed? and if it is, what exactly do you need?
[15:47] <cjwatson> ara: yes, I'd basically like a summary of hardware that "looks wrong" during the splash screen process
[15:47] <cjwatson> especially cases where it fails to get successfully to X
[15:48] <ara> cjwatson, OK, thanks
[15:48] <cjwatson> but also cases where the splash is something other than a correct-looking aubergine graphics-mode screen or a correct-looking aubergine text-mode screen
[15:48] <cjwatson> and I'd like to know whether the GRUB menu (hold shift at boot) is legible
[15:49] <cjwatson> on many systems there will still be a black screen for some period during boot; I don't need to know about that, for the time being
[15:49] <mvo> jibel: sure
[15:50] <mvo> jibel: I can add code for tihs
[15:50] <ara> cjwatson, all noted, thanks a lot for your input
[15:51] <cjwatson> great, appreciated
[15:52] <jibel> mvo, this is probable caused by the fix for bug 614993
[15:52] <seb128_> jdstrand, hey, do you want to sponsor the lucid security update on bug #718127?
[15:53] <mvo> jibel: thanks, that is indeed anoying if this is caused by a regression
[16:01] <seb128> zul, hey, do you think you could sponsor https://code.launchpad.net/~hudson-ubuntu/ubuntu/natty/libcommons-collections-java/bug-717157/+merge/49397?
[16:01] <zul> seb128: of course give me a couple of minutes
[16:02] <seb128> zul, thanks
[16:08] <zul> seb128: merged do you want me to upload it while im at it
[16:08] <seb128> zul, would be nice, thanks
[16:09] <cjwatson> persia: should I adjust ~developer-membership-board's membership in light of the recent election?
[16:12] <zul> seb128: done
[16:12] <seb128> zul, thanks
[16:29] <mvo> ScottK: hey, the backports-not-automatic stuff is finally making some progress again (apt had landed, python-apt support as well)
[16:29] <ScottK> mvo: Great to hear.  Very cool.
[16:30] <ScottK> mvo: Is that all of it at the tool level?
[16:30] <ScottK> I know software center and other applications could use some U/I to support it.
[16:31] <mvo> ScottK: the missing bits now are sofware-center ui and/or update-manager ui. plus support in aptdaemon
[16:31] <mvo> actually aptdaemon needs to come first, then s-c and/or u-m
[16:31] <ScottK> OK.
[16:31] <mvo> for u-m there is a branch already thats sort of working
[16:31] <ScottK> Cool.
[16:32] <mvo> but the hard work was done (donkult is as always the guy to thank)
[16:32] <ScottK> Excellent news.
[16:32] <ScottK> I guess I should figure out how to get the relevant Launchpad change done now.
[16:32] <ScottK> (I assume it still needs one)
[16:32] <mvo> oh, indeed
[16:32] <ScottK> I'll work on that then.
[16:32] <mvo> that needs to be done as well (also it should be the smallest amount of work, fingers crossed)
[16:35] <ScottK> I'll see what I can find out about that.
[16:36] <mvo> ScottK: time is short (unfortunately) until FF, but lets see what we can do. in any case, the important groundwork is done now (that blocked us)
[16:36] <ScottK> Yep.
[17:25] <didrocks> is there some known eglibc issue reported from today's upload?
[17:26] <DBO> doko__, I am here for blood
[17:26] <didrocks> DBO is hitting http://sourceware.org/bugzilla/show_bug.cgi?id=12454
[17:26] <DBO> and is here for blood
[17:26] <didrocks> :)
[17:27] <DBO> gah, half my stuff wont start
[17:28] <didrocks> I don't want to screw my box for testing :)
[17:28] <DBO> dont worry
[17:28] <DBO> I already did that for you
[17:29] <DBO> its borked
[17:29] <didrocks> DBO: downgrade on your box first
[17:33] <DBO> downgrade worked
[17:34] <DBO> but... 2.13 sounds sexy
[17:34] <didrocks> cjwatson: doko__ ^^
[17:34] <DBO> and my update manager wishes me to upgrade again
[17:34] <didrocks> DBO: it's a trap!  :-)
[17:35] <DBO> its a tarp!
[17:36] <doko> hmm, I did build a compiler with it
[17:39] <DBO> doko, I couldn't start quite a few applications with the new glibc
[17:40] <DBO> it basically broke a large (but seemingly random) percentage of my apps
[17:41] <DBO> doko, are you running 32 or 64 bit?
[17:50] <kees> shadeslayer: I've updated the bug report to point out the duplicated code
[17:58] <hallyn> when i do 'bzr branch lp:debian/experimental/multipath-tools', it works. but when i do 'bzr branch lp:debian/unstable/multipath-tools', that doesn't exist.  Likewise, I can't "pull-debian-source multipath-tools".  Can anyone explain why?  The package does seem to exist by that name as per http://packages.debian.org/unstable/admin/multipath-tools
[17:59] <jelmer_> hallyn, hi
[17:59] <jelmer_> hallyn, does lp:debian/sid/multipath-tools work?
[18:00] <hallyn> jelmer_: jinkeys, it does, thanks.
[18:00] <hallyn> but so why does pull-debian-source not work?
[18:01] <jelmer_> hallyn: there's an open bug about supporting the unstable, testing and stable aliases in launchpad (don't have the bug # here though)
[18:01] <seb128> @pilot out
[18:02] <jelmer_> have a nice weekend seb128 :)
[18:02] <seb128> jelmer_, thanks!
[18:02] <seb128> you as well ;-)
[18:02] <hallyn> jelmer_: thanks
[18:02] <jelmer_> hallyn: How does pull-debian-source fail?
[18:05] <jelmer_> hallyn: it fetches 0.4.8+git0.761c66f for me
[18:05] <jelmer_> seb128: Thanks :)
[18:06] <hallyn> jelmer_: well what the heck.  I tried three times and got 'Unable to find mulitpath-tools in unstable'.  Now it fetched it
[18:06] <hallyn> thanks, looks like I"m all set now :)
[18:10] <doko> DBO: did you test this patch?
[18:10] <DBO> i did not
[18:14] <bdmurray> doko: I've run into the same issue with evolution on x86_64
[18:18] <marcrouse> hi
[18:18] <marcrouse> i suche logari81
[18:19] <Chipzz> marcrouse: first of all the official language of this channel is English; you're highly unlikely to get an answer in a different language
[18:20] <marcrouse> i m sorry
[18:20] <marcrouse> i search logari81
[18:20] <Chipzz> 2nd, my last log shows no occurence of that name; it's not very likely you'll find some random user here (unless of course there's good reason to believe he frequents this channel; which I doubt there is)
[18:22] <Chipzz> (I read the backlog of this channel regulary, and I don't recall seeing anyone by that name talk here either recently or at all)
[18:22] <doko> bdmurray, DBO: just uploaded a test package to https://launchpad.net/~ubuntu-toolchain-r/+archive/test/ currently building
[18:22] <DBO> okie dokie
[18:25] <Chipzz> marcrouse: I see the guy has a PPA; I would suggest you ask in #ubuntu-motu, chances are ppl over there have seen him
[18:26] <Chipzz> marcrouse: (#ubuntu-devel is mostly (99%) about the development of ubuntu main; discussion of PPA's (unless they contain software which is in main) is done in #ubuntu-motu)
[18:43] <doko> bdmurray, DBO: amd64 build finished
[18:45] <DBO> doko, will test in a bit
[19:11] <doko> bdmurray, DBO: away for the evening
[19:12] <ScottK> hallyn: pull-debian-source works fine here.
[19:12] <DBO> doko, understood
[19:12] <ScottK> Ah, I see you got it working.
[19:13] <ScottK> Chipzz: PPA's aren't on topic in #ubuntu-motu either.
[19:29] <didrocks> ScottK: hey
[19:29] <didrocks> ScottK: did you follow the eglibc issue?
[19:30] <ScottK> didrocks: I've read the stuff on IRC.
[19:30] <ScottK> (and I'm not updating anything just now as a result)
[19:30] <didrocks> DBO: did you try the patched version? will be nice to know before the week-end if the new one is working
[19:31] <didrocks> ScottK: just trying to figure if we should revert or not for amd64 users (I'm on i386, so can't test)
[19:31] <DBO> i will test in a minute
[19:31] <DBO> mmm cheese and mustard are a good combo
[19:36] <Chipzz> ScottK: ah k. thought they were
[19:36] <ScottK> Chipzz: We do Ubuntu in there too.
[19:37] <Chipzz> ScottK: universe and multiverse that I know of idd
[19:38] <ScottK> Chipzz: Yes.  In Ubuntu.  PPA's aren't part of Ubuntu, so they're no more on topic there than here.
[19:39] <micahg> PPA packaging can be discussed in #ubuntu-packaging, PPA support would be in #launchpad
[19:40] <dobey> i guess problems with a particular PPA should be discussed with the PPA owner though, not #launchpad or #ubuntu-packaging, in general
[19:41] <dobey> which is what i guess the guy was trying to do, but the owner wasn't in here
[19:43] <Chipzz> and the chance of him being in #ubuntu-motu was higher
[19:44] <cjwatson> didrocks: please do not revert libc6
[19:44] <cjwatson> didrocks: the dependency chaos would be horrible
[19:44] <cjwatson> we need to go forward there, not backward
[19:44] <didrocks> cjwatson: that's why I didn't want to do that on my own :)
[19:44] <didrocks> (and was waiting)
[19:45] <dobey> i don't know if that's true, but /whois should answer whether someone is on irc or not
[19:45] <cjwatson> if somebody can confirm the upload doko referred to, I can upload it
[19:45] <didrocks> I think DBO will test in a few
[19:46] <DBO> I am testing hold on
[19:46] <DBO> I dont like installing ppas is all...
[19:46] <cjwatson> (well, not right now because it's my daughter's bathtime, but this evening)
[19:46] <DBO> gah
[19:46] <DBO> there are other thing in that PPA
[19:47] <DBO> time to download debs
[19:49] <hallyn> ||http://pastebin.ubuntu.com/568876/
[19:49] <hallyn> oops, sorry
[19:50] <hallyn> misfir
[20:00] <DBO> cjwatson, the fix does not work
[20:01] <seb128> cjwatson, doko: since the update doesn't work and natty is broken should we consider asking to block the binaries from being downloaded?
[20:34] <janimo> which package sets up the 'Restart Needed' notification after certain kernel upgrades?
[20:37] <ohsix> good question, you could look in the debian dir in the source package
[20:40] <janimo> ohsix, I was hoping someone knows so I don't have to look in the various kernel related packages :)
[20:40] <ohsix> i think i might have it laying around already, one sec
[20:40] <ohsix> ah nope i rm'd it
[20:41] <cjwatson> seb128: I'm not happy with that either, that would be massive disruption
[20:41] <cjwatson> DBO: do you have any more details?
[20:42] <cjwatson> DBO: which architecture are you using?
[20:42] <seb128> cjwatson, we got Jason and bdmurray to confirm and bug reports with duplicates
[20:42] <seb128> cjwatson, using amd64
[20:42] <cjwatson> does it happen on i386?
[20:42] <soren> Sorry, which binaries are we talking about?
[20:42] <seb128> cjwatson, i.s got asked to block the amd64 binaires
[20:42] <cjwatson> soren: eglibc
[20:42] <soren> Erk.
[20:42] <cjwatson> argh
[20:42] <seb128> soren, https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/721469
[20:43] <soren> I was *just* about to update my laptop and test systems. Phew.
[20:43] <jcastro> soren: likewise
[20:44] <highvoltage> jcastro: you're an omg!ubuntu writer now?
[20:44] <jcastro> heh
[20:45] <cjwatson> DBO: did you get literally the same error message with the upgraded libc?
[20:45] <cjwatson> DBO: I'd appreciate a copy-and-paste of the error you get with the new libc packages
[20:45] <ricotz> soren, hello, are you the right one who can look at a plymouth package?
[20:46] <DBO> DBO, its the exact same error
[20:46] <DBO> cjwatson,  Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!
[20:47] <soren> ricotz: Not really, sorry.
[20:47] <cjwatson> that's odd, because I would have expected at least the line number to change or something
[20:47] <ricotz> soren, who might be?
[20:48] <seb128> ricotz, subscribe ubuntu-sponsors
[20:48]  * cjwatson hunts down the diff
[20:48]  * soren actually didn't think he'd be able to set the /TOPIC
[20:48] <seb128> cjwatson, http://launchpadlibrarian.net/64652847/eglibc_2.13~pre1-0ubuntu1_2.13-0ubuntu1~ppa1.diff.gz
[20:48] <seb128> cjwatson, that's doko's upload
[20:49] <cjwatson> it's OK, I can drive LP, it just takes a while :)
[20:49] <seb128> cjwatson, well I had it in a tab open so I figured I would spare you to search for the ppa etc
[20:50] <cjwatson> doko only applied one of the two patches in the upstream report, by the looks of things
[20:50] <cjwatson> perhaps he thought it was one or the other; my reading is that it's a two-parter
[20:50] <DBO> its two parts
[20:51] <seb128> cjwatson, right, c.f what I copied on the other channel
[20:51] <seb128> sorry for dispatching the info in 2 channels
[20:52] <cjwatson> I'll do another test upload in a bit
[20:53] <cjwatson> just want to do some reading here
[20:53] <kees> the first patch could probably do s/assert (nlist > 1)/assert (nlist > 0)/ with s/while (1)/while (nlist > 1)/ to reduce the indentation insanity
[20:54] <cjwatson> yes
[20:59] <robbiew> seb128: so we've blocked the download now, right?
[20:59] <seb128> robbiew, yes, downloads and mirroring are blocked
[20:59] <robbiew> ok, thnx
[21:00] <cjwatson> just putting all the pieces together here, since doko's previous test upload included a bump to 2.13 proper and a new .orig.tar.gz
[21:00] <didrocks> DBO: it worths to wait and warn people :)
[21:00] <bdmurray> seb128: this won't get caught by apport is that right?
[21:00] <cjwatson> fortunately that's in Debian experimental so the orig exists publicly
[21:01] <seb128> bdmurray, not sure but the people who reported it did without apport and it's an assertion and not a crash
[21:01] <seb128> so it's likely apport will not report those
[21:02] <ohsix> would be nice if apport did assertion reports, it catches them but then says they're not supported
[21:02] <bdmurray> okay, I can't find any apport-crash tagged bugs about it either
[21:03] <bdmurray> I was hoping to stop any from coming in
[21:04] <soren> ricotz: What do you need, exactly?
[21:04] <seb128> ohsix, it does support them if they have an assertion description as well
[21:04] <seb128> but right, it's suboptimal
[21:06] <ricotz> soren, i wanted to propose an update of the pretty old upstream version of plymouth, since 0.8.3 is pretty old too, i might be useful to take the current git version, i already packaged and using it
[21:07] <cjwatson> if you do that make sure the quilt patches are intelligible
[21:08] <cjwatson> and make extra sure that all the patches we still have on top of upstream are still there
[21:10] <kees> seb128: apport is _supposed_ to catch asserts.
[21:10] <cjwatson> catching asserts in the dynamic loader might be more of a challenge than usual ...
[21:11] <soren> ricotz: Yeah, I'm totally not the right person to talk to about that. I just did a couple of drive-by's on Plymouth.
[21:11] <kees> yeah, I think the dl asserts aren't actually hooked up to the glibc assert framework.
[21:11] <kees> in which case, apport will ignore it
[21:13] <ricotz> soren, so slangasek might be the right person?
[21:14] <ohsix> seb128: ah
[21:14] <ohsix> seb128: the most pernicious ones are assertions, too :]
[21:14] <slangasek> ricotz: well, I'd be willing to review any proposed merges.  cjwatson has the gist of it though
[21:15] <cjwatson> I don't have time for such a plymouth merge at the moment, unfortunately
[21:15] <slangasek> ricotz: also I'm not thrilled about updating plymouth the week before feature freeze... if that was going to be done this cycle it would've been better to merge it sooner
[21:15] <ricotz> slangasek, yeah i dont wanted to bug cjwatson, he seems pretty busy ;)
[21:15] <cjwatson> (one of the problems for me with sponsoring merges is that I always find that reviewing them takes much, much longer than doing it myself)
[21:15] <slangasek> ricotz: sorry, I meant: I don't have much to say on the subject besides what cjwatson already said
[21:16] <slangasek> and by review merge I mean reviewing a UDD merge request, btw
[21:16] <slangasek> anything short of that, and the comments about reviewing merges taking longer than doing merges apply
[21:16] <lifeless> cjwatson: what takes up the bulk of that time?
[21:17] <cjwatson> sorry don't have time to explain right now
[21:17] <lifeless> cjwatson: another time then
[21:17] <cjwatson> conversation too wide for this irc channel
[21:17] <ricotz> slangasek, ok, i see
[21:22] <cjwatson> eglibc 2.13-0ubuntu1~ppa2 uploaded to the same PPA
[21:22] <cjwatson> amd64 built inside 20 minutes last time, so hopefully it'll do so again
[21:24] <TheMuso> ogra: Started working on it yesterday, and will be finishing and uploading it first thing next week, if not sooner.
[21:30] <arand> Complete RE history is ~2G, surprisingly small...
[21:32] <ogra> TheMuso, awesome, thanks, TI was asking :)
[21:34] <slangasek> cjwatson: hi, put two and two together and read through scrollback here; as it happens I was just about to push the orig.tar.gz for eglibc 2.13~pre1 onto the pristine-tar part of the UDD branch, is that going to slow you down if I do?  (Alternatively, is there something else you'd rather I be doing with my time in order to help rather than hinder? :)
[21:45] <cjwatson> slangasek: I think that should be OK, as long as doing so doesn't change lp:ubuntu/eglibc itself?
[21:46] <slangasek> cjwatson: it does because it adds a no-change commit to lp:ubuntu/eglibc to add the reference to the upstream tarball
[21:46] <slangasek> cjwatson: so I'll just cool my heels until you're done, so I don't slow you down :)
[21:46] <cjwatson> argh, upload rejected
[21:46] <cjwatson> a no-change commit won't make a difference
[21:46]  * cjwatson grabs the orig from LP instead
[21:47] <cjwatson> slangasek: please note that the orig in Debian and the one in Ubuntu aren't the same - I think because of the manual
[21:47] <slangasek> it's no change on the tip, it has a *large* batch of metadata :)
[21:47] <slangasek> well, the upstream version number between Debian and Ubuntu isn't the same either
[21:47] <cjwatson> I mean it won't slow me down
[21:47] <slangasek> ok
[21:47] <cjwatson> slangasek: it wasn't in the last upload - it will be in the next
[21:47] <slangasek> ah
[21:48] <cjwatson> at least I believe so.  2.13 in both, right?
[21:48] <slangasek> he labelled it '2.13~pre1', I assumed that was deliberate?
[21:48] <cjwatson> in the PPA he bumped to 2.13
[21:48] <slangasek> ok
[21:48]  * slangasek again, keeps his hands off
[21:49] <slangasek> the tarball I imported is the one he labelled 2.13~pre1
[21:49] <cjwatson> https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+files/eglibc_2.13.orig.tar.gz
[21:49] <slangasek> if there's a different one for 2.13, I can do merge-upstream again as needed
[21:52] <cjwatson> ^- the above is the one I'll be using, anyway
[21:54] <cjwatson> uploaded again, hopefully won't be rejected this time
[21:56] <cjwatson> good, building
[21:57]  * cjwatson goes off for a bit to watch Bones
[22:26] <slangasek> cjwatson: so do I have this right that you're doing a ppa build first to verify the fix, and the upload goes to the archive only if it checks out?
[22:31] <charlieS> slangasek,cjwatson: /me notes that someone needs to tell IS when to re-enable publishing syncing, so things can actually hit the archive.
[22:31] <charlieS> if that ETA is within ~3.5 hours, no problem.
[22:42] <slangasek> charlieS: I guess it *should* be within that time, but I don't know the full plan here
[22:42] <slangasek> I came into this by accident because I was prepping a new eglibc upload to my multiarch ppa
[22:44] <slangasek> cjwatson: I'm definitely at a loss to understand why doko built a new tarball rather than using the one already in Debian; are we sure that's deliberate?
[22:44] <slangasek> doko: ^^ ?
[22:56] <slangasek> cjwatson, doko: n/m, I see that there's an added GFDL manual on the Ubuntu side, that explains it
[22:58] <slangasek> DBO: are you the designated tester for this fix? :)  The amd64 packages of eglibc are built: https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+buildjob/2271568
[23:00] <DBO> slangasek, I am not the designated tester, but I will do it in a little bit
[23:00] <DBO> :)
[23:00] <slangasek> DBO: cheers :)
[23:06] <cjwatson> slangasek: tarball> GFDL divergence - we ship the manual
[23:06] <slangasek> yep
[23:06] <cjwatson> oh, you saw
[23:06] <cjwatson> slangasek: and yes, PPA to verify
[23:07] <slangasek> ok
[23:07] <cjwatson> also the PPA has the testsuite disabled
[23:07] <cjwatson> (for speed, I think)
[23:07] <slangasek> ah :)
[23:13] <ohsix> is vino supposed to turn off desktops effects when you connect? it's reaaaaally hard to use when compiz is running
[23:18] <cjwatson> bdmurray: I don't suppose you would have time to test the amd64 libc6 in https://launchpad.net/~ubuntu-toolchain-r/+archive/test?
[23:21] <RoAkSoAx> cjwatson: fwiw i just installed it and evolution doesn't crash anymore (which is what crashed in my case)
[23:21] <bdmurray> cjwatson: sure I could do that
[23:23] <cjwatson> the upstream commit that introduced this was 968dad0ab1f367a087ff4ad503b511dd0c565adc
[23:23] <cjwatson> "Fix ordering of DSO constructors and destructors."
[23:26] <cjwatson> FWIW I suspect LD_PRELOADing something random and pointless is a workaround
[23:27] <cjwatson> oh, here, I bet that's it
[23:27] <cjwatson> hypothesis: any dlopen will fail
[23:28] <cjwatson> maybe only a dlopen of a sufficiently simple object
[23:28] <cjwatson> e.g. one with no DT_NEEDED entries of its own
[23:28] <cjwatson> anyway, this is basically just guesswork from code inspection
[23:39] <aroman> hello, does anyone know how to change the "You may wish.." text as seen here: http://i.imgur.com/6yOIE.png In ubiquity? I've been ripping through its source tree looking for it, but i can't find it. Thanks :)
[23:41] <cjwatson> just grep for it
[23:42] <cjwatson> try not grepping for the whole string though, since there's markup around "release notes"
[23:43] <cjwatson> bdmurray: anything?
[23:43] <bdmurray> cjwatson: do know of any applications I should test?  evolution is behaving badly in a different way
[23:43] <cjwatson> I'm planning to upload shortly on the strength of RoAkSoAx's test
[23:43] <cjwatson> how does it misbehave?
[23:44] <cjwatson> I have no idea, I'm just shuffling patches :P
[23:44] <aroman> cjwatson: think this'll do the trick: find . | xargs grep -i "You may wish to read" (In the root directory)
[23:45] <bdmurray> (evolution:1154): evolution-plugin-lib-WARNING **: can't load plugin '/usr/lib/evolution/2.32/plugins/liborg-gnome-exchange-operations': libexchange-storage.so: cannot open shared object file: No such file or directory
[23:45] <cjwatson> hmm
[23:45] <cjwatson> aroman: just use grep -r
[23:45] <cjwatson> no need to mess about with find and xargs
[23:46] <bdmurray> that happens on old with the old version of eglibc though
[23:46] <aroman> lol i didn't even realize it had that param
[23:46] <cjwatson> bdmurray: could you run 'strace -etrace=file -f -o evolution.trace evolution' and post evolution.trace?
[23:49] <cjwatson> bdmurray: actually, never mind, that seems like a package bug to me; the linkage is there but the library is nowhere to be found
[23:51] <bdmurray> cjwatson: okay
[23:51] <cjwatson> I'm going ahead and uploading
[23:51] <cjwatson> (to natty)
[23:56] <kees> cjwatson: yeah, it doesn't seem to eat my VM, and ogg123 runs.


[00:12] <camako> fginther, works for me!
[00:29] <camako> fginther, though the device seems to be stuck at the 'Google' splashscreen and adb doesn't work... u-d-f generates 'initctl: unable to determine sessions' errors... I suspect the debs that are pulled in may not be correct for vivid...
[07:09] <RAOF> We're cool with std::experimental, right? :)
[09:11] <anpok_> RAOF: for optional?
[10:14] <alan_g> duflu: according to bzr you put the (failing in CI) equality test in StaleFrames.are_dropped_when_restarting_compositor (line 209). It doesn't seem to be testing the stale frames and it isn't obvious to me why it is correct do you remember?
[10:14] <duflu> alan_g: No idea. My brain is now officially fried
[10:14] <duflu> I'm departing soon
[10:15] <alan_g> OK. Have a good night!
[10:15] <duflu> alan_g: Also bzr blame is notoriously unreliable/hard to follow
[10:15] <alan_g> agreed
[10:16] <alan_g> But it is pretty clear that only you and alf_ have touched that test
[10:19] <alan_g> Definitely you: bzr log -c 2002 tests/integration-tests/test_stale_frames.cpp (and the pre code on that line makes sense)
[10:20] <alan_g> Anyway, have a good weekend.
[10:26]  * alf_ bangs head against wall... glib main loop and forking after having created a signal source in the same thread (e.g. from previous tests) don't work well at all
[10:27] <alan_g> alf_: maybe you should use asio. ;^)
[10:28]  * duflu vomits on keyboard
[10:29] <duflu> It must be time to go...
[10:57] <alan_g> alf_: could you take a look at this? (Trying to unblock CI) https://code.launchpad.net/~alan-griffiths/mir/fix-1390388/+merge/241060
[10:58] <alf_> alan_g: looking
[11:09] <alf_> alan_g: Not sure how this version is different than the previous one. The two versions are testing the same thing, expressed slightly differently, or am I missing something?
[11:11] <alan_g> They are not. Suppose new_buffers[0] is a fourth buffer.
[11:24] <alf_> alan_g: That's an error (where did the 4th buffer come from?). We want new_buffers[0] to be the third buffer, i.e., the latest sent by the client.
[11:25] <alan_g> alf_: OK I've misunderstood the test
[11:26]  * alan_g is still interested to see what happens in CI though