[00:00] <m3ga> ScottK: thats my problem :-) i've seen breakage in both ocaml and haskell libs.
[00:01] <ScottK> What we need is someone who can tell us what needs to be done and in what order since none of use really know about those things.
[00:01] <ScottK> If someone can do the analysis, we can probably make it happen.
[00:02] <m3ga> i think what it needs more than anything is process; testing that the complete set o libs does work.
[00:04] <m3ga> ScottK: does ubuntu  pull from debian testing or from debian unstable?
[00:04] <ScottK> m3ga: This discussion if probably better on #ubuntu-motu since the packages are all in Universe.
[00:04] <ScottK> m3ga: Mostly unstable.
[00:10] <m3ga> ScottK: just joined -motu
[00:10] <ScottK> OK.
[00:11] <maxb> laprice: Correct, .ex just means "example" - though those files, even when renamed are not really "built into the package" so much as "used to build the package". Please direct similar future questions to #ubuntu-motu, which is a more on-topic forum for guidance on learning packaging.
[00:12] <laprice> sorry, i didn't realize this was not the correct channel.
[00:12] <TheMuso> slangasek: When you get a minute, I think we will need studio disks rebuilt, due to include the fixed apt-setup package. One of our testers ran into bug 316618.
[00:13] <TheMuso> slangasek: Thanks in advance.
[00:13] <slangasek> heh, just making that comment on #ubuntu-tsting
[00:13] <slangasek> or on #ubuntu-testing, rather
[00:14] <TheMuso> he ok.
[00:14] <TheMuso> s/eh/heh/
[00:29] <cjwatson> superm1: (addressed Matt Domsch's mail now)
[00:38] <calc> cjwatson: who is in charge of reviewing SRUs currently?
[00:39] <calc> ah i found the group :)
[01:27] <maxb> (roughly) how many days should I wait for ubuntu-devel@ moderation before seeking a kindly moderator here to expedite matters?
[01:48] <superm1> maxb, eventually nvidia with have an open libvdpau library and those packages that were provided right now will go away.  they're named the way they're named right now in case that doesn't happen by the time nvidia-185-graphics-drivers is out
[01:48] <superm1> nvidia didn't really provide a time frame for when libvdpau will be open
[01:48] <superm1> bryce,^ if you are interested too
[01:49] <maxb> So, if 185 shows up in the meantime, it will just need to conflict with 180 explicitly? And if additional versions, then the conflicts lines just grow longer, and hopefully nvidia gets around to doing it properly before it gets silly?
[01:50] <superm1> maxb, exactly
[01:50] <maxb> gg, makes sense
[01:51] <superm1> once libvdpau is open it will be installed by default likely too since ffmpeg will likely be linking to it..
[01:56] <ArneGoetje> calc: pong
[02:07] <calc> ArneGoetje: heh nevermind slangasek and I worked out what he wanted to do for alpha 3, he had been thinking about rerolling langpacks but decided against it
[02:27] <superm1> bryce, i updated one bit on there, but otherwise looks right
[02:28] <bryce> superm1: great thanks
[02:29] <ArneGoetje> calc: is there anything we need to change in the language-support packages for oo.o3?
[02:44] <calc> ArneGoetje: i don't think so
[02:45] <calc> i just found out the main drive in my computer is subject to sudden death at ~ 3mo of use
[02:45]  * calc is going to back all his data up onto an external drive asap
[02:49] <LaserJock> calc: 3 months?
[02:49] <calc> yea the lovely Seagate 7200.11 1TB drives
[02:50] <LaserJock> geeze, and 1TB too :(
[02:50] <calc> http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=3668&view=by_date_ascending&page=1
[02:50] <LaserJock> calc: too many OO.o builds? :-)
[02:51] <calc> the 1.5TB had the problem which was revealed over a month ago and apparently they now know the 1TB are affected too but no solution yet
[02:56] <ArneGoetje> calc: I avoid to buy Seagate and WD for exactly that reason. Too much bad experience.
[02:56] <ArneGoetje> calc: the last WD I bought failed after 2 weeks. :(
[02:56] <LaserJock> go Maxtor! ;-)
[02:57] <superm1> um didn't seagate buy maxtor?
[02:58] <superm1> eg http://www.seagate.com/maxtor/ existing
[02:58] <LaserJock> ah
[02:58] <LaserJock> well, there you go
[02:58] <kees> craaap.  I've got 2 of those drives.
[02:58] <ArneGoetje> I've never had problems with Hitachi
[03:08] <RAOF> Hm.  Alpha-3 freeze means shephearding f-spot and tomboy through the gnome-sharp2 transition so I can get the new version of smuxi is... unlikely :)
[03:08] <cjwatson> didn't hitachi make the notorious deskstar (aka deathstar)?
[03:09]  * kees is currently backing up everything to is handy 1TB usb drive....
[03:09] <ArneGoetje> cjwatson: that was IBM (before taken over by Hitachi), yes. But despite the name, I've never had any problems with them... maybe I was just lucky... ;)
[03:12] <cjwatson> it's amazing how half the web forum posts I read castigate Ubuntu for doing nothing but changing the desktop background, and the other half complain about how we haven't changed the theme much for several releases
[03:12] <ArneGoetje> but since my last encounter with WD (which costed me 20000 NT$ to get the data recovered by a profesional data rescue company, I have invested in a hardware raid 5 solution. :)
[03:12] <cjwatson> (obviously both missing the point rather substantially)
[03:14]  * kees needs eSATA.  usb is slow
[03:16] <RAOF> Urgh.  The new volume control notification applet is really annoying.
[03:17] <cjwatson> the way it's horizontal and semi-offscreen?
[03:17] <RAOF> No, that's the new panel applet.
[03:17] <RAOF> That's also more than moderately annoying.
[03:17] <slangasek> RAOF: are the gnome-sharp2 bits in place in the archive?  we didn't have gnome-desktop-sharp2 yet, last I was looking at that
[03:17] <RAOF> I'm talking about the notification icon that only pops up when something's playing a stream.
[03:18] <RAOF> Meaning that it's impossible to change the volume before something starts playing, and the volume icon is always in a different spot.  Score!
[03:19] <RAOF> slangasek: Looks all done to me.
[03:19] <RAOF> https://edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/2.20.1-2ubuntu7/+build/831357
[03:19] <RAOF> Urgh, wrong page.
[03:20] <slangasek> RAOF: ooh, ok.  Well, maybe we can transition f-spot and tomboy if we desperately need more CD space for alpha-3. :)
[03:20] <slangasek> RAOF: you've confirmed that they build ok now against the new versions?
[03:20] <RAOF> No, not tomboy or f-spot.
[03:21] <RAOF> Did it for banshee, because that was something I could fix ;)
[03:21] <slangasek> heh
[03:22] <RAOF> I'll do it for the others now if you like
[03:22] <slangasek> it would be useful to have that done so that we can transition them at the best opportunity
[03:24] <RAOF> I'll check & attach debdiffs to the transition bug, I guess.
[03:25] <slangasek> RAOF: awesome, thanks
[03:26] <calc> backing up 1TB over USB is going to be slowww
[03:26] <calc> should take ~ 14hr or so i guess
[03:29]  * RAOF should get >=4GB of ram on his next purchase.  Building things on a tmpfs is just too nice.
[03:33] <calc> RAOF: i'm thinking of buying another 4GB for my system to bring it up to 8GB (max for my chipset)
[03:34] <RAOF> Well, that's not gone well.  Apparently no package in the archive contains gnome-panel-sharp-2.24.pc
[03:34] <slangasek> RAOF: ah, that's what I meant earlier wrt gnome-desktop-sharp2
[03:35] <slangasek> we need gd#2 2.24
[03:35] <RAOF> Why did the -0ubunt1 build succeed then?
[03:36] <slangasek> of which?
[03:36] <RAOF> Of tomboy.
[03:36] <RAOF> The upstream version doesn't seem to have changed.
[03:36] <slangasek> because it was built against the older gnome-sharp2 that still had gnome-panel-sharp, I think
[03:37] <slangasek> er, no; maybe it was that tomboy had code that, *if* it detected g# 2.24 or better at build time, it requires this new .pc
[03:37] <slangasek> anyway, if gd#2 isn't updated yet, that's definitely the first step
[03:39] <RAOF> Ah, yes.  There it is, conditional on gnome-sharp being >= 2.23.99
[03:39] <RAOF> Right.  New gd#2.24!
[03:39]  * RAOF goes and checks pkg-cli-libs
[03:45] <RAOF> Ah, so no quick joy there.
[03:45] <RAOF> And you made the last, unuploaded checkin to svn.  Score.
[04:07] <ebroder> Any core devs willing to sponsor uploads into {hardy,intrepid}-proposed for LP #216761?
[04:17] <ScottK> ebroder: We're in the middle of a freeze for Alpha 3, so no.
[04:17] <ScottK> Unless it fixes something critical for Alpha 3
[04:17] <ebroder> ScottK: It's not Jaunty - it's for Hardy and Intrepid
[04:17] <ScottK> Oh.
[04:43] <ScottK> ebroder: Since pitti asked bryce to sponsor it, I think I'll let him do it.  Otherwise you might ask zul.
[04:45] <ebroder> Ok. Did bryce actually get that request? He wasn't subbed to the bug
[04:48] <ScottK> Dunno, but I just highlighted him.
[04:48] <ScottK> It's late here, but I imagine he'll get it eventually.
[04:49] <ebroder> Ok, thanks
[04:54] <nixternal> bryce: http://paste.ubuntu.com/105046/
[04:55] <nixternal> there are a few of us witnessing this right now with kde4 in jaunty...any ideas?
[04:56] <slangasek> calc: um, that's disturbing, OOo finished both i386 and amd64 in < 6h?
[04:56] <pwnguin> slangasek: maybe database didn't build or something
[04:56] <slangasek> calc: huh, but 2ubuntu3 took the same time, so I guess things got faster in 3.0?
[04:57] <slangasek> or maybe the buildds got an upgrade and I hadn't noticed until now :)
[05:43] <bryce> nixternal: weird, never seen that
[05:44] <bryce> actually...
[05:44] <bryce> exaCopyDirty sounds familiar
[05:44] <nixternal> bryce: ya, we noticed that tonight, however it seems to not be the root of our issue actually...there are one of two things going on that are kde4 related..but I thought I would pass that by you
[06:04] <det> When I upload a new package to that replaces an older one (the name of the package changed, what can I do to ensure that an aptitude upgrade will upgrade the package), I tried putting "Replaces: X" in the control file, but it isnt working.
[06:07] <slangasek> you would want to create a "dummy" package under the old name to ensure upgrading
[06:07] <slangasek> but why did the package name change?
[06:09] <det> It is in a PPA, and the old maintainer gave it a confusing name.
[06:09] <slangasek> ok
[06:09] <slangasek> creating a dummy package is the only way to ensure an upgrade
[06:09] <det> ok, thanks
[06:10] <det> I think I have another solution, actually.
[06:10] <det> There is 1 metal package that people install to bring in all the packages, so I just added a conflict on the old package in the meta package
[06:10] <det> meta*
[06:11] <det> and changed the depend on the new package
[06:11] <slangasek> right, if you have a top-level package whose name will stay the same, that's a better solution :)
[06:12] <det> Btw, what is the best way to ensure that a hardy package has an lesser version number than an intrepid package
[06:12] <det> Is there any kind of established naming scheme ?
[06:13] <det> Right now I am using "XXX-0ubuntu1~ppa2" for intrepid and "XXX-0ubuntu1~ppa1" for hardy
[06:13] <det> It would be nice to number then independently somehow
[06:14] <det> XXX-0ubuntu1~ppaX and XXX-0ubuntu2~ppaX maybe ?
[06:14] <RAOF> I tend to use foo-0~intrepid~ppa1, foo-0~hardy~ppa1, etc.
[06:14] <det> RAOF, does that only work because I > H ?
[06:16] <slangasek> yes
[06:17] <slangasek> I would lean towards foo-0~ppa1~{hardy,intrepid} or foo-0~ppa1{hardy,intrepid}or foo-0~ppa1.8.{04,10}; that way the release it's built for is the least significant part of the version
[06:18] <det> btw, how do "-" and "~" differ ?
[06:19] <slangasek> ~ sorts earlier than anything, including end-of-string
[06:20] <slangasek> - has a special meaning, in that the last occurence of it in a version number is taken to be the delimiter between the upstream version and the Debian revision
[06:20] <RAOF> slangasek: But that won't sort below official backports?
[06:20] <det> btw, why use "-0", I was told to use "-0ubuntu1", but I dont understand the rational for either
[06:20] <slangasek> RAOF: well, true; I wasn't worrying about those
[06:21] <slangasek> det: if Debian hasn't packaged that upstream version yet, we use "-0" so that our versions sort earlier than an eventual "-1"
[06:22] <slangasek> in theory the Debian maintainer could release a -1 version that includes all of our changes, and we want to ensure we'll be able to sync that version from Debian
[06:22] <det> Ok, thanks
[06:22] <det> why the 1 on the end then ?
[06:22] <Mithrandir> det: because we might want to update the packaging or add patches later too
[06:23] <Mithrandir> so it might be 0ubuntu2, 0ubuntu3 and so on
[06:23] <det> XXX-0~0hardy~ppaX and XXX-0~1intrepid~ppaX, does that seem like a reasonable scheme ?
[06:24] <det> basically, RA0F's scheme, except prepend a number to the codename
[06:24] <LaserJock> why would you do that?
[06:25] <det> seems like a bad idea to depend on the sort order of the codename
[06:25] <LaserJock> that's why the codenames sort
[06:25] <Mithrandir> better use the release version, then.
[06:25] <det> for now :-)
[06:25] <det> they cant do that forever
[06:25] <det> and they didnt always sort in the past
[06:25] <LaserJock> since breezy
[06:25] <det> release version is a good idea, thanks
[06:26] <det> XXX-0~8.04~ppaX and XXX-0~8.10~ppaX it is
[06:26] <Amaranth> guaranteed to work until the year 3000
[06:27] <det> Anyways, after Zany Zebra, this sorting system breaks down
[06:27] <det> and I dont like to use things that are fundamentally broken
[06:27] <det> and not until year 3000
[06:27] <StevenK> Amaranth: Further, since we only minus 2000
[06:28] <det> we are on j very soon, so 16 letters left, aka 8 years
[06:28] <Amaranth> StevenK: I guess if you want 100.4 :P
[06:28] <det> Thanks for the help guys
[06:28] <Amaranth> err, that'd be 2100
[06:29]  * StevenK laughs
[06:29] <Amaranth> so, good until then
[06:29] <Amaranth> might need a new scheme if it makes it that long
[06:29] <det>   spring: Depends: spring-lobby which is a virtual package.
[06:29] <det> argh
[06:30] <det> I made the metal package conflict with the old package, and depend on the virtual package that the new package provides
[06:30] <det> but aptitude is complaining
[06:30] <det> meta*
[06:32] <det> $ apt-cache show springlobby | grep Provides
[06:32] <det> Provides: spring-lobby
[06:32] <det> $ apt-cache show spring | grep Depends
[06:32] <det> Depends: spring-engine, spring-lobby, spring-installer, ca-installer
[06:32] <det> Am I doing something that is not allowed ?
[07:39] <dholbach> good morning
[07:40] <ion_> Howdy
[08:27] <siretart> could you please give us your opinion on the jack issue? my last update to the mailing list was on monday, but the issue is open since mid december
[08:27] <siretart> -ECHAN, sorry
[08:29] <LaserJock> siretart: is that JACK in Main?
[08:29] <siretart> LaserJock: no. I currently don't see jack suitable for main
[08:30] <siretart> but that's just my personal humble opinion
[08:30] <LaserJock> darn
[08:30] <LaserJock> all the music apps that would be nice to include in Edubuntu require JACK
[08:31] <LaserJock> however we are working on some Universe metapackages that would make it less of an issue I think
[09:23] <asac> siretart: what happened to the glorious iceowl/experimental upload ;)?
[09:39] <siretart> asac: ah, on my harddisk, not uploaded yet. just a sec
[09:39] <siretart> LaserJock: do you know someone actively working on jack in ubuntu?
[09:40] <LaserJock> siretart: there was discussion for Intrepid with Ubuntu Studio folks
[09:40] <LaserJock> siretart: I think bigon perhaps was looking at it
[09:41] <bigon> LaserJock: at jack?
[09:42] <Baby> LaserJock: ping!
[09:42] <LaserJock> bigon: maybe my memory is failing me, it's almost 2am :-)
[09:42] <LaserJock> Baby: yeah?
[09:42] <Baby> LaserJock: are you looking at KDE4 as a foundation for an educational desktop for kids? (ref: http://laserjock.wordpress.com/2009/01/13/why-we-need-edubuntu-to-succeed/ )
[09:42] <bigon> LaserJock: I dont remember I've work on jack
[09:43] <siretart> asac: uploaded
[09:43] <LaserJock> bigon: hmm, were you looking at freebob?
[09:44] <asac> siretart: thanks
[09:44] <LaserJock> Baby: Edubuntu is currently "adding on" to both Gnome and KDE4, however I'm currently interested in what KDE4 can offer
[09:45] <LaserJock> Baby: maybe pop over to #edubuntu and we can chat about what Debian's doing
[09:46] <Baby> I'm very interested in KDE4 as a foundation for a desktop targeted at kids (Debian Jr project). I've just talked to Aaron about it, even though it doesn't have direct educational purposes, I think it would be good to collaborate
[09:46] <Baby> yup :)
[10:31] <cjwatson> det: you mentioned using Replaces earlier; it doesn't mean quite how you described it, and you should probably read the policy manual carefully because this is an area where people often get confused
[10:31] <cjwatson> det: A Replaces: B on its own actually just means that A contains some files also contained by B (so B here is usually "foo (<< some-version)")
[10:32] <det> I went the dummy package route
[10:33] <det> A Replaces B; A Conflicts with B; New dummy package of B that depends on A
[10:33] <cjwatson> for a single package with no complicating dependencies from elsewhere, Conflicts+Replaces+Provides should do it; the Provides may not always be necessary
[10:33] <cjwatson> slangasek is right that there are cases that can only be solved by a dummy package, though - apt doesn't always work it out
[10:34] <cjwatson> (Conflicts+Replaces means something completely different from Replaces alone)
[12:08] <mdz> mvo: have you seen bug 312092?  It seems to break upgrades from intrepid to jaunty
[12:10] <mvo> mdz: checking it now, thanks - I think its a side-effect of new code that tries to ensure that if one component is enabled it should be used consistently (in -updates and -security as well) - looks like partner somehow entered this
[12:10] <mdz> mvo: yes, that's what the log messages seem to indicate
[12:10] <mdz> mvo: I have a system ready to upgrade to jaunty if you want a tester
[12:11] <mvo> mdz: thanks, I will ping you when its fixed
[12:31] <slangasek> tkamppeter: milestone freeze is still in effect, please don't upload new upstream versions of packages that are on the CDs right now
[12:41] <jakon> A regression has been found in acpi-support released yesterday: apm of desktop disks is set to 128 instead of 254
[12:41] <jakon> -> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695
[12:42] <jakon> The regression is in acpi-support (0.109-0hardy1)
[12:42] <cjwatson> jakon: have you suspended and resumed?
[12:43] <cjwatson> slangasek: ^-
[12:43] <jakon> This has nothing to do with that i guess
[12:43] <jakon> There are two bugs in the scripts
[12:43] <jakon> They don't handle the case of on_ac_power returning 255.
[12:44] <slangasek> hmm
[12:45] <jakon> I attached two patches that should fix this to the bug tracker (last 2 comments)
[12:46] <slangasek> the second is a patch to the resume script; I see the bug, but how does that change anything on a non-laptop system?
[12:46] <slangasek> or do you mean for it to be applied to all four copies of the script?
[12:47] <jakon> Oh yes
[12:49] <jakon> The script in resume.d is irrelevant (the whole folder is)
[12:49] <slangasek> not entirely
[12:49] <slangasek> it just isn't used by default
[12:49] <jakon> ;) ok
[12:56] <slangasek> sigh; there's nothing about acpi-support that doesn't make me weep
[13:16] <tkamppeter> slanagsek, sorry, but changes are small, as we already had Foomatic 4.0 development snapshots in Intrepid. So all these packages are only bug fixes (for the last bugs fixed before Foomatic 4.0 official release).
[13:16] <slangasek> tkamppeter: doesn't matter, they're not supposed to be uploaded during the freeze.
[13:17] <slangasek> cjwatson: acpi-support 0.109-0hardy2 uploaded to hardy-proposed, please review
[13:18] <cjwatson> slangasek: will do, can you mail the TB (CC me) as per standard procedure for regressions?
[13:18] <slangasek> yes
[13:21] <cjwatson> accepted
[13:22] <slangasek> gar, bug #59695 is way too unwieldly
[13:22] <cjwatson> tkamppeter: the reason not to upload these things despite the small changes is that they can cause other builds to be delayed, which causes a problem for the release manager getting things out on time especially when he's already been up for too many hours
[13:22] <slangasek> I'm getting repeated timeouts :(
[13:22] <Hobbsee> slangasek: try edge.launchpad.net
[13:22] <Hobbsee> hrm.  it's falling over on that too, it seems.
[13:23] <slangasek> I got it to load at last, so I'm good now
[13:25] <cjwatson> if Ralph and Jakob confirm the fix, and somebody on a laptop confirms that it doesn't regress for them, I think we can push this on through to -updates
[13:25] <cjwatson> do we need to block downloads of 0.109-0hardy1 and 0.114-0intrepid1?
[13:26] <slangasek> jakon: can you test the 0.109-0hardy2 package once it's built and available in hardy-proposed?
[13:27] <slangasek> cjwatson: the impact of the regression is to cause decreased drive performance on systems with acpi-support installed and without batteries; I'm not sure the user-facing disruption of blocking the downloads is warranted
[13:27] <jakon> Yes, can test that
[13:27] <cjwatson> it's only decreased performance, not damage?
[13:27] <jakon> I guess
[13:28] <cjwatson> I don't know, I was asking
[13:28] <slangasek> cjwatson: until we roll out the new update, affected systems will have a greater rate of increase in load cycle count as well
[13:28] <jakon> There won't be any immediate damage
[13:28] <slangasek> but nothing that should be damaging if we're rolling out a new update shortly
[13:29] <pochu> could a core-dev please approve the Intrepid task in bug 295490? TIA.
[13:29] <jakon> I don't know if there are (old? strange?)disk that will hang when set to apm 128
[13:30] <slangasek> jakon: well, I don't think we should take precipitous action based only on speculation that some drives might fail under standard conditions
[13:33] <jakon> There is certainly no need to act precipitately, but this should be fixed sometime soon.
[13:33] <jakon> The "hanging" ide led reported in launchpad frightened me a little
[13:34] <slangasek> yes, working as fast as I can to get it fixed
[13:34] <cjwatson> slangasek: I just noticed that I declared "layers" to be the Name in archive-reorg and that you objected to it on the grounds that they weren't layered. Can I convince you on the grounds that they're partially layered? :-)
[13:34] <slangasek> haha
[13:34] <slangasek> I don't think you can cnvince me, but you can make the declaration anyway and I'll live with it
[13:34] <cjwatson> (I figured I'd just take the blame)
[13:35] <cjwatson> actually I was sort of also thinking of them as something that a user could layer onto their minimal system
[13:36] <cjwatson> but mostly as "oh my god we have spent hours on this name"
[13:38] <Hobbsee> snowflakes!  :P
[13:43] <cjwatson> I'm noticing an amazing similarity between this IRC log and the log of the one coinciding with that UDS session that I happen to have open ...
[13:43] <cjwatson> oops
[13:46] <jakon> Just a note for testing acpi-support: I don't have desktop pc, i faked one by replacing on_ac_power with a "exit 255" shell script. But that should do i think.
[13:46] <slangasek> cjwatson: 0intrepid2 accepted
[13:47] <slangasek> cjwatson: er, no it wasn't
[13:47]  * slangasek reads the whole subject line
[13:50] <slangasek> cjwatson: ok, there - /now/ 0intrepid2 is in unapproved
[13:58] <cjwatson> slangasek: accepted
[14:00] <slangasek> thanks
[14:08] <maxb> How long should I wait for ubuntu-devel@ moderation before it becomes reasonable to ask on IRC for a kindly moderator to expedite matters?
[14:19] <emgent> mvo: ping
[14:23] <Riddell> calc: I see the openoffice source has patches for KDE 4, have you tried them?
[14:30] <mvo> emgent: pong
[15:14] <jakon> slangasek: acpi-support 0.109-0hardy2 looks good, just tested it
[15:15] <slangasek> jakon: great, thanks.  Could you follow up to the bug report as well?
[15:17] <jakon> Will as soon as launchpad is up again
[15:17] <jakon> Ok, that is now.
[15:23] <jakon> Commented in launchpad
[15:29] <jakon> slangasek: Do you plan to use the pm-utils script i posted? ( http://launchpadlibrarian.net/21210580/95hdparm-apm ) Because it also contains this bug. If yes, i will update it.
[15:35] <slangasek> jakon: hadn't looked at it in detail yet
[16:07] <calc> Riddell: yes they don't work
[16:08] <calc> Riddell: i'm going to be talking to some people to see about why soon
[16:08] <calc> Riddell: i used them in the previous build from a few weeks ago and got lots of bug reports about it not working at all
[16:19] <Riddell> calc: a shame, do you know who was working on them?
[16:24] <calc> Riddell: i think Kendy of Novell
[16:24] <calc> but i haven't pinged him about the KDE issue yet
[16:25] <calc> Riddell: just asked him but i am not sure if he is online right now
[16:30] <jakon> quit("Bye")
[16:30] <jakon> Whatever.
[16:39] <calc> Riddell: kendy says it is pretty much completely broken and he hasn't had time to work on it
[17:00] <lool> siretart: Do you have any commit on upstream xine-lib?  I'd love it if you could merge the two "%s" additions upstream
[17:00] <Riddell> calc: a shame that
[17:01] <calc> Riddell: it will work better with kde3 support than it does in alpha3, aiui the file picker is missing currently
[17:01] <calc> Riddell: but it won't have full kde4 integration unfortunately :(
[17:02] <calc> Riddell: gio support doesn't work right either but it is being worked on luckily
[17:09] <rtg> superm1: wrt bug #317270, can you clarify which kernel version? I assume its Jaunty.
[17:10] <superm1> rtg, yes that was with jaunty
[17:10] <rtg> superm1: thanks
[17:18] <mib_uo1mgbbs> hi
[17:19] <mib_uo1mgbbs> anyone familiar with ext4? may I use ext4 as logical drive?
[17:20] <cjwatson> mib_uo1mgbbs: ext4 is independent of whether you're using primary or logical partitions (so "yes")
[17:22] <mib_uo1mgbbs> the funny thing is while i'm installing xubuntu 9.04, I choose ext4 as logical drive cos my primary drive is winxp, the partioner dunno for what reason is showing ext3
[17:25] <mib_uo1mgbbs> can anyone enlighten me?
[17:25] <calc> ugh my laptop just died i think
[17:26] <maxb> mib_uo1mgbbs: ext4 can be misinterpreted as ext3 by things which don't know about ext4 properly
[17:28] <LaserJock> calc: hard drive?
[17:28] <calc> LaserJock: no it just went black showed a bunch of blue crap on the screen then didn't respond, its rebooting ok though
[17:28] <calc> LaserJock: i'm still working on backing up my desktop though
[17:29] <mib_uo1mgbbs> is there a way I can confirm wheteher I'm currently using ext4 or not?
[17:29] <calc> mib_uo1mgbbs: mount?
[17:31] <mib_uo1mgbbs> i need to restart my computer to boot xubuntu
[17:35] <cjwatson> mib_uo1mgbbs: there was a known partitioner bug that may have caused that kind of symptom; make sure you're running an absolutely current daily build
[17:35] <cjwatson> maxb: really shouldn't be relevant in the installer, I believe I've caught everything
[17:37] <cjwatson> mib_uo1mgbbs: if you're encountering this with a current daily build, please don't ... reboot
[17:37] <cjwatson> bah in excelsis
[17:42] <calc> i think the fuse ntfs support is a bit buggy, my drive claimed to be full when i used around half of it
[17:42] <calc> so i reformatted it as ext3
[17:43] <calc> well didn't really claim to be full but refused to allow me to write any more to it in any case
[17:43] <cody-somerville> calc, that could be due to an error causing it to remount as ro
[17:43] <calc> got a bunch of cp: cannot create regular file "foo" Operation not supported messages
[17:44] <calc> hmm maybe it remounted during the middle of the copy, not certain
[17:44] <calc> it copied about 390GB of 500 to do when it showed those
[17:47] <cjwatson> EOPNOTSUPP is rather unusual and does *not* mean "disk full"
[17:48] <cjwatson> ntfs-3g appears to return it basically when it gets garbage requests
[17:48] <calc> hmm ok
[17:48] <calc> it did that for cp and mkdir, etc
[17:57] <cjwatson> Ng: I'm trying to work out what's happening in this bug of yours - it seems that there may be multiple problems
[17:57] <cjwatson> Ng: can you tell me what you did at the ignore/cancel prompt?
[18:00] <siretart> lool: err, how comes that the translations are THAT broken?
[18:00] <Ng> cjwatson: I tried both, neither took me to any kind of disk selection thing, they'd just bounce me to the menu (I assumed that Ignore was thinking I just had a strange disk and I'd fix it up with partman, but partman clearly didn't want to run)
[18:00] <Notch-1> anybody knows what means "unexpectedly too meny pseudo-links" from aufs? i'm using kubuntu intrepid in live mode with persistence file (with both -7 and -9 kernel)
[18:00] <siretart> lool: and does this also happens with the translations provided by upstream?
[18:00] <cjwatson> siretart: separate bug we're investigating
[18:00] <cjwatson> nevertheless it is still a xine bug (and probably a security flaw)
[18:01] <cjwatson> gettext and gcc provide facilities to test for this, which for some reason didn't manage to fire in this case
[18:01] <cjwatson> gcc handles it under -Wformat-security
[18:01] <siretart> users can override the paths gettext uses?
[18:01] <cjwatson> translations should not be considered fully trusted anyway; show me a maintainer who reads every line of every translation they merge
[18:01] <mvo> mdz: a fixed upgrader is now availabe (for the bug you mentioned earlier
[18:02] <Ng> cjwatson: I think my suggestion would be that if partman fails to run and there are other disks in the system, offer to choose one, or maybe add that as a third option in Ignore/Cancel
[18:02] <siretart> sure. I'm just wondering about the severity of the issue. and if that would warrant updating released versions of xine-lib
[18:02] <cjwatson> Ng: Ignore should do just that
[18:02] <lool> siretart: I don't think so
[18:02] <Ng> hrm
[18:02] <cjwatson> it doesn't need a third option which basically just means Ignore
[18:02] <lool> siretart: No
[18:03] <Ng> cjwatson: perhaps it's something special about the disks being under /dev/cciss/ that confuses it?
[18:03] <cjwatson> Ng: I doubt it
[18:04] <cjwatson> siretart: I was under the impression that TEXTDOMAINDIR overrode such things
[18:04] <cjwatson> though I have not checked; but in any case I don't think that's relevant
[18:04] <Ng> cjwatson: hmm, ok. well I've pulled the unused card out of the machine so I could actually install it, so we do have the card floating about and could probably drop it into similar hardware to reproduce it again
[18:04] <cjwatson> Ng: I expect there are multiple bugs here really, I'm just trying to break it down
[18:04] <mdz> mvo: I will test, thanks
[18:06] <cjwatson> Ng: in particular there seems to be a bug in partman's error handling, which is why I asked what you selected
[18:06] <cjwatson> I may have introduced that recently
[18:07] <cjwatson> Ng: after that, partman will have been completely buggered which probably explains the later problems
[18:07] <Ng> ah :)
[18:07] <Notch-1> also, casper seem to boot only if i unplug & replug the pendrive first, otherwise i got dropped to a shell... i'm at 4th trial...
[18:14] <Notch-1> what is casper-snapshot for? i'm reading the man page but still i don't understand :P
[18:17] <Notch-1> it's used to enable the home persistence? or i can simply put a home-rw named empty image to the pendrive and boot?
[18:22] <siretart> lool: 19:18:30 < _ds_> ISTM that the second half of the patch is broken anyway: looks like the wrong xine_log is patched.
[18:23] <siretart> lool: perhaps you could join #xine/oftc and discuss it directly with darren?
[18:31] <Ng> cjwatson: huh, looks like the next machine on my list has the same hardware. Is there anything I can do RightNow to provide more information? otherwise I need to yank that card too ;)
[18:33] <lool> siretart: sure
[18:46] <rtg> kirkland: after selecting the encrypted home option, I'm curious why I still have a .Private ecryptfs mount. Is this expected behavior?
[18:47] <kirkland> rtg: that's where your encrypted data goes
[18:47] <kirkland> rtg: /home/rtg/.Private gets mounted on /home/rtg
[18:48] <rtg> kirkland: What does encrypted home mean? I thought it would supersede .Private
[18:48] <kirkland> rtg: yes
[18:49] <kirkland> rtg: ALL of /home/rtg will be mounted on /home/rtg/.Private
[18:49] <kirkland> rtg: we just need a place to put your encrypted data
[18:49] <kirkland> rtg: and that place is /home/rtg/.Private (for lack of a better place to put it)
[18:49] <rtg> kirkland: that makes my head hurt. how can I mount on a directory that is within the filesystem being mounted?
[18:50] <kirkland> rtg: easily.  by just doing it.
[18:50] <rtg> ugh.
[18:50] <kirkland> rtg: where would you prefer this data?
[18:50] <kirkland> rtg: alternatively, we could mount /home/rtg on top of /home/rtg
[18:51] <rtg> kirkland: no preference, I'm just confused.
[18:51] <kirkland> rtg: but i found that even more confusing
[18:51] <rtg> perhaps my understanding of file name spaces is insufficient.
[18:51] <kirkland> rtg: sorry, am i being to terse?
[18:52] <kirkland> too terse?
[18:52] <kirkland> rtg: when your encrypted home is unmounted
[18:52] <kirkland> rtg: your home data is unvailable
[18:52] <rtg> kirkland: speaking of file names, in what state is Halcrow's filename encryption patch?
[18:52] <kirkland> rtg: your unmount /home/rtg dir is perm'd 500
[18:52] <kirkland> rtg: so you can't write anything inadvertantly there
[18:53] <kirkland> rtg: you have a couple of symlinks in that dir
[18:53] <rtg> kirkland: ok, I'll ssh as root and mess with it.
[18:53] <kirkland> rtg: pointing to your .ecryptfs meta data
[18:53] <rtg> yeah, in /var/lib
[18:53] <kirkland> rtg: and a README.txt telling you that your home data is not mounted
[18:53] <kirkland> rtg: when you do mount your encrypted home dir
[18:54] <kirkland> rtg: the stuff in /var/lib/ecryptfs/rtg is used to basically do:
[18:54] <kirkland> rtg: mount -t ecryptfs /home/rtg/.Private /home/rtg
[18:54] <kirkland> rtg: and then all of your data is decrypted through that mountpoint for you
[18:55] <kirkland> rtg: and .Private is masked from your view
[18:55] <kirkland> rtg: which keeps you from farting around inside of there
[18:55] <rtg> its the mount abstraction that I found confusing. I didn't know you could do that.
[18:55] <kirkland> rtg: yup yup
[18:55] <rtg> cool. how about file name encryption?
[18:56] <Ng> cjwatson: probably unnecessary, but just to confirm, the hardware boots fine post-install if I put the empty controller card back in
[18:56] <kirkland> rtg: i'm pinging tyhicks
[18:56] <cjwatson> Ng: yeah, I'm sure it's just parted. I'm probably not going to do anything more withit until tomorrow though, sorry
[18:57] <kirkland> rtg: it's been the salting of filenames that has given them trouble
[18:57] <Notch-1> excuse me, the .Private dir is really mounted on /home/userhome ?? i tried the encripted home only in ubuntu studio but it seem simply to mount the encrypted dir in /home/userhome/.Private, what i'm missing?
[18:57] <cjwatson> *with it
[18:57] <kirkland> rtg: i'll send tyler an email, and cc you on it, asking for status, and the possibility/difficulty of us carrying it
[18:57] <Ng> cjwatson: that's fine. I may well come back here tomorrow anyway. I'm not done and it's reassuring to be here in person for random acts of madness ;)
[18:58] <kirkland> rtg: <tyhicks> kirkland: I got an email saying they were removed from morton's tree and placed in linus' tree
[18:58] <rtg> Notch-1: don't confuse the Intrepid Private option with Jaunty encrypted home. they look quite similar. Hence the previous discussion.
[18:58] <rtg> kirkland: no shit, I'll go look.
[18:58] <kirkland> rtg: this is without salts
[18:59] <kirkland> rtg: so this is more like "filename obsfucation"
[18:59] <rtg> kirkland: so, encrypted but crackable 'cause all filenames use the same key?
[18:59] <Notch-1> ah ok thanks, so jaunty has the entire home encrypted while intrepid use only the .Private dir, right?
[18:59] <rtg> Notch-1: correct
[18:59] <Notch-1> thanks
[19:00] <Notch-1> excuse me, another flash question: to enable loop-aes i can simply use module-assistant?
[19:00] <rtg> Notch-1: I believe you can choose to _not_ encrypt home, then install ecryptfs-utils later on in order to encrypt just .Private.
[19:00] <rtg> kirkland: true? ^^
[19:01] <calc> interesting it appears sparc wanted to build OOo this time
[19:01] <Notch-1> nono, i prefere entire home encrypted, thanks :P
[19:01] <rtg> Notch-1: well, that has performance implications of you're a developer.
[19:01] <rtg> s/of/if/
[19:03] <Notch-1> you mean with entire home encrypted or with loop-aes module?
[19:03] <rtg> Notch-1: entire home
[19:04] <Notch-1> oh sure, it's not a big deal for me...
[19:05] <kirkland> rtg: that's absolutely true
[19:05] <kirkland> rtg: encrypting just Private will still be supported
[19:05] <kirkland> rtg: useful for auto-login systems, for instance
[19:06] <rtg> kirkland: you'd just about have to for the dist-upgrade case.
[19:06] <kirkland> rtg: where you want to automatically login, but not mount up your documents until you need them
[19:06] <kirkland> rtg: i'm going to *try* and get a live migration script working
[19:06] <kirkland> rtg: i have it written down on paper; not implemented it
[19:06] <kirkland> rtg: will probably hack on it on the plane over to Munich
[19:07] <rtg> speaking of which, we should finalize our plans a bit. phone call next week?
[19:21] <Nafallo> kirkland: hehe. running screen-profiles on my laptop :-)
[19:21] <Nafallo> kirkland: works a lot better since last time I tried.
[19:27] <LaserJock> hmm, CD size must really be tight if we're dumping tracker off for the moment :-)
[19:55] <Keybuk> LaserJock: not really, since it's not even enabled by default
[20:35] <rtg> kirkland: I backported all of the relevant patches to fs/ecryptfs since v2.6.28. Next I'll see if it actually works. Some file name encryption is better then none.
[21:02] <kirkland> rtg: cool, thanks.  keep me posted
[21:02] <kirkland> rtg: also, if you publish a test kernel, i'll gladly try it in a kvm
[21:02] <rtg> kirkland: gimme a bit, its just about done building
[21:04] <rtg> kirkland: I'll send an email later. I'm gonna go catch some rays. its the first sun we've had in a couple of weeks.
[21:04] <kirkland> rtg: sounds fine by me
[21:10] <rtg> kirkland: watch in http://people.ubuntu.com/~rtg/2.6.28-4.11-ecryptfs. the debs are copying, but I haven't tested them. I'll check back in a few hours.
[21:10] <kirkland> rtg: cheers
[21:13] <calc> looks like Seagate might be announcing the 7200.11 problem tomorrow
[21:13] <calc> as of today their tech support still denies there is anything wrong with the drives
[21:16] <calc> if anyone here has a seagate 7200.11 be careful with it as it sounds like the problem may affect the entire line-up
[21:19] <BUGabundo> sebner: ping
[21:19] <BUGabundo> just updated bug 308985
[21:21] <calc> slangasek: ping
[21:21] <DktrKranz> BUGabundo, he's won't be online too often, he's in army right now. He will probably on IRC during weekends, though.
[21:22] <BUGabundo> maybe I got the wrong nick?
[21:22] <BUGabundo> looing for sebastien
[21:22] <BUGabundo> humm seb something!
[21:23] <calc> BUGabundo: its late for seb128 so he may be asleep
[21:23] <BUGabundo> I guess sebner was the 1st and only catch of my auto complete DktrKranz
[21:23] <BUGabundo> thanks calc
[21:23] <BUGabundo> I'll wait for the bug mail
[21:24] <DktrKranz> BUGabundo, heh :)
[21:24]  * BUGabundo blames autocomplete
[21:30] <Keybuk> take *that* lsb_release
[21:37] <BUGabundo> Keybuk: !cat /etc/lsb-release | head -n 2
[21:37] <BUGabundo> DISTRIB_ID=Ubuntu
[21:37] <BUGabundo> DISTRIB_RELEASE=9.04
[21:39] <Keybuk> holy crap
[21:39] <Keybuk> that one little change reduces the boot speed by 6-8s alone!
[21:40] <Keybuk> 54s seems to be the right cut-off point here
[21:40] <Keybuk> 71s in intrepid
[21:40] <Keybuk> so that's 17s faster now ;)
[21:40] <Keybuk> rtg: \o/
[21:43] <slangasek> calc: pong
[21:43] <BUGabundo> Keybuk: here are mine http://fileland.bugabundo.net/fotos/Linux/bootchart
[21:43] <BUGabundo> let me upload the lastest there
[21:59] <calc> slangasek: the disks are still oversized?
[21:59] <BUGabundo> calc: daily are... the alpha3 shouldn't be
[21:59] <BUGabundo> let me check
[22:00] <slangasek> calc: desktop CDs are a little oversized.  We spent the night applying some questionable liposuction techniques, they should be down to size here in the next few hours
[22:00] <BUGabundo> calc: http://cdimage.ubuntu.com/releases/jaunty/ A3 still isn't out
[22:00] <calc> slangasek: ah ok
[22:00] <calc> BUGabundo: yes i know, i was wondering if he needed any more changes for OOo :)
[22:00] <BUGabundo> ahh
[22:01] <BUGabundo> calc: we are getting new packages daily now of OOo from the PPA?
[22:01] <calc> BUGabundo: i think i helped reduce it by ~ 90MB ;-)
[22:01] <BUGabundo> not bad
[22:01] <calc> BUGabundo: no not daily, i was doing them as i updated for jaunty but it became too much work this week, but i should put a new version in ppa for rc2
[22:02] <calc> BUGabundo: iow its far from automated daily ;-)
[22:02] <BUGabundo> calc: I ask because I've been getting packages for the last 3 days
[22:02] <BUGabundo> how is in charge of synaptic?
[22:03] <BUGabundo> or better yet the quick search?
[22:12] <primes2h> ogra: Are you here?
[22:13] <primes2h> ogra: Hello for first...
[22:15] <ogra> primes2h, i was about to cal it a day, wahts up ?
[22:16] <primes2h> ogra: :-) There is a patch that needs to be uploaded in Hardy. bug #211710
[22:17] <primes2h> you commented it  some time ago...
[22:17] <primes2h> Tormod provided a patch for Hardy and he tested it.
[22:17] <ogra> primes2h, oh, right, that somehow drowned in my huge todo list
[22:19] <primes2h> I just subscribed ubuntu-sru but it needs to be uploaded in main, so I asked you...
[22:20] <ogra> i'*ll take care for it (not tonight anymore, but i'll care, promised :) )
[22:21] <james_w> does anyone know if we will have python-central for jaunty?
[22:21] <primes2h> ogra: Thank you very much, do it when you want... :-)
[22:21] <james_w> the new python-central, sorry. 0.6.8?
[22:21] <ogra> thabks for the head up ... i really forgot about it
[22:23] <primes2h> ogra: Don't worry, I can understand you, I usually have a lot of things in my mind and sometimes I face this kind of problem too ;-)
[22:24] <ogra> :)
[22:42] <calc> is there a way to tell cp not to follow mounts?
[22:42] <Mithrandir> -x ?
[22:42] <calc> ah i just searched for the wrong thing, thanks! :)
[22:47] <Keybuk> calc: though that doesn't work on bind mounts, for obvious reasons
[22:51] <kees> hrm, usplash bouncer hangs during input
[23:00] <kirkland> cjwatson: lookey there .... a member of ~rosetta-admins for 3 hours now :-)  i wonder if I can talk you into reviewing the po/pot i submitted for screen-profiles :-P
[23:01] <cjwatson> I'm only there for emergency work
[23:01] <kirkland> cjwatson: (not urgent at all)
[23:01] <kirkland> cjwatson: gotcha, no worries
[23:01] <kirkland> cjwatson: happened to catch your name, and tenure, figured i'd pick on the rookie
[23:01] <cjwatson> yeah, I'm not a regular member, as it were, or you'd be justified
[23:02] <cjwatson> (actually I may not even need my access, will see)
[23:11] <Skiessi> can I ask here for a package to be upgraded?
[23:12] <Skiessi> bristol is a bit out-of-date
[23:15] <directhex> Skiessi, if it's not in Main then here's not the place to ask
[23:15] <Skiessi> okay
[23:28] <kees> Keybuk: so, the new udev doesn't respect the old saved interface names?
[23:28] <Keybuk> it should do
[23:29] <kees> Keybuk: ah! hm. it moved my eth0 to eth5 because the kernel driver name changed.
[23:29] <kees> er, no...
[23:30] <kees> wtf happened.
[23:30] <Keybuk> pastebin < 70-persistent-net.rules
[23:31] <kees> I will, need to get the net back up on that machine
[23:31] <kees> where is ifrename go?
[23:31] <kees> s/is/did/
[23:33] <Keybuk> it went away
[23:34] <Keybuk> to the darkest, blackest pit from whence yada came
[23:35] <Keybuk> (if it had a command-line "rename this interface to this" mode, it might have stayed around - but it was expressly written as a boot time thing with conffile, so we dropped it in favour of udev renaming)
[23:35] <kees> I liked having it around.  means I can't set device names without rebooting.  :(
[23:36] <slangasek> kees, jdstrand: how do you feel about dropping openssl-blacklist as an ssl-cert dep in jaunty?
[23:37] <kees> slangasek: makes me sad, but I leave it to cjwatson's discretion
[23:37] <jdstrand> slangasek: IIRC openssh-blacklist was already downgraded to Suggests?
[23:37] <cjwatson> openssh-blacklist going away made me sad too
[23:37] <cjwatson> but I think we had no choice
[23:37] <slangasek> kees: well, the only thing ssl-cert uses it for is checking the integrity of the local snakeoil key, yes?
[23:38] <jdstrand> slangasek: yes
[23:38] <kees> Keybuk: http://pastebin.osuosl.org/23327
[23:38] <kees> slangasek: oh! I misread.  ssh/ssl
[23:38] <kees> slangasek: is it a CD space issue?
[23:38] <cjwatson> Keybuk: I thought it did have such a command-line mode. I must be misremembering
[23:38] <kees> Keybuk: note eth0 vs eth5
[23:38] <jdstrand> heh.. openssl-blacklist is pretty big
[23:39] <slangasek> jdstrand, kees: so anybody who hasn't been ignoring security updates in 8.04 for 9 months, or has upgraded to intrepid, already has the fix; the only case not covered is "people who never install security updates and are going to jump straight to 10.04 LTS"
[23:39] <slangasek> kees: yes, CD space
[23:39] <kees> Keybuk: it did have a "rename this interface to this" mode.  that's what I used it fore.
[23:39] <slangasek> Keybuk: I wonder where I'm expected to have seen these parport errors in intrepid :)
[23:39] <kees> slangasek: right, which was the logic with the ssh blacklist too.  seems like it follows to move it to suggests for ssl too.  jdstand?
[23:40] <slangasek> well, if we drop it below a depends, the ssl-cert postinst can't use it anymore
[23:40] <kees> Keybuk: though I did have to run it with -c /dev/null or something
[23:40] <slangasek> so we might as well drop it out completely; other packages that use ssl certs still depend on it, e.g. openvpn
[23:40] <jdstrand> slangasek, kees: I'm ok with it
[23:41]  * slangasek pounces
[23:41] <kees> Keybuk: yeah,  ifrename -c /dev/null -i OLDif -n NEWif
[23:42] <kees> Keybuk: anyway, that doesn't matter so much atm.  do you have any idea what caused the problem with my net rule?
[23:45] <slangasek> kees, jdstrand, cjwatson: should we maybe leave a debconf note in place, so that if the user *was* still upgrading from an old version of ssl-cert, they at least get a warning?
[23:47] <jdstrand> slangasek: seems a long shot that no updates were made in those two years, but it would probably be best
[23:47] <cjwatson> slangasek: if it's straightforward to detect the situation without the blacklist, yes
[23:47] <jdstrand> slangasek: actually-- isn't an upgrade required before doing a do-release-upgrade?
[23:48] <slangasek> cjwatson: yeah, that code is already there, I just have to drop the one extra 'if' before displaying the debconf question
[23:48] <slangasek> jdstrand: sure.  There are still users that bypass do-release-upgrade, though.
[23:49]  * jdstrand nods
[23:51] <Nafallo> o/
[23:51]  * Nafallo hides and ponders if he should looking at why he isn't using it :-P
[23:53] <slangasek> yes, you should ;)
[23:55]  * Nafallo grabs code
[23:56]  * ogra prefers update-manager
[23:59] <Nafallo> ogra: I don't use x on servers I'm afraid ;-)
[23:59] <ogra> pffft


[12:26] <AlanBell> IdleOne: looks like it will be in the unity menu in oneiric, the patch to remove it is not there now
[12:26] <AlanBell> same for orca, that is back in the menus
[12:29] <Pendulum> \o/
[12:45] <AlanBell> all you have to do is find it in unity somewhere /o\


[10:22] <ev> mpt: http://people.canonical.com/~evand/screenshots/ubiquity/2.7.10
[10:23] <CIA-14> tasksel: cjwatson * r1467 ubuntu/ (6 files in 3 dirs): Add Lubuntu tasks.
[10:24] <CIA-14> tasksel: cjwatson * r1468 ubuntu/ (debian/changelog ubuntu-seeds.pl):
[10:24] <CIA-14> tasksel: Use 'bzr branch' rather than 'bzr get'; the latter is apparently
[10:24] <CIA-14> tasksel: deprecated in bzr 2.4.
[10:25] <CIA-14> tasksel: cjwatson * r1469 ubuntu/debian/changelog: releasing version 2.88ubuntu5
[10:59] <cjwatson> bdmurray: perhaps similar, but the fix does need to be different - casper needs to tweak things to avoid running update-grub
[11:00] <cjwatson> bdmurray: (similarly, 703009 can be avoided by running grub-install in a chroot for recovery)
[11:02] <cjwatson> ev: could you build wubi r223, please?  (includes jibel's noninteractive mode)
[11:02] <ev> yup, on it now
[11:09] <ev> done
[11:12] <cjwatson> ta
[11:16] <cjwatson> ev: any news on bug 644198?
[11:16] <ubot2> Launchpad bug 644198 in ubiquity "Ubuntu LIve Cd does not enable bluetooth before choice menu in live-cd" [High,Confirmed] https://launchpad.net/bugs/644198
[11:17] <ev> oh, I haven't looked into that yet
[11:18] <cjwatson> just wondering 'cos you milestoned it for a1
[11:18] <ev> should I bump the priority for it in my brain?
[11:18] <ev> ah, I'll move it back a bit
[11:31] <davmor2> hmm different todays iso drops me straight into cli
[11:32] <davmor2> yay thrid time lucky
[11:37] <davmor2> ev: the install top menu bar is still light grey should it be black again now?
[11:38] <ev> yeah, I noticed that as well
[11:38] <ev> I'll have a look once we're in FF
[11:38] <davmor2> ev: no probs want a bug for it?
[11:40] <cjwatson> straight into cli> I blame lightdm (possibly unfairly)
[11:41] <cjwatson> my network has been even more terrible than usual lately so I can't check - will have to make sure to sync up all my ISOs at the rally
[11:44] <ev> davmor2: sure, thanks
[11:45] <cjwatson> oneiric-desktop-i386.iso
[11:45] <cjwatson>    104249544  13%   58.66kB/s    3:05:33
[11:45] <cjwatson> I mean, for pity's sake
[11:48] <davmor2> cjwatson: don't try blaming pitti he's got nothing to do with it ;)
[15:55] <charlie-tca> looking for a little help with bug 799238
[15:55] <ubot2> Launchpad bug 799238 in casper "Xubuntu amd64 20110618 xserver abort" [Medium,Triaged] https://launchpad.net/bugs/799238
[15:56] <charlie-tca> It is blocking the Xubuntu live desktop sessions
[16:02] <cjwatson> charlie-tca: try #ubuntu-x
[16:02] <charlie-tca> okay