[12:37] <slangasek> yuck, why do the gutsy mythtv packages depend on msttcorefonts?
[12:37] <man-di> ScottK: today I saw that it doesnt seem to work on i386
[12:37] <man-di> ScottK: in debian at least
[12:37] <ScottK> man-di: The proposed revision or the current one?
[12:38] <ScottK> superm1: See slangasek's comment ^^^
[12:38] <man-di> -4 is the current one in debian, yes
[12:38] <doko> ScottK: its universe, if you're ok with the upload, pleae go ahead. there's a reason that I'm still awake on Saturdaynight :-(
[12:39] <ScottK> doko: I'm fairly highly allergic to Java (but know others aren't).  If you think technically (from a Java perspective) it's a good change, I'll see if I have time to build/test/uplod it.
[12:39] <man-di> ScottK: testing on i386 would be needed, I dont really know why it doesnt work on i386 in debian
[12:40] <doko> ScottK: please go ahead, and please convince man-di to get motu status himself so he can do it himself ;)
[12:40] <ScottK> OK.  Well my Gutsy box has 256MB of RAM, so I don't think I'm the one to test it.
[12:41] <man-di> ScottK: my machine has 2 GB and I get OOMs when buidling eclipse without tricks since doko uploaded GCJ 4.2 :-/
[12:42] <mlind> ScottK: roll the package in PPA maybe ?
[12:42] <ScottK> man-di: I've got a server I can build it on with 4GB ram.  It's the testing not the building that's the trouble.
[12:42] <ScottK> mlind: If you've got a PPA, you can do that.
[12:42] <man-di> ScottK: aah, okay
[12:43] <ScottK> mlind: At this point the only option I would consider is the small one.
[12:44] <mlind> ScottK: yes, I'd do that too.
[12:44] <man-di> doko: BTW: I dont really see a reason to make me a MOTU, after all I dont use Ubuntu
[12:44] <ScottK> man-di: I don't see that as a hard requirement.
[12:44] <pochu> night all
[12:45] <man-di> ScottK: for you, but for me ;-)
[12:45] <mlind> can one yet delete packages from PPA?
[12:47] <ScottK> mlind: --> #launchpad.
[12:48] <man-di> ScottK: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446438 was reported against the 'fixed' version in Debian
[12:48] <ubotu> Debian bug 446438 in eclipse-jdt "eclipse-jdt: ant editor can not open build.xml" [Important,Open]
[12:48] <man-di> ScottK: cu
[01:58] <nenolod> Adri2000, btw le_vert (audacious-plugins launchpad #123150) can be very stubborn
[01:58] <ubotu> Launchpad bug 123150 in audacious-plugins "Audacious unable to play MP3 streams" [Medium,In progress]  https://launchpad.net/bugs/123150
[01:58] <nenolod> Adri2000, so i don't know how cooperative he will be
[01:58] <nenolod> ;p
[02:03] <Kmos> Can someone archive this one? http://revu.tauware.de/details.py?upid=377
[02:03] <Kmos> thanks
[02:03] <Kmos> or nuke it :)
[02:03] <Kmos> it's NEW on debian now..
[02:06] <Kmos> http://revu.tauware.de/details.py?upid=363
[02:06] <Kmos> and this one too
[02:52] <imbrandon> anyone here that uses fluxbox ?
[02:53] <imbrandon> he's afk
[02:53] <imbrandon> heh
[02:54] <_MMA_> Oh yeah. He said he had to lay down.
[02:54] <imbrandon> i just installed fluxbox ( not fluxbuntu ) on gutsy, started a flux session and right click isnt bringing up the menu
[02:55] <imbrandon> i even had to start xterm from tty1 with `DISPLAY=:0 xterm`
[02:55] <imbrandon> heh
[02:56] <imbrandon> sux to be me atm :)
[02:56] <_MMA_> imbrandon: Talk to nothlit in #fluxbuntu
[02:57] <imbrandon> k
[03:06] <persia> slangasek: Sorry.  Sleeping.  ceclilia needs architecture-specific drops.  snort doesn't need a merge: the Ubuntu changes were adopted by Debian.  Thank you for gxmms and zeroc-icee-java.
[03:08] <imbrandon> _MMA_: wow people in that channel are harsh :)
[03:09] <_MMA_> lol really?
[03:09] <imbrandon> persia: test it on gutsy ?
[03:09] <_MMA_> Joe wouldnt let that happen. The kids must be at play.
[03:09] <persia> imbrandon: manually execute `update-menus`, which should fix it.  There's something funny about menu generation on package install (or initial install).
[03:09] <persia> imbrandon: Yes.  Test on gutsy.
[03:09] <imbrandon> persia: if you can get me a gutsy i386 package built from that i'd be happy to but i'm on a p200 and dont wanna compile it
[03:10] <imbrandon> lol
[03:10] <slangasek> persia: for snort, the scripts I have available don't appear to let me override the fact that snort has previously diverged from Debian
[03:10] <persia> slangasek: Understood.  I'll wait for someone else.
[03:19] <imbrandon> persia: should a session restart be required after update-menus ?
[03:19] <persia> imbrandon: It shouldn't, but you might need to wait a minute.  You'll want to make sure to run it system wise (`sudo update-menus`)
[03:19] <persia> s/wise/wide/
[03:19] <slangasek> persia: as for cecilia, the problem package is an arch: all package; I'm not sure why it wasn't removed automatically when the arch: any binaries became available, but the tools don't work for cleaning this up either
[03:20] <imbrandon> right
[03:20] <imbrandon> ok how much longer do i have for a universe upload ?
[03:20] <persia> slangasek: It's not arch: all anymore :)
[03:20] <slangasek> persia: um, the problem package you're asking to have removed *is*
[03:20] <persia> slangasek: Are you sure?  I thought there was a script for binary removal (if a less popular one).
[03:20] <persia> slangasek: Right.  Sorry.
[03:24] <slangasek> persia: the script for binary removals doesn't appear to DTRT with -a all
[03:25] <persia> slangasek: Thanks for trying.  I keep finding corner cases :)
[03:26] <persia> imbrandon: I think binary uploads have about 22 hours left, so source uploads should be earlier.
[03:26] <StevenK> For universe, you have more than 22 hours
[03:27] <imbrandon> we dont do binary upload iirc
[03:27] <imbrandon> anyhow so i'm good for now with universe correct ?
[03:28] <imbrandon> man i hate "comming back" at the end of a cycle
[03:29] <persia> StevenK: I thought there was a new announcement that we had until Monday 0:01 UTC.  Is my math broken?
[03:29] <persia> imbrandon: From what I understood about the archive, you'll want to have your builds done before the hard freeze (I may be mistaken).
[03:30] <persia> imbrandon: and, yes, now is safe to upload.
[03:32] <imbrandon> ok i *think* my final upload for gutsy is done, probably not though
[03:35] <StevenK> persia: When ScottK and I were talking to pitti, he said until Wednesday for universe - we (being motu-uvf) have to approve it.
[03:35] <StevenK> Anyway, I'm out.
[03:36] <persia> StevenK: Ah.  I'm following https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002450.html
[03:38] <imbrandon> well its only a revision anyhow not a UVF , worst case it will be rejected
[03:38] <imbrandon> looks like one more reboot bbiab
[03:50] <bddebian> persia: Are you still working on esniper? :-)
[03:50] <persia> bddebian: Rather, I'M hoping someone with an ebay account will.  We've about 4 hours left on the auction.
[03:51] <DktrKranz> persia, need a hand?
[03:52] <persia> DktrKranz: very much so.  could you build http://http.us.debian.org/debian/pool/main/e/esniper/esniper_2.17.0-1.dsc for gutsy, and see if it works?
[03:52] <DktrKranz> what I need to do to discover if it works properly?
[03:53] <persia> minghua was nice enough to host http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140167990751 for use to test against.
[03:53] <joejaxx> imbrandon: the issue is update-menus
[03:54] <joejaxx> when it forks duing a dpkg execution on a package that has the menus add hook it never returns after dpkg is done
[03:56] <persia> The fork is a good thing, but the return hook is just plain broken.
[03:56] <superm1> slangasek, unfortunately the themes call for arial right now.
[03:57] <joejaxx> persia: yeah unfortunately
[03:57] <slangasek> superm1: <whimper>fix the themes?</whimper>
[03:57] <superm1> slangasek, well we were waiting for the liberation fonts to come through
[03:57] <joejaxx> persia: which stinks for us that use the debian menu :D ;)
[03:57] <superm1> and we were going to make a package called fake-msttcorefonts then
[03:58] <superm1> that symlinked those to the font names that msttcorefonts provided
[03:58] <slangasek> heh
[03:58] <persia> joejaxx: Yep.
[03:58] <slangasek> so dejavu sans isn't good enough?
[03:58] <superm1> so that no patching was needed.  but since those didn't ever come through
[03:58] <joejaxx> and if iirc we are close to hard no more packages freeze
[03:58] <superm1> no, i did some experiments with other fonts and it looked pretty tacky
[03:58] <joejaxx> or past it
[03:58] <joejaxx> :P
[03:58] <slangasek> aww
[03:58] <superm1> compared to how they look with the msttcorefonts
[03:58] <superm1> so hopefully licensing on the liberation fonts gets sorted during hardy, so that we can use those
[04:02] <DktrKranz> persia, built. now what?
[04:04] <bddebian> Now install and start bidding ;-)
[04:05] <persia> DktrKranz: You'll want to look at sample_config and sample_auction in /usr/share/docs/esniper/
[04:11] <DktrKranz> is it mandatory to test it right now? it's quite late here and I should have some sleep...but if you need it in short time, I can give it a better try
[04:11] <persia> DktrKranz: We hav 3 hours & 53 minute left in our test.  If you don't have time, could you put up an i386 binary for imbrandon?
[04:12] <DktrKranz> no problem at all...just a second
[04:12] <persia> DktrKranz: Thanks a lot.
[04:12] <imbrandon> DktrKranz: thanks
[04:13] <DktrKranz> and sorry to not been able to test it directly as I wish...it's 4:15 here and I was busy in bug squashing :)
[04:13] <persia> DktrKranz: No worries.  That's why we're a team :)
[04:16] <DktrKranz> imbrandon, www.linuxdc.it/esniper_2.17.0-1_i386.deb
[04:16] <imbrandon> DktrKranz: sweet, getting it now
[04:16] <DktrKranz> built on up-to-date gutsy
[04:16] <imbrandon> k, good thats what i'm running
[04:17] <DktrKranz> anyway, it took me just a couple of minutes
[04:17] <DktrKranz> if you ever need to recompile, it will not be a waste of time
[04:18] <persia> imbrandon: Can you snipe by yourself, or do you need someone else to compete with you?
[04:18] <imbrandon> well i just dident want to install all the build tools and buld aon a p200
[04:18] <imbrandon> persia: not sure, never used this app in my life, i just have an ebay account and wanted to help
[04:18] <DktrKranz> I'm going to sleep, if you don't need something else
[04:18] <persia> DktrKranz: Thanks a lot.  Sleep well.
[04:19] <imbrandon> persia: ok its installed, any "quick start" tips for what you need testede
[04:19] <imbrandon> tested*
[04:19] <imbrandon> DktrKranz: thanks
[04:19] <DktrKranz> thanks to you, gnight
[04:19] <imbrandon> persia: ok its installed, any "quick start" tips for what you need testede
[04:20] <persia> imbrandon: You'll want to create an auction file for http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140167990751, and run esniper in the background.  Someone else will outbid your last bid, and near the auction end, esniper should make a quick bid so you win.
[04:25] <imbrandon> persia: ok i think its running correctly , someone else will have to test near the end of the auction i guess ( i'll leave it running )
[04:25] <imbrandon> Auction<PHONE_NUMBER>51: Ubuntu 7.10 CD Image file
[04:25] <imbrandon> Time remaining: 2 hours 39 mins 36 secs (9576 seconds)
[04:25] <imbrandon> End time: 14/10/2007 00:04:35
[04:25] <imbrandon> Currently: 0.01  (your maximum bid: 0.75)
[04:25] <imbrandon> # of bids: 1
[04:25] <imbrandon> High bidder: holtsclawb!!!
[04:25] <imbrandon> Latency: 0 seconds
[04:25] <imbrandon> Sat Oct 13 21:24:59 2007: Sleeping for 1 hours 39 minutes
[04:25] <imbrandon> it wont check again for 1.5 hours
[04:25] <persia> imbrandon: What timeout did you use for the snipe?
[04:26] <imbrandon> i dunno i ran it like this ....
[04:26] <imbrandon>  esniper -u holtsclawb -P<PHONE_NUMBER>51 0.7
[04:26] <imbrandon> err
[04:26] <imbrandon>  esniper -u holtsclawb -P<PHONE_NUMBER>51 0.75
[04:27] <persia> imbrandon: Thanks.
[04:27] <imbrandon> e.g -u user -P prompt for pass and auction number and price
[04:27] <imbrandon> i'll leave it running in the background
[04:28] <persia> Could someone please bid $0.60 on  http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140167990751?
[04:28] <bddebian> I'll try if I can remember my password :-)
[04:29] <persia> bddebian: Thanks.
[04:29] <imbrandon> afk one sec
[04:30] <persia> imbrandon: Just to make sure, we want someone other than you to be the high bidder :)  You should bid 0.75 near the end, and win anyway.
[04:30] <ScottK> StevenK: We got revised on the Wed thing today.
[04:31] <ScottK> StevenK: They need to starting copying the entire archive for -updates/-security at the same time they start making the CDs.
[04:31] <bddebian> OK, .60 bid
[04:31] <persia> bddebian: Thanks.
[04:31] <bddebian> Have to be of some use on occasion ;-)
[04:33] <ScottK> StevenK or zul: Would you please ack Bug 152423 (patch currently is totally broken so downside risk is nil).
[04:33] <ubotu> Launchpad bug 152423 in ktoon "[Gutsy Sync]  Please sync KToon (0.8.1-1) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152423
[04:34] <ScottK> StevenK and zul: I'm interested in what you think about Bug 151699 (I am uncertain on this one).
[04:34] <ubotu> Launchpad bug 151699 in gdc-4.1 "[UVFe]  gdc-4.1 0.25 new upstream release" [Undecided,Incomplete]  https://launchpad.net/bugs/151699
[04:48] <persia> Should motu-uvf be subscribed for review prior to the completion of testing, or only after verification?
[04:51] <RAOF> Yay, gdm starts again!  (bug #152505)
[04:51] <ubotu> Launchpad bug 152505 in gdm "gdmgreeter segfaults when XRandR is not available" [Undecided,New]  https://launchpad.net/bugs/152505
[04:56] <TheMuso> Sweet. Uses Ape v2/c
[04:56] <TheMuso> ugh
[04:56] <TheMuso> wrong channel
[05:19] <ScottK> persia: Subscribe motu-uvf when you are ready for motu-uvf to decide something (I'd say after).
[05:20] <persia> ScottK: That makes sense.  Thanks for the confirmation.
[05:21] <ScottK> For?
[05:21] <persia> http://offer.ebay.com/ws/eBayISAPI.dll?ViewBids&item=140167990751 for bug #152503
[05:21] <ubotu> Launchpad bug 152503 in esniper "Please sync esniper _2.17.0-1 (universe) from Debian (main)" [Undecided,New]  https://launchpad.net/bugs/152503
[05:21] <ScottK> Right.
[05:25] <ScottK> persia: Do you have time in your schedule to look at a proposed Eclispe revision?
[05:26] <persia> ScottK: That looks like a merge.  I'd really prefer if someone else hit it (as there doesn't seem to be anyone else tracing RC bugs).
[05:28] <ScottK> persia: There's a minimal debdiff option which I think we should pursue, but I don't have enough RAM on my gutsy machine to build/test it.
[05:28] <ScottK> RAOF: How about you?  Up for fixing eclipse?
[05:28] <persia> ScottK: If you just need build cycles, I can do that.  Where's the debdiff?
[05:28] <RAOF> ScottK: Uuuuuur...
[05:28] <RAOF> ScottK: I'm up for *building* eclipse?
[05:28] <ScottK> http://launchpadlibrarian.net/9973602/debdiff_small.txt
[05:29] <persia> RAOF: Thanks.
[05:29] <ScottK> There's the debdiff.  RAOF, if you would, since persia has a lot of stuff on his plate.
[05:29] <RAOF> Anyone want to review bug #152505 before I subscribe u-m-s?
[05:29] <ubotu> Launchpad bug 152505 in gdm "gdmgreeter segfaults when XRandR is not available" [High,New]  https://launchpad.net/bugs/152505
[05:33] <persia> Anybody around using xen?  Could you confirm that gutsy xenman doesn't crash on start?
[05:37] <ScottK> RAOF: You know about 64bit stuff, right?
[05:38] <ScottK> RAOF: Any idea why https://launchpad.net/ubuntu/+source/libgnomedb3/3.0.0-2build1 would build on AMD64, but FTBFS on IA64?
[05:40] <RAOF> ScottK: Because IA64 is wierd and crazy?
[05:40] <slangasek> because the ia64 platform always has bits set in the high 32-bits of a pointer
[05:40] <slangasek> whereas on amd64 it's a crapshoot
[05:41] <RAOF> That looks a likely culprit, yes.
[05:42] <ScottK> Right, but knowing little about 64bit stuff, I was suprised that'd be a problem on IA64 and not AMD64.
[05:44] <slangasek> no, that's not the reason
[05:44] <RAOF> It's possible that it's not actually a 64bit problem, but something strange with the IA64 linking process.
[05:44] <slangasek> try fixing the implicit function declarations
[05:45] <slangasek> including the headers that contain the declarations? :)
[05:45] <persia> The linking is fine, it's just that the result SEGVs.  I suspect slangsek is correct, and the non-portability assumes that a 64-bit integer can be safely treated as two 32-bit integers.
[05:46] <slangasek> right, because if you try to use a function before importing it python immediately tells you to get bent, on any arch. :)
[05:50] <slangasek> pff, I don't even see where libgnomedb-3.0-scan.c is coming from, it's apparently not part of the libgnomedb3 source
[05:53] <persia> Does sbuild 0.56 work for anyone else?  It's not on my list, but I'm still pinned at 0.53.
[05:58] <slangasek> ScottK: well, this is some serious gnome voodoo in gtk-doc-tools; it's the generated source that's missing the includes, I have no idea how to tell it what headers to include
[05:59] <ScottK> slangasek: OK.  Well if it's serious vodoo to you, then I'm not even going to go near it.  I guess it'll just have to stay dead.  Thanks for looking.
[05:59] <slangasek> it's probably less serious to someone who works more with GNOME packaging
[06:01] <RAOF> I've got a friend up from Hobart, I'm not going to have time to expose that voodoo.
[06:12] <slangasek> ok, libgnomedb-3.0.types is the sourceful bit that declares the types to reference
[06:12] <slangasek> that's doc/C/libgnomedb-3.0.types
[06:13] <slangasek> it includes records for gnome_db_entry_foo, but several of these (the ones with warnings in the build log) have no public headers that are installed in libgnomedb3-dev, nor are those headers referenced at the top of libgnomedb-3.0.types itself
[06:14] <slangasek> so either those headers need to be made public (including them from libgnomedb.h seems to be the standard way), or the references to those types should be removed.
[06:19] <persia> slangasek: That makes sense (in a twisted way).  Why does it work for !ia64?
[06:19] <slangasek> because on ia64, the high 32-bits of a pointer address are non-empty?
[06:20] <slangasek> so if the compiler doesn't have a declaration of the function, it doesn't know it returns a pointer (actually a GType, which much to my frustration is typedefed as an int rather than a pointer, suppressing a relevant compiler warning); which means it defaults to int, which is always 32-bit and truncates the return value
[06:21] <slangasek> so then the code takes what should be a valid pointer, and walks off into nowhere in memory -> segfault
[06:21] <persia> Aha.  So it's a compiler parsing issue with unknown types.  That makes sense.  Why isn't it a compiler bug?
[06:21] <slangasek> because the compiler isn't doing anything wrong
[06:22] <slangasek> it's behaving exactly as it's told
[06:22] <slangasek> it gives a warning, which is as much as it's supposed to do when invoked this way; it's up to the developers to notice the warning and fix the bug
[06:23] <persia> Ah, never mind.  I'm missing the placement of GType.  Thanks for the explanation, but I suspect I need to look at much more before I have a full understanding (and should get back to emulating a buildd)
[06:23] <ScottK> slangasek: Any idea of how much longer the i386 buildd's are going to be occupied with language packs?
[06:24] <slangasek> ScottK: no clue
[06:24] <ScottK> OK.  Just getting a bi t antsy.
[06:25] <ScottK> Hello Hobbsee.
[06:26] <slangasek> where does one look to see that they /are/ occupied with language packs? :)
[06:26] <ScottK> Hobbsee: Would you be up for a quick motu-uvf ack of bug 152423 (it's a package doesn't work at all -> works at least some kind of upload).
[06:26] <ubotu> Launchpad bug 152423 in ktoon "[Gutsy Sync]  Please sync KToon (0.8.1-1) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152423
[06:26] <ScottK> slangasek: I look here, https://launchpad.net/ubuntu/gutsy/+builds?build_text=&build_state=building but I'm sure there are better places
[06:26] <slangasek> well, not for me there probably arent'
[06:28] <ScottK> persia: Bug #152519 acked by me.  Maybe Hobbsee will look at it too.
[06:28] <ubotu> Launchpad bug 152519 in sqlfairy "Please sync sqlfairy 0.08.001-1 (universe) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152519
[06:31] <persia> ScottK: Thanks.  Soon...
[06:38] <ScottK> persia: I'll have a look at uus now that you mention it.
[06:38] <ScottK> RAOF: How's eclipse?
[06:38] <persia> ScottK: If there's anything not appropriate for gutsy, would you mind adding a comment indicating this, and asking for preparation for hardy?
[06:39] <ScottK> persia: I was just thinking that exact same thing.  Absolutely.  I've already done that more than once on REVU.
[06:39] <persia> ScottK: Perfect :)
[06:40] <Hobbsee> hiya slangasek
[06:41] <ScottK> persia: You looked at the openct patch and decided not to upload it.  How strongly do you feel about that?
[06:41] <ScottK> IIRC
[06:41] <persia> ScottK: Bug#?
[06:42] <ScottK> persia: Bug #125054
[06:43] <ubotu> Launchpad bug 125054 in openct "openct broken by ubuntu udev setup" [Undecided,Confirmed]  https://launchpad.net/bugs/125054
[06:44] <persia> ScottK: Not very strongly.  I'd like to see someone other than upstream test it in gutsy, or to understand where $MODALIAS comes from.  With either of those, I'd upload.
[06:45] <ScottK> persia: Based on it's backported from the upstream svn and it seems the package is fairly broken, I'm inclined to upload it.
[06:45] <ScottK> Hmmm
[06:47] <persia> ScottK: Don't let me block you.  I'm being conservative because I don't understand one clause.  If $MODALIAS is always undefined, everything should work fine (and the previous script appears like it shouldn't work)
[06:47] <ScottK> persia: OK.  Based on that, I'll go for it.  Thanks.
[06:48] <persia> ScottK: Sure.    I'm dead without tab completion.
[06:51] <ScottK> Hobbsee: How about the ktoon UVFe?
[06:53] <Hobbsee> sorry, dealing with emial
[06:53] <ScottK> No problem.
[06:53] <persia> imbrandon: Around?  I just want to make sure that the esniper process is still running smoothly: the auction expires in 11 mins 38 secs
[06:53] <ScottK> Hobbsee: How about persia's sqlfairy UVFe?
[06:54] <Hobbsee> ScottK: just ack'd that too
[06:54] <Hobbsee> ScottK: right, so now i'm requested not to accept things.
[06:54] <persia> Hobbsee: Thanks.  I'll subscribe the next team in the list :)
[06:55] <Hobbsee> persia: no problem.  i did it via email, so it should just work
[06:55] <ScottK> Hobbsee: Urgh.
[06:55] <Hobbsee> oh no!
[06:55] <persia> heh
[06:55] <Hobbsee> oh, no, it's to a separate mailing list.
[06:55] <persia> Hobbsee: Thanks for pushing it along :)
[06:55] <Hobbsee> persia: slangasek may do a bunch of processing.  right now, it's as if i dont have access to any of it :(
[06:56] <persia> 3 RC syncs pending in the u-a-a queue :)
[06:56] <imbrandon> persia: yea it will wakeup in 6 minutes
[06:56] <imbrandon> it said
[06:56] <persia> imbrandon: Excellent.  Thank you.
[06:57] <imbrandon> Auction<PHONE_NUMBER>51: Ubuntu 7.10 CD Image file
[06:57] <imbrandon> Time remaining: 7 mins 49 secs (469 seconds)
[06:57] <imbrandon> End time: 14/10/2007 00:04:35
[06:57] <imbrandon> Currently: 0.55  (your maximum bid: 0.75)
[06:57] <imbrandon> # of bids: 2
[06:57] <imbrandon> High bidder: bddebian (NOT holtsclawb)
[06:57] <imbrandon> Latency: 0 seconds
[06:57] <imbrandon> Sat Oct 13 23:56:46 2007: Sleeping for 5 minutes 39 seconds
[06:57] <persia> Nice latency :)
[06:58] <imbrandon> :)
[06:59] <imbrandon> lol
[06:59] <imbrandon> hrm why would one do such a thing
[07:02] <persia> imbrandon: Bootstrapping.  Often when building compilers or interpreters, you need to build a framework to then build the self-hosted true system.
[07:03] <imbrandon> ahh like fpc
[07:03] <persia> Only 1 minute left...
[07:04] <persia> Cool.  It works!
[07:04] <persia> Thanks minghua, bddebian, imbrandon, and dktrkranz
[07:06] <imbrandon> persia: np
[07:07] <persia> ScottK: over to you: bug #152503
[07:07] <ubotu> Launchpad bug 152503 in esniper "Please sync esniper _2.17.0-1 (universe) from Debian (main)" [Undecided,New]  https://launchpad.net/bugs/152503
[07:08] <ScottK> persia: Ack.  Ask Hobbsee now...
[07:09] <persia> Hobbsee: Our last non-xen Debian RC in gutsy awaits your pleasure :)
[07:09] <Hobbsee> woot!
[07:09] <persia> Um.  s/RC/Grave RC/
[07:10] <Hobbsee> how's our sponsorship queue looking?
[07:10] <Hobbsee> debian bug 442369
[07:10] <persia> universe: 16, main: 20
[07:10] <ubotu> Debian bug 442369 in esniper "esniper: unable to find auction --> solved in CVS" [Grave,Fixed]  http://bugs.debian.org/442369
[07:10] <ScottK> Hobbsee: Not bad.  16 left many of which are debian dupes or pending SRUs
[07:10] <Hobbsee> we can search by subscriber now, from ubuntu itself
[07:10] <Hobbsee> so can get rid of teh debian dupes
[07:11] <persia> But https://bugs.launchpad.net/ubuntu/~ubuntu-universe-sponsors/ or https://bugs.launchpad.net/~ubuntu-universe-sponsors/ubuntu/ should do that.
[07:11] <Hobbsee> ack'd.
[07:11] <Hobbsee> oh nice!
[07:11] <Hobbsee> didnt know that was supported
[07:12] <persia> Hobbsee: It's not :(
[07:12] <Hobbsee> oh, should, right, yes.
[07:12] <ScottK> their/there
[07:12] <Hobbsee> although no one would ever ifnd it.
[07:13] <Hobbsee> it even got implemented in way under 6 months?  how nice is that?
[07:14] <persia> Hobbsee: You don't really want that.  I'd be asking you to try to figure out how to sync snort or drop cecilia as arch:all, neither apparently trivial.
[07:14] <Hobbsee> heh
[07:14] <Hobbsee> whta's wrong with cecilia?
[07:14] <Hobbsee> persia: i already have those powers - when it includes asking other people to do that, and they say yes.
[07:15] <persia> It used to be arch: all, and depended on csound.  csound assumes that 64 bit integers can be split so that the high half is flags, and the bottom half a pointer.  I uploaded an arch: many cecilia, but the arch: all binary is still floating around.
[07:15] <persia> Hobbsee: heh
[07:16] <Hobbsee> lamont: you around?
[07:16] <Hobbsee> seems not.
[07:16] <Hobbsee> lamont: when you wake up and come and see irc again, can you deal with persia's request, presumably in P-a-s?  thanks.
[07:16] <ScottK> persia: What version of snort are you trying to sync?
[07:17] <persia> ScottK: 2.7.0-6
[07:17] <persia> ScottK: The things that make it tricky are 1) it overrides previous Ubuntu changes (Debian adopted them), and 2) it introduces a NEW binary package.
[07:18] <ScottK> persia: I can solve #1 if slangasek can solve #2 ^^^
[07:18] <bluefoxicy> Removing linux-ubuntu-modules-2.6.22-13-generic ...
[07:18] <bluefoxicy> update-initramfs: Generating /boot/initrd.img-2.6.22-13-generic
[07:18] <bluefoxicy> Purging configuration files for linux-ubuntu-modules-2.6.22-13-generic ...
[07:18] <bluefoxicy> update-initramfs: Generating /boot/initrd.img-2.6.22-13-generic
[07:18] <persia> slangasek: ?
[07:18] <bluefoxicy> Can anyone guess what I'm doing?
[07:18] <ScottK> bluefoxicy: Flooding the channel.
[07:19] <bluefoxicy> scottk besides that
[07:19] <persia> bluefoxicy: distracting people from syncing snort?
[07:19] <ScottK> persia: He's the new release manager (and I believe is here and has archive admin powers to NEW the new binary).
[07:19] <ScottK> bluefoxicy: That's all I really noticed.
[07:19] <bluefoxicy> persia:  that too.  But I more meant REMOVING A KERNEL, and rebuilding its initrd 15 times in the process >.>
[07:19] <Hobbsee> persia: i can new the binary.
[07:20] <persia> Hobbsee: Great.
[07:20] <Hobbsee> like, without cjwatson eating me.
[07:20] <ScottK> Hobbsee: I'll see if I can upload it.
[07:20] <persia> ScottK: Can you fix #1?  Hobbsee will do #2.
[07:20] <Hobbsee> oh wait.  am i supposed to, based on saying i'd avoid the new queue?
[07:20] <ScottK> trying.
[07:20] <persia> Hobbsee: binary new, or source new?
[07:20] <Hobbsee> hm.  i think i was asked to wait until after the powers that be were consulted.
[07:20] <Hobbsee> persia: well, that's the question
[07:20] <ScottK> Hobbsee: Is it better to have the archive fixed with an incomplete paper trail or broken and documented?
[07:21] <Hobbsee> persia: i cant do source new, due to no paper trail, and licencing stuff.  but binary accepted mails get blackholed anyway.
[07:21] <ScottK> This is a binary NEW
[07:21] <Hobbsee> exactly
[07:21] <ScottK> So it should be fine, right?
[07:21] <Hobbsee> bluefoxicy: and we dont do kernels in this channel.
[07:21] <Hobbsee> ScottK: unsure.  we'll see :)
[07:22] <Hobbsee> ScottK: oh, it's universe?  no, i shouldn't, then.
[07:23] <ScottK> I'd settle for Hobbsee agrees to hunt someone down and make them do it before the deadline.
[07:23] <Hobbsee> i'm not their boss, i cant really hunt them down.
[07:23] <Hobbsee> but i'd expect that they would, yes
[07:23] <RAOF> ScottK: Taking *ages* to build.  Current load: 25.93
[07:24] <ScottK> RAOF: It does that.
[07:24] <ScottK> persia: So if I upload this and it the new package never makes it, are we better or worse off than if I don't upload it (snort).
[07:25] <persia> ScottK: i386 users are worse off.  Everyone else is the same.  All users can `apt-get install --build snort` and get a working system.
[07:25] <Hobbsee> ScottK: we'll find someone.
[07:25] <ScottK> Hobbsee: OK.
[07:26] <Hobbsee> even if i have to accept it, then someone else has to override.
[07:26] <ScottK> Well the syncpackage script made a useable .changes file, so I can do the upload.
[07:27] <ScottK> Hobbsee and persia: Unless one of you says don't, I'm going to dput snort momentarily.
[07:28] <ScottK> OK.  Done.
[07:29] <persia> ScottK: please also update bug #152205
[07:29] <ubotu> Launchpad bug 152205 in snort "Please sync snort 2.7.0-6 (universe) from Debian unstable (main)" [Undecided,Fix released]  https://launchpad.net/bugs/152205
[07:29] <ScottK> persia: Done
[07:29] <persia> (never mind)
[07:29] <persia> ScottK: Thanks.
[07:29] <ScottK> No problem.
[07:30] <persia> Any fortran people around?
[07:33] <ScottK> Hobbsee: I got the Waiting for approval mail for snort, so over to you as far as getting the RM and New stuff done ...
[07:35] <ubotu> Debian bug 432376 in semidef-oct "semidef-oct: FTBFS: /usr/bin/ld: cannot find -lgfortranbegin" [Serious,Fixed]  http://bugs.debian.org/432376
[07:36] <persia> Are updates to native packages considered New Upstream Versions?
[07:37] <ScottK> persia: Not really, but if it's big or scary asking isn't a bad idea.  Personally, I'd say as long as your sure you don't want someone to share the blame, go ahead.
[07:38] <persia> ScottK: Thanks.  I just wanted to make sure to comply with the procedures: if it was about blame, I would have just uploaded just about everything I've touched in the past couple days.
[07:38] <ScottK> Understand.  It's just a bit of a grey area.
[07:39] <ScottK> I think I've done enough damage for one night, so I'm off to bed.  Good night all.
[07:40] <ScottK> RAOF: If eclipse builds and installs, I'd say upload it.  I don't see a downside risk.
[07:49] <persia> Anyone around looking for a bitesize bug for Hardy?
[08:15] <nxvl> hi
[08:15] <nxvl> anyone here?
[08:18] <persia> nxvl: Heaps of people are here, but not everyone is watching :)
[08:18] <nxvl> heh
[08:18] <nxvl> u'r right
[08:18] <nxvl> i want to help fixing bugs on gutsy
[08:19] <nxvl> i have patch some bugs before
[08:19] <nxvl> but i don't know launchap very well
[08:19] <persia> nxvl: That'd be great.  We're really close now, so only certain bugs are getting approved.
[08:19] <persia> Would you like to help track down the release critical bugs fixed in Debian, that may be open in Ubuntu?
[08:21] <persia> Basically, one works from http://django.ajmitch.net.nz/rcbugs.  Look for a package that doesn't have a comment.  There are roughly four classes of bugs: the easiest to check are those that report "FTBFS" (failed to build from source).
[08:22] <persia> The easiest way for you to help would be to download the latest gutsy sources for the packages that might FTBFS on a gutsy system, and try to build them.  I'm happy to help if you have any questions.
[08:30] <nxvl> ok
[08:30] <nxvl> i will start now
[08:30] <nxvl> thnx
[08:31] <persia> nxvl: Thank you.  I'm working from the bottom, so I'd suggest starting from the top.  That way if we have a collision, we'll know we're done :)
[08:32] <nxvl> he
[08:32] <nxvl> :D
[08:33] <nxvl> persia: you are fixin FTBS too?
[08:35] <persia> nxvl: Sometimes.  For every bug in this list, there is a fix available from Debian, so usually one doesn't need to hunt and fix it.  Sometimes the new Debian version is a new upstream version, and then it requires deeper investigation, and a local Ubuntu fix.
[08:35] <nxvl> persia: i found one on eclipse, but it seems its done, am i ok?
[08:35] <persia> nxvl: I think RAOF is working on that one.  Try the next one :)
[08:36] <nxvl> persia: so, what you are saying is that i only need to find the debian patch?
[08:36] <nxvl> am i right?
[08:37] <persia> nxvl: For most of the packages, I find that the Ubuntu version doesn't actually FTBFS, so I just report that version X builds successfully in the comment.  If the Ubuntu version FTBFS, and Debian doesn't have a new upstream version, and there aren't local Ubuntu changes, I try building the Debian version.
[08:38] <nxvl> ok
[08:38] <nxvl> i will check, i need to go out some minutes y will brb
[08:39] <persia> If there are local Ubuntu changes, or a new Debian upstream version, one needs to try to merge the FTBFS fix into the Ubuntu package.  These are the hardest - I'd skip them unless you're really good at troubleshooting build problems.  We can always go back once we've marked all the ones that aren't a problem.
[09:12] <Hobbsee> they're done online ;P
[09:15] <minghua> Virtual sharp implementation is what Hobbsee is famous for.
[09:15] <Hobbsee> yes, the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!
[09:15] <minghua> BTW persia did you fix esniper?
[09:18] <persia> minghua: No.  Dima did.  Dktrkranz made a .deb, bddebian tried to buy the ISO, and imbrandon sniped.
[09:19] <minghua> Yeah, I saw the auction sniped, so I figure it has a good chance to have been fixed.
[09:19] <persia> minghua: Thanks a lot for hosting the auction.  Without that we couldn't have tested.
[09:20] <minghua> persia: No problem.  You are the one should be thanked since you started the whole thing.
[09:21] <persia> Nah.  Blame ajmitch.  He wrote the rc buglist hosting software
[09:22] <ajmitch> yes, blame me, there's nothing else I do
[09:22] <Hobbsee> exactly
[09:24] <ajmitch> I see you have mad archive powers now
[09:26] <Hobbsee> yeah, but i cant use them.
[09:26] <Hobbsee> or at least, have been asked not to use them.
[09:27] <Hobbsee> although technically i can probably still accept translations fine :P
[09:32] <lucas> ajmitch: do you still plan to work on your debian packages, or should they be orphaned, like pnet* ?
[09:34] <ajmitch> just orphan the lot of them then
[09:35] <Hobbsee> persia: use https://edge.launchpad.net/ubuntu/+filebug-advanced
[09:35] <Hobbsee> persia: as in, +filebug-advanced, not filebug
[09:35] <Hobbsee> you can probably write a greasemonkey script for it
[09:36] <persia> Hobbsee: Yes.  I use that every time.  I'd just like to be able to do something in http://launchpad.net/~persia/<whatever> to make it default.
[09:36] <Hobbsee> persia: greasemonkey script to make launchpad not suck.
[09:36] <Hobbsee> or file less bugs.
[09:36] <Hobbsee> persia: filing via email is good too
[09:36] <persia> Hobbsee: Umm...  There's got to be a third way.
[09:37] <persia> s/third/fourth/ : email bugs are ugly
[09:37] <Hobbsee> heh
[09:44] <nxvl> im back
[09:45] <nxvl> persia: can we patch a bug together so i can undestund better the proces?
[09:45] <nxvl> process*
[09:45] <persia> nxvl: Sure.  Look for an FTBFS bug, and let me know the package name.
[09:46] <nxvl> persia: pam-krb5-migrate
[09:47] <thekorn> persia, you could use python-launchpad-bugs for filing bugreports, like
[09:47] <thekorn> https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug#head-27dc45b0392cc14364bd08fc4484df026122c91f
[09:48] <persia> nxvl: That one has a comment, so someone started looking at it.  It indicates that someone needs to file a UVFe, so the first step is to look for any open or rejected UVFe request for the package in Launchpad.  The leftmost link on the bug line goes to the LP bug page.
[09:48] <persia> thekorn: Could you point me to an example bug filed with p-l-b?
[09:49] <nxvl> persia: mm, so where is that i need to look for a uncommented FTBFS bug? open the debian bug and looking whats there?
[09:49] <nxvl> persia: say in other word, search for an uncommented bug, read the debian bug report and then search if it's FTBFS?
[09:50] <persia> nxvl: Exactly.  If there's no comment, it either means that nobody looked at it yet, or nobody bothered to report what they discovered.  Do you want to continue with pam-krb5-migrate, or choose a different bug?
[09:50] <nxvl> s/sword/swords(/g
[09:50] <nxvl> persia: chose a diferent bug, so i start from the beginning
[09:50] <thekorn> persia, I'm filing all bugreport with py-lp-bugs , for example bug 150643
[09:50] <ubotu> Launchpad bug 150643 in python-launchpad-bugs "bug.sourcepackage is not 'None' if there is no package specified" [Undecided,New]  https://launchpad.net/bugs/150643
[09:50] <persia> nxvl: OK.  Let me know which package.
[09:50] <nxvl> persia: ok
[09:51] <nxvl> persia: searching
[09:51] <persia> thekorn: That looks nice?  Thanks.  I'm a little fixated on my workflow for gutsy, but I'll certainly start with that for hardy.
[09:51] <persia> s/?/!/
[09:55] <nxvl> persia: i found a FTBFS but for ppc and i have no ppc
[09:55] <persia> nxvl: OK.  Keep looking...
[09:55] <nxvl> persia: that was the cuestion
[09:55] <nxvl> persia: :D
[09:56] <nxvl> persia: asterisk-oh323
[09:58] <persia> nxvl: OK.  The first step is to try to build the Ubuntu version in gutsy.  You can easily download the source by running dget with an argument of the URL for the first "Grab" entry.
[09:58] <nxvl> persia: i can't use apt-get source?
[09:59] <persia> nxvl: That works too.
[10:00] <Hobbsee> thekorn: that looks nice!
[10:04] <persia> Most of my bugs are sync requests.  If you find a way to automate it that doesn't make for ugly bugs, and let's me complete the Rationale section, I'll be very happy.
[10:04] <persia> ls
[10:06] <Hobbsee> id ont work on launchpad :)
[10:06] <Hobbsee> i just bug them when it doesnt work.
[10:06] <Hobbsee> and tell them that they're on crack occasionally
[10:06] <persia> Hobbsee: Don't underestimate the value of persistent communication - it's accomplished more than all the coding put together.
[10:07] <Hobbsee> well, yeah.  that's probably part of the reason why thye documentation is getting somewhat sane
[10:07] <nxvl> persia: it necessary only a "make" doesn't it? i don't need to 'make install' it doesn't i?
[10:07] <persia> nxvl: It's necessary that one of debuild, pdebuilder or sbuild successfully compiles the package.
[10:08] <nxvl> persia: i'm kind of lost
[10:08] <persia> nxvl: Have you ever built a package before?
[10:08] <nxvl> persia: i don't need to 'make' it? instead of that i only need to debuild it?
[10:09] <persia> nxvl: debuild will call make (and other things), depending on the contents of debian/rules.
[10:09] <nxvl> persia: build a package as in make a .deb package?
[10:09] <persia> nxvl: Yes.  Convert a .dsc package into a .deb package.
[10:09] <nxvl> persia: oh! no i haven't
[10:10] <nxvl> persia: well, i have, but really long time ago
[10:10] <nxvl> persia: and don't remember it well
[10:10] <persia> nxvl: My apologies then - I've assumed too much.  You probably don't want to try to learn that chasing RC bugs in the last day before the hard freeze :)
[10:11] <nxvl> persia: i want to learn
[10:11] <nxvl> persia: i have made it, but long time ago
[10:11] <nxvl> persia: and i think with your help i can make it
[10:11] <nxvl> :D
[10:12] <persia> nxvl: It's probably too late for gutsy, but I'll recommend you work on some patches for some bugs that will get included in hardy.  One to start might be turning https://lists.ubuntu.com/archives/ubuntu-motu/2007-October/002448.html into a bugreport, making a patch, and preparing a debdiff.  There's some documentation on some of the tools in https://wiki.ubuntu.com/MOTU/Contributing
[10:13] <nxvl> persia: ok, the i will start reading
[10:14] <persia> nxvl: Great.  If you have any questions, ask in here.  I warn you that it will be a few weeks before any patches get uploaded to hardy, but there's still ~30,000 bugs that won't get fixed in gutsy, so there's plenty to do in the meantime.
[10:16] <nxvl> persia: so, i can still help bugfixing gutsy for some months after the release?
[10:17] <luca> hi everyone
[10:17] <persia> nxvl: Yes, but the criteria for getting a fix into gutsy after release is much higher.  To start, I'd recommend working on hardy to get familiar with the tools.  Once you're comfortable, chasing the security bugs and severe breakage that got into gutsy should be easier.
[10:17] <luca> I would like to add a little hack to knetworkmanager
[10:18] <nxvl> persia: ok, so i have plenty of work for the next 6 months :D
[10:18] <persia> luca: Does it fix a severe bug?
[10:18] <Hobbsee> persia: see -devel
[10:18] <luca> but I know very little about programming - could someone help me out or point me to some good starting resources? :)
[10:18] <luca> persia: it's an annoying and I would say show-stopper bug for kubuntu
[10:18] <persia> luca: This isn't really the right forum for learning about programming.
[10:19] <luca> where then? :=
[10:19] <luca> :)
[10:20] <persia> luca: I'd suggest a web resource (start with searching for the major toolkit and programming language for your target software).  IRC isn't a very good place for that.
[10:20] <luca> ok thanks
[10:21] <persia> luca: If it's a showstopper bug, you'd do best to get all the info about it reported to launchpad.  It's not easy to learn programming, and the release is happening very soon now.
[10:21] <luca> persia: I already did
[10:21] <luca> two or three weeks ago
[10:22] <luca> it's a bug which prevents knetworkmanager to successfully connect after suspension unless it is switched first to offline mode and then again to online mode
[10:23] <luca> I guess that a simple hack making it doing this automatically could patch (very badly maybe ;) ) the problem, so I wanted to give the idea a try.....but I cannot as I do not how :)
[10:25] <luca> Hobbsee I am using the 0.2 version in gutsy
[10:25] <luca> if you are using the 0.1 then yes that had not this bug
[10:26] <luca> (had lots more though ;) )
[10:46] <pochu> *waves*
[10:50] <luca> bye
[11:01] <pochu> anyone can reject my last mail to -motu and -motu-mentors ML? should be in the mod queue...
[11:50] <persia> Anyone familiar with python-scipy?  Does Debian bug #444124 still apply?
[11:50] <ubotu> Debian bug 444124 in python-scipy "fftpack/_fftpack.so: undefined symbol: zfftnd_fftw" [Serious,Fixed]  http://bugs.debian.org/444124
[11:51] <Kmos> ScottK is more familiar with that
[11:54] <persia> Kmos: You like compiling things, don't you?
[11:55] <Kmos> persia: i can do it if you need something
[11:56] <persia> Kmos: I'm trying to make sure that none of the FTBFS bugs that Debian fixed are still in gutsy.  I'm working from http://django.ajmitch.net.nz/rcbugs.  Would you mind looking at some of the packages with no comments, and seeing if the gutsy version FTBFS when the bug is a FTBFS bug?
[11:56] <Kmos> persia: i got some time now, i can handle it
[11:56] <persia> Kmos: Great.  Thanks.
[11:57] <DktrKranz> persia, did esniper work?
[11:58] <persia> DktrKranz: Yes.  Completely.  Thanks for the build.  We're now waiting on the archive-admins to sync it.
[11:58] <DktrKranz> good :)
[11:59] <DktrKranz> you're looking at FTBFS... is it still an issue if Ubuntu version builds fine? I never managed them in such cases
[12:00] <persia> DktrKranz: I'm specifically looking at the list of Release Critical bugs fixed in Debian where Ubuntu has an older revision.  Lots of them are FTBFS bugs.  Debian usually has patches, so it's not hard to fix.  The important part is separating out the 20% that need attention from all of those that don't really apply to Ubuntu.
[12:01] <DktrKranz> I looked at them some time ago, as you said, the majority does not need love
[12:01] <DktrKranz> but there are probably some good candidates, especially with CVE in evidence
[12:02] <persia> DktrKranz: I've only found a few CVEs, and I think we've pushed them all to gutsy now.  Now it's just the "Serious" bugs left.
[12:02] <DktrKranz> good
[12:03] <DktrKranz> IIRC, \sh looked at them carefully
[12:03] <Kmos> persia: doko is alive, maybe you can ask him to sync.. don't know if he can
[12:03] <persia> DktrKranz: That explains why I could only find a couple missing :)
[12:03] <DktrKranz> heh
[12:03] <persia> Kmos: No rush.  They're in queue, and the admins will sync when they have time.
[12:03] <Kmos> ok
[12:03] <Kmos> tomorrow :)
[12:04] <DktrKranz> persia, if you find some and you haven't time to process them, please ping. I will be happy to have a look at them
[12:04] <persia> DktrKranz: CVE's or checking RC bug status?
[12:05] <DktrKranz> CVEs
[12:05] <Kmos> persia: http://packages.qa.debian.org/a/asterisk-chan-capi/news/20070922T161702Z.html -> isn't this one a good candidate for sync ?
[12:06] <persia> DktrKranz: I doubt I'll find anymore, where I'm looking.  Thanks though.
[12:07] <persia> Kmos: We don't need to sync that - ours is already built against asterisk-dev 1:1.4.4~dfsg-3ubuntu1.
[12:07] <persia> Kmos: Look for bugs where there's no comments first: those need more attention.
[12:07] <Kmos> persia: ok
[12:08] <DktrKranz> Kmos, can you reach packages.qa.debian.org? I have some troubles right now
[12:18] <geser> DktrKranz: I can reach the Debian PTS here
[12:19] <RAOF> How long should eclipse take to build?  TIt's still going!
[12:20] <man-di> RAOF: looooooooooook
[12:21] <RAOF> Also, this bux get's a little bit unrsponsive when the load average is > 20
[12:21] <man-di> RAOF: it needs incredible much memory with current settings in aotcompile.py (from java-gcj-compat-dev)
[12:21] <Kmos> DktrKranz: I can too..
[12:21] <man-di> RAOF: I'm currently speaking with doko how to improve this
[12:22] <RAOF> man-di: It's a little hard to check the spelling when it takes > 1 min between typing stuff in and it getting seen :)
[12:22] <man-di> RAOF: I know that feeling
[12:23] <man-di> RAOF: It eats all my 4 GB memory in the current default settings and still OOMs after a while
[12:23] <geser> RAOF: the i386 and amd64 Ubuntu buildds needed 90 and 100 minutes to build eclipse the last time
[12:23] <man-di> geser: with gcj-4.1 I needed 18 minutes on my box...
[12:24] <man-di> geser: with gcj-4.2 its unbuildable, I needed to limit the build to one CPU
[01:30] <white> !info nagios-plugins gutsy
[01:30] <ubotu> nagios-plugins: Plugins for the nagios network monitoring and management system. In component universe, is extra. Version 1.4.8-2ubuntu2 (gutsy), package size 87 kB, installed size 164 kB
[01:31] <white> someone should check, if CVE-2007-5198 is fixed
[01:31] <ubotu> Buffer overflow in the redir function in check_http.c in Nagios Plugins before 1.4.10 allows remote web servers to execute arbitrary code via long Location header responses (redirects). (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5198)
[01:32] <persia> DktrKranz: You wanted a CVE?  This is open and needs attention.
[01:32] <persia> white: Thanks for pointing it out.
[01:33] <DktrKranz> \o/
[01:34] <white> persia: that is one of the links, which should be observed by the ubuntu universe sec team :)
[01:34] <white> http://svn.debian.org/wsvn/secure-testing/data/NMU/list?op=file&rev=0&sc=0
[01:34] <white> the other one would be this one:
[01:34] <white> http://svn.debian.org/wsvn/secure-testing/data/CVE/list?op=file&rev=0&sc=0
[01:34] <persia> white: Thanks for those.  We've caught a few, but miss a lot.
[01:35] <white> persia: and I am not really the best ambassador and forget to forward a lot as well, sorry :/
[01:35] <white> !info dircproxy gutsy
[01:35] <ubotu> dircproxy: IRC proxy for people who use IRC from different workstations. In component universe, is optional. Version 1.0.5-5ubuntu1 (gutsy), package size 118 kB, installed size 268 kB
[01:36] <persia> DktrKranz: Could you make sure those links get to the rest of the team?  I don't see them listed at https://wiki.ubuntu.com/MOTU/TODO or https://wiki.ubuntu.com/MOTU/Teams/Security
[01:36] <white> !info dircproxy sid
[01:36] <ubotu> dircproxy: IRC proxy for people who use IRC from different workstations. In component main, is optional. Version 1.0.5-5.1 (sid), package size 114 kB, installed size 256 kB
[01:36] <persia> white: No worries.  We're not necessarily as organised as we could be regarding pulling the good bits.  We tend to sync at the start, and then fiddle.
[01:36] <DktrKranz> persia, should we add http://security-tracker.debian.net too?
[01:37] <white> DktrKranz: yes, that is the main source for the testing-security team
[01:37] <Fujitsu> white: I uploaded the dircproxy fix to Gutsy a couple of hours after you mentioned it in here and talked with \sh.
[01:37] <persia> DktrKranz: That sounds good.  Ideally we'd want something like http://django.ajmitch.net.nz/rcbugs to track the status, but someone would have to determine how to scrape the resources and write the interface.
[01:38] <white> Fujitsu: hi :)
[01:38] <white> Fujitsu: wanna look into xorg-server for a DTSA? :)
[01:38] <DktrKranz> ok, I'm after a potential SRU, a couple of minutes and I'll have a look at wiki pages
[01:38] <Fujitsu> white: Sorry, really busy with school stuff at the moment (and for the next couple of weeks).
[01:38] <white> no worries, good look with school :)
[01:39] <white> DktrKranz: you look like the man for xorg-server ;)
[01:39] <Fujitsu> Thanks.
[01:39] <DktrKranz> persia, it will be very useful! IIRC, debian uses changelog entries to determine if a CVE has been fixed or not
[01:39] <DktrKranz> white, but I'm not :P
[01:39] <white> DktrKranz: well, we use the tracker you just pointed out
[01:40] <white> DktrKranz: if the CVE is mentioned in the changelog, it helps us a lot spotting, which version fixes the issue
[01:41] <DktrKranz> unluckily, several CVEs are still "open" even if they have been fixed upstream
[01:41] <white> DktrKranz: well forwarding the patches to BTS helps a lot
[01:42] <white> DktrKranz: and ping me for every issue, if you want. We can arrange some uploads :)
[01:42] <white> if approrpiate
[01:42] <Hobbsee> hiya white
[01:42] <white> Hobbsee: hi :)
[01:42] <white> thought I join in your party for a few hours ;)
[01:42] <DktrKranz> white, are you referring to NMUs?
[01:42] <white> DktrKranz: yes
[01:43] <Hobbsee> white: woo!
[01:43] <DktrKranz> white, could I prepare them even if I'm not a DD?
[01:43] <white> DktrKranz: yes, you need a sponsor though
[01:43] <white> forwarding the patches to BTS would maybe be a bit faster
[01:43] <DktrKranz> ah, nice to know, I did'n realize that before. thanks :)
[01:44] <DktrKranz> *didn't
[01:44] <white> well we are very concerned about fixing security issues in testing (and unstable)
[01:45] <fms> hi all
[01:49] <RAOF> ...eclipse continues to build, but now isn't thrashing swap at least...
[01:50] <_polto_> hello all
[01:52] <DktrKranz> I'm definitely having network troubles...packages.qa.debian.org nor cve.mitre.org are reachable...
[01:53] <persia> DktrKranz: They work from here, so I suspect it's a continental problem or smaller
[01:54] <luk_> white: you are also over here :-)
[01:54] <DktrKranz> or on a provider basis, I asked on IRC and they seem reachable for someone
[01:54] <DktrKranz> I'll try to use a proxy or some
[01:55] <persia> DktrKranz: Could be.  You can't be doing too badly, or you'd have difficulty with IRC presence.
[01:56] <_polto_> Fujitsu, hello. I come back on Elphel cameras. :) Last things i have seen on mplayer ML is http://lists-archives.org/mplayer-dev-eng/19797-allow-elphel-cameras-to-work.html & http://lists-archives.org/mplayer-dev-eng/19858-allow-elphel-cameras-to-work.html
[01:57] <_polto_> Fujitsu, did you had some time to evaluate the possibility to include this patch in ubuntu's mplayer ?
[01:57] <white> luk_: i am practically everywhere :)
[01:57] <white> luk_: and of course i need to spy here at the enemy ;)
[01:57] <DktrKranz> :)
[01:58] <persia> white: enemy?
[01:58] <luk_> persia: just a joke
[01:58] <white> persia: well don't you know that dds do not like ubuntu and no dd would ever come into an ubuntu channel?
[01:58] <white> persia: haven't you read the stories about that?
[01:58] <Fujitsu> _polto_: I've been really busy with school stuff lately, and will be for the next few weeks (exams for my last year of school coming up).
[01:59] <white> Fujitsu: i hope that you are applying for la trobe ;)
[01:59] <white> that is, if you are going to study :)
[01:59] <Fujitsu> white: Not quite sure what I'm going to apply for at this time.
[02:00] <white> Fujitsu: apply for living on campus and come to my college here :)
[02:00] <white> i could use another OS developer :)
[02:00] <_polto_> Fujitsu, ok, just pls do not forgot about, or just transfer the tusk to somebody :)
[02:00] <_polto_> Fujitsu, and good chance!
[02:00] <Fujitsu> _polto_: Non-school stuff is on the backburner at the moment, but I won't forget about it.
[02:00] <Fujitsu> Thanks.
[02:04] <Hobbsee> Fujitsu: good luck with your exams!
[02:04] <Fujitsu> Hobbsee: Thanks... almost there now.
[02:04] <StevenK> Fujitsu: Best of luck!
[02:04] <Fujitsu> StevenK: Danke.
[02:05] <Fujitsu> Bwaha.
[02:06] <persia> I'll be stopping my RC bug attack soon.  Do I need to poke anyone about the motu-uvf, ubuntu-archive, and unapproved items, or will they be taken care of without advocation?
[02:18] <Schnitz> i this the right place to request feedback for a newly created deb package? i've just done it the first time so i'd like to get some hints...
[02:18] <persia> Schnitz: If it's a package you intend to submit for inclusion in Ubuntu universe, yes.
[02:20] <Schnitz> persia: exactly. i've assigned a bug to myself yesterday and now i'm nearly finished doing the packaging but i'm not sure if i should just upload it to launchpad without showing anyone first
[02:20] <DrKranz> persia, nagios-plugins vulnerability confirmed. I'll prepare a debdiff.
[02:20] <lamego> Schnitz, I hope you do not expect it to be available for Gutsy :P
[02:20] <persia> Schnitz: You'll want to upload to a PPA or to REVU.  I think REVU is better if you're not sure about the packaging.
[02:20] <persia> !revu
[02:21] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[02:21] <DrKranz> white, nagios-plugins has not fixed in unstable yet, so I'll open a new bug report and attach a patch
[02:21] <astimodeus> good evening peolpe, may I ask you a question?
[02:21] <persia> DrKranz: Thanks.  I'll be away soon, but subscribe ubuntu-universe-sponsors and the security team (I forget the team name) to get the right people's attention.  You might also advertise the bug here.
[02:21] <Schnitz> persia: thanks
[02:21] <persia> astimodeus: Please do so (although we may not answer)
[02:23] <astimodeus> I was wondering if i need to download beta versions of ubuntu to help with the development process or i can just  download the sources of what i want  to fix myself?
[02:23] <persia> astimodeus: You can just download the sources of things you want to fix, but the fixes must be tested against the current development environment to be uploaded.
[02:23] <astimodeus> yes that's obvious ^_^
[02:24] <astimodeus> i've spent some time on the ubuntu wiki don't worry :D
[02:25] <persia> astimodeus: There are a number of people who maintain a chroot or virtual environment with a current dev snapshot on a stable machine.  Unless you're really happy with seeing all the most recent bugs, that's probably easiest.
[02:25] <astimodeus> yeah good idea
[02:25] <astimodeus> :D
[02:26] <astimodeus> i'm gonna get qemu or vmware then ;)
[02:26] <astimodeus> thank you
[02:27] <Schnitz> lamego: being honest i don't expect anything ;-)
[02:34] <blueyed> ScottK: the debdiff for bug 135695 applies cleanly for me!? But it appears that the debian/php4-* files do not get removed, but only truncated (to 0 bytes).
[02:34] <ubotu> Launchpad bug 135695 in php-interbase "FTBFS: depends on php4-dev, which has been removed" [Undecided,Confirmed]  https://launchpad.net/bugs/135695
[02:35] <persia> blueyed: That's expected behaviour.  One must manually delete the 0 byte files after applying the debdiff.  The reason is that the diff.gz is not allowed to delete files, and debdiff adopts that behaviour.
[02:36] <blueyed> ok, so the patch seems fine.
[02:39] <blueyed> Can somebody please try, if the patch applies cleanly to php-interbase?
[02:42] <persia> blueyed: patch applied cleanly here.
[02:43] <blueyed> Thanks, persia. I'll resubscribe u-u-s then.
[02:52] <Schnitz> eg
[02:53] <Schnitz> could anyone please re-sync the revu uploaders keyring? https://wiki.ubuntu.com/MOTU/Packages/REVU says i should ask for that here after adding myself to the group (i also have a pgp key in my launchpad account)
[02:54] <Hobbsee> yup
[02:57] <Hobbsee> oh yay, i remember why one *doesnt* terminate this for any reason, now.
[02:57] <Hobbsee> there we go, now it's working.
[02:58] <xhaker> i have a question for the english speakers here
[02:59] <Hobbsee> TheMuso: unsure.  recruiting, probably
[02:59] <xhaker> sickest is a bad word or a good word?  i mean to describe something rad/extraordinary/awesome?
[02:59] <Hobbsee> it's a good word
[02:59] <TheMuso> Hobbsee: hrm. I've never really liked that project for some reason.
[02:59] <Hobbsee> it's somewhat aol-speak-ish, though
[03:00] <Hobbsee> TheMuso: yeah, well
[03:00] <lamego> TheMuso, nothing, was an information email
[03:00] <lamego> because there is a lot of misinformed people
[03:00] <lamego> TheMuso, what is your reason ?
[03:01] <lamego> and there is people which find that information valuable
[03:02] <lamego> not to mention, that information and debating ideas, is part of the CoC
[03:02] <TheMuso> lamego: Probably because its one more source where people can get packages that are not certified as quality packages.
[03:02] <xhaker> Hobbsee, thank god. I woudn't want people to misinterpret this posting http://digg.com/linux_unix/PIC_The_Sickest_Ubuntu_booth_you_have_ever_seen
[03:03] <lamego> TheMuso, do you have numbers to show against getdeb, is this is just another theory based argument ?
[03:03] <Hobbsee> xhaker: :)
[03:03] <TheMuso> lamego: No, its born from a personal distrust of any other repo than the Ubuntu official repos. My opinion of PPAs is the same.
[03:04] <white> DktrKranz: i uploaded an NMU for nagios-plugins, it is in incoming
[03:04] <DktrKranz> white, thanks
[03:05] <lamego> TheMuso, some of the people which contributes to getdeb, does also contribute for Debian and for Motu, you mean you don't trust on such people just because they are participating on a non official project ?
[03:06] <DktrKranz> I just prepared bug 152624, is it worth to upload it as a standalone fix or merge new version from Debian?
[03:06] <ubotu> Launchpad bug 152624 in nagios-plugins "Buffer overflow in check_http.c (CVE-2007-5198)" [Undecided,Confirmed]  https://launchpad.net/bugs/152624
[03:06] <DktrKranz> I will check impact for stable releases soon
[03:07] <Hobbsee> lamego: no, it's not that we dont trust them, as they do unofficial stuff.  at least for one of them, we dont trust him, as we've seen some of his packaging, and his requests.
[03:07] <TheMuso> lamego: Great for them. If I was to use getdeb, and determined that it was someone from Debian or Ubuntu MOTU/core dev, I'd feel more comfortable in using their packges. By this I mean, actual people who have upload rights to the repos. However, its the rest of the packages that I woud not be so trustworthy of.
[03:07] <white> DktrKranz: wait and sync it from debian?
[03:07] <lamego> you can have an abstract distrust, unless you are based on ideology and not on real factors
[03:07] <lamego> can't
[03:08] <Hobbsee> hint:  don't request things to be removed from ubuntu that are not in it in the first place.
[03:08] <lamego> Hobbsee, you can't evaluate a team for 1 member, I could tell the same about the MOTUs :)
[03:08] <TheMuso> I've seen first hand what 3rd party repos can do to other distros, especially a distro that has no great packaging standards or QA in place.
[03:08] <Hobbsee> lamego: none of our MOTU's are that bad - or else they wont have MOTU for very long, let me tell you...
[03:09] <TheMuso> Such repos has packages often of really really questionable quality.
[03:09] <lamego> Hobbsee, try to be anonymous and chat with SteveK on one of his bad days :)
[03:09] <TheMuso> s/has/had/
[03:10] <StevenK> lamego: Explain.
[03:10] <lamego> TheMuso, we have a clear statement of quality "Some of our packages do not meet Debian/Ubuntu QA requirements"
[03:10] <lamego> StevenK, not again, we already had that debate, and I can assure you I am not the only one which contributes to Ubuntu, which finds you particular unpleasent on some debates
[03:11] <lamego> anyway, we all have our share of bad temper some times
[03:11] <Hobbsee> lamego: are you sure you're not confusing scottk and stevenk?
[03:11] <Schnitz> i've built a package for tvbrowser (java application) i everything works fine with debuild
[03:11] <Hobbsee> lamego: based on the fact that you've already mashed their nicks.
[03:11] <ScottK> Hobbsee: Probably.
[03:11] <lamego> ops, it was ScottK
[03:11] <lamego> sorry :P
[03:11] <Schnitz> but when i try building with pbuilder it says: sun-dlj-v1-1 license could not be presented
[03:12] <lamego> StevenK, sorry, for the nick confusion
[03:12] <ScottK> lamego: You're the one that said you didn't want to work on Ubuntu packaging because it was to much work to do it right.
[03:13] <Schnitz> is it possible to get this license to work with pbuilder or is it generally not allowed to use the sun-java* packages for building java applications?
[03:13] <lamego> ScottK, no, that is your interpretation, I said I don't want to work on Ubuntu packaging because I have other priorities and do not have enough time, that together with the fact that MOTU work is a time consuming task
[03:14] <lamego> and is not that I don't want, is not that I do not have the required time
[03:14] <TheMuso> lamego: Surely getdeb is also time consuming.
[03:14] <lamego> yes, it is, and each of us does it owns choices, some people work on getdeb only, some people work on getdeb+ubuntu, some others on getdeb+debian, some others on debian+ubuntu, etc
[03:15] <Hobbsee> TheMuso: apparently less so.  although, one may not end up doing as much testing, etc, perhaps?
[03:15] <Schnitz> can anyone point me in the right direction please?
[03:15] <lamego> regardless of my personal choice, getdeb work is available for debian, ubuntu, insert your preferred debian base distro here :)
[03:16] <lamego> and, the most important, the users :)
[03:16] <TheMuso> lamego: What are your requirements for package submission?
[03:16] <Hobbsee> Schnitz: er, it's a pain.
[03:16] <Hobbsee> Schnitz: better to use other java if you can - your package gets sent to multiverse, and it has to have manual fun when building
[03:16] <blueyed> Schnitz: don't know really, but found this when googling: bug 45292
[03:16] <ubotu> Launchpad bug 45292 in sun-java5 "sun-dlj-v1-1 license could not be presented" [Low,Fix released]  https://launchpad.net/bugs/45292
[03:17] <lamego> TheMuso, http://wiki.getdeb.net/Package_Building/Acceptable_package_policy
[03:17] <Hobbsee> Schnitz: it's because pbuilder never presents you with the dialog saying "do you accept these terms?" when it's installing the build-deps, so the entire build falls over, as they never got an asnwer
[03:18] <lamego> if you are referring to QA, I am doing it for every package that get's published
[03:18] <Hobbsee> lamego: what types of thigns do you look for, in terms of QA?
[03:18] <TheMuso> lamego: As soon as anybody uses a repository other than the official Ubuntu/Debian repo, or an official mirror, they should be aware that any package they install from a 3rd-party repo could break their system, and they won't get support from the distro team to get help to fix their problem.
[03:19] <ScottK> Hobbsee: Do you know if anyone is doing accepts just now?  I don't see any for uploads I did ~7 hours ago.
[03:19] <Schnitz> Hobbsee: i could edit /etc/pbuilderrc and switch from noninteractive to readline
[03:19] <Hobbsee> Schnitz: probably not yet
[03:19] <Hobbsee> Schnitz: you probably could - but if it gets uploaded, it'll fail as well
[03:19] <lamego> Hobbsee, 1 - build  and run time depneds (using a schroot), 2 - provides an acceptable copyright notice, 3 - functional tests when possible, 4 - menu entry
[03:19] <Schnitz> Hobbsee: ok so you think i should try using other java...if that doesn't work i can't do packaging for tvbrowser?
[03:20] <lamego> if the package is not acceptable, but the requirement is justified, I will rebuild the entire packaging process myself
[03:20] <Hobbsee> Schnitz: yeah, try with the other one.  if it doesnt work, there are ways around it (but they're a pain)
[03:20] <lamego> TheMuso, that is why getdeb does not provide a repository, if you break your system, is because you have selected a package on the getdeb web site
[03:20] <Hobbsee> lamego: oh, so you dont end up testing upgrades or anything, because it's all deb files, not a repo
[03:21] <Hobbsee> yes, i see hwo it could be less work, that way.
[03:21] <lamego> TheMuso, getdeb packages have a ~getdeb~ tag, they can't be wrongly reported as official packages
[03:21] <Hobbsee> ScottK: no idea. maybe
[03:21] <TheMuso> lamego: Its got nothing to do with the version tag on the packages.
[03:21] <lamego> Hobbsee, correct, our users were informed that they should remove all ~getdeb~ packages before upgrading to Gutsy
[03:22] <Hobbsee> lamego: i actually meant between getdeb versions of packages, and such.  but that was going to be the next question :)
[03:22] <lamego> Hobbsee, yes, I do also validate package upgrades, between getdeb package version upgrades
[03:23] <lamego> if a package is complex, and we do not have the required skills to build it or test it, it does not get published
[03:23] <Hobbsee> right
[03:23] <Hobbsee> TheMuso: i think the problem si that most people are thinking that it *is* a repository - which would (or should) naturally have a bit more QA
[03:23] <TheMuso> lamego: So from that I am guessing you don't publish packages that need nweer versions of big infrastructure bits, such as libraries, so that you don't need to worry about conflicts/replaces/overrides?
[03:24] <lamego> TheMuso, that is correct, we do not have enough human and technical to work on such packages
[03:25] <lamego> TheMuso, we made a complete site re branding and slogan change 1 month ago, to avoid such confusions
[03:25] <Hobbsee> TheMuso: do most of our bugs even come from getdeb?  i thought they were more from automatix and such.
[03:25] <Hobbsee> for some reason, i dont see many getdeb bugs reported.
[03:25] <TheMuso> Hobbsee: I don't know.
[03:25] <lamego> automatix breaks people systems, getdeb does not, there were 4 seriously broken packages
[03:25] <Hobbsee> TheMuso: and they appear to be somewhat sane, at least picking up most of the cases of packages not building, not upgrading, etc.
[03:25] <lamego> which included a mime cache file
[03:26] <lamego> I mean, broke, not sure about automatix QA improvement
[03:27] <white> !info knowledgeroot gutsy
[03:27] <ubotu> knowledgeroot: web-based knowledgebase system. In component universe, is optional. Version <IP_ADDRESS>-2 (gutsy), package size 1266 kB, installed size 9416 kB
[03:27] <Hobbsee> TheMuso: the getdeb stuff is probably the most safe 3rd party lot of repos out there.
[03:27] <white> !info knowledgeroot sid
[03:27] <ubotu> knowledgeroot: web-based knowledgebase system. In component main, is optional. Version <IP_ADDRESS>-1 (sid), package size 1218 kB, installed size 8760 kB
[03:28] <lamego> also, we do have a QA from users, which does help sometimes,  release comments , but this is most for runtime/functional QA
[03:28] <white> there is a <IP_ADDRESS>-1.1 version coming in containing a fix for CVE-2007-5156
[03:28] <ubotu> Incomplete blacklist vulnerability in editor/filemanager/upload/php/upload.php in FCKeditor, as used in SiteX CMS 0.7.3.beta and probably other products, allows remote attackers to upload and execute arbitrary PHP code via a file whose name contains ".php." and has an unknown extension, which is recognized as a .php file by the Apache HTTP server, a different vulnerability than CVE-2006-0658 and CVE-2006-2529. (http://cve.mitre.org/cgi-bin/cvename.cgi?
[03:28] <Hobbsee> white: when will it be in?
[03:28] <white> Hobbsee: just uploaded the NMU
[03:28] <Hobbsee> white: great.
[03:28] <white> should be able to backport the patch
[03:29] <Hobbsee> ScottK: can you hit that with your sync script?   this is your first verbal irc ack, and you can do the other.
[03:30] <TheMuso> lamego: Ok, you and Hobbsee have eased my concerns somewhat. I'm just not one to trust 3rd-party repos, no matter who is involved, since I've been badly burnt by such repos on other distros in the past.
[03:30] <lamego> uff :)
[03:30] <Hobbsee> TheMuso: of course, it helps that the ubuntu stuff will be prefered anyway.
[03:31] <TheMuso> Hobbsee: yeah.
[03:31] <lamego> Universe is the core, getdeb is just an addon to Universe :P
[03:33] <ScottK> Hobbsee: I could, but I'm leaving for church.
[03:33] <Hobbsee> ScottK: after that is fine.
[03:33] <ScottK> I'll look at it if I have keyboard time, but not sure when that'll be.
[03:34] <TheMuso> Is anybody processing DktrKranz's nagios security bug?
[03:34] <TheMuso> If not, I'll do it.
[03:35] <DktrKranz> TheMuso, I'm preparing merge too since white just uploaded a NMU
[03:35] <TheMuso> DktrKranz: Oh ok, I'll wait.
[03:35] <DktrKranz> just a couple of minutes, then
[03:35] <TheMuso> Sure.
[03:38] <Schnitz> Hobbsee: in the tvbrowser wiki they say explicitly for ubuntu/debian that it is required to use the sun java implementation for running (and so building i think) tvbrowser because the free java implementations are not 100% compatible (and break tvbrowser)
[03:39] <Schnitz> Hobbsee: another problem is that it requires java >1.5 and the e.g. blackdown is only at ~1.4
[03:40] <Hobbsee> Schnitz: fair enough, then you'll have to use the sun-java, and i'tll have to go to multiverse
[03:41] <Schnitz> Hobbsee: okay then i'll upload as soon as it builds using pbuilder using the sun java stuff, thanks for your assistance that is very friendly!
[03:51] <TheMuso> Alright folks, I'm calling it a night. DktrKranz, sorry I am unable to help at this point.
[03:52] <DktrKranz> argh... just finished :(
[03:53] <DktrKranz> no problem then, I'll publish new debdiff to u-u-s
[04:12] <RAOF> Ok.  I'll leave that building overnight.  With any luck, eclipse takes < 8 hours to build on an x86-64 with 1Gb of ram.
[04:14] <man-di> RAOF: or OOMs before shortly before done because of not enough swap...
[04:14] <man-di> after 8 hours of building
[05:04] <Schnitz> how long does it take after i uploaded something to REVU till it appears on the http interface? i've uploaded maybe 10 minutes ago
[05:06] <DktrKranz> Schnitz: IIRC, REVU is updated every 5 minutes
[05:06] <Hobbsee> Schnitz: what did you upload?
[05:07] <Schnitz> oh excuse me please i jost got an email that it was rejected because distro was unstable....think i should have used feisty but then the package checkers say that feisty is not a known distro
[05:07] <Nafallo> Schnitz: gutsy or hardy I would say.
[05:07] <Hobbsee> why do you want to use feisty?
[05:07] <Nafallo> Schnitz: what are you trying to upload?
[05:08] <Schnitz> i'm trying to upload something for https://bugs.launchpad.net/ubuntu/+bug/102910 (fabian stietzel is my real life name)
[05:08] <ubotu> Launchpad bug 102910 in ubuntu "[need-packaging]  TV-Browser" [Wishlist,In progress]
[05:08] <Schnitz> please excuse me i'm new to packaging
[05:08] <Hobbsee> well, you wont get that into feisty
[05:08] <Schnitz> Hobbsee: no problem, then hardy? ;-)
[05:09] <Hobbsee> yes, you want hardy
[05:09] <Schnitz> i'm just trying to help, not trying to get something somewhere in asap or stuff like that ;-)
[05:09] <Schnitz> ok i rebuild with hardy
[05:10] <man-di> does hardy exist already?
[05:10] <StevenK> Hardy does not.
[05:10] <Schnitz> does not do what?
[05:11] <Hobbsee> exist
[05:11] <StevenK> It's named, it won't be created until Gutsy is out the door
[05:12] <Schnitz> okay i see, so i now use gutsy because gutsy is still the current testing/unstable?
[05:12] <Schnitz> i'd just like to upload my package to be able to get some feedback
[05:12] <StevenK> For now, build against gutsy
[05:13] <StevenK> If people ask, say you don't want it in Gutsy. :-)
[05:13] <Schnitz> aha okay
[05:14] <Schnitz> so i can upload it using gutsy?
[05:16] <frafu> Hello, I am trying to build a source package for my ppa, but don't know what I should do with the Changelog file under in the debian directory. The changelog outside the debian directory already has several entries. Should I transfer the entries to the debian-changelog? If so, what tools should I use? (I created the debian dir with dh_make)
[05:17] <lamego> Schnitz, this is not the right time to upload a new package to an official process, you would be better by just posting your building diff somewhere and ask for a MOTU review or mentoring
[05:17] <lamego> right time as, in the release cycle
[05:17] <Hobbsee> revu is a place for review...
[05:18] <lamego> can a package be uploaded to revu for inclusion on hardy, now ?
[05:18] <gnomefreak> frafu: no just add your changes to debian/changelog if there are CVE in source changelog adding them might be good as well but only the latest changelog entry
[05:18] <frafu> As a later version will probably go to REVU, I would like to make it at once conform for it
[05:19] <gnomefreak> frafu: for ppa add ~ppa1 to the end of the version
[05:20] <frafu> Should I modify the changelog manualy?
[05:20] <gnomefreak> can a motu please take a look at http://revu.tauware.de/details.py?upid=360 please
[05:20] <gnomefreak> frafu: yes or dch -i
[05:20] <gnomefreak> than go to it and add ~ppa1 and anything else it didnt add
[05:23] <frafu> By the way, does the debian changelog refer to changes in the source or to changes to the packaging? (for example, it is the same source, but something is different in the source package)
[05:23] <StevenK> It can refer to both
[05:24] <StevenK> It usually refers to the latter only.
[05:25] <frafu> ok;  thanks
[05:27] <Schnitz> i've put all the stuff dput would upload in a tarball: http://www2.ba-horb.de/~i06015/tvbrowser_deb.tar.gz
[05:27] <Schnitz> i'd be glad to recieve any feedback, if you like write an email to<EMAIL_ADDRESS>[05:37] <lamont> Hobbsee: nope.  both syncing snort and dropping the arch:all cecilia are archive tasks
[05:37] <Hobbsee> fair enough
[05:38] <lamont> PaS only affects where we build things
[05:38] <Hobbsee> ahh
[05:39] <RainCT> hi
[05:41] <RainCT> I'm working on a program that has some plugins (non-executable sh/bash scripts). Where should they go? /usr/share/<app name> ?
[05:42] <geser> yes
[05:43] <RainCT> ok, thx
[06:00] <frafu> The copyright field in debian/copyright: Does it refer to the person who implemented the propgram or to the packager? I suppose the packager; can anybody confirm?
[06:03] <RainCT> frafu: copyright field?
[06:03] <frafu> yes
[06:04] <RainCT> frafu: what do you mean? debian/copyright has no fields as far as I know, you just write all copyright information (both, of the program, and the package) there the way you want
[06:04] <frafu> there is a template for the upstream, and another one named copyright
[06:05] <frafu> ok; I set both, author and packager
[06:05] <RainCT> frafu: here you have an example http://packages.debian.org/changelogs/pool/main/g/gbrainy/gbrainy_0.2-2/gbrainy.copyright
[06:08] <geser> frafu: debian/copyright contains both (packager and upstream) but the greatest part is about upstream copyright (and license)
[06:10] <frafu> It is a bit different from the template created by dh_make; but I see that the format is not strict; i will put upstream and packager into it; both GPL
[06:12] <frafu> By the way, the packager information has been put in automatically by dh_make.
[06:13] <geser> frafu: debian/copyright is freetext but most files have a similar layout and look
[06:14] <frafu> ok
[06:17] <jdong> there's a few developers that have macbooks, right?
[06:18] <amachu> bluekuja: ping
[06:18] <Nafallo> jdong: should be one or two in the world :-)
[06:18] <bluekuja> amachu: heya
[06:18] <Hobbsee> a few of them, yeah
[06:18] <jdong> Nafallo: hehe :)
[06:18] <jdong> it almost worked out of the box with Gutsy... :)
[06:18] <jdong> minus needing madwifi svn
[06:19] <jdong> rigth now , I'm tryin to figure out how to enable palm detection of the touchpad
[06:19] <jdong> the xorg.conf synaptics parameters don't have any effect
[06:19] <amachu> bluekuja: yet to start work.. was held up with things a little..
[06:19] <amachu> ping you as and when needed..
[06:19] <amachu> :-)
[06:21] <amachu> bluekuja: you there?
[06:23] <bluekuja> amachu: ye
[06:23] <amachu> bluekuja: :-)
[06:34] <highvoltage> hey bluekuja
[06:36] <frafu> I got a few warnings from debuild -S -sa. Could anybody please tell me what this warning means: dpkg-source: warning: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[06:36] <bluekuja> heya highvoltage
[06:37] <bluekuja> how are you jon?
[06:39] <jdong> WHOOO!!
[06:39] <jdong> found the bug tha fixes my Intel panics
[06:39] <bluekuja> jdong: :)
[06:39] <jdong> ok, now last thing to tackle... battery life
[06:39] <highvoltage> bluekuja: ugh, I have my ups and downs :)
[06:40] <bluekuja> highvoltage: same here, what's up?
[06:40] <frafu> And this which is probably more serious: W: mousetweaks source: debian-rules-ignores-make-clean-error line 56
[06:40] <bluekuja> highvoltage: do you still have a planet on your website?
[06:40] <highvoltage> bluekuja: playing catch-up on work, for months now. just getting a bit frustrated
[06:40] <highvoltage> bluekuja: nope
[06:41] <highvoltage> bluekuja: I'll add one again in the future, the old one started to give some problems so I just took it off
[06:41] <Hobbsee> yay, catchup
[06:41] <highvoltage> Hobbsee: yay! someone that understands!
[06:41] <bluekuja> highvoltage: oh that's why I cannot see it anymore
[06:41] <frafu> But the binary builds under pbuilder
[06:41] <highvoltage> bluekuja: yep. your blog was on there, but I think you only ever made one post, right?
[06:42] <frafu> I suppose that I can ignore the warnings!?
[06:42] <bluekuja> highvoltage: I deleted it, created an italian one, and some days ago made a new english one
[06:42] <highvoltage> bluekuja: aah
[06:42] <bluekuja> highvoltage: that's why only one post got published there
[06:42] <highvoltage> bluekuja: where's your new blog? I'll update my rss reader...
[06:43] <bluekuja> highvoltage: it's on blog.ibluepaper.com
[06:43] <bluekuja> highvoltage: you can grab the feed there
[06:44] <bluekuja> highvoltage: some news for that edubuntu-website discussion?
[06:44] <bluekuja> highvoltage: I see no more posts on the mailing list
[06:45] <highvoltage> bluekuja: each time we make some progress we have a setback and things get stalled a bit
[06:45] <bluekuja> highvoltage: there will be a meeting for that?
[06:45] <highvoltage> bluekuja: what's encouraging though, is that there's a better localisation plugin for drupal that will allow us to translate the site like we wanted to do waaay back
[06:46] <highvoltage> bluekuja: none scheduled, that I know of
[06:46] <bluekuja> highvoltage: oh cool! we talked about that plugin something like 1 year or more ago
[06:47] <highvoltage> yep, but back then it was quite buggy and didn't work very well
[06:47] <bluekuja> highvoltage: edubuntu-it is going great, forum and website area are alwais up-to-date
[06:47] <highvoltage> bluekuja: excellent!
[06:47] <bluekuja> highvoltage: and I received a lot of mails from several teachers in Italy
[06:47] <highvoltage> bluekuja: we also have a lot more people willing to translate the site, in a few weeks I want to start a translation drive
[06:48] <bluekuja> highvoltage: nice to hear, really, ping me for the italian part of translations
[06:48] <bluekuja> highvoltage: so I can organize myself with italian translators here
[06:48] <highvoltage> bluekuja: ok, sounds good
[06:48] <highvoltage> bluekuja: I see you also became a motu recently- congrats!
[06:49] <bluekuja> highvoltage: yeah! thanks a lot :)
[06:50] <bluekuja> highvoltage: ok, I finish something here, feel free to ping me anytime, you're alwais really welcome to me
[06:50] <bluekuja> :)
[06:55] <ScottK> white: For knowledgeroot: do I want <IP_ADDRESS>-1.1 or <IP_ADDRESS>-1?
[07:03] <highvoltage> bluekuja: ok, thanks :)
[07:03] <bluekuja> highvoltage: ;)
[07:07] <kagou> Hi
[07:09] <kagou> i have problem using dput. I can't succesfully upload my files with (i precise : here at home). I suspect a router problem at home. Anybody have an idea ,
[07:09] <kagou> ?
[07:09] <pochu> uploading to where?
[07:11] <kagou> pochu, to ppa
[07:12] <soren> kagou: And what makes you think it doesn't work?
[07:12] <kagou> at home i have a little internet connection (2Mb) and i always have problem. At work all is Ok (other reouter and 8Mb)
[07:12] <Nafallo> 2Mbps up should be well enough
[07:12] <kagou> sommer, my upload stop (monitoring upload), dput seems to freeze.
[07:13] <kagou> if i use an ftp client like filezi_lla i have connection time out
[07:13] <soren> It can take a while. How big is your .orig.tar.gz?
[07:13] <kagou> not big
[07:13] <kagou> 14 Mo
[07:14] <kagou> and i can wait one night it will make no difference
[07:14] <kagou> ;)
[07:14] <soren> kagou: How long have you waited?
[07:16] <jdong> 640KB/s up ought to be enough for anyone
[07:16] <Hobbsee> jdong: try 128kbps
[07:16] <jdong> poor Hobbsee :)
[07:17] <Hobbsee> yeah....
[07:18] <kagou> it's not a time problem
[07:19] <kagou> i had time out with filezilla
[07:19] <kagou> connection lost etc.
[07:20] <Hobbsee> then ctrl+c it.
[07:24] <kagou> is at active or passive connection with ppa ?
[07:29] <kagou> ok. i try to sniff my connection. see you
[07:36] <bluekuja> ScottK: around?
[07:43] <bluekuja> ScottK2: around?
[08:20] <blueyed> If there's only a bug fixed in a new Debian version, a sync request makes more sense than an Ubuntu patch, correct? (bug 152432)
[08:20] <ubotu> Launchpad bug 152432 in duplicity "duplicity vs. ncftp" [Undecided,Confirmed]  https://launchpad.net/bugs/152432
[08:24] <geser> blueyed: is it still the same upstream version?
[08:25] <blueyed> yes
[08:25] <geser> then a sync should be possible
[08:39] <blueyed> Yes, makes more sense of course. But I'm not sure, what's easier to ACK (and do). Filed as bug 152714.
[08:39] <ubotu> Launchpad bug 152714 in duplicity "[sync request]  Please sync duplicity 0.4.3-4 from Debian" [Undecided,New]  https://launchpad.net/bugs/152714
[08:40] <bluekuja> ScottK: ping me when back please
[08:56] <jussi01> anyone know where i can get information on future UDS's?
[09:44] <ScottK> bluekuja: I'm here.
[09:44] <bluekuja> ScottK: about https://bugs.edge.launchpad.net/ubuntu/+source/exaile/+bug/123409
[09:44] <ubotu> Launchpad bug 123409 in exaile "[exaile/gutsy]  crash in lib gtkembedmoz" [Undecided,Confirmed]
[09:44] <ScottK> Yes.
[09:44] <bluekuja> ScottK: I've added the patch posted there
[09:45] <bluekuja> and tested it out
[09:45] <bluekuja> it doesnt crash anymore
[09:45] <bluekuja> on selecting sub-tabs
[09:45] <bluekuja> like lyrics or  artist
[09:45] <bluekuja> just wanted to hear an opinion from you
[09:45] <bluekuja> as far as you followed that bug
[09:45] <bluekuja> since the beginning
[09:46] <ScottK> bluekuja: If you have a fix for a crash bug that you are confident of, I would upload it.
[09:46] <pochu> bluekuja: listen had a similar bug, which was fixed in a similar way... :)
[09:46] <bluekuja> pochu: oh cool :)
[09:46] <pochu> I mean, it was crashing in the same function in gtkembedmoz, and adding MOZILLA_FIVE_HOME=/usr/lib/firefox fixed it.
[09:46] <bluekuja> ScottK: yeah, I thought you followed it closely
[09:46] <bluekuja> pochu: yeah, it seems to be quite common
[09:47] <ScottK> bluekuja: Not that closely.
[09:47] <bluekuja> pochu: currently I dont know if the bug can be found on python too
[09:47] <bluekuja> pochu: there are a lot of bugs around about that lib
[09:47] <bluekuja> pochu: but that's a workaround to have exaile working
[09:47] <pochu> bluekuja: I think that was reported on bugzilla.mozilla.org...
[09:47] <bluekuja> ScottK: ok then, I ask to pochu to test it as well
[09:48] <bluekuja> pochu: can you test something for me please?
[09:48] <pochu> I think so.
[09:48] <bluekuja> pochu: please apt-get install exaile
[09:48] <bluekuja> ty
[09:48] <pochu> hehe :)
[09:48] <bluekuja> open it from terminal
[09:48] <bluekuja> add a song in the active playlist
[09:49] <bluekuja> then
[09:49] <pochu> change to lyrics :)
[09:49] <bluekuja> yeah
[09:49] <bluekuja> :D
[09:49] <bluekuja> nice, so I dont have to explain everything
[09:49] <bluekuja> does it core dump?
[09:50] <pochu> bluekuja: ermh, were are the lyrics in exaile?
[09:50] <pochu> hehe
[09:50] <bluekuja> ^^
[09:51] <bluekuja> pochu: right click on the song
[09:51] <pochu> ah, ty
[09:51] <bluekuja> move to information
[09:51] <bluekuja> and you have statistics selected
[09:51] <bluekuja> move to artist/lyrics
[09:51] <bluekuja> and should crash
[09:52] <pochu> yes, it does
[09:52] <bluekuja> pochu: ok, now I give you a link
[09:52] <bluekuja> pochu: I give you deb file
[09:52] <bluekuja> so you can check it directly
[09:52] <pochu> wow, that's better :)
[09:52] <bluekuja> please purge everything
[09:54] <pochu> done, link?
[09:54] <bluekuja> pochu: http://incoming.ibluepaper.com/exaile_0.2.10+debian-1.1ubuntu2_i386.deb
[09:56] <bluekuja> pochu: works fine?
[09:56] <pochu> bluekuja: works fine now
[09:56] <bluekuja> ok great
[09:56] <bluekuja> uploading it then
[09:57] <pochu> cheers
[09:57] <bluekuja> thanks pochu for helping out
[10:04] <bluekuja> ScottK: what time for the freeze tomorrow?
[10:05] <ScottK> bluekuja: After 0001 UTC no uploads without motu-uvf approval.  After 1000 no uploads without release manager approval (assume that won't be forthcoming for anything in Universe).
[10:05] <ScottK> bluekuja: See /topic
[10:06] <bluekuja> ScottK: ok thanks, anyway fix has been pushed. We'll wait for the ack tomorrow
[10:07] <ScottK> OK.  Those deadlines are for us to push.  Up to the RM when they accept.
[10:07] <bluekuja> yeah, I guess the queue will be cleaned up
[10:07] <bluekuja> and not left undone
[10:08] <bluekuja> leaving now, good night ScottK
[10:08] <ScottK> One hopes, but Universe stuff will come behind Main, so no guarantees.
[10:08] <ScottK> Good night.
[10:08] <bluekuja> yeah
[10:08] <bluekuja> I hope it will be in, that crash is bad to have, really.
[10:08] <bluekuja> cu tomorrow, take care
[10:09] <ScottK> StevenK, soren, or zul: Please have a look at Bug #152590 and Bug #151699.
[10:09] <ubotu> Launchpad bug 152590 in polyxmass-doc "Please sync polyxmass-doc 0.9.1-2 (universe) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152590
[10:09] <ubotu> Launchpad bug 151699 in gdc-4.1 "[UVFe]  gdc-4.1 0.25 new upstream release" [Undecided,New]  https://launchpad.net/bugs/151699
[10:53] <ubotu> Launchpad bug 152590 in polyxmass-doc "Please sync polyxmass-doc 0.9.1-2 (universe) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152590
[10:55] <Kopfgeldjaeger> n8


[06:49] <pabs3> I noticed that with "d-i netcfg/enable boolean false" in preseeding, netcfg from the Ubuntu precise 12.04.1 segfaults. is this a known bug? any suggested workaround?
[06:50] <pabs3> er s/segfaults/alternate installer segfaults/
[06:51] <pabs3> this is in an i386 vm with virt-install & kvm
[10:14] <pabs3> found a workaround; set static network with bogus addresses in the 127.x range
[20:53] <infinity> cjwatson: D'oh, I was holding off on the d-i upload until today's master kernel landed.  Oh well.  Another upload later today, I guess. ;)
[20:53]  * infinity wonders if we can hit quadruple digits in the Ubuntu revision before we get around to merging.
[21:13] <cjwatson> I was trying to get the revision history ported across the svn/git switch ...
[21:13] <cjwatson> Maybe I should have another go at that some month
[21:14] <cjwatson> I did want to get an image with the new udev ASAP, though
[21:21] <infinity> cjwatson: Fair enough.  Not like rebuilding d-i a few times a day hurts, it's just entertaining. ;)
[21:22] <infinity> cjwatson: (FWIW, you also missed seed-twiddling when you pushed my omap4 change yesterday... Further evidence that I should fix things to not require ABI versions in seeds, as discussed a month or two ago.  I think I'll write myself a post-it and glue it to my forehead)
[21:23] <cjwatson> Er, oops, sorry
[21:23] <cjwatson> Yeah, both of us forgetting it means it's basically doomed
[21:23] <cjwatson> (seed updates)
[21:24] <infinity> I get good LP karma for the weekly seed updates, but I'm preeeeetty sure that's a lousy argument for not fixing the root cause. ;)
[21:27] <cjwatson> Yeah :-)
[21:27] <cjwatson> Neither of us, surely, need karma


[07:57] <vmlintu_> alkisg: we've just been thinking of ways of cloning the nbd image to the local disk
[07:57] <vmlintu_> alkisg: did you plan on installing the fat client chroot on the local disk and running from there?
[07:58] <alkisg> vmlintu_: I want to support that as a possible scenario for slow local networks, yes
[07:58] <alkisg> It involves 2 steps, as I thought it:
[07:59] <alkisg> 1) Boot all the clients as ltsp clients. It'll be slow as the network is slow.
[07:59] <alkisg> Run a "copy nbd image locally" script
[07:59] <alkisg> Since that's a fat chroot, it can also contain gparted etc
[07:59] <alkisg> I think here we'll do that part from epoptes, as it allows launching programs as root on the clients
[08:00] <vmlintu_> have you done any tests on that yet?
[08:00] <alkisg> 2) On boot, mount the nbd image and compare to the local version
[08:00] <alkisg> If the remote image is newer, run rsync to sync it locally
[08:00] <alkisg> So every time the sysadmin runs `ltsp-update-image`, the next boot will be a bit slower
[08:00] <alkisg> Depending on the changes, it might need a couple of minutes to complete the boot process
[08:01] <alkisg> That's all, it should allow for very slow networks to use LTSP
[08:01] <vmlintu_> your plan sounds quite similar to what I had in mind
[08:01] <alkisg> No, I haven't implemented anything about that part yet
[08:01] <alkisg> I don't know when I'll have time for it
[08:02] <vmlintu_> have you thought about the kernel updating part?
[08:03] <vmlintu_> or would you always boot and load the kernel from the network?
[08:03] <alkisg> That's on the (2) part as well
[08:03] <alkisg> The newer kernel is available in the nbd image, one can copy it over its local /boot as well
[08:04] <alkisg> (11:03:16 πμ) vmlintu_: or would you always boot and load the kernel from the network? => that's a possible variation, yes, and it has an additional advantage:
[08:04] <alkisg> one can just have a "sync-image-locally" kernel parameter,
[08:05] <alkisg> and when that's in effect, it would copy the nbd image to the first hd partition, whatever that is,
[08:05] <alkisg> so e.g. if it's a windows partition, it would sync the nbd image to C:\ltsp.nbd
[08:05] <vmlintu_> that'd be interesting
[08:06] <alkisg> The good side of it is that there's no step "1", so it can work even with student laptops
[08:06] <alkisg> And e.g. in the summer vacations students can just delete that file to free up space
[08:06] <alkisg> It'll be automatically synced on next boot
[08:07] <vmlintu_> local kernel would enable some kind of wireless use, though
[08:08] <vmlintu_> wireless updating would need to be done after wireless connection is up, though, so updating the image at boot time wouldn't work
[08:09] <alkisg> True. One other thought is to use wubi or win32loader (the debian equivalent) to have the ltsp entry appear in the windows boot loader
[08:10] <alkisg> It's a bit less intrusive for PCs that already have windows in their disks, no partitioning / other boot manager are needed
[08:12] <alkisg> Finally, we also thought about the possibility to do the same thing with USB sticks, but currently they're a bit slow
[08:14] <alkisg> I'm postponing the whole thing for later, for when btrfs snapshots are available out of the box
[08:14] <vmlintu_> how would you use snapshots in this?
[08:15] <alkisg> That way a client could boot with its older image and do a lazy rsync/update to the new one while students are working on it. When the update is done, it would take effect on the next boot.
[08:16] <vmlintu_> I was thinking of storing two images on the disk: current and "next"
[08:17] <alkisg> Currently storing images on NTFS volumes has problems; 100 % cpu usage for several seconds, making the system unresponsive and the students angry
[08:17] <vmlintu_> ouch
[08:18] <alkisg> So until that is solved, I'd go with the seperate partition solution, and I wouldn't want to have 2 of them, neither to have to duplicate the "old" into the "next" before rsync
[08:18] <vmlintu_> yes, snapshots could solve that problem quite nicely
[08:19] <alkisg> Also squashfs isn't rsync'able, so I'd use compressed btrfs, so I'd have to wait for it anyway
[08:20] <vmlintu_> squashfs isn't rsync'able?
[08:20] <alkisg> It's not writeable
[08:20] <alkisg> It's read only
[08:20] <alkisg> ...although it's possible to rsync from a squashfs network image to e.g. a local ext partition
[08:21] <vmlintu_> I cannot twist my mind enough for that right now
[08:22] <alkisg> But for slow USB sticks, a compressed btrfs would make a big difference
[08:23] <alkisg> What I would also like to test, is 10 clients using x2go to connect to the LTSP server over 54mbps wifi
[08:23] <alkisg> ...for older clients that are not good enough to be fat
[08:23] <vmlintu_> do you mean rsync from mounted nbd image to local disk?
[08:23] <alkisg> Yes
[08:24] <alkisg> "nbd" can be whatever, squashfs, ext, btrfs, that's why I was specifically mentioning squashfs, as that one doesn't have write support, it's read-only by design
[08:24] <alkisg> So you can't rsync it locally
[08:24] <alkisg> You can copy it, but not rsync its contents to a local squashfs image, the local image needs to be something else, ext, btrfs...
[08:25] <alkisg> $ sudo mount -o loop /opt/ltsp/images/i386.img /mnt
[08:25] <alkisg> mount: warning: /mnt seems to be mounted read-only.
[08:25] <vmlintu_> but you can rsync the whole image file from the server as a file to the local disk
[08:25] <alkisg> ...I can't write anything in /mnt after mounting it, it's like mounting a cdrom
[08:26] <alkisg> Yes, but since it's compressed, it's completely different
[08:26] <alkisg> Even if you recompress the same data, the result might be completely different
[08:26] <alkisg> So rsync makes no sense there, it's like doing "cp" from scratch
[08:28] <vmlintu_> oh yes.. I just realised that we are using currently uncompressed squashfs images
[08:29] <alkisg> Uncompressed squashfs would be rsyncable, but compressed btrfs would be rsyncable too and twice as fast
[08:30] <alkisg> Uncompressed squashfs is too slow, I've never used it here
[08:31] <vmlintu_> there were some stability issues with compressed images at some point
[08:32] <vmlintu_> are the ubuntu images now compressed by default?
[08:52] <alkisg> (11:31:20 πμ) vmlintu_: there were some stability issues with compressed images at some point ==> no the stability problems were caused by nbd-proxy
[08:52] <alkisg> (we never used nbd-proxy here)
[08:52] <alkisg> (11:32:09 πμ) vmlintu_: are the ubuntu images now compressed by default? => yes they're again compressed by default, and nbd-proxy is disabled by default as well
[08:56] <vmlintu_> yes, I'm starting to remember those again.. I had forgotten the whole thing already
[08:58] <alkisg> bbl