[12:53] <holymoly> *hmmm*
[12:54] <holymoly> a dd is mentioned as the maintener of hplip on ubuntu
[12:54] <holymoly> does that sound right?
[12:54] <holymoly> do ubuntu maintainers take over from dd maintainers?
[12:56] <StevenK> holymoly: According to my Gutsy chroot, the Maintainer is Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[12:56] <StevenK> holymoly: But, it isn't uncommon to have a Debian Developer as a Maintainer of a source package in Ubuntu, we are after all, derived from Debian.
[12:57] <holymoly> right, if i have a question about a particular package and building a particular package on ubuntu (say dapper), should i post to the ubuntu devel mailing list?
[12:58] <holymoly> i'd hate to spam the dd with ubuntu questions if he isn't directly involved in ubuntu
[12:58] <azeem> you should post to the user list I guess
[12:58] <holymoly> okay thank you
[12:58] <azeem> building packages for the sake of it isn't distribution development
[12:59] <holymoly> true, i know how touch dd's are about the ubuntu project, would really hate to add to the fire
[12:59] <StevenK> holymoly: Most of them are reasonable. It's the verbal minority that give that impression.
[01:00] <holymoly> well thats probably true
[01:07] <holymoly> okay so let me ask this question
[01:07] <holymoly> i've built hplip 2.7.7 from source and installed it via the hplip installer on dapper as well (which also builds it from source)
[01:07] <holymoly> using the gutsy src package for hplip is not working it seems as debhelper cannot resolve the dependencies
[01:08] <holymoly> i'm assuming the maintainer is modifying some of the dependencies and assuming gutsy versions
[01:08] <holymoly> how else can i build an hplip package? i presume similar steps can be used with the .tar.gz from sourceforge?
[03:20] <bddebian> Heya
[03:23] <Hobbsee> hi bddebian
[03:23] <bddebian> Heya Hobbsee
[03:52] <holymoly> what would be a nice simple application to try and backport
[03:53] <holymoly> something that doesn't require too many dependencies?
[03:53] <RAOF> holymoly: Miro!
[03:54] <holymoly> in the repos
[03:54] <holymoly> i'm testing something called prevu
[03:54] <holymoly> it supposedly simplifies the backporting process
[03:54] <RAOF> holymoly: What do you mean.  Miro's in the repos, right?
[03:56] <holymoly> nope
[03:56] <holymoly> not that i can see
[03:56] <dobey> holymoly: gtk2-engines-cleanice would be a simple backport
[03:56] <holymoly> danke!
[03:57] <dobey> no problem ;)
[03:57] <holymoly> oh yeah that totally makes sense, right
[03:57] <StevenK> RAOF: rmadison -u ubuntu knows nothing about miro
[03:59] <ajmitch> sure, it's stuck in NEW
[03:59] <RAOF> Oh, yeah.  There it is.
[04:00] <StevenK> Source NEW, I'm guessing.
[04:01] <StevenK> Hrm, ENOSEB
[04:01] <RAOF> Indeed
[04:05] <StevenK> 16. Not too bad.
[04:05] <StevenK> Except that one of the packages is texlive-bin ... twitch.
[04:06] <wolfe> ENOSEB?
[04:07] <StevenK> As in, seb128 isn't here.
[04:07] <wolfe> ohhh, heh
[04:09] <bryce> i just got one of those errs too
[04:10] <StevenK> Heh, it's catching.
[04:13] <bryce> hi
[04:27] <holymoly> okay so backporting an app from gutsy obviously is a dependency challenge
[04:27] <bddebian> Yep :-)
[04:28] <holymoly> if i have the source files and instructions how to compile and make install on dapper from the original vendor, how easily can that be built into a deb?
[04:29] <bddebian> Depends on the package and your definition of easy
[04:30] <holymoly> well right now i'm a noob trying to jet get a deb of hplip 2.7.7 for dapepr built, later i'm interested in learning more about packaging, compiling and coding
[04:30] <holymoly> so i'm heavily leaning on easy :) just for now
[04:32] <bddebian> Is there a specific reason you need it for Dapper?
[04:33] <holymoly> because we have about 30 dapper boxes and need hplip support roughly within the next day or two.  waiting for gutsy to show up isn't really an option, never mind that a company wide dist-upgrade is unlikely to happen without serious testing anyway
[04:34] <holymoly> it's not an emergency, i just haveto buy some printers and would love to have proper hplip support
[04:35] <bddebian> Ah
[04:35] <bddebian> You need the gutsy version?
[04:35] <holymoly> i've compiled and installed hplip 2.7.7 from scratch using the hp provided sources, what i need is a deb i can deploy because compiling on 30 machines each time is not really a sensible thing to do
[04:37] <bddebian> One thing you could try is grab the Dapper hplib source package copy the debian dir from that to an extracted tarball of your 2.7.7 and try to tweak it to build with that
[04:37] <holymoly> oh thats interesting
[04:37] <holymoly> *hmm*
[05:00] <lamont> cjwatson: we'd done a good job of nuking libsvga1, iirc... it's not present on all platforms, so it tends to be one of the things that gets a reaction out of me...
[05:09] <det> If a package was uploaded to Debian sid on Aug 3rd, does that mean it will not be included in Gutsy?
[05:10] <det> Sorry, I mean Sep 3rd (yesterday)
[05:11] <bddebian> det: If it is a new version most likely not unless a UVFe is filed.  If it is just a new release, possibly.
[05:11] <det> It is a new release and has support for more architectures (It is a compiler which, with this release, can now target 64-bit platforms)
[05:12] <det> New version, I mean.
[05:31] <Chipzz> det: extremely low probability of being included I'ld say
[05:31] <Chipzz> new version, new features, features which are likely to break other stuff
[05:31] <Chipzz> (last thing depending on how pervasive the changes are)
[05:32] <Amaranth> det: what is it?
[05:32] <det> MLton
[05:32] <Amaranth> never heard of it :)
[05:32] <det> Yeah, there isnt much chance of it breaking anything.
[05:32] <Amaranth> is has zero rdepends
[05:32] <det> exactly
[05:33] <det> does rdepends include build-depends ?
[05:33] <Hobbsee> Amaranth: it's a *compiler*.  of course it wouldnt.
[05:33] <Chipzz> det: also depends if it's main or universe
[05:33] <det> universe
[05:33] <Amaranth> but it's also universe so that's an #ubuntu-motu thing
[05:33] <Amaranth> hobbsee: oh, right, didn't see that :)
[05:33] <det> It is significant in that it now builds on amd64
[05:38] <Chipzz> det: current version in gutsy appears to be quite old
[05:38] <Chipzz> so the delta is likely to be quite big
[05:38] <Chipzz> Version: 20061107-1
[05:43] <Chipzz> but otoh, only mlton build-depends on it
[05:43] <Chipzz> heh :P
[07:37] <cjwatson> lamont: well, svg != svga
[08:03] <ion_> It would be nice to have.
[08:05] <lamont> cjwatson: DOH
[08:05] <StevenK> cjwatson: As a member of -release, do you think I should bother filing it?
[08:06] <StevenK> cjwatson: And when are you going to get your launchpad account changed to not be ~kamion. :-P
[08:09] <cjwatson> StevenK: hmm, not sure, sounds worth considering, but I'm supposed to be getting on a train
[08:09] <cjwatson> StevenK: we'll be lambasted if we ship an RC and it turns out to suck though
[08:09] <StevenK> cjwatson: Agreed.
[08:09] <cjwatson> though, is 2.3.18 part of the same development cycle?
[08:09] <StevenK> Yup, an earlier snapshot of
[08:09] <cjwatson> ah, ok, definitely sounds worth considering then
[08:10] <StevenK> cjwatson: Just before you go, I will build Debian's version for Gutsy and round up a few testers. If they don't want my blood, I'll file a UVFe.
[08:11] <cjwatson> I tried to change my Launchpad account name a while back but the problem is that it changes the URLs for all my Bazaar branches
[08:11] <cjwatson> so I need to figure out something for that
[08:11] <cjwatson> StevenK: sounds good
[08:14] <StevenK> cjwatson: Ahh. Launchpad won't/can't do redirects?
[08:21] <thekorn> keescook: can you please try my patch attached to bug 137437
[08:21] <ubotu> Launchpad bug 137437 in python-launchpad-bugs "committing a status-change does not work" [Medium,New]  https://launchpad.net/bugs/137437
[08:41] <dholbach> good morning
[09:01] <kagou> Good morning
[09:24] <soren> Has MoM been switched off?
[09:26] <pwnguin> a question about readahead: is the list sorted in any particular order?
[09:34] <dholbach> pwnguin: if you see anything we could do make it better - that'd be awesome
[09:35] <pwnguin> im just browsing the source right now, but i was thinking to myself, if they just read one file at a time in no particular order, that's painful
[09:35] <dholbach> pwnguin: Keybuk (once he's here) might answer that question for you if your inspection of the code doesn't
[09:36] <ion_> The files are sorted optimally.
[09:36] <pwnguin> that sounds impressive
[09:37] <pwnguin> it looks like it essentially calls the syscall readahead() on every file. i was thinking it might make sense to queue up a couple or more at a time
[09:37] <pwnguin> and let the disk scheduler sort out what's optimal
[09:38] <thom> pwnguin: no; it makes more sense to order the files based on disk position, so you can pick them up in the correct order
[09:38] <pwnguin> thom: i think thats what im saying
[09:38] <pwnguin> though i dont know much about how the scheduler currently works
[09:39] <thom> that's what it does, now
[09:39] <soren> pwnguin: The disk scheulder doesn't know where the files are.
[09:39] <soren> pwnguin: It deals with blocks and sectors, not filenames. You can't give it a list of filenames you want and make it fetch them in the most optimal order.
[09:44] <dholbach> hey seb128
[09:44] <seb128> hi dholbach
[09:50] <dholbach> seb128: if you get back to doing archive stuff, do you think you could reject sqlite-ruby (in the NEW queue)?
[09:51] <StevenK> seb128: I'm looking at uploading 15 rebuilds for the poppler SOVER bump, do you have an issue with that?
[09:52] <pwnguin> soren: well, i almost never see very good throughput on readahead. i dont know if it's a matter of file system overhead, fragmentation, or simply lots of small files rather than big ones.
[09:56] <seb128> dholbach: ok, why?
[09:56] <seb128> StevenK: no
[09:56] <seb128> dholbach: btw why "get back", I usual do archive work on wednesday I didn't stop it ;)
[09:57] <StevenK> seb128: Just test-building the lot of them. At this point I will probably skip gimp, since I'm looking at updating it.
[09:57] <dholbach> seb128: I did not follow the NewPackagesFreeze process
[09:57] <seb128> StevenK: ah, good to know, I was going to do merge the 2.4 rc from Debian, I don't need to do it if you are already working on it ;)
[09:58] <StevenK> seb128: It needs a UVFe, I was going to do it, and get a few people to test.
[09:58] <seb128> ok
[09:59] <seb128> yeah, I know it needs an UVF exception, I expect it'll be easy to get though
[09:59] <StevenK> seb128: Can you push poppler through binary NEW? It has built everywhere.
[10:00] <Company> siretart: ping
[10:00] <seb128> StevenK: I was just doing it
[10:00] <StevenK> seb128: Cool, sorry to bug you.
[10:00] <seb128> that's ok ;)
[10:01] <StevenK> seb128: Hrm, will the binaries make the publisher run that starts in about 2 minutes?
[10:02] <seb128> likely
[10:02] <StevenK> Way cool.
[10:02] <StevenK> Even though I'm limited by when the builds finish on my machine.
[10:04] <seb128> StevenK: you don't need to wait for the upload anyway, the buildd will depwait automatically
[10:05] <StevenK> If I update the build dependancy for the new version ...
[10:06] <StevenK> My machine just starting building koffice. texlive is one of the next, I bet the buildds have picked up poppler2 by the time I'm done. :-)
[10:06] <seb128> StevenK: no need to upload tracker, I'm going to ask an UVF for the new version now
[10:07] <StevenK> seb128: Aye. Should I put my list up so you can eyeball it?
[10:07] <seb128> Riddell, Hobbsee: what do you think about updating tracker to the new version available? It fixes several bugs and the deskbar plugin has been updated to work with the deskbar-applet API
[10:08] <Hobbsee> seb128: does that include the performance bug?
[10:08] <Hobbsee> seb128: as in, there's still *lots* of talk about the current version eating up all available power, when caching
[10:08] <seb128> Hobbsee: "* Dramatically reduced disk access and disk contention "
[10:09] <seb128> "* Highly optimised email indexing (up to 5x faster)"
[10:09] <Hobbsee> seb128: way cool.  Do It.
[10:09] <seb128> "* Makes use of idle class disk IO scheduling if available"
[10:09] <Hobbsee> nice
[10:09] <seb128> Hobbsee: thanks ;)
[10:09] <Hobbsee> seb128: no problem :)
[10:09] <Hobbsee> mvo: you cant have it!
[10:10] <StevenK> RAOF: That's a feature, not a bug.
[10:10] <Hobbsee> haha
[10:10] <Hobbsee> that says you have too much email.
[10:10] <seb128> StevenK: the list should be something like claws-mail-extra-plugins epdfview gimp pdfcube referencer kdegraphics koffice
[10:10] <RAOF> Only 100,000 or so.  It should easily be able to handle that :P
[10:11] <StevenK> seb128: + abiword texlive-bin kbib kde4graphics popplerkit.framework okular evince
[10:11] <seb128> StevenK: kbib kde4graphics also
[10:12] <seb128> StevenK: evince is dep-waiting on the binaries
[10:12] <StevenK> Aye, dumping evince.
[10:27] <soren> seb128: Oh, if you're doing source NEW today, I'd just like to point out that system-config-samba has been approved by motu-uvf for a NPFe.
[10:27] <seb128> NPF?
[10:27] <seb128> ah, k
[10:27] <seb128> gotcha ;)
[10:28] <soren> :)
[11:00] <dholbach> ajmitch, bhale: can we get mono to build with gda3 instead of gda2?
[11:04] <dholbach> ^ or some other mono expert
[11:04] <dholbach> it'd help us get rid of gda2 in main
[11:06] <Riddell> seb128: got a changelog for tracker?
[11:06] <seb128> Riddell: Hobbsee already approved it
[11:14] <dholbach> http://daniel.holba.ch/bugs is back up again
[11:14] <ajmitch> dholbach: hard to say, the system.data.oledb component apparantly hasn't been getting much love
[11:15] <ajmitch> I guess it'd be a case of try & see
[11:15] <dholbach> ajmitch: it'd be very nice :)
[11:25] <cjwatson> StevenK: can't do redirects at present, AFAIK
[11:25] <cjwatson> I should probably prod LP folks about that at some point
[11:29] <seb128> Hobbsee|Remote: why did you subscribe ubuntu-archive to bug #134501?
[11:29] <ubotu> Launchpad bug 134501 in gmountiso "[UVFe]  gmountiso 0.4" [Undecided,Triaged]  https://launchpad.net/bugs/134501
[11:31] <ogra> cjwatson, i got to a point where my udeb script finishes fine now with all the in-target stuff .... the bad thing is indeed, if i unset all the debconf vars my real frontend of the script gets unresponsive :(
[11:31] <cjwatson> I'm sorry, but I'm unlikely to have time to help today
[11:32] <ogra> ok
[11:42] <seb128> doko: why did you subscribe ubuntu-archive to bug #124778?
[11:42] <ubotu> Launchpad bug 124778 in expat "linux grashed" [Undecided,New]  https://launchpad.net/bugs/124778
[11:44] <doko> seb128: I did wonder myself, why I did get this message, can't remember, typo?
[11:44] <seb128> doko: dunno, I've unscribed it now
[11:51] <Le-Chuck_ITA> hi all, I am planning on improve the state of home backup in ubuntu
[11:52] <mvo> go for it!
[11:54] <Le-Chuck_ITA> well
[11:55] <Le-Chuck_ITA> I remember that in edgy we had a problem
[11:55] <Le-Chuck_ITA> :
[11:55] <Le-Chuck_ITA> backup was not made "on the fly"
[11:55] <Le-Chuck_ITA> resulting in impossibility to back up data when disk was almost full
[11:55] <Le-Chuck_ITA> is this still the case?
[11:56] <Le-Chuck_ITA> this I mean in the "hubackup" package
[12:00] <seb128> Mithrandir: is claws-mail in main for mobile?
[12:00] <Mithrandir> seb128: I wasn't aware it was in main, but it should be there eventually.
[12:01] <seb128> Mithrandir: well, it's on component-mismatch
[12:01] <seb128> "   [Reverse-Depends: Rescued from claws-mail, Ubuntu.Gutsy mobile seed, libsylpheed-claws-gtk2-dev] "
[12:01] <mvo> Le-Chuck_ITA: I don't know, but I think not much has changed since edgy, the package got not a lot of attention
[12:01] <Mithrandir> seb128: it doesn't have a MIR, does it?
[12:01] <seb128> Mithrandir: and it's trying to trigger gnome-libs (gnome 1), gtk1.2n glib1.2 to main
[12:02] <seb128> Mithrandir: doesn't look like no
[12:02] <Mithrandir> seb128: argh, it wants gtk 1.2? :-/
[12:02] <seb128> hum
[12:02] <Le-Chuck_ITA> ok thank you
[12:02] <seb128> Build-Depends on libgdk-pixbuf-dev
[12:02] <seb128> that looks wrong
[12:03] <seb128> Mithrandir: I'm having a look, I think it Build-Depends on that wrongly
[12:32] <Kopfgeldjaeger> hi
[01:19] <gnomefreak> is there a reason why updates want to access external disk (thats not external) this is bothering me
[01:20] <soren> updates? external disks that are not external? what?
[01:20] <gnomefreak> its root partition its trying to access as external
[01:20] <soren> I have no clue what that means.
[01:20] <soren> Whose root partition? What does it mean to access something "as external"?
[01:21] <gnomefreak> soren: during updates it prompts for root password to access root partition
[01:21] <gnomefreak> but yes after give password it shows up as disk on desktop (like external drive would
[01:21] <gnomefreak> its hal thats doing it
[01:22] <soren> soren: Ok, so when you're running update-manager, you're asked for your password... What makes you think it's "to access root partition"?
[01:23] <gnomefreak> soren: because when you give the password it shows up on desktop if i open it it has bin, var, ect.... dirs
[01:24] <mvo> gnomefreak: so when you run update-manager and install updates with it it does mount some of your dirs? is that the questions/concern?
[01:24] <gnomefreak> you dont seem to need to do it as i didnt do it this time but i did yesterday and its still shouldnt ask you to do that. i do believe (will hav eto wait for next hal update) its says external drive
[01:24] <gnomefreak> mvo: dist-upgrade
[01:25] <gnomefreak> i dont use update-manager too often as i always have a load on the pc from building/uploading/ect
[01:26] <mvo> gnomefreak: in dist-upgrade mode it accesses some dirs to compute the size that the upgrade will take
[01:27] <gnomefreak> Setting up libhal-storage-dev (0.5.9.1-1ubuntu6) ...
[01:27] <gnomefreak> Setting up hal (0.5.9.1-1ubuntu6) ... * Reloading system message bus config...                                [ OK ]   * Starting Hardware abstraction layer hald
[01:27] <gnomefreak> that is when i get the dialog
[01:27] <mvo> oh, I see. that sounds like a issue with the hal package then
[01:27] <mvo> update-manager/apt-get/etc are just the messanger than :)
[01:27] <gnomefreak> yep
[01:28] <gnomefreak> i dont know who is the hal guy or i would have went to him/her directly
[01:28] <gnomefreak> but being sick i cant be here as often either
[01:28] <mvo> pitti would be a good candidate, but he is currently on vacation
[01:29] <gnomefreak> ok ill ping him next week than maybe ill be feeling better than
[01:29] <gnomefreak> ty mvo
[01:29] <mvo> gnomefreak: get well!
[01:29] <soren> gnomefreak: Could you throw the output of lshal on pastebin?
[01:29] <soren> gnomefreak: Or even better:
[01:29] <soren> gnomefreak: File a bug and attach it?
[01:30] <seb128> soren: what is the issue?
[01:30] <gnomefreak> soren: yes but it is gonna have to wait
[01:30] <gnomefreak> seb128: hal update asks to access root partition and prompts for password and disk shows up in desktop
[01:31] <soren> seb128: I'm not entirely sure :) Something about hal making stuff show up on gnomefreak's desktop.
[01:31] <soren> gnomefreak: "asks to access root partition"? What's the exact question it asks?
[01:31] <seb128> I think it's something like hal or dbus restarted
[01:31] <gnomefreak> hal update prompts for root password to access disk (IMHO not good)
[01:32] <seb128> that looks like gnome-mount asking permission to mount a driver which is not listed if fstab for the user
[01:32] <seb128> s/driver/drive
[01:33] <jamiemcc> seb128: is tribe 6 frozen or is there time to squeeze in latest tracker 0.6.2?
[01:34] <seb128> jamiemcc: the 0.6.2 exception has been accepted, I'm looking at the update
[01:34] <jamiemcc> ok great
[01:34] <seb128> soren: "sudo invoke-rc.d hal restart" to simulate the bug
[01:35] <gnomefreak> seb128: running that will do the same as the update did?
[01:35] <seb128> soren: when hal restart it looks like GNOME get events like if the drives where just connected
[01:35] <Amaranth> jamiemcc: what is new in 0.6.2?
[01:35] <Amaranth> jamiemcc: and are the io issues sorted out?
[01:35] <jamiemcc> amaranth: hopefully
[01:35] <soren> seb128: Not on my system it doesn't..
[01:35] <seb128> gnomefreak: no, the upgrade should not restart hal, I'm not sure why it did
[01:35] <gnomefreak> yep it does
[01:35] <jamiemcc> my testing shows its much more reliable with io
[01:35] <gnomefreak> seb128: not sure either
[01:36] <seb128> soren: do you have other partitions not in fstab?
[01:36] <Amaranth> i _always_ notice when tracker is doing something now but luckily it finishes so fast it's almost never annoying
[01:36] <jamiemcc> amaranth: we have smoothed over io issues quite a bit and it now pauses when it detects external disk access outside
[01:37] <Amaranth> neat
[01:37] <gnomefreak> ok i really need to get more painkillers in me and laydown, ty for looking at that seb128
[01:37] <jamiemcc> amaranth: full changes here: http://mail.gnome.org/archives/tracker-list/2007-September/msg00012.html
[01:38] <seb128> gnomefreak: you're welcome
[01:38] <Amaranth> jamiemcc: yay, even more "i'm compiling, go away" stuff :)
[01:39] <jamiemcc> amaranth: yeah although there may be corner cases where it does not work well - we need trivbe 6 exposure to find out
[01:39] <Amaranth> "This version will cause your hard drive to be re-indexed due to the new sqlite indexer backend"
[01:39] <soren> seb128: Er... Mounted ones?
[01:40] <seb128> soren: no, not mounted ones
[01:40] <Amaranth> that's 60GB of code, video, audio, etc
[01:40] <jamiemcc> amaranth: so long as code or text files < 10gb you should be ok
[01:40] <Amaranth> they are
[01:40] <seb128> soren: the computer place lists all the available partitions, and you can mount them by double clicking, gnome-mount does the job and will ask the sudo password if required
[01:40] <Amaranth> and i suppose it should have a problem racing through flac files
[01:41] <seb128> soren: likely if you have a windows partition not in fstab you should be able to mount it this way
[01:41] <Amaranth> err, shouldn't
[01:41] <jamiemcc> amaranth: providing gstreamer can extract metadata from them no
[01:41] <Amaranth> if it couldn't rhythmbox would look weird :)
[01:41] <soren> seb128: I don't. I have a dm-crypt'ed partition, but hal won't know about that.
[01:42] <seb128> soren: ok, that's why restarting hal does nothing for you ;)
[01:42] <soren> seb128: But gnomefreak's problem was that his root partition showed up like this as well, right?
[01:42] <ogra> soren, the dm-crypt code in hal isnt used ? i know upstream added stuff for that
[01:42] <soren> ogra: By design, it won't be able to recognize it.
[01:43] <soren> ogra: dm-crypt'ed block devices don't have an identifying superblock.
[01:43] <ogra> soren, there is a hal handler for encrypted partitions afaik
[01:43] <ogra> that should automatically ask for a pw and the like
[01:43] <soren> ogra: Possibly, but it can't recognize a them by looking at them.
[01:43] <soren> ogra: You may be thinking of LUKS partitions?
[01:43] <ogra> but might be that pitti disabled it
[01:43] <ogra> oh, right, i mixed that up
[01:44] <seb128> soren: I'm not sure the description is accurate, anyway the bug there is that hal should not been restarted on upgrade
[01:44] <ogra> indeed, it was LUKS
[01:44] <soren> ogra: Ah, ok.
[01:44] <soren> ogra: That makes more sense. That's (AFAIK) basically dm-crypt+superblock.
[01:44] <Mithrandir> soren: uh, yes and no.  LUKS typically uses dm-crypt.
[01:44] <soren> Mithrandir: Did I say differently?
[01:45] <Mithrandir> soren: you were just slightly confusing when you said dm-crypted block devices don't have a superblock, while they can have, but they don't need to have.
[01:56] <ScottK> seb128: If you have a moment, would you please relook at Bug #131776 as it appears there was some confusion about what package was being asked for (I hope the comment I just added clarifies it).
[01:56] <ubotu> Launchpad bug 131776 in feisty-backports "please backport xserver-xorg-video-openchrome" [Wishlist,In progress]  https://launchpad.net/bugs/131776
[01:56] <ogra> heh
[01:56] <seb128> ScottK: looking
[01:56] <ScottK> Thanks.
[01:57] <seb128> ScottK: ah, right, I read the bug description and it mentions the wrong package
[01:57] <seb128> ScottK: will fix it now
[01:57] <ScottK> Thanks.
[01:57] <ogra> ScottK, the thing is that many via boards run with all three (via, uni- and openchrome)
[01:57] <ogra> but only one of them will support certain features of the device
[01:58] <ogra> the via drier situation is a big bad mess
[01:58] <ogra> *driver
[01:58] <seb128> ScottK: fixed, could you try to include the versions in backport requests though?
[01:58] <seb128> ScottK: you did in the new comment but not before
[01:59] <ScottK> seb128: Yes.  I usually make sure that's there.  I slipped up on that one.
[01:59] <soren>  /win 21
[01:59] <soren> ...
[02:01] <AlinuxOS> Hello asac, is there some news with this bug: https://bugs.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/+bug/88677
[02:01] <ubotu> Launchpad bug 88677 in mozilla-firefox-locale-all "Georgian Language support." [Undecided,Confirmed] 
[02:13] <kwwii> seb128: here is the source package for human icon theme
[02:14] <kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1.tar.gz
[02:14] <kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1.dsc
[02:14] <kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1_source.build
[02:15] <kwwii> http://sinecera.de/human-icon-theme_0.21ubuntu1_source.changes
[02:15] <StevenK> Neeeeeeeeeat.
[02:16] <StevenK> liquified kernel: [1567134.553120]  journal commit I/O error
[02:20] <dholbach> kwwii: if you could rename it to 22, I'd upload it
[02:24] <StevenK> seb128: Just about to upload the seven packages that built, plus koffice for the poppler rebuilds.
[02:25] <seb128> StevenK: cool, thanks
[02:25] <StevenK> seb128: koffice failed here after 2 and a half hours due to an I/O error, during the final dh_install, so I'm reasonably certain it will deal.
[02:32] <StevenK> Riddell: You about?
[02:35] <Riddell> hi StevenK
[02:38] <StevenK> Riddell: Hey, I'm looking to upload kdegraphics and koffice, but both of them didn't have the DebianMaintainerSpec stuff set, and I wasn't sure if you'd prefer the KDE packages not set to core-dev.
[02:43] <dholbach> kwwii: reviewing it
[02:43] <Riddell> go ahead and fix that StevenK
[02:44] <StevenK> Riddell: Will do, thanks
[02:49] <dholbach> kwwii: did you also push your changes to the branch?
[02:50] <kwwii> dholbach: no, should I do that now? wanted to wait to hear your opinion
[02:53] <dholbach> kwwii: feisty -> gutsy
[02:54] <dholbach> kwwii: hum, I see no changes to 0.21 apart from the changelog
[03:02] <kwwii> dholbach: nope, there should not be any...I just took the stuff you updated and built the package :-)
[03:02] <kwwii> I assumed that nobody had done that yet
[03:02] <kwwii> dholbach: sorry if I was wasting your time :-(
[03:02] <dholbach> kwwii: ok, I'll upload it
[03:02] <dholbach> kwwii: for some reason it did not hit the buildds
[03:03] <dholbach> maybe I just forgot to upload it (???)
[03:03] <dholbach> anyway, uploading now
[03:03] <dholbach> kwwii: can you push it to bzr?
[03:03] <kwwii> dholbach: yes, but I should change feisty to gutsy in the changelog, right?
[03:03] <dholbach> (with the change from feisty to gutsy please)
[03:03] <dholbach> yeah
[03:04] <dholbach> thanks kwwii
[03:05] <kwwii> dholbach: commited, thanks to you for the help :-)
[03:05] <dholbach> thank YOU :)
[03:05] <Skiessi> committed what?
[03:05] <Skiessi> :o
[03:05] <dholbach> Skiessi: changes to human-icon-theme bzr
[03:06] <Skiessi> ok :)
[03:06] <soren> seb128: Do you think you will have time to look at system-config-samba today?
[03:06] <seb128> soren: what is this thing?
[03:07] <soren> seb128: It's in the NEW queue.
[03:07] <seb128> soren: looking right now
[03:08] <xhaker> Hi. Anyone here willing to help remove a bashism in a package?
[03:11] <xhaker> http://pastebin.com/m2e824844
[03:13] <seb128> soren: looks good, one small question, why do you include the cdbs dpatch rule and also dpatch.make?
[03:14] <soren> seb128: Probably because I'm an idiot.
[03:14] <soren> seb128: :)
[03:14] <seb128> ;)
[03:14] <dholbach> seb128 sees everything
[03:14] <cjwatson> xhaker: cp "$$(printf %s "$$f" | sed 's/$(SOVERSION)//')" "$$f"
[03:14] <soren> seb128: I can't remember. I packaged it months ago and only this friday got upstream to include the GPL in the tarball so it's just been lying around waiting to get uploaded.
[03:15] <cjwatson> xhaker: or, if $(SOVERSION) is guaranteed to be at the end of $f:
[03:15] <cjwatson> xhaker: cp "$${f%$(SOVERSION)}" "$$f"
[03:16] <soren> seb128: I've got anoter patch for it I want to upload real soon anyway. I'll take care of it then.
[03:19] <seb128> soren: accepted
[03:21] <seb128> ;)
[03:23] <xhaker> thanks cjwatson, will try. many thanks, really.
[03:31] <seb128> jamiemcc: tracker is still not really nice, it creates a load around 3 on my gutsy
[03:31] <jamiemcc> seb128: laod?
[03:32] <seb128> which makes applications laggy, etc
[03:32] <seb128> the number you have in top
[03:32] <jamiemcc> iowait state
[03:32] <seb128> "load average"
[03:32] <jamiemcc> it should be niced though
[03:32] <jamiemcc> io wait states can make apps that access the disk laggy
[03:32] <jamiemcc> run vmstat 1
[03:34] <seb128> jamiemcc: the io bi is pretty low (between 0 and 300) and bo goes between 1000 and 9000
[03:35] <jamiemcc> the wa figure at end is most important
[03:35] <seb128> 99
[03:35] <seb128> 99
[03:35] <seb128> 96
[03:35] <jamiemcc> ouch
[03:35] <seb128> etc
[03:35] <jamiemcc> yes we aim for less than 90
[03:35] <jamiemcc> what else is accessing the disk?
[03:35] <seb128> nothing I think
[03:36] <seb128> or nothing with heavy access
[03:36] <seb128> I've web browsers, xchat, evolution open
[03:36] <seb128> but there are not doing anything special
[03:37] <jamiemcc> se128: is that wa figure continuing?
[03:37] <jamiemcc> to be above 90?
[03:38] <f0rqu3> http://-kol.deviantart.com/ I cant open this website on ubuntu
[03:38] <seb128> jamiemcc: no, but it goes often between 96 and 100 and that's when the system is laggy
[03:39] <seb128> jamiemcc: like it's ok for 10 seconds and then lag for some seconds, then it's ok, again, etc
[03:39] <seb128> and when it's laggy even typing on IRC is frozen
[03:39] <jamiemcc> seb128: how big is your home/.cache/tracker
[03:40] <seb128> 401M at the moment
[03:40] <seb128> it's the first indexing
[03:40] <jamiemcc> yeah mine is about that too and I dont have any issues
[03:40] <seb128> I removed tracker from this box previous because I can't work with this lag
[03:40] <jamiemcc> im on feisty 2.6.15 kernel though
[03:40] <seb128> just giving a try to the new version
[03:40] <StevenK> Feisty ought to 2.6.20 ...
[03:41] <jamiemcc> seb128: I can make it write to disk more often in smaller chunks to reduce latency
[03:41] <jamiemcc> assuming its not a kernel issue
[03:42] <seb128> jamiemcc: well, not sure what is creating the issue, could be the kernel
[03:42] <f0rqu3> ???
[03:42] <seb128> but that's not really nice from an user point of view
[03:42] <jamiemcc> seb128: I will play with it on gutsy and see what  can do
[03:42] <seb128> thanks
[03:43] <seb128> jamiemcc: other thing, the search tool was supposed to indicate that indexing was still running, no?
[03:43] <seb128> that doesn't seem to be the case
[03:43] <jamiemcc> seb128: yeah we plan on having an applet/notification icon to do that
[03:43] <jamiemcc> we have one submitted but its not stable yet
[03:44] <jamiemcc> will be ready for gutsy beta
[03:45] <seb128> ok, cool
[03:45] <pedro_> jamiemcc: is there any news related to not indexing while running on battery?
[03:45] <jamiemcc> pedro_: thats coming with the applet
[03:45] <seb128> I though the tracker-search-tools had a "still indexing" indication
[03:45] <seb128> beagle does that I think
[03:45] <jamiemcc> seb128: yeah we can add that - not hard
[03:45] <pedro_> seb128: yes it does
[03:46] <Mithrandir> also, turning off indexing should kill trackerd.
[03:48] <jamiemcc> seb128: it shopuld be possible for us to read the iowait figures on linux and throttle back if necessary
[03:49] <bddebian> Heya
[03:49] <bddebian> seb128: Thanks for the syncs!
[03:49] <seb128> bddebian: you're welcome
[03:56] <superm1> seb128, i subscribed ubuntu archive to bug 134726 because you told to last week.  I'm just waiting on an archive admin to release the uploads into -proposed per the SRU process.
[03:56] <ubotu> Launchpad bug 134726 in mythtv "MythTV 0.20.2 SRU " [High,In progress]  https://launchpad.net/bugs/134726
[03:56] <seb128> superm1: did I?
[03:56] <superm1> Yes
[03:57] <seb128> superm1: k, maybe I didn't connect what you asked and the bug
[03:57] <seb128> I've to admit that the one page describe doesn't make me want to read it to understand what is to do
[03:58] <superm1> :)
[03:58] <superm1> Aug 29 08:42:03 <seb128>        superm1_: I looked at ubuntu-archive bugs this morning and there was nothing about that
[03:58] <superm1> Aug 29 08:42:41 <superm1_>      seb128, previously Riddell had just acked it without looking for a bug about it, so it wasn't apparent that i needed to file a bug to make it happen.
[03:58] <superm1> Aug 29 08:43:21 <seb128>        superm1_: well, pings on IRC don't scale
[03:58] <superm1> Aug 29 08:43:30 <seb128>        superm1_: that's not a replacement for a bug ;)
[03:58] <seb128> k
[03:59] <seb128> shouldn't the SRU be approved by ubuntu-sru?
[04:00] <superm1> its a universe SRU
[04:00] <Hobbsee> dont think the team exist anymore
[04:00] <seb128> Hobbsee: https://launchpad.net/~ubuntu-sru
[04:00] <superm1> the current MOTU sru process just requires that "After the upload, archive administrators should then verify that the version number of the upload is sane and accept the package into -proposed. They set the bug status to Fix committed." per  https://wiki.ubuntu.com/MOTU/SRU
[04:00] <ScottK> It doesn't.  It's 2 it works inputs on the bug and 7 days aging and any MOTU can mark it motu-verification-done.
[04:01] <Hobbsee> seb128: for MOTU
[04:01] <seb128> Hobbsee: https://wiki.ubuntu.com/MOTU/SRU doesn't make clear what team should approve it
[04:01] <Hobbsee> seb128: dont look at me, i avoid them :)
[04:02] <superm1> this is exactly why I wanted to bring this up for discussion at the upcoming MOTU meeting this weekend :)
[04:02] <StevenK> ScottK, seb128, Hobbsee: Currently test building gimp 2.4.0~rc2
[04:02] <seb128> StevenK: rock on ;)
[04:03] <seb128> superm1: that would be a good idea, because I'm not comfortable to let anybody upload SRUs without requiring any approval
[04:03] <superm1> seb128, my understanding is that any MOTU can do the SRU, and the role for the archive admin is to just check the version number is good and let it into proposed, and then we have our other verifications steps
[04:03] <seb128> and we usually don't accept new version to stable and use backports for that
[04:03] <seb128> well, I'm not sure I'm willing to accept a new version as SRU
[04:04] <superm1> well Riddell already accepted the first proposed variant to -proposed.  this is just to make up for an issue that was discovered upstream with the new version and affects a few people
[04:04] <seb128> " 226 files changed, 14006 insertions(+), 6391 deletions(-)"
[04:04] <seb128> that's scary for a SRU
[04:04] <StevenK> Uh, agreed.
[04:06] <iwj> This damn drive has been blanking this disc at `speed 4' for about 25 minutes.
[04:07] <superm1> those debdiffs on the bug are against the version currently in universe.  the changes between these two proposed versions aren't more than 3 dpatches that get applied during build
[04:08] <seb128> superm1: well, I'm discussing whether accepting the first upload was right
[04:08] <superm1> well i did consult with the technical board
[04:08] <seb128> that is not mentioned in the bug
[04:08] <superm1> and mdz's end response was "This update has my ack in principle (the problem is severe enough to justify
[04:08] <superm1> the risk of an update); a decision on the actual package updates themselves
[04:08] <superm1> (the implementation of the fix) remains with the SRU team." (This was before the packages were fully prepared)
[04:09] <StevenK> Awww. Gimp doesn't do the fun "checking for intelligent life ... none found" in its configure any more
[04:09] <azeem> does Martin Owens IRC?
[04:12] <seb128> azeem: no idea, dholbach ^ ?
[04:12] <bddebian> StevenK: Maybe it just never found any so it gave up? :-)
[04:12] <superm1> seb128, I can bounce the mail thread to ubuntu-archive ML if you'd like, since mdz didn't actually comment on the bug after he responded to me
[04:12] <azeem> he sure seemed grumpy on debian-devel-discuss
[04:13] <StevenK> bddebian: :-)
[04:13] <seb128> superm1: no that's ok
[04:13] <azeem> seb128: is ubuntu-desktop taking care of conduit?
[04:14] <dholbach> azeem, dholbach: no idea - sorry
[04:14] <azeem> ok
[04:14] <seb128> superm1: uploads approved to proposed for edgy and feisty now
[04:15] <azeem> that conduit dude was talking in #opensync a while ago, I'll catch him next time I'll see him
[04:15] <superm1> thanks seb128 :)
[04:15] <seb128> azeem: no, any voluntar is welcome, I can sponsor uploads ;)
[04:15] <azeem> seems a conduit package is in gutsy
[04:15] <dholbach> azeem: is it http://launchpad.net/~doctormo you're talking about?
[04:15] <seb128> it's from debian
[04:16] <azeem> ah, right
[04:16] <azeem> dholbach: yeah, I guess
[04:16] <dholbach> azeem: so it should be doctormo on freenode
[04:16] <azeem> yeah, but he's not in here
[04:16] <azeem> ok, thanks
[04:16] <azeem> should've actually figured that out myself, sorry
[04:17] <dholbach> no problem :)
[04:17] <dholbach> azeem: he's on  #Perl #ubuntu-massachusetts @#dohickey #inkscape #ubuntu-us #ubuntu
[04:23] <seb128> superm1: mythbuntu-control-centre also accepted
[04:24] <superm1_> seb128, thx, was waiting on that one, but didn't want to badger :)
[04:24] <StevenK> Hum. Where is $XDG_APPS_DIR supposed to be set?
[04:25] <seb128> superm1_: mythbuntu-meta also accepted
[04:26] <seb128> StevenK: nowhere?
[04:26] <StevenK> seb128: % head -n 24 okular/shell/CMakeLists.txt | tail -n 1
[04:26] <StevenK> install( FILES okular.desktop  DESTINATION  ${XDG_APPS_DIR} )
[04:27] <seb128> StevenK: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
[04:27] <seb128> StevenK: those are the spec-ed variables
[04:28] <seb128> StevenK: XDG_APPS_DIR seems to be a KDE thing
[04:28] <seb128> maybe Riddell knows about it
[04:28] <StevenK> This thing has cmake and Hobbsee all over it, so agreed.
[04:29] <Hobbsee> wha?
[04:29] <seb128> Hobbsee: oh yes, you are
[04:29] <Hobbsee> seb128: like what?
[04:29] <seb128> Hobbsee: all over kubuntu ;)
[04:29] <Hobbsee> seb128: oh.  right.  only if it's going well.  if it's not, then it's all Riddell's fault.
[04:29] <seb128> :)
[04:30] <StevenK> Hrm. Yay for poppler API changes.
[04:30] <seb128> StevenK: they didn't change the soname for nothing ;)
[04:31] <StevenK> Heh
[04:32] <StevenK> seb128: I wonder if poppler have a lovely API web page like the libquicktime guys do.
[04:32] <seb128> ogra: should edubuntu-addon-meta be in main or universe?
[04:33] <ogra> main
[04:33] <ogra> need to seed that on server-addon
[04:33] <seb128> ogra: can you seed it? ;)
[04:33] <seb128> thanks
[04:33] <seb128> ogra: BTW new gnome-power-manager to package
[04:33] <seb128> StevenK: you can use devhelp to search the API
[04:33] <ogra> yup, will do both today
[04:34] <seb128> dholbach, kwwii: human-cursors-theme wants to go to universe, is that normal?
[04:34] <StevenK> seb128: Grmh? Can I have a little more of a hint?
[04:34] <dholbach> seb128: yes, we use dmz-cursor-theme now
[04:35] <seb128> StevenK: about what? you know devhelp?
[04:35] <StevenK> seb128: Nope, which is why I want a little more of a hint. :-)
[04:35] <seb128> StevenK: apt-get install devhelp
[04:35] <seb128> StevenK: it's a documentation, API browser
[04:35] <seb128> you have the index on the left and can search for function names
[04:36] <StevenK> Ah
[04:36] <seb128> all the GNOME API are indexed there
[04:36] <seb128> anything using gtk-doc
[04:36] <seb128> dholbach: thanks
[04:36] <tkamppeter> doko, ping
[04:38] <seb128> BenC: is kexec-tools needed to main? If that's the case could you seed it or make something in main (Build-)Depends on it? Because it wants to go to universe at the moment
[04:38] <doko> tkamppeter: pong
[04:41] <Riddell> StevenK: is that kde4graphics?
[04:42] <StevenK> Riddell: Nope, okular
[04:44] <geser> Can an archive admin move ion3-mod-xinerama from universe to multiverse (where ion3 is already). Thanks.
[04:44] <StevenK> ScottK, seb128: gimp uploading to my PPA
[04:45] <soren> cjwatson: I'm looking at the seeds and noticed some "Task-Key: " stuff.. I can't find it documented anywhere and looking at the germinate source didn't help me much. Am I looking in the wrong places, or is it just not documented?
[04:45] <Riddell> StevenK: right, well that variable should be set by the cmake include files, what's the actual problem?
[04:45] <seb128> StevenK: why not to Ubuntu? ;)
[04:45] <StevenK> seb128: Because I want more people than me to test it. :-)
[04:45] <ScottK> StevenK: I have to retract my testing offer.  The latest libhal (I'm pretty sure) did away with the cooling fan on my Gutsy install so it won't run for more than a few minutes other than at complete idle.
[04:46] <StevenK> Riddell: It looks to not be set, since the build bombs:
[04:46] <StevenK> /build/steven/okular-0.5.82/okular/shell/CMakeLists.txt:24:
[04:46] <StevenK> INSTALL FILES given no DESTINATION!
[04:46] <StevenK> ScottK: So noted.
[04:46] <seb128> Riddell: do you know why adept and debtags stopped Build-Depending on libtagcoll?
[04:46] <bddebian> cmake.. w00t love it!
[04:47] <dholbach> mvo: if I use python-apt for finding out if a package is in main or universe: is sources.Index.ArchiveURI or sources.Files my best bet?
[04:49] <Riddell> StevenK: it's probably in an old syntax for cmake, that's quite an old snapshot, I'll ask them when they plan to release a new one, in the mean time just ignore okular (and kde4graphics if you want, that has a new snapshot coming this week)
[04:50] <BenC> seb128: yeah, it should move to main
[04:50] <Riddell> seb128: not off hand, that tangle of dependencies always confuses me, what's the problem?
[04:50] <enrico> seb128: they now depend on libtagcoll2
[04:50] <enrico> seb128: and on libept
[04:50] <seb128> BenC: it is to main and wants to go to universe, could you sed or make something use it? ;)
[04:50] <StevenK> Riddell: I shall ignore okular, kde4graphics built fine and was uploaded.
[04:50] <seb128> s/sed/seed
[04:51] <seb128> Riddell: it's to main and wants to go to universe, you wrote the MIR so I'm asking if it's still needed or can be demoted
[04:51] <seb128> enrico: there is no libtagcoll2 in gutsy
[04:51] <BenC> seb128: I can make the linux-image-debug depend on it
[04:52] <seb128> BenC: thanks ;) There is no hurry, whenever you do the next upload is fine (I'm just trying to clean component-mismatches.txt)
[04:52] <enrico> seb128: then you can't build libept, debtags adn adept
[04:52] <Riddell> seb128: that should be fine to demote, they use libtagcoll2-dev now
[04:53] <soren> cjwatson: Ah... I think I've got it.
[04:53] <seb128> Riddell: thanks
[04:53] <Riddell> which is in gutsy
[04:53] <seb128> Binary: tagcoll, libtagcoll2-dev
[04:53] <seb128> right
[04:55] <soren> cjwatson: Yes, got it. Never mind.
[04:57] <cjwatson> soren: you should be looking in tasksel for that. documentation, uh, RTFS? ;-)
[04:57] <xhaker> Hey, it seems the next ATi proprietary driver will have support for AIGLX
[04:58] <seb128> calc: are you going to make openoffice use libsvg libvigraimpex libwpg?
[04:58] <xhaker> article at: http://www.phoronix.com/scan.php?page=article&item=821&num=1
[04:58] <seb128> calc: they are to main but want to go to universe since nothing use it at the moment
[04:58] <thom> in other news, silicon valley's airspace has just been entered by a squadron of pink porcine creatures doing mach 2
[05:00] <jwendell> doesn't Ubuntu have libiconv??
[05:00] <\sh> going home...end of business todayx
[05:02] <jwendell> ah libc6 :)
[05:06] <soren> cjwatson: Yeah, it was the "look in tasksel" bit that I was missing. :) Never having looked at a tasksel description before, I didn't recognize anything.
[05:06] <soren> cjwatson: I have a problem with it, though.
[05:06] <soren> cjwatson: I want to add several Key packages.
[05:07] <soren> cjwatson: If I add several "Task-Key: foo" lines, the ubuntu-seeds.pl script lists the last one three times.
[05:07] <mthaddon> anyone able to help me with a gutsy upgrade - bug 137539
[05:07] <ubotu> Launchpad bug 137539 in update-manager "update-manage incorrectly reports free disk space" [Undecided,New]  https://launchpad.net/bugs/137539
[05:08] <cjwatson> soren: meeting, will get back to yo
[05:08] <soren> cjwatson: like so: http://pastebin.ca/682409
[05:08] <soren> cjwatson: Ah, sorry.
[05:13] <Hobbsee> bug #134501
[05:13] <ubotu> Launchpad bug 134501 in gmountiso "[UVFe]  gmountiso 0.4" [Undecided,Triaged]  https://launchpad.net/bugs/134501
[05:13] <Hobbsee> seb128: er, pebkac error.
[05:14] <seb128> Hobbsee: what I figured ;)
[05:14] <Hobbsee> seb128: looks like i thought it was already in debian
[05:14] <Hobbsee> not that they've actually mentioned where the file in question is at all
[05:14] <seb128> Hobbsee: I've unsubscribed ubuntu-archive
[05:15] <calc> seb128: yes already using them in my current build, the current build has another set of problems so hasn't been uploaded yet
[05:15] <Hobbsee> seb128: thanks
[05:15] <calc> seb128: they just got put into main in the past couple days
[05:16] <soren> cjwatson: Never mind. :)
[05:16] <cjwatson> soren: I think you can comma-separate
[05:18] <tkamppeter> doko, still there?
[05:18] <doko> tkamppeter: did pong 1min after your ping ;)
[05:18] <tkamppeter> doko, it is about bug 130842
[05:18] <ubotu> Launchpad bug 130842 in ghostscript "[ia64]  ps2pdf crashes on ia64, causing several build failures" [High,Incomplete]  https://launchpad.net/bugs/130842
[05:18] <soren> cjwatson: Yes, exactly.
[05:19] <tkamppeter> doko, I can only report it upstream if I have a file with which I can reproduce it. See my last comment on the bug report.
[05:20] <doko> tkamppeter: I requeued it, lets see if it builds
[05:23] <tkamppeter> doko, OK. Were there very many packages not building due to this?
[05:24] <soren> seb128: If you have time to look at the system-config-samba binary package today, that would be much appreciated, too.
[05:27] <stgraber> asac: saw what I said yesterday at 20:25 ?
[05:28] <asac> stgraber: what kind of question :)
[05:29] <asac> stgraber: what did you say (sorry had to restart irssi so my scrollback is gone)
[05:29] <stgraber> 20:25 < stgraber> asac: result is that I have that deassociation problem only when moving back to Wired from Public
[05:29] <stgraber> 20:25 < stgraber> asac: and when I have the AP_SCAN 0 timeout thing
[05:29] <seb128> soren: binary accepted
[05:29] <asac> stgraber: yes ... do you know the place in code where i do that?
[05:30] <asac> stgraber: can you remove everything but the TERMINATE ? (e.g. DISABLE_NETWORK, AP_SCAN 0) ?
[05:30] <asac> and try if it helps?
[05:30] <stgraber> yep
[05:30] <asac> grep for TERMINATE in the patches to find the exact place
[05:30] <soren> seb128: woo!
[05:32] <stgraber> asac: I'm pretty sure I'll break 41u if I edit 41q ...
[05:32] <asac> stgraber: just outcomment ... should be easier in terms of no conflicts
[05:32] <asac> (outcomment source in patch with // i mean)
[05:33] <stgraber> k
[05:33] <stgraber> DISABLE_NETWORK is in NM code itself (not one of our patch), I'm trying to disable the AP_SCAN 0 part and test with that
[05:34] <doko> tkamppeter: did you my msg?
[05:36] <asac> stgraber: he?
[05:36] <asac> stgraber: i added DISABLE_NETWORK
[05:36] <stgraber> oh, really ? :)
[05:36] <asac> stgraber: maybe its in another patch
[05:36] <stgraber> so it isn't in the patch I'm currently reading
[05:37] <mvo> mthaddon: let me look at the update-manager issue
[05:37] <mthaddon> mvo, thx
[05:37] <tkamppeter> doko, which msg? The last one here on IRC was that you are requeuing the build of the package.
[05:37] <stgraber> (a good idea once those issues will be fixed would be to do a wpa_supplicant_hack.patch and ipw3945_hack.patch to replace all those small patches :))
[05:38] <mvo> mthaddon: could you please attach the content of /proc/mounts and the file /var/log/dist-upgrade/main.log to the bugreport?
[05:38] <mthaddon> mvo, sure will do
[05:38] <doko> tkamppeter: now?
[05:39] <Hobbsee> mvo: have you seen https://launchpad.net/bugs/137546, incidently?
[05:39] <ubotu> Launchpad bug 137546 in app-install-data-commercial "[Gutsy]  traceback while updating to 8.2" [Undecided,New] 
[05:39] <Chipzz> asac: ping
[05:39] <cjwatson> doko: hmm, upgrading libgtk2-perl to the current upstream version doesn't seem to help much. will need to dig some more
[05:40] <mvo> Hobbsee: oh, no. thanks
[05:40] <mthaddon> mvo, ok, that's done
[05:40] <doko> cjwatson: hmm, that was just what I did read from their page :-/
[05:40] <cjwatson> in fact, 1.146 fails (er, unexpectedly succeeds) one *more* test than 1.140
[05:40] <cjwatson> yeah, I saw that in the release notes too
[05:41] <cjwatson> it looks like we do need the current version due to GSlice changes in pango
[05:42] <bddebian> heh
[05:42] <cjwatson> hey, I made XS work with an entirely custom C++ standard library replacement, it was pretty hot :)
[05:43] <cjwatson> albeit evil beyond belief
[05:43] <Hobbsee> hah
[05:43] <thom> reimplimenting mod_perl in zeus was *never* hot ;)
[05:45] <cjwatson> http://support.zeus.com/zws/examples/2005/12/16/perl_extensions_introduction
[05:45] <cjwatson> thom: so was
[05:45] <cjwatson> ok, the proprietary kind of hot, BUT STILL
[05:46] <thom> when you're standing at the pearly gates, whatshisface will be weighing up good and evil. and then he'll come to that, and cast you straight down.
[05:46] <thom> :)
[05:46] <bddebian> hah
[05:46] <Hobbsee> cjwatson: dont even *try* to validate your temporaral smoking of the crack pipe :P
[05:47] <Hobbsee> it wont work.
[05:51] <calc> lol
[05:54] <mvo> mthaddon: hm, looking at the figure it does not look entirely implausible. it requires to download 1,6G of deb packages (that is quite a lot but not impossible much) and an additional 900mb of hardspace on / will be used. the free space on "/" may just be a little bit too small
[05:55] <mthaddon> mvo, oh, so when it says it needs 900 free, it, actually needs 900 + 1.6 GB?
[05:55] <mthaddon> mvo, if so, I can try freeing up some extra space
[05:56] <mvo> mthaddon: aha, I see. I think the message is just misleading :/
[05:57] <mthaddon> mvo, yeah, seems a little misleading, but will free up the space and I'm sure it'll be fine - thx
[05:57] <mvo> mthaddon: what is the exact message? could you paste it please (word for word)? it maybe that the size is displayed incorrectly in the message
[05:58] <mthaddon> mvo, will run it again and take a screenshot and attach it to the bug
[05:58] <mvo> mthaddon: i.e. that it does not sum up the space required for the deb package and the additonal space on the HD in the message so that people get confused
[05:58] <mvo> mthaddon: that is great, thanks a lot!
[05:59] <mathiaz> mvo: I've tried to use update-manager-core to upgrade a feisty server to gutsy.
[05:59] <asac> Chipzz: ?
[05:59] <tkamppeter> doko, are you still there?
[06:00] <asac> Chipzz: ipw2200 right?
[06:00] <mathiaz> mvo: I was using the do-release-upgrade command. Is this the correct one ?
[06:00] <mathiaz> mvo: because it failed with an error message saying no dist found in the meta file (or something like that).
[06:00] <mvo> mathiaz: yes, please run it with "-d" to get the current development release. if it fails, please file a bug and include /var/log/dist-upgrade/main.log
[06:01] <mvo> mathiaz: and notify me on irc :) today seems to be the release-upgrade day for some reason :)
[06:01] <mathiaz> mvo: ok. I'll try again.
[06:01] <mvo> mathiaz: thanks!
[06:03] <asac> siretart: ping?
[06:06] <Chipzz> asac: yes
[06:08] <Chipzz> asac: so anyway, no networkmanager either... not a big fan of it
[06:09] <asac> Chipzz: well ... lets start then
[06:09] <asac> Chipzz: it associates automatically for you?
[06:09] <asac> Chipzz: how do you trigger this? when do you see it?
[06:11] <Chipzz> asac: sorry if I respond tardily, crappy wireless
[06:11] <Chipzz> asac: not really reproducible, but it occurs sometimes, not every time, when the network it is supposed to be asociating with is not "in reach"
[06:12] <Chipzz> ie, too bad (to nil) reception
[06:12] <Chipzz> and
[06:13] <asac> Chipzz: sorry please rephrase ;)
[06:13] <stgraber> asac: http://paste.stgraber.org/3400
[06:13] <stgraber> asac: will be back in 15min or so
[06:14] <asac> stgraber: so you managed to go back to eth0 ?
[06:14] <Chipzz> I think when I rmmod and modprobe the module
[06:15] <Chipzz> asac: currently, the network I'm trying to associate with sometimes has bad reception here
[06:15] <Chipzz> when the reception drops below a certain point, ie when iwlist would not show it (I *think*)
[06:15] <asac> stgraber: can you confirm that the TERMINATE works well when you try to reconnect to wireless device (e.g. two times in a row)
[06:16] <Chipzz> *iwlist scan
[06:16] <cjwatson> doko: ahh, I think I may have been using the wrong branch
[06:16] <cjwatson> (libgtk2-perl)
[06:16] <ogra> cjwatson, got it all working now, i was simply looking at a way to low level, blindly not noticing that deboootstrap already had a frontend problem (it could be a bit noisier though) i tried to fix it in the chrooted apt-get calls ... using debconf vars at the very top level helps a lot :)
[06:17] <cjwatson> ogra: ah, right, good stuff
[06:18] <asac> Chipzz: 1. you modprobe your module ... is it (auto-)associating right after that?
[06:18] <ogra> debootstrap cheats me every time though ... last time it took me as well two days to find that it failed there ... it should really throw a lod error :)
[06:18] <ogra> *loud
[06:20] <sbalneav> dendrobates: Hey, any idea where I can follow the status of what the auth-server team is developing?
[06:21] <Chipzz> asac: more like 1) reception drops below certain point, so to fix it I 2) rmmod the module, and 3) I modprobe it. And it auto-associates right after that (but only sometimes)
[06:22] <asac> oh
[06:23] <Chipzz> asac: btw, this is plain and simple WEP, no WPA or anything
[06:24] <asac> how do you manage your connections?
[06:24] <Chipzz> I have a set of configurations in /e/n/i which I comment in/out according to needs
[06:25] <mvo> mthaddon: ok, I think I know what causes this incorrect message, thanks for reporting!
[06:25] <Chipzz> if that's why you mean
[06:26] <mthaddon> mvo, cool
[06:26] <Chipzz> and ifup/ifdown
[06:26] <Chipzz> asac: AFK for a bit
[06:28] <stgraber> asac: it works yes
[06:29] <stgraber> asac: it's causing two problems when switching from Public to Wired, first it doesn't deassociate (which is a problem with the ipw3945 driver), second it takes some seconds to actually start connecting to wired (and then some users may think that they didn't correctly clicked on wired and click a second time ...)
[06:31] <stgraber> asac: switching between wireless (public and WPA) work fine, switching between WPA and Wired too
[06:31] <asac> stgraber: are we sure that the driver gets told to deassociate?
[06:31] <asac> do you see thate deassoc debug output in driver log?
[06:32] <asac> stgraber:                         IPW_DEBUG_ASSOC
[06:32] <asac>                             ("Deassociating because OFF/ANY set with auto association"
[06:32] <asac>                                 " disabled.\n");
[06:35] <Chipzz> asac: back
[06:36] <asac> Chipzz: is a bit strange .... the driver probably doesn't remember any previous association attempt
[06:38] <asac> you sure it doesn't happen after loading the module for the first time?
[06:44] <stgraber> asac: http://www.stgraber.org/download/nm-debug-wpa
[06:44] <asac> Chipzz: try echo 65535 > /proc/net/ipw/debug_level ... and see if you get debug messages from driver
[06:44] <Chipzz> asac: not sure
[06:44] <stgraber> asac: I just had the same issue while switching from WPA to Public
[06:44] <Chipzz> asac: I just had it happen a couple of moments ago
[06:44] <stgraber> asac: and then no issue when switching from Public to Wired
[06:44] <stgraber> asac: so it seems to appear randomly (I hate that)
[06:44] <stgraber> asac: look at 18:38:48
[06:45] <Chipzz> # echo 65535 > /proc/net/ipw/debug_level
[06:45] <Chipzz> -su: /proc/net/ipw/debug_level: No such file or directory
[06:45] <stgraber> Chipzz: /sys/bus/pci/drivers/ipw3945/debug_level
[06:45] <asac> stgraber: you see any pattern in kernel log? .e.g. what happens when it blocks ... what doesn't happen when it does?
[06:45] <asac> stgraber: he has ipw2200
[06:45] <stgraber> oh
[06:45] <asac> stgraber: i took this out of code ... might be wrong place though
[06:45] <asac> Chipzz: try to find it ... should be somewhere
[06:46] <Chipzz> # find /proc -name "*ipw*"
[06:46] <Chipzz> /proc/irq/7/ipw2200
[06:46] <Chipzz> # find /sys -name "*ipw*"
[06:46] <Chipzz> /sys/module/ipw2200
[06:46] <Chipzz> /sys/module/ipw2200/drivers/pci:ipw2200
[06:46] <Chipzz> /sys/module/ieee80211/holders/ipw2200
[06:46] <Chipzz> /sys/bus/pci/drivers/ipw2200
[06:46] <Chipzz> any of the sys ones?
[06:46] <asac> /sys/bus/pci/drivers/ipw2200/debug_level ?
[06:46] <Chipzz> yeah google just told me that ;)
[06:47] <stgraber> asac: looking at the log, it seems that the driver simply doesn't receive the TERMINATE, it doesn't even try to deassociate
[06:47] <asac> yeah ... what wpasupplicant are you using?
[06:48] <asac> stgraber: i am sure its something blocking wpasupplicant
[06:49] <asac> stgraber: i think that its blocked in some other operation and thus can't exit the eloop in time (12 seconds)
[06:49] <Chipzz> asac: aha, I just reproduced it
[06:49] <Chipzz> and dumped dmesg to a log
[06:49] <asac> stgraber: can you try to boost that time to ridiculous 30 or 40 sec?
[06:50] <Chipzz> asac: this looks suspicious:
[06:50] <Chipzz> [261181.832000]  ipw2200: Firmware error detected.  Restarting.
[06:50] <Chipzz> [261181.832000]  ipw2200: Failed to up device
[06:50] <asac> Chipzz: syslog please
[06:50] <asac> oh yes indeed
[06:50] <Chipzz> one of the last things in the log after rmmod/modprobe
[06:50] <Chipzz> *after doing
[06:51] <Chipzz> :q
[06:51] <Chipzz> whoops
[06:51] <stgraber> asac: I'm using gutsy's
[06:53] <asac> stgraber: can you try 0.5.8 from http://siretart.tauware.de/upload-queue/ ?
[06:54] <stgraber> asac: I'll, I've got to go for some hours but will try once back (I've the amd64 one somewhere on my system I'll just have to install it and test
[06:54] <stgraber> )
[06:56] <asac> stgraber: ok
[06:56] <Chipzz> asac: can't reproduce it atm
[06:56] <Chipzz> but I'm not getting associated after modprobing
[06:56] <Chipzz> also with the firmware error
[06:57] <Chipzz> hrrrrm
[06:57] <Chipzz> apparently I'm not always getting the firmware error
[06:58] <Chipzz> asac: btw, I'm not 100% sure if this is still the case, but I had problems in the past configuring my wireless network manually with iwconfig
[06:59] <Chipzz> changing essid would not work when the module was loaded, what would work was putting the config in /e/n/i and rmmod'ing + modprobing ipw2200
[07:00] <geser> Mithrandir: can you please move ion3-mod-xinerama from universe to multiverse (where ion3 is already). Thanks.
[07:00] <ogra> ino3 in multiverse ? wow
[07:00] <ogra> how did that happen
[07:02] <geser> ogra: it did move there as upstream was unhappy with Debian and changed the licence
[07:02] <ogra> wow, thats mean
[07:05] <Chipzz> asac: aha, just managed to reproduce
[07:06] <geser> ogra: iirc it has something to do that Debian stable had some old devel version and Debian didn't want to update it in stable
[07:07] <ogra> which is policy ... well ... shrug ...
[07:07] <ogra> i dont use it .... but i know *many* users
[07:08] <Chipzz> asac: http://chipzz.safehex.be/random_associate
[07:08] <Chipzz> asac: AFK now, ping me if you want more info ;)
[07:15] <asac> Chipzz: you didn't enable the debug_level
[07:23] <mvo> mthaddon: I'm preparing a new version that should fix the error message, would you mind waiting a bit with our upgrade so that you can test the new version and if it correctly reports the size requirements now?
[07:24] <mthaddon> mvo, too late - already started it :) but I can probably figure out a way to replicate the issue on another machine and test it there
[07:24] <mvo> mthaddon: ok, no problem. I can do that here too, it would have been nice to have a real-world test-case in additon to my canned test :)
[07:37] <mvo> mthaddon: its entirely possible that you will be bitten by another bug that I just fixed in the process :/
[07:41] <asac> stgraber: i see something like:
[07:41] <asac> WEXT auth param 4 value 0x0 - eloop: could not process SIGINT or SIGTERM in two seconds. Looks like there
[07:41] <asac> is a bug that ends up in a busy loop that prevents clean shutdown.
[07:45] <mthaddon> mvo: what's that?
[07:47] <mvo> mthaddon: a bug in the gtk upgrade view when the upgrade actually starts, if you use kde or the textview it will work, otherwise its probably best to cancel now and just wait a bit, it should be available failry soon (the update)
[07:47] <asac> stgraber: i see that output when running nm from terminal with --no-daemon option
[07:47] <mthaddon> mvo: is it worth going through just so it downloads the packages for the next time I run it?
[07:48] <mthaddon> mvo, and how do I use the textview if I want to go ahead with that?
[07:48] <mvo> mthaddon: you can cacncel it at ~90% or so, if you cancel it it will restore your system state (i.e. rewrite your sources.list back to the original one)
[07:49] <mvo> mthaddon: "do-release-upgrade -d", but I would just wait, the upload will happen in max. 1h
[07:50] <mthaddon> mvo: oh, ok, cool - will I get it if I cancel as my sources.list will be pointing to the gutsy stuff?
[07:50] <mvo> mthaddon: if you cancel it will restore the original sources.list
[07:50] <mthaddon> mvo, cool, thx
[07:51] <\sh> ladies and gentlemen, does anyone has time to discuss an important issue? regarding wine 32bit packages on amd64... I'm just reviewing a new package of our upstream and need some advise regarding lib installation structure and packaging structure
[08:25] <Chipzz> asac: I did; could it be that it's reset when rmmod'ing/modprobing the module?
[08:49] <Chipzz> asac: log with debug information online on same location
[08:53] <tkamppeter> doko, still there?
[08:53] <keescook> hm, any reason pam isn't listed on merges.ubuntu.com ?
[09:25] <soren> keescook: Merges seems to not be running.
[09:25] <soren> keescook: MoM, I mean.
[09:25] <Luke> asac: you around?
[09:25] <keescook> soren: that would explain it.  ;)
[09:26] <soren> keescook: The {main,restricted,universe,multiverse}.html date back to August 24th.
[09:26] <keescook> heh, oops
[09:37] <asac> Chipzz: yes
[09:38] <asac> Chipzz: you can load the module with debug_level parameter i think
[09:38] <asac> Luke: yes ... haven't received any mail
[09:38] <asac> even looked in spam folder
[09:44] <Chipzz> asac: I did that\
[09:44] <Chipzz> crap, can't type on this keyboard...
[09:44] <Chipzz> oh, wait, it's mine...
[09:47] <davmor2> Riddell: ping
[09:52] <Riddell> hi davmor2
[09:54] <davmor2> Riddell: I started a 24hr testing of kubuntu today did the updates and now the network icon has gone and the live cd has a bluetooth crash on it that continues to the installed system.
[09:55] <Riddell> davmor2: both known thanks, network-manager-kde has a new upload that should be available soon to fix the firs
[09:55] <Riddell> bluetooth is waiting on a fix from mhb and doko
[09:55] <doko> Riddell: ?
[09:55] <davmor2> okay np I'll carry on and see if I find anything else then
[09:59] <bryce> Riddell, fyi, we're going to be switching on bulletproof-x hopefully by tomorrow.  All major issues holding it back have been resolved.
[10:01] <bryce> Riddell, also fyi, the xserver backports are coming along well; status page is at https://wiki.ubuntu.com/X/Fixes_to_Backport.  The first set of backported fixes from xorg 1.3.99 was uploaded yesterday, and I've got a second set taken mostly from fedora which I'm hoping to have ready before Friday.
[10:02] <bryce> There are also some misc. bits and pieces leftover that might be worth pulling in post-beta.  We'll see.
[10:05] <allee> doko: Riddell refers to 'import dbus.mainloop.qt' fail to load qt module.   I think mhb has pinged you already about this
[10:06] <doko> allee: no?
[10:07] <allee> doko: this link is needed to get import work properly: /var/lib/python-support/python2.5/dbus/mainloop/qt.so -> /usr/lib/python2.5/dbus/mainloop/qt.so
[10:07] <allee> doko: ^^ hack of course
[10:08] <allee> doko: qt.so is the only thing in /usr.  Al other releated stuff in in /var
[10:08] <doko> ahh, the great fun of python-support, yeah!
[10:08] <bddebian> heh
[10:09] <doko> I'll look at that tomorrow
[10:10] <allee> doko: as kblueplugd need to import dbus.mainloop.qt.  Every Kubuntu user get's on login a apport msg :(
[10:10] <allee> doko: thx great!!
[10:19] <siretart> asac: pong
[10:22] <allee> siretart: hi!! Long time no see :)   Curious: you have any plans about fai 3.2+ ?
[10:23] <siretart> allee: well, in principle I have a fai branch which I need to test
[10:24] <siretart> allee: I was having heavy problems with our squid proxy, which needed to be fixed first, and then got disctracted with lots of other stuff
[10:24] <siretart> allee: but In principle, it 'just' needs testing. I plan to test it in a PPA
[10:28] <allee> siretart: okay.  I'll let you know  IIIIFFFF I find time to work on it too
[10:30] <siretart> allee: thanks!
[10:48] <Lure> doko: allee was talking about bug 135893
[10:48] <ubotu> Launchpad bug 135893 in kdebluetooth "kblueplugd crashed with ImportError in <module>()" [Medium,Confirmed]  https://launchpad.net/bugs/135893
[10:51] <nny> how do you check which version of a package the repository has with apt?
[10:52] <ajmitch> short way: apt-cache madison
[11:08] <siretart> nny: `rmadison -u ubuntu $package`
[11:21] <mdke> is gutsy in a decent ish state? I'd like to upgrade
[11:23] <asac> siretart: ... are you aware of a supplicant bug that makes TERMINATE fail?
[11:34] <nny> thanks
[11:39] <mathiaz> keescook: I'm going throught the sysklogd bugs on LP.
[11:39] <keescook> mathiaz: excellent
[11:39] <mathiaz> keescook: It seems that debian has an updated version of the package
[11:40] <mathiaz> keescook: actually upstream has released a new version
[11:40] <mathiaz> keescook: do you think it's worth trying to merge it ?
[11:41] <keescook> mathiaz: if it fixes some of the open bugs, it would be worth getting a UVFe for it, sure.
[12:11] <asac> siretart: after blocking for some time there is an error that eloop is not terminating et al
[12:16] <mthaddon> just done an upgrade to gutsy and udevd seems to be hogging CPU - anything I can do about that?
[12:22] <ionstorm> i had the same problem
[12:22] <ionstorm> gutsy dont support rt73 drivers either
[12:22] <ionstorm> locks up the box