[07:59] <Japje> for custom images (debian 10 in my case) is there a way to re-create the 90_dpkg* files so i can access the maas datasource?
[07:59] <Japje> perhaps somehow from within curtin
[12:09] <ivve> anyone know if its possible with some modification to _not_ use lwIP in pxelinux?
[12:09] <ivve> via maas
[12:16] <ivve> to be honest i think the shift made in 2.4 to 2.6 with pxe will follow a lot of problems since the issue isn't in maas but in drivers and pxe. example HP machines older than gen9 don't work
[12:31] <ivve> nvm figured it out :)


[23:25] <mup> Bug #2047178 opened: Cannot lock device that status is `allocated`. <MAAS:New> <https://launchpad.net/bugs/2047178>
[23:25] <mup> Bug #2047180 opened: MAAS no longer producing logs <MAAS:New> <https://launchpad.net/bugs/2047180>


[12:13] <Rinchen> ogra, I had tried to sort through lsof with as many of the processes stopped as possible but even then the output was enormous
[12:13] <cjwatson> bryce: I've approved xorg7.3; not got to the other two yet, but it's OK, I think they're in reasonable shape now and I'll do them tomorrow
[12:14] <bryce> ok cool, thanks
[12:16] <bryce> ok, I need to hit the post office before they close; be back in a bit
[12:17] <Chipzz> tepsipakki: I actually used one of those settings for preseeding :P
[12:17] <Chipzz> but nothing major
[12:17] <tepsipakki> Chipzz: heh
[12:18] <Chipzz> (using the modules setting to prevent certain modules from being loaded, when setting up an ltsp chroot)
[12:19] <Chipzz> 23:43 < tepsipakki> some of the xserver-xorg debconfage has been removed by debian, but only the uninteresting ones (like modules, fontserver)
[12:21] <Chipzz> (I wanted to prevent to monitor from turning itself off)
[12:21] <tepsipakki> bryce: we won't compile libX11 against xcb for gutsy either? (reading the spec)
[12:36] <Neliath> Could somebody comment on this, please: http://lists.gnu.org/archive/html/gnewsense-users/2007-05/msg00136.html
[12:40] <mjg59> Neliath: No, it's not in the slightest bit on-topic here
[12:40] <Neliath> mjg59, how can you say that while we are on the affected network?
[12:41] <mjg59> Neliath: Because, as the topic states, this channel is for the discussion of Ubuntu development - not Ubuntu policy, Freenode policy or anything else
[12:41] <Neliath> mjg59, imagine you have a disagreement with christel and she posts your private data to people who hate you
[12:41] <mjg59> Neliath: Still not on-topic
[12:42] <Neliath> "this is not on-topic" means you dont care about the topic
[12:43] <mjg59> Nice timing
[12:43] <Hobbsee> i'd imagine he was in multiple channels
[12:48] <ajmitch> Hobbsee: yes well he spammed #debian-devel on here with it
[12:49] <Hobbsee> fun
[12:49] <ajmitch> which is a fairly quiet channel
[12:52] <ajmitch> isn't that your preferred form of modification?
[12:54] <mjg59> Yeah, I enjoy hacking binary DSP code with no indication of what the instruction set is
[12:54] <mjg59> Actually, I chatted to the Maestro driver author last month - ESS had no idea of what the DSP instruction set was either, as far as I can tell
[12:54] <ompaul> mjg59, line 698 afik]
[12:55] <mjg59> ompaul: Yeah. That's DSP code.
[12:55] <mjg59> The comment above makes it sort of clear :)
[12:55] <ompaul> hmm will we ever reinclude it
[12:56] <ompaul> I'll pass it back :)
[12:56] <mjg59> Also pretty sure starfire_firmware.h is, well, firmware
[12:57] <mjg59> Actually, a lot of stuff on the FalsePositive list is sourceless firmware
[12:57] <mjg59> It'd be interesting to know what the checking process was
[12:57] <mjg59> Though a lot of it is also just conversion tables
[01:09] <bryce> tepsipakki, I may not have stated it correctly, but I think the intent we decided on was to provide both a libx11 with xcb, and a legacy version for binary apps
[01:09] <bryce> tepsipakki, however I'd like to see evidence that we definitely need it (I assume we do but don't know for certain yet)
[01:44] <keescook> anyone have any idea how ubuntu has unlimited lock memory (ulimit -l)  the kernel default is 32k.
[01:45] <elmo> /etc/security/limits.conf ?
[01:45] <elmo> (I'm WAGing)
[01:46] <keescook> elmo: nope.  I can't find any trace of it.  not in limits.conf, not set by upstart.  very odd
[01:47] <elmo> is the default soft or hard?
[01:48] <keescook> the unlimited is soft, but I would like it to be 32k hard
[01:52] <ashok> hi
[01:53] <ashok> i need a ubuntu mentor on how to start developing in ubuntu
[01:53] <ashok> can u people guide me how the process goes
[01:53] <Riddell> depends on what you're developing
[01:53] <crimsun> where in https://wiki.ubuntu.com/UbuntuDevelopment are you starting?
[01:53] <ashok> i would like to develop java applications in ubuntu
[01:54] <ashok> yeah i've registered
[01:54] <Riddell> ubuntu itself doesn't use java for applications
[01:54] <Riddell> if you just want to develop java stuff that happens to be on ubuntu, you want a java community to help
[01:55] <ashok> than how can i contribute to ubuntu
[01:55] <ashok> i am not attached to java only
[01:55] <ashok> just develop some applications maybe in python
[01:56] <Riddell> bugfixing, packaging, we have a limited number of applications we maintain ourselves almost all in python, doc writing etc etc
[01:56] <ashok> can u give me basic idea of python
[01:56] <Riddell> best way to start is to find a bug that annoys you and fix it
[01:57] <Riddell> but most of our code comes from upstream projects
[01:57] <ashok> upstream projects??
[01:57] <ashok> can u elaborate
[01:57] <Riddell> kde, gnome, linux, X etc
[01:57] <`23meg> projects that produce the code of the components that make up Ubuntu
[01:58] <ashok> ok
[02:00] <`23meg> here are some relevant links: https://wiki.ubuntu.com/NewDeveloperProcess , https://wiki.ubuntu.com/MOTU/#head-ec7a97d5af67e96747b4f36993232ff434f4486c
[02:00] <ashok> ok
[02:05] <ashok> what are the starter bugs which i can start with
[02:05] <ashok> just to get along
[02:05] <ashok> i mean some smaller bugs
[02:35] <scoobydoo28139> Are the developers in here
[02:36] <scoobydoo28139> If the developers are in here i would like to thank you personaly(chatwise anyway)
[02:36] <scoobydoo28139> Thank you for giving me a novice operatable verson of an OS, its verry nice
[02:37] <scoobydoo28139> And I want to thank you for your time that you have put into it.
[02:38] <bryce> heya scoobydoo28139
[02:38] <scoobydoo28139> I hope some one sees this , have a good night
[02:38] <scoobydoo28139> hello bryce:
[02:39] <bryce> yeah right now is sort of a quiet time, but I'm sure the ubuntu team will see your comments.  Good to hear you're enjoying it.  :-)
[02:39] <scoobydoo28139> bryce: do you help with the development of ubuntu?
[02:39] <scoobydoo28139> ok that was a delay
[02:39] <bryce> yes, although I joined after feisty, so can't take any credit :-)
[02:40] <scoobydoo28139> well I can still appriciate a good OS that has novice people in mind
[02:40] <scoobydoo28139> and to the people taking a chance on an os these days is hard to do
[02:40] <bryce> you know, if you're ever interested in joining in on development (even in non-coding areas), folks would love to welcome you
[02:41] <scoobydoo28139> If i could i would, I am still trying to figure out terminal. I am however passing out cd's. around 300+ so far in this hick town.
[02:42] <bryce> awesome, marketing's a great contribution :-)
[02:42] <scoobydoo28139> Most are still wondering what a computer is here
[02:43] <bryce> I set up a ubuntu box for my mother a while back, and it's worked well - no popups, spyware, etc. means very little IT work for me :-)
[02:45] <scoobydoo28139> my bigest complain is finding someone with the patience to deal with a total newb like me
[02:46] <bryce> we were all newb's once ;-)  As long as you're polite, do homework before asking questions, and stick to tasks, people seem happy to help get newbs up to speed
[02:47] <scoobydoo28139> I will continue to help spread the ubuntu OS all over,If money would just grow on trees , i could do my own ship it
[02:48] <bryce> cool, increasing the userbase is always a big help.  :-)
[02:48] <bryce> also keep your eye out for other smart young folk who might be interested in doing development, and help steer them in the right (open source) direction
[02:49] <scoobydoo28139> Ya know what makes microsoft so apealing and hard to over come is...
[02:50] <scoobydoo28139> It is easy to install everything- its mostly a no brainer. That is hard for people to over come. And the ink jet suport like for my dell photo 944, is scarce
[02:52] <scoobydoo28139> so when i pass out this ubuntu os its hard for me to explain about some things. I even have a tv card i can't use and the game thing is weard to understand. But i have hope that i am promoting a os in progress:)
[02:54] <scoobydoo28139> any way i am going to get back to scoping out how to open installer.sh file :) good chatting with ya, and again thanks for ALL that you all do. From NC rutherfordton good day
[02:55] <scoobydoo28139> bryce: one more thing.. how did you learn to write code?
[02:57] <bryce> hmm, as a kid 20-some years ago, I copied it out of books and magazines into my vic20 and poked at it a lot
[06:39] <fabbione> morning guys
[06:40] <Hobbsee> morning fabbione!
[06:40] <fabbione> hey Hobbsee
[06:45] <Burgundavia> hey fabbione
[06:45] <fabbione> yo
[07:15] <tepsipakki> bryce: ok, I think java is the one that matters, and hopefully Sun  will fix it soon
[07:21] <pitti> Good morning
[07:24] <LaserJock> morning pitti
[07:35] <Hobbsee> morning pitti!
[08:49] <pitti> BenC: for the record, rejecting 2.6.22-6.13 kernel binaries due to i386 FTBFS
[09:36] <dholbach> good morning
[09:37] <mdke_> morning dholbach
[09:37] <dholbach> hi mdke_
[09:39] <sacater> damnit
[09:39] <sacater> that was not me who did that quit message
[09:39] <sacater> my stupid brother
[09:39] <sacater> please ignore it
[09:40] <pygi>  Hobbsee !
[09:47] <Mithrandir> pitti: might be worthwhile mailing him + cc to ubuntu-archive@lists too
[09:47] <pitti> Mithrandir: right
[09:48] <Mithrandir> the whole IRC isn't a very good permanent record thing.
[09:53] <desrt> pitti; yr (getting?) married?
[09:53] <Hobbsee> desrt: somethinig like that
[09:53] <pitti> desrt: yep, in August; lots of prep until then, too
[09:53] <desrt> Hobbsee; fail a few classes or worse?
[09:53] <Hobbsee> desrt: actually, it's mroe "cut me some more slack, i'm working on it"
[09:54] <desrt> pitti; i had no idea.  congrats.
[09:54] <Hobbsee> desrt: havent failed yet.  its' labs and such that i've missed, assignments not handed in, classes that i havent attended.
[09:54] <desrt> i guess UDS was in the middle of the term?
[09:54] <pitti> desrt: thanks
[09:54] <Hobbsee> desrt: yep
[09:54] <pygi> Hobbsee, but you *must* attend them :P
[09:54] <desrt> Hobbsee; eh.  you make choices.
[09:54] <Hobbsee> desrt: yeah, i know.  i didnt expect to get *this* far behind though.  i thought i'd be OK
[09:55] <desrt> Hobbsee; imo, if you can deal with this uni stuff, you made the right choice
[09:55] <Hobbsee> heh
[09:55] <Hobbsee> we'll see, we'll see
[09:55] <desrt> good luck, in any case
[09:55] <pygi> that's why I'm hiding :P
[09:56] <Hobbsee> desrt: thanks.  i be needing it.
[09:56] <desrt> Hobbsee; you wouldn't be a true hacker if you weren't in trouble at school :)
[09:56] <desrt> Hobbsee; and after all... IRC = i repeat classes.
[09:56] <Hobbsee> desrt: but i was always a good student!  :P
[09:56] <Hobbsee> heh
[09:57] <desrt> Hobbsee; eh... there comes a point when you're learning more outside of school than inside of it
[09:57] <Hobbsee> desrt: that's true.  but still.
[09:57] <desrt> Hobbsee; but that doesn't make the little piece of paper they hand you at the end any less valuable
[09:57] <Hobbsee> i just hate letting people down
[09:58] <Hobbsee> ture that
[09:58] <desrt> are you in compsci?
[09:59] <Hobbsee> optoelectronics
[09:59] <Hobbsee> so it's not quite related, either.
[09:59] <desrt> oh ya.  i think you mentioned that before
[10:00] <desrt> makes it a bit harder to justify jetting off to ubuntu confs :)
[10:00] <Hobbsee> exactly
[10:01] <desrt> hello 4am.  it's disgusting to see you.
[10:02] <siretart> hi pygi
[10:02] <desrt> Hobbsee; best of luck
[10:02] <pygi> hi siretart :) How are you ? ^^
[10:02] <Mithrandir> night, desrt
[10:02] <seb128> desrt: "hello pillow, nice to see you"? ;)
[10:02] <siretart> pygi: fine! thanks
[10:02] <pygi> siretart, just looking over what (if anything) I broke
[10:03] <pygi> doing some major changes to libisofs
[10:03] <pygi> 4000 lines changed so far
[10:03] <siretart> pygi: how;s work going on with libburn?
[10:03] <pygi> in a week.
[10:03] <pygi> siretart, perfect :)
[10:03] <pygi> more on libisofs lately, since I didn't got a lot of time before to work on it... but it's advancing :)
[10:03] <siretart> pygi: I subscribed you to bug #117948 - did you notice it?
[10:03] <ubotu> Launchpad bug 117948 in libisofs "libisofs4-dev has no .so for linking" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117948
[10:04] <pygi> no, but I will look now :)
[10:04] <pygi> oh ,very descriptive
[10:04] <pygi> will look at it as soon as I can
[10:04] <pygi> it's weird
[10:04] <pygi> ah, ah, seb :)
[10:05] <pygi> ok, assigning to me
[10:05] <pygi> testing to see if svn produces .so
[10:06] <pygi> or it won't compile :P
[10:06] <pygi> knew I broke something
[10:07] <pygi> testing 0.2.4
[10:08] <pygi> 0.2.4 does produce .so files
[10:09] <pygi> must be something weird with the deb
[10:09] <pygi> I'll look it after today. Important exam. Ok?
[10:12] <pygi> or anyone else for that matter
[10:12] <pbn> firestarter ?
[10:13] <pbn> bug 118204 ?
[10:13] <ubotu> Launchpad bug 118204 in kdeartwork "kfiresaver.kss chewing up 154% CPU" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118204
[10:13] <pbn> no that's kfiresaver :)
[10:15] <siretart> pygi: sure (I'm at work right now)
[10:15] <pygi> siretart, oh, oki then ^_^
[10:18] <pitti> siretart: woot! ffmpeg has a shared lib now?
[10:18] <siretart> pitti: the debian one ships it for quite some time now
[10:19] <siretart> pitti: could you perhaps move the ffmpeg library binary packages to main and give back xine-lib? xine-lib is waiting for them
[10:19] <pitti> siretart: hm, so they are good for main now, but shouldn't go on the CDs, right?
[10:20] <siretart> right
[10:20] <siretart> none of them
[10:20] <pitti> that makes me nervous...
[10:21] <cjwatson> erm
[10:21] <cjwatson> that's been deliberately blocked on germinate work for a while now
[10:21] <cjwatson> per a TB decision
[10:22] <Mithrandir> cjwatson: wouldn't a big red blinking note on the testing/ pages work as well?
[10:22] <cjwatson> I suppose, but I'd really rather have germinate do it
[10:22] <siretart> cjwatson: err, the last time I called the TB for this, I was told the packages were fine for main, as long as they don't get on the CD
[10:23] <cjwatson> siretart: yes, which requires germinate work to enforce the latter
[10:23] <cjwatson> how about '!ffmpeg' or whatever to blacklist a binary package from everything in the containing seed or inside?
[10:24] <cjwatson> I think that syntax is free
[10:24] <pitti> cjwatson: all binaries from that source? or listing the binaries explicitly?
[10:24] <pitti> for ffmpeg the former would be easier
[10:25] <pitti> but the latter is more precise
[10:25] <cjwatson> !%ffmpeg
[10:25] <ubotu> Sorry, I don't know anything about ffmpeg - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[10:25] <cjwatson> just stack the syntaxes :)
[10:25] <rohan> the 2.6.20-16 kernel build for feisty disabled libata ?
[10:28] <siretart> cjwatson: the binary package 'ffmpeg' is for universe anyway
[10:29] <siretart> cjwatson: actually, only the binary package 'libavcodec.*' (regexp) are 'dangerous' and need to stay off. the other ones (libavutil, libavformat, libpostproc) are harmless patentwise
[10:29] <crimsun> rohan: git commit 51d8d888cdc05e426af4cbb93d5c3aea9f6b7b01
[10:29] <sabdfl> anybody have a quick answer to: how many files are in the ubuntu kernel source package?
[10:30] <sabdfl> and how much space do they take up?
[10:30] <rohan> crimsun: thanks
[10:30] <cjwatson> siretart: I couldn't remember the exact binary package name; it was just an example
[10:31] <fabbione> sabdfl: about 22K files..
[10:32] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/linux/ubuntu>$ find -name .git -prune -o -print | wc -l; du -sh --exclude .git
[10:32] <cjwatson> 23917
[10:32] <cjwatson> 304M    .
[10:32] <cjwatson> sabdfl: ^-- current-ish gutsy tree
[10:32] <Mithrandir> : tfheen@xoog ..inux-source-2.6.22-2.6.22 > find -type f | wc -l
[10:32] <Mithrandir> 22513
[10:32] <Mithrandir> not out of git, but the actual source package
[10:33] <fabbione> yeah 304MB confirmed here too :)
[10:33] <siretart> cjwatson: pitti: so whats the plan with ffmpeg/xine for now?
[10:33] <pitti> I'd rather wait with the promotion for the germinate fix TBH
[10:33] <siretart> xine-lib currently just dep-waits for the ffmpeg packages to be able to build
[10:34] <siretart> hm
[10:34] <pitti> siretart: depends on the ETA; I guess; dep-wait for a few days is fine, for a few weeks is not
[10:34] <rohan> crimsun: that is for the linus' git tree ? i can't find any commit no. "51d8d888cdc05e426af4cbb93d5c3aea9f6b7b01" there
[10:34] <crimsun> rohan: no, see ubuntu-feisty.git
[10:34] <pygi> rohan, gutsy tree
[10:35] <pygi> ah, feisty :p
[10:35] <rohan> ah, thanks crimsun
[10:35] <crimsun> rohan: http://preview.tinyurl.com/36y7rm
[10:37] <rohan> wow, beautiful .. libata driver was causing too many  Emask/Exceptions on my cdrom drive :)
[10:37] <cjwatson> siretart: I'm attempting the germinate work now
[10:38] <siretart> thanks!
[10:39] <rohan> and i know this was the wrong channel to ask in, so sorry
[10:39] <cjwatson>  Germinate/germinator.py |   31 +++++++++++++++++++++++++++++--
[10:39] <cjwatson>  man/germinate.1         |    6 ++++++
[10:39] <cjwatson> it's not looking too hard
[10:44] <sabdfl> thanks fabbione, cjwatson, that gives me a good estimate of bzr performance on that kind of tree
[10:44] <sabdfl> about 3s status with the the next release of bzr, i expect
[10:44] <fabbione> sabdfl: are you importing the history as well?
[10:45] <sabdfl> no, but i don't think status is affected by history size
[10:45] <sabdfl> commit, branch etc are
[10:45] <sabdfl> but the bzr guys just landed a nice couple of performance bumps
[10:45] <sabdfl> and have a pyrex version of some core routines which should take that time down to 2s
[10:46] <fabbione> i get about 2 secs on git status with cold cache and 0.7 secs on hot cache
[10:46] <sabdfl> which IMO is very impressive
[10:46] <sabdfl> my numbers are hot cache
[10:46] <fabbione> ok
[10:46] <sabdfl> i.e. regular use, hack hack hack status hack hack status commit
[10:46] <fabbione> yeps..
[10:46] <pitti> depends on whether you compare sabdfl's small laptop against fabbione's supa-powah toys, I guess
[10:46] <sabdfl> bzr commit is still slower than the others, but they have been optimising status and it's come out very impressively
[10:47] <fabbione> pitti: that's also true.. let me import a kernel tree in bzr on my machine
[10:47] <sabdfl> sigh. pitti. size is SO not important.
[10:47] <sabdfl> http://www.scienceblog.com/cms/men-worry-more-about-penile-size-women-13347.html
[10:47] <fabbione> ROFL
[10:48] <sabdfl> hard science, so to speak
[10:48] <fabbione> well i guess it's more due to the fact that a man is "stocked" with his penis.. women can change and decide...
[10:48] <crimsun> I haven't used bzr over this 56kbps dialup in some time.
[10:53] <Treenaks> I need to sit down and write that sourcepuller dump importer for bzr :)
[10:56] <fabbione> running constantly out of disk space and after 3 months you realize that you still have 80GB unused LVM space kind of sucks
[10:58] <shawarma> fabbione: Sucks to be you?
[10:58] <fabbione> shawarma: yes indeed
[10:59] <Kigh> it confused my X11 totally after i upgraded the kernel on 7.04 2 days ago. (terminal windows needed 10 seconds! to appear)
[10:59] <Kigh> resolution: replace <IP_ADDRESS> with <IP_ADDRESS>
[11:00] <fabbione> sabdfl: bzr status + hot cache + same machine as before takes about 3.5 secs
[11:00] <Keybuk> Kigh: it comes from Debian
[11:00] <fabbione> sabdfl: do you have a devel version of bzr with those optimizations?
[11:00] <Keybuk> Kigh: it's exploiting a kernel bug to seperate the IP of localhost from that of the machine name
[11:01] <Keybuk> Kigh: afaik all kernels should reply on any 127/8 address for lo
[11:01] <fabbione> hmm no
[11:01] <fabbione> 127/8 is a routable network
[11:01] <Kigh> Keybuk: i already thought that. but it lead to issues with X11.
[11:01] <Kigh> fabbione: its not.
[11:01] <Keybuk> fabbione: no, it's not
[11:01] <fabbione> ihih RFC says that you are not allowed to route it on the internet
[11:01] <Keybuk> the fact Linux replies to any packages sent *down* the lo network device, rather than *to* its address is a "bug"
[11:02] <Kigh> fabbione: well it is, but read the RFCs. one should never route 127/8
[11:02] <fabbione> it doesn't say you can't route it internally
[11:02] <Keybuk> or at least "an odd feature"
[11:02] <fabbione> Kigh: internet routing is not the same as local
[11:02] <fabbione> be careful there.. the difference is small
[11:02] <Keybuk> Kigh: I don't see why this would break
[11:02] <Keybuk> which kernel did you upgrade to?
[11:02] <Kigh> youre right fabbione
[11:02] <Kigh> mom
[11:02] <Keybuk> 2.6.22 still exhibits the "lo replies to any packet routed to it" feature
[11:03] <Kigh> "2.6.20-16-generic" per "apt-get upgrade"
[11:04] <Keybuk> can you nopaste the output of "ifconfig lo" somewhere
[11:04] <Kigh> after that update my gnome-desktop needed ~3mins do show up and i needed ~1 hour to locate and resolve that issue
[11:04] <Kigh> Keybuk: i can ping every 127/8 correctly on lo
[11:05] <Keybuk> ok
[11:05] <Keybuk> then I suspect the issue is unrelated
[11:05] <Keybuk> you should have in /etc/hosts:  <IP_ADDRESS> localhost
[11:05] <Keybuk> and <IP_ADDRESS> hostname
[11:05] <Keybuk> and *nothing* should be using "hostname"
[11:05] <Kigh> http://nopaste.biz/16619
[11:05] <Keybuk> (all local communication, including X, should be to "localhost" anyway)
[11:06] <Kigh> Keybuk: that was my /etc/hosts before i resolved the issue. now "localhost" and "hostname" do both point to <IP_ADDRESS> and voila: X11 reacts blazing fast.
[11:06] <Keybuk> http://lists.debian.org/debian-boot/2005/06/msg01047.html
[11:06] <Keybuk> hmm
[11:06] <Kigh> i didnt change anything, all DIST
[11:06] <Keybuk> that sounds like things in X are trying to use your hostname
[11:06] <Keybuk> that's a bug
[11:06] <Mithrandir> Kigh: what is DISPLAY set to?
[11:06] <Keybuk> in the long term, there won't even be an entry in /etc/hosts for your hostname
[11:07] <Kigh> declare -x DISPLAY=":0.0"
[11:08] <Kigh> Keybuk: i know. i didnt have a hostname entry on my archlinux or slackware before i switched to comfortable ubuntu
[11:08] <Keybuk> Kigh: since this configuration works for everybody else, we need to understand what's different about your machine to understand why it breaks for you
[11:09] <Kigh> if i only knew that :)
[11:09] <Kigh> i didnt change any config manually, except etc/hosts to resolve this X11-issue
[11:09] <Kigh> everything is installed via apt-get
[11:09] <Kigh> no self-compiled apps
[11:10] <Kigh> any guess what could be different?
[11:13] <Kigh> i have a lot of interfaces, but this should not affect "lo"
[11:13] <Keybuk> no idea, sorry
[11:14] <Kigh> k. if nobody else had this issue, then its not important. i know how to resolve it for myself
[11:14] <Kigh> but for what reasons should "hostname" never be an alias of "localhost"? (<IP_ADDRESS>)
[11:15] <Kigh> it works just fine
[11:15] <Keybuk> Kigh: http://lists.debian.org/debian-boot/2005/06/msg00938.html
[11:16] <asac> pitti: edgy and feisty should be building now ... do you need the version that will fix things in gutsy?
[11:17] <Kigh> Keybuk: this does not explain why <IP_ADDRESS> should not be used. he just suggests hostname should point to <IP_ADDRESS> (for no specific reason)
[11:17] <asac> pitti: for gutsy its <IP_ADDRESS>+2-0ubuntu1
[11:17] <pitti> asac: no, we don't do that for Ubuntu USNs
[11:17] <pitti> asac: but thanks anyway
[11:17] <asac> pitti: ah ok
[11:17] <asac> pitti:  i will test things till lunch ... if you haven't heard a thing you can push
[11:18] <Kigh> Keybuk: mh okay, i better think about "reverse dns" :-)
[11:21] <sabdfl> fabbione: bzr branch lp://bzr
[11:21] <sabdfl> or maybe http://launchpad.net/bzr
[11:21] <sabdfl> i.e. bzr branch that url
[11:22] <fabbione> got it
[11:22] <fabbione> bzr branch lp:///bzr foo
[11:22] <fabbione> it's 3 ///
[11:41] <ion_> gcc has been compiling a single C++ file for 8 hours or so. It has been able to use 27 CPU minutes; the rest has been spent waiting for IO, namely swapping. :-D
[11:43] <dholbach> holy cow
[11:43] <mrsn0> :I what are you compiling ion_ ? gentoo?
[11:43] <ion_> cimg-dev
[11:44] <ion_> inrcast.cpp in it.
[12:12] <asac> pitti: builds went fine? if you haven't pushed yet, please wait a bit ... have to verify something for feisty.
[12:13] <pitti> asac: edgy built fine
[12:13] <pitti> asac: still waiting for feisty anyway
[12:26] <asac> pitti: ok ... feisty should be fine too
[12:29] <ogra> Keybuk, i see constant ewarnings from udev-event: rename_netif trying to rename my eth0 on a thin client, is there a way to tell udev to not try to rename it ?
[12:30] <Keybuk> release?
[12:30] <ogra> gutsy
[12:30] <ogra> fresh installed
[12:30] <ogra> (the chroot)
[12:42] <Keybuk> what are the warnings?
[12:43] <ogra> that its in use and cant be renamed
[12:43] <ogra> which is indeed true on an nfsroot :)
[12:43] <ogra> its not doing any harm either, but its ugly
[12:43] <Keybuk> oh, hmm
[12:43] <Keybuk> interesting ;)
[12:44] <Keybuk> I wonder why it's trying to rename it though
[12:44] <Keybuk> it should have the same name
[12:44] <Keybuk> what's it trying to rename it to/
[12:44] <ogra> hmm, wait, the chroot is built on another machine indeed
[12:44] <ogra> eth2
[12:44] <Keybuk> aha!
[12:44] <Keybuk> yeah, that's the same postinst bug that fabbione had
[12:44] <Keybuk> there's a temporary hack in postinst that seeds the file, which won't be in the final release
[12:45] <ogra> ah, ok
[12:45] <ogra> as i said, it does no harm, just cosmetical stuff ... as long as udev behaves i'm fine
[12:46] <ogra> Keybuk, another thing i stumbled across is that udevsettle doesnt seem to do anything if you use it in initramfs
[12:47] <ogra> i was trying to fix the persistent lvecd mode and make it wait until the device is there, but it sems to be ignored .... checking other scripts it seemed to be the same
[12:48] <Keybuk> what are you expecting udevsettle to do?
[12:48] <Keybuk> tip:
[12:48] <Keybuk> never, ever, run udevsettle
[12:48] <ogra> i didnt dig deeper since i worked around the initial problem by adding the same loop as the other / mounting modes have, so it jus retries until the / device is there
[12:49] <Keybuk> udevsettle is not the binary you are looking for
[12:49] <ogra> Keybuk, well, its run in several scripts in initramfs and as i understood its the commad to run to make sure udevtrigger is done
[12:49] <Keybuk> right
[12:49] <Keybuk> what do you think that means?
[12:49] <ogra> which apparently doesnt work in initramfs
[12:49] <Keybuk> no
[12:49] <Keybuk> I suspect you just don't know what you're doing
[12:49] <ogra> since i see udev still working while the script moves on
[12:49] <ogra> (udevtrigger i mean, sorry)
[12:49] <Keybuk> you never need to run either command
[12:50] <Keybuk> if you're running them, then you're attempting to do something wrong
[12:50] <ogra> why is it run then ?
[12:50] <Keybuk> it's run once by the udev initramfs script
[12:50] <Keybuk> it needs to be run no other times
[12:50] <ogra> right
[12:50] <Keybuk> and you'll notice that udevsettle is never run
[12:51] <Keybuk> so
[12:51] <ogra> ah, well its run in the nfs-top udev script ....
[12:51] <shawarma> Really? How does that work, then? Are the events just queued until udev starts to listen?
[12:51] <Keybuk> what do you want to happen?
[12:52] <Keybuk> ogra: there should be no nfs-top udev script
[12:52] <ogra> # We need to wait for the network card drivers to be loaded
[12:52] <ogra> /sbin/udevsettle
[12:52] <Keybuk> there should only be an init-premount and init-bottom script
[12:52] <ogra> from usr/share/initramfs-tools/scripts/nfs-top/udev
[12:52] <Keybuk> ogra: what package supplies that script?
[12:52] <ogra> for the nic drivers it seems
[12:52] <ogra> root@laptop:/# dpkg -S usr/share/initramfs-tools/scripts/nfs-top/udev
[12:52] <ogra> udev: /usr/share/initramfs-tools/scripts/nfs-top/udev
[12:53] <Keybuk> oh, hmm
[12:53] <Keybuk> that's probably my bad then
[12:53] <Keybuk> it doesn't really help you
[12:53] <ogra> well, but thats not the one i had the prob with
[12:53] <Keybuk> all udevsettle does is ensure that the udevd daemon is "up to date" with kernel uevents
[12:53] <ogra> but i saw the comment and thought i could use udevsettle
[12:53] <Keybuk> udevtrigger causes missed uevents to be resent
[12:53] <ogra> in my classmate initramfs script ...
[12:53] <Keybuk> thus bringing udevd up to date
[12:53] <Keybuk> after that, udevd will receive them from the kernel directly, so there's no need for either binary to be run
[12:54] <ogra> ah, s if i would run udevtrigger a second time it would just do a noop
[12:54] <Keybuk> the reason that udevsettle doesn't work for the network driver case, is that it only ensures that udev has reacted to the existance of the pci device (since that's all that will exist in sysfs before modules are loaded)
[12:54] <Keybuk> the reaction to the pci device is to load a module
[12:54] <ogra> err, it works for the network driver case
[12:54] <Keybuk> there is an indeterminate amount of time between "udev has reacted and loaded a module" and the network interface actually being useful
[12:55] <Keybuk> (or even existing)
[12:55] <Keybuk> it may happen to occur quicker than it takes the initramfs to get to the command that uses the network
[12:55] <Keybuk> but it's still a race condition
[12:55] <ogra> it didnt for the persistent mode from casper (which m classmate script is based on) since the usb disk wasnt there whne it tried to mount /
[12:55] <Keybuk> exactly
[12:55] <ogra> adding a loop around the / mounting function solved it
[12:56] <ogra> but thats indeed not the proper fix
[12:56] <Keybuk> udev will react to the existance of the pci device representing the usb hub
[12:56] <Keybuk> that does not guarantee the usefulness of any usb device somewhere down the device tree
[12:56] <ogra> the usb hub is very slow
[12:56] <ogra> ah
[12:56] <ogra> so the loop is the only option then ...
[12:56] <ogra> uless i fix the HW
[12:57] <ogra> *unless
[12:57] <Keybuk> the time between "udev being up to date with the kernel (it's seen that there is a usb hub)" and devices somewhere in the usb tree having been probed, negotiated for power requirements/speed/etc., kernel knowledge created, udev being aware of the existance of those devices, modules being loaded, modules initialising the device, device responding, udev creating /dev nodes as appropriate
[12:57] <Keybuk> is longer than the (simpler) network card case
[12:57] <Keybuk> they're both race conditions
[12:57] <ogra> indeed
[12:57] <Keybuk> the USB one is a race with an american who likes to eat at McDonalds every day
[12:58] <ogra> it also has to load the filesystem and usb storage stuff
[12:58] <ogra> haha
[12:58] <Keybuk> right
[12:58] <Keybuk> there are two common solutions
[12:58] <Keybuk>  1) loop until what you expect to exist/work does exist and work
[12:58] <ogra> right, thats what we seem to do anyway in all other scripts, just not in casper
[12:58] <Keybuk>     - we use this in the initramfs local mountroot(), we loop until the $ROOT device exists and vol_id works on it
[12:59] <Keybuk>  2) react to the events telling you that it does work
[12:59] <Keybuk>     - we're gradually moving to this where we can (e.g. devmapper, LVM, etc.)
[01:00] <Keybuk> (2) is clearly better, but also harder than (1)
[01:00] <ogra> yeah
[01:00] <ogra> well, as long as 1) is used everywhere i'm not much concerned even though i dont really like it ...
[01:00] <Keybuk> all this talk about udev and events has made ian explode
[01:01] <ogra> heh
[01:01] <Keybuk> actually, there is a 3) I should talk about for fairness
[01:02] <Keybuk>  3) do everything in a predictable order, and don't move on to the next step until you know the previous step is finished
[01:02] <Keybuk>     - we don't like this because it's slow, and introduces "points of no return" (if you don't plug your USB key in by now, it won't be used)
[01:04] <ogra> upstart philosophy :)
[01:04] <cjwatson> Keybuk: (would you mind fixing casper to do this right for persistent USB sticks? :-))
[01:04] <ogra> cjwatson, i have the loop fix here if we dont come up with aything better
[01:04] <Mithrandir> cjwatson: that'd be sweet.
[01:04] <cjwatson> I tried udevtrigger/udevsettle, but I now understand why that didn't work
[01:05] <ogra> (works fine and saved my ass on the classmate image)
[01:06] <Keybuk> cjwatson: as I understand it, the cow problem is that in order for the root filesystem to be set up, the cow has to be configured first
[01:06] <cjwatson> yes
[01:06] <Keybuk> e.g. if you find the cow, you need to build the root filesystem with it in
[01:07] <ogra> you do an unionfs mount
[01:07] <Keybuk> you can't be halfway through booting, discover the cow, and modify the root filesystem so it's now writable to that instead of ram
[01:07] <cjwatson> fortunately there is a boot argument to say "please go and look for a cow"
[01:07] <Keybuk> right
[01:07] <cjwatson> it's not just done on-spec
[01:07] <cjwatson> so a loop would be workable
[01:07] <Keybuk> you can't say "if I have a cow, don't use the ram"
[01:08] <ogra> i'll add that then
[01:08] <Keybuk> you can say "I have a cow, don't use the ram"
[01:08] <Keybuk> and wait for the cow
[01:08] <cjwatson> casper --animal-farm
[01:08] <Keybuk> (because the question "Where's my cow?" takes a while to answer ...
[01:09] <Keybuk>  "That's not my cow!  It goes NRRRRGH!  That is a hippopotamus!"
[01:09] <thom> it worries me that keybuk had that pterry quote quite so close to hand ;-)
[01:10] <elkbuntu> Mithrandir, just tell them to apt get their own ;)
[01:10] <Keybuk> thom: I'm not sure it's an accurate quote; but it's certainly correct in gist
[01:10] <Mithrandir> Keybuk: can we have a point of no return where we look for cow devices and if none are found, continue as usual?
[01:10] <Keybuk> Mithrandir: arguably that's the point where we reach init-premount; which doesn't take very long at all
[01:11] <Keybuk> certainly takes a lot less time than starting the few things in between
[01:11] <Keybuk> we could add a 10s delay, but that penalises cow-less people
[01:11] <Mithrandir> yes, which is bad.
[01:11] <Mithrandir> but we could do it after the cdrom has been mounted, since that always takes time.
[01:12] <Keybuk>  "That's not my cow!  It goes 'Buggrit, Millennium, Hand and Shrimp!  That is Foul Ol' Ron!"
[01:12] <Keybuk> how long does an integrity check take? :p
[01:13] <Mithrandir> too long
[01:13] <Keybuk> bah
[01:13] <Mithrandir> say you get around 5MB/sec from your drive, so around two minutes.
[01:33] <shawarma> There's not another Dapper point release planned, is there?
[01:36] <cjwatson> shawarma: it's possible
[01:36] <cjwatson> but no explicit plan at the moment
[01:37] <shawarma> cjwatson: Ok. I've got an issue that pertains to the installation, so it doesn't make much sense to put any effort into it unless such a release is planned, so it's not really a candidate for an SRU.
[01:38] <shawarma> It's about a commonly used raid driver missing from the standard initramfs.
[01:38] <shawarma> Not sure what to do about it..
[01:40] <StevenK> cjwatson: gutsy_probs.html only covers main, right? ultrastar-ng has been demoted to universe, and yet still appears in it.
[01:42] <cjwatson> right - I've tried running it on universe and it takes way too long to contemplate
[01:42] <cjwatson> ultrastar-ng |    0.1.4-1 |         gutsy | all
[01:42] <cjwatson> ultrastar-ng |    0.1.4-1 | gutsy/universe | source
[01:43] <cjwatson> apparently only the source was demoted
[01:43] <StevenK> Ahh.
[01:43] <cjwatson> btw, 'rmadison -u ubuntu ultrastar-ng' works if you have ultra-current devscripts
[01:43] <cjwatson> the archive it uses is only updated every six hours, so may sometimes be a bit behind
[01:45] <pitti> Hobbsee: welcome to -core-dev, and congratulations! well-earned
[01:45] <Hobbsee> pitti: thankyou :)
[01:45] <Hobbsee> oh wait, i'm not supposed to say that!
[01:45] <thom> Hobbsee: congrats!
[01:46] <Hobbsee> thom: thankyou :(
[01:46] <Hobbsee> * :)
[01:46] <ajmitch> well done :)
[01:47] <ajmitch> yay, 3-day weekend
[01:47] <StevenK> For me too, sort of.
[01:47] <StevenK> And then a 4 day weekend
[01:47] <ajmitch> public holiday?
[01:47] <StevenK> I have uni presentation on Monday, so I have the day off $WORK.
[01:48] <StevenK> Friday is my birthday, so I'm also taking it off.
[01:48] <ajmitch> lucky, I think
[01:48] <ajmitch> hah
[01:48] <StevenK> The following Monday is a public holiday.
[01:52] <StevenK> Oooh, I wonder if tc could be anymore esoteric to use.
[01:53] <StevenK> # tc qdisc del dev eth0 pfifo_fast
[01:53] <StevenK> Segmentation fault
[01:53] <StevenK> Yeah, it could.
[01:53] <Keybuk> Hobbsee: there's a reason that the LP emblem for core-dev is a hammer <g>
[01:54] <Hobbsee> Keybuk: hahahha, i havent looked yet
[01:54] <pitti> BenC: do we still need the 2.6.20 kernel in gutsy?
[01:54] <StevenK> Keybuk: HAh
[01:55] <Keybuk> (it's amazing how many people have never noticed that; it's always been a hammer since the day emblems were rolled out back at UBZ)
[01:55] <StevenK> Keybuk: Is that the same reason the emblem for ubuntu-dev looks a little like a target?
[01:55] <Keybuk> StevenK: that was supposed to be the MOTU logo from He-Man
[01:56] <StevenK> Oh geez. Well, considering I last watched He-Man when I was like 8 ... :-P
[01:57] <Keybuk> we still haven't found a He-Man costume for dholbach
[01:58] <Hobbsee> awww
[01:59] <StevenK> Not so much a costume, more like conviently placed articles of clothing and armour
[02:01] <Keybuk> http://www.costumania.net/galleries/costumes/heman/big/heman01.jpg
[02:01] <Keybuk> lol
[02:02] <Keybuk> I see your point
[02:03] <ajmitch> that's worrying
[02:03] <fabbione> ahhaha
[02:03] <cjwatson> my eyes
[02:03] <Fujitsu> Eeeergh.
[02:03] <fabbione> now.. gimp dholbach face in there
[02:03] <Fujitsu> It burns.
[02:03] <fabbione> and you are done
[02:03] <Fujitsu> fabbione: Hahahah.
[02:03] <cjwatson> siretart: so I'm looking at blacklisting libavcodec0d and libavcodec-dev, yes?
[02:04] <cjwatson> actually, a regex would even work - awesome
[02:04] <Hobbsee> Keybuk: now, i know you'd love to dress in that kind of stuff...but you really shouldnt.
[02:05] <Hobbsee> Keybuk: making dholbach wear it isnt going to make you feel like you're any closer to wearing it...
[02:05] <Keybuk> Hobbsee: there are, sadly, far worse pictures of me
[02:05] <Hobbsee> :P
[02:05] <Hobbsee> Keybuk: pictures are evil
[02:05] <Hobbsee> Keybuk: surely you've seen the ones of me at UDS - makes me look like i'm on drugs.
[02:05] <Fujitsu> Hobbsee: These I must see.
[02:06] <BenC> pitti: No, it can go away
[02:06] <Keybuk> though if there was an Ubuntu Fancy Dress Party, I know exactly what costume I'd make :p
[02:06] <Hobbsee> Fujitsu: haha.  nope
[02:06] <Hobbsee> if there was an Ubuntu Fancy Dress Party, i wouldnt come.
[02:06] <Hobbsee> although maybe that's something for the last night, too.
[02:06] <Mithrandir> Keybuk: we should have one for next UDS.. or allhands. :-O
[02:06] <ajmitch> how disturbing
[02:06] <fabbione> Keybuk: we do NOT want to know
[02:07] <fabbione> there is a need to know... and a wish to know
[02:07] <Hobbsee> pictures must be provided
[02:07] <Keybuk> fabbione: I'd come as my Launchpad picture <g>  which is somewhat easier for me, admittedly, than some people <g>
[02:07] <Hobbsee> yes, all hands sounds good
[02:07] <fabbione> Keybuk: ehehe
[02:08] <Mithrandir> Keybuk: wouldn't be that hard for me either.  I'd need to buy a blue jacket and darken my face a bit.
[02:08] <StevenK> Keybuk: And how would you look that pixelated?
[02:08] <Keybuk> Mithrandir: don't forget the yellow biro
[02:09] <Keybuk> StevenK: I'd have to start drinking again
[02:09] <StevenK> Hah
[02:09] <Treenaks> Keybuk: Look! Behind you! A three-headed monkey!
[02:09] <Keybuk> Treenaks: How appropriate, you fight like a cow!
[02:09] <mjg59> a
[02:09] <BenC> pitti: did you reject 2.6.22-6.13?
[02:09] <mjg59> Oops
[02:09] <pitti> BenC: yes, I mailed you about it, due to the i386 ftbfs
[02:10] <BenC> pitti: did you notice i386 ftbfs was caused by ghostscript failure to install for build-deps?
[02:10] <BenC> No alternatives for gs.
[02:10] <BenC> dpkg: error processing /home/buildd/build-342472-782743/chroot-autobuild/var/cache/apt/archives/ghostscript_8.60.dfsg.2-0ubuntu1_i386.deb (--unpack):
[02:10] <BenC>  subprocess pre-installation script returned error exit status 1
[02:11] <pitti> BenC: oh, oops :) so, let me unreject them
[02:11] <BenC> thanks :)
[02:11] <Mithrandir> pitti: unreject = accept, you know that?
[02:11] <pitti> Mithrandir: yep
[02:11] <cjwatson> <cjwatson@cairhien ~/src/ubuntu/seeds/gutsy>$ bzr commit -m 'blacklist libavcodec* from CDs (syntax from germinate 0.27)'
[02:11] <pitti> Mithrandir: I didn't plan to do it now, just mentioning that we don't need another kernel upload
[02:12] <cjwatson> drescher's germinate will whine, but shouldn't crash or do anything harmful
[02:12] <cjwatson> lithium's germinate is up to date
[02:12] <cjwatson> with any luck that should do it for ffmpeg
[02:20] <pitti> BenC: I uploaded a fixed ghostscript which should install again
[02:21] <pitti> BenC: after it's in the archive, we can give-back the kernel on i386
[02:21] <StevenK> pitti: The question is, have another failed to build like the kernel did?
[02:22] <pitti> StevenK: sorry, parse error
[02:22] <StevenK> Yes, sorry, my brain skipped ahead.
[02:22] <StevenK> pitti: The question is, have other packages failed to build like the kernel did?
[02:23] <pitti> StevenK: entirely possible, I didn't check
[02:23] <pitti> cjwatson: great
[02:24] <pitti> cjwatson, siretart: does that mean it is possible to promote the ffmpeg libs?
[02:26] <pitti> doko: can you please fix python2.{4,5} to build against libbluetooth-dev instead of libbluetooth2-dev?
[02:30] <cjwatson> pitti: that's the intention, though I haven't checked the patent comments
[02:31] <pitti> cjwatson: we discussed these with elmo at UDS; the primary issue was to make *damn* sure that those will never land on CDs, but in main they are fine
[02:37] <siretart> cjwatson: right, libavcodec* is the evil bit
[02:37] <pitti> Hobbsee, Riddell: digikam, digikamimageplugins, and gwenview need to be rebuilt against a newer libexiv;libexiv2-0.12 is not built any more; who can I bother about that?
[02:38] <Hobbsee> pitti: i could be persuaded
[02:38] <pitti> (and some universe packages as well)
[02:38] <Hobbsee> better test the shiny upload powers out
[02:38] <robertj> is there any sort of general advice you give to one who has a depatch that won't reverse? gnome-system-utils build clean the first time only
[02:39] <Hobbsee> pitti: er, according to my apt-cache, libexiv2-0.12 still exists.
[02:39] <seb128> robertj: fix the bug? ;)
[02:39] <seb128> robertj: or rm the dir and unpack the source again
[02:39] <robertj> seb128: well I was hoping to take a stab and poking somethingin the src
[02:40] <Hobbsee> pitti: presumably it's supposed to be built against libkexiv2-1 (well, the required dev package)
[02:40] <robertj> is there a way to get more info as to why it wouldn't apply?
[02:40] <pitti> Hobbsee: it does, but it is NBS
[02:40] <pitti> Hobbsee: i. e. it's about to be removed
[02:40] <Hobbsee> NBS?
[02:40] <seb128> robertj: it's likely an autotools patch changing config.guess,sub or something similar
[02:41] <robertj> yeah, it was an autotools patch, don't remember what it was patching though
[02:41] <StevenK> Hobbsee: Not Built from Source
[02:42] <Hobbsee> ahhh
[02:42] <StevenK> Hobbsee: I merged exiv2, the -dev package name didn't change.
[02:42] <Hobbsee> ahhh
[02:43] <pitti> Hobbsee: 'Not Build from Source' anymore
[02:44] <Hobbsee> gotcha
[02:45] <cjwatson> pitti: right, the germinate and seed changes I made ensure that germinate will now refuse to include them anywhere logically inside the ship, ship-live, or server-ship seeds
[02:45] <cjwatson> whether they're explicitly seeded or pulled in by dependencies or build-dependencies
[02:45] <pitti> awesome
[02:46] <cjwatson> it is possible that uninstallable packages on CDs may result from this
[02:46] <cjwatson> it doesn't go back up the tree when it hits a blacklist entry
[02:47] <Riddell> pitti: Lure knows all about those
[02:48] <Lure> pitti: right, SteveK said he will upload -build packages for all rdepends of exiv2
[02:48] <siretart> Tonio_: can you have a look at pitti's latest ghostscript upload to gutsy?, looks like that's what we need for xine-lib's backport in feisty!
[02:48] <Lure> pitti: I have seen one upload only though
[02:48] <pygi> Hobbsee, congrats ;)
[02:48] <Hobbsee> thanks pygi :)
[02:49] <pygi> knew you can do it^_^
[02:49] <pygi> and you deserve it ;)
[02:49] <Hobbsee> :)
[02:49] <Riddell> Hobbsee: I think digikamimageplugins doesn't exist any more
[02:49] <Tonio_> siretart: will have a look
[02:49] <Hobbsee> Riddell: it hasnt been removed from the archive yet, at least.
[02:49] <Lure> Riddell: correct - when digikam 0.9.2-beta2 builds, we can remove imageplugins
[02:49] <Hobbsee> oh neat
[02:50] <Tonio_> siretart: what about backport ? it also ftbfs on gutsy.... did I missunderstand you ?
[02:50] <Lure> Riddell: but digikam is waiting for libkdcraw promotion to main
[02:51] <Lure> pitti: ^^^ just a reminder
[02:52] <StevenK> Hobbsee: gwenview uploaded
[02:52] <Hobbsee> cool
[02:52] <Riddell> Lure: since it shouldn't need a main inclusion report we can probably ask any archive admin just to promote it
[02:53] <Hobbsee> Riddell: which is you, right?
[02:53] <Riddell> Hobbsee: not yet
[02:53] <Hobbsee> oh
[02:53] <Hobbsee> i thought they gave you power
[02:53] <Lure> Riddell: pitti said he will just do a quick check (it is library now, before it was part of core digikam)
[02:54] <Riddell> Hobbsee: needs sysadmins to do their thing
[02:54] <Hobbsee> blerg.
[02:54] <Riddell> Lure: right
[02:54] <Hobbsee> Riddell: surely the entire world is covered by launchpad now
[02:54] <Riddell> archive admin is mostly command line stuff
[02:55] <siretart> Tonio_: didn't you send me a buildlog of xine-lib in feisty?
[02:55] <Hobbsee> as in, that launchpad would now give you access to the archive admin stuff, being part fo the team
[02:56] <pitti> Lure: promoted
[02:56] <Lure> pitti: thanks!
[02:56] <StevenK> I expect it's a case of they don't want LP to run adduser and edit sudoers when someone joins/leaves the -archive team.
[02:56] <Lure> pitti: for digikamimageplugins removal, I just open bug and subscribe archive-admin, right?
[02:57] <seb128> Lure: correct
[02:57] <seb128> ubuntu-archive
[02:57] <Lure> seb128: thanks, will do when new digikam get in the archives
[02:57] <pitti> Lure: yep
[02:58] <pitti> Lure: can we get rid of dcraw with that? otherwise we'd have duplicate source code
[02:58] <Tonio_> siretart: no that was for gutsy
[02:58] <Lure> pitti: not really, as some other SW depends on it
[02:59] <Lure> pitti: I agree it is bad, but dcraw in libkdcraw was introduced due to constant breakages of dcraw command line interface
[02:59] <siretart> Tonio_: oh, then it seems that pitti fixed the problem :)
[02:59] <Lure> pitti: good thing is that most kde sw is moving to libkdcraw
[03:00] <pitti> Lure: then dcraw shuold use that new library
[03:00] <Lure> pitti: but we might want to reconsider this if license issue is not resolved with new dcraw
[03:01] <Tonio_> siretart: hehe perfect :)
[03:01] <Lure> pitti: latest releases of libkdcraw did not pass debian license check, ie. is non-free
[03:01] <Lure> pitti: new library (libkdcraw) is just a wrapper around "known-to-work-well" dcraw
[03:02] <Lure> pitti: and it is c++, so I doubt gtk/gnome photo programs will be thrilled
[03:04] <elmo> I'm repeatedly seeing netboot installs running an fsck on fresh installs that require a reboot (fsck is 49170 days old) - known bug?
[03:05] <ogra> elmo, TZ rpoblem
[03:05] <ogra> *problem
[03:05] <StevenK> Neat how it labels the filesystem as being created in 1872.
[03:05] <elmo> ogra: err?
[03:05] <elmo> ogra: what timezone accounts for a shift of 135 years?
[03:06] <ogra> the installer is switching the timezone after you partitioned or something, i forgot the precise error
[03:06] <pitti> asac: can I ask you to rebuild cman against the new libnspr4?
[03:06] <ogra> we dug into that in feisty
[03:06] <asac> pitti: sure ... let me see
[03:06] <ogra> there is no easy fix
[03:06] <StevenK> elmo: -1180080, obviously. :-P
[03:07] <mjg59> elmo: I suspect that the time has been set to the future, but fsck always interpretes it as being in the past
[03:07] <ogra> elmo, mvo had a bug about it we worked on for this
[03:07] <ogra> not sure i can find it
[03:07] <pitti> asac: cool; then I can remove libnspr4 and libnss3 & friends, since they are NBS
[03:08] <StevenK> pitti: I can point out other NBSes if you wish.
[03:08] <asac> pitti: its already rebuild
[03:08] <asac> pitti: i have just to drop the manual depends
[03:08] <asac> pitti: doing so now
[03:09] <asac> pitti: e.g. currently depends on libnspr4-0d and libnspr4 :=
[03:09] <ion_> Is gimp-plugin-registry going to be synced from debian to gutsy automatically, or should i request a sync?
[03:09] <ogra> elmo, its related to the order of asking about UTC, partitoning and actually setting the timezone
[03:10] <pitti> StevenK: I have all of them in vi now and wade through the easy ones
[03:10] <StevenK> pitti: Fairy 'nuff. Hopefully, it'll stop britney complaining so much.
[03:11] <mjg59> We could just fix fsck to assume that insane dates shouldn't be checked
[03:11] <StevenK> ion_: It should be done semi-automatically.
[03:12] <ogra> elmo, bug 63175 and bug 43239
[03:12] <ubotu> Launchpad bug 63175 in e2fsprogs "Edgy Beta -- fsck on every (re)boot" [Medium,Needs info]  https://launchpad.net/bugs/63175
[03:12] <ubotu> Launchpad bug 43239 in e2fsprogs "fsck should check against a timestamp "49710 days" old" [Medium,Confirmed]  https://launchpad.net/bugs/43239
[03:13] <ogra> we should just blindly dump th eright value in tune2fs
[03:13] <ogra> since we know we just formated in the installer
[03:14] <StevenK> ogra: I just read the manual page, it's a simple matter (for ext3, at least) of tune2fs -T now <fs>
[03:15] <ogra> right
[03:15] <ogra> thats what i mean
[03:15] <ogra> and we know the fs is clean (at least if we are in the installer)
[03:16] <StevenK> The other problem might be we can't do that while the filesystem is mounted.
[03:16] <pitti> asac: erk, I just noticed that firefox does not build mozilla-firefox any more; we need that transitional package until the next LTS
[03:16] <ogra> well, its still /target so we can unmount it
[03:16] <ogra> its not that we are chrooted into it or something
[03:17] <ogra> so the cleanup step that also does the unmounting shold just get tihis line of code
[03:17] <asac> pitti: it has been discussed with mvo
[03:18] <StevenK> ogra: It's a little more than one line.
[03:19] <ogra> why ? we should have the device name from the unmounting code
[03:19] <ogra> what else do you need than putting tune2fs -T now ${DEVICE} behind the umount ?
[03:19] <StevenK> Firstly, because there might be more than one filesystem to run it across, and secondly, because there might be other filesystems being used in the new install, such as xfs.
[03:20] <ogra> hmm, righ
[03:20] <ogra> t
[03:20] <StevenK> I don't want to try tune2fs against a xfs partition. :-)
[03:21] <cjwatson> furthermore d-i doesn't actually set the UTC value itself - it just dumps it into /target so that it's correct at first boot
[03:24] <ogra> ah
[03:24] <ogra> set a firstboot flag we delete and make fsck respect that ?
[03:25] <StevenK> Actually, I'd be curious if this affected all filesystems or just ext[23]
[03:25] <ogra> i ddint test with anything else back then
[03:31] <StevenK> What do you mean, the CD has music and data on it. There is no CD!
[03:36] <pitti> StevenK: it means the one on the kitchen shelf
[03:38] <StevenK> There isn't one there either, so nyah.
[03:38] <pitti> asac: if you allude to 'the dist-upgrader will handle it': why should we deliberately break apt-get upgrades if it's so cheap to keep them working?
[03:39] <StevenK> I'm curious how to get the CD off my desktop, though. I can't eject it, there's no CD to eject.
[03:42] <ogra> prssed the button on the cD drive ?
[03:42] <ogra> afaik we dont lock it anymore (or was that reintroduced)
[03:43] <asac> pitti: i can't remember for sure, but I think its because one step dist-upgrade from dapper to gutsy+1 will break anyway ... so we don't break anything by breaking apt-get upgrades for firefox
[03:44] <StevenK> ogra: I've opened it twice, just to check I'm not going crazy.
[03:44] <asac> pitti: but i open a bug to keep track of the discussion now
[03:47] <asac> pitti: subscribed you (and mvo) to bug 118247
[03:47] <ubotu> Launchpad bug 118247 in firefox "reenable mozilla-firefox* transitional packages in gutsy" [Undecided,Needs info]  https://launchpad.net/bugs/118247
[03:47] <pitti> asac: thanks
[03:58] <iwj> If I'm editing the seeds to add something (sl-modem-daemon, from restricted) to ship and ship-live, do I need to edit the seeds for kubuntu and xubuntu and edubuntu separately ?
[03:59] <ogra> iwj, we'Re usually supposed to care for merging ourselves, but its indeed appreciated if someone else does the work :)
[03:59] <cjwatson> no, just edit the Ubuntu seeds and then either (a) bzr merge into each of the other branches or (b) let the release team or the {K,Ed,X}ubuntu lead merge it for you later
[04:00] <cjwatson> don't commit four independent identical changes, though
[04:00] <iwj> Right.
[04:00] <ogra> right, the ubuntu seeds are the master branch
[04:03] <iwj> I've done a bzr merge and there are other changes - should I just commit my merge results or leave it ?
[04:05] <iwj> As in, just commit the results of   for foo in k x ed; do (set -e; cd ${foo}ubuntu.gutsy; bzr merge ../ubuntu.gutsy); done
[04:07] <cjwatson> if it looks sensible ...
[04:07] <cjwatson> 'bzr status' should show the merges since the last time anyone merged into each
[04:08] <cjwatson> should be a small number
[04:12] <ogra> also dont wrooy to much about it for now, i'm pretty sure every tec lead will touch and sort his seeds before tribe 1
[04:12] <ogra> *worry
[04:12] <ogra> so we can clean up what we dont like
[04:14] <iwj> It looks good to me so I'm committing it now.
[04:14] <iwj> for foo in k x ed; do (set -e; cd ${foo}ubuntu.gutsy; bzr ci -m 'merge from ubuntu.gutsy'); done
[04:14] <iwj> :-)
[04:14] <iwj> This should be automated in a less ad-hoc way perhaps ...
[04:15] <ogra> good point
[04:16] <iwj> Aha!  I've found the power brick for this winmodem test laptop; it was in the living room's box of `cables and junk (misc)'.
[04:19] <pitti> siretart: ffmpeg libs promoted
[04:20] <siretart> pitti: cool, thanks. can you please give back xine-libs on all archs now?
[04:21] <pitti> siretart: no, we need Mithrandir's powers for that
[04:21] <siretart> ah, ok
[04:21] <siretart> Mithrandir: could you please give bach xine-lib on all archs?
[04:21] <pitti> if you do it now, it should go to dep-wait, since the main promotion will not actually happen until the next publisher run
[04:22] <siretart> ah, i see
[04:25] <elmo> Unpacking ghostscript (from .../ghostscript_8.60.dfsg.2-0ubuntu1_amd64.deb) ...
[04:25] <elmo> No alternatives for gs.
[04:25] <elmo> dpkg: error processing /var/cache/apt/archives/ghostscript_8.60.dfsg.2-0ubuntu1_amd64.deb (--unpack):
[04:25] <seb128> elmo: you want  ghostscript (8.60.dfsg.2-0ubuntu2) gutsy; urgency=low
[04:25] <pitti> elmo: I fixed that about an hour ago
[04:26] <seb128> elmo: pitti uploaded it 2 hours ago
[04:26] <pitti> still NEEDSBUILD, though
[04:26] <elmo> meh, ok
[04:30] <Mithrandir> siretart: somebody already did
[04:30] <Mithrandir> siretart: apart from i386 where it claims chroot problem
[04:32] <pitti> Riddell: someone put strigiapplet into the kubuntu seeds, but the package is in universe
[04:34] <pitti> Riddell: ah, it's a recommends, so it's not uninstallable
[04:38] <cjwatson> it wouldn't be uninstallable anyway
[04:39] <cjwatson> update-metapackage won't add it to -meta binaries' Depends unless it's in main/restricted
[04:39] <siretart> Mithrandir: oh, thanks anyway
[04:46] <iwj> Ug, this CD drive is sooo slooooow.
[04:47] <cjwatson> s/this CD drive is/CD drives are/
[04:56] <ogra> bryce, displayconfig-gtk doesnt work without existing xorg.conf ?
[05:04] <iwj> cjwatson: This one is particularly bad.
[05:07] <keescook> pitti: just so I'm on the same page.  for the apparmor changes mathiaz sent, the preinst is not needed, is that right?  (i.e. dh_installinit should already do all the right things?)
[05:08] <pitti> seb128: thanks for the gnome stack trace patterns
[05:08] <pitti> keescook: it is needed
[05:08] <seb128> pitti: you're welcome
[05:09] <pitti> keescook: as I wrote, dh_installinit won't touch the symlinks as long as any symlink to the init script still exists
[05:10] <keescook> aaah, you wrote "update-rc.d won't do anything if there is any symlink..." so I wasn't sure if that was dh_installinit's invocation or a manual one.  I'm sorted now, thanks
[05:17] <pitti> asac: FOAD, no feisty-security firefox in the queue yet
[05:18] <asac> pitti: no?
[05:18] <pitti> asac: ah:
[05:18] <pitti> firefox_<IP_ADDRESS>+1-0ubuntu1_source.changes
[05:18] <pitti> REJECT
[05:18] <pitti> Rejected: Uploads to feisty are not accepted.
[05:18] <pitti> asac: feisty-security :)
[05:19] <cjwatson> pitti: err. did you mean FAOD? :)
[05:19] <asac> pitti: ouch
[05:19] <elmo> yeah, I was wondering if FOAD had a different meaning in German or something
[05:19] <pitti> cjwatson: indeed, sorry
[05:20] <cjwatson> "f*** off and die"
[05:20] <elmo> or if Evil Pitti really did come through from the mirror universe
[05:20] <Hobbsee> hehe
[05:20] <Hobbsee> it's likely the evil Hobbsee having an effect.
[05:20] <pitti> oops
[05:20] <pitti> asac: sorry, that wasn't my intention at all
[05:20] <Hobbsee> pitti: you used an acroynm without knowing what it meant?  unwise...
[05:20] <pitti> Hobbsee: I wanted 'FAOD', and I know what it means
[05:20] <Hobbsee> cjwatson: what's FAOD?
[05:21] <pitti> I just tpyoed
[05:21] <keescook> Hobbsee: congratz on your new badge.  :)
[05:21] <pitti> Hobbsee: for avoidance of doubt
[05:21] <asac> pitti: i didn't recognize it :)
[05:21] <Hobbsee> keescook: both of them?  :P
[05:21] <kylem> pitti is so innocent :)
[05:21] <Hobbsee> pitti: ahhh.  didnt know that one
[05:21] <elmo> disturbingly the first hit of FAOD on google is 'Furry Army of Doom'
[05:21] <elmo> I also hope that's not what pitti meant :-P
[05:21] <keescook> Hobbsee: ah, just saw the core-dev announcement.  :)
[05:21] <Hobbsee> elmo: hahahahhaa
[05:22] <iwj> pitti: Oh, sorry about not spotting that dpkg-source &warn thing.
[05:22] <Hobbsee> er, s/FAOD/FOAD/
[05:22] <pitti> iwj: no problem, it's all goo dnow
[05:23] <asac> pitti: do i need a version bump or the other upload forgotton now?
[05:24] <pitti> asac: the latter
[05:24] <asac> fine
[05:30] <Hobbsee> pitti: when you do finish with that brain eraser, please give it to me.  i've got work tomorrow, and the crazies are likely out.
[05:30] <desrt> saturday morning crazies?
[05:31] <desrt> the ones that line up half an hour before the store opens so that they can be the very first person on earth to have the privilege of buying a can of beans at the new price?
[05:32] <Hobbsee> desrt: saturday afternoon crazies
[05:32] <desrt> what's crazy about saturday afternoon?
[05:33] <Hobbsee> desrt: last week we had some guys on crack or something at night.  usually the afternoon is worse, with people wanting insane things.
[05:33] <Mithrandir> Hobbsee: like, food?
[05:34] <desrt> Hobbsee; is ketchup on your danishes really an insane thing or are you just closed-minded?
[05:34] <Hobbsee> Mithrandir: like refunds on stuff they didnt buy in the store, etc.
[05:34] <Hobbsee> desrt: heh.  we dont have ketchup.
[05:34] <desrt> as in "australia doesn't have ketchup"?
[05:34] <Hobbsee> yep
[05:34] <Hobbsee> it's tomato sauce, isnt it?
[05:34] <ogra> desrt, they have vegemite
[05:34] <desrt> not really
[05:34] <Hobbsee> or is it just sauce?
[05:35] <Hobbsee> haha
[05:35] <desrt> it's make out of tomatos but it's not tomato sauce
[05:35] <Spads> http://zork.net/~sneakums/fortunes/gar/110 <-- Hobbsee
[05:35] <desrt> it has vinegar and some other stuff in it
[05:35] <Hobbsee> vegimite is *not* a substitute for sauce
[05:35] <desrt> ketchup isn't "sauce"
[05:35] <Hobbsee> Spads: hahaha
[05:35] <desrt> it's more in the same category as mustard or something
[05:35] <ogra> ketchup is slightly sweet and sour and surely not sauce :)
[05:35] <desrt> condament
[05:36] <desrt> *condiment
[05:36] <ogra> glatzor, hey
[05:36] <desrt> yuck
[05:36] <Hobbsee> yummy!
[05:37] <glatzor> servus ogra!
[05:38] <ogra> glatzor, so displayconfig doesnt like if i dont have any xorg.conf ... is it planned to stay like that ?
[05:38] <ogra> s/doesnt like/doesnt like to start/
[05:41] <glatzor> ogra: depends on the plans of bryce.
[05:41] <ogra> ah
[05:41] <ogra> well, currently you get a traceback
[05:42] <MappyPants> anybody know of a free windows C++ profiler?
[05:42] <Hobbsee> try #c++
[05:42] <ogra> what kind of windows are that ?
[05:42] <Hobbsee> that's hardly on topic here
[05:42] <cjwatson> MappyPants: I'm afraid an Ubuntu development channel isn't the right place
[05:42] <MappyPants> i know, sorry heh.  there arent many chans for this question on freenode
[05:43] <pitti> Mithrandir: can you please give-back linux-source-2.6.22 on i386?
[05:43] <cjwatson> tepsipakki: huh, the current gutsy CD images don't seem to do gfxboot
[05:43] <bryce> ogra, yeah currently it requires an xorg.conf, however I hope to make it run without one, if we can find a good way of handling that situation
[05:44] <asac> pitti: keescook ok uploaded to feisty-security now
[05:44] <glatzor> ogra: you can currently start displayconfig with a stripped down xorg.conf that does not include any monitor or graphics card sections
[05:44] <keescook> asac: great, thanks!
[05:44] <pitti> asac: confirmed, it's on jackass
[05:44] <glatzor> ogra: and displayconfig-gtk should guess your configuration.
[05:44] <asac> i will look later tonight ... but am out for now
[05:44] <asac> pitti: cu tomorrow :)
[05:45] <pitti> asac: Berlin!
[05:46] <glatzor> ogra: but there are some problems with detecting dual screen layouts currently. but this seems to be fixable
[05:46] <ogra> pitti, you too ?
[05:46] <ogra> bryce, feel free to abuse me as guineapig
[05:47] <pitti> ogra: yep
[05:47] <ogra> cool
[05:48] <ogra> but i'll bring some ketchup for the grill :)
[05:49] <adilson> ogra: ketchup and gril are 2 words that *never* should be used in the same sentence ;)
[05:49] <pitti> darn, I cannot log into my LT account
[05:49] <bryce> ogra, since we will still need keyboard and font sections, for integration purposes I'm thinking we'll be focusing on partly-empty xorg.conf's, rather than no xorg.conf at all
[05:50] <bryce> but xorg is also adding input hotplug, and redoing fonts such that font paths won't be needed
[05:50] <bryce> so at some point, maybe gutsy+1, we will be able to realize xorg.conf-less default installation
[05:50] <cjwatson> tepsipakki: you seem to have dropped old changelog entries from syslinux too, which is generally bad form
[05:51] <ogra> adilson, yeah, i wouldnt dare to do that in brazil to prevent being lynched :)
[05:51] <ogra> but then you guys have the best meat ... ketchup is to hide the taste ;)
[05:51] <glatzor> morning bryce
[05:51] <bryce> heya glatzor :-)
[05:52] <ogra> bryce, why not leave keyboard to the desktop ?
[05:52] <ogra> and whty for do we need the font stuff ? my fonts work just fine without xorg.conf
[05:52] <bryce> ogra, how do you mean?
[05:53] <ogra> bryce, well, when i wiped my xorg.conf 1h ago gnome asked me if i want the X or the gnome keyboard config ...
[05:53] <cjwatson> leaving keyboard to the desktop will make console-setup's life more difficult
[05:53] <cjwatson> and also means that the keymap will be wrong at the gdm login prompt
[05:53] <cjwatson> please don't do that
[05:53] <ogra> cjwatson, not if we get a freedesktop standard for it
[05:53] <ogra> even gdm could use that
[05:54] <cjwatson> if that happens, we can talk about it then
[05:54] <ogra> heh
[05:54] <cjwatson> but we have reality to contend with
[05:54] <ogra> right
[05:54] <ogra> well, in gnome it would be just a gconf key ... sad we have so many other things to regard
[05:55] <bryce> ogra, well fortunately things are moving in the right direction :-)
[05:55] <cjwatson> tepsipakki: I think you also made a mistake in dropping my localboot-gfxdone patch
[05:56] <iwj> seb128: I was wondering if I could have your help again with gnome-system-tools and the default modem dial type (tones vs. pulses).  I'm trying to change the default and I'm lost in a twisty maze of thousands of lines of pointless boilerplate in g-s-t, s-t-backend, liboops, etc.
[05:56] <iwj> I've found what looks like the default but it's set to tones and manifestly the default is pulses.
[06:08] <agoliveira> Am I reaching this? freenod is disconnecting here from time to time.
[06:08] <Hobbsee> agoliveira: yes.  servers are dying occasionally
[06:10] <cjwatson> tepsipakki: I wonder if it just needs a new gfxboot package - looking at that now
[06:20] <superm1> Are any archive admins around?  I wanted to poke around as to why a package uploaded hasn't shown up to launchpad yet (It was uploaded a week ago on 5/23)
[06:23] <ogra> superm1, is it in the queue ? https://launchpad.net/ubuntu/gutsy/+queue
[06:24] <superm1> ogra, now that i look, yes it is.  Should have checked!
[06:24] <ogra> get someone to review it :)
[06:25] <superm1> i didn't realize that another review was required once it was past -motu...
[06:26] <ogra> if its a NEW package an archive admon has to review it
[06:26] <ogra> *admin
[06:26] <superm1> oh that would make sense
[06:26] <ogra> even for main developers thats the case
[06:26] <superm1> well this being the case, any archive admins up for looking it over?
[06:44] <Keybuk> superm1: NEW is processed roughly in order
[06:44] <superm1> ah okay. thanks Keybuk.
[06:44] <superm1> usually uploaded changes not NEW packages, so didnt hit the delay
[06:46] <iwj> Keybuk: Re your comments on BootLoginWithFullFilesystem, the `Demo plan' includes filling the disk and then rebooting.  Is that the kind of test you were thinking of ?  In which case perhaps I should clarify by moving the comments about Testing/Long to `Demo plan' and or add `Test' to the `Demo plan' title ?
[06:47] <iwj> Ttracing the system to find which daemons try to write stuff isn't going to help because we know there are lots of them and the issue isn't whether they write but what they do if they can't and whether the system can be used well enough to make space without them (if they break).
[06:47] <iwj> Which is why I suggested testing that directly.
[06:48] <iwj> As in, fill disk, reboot, how does it go ?
[06:48] <Keybuk> iwj: sure, but at least finding out which ones try to write is going to help, no?
[06:48] <iwj> I don't think so, no.  There'll be loads.
[06:48] <Keybuk> "fill disk, reboot" is a bit "yeah, looks like it kinda works, let's ship it"
[06:48] <iwj> And it'll be quite uninteresting.
[06:48] <Keybuk> needs to be done on a step-by-step way
[06:49] <Keybuk> you could fill the disk and examine what happens when hal starts, for example
[06:49] <Keybuk> or even not fill the disk, but wrap it with something that always fails on write() to a disk file
[06:49] <Keybuk> etc.
[06:49] <iwj> You could but I think that's out of scope.
[06:49] <iwj> `Examples of problems we consider out of scope: ... It is possible that some parts of the system or of the user's session will come up in a suboptimal state if the disk was full; this is fixable by making space and then rebooting'
[06:49] <Keybuk> the scope is "rigorously test the distribution"
[06:50] <Keybuk> (and fix any problems found)
[06:50] <iwj> That seems too ambitious to me.
[06:50] <Keybuk> it should be a few weeks of work, certainly
[06:50] <iwj> I don't think in practice we can make every default-install user app work if the disk is full at boot.
[06:51] <Keybuk> app; no
[06:51] <iwj> I agree that it would be nice but if we try to do this we'll be trying to shovel water uphill.  For every bug in this we fix some upstream will introduce ten more.
[06:51] <Keybuk> every process that we start by default should operate though
[06:51] <iwj> I agree that server installs ought to work if the disk was full during boot.
[06:52] <Keybuk> the desktop should as well
[06:52] <iwj> But that's largely already the case and I think making servers more robust against that is a rather different task.
[06:52] <Keybuk> the user should be able to clean up some files, and carry on
[06:52] <iwj> Yes, I agree that it _should_ but in practice we're not going to be able to make it.
[06:52] <Keybuk> we should try
[06:52] <iwj> You might as well say `the desktop should keep working after we've upgraded the system under it'.
[06:52] <Keybuk> it should
[06:53] <iwj> I agree but it's not going to happen.  If we put in two months of effort making it work in gutsy then it'll be broken in gutsy+1.
[06:53] <iwj> Since upstream don't think it's important.
[06:53] <Keybuk> we have an automated package testing framework, no?
[06:54] <iwj> All that thorough testing will do is tell us that it's broken.  It won't fix it for us.
[06:54] <Keybuk> knowing that it's broken is more than half of the battle
[06:54] <iwj> For example, probably the single most important application is firefox and trying to make firefox work when your disk is full is a hopeless struggle.
[06:54] <Keybuk> I don't think it's unreasonable for firefox to need to be restarted
[06:54] <iwj> It's hard even to stop upstream making it catastrophically lose data.
[06:55] <Keybuk> this is why it's "boot and login with full filesystem"
[06:56] <iwj> `We will aim to make the system work well enough for a user to be able to log in and delete files using the normal graphical file manager'
[06:56] <iwj> Is achieveable.
[06:56] <iwj> I don't think `make whole system work' is.
[06:56] <Keybuk> I didn't say "whole system"
 every process that we start by default should operate though
[06:56] <iwj> And we can test `can log in and check and delete files' without needing to know whether this or that breaks.
[06:57] <Keybuk> the work asked for in the spec was to perform a *comprehensive* test
[06:57] <iwj> I don't see why `process that we start' is a relevant criterion for this spec.
[06:57] <Keybuk> I don't see any plan for this test
[06:57] <Keybuk> and I don't see any evidence in the spec of the test results
[06:58] <Keybuk> iwj: relevant processes are all those run during the boot sequence, and login sequence; a subset of those being all those that are running when the user is at their desktop
[06:58] <iwj> AIUI the purpose of the spec is to improve the system's usefulness to users with specific references to the use cases and existing problems identified, right ?
[06:58] <Keybuk> none of these should fail in the case of full filesystem
[06:59] <iwj> I mean, that's the purpose of all specs.
[06:59] <iwj> Development activities listed in the spec should further that goal.
[07:01] <iwj> It's not clear to me how (for example) discovering whether or not hal breaks during boot with full filesystem furthers the goal of making the user able to delete files.  Although actually we should extend the scope to removeable media since that's important for cleanup.
[07:01] <Keybuk> it may not
[07:01] <Keybuk> but if HAL isn't operating, the user can't continue using their PC after deleting the files
[07:01] <Keybuk> since a major component will not be working
[07:02] <iwj> Indeed, but we expect them to reboot afterwards.  Since we know that the system may not operate properly and we don't think we can make all of the user's applications survive this problem, we should tell them to reboot.
[07:02] <Keybuk> no
[07:02] <Keybuk> we do not want them to have to reboot afterwards
[07:03] <iwj> `t is possible that some parts of the system or of the user's session will come up in a suboptimal state if the disk was full; this is fixable by making space and then rebooting.'
[07:03] <Keybuk> that part of the spec is wrong
[07:03] <iwj> Are you saying you disagree with that part of the scope ?  OIC
[07:04] <iwj> I think the effort/reward ratio for making this work and keeping it working is not going to be worthwhile.
[07:05] <iwj> If the user is going to be expected to restart firefox we might as well ask them to reboot.
[07:09] <nnonix> News: You cannot (according to Dell) buy an E1505n (or any non-server Linux option) under your small business lease program. Residential credit only.
[07:10] <nnonix> I just tried.
[07:10] <cypherbios> glatzor_: ping
[07:19] <glatzor_> pong cypherbios
[07:20] <cypherbios> glatzor_: hi. What do you think about having a --sources-list=FILE in software-properties -- to let the user specify a custom sources list and do not mess up with their default one?
[07:20] <glatzor_> cypherbios: generally it's nicer to not cover all kind of extra cases in the core of the application, but making the core as flexibel as possible and use it in different contexts
[07:21] <glatzor_> cypherbios: so you could just add a manager.window_main.hide() after the init, instead of checking the options inside of the core
[07:21] <glatzor_> cypherbios: why?
[07:22] <cypherbios> glatzor_: are you talking about the patch I sent yesterday?
[07:22] <glatzor_> cypherbios: yes
[07:23] <glatzor_> sorry, I started typing as soon as you pinged me :)
[07:23] <cypherbios> glatzor_: np ;)
[07:23] <cypherbios> glatzor_: about the patch, what you think is better? I didn't catch you point :)
[07:23] <cypherbios> *your
[07:24] <imbrandon> Keybuk, hrm i have an upstream thats wanting to use the http://sam.zoy.org/wtfpl/ license, is that acceptable, its free but seems a but tacky imho
[07:24] <imbrandon> err Keybuk dident mean to direct that to you individualy
[07:24] <imbrandon> anyone*
[07:25] <glatzor_> cypherbios: "if self.options.add_cdrom:" inside of SoftwarePropertiesGtk.py is not needed
[07:25] <cypherbios> glatzor_: oh, I got
[07:26] <cjwatson> imbrandon: as you say, it's tacky but acceptable
[07:26] <cypherbios> glatzor_: that's right, I didn't noticed that
[07:26] <Keybuk> what has the author of that licence ever achieved?
[07:26] <Keybuk> apart from becoming the Debian Project Leader, of course
[07:26] <Keybuk> :p
[07:27] <cypherbios> glatzor_: btw, I'm wondering if would be nice if we have a new option --sources-list=FILE, what you think about?
[07:27] <imbrandon> heh , he was a DPL ?
[07:27] <imbrandon> lol
[07:27] <elmo> is
[07:27] <imbrandon> is?
[07:27] <Keybuk> yes
[07:27] <imbrandon> err
[07:27] <Keybuk> is the current DPL
[07:27] <imbrandon> wow
[07:28] <imbrandon> i realy must come out of my cave once in a while
[07:28] <desrt> i wouldn't say "not knowing who the current DPL is" is indicative of life in a cave
[07:28] <desrt> i'd actually suspect the opposite to be true :)
[07:28] <imbrandon> heh
[07:28] <avoine> someone know what package is responsible of creating and populating /dev in ubuntu?
[07:29] <desrt> avoine; in what sense?
[07:29] <desrt> these days, udev
[07:29] <Keybuk> avoine: udev
[07:29] <avoine> ok
[07:30] <mc44> I wonder if doing WTFYL is acceptable legal terminology :)
[07:31] <Keybuk> avoine: why?
[07:32] <avoine> I try to modify debian-installer
[07:32] <cypherbios> glatzor_: a use case would be when the user do not want to touch in his default sources.list (/etc/apt/sources.list) but want to add a reporitory or a third-party source or even a cdrom without messing the system's sources.list
[07:32] <avoine> for install a backup instead of ubuntu
[07:33] <glatzor_> cypherbios: why would you do this? I could only think of a developer
[07:33] <glatzor_> who wants to test his cd
[07:33] <avoine> the problem is when I try to install grub with grub-install I have a error because /dev is empty in the target
[07:35] <glatzor_> bryce: have you seen, that the Nvidia configuration tool is open sourced?
[07:35] <bryce> no I hadn't; is that a recent change?
[07:35] <pitti> good bye
[07:36] <glatzor_> bryce: I don't know. it does not include a NEWS or Changelog file
[07:36] <bryce> I was just now looking at the ati driver - looks like they put out a new release (8.37.6 vs. our 8.34.8)
[07:37] <glatzor_> bryce: have you already read: http://www.phoronix.com/scan.php?page=article&item=735&num=1
[07:37] <cjwatson> avoine: standard solution is 'mount --bind /dev /target/dev'
[07:37] <bryce> hmm, looks like the last update for our nvidia driver was Mar 23
[07:37] <cjwatson> avoine: probably same for /proc and /sys
[07:37] <cypherbios> glatzor_: actually I have a application called aptoncd, the objective of this tools is to create a removable repository with the apt-cached packages. After creating this medium, the user wants to add it as apt source, so they can do that by using the apt-cdrom add, synaptic, software sources or something, but the user also can do it by using the aptoncd interface,
[07:37] <glatzor_> bryce: the article mentions Ubuntu being part of the beta tester programme :)
[07:37] <cypherbios> glatzor_:  currently aptoncd calls "/usr/sbin/synaptic", "--hide-main-window", "--non-interactive","-o=dir::etc=" + sourcesdir","-o=dir::etc::sourcelist=aptoncd.list"
[07:38] <cjwatson> avoine: actually, I think 'mount -o bind' rather than 'mount --bind' - the mount in the installer doesn't understand --bind
[07:38] <cjwatson> or maybe I'm wrong :)
[07:38] <bryce> glatzor_: in fact that's why I was just checking out the ati driver ;-)
[07:39] <cypherbios> glatzor: with the --ask-cdrom, but I'd like do the same using the software-properties, so it will work in a kubuntu box without synaptic
[07:41] <cypherbios> glatzor: so software-properties-{kde|gtk} --add-cdrom --sources-list=/etc/apt/sources.list.d/aptoncd.list would do the trick
[07:41] <glatzor> cypherbios: But I don't understand why you want to write into a different sources.list. Isn't enabling or disabling a repository using the software-properties or an editor the better way instead of copying sources.list files?
[07:42] <cypherbios> glatzor: it will not copy the sources.list, it will add the medium in the specified file, in a stand-alone mode, so I can remove, or edit the file in any way I (or user) want to, just to keep everything safe from mistakes
[07:43] <cypherbios> btw, it's not essential, just an additional option would turn things nicer
[07:43] <glatzor> ah I am a fool, cypherbios
[07:44] <glatzor> I haven't seen the sources.list.d :)
[07:44] <cypherbios> heh ;)
[07:49] <cypherbios> glatzor: currently I can use software-properites $FILE, so it will use $FILE as sources.list, but if $FILE doesn't exist or it haven't any valid entry I will get an error, so in this case what we need to do is continue without a error
[07:51] <glatzor> cypherbios: Hm, I am unsure about doing this by the using a command line switch. If it is available there will be users using it for other purposes :)
[07:52] <glatzor> cypherbios: But I will implement it.
[07:52] <cypherbios> glatzor: I understand.
[07:53] <cypherbios> glatzor: oh thanks, it will be really useful
[07:55] <glatzor> cypherbios: We already added the --enable-component option for gnome-app-install. And I was quite surprised seeing bug reports and feature requests on Launchpad.
[07:56] <glatzor> glatzor: but there are often bug reports that are written because users think that s-p behaves like a normal text editor.
[07:56] <cypherbios> glatzor: unhappy new features usually brings new bugs =/
[07:57] <cypherbios> glatzor: and what about a more 'hidden' option?
[07:58] <cypherbios> glatzor: like an apt arbitary option (such the -o=$APT_PARAMETHER of the synaptic)
[07:58] <cypherbios> glatzor: so we would use s-p -o -o=dir::etc::sourcelist=mycustomsources.list
[07:59] <cypherbios> ops, too many '-o' ;)
[07:59] <cypherbios> software-properties -o=dir::etc::sourcelist=mycustomsources.list
[08:00] <glatzor> cypherbios: what kind of script do you use to run software-properties?
[08:01] <glatzor> cypherbios: perhaps it would be nice to even use a python script and just import softwareproperties
[08:01] <cypherbios> glatzor: it's python, it's a python application
[08:01] <glatzor> cypherbios: then this could be a nicer approach.
[08:02] <cypherbios> glatzor: indeed!
[08:03] <cypherbios> glatzor: I was just afraid to implementing some 'feature' that wouldn't arrive the upstream
[08:06] <cypherbios> glatzor: I need to go out. Thanks for the attention :)
[08:08] <bryce> is anyone using kubuntu?  Could someone do a dpkg -S /usr/bin/hwdb-kde for me?
[08:10] <glatzor> bryce: packages.ubuntu.com provides a file search function
[08:10] <bryce> ahh, excellent, thanks
[08:12] <keescook> hm, anyone know a way to find out what file maps to a fd without using /proc/$pid/fd ?
[08:14] <Lure_> bryce: hwdb-client-kde: /usr/bin/hwdb-kde
[08:15] <bryce> Lure_: thx
[08:16] <superm1> keescook, can you possibly use fdlist?
[08:16] <Lure_> bryce: apt-file might also help
[08:16] <keescook> superm1: ah, also lsof, got it
[08:17] <superm1> lsof will easily hang though in the case of an nfs server not being located
[08:17] <superm1> not sure if there is a way around that
[08:17] <bryce> Lure_: cool I didn't know about that
[09:22] <bokey> hi with samhain package in sys admin universe, is lkm checked in default install ?
[09:26] <bokey> i see that samhainrc has lkm rootkit detection off by defualt
[09:26] <bokey> anyone know why ?
[09:27] <bokey> I am talking about version samhain (2.2.0)
[09:27] <bokey> ~edgy sys admin universe
[09:30] <bokey> Javier Fernandez-Sanguino if here please tell me
[10:16] <cypherbios> Riddell: would adept have a --set-selections or --set-selections-file option?