[12:08] <theCore> which version of gstreamer will be in Edgy? any plans yet?
[12:13] <HiddenWolf> theCore, probably the latest upstream stable version at that time
[12:15] <theCore> ah ok, it's what I was thinking
[12:16] <theCore> HiddenWolf: thanks
[12:22] <Keybuk> mdz: https://merges.ubuntu.com/main.html
[12:40] <Keybuk> siretart: ping
[12:59] <siretart> Keybuk: pong
[01:00] <Keybuk> siretart: universe merges now up
[01:00] <Keybuk> mdz: https://merges.ubuntu.com/universe.html
[01:01] <siretart> Keybuk: w00t! :)
[01:01] <siretart> gn8
[01:02] <ogra> will edgy still have gcc-4.0 available in main ?
[01:03] <Keybuk> ogra: doubtful
[01:03] <Keybuk> I think it's already in universe :p
[01:03] <ogra> ok
[01:32] <zul> hey
[02:22] <Evaso2> hi guys how could be debugged acpi s3 sleep mode that doesn't wake up on a fujitsu notebook for help ubuntu developping?
[03:22] <ogra> mdz, ping ? 
[03:22] <mdz> ogra: pong
[03:23] <otavio> ogra: hi
[03:23] <ogra> mdz, otavio is poking me about upstream status in ltsp and package versioning
[03:23] <jsgotangco> eh? still awake?
[03:23] <ogra> jsgotangco, i just megred gcompris ... uploading it takes ~2h ;)
[03:24] <jsgotangco> yeah i saw the -changes list
[03:24] <ogra> otavio, probably outline your idea to mdz ...
[03:24] <mdz> otavio: yes?
[03:25] <otavio> mdz: current way that ltsp source is now allow us to unify the development between Debian and Ubuntu
[03:26] <ogra> which happens on a bzr level anyway
[03:26] <otavio> mdz: I was asking ogra if we could upload to Debian and Ubuntu sync with Debian to get the versions since Ubuntu has a way to get it easily then us.
[03:26] <otavio> mdz: and then we can all work on same codebase
[03:26] <ogra> which again happens on a bzr level anyway ...
[03:26] <mdz> otavio: it's a good idea to have a single mainline where we can all work
[03:26] <otavio> yes
[03:27] <otavio> mdz: that's what I want to have
[03:27] <mdz> otavio: where and when it gets uploaded to distributions should be a separate issue
[03:27] <otavio> mdz: since Debian doesn't allow different suite names in changes files might make our life easy
[03:27] <mdz> the way this will work in the future is that the LTSP project will roll official tarballs and they will be packaged for Debian and Ubuntu independently
[03:28] <mdz> however, the migration to the new codebase is not complete yet
[03:28] <otavio> mdz: but currently the source is unique for both
[03:28] <otavio> mdz: there's few changes on it
[03:28] <mdz> so meanwhile, I suggest that ogra roll official tarballs for you
[03:28] <otavio> mdz: basically debian/control only
[03:29] <ogra> otavio, thats because we didnt start feature development yet
[03:29] <mdz> the packaging should be kept separate from the mainline
[03:29] <ogra> otavio, after the merge phase is done there will be daily changes to the source
[03:29] <otavio> ogra: well but since all will be done in plugins, basically, we can follow it easier, no?
[03:29] <mdz> otavio: make sense?
[03:30] <otavio> mdz: so you mean that we both (Ubuntu and Debian) might use an "official" tarball as base and this to be the mainline?
[03:30] <mdz> otavio: yes.  soon that tarball will be used by other projects as well
[03:31] <mdz> and so we should have a separation between upstream development and packaging
[03:31] <otavio> mdz: so we both change to 0.XX-Y version format?
[03:31] <ogra> otavio, i mailed pkg-ltsp-devel about it 
[03:31] <mdz> otavio: yes
[03:31] <ogra> with links to all the specs 
[03:31] <otavio> mdz: is ok to me
[03:31] <otavio> ogra: I saw it
[03:31] <ogra> including the tarball stuff :)
[03:31] <mdz> we should start to migrate away from native packaging
[03:32] <otavio> ogra: but then we both might start an upstream branch now
[03:32] <ogra> otavio, no
[03:32] <otavio> ogra: why?
[03:32] <ogra> otavio, we both start distro branches
[03:32] <mdz> it causes unnecessary complications and isn't appropriate for a project which is used elsewhere
[03:32] <ogra> and have an additional upstream branch we base on
[03:32] <otavio> where's the baes branch now?
[03:32] <ogra> which also might contain gentoo or redhat stuff we both dont use
[03:32] <otavio> is it your devel?
[03:32] <ogra> yep
[03:33] <otavio> ogra: please, rename it :P
[03:33] <otavio> ogra: make it clear :P
[03:33] <otavio> hehe
[03:33] <ogra> ok, no problem
[03:33] <ogra> mane suggestions ? 
[03:33] <ogra> *name 
[03:33] <otavio> upstream?
[03:33] <ogra> fine ...
[03:33] <otavio> to make it very clear :P
[03:34] <otavio> and I, in Debian side, can make an upstream-fixes
[03:34] <ogra> it will be "ltsp mainline" in launchpad anyway :)
[03:34] <otavio> so use mainline
[03:34] <otavio> so to people used in launchpad is clear
[03:35] <ogra> yep
[03:35] <otavio> where you'll make tarballs available?
[03:35] <ogra> thats wh its not registered yet (i mentioned that in the mail as well)
[03:35] <otavio> humm
[03:36] <ogra> i think i'll start off on people.ubuntu.com/~ogra
[03:36] <ogra> if we see everything works as expected it should move somewhere else
[03:36] <ogra> humm ?
[03:36] <otavio> well, do it as soon as possible so I can add a watch file to get it in an automated way
[03:36] <ogra> yep
[03:37] <ogra> i have 13 packages on my merge list atm ... if i'm done with these and sbalneav is up to speed with bzr (we have a crash curse tomorrow) i'll make it work
[03:38] <ogra> *course
[03:38] <otavio> crash course? what's it?
[03:38] <ogra> an intorduction into bzr 
[03:38] <mdz> ogra: just call it 'main' or 'mainline'
[03:38] <otavio> will it be online and open? or will it be closed?
[03:38] <ogra> well, we had an intorduction already ... rather the advanced part :)
[03:39] <ogra> mdz, mainline is fine
[03:39] <otavio> mdz: mainline looks better
[03:39] <mdz> fine
[03:39] <mdz> just not upstream :-)
[03:40] <ogra> otavio, he wanted to do it via teamspeak or some voice media ... we agreed to meet in #edubuntu ~13:00 UTC
[03:40] <otavio> ogra: will the course be open?
[03:40] <ogra> i guess we can also do it via irc
[03:40] <mdz> ogra: have you invited someone from the bazaar team?
[03:41] <ogra> otavio, well i dont think i'll teach anything you dont know already, but we can hold it in a public irc channel if sbalneav doesnt mind irc
[03:41] <ogra> mdz, its about the basics ...
[03:41] <mdz> ogra: please ask for someone to be there
[03:41] <ogra> oki
[03:41] <otavio> ogra: ah ok
[03:42] <otavio> ogra: i'm interested  to learn more about bzr :-D
[03:42] <otavio> ogra: is always good to learn ;-)
[03:42] <ogra> otavio, yeah, thats true :)
[03:42] <bddebian> Heya folks
[03:43] <otavio> ogra: how the branch merging in launchpad side works? 
[03:44] <otavio> ogra: how the fixes and other branches will be merged there?
[03:46] <ogra> otavio, i guess i'm not the best to ask about that yet i didnt use the merge stuff there yet ... #launchapd will be able to tell you
[03:47] <otavio> ogra: right
[07:39] <pitti> Good morning
[07:43] <Hobbsee> hi pitti 
[07:43] <pitti> Hi Hobbsee 
[07:44] <ajmitch> hi pitti 
[07:44] <ajmitch> heh
[08:08] <Hobbsee> ogra: ping?
[08:11] <fabbione> morning
[08:11] <Hobbsee> hi fabbione :)
[08:12] <fabbione> hello there :)
[09:37] <nomed> hi all
[09:37] <nomed> Mithrandir, around
[09:40] <Mithrandir> nomed: hi
[09:40] <nomed> hi Mithrandir 
[09:40] <nomed> i was reading the new specs for edgy
[09:40] <nomed> LiveCDStackedFileSystem
[09:41] <nomed> in particular
[09:41] <nomed> i ported my initramfs scripts to use casper a while ago ..
[09:41] <nomed> and they works nicely ..
[09:42] <nomed> for dapper i needed to recompile the squashfs module
[09:42] <nomed> as there is a critical bug 
[09:42] <nomed> it doesn't support unified squashfs "layers" 
[09:43] <nomed> mainly i'd like to help if possible
[09:43] <Mithrandir> we're going to use unionfs, so that should still just work.
[09:43] <nomed> have you already some code ?
[09:43] <nomed> Mithrandir, not if u use unionfs + squashfs from dapper
[09:43] <infinity> Which we won't.
[09:43] <infinity> Since the spec is for edgy.
[09:44] <nomed> anyway .. this is edgy  stuff
[09:44] <Mithrandir> nomed: I've tested it and it worked fine for me, at least.
[09:44] <nomed> infinity, yep
[09:44] <nomed> Mithrandir, the issue appears randomly
[09:45] <nomed> it should be explained in squashfs log
[09:45] <nomed> (cvs)
[09:45] <Mithrandir> well, if it's fixed it shouldn't be a problem, then
[09:45] <infinity> Anyhow, tell me more about this "squashfs layers" thing?  Is that part of the squashfs driver itself?
[09:46] <nomed> infinity, yes
[09:46] <infinity> That may be more stable than stacking 5 unionfses...
[09:46] <Mithrandir> infinity: we'd still need unionfs, though.  But yeah, we should investigate it.
[09:47] <Mithrandir> nomed: care to add relevant information to the end of the spec, preferably including a link to some page explaining layered squashfs-es sans unionfs?
[09:47] <infinity> Mithrandir: Yeah, given our past experiences, one union sounds less scary to me than several, that's all. :)
[09:49] <nomed> infinity, http://squashfs.cvs.sourceforge.net/squashfs/squashfs/kernel/fs/squashfs/
[09:50] <nomed> it seems fixed .. and i'm testing it .. 
[09:50] <nomed> Mithrandir, anyway .. what i'd love to know is:
[09:51] <nomed> how do u use the apt db file when u have n layers ?
[09:51] <infinity> The layers have to be used in order.
[09:51] <infinity> We aren't doing arbitrary mixing and matching.
[09:52] <infinity> (Not in this spec, anyway.. That will take way more thought and effort)
[09:52] <nomed> infinity, k
[09:52] <infinity> So, on the buildds, I'll build the base layer, then mount it and build the desktop layers on top, then mount those and build the live layers on top.
[09:52] <nomed> so i can continue playing with it :)
[09:52] <infinity> Then mount THOSE and do the langpack layer for the DVD.
[09:53] <nomed> infinity, yep .. that's what i'm doing to ..
[09:53] <nomed> but i split the apt db file in many pkge.status
[09:54] <Mithrandir> the dpkg db is more important than the apt lists.
[09:54] <nomed> Mithrandir, yes .. i mean /var/lib/dpkg/status
[09:56] <infinity> I *think* we could pull some merge-avail tricks to mix arbitrary layers, so long as we're careful not have stuff in Layer 07 dpkg-diverting files from Layer 04 and such.
[09:56] <infinity> That's where it would get really messy.
[09:57] <infinity> (merge-avail isn't meant to be used to merge status files, but it could be mangled a bit to do so, I'm sure)
[09:58] <infinity> Anyhow, unless someone has copious free time to hack on that, I think arbitrary mixing is out of scope for edgy, and shooting for pre-ordered stacked filesystems is sufficiently cool to keep us happy until edgy+1.
[09:59] <Mithrandir> infinity: unless somebody gives me a load of well-tested, reviewed code which does arbitrary mixing, we won't do it, no.
[10:00] <infinity> Mithrandir: I have a general idea about how I'd do it, but I doubt I have the time to do it in work hours or the motivation to do it in my spare time.
[10:00] <nomed> infinity, Mithrandir i was using layers since breezy devel version
[10:01] <nomed> i was using yuch + deliver .. something similiar to casper
[10:01] <Mithrandir> infinity: dpkg is just one application which would be affected, though.  Think about some crazy people making exim.squashfs and postfix.squashfs.  Those'd need to conflict.  Joy!
[10:01] <nomed> now that casper exists .. and makes the job 
[10:01] <nomed> i guess that's were i'd like to focus
[10:02] <nomed> so if u have a guideline .. i guess i could play with it
[10:02] <infinity> Mithrandir: Well, that's easy enough to deal with, really.
[10:02] <Mithrandir> infinity: "don't"?
[10:03] <infinity> Mithrandir: It'd have to be a two-step process anyway, since you need to read into the squash to get the status files, before you overlay them (leaving only one visible)
[10:03] <infinity> Mithrandir: So, in the process of reading into the status files to merge them, you evaluate conflicts and disallow mounting those two together.
[10:03] <Mithrandir> aiee.
[10:03] <Mithrandir> painful.
[10:03] <infinity> I knew you'd like that.
[10:04] <Mithrandir> reimplement dpkg in shell.  Mmmm.
[10:04] <Mithrandir> that'll be.. fast.
[10:04] <infinity> Nah, this is the Killer Feature that will finally push someone to break out libdpkg. :)
[10:05] <infinity> (What are you doing on the weekend?)
[10:05] <fabbione> lol
[10:05] <Mithrandir> Celebrating Karianne's birthday. :-P
[10:06] <infinity> Well, that does sound a bit more fun...
[10:07] <sivang> morning everybody!
[10:08] <Hobbsee> hi sivang 
[10:08] <sivang> hi Hobbsee !
[10:15] <lucas> somebody has a script to file a "request sync" bug ?
[10:17] <fabbione> sivang: luckly you still have a computer.. and a gpg key
[10:19] <Hobbsee> fabbione: whatever happened to your computer?
[10:20] <sivang> fabbione: my dear fabbione, what happend to your machina ?
[10:20] <fabbione> Hobbsee: to my computer? nothing..
[10:20] <fabbione> sivang: machina = car :) nothing yet...
[10:20] <pitti> lucas: yes, I have
[10:21] <fabbione> Hobbsee: sivang has a long story about gpg keys.... ;)
[10:21] <pitti> lucas: http://people.ubuntu.com/~pitti/scripts/requestsync
[10:21] <Hobbsee> fabbione: ahhh...right...
[10:21] <pitti> lucas: it needs a local MTA, otherwise you have to change the smtp call to add a host name
[10:21] <lucas> thanks
[10:21] <sivang> fabbione: and the gpg key? :)
[10:22] <infinity> sivang: He's referring to YOU leaving your laptop and GPG key unprotected in Montreal.
[10:22] <infinity> sivang: Short memory? :)
[10:22] <fabbione> infinity: so it seems :)
[10:22] <sivang> infinity: nah, I recall that quite strongly. I don't think I will ever forget it :-) However, I did not create the association between what he said and this incident :p
[10:23] <fabbione> infinity: to be fair...
[10:23] <fabbione> "He's referring to YOU leaving your laptop and GPG key unprotected in Montreal" + and a bastard like him passing by
[10:24] <infinity> fabbione: A bastard?  You?  That seems unfai-- Wait, no, that's fair. :P
[10:24] <fabbione> right.. bastard inside and outside :D
[10:25] <Hobbsee> haha
[10:25] <ghee22> anyone familiar with mono's read & write with ubuntu?  I'm getting a very strange compile error
[10:25] <Hobbsee> sivang: um, stupid question, but you didnt leave the passphrase there as well did you?
[10:25] <infinity> Hobbsee: "What's a passphrase?"
[10:25] <fabbione> Hobbsee: don't turn the knife in the wound... it hurt ;)
[10:26] <pitti> warning to all: if you dist-upgrade edgy, make sure you do not upgrade sudo
[10:26] <Hobbsee> infinity: oh holy sugar.
[10:26] <sivang> pitti: interesting :)
[10:26] <Hobbsee> that is shocking.
[10:26] <fabbione> pitti: hem.. halt.. is it ok if i have a root passwd?
[10:26] <pitti> fabbione: yes
[10:26] <fabbione> ok
[10:26] <fabbione> thanks
[10:26] <Hobbsee> fabbione: sudo's broke, i believe
[10:26] <pitti> fabbione: sudo is broken; I wanted to fix the merge today, but Scott uploaded the merge already
[10:27] <fabbione> Hobbsee: you may never know HOW broken it is
[10:27] <Hobbsee> fabbione: that's why i havent dist-upgraded yet
[10:27] <Hobbsee> i'm not sure i want to
[10:27] <sivang> Hobbsee: I did not leave the passphrase anywhere near. But I suspect it was not strong enough. In either way, fabbione did not find it out IIRC, but just leaving the machine unlocked with access to gpg --edit-keys is enough to let an attacker try and break it if it's not strong enough
[10:28] <Hobbsee> sivang: ah.  ouch. true.
[10:28] <StevenK> Hobbsee: hold sudo, then
[10:28] <fabbione> sivang: hem.. well how did i add the "You are 0wn3d" comment in your key without a passphrase?
[10:29] <fabbione> brb
[10:29] <Hobbsee> hehe - i think we scared him.
[10:29] <sivang> heh
[10:29] <sivang> anyway, back to productive things :-)
[10:30] <jsgotangco> lol
[10:43] <pitti> infinity: yay, Debian has gnutls13 and 12 doesn't build all packages any more. happy transition...
[10:45] <infinity> pitti: Does everything build against 13?  I recall talking to vorlon about it a month or two ago, and they weren't going to move on 13 until the archive was happy with it.l
[10:45] <pitti> infinity: no idea
[10:45] <pitti> infinity: I just saw the current merge diffs and wasn't quite happy
[10:46] <pitti> infinity: in fact, Debian seems to have reverted the libtasn security fix
[10:46] <pitti> so we shouldn't touch our libtasn1-2 and gnutls12 packages for now
[10:46] <infinity> pitti: Joy.
[10:46] <pitti> (tasn broke the abi in the security fix, and gnutls12 needed a patch to cope with that)
[10:47] <pitti> I need to investigate this more closely, but my feeling is that we should just wait until Debian sorted that out
[11:05] <elmo> dpkg-divert: rename involves overwriting `/usr/bin/ldd' with different file `/usr/bin/ldd.amd64', not allowed
[11:05] <elmo> anyone seen that during a dapper amd64 upgrade?
[11:06] <jamesh> yeah
[11:06] <jamesh> I think I ended up manually renaming /usr/bin/ldd.amd64 to /usr/bin/ldd
[11:07] <jamesh> or deleting ldd.amd64 (whichever one was newer)
[11:07] <elmo> jamesh: did you file a bug or was there already one?
[11:08] <jamesh> elmo: I think there was already a bug open about it
[11:08] <doko> never seen that, dapper->edgy, or breezy->dapper upgrade
[11:08] <elmo> god why do we not sort distributions by popularity
[11:09] <elmo> https://launchpad.net/distros/ubuntu/+source/ia32-libs/+bug/48299
[11:09] <Ubugtu> Malone bug 48299 in ia32-libs "Upgrade from ia32-libs ubuntu17  to ubuntu19 fails" [High,Confirmed]  
[11:10] <elmo> doko: anything I can usefully do while I still have the machine in this state?
[11:13] <jamesh> elmo: https://launchpad.net/distros/ubuntu/+source/ia32-libs/+bug/45705 <- see infinity's comment
[11:13] <Ubugtu> Malone bug 45705 in ia32-libs "Error in Dist-upgrade on Dapper" [Medium,Rejected]  
[11:14] <elmo> which is nice, except completely untrue
[11:14] <elmo> this machine is and always has been breezy only
[11:14] <elmo> (or at least <= breezy)
[11:14] <elmo> and always using released suites
[11:14] <jamesh> seems that I deleted /usr/bin/ldd which let the thing upgrade
[11:16] <doko> ia32-libs tries to remove the diversion in the preinst: dpkg-divert --quiet --rename --divert /usr/bin/ldd.amd64 --package ia32-libs --remove /usr/bin/ldd
[11:16] <doko> so how does the diversion look like?
[11:21] <elmo> diversion of /usr/bin/ldd to /usr/bin/ldd.amd64 by ia32-libs
[11:21] <elmo> james@asuka:~$ dpkg -S /usr/bin/ldd
[11:21] <elmo> diversion by ia32-libs from: /usr/bin/ldd
[11:21] <elmo> diversion by ia32-libs to: /usr/bin/ldd.amd64
[11:22] <pitti> Keybuk: btw, what do the different colours mean on the merging status page?
[11:22] <elmo> -rwxr-xr-x 1 root root 5158 Jul 21  2005 /usr/bin/ldd
[11:22] <elmo> -rwxr-xr-x 1 root root 5972 May 21 18:22 /usr/bin/ldd.amd64
[11:24] <Keybuk> pitti: package priority
[11:26] <pitti> ah
[11:26] <infinity> elmo: Feh.  I couldn't reproduce it in a breezy chroot, doing breezy->dapper.  I'm positive the package IS still buggy, but I was fairly sure it wouldn't trip in that case.
[11:27] <tseng> infinity: can you please kick muine on i386/ppc?
[11:27] <infinity> elmo: Err, wait.  You have a /usr/bin/ldd owned by nothing?  That's kinda special.
[11:27] <tseng> infinity: or is that more automated now
[11:27] <elmo> and I am being particularly stupid, or what?   how is ldd not the diverted version?
[11:28] <infinity> tseng: I'll look at 'em.
[11:28] <tseng> infinity: thanks.
[11:28] <Keybuk> pitti: it seemed an arbitrary way to sort and break up the table ;)
[11:28] <tseng> amd64 says "chroot problem", I am asuming that is known
[11:29] <elmo> infinity: oh, no it's "owned" by libc6
[11:29] <elmo> but that's a lie AFAICT
[11:29] <elmo> libc6: /usr/bin/ldd
[11:29] <elmo> but the md5sum doesn't match the ldd of the nominally installed libc6 package
[11:29] <infinity> elmo: ldd.amd64 should, I suspect.
[11:30] <TheMuso> Keybuk: Are you aware that the grab-merge script doesn't work properly when attempting to unpack package sources with colons in their version number?
[11:30] <elmo> infinity: ah, duh, right
[11:31] <infinity> elmo: Anyhow, I think this probably warrants a release to -updates with a more correct fix (I handed one to mdz pre-release, but he deemed it too intrusive)
[11:31] <elmo> infinity: ok, so you know what the fix is?
[11:31] <infinity> elmo: If you can dump yout dpkg -l output to the bug log before you fix it manually (just delete /usr/bin/ldd, then continue the upgrade), that would be appreciated.
[11:31] <infinity> s/yout/your/
[11:32] <Keybuk> TheMuso: yes
[11:32] <infinity> s/dpkg -l/dpkg -S/
[11:32] <elmo> the rejected bug or the new one?
[11:32] <infinity> elmo: Yeah, I know how to do it more correctly, but amunition in the form of a "me too" from you will help push the update in.
[11:32] <infinity> elmo: Whichever.  Reopen the rejected one and dupe the new onr against it, if you're feeling Maloney.  Otherwise, do whatever you want. :)
[11:33] <TheMuso> Keybuk: Ok.
[11:35] <infinity> Ahh, good, I still have my proposed pre-release diff.
[11:35] <infinity> elmo: I'll push it in to updates before I go VAC, if I get approval.
[11:35] <elmo> infinity: cool, thanks
[11:36] <infinity> elmo: Thanks for reminding me.  Outstanding bugs get flushed from my cache post-release.
[11:38] <sivang> hi ogra 
[11:38] <elmo> "There are other bugs already marked as duplicates of Bug 48299. These bugs should be changed to be duplicates of another bug if you are certain you would like to perform this change."
[11:38] <Ubugtu> Malone bug 48299 in ia32-libs "Upgrade from ia32-libs ubuntu17  to ubuntu19 fails" [High,Confirmed]  http://launchpad.net/bugs/48299
[11:40] <thom> elmo: was that english?
[11:40] <Hobbsee> hey ogra. ping?
[11:41] <elmo> thom: launchpadese
[11:41] <jsgotangco> lol
[11:42] <sivang> heh
[11:43] <infinity> elmo: Yeah, Malone doesn't allow dupe chains, and I have NO idea why.
[11:44] <Hobbsee> infinity: because dupe chains are evil?
[11:44] <infinity> Hobbsee: Not inherently.
[11:44] <infinity> Hobbsee: Assuming the UI can follow the chains, it's all the same to the end user.
[11:45] <Hobbsee> infinity: that's true. 
[11:45] <Hobbsee> i think.
[11:47] <slomo_> hrm, my /etc/sudoers was broken by the sudo upgrade yesterday =)
[11:48] <sivang> slomo_: pitti noted to not upagrade sudo some time ago. If you have a root password it's also okay IIRC
[11:48] <sivang> slomo_: (that is , to hold it back)
[11:48] <slomo_> sivang: i don't have one... i'll boot from a livecd now and fix it ;) brb
[11:49] <sivang> slomo_: using edgy right ?
[11:49] <thom> slomo_: just boot in rescue mode
[11:50] <slomo_> thom: is this also possible without using the livecd? how?
[11:50] <tseng> slomo_: go to grub
[11:50] <tseng> slomo_: go to Your Kernel (Rescue Mode)
[11:50] <tseng> it will put you in single user
[11:51] <tseng> root shell
[11:51] <slomo_> tseng: i use lilo because of xfs... hm, i wonder if i have an entry for that in lilo :)
[11:51] <tseng> oh..
[11:51] <tseng> oops
[11:51] <tseng> well
[11:51] <tseng> can you edit the kernel command line in lilo?
[11:51] <tseng> at boot time
[11:51] <StevenK> Yes.
[11:51] <tseng> so add "single" to the end
[11:51] <slomo_> ok, thanks
[11:51] <slomo_> brb
[11:52] <Kamion> woo, working anastacia
[11:52] <infinity> Do I even want to look?
[11:53] <infinity> Oh, that's not bad.
[11:53] <tseng> I cant figure out how to unstuff sudo
[11:53] <infinity> Kamion: I suspect it'll get scarier if/when hppa catches up...
[11:53] <Kamion> nod
[11:53] <Kamion> any updated ETA for that?
[11:54] <infinity> I prodded jbailey, who's prodded upstream, who claims to have patches more or less ready, but we need some time to eyeball and run them through a test cycle.
[11:54] <infinity> If I had to guess, I'd say we'd have glibc on hppa good to go in ~2 weeks.
[11:55] <infinity> (But Jeff's guess would be better than mine, since I'm not directly involved in Linux/PARISC upstream)
[11:56] <Kamion> The way type-handling is being pulled into main is freaky.
[11:56] <Kamion> Apparently it Provides: linux ...
[11:56] <infinity> It always has, though.. Hasn't it?
[11:57] <infinity> Yeah, it has.
[11:57] <Keybuk> is it not blacklisted?
[11:57] <Kamion> nop
[11:57] <Kamion> nope
[11:57] <Keybuk> iirc. blacklisting was invented in germinate for type-handling
[11:57] <Kamion> the version in dapper did provide linux though
[11:57] <Keybuk> it kept showing up when I didn't want it to
[11:57] <Kamion> (breezy's didn't)
[11:57] <Kamion> never been blacklisted as far as I'm aware
[11:58] <elmo> I should hack drescher's kernel to oops if it sees a file with a path of pool/main/t/type-handling
[11:58] <pitti> Riddell: ping
[11:59] <Kamion> as far as I can see germinate doesn't actually do anything useful with the blacklist other than reporting on it
[11:59] <Kamion> could be I broke that although I don't remember doing so
[11:59] <fabbione> elmo: LOL
[11:59] <Kamion>             if src in self.blacklist and src not in self.blacklisted:
[11:59] <Kamion>                 self.blacklisted.append(src)
[11:59] <infinity> Kamion: The more bizarre thing, though, is that germinate should prefer the real "linux" package over the virtual one, no?
[11:59] <Hobbsee> pitti: FYI he's speaking somewhere or other? UKUUG?
[11:59] <Kamion> that's the only bit that actually cares, and it doesn't stop the package being processed
[11:59] <infinity> Kamion: Is it dropping "linux" because it's uninstallable?
[11:59] <pitti> Hobbsee: ah
[12:00] <infinity> Kamion: Cause that's an easy fix. :)
[12:00] <Kamion> oh, I suppose that could be
[12:00] <Hobbsee> pitti: he said it was too bad if kde wasnt fixed by the time he left - that we couldnt have a fix :P
[12:00] <mvo> Riddell: does the kde screensaver has a similar command as xscreensaver-command ? I need a way to stop it
[12:01] <Hobbsee> mvo: see my note to pitti 
[12:01] <Hobbsee> mvo: if you tell me what the xscreensaver-command is , i can check it for you
[12:02] <mvo> Hobbsee: xscreensaver-command is a way to tell the screensaver what to do. there is e.g. -exit to stop it or -activate to make it active
[12:02] <mvo> I wonder if something like this is available for kde screensaver as well
[12:03] <Hobbsee> mvo: i'm not sure, nto found one, but havent looked.  screensaver fixing is on my to do list, if i can understand the stuff.
[12:03] <Hobbsee> mvo: ogra's the man for screensavers i'm told
[12:03] <mvo> Hobbsee: well, he is the man, but not for kde :)
[12:04] <Hobbsee> mvo: true
[12:04] <Mithrandir> infinity: if I give you a file which should be passed to mksquashfs -sort, can you fix that for me?
[12:04] <infinity> Kamion: Hrm, no, "linux" appears to be installable in my edgy chroot...
[12:04] <Hobbsee> mvo: dont think you'll find kde experts at teh moment :P
[12:04] <infinity> Mithrandir: You're just going to give me a static file for now?
[12:04] <Hobbsee> come on...build you stupid thing!  i have to go out!
[12:04] <infinity> Mithrandir: I guess that's saner than attempting to do something dynamic.
[12:04] <Hobbsee> ah ha!
[12:04] <infinity> Mithrandir: Yeah, if you give it to me, I can add it to the livefs mojo.
[12:05] <infinity> Mithrandir: Though you may as well TODO it and poke me on the 10th, since I don't intend to make the livefses build until I get back anyway.
[12:05] <Hobbsee> good, it built
[12:05] <Hobbsee> bye all!
[12:05] <Mithrandir> infinity: ok, sure.
[12:06] <Mithrandir> infinity: it needs to be a static list.  I can generate it easily enough, but one does need to boot a live cd to make it.
[12:06] <Hobbsee> mvo: good luck, it's pretty quiet there
[12:07] <Kamion> ? Unknown supported package: linux-restricted-modules-386
[12:07] <Kamion> I have a feeling it's forgotten about restricted somehow
[12:09] <Kamion> I think I'll just ignore it for a bit and hope it goes away
[12:10] <Kamion> also I'm going to exclude hppa from anastacia until it catches up
[12:10] <infinity> That might make hppa require manual bootstrapping to catch up...
[12:10] <Kamion> it will do anyway, I suspect
[12:10] <Kamion> I've done removal passes on things that may have affected hppa
[12:10] <infinity> If you start demoting stuff now, based on "nothing depends on it anymore", then build-deps will be uninstallable.
[12:10] <infinity> Oh, meh.  Fair enough.
[12:10] <Kamion> I wasn't planning to demote much stuff yet though
[12:11] <Kamion> just promote
[12:11] <infinity> I'm prepared to do some hackery.
[12:11] <Kamion> we can make edgy less fat later; now it just needs to work
[12:11] <infinity> Worst case, I'll need to build against dapper for a bit.
[12:11] <infinity> Poor little hppa.
[12:12] <Fujitsu> :(
[12:12] <slomo> infinity: will you give-back all the stuff that failed on amd64 yesterday because of chroot error?
[12:12] <infinity> slomo: Yes.
[12:12] <infinity> slomo: I'm doing a mass give-bakc later today, just for kicks, after elmo's done upgrading the buildds to dapper.
[12:12] <infinity> (which is what cause some amd64 builds to have a conniption fit)
[12:35] <TheMuso> Mithrandir: At what stage in ubiquity do the casper ubiquity hooks get executed? I am assuming that the majority, if not all the system has been installed?
[12:35] <fabbione> isn't it up already?
[12:36] <fabbione> ii  vim            7.0-017+8ubunt Vi IMproved - enhanced vi editor
[12:36] <Mithrandir> TheMuso: at the end, when it's been copied and all
[12:36] <TheMuso> Ok.
[12:37] <slomo> pitti: i already merged it yesterday evening
[12:37] <slomo> pitti: sorry :(
[12:37] <TheMuso> The hook script for accessibility would be almost a complete copy, except for removing some bits, and changing others.
[12:38] <TheMuso> The only thing I am unsure of, is how we would get the username of the created user during the install, so we can set the gconf values for that user.
[12:39] <pitti> slomo: erm? oh
[12:39] <TheMuso> Is such information retrievable from a file or a variable somewhere?
[12:39] <pitti> slomo: d'oh, this costed me 1.5 hours -- I should have read -changes before
[12:39] <pitti> slomo: I did a lot of diff cleanp
[12:40] <pitti> slomo: I'll grab yours and compare
[12:40] <slomo> pitti: i merged our changes by hand into the debian package and cleaned up too... but it took me 0.5 hours longer than you ;)
[12:40] <pitti> bah, we should really return to bugs for merges
[12:41] <fabbione> pitti: you can merge X if you want to be the c00l k1d :)
[12:42] <Kamion> fabbione: did you happen to keep the partman log anywhere corresponding to the fix you did in parted 1.6.25.1-1ubuntu1?
[12:42] <Kamion> or file a bug or anything?
[12:42] <fabbione> Kamion: let me check
[12:42] <Kamion> TheMuso: db_get passwd/username
[12:43] <Kamion> assuming you've done '. /usr/share/debconf/confmodule' somewhere above
[12:43] <Kamion> fabbione: s/fix/workaround/ - I'd like to ditch that patch and do it properly in parted_server
[12:43] <TheMuso> Kamion: Ah thanks. So I guess I should source debconf as well?
[12:43] <Kamion> TheMuso: yes
[12:43] <TheMuso> Yeah thought so.
[12:43] <TheMuso> thanks
[12:44] <fabbione> Kamion: oh the fix is 3 lines..
[12:44] <fabbione> workaround i mean
[12:44] <Kamion> fabbione: you said that it fails "while writing a new label", but as far as I can see that check is only performed when reading an existing label
[12:45] <Kamion> I know the workaround is small, but I want to ditch it
[12:45] <Kamion> it's the one remaining delta versus Debian - they incorporated your RAID patch
[12:45] <Kamion> and since it should be fixable in partman, given a log ...
[12:45] <fabbione> ok it's kind of tricky
[12:46] <fabbione> libparted does read if the existing label is valid before writing the new one
[12:46] <Kamion> nah, it's just exception handling, partman does that already all over the place
[12:46] <fabbione> nah the underlaying is tricky :)
[12:46] <fabbione> so what libparted does is read:
[12:46] <fabbione> if valid label compare it with the one we are writing -> (where it fails)
[12:46] <fabbione> and other cases..
[12:47] <fabbione> no valid lable -> just write
[12:47] <fabbione> so yes you can ditch the workaround and propagate the error up in the stack
[12:47] <Kamion> are you absolutely sure that that is in libparted? 'cos I'm looking at ped_disk_new_fresh etc. right now and can't see any such thing
[12:47] <fabbione> +++ parted-1.6.25.1/libparted/disk_sun.c        2006-02-28 10:17:29.000000000 +0100
[12:48] <fabbione> this is where the patch/workaround is
[12:48] <Kamion> yes, I know
[12:48] <fabbione> yes
[12:48] <Kamion> that code is only called when reading an existing label, and is not called when writing a new label
[12:48] <fabbione> Kamion: yes and read above...
[12:48] <fabbione> the code does first read
[12:48] <Kamion> I did read, and it does not match the code
[12:48] <fabbione> compare to what we want to write
[12:48] <Kamion> which is why I asked if you were sure that that was in libparted as opposed to say parted_server or somewhere else in partman
[12:49] <fabbione> let me recheck it
[12:49] <fabbione> Kamion: the check is right there
[12:49] <fabbione>         if (PED_BE16_TO_CPU(label->nsect) != dev->bios_geom.sectors ||
[12:49] <fabbione>             PED_BE16_TO_CPU(label->ntrks) != dev->bios_geom.heads) {
[12:49] <fabbione> in libparted
[12:50] <fabbione> if we trigger that condition, libparted sends an error to whatever is up in the stack
[12:50] <Kamion> I see that code
[12:50] <fabbione> right
[12:50] <Kamion> it is in _check_geometry_sanity, which is called from sun_read
[12:50] <fabbione> i don't remember what's up in the stack..
[12:50] <Kamion> sun_read is ONLY called when reading an EXISTING label
[12:50] <Kamion> it is NOT called when writing a NEW label
[12:50] <fabbione> well the error was happening when writing
[12:51] <Kamion> which is why I'm asking if you have a log
[12:51] <Kamion> because the partman log should help me actually fix this
[12:51] <fabbione> no i don't have a log handy
[12:51] <fabbione> i can make one
[12:51] <Kamion> do you still have a machine where the problem can be reproduced?
[12:51] <Kamion> ok
[12:51] <fabbione> i think i can reproduce it
[12:51] <Kamion> thanks, that would be very helpful
[12:51] <fabbione> ok
[12:51] <fabbione> but i remember 2 things for sure
[12:51] <Kamion> presumably with dapper you'd need to rebuild parted to switch off that workaround though
[12:52] <fabbione> yeah 
[12:52] <fabbione> i remember how i did test it
[12:52] <Kamion> I believe you that it happens while writing a new label, but I want to know where in the stack it's failing, because as far as I can see it's not while *libparted* is writing the new label
[12:52] <Kamion> so something in partman is doing the check, and I need to know what
[12:52] <fabbione> Kamion: libparted sends the error to $something (parted_server??) -> $something doesn't understand the exception -> UI doesn't know what to show
[12:53] <fabbione> Kamion: yeps.. i will get you the logs
[12:53] <fabbione> that's what i remember and i am just telling you...
[12:53] <Kamion> the question is what is calling the function in libparted that generates the exception
[12:53] <fabbione> no need to bang your head on a wall
[12:53] <Kamion> I know how libparted->partman exception handling works, there's no need to explain it :)
[12:53] <fabbione> in this case it doesn't because partman doesn't understand this exception
[12:54] <fabbione> or at least not in full
[12:54] <Kamion> indeed
[12:54] <fabbione> but i will get you the log and everybody will be happy
[12:54] <Kamion> that's what I want to fix
[12:54] <fabbione> perfect
[12:54] <Kamion> since your changelog indicated that it should be fixed once we were out of deep freeze
[12:55] <Kamion> so I hear and obey :)
[12:55] <fabbione> yes and you are right :)
[12:55] <fabbione> davem was just considering a full rewrite of libparted
[12:55] <fabbione> for sparc at least
[12:55] <fabbione> since "sucks" can't describe it in full
[12:56] <mjg59> libparted needs "fixing" for Apples
[12:57] <fabbione> Kamion: how urgent is this thing?
[12:57] <Keybuk> I've often wondered whether Intel's new name for the Pentium was influenced by Apple
[12:57] <Kamion> mjg59: isn't that just the HFS+ journal byte-swapping business?
[12:57] <Kamion> fabbione: not very, just not to be forgotten
[12:57] <Kamion> I may be able to zen it
[12:57] <Keybuk> "Apple Core" is just too perfect to be a coincidence
[12:57] <Treenaks> Keybuk: if that's true, the 'iTanium' was meant for apple too ;)
[12:58] <fabbione> Kamion: ok, i have my machine busy today to test a gcc fix that should allow doko to unleash ssp in edgy. i will try to get to it sometimes tomorrow
[12:58] <Kamion> fabbione: oh, cool, thanks
[12:58] <fabbione> Kamion: also because i need to powerup the SAN to get to the solaris partition layout that trigger the problem
[12:58] <Kamion> fabbione: I'll sync parted and deal with the ABI change uploads following that then
[12:58] <fabbione> Kamion: ok perfect
[12:59] <sivang> Keybuk: what is Apple Core?
[12:59] <Treenaks> sivang: the thing that's in the middle, the part that most people don't eat.. with the seeds in it
[12:59] <sivang> heheh
[01:00] <sivang> Treenaks: better not eat the seeds, their full of Cyanid, and frequent dosage of those can cause raspatory blocks
[01:00] <mjg59> Kamion: That, plus it needs to sync MBR and GPT partition tables
[01:00] <mjg59> (Which breaks the GPT spec)
[01:23] <Kamion> fabbione: filed bug 51289 about this and targeted it to edgy since it'd be a regression otherwise
[01:23] <Kamion> fabbione: if you could attach your log to that once you have it, that'd be perfect
[01:55] <infinity> pitti: Is there an ETA on that "sudo that doesn't suck" upload?
[01:56] <infinity> pitti: (Not that I care, I'm still running dapper, but others seem to care more)
[01:58] <pitti> infinity: I'm on it, but it's a fairly tricky one. I'm currently in the depths of yacc code and processing to find out what goes wrong
[01:58] <pitti> infinity: expect a fix by the meeting
[02:03] <infinity> pitti: Thanks, dude.
[02:08] <sivang> bah, deptch of yacc..
[02:10] <pitti> yay, it works now
[02:10] <pitti> hi ivoks 
[02:11] <jsgotangco> hey
[02:11] <ivoks> hi all
[02:11] <ivoks> what works? :)
[02:11] <pitti> ivoks: sudo
[02:11] <ivoks> oh...
[02:12] <ajmitch> pitti: yay! :)
[02:12] <Fujitsu> How long until it's uploaded?
[02:12] <ivoks> it didn't work before? :)
[02:12] <Fujitsu> ivoks, not in edgy, no.
[02:13] <ivoks> ah, /me is too busy with exams on faculty, so i didn't upgrade edgy for couple of days
[02:16] <zul> hey
[02:20] <pygi> ivoks, morning :)
[02:31] <fabbione> Kamion: ok thanks
[02:31] <ivoks> pitti: what's with hplip in dapper?
[02:32] <pitti> ivoks: -v please
[02:32] <ivoks> pitti: well, hplip in dapper was release almost a year ago
[02:33] <ivoks> pitti: there were newer version, but we didn't include them
[02:33] <Keybuk> do you mean "why hasn't hplip in dapper been updated?"
[02:33] <ivoks> yes
[02:33] <Keybuk> http://merges.ubuntu.com/h/hplip/REPORT
[02:33] <ivoks> thanks
[02:33] <Keybuk> ^ Feel free to grab the files there and do the merge for somebody
[02:38] <ivoks> will do
[02:39] <StevenK> Keybuk: How often does MoM peer at the archive? IE: will it notice the stack of syncs and dump them out of the list?
[02:41] <Keybuk> StevenK: yes.
[02:41] <Keybuk> it peers at the archive whenever I run it :p
[02:42] <Keybuk> if there is no "merge" for a package (which is true if it is syncd) then it cleans up the merge directory so it doesn't appear in the list anymore
[02:42] <StevenK> Keybuk: How long does it take to run?
[02:42] <Keybuk> I don't know yet
[02:42] <Keybuk> I've not done a "pulse run" yet
[02:43] <Keybuk> it takes about 6 hours to do a rebuild run
[02:43] <StevenK> Ah. You've only the "ohmigod it hurts" first run?
[02:43] <Keybuk> I've done a first run, and a couple of "redo everything again" runs
[02:43] <StevenK> MoM is all Python?
[02:44] <tseng> mom was just rewriten
[02:44] <Keybuk> yes
[02:44] <StevenK> I know that.
[02:44] <Keybuk> I've been thinking what to call it
[02:44] <Keybuk> there's a lot of jokes available with the term "new mom"
[02:45] <Keybuk> "she loves you just as much as your old mom"
[02:45] <StevenK> Heh
[02:45] <StevenK> Keybuk: Well, you can't call it Britney. :-P
[02:45] <tseng> is there a Stepahie?
[02:45] <Keybuk> I haven't been able to backronym "step-mom" yet
[02:46] <StevenK> Keybuk: Julia
[02:46] <tseng> we could buy a book of "names for baby girls" to name new infra projects
[02:46] <Keybuk> tseng: we've been abandoning that
[02:46] <StevenK> Awwww.
[02:46] <StevenK> elmo stopped loving girl celebs?
[02:46] <Keybuk> amusingly, the first set of "new mom" tools had boys names just as a rebellion against the katie suite
[02:46] <tseng> oh, they are celebs?
[02:46] <StevenK> Keybuk: Please tell me one of them wasn't called justin or kevin?
[02:47] <_ion> justin time
[02:47] <_ion> i.e. almost late
[02:47] <Keybuk> StevenK: one was called justin, yes
[02:47] <StevenK> Eek
[02:47] <Keybuk> I got bored with that though, because I forgot what each one did when there were just three of them
[02:47] <StevenK> Hah
[02:48] <pitti> Keybuk: can I please have http://patches.ubuntu.com/patches back?
[02:48] <Keybuk> pitti: where did it go?
[02:48] <pitti> I don't know :)
[02:48] <Keybuk> merge@casey:/srv/patches.ubuntu.com/published$ cat .htaccess
[02:48] <Keybuk> # Patches manually attached to the BTS
[02:48] <Keybuk> Redirect /patches/ http://people.ubuntu.com/patches/
[02:48] <Keybuk> hmm
[02:49] <Keybuk> oh, I know
[02:49] <Keybuk> nope, that didn't work either
[02:49] <Keybuk> bet someone disabled redirects
[02:50] <StevenK> Keybuk: RewriteEngine On? :-)
[02:50] <Keybuk> StevenK: no idea, it worked the other day
[02:50] <infinity> You don't need mod_rewrite for Redirect{,Match}
[02:50] <StevenK> Not sure if that even works in .htaccess
[02:50] <Keybuk> one of the admins must have been fiddling
[02:51] <infinity> If the FileInfo override has been disabled in that directory, it won't work.
[02:51] <infinity> Or if mod_alias is disabled (seems unlikely)
[02:52] <mvo> iwj: here? I'm pondering about your comment in AlwaysEnableUniverseMultiverse about making apt-get show something about the unsupported nature of the install
[02:52] <infinity> Anyhow, better to have the Redirect in the vhost config anyway, not in .htaccess, so I'd just RT it and ask elmo to put it in the Right Place.
[02:52] <Keybuk> infinity: mod_alias has been disabled
[02:52] <infinity> Keybuk: Oh, hah.
[02:53] <infinity> Keybuk: A great argument for asking elmo to put it in the vhost conf for you, since apachectl will SCREAM if you start with an unsupported directive in the conf. :)
[03:02] <StevenK> Heh
[03:02] <Kamion> who uploaded the cyrus21-imapd merge?
[03:04] <Keybuk> \o/  my VoIP hard-phone arrived
[03:05] <mjr> SIP?
[03:05] <Keybuk> aye
[03:05] <infinity> signature from "Martin Pitt <martin@piware.de>
[03:05] <mjr> good on you
[03:05] <infinity> Tsk, tsk.
[03:06] <infinity> pitti: Naughty.
[03:06] <pitti> infinity: ?
[03:06] <ogra> pitti, you pretend to be our mom
[03:07] <Keybuk> and this is now the second device I've got where the presentation of the power supply is a USB-2 plug
[03:07] <ogra> pitti, Von: 	Ongoing Merge Process <mom@ubuntu.com>
[03:07] <ogra> Betreff: 	Accepted cyrus21-imapd 2.1.18-3ubuntu1 (source)
[03:07] <pitti> ooh, that
[03:07] <Keybuk> maybe, at last, we're starting to see a standard connector?  (hopes)
[03:07] <pitti> yes, sorry for that
[03:07] <StevenK> Keybuk: Nah!
[03:08] <ogra> pitti, nah, i'm always happy to get mail from mommy ;)
[03:09] <tseng> I wish that also, but as it is a forward
[03:09] <tseng> based on the primary field
[03:09] <tseng> tricky problem.
[03:12] <StevenK> Oh crap, I haven't prelink'd ooo on this machine.
[03:19] <TheMuso> Keybuk: Is there a reason Mom doesn't use packages from dapper-updates?
[03:20] <Keybuk> because those packages are not in edgy
[03:20] <Keybuk> this should hopefully force people to realise that uploads to dapper-updates _do_not_affect_edgy_
[03:21] <TheMuso> hmm ok
[03:21] <TheMuso> I knew that re dapper-updates packages not effecting edgy.
[03:21] <G0SUB> jsgotangco: hello!
[03:22] <TheMuso> I ask because I patched a package in universe for dapper-updates, and noticed that those changes weren't included in the merge files.
[03:22] <jsgotangco> G0SUB: hey dude
[03:22] <G0SUB> jsgotangco: how are you?
[03:22] <G0SUB> jsgotangco: can I PM you?
[03:22] <jsgotangco> G0SUB: go ahead
[03:26] <iwj> mvo: Hi.
[03:26] <iwj> (sorry, I was eating)
[03:27] <iwj> mvo: You mean my comment about command-line users ?
[03:28] <mvo> iwj: yeah, I'm pondering how to do it without permanently annoying them with a nag-line like "the following packages are unsupport, do you want to continue"
[03:28] <ajmitch> mvo: <blink> tags :)
[03:28] <iwj> You could treat it like the dependency resolution prompt perhaps ?
[03:29] <iwj> Ie, mention it as   The following UNSUPPORTED packages    or some such and then say [Y/n] .
[03:29] <iwj> But I'm not sure how easy that would be to do.
[03:29] <mvo> coding it shouldn't be hard, I guess that is the way to go
[03:29] <iwj> Or you could ask a question on the first run of commandline apt-get.
[03:30] <Keybuk> TheMuso: the easiest way to get them included would be to patch the edgy package as well
[03:30] <Keybuk> interestingly, new-mom is sufficiently generic that I could do a dapper-updates/edgy merge <g>
[03:30] <Keybuk> it might be a fun attempt
[03:31] <TheMuso> Keybuk: thats what I am going to do. Was just wondering.
[03:40] <StevenK> Can some kind soul remove my aborted upload attempt of xemacs21?
[03:42] <infinity> No need to remove it.
[03:42] <infinity> If you uploaded an incomplete upload it'll just fail and carry on.
[03:46] <sivang> mdz: thanks for setting my specs back to reivew, I confused and set them to pending approval..
[03:47] <sivang> mdz: (to request more review)
[04:00] <Hobbsee> infinity: a life?  what's that crazy thing you speak of?  :P
[04:01] <Mithrandir> Hobbsee: it's pink with blue spots.
[04:01] <Mithrandir> moves quite quickly and is hard to catch
[04:01] <ajmitch> ah
[04:01] <Hobbsee> Mithrandir: ah right
[04:01] <ajmitch> sounds rather elusive
[04:03] <ajmitch> Hobbsee: none of that, thanks
[04:04] <Hobbsee> no?
[04:04] <Hobbsee> ajmitch: who'd that get assigned to instead?
[04:04] <ajmitch> no
[04:04] <ajmitch> the other MOTUs handle all the merging
[04:04] <Hobbsee> ah, right, so you just sit and be lazy, or boss them around, fixing REVU at times when it breaks.
[04:04] <ajmitch> except for stuff I care about, need, or have time for :)
[04:05] <ajmitch> no, I do coding & other packaging
[04:05] <ajmitch> stuff that's not uploaded yet
[04:05] <Hobbsee> right
[04:09] <pitti> Keybuk: do you expect any problems if dash gets the default for < breezy dist-upgrades? it's working fine here for ages
[04:12] <Keybuk> how do you mean?
[04:12] <Keybuk> (discuss after)
[04:18] <pitti> Keybuk: since mdz seemed to worry about getting that change on upgrades
[04:18] <Keybuk> I thought mdz was oppositely worried; in that people with dash already installed _wouldn't_ get the /bin/sh change?
[04:19] <mdz> Keybuk: correct
[04:19] <pitti> oh, ok; well that would break even less...
[04:19] <mdz> (meaning it will get less testing)
[04:19] <mdz> the sorts of people who are running edgy probably already had it installed
[04:19] <Keybuk> right ... it needs me to get out "Debconf for Dummies" and change the value of the existing default :)
[04:20] <Keybuk> do I anticipate any problems with it being /bin/sh in general?  no, because almost everyone I spoke to had already done it themselves anyway :p
[04:21] <Mithrandir> Keybuk: DfD, aka debconf-devel(7) :-P
[04:21] <Keybuk> and Nokia have provided hundreds, if not more, patches to Debian
[04:21] <Keybuk> Mithrandir: Kamion was amazed that, in all my years in Debian, I'd managed to completely avoid touching debconf :p
[04:22] <pitti> Keybuk: I did some debconf hacking (including db_set), feel free to ping me for questions
[04:22] <Kamion> there's no way to tell whether it's been explicitly set
[04:22] <Kamion> however, if you do, make sure it's in an upgrade clause guarded by dpkg --compare-versions
[04:23] <Keybuk> Kamion: that was the reason I didn't change it ... I didn't realise we'd ever shipped dash ourselves
[04:29] <Kamion> BenC: re libata-for-all-ata-disks, I'd very much like partman-target to use uuids before you go ahead with the kernel change
[04:29] <Kamion> otherwise the upgrade is more complicated
[04:31] <BenC> Kamion: ok, so upgrade needs base-files, boot loaders, and partman?
[04:32] <Kamion> right
[04:32] <Kamion> er
[04:32] <Kamion> fresh install needs partman
[04:32] <Kamion> but don't want to do the upgrade handling until fresh installs are right, otherwise there's no sane version to pick to key the upgrade off
[04:32] <Kamion> Keybuk: ^--
[04:33] <Keybuk> right
[04:33] <Keybuk> we'll keep them blacklisted until the migration stuff is in place
[04:35] <BenC> yeah, atleast then ppl can manually enable them for testing
[04:35] <BenC> and I might actually send out an email requesting that, see if we can spot some problems in advance
[04:36] <BenC> Keybuk: I am going to send a list of libpata modules I am enabling, and each one will show the matching IDE module
[04:36] <BenC> so you can create the blacklist like:
[04:37] <BenC> blacklist pata-foo
[04:37] <BenC> # blacklist ide-foo
[04:37] <BenC> or similar
[04:37] <Keybuk> indeed
[04:40] <Keybuk> real    34m44.593s
[04:40] <Keybuk> hmm
[04:40] <Keybuk> that's encouraging
[04:40] <Keybuk> we could run mom every hour :p
[04:41] <pitti> Keybuk: running it more than once a day would indeed be helpful, given the current merge pace
[04:42] <Keybuk> I've set it to every 6 hours at the moment
[04:42] <pitti> yay
[04:42] <Keybuk> I'm completely unconvinced cron is running on casey though <g>
[04:45] <pitti> ogra: oh, dhcp3 is currently on my merge list; if you want to merge it, I'll ignore it
[04:47] <ogra> pitti, as you like just dont forget to supress next-server :)
[04:49] <infinity> ARGH.
[04:49] <infinity> Who merged cpio?
[04:50] <Hobbsee> infinity: whoever did broke it, and that's why visudo is also failing.
[04:51] <infinity> Oh, wait, that's not a merge, it's a sync.
[04:51] <infinity> Awesome.
[04:51] <Kamion> "cpio" != "sudo"
[04:51] <infinity> cpio broke my chroots.  All of them.
[04:51] <infinity> I'm so thrilled.
[04:52] <Kamion> how did cpio break visudo?
[04:52] <Hobbsee> Kamion: according to the build logs, that's what it failed on, from what i can see
[04:52] <pitti> ogra: no idea what's that about
[04:52] <Kamion> Hobbsee: oh that'll just be breaking everything, not sudo in particular
[04:52] <infinity> Keybuk: Please merge cpio/2.6-15 ASAP, I may need to manually bootstrap it.
[04:52] <Hobbsee> Kamion: ah great - that's the only one that i was looking out for :P
[04:53] <ogra> pitti, debian forces usage of the next-server option, we patched that out because it breaks existing ltsp setups
[04:53] <Kamion> infinity: I'll do netcfg, although you have the touched-it-last bit
[04:54] <Kamion> I have it in bzr and stuff
[04:54] <pitti> ogra: since I did a fair bit of hacking in DHCP, I propose that I do the initial merge and then give you the package for testing and polishing
[04:54] <pitti> ogra: (that said, I'd be happy if you did the merge yourself, I just stick to the default assignee in the merge list :) )
[04:55] <infinity> Keybuk: s/merge/sync/
[04:55] <ogra> pitti, fine with me, just make sure to not upload something with next-server in it, it resulted inn a ton of howtos in dapper i still have to fight
[04:56] <pitti> heh, ok :)
[04:57] <Keybuk> infinity: *confused*
[04:57] <Keybuk> there is no sync?
[04:57] <infinity> Keybuk: incoming, perhaps.
[04:58] <Keybuk> will look
[04:58] <infinity> Yeah, it's in incoming.
[04:58] <infinity> -14 has a broken preinst.
[04:58] <infinity> I'm going to work around it in the chroot tarballs so the world stops breaking.
[04:58] <infinity> But we need that sync to not break everyone else.
[05:03] <Keybuk> infinity: I think that _may_ have just made the publisher run
[05:05] <pitti> btw, archive admins: thanks for the fast responses to sync bugs!
[05:06] <tseng> pitti: yes seriously
[05:06] <tseng> they are rocking
[05:06] <tseng> Kamion rocks on NEW also
[05:12] <pitti> ajmitch: you know the requestsync script, right?
[05:13] <ajmitch> pitti: yep
[05:13] <ajmitch> pitti: I need to check which ones need the sync first
[05:16] <bddebian> Heya
[05:17] <infinity> Okay, buildd chroots rescued, mass-give-back pending the next queuebuilder run at :50
[05:19] <zul> hey fabbione 
[05:19] <fabbione> hey zulligno
[05:19] <infinity> And that's my last good deed for the day.
[05:19] <infinity> 'Night, folks.
[05:20] <Hobbsee> night infinity.  thanks for fixing the world.
[05:20] <sivang> infinity: night dude
[05:20] <bddebian> gnight infinity
[05:21] <ariel> enrico?
[05:21] <fabbione> infinity: night dude
[05:22] <fabbione> yeahhh gcc is building the binaries
[05:22] <fabbione> doko: do you want a debdiff?
[05:23] <infinity> fabbione: Going to upload it in time for the next publisher run, so it has a hope of finishing by the time I wake up? :)
[05:23] <fabbione> infinity: as soon as i have the debs i need to fire up glibc
[05:23] <fabbione> i assume in one hour or so 
[05:24] <fabbione> infinity: it should be done by the time you wake up hopefully
[05:25] <enrico> ariel: yes
[05:25] <enrico> ariel: at your service
[05:25] <ariel> enrico: you were looking for some help with scheme / festival
[05:25] <enrico> ariel: yes.  Most of it I think i solved
[05:25] <enrico> ariel: although, I could use some review
[05:25] <ariel> yes I just saw your last email
[05:25] <ariel> :>
[05:26] <enrico> ariel: :)
[05:26] <enrico> ok
[05:26] <ariel> anyway, if in the future you need some scheme help ping me
[05:27] <enrico> ariel: sure.  But at least, do you think that my patch makes sense, festival-wise?  That is, did I add the element with the right name and in the right position?
[05:27] <enrico> (btw, thanks!)
[05:27] <sivang> yo enrico !
[05:27] <enrico> sivang: hi
[05:28] <ariel> enrico: maybe you should put coding befor description
[05:29] <enrico> ariel: I fear breaking things if I append.  gnome-speech was reading things positionally instead of by name
[05:29] <ariel> well yes you ar right
[05:30] <ariel> in an ideal word something like current-voice should be an object or an structure
[05:31] <enrico> well... we're far from an ideal world there
[05:31] <ariel> I can't understand why they SIOD as their scheme interpreter
[05:32] <enrico> ariel: maybe it just happened to be handy
[05:32] <ariel> enrico: and Iam a guile guy so...
[05:35] <Kamion> Keybuk: would you expect /dev/cciss/* devices to have a 'device' symlink in /sys/block/?
[05:35] <enrico> ariel: first LISP I've written is for this festival incident
[05:35] <ariel> enrico: :) welcome to this lisp world!
[05:36] <sivang> question to the review team: should I nag you so my spec will get reviewed , or just sit quitely wait for the status to change on LP? :)
[05:42] <doko> fabbione: just email it please
[05:43] <bddebian> Is there a sane way to make a cdbs package build everything in debian/tmp/foo and then parse out after the fact?
[05:43] <fabbione> doko: yeps.. almost done
[05:43] <fabbione> doko: glibc is building right now.
[05:50] <CarlFK> nice timing - this just in from a mail list: "I also second Carl's comments about Ubuntu as an organization. Lots of warm fuzzies there. "  
[05:51] <Kamion> bddebian: I'm afraid I can't work out what you mean, much less answer it. "parse out after the fact"?
[05:51] <Kamion> also, a whole six minutes, oh no
[05:51] <bddebian> :)
[05:53] <bddebian> As near as I can tell scilab-3.0 uses DEB_MAKE_INSTALL_TARGET := install DESTDIR=`pwd`/debian/tmp/usr  to "build" in debian/tmp.  Then in the .install files for the three binary packages they split out the files into the appropriate dirs
[05:53] <bddebian> For scilab-4.0, using a very similar rules file it doesn't not work
[05:54] <Kamion> try building with DH_VERBOSE=1 to see what debhelper is doing under the covers
[05:54] <bddebian> Of course I'm not sure I understand why this is three binary packages anyway but that's a different issue :-)
[05:55] <Kamion> and dig down further than "doesn't work" - find out where files are going, whether they're not getting installed correctly into debian/tmp or whether they're not getting copied out of there properly, at minimum
[05:55] <Hobbsee> 
[05:55] <Hobbsee> crud, sorry, this irssi on the live cd is weird!
[05:55] <bddebian> Kamion: They are going to debian/$package/foo but it's not all there
[05:56] <Hobbsee> 
[05:56] <Hobbsee> argh!
[05:56] <desrt> 
[05:56] <Kamion> bddebian: then start with the package's Makefile
[05:56] <Hobbsee> someone help!  how do you switch windows on irssi?  this thing is weird and bizarre and the normal shortcuts arent working!
[05:56] <Kamion> DESTDIR support sometimes has to be hacked in
[05:57] <Kamion> Hobbsee: Escape <window number>
[05:57] <Kamion> or /window <number>
[05:57] <infinity> Hobbsee: Alt-#, Esc-#, or /win #
[05:57] <Hobbsee> Kamion: infinity: thanks so much!  i kept trying alt, as that's the version that works in konsole
[05:58] <Hobbsee> would have asked in a more appropriate place, but i couldnt switch windows :P
[05:58] <bddebian> Kamion: Thank you.  What would the approprate place for DESTDIR be?  SHould it be in DEB_MAKE_INSTALL_TARGET?
[05:59] <Kamion> bddebian: I guess, I don't really know cdbs, but what that's probably doing is calling 'make install DESTDIR=`pwd`/debian/tmp/usr'
[05:59] <Kamion> bddebian: so run that by hand and see what it does
[05:59] <Kamion> usual debugging practice is to drill down one step at a time
[06:00] <Kamion> use grep etc. to find out what implements the stuff that's causing you problems
[06:00] <bddebian> Aye, but I don't know cdbs well enough to know what runs when..  I will shut up now
[06:00] <Hobbsee> bddebian: check other cdbs stuff?
[06:00] <bddebian> Hobbsee: I have :-)
[06:01] <Hobbsee> right
[06:01] <bddebian> And read usr/share/docs/cdbs/examples, etc
[06:01] <bddebian> And LaserJocks packaging guide
[06:02] <Hobbsee> hmmm
[06:04] <Kamion> bddebian: (this is why I avoid using cdbs personally, but that's no help to you)
[06:04] <sivang> cdbs is evil! :-)
[06:05] <Kamion> it's fine as long as you like your rules files to take the prolog approach :P
[06:05] <sivang> hehe
[06:05] <Kamion> but then when it goes wrong it says "no" and you don't know why
[06:06] <Kamion> bddebian: anyway, if all else fails you can 'fakeroot strace -f -etrace=execve debuild -b' to see what subprocesses it's spawning
[06:10] <raphink> is it only me or is sudo badly broken in edgy ?
[06:11] <raphink> >>> sudoers file: syntax error, line 2 <<<
[06:11] <raphink> >>> sudoers file: syntax error, line 21 <<<
[06:11] <raphink> etc ....
[06:11] <raphink> on a file that's perfectly correct
[06:11] <raphink> :s
[06:12] <Hobbsee> raphink: it's broken, fix was uploaded, but failed due to a broken cpio
[06:12] <Kamion> known, fixes are working their way through the queue
[06:12] <Hobbsee> bleh
[06:12] <raphink> yes, cpio is broken, too
[06:12] <raphink> :)
[06:13] <raphink> I wonder how to fix it now, since sudo is broken ;)
[06:13] <raphink> hehe
[06:13] <Kamion> boot into recovery mode
[06:13] <raphink> Kamion: it's in my chroot
[06:13] <raphink> I havent' upgraded my machine yet :)
[06:13] <raphink> I guess I just have to sudo -i and then chroot
[06:14] <Kamion> that makes the task rather easy; exit the chroot and chroot in as root
[06:14] <Kamion> sudo chroot /blah
[06:14] <raphink> yep that works :)
[06:14] <raphink> yes
[06:14] <bddebian> Kamion: Can I bug you for something else? :)  (BTW, I'm only using cdbs because the current Debian maintainer, who is orphaning the package, won't sponsor if not cdbs)
[06:14] <Kamion> bddebian: just say it on channel rather than to me personally
[06:15] <Kamion> for all you know I might have no idea about whatever it is
[06:15] <Kamion> also, please don't ask to ask, just ask :)
[06:15] <bddebian> But you know everything :)
[06:15] <Kamion> if I get *asked* about everything, I'll /quit
[06:15] <Kamion> there are other clever people on this channel
[06:16] <bddebian> Anyway, in my edgy pbuilder, if I do a pbuilder login and apt-get update && apt-get install x11proto-gl-dev, no problem
[06:16] <bddebian> However, pbuilder update and pbuilder build foo.dsc which build-deps x11proto-gl-dev says it can't satisfy x11proto-gl-dev build dep
[06:16] <bddebian> Kamion: Yeah but they hate me too :-)
[06:18] <Kamion> bddebian: I'm afraid I do not know the cause of that problem.
[06:18] <Kamion> so no, I don't know everything :P
[06:18] <Hobbsee> Kamion: shameful!!!
[06:18] <Kamion> perhaps people are reticent to answer you because whoever answers one of your questions gets all the subsequent questions too? just a thought :)
[06:20] <pitti> wb mdz
[06:20] <mdz> kernel upgrade + sudo downgrade
[06:21] <infinity> But the new sudo was so much FUN.
[06:21] <infinity> Like a distro team video game.
[06:21] <pitti> speaking of the kernel -- BenC, when do you think it is time to switch linux-meta to .17?
[06:21] <BenC> pitti: in about 1 hour
[06:21] <infinity> pitti: When LRM clears NEW.
[06:21] <pitti> infinity: I regarded it as 'edgy user base count tool'
[06:21] <Hobbsee> (infinity: didnt you go to bed?)
[06:21] <pitti> oh, wow, that's fast :)
[06:21] <infinity> Hobbsee: Yes.
[06:21] <pitti> Hobbsee: that's the InfinityBot you are speaking to
[06:21] <Hobbsee> hehe
[06:22] <BenC> infinity: go to bed :P
[06:22] <Hobbsee> heya um...pitti?
[06:22] <pitti> infinity.sleep(8*3600)
[06:23] <BenC> pitti: sent update email for kernel vulns
[06:26] <fabbione> BenC: do you want to take of new silo for edgy? or should I?
[06:26] <bddebian> Kamion: :-(
[06:28] <Kamion> bddebian: genuinely trying to help. I find that repeatedly asking the same person for help when I don't know that it's their field leads to the help drying up rapidly
[06:29] <BenC> fabbione: have at it
[06:32] <bddebian> Kamion: OK, fair enough
[06:33] <Kamion> bddebian: again, though, my approach would be to find out what pbuilder's calling, run that by hand, see what breaks, drill down, etc.
[06:33] <Kamion> most problems are soluble by drilling down a step at a time.
[06:34] <fabbione> BenC: ok
[06:39] <zul> BenC,pitti: i should have breezy/hoary done this weekend
[06:43] <sshrdp>  /join #ubuntu
[07:07] <jsgotangco> goodnight
[07:07] <jjesse> night
[07:11] <Keybuk> Kamion: sorry, was at lunch -- and took a bit longer to get home than I hoped
[07:12] <Keybuk> I do not believe /dev/cciss is currently covered by the persistent disk rules
[07:12] <Keybuk> but then I don't know which subsystem they come from
[07:27] <elmo> our standard kernels support root raid, right?
[07:29] <elmo> 'cos I just switched a box from monolithic to standard kernel and it spassed out during initramfs claiming it couldn't find /dev/md0
[07:31] <fabbione> elmo: yes it does 
[07:31] <fabbione> i blame udev for that
[07:31] <fabbione> elmo: can you modprobe raid1 and do a mdrun -a?
[07:32] <fabbione> that should start the raid
[07:32] <fabbione> (i assume you used raid1)
[07:32] <Keybuk> fabbione: udev has nothing to do with /dev/md
[07:32] <Keybuk> the idiot kernel md stuff doesn't support driver core
[07:32] <fabbione> Keybuk: if udev didn't load the controller modules... yes :)
[07:33] <Keybuk> fabbione: why would udev load the controller module?  it's not bound to any particular hardware
[07:33] <elmo> fabbione: there's no mdrun in the initramfs system
[07:33] <Keybuk> elmo: should be scripts/local-top/md
[07:33] <elmo> ah, right
[07:33] <elmo> I'm back in monolithic, lemme reboot
[07:34] <fabbione> . /usr/share/initramfs-tools/hook-functions
[07:34] <fabbione> copy_exec /sbin/mdadm /sbin
[07:34] <fabbione> copy_exec /sbin/mdrun /sbin
[07:34] <fabbione> it should be therre
[07:35] <fabbione> elmo: i assume you have mdadm installed on the system
[07:35] <elmo> I assume so - monolithic boots ;-)
[07:36] <fabbione> elmo: raid doesn't really need userland to work if compiled in. there is a magic to autostart raid in the kernel
[07:37] <Keybuk> fabbione: won't that die with the klibc patch>
[07:37] <fabbione> Keybuk: ?
[07:37] <Keybuk> not following lkml?
[07:37] <fabbione> no
[07:37] <Keybuk> the patch to add klibc to the kernel tree proper, and expel the last of the bits of the kernel that deal with mounting the root, etc.
[07:38] <Keybuk> so even a monolithic kernel would have an initramfs in it
[07:38] <fabbione> the raid autostart is done by magic superblocks
[07:38] <fabbione> but yeah it might.. dunno what future will say
[07:38] <elmo> ok, ACPI Debug + 9600 Serial Console ==> very effective boot DOS
[07:38] <fabbione> elmo: that's ia64, isn't it? :P
[07:39] <elmo> yes :-P
[07:39] <elmo> mptscsih: Unknown symbol scsi_remove_host
[07:39] <elmo> mptscsih: Unknown symbol scsi_host_put
[07:39] <elmo> mptscsih: Unknown symbol scsi_print_command
[07:39] <elmo> hmm
[07:39] <fabbione> oh hmm
[07:39] <fabbione> oh yeah
[07:39] <fabbione> there is a bug open for that
[07:39] <fabbione> it's binutils miscompiling a kernel module
[07:40] <fabbione> something benc knows about
[07:40] <fabbione> (in details)
[07:41] <elmo> Begin: Waiting for root file system... ...
[07:41] <elmo> how long will it do that for?
[07:41] <BenC> up to 3 minutes
[07:41] <BenC> I think
[07:42] <elmo> is there someway to reboot in the initramfs environment?
[07:43] <fabbione> on ia64... hmm
[07:43] <fabbione> yes
[07:43] <fabbione> you can do a ctrl+a+f to send a break and it will show the other options
[07:43] <elmo> yeah, ok so the md0 stuff is a red herring - it's not got /dev/sd* which is much more relevant
[07:43] <fabbione> iirc it's ctrl+a+r to reboot
[07:44] <fabbione> elmo: i still blame udev for that ;)
[07:44] <elmo> hmm, minicom has that key bound :/
[07:44] <elmo> fabbione: not the mpt driver fuckage?
[07:44] <fabbione> elmo: yeah it's mpt.. i was just kidding :)
[07:44] <fabbione> elmo: not here.. i use minicom
[07:44] <fabbione> elmo: do a crtl+a+space
[07:44] <fabbione> it should show the help
[07:45] <fabbione> or ctrl+a+f+space.. hell i can never remember
[07:45] <fabbione> let me power on my ia64
[07:45] <fabbione> i can be more useful that way
[07:46] <elmo> ah, C-a-f b
[07:46] <elmo> fabbione: got it, thanks
[07:46] <fabbione> elmo: no problem..
[07:47] <fabbione> later
[07:50] <Keybuk> sip debug
[07:50] <Keybuk> meh
[07:52] <Tonio_> hello
[07:59] <bddebian> Hi Keybuk
[07:59] <Keybuk> hi
[08:00] <elmo> BenC: do you know if there's a launchpad bug for  that mpt binutils symbol lossage, offhand?
[08:00] <BenC> yeah, there is
[08:00] <BenC> not sure if the bug report, but I recall it
[08:00] <BenC> err, not sure of the bug number, but... :)
[08:02] <BenC> uhg, gcc/binutils...one of them will be the death of me
[08:03] <BenC> l-r-m is failing to build on i386 because of binutil 2.17, but it worked with 2.16 :/
[08:03] <bddebian> whee
[08:04] <elmo> Keybuk: do you know how to turn off buildds?
[08:04] <Keybuk> elmo: yes
[08:04] <BenC> well, I can't really say that
[08:05] <Keybuk> well, I know how to put them into MANUAL
[08:05] <BenC> strip is failing on pre-built nvidia libraries
[08:05] <elmo> Keybuk: what's the URL?
[08:05] <elmo> BenC: ah, yeah,t here's a bug in Debian about that
[08:05] <elmo> I've been meaning to forward it upstream
[08:05] <Keybuk> elmo: /+builds/$BUILDD/+mode
[08:05] <BenC> I guess I can just ignore the nvidia libs
[08:06] <elmo> "+builds" not "+buildds" ?
[08:06] <elmo> BenC: not stripping themwould be the short term fix, yeah
[08:06] <elmo> Keybuk: that's afe to do while it's building, right?
[08:08] <Keybuk> elmo: absolutely no idea!
[08:08] <elmo> oh well, we'll find out now I guess
[08:08] <Keybuk> definitely +builds
[08:09] <fabbione> elmo: please don't stop artigas
[08:09] <fabbione> we really need gcc in asap for sparc
[08:09] <elmo> fabbione: I've put it into manual, if that breaks the current build, it's too late to do anything about it
[08:09] <elmo> and it's a hideous LP bug anyway
[08:10] <elmo> if it doesn't break the current build, I'll be waiting for it to finish before I reboot anyway
[08:10] <fabbione> ok thanks
[08:10] <fabbione> i can tell you sejong willFTBFS
[08:10] <fabbione> it needs gcc on artigas to build ;)
[08:14] <BenC> ok, new vim default syntax stuff is really freaking me out
[08:15] <BenC> collapsed debian/changelog sections by default, hihglighting open/close of parens in makefile vars, etc
[08:16] <bluefoxicy> uh
[08:17] <bluefoxicy> is there a way to get root besides sudo?
[08:17] <bddebian> boot in recovery mode?
[08:17] <bluefoxicy> figured that was it :/
[08:18] <bluefoxicy> /etc/sudoers is fragged on edgy
[08:18] <Amaranth> no it's not
[08:18] <Keybuk> it's just sudo that's fragged <g>
[08:18] <bluefoxicy> heh, yeah
[08:18] <Keybuk> oh look, it even says that in the /topic :p
[08:18] <bluefoxicy> remind me to put public keys for root on both my machines so I can ssh in remotely.
[10:22] <Kamion> Keybuk: cciss> sorry, not familiar with the connection between having a device symlink in /sys/block and being in the persistent disk rules
[10:27] <pitti> hm, since both cpio and sudo are fixed and in the archive now, we can certainly change the title
[10:29] <crimsun> pitti: don't join #ubuntu
[10:29] <pitti> WTH is going on with my ISP???
[10:29] <crimsun> trolls are using dcc send exploits
[10:29] <pitti> crimsun: thanks, I left the channel
[10:31] <Keybuk> crimsun: can we not kick them?
[10:31] <bddebian> pitti: Why didn't you remove 'HAPPY DAPPER DAY' too? :-)
[10:32] <crimsun> they're being kicked/k-lined whatnot, but they keep rejoining on different hosts
[10:32] <pitti> bddebian: s/day/5 years/? :)
[10:32] <bddebian> :-)
[10:32] <wasabi_> Sure wish the gov cared about people's compromised computers being used to attack others.
[10:39] <Keybuk> whose gov?
[10:39] <bddebian> The government?
[10:40] <pitti> Keybuk: Is there any doc/spec about the 'Config-Version:' field in dpkg -s?
[10:40] <Keybuk> the what field?
[10:40] <pitti> Keybuk: in short, is this guaranteed to only show up on removed, but not purged packages?
[10:40] <pitti> oh, ok
[10:41] <wasabi_> ya know, any of em.
[10:41] <wasabi_> the one where the zombies are at. :0
[10:41] <pitti> well, I'll just use the Version: then and grep for 'config-files' in Status: then to be on the safe side
[10:57] <Seveas> pitti, you should upgrade your router firmware, /msg ubotu dcc for the CVE link
[10:58] <pitti> Seveas: hm, that's not under my control
[10:58] <Seveas> pitti, workaround: connect to freenode on port 8001
[10:58] <Seveas> that exploit is going on on all big irc networks :/
[10:58] <mdz> tseng: do you intend to expand beagle-integration and make it a proper edgy goal?
[10:58] <pitti> Seveas: thank you! I'll forward this to my ISP
[10:59] <Seveas> pitti, isp can't do much about it
[10:59] <pitti> Seveas: our house router (ISP WiFi <-> house ethernet) is an old P60 running woody :)
[10:59] <Seveas> hmmm
[11:00] <sivang> Seveas: what is the exploit symptoms ?
[11:00] <Seveas> that is odd - the bug that is causing this according to the CVE is a bug in stateful packet inspection in netgear home-routers
[11:00] <Seveas> sivang, someone sends a a malformed DCC request and the router barfs
[11:01] <Seveas> and disconnects you
[11:01] <sivang> Seveas: I see, luckily, I'm using a remote machine for IRC
[11:04] <sivang> (that should be heavily protected IIRC)
[11:05] <HiddenWolf> mdz, there was a thread on the mailing list about integrating tracker, does that stand any chance?
[11:24] <mdz> HiddenWolf: it seems both less mature and less complete than beagle
[11:26] <HiddenWolf> mdz, I guess, but upstream gnome seems to be going to start using it, it doesn't require mono and a heap of ram, and jamiecc is very interested in promoting tracker
[11:26] <mdz> HiddenWolf: jamiemcc is the maintainer of tracker, so yes, I imagine he would be :-)
[11:27] <mdz> we'll likely ship mono in the desktop anyway for f-spot and tomboy
[11:27] <HiddenWolf> on the cd?
[11:32] <Keybuk> mdz: ping?
[11:33] <mdz> Keybuk: pong
[11:33] <Keybuk> https://merges.ubuntu.com/main.html
[11:33] <Keybuk> ^ the ones without a red dot have already seen at least one upload to edgy
[11:34] <mdz> Keybuk: hmm, but we can't tell whether that upload was a merge or not, I suppose
[11:34] <Keybuk> right, there's no easy way to tell that sadly
[11:34] <mdz> I think we can live with that
[11:34] <Keybuk> but for the most part, it's probably true
[11:34] <mdz> Keybuk: can we sort those to the bottom?
[11:34] <slomo> hm is there any reason for type-handling not beeing in main other than that nobody has written a report yet? otherwise i would write one now ;)
[11:34] <Keybuk> slomo: we explicitly keep it out of main with all our effort and power available to us
[11:34] <pitti> slomo: it is generally regarded as crackful
[11:35] <Keybuk> mdz: bottom of each priority band, or bottom in general?
[11:35] <pitti> slomo: rewriting debian/control on the fly --> baaad things happen
[11:35] <slomo> ok, fine... i'll continue to patch it out of everything then :)
[11:35] <mdz> Keybuk: if it were more precise I'd say bottom in general; browsing over it I'm not sure
[11:35] <Keybuk> mdz: let's leave them in order for now, and then decide in a few days
[11:35] <Keybuk> it's a trivial enough script to change
[11:36] <mdz> Keybuk: seem to be too many false positives
[11:36] <Keybuk> I suspect right now they're largely false positives, by next week, they'll be mostly true
[11:36] <mdz> Keybuk: pychecker has not been uploaded to edgy that I can see
[11:36] <Keybuk> mdz: right ... and it has a red dot :p
[11:36] <mdz> Keybuk: oh, *without* a red dot
[11:37] <Keybuk> red dot = needs doing :)
[11:37] <mdz> Keybuk: in that case, it looks much more reasonable :-)
[11:37] <mdz> I think it'd be best to have two tables, with the red dots in the first table and the rest in a second
[11:37] <mdz> both in priority order
[11:38] <mdz> and eventually the top list will go away
[11:38] <Keybuk> okies
[11:38] <mdz> a low-priority package which is untouched is more important than a high-priority one which has been merged already
[11:38] <mdz> at least until we've gotten through the first round
[11:41] <Keybuk> I think there was a spec about that
[11:41] <Keybuk> basically make sure we at least look at what Debian did
[11:42] <slomo> pitti: i'll merge gnutls12 if you don't mind :)
[11:42] <pitti> argh, argh, no
[11:42] <pitti> slomo: please do not touch gnutls and libtasn1-2 for now
[11:43] <slomo> ok, np
[11:43] <pitti> these are pretty messy in Debian now
[11:43] <pitti> slomo: they seem to be in the middle of the gnutls13 transition, libtasn1-2 security patch was reverted, and the gnutls12 package doesn't build all packages any mroe (and misses the libtasn1-2 api change patch)
[11:44] <slomo> pitti: no idea, i didn't look at it yet... i just selected a random package and saw that you were the last uploader ;) is sdl fine with you or do you want to care for it? :)
[11:45] <pitti> slomo: yes and no
[11:45] <mdz> the conflict markers are nice
[11:45] <pitti> slomo: thanks for your help
[11:45] <slomo> pitti: np :) i wonder why almost all the packages i randomly choose were previously uploaded by you :P
[11:46] <pitti> slomo: I'd like to do g-v-m and cupsys myself (the latter because it's in svn), the rest is fair game
[11:46] <pitti> slomo: I touched a lot of packages due to POT file building stuff and such :)
[11:47] <slomo> pitti: i won't touch printing stuff anyway... i hate printers and they usually hate me too ;)
[11:47] <Keybuk> mdz: https://merges.ubuntu.com/main.html   better?
[11:47] <pitti> slomo: likewise :)
[11:47] <sivang> pitti, slomo : hehe
[11:47] <mdz> Keybuk: no
[11:47] <mdz> Keybuk: not better
[11:47] <mdz> Keybuk: ROCKING
[11:47] <Keybuk> mdz: no?
[11:48] <Keybuk> heh
[11:48] <mdz> Keybuk: I think we can lose the red dots
[11:48] <mdz> unless you're really attached to them
[11:48] <pitti> now they have reversed semantics
[11:48] <Keybuk> mdz: I was just trying to lose those
[11:48] <Keybuk> only managed half of them
[11:48] <mdz>    - add -D_LARGEFILE64_SOURCE on top of $(getconf LFS_CFLAGS)'s output
[11:48] <mdz>      to fix lfs  support (closes: #13647)
[11:49] <mdz> now why in the world would that work?
[11:49] <Keybuk> gone now
[11:49] <Keybuk> mdz: syslog? :)
[11:49] <mdz> Keybuk: yes
[11:49] <Keybuk> mdz: chmj? :)
[11:49] <mdz> Keybuk: yes
[11:49] <Keybuk> mdz: broken? :)
[11:49] <mdz> just happened to notice it because it caused a conflict
[11:49] <mdz> doesn't look right
[11:50] <Keybuk> it doesn't work
[11:50] <mdz> oh, I see what happened
[11:50] <mdz> it was a Debian bug, and the person filing it suggested that as a fix
[11:50] <mdz> people who knew better rejected it in Debian
[11:53] <mdz> http://bugzilla.ubuntu.com/show_bug.cgi?id=13647
[11:53] <Ubugtu> Ubuntu bug 13647 in sysklogd "sysklogd: Large file support is broken in the sarge version" [Major,Resolved: fixed]  
[11:55] <mdz> The packet loss hits!  The packet loss hits!  You feel slower.
[11:57] <mdz> `bsdmainutils_6.1.3.tar.gz' at 16384 (9%) 2.1K/s eta:72s [Receiving data] 
[11:57] <pitti> mdz: be glad that you weren't the last one touching OO.o :-P
[11:57] <Keybuk> A GIGABYTE!!!OJIKJSFJAF
[11:58] <mdz> it would take the same amount of time to download oo.o over a properly functioning path
[11:58] <mdz> lftp apparently gives up displaying the transfer rate as it approaches zero
[11:58] <Keybuk> mdz: oh, in case you didn't catch earlier; that status page now updates hourly
[11:58] <Keybuk> so it should pretty much be up to date with publisher runs
[11:59] <sivang> pitti: where do I set up locales to use "C" until locales are fixed?
[11:59] <Keybuk>   C* debian/patches/00list
[11:59] <Keybuk> *blink*  yeah, because that's SO binary
[11:59] <pitti> sivang: hm? they have been fixed for days
[11:59] <mdz> Keybuk: next you will tell me a graph will appear at the top showing the merge progress
[11:59] <Keybuk> mdz: I thought of that, but Riddell would give a DivideByZero exception
[11:59] <mdz> Keybuk: yeah, I saw one of those with 00list too
[11:59] <mdz> that is, noticed in passing in a REPORT, didn't look at it
[11:59] <pitti> Keybuk: don't forget the merge Karma
[12:00] <Keybuk> mdz: that probably means the entire thing was one big conflict
[12:00] <Keybuk> (which is how I detect binary files <g>)
[12:00] <sivang> pitti: hmm, maybe I need to reboot?
[12:00] <mdz> ha
[12:00] <pitti> sivang: restarting X should suffice
[12:00] <mdz> so the maintainer renamed all of the patches or something
[12:00] <mdz> 700542 bytes transferred in 356 seconds (1.9K/s)
[12:00] <mdz> I'm getting nostalgic
[12:00] <Keybuk> mdz: exactly
[12:00] <pitti> mdz: maybe s/patch/dpatch/ or so? happens
[12:01] <Keybuk> debian/patches/ubuntu_testsuite_tcl8.3.dpatch => debian/patches/10_tcl8.3_testsuite_failure.dpatch
[12:02] <Keybuk> I have noticed one mom bug ... it sometimes drops the bottom of _really_old_ changelogs
[12:03] <mdz> Keybuk: does it try to parse them?
[12:03] <Keybuk> mdz: yup, parses, then version sorts
[12:04] <Keybuk> oh, figured the bug, wasn't appending any trailing non-changelog junk
[12:04] <Keybuk> fixed
[12:04] <mdz> right
[12:04] <mdz> changelogs are not very compliant
[12:04] <Keybuk> mdz: it was more sane than previously ... which involved randomly stripping and wiggling patch hunks until they fitted
[12:04] <Keybuk> usually this resulted in mom getting the changelog entirely backwards
[12:05] <mdz> I wonder what would happen if I submitted my ubuntu calendar patch to bsdmainutils to debbugs
[12:06] <Keybuk> "ubuntu calendar patch"? :)