[01:17] <mjg59> mdz: Ok, working graphical hibernate
[01:17] <mjg59> (modulo the bugs that stop hibernate working with splash at the moment, which also stop this working with splash. But still)
[01:18] <mdz> mjg59: woo
[01:19] <mjg59> I'll upload the needed usplash changes now
[01:34] <sabdfl> mjg59: very cool indeed. should i be testing hibernate etc on an x60?
[01:34] <mjg59> sabdfl: Not just yet
[01:34] <sabdfl> ok, ping when it would help
[01:34] <mjg59> It'll need a new kernel first
[01:35] <sabdfl> ok, i'll find a kernel maintainer in a bandana to poke
[01:36] <zul> hola
[01:45] <Seq> does anybody have much experience with apt-ftparchive, or can suggest a better way to run a repository?
[01:46] <bluefoxicy> how are duplicates handled?
[01:46] <desrt> Seq; http://ubuntu.desrt.ca/Makefile
[01:46] <jdub> Seq: http://www.gnome.org/~jdub/ubuntu/edgy/Makefile
[01:46] <desrt> hahah
[01:46] <bluefoxicy> except my bug is months older :O
[01:46] <desrt> mine comes from jdub answering that same question to me a while ago :)
[01:47] <bluefoxicy> is there some sort of competition on who has the coolest bug?
[01:47] <Seq> thanks desrt & jdub
[01:47] <tseng> hi desrt
[01:47] <desrt> tseng; goodbye.
[01:47] <Seq> desrt, also, thanks tonnes for the macbook-backlight
[01:47] <tseng> oh, fine
[01:47] <desrt> Seq; no prob :D
[01:48] <desrt> Seq; it was a fun hack to reverse engineer the apple stuff to figure out how it worked :)
[01:48] <tseng> Seq: desrt has a sick and twisted concept of "fun"
[01:49] <Seq> desrt, thats why i got a macbook. I thought it would be a useful (and possibly fun, yes) use of my time.
[01:49] <desrt> tseng; i was sitting in the shwarma place across the street frm the university with a good friend and we were poking random values at guessed memory locations on my shiny new laptop
[01:49] <tseng> Seq: like playing drunken match maker for the locals in a foreign country
[01:49] <desrt> tseng; that's fun :)
[01:49] <Fujitsu> desrt, that does sound fun :P
[01:49] <desrt> tseng; now that's just a weird person who would do that
[01:50] <tseng> yeah, I don't know anyone of the sort
[01:50] <desrt> b'sides.  i didn't play matchmaker
[01:50] <desrt> i just greased the wheels a bit with copious amounts of alcohol
[01:51] <tseng> you altered the course of business
[01:51] <desrt> it'd have happened eventually anyway
[01:51] <tseng> I doubt it, did you not notice his hair
[01:51] <desrt> you're a jerk :p
[01:52] <tseng> this is true.
[01:52] <desrt> anyway... baris was there too.
[01:52] <tseng> baris ciciek?
[01:52] <desrt> ya
[01:52] <desrt> the 4 of us
[01:52] <tseng> wish i'd met him
[01:52] <desrt> cool guy.  strong silent type :)
[01:52] <tseng> working with him on last-exit now
[01:52] <tseng> i wasnt aware of him previously
[01:53] <desrt> do you know what he looks like?
[01:53] <tseng> nope
[01:53] <tseng> please help
[01:53] <tseng> for all I know we chatted it up
[01:53] <desrt> plz wait.
[01:54] <desrt> http://desrt.mcmaster.ca/random/baris+friends.jpeg
[01:55] <tseng> oh, don't think so
[01:56] <desrt> he was around....
[01:56] <tseng> i saw him
[01:56] <tseng> i don't recall having a chat
[01:56] <tseng> I didnt really introduce myself to random people
[01:56] <desrt> your loss :)
[01:57] <tseng> yeah
[02:00] <exobuzz> is there a workaround for this bug yet ? https://launchpad.net/distros/ubuntu/+source/python2.4/+bug/56779
[02:00] <Ubugtu> Malone bug 56779 in python2.4 "Error during Dapper-->Edgy update" [High,Confirmed]
[02:00] <tseng> desrt: im lounging in my ucc shirt btw
[02:01] <tseng> desrt: computer clubs you
[02:01] <desrt> :)
[02:04] <Keybuk> ucc?
[02:04] <tseng> Keybuk: hold
[02:05] <mjg59> Today I have uploaded more crack than you can shake a stick at
[02:05] <tseng> Keybuk: http://www.ucc.asn.au/t-shirts.ucc
[02:06] <tseng> Keybuk: computer club at davyd madely's university
[02:06] <Keybuk> ah
[02:08] <desrt> madeley
[02:08] <tseng> sure.
[02:08] <desrt> hmm.  they're sold out now
[02:09] <desrt> that shirt is very popular at my school :)
[02:09] <desrt> everyone wants one
[02:09] <tseng> i dont really wear this sort of thing out on the town
[02:09] <tseng> "Mono" doesnt go over well in public here either
[02:09] <desrt> me neither.  but school is fair game for borderline fashion
[02:11] <tseng> you think the jokes would be too obvious to be funny
[02:11] <tseng> but most people don't agree
[02:11] <LaserJock> heh, I hadn't really thought of that
[02:12] <tseng> It's Moh-no, not Mon-oh
[02:12] <Burgundavia> iwj: you broke gai
[02:12] <tseng> but americans arent cultured like that
[02:12] <LaserJock> heh
[02:12] <Burgundavia> iwj: Bug #57528
[02:12] <Ubugtu> Malone bug 57528 in gnome-app-install "[Edgy]  Missing dependency on python-gdbm" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57528
[02:13] <desrt> g_key_file is really really easy to use.
[02:14] <tseng> desrt: whats that?
[02:14] <desrt> [section]
[02:14] <desrt> key=value
[02:14] <desrt> key2=value2
[02:14] <desrt> this sort of file
[02:15] <tseng> oh.
[02:15] <desrt> it even has a load_from_data_dir interface
[02:15] <desrt> so i can tell it "applets/WeatherApplet"
[02:15] <desrt> and it will check /home/desrt/.local/share/applets/WeatherApplet, /usr/local/share, /usr/share, etc...
[02:17] <desrt> and because of the way the API works (which might actually seems a bit weird/annoying at first) you can make a bunch of calls without ever checking for errors on the intermediate calls and the final call will just return NULL if -anything- bad happened at all along the way
[02:18] <tseng> why a file and not gconf?

[02:18] <tseng> i see for weather applet
[02:19] <desrt> oh.  no.  think like .desktop file
[02:19] <desrt> this is just a pointer to the location of the executable
[02:19] <HrdwrBoB> the weather applet should use the timezone for the default location
[02:19] <tseng> HrdwrBoB: uh
[02:19] <tseng> HrdwrBoB: right.
[02:19] <desrt> HrdwrBoB; bad idea.  country is much more accurate
[02:19] <desrt> (which is what it does now, in a roundabout way)
[02:19] <HrdwrBoB> I mean Location
[02:19] <HrdwrBoB> wrt timezone
[02:19] <HrdwrBoB> Austraila/Melbourne
[02:20] <HrdwrBoB> f.e.
[02:20] <desrt> that works great for australia maybe, but not most of the rest of the world
[02:20] <desrt> where central european time is a huge number of countries
[02:20] <HrdwrBoB> people in the rest of the world don't put in their location correctly?
[02:20] <tseng> new york and some place in south america are probably in the same TZ
[02:20] <HrdwrBoB> it's at least closer
[02:20] <tseng> closer than what?
[02:20] <Burgundavia> the weather applet has other issues
[02:20] <tseng> if you have to set it, you have to set it
[02:21] <tseng> it has search, no big deal
[02:21] <desrt> k let's stop talking about applets :p
[02:21] <tseng> yeah, don't hurt desrt
[02:21] <desrt> k thx
[02:21] <tseng> Keybuk: what in the world are you doing up, anyway?
[02:21] <mae> hey guys, I was wondering if you could suggest a reasonably priced linux friendly core2 laptop -- anyone in the market lately?
[02:22] <Burgundavia> desrt: btw, great work on the api stuff. I am sure that people smarter than me will appreciate it
[02:22] <tseng> mae: there are hardly any core2 laptops in the market atm
[02:22] <desrt> Burgundavia; i hope vincent appreciates it as he's writing my final evaluation :)
[02:23] <tseng> Burgundavia: the key for you is, "no more bonobo"
[02:23] <Burgundavia> tseng: but I like monkeys!
[02:23] <Burgundavia> I mean, I love you, tseng
[02:23] <desrt> Burgundavia; so have some mono
[02:23] <tseng> Burgundavia: or maybe you don't remmeber the days of 'bonobo-slay'
[02:23] <desrt> heh
[02:23] <desrt> we're having a real life bonobo-slay these days
[02:23] <tseng> that was so badass
[02:24] <desrt> and it doesn't take a commandline argument
[02:24] <tseng> evolution would break it all
[02:24] <desrt> it just slays itself
[02:24] <tseng> killall orbit
[02:24] <tseng> gconfd
[02:24] <tseng> bonobo-slay
[02:24] <desrt> k.  i'm out.
[02:24] <tseng> etc
[02:24] <HrdwrBoB> mae: macbook :)
[02:24] <tseng> HrdwrBoB: didnt he just say "linux friendly"?
[02:25] <tseng> HrdwrBoB: and core2?
[02:25] <tseng> HrdwrBoB: and... reasonably priced?
[02:25] <mae> HrdwrBoB: i thought they got super hot
[02:26] <Keybuk> tseng: coding ;)
[02:26] <HrdwrBoB> macbook is reasonably priced
[02:26] <HrdwrBoB> macbook PRO is expensive
[02:27] <HrdwrBoB> and oh.. I'm blind, there are no core 2 laptops afiak
[02:28] <exobuzz> macbook pro looks nice though
[02:28] <exobuzz> :-)
[02:30] <exobuzz> why when it comes to electronics is the exchange rate from USD to GBP about $1 to the pound ?
[02:30] <exobuzz> it just isnt fair..
[02:31] <mae> how is Intel(R) Graphics Media Accelerator 950 support?
[02:31] <Burgundavia> mae: very good
[02:32] <mae> better than/same as an nvidia setup?
[02:32] <mae> how about power management?
[02:33] <exobuzz> i have some big regrets getting a laptop with an ati card (for linux)..
[02:33] <mae> heh
[02:34] <mae> well i just want something powerful enough for xgl/aiglx and maybe a few light games -- but power management is more important to me, i want suspend-to-memory working
[02:35] <exobuzz> suspend to memory.. i remember that.. back when i had a laptop which didnt have an ati card :-)
[02:35] <mae> haha
[02:36] <exobuzz> mae: you want some eye candy eh ?
[02:36] <mae> well i hope you guys don't mean vesa when you say "good linux support"
[02:36] <bddebian> Howdy folks
[02:36] <mae> i want hardware acceleration support
[02:36] <mae> exobuzz: well thats OK but mainly i want it for scale(expose` ripoff)
[02:36] <mae> it makes navigating bagillions of windows much more functional
[02:37] <exobuzz> bagillions.. wow. thats like. more than a billian right ? :-)
[02:38] <mae> lol
[02:38] <mae> exactly
[02:39] <exobuzz> i dont see why you need more than one window... should be enough. with a basic prompt of course, and some free ram. built in assembler is a bonus!
[02:39] <exobuzz> aah the good old days
[02:47] <Keybuk> I HATE AUTOMAKE
[02:50] <Keybuk> [02:50] <Keybuk> upstart-0.1.0 archives ready for distribution:
[02:50] <Keybuk> upstart-0.1.0.tar.gz
[02:50] <Keybuk> upstart-0.1.0.tar.bz2
[02:50] <Keybuk> [02:50] <Keybuk> \o/
[02:51] <tseng> upstart?
[02:51] <Keybuk> aye
[02:51] <bddebian> *\O/*
[02:51] <Burgundavia> tseng: Keybuks new init crack
[02:51] <bddebian> hehe
[02:51] <tseng> weirdo
[02:51] <tseng> does it use the old scripts?
[02:52] <bddebian> Heya tseng
[02:52] <tseng> hello
[02:52] <Keybuk> tseng: yeah, it runs them
[02:52] <tseng> Keybuk: elite
[02:52] <Keybuk> it would be a hell of an annoying transition if it didn't
[02:52] <tseng> eight
[02:52] <tseng> right
[02:53] <bluefoxicy> so what cool shit did you add?
[02:53] <bluefoxicy> init script dependencies?  Named and hierarchical runlevels?  Dancing catgirls on usplash?
[02:55] <Keybuk> none of those three things
[02:55] <tseng> runlevels are for suckers
[02:55] <bluefoxicy> tseng:  hence why I have 6 of them.
[02:55] <HrdwrBoB> kernels depending on udev?
[02:55] <bluefoxicy> seven, I guess 0 is a valid runlevel.
[02:56] <HrdwrBoB> and by that I mean they DON'T depend on udev
[02:56] <tseng> HrdwrBoB: would you like devices?
[02:56] <tseng> oh.
[02:56] <HrdwrBoB> yes, I like devices very much
[02:58] <Keybuk> right, bed
[02:58] <Keybuk> before I do anything more
[02:58] <tseng> g'night Keybuk
[03:01] <bddebian> Gnight Keybuk
[03:16] <tseng> desrt: boston summit?
[04:20] <bddebian> Anyone around that can check if my ipac-ng upload got rejected?
[04:35] <toddobryan> Sorry if this is OT, but it looks like the latest portmap package was compiled without tcpwrappers support. It ignores /etc/hosts.deny and /etc/hosts.allow
[04:35] <toddobryan> Where can I verify and report that?
[04:40] <lifeless> will the buildlog tell you ?
[04:42] <toddobryan> Where would it be?
[04:45] <Hobbsee> launchpad, presumably
[04:45] <lifeless> https://launchpad.net/distros/ubuntu/+source/portmap
[04:45] <bddebian> toddobryan: https://launchpad.net/+builds/+build/226076
[04:45] <lifeless> takes you to https://launchpad.net/distros/ubuntu/+source/portmap/5-20
[04:45] <lifeless> and from there you can get to the url bddebian has pasted, which is for i386
[04:46] <toddobryan> I just downloaded the source. It has a WRAP_LIB line commented out, but another one with WRAP_LIB = -lwrap in there.
[04:46] <lifeless> if you are not on i386 though, you should look at the buildlog for your architecture
[04:46] <toddobryan> http://nfs.sourceforge.net/nfs-howto/ar01s06.html
[04:47] <toddobryan> I tried the check the NFS HowTo suggested, and there's no /etc/hosts.allow or .deny anywhere.
[04:47] <toddobryan> It's right above the first code block on that page.
[04:52] <lifeless> toddobryan: I'm not sure what you are talking about, but FWIW look for -lwrap in the buildlog - and its there
[04:52] <lifeless> cc -Wall  -DHOSTS_ACCESS -DCHECK_PORT  -DFACILITY=LOG_DAEMON  -DIGNORE_SIGCHLD	 -DIGNORE_SIGPIPE    -O2  -o portmap portmap.o pmap_check.o from_local.o  -lwrap -lnsl
[04:52] <lifeless> etc
[04:55] <toddobryan> lifeless: but portmap doesn't appear to pay any attention to hosts.allow and hosts.deny; it just ignores them
[04:56] <lifeless> I dont know enough about that to help you.
[04:56] <lifeless> I was asnwering your question, which was 'was it built with it'
[04:57] <toddobryan> It looks like -lwrap was a recent change to the build file. I'm wondering if it actually did what it was supposed to.
[04:57] <toddobryan> Where should I take this to find out/report it?
[04:58] <lifeless> file a bug?
[04:59] <toddobryan> OK. I'm just not sure that it is one. :-/
[04:59] <lifeless> have you used it before ?
[05:00] <toddobryan> No. I'm using it for the first time, and, like I said, going through NFS's HowTo.
[05:00] <lifeless> is this a regression you are observing, or are you doing a new setup
[05:00] <toddobryan> new setup.
[05:00] <lifeless> ok, then #ubuntu or a support request are the right places to ask
[05:00] <toddobryan> OK. Somebody posted something about it on the forums, but nothing came of it.
[05:01] <Hobbsee> how odd.
[05:01] <Hobbsee> toddobryan: the developers dont read the forums, FYI
[05:01] <toddobryan> Thanks a lot. I'm going to try rebuilding, removing the -lwrap line and using the commented out line it replaced, just to see what happens.
[05:01] <toddobryan> Thanks, though.
[05:01] <lifeless> ok. if that fixes things, please do file a bug saying so, and how to reproduce
[05:01] <toddobryan> Will do.
[05:19] <bddebian> Are there any archive admins awake?
[06:39] <jdub> so i suppose it's about time to start upgrading servers to edgy
[06:39] <jdub> for great justice
[06:40] <crimsun> I wouldn't
[06:41] <crimsun> there's some nasty python2.4-minimal interaction (from Debian's python2.4 2.4.3-7) that hasn't been fixed yet
[06:41] <jdub> crimsun: lazy tester!!!111
[08:56] <Keybuk> damn those habits
[10:29] <iwj> Burgundavia: Upload on the way, thanks for the report.
[10:34] <dholbach> TheMuso: it'd be nice if you could forward your bug reports to upstream also and link it from launchpad
[10:59] <Seveas> Kamion, is there a specific reason that there is no stock reply for duplicates of bug 48524 on DebuggingUbiquity, or can I add one?
[10:59] <Ubugtu> Malone bug 48524 in ubiquity "crash when hw-detect/modprobe_error is asked" [Medium,Fix released]  http://launchpad.net/bugs/48524
[11:12] <infinity> pitti: Is python-apport-utils headed to main?
[11:15] <jdub> looks like it's time to upgrade my home server to edgy
[11:15] <jdub> let's see what breaks!
[11:16] <simira> jdub: nothing, of course. Edgy works just perfect! (almost)
[11:16] <jdub> perfect like communism!
[11:19] <jono> he
[11:19] <jono> hey
[11:20] <dholbach> hellas jono, hellas jdub!
[11:20] <\sh> moins
[11:20] <jono> hey dholbach :)
[11:20] <Kamion> Seveas: I'd prefer you didn't just directly add one for 48524, but feel free to mail me suggested text; it would be useful
[11:21] <glatzor> lifeless: hi. I created a new bzr branch (using bzr 0.9) and pushed the repository via rpush. But if you want to branch my repo you will get the following error: "ERROR: No repository present"
[11:24] <Kamion> Seveas: (I like to be quite careful about DebuggingUbiquity, since it gets cut and pasted into lots of bugs
[11:24] <Kamion> )
[11:25] <Seveas> Kamion, that's hy I asked ;)
[11:25] <Kamion> infinity: will dapper-backports get built usefully at the moment? If not, can you set that up?
[11:26] <infinity> Kamion: It won't, but I can certainly make it do so, yes.
[11:26] <infinity> Kamion: Does this mean you guys have sprinted on the ftp-master tools to cobble it together?
[11:27] <infinity> Kamion: You'll need to give me a quick run-through to let me know how to make them go.
[11:27] <infinity> Kamion: And, please push at least one backport through to ACCEPTED, so I can test the buildd infrastructure when I get it going.
[11:30] <Kamion> infinity: yes, I got Mark and Scott to help me write the necessary LP code
[11:31] <Kamion> lp_archive@drescher:~/backports$ ~cjwatson/backport-source.py -b jdong -s dapper libtheora
[11:31] <Kamion>   - <libtheora_0.0.0.alpha7-1ubuntu1.dsc: downloading from librarian>
[11:31] <Kamion>   - <libtheora_0.0.0.alpha7-1ubuntu1.diff.gz: downloading from librarian>
[11:31] <Kamion>   - <libtheora_0.0.0.alpha7.orig.tar.gz: downloading from librarian>
[11:31] <Kamion> I: Extracting libtheora_0.0.0.alpha7-1ubuntu1.dsc ...  done.
[11:31] <Kamion> then dump into sync queue
[11:31] <Kamion> I: Building backport of libtheora-0.0.0.alpha7 ...  done.
[11:31] <Kamion> script will move to a more sensible place of coursse
[11:31] <Kamion> -s
[11:32] <Kamion> default backport-from suite is current development branch
[11:33] <infinity> Kamion: Kay, and I assume there's a switch to pick a different one?
[11:33] <Kamion> yeah, -S
[11:33] <Kamion> haven't quite sorted out sync-queue/process-incoming.sh - I think there's some issue regarding pockets there
[11:33] <infinity> Kamion: And is it smart enough to go devel->devel-- if you don't supply either of -{s,S}?
[11:33] <Kamion> since it needs to drop the sync into -backports
[11:34] <Kamion> infinity: not at the moment unfortunately - couldn't immediately see how to get the distrorelease ordering out of lp
[11:34] <mvo> infinity: could you please trigger a rebuild for eel2 on powerpc? it blocks the new nautilus on ppc
[11:34] <infinity> Kamion: process-incoming is smart enough to read .changes files, just stop providing a hardcoded dist in your shell script.
[11:34] <Kamion> oh, really? cool.
[11:34] <infinity> Kamion: The only reason the builddmaster hardcodes the dist is because of the brain-dead --dist=autobuild thing on the buildds.
[11:34] <Kamion> I'll check that out, thanks
[11:35] <infinity> Kamion: And I suspect that code was stolen from the builddmaster, hence the hardcoding.
[11:35] <infinity> mvo: Yeah, there area couple of GNOME snags on PPC/sparc.  I'm looking at them all right now.
[11:36] <mvo> infinity: thanks!
[11:37] <infinity> mvo: Thanks for the heads-up anyway.  People sometimes expect me to be all-knowing, and I embarassingly miss stuff like this for days when I'm not paying attention. :)
[11:39] <dholbach> could somebody please liberate sofia-sip from NEW (it was synced from Debian and was NEW for us)
[11:40] <infinity> dholbach: I'm doing NEW right now, let me look.
[11:40] <dholbach> infinity: thanks a lot.
[11:40] <infinity> dholbach: universe, I assume?
[11:41] <dholbach> yes
[11:41] <infinity> dholbach: And it's just a sync from Debian?
[11:41] <dholbach> yes
[11:42] <infinity> That's a susprisingly comprehensive debian/copyright.
[11:43] <infinity> star, too.
[11:44] <jdub> dholbach: woo
[11:44] <infinity> dholbach: Accepted.
[11:44] <dholbach> infinity: you rock
[11:45] <Kamion> infinity: process-incoming> yep, looks plausible
[11:45] <infinity> Kamion: I should hope so, otherwise our upload queues would never work right. :P
[11:49] <Kamion> infinity: exactly :)
[11:50] <LarstiQ> Equivalent code is available from RSA Data Security, Inc.  This code has
[11:50] <LarstiQ> been tested against that, and is equivalent, except that you don't need
[11:50] <LarstiQ> to include two pages of legalese with every copy.
[11:50] <LarstiQ> woops
[11:50] <LarstiQ> infinity: a gold star indeed :)
[11:50] <Kamion> infinity: ok, there's one in accepted now
[11:50] <infinity> Kamion: Spiff.  I'm building the chroots right now.
[11:51] <Kamion> cool, and it goes straight through to accepted, not unapproved, even
[11:51] <dholbach> infinity: i'm looking at the url-selection stuff in gnome-terminal (vte) now
[11:51] <infinity> dholbach: Ahh, so you've seen the bug, then?  I don't need to give you obscure instructions and screen shots?
[11:52] <dholbach> infinity: http://bugzilla.gnome.org/show_bug.cgi?id=352439
[11:52] <Ubugtu> Gnome bug 352439 in VteTerminal "URL highlighting seriously broken" [Major,New]
[11:52] <infinity> dholbach: (the underlining being nowhere near the actual URL, the mouse-sensitivity being in the wrong spot, etc)
[11:52] <dholbach> infinity: i have a "test case" now :)
[11:53] <infinity> dholbach: Ahh, cool.  Thanks for tracking it.  You're my almost-as-cool-as-mvo hero.
[11:53] <sivang> morning
[11:53] <Hobbsee> hey sivang
[11:54] <infinity> Hobbsee: It's telling you that you upload too much.
[11:54] <sivang> pitti: going to test the fix now :)
[11:54] <Hobbsee> infinity: hehe, yeah, i think so....
[11:54] <StevenK> ln -s edgy-changes hobbsee-changes
[11:54] <sivang> hey infinity , 'sup ?
[11:55] <Hobbsee> StevenK: hah.
[12:01] <elmo> why do we put deb-src lines in apt configs by default?
[12:01] <infinity> elmo: To make RMS happy, and to make users download too much crap?
[12:02] <infinity> elmo: I actually got into a flamewar with rms over him insisting that a default sources.list with no deb-src lines was not "providing equivalent access to source".
[12:02] <dholbach> to make  apt-cache showsrc  and  apt-get build-dep  work and to make it easier for us to give instructions to build packages with debug symbols on bug reports :)
[12:02] <elmo> ehm, seriously
[12:02] <infinity> elmo: I gave up when the blood from my forehead appeared to be irreversibly staining my wall.
[12:04] <elmo> oh well, ok
[12:04] <infinity> elmo: He was arguing that without deb-src lines, users would never know that the sources were on the FTP site, and we'd need to do the written promise thing to make up for it.  This was years ago on some Debian list or other.
[12:05] <infinity> elmo: It all seemed a bit sketchy to me, but Sources.gz is significantly smaller than Packages.gz, so I gave up the fight.
[12:05] <elmo> infinity: it's things like this that make me fear the "or later at your option" clause :(
[12:05] <elmo> infinity: it's smaller, but it basically doubles the amount of http connects all our users are doing
[12:05] <elmo> and 99% of them aren't going to ever be using the info returned
[12:05] <elmo> which is a bit frustrating, but oh well
[12:07] <mdz> BenC: bug 56591
[12:07] <Ubugtu> Malone bug 56591 in linux-source-2.6.17 "Can't resume from hibernation" [High,In progress]  http://launchpad.net/bugs/56591
[12:08] <dholbach> infinity: vte 0.13.6-0ubuntu2
[12:10] <BenC> mdz: thanks
[12:10] <Keybuk> elmo: why?  it's "at your option"
[12:10] <Keybuk> you can always just distribute it under the GPL-2 again
[12:10] <Keybuk> (unless some interim developer has added GPL-3 code to it)
[12:10] <infinity> Keybuk: Until an upstream switching to v3, and all the new code is under the new license.
[12:11] <infinity> s/switching/switches/
[12:11] <Keybuk> infinity: assuming upstream own the copyright to all their source
[12:11] <Keybuk> so send a GPL-2 only patch to your upstream today <g>
[12:13] <jdub> Keybuk: triple-headed hydra :(
[12:13] <Keybuk> actually, it just needs to be a "GPL-2 or at your option" patch
[12:13] <Keybuk> they can't revoke your permission for other people to have an option for that bit of code
[12:13] <Keybuk> obviously, they can remove it
[12:16] <infinity> dholbach: *hug*
[12:16] <geser> Keybuk: hello
[12:16] <geser> is it possible to sync a package from debian which source name has changed?
[12:17] <infinity> Keybuk: Yeah, it's not about "that bit of the code", it's about "new bits of the code".  Unless v3 ends up being declared incompatible with v2, and you can't mix-and-match them in the same codebase, which would be entertaining.
[12:17] <geser> rhythmbox-applet is now called music-applet
[12:18] <infinity> Keybuk: Cause if they are declared incompatble licesnse, then adding any v3 code to a "v2 or later" project would force you to relicense the whole thing as v3 (or drop the new code).
[12:19] <Kamion> infinity: v2-only and v3-only are incompatible both ways
[12:21] <sivang> pitti: cool, my code works again, gazil thanks
[12:22] <pitti> sivang: \o/
[12:22] <Keybuk> http://www.netsplit.com/bzr/libnih/
[12:23] <Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk
[12:23] <Keybuk> uh. sorry
[12:23] <Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/main
[12:25] <simira> mvo: do you need me to break u-m anything more today, ir can I finish my upgrades?
[12:25] <simira> ir/or
[12:25] <mvo> simira: finishing your upgrade should be fine, thanks :)
[12:25] <infinity> Kamion: Sure, but you could relicense a "v2 or later" as v3-only or v2-only.
[12:25] <simira> mvo: thanks
[12:26] <Kamion> infinity: right
[12:26] <Kamion> well, sort of
[12:27] <Kamion> if you were adding something copyrightable to it, you could make that addition v3-only or v2-only, and then the only way to distribute the combination would be under the terms of v3 or v2 respectively
[12:27] <Kamion> you couldn't actually change the licence of the other code
[12:27] <infinity> Kamion: Well, yes.  I meant "relicense the bundle", as it were, not the original code.
[12:28] <infinity> Kamion: But with enough new code that people don't want to discard, they end up amounting to the same thing.
[12:28] <Kamion> nod
[12:29] <Kamion> woo, backports backlog cleared, pending builds
[12:30] <Kamion> and one that I queried
[12:30] <Hobbsee> cool!  backports!
[12:30] <Hobbsee> thanks Kamion!
[12:33] <sivang> Keybuk: what does upstrat do?
[12:35] <geser> IIRC is upstart an event-driven init system
[01:06] <grendel_> afternoon folks
[01:11] <infinity> Seriously, when an hppa box that lamont rescued from a dumpster can outperform you, there's something wrong guys.
[01:11] <grendel_> is anybody involved with ubuntu's openldap around?
[01:11] <infinity> grendel_: Define "involved".
[01:11] <grendel_> well, in the know, perhaps
[01:11] <infinity> grendel_: I tend to do most of the Ubuntu work on it, but we don't modify it much from Debian.
[01:12] <infinity> (if at all, these days)
[01:12] <grendel_> hmm, does it work for you under edgy?
[01:12] <grendel_> I can't get the edgy version to start, just compiled the debian/sid version, it starts but doesn't authenticate
[01:12] <grendel_> the same was with the edgy's version a few weeks back
[01:12] <grendel_> all after a standard install, no tweaking
[01:13] <infinity> grendel_: Have you filed a bug about it?  I don't run it on my laptop, and I've not played with the edgy build for a while.
[01:13] <grendel_> even putting rootdn and rootpw in slapd.conf doesn't help
[01:13] <infinity> grendel_: If you file a bug, I'll be sure to hit it with a stick and sort it.
[01:13] <grendel_> infinity: no bug filed yet, I want to learn whether it's just me first
[01:13] <infinity> grendel_: Well, I can do a quick install and see if it breaks here too.
[01:13] <grendel_> infinity: it seems strange that nobody else has seen it, that's why I'm suspecting it might be my system
[01:13] <grendel_> infinity: that'd be cool
[01:14] <grendel_> infinity: anonymous bind works, authenticating as defined admin (-x -W -D "cn=admin,dc=domain,dc=org") doesn't work
[01:14] <infinity> (base)adconrad@cthulhu:~$ ps ax | grep slapd
[01:14] <infinity> 11725 ?        Ssl    0:00 /usr/sbin/slapd
[01:14] <grendel_> giving error 49, bad credentials
[01:14] <infinity> Oh, it starts, but doesn't auth?
[01:14] <grendel_> yeah
[01:14] <infinity> Using what client(s)?
[01:14] <grendel_> ldapsearch from ldap-utils
[01:15] <grendel_> and I used lat too
[01:15] <grendel_> no candy there either
[01:15] <grendel_> what was the url of the ubuntu's pastebin?
[01:16] <infinity> We don't have one... ubuntulinux.nl does, though.
[01:17] <grendel_> k, sec then
[01:17] <infinity> As does this one, evidently: http://paste.ubuntu-nl.org/
[01:17] <infinity> Oh, same one, differnet domain. :)
[01:17] <infinity> Google is so cruel to me.
[01:17] <grendel_> just found the above :)
[01:18] <grendel_> http://paste.ubuntu-nl.org/21533
[01:18] <grendel_> using -d10 shows the hex dump of the packets, the password is sent correctly
[01:18] <grendel_> no sasl is uses afaict
[01:18] <grendel_> s/uses/used/
[01:19] <grendel_> I'm going to recompile slapd with gcc 4.0, maybe it's the stack protector that gets in the way
[01:20] <infinity> grendel_: It authenticates fine for me here.
[01:20] <infinity> grendel_: So I don't think it's the build.
[01:21] <grendel_> damn
[01:21] <grendel_> I'm running it on a freshly installed system
[01:21] <grendel_> and it breaks...
[01:21] <grendel_> ok, maybe it's some stupidity on my part
[01:21] <grendel_> what command line are you using?
[01:21] <infinity> Identical to yours, save the domain (sine I picked a "foo.org")
[01:21] <infinity> s/sine/since/
[01:22] <grendel_> I have no idea what gives then
[01:22] <grendel_> infinity: did you give foo.org as your organization name?
[01:22] <grendel_> AND the domain name?
[01:22] <imbrandon> moins all
[01:22] <infinity> Yeah.
[01:22] <grendel_> man, I'm baffled
[01:23] <grendel_> there's one possibility though.... :)
[01:24] <infinity> grendel_: If I mess up the cn or the password, I get what you get, obviously, but here's hoping that's not your problem. ;)
[01:24] <grendel_> no, it's definitely not :)
[01:24] <grendel_> unless the password I use gets misencrypted somehow
[01:25] <infinity> Are you using ldapsearch from edgy as well?  (ie: on the same machine)?
[01:25] <grendel_> infinity: I supected that too, so I ran ldapsearch with -d10 to see whether the password was fine :)
[01:25] <grendel_> infinity: yes, the same machine, the same version
[01:25] <infinity> Oh, obviously the same mahcine, since you didn't specify host in your command line.
[01:26] <infinity> Duh.
[01:26] <grendel_> yeah, puzzling
[01:26] <infinity> Forgive me.  Head cold.  Not smart today.
[01:26] <grendel_> infinity: there's one possibility, I might have some stray libs laying around
[01:26] <grendel_> for my devel stuff
[01:26] <grendel_> I'll check that next
[01:28] <grendel_> nope, it's not that
[01:31] <infinity> grendel_: Well, feel free to file a bug anyway, if you can't figure it out, but I'll have to trace it with you another time.  I have too much on the go right now, and not enough intelligence left to do any of it.
[01:32] <grendel_> infinity: sure thing, thanks man
[01:32] <grendel_> I will sit on it since I need that for work
[01:32] <infinity> You sure you're not suffering from reusing an old DB (from a previous install?) with an old password, or something equally OOPStastic?
[01:33] <grendel_> nope, I'm removing /var/lib/ldap
[01:33] <grendel_> it's a pure database created by postinst
[01:33] <grendel_> tried both hdb and bdb
[01:33] <grendel_> usually putting rootdn/rootpw in slapd.conf used to work
[01:33] <grendel_> but not this time
[01:34] <infinity> Bizarre.
[01:34] <grendel_> yeah
[01:34] <grendel_> I also noticed that some packages depend on old libldap2
[01:34] <grendel_> 2.1.30
[01:34] <grendel_> that shouldn't affect ldap-utils or slapd though
[01:35] <infinity> s/some/all/
[01:35] <infinity> We don't build against the new lib.
[01:35] <grendel_> oh, ok
[01:35] <grendel_> and now de.archive.ubuntu.com goes down :(
[01:35] <grendel_> argh, just not my day
[01:37] <grendel_> infinity: ok, thanks for help, Adam, I'll be splitting now
[01:37] <grendel_> if I can't solve it, I'll file a bug
[01:37] <grendel_> l8r
[01:39] <infinity> pitti: *poke,poke*
[01:48] <dholbach> infinity: he's at lunch
[01:48] <infinity> dholbach: LIES.
[01:48] <infinity> dholbach: He's just avoiding me, isn't he?
[01:49] <dholbach> infinity: you're seeing things
[01:49] <infinity> dholbach: Through my tears?  You bet.  He abandoned me!
[01:50] <infinity> Yeah, I prefer 'em on the front.
[01:51] <Hobbsee> :P
[01:51] <dholbach> infinity: You're over-reacting :)
[01:51] <Hobbsee> seeing as you seem to want them
[01:51] <infinity> dholbach: Yes, I know. :)
[01:51] <Hobbsee> Keybuk: why havent you broken everyone's systems yet?
[01:53] <fabbione> Hobbsee: because we can beat him up to death here
[01:53] <fabbione> he wil wait monday :)
[01:53] <Hobbsee> fabbione: hah!  i'll keep that in mind :)
[01:53] <infinity> Kamion: https://launchpad.net/+builds/+build/238586
[01:53] <Hobbsee> fabbione: maybe you need to beat him so that he doesnt do damage on monday?
[01:54] <Keybuk> fabbione: nobody here will notice because the bandwidth is so bad
[01:54] <infinity> Kamion: We win.
[01:54] <fabbione> Hobbsee: nah... he looks too much like a cuddly teaddy bear
[01:55] <Hobbsee> fabbione: hmmm okay.  i guess i'll have to take your word for it, not being there.
[01:56] <Kamion> infinity: rock on!
[01:58] <Keybuk> I'm not sure I like the "cuddly"
[01:58] <geser> Keybuk: is it possible to sync a package from debian which source name has changed?
[01:58] <Keybuk> geser: yes, of course; mention it in the sync request so the original source can be removed
[01:58] <Kamion> obviously (?) it isn't possible to sync a(Debian) -> b(Ubuntu)
[01:59] <Kamion> has to be a(Debian) -> a(Ubuntu), i.e. once it's synced the package name has to be the same on both sies
[01:59] <Kamion> sides
[02:00] <geser> I ask because the source package rhythmbox-applet got renamed to music-applet in debian
[02:04] <_ion> Yay, cool new stuff in the upstart repo. :-)
[02:11] <pitti> infinity: pong
[02:11] <Keybuk> _ion: ie. all of it? :p
[02:12] <Keybuk> "make"; cp init/bin /sbin; reboot; ... uh-oh
[02:12] <Keybuk> init/init even
[02:12] <Keybuk> (ps. don't do that :p)
[02:12] <Keybuk> (pps. NO, REALLY, DON'T)
[02:12] <_ion> :-D
[02:12] <Hobbsee> haha
[02:12] <_ion> Well, that wouldn't be very difficult to fix. :-)
[02:13] <infinity> pitti: Is python-apport-utils going to be seeded to main, or do you want it in universe?
[02:13] <pitti> seb128: http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ \o/
[02:13] <pitti> infinity: in main definitively
[02:14] <pitti> infinity: I specifically wrote it for usage in ubiquity
[02:14] <pitti> infinity: (it's something we discussed here at the sprint)
[02:14] <infinity> pitti: Ahh, cool.  Accepted, then.
[02:15] <Kamion> I imagine apport depends on it now anyway
[02:15] <pitti> right, it does
[02:16] <infinity> Yeah, I didn't go so far as to check the binaries.  Pinging the uploader is less effortl :P
[02:16] <infinity> s/effortl/effort./
[02:17] <siretart> Kamion: thank you for your great work on the backports script!
[02:18] <Kamion> no problem, sorry it took so long
[02:18] <Kamion> should be exactly as much effort as syncs now
[02:18] <infinity> Well, source NEW anyway.  Some will land in binary NEW later.
[02:18] <Kamion> I'll need to try to persuade the Soyuz team to take the script of course, but later
[02:18] <Kamion> infinity: oh, thanks
[02:19] <siretart> Kamion: do you think the script might be of interest for automated backports for http://backports.org?
[02:19] <infinity> Kamion: Yeah, I think we need an lp_archive alias to do "for i in (all non-devel releases); do q -R $i -Q new info; done"
[02:19] <infinity> Kamion: Cause I only ever think to look once in a blue moon.
[02:20] <Kamion> siretart: there's a lot of launchpad-specific stuff in there
[02:20] <Kamion> siretart: that was the hard bit
[02:20] <Kamion> siretart: the actual worker bit is just unpack, dch, dpkg-source, dpkg-genchanges - pretty trivial
[02:21] <siretart> I see.
[02:21] <infinity> Kamion: Maybe even mailing out new/unapproved status reports for !devel would be handy from time to time.  I dunno.
[02:22] <Kamion> mm
[02:23] <pitti> seb128: current langpacks have evolution-2.6 domain :(
[02:23] <pitti> seb128: so, I'll stick the 2.8 ones in manually
[02:25] <_ion> Hmm, connection to archive.ubuntu.com timeouts. Anyone else experiencing this?
[02:25] <slomo_> _ion: yep
[02:25] <seb128> pitti: thank you
[02:25] <seb128> pitti: do you want to the mo from my build?
[02:30] <Kamion> _ion: without certain knowledge, I think it's very slow due to taking all the load of the xserver-xorg-core update
[02:31] <elmo> I've given it some more bandwidth - that might help
[02:31] <Kamion> _ion: same reason
[02:32] <_ion> To get the update to people faster? Right, that's good.
[02:32] <Kamion> _ion: we needed to stop people going to mirrors and getting the broken X
[02:33] <HiddenWolf> elmo: can't you verify some of the beefy mirrors to see if they got the right version to lighten the load a bit?
[02:33] <_ion> elmo: Thanks, seems to work better now.
[02:33] <elmo> HiddenWolf: no
[03:06] <Hobbsee> gosh.  you guys really do have a shocking connection...
[03:08] <heno> infinity: around?
[03:09] <infinity> heno: Ish.
[03:09] <infinity> heno: 'sup?
[03:09] <heno> infinity: is there anything important blocking gnome-orca being uploaded to main?
[03:10] <infinity> heno: Other than the part where it needs to be modified to work, and I don't think TheMuso did that yet?
[03:10] <heno> infinity: it has gotten a new shiny upstream version since then, 0.9
[03:10] <infinity> Oh, I see.
[03:11] <heno> TheMuso and I are both very happy with it
[03:11] <infinity> And the shiny new upstream no longer tries to dlopen a library incorrectly, and actually functions?
[03:11] <heno> indeed
[03:11] <infinity> If so, then that was the only blocker.  pitti already approved it.
[03:11] <heno> cool!
[03:11] <infinity> At least, I think he did.
[03:11] <TheMuso> It still dlopens, but upstream are not about to change it
[03:12] <infinity> TheMuso: Err, kay, but it dlopens the correct file now? :)
[03:12] <heno> pitti approved it yes
[03:12] <TheMuso> infinity: Yes, that has been done.
[03:12] <infinity> TheMuso: Kay, that's all I needed.
[03:12] <infinity> heno: Then the only thing left is for someone to update the seeds to land it wherever it's meant to belong, and we can promote it.
[03:13] <heno> infinity: right, it should go in desktop and gnopernicus should be moved from desktop to supported
[03:14] <heno> Kamion: ^ is that something you can do?
[03:14] <infinity> heno: If you don't want to do that yourself, find a patsy who isn't heading to bed soon to do it for you. :)
[03:14] <infinity> Oh, didn't realise.
[03:15] <Hobbsee> heno: all the more reason to keep it out of main, surely?
[03:15] <infinity> Yes, Kamion (and pretty much any of us) can do it.
[03:15] <Keybuk> so, what should the config directory be?
[03:15] <Keybuk> it's /etc/rc.d at the moment ... should we use something else?
[03:16] <heno> dholbach__: around? could you perform the seed change above?
[03:16] <heno> Keybuk: are you talking about Orca?
[03:16] <infinity> Keybuk: /etc/whend, of course.
[03:16] <TheMuso> heno: no he isn't.
[03:16] <heno> ok :)
[03:16] <infinity> Keybuk: That name needs to live on SOMEWHERE. :)
[03:16] <Keybuk> infinity: it hasn't been called that for ages
[03:17] <infinity> Keybuk: Even if it's just a "see also: whend(8)" in the manpage. :)
[03:25] <jdub> edgy server upgrade going well so far
[03:26] <jsgotangco> ohhh brave one
[03:26] <Lathiat> haha im still afraid to upgrade one of my major production servers to dapper
[03:26] <Lathiat> but i need to at some point
[03:26] <Lathiat> the i can coast on LTS till i can be bothered to upgrade it again
[03:26] <Lathiat> (runs breezy atm)
[03:26] <thom> you were really going to call it whend? (why am i surprised, actually?)
[03:27] <jdub> i will probably leave my Linode server on dapper
[03:27] <jdub> i don't run X on it, so... ;-)
[03:27] <jdub> whend is a rad name
[03:28] <Lathiat> 7              w qwe qwe
[03:28] <jdub> uh oh
[03:28] <jdub> Errors were encountered while processing: linux-image-2.6.17-6-686 linux-image-686 linux-restricted-modules-2.6.17-6-686 linux-restricted-modules-686 linux-686
[03:28] <Lathiat> eh hrm excuse me
[03:28] <jdub> E: Sub-process /usr/bin/dpkg returned an error code (1)
[03:28] <jdub>
[03:28] <jdub> hmm, that might be a /boot full issue
[03:29] <Lathiat> heh i started making my /boots a little bigger than i used to
[03:29] <Lathiat> i used to make them 64-128 but i started doing 256 for that reason
[03:31] <dholbach__> heno: which change?
[03:32] <heno> dholbach__: adding gnome-orca to the desktop seed
[03:32] <dholbach__> heno: and drop gnopernicus?
[03:32] <heno> dholbach__: and then moving gnopernicus to supported, yes
[03:32] <dholbach__> heno: ok
[03:33] <heno> I guess dropping it from main is a discussion for later
[03:33] <heno> dholbach__: thanks!
[03:33] <heno> Lot's of eager testers will be very glad!
[03:33] <dholbach__> it will take a while
[03:34] <heno> ok, np
[03:36] <dholbach__> heno: it went through main inclusion queue?
[03:39] <infinity> dholbach__: I'll move it to main right now, if you're doing the seeds.
[03:39] <dholbach__> heno:  I mean gnome-orca. Was it reviewed?
[03:40] <infinity> dholbach__: Once it's moved (next publisher run), you should be okay to update a new -meta, if you like.
[03:40] <elmo> "83 days"?    Should be promoted fully and published in about 60 mins.
[03:46] <infinity> dholbach__: In theory, the next germinate rnu after that should provide you with output that makes -meta DTRT.
[03:53] <jdub> ahr!
[03:53] <jdub> so on my md/raid1 machine
[03:53] <Lathiat> booting with UUID= broke?
[03:53] <jdub> the root uuid migration bits didn't work
[03:54] <Lathiat> still, hrm
[03:54] <infinity> I'm so shocker, I nearly hurt myself with my lack of reaction.
[03:54] <infinity> s/shocker/shocked/
[03:55] <Keybuk> jdub: fabbione is over there
[03:55] <fabbione> no i am not
[03:55] <Keybuk> he promised me this week that things like that "would just work"
[03:55] <fabbione> i said LVM
[03:55] <Keybuk> if they don't, he LIED to me, and I am hurt
[03:56] <fabbione> jdub: do you have / on raid or lvm?
[03:56] <Keybuk> I asked about all fabbione filesystems
[03:56] <jdub> fabbione: boring old md raid1
[03:56] <jdub> hrm, and /tmp wasn't o+t for some reason
[03:57] <fabbione> jdub: can you check /proc/mdstats and/or cat /proc/partitions
[03:57] <fabbione> Keybuk: i think we forgot to talk about raid actually.. we did talk only about LVM/EVMS/devmapper
[03:57] <Keybuk> I assumed we had
[03:58] <fabbione> iirc the last time we did talk about raid was here on IRC
[03:58] <jdub> fabbione: what am i looking for (all looks normal)?
[03:58] <Keybuk> when we leave the subject of an ordinary block device with an ordinary filesystem on it, to me, it's a bit like listening to german
[03:58] <Keybuk> blah blahkdj ksdjfdks fjskfjk dsf kdsfsdj filesystem lsdjfsdfkdjfk sdfkjsdfj sdfjsf block device dfsf sdfsf dfsdf kernel panic
[03:58] <fabbione> jdub: you are looking at your /dev/hdaX changed into /dev/sdaX something MORE OR LESS
[03:59] <Keybuk> fabbione: there's no reason it should have done that, unless he has one of the odd kernel drivers
[03:59] <fabbione> jdub: and then we try to start the raid manualy
[03:59] <fabbione> Keybuk: if that's the case.... it's hw bug
[03:59] <jdub> fabbione: ah right, no, using sd[ab]  still (as i've been using sata_sil)
[03:59] <fabbione> is the module loaded?
[03:59] <fabbione> are the disks there?
[04:00] <fabbione> mdrun -a
[04:00] <fabbione> to try to restart the raid?
[04:00] <fabbione> or gimme a serial console to that crap and i will fix it
[04:00] <jdub> the UUID in menu.lst is the same as /dev/md1 (which is /)
[04:00] <Keybuk> /sbin/vol_id /dev/md1
[04:01] <jdub> fabbione: as far as reporting goes, i'm told that the two raid devices are up and running before it sits there 'waiting for root filesystem'
[04:01] <infinity> Could just be an event ordeing issue, since /dev/md1 isn't anyhting useful until after mdrun happens.
[04:01] <jdub> Keybuk: looks all ok here
[04:02] <Keybuk> jdub: you have a /dev/disk/by-uuid that matches the UUID and is a symlink to /dev/md1 ?
[04:02] <fabbione> infinity: raid run before initramf attempts to mount /
[04:02] <jdub> Keybuk: yeah
[04:02] <fabbione> otherwise none of my retarded installs would boot
[04:02] <Keybuk> jdub: *shrug* then what's it looping and looking for? :p
[04:02] <jdub> Keybuk: (note that this is after i've booted with root=/dev/md1)
[04:02] <infinity> fabbione: Yeah, I was thinking more the above (/dev/disk/etc..), but that appears to be fine.
[04:03] <Keybuk> jdub: could you boot it with break=mount on the kernel command line and check that
[04:03] <infinity> jdub: Some of this debugging in the busted initramfs would be helpful.
[04:03] <jdub> Keybuk: righto
[04:03] <Keybuk> it could be that mdrun doesn't create /dev/md1 until after udev has run AND doesn't cause the kernel to send a uevent
[04:03] <Keybuk> therefore you won't have the /dev/disk/by-uuid for it
[04:04] <infinity> That sounds plausible.  What would be the fix?
[04:04] <Keybuk> making md not suck and play nice with the modern kernel? :p
[04:04] <infinity> Keybuk: Is there a way to prod udev from the md script to walk devices for UUIDs again?
[04:04] <infinity> Keybuk: Well, yeah, or fix the kernel driver.  But I meant "is there aplausible user-space solution?"
[04:04] <Keybuk> echo -n add > /sys/block/md1/uevent
[04:04] <infinity> Right.  That seems easy enough.  Ish.
[04:06] <Keybuk> though it'd be odd for that to exist, and udev not to have noticed
[04:07] <fabbione> it's udev bug
[04:07] <fabbione> :)
[04:07] <Keybuk> it could be possible that when /dev/md1 is created, it doesn't have a valid filesystem on it
[04:07] <Keybuk> so vol_id fails to find a uuid
[04:07] <Keybuk> which would explain why the symlink was missing
[04:08] <Keybuk> in which case it's md's responsibility to send the uevent again
[04:08] <Keybuk> which we can hack with that echo again
[04:15] <windub> ahr
[04:15] <windub> okay
[04:15] <windub> so /dev/disks/by-uuid doesn't contain the / uuid
[04:15] <windub> running mdrun -a results in:
[04:15] <windub> cat: /proc/mdstat: No such file or directory
[04:16] <windub> then four lines of mdadm spew
[04:16] <StevenK> Is the raid module loaded at all?
[04:16] <windub> nup
[04:18] <windub> Keybuk, fabbione: anything further i can do for you?
[04:18] <Keybuk> windub: what happens if you run  echo -n add > /sys/block/md1/uevent
[04:18] <windub> cannot create ... directory nonexistent
[04:19] <Keybuk> err ... find /sys -name md1
[04:19] <fabbione> if there is no mdstat, mostlikely none of the raid modules have even been loaded
[04:19] <windub> Keybuk: not found. lack of raid / mdstat would impact that, surely?
[04:20] <fabbione> windub: try to modprobe raid1
[04:20] <fabbione> and check in cat /proc/modules if it is even loaded
[04:20] <fabbione> that should create mdstat
[04:21] <fabbione> next cat /proc/.partitions and make sure the disks have been found
[04:21] <fabbione> next mdrun -a
[04:21] <fabbione> check mdstat again to see if the raids are there
[04:21] <fabbione> next check UUID
[04:21] <windub> raid1 loaded, disks have been found
[04:21] <Keybuk> did loading that module cause /dev/disk/by-uuid to appaer
[04:22] <windub> hrm
[04:22] <windub> loading raid1 didn't, no
[04:22] <windub> and mdrun -a doesn't have that error, but still spews:
[04:23] <windub> mdadm: --auto=yes requires a 'standard' md device name, not /dev/md?
[04:23] <windub> four times
[04:23] <windub> but there's nothing listed in mdstat yet
[04:24] <Kamion> /dev/md1 should count as "standard"
[04:24] <Kamion> (it's not mdadm's default - that's /dev/md/1 - but is_standard() in mdadm should return true for it)
[04:26] <Kamion> yes
[04:26] <Kamion> ./mdopen.c:                     fprintf(stderr, Name ": --auto=yes requires a 'standard' md device name, not %s\n", dev);
[04:27] <windub> Keybuk, fabbione: anything else i can do? i can test stuff again later, but kinda need to get this back up for the moment
[04:28] <fabbione> windub: no sorry.. no idea without having console
[04:28] <Keybuk> windub: at this point, it just sounds like a raid problem to me
[04:28] <Keybuk> of all the things to make difficult for yourself, you pick your root filesystem <g>
[04:29] <windub> i make /boot easy so / can be whatever
[04:30] <fabbione> it might be that mdrun in initramfs does some extra checks like root=/
[04:30] <fabbione> and UUID just confuses the script
[04:30] <fabbione> i can't really see any other reason why root=/dev/md1 would work otherwise
[04:33] <simira> mvo: it only failed to open once now, with http://pastebin.com/774845
[04:34] <mvo> simira: run as user or as root?
[04:34] <mvo> looks like user :)
[04:35] <simira> mvo: opened from systray, but I gave up password the first time (when it failed)
[04:39] <simira> mvo: but yes, I was asked for password trying to install
[04:39] <AnAnt> can anyone help me in packaging a library ?
[04:40] <simira> try ubuntu-motu or something?
[04:40] <desrt> AnAnt; did you read the debian new maintainer guide?
[04:41] <AnAnt> simira: tried there
[04:41] <AnAnt> desrt: not sure if I read that
[04:41] <desrt> AnAnt; it's mostly focused on packaging binary programs but would definitely help you
[04:41] <desrt> http://www.debian.org/doc/maint-guide/
[04:42] <AnAnt> I did package binary programs before
[04:42] <AnAnt> my problem is with a library
[04:42] <AnAnt> it does not install properly
[04:42] <desrt> afaik, dealing with libraries is a matter of adding some extra dh_ rule to make sure a rule to run ldconfig gets written into the postinst script
[04:43] <AnAnt> well, that's not the problem I've got
[04:44] <desrt> what's the problem though?  it never hurts to just ask things (although you would really be much better to "just ask" in #-motu)
[04:44] <AnAnt> well, I neither get headers in the fsplib-dev, nor do I get the libs installed in the fsplib0 packages
[04:44] <AnAnt> dunno why
[04:44] <AnAnt> I asked in motu
[04:45] <desrt> oh.  so it's a problem with multiple target .deb's?
[04:46] <desrt> k.  for each target deb you need to make sure a directory exists in debian/ at the end of the build with all the files you want to land in that .deb
[04:46] <desrt> so if you have a libfoo-dev package you need files in debian/libfoo-dev/usr/include/....
[04:46] <AnAnt> how ?
[04:46] <desrt> you need to have rules to make sure that happens
[04:47] <AnAnt> yes, that's what I dunno
[04:47] <AnAnt> how can I install headers ONLY in the libfoo-dev
[04:47] <desrt> well, you can either do it yourself or figure out how cdbs or whatever does it for you
[04:47] <AnAnt> and libs only in libfoo0
[04:47] <desrt> or look at another package
[04:47] <desrt> that's really the best way... find a small library and look at it
[04:47] <AnAnt> k
[04:47] <desrt> best of luck
[04:48] <moe_evil> hi
[04:49] <moe_evil> anyone con helpme with partman?
[04:49] <moe_evil>  I'm trying to use an existing partition. I create the files necesaries in the dev dir, but doesn't work
[04:51] <simira> moe_evil: please read topic and have a try on #ubuntu
[04:51] <AnAnt> what is the smallest library (in size) in Ubuntu ?
[04:51] <Spads> ls -lt /usr/lib
[04:52] <Keybuk> -lS
[04:52] <Spads> er yes
[04:52] <Spads> sorry
[04:52] <Spads> t is mtime
[04:52] <Keybuk> and that'll just tell you lots of symlinks
[04:52] <Keybuk> zsh -c "ls -lS /usr/lib/*(.)"
[04:52] <Keybuk> in fact
[04:52] <Keybuk> zsh -c "ls -lS /usr/lib/*.so.*(.)"
[04:53] <Spads> ls -lS /usr/lib | grep -v -- '->'
[04:53] <Spads> hmm, many of those tiny ones are linker scripts on my box
[04:54] <Keybuk> most
[04:55] <AnAnt> k, thanks
[04:55] <bddebian> Morning folks
[05:08] <moe_evil> sorry :)
[05:19] <bddebian> Keybuk: I know you are busy and sorry to bother you but do you think you will get a chance to hit sync requests any time soon?
[05:19] <Keybuk> nope
[05:19] <Keybuk> however we'll be instigating some new procedures next week
[05:20] <bddebian> Nice
[05:21] <Keybuk> the distro team are all in Wiesbaden this week, so normal operation is...delayed ;)
[05:21] <Keybuk> unless there's a critical bug or two you need syncing?
[05:22] <bddebian> No no, just trying to keep up
[05:23] <bddebian> Some days I'm not even sure why I bother. :-(
[05:23] <Keybuk> because you love it
[05:23] <Keybuk> it thrills you to your free software loving core!
[05:23] <Keybuk> oh dear, I appear to be channelling jdub
[05:23] <bddebian> Hah
[05:24] <bddebian> I do love it but I feel more like a nuisance than a help most of the time
[05:24] <bddebian> :-)
[05:24] <Hobbsee> bddebian: you're far from a nuisance, dont worry :)
[05:25] <Hobbsee> bddebian: dont you try to steal my title :P
[05:25] <bddebian> Hobbsee: Not a chance, I just try to steal your karma ;-P
[05:25] <Hobbsee> bddebian: hah
[05:25] <Hobbsee> bddebian: as long as you dont go trying to steal my title of bitchy pscyopath, you'll be okay.
[05:32] <bddebian> Hobbsee: :-)
[05:40] <zyga> hello
[05:42] <bddebian> Hello zyga
[05:45] <pitti> yay fresh edgy language packs!
[05:46] <pitti> please feel invited to deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./  and give feedback
[05:47] <Keybuk> pitti: I installed my language pack and all the text was still in English
[05:47] <Keybuk> admittedly *better* English ...
[05:47] <Keybuk> except for "Wastebasket"
[05:47] <Keybuk> one day I'm going to go rename that to "Rubbish Bin"
[05:47] <Keybuk> in fact, I shall do that now
[05:48] <Kamion> "Round Filing Cabinet"
[05:48] <bddebian> hehe
[05:48] <bddebian> That's "Circular File"
[05:48] <Hobbsee> hehe
[05:48] <Hobbsee> so then i could say...
[05:48] <Kamion> not in en_GB :)
[05:51] <zyga> Keybuk: isn't that a trash applet now?
[05:53] <sbalneav> Who here's at the sprint?    Is that the preferred route or would it be better to get upstream to work on desextras.py?
[06:36] <slomo> seb128: all parts of main except kde stuff work perfect with new dbus, very few need a trivial patch, most are just rebuilds :)
[06:37] <seb128> bddebian: upstream is not going to work on that right so apparently and you can't force them to work on it if they don't want
[06:37] <bddebian> Or better yet, is there something that replaces dsextras
[06:37] <seb128> slomo: rock on!
[06:37] <seb128> bddebian: no idea
[06:37] <seb128> bddebian: maybe open a bug on bugzilla.gnome against pygobject
[06:59] <Riddell> slomo: what's up with kde and new dbus?
[07:00] <slomo> Riddell: nothing, i just didn't test yet whether it works or not :) but i see no reason why it shouldn't
[07:00] <Riddell> slomo: need me to test?
[07:02] <slomo> Riddell: yes, would be nice :) it's k3b, kdegames, kdebase, knetworkmanager that needs to be tested... i'll upload the new stuff for you in some minutes
[07:02] <slomo> or you on x86?
[07:02] <Riddell> slomo: I am
[07:03] <Riddell> slomo: we're about to leave for dinner, /msg me the URL and I'll get it tomorrow morning
[07:03] <slomo> Riddell: ok, will do... thanks :) and have a nice dinner
[07:38] <welshbyte> just reading http://www.ubuntu.com/FixForUpgradeIssue ... shouldn't the first step say ctrl + alt + f1 rather than just alt + f1 ? that might confuse some people
[07:41] <infinity> welshbyte: If X isn't working, Alt-F1 is good enough.  If it is working, you hardly need the instructions, do you?
[07:42] <tepsipakki> how come the /etc/debian_version in dapper is "testing/unstable" ?-)
[07:42] <_ion> tepsipakki: Look at /etc/lsb-release instead. :-)
[07:42] <infinity> tepsipakki: It is in every Ubuntu release.  We rely on lsb_release to give proper info, we have /etc/debian_version just to keep 2rd party scripts and such happu.
[07:43] <infinity> s/2rd/3rd/
[07:43] <infinity> s/happu/happy/ too.  I wish I could sleep and reset my fingers.
[07:43] <welshbyte> oh yeah, so it is *blush*
[07:44] <jsgotangco> LaserJock: ping
[07:45] <LaserJock> jsgotangco: pong
[07:45] <jsgotangco> err ill just pm you in jabber
[07:47] <tepsipakki> _ion,infinity: righto :)
[09:22] <Tuxist> hi
[09:22] <Tuxist> is a kde developer here
[09:22] <LaserJock> Tuxist: try kubuntu-devel maybe
[09:23] <Tuxist> xes
[09:25] <Zdra> thanks to the new crash report system, when I get a simple app crash the system completly freeze for 1seconde or 2...
[09:26] <Zdra> I think that's the time to get the core dump
[09:48] <siretart> BenC: around?
[09:49] <zul> siretart: is there something i can help you with?
[09:49] <siretart> zul: yes, bug #57146
[09:49] <Ubugtu> Malone bug 57146 in wpasupplicant "[prism2.5]  doesn't associate" [Untriaged,Confirmed]  http://launchpad.net/bugs/57146
[09:49] <siretart> zul: I believe this is a regression in the kernel
[09:49] <BenC> siretart: sort of
[09:49] <siretart> zul: do you kernel guys agree to reassign it to linux-source-2.6.17?
[09:50] <zul> gimme a sec
[09:53] <siretart> the other possibility could be that the bug could be in the 0.5 branch of wpasupplicant. But I don't really beleive this, since we have that branch since months in debian unstable/testing, and we got quite a few bugs about that new package, but nobody mentioned problems with hostap and wpasupplicant 0.5
[09:53] <siretart> would be of course quite funny, since wpasupplicant and hostap share the same upstream
[09:54] <zul> yeah you might want to re-assign it to us
[09:54] <siretart> allright
[09:54] <zul> whats one more bug ;)
[09:58] <fdoving> is it intentional that *.archives.ubuntu.com goes to uk.archives?
[09:58] <Nafallo> fdoving: it doesn't.
[09:58] <fdoving> Nafallo: does here.
[09:59] <Nafallo> fdoving: se.archive.ubuntu.com try that :-)
[09:59] <fdoving> se.archive.ubuntu.com has address <IP_ADDRESS>
[09:59] <fdoving> fi.archive.ubuntu.com has address <IP_ADDRESS>
[09:59] <fdoving> and so on.
[09:59] <Nafallo> ehh...
[09:59] <Burgwork> fdoving, yes
[09:59] <Nafallo> what did they do now :-P
[09:59] <Treenaks> yes, see www.ubuntu.com
[09:59] <Burgwork> the creation of teh country specific archives is about ease of later seperation
[10:00] <Treenaks> becaue of the X breakage, afaik
[10:00] <fdoving> Burgwork: ok. just ckecing :)
[10:00] <Treenaks> Burgwork: they used to point to mirrors, but because the X fix hadn't been synced to all mirrors yet, that was disabled, according to the wiki
[10:01] <Burgwork> Treenaks, oh, that too
[10:01] <Burgwork> forgot about that, don't have any dapper boxes
[10:01] <Nafallo> dooh.
[10:01] <Treenaks> Burgwork: no dapper boxes? you're either brave, or still on breezy :)
[10:01] <Burgwork> fdoving, however, there are country specific archives that point to the uk mirror
[10:01] <Burgwork> Treenaks, my server is breezy, desktop and laptop are edgy
[10:02] <Burgwork> not gotten around to upgrading my server yet
[10:02] <Nafallo> all my servers is 6.06.1 and doesn't run X ;-)
[10:02] <Treenaks> Nafallo: same for me :)
[10:02] <Nafallo> all my clients is on edgy :-)
[10:03] <Nafallo> so not problems for me ;-)
[10:03] <fdoving> all my servers downloads updates faster from no/se/fi than from uk. :)
[10:03] <Nafallo> anyway, this is becoming way of topic :-P
[10:04] <ivoks> fdoving: that's normal
[10:05] <fdoving> ivoks: i'm in norway, so yes. :)
[10:14] <ivoks> fdoving: we have a situation in croatia where link to sweden is faster than a link to a neighbour next door :/
[10:15] <fdoving> ivoks: hm.. that's interessting routing. :)
[10:16] <ivoks> fdoving: yup, t-com isn't part of "national network", so routing from other providers goes like this "croatia -> hungary -> slovenia -> italy -> austria -> germany and back" :)
[10:17] <Tuxist> imbrandon: i have been modfiet your packages with libmtp support, helix engine, nfs and smb support
[10:18] <Tuxist> ftp://tuxist.de/edgy/
[10:18] <fdoving> ivoks: as long as you're aware of it it's not a big problem i guess? anyway.. a bit offtopic for this channel :)
[10:20] <Tuxist> nvidia driver 1.0-8774 is out with xorg7.1 support juhu
[10:20] <ivoks> great
[10:25] <pygi> ivoks, you and your t-com :)
[10:25] <pygi> go to medjimurje, use xDSL :)
[10:25] <ivoks> pygi: HSDPA is my rush these days (but we are offtopic)
[10:30] <ivoks> ok, sorry, i know it's offtopic, but it's kind of funny and it makes you think
[10:30] <ivoks> person A: I'm lumberjack
[10:30] <ivoks> person B: I'm carpenter
[10:30] <ivoks> what's in common? Yes, they work with wood, but else?
[10:30] <ivoks> they are both on #ubuntu-devel
[10:44] <lfittl> elmo: ping
[10:51] <tuxi> hi
[10:51] <_ion> Argh.
[11:20] <pygi> sivang, poke?
[11:20] <pygi> oops, forgot, nvm sivang :)


[08:15] <acheronuk> If I wished to change the name of my launchpad ID, I assume changing it would not break any permissions/memberships/subscriptions or website logins that use login.launchpad.net to authenticate?
[08:15] <acheronuk> I know I would need to remove any ppas before changing


[02:46] <sergiusens> slangasek: mind sponsoring/accepting the click's in https://launchpad.net/~sergiusens/+archive/ubuntu/ppa/+packages?field.name_filter=click&field.status_filter=published&field.series_filter= ? or do I need to ask separate people?
[03:10] <Ukikie> Has skype allowed/pushed/whatever an update for -partner?  According to them, the version that's in partner will be incompatible with the network July 1st.
[03:41] <slangasek> sergiusens: I will try to take a look at it.  But why does the 'finalize' log at https://bileto.ubuntu.com/log/2790/finalize/1/ show that the branches were merged before I clicked finalize?
[03:42] <sergiusens> slangasek: I tried to click and got "unautharized" error, maybe it did really trigger them?
[03:45] <slangasek> sergiusens: hmm, well I hope not
[03:51] <sergiusens> slangasek: cannot say much after that, first time I use bileto; I don't have permissions for lp:click nor this part of the command. The merges do say bileto bot
[04:53] <slangasek> sergiusens: indeed.  Could be a bug in bileto, I simply hope that it wasn't
[08:26] -queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.6-0ubuntu<IP_ADDRESS> => 17.0.7-0ubuntu<IP_ADDRESS>] (core, xorg)
[09:01] -queuebot:#ubuntu-release- New source: python-os-traits (artful-proposed/primary) [0.3.1-0ubuntu1]
[09:31] <bluesabre> Hello release team,  is it possible to release thunar (xenial, yakkety, zesty) and xfce4-weather-plugin (xenial) into -proposed? We started the SRU process  a couple weeks ago, but I think these two got missed and never made it to the second step. https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1679488 and https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1688056
[09:56] <apw> bluesabre, hmmmm, can look in a little i suspect
[10:03] -queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (zesty-proposed) [1.6.11-1ubuntu<IP_ADDRESS>]
[10:05] -queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (yakkety-proposed) [1.6.11-0ubuntu<IP_ADDRESS>]
[10:05] -queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (xenial-proposed) [1.6.11-0ubuntu<IP_ADDRESS>]
[10:10] -queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (xenial-proposed) [0.8.9-0ubuntu<IP_ADDRESS>]
[10:33] -queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (zesty-proposed) [17.0.7-0ubuntu<IP_ADDRESS>]
[10:38] -queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.6-0ubuntu<IP_ADDRESS> => 17.0.7-0ubuntu<IP_ADDRESS>] (core, xorg)
[10:47] -queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (yakkety-proposed/universe) [0.8.7-3 => 0.8.9-0ubuntu<IP_ADDRESS>] (ubuntustudio, xubuntu)
[10:51] -queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (yakkety-proposed) [0.8.9-0ubuntu<IP_ADDRESS>]
[11:45] <tjaalton> could someone override glbinding autopkgtest on armhf, it "fails" because current gcc adds some deprecation notifications to the test output. tests itself pass fine
[11:46] <apw> tjaalton, is someone going to sort out the tests for next time ?
[11:47] <tjaalton> as in modifying glbinding pkg?
[11:47] <tjaalton> maybe I should try that first
[11:52] <tjaalton> though I don't know how to best do that
[11:52] <tjaalton> right now it does
[11:52] <tjaalton> cmake .. && make && make test
[11:53] <tjaalton> and it's the output from 'make' that fails the autopkgtest
[11:58] <apw> tjaalton, you do not want to have to read the output for the tests every time for ever going forward to check it is overridable, so we want to do something with it
[11:59] <tjaalton> yes, but what
[12:00] <apw> i guess we have some options, 1) fix the code so it is no longer using the deprecated interfaces, 2) elide the deprecation errors from make component
[12:00] <apw> the first is ideal of course
[12:02] <tjaalton> I just wanted to update mesa, and now have to update glbinding :P
[12:02] <tjaalton> esp. since the debian maintainer isn't too active
[12:02] <tjaalton> this is the initial upload from last year
[12:02] <apw> heh life does suck sometimes
[12:02] <apw> it may of course not build .... la la la
[12:03] <apw> tjaalton, i guess if those are the only errors and you ahve checked them for your mesa we could just ignore them for your upload
[12:04] <apw> so they don't get a free pass forever in this version
[12:05] <tjaalton> there are no errors
[12:05] <tjaalton><EMAIL_ADDRESS>[12:05] <apw> tjaalton, there are failures when re-testing with your mesa update because of the warnings coming out, right ?
[12:05] <tjaalton> it's just the make output that makes it fial
[12:05] <tjaalton> fail
[12:05] <tjaalton> notifications, yes
[12:05] <tjaalton> and it's not because of mesa but something else
[12:06] <tjaalton> that changed in artful
[12:06] <tjaalton> mesa just triggered the autopkgtes
[12:06] <tjaalton> t
[12:06] <apw> tjaalton, so i am saying it would likely be reasonable to say we can ignore the failures for mesa if that is the only regression you have
[12:06] <tjaalton> it is
[12:09] <apw> tjaalton, ok done
[12:09] <tjaalton> thx'
[12:09] -queuebot:#ubuntu-release- Unapproved: libclc (xenial-proposed/universe) [0.2.0+git20150813-2 => 0.2.0+git20170213-1~16.04.1] (no packageset)
[14:27] <jamespage> any archive-admins have a few cycles to review some new packages for OpenStack in the artful NEW queue?
[14:27] <jamespage> specifically: python-deprecation, pypowervm, python-ovsdbapp, python-zunclient and python-os-traits
[15:28] <slashd> morning bdmurray (today's vanguard), I know you are sprinting and I don't want to take a lot of your time, but could you please have a look at theses uploads whenever you have time [1] - https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=lxd [2]- https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=vlan and if you have extra time to "Fix Released" percona-xtradb-cluster-5.5 that would be
[15:28] <slashd> awesome for us.
[15:29] <slashd> ddstreet ^
[15:31] <stgraber> looks like the snapcraft test is busted right now, most likely because of external code it's getting/running which appears to have changed
[15:31] <stgraber> that's blocking the push of a critical bugfix for LXD in artful so I'm going to be pushing a force-badtest for snapcraft
[15:36] <apw> stgraber, if you badtest it it will migrate, so it needs blocking
[15:36] <apw> stgraber, or you could skiptest lxd if that is its only blocker
[15:36] <stgraber> apw: I'm badtesting the old snapcraft from artful itself, not the one in artful-proposed (which seems to also be broken)
[15:37] <apw> stgraber, ahh ok
[15:37] <stgraber> apw: but indeed as it's the only failure for LXD, I could have gone with skiptest for LXD instead
[15:37] <stgraber> apw: I pinged kyrofa about it so upstream snapcraft can figure out what's going on here. AFAICT they're downloading bits from pip and running them, so it's likely external code which changed...
[15:37] <apw> stgraber, the second fatal change in pip in 2 weeks by the sounds of it
[15:38] <stgraber> yeah, I saw you and infinity pushed similar overrides to snapcraft...
[15:38] <stgraber> that's a big hint not to depend on external code in your package tests but given what snapcraft does, it might be kinda hard for them to do
[15:39] <apw> yeah
[16:16] -queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.4]
[16:31] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.10-0ubuntu1~16.04.1]
[16:57] <slashd> sil2100, hi about LP: #1657256. My colleague Mmike told me that this particular fix is percona-xtradb-cluster-5.5 (only available in trusty) and the current fix doesn't apply to Xenial and late because it run 5.6 (totally different source code) and no upstream fix is made yet for 5.6 but there was one already for 5.5, does that make any difference ? if not it's totally fine, just wanted to bring this to the table since the
[16:57] <slashd> sru has been blocked. If you keep the decision to block the SRU, I'll talk to Mmike in order for him to create a upstream fix to 5.6 before SRU'ing 5.5
[17:01] <sil2100> slashd: so the case here is that for us to release a fix somewhere in an older series it needs to be also present in the devel series - the package names are different but basically 5.6 replaces 5.5 in future releases
[17:05] <slashd> sil2100, yeah I though it wouldn't apply because it's totally 2 different versions, so I'll told MMike to start working on a 5.6 fix upstream, SRU'ing it, and then restart the SRU of 5.5 from skratch
[17:05] <sil2100> slashd: if we accept the 5.5 fix in trusty and people will upgrade to a future release, the fix will be gone
[17:06] <sil2100> slashd: this is the biggest worry and the main reason why we require the devel series to be released first
[17:07] <slashd> sil2100, true, and I'm totally in favour to have the fix release in devel release first. I just thought that since it was 2 different version it wouldn't apply in this particular, case but it's noted for future, thanks
[17:07] <sil2100> slashd: it doesn't have to be the *very same* fix, but the bug needs to be fixed
[17:07] <slashd> sil2100, sure, I'll pass the message to MMike and it's noted in my case for similar SRU situation.
[17:08] <slashd> thanks bdmurray and sil2100, much appreciated
[17:09] <slangasek> override_dh_fixperms:
[17:09] <slangasek> 	$(overridden_command) -Xetc/xdg/autostart/kalarm.autostart.desktop
[17:09] <slangasek> $ cat debian/lintian-overrides
[17:09] <slangasek> executable-not-elf-or-script etc/xdg/autostart/kalarm.autostart.desktop
[17:09] <slangasek> $
[17:09] <slangasek> mmmhmm
[17:09] <sil2100> slashd: thanks!
[17:11] -queuebot:#ubuntu-release- New binary: gir-to-d [amd64] (artful-proposed/universe) [0.9.0-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: gir-to-d [armhf] (artful-proposed/universe) [0.9.0-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: gir-to-d [i386] (artful-proposed/universe) [0.9.0-1] (no packageset)
[17:11] -queuebot:#ubuntu-release- New binary: python-pyepsg [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
[17:14] <slangasek> acheronuk: kalarm debian/copyright claims that the code is all GPL2+; the copyright in ./src/kalarmmigrateapplication.{cpp,h} does not agree
[17:15] -queuebot:#ubuntu-release- New: accepted kalarm [source] (artful-proposed) [4:16.12.3-0ubuntu1]
[17:16] -queuebot:#ubuntu-release- New: accepted python-pyepsg [amd64] (artful-proposed) [0.3.1-1]
[17:17] -queuebot:#ubuntu-release- New: accepted gir-to-d [amd64] (artful-proposed) [0.9.0-1]
[17:17] -queuebot:#ubuntu-release- New: accepted gir-to-d [i386] (artful-proposed) [0.9.0-1]
[17:17] <acheronuk> slangasek: oh. I didn't do the copyright updated for those, but will make sure any that are wrong are correct with the next upload
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [amd64] (artful-proposed) [0.4.4-4]
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [armhf] (artful-proposed) [0.4.4-4]
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [ppc64el] (artful-proposed) [0.4.4-4]
[17:17] -queuebot:#ubuntu-release- New: accepted lua-argparse [amd64] (artful-proposed) [0.5.0-1]
[17:17] -queuebot:#ubuntu-release- New: accepted python-iso3166 [amd64] (artful-proposed) [0.8.git20170319-1]
[17:17] -queuebot:#ubuntu-release- New: accepted gir-to-d [armhf] (artful-proposed) [0.9.0-1]
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [arm64] (artful-proposed) [0.4.4-4]
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [s390x] (artful-proposed) [0.4.4-4]
[17:17] -queuebot:#ubuntu-release- New: accepted jquery-at.js [amd64] (artful-proposed) [1.5.3+dfsg.1-1]
[17:17] -queuebot:#ubuntu-release- New: accepted node-stream-assert [amd64] (artful-proposed) [2.0.3-1]
[17:17] -queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [i386] (artful-proposed) [0.4.4-4]
[17:18] <slangasek> acheronuk: this was not a regression vs. kdepim, and I have accepted the package.  should be fixed, though
[17:19] <acheronuk> slangasek: it will be. thanks for doing that :)
[17:19] <slangasek> acheronuk: also, see my skepticism above regarding the combination of a dh_fixperms override in debian/rules with a lintian override
[17:19] <acheronuk> noted, and now looking where that came from
[17:32] <acheronuk> slangasek: I'm doubtful we need any of that. I'll do a test build to see if we can throw that away and still have that autostart
[18:07] <Ampelbein> Hi. Is there anything missing for #1513567 to be reviewed? Do you need any more information?
[18:08] <Ampelbein> bug #1513567
[18:10] -queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
[18:14] -queuebot:#ubuntu-release- New binary: dpdk [amd64] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
[18:15] -queuebot:#ubuntu-release- New binary: dpdk [i386] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
[18:18] -queuebot:#ubuntu-release- New binary: dpdk [arm64] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
[18:23] -queuebot:#ubuntu-release- New: accepted dpdk [amd64] (artful-proposed) [16.11.1-2]
[18:23] -queuebot:#ubuntu-release- New: accepted dpdk [i386] (artful-proposed) [16.11.1-2]
[18:23] -queuebot:#ubuntu-release- New: accepted dpdk [arm64] (artful-proposed) [16.11.1-2]
[18:23] -queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (artful-proposed) [16.11.1-2]
[19:09] -queuebot:#ubuntu-release- New binary: node-gulp-concat [amd64] (artful-proposed/universe) [2.6.1-1] (no packageset)
[20:39] -queuebot:#ubuntu-release- New binary: octave [ppc64el] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[20:55] -queuebot:#ubuntu-release- New binary: octave [i386] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[21:01] -queuebot:#ubuntu-release- New binary: octave [amd64] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[21:02] -queuebot:#ubuntu-release- New binary: octave [s390x] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[21:21] -queuebot:#ubuntu-release- New binary: octave [armhf] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[21:39] -queuebot:#ubuntu-release- New binary: octave [arm64] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: flask-htmlmin [amd64] (artful-proposed/universe) [1.2-1] (no packageset)
[23:14] <infinity> lan3y: I had to restart all but 3 ppc64el worker services for autopkgtest.  Not sure how or where to debug why they were dead, so if you feel like doing a post-mortem, please do.
[23:28] <Laney> infinity: Why did you have to?
[23:31] <infinity> Laney: Because they were all dead, only 3 things were running, yet hundreds in the queue.
[23:31] <infinity> Laney: Which implied to me that all the dead ones were maybe an issue.
[23:31] <infinity> Laney: But I dunno.
[23:31] <Laney> They're supposed to self-restart
[23:31] <Laney> Would be interesting if they didn't
[23:32] <infinity> Laney: "systemctl --all list-units autopkgtest\*|sort | grep dead" seems to disagree on that score.
[23:32] -queuebot:#ubuntu-release- Unapproved: cloud-init (trusty-proposed/main) [0.7.5-0ubuntu1.21 => 0.7.5-0ubuntu1.22] (ubuntu-cloud, ubuntu-server)
[23:33] <smoser> hi. there are now 2 cloud-init uploads in trusty  queue
[23:33] <smoser> could someone NACK my first? the first does not have a fix for bug 1379080
[23:33] <Laney> infinity: I'll look later on if you don't figure it out
[23:33] <Laney> Got to go watch election results / sleep
[23:33] <Laney> night
[23:34] <infinity> Laney: I'm about to go eat all the meat, hence the hand-off (which I assumed would catch you in the morninig, not now. :P)
[23:34] <infinity> morning.  Typing hard.
[23:35] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (trusty-proposed) [0.7.5-0ubuntu1.22]
[23:37] -queuebot:#ubuntu-release- Unapproved: rejected desktop-file-utils [source] (precise-proposed) [0.20-0ubuntu3.1]
[23:56] -queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.1.5+bzr5596-0ubuntu1~16.04.1 => 2.2.0+bzr6054-0ubuntu2~16.04.1] (ubuntu-server)
[23:56] -queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.5+bzr5596-0ubuntu1~16.10.1 => 2.2.0+bzr6054-0ubuntu2~16.10.1] (ubuntu-server)
[23:57] -queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.0~rc1+bzr5922-0ubuntu2 => 2.2.0+bzr6054-0ubuntu2~17.04.1] (ubuntu-server)


[09:36] <quicksilver> how do I pick a version of a file and record that?
[09:36] <quicksilver> if I bzr revert -r123 file.txt
[09:36] <quicksilver> I belive it will rever the text contents of file.txt to the text contents as of revision 123
[09:37] <quicksilver> but it won't reset the rev-id of that file to the revision called 123
[09:37] <quicksilver> does that even make sense
[09:37] <fullermd> What "the rev-id of that file"?  Files don't have revisions, revisions have files.
[09:39] <quicksilver> fullermd: when I do a later merge into another branch
[09:39] <quicksilver> fullermd: I want it to think "this file is current as of rev-id X, so there is nothing to do"
[09:39] <quicksilver> fullermd: and I want it to use X as the basis for the diff it will build when merging
[09:40] <quicksilver> does that make sense?
[09:40] <fullermd> As in forgetting the history and all the changes to it since then?
[09:40] <quicksilver> effectively yes
[09:40] <fullermd> No such thing.
[09:40] <quicksilver> I can make my situation more concrete if you like
[09:40] <fullermd> You'd have to recreate the whole history from that point.
[09:41] <quicksilver> file is in a good state in rev-id A, say
[09:41] <quicksilver> in rev-id B it received massive formatting only changes
[09:41] <quicksilver> in one particular branch, in rev-id C, those formatting changes were accidentally undone
[09:41] <quicksilver> so rev-id C is textually identically to rev-id A
[09:42] <quicksilver> now all the other active branches have the file correctly formatted (B)
[09:42] <quicksilver> if I simply correctly format and commit I believe I will generate a new revision (D)
[09:42] <quicksilver> which might 'look like' B
[09:42] <quicksilver> but because it has more history, it will conflict with branches from branch point B
[09:42] <quicksilver> if they ever make changes to affected lines (which is lots of them)
[09:43] <quicksilver> fullermd: does that sound like it makes sense?
[09:43] <fullermd> Not necessarily; 3 way merge should ignore all the stuff in the middle and just look at the LCA and end products.  Weave merge would probably blow beets on it, to be sure...
[09:44]  * quicksilver googles LCA
[09:44] <quicksilver> common ancestor?
[09:44] <fullermd> But you're essentially talking about changing the contents of a file in a revision [multiple, but same difference].  You can't do that without changing (i.e., replacing) the revision, and you can't do that without replacing all the revisions that follow.
[09:44] <fullermd> So the only feasible way would be recreating some amount of branch history to eradicate the traces of such things.
[09:44] <fullermd> Latest Common Ancestor
[09:44] <quicksilver> nod
[09:45] <quicksilver> I know how to recreate the history, done it before for worse issues than this one
[09:45] <quicksilver> I'll try the text revert and see if I get conflicts!
[09:45] <fullermd> If you're needing to dispose of 2 revs from earlier today that aren't published, that's trivial; if it's 500 revs from the last 6 months that are all over the world...
[09:45] <quicksilver> or even if they're just all over 30 branches in this office it's still a pain :P
[09:46] <fullermd> Quite.  The pain goes all nonlinear as soon as there's more than one copy...
[09:47] <quicksilver> thanks
[20:34] <fmccann> Hey bzr folks, I’m trying to configure bzr to use vim for resolving conflicts. Is this possible? I’m tring to config either bzr.mergetool or external_merge for the extmerge plugin and I’m not getting anywhere :D