#ubuntu-devel 2004-10-18
<yuval> Kamion, sivang, https://bugzilla.ubuntu.com/show_bug.cgi?id=1231
<mdz> is there any way to play a Vorbis stream from firefox, e.g. as background audio for a web page?
<Kamion> quick review of https://bugzilla.ubuntu.com/show_bug.cgi?id=2123 please?
<Kamion> yuval: thanks, I noticed your updates; I'll have a look tomorrow
<Kamion> (since most of my other RC stuff is out of the way now)
<Kamion> yuval: it seems to be a d-i bug too
<Kamion> he_IL.UTF-8 UTF-8
<Kamion> he_IL ISO-8859-8
<Kamion> but languagelist has:
<Kamion> Hebrew;he_IL;he_IL;he;IL;he_IL:he:en_GB:en;kbd=iso08.f16(utf8)
<Kamion> ... in fact, why don't I just have a look tonight ...
<yuval> Kamion: I checked debian installer and there is no problam there.
<Kamion> really? languagelist seems to be the same
<yuval> ubuntu have a more update base-config, maybe something changed.
<thom> Kamion: that patch looks reasonable at plain reading
<Kamion> thom: actually there's a minor bug in the LENOF macro (insufficient parentheses at one point), although it doesn't affect this case
<Kamion> yuval: don't see anything relevant in the base-config changelog
* thom takes that as his cue to go to bed
<thom> g'night
<Kamion> thom: but thanks
<Kamion> will upload now
<thom> np
<yuval> Kamion: What is he_IL;he_IL;he;IL;he_IL:he:en_GB:en ?
<thom> i'm almost at matchsticks to hold eyes open here :-)
<Kamion> yuval: too complicated to explain here, look in the languagechooser source ...
<yuval> I'll do that.
<Kamion> I'm trying it out with the first two he_IL entries changed to he_IL.UTF-8
<Kamion> not that I speak Hebrew, but fortunately I can drive the installer almost blind :)
<yuval> lol
<mdz> Kamion: how confident are you in this archive-copier change?
<Kamion> mdz: seems to work when I test package-cache-names at the command line
<mdz> Kamion: it's tempting to revert to copying everything, considering the late hour
<Kamion> that seems overkill; this is a really easy change
<yuval> Kamion: Do you know how "Hebrew" looks in Hebrew?
<Kamion> yuval: not even that
<mdz> Kamion: ok, if you're confident, it's OK with me
<Kamion> mdz: if you're really uncomfortable with the change to C code I can fix it in debian/postinst, but that's harder to test
<Kamion> (since I have to boot d-i to test it in that case)
<mdz> Kamion: it looks bigger than it is, due to the renaming
<mdz> I think it's fine
<Kamion> uploaded
<yuval> I'll be back in half an hour. I go out with my dog.
<sivang> Kamion : hand me over an iso when you set it up, I'll test it on my USB kbd
<sivang> Kamion  : however if the languagle list is the same like debian's , I don't see why it should break.
<Kamion> that does puzzle me
<sivang> I mean, you havn't touched anything on the lists right?
<Kamion> we are somewhat behind on languagechooser/countrychooser/base-config, and the interactions there are subtle
<sivang> BTW : how can I svr or else get U-I's source?
<Kamion> (and quick to anger)
<Kamion> sivang: from the source packages in the archive. we have no revision control yet.
<sivang> ok
<sivang> apt-get source u-i/d-i ? ;)
<Kamion> it's easy for me, since I uploaded most of it and can just look in ~/src/ubuntu/ :-)
<Kamion> no, individual source packages
<Kamion> so e.g. apt-get source languagechooser
<sivang> oh
<sivang> much better ;)
* sivang feels again the need for 3mb downstream broadband..
<sivang> for iso testing..;)
<sivang> Kamion : the languagechooser scripty is the whole source?
* T-Bone would rather have the opposite of his current setup: 6mb dl/ 0.5mb up. Much better to upload big packages and run servers ;)
<Kamion> sivang: it has complex interactions; if you're interested in figuring out how d-i works it's probably much easier to check out the upstream source from subversion, at the moment
<sivang> Kamion : oh, you removed all the remarks and stuff? :)
<Kamion> no
<sivang> ok
<Kamion> but it's easier to navigate the upstream tree since it's all in one piece
<Kamion> erk, he_IL.UTF-8 doesn't even work a little bit for me
<T-Bone> Kamion: btw, i've been unfortunately delayed on the ia64 side, but I haven't dropped d-i stuff there. It's just a 1week delay, most likely
<sivang> Kamion : you on the USB kbd?
<Kamion> sivang: that's not relevant for this part of the bug
<Kamion> sivang: don't get too distracted by the keyboard thing; it's connected, but it won't be the thing causing text to be unreadable
<sivang> oh , _that_ bug
<sivang> :)
<sivang> I thought we were discussing the one that fails right when d-i starts.
<sivang> *that makes d-i fail on start
<Kamion> no
<Kamion> hm
<Kamion> well, there seem to be two conflated things in that bug
<Kamion> I'm talking about Yuval's report of corrupted text in the second stage
<Kamion> which is really a different bug and probably shouldn't be part of #1231
<sivang> right. 
<sivang> I never went on with the hebrew install fearing it would break other thigns, so I never got to see this ;-)
<yuval> sorry... he_IL.UTF-8 doesn't change anything?
<sivang> moreover, I don't think I could survive a complete hebrew d-i install ;-))
<yuval> sivang: Why not?
<Kamion> yuval: it's corrupted differently; I'm trying to investigate
<sivang> yuval : ah, it's a long story. I am so used to english on computers by now, it freaks me sometimes people have "enabled" setups. I'm using english to correspond even with my closest freinds, so I don't really need it. Plus if you have ever tried KDE/GNOME with hebrew, it's not the most pleasent experience trying to figure out where everything is put. issue of taste and experience. 
<sivang> yuval : using a bank's site or anything close does require me to have the suitable fonts for hebrew display on the browser, however all interactions with them are numbers and english password letters - so everything's fine.
<Kamion> oh, we don't have jfbterm in base, that might explain it ...
<sivang> yuval : But I sure like to see Ubuntu works well with it, just for the sake of hebrew users.
<Kamion> maybe it would be easier to attack the Greek bug first
<sivang> boy it uses iconv
<sivang> Kamion : there's a related greek one?
<Kamion> I think so, if only I can find it
<Kamion> maybe I'm mixing up Debian and Ubuntu bugs
<Kamion> oh, there it is, #1683
<sivang> Kamion : I can't explain why, but base-config sure attracts me. reading the sources is the _only_ way to get aroud it?
<Kamion> I don't understand; could you rephrase?
<sivang> Kamion : ahhm. sorry. I meant, in general reading the package's srcs would be the best way to understand base-config and it's inner workings?
<Kamion> that is the case for software in general
<sivang> Kamion : true, however having a pre background about it can help understanding it. When I do so, I usually come up with new questions, that usually are left unanswered unless I bug someone on IRC ;-)
<sivang> Kamion : "When I do so" = when I read the source
<sivang> do we have a script to automagically set up nvidia? (think i've seen that on the wiki somewhere)
<Kamion> daniels: OK, I'm a substantial way through investigating this locale problem, so I can take the Greek bug back if you like; it is indeed a subtle set of interactions ...
<Kamion> we need languagechooser to set up /etc/environment in order for /etc/init.d/console-screen.sh to work in order for UTF-8 to have any chance of being set up correctly in order for ...
<sivang> having hebrew, greek and other  display correctly for ... :)
<Kamion> quite
<Kamion> ow, gums bleeding, this can't be good
<Kamion> think I'll go to bed
<T-Bone> heh
<T-Bone> have a good night
<sivang> Good night Kamion
<yuval> Good night (01:53 in israel)
* T-Bone gently pokes lamont, just in case
<sivang> I think he's still away, he said he had more of a couple of things to do ;)
<jdub> mdz: so i have some interesting bugs to figure out
<jdub> ubuntu, on pia's oldish p2 toshiba satellite is incredibly slow
<jdub> to install and to run
<jdub> sid runs at full speed
<mdz> is DMA disabled?
<jdub> however, running sid with the ubuntu kernel demonstrates the slowness
<jdub> nup
<jdub> doesn't seem to be i/o related
<jdub> everything runs slowly
<mdz> what kernel did you use under sid?
<mdz> I had a similar machine (though k6 rather than p2), and ubuntu performed similarly to debian
<jdub> she's currently using a 2.4 kernel; will have to try a different 2.6 when she comes back from cairns
<mdz> did you try the -686 kernel?
<jdub> hrm
<jdub> i think she might have
<jdub> but i'll check that too
<mdz> jdub: you have a powerpc machine handy?
<mdz> (running ubuntu)
<mdz> someone please try installing libopenhbci-dev on powerpc
<jdub> hrm, it's totally out of date ;)
<jdub> "Disable challenge-response authentication?"
<mdz> jdub: Kamion
<mdz> jdub: #1586
<jdub> ahr
<daniels> Kamion: sure, you can have it; seems you figured it out while I was asleep :)
<tseng> rc bugs dropping like drunken college chicks
<tseng> way to go.
<sivang> jdub : i have had witnessed horroble slowness with ubuntu using kerlen 2.6.8-386 on a dell inspiron 8200
<sivang> jdub : I tried swithicng to 686 kenrel - didn't help either
<sivang> jdub : this is a 1.8Ghz machine, 7200 rpm 256MB ram
<T-Bone> past 5AM here, time to get some sleep. Bye all.
<fabbione> morning guys
<fabbione> mdz: permission to upload fontconfig for 2122, s/|/, in debian/control ofr laptop-detect
<fabbione> jdub?
<fabbione> or any other devel
<mdz> fabbione: yes, that's trivial, no need to ask
<fabbione> usual peer-review ;)
<fabbione> never lose the good habits :)
<fabbione> mdz: i have a wacom driver for the submitter to test and some keyboard layout almost pending (waiting Denis Barber to commit)
<fabbione> the latter ARE important for us to have
<mdz> ok
<lamont> moof
<fabbione> hey lamont 
* lamont is going to be very sore tomorrow.
<fabbione> lamont: uh what happened?
<lamont> must. learn. to. fall. better.
<lamont> oof.
<fabbione> ahi
<mdz> fabbione: do you need a ppc login to build a driver for that guy?
<doko> morning
<fabbione> mdz: oh right... he has a ppc
<fabbione> mdz: no i can build in the chroot
<mdz> ok
<lamont> mdz: 2113....  should we add cupsys-driver-gimpprint* to supported?
<lamont> (works for the user...)
* lamont thinks actually desktop would be good..
<mdz> I think it's too late for that
* lamont has issues with adding the drivers yet again...
<lamont> certainly want them for hoary...
* lamont could probably be talked into adding bfc-s200-hack.ppd to the cupsys package... :-)
<fabbione> ubuntu-users is way too high traffic now
<mdz> yep
<lamont> 12MB in the last half of Sept, 7MB in the first 6 days of Oct.  sheesh
<sivang> mdz : I'm occasionaly stung when I see you respond almost every user with support request. How do you keep up? ;)
* sivang has long given up on reading it as a whole. trying only to notice relavent parts for him to support/help.
* fabbione wisper to sivang that mdz is a manager and therefor sit on the chair *almost* doing nothing :P
<fabbione> sivang: mdz is a bot
<fabbione> that's the truth
<fabbione> we created an AI living form even able to walk on walls
<fabbione> like spideman
<sivang> he's so fast also,
<fabbione> spiderman even ;)
<sivang> amazing
<sivang> :))
<sivang> are we going to have to bug system tp accept http://bugzilla.u.c/bug# ?
<sivang> *the
<mdz> sivang: it already does
<mdz> fabbione: :-P
<sivang> oopst
<sivang> ok.
<sivang> mdz : thanks :)
<sivang> mdz : are you going to leave fabbione get away with this? :-)
<mdz> sivang: my revenge is swift and without warning
<mdz> when he least expects it
<mdz> the black helicopters will hover overhead...
<sivang> haha
<fabbione> ahhah
<sivang> boy, i'm after a sleepless night, almost dropps and can't stop
<sivang> fabbione : remeber the drug?
<sivang> I think I am in it bad....
<fabbione> sivang: yes i do :-)
<fabbione> mdz: a patch for 2111 is very very simple
<fabbione> mdz: the driver code is nice and dandy ;)
<mdz> why do I get the feeling you are not entirely serious?
<fabbione> mdz: i am serious
<fabbione> it's a 3 lines change
<fabbione> right now is:
<fabbione> use_bios = TRUE;
<fabbione> it will be:
<fabbione> if CARD == foo || CARD == bar { use_bios=FALSE
<fabbione> and so on
<fabbione> the line after will load the override (if any) from XF86Config-4
<fabbione> as simple as this ;)
<fabbione> there are only to ProSavageDDR models defined/known in the driver
<fabbione> that makes things easier
<mdz> I hate NFS
<mdz> oh I hate it so
<lamont> mdz: just repeat after me 'NFS stands for "Not a File System"'
<sivang> night everybody - hitting bed after 20hrs of uptime ;-) wish I had some auxilary power source to connect to..
<sivang> NFS stands for "Not a File System"
* sivang wishes he had a pesronal human docking station.
<mdz> I am finally caught up on email
<mdz> from taking sunday off
<mdz> -users is out of control
<lamont> mdz: definitely.  No slow s-curve of adoption here...
<fabbione> i don't think we expected such a boom
<fabbione> did we?
<lamont> fabbione: hoped is the word, I think.
<mdz> aw, ubuntu-traffic didn't make LWN this week
<fabbione> we hoped for a boom... but i don't think we were ready for one of this size.. that's my impression at least
<lamont> mdz: so do you want a new cupsys upload with the file then, or we defer moving cupsys-driver-gimpprint's move til hoary and downgrade the bug?
<mdz> lamont: that bug isn't RC anyway, is it?
<mdz> if it is, that's wrong
* lamont checks again
<plovs_work> i want to thank you guys, my gnome-login-bonobo-hang-error was no longer there this morning, thanks!
<mdz> 3 of the remaining 14 bugs are powerpc bugs :-/
<lamont> normal
<mdz> doko: what is the status of tetex-base?
<mdz> (#2066)
<doko> mdz: removing the references in the documentation to the removed .html file. should be done in some minutes
<mdz> ok
<jdub> fabbione: pong
<fabbione> jdub: too late :-)
* lamont prepares to head for bed.
<fabbione> good night lamont 
* lamont wonders if there is anything he can do to help progress on any of the RC bugs
<lamont> anyrate, sleep until morning..
* Mithrandir waves
<fabbione> is "reject_nondigits" something that debconf uses?
<fabbione> no
<fabbione> never mind
<mdz> jdub: this new firefox is supremely buggy
<Mithrandir> mdz: should we consider switching to gcc 3.4 for it?  Works on AMD64. :)
<tseng> seems to work on x86 now for the most part as well
<tseng> besides a pretty major b0rkage with sse2
<Mithrandir> tseng: do you have a p4?
<tseng> i have a p4 and a p-m
<Mithrandir> could you try reproducing 1854?
<tseng> i have no HT
<doko> mdz (or someone else): somebody wants to review tetex-base (#2066) before upload? chinstrap:~doko/tetex/
<tseng> and no apt-get lameness on gzip either
<Mithrandir> tseng: ok. :/
<mdz> doko: attach a diff to the bug?
<Mithrandir> tseng: it doesn't show without HT, it seems.
<tseng> Mithrandir: my friend joe is using an HT p4 w/ no serious problems either
<tseng> Mithrandir: smp 686 kernel
<doko> mdz: ok, but debdiff doesn't show removed files.
<Mithrandir> tseng: hmm, ok.  I find it somewhat strange that I'm the only one able to reproduce it.
<tseng> ah, you can?
<Mithrandir> yes, it's I who filed it.
<Mithrandir> :)
<fabbione> foo() { echo "" }
<fabbione> bar=$(foo)
<fabbione> what can cause something like that to hang?
<Mithrandir> and I'm hunting for somebody else who can confirm it, if nothing else to prove I'm not on serious amounts of crack.
<fabbione> in a debconf environment
<tseng> this happens on any apt-get upgrade?
<Mithrandir> tseng: no :/  ; apt-extracttemplates seems to hang randomly about 10% of the time.
<tseng> mmmm, random
<Mithrandir> of course, stracing the problem makes it go away.
<tseng> is apt-extracttemplayes heavily threaded?
<Mithrandir> which probably means it's some sort of a race issue
<Mithrandir> I don't know, mdz could tell?
<fabbione> Mithrandir: can you try to call sync between each call to apt-extracttemplates?
<tseng> well mdz alluded to nptl there
<tseng> we fought some funny bugs with nptl and apps making alot of threads just crapping out
<tseng> but it didnt seem to affect distros that ship a hybrid glibc
<Mithrandir> fabbione: same problem.
<Mithrandir> tseng: can I list the threads somehow, or do they still show up as separate processes in ps?
<tseng> not under nptl
<tseng> they look like a single process
<fabbione> Mithrandir: do you have any idea for the sh script above?
<Mithrandir> I doubt apt-extracttemplates uses many, if any, threads.
<tseng> but that doesnt explain much about the non-SMP kernel
<Mithrandir> fabbione: are you sure you aren't talking to debconf?
<tseng> ya..
<tseng> the race idea is valid also
<fabbione> Mithrandir: it's the config.in for xserver-xfree86
<Mithrandir> since it only happens once in about ten times.
<fabbione> Mithrandir: it loads debconf that's clear
<fabbione> Mithrandir: it hangs in a function similar to the one i wrote above
<fabbione> Mithrandir: see https://bugzilla.ubuntu.com/attachment.cgi?id=355
<Mithrandir> fabbione: yes, but the foo=$(bar) might try to read from debconf since stdout is redirected.
<doko> mdz: done
<Mithrandir> tseng: and I have to kill -9 the gzip processes.
<Mithrandir> hmm, weird.
<Mithrandir> if I reproduce the problem, it doesn't seem to go away until I start another process (ls, dmesg, whatever)
<Mithrandir> oh, it does
<Mithrandir> it's just slow
* Mithrandir scratches head.
<mdz> doko: debdiff seems to show the removed file OK
<mdz> doko: the diff looks fine to me
<mdz> doko: will you upload it?
<doko> mdz: done
* ..[topic/#ubuntu-devel:doko] : Ubuntu development -- general discussion on #ubuntu | 13 RC bugs to go
<doko> mdz: the libnet-ph-perl upload discussed in email: does the control file section need to be changed to universe/*
<mdz> doko: no, it is overridden
<doko> ok, uploading
<daniels> mdz: now down to 12 RCs?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 12 RC bugs to go
<mdz> 1080 is getting downgraded as well; it's way too late to mess with fixing bug-buddy
<mdz> doko: you forgot to close #2066?
<Kamion> jdub: hmm, I guess that message is going to show up for everyone who installed the preview and then upgrades to final
<Kamion> that kind of sucks
<Kamion> um, guys
<Kamion> mdz: wvdial is being interactive on me during the initial installation
<Kamion> mdz: can't we stop it doing that? debconfization should be two hours' work for somebody who knows debconf reasonably well
<mdz> Kamion: pitti fixed that yesterday, I thought
<mdz> maybe it didn't make the CD build?
<Kamion> ah, maybe it missed my CD
<Kamion> I think I have yesterday's here
<mdz> Kamion: #2069
<Kamion> OK, fine
<Kamion> but hey, SHINY GREEK TEXT
<doko_> kamion: should the pmac sound problem be fixed on yesterday's powerpc cd?
<mdz> Kamion: any idea what's going on with #1997?
<mdz> doko_: <mdz> doko: you forgot to close #2066?
<Kamion> doko_: should think so, yeah
<Kamion> mdz: absolutely no idea; I'm tempted to ask the submitter to try yet another daily just to be sure
<Kamion> but the CD he claims to have really should have all the required code
<mdz> Kamion: it doesn't look like we've confirmed that the module is being loaded
* ..[topic/#ubuntu-devel:doko_] : Ubuntu development -- general discussion on #ubuntu | 11 RC bugs to go
<doko_> mdz: done :)
<mdz> maybe it is in fact being loaded, but something else is wrong
<Kamion> it's rather hard to tell without a keyboard
<mdz> true
<fabbione> brb
<mdz> I thought ohci-hcd was built in on powerpc for just this reason
<Kamion> it's not; it really shouldn't need to be
<mdz> hmm, so there's no keyboard until hotplug runs?  that's rather scary
<mdz> what happens if fsck fails?
<Kamion> dunno :)
<Kamion> mdz: fix in #1683 OK by you, in principle? I need to do more testing
<Kamion> for Greek it works for me all the way up to a desktop
<Kamion> incidentally I really must learn Greek, because it is so much prettier
<mdz> Kamion: so the bug is that it wasn't generating the locale?
<Kamion> it wasn't generating it early enough
<mdz> ah
<Kamion> it was being generated in base-config or something, but that's too late; it needs to be there by the time /etc/init.d/console-screen.sh runs
<mdz> and the fix is to have prebaseconfig generate the locale in the target?
<mdz> if so, sounds fine
<Kamion> right
<Kamion> anyway, I need to shut down, taxi coming soon; back in some hours
<seb128> morning
<sjoerd_> pitti: ping
<seb128> hey sjoerd 
<sjoerd> seb128: morning :)
<pitti> sjoerd: pong
<pitti> sjoerd: sorry, I was away for half an hour
<sjoerd> pitti: haha
<pitti> sjoerd: ?
<sjoerd> pitti: don't apply davidz version of my patch, it's wrong
<pitti> sjoerd: the one for the first hotplug event?
<sjoerd> pitti: that you say sorry for being away half an hour :)
<sjoerd> pitti: yes
<pitti> sjoerd: last_seq_number or so
<sjoerd> pitti: it can kill off hotplug processing of hal, if events come at a bad timing
<pitti> sjoerd: well, since the current version works great, I rather not change anything unless I find a bug
<sjoerd> pitti: i'll send a mail explainign why, after i finish math homework :)
<pitti> sjoerd: but thanks for letting me know. Did you already talk to David about this?
<pitti> sjoerd: ah, okay. 
<sjoerd> david is probably still sleeping anyway
<thom> Mithrandir: hrm, do you know if firefox-locale-no has a PR1.1 release?
<Mithrandir> thom: it does, I just haven't made a package yet.
<Mithrandir> at least pr1.0 release.
<thom> oh, rock
<thom> we might get it locaalised to one language then
<thom> afaics, french and german hasn't happened yet
<Mithrandir> I can look at fixing it up and dropping the package into experimental tonight
<daniels> thom: it's so nice
<daniels> thom: remind me to buy you a beer some day
<thom> *g*
<thom> told ya
<daniels> thom: except mine is superior to yours
<pitti> jdub, mdz: IMHO we can downgrade #2131, do you agree?
<daniels> thom: they must've fixed the keyboard layout in a later revision :)
<daniels> thom: your keyboard LED is white, no?
<thom> no, orange
<daniels> ahr, mine's orange too
<daniels> I thought yours was white for some reason
<daniels> strikes me as kind of odd to put an orange LED there
<daniels> when white provides more light and IMO looks better
<daniels> ho hum
<daniels> dinner time
<sabdfl> Kamion: fun and games with openssh-server this morning
<sabdfl> Kamion: i installed openssh-server a month ago and never touched the config
<sabdfl> this morning'supdate is asking me about passwords being disabled and challenge response...
<sabdfl> seems like that quesiton assumes the default is passwordauth yes, so if your config is "no" then it assumes you must have edited it
<sabdfl> but i think your default is passwordauth no
<sabdfl> so this question is getting asked
<sabdfl> can we fix that please?
<sabdfl> seb128: morning
<sabdfl> Setting up desktop-file-utils (0.9-0ubuntu1) ...
<sabdfl> File '/usr/share/applications/gnumeric.desktop' contains invalid MIME type 'comma-separated-values' that is missing a slash
<sabdfl> ?
<seb128> hello sabdfl 
<seb128> sabdfl: yeah, the new desktop-file-utils reports problems instead of just ignoring the files
<sabdfl> seb128: cool, lint!
<sabdfl> or... lint-free!
<sabdfl> nice that there was only one glitch when that got turned on. neat work, thank you
<seb128> sabdfl: so gnumeric.desktop has a problem, I put that on my todo list for today :)
<thom> great, now there are people filing dups upstream of the firefox crasher
<thom> they're never gonna fix it in a week :/
<seb128> thom: you're going to fix it, aren't you ? :)
<thom> i stared at it till my eyes blead, and pitti's dug into it too
<daniels> eh? surely the mime type for csv would be something like text/csv or text/comma-separated-values
<daniels> mdz: dbus-monitor seems to be completely non-functional in some cases. amircornot?
<daniels> or ratemybugseverity, whichever you like
<daniels> wow, IE really is terrible.
<daniels> konq was cooler about three years ago
<thom> get netbooting, kid
<daniels> thom: er
<daniels> thom: so we're on a 4GB plan, right.  but Dad didn't see fit to tell me that he forgot to ask for unlimited and that we were on 4GB until I'd sucked 2.3GB in the first 24-48h.
<Kinnison> pitti: ping
<daniels> thom: and that was about a month ago, and we haven't rolled over to a new month yet.
<daniels> thom: so I'll download it at uni tomorrow.
<thom> oops.
<daniels> yeah
<daniels> hence the note on StaffCalendar
<thom> oh man. i saw gpl'd flash impementation on ubuntu-devel and nearly died
<daniels> pitti: hal is being really weird on Kinni's system
<daniels> pitti: the first word that comes to mind when describing his system starts with 'b' and ends in 'ong'
<pitti> Kinnison, daniels: pong
<pitti> back from lunch
<Kinnison> pitti: hal is being very odd at me
<pitti> Kinnison: some details?
<Kinnison> pitti: Well; on first boot; if I plug a usb device in; hal knows nothing about it
<daniels> pitti: if you have binaries or sources around for -1ubuntu4, that may help isolate Kinni's problem
<Kinnison> pitti: but restarting it seems to help
* pitti looks
<pitti> daniels, Kinnison: I can reconstruct ubuntu4, I just need to remove four patches
<pitti> Kinnison: did it work with ubuntu4?
<pitti> Kinnison: most of the patches fix only segfaults
<Kinnison> pitti: I don't remember
<pitti> Kinnison: you can try removing the patch fix_first_hotplug.patch
<pitti> Kinnison: Shall I build you a package or do you want to build it yourself?
<Kinnison> pitti: As I said; it only manifests itself when I first boot
<Kinnison> pitti: so if I restart hal; it'll most likely work
<sjoerd> Kinnison: if you unplug your usb device, restart hal, plug it in again
<pitti> Kinnison: exactly, the mentioned patch fixes sort of a race condition
<sjoerd> Kinnison: what happens then
<pitti> Kinnison: also, does the second plug work? We had problems only with the first plug in after hal start
* Kinnison would have to reboot to answer about a second plugin before a hal restart :-(
<sjoerd> pitti: the race is still there, it's just less likely :(
<Kinnison> sjoerd: I'll try the unplug/restart/plug now
<pitti> Kinnison: you shouldn't need to reboot
<pitti> Kinnison: /etc/init.d/dbus-1 restart should do
<sjoerd> pitti: only restarting hal should be enough (then your gvm isn't dead)
<pitti> sjoerd: no, g-v-m was recently fixed to reconnect :-)
<Kinnison> Right; so if I unplug/restart/plug I get:
<sjoerd> pitti: ooooh... patch patch patch :)
<Kinnison> g-v-m notices and mounts
<Kinnison> hal-device-manager doesn't notice
<pitti> what? that's odd, never seen this
<daniels> jesus, how hard is it to do transparent png?
<pitti> there is no device and volume in hal-device-manager?
<Kinnison> pitti: indeed; but if I restart hal-device-manager it shows up
* Kinnison tries a restart of the entire dbus subsystem
<plovs_work> pitti, just to let you know, my camera now automatically opens gtkam and I get my photo's, *all* my  devices are working now! Thank!
<sjoerd> h-d-m is easily confused if hal restarts
<pitti> Kinnison: well, you must restart device manager anyway
* fabbione looks at https://bugzilla.ubuntu.com/show_bug.cgi?id=1117#c28 first lines and enjoyes :))))
<pitti> Kinnison: for me it crashes if hal is stopped
<Kinnison> pitti: so; unplug/dbus-restart/plug works okay
<pitti> Kinnison: this is indeed the "first hotplug gamble" bug
<pitti> Kinnison: neither David, nor Sjoerd, nor me found a clean solution for this
<thom> fabbione: dude, soon your head will be so big you won't fit through doors :-)
<pitti> Kinnison: it usually works from the second plug on, but the first one is still a problem sometimes
<sjoerd> pitti: no there is a ``clean'' solution, but it requires kernel support and isn't mainline yet.....
<pitti> thom: and he will soon get X-shaped legs :-)
* Kinnison will put up with the irritation then; sorry to bother you
<pitti> Kinnison: no problem, but it is good to know that there isn't yet another bug
<pitti> sjoerd: what will change?
<sjoerd> Kinnison: what happens if you start hal manually after the first boot
<sjoerd> pitti: the hotplug seqnum will be published in /sys
<daniels> fabbione: wow, bong
<pitti> sjoerd: ah, sounds nice
<sjoerd> pitti: so it's initialised correctly
<daniels> fabbione: should've CCed me on that bug
<daniels> fabbione: what was the problem?
<pitti> sjoerd: was that the reason for the uniniialized random sequence number?
* sjoerd thinks it's a hack and it should work in no matter what order events come in
<pitti> sjoerd: so if the kernel publishes the sequence number, hal can just sort them?
<Kinnison> sjoerd: how do you mean?
<fabbione> daniels: you botched the backport of the driver
<daniels> fabbione: yeah ... how?
<sjoerd> Kinnison: put a exit 0 at the start of the hal init script, reboot, start hald --daemon=no --verbose=yes
<daniels> fabbione: i'd be interested in the interdiff
<sjoerd> Kinnison: see what happens then, should be interesting
<pitti> sjoerd: I think the whole concept of partition detection in hal is somewhat flawed
<pitti> sjoerd: why the kernel can't just look at the devices exported by the kernel?
<fabbione> daniels: you added only one .h file out of several files required. and forgot to modify the Imakefile to reflect the changes..
<pitti> sjoerd: why do partition detection again?
<Kinnison> sjoerd: I'll try to remember that for my next reboot
<fabbione> thom: ahahah
<daniels> fabbione: weird, I could swear I did that
<daniels> fabbione: although if I just forgot to redo the patch in DBS, I'll kick myself
<sjoerd> pitti: hmmm, partition detection in hal isn't really a problem
<pitti> sjoerd: it was
<daniels> fabbione: oh well.  next time something like that comes up, please CC me.
<fabbione> daniels: well.. one way or the other.. stuff was missing
<daniels> fabbione: yeah
<sjoerd> pitti: yeah, because it did it differently from the kernel
<pitti> sjoerd: and I heard from David (or some other guy) that it is still hackish
<sjoerd> pitti: hal's logic behind it is weird.. the volume_id stuff is nice
<sjoerd> pitti: but as you know by now, hal's concept is great, it's code however....
<pitti> sjoerd: all these segfaults I fixed recently showed that hal does not care a s**t about checking externally acquired values ...
<pitti> sjoerd: so I expect more segfaults in the future :-(
<pitti> sjoerd: but right, the concept is nice
<pitti> sjoerd: maybe David can be convinced to rewrite the stuff in python :-)
<sjoerd> pitti: i don't think that helps
<sjoerd> pitti: you can write shitty code in any language
<pitti> sjoerd: yes, but you cannot produce segfaults so easily
<sjoerd> some parts of the design are flawed to begin with
<sjoerd> if the freebsd guys want to port hal they basically need to rewrite it :(
* fabbione wants a X-Men t-shirt
<pitti> sjoerd: so if they do, maybe they design it better
<pitti> sjoerd: the problem is that I personally only need a fraction of hal's features
<pitti> sjoerd: we only need it for detecting removable media, but hal does a thousand other things
<sjoerd> well need.. you only currently use those 
<pitti> sjoerd: OTOH, if we had devised our own hotplug agent, we would not have such nice features as gphoto camera autohandling
<fabbione> daniels: i also have a pending patch for 2111
<fabbione> daniels: want to review?
<sjoerd> pitti: hal's concept for a hw database of your system is great. but nobody is going to use it if the info they isn't at least mostly  there
<pitti> but anyway, on many systems it runs quite nicely now
<sjoerd> pitti: so currently hal is publishing a lot of info, which basically nobody uses that
<pitti> sjoerd: right. Network devices are a field that can still be exploited
<sjoerd> not only that, video device detection is in current cvs which could be used by some apps
<pitti> sjoerd: in Hoary, we also want proper device labels instead of sdasomething
<fabbione> daniels: http://people.ubuntulinux.org/~fabbione/
<pitti> sjoerd: hal's ID detection/assignment is probably good for this
<sjoerd> pitti: in sarge+1 i want al the hotplugging mounting stuff to work out of the box :)
<pitti> sjoerd: great!
<fabbione> daniels: 036 for the wacom, 991 for the savage
<sjoerd> pitti: and that includes nice mount points
<pitti> sjoerd: it would be nice if Ubuntu and Debian used the same system
<daniels> fabbione: sure, I'll review it in a sec
<fabbione>   307346 total
<pitti> sjoerd: my idea was to have g-v-m maintain a database volume id -> device name and use this as mountpoint and label
<fabbione> we are close to 310000 lines of patches for X
<pitti> sjoerd: not device name, device label
* fabbione hits his head on a wall
<sjoerd> pitti: i'm currently figuring out how svn-buildpackage works, to put debians hal and gvm under version control
<pitti> sjoerd: pmount already supports device labels, BTW
<daniels> fabbione: uh
<fabbione> it will take AGES to review them for X.org
<daniels> fabbione: don't really like 911
<pitti> sjoerd: BTW, would you consider using pmount in Debian? Instead of fstab-update?
<fabbione> daniels: what do you think is wrong?
<sjoerd> pitti: ofcourse, i'm telling everybody that i need to really look at it sometime :)
<daniels> fabbione: I would prefer that you used the first block that you commented out to do the detection
<fabbione> daniels: i moved it after the chipset probe
<daniels> so, set the default according to which chipset it is
<pitti> sjoerd: well, I would maintain it for both Ubuntu and Debian
<sjoerd> pitti: not changing fstab with al it's problems is a big plus 
<daniels> fabbione: oh, there's a chipset probe in between there. bong.
<pitti> sjoerd: but it makes no sense to put it in Debian if nothing uses it
<fabbione> daniels: i need to have the pciId stuff
<fabbione> daniels: otherwise it's the same
<daniels> fabbione: ok, I'm happy with that
<pitti> sjoerd: the other big plus is hal-running-as-user
<fabbione> daniels: yes, but i still want a user test
<fabbione> daniels: do you have a normal savage to test on?
<daniels> fabbione: could you please give me an interdiff between the original #036 and the new one?
<sjoerd> pitti: i don't really find hal running as user very usefull currently, but my view is somewhat different
<daniels> fabbione: maybe, but it's still packed away; I can test later on tonight
<fabbione> daniels: nope.. i fried away the old 036
<sjoerd> pitti: although i've got the design in my head to make hal run mostly as user, while still doing everything
<fabbione> daniels: the old 036 was adding xf86wacom.h and that's it
<pitti> sjoerd: what's wrong with hal in Ubuntu? It works fine
<fabbione> daniels: there was nothing more than that
<sjoerd> pitti: don't know if i've got the time to code it
<pitti> sjoerd: the only real reason to run hal as root were the callout scripts
<pitti> sjoerd: like fstab-update
<sjoerd> pitti: i know, for the stuff ubuntu uses it it's great
<pitti> sjoerd: but we want to keep hal policy free, so we do not want that anyway
<sjoerd> pitti: don't forget filesystem label reading
<pitti> sjoerd: hal can read plugdev devices
<sjoerd> pitti: yes, but not the ones on my harddisk
<pitti> sjoerd: just not fixed disk partitions, but we do not want hal to be able to mess them up
<pitti> sjoerd: you can put hal into 'disk', but that is equivalent to root
<pitti> sjoerd: actually we need a read-only 'disk' group
<sjoerd> pitti: yes, that's why i say that i find running hal as user useless :)
<pitti> sjoerd: in Hoary we will probably solve that with mandatory access control
<daniels> fabbione: sorry, but the only S3 cards I have are early Trios, and a Virge
<sjoerd> pitti: when using gnome-vfs with hal it's really nice to get your filesystem labels read
<sjoerd> pitti: so my os X partitions shows ``OS X volume'' instead of idedisk1 ;)
<pitti> sjoerd: if I look at the many segfaults and stack corruptions of hal, I won't ever allow hal to run as root
<daniels> what I do have here is Cirrus, Tseng, i740, r200, Voodoo (probably Voodoo2?), GeForce2, soon a Number9 card, and a G400
<daniels> and the i855 in here
<sjoerd> pitti: the design in my head has only a bare minimum of hal code running as root and the others as user
<pitti> sjoerd: as I said, in a MAC system we could allow read-only access to disks
<pitti> sjoerd: this sounds better
<ross> ooh, my ipod's volume is labelled "ross' ipod"
<pitti> sjoerd: so you have two hald processes then?
* ross labels partitions
<sjoerd> pitti: yes, split one off before dropping prives
<pitti> ross: pmount /dev/sda2 "ross' ipod" :-)
<sjoerd> pitti: with communition though a pipeline.. to do request like ``read this devices label''
<ross> pitti: sweet
<ross> e2label works on mounted filesystems, right?
<pitti> ross: pmount support is ready, we just need g-v-m support for this
<pitti> ross: I don't know
<sjoerd> pitti: do you want to do it in gvm or some other layer ?
<sjoerd> for debian i think another layer is nicer, so k-v-m could use it too
<pitti> sjoerd: actually I would have liked to do all this magic in a DE agnostic layer
<pitti> sjoerd: so I could even benefit from it in fvwm or the command line
<pitti> sjoerd: but in Ubuntu, I think g-v-m is the right place
<ross> pitti: hal needs to monitor the filesystems for label changes ;)
<pitti> sjoerd: the database can be DE agnostic, just the invocation must be rewritten for KDE etc.
<pitti> ross: good catch, I will ask upstream about that
<sjoerd> pitti: you know that rml plans to changes g-v-m's design completely
<pitti> ross: OTOH, it's difficult to detect
<sjoerd> ross: that would mean polling for now
<sjoerd> when/if the kernel gets the extra event stuff via netlink it should be easy though
<sjoerd> thatis if the kernel itself knows the volume has changed
<pitti> sjoerd: oh, then it might be worth discussing that with him
<pitti> sjoerd: if g-v-m supported device labeling upstream, this would be nice
<ross> yeah, i can see it being a pita
<pitti> ross: I think it would be enough to read the label on plugin
<pitti> ross: (which is done anyway)
<sjoerd> pitti: let's see if i can find the mail
<pitti> ross: so a unplug/replug would suffice
<pitti> brb
<sjoerd> pitti: Message-Id: <1095697479.3666.16.camel@betsy.boston.ximian.com>
<sjoerd> pitti: on gnome's utopia-list
<pitti> sjoerd: thanks, I will look at it
<pitti> sjoerd: damn, the mail archives don't recognize the Message-Id as search term
<ross> pitti: unplug/replug doesn't work on / :)
<pitti> ross: it's tricky :-)
<pitti> ross: well, unplug certainly works :-)
<pitti> sjoerd: any idea how I can search for a message id?
<sjoerd> hmmm no ;)
<sjoerd> Date: Mon, 20 Sep 2004 12:24:39 -0400
<sjoerd> should be easier if it's not in your mailbox :)
<pitti> sjoerd: thx
<sjoerd> pitti: i'm planning to create an alioth project, to do hal and g-v-m's maintaince under version control and probably an utopia discussion list
<sjoerd> pitti: do you feel like eventually discussing these ideas on a list there ?
<pitti> sjoerd: of course
<pitti> sjoerd: just read the mail, in fact I already saw it in my mbox
<pitti> sjoerd: I like the notification area plan, we urgently need this anyway
<pitti> sjoerd: a small icon in the panel which allows to unmount devices
<sjoerd> a sort of eject icon or something..
<daniels> fabbione: sorry, little sister was demanding a story
<pitti> sjoerd: right
<pitti> sjoerd: https://bugzilla.ubuntulinux.org/show_bug.cgi?id=980
<ross> hm, why doesn't my ipod disk appear as a removable device in hal?
<pitti> ross: hmm, it should
<pitti> ross: works fine for carlos and other guys
<ross> pitti: well, i can't see a "removable" key in the hal device manager
<pitti> ross: oh that. Just ignore it.
<pitti> ross: this key has never worked for me correctly
<pitti> ross: but is it automatically mounted and such?
<ross> yeah
* pitti is relieved
<ross> pitta: but i can't unplug it without manually ejecting in a terminal
<pitti> ross: this thing again...
<pitti> ross: what happens with unmount in the context menu?
<sjoerd> pitti: i don't know how exacly ubuntu handles drives
<sjoerd> pitti: their not on the desktop are they ?
<ross> pitta: it unmounts, but the ipod wants to be ejected
<pitti> sjoerd: we reenabled the desktop icons shortly before the preview
<pitti> sjoerd: since we needed an easier way to unmount than the "Disks" window
<ross> ah the ipod device itself is removable
<pitti> ross: oh yes, the ipod still thinks it's connected. Same problem as with Carlos
<pitti> ross: however, it it safe to unplug it
<pitti> ross: you can also unload the spb2 module
<ross> silly me was looking at the partition node
<ross> pitti: really nautilus needs unmount and eject entries
<pitti> ross: right. Would that be easy to implement, I would have done it long ago
<ross> (in the device context menu)
<ross> ha
<pitti> ross: the problem is that this would involve a fair amount of new code
<pitti> ross: actually there is only one option and a low level determines whether to unmount or eject
<ross> i was hoping the gnome-vfs+hal code would make it easy
<pitti> ross: the problem is not the backend stuff, but the user interface
<pitti> ross: actually we should use eject for all removable media; it works fine for usb sticks
<pitti> ross: so maybe it is just a matter of calling eject unconditionally
<ross> i'm tempted to write a nautilus-python plugin which looks up the mount point in hal and adds an eject entry
<pitti> ross: if we can convince Matt to allow the "always eject" change in gnome-vfs, we would be done with it
<pitti> ross: I will prepare an updated package and have it reviewed by seb128, mdz and you. What about this?
<sjoerd> pitti: the big problem with device eject/umount stuff it to get the user to actually do it...
<sjoerd> pitti: most people are used to just pulling usb sticks out
<pitti> sjoerd: well, hal will lazily unmount removed devices, that's not the problem
<sjoerd> pitti: yeah i know
<ross> pitti: you mean call eject on unmount?
<pitti> sjoerd: the real problem with this approach is https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1959
<pitti> ross: yes
<pitti> ross: this works even better than just unmounting with my usb stick
<pitti> ross: the device is actually shut down, the LED goes off
<sjoerd> pitti: autch
<pitti> sjoerd: yes, I told everybody proudly that you can just rip off devices in Ubuntu, and then this report came
<sjoerd> pitti: but i mean the problem is getting people to understand that umount manually first is really the right way
<sjoerd> apple stuff does that nicely by putting a warning on the device
<pitti> sjoerd: see ross' problem
<sjoerd> yes
<pitti> ross: can you please file a bug report about this? Then I have a place to send a patch to
<pitti> ross: I have a minimal patch ready (just changes a FALSE to TRUE)
<ross> k
<ross> pitti: what component? nautilus?
<pitti> ross: gnome-vfs2
<pitti> ross: just assign it straight to me (martin.pitt@canonical.com)
<ross> pitti: #2134
<pitti> ross: thanks!
<daniels> fabbione: dude
<daniels> fabbione: look in the patches in people.ubuntu.com/~daniels/xorg/
<daniels> fabbione: i've already done the X11R6 migration :)
<daniels> there are a few patches in there related to it
<fabbione> daniels: i know that.
<daniels> fabbione: ah, ok
<daniels> fabbione: just making sure :) you have to change the man dir and stuff, iirc
<fabbione> daniels: yup...
<fabbione> wartylog:
<fabbione> Start killing X11R6.
<fabbione> s/warty/
<fabbione> ^^ --->> start <<---
<daniels> yeah :)(
<daniels> just making sure
<fabbione> daniels: i need to play around to understand more stuff
<fabbione> daniels: and see how things interact with each other
<fabbione> daniels: it's not only question of grabbing a patch here and one there
<daniels> fabbione: yeah, fair enough
<daniels> fabbione: if you ever need a hand, give me a yell, because I got it pretty much all worked out
<daniels> took a while
<fabbione> daniels: ain't my fault if you slow :P
<fabbione> daniels: but i have your patches.
<fabbione> i want to use them as last resource if i don't get a clue
<daniels> fabbione: heh heh, I've already done it, buddy; where are your packages? :P
<thom> oh man. fedora core 3 has gtk filechooser patches for firefox
<thom> they're so sexy
<fabbione> daniels: where are yours? do they work? do they actually install?
<fabbione> daniels: no.. sorry.. do they actually exists?
<fabbione> ;)
<pitti> ross: new package is available, see bug 
<fabbione> thom: argh... include them :-)
<pitti> ross: I would greatly appreciate some testing :-)
<thom> tempting, but i might get killed
<fabbione> thom: where is that SECURITY updated to the gtk filechooser in firefox?
<fabbione> thom: you forgot to add it last upload!
<ross> pitti: sure
<thom> heh
<thom> what the heck is tr_TR ?
<pitti> thom: Turkish?
<Mithrandir> turkey?
<thom> yeah, i guess so
<daniels> fabbione: haha
<daniels> fabbione: they're on my desktop (well, my portable hard drive)
<daniels> fabbione: they're not *entirely* complete, but they work fine with just fd.o xlibs + xorg
<daniels> they were running on mdz's laptop for a while
<daniels> fabbione: i'll go somewhere where I can upload all the source packages (probably uni) tomorrow and throw them up on fooishbar
<daniels> fabbione: they're not entirely complete in terms of separating the .orig.tar.gz and stuff and retargeting to warty, but they're a very good base imo
<daniels> fabbione: remember how mdz kept stalking around looking for me until I unbroke his laptop at Oxford? :)
<fabbione> daniels: are they printed on paper or something that they lay on your desktop? ;)
<fabbione> daniels: no because i was too busy fixing other stuff breaking on xfree86
<daniels> fabbione: heh heh. they're on my portable hard drive, which is connected to my desktop right now.
<daniels> fabbione: oh, fair enough
<daniels> fabbione: but stuff like xresprobe needs to be probed
<fabbione> daniels: pkgnum is going to be ... hmmm.. high :-)
<fabbione> daniels: i wonder if elmo will hunt me down
<daniels> fabbione: yeah, last I saw it was up to about 52 source packages
<daniels> i think
<daniels> yeah
<fabbione> daniels: yes.. that's YOUR split...
<fabbione> daniels: mine start with 1 source -> 171 packages -> 171 source packages -> N binary packages
<daniels> !!!
<fabbione> but 171 is a virtual number
<daniels> i think elmo just booked a flight to Copenhagen
<Mithrandir> fabbione: don't scare us that much.
<fabbione> since it needs to be stripped of all the crap
<fabbione> Mithrandir: i am not kidding
<fabbione> i am going to reduce X.org in small little tiny packages
<fabbione> a lot of them
<Mithrandir> one package per file :)
<fabbione> daniels: for ex: xorg/xc/libs/zlib <- we can kill this one
<fabbione> daniels: there are plenty like that one
<fabbione> Mithrandir: almost ;)
<daniels> fabbione: yeah
<daniels> fabbione: we can kill a fair few things in programs as well
<daniels> not to mention a lot of ancient libs
<fabbione> daniels: exactly
<daniels> tell me you're not building a pex5 source package :P
<fabbione> daniels: check my commits
<fabbione> daniels: right now i am only building one package
<fabbione> daniels: so i mean.. it's not like i am going to build much atm
<daniels> fabbione: yeah, I'm watching your commits roll in to debian-x
<daniels> it's been a long time since I've checked out any part of the XSF SVN repo
<fabbione> daniels: as soon as warty is out i will put up .orig.tar.gz
<daniels> fabbione: i think we should co-ordinate a little more on this
<fabbione> right now i am working on it only in my (almost inexistent) spare time
<daniels> fabbione: because we've got two pretty diverse sets of packages here, so putting out an .orig.tar.gz might be a little hasty ... they tend to stick around
<fabbione> daniels: it's not like they can do anything with it
<fabbione> daniels: it doesn't build any binary
<fabbione> daniels: it's the *-source-* stuff
<fabbione> daniels: that is nothing more than grabbing X11R6 from freedesktop :-)
<daniels> mmm, if you want to
<daniels> if you're going to do that, if you at least grab the xorg-6.8.1.tar.gz (or whatever kem renamed that to -- probably X11R6.8.1-src.tar.gz) from ~xorg/X11R6.8.1/src-single/
<fabbione> i did already
<fabbione> that's the one i am using
<fabbione> but it still needs to be sanitized
<fabbione> there are the non-free code that we want to get rid of
<daniels> ah, rad
<daniels> yeah, mainly fonts
<daniels> the autoconfig stuff is fine, remember
<fabbione> dude...
<daniels> it's basically stuff which is non-dfsg-free -- there's no XFree86 1.1 code
<daniels> yeah?
<fabbione> read debian-x :-)
<ross> pitti: so far so good with new gnome-vfs. it ejected the ipod as expected
<fabbione> daniels: -r19
<pitti> ross: nice to hear, thanks! :-) Can I quote you on a bug followup
<fabbione> daniels: and thread
<pitti> ross: ?
<ross> sure
<tseng> ross: hmm, does the ipod realize its been unmounted also?
<ross> tseng: yes, that what was good
<tseng> hm neat
<tseng> :D
<daniels> fabbione: oh right, I just saw Roland waffling about some crap about Xprint and sort of tuned out
<ross> pitti: would be nice if in the end nautilus knew if the device was ejectable, like it does with cdroms
<fabbione> daniels: i am off for a little while
<fabbione> daniels: try to test the savage driver if you can
<daniels> fabbione: take cure dude :)
<fabbione> daniels: kinda asap :-)
<daniels> fabbione: i have no savages, sorry, but I'll try to find someone with one
<daniels> fabbione: heh yeha
<daniels> also, 'yeah'
<pitti> ross: Well, actually an iPod cannot be "ejected"; it will not be spat out of the firewire plug AFAIK :-)
<fabbione> daniels: you said you have one in a box
<fabbione> daniels: find it and plug it
<fabbione> ;)
<pitti> ross: so I think the current term "unmounting" is better
<fabbione> or ask on #ubuntu or something
<azeem> how about 'Remove device'?
<azeem> 'unmounting' sounds quite techy
<daniels> fabbione: i said I probably did, then I realised it was only Virge and old Trios
<pitti> azeem: remove from your desk?
<ross> pitti: hm. problem is that ipods are "removable", whereas an external jazz drive is actually removable. in HAL they'll both appear as removable
<pitti> ross: you mean the ZIP and cd-roms are ejectable?
<ross> cd-roms are from nautilus, zip should be
<pitti> ross: right, this probably requires HAL support
* sjoerd notes that os X calls both umount en eject, eject
<tseng> my old usb zip drive actually rockets disks at me ocassionally
<tseng> its humorous.
<pitti> tseng: but ZIP drives can actually be ejected
<tseng> yep.
<pitti> but there's nothing to eject on an iPod (at least I would not want it to :-) )
<tseng> itunes does call it "ejecting" the ipod however
<pitti> hmm. The German translation is far better
<azeem> ok, so what about 'disconnect'?
<pitti> sounds much better
<pitti> jdub: can you please take a look at #2135 (and approve, if appropriate)?
<thom> jdub: the firefox crasher was reported upstream on the 3rd of august :(
<jdub> thom: good lord
<jdub> pitti: approved (and commented)
<thom> jdub: we also have basically no translations available for 1.0
<pitti> jdub: thanks, uploaded
<jdub> thom: do you have a landline?
<thom> jdub: wait one
<jdub> (thom is stringing up some tin cans and string to the overhead cables AS WE SPEAK)
<thom> pretty much
<thom> it does mean finding the phone :-)
<tseng> the first trans-pacific tin can conversation
<jdub> tseng: the ISS is just one big tin can, dude ;)
<tseng> hmz
<ross> yo yo jdub
<tseng> hey ross, ive been thinking about a stupid "feature" on s-juicer if youd entertain
<tseng> seems to be an unpopular idea, but i encode both flac + mp3 ... i have a home theater box and an ipod. totem wants to rip the cd twice instead of encode the tracks twice
<tseng> jdub: someone is working on packaging beagle/dashboard now :)
<ross> tseng: i doubt i'll implement multiple encoding formats
<ross> you could hack it with a weird profile in sj-profiles-branch
<tseng> hm
<jdub> tseng: rock :)
* thom happydances
<jdub> tseng: so we really should get your mono stuff into universe
<jdub> pants off ross
<tseng> hm, for warty?
<jdub> ross: 0.9 is in :-)
<jdub> tseng: sure
<tseng> hm ok
<jdub> tseng: how much of it is different to sid versions now?
<tseng> monodevelop only
<ross> jdub: so i heard, pants off!
<tseng> which i need to poke here again, missing deps
<ross> jdub: did you get my app install mail?
<jdub> ross: been travelling for a couple of days, so will get to it soon ;)
<tseng> oh and tomboy still isnt in sid afaik
<ross> jdub: ok. good time?
<jdub> ross: lovely. did an ubuntu presentation in daniels's home town.
<ross> jdub: sweet.  i just plugged ubuntu to a techie doing due diligence here
<jdub> ross: put up embarrassing pictures of him, pipka and bob2 up on the big screen etc. ;)
<daniels> jdub: sorry about the state of the house, btw
<ross> ha
<tseng> jdub: there is a very minor bug also in my monodevelop (upstream as well) ... missing some file for nermle template, warning issued on New
<daniels> jdub: we were all pretty much out for everything but dinner for the last week; particularly me, as I'd get home, and need to clear a day's worth of work after that
<jdub> daniels: i didn't find any WMD, so i'm not too fussed.
<tseng> but I think in universe that isnt a real blocker
<daniels> jdub: heh
<daniels> jdub: or catch cooties
<jdub> daniels: in communist ivanhoe, the cooties catch you.
<daniels> jdub: ahr, I am the cootie monster
<ross> should totem in ubuntu be able to play the fluendo stream?
<tseng> seb just posted new gst* and totem packages this morning if that helps
<ross> hm, good point. i'm, using totem-xine atm
<tseng>  deb http://people.ubuntulinux.org/~seb128/gstreamer/  /
<tseng> the fluendo guys have been working like mad lately.
<ross> yeah
<jdub> oh good
* sjoerd wonders if ubuntu and debian will be able to ship gst-ffmpeg
<jdub> ross: totem+gstreamer in ubuntu should be able to play the fluendo stream now
<jdub> now like, "already" not "as of just now"
<seb128> no
<seb128> current version is bugged
<jdub> seb128: oh
<seb128> I've asked if I should apply the patch to gstreamer and you said it's not a priority so no
* jdub installs seb's :)
<pitti> seb128: I tried the new packages; mpeg2 decoding got a slight bit better, but is still unusable; totem crashed after closing it
<pitti> Hi carlos!
<carlos> pitti: my hero!!
<carlos> :-P
<pitti> carlos: Can I bother you to take a look at #2134?
<seb128> if we don't have regression I'm all for using the new packages
* thom stops looking at firefox's download mangler
<carlos> let me see it
<pitti> carlos: your iPod should finally unmount fine with this
<jdub> seb128: i thought i said "because the new releases with BBB's hacking love will be out soon anyway"?
<carlos> pitti: oohh, that one
<carlos> pitti: I answered it already :-P
<carlos> that's why you are my hero :-)
<pitti> carlos: oh, I did not notice. Thanks
<seb128> jdub: no no, you just said it was not a priority :)
<seb128> it was like 3 weeks ago
<Kamion> sabdfl: there's already a bug for that; suffice to say there was a rationale for the behaviour I chose and it wasn't a mistake for Debian (long story, basically the config options were shuffled by upstream and *then* the PasswordAuthentication default was changed by me, which confused things muchly), but it's not appropriate for Ubuntu and I'll be changing it
<pitti> carlos: I feel honored :-)
<ross> seb128: totem from that source is hanging
<ross> seb128: i think its a HAL problem
* Kamion managed a complete start-to-finish Hebrew install on the train
<tseng> jdub: btw, is there an env i can set so that dch gets my proper email?
<Kamion> with only a little hacking
<seb128> ross: hum ... totem uses hal ?
<Kamion> jdub: how scared will you be if I tell you that we need to drag jfbterm into warty?
<daniels> Kamion: ?!?
<ross> seb128: the bacon stuff will if its around
<ross> seb128: call yourself a packager? ;)
<jdub> Kamion: first, i will be pensive, and raise my eyebrows.
<Kamion> thought so
<carlos> pitti: you are doing a good work about removable devices in Ubuntu that are really good for normal users and we will be the first with those features :-P
<Kamion> needed for certain languages, I'm afraid
<ross> seb128: well, i think that is what is happening anywya
<Kamion> otherwise they won't be able to read the text in base-config at all
<jdub> Kamion: which ones?
<pitti> carlos: do you happen to have any other USB devices to test it with?
<daniels> jdub: presumably chinese and japanese
* seb128 slaps ross 
<Kamion> CJK
<daniels> ah, also Korean
<daniels> cjk
<ross> seb128: watch:
<ross> $ totem
<ross> libhal.c 2213 : Error sending msg: Service "org.freedesktop.Hal" does not exist
<ross> see
* ross slaps seb128 back
<daniels> ross: cool!!
<Kamion> and possibly a few random stragglers where the Linux console doesn't do their UTF-8 well
<carlos> pitti: yes, let me look for my syster's usb pen
<daniels> ross: is HAL running?
<Kamion> we get away without it for Hebrew apparently; haven't tested Farsi yet although we're probably missing most of the d-i translations for that anyway
<ross> daniels: it got upgraded so probably not
<jdub> Kamion: this won't matter so much when we're-- yeah -> utf-8 impact?
<pitti> carlos: beware, now it is ejected; after unmounting, it will stick in your eyes :-)
<seb128> ross: $ grep -i hal totem-0.99.17/configure.in
<seb128> $
<Kamion> jdub: hmm?
<ross> seb128: fun.
<jdub> Kamion: when we switch to utf-8 for hoary, what will we use?
<Kamion> jdub: base-config actually tries to use it even for UTF-8; apparently it does a better job than the console for some languages
<seb128> ross: isn't it ? :)
<Kamion> however turning on the framebuffer is *probably* enough for most people
<carlos> pitti: it's not mounted automatically...
<ross> seb128: now i am getting confused
<Kamion> I'll fix up Greek and Hebrew now
<pitti> carlos: hmm. What does the device manager say?
<carlos> and dmesg shows me it
<pitti> carlos: BTW, this can't have anything to do with my gnome-vfs changes
<carlos> I know 
<pitti> carlos: does device manager show a volume for it?
<carlos> I saw the patch
<carlos> which one was the command?
<ross> seb128: aha, maybe its gnome-vfs?
<pitti> carlos: hal-device-manager
<pitti> carlos: should also be in the menu
<pitti> carlos: unless you did not install the package hal-device-manager
<carlos> seems like it's not installed
<seb128> ross: the hal supported is turned off in warty
<seb128> for gnome-vfs
<ross> ross: i bet pitta turned it on for his ipod fixing gnomevfs
<seb128> ross: oh, that's nautilus-cd-burner 
<seb128> * Use CD selection widget from nautilus-cd-burner, instead of our copy
<seb128> for totem
<ross> ah ok
<seb128> and n-c-b has the hal support on
<carlos> pitti: Could not get device list. Make sure hald is running!
<ross> fune
<ross> i must restart i guess
<carlos> seems like hald died
<tseng> hald is good at that
<pitti> carlos: so your hal does not run. /etc/init.d/dbus-1 restart
<carlos> but It was running becuase the iPod was mounted automatically
* pitti sighs
<carlos> hmm
<carlos> pitti: it's running
<carlos> hal       3196  0.0  0.7  7616 5644 ?        Ds   15:02   0:02 /usr/sbin/hald --drop-privileges
<pitti> carlos: just because you restarted it or was it running before?
<ross> carlos: i've got one of those! Ds is bad
<fabbione> daniels: the savage patch seems to work
<daniels> fabbione: awesome.  did you find someone to test?
<carlos> pitti: it was running before
<ross> pitti: me too
<pitti> carlos: so you just cannot communiate with hal any more? Try lshal
<fabbione> daniels: the submitter :-)
<daniels> fabbione: ah, rad :)
<ross> pitta: "Service "org.freedesktop.Hal" does not exist"
<carlos> pitti: no, it hangs
<daniels> ross: 'pitti'
<daniels> ross: as in, da fool
<ross> doh
<ross> i'm hungry ;)
<carlos> carlos@frodo /var/log $ lshal
<carlos> lshal version 0.2.98
<carlos> libhal.c 696 : org.freedesktop.DBus.Error.NoReply raised
<carlos> "Message did not receive a reply"
<carlos> *** [DIE]  lshal.c:dump_devices():70 : Couldn't obtain list of devices
<pitti> what the hell...
<pitti> ross,carlos: can you please restart dbus-1 and see whether this is reproducible?
<daniels> hal is totally shot
<sjoerd> pitti: if hald is in D state your screwed
<daniels> s/hal/&d/
<pitti> sjoerd: right
<pitti> didn't notice that
<carlos> pitti: after restarting dbus I get:
<pitti> carlos,ross: so I guess you have to reboot
<daniels> oh wow, hald in D
<carlos> carlos@frodo /var/log $ lshal
<carlos> lshal version 0.2.98
<carlos> libhal.c 696 : org.freedesktop.DBus.Error.ServiceDoesNotExist raised
<carlos> "Service "org.freedesktop.Hal" does not exist"
<carlos> *** [DIE]  lshal.c:dump_devices():70 : Couldn't obtain list of devices
<ross> pitti: this is the 3rd time i've got hald in D after upgrading
<pitti> daniels: if I had a penny for every time... nevermind
<daniels> ross: probably trying to read from a non-existant device
<daniels> huzzah.
<sjoerd> the only times i've seen hald in D state it where hardware issues
<carlos> wow hald does not die
<daniels> yeah, same
<ross> ooh mine died!
<daniels> carlos: yeah, it's in D, which means it's waiting on the kernel
<daniels> ross: woo!
<ross> hm
<ross> now lshal hangs instead
<carlos> ross: :-P
<daniels> ross: if you can get debugging up the hizzle, knowing just what it's doing might be nice
<sjoerd> ross: does dmesg show strange things ?
<daniels> ross: yay! has hald gone back into D?
<ross> and its back in Ds
* carlos reboots
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 12 RC bugs to go
<daniels> ross: yeah, that's what I thought
<sjoerd> ross:  ls -l /proc/$(pidof hald)/fd 
<ross> hm, i blame the ipod
<sjoerd> ross: what device files does it have open 
<ross> sjoerd: null, null, null and null
<pitti> @all: this might be because devices are now ejected, which means to power them down
<ross> sjoerd: some pipes, 2 sockets and the pci id files
<pitti> so it may take forever to open the device
<ross> blocking in scsi_wait_req says wchan
<ross> i'm totally blaming a powered-down but connected ipod
<pitti> ross: try to stick your iPod back in
<daniels> ross: urgh
<pitti> ross: no, that won't help, it will get a new device node
<sjoerd> hmm why are the pci id's files still open..
* sjoerd fixes another fd leak in hal
<ross> go sjoerd
<pitti> odd, works for me
<sjoerd> could be a ieee1394 bug
<pitti> sjoerd: probably; carlos already told me about some module unloading magic
<pitti> sjoerd: but this should not hang hal
<sjoerd> pitti: imho the kernel should say, dead device, -EINVAL or something
<sjoerd> your process should stay in D so long because you open() or something like that
<pitti> sjoerd: yes, I saw this on an user with a faulty CD rom drive
<sjoerd> pitti: my own cdrom drive is quite nasty during bootup, causing hald to stay in D for some time (untill the kernel shuts off dma for it)..
* pitti curses at hal loudly
<sjoerd> hehe
<pitti> So I guess we have to revoke the eject patch for now
<sjoerd> i don't think their is a way to work around this
<pitti> carlos: Hi! Back?
<pitti> sjoerd: well, open() should have a timeout
<carlos> pitti: hi
<pitti> sjoerd: or even better, should fail immediately
<pitti> carlos: we just discussed that you are lost. Your computer was destroyed completely, go and buy a new one
<pitti> carlos: just kidding
<carlos> pitti: :-P
<thom> jdub: mail away
<pitti> carlos: we probably have to revoke the patch because the kernel stinks
<carlos> pitti: I was calling to Apple, I'm having problems with my iPod battery
<pitti> carlos: it hangs forever on opening a non-existing device
<carlos> btw, it works with the pen drive
<sjoerd> pitti: you can open with O_NONBLOCK.. 
<pitti> Interestingly, this does not crash on USB
<pitti> sjoerd: does this also apply to open() itself?
<pitti> sjoerd: I thought it only was meaningful to further read() calls
<sjoerd> from the manpage: Neither the  open  nor  any subsequent operations on the file descriptor which is returned will cause the calling process to  wait.
<carlos> pitti: also, If I boot with the iPod connected, it's not mounted :-(
<sjoerd> but i think it's non-trivial to patch hal for that 
<pitti> carlos: https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1499
<pitti> sjoerd: are there so many places which open a device?
<carlos> carlos@frodo ~ $ eject /dev/sda
<carlos> pitti: that's the problem
<carlos> eject hangs
<carlos> with the iPod
<pitti> ah, THIS is the hanging problem
<pitti> there was a bug about that recently, but it was closed again
<carlos> pitti: I'm not using latest kernel
<ross> AHA
<carlos> need to execute a dist-upgrade 
<carlos> so perhaps that's the problem
<ross> carlos: that is the bug i had last week
<pitti> carlos: if you can reproduce the hanging problem, I would like to patch eject with O_NONBLOCK and let you test it
<sjoerd> pitti: on my friends G5 the daily snapshot cd's give the same error:  
<sjoerd> christian: https://bugzilla.ubuntu.com/show_bug.cgi?id=2137
<carlos> pitti: sure
<carlos> pitti: but could we do it later?, give me the URL and I will work on it tonight, I just started to work today and I have lots of things to do...
<sjoerd> pitti: more problamatic that hal's logic works synchronous everywhere 
<pitti> carlos: sure, I just provide a new package and put it on my webserver
<carlos> pitti: perfect
<carlos> I will reboot now to "fix" the hang
<pitti> carlos, ross: I reopen the eject bug
<carlos> pitti: perfect
<pitti> carlos,ross,sjoerd: bad news. eject() already uses O_NONBLOCK
<sjoerd> pitti: i assume your on the hal@fd.o list 
<pitti> sjoerd: yes
<sjoerd> k
<pitti> sjoerd: just saw your patch
<pitti> sjoerd: will it help to fix these hangings?
<sjoerd> that's fast i send it about 10 seconds ago
<sjoerd> pitti: no, it just plugs an innocent fd leak
<tseng> i have an ipod to play with if anyone needs more test
<pitti> throw it away
<pitti> no, please don't
<pitti> throw hal away
<tseng> no i use it every day
<tseng> its nice.
<sjoerd> if you throw it away, throw it in this direction :)
<tseng> except for not using OGG
<tseng> which is suck.
<ross> tseng: join the gang and send a complain to apple
<pitti> tseng: isn't there any hacker out there with updated firmware?
<tseng> i think when it first came out there were some guys that installed ucLinux on it
<tseng> ive never seen any real clean solution
<tseng> its very proprietary all around
<daniels> the interesting thing with decoding Ogg on iPod is that they only ever got it to ~90% realtime
<daniels> when the Vorbis guys claim Tremor should be able to do 100%, even in pure integer mode
<tseng> so whats that make for, a little pause between tracks?
<daniels> assuming you pre-buffer the entire thing to PCM
<pitti> sjoerd: I cannot find any other open() option for us. Once you do the open(), the process hangs forever without any signal being able to recover it
<daniels> you'd need a 10% track length pause just between the tracks, assuming you could manage to decode the entire thing to PCM and store it
<daniels> not to mention spinning up the hard drive, access, streaming the file, et al
<tseng> =/
<daniels> (decoding to PCM being non-trivial -- you'd need something like ~60MB of solid state for most tracks)
<sjoerd> pitti: that's not easily fixed then...
<pitti> sjoerd: no, it's a kernel bug.
<sjoerd> pitti: exactly 
<sjoerd> pitti: although it would be nice if hald worked somewhat less async
<pitti> sjoerd: indeed.
<sjoerd> uhm somewhat less sync or somewhat more async :) 
<pitti> sjoerd: but regardless of how it works, if a single open() on the wrong device kills it, you are lost anyway
<sjoerd> pitti: yes that's what i said earlier :)
* pitti goes to kill the new gnome-vfs2 packages from his unofficial archive
<Kamion> so; any objections to me changing the default Hebrew locale to he_IL.UTF-8? it works for me.
<Kamion> I think the same might be needed for Arabic (ar_EG.UTF-8) too; checking
<seb128> jdub, mdz: ok to upload eagle-usb instead of eagle-adsl ? We already have the kernel module from eagle-usb, we should have the user tools in sync, I've forgotten to do this before ...
<zepo__> hi everybody...someone has installed Ubuntu on Acer travelmate laptop,coz i've problem
<zepo__> or tell me something about, tnx
<fabbione> zepo__: these questions should go to #ubuntu. please see /topic
<zepo__> ah ok... i've seen in the ubuntu homepage : http://www.ubuntulinux.org/community/teams/laptop/view?searchterm=laptop
<zepo__> and nobody can help me on #ubuntu
<zepo__> am i wrong?
<thom> zepo__: check http://wiki.ubuntulinux.org/HardwareSupport
<zepo__> tnx
<carlos> pitti: could we add to #2134 a dependency to #1891 ?
<pitti> carlos: good idea
<carlos> pitti: thanks
<tseng> mono fans: considering tweaking muine package to use gstreamer rather than xine.. thoughts?
<carlos> tseng: gstreamer for sound works really good
<tseng> yep.
* carlos does not use muine
<tseng> the debian sid pkg defaults to xine atm
<Kamion> wow, something is really screwed with Arabic
<Kamion> (d-i)
<Kamion> the translations for partman are sufficiently broken to make the mount point selector fall over and refuse to allow anything but /
<daniels> Kamion: ... impressive
<Kamion> I don't believe I've ever seen that before ...
<Kamion> daniels: hey, you look like a volunteer ... :)
<Kamion> there's also something weird with the countrychooser shortlist generation for Arabic, not sure about that yet
<daniels> Kamion: how much arseclownery is required to build a netinst?
<Kamion> for warty?
<Kamion> theoretically not too much, debian-cd has support, you set INSTALLER_CD=2 or some such; but I've never actually tried it for warty
<Kamion> partly 'cos Mark wanted the Only One CD approach
<Kamion> I was vaguely thinking about chucking out a totally unofficial netinst for hoary
<fabbione> Kamion: netinst ?
<fabbione> we have netinst, don't we?
<Kamion> daniels: the debian-cd tarball I'm using is at http://cdimage.ubuntulinux.org/code/
<fabbione> or are we talking about 2 different netinst?
<Kamion> fabbione: no, netinst = CD with installer and base system only
<Kamion> you're thinking of netboot
<Kamion> netinst is badly misnamed really
<daniels> oh, netboot, sorry
<daniels> something I can install my X40 with :)
<fabbione> Kamion: ok :-) isn't that the miniiso in netinstall dir on the mirror?
<Kamion> daniels: aha! we have netboot, look in install/netboot/ on CD images
<fabbione> daniels: we have netboot punk
<Kamion> or /dists/warty/main/daily-installer-i386/netboot/ I think
<daniels> Kamion: right ... so no buggery required with debian-cd?
<Kamion> nope
<Kamion> businesscard would actually be more useful to produce than netinst; that's a CD with just all the udebs on it, fetches base system etc. from network
<daniels> Kamion: cool
<fabbione> Kamion: we can expand the mini.iso
<Kamion> but we have the netboot mini.iso for most of that kind of use case I guess
<Kamion> fabbione: nooooooooo
<daniels> Kamion: hm
* fabbione was joking :-)
<Kamion> fabbione: upstream totally vetoed that :)
<daniels> Kamion: would it be possible to just netboot the standard cd? :)
<Kamion> daniels: 'fraid not, the CD doesn't actually have enough udebs to support netboot; there's a bug about it
<daniels> Kamion: ahr, heh
<daniels> Kamion: ok, I'll try mini.iso, and construct a mirror here
<daniels> Kamion: any tips on constructing a mirror?
<daniels> Kamion: (well, basically gotchas that I'd need to look out for)
<Kamion> I basically just do debmirror --section=main/debian-installer
<daniels> Kamion: rad
<Kamion> make sure that gives you a Release file
<Kamion> I wish I knew why my powerbook's screen occasionally goes into flickery nightmare mode
<daniels> hm
<daniels> Kamion: i was kind of hoping to do it from local sources
<Kamion> it's like it's shuddering a bit under a fifth of a screen from the right
<Kamion> s/from/to/
<daniels> Kamion: is apt-move with a bit of poking sufficient?
<zepo__> may i suggest to consider, if it's possible,clearly,also Acer laptop
<Kamion> daniels: you could copy all the udebs from the CD to an archive structure and debmirror the rest
<daniels> zepo__: basically, try it and see if it works; the reason it won't be listed is because no-one has it
<daniels> zepo__: even a failure report is better than unknown, because we then have a far better idea of what to fix
<Kamion> there won't be all that much beyond what's on the CD
<daniels> Kamion: cheers
<zepo__> i tried,i have on my acer
<zepo__> daniels: sorry, and i 've video problems
<zepo__> daniels:if i will resolve i'll post on ubuntu page,but i don't know if i'll do
<thom> why is someone using ndiswrapper for an ipw2200?
<thom> Kamion: 2137 looks strangely familiar
<thom> :-)
<Kamion> thom: indeed :)
<Kamion> guess why it didn't take me long to work out what the problem was ...
<Kamion> (likely to be)
<daniels> ok, seems apt-move has mostly done the trick
<Kamion>    * Load firmware from standard locations (me):
<Kamion>      . drivers/net/wireless/acx/acx100_helper.c
<Kamion>      . drivers/net/wireless/acx/acx100_usb.c
<Kamion> ROCK!
<daniels> Kamion: btw, $MIRROR in update-cd is still n-n-y
<tseng> yay for dh_netlibs !!!
<tseng> + cdbs
<Kamion> daniels: right, we haven't changed the directory in /srv yet
<Kamion> thom: hm, do you have a minute to coordinate moving that to /srv/cdimage.ubuntu.com, or have you not bothered yet for other services?
<daniels> Kamion: fair point
<daniels> Kamion: hm
<daniels> Kamion: do I get to set a local mirror to download stuff from, or will it have a bash at archive.ubuntu.com?
<daniels> Kamion: (that's a d-i rebuild if no, correct?)
<thom> Kamion: sorry, move what?
<Kamion> thom: little:/srv/cdimage.no-name-yet.com
<Kamion> daniels: you'll get to set a local mirror when using netboot
<thom> Kamion: most haven't bothered yet
<Kamion> fair enough, no hurry then
<ross> thom: amusing bug i've just found in IIS
<ross> thom: which being an apache guy you'd find amusing
<tseng> jdub: would you mind double checking tomboy sometime? I fixed it
<ross> thom: domain names with the final period don't get matched in the virtual hosts.. www.180sw.com/ works fine, www.180sw.com./ fails
<thom> yeah, seen that one
<thom> it's... irritatiing
<ross> fools. our company signature has the dot at the end...
<daniels> Kamion: ahr, crap
<daniels> Kamion: any way to build it without source?
<thom> ross: it does? ugh
<daniels> Kamion: (my /var/cache/apt/archives doesn't extend to sources, sadly)
<thom> and why on earth are you using IIS?
<thom> hosted by bluewank?
<ross> thom: business, so telewest thankyou very much ;)
<daniels> Kamion: forgive the dumb questions
<thom> ah
<Kamion> daniels: --nosource, if you mean debmirror?
<Kamion> daniels: no problem
<daniels> Kamion: debian-cd
<daniels> Kamion: i've apt-moved /var/cache/apt/archives into a pool structure
<Kamion> uh; do you still need to use debian-cd?
<Kamion> I thought you were going to use netboot now
<daniels> Kamion: oh
<daniels> how do I generate netboot, if not debian-cd?
<Kamion> I think we're talking at cross-purposes :)
<Kamion> you download it from warty?
<daniels> oh, man
<daniels> yeah
<daniels> imagine I'm sitting here slapping my forehead.
<Kamion> the reason you need the debmirrored archive is because netboot will need to download from it
<daniels> yeah :0
<daniels> :), even
<daniels> it was an entertaining sojurn into debian-cd, anyhoo
<Kamion> heh :)
<Kamion> an ugly piece of code, that
<daniels> yeah
<seb128> grrrr
<seb128> I just spent 1 hour to understand that wanadoo rejects all the mail with a subject starting by "new ..."
<daniels> seb128: wtf?
<seb128> I was trying to send a mail about the new totem/gst packages
<seb128> daniels: apparently an anti-spam system
<carlos> seb128: man, you need a real mail account...
<seb128> I need a real provider :p
* Kamion has a bugzilla mid-air collision with himself. whoops
<thom> seb128: rock on
<daniels> hm, the biggest challenge might actually be finding a hub ;)
<tseng> hmm, pkgconfig is uninstallable?
<tseng> or am I smoking crack.
<thom> tseng: works fine for me
<tseng> thom: good deal
<daniels> i'm with thom
<tseng> says no installation candidate
<daniels> try putting a warty repo in sources.list :P
<tseng>  deb http://archive.ubuntu.com/ubuntu warty main restricted universe
<tseng> smartarse
<thom> apt-cache policy pkg-config ?
<tseng> oh.. sorry
<tseng> i have depend pkgconfig =/
<thom> that'd be why then :-)
<tseng> ya, i r dumb
<tseng> hacking on the monodevelop pkg some more
<thom> cool
<tseng> i broke some stuff when i converted to cdbs
<tseng> the sid package was debhelper
* thom sobs at cdbs
<thom> horrible thing :-)
<seb128> bah
<daniels> thom: in my case, cdbs wasn't doing me wrong; it was autotools the whole time
<mdz> pitti: agreed, 2131 is not RC
<seb128> jdub, mdz: ok to upload eagle-usb instead of eagle-adsl ? We already have the kernel module from eagle-usb, we should have the user tools in sync, I've forgotten to do this before ...
<pitti> Hi mdz!
<mdz> sabdfl: already a bug filed about that question
<mdz> daniels: dbus-monitor is not critical functionality
<daniels> mdz: 'kay
<mdz> seb128: what's the difference between eagle-usb and eagle-adsl?
<daniels> mdz: so absolutely no changes, even if dbus-monitor is totally dead to the world?
<pitti> mdz: okay, but thom was faster with downgrading it :-)
<mdz> daniels: give me a bug #
<seb128> mdz: the package has been renamed. We have the module from eagle-usb, the old -adsl doesn't work with 2.6
<daniels> mdz: none filed
<seb128> dunno what has changed exactly in the user tools part
<daniels> bonza! ubuntu me up, baby
<mdz> 13018: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-connection.c line 1999.
<mdz> This is normally a bug in some application using the D-BUS library.
<mdz> Failed to set up match "dbus-monitor": 
<mdz> free(): invalid pointer 0x40257edc!
<mdz> daniels: that?
<daniels> mdz: ya-huh
<mdz> seb128: so we need to replace -adsl with -usb?
<seb128> mdz: yes
<daniels> Kamion: where does 'anna' come from?
<Kamion> the name?
<daniels> Kamion: 'user.warn anna[2451] : WARNING **: bad d-i Packages file'
* azeem bets on Anna Kurnikova
<Kamion> no, Anna Hess, Joey's sister
<daniels> Kamion: grep turns up nothing in d-i
<Kamion> daniels: there's a source package named thus
<daniels> hrm
<daniels> arh, maybe if I learnt to type
<mdz> daniels: if the breakage is in dbus-monitor itself, and fixing it doesn't risk breaking dbus itself, I don't mind if you want to fix it
<daniels> mdz: thanks
<daniels> ARGH
<daniels> Kamion: hum
<tseng> anyone using the new totem pkg?
<sivang> just upgraded. dpkg asks about hal config file, replace?
<daniels> Kamion: 
<tseng> if i start totem while muine was using the dsp, it crashes
<daniels> daniels@nanasawa:~/mirror/warty-local/dists/warty/main/debian-installer/binary-i386% for i in $(zgrep '^Filename:' Packages.gz | sed -e 's/^Filename: //;'); do (cd ~/mirror/warty-local/$(dirname $i) && wget http://archive.ubuntu.com/ubuntu/$i); done
<Kamion> hoorah
<Kamion> looks reasonable to me, if gross :)
<Kamion> you might want a mkdir -p in there
<daniels> already done a mkdir -p loop
<Kamion> ok
<daniels> it's happily downloading all the udebs now
<Kamion> debmirror for dummies. :)
<daniels> it was the easiest way to not do a debmirror ;)
<daniels> heh
<daniels> the problem was that I moved my local cache over with apt-move (which has every package I need -- I checked)
<daniels> so I ran debmirror to just get the main/d-i section, and it decided to clobber the Release file and delete all of my debs
<daniels> so I wget'ed the Packages.{gz,bz2} from auckland, hacked the Release file by hand, and now I'm wget'ing the udebs
<daniels> ghetto mirror 101
<thom> speaking of ghetto, it appears i'm moving
<daniels> thom: oh?
<daniels> thom: where to?
* lamont_r waves
<daniels> lamont_r: hey dude
<daniels> Kamion: (turns out linux-image hadn't been updated -- go figure)
<daniels> Kamion: bloody good job on d-i btw; it should, by rights, be absolutely refusing to install (hacked-up setup, plus about twenty failures and other crap)
<Kamion> d-i's pretty good at coping with weird shit :)
<daniels> (mercifully)
<daniels> second stage ...
<lamont_r> any rc bugs for me to help with?
<amu> lamont_r: firefox ? ;)  
* lamont_r ducks
<lamont_r> I thought they decided that firefox was a heisenbug
<sivang> lamont_r : how did it go with postifx eventually?
<sivang> ah, just noticed debian branding issue in emacs
<sivang> "modified by debian project"
<azeem> what's wrong with that?
<sivang> ah nothing
<tseng> it was modified by debian project, no?
<sivang>  I just noticed it was removed from openoffice,
<sivang> which was also modified by the debian proejct..
<sivang> so figured this should be consistent.
<lamont_r> sivang: considering upload now, although I'd like _one_ more set of eyes first...
<sivang> lamont_r : you've fixed up the postfix-doc oopsy ?
<amu> lamont_r: hehe ( heissenbug ) 
<lamont_r> sivang: the .gz issue?
<sivang> lamont_r : yes. that missing file.
<lamont_r> fixed that by pointing to the html version, which is never compressed.
<sivang> lamont_r : page me I will give it another run also
<amu> i found something nice to fix, ex. if i install german env, i got a english openoffice, english *spellcheckers ... should it german instead of english ;) ? 
<lamont_r> see bug 2022
<lamont_r> amu: and lots of "misspelled" words, eh?
<amu> lamont_r: thats no prob and impossible to fix i18n from gnome, but as a new user, i expect choosing german or any other lang, my programs and depends setuped in german, just a little more useability
<mdz> Kamion: around?
<Kamion> mdz: yep
<lamont_r> amu: yeah
<fabbione> hey amu
<amu> fabbione: buona sera ;) 
<fabbione> amu: heheh
<amu> fabbione: what up, you GF is again away ? *ducked* 
<lamont_r> fabbione: gmt+3 there?
<Kamion> mdz: will be gone for dinner in about 15 minutes
<fabbione> amu: ehehehe
<fabbione> lamont_r: gmt+2
<fabbione> (we are still summer time)
<lamont_r> right.  so london + 1
<fabbione> amu: she is sleeping.. all this changing house stuff is killing us a bit
<fabbione> lamont_r: yeps
<amu> hehe, summertime, but 8C here 
<fabbione> amu: yeah... nothing new about it :-)))
<myk> is there documentation on the correct way to rebuild debian packages for ubuntu?
<Kamion> myk: the only things that build our packages are our build daemons ...
<mdz> Kamion: have a moment to review ubuntu-meta for me?
<Kamion> mdz: sure
<Kamion> what is it? :)
<mdz> mailed
<mdz> the thing which generates ubuntu-base and ubuntu-desktop
<myk> Kamion, i'd like to use robert love's netapplet, and there's already a debian package for it.  can i just install it?
<Kamion> ah
<Kamion> myk: should be able to yes
<Kamion> myk: failing that just build the package in the normal Debian way on an Ubuntu system
<myk> mkay
<lamont_r> myk: for rebuilding, the trivial answer is: have current build-depends installed and say dpkg-buildpackage -rfakeroot -b
<myk> lamont_r: thanks
<lamont_r> I guess there's and apt-get version that does that for you, but I can't ever remember it... :-)
<myk> i'm new to the debian system... still thinking in gentoo
<lamont_r> myk: the build daemons actually us a chroot to build things, and 'sbuild' to deal with getting in and out of the chroot properly.
<lamont_r> but that's overkill for most things.
<myk> is there a way for users to submit rebuilt packages to say, universe?
<lamont_r> myk: for that, generate a diff vs the ubunut source that fixes the issue, and file a bug with that.
<myk> lamont_r: well, this is a debian package I just downloaded that isn't yet available in ubuntu
<lamont_r> as time permits, we'll review it and upload
<lamont_r> then the buildds build it in the pristine environment
<thom> mdz: i guess you and jdub need to work out a sane strategy for firefox, but the current release isn't sustainable
<lamont_r> thom: ouch
* lamont_r upgrades yet again. 214 packages. sigh.
<mdz> thom: it does seem a bit on the shitty side
<mdz>    * Add ipw2100 and ipw2200 to nic-extra-modules.
* mdz high-fives Kamion
<tseng> hmm
<Kamion> thought you'd like that
<mdz> Kamion: that includes the firmware as well?
<Kamion> dunno why I'd forgotten it
<Kamion> no, not the firmware, that involves more work
<Kamion> I do want to do that before warty though, if I can
<mdz> I thought you were intentionally leaving it out because the firmware wouldn't work yet
<Kamion> might as well have it in there, then at least even if I don't get the firmware in people can copy it over on a USB stick or a floppy
<lamont_r> does this mean that we have those stupid d-link cards working now?
<Kamion> that would suck, but only gently
<Kamion> the d-link cards need ndiswrapper, don't they?
<Kamion> I haven't included that, that seems like lots more pain
<elmo_> the word your look for is WORLDDESTROYINGCRACK
<lamont_r> no issue here.
<lamont_r> ndiswarpper evil.
<lamont_r> and warping, apparently
<lamont_r> fabbione: daniels: how do I tell X to switch bits-per-pixel without restarting X?
<sivang> lamont_r : ok, i see it's accepted. have a look at it? or when it's accepted that means it's uploaded already?
<lamont_r> accepted means that the source is in the archive.  given thebuild time, the binaries will be available in just over 23 minutes
<sivang> lamont_r : ok
<lamont_r> that reminds me - time to close the bug.
<fabbione> lamont_r: you mean depth?
<lamont_r> yeah
<fabbione> lamont_r: you can't.. 
<fabbione> you need to restart X
<lamont_r> feh
<lamont_r> ok.  something to do after the upgrade finishes,then.
<lamont_r> xresprobe doesn't give depth, edid fails, and the card claims that it does 24-bit.
<lamont_r> for whatever reason, 16 bit was chosen back in the dawn of time for this system
<lamont_r> fabbione: there was a keystroke sequence for changing resolution though, yes?
<thom> ctrl+shift++
<thom> and ctrl+shift+-
<fabbione> yes
<lamont_r> hrm.. metacity seems to keep those grabbed, or the LCD doesn't want to change, or something.. :-)
* fabbione is trying to kill X11R6 and mostlikely X11 from the filesystem in a nice way
<thom> mdz: if we go back to 0.9.3 we'll need to sync the firefox language packs from unstable
<mdz> thom: that sounds relatively painless
<mdz> thom: certainly compared to the profile nightmares that would likely ensue
<thom> yeah
<thom> i'm sure downgrading profiles is even less supported than upgrading them
<mdz> echo "rm -rf /home/*/.mozilla/firefox" >> mozilla-firefox.postinst
<thom> the firefox wrapper script does something similar, actually. it may or may not be enough
* lamont_r looks at 1927, ponders the fact that he doesn't see it on his vaio (with an RTL8139)
<mdz> Kamion: any feedback on ubuntu-meta?
<lamont_r> gnumeric.desktop contains invalid MIME type 'comma-separated-values'
<lamont_r> (missing slash)
<mdz> lamont_r: how is multiverse looking in terms of builds?
<lamont_r> it was chunking along - let me go look
<elmo_> 1.1G    ftp/pool/multiverse
<elmo_> quinn-warty.amd64-old:149
<elmo_> quinn-warty.i386-old:136
<elmo_> quinn-warty.powerpc-old:139
<elmo_> ^-- multiverse entries in q-d
<lamont_r> 209 total multiverse packages (i386), 75 Installed.
<elmo_> a lot of the marillat stuff probably won't build - some of it wasn't even signed (woot)
<lamont_r> 76 dep-wait, 4 needs-build, 53 building (==failed)
<elmo_> heh half the world dep-waiting on java
<lamont_r> not surprising. :-(
* thom goes to sit in front of the tv and do NetworkManager packages
<thom> since world+dog have now asked
<lamont_r> hrm.. telling xchat to open a url in a new tab of mozilla was working with firefox before the upgrade..
<Mithrandir> lamont_r: http://freerelay.raw.no/setup-postfix ?
<lamont_r> um, that just says how to use freerelay.raw.no as a relay...
<lamont_r> although I must wonder why you have relayhost twice...
<lamont_r> also, I think you really want [freerelay.raw.no] :2525
<lamont_r> without the []  it does MX lookups
<lamont_r> time to go get kids from school.  bbiab
<sivang> I have a user wanting to make a custome kernel, is this applicable to ubuntu already? (e.g, k-src pageas, build-deb it etc)
<sivang> (just like it goes for debian?)
<mdz> mako: ping?
<mdz> sivang: it is almost the same; the packages are named linux-* rather than kernel-*
<sivang> mdz : yes, someone else noted it on #ubuntu, I checked so it's cool. afterwards it's make xconfig/menuconfig and dpkg-builddeb..;)
<mdz> sivang: generally, when someone is new to the system and is asking to compile the kernel, the question is "why?" :-)
<sivang> hmmm
<sivang> :)
<sivang> didn't even think of asking him
<sivang> but he said himself,
<mdz> so many people are accustomed to compiling the kernel just because they've always done it
<sivang> "I think I need for booting my USB drive"
<sivang> his kenrel panics on /dev/console missing || cannot open
<mdz> same guy from the mailing list?
<mdz> if so, I think he's in over his head
<sivang> he told me he used to do this on gentoo (compile the kernel with uid support built in)
<sivang> and it worked for him.
<sivang> sec, I'll search
<sivang> oh god..He's gone to IRSSI, I am afraid something there is going to break..shall I shout him to stop? :)
* sivang is very happy at ubuntu's approach to _not_ having to compile the kernel everytime a gfx driver changes.
<mako> mdz: hey there
<mdz> mako: hey, I noticed that LWN didn't pick up this week's traffic, do we need to synchronize with them or something in order for that to happen?
<mako> mdz: whats up?
<sivang> hey mako
<mako> sivang: hey
<mako> mdz: i didn't realize they had picked up other traffics
<mdz> mako: http://lwn.net/Articles/103368/
<mdz> mako: last week picked up traffic #5
<mdz> which is awesome
<mdz> it would be even better if they did it every week from now on :-)
<mdz> so 0923 had a headline article about ubuntu, 0930 had traffic #5, but this week we're a zero :-(
<mako> mdz: excellent.. do we have a contact there or should i just email lwn@lwn.net?
<mdz> mako: I think lwn@lwn.net is the place
<mako> i'm happy to just BCC traffic to them every week then
<mdz> mako: I think we probably want to set up an ubuntu-news, a la debian-news
<mako> mdz: i was thinking of that
<mdz> I'm pretty sure lwn@lwn.net subscribes, and that's how they pick up DWN
<mdz> mako: mail jdub on it?
<mako> mdz: sure, i can do that
<mako> mdz: i'm going to try to hook up with kernel traffic i think too 
<mako> mdz: so we're in their header
<mdz> mako: once it's set up, we should announce it to -announce for those folks who are ready for more traffic than -announce, but less than -users :-)
<mako> mdz: absolutely
<mako> mdz: can you verify that you can you regen your pw in shipit and such without getting internal server errors for me?
<mdz> mako: yep, works
<mdz> at least, doesn't throw an error
<mako> brilliant
<mako> ok
<mako> kiko pointed out you can order negative cds :)
<mako> if you do this, i will flag it when shipping and send someone to your house to steal your cds
<mdz> good plan
<m_tthew> mako: worked for me 100%
<m_tthew> mako: the new shipit stuff
<Mithrandir> mdz: would you be unhappy if I sat down and implemented good amd64 nvidia support over the weekend, wrt stability?
<mdz> Mithrandir: no, I would be quite pleased in fact
<mako> m_tthew: awesome :)
<mdz> I started on it, but it required more time than I could devote
<mdz> Mithrandir: if you want, I'll send you what I have
<Mithrandir> mdz: the student society has some amd64 cards, so I'm going to borrow it.
<Mithrandir> mdz: yes, please.
<mdz> argh, I can't
<mdz> apparently I deleted it
<mdz> it was a mess anyway; I had pretty much decided I should have rewritten debian/rules instead
<Mithrandir> ok
<Mithrandir> it uses the nvidia-kernel-source thingy, or how is all this structured?
<mdz> Mithrandir: as long as you can verify that the existing i386 package is exactly the same after your modifications, I'm OK with it
<Mithrandir> I haven't looked at it at all
<mdz> Mithrandir: it's all part of linux-restricted-modules
<Mithrandir> including the X module bit?
<mdz> yes
<Mithrandir> ok, coolie
<Mithrandir> verification should be easy.
<mdz> it builds sboth the modules and nvidia-glx
<thom_> daniels: ping?
<sabdfl> erm... i can't believe i even found the words "ndiswrapper" and "installer" in the same SENTENCE in scrollback tonight :-)
<sabdfl> kamion: did I read it right, we have fw in the installer? awesome, great work indeed.
* thom_ bounces up and down on redhat's head
<thom_> using bleeding unreleased features in dbus
<sabdfl> thom: careful dude, russian joke about condoms calls them "red hats", and this is a very multicultrual channel
<mdz> sabdfl: we don't yet have firmware in the installer, but Kamion has done much of the work and we may have it for Warty
<sabdfl> fantastic, that's a big one for me, worth leaving one or two other warts in for if it comes down to a choice
<thom_> sabdfl: thanks, i'm now disturbed :-)
* chrisa moves away from thom
#ubuntu-devel 2004-10-19
* lamont notes that sound no longer works on his vaio.  grumble
<lamont> otoh, it now powers off when it shutsdown. :-)
<mdz> it's very encouraging to see that an increasing fraction of #ubuntu and ubuntu-users seems to be non-ubuntu-specific user support
<Kamion> mdz: I don't seem to have got your mail about ubuntu-meta
<Kamion> sorry
<Kamion> (un?)fortunately I am being asked to go to bed now; I hope it can wait until tomorrow
<thom> NetworkManager ate my network
<thom> (and lets not mention the fact i'm running a cvs version of dbus, either)
<lamont> mdz: so which snd modules did I not want loaded?
<mdz> lamont: eh?
<lamont> upgraded my vaio today.  ENOSOUND.
<mdz> Kamion: weird; I'll upload it someplace instead
<mdz> Kamion: http://people.ubuntulinux.org/~mdz/temp/ubuntu-meta_0.1.tar.gz
<mdz> if anyone else would like to take a look as well, I'd appreciate it
<azeem> lamont: perhaps the mixers are muted?
<azeem> happens for me all the time, although on unstable
<mdz> lamont: sounds like you want them loaded, rather than wanting them not loaded
<lamont> was thinking oss vs alsa crap again.
<lamont> otoh, this is that wonderful realtek stack...
<lamont> but my network does work (RTL8139
<mdz> the oss vs. alsa crap was solved long ago by getting rid of discover
<mdz> Mithrandir: if you're going to fix nvidia, please fix that awful bit where you need to update the nvidia version number by hand in debian/rules with every upload
<mdz> that bites everyone
<pooh_> strange. does a manual edit of /etc/fstab supposed to trigger a complete crash of gnome?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 13 RC bugs to go
<lamont> boo hiss
<sivang> sure I added something to /media , but  a crash?
<mdz> sivang: yes that's a feature, the "crash feature"
<sivang> mdz : :-))
<sivang> mdz : maybe adding it under /mnt would be better?
<mdz> sivang: subdirectories under /mnt are evil
<mdz>  /media is the right place for random storage devices, if that's what it is
<sivang> mdz : why? /mnt is the good'o no?
<sivang> mdz : oh, it's a vfat part.
<mdz> sivang: then it doesn't belong under /media, just create a directory for it someplace
<mdz> sivang: /mnt is meant for having things mounted on it.  if you make subdirectories under it, they are masked when you mount something on /mnt
<sivang> mdz : but it shouldn't crash whenever I edit the file right?
<mdz> sivang: it should never crash, ever
<sivang> mdz : :-)
<sivang> mdz : i'll look for it on the bts
<sivang> mdz : if I put hd parts on /mnt, I get to click them on file manager and they automount. I like that.
<sivang> hmmm, trying another upgrade: debconf: apt-extracttemplates faild: Bad file descriptor.
<sivang> it just hung up after fetching.
<r4bb1t> does anyone know offhand if acpi and apm can be on at the same time and play nice?
<r4bb1t> my side question is: how does ubuntu suspend? using ACPI or APM?
<thom> it doesn't, in general
<lamont> 2.6.8.1-2 has sound, doesn't power off.  2.6.8.1-3 has no sound, powers off.... hrm...
<thom> we can't safely turn it on globally
<thom> since many, many laptops do all kinda loopy things when you suspend them
<sivang> can't start gnome back...
* lamont needs to find a map of the UK online somewhere...
<thom> lamont: http://www.ukguide.org/ukmap.html ?
<thom> what detail do you need?
<lamont> thom: awesome.
<lamont> hrm.. she needs to find some rivers too...
<doko> rivers, in uk?
<lamont> yeah, they exist.
<lamont> the camm for example..
* lamont ponders why rebooting into -2 and back into -3 fixed sound...
<sivang> no luck :(
<sivang> where can I see logs to find out what's bugging my gnome?
<thom> lamont: well, http://www.ordnancesurvey.co.uk/oswebsite/getamap/ has a vicious click through license, but is pretty cool
<thom> sivang: .xsession-errors
<thom> ?
<seb128> sivang: what's happening ?
<sivang> seb128,thom : it all started with a very innocent personal touch to fstab,
<sivang> seb128,thom : then an upgrade in text mode, now gnome gets stuck with the 2 pannels and nothing more.
<seb128> what's the change in fstab ?
<sivang> seb128 : I added a vfat part to it, first it pointed at /media (it used to work that way) no on /mnt
<sivang> looking at xsession-erros:
<sivang> gnome_execute_async_with_env_fds: returning -1
<sivang> killing it and retuning to gdm, trying to relogin doesn't help.
<seb128> dpkg -l gnome-panel ?
<sivang> seb128 : what's the best way to see what happend on the last upgrade?
<seb128> no
<sivang> seb128 : I wasn't near the machine, it might have upgraded the kernel
<seb128> dpkg -l gnome-panel ?
<sivang> seb128 : wouldn't I have to reboot in this case?
<seb128> I don't think so
<sivang> seb128 : it's there, sec. (on irssi)
<sivang> 2.8.0.1-0ubuntu
<seb128> ii ?
<sivang> yes
<seb128> hum
<seb128> gnome_execute_async_with_env_fds <- I think it's trying to start something missing
<sivang> seb128 : i'll do a cold reboot, and try again?
<seb128> ok
<sivang> c'ya in a sec.
<sivang> hmm
<sivang> it worked :)
<sivang> strange. I got used to debian not having to ever reboot 
<seb128> yeah, that's weird
<seb128> perhaps a hal issue ...
<sivang> maybe. there have been a couple of them.
<sivang> :)
<mdz> jdub: ping?
<jdub> pong
<sivang> mdz : what would be your oppinion about a python http bug-buddy to bugzilla hack for Hoary?
<mdz> jdub: do you have the original presentation file for those 1-2-3 slides?
<mdz> sivang: for hoary, we'll be transitioning away from bugzilla
<jdub> mdz: yeah, will send you the bits
<jdub> it's updated too
<mdz> jdub: awesome
<mdz> jdub: a friend of mine is doing a presentation this evening for a LUG and asked for slides
<sivang> mdz : to what?
<jdub> mdz: i'll send you jane's too
<mdz> jdub: I have jane's, unless you've changed it since she sent it out
<jdub> oh, nup
<thom> sivang: magic
<thom> sivang: or malone, even :-)
<sivang> thom : is there a place to read about those?
<thom> sivang: i rather suspect not, currently
<thom> sorry
<sivang> ok
<thom> i believe there is already an xml-rpc client for it tho
<sivang> nice, anyway I'm headed to bed. Night everybody
<thom> ciao
<mdz> jdub: I saw your bug closure for vim-gnome, but no upload
<jdub> i thought you fixed it a while back - i don't have an icon here
<jdub> s/icon/item/
<jdub> oh, puce -> panel is dead
<tseng> hiya
<jdub> mdz: fixing/uploading now
<mdz> jdub: I thought I had, too, but I didn't
<tseng> jdub: anything more you need from me to get mono in?
<jdub> tseng: just a confirm from mdz :)
<tseng> i updated tomboy and monodevelop
<mdz> jdub: mm?
<mdz> I thought we already exchanged email on that. new versions now or something?
<tseng> we did, it was approved
<tseng> whats the next step?
* tseng sits on the outside and looks in
* lamont curses at xteddy rubymagick qvwm prestimel pixelize pike7.6-image mgp libepplet0 libautotrace3 idesk icewm-experimental icewm guikachu2rcp guikachu epplets enlightenment endeavour2 dvdauthor chameleon autotrace animal0 ale
<lamont> on the bright side, they're all in universe.
<lamont> on the dark side, they all Depend: libtiff3g on powerpc, and are therefore not installable.
<lamont> fabbione: daniels: you around?
<lamont>  /etc/init.d/xfree86-common: line 11: /lib/lsb/init-functions: No such file or directory
<justdave> hmm...  wonder if the keys for mouse emulation on ppc should be different...
<justdave> F12 appears to be 'right-click'
<justdave> it's also my eject key, and now I can't eject
<justdave> because typical Apple hardware has no eject button on the actual cd drawer
<justdave> I can eject okay by right-clicking on the CD in nautilus and picking eject, but that leaves the drawer open, and it's one of those ones that feels like you're going to break it if you push the drawer hard enough to make it shut
<tseng> hmm, did pitti's utopia packages go away?
<npmccallum> tseng: I believe they are in the archive nw
<tseng> npmccallum: the archive looks to be ubuntu4, his sources are ubuntu5
* tseng shrugs
<tseng> unless its pending or something.
<daniels> thom: pong
<daniels> lamont: pong
<daniels> lamont: i don't think you can do depth moves
<daniels> thom: but I'm running out the door now, and won't be back for a couple of hours. give me a call if you need me.
<daniels> thom: oh, you just want bleeeeeeeding edge dbus, I see. i'll sort that out tonight.
<mdz> there seem to be a lot of successful builds from universe where the packages aren't in the archive yet
<mdz> 20041008-0208
<mdz> s/universe/multiverse/
<mdz> the buildds are BST, right?  that was hours ago
* lamont will check
<mdz> why does lsb depend on 'make'?
<lamont> mdz: probably for the same reason that it Depends: on cron, libc6-dev, lpr, m4, mawk, passwd, procps, etc...
<lamont> they
<lamont> they're part of the spec?
<mdz> ok, let me rephrase
<mdz> why does LSB require make and libc6-dev?
<lamont> daemon.log:Oct  8 02:10:05 buildd-mail: mythtv must be manually dinstall-ed -- delayed
<lamont> mdz: nfc
<mdz> lamont: ah, right
<mdz> I keep forgetting about that bit, in the midst of all the delicious automation we have otherwise :-)
<fabbione> morning guys
<fabbione> hmmm
<fabbione> thuderbird crashed on me
<mdz> morning
<fabbione> hey mdz
<fabbione> and it is done according to:
<fabbione> ops
<fabbione> lamont: 2151 pending upload?
<lamont> no - I fat fingered something
<fabbione> (also please take ownership of the bug so i we know someone is working on it)
<fabbione> ahah ok
<lamont> fabbione: that would be the same firefox bug as the pending upload
<lamont> (back doesn't quite do it...)
<lamont> you have to re-enter everything. :-(*
<fabbione> mdz: 2158 are you on it?
<fabbione> lamont: it's not only on firefox.. it's on all browsers and justdave claims to be ok, but it was different before
<justdave> I'm not ok, I get it too
<fabbione> justdave: well, why did you close the bug than?
<justdave> which bug?
<justdave> unless I'm confused about what you're talking about, there's still an open bug on it
<mdz> fabbione: I will not be able to deal with it until tomorrow; it is yours if you want it
<fabbione> justdave: the one that was open by a girl i think and where i added info
<fabbione> mdz: ok i take it. Can you send me the usual stuff if you have any?
<justdave> 2108?
<mdz> fabbione: I'll look
<fabbione> mdz: the patch is one line
<justdave> looks open to me still
<justdave> 2109 also (which has comments from you)
<fabbione> justdave: 2109
<justdave> I think the two are related
<fabbione> hmm
<fabbione> ok.. i must have misread the bug number
<fabbione> there was one invalidated.. i am sure
<fabbione> or you are cheating behind the lines :PP
<justdave> I have yet to find anyone who knows enough about DOM and caching to tell me why it's broken
<fabbione> jdub: you will have to take the last 2 bugs you opened
<fabbione> jdub: i don't have a synaptic thing to even check what you are talkign about
<fabbione> also.. the synaptics driver is not shipped by xfree86
<jdub> fabbione: assign to daniel :)
<jdub> hrm
<jdub> so, if i do a dpkg-reconfigure when xfree86 is already configured
<jdub> it doesnt' change the file
<jdub> oh
<fabbione> jdub: that's because you modified the config file manually
<jdub> yeah
<jdub> just found that bit in the file
<mdz> fabbione: did you receive the email?
<fabbione> mdz: yes
<fabbione> thanks
* lamont sleeps
<pitti> Morning
<mdz> morning
<fabbione> mdz: i updated the office stuff to reflect my office movement situation
<pitti> jdub: just tried the new gdm; isn't it a little bothering to hear the same lengthy sound two times in short succession?
<jdub> pitti: yes
<pitti> jdub: so will the login sound be disabled then?
<jdub> pitti: depending on whether or not the event sounds stay enabled
<jdub> pitti: the sound may change
<pitti> jdub: personally I'd prefer a short, short confirmation sound when gdm finished, but that's a matter of taste...
<jdub> that's what it would be if the event sounds stay enabled
<seb128> morning
<pitti> Hi seb128!
<seb128> hello pitti 
<Kamion> mdz: hmm, please make ubuntu-meta/update sort the package lists it spits out :) it's pretty much impossible to compare them to anything as it is
<Kamion> mdz: looks like the right idea, but the actual packages will need testing; I'm slightly concerned that we're going to be making all our users regression-test germinate :-)
<Kamion> mdz: please also blacklist hfsplus hfsutils libhfsp0 from amd64 and i386; and you might want to consider blacklisting the kernel
<Kamion> mdz: oh, and grub and yaboot
<sivang> morning all
<thom> daniels: it's already done :-)
<sivang> Might Herbert Xu be here?
<elmo_> I don't think he IRCs
<sivang> k
<fabbione> hey elmo_
<fabbione> elmo_: do you think can i make the last X upload using my canonical.com address? ;)
<elmo_> how do you mean?  *@canonical.com is whitelisted.. if you mean your key, blah
<fabbione> elmo_: the latter ;)
<daniels> thom: rad
* Kamion falls over
<Kamion> my scary kernel-wedge hack for firmware pretty much worked first time
<Kamion> nic-firmware-2.6.8.1-3-amd64-generic-di_0.14ubuntu10_amd64.udeb
<Mithrandir> you're doing firmware-for-di-hacking?
<Kamion> yup
<Mithrandir> _scary_
<Mithrandir> Kamion: do you have anything to do with the rc-bug-list?
<Mithrandir> from bugscan
<Kamion> which one?
<Kamion> oh
<Kamion> yes
<Mithrandir> could you add an explanation to what the colors mean?  And, it would be nice to have some icons for people like me who are red-green color-blind.
<Kamion> bloody hell, it's jumped a lot
<Kamion> there's already an explanation there
<Kamion> The red line graphs all bugs with release-critical severities; the green line graphs the number of bugs that are actually a concern for the next release (excluding ignored bugs, bugs on packages not in testing, and bugs whose tags indicate that they don't apply to testing).
<Mithrandir> oh, not the graph, the list.
<Kamion> as to icons, tell me how to do it in gnuplot :)
<Kamion> oh
<Kamion> the colours are just visual additions to the existing letters
<Mithrandir> ok
<daniels> Kamion: remind me to buy you a beer some day
<Mithrandir> daniels: we'll get kamion really drunk during next meeting. :)
<Kamion> Mithrandir: I'll try to remember to add some descriptions of the colours at some point
<Mithrandir> Kamion: thanks.
<Kamion> haven't really bugscan-hacked for a little while, there's a bug with all-numeric package names that needs to be fixed first
<elmo_> use R, it's fun for stats pr0n graphcs
<fabbione> hmmmm
<fabbione> bt in gdb
<fabbione> in which order does it show the trace?
<fabbione> 0 is the last function called and NN the first one traced?
<fabbione> or viceversa? ala strace?
<Mithrandir> first is deepest in the call stack
<Mithrandir> iirc.
<fabbione> so NN is the last called
<fabbione> https://bugzilla.ubuntu.com/show_bug.cgi?id=1842
<fabbione> Mithrandir: comment 8
<Mithrandir> you see that #30 is main :P
<fabbione> Mithrandir: yes, but X is not that "main"
<fabbione> it does a lot to recover from a crash
<Mithrandir> seems to be the X server's main function.
<fabbione> it would make sence
<fabbione> but i am not sure about the raise() at 0
<fabbione> that's like kill <proc> <sig>
<fabbione> anyway.. food time :-))
<Mithrandir> that's the result of it getting a signal in #7
<fabbione> ok
<Mithrandir> and #5 probably has a line abort()
<Mithrandir> or, ddxGiveUp, has one.
<fabbione> good point
<sivang> john levin here?
<elmo_> huh?  I thought our debootstrap had a .buildd variant?
<Mithrandir> elmo_: I don't think it's shipped.
<Mithrandir> elmo_: want a copy, or do you have it?
<elmo_> no, it's cool, don't need it as it turned out
<elmo_> might be nice to ship it tho someday
<Mithrandir> I just got it from lamont, but I agree it would be useful to ship it
<lamont> --variant=buildd
<lamont> in the current debootstrap
<elmo_> lamont: "no such file: warty.buildd"
<elmo_> ...
* lamont runs off again
<lamont> le huh. will check when I get back
<lamont> apt-get source has it.. :-(
<Mithrandir> lamont: yeah, but currently we don't even ship the file. :P
<Mithrandir> doko: any progress with AVM?
<Kamion> lamont: would've been a good idea to add it to Makefile ;)
<Kamion> lamont: I'll fix
<lamont> Kamion: I could swear I did that.
<lamont> sigh.
<lamont> kids to school (last was a fire call..), bbiah
<lamont> moo
<pitti> jdub: may I upload #2165? Trivial, but... protocol...
<Kamion> quick review of http://people.ubuntulinux.org/~cjwatson/kernel-wedge.diff, please?
<Kamion> copy-firmware is basically just clone-and-hack of copy-modules
<Kamion> and then there's a bunch of other gunk for putting the *-firmware-di packages together
<Kamion> seems to work with linux-kernel-di-amd64-2.6 and my new linux-kernel-restricted-di-2.6
<Kamion> hm, although something's still wrong, never mind for the moment
<seb128> mdz, jdub: ok to upload the patch in #1643 ?
<pitti> fabbione: got a minute?
<pitti> Kamion: I just had a friend of me installing Ubuntu. He was bitten by #993 (no grub menu to select windows)
<pitti> Kamion: will this be settled by release? Would you oppose to raising it to major?
<ggi> I'm noticing some odd phenomena. Playing music in Rhythmbox results in quite noticeable hisses and pops on some tracks. Playing things in Muine sounds absolutely fine, but only sometimes. It seems to be playing fine now (I just killed esd), but often it plays fine when esd is running, then hisses and pops after I run ogg123, which in turn has noticeable popping in the output.
<ggi> Any ideas of what's to blame here? My natural reaction was to blame esd, but that can't explain the ogg123 thing.
<ggi> Would anyone care if I put up an ogg file with noticeable pops/clicks when played with Rhythmbox somewhere?
<ggi> Except the copyright holders, obviously.
* lamont is happy to introduce http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html (where today is london time, and only changes if there are new log files for that day...)
<Mithrandir> lamont: RSS feed, pretty please?
<lamont> Mithrandir: uh, how?
* lamont has never done rss...
<Mithrandir> write a perl script using XML::RSS or something?
<lamont> tsk tsk.
<lamont> s/perl/python/
<Mithrandir> I've only done it in perl, I guess there are python modules to do the same thing.
* lamont has no clue where to start... maybe one of your scripts?
<Mithrandir> hmm, you have a cron job pushing over the new data, right?
<Mithrandir> that is, the new logs.
<Mithrandir> or rather, how is today.html built?
<Kamion> pitti: I was planning to do it before release anyway
<Kamion> pitti: I'm not convinced it's major, since people can just hit Escape
<pitti> Kamion: my friend was just confused, he did not catch the one-line message which said to press Esc
<pitti> Kamion: but if it's fixed by the release, I don't really care about the severity :-)
<pitti> Kamion: another thing: my friend selected English language, but German keyboard in the installer
<pitti> Kamion: however, the installed system had an English keyboard and POSIX locale
<pitti> Kamion: shall I submit that as a bug , or do you know about it?
<Kamion> console or X?
<pitti> X
<pitti> I didn't check console
<pitti> I advised him to switch in Gnome
<Kamion> do so; if it's just X then it's an X bug
<pitti> (the keyboard)
<pitti> okay, I do
<pitti> standard locale was POSIX
<Kamion> POSIX locale is the expected result of selecting English at the moment, I think
<pitti> but he actually needs en_US
<Kamion> {language,country}chooser are odd
<Kamion> needs?
<pitti> because otherwise you cannot enter umlaute otherwise
<Kamion> ah
<Kamion> I'd rather not attempt to fix that for warty
<Kamion> it's subtle and quick to anger
<pitti> I had him call dpkg-reconfigure locale and set en_US.UTF-8
<pitti> Kamion: no, this shouldn't be fixed for warty, but the keyboard selection should work
<Kamion> sure
<pitti> I try under console, brb
<lamont> Mithrandir: the cronjob that pulls the log files processes the output of rsync, actually.. :-)
<Mithrandir> lamont: so there's no way to say "please give me the log files for $DATE"?
<lamont> ~lamont/bin/mirrorLogs.py
<pitti> Kamion: it works correctly at the consoles
<pitti> Kamion: so, an X configuration bug
<lamont> only in that it actually builds yyyymmdd.html, and symlinks today.html to it.
<pitti> Kamion: shall I bother fabbione with that?
<lamont> what I added today is the symlink to today.thml
<pitti> Kamion: or is it an installer bug?
<lamont> Mithrandir: see http://people.ubuntu.com/~lamont/buildLogs/byDate/
<Kamion> pitti: -> fabbione
<pitti> Kamion: okay, I'll file a bug
<Kamion> pitti: my job ends when X starts :)
<pitti> ;-)
<Kamion> hm, bugger
<Mithrandir> lamont: yeah.. I could possibly build something off that. it's on rookery, right?
<lamont> yeahg
<Kamion> does anyone care if nic-restricted-firmware.udeb doesn't depend on kernel-image or firmware-modules?
<pitti> Kamion: BTW, his USB key crashes hal, so I also got sth to do now :-)
* Kamion figures that if I can live without those dependencies then nobody else is going to care ...
<lamont> Kamion: sounds reasonable, I think.
<lamont> are udeb's even used anywhere other than d-i?
<Mithrandir> lamont: no
<lamont> Mithrandir: btw, would be interested in seeing the RSS feed when you get it happy...
<Mithrandir> lamont: I'll give it a shot when I've banged my head through a wall with the amd64 nvidia drivers. :)
<Kamion> in that case http://people.ubuntulinux.org/~cjwatson/kernel-wedge.diff should really be reviewable now
<Mithrandir> Kamion: I seriously dislike ( while read foo; ... ) < file, but that might just be me.
<Mithrandir> I'd rather have rewritten that part in awk or python or something.
<Kamion> Mithrandir: copy-firmware is a cloned-and-hacked copy of copy-modules. I explicitly avoided changing too much stuff because I wanted to keep the diff against copy-modules small.
<Kamion> I'm slightly uncomfortable with the clone-and-hack in the first place, but it was less risky that way.
* Mithrandir blinks over the triple nested subshells and piping between those.
<Mithrandir> Kamion: why not rather use cp -a than two tar processes?
<Mithrandir> oh, yeah, I see.
<Keybuk> cpio -p
<Keybuk> Mithrandir: I dislike ( ) < foo too ... exec 3<&0 <file is better
<Kamion> 16:34 < Kamion> Mithrandir: copy-firmware is a cloned-and-hacked copy of copy-modules. I explicitly avoided changing too much stuff because I wanted to keep the diff against copy-modules small.
<thom> NetworkManager appears unkeen on hidden networks
<Mithrandir> we're shipping the isl3890 firmware now?
<Mithrandir> that's cool :)
<Keybuk> thom: yeah, it was written to ignore them; wasn't it?
<Kamion> if you want to review copy-firmware then please review the diff against copy-modules :)
<Mithrandir> Kamion: it looks fairly good to me, but I have just read the diff and I don't know kernel-wedge too well.
<Kamion> http://people.ubuntulinux.org/~cjwatson/copy-firmware.diff
<thom> Keybuk: unkeen to the point of exploding
<Keybuk> heh
<Mithrandir> what's a hidden network?
<daniels> thom: how's NM coming along?
<daniels> Mithrandir: wireless network that doesn't beacon
<Kamion> OK, I'm going to upload kernel-wedge on the basis that an upload of that is fairly harmless by itself, and see about the four client packages
<thom> daniels: well, i have something that seems to more or less work, kinda
<thom> it needs a lot more time
<daniels> thomrad
<daniels> npmccallum: hey dude
<npmccallum> daniels: hey, whats up?
<Kamion> mdz: let me know if you're happy for me to add firmware udebs to the InstallerSeed and upload them
<mdz> Kamion: separate firmware udebs?
<mdz> Kamion: or add the firmware to the appropriate existing udebs?
<Kamion> mdz: separate
<Kamion> it's excessively fiddly to have them mixed in with the existing udebs
<mdz> as long as they're guaranteed to be synchronized
<mdz> because that's the point of shipping it together with the kernel
<Kamion> same source package as linux-kernel-di-*
<mdz> fine with me, then
<Kamion> except for the restricted one
<Kamion> which, AFAICT, needs to be separate
<Kamion> the rest of them are as guaranteed to be synchronized as you can get
<Kamion> (I'm correct that we're disallowing main source from building restricted binaries, right?)
<mdz> Kamion: it seems logical to have such a restriction
<elmo_> yes
<|trey|> restricted modules package name is....?
<mdz> |trey|: apt-cache search restricted modules
<|trey|> mdz: restcted is removed... I don't need them, but I don't recall the name  :(
<Kamion> linux-restricted-modules-*
<thom> mdz: ok to upload firefox? 1:0.9.3-6 ; plain debian with our branding patches
<mdz> thom: replied to your email
<thom> ah, so you did
<thom> i should set strict threads on my inbox
<fabbione> hmmmm
<fabbione> thunderbird keeps crashing on me
<fabbione> just leaving it open
* thom sticks his fingers in his ears and whistles
<thom> mdz: replied
<seb128> mdz: ok to upload the patch in #1643 ?
<mdz> seb128: is this a functional issue or a cosmetic/display issue?
<seb128> functional. For the moment the default workgroup for samba in nautilus is WORKGROUP
<seb128> if you want to change that the only way is to edit the gconf key directly (no UI)
<seb128> with the patch it uses the workgroup in smb.conf if the file exists
<thom> mdz: i was thinking about this earlier
<thom> using an epoch is cleaner
<mdz> seb128: I see
<mdz> thom: epoch make baby jesus cry :-(
<thom> but i suspect it's going to cause much pain later on when we want to remerge from debian
<seb128> yeah, the epoch is bad
<thom> the monstrosity is also going to make baby jesus cry, but probably not so much
<elmo_> for a temporary reversion, I tend to agree we should use a fugly but non-epoch-ful version
<mdz> the concatenated version seems less evil because the existing version is already a concatenated monstrosity
<thom> yeah
<mdz> wtf is 0.99 anyway? was there ever such a version?
<thom> we're going to have to munge all the language packs, either which way
<elmo_> let's face it - mozilla-firefox makes baby jesus cry.  version numbers don't even need to enter into it
<thom> mdz: 1.0PR sorts higher than 1.0
<mdz> thom: how many/which language packs will we get with 0.9.3?
<Kamion> epoch would break dependencies later => bad
<Kamion> (in ways we can't fix)
<thom> mdz: ~11
<mdz> thom: sold
<mdz> shall we stage this someplace?
<mdz> or just go for warty?
<thom> i'll stage it, but it'll have to wait for tomorrow morning now :/
<Kamion> ~11 as in use the ~ thing?
<thom> Kamion: as in about
<Kamion> ah, sorry
<Kamion> panicked for a second :)
<mdz> hehe
<mdz> Kamion: you know, we probably *could* get away with that :-)
<thom> Kamion: *g*
<thom> mdz: aaaaaiee
<mdz> our apt and dpkg both have support for it, our version would still compare positively to woody
<mdz> but let's not, hmm? :-)
<thom> mdz: agree 100000000% 
<thom> anyway, i need to go catch up with friends for dinner
<mdz> thom: if it's a matter of doing builds and setting up a repository, I can do it if you need to go
<elmo_> katie will slap you down if you try
<Kamion> mdz: run awaaaaaaaaaaay
<|trey|> mdz: Ubuntu shouldn't compare to Woody, should compare to Sarge...
<thom> mdz: ok, will send you the current diff for firefox
<Kamion> won't woody's apt fall over if you try to do that?
<Kamion> |trey|: we don't and can't support upgrades from sarge.
<mdz> |trey|: the only officially supported upgrade path to warty is from woody
<Kamion> |trey|: since sarge is not yet released, and will release after us
<mdz> sarge is newer
<elmo_> Kamion: no
<pitti> mdz: shall I ask elmo to sync libsasl2 (#1899), or did you already take care of this?
<thom> mdz: sent
<|trey|> Kamion: I have a Sarge CD... Sarge was supposed to be released on the 12th... its pretty close...
<mdz> pitti: please do
<elmo_> using ~ is in fact entirely feasible, just untested and would require some emergency katie surgery
<Kamion> |trey|: I am one of Sarge's release managers; if you want more authority I can find the other one
<mdz> it is entirely feasible, the only problem is that it would be a pointless risk
<|trey|> Kamion: ha, imma shut up now  :)
<mdz> I don't think the tools choke on '~' or anything in woody, they just don't use the magic
<pitti> elmo_: Can you please sync cyrus-sasl2 from Debian? See #1899, mdz approved it. 
<mdz> justdave: could you hit #1379 one more time?
<thom> mdz: (grab firefox 0.9.3 orig from debian)
<elmo_> pitti: it's not on the mirror we use yet - please mail me
<pitti> elmo_: okay, I do
<thom> *gone*, good night folks
<seb128> mdz: so, the smb/gnome-vfs patch, do we want it in ?
<seb128> good evening thom 
<mdz> seb128: right, sorry.  I've read it and it seems fairly safe.  Assuming that both you and James are confident in it for Warty, it's OK with me
<seb128> ok, thanks
<mdz> Kamion: so about ubuntu-meta...
<Kamion> did you see my comments this morning?
<mdz> yes
<mdz> I've made it sort the output
<mdz> the exceptions are going to suck a bit
<mdz> so I'm thinking about lowering my expectations
<mdz> maybe we should just do this by hand for Warty
<Kamion> sorry about the arch-specific blacklists
<Kamion> don't have a wiki syntax for those yet
<mdz> well, if there were a way I could authoritatively test it, that'd be fine
<mdz> is there already a list someplace of what this thing should spit out?
<Kamion> for ubuntu-base, compare to debootstrap
<mdz> ok
<elmo_> kamion: hmm, has germinated changed much recently?
<Kamion> for ubuntu-desktop, take two fresh warty debootstraps, and do 'apt-get install ubuntu-desktop' in one and 'aptitude install ~tubuntu-desktop' in the other
<Kamion> 2004-09-22 23:38:50 GMT Colin Watson <colin.watson@canonical.com>       patch-5
<Kamion> elmo_: that's the last code change
<Kamion> hm, and that was cosmetic
<Kamion> so no
<elmo_> ok, mine's still doing screwy things with ored deps
<elmo_> not sure what version I'm on tho, meh
<Kamion> tla tree-version?
<elmo_> colin.watson@canonical.com--2004/germinate--mainline--0
<Kamion> hm, is there something that gives the patch number?
<elmo_> looks like I was on -3
<mdz> Kamion: but we already know that aptitude install ~tubuntu-desktop is buggy :-)
<Kamion> mdz: how so?
<Kamion> elmo_: -4 changes the wiki URL, -5 is cosmetic, so ...
<mdz> Kamion: is it not still doing that gs-esp weirdness?
<Kamion> mdz: oh, is that aptitude's fault? I think I missed the resolution of that
<mdz> Kamion: I think it was aptitude and germinate having different ideas about resolving deps
<mdz> Kamion: and germinate seeming more reasonable in this case
<Kamion> well, compare against aptitude and check the differences by hand
<mdz> Kamion: perhaps ubuntu-meta should just use debootstrap to work out the package list?
<mdz> (for base)
<mdz> that seems a bit more fragile when doing updates, though
<elmo_> kamion: okay, well, is it pulling in dialog for you because of alsa-utils for you?
<elmo_> it is for me, and should be pulling in whiptail instead
<Kamion> elmo_: not here
<elmo_> neat
<Kamion> warty/i386?
<elmo_> yeah
<Kamion> oh, dialog's in universe, so I won't be seeing it
<elmo_> well, I dunno which one is doing it to be fair, lemme try and reduce it to a given Packages/Sources
<Kamion> hmm
<Kamion> so you cat all the Packages and Sources together, is that right?
<elmo_> all the components, for each arch yeah
<Kamion> lftp rocks far too hard
<Kamion> lftp archive.ubuntulinux.org:/ubuntu/dists/warty> zcat main/binary-i386/Packages.gz > main-Packages
<mdz> yes it does
<Kamion> that just Should Not Work in an FTP client :)
<|trey|> Out of curiosity, who do I praise about the Human icons?
<Kamion> elmo_: OK, can reproduce after concatenating all the files
<Kamion> elmo_: dialog is the first alternative, though ...
<elmo_> well.. sure.. but it's pulling in whiptail for something else :)
<Kamion> elmo_: and whiptail isn't explicitly seeded, it gets pulled in by other stuff
<Kamion> if it were explicitly seeded it'd probably make the right decision
<elmo_> ok
<Kamion> the only fix I can think of would be to defer all alternated-dependency resolution to a subsequent pass
<elmo_> yeah
<Kamion> and pick some arbitrary minimal set
<elmo_> well, I'm easy with either .. for  now, I can just hax0r the seed lists
<elmo_> (err, either meaning, the other possiblity being to fix the packages)
<elmo_> which is obviously no longer an optioin
<elmo_> esp. X
<Kamion> at the moment it just arbitrarily picks the first alternative if it's not already satisfied (which might either be by a seed or by whatever the processing order happens to be
<Kamion> )
<Kamion> you could also use a hint
<Kamion> i.e. 'base whiptail' or whatever
<elmo_> am I meant to have any hints?  I don't
<Kamion> not unless you wanted them
<Kamion> they're local seed overrides
<elmo_> that worked, thanks
<elmo_> kamion: hmm,e xcept for the gcc-3.2 chain of doom
<mdz> any preferences for the firefox version number?
<mdz> 0.99+1.0PR.1+really0.9.3?
<mdz> 0.99+1.0PR.1+reverted0.9.3?
<Kamion> yarrr, suppose I should spend a day on germinate hacking sometime then
<Kamion> is it urgent (i.e. pre-warty)?
<elmo_> kamion: no, doesn't matter, you just reminded me of it by talking about germinate
<Kamion> ah, ok, good
<mdz> Kamion: any exceptions or such in desktop that I need to worry about?
<mdz> I've fixed up ubuntu-meta to check itself against debootstrap
<Kamion> mdz: don't think so
<mdz> Kamion: new version at http://people.ubuntulinux.org/~mdz/temp/ubuntu-meta_0.1.tar.gz
<Kamion> will look later, about to get dragged out
<Kamion> mdz: BTW, acx driver seems to load its firmware successfully with my new udeb
<mdz> Kamion: nice! can I test ipw2200 for you?
<Kamion> mdz: lots of encouraging noises in the syslog, although it doesn't actually *work* for reasons undetermined
<Kamion> mdz: are you happy to hack up an image yourself or do you want me to do it? I can give you an image later tonight
<mdz> Kamion: ah, I didn't realize you had a system with an ipw2200 to test
<mdz> Kamion: I can wait
<mdz> I would like to get ubuntu-meta in ASAP though
<Kamion> I don't, but I can do the image nevertheless
<mdz> Kamion: oh, I thought your second comment was about ipw2200, but I guess you still meant acx
<Kamion> ah, yes, right
<Kamion> well, bunch of .old files in that package which I assume you'll remove
<mdz> heh, just realized that a ton of people are going to remove ubuntu-desktop
<mdz> because everyone uses totem-xine instead of totem-gstreamer
<Kamion> looking
<mdz> that's like the FAQ of all FAQs on #ubuntu
<Kamion> mdz: looks reasonable to me, although I haven't checked the package lists; the proof of whether it works is likely to be in users' reactions
<Kamion> mdz: I'm scared of making the installer use it though; would rather have it stay with the task for now
<mdz> Kamion: oh, I completely agree
<mdz> its only real purpose is to propagate additions to the seed lists
<Kamion> mdz: would it be possible also to check that everything in ubuntu-desktop has a Task: ubuntu-desktop line?
<mdz> I'm going to do the following test:
<mdz> debootstrap a fresh warty
<mdz> install ubuntu-base and make sure no deps are unsatisfied
<|trey|> Kamion: can't you make it depend one or the other (many packages do this)
<mdz> aptitude install ~tubuntu-desktop
<mdz> check that no deps are unsatisfied
<mdz> I'll check the Task: headers too
<Kamion> |trey|: don't understand what "it" refers to there
<|trey|> it = ubuntu-desktop
<Kamion> |trey|: -> mdz :-)
<mdz> that sort of misses the point
<Kamion> |trey|: I'm just looking over his package before upload
<|trey|> Kamion: I knew that  :)
<mdz> the idea is to have it pull in everything in the standard desktop set
<|trey|> mdz: people need pr0n though, either figure out how we get pr0n via -gstreamer, or let us use -xine cuz it works  :)
<mdz> eventually, totem-gstreamer will work as well as totem-xine or better (we hope), and then we can tell everyone to just install ubuntu-desktop and get back what we think is best as of that day
<mdz> I don't even find totem-xine to work particularly well
<mdz> in terms of playing video streams found on the internet, mplayer is still king
<mdz> for all its awfulness
<|trey|> mdz: if -gstreamer is listed first, it will be installed be default... but it makes sure people don't remove ubuntu-desktop, which will allow for easier management of packages for you all  :)
<mdz> if people deviate from the desktop configuration, we respect their choice
<mdz> but it's all or nothing
<|trey|> mdz: "heh, just realized that a ton of people are going to remove ubuntu-desktop ; because everyone uses totem-xine instead of totem-gstreamer"  <-- just trying to make this not happen in a sensible way...
* Kamion heads off; back around 11
<mdz> Kamion: thanks
<mdz> |trey|: people _should_ remove desktop if they choose totem-xine over totem-gstreamer
<mdz> that's not even a supported package
<|trey|> mdz: good point... but that isn't really respecting choice.. it makes their choice cause problems
<mdz> it doesn't cause problems
<|trey|> if you change package sets via ubuntu-desktop, it would over time, and if thats not the plan, the package would appear useless?
<mdz> that's an exaggeration
<|trey|> (for instance, replacing fam with gamin could be done by a conflict and depends in ubuntu-desktop, if you did this, they wouldn't get the change)
<mdz> as was my "everyone"
<mdz> the idea is not to force things on people, it's to provide a way for them to keep up if they want to
<|trey|> mdz: ok... I just think there should maybe be choices allowed within the package... not everyone has the same exact tastes etc, but would still follow the general set...
<mdz> noted
<|trey|> :)
<mdz> lamont: ping?
<lamont> mdz: yo
<lamont> but about to go to lunch... 
<lamont> window obscured and all that... :-(
<mdz> lamont: I need a firefox built on all warty architectures
<mdz> lamont: http://people.ubuntulinux.org/~mdz/firefox/
<lamont> sigh.
<mdz> should keep the machines busy while you're at lunch :-)
<lamont> yeah
<lamont> but not uploaded, yes?
<mdz> correct
<lamont> building.  will advise when I get back
<mdz> thanks
<|trey|> lamont = build master or whatever? (forget correct term)
<Keybuk> you're too young to know the correct term for lamont :p
<hazmat> is inotify in the ubuntu kernels?
<|trey|> GNU is older then me I think   :(
<hazmat> i wanted to do some beagle development, and inotify in the kernel is a prereq at the moment
<Keybuk> hazmat: inotify is just a *wee* bit under development
<|trey|> I think announcement was Febuary? So by a month  8)
<Keybuk> heh, that makes you older than daniels, I think
<hazmat> Keybuk, good point, but so's the linux kernel ;-)
<|trey|> I wasted too much time during high school... could have been learning languages, instead was getting high  :/
<Keybuk> hazmat: heh, last time I played with that it needed a version of inotify rml hadn't actually released yet
<hazmat> Keybuk, fun quote. "The _reality_ is that there is _no_ point in time where you and Linus allow for stabilization of the main tree prior to release. The release criteria has devolved to a point where we call it done when the stack of pancakes gets too high.
<hazmat> -- Jeff Garzik "
<Keybuk> yeah I saw that :)
<hazmat> i'll see if i can get this patch to apply to the ubuntu kernel http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.13/
<Keybuk> there's a few rather major security issues on the todo list for it, aren't there?
<Keybuk> plus there's no way to make udev make the device node when it needs to yet
<hazmat> Keybuk, i'm fuzzy on the impl details, i've been following along from the perspective of wanting to work on beagle/dashboard, but my understanding if your using udev then its not an issue.. if your not the dev node needs to be managed by hand... re security.. dunno. i would hope it checks access against the watched
<|trey|> Wierd question, I filed a bug report enhancement pertaining to the menu, it doesn't appear to be in the db anymore, why would that be?
<mako> mdz: you around?
<mdz> mako: yep
<mako> mdz: i just saw your message to ubuntu-announce about the livecd
<mako> send tuesday or wahtever
<mdz> yes?
<mako> i haven't been checking -announce daily for moderator requests
<mako> so it didn't go out
<mako> two things
<mako> apparently, neither has jeff
<mako> so two things
<mdz> whoa
<mako> (1) should i sent it off on its way now?
<mdz> fabbione: I just upgraded xserver-xfree86 on amd64 and it asked me the driver question and the keyboard question
<mdz> mako: I was wondering why there were so few downloads of it
<mdz> yes, it should go out now
<mako> (2) since it's probabl just you, me, jeff, and mark that will be using that list, it's best to just poke me or cd me
<mdz> I don't remember getting a message telling me it was moderated
<mako> mdz: i will write have procmail redirect those requests into my main canonical box
<mako> mdz: maybe a filter caught it.. 
<mako> everything on that list is going to be moderated
<mako> including my own posts.. 
<mako> until we get something like key-based auth
<sivang> can anybody explain how to enable colors for c code in vim?
<mako> mdz: sent now
<mako> mdz: in the future, don't hesitate to poke me
<mdz> mako: I would have if I had realized it didn't go out :-)
<mdz> in fact I would have approved it myself
<mdz> justdave: ping?
<justdave> mdz pong
<mdz> sivang: -> #ubuntu
<mdz> justdave: can you follow up on #1379?
<justdave> done
<mdz> thanks
<mdz> fabbione: never mind, false alarm
<seb128> justdave: any news for the upstream status ? It would really help to sort the bug list
<justdave> seb128: I'll try to get in tonight. It should be pretty quick to throw in
<seb128> thanks
#ubuntu-devel 2004-10-20
<lamont> mdz: amd64/i386 built, ppc still chunking along.
<lamont> you want log files?
<mdz> justdave: at the point of the last message you see, does the system hang, power off, do anything?
<mdz> lamont: logs are not necessary; just copy the debs to rookery so I can put them up for download
<lamont> mdz: source and binaries (all 3 arch) at http://people.ubuntu.com/~lamont/mozilla - feel free to toss them somewhere else.
<mdz> lamont: thanks
<justdave> mdz: it just hangs
<mdz> elmo_: there seem to be packages in DesktopSeed which are lacking Task: ubuntu-desktop headers; is that normal?
<mdz> seem to be all gstreamer stuff
<mdz> e.g, gstreamer0.8-alsa
<elmo_> mdz: I just do it based on the 'desktop' output file of my germinate run
<mdz> elmo_: I think that stuff was added on 09-02; whet was the last time that was updated?
<elmo_> hmm, and gstreamer0.8-alsa is in there
<mdz> they show up in my germinate output
<mdz> hmm, I think apt is just being weird
<mdz> yeah, it's showing me the status file entry rather than the Packages file entry
<mdz> which is a very weird thing for dumpavail to do
<mdz> I guess it's playing its "the version numbers are the same so everything is cool" game
<jono> hi all
<jono> I am writing Linux Desktop Hacks for O'Reilly and we are looking for contributors to write a few hacks - would anyone be interested in getting involved?
<sivang> jono : what are those Desktop Hacks? :)
<jono> well, we are taking suggestions
<jono> we are writing 80 hacks and 20 are available for contributors
<jono> any cool ideas, mail them to me at jono AT jonobacon D-O-T org
<elmo_> heh, 'ubuntu-desktop' in Section: base
<justdave> mdz: new lead.  added ramdisk_size=8192 to the yaboot boot parameters, and successfully booted non-smp
<justdave> dropping a dmesg on the bug as soon as it finishes logging in
<mdz> justdave: how big is your initrd?
<elmo_> mdz: good god, that is the Depends line of doom - are you sure that doesn't overflow one of apt's static buffers at least in woody?
<justdave> mdz: the smp initrd is 4 MB even, the non-smp initrd is 3.8 MB
<mdz> elmo_: no clue about woody
<mdz> but woody users won't get that package upgraded anyway
<mdz> ubuntu apt is fine with it afaik
<mdz> justdave: stinks of weird bootloader problems
<mdz> elmo_: the stanza is only slightly larger than the d-i Sources one
* justdave reboots again to see if it's yet another fluke or if it's consistant this time
<justdave> it's a fluke
<justdave> just booted without the ramdisk_size thing and succeeded
<mdz> justdave: have you upgraded since the last time you tried?
<justdave> still has devfs in there though.
<justdave> no.  I did update the kernel yesterday, but before my previous attempts.
<justdave> oh, and yaboot does let you pass kernel params from the boot prompt
<justdave> took all the garbage out of yaboot.conf, and experimenting from the boot prompt now that I proved that
<justdave> ok, just got it to hang again
<justdave> only changed from the previous boot was the "idebus=66" got removed.
<justdave> one more attempt, same params, just to make sure, still hangs
<justdave> added idebus=66 back in, still hangs.
<justdave> so there's apparently no pattern to it
<justdave> added video=ofonly in addition to the idebus=66 and it booted
<justdave> btw, the new startup sound is cool, I like it :)
<justdave> ok, just successfully booted it with the default command line.
<justdave> so the command line options are another red herring
<justdave> appears to be just luck or timing or something
<mdz> justdave: so basically, it happens on UP and SMP systems, and regardless of the kernel command line
<Kamion> sivang: ':syntax on'
<justdave> seems that way.
<mdz> justdave: try unplugging all your USB devices when you boot
<mdz> and 1394
<Kamion> justdave: yaboot lets you pass kernel parameters from the boot prompt as long as they aren't initrd= (well, you can pass it, but it's not useful), which is kind of annoying
<sivang> Kamion : you're replying my vim question? :)
<Kamion> sivang: yes
<justdave> no 1394 on it right now.
<sivang> Kamion : boy that was a while, thanks!
<justdave> I'll have to change the default kernel in yaboot to do that. :)  my keyboard is USB :)
<mdz> Kamion: any idea about #1379?
<mdz> justdave: you can plug it in after boot if it works
<mdz> justdave: just try it and see if it makes a difference
<mdz> oh, you mean you need to change yaboot.conf
<Kamion> sivang: it's IRC, it often has a big delay built-in
<justdave> yep, done.
<justdave> booting...
<sivang> Kamion : yes, I've got used to it by now ;-)
<Kamion> mdz: I haven't had any idea about that since the start
<justdave> (well, powered up -- still waiting for yaboot prompt to timeout)
<justdave> ok, all USB and 1394 removed, it hung
<mdz> Kamion: I've searched around a bit and haven't found anything in Debian land
<mdz> besides that bug report you pointed out
<mdz> which doesn't seem to have any leads
<mdz> there goes my last idea
<mdz> that was from the YDL website
<mdz> Hang after install: If after install your computer hangs on re-boot, unplug any USB hubs you may have. An intermittent problem causes the hub to interact poorly with the CUPS printer software. 
<mdz> that sounded fairly promising, since the CD boot was working and not the HDD boot
<mdz> of course, this is hanging way before CUPS starts
<mdz> what bootloader does the CD use on ppc?
<Kamion> yaboot
<Kamion> there's no other sensible option
<justdave> plugged the USB stuff back in and booted, and it worked.
<Kamion> bah, linux-kernel-di-{i386,powerpc}-2.6 failed to build
<Kamion> ... and it was because I'm dim
* Kamion fixes
* carlos was able to downgrade debian sid into debian warty without major problems
<carlos> do we want a kind of howto about it?
<mdz> carlos: only with BIG BOLD BLINKING warnings :-)
<carlos> sure :-)
<carlos> wiki or website ?
<mdz> wiki, I suppose
<carlos> ok, I will do it tomorrow. Good night
<sivang> why would someone like to downgrade from sid to warty anyways? :-) 
* sivang hides form mdz
<sivang> wow, just noticed the girl on the artwork....the best default livecd background I've yet to see...
<sivang> mdz : would it be reasonable to push in stuff to yelp before the release (no further than the 17th) as this does not fall even under special circumstances? although yelp might not be effecting too much I suppose.
<mdz> sivang: what kind of stuff?
<sivang> mdz : I am not sure it will be ready for this, but just in case it will. It this listed under "roadmap" in http://wiki.ubuntulinux.org/DocumentationTeam.
<sivang> mdz : if you have any comments, suggestions I'd be glad if you could mail me in , or on -devel. I'm hitting bed now, this time _for_real :)
<sivang> nighters everybody
<daniels> ha ha ha, oh man
<fabbione> oh god
<fabbione> mdz: LATER is not even documented
<fabbione> and imho it means that it will be fixed later
<fabbione> that also means that after release all LATER bugs will be reopened
* justdave hates LATER
<justdave> that should be a status, not a resolution, if we have it at all
<daniels> RESOLVED/LATER is interesting
<daniels> because then the bug just falls out of our BTS
<daniels> i think setting the target milestone to Hoary is far better, IMO
<justdave> the only reason that's not gone from Bugzilla upstream already is because customizable statuses was coming down the pike, and we didn't want to screw over people that were actually using it before they had an easy way to put it back.
<justdave> except the guy who was working on the customizable statuses dropped off the face of the planet
<fabbione> daniels: 2153 is your ;)
<daniels> fabbione: yeah
* daniels heads off to vote.
<mdz> fabbione: yeah, I am not so sure why we would use that rather than leaving the bug open and setting its milestone
<fabbione> mdz: same reason as i posted in the comment :-)))
<fabbione> it is not something that we can fix for sure for hoary
<mdz> fabbione: I don't want those bugs to vanish from the list of open bugs though
<fabbione> mdz: it's not vanished...
<fabbione> it's still in bugzilla
<fabbione> and i did plan to reopen tham afterwards
<mdz> to me, 'resolved" means it has been dealt with
<mdz> I know, I understand
<fabbione> well bugzilla is wrong
<mdz> heh
<fabbione> LATER is a "tag" not a status
<mdz> it is best if we all use the same semantics for handling bugs
<mdz> if you are using LATER and someone else is using a milestone, that's unnecessarily confusing for everyone
<fabbione> mdz: i don't disagree, what i wrote in the bug is: LATER because we don't know if it can be fixed for hoary
<fabbione> mdz: that's kinda different from a milestone
<justdave> maybe add a milestone called "Future"
<mdz> fabbione: "hoary" is our name for all of the time between the warty release and when the world crumbles into dust :-)
<mdz> anything that is not now or the past is "hoary"
<mdz> our list of feature goals is long enough to fill that time
<fabbione> whatever
<fabbione> i will reopen the bugs and mark them hoary
<fabbione> mdz: 2119 -> for me it's invalid
<mdz> fabbione: I didn't read the logs; what is the deal?
<fabbione> mdz: it's 24 to 16 bit and no DRI
<fabbione> + one obscure option that for sure i am never going to set by default
<mdz> fabbione: wait, I am rereading it and he is saying Ubuntu is faster
<mdz> and his problem is with userlinux?
<fabbione> no the other way around
<mdz> Ubuntu is
<mdz> marginally faster
<mdz> than UserLinux -- moving a card in freecell takes 5-8 seconds
<mdz> instead of 10-15 seconds.
<mdz> moving a card in freecell in UserLinux takes 10-15 seconds.  
<mdz> I think he has reported his bug to the wrong BTS
<chrisa> Someone is using freecell as a benchmark? That terrifies me
<fabbione> either he wrote to the wrong BTS or the wrong order of distros
<fabbione> both cases -> INVALID
<mdz> yep
<mdz> I did not see that before for some reason
<fabbione> wait
<fabbione> we can check in the logs
<fabbione> XFree86 Version 4.3.0.1 (Ubuntu 4.3.0.dfsg.1-6ubuntu23 20041004140652 root@terranova.warthogs.hbd.com)
<fabbione> he is talking about ubuntu
<mdz> uhh
<mdz> fabbione: both the fast and slow logs say Ubuntu
<hazmat> is it possible to have packages not install themselves into the rc.d directories by default.. ie make an admin explicitly enable them.. i just got myself locked out of my ubuntu system after installing openldap, and watching slapd hang the system during startup.. had to fix things with the install cd.
<mdz> fabbione: so either UserLinux is borrowing Ubuntu packages, or he is confused
<fabbione> mdz: exactly
<fabbione> mdz: do you where the userlinux archive is?
<fabbione> i can't find the pool
<jdub> fabbione: userlinux == sarge
<jdub> fabbione: apart from a few meta packages
<fabbione> It also doesn't configure the national language keyboard for X. It certainly shouldn't install any such thing without asking first. The country the box happens to sit in may determine it's time zone, but that's about it. Certainly not the language (there are often several in the same country anyway, and chances are none of them is English, but the admin still wants his computer in English)
<fabbione> That's from their wiki
<fabbione> it looks sooooo much as the bugs we get
<fabbione> jdub: they released an update the 17th of Sept.
<jdub> fabbione: sarge is updated all the time :)
<fabbione> jdub: our code is not in Debian
<fabbione> at least not the autodetection stuff
<jdub> fabbione: it seems, from the bug, they're saying userlinux but using ubuntu. simplest explanation.
<jdub> so, a couple of people have mentioned that they're not getting any sound at all
<jdub> and i think i've hit a similar situation
<jdub> snd-intel8x0 driver, nforce2 hardware
<fabbione> mdz: your announce is on distrowatch
<jdub> no amount of alsamixer tweaking has helped
<mdz> fabbione: I sent that Tuesday, and didn't realize it was waiting in the moderation queue :-(
<jdub> oof, really?
<jdub> i thought it had gone through
<mdz> live-i386.iso	634MiB	57	50	179	110.95GiB
<jdub> did you send it to deve or user too?
<mdz> jdub: mako just pushed it out today
<mdz> no, I think only -announce
<jdub> hrm
<mdz> some folks were listening, though -> 50 torrents
<jdub> sorry about that
<mdz> (more than the install CD right now)
<mdz> jdub: for some reason I don't think I got a notification saying it was held for moderation
<mdz> or I would have just taken care of it
<jdub> might've been the double-auth mailman thing i'm getting
<jdub> oh wait
<jdub> i'm not even on -announce moderation
<mdz> I thought the sender was notified too?
<jdub> should've been, yeah
<jdub> but you're also moderator
<jdub> i think
<jdub> oh, that's just ubuntu-security-announce
* jdub is stuck on console atm ;)
<jdub> could sharing an interrupt with ehci be an issue?
<mdz> depends on what with
<mdz> if it's a parallel  port or something, yeah :->
<jdub> the sound card
* jdub is talking about the sound issue
<mdz> oh
<mdz> is this the mixer-volume-is-up-and-it-looks-like-it's-working-but-no-sound issue?
<jdub> yeah
<mdz> haven't seen that one myself
<mdz> could be IRQ stuff, yeah
<jdub> a few locals are asking about it
<jdub> only *just* started happening on this machine
<jdub> previously, i was enjoying the just works sound/volume foo ;)
<mdz> interesting
<jdub> stuff under /proc/asound looks fine
<mdz> jdub: pci=noacpi?
<mdz> noapic?
<mdz> those are my stock answers to everything these days :-)
<mdz> headache? noapic
<jdub> haven't tried them... will do now
<mdz> toothache? pci=noacpi
<jdub> haha
<mdz> people look at me funny
<fabbione> ahaha
<daniels> mdz: no more jellybeans
<daniels> thom: ping
<mojo> hi all fellow developers!
<mojo> I'm getting stuck with stupid Bug #1552
<mojo> too shit I am, can't find other way around to fix this, hope someone here give me a hand, let SSH to my box and fix it with me
<carlos> jdub: should we report missing icons from ubuntu-artwork?
<thom> daniels: ack?
<daniels> thom: ack-ack
* daniels tries to remember what he wanted two and a quarter hours ago.
<jdub> carlos: nah, they're known
<thom> daniels: heh
<thom> you're too young to be going senile
<daniels> thom: and you don't have that problem? :)
<thom> no, but i work around this problem by asking at the time :P
<daniels> thom: heh, fair cop
<daniels> oh, right.
<daniels> suspending on the X40.
<thom> ah?
<daniels> even when removing ehci, can't get it going with echo 3 > /proc/acpi/sleep, then coming back with echo 0 > /proc/acpi/sleep
<daniels> it never comes back, it just sits there with both the battery and sleep lights on
<daniels> any known issues?
<daniels> i.e. is this your acpi-support bong gone wrong? :)
<thom> no, acpi-support does nothing with suspend
<thom> hit the power button when it's suspended, what happens?
<daniels> suspended with ecoh 3 > /proc/acpi/sleep?
<daniels> (the /proc/acpi/sleep stuff being my additions to lid.sh)
<thom> daniels: grab http://www.planetarytramp.net/acpi-x40.tgz
<carlos> jdub: ok
<daniels> thom: do I need the tpbutton stuff or whatever?
<daniels> thom: (fwiw, it froze, and I needed to reboot)
<thom> daniels: shouldn't do
<thom> hrm
<daniels> well, it works fine with x40
<daniels> but with mangling /proc/acpi/sleep, it freezes when resuming
<daniels> with your x40 stuff it doesn't actually suspend, however
<daniels> it just chvts
<thom> it'll only suspend if you're on battery
<daniels> ahr(se)
<daniels> hm
<daniels> so I did it on battery, and it hung :)
<thom> i've not tried with the current kernel tree, i have to admit
<daniels> this is just with 2.6.8.1-3-686
<thom> yeah
<thom> i (or rather mjg59) had a custom 2.6.7 where it worked
<daniels> any known gotchas?
<daniels> ah
<daniels> what were the patches -- acpi.sf.net?
<thom> that and one other i don't remember
<daniels> mjg59: ping?
<daniels> (own reference to avoid senility-related troubles: x40 acpi)
<sivang> morning/afternoon all
<thom> daniels: btw, you really need to push freedrtools, since otherwise we're gonna wind up with about 50 forks
<doko> anybody around who can/wants to review #2193?
<Kamion> doko: patch looks good to me, I'd been hoping somebody would investigate that
<doko> ok, so I'll upload that.
<doko> while you are here: did a fresh powerpc install, sound works, keyboard not.
<doko> kamion: which package writes /etc/environment on installation?
<Kamion> doko: prebaseconfig
<Kamion> combined with base-config
<Kamion> which reminds me ...
<Kamion> doko: keyboard doesn't work in what way?
<Kamion> anyone object to this patch to base-config?
<Kamion> -                       grep -v "^LANG=" /etc/environmment > /etc/environmment.new || true
<Kamion> -                       mv /etc/environmment.new /etc/environmment
<Kamion> (lib/menu/finish)
<carlos> mdz: ping
<Kamion> +                       grep -v "^LANG=" /etc/environment > /etc/environment.new || true
<Kamion> +                       mv /etc/environment.new /etc/environment
<doko> kamion: no, don't object. could you have a look at #2195
<Kamion> so my patch fixes the first half at least
<Kamion> and almost certainly the second; what breaks exactly?
<Kamion> "The file /etc/enviroment (without typo)"
<Kamion> :-)
<doko> how do I force dpkg-reconfigure console-common to ask for the language?
<doko> the grep in line 47 prints two lines.
<Kamion>         for var in LANG LC_ALL LC_CTYPE; do
<Kamion>                 value=$(egrep "^[^#] *${var}=" /etc/environment | cut -d= -f2)
<Kamion>                 eval $var=$value
<Kamion>         done
<Kamion> right, ok
<Kamion> so you mean /etc/init.d/keymap.sh I'm guessing
<doko> correct, thanks for thinking for me :)
<Kamion> that's such a crap script; why doesn't it just source the damn file?
<Mithrandir> it should use the interface provided by PAM, shouldn't it?
<Kamion> oh, yeah, duh, /etc/environment not a shell script
<Kamion> yes, it should use pam_getenv then
<Kamion> anyway, fixed
<doko> ok, keyboard works, after I manually reconfigure console-data to use the german keyboard.
<doko> why isn't this done correctly by the installer? wondering ...
<Kamion> doko: hm? it should be, isn't it just that base-config bug?
<doko> which one?
<Kamion> console-data is very bizarre, but the installer should set up the keymap
<Kamion> (even if it doesn't look like it has when you reconfigure console-data)
<seb128> doko: not sure than #2194 is a bug
<Kamion> doko: /etc/environmment for /etc/environment
<Kamion> if that screws over /etc/init.d/keymap.sh then it's maybe not too surprising that the keymap's broken?
<doko> seb128: believe me, it is. if you use two nomens in the singular form, you have to use the verb in the plural form.
<doko> s/nomen/noun/
<seb128> doko: on an another chan I've 2 people saying that "ist" is correct
<Kamion> doko: isn't it like English where if you use "or" the verb is singular, whereas if you use "and" the verb is plural?
<seb128> Kamion: I think so
<doko> ah, ok. I'll review that with the next installer.
<seb128> that's a "or" in this case .. so "ist" seems to be right
<doko> hmm, I'll review that in the "Duden", but it sounds wrong.
<Kamion> although I do remember a German class where we were told there was some weird grammar rule, but I don't remember exactly which way it went, hmm
<Kamion> I could believe either
<doko> seb128: which channel?
<seb128> doko: a gnome, but they are not translators afaik
<seb128> I'll try to ping a i18n guy
<carlos> seb128: we are missing some spanish translations for our gnome-panel changes, could you give me an updated .po so I could finish it?
<seb128> arg
<azeem> doko: use "ist/sind fehlerhaft" :)
<seb128> you (i18n guys) need to set a system up
<seb128> I can't keep to synchronize all sort of translations in all the packages in that way
<Kamion> The i386 daily CD image I just built should have support in the installer for ipw2100 and ipw2200 cards.
<Kamion> allegedly acx_pci too, but that didn't work for me
<seb128> carlos: that's not manageable
<Kamion> I guess I have a bunch of d-i translations lying around in bugs somewhere to integrate, too.
<Kamion> mdz: if you could test the current i386 CD on your ipw* box, that'd be good
<carlos> seb128: O:-)
<carlos> seb128: hoary time
<seb128> carlos: no seriously, people keep reporting translation updates/changes on different GNOME pieces
<seb128> carlos: merging the changes are a pain each time
<carlos> seb128: btw, changing the talk subject... the trash applet does not sees my iPod trash directory
<carlos> seb128: how do you handle that under Debian?
<Kamion> seb128: in fairness this *is* what carlos is working on full-time :-)
<seb128> carlos: we don't, that's upstream job
<carlos> Kamion: yes, that's the idea :-P
<seb128> carlos: BTW for the trash, please check with jamesh, he made the changes for monitor extra drives
<carlos> seb128: ok
* carlos did his first kernel patch today :-D
<carlos> and I'm able to use my iPod under Ubuntu as a normal user, finally !!
<doko> seb128, kamion: as usual: both things are ok, altough they say the singular finitum is more common.
<seb128> carlos: I've updated #941 to include the list of strings, if you do a translation include the full file with this format (no information about lines or so, it's problematic for updates when code change)
<seb128> doko: ok, so NOTABUG, ok ?
<carlos> seb128: ok, thanks
<doko> seb128: yes
* Mithrandir waves with his nvidia-glx package for amd64
<elmo_> hmm, lshw on amd64 is interesting...
<elmo_> it seems to be peeking through every single byte of memory
<Mithrandir> how so?
<Mithrandir> apart from it listing a fair bunch of hw, it seems fine here.
<elmo_> read(3, 0xb2e41811, 1428514031)         = -1 EFAULT (Bad address)
<elmo_> read(3, 0xb2e41810, 1428514032)         = -1 EFAULT (Bad address)
<elmo_> read(3, 0xb2e4180f, 1428514033)         = -1 EFAULT (Bad address)
<elmo_> read(3, 0xb2e4180e, 1428514034)         = -1 EFAULT (Bad address)
<elmo_> root      4560 32.1  0.0  2692  860 pts/48   R+   15:24   6:01  |           \_ lshw
<Mithrandir> weird, doesn't do that on my box.
<elmo_> heh, 'dpkg: warning 'amd64' not in the remapping table'
<carlos> pitti: here :-P
<pitti> carlos: yes, I remember
<pitti> carlos: the "I have to unload the module first" problem?
<carlos> no, that's not the bug I'm talking about
<carlos> pitti: the one that does not let me use the iPod after mount
<carlos> because the owner is root
<pitti> ah
<pitti> yes
<carlos> I did a patch (https://bugzilla.ubuntu.com/show_bug.cgi?id=2197)
<pitti> all files should be owned by you, but only the mount point itself is wrong?
<carlos> no, all files are owned by root
<carlos> well, in fact the problem is that all files have their original values, like when you mount an ext2/ext3 filesystem
<pitti> hmm, can you add the patch to the bug as attachment?
<carlos> it's in the upstream bugzilla, but yes, I could do it
<pitti> I think I cannot decide that, but mdz should. Maybe you should assign the bug to Herbert and CC mdz for approval?
<pitti> Would be great if that finally worked
<pitti> iPods are quite common
<carlos> pitti: no, that's not why I want to ask you :-P
<carlos> after reading some code, seems like my fix is wrong
<pitti> So?
<chrisa> The number of ipods I see on campus frightens me
<carlos> the hfsplus code implements the uid/gid options like a fallback when they don't have any posix information for a file
<pitti> ugh, that's ugly
<carlos> that information exists with iPods so the driver just ignore it
<pitti> I thought it should just map any root to the given uid
<carlos> me too :-)
<carlos> the problem with my patch is that if you mount it as root without uid/gid arguments, all files are owned by root
<carlos> that's why I'm not sure if my fix is valid
<carlos> no matter if you have a file owned by uid=500, next mount will show it as owned by root
<pitti> whatever you modified, can't you just check if uid != 0 before changing anything?
<carlos> so, the question is... How do you think it should be fixed?
<carlos> so if the current uid == 0 I don't change anything?
<carlos> yes, it's possible
<pitti> well, this is just my first thought, I've never seen the code
<carlos> don't worry about the code.
<carlos> think about ext2/ext3
<carlos> it does not have any feature that lets you map all uid/gid to one concrete uid/gid
<carlos> same as hfsplus
<elmo_> hmm, after upgrading the buildds to 2.6.8.1, I've had two in a row hang on apt-extracttemplates - strace shows it stuck in a futex.. anyone else seen this/know about it?
<carlos> I just need a suggestion (under your point of view) about a way to implement it :-P
<pitti> this uid= option is certainly supposed to be a hack anyway :-)
<pitti> but if some fs support it, all others should, too
* pitti looks at the patch
<pitti> hmm, just by looking at the patch I cannot see how it works
<pitti> so inode->i_uid is the uid that the file really appears under?
<Mithrandir> fabbione: around?
<pitti> carlos: and HFSPLUS_SB(inode->i_sb).uid is the uid that is saved on the iPod?
<pitti> carlos: in the patch I don't see the value of the uid=XXX mount option
<carlos> pitti: that's a "general" uid value that it's set on startup to the current uid or to the uid argument
<pitti> carlos: where is that stored=
<elmo_> nm, it's #1854
<pitti> carlos: s/=/?/
<carlos> pitti: inside that structure
<carlos> HFSPLUS_SB(inode->i_sb) is a kind of superblock struct
<carlos> pitti: it's initialized as:
<carlos> opts->uid = current->uid;
<carlos> 	opts->gid = current->gid;
<carlos> opts is HFSPLUS_SB(inode->i_sb)
<carlos> and then, it parses the options
<carlos> and updates those values if they are present
<pitti> carlos: phone, brb
<carlos> no problem
<pitti> carlos: back
<carlos> I'm looking at MacOSX for the way they handle it
<pitti> carlos: as you describe it, it should be fine to only update opts->uid to the override value if the latter is != 0
<pitti> carlos: since uid=0 makes not really sense, it can be regarded as "not set"
<carlos> latter == uid option or current->uid?
<pitti> carlos: the override value, so the uid= option
<pitti> carlos: but AFAICS you should not delete the lines in the patch then
<pitti> carlos: just override them afterwards if uid= != 0
<pitti> carlos: I did not see the whole code, but does that make sense?
<carlos> pitti: well the check should be if uid argument is given or not
<pitti> carlos: if you can decide that direcly, so much the better
<carlos> the problem comes when you don't use the argument :-)
<pitti> carlos: I thought that 0 (or -1) or whatever could be a default value if no uid= option is givne
<pitti> carlos: the code should work correctly if uid== is not given, right?
<carlos> if there is no uid given, the uid that is used is the process uid
<carlos> current->uid
<carlos> so perhaps I could do that check
<pitti> but that sounds wrong as well
<carlos> if current->uid ==  HFSPLUS_SB(inode->i_sb).uid, then I do nothing
<pitti> if no uid is given, it should use the uid that is saved on the ipod?
<carlos> pitti: yes, it does it that way, the problem comes with my patch :-)
<carlos> seems like hfsplus let you store files without posix permissions information
<pitti> carlos: ah, I see.
<carlos> and they are using the uid and gid options to give a default value for that case
<pitti> carlos: hmm, but if it does not have POSIX permissions, it should default to root, to be sure
<pitti> (which is then mapped to uid= of coruse)
<pitti> which is essentially the same, as I see now
<pitti> carlos: now I understood what they use the uid and gid options for currently
<carlos> well, the way they do it let a normal user mount it and all files with that information will be owned by that user
<pitti> so my proposal would be: set uninitialized uid/gid of files to root:root
<carlos> if I change it to 0 then I will break that case
<pitti> and later, when you evaluate the mount options, change all root files to uid=XXX
<carlos> makes sense, but there is still the problem when you mount it as a normal user from a fstab entry with the "user" option
<pitti> doesn't that imply uid=getuid() and gid=getgid()?
<pitti> it should
<pitti> ^^^ (as mount options)
<pitti> jdub: here
<carlos> don't know
<carlos> pitti: is that possible inside fstab?
<pitti> what?
<carlos>  uid=getuid(),gid=getgid()
<pitti> carlos: no, not in fstab
<pitti> carlos: it should be in the option parsing
<carlos> hmm
<pitti> carlos: if no uid= option is set, but 'user' is set, it should imply uid=getuid()
<carlos> so if there is a "user" option, then I should assume that?
<carlos> let me check...
<pitti> just as VFAT
<pitti> well, I had to try that out
<pitti> no, please forget that
<pitti> user does not imply uid=getuid(), sorry
<carlos> true I don't see that option inside the fat driver
<pitti> this is not done with VFAT, I just mixed that up, pmount explicitly gives uid=getuid() options
<pitti> if you use pmount, the 'user' option is not important anyway
<pitti> I think we don't need to consider the case where the iPod is in fstab
<pitti> it should work with pmount, so uid= and gid= has to work correclty
<carlos> well, it's not iPod but any hfsplus drive
<pitti> (more correct than my spelling, that is :-) )
<carlos> :-)
<pitti> right
<carlos> apple has the uid and gid options like vfat has
<carlos> so I suppose it's a good argument to use it that way
<pitti> so conclusively, you revert the patch and instead set the effective inode uid to the mount option only if the mount option != 0?
* carlos looks for the hfsplus documentation for a reference about what happens when there is no posix information...
<pitti> and maybe implement defaulting to root:root if no posix info is available for a file?
<carlos> pitti: yes, something like that
<pitti> carlos: well, anyting other than root makes no sense
<carlos> I will read the documentation first to be sure I'm not breaking anything
<pitti> carlos: anything other than root makes no sense
<pitti> carlos: of course it should be overridden by uid= afterwards
<carlos> yes
<carlos> pitti: funny:
<carlos> ownerID
<carlos>     The Mac OS X user ID of the owner of the file or folder. Mac OS X versions prior to 10.3 treats user ID 99 as if it was the user ID of the user currently logged in to the console. If no user is logged in to the console, user ID 99 is treated as user ID 0 (root). Mac OS X version 10.3 treats user ID 99 as if it was the user ID of the process making the call (in effect, making it owned by everyone simultaneously). These substi
<carlos> tutions happen at run time. The actual user ID on disk is not changed.
<pitti> phone again... sorry ...
<carlos> don't worry
<pitti> party this evening...
<carlos> :-)
<pitti> back
<Mithrandir> scary
* pitti cries out
<pitti> who invented this crap?
<carlos> pitti: Apple :-P
<pitti> the actual user ids on the disk should not be changed anyway
<carlos> groupID
<carlos>     The Mac OS X group ID of the group associated with the file or folder. Mac OS X typically maps group ID 99 to the group named "unknown." There is no run time substitution of group IDs in Mac OS X.
<pitti> so they have "root stays root" and "99 becomes the user in uid="?
<carlos> pitti: no
<carlos> root stays root, 99 becomes the user that is logged in
<pitti> oh no, sorry
<pitti> right
<carlos> and with latest MacOSX 10.3
<carlos> 99 becomes getuid()
<pitti> dynamically for every process then
<carlos> and then, they have the uid, gid options to change it at mount time
<pitti> so if both you and me are accessing the same file, both of us would think that the file belonged to us, right?
<carlos> pitti: no, dynamically for the mount command
<carlos> hmm
<carlos> perhaps you are right...
<pitti> well, what is "the call"?
<carlos> let me check it :-)
<pitti> file access or mount?
<pitti> but they say "making it owned by everyone simultaneously"
<carlos> we will know it soon, let me create a new user in my imac
<carlos> :-)
<pitti> but anyway, if that were already implemented like this in linux, the files should belong to you no matter whether it is mount or file access
<Mithrandir> could somebody review http://err.no/patches/linux-restricted-modules-2.6.8.1.2-3_2.6.8.1.3-1.amd64.diff ?
<pitti> so the current implementation neither fulfils the apple specs nor the usual uid=/gid= semantics
<carlos> pitti: true
<pitti> carlos: I think we should not use the uid 99 semantics
<pitti> carlos: because it could be a regular system user on somebody's computer
<pitti> carlos: and this could even be a security hole (because any user could then access files which are meant only for the user with id 99)
<carlos> pitti: it's owned by the process that access the device not the mount command
<pitti> carlos: so it's really the 'I belong to everybody' sematics?
<pitti> odd
<Mithrandir> pitti: 99 is statically allocated and in the range owned by base-passwd, though.
<pitti> Mithrandir: I know, but you know, there is always one person.. never mind
<carlos> pitti: yes
<pitti> It's not a big deal, but  I learned to be paranoid :-)
<Mithrandir> unix gives you enough blackpowder and rope to kill yourself in various ways.
<Mithrandir> that's a feature. :)
<carlos> pitti: if I'm root, I'm the owner, if I'm carlos, I'm also the owner :-)
<pitti> Mithrandir: yes, but if I shoot myself in the foot, then I should know what I'm doing
<pitti> carlos: probably it's not too bad to just implement Apple's semantics
<pitti> carlos: although I don't really like it
<carlos> pitti: the fact is that it's a hfsplus volume and the designer did it that way...
<pitti> carlos: I would not want to enable other users to overwrite my hfsplus files
<carlos> pitti: yes, that's my point
<carlos> pitti: btw, that will not happen if you use the uid/gid options
<pitti> carlos: OTOH I'm not really the one who can overrule Apple :-)
<pitti> carlos: oh, not?
<carlos> no, because it will not be 99 :-)
<carlos> it will be the uid you say :-D
<pitti> Mithrandir: I meant that I would not expect my files go world-writeable if I create an user with id=99
<pitti> carlos: but the file on disk has still 99
<carlos> pitti: but it's the hfsplus driver which changes it
<carlos> I will prepare a patch to follow Apple rules
* pitti slowly gets confused about so many different uids
<Mithrandir> pitti: well, true, but you shouldn't create a user with uid = 99. :)
<carlos> pitti: when it's ready i will show you it, perhaps it's easier to understand that way...
<pitti> Mithrandir: now I know that
<pitti> Mithrandir: :-)
<pitti> carlos: agreed. "Use the Source, Luke"
<carlos> :-P
<pitti> carlos: I think I now understood the problem
<pitti> carlos: BTW, you should put this Apple spec into the bug report
<pitti> carlos: then the patch can be verified against it
<pitti> guys, I've gotta go. In an hour 10 friends will arrive and I have to prepare the meal
<pitti> See ya later!
<pitti> carlos: Have fun implementing the stuff! :-)
<carlos> :-D
<carlos> pitti: have fun
<sivang> am trying to build a package, and I get this :" found. Your intltool is too old.  You need intltool 0.29 or later.
<sivang> "
<sivang> can anybody tell me why it does that? do we have a newer version of intltool ?
<sivang> it's a gnome package btw
<seb128> apt-get install intltool
<seb128> warty has 0.31.1
<sivang> seb128 : ok, thanks
<sivang> seb128 : it tells it's already the newest version 
<seb128> ok, so fix the upstream soft
<sivang> k
<|trey|> sivang: apt-get update && apt-get install intltool
<sivang> |trey| : thanks, already solved it. I had done something bad to my packages, so reinstalled from source and applied the changes back everything went to normal.
<elmo_> gar, how did we end up shipping without ethtool
<Mithrandir> mdz: ping?
<daniels> thom: yeah
<daniels> thom: the red hat guys are getting a little antsy
* daniels sleeps.
<mdz> Mithrandir: pong
<mdz> what's all this gs-esp stuff about?
<doko> mdz: see #2193, after a fresh install the installer wants to fetch tcl8.0, gs-gpl and gs, which are not on the CD. these patches resort the recommends/depends so that gs-esp (which is on the CD) satisfies the dependencies/recommendations.
<mdz> doko: did you test that it has the desired effect?
<doko> well, difficult to test. I hand edited the package list before the download started and no more packages were fetched from the net. no, I didn't build a new CD.
<mdz> ok
#ubuntu-devel 2004-10-21
<sivang> jdub : I have tried to modify gnome-system-tools package, if I dpkg-buildpackage -rfakeroot it without modifications, no prob. it makes a new deb.
<sivang> jdub : however, if I change anything inside /src  or /backends  it gets upset telling that intltool is outdated.
<sivang> jdub : I've been trying to add some code to it to enable me to do xml output dump outs to see what's going on the interfaces xml db, see #2221
<jdub> what are you changing?
<sivang> jdub : I tried to you xml_doc_dump (or something similar) to profile_save_interfaces.
<sivang> jdub : I also enabled debugging mode for the backend,
<sivang> jdub : so it won't trash my system's iface file and allow me to see errors.
<sivang> jdub : there was a debug flag commented on network-conf.in , I used it
<sivang> jdub : I'm headed to bed (4:45 am my time :) you can leave here comments if you have any idea ;) I'd appriciate it.
<sivang> jdub : better, on the bugtrail
<sivang> night all
<fabbione> mdz: ping
<fabbione> anybody around?
<mdz> fabbione: here
<fabbione> mdz: cupsys is up
<fabbione> i am working on emacs21
<fabbione> mdz: is the patch for emacs final?
<mdz> fabbione: upstream accepted it
<mdz> on the mailing list, RMS said to commit it, so I think that is good enough :-)
<fabbione> ok
<fabbione> wtf is wrong with dpatch
<fabbione> mdz: emacs is ready
<fabbione> ok to upload?
<fabbione> heck.. you gave me the patch ;)
<fabbione> goody we are down again to 13
<fabbione> later :-)
<doko> review wanted: patch for #2216 attached to the bug report.
<Mithrandir> mdz: nvidia; approval wanted.
<mdz> Mithrandir: has someone looked over it?
<mdz> and have you done the regression test on the i386 packages that we discussed?
<Mithrandir> mdz: fabbione thinks the nvidia part of it looks good; I've done a debdiff on i386, but I don't have any i386 with ubuntu at home
<mdz> debdiff should be sufficient
<Mithrandir> (debdiff on the binary packages, that is)
<mdz> if you would unpack it and checksum all the files, too, I wouldn't be opposed to that :-)
<mdz> that debian/rules seemed a bit clumsy
<mdz> (the original one)
<mdz> did you clean it up, or add an amd64-specific mess? :-)
<Mithrandir> somewhere in between -- I abstracted stuff a little, but I don't want to possibly destabilize the package this close to release.
<Mithrandir> I can unpack the packages and checksum, sure.
<Mithrandir> http://err.no/patches/linux-restricted-modules-2.6.8.1.2-3_2.6.8.1.3-1.amd64.diff is the diff
<Mithrandir> mdz: if you could look at it, test it on i386 and do whatever other magic you want to do, it would be most appreciated; I'll checksum it on i386.  If that matches, is it ok to upload?
* Mithrandir wanders off for breakfast and will look at the answer when he comes back
<cc> say, glibc has been "updated" to allow the time within gnome to be updated fixing gnome bug #19197 - can that make it before release?
<cc> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133481 is the bug thats fixed in Fedora, but still around in Ubuntu (just tested)
<daniels> mdz: ^^ looks like a reasonably non-intrusive patch to me
<cc> daniels: it is, and makes the UI more usable
<cc> also, how comfortable are ya'all if i link to RH bugzilla stuff in Ubuntu bugzilla?
<daniels> cc: as in, 'check out this Ubuntu bug', or intimate BZ linking?
<cc> daniels: no as in I'll file an RFE or bugreport in Ubuntu, link to a RH bz entry where the "fix" is, and hope ya'all integrate it :)
<daniels> cc: ah, right, sure :)
<daniels> cc: we don't really have RFEs, just bugs
<daniels> pick the right severity, that's all you need
<cc> daniels: yeah, just checking in case ya'all get annoyed or not. thanks.
<daniels> cc: that'd be great, thanks :)
<daniels> thom: dude, you need to set up a Planet for Planet developers
<daniels> thom: planet.planetplanet.org
* daniels is setting up a Planet for everyvoteforjohnhowardgodkillsakitten.org.
<pitti_> jdub: here?
<jdub> pitti: pong
<mdz> daniels: I don't see a patch there..the description in RH bugzilla sounds fairly straightforward, but to be honest, I think that touching glibc right now, for a feature, would be in very bad taste
<sabdfl> anybody able to help with a question on python packages?
<Mithrandir> sabdfl: shoot.
<daniels> mdz: s/patch/change/
<daniels> mdz: fair enough
<sabdfl> i have a directory call vocabulary
<sabdfl> inside that an __init__.py
<sabdfl> which imports * from two other files, call them foo and bar
<sabdfl> now, in another file, i want to import * from foo but I don't want to trigger the import of bar
<sabdfl> because of circular imports
<sabdfl> but when I do: vocabilary.foo
<mdz> wasn't this just discussed on the launchpad list?
<sabdfl> sorry
<sabdfl> could be
<sabdfl> when i do from vocablary.foo import * it seems to import bar as well
<mdz> foo imports bar?
<sabdfl> no
<sabdfl> foo and bar are independent
<sabdfl> it's the __init__.py that binds them together
<mdz> and when you import vocabulary.foo, it evaluates __init__.py?
<sabdfl> appears to
<sabdfl> >>> import canonical.launchpad.database
<sabdfl> --Return--
<sabdfl> > /usr/lib/python2.3/pdb.py(992)set_trace()->None
<sabdfl> -> Pdb().set_trace()
<sabdfl> (Pdb) bt
<sabdfl>   <stdin>(1)?()
<sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/database/__init__.py(4)?()
<sabdfl> -> from canonical.launchpad.database.person import *
<sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/database/person.py(14)?()
<Mithrandir> sabdfl: having __init__.py being __all__ = ['foo', 'bar' ] 
<sabdfl> -> from canonical.launchpad.interfaces.person import IPerson, IPersonSet,  \
<sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/interfaces/__init__.py(13)?()
<sabdfl> -> from canonical.launchpad.interfaces.bug import *
<sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/interfaces/bug.py(12)?()
<sabdfl> -> from canonical.launchpad.vocabulary.dbschema import *
<sabdfl>   /home/mark/projects/ubuntu/launchpad/lib/canonical/launchpad/vocabulary/__init__.py(2)?()
<sabdfl> -> import pdb; pdb.set_trace()
<sabdfl> > /usr/lib/python2.3/pdb.py(992)set_trace()->None
<sabdfl> -> Pdb().set_trace()
<sabdfl> (Pdb)
<sabdfl> Mithrandir: but I want to populate the __init__.py namespace with the contents of both foo and bar
<sabdfl> i want to refer to these things as canonical.launchpad.vocabulary.XYZ
<sabdfl> whenre XYZ could be in foo or bar
<mdz> this would seem to only be a problem because foo and bar are under 'vocabulary'; could they not be in an adjacent module rather than in the same one?
<sabdfl> that's why i have "from canonical.launchpad.vocabulary.foo import *" in __init__.py
<sabdfl> hmm... could be
<sabdfl> i could maybe create a vocabulary.py which imported them from adjacent files
<mdz> yes, or that
<sabdfl> does every directory in the module tree need to have an __init__.py?
<mdz> no
<sabdfl> ok
<sabdfl> let me play with that idea
<mdz> hmm, actually they do need a __init__.py if they have .py files in them, rather than extension modules and the like
<mdz> but it can be empty
<sabdfl> ok
<sabdfl> just ran into that problem :-)
<sabdfl> whadyaknow
<sabdfl> thanks mdz, Mithrandir
<mdz> I was still technically correct, since the top-level directory doesn't need a __init__.py :-)
<sabdfl> well, then you were correct both times, slightly differently
<mdz> I get the feeling that I should be asleep
<mdz> night
<sabdfl> night mdz
<hazmat> btw. i pointed out an important bug in sqlos txn integration the other day, svn should be updated.
<hazmat> txn aborts could lead to data corruption on subsequent commits
<Mithrandir> mdz: the checksums don't line up, but that seems to be due to timestamps for .a files and hardcoding of paths in kernel objects.
<doko> mdz: still there? what about the template translations for the installer packages?
<Mithrandir> doko: 12:40 < mdz> night
<daniels> Keybuk: hey ho
<Keybuk> heyhi
<daniels> sup?
<Keybuk> hungover :(
<daniels> heh
<daniels> f1 party? or did you also hold a massive post-.au-election wake?
<Keybuk> neither.  went out last night with an old school friend
<daniels> ahr
<lamont> bob2: optional:uncompiled isn't a state...
<bob2> oh
<lamont> but I'm checking
<lamont> universe/net/kismet_2004.04.R1-1.1: Installed [optional:uncompiled] 
<lamont> that'd be 'Installed'...
<lamont> Filename: pool/universe/k/kismet/kismet_2004.04.R1-1.1_i386.deb
<lamont> Size: 953826
<lamont> or which arch are you asking about?
<bob2> powerpc.
<bob2> sorry, didn't even think to check if it was built on another arch
<lamont> snacc is ftbfs on powerpc.  and kismet is dep-wait on that
<lamont> poke me tomorrow and I'll see what I can do about that...
* lamont must leave now, before blood is shed.
<bob2> sure, thanks a lot
<lamont> bob2: interestingly, snacc is now ftbfs on i386 as well..
<thom> nice, the firefox no scroll wheel crappiness has been confirmed and may even get worked on soon
<thom> mdz: just snagged the last security patch, getting ready to upload
<thom> (for firefox, i mean)
#ubuntu-devel 2004-10-22
<mdz> thom: the feedback on the 0.9.3 downgrade has been 100% positive, let's get it into warty straight away
<seb128> mdz: hey
<seb128> mdz: what about the new gst/totem packages and eagle-usb ?
<jdub> mdz: oof :)
<mdz> jdub: oof indeed
<seb128> jdub: hey :)
<thom> mdz: sat in the upload queue, although i think katie is sulking
<seb128> jdub: same question :p
<mdz> seb128: I thought I had upgraded to your new gst/totem, but I seem to have the same version as in warty
<mdz> seb128: could you give me the sources.list entry again please?
<mdz> thom: hmm. anyone roused elmo?
<thom> mdz: the last security fix was a one liner to a javascript file, which was a nice surprise
<mdz> thom: how very un-mozilla of them
<thom> mdz: just pinged him on jabber, will text in a second
<seb128> mdz: deb http://people.ubuntulinux.org/~seb128/gstreamer/  /
<thom> mdz: indeed - the bug talks of suggestions of monster changes, and then someone goes "why not change remove from true to false" and that's what they did 
<mdz> seb128: it is hard to say whether it is any better than the previous version; it still doesn't seem to play any video streams for me :-/
<mdz> seb128: is there any video encoding that it is known to play properly?
<seb128> theora ?
<mdz> mizar:[/space/video/misc]  totem http://mirror.fluendo.com:8800/
<mdz> zsh: segmentation fault  totem http://mirror.fluendo.com:8800/
<mdz> (after saying it could not play for unknown reasons)
<mdz> I had a theora stream which I tested with the previous version
<mdz> the A/V sync was way off and the video choppy
<mdz> ah, it was the RMS thing, I'll retry that
<seb128> "totem http://mirror.fluendo.com:8800/" works here ...
<mdz> hmmm
<mdz> ii  totem-gstreamer     0.99.17-0ubuntu1    A simple media player for the Gnome desktop based on g
<mdz> \
<mdz> ii  libgstreamer0.8-0   0.8.7-1             Core GStreamer libraries, plugins, and utilities
<Mithrandir> mdz: I've read through the binary diff and it seems the only things changed are timestamps and compiled-in paths (from the build directory)
<seb128> mdz: yeah, current versions ...
<Mithrandir> mdz: so if I could get permission to upload, I'd be very glad.
<mdz> hmm, it is playing now
<mdz> second try
<seb128> weird
<mdz> Mithrandir: OK
<elmo_> I _really_ think #1854 needs bumped to RC
<mdz> seb128: does gstreamer default to esd output on new installs?
<elmo_> it's what's killing katie on jackass
<mdz> seb128: mine seemed to be set for OSS, but I may have opened gstreamer-properties at some point
<seb128> mdz: I've not changed the patches
<elmo_> "don't use SMP kernels" isn't really a very good answer
<Mithrandir> elmo_: what kind of box is jackass?
<elmo_> Mithrandir: how do you mean ?
<mdz> seb128: it still segfaults when I exit totem
<Mithrandir> elmo_: cpu type?
<Mithrandir> (and number)
<mdz> elmo_: well, after Mithrandir you're the first person to be able to reproduce it, so by all means...
<elmo_> 1 3.2Ghz Xeon HT
<jdub> seb128: i support upgrading gst as a natural bugfix release from gnome
<elmo_> but I also saw it on apt-extracttemplates on one of the 3.06GHz Dual Xeon boxes
<jdub> (ie. 2.8 desktop packages)
<jdub> and then totem on top of that is not a huge worry
<seb128> ok
<mdz> seb128: anyway, it doesn't seem to be any more broken than the previous version
<Mithrandir> mdz: I think it's triggered by HT somehow, and HT isn't that common.
<mdz> it still doesn't play theora streams or anything else for me
<seb128> mdz: according to upstream a lot of bugs have been fixed
<seb128> ok to push it ?
<mdz> I can get about 2-3 frames from it and then it never draws a new frame
<mdz> sure
<seb128> we don't have a lot to loose, totem-gstreamer didn't work fine in all cases
<Mithrandir> mdz: I'm going to try to reproduce it on a friend's FC box, in an ubuntu chroot, if so, we should find out whether it's the kernel or glibc (or possibly still unknown)
<elmo_> Mithrandir: ?? it's ridiculously common in servers
<mdz> seb128: I agree
<mdz> elmo_: you're probably the only one on staff running Ubuntu on that grade of server at the moment
<seb128> ok thanks
<Mithrandir> elmo_: I think we have a small market share when it comes to workstations, but our server market share is probably ~0% on servers.
<Mithrandir> uhm s/on servers//
<Mithrandir> since people are a lot more likely to jump on the "new shiny distro" wagon for workstations and home boxes than for servers.
<elmo_> Mithrandir: dude, we can't ship a product where gzip doesn't fricking work on any modern server and expect to be taken seriously
<seb128> mdz: and about eagle-usb ? Sorry to ask again, but some french guys would be happy to get the change, and I don't think that eagle-adsl is used a lot, should not problematic neither ...
<Mithrandir> elmo_: no, we can't, I'm just trying to guess why nobody but us two have stumbled across it so far.
<mdz> seb128: ok, so currently we have neither eagle-adsl nor eagle-usb in warty, they are alternatives to each other, and you propose that we add eagle-usb to supported?
<Mithrandir> I think it's a timing issue somewhere, since the only way to reproduce it is to run apt-extracttemplates a bunch of times.
<Mithrandir> and strace makes the timing slightly off, so the problem then disappears.
<mdz> Mithrandir: nothing else with a gzip pipeline triggers the problem?
<Mithrandir> mdz: not that I've seen
<seb128> mdz: hum, let me checked, but one should be in the shipped seed
<mdz> elmo_: if you can put me in a position where I can debug it, I'll have a go
<mdz> seb128: neither one seems to be in main
<mdz> seb128: I thought we had discussed this before and agreed on it
<Mithrandir> mdz: I can give you root on the box if you want, no problems. :)
<mdz> Mithrandir: ok
<mdz> Mithrandir: shall I send you an ssh key?
<seb128> mdz: ok, eagle-usb-utils is in the shipseed
<seb128> mdz: I've pinged you 2 times, but never go a "ok" ... you asked for details and we didn't get a conclusion
<Mithrandir> mdz: just sent you a mail with host name and password; hope you have your key nearby.
<seb128> mdz: BTW the module in the kernel package is the -usb one and the package is in the seed, so I'll upload it if you're ok
<mdz> seb128: ok, my apologies
<seb128> no problem
<mdz> seb128: is eagle-usb-utils sufficient?
<seb128> yes
<mdz> 12	2004-09-24 00:38:11	852		MattZimmerman	add eagle-usb-utils
<mdz> seb128: so we did agree and I added it to the seed
<seb128> hum
<seb128> there is a -data too
<mdz> if we need the -data, that is fine with me
<seb128> ok thanks
<seb128> mdz: perhaps we agreed but I missed the agreement :) BTW that's ok now, thanks
<elmo_> that's just fucking typical.  I reboot 19 machines when I'm physically there and they all come back fine. I reboot one machine when I'm 200 miles away and it dies
<mdz> Mithrandir: yeah, I am at home.  logged in now
<mdz> Mithrandir: so what's the easiest way to reproduce it?
<mdz> elmo_: no iLO goodness?
<Mithrandir> mdz: cd /var/cache/apt/archives 
<Mithrandir> then run apt-extracttemplates apache2-mpm-worker_2.0.50-12ubuntu3_i386.deb
<Mithrandir> like ten times.
<mdz> I just did apt-extracttemplates *.deb and it hung right away
<elmo_> mdz: no, not for this machine
<mdz> fucking gdb
<Mithrandir> mdz: have fun. :)
<mdz> elmo_: there's a much simpler workaround than "don't use SMP"; just disable TLS/NPTLS/whatever
<elmo_> mdz: blah, well, a little late for that now
<Mithrandir> "disable NPTL" isn't an option in many cases either, though.
<mdz> only if you're running a billion threads
<Mithrandir> mdz: that's just my workstation, so feel free to hack away on it, but please don't kill /home, fyi.
<Mithrandir> lamont: care to adjust PaS for linux-restricted-modules?  There's a version I'm uploading now with amd64 support.
<mdz> (gdb) bt
<mdz> #0  0x40108721 in pthread_setcanceltype () from /lib/tls/libc.so.6
<mdz> (gdb)
<mdz> gdb is so fucking useless with tls
<mdz> Mithrandir: nice bandwidth :-)
<Mithrandir> mdz: university network, so 100Mbit straight to the box.
<Mithrandir> would have been nice with gbit, but it doesn't really matter.
<doko> mdz: what about #2204 and #2216 for warty?
<mdz> doko: 2204 is a one-liner, right?  OK with me
<mdz> doko: regarding 2216, could you explain the problem a bit?
<doko> mdz: 2204: yes. 2216: a file is deleted during the build. the patch makes sure that this file exists at all times and the python modules gets built.
<mdz> doko: I don't understand the original problem, though. if this file is important, why is it disappearing?
<doko> if I understand it correctly:   * debian/rules: Added a workaround for python/libxslt-py.c file to recover
<doko>     its original state after build (to avoid pollution of svn and diff file).
<doko> but that fails, if you build the package twice.
<doko> (changelog from 1.1.6-1)
<mdz> so the file is modified during the build, and the packagaing was trying to restore it?
<doko> exactly, and misses the fact that it's remove by make realclean
<mdz> doko: ok, thanks, I understand.  OK to upload
<mdz> Mithrandir: I have a workaround for apt-extracttemplates at least
<mdz> did elmo say if he saw it anywhere other than in apt-extracttemplates?
<mdz> I don't think katie uses that
<mdz> it's seeming like a glibc bug
<Mithrandir> mdz: ok, what would it be?
<mdz> Mithrandir: apt-inst's extracttar does this funny thing where it sends a signal to gzip right when it's supposed to be exiting, to make sure it's gone
<mdz> Mithrandir: if I turn that off, it never hangs
<Mithrandir> ok
<thom> argh, it's 1am
* thom goes to bed
<doko> ugh, jackass is down?
<thom> yeah
<thom> elmo is en route currently
<doko> from where?
<thom> from his house to the data center
<doko> this are a few miles ... :-(
<thom> at this time of night, it's easier for him to drive than for me to try and get there *sigh*
<doko> shit happens.
<doko> good night!
<daniels> ahar!
<daniels> thom: all you need is acpi_sleep=s3_bios for x40 suspend
<daniels> thom: mind if I package your /etc/acpi as acpi-support-x40 or something?
* Mithrandir goes to bed
<daniels> thom: (after cleaning it up a bit)
<thom> no, not at all
<lamont> Mithrandir: PaS is an elmo thing.
<daniels> thom: rad, thanks
<daniels> thom: my 'X40 on Ubuntu' page will consist of: 'First, boot with linux acpi_sleep=s3_bios when you install.  Secondly, when you're done, add in this APT source, and install acpi-support-x40.'
<thom> heh, nod
<mjg59> Teh x40 is teh rock
<daniels> mjg59: that it is
<daniels> indeed, it is love
<thom> daniels: those scripts are originally mjg59's, and gpl'd (i'm sure i'll be corrected shortwith if my memory is broken :) )
<mdz> thom: #1357 and friends should be trivial to fix now, yes?
<thom> mdz: the language packs are just gonna need to be updated to accept our warped version numbers, yeah
<thom> i'm intending to do that first thing tomorrow
<mjg59> One of the Novell people at the expo told me something interesting
<mjg59> NLD will ship with KDE in Europe and Gnome in the US, allegedly
<thom> mjg59: *boggle*
<thom> they really think the divide is that strong?
<mjg59> Seemingly so
<daniels> have you guys also experienced a random system beep?
<mjg59> But also, I think all their EU support staff are originally SuSE
<daniels> i'm getting one, and Googling shows it also happens under XP, but if you remove a device called 'Beep' from Device Manager (?!?), it all goes away
<daniels> mjg59: dude, that's total bong
<daniels> mjg59: so there will be SuSE, KDE NLD and GNOME NLD?
<mjg59> daniels: Using wireless?
<mjg59> And ifplugd?
<daniels> mjg59: yes, and maybe
<daniels> mjg59: does ifplugd run as a daemon?
<mjg59> Yes
<daniels> mjg59: ok. it's not running, but I've muted everything anyway.
<mjg59> If so, it's probably the firmware resets on the wireless card
<daniels> nope, not even installed
<mjg59> Hmm
<daniels> basically, it sounds like there's a hard disk write, then a system beep
<mjg59> Check whether it correlates to those anyway
<mjg59> Oh, are you /sure/ it's a beep?
<daniels> http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2004-July/019160.html
<mjg59> The drive makes an odd chirp noise when it parks
<daniels> http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2004-August/019163.html
<daniels> it's a beep-like sound, but it does sound a little different
<daniels> can I make the drive shut the fuck up?
<mjg59> Mine doesn't seem to do it now
<mjg59> I've no idea what changed
<thom> NetworkManager is hardcore crackadelia, by the way
<daniels> thom: duh
<mjg59> NetworkManager was a mess of race when I tried it
<daniels> mjg59: which kernel are you running?
<mjg59> 2.6.7
<mjg59> +random patches
<thom> it's now a mess of race, with broken dbus permissions
<mjg59> It's irritating - Netapplet is the wrong solution, but it works
<daniels> mjg59: are you running laptop-mode?
<daniels> thom: urgh
<mjg59> NetworkManager is the right solution, but implemented in an over-complex way
<mjg59> daniels: Yeah
<mjg59> Only on battery, though
<thom> networkmanager will eventually get there, but may need a rethink and tears to get there
<daniels> mjg59: right
<daniels> mjg59: any clue as to which patches you're running?
<daniels> yes, it definitely sounds like the drive parking
<mjg59> daniels: ACPI + random stuff of my own to debug ACPI stuff
<mjg59> Shouldn't be anything special
<thom> the packages almost work, but there really needs to be a way to add NetworkManagerInfo to the user's gnome session :/
<mjg59> Playing with the hdparm accoustic management stuff might help
<daniels> hm
<daniels> yeah, I just set it to 192 on a semi-whim
* daniels waits for it to spin down.
<daniels> GAH
<mjg59> 128 is the only one that's likely to do anything
<daniels> yeah, tried that too
<tseng> thom: patching the default session might be a start
<jdub> yo mjg59 
<mdz> I think we've found a paleobug in gzip
<tseng> ew
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 12 RC bugs to go
<fabbione> morning guys
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 13 RC bugs to go
<chrisa> 13 RC till warty?
<lamont> Rejected: libglib2.0-udeb_2.4.7-0ubuntu1_x86_64.udeb: architecture part of filename (x86_64) does not match package architecture in the udeb (amd64).
* lamont giggles
<fabbione> chrisa: bug in discover1-data
<fabbione> and thunderbird keeps crashing on me..
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 12 RC bugs to go
<mdz> (downgraded a NEEDINFO bug which had been waiting for too long)
<mdz> looked like it was fixed, but the submitter would not confirm
<hornbeck> mdz: do you guys want the user manual's in yelp to be Ubuntu specific for Hoary?  If so I will start working on them if noone is
<mdz> hornbeck: an updated user manual would be delightful
<hornbeck> ok, I did not want to start without knowing it was needed
<hornbeck> I am on it
<fabbione> mdz: can i remove Build-Dep:  libstdc++5-3.3-dev ?
<fabbione> according to debian any pkg providing libstdc++-dev is build-essential
<fabbione> bah we can wait after warty
<fabbione> daniels: you around?
* fabbione feels very lonely
<fabbione> mdz: are you still around?
<jdub> hornbeck: ROCK!
<fabbione> ah jdub!
<fabbione> jdub: i have a "design" problem here
<fabbione> jdub: 2205, 2106, 1690 
<fabbione> jdub: basically the problems are:
<mdz> fabbione: here
<fabbione> people that installs using an american/english language they get wrongly an US keyboard in X
<fabbione> + there is a 50% 50% chance to get the keyboard model wrong on ppc
<fabbione> now there is no easy solution for warty to any of these problems
<fabbione> my suggestion is:
<fabbione> if LAYOUT=us we ask to confirm the layout. For us people is one enter
<fabbione> and for ppc users we need to ask to confirm the keyboard model
<fabbione> all the other cases will NOT see the questions
<fabbione> that's the best we can do atm
<fabbione> mdz: i also reviewed again Kostantinos code
<fabbione> and he keeps going for the LANG way that we know isn't complete
<fabbione> or working in all cases
<fabbione> what do you want me to do?
<mdz> fabbione: can we use the answer to the keymap question in d-i?
<fabbione> mdz: no. we don't have the mappings 
<mdz> it is quite late to be making these changes
<fabbione> mdz: + that question has been reintroduced not too long ago
<jdub> hrm, makes me a little queasy
<fabbione> mdz: asking for me is setting a variable
<fabbione> it's not like i need to reimplement the code
<fabbione> if [ $LAYOUT=us ] ; then PRIORITY=high; fi
<fabbione> 2 lines like that
<mdz> and that would ask the usual X keymap question?
<mdz> which is two screens and text entry?
<fabbione> mdz: that will ask only for the layout
<fabbione> one question
<mdz> users do not generally know how to answer that question
<mdz> well debconf displays it as one screen of text and then a prompt for the keymap name
<mdz> but more importantly, the user doesn't know the answer
<fabbione> mdz: it's one screen only
<fabbione> the message is hidden with priority low
<mdz> ah, so that is actually a separate question
<mdz> so the user would see "Please select your keyboard layout" and a text entry box
<fabbione> when you get the 3 questions in a raw is because you are either reconfiguring or installing debian
<mdz> that is extremely unfriendly
<fabbione> well i can reenable messages if that's required
<mdz> I think it's a problem either way
<fabbione> but i think that as it is now is going to me the root of my headackes until hoary will have the "nice selector"
<mdz> if it is not yet right for warty, I think it is time to say "oops" and let it go
<mdz> we cannot make things worse for cases where it currently works
<fabbione> http://people.ubuntulinux.org/~fabbione/boom
<fabbione> ah nevermind
<fabbione> it's missing one thing
<fabbione> ok
<fabbione> mdz, jdub: that's the changelog for the next X upload
<fabbione> it should also fix 1089 but only for common layout as Denis specified
<fabbione> so it's not a complete fix
<fabbione> changelog is pedantic
<fabbione> but the changes are minimal and tested
<daniels> fabbione: sup?
<hornbeck> jdub: thanks I will try to have some good docs in place
<fabbione> daniels: check above url
<daniels> fabbione: checking now
<daniels> looks good to me
<jdub> hornbeck: if you make any changes that would be appropriate for upstream, perhaps we should split those out and send them up
<hornbeck> ok
<hornbeck> jdub: Do you want all of the manuals in yelp to be Ubuntu specific?
<hornbeck> or just updated to the releases
<hornbeck> I am thinking of adding a Ubuntu tab under the "Help Contents/Categories" for strictly Ubuntu docs 
<jdub> hornbeck: ideally, they should be well integrated
<jdub> hornbeck: but upstream need to provide a way for that to be done easily
<jdub> atm it's very hard
<hornbeck> jdub: I noticed that the user guide shipping with Warty is for Gnome-2.6
<hornbeck> is noone working on it anymore?
<jdub> hornbeck: it hasn't had a lot of love for this release
<hornbeck> hmm
<jdub> hornbeck: the man to speak to for status is shaunm
<hornbeck> jdub: I was working with him, but he kinda flaked out alot
<hornbeck> over worked I guess
<jdub> heh
<jdub> he's been busy
<hornbeck> yeah, I would have been flaking to
<hornbeck> I will touch base with him
<jdub> cool
<jdub> unfortunately, that's an area that needs work (upstream + vendor documentation)
<hornbeck> I just sent him a email about helping with the Gnome User Guide
<hornbeck> if I can get it updated enough maybe it will help Ubuntu and Gnome
<jdub> hornbeck: you're a legend, thank you :-)
<hornbeck> haha
<hornbeck> jdub: in cvs it looks like there is 2.8 docs
<hornbeck> ahhh, it is maintained by the Sun GNOME Doc team
<jdub> except not
<jdub> because they can't keep up ;)
<hornbeck> I guess that is where I come in 
<fabbione> mdz: i added the warty bug info to the changelog.
<fabbione> jdub: same for you
<jdub> oh man
<jdub> this is really scary
<jdub> i've started typing: sudo apt-get source ...
<Mithrandir> I did that too the other day.
<Mithrandir> scary, yes.
<fabbione> http://people.ubuntulinux.org/~fabbione/console-common_u3-to-u4.diff
<fabbione> to fix: 2196
<fabbione> anybody can review the "deep" changes? ;)
<Mithrandir> looks good to me. :P
<fabbione> jdub: ???
<Mithrandir> fabbione: I think this falls into the "trivial" category.
<fabbione> Mithrandir: i know :-))))
<fabbione> i am just teasing jdub
<fabbione> since nobody still approved my Xfree86 changes 
<Mithrandir> ;)
<fabbione> on the otherside nobody here smokes enough crack for that
<Mithrandir> fabbione: could you look at http://raw.no/patches/nvidia-settings_1.0-4.amd64.diff and tell me if it looks sane to you?
* jdub spanks fabbione 
<Mithrandir> jdub: or you, possibly.
<Mithrandir> this is almost like old times, sponsorwhining on IRC :D
<fabbione> Mithrandir: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.7
<fabbione> EXTINCSRC=/usr/X11R6/include/X11/extensions
<fabbione> needs to be changed
<fabbione> to /usr/include/X11/foobarbazcrap
<Mithrandir> that makefile is imake-generated.
<fabbione> imake sucks, didn't you know that?
<fabbione> but i was talking about debian/rules
<Mithrandir> tell nvidia, not me. :)
<Mithrandir> oh, in rules
<fabbione> anyway
<fabbione> if you want to simplify that
<fabbione> you can build-deps on xutils
<fabbione> and use xmkmf
<fabbione> that will generate the Makefile from the Imakefile on the fly
<fabbione> otherwise you can use imake (still from xutils)
<fabbione> imake -I/usr/X11R6/lib/config/ 
<fabbione> or something like that
<fabbione> DESCRIPTION
<fabbione>        The xmkmf command is the normal way to create a Makefile from an Imake-
<fabbione>        file shipped with third-party software.
<Mithrandir> is running imake when building the preferred solution?
<fabbione> no idea of what nvidia-setting does
<fabbione> but i can see you are adding Makefiles
<fabbione> the best way is to create them
<fabbione> so that when imake/xmkmf will change
<Mithrandir> ok, then I'll do that instead.
<fabbione> it will be enough to reupload/rebuild the package
<fabbione> other than recreating all the Imakefiles
* fabbione can't wait to see how many packages will FTBFS with X.org
<Mithrandir> heh
<suheimi> questions: it is said that python is integrated in ubuntu. How integrated is it?
<Mithrandir> fabbione: so you're happier with http://raw.no/patches/nvidia-settings_1.0-4.amd64.2.diff ?
<mdz> suheimi: a rich python environment is provided by default, and a greater degree of integration is coming in future releases
<jdub> ahr, mdz
<jdub> mdz: you happy with this patch for openldap2?
<jdub> http://cvs.gnome.org/viewcvs/*checkout*/evolution-exchange/docs/openldap-ntlm.diff?rev=1.1.1.1
<mdz> hmm, didn't we talk about this already?
<jdub> yes, just making sure
<jdub> as i'm about to upload
<suheimi> is it going tobe like java and jds linux?
<fabbione> Mithrandir: yes.. just check if it compiles at it should :-)))
<jdub> suheimi: WAAAAAAAAY more integrated
<fabbione> Mithrandir: but it looks much simpler than shipping a 200K Makefile
<fabbione> ;)
<Mithrandir> fabbione: "hey, it compiles!  Ship it!"
<mdz> jdub: I assume there is a very good reason to do this for Warty?
<Mithrandir> ;)
<Mithrandir> fabbione: seems to build fine here, and it builds the .a, which it didn't do before.
<jdub> mdz: making evolution-exchange useful for people who are using it in a real environment :-)
<suheimi> jdub: can u explain ?
<Mithrandir> mdz: http://raw.no/patches/nvidia-settings_1.0-4.amd64.2.diff -- happiness?
* fabbione fucking ROCKS on Imakefile
<jdub> suheimi: we're planning on deep python scriptability for as much as we can throughout the OS
<mdz> Mithrandir: hmmm
<mdz> Mithrandir: presumably it includes an i386 binary which we currently use?
<Mithrandir> mdz: correct.
<mdz> Mithrandir: and now we are building it from source instead, even on i386?
<Mithrandir> and somehow, that links on amd64, but blows up when running.
<Mithrandir> yes.
<Mithrandir> it's a gpl-ed library from nvidia
<Mithrandir> they ship it as a binary because they think it's easier for people.
<mdz> Mithrandir: but we have no idea whether it actually works when built from source on Ubuntu?
<suheimi> jdub: you mean, the bash will be in python ?
<Mithrandir> mdz: it works on amd64, at least.
<mdz> Mithrandir: please get someone to test it on i386
<Mithrandir> mdz: ok.
<fabbione> Mithrandir: put up the .diff.gz
<fabbione> i can test on i386
<mdz> for all we know, it may never have been built with our gcc etc.
<fabbione> and the dsc
<fabbione> mdz: i can test it
<jdub> suheimi: heh, no :-)
<fabbione> no panic!
<fabbione> NOBODY PANIC!
<jdub> suheimi: like, scripting openoffice and stuff like that
<fabbione> :P
<Mithrandir> fabbione: thanks -- http://raw.no/tmp/nvidia-settings_1.0-4.dsc and http://raw.no/tmp/nvidia-settings_1.0-4.diff.gz
<suheimi> ok, like vbscript then.
<mdz> panic()
<mdz> Mithrandir: did you see my notes on #1854?
<mdz> I think it may be a gzip paleobug
<Mithrandir> mdz: yeah, it might be.
<Mithrandir> but I think it's also a libc/kernel bug -- you shouldn't end up with deadlocks like that.
<mdz> if the situation is as I think it is, glibc and kernel are correct and gzip is buggy
<mdz> a signal can arrive at any time, even inside a critical section
<mdz> as to why no one else seems to have encountered this bug, I have no idea
<mdz> at least Debian users should see it
<Mithrandir> I think it's a race condition in glibc when two signals arrive closely together, but you seem to be correct.
<mdz> it seems that the only requirement is a 2.6 SMP kernel
<Mithrandir> possibly with HT.
<mdz> hmm, didn't elmo experience it on a non-HT xeon?
<Mithrandir> hmm, I have a dual celeron here.. I should be able to reproduce on it.
<Mithrandir> not AIUI.
<mdz> hmm
<mdz> please do try
<Mithrandir> I need to build a box around the mobo, though
<fabbione> Mithrandir: it works fine here.
<Mithrandir> fabbione: goodness.
<fabbione> but i think the package should be 3ubuntu1 ?
<fabbione> and not 4
<Mithrandir> fabbione: yeah, of course, mea culpa.
<fabbione> no problem ;)
<Mithrandir> mdz: as it works on i386 as well, permission to upload?
<rburton> is ubuntu-base a required package, or is it just used to bring in the default install?
<Mithrandir> rburton: no, but it can be used for keeping up with the ubuntu-base task.
<Mithrandir> if the task changes.
<rburton> it wants to remove my mta (as it changed postfix)
<mdz> Mithrandir: OK
<rburton> so i'll remove it
<mdz> feel free
<mdz> Kamion: awake?
* Mithrandir wanders off
<mdz> fabbione, daniels: #2239 doesn't seem RC; is there some justification?
<fabbione> mdz: yes. if the hardware of that guy is ok, either discover1-data is broken or discover1 making X failing to work
<fabbione> discover1-data seems to be ok
<mdz> X not working on a particular piece of hardware is not usually an RC bug
<fabbione> but something else can be badly broken
<fabbione> mdz: i know that.. that's not the problem. X works on that machine, but the generated configuration is bad
<fabbione> mdz: not getting the proper driver is much worst than running @60Hz or something
<mdz> I understand that
<fabbione> ok X i up
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu development -- general discussion on #ubuntu | 11 RC bugs to go
<mdz> is anyone able to reproduce #1254?
<mdz> there are several possible solutions, but since none of us can test, it is difficult
<mdz> seems to hit many Dell laptop users
<rburton> i take it i'd need to recompile the kernel to get the sysrq key working?
<mdz> rburton: that, or wait for Herbert's next upload, where it'll be enabled
<rburton> excellent
<mdz> (assuming you're on i386)
<mdz> it's already enabled on powerpc and amd64
<rburton> yeah, i am. i'll wait
<daniels> mdz: i suspect 1254 is people choking on the apic pipe
<daniels> unreproducalbe
<daniels> or whatever
<mdz> daniels: noapic doesn't help those folks
<mdz> read the comments
<daniels> mdz: yeah, just finished reading them, and it's the BIOS being arse :\
<daniels> jdub: kaping
<daniels> jdub: (there were some X changes pending for Warty -- can you remember what they were?)
<jdub> whowhat?
<fabbione> memtest86+ (1.15-2ubuntu2) warty; urgency=low
<fabbione>   * Fix bashishm in debian/make-memtest86+-boot-floppy.
<fabbione>     (Closes: #2121/#275233)
<fabbione>   * Add make-memtest86+-boot-floppy man page. (See #263708)
<fabbione> trivial changes
<fabbione> any objections?
* fabbione listens to the sound of silence
<mdz> fabbione: seems harmless enough
<mdz> there are plenty of bigger bugs, though
<fabbione> mdz: i am going trough "orphaned" bugs
<fabbione> all the one assigned to nobody
<fabbione> food time
<Mithrandir> mdz: mind if I kill off your gzip processes?
<mdz> Mithrandir: not at all
<Mithrandir> gnome-cups-manager doesn't like cupsys to be upgraded underneath it.
<sivang> mdz : could you please take a look at #2221 and tell me if it's major? (I've catagorized it minor)
<sivang> mdz : minor = normal
<mdz> sivang: normal is appropriate
<mdz> I don't really expect network-admin to cope with the loopback interface being deleted out of /etc/network/interfaces
<mdz> but it seems to try
<daniels> ?!?
<sivang> mdz : Ok. It's not that I deleted the spcific interface line, I erased the entire file just to see what will happen to a user that he's config would disappear.
<sivang> mdz : It's currently unable to create interfaces file correctly from scratch.
<mdz> sivang: that is true of most of the configuration files on the system :-)
<sivang> mdz : I see :-) Shame I lost about 1 day (of which I should have rested while ill) to debug the little thingy off...Well, guess this is hoary material then? :-)
<mdz> definitely
<sivang> mdz : it also appeared that this happens on debian sid also..This should have raised a red light to me :-)
<sivang> mdz : anyways, could you fill me up on what you and hornbeck agreed regarding yelp? I've got little lagged..
<mdz> that was jdub
<sivang> mdz : oh ok, I'll ping him then.
<sivang> jdub : ping?
<daniels> lifeless: how long do you think it will take to release the KDE arch archive? :)
<jdub> daniels: haha
<jdub> sivang: nothing about yelp
<mdz> jdub: I think he means about the user manual
<jdub> oh
<sivang> jdub : he also mailed me about that you and him agreed on some thing etc..
<sivang> jdub ; regarding what should go into yelp I think
<jdub> hornbeck is going to work on updating bits from the 2.8 version and integrate ubuntu information
<jdub> sivang: note that this has nothing to do with yelp (it's just the viewer)
<sivang> jdub : Yes. (I might have needed to repharase my inquiry) He's going to work on gnome 2.8 manual and update it to fit Ubutnu quirks?
<fabbione> 2251 <- doh.. this is becuase we disabled browsing, didn't we?
<mdz> fabbione: yes, that is a feature
<fabbione> mdz: invalid?
<mdz> fabbione: enhancement
<mdz> we do want to have automatic discovery of printers
<mdz> but we will need to find a way to do it without opening a port continuously forever
<mdz> the implementation is broken
<sivang> jdub : also, what would be that last date to sumbit docs to get on the release? the 17th 0:-) ?
<mdz> Keybuk: could I trouble you for a second opinion on #1854?
<mdz> Keybuk: hypothesis: it is simply evil to exit() or free() in a signal handler
<Keybuk> I don't think you can free in a signal handler
<Keybuk> that's one of the forbidden actions
<Keybuk> (the signal might happen inside malloc)
<mdz> likewise for exit()
<Keybuk> yeah, I tend to agree
<mdz> because it flushes streams, and the signal might arrive while one is locked
<mdz> I have no idea why no one else has encountered this, however
<mdz> which is the only reason I doubt
<mdz> I mean, this is _gzip_
<mdz> something that gets piped and signalled and context-switched all day long on a wide variety of hardware
<Keybuk> have FreeBSD not fixed this?  their system is very sensitive to malloc/free-in-signal issues
<Keybuk> yeah, but how often does SIGINT really get thrown?
<Mithrandir> mdz: I'm going to try reproducing it this evening.
<Mithrandir> (on said celeron system)
<mdz> Keybuk: it calls the same handler for SIGPIPE
<mdz> and SIGTERM and SIGHUP
<Keybuk> signal handlers should generally just set a flag which the main loop picks up; anything else is a bit dodgy :-/
<mdz> _exit() and abort() should both be safe
<mdz> according to POSIX
<Keybuk> yes, that sounds right
<mdz> Mithrandir: I attached a patch
<Keybuk> I'd just call _exit() rather than do_exit() ... the kernel will free the memory quite adequately when it collapses the process
<sivang> mdz : you have any ideas as to how make Ubuntu in (maybe _this_ specific?) Dell Inspiron 8200 - it's barely usable when firefox and startup take _so_ long.
<mdz> Keybuk: that's exactly the patch I just attached to the bug
<sivang> mdz : also, disk access seem to take _ages_.
<mdz> sivang: I have no idea, make sure DMA is enabled on the hard drive, ask in #ubuntu
<lifeless> daniels: not long if I get a tarball. the anoncvs servers seem to have a badly configured conection limit detector
<mjg59> Oh dear. 1061 unread in ubuntu-users
<mdz> Mithrandir: emailed you a gzip .deb to test
<mdz> bah, I'm just going to upload it
<mdz> it's only gzip, right? :-P
<daniels> heh
<mdz> could someone take care of forwarding the patch upstream?  I need to sleep
* mdz falls over
<sivang> mdz : it's a matter of attaching the file and mail it to the upstream developer(s) ?
<daniels> mdz: this is the mdz of legend? sleeping?
* daniels falls over also.
<sivang> mdz also deserves to sleep once in a 3rd night ;-)
<Mithrandir> mdz: I'm going to test it this evening.
* fabbione places gzip on hold
<Mithrandir> mdz: and you have root on the workstation -- it's not like you couldn't just install it and test yourself. :P
<fabbione> 2252 looks like a missing reautoconfig --everything --r3g3r4t3 --4ut0t00l5
<rburton> that bug ruined my plans for this morning :)
<fabbione> rburton: rebuilding it seems to fix the problem
<fabbione> rwxr-xr-x root/root         0 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/
<fabbione> -rw-r--r-- root/root     39227 2004-10-11 13:03:15 ./usr/lib/python2.3/site-packages/libxslt.py
<fabbione> -rw-r--r-- root/root     53388 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/libxsltmod.so
<fabbione> -rw-r--r-- root/root      1021 2004-10-11 13:03:15 ./usr/lib/python2.3/site-packages/libxsltmod.la
<fabbione> -rw-r--r-- root/root     67712 2004-10-11 13:03:18 ./usr/lib/python2.3/site-packages/libxsltmod.a
<rburton> yay, files
<rburton> can you mail me that deb?  for some reason i can't get it from packages.debian.org :(
<fabbione> but i wonder why it didn't build properly in the first place
<fabbione> rburton: let em put it on the web
<daniels> we need the build log
<daniels> probably failed a config test, just non-fatally
<daniels> so it didn't build half of it
<daniels> most configure scripts don't actually error out when they need to
<fabbione> rburton: people.u.o/~fabbione/
<fabbione> http://people.no-name-yet.com/~lamont/buildLogs/libx/libxslt/1.1.7-1ubuntu1/libxslt_1.1.7-1ubuntu1_20041011-0737-i386-successful
<rburton> fabbione: cheers
<rburton> it doesn't build-dep on libxslt1-dev
<daniels> huzzah
<fabbione> ARGH
<seb128> missing a build-dep on python apparently
<fabbione> no it can't builde-dep on libxslt1-dev
<fabbione> ok i am on it
<seb128> python-dev used to dep on python
<Kamion> mdz: hello
<Kamion> mdz: oh, damn, you went to sleep
<fabbione> seb128: afaik python is installed on all the buildd
<elmo_> fabbione: it shouldn't be
<seb128> fabbione: look on the log, python: no in the ./configure
<thom> fabbione: doubt it, you need to depend explicitly
<seb128> just add the build-dep on python
<daniels> fabbione: chroots, dude
<fabbione> elmo_: lamont installed it a long time ago... but anyway not a big deal
<fabbione> daniels: i am testing in a chroot dude..
<fabbione> thom: as per elmo
<fabbione> seb128: thanks :-)
<seb128> np
<elmo_> fabbione: then lamont needs a beating
<fabbione> elmo_: if he removed it.. i dunno..
<elmo_> jdub: is this sync request for main?
<fabbione> i remember he installed it in the beginning to let a bunch of stuff to build
<fabbione> HMMM
<fabbione> building in a fresh chroot works fine
<fabbione> and it creates the stuff
<fabbione> ok yeah
<jdub> elmo_: which one?
<elmo_> jdub: the mono one
<jdub> elmo_: they're all in universe
<elmo_> ok
<daniels> jdub: permission to upload g-v-m with the gthumb bugfix discussed?
<jdub> daniels: oh, ok.
<fabbione> there.. fixed
<jdub> daniels: kinda hoping azeem would have a chance to respond ;)
<Mithrandir> elmo_: did you see mdz tracked down the apt problem?
<seb128> jdub: any idea of why bugzilla.gnome.org is down ?
<elmo_> Mithrandir: yeah, he phoned me about it while I was on the way down
<daniels> jdub: heh
<Mithrandir> elmo_: ok
<daniels> jdub: i can test it locally if you like
<jdub> seb128: might be some server probs atm
<seb128> ok
<sabdfl> jdub: if I do the image in black and white, is it possible to turn the white into transparency?
<sabdfl> i don't know the gimp that well
<eniac> and it's hard getting to know the gimp to
<sabdfl> the design company work to very specific instructions and frankly haven't a clue about transparency
<eniac> does ubunto work with a design company ?
<sabdfl> elmo_: can we saturate 600 mbit/s with the current server setup?
<sabdfl> and is plone setup properly for cacheing now?
<sabdfl> is the reverse proxy setup for cacheing rather?
<sabdfl> because we're going to get /.'d 
<fabbione> hey sabdfl 
<sabdfl> eniac: yes, but not very fruitfully thus far
<sabdfl> jdub: go ahead on gnome-default icons
<eniac> sabdfl: why not depend on the community ?
<thom> i'll take another run through the site and check everything is caching properly
<sabdfl> hay fabbione
<sabdfl> thom: thanks
<thom> last i checked, it was just broken settings on a bunch of the pages
<sabdfl> also, the more mirrors we have wednesday the better, of course
<sabdfl> what settings on the pages?
<jdub> sabdfl: that's a pita to do *really* well.
<jdub> sabdfl: tends to be easier to do it from the start with transparency in mind
<jdub> sabdfl: happy to explain it to them in photoshop terms :)
<sabdfl> jdub: you don't want to go there. very high latency link
<sabdfl> i think we have to go with the single colour option for warty
<sabdfl> we can do better for hoary
<sabdfl> seems like chocolate was the preferred one from responses thus far
<jdub> you mean single colour background + watermark?
<sabdfl> jdub: single basic shade
<sabdfl> will put the glow in
<jdub> ok
<sabdfl> then get the design company to add the figures
<jdub> i'll whip a couple up tonight
<sabdfl> default desktop will be colour + glow + ubuntu
<sabdfl> like in the chocolate image
<sabdfl> there will also be a plain one (colour plus glow) with no logo and no image
<sabdfl> and then the calendar image will have colour, glow and one image
<jdub> the glow without logo is really easy
<jdub> and not a problem for different scales
<jdub> but if you add the logo, making it work nicely across resolutions is a bit harder
<sabdfl> jdub: erm, try doing the gradient on 1600x1200 with cubic interpolation, threshold at zero and max depth set to 6 on the adaptive supersampling
<jdub> although, if you're happy with 4:3 images and stretching for other ratios for warty, that's cool
<sabdfl> it... takes a while
<sabdfl> jdub: good point, all of the above should be available in 4:3 and 16:9
<jdub> we can't auto switch for the right ratio though
<jdub> i'd lean towards making ratio-independent images
<jdub> (which means you can't bleed, or it'll look like crap)
<daniels> fabbione: 275973
<thom> fabbione: dude, inventing new words now? (randomically)
<Mithrandir> thom: it's just itaglish. :)
<fabbione> daniels: saw that... no clue
<fabbione> thom: tsk :-P
<fabbione> thom: you should know by now ;)
<thom> and aaargh, not *another* X upload
<fabbione> daniels: probably related to the fact that -8 is missing the us_intl layout?
<fabbione> daniels: while we have it?
<fabbione> thom: there will be more.. be sure about that
<Kamion> jdub: am I OK to upload d-i translation updates in general?
<Kamion> doko: why is #1232 assigned to you rather than me? I'd've looked at it earlier if it had been assigned to me :)
<daniels> fabbione: everyone should just use us layout anyway
<fabbione> daniels: whatever kid ;)
<fabbione> let see what Denis answers to it
<daniels> he seems to have a grip on XKB
<daniels> he can have it
<daniels> jdub: oh, that's right -- the -br patch
<daniels> jdub: so you've implemented all you need in gdm?
<jdub> daniels: yeah, somehow it was lost along the way
<jdub> daniels: i can send you a colour code later
<daniels> jdub: 'kay
<thom> sabdfl: sigh, they've still not fixed all the expires
<azeem> if I enable remote gdm, I get a Debian swirl as greeter :)
<azeem> jdub: well, I could extract the change from the unstable g-v-m package I guess, if you want it to be consistent and it's not uploaded yet
<jdub> bah
<jdub> could've told me before i did the last bugfix ;)
<jdub> thanks ;-)
<azeem> I was having lunch
<jdub> azeem: looks like daniels is on the job
<daniels> yeah, I'm taking care of it
<daniels> just fixing up some dbus stuff first
<azeem> okie then
<hornbeck> jdub: is there anyway for the gnome 2.8 docs to make it into Warty?
<jdub> hornbeck: oh! i thought that was part of what you were doing?
<hornbeck> haha
<hornbeck> well it can be
<jdub> just a matter of a package upgrade ;)
<hornbeck> most of the 2.8 docs are already there, in cvs
<hornbeck> jdub: my main goal is super clean, easy to understand docs for Hoary
<daniels> bloody brownouts.
<jdub> hornbeck: seems like we might get quite a bit of help with that
<hornbeck> jdub: that would be nice
<hornbeck> how would you like me to submit docs to you?
<jdub> i think we have to discuss that a bit among the documentation team when we get it rolling
<jdub> i think docbook is an easy assumption, however
<hornbeck> jdub: Do you want me to package it? Tell you where its at?
<jdub> hrm
<jdub> do you grok autofoo?
<hornbeck> cause the 2.8 docs are there, and I think they are ready to roll
<hornbeck> no, I don't but can learn
<jdub> perhaps we should start by looking at the gnome user docs cvs module
<hornbeck> yes
<jdub> i'm not sure if that has xml2po loving yet
<jdub> using gnome-doc-tools
<Keybuk> then what do you do with the po?
<jdub> but i think the combination of docbook, xml2po (in gnome-doc-utils) and regular translation tools will be the best bet
<Keybuk> or is it the fo I mean?
<jdub> Keybuk: translate as you would any other po files
<Keybuk> ah, you're talking about something else
<hornbeck> I think if we keep with the docbook style that is already there it would be best bet
<Keybuk> the problem I always had with XML Docbook was that you could do the XML -> FO -> nothing
<Keybuk> so you couldn't actually produce printables from it
<jdub> hornbeck: yeah
<daniels> fabbione: 275973 is not our problem, yay
<jdub> Keybuk: oh right, yeah
<rburton> Keybuk: fop works for me
<jdub> rburton: shush, javur boy!
<Keybuk> rburton: non-free
<rburton> ;)
<rburton> Keybuk: good point -- i've not tried it with gcj, though the fop maintainer did say he would try shortly
<Keybuk> rburton: I tried, and never got it to compile
<jdub> i bet you don't do fop processing on javacards
<daniels> heh yeah
<rburton> haha
<daniels> fop is, um, interesting
<rburton> yeah
<daniels> since you can process it with java
<daniels> and, um, java
<rburton> by works i mean "doesn't crash"
<rburton> another definition is "better than passiveTeX
<hornbeck> jdub: What day do you need the final docs by?
<jdub> hornbeck: none specified so far. let's make it the 18th.
<hornbeck> ok, I will keep in touch with you on progress
<hornbeck> have to go work now
<jdub> rock!
<jdub> have fun ;)
<Kamion> quick review of http://people.ubuntulinux.org/~cjwatson/debian-installer-utils.diff?
<Kamion> been meaning to do that for a while for completeness, we made a similar change to debootstrap a while back
<fabbione> Kamion: seems ok to me
<fabbione> daniels: 275973 - user error
* fabbione goes offline for a little while
<plovs_work> in case the wiki-admin is here, the wiki seems messed up (css can not be found?)
<daniels> fabbione: yeah, as I said :)
<daniels> plovs_work: works fine for me
<plovs_work> daniels, not for me, with a downgraded firefox 9.3 and a new profile?? did you refresh?
<daniels> plovs_work: i'm still back on 1.0, but yes, I refreshed, then tried with Mozilla
<daniels> plovs_work: try restarting your browser
<plovs_work> daniels, I'll try it on windows down the hallway :) brb
<daniels> plovs_work: (or it could be something in between -- I thought Planet Debian was busted, 'till I realised planet.debian.org/nudebian.css was getting caught by .*nude.* on my upstream proxy at the time)
<Kamion> scunthorpe!
<daniels> heh
<daniels> Kamion: it also blocked fuckedcompany.com, among others
<daniels> stupid fascist proxy
<thom> yikes, i now have a catalan firefox
<plovs_work> daniels, maybe this should be on #ubuntu but here the wiki does *not* work on firefox-linux-9.3, firefox-windows-1.0pre/9.3 but it *does* work in IE :(
<thom> und auf deutsche
<daniels> wow ... people actually hack on utah-glx
<thom> wow, italian looks crazy
* thom avslutt mozilla
<Kamion> Swedish? Norwegian?
<thom> Norwegian
<thom> no_NB
<plovs_work> daniels, http://moinmoin.wikiwikiweb.de/ *does* work so it really is something at http://wiki.ubuntulinux.org
<thom> testing firefox in languages you can't even guess at is fun
* Kamion looks at cdimage with some puzzlement
<Kamion> two cron.daily runs in succession are hung at exactly the same place
<Kamion> in *gzip*
<Kamion> thom: could I have strace on little, please?
<daniels> Kamion: i blame mdz
<Kamion> daniels: gzip is version 1.3.5-9 on little, before mdz's change
<Kamion> does sound like #1854
<thom> Kamion: done
<thom> want the new version of gzip just in case?
<Kamion> both stuck in read()
<Kamion> thom: yes please
<thom> done
<daniels> Kamion: hm
<Kamion> thom: strange that it's only shown up since 20041010
<Kamion> thom: oh, little got its kernel upgraded yesterday, didn't it?
<pitti> jdub: can you please approve #2208 and #2209?
<thom> yeah
<Kamion> built from linux-source-2.6.8.1 2.6.8.1-10
* Kamion kills off the previous two runs and starts a new one
<Kamion> somebody wanna tell Herbert that his latest kernel package fails to build?
<sivang> Kamion : hmm, is it a risky thing to do ? :)
<Kamion> sivang: no, but I'm busy :)
<sivang> Kamion : you have his bug# ?
<Kamion> EPARSE
<Sledge> Kamion: you available to talk about jigdo-related goodness?
<Kamion> Sledge: sure
<Sledge> cool
<Sledge> sorry to keep you waiting around for a few days
<Sledge> kind of stuck in hospital etc...
<Kamion> yeah, sure :-/ did it go OK in the end?
<Sledge> ish
<Sledge> dad's still ill, but stable for now
<Kamion> good luck ...
<Sledge> they've let him home for a while
<Sledge> cheers.
<Sledge> so, what kind of snapshot layout are you looking for?
<Kamion> one snapshot per CD build for all arches
<Sledge> ok
<Kamion> not much bothered about the exact layout but we might as well just snapshot the whole archive, I think
<Kamion> hm, no
<Kamion> snapshot the union of all files used in all three CDs
<Sledge> so something like /snapshot/date/<stuff>
<Kamion> or possibly date.suffix
<Sledge> ok
<Kamion> like in http://cdimage.ubuntulinux.org/daily/
<Kamion> the cdimage build scripts need to own the version numbers there rather than having mkjigsnap guess them itself
<Sledge> I'm thinking that you would set up sym links to specific dates for hoetcary/warty/
<Sledge> ok
<Kamion> or maybe just create a new hardlink tree, since they're notionally cheap
<Sledge> yup, could do
<Kamion> although I guess that would screw the jigdo files already generated
<Sledge> you could just hand-edit the config file to fix that
<Kamion> yeah, though I'd rather not make the process of making a release more complicated than it needs to be
<Sledge> so, easiest way is to call mjs with a date option for each arch
<Kamion> we tend to be in a hurry :)
<Sledge> :-)
<Kamion> right
<Kamion> so the question is how to get that across the command-limited ssh trigger
<Sledge> and simply overlay the snapshot trees on each other
<Sledge> how limited is the trigger?
<Kamion> you don't get arguments when you're using ssh command=
<Kamion> it's all or nothing
<Sledge> you sure?
<Sledge> it works for me...
<Sledge> oh, hang on
<Sledge> I get you
<Sledge> the way I get around it for tasks here is to run a limited shell for the user rather than use "command="
<Kamion> I'm thinking of putting a trigger.conf file somewhere with a very simple format that the script can use to figure out what to do with mkjigsnap
<Sledge> hmmm
<Sledge> that'll be _tricky_
<Kamion> or maybe that's not necessary
<Kamion> what I think needs to happen is that the trigger needs to go through daily/ and make sure there's a matching snapshot for the latest one
<Sledge> possibly
<Sledge> or pass the args to the trigger script on stdin rather than as args
<Kamion> occasionally I run the trigger manually when a daily has *not* just been generated
<Kamion> oh, that would work too, yes
<Sledge> simple perl/sh wrapper to read in options then pass them straight through to mjs
<Kamion> so 'echo snapshot 20041011.1 | sync-auckland'
<Sledge> yup, something lik
<Sledge> e
<Kamion> rather not have them be generic options, I suspect elmo would prefer maximum restriction
<Sledge> ok
<Sledge> but that bit should be easy enough to work out
<Sledge> the backend on auckland can parse input and drop anything it doesn't like
<Sledge> but I'll leave that bit to you... :-)
<Kamion> so, let's assume that's trivial; it seems to just be that piece plus making mkjigsnap able to do all three arches at once
<Sledge> simplest thing is a tweaked mjs with a -d <datestring> option
<Kamion> right
<Sledge> and of course you don't need to pass all three at once
<Sledge> simply run it three times and have it write in the same dir
<Sledge> so you scp the jigdo and template files into place, then run sync-auckland
<Kamion> hm, does that work? ok
<Sledge> it will do a "for file in *.jigdo; do mjs <stuff> ; done"
<Sledge> I'll hack on mjs right now for the date and overlay change
<Sledge> anything else you'd like?
<Sledge> :-)
<Kamion> thanks, that sounds sufficient to me
<Kamion> mail it to me and I'll pass it straight on to admins@ with a usage note
<Sledge> ok
* sivang brb. switching laptop AC points.
<pitti> Mithrandir: have you got a minute for an easy peer review?
<rburton> seb128: new SJ if you want it -- fixes HAL build and the memory leaks.
<rburton> should mean you can remove your patches
<seb128> rburton: oh, nice :)
* ..[topic/#ubuntu-devel:thom] : Ubuntu development -- general discussion on #ubuntu | 15 RC bugs to go
<rburton> seb128: and i'll have a new c-l-a tonight probably which fixes the no sources bug, and a nasty crasher
<seb128> cool :)
<seb128> rburton: BTW, nice changelog entry for sj :p
<carlos> seb128: do you have "my" gstreamer packages to test? :-P
<rburton> seb128: :)
<seb128> carlos: ?
<carlos> seb128: the test packages for the new gstreamer, you said you will add them to be tested and evaluated before asking for inclusion in Warty...
<carlos> or did I misunderstood it?
<seb128> carlos: I've mailed ubuntu-devel with the url to the packages 4 days ago and uploaded them in warty today
* carlos needs to subscribe to ubuntu-devel...
<carlos> O:-)
<seb128> arf
<seb128> and I've given the url on #ubuntu too ... perhaps you need to hang here ? :p
<fabbione> GRRR
<fabbione> i have been fighting all day to keep RC bugs down to 11
<fabbione> as soon as i leave and come back it jumps up to 15
<carlos> seb128: :-P
<fabbione> :P
<fabbione> thom: ping
<pitti> carlos: Hi! Any news regarding your updated kernel patch for hfs+ ?
<carlos> pitti: I did a new patch
<pitti> carlos: I saw it
<carlos> pitti: it's working except for the 99 magic behaviour
<carlos> because I don't see a way to invalidate the cached inode
<pitti> carlos: I saw that too, I think it is right for Linux to skip that
<carlos> pitti: at this moment, it should work
<pitti> carlos: IMHO it's just not the "Linux way" to have such a mess^Wmagic
<carlos> except for that feature
<carlos> pitti: but it's the way that filesystem works
<carlos> well, it's not completely true
<carlos> s:-)
<carlos> :-9
<carlos> grr
<carlos> :-)
<carlos> because I suspect that the 99 "magic" is done at system leve instead of the HFS+ driver
<Mithrandir> pitti: pong
<pitti> carlos: to be honest, I'm not unhappy that it doesn't work :-)
<Kamion> I only briefly saw that 99 stuff in scrollback, but it sounds really really evil
<pitti> Mithrandir: oh, hi! I would like to upload pmount with #2208 and #2209. Trivial patch, but the rules require a review. Do you have a minute for that?
<carlos> pitti: I did also a change that will ignore the uid and gid arguments if the owner in the filesystem is root (not sure if that should be removed, but that's how it works in MacOSX)
<Kamion> a near-future release of base-passwd is going to make group 99 be 'users'
<Mithrandir> pitti: sure, url?
<pitti> Mithrandir: patch is attached to #2208
<carlos> pitti: I mean, all files that have an owner != 0 will use the uid argument, if the owner is root, it will be always root
<pitti> Mithrandir: https://bugzilla.ubuntulinux.org/attachment.cgi?id=421
<Kamion> how exactly are you proposing to use gid 99?
<pitti> carlos: but wasn't the complete point of your patch to fix exactly that?
<pitti> carlos: or are the files on the iPod usually owned by 99?
<carlos> pitti: no, the iPod filesystem has as owner for the files an uid != 0
<carlos> pitti: no, at this moment uid = 1000
<pitti> carlos: hmm, then it's odd that it didn't work before.. this seems to be the easiest case
<carlos> but the .Trashes folder and the .journal and other system files
<pitti> carlos: BTW, the apple standard user also has uid=1000?
<Mithrandir> pitti: apart from the fact that I think creation of /media belongs in base-files, it looks good to me.
<pitti> Mithrandir: I know, and it is in fact done in base-files
<carlos> pitti: I think I did not changed since last iPod "reinstall" so yes, seems like Apple uses uid=1000 by default
<pitti> Mithrandir: but this was requested for upgrades from woody
<Mithrandir> pitti: why not add a versioned dep rather, then?
<pitti> Mithrandir: ?
<pitti> Mithrandir: to what and for what?
<Mithrandir> pitti: doesn't base-files create the directory if it doesn't exist (on upgrades)?
<carlos> Mithrandir: no, it never creates it if it's not a new installation
<Mithrandir> oh, ok.
<pitti> Mithrandir: hmm, I'm not sure any more. Could be that I mixed up b-files with b-config
<carlos> Mithrandir: (talking about Debian), not sure if we changed it with Ubuntu
<Mithrandir> carlos: sounds like a bug to me.
<Mithrandir> but, if it doesn't, it doesn't, so.. patch looks fine to me.
<carlos> Mithrandir: it was done that way to prevent it to be created with every update if the sysadmin removes it by hand
<carlos> there was a discussion about it in Debian some months ago
<pitti> Mithrandir: I looked in base-file's postinst: media is created only on fresh installations
<pitti> carlos, Mithrandir: hmm, then pmount would reintroduce this
<pitti> Mithrandir: I could change the patch to only create /media if $2 == ""
<pitti> Mithrandir: then we would have the same effect, but pmount would not work if the admin removes /media
<Kamion> you could easily do it only on upgrades from less than the version that first creates /media
<Kamion> dpkg --compare-versions, trivial
<Mithrandir> pitti: I don't think so; having the system break horribly if you mess around with system directories is fine, IMHO.
<pitti> Kamion: okay, that sounds reasonable
<Kamion> if dpkg --compare-versions "$2" lt-nl whatever-version-you-introduce-it-in; then mkdir -m 0755 -p /media; fi
<pitti> Kamion: but that reduces the "always override an admin's decision" to "only once override an admin's decision".
<carlos> Base-files will not create the directories for /media, /opt and /srv on 
<carlos> upgrades and according to the FAQ this is desirable behavior. As an 
<carlos> alternative, please provide a script which creates these files or provide 
<carlos> instructions on creating them with proper ownership, permissions, etc.
<carlos> from #275416 (Debian BTS)
<pitti> So can we regard this as a concensus? Attempt to create /media only once?
<carlos> pitti: for me, warty should have always /media 
<thom> fabbione: pong
<carlos> pitti: in Debian it's not needed because we don't have (yet) pmount
<Mithrandir> Kamion: 2256 looks like a d-i bug to me.
<Kamion> if pmount must have /media, you could just ship /media in pmount.deb
<pitti> carlos: well, the Golden Rule...
<carlos> if a sysadmin removes it, pmount will be broken
<Kamion> pitti: dude, the golden rule still doesn't allow admins to remove /usr :-)
<carlos> :-P
<pitti> Kamion: but if it already exists? As a symlink? Then package installation would fail, not?
<Kamion> true
<Mithrandir> pitti: no, it would work.
<Kamion> no it wouldn't, dpkg fails in that case
<Mithrandir> if it exists as a file, things will blow up.
<pitti> Mithrandir: that's why I wanted to do that in the postinst
<Kamion> dpkg does not allow overwriting a directory with a symlink or vice versa
<pitti> (which is very sane :-) )
<Mithrandir> pitti: just ship the directory in the deb.
<Kamion> hm, let me check that
<pitti> Mithrandir: see above, what if it already exists?
<Mithrandir> pitti: dpkg handles that nicely.
<Mithrandir> pitti: if the admin has stuck a /media file on his system, well, then it will break.  likewise if he puts a file as /usr/share/doc or a number of other things.
<Kamion> however we should be able to operate if /media is a symlink to a directory
<pitti> By now I have:
<pitti>         if dpkg --compare-versions "$2" lt-nl 0.1-5;
<pitti>             [ -e /media ]  || mkdir /media
<pitti>         fi
<Mithrandir> yes, and dpkg handles that fine.
<pitti> Mithrandir: what does dpkg do in this case? Silently not install the directory? Or fail?
<Kamion> hm, I think you're right
<Mithrandir> not install the directory.
<pitti> okay, I try that out.
<Mithrandir> Kamion: I've run systems where /var has been a symlink to /usr/var or similar.
<Kamion>         if ( mkdir(i->Name, i->Mode & ~S_IFMT) != 0 ) {
<Kamion>                 if ( errno == EEXIST ) {
<Kamion>                         struct stat s;
<Kamion>                         if ( stat(i->Name, &s) != 0 || !(s.st_mode & S_IFDIR) )
<Kamion>                                 return IOError(i);
<Kamion> but stat() will give S_IFDIR so that's fine
<Mithrandir> it confuses maintainers regularly, when they try replacing a symlink with a directory.
<Mithrandir> and it doesn't work.
<Kamion> in that case shipping /media in pmount.deb is exactly the right thing to do
<Mithrandir> Kamion: but, wrt 2256, I think putting localhost first on the line in /etc/hosts is broken.
<pitti> Mithrandir, Kamion: I just tried it with /media in the deb, works fine
<pitti> Mithrandir, Kamion: thanks a lot!
<Kamion> Mithrandir: possibly, kinda scared to change netcfg at this point though!
<Kamion> particularly given I don't really know offhand what to change ...
<Kamion> you're welcome to look though :)
<Mithrandir> Kamion: understandable.
<thom> fabbione: poke
<pitti> Mithrandir: gosh, the directory is present in <pkgdir>/debian/pmount/, but the created .deb does not contain it. Do you happen to know about any debhelper magic which deletes such directories?
<Kamion> you're sure you're using DH_COMPAT >= 2?
<Kamion> (or debian/compat)
<pitti> Kamion: yes
<Mithrandir> hmm.. dpkg doesn't drop empty dirs, does it?
<Kamion> shouldn't
<pitti> Kamion: debian/compat is 4
<Kamion> never has IME
<pitti> odd
<Kamion> try DH_VERBOSE=1
<daniels> i don't believe it does/has
<pitti> I didn't bother to look into the deb, I just looked into the package dir below debian
<Mithrandir> pitti: I can't duplicate it, by putting a mkdir call in debian/rules
<Kamion> Mithrandir: linux-restricted-modules failed to build, in case you hadn't noticed
<pitti> Mithrandir: odd. Well, I will try some other methods. BTW, the package which does not include it is on www.piware.de/pmount/
<Mithrandir> Kamion: argh
<Mithrandir> mdz is going to kill me
* Mithrandir blinks a bunch of times.
<pitti> Mithrandir: don't bother. It's actually a bug in midnight commander, it just does not display the media directory, but it's there
<pitti> Mithrandir: sorry about the fuss! I'm going to fetch my brown paperbag now...
<Mithrandir> pitti: oh, ok.
<Mithrandir> I SUCK
<Mithrandir> badly.
<Mithrandir> I'm going to make some food, then fix the restricted modules
<daniels> could someone please review http://people.ubuntu.com/~daniels/dbus/ ? fixes the problem whereby dbus-monitor segfaulted.  a lot. (probably need some dbus experience here)
<daniels> likewise g-v-m at http://people.ubuntu.com/~daniels/g-v-m/
<daniels> (the g-v-m stuff should enable proper gthumb support for cameras which do usb mass storage instead of proprietary protocols, and seems to work fine here)
<daniels> (dbus wfm also)
<pitti> daniels: oh, I also attached an interdiff to #1292 for the same problem
<pitti> daniels: do you have an interdiff?
<Mithrandir> I suck so badly I don't have words for it.
<daniels> ah
<daniels> pitti: interdiff is up now
<pitti> daniels: this is Sjoerd's patch, AFAICS
<daniels> pitti: oh, didn't see your interdiff in the bug
<daniels> pitti: yeah, sjoerd's patch plus unbreaking the @#($ clean target
<pitti> daniels: I moved the wrapper into /usr/lib/g-v-m and called gthumb with 'exec'. What do you think?
<pitti> daniels: ah, fixing the clean target is a good idea
<pitti> daniels: we should merge this
<daniels> pitti: um, the wrapper should be /usr/share/g-v-m
<daniels> pitti: give me a sec
<pitti> daniels: oh, right
<sjoerd> daniels,pitti: patch for me somewhere :) ?
<pitti> daniels: BTW, if the patch already deletes gmo files, it could as well delete them all
<pitti> sjoerd: we are using your patch for g-v-m and gthumb, but slightly modified it
<pitti> daniels: your interdiff does not contain the gmo deletion
<daniels> pitti: new interdiff/sources up
<daniels> pitti: the deletion is done in debian/rules
<daniels> pitti: be sure to look at ubuntu3-to-ubuntu4, not ubuntu2-to-ubuntu3
<pitti> daniels: ah, I looked at the wrong file
<pitti> daniels: why do you install the wrapper as 644? It should be executable, or not?
<sjoerd> pitti: improvements are always welcome 
<pitti> daniels: can you attach the updated interdiff to #1292, for mdz's approval?
<daniels> pitti: sure
<daniels> pitti: er, right, my bad
<Mithrandir> could somebody look at and test http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff ?
<daniels> pitti: good catch, thanks
<pitti> daniels: now it looks fine to me
<daniels> pitti: thanks
<pitti> daniels: well, let's call it "peer review" instead of "redundant work" :-))
<daniels> heh!
<daniels> pitti: sorry, I had no idea you were working on it
<daniels> pitti: i scrounged around on the BZ, but couldn't find anything
<pitti> daniels: dame for me :-)
<pitti> daniels: same, of course
<daniels> can people please test cameras in g-v-m with http://people.ubuntu.com/~daniels/g-v-m/ ?
<daniels> usb mass storage cameras should now work fine
<pitti> daniels: I tested with my gphoto camera and MS, both work fine
<daniels> pitti: well, I'm off to bed, it's 0252 here and in making the last source package I mistyped my GPG password about 5 times
<daniels> pitti: cool
<pitti> daniels: BTW, did you get two dialog boxes, too?
<pitti> daniels: for a gphoto cam?
<daniels> pitti: er, just the one
<daniels> i'll have to debug it in the morning, though
<sjoerd> Sjrd Simons ? :)
<daniels> is it sjoerd rather than sjrd?
<daniels> oh yeah
<sjoerd> yeah
<daniels> god, now I'm getting you mixed up with jrg schilling
<daniels> sjoerd: sorry about that :\
<sjoerd> pitti: you get one from gvm itself and one from gphoto (search the cam)
<Mithrandir> Kamion: could you look at http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff , please?
<thom> oh man, mortal insult
<Kamion> Mithrandir: looked at it a moment ago, seemed fine to me, don't have time to do a test build though :-/
<sjoerd> daniels: hopefully only in name, not in image 
<daniels> sorry, updated sources up
<pitti> sjoerd: I got the "would you like to import the photos" with OK and Cancel twice
<Mithrandir> Kamion: ok :/
<daniels> thom: you know it's really time to go to bed when ...
<pitti> sjoerd: I suppose this is a hal bug since the camera creates two nodes
<daniels> sjoerd: updated sources up -- sorry again about that
<daniels> 'nacht
<Kamion> can anyone review the patch in https://bugzilla.ubuntu.com/show_bug.cgi?id=993, please?
<Kamion> (grub-installer menu/timeout stuff for dual-booters)
<sjoerd> pitti: maybe a hal-hotplug-map bug..
<sjoerd> daniels: np
<pitti> sjoerd: I suppose
<pitti> sjoerd: I have a camera node and a PTP node
<pitti> sjoerd: I suppose hal regards both as a camera
<sjoerd> pitti: check the info.category props if any
<thom> Kamion: looks reasonable to me
<daniels> Kamion: the only note would be that if that was called outside of d-i, it would break on /target != /
<daniels> Kamion: other than that, looks good to me.
<Kamion> sure, but grub-installer never will be
<pitti> Kamion: the sed's look a bit scary and the second one could be made a bit easier with \+ instead of *, but otherwise it looks as if it does what it should
<Mithrandir> Kamion: the busybox sed supports [:space:] ?
<daniels> Kamion: oh, grub-installer, not grub.  phat.
<Kamion> pitti: according to regex(7) \+ does not exist
<Kamion> Mithrandir: yep - tested and everything
<Mithrandir> then it looks good to me.
<pitti> Kamion: oh, it's a GNU extention
<daniels> Kamion: if busybox sed supports -i, that might be more elegant, but meh
<Kamion> pitti: ah, it does seem to work in GNU sed
<Kamion> dunno about busybox, didn't try
<Kamion> does seem to work in busybox, oh well
<Mithrandir> . o O ( busybox perl )
<thom> damn, the subversion test suite takes forever
<Kamion> daniels: apparently not
<pitti> Kamion: BTW, it does not allow spaces in front of the keywords, but I suppose this cannot happen since the installer uses a file from scratch, right?
<Kamion> pitti: right, it's called update-grub immediately beforehand
<Mithrandir> thom: care to look at http://err.no/patches/linux-restricted-modules-2.6,8.1.3-2.diff , then, since you're idling anyhow? :)
<Kamion> daniels: (unfortunately)
<daniels> Kamion: much of a muchness, I'm used to the < foo > foo.ish && mv foo{.ish,} notation anyhoo
* daniels really sleeps.
<Kamion> yeah, it was stolen from immediately above in that script anyway :)
<thom> Mithrandir: dumbass :-) looks reasonable
<Mithrandir> thom: can you test it as well, to make sure I haven't fucked up?  I'd _hate_ to have two brown bag releases after each other. :)
<thom> heh
<thom> geez, i spose
<sjoerd> time to eat
<thom> Mithrandir: it'll have to wait till after the svn test suite, since i'm in x86 mode currently
<Mithrandir> that's fine. :)
* thom -> amd64
<thom> 25 minutes for a full install. pretty good
<thom> Mithrandir: well, that built
<Mithrandir> thom: can you try to build on an i386 as well?
<thom> gar
<thom> that means rebooting again, you git :-)
<Mithrandir> thom: I'll buy you beer
<sabdfl> mdz: so... in the "big changes at the last minute to mission critical software" dapartment...
<sabdfl> s/dap/dep/
<sabdfl> i just learned that there is such a thing as PL?Python for POstGres
<sabdfl> thom: nice duck on the epoch there, well done :-)
* sivang notes he thinks postres is wonderful. he likes it much better than MySQL
<thom> sivang: poor deluded fool :-)
<pitti> thom: hey, PostgreSQL _is_ nice!
<pitti> let's start a flamewar (or better not...)
<Kamion> sabdfl: current daily should be worth testing for ipw2[12] 00 support in the installer
<sabdfl> kamion: will o
<sabdfl> right o, will do, pick one
<Kamion> doesn't seem to work with my acx card, but I think that's a driver issue rather than broken firmware support
<Kamion> the firmware does get loaded according to syslog, but then it can't actually talk to anything - shrug, it's a cheapo card
<sabdfl> ok.... command to detach from a screen session?
<Kamion> C-a d
<sabdfl> while it comes down... do we have an rsync module that is just the warty / hoary release / preview cd's, install and live, as discussed?
<Kamion> not yet, I'm still due to talk with elmo about implementing that
<Kamion> before Wednesday ...
<sabdfl> yup.
<sabdfl> well, tomorrow, for mirrors that can respond quickly
<Kamion> ok, noted
<Kamion> right, the acx card doesn't work in an installed system either, so not a d-i bug; good
<sivang> thom : quite deluded (I caught up this virus that doesn't let go) yeah :) however one cannot not notice the license differences between the two ;-)
<thom> sabdfl: see my email to you/lu about expires?
<pitti> sivang: is your only concern about my/postgresql license stuff?
<sivang> pitti : ofcourse not :)
<sabdfl> thom not yet... catching up
* Mithrandir grumbles and downloads an iso
<thom> sivang: frankly, i prefer a db that cares about upgradability to a nicely licensed one *shrug*
* sabdfl relishes the new quickfile extension that has finally been written a year after he issued the bounty
<thom> sabdfl: gosh, quick turnaround... d'you fancy issuing a "please make firefox less buggy" bounty? :p
<sabdfl> thom: i considered asking the mozilla guys to get off their asses on the RC bugs we had, given the other support i've given them
<azeem> easy. ln -s /usr/bin/epiphany /usr/bin/mozilla-firefox :)
<sabdfl> but the list looked too long, and there were probably more lurking in there
<Mithrandir> thom: you're happy with the package?
<sabdfl> azeem: agreed, if epiph had the same feature set i'd back a native app any day
<thom> Mithrandir: yes, it seems fine (I can't actually test any of the contents)
<thom> sabdfl: yeah, it's unfortunate in the extreme that bug list seems to be growing as they near 1.0 :(
<sabdfl> thom: inevitable with a psych milestone like 1.0, everyone wants their favourite patch to land
<thom> yeah
<Mithrandir> thom: ok, I'll build and upload, then.  Thanks for testing.
<thom> Mithrandir: care to look at https://bugzilla.ubuntu.com/show_bug.cgi?id=2259#c2 by way of a swap? :-)
<Mithrandir> thom: the patch from http://svn.collab.net/viewcvs/svn/branches/1.0.x/subversion/libsvn_subr/cmdline.c?rev=11018&r1=8524&r2=11018 seems like happiness to me.
* Mithrandir goes to the shop
<thom> ta
* Kamion looks for review of https://bugzilla.ubuntu.com/show_bug.cgi?id=2268
<Kamion> the patch is large due to *.po updates; the actual text under review is right at the end
<Kamion> thom: did you mean to close #2259 too?
<Mithrandir> elmo_: could you please adjust PaS for linux-restricted-modules-2.6.8.1?  It should be built on amd64 as well
<elmo_> Mithrandir: as I told you the other day, it's not in p-0a-s
<elmo_> Mithrandir: and you broke the i386 build
<elmo_> linux-restricted-modules-2.6.8.1_2.6.8.1.3-2_i386.changes
<elmo_> REJECT
<elmo_> Rejected: nvidia-glx_1.0.6111-1ubuntu5_i386.deb: old version (1.0.6111-1ubuntu5) in warty >= new version (1.0.6111-1ubuntu5) tar
<elmo_> geted at warty.
<elmo_> etc. 
<Mithrandir> elmo_: I didn't see that.
<elmo_> you wouldn't - it wasn't the sourceful upload
<Mithrandir> and, that was what mdz talked about. aaargh.
<elmo_> yeah, even herbert himself gets bitten by that bug
<Mithrandir> I'm beginning to hate that package.  A lot.
<mdz> sabdfl: Python procedures in postgresql sounds very cool
<mdz> Mithrandir: I had already tested that gzip change on your workstation
<mdz> it does fix the bug
<Mithrandir> mdz: ok, I'm installing a dual celeron now to see if I can reproduce it there.
<Mithrandir> http://raw.no/patches/linux-restricted-modules-2.6.8.1.3-3.versionbump.diff <-- somebody please review?
<mdz> fabbione ph33rz my gzip patch
<mdz> Mithrandir: looks good
<mdz> Mithrandir: that's what I did after I broke it
<mdz> Mithrandir: and what Herbert did after he broke it
<mdz> but it would be nice if someone would fix it permanently :-)
<Mithrandir> how to fix it permanantly?  Store the version number in a file somewhere?
<mdz> something like that, to allow for an error if you forget to update the other one
<mdz> but don't let that delay your quick fix
<mdz> pitti: your interdiff in #2208 looks good
<doko> kamion: #1232 please feel free to reassign it to you, I just synced the translations from unstable and waited for some feedback.
<elmo_> gst-plugins0.8 FTBFS on amd64
<mdz> seb128: ^^^
<Mithrandir> mdz: ok, thanks, uploaded.
<seb128> mdz: ok
<seb128> I'll have a look
<mdz> elmo_: have you been brave enough to put the gzip fix on emperor?
<elmo_> mdz: emperor?
<elmo_> you mean jackass?
<Mithrandir> mdz: we could take the revision number from l-r-m, s/-/./ and use that after ubuntu in the nvidia-glx version number
<Kamion> mdz: thom installed the gzip fix on little, it fixed the hangs that reliably scuppered the 20041010 and 20041011 CD builds
<elmo_> REJECT
<elmo_> Rejected: libglib2.0-udeb_2.4.7-0ubuntu1_x86_64.udeb: architecture part of filename (x86_64) does not match package architecture
<elmo_>  in the udeb (amd64).
<elmo_> hmm...
<pitti> mdz: great, can I regard this as approval?
<Mithrandir> would give us 1.0.6111-1ubuntu2.6.8.1.3.3
<Mithrandir> ugly, but should work.
<mdz> pitti: yes
<Mithrandir> or ubuntu+restricted+2.6.8.1.3+3
<mdz> elmo_: lamont mentioned the same thing
<mdz> elmo_: where did it come from?
<elmo_> mdz: dunno - other amd64 udebs have been built since without such fucked filenames
<elmo_> hmm, on a different host tho
<Mithrandir> bug in libglib?
<amu> guess the problem comes from uname : Linux amu.debian.net 2.6.8-3-amd64-k8 #1 Mon Aug 30 01:09:23 CEST 2004 x86_64 GNU/Linux
<mdz> Kamion: thanks for taking care of #993, one FAQ down
<mdz> but surely we've built libglib before
<mdz> successfully
<mdz> amu: hey, welcome
<amu> mdz: *hi*
<seb128> hum
<seb128> for the udeb problem:
<seb128> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275419
<seb128> DEB_BUILD_GNU_CPU -> DEB_BUILD_ARCH
<seb128> has been made by JHM
<elmo_> yeah
<elmo_> udebname=libglib$(apiver)-udeb_$(debversion)_$(shell dpkg-architecture -qDEB_BUILD_GNU_CPU).udeb
<mdz> ick
<elmo_> why on earth does DEB_BUILD_ARCH return 'i386' on hurd anyway?  that's so not the "Debian architecture of the build machine"
<sabdfl> Kamion: didn't work with the ipw2200 test laptop :-(
* Mithrandir thinks this mobo will soon be angry.
<sabdfl> this with the latest daily
<elmo_> azeem: ?
<Mithrandir> this is fun, grub is broken on this system.
<Mithrandir> hangs on "GRUB loading, please wait"
<amu> elmo_: http://lists.debian.org/deity/1999/06/msg00041.html 
<elmo_> amu: whiuch is why 275419 doesn't make any sense
<Mithrandir> heh, seems like the hpt366 controller fucks with grub.
<mdz> elmo_: jackass, whatever
<mdz> elmo_: I don't suppose you had a reliable way to reproduce it on that machine?
<mdz> if you haven't upgraded it already, it might be worthwhile to try to apt-extracttemplates test
<mdz> and then upgrade it and verify the fix
<Mithrandir> Kamion: wantabug? :)
<elmo_> mdz: it's running UP now, so the issue's latent
<elmo_> and I'm so not rebooting that box again :-P
<amu> elmo_: sorry I just read with one eye and till reading the mail, finally i thing problem comes from dpkg *ducks* 
<mdz> elmo_: what went wrong with it last night?
<elmo_> mdz: our kernel breaks if you add just 'nosmp' to the command line - it needs 'nosmp noapic'
<mdz> elmo_: but a UP kernel boots fine without noapic?
<mdz> amu: where can I download the ubuntu/gnoppix iso?
<azeem> elmo_: yeah?
<elmo_> mdz: I suspect so, but dunno for sure - I didn't want to experiment at the time (4am and all) - I'll do so next time I'm there on a less critical machine, and file a bug if so
<elmo_> azeem: what's dpkg-architecture -qDEB_BUILD_ARCH return on hurd-i386 for you? 
<azeem> hmm, one sec
<pitti> sjoerd: still here?
<sjoerd> pitti: somewhat yes
<mdz> Kamion: I thought base-config already did mention sudo
<pitti> sjoerd: I'm just at debugging the double camera dialog bug
<amu> mdz: ;) http://www.gnoppix.org/pages/downloads/index.html Telefonica is probably the best connected  
<azeem> 21:33 < jbailey> azeem: hurd-i386
<azeem> :)
<azeem> elmo_: ^--
<pitti> sjoerd: I have two devices: the camera itself (with info.capabilities = camera and camera.libgphoto2_support = 1) and an "USB PTP Interface" with just the camera capability.
<elmo_> azeem: thanks
<pitti> sjoerd: what do you think: shall hal be fixed to report just one device as camera?
<amu> btw. hi azeem 
<elmo_> gar, I misread the bug - it's fine, we just need the same fix in our glib2.0
<pitti> sjoerd: or shall we fix g-v-m to additionally check for camera.libgphoto2_support or camera.access_method?
<azeem> elmo_: any other questions, otherwise I could summon jbailey
<elmo_> azeem: nah, that's cool thanks
<sjoerd> pitti: can you put lshal of that somewhere ?
<mdz> Kamion: I think the text can be a bit less scary
<seb128> elmo_: I'll fix it
<elmo_> seb128: cool
<azeem> amu: hey. noel just said you'll be in Frankfurt/LWE. I'll probably drop by as well :)
* Mithrandir reboots his system with a shiny new smp kernel.
<pitti> sjoerd: http://www.piware.de/lshal.cam
<sjoerd> pitti: who is setting the camera only capability btw.. the hotplug map callouts always sets both 
<pitti> sjoerd: I know, and in fact both nodes are valid to have a camera capability
<pitti> sjoerd: because this camera can be used with the traditional gphoto access, and also with the newer PTP interface
<sjoerd> pitti: one node is PtP the other is proprietary something ?
<sabdfl> mdz: which scary text?
<pitti> sjoerd: yes, historically every camera had its own access method, but the PTP is a common standard now
<mdz> sabdfl: https://bugzilla.ubuntu.com/attachment.cgi?id=427
<sjoerd> pitti: i've got a cam which can do multiple modes too (ptp and mass storage), but you need to choose one 
<pitti> sjoerd: I'm currently not sure whether this is a hal or a g-v-m bug
<Mithrandir> mdz: fwiw, can't reproduce the problem on dual celeron 466.
<sjoerd> pitti: the second udi is the parent of the first.. so apperently capabilities go down to the children
<Mithrandir> (sorry, dual 433)
<pitti> sjoerd: my inclination is currently to fix that in g-v-m and choose the preferred interface there
<pitti> sjoerd: both work; I can either cancel the first message box and accept the second, or the other way round
<pitti> sjoerd: however, in the long run we should prefer the PTP protocol
<Mithrandir> mdz: so, even though it's a bug in gzip, I also think it exposes a timing issue with HT, but I guess we should let it just be closed with the new gzip.
<pitti> sjoerd: maybe hal shouldn't attach a camera capability for both a parent and a child node... This is so arbitrary...
<amu> azeem: unfortunatley not, the government put me on jail :) too many guys go to lwe so i can make some nice days with hot ........ supportcalls :)  
<sjoerd> pitti: i find it strange that the hotplug map callout has put the stuff on the parent, not on the child
<sjoerd> pitti: also not the info.bus prop on both devices
<mdz> Mithrandir: Herbert's comment on the bug is informative
<sjoerd> pitti: i'm watching ST for a while, i'll have a real look afterwards :)
<pitti> sjoerd: oh, have fun!
<Mithrandir> mdz: yeah, but I somehow think it should have been exposed on this system as well.
<Mithrandir> anyhow, I need sleep.
<pitti> sjoerd: both nodes have identical product and vendor ids, so both are recognized by hal's hotplug_map
<mdz> Mithrandir: night
<sjoerd> pitti: maybe we need to fix hotplug_map to only set it on the node with info.bus == usb
<sjoerd> pitti: need to test with my own cam to see how that behaves
<pitti> sjoerd: I just noticed that we don't need to prefer a volume anyway, because gthumb will choose
<lamont> moo
<pitti> sjoerd: I would prefer not to set camera if the parent already has a camera capability
<pitti> sjoerd: this seems more robust than selection by bus
<lamont> elmo_: nvidia-glx was what you were mentioning just a bit back, yes?
* lamont is finally reading email.
<sjoerd> pitti: i'll have a good look in 45 min. :) but that capability i'm currently guessing the capability on the parent is wrong
<pitti> sjoerd: okay, I won't disturb you any further. ST^Weducation is important :-)
<sjoerd> pitti: :)
<mdz> can someone peer-review https://bugzilla.ubuntu.com/attachment.cgi?id=428&action=edit
<mdz> ?
<mdz> or rather, https://bugzilla.ubuntu.com/attachment.cgi?id=428
<lamont> hrm...  OO.o build-depends a universe package.
<lamont> (libaltlinuxhyph-dev)
<doko> mdz: #2256, is the changed nsswitch.conf a better default?
<lamont> mdz: gzip patch looks sane to me.
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 14 RC bugs to go
<elmo_> lamont: yes
<mdz> doko: why did you upgrade 2256 after I downgraded it?
<doko> mdz: did I upgrade it? not by intent
<mdz> doko: must have been a mid-air collision
<doko> anyway, what about the suggested solution?
<mdz> doko: not for warty
<sabdfl> Kamion: it didn't detect my ipw2200 card
<sabdfl> but if i switch to vc3 and modprobe ipw2200
<sabdfl> then go back and rerun network hardware detection
<sabdfl> it works
<sabdfl> peachily
<sabdfl> do you need lspci details?
<sjoerd> pitti: weird i only get the capability on the parent 
<pitti> sjoerd: so the child doesn't have vendor and product id?
<sjoerd> pitti: it does.. but it's not hotplug_map that's setting the stuff on the child..
<sjoerd> pitti: on your system thatis
<pitti> sjoerd: not?
<pitti> sjoerd: oh, I thought it was because the child and parent have identical vendor and product ids
* lamont only sees 13 RC bugs.
<sjoerd> pitti: if hotplug_map sets camera it also sets camera.access_method and camera.libgphoto2_support
<pitti> sjoerd: ah, you are right
<pitti> sjoerd: that would mean that hal can now detect cameras on its own?
<pitti> sjoerd: ah, I think I know what's going on:
<pitti> sjoerd: previous ubuntu versions added some fdi files for the A70 (I have that) and some other cameras which also add some attributes
<sjoerd> ah.. so the capability comes from the fdi file
<pitti> sjoerd: so I guess I just have to delete the fdi files; they are obsolete anyway
<sjoerd> pitti: yeah that will fix it.. I'm now trying to find out why it's on the parent and not on the child
<sjoerd> pitti: but that doesn't matter for g-v-m
<pitti> sjoerd: right
<pitti> sjoerd: nice that the solution is so trivial... :-)
<sjoerd> hmm it seems that hotplug_map only does devices on bus usb_device
<sabdfl> mdz: attachment#427 looks good to me
<sjoerd> pitti: bah the hotplug maps don't have the info to choose one interface..
<pitti> sjoerd: exactly, they only rely on product/vendor id presence
<sjoerd> pitti: so we can't easily improve it, but removing the fdi's will help :)
<pitti> sjoerd: that's why I thought that the error was there
<sjoerd> pitti: for the right fix you probably have to call libgphoto itself to probe.. but as g-v-m doesn't provide the device to gthumb anyway this works..
<sjoerd> suck when having multiple ptp cams attached though
<pitti> sjoerd: why, each one should have its own device
<sjoerd> pitti: you but gthumb will scan and find both, while it should just open the one you just plugged in
<pitti> sjoerd: ah, right
<pitti> sjoerd: so in the future, gthumb should get an (optional) parameter which device to scan
<sjoerd> pitti: the future is in the libgphoto dbus service, so things will change anyway
<sjoerd> i've got the same problem with sound-juicer though
<mdz> sabdfl: I thought the bit about damaging your system was unnecessary; every single user is shown this message, even those who don't know what a command line is
<sabdfl> ah, ok, agreed
<sabdfl> is this on an existing prompt, btw, or a new one?
<sjoerd> pitti: btw i was wondering how ubuntu handles cdrw on which you want to burn something new ?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 13 RC bugs to go
<pitti> sjoerd: the ubuntu version of n-c-b unmounts the cd before burning
<sabdfl> either way, we are still going to get a lot of questions, because the 3l33t users who go for root immediately won't read anything we put on the screen during install :-)
<sjoerd> pitti: ah nice ;)
<mdz> sabdfl: this is an appended paragraph to an existing dialog
<sabdfl> ok
<sabdfl> thanks
<mdz> Kamion: where do we stand on the kernel metapackages at install time?  that's very important for the release
<pitti> sjoerd: want the patch?
<sjoerd> pitti: did you send pci_pre_process_check_null.patch hal patch upstream ? it was the only one that wasn't in CVS yet
<pitti> sjoerd: actually I sent all patches to David
<pitti> sjoerd: he ack'ed most of them to me, but this patch came in a separate mail
<pitti> sjoerd: so maybe he forgot about it
<sjoerd> pitti: could be, i noticed it yesterday when i was integrating ubuntu's hal changes
<pitti> sjoerd: oh, did you? Thanks
<pitti> sjoerd: it's a pain to apply the ubuntu changes to new upstream/debian versions
<sjoerd> pitti: guess you need to remind him :)
<pitti> sjoerd: will do
<pitti> sjoerd: I will ask him to remove the remaining camera fdi file as well
<mdz> pitti: patch for #1292 looks good
<sjoerd> pitti: ross maintains n-c-b, so maybe he would like the patch 
<pitti> mdz: okay; daniels grabbed the bug in the meantime, so I'm not sure whether I shall upload it
<mdz> pitti: have you tested it very thoroughly and to your satisfaction?
<mdz> I am not entirely certain that it should go into warty
<pitti> mdz: well, I tested it with the two devices that I have, and daniels tested with his'
<pitti> mdz: so far it worked well and the patch looks straightforward
<pitti> mdz: it is not elegant though (this required modification of g-v-m)
<pitti> sjoerd: my new hal package works fine!
<mdz> pitti: did anyone test for regressions with non-usbstorage cameras?
<pitti> mdz: I have a gphoto camera, works fine
<pitti> mdz: daniels, too
<sjoerd> pitti: hehe, good thing i didn't put your fdi's in the debian packages :)
<pitti> mdz: in fact the very same camera now works even better with the new hal package in #2264. Even easier patch :-)
<pitti> sjoerd: right :-) But there's still one camera fdi in upstream
<sivang> pitti : finally my USB Key works. thanks :-) (just retested)
<pitti> sivang: finally some good news. thanks :-)
<sjoerd> pitti: that has <match key="info.bus" string="usb_device">
<sjoerd> pitti: so that will work
<sivang> pitti : I had tested almost every time you published a patch, is is now working consitently :)
<pitti> sjoerd: okay, but it is not really required any more anyway
<sjoerd> pitti: true
<pitti> sivang: nice to hear that two times before a release deadline :-)
<pitti> mdz: patch for #2264 just reverts some supplemental fdi files that were introduced with an earlier warty version. Can I upload this?
<sivang> pitti : my _pleasure_
<sjoerd> pitti: http://luon.net/~sjoerd/hal/hal-0.2.98/ contains the latest debian hal packages (which is still stuck in NEW :( )
<mdz> pitti: I'm making my way through my warty-bugs mailbox; just saw that one
<pitti> sjoerd: just looked at the changelog, nice :-)
<pitti> sjoerd: do you consider to add the "run as user" option as well? (With default file)
<pitti> sjoerd: with default off for Debian, of course
<sjoerd> pitti: i knew i forgot something :)
<Kamion> sabdfl: yes please, send 'lspci' and 'lspci -n' output and I'll make it work
<pitti> sjoerd: BTW, I made another change to the hal package which could interest you
<Kamion> mdz: ok, happy to drop the "use this with caution" sentence; is it OK apart from that?
<pitti> sjoerd: somehow the hal daemon isn't stopped if the package is upgraded, so the old process continues to run
<sjoerd> pitti: that should be fixed in the debian package too
<pitti> sjoerd: I fixed this by stopping hald already in the preinst (which seems to work fine)
<Kamion> mdz: base-installer's on my list for tomorrow, honest :)
<sjoerd> pitti: the debian package stops dbus in preinst now
<sabdfl> Kamion: on its way
<pitti>     # already stop hald before upgrading the package; this fails in the postinst
<pitti>     start-stop-daemon --quiet --stop --oknodo --exec /usr/sbin/hald
<pitti> fi
<pitti> Oops, sorry, this should all go to sjoerd...
<mdz> Kamion: yes, sudo text is fine with me with that change
<mdz> Kamion: at this point, I'd be more than happy to add a super-magic-uuid-token to the description of the linux-foo packages for base-installer's sake
<mdz> Kamion: and fix it better for Hoary
<sivang> mdz : I'm starting work on the GNOME 2.8 manual for Ubuntu, I'm concerned about copyrights - which can I drop, which to change etc?
<sivang> mdz : it's copyrighted Sun Microsystems.
<pitti> sjoerd: did you fix the partition detection in Debian?
<sjoerd> pitti: debian/patches/fs_probing.patch
<Kamion> mdz: why don't I just grep for the ones we know are ours for warty?
<Kamion> i.e. big hardcoded list
<sjoerd> pitti: upgrades volume_id to the cvs version, which contains somewhat more fixes then just part. detection
<Kamion> sivang: you need to have a very careful basis for your argument before dropping any copyright notices
<pitti> sjoerd: yeah, I saw these patches
<Kamion> sivang: if you want to drop a copyright notice, you must be sure that you've removed everything significant written by that copyright holder
<pitti> sjoerd: otherwise I did not find anything, apart from the default file both packages are relatively close
<sjoerd> pitti: when the pkg-utopia project on alioth, i'll put the hal and g-v-m packages in svn. Should make cooperating easier
<sivang> Kamion : I see then. Keep sun's copyright notice, add our own?
<Kamion> sivang: that would be normal practice
<sivang> Kamion : or "Portion Copyright Ubuntu Linux" ?
<sivang> Kamion : Portion(s)
<Kamion> "Copyright (c) 2004 Canonical Ltd." is what I've been adding
<Kamion> (or equivalent)
<sivang> Kamion : ok, thanks!
<Kamion> since you don't work for Canonical, perhaps "Copyright (c) 2004 Sivan Green" would be more appropriate
<mdz> Kamion: that's fine with me
<mdz> Kamion: but when I suggested that the last time, you sounded less than enthusiastic :-)
<Kamion> you shouldn't say copyright some other organization unless you have an employment contract with them specifying copyright ownership, or you've filled out copyright assignment papers
<Kamion> mdz: I am less than enthusiastic, but what works wins right now
<mdz> wow
<mdz> over 100 live CD downloads in the past 24 hours
<mdz> via bittorrent alone
<sivang> Kamion : however , if this document needs to be defendent at court, I think canonical copyright is better.
<mdz> Kamion: agreed
<sivang> Kmaion : I've read on the GNOME devels guidelines that regarding to Ximian
<Kamion> sivang: unless you have a contract, Canonical has no right to defend it in court *anyway*.
<Kamion> sivang: use your own name.
<sivang> Kamion : Oh
<Kamion> (since we're not the copyright holder unless you legally assign the copyright to us)
<sivang> And me stating the copyright to canonical doesn't suffice as such?
<Kamion> (which I imagine you could do if you wanted, but it's bureaucracy, and I don't think we're requiring it of Ubuntu contributors in general)
<Kamion> see the GNU project's copyright assignment procedures
<Kamion> they're a bit more involved than that
<sivang> hmm, Well I'll assume that having sun on the copyright notice is fair enough by now, at least for warty :)
<sivang> (assuming their microsoft agreement won't fiddle with those parts :-)
<hazmat> is there a page with bounties for ubuntu or canonical?
<pitti> hazmat: http://wiki.ubuntulinux.org/WartyWarthog_2fBounties
<hazmat> ugh.. the wiki ui has turned all the actions links into a flat list.
<hazmat> pitti, thanks
<sivang> hazmat : I noticed that also, but only for specific parts. strange ha?
<Kamion> sivang: if Sun have contributed legitimately to the documentation, and it's under a free licence, that's fine ...
<hazmat> its does it for me on every page.
<sjoerd> pitti: you should add some bounties for hal stuff :)
<pitti> sjoerd: one for fixing all potential SIGSEGVs would be nice :-)
<doko> kamion: will you care about #1232, or should I prefer packages for the 4 updated translations?
<Kamion> doko: was planning to do it tomorrow, although I don't mind if you do it either before then
<Kamion> doko: I'm doing a base-installer change anyway, so maybe it would be easier for locking purposes at this point if I took care of it
<Kamion> mdz: are d-i translation changes in general OK?
<mdz> Kamion: absolutely
<doko> so, I can go ahead and merge the 2MB patch to the installer packages mentioned?
<mdz> as long as it only touches .po files, sure
<doko> ok, when is the last day for .po updates? I want to ask for updates for the translations, which still need to be done, on the users list.
<jdub> pitti: still need 2208 and 2209 checked?
<pitti> jdub: no, I already uploaded it. Thanks anyway!
<jdub> ok
<pitti> jdub: good morning, BTW! :-)
<Kamion> doko: tomorrow
<jdub> :)
<mdz> doko: we can be quite flexible with translation updates; ask Kamion when he would need them in order to do the final CD build
<Kamion> mdz: patch in #2136, untested yet
<Kamion> oh, tomorrow for release candidate
<Kamion> if mdz and jdub are happy with updates between RC and release, anything up to next Monday
<Kamion> any later than that starts to get very risky
<Kamion> as opposed to merely quite risky :)
<mdz> Kamion: patch looks perfect, fire away
<lamont> Kamion: s/very/extremely/; s/quite/very/
<mdz> I'm happy with translation updates between RC and release
<Kamion> lamont: :-0
<Kamion> :-)
<lamont> Kamion: are there any univers packages on the CD, btw?
<Kamion> lamont: should certainly hope not :-0
<lamont> just double checking my assumptions.
<doko> ok, I'll send an email to the users list asking for updated translations and trying to get most of it done tomorrow (those which are merged from Debian).
<Kamion> lamont: the cdimage build process does not even rsync universe or multiverse, just to make sure
<lamont> Kamion: awesome
<mdz> Kamion: regarding #2276, shall we add the package to the germinate workarounds section for now?
<lamont> mdz: note that it's only a build-dep, not a dep.
<Kamion> mdz: is dpkg-dev not already in a seed?
<lamont> dpkg-dev is too new.
<Kamion> too new?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 12 RC bugs to go
<lamont> ii  dpkg-dev       1.10.22ubuntu2 Package building tools for Debian
<mdz> thom: ping?
<Kamion> grief, no, apparently dpkg-dev is only pulled in via debhelper etc.
<lamont> and the d-w says dpkg-dev (<<1.10)
<Kamion> lamont: oh, duh, I see
<mdz> that's one of those awful hacks to try to support building on woody with different build-deps
<Kamion> and germinate doesn't do << deps? how broken
<lamont> used to be it didn't...
<Kamion> mdz: if you meant libaltlinuxhyph-dev, hell yeah
<mdz> Kamion: I did, ok, will do
<Kamion> I don't see any version-checking code, indeed
<Kamion> probably doesn't understand >= etc. either
#ubuntu-devel 2004-10-23
<Kamion> mdz: can I add the linux-* metapackages to base? :-)
<Kamion> (minor problem installing them when they aren't on the CD)
<Kamion> and adapt the other seeds too, probably
<Kamion> mdz: you may want to adapt your ubuntu-meta update script to cope, if you haven't already
<Kamion> mdz: I might kill the install_restricted_modules function as well if you don't mind
<mdz> Kamion: sure
<mdz> Kamion: (to both)
<mdz> Kamion: the version of ubuntu-meta that went into the archive uses debootstrap as a filter for base, so as long as you don't add them to debootstrap, you're safe
<Kamion> I don't think linux-386 etc. ever went into a seed, slightly puzzled about how it's in the archive
<sivang> jdub : around?
<mdz> Kamion: perhaps elmo massaged it, since I mentioned it to him around the time I was uploading it
<sivang> seb128 : ping
<seb128> pong
<sivang> seb128 : Could you briefly explain how does the yelp ubuntu package finds the documentation package? do they cross depend?
<seb128> define "documentation package" please
<sivang> seb128 : documentation package = where all the docs displayed by yelp are
<mdz> sivang: /usr/share/omf
<seb128> that's it :)
<sivang> seb128 : what's the pkg name ? there must be a pacakge to put those files there :)
<seb128> no
<seb128> each gnome package has some omf file for example
<sivang> mdz : tnx
<seb128> and scrollkeeper-update is called in the postinst
<mdz> sivang: are you working on #1205?
<mdz> elmo_: if you don't have an opportunity to debug #2211, please arrange access for me or someone else
<sivang> mdz : yes, but not only on :) I'd like to know also how to introduce new docs besides the offline "home page"
<mdz> is bugzilla broken for anyone else?
<sivang> mdz : yes
<mdz> sivang: the home page would not be registered in yelp
<mdz> but if we are going to do an offline home page, it needs to be done today
<sivang> mdz : are you putting it ubuntu-desktop ?
<mdz> sivang: I do not have anything to put it in at the present time
<mdz> s/it in/in it/
<mdz> I can't get to anything at the DC
<sivang> mdz : DC=?
<mdz> data centre
<mdz> elmo_: ?
<jdub> the on-disk home page will live in ubuntu-artwork
<jdub> i've hacked up a simple on
<jdub> e
<sivang> jdub : why don't you send it up to me, I'll add to it some ?
<jdub> ok
<sivang> I can't even access ubuntu.com 
<sivang> jdub : you know the address?
<jdub> yes
<mdz> thom: ping?
<sivang> jdub : thanks, I'll do a merge between our 2 versions and send it to you for approval?
<sivang> mdz : regarding the dead line, that's strange. I understood from John Hornbeck that it's the 18th, is it?
<sivang> mdz : sorry, this was meant to go to jdub :)
<sivang> jdub : I was sure it had to be sometime closer, as the cd needs time to get pressed :)
<sabdfl> elmo_: knows, has remote hands incoming to check
<sabdfl> i'm not too far if it needs someone onsite
<mdz> ok
<mdz> thanks for checking
<mdz> what kind of box is passing for a firewall over there?
<sabdfl> ibm
<sabdfl> ubuntu
<sabdfl> 2.4 kernel, hasn't been rebooted to 2.6 yet
<sivang> seb128 : for example, the gnome-user-guide get's instlled when I install the GNOME desktop ?
<sivang> seb128 : or it's meta package for that matter.
<seb128> ?
<seb128> it's in the desktop seed
<seb128> meta package for what ?
<Kamion> ubuntu-desktop I imagine
<sabdfl> Kamion: is the ubuntu-desktop package installed?
<sivang> seb128 : just a though :) 
<sabdfl> maybe a good idea is to have it but not install it?
<Kamion> sabdfl: it's installed, yeah
<sabdfl> that way someone can knee-jerk their system into a state of compliance, then get rid of it while they tune
<sivang> seb128 : thought. Suppose you had a meta package for gnome (that includes all gnome's dependecies) 
<Kamion> I thought the point of it was to have it installed so people could use it to track by default
<Kamion> the system starts out in a state of compliance :-)
<sabdfl> well... between releases it will only cause pain
<Kamion> certainly they can get rid of it
<Kamion> hm, won't it help?
<Kamion> how can we reliably add new packages to desktop otherwise?
<sabdfl> it means they get TWO warnings when they override a default of ours
<sabdfl> one for the default, and one for ubuntu-desktop
<Kamion> which is the other warning?
<sabdfl> say they sub epiph and firefox
<jdub> i'd kinda prefer an upgrade helper sort of thing
<jdub> sabdfl: or worse fam/gamin, esound/polypaudio
<sabdfl> sure, but we used a metapackage as a stopgap for that
<sabdfl> jdub: yes
<Kamion> hm, well, it's silly to have me in the position of advocating this, I'll let mdz do it :)
<sabdfl> a metapackage is nice because BLAM the system comes into compliance
* jdub wasn't entirely sure why we went for metapackage instead of sticking with tasks
<sivang> seb128 : could you tell me tha package name? seeds are menifested in a group of pkgs, if I recall right..
<sabdfl> i'm just asking questions, i could well be clueless here :-)
<mdz> sabdfl: what's the second warning?
<Kamion> not installing by default is certainly easy IF we decide to go that way. I have no opinion really :)
<sabdfl> one when they remove the conflicting package, one because ubuntu-desktop will have to be removed too
<mdz> jdub: so that users who upgrade receive new packages we add to the seeds
<jdub> mdz: we could do that with aptitude install "~tubuntu-desktop", too
<mdz> jdub: which you would know if you read ubuntu-devel :-P
<mdz> jdub: the point is that it happens automatically
<sabdfl> i think an upgrade assistant for warty->hoary could be more subtle than a metapackage
<jdub> mdz: well, i read that, but wasn't convinced
<Kamion> hm, http://www.markshuttleworth.com/bounty.html is 403?
<mdz> jdub: and is automatically turned off if they remove one of the packages we install
<sabdfl> kamion: ran out of cash
<seb128> sivang: what do you want to install exactly ? aptitude install "~tubuntu-desktop" ?
<sabdfl> kthnxbye
<sabdfl> :-)
* Kamion grins
<mdz> jdub: you should probably have followed up to the list, then
<sabdfl> process of moving to ubuntu bounties page
<elmo_> somewhere there's a very rich jelly bean making company ...
<jdub> haha
<mdz> elmo_: and dentists
<Kamion> sabdfl: mmmkay, a friend asked me about it
<mdz> or perhaps the dentists OWN the jellybean company...
<jdub> elmo_: we should convince the jelly belly company to make jelly belly SCHNAAAAKEs
* Kamion tries not to laugh too loudly as he has somebody else sleeping in this room
<sabdfl> Kamion: should be back now, stooopid permissions problem
<Kamion> cool, ta
<sivang> mdz : what is the dead line for the webpage in hours from now? (I'm bad at translating UTC times)
<sivang> :)
<mdz> sivang: as soon as possible
<nasdaq4088> i just had an idea: why not allow companies to post bounties on ubuntu's web site for development of the os?
<sabdfl> nasdaq4088: willdo :-)
<sivang> is ubuntu.com up already?
<mdz> yes
<sivang> archive is not letting me install too much :)
<sivang> 0% [Connecting to archive.ubuntu.com] 
<sivang> and stays there
<Kamion> sivang: it'll be up and down for a while apparently
<sivang> Kamion : ok. I'll continue to hope :)
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 13 RC bugs to go
<Kamion> (upgraded #2136, will fix tomorrow, bed now)
<thom> mdz: ack
<thom> mdz: actually, please mail. going to bed now
<mdz> thom: was just the "data center falling into the ocean" thing
<thom> ah, right
<sivang> still down
<mdz> sivang: <Kamion> sivang: it'll be up and down for a while apparently
* lamont points at people.ubuntu.com/~lamont/testing/warty.iso and looks for people with bandwidth to test the LiveCD.
<sivang> jdub : sent the html page?
<sivang> anyone of the native english speaker, how do you refer to the life saver thingy that yelp is executed by clicking on?
<mdz> life preserver, or life saver
<sivang> mdz : tnx :)
<sivang> i think there some bug with firefox, I just tried to save a web page locally - the gui presents the same icon for new dir and up one level
<sivang> anyone seen that?
<jdub> sivang: having network issues atm; if you have suggested content for it, send it over - i'll get it eventually
<sivang> jdub : ok, no prob. I myself had a horroble DNS failure problem....:)
<daniels> Kamion: with the acx, you need to explicitly set key off before it will associate
<daniels> Kamion: you may also need to set a nickname before it will send data down (it will associate but not do data, e.g. dhcp -- bong)
<bob2> daniels: did your wireless Just Work, btw/
<bob2> ?
<daniels> bob2: the Atheros? once out of the installer, yeah
<bob2> ah, cool.
<daniels> yes siree, this laptop is all about Just Working
<lamont> few more minutes and I can go fetch my (hopefully good) liveCD attempt
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 11 RC bugs to go
<m_tthew> lamont: it tanked on me, unable to mount rootfs, I am getting a log for you now
<lamont> thanks
<lamont> I think
<m_tthew> sorry to bear bad news :)
<lamont> exactly
<lamont> OTOH, once I have the image on the local machine, the rsync's should go faster... :-)
<m_tthew> :)
<lamont> hrm. no doko around
* lamont bbiab - fetching a CD.
<bob2> hm, .au isn't the canonical bandwidth ghetto anymore
<daniels> heh
<jdub> just canberra
<bob2> I have dsl now, foo'
<daniels> yes, but all you can access is news about the Melbourne Olympics :P
<m_tthew> lamont: I know this is suboptimal, but I am a fool who does not know how to get grub to talk to the serial port:
<m_tthew> lamont: http://www.ice-nine.org/matt/tmp/warty-livecd-2004-10-11-lamont1.png
<bob2> daniels: that dawn fraser chick, whew!
<Mithrandir> meow
<sivang> jdub : apart from the web page which must be completed today, the reworking of gnome manual is dued by the 18th ?
<daniels> ROCK!
<bob2> 'n'
<doko> lamont: morning
<daniels> can everyone please try gnome-volume-manager from http://people.ubuntu.com/~daniels/g-v-m/ with cameras?
<daniels> it should now work with both crazy-proprietary and usb mass storage cameras
<daniels> and with USB MS, it should just pop up to the right folder automatically
<lamont> doko: remind me what I need to change to make gcc-3.3 build libgcc1 again?
<doko> huh, why that?
<lamont> bootstrapping something
<lamont> from the "go back to where you first got the job" school of bootstrapping... :-)
<doko> on which architecture?
<lamont> m_tthew: hrm... seemed to boot OK for me... Now to see which disk its on...
<lamont> heh.  My login works -> booted from real root.
<lamont> m_tthew: well, that's more consistant anyway.  sigh.
<lamont> time to track down alex
<daniels> if anyone wants to test g-v-m, you'll need to killall gnome-volume-manager && gnome-volume-manager, fwiw
<doko> daniels: the only mass storage device I have is a usb stick ...
<m_tthew> lamont: let me know if there is anything I can do
<daniels> doko: you can simulate a camera pretty easily ;) mkdir -p /media/sda1/dcim/100g-v-m, and put some jpegs in there
<daniels> i'd like to get testing with both usb mass storage cameras (of which I've tested two) and non-mass-storage cameras
<sivang> jdub : send to jdub AT perkypents.org 
<daniels> perkypents, or perkypants? :)
<sivang> daniels : does it really matter ? :)
<sivang> daniels : you happen to do something with Ubuntu's hdparm support? who has it anyways?
<daniels> sivang: it probably matters who you mail it to, yeah ...
<daniels> sivang: for laptops, Thom has the acpi-support package
<lamont> doko: ia64
<lamont> m_tthew: unless you can cause alex to appear, not much.
<lamont> OTOH, with the ISO here, I can rsync happier...
<sivang> daniels : i am not sure what sort of problem this is, but although I have throughly drilled through hdparm and checked everything, Ubuntu on my 8200 inspiron frequnetly comes to a complete halt, performance wise. fauly hardware?
<daniels> sivang: no idea, sorry
<sivang> i sent to perkypants
<sivang> ok)
<doko> lamont: build logs anywhere?
<sivang> nighters everybody
<lamont> doko: well, the gcc-3.4 build I have times out in 'Running chapter c9' of the acats tests (I guess disabling the tests would be a good start...)
<doko> definitely better than downgrading libgcc1. I don't know how the kernel on debian's buildd is configured, so that it doesn't time out.
<lamont> debian buildd is running 2.4.25-dsa, my ia64 box is running 2.4.19...
<lamont> and in sarge of jun 28.
<lamont> er, sid, that is
<lamont> maybe I'll just get a reasonably current kernel on my machine, eh?
<doko> lamont: worth a try, however sent a patch for you
<lamont> doko: cool.  Rebooting now
<lamont> and crossing digits, since I don't want to have to go hook up a monitor to the beast...
<fabbione> morning guys
<daniels> fabbione: hey dude
<fabbione> hey daniels
<fabbione> i feel like shit today
<daniels> oh?
<fabbione> i think i have a bit of fever
<fabbione> or something like that
<lamont> doko: at the risk of sounding stupid... I just drop that file into debian/patches?
<doko> and add it to debian/rules.patch.
<doko> (however the patch is untested)
<lamont> right
<daniels> mdz: ping
<daniels> fabbione: ping
* daniels glares at mdz's connection.
<lamont> make: *** No rule to make target `stamps/02-patch-stamp-disable-gnat-testsuite.d
<lamont> hrm.  clearlly missing something here..
<doko> lamont: in debian/rules.patch: debian_patches += disable-gnat-testsuite (without .dpatch)
<lamont> doh
<fabbione> Unpacking replacement ssh ...
<fabbione> dpkg: error processing /mirrors/debian.org/pool/main/o/openssh/ssh_3.8.1p1-8.sarge.1_i386.deb (--unpack):
<fabbione>  trying to overwrite `/usr/bin/ssh', which is also in package openssh-client
<fabbione> dpkg-deb: subprocess paste killed by signal (Broken pipe)
<fabbione> Kamion: i guess that's a known problem
<hornbeck> jdub: I have the file that sivang worked with, would you like me to message it
<hornbeck> fix the spelling?
* lamont heads to bed
* lamont will be working .au tz tomorrow, btw.
<daniels> lamont: good plan
<daniels> except for the fact that none of the Australians are working .au TZ ;)
<jdub> i am
<hornbeck> jdub: you are fixing it?
<jdub> i am running on .au tz
<jdub> what am i fixing?
<hornbeck> jdub: sivang sent you a file?
<hornbeck> I have a currected version of it, would you like me to send it to you?
<hornbeck> corrected
<jdub> ok
<jdub> thanks
<hornbeck> what address do you want it at?
<jdub> jeff.waugh@canonical.com  please
<hornbeck> on its way
<hornbeck> night
<pitti> Morning!
<Kamion> sivang: in British English we'd call it a "lifebelt"
<Kamion> daniels: ugh, BONG. shame there's no wireless-tools in the installer, eh?
<Kamion> fabbione: that's a downgrade, dude => not supported
<Kamion> hey, there *is* a wireless-tools-udeb, mind
<Kamion> maybe I do have it after all
<sivang> Kamion : Now this is a delayed response ;-) They are usually so good coming from you - not to believe I asked it before I went to sleep ..:)
<Kamion> sivang: you asked it after I went to sleep, more to the point
<Kamion> 01:31 < sivang> anyone of the native english speaker, how do you refer to the life saver thingy that yelp is executed by clicking on?
<Kamion> 00:33 < Kamion> (upgraded #2136, will fix tomorrow, bed now)
<sivang> right :-) Well, I usually turn off the machine so I don't get the pleasure of what's going on after I fall asleep.
<sivang> Kamion : too bad the home page offline version is already sent to jdub, and I don't have the sources here..
<sabdfl> morning all
<sivang> morning sabdfl 
<sivang> Kamion : interesting you refer to it as a "belt". In hebrew it's something like a "life saving wheel"
<sivang> Kamion : hebrew is strange, however when I think of lifebelt, somehow I get the picture of something elastic , rather than firm and solid like the lifebelt
<Kamion> sivang: "life preserver" will be understood
<sivang> Kamion : I'll modify it - good there are USB sticks, and someone who made them work well in Ubuntu 
<Kamion> daniels: still can't get it to associate as far as I can tell, though :(
<daniels> Kamion: hmmm, what variant of acx100? i had to go through a couple of drivers using ndiswrapper
<daniels> well, for acx111
<sabdfl> (08:48:55) mdz: tech board meeting is going to be very fast unless you have something to bring up
<sabdfl> (08:49:22) mdz: "release tomorrow lots to do kthxbye"
<sabdfl> (08:53:13) sabdfl: i think the schedule is actually community council meeting this week
<sabdfl> (08:53:39) sabdfl: was going to invite tech board to participate and have you sign off on the release process with the cc
<sabdfl> (08:53:42) sabdfl: sound ok?
<sabdfl> (08:53:52) sabdfl: will have a release process drafted for the meeting
<Kamion> daniels: um. how do I tell? :)
<daniels> Kamion: whatever it says on the box
<sabdfl> Kamion: would today's daily have the lspci update for my test ipw2200 card?
<Kamion> daniels: it's a US Robotics card, not much in the way of labelling
<Kamion> sabdfl: probably not, since discover1-data is in the initrd
<Kamion> unless elmo's up VERY early
<daniels> Kamion: ah. when you do lspci, is it acx100, or acx111?
<Kamion> rebooting now to check
<sivang> sabdfl : when is the CC meeting scheduled?
<sabdfl> 1600 UTC
<sivang> sabdfl : uhm..today ? :)
<sabdfl> yes
<sabdfl> every tuesday we have a tech board or cc meeting
<sabdfl> unless we don't :-)
<sivang> you had last tuesday?
<sivang> oh :-)
<sivang> and TB?
<Kamion> did we have a tech board meeting last week? I think I missed it
<sivang> Kamion : I revised , and resent. thanks for the english know how :)
<mdz> I thought CC was last week and TB was this week
<mdz> but the email is out now, so CC it is :-)
<sivang> I propuse to write down dates and time on the CC wiki page, just o avoid confusion :)
<Kamion> sivang: I did say "British English"; mdz is a more reliable speaker of American English than I am
<Kamion> two countries separated by a common language, and all that
<mdz> two countries separated by the atlantic ocean...
<sivang> Kamio : yep, I now recalled he also told me about the "life preserver"
<mdz> to my credit, I provided both alternatives
<sivang> mdz : yes you did ;-)
<Kamion> mdz: neither of which I'd use in British :)
<mdz> Kamion: what do you call them?
<Kamion> mdz: "lifebelt"
<daniels> lifejacket
* mdz rolls his eyes
<mdz> daniels: then what do you call a life jacket?
<Kamion> daniels: "Texas Instruments ACX 100 22Mbps Wireless Interface", 104c:8400
<Kamion> daniels: it so isn't a jacket :)
<sivang> lifejacke is again, somethign elastic, extendable to fit person's size
<daniels> you guys are talking about a seatbelt?
<Kamion> no, an inflatable ring
<daniels> oh
<sivang> the wheel is stiff 
<mdz> not inflatable, but buoyant
<daniels> you mean, an inflatable ring :)
<sivang> hahah
* sivang enjoys the english insights he absorbs here
<sivang> buoyant = stiff ?
<daniels> buoyant = floats
<sivang> oh
<sivang> I don't even want to try imagine how you pronounce that 
<sivang> :)
<daniels> boy-unt
<mdz> ok, time to sleep before CC meeting, good night
<sivang> sabdfl : is it late now to add stuff to the agenda?
<pitti> Morning seb128!
<sabdfl> sivang: go ahead, i might move them to the next meeting or handle them today
<sivang> mdz : night
<pitti> mdz: good night
<sivang> sabdfl : ok, tnx
<daniels> Kamion: ah, acx100 ... hm, unsure.  but you might need to give ndiswrapper a shot; i never had much luck with that driver.
<seb128> hello
<Kamion> mdz: commented on #2284 in reply to you
<sabdfl> night mdz
<Kamion> daniels: ah well, ignoring then since I have no plans to make ndiswrapper work in d-i
<sabdfl> Kamion: please ping me as soon as ipw2200 is testable by me
<Kamion> sabdfl: OK, will be later today
<daniels> Kamion: fair enough
<daniels> Kamion: oh, you did do ifconfig interfacename up, right?
<Kamion> daniels: I let netcfg do that
<Kamion> same goes for 'ifup wlan0' outside the installer
<daniels> hm
<daniels> bong.
<Kamion> actually, it does claim to associate
<Kamion> it just doesn't DHCP
<daniels> hm
<pitti> Hi mvo! Nice to see you again!
<sivang> mdz : I understand that today's is final date for submission of docs and others - as tommorow is RC. And after RC there would be no more changes allowed right? (except for security patches, and act of gods)
<sivang> or acts of gods :)
<mvo> hi pitti. I'm back from university land :)
<fabbione> Kamion: that was updating sid ;)
* fabbione still feels like shit today
<sivang> fabbione : what's wrong?
<fabbione> sivang: a lot of headacke and a bit of fever
<Kamion> fabbione: you must have had openssh-client installed from experimental, then
<fabbione> i just woke up but i am going to lay in bed soon again
<Kamion> (or warty)
<Kamion> fabbione: openssh-client has never been in sid
<fabbione> Kamion: yes. experimental 
<Kamion> well then, not supported :)
<fabbione> ehhehe
<sivang> fabbione : oh, I've known those too well by now - still not over my dizziness, the last remains of my latest virus catch. :)
<Kamion> fabbione: (if you're going to use openssh-client from experimental, use ssh from experimental as well)
<fabbione> Kamion: yup i did a "dist upgrade" but it didn't pull in ssh or openssh-server.
<fabbione> Kamion: but later i did a mess myself.. reasonf of the informal message here ;)
<fabbione> rburton: instead of opening a new bug, please reopen the old one ;)
<rburton> fabbione: i tried, but couldn't find it :(  i'll duplicate/reopen if you can tell me the number...
<fabbione> rburton: how was to reproduce the problem?
<fabbione> left alt + ?
<fabbione> i can never remember these things
<rburton> fabbione: windows key + arrows, i've configured metacity to use super for keyboard shortcuts
<fabbione> rburton: there is also a metacity update
<rburton> ah ok
<fabbione> are you sure metacity didn't fry your settings?
<rburton> that shouldn't have broken it
<fabbione> just asking for info ;)
<rburton> yeah, if it reset the settings then super would do nothing
<fabbione> the SUper is the RWIN or LWIN?
<rburton> both i believe, but i use left
<fabbione> daniels: i saw that patch and i think we can stick it in X
<rburton> hm, rwin is compose for me atm
<rburton> handy, but i wasn't expecting that ;)
<rburton> oh, i set it last week.
<fabbione> if i push rwin it always pushes to the first desktop :-)
<daniels> fabbione: cool.  have you got any other pending changes, or should I just upload with this?
<fabbione> daniels: there might be a regression.. 2288
<fabbione> daniels: if you want to take care of it before uploading
<Kamion> bugger, I need to change rootskel
<rburton> fabbione: my /apps/metacity/global_keybindings/switch_to_workspace_down (etc) gconf keys are "<Mod4>Down" etc
<daniels> fabbione: ok
<fabbione> daniels, rburton: hold on
<Kamion> review of https://bugzilla.ubuntu.com/attachment.cgi?id=436 please?
<Kamion> (works for me in tests)
<thom> morning
<fabbione> rburton: which layout do you use?
<rburton> fabbione: gb
<fabbione> daniels: i leave it up to.. i add Denis in CC, but i am off.. too much headacke
<daniels> ok
<fabbione> rburton: try to check the changelog and see if there is anything that can tickle your brain
<daniels> morning
<fabbione> rburton: as root of the regression
<rburton> k
<fabbione> later.. or tomorrow guys
<fabbione> sorry but i am not too useful today
<sivang> laterz fabbione, get well soon!
<thom> take care mate
<rburton> i can't see anything obvious, unless the port from trunk had extra changes
<daniels> fabbione: hope it all sorts itself out soon
<sabdfl> Kamion: think we can build canidates for RC1 today? then get feedback so MDZ and Tech Board can sign off on it this evening?
<sabdfl> mirror tonight, then announce tomorrow am?
<daniels> Kamion: so how long do I have to upload XFree86? :)
<Kamion> sabdfl: it's going to be waiting on a d-i initrd rebuild, and I haven't got approval for the rootskel change that predates it yet, so I still don't know
<Kamion> daniels: ASAP please, dunno exactly
<daniels> Kamion: yeah, I'll hopefully clear it in the next 30min
<Kamion> sabdfl: I really needed to know about this plan yesterday
<sabdfl> rootskel? /etc/default/skel?
<Kamion> no, rootskel, equivalent of base-files for d-i
<sabdfl> Kamion: plan isn't set, tell me what you want
<sabdfl> i'm drafting a plan right now, thumbsucking for bits of it, open to your guidance
<Kamion> I was expecting to have tomorrow's daily be RC1 and to have a round of testing tomorrow morning before release
<Kamion> I'll need to have lamont kick off a manual d-i rebuild today before that though
<Kamion> or maybe just upload debian-installer again, since I'll probably need to update disk space estimates again
<Kamion> there's also #1232 with a load of d-i translation updates pending
<rburton> is there an archive of old packages available? i need metacity from last week
<seb128> grrr, my connection went down for 2 hours again
<mjg59> The logo on bugzilla still has nasty compression artifacts
<rburton> ewwww
<rburton> nearly as bad as the default XP wallpaper
<elmo_> who did the last linux-source upload?
<mjg59> Oh, are we supporting NTFS resizing?
<pitti> seb128: welcome back :-)
<pitti> seb128: need IP tunneling over letter doves?
<seb128> need a good isp
<thom> elmo_: herbert did
<elmo_> thom: duh, i wanted someone I could harass on IRC :p
<thom> heh
<thom> blame Mithrandir 
<Kamion> elmo_: oh, I meant to harass mdz about that last night
<Kamion> mjg59: not in the installer, yet
<Kamion> mjg59: it's in Debian but it was a very late change for us and too scary
<mjg59> But resizable FAT?
<Kamion> uh, if parted can do it?
<Kamion> I haven't checked, I must confess
<mjg59> Parted can do it, yeah
<Kamion> should Just Work then
* Kamion is still looking for review of https://bugzilla.ubuntu.com/attachment.cgi?id=436 for upload
<daniels> Kamion: looks good to me
<Kamion> thanks
<Kamion> (powerpc is not mentioned in that patch because get_arch_kernel always returns a kernel on the CD there)
<thom> can someone review http://people.ubuntu.com/~thom/thunderbird-dexul.diff please
<thom> fix for https://bugzilla.ubuntu.com/show_bug.cgi?id=1933
<daniels> thom: i can't see any obvious problems, but don't know enough about it (don't even use it) to properly review, sorry
<Kamion> bit of a scary lack of quoting?
<Kamion> (i.e. find "$PATHLIST")
<Kamion> I'd be inclined to use find -print0 | xargs -0 too but that's maybe just me
<Kamion> still, it looks functionally correct to me
<pitti> thom: I don't understand this: -e 's,Path=/,/,' -e "s,Path=,$HOME/.mozilla-thunderbird/,"
<pitti> thom: first you remove 'Path=', then you substitute it with sth?
<Kamion> might be worth trying out that sed on something that contains no Path= lines at all to make sure it doesn't fall over
<thom> Kamion: it's been in firefox's script since forever
<thom> i'm just transplanting to thunderbird
<Kamion> mmmkay
<pitti> thom: is "s,Path=,$HOME/.mozilla-thunderbird/," ever applied?
<thom> pitti: yes, because in most case the path is relative, not absolute
<thom> ie, Path=ey9ogb7w.default
<pitti> thom: ah, now I understand. This shall filter out absolute paths and only use relative ones.
<thom> the first expression deals with the Path=/home/thom/.mozilla-thunderbird/...
<thom> yeah
<Kamion> pitti: well, it uses both
<daniels> Extracting source xfree86-4.3.0.tar.gz ... 
<daniels> zcat: xfree86-4.3.0.tar.gz: invalid compressed data--crc error
<daniels> zcat: xfree86-4.3.0.tar.gz: invalid compressed data--length error
<daniels> failed!
<daniels> #@$@#$
<pitti> thom: now I've got it. Takes a while...
<pitti> thom: can you please use -print0 for find and -0 for xargs?
<pitti> thom: it's pathetic, I know, but it's not much effort to do it absolutely safe
<thom> (sorry, typing break)
<thom> yeah, will do
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 10 RC bugs to go
<daniels> over half a year on, the fact that all the X macros to do with extensions make the data pointer named 'stuff' still unnerves me
<daniels> the entirety of Xext and other various server-side things to do with extensions deal entirely with pointers named 'stuff'
<daniels> that was what I called the directory full of games and MP3s in year 7 so no-one would find it
<Kamion> MP3s *existed* in your year 7?
* Kamion feels old
<daniels> yeah, and I was using IRC to trade them :)
<daniels> h4x0r3d mIRC into there, got on Undernet channels and then set up our own channel in which we all traded MP3s amongst ourselves on the local LAN
<daniels> it was quite the sophisticated operation
<daniels> wrecked only when the admins started wondering why the size of the year 7 home directories had exploded in the last month
<thom> man, so many of these fricking mozilla-* bugs are broken profiles
<thom> jdub_: can i upload 2280; i've done exactly what seb told me to do ;-)
<seb128> thom: have tyou tested the package to be sure ? Just right click on a html file in nautilus and see if firefox is here
<thom> seb128: yeah
<seb128> ok, cool
<pitti> daniels: will you upload #1292 today?
<mjg59> daniels: Is it worth thinking about making swcursor the default?
<daniels> pitti: yeah
<daniels> pitti: about to do it now
<daniels> mjg59: are there really that many issues?
<pitti> daniels: fine, because I also have to do a g-v-m upload
<daniels> pitti: ah
<seb128> hum, time to lunch, bbl
<mjg59> daniels: I've seen several. Don't we end up using software cursors for the translucency anyway?
<Kamion> can somebody eyeball http://people.ubuntulinux.org/~cjwatson/cdrom-checker.diff for me?
<daniels> hm
<Kamion> without it, cdrom-checker only works in expert mode
<daniels> i think there are a couple of problems with swcursor, also
<Kamion> unfortunately I only noticed today :-/
<daniels> i'm not really happy with doing it this late in the game, also
<Kamion> cdrom-checker isn't on the default installation path so I think raising the priorities must be safe
<daniels> personally, I think the best thing to do is do like savage, where we just blacklist specific cards unless either sw or hw is specified
<pitti> daniels: if you have a minute, can you please take a look at the proposed patch in #2169?
<thom> Kamion: oh, hey. os-prober doesn't seem to find my XP install, but only on the amd64 installer, not the x86 one
<Kamion> thom: ur. forgot to make some amd64->i386 symlinks, I think
<daniels> pitti: bong. unreproducible.
<Kamion> bollocks, ok, will look today
<daniels> (waits for the component selector to load)
<daniels> pitti: looks goo dto me; if it works, i'd say upload
<pitti> daniels: unreproducible? Odd
<pitti> daniels: I get windows for all mounted volumes as soon as I do /etc/init.d/dbus-1 restart
<daniels> yeah, I was looking at the title at the time
<pitti> daniels: BTW, we have to coordinate this; both you and me want to upload ubuntu4 :-)
<daniels> once I read it fully, it was OK :) i thought it was to do with hotplugging, not restarting hal
<daniels> pitti: you asked me to upload g-v-m (sort of implicitly), so I already did :)
<pitti> daniels: okay, then I will change the changelog to ubuntu5 and wait for your version
<daniels> pitti: the accepted message has already gone to warty-changes
<pitti> jdub_: still here? If so, can you please approve #2169? daniels reviewed it, I tested it extensively
<pitti> daniels: oh, didn't read my mail in the last 10 minutes :-)
<daniels> pitt	heh
<lamont> Kamion: I can do the manual run, but it'll add that pesky extra digit to the date...
<Kamion> lamont: let's not worry for now, I have some other changes anyway
<thom> hrm, compiling firefox , thunderbird and apache2 all at once does bad things to machine usability
* thom goes to tidy room or have lunch or something
<lamont> Kamion: cool.  I'll be out for the next several hours, back about 2200 GMT or so.
<lamont> there is a remote chance that I can get online, but I rather doubt it.
<T-Bone> ladude!
<lamont> morning t-bone
* lamont kicks his i2000
<T-Bone> lol
<T-Bone> hey lamont ;)
<lamont> time to haul it outside and take an airhose to it. :-(
<lamont> I don't think I get to do any builds on it this morning, and I need to leave shortly
<T-Bone> lamont: haven't got much time to check what went wrong with those packages lately either, alas
<lamont> it made it about 90 minutes into the gcc-3.4 build for me last night before the machine died.
<lamont> I think it may be time to sync everything from the i2000 to the zx2000 :-)
<T-Bone> hehe
<T-Bone> fortunately i hadn't had such troubles with my gcc build, once i tweaked a bit. But the fact is that some core packages are screwed with that dir.gz file
<lamont> yeah - no clue why that was there...
<lamont> --force-overwrite??
<lamont> or something like that...
<T-Bone> lamont: yeah, i can do that, but i'm afraid that it will be there again during stage 2
<lamont> yeah
<T-Bone> iirc, hppa didn't show that.
<lamont> cool
<T-Bone> (though i couldn't build gcc-3.4 on hppa :( )
<lamont> that reminds me... I need to find a friendly person at ftc to send my dead A500 to ggg
<T-Bone> heh
<lamont> or throw it in the car next month. :-)
<T-Bone> =)
* lamont wonders if we could spit the universe into quadrants, so that the &*^)^ Packages file would be smaller.
<lamont> :-)
<T-Bone> :)
<thom> heh
* thom pokes lamont about pa-risc, kit
<lamont> kit?
<thom> uh, no idea where that comment came from
<thom> feh
<thom> s/comment/comma/
<thom> yeah. the much mentioned pa risc box :-)
<lamont> oh. that.
* lamont goes to change the topic...
<lamont>  [Topic]  + | Airlift of parisc box needed in London - see lamont
<lamont> :-)
<thom> heh
<lamont> of course, I won't be around to see what discussion that stirrs up..
<lamont> anyway, I'm off for several hours.
<T-Bone> lamont: see ya later or tomorrow then
<carlos> What's the multiverse archive?
<pitti> carlos: equivalent no Debian's non-free
<pitti> carlos: unsupported Non-DFSG
<Keybuk> Bug#268886: dpkg: Problem with dutch translation, south-african text appears in it
<Keybuk> heh
<amu> ..ooOOO oh my god, 211 users at #ubuntu 
<thom> my gosh, how can anyone get anything useful done with gui mail clients?
<Kamion> sloooooowly
<Kamion> -"Language-Team:  <debian-l10n-greek@lists.debian.org>\n"
<Kamion> +"Language-Team: Greece\n"
<Kamion> what sort of an entry is that?
<Keybuk> an Olympic one?
<Kamion> and the Greek translator is gratuitously changing translations whose msgid hasn't changed, just so that they'll be more work for me to merge later, as far as I can tell
* Kamion sighs and uploads anyway, it being more work to take the patch apart and reduce it to the minimal subset
<Keybuk> heh, I just generally used to ask translators to provide entire .po files, or nothing
<Keybuk> resolving 3-way diffs when you don't know the language ... is interesting
<Kamion> doko has assembled the tarballs provided by the translations into patches
<Kamion> I'm just applying them
<Kamion> (but yes, I know what you mean, and that's precisely the pain that's going to arrive in force come the Hoary merge)
<Keybuk> tell me about it
<thom> hoary is gonna be no fun for a while i think :/
<Kamion> you misspelled "total nightmare of death"
* Kamion sends a note to #1232 to forestall further pain
<thom> i vote we blame keybuk
<Keybuk> are you using msgmerge to merge the .po files?
<Kamion> me? I'm using patch right now
<Kamion> in general, I'm doing whatever debconf-updatepo does, which involves intltool-debian not gettext as far as I know
<Keybuk> *nods* there's intltool-merge which should do *something* useful
<Keybuk> though I don't think (usefully) that can do po files to po files
* Keybuk has been playing with some "merge the fuckers" recipies
<daniels> Keybuk: finish hct, yesterday
<Kamion> big chunks of d-i are about to become real good tests for you
<Keybuk> daniels: am working as fast as I can :)
<Keybuk> Kamion: once d-i is on arch.ubuntu.com, we can have a play with that
<daniels> are the london buses really called 'root master'??
<Keybuk> daniels: the ones with the spiral stairs at the back are called "Routemaster"
<Kamion> Keybuk: lifeless has had all the details for a while now
<daniels> oh man
<daniels> that is too funny
<Keybuk> every other time I go to London, they've either been put back on the roads due to amazing public opinion
<lifeless> its high on my todo, but we've had some trouble :[
<Keybuk> and the next time all withdrawn again because they're unsafe and impossible for the disabled to use
<rburton> they should all die
<daniels> i like the hop-on, hop-off idea
<daniels> i also like the fact that they're called 'root master'
<rburton> "route"!
<daniels> rburton: dude, if the London bus chief dude wanted to say 'route', he would've said 'route'
<rburton> slam-door trains should also die a slow and painful death
<daniels> but he was quite clearly saying 'root' :)
<rburton> daniels: you, sir, can't speak
<Kamion>  "????????? IP          = $[ipaddress}\n"
<Kamion>  "M???? ???????         = ${netmask}\n"
<Kamion>  "???? ???????          = ${gateway}\n"
<Kamion> -"Point-to-Point        = {pointtopoint}\n"
<Kamion> +"Point-to-Point        = ${pointtopoint}\n"
<Kamion> geez, either fix it all or don't fix any of it
<Keybuk> rburton: what's wrong with slam-doors ?!
<Keybuk> they hardly *ever* break down, unlike the new things that replaced them
<rburton> HAHAHA
<Keybuk> they have ample leg and seat room, unlike the new things that replaced them
<thom> Keybuk: you funny
<rburton> you clearly don't use them often
<Keybuk> and, more importantly, you can't door-surf on the new trains
<Keybuk> rburton: used to every day
<rburton> Keybuk: the new new ones are really nice, but only a few routes in the south east have them
<daniels> ... door-surf?
<Keybuk> daniels: "slam-door" trains just have ordinary doors
<Keybuk> with no locks
<rburton> as long as you have really bendy arms
<rburton> Keybuk: they are often very cold in winter though
<Keybuk> the deterrant to stop you opening them at full-speed is that you have to stick your hand out of the window to open them (the handle is on the outside)
<Keybuk> but you can have fun
<Keybuk> as you come into a station, open the door, and swing out on it
<Keybuk> so the door's at 90 to the train, and you ride on the door
<rburton> Keybuk: for fun, some trains have catches on the inside
<Keybuk> it's also fun if people aren't "standing behind the yellow line"
<Keybuk> because they get a door in their face
<Keybuk> :p
<rburton> s/face/body/
<Keybuk> rburton: yeah, the Waterloo line ones did, didn't they?
<daniels> Keybuk: haha
<rburton> Keybuk: i'd say half of the trains from london bridge have inside handles
<daniels> your trains are so very quaint
* Keybuk likes slam door trains
<daniels> have you considered a real PT system some day? :)
<rburton> daniels: slam door trains are a relic, and being replaced
<Keybuk> interestingly, did you know that no model railway company makes them in OO guage?
<daniels> rburton: that's a start ...
<Keybuk> rburton: we still need a real PT system though
<rburton> bah
<daniels> pitti: please see the new comments on #1292
<daniels> any PT system that includes something called a 'rootmaster' is alright by me, though :)
* Keybuk roots daniels
<Kamion> $ filterdiff -i \*/partman-md-\* lang-updates1.diff | patch -p7 -d ~/src/ubuntu/partman-md/partman-md-11ubuntu1
<Kamion> how did people ever get by without patchutils?
<pitti> daniels: odd, this works fine for me without any reconfiguration
<daniels> Keybuk: i'm so finding a new roommate for Spain
<daniels> pitti: i think his problem is that he's missing the %h
<Keybuk> lol
<thom> Kamion: how did we leave it out of main for so long?
<Keybuk> Kamion: ediff, man!
<Kamion> that would imply the Dark Side
<pitti> daniels: probably. maybe the wrapper script should check that $1 is nonempty
<Kamion> not to mention not using a shell
<daniels> pitti: yeah, don't think it's hugely important for warty, though
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu development -- general discussion on #ubuntu | 11 RC bugs to go
<Kamion> help with #1971 appreciated ...
<daniels> Kamion: i'd want dmesg
<Kamion> daniels: so would I, but it's kinda hard without a keyboard
<daniels> yeah
<daniels> without more info, it's really hard
<sabdfl> elmo: could you thom me the private key for 01.pem please?
* thom sulks
<T-Gone> bbi2h
<thom> verbing that is totally unfair :-)
<sabdfl> :-)
<daniels> i think we should verb that for any accidental disclosure of any form
<sabdfl> *legend*ary
<daniels> as in, 'whoops, I just thommed that to #ubuntu'
<sabdfl> guys, i'm very excited for this release!
<daniels> i'm excited about the release process
<daniels> the longer we stay in it, the longer we get to avoid syncing hoary :)
<thom> daniels: you're just not used to having a release process, kde boy
<daniels> i wonder how much bandwidth we'll burn through, given the phenomenonal interest with the preivew
<sabdfl> i think we should delay syncing hoary, take a break and set hoary feature goals and priorities, then come back to the packaging
<sabdfl> hopefully with some tools to make it a bit easier
<daniels> my biggest fear is that we come back to some painful upstream version drift, so it's not just reapplying patches
<Kamion> I'm worried about spending too long *without* syncing hoary, personally
<daniels> but I don't think GNOME will be a problem ;) and it looks like that would be the biggest pain
<Kamion> I think we need to get started on that ASAP
<Kamion> certainly we'll be spending a while on support ...
<daniels> we already have the most up-to-date GNOME, and once we get X out of the way ... my god, there are two massive sync nightmares gone
<Kamion> d-i
<daniels> yeah, that looks painful
<sabdfl> hmm... new kernel gives a weird menu.lst:
<sabdfl> title           Ubuntu, kernel 2.6.8.1-3-686.dpkg-tmp
<sabdfl> root            (hd0,0)
<sabdfl> kernel          /boot/vmlinuz-2.6.8.1-3-686.dpkg-tmp root=/dev/hda1 ro quiet splash
<sabdfl> savedefault
<sabdfl> boot
<sabdfl> ?
<Kamion> update-grub called at wrong time? dunno ...
* daniels stares at The Age -- 'Inside were a bodyboard and the plastic bag of cannabis, which measured about one metre by acme and was packaged in a vacuum-sealed Space bag.'
<elmo> yeah, I saw that at the DC, it seems to run update-grub twice - once when the .dpkg-tmp file is still there
<daniels> that's not mertic :)
<daniels> metric, either
<sabdfl> elmo: yes, it passes. interesting
<daniels> seb128: ping -- please see #1292 wrt changing preferences
<seb128> pong, ok
<daniels> thanks dude
* daniels -> bed
<seb128> 'night daniels 
<thom> night dude
<daniels> spam with a subject of ' %Please *contact m+e'
<daniels> it's like running ls in an arch dir :P
<daniels> sorry, 2534     Oct 12 Mary Jessi      (   0) % Pls ^contact *me+
<pitti> Yeah, my network is back
<Kamion> fabbione: have fun with #2299 :-/
<Kamion> thom: mozilla-firefox-locale-{es,gl} are uninstallable, if you hadn't noticed
<thom> Kamion: yeah
* Kamion desperately attempts to keep up with Herbert's kernel builds
<elmo> hmm, anyone know a good way to get the URLs of a given website? like determine the site-map from the outside
<Kamion> google?
<elmo> eh? google?
<Kamion> google some-common-term site:whatever
<Kamion> it's about the best you're going to do in general, I'd imagine
<elmo> oh, I was more thinking wget -r or linkchecker or something - but I guess google'd work 
<Kamion> does the site publish directory listings?
<Kamion> I suppose you could run a spider over it if it's fully linked
<Kamion> sorry, I'm probably thinking in slightly too general terms
<seb128> elmo: apparently jbailey has uploaded ximian-connector 2.0 in debian several time but not trace of the upload ... any idea of what's happening ?
* Kamion doesn't see any trace of it on newraff ...
<elmo> seb128: what kamion said - it's not in any of katie's log files
<seb128> weird
<seb128> <jbailey> Yes, same as I upload my other packages.
<seb128> <jbailey> No idea why this one hasn't worked despite being uploaded twice.
<elmo> Oct  8 14:46:44 ximian-connector_2.0.1-1_i386.changes isn't signed with PGP/GnuPG
<elmo> Oct  8 14:46:44 Removing ximian-connector_2.0.1-1_i386.changes, but keeping its associated files for now.
<seb128> oh, Jeff probably got the mails
<seb128> the uploader get nothing in this case ...
<seb128> s/Jeff/jdub/
<seb128> elmo: thanks
<sabdfl> ANNOUNCEMENT: Community Council meeting in #ubuntu-meeting in 2 minutes
<mdz> pitti: are you here?
<pitti> mdz: yes
<mdz> pitti: could you look at #957?
<pitti> mdz: sure
<mdz> pitti: I'm sure there's a simple fix once the right code is located, and it'd be very nice to get rid of that dialog for the RC
<pitti> mdz: I will look after this
<pitti> mdz: by now we just disable the dialog, not the cause, right?
<mdz> pitti: correct, just stop displaying it
<mdz> pitti: thanks
<mdz> pitti: hopefully you can reproduce it; it doesn't happen on my desktop
<pitti> mdz: I can, it happens every time on my iBook
<carlos> thom: http://nave.hispalinux.es/productos/firefox/1.0/descargas/firefox-1.0-es-ES.xpi
<thom> dude, 0.9
<carlos> thom: is it what you need?
<thom> but ok
<thom> i can dig on that
<thom> carlos: thanks
<carlos> thom: seems like there isn't a 0.9 release
<thom> yeah, that's exactly the problem :(
<thom> 1.0 is too different
<carlos> thom: I think there was an es-AR translation for 0.9, but I don't know the quality of it, but it's better than nothing...
<pitti> seb128, mdz: I have a fix and patched package for #957 ready, it is building
<pitti> seb128: Hi, welcome back
<pitti> seb128: mdz asked me to fix #957, since it is kind of urgent and you were absent
* thom tests current netboot
<seb128> pitti: was testing the news GNOME 2.8.1 packages, so restarting my GNOME and since I use xchat ...
<seb128> pitti: thanks for working on this one, I've not real idea of what /dev/pmu is and not box to test
<pitti> seb128: oh, no problem. I've got a powerpc and /dev/pmu is the analogon to apm on i386
<carlos> seb128: think on it like some kind of /dev/apm (not exactly, but you get the idea...)
<seb128> oh ok
<pitti> seb128: right now I don't fix the cause, I just suppress the dialog
<pitti> seb128: but for Hoary I can work on it as well
<pitti> seb128: to find the right solution :-)
<elmo> Kamion: am i giving this 19 image any special symlink name? ('rc' ?
<Kamion> 19 image?
<elmo> the d-i upload you just did
<thom> pitti: we know the right solution - make gnome use libpbbuttonsd
<Kamion> oh, that; yes, rc
<Kamion> um, maybe wait until it definitely works though :)
<thom> pitti: but that's a big chunky change
<pitti> thom: I meant a "little better" solution
<elmo> can I trash preview and older images yet, or now?
<pitti> thom: I only glanced at the code (I just wanted to get rid of the dialog), but it seemed to me that there is some odd logic
<Kamion> elmo: 15 and 16 can go, best keep the preview for now
<elmo> k
<thom> pitti: i can well believe that
<pitti> thom: anyway, Hoary stuff. Let's get this out of the door with as little patching as possible
<thom> fuck yes.
<carlos> pitti: I was thinking on a patch to use DBUS instead of polling with pbbuttons
<pitti> carlos: sounds much saner :-) 
<elmo> the amount of changes today has been insane(ly scarey)
<pitti> carlos: either way, the user space stuff must not touch /dev/pmu any more in Hoary
<pitti> yeah, package build finished
<thom> that means turning off pbbuttonsd and moving all the acpi/power management stuff to a dbus service
<carlos> thom: ?
<thom> which'd be cool, but a but a metric assload of work :-)
* Kamion switches cdimage from daily-installer-* back to installer-* in preparation
<thom> carlos: if you want to talk to pmu, you can't concurrently access it. it's not safe
<carlos> thom: that step it's too big to be done in 6 months
<carlos> thom: pbbuttonsd have a library to communicate from a normal user application with the daemon
<carlos> thom: I was talking about improve it with dbus
<thom> *rolls eyes* dbus isn't magic pixie dust
<carlos> thom: the right thing, IMHO could be to have a power management service like you said that works on any architecture, instead of pmud/pbbuttonsd, apmd/acpid
<carlos> but that's not possible in 6 months (without a dedicated work on it)
<Kamion> it's also not an Ubuntu-go-it-ALONE thing
<thom> right. so why waste time working on pbbuttonsd? make gnome work properly via pbbuttonsd, then when we have common infrastructure we can make gnome use that
<thom> Kamion: agree 100%
<carlos> thom: it's another option
<pitti> mdz: can you please approve the patch in #957? Builds and works correctly
<carlos> Kamion: I was not suggesting to do it only for ubuntu
<thom> which is more work and a, imo, a pointless fork in the road for something we're going to ditch when we have the correct infrastructure
<Kamion> pitti: I'd comment out the char *msg; too to avoid compilation warnings
<carlos> thom: well, if the dbus patch is done, it could be sent to pbbuttonsd :-)
<carlos> btw, don't worry about it now, it's a hoary thing so we should not care until next week :-)
<pitti> Kamion: oh, right
<Kamion> sabdfl: don't you want to call the image "install-i386.iso"? I thought we'd agreed that earlier
<sabdfl> yes
<sabdfl> maybe warty-install-i386.iso
<sabdfl> matching warty-livecd-i386.iso
<thom> i think we should have warty in the name, yeah
<Kamion> warty-live-i386.iso
<Kamion> OK
* Kamion hacks publish-daily
<thom> bah
<thom> i keep seeing posts on the 1.0PR crasher upstream report and getting excited, and it's only people adding themselves to the cc
<thom> WHY does bugzilla feel I care about this?
<sivang> is 
<justdave> seb128: you have upstream
<sivang> *.ubuntu.com down again?
<Kamion> sivang: works for me.
<amU> people are confused if theres only a name you should add also a number ;) image there are 5 different iso for downloading, a new user dont know which he must take ... he knows 2 is smaller than 1  
<seb128> justdave: thanks :)
<thom> sivang: um, no.
<mdz> pitti: go ahead
<Kamion> amU: don't understand?
<pitti> mdz: okay. I additionally commented out the char* declaration to avoid compiler errors
<mdz> pitti: s/errors/warnings/ ?
<pitti> mdz: not errors, warnings
<pitti> mdz: yes, sorry
<amU> Kamion: ;) ask your mother:  warty-install-i386.iso woody-install-i386.iso sarge-install-i386.iso, which of the 3 isos is newer. ask again, 1.iso 2.iso 3.iso .... which of the 3 isos is newer      
<Kamion> er, those three are not sanely comparable
<Kamion> the place for documentation is on the web site
<elmo> err, are these mozilla-locale's going on the CD?
<amU> Kamion: well, a small trick with versioning and all questions are answered, sure you can tell to them click there and later to there, dont forget 95% of the users are beginners, those other 5% follow your link         
<Kamion> amU: we already have /releases/4.10/preview/ etc.
<mdz> elmo: not unless someone added them to shipseed while I wasn't looking
<elmo> ok, cool
<amU> Kamion: than you should write also additionally the version. ( on the web )  
<Kamion> amU: this is not number one on our list of concerns just now :)
<Kamion> amU: I believe, however, that the version number is already on the web
<amU> Kamion: right it is, guess i missunderstand y 
<elmo> so, if we want to do the additional machine things - how do we want to do this - round robin DNS cdimage, change cdimage DNS, or just as a special one off website we point people to in the announcement?
<Kamion> seb128: did you notice the evolution-data-server build failure?
<seb128> on which arch ?
<Kamion> amd64
<seb128> no, thanks
<seb128> looking
<seb128> hum
<seb128> Mithrandir: here ?
<mdz> elmo: so about #2211...
<mdz> fabbione: is #2288 better than the bugs which were fixed by those xkb changes?
<sivang> something broke with epiphany install,
<sivang> it doesn't show up in the menu panel
<sivang> and can't be xecuted.
<Kamion> mdz: #1290> what fix? :)
<Kamion> mdz: the syslinux timeout has been like that since long before Ubuntu ever existed; that's what I don't understand about that bug
<mdz> Kamion: really?
<Kamion>     - set the syslinux timeout to 0 on floppys, to match the CD
<Kamion>  -- Joey Hess <joeyh@debian.org>  Mon, 23 Feb 2004 20:46:31 -0500
<mdz> Kamion: reopened
<Kamion> seb128: when will the last GNOME 2.8.1 tarballs show up?
<seb128> no idea
<mdz> seb128: if they're going in, we need them _now_
<seb128> should be today if they respect the schedule
<Kamion> I'm wondering about this with respect to CD build schedules
<Kamion> the release-candidate-candidate CD build is currently scheduled for 2200 UTC today
<seb128> hum
<mdz> Keybuk and I were just chatting about this very subject
<mdz> I did not realize that we were intending to drop in new GNOME upstream tarballs just hours before the release
<mdz> that strikes me as somewhat loopy
<seb128> 2.8.1 is due tomorrow
<seb128> same situation as for 2.8.0 last month
<Kamion> sounds like an argument for final on the 20th to me :)
<mdz> I don't think that's acceptable even for a release candidate
<seb128> 2.8.1 is a bug fixes release
<seb128> changes are very minimal
<mdz> yes, but even bug fix releases need to be tested
<mdz> and tested on Ubuntu
<seb128> translations updates and some fixes
<pitti> seb128: don't forget about the ubuntu-specific patches
<pitti> seb128: I still know the hassle of the new gnome-vfs2 package :-)
<seb128> pitti: don't worry about this
<pitti> seb128: are there no code changes in pacakges we modified?
<Keybuk> if we're not going to wait for the .1, I don't see the need for even *having* a preview/final release ... we should just do hoary final (e.g.) two weeks after GNOME release 2.10
<carlos> thom: a present for you: http://users.evtek.fi/~k0400388/debian/
<seb128> waiting for .1 is good, there is still a bunch of annoying bugs in .0
<Keybuk> seb128: indeed
<seb128> 2.8.0 has some mime issues fixed now
<carlos> thom: the firefox es locale packaged already for Debian
<mdz> seb128: we can't include 2.8.1 in the RC if it doesn't exist yet
<mdz> it just isn't possible
<Keybuk> the question is when *do* we stop uploading new bug fixes?
<carlos> thom: those packages are waiting for the sponsor to be uploaded into Debian
<seb128> mdz: it's 90% done
<Kamion> 2.8.1 tarballs have been being uploaded right up to today
<seb128> mdz: if we miss 2 tarball that's not a big deal
<Kamion> it seems to me we might as well finish the job rather than having something in between
<elmo> Kamion: s/today/5 minutes ago/ :)
<Keybuk> Kamion: especially given GNOME's traditional brokenness when you mix even point-release packages
<mdz> if these .1 releases are broken when used with .0, then they aren't living up to our expectations
<seb128> Keybuk: that's wrong
<mdz> those kinds of changes would not be acceptable
<seb128> don't listen to Keybuk 
<mdz> ok
<seb128> point-release are minimal change
<seb128> I'm checking all the changelog
<Keybuk> I'd still rather we delayed the RC so we had all of 2.8.1 in and tested than went with a hybrid
<seb128> BTW the upstream fix of e-d-s on amd64 seems to break the build
<seb128> http://people.no-name-yet.com/~lamont/buildLogs/e/evolution-data-server/1.0.2-0ubuntu1/evolution-data-server_1.0.2-0ubuntu1_20041012-1642-amd64-failed
<seb128> if somebody has an amd64 box to test ...
<seb128> Mithrandir hacked the previous version, he has probably an idea but he's not here apparently
<elmo> to test the build you mean?
<elmo> I can give you access to our amd64's to do that
<seb128> to try to fix it
<seb128> the problem is that I'm pretty busy with the stack of tarball to package before 2100 UTC (if the CD is for 2200 UTC)
<seb128> so if somebody has some time to check that ...
<Kamion> we can move the CD build back a bit if the pressure is intolerable
<seb128> 2200 UTC should be fine if the builds are ok
<seb128> so we need to fix e-d-s on amd64
<elmo> well, anyone who has time, needs an account, shout.. 
<elmo> I've installed e-d-s' build-deps in the chroot
<seb128> for the previous version we runned libdb/dist/s_config 
<seb128> to get it working on amd64
<seb128> if somebody can try to run a build after running this ...
<Keybuk> mdz: so what do we want to do for warty?  We can stick a tech-board agenda about hoary's release for next tuesday
<seb128> oups, the meeting !
<mdz> Keybuk: for warty it sounds like we are OK
<mdz> we'll get the 2.8.1 builds we can, and the others we'll give a miss
<Keybuk> 2100 UTC cut-off for the 2.8.1 tarballs?
<mdz> npmccallum: ping?
<seb128> Keybuk: I'll have the current tarballs done before 2100 UTC
<Keybuk> are any new ones expected/outstanding?
<seb128> I've not checked the details, but most of the desktop (nautilus/metacity/panel/applets/evolution) is here
<seb128> gnome-terminal is missing but didn't even get a 2.8.0 
<sabdfl> seb128: let's try to get them all in, even if it means we delay the first RC build
<seb128> and nobody really maintains the control-center
<seb128> sabdfl: ok
<seb128> but it should be fine for the build
<Kamion> I'm going to get dinner while I have a chance
<carlos> seb128: goneme project wants to retook it :-P
<elmo> GOD DAMN IT.  MY ADSL IS *NOT* ALLOWED TO DIE TONIGHT
<seb128> mine was down 2 hours this morning
<seb128> doesn't help
<Kamion> if your ADSL dies, I recommend driving to the nearest staff member's house :)
<elmo> even the nearest staff member is 2 hours away
<elmo> sabdfl's clearly got some no-northerner's hiring discrimination policy going on :-P
<sivang> elmo : where you located? :)
<elmo> sivang: Leeds in the UK
<mdz> could someone knowledgeable about multibyte whatsits look at 2304/2305/2307?
<mdz> is this RC material?
<pitti> mdz: I already looked at the bugs
<pitti> mdz: I already was inclined to downgrade them
<pitti> mdz: this affects a very special case in Unicode environments
<pitti> mdz: I know about this bug for some time, but since Warty uses the old encodings (latin and such), I don't think this is RC
<npmccallum> mdz: pong
<pitti> mdz: BTW, 2304 says that downgrading to 1:3.1.3-3 fixes the problem; this is exactly Warty's version :-)
<pitti> mdz: only #2307 applies to warty and is a bit nasty
<pitti> Kamion: do we install UTF-8 locales for some languages by default?
<pitti> Kamion: nevermind, this doesn't matter. #2307 applies to non-UTF-8 locales, too
<mdz> pitti: go ahead and NOTWARTY 2307, then, if you would
<pitti> mdz: 2307 is warty
<pitti> mdz: I just submitted a patch
<mdz> pitti: er, 2304 I meant
<pitti> mdz: the question is only if it is regarded as RC
<pitti> mdz: I already closed the other two, they are notwarty
<pitti> mdz: grep works fine for one-byte languages, but fails on this case for the e. g. asian languages (which are multibyte in any case)
<Kamion> pitti: some, yes
<Kamion> however I'd be slightly surprised if the installer worked entirely smoothly in e.g. ja_JP anyway
<pitti> Kamion: I just uploaded a patch for #2307; it is straightforward and I tested it, but _if_ we fix it for warty, I would nevertheless appreciate some more eyes
<elmo> err, WTF
<pitti> Kamion: I don't think that this affects the installer so much, this case is rather special
<elmo> 2211 isn't reproduceable anymore
<Kamion> pitti: no, I know, I'm just saying that anyone using exclusively ja_JP has other issues anyway
<pitti> Kamion: it might affect maintainer scripts and user's programs
<pitti> Kamion: right
* Kamion casually pockets his Heisenbug-generator out of elmo's sigh
<Kamion> sight
<pitti> Kamion: never tested it, it all looks japanese :-)
<elmo> I wonder if it's because the disks were still being scrubbed.. but that's like.. really odd
<Kamion> pitti: first stage should be fine, second stage is likely to be broken since jfbterm and unifont are not in warty
* pitti grabs sth to eat
<doko> Kamion: the {[] }@? keys don't work again on the german PBook keyboard with today's CD.
<Kamion> um, nothing's changed recently
<mdz> pitti: why do upper and lower not work, but alpha does?
<mdz> elmo: maybe it has to do with where the kernel lands on the disk?
<doko> /etc/environment looks better, however LANGUAGE="de_DE:de_DE:de:en_GB:en" (doubled de_DE)
<mdz> pitti: asian language support in Warty is not necessarily up to par anyway; we haven't tested it
<mdz> pitti: it's not worth the risk of changing grep; I'm downgrading it
<Kamion> doko: that's cosmetic though
<elmo> mdz: that won't have changed tho?
<Kamion> (don't know where it comes from)
<pitti> mdz: alpha is upper and lower together; the functions are just not interpreted correctly, they forgot to respect --ignore-case
<Kamion> oh, incidentally, whoever arranged for the GNOME menus to be ordered from right to left when you're running in a locale whose language is written from right to left deserves a Cleverness Medal
<Kamion> last call for RC1 uploads in about 15 minutes by the current schedule ...
<Kamion> where's that artwork?
<doko> kamion: do I understand you right, that you would prefer merging complete .po files only?
<Kamion> doko: it's too late for the release candidate anyway
<Kamion> doko: the patches are fine as long as we haven't drifted too far; all of yours applied cleanly
<seb128> ok, all the packages out of gnome-session have been uploaded
<doko> noticed that the debian packages converted to utf8 for all po files. that would be another patch (after warty).
<Kamion> we'll be doing a big resync with d-i after warty anyway
<Kamion> that's why I didn't want too many gratuitous changes to strings we haven't changed for Ubuntu
<doko> I'll send you the scripts I used for generating the diffs. msgmerge & co do very well.
<seb128> somebody had a chance to look on e-d-s amd64 ?
<Kamion> doko: OK
<Kamion> doko: thanks - I think we've merged as many as we can for warty now, though
<Kamion> I looked briefly at the Spanish translation, but those .po files only seemed to be for the changed strings, and I didn't have time for the merge
<carlos> Kamion: do you need help with that?
<Kamion> carlos: CD builds are starting in an hour at current schedule, it's just too late I'm afraid
<carlos> What needs to be done?
<Kamion> at the current schedule no more uploads will be accepted for warty
<Kamion> anything that touches the d-i initrd requires two hours absolute minimum
<Kamion> mdz: we have a server naming question to punt to you
<carlos> Kamion: ok
<mdz> Kamion: you know I suck at names
<Kamion> mdz: sabdfl wants an rsync module containing only current CD images for each current release
<Kamion> we can't use cdimage.u.c though, since people are already using it
<Kamion> would you and jdub kill us if we stole releases.u.c?
<sabdfl> mdz, Kamion, idea is to have a minimal "installer and live cd" mirror possibility for small mirrors
<mdz> Kamion: hmm
<mdz> Kamion: cdimages-i-actually-want.ubuntu.com?
<mdz> Kamion: releases doesn't sound too bad, as long as we can put something on port 80 as well if we decide we want to
<Kamion> unless we can do cdimage::releases/ sanely
<mdz> Kamion: I had no plans for it
<Kamion> mmmkay, thanks
<mdz> a module on the existing cdimage seems simpler, though
<mdz> cdimage::current?
<doko> discworld.ubuntu.com
<mdz> hehe
<elmo> mdz: still need non-rsync access
<mdz> pratchett.ubuntu.com, for the subtle indirection
<mdz> isn't the existing /releases/ pretty much that already?
<mdz> we could fold sounder-test and releases/preview into a "milestones" dir
<mdz> and use releases/ only for real releases
<elmo> we can't move ISOs around without a lot of advance notice
<seb128> ok, session seeems to be bugged, we keep 2.8.0
<seb128> so all the modules have been uploaded
<mdz> seb128: great
<seb128> somebody has looked on the e-d-s build ?
* ..[topic/#ubuntu-devel:mdz] : Ubuntu development -- general discussion on #ubuntu | 9 RC bugs to go
<mdz> seb128: is that the one which failed on amd64?
<seb128> yes
<mdz> Mithrandir: ping?
<seb128> if somebody has an amd64, it would be nice to run libdb/dist/s_config and run the build again to test
<Kamion> I have an amd64 but I haven't got it network-connected, which makes things very awkward
<mdz> seb128: I can get you a shell in 5 minutes
<seb128> elmo said he installed the build dep in the chroot some time ago
<seb128> where is the chroot in question ?
<elmo> yellow.warthogs.hbd.com
<elmo> you have an account
<mdz> argh
<seb128> thanks
<mdz> WHY does it include its own copy of libdb?
<Kamion> mdz: symlinks are fine but as elmo says we can't change what's there already
<Kamion> preview was really the last chance we had to do that
<seb128> elmo: 
<seb128> $ dchroot
<seb128> Executing shell in 'warty' chroot.
<seb128> Unknown id: seb128
<seb128> dchroot: Child exited non-zero.
<seb128> dchroot: Operation failed.
<elmo> seb128: dchroot -c warty
<Kamion> elmo: I don't think sabdfl's too bothered about HTTP access for now (correct me if I'm wrong)
<elmo> it's debian dchroot, not debian.org dchroot
<seb128> elmo: same
<elmo> oh, crap
<seb128> warti is the default 
<seb128> s/warti/warty/
<elmo> seb128: fixed, sorry
<Kamion> elmo: people accessing by HTTP can be directed to the right place by means of README.html
<elmo> kamion: mmk *shrug*
<seb128> elmo: np, thanks
<Kamion> is the module best constructed in rsyncd.conf, then, or by symlinks? bit worried about how symlinks will look in the HTTP tree
<Kamion> hm, rsyncd.conf can't map paths around arbitrarily
<seb128> elmo: 
<seb128> wartylog: Couldn't stat source package list http://archive.ubuntu.com ...
<seb128> on an "apt-get source evolution-data-server"
<seb128> s/wartylog/W:/ (completion ...)
<elmo> fixed too
<seb128> thanks
<elmo> Kamion: where are we going to point http folks?
<elmo> cdimage.ubuntu.com/ -> straight into the old layout
<Kamion> do we have people mirroring by http?
<sabdfl> PANTS OFF!
* Kamion wonders how jdub has managed to take over sabdfl's client from the other side of the world
* elmo introduces kamion to the concept of tcp/ip :-P
<Kamion> heh, ok
<Kamion> bleh
<Kamion> would you prefer I created something outside /srv/cdimage/www then, or a new symlink tree inside www?
<elmo> for http mirroring, I dunno.. but i bet we have people going to http://cdimage.u.c/ to download stuff, and AIUI we'd rather they went to the simple layout
<elmo> Kamion: I think outside, www/ maps to what's in the current tree
<Kamion> right, so they'll have to go to http://releases.u.c/ then
<Kamion> I wonder if rsync DTRT with symlinks pointing outside the tree you're rsyncing
<elmo> no, it won't 
<Kamion> arse
<Kamion> so I just have to hardlink it?
<elmo> kamion: err.  hmm.
<sabdfl> we want the simple view for everyone except people who explicitly want the hard one
<Kamion> observing that cdimage/releases/warty/ probably needs to continue to exist for a while
<sabdfl> sure
<daniels> ogg123 '/home/daniels/music/Aphex Twin/Richard D James Album/track01.cdda.ogg'
<daniels> (gah)
<elmo> daniels: stop pretending you listen to music other than David Hasslehof
<Kamion> sabdfl: right, but we have to give that a name other than cdimage now; we're agreed on the principle I think
<elmo> kamion: let's make it so www becomes www/simple and www/hardcore (or something) - and I'll adjust the mirror script on my end to DTRT with hardlinks
<sabdfl> can i see it before it's committed please?
<Kamion> www/full then
<Kamion> sabdfl: we're not going to change the existing cdimage tree, we're creating a new one; so it's probably as easy to commit it and then show you ...
<sabdfl> point :-)
<daniels> otoh, having 'hardcore' in the name will increase our google-fu
<Kamion> bugger, ok, need to rearrange a bunch of scripts now
<elmo> Kamion: me too - don't trigger before I fix my end :>
<carlos> elmo: I just got an email from a Spanish admin that is mirroring Ubuntu every 6 hours
<mdz> seb128: it looks like the code is simply duplicated
<mdz> seb128: maybe a wrong merge?
<carlos> elmo: he says that he sent an email as wiki asks but he did not got any answer and asks for permission to update the wiki with his mirror info
<seb128> mdz: commenting 760L fixes the build apparently
<seb128> libdb/dbinc/mutex.h, 760L
<carlos> what should I answer?
<seb128> do you think it's ok ?
<seb128> /*typedef unsigned char tsl_t;*/
<mdz> seb128: the entire HAVE_MUTEX_X86_64_GCC_ASSEMBLY block is duplicated in both places
<mdz> one of them should be removed
<mdz> they both define all of the same types and macros
<mdz> the code is identical in both cases
<mdz> the only difference is indentation
<seb128> ok, we just remove the libdb/dbinc/mutex.h one so ?
<mdz> seb128: there are two in mutex.h, I'm saying
<seb128> hum
<mdz> 731 and 756
<mdz> both #ifdef HAVE_MUTEX_X86_64_GCC_ASSEMBLY
<seb128> oups, yes
<seb128> why ?
<elmo> carlos: it's fine for him to edit the wiki
<carlos> ok
<carlos> thanks
<mdz> seb128: perhaps a bad merge?
<mdz> anyway, I deleted the first one
<mdz> and it is building
<seb128> ok
<seb128> you're going to upload it ?
<mdz> sure
<mdz> if you don't want to
<seb128> if you've made the changes, just debuild -S and upload please :)
<mdz> I made the changes, but I didn't do a dpatch
<seb128> don't
<mdz> no?
<seb128> that's using cdbs and simply-patch
<seb128> not dpatch
<mdz> ah
<seb128> you just remove the first block ?
<mdz> so you want me to just put the changes in the diff? or do I need to figure out how to make a patch with cdbs?
<mdz> yes
<mdz> correct
<seb128> ok, I'm doing the upload
<seb128> don't bother
<elmo> gar, having a desktop/laptop with reversed ~ and | is really MESSING WITH MY BRAIN
<mdz> seb128: 25 lines starting at 731
<seb128> ok, thanks
* thom makes a note to randomise the keys on the DC keyboard
<mdz> thom: load a dvorak keymap, just as good
<thom> i could just replace it with a french keyboar
<thom> d
<mdz> thom: confuse the hell out of the remote hands guy
<thom> but that'd be too painful for words
<thom> mdz: lol
<thom> mdz: trouble is, that'd inevitably mean i'd end up in the DC to fix the problem
* mdz eats
<Kamion> sabdfl: so, right now, the simple tree ought to contain the preview? or sounder 9?
<sabdfl> kamion: only the latest, greatest one
<sabdfl> the one we want people testing
<sabdfl> and the name of the file should reflect that
<Kamion> that's hard on rsyncers
<Kamion> if you want this to be ideal for mirrors, the name of the file shouldn't change all the time
<Kamion> we can have a README file in the same directory saying what it is
<sabdfl> umm... what about symlinks?
<sabdfl> i'd much rather the name istranferred with download
<Kamion> I guess, but you can't tell remotely that they're symlinks
<Kamion> and it might confuse bittorrent
<sabdfl> the guy ends up with a file that says "warty-sounder9-i386.iso"
<sabdfl> he knows what he got
<Kamion> this is a fundamental conflict between making life sane for mirrors and letting the user know what he's got
<Kamion> I think README is a good compromise
<sabdfl> it's at most a refresh every week
<sabdfl> except during release period
<sabdfl> symlinks seem better to me
<sabdfl> only thing is directing the user to the well-named symlink
<Kamion> if we're calling it warty-sounder9-i386.iso then that should probably be the *only* name, no symlink
<sabdfl> what about:
<Kamion> symlinks will just create "which one do I download?" confusion, and occasionally cause people to download two identical images by mistake
<sabdfl>   - /pool/warty-current-i386.iso
<sabdfl>   - /warty/warty-sounder9-i386.iso -> ../pool/warty-current-i386.iso
<sabdfl> that way people will go into the warty directory and go for the one they want
<Kamion> your pool is my full cdimage tree, apart from size :)
<sabdfl> the mirrors will spend most of their time rsyncing against the previous iso, which would be good
<sabdfl> size does matter in this special case :-)
<Kamion> it'll end up as /pool/warty-install-i386.iso and /warty/warty-install-sounder9-i386.iso, I think
<Kamion> hm, no, warty-sounder9-install-i386.iso
<Kamion> elmo: what do you think?
<sabdfl> what's the vi voodoo to reflow a paragraph?
<Kamion> gqip
<sabdfl> kamion: for for safety we do have sounder, preview, rc and final cd's in the pool?
<Kamion> or gq} to reflow to end of paragraph
<Kamion> sabdfl: people who want older ones have the full tree
<sabdfl> yes, agreed
<Kamion> if we're not convinced by the newer one, we shouldn't be declaring it to be the one everyone should be using :)
<sabdfl> erm, that didn't work so well on my python code
<sabdfl> oops
<sabdfl> is there a way to limit it to a selection?
<Kamion> v to enter visual mode; move over range; gq
<Kamion> assuming vim
<sabdfl> ah, perfect, thanks!
<Kamion> I'm going to need an ubuntu-release script at this rate
<Kamion> bet that'll be well-tested
<Keybuk> make damn-it-all-to-hell-im-going-to-bed
<Keybuk> (best run on Friday night, for maximum damage :p)
<Kamion> personally I'm just glad cdimage is effectively backed up all over the world now
<sabdfl> Kamion: one more, for the bonus prize!
<sabdfl> how do i autocomplete a word, searching forward in the doc?
<Kamion> sabdfl: Ctrl-n
<sivang> sabdfl : you recieved anything from jdub regarding default home page?
<Kamion> (I think)
<sabdfl> wow, works!
<sabdfl> thanks
<sabdfl> sivang: not yet
<Kamion> Ctrl-p searches backwards
<Kamion> elmo: ok, I have www/simple/ and www/full/ now; www/full/ is what used to be www/
<Kamion> elmo: let me know when you're ready for a sync
<Kamion> it's a bit steam-driven, I'll probably use the time between now and 7am to automate it :P
<elmo> Kamion: k
<sivang> sabdfl : regarding docs, as agreed on the meeting this is more of a Hoary material, however do we have sufficient docs for _users_ IYO per this release? (on ubuntu.com) or leave this entirly to Hoary?
<mdz> sivang: sufficient docs has always been a Hoary goal
<mdz> for Warty, our goal was to organize the existing documentation
<sivang> mdz : ok. proceding with streamlining current yelp accessible docs for Ubuntu, due by the 18th.
<sivang> mdz : that is , the gnome2-user-guide
<mdz> sivang: streamlining?
<hornbeck> mdz: I think he means making them more Ubuntu specific
<sivang> mdz : fetching 2.8 docs from CVS, makig sure it fits ubuntu perfectly and adjust when needed. (removable media )
<sivang> mdz : etc
<sivang> mdz : dealing with rmov. media is one aspect I guess, but than again there might not be any work needed other than that :)
<hornbeck> sivang: I already have most of the 2.8 gnome-user-guide ready, just need it packaged
<mdz> sivang: there are many differences apart from removable media
<mdz> Ubuntu's default menu structureis completely different
<sivang> mdz : yes ofcourse, I was  just trying to make you understand what I meant :-)
<sivang> mdz : this is this first thing you notice after install, this and that you have no icons on the desktop :)
<hornbeck> seb128: thanks for packageing for us doc guys :)
<seb128> np
<seb128> thanks for making docs work :)
<hornbeck> we try
<elmo> Kamion: your trigger is wrapped in a script and/or only called in one place, right?
#ubuntu-devel 2004-10-24
<Kamion> elmo: it's wrapped in a script
<elmo> cool
<Kamion> hey, you can even branch off it in tla if you want me to change it ;)
* elmo beats kamion with a +6 rust-proof sword of subversion
* Kamion zaps elmo with a wide-angle disintegration beam
<Kamion> (lucky he's disint-resistant, eh?)
<mdz> But wait!  elmo's medallion begins to glow!
<sivang> the medallion reflects back the disintegration beam to the Sun...
* Kamion summons Archons. Destroy elmo, my servants!
<Kamion> sivang: aha, you have not yet been infected by a certain game ...
<sivang> Kamion : quite not, waston my friend, quite not..:)
<Kamion> elmo: anyway, yeah, tla kinda seemed appropriate at the time given the context :P
<sabdfl> oh dear
<sabdfl> time for some potions of rejuvenation
<sabdfl> a.k.a. sleeping pills for the warty team
<sivang> sleep ? who us? sl-eep? what does the word mean anyway?
* Kamion writes a theoretically-might-work publish-release script
<amU> mdz: i'm upping a new iso, your ati problem is fixed, with packages from 23h CEST 
<mdz> amU: great, URL?
* mdz looks at the clock
<amU> .... upping now, ETA is 2h    
<elmo> gar.  stupid torrent.
<mdz> Kamion: ready to do the CD build?
<amU> elmo: who many users has the torrentserver ? mine broke at about online 500 users :( 
<amU> s/online 500/500 online/
<Kamion> mdz: only when elmo gives me the ack to sync to auckland again
<mdz> amU: http://torrent.ubuntu.com:6969/
<elmo> kamion: yeah, I'm setting up releases on another machine sorry
<Kamion> that's OK, just letting mdz know the status
<elmo> okay, you're good to sync
<elmo> I haven't done releases yet, but I've fixed auckland
<Kamion> I'll run through a test sync first
<Kamion> should be going now
<elmo> "pool"??
* elmo just actually saw this layout
<Kamion> 22:04 < sabdfl>   - /pool/warty-current-i386.iso
<Kamion> open to better names?
<sabdfl> elmo: great ideas show up in the oddest places :-)
<Kamion> it *is* a bit, er, conflated
<sabdfl> .pool might be more sekrit
<mdz> .dpwh/pool
<Kamion> dpwh?
<sabdfl> dpwh?
<mdz> kids these days...
<sabdfl> don't put warty here?
<mdz> "don't put warez here"
<elmo> well, err, like, why have a pool?  the point of pool is to handle things (.deb's, .iso's) which appear in multiple things (suites/releases/whatever)
<elmo> and we don't seem to do that with ISOs really?
<sabdfl> elmo: this is a place to put the "current" release so rsync's work well
<mdz> we do when we decide we want a different layout :-)
<mdz> put everything into the pool once, and symlink into the layout du jour
<sabdfl> the symblinks give them a meaningful name, depending on where they are in the release cycle
<Kamion> elmo: main issue we have is calling the ISOs warty-sounder9-install-i386.iso to keep sabdfl happy as above, while not screwing over mirrors completely on every update if the delta is small
<elmo> err, ok
<sabdfl> it's because (a) i want real names for the files ("warty-sounder9-i386.iso") and (b) kamion wants names that don't change for sensible mirroring
<sabdfl> if we can have a .dpwh dir which is larely hidden that makes me even happier
<sabdfl> less confusion
* Kamion waits for consensus :-)
<Kamion> anyway, I imagine I can kick off the CD builds now?
<Kamion> no artwork, so this can't be final
<mdz> jdub_: artwork status?
<sabdfl> jdub was around...
<Kamion> 22:34  * jdub_ leaves for nsw tender meeting
<Kamion> 50 minutes ago
<mdz> sabdfl: send the artwork to me and I'll do it
<sabdfl> k, coming up
<Kamion> I'll wait
<sabdfl> mdz: oh bugger, i don't have the gdm login screen, nor the gnome splash
<sabdfl> jdub has those directly from jane / designers
<sabdfl> i only have the desktop images
<sabdfl> will send the desktop images, with instructions
* mdz pings jdub_ extra hard
<sabdfl> mdz: i think he's chasing REVENUE! so let's go ahead and catch him when he gets back
<elmo> gar, I can't believe we're shipping a distro where fricking paste doesn't work right in vi
<sabdfl> elmo: why?
<elmo> sabdfl: why doesn't it work, or why can't I believe it it, or ?
<mdz> autoindent?
<mdz> that is a pretty lame default
<elmo> yeah, the autoindent shit
<mdz> that should only be enabled for source code
<elmo> and anyone who tells me to :set paste is going to get beaten
<sabdfl> well, let's get it sane
<sabdfl> elmo goes through walls
<elmo> yeah, I'll beat them through a wall or two
<mdz> Debian ships with the same default in vim
<mdz> but they ship a useless vi by default
<mdz> nvi is good for pasting and not much else
<elmo> meh, it's absolutely fine for non-hardcore or oldschool vi folks
<mdz> the sort of "oldschool" that means you still use ksh
<thom> elmo: paste works fine in nano *duck*
<sabdfl> ok, can we fix this to a sane default?
<mdz> sabdfl: _now_? :-)
<Kamion> hoary
<sabdfl> is it not trivial?
<mdz> it is trivial to change
<mdz> it is non-trivial to decide whether the change is the right thing to do
<Kamion> it's not a really painful badness
<Kamion> vim still works fine ...
<mdz> (except for elmo)
<Kamion> it requires testing in compatible mode, etc.
<sabdfl> mdz: you, elmo, kamion, do you all agree on a sane default?
<mdz> elmo: you could upload that change as your uber-secret easter egg without telling us
<elmo> sabdfl: I was just whining - it's not worth a zeroth-hour change
<sabdfl> ok
<Kamion> sabdfl: I'm not convinced we do; I think vi should set paste or noai or whatever only in compatible mode
<thom> hey, yeah. what happened to the easter egg
<elmo> thom: figlet got demoted to universe :-P
<Kamion> elmo, I suspect, disagrees here
<thom> Kamion: i tend to agree
<thom> elmo: lame easter egg :P
<elmo> thom: dude, it was going to be cowsay'ed figleted init.d startup scripts
<mdz> elmo: figlet turned out to be not-necessarily-redistributable
<thom> elmo: sick puppy :-)
<elmo> I dare you not to be freaked out when your computer starts up and starts shouting at you from a speech bubble of a cow 
<Kamion> dunno about the cowsay, but figlet-on-failure would rock :-)
<sabdfl> mdz: desktop images on the way
<elmo> mdz: yeah, I know
<sabdfl> i still vote for the very rare but random warthogs noises
<thom> yeah, forget this orange crap
<sabdfl> like, once in three years rare
<sabdfl> orange
<thom> lets have FAILED take up the whole screen
* sabdfl pricks his ears
<Kamion> that's like the old GNOME fish :)
<Kamion> appeared roughly once a month
<sabdfl> we should make our's really, really rare
<sabdfl> so it's a badge of honour to have heard the hog
<sabdfl> and it only lasts for, say 10 seconds
<sabdfl> quite quiet
<sabdfl> ooohhhh
<Kamion> (incidentally, why is all the init script stuff in /lib/lsb/init-functions rather than somewhere in /etc where you can actually configure it?)
<elmo> hey, speaking of sounds, are we going to get a "Hi, my name is Mark Shuttleworth, and I pronounce Ubuntu Uh-Boon-To" on the website? :)
<amU> :) 
<sivang> just like linus torvalds did?
<sivang> :)
<mdz> sabdfl: err
<mdz> sabdfl: are you sure you want to use JPEGs?
<mdz> rather than PNG?
<Kamion> elmo: Matthew Vernon wishes to convey a remote slap with a trout for the cowsay-figlet idea
<sivang> JEPS are evil
<sivang> JPEG
<sabdfl> mdz: alternatives?
<mdz> sabdfl: PNG
<sabdfl> i have high-res versions here
<sivang> PNG! PNG! :)
<sabdfl> can you do a quick check and see how big the png is?
<mdz> how?
<sabdfl> sivang: it's got fades and stuff, i though png might be too big
<mdz> they're compressed; I can't tell without a copy of the real image
<sabdfl> fire up gimp, open the image, save a copy, png
<mdz> that won't be the same
<elmo> we're down to one uninstallable, zero out of date
<mdz> it's been through jpeg compression and a smoothing filter
<mdz> elmo: what's the uninstallable?
<elmo> mozilla-firefox-locale-gl
<mdz> but I'll do it as an estimate
<sabdfl> i just started a gradient on a big widescreen background to try to get you widescreen desktops too
<sabdfl> grabs the X totally, can't stop it or switch away
<sabdfl> for about 90 minutes
<mdz> sabdfl: a bit under a meg
<sivang> sabdfl : oh, maybe color depth reduction/
<sabdfl> let me see a sec...
<Kamion> shall we just drop -gl?
<Keybuk> sabdfl: any particular reason why we don't just make the background an alpha PNG and use nautilus' inbuilt desktop gradient feature to do that
<thom> elmo: please remove it, i don't even know where gl is, let alone how to find firefox l10n for it
<mdz> agreed
<mdz> elmo: I'll remove it from the seed
<sabdfl> Keybuk: it's not an easy gradient
<elmo> it's gone
<sabdfl> we can get fancier for hoary, with png alpha overlays on solid desktops etc
<Keybuk> sabdfl: it's not just a horizontal or vertical one?
<sabdfl> ok, hold on a sec
<sabdfl> Keybuk: no
<sabdfl> its a blend of several radial and horizontal ones at different angles with different opacities
<doko> thom: it's your last european colony ;-)
* Kamion notes with slight amusement that our CDs will ship with dists/stable, dists/testing, and dists/unstable symlinks
* mdz is not amused
<Kamion> it only occurred to me today that it was inappropriate
<mdz> all pointing to warty, I suppose?
<elmo> oh yes, do we want stable in the archive yet, or only for final ?
<Kamion> all pointing to warty
<Kamion> I wouldn't like to swear that d-i is not relying on one of them
<amU> *nickdetection* ;)
<Kamion> I don't *think* it is, but now is not the time to mess - should have noticed last week
<mdz> amU: you need to match on word boundaries :-P
<sabdfl> ok, for png export from gimp
<sabdfl> does compression mean it's lossy?
<mdz> no
<mdz> set compression to max
<doko> thom: sorry, GI is Gibraltar, GL is Greenland, maybe no Ubuntu users there ...
<Kamion> doko: gl is Galician, not Gibraltar or whatever, if that's what you're thinking
<mdz> doko: language, not country
<sabdfl> interlacing?
<mdz> no
<sabdfl> we wait
<doko> I see ...
<sabdfl> we wait
<Kamion> oh, CRAP
<sabdfl> we wait....
<mdz> Kamion: don't say that...
<elmo> we all panic...
<Kamion> I need to upload debootstrap to remove pcmcia-cs
<mdz> Kamion: !!
<sabdfl> Kamion: Can't Really Answer Properly?
<mdz> I thought that was done weeks ago
<mdz> we can't do that now
<Kamion> so did I
<mdz> that means the automatic installation of pcmcia-cs is untested (in our environment anyway)
<Kamion> I've tested it in our environment ...
<sabdfl> comes out at 1.1MB, vs 360kb for the JPG
<sabdfl> can ship either, your call
<mdz> PNG, no question
<Kamion> mdz: how severe was that bug again?
<mdz> we have the space on the CD, and millions of ubuntu users will thank us
<Kamion> it'll need to be reopened
<sabdfl> ok, will render them now
<mdz> Kamion: that bug was not as bad as risking pcmcia-cs being missing for a much larger class of users
<Kamion> all right then, sorry for this :(
<mdz> though, the workaround is worse for the dell bug
<Kamion> that's the only discrepancy FWIW
<mdz> it stops the machine from booting
<mdz> whereas if pcmcia-cs is not installed for some reason, the user can just install it
* mdz ponders
<Kamion> it's only bad for machines with both a PCMCIA network card and a PCMCIA CD-ROM, and I'd suggest those are very rare
<Kamion> (or no networking, I suppose)
<mdz> ok, let's take it out of debootstrap
<elmo> okay, releases.ubuntu.com is up
<elmo> Kamion: can you also trigger archvsync@mirnyy.ubuntu.com pls ?
<doko> for hoary, do we want python everywhere?  see the embeddedpython builtin for bash ;-) http://home.eol.ca/~parkw/index.html#bash
<Kamion> elmo: same key?
<elmo> Kamion: yep
<Kamion> elmo: bash: line 1: /home/archvsync/releasessync: Permission denied
<elmo> heh
<sabdfl> schnake!
<elmo> Kamion: fixed, I think
<Kamion> elmo: done
<elmo> kamion: cool, working
<Kamion> sabdfl: nonexecutable python doesn't work well either :)
<sabdfl> mdz: images incoming
<sivang> sabdfl : could you let me know when you have the final offline page? i'd like to see how is came up.
<elmo> Kamion: he was talking about doko's stuff :)
<sabdfl> sivang: jdub is away for the moment
<mdz> sabdfl: I might have an email size limit somewhere upstream of me, we'll see
<Kamion> elmo: ah :)
<sivang> sabdfl : ok.
<sabdfl> sivang, maybe send me what you sent jdub
<mdz> sabdfl: hasn't come through
<sabdfl> s'gawn from here
<mdz> aha, finally arrived
<sabdfl> wow, check the size of the flat one vs the gradients
<elmo> so, err, someone remind me of the timetable, pls?  need to plan for sleep (or lack thereof)
<sabdfl> though these gradients are pretty slick
<Kamion> fortunately debootstrap-udeb is not in the d-i initrds
<sabdfl> elmo, if you are roughly done, now would be a good time to crash while we test the RC build
<sabdfl> mdz, that ok by you?
<mdz> sabdfl: yes
<Kamion> elmo: can I just bother you to hurry this debootstrap upload through incoming, if that's possible?
<Kamion> it was delayed a bit because I had to update my scripts to look at restricted, so as to make sure there was nothing else missing
<sabdfl> guys, let's change as little as possible.
<sabdfl> it's late here, and this is serious "whoops" material
<sabdfl> especially if mdz goes on his intended "final release" jihad
* mdz snickers
<mdz> sabdfl: what should the descriptions be for these images in the wallpaper selector?
<sabdfl> "hard core" and "soft core"?
<elmo> what final release jihad?
<sabdfl> as in "you thought this was a rc, muahaha"
<elmo> you mean mdz's in on that crack too?
<sabdfl> he's baking it, actually
<pitti> wasn't he the one who proposed it?
<elmo> doh.
<sabdfl> wel... why not
<elmo> because we've been uploading packages throughout the day that have received, like, zero testing?
<sabdfl> kamion: remember that comment about distributing this "to too many people to be embarrased about it"?
<sabdfl> speling aside?
<Kamion> sabdfl: sure, but as discussed with mdz above the result of not doing this is more embarrassing than the consequences if it goes wrong
<mdz> sabdfl: but seriously, where it currently says "Ubuntu Watermark" for the current image, what should these say?
<mdz> Kamion: (we hope)
<sabdfl> mdz: "Ubuntu Default Desktop" for the one with the logo on the gradient
<sabdfl> "Ubuntu Simple Desktop" for the one without the gradient, just flat colour with logo
<sivang> sabdfl : just got a very good email from enrico, we are going to rock ubuntu's docs :) Will send you draft also breifly.
<sabdfl> "No Wallpaper" for the one with.... no wallpaper
<elmo> gar, contents generation is so unbelievably expensive
<sabdfl> sivang excellent, thanks for your work on the wiki, i think the two of you will work well together
<sabdfl> umm...
<sabdfl> "Ubuntu Calendar Grrrlllls".... no, wait
<sabdfl> "Ubuntu Calendar Desktop" for the threesome
<sabdfl> just need a name for the one with the gradient but nothing else
<sabdfl> "Ubuntu Master Desktop"?
<sabdfl> mdz: ^^ all done
<sabdfl> hmm.... maybe "Reference" instead of "Master"?
<mdz> "plain"?
<mdz> sabdfl: should there be an entry for this month's calendar image itself, apart from the rotating one which we'll update?
<Keybuk> mdz: yes, there has to be, otherwise it doesn't work
<mdz> "Ubuntu October Calendar"?
<sabdfl> Then we have "plain" and "simple" :-)
<mdz> Keybuk: really, why?
<Keybuk> the calendar image itself is a symlink to whatever month is current
<sabdfl> ah, ok
<sabdfl> so we need "Ubuntu Monthly Calendar"
<mdz> Keybuk: does it read the symlink or something?
<Keybuk> mdz: this stuff gets copied into the user's .gnome2 directory -- so if you change it every month, they don't get new montly images, just new available images
<sabdfl> and "Ubuntu October Calendar"
<Keybuk> so you need one "Monthly Calendar" image that changes; but it has to be a symlink, otherwise it'll get cached and not updated :)
<mdz> Keybuk: yes, I know
<mdz> I'm talking about the menu
<Keybuk> so am I :)
<mdz> you're telling me there has to be an entry in the menu pointing to foo-bar.png in addition to the one pointing to ubuntu-calendar.png?
<Keybuk> also sometimes users simply aren't going to like the new month, so they should be able to nail it at a past image they liked
<Keybuk> mdz: yes.
<mdz> that makes no sense to me
<mdz> but we want one anyway
<Keybuk> ah, sorry, there doesn't *have* to be an XML entry -- the monthly is enough provided it's a symlink
<Keybuk> and provided the destination of the symlink changes each month
<Keybuk> but we want one anyway, so they can stick an old month they liked
<lamont> moo
<mdz> sabdfl: what did you say you wanted the gradient-only one called?
<mdz> Keybuk: ok, that's what I thought
<sabdfl> "Plain" would be fine
<sabdfl> mdz: we still need gdm and gnome splash
<sabdfl> gdm has me concerned as a straight droping, but I suppose we can test lots of resolutions on any given desktop
<sabdfl> dropin
<pitti> Can anybody tell me when the CD images will be ready approximately? Is it worth to stay awake for them for last-minute testing?
<mdz> it is so wrong that ubuntu-artwork uses cdbs
<Keybuk> blame jdub
<mdz> this "no wallpaper" option should have been added a long time ago
<mdz> it has to be done completely differently from the PNGs
<Keybuk> No Wallpaper ?
<Keybuk> that's built-in to GNOME
<sabdfl> pitti: rather crash and be up early if you can!
<sabdfl> there will be reports from users for you to review
<Keybuk> mdz: remember, you need to change $(THIS_MONTH) at the top of art/wallpapers/Makefile.am
<pitti> sabdfl: okay, I thought the images were ready by 2300 UTC :-)
<mdz> sabdfl: keep the existing watermark image in the list also, or remove it?
<mdz> I assume we have to keep the file, because people are using it for their background
<sabdfl> mdz: remove
<mdz> Keybuk: did
<Keybuk> sabdfl: that'll vanish strangely for people who've used Preview though?
<Keybuk> actually, given we shipped Preview with "Monthly Calendar" as the default -- it won't -- it'll get replaced with the threesome
<sabdfl> awesome :-)
* Keybuk adds a test user to check that
<Kamion> "threesome"? dare I ask? :)
<mdz> sabdfl: is that "stretched" or "scaled"?
<Kamion> pitti: sorry :-(
<mdz> I think "scaled"
<mdz> the existing stuff is all "centered"
<mdz> this is a bit crazy to be changing at this point
<Keybuk> hmm... ok, my new user just didn't get any session :-/  gah
<Keybuk> at least, no panel setup
<Keybuk> weird
* lamont grumbles.  looks like OO.o was the only large package that _didn't_ get uploaded since I last freshened my mirror.
<pitti> Kamion: np, planning means to exchange coincidence by mistake :-)
<pitti> I'm looking forward to test the images tomorrow; today's were very good
<Keybuk> ahh, I wonder whether this is related to this morning's gconf problem
<sivang> sabdfl : sent
<sabdfl> mdz: stretched i think
<sabdfl> scaled will give weirdness on widescreen
<mdz> sabdfl: I assume "scaled" preserves aspect ratio
<Keybuk> yes :o)  I needed to import panel-default-setup.entries after I'd nuked gconf's defaults
<Keybuk> mdz: yeah
<sabdfl> mdz: yes, but these iamges won't look *that* bad on widescreen
<Keybuk> stretched doesn't
<sabdfl> and I'm working on some widescreen png's for you
<sabdfl> at least, my pc is working on them 
<sabdfl> Keybuk: so, are we ok?
<mdz> gnome-background-properties crashes now
<Keybuk> gah ... it looks like seb's dropped the patch
<seb128> which patch ?
<Keybuk> to the desktop properties stuff
<mdz> sabdfl: the text will look moderately bad, and the people will look worse
<Keybuk> hmm, no, I'm just being stupid
<Keybuk> after explaining to mdz why it had to be a symlink, I changed the filename :p
<sabdfl> the scaled image will give very ugly lines
<sabdfl> so let's go stretched
<sabdfl> widescreen guys will immediately go to change it
<sabdfl> i've got 1600x900 versions under way
<Keybuk> sabdfl: yup, confirmed
<sabdfl> confirmed we are ok?
<Keybuk> it'll be centered though, because that's how we shipped Preview
<sabdfl> hmm... pity
<sabdfl> it won't pick up the new setting?
<Keybuk> no, golden rule, remember -- it doesn't override it because it doesn't know the old setting, so doesn't know whether the user had changed it
* Keybuk considers a trick ...
<sabdfl> gotcha
<sabdfl> thought the old setting was in a system pref somewhere, so if the user hadn't changed it, we could update it
<Keybuk> nah, this stuff is done by copying xml files about :(  it's not gconf
<Keybuk> oh, wait
<mdz> ok, this isn't working correctly at all
<Keybuk> mdz: what's not working?
<mdz> Keybuk: built new ubuntu-artwork, installed on a clean system, the preview images show up in the selector, but it never changes the background
<Keybuk> you click, and nothing happens?
<mdz> exactly
<mdz> nothing in xsession-errors either
<Keybuk> kill nautilus
<mdz> it works fine on my other machine where I did my tests
<mdz> but I've copied things around and deleted ~/.gnome2/background* etc.
<Keybuk> yah, it's a long-standing bug somewhere between nautilus, gconf and control-center
<Keybuk> similar to the "I added an applet and it didn't appear" one
<mdz> killing nautilus fixed that particular weirdness
<mdz> ok, we'll just add "killall nautilus" to the release notes :-P
* Keybuk sees it every now and then, and hasn't yet managed to track it down
<Keybuk> mdz: it's very very very very rare; and entirely unrelated to our voodoo here
<sabdfl> Keybuk: scott@netsplit.org right?
<mdz> ok
<Keybuk> it just happens that every now and then, nautilus and the control-center wallpaper properties dialog loose sync
<mdz> so I have a new libgnome which changes the default solid colour
<Keybuk> sabdfl: netsplit.com
<mdz> I have a new ubuntu-artwork with the new wallpaper
<Keybuk> or just scott@canonical.com :)
<mdz> I need gdm stuff
<Keybuk> mdz: I'm contemplating a trick to make the Previewers upgrade their imagery <g>
<mdz> gdm and gnome splash
<Kamion> 'pkill nautilus', puhlease :-)
<mdz> sabdfl: do we have those?
<sabdfl> mdz no, jdub does though
<sabdfl> i think jane sent them straight through to him, i didn't see them
<mdz> sabdfl: what shall we do?
<mdz> jane and jeff are the only people with copies?
<sabdfl> yes
<sabdfl> if that's the sole change we can make it tomorrow morning
* mdz faints
<sabdfl> jdub must be back soon
<sabdfl> mdz: patience, we need
<sabdfl> release, we will
<mdz> uploaded
<mdz> uploadING, I should say.  ubuntu-artwork will take a bit
<Keybuk> so what do we want to do about the watermark?
<Keybuk> do we mind that upgraders will get the threesome, but centered and not scaled ?
<sabdfl> Keybuk: its ok
<mdz> this is one of those things that jdub and I meant when we said we needed this stuff earlier
<mdz> Keybuk: we could add a sed one-liner to UpgradeNotes :-)
<Keybuk> mdz: or we could just change the default gconf schema <g>
<Keybuk> which you'll have had to do anyway to make the threesome not the default
<mdz> the calendar was the default?
<mdz> hmm, didn't change that
<Keybuk> yes
<mdz> will do
<Keybuk> I'd forgotten, the default has absolutely *nothing* to do with the XML
<Keybuk> if the first time they open that dialog, the default doesn't have an XML entry, their background vanishes
<Keybuk> if we change the gconf defaults (which we need to do anyway)
<Keybuk> preview users who never touched the background dialog will change to the plain/simple whatever image
<Keybuk> preview users who touched the background dialog will either keep their changes, or if they left it at Calendar, change to the threesome but centered (they can then change that if they want)
<Keybuk> which seems good enough for me
<sabdfl> night all, i'm crashing, back in about 7 hrs
<sivang> mdz faints? getoutta here!
<sivang> :)
<mdz> Keybuk: is debian/patches/01_default_background.patch at all relevant?
<mdz> I've already changed 06_ubuntu_theme.patch
<Keybuk> yeah
<mdz> yeah, it's relevant?
<Keybuk> of libgnome ?
<mdz> yes
<elmo> I'm going to crash for a bit too - phone's on if you need me (or shout in the next couple of minutes)
<Keybuk> *checks*
<Keybuk> nah, that's the old Debian one
<Keybuk> ignore it
<lamont> bad libgnome
<Keybuk> 06_ubuntu-theme is the right one
<mdz> ok
<lamont> libgnome_2.8.0-0ubuntu4 ftbfs
<lamont> Trying patch debian/patches/03_gnome-terminal.patch at level
<lamont> +0...1...2...failure.
<lamont> or did that get fixed already?
<mdz> Keybuk: want to look over this before I upload it?
<Keybuk> mdz: yeah, dcc the patch and I'll check it
<mdz> who what?
<Keybuk> libgnome-2.8.0/debian/patches/06_ubuntu-theme.patch
<mdz> added a new patch as well
<Keybuk> oh, right
<Keybuk> ok
<mdz> debdiff emailed
<Keybuk> and in ubuntu-artwork there's an XML entry for /usr/share/backgrounds/warty-final-ubuntu.png which is 'stretched' ?
<mdz>   <wallpaper>
<mdz>     <_name>Ubuntu Default Desktop</_name>
<mdz>     <filename>/usr/share/backgrounds/warty-final-ubuntu.png</filename>
<mdz>     <options>stretched</options>
<mdz>   </wallpaper>
<Keybuk> looks good to me then
<mdz> ok, uploading
<mdz> sivang: you don't need to threaten to revert to Debian for you bug report to get attention; we read all of them
<Kamion> elmo: I'm moving pool to .pool now, seems least controversial
<mdz> he's snoozing
<Kamion> yeah, but he'll see when he wakes up
<mdz> just mentioning it in case you missed his departure
<Kamion> odd, my sync to releases doesn't appear to be taking effect
<sivang> mdz : I didn't mean this to sound like a threat. Would have never dreamed to impose a such  - I just said I am considering to switch back to debian in order to get over the "bug" to allow me to continue work. :) However if this was understood as a threat - My apologies. I greatly appriciate the truely amazing work done on Ubuntu and might have got out of line unintentionally , will you excuse me?
<Kamion> mdz: so am I just waiting for libgnome and ubuntu-desktop now?
<Kamion> er, ubuntu-artwork
<mdz> sivang: no problem, a lot of people seem to be doing that recently and it is getting to me
<mdz> Kamion: yes
<mdz> with any luck, they're building now
<mdz> lamont: ?
<lamont> which package?
<lamont> libgnome_2.8.0-0ubuntu4 is ftbfs
* lamont looks to see if there's something newer
<mdz> lamont: ubuntu5
<lifeless> sivang: I'm curious - what bug is it?
<mdz> lifeless: 2315
<lamont> mdz: w-b still shows ubuntu4. give it another minute or2
<mdz> -rw-rw----    1 mdz      mdz           315 2004-10-12 17:19 libgnome_2.8.0-0ubuntu5_source.upload
<lamont> mdz: on a different note, does AM_MAINTAINER_MODE take any args, or is it just ^AM_MAINTAINER_MODE$?
<mdz> lamont: that's it
<Kamion> no documented arguments
* lamont fixes snacc while he waits
<Keybuk> lamont: just AM_MAINTAINER_MODE
<Kamion> you could in theory use arguments, I think, but they'd be ignored
<Kamion> and it's probably broken to try to do so
<lifeless> tasty bug there.
<Keybuk> uh, it'd probably expand to <contents of AM_MAINTAINER_MODE> (ARG1, ARG2)
* lamont fears that his autocrap virginity has been violated for some time now, but he likes to continue pretending...
<sivang> mdz : I fell inlove with Ubuntu the first day I layed hand on , I want to be proud of it on my laptop :) let me _whatever_ more info you need for this bug and don't hesitate to ask me to test quirks you have in mind for investigation.
<Kamion> Keybuk: would it? oh
<Kamion> Keybuk: how does m4 know?
<lifeless> why macro languages are not always good, or why m4 was the wrong choice
<mdz> sivang: you tried each of those parameters by itself, alone, with none of the others?
<Keybuk> Kamion: dunno, trying to remember how m4sugar treats that kind of thing
<Keybuk> don't give it arguments, anyway :)
<Keybuk> AM_MAINTAINER_MODE(AC_PROG_CC) ... would that expand AC_PROG_CC and therefore do checks for compilers? :p  (I *think* it would)
<Kamion> probably
<lifeless> Keybuk: 
<lifeless> bah
<Kamion> hm, no, m4 is expand-then-evaluate surely
<Kamion> oh, no, arguments are collected and expanded before macro expansion
<Keybuk> Kamion: ho-ho-ho
<Keybuk> cf. the infamous Libtool bug... "if AC_PROG_CXX has been expanded, do AC_LIBTOOL_CXX"
<Kamion> my m4 is, how can I put this, rusty
<Keybuk> which, of course, expanded AC_LIBTOOL_CXX and its dependencies *anyway*
<Kamion> heh
<sivang> mdz : yes, acpi=off miraculessly hangs the kernel in random parts. the most advanced part was when detecing HDs
<mdz> that makes no sense
<mdz> sivang: have you run a memory test?
<mdz> sivang: please attach the information requested
<sivang> mdz : I know, I have been given this about 3 hours of investigation, trinyg different kernels etc
<sivang> mdz : didn't run memory test.
<mdz> sivang: did you try the kernel which was working for you under sid?
<sivang> mdz : that's a starters..however it kills me to think this 1 year old machine has already corrupted memory
<sivang> mdz : I will try that
<sivang> mdz : I tried the latest sid, I am not sure which one was that worked. I erased sid for ubuntu :)
<sivang> mdz: I don't have any notes , I went unnoticed since everything was working fine
<sivang> mdz : on debian unstable , that is
<sivang> mdz : pitti suggested 2.6.7 , lastest what do you think?
<sivang> lastest = latest
<sivang> mdz : I am now on 2.6.8.1-3-686-smp, it gives me very slighttly better performance as a temporary workaround.
<Keybuk> PCI: Cannot allocate resource region 4 of device 0000:00:1d.2
<Keybuk> ^ is it me, or does that appear on every Ubuntu kernel
<lamont> libgnome, ubuntu-artwork uploaded for i386, I expect the others have to
<lamont> o
* lamont must run off for about 20-30 minutes
<Keybuk> sivang: randomly, if you run top is anything hogging CPU ?
<sivang> let's check
<sivang> mostly XFree86 but it switches places with gnome-termina and idle init
<mdz> can you guys take this discussion to #ubuntu?
<sivang> so guess it's normal
<sivang> anyway, I have to hit bed now
<mdz> releasing to do, and all that
<sivang> night all
<Keybuk> 2.6.8 and laptops definitely doesn't seem to be friends :-/
<mdz> lamont: when will they be in the archive, so Kamion can build a CD?
<Kamion> seven minutes from now I'd imagine
<hornbeck> 2.6.8 works great on my laptop
<hornbeck> Inspiron 600m
<Keybuk> hornbeck: yeah, seems randomly odd;  it seems that it just won't boot/work on any modern HP for example
<Kamion> building
<hornbeck> hmmm, I will have to grab a HP and try it out
<Keybuk> though that's an acpi problem, it won't switch on the fans so your laptop overheats
<hornbeck> man that is crap
<hornbeck> I used to use a compaq and it always had problems
<mdz> Kamion: let me know when I should start my rsync
<Kamion> mdz: jigdo-file isn't quick, I'm watching the log file
<Kamion> mdz: note that the images are now called warty-install-amd64.iso, etc.
<Kamion> (to distinguish from live)
<mdz> Kamion: same directory, though?
<Kamion> yes
<lamont> mdz/Kamion: they made it, I assume?
<Kamion> lamont: yep, I checked
<lamont> kewlness
* lamont is back,btw
<Kamion> bugger, it broke
<mdz> sweet
<Kamion> investigating
<mdz> off to a roaring start, then :-)
<Kamion> oh, probably just recent publish-daily changes
<Kamion> gah, BLOODY tla
<Kamion> its conflict handling SUCKS ARSE
<Kamion> mdz: anyway, it's up now, have at it
<Kamion> I'll announce to ubuntu-users as soon as a few of us have had a brief go at it
<lamont> Bad, bad server. No donut for you
<lamont> hehe
<Kamion> geez, 9K/s?
<Kamion> should've grabbed it myself before telling you lot :P
* lamont fixes snacc
<mdz> lamont: downloading ISOs?
<lamont> mdz: url? :-(
<lamont> mind you, it'll take about a day or two unless I head into town, which I was avoiding until later...
<Kamion> lamont: daily/current/
<lamont> duh
<mdz> we need more people testing this than just Kamion and me
<mdz> npmccallum: ping?
* lamont ponders driving down to the neighbors and hijacking his wireless/DSL
<Kamion> "testing" a.k.a. still downloading the first one
<Kamion>    163062594  28%    8.57kB/s   13:03:56
<lamont> Kamion: remind me of the rsync location again?
<asw> hi... I'm new. 
<Kamion> lamont: archive.ubuntulinux.org::cdimage/daily/current/
<Kamion> asw: hi
<mdz> burning i386
<mdz> Kamion: why such abysmal throughput?
<asw> kamion: is wartylog making public logs somewhere?  I wouldn't mind reading logs before I make a complete fool of myself. 
<Kamion> laptop test would be good
<Kamion> mdz: dunno, it's picked up now
<Kamion> asw: I think so, but to tell you the truth I can't remember where
<lamont> wow.  only 42 hours to go on the rsync. 
<lamont> :=(
<lamont> guess it's time to go hijack the neighbor's DSL.
<lamont> (for a very liberal definition of 'neighbor')
<Kamion> mdz: I'm hoping it's because all the Canonical staff are downloading it too
<Kamion> asw: may not be public for historical reasons, bug fabbione :-)
<lamont> anybody need anything before I disappear for 30+minutes?
<lamont> right.  there go all those excuses....  back online in a bit.
<Kamion> http://people.ubuntulinux.org/~fabbione/fabbione.jpg is just alarming
* lamont wonders what daniels did that day...
* lamont wanders
<mdz> ARGH
<mdz> where is pitti
<mdz> mizar:[~]  ls -ld /media/scd0
<mdz> d------rwx    1 mdz      mdz            11 1903-12-31 23:00 /media/scd0
<mdz> mizar:[~]  mount | grep scd0
<mdz> /dev/scd0 on /media/scd0 type hfs (rw,noexec,nosuid,nodev,sync,umask=007,uid=1000,gid=1000)
<Kamion> pmount b0rked?
<Kamion> pitti went to bed
<Kamion> about two and a half hours ago
<asw> that photo of "fabbione" is very interesting. I think I'll just lurk on the mailing lists and if people don't mind in here for a while... 
<Kamion> mdz: that would be 0.1-5 from yesterday; but why is umask=007 having that effect?
<Kamion> mdz: maybe umask= is broken for hfs?
<mdz> Kamion: yes
<mdz> Kamion: already filed a bug, fixing it and reopening the other one
<Kamion> looks hairy to fix well
<mdz> yes, I shouldn't have let that can of worms open
<mdz> easy enough to revert, though
<mdz> Kamion: the archive-copier progress bar is off
<mdz> not a show-stopper, but I remember you noticed it before and thought you fixed it
<Kamion> I think I noticed it and then forgot to fix it
<Kamion> nobody ever filed a bug
<Kamion> damn it, I was colliding with my own daily local mirror update, no wonder it was going slowly
<fabbione> morning guys
<mdz> Kamion: i386 success
<mdz> fabbione: please test the current daily
<fabbione> Kamion: why my pic should be "alarming"? ;)
<fabbione> mdz: i can't
<Kamion> fabbione: I think it's the unshavenness viewed from below :)
<fabbione> Kamion: ehehe
<mdz> fabbione: why not?
<asw> fabbione: are there irc logs for me to read?  I'm new just added myself to the mailing lists...  used GNU/Linux since 1993 programmed in C since the late 80s.  I've been looking for a distribution I could let my parents use. 
<fabbione> mdz: see my comments on Stuff Calendar
<mdz> Expected downtime between 2 to 5 hours.
<fabbione> mdz: read all the others too
<fabbione> please
<mdz> ok, I did not hear about that until now
<fabbione> Hardware capabilities will be reduced to minimum from 9/10 to 16/10. Still able to test and release X, not able to test d-i either in netboot or cd.
<fabbione> mdz: i wrote that a long while ago
<fabbione> anyway today i am going to test the new adsl line
<Kamion> mdz: burning amd64 now
<fabbione> mdz: in approx 2 hours and it will take 1 hour or so
<mdz> Kamion: i386 success, powerpc going, amd64 about to start
<fabbione> mdz: if it works i will move the office and i might be able to do something after downtime
<Kamion> mdz: presumably you want me to scratch and rebuild anyway with the new pmount, though
<fabbione> mdz: if it doesn't work i will take off tomorrow for the other office site
<tseng> yay mono is slowly trickling in
<Kamion> mdz: if so, I'd like to do so sooner rather than later, since I'd like to ask ubuntu-users@ for testing
<mdz> stage 1 complete on amd64 and powerpc
<mdz> Kamion: sure
<fabbione> jee guys you write too many emails :-)
<justdave> hmm, we got Firefox 0.9.3 back?
<Kamion> amd64 success
<Kamion> hm, we never fixed that bug where firefox starts up bigger than the space between the two panels?
<mdz> powerpc install failed
<Kamion> what happened?
<mdz> some bad kernel stuff on the screen
<mdz> unfortunately I was screwing around plugging and unplugging USB stuff at the time to try to get the KVM wired up
<mdz> so it may be tainted
<mdz> I got the "problems installing packages" dialog
<mdz> and yet no packages were unconfigured
<Kamion> that's a bit concerning
<Kamion> I'll let you know when powerpc manages to arrive here
<Kamion> 51% on i386 download currently
<mdz> amd64 hung hard
<mdz> going to retry it
<mdz> hmm, apparently not; it did a clean acpi soft power off
<mdz> ok, restarted amd64 and powerpc
<fabbione> asw: welcome to the team...
<Kamion> mdz: you know (NOTWARTY), there's not really much point in linux-amd64-* and linux-power* being in restricted
<Kamion> mdz: they don't depend on anything in restricted, so they could easily be in main
<Kamion> mdz: although I suppose that means they could disappear for some people if we had to move them from main to restricted later
<mdz> Kamion: amd64 does, now
<mdz> unless I forgot to upload that
<Kamion> I think you forgot to upload that
<Kamion> "Depends: linux-image-amd64-generic"
<mdz> shit, I forgot to upload it
<mdz> I even tested it on amd64
<Kamion> is somebody writing down the errata here? :)
<justdave> I'm about 80% on the ppc download
<justdave> says 10 minutes left
<Kamion> trying a German i386 install now
<mdz> Kamion: amd64 successful
<mdz> Kamion: yes, I am
<Kamion> pcmcia-cs is being correctly installed on this laptop
<Kamion> new CDs with new pmount coming up in half an hour or so
<mdz> Kamion: here as well
<asw> fabbione: thanks. I'm downloading the livecd.  I want to try it on the cheapest laptop I can get that does hardware accelerated OpenGL. My msc (cs) / phd (biophysics) project is a new alife simulator using the seti@home infrastructure (will be opensource again in January.) I would love to see it working out of the box on ubuntu
<fabbione> asw: sounds cool...
<asw> not much to look at but the first cut of the "ecology" is online at http://science.fiction.org 
* fabbione is a seti@home guy since 1997
<fabbione> or so..
<mdz> Kamion: powerpc has a problem
<mdz> libgphoto2-port0 failed for some reason
<mdz> it's still configuring other stuff, so I don't yet know what went wrong
<Kamion> mdz: package ordering problem?
<mdz> dunno
<Kamion> mdz: I've seen this from time to time; apt randomly decides to stick libgphoto2-port0 and gphoto2 in different dpkg runs, I think
<mdz> Kamion: there should only be one dpkg run
<Kamion> well, it's not randomly, it's deterministic for a given CD
<asw> at the moment are you guys only accepting packages already in debian? 
<Kamion> when I've seen it before, it has gone away in subsequent CDs with no relevant package changes
<asw> (I realize this may be the wrong place to ask...) 
<mdz> asw: we are not accepting much of anything right now; we're trying to build a release candidate
<fabbione> asw: no. but there will be no new packages until the 21st of Oct.
<Kamion> mdz: the problem might be reproducible in debootstrap?
<mdz> Kamion: the apt config options for the dpkg command line length and number of args were increased to huge values a while back
<mdz> if they're still not big enough for some reason, we should bump them up in base-config
<mdz> there are known ordering bugs when dpkg has to be invoked multiple times
<asw> mdz: yeah sorry. I shouldn't be bothering you guys.  But I thought I would drop by and say how excited I am to see your project!  I've used the knoppix livecd but competing with novell & redhat requires more ... 
<Kamion> what are they? they're not in apt.conf
<mdz> Dpkg::MaxArgs and Dpkg::MaxArgBytes
<Kamion> mdz: I'm not sure a base-config change in that area is significantly less scary than just changing the numbers in apt, to be honest
<Kamion> I mean what are the values
<mdz> 350 and 8k
<Kamion> that certainly sounds way too small for desktop!
<Kamion> hell, there are 596 packages in ubuntu-desktop alone
<Kamion> (powerpc)
<Kamion> the problem with doing it in base-config is that the apt.conf will stick around on users' systems forever
<mdz> dpkg: dependency problems prevent configuration of libgphoto2-2:
<mdz>  libgphoto2-2 depends on libgphoto2-port0 (>= 2.1.4-6.1ubuntu0); however:
<mdz>   Package libgphoto2-port0 is not configured yet.
<mdz> dpkg: error processing libgphoto2-2 (--configure):
<mdz>  dependency problems - leaving unconfigured
<Kamion> unless we remove it after the installation run, or do it with -o options
<mdz> Kamion: aptitude -o
<mdz> I suggest we increase to 1024 and 32k
<mdz> whether we do it in apt or in base-config
<Kamion> the length of all the package names combined for powerpc is 8193 bytes, *just* over 8k
<Kamion> perhaps that's tripping it
<mdz> it's probably tripping both
<asw> btw: are the people writing documentation in this chanel? or elsewhere? I'm working on a little review of x3d/vrml viewers on Debian. 
<mdz> Kamion: ok, I'm going to do it in apt
<mdz> hmm
<mdz> Kamion: actually, I wonder what the maximum safe MaxArgBytes is
<mdz> bash supports huge ones
<mdz> but I dunno about dash
<mdz> dash seems happy enough with 65000
<Kamion> I don't know either; I was beginning to lean towards base-config being a safer place at this point for that reason
<Kamion> oh, if dash is OK ...
<Kamion> asw: asleep, I think
<mdz> hmmm
<mdz> Kamion: let's do this in base-config
<Kamion> aptitude -o is passed through to libapt safely?
<mdz> I've never done an apt with a not-purely-numeric native version number
<mdz> who knows what could break
<Kamion> :-)
<mdz> oh, wait
<mdz> aptitude doesn't actually support -o, does it
<mdz> even _synaptic_ suppotrs -o, dammit
<Kamion>        -o <key>=<value>
<Kamion>               Set  a configuration file option directly; for instance,
<Kamion>               use -o Aptitude::Log=/tmp/my-log to log  aptitudes  ac
<Kamion>               tions to /tmp/my-log. For more information on configura
<Kamion>               tion file options, see the section Configuration  file
<Kamion>               reference in the aptitude reference manual.
<mdz> where's that?
<Kamion> aptitude(8)
<mdz> aptitude(1) you mean?
<Kamion> bleh!
<Kamion> it's aptitude(8) in Debian unstable
<mdz> it's not in my copy
<Kamion> the version in warty doesn't mention -o
<mdz> I don't think it supports it
<mdz> I remember it not being there
<mdz> the other option is to make this apt 0.5.28 and push that in
<Kamion> does it really not support it, or just not document it?
<mdz> oh, I could do .27.1
<mdz> it doesn't uspport it, just tried
<Kamion> I can't even type MaxArgBytes reliably at the moment, I'll take your word for it
<mdz> uploading
<Kamion> the other option is a temporary apt.conf
<Kamion> but that's flaky
<Kamion> ah, that was quick :)
<mdz> I thought they were bigger than that
<Kamion> they?
<mdz> maxargs and maxargbytes
<mdz> lamont_r: do you have the ability to kick this apt build into happening sooner?
<lamont_r> mdz: no
<Kamion> mdz: it has to get through the archive and into w-b first, I imagine
<lamont_r> Kamion: exactly
<lamont_r> mind you, I _could_ potentially violate all that is sacred and build it from a .dsc and upload it, but that would be wrong, and have no effect right now, since I couldn't get that to happen in the next 5.5 minutes
<lamont_r> assuming, of course, that you have already uploaded the source, that is.
<Kamion> let's not get too hacky at the last minute :)
<lamont_r> exactly
<Kamion> so, anything *else* before I build RCC3?
<lamont_r> the real solution is to have elmo whack the archive crunchers
<lamont_r> Kamion: you mean I can abort my 5 hour download and go back home???
<Kamion> lamont_r: leave it where it is, the rsync delta will be small
<mdz> hmm, just noticed something neat
<Kamion> lamont_r: and if you don't care about pmount or powerpc it won't matter anyway ;)
<lamont_r> Kamion: where it is is sitting in my car in the rain outside of the closed coffee shop in town... :-(
<mdz> if you mount nfs filesystems in fstab, portmap gets started with different options
<mdz> so if we have portmap listen on localhost by default, we don't have to fix that
<mdz> under other conditions, I would consider that a bug :-)
<mdz> lamont_r: closed, but the wireless still works?
<mdz> and what's "rain"?
<justdave> powerpc image still crashes Disk Utility
<Kamion> I think we'll just have to point people at other tools for that, doesn't sound easily fixable
<lamont_r> mdz: sure - he just has DSL from the phone company, unmetered.
<lamont_r> justdave: if we could find the bit-pattern... :-)
<mdz> there's a distinct SEP field around that issue
<lamont_r> mdz: rain is when the RH exceeds 100%, and the temp is > 0C. :-)
<Kamion> well, if it weren't a proprietary program that's crashing, I might go and look :P
* justdave burns it with Toast
<Kamion> "Bitte geben Sie Ihren Benutzernamen ein"
<justdave> Kamion: it's not.
<Kamion> i386 success auf Deutsch
<justdave> hdiutil is part of Darwin
<Kamion> justdave: ah, interesting
<justdave> (which is the open-source part of OS X)
<mdz> "open source"
<Kamion> in that case I might go and look when I have Copious Free Time :)
<Kamion> viewable source, at least
<justdave> mdz: seriously.  you can modify and redistribute. :)  no guarantee of Apple taking your changes back of course :)
<justdave> there are forks of Darwin out there
<Kamion> justdave: it's not DFSG-free which is pretty much the definition of open source too
<Kamion> the APSL has some interesting clauses, as I remember
<Kamion> unless those have been fixed
<justdave> that could be.  yeah, I've never looked too hard, never had anything worth borrowing from it related to anything I was working on yet to have a need to look at it
<mdz> dunno, it's too long for me to read right now
<mdz> which is a bad indication in itself
<Kamion> I wouldn't have any qualms about looking at the code (Ben Herrenschmidt does, for example); I'd be careful about using code from it directly
<mdz> lamont_r: is apt building?
<lamont_r> should be within a minute or 2
* lamont_r checks
<mdz> I thought :03 was the magic
<lamont_r> yeah, it is.
<lamont_r> but that takes a minute or so to get i386 w-b updated,
<lamont_r> and then one of the 3 buildd's has to finish its 300 second wait (nothing to do), and notice,.
<Kamion> seems to take a minute or two extra to sync all the data over sometimes too
* mdz taps his foot impatiently
<Kamion> you know, you'd think cdrecord could check whether the file you've asked it to record actually exists before wasting time spinning up the CD
<lamont_r> 0.5.27.1 is building
<lamont_r> on i386, at least
<thom> Kamion: don't be stupid, that'd be a feature
<thom> cdrtool doesn't have any of those
<mdz> cdrecord is crap and I am not using it anymore
<mdz> I will sooner buy a DVD-ROM drive for anyone I need to burn a disc for
<justdave> cdrecord doesn't appear to work on IDE burners, either
<mdz> you can pretty much burn DVDs with dd(1)
<justdave> I kept getting SCSI errors when I tried it
<lamont_r> mdz apt uploaded for i386
<mdz> justdave: works for me, after a fashion
<mdz> lamont_r: thnaks
<mdz> thanks, too
<justdave> couldn't come up with a usable device name
<lamont_r> mdz: it would be nice if growisofs would burn cds at the CD speed, not the DVD speed..
<justdave> I suppose if I could figure out the device name it might work
<lamont_r> er, nm. that's cdrecord again
<Kamion> thom: mkisofs does have a scary feature set, mind
<Kamion> justdave: /dev/cdrom works fine
<lamont_r> justdave: I use cdrecord with an ide burner just fine
<justdave> Kamion: on OS X?
<mdz> ignore its pedantic warning about it
<Kamion> justdave: oh. dunno
<Kamion> that seems like an ambitious prospect at best
<justdave> I'm thinking about people who only have OS X currently trying Linux for the first time :)
<Kamion> Joerg Schilling barely supports Linux never mind OS X
<justdave> cdrecord works on OS X, but I couldn't come up with a device name it liked for my burner
<Kamion> "works"
<lamont_r> mdz: wrt closed: I'm getting sig strength/qual of 5/55, using my gain antenna... :-)
<justdave> well, yeah, I couldn't get it to work :)
<lamont_r> ah, ppc.  dunno about that.. :-)
<mdz> lamont_r: and that's still faster than home?
<justdave> other folks on ubuntu-users claimed it did, iirc
* lamont_r needs someone to buy him a G5.
<lamont_r> mdz: sure
<lamont_r> I just have to hear his wimpy ACK's.. :-)
<lamont_r> he hears me just fine... :-)
<lamont_r> well, I lie...
<Kamion> interesting reaction to new artwork on #ubuntu
<lamont_r> I could burn bandwidth like there's no tomorrow and download at about the same speed, or even closer to 40KB/s,  but that gets real expensive real fast
* justdave grabs the freshly ejected CD
<justdave> showtime
<m_tthew> lamont_r: how high is your high-gain
<lamont_r> which artwork did we wind up with?
<Kamion> justdave: bet you hit the same apt bug
<lamont_r> m_tthew: this one is 5.5db on the end of about 5 db of cable loss
<lamont_r> 100mW card
<lamont_r> so I'm really only about 5db up
<lamont_r> I'm also shooting through about 5mm/hr of rain
<lamont_r> maybe 10mm/hr
<lamont_r> yeah.  10
<m_tthew> ugh
<lamont_r> not sure if he has low-E windows or not
<lamont_r> but I'm only going < 100meters
<mdz> m_tthew: there is this guy "Matthew D. Peavy" posting to ubuntu-users now, and I keep mistaking him for you at first glance
<mdz> Matthew...eav...
* m_tthew chuckles
<m_tthew> he probably types better than I do
<fabbione> lamont_r: do you remember what's the equivalent of 0C and -20C in F?
* thom kicks off the cd image cron job early and goes to make tea
<lamont_r> 32F and whatever 32-36 is
<thom> Kamion: define interesting :-)
<Kamion> thom: hmm?
<mdz> thom: up early or up late?
<thom> mdz: early
<thom> hideously so
<thom> 05:23 here
<fabbione> lamont_r: 32F = 0C =
<fabbione> ?
<thom> Kamion: " < Kamion> interesting reaction to new artwork on #ubuntu"
<Kamion> 05:09 < whiprush> woo, new wallpapers.
<Kamion> 05:09 < whiprush> half naked people!
<Kamion> 05:09 < ob> haha i saw that.
<Kamion> 05:09 < ob> my wife was like "what the hell are you doing?"
<Kamion> 05:09 < ob> "i swear to god i didn't do it!  it was ubuntu!"
<Kamion> 05:09 < whiprush> "Use ubuntu and you could end up like this guy. Two. women. and GNOME!"
<mdz> fabbione: yes
<fabbione> mdz: ok thanks
<mdz> 32F is the temperature at which water freezes under whatever standard conditions
* fabbione was checking the router env limits
<fabbione> mdz: yup.. that's what i assume with 0C
<lamont_r> so how does one make the people disappear from the new wallpaper?
<mdz> lamont_r: you should not get the people by default
<Kamion> they're not there by default
<mdz> lamont_r: if you are, that's a bug
<fabbione> mdz: i am going to disconnect wartylog and me to go and test the new adsl line in a few minutes.
<mdz> fabbione: ok
<fabbione> mdz: wish me luck.. :-)))
<lamont_r> fabbione: and 100F == "human body temp."  specifically, farenheit's wife.  with a slight cold that day... :-(
<mdz> fabbione: good luck
<fabbione> if everything goes ok i will have full hardware capability within a few hours
<mdz> lamont_r: which part of the body? :-)
<fabbione> lamont_r: ehhe sounds fun :-)
<lamont_r> mdz: ok.  hadn't actually gotten to that part, but walked through grabbing just ubuntu-artwork and waltzed through the .png's
<lamont_r> mdz: I expect it was an oral temp
* lamont_r wonders how long it will take Fort Collins' finest to inquire about why he's sitting in a parking lot with the engine running... :)
<m_tthew> not long, I'll wager -- although it *is* a weekday
<lamont_r> and only 22:30
<fabbione> no luck :(
<mdz> fabbione: :-(
<fabbione> mdz: there is no atm signal at all
<thom> ye gods. mono-assemblies-base is huge :/
<mdz> thom: universe package, RESOLVED/INVALID :-P
<fabbione> either the system requires an unconfigured router to set parameters (that won't surprise me)
<fabbione> or the ISP has done some fucks up
<mdz> or the telco has done some fucks up
<fabbione> either way tomorrow will be another 2-5 hours downtime
<mdz> I dunno about telcos in denmark, but here they are notorious
<fabbione> mdz: here they are pretty good, but the problem is that i have been testing with my router
<fabbione> their router still has to arrive
<fabbione> so i am not sure if there might be differences in the configuration
<fabbione> but i had to try
<thom> mdz: *g*
<pitti> Hi fabbione! Feeling any better today?
<fabbione> pitti: yes. i slept until 4 am this morning
<fabbione> almost all in a raw
<pitti> sounds good ;-)
<fabbione> yeah
<mdz> I'm looking forward to some of this "sleep" myself
<mdz> pitti: have you tested the release candidate candidate yet?
<pitti> mdz: It just finished downloading, cd writing is at 5%
<mdz> pitti: great, thanks
<pitti> mdz: It takes me a while, I only got 50kB/s
<pitti> mdz: I will test powerpc first
* fabbione feels pretty useless today
<mdz> pitti: it's only about 25% different from yesterday's daily
<mdz> fabbione: we still love you!
* pitti grins
* fabbione hugs mdz
* mdz gasps for air
<fabbione> since i can't test the crack today...
<mdz> fabbione: can you test a new portmap package?
<fabbione> mdz: yes i can do that
* thom cranks his dsl harder
* fabbione was writing "mdz: what can i test for you?"
<mdz> fabbione: i386?
<pitti> gar, another broken cd-rw
<fabbione> mdz: yeps
<mdz> fabbione: emailed
<fabbione> mdz: i cannot do installations from scratch. that's it
<mdz> fabbione: it listens on only localhost by default
<mdz> fabbione: (#505)
<fabbione> mdz: but i can test packages
<thom> right, nearly have the amd64 iso
<mdz> see the comments in #505 about what needs specific testing
<mdz> thom: do you want me to burn an extra and send it to you?
<mdz> it might be faster
<thom> at this rate it might well be :/
<thom> yay, just finished
<mdz> my secret is that I rsync the CD images every night
<mdz> so I never have more than one day of deltas
* fabbione does sync 6 times a day :-)
<Kamion> I don't actually rsync automatically, but I rsync most days anyway
<fabbione> ok
<fabbione> time to test portmapper from bottom up
<fabbione> later
<thom> mdz: that was only one day of deltas
<thom> well, once i remembered that the names had changes
* mdz comforts thom
<daniels> thom: you should move somewhere with decent bandwidth
<thom> end of november.
* ..[topic/#ubuntu-devel:pitti] : Ubuntu development -- general discussion on #ubuntu | Happy birthday Matt! 9 RC bugs to go
* pitti hands mdz a glass of champagner
<pitti> Cheers to our fearless distribution leader!
<mdz> I'm drinking creamsicles actually :-)
<thom> happy birthday dude
* mdz hobbles around with a cane
* pitti cannot find "creamsicles" in the dictionary. No matter, if it tastes well :-)
<mdz> pitti: orange juice and stoli vanil
<doko> happy release day ;)
<pitti> Can we say it's also Warty's birthday? If RC == Final?
<mdz> pitti: sadly, RC != final
<mdz> due to #505
<mdz> though maybe fabio's testing will give us a second chance
<Kamion> any word on gdm artwork?
<mdz> Kamion: hmmm, jdub should be well awake
<mdz> jdub_: ping?
<fabbione> mdz: nfs client is ok. portmapper binds to localhost only.
<Kamion> powerpc's good, I'm 3 for 3
<mdz> fabbione: I assume locking does not work
<fabbione> mdz: but i was checking.. there are other services like rpc.statd that are listening on all ips
<mdz> fabbione: that is OK, those are not enabled unless you install non-default packages (nfs-common()
<mdz> Kamion: Jane might be awake
<mdz> she is the other party in possession of the gdm bits
<Kamion> 8am's a bit early yet
<mdz> repo man's got all night, every night
<mdz> what time did Mark say he would be back?
<thom> fucking. i'm so buying a new router when i move
<fabbione> tcp        0      0 *:32768                 *:*                     LISTEN     
<mdz> thom: www.soekris.com
<fabbione>     100021    3   tcp  32768  nlockmgr
<mdz> fabbione: but without portmap, the server can't find the port number to connect to
<fabbione> that's correct
<Kamion> 01:06 < sabdfl> night all, i'm crashing, back in about 7 hrs
<Kamion> 01:06 < sabdfl> night all, i'm crashing, back in about 7 hrs
<mdz> fabbione: I think we mostly just need to document how to turn on portmap
<Kamion> so about now
<fabbione> mdz: i am checking the server side
<mdz> Kamion: that's what I thought
<Kamion> ok, time for a Windows installation in order to test dual-booting
<Kamion> pity me
<mdz> Kamion: I haven't seen a non-Canonical install report yet :-/
<Kamion> nor I
<mdz> Kamion: oh dear
<mdz> there ought to be a medal or something
<fabbione> mount: RPC: Remote system error - Connection refused
<fabbione> mdz: super!
<Kamion> mdz: do we have any idea what the timescales are for the rest of today?
<Kamion> we need about three hours after the artwork is uploaded, ideally
<mdz> Kamion: I'm in the dark regarding the remaining artwork
<Kamion> I was considering whether it would be possible to crash briefly, but I suspect it won't be
<mdz> all I know is that jdub and silbs have copies
<mdz> I SMSed jdub, but no response
<mdz> Kamion: assuming the CD build script still works for me, that's doable
<mdz> I have a few more hours in me
<Kamion> I'll still have to do publish-release though; that's very raw
<Kamion> I'll keep going on micro-dozes in my chair :)
<mdz> fabbione: that's pretty good, actually
<mdz> fabbione: gives a pretty good idea where to look
<mdz> better than, say, segfaulting :-)
<mdz> it is 0015, why is it hot inside?
<mdz> ah, right, all the computers are on
<thom> mdz: too much vodka?
<thom> oh
<mdz> it was quite hot today as well
<mdz> 29C
<mdz> 84% humidity, yuck
<fabbione> mdz: you can move here... 6C
<mdz> fabbione: maximum?
<mdz> no thanks
<thom> 29C? crikey, it was 10 here today and raining all day
<fabbione> mdz: in this period the top was 10C yesterday
<fabbione> mdz: this morning was 4 or something
<daniels> it was about 24C here today; around 32 yesterday
<daniels> and it's not even bloody summer :\
<mdz> average high October temp in LA is 23C
<daniels> luckily it's been raining also
<fabbione> daniels: here it's winter.. you live in the wrong side of the world
<daniels> apparently yesterday was the hottest october day ever; got up to 40C in some parts of Victoria
<mdz> but it's generally quite dry, and so very pleasant even when it's hot
* thom hacks up dbus-cil packages
<mdz> daniels: seasons don't really mean anything down there
<mdz> daniels: you just make them up as you go along
<daniels> thom: no, don't
<daniels> thom: edd already has a patch in the bts
<thom> oh, gar
<daniels> mdz: we have 'hot', 'pleasant' and 'visiting englishman'
<daniels> the latter involves a lot of rain and biting southerly winds :)
<mdz> daniels: which, to a visiting englishman, is 'pleasant', right?
<mdz> compared to the UK
<mako> mdz: ok, i'm working on an announce mail
<mako> mdz: is the plan to still have a wide audience for this?
<mdz> mako: ok, let me know if you need anything
<mdz> mako: hmm, not sure quite how wide
<daniels> mdz: itym 'familiar'
<thom> mdz: since the visiting englishman in question had been in .au for the 6 months or so preceeding, no, not really
<mdz> mako: the wiki says lwn, debian, python, etc.
<mako> mdz: right, this is definitely the RC announcement though, not the real deal
<mako> mdz: yeah
<mdz> mako: likewise
<thom> daniels: build deps for that patch ain't right
<daniels> thom: it's a start, if nothing else
<jdub_> mdz: here briefly
<jdub_> mdz: artwork and homepage bits on their way
<jdub_> mdz: been at meetings all day
<jdub_> mdz: coming back in ~30mins
<mdz> jdub_: ok, artwork is the biggie
<fabbione> mdz: what's a simple way to test locking on nfs?
<mdz> fabbione: good question
<fabbione> mdz: i know it needs lockd running
<thom> daniels: yeah, will send updated patch in a few
<fabbione> but that's it
<justdave> ok, my ppc install was successful
<mdz> fabbione: how about dpkg?
<justdave> it finally finished.
<daniels> thom: phat
<mdz> justdave: thanks
* pitti curses at archive-copier, which takes aaaages
<elmo> morning
<pitti> Hi elmo
* daniels kicks his saturated DSL line, complete with flaky router that hd to be power-cycled not long ago.
<fabbione> mdz: i don't want to ruin your day but nfs-common is in main :-))
<daniels> elmo: 'morning dude
<mdz> fabbione: yes, I know...?
<fabbione> mdz: nevermind... :(
<fabbione> mdz: for dpkg? you mean installing a deb package as a client?
<mdz> it is not in base or desktop :-)
<fabbione> mdz: that's easy to test..
<mdz> fabbione: yes, dpkg does flock() locking I believe
<thom> ok, the gdm startup sound freaks me the fuck out
<daniels> thom: doubly so when combined with aphex twin
<mdz> ah, it does fcntl()
<mdz> even better
<daniels> this bloody annoying chirp when the hard drive parks is a great metric of how often it spins up
<fabbione> mdz: testing in a few... 
<Kamion> mdz: what, on the .deb, not on /var/lib/dpkg?
<mdz> Kamion: on /var/lib/dpkg
<fabbione> mdz: i don't have /var on nfs
<mdz> fabbione: debootstrap, mount, chroot, dpkg?
<fabbione> mdz: hmmm i can arrange soething
<mdz> thom: the fact that sound works out of the box freaks me out
<fabbione> mdz: i need a few minutes to move stuff around
<Kamion> it's only worked on one out of three machines here
<Kamion> the powerbook, I think
<thom> mdz: heh
<mdz> Kamion: what has?
<thom> ok, looks great on amd64
<Kamion> then again the amd64 doesn't have speakers
<justdave> yeah, worked on the iBook out of the box, too.  cool :)
<mdz> Kamion: RCC?
<mdz> oh, sound
<Kamion> mdz: sounds
<mdz> sabdfl: morning
<sabdfl> morning warthogs!
<fabbione> morning sabdfl 
<sabdfl> hey fabbione
<sabdfl> Happy Birthday MDZ!
<daniels> mdz: happy birthday
<daniels> sabdfl: 'morning
<fabbione> doh!
<thom> morning mark
<fabbione> mdz: congratulation kid ;)
<fabbione> mdz: 15 again?
<thom> mdz: still think default shell should be zsh tho ;-)
<mdz> thom: hoary :-)
<mdz> sabdfl, daniels, fabbione, pitti: thanks :-)
* daniels beats xorg@freedesktop.org with the 'glxgears is not a bloody benchmrak' stick.
<daniels> so tempting to disable the fps display per default
<doko> thom: does it support utf8 and multibyte?
<pitti> Hi sabdfl
<daniels> mdz: are you on autoreply? ;)
<daniels> mdz: i think we should get get flaweless acpi support so we can suspend, resume, and hibernate on every laptop ever
<daniels> mdz: also, open source support for all wireless cards, and nvidia
* daniels waits for the 'hoary' reply.
<Kamion> dunno about autoreply, but I'm on autopilot
<Kamion> daniels: you forgot to say "kthxbye"
<thom> ok, so. EVMS worked out of the box. sata_via worked fine, mutt is too old but i can deal with that
<mdz> daniels: hoary
<sabdfl> hey Kamion
<daniels> Kamion: ah, my bad
<Kamion> morning Mark
<daniels> mdz: yay!
<thom> from where i'm sat, life is good
<Kamion> the "lens passing over test-card" screensaver freaks me out
<elmo> is this "<foo> freaks me out day"? 
<elmo> :-P
<Kamion> yes, that happens after umpteen hours awake
<Kamion> although I dunno what thom's excuse is, the slacker :)
<fabbione> mdz: ok.. i have /var/lib/dpkg as a symlink to /home/fabbione/dpkg that is NFS mounted...
<thom> pffft. 5am is not sleeping.
<fabbione> mdz: right a few secs that i am waiting rsync to finish and i will do an "update"
<fabbione> mdz: if my workstation will go banana you know who to blame ;)
* mdz looks around...thom!
<fabbione> thom: !
<elmo> thom: 5am? dude, you started claiming you were going to bed at like 11
<thom> elmo: no, i got up at 5
<fabbione> thom: if you want to make all these blames true.. i can handover x.org to you :P
<thom> i went to bed at 1
<elmo> oh, okay, so you only procrastinated for 2 hours :)
<thom> mdz: sorry, kamion has already played the "blame thom" card for the day
<thom> elmo: *g*
<thom> mdz: it's elmo's turn now
<Kamion> thom: don't mind me, I'm easily amused today :)
* fabbione points the finger are elmo
<fabbione> s/are/at
<mako> mdz: http://wiki.ubuntulinux.org/WartyWarthog_2fRCAnnouncementEmail
<mako> based off the last release announcment
<mako> i kept the features totally intact
<mako> and the first paragraph
<mako> dunno if that's still a desireable thing to keep around
<Kamion> mako: s/before the distribution if/before the distribution is/
<fabbione> mako: " Our XFree86 packages have been updated to support plenty of new hardware."
<fabbione> this is not completely true
<Kamion> and aaargh, check the use of "it's" :-)
<fabbione> and i have been kinda "harassed" for that
<doko> finished powerpc and i386 installs. looks ok, besides the known german keyboard problem on powerpc X11
<Kamion>    GNOME 2.8
<Kamion>         Ubuntu is the first distribution to ship Gnome 2.8, on the day of its release - be the first on your street to try it out!
<mako> fabbione: i didn't edit that part.. :)
<mako> Kamion: right
<Kamion> that maybe needs rewording now
<mako> i should edit that part :)
<mdz> mako: I think we should tone down the bit about xfree86 hardware support; fabbione will correct me if I'm mistaken, but we have done more work to correctly detect and configure for the hardware than adding support for devices which were not supported previously
<fabbione> mdz: correct
<fabbione> we improved some drivers
<fabbione> that's true, but after preview I pushed the drivers to debian too
<justdave> where is says "Firefox 0.9" it might be worth pointing out that we've applied security patches.
<mako> mdz: i've already don this
<fabbione> tho not all of them are up in the archive yet
<justdave> otherwise everyone's going to ask
<mdz> mako: the copy I'm looking at on the wiki still says " Our XFree86 packages have been updated to support plenty of new hardware."
<mako> mdz: right.. i am making all of these changes and then will save the new page
<mdz> ah, ok
<daniels> how about 'we have an absolute arseload of patches to XFree86 4.3, and the first person to ask about X.org gets ti maintain 4.3 in the meantim' ;)
<daniels> god, my typing is terrible, and I'm not celebrating
<mako> ok, there's a batch of changes
<mdz> mako: looks pretty good
<mdz> mako: we need to make sure to update /download/ before this goes out
<mako> mdz: yes
<mako> saf
<mako> sabdfl: have at it: http://wiki.ubuntulinux.org/WartyWarthog_2fRCAnnouncementEmail
<sabdfl> mako: i'm going to take out a bit of the hype in the announcement
<sabdfl> and warm it up a little with some warthogs humour
<elmo> yes, please make sure /download/ points at releases.$distro.$tld
<mdz> snort, snort
<mako> sabdfl: sounds good :)
* thom remembers to beat elmo with the "including -n in rsync command lines is bad, mmmkay?" stick
<Kamion> sabdfl: looked at http://releases.ubuntu.com/ and rsync releases.ubuntu.com::releases/ this morning?
<daniels> -n?
<thom> daniels: dry-run
<elmo> feature ;-P
<justdave> is there any significance to the installer coming up with a red background?
<Kamion> justdave: buglet in bogl
<justdave> it was blue on the iBook...
<thom> elmo: suuuure
<justdave> just booted it on the G4 and it's red. :)
<sabdfl> Kamion: looks almost too good to be true... where are the -current- files hidden?
<pitti> justdave: does it show any error? This is the normal background of error messages...
<Kamion> justdave: haven't seen that on any of my machines for months
<Kamion> sabdfl: .pool; they get magically hidden over HTTP apparently, which is ideal
<justdave> pitti: no error.  just the screen asking for my language
<Kamion> sabdfl: look using rsync and you'll see them
<sabdfl> love it when a plan comes together :-)
<Kamion> I'm hoping it'll actually work in practice :)
<Kamion> when we release the RC, I update the .pool/warty-* hardlinks and rename the warty/warty-* symlinks
<justdave> This is the same machine that the non-smp kernel was hanging on when booted from the hard drive.
<justdave> perhaps the installer knows something it isn't telling us :)
<Kamion> justdave: it's probably a framebuffer palette glitch
<Kamion> justdave: what kind of graphics hardware is it?
<justdave> it's stayed red the whole time, for everything.
<justdave> Nvidia something or other
<Kamion> maybe it's an ati vs. nvidia issue then; I haven't seen that on ATI for a long time
<justdave> yeah, the iBook is ATI, it was fine
<Kamion> will note for future reference
<daniels> bongbongbong
<pitti> mdz:  Just finished iBook installation. Went without the hitch, just the AltGr key (for {}[] @ etc.) still does not work
<daniels> the acx100 won't associate with the AP, but if I disable my laptop's wifi long enough (atheros), it will associate just fine, then the laptop associates too, and they all play nicely together.
* daniels boggle.s
<pitti> mdz: otherwise, nice install experience :-)
<doko> pitti: same here
<fabbione> doko, pitti: which version of X did you get?
<doko> today's CD
<pitti> fabbione: the one on 12.3 cd
<justdave> either a lot of the install is CPU intensive, or the iBook has a sh***y hard drive in it.
<fabbione> doko, pitti: dpkg -p xserver-common
<fabbione> i need to be sure
<pitti> fabbione: 6ubuntu24
<fabbione> pitti: which keyboard layout did you get?
<pitti> fabbione: gar, I never noticed this since usually I mount my shared /home
<fabbione> and which keyboard model?
<pitti> fabbione: but my ~/.bashrc has an xmodmap call
<pitti> fabbione: shall I look in the gnome setting?
<daniels> gnome will override it by calling setxkbmap
<pitti> fabbione: I want German with nodeadkeys, pc105
<fabbione> pitti: no. i want to know what's in the config and what happens if you remove that call
<pitti> daniels: but the xmodmap call worked fine; I already forgot about it
<doko> fabbione: 6ubuntu24
<doko> this works: http://www.mathematik.uni-marburg.de/~schmidtm/apple/Xmodmap
<pitti> fabbione: I installed this one without my /home, it's absolutely clean
<fabbione> pitti: on ppc you should get pc105
<fabbione> i fixed that with ubuntu24
<pitti> fabbione: XF86Config-4 says pc105, de
<doko> fabbione: yes pc105 is configured
<fabbione> so that's correct
<fabbione> pitti, doko: check gnome at this point
<pitti> fabbione: AltGr should be on the Option (Apple) key, right?
<fabbione> pitti: i don't know.
<fabbione> i don't have any kind of ppc at home
<pitti> fabbione: at least that's where I use to have it
<fabbione> pitti, doko: i have o rely on info coming from you guys
<pitti> fabbione: gnome says german, generic 105-key (Intl) PC
<justdave> phase 1 complete, rebooting
<justdave> hey, it boots. :)
<mdz> justdave: is this the box that doesn't boot with a non-smp kernel?
<justdave> yes.
<justdave> and it's booting
<fabbione> bah gnome should stop playing with xmodmad & Co.
<justdave> I noticed a new kernel up yesterday before getting the new cd images, hadn't had a chance to try it yet
<mdz> justdave: the recent kernel changes have been unrelated to ppc
* fabbione KICKS BUGZILLA!!!!!
<justdave> there seemed to be no real pattern to it before...  so perhaps I just got lucky this time.
<fabbione> Internal Error
<fabbione> Bugzilla has suffered an internal error. Please save this page and send it to justdave@canonical.com with details of what you were doing at the time this message appeared.
<fabbione> URL: https://bugzilla.ubuntu.com/process_bug.cgi
<fabbione> Form field knob was not defined; this may indicate a bug in your browser. Check that the "Leave as..." radio button was selected. 
<fabbione> justdave: one hour of test report gone to hell
<mdz> fabbione: check /proc/kcore
<doko> hmm, the left and the right apple key show the same keycode with xev (115, Super_L)
<fabbione> mdz: locking seems to be working
<justdave> reloaded the form before you submitted?
<mdz> fabbione: really? with portmap listening on localhost only?
<daniels> fabbione: gnome/kde doesn't touch xmodmap
<fabbione> mdz: yes
<justdave> the radio button selection goes away when you hit reload I noticed.
<daniels> they use setxkbmap
<mdz> justdave: yes, very frustrating
<fabbione> justdave: i only hitted "reply" to a comment
<justdave> which seems really stupid, but that's what it's doing.
<pitti> justdave: yep, this killed more than one report text for me
<fabbione> mdz: if using /var/lib/dpkg on nfs is the test.. than yes.. it's working
<justdave> I've been bit by it a few times myself.  Maybe we should just live with a huge dropdown box and kill the component selector.
<mdz> fabbione: check strace to be sure
<pitti> daniels: as I said, with the xmodmap call in ~/.bashrc everything went fine
<justdave> that's the only real difference between us and mozilla.org and redhat.com, and they don't seem to have this problem
<mako> sabdfl: looks nice
<sabdfl> mako: still tweaking
<sabdfl> Kamion: what's the rsync line to give mirrors for the "iso only" mirror?
<fabbione> access("/var/lib/dpkg", W_OK)           = 0
<fabbione> open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0660) = 3
<fabbione> fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, 0xbffff8d0) = 0
<fabbione> fcntl64(3, F_GETFD)                     = 0
<fabbione> fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
<fabbione> open("/var/lib/dpkg/status", O_RDONLY|O_LARGEFILE) = 4
<fabbione> fstat64(4, {st_mode=S_IFREG|0644, st_size=2309977, ...}) = 0
<fabbione> mdz: looks very very good!
<mdz> fabbione: yes, very interesting
<mdz> I wonder if lockd just listens on a standard port
<fabbione> mdz: let me check
<pitti> doko: did you file a bug for this altgr thingy? I cannot find it in bz
<fabbione>     100021    3   tcp  32768  nlockmgr
<fabbione> netstat -an | grep 32768
<fabbione> tcp        0      0 0.0.0.0:32768           0.0.0.0:*               LISTEN     
<fabbione> udp        0      0 0.0.0.0:32768           0.0.0.0:*                          
<fabbione> it's listening on everything, but portmapper is only on localhost
<mdz> fabbione: do you actually see traffic to 32768?
<fabbione> mdz: i didn't check
<fabbione> let me see
<doko> pitti: the same keycode?
<fabbione> mdz: i don't see any traffic
<mdz> fabbione: did you try unmounting and remounting?
<mdz> maybe it checks when mounting if lockd is there, and disables locking if not
<fabbione> no. i did try only using the partition/installing a package
<fabbione> hold on
<pitti> doko, fabbione: argh, now even my xmodmap call does not work any more
<pitti> doko: what do you mean?
<doko> pitti: ugh, the eject button is mapped to Super_R (116)
<fabbione> mdz: hmmm
<fabbione> actually
<fabbione> there is something wrong in my test
<fabbione> mdz: locking is done by the server...
<mako> mdz: i think i'm going to crash for some period of time.. is it important for me to resurface at a given time? sending an announcment, etc?
<doko> pitti: I just discovered the altgr thing, so no bug report yet.
<fabbione> and clearly the server doesn't work if you don't let portmap to listen on the iface
<pitti> doko: oh, I thought you were the one who filed it
<mdz> mako: I can send off the announcements
<fabbione> mdz: so once you open portmap you also open lockd (if running)
<mako> mdz: alright.. bcc lwn@lwn.net :)
<fabbione> mdz: mine were clientside tests :/
<mako> i should be up in a few hours
<fabbione> mdz: i did only a simple test on the server for mounting/umounting
<mako> and i can just resent bounce where necessary
<mako> night then.. don't hesitate to call/sms if necessary
<justdave> mdz: yup, just got lucky.  rebooted and it hung
<justdave> 2nd try it booted
<sabdfl> mako: early please, this will likely go out around 1200 UTC
<sabdfl> which is *early* NYC time
<daniels> sabdfl: http://www.ubuntuforums.org/viewtopic.php?p=790
<justdave> ok, confirmed, the component selector is what's breaking the cache somehow...  the Websites product doesn't use it, and Websites bugs don't lose their cache when you hit back.
<mdz> going to try to sleep for 20-30 minutes
<daniels> mdz: sleep well
<fabbione> mdz: portmap is ok for me if you want to upload it
<rburton> pitti: i replicated the ipod eject hang and got something maybe useful
<pitti> rburton: I just read your bug followup, nice
<rburton> ah just the man
<rburton> hi seb128!
<pitti> Hi seb128!
<seb128> hey rburton & pitti & everybody else :)
<rburton> seb128: so gnome and my keyboard disagree until i add an option which claims to be the default.  should X add it magically?
<rburton> (the "super is mapped to win keys" option in the keyboard capplet)
<fabbione> rburton: X doesn't configure or set any default in gnome
<seb128> rburton: is that the "altwin:super_win" option ?
<rburton> seb128: yes
<fabbione> and it will never do that
<rburton> fabbione: the gnome xkb stuff
<seb128> rburton: Denis Barbier said we should add this in the XFConfig86-4 by default yeah
<fabbione> rburton: " should X add it magically? "
<rburton> fabbione: i meant X configuration, on a pc105 keyboard
<fabbione> seb128: reference please?
<Kamion> sabdfl: releases.ubuntu.com::releases/
<seb128> fabbione: private mail in french when I mailed him about #1390 
<fabbione> jeeeeeeee
<seb128> I'm checking 1390 but I think that's in the bug report
<daniels> rburton: yo
<daniels> seb128: sup
<seb128> comment #16
<rburton> yo yo daniels
<seb128> "Setting altwin:super_win option should do the trick.  The problem is that GNOME components are XKB-unaware, so modifiers have to be bound to real keys.  Adding this option by default in a GNOME environment is surely a good idea."
* rburton bops along to Liquid Swords
<seb128> hey daniels
<rburton> seb128: gnome claims altwin:super_win is the default, i take it that is wrong
<fabbione> "Adding this option by default in a GNOME environment is surely a good idea"
<fabbione> seb128: that doesn't tell me it needs to be set in X
<seb128> we are in a GNOME environment -> we should add it in the xfree config
<fabbione> a good idea also doesn't mean that it won't break the hell...
<fabbione> what happens for users that use some other settings?
<fabbione> what are the regressions at 7 days from final?
<seb128> no idea sorry, I don't know a lot about xfree xkb stuff
<daniels> if it's a good thing to have for GNOME, why not add it in the gnome keyboard manager?
<justdave> woohoo
<daniels> i'm also not so white-hot keen on changing it in X
<justdave> cache problem is gone on bugzilla
<justdave> found it finally
<daniels> especially given the amount of seemingly unrelated shit that breaks every time someone touches XKB
<fabbione> daniels: agreed
<rburton> wimps! ;)
<daniels> it's been a nightmare for us so far, and I'm extremely reluctant to touch it, *except* to fix the reversion from ubuntu19
<fabbione> sooner or later we will get bugs like: Why my Xserver installation didn't detect my wifi WEP key encryption at 4096 bit automatically? ;)
<daniels> hahaha
<rburton> quick question -- if i have the nvidia drivers loaded, will hotplug detect and load the nvidia module or should i add it to /etc/modules?  i'm doing the latter atm
<daniels> and it will be traced back to super_l not being a modifier in xkb or some bong like that
<fabbione> rburton: the latter
<pitti> doko: #2327, you might want to CC on it
<rburton> fabbione: ok, thanks
<daniels> shouldn't the X driver load the kernel module automatically?
<fabbione> rburton: can you do a test for me?
<fabbione> daniels: no it doesn't
<rburton> fabbione: sure
<daniels> bonnnng.
<fabbione> rburton: downgrade to xlibs ubuntu23 and cp -rp /etc/X11/xkb* somewhere
<fabbione> install ubuntu24
<fabbione> and send me the diff between the 2 dirs
<fabbione> i am curios if something that we can catch easily
<rburton> where can i get ubuntu23 from?
<pitti> rburton, daniels: you can set IGNORE_PCI_CLASS_DISPLAY to false in /etc/default/hotplug, then the module should load automatically
<fabbione> hmmmm nowhere i guess
<pitti> doko: Hi! I just submitted #2327, you might want to CC on it
<rburton> pitti: sweet
<pitti> rburton: it wasn't Unix if it worked without configuration :-/
<fabbione> elmo: can we get xlibs ubuntu23 from the "deb cemetary"?
<elmo> fabbione: jackass/morgue from within the lan
<elmo> I'll work on making it more publicly available, but for now, you can grab what you need, I guess
<fabbione> elmo: thanks
<sabdfl> elmo: what's the rsync location for the "minimalist iso-only" mirror?
<doko> pitti: ok, digging me through /etc/X11/kbd ...
<elmo> sabdfl: <Kamion> sabdfl: releases.ubuntu.com::releases/
<sabdfl> elmo, kamion, thnaks
<sabdfl> er..
<sabdfl> thanks
<fabbione> rburton: http://people.ubuntulinux.org/~fabbione/23_to_24.diff
<fabbione> that's the diff from u23 to u24 of /etc/X11/xkb*
<fabbione> rburton: mind to look and see if you spot something that might have changed the behaviour
<rburton> ok
<daniels> elmo: i assume that's http://jackass/morgue/ ?
<elmo> yes
<fabbione> pitti: if you revert to xlibs ubuntu23 does it work?
<doko> fabbione: xserver-common only?
<fabbione> doko: xlibs_ only
<fabbione> and of course you must restart X
<fabbione> if you don't have the old version you can grab it here;
<fabbione> http://people.ubuntulinux.org/~fabbione/
<fabbione> ah bah.. you are on ppc
<doko> fabbione: wait, I can't type ~ on the powerpc :-(
<fabbione> doko: you will have to grab it from the morgue in case
<pitti> doko: you can do it on the text consoles
<pitti> doko: just use alt, alt and command are swapped there
<fabbione> nevermind.. the package is _all.deb
<pitti> fabbione: I installed your xlibs deb, restarted gdm, no change
<pitti> fabbione: even the xmodmap call does not work
<daniels> elmo: have you broken rsync on auckland recently? :)
<daniels> elmo: nevermind
<sabdfl> jdub_: i have widescreen images too
<sabdfl> coming up by mail
<fabbione> pitti: since how long you didn't restart X?
<pitti> fabbione: 5 minutes
<fabbione> pitti: you will have to go trough the morgue and figure from which version to which version the call to xmodmap is broken
<pitti> fabbione: okay. Where is the morgue?
<fabbione> pitti: no. i mean.. you noticed with ubuntu24.. what was the last version that was working?
<fabbione> pitti: http://jackass/morgues from within the lan
<fabbione> pitti: also.. if you call xmodmap from within X
<pitti> fabbione: ugh, I just overwrote that one by today's installation :-(
<fabbione> instead of .bashrc, does it work?
<pitti> fabbione: I tried to call it manually in a gnome terminal
<fabbione> pitti: xterm please
<fabbione> gnome-terminal might do fancy things
<pitti> ugh, xterm has an uuuugly font
<pitti> fabbione: nope
<fabbione> pitti: i don't really care about fonts here :P
<sabdfl> jdub_: widescreen images are on their way to you now, a biggish email so let me know if it's not there in 5
<pitti> fabbione: ubuntu22 was uploaded Sep 27, I definitively reinstalled the iBook after this date
<pitti> fabbione: I'm pretty sure I had ubuntu22 before
<|trey|> pitti: what are you refering to as ubuntu22?
<pitti> |trey|: the X server
<jdub_> sabdfl: backgrounds, or...?
<|trey|> package?
<fabbione> pitti: than please grab ubuntu22
<pitti> fabbione: don't get me wrong, the xmodmap call does not need to work if I can get AltGr by other means
<pitti> fabbione: okay, I'll do
* |trey| wants to know what ubuntu22 entails  :(
<fabbione> pitti: xmodmap should work
<pitti> fabbione: xlibs is sufficient?
<fabbione> i need to know when X broke
<fabbione> pitti: yes
<fabbione> pitti: also.. before the default was "macintosh" and not "pc105"
<fabbione> pitti: so you need to double test it
<fabbione> once with pc105 once with mac
<pitti> fabbione: okay
<fabbione> pitti: btw.. next time buy an i386.. it has better support :P
* fabbione hides
<pitti> fabbione: I have an i386
<pitti> fabbione: but I really like my ppc, in particular because it is a different platform to test things :-)
<pitti> fabbione: ubuntu2[34]  with macintosh does not work
<pitti> fabbione: http://jackass/morgues does not exist
<fabbione> pitti: morgue
<pitti> fabbione: I already tried that
<fabbione> from within the LAN
<pitti> Hi mvo!
<pitti> fabbione: I tried from chinstrap
<fabbione> pitti: i took ubunut23 out of that
<mvo> hi pitti !
<fabbione> wget http://jackass/morgue/
<fabbione> pitti: from roockery
<fabbione> same from chinstrap
<pitti> fabbione: ERROR 404: Not Found.
<fabbione> add the / at the end
<pitti> fabbione: thanks, that was it
<pitti> fabbione: just installed xlibs ubuntu22, same result
<pitti> fabbione: do I have to regenerate some keymaps or delete something from my ~?
* pitti tries with a fresh user
<fabbione> pitti: nothing to regenerate
<fabbione> pitti: just be sure to kill X
<pitti> fabbione: I restarted gdm completely
<fabbione>  /etc/init.d/gdm stop/start
<fabbione> ok
<pitti> fabbione: I'm absolutely sure that this worked until yesterday
<fabbione> pitti: good point.. try with a fresh user
<fabbione> pitti: there have been some gnome updates too
<fabbione> i can't guarantee if something else broke down
<fabbione> gnome takes over keyboard stuff
<pitti> fabbione: BTW, now it asks me whether to use the GNOME or the X settings. Does not make any difference, though
<fabbione> and it does not make things simpler
<fabbione> pitti: yes it does
<fabbione> use the X settings :-)
<fabbione> so we will isolate the problem
<pitti> I did :-)
<fabbione> kill the user... use the gnome settings
<fabbione> and see what happens
<pitti> argh, my test user cannot login with a completely empty ~
<pitti> fabbione: fresh test user with xlibs ubuntu22: same result, xmodmap does not work
<pitti> fabbione: this must be a gnome thingy
<fabbione> pitti: than something else is changes
<fabbione> changed even
<pitti> fabbione: shall I beat up seb128 then?
<fabbione> pitti: can you revert to ubuntu18?
<pitti> fabbione: I can
<fabbione> pitti: please do
<fabbione> and remember to cleanup the ~ of the user from the gnome crap
<pitti> fabbione: same result. Shall I try in twm, or so=
<pitti> fabbione: s/=/?/
<sabdfl> what's the best url to point people at for an introduction to linux that's vendor neutral?
<sabdfl> for our default home page
<pitti> fabbione: doesn't work in "Terminal" session either :-(
<thom> sabdfl: http://www.linux.org/ isn't so bad
<pitti> fabbione: startx with 'exec xterm' in ~/.xsession still does not work. This is the most basic and close-to-X method I know
<pitti> fabbione: maybe it is some other X package apart from xlibs?
<fabbione> pitti: i doubt.
<fabbione> pitti: the xkb stuff is only in xlibs
<fabbione> but manly we changed xlibs and xserver-*
<fabbione> so you can try a combination of them
<fabbione> but nothing is changed that cannot load .xsession or similar
<fabbione> i am 1000% sure about it
<pitti> fabbione: I try to purge and reinstall the xlibs first
<pitti> fabbione: by now I just downgraded
<pitti> DAMN
<thom> seb128: gnome weather applet is missing just about all the locations barring noirth american and mid east
<fabbione> pitti: do you have an old sounder cd?
<pitti> thom, seb128: I reported this as #2325
<pitti> fabbione: no, I rsync them every day :-( 
<pitti> fabbione: and my previous CD-RW broke this morning
<pitti> fabbione: not the best day today, I guess
<fabbione> yeah there have been no sounders for a while
<seb128> thom,pitti: I've just upload a fixed package for the weather
<elmo> Oct 13 11:33:12 mirnyy postfix/master[6882] : fatal: /etc/postfix/master.cf: line 84: bad hostname or network address: ::1
<seb128> in fact that's in upload
<fabbione> pitti: without these info there is really nothing i can do
<elmo> uh.. does that mean our postfix config breaks on kernels without ipv6 or am I being stupid ?
<seb128> uploaded
<pitti> fabbione: I try to revert to xserver-xfree86 ubuntu18
<fabbione> elmo: lamont fixed that a while ago
<elmo> fabbione: I just purged and reinstalled postfix - same thing?
<pitti> fabbione: YEAH! It works with xserver-xfree ubuntu18!
<pitti> fabbione: that's something for a start
<pitti> fabbione: I will slowly upgrade to the recent versions and isolate the problematic package
<sabdfl> jdub_: looks great, needs a tweak or two
<sabdfl> on 1024x768, the shoulder at the bottom is clipped
<sabdfl> need to shift that image up a few pixels
<fabbione> elmo: hold on a sec.. i can't remember in which version it has been fixed
<fabbione> elmo: postfix (2.1.1-4) unstable; urgency=low
<fabbione> or higher
<jdub_> sabdfl: that's going to be a design co. thing if anything
<jdub_> hrm, guess it can be done underneaththe blue bar
<fabbione> pitti: what does work with ubuntu18? the alt+gr or the xmodmad command?
<pitti> fabbione: without any xmodmap invocation the Option key at least does something; it prints other characters (though the wrong ones)
<jdub_> sabdfl: trouble is, it's all relative
<pitti> fabbione: if I issue the xmodmap command then, it works correctly
<pitti> fabbione: I already upgraded the xlibs to the most recent version, still works
<pitti> fabbione: now I upgrade the xserver to 22, 23
<pitti> fabbione: I write this up as bug followup
<sabdfl> jdub_: ok, we'll ship it as is. i think it looks FANTASTIC
<fabbione> pitti: ok...
<sabdfl> need to test quickly on much bigger screen, and widescreen
<jdub_> sabdfl: it's going to look like horseshit on widescreen
<jdub_> sabdfl: and without having non-bleed images (as suggested), we can't make it otherwise at this stage
<jdub_> sabdfl: i mailed you about this and the logo issue last week
<sabdfl> asking for non-bleed images on the morning of the release is horseshit :-)
<sabdfl> didn't see it, didn't hear anything else from you
<sabdfl> anyhow, nuff said, let's get it wrapped
<sabdfl> what's the logo issue?
<jdub_> the bottom right logo could be a separate image, to avoid mushing stuff over it (blue bar)
<jdub_> ideally, each image component would be separate
<jdub_> we can compose them flexibly in the theme
<jdub_> (if the people were separate, and it didn't bleed, we could have those hanging on the left, etc)
<sabdfl> jdub_: Oops.
<sabdfl> the calendar image (non-ws) needs an update, in mail to you now
<thom> hrmph, who forgot to add amd64 to architectures lists for mono?
<pitti> fabbione: ugh, this is a tricky one. I followed up in bz
<fabbione> pitti: that can't be possible
<sabdfl> Kamion: status update
<pitti> fabbione: I tried two times
<sabdfl> jdub_: Kamion: i'm finishing up skinning the new default home page with limi
<pitti> fabbione: purge xserver, isntall 24 -> does not work; install 23, upgrade to 24 -> works
<sabdfl> should be done in about 20 minutes
<fabbione> pitti: it would be interesting to know if starting from ubuntu18 to ubuntu24 there are leftovers from one installation -> upgrade to the other
<sabdfl> to whom should i send the files?
<jdub_> sabdfl: me, so they can go in ubuntu-artwork
<pitti> fabbione: maybe 23 installs some files which are necessary?
<fabbione> but if you can reproduce it with u23.. the latter woulb ok
<pitti> fabbione: what is the other?
<sabdfl> elmo: i still see no warty-security for multiverse?
<jdub_> sabdfl: have the firefox and epiphany packages been modified to suit?
<sabdfl> jdub_: no afaik
<fabbione> pitti: i would check all the Xserver files and /etc/X11
<sabdfl> thom: offline homepage is incoming
<pitti> fabbione: with debdiff?
<fabbione> pitti: but that's why we have a MANIFEST check
<fabbione> no. on the real installation
<jdub_> sabdfl: offline homepage goes in ubuntu-artwork
<jdub_> sabdfl: the browser packages just need the home location changed
<fabbione> pitti: the MANIFEST file would fail if files are added or removed without specific integration
<sabdfl> jdub_: yes, understood
<thom> cool. goes in u-a, ffox depends on it and changes home location
<thom> goodo
<sabdfl> thom: will you handle the firefox upload?
<sabdfl> who will do epiph?
<jdub_> i can
<pitti> fabbione: so I diff -Nru /etc/X11 between the two possibilities (install from scratch and upgrade)?
<fabbione> pitti: that's the first thing i would do
<jdub_> thom: i'm thinking /usr/share/doc/ubuntu-artwork/home/index.html -> yeah?
<fabbione> pitti: take into account the diff i posted to people/~fabbione
<fabbione> pitti: there are updates in ubuntu24
<fabbione> pitti: but it doesn't explain why upgrading works and installing from scratch no
* jdub_ wilts in the heat.
<pitti> fabbione: no, I meant: I isntall 24, save /etc/X11; then it install 23, upgrade to 24, save /etc/X11 and then compare
<pitti> fabbione: so theoretically there should be no differences
<fabbione> pitti: oh right
<thom> jdub_: looks sane
<fabbione> pitti: yes theoretically no difference
<Kamion> jdub_: /usr/share/doc sounds bad
<Kamion> I'd go for somewhere in /var
<Kamion> or /usr/share/ubuntu-artwork/home/index.html maybe
<thom> Kamion: /usr/share/u-a no?
<thom> yeah
<jdub_> yeah
<Kamion> right
<thom> sorry, didn't see the doc/ originally
<fabbione> pitti: are you still testing with startx only or are you involving gnome too?
<pitti> fabbione: with startx because it is faster, but I checked also with gnome
<fabbione> pitti: ok
<thom> jdub_: what's the version of ubuntu-artwork you're uploading?
<jdub_> 0.2.11
<jdub_> -1
<elmo> sabdfl: added - it'll be in the next cron.daily
<pitti> fabbione: odd, the only difference is XkbModel pc105 (install from scratch) vs. XkbModel macintosh (upgrade); seems it does have to do with this change after all...
<pitti> fabbione: I think I tested the keyboard layout change only in Gnome, not in Terminal session
<thom> jdub_: building now
<fabbione> pitti: is gnome aware of tXkbModel ?
<fabbione> pitti: or it doesn't care?
<pitti> fabbione: I don't know
<fabbione> pitti: if you revert pc105 to macintosh in ubuntu24, does it work?
<fabbione> (on a fresh install)
<pitti> fabbione: I'm right at trying this
<pitti> fabbione: yes, works
<pitti> fabbione: puuh...
<pitti> fabbione: so changing macintosh to pc105 breaks xmodmap in pure X
<fabbione> pitti: at this point you and carlos and canonical have to agree of what XkbModel you want for ppc
<pitti> fabbione: now I try with gnome
<fabbione> otherwise i must ask
<pitti> fabbione: hm, macintosh always worked fine for me; is it possible to fix xmodmap in pc105?
<pitti> fabbione: OTOH, maybe the Option key just has another keycode in pc105
<pitti> by now I use 73, but I can find that out with xev, right?
<fabbione> pitti: i have no idea....
<fabbione> pitti: yes you can check with xev
<pitti> fabbione: nope, it's the same keycode and xmodmap still does not work
<pitti> fabbione: also, with macintosh Option+key prints another character, but with pc105 it does nothing
<fabbione> pitti:  1690
<fabbione> either is pc105 or mac by default
<fabbione> pitti: there is no much time to figure out what to do
<fabbione> my suggestion to reintroduce the question for ppc had a negative consensum
<pitti> okay, as expected it works with installing from scratch, changing back to macintosh and using the X keyboard settings
<fabbione> ok
<fabbione> we found a weird debconf bug
<fabbione> db_set template/foo
<fabbione> db_go
<fabbione> (question is not shown(
<fabbione> db_get template/foo
<fabbione> it returns the default and not what it has been set?
<fabbione> and nobody ever noticed before?
* Mithrandir waves
<fabbione> + db_set xserver-xfree86/config/monitor/mode-list '1152x768 @ 60Hz'
<jdub_> sabdfl: home page was sent...?
<fabbione> + db_input low xserver-xfree86/config/monitor/mode-list
<fabbione> + db_go
<fabbione> + db_get xserver-xfree86/config/monitor/mode-list
<fabbione> + RET=640x480 @ 60Hz
<fabbione> grrr
<Kamion> fabbione: never seen anything like that happen
<fabbione> Kamion: never mind
<fabbione> I just figured
<Kamion> fabbione: is xserver-xfree86/config/monitor/mode-list a select list?
<Kamion> if so, is that value in its list of choices?
<fabbione> Kamion: exaclty
<fabbione> where is the PENDING upload status???
<daniels> PENDINGUPLOAD
<Kamion> uh, are we getting a new X upload before the RC?
<fabbione> Kamion: probably yes
<daniels> mdz has stated it's frozen
<Kamion> isn't that a bit risky?
<daniels> but I would really like to see one
<daniels> yeah
<fabbione> sabdfl: you around?
<daniels> also, by the time all the buildds pick it up, and it hits the archive ...
<daniels> mdz: ^^
<Kamion> it'll take ages; I thought we were just waiting for ubuntu-artwork
<sabdfl> fabbione: yes
<fabbione> sabdfl: we have a problem with XkbModel for ppc
<sabdfl> fabbione: ok
<fabbione> it's a 50% 50% bet...
<sabdfl> critical?
<sabdfl> 50/50 it's fixed with the upload?
<daniels> sabdfl: neither of us have Powerbooks
<fabbione> sabdfl: well basically either we make happy 50% of the ppc users or the other 50% of the ppc users
<sabdfl> fabbione: can we get it 100%, in the next hour?
<sabdfl> how the hell did we miss half the ppc world till now?
<fabbione> sabdfl: i can make them almost happy, but that means reintroducing a question for X during ppc (only) installation
* Kamion wonders when the hell he's going to sleep today
<fabbione> sabdfl: because i don't have 2 ppc to test on ;)
<fabbione> sabdfl: either i fix it for final
<fabbione> or Kamion will not go to sleep today
<fabbione> hounestly i would prefer for final
<sabdfl> ok, this is rc, we can't make it final
<sabdfl> pity
<sabdfl> so kamion, please just wait for artwork and firefox default home page and SHIP IT!
<sabdfl> erm, mdz?
<sabdfl> getting ahead of myself there
<pitti> fabbione, sabdfl: if you want to introduce a question, you can as well point the users to dpkg-reconfigure xserver-xfree86 afterwards
<sabdfl> mdz?
<Kamion> we still need that portmap fix for final anyway
<pitti> fabbione, sabdfl: I don't think that the AltGr issue is RC, it can easily be fixed
<sabdfl> oh, ok, i though we had a good chance for this to be final
<sabdfl> sorry
<sabdfl> i guess mdz is still crashed
<pitti> fabbione, sabdfl: and if you ask the question on installation, users can only gamble and guess anyway
<fabbione> pitti: it is RC if you can't type half of the chars on your keyboard
<sabdfl> pitti, fabbione: is this not something we can autodetect?
<Kamion> mdz/fabbione had a fix-candidate for portmap, but it hasn't yet been uploaded
<fabbione> sabdfl: no unfrotunatly
<fabbione> Kamion: i only did the tests. mdz has the source
<pitti> sabdfl, fabbione: please be aware that AltGr _never_ worked on ppc, also not with previous versions
<sabdfl> but it's only ppc users that get asked the question?
<fabbione> Kamion: the patch is in bugzilla
<Kamion> 09:39 < mdz> going to try to sleep for 20-30 minutes
<fabbione> sabdfl: yes
<Kamion> he might have overdone it
<sabdfl> wel, he deserves it
<Kamion> yeah
<sabdfl> and it's not critical since we're definitely not going final today
<sabdfl> ok, let's get this sucker on the wire
<sabdfl> jdub_: got the default home page?
<sabdfl> thom: fixed firefox?
<pitti> fabbione: if you ask the question, can you make sure that the xmodmap modification is done by default? Otherwise it makes no sense since you need the xmodmap to get a workign keyboard
<thom> sabdfl: building currently
<jdub_> sabdfl: just then
<jdub_> sabdfl: can't see any errors - can i s/Gnome/GNOME/ ?
<sabdfl> jdub_: sure
<pitti> fabbione: the best thing IMHO would be to make xmodmap work for pc105, but I don't know whether this is possible
<fabbione> pitti: how can i set that option within the X config?
<pitti> fabbione: you mean like the extra options, win:altgr or so?
<fabbione> yes
<pitti> fabbione: I never found a solution for this, there is just no altgr modifier
<jdub_> sabdfl: btw, are we meant to be referring to it as 'Ubuntu' everywhere, despite the website url? the first sentence is 'Ubuntu Linux is...'
<pitti> fabbione: I needed something like Apple:AltGr, or Option:AltGr
<pitti> fabbione: BTW, the Apple key is recognized as Super_L
<sabdfl> jdub_: that's planned
<fabbione> pitti: if you know how to do it.. let's do it.. otherwise i will only ask to confirm the Model
<sabdfl> we need a little Linux here and there at the moment
<sabdfl> can drop it later
<jdub_> ok
<pitti> fabbione: the "otherwise" part does not really make sense---altgr will not work regardless of the selected model
<sabdfl> we'll add a portlet with a good description of ubuntu (spirit of humanity) for final
<pitti> fabbione: there's neither AltGr or SuperL in the available options, so if that should work, new options must be invented
<fabbione> pitti: ah
<fabbione> hmmm
<sabdfl> artwork upload status? firefox status?
<sabdfl> are there test packages I can try please?
<fabbione> pitti: i guess that we will skip the question part than
<fabbione> pitti: people that needs specific configs like yours will have to do it manually for warty
<fabbione> daniels: you around?
<sabdfl> jdub: will get you the gdm image components today, so we can have a new package post-RC thatdoes gdm properly for 4:3 and widescreen
<pitti> fabbione: agreed. We need a faq for the xmodmap part anyway, then we can add the macintosh part as well
<jdub_> sabdfl: great, thanks
<daniels> fabbione: 'sup
<sabdfl> jdub_: is there a test package of what you are submitting to the rc?
<sabdfl> thom: same for firefox?
<jdub_> sabdfl: just building now, will take a bit to upload
<jdub_> sabdfl: i'll mail you the separation reqs
<sabdfl> jdub_: please ping this forum with a url as soon as it's built somewhere so we can test it while kamion builds the cd image
<sabdfl> jdub_: cool
<jdub_> yep
<sabdfl> damn, 1200UTC is in SIX MINUTES
<sabdfl> Kamion: time to build the cd?
<Kamion> um, no :)
* sabdfl searches for faster build system for kamion
<sabdfl> jdub_: eta for artwork for kamion?
<Kamion> the packages aren't even in the archive yet, I need a time machine as well
<sabdfl> thom: eta for firefox?
<rburton> this is getting exciting ;)
<rburton> people all over the world, starting to panic
<sabdfl> rburton: you mean, at RHAT?
<sabdfl> Redmond?
<sabdfl> Cupertino?
<rburton> haha
<jdub_> sabdfl: 5 min
<thom> sabdfl: i can upload it untested
<ehb> my ubuntu installtion cd is unable to mount the cd-rom which is really a crucial bug since I'm stuck 
<daniels> nremberg?
<thom> but it's still building
<Kamion> ehb: which CD?
<jdub_> sabdfl: 6 min
<ehb> the one uploaded the 28th september
<daniels> ehb: what sort of cd-rom drive is it?
<sabdfl> ehb: give us an hour and we'll publish the RC
<daniels> ehb: just a normal ide cd-rom drive?
<sabdfl> pcmcia....
<Kamion> sabdfl: you're optimistic
<ehb> yes normal IDE 
<Kamion> sabdfl: it'll take an hour minimum for builds to arrive in the archive
<sabdfl> OK, so we are at 1500 UTC for release then?
<sabdfl> hour to get builds, hour to make cdimage, hour for slips?
<ehb> Kamion, after trying from source install from cd install also fails, I'm really concidering giving up on ubuntu
<sabdfl> mako: around?
<Kamion> ehb: you've managed to pick a time when we're all flat-out, unfortunately
<jdub_> sabdfl: erm, still around 5 mins to go... .au bandwidth is grrrreat!
<jdub_> ehb: someone on #ubuntu might be able to help you in the mean time
<Kamion> ehb: I'd be inclined to try a current daily build as the first port of call, though
<fabbione> YES!
<pitti> fabbione: I've found it!! I've found it!!!! ;-))
<pitti> fabbione: it works with grp:lwin_switch (in macintosh layout)
<fabbione> i found teh reason why some people had a 640x480 screen!
<pitti> fabbione: day starts to get better, doesn't it? :-)
<daniels> fabbione: why?
<fabbione> pitti: considering that the adsl at my new house isn't working yet... yes
<pitti> fabbione: not everything at the same time...
<fabbione> daniels: we were getting the wrong frequencies. I didn't expect the template to be so... hmmm "empty"
<daniels> fabbione: hm?
<fabbione>       db_input low xserver-xfree86/config/monitor/mode-list || true
<fabbione>       db_go
<fabbione>         db_get xserver-xfree86/config/monitor/mode-list
<fabbione> basically if the resolution is not there we were always getting 640x480 @ 60 Hz as default
<daniels> ah, bong
<fabbione>       db_input low xserver-xfree86/config/monitor/mode-list || true
<fabbione>       db_go
<fabbione>       if [ -n "MAXRES" ] ; then
<fabbione>         RET="MAXRES"
<fabbione>       else
<fabbione>         db_get xserver-xfree86/config/monitor/mode-list
<fabbione>       fi
<fabbione> this is the fix
<daniels> there are some really wack resolutions though
<daniels> like 2777x2700 came up the other day
<fabbione> if MAXRES exists it means that we are still guessing
<daniels> for like some 14" 4:3 LCD
<jdub_> ahr
<jdub_> people.ubuntulinux.org/~jdub/ubuntu-artwork_0.2.11-1_all.deb
<jdub_> ^ check that
<jdub_> sabdfl: ^
<fabbione> so we need to respect the wack resolution or the fact that the results might not be in the template
<sabdfl> jdub_: thanks
<sabdfl> please, everybody bang on that
<sabdfl> thome, please do the same as soon as you have a build
<sabdfl> thom
<daniels> jdub_: changes?
<sabdfl> ^
<fabbione> daniels: that change will fix that problem too
<jdub_> daniels: on-disk home page, gdm screen, splash, backgrounds
<fabbione> daniels: it's pretty generic
<daniels> fabbione: cool
<daniels> jdub_: ahr!
<fabbione>   * Fix a nasty bug in frequencies detection logic to get a better
<fabbione>     clue if the resolution is not in the mode-list template. This fix will
<fabbione>     also catch all the unknown resolutions without projecting the users
<fabbione>     back in time to a 640x480@60Hz view of the world.
<fabbione> daniels: what about the last changes Denis did in SVN about XKB?
<daniels> fabbione: nice
<daniels> fabbione: don't know enough about XKB to comment, really
<fabbione> daniels: i think it is pretty much sane to get them
<daniels> all I can say is that I assume he knows what he's doing
<sabdfl> fabbione: what about daniels concerns that this could give whacked resolutions like 2777x2700?
<fabbione> sabdfl: this change fixes the frequencies detection problem on whatever resolution we get back
<fabbione> sabdfl: specially when the resolution is UNKNOWN and we are guessing
<Kamion> new u-a seems to work on this i386 laptop
<Kamion> wonder how well the gnome-session image will go over
<daniels> fabbione: yeah, but sometimes ddcprobe feeds back resolutions like 2777x2700 because monitors are really really stupid and break ddc
<jdub_> Kamion: mm
<fabbione> pitti: ok.. so if we set XkbModel to macintosh, we need to set grp:lwin_switch?
<pitti> fabbione: with this it works fine, yes.
<fabbione> daniels: well.. that goes behiond my possibilities to fix crap around
<lamont> daniels: but my monitor _works_ with ctiming: 1792x1344@60
<sabdfl> Kamion: what's the best HTTP url to be pointing people at for download now?
<Kamion> is the session splash configurable?
<pitti> fabbione: but grp:lwin_switch does not work with pc105
<fabbione> pitti: what happen if you do that on pc105 layout?
<fabbione> ok
<sabdfl> am editing the web site now
<thom> jdub_: gdmthemetester looks good
<pitti> fabbione: nothing :-) It is essentially the same like the xmodmap call
<lamont> do we have torrent?
<Kamion> sabdfl: can it wait until the RC actually exists? until then I'd like it left at Sounder 9
<jdub_> thom: awesome image
<pitti> fabbione: I don't know anything about the keymap stuff, but I try to add the option to pc105
<sabdfl> kamion: ok.... twitchy trigger finger mark
<daniels> fabbione: that's one of the reasons why I liked the whitelist
<thom> lamont: yes
<daniels> fabbione: could we please get 1792x1344 in the whitelist?
<fabbione> daniels: of which template? 
<sabdfl> thom: is there a place to fetch your build of firefox yet?
<daniels> fabbione: mode-list
<Kamion> jdub_: no preview of Human visible in gdmsetup?
<fabbione> daniels: we have 2 templates for resolutions. one for the pure size of the screen and one for the frequencies
<daniels> fabbione: i think maintaining a whitelist is the best solution imho
<daniels> fabbione: a lot of monitor just give back complete shit in dtiming
<Kamion> it just says "No screenshot available"
<jdub_> Kamion: ah, bong, forgot to add the thumb - thanks
<daniels> like, it looks valid, and you can't pick it from valid stuff, but it's just complete shit
<thom> sabdfl: no, it's still going
<fabbione> daniels: we don't use dtimings anyway
<thom> firefox takes for EVER
<sabdfl> jdub_: that can go in for final, not a new upload now
<sabdfl> thom: where is it building?
<daniels> fabbione: yes we do
<daniels> fabbione: some monitors (quite rightly) only return dtimings
<thom> sabdfl: locally, so i can make sure i got the changes right
<jdub_> sabdfl: haven't uploaded yet
<daniels> fabbione: i think that's been in since about xresprobe 0.4.6 or .7
<fabbione> daniels: that resolution is already whitelisted
<daniels> gdmthemetester here looks great, and I like the theme (although maybe a bit too much nipple), although xnest has gone totally bongtastic
<thom> ok, bored of firefox now
<sabdfl> thom: *legend*ary
<sabdfl> Kamion: many of the mirrors that have been setup are mirrors of the huge full tree
* thom wonders if it'd go faster if he got out and pushed
<sabdfl> is there a directory in there which has the same simple structure as the shiny releases dir you setup last night?
<jdub_> thom: i'll start calling you princess...
<Kamion> sabdfl: no, was worried about the rsync implications of that
<Kamion> not to mention confusion ...
<sabdfl> Kamion: could be constructed purely of symblinks?
<Kamion> can't we just do README.html as previously discussed?
<jdub_> symbling!
<daniels> bling!
<Kamion> the link structure on little is getting way out of hand already
<sivang> jdub : you've got my draft for the offline page?
<sabdfl> Kamion: this will allow me to link from the download page straight to that directory on the major mirrors
<jdub_> sivang: yes, mark has checked and updated it
<jdub_> sivang: thanks
<thom> extensions/webservices/soap FFS
<sabdfl> it meas that someone doesn't have to find the image in that huge tree
<sabdfl> symlinks only means rsync implications are tiny
<thom> i wish SOAP would burn in the utmost fires of hell
<Kamion> my head hurts thinking about this
<Kamion> OK, I guess. it's still a totally fucked-up mess now though.
<sabdfl> could we create it at the very top, next to pool etc?
<sivang> thom, I am not sure if soap is flameable... :)
<Kamion> what can we call it? releases is taken
<sabdfl> as /releases/
<Kamion> that's taken
<sabdfl> i don't see it anywhere on the big mirrors
<Kamion> I'm looking at it right here
<sabdfl> http://mirror.clarkson.edu/pub/distributions/ubuntu/
<Kamion> sabdfl: that's the archive, not the cdimage tree
<lamont> sivang: with sufficient heat, it'll burn. :)
<sabdfl> that's what some guys are mirroring
<sabdfl> does it not include the cdimage tree?
<Kamion> sabdfl: we can't just force them to grab the cdimages too
<Kamion> not all mirrors will have space for that
<Kamion> no, it doesn't
<sabdfl> ok
<sabdfl> for hoary i figure we want that
<sabdfl> mirrors can be either cdimage or the archive + cdimage
<Kamion> mirrors have a legitimate need to choose between the archive, cdimages, or both
<sabdfl> for one or more architectures
<Kamion> but they already can
<sabdfl> well, with --exclude they would still be able to
<Kamion> I don't think it's at all fair to say that mirrors can't mirror just the archive
<Kamion> that's an incredibly common use case you're cutting off
<sabdfl> Kamion: ok
<sabdfl> but this means that for release, none of those guys have the cd images
<Kamion> right, but that's their choice
<Kamion> if they were interested in that, they'd already be mirroring the preview cdimage, right?
<Kamion> since that's pretty easy to mirror on its own
<sabdfl> do they have the option currently to mirror cdimages and archive in ONE SHOT?
<Kamion> no, but mirrors don't actually want that AFAICT
<sabdfl> i agree they need the option
<sabdfl> but I think they want a single line that does what they want
<Kamion> most distributions have two separate and distinct trees for cdimage and archive
<sabdfl> that's all i'm saying
<sabdfl> we don't want that
<sabdfl> i asked baby je... never mind
<Kamion> I think we need to ask mirror admins before Just Doing it
<sabdfl> agreed
<sabdfl> we won't just do it, we'll plan it during the hoary process
<Kamion> since a lot of them will have disk space constraints and will be very surprised by it showing up out of the blue :)
<sabdfl> my bad, i thought we had this already
<Kamion> ok
<sabdfl> we need a way for them to mirror just releases, cd image, and security updates
<sabdfl> not the development stuff
<sabdfl> not the daily cd builds
<sabdfl> not even the previews
<Kamion> that still leaves the question of what to call the version of the simple tree visible on mirrors that already have the full tree
<sabdfl> we can get together in the hoary process and nail this properly
<Kamion> that sounds like an entirely new rsync module
<sabdfl> well, if they have the full tree by my schema they already HAVE the simple version
<Kamion> currently the full tree has at the top level: code, daily, releases, sounder-test
<hornbeck> the new cd is working great for me
* jdub_ uploads u-a
<sabdfl> as /releases/ with symlinks
<fabbione> pitti: i am building an xserver for you to test
* sabdfl apploads jdub
<sabdfl> um applauds, even
* thom rolls eyes
<thom> dpkg-buildpackage -rfakeroot -uc -us  1412.10s user 209.07s system 37% cpu 1:12:58.53 total
<sabdfl> wow
<pitti> fabbione: oh, nice. Currently I try to find an option combination that works for pc105
<pitti> fabbione: you build for powerpc?
<sabdfl> does this still have to build on the buildd's?
<fabbione> pitti: ah right.. you are on ppc
<Kamion> they've got /releases/warty/preview/ at the moment, etc.
<fabbione> pitti: yes i can do that too
<Kamion> um
<Kamion> where is alex de landgraaf?
<pitti> fabbione: there's no problem on i386, there I have a proper AltGr key
<lamont> sabdfl: if he hasn't uploaded source yet, then, um, yes.
<sabdfl> kamion i think we can go for RC with the new artwork but without the new firefox
<sabdfl> that's just a homepage update
<thom> sabdfl: yup
<sabdfl> artowrk should build really fast
<jdub_> i'm about to do ephy too
<Kamion> ok
<sabdfl> great
<thom> buildds will be much faster tho
<thom> works
<thom> uploading now
<Kamion> a live-i386.iso has suddenly appeared in a directory I was using for testing only and was about to blow away, owned by alex
<sabdfl> lamont: please steer jdub's artowrk package through the buildd's and into the archive blitz-vinnig
<fabbione> pitti: i am going to build on ppc in a few minutes
<fabbione> pitti: i am uploading the diff.gz
<sabdfl> he's not on irc
<pitti> fabbione: did you change anything that could help to make the option work on pc105?
<sabdfl> Kamion: pause on the blowing away :-)
<jdub_> http://www.gnome.org/~calum/img/person-applet.png
<sabdfl> that might just be a godsend... we could get live cd for RC too :-)
<fabbione> pitti: no, if i don't know exactly what to stick in there
<m_tthew> good morning, guys
<Kamion> sabdfl: it'll predate new artwork of course
<m_tthew> Kamion: when I slept it was RCC3, news ones I should test?
<m_tthew> new, even
<pitti> fabbione: I looked in /etc/X11/xkb, but I can't make out how these modifiers are defined and how the keymaps use them
<sabdfl> m_tthew: RC is in process
<lamont> sabdfl: I can gain it a couple minutes is all.
<fabbione> pitti: you need to ask Denis
<lamont> and then only if the build time is >25 min and < 30
<fabbione> pitti: i really really have issues with XKB
<sivang> jdub_ : nice, this already existing? does it plugin to GAIM ?
<sabdfl> lamont: please keep me posted if it bottlenecks anywhere
<pitti> fabbione: Denis? any mail address? or IRC?
<jdub_> sivang: no, that's a mockup
<lamont> we'll do
<sabdfl> lamont, jdub_, it shoudl build even faster than that, it's just artwork for _all
<lamont> jdub: did you happen to upload it before :30?
<fabbione> lamont: can i use adare?
<jdub_> lamont: haven't uploaded ephy yet
<fabbione> lamont: or it is going to be hitten hard?
<sabdfl> (13:30:03) ***jdub_ uploads u-a
<lamont> uploads that happen before :30 or :00 start building shortly after :33 or :03
<jdub_> just about to submit u-a to the queue
<Kamion> sabdfl: oh yeah, it's cool to have it, I just want to know exactly what it is :)
<elmo> lamont: don't worry about that, I'll be byhanding stuff
<lamont> elmo: awesome.
<sabdfl> trojan horse from the dutch
<lamont> sabdfl: elmo, OTOH, can make :[03] 0 happen faster...
<jdub_> sabdfl: heh, from here "upload" and "submit to queue" are very separate processes ;)
<Kamion> plus, somebody needs to test it
<jdub_> u-a submitted
<sabdfl> elmo: can you steer the new artwork package through the archive process fast as lightning please?
<lamont> elmo: tell me when it's in src, and I'll kick a buildd or 3...
<thom> aaargh
* thom radiates hate at firefox
<daniels> jennifer /org/archive.w.h.c/queue/unchecked/*.changes && kelly /org/archive.w.h.c/queue/accepted/*.changes
<elmo> daniels: err, no
<daniels> or whatever it is
<daniels> or just run the cron scripts by hand
<daniels> or do other stuff
<elmo> sabdfl: yes, am doing
<daniels> either way
<jdub_> ephy ready to submit to queue
<thom> (the make leaves symlinks spattered over the tree that they don't clean up)
<thom> (which of course breaks dpkg-source)
<elmo> lamont: kick i386?
<thom> firefox is in the queue
<Kamion> am I waiting for firefox?
<jdub_> ephy submitted
<elmo> lamont: mozilla-firefox available to the buildds
<Kamion> Alex's new live CD is at http://cdimage.ubuntulinux.org/releases/warty/rcc3/live-i386.iso; testing appreciated
<lamont> royal, crested, terranova
<elmo> lamont: and epiphany now too
<jdub_> heh:
<jdub_> gdmflexiserver --monte-carlo-pi
<Kamion> I'm getting a three-hour ETA on the live CD; unless anyone can get it faster than I can, I'd suggest we might want to publish it slightly after the rest of the RC
<Kamion> I'm not comfortable with releasing something we haven't tested
<jdub_> Kamion: that's via rsync?
<Kamion> jdub_: I don't have a useful base to start from
* lamont finally has the last of the bits he needs to do a local (to the DC) build of a LiveCD, now that alex is done uploding...
<Kamion> jdub_: this is from scratch
<fabbione> daniels: 099l does NOT build
<jdub_> i'll try pulling via rsync
<Kamion> lamont: hooray
<lamont> Kamion: once I get a good build of a LiveCD, then I need to see what other non-DC bits it's dependant on, and address that..
<lamont> _then_ we'll have a LiveCD that I'm comfortable with.
<pitti> fabbione: success!
<fabbione> pitti: ???
<pitti> fabbione: lv3:lwin_switch works for pc105
* Kamion goes for a much-needed shower; I should be back by the time builds are ready for kicking off CD builds
<lamont> meanwhile, I think I'm gonna go torture my buddy in a couple hours... 75 hr eta on RCC1 download. :-(
<fabbione> pitti: ok!
<daniels> fabbione: ?!?
<pitti> carlos: here?
<daniels> fabbione: oh
<carlos> pitti: hi
<daniels> fabbione: yeah, s/VEROBSITY/VERBOSITY/
<m_tthew> lamont: at least now you should be able to get coffee
<daniels> fabbione: forgot to scp the updated version to rookery, sorry
<pitti> carlos: regarding #2327 (macintosh vs. pc105 war)
<pitti> carlos: can you please try whether XkbOptions 'lv3:lwin_switch' does any harm to you?
<lamont> m_tthew: don't drink the stuff...  Leads to discussions with the coffee shop owner, of course...
<pitti> fabbione: I let carlos check that it does not break anything
<lamont> since I don't buy any high-margin items.
<pitti> carlos: I need it to have kind of an AltGr key (The apple key in this case)
<lamont> but he only has 256kbps, buddy has 1.5Mbps atm, or so
<carlos> pitti: with macintosh or pc105?
<lamont> ENOSHARING :-)
<pitti> carlos: pc105
<pitti> carlos: fabbione changed the default to pc105, which broke my clever xmodmap call
<pitti> carlos: and I currently try to get a working solution for pc105
<pitti> carlos: above option works fine for me
<carlos> pitti: well, my request was only for Spanish keyboards
<pitti> carlos: nevertheless it would be nice if you could test
<carlos> sure
<pitti> carlos: does the Apple key currently do anything useful for you?
<carlos> let me boot the imac, I cannot reboot the powerbook at this moment
<carlos> not really
<pitti> carlos: I don't have an AltGr (as you have), so I need the Apple key for AltGr
<carlos> pitti: did you tested Fn + Alt as AltGR?
<pitti> carlos: I think yes, lemme try...
<pitti> carlos: it works for some keys like ~, but not for []   {}
<carlos> :-?
<carlos> pitti: which keymap do you have with xev?
<pitti> carlos: you mean keycode?
<carlos> pitti: xev says the symbol a key has
<carlos> it should say AltGr 
<pitti> carlos: I don't have AltGr
<sabdfl> Kamion: not waiting for firefox
<Kamion> ok
<sabdfl> Kamion: agreed, we can publish the livecd a bit later
<fabbione> pitti: so i can just set lv3 instead of the other
<fabbione> ops
<fabbione> well yeah
<pitti> fabbione: yes
<pitti> fabbione: works for me, but let carlos test this, too
<sabdfl> jdub_: does X come up with the new background colour instead of black?
<pitti> carlos: Apple is "Super_L" in xev without any XkbOptions
<jdub_> sabdfl: hrm, don't think that went in
<jdub_> daniels: was that in the latest X update?
<fabbione> jdub_: no
<fabbione> there is nothing in the changelog for that
<fabbione> jdub_: what is all about?
<carlos> pitti: with that, I get the AltGr also in the Apple key
<pitti> carlos: exactly this was the intended change
<sabdfl> fabbione: can you make sure that x is starting with a colour other than black?
<sabdfl> for the final
<jdub_> fabbione: daniel was going to change the stipple to a flat colour (same as the desktop default colour, or grey)
<pitti> carlos: because the iBook does not have AltGr
<sabdfl> the colour should be the same as the gdm background colour
<pitti> carlos: I asked you to test it because you could have used the Apple key for sth different
<fabbione> sabdfl: i think so... 
<pitti> carlos: so does it break anything?
<jdub_> sabdfl: which is now the desktop background colour
<carlos> pitti: neither my Powerbook or imac keyb, but I have a right Alt that is a AltGr key
<fabbione> daniels: do you have a patch for that?
<carlos> so now I have three AltGr keys
<carlos> pitti: no, it does not breaks anything as far as I know
<pitti> carlos: so would it be okay for you to have the option as default?
<pitti> carlos: great!
<sabdfl> Kamion: we still ok for a UTC 15:00 release?
<pitti> fabbione: it does not break for carlos, too
<carlos> pitti: well, perhaps it's better if the pc105 change is done only for Spanish keymaps...
<fabbione> pitti:     MACOPTS="lv3:lwin_switch"
<fabbione> pitti: is that final?
<pitti> carlos: No, I don't think so. It is better for me, too, and many other users need it also
<Kamion> sabdfl: oh, UTC, phew, not UK time
<carlos> so you don't need to do those things, because perhaps the de keyboard and es one are fixed but we could break other ones
<pitti> fabbione: works for me and carlos, for pc105 and macintosh
<carlos> pitti: ok
<Kamion> sabdfl: should be OK as long as all the builds arrive
<fabbione> Kamion: you still have a ppc, right?
<pitti> fabbione: so that should be fine
<carlos> pitti: for pc105, macintosh is not tested here
<Kamion> fabbione: yes, typing on one now
<Kamion> fabbione: but I cannot give you testing love just at the moment
<fabbione> Kamion: ok
<fabbione> Kamion: no rush
<fabbione> elmo is on ppc ;)
<pitti> Kamion: do you need the Apple key for anything particular?
<pitti> Kamion: because I propose to make it equivalent to the AltGr key (I don't have the latter)
<Kamion> pitti: uh, yes, it's my meta key
<pitti> Kamion: we must not do this by default if Apple is used for something
<sabdfl> jdub_: #4e3e29 i think
<sabdfl> is the colour to be used for "No wallpaper", in the email i sent you
<Kamion> Option is Alt_L, Apple key is Meta_L
<pitti> Kamion: what's a Meta key? I need the key for typing @ []  {} and so on
<jdub_> sabdfl: see latest gdm upload
<pitti> Kamion: do you have AltGr?
<sabdfl> jdub_: in the archive?
<Kamion> pitti: no, I don't have AltGr, unless it's Fn+Alt
<jdub_> sabdfl: on its way in; it just sets the gdm background to the desktop default background
<pitti> Kamion: Fn+Alt only works partly for me
<sabdfl> ok
<Kamion> pitti: maybe it should be made to work fully :)
<Kamion> pitti: stealing Apple scares the hell out of me
<pitti> Kamion: since I need an AltGr/Super_L/whatever key to get []  {} @
<sabdfl> hmm... jdub_ the gdm login screen has a different background colour, much lighter than the desktop
<elmo> gdm and ephy built for all arches
* fabbione fetches popcorn and watches a movie about ppc users killing each others about keybaord layout
<elmo> just waiting on moz-ff for powerpc/amd64 now
<sabdfl> pitti: let's not make any rushed decisions now
<Kamion> pitti: just saying not to do it without *extensive* testing, that's all, I don't really have brain-space to think about it just now
<sabdfl> elmo: is artwork done?
<elmo> sabdfl: yeah
<pitti> Why those Apple bastards just forgot to give me an AltGr key???
<Kamion> ubuntu-artwork |   0.2.11-1 |         warty | all, source
<daniels> jdub_: no, I never got a colour code
<Kamion> that right?
<sabdfl> pitti: let's figure this out tomorrow, after a good nights rest
<daniels> fabbione: i don't have a patch, but I can make one
<jdub_> sabdfl: yeah. i think the X background should be grey or something neutral, because the gdm and desktop will change.
<pitti> fabbione: Seems that the change should be postponed
<sabdfl> final changes in this week so it can bake over the weekend
<daniels> if you want to risk an X build ...
<Kamion> mozilla-firefox | 0.99+1.0PR.1+revertedto0.9.3-0ubuntu2 |         warty | amd64, powerpc
<Kamion> mozilla-firefox | 0.99+1.0PR.1+revertedto0.9.3-0ubuntu3 |         warty | i386, source
<sabdfl> jdub_: trying to avoid three changes
<pitti> sabdfl: okay, if anybody uses the Apple key, we should not change the default
<jdub_> sabdfl: and the gdm background should probably be the same.
<Kamion> sabdfl: um, sorry, have to wait for the other firefox builds now, can't release with it inconsistent
<thom> Kamion: ubuntu3 is what you want, indeed
<jdub_> sabdfl: let's change X and gdm.
<sabdfl> X background should be the same as gdm
<pitti> sabdfl: at least I now know how to fix it easily if users ask :-)
<elmo> amd64 is almost finished
<daniels> sabdfl: are we talking post-RC here?
<fabbione> daniels: just tell me where that stuff is.. i can patch and test it
<daniels> sabdfl: or nownownow?
<sabdfl> jdub_: i'd like the gdb login screen to look exactly as it does with the fixed image currently
<sabdfl> just using components to place the pieces more approrpriately for widescreen etc
<Kamion> pitti: FWIW, I use my Meta key for keyboard shortcuts like Meta-F1 to launch a terminal; it tends to collide with fewer things than Alt-F1 would
<sabdfl> that would be gdm
<sabdfl> daniels: post-rc
<thom> elmo: you think firefox is finished, and then it builds a gazillion extensions...
<jdub_> sabdfl: the 'background colour' used by gdm is independent of the gdmgreeter theme
<sabdfl> oh?
<elmo> thom: nah, I could tell it was doing make install :)
<sabdfl> oh right it;s the colour underneath gnomesplash
<jdub_> i'll explain:
<elmo> amd64's built...
<pitti> Kamion: we should leave it as it currently is; at least I know what to tell users who have this problem :-)
<jdub_> - X starts with stipple (i suggest neutral grey)
<pitti> Kamion, carlos: Thanks for testing! Hoary item.
<jdub_> - gdm starts with BackgroundColor setting in gdm.conf
<sabdfl> jdub_: this is where i want the gdmgreeter colour
<Kamion> pitti: ok, sorry I don't mean to scupper l10n or anything, just saying people do use the Meta key
<carlos> pitti: ok
<jdub_> - if using gdmlogin, that's the background colour
<fabbione> pitti: ok.. so we are going pc105 and no options, ok????
<sabdfl> so you go from text, to a colour, then the gdm picture elements appear
<Kamion> pitti: it could be changed only for layouts where AltGr's needed
<pitti> fabbione: just as we have now, yes
<jdub_> - if using gdmgreeter, the backgroundColor doesn't matter -> you're using a theme
<lamont> amd64 moz build is cleaning up
<lamont> (successful, of course)
<sabdfl> jdub_: we are using the theme by default, right?
<pitti> Kamion: difficult to detect, I think
<thom> ppc doesn't have much longer i think
<sabdfl> there is a colour display before the theme kicks
<sabdfl> in
<daniels> fabbione: xc/programs/Xserver/hw/xfree86/dix/window.c, MakeRootTile()
<Kamion> pitti: detect? you'd just hardcode in the keyboard layouts :-)
<carlos> Kamion: the funny thing is that the spanish keymap has the AltGR key with Fn+Alt
<sabdfl> that colour should match the default theme
<jdub_> - once you finish the login process, the gdm background colour now appears with the splash, etc.
<sabdfl> fabbione: pitti: please DO NOT make big changes now
<jdub_> - when the user's own background setting is loaded, it changes to their background
<sabdfl> let's deal with those tomorrow
<pitti> sabdfl: we already canceled it :-)
<daniels> fabbione: you want to fill back with pixels of a certain colour, which is the gdm colour
<rburton> seb128: i'm still seeing gconf notification disconnection -- is this known?
<daniels> fabbione: i can take care of it when I wake up if you like -- I'm just falling asleep in my chair here
* pitti is happy that his iBook works again now :-)
<jdub_> to avoid excessive colour changes, i suggest using the same (neutral) colour to replace the X stipple and the gdm BackgroundColor
<seb128> rburton: with what ?
<jdub_> though that might be different from the gdmgreeter theme (which will change anyway)
<sabdfl> jdub_: yes, and that colour should be the same as the basic colour of the default gdm theme we ship
<sabdfl> with the three people
<jdub> sabdfl: that's going to change, though.
<sabdfl> when?
<jdub> when either a) we have a new release or b) when the user changes it
<sabdfl> jdub: if the user has changed it, then golden rule applies
<sabdfl> otherwise, when we update the theme for next release, we pick colours accordingly
<jdub> also, we should take into account the pre-X startup process
<sabdfl> yes
<jdub> sabdfl: they will never be able to choose the X stipple replacement colour
<seb128> rburton: where do you get the problem ?
<sabdfl> by default we set it to match our current defaults
<sabdfl> if it's a real issue we can improve that part of X
* jdub thinks apple had the right idea here
<fabbione> daniels: ok. i can wait for the patch tomorrow
<elmo> amd64 installed
<jdub> so by default, there would be one flat colour from X startup through to gdm theme (which would be more detailed, but same basic colour), then back to flat background until the desktop loads
<sabdfl> elmo: of firefox?
<elmo> yeah
<elmo> powerpc's still building
<sabdfl> do we have artwork on all three?
<mdz> back
<Kamion> artwork's arch: all
<sabdfl> morning mdz
<mdz> involuntary nap extension
<elmo> sabdfl: yes
<sabdfl> mdz: deserved, you haven't missed the release
<lamont> mozilla-firefox:        00:53:44 (6 entries, sigma 00:43:59)
<lamont> that'd be ppc, btw
<lamont> amd64,i386 installed
<lamont> "and elmo saw that it was good, and He called it a day"
<thom> reboot, brb
<fabbione> lol
<lamont> ppc should be uploading sometime between :35 and :15 or so.. :-(
<lamont> fabbione: that was just a hint, I don't _know_ that elmo has declared the beginning of a new day :-)
<sabdfl> Kamion: so we should be good for RC then, with new artwork
<Kamion> sabdfl: we have to wait for mozilla-firefox/powerpc now unfortunately, since the other two arches have it
<lamont> Kamion: how long does the mastering take?
<lamont> ISTR < 10 minutes to be sure.
<jdub> supposedly my livecd download will be another 40min
<Kamion> lamont: about 20 minutes
<Kamion> lamont: jigdo has extended it; it's excessively difficult to run it later having disabled that, though
<Kamion> (and my bug reports testify that we have people using jigdo already)
<daniels> fabbione: k
<sabdfl> ah
<sabdfl> ok
<mdz> what's happening with firefox?
<sabdfl> can i do the usual livecd rsync
<lamont> Kamion: then it sounds like we could build i386 and amd64 while we wait for ppc, yes?
<sabdfl> mdz: updates to local homepage
<jdub> now i've got 1:15 to wait for the live cd...
<mdz> ah
<mdz> we have a new live cd?
<sabdfl> mdz: want to crash again, i can call you when we are ready to go
<sabdfl> yes
<Kamion> lamont: theoretically, but I'd really rather keep the build process as standard as possiblee
<lamont> ah, true
<Kamion> lamont: now is not the time for human-error-induced screwups
<sabdfl> agreed Kamion
<Kamion> mdz: alex silently dropped one into a directory I was using for testing and was about to blow away
<elmo> Kamion: if not now, when??
<elmo> oh, wait, that's what final is for.. I forgot
<sabdfl> elmo: soon, soon :-)
<mdz> Kamion: er, great
<Kamion> elmo: I agree it'd be traditional :)
<mdz> and he isn't here to coordinate the release
<lamont> once the RC testing is done and dealt with, interested parties are directed to http://people.ubuntu.com/~lamont/testing/warty.iso, which should (in theory) be a liveCD built in the DC...
<Kamion> mdz: I mailed him asking him to show up on IRC so we could interrogate him about what the image actually was :)
<lamont> but use a CD-RW - the last one was coaster-quality.
<Kamion> mdz: http://cdimage.ubuntulinux.org/releases/warty/rcc3/live-i386.iso
<Kamion> (for now)
<sabdfl> Kamion: is that rsyncable?
<Kamion> sabdfl: yes, in the usual way for cdimage.u.o
<mdz> ETA 40 minutes
<jdub> just s/http/rsync/ and add cdimage/ before releases
<Kamion> (cdimage.ubuntulinux.org::cdimage/releases/warty/rcc3/live-i386.iso
<Kamion> )
<mdz> rsync won't really help, in terms of saving bits to download, though
<m_tthew> I am burning that image now, can report shortly.
<mdz> the live CD is one big compressed blob
<m_tthew> mdz: it helped some for me download
* m_tthew sighs, 'my'
<lamont> the diff between my two livecd images was only 487MB. :-(
<jdub> m_tthew: it's not talklikeapirateday ;)
<elmo> I think ppc is in the install phase now
<lamont> elmo: yep
<lamont> about 50 kb of log left to generate
<lamont> dupload successfu
<lamont> l
<elmo> cron.daily's running now
<lamont> ah, the joy of the tag-team bitch-slap build dance
<Kamion> hi alex, thanks for coming
<alextreme> gday
<lamont> g'day
<Kamion> alextreme: do I gather correctly that /releases/warty/rcc3/live-i386.iso is the new live CD you've produced?
<elmo> Updating master mirrors...
<alextreme> yup, sorry for throwing it in there, thought it was set up for the RC
<elmo> Daily cron scripts successful.
<Kamion> alextreme: no problem, I was just a little surprised because I was about to go and blow that directory away and then spotted your image :)
<alextreme> it's also on chinstrap, so it wouldn't have been much of an issue :)
<Kamion> alextreme: OK, so roughly when was that built?
<alextreme> Kamion: yesterday evening
<Kamion> just so we know which of the last-minute fixes it has
<mdz> so, none of them :-)
<lamont> if my build works, then it has everything before the ubuntu-artwork change of jdubs
<Kamion> ok, that may be fine for the live CD of course
<elmo> and we're all done
<Kamion> epiphany-browser | 1.4.4-0ubuntu2 |         warty | amd64, i386, powerpc, source
<Kamion>        gdm | 2.6.0.3-1ubuntu20 |         warty | amd64, i386, powerpc, source
<mdz> alextreme: lamont has produced a live CD using the automated process, but it apparently didn't function
<Kamion> mozilla-firefox | 0.99+1.0PR.1+revertedto0.9.3-0ubuntu3 |         warty | amd64, i386, powerpc, source
<Kamion> ubuntu-artwork |   0.2.11-1 |         warty | all, source
<Kamion> good to go?
<alextreme> mdz: any clues on what went wrong?
<mdz> lamont: ?
* Kamion starts the CD builds
<fabbione> GO KAMION GO!
<fabbione> ;)
<lamont> <lamont> once the RC testing is done and dealt with, interested parties are directed to http://people.ubuntu.com/~lamont/testing/warty.iso, which should (in theory) be a liveCD built in the DC...
<Kamion> alextreme: OK, I think our plan for now is to publish the RC first with the install CD only (since it's in about an hour and a half), but to add the live CD later today once a few people have had time to test it
<alextreme> Kamion: sounds good
<lamont> alextreme: that was the one without the local warthog packages.
<alextreme> lamont: cool, i'll give it a spin lateron
<alextreme> ahh, then it probably wouldn't init properly
<lamont> the new one as of this morning (and hence with almost all the fixes), is the one above.
<m_tthew> alextreme: re, lamont's previous livecd build: http://www.ice-nine.org/matt/tmp/warty-livecd-2004-10-11-lamont1.png
<mdz> lamontt: you'll need to build another one anyway, no?
<lamont> alextreme: failed to mount root
<lamont> fs
<lamont> m_tthew: thanks
<m_tthew> alextreme: I am too follish to figure out how to make the livecd's grub talk to serial
<lamont> btw, cool data transfer technique. :-)
<m_tthew> lamont: np
<sabdfl> lamont: which is that?
<lamont> I found it, resourceful.
<alextreme> m_tthew: hehehe
<lamont> sabdfl: he took a pic of the display.
<lamont> that or he's a _GOD_ with gimp.
<mdz> seb128: why a new totem and gnome-applets at the last minute?
<m_tthew> heh, moreso the former.
<sabdfl> who? which?
<sabdfl> for what?
<Kamion> 14:37 < m_tthew> alextreme: re, lamont's previous livecd build: http://www.ice-nine.org/matt/tmp/warty-livecd-2004-10-11-lamont1.png
<sabdfl> ah
<seb128> mdz: the new totem has only 1 change, a crasher fix with the "play CD" entry
* sabdfl must not have slept as well as planned
<rburton> jdub: so my co-worker who is also running ubuntu just said "hmmmm breasts"
<jdub> yeah.
<rburton> i'm tempted to logout myself
<lamont> sabdfl: history: lamont builds a liveCD coaster, m_tthew tests, takes pic, lamont talks to alex, builds another.
<seb128> mdz: and the gnome-applets to fix a bug reported by pitti this morning (weather locations broken)
<jdub> rburton: i have already heard "wanking warthog"
<sabdfl> gotcha
<Kamion> jdub: doesn't seem like ideal PR
<seb128> mdz: the gnome-applets was a typo fix in an xml file
<alextreme> lamont: sounds like sound QA ;)
<carlos> jdub: are the icon theme finished?
<sabdfl> jdub: where you get your warts is your own business
<lamont> alextreme: yep
<jdub> carlos: nah, not ready for release unfortunately
<jdub> carlos: you can try the icon theme though
<jdub> sabdfl: haw haw ;)
<jdub> Kamion: so i used to work in a cookery book shop
* Kamion ponders deferring showing Ubuntu to his parents
<lamont> us prudish US types will have challenges with some of the artwork..
<sabdfl> guys, when it comes to PR, the important this is that they spell our name right
<alextreme> Kamion: so there have been a few fixes this morning? could rebuild and reupload this evening
<sabdfl> ubuntu
<sabdfl> not ubunto
<carlos> jdub: ok, It's just I have the WebDAV icon with the gorilla one instead of ubuntu, if it's not finished I will not report it as a bug :-)
<sabdfl> or obonto
<rburton> that is the luckiest ubuntu logo in the world
<jdub> Kamion: only specialist in .au (which has a huge market here) big mail order business
<Kamion> alextreme: right; are you subscribed to warty-changes?
* alextreme saw obuntoo somewhere
* lamont also rebuilds
<alextreme> Kamion: nope
<jdub> carlos: that's a bug in the current icons them
<jdub> carlos: please report
<Kamion> alextreme: it's on lists.ubuntu.com, might be useful for you
<jdub> Kamion: there's a book called "the cake bible"
<mdz> seb128: we should not make any changes at this point unless they are critical for the release candidate
<Kamion> well, the racier the artwork is the fewer people I'll be willing to show it to *shrug*
<carlos> jdub: but does it exists with ubuntu?
<jdub> Kamion: numerous times it was returned from customs in saudi arabia, etc. :-)
<alextreme> Kamion: i'll put the archive in my bookmarks, but am on too many lists already :)
<mdz> Kamion, lamont: you guys do realize that it isn't shown by default?
<jdub> carlos: the default icon theme atm is the gnome one
<sabdfl> Kamion: the default is not racy
<seb128> mdz: the crasher was pretty bad, and the second was a typo a << instead of < broken the xml file ... 
<jdub> carlos: so if you see problems with it, please report them
<lamont> alextreme: want me to send you the log from my build so you can see if there's anything obviously coaster-producing in it?
<lamont> mdz: understood
<tseng> i dont find any of those to be "racy".
<alextreme> lamont: yes, please
<carlos> jdub: sorry, it's the gnome one, not gorilla 
<lamont> alextreme: as soon as it finishes..
<jdub> sabdfl: i may need to expense a cricket bat. need one to teach lifeless to pronounce ubuntu correctly.
<seb128> mdz: BTW I've a fix for data corruption happening sometime with ftp transferts (and possible http) in nautilus ready to upload if we still have time
<Kamion> mdz: I thought several people were commenting on the images other than the wallpaper
<mdz> seb128: please wait until after the candidate is out
<sabdfl> erm... line him up for cloning first, would ya?
<Kamion> jdub: teach him to pronounce Debian while you're at it :)
<seb128> mdz: ok
<mdz> Kamion: oh, haven't seen the gdm stuff yet
<sabdfl> and, erh arch
<jdub> 02:47  * dalderman loves the nipples on gdm now :-)
<mdz> oh, yes I have
<mdz> it's not racy
<jdub> Kamion: he uses his heritage as an excuse for pronouncing everything incorrectly. gotta beat the sheep out of him.
<jdub> mdz: not racy, but it must be a bit chilly.
<sabdfl> just don't accidentally beat him into the sheep
<sabdfl> no, that was just me taking the photo
<Keybuk> jdub: give daniels a beating for mis-pronouncing route while you're at it :)
<jdub> sabdfl: he's a bit of a dag already. :)
<Kamion> sabdfl: I was trying to come up with a similar pun but decided against it :)
* Kamion couldn't figure out how to change the gnome-session splash earlier
<Kamion> I think I concluded that isn't possible
<lamont> is there a pic of the gdm screen anywhere?
<jdub> Kamion: gconf-editor
<Kamion> jdub: ah, ok
<sabdfl> Kamion: we should try to make that themable for hoary
<sabdfl> jdub: could that be part of a theme?
<jdub> it's changeable, but it so doesn't need to be themeable ;)
<jdub> that said, it could be defined as part of a metatheme
<sabdfl> i guess we do need to be able to remove the people from the theme altogether for some users
<jdub> (btw, i left the just-logo splash on the disk, so admins can switch to that instead)
<jdub> just a matter of a gconf default change
<sabdfl> which is the "login in a new window" package?
<jdub> sabdfl: it's part of gdm, but you need to install xnest to see the menu entry
<sabdfl> ok
<rburton> jdub: how about a version of the splash without the ubuntu logo? ;)
<Kamion> hm, didn't seem to work, I wonder if I changed the right key
<dalderman> jdub: yeah, the logo is in the wrong place
<jdub> rburton: it offends you more than erect nipples?
<jdub> oh
<jdub> right
<jdub> haw haw
<jdub> very funny
* jdub hoses down rburton and dalderman 
<sabdfl> Kamion: you don't like it that much?
<rburton> i'm just being bawdy
<dalderman> we have no women in our office at the moment :-(
<dalderman> far too much testosterone in here
<Kamion> sabdfl: just anticipating raised eyebrows from family
<Kamion> it's suggestive rather than there actually being anything wrong with it
<jdub> sabdfl: already have two people asking how to switch the logo for their rollouts.
<Kamion> hm, is it not /apps/gnome-session/options/splash_image then?
<rburton> for $MEGACORP its a little suggestive
<rburton> put them in suits?
<tseng> getsweaaa.com/~tseng/new-gdm.png for whoever asked
<jdub> Kamion: that's it
<dalderman> most corporate places are full of short fat hairy people, it's just going to make them feel inadequate :-)
<Kamion> jdub: uh, ok, it would help if I weren't a moron
<Kamion> (yes, works)
* Kamion raises an eyebrow at the jigdo-file assertion failure in the powerpc CD build logs.
<sabdfl> so what is the alternative image?
<Kamion> the one we had up to yesterday's still installed and available, it seems
<mdz> Kamion: are you sure you can't turn that off without risking the stability of the rest of the process?
<dalderman> I can arrange a nice half nakes one of rburton if you like :-)
<Kamion> mdz: I can, but I am not convinced I can reliably generate the .jigdo and .templates files later
<Kamion> for ten minutes I don't think it's worth the complexity of trying to work that out
<lamont> so is the male model that much taller than the other two, or am I just misinterpreting the picture?
<mdz> I don't mind if we don't have .jigdo for the release candidate
<Kamion> too late :-)
<sabdfl> lamont: try the calendar desktop :-)
<lamont> sabdfl: I'm still _downloading_ stuff..
* jdub just went through the entire default boot process.
<sabdfl> jdub: how's it look?
<jdub> ubuntu is so much pr0n.
<jdub> good
<Kamion> CDs up
<sabdfl> Whooooot!
<rburton> jdub: i still get hangs on shutdown...
<sabdfl> can i update the web site?
<lamont> although I'mstarting to question the term "release candidate"... :-)
<mdz> we should, er, test the images first :-)
<jdub> IT BUILDS SHIP IT
<Kamion> sabdfl: they're only in /daily/current as yet
<Kamion> give us an hour to hammer them :)
<rburton> jdub: COCKFOSTERS
<sabdfl> pants off, hammer them. uh. jdub, don't do that.
<lamont> it would be good for corporate america to have the defaults not include any significantly suggestive photos...
<jdub> already there.
<jdub> i just booted, remember.
<mdz> lamont: can we get a live CD build which is in sync with the latest rcc?
<lamont> mdz: it's building, hopefully will boot..
<mdz> rsyncing daily/current
<mdz> hmm, apparently carlos decided today would be a good day to start testing ubuntu :-)
<fabbione> mdz: ahahhahaha
<fabbione> mdz: http://people.ubuntulinux.org/~fabbione/boom
<mdz> fabbione: ???
<carlos> mdz: well, I'm testing it since long ago, but I had some bug reports in my queue O:-)
<rburton> i wonder how long after release it will be for someone to make a pr0n version of the human theme?
<fabbione> boom = X changelog for ubuntu25
<pitti> fabbione: first and second + are duplicates :-)
<carlos> rburton: a friend asked me if it will be more pr0n with every month update :-P
<fabbione> pitti: ops
<pitti> fabbione: not really RC, though :-)
<mdz> fabbione: we are only fixing RC bugs right now
<fabbione> mdz: the frequency stuff is RC
<thom> mdz: would you hurt me significantly if i fix the mono stuffs to build on amd64 at some point in the next week?
<fabbione> mdz: the XKB stuff too
<fabbione> mdz: every fix for the XKB = a slightly longer life for me
<mdz> thom: of course not, right after the RC bugs are closed
<mdz> fabbione: the last XKB changes imported from Debian broke things
<fabbione> mdz: the rest is documentation and absolutely non introsive changes
<mdz> we should not be making these changes now
<fabbione> mdz: there was only one regression and apparently the fix is clear
<thom> mdz: that was kinda what i meant, yes
<fabbione> mdz: 2288 is the "regression" and we can argue forever if it is a X problem or a gnome problem
<mdz> 2288 is not an RC bug
<lamont> alextreme: http://people.ubuntu.com/~lamont/liveCD.out.gz
* lamont has freshened his liveCD image
<alextreme> lamont: ta
<fabbione> mdz: only because it has been opened as normal
<mdz> fabbione: I am looking at the bug and it is not RC
<alextreme> lamont: crap, forgot to include the makedev dependancy
<lamont> so it's a coaster?
<alextreme> yup
<lamont> what do I change where?
<alextreme> i'll go poke around some more, bound to be more issues
<alextreme> lemme check...
<lamont> brb
<fabbione> mdz: ok.. whatever you think it's fine for me, but seriously.. we will get a hell load of reports for that
<fabbione> mdz: no more than what we got in debian
<alextreme> lamont: apt-get install makedev on the buildmachine as a workaround, will fix cvs now and make a new package later on
<thom> mdz: heh, just got a mid-air collision with you on the homepage bug 
<mdz> fabbione: I know that you want it to be perfect, but it cannot be. at some point we must leave it alone because we have a release to make
<lamont> alextreme: ah, so it just needs to be there on the building machine?
<alextreme> lamont: should do the trick
<alextreme> lamont: Failed to fetch file:/local/warthog/./Packages.gz  File not found
<thom> mdz: can i help test your portmap fixes?
<mdz> thom: absolutely
<mdz> thom: there's a debdiff attached to #505
<lamont> alextreme: does it not like file: urls?
<thom> ah, cool
<fabbione> mdz: Denis work on XKB is the ONLY good source for fixes in that mess. I know we have a release to make. I also have a responsability towards our users to give them the best. sorry if it sounds retoric (yeah itaglish) but that's the only reason why i push so much on X
<alextreme> lamont: guess not, probably due to it apt-getting in the chroot
<lamont> that'd do it.
<lamont> anything about those 3 packages that makes them not want to be world-fetchable?
<T-Bone> l.a.d.u.d.e!
* lamont pushes /local/warthog to p.u.c/~lamont/LiveCD
<lamont> or some such
<fabbione> mdz: which changes do you want me to revert?
<mdz> fabbione: let's look at it together tomorrow, after the RC is out
<fabbione> mdz: ok
<fabbione> mdz: tomorrow i will be 99% moving to the secondary office
<fabbione> so i expect to be up and running again around 8 UTC
<mdz> fabbione: I do not consider X to have any showstopper bugs at this time
<alextreme> lamont: not really, mostly use my local webserver when building and only upload stuff that actually works ;)
<fabbione> mdz: the frequency thing is the reason why some people were getting a 640x480 screen and they couldn't go out of it
<fabbione> mdz: it's a 3 lines diff -u
<thom> first complaint on the users list
<thom> about the theme
<alextreme> lamont: something odd is happening right at the end, deb-get downloads the udebs but they don't seem to be extracted
<mdz> thom: militant?
<thom> mdz: "conservative and uncomfortable"
<alextreme> lamont: it's a messy script, but running those commands again should give a clue what's happening
<Kamion> we did get an unexpectedly large number of compliments about the old theme
* lamont has the script running with a valid URL for the local stuff, and makedev installed.
<mdz> the delta on the current daily is huge
<mdz> only just got amd64 down
<alextreme> lamont: cd /tmp/libmorphix-u2uloT && /usr/bin/deb-get grub-gfxboot-iso-udeb
<alextreme> lamont: the udeb is being downloaded, but doesn't seem to appear in the build directory
<lamont> alextreme: it says "Can't open configuration file
<alextreme> lamont: /usr/bin/deb-get -r http://www.morphix.org/debian/udeb
<thom> mdz: good grief, does that mean i beat you? :-)
<Kamion> whoa, you're using udebs?
<alextreme> Kamion: don't worry, they won't clash :)
<Kamion> ok :)
<mdz> hmmm
<mdz> i386 was way faster
<Kamion> scary
<mdz> that is not very encouraging
<Kamion> @ERROR: Unknown module 'cdimage'
<Kamion> aargh. thom/elmo!
<Kamion> archive.ubuntulinux.org apparently round-robins to the machine that's serving releases.u.c
<Kamion> which does not know about the 'ubuntu' and 'cdimage' modules
* Kamion switches to cdimage.u.o in order to get vaguely predictable results; archive.u.o is useless for rsync currently
<m_tthew> alextreme: this is all deprecated by the new livecd underway, but: http://www.ice-nine.org/matt/ubuntu/warty/livecd/
<m_tthew> alextreme: dmesg, lsmod, and lspci output -- I had no mouse (I use a USB logitech)
<lamont> m_tthew: the last coaster was short a few device files... :-(
<elmo> Kamion: uh
<alextreme> m_tthew: was this from the RC version, or from the one from last week?
<elmo> we've been pointing people at rsync://archive.ubuntu.com/ ??
<m_tthew> lamont: d'oh
* fabbione enjoys the monthly desktop background!
<Kamion> <cjwatson@cairhien ~/ubuntu/cdimage>$ rsync archive.ubuntulinux.org::
<Kamion> releases        Ubuntu Release CD Images
<Kamion> <cjwatson@cairhien ~/ubuntu/cdimage>$ rsync archive.ubuntulinux.org::
<Kamion> ubuntu          Ubuntu Archive
<Kamion> cdimage         Ubuntu CD Images
<lamont> m_tthew: and was it from me, or the one alex uploaded?
<elmo> yeah, I know
<Kamion> elmo: that's been in sounder release announcements since ages
<m_tthew> alextreme: this is from your build of .. yesterday morning I believe you said? The one Kamion moved out of rc3/
<elmo> bah
<Kamion> elmo: even discounting cdimage rsyncers, aren't regular archive mirrors using archive.u.o?
<Kamion> it'll fail half the time for them, too
<elmo> why did we set up cdimage.u.c if we weren't going to use it?
<alextreme> m_tthew: scary stuff, thanks for the info
<elmo> kamion: http works
<Kamion> sure, rsync doesn't though
<m_tthew> alextreme: no problem, I will test the one currently being built soon as you guys lemme know it's ready to download.
<Kamion> elmo: I'm not sure why we weren't using cdimage in release announcements; I'll make sure to do so from now on
<elmo> I've reverted archive.* back to just auckland
<alextreme> m_tthew: it probably will take some bugfixing to get right, i'll do a partial rebuild and some testing once i get behind my buildmachine later on
<lamont> sabdfl: the one that scares me most about the new themes is explaining it to my daughter's 12-year-old friend's mother, after he installs ubuntu on my recommendation...
<sabdfl> lamont: HE won't be upset.
<lamont> that, and pictures of people on the desktop are just plain distracting.
<lamont> sabdfl: don't care what he thinks.
<sabdfl> lamont: they are not the default
<Kamion> this is what the Mozilla people would call an "Evangelism bug", I think
<lamont> including on the login screen?
<sabdfl> ok, let's see where the dust settles
* lamont wishes he had a *(^*^& iso.
<pitti> carlos: I did not find out how to create an HFS+ file system under Linux. Did the previous pmount (which did umask=007) work for the iPod as expected?
<Kamion> pitti: 'man hfsplus'
<carlos> pitti: I can send you a file with an empty HFS+ file system if you want
<pitti> Kamion: it contains a lot of tools, but none to create a filesystem
<thom> right, reboot for GREAT JUSTICE
<carlos> pitti: I think so, but I need to recheck it to be sure (I did not saw any problem)
<pitti> carlos: that'd be nice
<elmo> bloody rsync needs vhosting
<pitti> carlos: mdz reverted the umask because umask=007 is interpreted totally wrong for hfs
<carlos> pitti: btw, did you saw my bugreport about hal not seeing my iPod anymore?
<Kamion> pitti: so it doesn't
<Kamion> Greek install time
<pitti> carlos: I saw the notification mail, but did not yet look at the report
<carlos> pitti: ok
<carlos> pitti: I have 0.1-6
<lamont> alextreme: /usr/sbin/mkminiroot-morphix: line 58: Found: command not found
<lamont> le huh?
<Kamion> elmo: or make both of them have all three rsync modules, I guess ...
<carlos> which version should I test?
<elmo> kamion: I can't - cdimage is too big
<carlos> (talking about pmount)
<Kamion> elmo: ah :-(
<Kamion> elmo: I can temporarily shrink it but I'm sure it'd grow again, daily builds being what they are ...
<Kamion> I should set up auto-pruning
<Keybuk> jdub: is there any particular reason ubuntu-artwork isn't 1.0 or 4.10 ?
<pitti> carlos: ugh, that sounds bad. the last intrusive change has been on Sept 27...
<Keybuk> likewise ubuntu-base and ubuntu-desktop
<pitti> carlos: lshal does not contain anything?
<lamont> for udeb in $UDEBS
<lamont> do
<lamont>   `cd /tmp && deb-get $udeb`
<lamont> done
<elmo> Kamion: unfortunately the free machines we have aren't nearly as well endowed storage wise - you'd have to shrink it to like 35Gb for it to fit
<lamont> I, um, think those want to be () ,not ``
<jdub> Keybuk: NOW IS NOT THE TIME
<jdub> ;)
<carlos> pitti: wait, let me finish the check you asked me and then we come back to hal :-)
<Kamion> (not to mention quoting "$udeb" thus
<Kamion> )
<lamont> Kamion: it needs quotes?
<Keybuk> jdub: you didn't think of that, did you? :o)
<carlos> pitti: which version of pmount should I test?
<alextreme> lamont: did you install the recommended packages? :)
* lamont is reminded to grumble at lgc-pg_0.32-2 ebook-dev-ggad_199908-5 lgeneral_1.1.1-4 libnsuml-java_0.4.20-10 libvpopmail-perl_0.08-2
<pitti> carlos: 0.1-5
<jdub> Keybuk: i just stuck with the existing numbering ;)
<lamont> alextreme: what are recommends? :-)
<Kamion> lamont: shell variable expansions always need quoting unless you have a very good reason not to
<lamont> Kamion: true
<Kamion> 'for udeb in $UDEBS' is a good reason where you don't want quoting around $UDEBS.
<lamont> alextreme: if it has to be there, then it's not a recommends...
* thom sees more blue and red screen
<Kamion> crap, my i386 CD burnt badly
<lamont> alextreme: what package do I need to have there
<lamont> ?
<alextreme> lamont: yeah yeah, i'm not a DD :)
<alextreme> lamont: une momento...
<thom> install0r1s1ng kernel
<alextreme> lamont: mkminiroot-morphix, morphix-deb-get, morphix-make-iso
<thom> copying every bastard thing on the planet on the cd
<pitti> carlos: soory to bother you with all this :-)
* alextreme throws them into the very long dependancy line...
<carlos> pitti: no problem
<lamont> ii  mkminiroot-mor 0.1-5          creates a miniroot/initrd for Morphix using 
<carlos> pitti: ok, pmount /dev/sda3
<lamont> ii  morphix-deb-ge 0.2-2          Script to retrieve packages from repositorie
<lamont> ii  morphix-make-i 0.2-2          Script to build a Morphix iso from a directo
<m_tthew> thom: we are almost sychronized
<carlos> any other argument?
<pitti> carlos: are the permissions on the device correct?
<thom> archiver-copier is really boring
<carlos> pitti: /dev/sda3 on /media/sda3 type hfsplus (rw,noexec,nosuid,nodev,sync,umask=007,uid=1000,gid=1000)
<pitti> carlos: i. e. not world-readable/writeable
<lamont> alextreme: but the `` on that line are causing the shell to attempt to _EXECUTE_ the _OUTPUT_ of the command, after it runs...
<pitti> carlos: ls -l /media/sda3
<lamont> I can't see how that could be what we want
<carlos> pitti: no, they are world readable
<pitti> carlos: (only one or two examples)
<mdz> i386, powerpc and amd64 underway
<carlos> drwxr--r--    1 carlos   carlos          2 2004-08-21 12:06 Calendars
<carlos> drwxr--r--    1 carlos   carlos          4 2004-08-21 12:06 Contacts
<pitti> carlos: okay, that means that hfsplus does not respect umask.
<alextreme> lamont: une momento...
<pitti> carlos: that's what I wanted to know, thanks a lot! :-)
<jdub> OH BONG
* lamont is reminded to grumble at lgc-pg_0.32-2 ebook-dev-ggad_199908-5 lgeneral_1.1.1-4 libnsuml-java_0.4.20-10 libvpopmail-perl_0.08-2
<carlos> pitti: no problem, if you want I could "fix" it with my patch (but will be for hoary)
<jdub> the fricking bullet points in the on-disk home page are off-disk
<Kamion> jdub: ?
<Kamion> d'oh
* jdub will fix post-rc
<thom> jdub: HFSNW
<jdub> thom: W!
<pitti> carlos: I was asked for umask=007 in case you store gpg keys and such on your memory stick
<lamont> jdub: s/rc/preview2/
<jdub> haha
<Keybuk> jdub: though I do like the new login screen
<carlos> pitti: I don't see the problem with hfs+ then, it does not work for it, that all, right? but it will work with other filesystems
<Keybuk> (install just finished)
<jdub> Keybuk: yeah, that image works so nicely for it
<pitti> carlos: I wanted to know whether it breaks similarly to hfs; for hfs, umask=007 means that all files are 007!
<thom> "the hardware clock says the time is now ."
<carlos> pitti: hfs or hfs+?
<pitti> thom: now is always a good time to be at :-)
<pitti> carlos: hfs
<carlos> oh, I tested it as hfs+
<Kamion> maybe hwclock didn't produce sensible output
<carlos> let me recheck it as hfs
<pitti> carlos: right, that's what I wanted
<thom> Kamion: amd64, no rtc access
<pitti> carlos: I can check hfs for myself (hfsutils)
<carlos> does pmount accept -t hfs?
<Kamion> thom: heh, I thought we'd fixed that bug
<thom> (cos the module ain't loaded)
<pitti> carlos: no
<thom> seems not
<carlos> then I cannot test it now
<Kamion> oopsie
<pitti> carlos: it autodetects the filesystem
<carlos> hmm, well, I could "remove" hfsplus driver
<thom> i shall get useful dmesg in a bit and file bugses
<pitti> carlos: no need, I know everything that I wanted and need
<carlos> ok
<pitti> carlos: thanks
<Kamion> thom: I think I've already got a bug about rtc not being loaded
<thom> i won't bother then.
<thom> even better
<thom> :-)
<carlos> pitti: about the hal problem, lshal does not list my ipod anymore
<pitti> carlos: do you know whether it worked with any 0.2.98 version?
<pitti> carlos: i. e. anytime after September 27?
<carlos> pitti: the problem was with latest update
<pitti> carlos: should, other people reported it to work
* pitti looks in the changelog
<Kamion> amd64 successful
<thom> i still think the steel grey watermark background is the best of the lot
<mdz> amd64 and powerpc in aptitude, i386 in archive-copier
<pitti> carlos: odd, the last change was just removing some digital camera fdi files
<lamont> thom: grey is much softer on the eyes than brown
<thom> amd64 just about to finish aptitude
<pitti> carlos: can you please verify that reverting to ubuntu7 works?
<lamont> or so ISTR from the ergo folks
* lamont wanders off for about 10-15 minutes
<Keybuk> ok, I just logged in and got only a black background
<Keybuk> and the desktop background dialog crashes when I open it
<thom> registering documentation
<carlos> pitti: verified
<mdz> Keybuk: nice
<carlos> installed the ubuntu7 version and nautilus show me the iPod directory automatically
<pitti> carlos: what the hell do the camera fdi files have to do with iPods? *grumble*
* Keybuk tries again
<carlos> pitti: don't know :-P
<mdz> pitti: perhaps the autoreconf broke it
<amu> hehe the new theme must be x-rated   
<pitti> carlos: Can I send you a test deb?
<carlos> pitti: by mail or URL, don't think my firewall will let you send it by irc (you could try, of cours)
<thom> and we have gdm
<thom> rock
<pitti> mdz: maybe, but it was autoreconfed before. Well, it's worth a try
<mdz> pitti: check the debdiff
<pitti> carlos: i386 or powerpc? I only have an i386 deb at the moment
<carlos> ppc
<pitti> carlos: can you build it yourself?
<carlos> I don't have firewire in my pc
<carlos> pitti: sure
<pitti> carlos: okay, I mail you diff.gz and .dsc
<Keybuk> ok... that's *really* weird
<carlos> ok
<Keybuk> gconf-editor won't even let me look at the background key
<mdz> amd64 success
<thom> yeah, +1 for amd64 here
<pitti> carlos: you have it 
* thom ambles off to get lunch
<Keybuk> ah, fixed it ... was my fault :p
<carlos> pitti: don't see the mail
<alextreme> lamont: back, did take a quick look at it and it should boot. got some new packages to fix the issues you were having, should hit m.org/debian shortly
<thom> Keybuk: ... shock
<Keybuk> thom: had checked how the widescreen stuff had been done by opening in vi
<Keybuk> there was a stray "i" left in the file
<pitti> carlos: I sent it to carlos@pemas.net
<carlos> I got it
<mdz> powerpc success
<mdz> anyone had a successful i386 install yet? mine is registering docs
<carlos> mdz: same here, powerpc installation was right, need to test it
<m_tthew> mdz: I am in aptitude, watching the Selecting... Unpacking... shuffle
<carlos> jdub: the gdm login screen does not shows "Contrasea" (password in spanish)  but "Contrase" the rest of the word is under the input field
<mdz> i386 successful
<mdz> Kamion: 3 for 3
<mdz> pitti: FYI, my card reader works as expected with the RC
<pitti> mdz: graet, some good news :-)
<pitti> mdz: my devices work well, too
<mdz> pitti: sabdfl has a problem with a pen drive which worked previously
<pitti> rburton: does your iPod work with the latest hal (i. e. with the RC)
<rburton> pitti: it works as long as i don't mount/unmount/eject quickly
<pitti> mdz: I created a hal version without any autotool file changes, carlos currently tests it
<thom> pitti: my usb card disk works fine
<pitti> mdz: I cannot imagine how the autotools stuff should break such things, but who knows...
<pitti> thom: thx
<Keybuk> pitti: just tried the camera, it takes about 10-15 seconds to appear -- and I get both an "sda1" window+icon rather than anything descriptive, but it works
<carlos> pitti: seems to be working now
<pitti> Keybuk: sometimes I had that as well - absurdly long delays
<carlos> pitti: do you want the .deb fileS?
<pitti> carlos: with the new hal?
<carlos> pitti: yes
<mdz> lamont: how goes the live CD?
<pitti> carlos: well, I could put them into my unofficial utopia repository
<Keybuk> pitti: looking at syslog it's actually making sda, sdb, sdc, sdd, sde, sdf, sdg, etc. as well
<pitti> carlos: I can compile them myself if necessary, though
<sabdfl> pitti: my pen drive isn't firing up a window when i plug it in
<pitti> Keybuk: so many nodes for one device?
<pitti> sabdfl: i386?
<sabdfl> pitti: yes
<Keybuk> pitti: they're just device nodes, there's only an sda1
<mdz> pitti: did you revert the removal of the freedesktop stuff as well?  or patch that into Makefile.in?
<Keybuk> CD works
<Keybuk> (btw, for hoary, do you have any idea how to get these things to have useful names like "CD-ROM" and "Camera" instead of hdc/sda1?)
<pitti> mdz: I reverted the removal of the fdi file that is upstream, because that one does not break cameras
<pitti> sabdfl: I can send you a test deb
<mdz> Keybuk: yes
<pitti> Keybuk: we have
<carlos> pitti: http://carlos.pemas.net/ubuntu (if you want the ppc debs)
<pitti> Keybuk: g-v-m should keep a label database; pmount already supports it
<sabdfl> pitti: url is better than email
<pitti> carlos: thanks
<pitti> sabdfl: http://www.piware.de/hal_0.2.98-1ubuntu9_i386.deb
<Kamion> i386 in aptitude, powerpc in base-config
<rburton> pitti: i was going to check that it detected a usb stick here, but my hal is dead. still blocked in open() :)
<pitti> rburton: that's the error we already know about. Damn kernel bug...
<rburton> pitti: apart from that looking good
<rburton> next time i reboot i'll verify the usb stick works here
<carlos> pitti: latest official pmount releases works with my pendrive (if you need a confirmation about it)
<pitti> carlos, rburton: thanks
<sabdfl> pitti: perfect, what's the fix?
<pitti> sabdfl: I reverted to upstream's autotool files
<pitti> sabdfl: I needed to autoreconf in past releases
<sabdfl> ok
<pitti> sabdfl: but now that's not really necessary any more
<Mithrandir> mdz: I think you're going to hate me.. but 1854 isn't fixed.
<mdz> Mithrandir: really?
<mdz> I tried many times to reproduce it on your machine and was unable, after the patch
<Mithrandir> mdz: try logging in and running apt-get upgrade
<mdz> Mithrandir: oh crap
<mdz> Mithrandir: I botched the change
<pitti> mdz: the newer hal seems to work better, so... (I don't dare to ask :- ))
<Mithrandir> sorry I haven't been able to test it before, but I completely forgot to actually verify that it was fixed :/
<Kamion> mdz's change fixed the bug I was hitting big-time on little
<Kamion> so I thought it was safe ...
<mdz> Kamion: the patch, 9ubuntu1 or 9ubuntu2?
<mdz> 9ubuntu2 was busticated
<Mithrandir> my system has never seen 9ubuntu1.
<Kamion> oh
<mdz> the patch and 9ubuntu1 are ok
<Kamion> 9ubuntu1
<mdz> I have 9ubuntu3 with the proper brown-bag fix
<Kamion> is 9ubuntu2 showstopperishly broken?
<Kamion> or just broken in the same way as -9?
<mdz> Kamion: not an RC showstopper
<mdz> but a final showstopper, methinks
<Kamion> ok
<Kamion> yes, agreed
<sabdfl> Kamion: is ubuntu-desktop *exactly* the same as germinate?
<mdz> sabdfl: it's based on the seed, not germinate output
<mdz> (no dependencies)
<Kamion> what he said
<Kamion> makes more sense that way
<Mithrandir> mdz: you're just fixing it now, so no need to reopen, or?
<Keybuk> Kamion: which kernel *is* http://archive.ubuntu.com/ubuntu/dists/warty/main/installer-i386/20040801ubuntu19/images/netboot/vmlinuz ?
<sabdfl> ok, need to help alex get the livecd package list into parity, what's the best way?
<mdz> Mithrandir: I reopened it; I'm not uploading gzip until after the RC
<Mithrandir> mdz: ack.
<mdz> sabdfl: Kamion can send him germinate output
<sabdfl> ok, this is not absolutely totally fixed, right?
<sabdfl> sorry
<sabdfl> now, not not
<sabdfl> once again
<sabdfl> this list is now totally fixed for release?
<Kamion> Keybuk: look in initrd.list alongside it
<Keybuk> Kamion: ah, didn't know about that, handy
<mdz> sabdfl: should be
<sabdfl> ok
<Kamion> Keybuk: you might have to correlate against linux-kernel-di-i386-2.6 changelogs
<mdz> barring some extremely major "oh shit" moment
<sabdfl> Kamion: could you please send alex the exact list when you have a sec?
<Kamion> sabdfl: sure, after RC :-)
<Kamion> i386 success
<Kamion> (in Greek)
<mdz> Kamion: this is for the RC live CD
<Kamion> crap, ok
<mdz> he just needs base + desktop for i386
<sabdfl> can i generate that list from a freshly installed box?
<Kamion> alextreme: can you just use https://chinstrap.warthogs.hbd.com/~cjwatson/germinate-warty-output/?
<mdz> I wasn't sure if he had access to that
<alextreme> Kamion: i'll check, think it should do
<mdz> sabdfl: in theory, yes
<Kamion> mdz: alex has an account on chinstrap
* lamont pushes the new liveCD image (and out.gz) and admits to being back
<lamont> someone with bandwidth wanna test that?
<mdz> lamont: need a bit more information in order to do that
<lamont> http://people.ubuntu.com/~lamont/testing/warty.iso
<m_tthew> i386 success
<m_tthew> lamont: rsyncing
<Kamion> powerpc success
<lamont>    551401472 100%    9.01MB/s    0:00:58  (1, 100.0% of 1)
<lamont> wrote 542946115 bytes  read 164407 bytes  8291763.69 bytes/sec
<lamont> rsync is not a big win. :-(
<Kamion> so; shall I publish this on releases.ubuntu.com?
<mdz> Kamion: I think we have a winner
<Kamion> let's hope the publish script works
<mdz> lamont: wasn't the previous live CD significantly larger than this one?
<lamont> mdz: dunno
<lamont> still in the debug iteration phase... haven't been keeping logs. :-(
<mdz> ETA 24m
* lamont has a high-bandwidth lunch planned
<lamont> although I have to give the nice man some blank CDR's to make up for it....
<Kamion> enjoy munching that CAT-5
<lamont> actually, he's bringing a couple of burnt CD's to lunch with him...
<Kamion> $ publish-release 20041013.1 rc
<Kamion> it might even work this time
<lamont> not rc1?
<Kamion> we've just been calling it "the warty release candidate"
<lamont> 'k
<mdz> there shall be one release candidate :-)
<pitti> One Disc To Rule Them All...
<lamont> mdz: and 3 elves, yes.
<lamont> I'm glad we didn't use an LoTR naming convention.
<mdz> sabdfl, make: do we have a finalized release candidate announcement to send out?
<sabdfl> we do
<sabdfl> before you send it I need to update the download page
<sabdfl> are we blessing the latest live cd as rc?
<mdz> unknown
<mdz> it has not had a single test yet
<Kamion> mirnyy's data transfer to/from little doesn't seem so great
<m_tthew> ETA ~25m on the linvecd image for me
<jdub> carlos: can you file a bug and attach a screenshot please?
<mdz> it is the very first live CD built at the data center, rather than by alex
* jdub wilts in the heat.
<mdz> carlos: he did already
<carlos> jdub: it's already done
<pitti> Will releases.u.o be updated as well?
<mdz> er
<mdz> jdub: he did alreaday
<mdz> already
<Kamion> RC published, have a nice day
<jdub> ah, ta
<carlos> mdz: btw, Happy birthday
<jdub> (not getting mail atm, letting lappy cool down)
<mdz> thanks
<Kamion> somebody have a look at releases.ubuntu.com please to make sure it's what y'all want
<mdz> looks fine to me
<pitti> so, no live cd?
<lamont> pitti: not until we test it...
<sabdfl> looks perfect
<Kamion> superb
<pitti> Kamion: congratulations!
<Kamion> now to actually fix the bugs in the publishing script that delayed that ...
<sabdfl> can i update the web site to point there?
<Kamion> yes
* lamont taps his foot
<lamont> hrm.. what's /dev/sequencer, I wonder?
<jdub> midi
<lamont> ah
<sabdfl> http://cdimage.ubuntulinux.org/releases/warty/rc/
<sabdfl> this is the canonical location, right?
<sabdfl> kinnding
<sabdfl> http://releases.ubuntu.com/warty/
* mdz listens to his alarm clock going off in the next room
<sabdfl> ok, page is updated
<mdz> thom: here?
<sabdfl> i think it's announcement time
<Kamion> sabdfl: either's fine, latter probably better
<mdz> thom: scp warty.iso potpal:warty-live.iso 
<mdz> er
<sabdfl> simpler's better
<mdz> thom: http://issues.apache.org/bugzilla/show_bug.cgi?id=31505
<Kamion> noting that if people look back to the RC announcement after the warty release, the link will no longer point to the RC
<lamont> mdz: iso?
<mdz> lamont: burning
* lamont considers this a lesson in patience.
<thom> mdz: *sigh*
<Keybuk> thom: ping?
<Keybuk> ah, there you are
<Keybuk> how did you add thermal and fan to the loadmodules file in mkinitrd ?
<mdz> thom: please roll a patch; we'll put this into final
<thom> mdz: ok, will get packages built ASAP
<mdz> Keybuk: /etc/mkinitrd/modules
<sabdfl> i will check the mirrors every hour or two, and point people at them as they get the cd images
<Keybuk> mdz: I looked at that, it's empty (apart from comments)
<mdz> Keybuk: oh, that
<sabdfl> so congratulations, warty team
<mdz> Keybuk: he patched mkinitrd
* Keybuk can't find the patch
<mdz> yes, congratulations
<m_tthew> way to go, guys.
<mdz> Keybuk: line 961
<Keybuk> because I think I just fixed the problem with fans and HP Compaqs
<sabdfl> happy birthday mdz!
<mdz> thanks
<thom> Keybuk: oh?
<Keybuk> ahh
<Kamion> happy warty^Wbirthday
<Keybuk> thom: you have to load 'fan' before 'thermal', otherwise thermal doesn't know there are any fans to control
<thom> gack
<thom> now you tell me :/
<Keybuk> which is why they don't come on :)
<Keybuk> thom: this seems to be a recent change; 2.6.7 the order doesn't matter, 2.6.8.1 it seems to
<Sledge> Kamion: did you get on ok with mkjigsnap now?
<Keybuk> (or maybe it always mattered, and acpid's init script happens to load fan before thermal because it's asciibetically less)
<Kamion> Sledge: I was instructed to concentrate on the release candidate that we just put out first, and come back to jigdo afterwards; returning to it now
<mdz> lamont, alextreme: Kernel panic: VFS: Unable to mount root fs on unknown-block(9,0)
<fabbione> guys good luck with the release
<elmo> sabdfl: w.ul.o/download/ will be fixed before we release, right ?
<alextreme> mdz: does the grub menu show up at all?
<fabbione> i have to go to the house and do some preparation work for tomorrow :((((
<mdz> alextreme: yes
<lamont> mdz: well, that's consistant at least.
<Kamion> is admins@admins.w.h.c still the right admin contact address?
<lamont> m_tthew: did you also get that with alex's new bits?
<sabdfl> elmo: what's wrong with it?
<alextreme> lamont: the buildlog is online?
<lamont> yes
<lamont> ~lamont/out.gz
<lamont> I think.  wherever the last one was
<sabdfl> erm, that's weird, i edited it
<m_tthew> lamont: with alex's build from yesterday, I got a boot (no mouse). with the most recent build, I am still waiting (~5m) on the iso download.
<Sledge> Kamion: understood
<thom> Kamion: yes
<mdz> failsafe mode gives the same results
<lamont> ok
<alextreme> k
<elmo> sabdfl: it refers to archive.ubuntu.com rather than releases.ubuntu.com
<thom> Keybuk: please file a bug
<mdz> alextreme: if a photo of the messages would help, let me know
<mdz> but it sounds the same as lamont experienced before
<lamont> alextreme: the most recent build has the `` changed into (), but that shouldn't really have mattered.
<sabdfl> oh hell there 's this new workflow system
<sabdfl> hold on
<sabdfl> and thanks :-)
<alextreme> mdz: nope, not worth the effort, i'll download and inspect it when i get home
<alextreme> lamont: indeed. if you don't mind, i have to run now. i'll mail you anything i can find and pop in here every now and then. the next few days just got slightly more... interesting :)
<lamont> alextreme: yes, please.
<alextreme> k, bbl
<mdz> thom: I have CVS revision numbers for the apache2 fixes, if you don't have them already
<mdz> thom: please reference CAN-2004-0885
<thom> i have the patches, yeah. ok
<thom> just throwing food down my neck
<sabdfl> elmo: looks like it could be the apache cache for the download page
<mdz> thom: don't choke; it doesn't sound all that serious
<sabdfl> thom: can you see if the download page is cached, and that's why it still points in the wrong place?
<sabdfl> thom: please ack on the cache front
<Kamion> hmmmmm
<Kamion> symlinking to .jigdo/.template files with different names is problematic
<Kamion> we may have to copy the .jigdo
<thom> sabdfl: sorry, was eating as previously stated
<thom> sabdfl: yes, it's in apache cache
<Kamion> same for the .torrent probably
<sabdfl> is that why http://www.ubuntulinux.org/download/index_html/ is different to http://www.ubuntulinux.org/download/
<thom> zope/plone appears not to bother sending Last-mod or etags or anything else remotely useful
<thom> sabdfl: yep
<sabdfl> can you jig it please
<sabdfl> how long will it cache it for?
<mdz> where did pitti go?
<thom> kicked
<sabdfl> thom: i'll need to update that page as more mirrors come on stream
<sabdfl> thom: thanks,we're golden for the anouncement
<m_tthew> lamont: same cannot mount root failure on the livecd as mdz saw.
<thom> sabdfl: 1 hour
<sabdfl> thom: ok, great
<sabdfl> that's the one that's going to be hammered from the announcement so it needs to be cached
<sabdfl> but we also need to be able to kick it when we rev the page
<Kamion> I've fixed the .jigdo and .torrent files now, I think
<Kamion> can somebody please test the .torrent?
<m_tthew> Kamion: yes, I will re-grab .torrents, the ones I have fail
<Kamion> Sledge: you might get productive results testing jigit against the release-candidate .jigdo files, actually
<sabdfl> neat
<Kamion> Sledge: at least just at the moment, since I don't think the archive has changed
<sabdfl> "Need to get 0MB of 400MB".
<sabdfl> nice round numbers
<Kamion> we did that specially
<m_tthew> Kamion: rejected by tracker - Requested download is not authorized for use with this tracker.
<Kamion> thom: any clue?
<Kamion> maybe torrent.u.c needs to be told about releases.u.c?
<thom> hang on
<Sledge> Kamion: ok, ta
<thom> the path has changed i guess, lemme check
<m_tthew> thom: let me know when I should try again
<thom> well, i grabbed http://torrent.ubuntu.com/releases/4.10/rc/warty-install-amd64.iso.torrent and it seems fine
<mdz> carlos: here?
<carlos> mdz: ye
<carlos> yes
<mdz> carlos: do you have a copy of the source for martin's hal fix?
<carlos> mdz: yes
<m_tthew> thom: ok, I was using the torrents from http://releases.ubuntu.com/warty/
<mdz> carlos: could you send it to me?
<Kamion> Sledge: ok, updated directions sent to admins, hopefully should work
<thom> but it likes releases.ubuntu.com not at all
<carlos> mdz: I have also ppc packages if you want
<mdz> carlos: sure
<carlos> mdz: http://carlos.pemas.net/ubuntu
<mdz> thanks
<carlos> I'm going to upload now the sources
* thom wonders why that shouldn't work
<thom> Kamion: releases.u.c isn't regenerated or any madness like that, is it?
<carlos> mdz: sources uploaded
<Kamion> thom: regenerated in what way?
<Kamion> thom: the torrents are regenerated, because the filenames have changed
<thom> we need to have those exact torrents on cdimage, or we need to move torrent to mirnyy then
<thom> otherwise the tracker can't see those torrents
<Kamion> don't get you, they are on cdimage
<Kamion> I don't think releases.u.c does any magic on mirnyy
<thom> are the torrents on auckland and mirnyy exactly the same? 
<thom> ok
<Kamion> I just did 'btmakemetafile http://torrent.ubuntu.com:6969/announce --comment "Ubuntu CD cdimage.ubuntu.com" `pwd`/warty-rc-install-amd64.iso' etc.
<Kamion> auckland's torrents will be different
<Kamion> because auckland mirrors www/full/ from little whereas mirnyy mirrors www/simple/
<thom> ok. the tracker has to have all the torrent files that people are going to request from it on its local filesystem
<thom> you're saying we don't have that currently?
<Kamion> www/full/releases/warty/rc/ and www/simple/.pool/ have warty-install-*, but www/simple/warty/ has warty-rc-install-*
<Kamion> thom: how does it find the torrent files?
<Kamion> thom: and where is the tracker?
<Sledge> Kamion: ah, difficult to test without .conf files
<Sledge> Kamion: I'm grabbing bits down anyway...
<thom> Kamion: you give the tracker and allowed dir, and it allows you to use any torrents below that dir
<thom> and it runs on auckland
<Kamion> thom: so just anything called *.torrent?
<Kamion> Sledge: oh, whoops
<thom> yeah
<Kamion> .conf is kind of a generic name ...
<Sledge> Kamion: yup
<thom> we're also gonna need to run seeders on mirnny then
<thom> or so all the .pool magic on auckland, which might well be saner
<thom> s/so/do
<Sledge> I can change that to something else if it helps
<elmo> thom: we need to get some load off auckland, and using mirnyy for releases is our best and about only hope
<Kamion> you could sync all of www/ onto auckland but only publicise www/full/, if it has space to do that
<Sledge> .jigit might be easiest
<elmo> I don't think we should not do that for the sake of torrent
<Kamion> sounds like seeders on mirnyy are a better plan then
<elmo> kamion: auckland has gobs of space, mirrny is the space restricted one
<Kamion> (p.s. please choose typable hostnames, kthxbye ;))
<thom> elmo: sure, not saying we shouldn't use mirnyy, just that the tracker needs to be able tosee the torrents and the files
<elmo> why can't we just also sync little::releases to auckland couldn't we?
<elmo> speak.  english.  good.  no.  me.
<Kamion> elmo: I thought that's what I was suggesting above
<thom> elmo: that would be best, i didn't know if there was some reason we hadn't?
<Kamion> i.e. syncing all of www/
<elmo> learn.  I.  it.  book.  from.  a.
<thom> Kamion: be glad that elmo added the 'i'
<thom> it's properly mrnyy iirc
<Kamion> jesus
<Kamion> (baby, crying, etc.)
<elmo> thom: no it was just late or early when I set up releases.u.c
<elmo> no, it really is 'mirnyy', at least according to the website we use
<thom> aww, ok
<elmo> thom: btw, that evil Russian name you wanted to use is apparently a joke name that roughly equates to 'New Miami'
<thom> right, so lets sync ::releases
<thom> elmo: rofl
<thom> that's even better then :-)
<Mithrandir> gobbing the .torrents off http://cdimage.ubuntu.com/releases/warty/rc/ is good, right?
<Kamion> Sledge: I'm mostly thinking that we want to have all of these in one directory, and it's getting confusing as it is with .iso, .iso.torrent, .list, .jigdo, and .templates for each of three architectures
<Mithrandir> or should I seed from some other URI?
<Kamion> in fact, maybe moving all the jigdo files elsewhere would be marginally more sensible
<Sledge> Kamion: ok
<Kamion> but AARGH TWISTY DIRECTORY TREE NIGHTMARE
<elmo> giggle
* thom watches Kamion's brain implode
<Sledge> I wasinitially thinking putting all the jigdo bits under /jigit/
<lamont> need more links to ../../../bar/foo/baz
* Sledge grins thom
<Kamion> Sledge: that makes sense, but jigit still needs to find the .iso doesn't it?
<thom> Mithrandir: that'll  be great
<Sledge> jigit doesn't ever need the iso, no
<Mithrandir> thom: I only have two 100Mbits to seed from, though.
<Kamion> thom: bittorrent won't know that cdimage/releases/warty/rc/ and releases/warty/ are the same thing, though, will it?
<Kamion> if we're publicising releases/warty/, then better to seed from that when it works
<Sledge> Kamion: ditto, other jigdo progs don't care about the iso either
<Kamion> Sledge: oh, ok, that's cool
<Kamion> I still have no idea where to put them, but it suggests ideas at least
<Sledge> *grin*
<Kamion> you missed the reorganisation of the cdimage tree
<Kamion> we now have two parallel trees with intermixing hardlinks and symlinks
<Sledge> eeek!
<mdz> is the twisty directory maze holding up the release candidate announcement?
<Kamion> I think cdimage/releases/warty/ is going to have to be considered legacy in its current form or I'll go nuts
<Kamion> mdz: torrents might be, directory mazes aren't
<Sledge> Kamion: does torrent need the iso too?
<Kamion> pass
<Sledge> ok
<Sledge> otherwise I'd lay it out
<elmo> what the heck is cdimage/releases/warty ?
<Sledge> /cdimage/<foo>
<Sledge> /cdimage/<foo>/bt
<Kamion> elmo: old layout, predating ::releases
<Sledge> /cdimage/<foo>/jigit
<Kamion> Sledge: makes sense
<Sledge> /cdimage/<foo>/iso>
<Sledge> how much effort to make torrent configs?
<Kamion> trivial, you run btmakemetafile and it does it
<Sledge> ok
<Sledge> just wondering if it would help to make one back-end script to do a CD release and DTRT
<Sledge> :-P
<Kamion> I've got publish-daily and publish-release scripts already which do most of the heavy lifting
<lamont> Sledge: I thought Kamion already "did that" [sic] .
<Sledge> I guessed you would... :-)
<Kamion> mdz: mm, if that was a "go away and stop distracting us", we'll move the detailed CD discussion elsewhere
<mdz> Kamion: no, it was an honest question
<Kamion> ah, ok
<mdz> sabdfl: is the release announcement waiting on anything other than torrents?
<mako> mdz: i'd like to look it over right now if it's changed since i left last night
<sabdfl> mdz: not from me, i've got my teflon trousers on already :-)
<mako> looks great
<thom> ok, last minute torrent hacking seems to be turning into a theme
<lamont> sabdfl: those are, like, slipperier than silk, yes?
<mako> lamont: i hear they're very popular in europe
<Keybuk> yay, the HP is a happy laptop once more
<Keybuk> thom: you know how a lot of people saw a change from 2.6.7 to 2.6.8 with the fans thing?
<jdub> you guys don't really need me any more
<jdub> it's 3am and i have meetings tomorrow :|
<jdub> i'm going to get some rest ;)
<Keybuk> it actually turns out that 2.6.7 didn't have your initrd change in it, and 2.6.8 did :)
<sabdfl> mako: and baghdad
<silbs> jdub: g'night
<thom> ok, tracker seems happy now, just hacking the seeders
<thom> m_tthew: please try again now? :-)
<m_tthew> thom: I regrabbed torrents from http://releases.ubuntu.com/warty/, bt seems happy but seedless (expected, I assume)
<thom> should be seeded now, i just this second kicked them off
<m_tthew> ok, keeping an eye on them
<m_tthew> my i386, which is complete, is sending upstream A-OK
<m_tthew> still not seeing any downstream on my incomplete amd64 and ppc torrents
<Kamion> thom: awesome, thanks
<m_tthew> there comes downstream on ppc
<m_tthew> and amd64
<m_tthew> all torrents look good from here
<thom> thanks for testing
<m_tthew> np
<mako>  we should change the text http://www.ubuntulinux.org/community/download
<mako> so it doesn't say preview release
<mako> i can do it
<mako> ergh. if i can find my pw
<sabdfl> do
<sabdfl> done
<sabdfl> but thom will need to kick the cache for it to populate
<sabdfl> mako: so is it good for announcement?
<mako> sabdfl: beat me too it
<thom> Totals:   2.5 MB/s 105.2 KB/s
<thom> wee
<mako> sabdfl: i'
<mdz> the new artwork has caused text breakage in non-english locales
<mako> i am going to add somethign to mention that the torrent file are at the download site
<mako> sabdfl: that's not entirely clear from the current text
<sabdfl> mako: mind if i do it?
<sabdfl> i'm right there
<mako> sabdfl: i did it
<mako> sorry.. was finished by the time i saw your message
<sabdfl> mako: then i think we just collided
<mako> if it lets you stomp on my changes, that's fine :)
<sabdfl> can you verify you're happy with the current state?
<sabdfl> shoudl we say RC instead of Release Candidate?
<mako> sabdfl: if we say the former we should have the latter at least once
<mako> our version numbering is confusing enough people as it is :)
<mako> sabdfl: looks good
<mako> my main concern was that the links at that page pointed to the correct place, which they do
<mako> this is nice timing.. i'm giving a talk on ubuntu tonight at the a new york lug meeting :)
<mako> their beginners group
<mako> gnubies
<Kamion> mdz: I noticed something being overprinted in Greek
<mdz> Kamion: someone reported a bug about Greek as well
<Kamion> which?
<mdz> in gdm
<mdz> never mind
<mdz> it was greek in openoffice
<mdz> #2337 points out Spanish and French as being broken
<mdz> are there photos of me on the website or something?
<mdz> someone just made a comment on -users about my lack of hair :-)
<mako> mdz: wow. :)
<silbs> mdz: maybe they think the guy in the artwork is you
<mako> hah!
* m_tthew laughs
<mdz> sounds like an infection meme; let it spread :-)
<mdz> I will neither confirm nor deny
<mako> what, you mean the guy in the picture is *not* mdz?
<mako> mdz: the uberhacker, the amature body builder, the model
<mdz> amateur??
* mdz poses and flexes
<Keybuk> he does look like he can walk up walls, now you mention it ...
<sabdfl> mdz: that's what a power nap will do for you
<mdz> s/infection/infectious/
<mdz> what it will do is cause me not to notice my own typos until several minutes later
<sabdfl> look, having met the guy, i can confirm that he's NO ROCKET SCIENTIST
<hornbeck> sabdfl, mdz: Off topic but is there anything in the works for a doc mailing list
<sabdfl> much prefer having mdz on board
<silbs> sabdfl: doesn't matter
<silbs> (that he's not a rocket scientist)
<sabdfl> hornbeck: enrico, sivang are collaborating now i think, ping them, sounds like a good idea
<hornbeck> sabdfl: I have been working with sivang but he is out in the cold also about what is going on
<mako> hornbeck: to start, conversations should just be on -devel prefixed with a [doc]  or something
<mako> hornbeck: i've been talking to sivang every couple days but have been samped teh last 2 or so
<hornbeck> mako: I will start pointing everyone to the devel list
<mako> hornbeck: if you guys want some direction or someone to bounce ideas off, lets organize a meeting in a couple days
<hornbeck> for some reason I have become the contact person for docs
<mako> hornbeck: i'm happy to help however i can :)
<hornbeck> mako: A meeting would be great
<mako> hornbeck: you stick your neck out, you get noticed :)
<hornbeck> I know what I am working on but others need direction
<mako> hornbeck: and it might be good to compare
<hornbeck> yeah
<mako> hornbeck: maybe plan for friday?
<hornbeck> mako: what time?
<mako> i think i should have dug myself out of the hole i'm in workwise
<hornbeck> 1600 UTC?
<mako> hornbeck: i think UTC 14-> would work
<hornbeck> friday at ubuntu-meeting
<mako> hornbeck: sounds good
<mako> hornbeck: throw out that message to the -devel
<hornbeck> I will put on -devel and ubuntu
<hornbeck> mako: 1400 UTC in #ubuntu-meeting
<mdz> I think an ubuntu-doc list could very well be in order
<sabdfl> yes, agreed on -devel with [doc] 
<sabdfl> as discussed in the cc ;-)
<mdz> there seems to be a lot of activity picking up
<hornbeck> mdz: there are alot of us and we need a place to talk
<mdz> -devel is very focused on packaging and release right now, and I appreciate that
<hornbeck> mdz: in the past two days I have had about five new request of how to join a doc team that does not exist
<sabdfl> hornbeck: please start on -devel though, then setup the list when traffic hits a threshold
<mako> as right
<hornbeck> sabdfl: I will direct everyone there
<sabdfl> oh, ok
<mako> hornbeck: that's exciting :)
<mdz> yes, there has been a great deal of activity in the wiki as well
<hornbeck> mako: yes it is 
<hornbeck> email is out
<hornbeck> hey
<sivang> hey john
<sivang> whassup?
<hornbeck> sivang: doc meeting friday, 1400UTC
<sivang> RC already out?
<hornbeck> #ubuntu-meeting
<sivang> ok, talked with sabdfl?
<mako> sivang: yeah, lots of people
<hornbeck> :)
<mako> sivang: i'll be there as well
<sivang> mako : really? what did I miss?
<mako> sivang: nothing that reading the mail on -devel won't fix :)
<sivang> ok
<hornbeck> read the regular list also about the unofficial faq
<sivang> hornbeck : already did :)
<hornbeck> that guy is mailing me direct now
<hornbeck> he is going to help out, I talked him into it
<sivang> great
<sivang> :)
<hornbeck> yeah hes a smart guy
<sivang> We need to join forces, not split up
<hornbeck> definatly
<hornbeck> well I have to go to a job interview
<hornbeck> wish me luck
<hornbeck> bbl
<mako> hornbeck: good luck
<sabdfl> hornbeck: break a leg
<sivang> mako : who else is going to be on the meeting?
<mako> sivang: all of the people who have expressed interested in doc stuff i believe
<sivang> mako : ok, sound neat.
<sivang> is RC out already?
<mako> sivang: http://www.ubuntulinux.org/community/download
<mako> although i don't thinkt he announcement went out
<mdz> sabdfl: your turn; now they're speculating that the man in the theme is you
<mako> man.. my email is not downloading right now.. i *really* want to read this thread
<sivang> mako : thanks - I'll download and start to test.
<elmo> LOL
<mdz> almost everyone protesting the artwork seems to be doing so on behalf of handwavy third parties
<Keybuk> yeah
<Keybuk> I've added a bunch of FAQs to the Ubuntu wiki for those that really feel the urge to change them
<mdz> I'm against it because...someone else might not like it
<elmo> can I change the wiki yet to point to releases?
<elmo> I guess so, given the website's been changed
<sabdfl> elmo: yes please
<sabdfl> i have to step out for an hour, see you guys shortly
<sabdfl> has any announcement been sent?
<elmo> have we actually got anyone responsible for sending it, or do we all think the other is doing it ? ;-)
<Kamion> elmo: well volunteered that man
<Mithrandir> have the url for the torrent changed?
<mdz> sabdfl: no, I thought you and mako were on that?
<Mithrandir> my box is sad, it doesn't upload anything.
* sabdfl cries
<sabdfl> mako: please send!
* elmo ponders the inevitable "How many Canonical staff does it take to send a release announce?" jokes
<sabdfl> thom: this is a very confidential.... nevermind
<mako> i'll send, i'll send
<sabdfl> cheers guys, hope i come back to some fireworks :-)
<sabdfl> have my phone with me in case
<Kamion> enjoy :)
<elmo> what's the "correct" form for rsync URLs ?
<elmo> rsync://host::module/path/ ?
<mdz> elmo: rsync://host/module/path
<mdz> :: is the non-URL syntax preferred by Kamion :-)
<mako> mdz: i'm sending the announcement to u-a now
<mako> i'
<mdz> mako: great
<mako> m going to double check the url's first
<sivang> mako : do send me the log of everything went with docs, I taking off for 30 minutes and will be back
<mako> sivang: after the announce goes out :)
<sivang> mako : sure no problem.
<Kamion> mdz: I'm hopelessly inconsistent about which I use
* thom notes he really needs to throw large things at mark next time he sees him
<Kamion> mdz: even I'd avoid rsync://host::module/path/ though :)
<elmo> thom: bribe jane
<elmo> Dear Jane, please pull large shelf unit down on to Mark.  kthxbye
<thom> i'll give that a whirl
<mako> the deed is done
<mako> RC has been announced
<elmo> did anyone else get it back yet?
<elmo> oh,nm
<mako> who knows how to update/alert distrowatch
<mako> we just hit LWN
<elmo> those lwn guys are super fast
* mako nods
* thom -> bed
<mako> jdub: if you know how to do distrowatch, please follow up on that one
<thom> mdz_: apache2 building currently, will upload first thing tomorrow
<mako> mdz_: do you want to fwd the announcment to debian-devel or is not worth it for an RC?
<mdz_> mako: I think we're getting increasingly off-topic for -devel
<mdz_> I don't want to keep pushing until someone tells us to go away
<mdz_> debian-user I think would be fine, though
<mako> i think we shoudl announce annoucnments
<mako> mdz_: it's a balance.. progency and linspire have been criticized for taking debian's stuff and just doing their own thing
<mako> mdz_: certainly, something other than just forwarding announcments would be good as well
<mdz_> mako: our RC announcement has essentially nothing to do with Debian development; it's off-topic
<mdz_> the announcement of our existence was pertinent, but I don't think that our every announcement is
* mako nods
<Kamion> debian-project would be arguable, although even there it's borderline
<mako> i don't disagree, that's why i suggested it miht not be worth it
<mdz_> we are more interesting to Debian users than Debian developers, which is why I suggested -user
<mako> elmo: 20:54 <Md> hi. I think ftp3.linux.it is still listed as an ubuntu CD mirror, please remove it because it's down and the stupid sponsor is not replying to email...
<elmo> mako: it's not on the website, mark took them all down until we can get confirmation they've got the RC
<elmo> but thanks
<amu> is there a need for a good connected german mirror ?  
<amu> ( Telefonica ) 
<mako> elmo: ?
<mdz_> mako: is the announcement sent?
<amu> mdz_: i got it ;) 
<mdz_> I haven't
<mdz_> I'd better be subscribed :-P
* sabdfl returns, expecting flames everywhere...
<sabdfl> how's it look?
<elmo> mako: ?
<elmo> sabdfl: not been slashdotted yet, so not much increase in activity
<sabdfl> Kamion: odd, on the test ipw2200 laptop, the wifi was detected and used during install, but it's not there after reboot
<sabdfl> fun
<sabdfl> the module is loaded though
<amu> .... or test the Live CD, you can download it here .... i cant find the liveCD :) *ducks* 
<sabdfl> dmesg shows:
<sabdfl> detected it
<sabdfl> then "failed to send TX_POWER command" fives times
<sabdfl> then it gave up
<mdz_> lamont: live CD?
<amu> hmm, if i change my laptop vom ethernet to wlan, i've to setup wlan everytime by hand ...i miss something like laptop-net, which handle ethernet,usb,firewire,vpn,gprs sessions        
<mdz_> amu: http://wiki.ubuntu.com/HoaryHedgehog
<amu> mdz_: again, it sounds cool ;) i didnt found encryption, ex. in german governments, encrytion is a must.       
<mdz> amu: encryption in which applications?
<amu> the hole harddisk or partions .... 
<amu> if they put sensible datas on their notebook and the book gets lost, i must be guaranteed that nobody comes to the datas. Very interessting   
<amu> http://www.bsi.bund.de/produkte/erposs3/index.htm
<lamont_p> moo
<lamont_p> silbs around still?
<mako> elmo: has anyone else here submitted it to slashdot???
<mako> actaully that was to everyone
<m_tthew> yes
<m_tthew> without spelling errors, this time.
<lamont_p> mako: any clue why a 5-pack would weigh 1kg?
<lamont_p> palm + irc is interesting
<mako> lamont_p: five pack of cd's?!
<lamont_p> yes
<mako> lamont_p: not last i checked
<mako> lamont_p: that's 2+ lbs
<lamont_p> q for silbs from a us bdder on the shipping
<lamont_p> e
<lamont_p> exactly
<fabbione> mdz: is alright for you if i take the tiff problem and fix it tomorrow morning?
<m_tthew> "2004-10-13 18:26:30 Ubuntu Linux 'Warty Warthog' Release Canidate Out (Linux,Announcements) (rejected)"
<m_tthew> I assume some more people tried
<lamont_p> .gah.
<lamont_p> anyway.  bbl
<elmo> mdz: ?
<hornbeck> I am getting alot of replys about the doc meeting
<mdz> fabbione: yes
<mdz> elmo: ?
<elmo> mdz: should snmp on linux provide 64-bit counters by default, do you know?
<mdz> elmo: I do not know
<mdz> elmo: sometimes it's enough to shorten the collection interval
<mdz> sucks with rrd, though, because it means generating a new rrd
<mdz> rrdtool has this magic where it tries to account for counter overflow
<mdz> which is normally nothing but a huge pain in the ass because it causes huge spikes whenever the snmp agent is restarted
<elmo> [13-Oct-2004 21:25:24*]  Received SNMP response with error code noSuchName. OID: 1.3.6.1.2.1.31.1.1.1.6.1
<elmo> :/
<mdz> mizar:[/tmp/net-snmp-5.1.2]  grep -i '64.*counter' TODO
<mdz> 64-bit counters
<elmo> doh
<mdz> there is a bunch of code for it, though
<mdz> it has a 64-bit counter data type
<elmo> why on earth does changing the collection interval mean trashing the rrd?
<mdz> it's the nature of rrd
<mdz> it's a fixed number of slots
<mdz> I suppose you could just make up data
<mdz> if it's evenly divisible, duplicate each sample N times or something like that
<mdz> I'm sure there are consolidation functions that would break with that approach, though
<mdz> but AVERAGE would stay the same
<mdz> hmm
<mdz> yeah, I think net-snmp might just suck in this respect
<mdz> seems to be able to retrieve 64-bit counters from devices which have them
<sabdfl> elmo: how's traffic looking?
<mdz> slashdot has given us the thumbs-down, it would appear
<m_tthew> apparently they find parrot more exciting
<mdz> we're on LWN
<azeem> mdz: resubmit to /. with 'Ubuntu release candidate with pr0n wallpaper'
<m_tthew> no doubt that is how the /. splash will eventually happen
<azeem> when exactly do you plan to ship the CDs?
<mdz> after the final release
<azeem> hmm, ok. It's just I'll be at Systems, Munich next week, so I could put some up at the Debian booth perhaps if they'd arrive till then
<mdz> you are free to bring some release candidate CD-Rs with you of course, but we only plan to press CDs for the final release
<azeem> sure
<Keybuk> I'm not surprised ... we've probably had all our /. coverage for a while now
<Keybuk> too many announcements too quickly
<sabdfl> patience
<sabdfl> is there a submission we can see?
<sabdfl> ftp://ftp.aditel.org/pub/isos/ubuntu-cdimage/releases/warty/rc/
<sabdfl> is that a mirror of today's release?
<Keybuk> according to the MD5SUMS file, yes
<sabdfl> 'k
<sabdfl> thanks
<vorlon> I don't suppose I can bug anyone here with a question about an ISO I downloaded yesterday that I can no longer find a link back to in order to check the md5sum? ;)
<Keybuk> vorlon: sure, the answer is "blue and ever-so-slightly salty"
<Mithrandir> vorlon: or sqrt(42/sqrt(pi))
<Mithrandir> :P
<Mithrandir> vorlon: please shoot.
<vorlon> Keybuk: damn, guess that means I'll have to redownload.
<Mithrandir> vorlon: rsync.
<vorlon> from?
<Keybuk> vorlon: was it one of http://cdimage.ubuntu.com/daily/ ?
<Keybuk> or something from http://cdimage.ubuntu.com/releases/warty/ ?
<vorlon> Keybuk: it was the main download link posted on ubuntulinux.com, US mirror.
<Keybuk> http://cdimage.ubuntu.com/releases/warty/preview/MD5SUMS
<Mithrandir> vorlon: archive.ubuntu.com::cdimage/releases/warty/rc/ somewhere. :)
<Keybuk> ^ that's probably the MD5SUMS file you want ... (guessing)
<vorlon> Keybuk: ah, n/m, it looks like this was actually a bad burn.
* vorlon is so used to having perfect burns that he hadn't bothered to check this. Meh.
<Mithrandir> this is weird -- https://bugzilla.ubuntu.com/show_bug.cgi?id=2348 , in normal mozilla. scroll down with the mouse wheel, and it stops approximately 500 pixels from the bottom.
<m_tthew> Mithrandir: I thought that was just me
<m_tthew> Mithrandir: it has not always been that way, I quasi-suspected CSS magic/crack.
<Mithrandir> sounds like a mozilla bug
<Mithrandir> since arrow keys work
<Mithrandir> and you get stuck at the bottom
#ubuntu-devel 2005-10-24
<sabdfl> elmo: ping
<sabdfl> Kamion: the .dsc file i'm looking at has a Source: and Binary: lines, and a Version:. It also seems to list 2 files, the orig.tgz and the diff.gz, with digests. Why does it not give the digest of the .deb too?
<sabdfl> is there a file which has the .deb's with digests, produced by a single build of the source package?
<jbailey> sabdfl: The .dsc file is for the source files.  The .changes file is for the .debs
<jbailey> The changes file also includes the digest for the .dsc.
<sabdfl> jbailey: ok. does the .changes file include sha1's?
<jbailey> sabdfl: They're md5sums.
<sabdfl> ok
<sabdfl> hmm... ok, that's a start, anyhow
<jbailey> I can include my standard wishlist response about package signatures here. =)
<sabdfl> jbailey: you betcha. we need to improve the whole structure. only question is how to transition it :-)
<sabdfl> though it does work remarkably well
<jbailey> I think it depends which problems we're trying to solve first, really.
<jbailey> The nice part is that almost any change I can think of has been debated around enough times, so we never have to start from square 1.
<sabdfl> we just have to pick a square? there are so many to choose from. vote for mjg59 to improve our square selection algorithms.
<sabdfl> where can i get the copy of the .changes file for any given binary in the archive?
<ogra> heh
<jbailey> Isn't he a biologist?  I don't think square things occur in biology. =)
<kiko> ahoy changes people
<jbailey> The .changes files get eaten by elmo's harem in processing.  IIRC, In Debian they're kept somewhere for auditing afterwards.
<kiko> jbailey, are they in katie, I wonder -- or the information?
<ogra> they are at least on a -changes ML
<jbailey> kiko: Dunno.  I looked at it when I was running the hurd-i386 buildd, and when I was writing multibuild and turtle, but that was a few years ago. =)
<ogra> after katie processed them...
* Loiosh wonders how HURD is going.
<ajmitch> hello kiko 
<jbailey> s/writing/helping write/
<kiko> hey ajmitch 
<schweeb_> fabbione: around?
<lifeless> `anthony: ping
<Kinnison> ciao all
<bddebian> Hello
<Am|NickTaken> bed time
<fabbione> morning
<Keybuk> ARE WE THERE YET?
<fabbione> bella Scott
<schweeb_> fabbione: have you heard much from anybody installing the SPARC port?  gonna be messing around with it on my blade 1500 in the next few days
<fabbione> schweeb_: yes i did hear from several people. What do you need to know exactly?
<fabbione> schweeb_: i can tell you that in 99% of the cases X autoconfiguration will not work and mostlikely hang your machine at end of phase2
<fabbione> schweeb_: if your box is SMP with Sparc III or > you need to run UP kernels
<schweeb_> heard anything specifically from people on 1500s possibly?
<schweeb_> it's a single proc IIIi, 1.5ghz, iirc
<fabbione> schweeb_: if you have qla2200 controller or similar you might get a problem on the 3rd reboot (patch is pending for the next kernel)
<fabbione> UP is fine.
<fabbione> schweeb_: i think David Miller installed on his SB1000
<fabbione> without any problem
<fabbione> other than X.. that's it
<fabbione> and they are pretty similar hw
<schweeb_> is there a ports mailing list or anything, or where is the proper place to discuss this, so I don't bug people (you) on dev all the time :-P
<schweeb_> (ports mailing list that is)
<fabbione> schweeb_: we have #ubuntu-ports
<fabbione> no mailing list yet
<fabbione> but the traffic is still low, so there is no point in abusing infrastructure for a ML
<schweeb_> right
<fabbione> schweeb_: anyway i am pretty sure you are goot to go on that box
<schweeb_> I'm just hyped to possibly get rid of Solaris 10 at work, heh.... my last experiences with hoary and Blade 2000 weren't that good though
<fabbione> schweeb_: yes i know.. hoary was crap on sparc
<fabbione> at least the installer works for breezy
<fabbione> and in theory it goes all the way to gdm :)
<schweeb_> heh
<fabbione> (modulo X autoconf/hanging)
<schweeb_> I can handle X config
<fabbione> exactly :)
<schweeb_> been doing that crap for years now
<fabbione> schweeb_: btw.. OO2 on sparc is way way way faster than the amd64  equivalent :P
<schweeb_> haha
<fabbione> and i mean a lot faster
<fabbione> amd64 3000+ 1G or RAM idle.. 16 secs to open oowriter
<schweeb_> all I do with my workstation is run remote X apps, and 3270, for the most part
<fabbione> sparc64 433Mhz 512MB of RAM busy as buildd... oowrite 19 secs.
<schweeb_> I just feel more comfortable in a linux environment
<fabbione> schweeb_: eheh i understand.. slowlaris is not exactly nice, if you don't know it in deep details
<schweeb_> fabbione: if I weren't proxied off, I'd offer up a few workstations for distcc'ing
<schweeb_> chrysler has me all proxied though
<fabbione> schweeb_: thanks :) don't worry
<lifeless> distcc-over-irc :)
<schweeb_> fabbione: I have 4 1.5Ghz Blade 1500's w/ 1G RAM that sit and don't do much
<fabbione> schweeb_: ever played with vtun? :P
<fabbione> schweeb_: that would be 4 really nice buildd :P
<schweeb_> ssh tunneling of any sort doesn't work
<schweeb_> not sure how vtun works though
<fabbione> schweeb_: check vtun on port 80 :)
<schweeb_> I know when I was doing SSH tunneling over 443, they figured it out, and looked for the OpenSSH advert
<fabbione> ah
<schweeb_> so they're doing some kind of app layer filtering or something now
<fabbione> they are not that blind than
<schweeb_> right :-/
<fabbione> schweeb_: what protocols can you contact outside?
<schweeb_> HTTP, HTTPS, FTP
<fabbione> oh plenty
<schweeb_> I'll hafta look into vtun
<fabbione> schweeb_: check vtun.. and see if you can make it to talk on port 20
<fabbione> (ftp-data)
<schweeb_> most of the stuff I saw that people used revolved around running SSH on alternate ports, so I kinda gave up
<fabbione> there is no way a proxy can really understand what kind of traffic is passing there
<schweeb_> at least I think I can do FTP, haven't tried in a while
<schweeb_> not much in the way of docs
<schweeb_> fabbione: well, if I can scrounge up a blank CD somewhere, I'll have an installation report for you tomorrow
<fabbione> schweeb_: you need to do netinstall
<fabbione> CD installs are broken
<fabbione> but the netinstall can cope with proxies just fine
<schweeb_> ugh
<fabbione> well if you are talking about the miniso it's fine
<schweeb_> I couldn't get rarp working today
<fabbione> but you can't do pure CD installs
<schweeb_> yea, mini.iso "net install"... CD boot, networked install
<fabbione> i wrote that in the announce 
<fabbione> yup
<fabbione> that works just fine
<schweeb_> good good
<schweeb_> couldn't get rarp or bootp working... think they block broadcasts at the switches
<fabbione> yeah that's not an issue.. just use the miniso
<schweeb_> k
<fabbione> but you can't do normal CD install because apt is crashorama with sources.list deb file://
<fabbione> and we did find out a bit too late
<schweeb_> hehe
<schweeb_> well, I'm headed to bed
<fabbione> good night
<schweeb_> got an early meeting w/ mgmt... thanks for the help
<fabbione> no problem!
<fabbione> looking forward to hear how it did go
<dholbach> hellas!
<bob2> guttentahg
<dholbach> nearly :)
<dholbach> "guten tag", but you were close :)
<bob2> ah, dang
<daniels> good morning, face of motu
<HiddenWolf> dholbach, guten morgen is correct also, right? :)
<Keybuk> http://www.google.com/intl/xx-klingon/
<Keybuk> ...why have I never seen that before? :p
<dholbach> HiddenWolf: yes :)
<fabbione> Keybuk: did you see the hacker one?
<dholbach> good morning daniels
<HiddenWolf> dholbach, thanks, my German is rusty. :S
<bob2> oh, wow
<bob2> you're #1 on google for "face of motu"
<dholbach> WOW
<bob2> 30-odd for MOTU
<Lathiat> haha
<dholbach> now we just need some more people :)
<HiddenWolf> dholbach, time will get you that. :)
<dholbach> ouch... just read, there's a guy who called his son "google"
<HiddenWolf> dholbach, that'll get him a job, and his son a life in hell. ;)
<infinity> And when that kid gets older, and people ask him "Hey, Google, what's up with <thing X>?", he can shrug and reply "search me..."
<HiddenWolf> That's a name that'll get him into trouble.
<HiddenWolf> When he's out at night, and a police officer is asking for his name, and he says google, they'll likely bring him in for being cheeky.
<HiddenWolf> There was that story about Winston Churchill's son, Winston Churchill jr, who got beaten by police because they believed he was messing with them...
<dholbach> how do i set myself as default assignee for packages in bugzilla?
* jsgotangco jumps ahead of scheduled bug day
<dholbach> :)
<dholbach> hey jerome, how are you?
<ajmitch> evening all :)
<jsgotangco> still alive :-) cleaning up some training materials i got from the IOSN...colin charles was the one who did the project and used the hoary live cd to make a custom cd for the IOSN
<dholbach> oh wow
<jsgotangco> yeah it's blue :)
<jsgotangco> the training materials are still in fedora though
<jsgotangco> its not a bad thing (fedora) but the materials just dont fit atm
<Amaranth> anyone got some time to kill?
<fabbione> Amaranth: ???
<Amaranth> http://dev.realistanew.com/alacarte-0.8beta2.tar.gz (new version of smeg)
<Amaranth> extract and run alacarte-0.8/src/alacarte
<Amaranth> i need people to try to break it
<Amaranth> fscking gmail dies right when i need an attachment from one of my mails
<Amaranth> night folks
<jsgotangco> wwooo so its now alacarte :)
<pitti> Good morning
<dholbach> hellas pitti
<hunger> Hi pitti
<\sh> moins
* dholbach -> dogwalk
<mvo> hey pitti 
* mvo waves to \sh 
<jdub> ogra: http://www.stroven.org/blog/?postid=63
<pitti> mvo: yay apt-get source -t hoary :-)
<dholbach> jdub: already told him, he was quite pleased :)
<Treenaks> jdub: Hey, you found your way back to The Buttplug? :P
* dholbach hopes this is an insider joke, he doesn't yet get
<mvo> pitti: needs testing, but works for me(tm) :)
<jsgotangco> have you guys seen the Ubuntu-tan?
<Treenaks> dholbach: http://olympiads.win.tue.nl/ioi95/photo/fot4.jpg
<Treenaks> dholbach: the national war monument, re-christened "The Buttplug" by jdub 
<jsgotangco> Treenaks, errr nice
<Keybuk> spooky, I have that almost exact picture
<Treenaks> Keybuk: most tourists do :)
<Keybuk> and I stayed at the same hotel as jdub
<pitti> mvo: well, for apt-get source this sounds relatively easy, compared to apt-get install 
<Keybuk> jdub is stealing my past!
<zyga> morning
<Treenaks> Keybuk: oh no! next thing you know he'll start hacking on dpkg
<Keybuk> seems Diziet is doing that these days
<mdz> morning
<mvo> hey mdz, isn't it in the middle of the night for you?
<mdz> 0042 local time
<mvo> good morning then :)
<fabbione> hey mdz
<ajmitch> morning mdz :)
<Mithrandir> teh mdz.
<ogra> jdub, yeah, its already in the topic of #edubuntu ;)
<ogra> morning :)
<jdub> http://www.livejournal.com/users/jwulf/7170.html
<jdub> fedora guy about ubuntu ^
<Keybuk> they're learning
<Keybuk> you know Alex, the FP girl?
<Treenaks> frontpage?
<Keybuk> Fedora Project
<jsgotangco> fedora live? not a bad idea
<Burgundavia> jsgotangco, they got money from Google to do it
<jsgotangco> Colin Charles told me about it as well a few days ago
<bob2> who is in here spying on us at this very moment!
<jsgotangco> lol
<Keybuk> Alex Maier
<Keybuk> found her business card, heh
<Keybuk> bumped into her at LinuxWorld, she was sniffing for how to make FUDcon and the Fedora Community in general better :P
<jdub> hrm, archive seems to be out of sync again
<jdub> Znarl, elmo: ping
<fabbione> jdub: yes.. i already opened an rt request for it
<jdub> ta
<fabbione> 2 mirrors and ports are in manual mode = desync every 30 minutes or every time there is a security/updates upload
<Znarl> jdub : I'll sync archive.
<sabdfl> Kamion: some questions about the soon-to-be-announced server iso's
<ajmitch> sabdfl: what did you mean with this change? : https://wiki.ubuntu.com/DeveloperResources?action=diff
<sabdfl> ajmitch: as discussed, where we are creating the packages, we don't do that
<sabdfl> Xorg
<sabdfl> and others
<ajmitch> right, in universe we tend to do that though
<sabdfl> i'm even not convinced about the first bullet point, since cross grading is not supported
<sabdfl> ajmitch: please don't
<Kamion> there's actually a problem with initramfs-tools at the moment due to that - it's been incorporated into Debian, and now is being developed on both sides with clashing version numbers
<ajmitch> specifically that it becomes 1.2.3-0ubuntu1
<Kamion> Debian initramfs-tools 0.31 != Ubuntu initramfs-tools 0.31
<seb128> is there any plan to fix the website certificate?
<ajmitch> so that we don't get those problems as Kamion says
<sabdfl> elmo told me to tell people the certs are broken because he is crap
<sabdfl> ;-)
<seb128> ah ah :)
<sabdfl> if we do the work to get it up, debian can defer to that
<Kamion> they generally won't, though :-)
<sabdfl> Kamion: on the server iso's, is smp installed by default
<sabdfl> Kamion: the polite folks will win over, given time
<ogra> sabdfl, the versioning is important in universe for packages entering debian at some point. they can be synced more easy so we lower the workload
<sabdfl> ogra: debian can equally well sync from ubuntu
<Kamion> sabdfl: should be; the SMP kernels are on the CD
<sabdfl> we should not put ourselves in the position where we plan to do the work on both sides
<Kamion> haven't tested though, I have no SMP systems :-)
<sabdfl> that's not collaboration
<sabdfl> Kamion: so, in theory, it should detect that and install the smp ones by default?
<sabdfl> if its an smp box?
<Kamion> sabdfl: in theory. we're missing some changes to d-i post-breezy-UVF that improved SMP detection
<Kamion> so I would not like to guarantee it
<sabdfl> ok. i'll trust in The Force and put it in the announcement.
<Kamion> rootskel (1.19) unstable; urgency=low
<Kamion>   * Add boot scripts for x86 and alpha to grep dmesg for strings indicating an
<Kamion>     SMP machine and store this info in /var/numcpus for later use by
<Kamion>     base-installer. This avoids the info being lost when the ring buffer
<Kamion>     overflows.
<Kamion> specifically that
<sivang> Morning all!
<pitti> Hi sivang 
<ajmitch> morning sivang, pitti 
<Kamion> sabdfl: even if that fails, people will at least get the -686, -k7, -amd64-k8, etc. kernels, which is still an improvement
<ajmitch> sabdfl: if we upload as 1.2.3-1, and debian does the same with a different package, we'll get changes overwritten on next debian upload
<\sh> sabdfl: so you think we should name new packages in debian as it is with new packages in debian? maj.min.rev-1?
<Kamion> right, including "ubuntu" in our version numbers is a defence
<Kamion> against autosync
<Kamion> if we drop it we're going to get autosyncs when we don't expect them
<\sh> grmpf...
<\sh> 10:48 < \sh> sabdfl: so you think we should name new packages in debian^Wubuntu as it is with new packages in debian? maj.min.rev-1?
<ajmitch> \sh: patience :)
<Kamion> ajmitch: he was correcting himself, "debian^Wubuntu"
<sabdfl> hmm.
<ajmitch> aha
<sabdfl> in future, we will be syncing from LP to LP, which gives us the ability to be smarter about this
<ajmitch> the autosync issue shows up when we have differing dependencies for example (python 2.3 vs 2.4)
<Kamion> even so it will be difficult to accurately merge changelogs (on the human side) if version numbers clash too often
<Kamion> and just highly confusing in general
<Kamion> with good cooperation I agree you can resolve most problems, but you do have to have active cooperation :)
<\sh> sabdfl: I don
<Kamion> I recently added an epoch to new rewritten tzsetup-udeb and apt-setup-udeb packages in Debian to make sure they would supersede our base-config-based hacks, for instance
<\sh> sabdfl: I don't see the point? what is the problem at all, to have something line -0ubuntu1? it gives the utnubu people the possibilty to see new packages in ubuntu and not in debian easily..and I think it's better for a good co-operation of ubuntu and debian... a plain debian version scheme will cause more confusion
<sivang> hey ajmitch , pitti 
<\sh> s/line/like/
<sabdfl> \sh: part of the challenge of collaborating with debian is that the debian guys tend to assume they should not have to think or do anything different
<sabdfl> if we continue to reinforce that, there's no incentive for them to decide they really want to collaborate
<sabdfl> collaboration is a two way street
<ogra> the big advantage is that debian grabs our packages, does the main work on them and we can easily resync and only do minor tweaks... we loose this ability
<sabdfl> no matter how far we bend, we can't do it alone
<pitti> sabdfl: but what does this have to do with version numbers?
<sabdfl> pitti: nothing, except that our current sync system looks at them, imo
<pitti> sabdfl: by not being able to tell apart the origin of a package, we make it harder for both us and Debian AFAICS
<sabdfl> pitti: why should debian own OUR package version namespace?
<sabdfl> and in LP, we can tell the origin of a package
<pitti> sabdfl: it's not ours
<Kamion> because it's not our namespace
<sabdfl> yes it is
<pitti> sabdfl: Debian invented it and we adopted it
<Kamion> we are merging with Debian; in order to do that we MUST share the namespace
<pitti> we based Ubuntu on Debian, so it is unfair to hijack Debian's namespace
<sabdfl> were not hijacking it
<Kamion> the fact that we're merging means that we have to] 
<sabdfl> the issue comes when packages move between the two
<sabdfl> so, we need to be smart when we bring debian packages into ubuntu, and they need to be smart when they do the reverse
<pitti> sabdfl: you mean an Ubuntu package is adopted to Debian?
<pitti> right
<sabdfl> if we assume the responsibility of getting it right both ways, we will always be on the back foot
<pitti> debian->ubuntu works well so far, I see the difficulty in the other direction
<Kamion> I agree that Debian need to be smart, but it's not Debian we're helping by -0ubuntu1, it's ourselves
<ogra> pitti, worked fine in the past
<sabdfl> pitti: currently debian -> ubntu depends on the version number, for autosync
<pitti> so you mean we can't easily sync ubuntu packages to debian
<sabdfl> we can discuss this more at UBZ
<pitti> yes, probably better
<sabdfl> the main thrust of what i'm getting at is not technical, it's psychological
<pitti> probably I don't see the full background yet
<dholbach> sabdfl: i'd perfectly agree with you, if the changelog would be as clear as possible (referring to patches that are available on the net and changes are mentioned)
<ogra> sabdfl, it currently depends on the -XubuntuX tag, not on the numbering
<dholbach> but in the most cases it's not
<Kamion> I think we need to consider other technical approaches, or we're going to shoot ourselves in the foot
<sabdfl> we need to see the relationship between ubuntu and debian as one of peers, not master/servant
<sabdfl> and they need to do so too
<pitti> sabdfl: it almost seems that we need kind of a "Distribution:" field in source package .dsc files
<Kamion> it's called Origin:, HTH
<sabdfl> if we continue to act in a master/servant way, it will reinforce that perception on the other side
<pitti> Kamion: oh, thanks
<sabdfl> anyhow
* zyga keeps listening with great interest
<pitti> we need *something* that tells apart Ubuntu and Debian versions, otherwise we'll step on each other's feet
<ajmitch> pitti: agreed
<zyga> what about -ubuntu- ?
<pitti> I agree that there are maybe more elegant somethings than the version
<ogra> sabdfl, i dont see a master/servant thing here, we create a package, debian grabs it, does the further work and we can resync from them ith having less work
<ogra> it saves manpower
<ogra> (for us)
<sabdfl> ogra: if we are the ones always having to step out of the namespace, we are the servant
<Keybuk> sabdfl: I agree with you philosophically, but technically your argument is bullshit :p  we need that ubuntu marker so we no not to overwrite our own changes when we take from Debian
<dholbach> the problem is rather finding the changes, not indicating that there were changes at all, which kamion already said
<sabdfl> kamion's point on defensiveness is exactly right
<Keybuk> we can talk about removing it when we have an LP sync infrastructure
<sabdfl> it *does* help us to stay out of debian's way
<\sh> well...actually it sounds like the RPM problem a couple of years ago
<sabdfl> but that also reinforces the perception, on both sides, that we should somehow always defer
<Keybuk> it isn't there for debian, it's there for us
<Kamion> \sh: yeah, and RPM is now a hideous minefield nobody trusts because they broke each others' namespaces
<zyga> Keybuk: BTW: I've got a patch for your fanboy applet
<pitti> maybe we can actually use Origin: for that distinction
<ajmitch> seeing two packages with the same version, yet different changes made, is going to be very confusing
<sabdfl> we'll figure it out
<\sh> Kamion: yes...because there was no way to tell if it's a redhat/suse/mandrake rpm...only from the inside u could see who worked out more strange code ,-)
<sabdfl> the goal we set was to be "good at collaborating", but that does not mean "avoiding stepping on other toes"
<pitti> sabdfl: sounds like an interesting BoF topic :-)
<Kamion> there's also the issue of dependencies
<Kamion> versioned ones, specifically
<sabdfl> pitti: we spoke about this at both mataro and sydney
<Keybuk> there's also the issue of finding a common base for merges
<Kamion> I realise our current system is a bit broken (1.0-2 > 1.0-1ubuntu1 but not necessarily an ancestor), but at least if you see "ubuntu" in a versioned dependency you know that it depends on an Ubuntu feature and can take account of that while merging
<sabdfl> and the conclusion in both cases was that it is not possible to do a proper job of giving apt enough information to know exactly how to cross-grade
<pitti> oh, then I probably had been in other BoFs at that time
<Keybuk> we can't do that if we can't trust our changelog to not stamp over debian version numbering
<Kamion> if we lose that we will really have no clue whatsoever about what's going on
<Kamion> I rely on that in debconf/base-config/similar a lot
<sabdfl> therefor, it makes no sense to give the IMPRESSION that it is doable.
<Kamion> I'm not particularly bothered about cross-grading personally
<Keybuk> sabdfl: but those ubuntu markers _are_not_ there for cross-grading
<sabdfl> keybuk's right, this does depend on our ability to know automatically the pedigree of a package, and be smart
<sabdfl> Keybuk: they were initially
<Keybuk> no, they weren't
<sabdfl> yes they were
<Keybuk> they were also there so we knew where to merge from
<infinity> sabdfl : The only way to cross-grade halfway reliably is with a pin-priority > 1000, which will force downgrades to the "right" packages.  I'm not sure changing how we version things will fix that.
<sabdfl> no, thats just how you started to use them :-)
* \sh looks at his glas sphere....and is seeing libx11-dev (>= 7.0.1@ubuntu) or (>= 7.0.0@debian) where ubuntu/debian is coming from an "Origin/Distribution" field in control ,)
<zyga> \sh: that's a good point
<sabdfl> \sh: that's the point. we can't reliably provide enough information for the package management system to understand two distros
<Kamion> letting developers know what's going on on either side is far more important than cross-grading or anything to do with apt IMO
<sabdfl> LET ALONE debian + ubuntu  + guadalinex
<ajmitch> infinity: which is what I did to do sid->breezy, and that was rocky enough
<sabdfl> and there are those who will try to make that work :-)
<Kamion> without feature dependencies we don't have a better option there currently
<sabdfl> Kamion: right, but there must be a better way to do that than trying to bung this info in the version number
<sabdfl> we had this conversation in mataro
<sabdfl> look at the rpath mess
<sabdfl> branched version number hell
<dholbach_> it requires more organisation and clarity in the packaging on both sides, i don't think we can solve that technically
<Kamion> sabdfl: definitely in the future, but it's *not there yet* so abandoning our current system before it's there is scary
<sabdfl> ok, agreed
<sabdfl> Kamion: ^
<ajmitch> good
<Kamion> I really like feature dependencies and I wish we had them about once a week
<sabdfl> Keybuk: ^
<Keybuk> Kamion: elmo thinks they're total crack :p
<\sh> sabdfl: please change the wiki page to something like "Packages not in debian yet should end with revision -0ubuntu1 (TBDiscussed)" ,-)
<pitti> Kamion: but it seems that this requires far more discipline and awareness from package maintainers than the current system
<Kamion> pitti: that's true
<Kamion> of course package maintainers for whom it doesn't matter don't have to use them
<pitti> Kamion: e. g. for libraries we can generate versioned deps with shlibs, we can hardly do that with features
<pitti> it would rock, but I'm not sure whether it scales robustly to 10.000 packages
<Kamion> I don't think it would be needed in 10,000 packages
<sabdfl> \sh: please go ahead and make that change
<pitti> no, of course not
<Kamion> stuff like debconf and cdebconf is where it really wins - at the moment we're trying to transition to cdebconf yet nobody knows what features in debconf people are really relying on that aren't in cdebconf yet
<pitti> well, it certainly shouldn't replace shlibs anyway
<\sh> sabdfl: do u have something like a bof to link to? so we know about what we're talking :)
<sabdfl> \sh: please add a spec "PackageVersionConflicts", register in LP and add to UBZ agenda
<sabdfl> Kamion: does the server iso avoid usplash?
<Keybuk> there's a UBZ agenda now?
<Kamion> and people are doing debconf (>= version-where-some-feature-was-added) | debconf-2.0 without any guarantee that the debconf-2.0 provider includes that feature
<Kamion> $ cat data/breezy/preseed/ubuntu-server/ubuntu-server.seed
<Kamion> # Don't install usplash.
<Kamion> d-i     base-installer/kernel/linux/extra-packages-2.6  string
<sabdfl> Keybuk: https://launchpad.net/sprints/ubz
<Kamion> sabdfl: yep :)
<sabdfl> Kamion: good man
<Keybuk> sabdfl: cute, that's working now ... it gave me System Error when I played on localhost :p
<Kamion> (likewise the server mode in our normal images)
<fabbione> sabdfl: server iso's are the rock.. Kamion did really really really good there :)
* sabdfl can picture the horrified look on an elmo-clone's face when confronted with a usplash...
<Kamion> heh
<Keybuk> sabdfl: elmo would just compile his own kernel and disable initramfs support
<Keybuk> s/would/does/ :p
<sabdfl> do we manage to avoid any other installer questions in the server case?
<Kamion> somebody filed a bug about ten minutes after the first image that added usplash
<Keybuk> sabdfl: those are all LP specs, is there one for Distro?
<Kamion> sabdfl: we never show that "download language support packages?" question; it's forced to false
<Kamion> sabdfl: apart from that, no others at the moment
<ajmitch> Keybuk: https://launchpad.net/distros/ubuntu/+specs ?
<pitti> Kamion: do you configure a proper root user on servers? or use sudo as well?
<fabbione> Kamion: i don't even think there is space to remove more questions, is it?
<Kamion> pitti: still sudo
<Kamion> by the elmo-o-meter I figured that was probably ok ;)
<pitti> Kamion: I learned to love sudo on my desktop, but I'm still using root on my server; but maybe that's just me
<infinity> pitti : I don't have a password on my root users on servers.
<infinity> pitti : (I sometimes have a joey-inspired root backdoor user if I feel the need, but root itself has no password)
<pitti> infinity: I'm still paranoid enough to not allow root ssh login, so that an attacker has to overcome two passwords
* \sh sounds like a LP n00b, _but where do I add the spec?_
<sivang> sabdfl: how do you add something to the ubz agenda? this page seems immutable
<infinity> pitti : They'd have to overcome an SSH key and a password for me, since I only use passwords for sudo, not for SSH logins.
<ajmitch> \sh: see URL I pasted above 
<sabdfl>  * Includes server-oriented kernels with out-of-the-box
<sabdfl>    automatic support for multiprocessor systems
<sabdfl>  * Includes a wide variety of popular server applications
<sabdfl>    such as apache, mysql, postgresql, php, zope, openldap,
<sabdfl>    bind, samba, all on the single CD, ready for installation
<sabdfl>  * A slim default installation, occupying just 400 megabytes:
<pitti> infinity: right
<sabdfl>    add only the software you need, for a clean, maintainable
<sabdfl>    configuration.
<sabdfl>  * Provides no desktop environment (GNOME, KDE, etc.) by default
<infinity> pitti : So, similar effect, but still no root password (and easier sharing of root privs with others)
<sabdfl>  * Safe and text-oriented boot mode for better clarity and
<sabdfl>    infinite justice on boot.
<sabdfl>  * Secure by design, with no network ports active after install
<sabdfl>    and automatic, free security updates activated
<sabdfl> would that be fair?
<Kamion> infinite justice> :-)
<Kamion> that looks pretty good to me
<sabdfl> a little fnord for those who care
* infinity thinks the last point was actually a mistake, and the 'server' image should have installed openssh-server, but whatever.
<pitti> Kamion: oh, just to make sure (I haven't checked): you install "postgresql-8.0", not "postgresql", right?
* sabdfl thinks infinity does not remember the last openssh-server vulnerability
<Kamion> pitti: both 7.4 and 8.0 are on the CD
<Kamion> we don't install either by default
<sabdfl> nothing should be installed by default
<pitti> ah, I see
<infinity> sabdfl : s/last/only/?  Yeah, I still remember the hell we went through in Debian getting that all sorted.
<Keybuk> Kamion: oh, that reminds me, I had some weird freaky error from ssh early
<Kamion> pitti: bare postgresql isn't on the CD, only postgresql-<stuff>
<\sh> ajmitch: thx...but first I have to do real life work :(
<Keybuk> Kamion: Corrupted MAC on input
<pitti> Kamion: good, thanks
<Keybuk> Kamion: any idea what that means?
<ajmitch> \sh: yeah, I know how that feels :)
<Kamion> Keybuk: er, usually means actual network data corruption AFAIK
<sabdfl> infinity: yeah, i only remember one too.
<Keybuk> it went away after I rebooted the server
<infinity> sabdfl : But on any "server" worthy of the name, SSH is your only head (unless you're lucky enough to have LOM hooked up)
<Keybuk> isn't network data corruption impossible under TCP? :p
<Kamion> it means that the MAC on (seqnr, packet) didn't match
<sabdfl> infinity: point being, if he installs it, it's HIS head ;-)
<sivang> lol
<infinity> <shrug>... Fair enough.  We're all bright enough to install ssh ourselves.
<infinity> I'll retract my opposition. :)
<Kamion> Keybuk: well, either that or ssh is horribly confused, obviously, but I don't know the packet layer anywhere near well enough to guess
<sabdfl> \sh: go to any product, or distro, in launchpad, click on Specifications tab at the top, then "Register New Specification"
<infinity> I still need to look at the base package set that server installs get, and see if we can make it even smaller.  I tend to start from just about nothing on my machines.
<Kamion> Keybuk: did restarting sshd not help?
<sabdfl> so, https://launchpad.net/distros/ubuntu/+specs
<sivang> ha! found it :)
<Kamion> it won't make any difference to the server install, but I'd like to move the filesystem stuff from minimal out to standard at some point
<sabdfl> \sh: to add a spec to the UBZ agenda, first register it in LP as above, then view the spec, and look for "Add to Meeting Agenda" in the menu
<Keybuk> Kamion: no
<Kamion> Keybuk: sounds like your TCP stack blew up, to me
<Keybuk> the machine's been freaky for a while
<Keybuk> maybe it's dying
<Kamion> there's also some stuff that can move out once base-config goes away, although I think that's probably post-dapper
<sivang> sabdfl: yeah, I was just noticing that one :) I was sure it would appear somewhere in the sprint view
<Kinnison> moinmoin
<ajmitch> hello Kinnison 
<sivang> Kinnison: Morning!
<Kamion> perhaps the last remaining network clients should move out to standard too
<sabdfl> sivang: problem there is the selector gets more complex because you'd have to pick product/distro, then the spec
<Kamion> (ethtool, iputils-ping, mii-diag, netcat - on second thoughts maybe not the mii/ethtool stuff)
<sivang> sabdfl: ah
<Kamion> infinity: the problem with minimal is that it's overloaded between (a) stuff you shouldn't remove and (b) stuff needed for the first boot to work properly
<Kamion> alsa's in there so that blacklists are there at the first boot
<pitti> Hi Kinnison! AWTY? :-) 
<Kinnison> pardon?
<ajmitch> pitti: sshh, you'll jinx it :)
<pitti> Kinnison: just tickling, nevermind
<pitti> Kinnison: (I'm just eager to actually upload some crack I prepared for dapper)
<infinity> Kamion : Yeah.  I know.  It's sticky.
<pitti> oh, forcing alsa being installed on servers sucks...
<pitti> OTOH, nobody forces a server admin to keep -minimal installed, right?
<Mithrandir> it's just a metapackage
<Kinnison> pitti: I'm eager to let you
<infinity> Kamion : I tend to be able to get down to a very bare filesystem that looks a lot like Essential+Required+PartsOfImportant... Not sure how well that maps to minimal currently.
<Kinnison> pitti: just gotta get the data imported cleanly first
<hunger> pitti: Well, -minimal kind of suggest that you shouldn't remove the stuff in there.
<pitti> Kinnison: no hurry, my disk (hopefully) won't crash until tomorrow
* Kinnison grins
<ajmitch> pitti: push the upload somewhere else then :)
<hunger> pitti: We will all try to hack you and make your HDD crash now;-)
<pitti> hunger: don't! ~/ubuntu is not automatically backed up
<ajmitch> hunger: he's the security guy here :)
<hunger> That reminds me of a guy that wanted to hack me... and that I handed my IP to to try: 127.0.0.1
<pitti> hunger: lol
<ajmitch> pitti: people.ubuntu.com is ready & waiting for you :)
<hunger> He actually managed to crash that box...
<pitti> hunger: my IP is 'almost' localhost, I'm behind a crazy NAT
<ajmitch> very clever of him
<pitti> hunger: with a chainsaw?
<pitti> hunger: oh, "that" != yours
<hunger> pitti: He informed me that I was lucky that his box had crashed just after he started his attack on mine...
<pitti> lol
<pitti> hunger: you mean, he is clever enough to apply a remote DoS, but he is totally illiterate in IPv4 namespaces?
<pitti> odd guy...
<ajmitch> hunger: it's better if you give out an ip address like 127.64.115.178
<pitti> ajmitch: won't work. 127 is /24 by default
<ajmitch> I thought it was defined as /8 in the rfcs?
<pitti> (of course you can reconfigure it)
<pitti> oh , wait
<pitti> sorry, I mixed that up with my other local net
<ajmitch> :)
* pitti should watch more closly
<hunger> pitti: Clever enought to remote DOS == clever enough to run some script he found on the net.
<pitti> hunger: ah, ok
<pitti> ajmitch: I don't actually have a route entry for 127.
<hunger> pitti: Did you have a look at the cryptodisk script yet?
<pitti> hunger: no, sorry
<pitti> hunger: and no time for it in the near future, I'm afraid
<ajmitch> pitti: neither do I, but ifconfig shows a /8 mask 
<pitti> hunger: just upload it yourself :-)
<pitti> ajmitch: right, for me too
<hunger> pitti: Well, I need to fix it up somewhat anyway... work fine in normal operation, does give a error when run during shutdown though.
* ajmitch has a number of addresses on here, a mix of ipv4 & ipv6
<koke> the wacom kernel module is included by default in breezy's kernel, isn't it?
<hunger> pitti: Better not. I can not commit to maintaining a package at this time (no time for it, at least not on a regular base)
<pitti> right, then maybe just file a bug about it
<pitti> and attach the new script
<hunger> pitti: I thought I had done that before... let me check.
<hunger> pitti: I'll check on friday. can't get to the launchpad fropm behind this firewall:-(
* hunger curses "security" at this site.
<hunger> malone is the bugtracker of choice now, isen't it?
<Kamion> hunger: nearly
<Kamion> we haven't "officially" switched over from bugzilla yet; there'll be an announcement when we do, I imagine
<ajmitch> the breezy release announcements did go out stating that bugs were to be filed in malone, iirc
<hunger> It looks *UGLY* in IE (Mozilla can not access it from here, really strange FW layout they have)
<ajmitch> hunger: don't worry, it looks ugly in firefox as well :)
<hunger> ajmitch: Well, at least I was able to read stuff as it did not render things one atop the other:-(
<ajmitch> ah, that sounds a bit broken
<hunger> ajmitch: Well, even MS is nowadays asking webdesigners to fix their pages...
<hunger> ajmitch: Looks like IE7 won't be able to support all the brokeness of IE6:-(
<sabdfl> mjg59: does mjg59@ubuntu.com reach you, eventually?
<mjg59> sabdfl: Not that I know of
<ajmitch> jdub: ping
* dholbach -> lunch
* pitti does not understand the purpose of disks-admin
<Lathiat> pitti: to mount, format, look at your disks?
<Lathiat> and to look horrid as your buttons go off the edge of the tab page they are on?
<pitti> but it doesn't even write fstab
<pitti> we should rather use pysdm in dapper
<Lathiat> pysdm?
<pitti> that was a SoC bounty
<Lathiat> well, disks-admin is part of uh
<pitti> python storage device manager
<Lathiat> gnome-system-tools or whatever it is
<pitti> yes
<Lathiat> pysdm is the result of the bounty?
<pitti> well, the functionality of these two should be merged
<pitti> Lathiat: yes
<infinity> "a part of g-s-t" doesn't make it worth including.
* sivang installs to see
<Lathiat> infinity: i know, just saying
<Lathiat> pitti: nice
<infinity> We dropped boot-admin cause it had integration issues too.
<Lathiat> nice to see some good stuff coming out of it
<sivang> depends what we define as our main suit for admin tools, or not define it at all :)
<Lathiat> its missing a dependancy on python2.4-glade
<Lathiat> -glade2, that is
<Lathiat> well i cant say its pretty
<pitti> it's not as eye-candyish as disks-admin
<pitti> but it actually *works*
<Lathiat> yeh
<Lathiat> just needs a little work
<Lathiat> wow
<Lathiat> it even writes nicely formatted lines in /etc/fstab!
<Lathiat> like, it lines up with the defaults
<Lathiat> not quite sure what the dynamic configuration bit is doing
<pitti> yes, I pushed Kronoss hard to not screw up the formatting
<pitti> Lathiat: you can configure udev rules with it
<Lathiat> man, if this got a bit of UI love it'd be totally sweet
<pitti> so, tell, "if I plug in this Sony USB stick, make it appear as /dev/sonymusic"
<pitti> or whatever
<Lathiat> oh ok
<pitti> or give it certain permissoins
<pitti> it's not so important for Gnome with all our Utopia foo
<pitti> but udev rules are the automount magic of the poor :-)
<Lathiat> heh
<pitti> (IOW, they work nicely on old computers without hal/g-v-m/gnome overhead)
<sivang> pitti: the udev rules thingy are quite nice
<Lathiat> 10 points lost for not autodetecting new devices
<sivang> pitti: could be use also for yet-not-hal-detected hardware no?
<pitti> Lathiat: right, it needs some hal love
<pitti> sivang: yes, as long as it is a block device
<Lathiat> but yeh, thats totally rocking
<pitti> Lathiat: it was just too late for breezy
<Lathiat> i assume 'jaime pastor' is the dev and not just the packager?
<Lathiat> kronoss@kronoss.org
<pitti> yes
<pitti> he is both
<pitti> well, I heavily helped him with the packaging, of course
<pitti> but he did it himself
<pitti> Hi Seveas 
<Seveas> hi
<ajmitch> hello Seveas 
<Seveas> mornin'
<sivang> is wiki.ubuntu.com down?
<infinity> Bah.
<infinity> pitti : pysdm is teh suck here.
<pitti> infinity: in what regard?
<infinity> pitti : The only "partition" it lists is "sda"... Which is obviously useless. :)
<pitti> infinity: ah, I saw this before; I thought Kronoss fixed it
<pitti> infinity: can you please remove /etc/blkid.tab and try again?
<pitti> infinity: pressing "Update" doesn't help?
<infinity> Update didn't help.
<infinity> Neither does removing that file.
<infinity> s/update/refresh/
<infinity> But, yeah.  No dice.
<pitti> infinity: "sudo blkid" does not give any information about /dev/hd*?
<infinity> sudo blkid works fine.  Give me /dev/sda[12356]  and /dev/evms/sda[12356] 
<pitti> infinity: oh, you don't actually have IDE drives then?
<infinity> No, SATA.
<pitti> ah
<infinity> Don't see how that should matter.
<sivang> pysdm doesn't seem to go out of the freeze it fire up with
<pitti> infinity: well, so only having sda in pysdm is correct, isn't it?
<pitti> when hda isn't there?
<infinity> pitti : No, it only has "sda"... No partitions listed, just the raw disk.
<pitti> ah, suck
<pitti> sivang: I noticed that, too
<pitti> still some work to do as it seems
<infinity> Which, uhm, works much better if I run it as root.
<sivang> pitti: is it in main? ;-)
<pitti> infinity: *cough*
<infinity> It's only the read-only non-rott display that sucks.
<infinity> non-root, even.
<infinity> (Still broken, but less broken, I guess)
<pitti> infinity: the menu entry uses gksudo
<pitti> sivang: no, universe for now; it was too late for breezy
<sivang> infinity: ah, works well when run as root
<pitti> infinity: so we need a check for uid == 0
<infinity> Eww, that "hasn't been configured, would you like to?" popup is annoying too.
* sivang now notices the coolness in pysdm
<Lathiat> infinity: yeh it could do with makign it part of the dialog
<jdub> ajmitch: pong
<sivang> pitti: and offer to run with gksudo otherwise?
<sivang> pitti: I notice that I can enable journaling, I thought journaling is enabled by default in ext3 , no?
<pef> hello
<ajmitch> jdub: just about ops in #ubuntu
<infinity> Hrm.  Also, shouldn't it mount the filesystem after I set it up?
<infinity> I guess I could click the mount button.
<ajmitch> jdub: what do you think about adding rob^ ?
<jdub> dunno
<jdub> i guess if existing ops want to, and CC says yeah, then it's good to go
<ajmitch> I thought I'd run it past you first :)
<jdub> or maybe if CC says existing ops can agree to bless someone else
* ajmitch isn't in there enough to help out much
<jdub> i don't have a strong opinion
* ajmitch will raise it at CC meeting 
<\sh> sabdfl: why didn't you offer Bob Young a job? ;)
<azeem> W 26
<azeem> oops, sorry
<sivang> anybody knows when w.u.c comes up again? Znarl ?
<sivang> ah, it just did. sorry for the noise then.
<HiddenWolf> w?
<sabdfl> \sh: interesting development, isn't it?
<sabdfl> i did try to hire the founder of gentoo
<sabdfl> good guy
<Lathiat> drobbins?
<jdub> *mmm*, IronPython
<sivang> he works for M$ or was that someone else from gentoo ?
<Lathiat> yeh thats drobbins
<Lathiat> im pretty sure its him + hes the gentoo founder
* Lathiat googles
<Lathiat> Gentoo founder and former Gentoo Chief Architect Daniel Robbins began a new position at Microsoft on 23 May 2005. According to drobbins: "I'm helping Microsoft to understand Open Source and community-based projects."
<Lathiat> http://www.gentoo.org/news/20050613-drobbins.xml
<infinity> Ironic, given that Gentoo snagged Debian's Social Contract as a basis for their own.  That's not the sort of thing you'd expect from someone who the njumps ship to the proprietary software world.
<HiddenWolf> infinity, it's not like he's a traitor to the cause. :P
<Lathiat> infinity: i guess he takes the "helping Microsoft to understand Open Source and communit-basd projects" to justify that
<HiddenWolf> "cause" 
<Lathiat> what h
* infinity wonders what "helping Microsoft understand Open Source" really means.
<Lathiat> what hes actually doing there i have no idea
<infinity> I assume they're helping him undrstand that being paid a lot is nice and makes your girlfriend love you more.
<HiddenWolf> infinity, why is it you don't approve?
<HiddenWolf> infinity, the man is within his right to do it, to spend his life as he wishes.
<infinity> HiddenWolf : Of course he is.  I don't have to APPROVE, however, do I?
<infinity> That's lunacy.
<HiddenWolf> infinity, so why don't you approve?
<infinity> I don't approve of people wearing pea green, or fat people in tiny t-shirts, but they can still do so.
<Lathiat> whoah, hes only 18 too
<TMM> mjg59, hello, are you here?
<TMM> mjg59, actually, there, because I am sure you aren't 'here' :)
<Lathiat> http://article.gmane.org/gmane.linux.gentoo.nfp/72
<mjg59> Hello
<infinity> HiddenWolf : If I, for one second, actually believed he was helping bring them into the free/open software world, I may approve.  But Microsoft has never been too keen on moving in that direction, so I suspect he isn't.
<TMM> hello mjg59 :)
<Lathiat> h no
<Lathiat> thats talkign about someone else
<TMM> I was told to talk to you for some laptop-related trouble
<Lathiat> i misread it
<jdub> infinity: they just announced three open source licenses today
<HiddenWolf> infinity, so MS is evil by definition?
<TMM> hey jdub ! see you in a couple of hours ;)
<jdub> infinity: one bsd-like, one mpl/cddl-like, one look-but-don't-touch
<Lathiat> mpl/cddl ?
<jdub> annoying that it's more branded license proliferation
<infinity> jdub : But what will they license under said licenses?
<jdub> but definitely going in the right direction
<TMM> mjg59, I've got a host of compaq laptops here, with extra multimedia keys that require some magic poking of memory to get them to work
<infinity> HiddenWolf : Did I say that?
<jdub> infinity: their existing open source stuff, like ironpythonwix, etc.
<mjg59> It's technically poking of the keyboard controller, but yeah
<TMM> mjg59, ah, you know that already?
<HiddenWolf> infinity, it's the impression you give me.
<mjg59> Yeah, but I don't have any hardware here to test it
<TMM> mjg59, I've got 3 :)
<TMM> mjg59, and I've got the magic values for the rest of the keys too
<TMM> mjg59, also, there is a led next to the mute button, that you can set/unset by poking the keyboard controller 
<mjg59> Eww
<TMM> mjg59, I know, it is not my design, I'm just the messenger
* Lathiat laughs
<TMM> mjg59, and, the best part, it has absolutly nothing to do with either the soundcard or the mute button, you have to sync that manually :)
<mjg59> Haha
<TMM> so, anyway
<TMM> :)
<TMM> do you want to make that work? (ie, would you allow me to make it work) ;)
<TMM> ?
<TMM> if so, I have a couple of ideas on how :)
<TMM> some dirtier than others :)
<Treenaks> TMM: look at the hotkey-setup package
<Treenaks> TMM: you could do a conditional poke when you detect one of your known compaqs
<Treenaks> don't know about the mute led tough
<TMM> Treenaks, then, there is still the mute led :)
<TMM> Treenaks, indeed :)
<infinity> HiddenWolf : I don't believe Microsoft is (or always will be) pure evil.  I do think it's ironic for someone to go from a "we will always be 100% free software" thing to a "teaching a bit about open source to the largest proprietary software vendor in the world who will certainly never make their core business units free without a court order or bankbruptcy"
<infinity> bankruptcy, too.
<TMM> bankruptcy would fix malone bug #1 :)
<mjg59> I have a Mac. I want to boot it off CD.
<mjg59> My usb/ps2 adapter doesn't seem to power up fully until too late.
<mjg59> How can I make this work?
<Lathiat> haha
<TMM> mjg59, I think you need to press and hold "d" :)
<Lathiat> TMM: with a working keyboard :)
<Lathiat> mjg59: dont have another keyboard or something?
<mjg59> Lathiat: I have no USB keyboards
<Lathiat> that sucks
<TMM> mjg59, get one :) 
<TMM> mjg59, or get a better converter ;)
<mjg59> I'm not buying a keyboard just to boot this device once
<Lathiat> maybe you can poke something in openfirmware from macosx or something
<TMM> mjg59, you can set the boot device from macosx settings thingy somewhere
<TMM> mjg59, perhaps you can set it to cdrom as well
<Lathiat> careful in case you cant get it back? ;p
<mjg59> TMM: That doesn't let you set CDs
<TMM> I think there's a linux tool to set it too
<TMM> mjg59, ok, sorry, wasn't sure
<Kamion> mjg59: it can certainly be set in the underlying OF, even if the tool doesn't let you do it
<TMM> mjg59, borrow an usb keyboard from someone? :)
<Kamion> boot-device=cd:
<mjg59> Kamion: Yeah. 
<Kamion> mjg59: Google suggests that the Darwin console has an 'nvram' command
<TMM> mjg59, should I poke the keyboard controller from hotkey-setup or from the acpi scripts?
<Kamping_Kaise1> im not sure if i should ask here, but if its not your going to tell me ;). i was wondering why ISA sound cards have had their support dropped from hoary and breezy?
<Kamion> nvram VAR=VALUE
<mjg59> TMM: hotkey-setup
<Kamion> mjg59: only problem is that if you get it wrong you probably don't get another shot at it
<mjg59> Kamion: Well, there's the PRAM reset thing, but still
<Kamion> mjg59: that requires a keyboard
<mjg59> Yeah
<Kamion> mjg59: now if you were *really* an OF whiz you'd configure it to bring up the OF telnetd thing straight away and operate it that way
<Kamion> but that's rather riskier than setting boot-device :-)
<TMM> mjg59, there is currently no poking being done it seems, should I add another .c file to the package?
<mjg59> TMM: Hmm. How much poking is needed?
<mjg59> There's a perl script that's meant to do it
<TMM> mjg59, yeah, I did the extra compaq stuff
<TMM> mjg59, omke.pl
<mjg59> Kamion: Interesting. It just booted off hard drive again.
<TMM> mjg59, not included in ubuntu it seems
<mjg59> TMM: Indeed
<Kamion> mjg59: odd
<TMM> mjg59, so, include omke.pl in it then?
<mjg59> TMM: What dependencies does it have?
<TMM> mjg59, perl
<mjg59> Just perl?
<HiddenWolf> doko, ping
<mjg59> No other modules?
<mjg59> Kamion: Did I need to do anything special to the CD other than just burn the iso?
<TMM> mjg59, doesn't look like it (I'm not much of a perl guru)
<mjg59> TMM: omke.pl looks to have way more functionality than is needed
<TMM> mjg59, a little too much, I can just extract the bits needed obviously
<Kamion> mjg59: no. did you create the iso yourself?
<mjg59> Kamion: No, it's downloaded from releases.u.c
<Kamion> should be no problem then
<Kamion> what kind of Mac?
<mjg59> Mini
<TMM> mjg59, shall I create a stipped version of omke.pl, and include that in hotkeys-setup?
<sabdfl> mjg59: does mjg59@ubuntu.com reach you?
<Kamion> mjg59: I think a keyboard's going to be necessary
<mjg59> sabdfl: Not that I know of
<mjg59> Kamion: Is there an OF flag I can set to dump me into it automatically on boot
<mjg59> ?
<mjg59> I seem to remember one
<Kamion> mjg59: set auto-boot? to false
<mjg59> That's the one
<Kamion> you need usable input-device and output-device
<mjg59> (I used to know this stuff)
<Lathiat> mjg59: i guess the question is whether your usb adapter is taking too long to power up or not powering up until later in OF?
<mjg59> Hurrah, OF
<Lathiat> ah, so it worked then?
<Kamion> mjg59: is the USB/PS2 adaptor thing purely "you have to wait some number of seconds" rather than "you have to wait for <software> to appear"?
<Kamion> ah, basically Lathiat's question
<\sh> sabdfl: don't tell anybody from the gentoo universe that u tried to hire daniel robbins ;)
<mjg59> boot cd results in "LOAD_SIZE is too small"
<mjg59> Kamion: Yeah
<mjg59> It's intelligent - it just makes the keyboard appear as a USB keyboard
<Lathiat> i got one of them off ebay
<Lathiat> unfortunatedly it was a ddgy seller
<Lathiat> good thing it was only $10
<Lathiat> they sent me some plastic battery pwoered lamp instead
<Kamion> try cd:,\\:tbxi
<Lathiat> ... after giving me the wrong account numbe rand taking 4 weeks to reply
<mjg59> Kamion: Ah, there we go
<mjg59> Yay yaboot!
<Kamion> cool
<mjg59> TMM: If you could strip it down to just the -k stuff, that would be great
<TMM> mjg59, np, now, how will I know when to run it?
<mjg59> TMM: What dmidecode information do you have?
<TMM> mjg59, the output from the dmidecode stuff in the acpi scripts?
<mjg59> TMM: Basically, you want to run it on hardware where it should be run. Which is probably mostly HP and some Compaq
<TMM> mjg59, there is where it gets a bit tricky :) some of these things are branded compaq but are reported as 'hewlett packard' by the dmidecode stuff, some as 'compaq'
<doko> HiddenWolf: pong
<TMM> mjg59, still, should I include the dmidecode magic into hp.hk or something? or can I somehow call those scripts?
<HiddenWolf> doko, printing from firefox is broken for me. Seems the settings for firefox are different from those used by thunderbird, etc. It's your package, right? 
<doko> _my_ package?
<mjg59> TMM: If you can put that information up somewhere so I can take a look, that would be good
<TMM> mjg59, sure, just a sec
<HiddenWolf> doko, actually, never mind, Have to run! :)
<TMM> mjg59, http://braam.sytes.net/~hp/compaq_2557eu.txt
<mjg59> TMM: Ok. In that case, we may want to check if it's a Presario
<TMM> mjg59, and a 2500 I think
<mjg59> Just add an extra case below the Tablet one
<TMM> or certain evo models....
<shadeofgrey> Good morning all you ubuntu coder folks..
* Diziet laughs.  My latest Breezy install (my first fresh install of the actual release) has left me with 6 `hard disk' icons on my desktop labelled hda1, hda3, hda4,5,7,8.
<TMM> mjg59, yeah, hp is really clear on this isue :)
<TMM> mjg59, I'll do some digging on the hp site, I can identify the models that need it by pictures
<TMM> mjg59, but I won't know the exact dmi info they produce
<shadeofgrey> I was very flattered to see that i made the front pafge of planet.ubuntu.org ....  If I'd known I was going to make such an impact i might have worn a tie
<shadeofgrey> you guys need to start thinking about adding voice recognition software to the accessibility software....  Dragon Naturally Speaking and WINE dont like each other very well...
<TMM> mjg59, looks like you can't even know the exact type of laptop from the dmi info... sick
<shadeofgrey> in fact attempting to get them to work together ended in blaize of glory crash and burn utter failure 
<TMM> mjg59, the difference between the 2556eu and 2557eu are pretty drastic (I know, I've got them both) ;)
<mjg59> TMM: /win 7
<mjg59> Oops
<TMM> mjg59, thanks for that remark, very informative ;)
<TMM> mjg59, so, what do I do? do I parse dmi info in the hotkey-setup stuff?
<mjg59> TMM: Just do what the init script already does
<mjg59> Where it checks for *Tablet*, check for Presario*
<TMM> mjg59, ahhh, sorry. I missed that 
<mjg59> If you get a Presario, enable the keys and include something that sets them up
<TMM> mjg59, ahhh, thank you. I didn't know about the debian/init.d script yet
<mjg59> Ah, ok
<Mithrandir> Keybuk: any idea why autoconf tells me: ***BUG in Autoconf--please report*** AC_ARG_VAR
<TMM> mjg59, in a source package
<TMM> mjg59, I was going to ask you what ran this :)
<Mithrandir> Keybuk: after running aclocal to get the right set of macros.
<TMM> mjg59, one other question, I've manually set the resulting keycode from the lock button to the one in hp.mk ( setkeycodes e071 168 ) but, that is binded to 'eject' in gnome... am I doing something wrong?
<mjg59> Uhm. Er.
<mjg59> No, that looks like my screwup
<Keybuk> Mithrandir: nope, not off-hand ... maybe a bug
<TMM> mjg59, shall I file a bug? ;)
<mjg59> TMM: Heh. Yes, please.
<Keybuk> Mithrandir: or, at least, not without context
<Mithrandir> Keybuk: I'll see if I can reproduce with a minimal configure.in
<Mithrandir> Keybuk: a configure.in consisting of AC_INIT(NXlib.h)\nPKG_CHECK_MODULES([X11] , "x11 xorg-server") shows me the problem.  aclocal-1.7 (or 1.9 or whatever), then autoconf.
<bddebian> Morning
<TMM> mjg59, bugzilla or malone? does it matter?
<CarlK> breezy installer bugs - post to bugzilla or the new one?
<Keybuk> Mithrandir: could be a pkg.m4 bug then
<mjg59> TMM: Malone, probably
<Mithrandir> Keybuk: do you have to AC_REQUIRE on AC_PATH_TOOL and such?
<TMM> mjg59, ok, and for the compaq stuff, also a bug + patch? or shall I send you a patch directly?
<mjg59> Either
<TMM> ok then I know enough :)
<Keybuk> Mithrandir: AC_REQUIRE expands them at that point
<TMM> mjg59, thanks for your time
<Keybuk> it's not an "import"
<TMM> mjg59, I'll talk to you about the mute led later ;)
<Mithrandir> Keybuk: yes, unless they have been expanded earlier, yes
<Keybuk> indeed
<Keybuk> it can't be used on macros that have arguments
<Mithrandir> apparently, this was an autoconf 2.13 bug, invoking 2.50 directly fixed it.
<TMM> mjg59, sorry, one more, is there a list of keycodes to use for certain functions? because lock isn't defined in my keyboard shortcuts at all
<TMM> mjg59, in gnome anyway
<Keybuk> oh, that could totally do it
<Keybuk> 2.13 is nasty
<Keybuk> always put AC_PREREQ(2.59) in configure.in, or name it configure.ac
<Kamion> mvo: do you remember why you added file to debhelper's build-deps?
<Keybuk> I'm sure I put one in pkg.m4, actually
<TMM> mjg59, should I just leave that to you then? :)
<mjg59> TMM: If you could include a list of the keys and what they should do, I'll work on it
<Diziet> *snort*:
<Diziet> root@samual9:~# find /var/lib/dpkg/info -type f | xargs md5sum | awk '{print $1}' | wc -l
<Diziet> 4164
<Diziet> root@samual9:~# find /var/lib/dpkg/info -type f | xargs md5sum | awk '{print $1}' | sort -u | wc -l
<Diziet> 3630
<mvo> Kamion: TBH no
<TMM> mjg59, ok, I will
<CarlK> hello Kamion - my base-config-pkgsel.log is 9004683264 bytes - is this a problem? ;)
<Mithrandir> 9G?  That sounds slightly excessive.
<CarlK> it would have been more, but I ran out of space
<Lathiat> haha
<Nafallo> lol
<Lathiat> the obvious solution is to never log anything!
<Lathiat> just link all your logs to /dev/null
<CarlK> hehe
<sabdfl> smurf: hiya. which is the best starting page for LoCo teams?
<CarlK> it got hung up on "Warning: untrusted versions of the following...  language-pack-en-base language-pack-en" 
<CarlK> and then 8.9 gig of Should I go ahead and install the packages anyway?
<CarlK> To continue, enter "Yes"; to abort, enter "No": Unrecognized input.  Enter either "Yes" or "No".
<CarlK> but before anyone freaks - I am using the CD on a local web server as my mirror
<CarlK> so im hoping that is the cause - Ill try again using us.ubuntu.com
<mantiena> Hi all
<Kamion> CarlK: by way of education, base-installer is not a catch-all for installer bugs. :-)
<Kamion> you wanted base-config, but I'll assign it elsewhere anyway
<mantiena> Kamion, hi, I see you are ubuntu-deskop maintainer or at least uploader ;)
<mantiena> I wanna ask why ubuntu-desktop depends on irssi-text ?
<CarlK> I was close ;)
<Kamion> *everyone* assigns stuff to base-installer
<pitti> does anybody know a GUI way to change the monitor frequency?
<Kamion> mantiena: ubuntu-desktop is maintained semi-automatically based on the seeds
<azeem> pitti: gnome-display-properties, perhaps?
<Kamion> irssi-text has been part of desktop forever
<pitti> azeem: no, it only changes the resolution, and it does not even have root privs to be able to change freq
<Kamion> under the general heading of "useful console-based tools that we install as part of the desktop"
<azeem> pitti: ah, hmm
<azeem> pitti: well, works here at the Uni (where I'm not root), but this is sarge, not breezy
<mantiena> Kamion,  so, you think, that ubuntu-desktop should depend on irssi-text and I should'nt fill a bugreport about this ?
<Kamion> mantiena: I think the current dependency is correct, yes
<infinity> irssi-text could probably move to "ship" without anyone complaining.  Somehow I doubt that irssi users are the sorts who mind installing extra packages after an install.
<Kamion> if you don't like the desktop set, you can remove ubuntu-desktop
<infinity> But ubuntu-desktop depends on a lot of stuff you don't need, just stuff you "may want"... That's what it's for.
<mantiena> : ftp://ws314.juntadeandalucia.es/guadalinex2005/archives/peez2/
<mantiena> sorry
<pitti> azeem: I just saw that xorg.conf limited it to 60 Hz. I'll spank daniels when he returns :-)
<mantiena> pitti, daniel thinks, that 60 Hz is ok :-P
<infinity> pitti : What platform?
<infinity> pitti : If it's amd64, that's kinda a known issue.
<pitti> infinity: no, i386
<Nafallo> I have 59Hz on my amd64 :-)
<infinity> Oh.  A laptop?
<mantiena> Kamion, Btw, did you noticed that ubuntu-desktop also depends on *very big* Korean, Japanese and Chinese font packages ? this is also ok ?
<Lathiat> my laptops dont care. :)
<mjg59> /tmp/zd1211/src/modules-2.6.12/zddevlist.h:7:2: #error "Error in source file, line 35"
<pitti> infinity: no, an ordinary desktop
<Nafallo> Lathiat: but that gnome-thingie still have it as an option, no? ;-)
<infinity> pitti : Hrm.  Sucks to be you, then. :)  Bug filing time.
<TMM> mjg59, see malone bugs #3363 and #3362 :)
<Kamion> mantiena: I'm pretty familiar with the set of packages in desktop, yes. We install those fonts because they make CJK web pages look reasonably decent by default.
<pitti> infinity: it's not *my* PC :-) I'm just adminstrating a friend's one, who installed Ubuntu the first time and has various hassles
<pitti> infinity: my shiny TFT doesn't care about the freq :-)
<infinity> pitti : Yeah, I know. :)
<infinity> Anyhow, it's odd for it to be limited to 60Hz out of the box.
<infinity> Unless we really couldn't get any useful info from the monitor at all on install, then it would have been set to a "safe" refresh rate to avoid exploding CRTs.
<Mithrandir> infinity: CRTs stopped exploding some time ago
<maswan> I think that it is a safe assumption that any exploding CRTs have exploded or otherwise expired by now.
<pitti> infinity: I'm afraid that was the reason - there are probably no DPMS information
<pitti> s/are/is/
<infinity> Mithrandir : Yes, around the same time they started providing DPMS.
<maswan> What is even more annoying is overriding it when DPMS gives lies.
<TMM> maswan, I still use a crt monitor that might explode :)
<TMM> maswan, very old very large (Very pretty) 21" sgi monitor :)
<Mithrandir> infinity: nah, I have a monitor from 1987 which I'm fairly sure doesn't do evms, but it doesn't explode when you throw > 1024x768 at it either.
<maswan> TMM: I have a few old monitors too. They won't explode, or they would have by now. :)
<infinity> Mithrandir : I had one from 1989 that, while it didn't EXPLODE, per se, would whine and threaten to do so when you would overdrive it.
<pef> where are ftbs on wiki ? I can't find them using search function
<infinity> Mithrandir : The point being that any monitor that doesn't shut off the tube (or otherwise refuse to do what you're asking) when overdriven should never be overdriven.
<Mithrandir> infinity: yes, I know that.
<dholbach> pef: i trashed the pages, since i thought it might be more exciting after the sync :)
<infinity> Mithrandir : And it wasn't until 5 years ago or so that I finally bought a monitor that would do the nice "out of range" blinking thing when tried to overdrive it.
<infinity> Anyhow, I still say it's a better safe than sorry thing.
<infinity> And because X just uses the "best refresh rate it can manage" on invocation, you have to artificially limit it, if you want to be safe, which means the RandR applet won't work.
<pef> dholbach: oh, it's because malone #3360 is fixed (also a FTBS) by using debian's version
<infinity> Until we fix that (allowing you to have a lower default refresh rate, but later switch to a higher one), the status quo, suck though it is, remains.
<dholbach> pef: cool
<pef> dholbach: so I wanted to mention this on ftbs page :)
<dholbach> yeah
<pef> dholbach: debian's version builds fine. Should I ask for a sync from Debian, or wait the big sync ?
<pef> (package is currently empty)
<dholbach> pef: the archive is not open yet, so you can't ask for a sync now
<pef> dholbach: when dapper will be opened, sync are done case by case ?
<Kamion> pef: not established yet
<trulux> heya folks
<bddebian> Hello trulux
<trulux> hi bddebian , how's it going?
<bddebian> Fair to midland thanks.  You?
<jdub> Keybuk: what do you think about html output for bzrk? :)
<Keybuk> has already been discussed
<Keybuk> the tricky bit would be making a table that still kept the graph aligned with the revision data
<jbailey> Keybuk: Use SVG
<jbailey> Keybuk: If you output the data as a series of blocks that renders flat, I think you can use SVG for all the lines and then position them.
<jbailey> Keybuk: I suspect you can make it look elegant in text mode and in a graphical browser.
<carstenh> ... and make all people use a svg-plugin in their browsers?
<jbailey> carstenh: IIRC, Firefox supports it natively.
<Keybuk> but the problem is what if they increase their font size
<Keybuk> double the font size, and none of the text rows match anymore
<carstenh> jbailey: that would solve that problem :)
<Keybuk> it's currently rendered using Cairo, so output formats aren't the problem -- we can output in png, svg, etc. with just one line of code
<koke> Keybuk: even with font-size: monospace ??
<koke> font-family, sorry
<Keybuk> koke: it's the height that's the issue
<Keybuk>  o |  fix some bug  Keybuk
<Keybuk>  |\o  some other bug  Martin
<Keybuk> type thing
<Keybuk> if you double the font size, there will be a gap between the two row images
<koke> hmm, I see
<Keybuk> or if you just render one big long image, the lines of text won't match the graph
<Keybuk> (in the GUI it actually gets the font size that's being used, and scales the graph appropriately -- so the larger the font, the thicker the lines and bigger the circles)
<koke> Keybuk: you can make the lines/dots backgrounds instead of images, and make it some bigger than the cell
<koke> if the angle is 45 it may work
<Keybuk> koke: it has diagonal lines :p
<Keybuk> it tube-maps them all to 45, but they still wouldn't line up, as you have to decrease the angle as you increase the distance
<koke> if you counld just make the width adjust to height...
<koke> it must be possible :)
<Keybuk> you could probably get the font size with javascript
<Keybuk> and rewrite the urls to get the images to include the height of the font
<Keybuk> and then have a cgi render them at the right heights
<sabdfl> smurf: ping
<smurf> sabdfl: 
<sabdfl> errr... squiggle!
<sabdfl> smurf: what's the best "home page" for loco activity and info?
* sivang .oO(launchpad should maybe have something for loco teams managemnt?) ;-)
<smurf> sabdfl: Depends on whom you talk to. I usually just point people to LoCoTeams; if that's not what they want, the first three paragraphs have a couple of more specific links in them.
<smurf> sivang: do you have anything specific in mind, besides group management (which it already has ;-) ?
<sivang> smurf: Something on front page of "LOcoTeam" bussiness showing current activity other then translations, place to put instructions per loco team for it's standards and current goals , acutally this seem to overlap alot with other stuff it already has.
<sabdfl> smurf: ok, cool. I'm putting a bit about loco teams on the main project governance page, because i think they are very important
<smurf> sabdfl: yes, that makes sense
<sivang> smurf: I'll try to get more specific and may be put up a spec suggestion
<smurf> sivang: please do
<koke> Keybuk: http://www.amedias.org/~koke/diagtable/test.html <-- something like this
<koke> although it needssome polishing :)
<maswan> Kamion: http://ftp.acc.umu.se/mirror/cdimage.ubuntu.com/releases/breezy/release/
<\sh> time to go home and have something like an aspirin
<Keybuk> koke: the lines don't go the same way as bzrk though
<\sh> bbl
<Keybuk> koke: the diagonals go from the centre point of a row, to the centre point of another
<Keybuk> they don't stop half way
<maswan> or anyone else that might be interested in linking people to a mirror for the dvds
<Keybuk> try carrying that right-heading diagonal on until it reaches the middle of the next line
<Kamion> maswan: cool - can you add that to wiki.ubuntu.com/Archive?
<Diziet> kamion: Did you fancy testing my magicmirror packaging or should I post to ubuntu-devel ?  For the moment the package is at ftp.chiark.greenend.org.uk:/users/ian/magicmirror/
<maswan> Kamion: sure. would you prefer the ftp.acc or se.archive name?
<Diziet> -anarres:mozilla-firefox-1.4.99+1.5beta2.dfsg> find -name '*.rej' | wc -l
<Diziet> 118
<pitti> cool - it looks as if in Dapper, we can share alsa devices amongst several users at the same time
<sabdfl> pitti: nice
<sabdfl> could be confusing with a 4-way computer though :-)
* Keybuk can hear Jane giggling at that from here
<pitti> in Breezy, we made this work with esound too, but since I want to drop esound, we need a replacement for that feature
<Kamion> Diziet: I'll have a look, although it'll take a little while for me to wrap my head around it :-)
<Diziet> k: I wrote a nice simple README.Debian which tells you what to do so you don't need to understand it.
<Diziet> The proper README is more of a reference manual in my typical style.  Everything about what the parts are and exactly how to fettle them, but not recipes.
<Kamion> yeah, I saw README.Debian
<Kamion> hmm, will have to do some filesystem-munging, urk
<jdub> bah
<jdub> anyone know how to get raw hid events from a usb device?
<Diziet> filesystem-munging: I assume ext3 doesn't have support for heouwge directories yet.
<Keybuk> jdub: /proc/bus/usb/devices /
<Kamion> tune2fs -O dir_index is there, but I think there's still a hard limit
<pitti> Diziet: what is this funny name about?
<Keybuk> or is that not what you meant
<Diziet> pitti: Funny name ?  heouwge = huge pronounced expansively.
<Diziet> My magicmirror repo on davenant has about 200k files in it.
<pitti> Diziet: ah; you have to explain that to us poor non-English-natives :-)
<jdub> Keybuk: messages, not the devices
<Diziet> drwxrwsr-x    2 mirror   mirror    8978928 Oct 19 09:50 /export/mirror/Repository/data-md5/
<Keybuk> jdub: sorry, could you be a bit more detailed about what you actually want
<Keybuk> do you want the plug events?
<jdub> no, the hid events
<Keybuk> do you want raw access to the device?
<Keybuk> what kind of events?
<jdub> as per first question :)
<Keybuk> there's lots and lots of possible events
<Keybuk> and you get them all from different places
<jdub> it's a hid device, so i want the hid event stream
<Kamion> I see that reiserfs plays some tricks with the directory i_nlink count.
<Kamion> If you exceed 64536 links in a directory, it reverts to "1" and no longer
<jdub> for keyboard events
<Kamion> tracks the link count. 
<Keybuk> right, /dev/input/eventX then
<Kamion> that makes me feel so confident
<Keybuk> where X matches the device
* jdub notes he said "hid" in the first question :)
<Keybuk> yes, but you weren't specific
<Kamion> ah, no, the limit is on number of *subdirectories* in a single directory
<Keybuk> you said "raw" too
<Keybuk> which you don't want
<Diziet> 6_4_536 ?
<Keybuk> you want the structured, filtered ones
<jdub> "raw hid" -> not entirely unspecific :)
<Keybuk> jdub: no, but it was wrong :p
<Diziet> I assume you mean `links _to_ a directory', anyway.
<Keybuk> Kamion: isn't it the number of hardlinks in a directory that's the limit?
<Kamion> Diziet: wasn't me, was a quote from a linux-kernel post
<Kamion> Keybuk: yes
<Diziet> WDYM `hardlinks in a directory' ?  DYM `files with a link count >1' ?  Because my mirror repo here has 190kfiles with a link count of 2 each, and is on reiserfs.
<Kamion> Diziet: it's an ext2/3 limitation
<Kamion> Diziet: http://www.ussg.iu.edu/hypermail/linux/kernel/0105.0/0164.html
<Diziet> Ah, right.
<Diziet> I think that message confuses (as we have been) link count of a directory and count of names (ie, links) in a directory.
<Diziet> Only subdirs count towards a directory's link count.
<Diziet> Luckily magicmirror doesn't make subdirs in its repo :-).
<Kamion> right
<Kamion> I'll try with ext3 dir_index and see how the Repository behaves
<Diziet> Do let me know.  I should update the README ...
<Kamion> Diziet: BTW your provided selections file doesn't seem to mirror Contents by default
<Kamion> and the syntax reference does not appear to say what happens if you fall off the end of the configuration file without matching any inclusions/exclusions
<Diziet> Contents> That's a mistake.
<Diziet> Um, or is it ?  My actual mirror here has Contents for all arch's.
<Diziet> Do you mean it left the Contents out or do you mean you second-guessed the syntax and it seemed that it would ?
<Kamion> I'm guessing at the syntax; the mirror layout I want is somewhat different from the default so I have to write one anyway
<Kamion> s/one/configuration files/
<Kamion> and it will be a while before I actually get it going because due to disk space constraints I'll have to glue the parts of debmirror that do suite selection into magicmirror somehow
<Diziet> Ah, yers.
<Diziet> Err, do you really mean `suite' ?
<Diziet> suite = {universe,main,multiverse,restricted} ?
<Kamion> yes, I do
<Kamion> no, component = {universe,main,multiverse,restricted}
<Kamion> suite = {warty,hoary,breezy} or {sarge,etch,sid}
<Diziet> Oh, I thought those were called `releases' :-P.
<Diziet> It's true that it doesn't know how to do that.
<infinity> They will be in launchpad, so you're ahead of the curve. :)
<Kamion> katie's internals call them suites, so I'm in the habit of calling them that; it gets rid of the confusion inherent in talking about "unreleased releases"
<Diziet> Ah, yes.
<infinity> But in katie-speak, warty, hoary, breezy, (and the -updates and -security of each) are suites.
<infinity> In the New World order, we get DistroReleases and (wait for it), Pockets.
<Diziet> *boggle*
<ogra> Pockets ?
<Kamion> breezy-updates is a pocket of breezy, iirc
<infinity> Pockets.  The sub-releases of each DistroRelease.  So, breezy has two pockets, -updates and -security.
<ogra> ah
<infinity> Pockets are, generally speaking, non-self-contained children of a larger release.  At least, I think that's how the data model sees them.
<ogra> do we have a documentation about this public anywhere ? 
<Diziet> The best way I can think of making the magicmirror approach do what debmirror does, is to run magicmirror once with a config file which gets only the metadata, and then have a program which turns the metadata into a pair of index files.
<infinity> ogra : No, cause from your POV, nothing will have changed.
<infinity> This is just about how the LP people see it and talk about it. :)
<ogra> infinity, ah, ok :)
<Kamion> Diziet: where should I send bug reports? the only two addresses in the source package are in debian/control and debian/changelog, and they differ :-)
<ogra> as long as upload.u.c and -changes are there i'm fine :)
<Diziet> kamion: Oh, ian@davenant is sensible.
<Kamion> OK, thans
<Kamion> thanks
<Diziet> NP
<mdz> morning
<Diziet> Hello.
<bddebian> Heya mdz
<pitti> Hi mdz 
* mvo waves to otavio 
<spayne> hi di hi
<Keybuk> "I run a 100% free service to stop SPAM" ... that's nice, so, err, could you STOP SPAMMING ME YOU MOTHER FUCKINGOII"UIURIJWJOHFO"
<bddebian> Hehe
<mdz> Diziet: free now if you want to talk automated testing
<Diziet> Ah, hello.  Right.
<Diziet> So, basically, I've come to the conclusion that the biggest missing piece is a standard way to find and store the tests, and a standard interface to invoking them.
<Diziet> The question of how to invoke them without making a mess of a real system is indeed not entirely trivial but it's a SMOP by now I think.
<Diziet> We want obviously to be able to use upstream's tests and write our own and share them, and the flow of the tests is going to be very similar to that of the source they relate to.
<mdz> Diziet: we should make a distinction between destructive and non-destructive tests, and plan to only run the destructive tests in a virtual environment
<Diziet> So it seems to me that they should be attached to (in, even) the package - probably the source package, since testing is a development activity which you have source for.
<Diziet> mdz: Right, exactly.
<Diziet> But what we're missing is a standard way to say `these here are the destructive tests and you know how to run them' vs. `these are the destructive tests' vs. `this test needs foobar (>= 3.7) installed'.
<mdz> you should be able to run, e.g., the upstream test suite non-destructively on a live system, but we also want the capability to test things like purging packages
<Diziet> Absolutely.  So that's a destructive test of dpkg.
<mdz> also of the package being purged
<Diziet> Indeed so.
<mdz> as I said out in that spec document I showed you, we want to do a lot of generic testing at the package level
<Diziet> Now purging a package is a special case because every package is supposed to have the same interface.
<mdz> as far as placing the tests, I agree that they make most sense in the source package
<Diziet> So package purge isn't a test that has a test case file or three in the package itself; it's just a thing it's supposed to do which you can know how to try.
<Diziet> Most tests need files.  Right, in the source.
<Diziet> The first piece of this then I think is a spec. which describes, given the source package, how to find the tests.
<mdz> for the interface, if we can get away with a simple exec() interface for tests, that's probably ideal because we have freedom to implement tests in any language
<Diziet> And which ones have which properties and how to invoke them.
<Diziet> Indeed.
<mdz> if we can't, then python modules written to an API published by the testing framework
<Diziet> It would be good to have a declarative way to (a) distinguish between different tests and (b) tell whether to try a test, rather than running the test and having it decide to give a `noop' pass.
<Diziet> Then you could be able to say `well, one out of 50 tests failed, and we couldn't run 20 because we're on the wrong arch / don't have foobar / whatever'.
<Diziet> When there's an interface specification, if it's not insane it'll be easy to glue upstream's test framework into it.
<Diziet> So I think the first thing is to start a requirements capture for that specification, and then to write it.
<Diziet> Now last time we talked about this you mentioned launchpad.  But I'm not sure how that fits in ?  Obviously launchpad will have a set of machinery for _running_ the tests.  Was that what you meant ?
<mdz> I think it would help to dream up some real-world tests for things which are important to us
<mdz> I'm especially interested in upstream self-tests being run on the live system, though it's not clear how practical that will be
<ogra> do you guys only plan testing of the underlying architecture or are GUI tests planned too ?
<Diziet> I don't see why that would be impractical.  How deeply you need to wade into upstream's machinery will vary.
<Diziet> ogra: I don't see why gui tests wouldn't be feasible.
<Diziet> Not that they're easy of course.  You've got all of the standard problems.  But I don't think we'd be ruling it out architecturally.
<ogra> there is a team rom gnome bangalore that developed a gui testing framework
<ogra> *from
<Diziet> Obvious examples are: packages install and remove properly; gs works on oo-generated files; gmp and openssl pass their own selftest suites.,
<ogra> they showed it off at guadec
<Diziet> I think the first step though is to describe how a source package presents the tests it has available.
<ogra> this tests were tied to libgnome iirc, it opened a file typed some text where appropriate, saved the file etc... the common actions tied to libgnome...
<Diziet> Right.
<Diziet> mdz: So do you agree ?  What did you mean about launchpad ?
<mdz> Diziet: upstream tests often have a lot of assumptions about being run from the source tree
<Diziet> Right.  That would be the bit you'd have to hit over the head.
<mdz> one trick of the design will be to provide for both self-tests provided by the package, and generic tests which apply to all or most packages
<Diziet> The source tree would be available, of course.  It's just that you'd have to make sure they actually ran the installed programs.
<mdz> Diziet: well, it won't be practical to maintain significant deltas to upstream test suites, so either we'll find a way to utilize them almost unchanged, or if that isn't practical, we'll lose them
<Diziet> Right.
<mdz> Diziet: we need to be able to test the binaries we are actually shipping in the distribution
<Diziet> But systematic seddery is an option :-).
<Diziet> Indeed so.
<mdz> i.e., test using the installed binary package
<Diziet> Yes, that's what I mean.
<mdz> so we can't rely on the build tree being available
<Diziet> Err, we can rely on the _source_ tree being available.  That is, an unbuilt source will definitely be available because that's where the tests are.
<mdz> "a" source tree, sure, but not one where the actual build has taken place. that means that auxiliary programs built for the tests, and that sort of thing, need to be handled specially
<Diziet> It would make life easier if it were permissible for a test to require a _built_ source tree (eg, the test needs some helper utility which isn't shipped, or some such).
<ogra> Diziet, mdz, seen that one ? http://people.redhat.com/zcerza/dogtail/index.html
<mdz> Diziet: have another meeting right now, let's catch up later or via email
<Diziet> OK.
<Diziet> I was going to suggest that debian-policy would be a good place to have this discussion.
<Diziet> ogra> No.  Looks interesting.
<ogra> there was another gnome centric framework, but written in C
<ogra> cant find the link currently
<xTina> Kamion: Is there a difference between the harddrive-detection udeb in a netboot installer and the regular CD installer?
<mdz> jdub: around?
<mdz> I approved an -announce message but it hasn't shown up in the archives
<mdz> trying to determine if I botched the approval or if the archive is busted
<mdz> ah, there it is
* Keybuk takes away mdz's sugar
<mdz> it usually shows up immediately, this time it took almost 10 minutes
<Keybuk> I still think the server version should be called 1-ubuntu
<mdz> Keybuk: you're playing with fire
<Loiosh> Heh
<Keybuk> mdz: are you saying I'm crap at names?
<mdz> Keybuk: bendy was strike one
<Keybuk> what happens on three?
<mdz> are you sure you want to find out?
<mdz> I know where you live
* sivang runs away screaming
<Keybuk> ya know, this brings back memories of school; the teachers were convinced I misbehaved just to find out what new punishments they'd come up with
<sivang> mdz: what was the -announce msg about?
<sivang> (trying to see if I got it already)
<Loiosh> Ubuntu Server?
* Loiosh kisses googledesktop
<mdz> sivang: as Loiosh said
* Loiosh wags.
<sivang> mdz: ah, but we did already release/have a "server" iso which is a server "edition" right?
<mdz> Kamion: any reason not to move apt-setup ahead of adduser config in d-i, since it's usually non-interactive (and can be slow, e.g. around releases)?
<BenC> right now server is just an install option that doesn't do ubuntu-desktop, right?
<mdz> sivang: that's what the message was announcing
<mdz> BenC: oh, hello.
<BenC> mdz: hey
<mdz> there is a 'server' option on the desktop CD
<mdz> but also a dedicated server CD now
<BenC> mdz: I'll be sending you an email later with some things that mark and I talked about this morning
<mdz> BenC: please do
<mdz> BenC: have you also fixed your contact info in the wiki?
<siretart> does anyone here intend to work on https://wiki.ubuntu.com/NetworkAuthentication for Dapper?
<BenC> mdz: yeah, my cell phone was off by a digit, didn't realize it
<mdz> BenC: whoever has that number has received some stern voicemail messages recently
<BenC> lol
<fabbione> WOWOWOW
<fabbione> my powerbook has been upgraded for free
<fabbione> too bad i still need to get it
<fabbione> "Today, Apple unveiled a new Powerbook with a variety of fantastic new features.
<fabbione> Accordingly, we are pleased to revise your recent order by substituting the original product "
<Loiosh> Ooo =)
<fabbione> neat :) new monitors.. new dvd burner, new battery with extended life
<bddebian3> It's been "upgraded" with a fresh new PII 550Mhz Celeron ;-P
<Loiosh> Perfect to run a server on!
<fabbione> bddebian3: ahaha
<pitti> Dear seb128: Please make my gthumb not crash every time I change to /. Love, Martin
<sivang> LOL
<sivang> pitti: are you loading lots of image thumgs into it ?
<pitti> sivang: actually not, there is not a single picture in my root dir :-)
<dholbach> pitti: will fix that with next upload, hope the backport guys will fix that for breezy, love, daniel
<pitti> (nevermind, I know myself how to operate a debugger - just tickling)
<pitti> Dear Daniel: Thanks for caring about stable releases. Love, Martin
<sivang> guys, stop it, you're killing me
<dholbach> dear martin: i tried to get it in, sorry, for having upset you. love, daniel
<dholbach> dear martin: and now get over it, kthxbye :)
<sivang> dear daniel and martin, how do I become such a good bug fixer like you? with love and admiration, Sivan :)
<dholbach> sivang: read upstream changelogs ;)
<seb128> pitti: this app is maintained by dholbach :)
<seb128> pitti: I use f-spot for my part :)
<pitti> seb128: shying away from good old C gnome code? :-)
<sivang> here we go...:)
<pitti> seb128: seriously, does f-spot rock?
<seb128> pitti: it really rocks imho
<pitti> seb128: I'm quite happy with gthumb, at least as long as it doesn't crash all over the place
<pitti> but it needs this C# stuff
<seb128> right, that's the issue
<dholbach> pitti: gthumb 2.6.8 is really nice
<pitti> dholbach: isn't that always the case? "Yes, the current version sucks, but in 2 months, everything will be ubercool"
<dholbach> pitti: *bllllllllll* :-p
<seb128> I like this date graph from f-spot, and the autorotate according to the exif datas on import
<pitti> dholbach: (I love you too)
<pitti> seb128: gthumb can autorotate, too
<dholbach> pitti: i proposed an ice hockey match for ubz, last proposal was launchpad vs distro, now i'd wish you were in the other team :-ppp
<seb128> I had some usuability griefs with it, but I've not tried for some time
<seb128> I should try again
<pitti> dholbach: Be assured, you don't *want* me in your team
<seb128> dholbach: because you like pain ... ? :)
<dholbach> hahahaa
<dholbach> you guys are awesome :)
<pitti> dholbach: I'm so bad at such games that I will do more for you when I play in the opposite team
<jbailey> I'm not up for hockey.
<jbailey> I could do curling. =)
* pitti proposes volleyball
* seb128 plays football
<pitti> ... or frisbee
<dholbach> pitti: it's just about fun and tackling people :)
<seb128> dholbach: we can do that with football :)
<pitti> dholbach: tickling you mean?
<dholbach> no, not tickling ;)
* pitti excuses to the other channel listeners for being ludicrously OT
* sivang would be in for a soccer match
<bddebian3> :)
<jbailey> pitti: We're discussing UBZ. =)
<sivang> jbailey: shouldn't we be talking technical stuff there?
<sivang> err, s/there/then/
<pitti> jbailey: but I don't want to "develop" my body shape, I'm quite content with the number of legs I have
<pitti> jbailey: so hockey is not for me
<sivang> pitti++
<\sh> pitti: I'm with you playing volleyball ;) so I don't break other peoples bones 
<sivang> seb128: football = soccer ?
* pitti shuts up and asks the other guys to move to #ubuntu-wekillourselves
<jbailey> sivang: Sports are technical.
<\sh> sivang: in europe yes
<jbailey> Always a mix of science and art.
<sivang> \sh: cool, in .il as well
<pitti> jbailey: "art"? not in the .de team then... :-/
<\sh> sivang: american football in europe is called american football or in rugby on the island ;)
<sivang> actually it's something to live and die by in .il. People get depressed badly when they're team looses
<\sh> -in ,)
<sivang> anyway, this is OT so..
<pitti> righto, let's talk again about patches, kernels, and how to beat up dholbach so that he quickly fixes gthumb (SCNR)
<pitti> (sorry dholbach, I'll buy you an extra beer in Montreal :-) )
<dholbach> it's alright
<dholbach> :)
<crimsun> cool, not vulnerable to US-CERT TA05-291A/CAN-2005-3252
<jbailey> pitti: How many does he have to have before it becomes "extra"? =)
<pitti> crimsun: hm, that's not yet in my db
<pitti> jbailey: let's find out :-)
* pitti conceives a nice new Mao rule
<sivang> pitti: you also play Mao ? :-)
<pitti> sure
<pitti> it's a prerequisite for an Ubuntu developer
<sivang> yeah, I know :)
<sivang> Kinnison explained it to me on Mataro
<pitti> sivang: we'll teach you at UBZ
<pitti> ah, so much the better
<sivang> however, my Mao foo has long be forgotten since Mataro
<sivang> ^^^^^^
<jbailey> "explained"
* jbailey grabs a card and looks for Kinnison 
<sivang> hehe
<pitti> jbailey: "taught the hard way"
<Kinnison> jbailey: surely by now you know me well enough to not have actually explained anything
<sivang> jbailey: have you ever been in a Mao match with Kinnison as the dealer?
<sivang> jbailey: hilarious
* Kinnison smiles sweetly
<jbailey> Kinnison: I figured if it wasn't true, you'd pass the card on to the appropriate destination. =)
<\sh> whatever mao is
<pitti> \sh: you'll come to UBZ, right?
<jbailey> sivang: I think so.  I try not to be sober enough to remember.
<\sh> pitti: yepp..
<pitti> \sh: you'll find out, don't worry :-)
<\sh> pitti: I hope it's not MauMau ;)
<sivang> muhahhahahah
<sivang> :)
* pitti grins
<jbailey> \sh: Isn't that Chinese for cat?
<\sh> jbailey: no it's a cardgame in germany :)
<pitti> jbailey: it's a popular child's game
<sivang> \sh: what ever happens, it's part of the game. Remember that :)
<sivang> anyway, I need to get some food, maybe pizza
<sivang> later mates
<Kamion> xTina: no (there isn't actually a harddrive-detection udeb, it's provided by disk-detect - but still they're the same)
<pitti> cu sivang
<crimsun> jbailey: (but yes, it's Mandarin for cat)
<Kamion> mdz: yeah, we're going to be rearranging quite a bit of that in dapper, because tzsetup and apt-setup have both been rewritten upstream to avoid that awful base-config passthrough kludge
<pitti> crimsun: what's that vuln about? it's not yet in the CVE db
<xTina> Kamion: Weird. I have a server machine that refuses to detect its (cpqarray) raid with a netboot installer and not with the regular install CD
<Kamion> mdz: it may even be possible to run apt-setup before base-installer, though I'm not sure about that yet
<\sh> crimsun: really? wow...I didn't even know, that I can pronounce cat in mandarin
<Kamion> xTina: disk-detect itself is the same, but the order of module loading may very well be different
<crimsun> pitti: snort 2.4.x backorifice preprocessor buffer overflow, http://www.kb.cert.org/vuls/id/175500
<Kamion> I view this mostly as a kernel/hotplug/udev/whatever problem
<xTina> Kamion: The modules are fine, it's loaded and the device files are there, I can even mount them on the builtin shell.
<Kamion> xTina: yeah, but load ordering sometimes matters
<sivang> pitti: when I come back, I'd like to discuss some of my sepcs if you will, specifically how to move further with CupsDbusIntegration, or should we just wait to see which BOFs get priority? (Is it worth to have some sort of proof conpect program ready / whatever)
<Kamion> it's all really nasty
<crimsun> pitti: we could ask for http://www.kb.cert.org/vuls/id/MIMG-6HAL5M to be modified, since we only ship 2.3.2 in universe
<Kamion> at least, that's my first guess as to your problem - but I don't have the detailed knowledge to go much further
<pitti> crimsun: 2.3.2 of what?
<crimsun> pitti: snort-2.3.3
<crimsun> err 2.3.2
<pitti> crimsun: ah, I see
<pitti> crimsun: CERT contacted me about this today
<crimsun> ok
<seb128> bzr really rocks !
<pitti> seb128++
<sivang> seb128: how come?
<seb128> it's easy to use
<seb128> it's FAST
<sivang> ah, yes, I've heared that already :)
<jbailey> seb128: Did you see the visualisation plugin that Scott did?
<seb128> jbailey: a screenshot yep
<pitti> bzrk?
<jbailey> Yeah.
<jbailey> It's in my nightly snapshots repo.
<pitti> jbailey: thx for packaging it
<Nafallo> jbailey: oh? :-)
<jbailey> Nafallo: 
<jbailey> deb http://people.ubuntu.com/~jbailey/snapshot/bzr ./
* Nafallo apt-get installs ;-)
<Nafallo> jbailey: oki, three packages updated daily from you now ;-)
<Nafallo> thanks :-)
<jbailey> Glad to help. =)
<\sh> hmmm.../me should use bzr now for python-kde3
<jbailey> \sh: I will write bzr-buildpackage sometime soonish.
<\sh> jbailey: I need to get rid of my patch collection :( 
<Nafallo> \sh: convince nk to switch to trac+bzr, kthxbye ;-)
<\sh> Nafallo: hmm...
<Nafallo> :-)
<\sh> Nafallo: I'm preparing first some new pykde packages ,-)
<Nafallo> :-)
<\sh> jbailey: bzr repos can I pulish on a plain normal webserver? and pulling other branches for merging is working via http?
<jbailey> Yup and yup
* mvo is a bzr fan
<Nafallo> \sh: you know PQM is downloadable? :-)
* pitti just converts his postgresql branches to bzr
<\sh> Nafallo: PQM? oh well...all these abbrevs. My brain is not able to remember all the meanings...SDT, NIT, EMM, ECM, EIT, bla
<pitti> mvo, jbailey: btw, does anybody already have a commit hook that sends out notification emails?
<pitti> I have a nice and generic thing for baz, but not yet for bzr
<jbailey> pitti: I don't think the concept makes sense.
<jbailey> pitti: You're working on a local branch.  Who would it notify?
<pitti> jbailey: I'm still used to pushing my changes to arch.debian.org/arch/pkg-postgresql
<jbailey> I think it makes more sense to have a bzr watch command of some sort which a user can run.
<jbailey> That way you can cron a set of repos to watch, and if the revno changes, notify.
<pitti> jbailey: so that other psql devs see what I do, and I see what they do
<Nafallo> \sh: I dunno. that's what launchpad uses for pulling in patches or something. jbailey probably knows more than me :-).
<jbailey> pqm is a bot that makes baz/bzr behave more like a centralised system.  I don't really know more than that.
<jbailey> All I know is that it can handle merges to a central repo./
<Nafallo> hmm, I _thought_ you knew more than me :-)
<Nafallo> It has reviewers :-)
<siretart> has anyone spotted/worked on a bzr-buildpackage yet?
<Nafallo> <jbailey> \sh: I will write bzr-buildpackage sometime soonish.
<Nafallo> :-)
<sivang> jbailey: what will it do?
<mdz> infinity: please try to make some sense of this tetex mess; we'll have to decide whether or not to bring tetex 3.0 into breezy I think
<pitti> mdz: s/breezy/dapper/?
<Kamion> I assume somebody's noted that it's in unstable already
<pitti> yes, it closed some bugs I filed :-)
<ajmitch> morning
<pitti> Hi ajmitch 
<ajmitch> mdz: would I be able to get a data-munching bug fixed in breezy-updates, since upstream has been kind enough to provide a patch?
<ajmitch> (for a universe package)
<doko> mdz: I think the only "mess" is the relinking problem, which shouldn't tangle us
<mdz> doko:
<mdz>   22     Oct 18 bugzilla-daemon (0.9K) [Bug 18027]  New: linuxdoc-tools: [sgml2latex]  Fails to produce DVI output with teTeX-3.0, a  34 O   Oct 19 bugzilla-daemon (0.9K) [Bug 18068]   New: package installation fails with teTeX 3.0
<mdz>   38     Oct 19 bugzilla-daemon (0.9K) [Bug 18072]  New: tetex-bin: fmtutil-sys fails during package package setup
<mdz>  111     Oct 19 bugzilla-daemon (0.9K) [Bug 18087]  New: tetex-doc: uninstallable due to file overlap with tetex-base
<mdz>  232     Oct 19 bugzilla-daemon (0.9K) [Bug 18111]  New: can't install tetex-bin 2.0.2-31 due to /usr/share/man/man1/texi2pdf.1.gz
<mdz>  260     Oct 19 bugzilla-daemon (0.9K) [Bug 18116]  New: tetex-bin: package doesn't install because of missing mfw binary
<mdz>  337 N   Oct 19 bugzilla-daemon (0.9K) [Bug 18131]  New: tetex-base: Dummy bug: Should not migrate to testing for a while
<mdz> doko: etc.
<mdz> pitti: yes, s/breezy/dapper/
<mdz> Kamion: yes, which is why we care about it at all
<doko> well, looks like the usual -1 version hitting unstable :-)
<jbailey> sivang: Similar to svn-buildpackage
<pitti> night everybody
<bddebian> Later pitt
<bddebian> i
<sivang> jbailey: some gismo that fetches a source from repo, prepares a tarball and then packages into a deb?
<GNULinuxer> sivang: which source ? upstream?
<sivang> GNULinuxer: could be , I think
<GNULinuxer> sivang: hmm ...
<sivang> GNULinuxer: not sure, still waiting for jbailey's response :)
<GNULinuxer> sivang: i have seen such a script for emacs ...
<soumyadip> sivang: you want to pull in sources from CVS/SVN, build it automatically and upload the package to a deb repo ?
<GNULinuxer> sivang: but i guess a generic tool will be difficult. but we can write a script for one specific package
<sivang> GNULinuxer: I think jbailey is writing something like that guys :) I actually have no expertise on that what so ever :)
<GNULinuxer> sivang: heh, that'd be cool then !!
<jbailey> sivang: The tarball has to be present.  It allows easy versioning of the debian/ directory
<sivang> jbailey: eh , cool
<soumyadip> jbailey: you mean get the tarball of the new source and automatically add debian diffs, and requisite changelogs ? 
<jbailey> soumyadip: Well, it's everything in the debian/ directory.  I don't think svn-buildpackage has much in the way of special treatment for diffs.
<jbailey> I might be wrong on that, though.
<soumyadip> well I haven't played around much with svn-buildpackage myself
<sivang> mdz: I see that the partman-auto-lvm issue was not mentioned on the ubuntu.com main site pages (not wiki) , was it fixed/workarounded some way?
<mdz> sivang: bug#?
<sivang> mdz: sec
<sivang> mdz: 15017
<sivang> mdz: ah, I see it got removed entirly
<sivang> sorry for the noise, then
<Robi-> who runs a soft-raid system?
<Lathiat> i do
<ivoks> night guys
<Robi-> can someone explain why ones has to Initialise the superblock with mdadm aftr the hoary->breezy upgrade
<Lathiat> Robi-: hrm no idea
<zyga> hi
#ubuntu-devel 2005-10-25
<zyga> jdub: ping
<sivang> good night all
<zyga> archive.u.c has bad signatures?
<alexr> Hi! Can anybody help me with the question about modifying breezy install CD?
<dholbach> good night
<mdz> sivang: please fix the summary of the splash-down spec to only discuss shutdown, not hibernation. that will be a separate spec
<dholbach> mdz: he went to bed half an hour ago
<ajmitch> mdz: do I just upload to breezy-updates, with right distribution & version number set in changelog?
<mdz> ajmitch: you first mail me a debdiff for review
<ajmitch> alright
<ajmitch> it's nice & small
<bob2> does soyuz support hot tiffani archive love?
<tseng> mdz: Infinite Justice!!!
<schweeb_> tseng: haha, I liked that part too
<jdub> mdz: pong
<jdub> zyga: pong
<mdz> jdub: unping
* jdub recalibrates.
<tseng> yo jdub 
<jdub> hey tseng 
<jdub> how are you?
<jdub> yo jcape 
<jcape> Hey jdub
<tseng> jdub: fine thanks
<jcape> jdub: What's up?
<tseng> your ironpython post seemed to be lacking in GOOD MORNING FREEDOM LOVERS
<jdub> haha
<jdub> my talk to the gnome/ubuntu/random-nl people tonight wasn't lacking in GMFL :)
<tseng> elite
<bob2> is ironpython in ubuntu yet?
<tseng> no, but it sounds like mono compat is "almost there"
<tseng> for now
<TMM> jdub, you ARE still awake :)
* TMM is amazed :)
<tseng> jdub: why are you in .nl anyway?
<jdub> tseng: eurooscon
<tseng> hm oh
<ajmitch> more of the 3B tour?
<tseng> say hello to Edd for me, im sure that con has his name all over it
<zyga> jdub: there is a typo in lists.u.c in the description of ubuntu-pl
<TMM> jdub, you wheren't in .nl for us? I'm so dissapointed ;)
<schweeb_> and tell him to make gnome-bluetooth-manager better :P
<doko> tseng: the thing is, when mono catches up, ironpython already uses features not yet found in the current mono ...
<tseng> doko: exactly
<jdub> tseng: haha, only for a couple of days, but i will
<tseng> cheers
<tseng> doko: those features are beta in MS even afaik
<tseng> C# 2.0 stuff
<tseng> i guess IP is considered beta too
<zyga> jdub: can you fix this?
<TMM> tseng, get the code under one of those nifty new licenses MS published :) (according to /.)
<TMM> :P
<TMM> anyway
* TMM sleep
<tseng> sigh, /.
<mdz> daniels: debdiff for mesa, please
<daniels> mdz: puc/~daniels/debdiff
<mdz> 404
<mdz> xkeyboard-config also
<daniels> mesa-debdiff
<daniels> xkc-debdiff
<daniels> there's likely to be an xorg update if I can find another issue to solve besides the fucking radeon acceleration plague
<jabra> who is the current sshd package maintainer?
<tseng> ubuntu doesnt have package maintainers
<tseng> we stand in circles holding hands and all that
<jdub> jabra: Kamion 
<jabra> uh, I have an idea for patch for the sshd package
<bob2> then submit it to the bts
<jabra> bts?
<daniels> jabra: http://bugzilla.ubuntu.com
<jabra> ok thanks I will do that right now
<jabra> done
<jabra> bug 18153
<crimsun> huh?
<bob2> why do you want to hide your ssh version?
<bob2> also, that has no patch
<crimsun> not only that, but the bug report is useless - just use the Banner directive in /etc/ssh/sshd_config
<jabra> crimsun: banner directive?
<crimsun> Banner /path/to/banner/file
<crimsun> keep in mind that changing your banner is largely futile; a determined person will simply use scanssh
<jabra> true but shouldn't give out which linux distro your using for anyone who telnet's to 22
<crimsun> security through obscurity? not quite.
<tseng> why not
<jabra> because not much information given out
<daniels> apache also gives out the same information, and I don't think anyone's ever really cared
<jabra> you can disable that banner 
<daniels> and you can disable the banner in sshd too
<jabra> k sorry for the useless bug then
<mdz> why does yaboot have an ascii cow in it?
<Kamion> daniels: no, you can't
<Kamion> it's part of the protocol
<Kamion> I've closed the bug WONTFIX though, see explanation there
<Kamion> crimsun: Banner is different and unrelated, FWIW
* Kamion goes back to bed
<mdz> jdub: you're on the front page of lwn
<jabra> Kamion: thanks
<OddAbe19> what's the new date for dapper?
<mdz> OddAbe19: there isn't one yet
<OddAbe19> check check
* daniels drums his fingers on the desk, updates yet more packages locally.
<daniels> jbailey: PING
<jbailey> daniels: yoyosup?
<daniels> jbailey: can you please explain to me in words of two syllables or less why glibc is explicitly preventing me from including linux/types.h?
<daniels> jbailey: a few headers define _LINUX_TYPES_H, so anything including <linux/agpgart.h> tanks because it includes <linux/types.h>, and  naively expects that the types that defines will actually be there
<daniels> navely, even
<jbailey> daniels: No good response beyond that userspace applications should generally not include anything in linux/* or asm/* anyway (per kernel maintainers)
<jbailey> I've done a bit of hacking to make many of the headers usable.  What do you need, and I'll help you figure out the best solution.
<daniels> jbailey: *shrug*, idealism is nice, but I kind of like it when the X server actually has agpgart support, y'know ;)
<daniels> jbailey: i think it's just sys/kd.h that's the main culprit; if it could either a) not define _LINUX_TYPES_H, b) undef it when it's done a la sysctl.h, or c) define __u16 and __u32 when it defines _LINUX_TYPES_H, that'd be great
<daniels> jbailey: my short-term hack was to change linux/types.h's test to _LINUX_TYPES_H_FUCK_YOU_GLIBC, but I don't think that'd fly for uploading to the archive
<jbailey> *lol*
<jbailey> Do you basically need linux/agpgart.h ?
<jbailey> I can tweak that to have usable user-space types.
<daniels> jbailey: yeah, the end goal is a usable linux/agpgart.h
<daniels> jbailey: but tweaking sys/kd.h to have the same __undef_LINUX_TYPES_H hack as sysctl worked too, and it would seem to be correct in any case (even if agpgart should have usable userspace types, which I assume it should)
<daniels> oh, and while I'm at it
<daniels> hm, no keybuk.  damn.
<daniels> (libtool is broken.  shock.)
<jbailey> Nothing in linux/ is intended to be usable by upstream, but I'll hack that into the lkh update
<daniels> upstream -> userspace? :)
<jbailey> upstream like the kernel.
<daniels> ah
<jbailey> The kernel provides no headers that are intended to be used.
<daniels> right
<jbailey> I don't quite understand why.
<daniels> don't question the wisdom
<jbailey> But it's been said more than once, and I know better than to argue.  So I hack the headers to be usable. =)
<daniels> heh
<jbailey> daniels: What's your bugzlilla id?
<daniels> jbailey: daniel.st
<jbailey> <tab completes> thanks
<jbailey> =)
<jbailey> I've filed it as 18157 as a reminder, cc:'d you/
<bddebian> Doesn't glibc provide a stddef.h now?
<daniels> cheers :)
<jbailey> bddebian: stddef.h comes from gcc.
<bddebian> Ahh.. But what if an app is looking in /usr/include or /usr/X11R6/include?
<jbailey> If an app explicitely is looking in /usr/include and isn't trusting compiler search paths, it's broken beyond repair.
<jbailey> gcc and glibc play games with the search paths that mere mortals cannot predict.
<bddebian> Hmm
<jbailey> And -I/usr/include is known to break things all *over* the place.
<ajmitch> that's comforting
<daniels> also, /usr/X11R6/include doesn't exist anymore
<bddebian> Why is everything a PITA? :-)
<bddebian> daniels: I know, that's what started this all.
<jbailey> bddebian: It's not.  It's called trust your compiler and write good code.
<jbailey> =)
<daniels> well, it has *two* things in it.  but they're going the hell away with the first xorg upload dapper ever sees.
<bddebian> Its installing stuff in /usr/X11R6/bin
<daniels> bddebian: boooo
<daniels> bddebian: that was broken even before we went modular
<bddebian> Aye
<bddebian> ajmitch: Make that part of our MOTU goals: To fix packages still installing in /usr/X11R6/bin.  Apparently there are still a few :-(
<bddebian> ;-P
<daniels> s/\/bin//
<daniels> putting stuff in /usr/X11R6 has always violated the FHS unless you're the X SI, IIRC
<jbailey> Hmm.  Do you just grep the logs to find those?
<daniels> jbailey: Contents-*.gz?
<jbailey> daniels: No, that wouldn't tell you who was including stuff from there.
<bddebian> Dunno.  Kyral showed me this one (mgp btw if anyone is curious)
<marcin_ant> is there any emacs packaging guru?
<daniels> marcin_ant: keybuk
<daniels> jbailey: oh, inclusion, right
<marcin_ant> ,seen keybuk
<marcin_ant> .seen keybuk
<marcin_ant> ehh no bot...
<daniels> no
<jbailey> I'm sure had a noisy bot been in here it would've been tied up and tazers a long time ago...
<jbailey> tazered, rather.
<bddebian> heh
<bddebian> How do you know I'm not a bot? ;-P
<jbailey> bddebian: Because you get offended when I make jokes about americans... ;)
* jbailey hides.
<bddebian> Heh.  I don't get offended at jokes about us, it's other things :-)
<tritium> hi bddebian 
<bddebian> Heya tritium 
<marcin_ant> jbailey: be careful bddebian could be FBI/CIA/USAF/NASA/WHATEVERSTUPIDAGENCY bot that reports any joke about americans directly to pentagon with your current position (GPS info) ;)
<jbailey> It's possible.  But I think "Another Canadian making a comment about us" isn't going to register high on their radar.
<jbailey> Especially someone living in the French part of Canada, y'know? =)
<marcin_ant> you don't have oil so you can sleep safely
<tritium> oh brother
<jbailey> Better than that, I live in a province with huge hydro-electric capability.  Most of my electricity day-to-day doesn't rely on oil. =)
<marcin_ant> heh cheap and clean energy is really a nice thing
<jbailey> I was reading something really cool about how they make mechanical "batteries" for dealing with peak load.
<marcin_ant> you should also buy an electic car then you could be 100% oil independent...
<daniels> off-topic ...
<bddebian> Oh but think of all poor fishies you are hurting
<jbailey> Apparently during off time, they can divert streams and such to side chanels that are dammed.
<jbailey> Then just open up those to the turbines during peak time.
<jbailey> daniels: Sorry, dear.
<bddebian> heh
<marcin_ant> jbailey: btw how much money you need to pay for 1l of fuel in Canada?
<marcin_ant> jbailey: is it also so cheap as in US?
<jbailey> marcin_ant: No idea, I don't own a car.
<daniels> dpkg-deb: building package `xserver-xorg-core' in `../xserver-xorg-core_0.99.2-1_i386.deb'.
<daniels> dpkg-deb: building package `xserver-xorg-dev' in `../xserver-xorg-dev_0.99.2-1_i386.deb'.
<marcin_ant> daniels: off topic ;)
<lifeless> fabbione: cm-0.2 is in the queue for sid - so packages should be available soon :0
<infinity> mdz : I expect we'll want TeTeX 3.0 in dapper, I assume "bring it into breezy" was a thinko?
<Amaranth> http://bcm43xx.berlios.de/ <--holy crap
<wickedpuppy> error ..
<fabbione> lifeless: ok
<fabbione> morning guys
<Lathiat> Amaranth: its not actually working yet
<Amaranth> i know, but it looks promising
<Amaranth> unless they spend more time on webdesign then coding
<Lathiat> yeh
<Lathiat> looks like someone actually documented it
<Lathiat> http://bcm-specs.sipsolutions.net/
<Amaranth> btw, someone wanna test a potential gnome-menus bug for me? you have to download alacarte
<Lathiat> mmm, http://linux-bcom4301.sourceforge.net/go/progress
<Amaranth> http://dev.realistanew.com/alacarte-0.8beta2.tar.gz extract and run alacarte-0.8/src/alacarte then move Accessories under System Tools and move it back under Applications (drag and drop)
<Amaranth> whoa, mignight. bed time
<nayif> http://bugzilla.ubuntu.com/show_bug.cgi?id=17555 , who need more info on this bug ask me please ,http://bugzilla.ubuntu.com/show_bug.cgi?id=16629 
<pitti> Hi folks
<nayif> hi pitti 
<ajmitch> hi pitti 
<pitti> mdz: still here?
<pitti> mdz: nevermind
<nayif> who work on gnome?
<pitti> we all do more or less, but the main cracks are dholbach and seb128
<nayif> the  arabic text appear broken and i send to bug about that and mdz askme more info about it ,what info need here 
<jsgotangco> error logs, screenshot if possible, etc.
<sivang> mdz: ok, will do.
<sivang> Good morning all
<pitti> Hi sivang 
<sivang> pitti: Martin :)
* sivang pets epiphany.
<milli> torkel: hey, would you happen to have a new arla deb for breezy?  0.40?  :)
* sivang out for some shopping.
<torkel> milli: nope. We more or less have switched to openafs. When I find some time I will try topick up arla again
<zyga> hey
<zyga> archive.ubuntu.com still has some bad signatures
<zyga> is that okay?
<fabbione> zyga: yes.. just try to update a few times.. 2 of the 4 machines serving archive.u.c are out of sync
<vuntz> hrm
<sivang> fabbione: do you know anything about the slow throughput form archive as well?
<vuntz> I can't send a mail to info@shipit.ubuntu.com...
<mdz> pitti: yes?
<mdz> infinity: see 3+ lines after for context
<fabbione> sivang: no, i assume the servers are still overloaded by release
<fabbione> sivang: check with a traceroute too, to see if there is a problem on the way to archive
<pitti> mdz: nevermind, I mailed you (some u-security-announce unsub problem)
<sivang> fabbione: k, thanks
<jdub> Setting up bzr (0.1.1+20051020-0) ...
<jdub> Compiling /usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py ...
<sivang> zyga: where do you get the bzr packages?
<jdub> Sorry: IndentationError: ('unindent does not match any outer indentation level', ('/usr/lib/python2.4/site-packages/bzrlib/selftest/testplugins.py', 70, 20, ' PLUGIN_TEXT = """\\\n'))
<jdub> dpkg: error processing bzr (--configure):
<jdub> 
<jdub> jbailey: ^^^
<sivang> zyga: ah, got it. Doh
<fabbione> sivang: http://www.ubuntu.com/download/mirror/document_view
<fabbione> jdub, zyga: known problem already reported
<sivang> jdub: I just installed it, seems fine here
<zyga> sivang: jbailes archive 
<sivang> zyga: eh :)
<zyga> Keybuk: so
<Keybuk> zyga: I'm not even sure I have the source to it anymore
<zyga> hehe :)
<zyga> I've got for sure
<zyga> it's nice as a tiny thing to play with
<Keybuk> feel free to publish it as you see fit
<zyga> Keybuk: okay
<zyga> Keybuk: do you know why proffs path is different?
<Keybuk> different models of laptop
<zyga> aww
<zyga> that sucks
<Keybuk> the THRM bit is defined by your bios
<zyga> there is no portable way of mesuring temperature then
<Keybuk> mine happens to define TZ1, TZ2 and TZ3
<Keybuk> hal
<Keybuk> that has (or should have) all the magic to get the right bits
<jdub> so last night
<jdub> i did my 3BT talk
<jdub> at the university
<jdub> and spoke for 2 1/2 hours, including questions
<Keybuk> "3BT" ?
<jdub> my voice is a bit b0rk
<jdub> but now i have to do mostly thesame thing in under an hour
<jdub> it's very tom stoppard
<jdub> Keybuk: badger badger badger tour
<jsgotangco> mushroom musrhoom
<zyga> ohhh
<zyga> that reminds me
<zyga> I've found a strange bug in debian-installer
<zyga> after partitioning phase where I've selected to format one partition on an ATA disk and leave everything else as is
<zyga> the installer borked with something about 'unusual ext2 partition' and 'unable to resize'
<zyga> I don't remember the exact string but I'm sure I could look it up
<jdub> jsgotangco: Treenaks, Seveas and i did the badger dance last night ;)
<Keybuk> jdub: dude, it's so about the drake dance now
<zyga> the setup was as follows: 1 ATA disk, 40GB via /dev/hda and two SATA disks via pci controller, 37 and 200GB
<Keybuk> that's the one where we all stand around in a room twiddling our thumbs and waiting
<zyga> after disconnecting sata disks the installer didn't crash
<zyga> note that I didn't ask it to mount any other partition apart from the formatted / partition
<jsgotangco> lol
<jsgotangco> schnaakkess
<Treenaks> jsgotangco: and we have it on video
<\sh> jsgotangco: http://en.wikipedia.org/wiki/Badger_Badger_Badger
<jsgotangco> Treenaks, oh my link?
<Treenaks> jsgotangco: I haven't pulled it off the cam yet, it's 2.5 hours of DV tape :)
<jsgotangco> i've seen the football badgers before
<Treenaks> football badgers?
<fabbione> sivang: do you have 2 minutes to help me?
<sivang> fabbione: always
<jsgotangco> yes theres also christmas badgers
<fabbione> sivang: you have been working on LP to register specs, right?
<jsgotangco> the footbal badgers say "england england"
<infinity> mdz : Right, context gathered, I'll have to play with as many tetex bugs as I can get my hands on, and monitor the BTS for a while, but I'm still fairly certain that's the route we want to go.  Most of the bugs look trivial, and easier to fix for us than Debian (just due to the fact that I can fix 'em all in a day, rather than waiting on maintainers)
<fabbione> sivang: if so, do you mind to drive me trough the process?
<sivang> fabbione: yes, intend to continue with this and finish up today
* ajmitch wanders back in
<sivang> fabbione: np
<fabbione> sivang: i only have one specs to register, so it's more like to understand the process right at the first shot :)
<sivang> fabbione: 1) Draft your spec on the wiki , add it to UBZ/BOFs page over wiki
<dholbach> good morning
<sivang> fabbione: 2) go to launchapd.net/distros/ubuntu/+specs
<ajmitch> morning dholbach 
<infinity> mdz : And no, I don't know what timezone I'm in anymore either.  I figure if I get REALLY out of whack, I'll be just about right when I get to Canada, though. ;)
<sivang> fabbione: 3) add an entry there, fill required info in requested fields
<fabbione> sivang: ok.. thanks
<sivang> fabbione: 4) "Add to meeting" on the right menu, and you're done :)
<Keybuk> infinity: it's when you arrive on Canada on Wednesday, when it's Sunday for everyone else, you have to worry
<sivang> fabbione: (4) is rather imporant, since if you leave it it doesn't show on the general agenda.
<fabbione> sivang: ok.. thanks
<sivang> fabbione: but really, only one spec? ;-)
<infinity> Keybuk : Well, I /do/ live in the future, so anything's possible.
<sivang> Keybuk: how can that happne? lingoliris :-) ?
<infinity> Keybuk : It's a shame that moving to Australia didn't allow me to win Canadian lotteries, but I suspect this just means I misunderstood how timezones work.
<fabbione> sivang: well i did propose one, but it has hell of a lot of implications :)
<sivang> fabbione: then you should break it to small, "manageable" chunks ;-)
<sivang> fabbione: so we can spec each one of them seperately
<fabbione> sivang: it's not really possible, because it's one block that touches several subsystems
<sivang> fabbione: :)
<fabbione> sivang: url to the RawSpecDraft?
<fabbione> the one to copy and use to write a new one?
<sivang> fabbione: eh, that is now SpecTemplate
<fabbione> ok thanks
<sivang> fabbione: and SpecSpec has some guidelines
<infinity> fabbione : If you go to wiki.ubuntu.com/MyNewSpec, it will offer "SpecTemplate" as a list of templates on the left, so you don't have to copy and paste.
<infinity> Clock on it, and you end up editing "MyNewSpec" with template=SpecTemplate
<fabbione> infinity: i prefer to edit locally in text mode and upload after
<sivang> infinity: ooh, that's cool. This should be linked from launchapd
<sivang> fabbione: that's actually more comfortable :-)
<sivang> editing against web is a pain
<infinity> fabbione : I like to create the initial page to stake my claim on namespace, copy into a text editor, work locally, then paste when done. :)
<Mithrandir> I should hack up my wiki file access handler for emacs.
<infinity> This also prevents firefox segfaulting for NO APPARENT REASON AND LOSING ALL MY EDITS on long wiki pages.
<fabbione> infinity: ehehhe
<infinity> Also, I hate wikis.
<infinity> I wonder if I can get fired for admitting that?
<fabbione> wget --no-check-certificate "https://wiki.ubuntu.com/SpecTemplate?action=raw"
<fabbione> HTTP request sent, awaiting response... 403 FORBIDDEN
<fabbione> wiki it's your birthday!
<Mithrandir> fabbione: it works if you use --user-agent="Mozilla/5.0"
<Mithrandir> which is bloody stupid
<fabbione> Mithrandir: exactly
<mdke> you could file a bug in Moin
<Mithrandir> mdke: it's a bug in how it's set up for us, not in moin per se.
<mdke> ah
<mdke> then https://wiki.ubuntu.com/wiki/bugs or something
<mdke> wiki/BugReports sorry
<coastGNU> Kamion: Is there any roadmap for OEM-Install documentation? E.G. What is the state of art for OEM doc, who is working on documentation, what will be documented, ..., ...
<coastGNU> Kamion: IMO it needs some beef, sasp...
<jsgotangco> coastGNU, like a white paper?
<jsgotangco> it was in the back of my mind last night...
<coastGNU> jsgotangco: There's need for much more like that. - How to remaster a Ubuntu CD, how to set up own preeseed files, how to introduce such modifications in an OEM environment, and much more
<jsgotangco> ahh not on my league then...
<coastGNU> jsgotangco: Up to now OEM install is only a nice to have but it lacks just in the well documented HowTos an OEM will need.
<coastGNU> jsgotangco: There are some of them in the internet but no OEM, at least I don't know any, who will dig for them and fizzle it together.
<jsgotangco> well that's true I only know the obvious details on how it works, but not what's happening underneath...
* jsgotangco is interested to dig on it as well
<coastGNU> jsgotangco: OEM Install is only one little brickstone in the workbench an OEM will need...
<jsgotangco> coastGNU, do you work for an OEM?
<coastGNU> jsgotangco: No, I don't. But Ive been asked by an OEM, only a small one (turnover 200M EUR/Y). But I'm not allowed to work for him on an voluntqary base...
<Kamion> coastGNU: not at present; yes, I know I should pull my finger out and write some ...
<coastGNU> jsgotangco: s/voluntqary/voluntary/
<Kamion> at the moment it's basically just various bits of documentation on the wiki
<Kamion> you're right that much better documentation is needed
<Kamion> the installation manual covers some of the things you're asking for (preseed files)
<jsgotangco> Kamion, it'd be nice to have docs about branding, changing wallpapers, stuff
<Kamion> that I don't know much about myself
<coastGNU> Kamion: I would like to do that. But as I've just told to jsgotangco I'm not alowed to do this on an voluntary base anymore. So may be there might be a way to let it be interesting enough for this OEM to pay for the job.
<Kamion> well, I wouldn't object :)
<coastGNU> Kamion: I've been working for them some years ago, aside the university (precission engeneering). 
<pitti> jbailey: the current bzr snapshot is uninstallable; is it possible in any way to only update the package when the selftest succeeds? (it currently fails)
<Kamion> coastGNU: it's really something I should integrate into the installation manual
<coastGNU> Kamion: As I see you are in the UK, right?
<coastGNU> Kamion: May I ring you up by phone?
<Kamion> I'm not very good on the phone
<Kamion> I'd prefer IRC or e-mail if possible
<coastGNU> Kamion: The better I am :-))
<coastGNU> Kamion: There are some points I will not discuss in public. And email isn't duplex enough...
<jordi> I have an HP laptop here that is havign lots and lots of trouble with Ubuntu breezy
<Kamion> oh, when I said IRC I didn't necessarily mean a public channel
<coastGNU> Kamion: An non public irc channel will be Ok
<Kamion> you know about /query? :-)
<jsgotangco> heh
<jdub> slow interweb
<jdub> evil badness
<jdub> slow interweb
<jdub> this is my song
<mvo> Kamion: do we use APT::Authentication::TrustCDROM currently? 
<Kamion> mvo: no, I don't think so
<mvo> Kamion: and we haven't documented it yet either? I would like to name it "Trust-CDROM" to make it more consistent with the rest of the config options
<mvo> but I want to be sure not to break anything
<Kamion> ./doc/examples/configure-index:77:     TrustCDROM "false";            // consider the CDROM always trusted
<Kamion> *you've* documented it, I haven't ...
<infinity> That doesn't count as documentation, it's auto-generated from the code, isn't it?
<Kamion> and shipped in /usr/share/doc/apt/
<infinity> Well, true.  But who reads that? :)
<infinity> (other than me)
<mvo> right, that's probably enough. 
* mvo makes a note not to document stuff in the future
<Kamion> heh
<Kamion> reminds me of:
<Kamion> <vorlon> elmo: grip_3.2.0-5/sparc seems to have gone missing, marked as
<Kamion>          Uploaded 2 1/2 hours ago and nowhere to be found on newraff
<Kamion> <elmo> uh?
<Kamion> <elmo>       grip |    3.2.0-5 |      unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<Kamion> <elmo> I hid it in the pool, being the cunning cabalist that I am
<Mithrandir> *chuckle*
<infinity> Hah. :)
<\sh> grmpf..
<\sh> dbuntu ... ubuntu for dbox2 i need now 
<Lathiat> dbox2?
<\sh> yes...a dvb-s or dvb-c digital tv decoder box from nokia
<\sh> but I need a special tuxbox version for it now
<Diziet> `Safe and text-oriented boot mode for better clarity and infinite justice on boot' ??
<ogra> \sh, develop one... 
<ogra> ;)
<Keybuk> TO INFINITY AND BEYOND!
<Keybuk> infinity: no, not you
<pitti> sivang: any idea how to fix culmus? (#17175)
* zyga_ server hardware change 
<maswan> Znarl: http://farbror.acc.umu.se/stats/monitordata/index.shtml
<maswan> Znarl: at 15:40 local time I stopped redirecting to one of the hosts
<maswan> Znarl: there are 9 current downloads left, compared to 450-500 on the still active redirect target
<Znarl> maswan : Nice, we're seeing a fairly simular drop in bandwidth.
<pitti> Hi carstenh 
<carstenh> hi pitti 
<seb128> pitti: is there a way to put a label on a vfat partition?
<pitti> seb128: mkdosfs -n
<pitti> seb128: unfortunately there is no tool to *change* a vfat label
<pitti> seb128: there is one for ext2/3 and the like, but not for vfat
<pitti> seb128: well - hexedit /dev/sda1 :-)
<seb128> hum
<seb128> and is nautilus supposed to use the label?
<infinity> It owuld be trivial to hack mkdosfs to support label changing.
<seb128> that's for http://bugzilla.ubuntu.com/show_bug.cgi?id=18036
<pitti> seb128: yes, it is
<pitti> seb128: through hal
<pitti> seb128: not on hard disk, though
<seb128> what I said on the bug
<pitti> seb128: updated and reassigned to hal and me
<seb128> pitti: thanks
<dholbach> who can i add in bugzilla to propose a *-backports upload?
<Kamion> I believe elmo prefers you to contact him directly, not via bugzilla
<Kamion> use e-mail, he's not around today
<dholbach> oh, ok, i thought the backports crew did that
<dholbach> thank you
<Kamion> oh, yeah, if you're not in the backports team, talk to Mez or somebody?
<Mithrandir> Kamion: can you get yaboot-installer to install to an external FW drive?
<dholbach> Kamion: yeah, wanted to CC him in bugzilla/malone
<Kamion> Mithrandir: not unless ofpath can deal with it
<Kamion> Mithrandir: in general failures there are down to ofpath not knowing how to figure out the openfirmware path to the drive
<Mithrandir> Kamion: ok, and OF doesn't support booting off external stuff?
<ogra> dholbach, thats usually done via the backports ML, not bugzilla
<dholbach> i see
<dholbach> then I'd CC the list :-p
<Kamion> Mithrandir: it does, although you often have to feed it the path manually at boot time. the problem is not generally OF, it's that the ofpath utility (part of yaboot) isn't complete.
<ogra> dholbach, jdon will do a backport and put it up for testing somewhere... if the tests are positive he normally triggers Mez/elmo to build it 
<sabdfl> https://www.ubuntu.com/community/processes/newdev
<sabdfl> i've tidied that page up a little bit
<sabdfl> comments? brickbats?
* fabbione checks
<Lathiat> brickbats?
<Lathiat> why not baseball bats :)
<fabbione> sabdfl: any reason why it asks for a login on the www site?
* Lathiat wonders why that page is restricted
<Lathiat> fabbione: i can't even view it
<Lathiat> fabbione: when i login
<sabdfl> fabbione: hmm... let me see
<fabbione> i don't think i have an account 
<Lathiat> fabbione: launchpad ?
<Lathiat> that worked for me at least
<fabbione> that was my first attempt and he told me that i don't exist
<Lathiat> oh
<sabdfl> try now?
<fabbione> much better :)
<Lathiat> yep good
<sabdfl> phew :-)
<sabdfl> NO MORE DEVELOPERS
<pitti> lifeless: "bzr push --help" still says that it will bail out on unknown files, although that does not seem to be true any more. Can this be fixed, please?
<lifeless> pitti: sure thing, can you file a bug please? bzr in launchpad
<Lathiat> "skill and knowledge in the open source. "
<pitti> lifeless: sure
<fabbione> sabdfl: you mention "Ubuntu Service Level Commitment" but there is no detailed explanation (at least linked in the page) to what are these standars
<fabbione> standards even
<fabbione> sabdfl: "Once your have made substantial contributions over a period of 4-8 weeks" <- i think this should be more likely "for not less than 2/3 months"
<sabdfl> fabbione: MOTU?
<fabbione> sabdfl: yes.. 4/8 weeks is easy to achieve in time.. the person might disappear one week later.. it sorts of raise the presence level requirement a bit
<sabdfl> i thnk we should keep MOTU entry pretty straightforward. much more strict for core dev
<fabbione> for core yes..
<fabbione> no doubts
<fabbione> i can tell from an AM experience that 2/3 months filter a lot of people that get overexicited in the beginning and lose interest pretty fast
<fabbione> even for a MOTU, but well.. that's a MOTU decision :) just my 2DKK
<ogra> fabbione, motus that really want to help out appear in #uuntu-motu and work with the team... i think others drop the towel before reaching IRC
<ogra> *#ubuntu-motu
<fabbione> i have a better idea :)
<fabbione> let's add as a task: You must fix at least two kernel bugs to join the community :P
<fabbione> sabdfl: seriously.. it looks ok to me
<dholbach> and you'll do everything alone, fabbione :)
<jdub> grrrrrr
<jdub> my laptop has frozen 3 times in the last few hours
<Treenaks> jdub: disk b0rkage?
<sabdfl> ok cool
<jdub> doesn't look like it
<jdub> can't see anything useufl in the logs
<Lathiat> memtest?
<jdub> extremely annoying
<Lathiat> haha fabbione 
<jdub> Lathiat: might do that tonight
* jdub avoids running firefox, to see what happnes
<mpt> sabdfl: "Being a developer is orthogonal to membership" would be more understandable if "membership" linked to the page about membership
<infinity> sabdfl : I might tone down the "matter of great pride" bit in reference to core developers.  We have enough people clamoring for debian.org email addresses purely for prestige reasons, I don't think we need to make ubuntu.com end up the same way.
<pitti> sabdfl: so a developer does not need to be a member? that's surprising
<infinity> pitti : Later on, it states they have to.
<pitti> then it's not orthogonal
<mpt> hmm, true
<mpt> it's a subset
<infinity> No, but technical people LOVE the word orthogonal. ;)
<mpt> or a ... post-requisite?
<Lathiat> yeh its just a buzz word
<pitti> but the correct word would be "imply"
<Lathiat> no one really knows what it means
<pitti> Lathiat: it has a clearly defined meaning
<Lathiat> sure but no one KNOWS so they just assume ;p
<Lathiat> 'wow big word, ubuntu membership is cool' :)
<mpt> Actually, since "you need to be a member" is said twice elsewhere, that sentence could be nuked
<pitti> mpt++
<fabbione> ahahah
<fabbione> oh well
<fabbione> time to get off line
<fabbione> later guys
<pitti> cu fabbione 
<fabbione> (are we there yet?)
* fabbione hides
<infinity> mpt : I thin kthe point of that sentence is to discourage people from applying to be developers when they don't need to for their level of participation.
<infinity> mpt : Hence, the sentence should stay, just be reworded to not have false logic. :)
<infinity> mpt : It's important to point out to people that you don't need upload rights for a variety of contributions.
<infinity> mpt : Yet another problem Debian has that we shouldn't repeat.
<mpt> infinity: well, it's already repeated twice
<mpt> actually, three times
<mpt> unless you mean, "You can be a member without being a developer"
<infinity> mpt : Yes.
<infinity> mpt : That's the important distinction.  That membership doesn't require developership, and most people shouldn't even be reading that page to start with.
* mpt hunts for the "Edit" link on the page :-)
<Lathiat> ergh, i seem to havelost my ability to edit bugs in launchpad
<Lathiat> +editstatus that is
<Lathiat> eh wtf it worked this time
<Kamion> Lathiat: anyone with mathematical training should know what it means
<Kamion> (orthogonal)
<marcin_ant> is there something like 'breezy goals' wiki page but for dapper release?
<mpt> Lathiat: If you have multiple windows open, and log in in another window, the link in the first window won't go to the right place
<marcin_ant> and more - are there any bounties available for dapper? (especially if not released with breezy)
<apokryphos> marcin_ant: https://wiki.ubuntu.com/DapperDrake
<Lathiat> mpt: oh, right, thats probably what happened
<marcin_ant> apokryphos: thanks - and what happened with bounties - any available with dapper?
<apokryphos> marcin_ant: I imagine several will be deferred forward, but either yet-to-be-determined or just not documented yet
<ogra> marcin_ant, bounties are handled in launchpad now afaik
<ogra> search there ...
<marcin_ant> ogra: welll I did... 125 bucks and pretty hard things to do...
<marcin_ant> ogra: thx
<marcin_ant> ogra: btw does anyone in ubunutu care about emacs packages for breezy/dapper?
<ogra> marcin_ant, wrong person to ask, i'm heavy vim user ;)
<Mithrandir> marcin_ant: I care very much about emacs, yes.
<ogra> so i dont care at all :)
<Mithrandir> $ pgrep emacs | wc -l
<Mithrandir> 8
<marcin_ant> ogra: currenlty packages for emacs are pretty much outdated (emacs22 not released yet but pretty much stable and with a lot of new and nice stuff)
<marcin_ant> ogra: ok :)
<ogra> marcin_ant, they'll surely be in dpper if they release in time
<ogra> *dapper
<infinity> Not released yet probably means we won't carry it.
<infinity> Supporting CVS snapshots longterm is a serious pain.
<marcin_ant> infinity: well that's true but you know - emacs development is really slow
<infinity> I've noticed. :)
<marcin_ant> infinity: and in fact I really don't know why they don't release much often - in my opinion emacs22 is quite ready for release...
<infinity> Because emacs is mostly used by people as slow as upstream? :)
<marcin_ant> infinity: yet another vi user?
<infinity> (Or, more to the point, emacs users are used to stability, both from the quality of code, and an unchanging feature set, and they hate moving targets)
<infinity> Nah, I'm mostly editor agnostic.
<Diziet> I'm still using Emacs 19.
<infinity> Diziet : Thank you for proving my point. :)
<marcin_ant> infinity: well it's true but in fact packages for emacs in debian/ubuntu - sorry - they sucks pretty much
<seb128> I would be happy to have a emacs-gtk2 :p
<marcin_ant> seb128: I got emacs-gtk2 packaged already
<pitti> seb128: there is gvim, so what else do you need? :-)
<marcin_ant> seb128: don't listen to pitti ;)
<seb128> pitti: I'm a vim newbie and not wanting to learn another editor :p
* pitti resists the temptation to cry out "VIM RULEZ" :-)
<Kinnison> Kamion: I'm rolling your debian_installer stuff into launchpad :-)
<pitti> seb128: that's perfectly reasonable :)
<seb128> anyway, I want NEW CRACK
<seb128> WHERE IS DAPPER :)
<marcin_ant> infinity: and another thing that maybe quality of code in emacs is high but quality of deb packages is really low
* Treenaks takes the scalpel.. a new crack you said?
<pitti> seb128: I already stacked new crack in chinstrap:~/uploads :-)
<seb128> nice :)
<marcin_ant> infinity: especially dependencies and such things... there is a lot of problems with them
<infinity> marcin_ant : Bug filed with patches are welcome.
<infinity> s/Bug/Bugs/
<infinity> Complaining that "stuff sucks" doesn't help much.
<marcin_ant> infinity: well the problem is that these bugs need to repackage emacs
<marcin_ant> infinity: and rethink policy for emacs
<azeem> marcin_ant: is emacs-snapshot(-gtk) not what you want?
<seb128> marcin_ant: http://lists.debian.org/debian-emacsen/ to discuss changes maybe?
<marcin_ant> azeem: yes - I got it already and heavy modified by myself
<azeem> what do you mean with "these bugs need to repackage emacs"?
<marcin_ant> seb128: well it's pretty hard to talk with these people since they think that they current packages and debian policy for emacs is brilliant
<Kamion> Kinnison: the raw-installer code?
<infinity> Kinnison : \o/
<Kamion> Kinnison: rah, thanks
<marcin_ant> azeem: the thing is that emacs is 'emacs' binary and a bunch of *.el files in common package
<marcin_ant> azeem: and there are dependencies set in debian/control in emacs21|emacs-snapshot and so on
<Kamion> marcin_ant: welcome to the need for compromise ;-) they in turn probably think you don't understand any of the benefits of the current system and just want to change things for the sake of it ...
<Kamion> I'm sure there's a middle ground if you come to it with an open mind
<marcin_ant> azeem: but the problem is that these dependencies are in fact related with emacs binary
<marcin_ant> azeem: while there is a really long list of dependencies required for some emacs modules
<marcin_ant> azeem: short example - flyspell.el requires ispell
<marcin_ant> azeem: while ispell is not on dependencies list
<marcin_ant> azeem: the same for tramp, ange-ftp and so on so on
<marcin_ant> azeem: so we have two options - add _all_ these dependencies to emacs debian/control
<marcin_ant> azeem: or split emacs package to small packages with small list of dependencies in each 'subpackage'
<Kamion> people should be allowed to use Recommends for that kind of thing
<marcin_ant> azeem: and yet another thing is that we have a lot of doubled software - for example speedbar is in emacs21 while there is speedbar as separate package - the same with gnus and many more
<marcin_ant> Kamion: sure but it's not so easy
<Diziet> This kind of thing is one thing that Recommends is for.
<marcin_ant> Kamion: yet another thing is that it depends if some emacs packages load when emacs starts or not
<Diziet> ??
<marcin_ant> Kamion: if you got something in your load-path for emacs then it _should_ work - just work
<marcin_ant> Diziet: for example - flyspell.el is in emacs load-path
<Diziet> If you have the right autoloads.
<marcin_ant> Diziet: it means that you can use this at any time you want
<Diziet> Yes, but I don't see your point.
<marcin_ant> Diziet: but if you don't have ispell - you will get error message
<Diziet> So install ispell then.
<marcin_ant> Diziet: my point is - things should _just work_ - but they don't
<Diziet> http://lists.debian.org/debian-ctte/2002/07/msg00017.html seems tangentially relevant.
<marcin_ant> Diziet: it's not ubuntu philosophy right? - and this is why you got dependencies for
<Diziet> You think it should automatically install ispell for you ?
<marcin_ant> Diziet: ispell should be installed before
<Diziet> But I might prefer not to install ispell on my 24Mb 486/33.
<azeem> marcin_ant: what's wrong with Recommends? 
<marcin_ant> Diziet: then you don't need flyspell.el too
<Aegir> Heheh. Tinkering with the 'Browser Appliance' VMWare made for the VMWare player. Infact, doing an upgrade to Breezy from hoary... Lets see how this works
<marcin_ant> azeem: Recommends are for things that are optional/additional right?
<Diziet> marcin_ant: If I don't have flyspell.el, then when I say M-x flyspell it gives me an error message.
<Diziet> Is that somehow unacceptable ?
<marcin_ant> azeem: but not for things really required to run something
<azeem> marcin_ant: I think it also applies to this case, i.e. a dependency for an optional part of the package
<marcin_ant> Diziet: no it will say [No match] 
<Diziet> That's an error message.
<azeem> not a very good one, though
<Mithrandir> marcin_ant: in the case of gnus, what would you do?  Just not have the gnus released with emacs, or not the newer upstream version?
<Diziet> Why do you care so much exactly what kind of error message you get ?
<marcin_ant> Diziet: well you will get the same error if you will try to execute 'blablbalba' on gnome-terminal
<marcin_ant> Diziet: error and 'no match' are not the same things
<marcin_ant> Diziet: no match means that there is no software you want to use
<marcin_ant> Diziet: error means that your software is installed but broken - it's something different
<Diziet> If you type `ispell' in a gnome-terminal you get the same error message as if you try to run it via flyspell, surely ?
<Mithrandir> marcin_ant: micropackages is not the solution, really.
<Diziet> This distinction of two kinds of error is meaningless.
<marcin_ant> Mithrandir: well maybe they aren't but if you got gnus in emacs and gnus as separate package then you need to have an easy way to configure which one you want to use
<Mithrandir> marcin_ant: yes.  Load-path.
<Diziet> In particular, please read what I wrote in http://lists.debian.org/debian-ctte/2002/07/msg00001.html.
<marcin_ant> Mithrandir: and another thing is that as Diziet said - why double packages on something like 24mb 486/33?
<Mithrandir> marcin_ant: why increase the size of the Packages file for _everybody_?
<Mithrandir> 22M     /var/lib/apt/lists
<Mithrandir> which means running apt-get update takes more time, it means running apt-get install takes more time, and so on.
<Mithrandir> marcin_ant: so just having stuff in Recommends or Suggests is, IMO, just fine.
<Diziet> xenophobe:~# time dpkg -l >/dev/null 
<Diziet> real    1m33.397s
<marcin_ant> Mithrandir: so I should create a list of recommended packages for emacs and send patches for debian/control in emacs21
<infinity> Diziet : Ouch.
<Mithrandir> marcin_ant: sure, that would make sense.
<Diziet> That 24Mb 486/33 I mentioned is not hypothetical.
<marcin_ant> Diziet: :D
<marcin_ant> Diziet: and now I feel much better in front of my few years old machine ;)
<Diziet> That's just the firewall, thankfully.
<marcin_ant> Mithrandir: so - recommendations are ok
* Mithrandir likes his own box better:
<Mithrandir> dpkg -l  0,07s user 0,01s system 40% cpu 0,208 total
<marcin_ant> Mithrandir: but what about doubled software?
<Mithrandir> marcin_ant: I don't see it as a problem, can you try explaining what you think the problem is?
<jbailey> pitti: It does thatnow.
<marcin_ant> Mithrandir: problems -> gnus, speedbar, calc, tramp and propably more
<marcin_ant> Mithrandir: they are included in emacs - but also available as standalone packages
<Mithrandir> marcin_ant: you're not explaining why that is a problem.
<pitti> jbailey: great
<jbailey> pitti: No, as in, why did it pass all the selftests? =)
<pitti> jbailey: I tried to install the latest package some 7 hours ago, and they failed
<jbailey> It still fails.
<pitti> jbailey: ok, then we still have the same packages
<jbailey> Yup
<pitti> jbailey: I'm not sure whether the failed selftest is the cause for the failed installation, or the other way round, though
<jbailey> There is no failed selftest...
<jbailey> That's what I'm saying.
<jbailey> "There is no spoon"
<marcin_ant> Mithrandir: I think that if you have two different versions of the same software then it's a problem itself
<marcin_ant> Mithrandir: another thing that 'Joe user' will be confused
<Mithrandir> marcin_ant: so you think that we have emacs21 and emacs21-nox is wrong?
<marcin_ant> Mithrandir: because when he is browsing a list of packages in synaptic/aptitude
<Mithrandir> or the plethora of xemacs versions
<marcin_ant> Mithrandir: than he can see for example 'calc' while he already has _newer_ version of calc bundled with emacs21-common 
<marcin_ant> Mithrandir: emacs and emacs-nox are the same things but with different compilation options
<paulproteus> Do you guys want a non-broken us.archive.ubuntu.com?  I can offer my computing club at JHU if you all want another host to put in a pool.
<marcin_ant> Mithrandir: speedbar bundled with emacs and speedbar standalone are different versions (releases) of the same application
<Mithrandir> marcin_ant: yes, but iirc emacs gives you the newest one, doesn't it?
<marcin_ant> Mithrandir: and that's the point - maintainers should decide - to have software bundled with emacs
<marcin_ant> Mithrandir: or as separate micropackages
<marcin_ant> Mithrandir: so if they got speedbar in emacs then remove speedbar standalone
<marcin_ant> Mithrandir: or if you got speedbar standalone then remove this one from emacs
<carstenh> or just build calc and emacs31 from the same source-package?
<Mithrandir> marcin_ant: the emacs21-speedbar won't necessarily work with xemacs21 and vice versa.
<marcin_ant> carstenh: and that's another thing....
<marcin_ant> Mithrandir: standalone speedbar won't necessarily work with emacs22 too
<Mithrandir> marcin_ant: correct, so how would you solve that?
<marcin_ant> Mithrandir: no idea :D
<Diziet> I don't see what's wrong with bundling some foobar package with emacs46 and then having a separate foobar package which overrides the autoloads.
<marcin_ant> Mithrandir: this is why I'm here :)
<Diziet> overrides> Only in the cases where it works and is better, of course.
<Mithrandir> Diziet: for some definition of "works" and "better".
<marcin_ant> Mithrandir: carstenh idea is also pretty nice - to split emacs21 to emacs21 common and build emacs21-speedbar (only for emacs21 in dependencies and emacsen-install scripts!)
<Diziet> Mithrandir: Yes, of course.  That's why we're not robots.
<Diziet> marcin_ant: Nightmarish.  Zillions of pointless packages.
<Mithrandir> Diziet: we might want to give our users the option to go with what's shipped upstream as well as jump forward when there's a newer release there.
<Diziet> All of which will have an insane cross-dependency/conflict nightmare with half of the ohters.
<marcin_ant> Mithrandir: but the problem is that it is pretty hard to define versioning/naming convention
<Diziet> mithrandir: Well, if you do it sanely, there'll be a way to set locally what it does.  Or isn't that what you meant ?
<marcin_ant> Diziet: so... following your idea - we should just remove gnus/speedbar/calc as standalone packages
<Mithrandir> marcin_ant: if we take a step back and look at this whole thing, you think that making a zillion split packages is better than having emacs21, speedbar, gnus and some more as separate packages?
<Diziet> marcin_ant: They should be standalone packages iff they are shipped and maintained separately upstream.
<marcin_ant> Diziet: and bundle everything in emacs-common
<Mithrandir> marcin_ant: no, the gnus package for instance is very useful in some circumstances, since it has fixes I need.
<Mithrandir> for a long time, gnus in emacs didn't do MIME, while the gnus package did have that support
<marcin_ant> Mithrandir: right - but then if you want to use gnus - from standalone package
<marcin_ant> Mithrandir: then you don't need this one from emacs21-common - right?
<carstenh> marcin_ant: i did not suggest what you said, just put all that packages in one source package, i.e. (Source-)Package: emacs21, Binary: calc. this would avoid having the same source twice in the archive which is always suboptimal
<Mithrandir> marcin_ant: I might not, but the other user on the same system as me might not agree.  and it doesn't hurt to have it there.
<marcin_ant> carstenh: you are right - but you should read debian policy for emacs
<Mithrandir> carstenh: no, people might want the older version because they're more conservative, for instance.  Forcing them to run CVS snapshots of gnus would be wrong.
<marcin_ant> carstenh: their idea is that you should have an ability to install more than one instance of emacs - called 'flavor'
<Mithrandir> marcin_ant: which I think makes a lot of sense, at least for multiuser systems.
<marcin_ant> carstenh: and then you could have for example emacs20 emacs21 emacs22 and xemacs on single machine
<carstenh> hmm, ok. the conservative argument is good :)
<Mithrandir> marcin_ant: it makes a lot less sense for single-user systems, I agree
<Diziet> marcin_ant: The multiple versions thing is very sensible.
<Mithrandir> marcin_ant: if you compare how well the emacs packaging and policy works, compared with, say, the python one, I think I know which I prefer. :-)
<marcin_ant> carstenh: and if you got some external package - say 'speedbar' then you get source .el files in your deb package
<marcin_ant> carstenh: and then specialized install script from package called emacsen-common byte-compiles this speedbar sources
<Diziet> -chiark:~> ps -ef | grep emacs | grep -v gnuserv | awk '{print $8}' | sort -u
<Diziet> emacs
<Diziet> emacs21
<Diziet> grep
<Diziet> xemacs
<Diziet> xemacs21
<marcin_ant> carstenh: for each emacs 'flavour' on your machine
<Diziet> `emacs' is emacs19.
<Diziet> `xemacs' is xemacs21.  I also have emacs20 but no-one is running that atm.
<Diziet> -chiark:~> ll -uL /usr/bin/emacs20 
<Diziet> -rwxr-xr-x    1 root     root      2917428 Oct  8 02:44 /usr/bin/emacs20*
<marcin_ant> Mithrandir: sorry to say but all this is just insane
<marcin_ant> Mithrandir: sooo we have an ability to install more than one emacs at the time
<Diziet> I'm not hugely convinced by the whole byte-compiling thing but it's probably better than most of the other options.
<marcin_ant> Mithrandir: ok - we got 'flavours'
<Diziet> marcin_ant: The multiple versions thing is very sensible.
<marcin_ant> Mithrandir: but do we need 'flavours' for gnus and other packages too?
<Diziet> Oops, mispaste.
<marcin_ant> Diziet: I agree but only for binaries - I mean /usr/bin/emacs
<Diziet> What do you mean ?  You're saying you don't want both Emacs's (whichever Emacs) and separate gnus ?
<marcin_ant> Diziet: but not for external packages
<Mithrandir> Diziet: the alternative would be to ship pre-compiled .el files, which would be insane when we have multiple emacs versions in the archive.
<marcin_ant> Diziet: no - I want to have emacs20, emacs21 and so on
<Mithrandir> marcin_ant: we don't have flavours for gnus and other external packages.  We have the ability to install a newer version which overrides the built-in one.
<Diziet> mithrandir: Quite so.  It would mean that an Emacs addon source package would Build-Depends on lots of Emacs binaries.  Or that the .deb it produced would depend on which you had installed.
<marcin_ant> Diziet: but then I want single version of gnus, speedbar etc.
<Mithrandir> Diziet: my point exactly. :-)
<Diziet> marcin_ant: Well, sorry, but people seem to like having a choice.
<marcin_ant> Mithrandir: and this never one overrides it in /etc/emacs/site-start.d ?
<marcin_ant> Mithrandir: and is... system wide?
<marcin_ant> anyway we have three options
<Mithrandir> marcin_ant: seriously, I don't see it as a problem. 
<marcin_ant> Mithrandir: ok then example
<marcin_ant> Mithrandir: you got 'Joe users' that runs apt-get install emacs21
<marcin_ant> Mithrandir: then he gets emacs21 with calc bundled with this package
<Mithrandir> s/apt-get install/installs through synaptic/, but yes.
<marcin_ant> Mithrandir: but he has no idea that he already has 'calc'
<marcin_ant> Mithrandir: and then he runs 'ctrl+f' to get list of all packages for emacs
<marcin_ant> Mithrandir: and then he runs apt-get install calc - and gets older version of calc that he already has
<azeem> would a Provides: help here?
<Diziet> Well, it's probably wrong when that happens.  Some bit of startup stuff in site-start.d should choose the `best' one by default.
<Diziet> azeem: No.
<marcin_ant> Mithrandir: I know that emacs users are usually 'power users' but don't you see that current policy is pretty confusing?
<Mithrandir> marcin_ant: how do I find out what version "calc" bundled with Emacs is? :-P
<marcin_ant> Mithrandir: well if there is no M-x calc-version
<marcin_ant> Mithrandir: than you propably should get some info from source code....
<Mithrandir> marcin_ant: no calculator-version {function,variable}, no.
<Mithrandir> it's not noted in the source code either.
<Mithrandir> anyway, I don't think it's particularly confusing, no.
<marcin_ant> Mithrandir: while.... holy crap you cannot take a look at .el because there is no el file for calc
<marcin_ant> Mithrandir: if you don't have emacs-el package <rotfl>
<Mithrandir> sure you can, install emacs21-el
<Mithrandir> it's usually not shipped, since most people don't need it
<pitti> lamont-away: ping
<marcin_ant> soooo as you see you have to be a kind of 'power user'/linux guru/hacker/cracker
<marcin_ant> Mithrandir: to know about all these things
<Diziet> You have to know what software you want to use.  But I think that can be expected of Emacs users.
<Mithrandir> marcin_ant: no, I just don't think it's so bloody hard you're trying to make it. :-)
<marcin_ant> Mithrandir: an average user won't take a lok at source code to get which version of software he has
<Mithrandir> marcin_ant: I just noted that there's no way to get the version of the "calc" shipped with emacs21, so I wondered how you knew it's older
<marcin_ant> Mithrandir: the version info is in calc.el
<Mithrandir> $ dpkg -L emacs21 | grep calc.
<Mithrandir> $
<marcin_ant> Mithrandir: in comment on top - I got emacs-cvs so my calc is 2.1
<marcin_ant> Mithrandir: maybe try dpkg -L emacs21-el | grep calc
<marcin_ant> Mithrandir: or emacs21-common
<Mithrandir> marcin_ant: $ grep version /usr/share/emacs/21.4/lisp/calculator.el doesn't give me anything resembling relevant (except :version "21.1", which is the emacs version
<bob2> in conclusion, people smart enough to use emacs are not dumb enough to be confused.
<marcin_ant> Mithrandir: calculator.el != calc/calc.el
<Mithrandir> marcin_ant: well, emacs21 doesn't ship any calc.el
<marcin_ant> Mithrandir: emacs21-common?
<Mithrandir> marcin_ant: there is no calc.el in emacs21-el.
<Mithrandir> marcin_ant: and if calc is older than the version shipped with emacs22, it just shouldn't build for emacs22 until there's a newer version of calc out than what's shipped in emacs22
<marcin_ant> Mithrandir: ok - got me
<marcin_ant> Mithrandir: calc is bundled with emacs-22 (cvs)
<marcin_ant> Mithrandir: anyway you still can try
<marcin_ant> Mithrandir: gnus, speedbar
<Mithrandir> marcin_ant: but if you install calc, it won't try to build for emacs22, unless there's a bug in the package.
<Mithrandir> marcin_ant: gnus is newer than what's in emacs21, I can't be arsed to install speedbar.
<marcin_ant> haaa and now I need to take a look at the source - just a moment
<Mithrandir> marcin_ant: anyway, I think we've worked this down to "if installing a separate package makes the available version in an emacs version older, it's a bug"
<xyz> hello guys
<xyz> I have a question
<marcin_ant> ehh no there is no 'calc' in emacs21*.orig.tar.gz...
<xyz> when I try to start the Xorg server as user/root I get an error, which says that the priority is set to -1
<marcin_ant> Mithrandir: right
<Mithrandir> marcin_ant: and bugs are easy.  They just need to be fixed.
<xyz> I'm using kernel 2.6, therefore it has to be set to 0
<xyz> I also did a dpkg-reconfigure xserver-common
<marcin_ant> Mithrandir: but calc were just wrong example - because calc is bundled with emacs22
<xyz> and set the nice level to 0
<xyz> but it still doesn't work with the same error: 
<Mithrandir> marcin_ant: well, the package tells the emacs compile scripts what emacsen it works with
<xyz> X: warning; process set to priority -1 instead of requested priority 0
<marcin_ant> Mithrandir: there is stil a question what about another bundled packages...
<marcin_ant> Mithrandir: hmm then just a moment
<marcin_ant> Mithrandir: ok - calc will not install on my machine while I don't have emacs22
<bob2> xyz: warning != error
<xyz> yes
<xyz> I mean it's an error for me
<xyz> lol
<xyz> because the xserver doesn't work and I don't have an idead, how to set the nice level to 0 (though dpkg-reconfigure xserver-common didn't work)
<bob2> this is not causing X not to work
<xyz> Xorg is working
<marcin_ant> xyz: sorry to say it but it's #ubuntu problem
<xyz> k
<xyz> just gimme a hint
<marcin_ant> Mithrandir: so our point is that we should keep packages that are bundled with emacs in emacs[xx] -common
<Mithrandir> marcin_ant: uh, no?
<marcin_ant> xyz: try to take a look at
<Mithrandir> or possibly, yes.
<Mithrandir> emacs21-common should probably contain the .elc files for emacs21 and emacs21-nox
<marcin_ant> xyz: /var/log/Xorg.0.log
<marcin_ant> and we should take a look at emacs install scripts they shouldn't allow overriding newer versions with older from standalone packages
<marcin_ant> Mithrandir: but we also should improve our Recommends: tags in debian/control for emacs[xx] 
<Mithrandir> marcin_ant: sure.
<Diziet> I'm not convinced.
<Mithrandir> Diziet: about recommends?
<Diziet> I don't think emacsnn should Recommend every random program that some .el happens to invoke.
<xyz> well the file is ok, just: Warning: font render for ".pcf" already registered at priority 0, which means, that it has nice level 0 but not the instance of the xserver :(
<Mithrandir> Diziet: recommend/suggest, obviously.
<Diziet> Well, possibly Suggest.
<bob2> xyz: that still won't stop X working; also, #ubuntu
<Diziet> But bash doesn't Recommend everything you might type at the command-line.
<xyz> X works
<xyz> running Xorg gives me an Xserver
<bob2> also, #ubuntu
<Mithrandir> Diziet: emacs is providing a bit more hooks for calling external stuff than bash does, though.
<xyz> but gdm uses startx, also other scripts use startx
<Diziet> Yes, but by and large it's little more than hooks.
<xyz> and using startx I always get nice level issues
<ogra> xyz, please thake that to #ubuntu
<Diziet> In the days before the magic wm automagic menu systems, we didn't have wms Suggest every program you might invoke from a menu.
<xyz> I'm on #ubuntu and there's no one, who can answer me that
<marcin_ant> Diziet: but mldonkey-gui suggests mldonkey-server - right?
<marcin_ant> Diziet: if flyspell.el is frontend to ispell it should suggest it
<Mithrandir> Diziet: if the list gets too big, it should be trimmed, but I don't see it as a problem if we have a bunch of suggests in there.
<marcin_ant> Diziet: the only problem is that emacs could be in fact standalone desktop environment
<Diziet> marcin_ant: flyspell.el isn't a package.
<marcin_ant> Diziet: and the list of recommended/suggested packages can be huge
<marcin_ant> Diziet: it's part of emacs
<Diziet> mithrandir: I think the situation is exactly analogous to a wm menu.
<Diziet> marcin_ant: Yes, but your statement doesn't hold true any more if we s/flyspell/emacs/ because `emacs is a frontend to ispell' isn't correct.
<marcin_ant> Diziet: so if emacs with flyspell is frontend to ispell then there should be some kind of dependency between emacs and ispell
<Diziet> can be huge> Um, there are costs to big suggests/recommends lists.  They should be avoided.
<Diziet> `emacs with flyspell is frontend to ispell' is not a correct statement.
<Diziet> Because it's lots of other things too.
<Diziet> I agree that a package whose primary function was to be a frontend to ispell should Depend on ispell.
<marcin_ant> Diziet: following your way - xmms is not frontend to mp3
<Mithrandir> Diziet: it's much easier to sanely debate that once we actually have a list of suggested changes rather than "the list is going to be too big", "no, it won't", "yes, it will", "no, it won't".
<Diziet> A package which has being a frontend to ispell as an important but not wholly critical part of its function should Recommend.
<Mithrandir> once we have a list, it can be debated sanely, adjusted, trimmed and so on.
<Diziet> A package which has being a frontend to ispell as a significant feature, compared to its other functions, should Suggest.
<marcin_ant> Mithrandir: good point
<Diziet> But being a frontend to ispell is not, given all of the other things that Emacs does, significant.
<marcin_ant> Diziet: ispell is just first example 'from the hat'
<Diziet> mithrandir: I'm not saying the list will be too long.  My arguments work even if the list of spurious dependencies is fairly short.  But someone said that length didn't matter, which isn't true.
<Diziet> marciln_ant: Indeed.
<Mithrandir> Diziet: you appear to be arguing that any extra Recommends/Suggests added to emacs21 based on a review will be spurious and you appear to be really busy digging yourself a nice trench.  Mind coming out of it and be a bit constructive?
<Mithrandir> (I'm not saying you're wrong, but I'm saying the direction the discussion is moving is silly, pointless and unproductive)
<marcin_ant> Diziet: is ange-ftp and ftp dependency something better than ispell?
<Diziet> mithrandir: I'm just talking about ispell, because that was our example.
<marcin_ant> or tramp which is standalone package for emacs21 (bundled in emacs-snapshot)
<Diziet> And how is saying I don't think dependencies should be added unconstructive ?  It's not unconstructive to say that the current situation is correct, any more than it's unconstructive to argue in favour of changing it.
<xyz> so gys
<marcin_ant> and in tramp package (standalone) you got suggestions for ssh|telnet|etc
<xyz> *guys
<xyz> I still don't get an answer on #ubuntu
<Mithrandir> Diziet: you're whacking away at the example rather than what it examplifies.
<xyz> would be really nice to hear from you developers
<Mithrandir> xyz: this still isn't a support channel.
<xyz> how to fix it
<marcin_ant> while if tramp gets bundled with emacs22 there is no word about these dependencies
<Diziet> marcin_ant: ange-ftp (bundled) should not cause a mention of ftp in the emacs control file.
<xyz> well
<xyz> apt-get dist-upgrade should work
<Diziet> tramp (standalone) should probably Recommend ssh or whatever the preferred transport is.
<xyz> so, you're responsible that it works
<xyz> and it messed everything up
<Keybuk> xyz: this is not a support channel, please take it to #ubuntu
<ogra> xyz, this is still no support channel
<Keybuk> this is also not a channel for harassing developers on
<xyz> you just really suck
<xyz> ppl
<Diziet> Do we have a chop here ?
<marcin_ant> xyz: you can pay me for my time then I'll support you 
<Keybuk> if you have a bug, please file it in bugzilla (http://bugzilla.ubuntu.com/) -- if you have a support question, please ask on #ubuntu or on the ubuntu forums (www.ubuntuforums.org)
<marcin_ant> xyz: and then I won't 'suck' anymore
<ogra> or ask on the ubuntu-users mailing list :)
<xyz> you suck your moma
<Keybuk> 12?
<marcin_ant> or give someone few bucks for support 
<marcin_ant> (it's best option while every linux guru needs money ;) )
<marcin_ant> Keybuk: propably 8 or less
<Diziet> Obviously we don't have a chanop.
* mode/#ubuntu-devel [+o Diziet]  by ChanServ
<marcin_ant> Diziet: so you said that tramp standalone should recommend some packages
<Diziet> Yep.
<Diziet> Right.  Next time I'll act out my anger :-).
<marcin_ant> Diziet: so what about tramp bundled with emacs22 ?
<Diziet> marcin_ant: Nope, no dependencies.
<Diziet> That's because when the user says to install tramp as a standalone package we know they want those features.
* mode/#ubuntu-devel [-o Diziet]  by ChanServ
<Diziet> But when they say to install emacs it's probably just that they wanted to edit stuff.
<zakame> emacs!!!
<Keybuk> I prefer emacs-nox
<Keybuk> I'd install emacs-furling, but nobody's seen it
<zakame> why isn't emacs in the cd by default? :(
<Keybuk> zakame: it's more of a developer's IDE than a simple editor -- and as we don't provide development tools by default, it didn't belong
<Mithrandir> Keybuk: furling?
<ogra> ln -s /usr/bin/gedit /usr/bin/emacs ;)
<Mithrandir> ogra: gedit's mail client sucks
<Keybuk> ogra: tsk, they aren't anywhere near functionally equivalent
<TiMiDo> bla
<zakame> Keybuk: ah
<ogra> Keybuk, gedit is more usable, from a vim users POV ;)
<Keybuk> zakame: we used to ship it on the CD (but not install it by default), but we ran out of room
<zakame> Keybuk: yes, it was in warty and hoary
<ogra> Keybuk, i'm always going mad if i have to use emacs without the keyboard shortcut poster handy :)
<marcin_ant> Keybuk: you should remove some crap from emacs/etc (condom.1 files etc.)
<Keybuk> ogra: my fingers know the shortcuts I use
<marcin_ant> Keybuk: then it could fit ;)
<ogra> Keybuk, mine always use vim shortcuts ;)
<zakame> ogra: try it with dvorak ;)
<Keybuk> marcin_ant: you miss the point ... the problem is that desktop almost doesn't fit on the CD anymore :) 
* Keybuk hugs C-x 4 a
<ogra> zakame, that fixes the shortcuts ? 
<Keybuk> and C-c ^ n, C-c ^ m, C-c ^ o
<Keybuk> I like those ones
<marcin_ant> Keybuk: remove desktop put emacs + ratpoison | ion3 ;) 
<zakame> ogra: somehow :)
<ogra> heh
<Mithrandir> ogra: just use viper-mode, then.
<Keybuk> marcin_ant: and how long have you been off your medication?
<zakame> marcin_ant: I was on that setup, on sid :)
<marcin_ant> Keybuk: ;)
<ogra> Mithrandir, why ? i'm happy with vim and gvim as is :)
<ogra> and its a lot smaller :)
<marcin_ant> Keybuk: whooo C-x 4 a is pretty impressive I didn't know about this shortcut
<Mithrandir> ogra: because emacs21 rocks.
<Keybuk> marcin_ant: yeah, it's dead handy -- though sometimes it mis-guesses what function you're in
<zakame> Mithrandir: w00t!
<marcin_ant> Mithrandir: emacs22 rocks even more
<Keybuk> C-c ^ n/m/o/a are used when in smerge-mode ... they allow you to move between <<<</>>>>> bits and pick which one you want
<zakame> Keybuk: yeah ChangLog mode!
<Keybuk> I haven't used emacs22 yet
* ogra always wondered why the use the size in MB as version numbers
<Keybuk> what's new?
<Diziet> Have they finally arranged it so we can not have `fringes' in X ?
<zakame> Keybuk: gtk2 for one
<marcin_ant> Keybuk: support for gtk2...
<Keybuk> does it have _proper_ GTK+ 2 support?
<Keybuk> or is it still using it's own stupid font renderer?
<Keybuk> I'll switch _IF_ it uses Pango
<marcin_ant> Keybuk: they propably won't use Pango
<zakame> Keybuk: hmmm, haven't noticed, I'm on xfonts-terminus ;)
<Keybuk> I still use emacs in a gnome-terminal, because it just looks so much smoother
<marcin_ant> Keybuk: emacs-gtk is not much different than emacs-x11(athena) I just like these gtk scrollbars
<bob2> mjg59: ps sleep works again now, and is a jillion times quicker than in hoary.
<mjg59> Hurrah
<marcin_ant> btw guys is there any new repository for dapper?
<bob2> as scary as the vertical green lines are during resume
<mjg59> marcin_ant: It'll be in the topic when there is
<Keybuk> next week sometime
<marcin_ant> mjg59: ok - thx
<zakame> ah, good :D
<pitti> mvo: cool, the python devs fixed the tarfile bug I showed you yesterday
<Mithrandir> ogra: *shrug*, you are of course aware that vim is about half the size of emacs21?  And includes way less extra tools, so it would just need those to go into the same size as emacs21.
<mvo> pitti: cool! they are quick
<ogra> Mithrandir, i need an editor, not fully equipped car garage :)
<Mithrandir> ogra: I'm so going to write that mail reader for vim, just to prove its bloat once. :-P
<ogra> lol
<ogra> why should i read mails with an editor ? 
<ogra> there is mutt and there is evo.... both work fine for me...
<zakame> ogra: uhh, planning for one ;)
<ogra> planning ? 
<zakame> ogra: planner-el integrates to gnus and makes blogging and wikis easy :)
<zakame> the downside only is that I haven't finished migrating from my sid to breezy
<zakame> my ~/.emacs, i mean
<ogra> i'm fine with moins web inetrface and since i only blog every 6 months i'm, fine with monkey journal for blogging... no need to clutter my slim editor
<ogra> )
<ogra> :)
<zakame> :) yeah... then again, I haven't blogged and planned myself lately...
<ogra> heh
<dholbach> re
<Keybuk> hmm
<Keybuk> I appear to have just found a box of warty CDs
<Keybuk> anyone want them? :p
<infinity> I have a stack of hoary CDs, I'll trade you.
* mpt has ShipIt warty CDs waiting for him back in NZ
<infinity> I can sign them first, if you'd like.
<Keybuk> heh
<bddebian> Hello
<omar__> I would just like to say great work with Breezy and I am so pleased with this distro, ubuntu all the way.
<bddebian> Even though I have little to do with it, thanks omar__! :-)
<omar__> its ok, I have been using it since 4.10 and it only gets better, fedora, suse, nothing else can compare
<infinity> mvo : <ping>
<mvo> infinity: pong
<infinity> Why does apt-get still not have an option to do something like "apt-get build-dep foo.dsc"?
<infinity> So I don't have to set up a source repo just to use build-dep.
<azeem> same for install
<infinity> install has a workaround.  "dpkg -i foo.deb && apt-get -f install"
<mvo> azeem: install is being worked on
<mvo> infinity: *evil*
<infinity> The only workaround for build-dep is "parse dpkg-checkbuilddeps by hand"
<infinity> Which sucks.
<mvo> infinity: hm, no idea about this "apt-get build-dep foo.dsc". is there already a bug open aobut it?
<infinity> mvo : I recall that mdz asked me, like 3 years ago "what would apt-get need to be able to do to replace build-dep handling in sbuild?"... That was one criteria. :)
<infinity> Not sure if it ever got bugged.
<infinity> Nope, looks like neither he nor I ever actually FILED the bug.  Go us.
<infinity> mvo : Make it happen before UBZ, and I'll bring you some sort of fantastic gift from Australia.
<mvo> infinity: that's tempting ;)
<mdz> infinity: I read that as "I'll bring you some sort of fantastic girl from Australia"
<infinity> mdz : That may be how he read it too, given his enthusiasm.
<ogra> dont let his GF hear that :)
<infinity> AIUI, Germans are a sexually open people...
<ogra> heh
<ogra> thats very age depending i guess 
<bddebian> w00t can someone bring me an Aussie girl too? :-)
<ogra> bddebian, do you come to UBZ ?
<azeem> we won't tell your wife
<dholbach> haha :)
<bddebian> azeem: Exactly :-)
<bddebian> ogra: No. :-(  My kids would never forgive me for skipping Halloween.
<infinity> bddebian : You wouldn't be skipping it, just spending it with scarier monsters than usual.
<ogra> *grin*
<azeem> you could bring them along and let them play with elmo
<bddebian> infinity: Heh
<bddebian> azeem: Oh yea.. :-)
<bddebian> My middle one sleeps with elmo every night ;-P
<infinity> I'm disturbed.
<bddebian> As well you should be :-)
* mvo catches up with the last 5 minutes and keep lauthing
<jbailey> Ugh.  Two hangs in the last 12 hours.  /me wonders what he broke and how.
<trulux> heya
<ogra> is there any command like debconf-get-selections in the default install we ship ?
<ogra> or any other way to get debconf values without installing additional packages ? 
<Kamion> debconf-utils is in ship; you can do it with debconf-communicate if you must ...
<Kamion> it's kinda tempting to promote debconf-utils to standard, since it's tiny and useful
<ogra> soudns like
<ogra> i have a nice patch that sets the X keymap automatically for ltsp clients based on the servers debconf value... but it uses debconf-get-selections for reading
<Kamion> feel free to depend on debconf-utils for that; you should have the dependency anyway
<ogra> Kamion, thanks
<ogra> first i'll have to play with the patch a bit... on my laptop  debconf-get-selections | egrep 'xserver-.+/config/inputdevice/keyboard' gives me xserver-xfree86, xserver-xorg and xserver-xorg-dbg settings ... seems the values stay on upgrades...
<Kamion> ogra: if the package isn't purged or if the upgraded version doesn't db_unregister the old templates, yes
<Kamion> (or if it fails to call db_purge on purge, I suppose)
<ogra> ah, nice... we should make db_purge policy for -dbg packages then i think...
<Kamion> er, dh_installdebconf already does it; practically everything that ships debconf templates uses dh_installdebconf
<infinity> debconf-show is in the base system, but eww.
<Kamion> I bet you just haven't purged the old packages
<infinity> (debconf-show xserver-xorg | grep whatever | sed 'munge')
<Kamion> should depend on debconf for that all the same
<infinity> ltsp surely already depends on debconf for something..
<Kamion> ogra: calling PURGE when your package is purged is already in the debconf specification (referenced from policy) btw
<infinity> Or not.
<ogra> infinity, cool, works and looks much cleaner
<infinity> debconf-couumicate is cleaner still, though.
<infinity> communicate, too.
<Kamion> better to just source the debconf confmodule and use that
<Kamion> debconf-communicate is for fairly special cases - manual use and some really weird stuff
<ogra> Kamion, but i normally dont think about purge if i remove -dbg packages ... and they are seldom permanent on the system, so they should clean up afterwards by default
<infinity> Assuming the postinst is otherwise debconf-clean (ie: no stdout or stderr output)
<Kamion> (when sourcing the debconf confmodule is harmful, basically)
<Kamion> ogra: no, debconf templates shouldn't be purged unless you're purging the package, sorry
<Kamion> if you're messing about with other package's templates then you have to take account of this
<ogra> so db_unregister ?
<Kamion> no
<Kamion> leave it alone :P
<ogra> heh, k
<Kamion> it would be really annoying if debconf templates were unregistered when you just removed a package
<Kamion> because all the questions would be re-asked when you reinstalled
<ogra> i talk about -dbg packages that are only used temporary
<infinity> Same thing.
<infinity> A package is a package, -dbg isn't a special case here.
<infinity> If you don't want it hanging around, purge it.
<ogra> but it leaves unneeded stuff behind
<infinity> Kamion : Erm, debconf-communicate is in debconf now, not debconf-utils
<Kamion> *only if you don't purge it*
<Kamion> infinity: right, but debconf-get-selections isn't
<ogra> yes 
<infinity> Oh, right.  I was getting confused about which was being discussed where. :)
<infinity> debconf-get-selections is vile for this sort of use anyway.
<Kamion> by *definition*, packages leave bits of configuration behind when you remove them but don't purge them
<infinity> No one wants the WHOLE db very often.
<ogra> Kamion, the original patch is from pere, i thought i could trust his debconf skills ...
<infinity> ogra : That's what "remove" and "purge" in dpkg mean.  "remove" is "remove everything but the configuration", "purge" is "remove + take out the configs"
<Kamion> ogra: perhaps he didn't try it with lots of xserver-* installed; I strongly suspect he didn't in fact
<ogra> infinity, imho -dbg packages are a special case because i only use them for debugging
<ogra> Kamion, yes, i think he only has one :)
<Kamion> anyway, the ltsp code should be fixed
<infinity> ogra : I install a lot of stuff only for debugging (or package build-deps), and then remove them later.  But I always purge. :)
<Kamion> or the patch, whatever
<ogra> yes, the patch
<infinity> ogra : Just learn to love the purge, and you'll be fine.
<ogra> the code doesnt have keymap detection yet 
<ogra> i'll try to get used to it :) thanks for all the help
<infinity> When I first started using Debian, I didn't really understand the difference, but got into the habit of always purging for aesthetic reasons.
<infinity> (Underscores are prettier in dselect than dashes)
<ogra> heh
<Kamion> infinity: heh, absolutely
<slomo> hm, does someone know what to do with already fixed CVE in LP? this one was fixed weeks ago: https://launchpad.net/malone/cve/2005-2718
<Kamion> slomo: I don't think the CVE itself ought to get closed; if there was an associated task to fix it in Ubuntu, *that* should get closed
<infinity> A way to add a reference either to the -changes post that fixed it, or the USN that did so would be nice.
<slomo> Kamion: ok... there never was one... but pitti's tool thinks it is still unresolved: http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html
<infinity> slomo : pitti's tool parses changelogs.  If the CVE isn't mentioned in the mplayer changelog, it's considered vulnerable unless he adds a manual override.
<slomo> infinity: ok, i'll tell him... there was no CVE at the time I fixed it ;)
<infinity> slomo : Did you fix it in all releases?
<slomo> infinity: only for breezy... shall i take care of it for warty and hoary?
<infinity> slomo : Yes, if you have an isolated patch for it that you can easily backport.
<slomo> infinity: if it applies cleanly or can be easily backported to the old versions... yes... is pitti the one to talk to when i've fixed packages?
<infinity> slomo : Yes.
<infinity> slomo : I can review the debdiff for you and probably give you an okay to upload if it looks sane, but ultimately he's the one who will need to release the final packages to the archive.
<slomo> infinity: ok, i'll prepare the debdiffs at the weekend... i don't have any time for it before... what would the version numbers be?
<infinity> Erm.  Nothing, it looks like.  <scratch head>
<infinity> Maybe we didn't have mplayer in hoary or warty.
<infinity> I don't see it. :)
<infinity> Oh, nevermind.  Just didn't have the metapackage.
<slomo> we had 1.0-pre5-0.6ubuntu1 in warty and 1.0-pre6-0.3ubuntu6 in hoary
<slomo> ok ;)
<infinity> Okay, so for hoary, we have "1:1.0-pre6-0.3ubuntu6".  Make yours "1:1.0-pre6-0.3ubuntu6.1"
<infinity> And the same .1 on the end of the warty version.
<infinity> And ignore lintian when it tells you that's a binNMU version.  <smirk>
<pef> Kamion: hello, can I bother you a few minutes ? :] 
* mvo goes to play hockey, bbl
<slomo> infinity: ok, thanks :) i'll talk to you or pitti at the weekend
<Kinnison> ciao
<pef> Kamion: can you have a look at malone #2018 ? a debdiff is waiting you ;) thanks !
<ogra> pef, i doubt he will upload motu stuff, you should ask him if the debdiff is ok for -updates 
<ogra> gah... missed that he left
<TMM> lol "topic will be changed when dapper opens"
<TMM> great ;)
<Keybuk> TMM: no ice cream for you
<TMM> awww
<TMM> again?
<TMM> not even one spoon?
<ogra> TMM, not even a glance into the box
<siretart> hrhr
<HiddenWolf> OMFG. :)
<TMM> ogra, wheeeee... what did I do???? 
* TMM cries
<ogra> TMM, moaning about dapper :)
<TMM> ogra, I was complimenting the great channel title
<TMM> ogra, can I have ice now? 
<ogra> no
<ogra> simply because i have none here... its getting autumn in germany... nobody eats icecream
<Kamion> ogra: and it's not ok for -updates, changes random packaging bits totally unnecessarily, like debian/watch
<ogra> Kamion, the package doesnt work at all, these four lines in the code make it work... i admit the menu change and debian/watch wouldnt be necessary
<ogra> i'll tell him to change that back if he comes around again
<ogra> oh, sorry, 6 lines
<Kamion> ogra: yes, I mean the extra changes unrelated to the bug
<Kamion> changes to be considered for -updates should only fix the issue in question, not muck about with other stuff
<ogra> yup
<da_bon_bon> how do i see all the patches and fixes that ubuntu applies to a particular package ? 
<ogra> mdz, we really should remove ltspadmin and friends asap... i had a lot of unnecessary support for people who use it on breezy ltsp already
<ogra> (and break their working install with it)
<mdz> ogra: we shouldn't remove them; using ltsp 4.1 on ubuntu is a valid use case
<da_bon_bon> how about ubuntu using suspend2 instead of swsusp ?
<mdz> I have removed the dependencies in baz
<ogra> mdz, but mixing them breaks totally...
<da_bon_bon> its more configurable, and works.
<ogra> da_bon_bon, we only accept patches that are likely to be accepted upstream
<ogra> swsusp2 isnt among them
<da_bon_bon> ogra: but swsusp is really buggy.
<da_bon_bon> why not move over to a nicer interface ?
<ogra> da_bon_bon, file a bug
<da_bon_bon> :)
<ogra> so it will get better
<da_bon_bon> a bug ? Move to suspend2
<da_bon_bon> it just doesnt work.
<ogra> a bug about swsusp
<ogra> works fine for me ...
<da_bon_bon> for people ho donot use acpi, its bad
<da_bon_bon> wont ever know when to switch off the pc.
<da_bon_bon> and, suspend2 has already been submitted for peer review.
<mdz> da_bon_bon: this has been discussed already; should be in the mailing list archives
<da_bon_bon> mdz: if possible, can you tell me the final views ? i am not subscribed to the devel list.
<mdz> da_bon_bon: you don't need to be subscribed; the list archives are on the web and searchable (the discussion was several weeks ago at least)
<da_bon_bon> uh..
<da_bon_bon> ok
* da_bon_bon looks
<mdz> da_bon_bon: iirc, the issue was that the patch is very invasive and conflicts with others that are more important to us
<da_bon_bon> oh, ok.
<da_bon_bon> maybe i will need  to compile my own kernel on dapper too :)
<mdz> to each his own
<da_bon_bon> yes. but i suppose not many people compile kernels on ubuntu .. it just works :)
<da_bon_bon> anyway, swsusp -- why is the screen blanked /
<da_bon_bon> why not leave the screen on ?
<da_bon_bon> that way, people not using acpi know when to switch of the pc.
<lucas> hi
<lucas> are dist-upgrades from debian sarge to ubuntu breezy working ? supported ? tested ?
<HiddenWolf> lucas, working, might be, supported/tested, hell no.
<lucas> ok
<lucas> thanks
<HiddenWolf> lucas, debian is not ubuntu, and ubuntu isn't debian. :)
<HiddenWolf> lucas, you can try it, but be sure to have plenty of backups.
<lucas> yup, but I thought that would be a bonus of the "we don't want to diverge from debian" part ;)
<lamont> so lets say I'm silly enough to have a laptop that has a sound card that is only supported by OSS, not alsa... how screwed am I?
<ogra> lucas, sarge -< breezy was tested afaik
<lucas> lamont: you are not, I was in the same situation
<ogra> erm s/-</->/
<jbailey> lamont: For dapper, not very.  A few minutes after dapper gets released, probably very.
<lucas> ogra: oh ok
<lamont> jbailey: so what do I need to enable to get oss happy?
<lamont> istr we blacklisted all of oss...
<ogra> lucas, but it needs to be a really clean sarge ... no other repos etc
<jbailey> lamont: Just add the modules to /etc/modules if you want minimal hacking.
<lamont> righto
* lamont decides that maybe the best way is to bring the poor laptop to UBZ with him.
<lucas> I'm interested in MOTU, but I haven't had time to read the whole thread about dapper drake RM
<lucas> was MOTU mentionned ?
<jbailey> lamont: Spend your days writing and alsa driver? =)
<jbailey> lamont: Honestly, since we're doing dmix and all that now, oss-only drivers days are generally numbered.
<jbailey> lamont: It's probably not worth hacking it so that anything supports oss more easily.
<lamont> jbailey: right.
* lamont is at a loss as to where to start with an alsa driver, of course.
<ogra> lucas, if universe was mentioned, it would affect MOTU (without being mentioned)
<ogra> lucas, if youre intersted come to #ubuntu-motu
<dholbach> ogra: he's one of the MOTURuby types, so i guess he knows where to go :))))
<dholbach> YAY Lucas! :)
<ogra> oh, ok
<ogra> didnt know that
* Riddell adds lucas to his kde ruby testing team
<jbailey> lamont: IIRC, http://www.alsa-project.org/ had some porting instructions.
<lucas> Riddell: please don't, I'm a gnome user and use ruby mainly for developping
<jbailey> I looked at it briefly this summer for the Mac G5 sound driver, but someone beat me to it.
<lucas> I don't use many ruby apps except those I develop myself
<lamont> mind you, adding the oss driver does not produce love either
* Kamion looks up collective nouns for ducks
<Kamion> wikipedia lists dopping, plump, paddling, flush, raft, team
<zyga> Kamion: ?
<Kamion> zyga: beta CD release names
<Kamion> I think I like raft best out of those
<zyga> Kamion: :-[)}
<zyga> beta cd of what?
<Kamion> dapper
<Kamion> y'know, sounder of warthogs, array of hedgehogs, colony of badgers, ...
<jdub> raft! :)
<zyga> flock of doppings?
<zyga> flocky dopping
<zyga> eh ;] 
<jdub> Kamion: yeha, i like raft - are there no specific ones for draks?
<zyga> Kamion: why ducks in particular?
<Kamion> dopping is a bit obscure I think - it refers to ducks while diving apparently
<jdub> zyga: a drake is a kind of duck
<zyga> jdub: ah
<zyga> the new words I learn with ubuntu releases :-)
<Kamion> it's just a male duck AFAIK
<Kamion> wikipedia agrees
<jdub> yeah, it is
<zyga> nifty nipper
<zyga> sounds cool
<lamont> Kamion: "male" is a kind of duck. :-)
<zyga> and nipper is an animal too
<lamont> Kamion: raft seems to be the winner
<Kamion> jdub: haven't found anything specific for drakes, no; you don't often find collective nouns for gender-specific words
<jdub> Kamion: there's always the drake-as-dragon option
<jdub> but seems we're definitely ducky
<zyga> jdub: mandivia has drakes
<jbailey> LotR characters? =)
<Kamion> raft is apparently "while idle in water"
<jdub> Kamion: hrm, idle isn't a great message (not that too many people will research this and analyse it)
<Kamion> jdub: dragons would give us flight, weyr, wing
<Kamion> which are admittedly cool, but as you say I thought it was meant to be a duck
<jdub> sabdfl has said as much
<lamont> flush 1 just sounds, um...., yeah.
<jdub> heh
<jdub> nice way to release ;)
<jbailey> Kamion: Could be the sounds that ducks make in different languages.
<jbailey> Wow, the f and d are *way* too close together.
<bddebian> coin
<bddebian> quack
<Kamion> wow, http://www.nzbirds.com/more/nounsd.html has billions of duck nouns
<lamont> what does 'team' refer to?
<Kamion> badelynge
<Kamion> lamont: "in flight" per http://www.vigay.com/nouns/birds.html
<Kamion> "Team CD 1" just seems a bit anonymous
<Kamion> "a flight of ducks" seems possible
<zyga> Kamion: how about a word that ordinary non native speaker will understand?
<lamont> Bed 1?
<lamont> zyga: that'd be cheating
<Kamion> or just "flock", but I don't want to use that before I have to
<jbailey> lamont: That's certainly not for the "duck" release. =)
<Kamion> zyga: we haven't done that so far
<lamont> little knob 1?
<jdub> zyga: most native english speakers don't understand these words
<Kamion> I see no reason to start now - it's pretty much impossible to do plays on words in a way that everyone will understand
<Kamion> and yet plays on words are fun
<zyga> lamont, Kamion: how about putting some furigana
<lamont> ooohhh!  Kamion limiting yourself to 7-bit ascii is just so, um, limiting.
<lamont> skein 1 makes me think of yarns
<lamont> Kamion: you could always go with 'goose N'. :-)
<lamont> flight is certainly better than flock.
<zyga> lamont: hairy herd
<lamont> I know after hunting for a day, "handful" is a collective noun for ducks.
<jdub> ew
<lamont> jdub: not 'ew'.  'yum.'
<lamont> then again, those ducks aren't very dapper.
<whiprush> Kamion: it's a Paddle of Ducks.
<whiprush> I looked it up a few days ago
<HiddenWolf> Oh My
<HiddenWolf> We're going to have Ubuntu Paddle releases
* HiddenWolf rofl
<HiddenWolf>  /. headline: Ubuntu likes to be paddled
* mpt votes for Exaltation
<mpt> oh, damn, that's doves
<mpt> http://everything2.com/?node=badelynge
<ajmitch> morning
<Nafallo> sounder, array, colony, paddle :-)
<Nafallo> sounds nice :-)
<HiddenWolf> Nafallo, lol
#ubuntu-devel 2005-10-26
<dholbach> good night guys
<doko> ogra: building LTSP chroot: the progress bar jumps to 50% and stays there ...
<Robi-> does anyone run soft-raid?
<robertj> theoretically to get rid of grub, one could just copy over a stock mbr and munge the partition table so that the windows partition containing that file was active, right?
<zul> thats weird none of the irc logs are being displayed with firefox
<mdz> zul: the server which runs people.ubuntu.com has shat itself
<mdz> assuming you're talking about those irc logs
<zul> yeah i am
<zul> damn it..
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | topic will be changed when Dapper opens | people.ubuntu.com is temporarily m
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000038.html | topic will be changed when Dapper opens | people.ubuntu.com is misbehaving
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | topic will be changed when Dapper opens | people.ubuntu.com is misbehaving
<fabbione> morning
<bytee_> good morning, fabbione 
<pitti> Good mor*yawn*ing
<tritium> fabbione, is your irc logger working properly?  I was trying to find the motu meeting from the 18th, but -meeting and -motu logs from that date are empty
<ajmitch> tritium: probably because of the last item in /topic
<tritium> ajmitch, didn't see that.  Thakns.
<tritium> thanks even
<fabbione> tritium: mostlikely
<fabbione> i am pretty sure that -current are all borked
<tritium> fabbione, okay, thanks.  Sorry, didn't see the topic
<fabbione> i think that daily are ok
<fabbione> but i will need to check
<tritium> okay, thanks again
<poningru> whats the eta on NM becoming default?
<poningru> is it on Dapper or 6.04+1?
<poningru> Network manager btw
<pitti> is it just me, or do other people also have troubles with reading from people.u.c.?
<pitti> I tried it from two completely different servers
<ajmitch> pitti: see topic :)
<ajmitch> apparantly the server has 'issues' :)
<pitti> oops, sorry
<pitti> I tend to ignore the topic since it is 6 lines long
* ajmitch couldn't ignore it when it was changed 3 or 4 times in a row 
<mdz> it overflowed and required additional editing
<ajmitch> yes, I saw :)
<ajmitch> a common problem 
<infinity> Do we really need pointers to DeveloperResources and HelpingWithBugs in the topic, when both of those shold be in the topic of #ubuntu-motd, which we already point people to? :)
<infinity> s/motd/motu/
<infinity> Also, when I see jdub, I'm going to strangle him for cursing me.
<infinity> My laptop had been up for days when he showed up last night complaining about recent hardlocks, and blaming the ipw2200 driver...
<infinity> Sure enough, I wake up this morning, and my laptop is locked hard with the wireless light solid.
* infinity shakes fist.
<Seveas> hehe
<Seveas> jdubs laptop misbehaved during his presentation a few days ago
<Seveas> beagle fubared his user_xattr so /home got mounted read only
<infinity> Beagle?  FUBAR?  What are the odds?
<Lathiat> heh
<Lathiat> infinity: hahaha
<Lathiat> i have a laptop using ipw2200 on like, 24/7
<infinity> It still boggles my mind that people think it's both stable enough and generally useful enough to have it in the default session.
<Lathiat> and it never skips a beat
<infinity> Lathiat : Yes, I could say the same thing until this morning.  Just wait, your time will come.
<Lathiat> infinity: heh
<Lathiat> well its been on 80% of the last year
<Lathiat> poor laptop
<Lathiat> its probably not supposed to be on that much :)
<infinity> <shrug>... Mine is.
<infinity> I just have to remember to be nice to the battery.
<infinity> But my laptop is my only computer with a monitor, so I don't have much choice.  It gets used a lot.
<Lathiat> heh
<Lathiat> the same
<Lathiat> cept i have 2
<infinity> Well, okay, I have two computers with monitors, the other one being my OLD laptop that this one replaced.
<Lathiat> but between the both of them i use them all the time
<Lathiat> only other machine is just a server box with no monitor
<infinity> And when I say OLD, I mean OLD.  I'm pretty sure people were laughing at me behing my back at UDU as I walked around with it.
<Lathiat> haha
<Lathiat> at lca2004
<Lathiat> i had a p133 toshiba
<ajmitch> infinity: surely not
<Lathiat> altho i managed to steal a 1ghz machine towards the end of the week
<ajmitch> I thought mine was bad enough, and it was just a p2
<Lathiat> that toshiba was quite nice tho
<Lathiat> it wasnt overly chunky
<Lathiat> 160CDT or something
<Lathiat> 14" i think
<Lathiat> run xfce4 quite nice
<infinity> Oh well, nothing beats dilinger's keyboard.
<Lathiat> dilingers keyboard?
<infinity> I was complaning because I was missing one key, then he showed me his.
<infinity> I'll have to find a picure for you to really understand, but his laptop is missing, like, 10 keycaps.  Maybe more.
<Lathiat> haha
<Lathiat> nice
<jdub> infinity: i have cursed you?
<ajmitch> I saw a photo on tseng's site, if he still has them up
<infinity> jdub : Yes.  Jerk.
<Lathiat> jdub: yes! you evil man!
<infinity> jdub : My laptop was locked solid this morning, with the wireless light solid green.  And it's ALL YOUR FAULT.
<jdub> heh
<jdub> fix it!
<fabbione> infinity, jdub: buy better hw
<fabbione> why my machines never lock solid? because i use sane hw
<infinity> Mine's sane.  The kernel just needs to catch up.
<fabbione> infinity: no no no.. the kernel is sane :)
<fabbione> your hw sucks
<infinity> I out-blinged the speed of kernel and X devel.
* jdub watches fabbione paint utopia with dog poo
* fabbione can't picture jdub's crack
<jdub> fabbione: i'm shipping off to italy today :-)
<doko> good morning
<fabbione> jdub: yeah but you are going to milan.. that's not really italy.. it's padania :P
* infinity heads out to the store to get brainfood.
<fabbione> jdub: well they will explain that to you ;)
<jdub> :-)
<pitti> Hi JaneW
<pitti> ouch, even ssh onto rookery fails
<jdub> "Hi, my Italian friend who no longer lives in Italy says that you are not real Italians."
<JaneW> hi pitti
<jdub> oh man, someone put the ubuntu poster on flickr
<jdub> so if i sync the fridge's feed, there will be boobies on the shuffle
<pitti> jdub: oh, there is an Ubuntu poster`
<Lathiat> hahaha
<pitti> jdub: some guys from the "Linux Info Tag Dresden" asked me for one
<jdub> pitti: the one with the big boobies, "because naked people are totally appropriate for business dektops" or whatever
* pitti reconsiders giving out this one
<highvoltage> what codec do i need to play shuttleworth_zimmerman_band.avi?
<highvoltage> ah, gxine plays it :)
* netjoined: irc.freenode.net -> brown.freenode.net
<pef> hello
<pef> ogra: Hello Olivier, I've made the changes needed to my kcheckgmail debdiff (malone #2018)
* bubulle waves hi to fellow Ubuntu devel people....
<Treenaks> hi bubulle 
<bubulle> very short concern: I try syncing with mvo's repository for APT and I currently can't
<bubulle> cannot connect to archive (michael.vogt@ubuntu.com--2005)
<ajmitch> people.ubuntu.com is down, see topic
<pitti> bubulle: people.u.c. is screwed ATM
<bubulle> ah, thanks
<Treenaks> pitti: fixably so?
* bubulle slams self for not readin topic
* ..[topic/#ubuntu-devel:daniels] : yes, people.u.c is down | Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | topic will be changed when Dapper opens
<pitti> Treenaks: let's hope so
<bubulle> and /me waves bye..:)
<daniels> http://www.p0z3r.org/images/kde_hackers.png
<daniels> i wonder if that password still works
<Treenaks> daniels: all of them?
<daniels> Treenaks: hm?
<daniels> \sh_away: my god man, what the hell sort of blog software are you running?
<Treenaks> daniels: kde_hackers.png.. I see 7 people..
<daniels> Treenaks: note the whiteboard in the background
<Treenaks> daniels: yeah, saw that :)
<Treenaks> daniels: \sh blames planet for being broken
<infinity> For the curious, not the password no longer works. :)
<Burgundavia> daniels, it happens about once a week it seems
<mdke> it's a pain
<Burgundavia> infinity, at OSCON 2004, orielly gave everybody full access to safari but forgot to turn it off for 6 months
* ..[topic/#ubuntu-devel:fabbione] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | topic will be changed when Dapper opens
<fabbione> people is back
<Treenaks> \o/
<ogra> bah, but i still get no support for dapper :)
<Kamion> whiprush: I don't think you can say "it's a <foo> of ducks" given that I had just turned up earlier with half a dozen possible alternative collective nouns for ducks and was trying to pick the best one. :)
<Kamion> paddling is one of the alternatives, but imho not the best one
<Treenaks> gaggle!
<Treenaks> or waddling
<ogra> mob, troop, shoal, drove, swarm ?
<Treenaks> ogra: a drove of dapper drakes?
<ogra> why not ?
<Kamion> it's a gaggle of geese normally, not ducks
<Treenaks> Kamion: it's both, according to quite a few places
<Treenaks> ogra: (troop? not troup? :P)
<ogra> hehe
<ogra> would quiver fit ? 
<HiddenWolf> \sh_away, is your blog messed up? It's re-posting everything you posted the last week(s) to planet
<seb128> Kamion: does useradd behaves the same way as adduser?
<ogra> seb128, i think one of them creates a homedir by default iirc (dont ask which though)
<Kamion> seb128: useradd's a low-level tool and is not obliged to
<tsume> mm, one question. packages are based on stability and changed towards stability, yes?
<Kamion> Treenaks: I think geese is the association most native speakers have for "gaggle", but shrug
<tsume> once released that is. What if there is a bugfix update for a package?
<tsume> would it be able to get pushed out in a tree, or would it only be maintained for current bugs in the release of the software?
<seb128> Kamion: users-admin users useradd, should it use adduser rather?
<Kamion> oh, yeah, I'd've thought so, if it can ... adduser has better default policy, and uses useradd under the hood anyway
<Kamion> and it automatically creates groups for you and stuff
<infinity> Does useradd support different backends, or is it just one of the supported adduser backends?
<Kamion> the arguments it takes are quite different though
<infinity> The nice thing (in theory) with adduser is that it doesn't have to be dealing with /etc/passwd at all.
<Kamion> infinity: adduser always uses useradd
<Kamion> wouldn't you do different backends with PAM?
<Kamion> dunno, I haven't looked at the useradd code
<infinity> Oh, I suppose you would these days.
<infinity> I must be living in 1995.
<infinity> Anyhow, the arguments aren't so drastically different that one couldn't patch an application to use one instead of the other with minimal effort.
<infinity> They're just incomaptible as drop-in replacements.
<Kamion> yeah
<Kamion> infinity: it's more that the default behaviour's different, so it needs testing
<Kamion> I wouldn't quit or anything if we flipped the adduser/homedir-permission default :-) I just think many of the arguments being advanced are bogus and paranoid and miss the UI point ...
<infinity> I'd walk. ;)
<infinity> (Well, I'd just dpkg-reconfigure adduser and go about my day, but still..)
<infinity> My guess is that 99% of the people who argue that 700 or 711 is a better default than 755 have never actually worked on large multi-user systems.
<infinity> It becomes very obvious, very quickly, that convenience is more important than paranoid security in most setups.
<infinity> (Odds are that most of them are home users, bent on shoving their paranoid permission scheme down the throats of others who actually DO use large multi-user systems and tihnk the current default is fine)
<infinity> But, that's just a guess. :)
<Kamion> yeah, that's been my experience on large multi-user systems too
<Kamion> but what do I know, I've only tried it
<infinity> <cough>
<infinity> To be fair, I also run one system where the users aren't all buddy-buddy and I did reconfigure adduser to use 711.  But is that really so hard to do, if you feel the need?
<infinity> That's one system out of many, so I know which default makes more sense for me.
<zyga> can anyone tell me the rough estimate for the number of files in a full mirror of ubuntu?
<Yagisan> My take on it (as a "security guy" ) is that the tools should be consistent in setting permissions, and info on how to reconfigure
<Yagisan> them should be stuck in a securing ubuntu manual
<Znarl> zyga : Archive or releases mirror?
<zyga> Znarl: archive
<Znarl> 163903 files and directories.
<zyga> thanks
<zyga> Znarl: could you also tell me the total size?
<Znarl> 79G presently
<zyga> cool, thanks alot
<Keybuk> Znarl: gah, you beat me
<Keybuk> 79G     /srv/archive.ubuntu.com/ubuntu
<Keybuk> :p
<Znarl> Sorry
<zyga> does the installer ask the user if s?he would like to participate in the popularity contest?
<HiddenWolf> zyga, no
<jdub> http://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000043.html
<jdub> UBUNTU LOVE DAY!
<ajmitch> hi jdub 
<ajmitch> mm, nice
<fabbione> jdub: the wiki page is empty?
<fabbione> and 2 emails to announce :) cool
<fabbione> at least i got 2
* Keybuk gives jdub some hot Ubuntu loving
<highvoltage> that's scary.
<infinity> Yagisan : Yeah, no one's arguing that the tools should lack consistency.  gnome-system-tools should obviously be using adduser.
<infinity> Yagisan : We're all just arguing about defaults. :)
<slomo> pitti: i have two debdiffs for warty and hoary to fix CVE-2005-2718
<slomo> pitti: http://slomosnail.de/~slomo/mplayer_1.0-pre5-0.6ubuntu1.1.debdiff and http://slomosnail.de/~slomo/mplayer_1.0-pre6-0.3ubuntu6.1.debdiff
<slomo> pitti: it's the same patch we already have for breezy... applies cleanly on the older versions
<pitti> slomo: yes, sounds fine; thanks
<slomo> pitti: and your tool reports it is still unfixed for breezy... i uploaded a fix for it ages ago but didn't mention the CVE in the changelog
<pitti> slomo: I can mark it manually
<slomo> thanks :)
<pitti> slomo: so mplayer breezy is not vuln to CVE-2005-2718?
<slomo> pitti: yes... it has exactly the same patch
<ajmitch> pitti: there's yet another phpmyadmin hole, not sure if you saw it
<pitti> ajmitch: I saw it, but universe :-/
<ajmitch> yeah
<ajmitch> want me to put a debdiff together?
<infinity> ajmitch : And update prepared would be nice.
<ajmitch> ok
<Kamion> at this rate cdimage is going to gain the ability to read mail
<infinity> ajmitch : phpmyadmin is reasonably popular.
<Kamion> I just added a counting semaphore implementation to it ...
<ajmitch> certainly
<infinity> Kamion : It can't already?
<pitti> ajmitch: sure, and send it to security-review
<ajmitch> pitti: will do
<infinity> Kamion : Dude, even buildd can read mail.  You're so behind.
<Kamion> infinity: not in any code I've written. It's possible it's started to write code for itself.
<Kamion> sorry, I should've said. A counting semaphore implementation IN SHELL.
<Kamion> it's possible shell has stopped being the best language for cdimage, but ...
<Diziet> Woah.
<hunger> Kamion: When I was in uni I was told that GNU products were only complete if they were able to read mail and news...
<pitti> hmm, why do we enable DMA on CD-ROMs by default now?
<pitti> this hasn't been the case in hoary
<pitti> and it breaks on so many machines out there (and I get all the hal bugs)
<ajmitch> great, phpmyadmin fix is only 3 lines
<Treenaks> pitti: I thought we didn't, but HiddenWolf's machine disagrees
<Treenaks> pitti: so maybe the disabling is not working for some hardware?
<pitti> Treenaks: I thought that, too, and I always replied with "then don't enable DMA, dude"
<pitti> but I just noticed that DMA is active for my drive, too
<HiddenWolf> Treenaks, /dev/hda is my windows drive, which is not in fstab
<pitti> seems to WFM, but it is wrong
<HiddenWolf> Treenaks, dma is on for cd-roms too tho.
<pitti> yes, for hard disks its fine
<Treenaks> HiddenWolf: on hard disks DMA gets enabled
<pitti> Hi carstenh 
<carstenh> hi pitti :)
<Treenaks> pitti: we will need to figure out a way to determine if the CD-ROM/Controller combination is "DMA-OK"
<Treenaks> pitti: because no-dma sucks hard
<HiddenWolf> Treenaks, no, it's off for both my cdrom drives, in fact.
<bob2> lincvs is fux0red in breezy, if anyone cares
<pitti> Treenaks: DMA sucks even harder on many hardware
<Treenaks> pitti: So we need a black/whitelist
<Treenaks> pitti: because on _most
<Treenaks> _ systems it seems to work fine
<Treenaks> (most systems I've seen)
<Yagisan> infinity: you are a desktop distro, targeted at single users. 755 works for them. People (like me) that do run
<Yagisan> multi-user systems will run dpkg-reconfigure adduser (but that should be in a manual for new sysadmins)
<Kamion> mdz: FYI I've implemented parallel CD builds now at least for different projects (so we can run Ubuntu, Kubuntu, and Edubuntu builds at the same time, though not parallel install/live builds for the same project)
<Kamion> Yagisan: s/will/may/
<Yagisan> Kamion: yeah - it depends on the system, I know.
<infinity> Kamion : How much of a win is that?  Won't you just be hampered by disk speed anyway?
<crimsun> infinity: is this applicable for your ipw2200 freeze? It's a simple diff. jdub might want to take a look too if it's relevant. http://bughost.org/bugzilla/show_bug.cgi?id=740
<crimsun> (patch being http://bughost.org/bugzilla/attachment.cgi?id=479)
<mvo> hey doko! are you at berlinux?
<infinity> crimsun : Dude, I've only hung once.  It's a bit hard to debug that sort of (in)frequency.
<Kamion> infinity: there's a fair amount of waiting around for jigdo-file in there
<Kamion> which is mostly md5summing the world
<Kamion> I think there's enough of a mix between CPU-intensive work and I/O-intensive work that they should parallelise somewhat, but we'll see
* infinity wishes we could come up with some clever jigdo-live extension...
<infinity> I mean, I could write one that basically had livefs.sh embedded in it, but I'm not sure we want to let that hideous code see the light of peer review^W^Wday.
<doko> mvo: yes
<lucas> hi
<mdke> jdub, i'm still not on planet afaics :/
* fabbione heads offline
<fabbione> later fellas
<pitti> cu fabbione 
<vuntz_> hey lucas :-)
<lucas> hi vuntz 
<pitti> Kamion: does the installer put USB CD-ROM entries into fstab under some circumstances?
<zyga> pitti: hi
<pitti> Hi zyga
<zyga> pitti: about the installer, I hate bug reports and all but I've ran across a strange behaviour
<zyga> pitti: I had 1 ata and 2 sata disks, with sata disks the installer borked and died saying it cannot resize ext2 filesystems (even though I didn't even ask it to mount either of the sata disks) on the first sata disk it found
<pitti> zyga: bugzilla is exactly the right place for this report :-/
<Kamion> pitti: if mounted, if you're booting from them ... would have to dig into partman to say any more
<Kamion> mounted> as in explicitly in the partman UI
<pitti> Kamion: ok, thanks
<pitti> Kamion: I'm asking because of #6106
<pitti> anyone with an USB cdrom drive?
<Lathiat> pitti: yeh
<Lathiat> pitti: need somethign tested?
<mvo> pitti: not here, but I had one last weekend and it worked fine with breezy
<pitti> Lathiat: if you plug it in, do you get /dev/sr0, /dev/scd0, or both?
<Lathiat> both if i recall
<Lathiat> but i'll try
<pitti> Lathiat, mvo: maybe you can say something to #6106
<Kamion> pitti: oh, no, I think it always puts removable media into fstab
<Kamion> partman-target/finish.d/fstab_removable_media_entries
<pitti> ah, bad
<pitti> interesting, I never installed Ubuntu with my USB stick attached
<Kamion> we can probably just turn that off in dapper and see what happens, although new installs will no longer be able to use the traditional 'sudo mount /cdrom'
<pitti> Kamion: well, "removable" media in fstab are fine, just not "hotpluggable" ones
<pitti> Kamion: i. e. entries for an ATAPI card reader are fine, but it will break for an USB CD-ROM or USB stick
<Kamion> uh
<Kamion> I don't think partman knows the distinction
<pitti> (card reader, ATA CD-ROM: removable; USB stick: hotpluggable)
<Kamion> would take some hw-detect hacking to arrange tht
<Kamion> that
<pitti> Kamion: can we teach it to not add USB and Firewire devices?
<Kamion> like the existing hw-detect hacking that tells netcfg about hotpluggable network cards
<Kamion> I don't want to hardcode device types if I can avoid it; a hw-detect trick that remembers when disk devices have been hotplugged would be better if possible
<Lathiat> at one point the installer was putting /dev/sda instead of /dev/sda1 for removable usb drives in /etc/fstab
<Lathiat> dunno if that was fixed
<Kamion> but yeah, I could just delete the USB storage bit; I don't think it ever adds Firewire devices
<Lathiat> i think it adds firewire too
<Lathiat> i can test if you like
<pitti> seb128: thanks for adding the watch to malone #3418 - I guess I still need to get used to work with Malone
<Lathiat> ive got a dual firewire/usb enclosure
<Kamion> Lathiat: #10900
<Kamion> Lathiat: I've got the relevant code open in front of me and I can't see anything that adds Firewire
<Lathiat> interesting
<Lathiat> i reported that ages ago
<Kamion> it iterates through /proc/scsi/usb-storage-* /proc/scsi/usb-storage
<Lathiat> Kamion: ok it might not then
<Kamion> Lathiat: yeah, and see my explanation at the end of why the trivial fix wouldn't work and it needs something more complicated
<Lathiat> ah yeh my comment is in the bug haha
<Lathiat> Kamion: i take it from the bug you dont need an example now
<Lathiat> hm i need to hunt for a usb cable
<pitti> Keybuk: do you want to merge udev, or shall I?
<Kamion> I still haven't found my USB sticks though :(
<Keybuk> pitti: I will, it's not a simple matter of just taking the Debian version
<Keybuk> I have some pre-prepared packages here
<pitti> Keybuk: okay, great; I'm just eager to try it to play with libgphoto
<Keybuk> we need to figure out what to do with those
<pitti> Keybuk: I currently stack my uploads in chinstrap:~pitti/uploads until dapper opens :-)
<Keybuk> the "new udev" doesn't give us a move away from /proc/bus/usb, we need the new kernel for that too
<pitti> ah, right
<Keybuk> as the kernel needs to drop usbfs
<pitti> Keybuk: since the new hal's udev rule approach (instead of hotplug.d) works fine here, would the "new" way already work with our udev (0.063)?
<Keybuk> yes
<pitti> ah, cool
<pitti> so we need the kernel's "sysfs devices" patch
<Kamion> Lathiat: no, I don't, thanks
<Lathiat> pitti: 
<Lathiat> [4299920.567000]  sr1: scsi3-mmc drive: 2x/48x writer cd/rw xa/form2 cdda tray
<Lathiat> i get scd0 too
<Lathiat> and a sr1
<Keybuk> I'm still trying to understand how the kernel guys use git
<Lathiat> and my internal (sata) cdrom
<pitti> Lathiat: ok, thanks
<Lathiat> is sr0 and scd0 too
<pitti> Lathiat: the guy in #6106 apparently does not have scdN
<Keybuk> it seems that gregkh actually puts patches in git, rather than has separate branches
<Lathiat> anyone else want any debugging
<Lathiat> usb/firewire drive during install?
<pitti> Lathiat: not from my side; thanks!
<Keybuk> pitti: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fbf82fd2e1f4e679c60516d772d1862c941ca845
<Keybuk> is the patch we want
<Keybuk> I'm trying to work out when that's due/or got folded into a release
<pitti> Keybuk: ah, cool, so it already cares for the major/minor (in the "dev" attribute)
<Keybuk> yeah
<Keybuk> that's the nice thing about all the "proper" device stuff now
<Keybuk> the kernel can assign random numbers to them, it doesn't matter
<pitti> and it doesn't even look particularly scary
<Keybuk> aye, and totally replaces usbfs
<Keybuk> we just need to change /proc/bus/usb to /dev/bus/usb (or wherever we put them)
<pitti> Keybuk: the patch is small enough to be included even in our current kernel (AFAICS), if it doesn't get upstream any soon
<Keybuk> assuming that linus's linux-2.6.git tree is what gets released, it's in the current 2.6.14-rc series
<tepsipakki> is there a mechanism for you to force mirror-admins to update their mirrors? for instance fi.archive.ubuntu.com is currently broken on ppc
<Kamion> depends on the mirror
<tepsipakki> a friend of mine complained about it
<Kamion> fi == heanet
<Kamion> Znarl: ^--
<tepsipakki> yes
<Kamion> I thought we'd taken heanet out of rotation for (?)nl
<tepsipakki> kamion: the installer defaults to it (in Finland) so it is quite critical in that sense =)
<Kamion> tepsipakki: yes I know :P
<Kamion> tepsipakki: Znarl runs the mirror network, which is why I drew his attention above; explaining to me how critical it is won't help ;)
<tepsipakki> ok
<tepsipakki> just wanted to inform you
<Kamion> yeah, thanks, as you can see I've passed it on
<tepsipakki> yes, thanks ;)
<Znarl> Kamion : Ok, I'll chase heanet.
<Kamion> ta
<Kamion> jesus, you post to ubuntu-devel and get a huge load of replies in your private inbox
<Kamion> mailers so badly need to respect m-f-t
<Treenaks> set a bounty :)
<infinity> I'd be very happy if Tbird respected M-F-T.
<Kamion> my concern about it is slightly less than my desire to own a house
<infinity> But M-F-T is something only nerds think the world should respect, and the reality is that pretty much no "friendly" MUAs even look at it.
<lucas> how do I send a mail to all members of a launchpad team ?
<infinity> It actually irritates me a little bit every time I see a user get smacked down by someone with "jesus, can't you read M-F-T?!"... Seriously, how many "average users" read the full headers on all their mail?
<Kamion> infinity: that's only because nerds get far more mail than everyone else
<infinity> Kamion : Yes, and nerds should implement M-F-T in all the common mailers if they care, then.
<infinity> Kamion : Or, at least, all the ones we have the power to change.
<infinity> Get it into Evo and TBird, and I'll bet gmail will fix their webmailer for you.  That should kill 99% of Ubuntu list mailers.
<Kamion> I was under the impression evolution already had reply-to-list
<infinity> Does it use M-F-T, or list headers, or use an educated guess?
<Kamion> no idea
<infinity> I tend to just use reply-to-all in tbird, then remove the poster's email address iff I recall them being subscribed.
<infinity> (So, I remove developers, but will reply-to-all with most users I don't recognise)
<infinity> Nothing more irritating than replying-to-list with a user who comes back a week later asking the same question, cause they didn't actually think to check the list for replies.
<doko> photos from berlinux.de - http://people.ubuntu.com/~doko/berlinux/
<azeem> doko: nice thumbnails :P
<ogra> hehe
<tepsipakki> hmm, shouldn't the live/install-dvd load all the language-packs for the chosen language? I chose "finnish" but it didn't load them, locale was correct though
<azeem> doko: who are the guys in 42 and 46?
<doko> ogra: edubuntu even works ;-P
<ogra> tepsipakki, it does load them at the end of the install... if you put in the dvd after reboot at any time it will pull them from there ... (some space for improvement)
<ogra> doko, yes, but its easier to install if you read the fine manual :P
<ogra> *g*
<doko> azeem: herzi and a nice guy from openoffice
<azeem> ah, looked a bit like herzi
<ogra> i like DSCN9044 :) a lot of edubuntu there :)
<tepsipakki> ogra: oh, this is the live-session I'm talking about..
<ogra> tepsipakki, oh, ok...
<Znarl> tepsipakki : Can you help me?
<Znarl> tepsipakki : Do you have any more details about brokenness with heanet so I can bully the admin?
<tepsipakki> znarl: for instance mozilla-firefox-locale-fi-fi_1.0.4lang20050515-1ubuntu3_all.deb complains about size mismatch
<Znarl> OK, thanks.
<tepsipakki> or, actually dpkg/apt is the one complaining, but anyway
<dilinger> infinity: my keyboard will be making an appearance at UBZ
<ogra> dilinger, you have still the same one you had at UDU ?
<tepsipakki> ogra: is there a component I can file a bug on?
<ogra> casper probably ...
<Kamion> tepsipakki: we don't have a separate live fs build for the DVD yet; it's a fairly well-known problem
<Kamion> it's not a casper bug
<Kamion> tepsipakki: #17548
<tepsipakki> kamion: ok, good to know
<Lathiat> can someone dpkg -S gnome-settings-daemon for me
<tseng> gnome-control-center
<Lathiat> thanks
<Lathiat> eh that pulls in lots of shit
<Lathiat> i just want my themes to work damnit :(
<seb128> pitti: np for the watch :)
<seb128> Lathiat: what is the issue?
<Lathiat> seb128: using kde
<seb128> bah
<seb128> you can stop here :p
<Lathiat> its not my fault gnome doesnt have enough bling
<Amaranth> naughty
<Lathiat> so kubuntu whisked me away
<seb128> I like my desktop beeing clean and not a jukebox :)
<Amaranth> clean is nice
<Lathiat> i feel dirty but its kinda like a good dirty
<Lathiat> ;p
<Lathiat> YAY clearlooks
<Lathiat> also can we enable animation in clearlooks for dapper :(
<Lathiat> it entirely depresses me not havign animated progress bars
<Lathiat> i mean, kde has them
<Amaranth> Lathiat: they spin backwards, it makes you think the progress bar is counting down
<Lathiat> it doesnt actually
<Amaranth> and it needs to be a gtk thing so apps can choose whether or not they want to use them
<Lathiat> its a result of it aligning itself to the right of the progressbar
<Lathiat> or just a visual screw up or something
<Lathiat> at least i think
<seb128> some people bugged the other way
<Lathiat> what it looks like
<Amaranth> they spin backwards
<seb128> than animation are annoying
<Amaranth> remenic said so
<Lathiat> seb128: whats the bug number? i'll flame them to death :)
<Lathiat> PLZ TO TURN BACK ON OR I WILL KEEP USING KDE. KTHXBAI.
<seb128> sure, that's the way to fix an issue
<Lathiat> seb128: obviously
<seb128> happy KDE using
<Lathiat> thanks. :)
<Amaranth> Lathiat: build your own gnome-themes package
<Lathiat> i did ;p
<seb128> no need of that to install a theme
<seb128> you can do to your user folder
<Lathiat> yeh but that was easier
<Amaranth> you need to change a gtkrc file or something too to enable the animation
<Lathiat> you do?
<Lathiat> i just compiled it and it worked
<Amaranth> oh :P
<Amaranth> i could have sworn he was going to make it configurable from gtkrc
<Lathiat> i wish it was
<Lathiat> :)
<seb128> "was going"
<seb128> not made yet
<seb128> pitti: you use an amd64 install on your day to day work box?
<seb128> mvo: you too?
<mvo> seb128: yes
<mvo> it's my main development box
<mvo> (because it's fast!)
<seb128> mvo: does "gthumb /" crash?
<mvo> seb128: yes
<seb128> k
<seb128> amd64 specific issue
<seb128> let's put dholbach on it :)
<seb128> thanks
<dereks__> mvo: you are using amd64?
<dereks__> smp or 1 cpu?
<mvo> 1cpu
<dereks__> ahh, nm then
<mvo> nm?
<dereks__> never mind
<dereks__> i was going to ask you if you had trouble wiht an smp setup
<dereks__> i couldn't get the smp kernel to load
<mvo> seb128: crash happens in resolve_all_symlinks
<dereks__> so i am using 686 smp instead :(
<mvo> do you want me to have a look?
<mvo> derek__: you may try #ubuntu-kernel
<seb128> mvo: http://bugzilla.ubuntu.com/show_bug.cgi?id=6523 if you have a good bt
<dereks__> mvo: didn't know about that one :)
<seb128> mvo: we lag 2 upstream versions behind, dholbach packaged the new one, I would let him give it a try before bothering
<Amaranth> does xgettext no longer exist in breezy or something?
<mvo> seb128: do you know if his package is available somewhere? 
<seb128> gettext: /usr/bin/xgettext
<seb128> mvo: on his disk I guess :) Don't worry, the bug is here for months, it can wait a few day
* Amaranth smacks apt-file
<mvo> seb128: ok
<dconlon> Anyone know anything about the disappearance of libXcursor.la from the libxcursor-dev package in Breezy?
<seb128> .la are evil, daniels has decided to destroy them :)
<dconlon> Fair enough, breaks my Enlightenment builds though
<seb128> you have some other .la mentionning it probably
<seb128> just trash all the .la doing that
<seb128> or rebuild stuff with the right order so they stop doing that
<dconlon> cheers I'll get on with that, what's the particular problem with .la's though?
<seb128> they create such issues :p
<doko> http://gnome-look.org/content/preview.php?preview=1&id=29911&file1=29911-1.jpg&file2=&file3=&name=ubuntu+badger
<seb128> doko: cool
<Keybuk> dconlon: they show you up when you fuck up something to do with the builds
<Keybuk> so rather than fix the problems, people just remove the .la files and hide them
<Keybuk> "the .la file has the wrong information" just means you gave it the wrong information, and have a problem
<Keybuk> but some people are stupid and/or lazy
<seb128> I agree with the lazy
<seb128> but rebuilding 100 packages to update the .la files when something change is rather annoying
<seb128> ie: when cairo stopped to use glitz
<Keybuk> that's going to break people using static libraries too
<seb128> you have to rebuild, with the right order, all the stack
<Keybuk> so you need to delete all the .a files as well
<seb128> I doubt that his e17 build will need any static lib
<Keybuk> bet you they still get shipped though
<Keybuk> tbh, though, I'm somewhat inclined to write something that looks and smells like libtool. but actually isn't
<Keybuk> and just very thinly wraps gcc
<Keybuk> so when we build our packages, we end up with valid libtool .la files -- but don't actually use libtool to do it
<Keybuk> it takes away our build problems, without breaking the users (who can still use libtool itself)
<dconlon> There seem to be a lot of .la's created when I do my e17 build so it seems there seems to be some static libs being generated that reference each other, hence the problem with libXcursor.la
<seb128> no
<seb128> have the .la created doesn't mean that you use them
<seb128> it just give you the option to do so
<dconlon> is there a way then of doing a dynamic only build?
<Lathiat> arent .la files fairly useless on linux anyway
<seb128> you don't want to start this discussion with Keybuk :)
<Lathiat> haha
* Lathiat shuts up
<seb128> dconlon: --enable-static=no ?
<Keybuk> Lathiat: no :p
<Keybuk> they aren't needed on Linux for building shared libraries
<Keybuk> but they are still needed for building and linking to static libraries
<Keybuk> if you ship a .a file in your -dev package, you should also ship the .la
<Lathiat> Keybuk: oh ok
<Keybuk> but if you don't ship the static, on Linux, there's no reason to ship the .la
<Lathiat> whats it needed for?
<Lathiat> for statics?
<Keybuk> static libraries are just an archive of object files
<Lathiat> (i know its needed on some other platforms where you cant get the right info or something)
<Keybuk> they don't contain dependency information
<jbailey> Lathiat: defining relationships
<Keybuk> or version information, etc.
<Lathiat> ah ok
<jbailey> Shared ELF objects have that information
<Keybuk> so if I link to libxml2.a, it will fail
<Lathiat> but linux shared elfs do
<Keybuk> because I _also_ need to link to libz.a and libdl.a and libm.a
<Keybuk> and the .la file contains that information
<Keybuk> the .la file also contains the version information for the .a file, to make sure you don't link incompatible ones together
<Keybuk> all this is in the shared ELF on Linux, yes
<Keybuk> but not in the .a
<Lathiat> kernel stores TTL __s16
<Lathiat> oh
<Lathiat> actually
<Lathiat> mc_tlt
<Lathiat> __u8
<Lathiat> mc_ttl
<Lathiat> struct inet_sock {
<Lathiat> ...
<Lathiat>     __u8            mc_ttl;     /* Multicasting TTL */
<Lathiat> mc_loop is just 1 bit
<Lathiat> so let me chck what it decodes that as
<Lathiat> = !!val
<Lathiat> val being an int
<Lathiat> setsockopt takes an int
<Lathiat> so its probably casted in the kernel
<Lathiat> oh actually
<Lathiat> i lied
<Lathiat> its taken as  _u8
<Lathiat> and then casted into an int in the kernel
<Lathiat> its a pointer tho
<Lathiat> so it can really read whatever it wants out of it
<Lathiat> so mc_loop is !!val;
<Lathiat> for val = int
<Lathiat> and val = (int) optval
<Lathiat> and optval is a _u8
<Lathiat> for ttl its then stored without explicit cast
<Lathiat> in a _u8
<Lathiat> so
<Lathiat> go figure all of that out
<Lathiat> oh wtf
<Lathiat> irssi just typed that all into th wrong window
<Lathiat> but it said #avahi in the left
* Lathiat boggles
* Mithrandir was wondering wtf Lathiat was talking to himself about stuff which was just out of the blue here.
<ogra> EINDENTATION
<Lathiat> sorry guys
<Lathiat> must have got my terminal corrupted or something
<sivang> 'afternno all
<ogra> oh, its not code :)
<Lathiat> no
<Lathiat> i was just discussing the 3000 type changes
<Lathiat> something passed to setsockopt goes through
<Lathiat> in an attempt to dtermine the type we shoudl be passing to IP_MULTICAST_LOOP and IP_MULTICAST_TTL
<HiddenWolf> crimsun, ping
<sivang> pitti: Hey Martin
<pitti> yay, network back
<HiddenWolf> seb128, you took rhythmbox versions from cvs, right?
<infinity> dilinger : Will you be there with your keyboard?
<dilinger> infinity: yes
<seb128> HiddenWolf: no
<Lathiat> HiddenWolf: package claims to be 0.9.0
<HiddenWolf> seb128, i remember a lot of -cvs-etc version numbers, but must be some other package then.
<HiddenWolf> Lathiat, yes, that's why I was confused. I thought it was -cvs
<infinity> dilinger : \o/
<infinity> dilinger : For how much of it?
<seb128> HiddenWolf: I did package the CVS before 0.9.0
<seb128> HiddenWolf: but that was before 5.10, not for a stable
<dilinger> infinity: not sure yet.  i would like to stick around for the kernel stuff (but since the schedule's not known in advance, i have no idea whether i'll be able to), and i wanted to do some brainstorming/chatting w/ jeff about cdbs related things
<HiddenWolf> seb128, right, good. :) 0.9.1 changelog looks like it'll solve all my gripes with th current package. I was just checking it it'd all apply to the version now in breezy.
<freeflying> why don't we make grub perform more beautifuly with patch from susel 
<Lathiat> hrm, if you try compile a .cpp with gcc
<Lathiat> it spits out some undefined symbol error
<Lathiat> (compiles fine as a .c, g++ compiesl it fine)
<infinity> freeflying : Define more beautifully?... Ideally, it should be completely silent, except when displaying menus.
<infinity> freeflying : I'm indifferent about making the menus "prettier" at the expens of them perhaps not working anymore for some people.
<freeflying> but many newie prefer this 
<Kamion> freeflying: we tried using a graphical grub menu and it made it look worse in the common case due to VGA mode switches, plus caused problems on some weird graphics cards
<Lathiat> /tmp/ccAz06lX.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
<Lathiat> collect2: ld returned 1 exit status
<freeflying> so they may think thak ubuntu perform so bad compare to suse at first glance
<Amaranth> slomo: wanna be a guinea pig for my translation stuff?
<infinity> Lathiat : Not linking libstdc++
<slomo> Amaranth: depends... what shall i do?
<Lathiat> infinity: does having the '.cpp' extension do some magic in gcc?
<Lathiat> infinity: i mean, it compiles fine if its renamed to .c 
<Amaranth> slomo: in a minute i'll put up a new beta of alacarte with your old german translation in it, you download it, update the translation, install it, and see if it all works
<slomo> Amaranth: ok, fine :)
<infinity> Lathiat : Err, in both cases, it's being compiled with gcc, not g++?
<Amaranth> hrm
<infinity> Lathiat : I would guess so.
<Lathiat> infinity: yes
<Amaranth> i don't know where to install the translations
<Lathiat> infinity: and if i compile the .cpp with g++ its fine too
<Lathiat> its just compiling .cpp with gcc throws that error
<Lathiat> indeed -lstdc++ fixes it
<infinity> Lathiat : That's new behaviour of gcc to automagically use C++-mode for .cpp files.  It would also explain another bug I've seen recently.
<Lathiat> that seems kinda broken
<infinity> Hrm.
<Lathiat> what bug is that?
<infinity> Well, basically the same bug.
<Lathiat> infinity: looking at man gcc
<Lathiat> infinity: it says this behavior is correct
<Lathiat> line 480ish
<infinity> That compiling MySQL with 'gcc -fno-exceptions' used to work, and now it doesn't, cause it wants libstdc++ (though it shouldn't)
<Lathiat> infinity: ah
<Lathiat> at a guess its throwing it through the c++ preprocessor
<Lathiat> rather than the C preprocessor
<Lathiat> whats the name of the c++ preprocessor?
<infinity> cpp? :)
<Lathiat> ah
<infinity> But it's then shoving you off to cc1plus instead of cc1, probably.
<Lathiat> that doesnt exist?
<Lathiat> ah its in /usrlib
<freeflying> kaimon: how to make grub display graphically after use this patch
<Kamion> freeflying: splashimage directive, if I remember correctly; but #ubuntu for support questions, please
<Amaranth> slomo: http://dev.realistanew.com/alacarte-0.8beta4.tar.gz
<Amaranth> slomo: extract it, update de.po, run sudo ./setup.py install, see if you actually get everything translated
<Amaranth> slomo: sorry it took so long, this installer stuff is a PITA
<slomo> yes, it's even worse than autofoo ;)
<Amaranth> slomo: also, if you're running alacarte while it's translated into german in Help->About the credits button should pull up a dialog with your name in it
<slomo> yes
<Amaranth> slomo: that's the translator-credits string if you want to change it
<Amaranth> it works?
<slomo> no idea, i'm currently translating the missing strings ;)
<slomo> but i already noticed it
<Amaranth> ah
<slomo> Amaranth: "A menu can't be named \"Other\"." <--- is Other to be translated?
<Amaranth> oh, no
<Amaranth> ooh, WINE 0.9 coming tuesday
<slomo> Amaranth: you'll get a patch for some sources ;)
<Amaranth> eh?
<slomo> Amaranth: translations must be enabled for glade
<Amaranth> *facepalm*
<pvh> I keep getting "kernel-image not in control info" errors when trying to build a custom kernel using make-kpkg.
<pvh> I believe this is because Debian calls the custom kernel package "kernel-image", and Ubuntu calls it "linux-image", but I can't see how to specify that I want the resulting package to match the debian/control specs.
<pvh> Can anyone advise me on what I'm doing wrong?
<Amaranth> whoa, glade won't open my file
<Kamion> pvh: --stem linux
<pvh> Kamion: Thanks, I'll try that.
<Kamion> Debian's moving to linux-image too, so this will probably get cleared up eventually
<pvh> Kamion: I won't file a bug report then.
<Amaranth> slomo: i have them enabled for glade
<slomo> Amaranth: look at the query ;)
<pvh> Kamion: That did it! I've been trying to figure that out for two days now.
<pvh> Kamion: If I want to build a kernel that can coexist peacefully alongside another existing kernel, will I need to manually edit the debian/control file? I haven't read anything about having to do that before.
<Kamion> pvh: I'm not an expert on this, was just randomly answering a question I knew :)
<Kamion> I believe you can use --append-to-version to change the package name; I'd rather strongly recommend avoid editing debian/control by hand when using make-kpkg, as it all gets rather confusing
<pvh> Kamion: tell me about it. Thanks for your help anyway.
<Kamion> np
<carlos> doko, hi, around?
<jdub> jbailey: ping
<jbailey> jdub: pong
<mdz> morning
<doko> carlos: yes, but not long, we have to leave the booth now
<pitti> Hi mdz
<carlos> doko, it's fast
<carlos> doko, now that breezy has been released, could you take sometime to sync the spec at https://launchpad.net/products/launchpad/+spec/rosetta-openoffice-support with current implementation so we can approve and set as implemented it?
<carlos> doko, no need to do it today, just remember to do that
<doko> carlos: ok
<carlos> doko, thank you
<sivang> ogra: wow, edubuntu wiki is so visually appealing :)
<ogra> :)
<jdub> jbailey: is montreal canada/atlantic timezone?
<jbailey> jdub: No, canada/eastern
<jdub> thanks
<moyogo> seb128: could the patch actually be tested and included in pango on breezy?
<moyogo> seb128: this is a major bugfix for some african languages and for IPA
<moyogo> seb128: ... except there's no font to actually use the feature :(
<seb128> no
<seb128> that's quite a big change
<moyogo> ok
<seb128> not something you want to push to a stable version
<moyogo> cool
<moyogo> when is dapper in developpement then?
<Mithrandir> "soon"
<Kamion> next week sometime, we hope
<moyogo> sweet
<HiddenWolf> Kamion, decided on the name of the test releases already?
<Lathiat> "broken stuff"
<mvo> Keybuk: I was wondering if dpkg stores md5sum of the original conffiles of a pkg on the fs somewhere. or would that be a stupid idea?
<Lathiat> its not in the standard apckage md5sum file?
<Lathiat>  /var/lib/dpkg/info/*.md5sums ?
<Lathiat> they seem to be
<Lathiat> at least for some packages
<Keybuk> mvo: do you mean of the original package file?
<Keybuk> or the original contents of the package file?
<Keybuk> dpkg stores md5sums of configuration files in status
<Keybuk> some packages ship an md5sums control file which ends up as *.md5sums -- but that's not actually used or understood by dpkg
<Lathiat> ah, so it does
<mvo> Keybuk: great, that's what I was looking for (but didn't rememberd)
<Lathiat> Keybuk: is that md5sum taken postinst?
<Keybuk> Lathiat: "taken" ?
<Lathiat> calculated
<mvo> Keybuk: thanks!
<infinity> mvo : It would have to, how else do you think it handles conffile updates? :)
<Lathiat> as in, if the packages postinst messes with config files, does it md5 before or after that?
<Keybuk> it's calculated during unpack
<Lathiat> ok
<Keybuk> package postinst's are forbidden from messing with conffiles
<Keybuk> anyone caught doing it has their hands chopped off
<Keybuk> anyone caught doing it again has their package chopped off :p
<infinity> If only...
<sivang> Keybuk: cool, that's pretty good
<Lathiat> whats the proper definition of a conffile?
<infinity> Lathiat : A config file that's handled by dpkg.
<Lathiat> ah ok
<Keybuk> Lathiat: conffile = a file registered with dpkg as a conffile; appears in the conffiles control file and is managed by dpkg
<Lathiat> as opposed to say /etc/X11/xorg.conf, gotcha
<Keybuk> not all configuration files are conffiles
<Keybuk> in particular, if a package wants to ditz about with it in postinst, it is not allowed to register it as a conffile
<sivang> Keybuk: what is X11/xorg.conf then ?
<Keybuk> (because dpkg would issue a conffile prompt [the Y/N/D/Z thing]  every single upgrade)
<Keybuk> sivang: it's a file on the disk
<infinity> Keybuk : Any plans to eventually pull ucf's functionality into dpkg, so we can have a decent C implementation (and something blessed by policy)?
<Keybuk> infinity: no, not ucf
<sivang> Keybuk: but some package puts is there, no? :)
<Keybuk> sivang: it's not owned by any package, no
<infinity> Keybuk : Note I said the functionality, not the code.
<Keybuk> it's most likely written by one of the X postinsts
<sivang> Keybuk: ah, created on runtime by dexconf?
<Keybuk> I can't recall which one, maybe -common
<infinity> Keybuk : ie: Tha ability to magle conffiles, but still have them registered in their mangled states.
<Keybuk> infinity: http://www.dpkg.org/Classes
<infinity> xserver-xorg's postinst does xorg.conf
<HiddenWolf> infinity, shush ;)
<sivang> hmm, /me finds yet another expection for backing up conffiles....
<sivang> thoe "not owned by any package" files
<sivang> maybe get a hardcoded list of those..
<infinity> Keybuk : Cool.  Got a reference implementation yet? :)
<infinity> sivang : You should back up all of /etc anyway.
<Keybuk> infinity: yes :p
<Keybuk> shockingly
<Lathiat> a lot of /etc is crap tho
<infinity> Sweet.  Is this dpkg 2.0 stuff, or feasible in the near (next year or so) future?
<infinity> Lathiat : Only due to gconf living there, which should be moving RSN.
<Lathiat> i tend to see a whole bunch of other crap that im not particularly interested in backing up
<Lathiat> alternatives
<infinity> Lathiat : Without the evil that is gconf, /etc is tiny, and "crap" or not, you're better off with a "better safe than sorry" attitude to grabbing it with your backups.
<Lathiat> lots of hotplug
<Lathiat> infinity: oh, sure
<sivang> infinity: I want to be able to backup only things that  user changed ....
<infinity> alternatives is a mess of symlinks.  It's it hurts to copy those. :)
<Lathiat> udev rules, a whole whack of X11 crap
<Keybuk> infinity: probably 2; on the basis it's from-scratch code
<infinity> s/It's/Like/
<Keybuk> sivang: beware of the "files in /etc that are obsolete conffiles" trap too
<infinity> sivang : Then you need to start with a system snapshot of what you believe is "clean", and work from there.  The "full+incremental" backup model.
<infinity> sivang : There's no other way you'll maigcally know what they did and didn't change.
<sivang> infinity: ah right :)
<sivang> infinity: me and mvo discussed the MD5 way :)
<infinity> Right, but you need "unchanged" MD5s of everything first.
<Kamion> sivang: "dpkg-registerfile" (let postinsts register files with dpkg so that at least it knows who owns them) was proposed about a zillion years ago but hasn't made it into implementation yet
<infinity> Which takes you back to "full+incremental"
<infinity> No initial snapshot, no dice.
<sivang> e.g., comparing right, and as Keybuk noted, they are not held for any package
<sivang> Kamion: I see
<infinity> sivang : I suppose you could just do incremental for everything you have md5sums of, then "everything else"  (ie: all unregistered files would be considered changed)
<infinity> sivang : That would work well enough.
<sivang> infinity: yes, that seem as a sane defulat
* sivang yays for his typing
<infinity> I assume you're only using md5sums for conffiles, you're not summing everything in /usr.... Right? :)
<infinity> Cause that'd be evil.
<infinity> I'm all about dpkg --get-selections as a backup tool, and people wh omodify packaged binaries can cope with the loss. :)
<Lathiat> debsums does the whole md5sum everything
* Kamion successfully teaches germinate not to try to satisfy versioned dependencies of .debs with virtual packages; that should get rid of a fair few germinate workarounds in the seeds
<infinity> Lathiat : Yes, but a backup tool that CHECKS md5sums of the whole system would be painfully slow and useless.
<Lathiat> ah
<Lathiat> right
<sivang> infinity: that's the Kamion argument :) my vision is to have classes of snapshots, so for each membet of MarketingTeam, install snapshot:marketing-workstation :)
<sivang> infinity: not just "plain" bakcup..
<infinity> I mean, okay, a backup tool with a checkbox that says "I'm a really bad UNIX admin, and I put files ALL OVER MY DISK, so check it all" would be fine.
<Lathiat> heh
<infinity> But the default should be "backup /etc, home, /usr/local, the good bits from /var, and a package list"
* Lathiat always forgets something silly like /var/www
<Lathiat> or /var/lib/mysql
<infinity> Take all of /var, if you're paranoid.
<infinity> "The good bits" required actuall remember what's there, afterall.
<infinity> s/required/requires/
<Keybuk> sivang: one other thing that's worth making clear
<Keybuk> dpkg is a bit crap and litters /etc with obsolete conffiles
<Keybuk> if a package drops a conffile, dpkg doesn't remove it
<infinity> Keybuk : Which are often wanted.
<Keybuk> so watch out for those too
<Keybuk> yeah
<Keybuk> some of them are conffiles that have been turned into "edited by postinst" files
<Keybuk> and some of them really are supposed to have been deleted, but the maintainer didn't in postinst
<infinity> More fun, though, is backing up the "user deleted the conffile" state.
<Keybuk> ooh, didn't think of that one
<Keybuk> yes, you need to back that up to <g>
<Keybuk> deleting a conffile is a user change
<infinity> I assume you'd check for the file, if it doesn't exist, reocrd that, then when restoring, install the package and remove the conffile.
<Keybuk> ie. you might delete something from /etc/cron.daily
<sivang> Keybuk: right 
<sivang> damn :) that's a pandora box 
<Keybuk> (dpkg preserves that, if you upgrade it won't put the conffile back -- a source of many people's miseries
<Kamion> you could reconstruct that from /var/lib/dpkg/status plus your backup of /etc
<Keybuk> ie. I wiped /etc, reinstalled all the packages, and it didn't put any conffiles back, what gives?)
<sivang> yes, I mysself have been bitten by this
<Lathiat> yes thats caught me out a few time
<Lathiat> --force-confmiss or something i think 
<Keybuk> indeed
<Lathiat> only learnt that recently
<sivang> Lathiat: right :)
<Lathiat> i had many pains about that in previous years
<sivang> Lathiat: me too, from mvo :-)
<Lathiat> yeh i read it in here
<infinity> Kamion : If you backed up all of /etc, but sivang wants to only backup "the bits that changed", which is where the fun comes in.
<sivang> infinity: indeed :)
<Keybuk> these days I go out of my way to never change /etc
<infinity> (It's really much less hassle to juct backup all of /etc)
<Kamion> infinity: if it's full+incremental you can still work it out, as long as you can represent deletions in the incrementals
<Kamion> (which, surely, you can ...)
<infinity> Indeed.
<infinity> I argued this already. :)
<Keybuk> of course, being a developer on the distro you use, so you can change the package defaults to match your taste _helps :p
<infinity> He seems to be talking something fancier and/or crazier.
<sivang> Keybuk: I'm not sure I'm following you ... :)
<Keybuk> sivang: which bit?
<sivang> Keybuk: the "taste _help" one
<Keybuk> oh
<Keybuk> just muttering about me never changing /etc
<infinity> Keybuk : I just have apt configured to deny all new conffiles by default, then a post-invoke hook to show me find /etc -name \*.dpkg\*
<infinity> Keybuk : So I can peruse the diffs at my leisure, rather than ACT ON IT RIGHT NOW, DAMNIT.
<Keybuk> the only file I had to change when installing my desktop was /etc/hdparm.conf -- and I'm sure we can automate that one in dapper or dapper+1 :p
<sivang> infinity: hmm, so maybe work the other way around , track in a way similar to what you've mentioned, all the changed stuff. that prepares stuff in advance, instead of borking when trying to create a snapshot
<sivang> Keybuk: so anyway, every packages should have that .md5sums file in /var/lib/dpkg/info/ and if its not there, I can always check status ?
<Keybuk> sivang: no, there's no requirement for an md5sums file in info
<Keybuk> and for all you know, the contents could be the recipie for the author's meatloaf
<sivang> lol
<infinity> Yeah, the md5sums aren't always right (well, these days, if they're there, they seem to be right, but in the past there were oddities with that file not matching reality)
<infinity> But you can't count on them in any way, really.
<sivang> I wonder if given all this, starting with something that stores package selections, together with possibly gconf settings of a user/system can be a good starting point towards the snapshots/usage classes eventually..
<sivang> e.g., starting small which I intend to do anyways, just was nice to get some feedback re: the grand scheme
<sivang> (thanks all)
<Kinnison> ciao all
* zyga is back from work
<dilinger> http://www.zwane.com/blog/?p=59
<dilinger> how many people are taking one of those to ubz? :)
<sivang> dilinger: ROTFL
<sivang> :)
<crimsun> HiddenWolf: pong
<HiddenWolf> crimsun, It seems /all/ audio on my system is delayed by like 2 seconds.
<HiddenWolf> crimsun, any clue how I can figure out why?
<crimsun> HiddenWolf: ->#ubuntu
<\sh> jdub: pign
<\sh> ping even
<jdub> \sh: pong
<\sh> jdub: did u change something today on the planet?
<\sh> jdub: reloading or something? ,-)
<jdub> nup
<\sh> jdub: or should I change to atom 0.3 / atom 1.0?
<jdub> i don't have access to it
* \sh installs a test install of planetplanet
<zul> did the archive go caput?
<crimsun> Fetched 22.7kB in 2s (11.2kB/s), seems fine to me.
<zul> seems to be just me then
<mdz> fabbione: https://launchpad.net/distros/ubuntu/+spec/installer-volume-management
<mdz> fabbione: you don't really mean "by default", do you?
<ajmitch> yay, I have a passport so I can get to UBZ now ;)
<Treenaks> ajmitch: wooohoo :)
<ajmitch> Treenaks: I put in the application a bit late, my old passport was a bit water-damaged
<Treenaks> ajmitch: mine looks used, but isn't
<Treenaks> ajmitch: but then, it's 4 years old
<ajmitch> I'll be travelling through the US, I've heard they don't like passports that look worn, have bad photos, etc :)
<ajmitch> which mine did
<Treenaks> ajmitch: I'm going from Amsterdam to Heathrow, and then straight to Trudeau (Montreal)
<crimsun> definitely don't want a warn passport
<crimsun> worn
<crimsun> geez, mind is befuddled today
<Treenaks> crimsun: not worn, just.. well, used
* ajmitch is going via SF, then vancouver, then montreal
#ubuntu-devel 2005-10-27
<Lord_Maynoth> just wondering if anyone knows what features dapper drake is going to have?
<Lord_Maynoth> it it autoconfig my windows partitions?
<HiddenWolf> Lord_Maynoth, breezy should do that.
<Lord_Maynoth> it doesn't by default
<Lord_Maynoth> you can download a script
<HiddenWolf> Lord_Maynoth, dappergoals will be decided next week
<Lord_Maynoth> awesome
<HiddenWolf> Lord_Maynoth, installer should pick it up, but not mount it, no.
<HiddenWolf> we don't want rm -rf /media/windows happening by mistake. :P
<Lord_Maynoth> I bet in a year or two ubuntu will be a viabler replacement  to windows (for windows idiots like me)
<Lord_Maynoth> your guys are evolving ubuntu at such an awesome rate
<HiddenWolf> we're hoping to be there faster. :)
<Lord_Maynoth> now if autopackage would only hurry up and design a native package and dependency resolution system.... switching to linux might just be possible
<Lord_Maynoth> I can't wait
<Lord_Maynoth> ^_^
<HiddenWolf> Lord_Maynoth, excuse me, but autopackage is scary shit.
<Lord_Maynoth> awesome if you ask me
<HiddenWolf> Lord_Maynoth, I wouldn't install it for the love of god.
<Lord_Maynoth> I used gaim 1.50 and abiword on hoary
<Lord_Maynoth> with no problems
<Lord_Maynoth> and it even provided an unistaller
<Lord_Maynoth> Autopackage really has a bad rep
<HiddenWolf> Lord_Maynoth, you probably know what you're doing, but I don't want to see ubuntu getting a bad reputation because $randomnoob can by default start clicking on random executables and mess up his system.
<HiddenWolf> so no, I'm not a fan of autopackage.
<HiddenWolf> .deb is not ideal, but it works _well_
<Lord_Maynoth> yeah... but it or something like it is going to have to happen before linux becomes mainstream
<Lord_Maynoth> I have had more probs with debs than ap
<Lord_Maynoth> no icons etc
<HiddenWolf> Lord_Maynoth, that's just a .desktop file that needs to be made. that's a 5minute bugfix.
<HiddenWolf> Lord_Maynoth, universe should be mostly cleaned out as far as desktop files go nowadays.
<Lord_Maynoth> oh
<Lord_Maynoth> I found a bug
<Lord_Maynoth> freeciv the game does not install from the add/remove programs
<HiddenWolf> launchpad.net/malone
* HiddenWolf *sighs*
<dilinger> you guys need to link to the netinstall images for breezy :P
* dilinger finds them via google and a random planet.arstechnica blog entry
<HiddenWolf> any server admin on?
<HiddenWolf> http://help.ubuntu.com/faqguide/C/index.html
<HiddenWolf> Not Found
<HiddenWolf> The requested URL /faqguide/C/index.html was not found on this server.
<HiddenWolf> Apache/2.0.54 (Ubuntu) PHP/4.4.0-3 Server at help.ubuntu.com Port 80'
<derek> hey, i think i found a bug
<ajmitch> file a bug then
<derek> i installed warty->hoary->breezy one right after another, and it was running funny, i did apt-get distupgrade
<derek> it never installed ubuntu-desktop meta
<derek> i have no browser yet :) i will when i have one
<HiddenWolf> derek, just apt-get ubuntu-desktop then.
<sabdfl> hey stubarooney
<lifeless> stub: yo
<stub> yo
<sabdfl> night guys
<jayakumar2> any of you coming to foss.in/2005?
<dilinger> breezy's installer *really* wants to create a partition on /dev/md0
* dilinger growls
<Lathiat> dilinger: heh
<fabbione> mdz: meh no.. i meant available by default on all arches
<fabbione> mdz; fixed..
<mdz> fabbione: grazie
<fabbione> mdz: prego :)
<fabbione> ah rocking..
<fabbione> https://wiki.ubuntu.com/KernelGitGuide <-
* fabbione ^5s BenC
<zyga> morning
<Keybuk> so it is
<fabbione> Riddell: ping?=
<fabbione> bella Scott
<Keybuk> fabbione: which day do you get to Canada?  Wednesday?
<fabbione> Keybuk: yes
<Keybuk> I arrive Thursday evening
<fabbione> Keybuk: cool.. 
<fabbione> i will be playing the turist till sunday
<Keybuk> me also
<fabbione> at least that's what i am hoping for ;)
<fabbione> now.. why the last KDE updates did kill all my local changes?
<fabbione> Riddell: you better show up dude...
<fabbione> ;)
<fabbione> Keybuk:  i am getting this little mythtv box up and running, very slowly :)
<Keybuk> I'm hanging around waiting for a delivery van to arrive
<fabbione> Keybuk: what are you waiting for?
<Keybuk> which is possibly one of the most prolonged, irritating and ultimately disappointing things you can spend a weekend doing
<Keybuk> other than being in bed with my ex, of course
<fabbione> ehheh
<Keybuk> fabbione: like the rest of the world, my 770
<fabbione> 770 ??
<Keybuk> www.nokia.com/770
<fabbione> oh
<fabbione> i am not into mobile phones and stuff like that
<zyga> fabbione: it's not a phone
<zyga> fabbione: if it were, it'd be usefull
<Keybuk> it's not a phone, it's a hand-held web browser, basically
<fabbione> ah
<Keybuk> has wi-fi and bluetooth to get to the world
<zyga> fabbione: it's a touchscreen with a browser, mostly open source
<fabbione> ok gotcha
<zyga> fabbione: unfortunatly the battery lasts for 2 hours ;] 
<zyga> so it's really useful *g*
<fabbione> Keybuk:  i am waiting for my powerbook :) 
<fabbione> too bad it won't make it for UBZ :(
<zyga> Keybuk: how much does the nokia cost now?
<Keybuk> dunno, I got one of the developer ones
<zyga> ah
<zyga> neet :)
* zyga never gets stuff like that
<Keybuk> or, at least, am waiting for it to arrive
<fabbione> bah
<fabbione> the last kde uploads are full of regressions
<fabbione> including destroying my user settings for the 3rd time in a raw
<fabbione> row even
<fabbione> Keybuk: do you happen to know how to completely kill automount of removable devices?
<fabbione> just at system level
<fabbione> not kde
<Treenaks> fabbione: killall hald ?
<fabbione> given the latter does whatever it wants, the hard approach seems to be the only solution
<fabbione> Treenaks: i want it permant
<fabbione> permanent
<Treenaks> fabbione: dpkg --force-depends --purge hald
<Keybuk> sure, remove /etc/hotplug.d/default/20-hal.hotplug
<fabbione> ok thanks
<Treenaks> but Keybuk's way looks less prone to breaking :)
<Keybuk> it'll pretty much neuter hal, but then hal doesn't do much else in breezy anyway
<fabbione> that didn't work
<fabbione> i guess i need to restart something...
<Keybuk> hmm, shouldn't do ... that's the way it gets told about new things
<Keybuk> unless it'd being evil and actually polling the filesystem, which it bloody well shouldn't be <g>
<fabbione> it probably does
<Keybuk> I don't know how the kde stack works
<Lathiat> the kde stuff doesnt use hal iirc
<fabbione> no it doesn't
<Lathiat> i knwo theres work to do it but i dont think we're using it
<fabbione> and for some reasons in the last update there is no frigging way to disable kio_media
<Lathiat> eh, its usefull anyway
<Lathiat> stick in an audio cd :)
<fabbione> that makes my mythtv box unuseable
<fabbione> Lathiat: no, it's not useful
<Lathiat> fabbione: why are you running kde under myth?
<fabbione> i need it disabled
<Lathiat> remove the .so? ;)
<Lathiat> oh the myth qt stuff is using kio media and popping up stuff?
<fabbione> no i want a clean way to do it
<fabbione> Lathiat: no
<fabbione> mythtv preferes kde due to some focusing gnome issues
<fabbione> so i am using kde
<fabbione> and that's ok as underground layer
* Lathiat wasnt using a desktop at all when he was using myth
<fabbione> i don't want kde to crap my desktop when i insert a DVD
<Lathiat> just had myth started under a blank x session
<Lathiat> fabbione: how did you disabled it before?
<fabbione> just disabling the media manager from kde services
<fabbione> except that now keeps restarting automatically
<fabbione> even if i tell the system not to use it and to stop it
<Lathiat> works here, i stopped it an unchecked use and it didnt popup my dvd 
<Lathiat> hrm actually i lie it opened in the background somewhere
<sivang> Good morning all
<[Chameleon] > sivang: g'morning
<sivang> [Chameleon] : hey there
<[Chameleon] > :)
<[Chameleon] > sivang: was I talking to you a while back before Breezy was released about a xine bug related to stretching?
<sivang> [Chameleon] : not that I recall :)
<[Chameleon] > sivang: k, must have been somebody else.
<Treenaks> hi sabdfl 
<sabdfl> howdy Treenaks
<Treenaks> sabdfl: I've been playing with my new camcorder: http://foodfight.org/movies/2005-10%20Ubuntu%20Fanpeople/
<ajmitch> morning sabdfl 
<[Chameleon] > hi sabdfl
<Treenaks> (I've heard reports of the .ogg's crashing the totem-plugin in firefox, so downloading them first might be a good idea)
<sabdfl> Treenaks: cool, what are you using for encoding?
<Treenaks> sabdfl: I capture/edit/export them using kino
<Treenaks> sabdfl: (which uses ffmpeg2theora)
<[Chameleon] > Treenaks, sabdfl: seen http://www.jahshaka.org/ ?
<Treenaks> [Chameleon] : looks heavy, but cool
<[Chameleon] > I've been waiting for a reason to try it
<[Chameleon] > because it does look very cool
<[Chameleon] > and now that I have a better video card (got an nVidia GeForce 6600 GT the other day), I'm even more interested.
<[Chameleon] > Previously I was using a Radeon 9000 Pro, which is a decent card.
<sabdfl> [Chameleon] : is there a package for it in ubuntu?
<[Chameleon] > sabdfl: not that I'm aware of
<sabdfl> well, if you're feeling inspired, put one together!
<[Chameleon] > sabdfl: there's a .deb
<[Chameleon] > sabdfl: I'll try the generic .deb and go from there. I don't yet know how to package... This is a good time to learn.
<Treenaks> [Chameleon] : join us on #ubuntu-motu
<sabdfl> [Chameleon] : yes. should be straightforward
<HiddenWolf> sabdfl, don't listen to treenaks, he wasn't playing. we where forced to say we where ubuntu-users at gunpiont. :P
<HiddenWolf> sabdfl, be grateful he has to go through airport security before montreal. ;)
<[Chameleon] > LOL
<sabdfl> HiddenWolf: count on it. the .ogg's don't work in ff for me, only standalone
<ajmitch> heh
<HiddenWolf> yup, totem plugin is bugged.
* ajmitch is looking forward to being there, but not looking forward to the flights
<[Chameleon] > sabdfl: what do you think of a future meeting to be held in Seattle? Too close to Microsoft turf?
<sabdfl> ajmitch: need a biiiiig battery
<HiddenWolf> btw, sabdfl, the mandriva guy copied your faq. :) Bite back. ;)
<Lathiat> pedal power!
<ajmitch> yeah :)
<sabdfl> ajmitch: this week i fly to montreal on wednesday, to pretoria on thursday, and back to montreal on friday
<ajmitch> I heard that vancouver airport has wifi though
<ajmitch> ouch
<sabdfl> HiddenWolf: imitation is the sincerest form of flattery
<HiddenWolf> [Chameleon] , US > Free Software > being accused of being commies. :)
<ajmitch> you must clock up a lot of hours in the air
<sabdfl> ajmitch: big battery
<ajmitch> :)
<[Chameleon] > HiddenWolf: if free software == commie, gimme one of those furry hats and point me to the bread line!
<Lathiat> sabdfl: what laptop do you have?
<sabdfl> Lathiat: X40
<Lathiat> sabdfl: ah, like half the rest of canonical :)
<Lathiat> sabdfl: got the big battery + one of those battery mat thigns?
<sabdfl> no. got a generator on the plane
* ajmitch just has the stock dell battery for this latitude
<sabdfl> the mats are amazing
<Lathiat> i want to get a side battery for mine
<Lathiat> to replace the cdrom
<Lathiat> sabdfl: yeh theyre pretty cool
<sivang> sabdfl: that's cool :)
* sabdfl is looking forward to fuel cell batteries
<Lathiat> sabdfl: oh yeh
<Kinnison> sabdfl: mmm smells of ammonia
<Lathiat> i saw one thats not alot bigger than the current batteries
<Lathiat> and does like 20horus+
<sivang> Kinnison: where are you now?
<Kinnison> sivang: Wales for my grandmother's 90th birthday
<Lathiat> i coudl just leave home without my charger
<sivang> Kinnison: nice :)
<ajmitch> Lathiat: I'd like that
<sabdfl> hey Kinnison, how are the celebrations going?
<Lathiat> the battery in my m20 isnt so big
<Lathiat> only does 3H or so
<Lathiat> my 8600 does like 5hours on a stretch tho
<ajmitch> I think I'll be forced to read a book to keep myself occupied
<Kinnison> sabdfl: due to start soon, hence if I'm meant to be reviewing something for kiko, I'd like to get it done soon
<HiddenWolf> [Chameleon] , :)
<sabdfl> Kinnison: has he landed it?
<Kinnison> sabdfl: I thought I was meant to review it first :-)
<Kinnison> sabdfl: maybe he'll be sending it to me when he gets in today
<Lathiat> whats with all this landing its a launchpad not a landingpad :)
* Kinnison shrugs.
* Kinnison grins
<sabdfl> Kinnison: so, i had a minor heart attack last night, when i learned that there were no plans for a proper multiarch test of gina before rollout
<sabdfl> mdz was having conniptions
<sabdfl> so
<Kinnison> sabdfl: You're kidding? I told them over and over that we had to do multiarch
<sabdfl> Kinnison: "them" had no idea
<[Chameleon] > fuel cell battery for laptops available today:
<[Chameleon] > http://www.valence.com/ncharge.asp
<Kinnison> sabdfl: kiko and stub I told
* Kinnison sighs
<Lathiat> [Chameleon] : ooh *looks*
* Kinnison thinks that so many people dislike gina that it goes in one ear and out of the other
<Lathiat> [Chameleon] : will it cost 2 arms and a leg?
<sabdfl> current plan is that elmo is giving staging the necessary go go juice to do an entire archive, w/h/b, all three official architectures
<Kinnison> sabdfl: My dad is going to be doing a hoary->breezy upgrade today
<sabdfl> Kinnison: FTFUAW?
<Kinnison> sabdfl: cool
<Kinnison> sabdfl: pardon?
<[Chameleon] > Lathiat: 10 hours costs $300
<sabdfl> sorry. the STFUAW protocol?
<Kinnison> yes
<[Chameleon] > Lathiat: 5 hours is $200
<sabdfl> sunday, stub will do the whole kaboodle on staging
<Lathiat> [Chameleon] : see you can get battery matts that do similar
<Kinnison> sabdfl: I think the f*ck the f*ck up and watch protocol is what we do when we land code without review
<Lathiat> [Chameleon] : err, thats just a li-ion battery?
<sabdfl> monday, we will do some test uploads of dapper-grade bits
<sabdfl> har har
* Lathiat tries to make sense of the page
<Kinnison> sabdfl: cool, I'm very happy to go ahead with that on Monday
<[Chameleon] > Lathiat: I haven't heard of the mats... URL?
<Lathiat> [Chameleon] : there basically what you just pasted
* Kinnison goes to watch
<Kinnison> ciao dudes
<Lathiat> just a bit fla tbattery to sit yoru laptop on
<sabdfl> if its all good, we DOIT tuesday
* Kinnison nods
<sivang> sabdfl: what is gina?
* ajmitch cheers
<sabdfl> if not... katie comes into service and we need to switch to soyuz later in the cycle
<sabdfl> sivang: gina is a transitioning tool to get old archive data into the new archive mgmt system
<[Chameleon] > Lathiat: ahh... yeah, these batteries are safer and more environmentally friendly.
<Lathiat> [Chameleon] : yeh yeh every product is safer and more environmentally friendly than the last one ;p
* Lathiat grins
<[Chameleon] > well... Litium-Ion batteries use cobalt-oxide, which is rare and kind of explosive. The valence onces use a phosphate material that is readily available, cheap and totally safe.
<[Chameleon] > if a lithium-ion battery overheats, a runaway situation occurs where the burning cobalt-oxide actually produces more oxygen as it burns and fuels the fire.
<[Chameleon] > that's why hybrids are still using lead-acid batteries, because they are safer.
<[Chameleon] > though far less efficient
* sivang tests a new irssiproxy setup
<Treenaks> sabdfl: the oggs-not-working is a problem with the totem firefox plugin, I think
<Treenaks> sabdfl: it doesn't work for mpg here either (and those also do work standalone)
<\sh> good morning world
<Treenaks> hey sh
<Riddell> fabbione: having fun?
<Kamion> it is depressing that when I typo a bug number, it's *still* assigned to me anyway
<ajmitch> morning \sh 
<slomo> hi \sh :)
<sabdfl> hey \sh
<sivang> yo \sh , sup?
<\sh> ok...wanna have some good news?
<ajmitch> yes please :)
<sivang> \sh: yeah
<Lathiat> NO NEVER NO NO NO
<sivang> Lathiat: lol
<Lathiat> save me the pain and suffering!
<\sh> 1. my jabber server sourcecode.de is first place of all .de public jabber servers
<sabdfl> Kamion: heisenbug tunnelling effect?
<\sh> (stability wise)
<sivang> \sh: nice
<\sh> 2. it's running on Ubuntu 5.04
<sivang> pitti: Morning!
<Lathiat> \sh: :)
<ajmitch> morning pitti 
<\sh> was a suprise for me this morning :)
<ajmitch> \sh: impressive :)
<sivang> \sh: haha
<ajmitch> pitti: I have phpmyadmin fix for the security-review list
<fabbione> Riddell: no :)
<\sh> now I need to find the time to go to hosteurope DC and upgrade from hoary to breezy server install ;)
<ajmitch> \sh: you don't want to do a remote uograde?
<Lathiat> haha
<fabbione> Riddell: i am on the way out shopping now, do you have any idea on how to workaround that problem?
<sivang> lol
<Lathiat> of course ! a remote upgrade ! everyone should do those!
<ajmitch> Lathiat: why not?
<ajmitch> Lathiat: I did a remote upgrade to breezy when it opened :)
<Lathiat> ajmitch: youve never done much sysadminning have you? :)
<Lathiat> ha
<ajmitch> Lathiat: live on the edge
<\sh> ajmitch: no...i have some "experimental debian packages" running ;) cyrus-imapd didn't work on hoary for my setup (libdb stuff) and I needed the one from debian
* Lathiat learnt the lesson not to remote upgrade a couple times
<Lathiat> including at 10PM on christmas eve
<ajmitch> haha
<Lathiat> well, it was more liek 8
<pitti> Hi sivang 
<Lathiat> i had to catch a bus a train and a bus
<Lathiat> fi xit
<Lathiat> and catch them back
<ajmitch> \sh: well we can fix those in dapper so you can do your remote upgrade then :)
<Lathiat> got back by 1230am or so
<\sh> Lathiat: what? I installed hoary remotely :) 
<Lathiat> \sh: installing is fine
<Lathiat> if it buggers up you rnot sacrificing anything
<Lathiat> but upgrading a remote system thats live
<Lathiat>  = suck
<\sh> Lathiat: well...after reboot I had to go to the DC right ;)
<Lathiat> haha
<\sh> Lathiat: but u r right...I don't want to do a remote upgrade
<ajmitch> pitti: I didn't find a CAN for the phpmyadmin problem
<Kamion> sabdfl: I hope not. I have enough of them without not being able to know how many there are and how fast they're going at the same time
<sabdfl> send some of them to Copenhagen?
<pitti> ajmitch: I don't have one either
<ajmitch> pitti: it's sent anyway :)
<pitti> ajmitch: if you want one, just ask cve@mitre.org :-)
<Riddell> fabbione: what's the problem?
<fabbione> Riddell: the kio_media service can't be stopped. I was able to stop automounting/autoplaying on CD/DVD inster,
<fabbione> insert even
<fabbione> Riddell: now even if say to the Session Manager (or whatever is called) to not use the kio_media service and i stop it
<fabbione> as soon as i insert a DVD it starts the service again, it automounts and autoplay
<Riddell> fabbione: killall ivman
<Riddell> remove it from startkde
<fabbione> this is a regression for 2 reasons: one it was set not to start and the new pkgs override this behaviour. two it breaks my setup :)
<Riddell> fabbione: where was it set not to start?
<fabbione> Riddell: but how/why has been added back?
<fabbione> Riddell: from one of the control setting entris
<fabbione> entries
<Riddell> there's no control centre setting for ivman
<fabbione> there is one for kio_media
<Riddell> that's separate
<jayakumar2> out of curiosity, are any of you coming to foss.in/2005?
<Riddell> jayakumar2: possibly
<fabbione> Riddell: well i possibly don't remember how i did stop that in the first place. it's still a regression that it doesn't respect my settings :)
<pitti> sivang: yay, I just got answer from the cups guys
<fabbione> Riddell: but i will try that
<jayakumar2> Riddell, as a spkr?
<pitti> sivang: cups 1.2 handles dynamic printer additions
<fabbione> Riddell: thanks dude.. have a nice weekend
<pitti> sivang: so we don't need to bother with restarting on new printers
<Riddell> jayakumar2: hopefully, I understand that they will be sending me an invitation
<sivang> pitti: yay cool!
<Riddell> fabbione: kio_media just shows the devices in media:/ in KDE 3.4,  ivman does the automounting but isn't very integrated with KDE, KDE 3.5 does that better
<sivang> pitti: does it involve any work on our side?
<fabbione> Riddell: ok.. i will check that. gotta run now
<pitti> sivang: well, we have to package the new version :-)
<fabbione> Riddell: thanks again
* fabbione &
<jayakumar2> Riddell, cool. i'm told invites will be sent around oct 25th
<jayakumar2> also ooc, will there be an attempt to distribute lots of CDs? last years attendance was apparently 3k
<Riddell> jayakumar2: if I do get asked to be a speaker I'll make sure to bring lots of kubuntu CDs :)
<jayakumar2> lots as in like 3k?
<Riddell> that might go over my luggage allowance..
<Riddell> jayakumar2: are you involved with it somehow?
<Nafallo> jbailey: you changed key for a reason?
<sivang> pitti: do you have details about the way they solved it? did they rewrite the event handler to be good ? :)
<jayakumar2> Riddell, i'm not an organizer, just a volunteer type. i might be giving a talk on massputers though. kernelplanet.org
<pitti> sivang: they don't load the printer list on startup any more
<pitti> sivang: but rather load it when someone actually asks for it
<Nafallo> jbailey: anyway. I get BADSIG today.
<sivang> pitti: ah , very good. that relieves the periodical polling for available printers
<mdz> sabdfl: conniptions hah
<crispin> pitti: I'm not quite sure what happened with bug 18260, I didn't mean to set it to ASSIGNED, I must have hit the radio button by accident, sorry about that
<gabrieltomate> the calc.
<gabrieltomate> in mode expert, dont do "raiz"..
<Treenaks> ?!?!
<gabrieltomate> dont peak english very well
<gabrieltomate> speak
<gabrieltomate> open calc, chage to expert mode
<gabrieltomate> cahnge
<Diziet> Are you sure you shouldn't be in #ubuntu, which is where support enquiries should go ?
<gabrieltomate> now, say "9"
<gabrieltomate> and click in the "3 line, 6 coluna" (C6 in xadrez)
<gabrieltomate> look the results: "9Sqrt("
<gabrieltomate> dont do the calc
<infinity> gabrieltomate : Yes, and?
<gabrieltomate> its a bug.. no?
<infinity> Nah, just type stuff in in the right order. :)
<gabrieltomate> how i report this?
<infinity> Sqrt(9) works a bit better.
<jsgotangco> hey rob^ :)
<mvo> a question for the pyton gurus: I have a python module (written in c) and it looks like there is no local information set in it even though the locale information in the terminal are fine. inside the module, e.g. nl_langinfo(CHARSET) returns ACSII (but my local is UTF-8)
<zyga_> did you call setlocale?
<mvo> zyga_: no
<ogra> mvo, 
<ogra> #!/usr/bin/python
<ogra> # -*- coding: UTF-8 -*-
<ogra> thats what i use
<zyga_> mvo: call setlocale(LC_ALL, "")
<mvo> ogra: thanks, my problem happens inside the C extension
<zyga_> mvo: that will set the locale according to the environment
<jamesh> mvo: the unicode->string conversion always defaults to ASCII, if that's what you're wondering
<ogra> mvo, oh, k
<pitti> ogra: isn't that the encoding of the *source* file, not the locale?
<jamesh> mvo: locale.setlocale() calls the C setlocale() function
<jamesh> without it, things default to the legacy "C" locale
<ogra> pitti, it encodes the strings i use just fine normally...
<ogra> indeed its the encoding of the source...
<mvo> thanks jamesh and zyga_, I think that where the missing pieces
* mvo tests now
<mvo> yes, that looks pretty good now :) is there a convenient way to convert between utf8 and pythons ucs-2 (other than iconv)?
<fabbione> Riddell: that works :) thanks
<Robot101> mvo: python string objects have an encode() method
<mvo> Robot101: in the C-API as well?
<Robot101> well if you have a python string object, you can just make a python method call on it
<mvo> hm, I get the data from a external source (in utf8) and want to make it availabe inside python 
<jamesh> mvo: PyUnicode_Encode() is the C API version
<mjr> http://evanjones.ca/python-utf8.html
<mjr> ah, C interfacing
<mvo> thanks jamesh 
<mjr> didn't read too much upward
<mvo> mjr: yeah, but I think PyUnicode_Encode() will do what I need
<mjr> probably
<HiddenWolf> mvo, working on rad things again? :)
<mvo> in fact PyUnicode_DecodeUTF8() ... yeah!
<mvo> HiddenWolf: teching python apt about translated package descriptions
<HiddenWolf> python apt?
<HiddenWolf> mvo, rewriting apt?
<mvo> HiddenWolf: no, "only" python bindings for libapt 
<sivang> HiddenWolf: they are very nice, you can really have nice control over apt and packages form python-apt
<HiddenWolf> sivang, of course it's nice, mvo is writing it. :)
<sivang> HiddenWolf: yes :)
* mvo blushes
<HiddenWolf> :)
<HiddenWolf> mvo, tell me now, will dapper have autopackage? 
<ogra> ARGH
<ogra> he said the bad word !!!
<HiddenWolf> ogra, there /is/ a BOF about it...
<ogra> yes, anybody has requested it, very sad
<HiddenWolf> I'd hate to see it happen, but that wiki page is making me nervous. :P
<ogra> so we'll have to waste time *again* 
<mvo> haha
<sivang> don't kill the messanger :) I just registered most of the BOF suggestions I saw on the wiki :)
<HiddenWolf> ogra, well, to a certain piont autopackage has a market,  I wouldn't want to bug motu to package some adult entertainment software.. ;)
<HiddenWolf> *wink*
<ogra> lol
<sivang> might help us when we want to support all those "enterprise" grade software :)
<zyga> yay for web based software click n run
<sivang> In that sense, it's not completely bull :)
<sivang> ogra: has it been discussed already on UDU ?
<zyga> you take someone's computer, you click and run 
<ogra> sivang, it has been discussed at UDU, in the -devel ML and we have a clear statement that we cant and wont support it if it doesnt undergo heavy architectural changes... read the thread on -devel
<ogra> )or read joeyh's blog posts about it :) )
<sivang> ogra: ah :)
<sivang> ogra: well, I don't suppose all of the suggested ideas will be discussed, someone will probably do a perliminary screening for the ideas that will be discussed :)
<ogra> hopefully
<HiddenWolf> and what about killing synaptic? :)
<sivang> HiddenWolf: huh??
<zyga> HiddenWolf: get real
* HiddenWolf pokes the hornets nest
<ogra> HiddenWolf, thats really easy
<HiddenWolf> sivang, syga, https://wiki.ubuntu.com/SoftwareManager
<ogra> HiddenWolf, open synaptic, open a terminal... run sudo pkill synaptic ;)
<HiddenWolf> ogra, ;)
<zyga> lol
<zyga> HiddenWolf: you could put that to cron too
<mvo> HiddenWolf: see, what ogra said :) 
<ogra> not worth the time for a BOF :) or making mvo joblless
<sivang> HiddenWolf: why do you want to kill synaptic? it helps me so much with newbies :)
<HiddenWolf> sivang, I don't want to, but there is a BOF suggesting it, and it's not totally clueless. :)
* zyga thinks that 2 programs are really required
<zyga> 1 - full blown package manager, for the people that want total control
<mvo> HiddenWolf: is that part of the autopackage bof? or a differnent one?
<zyga> and synaptic is just that
<zyga> 2 - a nice, add/remove/update too
<HiddenWolf> mvo, see the link above
<zyga> and we don't have that yet
* mvo thinks it could even be a bit more full and blown
<zyga> mvo: what would you add?
* HiddenWolf would love more blown. :)
* zyga thinks where to stick l10n upgrades if they come to life
<mvo> zyga: automatic dependency managment (i.e. removal of automaticially installed dependencies when they are no longer needed) is IMHO the biggest missing thing
<zyga> mvo: hmm
<zyga> mvo: deborphan and aptitude
<mvo> HiddenWolf: oh, the software-manager one. I need to read that
<HiddenWolf> deborphan is sweet.
<mvo> zyga: yes, but having it in synaptic (in e.g. no-longer-needed or something) would be nice IMHO
<zyga> mvo: offtopic, does update-manager (or rather gnome-software-preferences) allow to easily restore default repos and upgrade to new repos without touching the terminal?
<mvo> zyga: upgrade to new repos, yes. restore no, but a nice idea
<zyga> mvo: how about getting that svn to bzr and putting it back to life? :)
<zyga> mvo: do you think that update-manager should be only an upgrade tool or should it also integrate with gnome-app-install
* zyga thinks that automatic popups could be hell 
<zyga> (from the https://wiki.ubuntu.com/SoftwareManager)
<zyga> imagine another user, Pavel
<zyga> Pavel doesn't speak english ;-)
<mvo> zyga: I think they should be two different apps
<zyga> Ubunt 6.04 has this new feature, warining users about programs with security updates
* Diziet restarts two firefox builds.  Damn.
<sivang> infinity: what's that magic you do that when you create a new spec on the wiki, it already gets the SpecTemplates content for "subclassing" ?
<zyga> unfortunatly (*g*) Ubuntu 6.04 integrated this functionality late in the release cycle and few translations are provided
<sivang> infinity: s/subclassing/instantiating/
<Treenaks> zyga: 6.04 will be released next April, 5.04 already had that function
<sivang> zyga: 6.04 ?
<zyga> Pavel constantly sees popup windows when he is trying to run his applications
<mvo> hm, is it too late now for new specs?
<zyga> hmm?
<sivang> mvo: I hope not
<sivang> (still got a couple to straight out)
<zyga> I'm talking about the stuff in Outstanding Issues
<zyga> Treenaks, sivang: I'm talking about different stuff
<sivang> zyga: ah , ko
* mvo needs to do a bit of house-work now, bbl
<infinity> sivang : Go to wiki.ubuntu.com/MyNewSpecThatDoesntExist, pick the SpecTemplate from the list of templates on the left.
<bddebian> Hello
<sivang> infinity: thank you :)
<sivang> infinity: btw, given our discussion from yesterday I think I'm gonna rewrite some of the Snapshots spec - e.g., do in incremental bulk backup of /etc, /var and possibly /usr and /top, combine this with package selection delta over seeds to produce a snapshot.
<sivang> infinity: seem easier to deliver, what do you think?
<Seveas> Znarl, ping?
<fabbione> who is Dennis Kaardrmaker?
<fabbione> Kaarsemaker even
<bddebian> No idea
<Kamion> fabbione: Seveas
<fabbione> ok
<fabbione> Kamion: ah ok thanks
<fabbione> Seveas: please keep 1642 open...
<fabbione> Seveas: i am proud of that bug :)
<Seveas> fabbione, hehe, resolved is not closed ;)
<fabbione> Seveas: please leave it open :)
<fabbione> it's a nice spot in the middle of the mess of all the others :)
<Seveas> hehe :)
<fabbione> ok
<fabbione> time to take my wife out for dinner
<fabbione> cya tomorrow
<Seveas> have fun
<fabbione> thanks
* Seveas silently closes the bug again
<Seveas> ;)
* fabbione crossburns Sepheebear 
<fabbione> ops
<fabbione> wrong tab
<Seveas> :)
* fabbione crossburns Seveas 
<fabbione> ;)
<fabbione> later
* fabbione &
<Seveas> fg
<Seveas> hmm, doesn't work :)
<Treenaks> file a bug
<fabbione> you are not on the same tty
<fabbione> :P
<sivang> Seveas: what is that bug about ? :)
<Seveas> read it, it's a fabbiones fanboy ;)
<Seveas> I was on a close-all-old-bugs spree
<Seveas> (which stopped quite soon after i started, had other things to do)
<sivang> lol
<jbailey> Nafallo_away: Changes which key?
<jbailey> Nafallo_away: Oh, the bzr archive?  A bunch of #lp folks were unhappy that the archive wasn't signed.  So I generated a new key with no password so that it can be automatically signed.
<jbailey> Nafallo_away: I'm not happy with the solution, but it should be consistant.
<wired_> Hi all
<bddebian> Hello wired_ 
<HiddenWolf> Kamion, who are the ubuntu server admins?
<wired_> I am experiencing strange problem in Breezy. When I try to restart my laptop (Satellite A20), it get's to the point where it says "umount: tmpfs busy" and then the system just hangs. I didn't have this problem in Hoary. I would really appreciate some help with this issue. Thanks.
<Lathiat> HiddenWolf: znarl, elmo i think
<Lathiat> wired_: wrong channel, this channel is for development discussion only, try #ubuntu-users, the mailing list (http://lists.ubuntu.com/lists/ubuntu-users/) 
<Lathiat> wired_: oops, #ubuntu
<wired_> ok, no problem
<HiddenWolf> Znarl, elmo, hearing reports of archives being down on #ubuntu
<Lathiat> man
<Lathiat> i could sit in #ubuntu all day long
<Lathiat> i suppose its better than sitting around installing gentoo for the hell of it
<bddebian> Heh
<Lathiat> (i'd never used gentoo, so decided to install it once just to try it out, like everything :)
<Lathiat> i could never run this
<Lathiat> takes far too long to install stuff
<Lathiat> i could install ubuntu on 100 machines by the time i get X compiled
<bddebian> But you'll be l33t ;-P
<Lathiat> ahah
<Lathiat> yeh
<Kamion> HiddenWolf: why is it that joining makes people assume you're actually in front of your computer rather than in bed with a headache while your client autorejoins, anyway? :-P
<Lathiat> Kamion: haha
* bddebian hands Kamion some aspirin
<HiddenWolf> Kamion, because most people are behind their pc's when they're online
* jdub spanks Kamion 
<bddebian> heh
<HiddenWolf> jdub, rock on with the blogpost.
<jdub> HiddenWolf: my irc client is always connected. i'm not.
* Lathiat is the same
<Kamion> HiddenWolf: anyone paying much attention to this channel would realise there are an enormous number of people who are just connected the whole time
<Kamion> seriously, don't ever assume people are around just because they randomly join :)
<jdub> man, i am not the #1 hit for "ubuntu site:au"
<HiddenWolf> Kamion, it's saturday night, i've had a few, allow me the slack. ;)
<jdub> hrm
<jdub> though i guess my blog doesn't count
<jdub> fascists
<HiddenWolf> does anyone know if you can get into an ubuntu install from the install cd?
<HiddenWolf> that avinoam guy is messed up. :(
<Keybuk> you can if you know what you're doing ... but it's far easier from the live cd
<HiddenWolf> he's tried from knoppix, but didn't seem to have worked.
<Kamion> type rescue at the boot prompt
<HiddenWolf> hm, if he gets back i'll advice him that.
<dooglus> archive.ubuntu.com has 4 addresses: 82.211.81.{151,167,182,193} but .193 and .167 don't have "/ubuntu/dists" directories available via HTTP
<HiddenWolf> i've never had to try, ubuntu is rock solid for me.
<Lathiat> HiddenWolf: creepers, its hard to keep track of whos having what problem haha
<HiddenWolf> Lathiat, yeah, #ubuntu is hard.
<HiddenWolf> Lathiat, gotto give Seveas some credit for riding that horse. ;)
<Kamion> dooglus: it's a known common problem at the moment, elmo will make those two servers autosync when he's all caught up again after being off sick. in the meantime znarl/elmo are occasionally manually syncing them
<Lathiat> HiddenWolf: yeh
<Lathiat> HiddenWolf: i used to stick in there a bit
<Lathiat> HiddenWolf: but i found 3 hours later i was still there and it was 4am and i had uni :\
<HiddenWolf> Lathiat, I know the feeling. :)
<dooglus> Kamion: I don't think the problem is that they aren't synced - rather they don't have the "ubuntu/dists" directory available at all.
<HiddenWolf> dooglus, elmo or Znarl need to know. :)
<dooglus> do they have email addresses?  or how would they like to be told?
<\sh> dooglus: james at ubuntu.com -> elmo
<dooglus> \sh: thanks.  should I email him about this?
<\sh> dooglus: when it is an error..sure
<Kamion> dooglus: nope, I just checked and /ubuntu/dists/ is available on all four servers
<Lathiat> 01:41 <DianWei> /dev/hda2            1692        1757      530145    f  W95 Ext'd (LBA)
<Kamion> dooglus: perhaps you're testing by hand and left out Host: archive.ubuntu.com in the HTTP header; archive.ubuntu.com isn't the default vhost on .167 and .193 I think
<Lathiat> ^^ is that an extended partition ?
<Lathiat> like for the hda5, hda6.. etc?
<Kamion> Lathiat: no
<Lathiat> Kamion: ok thanks
<Kamion> http://www.win.tue.nl/~aeb/partitions/partition_types-1.html, under 0f
<Kamion> Lathiat: oh, oops, misread, it is
<Kamion> extended-INT13 equivalent of 05 which is indeed an extended partition
<Lathiat> Kamion: oh, ok
* Kamion idly kills the PC partition table format
<Lathiat> heh
<Kamion> basically LBA-mapped extended partitions
<dooglus> Kamion: oh, i see :)
<dooglus> Kamion: thanks.
<Lathiat> wow, nice bunch in #ubuntu these days
<Lathiat> everytones like thanking me, etc, used to be a little rouger
<Lathiat> apart from the guy wanting help to write an OCR program to bypass ne of thsoe online image security things:)
<HiddenWolf> Lathiat, lol, you're kidding. :)
<jdub> "I'm downloading the upgrade for breezy badger for k-ubuntu (kubuntu means "I am stupid" in malay language).
<jdub> So, I am sticking to k-ubuntu instead of kubuntu."
<HiddenWolf> lol@jdub
<bddebian> hehe
* HiddenWolf wonders if the name should be changed, or if it's fitting. :P
<Lathiat> lol jdub 
<Lathiat> guys
<Lathiat> how do i make grub re-generate a new menu.lst?
<Lathiat> like, when its been wiped
<HiddenWolf> Lathiat, grub-update
<Lathiat> or update-grub ?
<HiddenWolf> one of the 2 it is
<HiddenWolf> otherwise, dpkg-reconfigure grub perhaps?
<Lathiat> HiddenWolf: yep update-grub was right
<Lathiat> HiddenWolf: asks if you want to createa a new one etc
<HiddenWolf> Lathiat, the wonders of debian. ;)
* HiddenWolf always wondered why it was grub-install and update-grub
<Lathiat> HiddenWolf: update-grub makes magic config files
<Lathiat> HiddenWolf: grub-install is the grub part that installs it
<Lathiat> HiddenWolf: update-grub is good if you change the comment options tooo
<HiddenWolf> Lathiat, i'm quite aware, I just think grub-install should be install-grub
<HiddenWolf> :)
<Lathiat> ohh
<Lathiat> sorry
<Lathiat> HiddenWolf: i get you
<Lathiat> Sun Oct 23 02:58:26 WST 2005
<Lathiat> :)
<Lathiat> time to finish off with this last person and hit the sack i think
<Lathiat> HiddenWolf: told ya ;)
<HiddenWolf> Lathiat, haha, yeah. :)
<HiddenWolf> I'll step in for a bit.
<HiddenWolf> *another* guy that fucked up his /home with permission problems
<Lathiat> HiddenWolf: heh
<HiddenWolf> Lathiat, I have no clue why anyone would want to chmod his ~.basrc
<Lathiat> HiddenWolf: my favourite wone
<Lathiat> hi	someone stuck umsak 755 at the top of their bashrc
<jdong> hmm, OOo 1.1.5, * link with -lhnj_pic and tighten libaltlinuxhyph builddep, why? and what does it take for this to work under Hoary?
<jdong> what provides the hnj_pic lib?
<HiddenWolf> Lathiat, nice. :)
<Lathiat> HiddenWolf: as you can guess, that will cause lots of fun
<Lathiat> HiddenWolf: sicne all files are now '022' :)
<Lathiat> hi	etook me a while to figure that one out
<HiddenWolf> *chuckle*
<wasabi> yay car paid off
<HiddenWolf> How the hell do you set that right? :)
<HiddenWolf> wasabi, is sabdfl paying that well?
<wasabi> im not working for him
<Lathiat> haha
<HiddenWolf> :)
<Lathiat> ok i just learnt a lesson the hard way
<Lathiat>  /boot cant be a logical partition :\
<Lathiat> that or this system had a seriously screwed logical partition or something :)
<HiddenWolf> Lathiat, tell me that wasn't your own pc. :)
<Lathiat> HiddenWolf: no
<Lathiat> some persons
<Lathiat> they used partition magic
<Lathiat> to resize and move stuff around
<Lathiat> made a bit of a mess i think
<Lathiat> ate his /boot
<HiddenWolf> omg
<Lathiat> and if /boot can be a logical partition, did something weird to it
<Lathiat> because grub refuse dto install on it
<Lathiat> deleted it
<HiddenWolf> Lathiat, if you can, try to help wpTony?
<Lathiat> made a new primary one
<Lathiat> and it worked
<Lathiat> HiddenWolf: hang a few
<HiddenWolf> Lathiat, told him to chmod/chown his files to the right permissions, but he's keeping the same errors.
<shadeofgrey> Hi everybody.
<shadeofgrey> Just dropping in to respectfully rewquest somebody smarter than me please compile debs for the new op4enoffice stable 2.0 release
<shadeofgrey> please please please
<shadeofgrey> ill grovel if necessary -- i have very little shame.
<shadeofgrey> =)
<HiddenWolf> shadeofgrey, once dapper opens, it'll be backported to breezy
<HiddenWolf> shadeofgrey, we just released, between development at the moment. Probably in a week or so.
<shadeofgrey> HiddenWolf:  Ah.  a week.  okay..  i can wait that long..  just please make sure that the powers that be dont forget. the new 2.0 stable fixes a LOT of bugs
<shadeofgrey> like, bugfixing that would justify tequila
<HiddenWolf> shadeofgrey, you're about the 20th person to ask today, it won't be forgotten. 
<HiddenWolf> shadeofgrey, and the powers that be, dude, buffy is so 1995, ;)
<shadeofgrey> HiddenWolf:  Make it happen, and I swear to god, I'll Fedex you a bottle of Quervo...
<HiddenWolf> shadeofgrey, That desperate? :)
<shadeofgrey> I will push my handicapped ass to the post office and mail a full bottle of Quervo.  I swear to god.
<Lathiat> HiddenWolf: that tonywp dude
<Lathiat> HiddenWolf: let me explain it this way:
<Lathiat> HiddenWolf: 03:36 <wpTony> tony:x:1000:1000:Tony <lastname>,,,:/home:/bin/bash
<HiddenWolf> Lathiat, I thought it'd be something like that.
* HiddenWolf rofls
<Lathiat> HiddenWolf: :)
<Lathiat> i went
<wasabi> Hmm. Wonder if there is some intelligent way to merge two passwd files.
<Lathiat> 'go ls -ald ~'
<Lathiat> then 'ls -lad /home'
<Lathiat> and he goes 'ls -lad ~' sayd .... /home
<Lathiat> and ls -lad /home says the same
<Lathiat> i just went, wah?? :)
* HiddenWolf grins
<HiddenWolf> Sometimes these people just can't read.
<Lathiat> how people get themselves into these situations i will never nknow :)
<HiddenWolf> How you manage to find a hidden file, figure out the cryptic chmod, and mess it up... 
<Lathiat> HiddenWolf: hrm?
<HiddenWolf> Lathiat, he had messed up his .dmrc, right? 
<Lathiat> HiddenWolf: http://bur.st/~lathiat/wptony.log
<HiddenWolf> Oh, My, God.
<Lathiat> uhuh
<HiddenWolf> so that was what he was trying to communicate. ;)
<Lathiat> i just asked if reinstall was an option, otherwise we could be here allnight trying to undo what he did
<Lathiat> he said no :\
<Lathiat> hrm
<Lathiat> HiddenWolf: now $HOME doesnt exist
<Lathiat> when he opens a terminal
<Lathiat> so i guess thats why the .dmrc thing is still a problem
<HiddenWolf> ah, and I was just thinking he'd messed with chmod. 
<Lathiat> i think hes f**ked it good :\
<HiddenWolf> it's one of the most colourful mess-ups i've seen so far.
<shadeofgrey> i dont know anything about half of what ive seen you guys say in the past 40 minutes and even *I* wouldnt do that
<Lathiat> shadeofgrey: lol
<HiddenWolf> shadeofgrey, let's just put it this way, if you don't have an idea what you're doing, do anything but type sudo in front of it.
<shadeofgrey> =)  I guess i shouldnt say that i use a root terminal every day
<Lathiat> lol
<Lathiat> basically
<Lathiat> if your not root
<shadeofgrey> but its true
<Lathiat> you cant do anything to mess the system up
<shadeofgrey> hey... take enough purgocet 10's and just about anything starts to sound like a grand idea
<Lathiat> you can mess up your homedir, etc, but that can easy be fixed by just blwing it away :)
<HiddenWolf> shadeofgrey, do yourself a favor, get rid of the root terminal untill you need it.
<shadeofgrey> ive reinstalled ubuntu 32 times since i started using it
<shadeofgrey> im a master at blowing shit away
<Lathiat> 03:51 <wpTony> drwxrwxrwx 41 tony tony 4096 date-time /home/tony
<Lathiat> eheh
<HiddenWolf> Lathiat, oh, my
<wasabi> Oooh PyDev is nice.
<Lathiat> pydev?
<HiddenWolf> shadeofgrey, stop using root, and you'll be much less likely to have to reinstall.
<shadeofgrey> i really wish you smart people would give some more love to the 64bit drivers
<Lathiat> shadeofgrey: smart people dont use 64bit drivers? :P
<HiddenWolf> Lathiat, be nice. :)
<infinity> shadeofgrey : Which 64bit drivers?... My amd64 machine Just Works.
<shadeofgrey> hidden:  Actually, over half of what i know about ubuntu has xome about because im not afraid to mess with crap.  
<shadeofgrey> infinity:  whatevers necessary to view quicktime and realplayer and windows medsia stuff in a browser window
<wasabi> Those aren't up to any of us smart people.
<HiddenWolf> shadeofgrey, messing is ok, but messing with root can be harmful to the system.
<wasabi> Please ask MS and Apple.
<infinity> shadeofgrey : That's "Not Our Problem"... Those are win32 binary-only codecs you're using.
<HiddenWolf> infinity, those codecs simply are not there for 64 bit
<infinity> shadeofgrey : Yes, obviously.  Note the "32" in "win32"
<shadeofgrey> well..  if thats true then does that mean Tiger uses 32bit Quicktime shit?  Nooooo... But i suppose thgey wouldnt make that freely available hmm?
<wasabi> Exactly.
<infinity> (Yes, some hackery could probably be done to get w32codecs to work with, say, mplayer on amd64, but then powerpc users will complain that it doesn't work for THEM, and that just isn't ever going to work in the slightest)
<shadeofgrey> yeah. either way we screw the ardvark on that one.
<infinity> shadeofgrey : Tiger and Quicktime are both Apple products.  Draw your own conclusions.
<wasabi> infinity, actually, an out of process media player would solve it kinda. ;)
<wasabi> Then you could run that player in qemu!
<wasabi> Err, codec.
<infinity> wasabi : Dude, that's sick.
<wasabi> I know. Isn't it.
<infinity> (And qould be so painfully slow it wouldn't work anyway)
<infinity> s/qould/would/
<wasabi> Think so? I can play windows media pretty well on my Mac in a virtual PC
<wasabi> I mean, given, it's a 1.5ghz.
<wasabi> Still, it's doable.
<infinity> VPC is much faster than qemu.
<wasabi> Oh yes. Certainly.
<shadeofgrey> im a mac user wannabe
<sivang> infinity: VPC ? a new emulator?
<wasabi> Doesn't mean the idea isn't usable.
<sivang> eh, that's microsoft's no?
<infinity> sivang : Virtual PC.  x86-on-powerpc emulator.  Was bought out by Microsoft and is now a generic virtual machine, similar to VMWare.
<infinity> If I can find my CD, I could tell you what Microsoft renamed it to.
<infinity> But I can't be bothered to unzip the binder it's in.
<wasabi> Think it's still called Virtual PC
<infinity> Okay, let me unzip. :)
<shadeofgrey> MSVirtualPC
<wasabi> No!!! Don't Unzip!
<wasabi> Put it away.
<Lathiat> 03:59 <wpTony> are you a religious man/woman?
<Lathiat> 03:59 <Lathiat> no
<Lathiat> 03:59 <wpTony> good....
<Lathiat> 03:59 <wpTony> YOU ARE GOD!!
<infinity> Virtual Server is what I'm thinking of.
<Lathiat> i think that tops todays appreciation list
<sivang> Lathiat: huh?
<Lathiat> (i fixed his problems)
<infinity> But I guess that's a multiple VM deal, meant to compete with VMware GSX... At a guess.
* infinity has never bothered to install it on anything, so is merely guessing based on CD labels.
<sivang> Kamion: is there way to know on an isntalled system, which of the seeds and/or combination of them was used for installation?
<Mithrandir> sivang: apt-cache rdepends | grep ubuntu-, possibly.
<darius_> Anyone familiar with the Atheros 5212 (wifi) problem on HP nc6000 laptop?
<infinity> Which problem is that?
<\sh> darius_: problems with dhcp and wpa-psk (via wpa_supplicant) ?
<\sh> Seveas: yes...but reading a book
<Seveas> \sh, just a quick question
<sivang> Mithrandir: that doesn't give much, doesn't it require a package name?
<Seveas> I'm setting up ubuntu hostname cloaks on freenode, do you want one?
<Seveas> sivang, same question for you
<sivang> Seveas: yes, please :)
<sivang> Seveas: will it work if I connect from different hostnames?
<Seveas> it's linked to your nickname
<sivang> Seveas: cool, thanks
<Seveas> as long as you register before joining channels (use your nickserv pass as server pass) it should work
<sivang> ok
<\sh> Seveas: if you explain to me , how it works...and if it's working with two linked nicks and if unregistered people can send me msgs, then I'm ok with it
<Seveas> \sh, you tell me you want one and ou get one, works with linked nicks and getting messages from unregisterd users works the same as without a cloak (/msg nickserv set unfiltered on)
<\sh> Seveas: possibilty to switch it off for channels I don't want a cloak?
<Seveas> No
<\sh> Seveas: sry if i bother you with those questions...10 years ago, we didn't have those toys ,)
<Seveas> np :)
<Seveas> 10 years ago I didn't even have a computer :)
<sivang> lol
<Seveas> well, maybe 12 years ago (time flies)
<\sh> Seveas: u see, and now u set up cloaks ,)
<Seveas> hahaha, I hack glibc too, that's much more interesting :)
<\sh> Seveas: but u can switch the cloaks off/on as the user likes?
<\sh> Seveas: do it then...
<Seveas> not yet, it's currently a permanent setting. When freenode finally has their new implementation of services (around the 12th of never) that might be dynamic
<Seveas> and switching it off per user now is manual work for both me and freenode administration, so it's not something that's quickly done :)
<sivang> Seveas: wow, hacking glibc sounds complicated :)
<Seveas> sivang, the word is boring
<\sh> Seveas: do it then...
<Seveas> a test-build takes 25 minutes on the fastest machine I have
<Seveas> \sh, k
<sivang> Seveas: man, why do you do it then?
<Seveas> work :)
<Seveas> I'm actually trying to pull everything my colleagues put in glibc out of it and use LD_PRELOAD 
<\sh> .oO(and i will have a look over the source of the irc implementation of freenodes ircd)
<sivang> Seveas: you work for someone paying to hack glibc? actually sounds pretty cool
<Seveas> sivang, university research :)
<\sh> sivang: redhat pays for hacking gnu c stuff and glibc ,)
<sivang> Seveas: better! no boss, tight schedules ,etc :)
<Seveas> (read: think up something funky, implement it in the weirdest way and pay someone else (me) to solve your probs)
<sivang> \sh: right, actualy I think they also pay for hacking on GNOME no?
<Seveas> hehe, you'd think...
<Seveas> sivang, yes, they are sponsoring gnome
<\sh> sivang: for sure..:) 
<sivang> I really think we should be greatful to them, they have given us alot of what we have today
<\sh> sivang: and they have a CEO which sits at the same lunch table as steve ballmer...
<sivang> \sh: oohhh??
<\sh> sivang: sometimes ,)
<sivang> lol
<sivang> anyway, back to spec's work :)
<Seveas> (y)
<\sh> Seveas: do u know what is the user mode +6 now on freenode?
<Seveas> that's for the unfiltered thing
<Seveas> but you can't manipulate it with /umode -6
<\sh> ah..ok...so set unfiltered on sets mode \sh +6
<Seveas> yeah
<\sh> Seveas: and for cloaks to work now, after u set them up, we have to reconnect or is it changing while the user is connected?
<\sh> bah..I should read the FMs of freenode...
<Seveas> you need to reconnect
<Seveas> I don't mind being an interactive FM :)
<\sh> instead of reading lotr
<\sh> for the 10th time
* Seveas never read it
<\sh> Seveas: u should :) and Kings "The Stand" (the new revision)
<Seveas> I like programming more than reading
<\sh> Seveas: ok...matrix the comic is also ok ;)
<Seveas> I programmed a simple deb repository script last week just to get to know how these things work
<Seveas> so much more fun than reading :)
<\sh> Seveas: bah...without reading you can't actually feel, why marvin is so depressed sometimes :)
<Seveas> marvin the martian?
<\sh> Seveas: marvin, the robot
<sivang> \sh++
<\sh> Seveas: hitch hiker's guide ,-)
<Seveas> ah
<Seveas> (never read that one either, but planning to)
<Seveas> I have it on audio :)
<sivang> \sh: I have the "Ultimate Hitchhicker's Guide to the Galaxy" here, with hard cover and includes "Mostly Harmless"
#ubuntu-devel 2005-10-28
<sivang> \sh: I am also getting Dirk Gently's "Long, Dark tea hour of the sould" together with "Salmons of Doubt"
<sivang> s/sould/soul/
<\sh> sivang: i have the 4 parts of the guide in german+english..the dirk gently books (only in german :()
<sivang> \sh: :-)
<sivang> \sh: I've never heared a dirk gently's yet
<sivang> \sh: s/heared/read/
<sivang> \sh: the hour does it's work on me :)
<\sh> sivang: actually dirk gently more fun to read...when u read that odin is laying in a bed of an asylum.and that all the time an eagle is hunting down dirk gently...
<\sh> sivang: totally weired...but funny...
<sivang> \sh: so it sounds :) I'm really looking forward to getting it 
<\sh> I think i change now to bed..and starting up the other laptop
<kbrooks> so. hi
<sivang> \sh: wow, you're continuing from bed with the laptop? when do you sleep?
<sivang> hey kbrooks 
<\sh> sivang: i just slept 15h since yesterday
<sivang> \sh: wow, had lots of work with the transitions over work?
<\sh> sivang: the planning is quite a lot of work..but the last days I was even during night at work...and today as well...
<\sh> sivang: i'm just happy that my holiday starts on thursday...and on saturday I'm sitting in the plane to ubz..
<sivang> \sh: same here :)
<kbrooks> ubz? ubuntu below zero?
<\sh> yepp
<sivang> \sh: when we started rolling the project at work, we worked almost 13-16 hours a day, it was a pain
<\sh> sivang: i
<\sh> sivang: i'm preparing some new packages for pykde in the meantime and play with bzr
<sivang> \sh: cool, I should start playing with it as well
<sivang> \sh: is it much different in its interface then baz?
<sivang> (I've heared it has memory and speed improvements)
<\sh> sivang: to be honest...i think i only played with tla once...for a short time...and i'm new to this baz/bzr/tla stuff ... i'll need a short, intensive jblack sprint at ubz for those tools :)
<\sh> sivang: to have an overview (also regarding the LP stuff)
<sivang> \sh: when you do, pull me in ok? I'd need that as well. I've only used baz for mostly RO operations, so it'd be nice to have this session with him :)
<\sh> sivang: i think a beer coaster will do as whiteboard replacement ;)
<sivang> \sh: hahah
<sivang> \sh: too bad I don't really drink, with all this talking about beer etc :)
<\sh> sivang: well...there is no need to drink alcohol at all :) but a beer coaster is a must to write some phonenumbers or use it for brainstorming sessions while u r sitting in a pub ,)
<sivang> \sh: this is the piece of wood/paper you put the beer glass on ?
<\sh> sivang: yepp paper :)
<sivang> \sh: ah so now I know what you meant by "coaster"
<sivang> \sh: :)
<sivang> \sh: can you conduct an intense packaging session for me over ubz? (guessing you're to packaging, like jblack is to bzr) :-)
<sivang> \sh: rather, a sprint
<\sh> sivang: i think thats possible
<\sh> ok..will change my place from desk to bed ,)
<sivang> \sh: sure, btw I'll appriciate it :)
<sivang> \sh: maybe we can come up with imroving your package-source-from-scratch wiki page
<\sh> sivang: oh..sure..yes...remove the whole wiki page and rewrite now after having more experience *eg*
<sivang> \sh: :)
<\sh> sivang: thats my plan...
<\sh> k...switching location
<sivang> nite all
<Seveas> nite
<Riddell> jdub: you don't want to know what it means in portugese
<jdub> wait
<jdub> no
<jdub> really, i do
<Seveas> Riddell/jdub: I'm setting up hostname cloaks on freenode. Do you want one?
<crimsun> you're the group contact?
<Riddell> Seveas: I already have a KDE one
<Seveas> crimsun, yes
<Seveas> Riddell, you can choose (and maybe even combine)
<jdub> Seveas: i am ok, thanks
<ajmitch> afternoon 
<crimsun> hi ajmitch 
<bddebian> Heya ajmitch, crimsun 
<crimsun> hey bddebian 
<jody_lap> The version of gnumeric in breezy is broken.  Unfortunately the 1.6.0 version missed inclusion by a few days, and 1.5.90 has a crasher that's hitting alot of users.  Is it possible to get an update with 1.6.0 pushed ?
<pupil> Hi guys,. I want to utilize pxe boot or etherboot for a wireless card ( DWL-G510 Wireless Adapter)  I am not sure how to go about doing this
<_maydayjay_> pupil - PXE only working on wired from the looks of all the info in the wiki....probably should ask this on #ubuntu
<pupil> _maydayjay_, I was hoping to add madwifi to the sources somehow to add my card to the probe .
<pupil> _maydayjay_, well not all of madwifi,. but support for my wireless card.. I'm not sure how I'm gonna do it,. cause I need this to boot from hardrive,. so I have enough space.
* Lathiat wonders if its actually psosible to netboot from wireless
<pupil> Lathiat, there would certainly be more configuration, as far as the card goes...
<Lathiat> pupil: i have my doubts as to whether its supported
<Lathiat> pupil: good luck i gues, 
<pupil> Lathiat, I don't think its supported,. but I think I can hack it out
<pupil> Lathiat, my card is supported,. all I need to be able to do is be able to detect and configure it to detect dhcp
<pupil> Lathiat,  there are wireless cards that support wake on lan
<pupil> I'm a little over my head though,. would love some help
<Lathiat> pupil: WoL is totally separate to netbooting
<pupil> Lathiat, right.
<pupil> heh
<pupil> Lathiat, do you think its possible to netboot from wireless adapter?
<Lathiat> pupil: no actual idea
<pupil> hmm
<Lathiat> pupil: try the pxe mailing lists/irc channels or whatever
<_maydayjay_> pupil - if wireless is essential you could use a wireless to ethernet bridge device to get around this.
<pupil> _maydayjay_, what do you mean?
<pupil> _maydayjay_, I don't see how it would solve problem,. because when coputer starts,. ith as to detect wireless card,. first issue.,. then  it has to look for dhcp
<_maydayjay_> pupil - wireless to ethernet bridge is a box that acts as a wireless client and converts the link to a wired ethernet jack - connect that to an ethernet(wired) interface on the computer you are trying to do PXE with.
<pupil> _maydayjay_,  ic,. I found an intersting site .. but I'm unclear as to whether he is booting from wiresless adapter,. 
<pupil> _maydayjay_, http://nlug.org/mail/nlug__2001_04/0338.html
<jayakumar2> _maydayjay_, i have not seen a bios based pxe client that knows about any wifi chip
<pupil> jayakumar2, maybe its time to make one
<pupil> jayakumar2, its not like wireless home network is uncomon
<Amaranth> pupil: good luck with that
<pupil> lol
<Amaranth> pupil: I can see it _maybe_ being possible for intel to do it with their wireless laptop setup
<Amaranth> otherwise you'd need a new bios everytime you got a new card
<jayakumar2> i don't think i've even seen pxe support for usb eth
<_maydayjay_> pupil - LTSP has a wireless package.  You are more than likely going to need to create a bootable CD.
<_maydayjay_> brb
<pupil> Amaranth, all I'm saying is to start you'd have to be able to compile the driver into whatever pxe your using,. and then have a script to set it up
<jayakumar2> Amaranth, i believe most eth chips have a prom that implements the x86 pxe interface (set of inb/outb calls)
<jayakumar2> so i would assume if a wifi chip implemented the same interface
<pupil> _maydayjay_, what do you mean wireless package,.?  you mean boot from wireless card?
<Amaranth> jayakumar2: then couldn't we use that to write a generic driver for all cards?
<jayakumar2> Amaranth, yes, that's correct. pxe clients all use that same generic interface
<pupil> _maydayjay_, yeah,. bootable cd is right
<jayakumar2> that's why pxe can fit in a 256kbit flash for bios
<Amaranth> what does regular network access need that isn't available with the pxe api?
<pupil> could this be the begginings of a new project
<jayakumar2> i don't know. i'd have to check the pxe spec. it should all be in there except it'd be slow since it'd be IO based
<Amaranth> sure, but it'd be better than nothing for cards without real drivers
<jayakumar2> agreed
<_maydayjay_> pupil - here is the announcement about the LTSP wireless support http://sourceforge.net/mailarchive/forum.php?thread_id=686348&forum_id=2543
<pupil> _maydayjay_, thank you
<rockie>  hi you all ,how to recover my gpg key from keyserver
<Amaranth> rockie: If you've lost the private key there is no way to get it back.
<Amaranth> rockie: The private key never goes to the keyserver.
<pupil> _maydayjay_, take a look  http://www.route1.com/
<pupil> _maydayjay_, I went there for an interview...
<rockie> my home direction was deleted 
<rockie> It's mean that I shall re-upload my key again?
<Amaranth> rockie: Unless you made a backup of your key it is lost forever and anything you used it with can't be used anymore until the new key is registered
<Amaranth> rockie: so if you had your key signed by anyone or used it for logins you need to do all of that over again
<Amaranth> rockie: but you can just make a new key and register it with a keyserver again, sure
<pupil> IT CAN BE DONE
<pupil> http://www.freebsddiary.org/wireless-install.php
<pupil> Read em and weep
<rockie> thanks 
<pupil> you guys reading that?
<_maydayjay_> pupil - good find - if it can be done on FreeBSD then it's doable on linux...  Or you could just use the freebsd solution if all you want is a thin client.
<pupil> _maydayjay_, true,. but,. I'm on ubuntu,. maybe a port is possible,. 
<ajmitch> all that appears to show is booting off a floppy, not pxe
<pupil> ajmitch, its a start
<pupil> I'm thinkin boot cd
<ajmitch> like the live cd which does wireless now?
<pupil> ajmitch, well,. i want to do ltsp via wireless
<_maydayjay_> pupil - check http://thinstation.sourceforge.net/wiki/index.php/ThIndex
<pupil> _maydayjay_, yeah,. I see it
<pupil> brb
<pupil> _maydayjay_, the guy release a wireless version,. wow,. 
<_maydayjay_> pupil - #ltsp has a wireless discussion happening ... channel is slow though...
<pupil> I'm on ltsp
<pupil> _maydayjay_, that page you gave me is helpful,.. extremely helpful
<pupil> gonna see how it works
<_maydayjay_> Cool let me know how it works out... I have a situation where it might be useful if performance is acceptable.
<pupil> _maydayjay_,  I'll tell yah,. if it works out on my P133 64mb edo ram,. I think you'll be ok,. I already have thin client working well on etherboot,. time to see how it does on wireless
<Lathiat> it depends how many clients you want to have...
<Lathiat> and whether its 11b or 11g
<Lathiat> overall i dont think itd be crash hot tho
<pupil> the guy that created ltsp is coming to my city,. Toronto, Canda, for tomorrow and Monday
<pupil> He's giving a lecture on it
<pupil> at a college
<_maydayjay_> pupil - I'm in Burlinton, Ont...not to far from TO.  Where is the lecture?
<pupil> Seneca college
<_maydayjay_> Free admission?
<pupil> I'm not sure, He did not indicate that it cost anything
<pupil> I will check seneca's site
<_maydayjay_> Thx...
<pupil> http://cs.senecac.on.ca/soss/2005/speakers.php
<pupil> _maydayjay_,  wow,. this dude spent like 5 dedicated hours with me on each day,.. 3 days in a row,. 
<pupil> so 15 hours
<pupil> or close to that
<_maydayjay_> Looks like a great conference...I'll see if I can get the time off work to attend some of it.  Thanks for the info!
<pupil> _maydayjay_,  no probs
<pupil> Seneca is stepping up it seems
<_maydayjay_> Sure does...glad to see opensource getting the attention it deserves in the Canadian Education system!
<_maydayjay_> brb
<Amaranth> goodnight all
<jsgotangco> hi all
<Treenaks> morning jsgotangco 
<ajmitch> hi jsgotangco, Treenaks 
<Treenaks> *yaawn*
<Treenaks> 8:00 and already up for 3 hours
<fabbione> Treenaks: welcome to the club :)
<Treenaks> fabbione: dude, it's Sunday
<Treenaks> and I've been hacking python-gst stuff
<jsgotangco> heh
<fabbione> Treenaks: i am trying to get 2.6.14 to build...
<Treenaks> fabbione: is it so broken?
<[Chameleon] > Treenaks: bummer... jahshaka requires QT3
<fabbione> Treenaks: not at all..
<fabbione> Treenaks: just cleaning up bits
<Treenaks> so when dapper opens we'll have LOADS of new crack :)
<Treenaks> seb had a new rhythmbox ready as well
<[Chameleon] > mmm crack
<jsgotangco> that would be fun indeed
* [Chameleon]  is really enjoying the composite crack
<Treenaks> ooh, yes, that too
<[Chameleon] > I got it setup to fade in/out windows
<[Chameleon] > freaking awesome
<Treenaks> [Chameleon] : fading windows? that sounds MovieOS, talk to ogra ;)
<[Chameleon] > Treenaks: yeah
<[Chameleon] > Treenaks: across dual monitors
<[Chameleon] > it's so sexy
<[Chameleon] > all my menus fade in/out when I access them, too
<[Chameleon] > even the tool tips fade
<crimsun> fabbione: excellent, that means we can kill lots of the alsa dpatches :-)
<fabbione> crimsun: they are all gone already
<crimsun> fabbione: righto
<Treenaks> Is there/has there been any work on unifying/fixing the WiFi drivers?
<Treenaks> As mentioned in some post I read linked from planet gnome (re: networkmanager)
<jsgotangco> brb
<nnonix> I'm thinking of filing a big report for network-manager (which would be my first bug report) and wondered if someone (familiar with network-manager) here might want to check my logic before I do so? I've had no real feedback from ppl in #Ubuntu.
<nnonix> er, that's BUG report ...
<LaschW> Does bug 17302 mean that fglrx isn't working at all for breezy? 
<Treenaks> it works..ish
<Treenaks> and I have a PCIE X700
<LaschW> Here all my ATI 9100 (r200) cards freeze the system since there is a new fglrx module. And it is reproducable for a lot of other ATI Cards
<LaschW> This is very poor due to the fact that fglrx worked fine with the older fglrx modules. 
<bob2> doesn't X come with Free accelerated drivers for 9100s, anyway?
<LaschW> bob2: :-/ accelerated? I would call it slowerated, 3D accelleration is more than poor
<bob2> ok then!
<LaschW> I can't get even one ATI AGP card working with fglrx. (9100 to 9800)
<LaschW> bob2: And a propper 3d accelleration is a must for CAD/CAM
<LaschW> And up to now I can't finde even one who get an ATI AGP card working with fglrx
<LaschW> So breezy had working fglrx modules in the past, will ubuuntu a) remove the nonworking fglrx or b) bring back the working fglrx modules
<LaschW> In the moment this fglrx problem is a nogo criteria for an OEM to use breezy
<Treenaks> LaschW: fglrx is not supported, and ATi breaks it every once in a while..
<Treenaks> LaschW: complain there
<LaschW> Treenaks: No I dwon't. Thare was a working fglrx in breezy in the past and it's Ubuntu to bring this back. Or, as I said, we (an OEM) will drop Ubuntu 
<LaschW> Treenaks: And I will bet most other OEM's will do so...
<LaschW> Treenaks: s/dwon't. Thare/won't. There/
* sivang --> attached
<sivang> Morning all
<Treenaks> LaschW: That one was broken in lots of other interesting ways for other people
<Treenaks> LaschW: The problem with the fglrx driver is that it's closed-source (for the most part) and written by ATi, not by us. We do test, and you had the opportunity to test during the release cycle
<LaschW> Treenaks: I won't say so. It was working for most all ATI cards in the past. Up to now it is only working for a few PCIE cards.
<Treenaks> LaschW: Well, explain your problem better in the bug then
<Treenaks> LaschW: it might get fixed
<LaschW> Treenaks: I'm not talking about closed source. I'm talking about bringing back the working fglrx modules!
<Treenaks> LaschW: Those were broken for (for example) me
<LaschW> Treenaks: There is a bug 17302
<Treenaks> LaschW: Add a comment to it that you're experiencing it too, and why you feel the severity should be higher than it currently is
<LaschW> Treenaks: And I don't think you have tested it on such a variet5y of cards than we have...
<bob2> come on folks
<bob2> whinging on irc does not fix anything
<Treenaks> LaschW: I haven't, the laptop team has.
<bob2> the bug is filed, people will look at it
<LaschW> bob2: I'm not whinging. I just lay my finger in an open wound. Which as I've said is a nogoi criteria for at least one OEM. Only a small one (turnover 230M EUR in 2004)
<LaschW> If hwdb.ubuntu.com would be online you might have received a lot of complains.
<LaschW> hwdb.ubuntu.com is in 'maintainance mode' since weeks
<infinity> LaschW : The current fglrx drivers are the very first version ever that have worked on my hardware.
<infinity> LaschW : That said, dapper will open with a shiny new fglrx version that is expected to work much better for everyone.  No, breezy won't get them.
<LaschW> infinity: PCIE cards I would think?
<LaschW> infinity: From an OEM's point of view it would be very helpfull if something like hwdb.ubuntu.com would be online to verify which cards are working and which not.
<LaschW> infinity: Also from a users point of view
<Treenaks> LaschW: Ubuntu is not only about OEMs
<bob2> ogra: what's up with the hwdb site?
<LaschW> bob2: Its in maintainance mode, since breezy release
<infinity> LaschW : I'm fairly sure bob2 can read, however he's asking the man responsible for it.
<LaschW> Treenaks: So Ubuntu is not interested in OEM's shiping pre installed systems? Good to know, thanks a lot... 
<bob2> LaschW: stop it, no one is saying that
<infinity> LaschW : Anyhow, the above comment was correct, it's a closed driver and I can't do much of anything about it.  I'm sorry that it seems to be broken for SOME people, but it seems to work quite well for many others, and I can't find a magical version that works for everyone, cause there isn't one.
<LaschW> Treenaks: Pardon me for beeing sarcastic...
<ajmitch> LaschW: going from 'not only OEMs' to 'ubuntu doesn't care' is a big jump ;P 
<infinity> LaschW : Note that we expect most OEMs would be shipping with the "ati" and "nv" drivers, not "fglrx" and "nvidia".
<infinity> LaschW : The free drivers, though lacking in the acceleration department, DO work.
<infinity> LaschW : The non-free drivers work for some people, sometimes, but never for everyone.
<LaschW> ajmitch: Apologize, see it as a sarcastic comment
<ajmitch> I would think that an OEM would be able to select & use the driver they wanted to?
<LaschW> infinity: Shure, but tell that a customer... 
<LaschW> ajmitch: We are able to do so, but our customers don't. And for us it's a must that also a customer is able to install the needed packages. We did so for RH and SUSE. And so there are only this distributions wich stay as candidates for a shipping of pree installed systems.
<infinity> I could trivially prepare some updated packages for testing, which you could distribute, but they'd get ZERO support from us (as we're not putting a newer fglrx into the breezy repository)
<LaschW> infinity: What about the idea to have a repository where a customer may find a set of different module versions? (just an idea comming in my mind)
<bob2> you're welcome to create such a repository
<infinity> Indeed.
<zyga> hmm
* zyga just recalled that fglrx for amd64 is broken
<LaschW> infinity: E.G a repository where one can get the old breezy and fglrx modules?
<infinity> As a rule, we'd expect OEMs to show a bit of initiative with driver issues like this.
<infinity> Microsoft doesn't press new Windows CDs for you with new driver support on them.
<Seveas> Microsoft and driver 'support'....
<Seveas> looks funny in one sentence
<LaschW> bob2: :-)) If I only had access on a repository where all the old packages lay around. There is no archive I've found up to now...
<ajmitch> especially as new hardware comes out that isn't supported by the current stable distribution
<zyga> LaschW: what about the morgue?
<LaschW> zyga: morgue? tell me more
<zyga> LaschW: http://morgue.ubuntu.com/
<zyga> if that is what you are looking for 
<infinity> That's not really going to work for you anyway.
<zyga> oh, it's quite emtpy
<bob2> are you really willing to tell your customers "oh, it doesn't work? try installing each of the ten drivers on blah.com and see which works"
<infinity> If you try to set your users up to use older packages, they'll just get upgraded the first time they do an online update.
<zyga> LaschW: are you having issues with fglrx?
<LaschW> bob2: No. Our sitiuation is a bit more complex. We are a b2b manufacturer for what we call "After Work resellers", very small computer shops. And this customers need working systems, and 3D accelleration is a big momentum for this people
<LaschW> zyga: Yepp
<zyga> LaschW: did you try the latest version straight from ati?
<LaschW> zyga: *grrmmbl* Yes I did. Never seen such a crap before...
<zyga> LaschW: (next time buy nvidia)
<zyga> LaschW: anyway you are cooked, as someone has already said - previous versions were buggy too
<LaschW> zyga: Ever tried the ATI installer? Try distribution customized install. And you will see an error about not able to find /lib/linux386/lib$FOO
<LaschW> zyga: Seems ATI guys never even startet their own installer. As I said crap..
<zyga> LaschW: I never tried the ati installer, I did try to use some prepackaged drivers in my fedora 1 days but that was long time ago
<zyga> mvo: morning
<ajmitch> hi mvo 
<zyga> WaterSevenUb: hi :-)
<LaschW> zyga: Right, RH fedora and SUSE packages are working. At least yesterday... So thats what makes me go up the trees...
<WaterSevenUb> zyga, hi there:) goodmorning.
<LaschW> zyga: I tried to offer ATI a helping hand making their installer work. But thei wanted me to pay for to do their job....
<zyga> LaschW: are they based (Suse/rh/fedora) on the latest version? 
<LaschW> zyga: Yepp, as far as I saw
<zyga> LaschW: then there is something magical about them - you've said that the lastest drivers from ati are not working
* zyga needs to go to work
<zyga> LaschW: good luck with solving your issues
<LaschW> the new ATI installer is not bad, on the first look. It offers to build deb packages. But isn't able due to do so due to wrong path definitions.
<sivang> morning mvo, zyga, ajmitch, infinity, Seveas 
<mvo> hey zyga, ajmitch 
<LaschW> zyga: At least the last fglrx drivers dont work for 8500 to 9800 agp on boards with Via, nvidia and intel chipset
<Seveas> oi sivang 
<zyga> sivang: morning :-)
* zyga needs an IRC client that displays message like 'you've been starring at this window for the last 5 minutes, get back to work!'
<sivang> interesting note from someone we know about spec ,) http://kerneltrap.org/node/5725
<sivang> s/spec/specs/
<zyga> sivang: ah, so last week
<\sh> moins
<Seveas> oi
<ajmitch> hey \sh 
<\sh> oh well...i need a life...sleeping next to my laptop is not the meaning of a working relationship...
<zyga> \sh: next time sleep next to your laptop *and* your girlfriend
<\sh> i mean, ok the laptop is warm and doesn't snorr, but I prefere a more softer version of someone in my bed
<sivang> \sh: hehe, Moins!
<sivang> \sh: at least you slept well?
<\sh> zyga: hmmm..question: if you would be a girlfriend and you see, that your boyfriend has a laptop in his bed...would you sleep next to him? ;)
<zyga> err
<zyga> \sh: mine does
<zyga> \sh: she's got a laopto too BTW ;-)
<zyga> (sometimes she preres my psp and just dumps the laptop)
<\sh> zyga: damn...I knew I made something wrong in my life ,-)
<zyga> \sh: you should have bought you gf a psp :-)
<\sh> zyga: well....I tried, but sony didn't release the psp just in time...so now I could buy a psp, but I don't know a place for buying a gf *eg*
<\sh> sivang: somehow yes...right now I'm prepared for long ubz sessions :)
<zyga> \sh: well, if I were you I'd buy the psp anyway, gf will come along one day
* zyga needs to downgrade psp again
<\sh> zyga: serious...I'm not in this gamers business...the last time I bought a portable gaming device was for my son...and I was too stupid to play with it...
<zyga> \sh: how old are you if I may ask?
<\sh> zyga: in january 35
<WaterSevenUb> mvo, I received an email from a user concerned with Synaptic translations in debian unstable to portuguese... did you talk to him?
<\sh> zyga: an old fart
<zyga> \sh: ever since I bought my first game console I dumped pc gaming, I'm 23 now and after 5 consoles I'm pretty much addicted
<zyga> \sh: nah
<WaterSevenUb> mvo, I think he was using pt_BR instead of pt_PT.
<zyga> \sh: you're very old school ;-)
<WaterSevenUb> mvo, unless there is some problem in debian unstable.
<zyga> \sh: anyway - gameplay is the only way I rest mentally (apart from sleep) really
<mvo> WaterSevenUb: no, I haven't 
* zyga is amazed by httpd for psp :-)
<\sh> zyga: I played some xbox games the last time I was visiting ogra...but I'm having trouble to control those big xbox-controls
<sivang> \sh: what did you prepare?
<zyga> \sh: I have a gamecube and psp currently, both are a marvel
<maswan> \sh: so does most humans. :)
<maswan> \sh: those controllers are huge
* sivang ditched gaming in favor of programming around the age of 10
<zyga> \sh: try a gamecube with your son at a retail store, there are great multiplayer games too
<maswan> http://ps2vsxbox.istheshit.net/
<zyga> \sh: (for kids that is)
<maswan> is the classic illustration of that. :)
<[Chameleon] > \sh: there are smaller xbox controllers available
<zyga> sivang: what!?
* zyga ditched gaminig in favour of learing how to write games in 6th grade
<\sh> sivang: nothing special..but now I slept so long, that I don't need to sleep again ;)
<\sh> zyga: he tried..that's why I bought him 2 or 3 years ago a PS2
<\sh> zyga: and the only game he wanted to play was "Quidditch" and "Fifa Soccer"...
<\sh> games even
<Lathiat> heh quidditch
<zyga> \sh: argh
* zyga plans to show his son adom/nethack as soon as he gets one
<zyga> (son that is)
<zyga> anyone who can appreciate adom is a worthy gamer :-)
<\sh> zyga: adom? this rogue like adv game which is not OSS?
<zyga> \sh: the very same
<zyga> \sh: while it'd be nice for the source to be FOSS it's a good thing it's not IMHO
<zyga> (but that's really offtopic unless we have #ubuntu-fun or #ubuntu-lazy-devel
<\sh> zyga: right
<HiddenWolf> zyga, -offtopic
<HiddenWolf> actually exists
<zyga> :D
<nomed> hi all
<nomed> what the diff. between xterminal and xfce4-termianl?
<[Chameleon] > nomed: try asking in #ubuntu. This is not a support channel.
<nomed> [Chameleon] , i asked here just because i think it's a "bug"
<nomed> take a look on those pkges
<nomed> cu
<[Chameleon] > nomed: what about them do you think is a bug?
<zyga> nomed: apt-get source xterm && apt-get source xfce4-terminal && diff -Naur xterm-203 xfce4-terminal-0.2.4 | less
<[Chameleon] > zyga: hehe
<WaterSevenUb> mvo, have you uploaded translations upstream?
<nomed> zyga, xterminal not xterm
<zyga> nomed: ah, sorry
<nomed> the only diff seems the Maint
<nomed> and the name
<mvo> WaterSevenUb: synaptic translations?
<zyga> nomed: the diff is around 1000 lines
<WaterSevenUb> mvo, yeah
<\sh> nomed: Conflicts: terminal, xterminal
<\sh> nomed: in xfce4-terminal that is...
<nomed> \sh ok
<\sh> nomed: please ask the xfce4 devs ( janimo e.g.)
<spayne> mornin' all
<mvo> WaterSevenUb: I commit everything I get to the synaptic svn
<jayakumar2> infinity, fwiw, i think it's a waste that everyone (users,distro folk, oems, devels) expend so much effort on trying to get 3d gfx support working. all that frustration. rev eng specs. 8k/4k problems. etc
<\sh> ok..laters...need some coffee and something to eat
<WaterSevenUb> mvo, ok... great. 
<zyga> mvo: what changes do you plan to implement in update-manager, if any?
<mvo> zyga: I'm undecided about that, probably some gui cleanups in the software-preferences dialog. the rest will depend on UBZ
<zyga> mvo: I've got three questions for you
<zyga> mvo: would you concider moving from cvs to something else?
<infinity> jayakumar2 : I agree, tell ATI.  Telling me it's a waste of time doesn't do much good.
<zyga> mvo: would you concider adding a apps vs packages tabs to the upgrade list (so that users know about applications that matter the most and about other stuff they might not understand)
<zyga> mvo: if so would you accept a third tab, translations
<zyga> mvo: (OTOH: it would be good to add reddish background on updates from security.*)
<zyga> mvo: we can take this to priv if you like
<mvo> zyga: can we possibly talk about this after ubz? then I have a better idea about what time I can allocate for what task? 
<zyga> mvo: okay
<zyga> mvo: I could implement the tab part
<mvo> in general I like the idea about e.g. having something "redish" for secuirty and telling the user that libxy is "System" and "libopenoffice" belongs to the Openoffic applikation. and that langpack-en-update means, that the translations are updated
<zyga> mvo: I'd need to know how much backend/frontend separation are you planning 
<mvo> but I wouldn't want to do it with tabs most likely
<mvo> zyga: python-apt is getting into good shape, I hope that the backend that installs the packages can be python-apt (instead of synaptic) for the next release
<zyga> mvo: why?
<mvo> zyga: mostly because it makes integration into the app easier
<mvo> and gives more flexibility
<zyga> hmm, I'm not sure I follow
<zyga> (I asked about tabs)
<mvo> oh, tabs
<zyga> I do understand backend separation, it's a good thing
<mvo> tabs get easily confusing. I wonder if we shouldn't just sort the list (e.g. security, apps, translaions)
<zyga> mvo: since I quite disagree I'll prepare some mockups today :-)
<zyga> maybe you will change your mind later :)
<mvo> zyga: feel free, my opinion is not set in stone
<mvo> :)
<zyga> mvo: actually I've got something interesting, I'll make the mockup, write a blog entry about it and send you the link, fine?
* infinity agrees with mvo.
* infinity fanboys mvo.
* zyga still waits for his first fanboy
* mvo blushes
<zyga> mvo: do you know any FOSS artwork source?
<zyga> I'd need a bunch of icons
<infinity> zyga : openclipart.org
<infinity> Which is down right now, cause they were naughty, naughty boys and had a horribly insecure script running in their vhost.
<infinity> But they'll be back soon, I assume.
<zyga> infinity: thanks, good to know
<zyga> hmm
<zyga> there is a bug in mozilla-thunderbird postinst script
<zyga> seems like a typo
<infinity> Which bug is that?
<infinity> The misplacement of "-maxdepth" arguments to find?
<zyga> infinity: yes
<infinity> Which is harmless, but incredibly noisy? :)
<infinity> Will get fixed in dapper, but it's not a problem in breezy, just noisy.
<zyga> infinity: yes :D
<infinity> It doesn't affect functionality.
<zyga> infinity: I've sent a 'screenshot' to my friend I hope to convert
<zyga> infinity: I had to hide in shame and edith that crap away
<infinity> Hah.
<infinity> Yeah, I'm going to do a recursive grep across an entire unpacked source mirror at the beginning of dapper, and try to nail every one of those I can find.
<infinity> I probably should have just removed the error message from find for breezy, but kinda forgot until it was too late.
<infinity> mvo : Oh, while I'm fanboying you, what's up with the rendering bug in update-manager?  (the arrow/text for "show progress of single files" seems to appear twice, overlapped)
<infinity> mvo : I'm fairly sure it has to do with my desktop not being at the default DPI (it goes away when I change DPI to 72), but I also don't see it in other GTK apps, so I'm wondering if maybe you're doing something crazy wrong with positioning..
<zyga> infinity: can you get a screenshot
<infinity> Sure...
<mvo> infinity: I have seen this as well, it seems to be a GtkSocket/GtkPlug problem 
<mvo> but I would need to check that again
<infinity> Right, no need for a screenshot then, if you've seen it. :)
<infinity> Oh well, it's a minor irritation.
<infinity> Wouldn't matter so much if we weren't currently trying to be so clever and setting laptop DPI based on screen size.
<infinity> (ie: If we just did the "dumb windows" thing and set everyone to 72dpi, the problem would be masked)
<infinity> And if my eyesight were better, I'd probably run at 72dpi...
<infinity> But 72dpi on a 15 inch 1400x1050 screen is.. Really small text.
<infinity> And I'm getting old. ;)
<mvo> heh :) 
<mvo> don't be silly ("getting old")
<Lathiat> i thought 96 was the default 
<infinity> Err, yes, of course it is, I'm backwards.
<infinity> Really old, AND bad at math!
<infinity> Or, wait.
<infinity> No.
<infinity> Not bad at math.
<infinity> 72 is the default.
<infinity> 96 may be a default in some interesting corner cases (and it's what my laptop is set to)
<infinity> But most desktops will be at 72.
<HiddenWolf> how does one check? :)
<Lathiat> oh ok
<Lathiat> i didnt knwo that
<Lathiat> both my laptops have been 96
<Lathiat> never used anything else
<Lathiat> altho tghis laptop is _actually_ around 120
<infinity> This may be too.
<infinity> HiddenWolf : It's in font preference, of all non-intuitive things.
<HiddenWolf> 96 for me.
* HiddenWolf checks what dell supports
<Lathiat> kde doesn't seem to have a way of finding it out
<Lathiat> err
<Lathiat> s/finding/changing
<Lathiat> but it does take the X setting
<Lathiat> where as gnome does not
<infinity> Yeah, not sure who's more correct there.
<infinity> With the KDE way, you get the "right" setting, but with GNOME you can actually change it.
<infinity> You can't change X's DPI on the fly.
<Lathiat> it should be the 'right' setting
<Lathiat> but overridable
<infinity> (in fact, xdpyinfo on my laptop claims that X thinks I'm at 75dpi)
<Lathiat> infinity: x _does_ think your at 75dpi
<Lathiat> infinity: gtk/pango does not
<infinity> Yes.  I know.
<infinity> But for now, this is (in my mind) the better solution, hack though it may be, cause X can't change it on the fly.
* zyga runs away
<infinity> When X gets smarter about geometry changes on the fly, GNOME can stop doing it.
<HiddenWolf> screen #0:
<HiddenWolf>   dimensions:    1920x1200 pixels (524x331 millimeters)
<HiddenWolf>   resolution:    93x92 dots per inch
<HiddenWolf> fits with gnome here
<infinity> it does?
<infinity> You said GNOME was at 96.
<HiddenWolf> hm, true.
<HiddenWolf> 72 looks odd, btw. :)
<HiddenWolf> can't find a recomended dpi in the monitor fact sheet.
<infinity> Looks good on my girlfriend's desktop.
<infinity> Not that it makes much different, but I probably meant s/72/75/
<infinity> At  aguess.  I can't see her machine right now to confirm.
<infinity> But 72 is the Win32 default dpi, 75 is X, so I likely confused the two.
<HiddenWolf> infinity, http://www.geocities.com/hiddenwolfsof/Screenshot.png
<infinity> Oh, note that for extra-hilarity, apps that aren't very GNOME-ish (like firefox and tbird) will respect the X dpi.
<infinity> So, you'll get the window manager widgets (titlebar, etc) at the GNOME dpi, but the browser widgets at the X dpi, making them look bigger.
* infinity decides to go attempt a nap after having been up for the last 36 hours.
<mvo> infinity: I hope that for dapper this gtksock/gtkplug buisness goes away, then the wrong error should be go away as well
<jdub> infinity: ber, just read back the dpi discussion
<jdub> infinity: i so want to fix this
<HiddenWolf> jdub, ditching firefox would be good
<HiddenWolf> jdub, :)
<mdke> jdub, planneeeeetttttttt
<jdub> infinity: i figure that even if X is wrong, it tends to have sensible defaults, so we should just trust X instead of mucking around
<jdub> mdke: i'm sure you can understand that elmo has been busy
<mdke> sure i can
<jdub> ahr HUNGRY ahr
<mdke> how is italy jdub ?
<jdub> haven't seen much, been too sick
<mdke> :/
<mdke> get better soon
<Simira> jdub: which day is the Rocky Horror Show-thing in Montreal?
<Simira> I've been told I'm going...
<tseng> Simira: be afraid
<jdub> Simira: um, shush
<sivang> Simira: Rocky Horror Show , Montreal? What's that?
<Simira> sivang: nm, just trying to find out what to do in Montreal, except from bugging Ubuntu-devs
<Simira> sivang: are you going to UBZ?
<sivang> Simira: yes :)
<Simira> sivang: me too. Though I'm planning on touristing a bit as well as working. There's a zoo (with penguins ;) and some interesting museums
<sivang> Simira: nice, if we do get a free moment (which I doubt ;-)) would be interesting to photo some real penguins for Ubuntu artwork 
<Simira> sivang: else, I'm sure you can get some from Tollef, we visited the penguins in Bergen two weeks ago. ;p Lucky for me, I'm not paid or obligated to do more work than I want to (or choose to), which still happens to be more than healthy....
<tseng> jdub: go pia!
<sivang> Simira: :)
<zyga> back :)
<zyga> mvo: re
<zyga> mvo: would you concider moving update-manager from cvs to bzr?
<zyga> mvo: this way we could work easier together
<mantiena> Hi all
<kbrooks> What if I don't want to insert a long description in debian/control (making a ubuntu package)?
<Keybuk> you do
<kbrooks> ?
<Keybuk> you do want to insert it
<tseng> if you dont when you upload it to REVU for inclusion in ubuntu we tell you to go back and add it
<kbrooks> Well, what do I insert if I think it will be too long?
<kbrooks> tseng: i'm not uploading it
<Mithrandir> write it shorter, then
<kbrooks> OK
<\sh> jbailey: what was the sources.list to your daily bzr repos?
<\sh> jbailey: have it  ;)
<mantiena> mdz, hi, are you online?
<trulux> BTW, hibernation on Breezy is working right?
<sivang> trulux: if you're on nvidia, use the FOSS driver or consult HiddenWolf how to make it work with them :)
<\sh> trulux: yes...but I have some problems with the fglrx drivers
<sivang> HiddenWolf: maybe you write a howto about it? I will use it for sure numerous times :-)
<trulux> I'm on vidia, just thought it would really rock if it worked out of the box
<HiddenWolf> sivang, dude, nvidia driver hardlocks my kernel here. :)
<trulux> hah
<trulux> bbl, lunch time
<HiddenWolf> sivang, trulux: apt-get install nvidia-glx linux-restricted-modules-`uname -r` , chance nv to nvidia, and reboot.
<HiddenWolf> change. :)
<trulux> I'm already using nvidia module
<kbrooks> i really need to fully reinstall breezy
<mantiena> Kamion, hi
<mantiena> Kamion, could you answer some questions about http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005/casper/casper--automount/ ?
<sivang> HiddenWolf: I recall you told me a set of steps, that helped me to get all pm working *with* the previous prorierity driver
<HiddenWolf> sivang, i can't remember, but the howto's are there on the wiki already.
<trulux> HiddenWolf: after nvidia gets loaded and used for glx, what's next?
<HiddenWolf> trulux, should work then, I've never gotten to that piont on breezy.
<trulux> HiddenWolf: OK, will check. many thanks
<Keybuk> hmm, tricky decision
<Keybuk> do I wipe and reinstall my laptop before or after UBZ?
<fabbione> Keybuk: before :)
<fabbione> after UBZ you will be tempt to install dapper ;)
<Keybuk> lol, that's a good point
<fabbione> and suffer because it won't
<fabbione> :(
<Keybuk> it's running breezy now, just a crufty install
<fabbione> Keybuk: i am running warty -> hoary -> breezy super hacked install :)
<fabbione> time to reset the counters
<Keybuk> yeah, this one was half way through breezy with a very crufty homedir
<Keybuk> and some things are annoyingly bust (like evo calendars and addressbook)
<Keybuk> my desktop was a unstable -> warty -> hoary -> breezy special
<trulux> HiddenWolf: I don't find the info. on the wiki
<Keybuk> and that got wiped and reinstalled fresh, and it's soooo much nicer
<\sh> Keybuk: install breezy during UBZ ,)
<Keybuk> \sh: I'll be busy during
<HiddenWolf> trulux, what exactly are you looking for?
<Kamion> mantiena: not on a Sunday :-) send me mail
<trulux> HiddenWolf: info on integration and configuration of hibernation stuff
<trulux> ie. KDE entry in the logout menu
<HiddenWolf> trulux, doesn't work, usually.
<\sh> Keybuk: u have the night ;)
* fabbione goes for a banana milk shake
<Keybuk> \sh: the night is for drinking and food and bitching and fun
<\sh> Keybuk: ok ok...you convienced me...do it before ubz
<pmjdebruijn> lo all
<pmjdebruijn> I want my application to also have a Translate This Application in my Help menu, I already added the menu item, but where can I find the associated icon?
<sivang> pmjdebruijn: hmm, how did you add the menu item?
<pmjdebruijn> sivang, uhm, add a menu item and call it Translate This Application
<pmjdebruijn> I didn't add a stock menu item
<TMM> isn't that supposed to be added by gnome-libs or something?
<pmjdebruijn> well I'm not writing native C
<Chipzz> TMM: no, launchpad
<Chipzz> gnome-libs is like ancient
<TMM> oeps :)
<pmjdebruijn> what does launchpad have to do with the menu item?
<HiddenWolf> pmjdebruijn, the menu item pionts people to launchpad/rosetta
<pmjdebruijn> HiddenWolf, yes I know, I already did that
<pmjdebruijn> I just need the icon
<pmjdebruijn> I can't seem to locate it
<sivang> pmjdebruijn: there is a special library we created for this, so you don't need to manually add the items.
<kbrooks> pmjdebruijn: look in /usr/share/pixbufs ?
<sivang> pmjdebruijn: is this a python app ?
<sivang> pmjdebruijn: fetch the source for gedit or gucharmap and see how it's done there. Basically you dynamically link against the launchpad integration library and use it's functions to add everything: items, icons, functionality
<sivang> pmjdebruijn: or look at the source of file-roller if you're app is UIManager
<pmjdebruijn> sivang, no it's a Mono/GTK# app
<zyga> mvo: ping
<pmjdebruijn> sivang, I'm not sure the integration library is going to work with Mono...
<pmjdebruijn> sivang, is there an easy way how I can test this?
<zyga> what is MOM/NDA?
<pmjdebruijn> kbrooks, yay, it's there, lpi-translate.png
<pmjdebruijn> kbrooks, /usr/share/pixmaps
<sivang> zyga: I know that MOM is merge-o-matic 
<kbrooks> pmjdebruijn: :)
<kent> pmjdebruijn, it doesn't seem to work for mono applications. I tried blam and muine and they dont have that translation-stuff.
<zyga> sivang: hmm okay that's a clue
<kbrooks> kent: ^
<kbrooks> everyone: ^ 
<zyga> kbrooks: mono?
<kbrooks> zyga: no
<kbrooks> the icon 
<zyga> kbrooks: what about it?
<kbrooks> /usr/share/pixmaps/lpi-translate.png
* zyga doesn't have it
<zyga> (just running hoary->breezy upgrade though)
* zyga is visiting parents
<kbrooks> lol
<zyga> kbrooks: what's with that icon btw?
<kbrooks> zyga: scroll up
<pmjdebruijn> zyga, i wanted to where it was at
<kbrooks> "
<kbrooks> pmjdebruijn kbrooks, yay, it's there, lpi-translate.png
<kbrooks> pmjdebruijn kbrooks, /usr/share/pixmaps"
<zyga> ok
<TMM> hum, is there a tool to simplify patch merging? 
<zyga> TMM: what do you mean by that?
<TMM> zyga, multiple vi windows with .rej files and the offending c files is beginning to be a tad unproductive ... :)
<zyga> :-)
<zyga> TMM: do it one at a time ;-)
<TMM> perhaps I just need a dualhead setup...
<zyga> TMM: I don't know of anything that helps really
<zyga> TMM: vimdiff is nice to see the changes though
<TMM> :)\
<TMM> I'll just go for dualhead, and I'll look into vimdiff
<TMM> it's just a pretty LARGE patch that is failing
<TMM> one large diff :)
<zyga> TMM: did you ever try vimdiff?
<TMM> no
<TMM> I will now though :)
<zyga> TMM: man, you'll be suprised :>
<TMM> that good, is it?
<TMM> hmm, not in ubuntu :(
<zyga> TMM: it's a symlink to vim
<zyga> TMM: just get vim
<TMM> ow, it's PART of vim :)
<zyga> yes
<TMM> zyga, is it 'just' a diff viewer?
<TMM> ah, it does a tad more
<TMM> nice :)
<TMM> thanks zyga I think this is going to help
<zyga> TMM: plesure
<zyga> TMM: note, vimdiff can do 3-way-diff too :D
<TMM> :)
<zyga> urghh...
<zyga> why is diveintopython in main again?
<zyga> it's not that my mom is going to check an english-only book about programming during her tea time
<Kamion> talk to Mark about that
<zyga> Kamion: thanks
<Kamion> we kind of started with *python* and removed things from there rather than the other way round ;-)
<zyga> Kamion: is that his nickname, he's not around?
<Kamion> zyga: Mark == sabdfl, the boss
<zyga> Kamion: ah
<zyga> sabdfl: ping, hi :)
<Kamion> although he's probably very busy right now with the launchpad/dapper rollout
<zyga> okay
<zyga> Kamion we kind of started with *python* and removed things from there rather than the other way round ;-)
<jordi> does anyone know if thom is on IRC lately?
<zyga> Kamion: ^^ I don't understand that
<zyga> Kamion: Mark, *the* mark?
<TMM> zyga, the big guy
<zyga> geez
<zyga> I've talked to him a couple of times, I never suspected that's him
<zyga> anyway -- ackward nickname
<HiddenWolf> zyga, SABDFL is an acronym
<TMM> zyga, Self Appointed Benevolent Dictator For Life :)
<zyga> hehehe
<zyga> that's appropriate :D
* zyga likes FOSS names a bit
<Kamion> zyga: Mark loves Python, so we slurped about as much python stuff into main as possible right from the start, and trimmed it down after that
<zyga> Kamion: I surely understand 
<zyga> Kamion: but while I do like python too, the geatest linux RAD tool around 
<zyga> Kamion: putting a english only  book into every desktop for clueless users (without any links or menu items)
<zyga> Kamion: where normal users never-ever go outside of /home and /media
<zyga> Kamion: is a waste of space IMHO
<zyga> Kamion: good effort, bad implementation
<Kamion> I value my job rather too much to remove something matching /python/ from desktop without checking first. ;-)
<TMM> Kamion, lol! :D is he THAT passionate? :)
<zyga> Kamion: python-sucks-use-ruby ^^ Depends: Ruby ;-)
<zyga> lol
<zyga> Conflicts: python
<zyga> hehe
<zyga> anyway I'd love to see Mark's point
<sabdfl> TMM: YES!
* TMM hides in horror
* TMM pulls a blanket of his head
<sivang> lol
<zyga> sabdfl: so basically what I don't understand is
<zyga> how is a *anyone* ever going to find out that such a valuable piece of knowledge is installed on his/her system
<sabdfl> good effort, bad implementation? you may have a point. patches welcome
<zyga> unless someone is really reading the package list
* TMM prays the scary spaceguy won't use his raygun
<zyga> or loves to read the upgrade cycle 
<zyga> sabdfl: cool I'll think of something 
<zyga> sabdfl: how about a item in apps->development
<sabdfl> zyga: good idea
<zyga> sabdfl: I'd love to patch this if you back up the effort
<TMM> zyga, sabdfl perhaps add it to the help browser?
<zyga> TMM: no-one check the help browser
<jdub> zyga: we're going to have a BOF about this at UBZ (about the 'ubuntu platform', which will cover python)
<zyga> TMM: everyone is checking the menu
<sabdfl> zyga, TMM: I would very much like to see this stuff taken further during Dapper
<zyga> jdub: UBZ is out of my financial reach
<TMM> zyga, add it to the help browser, and place an icon in the menu to point to the helpbrowser + start point of diveintopython?
<jdub> zyga: also, wrt documentation, there'll be a BOF and continuing work on exposing what already ships with ubuntu (rather than new docs)
<TMM> zyga, it'd be nice to have it in a uniform app, I think?
<zyga> TMM: true, good point
<jdub> install devhelp, make sure it's not already visible
<zyga> TMM: adding a menu item that launches help browser is a good idea
<TMM> jdub, first things first: ARE YOU WEARING PANTS? :D
<jdub> no
<zyga> jdub: hmm
<TMM> euh....
<jdub> zyga: system -> help
<zyga> TMM, jdub: that's yelp - right?
<jdub> but for diveintopython, look at devhelp (i know doko put some python docs in there, but dunno if he made sure DIP was)
<TMM> zyga, yeah
<sivang> jdub: registered in spec tracker / on the wiki ? havn't seen a bof suggestion about it
<zyga> aww
<zyga> offtopic
<zyga> /var/lib/dpkg/info/libgstreamer0.8-0.postinst: line 10:   412 Naruszenie ochrony pamici   GST_REGISTRY=/var/lib/gstreamer/0.8/registry.xml gst-register-0.8 >/dev/null
<zyga> Naruszenie ochrony pamieci == segvfault
<TMM> jdub, but, if it is installed per default, I don't you should have to install a seperate package to actually use/reat it?
<jdub> sivang: jbailey and i looked at the DapperStandardBase BOF, figured that would be a good place to start it
<sivang> jdub: ah cool, figures :)
* zyga wonders if he should still do anything as clearly others picked up the subject
<zyga> (and clearly others seem to have better knowledge of the system and the design)
<TMM> jdub, ow yeah, can you tell me what guy I need to talk to about the gdm stuff again?
<sivang> jdub: sounds like this is going to be on long BOF :)
<zyga> sabdfl: thanks for your time
<jdub> TMM: that's a problem, but one that i think ought to be solved by not installing it by default, really
<Kamion> mm, devhelp would be a nice place for it to go in the long run
<TMM> jdub, be wary of sabdfl's wrath :P
<sivang> zyga: dive into python is also available through "Applications --> PRogramming" in yelp
<Robi-> oh man did I have an episode upgrading..
<jdub> TMM: i'm more wary of user experience
<zyga> sivang: I never run yelp, I didn't even know it's there since most FOSS and win help systems are a laught and many users, me included, have learned to avoid them
<TMM> jdub, good point :)
<TMM> sivang, it is :) great, case closed :P
* zyga disagrees
<Robi-> hoary->breezy, mdadm was installed for some readon and started telling me I had degraded arrays, because somehow my second drive which isn't mounted had an array previously. this of course made me think I installed it as raid, and the error messages led nowhere.
<sivang> zyga: yelp is sweet :)
<zyga> sivang: letting users know about that is difficult
<zyga> sivang: and I think the stake is different here
<zyga> sivang: 1) there is this great idea about promoting python
<zyga> sivang: 2) we even get a nice free book about it
<TMM> jdub, do you have the name of that gdm guy for me please? I forgot...
<zyga> sivang: 3) aww, it's hidden in the help system -- I'd never look for a book in the help system
<zyga> sivang: 4) most users don't touch help systems with a 4 feet long stick
<jsgotangco> zyga: right
<sivang> zyga: I for my part alwasy mention "Did you know Ubuntu is python oriented?" and when they start asking, I show them the book and the interpreter :)
<Robi-> zyga, just tell the users that google uses it as their lgue language for everything
<sivang> (when pushing ubuntu around my commmunities)
* zyga likes python - that's not the issue
<zyga> how to launch yelp with generic html?
<sivang> Robi-: even better, "Does anyone wants to know how google know to speek the Elmar Fud language? Read DIP!"
<Robi-> so you want a little powered by python graphic somewhere on the desktop?
<zyga> Robi-: no
<zyga> Robi-: apps->devel->dive into python
<zyga> Robi-: after default install
<zyga> Robi-: basically I want one more desktop file
<zyga> never underestimate the value of the .desktop files
<Robi-> it would work, or at least a link to an online tutorial
<jdub> zyga: that means there'll be one menu item in Programming for normal users by default
<zyga> jdub: YES but then again THERE IS A BOOK ALREADY
<jdub> zyga: when it has no relevance whatsoever to them
<zyga> jdub: by default, just sitting useless
<jsgotangco> zyga: push html in yelp? it's scrollkeeper aware...
<zyga> jdub: then ask sabdfl to remove the book ;-)
<jdub> zyga: and we can provide a better user experience by making sure the documentation appears in devhelp
<jdub> zyga: this is not an either/or issue, dude
<TMM> jdub, zyga perhaps there needs to be a python-devel or ubuntu-devel metapackage?
<jdub> jsgotangco: it's already registered
<jdub> TMM: that's sort of what we'll be approaching with the 'ubuntu platform' stuff
<Robi-> zyga, where's the book now ?
<jsgotangco> jdub: ah yes
<TMM> jdub, is that on the wiki somewhere?
* jsgotangco is in kubuntu atm
<jdub> zyga: you can launch yelp with an html file as a parameter, but it's the wrong fix
<jdub> TMM: not afaik
<zyga> Robi-: dpkg-qurey -L diveintopython
<jdub> maybe our old spec is there
<zyga> everyone: thanks for noticing the issue 
<zyga> sabdfl: how about a ubuntu-devel metapackage?
<jdub> zyga: this is a bigger topic than just that
<Robi-> ya i dont seem to have it
<zyga> Robi-: ubuntu-desktop depends on diveintopython
<sabdfl> zyga: the whole point is that python is the easy way to extend your desktop, for everybody
<sabdfl> not heavy developers
<zyga> sabdfl: okay
<sabdfl> we don't add gcc, for example
<zyga> sabdfl: so the menu link is all we add, agreed?
<jdub> zyga: that's totally the wrong fix
<sabdfl> time to focus on the rollout. zyga: sounds like a reasonable start, we can tweak it at UBZ. be nice if you could start work on a spec "introducing the world to python on Ubuntu"
<zyga> jdub: okay, so how do you propose to fix, or rather -- imoprove this
<zyga> sabdfl: I'll try but I'm busy with RL work *and* a really huge idea about translations
<TMM> jdub, zyga, sabdfl  well, imho, on default install, there should either be meaningful documentation, and easy access to it, or none at all, and add it to a metapackage
<zyga> sabdfl: (maybe you've heard about it someplace)
* jsgotangco looks with interest
<mvo> zyga: hi, sorry for the lag. I'm a bit busy with RL currently (having friends visiting)
<zyga> mvo: hi, don't worry
<jdub> zyga: 1) build search into the user-focused help browser (already a spec for discussion at UBZ), 2) make sure DIP is in devhelp for developer-focused documentation, 3) distinguish DIP's role in the desktop vs. python dev 'platform', 4) link to DIP more usefully from python scripting environments and embedded python documentation in general
<zyga> mvo: feel free to leave me a message when you've got the time
<jdub> TMM: in this case, it's already in the user-focused documentation browser, but probably badly categorised, it's not well-linked in useful places (gimp-python, for example), nor is it easy to find in a search because search doesn't exist in yelp yet
<TMM> jdub, search seems to be the way to go then :D and perhaps add a tutorial on pyglade (I couldn't find it when I was looking, but I might just not have been able to find it)
<jdub> a major contributor to all of this is the awkwardness of documentation across multiple project silos
<TMM> jdub, pygtk is there 
<jdub> TMM: got python-gtk2-doc?
<TMM> jdub, yeah, it's in yelp too
<zyga> brb, reboot
<TMM> jdub, nothing about glade in there though. you'd have to know about the relation... 
<jsgotangco> badly registered then or non-existant
<mvo> zyga: ok
<TMM> cool\
<TMM> xen patches break all ISA stuff
<TMM> :)
<jsgotangco> good night
<TMM> mjg59, ping?
<Robi-> does anyone use vmware?
<mjg59> TMM: Hi
<TMM> hi mjg59 
<Robi-> someone should make a vmware ubuntu image so it can be used with teh newly released freeware vmware vmc viewer
<TMM> mjg59, did you have the chance to look at those hotkey patches in malone? and, is that the way you want to receive them? I've been carrying a breezy livecd and popping it into every laptop I come across to get keycodes, and I got a couple new ones
<mjg59> TMM: There's a wiki page somewhere - if you could add them there, that would be great
<TMM> mjg59, ok, cool.
<kbrooks> Robi-: link
<TMM> mjg59, and the compaq patch?
<Kamion> Robi-: mdz has asked me to work on that this coming week
<mjg59> TMM: Can't do anything until Dapper opens
<mdz> s/do/upload/
<Robi-> awesome
* HiddenWolf grins at mdz
<Robi-> vmware.com should have details
<mdz> dapper will open soon, one way or another
<TMM> mjg59, I just wondered if you thought it was ok, that's all :)
<HiddenWolf> mdz, that doesn't sound good...
<HiddenWolf> mdz, launchpad not holding it's own yet?
<mdz> no, literally. there are two ways to do it and we will do one or another ;-)
<Robi-> hopefully there'll be two images, a small basic install one and a full workstation one.. so there's choice
<TMM> mjg59, no rush :)
<ogra> mdz, is there a way for me to edit the description of https://launchpad.net/distros/ubuntu/+spec/screensaver-default-image ? it doesnt really match what is meant :)
<mdz> Robi-: once we've created a standard desktop image, anyone with vmware will be able to create new images and contribute them
<mdz> ogra: yes it does; I wrote it and that's what I meant :-)
<mdz> ogra: what do you think it should say?
<Robi-> mdz: what's involved in making it?
<ogra> mdz, sabdfl corrected it a bit when i asked why there is a spec for exchanging a single image file :)
<mdz> Robi-: that's what Kamion will be learning
<mdz> as far as the actual VM image, I think it's just a matter of saving it from a running VMWare session
<ogra> mdz, he wants that the image dir of xscreensaver gets populated by community artwork, calendar etc... thedefault image should only be one aspect 
<ogra> mdz, and the BOF to that pec should develop a general process how to get community artwork in there
<ogra> *spec
<Robi-> mdz: i see, yes, just get it working to a certain point, and zip/rar/tar up the vm directory
<mdz> ogra: updated
<ogra> mdz, thanks ... i wonder why i cand update it since i'm drafter for it :)
<Robi-> mdz, but it would be really usefull to have one quickly that is just the base install.. basic english defaults..
<ogra> *cant
* zyga is back at home
<sivang> mdz: have you read my overview SetupSnapshots (argh, what a terrible name) spec? What do you think about the general idea? (After discussing with people over here, I am looknig at making it easier then attempting to diff conffiles, more of an aggregation on top of a backup tool)
<zyga> can anyone remind me the URL to #u-devel log files?
<mdz> Robi-: feel free to contribute one
<zyga> and the specs deadline
<mdz> a desktop install sounds much more useful to me, though
<Robi-> mdz: installing one now, server boot option..
<Kamion> yeah, I expect to only work on one image due to time constraints
<Kamion> zyga: http://people.ubuntu.com/~fabbione/irclogs/
<zyga> thank you Kamion 
<Kamion> what are vmware's procedures for authenticating images they get?
<sivang> zyga: 27th 
<zyga> Kamion: if memcmp(image, "valid", sizeof "valid") ;-)
<Kamion> (not that I expect anyone will know, but it's an obvious concern with contributed images)
<zyga> sivang: darn, so little time
<Robi-> mdz, kamion, should I use LVM? or plain scsi [1.1G]  lvm could be resized later..
<mdz> Kamion: I expect vmware leaves that problem up to the user
<mdz> Robi-: your call
<Robi-> ok i'll stick to defaults for now
<HiddenWolf> mdz, what exactly is happening on #launchpad?
<HiddenWolf> mdz, moving the entire distro to launchpad?
<mdz> HiddenWolf: using launchpad to manage the package archive
<HiddenWolf> mdz, pfew
<sivang> HiddenWolf: right
<sivang> :)
* sivang --> out, be back when home
<jdub> Kamion: do you need vmware license details?
<jdub> Kamion: or are you going to do it qith qemu?
<mdz> jdub: he will need vmware
<jdub> ok, i'll send them
* zyga is crushed :-(
<Robi-> ok, the base install is all done, where can I stick it?
<Robi-> mdz, kamion, where can I upload the image
* sivang attached --> back
<mantiena> mdz, hi, are you online ?
<mantiena> mdz, why this patch http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005/casper/casper--automount/ is not included in casper-main or casper-breezy ?
<jdub> pitti: what's "Turn Off Computer" in german?
<jordi> jdub: dude, gnome-session source :)
<jordi> hmm gdm actually
<jordi> msgid "Shut _Down"
<jordi> msgstr "_Herunterfahren"
<jdub> heh
<jordi> I was about to suggest that :)
<jdub> hrm, don't actually mean shut down
<jordi> what do you mean? Turn off, with the switch?
<jdub> something slightly vaguer
<jordi> msgstr "Den Computer _herunterfahren"
<pitti> jdub: litereally, "Computer ausschalten"
<jordi> Imagine a german saying "Computer"
<pitti> jdub: it's a bit more obvious than "shut down"
<jdub> like the difference between 'shut down' and 'turn off computer' ;)
<jdub> pitti: thanks
<pitti> jordi: it is translated as "Rechner", but "Computer" is really common her
<pitti> e
<jordi> pitti: nod
<jdub> pitti: obvious as in "be off already!" or more about the process?
<zyga> jdub: what are you trying to do?
<pitti> jdub: obvious as being understand by more people
<jdub> zyga: understand the length of the string
<jdub> pitti: perfect, thanks :-)
<jordi> pitti: theey use it for "host"
<pitti> jdub: "shut down" is a more technical term
<jordi> msgid "A_dd host: "
<jordi> msgstr "Rechner _hinzufgen: "
<pitti> jordi: "to compute" really means "rechnen"
<jordi> aha
<zyga> jdub: ????
<zyga> jdub: understand strlen (or rather it's utf8 aware variant)
<jdub> zyga: no, i wanted to know how long the words were
<jdub> zyga: don't worry about it, i'm capable of asking questions myself :)
<zyga> jdub: anyway grepping the .po files is a simple alternative 
<jordi> where is mvo when I need him
<jdub> zyga: it's not, when i want help from a german speaker
<jdub> pitti: so in process terms for a normal user, would it make sense to click "Computer ausschalten" and then be given a choice between "_Herunterfahren", restart, etc?
<zyga> well you got something similar or identical to what's in the .po file, or am I missing something obvious
<jdub> zyga: i want to talk to a german about my question. don't worry about it.
<zyga> jdub: ah, okay :)
<pitti> jdub: it does not actually make sense - "ausschalten" means power off
<pitti> jdub: so it would rather make sense the other way round
<sivang> hey pitti 
<pitti> jdub: first, ask for "shutdown" (herunterfahren)
<pitti> jdub: then for "power off" (ausschalten), "restart" (neu starten), and so on
<jdub> pitti: so in english, "turn off computer" -> shutdown/restart/suspend sort of works
<sivang> jdub: joining the -de l10n team ? :)
<pitti> jdub: from my POV it does not make sense in Englihs either
<pitti> jdub: "turn off" means "power off", doesn't it?
<jdub> pitti: yeah, it's a bit wishy-washy ;)
<jdub> yeah
<pitti> jdub: so it should bue "shutdown" -> power off, restart, etc.
<jdub> it's kind of like, "What kind of turning off would you like?" ;-)
<pitti> jdub: same distinction in German for "Herunterfahren" vs. "Ausschalten"
* Kyral checks topic, smirks, and returns to lurking in the Motu Channel ;P
<pitti> jdub: yes, it's hard to find a general term that comprises power off/hibernate/restart
<jdub> pitti: i think the reason it mostly works in english is that 'shut down' has a specific technical meaning. it's still pretty bong though.
<pitti> jdub: for gdm, "End session" could make sense
<pitti> jdub: since it also offers you to log out the current user
<jdub> ah, see, "log out" is a separate thing, so it's even more complicated ;)
<jdub> windows xp quite sensibly splits these functions
<pitti> but all four options terminate your session
<jdub> log out -> quit / switch user
<jdub> turn off -> shut down / reboot / suspend
<pitti> well, as I said, for me "turn off" sounds more specific than shut down, but maybe it's just me
<jdub> nah, there's awkwardness there
<zyga> pitti: how about, power down
<pitti> same problem - we don't need synonyms, we need a more abstract term
<ajmitch> morning
<pitti> Hi ajmitch 
<zyga> pitti: what are you trying to accomplish with that?
<zyga> pitti: deactivate?
<zyga> pitti: computer, end program?
<pitti> zyga: I don't try anything, jdub asked me for some translations, and we discussed which terms would fit best
<sivang> pitti: what's up?
<pitti> zyga: it's just odd that after I ask my computer to "turn off", I get asked whether to restart it
<pitti> Hi sivang 
<pitti> zyga: turn off is turn off, not restart
<zyga> pitti: ah.....
<zyga> pitti: I understand now 
<zyga> pitti: I've got a great translation here
<zyga> pitti: it says 'end work'
<zyga> pitti: :D
<pitti> ... and start playing :)
<zyga> pitti: end session
<pitti> "A train station is a place where the train stops. But what the heck is a workstation?"
<pitti> zyga: hah, I proposed "end session", too
<jdub> 'session' means nothing to the user, though
<zyga> pitti: ask questions about what to do next ;-)
<zyga> pitti, jdub: how about 'leave system'
<jdub> 'system' doesn't mean anything
<zyga> jdub: exactly
<jdub> 'leave' means walk away
<pitti> "go play with your children"
<zyga> pitti: fine it could mean that
<zyga> pitti: how about: "Logout and..." (submenu) "...restart", "...hibernate", "power down", "show login screen"
<zyga> that could be good
<pitti> zyga: I like that
<zyga> the dimmed screen could just show 'are you sure you want to $BLAH'
<zyga> and a yes / no button
* zyga is glad to help
<zyga> jdub: how about you?
<jdub> no, they're separate issues
<lifeless> mjg59: any luck with dell ?
<mjg59> lifeless: Need to chase them this week
<mjg59> I've confirmed it in the Windows installer, plus in Windows safe mode
<sivang> mdz: is there any sense in specing stuff before the actual discussion, or a spec entry in launchpad suffices? (then it would be later discussed and then spec'd ?)
<mdz> sivang: it is reasonable to sketch an outline for the BOF discussion
<mdz> agenda items etc.
<sivang> mdz: ok, thanks. 
<mdz> not to actually write the spec of course; that should be done after the discussion
<mdz> unless it's not on the list for ubz
<mdz> ...and that list hasn't been made yet ;-)
<sivang> mdz: so that means that proof of concept code / programs are also irrelevant ? (I think I've seen in the past specs that already included some demo app code ,etc)
<mdz> sivang: anything relevant to the discussion, yes. just add a comments section at the bottom
<sivang> mdz: ok
<jdub> BenC: ROCK!
* infinity is reminded that he needs to get a spec up.
<infinity> mdz : When are the scheduling decisions being made?
<mdz> infinity: at the last minute, as usual
<infinity> Grantde, my spec probably doesn't need TOO much discussion, aside from assigning some tasks, and general buy-in that it's a good idea.
<infinity> mdz : \o/
<mdz> what is it?
* sivang is curious as well :)
<infinity> ReducingDuplicationInMain (not on the wiki yet, but that's what it'll be called)
<infinity> I've already been implementing it in sid, since dapper's not open yet. :)
<infinity> Killing off old versions of libdb, libmysqlclient, etc.
<infinity> I really want to do a rapid audit of main for private copies of libraries and kick them the heck out.
<infinity> That sort of thing.
<infinity> We're queueing up for a security support nightmare as it is, IMO.
<jdub> http://lxer.com/module/newswire/view/45917/index.html
<mdz> go ahead and put it in the spec tracker
<jdub> ^ blah blah firefox memory leak, firefox slow
<mdz> jdub: people who follow those howtos are going to have such an interesting time upgrading their systems later
<jdub> infinity: we going to switch to mysql 4.1 by default and things like that?
<jdub> mdz: yeah :(
<mdz> dpkg-divert should require --yes-its-my-own-fault if run from outside a maintainer script
<infinity> jdub : yes, mysql 4.1 will be the default about 5 minutes after dapper opens, with a mass-rebuild of all mysql-using apps to gfollow.
<jdub> infinity: ah, rock
<infinity> jdub : I already did a license audit to make sure I can punt the LGPL libmysqlclient10 completely (and I can stop maintaining it upstream, YAY!)
<jdub> infinity: php5?
<infinity> What about php5?  It's in breezy.
<jdub> oh yeah, we already did that switch
<crimsun> jdub: perhaps I should enqueue a preemptive FAQ for that one and link to it in #ubuntu when Dapper opens
<jdub> crimsun: "how do i unbreak my firefox"?
<crimsun> jdub: something along those lines
<infinity> MySQL 4.1 is high on the hit list, though.  Especially since we ran out of debugging time and ended up shipping breezy with a MySQL 4.0 that is B-R-O-K-E-N on PowerPC (fine on the other two arches, though)
<jdub> d'oh
<infinity> Kamion wasted a few hours on it, I wasted nearly a day, and Mithrandir blew another day or two, and we finally gave up in the end, pointing fingers alternately at MySQL upstream and the toolchain.
<Robi-> mdz: it's done
<infinity> At any rate, dapper should be a very solid server release, from where I'm sitting and surveying the lay of the land, so I'll be quite happy supporting it for 5 years.  Just needs a bit of tweak and polish to make me happy with it.
<infinity> And a pretty massive code drop in the first week of development.
<Robi-> mdz: where can I put it for you guys?
<Kinnison> hihi
<jdub> infinity: heh
<mdz> Robi-: wherever you want; just announce it to ubuntu-devel or something
<mdz> Robi-: once the CD image is ready, people can get it and swap it in if they want it
<Robi-> mdz, i'd have to upload it somewhere...
<Robi-> mdz, so you guys can use it if needed.. even Kamion 
<mdz> Robi-: that's fine, upload it somewhere
<Robi-> mdz, where? ;] 
<mdz> it doesn't matter as long as it's there
<Robi-> mdz, you wanna grab it then?
<mdz> no, I do not have time to deal with it
<mdz> managing a couple of crises right now
<Robi-> ok, here it is.. VMware base install of Breezy.. => http://robi.poptix.net/Ubuntu Breezy - base install VMware VM.rar
#ubuntu-devel 2005-10-29
<mantiena> mdz, still online ?
<mdz> mantiena: what?
<mantiena> mdz, why this patch http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005/casper/casper--automount/ is not included in casper-main or casper-breezy ?
<mdz> mantiena: because it isn't finished yet or even basically tested
<mdz> mantiena: why do you find it necessary to ask me this several times per day?
<mantiena> mdz, because I don't see you answer :) this patch is really tested - Baltix distribution (look at http://linux.akl.lt/baltix ) uses this patch from july and it works fine
<mdz> mantiena: Colin, who wrote the patch, told me it wasn't ready yet, and I find that more compelling
<mantiena> mdz, ok, I believe, that Kamion doesn't tested this patch ;)
<mdz> I don't know whether he has done further work on it since then, but he hasn't submitted it for merging yet
<mantiena> I talk with him then
<mdz> I suggest sending him email, rather than sending repeated IRC messages as you did with me
<mantiena> mdz, ok
<mantiena> thanks
<jdub> yo j^
<j^> yo jdub 
<Chipzz> oi jdub :)
<Chipzz> jdub: we don't see you talking here much lately ;)
<jdub> 3BT man
<j^> jdub why is there not more dogfood in the fridge?
<jdub> j^: because we are not pensioners?
<j^> but some more podcast would not hurt
<jdub> this is true
<jdub> i am planning to do quite a few at UBZ
<jdub> because there will be a lot of tired hackers too weak to say no
<jdub> MU HA HA
<jdub> *cough*
* Kinnison laughs
<whiprush> I am coming prepared too
* Kinnison gets his "NO" in early
<whiprush> got a video camera for the love day and everything
<jdub> Kinnison: the only interview question i have prepared for you is, "Are we there yet?"
<Kinnison> whiprush: planning on videoing the h0t ubuntu l0v3 ?
<jdub> whiprush: oh, seriously? awesome!
<Kinnison> jdub: to which the answer is still "NO"
<whiprush> jdub: yeah, I just need to find a tripod.
<Kinnison> jdub: Check out the URL I pasted in the company channel
<whiprush> I was planning on video taping each love day session and then ogg-ing them later
<jdub> whiprush: rock!
<Kinnison> oooh theora
<Kinnison> theoraenc is so slow
<j^> Kinnison try ffmpeg2theora
<whiprush> that's why it won't be in real time.
<whiprush> heh
<j^> or install theora-mmx
<Kinnison> j^: was running a custom built theora encoder
<jdub> Kinnison: the mmx bits crank it up nicely
<Kinnison> j^: on an umpteen gigglehurts amd64
<j^> amd64 has no mmx support right now
<jdub> 50% -> 25% when i was doing lca2005
<j^> Kinnison you might be better of using mmx 32bit version
<j^> you could try,
* Kinnison shrugs
<j^> or even better, write some mmx code for theora
<Kinnison> ended up using xvid :-)
<jdub> j^: supposedly the latest branch has runtime detection and stuff
<sivang> mdz: My intentions for the possible addition to language-selector, is that when someone chooses additional input language, it's gets automagically configured for him, wasn't that clear from the spec?
<j^> jdub well, no
<j^> http://v2v.cc/~j/ffmpeg2theora/ffmpeg2theora-0.15.linux.bin.bz2 is the lastest version i did of ffmpeg2theora and its using theora-mmx
<j^> http://downloads.xiph.org/releases/theora/libtheora-mmx-1.0alpha5.tar.bz2
<j^> will also speedup gstreamer and friends
<jdub> doesn't do runtime detection?
<j^> there is some work on using liboil(liboil.freedesktop.org) with theora in http://svn.xiph.org/branches/theora-oil
<j^> which does runtime detection
<j^> theora-mmx has, i forgot, let me check
* j^ should know, he did the last release
<jdub> oh, glad there's a liboil branch
<sivang> good night all, it's already way late for me :)
<jdub> let
<jdub> let's do that
<j^> yup, theora-mmx has runtime cpu detection
<j^> deb ftp://cipherfunk.org/pub/packages/ubuntu/ breezy main
<j^>  <- has theora-mmx breezy packages
<jdub> rad
<jdub> ah, you have new n-m/wireless-tools bits too :-)
<mdz> sivang: not only is it unclear in the spec, I don't understand what you just said
<infinity> mdz : What's the name of this spec?
<infinity> mdz : Without looking at it, I assume he's referring to mapping langpack installation with input method installation, so it all happens in one go.  Which has been discussed on -devel recently, and elsewhere.
<mdz> infinity: he put something in the tracker with a vague summary and I sent it back to him for review
<mdz> infinity: didn't mention anything about input methods, and neither did sivang above.  I don't think that's it
<infinity> mdz : Extending language-selector is easy (and doesn't need a spec, nor discussion really), it's fixing up all the various input method packages and picking sane defaults that requires capital E effort.
<infinity> is that when someone
<infinity>           chooses additional input language, it's gets automagically configured for him
<infinity> ^^^
<mdz> I haven't been keeping up with that thread; last time I looked it was the usual "well obviously <foo> is the best input method because everyone I know uses it"
<mdz> which we've heard with various values of <foo>
<infinity> That looks like it vaguely relates to input methods.  Can't see how else you'd configure an "input language" for someone.
<mdz> infinity: language-selector already has that concept
<mdz> it maps directly to language-support-*
<infinity> Right, I know.
<mdz> that is what "input language" means to me
<mdz> not "input method"
<mdz> language-selector doesn't let the user choose input methods, so that interpretation doesn't make much sense to me
<mdz> he can explain when he returns perhaps
<infinity> language-support-* isn't input languages, it's "feedback languages"... Difference between the computer talking to you, and vice versa. :)
<infinity> Anyhow, yes, he can explain what he means.
<infinity> I'll just work with the Debian SCIM maintainer behind the scenes to clean up the input method mess, as I'd already planned on.
<mdz> "when someone chooses additional input lanugage" (something that language-selector already does), "[it gets]  automatically configured for him" (unclear what "it" is here)
<gma> can anybody recommend a cheap hotel for UbuntuBelowZero?
<gma> there's a note on the wiki about the holiday inn, but according to their site they're booked
<gma> (as you can see, I'm planning ahead!)
<gma> are any of you even going?
<gma> !!
<jdub> http://lists.ubuntu.com/archives/ubuntu-desktop/
<jdub> hmm
<jdub> ^ in progress
<wasabi> WHy do people think we're so special.
<Amaranth> what do you mean?
<wasabi> Just venting. A thread on u-d which changed topic, so I don't htink I should respond there anymore. Somehow turned into the standard "linux doesn't get spyware because we're so secure" argument.
<infinity> The double-click .deb installer thread?
<infinity> I could see that one heading that way.
<wasabi> Yeah
<wasabi> I'm afraid it's mostly my fault. Heh.
<bob2> just spank the originator of the thread and tell them to make an apt source
<bob2> wow, so many long and rambling threads
<daniels> i think u-d needs something similar to kde-core-devel and (aiui) gnome-desktop-devel/gnome-hackers, where you actually have to justify write access
<bob2> or a higher level of "please stop posting to this thread until you've actually read the rest of it and have come up with something new and useful to say" smackdownosity
<wasabi> I wish Evolution had some better way of keeping track of mailing lists.
<wasabi> Like some sort of auto incoming sort that filed things away into categories, easily, without me micromanaging them.
<bob2> you could call it "threading"
<bob2> and implement it in every mail client since 1995
<wasabi> Yeah, sure, I'm on 16 mailinglists.
<bob2> only 16?
<daniels> you could call it "folders"
<daniels> and implement it in every mail client since 1995
<wasabi> I use folders, and I set up rules to filter things into them.
<daniels> make that 1975
<wasabi> But I use 4 different computers.
<wasabi> So I have to sync the rules between them.
<gma> he'd call that imap
<bob2> wasabi: server-side filtering
<wasabi> refer to point 1.
<bob2> ?
<wasabi> "easily, without me micromanaging them."
<bob2> evolution can't cope with you procmila'ing your mail?
<wasabi> I don't want to procmail things. I don't run my own IMAP server.
<wasabi> Hey I'm not looking for "how do I get this done". I was whining that it's not easier.
<bob2> the solution is "use imap and filter on the server"
<gma> how would it work though?
<gma> if it was easier
<Amaranth> you could call it "filters"
<daniels> gma: esp
<Amaranth> and just use gmail ;)
<wasabi> The client could detect the mailing lists and auto create server side filters.
<gma> oooh, "labels"
<bob2> gma: rules in an LDAP db using XML-RPC, duh
<gma> course
<gma> silly me
<wasabi> "I notice you just received mail from the foo@bar.com mailinglists. Would you like to auotmaitcally filter these messages into a seperate folder?"
<Amaranth> labels, oh yeah
<Amaranth> that's what those are called
<jdub> gma: sieve :)
<Amaranth> wasabi: It could check for List-ID, I suppose.
<wasabi> ANyways, that's all I was saying.
<gma> what about a procmail rule (just the one) to check for the list header (any header)
<gma> then smartfolders acting on that folder?
<gma> that'd be easy
<jdub> comments on http://lists.ubuntu.com/archives/ubuntu-desktop/ (and children) appreciated
<stub> fastmail.fm offers pretty cheap IMAP hosting with server side filters if you can't be arsed running your own systems like me
<gma> jdub,what happened to the fridge?
<jdub> it's not the fridge :)
<gma> jdub: well, it looks nice in safari. left margin surprisingly large though
<jdub> yeah, fixing that now
<gma> bullets for top and bottom "Messages sorted by:" are a surprise too (i.e. they're not really lists)
<bob2> jdub: what's the deal with the 9 of diamonfs?
<gma> ooh, no margin at all
<jdub> bob2: what do you think?
<jdub> bob2: deep down, you know
<bob2> jdub: oh, duh
<jdub> heh
* bob2 takes a penalty card
<jdub> talking
<gma> so have people booked hotels for Montreal?
<gma> actually, better question. which airport do you land at? I saw 3 listed on expedia.com
<gma> it's as if none of you are going...
<Amaranth> http://lists.ubuntu.com/archives/ubuntu-desktop/2005-October/thread.html has a weird space on top
<jdub> it does now
<jdub> fascist form elements
<stub> Gma: Most of the international flights land at Trudeau. The locals aren't online yet though.
<gma> stub: thanks. what time do they get in?
<stub> They are on UTC-5 or so I think. So whenever they wake up I guess.
<gma> lazy buggers, that's only 11pm.
<gma> school night I suppose
<stub> Gma: It is still Sunday
<stub> for them
<gma> yeah. and me.
<infinity> I land at Dorval Intl.  No idea where that is.
<gma> infinity: I'm finding it pretty hard to find any maps from the air port web site. it sucks.
<daniels> apparently dorval and trudeau are the same thing
<daniels> iirc
<gma> handy that, having 2 names
<ajmitch> and that there's taxis with a fixed fare at the airport
<gma> seems reasonable as dorval isn't listed on expedia's list
<gma> ajmitch: cool
<daniels> sydney's airport is alternately mascot or kingsford smith, also
<gma> by the way, I've never asked anybody this. I'm pretty handy with Python  and GTK, and can shell script quite happily.
<daniels> wikitravel: 'Montreal's Pierre Elliott Trudeau Airport (http://yul.aero/) (airport code: YUL), formerly Dorval Airport, is about half an hour west of the city center on highway 20.'
<gma> will there be people there who can put me to good use for 10 days?
<gma> I was just going to turn up...
<gma> daniels: cheers for the link, will read up
<fabbione> morning guys
<bob2> gma: basically no development happened at the last caonference, and the plan is similar for this one
<ajmitch> hi fabbione 
<pounk__> hello
<gma> bob2: so what kind of things can I expect? planning and discussion?
<bob2> gma: writing "specs"
<pounk__> I'm not sure, but I think that I found a bug in ubuntu... when I do tar -xvvjf with the vanilla source, my computer do a system beep and close.. this is normal? ^^
<gma> pounk__: is it a laptop?
<pounk__> no
<pounk__> I don't know if is just my computer.. I tried 2 time to decompress http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.4.tar.bz2
<ajmitch> gma: yes, lots & lots of planning & discussion
<gma> ok. less sure how useful I can be under those circumstances
<ajmitch> sounds more like it's overheating, if it's like my box :)
<gma> where can I find notes from the last one?
<daniels> somewhat randomly spread over wiki.ubuntu.com
<gma> thought as much. just reading the BOFs now. interesting stuff up for discussion
<pounk__> also, do you know that when you want use a french canandian keyboard, you can only edit /etc/X11/xorg.conf and change the keyboard layout to ca(fr).. you can't use the gnome-keyboard-properties.. so /me can't sugess ubuntu breezy for a quebec noob :'(
<pounk__> and everobody in the quebec can't really install ubuntu without know how to change the keyboard layout with /etc/X11/xorg.conf
<pounk__> it's normal because in the version of xorg use in ubuntu, the team of xorg change the name of the key layout ca_enhanced to ca(fr)
<mdz> pounk__: system->preferences->keyboard->add->Canada->French
<pounk__> I know..
<pounk__> but this don't work..
<pounk__> is a bug..
<pounk__> gnome think that the layout is ca_enhanced... but now is ca(fr)
<mdz> pounk__: if you want ca_enhanced, that's in the menu as "Canada (Multilingual)"
<mdz> ca_enhanced is still there
<fabbione> hey mdz
<mdz> hi
<pounk__> no... xorg change the name.. example... now, if I write ca_enhanced in /etc/X11/xorg.conf, I can't use my accents () I must write ca(fr)... but with an old version of xorg (the version that I use in my gentoo by example and the version that I used in ubuntu breezy) I had to write ca_enhanced... and I think that gnome-keyboard-properties use the old configuration of xorg because when I select keyboard->add->Canada->French,
<pounk__>  my accents don't work...
<fabbione> mdz: sabdfl and I were waiting a confirmation email from you, or at least i didn't get any answer... 
<daniels> ca_enhanced just uses ca(fr)
<pounk__>  that I used in ubuntu hoary scuse
<daniels>  $pcmodels  ca_enhanced     =   pc(%m)+ca(fr)+group(rctrl_switch)
<daniels>   *     ca_enhanced     =   pc(pc105)+ca(fr)+group(rctrl_switch)
<daniels> that's all it is; i'm not making this up
<pounk__> ok, but I don't know why, but the accent of an french canadian keyboard work with ca(fr) but don't work with ca_enhanced... and the accent don't work when I choose french canadian in the gnome tools to configure the keyboard..
<pounk__> and ca_enhanced worked with ubuntu hoary and work with gentoo by example.. 
<daniels> the canadian layout is being properly fixed for dapper
<daniels> the problem stems mainly from the fact that the keyboard itself is doomed by terminal stupidity
<pounk__> I don't know.. the only think that I know is that now, when you lived in the qubec, to use the accents, you must edit the /etc/X11/xorg.conf ..
<gma> right, bed time
<gma> cheers all
<daniels> i guess the snide response is to not live in qubec, but in all seriousness, it works just fine for me; i've never been able to reproduce ca_enhanced bugs
<PounK> but do you have a french canadian keyboard? is normal if you have an us keyboard, you can't reproduce the bug..
<daniels> of course I don't have a French Canadian keyboard, but the only physical difference between keyboards is that some have one extra key, others do not
<daniels> i can set my layout to ca_enhanced and it's exactly like I've got a French Canadian keyboard
<PounK> if you change the keyboard to french canadian in the key layout tool, try to do an  with the key / in your us keyboard
<daniels> what's been printed on the keycaps has no effect on the physical keyboard.  i can write 'whoohoo yarr' on one of the keys and it won't make any difference.
<PounK> but trie by example in xchat, not in the gnome keyboard tools
<daniels> like this   
<PounK> ok
<daniels> that  was meant to be a question mark, since that where I used to it being, but yeah
<PounK> I will just try to reinstall ubuntu in an other computer to test..
<dude2000> hello
<dude2000> is anyone in here?
<bob2> lots of people are
<dude2000> i'm new to irc's
<dude2000> just wondering why i didn't see anyone chatting
<bob2> this is a channel for developers' peopel only generally talk when they're discussing a particular issue
<bob2> (or ripping on Fedora)
<dude2000> I've been using linux for a year now and was wondering what I can learn in linux chats
<bob2> you probably want #ubuntu, not here
<dude2000> ok, i'll try that.  If I had any ideas on what should be developed, is this the room to come to?
<bob2> depends what it is
<bob2> just throwing out reams of feature ideas with no analysis or prototypes isn' that useful, unfortunately
<dude2000> ok, I'll look for other linux rooms intead, thanks
<bob2> eh?
<khakionion> ouch
<minghua> he doesn't seem to be happy
<mdz> fabbione: if it doesn't have a question mark in it, it doesn't get a priority reply ;-)
<fabbione> mdz: ahahhaha
<fabbione> mdz: dude.. time to change pusher? ;)
<mdz> fabbione: a pusher is someone who tries to convince you to buy drugs.  I have dealers.
<fabbione> eheh
<Robi-> uh
<pitti> Good morning
<Robi-> evening
<jsgotangco> afternoon
<jsgotangco> :)
<Keybuk> moin
<pitti> Hi Keybuk 
<Keybuk> how's it going?
<pitti> Keybuk: still a bit tired, I slept badly
<pitti> Keybuk: btw, Aaron told me how to unify diverged branches again
<Keybuk> oh right?
<fabbione> hey Keybuk 
<fabbione> hey pitti 
<pitti> Hi fabbione 
<pitti> Keybuk: you have to merge A changes to B, and then pull B changes to A
<pitti> Keybuk: that works fine
<pitti> Keybuk: thinking again about it, after cross-merging, branches are not guaranteed to be identical
<pitti> Keybuk: (in particular, after manually resolving conflicts)
<pitti> Keybuk: so maybe this was the reason to do it that way
<Keybuk> ah, maybe that was it
<pitti> slomo_: where was your security patch again?
<pitti> ajmitch: phpmyadmin patch looks good, please upload
<\sh> moins
<pef> hello
<pef> can someone check my debdiff for kcheckgmail against debian's version ? should go to breezy-updates, it fixes a grave bug (kcheckgmail doesn't longer works) malone#2018
<pitti> Hi JaneW 
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey sb
<sivang> Morning all
<sivang> mdz: still around?
<sivang> hey dholbach , seb128 
<dholbach> hi sivan
<seb128> hi
<seb128> grumpf
<seb128> so GNOME 2.13.1 tarballs are due today and we have nowhere to upload the packages :/
<Keybuk> let's do the dapper dance together
<Lathiat> mmm tomorrow apparently
<seb128> Lathiat: how so?
<Keybuk> suuuure
<Keybuk> I'd go for thursday or friday
<Lathiat> seb128: well sabdfl said if soyuz doesn't land by tuesday we'll go to katie and switch later in the cycle
<Lathiat> twas what he said anyway
<Lathiat> did he change that?
<seb128> no clue
<daniels> seb128: DUDE YOU HAVE NO RIGHT TO COMPLAIN
<seb128> I've not read that
<seb128> daniels: I've the right to be lazy because of that? :)
<daniels> yes
<seb128> cool
<daniels> ;)
<dholbach> seb128: meet you in the caf, bye guys :)
<Lathiat> on saturday: 8:07 < sabdfl> if its all good, we DOIT tuesday
<Lathiat> 18:08 < sabdfl> if not... katie comes into service and we need to switch to soyuz later in the cycle
<seb128> Lathiat: k, thanks. I'm not on IRC the saturday :)
<Lathiat> wonder whats happenign with merges
<Keybuk> nothing at the moment
<Keybuk> I'll switch on the bug-o-matic when we have an archive to upload to :p
<Keybuk> probably after UBZ anyway, so people don't get distracted
<sivang> does anybody know the package name of https://wiki.ubuntu.com/SimpleBackupSolution , and/or the status of this? I can't find this in the menus
<siretart> sivang: I think this is sbackup
<mdz> sivang: for a minute only
<ajmitch> evening
<ajmitch> pitti: thanks, will upload
<\sh> pitti: pingeling
<sivang> mdz: ?
<sivang> mdz: ah, ok then let's talk when you're back, have a good night
<dholbach> sivang: you asked, if he was still there
<ajmitch> mdz: btw, sent f-spot patch, hopefully to the right address :)
<mdz> ajmitch: I don't see it
<\sh> pitti: what about sec stuff like DSA 869-1 (do u have actually a CVE number for it?)
<mdz> unless you sent it in the past 3 minutes
<ajmitch> mdz: no, probably about 12 hours ago
<pitti> \sh: poooonngg
<ajmitch> mdz: which address shall I resend to?
<sivang> mdz: well, just one thing, seeing that most of my suggestion spec for SystemSnapshot is obsolete by SimpleBackup, why isn't it in main?
<pitti> \sh: there is a CVE number
<\sh> hmm....nothing works today...welcome to the real world of digital tv \sh :(
<mdz> ajmitch: mdz@ubuntu.com
<\sh> pitti: in your db?
<mdz> sivang: it wasn't finished in time
<pitti> \sh: if you want to fix it, see wiki.ubuntu.com/SecurityUpdateProcedures
<pitti> \sh: the DSA mentions a CVE number
<ajmitch> mdz: hm, I sent it there, no bounces or errors
<\sh> pitti: u rock...u can read my mind ,)
<daniels> mdz: what of mesa and xkeyboard-config?
<\sh> pitti: and what about new "upstream versions which are fixing the problem"? backport the patches or forget about it until dapper?
<pitti> \sh: backport or forget it :-)
<pitti> \sh: you can steal the fix from the Debian update
<\sh> pitti: well...3.7.0 in ubuntu against 3.7.2 in debian ;)
<ajmitch> \sh: I grabbed the patch for phpmyadmin, but it was a small fix
<ogra> moin
<pitti> \sh: look at the sarge diff
<ajmitch> hey ogra 
<ajmitch> how are you?
<pitti> \sh: 3.6.2-1 vs. -2
<\sh> pitti: ah well...yes
<ogra> ajmitch, fine, thanks... have to care for my hostel and need to buy some stuff today...
<ajmitch> ogra: great, had a good weekend?
<ogra> well... i had to fix up some hwdb stuff it was gotten darn slow ... but beside this, yes
<\sh> pitti: what do u want...the patch or the debdiff?
<pitti> \sh: debdiff
<Tode> hi there
<Tode> I'm working for a company which doing IWB (Interactive White Board)
<Tode> We want to develop a driver for Linux
<Tode> I'm working to get the right to develop a GPL Driver
<Lathiat> rock
<Tode> Linux is not a priority for the HQ... but I don't care
<Tode> I WANT A LINUX DRIVER
<Tode> :)
<dholbach> maybe the guys in #ubuntu-kernel have more ideas where to point you?
<Treenaks> Tode: or at least free specs..
<Tode> oh... ok
<Tode> copy-paste on kernel
<Tode> ;)
<Tode> thanks anyway :)
<ogra> dholbach, i sent Tode here as well as to -kernel :)
<Tode> ;)
<Treenaks> hey ogra 
<Tode> but people seems to be unavailable on -kernel..... :(
<ogra> moin Treenaks 
<\sh> hey ogra :)
<\sh> btw
<ogra> Tode, i told you, we are all in preparation of travelling ... its probably not the best time to catch them
<ogra> moin \sh 
* Treenaks needs to do some major laundry before Montreal :)
<Tode> ogra --> ok ok... I'll catch them later then
<\sh> ogra: last preparations? /me needs to pack his bag...that's it ;-)
<Treenaks> \sh: and your maps ;)
<\sh> Treenaks: my maps?
<Kamion> morning
<Treenaks> \sh: airport -> hotel :)
<Treenaks> \sh: etc
<\sh> Treenaks: there is a shuttle service as claire explained for 14 CAN$
<\sh> or 17
<ogra> \sh, i have to buy some new clothes etc... and to care for my hostel for the three frist days
<ogra> morning Kamion 
<Treenaks> \sh: oh, but only for sponsored people?
<\sh> ogra: ah...yes...the stomach problem, I remember :)
<\sh> Treenaks: no...officially
<Treenaks> \sh: hm, I've booked the ultra-cheap hostel, not the hotel
<ogra> yes, UDU made me fat, i have no fitting throusers anymore :/
<dholbach> ogra?
<dholbach> we're half a year away from UDU
<ogra> dholbach, and ? 
<\sh> ogra: well...breezy let my hair grow...there was no time to go to a hair dresser ,-)
<dholbach> enough time in between :)
<dholbach> and don't blame UDU :)
<dholbach> udu rocked :)
<ajmitch> dholbach: enough time at a computer :)
<ogra> i'm old, remember... with every year more your fat sticks on you...
<ajmitch> yes, it did rock
<\sh> *rotflbtc*
<jsgotangco> lol
<dholbach> tststs
<ogra> dholbach, i blame th ebeer :)
<dholbach> sissy :)
* jsgotangco got loads of fat
* ajmitch has plenty of insulation for the trip to montreal :)
<dholbach> ogra: of all people you shouldnt complain at all... you have a dog to take out :)
<Keybuk> ajmitch: bah, it's t-shirt weather there
<ogra> dholbach, i dont complain... but i wouldnt like to hold my edubuntu talk at love day in a jdub costume (pants off !!)
<ajmitch> Keybuk: how disappointing
<dholbach> i see
<\sh> dholbach: hey...fred is not the youngest anymore...he needs more love and petting then ogra ;)
<ogra> someone might stream it :)
<ogra> \sh, actually he's very bad ...
<ajmitch> dholbach: what have you got planned for the MOTU workshop on love day?
<\sh> ogra: what's up with him?
<ogra> \sh, he gets slowly lame at his rear legs 
* ajmitch is hoping the master MOTUs can teach us new tricks :)
<dholbach> ajmitch: a brief introduction and showing some simple samples of what we do, so people know it's easy to play in our team :)
<ajmitch> easy? get them fixing bugs :)
<dholbach> ajmitch: and if we have more time we could do some "excercises", whatever - do you have any ideas?
<\sh> ogra: sh*t
<ajmitch> dholbach: run through the IntroDeveloperDocs, use of malone
<ogra> \sh, yes... i'm not sure if he'll sirvive the winter :(
<ajmitch> dholbach: tools like debdiff & REVU
<ogra> *survive
<dholbach> ajmitch: yeah
<ajmitch> all the things people need to get started in MOTU
<HiddenWolf> mvo, ping
<dholbach> ajmitch: that's cool
<ajmitch> \sh & I can help out, I guess :)
<ajmitch> & siretart
<ajmitch> I guess we'll have as many MOTUs at UBZ as there were at UDU
<dholbach> we'll have a brilliant time over there, and we'll have 15 canadian motus after our presentation ;)
<ogra> only 15 ?
<ogra> bah
<ogra> lame
<ajmitch> we'll need them if you & ogra get tied up with main for dapper :)
* ogra wants 35 canadian MOTUs
<ogra> at least
<ajmitch> ogra: I hope your recruitment talk is good then :)
<ogra> ajmitch, i'm only in the second line... the talk is dholbach's :)
<ajmitch> oh right
<ajmitch> well we know we'll get at least 50 then
<dholbach> ogra: i'll do all i can :)
<siretart> that would be very great!
<Treenaks> ogra: I think a moviegotchi should be mandatory for MOTUs
<ajmitch> siretart: we'll expect you to be teaching potential MOTUs 
<ajmitch> Treenaks: nah..
<ajmitch> Treenaks: don't scare away the potential 
<Treenaks> ajmitch: why not? :)
<ogra> dholbach, there are great ways to poke your butt from the second line if you dont :p
<siretart> ajmitch: sure I'll do my best
<Treenaks> ajmitch: oh yeah, we're only supposed to tell them after the fact ;)
<ajmitch> Treenaks: I mean don't scare them with our faces :)
<Treenaks> ajmitch: _ogra_ is recruiting them
<Treenaks> ajmitch: ...
<ajmitch> haha
<ajmitch> be nice
* ogra goes looking for some lipstick and makeup then
<dholbach> ogra: i find the thought of somebody "poking my butt" disturbing :)
<ogra> *g*
<ajmitch> hm
<ajmitch> dholbach: I guess it's an incentive to give a good talk
<\sh> ogra: so I have to come again...and see him again...It's really sad
<ogra> \sh, yes, he's getting skinny... i can count his ribs from 3m distance now ...
<\sh> pitti: u have mail
<\sh> ogra: after UBZ there is time again
<ogra> \sh, yep
<\sh> ok lunch
<fabbione> who is Hidde Brugmans?
<Lathiat> hiddenwolf ?
<fabbione> HiddenWolf: ping?
* Lathiat checks
<fabbione> ok let's simplify
<fabbione> how do i reassign a bug in malone?
<Lathiat> click on the status thingy
<fabbione> given that random people are reassigning random bugs to me?
<Lathiat> Ubuntu (New) or whatever
<Lathiat> then can change it
<pitti> fabbione: click on the "request fix in..." line
<pitti> fabbione: there you can edit a bu
<pitti> g
<Lathiat> errr
<pitti> fabbione: it is impossible to find...
<fabbione> thanks
<Lathiat> it'l say like
<HiddenWolf> That's me
<HiddenWolf> fabbione, that's me.
<Lathiat> gst-ffmpeg (Ubuntu)
<Lathiat> you click on that
<fabbione> HiddenWolf: read above please
* Lathiat tries clicking on request fix in to see what happens
<HiddenWolf> fabbione, click on the ubuntu link
<HiddenWolf> fabbione, on the top
<fabbione> HiddenWolf: i have done already, the point is that you shouldn't reassigning random bugs around
<HiddenWolf> fabbione, did I?
<fabbione> HiddenWolf: i am not the ia64 contact person
<fabbione> [Bug 3109]  Need to execute elilo when upgrading kernel image on IA64
<HiddenWolf> ugh, sorry
<fabbione> i got this reassinged by you
<fabbione> not big deal..
<HiddenWolf> my reasoning was kernel-upgrade, he'd probably like to know - I'll check with you next time.
<hno73> Mithrandir: Are you still working on the NX stuff? I've described the speech recognition use case here: https://wiki.ubuntu.com/SpeechRecognition
<Mithrandir> Keybuk: I'm banging my head against something which looks a bit like a dpkg bug, with diverts.  I want to get rid of a diversion since it's no longer used.
<fabbione> HiddenWolf: i reassinged it to lamont, he is the IA64 porter
<fabbione> HiddenWolf: but generally malone bugs -> MOTU's
<Mithrandir> hno73: I worked on ia on Friday, not today, but yes, I work on it ATM.
<fabbione> HiddenWolf: it they have been opened against main pkgs -> redirect them to bugzilla
<Keybuk> Mithrandir: right ...
<Keybuk> there are a few
<Mithrandir> Keybuk: the problem is the non-diverted file doesn't seem to be removed by dpkg.  Ever.
<Mithrandir> Keybuk: which makes dpkg-divert --remove fail
<Keybuk> is the non-diverted file owned by dpkg?
<Mithrandir> yes
<Mithrandir> uhm, should be
<hno73> Mithrandir: OK, cool There seems to be a bug that causes strange UPPERCASE PHRASES to appear at times. It could be the Nomachine client of course
<dholbach> fabbione: do you think it's prudent to point the people from bugzilla to malone to bugzilla to malone, if we'll be switching to malone completely soon?
<hno73> (anyway, it's described on that wiki page)
<Mithrandir> : tfheen@xoog /tmp/ia32-libs-1.4ubuntu5 > LANG=C dpkg -S =ldd
<Mithrandir> diversion by ia32-libs from: /usr/bin/ldd
<Mithrandir> diversion by ia32-libs to: /usr/bin/ldd.amd64
<Mithrandir> ia32-libs, libc6: /usr/bin/ldd
<fabbione> dholbach: main -> buzgilla is still current working flow.
<fabbione> dholbach: we need to keep consistency until we switch
<bob2> haha
<fabbione> dholbach: also.. we are still not 100% sure when we will switch
<Mithrandir> Keybuk: this is with the version with the diversion installed.
<dholbach> fabbione: i don't like the thought of taking care of 2 "bugzillas" either, but i do it, since i don't want to push users around for the n-th time
<dholbach> fabbione: i hope we'll have ONE of them soon
<Mithrandir> Keybuk: however, if I upgrade to a version without /usr/bin/ldd, the file from ia32-libs is never removed.
<Keybuk> Mithrandir: there used to be a bug like that, I thought I fixed it though
<Mithrandir> Keybuk: this is with breezy.
<Keybuk> oh
<Keybuk> yeah, that fix didn't make breezy
<fabbione> dholbach: so do i, but i rather keep the current policy as standard for everybody rather than start mixing things around even more
<fabbione> dholbach: having one specific point in time for swtiching is better. We will make bugzilla readonly and that's finished
<fabbione> dholbach: if you let people opening bugs everywhere, than yes, you need to track 2 BTS
<dholbach> fabbione: i understand your position :)
<Mithrandir> Keybuk: ok, is there a workaround which is less gross than rm /usr/bin/ldd, dpkg-divert --remove?
<Keybuk> Mithrandir: upgrade dpkg
<HiddenWolf> fabbione, malone 3044, should be bugzilla, right?
<Mithrandir> Keybuk: Pre-Depends: dpkg (>= newer-than-breezy's) ? :-P
<Mithrandir> sivang: around?
<Keybuk> right
<Keybuk> seriously, it's a dpkg bug
<Keybuk> there isn't a work-around for it because dpkg is being silly
<Mithrandir> what version is it fixed in, then?
<fabbione> HiddenWolf: it's a duplicate of one in bugzilla already
* dholbach -> lunch
<Keybuk> Mithrandir: 1.13.11
<Keybuk>   * Fixed removal of files involved in diversions during upgrade, caused by
<Keybuk>     checking whether the "directory" was in use by another package without
<Keybuk>     actually checking whether or not it was a directory.  Closes: #310390.
<Mithrandir> Keybuk: ook, thanks.
<sivang> Mithrandir: now I am
<Mithrandir> sivang: you've played a bit with Ubuntu and POWER stuff, right?
<Mithrandir> Keybuk: any great suggestions on what I do with systems which have been affected by the bug already *cough*breezy*cough*
<sivang> Mithrandir: some limited plays, yes - what's up with that?
<Mithrandir> I could md5sum + rm, of course.
<pitti> \sh: patch looks fine, go ahead and upload
<koke> http://planet.ubuntu.com/news/ <-- I think this is pointing to an old css
<Mithrandir> sivang: IBM wants me to talk a bit about something related to it, any suggestions, pointers or something?  What's the status like, for instance?
<sivang> Mithrandir: well, we've came to the point we know what flags need be passed to mkisofs to create an image, however due to the fact I do not have a machine at home, and being busy at work I couldn't really give it much testing.
<sivang> Mithrandir: so now, Colin has those in our debian-cd scripts for the images.
<Mithrandir> sivang: it's the regular powerpc userland, right?
<sivang> Mithrandir: basically, when we get an image booting, and we have IBM behind us to support us with kernels, we'd ideally only have to care for user land.
<sivang> Mithrandir: Seems like it. The major changes are the OpenFirwamre and the way it boots, other then that you have the notion of "partitions
<sivang> Mithrandir: which only if we make Ubuntu a IOServer platform, we'd need to worry about
<\sh> pitti: thx
<\sh> pitti: uploaded
<pitti> \sh: thanks
<\sh> dholbach: ping what you need for the motu workshop?
<dholbach> \sh: pong
<dholbach> \sh: query
* HiddenWolf wonders how horrible his system would break if he tried to force apt-get to switch to amd64
<Lathiat> Hirion: badly? :)
<Lathiat> err
<Lathiat> HiddenWolf: badly :)
<Mithrandir> HiddenWolf: it's possible to do it, but you need to know how a lot of your system works.. or you'll learn that, the hard way. ;-)
* HiddenWolf grins
<HiddenWolf> Mithrandir, why, it's a 64 bit, it should cope. ;)
* HiddenWolf thinks he'll try on his spare install. :)
<Mithrandir> HiddenWolf: because unimportant stuff like libc.so.6 will go away. :-)
<HiddenWolf> Mithrandir, it'll have to learn and work without it then. ;0
<ogra> lol
<infinity> Mithrandir : Real men do system maintenance with a (completely) static shell.
* HiddenWolf thinks the -v option to rm -rf / is great fun, on a spare pc. :)
<infinity> Having a functioning libc is for wimps, anyway.
<Mithrandir> infinity: Pft, dynamic shells are fine as long as you know what you're doing.
<Mithrandir> I've done it, but I wouldn't recommend it to people who don't feel comfy about doing such stuff as rm /lib/libc.so.6
<Mithrandir> and being able to recover their system afterwards. :-P
<mdke> is security.ubuntu.com not working?
<mdke> i'm getting error 2 from it
<Znarl> mdke : What errors?
<mdke> [pasting
<Lathiat> works for me
<mdke> http://pastebin.com/403977
<mdke> Znarl, ^
<Znarl> I'll have a look.
<mdke> merci
<mdke> oh hang on
<mdke> maybe a firewall
<mdke> Znarl, yes, sorry call off the search, it is my stupid network
<Znarl> OK, search team has been called off.
<mdke> sorry for htat
<mdke> that*
<Znarl> Np.
<syrex|> Hello all :-),I want to add/fix to this script http://tinyurl.com/am97h 3 things: 1.adding input keyboard Hebrew 2.fixing the invert Hebrew in terimnal 3.adding Beep Media Player with my choice of fonts.
<sivang> pitti: we just tried to edit the same page on the wiki :)
<pitti> sivang: "just"? I didn't edit the wiki for about an hour
<trulux> morning
<sivang> pitti: it was minor change, you added yourself to the "Interested" field
<pitti> sivang: right
<pitti> trulux: Hi!
<pitti> trulux: btw, do you know about our ubercool new reboot notification?
<pitti> trulux: instead of printing a message in the postinst, you shuold just trigger it
<pitti> trulux: /usr/share/update-notifier/notify-reboot-required - just call it in the postinst if it is available, and otherwise print the message on the command line
<sivang> hey trulux , 'sup?
<trulux> heya pitti, lemme check that
<pitti> trulux: call it with sudo and watch the upgrade notice appear
<trulux> sivang: just came back from school,  I didn't take all the classes today. Need to study for exams ;)
<trulux> pitti: great
<sivang> trulux: I wish you good luck! I(actually my GF) know what it is to undergo the exams period, stressful and no sleep
<trulux> sivang: howya?
<sivang> trulux: pretty fine, trying to sort out stuff so they'll get approved for UBZ :)
<trulux> sivang: heh, well, I get less stressed because no one can say I must go to class. Only exams are mandatory, but I don't use to be away
<trulux> today I quit school and avoided having philosophy
<trulux> kind of anti-stress thing. I'm not up for discussion about lfie today
<trulux> ;)
<sivang> hehe
<trulux> although, other people go out for pot smoking, and then all of those who want to go earlier to home are taken as drug junkies
<sivang> hehe
<sivang> anyway, this OT , pm me if you like :)
<trulux> sure
<trulux> :)
<pitti> trulux: hmm, no vsec module after reboot...
<trulux> pitti: check dmesg
<pitti> [   52.159699]  VSEC: Failure registering vSecurity module with the kernel
<pitti> trulux: capabilities was loaded without disable=1 apparently
<pitti> trulux: the modprobe.d file is in place, though
<pitti> trulux: does that work for you out of the box?
<pitti> trulux: anyway, bbl (some food)
<trulux> pitti: well, it worked but I think I updated modprobe.conf manually with some command
<trulux> maybe it was update-modules, dunno
<trulux> bbl, lunch time
<trulux> :)
<sabdfl> jdub: are you happy with DapperReleaseSchedule being announced for wider discussion?
* trulux_ is away: relax...
<jbailey> .win 7
<pitti> Hi jbailey 
<Mithrandir> jbailey: do you happen to know if the .cpio archives which make up an initramfs can be compressed separately or if they have to be uncompressed if one does multiple ones?
<jbailey> Mithrandir: They can be compressed separately and cat'd together.
<jbailey> (tested it)
<jbailey> I think it was LaMont who told me that it's a property of gzip.
<Mithrandir> jbailey: ok, cool.  There's something wrong with my grub patch, but probably just something small and silly. :-)
<jbailey> Mithrandir: Trailing terminating null or something like that, perhaps? =)
<Mithrandir> jbailey: probably, yes.  Off-by-one-error or something.
<Mithrandir> since cat-ing the archives work.
<jbailey> Mithrandir: That's too cool, thanks. =)
<pitti> Hi jdthood 
<jdthood> pitti: Hi there
<Diziet> OK.  So our libgnomeui is more recent than unstable's.  How helpful.  And the pkg-config metadata file is incompatible with etch mozilla-firefox.
<Diziet> Anyone here know anything about font machinery ?  pangoxft, etc.
<mjg59> I know a small amount
<zburns> I'm doing some C# development (using Mono) and have just started using Ubuntu.  Is there a project list floating around that I can see if anybody wants help.
<Diziet> So are we supposedly using different font machinery to Debian ?  Are there relevant changes I should know about ?
<Diziet> etch's libgnomeui-dev has a .pc file mentioning libpangoxft-1.0 which breezy's doesn't.
<sivang> zburns: if you want to help maintain mono, you can contact tseng for that
<Diziet> I'm trying to decide whether breezy's is broken, or etch has different font handling to us, or something.
<DerekS> zburns: beagle, f-spot, plus many others, you might have better luck in a mono channel because the this isn't appropriate convo for this one
<zburns> dereks: thanks
<tseng> bwar?
<sivang> elmo: btw, do you know what is the status of SimpleBackupSolution ? 
<Nafallo> sivang: sbackup is in universe :-)
<sivang> Nafallo: I've seen that, yeah. I was wondering to what usable, if any state this is in :)
<infinity> sivang : Play with sbackup and file a bazillion bugs in the Debian BTS, please.
<sivang> infinity: debian? but I thought that was a Google SoC for Ubuntu, no?
<mjg59> Diziet: We shouldn't be using different font machinary
<Diziet> And the way our libgnomeui-dev is newer than etch's is generally worrying.  Maybe someone (preferably someone who knows what they're doing) should consider talk the Debian maintainer into an update.
<Diziet> mjg: Then I must conclude that our .pc file is wrong.
<mjg59> pangoxft is the xft backend to pango
<Diziet> Right, that's what I guessed.
<mjg59> If we weren't using that, then we wouldn't be getting anti-aliasing
<infinity> sivang : Yes, but the SoC student also happens to be a Debian developer, has the packages in sid, and would like bug reports there.
<Kamion> Diziet: wlog our GNOME is newer than Debian's
<infinity> sivang : I'm sure reports in Malone can also be passed to him, but.. <shrug>
<Diziet> kamion: IC
<Diziet> So all of our gnome apps are supposed to link against pangoxft ?
<mjg59> No
<mjg59> Apps should link against pango
<Kamion> seb works with the Debian GNOME folks too, but new upstream releases get slapped into our tree very quickly
<mjg59> What pango uses as its backend is up to pango
<seb128> Diziet: why is it worrying?
<seb128> Diziet: pango 1.10 uses cairo now, Debian has it to experimental only
<Diziet> If I don't include -lpangoxft-1.0 and -lXft on the link line for firefox-bin I get an undefined symbol.
<mjg59> Firefox may do xft magic itself
<Mithrandir> Diziet: I hope you're using pkg-config?
* infinity is having deja vu.
<Diziet> mithrandir: Yes, or rather firefox's configure.in is.
<mjg59> Hmm. Let me take a look.
<Diziet> seb128: Um, so you seem to be contradicting mjg59 who said we are using the same font machinery as Debian.
<infinity> seb128 : Didn't we just discuss this undefined symblo issue in IRC a week ago>
<mjg59> Oh, are we using the Cairo backend for font rendering now?
<sivang> infinity: I see, well, do you recall our talk about providing system snapshot? one last feedback from you, before I drop the whole idea :) Do you see any benefit in providing sbackup + packagae selection snapshotting tools combined ? 
<Diziet> mjg59: There's lots of cairo on my link line :-).
<seb128> infinity: yeah, I've filled this bug upstream but no reply yet
<mjg59> In that case, I may be talking bollocks
<Diziet> If we're different to Debian then my answer is to tell firefox's configure not to use xft.
<seb128> Debian unstable use pango 1.8 which uses xft
<elmo> sivang: no idea, no, sorry
<Diziet> I just wanted to check in which direction to change it ...
<infinity> sivang : <shrug>... I'm pretty uninterested in the whole thing in general, to be honest.  But file feature requests and patches on sbackup, if it doesn't do what you think it does.
<seb128> Debian experimental/Ubuntu use pango 1.10 which uses cairo
<Diziet> seb128: Thanks.  Right, I'll go back to wrestling the build system now.
<sivang> elmo: sure, thanks, already talking with infinity about that
<Diziet> (Unless you happen to have a handy predigested answer.)
<seb128> Diziet: we don't want to use xft IIRC, I've made some  firefox patching/upload about that, the corresponding upstream bug are probably pointed by the changelog
<seb128> firefox (1.0.6-1ubuntu9) breezy; urgency=low
<seb128>   * debian/ubuntu-patches/firefox-nopangoxft.patch:
<seb128>     - build with pangocairo (Ubuntu: #13881).
<seb128> in fact
<sivang> infinity: I understand, thanks.
<Diziet> seb128: Oh, right.
<mdke> elmo, do you have an eta on synching planet as per jdub's request?
<elmo> mdke: jdub hasn't requested it
<mdke> elmo, oh dear, he said that he had two weeks ago
<mdke> elmo, anything you can do?
<elmo> mdke: no - baz hates me.  send a mail to rt@admin.canonical.com about it, and I'll look at it later
<mdke> elmo, thanks
* mdke peers at jdub 
<Diziet> ccache++ again.
<Robot101> Diziet: hm?
<tseng> Robot101: hint, he maintains firefox
<Diziet> Oh, just my workstation not-compiling firefox.
<Robot101> :)
<Robot101> cache hit                           5742
<Robot101> cache miss                          1109
<j^> too bad ccache does not work with scons
<tseng> j^: using your NM 0.5.1 stuff
<tseng> j^: it rocks.
<j^> tseng yeah 0.5.x is quite an improvement to 0.4
<Nafallo> tseng, j^: where can I try it? :-)
<j^> Nafallo http://bootlab.org/~j/NetworkManager-breezy/
<Nafallo> thanx
<Nafallo> j^: I'll build it and point you to my amd64 packages so that you can import them then... ;-)
<Nafallo> baah
<Nafallo> anyone else get's MD5sum-errors on breezy-security/universe?
<infinity> Znarl / elmo ---^
<infinity> Nafallo : Looks like onle one machine is out of sync.  Just try the update again and it should go okay (yay, round-robin DNS)
<Znarl> I'll sort that out.
<Nafallo> worked after 4th time ;-)
<Nafallo> thanx :-)
<mdz> morning
<\sh> mdz: evening :)
<pitti> Hi mdz, how are you
<fabbione> hey mdz
<seb128> hi mdz
<mvo> hey mdz :)
<jdthood> Diziet: Have you received any other reports of #17216?
<Diziet> jdthood: None that aren't in the report, I think.
<Diziet> Do you have data that contradicts the theory that it only happens if you have the Flash plugin ?
<jdthood> Diziet: I think I do have flash plugin installed.  I have /usr/lib/flashplugin-nonfree/libflashplayer.so and symlinks to it from mozilla-firebird/plugins, mozilla-firefox/plugins, mozilla/plugins, mozilla-snapshot/plugins
<jdthood> Removing flashplugin-nonfree ...
<jdthood> Problem solved
<jdthood> Diziet: Consider your theory strongly corroborated.
<Diziet> Right.  Also, just a mo ...
<Diziet> Um, can you attach your xdpyinfo output to the report ?
<Diziet> And try running firefox with the Flash plugin and XLIB_SKIP_ARGB_VISUALS=1 in the environment.
<Diziet> According to the theory - not mine, but I seem to be holding the baby :-) - that will work.
<Diziet> See the gnomic comment from axel@banzais.org.
<Diziet> Thanks.
<jdthood> Setting up flashplugin-nonfree (7.0.25-5) ...
<highvoltage> I have something that I must say.
<highvoltage> I LOVE UBUNTU!
<jdthood> Diziet: (1) Run firefox; try to load www.ford.com -> death; (2) export XLIB_SKIP_ARGB_VISUALS=1;  run firefox; load www.ford.com -> Welcome to the home Ford Motor Company
<mdz> highvoltage: :-)
<jdthood> Diziet: Should I add 'export XLIB_SKIP_ARGB_VISUALS=1' to my .bashrc ?
<highvoltage> :)
<highvoltage> mdz: how are things? I finally got to see shuttleworth_zimmerman_band.avi, it cheered me up last week when I was feeling very down :)
<mdz> highvoltage: a bit hectic; leaving for Montreal on Wednesday morning
<Robi-> Kamion, around?
<Mitario> hi everyone
<Diziet> Damn, X VC switching bites me again.
<Mitario> jdub, around?
<Diziet> And I don't even want to reboot the damn thing because it's got a build running in it.
<Diziet> jdthood: Sorry about the delay.  Yes, please do that and let me know if any other X program behaves differently.
<highvoltage> mdz: cool, enjoy it. i can't wait for December, I've taken the entire month off to do some motu'ing, I'm going to drive ogra nuts!
<Diziet> I can't tell atm, but if you haven't told the bug report about your experience then please do so.
<mdz> highvoltage: you won't be joining us in montreal?
<highvoltage> mdz: unfortunately not. i'd love to join, but a combination of lots of work and lack of funds is against me.
<Diziet> And now chvt is hanging too.
<highvoltage> mdz: but i will be joining the events later next year, i have lots of plans to make more time and money for next year :)
<\sh> shuttleworth_zimmerman_band?
<jdthood> Diziet: Another question: In Opera ctrl-mouseup zooms in.  This is consistent with the way mouseup and sliders control the viewport's vertical position.  Illogically, Internet Explorer reverses the function of ctrl-mousemovement and unfortunately firefox follows IE.  Any change of getting firefox to work like Opera in this respect?
<jdthood> s/change/chance/
<jdthood> Is this a distro decision or something to be taken up upstream?
<Diziet> jdthood: I don't think this is a distro decision BICBW.
<\sh> jdthood: it's more a decision of QT and opera
<Diziet> That is, I haven't seen anything about it in our patches.
<Diziet> You mean `mousewheel movement such that top of mouse moves away from user' by mouseup ?
<highvoltage> \sh: have you seen it yet?
<\sh> highvoltage: what? the video? no...
<Diziet> And by `zoom in' you mean `show later part of document by moving the viewport down the document or the document up the screen' ?
<jdthood> Diziet: yes
<highvoltage> \sh: i'll send it to you tomorrow (or at least a link)
<jdthood> By 'zoom in' I mean that the font size increases.
<Diziet> I think mouse down ought to do the same as page down.  But I've never used a mouse wheel myself.
<Diziet> The font size !
<\sh> highvoltage: a link is good enough :)
<Diziet> I didn't even know mouse wheels changed the font size.
<jdthood> ctrl-mouseup/ctrl-mousedown
<Diziet> So you say :-).
<\sh> Diziet: konqui is doing it as well
<Diziet> Fair enough.
<\sh> Diziet: it's qt / kde behaviour
<Diziet> And we can be compatible with IE or KDE but not both ?
<Diziet> I don't want to make this decision, ask ubuntu-devel ? :-)
<\sh> Diziet: i would say a mapping of ctrl+mb4 and ctrl+mb5 to ctrl-+ and ctrl-- should be enough ,-)
<Diziet> Are their keystrokes that change the font size ?
<Diziet> Right, so Ctrl-+ increases font size.
<Diziet> I think + is more like down, but this reminds me of the flightsim vs FPS mouse movement argument.
<\sh> Diziet: oh well..i have to look...but jdthood spoke about "zooming" which is something else then inc/dec font sizes
<Diziet> So go and ask lots of people in a bigger forum.
<Diziet> \sh: He seems to be using the word to talk about font sizes.
<jdthood> \sh: Granted
<\sh> my wheel mouse is in the company at the moment...so I'll check it out tomorrow
<Mithrandir> jbailey: any idea if the load address of the initramfs has to be aligned?
<jdthood> \sh: So the solution is not to think of ctrl-mousup as moving forward, but as raising a font-size lever? :)
<Diziet> Anyway, ask in ubuntu-devel.  Sorry, I have to go RIGHT NOW.
<Diziet> TTFN all
<jdthood> Diziet: Seeya
<jbailey> Mithrandir: I don't, sorry.  I suspect so, since it gets handed around as a pointer internally.
<\sh> jdthood: well...u mean the movement up of the mouse or the wheel scrolling upwards?
<\sh> (movement up of the mouse...moving the mouse north ,-)
<Mithrandir> jbailey: I found a bug, let's see if this fixes it, if not, I'll try aligning.
<jdthood> \sh: Sorry, I have always meant "top of mouse wheel moving away from the user while control key is held down" by 'ctrl-mouseup'.  That wasn't very clear of me.
<\sh> (or into direction 1200)
<\sh> jdthood: ok...so..wheelup + ctrl == increasing font size and wheeldown+ctrl == dec font size
<jdthood> \sh: In Opera, yes.
<\sh> jdthood: in konqueror as well...which is QT behaviour..it works with all qt text controls
<Nafallo> jdthood: firefox and nautilus to.
<jdthood> In IE and firefox, the opposite is the case.
<Nafallo> hmm
<Nafallo> nope
<Nafallo> not in nautilus atleast ;-)
<Nafallo> but in firefox
<Nafallo> bug :-P
<jdthood> Aha.  If nautilus already does it the Opera way, then I can make a strong case for changing firefox's behavior.
<jdthood> "consistency"
<Nafallo> I never pondered, but I ALWAYS tries to shrink with the opposite. now it makes sense why :-P
<jdthood> Nafallo: Yes, when I started using this feature in firefox I found it frustratingly counterintuitive.  You move the viewport "forward" and ... things get smaller?
<jdthood> They say that LSD can cause one to have that kind of experience.
<Nafallo> in firefox yes, in nautilus no ;-)
<Nafallo> I don't really use the "feature", so for me both is annoying ;-)
<infinity> I'm all about wheeldown=growFont, wheelup=shrinkFont.  Given all the other things the wheel is used for "scrolling through lists of things, from first to last, scrolling through pages, top to bottom", that feels the most intuitive to me.
<Nafallo> for me wheelup feels like + ;-)
<Mithrandir> infinity: that feels utterly backwards for me, but I don't use the feature, so.. :-P
<Nafallo> Mithrandir: not even by mistake? ;-)
<Mithrandir> Nafallo: not really, no.
<runeh> Scrolling *down* the page ...
<Nafallo> Mithrandir: baah, just because you know what you do :-P
<Mithrandir> heh
<Mithrandir> well, rebooting.  Again.
<jdthood> Scrolling down the page (PgDn, mousewheel toward user) moves the text up.  We don't experience this as counterintuitive because we feel as if we are moving the viewport.  The same should be true for ctrl-mousewheel, IMHO.
<mdz> I don't find the feature to be particularly useful regardless of which way the binding would work
<mdz> on any page of non-trivial size, it takes a second or so to resize it
<mdz> such that a smooth wheelish sort of operation isn't really possible anyway
<Nafallo> mdz++
<jdthood> OK I'll file this issue at Severity: enhancement.
<Mithrandir> mdz: my mouse has wheel-up/down-buttons, then it makes a bit more sense.
<Mithrandir> jbailey: ok, works now. :-)
<jdthood> #18409
<jbailey> Mithrandir: too cool.  Was it just alignment?
<Mithrandir> jbailey: apparently, yes.
<jbailey> Hmm.
<jbailey> I wonder if that's biting me somehow with initramfs on ia64.
<sivang> mdz: I revised the i18n spec, I hope its less vauge now
<Mithrandir> jbailey: as well as such things as remembering to add to the size of the initrd, not just overwrite it with the latest fragment length, remembering to declare variables as static and similar vuss.
<jbailey> The magic numbers are all confused at the beginning, it almost seemed like an endianness problem. but it could be that too.
<jbailey> Mithrandir: =)
<Mithrandir> jbailey: but this seems to require updating of the stage1 code, which means running grub-install.  How do we get people to do that?
<jbailey> Mithrandir: Mmm.  Suggest burning that bridge when we come to it.  I can't see anything in Dapper wanting that, since it would be a non-conservative change.
<jbailey> Mithrandir: But it would be nice to say that it's possible on new installs and put it in the release notes?
<Kamion> Robi-: yes?
<Mithrandir> jbailey: yes, we can generate the monolithic initramfs as well as all the small chunks.
(Mithrandir/#ubuntu-devel) jbailey: it's a fairly small patch, though, so I wouldn't feel too bad to push it into dapper.
<Mithrandir> jbailey: http://err.no/patches/grub_chained-initramfs.diff is the patch
<jbailey> Mithrandir: Nice!  While you're digging in there, feel like adding one more? =)
<Mithrandir> jbailey: to do what?
<jbailey> Mithrandir: +  printf ("   [Linux-initrd, foo @ 0x%x, 0x%x bytes] \n", moveto, len);
<jbailey> Mithrandir: and friends should ideally be silent.
<Mithrandir> I could do that, but it's not in the form of a dpatch yet.  Should be trivial to do once we open up for real.
<jbailey> Mithrandir: #14502 is the wishlist.  It was too late for breezy, but it's probably the right thing.
<Mithrandir> How would we get them enabled for debugging etc?
<jbailey> Hmm.
<jbailey> Maybe add another token "quiet"?
<jbailey> Then update-grub can add that by default
<jbailey> I can't think of any other uses that could be overloaded for that would conflict.
<Mithrandir> you mean before root (..) ?
<jbailey> Yeah.
<Mithrandir> sure, that's easy enough to do
<Mithrandir> or make it quiet by default and verbose will enable it.
<ogra> re
<jbailey> I'd be inclined to leave the default as noisy, since it's expected behaviour for other grub installs.
<jbailey> We can change it in our generated stanzas easily enough without affecting what happens for people on their other OS installs.
<mdz> sivang: it's better, but I'm still not sure that I understand
<jbailey> (Avoiding panicy "WHY DID IT CHANGE?!?") emails.
<Mithrandir> point.
<mdz> sivang: you seem to be saying that when the user selects a language, we should choose a new keyboard layout for them
<Mithrandir> jbailey: I'll do that tomorrow, since it's a bit past 2000 here now, :-)
<mdz> sivang: but for a given language, there are multiple possible keyboard layouts
<jbailey> Mithrandir: No rush. =)  
<mdz> sivang: that's why, e.g. in the installer, we need to ask for language and keyboard layout, not just language
<Mithrandir> jbailey: well, given that we can't upload yet.. :-P
<sivang> mdz: adding another input language to GNOME keyboard notifier means changing layouts? 
<mdz> sivang: what is the GNOME keyboard notifier?  I assumed you meant the layout switcher
<mdz> sivang: I am talking about /usr/lib/gnome-applets/gnome-keyboard-applet. you?
<sivang> mdz: , yes the applet that allows you to  define grp shift behaviors to switch between english to herbew , etc. So yes, that's a layout switcher
<sivang> mdz: you are right. I have taken in consideration language which have only 1 layout per language, such as Hebrew and Arabic..
<sivang> mdz: maybe we can cross users' selected location and choose a reasonable layout for him. By choosing, I mean, we add it to the layout switcher, so he will have the option to use it when he wants to type in his lanugage.
<infinity> sivang : Well, you need to cross-reference with their current selected layout, too.
<infinity> sivang : For instance, if I live in Canada, install with a US Englihs keyboard, then add French as a second language, I do NOT want ca_fr (that layout will so NOT work the way I expect it to on a US English keyboard), instead I probably want US International (with dead keys)
<sivang> infinity: and asking them to specify that is starting to be like using the layout switcher itself..
<zyga> hi I'm trying to debug a scanner hotplug script
<zyga> it sets up bad permissions (root:root instead of root:scanner)
<zyga> where to start?
<madsen> 'ey! :)
<zyga> hmm
<madsen> I know that this isn't a support channel, but I'll dare asking this anyways... Any info on how to prevent mousedev from taking control of my tablet when plugging it? (I've asked on #ubuntu, but no one seems to know or be willing to answer.)
* madsen ducks.
* zyga needs to recall who has helped him with with hotplug scripts last time
<madsen> zyga: Actually, I think it's /etc/hotplug/usb/libusbscanner line 18. ;)
<infinity> zyga : I would assume your scanner's "magic" isn't included in libsane.usermap, so it's not detected as a scanner (and the perms aren't set)
<madsen> How does one go about finding that "magic"? I think I need to remove my tablets "magic" from usb.handmap to prevent mousedev from taking it over.
<Mithrandir> madsen: lsusb
<madsen> Ohoo! :)
<madsen> I was groping around in proc to find it. :-|
<Mithrandir> you could probably have found it there too, but lsusb is less work
<madsen> Mithrandir: Indeed. :)
<madsen> Bus 002 Device 009: ID 056a:0060 Wacom Co., Ltd 
<madsen> So, how would I write that usb.handmap style? (The 0xNNNN notation.)
<infinity> 0x056a 0x0060 
<madsen> infinity: Hehe, ok... Simpler than I thought. :) Thanks!
<infinity> (try 'lsusb -v' to get a more complete output)
<cevizoglu> does anyone know of a bug w/ pptpconfig getting double-free from glibc, or should I file it in bugzilla?  or is this the wrong place to ask?
<cevizoglu> er, I mean glibc reporting a double-free and then pptpconfig disconnecting...
<infinity> File it in bugzilla, please.
<cevizoglu> infinity, ok, thx  :)
<madsen> Hmm, that didn't work, apparently... :(
<leonel> can we start testing  Dapper ? 
<dholbach> leonel: no, it's not open yet
<leonel> dholbach, thanks
<ogra> leonel, come back from time to time or even idle here and watch the /topic ;)
<zyga> re
<zyga> sorry the scanner killed my system 
<Treenaks> whee, that was 90% of packing
<ogra> Treenaks, already packing ? 
<Treenaks> ogra: yeah, if I pack now, I won't forget as much ;)
<Treenaks> ogra: as when I packed on Friday
<ogra> heh...
<ogra> i fly on wednesday, but havent packed anything yet :)
<zyga> Bus 002 Device 007: ID 06bd:2095 AGFA-Gevaert NV SnapScan e25
<zyga> that's my scanner
<zyga> where should I add its 'magic'?
<leonel> ogra, perfect !
<ogra> :)
<sivang> ogra: when are you arriving at UBZ?
<Treenaks> ogra: I fly on Saturday
<sivang> Treenaks: me too :)
<ogra> sivang, i'll arrive on wednesday in montreal ... (the dumb hostle guys still havent confirmed my room, grumble) i'll arrive at the conference on Sat.
<sivang> ogra: ah cool, doing a trip there?
<sivang> ogra: Looking forward to seeing you there :)
<ogra> not really... just a bit recovering from travelling and looking around a bit
<ogra> i didnt plan any big sightseeing
<ogra> the hostel has free wireless ... if they ever confirm my booking i'll just do my work from there
<sivang> ogra: coool :)
<ogra> eles i'll probably end up on a park bench sleeping under a newspaper ... 
<ogra> :)
<sivang> ogra: luckily , I arrive at 29th evening, so I will probably have time to sleep and recover before next day 
<zyga> infinity: no, the magic is indeed contained in libsane.usermap file
<mpt> ogra: What hostel's that?
<ogra> mpt, same as doko's ... i'll try to catch him tomorrow by mobile so he can hopefully sort it... else i'll try to find *something* after arrival...
<jmg> hi guys
<wasabi_> woo hoo. car paid off.
<wasabi_> I now have no debt.
<jmg> is any work being done to replace init with another boot scheme?
<ogra> jmg, first we have to do a spec ... that will probably happen next week tha the conference...
<ogra> s/tha/at/
<jmg> ogra: just wondering how it could be done but retain compatibility with sysv stuff from upstream
<ogra> jmg, thats what the spec should describe ...
<zyga> jmg: AFAIR yes - there was an article about it somewhere recently
<jmg> zyga: is this inline with a debian action for etch?
<zyga> jmg: I'm not sure - etch is the next debian right?
<ogra> unlikely... the will add dependency init to sysv
<zyga> jmg: if yes -- then yes
<ogra> *tehy
<ogra> grr
<ogra> *they
<ogra> jmg, here's the first draft (not very much though) https://launchpad.net/distros/ubuntu/+spec/replacement-init
<ogra> i know Keybuk disagrees with debians way ....
<Amaranth> how do i comment on a spec?
<Mithrandir> Amaranth: come to the BOF
<Amaranth> Mithrandir: Not possible.
<ogra> Amaranth, you'll be able to comment to the wikipages comment section...
<Mithrandir> Amaranth: I guess you should add a "comments from people who won't be there" section to the bottom of the spec, then
<Amaranth> I want to try to kill MenuEditorPanelIntegration before people waste time on it, even doing a BOF.
<ogra> Amaranth, why ? 
<ogra> its an actual user request to add the menu editing back to the right click options in the panel...
<Amaranth> ogra: In order to do it you need to 1) write a custom widget and get themes to work with it, 2) basically port alacarte to C and integrate it into said widget to actually do things, and 3) do the same for KDE
<Amaranth> GtkMenu does not support what would be needed for doing this
<ogra> KDE already does it afaik
<Amaranth> ogra: There is no way it would get finished in time and more than likely whoever was working on it would give up once they realized how much work it would be.
<Amaranth> nope, KDE has kmenuedit
<ogra> whats the problem with just adding the old functionallity bach to GtkMenu but call smeg from it ? 
<ogra> finishing in time depends on the timeframe you set ;)
<Amaranth> ogra: That's not what the spec defines. It's talking about making the menus do all the stuff alacarte does
<Amaranth> alacarte == smeg
<ogra> just add your thoughts, the schedule will be done at UBZ anyway...
<Amaranth> oh, and just to be honest, 4) people wouldn't have to use alacarte anymore ;)
<ogra> if people doing the schedule agree with you, we probably wont have a BOF 
* Amaranth doesn't know how to add a comment to the wikipage
<Amaranth> there isn't a comment box and i don't want to kill the layout
<ogra> Amaranth, just add it at the bottom of the wikipage ...
<ogra> with a "comments" header
<siretart> someone willing to change topic? ;)
<Amaranth> why? is dapper open?
<cevizoglu> whoohoo
<ogra> not officially yet, but there was a first test upload it seems :)
<Nafallo> i.e. not on archive.ubuntu.com :-P
<cevizoglu> aww
<Amaranth> soyuz works?
<Amaranth> or is it using katie?
<daniels> Amaranth: katie
<Nafallo> the latest seem to be running both in parallell till soyuz is ready :-)
<Riddell> should the topic be changed?
<Nafallo> not until archive.ubuntu.com/dists/dapper exists IMHO ;-)
<ogra> Riddell, someone officially will do that if its ready
<dholbach> good night guys
<Nafallo> gnight dholbach :-)
<dholbach> night nafallo
<jbailey> doko!
<jbailey> Long time!
<doko> hi
<ogra> doko, !
<ogra> the damned hostel guys didnt confirm my romm request yet :(
<ogra> *room
<jbailey> ogra: Do you need me to call them?
<doko> ogra: I can ask them, although the rooms seem to be full, I'm in a "mixed" room :-)
<ogra> oh
<Amaranth> "mixed"? what does that mean?
<Nafallo> it's also the kitchen :-)
<ogra> grumble ... i'll have to find a park bench and a newspaper then :/
<jbailey> ogra: I have a porche and alot of newspaper.
<jbailey> Although if you want it, tell me quick - recycling day is tomorrow.
<doko> one newspaper isn't sufficient, it's getting cold
<ogra> doko, at least knowing if there could be a bed would be nice ... i'd be grateful if you could ask...
<doko> will do tonight
<jbailey> ogra: I'm sure there's a bed.  It just might already have doko in it. =)
<ogra> lol
<Amaranth> ogra: But that's still ok, right? ;)
<ogra> at least warmer than a benchand newspaper ...
<elmo> mdz: what do you want to do about auto-syncs?
<mdz> elmo: I want them to start flowing
<elmo> mdz/kamion: the infrastructure changes have only been lightly tested, caveat emptor if you choose/need to run any of the scripts
<zakame> good morning all
<elmo> mdz: ok 
<elmo> mdz: I need to go home, but I'll make that happen later tonight
<mdz> elmo: sabdfl already talked to you about saving the uploads as test cases for LP, right?
<mdz> dunno if you were already doing that, or for how long
<mdz> (keeping them for how long)
<elmo> mdz: queue/launchpad on jackass ...
<elmo> it's been there since before dapper opened
<mdz> great
<ajmitch> morning
<mdz> jbailey: .ca follows the same schedule for DST as .us, right?
<jbailey> mdz: This year =)
<minghua> mdz: yes, at least until 2007 :-)
<ajmitch> jbailey: canadians have to be confusing, don't they?
<jbailey> ajmitch: Confusing how?  The US is changing their DST.  One province (Ontario) has said that they'll follow.  None of the others have made an announcement.
<jbailey> But for now it's last sunday in October / Firsty Sunday in April
<ajmitch> NZDT starts first sunday in october for us :)
* ajmitch wonders how confused he'll get with TZ changes going to UBZ
<hughsie> ogra: ping?
<ogra> hughsie, pong
<hughsie> ogra: hey, you okay?
<ogra> i've seen your mail :)
<ogra> yup
<hughsie> ogra: bum... and i wanted to surprise you
<ogra> heh...
<hughsie> i've been learning dpkg....
<ogra> you shouldnt have sent it to a public ML then ;)
<hughsie> :-)
<hughsie> you wanna try?
<ogra> dapper is one since some minutes, where is the source pkg ? 
<ogra>  /one/open
<hughsie> not released yet, i'm still testing it
<hughsie> i i'll upload it to sourceofrge
<ogra> hey, its a development release, lest get the crack in :)
<hughsie> :-) lol, cool
<hughsie> what about for breezy?
<ogra> we can ask the backports tem as soon as its in dapper :)
<ogra> *team
<hughsie> cool. nice one
<hughsie> i'll upload it now
<ogra> cool
<hughsie> it wouldn't build for ages this afternooon, until i realised i was deleting the makefile.in's on a make distclean, as opposed to a make maintainerclean and then it worked
<Nafallo> ENOPITTI?
<ogra> Nafallo, come on its 11:50pm here
<Nafallo> ogra: I didn't see him leave :-P
<Nafallo> so I was quite surprised :-)
<Kinnison> Woohoo one danielstone of uploads
<hughsie> ogra: http://sourceforge.net/project/showfiles.php?group_id=133929 -- grab 0.2.8.1
<ogra> already ? 
* ogra goes to follow up :)
<sivang> Kinnison: uploads are already getting in?
<ogra> hughsie, i thought you made a soucre deb ? 
<ogra> *source
<Kinnison> sivang: into katie yes
<sivang> Kinnison: ah
<hughsie> ogra: <newbie>i made a deb, dsc, a changes and a new tar.gz, is that not cool?</newbie>
<ogra> hughsie, oh noo... you added a debian dir to your source tree ...
<hughsie> ogra: not cool?
<ogra> nope...
<ogra> always keep the packaging distinct from the real source
<hughsie> ogra: i figured package the stuff, then you only have to change a few lines for ubuntu
<ogra> this way people can adjust package specific things without changing the source itself
<hughsie> ogra: don't you patch the source already?
<ogra> debian might want to package it different, progeny too as well as linspire, knoppix or other debian based distros
<hughsie> surely the copyright stuff and docs and control stuff will be 99% the same?
<ogra> patching the source from the debian dir is fine... but the tar.gz should always stay untouched... i made such mistakes too in the past
<ogra> yup
<hughsie> ogra: i can r, the debian bit and re-upload if you like
<hughsie> *rm
<daniels> btw, I'm doing the traditional vim upload
<ogra> make a tgz with the debian dir and send it separately and leave the tgz as claen source ...
<daniels> it's already practically done
<ogra> cool
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | MOM/NDA producing bad diffs | Ubuntu 5.10 released: http://www.ubuntu.com/newsitems/release510 | yes, dapper
#ubuntu-devel 2005-10-30
<ogra> YAY !
<Seveas> topic too shory :)
<sivang> ogra: but it's using the non launchpad infarst.
<Seveas> short*
<ogra> sivang, its open
<sivang> right :)
<daniels> Seveas: 'yes, dapper' was all I wrote
<Seveas> lol :)
<hughsie> ogra: debian removed from directory source, i'll re-upload
<ogra> great
<hughsie> now i need to work out how to build the boody thing again!
<ogra> use dh_make
<ogra> but use a orig.tar.gz
<ogra> that contains the plain source
<hughsie> and how to use the debian files?
<ogra> dh_make creates them for you ...
<ogra> with dpkg-buildpackage -rfakeroot -S you create a debian source package that keeps packaging and soucre distinct
<hughsie> ahh, that's what i needed to know
<ogra> so a debian source package should consist of .dsc orig.tar.gz diff.gz and source.changes file
<ogra> the diff.gz will hold the debian dir and all patches to the source
<hughsie> sorry for being think, it's a bit of a difference to rpm
<ogra> yup
<hughsie> \me fires up breezy...
<hughsie> ogra: take two: http://sourceforge.net/project/showfiles.php?group_id=133929 (bare source)
<whiprush> wow, new Xorg already. Let the bleeding begin!
<Nafallo> :-)
<ajmitch> whiprush: just don't run with scissors
<hughsie> ogra: ok quite impressed , dh_make rocks.
<whiprush> I'm a boring person anyway
<ogra> yup
<Treenaks> ajmitch: jdub does it
<ajmitch> Treenaks: jdub is a special case
<Treenaks> ajmitch: true, he loves the bleeding edge ;)
<hughsie> ogra: what do you do with the .ex files?
<ogra> remove or use .ex == example
<ogra> also use lintian to check the package quality and pbuilder to check the building
<hughsie> ogra: okay, thanks
<ogra> there is a PbuilderHowto on the wiki :)
<hughsie> cool
* Nafallo giggles about archive.ubuntu.com some times have icons and some times not have icons :-)
<Seveas> Nafallo, a.u.c is not a single machine :)
<Nafallo> I know :-)
<Nafallo> three machines :-)
<Nafallo> should still have the same conf one might think ;-)
<daniels> christ vim take sa long time to build
<doko> elmo: please could you sync gcc-3.3, gcc-3.4, gcc-defaults from unstable, gcc-4.0 from incoming, overwriting the ubuntu changes?
<elmo> daniels: the clever linking tricks help
<daniels> elmo: i think the buildds are going to hate me for all my x11 lib uploads
<daniels> elmo: the dude generating the tarballs did it on some bleeding edge omgcvs gentoo version of libtool
<elmo> I think the buildds are bored and don't much care as long as they get something to do
<daniels> elmo: it tests the command length against $max_cmd_length, which doesn't exist in our libtool, and of course, setting a sensible default is for pansies
<elmo> doko: can you mail?  I'm swamped atm, I'll lose track of IRC
<daniels> so libX11's link invokes ar a few hundred times, just quietly appending to the archive, for shits and giggles
<elmo> daniels: dude, that is clever.  that beats vim
<daniels> it's great to watch, along with the ': numeric expression expected', or whatever
<daniels> elmo: x outsmarts all
<daniels> combined with libtool, we are an UNSTOPPABLE FORCE of sensibility and forward planning
<mjg59> daniels: I KILL YOU
<daniels> mjg59: good morning?
<Nafallo> mjg59: are you going to stream that event? :-)
<mjg59> Mostly I kill anyone who's ever touched libtool
<doko> elmo: ok, will do
<daniels> mjg59: i haven't touched libtool
<daniels> mjg59: libtool touches me at night, in very inappropriate places
<mjg59> See? it's evil
<daniels> mjg59: i have never, ever, claimed otherwise
<jdub> HOORAY FOR DAPPER!
* Nafallo silently nods to jdub
<ogra> hoary for dapper ??
<TMM> woot Dapper!
<Nafallo> it might even give me x atm ;-)
<TMM> dapper is going to be a breez(y) to install!
<ajmitch> morning jdub 
<TMM> hey jdub 
<ajmitch> or whatever timezone you're in today :)
<daniels> i haven't broken X in dapper.
<mjg59> daniels: Pls break X in dapper
<mjg59> We miss broken X
<daniels> mjg59: i will.  just for you.
<ajmitch> thanks
<zakame> Is dapper's repos up?
<mjg59> No
<mjg59> It'll be in the topic once it is
* ajmitch can't wait to dist-upgrade & enjoy the breakage
<daniels> mjg59: the X server is a complex beast, so it's easy to slip in if (strcmp(username, "mjg59") == 0)
<daniels> mjg59: (psst: it is)
<mjg59> Goddamnit.
<zakame> haha
<mjg59> I hate being behind the times.
<mjg59> Have we opened on Katie, then?
<daniels> mjg59: well, on jackass at least
<daniels> mjg59: yes, katie is up and running
<daniels> i've uploaded > 30 packages so far
<mjg59> Ah, I just got email
<mjg59> I bet they're all X
<mjg59> Are they modular?
* ajmitch is just waiting for autosyncs to flood my inbox
<jdub> ajmitch: in spain atm
<TMM> daniels, and merge r300 so fglrx can me moved to universe :)
<ajmitch> jdub: great fun, when do you travel over to montreal?
<daniels> TMM: what do you mean, 'merge r300'?
<daniels> mjg59: not got to the server yet, got to do new upstreams of everything else.
<TMM> jdub, you got out of here just in time then, its pouring rain here now :)
<daniels> mjg59: (well, I'm running the modular server of course, but it hasn't been uploaded yet.  patience.)
<TMM> daniels, the r300 dri driver, I don't think it is merged in xorg 7.0 yet
<ogra> hughsie, uploaded the initial package ;) could you add a manpage for gnome-power-info for the next upload ? 
<daniels> TMM: it has been for quite some time
<TMM> daniels, the dri driver as well? I thought only enough was merged for render and EXA
<daniels> TMM: dude, look in /usr/lib/dri on a *breezy* system
<Nafallo> hehe
<hughsie> ogra: i've done a source deb
<hughsie> manpage for g-p-i on it's way
<hughsie> plus i need to sort out the /usr/etc stuff
<Nafallo> baah, never trust google to do the right thing ;-)
<Nafallo> Epson Stylus Photo R300, why does it need dri? ;-)
<hughsie> ogra: lintian isn't bad... i'm quite impressed so far
<ogra> hughsie, /usr/etc ? 
<ogra> hughsie, i dont have any /usr/etc stuff here ...
<jdub> ajmitch: wednesday, but things may change...
<hughsie> ogra: i get a warning, that file-in-unuusal-dir /usr/etc/gconf..
<ogra> not in my package here ...
<hughsie> can you show me your diff. file
<daniels> elmo: link.sh> jesus shit.  that thing is an abomination.
<Nafallo> daniels: how do I enable r300 then? :-)
<daniels> Nafallo: first you update the kernel to get the drm module, then you update the X server and the Radeon driver to get the DDX bits.  dri is a three-way tangle.
<ogra> hughsie, its your former debian dir copied in a clean dh_make built package ...
<Nafallo> daniels: dapper will have that love soon enough? :-)
<hughsie> ogra: hmmm, i need toplay more...
<ogra> hughsie, all locations seem fine here, builds fine and runs fine :)
<hughsie> ogra: cool!
<daniels> Nafallo: you'll know about it when it does
<hughsie> hal cvs would help...
* ajmitch wanders off for lunch
<ogra> hughsie, dont forget we package for dapper, things are expected to be broken in the beginning... its just important that they are fine at *some* point :)
<Nafallo> daniels: oki, kewl :-).
<hughsie> ogra: okay, cool
<hughsie> ogra; we need a new hal release...
<ogra> hughsie, will come :)
<ogra> pitti is sleeping already 
<hughsie> ogra: gnome-power-info manpage being added to cvs..
<ogra> oki
<ogra> will add it in the next upload ...
<Nafallo> ogra: tomorrow? :-)
<hughsie> ogra: na, i'll release 0.2.8.2 soon, with a few other fixes in a few days
<ogra> hughsie, the package will show up on http://archive.ubuntu.com/ubuntu/pool/universe/g/gnome-power-manager/ at some point (source and binary) take that as a base  ;)
<ogra> Nafallo, not sure... i'll have to care for my travelling stuff tomorrow... 
<Nafallo> oh, right.
<hughsie> ogra: okay, thanks
<Nafallo> I forgot everyone was going away :-P
<ogra> hughsie, seems dholbach got the spec for dapper power management assigned, he'll pobably take over 
<hughsie> ogra: okay, cool. the pmi integration needs some work i think
* madsen taps the mic.
<ogra> hughsie, thats a mjg59 task, i'll try to figure out the changes from the lat package and adopt them to the new one ... (or tell dholbach to do it)
<ogra> *last
<madsen> Testing, testing... Is this thing on? :-p
<ogra> madsen, SING !
<madsen> I'm not sure if this is the right place, but there's a problem with the wacom module.
<ogra> madsen, bugzila is the right place ;)
<ogra> *bugzilla
<hughsie> ogra: whats lat?
<madsen> ogra: Well, that depends if it's really a bug or just me being an idiot...
<ogra> *last 
<madsen> For some reason the mousedev module takes control when I plug in my tablet - that b0rks the pressure sensitivity in the tablet. :-/
<hughsie> ogra: the hal package or g-p-m?
<madsen> So I was wondering if it's just because I haven't told it not too (dunno how or where I should do that) or if it's actually a bug...
<madsen> s/not too/not to/
<khakionion> i've got a wacom graphire2 here, can i help?
<madsen> khakionion: Hmm, perhaps! I've got the (cheap) Volito though..
<madsen> khakionion: Does you graphire work out of the box with ubuntu?
<khakionion> madsen: alrighty, well, let me see...do i just check dmesg to see if it loaded mousedev?
<khakionion> yep
<khakionion> madsen: it works out-of-box on hoary & breezy...i dunno about pressure sensitivity, though
<madsen> khakionion: Hmm... Well, you can do 'cat /proc/bus/input/devices' and paste me the Handlers= line. :)
<madsen> Problem is that the volito "works" but without pressure sensitivity - and that's mousedevs fault... Actually the tablet is just treated as a mouse...
<khakionion> madsen: for the "Wacom Graphire3 6x8" (ooh, even better than a Graphire2, heh) the Handlers line is
<khakionion> Handlers=mouse1 event3 ts1
<madsen> Heh, same thing as here... Then you probably don't have pressure sensitivity working either. :(
<madsen> mouse1 shouldn't be there at all... I think it's usbhid's fault... I remember seeing something about that on linuxwacom.sf.net...
<khakionion> hmm
<madsen> I just hoped I could either configure me out of it or file a bug report and complain until it was fixed. :-p (Someone said: Ubuntu users don't compile, they complain. :-p)
<Riddell> is uploading to dapper much the same as uploading to breezy?
<daniels> Riddell: ...
<daniels> Riddell: no, we upload srpms now
<Riddell> I have no answer to such wit
<infinity> What wit?
<infinity> He's being quite serious.  We're Fedora-based now.
<infinity> No one told you?
<Riddell> I think I'm going to become an openSuSE developer
<khakionion> madsen: after installing wacom-tools, the command "sudo wacdump /dev/input/event3" shows working pressure sensitivity
<daniels> the U is capitalised now, too
<hughsie> ogra: thanks, night..
<Riddell> daniels: except when it isn't
<madsen> khakionion: Hmm... Interesting... I never thought of checking it that way. :)
<ogra> night hughsie 
<ogra> thanks as well ;)
<sivang> ogra: you're not going to sleep as well?
<sivang> :)
<khakionion> madsen: i gotta go, but i'll be working on this later
<robertj> What kind of hardware is the wiki running on?
<Nafallo> moinmoin
<sivang> Nafallo: that the hardware? :)
<khakionion> looks like all that might need to be changed is xorg.conf...dunno what that would mean for usability, though, since changing that involves restarting X, right?
<madsen> khakionion: Ok, thanks for the help! :)
<Nafallo> oops ;-)
<Nafallo> sivang: nice catch :-)
<madsen> khakionion: Was that last line for me too?
<sivang> Nafallo: hmm, maybe we can sell moinmoin applicances :) be like google, and it will be based off ubuntu :)
<Nafallo> hihi
<khakionion> madsen: yeah, sorry :)
<madsen> khakionion: I've already setup a lot of stuff in xorg.conf, but since the system treats the pointing dev as a mouse it doesn't use the pressure sensitivity. :-/
<khakionion> ah, okay
<madsen> khakionion: Btw, wacdump shows working pres.sens. for me too, but gimp doesn't...
<khakionion> madsen: darn...hmm, okay, i've got some ideas on what to do, but i've got to get a physics test and a calculus test out of the way first. i'll be back on it tomorrow afternoon :)
<madsen> khakionion: Hehe, ok. Best of luck then. Don't stress yourself... I'm just bored and wasting my time trying to make the tablet work in the most impossible way I can find... (I think.)
<khakionion> madsen: thx...i've been anxious to start helping out w/ubuntu, glad i finally found something relatively unique/doable.
<Kinnison> bed methinks
<Kinnison> ciao all
<bob2> adios, Kinnison 
<daniels> Kinnison: g'night
<tseng> daniels: is dapper broken enough yet?
* tseng hides
<daniels> the next one to make a dapper being broken joke gets dapper broken with a faked changelog with their name in it
<tseng> hm
<sivang> daniels: at least that would get me some more changlog entries :)
<Nafallo> hehe, 43+ packages and and daniels uploaded all but 2 :-P
<tseng> sivang: whos counting
<daniels> and, unless I'm very much mistaken, that's dapper's first NEW source package
<sivang> tseng: heheh
<tseng> mkdir -p .maildir/.ubuntu.dapper-changes/{cur,new,tmp}
<tseng> we're off
<sivang> night all
<hyperactivecrond> night sivang 
* robertj ponders the dot mac clone spec
<bddebian> Hello
<ajmitch> hi bddebian 
<robertj> Anyone wanna help brain-storm on the Ubuntu.Mac spec?
<ajmitch> robertj: dotUbuntu? :)
<robertj> the best I can think of is TribeDisk
<ajmitch> https://wiki.ubuntu.com/DotUbuntuRegistrationClient
<robertj> with the ability to join "Tribes" to assist you in setting up your TribeDisk, EDS datasources, etc
<ajmitch> not sure why I can't find it on the main wiki
<robertj> ajmitch: https://wiki.ubuntu.com/Ubuntu%2eMac
<ajmitch> yeah, i saw
<robertj> ajmitch: I was envisioning a communal kerberos and slapd pool
<ajmitch> there's existing specs out there with similar goals from UDU
<bob2> haha
<robertj> and then for the space you get to grab hosting from davs source including Canonical on a pay basis
<robertj> bob2: you think kerberos & slapd would choke at that scale?
<bob2> I'd be amused to see someone try
<robertj> bob2: my realm has < 5k users so I'm not really one to vauch for capacity
<robertj> bob2: there are some really honking directory deployments that use kerberos
<robertj> bob2: I'm actually very curious, could you fill me in?
<bob2> I've never seen/been involved in a big kerberos deployment
<bob2> I've not heard of ones distributed across dozens of locations with hundreds of thousands of users, tho
<robertj> bob2: the Army does Active Directory if you count that
<robertj> and err...that's alot of users
<robertj> (US Army, sorry)
<Nafallo> robertj: sweden to soon ;-)
<robertj> but I think it's important that there is both an easy to use free service and the option to use local services
<robertj> one problem is that gconf doesn't have any mature backend except for XML, and even if it did alot of the services don't store the settings that need to be changed in gconf
<robertj> but for proper integration Gaim, EDS, and half a billion other things should get clued into the change
<robertj> another big issue is that SyncServer doesn't have any equivalent I am aware of in Ubuntu
<daniels> imendio have done work on gconf-over-dbus for the 770
<daniels> and nevermind me, misread your question
<Fuji-san> TRULUX!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<Fuji-san> FRIEND!!!!!!!!!!!!!!!!!!!!!!!!!!!
<Fuji-san> :D
<trulux> Fuji-san: stop it
<Nafallo> Fuji-san: ...
<tseng> dude
<Fuji-san> hi
<trulux> I had to ban this guy of #ubuntu-hardened
<bob2> Fuji-san: you've already been banned from two ubutnu questoins for being a gimp
<tseng> daniels: can you ban this guy please
<bob2> oh, 3, then
<bob2> daniels: oi
<ajmitch> bob2: almost 4
<tseng> bob2: i kicked him from -motu and he autorejoin'd
<Fuji-san> i'm innocent untill proven guolty :((
<tseng> bob2: i had mercy
<tseng> Fuji-san: not really
<ajmitch> Fuji-san: you just proved yourself guilty
<trulux> Fuji-san: you own the record of kicks and bans after pappy- the star destroyer
<Fuji-san> sorry guys i just want to make friends
<bob2> Fuji-san: no, you've been shown to be annoying and useless
<Fuji-san> i'm sorry
<bob2> Fuji-san: then join #hottub, these channels are for technical discussion
<trulux> Fuji-san: go out and make friends, that will calm you down
<bob2> and ripping on SuSe
<ajmitch> trulux: no, I think that we had some others that managed to get all channels
<Fuji-san> bob2 hottub is empty
<trulux> ajmitch: hah
<bob2> Fuji-san: that's a shame
<trulux> Fuji-san: bad for you
<trulux> :)
<Fuji-san> lolz
<trulux> let's stop this 
<Fuji-san> 4 channels
<Fuji-san> nice 1 tseng
<Fuji-san> peerpressure huh :/
<bob2> Fuji-san: no, you've just annoyed everyone simultaneously
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*i=Smith@*.upc-d.chello.nl]  by daniels
* Fuji-san was kicked off #ubuntu-devel by daniels (daniels)
<daniels> sorry, was making breakfast
<daniels> anywhere else I can be useful?
<schweeb> just keep up with the Xorg goodness :)
<tseng> i think we got it all
<tseng> (for now)
<Nafallo> daniels: more xorg? :-) you're doing a great job on that front already though ;-).
<schweeb> Nafallo: I win :p
<Nafallo> schweeb: mine was longer ;-)
* mode/#ubuntu-devel [-o daniels]  by daniels
<elmo> mdz: fyi, auto-sync is/has been running, but it looks like it's going to take all night
<bob2> I wonder why gdm is running on vt9 now
<mdz> elmo: ok, thanks
<mdz> elmo: where does webmaster@ubuntu.com go currently?
<elmo> henrik
<mdz> ok, good
<mdz> jbailey: do you already have initramfs-tools changes queued to put the final touches on the usplash integration?
<sabdfl> night all
<jody_lap> Good evening.  Where would I request that the gnumeric version in breezy get updated or patched ?
<jody_lap> I'm getting alot of reports upstream of a bug in the 1.5.90 beta version that made it into the release
<crimsun> jody_lap: after autosync runs to completion, we can probably sync from experimental
<Nafallo> crimsun: for dapper...
<crimsun> rather, if a core developer deems it safe, he can ask for such a sync for Dapper
<mdz> jody_lap: the best thing to do would be to report the bug
<mdz> jody_lap: be specific about what the problem is, and provide a reference to the upstream bug report(s) (don't just ask for a new version)
<ajmitch> mdz: just resent f-spot debdiff
<ajmitch> hopefully this one arrives
<mdz> ajmitch: third try?
<ajmitch> 2nd
<bddebian> f-spot?  Is that just below the g-spot?
* bddebian hides
* seth_k chases
<seth_k> get back here you
<ajmitch> don't encourage him
<bddebian> Heh
<seth_k> nobody makes a joke that poor and lives :D
<bddebian> You know you love me ajmitch :-)
<mdz> ajmitch: nothing
<ajmitch> hm
<ajmitch> strange, since I don't get any bounces from my ISP's mailserver
<mdz> I also get a few hundred messages per day successfully at mdz@ubuntu.com
<ajmitch> yes, mail I send to lists gets through
<mdz> unless the subject was "Wanna be more man? Check this dude" it didn't get marked as spam
<Nafallo> ajmitch: want to try to send it to me?
<ajmitch> Nafallo: address?
<Nafallo> ajmitch: pm :-)
<ajmitch> yep
<ajmitch> Nafallo: sent
<Nafallo> recieved
<Nafallo> I'll forward it :-)
<ajmitch> hm
<ajmitch> still rather strange that it'd get lost twice :)
<mdz> the forward arrived fine
<Nafallo> hehe, my isp told me that port 25 would be dropped when I got upgraded ;-)
* ajmitch is sending through his ISP's mail server
<Nafallo> that's what they told me I would have to do aswell.
<Nafallo> anyway, worked ;-)
<ajmitch> yeah
<Nafallo> yay! autosyncs seems to arrive :-)
<ajmitch> oh?
* ajmitch hasn't seen any flood yet
<Nafallo> 30 new in that folder :-)
<daniels> those aren't autosyncs
<Nafallo> no?
<daniels> no
<Nafallo> what are they then? :-)
<ajmitch> Nafallo: that's daniels going nuts
<Nafallo> in changes-auto?
<mdz> ...followed by the first batch of autosyncs
<ajmitch> Nafallo: hm, I didn't see that list on the server
<jody_lap> crimsun: I'm not terribly clear on ubuntu development.  Is that related to debian experimental or is there an ubuntu experimental ?
<daniels> hm, my mail delivery must be lagging an arseload
<ajmitch> ah, ubuntu-changes-auto, not dapper
<crimsun> jody_lap: mdz's statement regarding filing a bug was more appropriate
<Nafallo> ehm. did my evolution just hang? :-P
<mdz> jody_lap: he was referring to debian experimental
<mdz> jody_lap: ubuntu generally has 1 development branch and 3+ stable releases
<jody_lap> mdz: please repeat the comment, my connection dropped.
<mdz> jody_lap: I asked that you file a bug in our Bugzilla with the specifics of the bug that you were referring to
<daniels> poor katie.
<daniels> there's still 49 packgaes plus however many have been autosynced
* Nafallo agrees with daniels
<Nafallo> 68+ :-)
<mdz> jody_lap: someone should be able to look at it tomorrow morningish in europe
<bob2> \sh_away: oi
<jody_lap> mdz: done.  Thanks
<jody_lap> good night
<Nafallo> dapper: the free mta stress-test :-)
<schweeb> Nafallo: -changes traffic too much for you or something?  try subscribing to LKML :p
<Nafallo> nope, it stills holds up :-)
<daniels> fabbione: I WOULD LIKE A WORD
<daniels>     ../configure --prefix=/usr --sysconfdir=/etc --mandir=\$${prefix}/share/man \
<daniels>                  --infodir=\$${prefix}/share/info --libdir=/etc/X11 $(confflags) \
<daniels>                  CFLAGS="$(CFLAGS)"
<bddebian> Uh oh
* daniels gets bored of apps, moves on to xorg-server.
<Nafallo> :-)
<daniels> (there's still like 40-50 messages that haven't hit breezy-changes.  so much less fun without instant feedback.)
<Nafallo> hehe, I currently get about 20mails/min so... ;-)
<fabbione> morning
<fabbione> daniels: do your uploads require a specific building order?
<daniels> don't build libxaw 2:0.99.1-1 or whatever it is
<daniels> just skip straight to -2
<daniels> that aside, no
<fabbione> ok
<fabbione> i didn't start the buildd on dapper yet
<fabbione> so that's not a problem
<fabbione> it will take the latest automatically
<daniels> my X uploads are the least of your worries, dude
<fabbione> i know
<fabbione> i just wanted to be sure :)
<daniels> i'd be a little more concerned about the eleventy hojillion packages that just got autosynced
<fabbione> ehhehe
<Nafallo> 942 and counting ;-)
<fabbione> elmo: can we please remove speedtouch package from dapper completely? Md did remove it from debian too
<fabbione> elmo: and he did ask if we could do the same. thanks dude :)
<fabbione> (if you need an rt, just say so ;))
<ajmitch> fabbione: funnily enough I still use speedtouch on the old sarge box downstairs
<fabbione> ajmitch: well it has been removed from Debian for a reason i assume :)
<ajmitch> yes, it's not needed with kernels >= 2.6.10
<ajmitch> but I haven't got the speedtch module to work successfully for me yet :)
* fabbione builds his first dapper package on sparc
<slomo> elmo: can you please sync cli-common from debian/unstable? the ubuntu changes can be dropped and sync-permission by tseng ;)
<Nafallo> slomo: he said he wanted sync requests on e-mail till things get less to do :-)
<slomo> Nafallo: thanks... good to know :)
<pitti> Good morning
<bddebian> Heya pitti 
<dredg> morning pitti
<ajmitch> hi pitti 
<fabbione> hey pitti
<pitti> yay, dapper!
* pitti uploads his new crack
<fabbione> pitti: ahaha join the queue :)
<pitti> wow, I can't beat daniels, though :-)
<Nafallo> morning pitti :-)
<daniels> unstoppable.
<Nafallo> daniels: tsss, auto-changes beats you hard enough :-)
<daniels> Nafallo: auto-changes is cheating
<daniels> it's using an aimbot
<daniels> pitti: so, um, do we support any of the VNC servers?
<Nafallo> hehe :-)
<fabbione> pool/universe/c/crack/crack_5.0a-8.dsc
<fabbione> hey we got even new CRACK!
<pitti> daniels: hm?
* Nafallo giggles
<pitti> daniels: this vino thingy
<daniels> pitti: is it based on the standard X server codebase?
<pitti> daniels: no idea, sorry
<pitti> daniels: but it build-deps on many X libraries
<pitti> so maybe it doesn't duplicate (too much) X code
<pitti> ah, wait, does dapper use LP or the good ol' way now?
<Nafallo> good ol' :-)
<daniels> pitti: okay, I think we're safe
<daniels> pitti: if the other vnc shite is in universe, then we don't need to do another USN for the software fb core bug
<pitti> argh
<pitti> infinity: I accidentially uploaded the new pkgstriptranslations
<ajmitch> pitti: phpmyadmin patch uploaded to breezy-security
<pitti> ajmitch: thanks
<HiddenWolf> holy hell, people seem to have saved up a few uploads for dapper. ;)
<Nafallo> where people is daniels ;-)
<HiddenWolf> Nafallo, just wait till seb wakes up. ;)
<Nafallo> hehe
<Nafallo> 131 uploads and counting from daniels ;-)
<fabbione> new redhat cluster suite is up :)
<fabbione> too bad nobody can use it yet :)
<daniels> those are just the ones I did yesterday.  i haven't uploaded the ones I've been saving yet.
<bob2> there needs to be some way to make /etc/apt/sources.list harder to edit for users
<Lathiat> heh
<daniels> er, s/yesterday/today/
<ajmitch> bob2: sure, write it in a format like elisp
<bob2> ajmitch: I was thinking encrypting symmetrically with gpg
<ajmitch> same thing
<bob2> with the pass phrase "Yes I know what I am doing.  If I use backports, I will not whinge to anyone but the backport people."
<ajmitch> bob2: but, but, backports are official! :)
* Lathiat smirks
* bob2 looks around for backports people supporting broken packages in #ubuntu, and comes up empty
* Yagisan wonders why they never bitch to MS for "backports"
<ajmitch> bob2: #ubuntu has beaten all love of humanity out of you? ;)
<Lathiat> Yagisan: because they download everything
<daniels> bob2: -iacknowledgethatthistoolisnotabenchmark didn't even work for everyone
<Lathiat> Yagisan: in new, separate versions
<ajmitch> daniels: isn't getting 5000+ FPS in glxgears the most important thing?
<bob2> hahaha
<daniels> 17500+, dude
<daniels> get with the program
* Lathiat only gets 1000 :(
<Lathiat> im totally inadequate
<ajmitch> oh sorry
<daniels> (and then, bitch about it looking 'slow')
<ajmitch> I've got a gf2 mx
<Lathiat> should i go buy a new $1600 graphics card now?
* Yagisan thinks all new users need to acknowledge Ubuntu isn't f*cking Windows
<daniels> 'ITS LIKE MY MONITOR ONLY DISPLAYS 75 FRAMES PER SECOND OR SOMETHING'
<dredg> it's cos teh packages aren't optimised for i686
* Lathiat laughs at dredg 
<ajmitch> -ffast-math all the way
<Lathiat> daniels: you should add -ffast-math to xorg
<Lathiat> and mesa
<dredg> you should build them with --with-go-faster-stripes and --omfg-kill-it-in-teh-face
<daniels> i'll build mesa with -pipe
<HiddenWolf> LOL
<HiddenWolf> daniels, dude, where is the xorg package changelog, I was hoping for some good reading. :)
<daniels> everything I've uploaded today has been uninteresting, sorry
<daniels> just 'New upstream (version|release)', sometimes with 'new versioning scheme (argh|bah|sigh)' appended, sometimes with typos.
<ivoks> uninteresting?
<ivoks> 300 messages
<ivoks> :)
<daniels> changelog-wise
<bob2> I'm going to make my own internet
<daniels> and I've only done 132 uploads, not 300
<bob2> with a no-moron rule
<HiddenWolf> ow, I was getting all excited. :(
<bob2> then there won't be so many pdfs in my google results
<dredg> bob2: you're thinking too small
<Nafallo> bob2: squid? :-)
<dredg> bob2: really. genocide. cleanse the genepool
<daniels> HiddenWolf: even xorg_6.9.99.1-1 is really dull
<HiddenWolf> daniels, I was hoping for something to match the linux-meta "new trust a kernel developer" changelog. ;)
<mdz> bob2: &as_ft=e&as_filetype=pdf
<bob2> mdz: you are my new hero.
<mdz> speaking of heroes
<mdz> everyone remember to bring HALLOWEEN COSTUMES to UBZ
<pitti> argh
<daniels> what's halloween?
<HrdwrBoB> daniels: it's where children get abducted by strangers
<mdz> http://en.wikipedia.org/wiki/Halloween
<bob2> daniels: don't eat any candy any of them give you
<mdz> or perhaps hallowe'en in montreal
<daniels> hallowen
<mdz> in Colin's case, perhaps Pooky Night
<daniels> isn't pooky some kind of stuffed toy?
<mdz> pitti: for a moment I misread your postfix upload as as postgresql upload
<mdz> pitti: and I wondered why postgresql would link to libmysqlclient
<pitti> mdz: hehe, plan of the world domination plan, but ssshhhht :-)
<pitti> s/plan/part/
<bob2> you should totally make a mysql emulation layer for postgresql
<pef> hello
<daniels> pitti: btw, you win the 'first reverted upload in dapper' award
<bob2> for?
<daniels> pkgstriptranslations 18 and 19
<fabbione> well i win the award for the first uninstallable pkg :)
<tepsipakki> FYI: all of the 650 hoary cd's we got have been dealt out
<tepsipakki> woohoo
<mae> when will OOo 2.0 final make it into breezy, or will it at all?
<daniels> it won't
<fabbione> daniels: doko was planning a -updates afaik
<pitti> daniels: yes, I just tossed all the prepared uploads on chinstrap into the queue, but forgot about that one :-/
* fabbione wins the award for yet another breezy upload :/
<daniels> fabbione: you've still got a ways to go yet
<fabbione> daniels: i probably managed to fix it before katie run :)
<fabbione> daniels: you have 10 hours advantage due to TZ :)
<daniels> hah
<fabbione> hmm i guess katie or lists is very busy
<daniels> fabbione: katie is slammed.  a bunch of my uploads were between four to six hours latent.
<fabbione> daniels: she is catching up.. only 5 minutes delay
<fabbione> i remember when we did the first sparc import of hoary, it took around 10 hours to make her digest all of it
* fabbione wonders if MOM is running
<mvo> hey seb128 
<ajmitch> hi seb
<fabbione> hey seb128 
<fabbione> hey mvo
<mvo> hey fabbione 
<seb128> hi mvo fabbione
<fabbione> mvo: any plan to upload apt? ;)
<frans-th> hi all, i read that the ubuntu next version the drake have a branding derivative
<frans-th> can i join the team?
* fabbione is really looking forward for the 64bit mem allign fix
<frans-th> https://wiki.ubuntu.com/BrandingForDerivatives
<mvo> fabbione: oh, dapper is open :) 
<fabbione> mvo: yeps :) you are a 1000 uploads late by now :P
<ajmitch> mvo: you'd better catch up
<mvo> happens to me all the time ...
<zyga> morning 
<zyga> dapper is open? :-)
<ajmitch> zyga: yes..
<frans-th> dapper?
<zyga> great :>
<frans-th> anyone,know how to join the drapper development?
<frans-th> es the branding
<frans-th> zyga?
<zyga> frans-th: nope, I'm just happy because we can finally move stuff that was 'too late for breezy'
<carstenh> "#ubuntu-motu for getting involved in development"
<frans-th> motu said must this channel :(
<highvoltage> in Afrikaans, "dapper" means "brave" :)
<ajmitch> carstenh: the MOTU team can't really help with derivatives..
<ajmitch> and he disappears..
<carstenh> ajmitch: hmm, you are right in both cases ;)
* ajmitch didn't get an answer as to what he was actually wanting to do
<dholbach> morning
<ajmitch> morning dholbach 
<dholbach> hi andrew
<seb128> Hi dholbach
<dholbach> hey seb
<mvo> hey dholbach 
<dholbach> hey michael
<mvo> jamesh: around?
<jamesh> mvo: yeah
<mvo> jamesh: I was playing with pyhton-vte and I wonder how the "child-exited" signal is wrapped. are signals done automatically by the code-generator? it seems to be that the (important) pid and status arguments of the signal are missing when it reachs my python code
<mvo> jamesh: any idea where I should look? define a child-exited signal in vte.defs?
<jamesh> mvo: signals are wrapped automatically based on introspection information
<jamesh> mvo: looking at the header file, child-exited doesn't have any extra arguments
<mvo> jamesh: right, my bad. there are two "child-exited", one from VteTerminal and one from VteReaper. I need the later one, but asked for the former :/
<jamesh> mvo: I don't know if the reaper is exposed through the public API
<jamesh> mvo: you could file a bug report asking for the extra signal arguments
<torkel> fabbione: ok if I add some things to UbuntuClusters in the wiki?
<mvo> jamesh: I think it is (it's at least documented). I will rather do it myself, upstream wasn't very responsive in the past :/
<fabbione> torkel: please add them as comments at the end and i will merge them
<torkel> fabbione: sure
<jamesh> mvo: note that adding the signal arguments would be an API breakage for things like Python
<fabbione> torkel: specially if you are not going to be at UBZ, make your comments extremely detailed and clear
<mvo> jamesh: I think I will add a wrapper for the reaper. does that sound sane?
<jamesh> mvo: I suppose so.
<\sh> grmpf
<\sh> -EDANIELSSPAM
<sivang> Morning all
<torkel> fabbione: I have added some comments. Not very detailed yet though
<torkel> fabbione: I will try to add more details later...
* fabbione checks
<pitti> ajmitch: hmm, phpmyadmin does not build for some reason
<fabbione> torkel: FAI is deployment related. there is another spec for that
<fabbione> torkel: and that's not exactly the target for clusters
<torkel> fabbione: so is oscar
<fabbione> torkel: *  How to make sure all nodes are up to date?  ... -> there is another spec for this too.. https://launchpad.net/distros/ubuntu/+spec/network-wide-updates
<sivang> torkel: Oscar the grouch ?
<fabbione> torkel: yes, oscar is a full collection of everything..
<fabbione> torkel: we need to strip down what's required out of it. it's only under investigation
<torkel> fabbione: I added FAI as other deployment tools already was mentioned
<fabbione> torkel: *  How to distribute /etc/passwd and/or a.... https://launchpad.net/distros/ubuntu/+spec/network-authentication
<fabbione> *  How to handle monitoring of nodes .. this is definetely another spec.
<fabbione> torkel: the spec target is to find cluster implementations
<fabbione> and in case how to merge them into ubuntu
<fabbione> all the other bits like deploying, monitoring etc, if they are not part of the implementation itself -> another spec
<ajmitch> pitti: oh?
<ajmitch> pitti: I didn't see a build log last I checked
<pitti> ajmitch: no idea why - we should ask infinity when he is awake again
<pitti> ajmitch: build logs are not published anyway
<pitti> ajmitch: but I get failures emailed 
<ajmitch> HM
<torkel> fabbione: sure, but to be able to merge them into ubuntu you have to be aware of all the other specs. Maybe add an link to them from the cluster spec?
<torkel> fabbione: feel free to remove/edit my comments if you think they are out of the scope for the spec
<fabbione> torkel: yes, they will be linked during the spec discussion
<ogra> morning
<ogra> pitti, which hal version will dapper get ? g-p-m will need the backend functionallity from the latest i think... thos will obsolete the power-manager package (hal will need a replaces i guess)
<pitti> ogra: I already uploaded the latest and greatest (0.5.4)
<pitti> ogra: but I expect that more 0.5.x versions will follow
<ogra> hmm, i think it 0.5.5 
<pitti> not sure whether we will get 0.6, though
<pitti> ogra: I didn't see the 0.5.5 annoucement
<ogra> nope, thats current cvs ... but it will get released during dapper ...
<ogra> (the controverse hal version with more functionallity :) ) 
<pitti> ogra: I think 0.5.5 should be a safe bet
<ogra> thats the one that starts to actively manipulate stuff afaik
<ogra> at least how i understood hughsie
<pitti> ogra: that sounds like hal getting on the wrong track
<ogra> nope
<pitti> we discussed that on the mailing list
<pitti> and I gave my comments there
<ogra> not as long as it doesnt get renamed to HIL :)
<ogra> if its only a info layer, be it, but ten dont call it HAL
<ogra> *then
<ogra> i remember we discussed it here before already ;)
<ogra> and i dont think its the wrong track :)
<pitti> "HAL is a piece of software that provides a view of the various hardware attached to a system"
<pitti> ogra: making hal a centralized actor that runs with root privs *is* wrong
<ogra> it should also provide a possibility for user interaction
<pitti> it would become the single point of failure, and prefered (and highly vulnerable) attack vector
<pitti> ogra: no, there should be specialized daemons or at least callouts for that
<ogra> lets not have this discussion again, you wont convince me and i wont convince you and in the end its davidz's call :)
<ajmitch> pitti: I blame yada for any & all phpmyadmin issues
<pitti> ajmitch: I did not get a FTBFS mail, so I blame the buildds
<ajmitch> pitti: it's more fun to blame yada
<pitti> ogra: right :-) I try to convince him
<ogra> heh :)
<ogra> dholbach, the new gnome-power-manager for you to play with for your BOF is in ... have fun with it :)
<pitti> mvo: are you interested in the "hide admin programs for non-sudoers" spec?
<\sh> damn
<mvo> pitti: a bit, I would like to hide "update-notifier" as well
<pitti> mvo: I'd be interested to write a small program that decides whether the user has sudo rights
<pitti> mvo: but I don't want to mess with the higher levels (the gnome part)
<mvo> pitti: I think a small program is all we need, a lot of work has been done here during SOC (IIRC)
<ogra> pitti, mvo, YAY for that !! its urgently needed for edubuntu ...
<pitti> ogra: this little backend is a bit delicate and needs suid root, that's why I want to have an eye on it
<ogra> yup, thats fine as long as i get the functionallity :)
<ogra> its very high priority for me...
<pitti> mvo: we just need a small program "user-is-admin" that decides whether the user can suid to root and execute arbitrary programs, and deliver the result in the exit code, right?
<seb128> pitti: I am, I give some google bounty work to my student to hide the admin stuff to non-admin users
<pitti> seb128: is there any backend yet?
<ogra> pitti, cant it just read the groups and if admin isnt in the list act like needed ? 
<seb128> pitti: no, but the GNOME part is done
<pitti> ogra: that only works for the breezy default config
<pitti> ogra: not for warty updates or customized ones
<seb128> pitti: it's hacky, atm it works on "are you a member of the admin group"
<pitti> seb128: ah, cool
<\sh> ogra: it should be available for all linux distros ;)
<pitti> seb128: ok, that covers at least 90% of the cases
<ogra> pitti, enough for me ;) edubuntu didnt exist before breezy
<pitti> seb128: I thought about adding a sudo option that does that, to reuse the already existing sudo code
<seb128> pitti: remember, we poke you about that with lllmanuelll
<mvo> pitti: a small app like that would be great. prefereable with a argument "can user do a spefic command"
<pitti> mvo: yes, even better
<pitti> mvo: like a sudo --dry-run
<seb128> pitti: we could use "sudo -l <cmd>"
<pitti> mvo: sudo --permitted, or whatever
<seb128> pitti: but we need to use "Defaults listpw=never" which is not the current default
<seb128> or it asks for a pwd
<pitti> seb128: right, we must avoid asking for a password
<seb128> listpw=never :)
<pitti> or that, right
<pitti> seems that almost everything is already theren
<pitti> s/n$//
<seb128> hum
<seb128> the ubuntu sudo doesn't has this feature :/
<pitti> well, and it would break upgrades
<pitti> a little coding is necessary, I'm afraid
<seb128> yeah :/
<pitti> mvo: shall we two take AutomatedProblemReports again?
<pitti> mvo: implementing this early could be highly beneficial for stabilizing dapper
<sivang> seb128: anything I can offer a hand with ? are you talking about users-admin ?
<seb128> pitti: I really want this debug archive and the automatic debug bt stuff
<pitti> seb128: me too
<seb128> pitti: we spend like half of the bug triage ressources to ask for debug backtraces
<seb128> and to make debug packages
<seb128> and people don't get the issue again, so never get a good bt, etc
<pitti> seb128: and in general I have the feeling that breezy's gnome is pretty unstable
<seb128> sivang: pick any g-s-t bug and fix it :) no, no users-admin
<pitti> unless I get a second security team member, I won't have too many time for it
<pitti> but it is necessary
<seb128> pitti: crashy you mean?
<pitti> seb128: yes, I got some random nautilus crashes recently, which I could not reproduce
<pitti> things like that
<pitti> or that gthumb bug when changing to /
<seb128> sending a backtrace is useful you know :)
<seb128> right, but gthumb is not a part of GNOME and mvo has fixed the bug
<dholbach_>  seb128, pitti: going to upload gthumb in a sec
<sivang> seb128: but you'd need to have -dbg installed all over to get a meaningful one, no?
<pitti> ajmitch: any reason why you created a new ProactiveSecurityBof page instead of using the old -Roadmap?
<dholbach_> the changes were to much to get them in before breezy, we'll push it through backports
<pitti> sivang: that's what we want to change
<crimsun> pitti: something along the lines of http://www.sudo.ws/pipermail/sudo-users/2004-March/001976.html ?
<seb128> dholbach_: the fix is a one liner
<seb128> dholbach_: that's a good candidate for -update
<mvo> seb128: I haven't uploaded it IIRC, should we move it to breezy-updates? 
<dholbach_> hm, yes might be, but the changes in 2.6.8 fixed quite some other stuff too
<sivang> pitti: I'm interested in that as well, should I subscribe to AutoProblemReports if not already have?
<pitti> sure
<seb128> mvo: yep
<seb128> dholbach_: stop trying to push new versions to a stable distro
<pitti> crimsun: hm, but doesn't that only decide whether or not the user needs a password?
<pitti> dholbach_: why not just throw the patch into breezy-updates?
<dholbach_> seb128: that's why i chose backports, we have it now, i don't see why we shouldnt use it
<dholbach_> pitti: right
<crimsun> pitti: no, whether the user is qualified to use sudo. The next message in the thread is more explicit: "hoping that there was something in the usage that I was missing with
<crimsun> sudo that would not prompt me for a password, and would just silently
<crimsun> sorry
<crimsun> fail (nonzero error code response) and/or a simple stderr error msg"
<ajmitch> pitti: I just wanted somewhere clean to start & write up some notes before UBZ
<crimsun> pitti: ah, I see what you're saying now (RE: tokens)
<pitti> crimsun: right; -S -v < /dev/null does not make any difference for an admin and non-admin user
<pitti> ajmitch: do you want to lead that and I second? or the other way round? any preferences?
<pitti> ajmitch: I'd rather play Second
<ajmitch> pitti: doesn't worry me
<ajmitch> you'll probably have plenty of BOFs to lead :)
<pitti> ajmitch: I have too much other stuff to do to be able to actively code
<pitti> yes
<ajmitch> ok, I'll lead then
<pitti> ajmitch: I add you, I'm editting the page anyway
<ajmitch> ok
<pitti> ajmitch: will you add something to the initial spec?
<ajmitch> yes
<ajmitch> irc meeting in a few hours for it
<seb128> meeting for what?
<ajmitch> ubuntu-hardened specs
<seb128> k
<mdke> dholbach, around?
<daniels> for those that can't wait for NEW, I just bombed chinstrap:~daniels/tmp/dapper/ at the archive.  have at it.
<dholbach>  mdke yes
<Keybuk> tricky decision
<mdke> dholbach, query
<Keybuk> am going to reinstall my laptop ... do I go for breezy, or do I play it dangerous and put dapper on it? :p
<mdke> both
<fabbione> Keybuk: you already asked :) go for breezy
<fabbione> Keybuk: pointless to ruin your spare time at UBZ fixing your lappy ;)
<ogra> how many hours is dapper old ? 12 ?
<dholbach> less i guess
<fabbione> ogra: probably..
* ogra thinks Keybuk loves the risk :)
<fabbione> with at least a 1000 pkgs
<ajmitch> that's why we have LVM
<fabbione> ajmitch: ehehhe
<Keybuk> I lurve the disk
<Keybuk> uh, risk
<Keybuk> arrrrgh
<Keybuk> Firefox has opened a movie
<Keybuk> I now have to be very careful to note which web pages I have open, and what form contents havent been saved
<Keybuk> because it's going to crash when I try and move off this page
* Keybuk criess
<Diziet> I wasn't aware of this bug ...
<ogra> probably a dapper bug :)
<Keybuk> Diziet: it's entirely consistent
<Keybuk> if the totem video thing opens
<Keybuk> firefox crashes
<Treenaks> Keybuk: I have that too.. on all kinds of videos
<Treenaks> Keybuk: mpegs, theora, divx, etc.
<Diziet> Hmm.  Similar to 14882, perhaps.  If that could be said to be coherent enough for things to be similar to it.
<infinity> pitti : !
<pitti> Hi infinity 
<infinity> pitti : You uploaded pkgstriptranslations with the distaddfile change? :/
<\sh> wow...the syncs are flying in...the uploads are spamming my inbox...great
<infinity> pitti : Oh, then reverted it. :)
<infinity> pitti : Yay.
<pitti> infinity: yes, sorry
<infinity> No harm done.
<pitti> infinity: I just uploaded all my stacked .changes files
<pitti> infinity: can you please have a look why phpmyadmin doesn't build?
<pitti> infinity: (breezy-security)
<Diziet> (Why is it possible for a plugin to crash the browser, anyway?)
<infinity> Did it fail?
<pitti> infinity: no, I did not get any mail
<infinity> Nope, me neither
<Mithrandir> Diziet: because it's dlopened and run in the browser's address space?
* infinity goes to find it.
<Diziet> mith: What a ridiculous way to do things.
* ajmitch only got the accept mail for phpmyadmin
<Mithrandir> Diziet: how would you rather do it?
* infinity waits for rothera to upload crap...
<infinity> pitti / ajmitch : Anyhow, it build fine, just hasn't uploaded (yet)... Tracking that down.
<ajmitch> infinity: thanks
<Diziet> Any way that protects the browser from a buggy plugin.  It's not like there aren't loads of ways of doing that.
<ajmitch> there goes my chance to blame yada again
<infinity> Hrm, that went fine.
<infinity> ajmitch : As it turns out, you're just impatient.
<ajmitch> infinity: surely not
* ajmitch uploaded a few hours ago :)
<ajmitch> I was just told the build failed
<infinity> Yeah, pitti's just trying to make me look bad. ;)
<ajmitch> heh
<pitti> infinity: to the contrary, I just want to demonstrate the world how quickly you can solve all kinds of buildd problems
<pitti> :-)
* infinity laughs.
<infinity> I'm not even awake yet, either.
* infinity bows.
<infinity> THank you, I'll be here all week.
<ajmitch> what timezone are you in now?
<fabbione> infinity: i think amd64 buildd is not uploading?
<infinity> ajmitch : Location, or sleep pattern?
<ajmitch> infinity: location
<slomo> pitti: did you test the mplayer fixes on both distris?
<infinity> fabbione : Which one? :)
<pitti> infinity: you know the famous scene from Star Trek where Scotty needs 8 weeks for repairs?
<\sh> dapper update *harhar*
<pitti> slomo: testing is your responsibility :-)
<infinity> ajmitch : Melbourne, +10... Sleep pattern, no idea.
<fabbione> infinity: probably all of them.. if there is one going..
<ajmitch> heh
<pitti> slomo: I just looked at the patch
<fabbione> infinity: i can only see ppc and i386 pkgs coming down via rsync
<kamstrup> Is pygtk broken in Breezy?
<infinity> Oh, yay.  Go me.
<ajmitch> kamstrup: not that we've heard
<slomo> pitti: bah... ok, then i will upload on monday ;) need to create warty and hoary chroots...
<kamstrup> Yesterday morning I start getting "AttributeError: 'module' object has no attribute 'CAPI'"
<infinity> I didn't re-enable the buildd user's crontab after I stole my buildds back from Kinnison. :)
<infinity> La la la!
<kamstrup> whenever I import gtk
<fabbione> infinity: ahahahha
<pitti> slomo: well, if the patch works on breezy, it will work on warty and hoary, too, right?
<ajmitch> kamstrup: you've been installed anything extra in that time?
<ajmitch> oh dear
<ajmitch> my english is going downhill rapidly :)
<kamstrup> ajmitch, yes and no...
<kamstrup> I installed some stuff on my box at home....
<slomo> pitti: yes, it should... but there's a remaining risk imho ;) the stuff builds fine on breezy (even the warty/hoary packages) but i don't have any pbuilder chroots for hoary and warty yet
<kamstrup> I figured I broke something, but I tried it on my uni-box just now...
<kamstrup> -- never done anything else than dist-upgrading on it...
<kamstrup> and now
<pitti> slomo: right, you should test if it builds
<kamstrup> mikkel@smallpox:~$ python -c "import gtk"
<kamstrup> Traceback (most recent call last):
<kamstrup>   File "<string>", line 1, in ?
<kamstrup>   File "/usr/lib/python2.4/site-packages/gtk-2.0/gtk/__init__.py", line 37, in ?
<kamstrup>     from _gtk import *
<kamstrup> AttributeError: 'module' object has no attribute 'CAPI'
<pitti> slomo: but testing whether it *works* is probably enough to do it on one releaes
<ajmitch> kamstrup: sounds more like an #ubuntu question, it doesn't happen on a standard install
<ajmitch> & CAPI related things seem to be ISDN
<slomo> pitti: ok, will do on monday ;)
<kamstrup> this *is* a standard install
<\sh> kamstrup: 
<\sh> shermann@nc6000-laptop:~/pbuilder/etc$ python -c "import gtk"
<\sh> shermann@nc6000-laptop:~/pbuilder/etc$
<kamstrup> I tried to get someone one #ubuntu to help me, but not much luck
<\sh> nothing
* ajmitch is probably wrong about isdn though :)
<kamstrup> This freaks me out...
<\sh> kamstrup: new default install of breezy
<ajmitch> hi sabdfl 
<kamstrup> ajmitch, sh: One last thing and I'll stop buggin you :)
<kamstrup> python -c "import gtk; label = gtk.Label ('Hello world'); win = gtk.Window (); win.add (label); win.show_all (); gtk.main()"
<kamstrup> If this works for you I go shut my trap :)
<seb128> works for me
* ajmitch also
* mvo too
<kamstrup> well, must be me then... Which is a good thing :)
* zyga is back from work :-)
<sabdfl> hey all
<jsgotangco> hey sabdfl 
<jsgotangco> moin
<sabdfl> moin moin! gearing up for montreal...
<jsgotangco> nice
* jsgotangco dies in envy...
<Diziet> Morning.
<Kamion> ok, thank christ I arranged for dapper-changes mail filtering a few days ago
<fabbione> Kamion: ehehhe
<mjg59> I so need to set up dynamic DNS
<fabbione> point
<fabbione> i should set ip over dns
<Lathiat> hehe
<Diziet> There's no space in the spec template for `other versions of this same kind of thing'.  AKA `related'.
<\sh> moins sabdfl 
<\sh> woo..my first build with new dapper pbuilder ,-)
<Lathiat> hehe
<Lathiat> cool
<Kamion> which is a bit useless since dapper isn't debootstrappable. I'm fixing that now ...
<Diziet> mjg59: dynamic.greenend.org.uk ?  /info/dyndns.text.
<dholbach>  merci, Kamion 
<\sh> kamstrup: pbuilder-breezy create -> cp breezy-base.tgz dapper-base.tgz -> pbuilder-dapper update ,->
<\sh> aeh kamion
<mjg59> Diziet: Nah, I want to tie it into DHCP so the HUGE PILE OF LAPTOPS have consistent DNS
<Diziet> Oh, I _see_.  Have fun.
<Mithrandir> mjg59: that's easy enough to do.  I think it
<Mithrandir> 's documented too
<Keybuk> Kamion: that's where verp-based delivery comes in handy
<Kamion> jbailey: hope you noticed that initramfs-tools got autosynced from Debian ...
<Keybuk> it's resilient to jdub randomly subscribing you to ultra-high-traffic lists :p
<ajmitch> Kamion: that sounds like a recipe for disaster
<Mithrandir> Kamion: ew, that's suckage. :-(
* dholbach won't reboot anything :)
<ogra> dholbach, you actually *run* dapper ? 
<tseng> dholbach++
<ajmitch> ogra: you mean you don't? 
<dholbach> :))
<ogra> crzy guys
* ajmitch only has a pbuilder setup so far :)
<\sh> hahaha...
<Kinnison> Keybuk: verp-based delivery?
<tseng> i was about to debootstrap
<\sh> ready to break kubuntu dapper ,->
<ajmitch> tseng: dist-upgrade from breezy will be the only way
<Keybuk> Kinnison: ie. I'm subscribed as scott-ubuntu-changes@netsplit.com, and have a delivery rule for that which explicitly puts it in the right folder
<tseng> ajmitch: i know.
<jsgotangco> crazy
<Kinnison> Keybuk: aah
<Kinnison> Keybuk: I do that based on the List-Id :-)
<jdub> good morning freedom lovers
<Keybuk> Kinnison: that doesn't work when jdub subscribes you to the new list ... see above
<tseng> good morning less perky jdub 
<Mithrandir> Kinnison: Keybuk has it all hacked into his qmail crack.
<Keybuk> you get 160 new mails in your inbox that fell through your filters :p
<ajmitch> hey jdub 
<pitti> Hey hey jdub 
<ogra> jdub, already switched to dapper ? 
<Mithrandir> Keybuk: another fix is to beat people who subscribe you to random lists.
<Keybuk> Mithrandir: yes, sadly that didn't stop him doing it *again* this time :p
<ajmitch> yay, 404 errors on everything when I try a dist-upgrade
<Mithrandir> Keybuk: you didn't beat him well enough. :-)
<Kinnison> Keybuk: List-Id:.*-changes@lists.(ubuntu|canonical)
<\sh> lets wait for katie
<jdub> ogra: heh, no
<jdub> tseng: mmm, still sick
<jdub> Keybuk: dude, i will keep doing it as punishment for your lame procmail and mta skillz
<Keybuk> jdub: I don't use procmail
<jdub> (but did fall into my cunning trap!)
<jdub> EXACTLY!
<\sh> there is nothing better then have server side imap filtering ,-)
<ajmitch> jdub: you didn't subscribe everyone to ubuntu-changes-auto? 
<jdub> nein
<fabbione> jdub: wouldn't be much easier to just have ubuntu-changes@ instead of a list per release?
<\sh> hehehe...jdub learns german...very nice :)
<Diziet> `Brainstorm ideas for making Ubuntu a fun and exciting server platform' ?!
<Robot101> lol
<Diziet> fabbione, have you been eating those mushrooms again ?
<ajmitch> Diziet: security holes are 'fun & exciting'
<jsgotangco> much fun than quake?
<\sh> "Running DoS Attacks randomly from Ubuntu Server install to radom internet hosts like microsoft.com, apple.com or ebay.com, to nag some sysadmins, this is not in main"
<Seveas> \sh, it's been proposed :)
<\sh> Kids, don't do this at home ,-)
<Seveas> ./1337-ddos-tool --duration=1week www.microsoft.com
<Seveas> :p
<fabbione> Diziet: dude.. why don't you read WHO did open it and ask the same question to mdz?
<fabbione> Diziet: anyway that one is mine :)
<fabbione> Diziet: so keep your hands off :P
<Lathiat> Do i have to have my key signed before it'l be allowed for universe upload?
<fabbione> Lathiat: better if you do
<fabbione> spaeking of which
<Lathiat> eh, just i can't until i get my passport, which wont be for a while
<Lathiat> as in a month or more
<fabbione> did we plan a keysign party at UBZ?
<fabbione> Lathiat: are you coming to ubz?
<Lathiat> fab	no
<Lathiat> fabbione: no
<fabbione> ok
<Robot101> can someone fix irssi so it recognises magic keypresses in the cases when they're not the only character returned from read()? :)
<Lathiat> Robot101: its there for a reason
<Lathiat> Robot101: its paste detection
<Lathiat> and it happens because my session locks up
<Lathiat> because the I/O on this machien is locked to hell
<Lathiat> so irssi locks up a bit when flushing its logs out
<Robot101> no, its broken on low latency links
<Robot101> er
<Robot101> high latency
<mjg59> High
<Lathiat> Robot101: you mean high liglatency
<Lathiat> see just happened then :)
<Robot101> if I can type fast enough to make it think I'm pasting, it's fucked
<Lathiat> Robot101: no
<Robot101> >1 character a time does not imply a paste is occuring
<Lathiat> Robot101: it works on how quickly characters come in in succession
<jdub> fabbione: for some reason, we decided against that - don't quite remember why off-hand
<Lathiat> and if your ssh locks up for a second
<Lathiat> or irssi does
<jdub> fabbione: oh, because you want to know which release an upload was for
<Lathiat> all your characters come in at once
<Lathiat> so it looks like a paste
<Lathiat> it could possibly be made a little less sensitive
<jdub> fabbione: for instance, i've had emails to warty and hoary changes lists in the last few days
<fabbione> jdub: ahhh so that's why it's written in the .changes :)
<Robot101> Lathiat: yes, it's buggy
<Lathiat> Robot101: its not buggy
<Lathiat> Robot101: its just a result of tryign to guess things
<jdub> fabbione: we could make it more obvious in the subject, but this seems to have worked so far
<Lathiat> it could be 'tuned' to be better
<Lathiat> so its less 'buggy' in more circumstances than not
<fabbione> jdub: ok
<Robot101> yes it is, sending literal tabs that the user has typed is a bug
<Lathiat> but theres the flip side, of being not sensitive enough to detect some smaller pastes
<Lathiat> Robot101: its *not* a bug
<Lathiat> Robot101: its paste detection
<Robot101> even if it's the result of a poor heuristic it's still a bug
<Lathiat> in past mode, it sends tabs literally
<Lathiat> *paste
<Lathiat> along with most other control codes
<Lathiat> the bug is just that the paste detection is sensitive to too small strings which are often caused by temporary packet drops and/or/ program freezes
<jdub> seb128: oh man, now i want to run dapper!
<Robot101> the resulting behaviour where I type la<tab> and this gets sent over IRC is a bug. :)
<Lathiat> Robot101: right, but the *bug* isnt that it prints tabs literally
<Lathiat> thats just a sysymptom
<Lathiat> im waiting for irssi2 :)
<Robot101> oh this depends on how you define bug :)
<Lathiat> where i can attach a local client
<Lathiat> and it automatically picks up all my sessions and servers over 1 port
<Lathiat> and puts the windows and scrollback back hwo they were
<Lathiat> that == win
<jdub> infinity: ping
<Lathiat> i mean you can use irssi proxy but its ugly and you have to keep up with change  to servers you make, etc
<\sh> Lathiat: it's calleed dircproxy?
<Lathiat> fabbione: so, what can i do about my key issue?
<Lathiat> not being able to upload for the first month ro two of dapper is goign to kill a large patch of contributions
<fabbione> Lathiat: do you live close to any developer?
<ajmitch> Lathiat: surely you've got people in perth & some ID?
<Lathiat> fabbione: jamesh
<Lathiat> fabbione: but i have no id
<Lathiat> no drivers license, no passport yet
<fabbione> Lathiat: no ID at all?
<ajmitch> Lathiat: get a drivers license ASAP :)
<fabbione> Lathiat: sorry, without ID ... nothing i can do
<Lathiat> ajmitch: its on my todo list :)
<Lathiat> fabbione: exactly, hence asking whether i really need it signed to be uploadable
<\sh> Lathiat: u r not living in a cave, have a beard and you're real name is not usama? ;)
<fabbione> Lathiat: well the point is that there must be a way to identify you as person
<\sh> s/you're/your/
<fabbione> Lathiat: without ID you don't even exist :)
<Lathiat> i have a birth certificate
<Lathiat> but people tend to reject that sortof thing
<fabbione> Lathiat: it's useless without a pic
<Lathiat> (no photo)
<Lathiat> fabbione: right
<fabbione> exactly
<Lathiat> i have nothing with a photo
<jamesh> fabbione: yet it can be enough to obtain photo ID ...
<Lathiat> fabbione: this sort of thign is a real bitch for younger people
<Lathiat> fortunately im getting a passport soon to goto lca2006 in jan
<jamesh> Lathiat: get an 18+ card
<Lathiat> jamesh: im 17 :)
<fabbione> jamesh: well you know as much as i do that gpg key sign is also based on trust between people.. if you trust Lathiat, you can sign his key
<fabbione> certainly i am not going to without an ID
<fabbione> given that would be the first time i will ever meet him
<jamesh> I know Lathiat as "that guy who was harassing Linus at LCA2003"
* ajmitch doesn't feel like flying to perth to sign a key, even though he's met Lathiat 
* Lathiat smirks
<ajmitch> then he was 'that ipv6 guy' at lca2004
<stub> The authentication server is going down in 11 minutes which means the wikis will be in read only mode. Downtime is expected to be 30 mins.
<ajmitch> oh goody, an RFP for pqm in debian
* ajmitch retitles
<fabbione> siretart: igor is going back in the rotation as we speak
<siretart> fabbione: cool! :)
<fabbione> siretart: ehhe
<infinity> jdub : pong.
<jdub> infinity: mysql 5 by default in dapper?
<fabbione> jdub: what did you smoke today? ;)
<fabbione> we don't even have 4.1 in main
<infinity> jdub : No, 4.1
<ajmitch> fabbione: but 5.0 has been blessed today :)
<infinity> jdub : 5.0 isn't ready.
<Kamion> GAH, GAH, GAH, GAH
<Kamion> https://launchpad.net/distros/ubuntu/+spec/no-more-devfs
<smurf> fabbione: so? If gnome can get in with a week's notice, surely 6months for a stable mysql should be OK ;-)
<jdub> infinity: mysql dudes seem to think 5.0.5 is
<Kamion> "As of Ubuntu 5.10, the Ubuntu installer relies on devfs, which is a deprecated Linux feature."
<Kamion> *no it doesn't*
<fabbione> Kamion: uh.. didn't you add that one?
<Kamion> no
<infinity> jdub : Colour me crazy, but I don't tend to trust MySQL upstream.
<fabbione> Kamion: ah ok...
<infinity> jdub : I'll look into it, though.
<fabbione> Kamion: i did ask to be added as drafter
* jdub colours inside the lines
<Kamion> we should stop using devfs *paths*, but that's staggeringly low priority
<fabbione> Kamion: just kill it
<jdub> infinity: ok, i'll cc you on email
<fabbione> Kamion: well take into account that .14 has no devfs at all
<fabbione> Kamion: can d-i cope with that? i assume yes
<Kamion> fabbione: who cares? the installer doesn't
<fabbione> Kamion: ok
<ogra> Kamion, ah, come on, its an easy to solve BOF then .... low hanging fruit :)
* fabbione doesn't
<jdub> infinity: (sorry, 5.0.15)
<stub> save your wiki pages. Going into read only mode any minute.
<Kamion> ogra: no, I'm annoyed that the specs page implies that I didn't do something which I did nearly a year ago; and I'm not excited about more BOFs :P
<ogra> yes, its rather windfall then ...
<ajmitch> Kamion: so you can move it to implemented already :)
<infinity> jdub : I'll evaluate it and see if it's doable.  It would further my ReducingDuplication spec to promote 5.0 to the default and kick the rest out, so we'll see if it's actually viable.
<jdub> infinity: what's your ubuntu address?
<infinity> jdub : I suspect the first couple of months of 5.0 GA will be bumpy, so we'll see.
<infinity> jdub : adconrad
<jdub> ta
<jdub> new poll on the fridge
<jdub> "Dapper Drake is a... a) Duck! b) Dragon!"
<Lathiat> haha
<fabbione> ahaha
<pitti> jdub: that was unavoidable, wasn't it...
<Treenaks> jdub: did you get my mail re: video time on Love Day?
<ogra> voted
* pitti added the 5th vote
<jsgotangco> i like duck just to coincide with the bird flu scare...
* Treenaks 4
* jsgotangco hides
<mdke> you better all be voting duck
* mdke shakes his fist
<maswan> ducks are good
<Treenaks> ducks are food!
<maswan> I managed the second vote even, before someone voted wrong. ;)
<Lathiat> and in the first quarter DUCK IS IN THE LEAD
<Lathiat> only 9 votes in...
<Treenaks> 6/3 now
* fabbione sighs
<jdub> Treenaks: mail to me?
<Treenaks> jdub: yeah
<Nafallo> duck!
<maswan> http://www.acc.umu.se/~maswan/bilder/20050706-Ute/index.html?view=IMG_5222.JPG
<maswan> see? ducks are cute
<jdub> Treenaks: i got your mail to sounder
<jdub> Treenaks: and some pgp signing stuff
<mdke> maswan, nice
<ogra> maswan, do you have any statistics about edubuntu iso downloads ? 
<Nafallo> maswan: is that CC-licensed so that ogra can tell ubuntu-artwork about it? ;-)
<Treenaks> jdub: hm, I sent you  another mail after that
<Treenaks> let me check my server logas
<ogra> Nafallo, why me ? 
<maswan> ogra: http://www.acc.umu.se/technical/statistics/ftp/
<Nafallo> ogra: you are active there :-)
<maswan> Nafallo: Hmm.. Ok. Now it is. ;)
<Treenaks> jdub: see pm
<\sh> lol
<ogra> Nafallo, i'm there, but far from being called active ;)
<maswan> ogra: that doesn't seem to list edubuntu though. :/
<\sh> I see sip4-qt3 build ok...but don't have a dapper-changes mail..
<ogra> maswan, yes, just noticed
<jdub> maswan: er, wow, some interesting comparative stats there
<maswan> note that those lack the redirected isos
<ogra> at least edubuntu it jumped to place 48 on distrowatch fro the last month :)
<ogra> s/it/is
<maswan> we will be putting in the stats from the redirect hosts in a while
<pef> will OpenOffice.org2 be bakported to Breezy ?
<Nafallo> ogra: anyway, I sent the link to the mailing-list ;-)
<ogra> fine :)
<ogra> \sh, did you use dapper as distro in the changelog ? 
<\sh> ogra: no ;) 
<ajmitch> \sh: time to break that muscle memory ;)
<\sh> ogra: I have a katie mail, but no dapper mail, but I see the source already build on the buildds 
<\sh> ajmitch: the question of ogra was (IMHO) more rethorical
<siretart> do we already have merge bugs for packages requiring merging from debian?
<ajmitch> \sh: I know, but I've got to break the habit ;)
<siretart> I cannot find them in bugzilla
<Kamion> siretart: no
<ogra> \sh, probably daniels fault :) he's keeping listserver and buildds to busy
<ajmitch> siretart: probably not yet
<\sh> siretart: MoM is not running 
<Kamion> ogra: oh come on, there are far more autosyncs than X uploads ...
<ogra> true :)
<\sh> ogra: it's build cleanly..but I think it's daniels fault to spam the mailserver and mailman ,-)
<ogra> Kamion, but the autosyncs dont spam my nbox ;)
<ogra> *inbox
<\sh> ogra: u r not subscribed to ubuntu-changes-auto ?
<ogra> nope
<\sh> ogra: u should..it's healthy and fun...and u see that your postfix + cyrus imapd 
<ogra> i look at the archive if i look for something
<Nafallo> the auto-changes are done already, no?
<\sh> + spam assassin and virus checker is working 
<\sh> -EANNOYED  two random evo crashes in the last 3 mins
<mvo> \sh: upgraded to dapper already :P ?
<\sh> mvo: no...bug is known upstream..."threading for beginners" problem ,)
<Seveas> dapper-changes@ is stressing my evo too :)
<\sh> mvo: http://bugzilla.gnome.org/show_bug.cgi?id=317790
<Treenaks> Seveas: that's why I use mutt ;)
* mvo pats his mutt
<Seveas> actually it's the auto-changes list :)
* \sh switches back to kmail which  "just works (tm)"
* dholbach gets auto-changes as a digest :)
<\sh> dholbach: sissy ,)
<\sh> hmmm
<\sh> shermann@server3:~$ w 14:39:54 up 157 days, 20:00,  1 user,  load average: 0,19, 0,11, 0,09
<\sh> it's only a little inc of load...nothing serious..
<ajmitch> nice version for xserver-xorg-input-synaptics
<infinity> Oh, c'mon.  People whining about -changes stressing their mail clients should try getting build logs for a day.
<infinity> ajmitch : Yeah, I already gave him shit for that. :)
<infinity> ajmitch : He was like "seriously was the only thing I could think of that was higher than really"
<ajmitch> hah
<infinity> ajmitch : And I said "what about 'rel' or 'release'?" ... "Oh."
<\sh> infinity: all sissies ,-) they all don't know what's good for them ;)
<ajmitch> hello doko 
<infinity> Total 1398 package(s) in state Needs-Build.
<infinity> Christ, autosync day is PAINFUL.
<Nafallo> hihi
<Nafallo> that's ~half of what's uploaded?
<ogra> lo doko
<ajmitch> it'll hopefully settle down by ubz
<infinity> Oh, it'll settle in a day or so.
<pitti> seb128: I think you could be interested in subscribing to https://launchpad.net/distros/ubuntu/+spec/gstreamer-audio-backend
<infinity> It's just the initial sync that sucks, cause there's a backlog of new versions, ongoing syncs after that are fine.
<pitti> seb128: I dumped that part of my brain into a spec and I have some ideas, which we should discuss at UBZ
* fabbione starts the packing dance
* Kinnison doesn't know that one
<Kinnison> fabbione: you'll have to teach me that dance in Montral
<ogra> pitti, i'm vers intrested... i need a networked sound architecture for edubuntu ... i thought of a gstreamer trnasport for that 
<ogra> s/vers/very
<pitti> ogra: feel free to join :-)
<ogra> i'll do ;)
<pitti> I hope that spec subscriptions count in the scheduling
<fabbione> Kinnison: jump, yell and scream randomically around your bag, that's exploding for -ETOOMANYUNDERWEAR
* dholbach -> lunch, getting ca$, dogwalk
<Treenaks> fabbione: just don't wear any
<Treenaks> fabbione: --> problem solved
<ogra> pnts off ?
<ogra> *pants
<Treenaks> ogra: hey, it's called Love Day for a reason, right?
<ogra> heh
<Nafallo> :-)
<ajmitch> Treenaks: and it's UbuntuBelowZero for a reason, too :)
<Treenaks> ajmitch: yeah, so you have an excuse ;)
<Treenaks> </offtopic><ontopic>
<doko> ogra: ping
<ogra> doko, pongedipong
<doko> ogra: did you make the reservation?
<ogra> doko, i mailed info@ as the reservation page says...
<ogra> doko, no answer so far
<Treenaks> ogra: where?
<ogra> Treenaks, dokos hostel
<Treenaks> ogra: the Auberge Alternative?
<ajmitch> ogra: I like your release schedule suggestion about NEW
<doko> ogra: ab wann?
<ogra> Treenaks, nope, thats my fallback
<Treenaks> ogra: that's my primary :)
<ogra> doko, wednesday
<Treenaks> ogra: confirmed & all
<mjg59> Kamion: Fresh Breezy install, none of my partitions have been automounted
<ogra> Treenaks, i'll move to the hotel on sat.... its only for the three days i'm not at the conf
* Keybuk glares at evolution ... get OFF the futex!
<Kinnison> Keybuk: but it loves the futex
<ajmitch> ogra: you arrive in montreal quite early?
<Kinnison> Keybuk: it loves it *LONG* time
<Keybuk> mjg59: yeah, that's known ... it only works if you go through the manual bit
<ogra> ajmitch, 4pm on wednesday
<ajmitch> yes, quite early :)
<ogra> ajmitch, to have some days to look around and see something... and recover from travelling as well
<Treenaks> ogra: 4pm on wednesday? you should be leaving now then?
<mjg59> Kamion: Ah
<ajmitch> good plan
<ogra> Treenaks, ??
<Treenaks> ogra: tomorrow = wednesday
<Treenaks> oh wait
<ogra> Treenaks, my flight goes at 2pm from frankfurt ... 
<Treenaks> 4pm not 4am
<Treenaks> *kicks self*
<Treenaks> ogra: oh it's only a 2hr flight ;)
<mjg59> Kamion: Also, do you want information for identifying more recovery partitions (and what special options they need in order to boot)?
<ogra> Treenaks, yes :-D
<Treenaks> ogra: my flight takes 2 hours from London ;)
<Treenaks> ogra: and 5 minutes from Ams -> London :)
<ogra> Treenaks, cityhopper to london ?
<ogra> with the small 2 engine prop plane ? 
<Treenaks> ogra: no, it's a connecting BA flight
<ogra> ah
<Kamion>   * Diagnosed why partition automounting isn't working in the
<Kamion>     auto-resize case (method and acting_filesystem files not copied over
<Kamion>     to the new partman device directory). Not yet sure why or how to fix
<Kamion>     it.
<Kamion> mjg59: ^-- from my activity report log
<Kamion> mjg59: recovery> sure
<mjg59> Kamion: Ok, cool
<mjg59> Kamion: I filed a bug about the Dell one (which doesn't need anything special to boot). I'll let you know about the Toshiba one (which needs unhiding in order to work)
<seb128> jdub: ah ah :)
<seb128> pitti: will do, thanks
<pitti> seb128: I think we can make this truly rocking
<seb128> how so ?
<seb128> fix dmix to work everywhere and use alsasink? :)
<pitti> seb128: that should be the default
<pitti> seb128: the ALSA upstream guys want to hear bug reports about hardware where it doesn't work
<pitti> and they gave me some hints for debugging
<pitti> seb128: but we should automatically fall back to esd if dmix doesn't work
<pitti> seb128: I have some ideas in my head how to do that
<segfault> what app runs at planet.ubuntu.com?
<pitti> seb128: it needs some gstreamer hacking, but it is not Ubuntu-specific, so maybe upstream even adopts it
<mdke> segfault, planetplanet.org
<mdke> (i think)
<seb128> pitti: gst0.9/0.10 have working autosinks now
<pitti> seb128: "auto" means?
<seb128> pitti: but I don't know how they work, they are supposed to automatically pick the best option for you
<segfault> mdke: thanks
<pitti> seb128: even better
<pitti> seb128: maybe there is nothing left to do for us then :-)
<ogra> first we need to get rid of esd in gnome, dont we ?
<seb128> jdub: gstreamer 0.10 for dapper doable?
<pitti> ogra: we should leave it as a fallback
<ogra> sgh
<ogra> sigh
<pitti> ogra: at least as long as alsa doesn't work everywhere
<Treenaks> seb128: that would ROCK
* ajmitch would love to see esd die quietly
<pitti> ogra: but we want to change the default gstreamer sink to alsa where it works
<ogra> pitti, yup... but still
<seb128> ajmitch: need to fix alsa for that :)
<pitti> ogra: esd merely running is not the pain - it's *using* esd
<sabdfl> https://launchpad.net/people/ubuntu-dev/+poll/tb-nomination-mjg59-2005/
<sabdfl> yay
<sabdfl> looks much better
<sabdfl> has everyone participated in the mjg59 poll?
* ajmitch looks
<ajmitch> yes 
<ogra> yay for typography :)
<ajmitch> looks much much nicer
<Lathiat> Keybuk: hahaha @ your sounder post
<rob^^^> bwahah, it did make it to the fridge poll
<Kinnison> dragon!
* rob^^^ votes Dragon as it is quite obvious that fantastical creatures with long lives should be the basis for stable releases
<mdke> erm
<mdke> you know full well it's a duck
<mdke> any attempt to argue otherwise will be take as some weird Aussie inability to speak english
<Kinnison> aussie?
<mdke> rob^ is aussie
<rob^^^> sorry, US here
<mdke> oh sorry, another rob
<Kinnison> and UK here
<mdke> damn that is confusing
<rob^^^> oh
<jbailey> Kamion: Eh, really?
<jbailey> Hmm
* mdke retreats
* jbailey can always pull the breezy source to get the missing bits.
<robertj> ahh better
<robertj> There needs to be a Duck Season/Dragon Season wallpaper now ;)
<Kamion> jbailey: no "ubuntu" in the version so autosync wasn't inhibited
<jbailey> Kamion: Ah, okay.  I had assumed it checked the .orig.tar for sanity (or the .tar.gz)
<Kamion> jbailey: nope, it's purely on version
<jbailey> doko!
<jbailey> Kamion: 'kay.  I wanted to make it non-native for Dapper anyway, to make syncing with Debian easier (since otherwise we're racing version numbers.  I hate the recent Debian policy change that says you can't have - in native package versions GRR)
<Kamion> that's not a recent change
<Kamion> I remember bugs about that from 1997
<smurf> Kamion: didn't debian start actually enforcing that just recently?
<Kamion> like I say, there've been bugs about it since 1997, and that's always been the policy. it's possible that ftpmaster got a bit stricter about new packages with that problem, but otherwise no
<mjg59> Why do we never manage to ship with working a11y?
<smurf> Ah, right, that bit was in an ftpmaster's what-we're-checking-NEW-stuff-for announcement
<mjg59> seb128: gok refuses to start if installed on a clean system
<Lathiat> mjg59: heh
<Lathiat> perhaps it needs to go on a list of things to check pre-release
<seb128> mjg59: what is it saying?
<mjg59> seb128: "Registry not found"
<mjg59> On a terminal
<smurf> mjg59: I assume it's because all the testers have dirty systems :-/
<mdke> mjg59, known bug
<mjg59> It fails silently if started graphically
<mdke> i attached a backtrace today
<mdke> #13746
<mjg59> In fact, where's atk-bridge?
<mdke> i think it is a missing dependency
<mjg59> Yeah, it's missing at-spi
<mdke> surprising that bug wasn't picked up in time for breezy
<seb128> no
<ajmitch> 24
<seb128> it's not surprising, if you want to have a bug noticed assign it to somebody working on the package
<seb128> or Cc it
<seb128> s/it/him/
<mdke> when I said "picked up" i didn't mean to imply any blame seb128 
<seb128> I know
<seb128> I just say why it has not been fixed
<mdke> yup
<seb128> it's assigned to somebody
<seb128> so out of the radar of other people
<mdke> yeah i noticed that
<seb128> we have enough work to read the bug assigned to other people
<seb128> s/to read/without reading/
<mdke> will you take that bug now?
<mdke> maybe it is a candidate for an update?
<seb128> I'll give it to dholbach who has stepped for a11y stuff
<seb128> yeah
<seb128> dholbach:#13746  for you, need a Depends on at-spi, candidate for -update, thanks :)
<HiddenWolf> seb128, it should be perfectly safe to grab a few debs from dapper, right? Rhythmbox and such.
<mdke> thanks seb128 
<seb128> HiddenWolf: I'm not sure with the xorg changes
<seb128> mdke: np, thank you for pointing it
<HiddenWolf> seb128, that's why I just want the few debs, not dapper itself. :P
<seb128> if you can install them without triggering the new xorg go for it
<seb128> I don't know if the shlibs have changed and force it
<ogra> seb128, is there a way that we can make gnome-settings-daemon happy with two simultaneous logins of one user on the same machine in dapper ? currently the second login with the same user doesnt get settings at all..
<ogra> (i.e. somehow tie it to the DISPLAY variable or something)
<seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=94049 maybe ?
<ogra> s/two/two or more/
<ogra> seb128, yay, cool... its a big prob for some internet cafes running ltsp with th same user all over the place, thanks a lot :)
<seb128> np
<\sh> only to be sure, that i don't have a problem: toolchain is broken now, right? (at least gcc/g++/cpp)
<seb128> elmo: please sync gnome-doc-utils
<infinity> \sh : It is?
<infinity> That was quick...
<\sh> infinity: well...actually I can't compile some g++ stuff anymore...cpp (>=4:4.0) == 4.0.2-something but 4.0.1-something is going to be installed ,)
<\sh> 15:14 < \sh>   gcc: Depends: cpp (>= 4:4.0.2-1) but 4:4.0.1-3 is to be installed
<\sh> 15:14 < \sh>        Depends: gcc-4.0 (>= 4.0.2-2) but 4.0.1-4ubuntu9 is to be installed
<infinity> Oh, joy.  gcc-defaults got synced.
<\sh> yeah...time to go home...
<\sh> laters 
<Kamion> for anyone thinking of merging them, I've got the lsb/lsb-release revamp half-merged - it's rather complicated and requires us to keep up with a bunch of changes, though, so I won't finish them today
<Kamion> /etc/lsb-release is moving to base-files, which will require base-files to take over lsb-release-udeb, etc.
<infinity> Kamion : Does that mean the lsb-release package will get shuffled too, or will it still contain that one binary, just not the conffile?
<Keybuk> jdub: http://planetplus.python-hosting.com/
<Kamion> infinity: the lsb-release binary starts to come from the lsb source rather than its own source, and will just contain the binary not the conffile
<Kamion> Keybuk: hmm, what happens when I move a conffile from one package to another with Replaces: and simultaneously change its contents? will I get a conffile prompt?
<Keybuk> Kamion: mayyybe
<Keybuk> I think that's ok, if they haven't changed the conffile
<Kamion> if dpkg doesn't go looking for the conffile info in Replaced packages, it should
<Kamion> if people are silly enough to change /etc/lsb-release, they should get a conffile prompt :)
<Keybuk> hmm, I don't think it does check
<infinity> If we get a prompt when it's not changed, that's going to be 12 kinds of broken.
<Kamion> I can leave /etc/lsb-release in the lsb-release package until dapper if necessary
<infinity> Kamion : What's the rationale for moving it?.. Just want all release-specific stuff in one place?
<Kamion> infinity: yeah
<Kamion> it's the stated intent of the Debian lsb maintainer, so I was going to go with that unless we had a good reason to do otherwise
<Kamion> spurious conffile prompts are a good reason :)
<infinity> Spurious conffile prompts are hell.  If that can be fixed/avoided somehow, then moving the file makes sense, I guess.
<Diziet> kamion: Replaces isn't relevant.
<Kamion> Diziet: should it be?
<Diziet> No.
<Kamion> why not?
<Kamion> if I want to move a normal file from one package to another, I use Replaces
<Diziet> Um, because it is always right to do the thing that you want.
<Kamion> I'd've thought that the same would go for conffiles
<Diziet> Replaces just lets you avoid the conflict.
<Diziet> Yes.
<Kamion> oh, you mean dpkg should look for the conffile md5sum records etc. throughout all of the status file and ignore what packages they're associated with?
<Diziet> When the new package takes over the conffile (whether this is allowed due to Replaces or due to --force-overwrite isn't relevant) then dpkg should take the old hash and conffile ownership and move it to the new package.
<Kamion> ah, right
<Diziet> Whenever a file is overwritten, the file ownership is transferred.
<Kamion> That's fine by me, as long as it actually does this :-)
<Diziet> This used to be somewhat broken.  Just a mo.
<Diziet> This is related to Debian 108587 and (U. bugzilla 16133).
<Diziet> But that bug only shows up if the two packages conflict (or there's some other reason why the old one is removed first).
<Diziet> And anyway I fixed it.
<Diziet> I don't remember any bug in this area when the file is taken over during upgrade.
<Diziet> And I think this will have been one of the tests I did when I fixed that bug.
<Kamion> all right, I'll test it when moving the conffile from lsb-release to base-files, then
<Kamion> thanks
<Diziet> Right.
<Diziet> NP.
<Diziet> If you have any strangeness, do let me know.
<Kamion> will do
<mvo> JaneW: you created "SmallerUpdates", do you mind if I add something here? debian #128818 is implemented in the apt in debian/experimental
<siretart> tiffany?
<mvo> siretart: yes
<jbailey> https://www.ubuntu.com/ is giving me a bad proxy.  Anyone else seeing it?
<elmo> it'll be back up momentarily
<jbailey> (I think my ISP has a transparent proxy, but I thin khttps should bypass it)
<Znarl> jbailey : It's being worked on.
<jbailey> Cool, I don't have to report it.  Thanks! =)
<fabbione> hey elmo 
<fabbione> elmo: i am packing the luggage here... do i need to bring the AP with me or not?
<elmo> fabbione: if you can do so without causing yourself inconvenience, sure
<pitti> ah, I also have a spare AP if necessary
<ogra> me too
<jbailey> I can also bring mine. =)
<pitti> elmo: do we need more? I have an 11mbit one here
<fabbione> elmo: no problem, i think.. if there is an empty bit in the bag i will add it
<pitti> elmo: can you please sync postgresql-7.4 and postgresql-8.0?
<elmo> pitti: pls send mail, I have to run out RSN
<elmo> pitti/ogra/jbailey: we don't _need_ more, but it wouldn't hurt to have spares/more, but only if it's no inconvenience to you
<ogra> oki..
<pitti> ok
<fabbione> now nobody is going to bring one
<fabbione> wanna bet? ;)
<Simira> fabbione : when do you leave?
<ogra> fabbione, bah... already in the bag
<fabbione> Simira: tomorrow morning around 5am
<fabbione> ogra: ok.. than bring your.. i will keep mine at home
<Simira> fabbione : that early? It doesn't start until monday, does is? We leave on saturday, anyway.-
<fabbione> and i should seriously consider to really finish to pack
<fabbione> Simira: yes, but i have 2 days of holidays there to look around
<fabbione> so it will be tomorrow fly -> 2 days of relax -> saturday
<Simira> fabbione: Sounds nice. you should finish packing,  then. :-) I'm off now, so have a nice trip. See you there ;)
<fabbione> Simira: sure :) thanks and take car3e
<JaneW> mvo: go ahead...
<Amaranth> yay, upgrades
* Amaranth prepares to start crying
<mvo> JaneW: thanks
<sivang> dholbach: are you doing the distro-policy-tracker BOF?
<dholbach> sivang: i signed up for it, yes
<dholbach> seb128: will look at it
<seb128> dholbach: thanks
<sivang> dholbach: I would like to work on this as well, what should I do ?
<sivang> dholbach: (I proposed the spec based on something mdz requested)
<dholbach> sivang: we can spec it together and see how it works out, working on it together doesn't exclude anybody
<sivang> dholbach: ofcourse , cool
* lamont-away flys sunday
<lamont-away> (conflicts on saturday, means I miss the bulk of ubuntu-love day, which sucks.)
<ogra> lamont-away, you come ?
<lamont-away> si
<ogra> wohooo !!
<ogra> :)
<lamont-away> travel days are 30 oct and 6 nov
<pitti> Hi lamont-away! Looking forward to meet you again
<ogra> missing haloween at home ... ?
<lamont-away> not missing the teenager's halloween party on sat evening though...
<lamont-away> that'd be the conflict
<lamont-away> about the only pegan holiday I do anything for is Christmas.
<smurf> lamont-away: Stocked up on sweets yet?
<lamont-away> wife did last night
<smurf> Halloween -- every dentist's cash cow / nightmare ;-)
<lamont-away> ah - just call it by it's correct name: samhain... :)
<smurf> lamont-away: true
<ogra> dholbach, can you make sure the distro-policy-tracker will also cover doc decisions like moving around about ubunt etc ... ?
<ogra> *ubuntu
<ogra> (that'd be a nice enhancement)
<dholbach> it's nothing coded yet, not even specced yet :)
<dholbach> but yes, i'll keep it in mind
<ogra> thanks :) 
<ogra> just to avoid surprises 2 weeks befor release :)
<YokoZar> Wine 0.9 Beta just came out about 30 mins ago.  I'm going to put together the Ubuntu package.  ETA on the package will be 4 hours, since I need to finish D/Ling, compiling, and going to class for the day.
<YokoZar> After that it'll be available on the WineHQ website and we can discuss the future role of Wine on the mailing list ;)
<sivang> ogra: doc decisions are condisered distro-policy ?
<ogra> sivang, as long as they affect derivatives (kubuntu/edubuntu/a11y-buntu) they should be covered in the policy
<sivang> ogra: if you're talking about where docs are placed, and can be found and/or registered against various docs db programs (like scrollkeeper) then it does, otherwise I don't think it has anyting to do with distro policy
<mdke> he is
<sivang> ah ok :)
<ogra> sivang, for me the last minute change of "about ubuntu" two weeks before release generated some work i wasnt aware of the change and having it in a centralized policy document where i could look it up would avoid this in the future :)
<ogra> (indeed its not about doc contents, only about doc handling/plcement)
<sivang> ogra: ah, then I read your last sentence wrong. That is its acutal purpose. Furhter more, as I see it , it should also not allow addition changes to the policy it maintains after a determined period of time as well, so you'll never have weird surprises
<ogra> you wont avoid them completely i guess... but minimizing would already be a big help
<sivang> ogra: noted, I may add it to the BOF ideas then
<ogra> that'd be nice, thanks
<ogra> grumble grumble.... why does editing a spec from my speclist not drop me off to my own speclist afterwards, but to the global one ...
<mjg59> Keybuk: I just booted a system and my wireless interface didn't come up.
<HWolf> who maintains grub in ubuntu?
<Kamion> various people, depending on the problem
<Amaranth> everyone, who touched it last
<Lathiat> just blame it on seb128
<Lathiat> grub bugs are gtk bugs afterall
<HWolf> It's just there's a bunch of homeless grubby bugs in launchpad. :)
<Lathiat> ah
<seb128> no, not me
<Lathiat> just dont assign them to ubuntu-dev :)
* HWolf looks innocently at seb128
<Kamion> HWolf: we'll hunt them down when we switch over fully from bugzilla
<HWolf> Kamion, better to do it before the switch, to keep things clean, right?
<Kamion> HWolf: doesn't matter
<Keybuk> mjg59: was your wireless interface configured by the installer?
<Keybuk> ie. in /etc/network/interfaces
<mjg59> Yes
<Keybuk> ok, does /etc/iftab match /etc/network/interfaces ?
<Keybuk> or have they been flipped around
<mxpxpod> pitti: ping
<mjg59> Keybuk: Looks good
<mjg59>  /etc/network/interfaces has hotplug eth0, and the only auto reference is lo
<Keybuk> right
<Keybuk> and iftab says eth0 is which MAC ?
<mjg59> The wireless
<Keybuk> is there an eth1 as well?
<mjg59> Yes
<Keybuk> ok ... now look at ifconfig -a ... what interfaces are there?
<mjg59> eth0, eth1, lo and sit0
<Keybuk> and do the MACs match etc/network/interfaces ?
<Keybuk> uh, sorry, match /etc/iftab
<mjg59> Yes
<Keybuk> sodomy non sapiens, then
<Keybuk> has it been completely ignored by the boot sequence, and not even plumbed?
<mjg59> Looks like it
<mjg59> I'm guessing the hotplug event got lost somewhere?
<infinity> Does restarting hotplug after boot magically make it work?
<mjg59> What happens if eth1 gets loaded first? How does the hotplug event get generated?
<mjg59> Or, rather, what happens if my wireless device (eth0) is the second network device that hotplug loads?
<infinity> Keybuk : Is coldplugging getting a complete revamp with 2.6.14 and the new udev anyway?
<Keybuk> the uevent (today's fashionable name for hotplug events) would've been totally and utterly  lost
<Keybuk> because it would happen while the initramfs was running
<Keybuk> hotplug should've still picked up the network card
<mjg59> Ok
<Keybuk> there's a bug where the kernel allocates the cards in the _opposite_ order to the installer
<mjg59> I'll reboot soon and see what happens
<Keybuk> so the installer says eth0=wireless, eth1=wired
<Keybuk> but the kernel on a normal boot says eth0=wired, eth1=wireless
<Keybuk> and that goes a bit wrong
<mjg59> I /think/ eth0 was wireless on install
<Keybuk> infinity: yes, in theory we'll regenerate the uevents when we start udev in the initramfs, and do _something_ to remember to trigger the userspace rules when userspace is ready
<Keybuk> I'm not totally sure yet
<mjg59> Keybuk: Ok, it seems repeatable
<Keybuk> mjg59: try swapping the iftab rules around; and adjust network/interfaces appropriately
<Keybuk> ie. make eth1 your wireless and eth0 your wired
<Keybuk> and see if it comes up that way
<mjg59> Running /etc/init.d/hotplug start results in it starting
<Keybuk> yes, that is what I'd expect
<Keybuk> the problem is that we _can_ swap interfaces reliably, just not during coldplugging
<pitti> Riddell: here?
<Riddell> pitti: hi
<Keybuk> once swapped, if it comes up, it's that problem
<Keybuk> (you can also solve it, paradoxically, but adding eth1 to the hotplug thingywotsit)
<pitti> Riddell: do you know about any plans to drop arts in favor of something else?
<Keybuk> actually, no, scrub that
<Keybuk> you can't
<Riddell> pitti: it'll be dropped for KDE 4
<Keybuk> you do need to swap the iftab lines around
<Riddell> pitti: suse have patches to get of it for KDE 3
<pitti> Riddell: maybe you are interested in https://launchpad.net/distros/ubuntu/+spec/gstreamer-audio-backend, for the KDE counterpart
<pitti> Riddell: what's the replacement? ALSA direct?
<Riddell> pitti: I already signead up on https://wiki.ubuntu.com/GstreamerAudioBackend  :)
<Riddell> pitti: kdemm (a thin API), but I'm not sure what that outputs to
<pitti> Riddell: ah, cool; however, you should rather subscribe to the LP page
<Keybuk> mjg59: I'd be willing to bet that your laptop has a ipw2200 in it
<pitti> Riddell: I just talked to Mark and mdz, and it seems that the LP spec page is the source for scheduling the BoFS
<mdz-phone> correct
<mdz-phone> the wiki pages should not even contain this data
<pitti> mdz-phone: it's probably cruft from copying/reusing UDU specs
* pitti cleans up his specs
<mdke> i think some specs were created before that regime was implemented
<TMM> hi all
<TMM> anyone good with the python gnome bindings? :) I'd like to embed a gnome-terminal into a pyglade app, can someone point me to docs or examples please? I can't seem to find any
<infinity> elmo : If you're around, I need apache_2.0.55-3 synced (we misfired and got -2)
<seb128> TMM: use python-vte
<siretart> omg. madwifi-ng is introducing yet another command for configuring wifi parameters :(
<TMM> seb128, ah thanks
<seb128> np
<smurf> If I want a proposed Sarge update of one of my packages to be considered for breezy-updates -- ask for sync, upload directly, or upload with s/sarge/breezy/ ?
<TMM> seb128, "If you actually want to use the widget to get work done, you
<TMM>   should probably be using gnome-terminal." 
<TMM> seb128, very encouraging... :)
<smurf> TMM: Nobody prevents you from dupicating all of g-t's features ;)
<Lathiat> smurf: in general, sync, but im not sure when it comes to -updates
<Kamion> smurf: send mail to mdz with a diff of the proposed update
<Kamion> it should only fix whatever's necessary, and it should be versioned appropriately for breezy-updates
<Kamion> i.e. breezy <= breezy-updates <= dapper
<TMM> smurf, lol :) it doesn't need too much
<smurf> Kamion: Umm, ITYM "breezy < breezy-updates" ;-)
<Kamion> smurf: well, I was considering breezy-updates to be identical to breezy if there was nothing in it, but if you want to look at it that way instead, sure
<Kamion> I wouldn't attempt a sync to breezy-updates personally
<Kamion> I don't think we have the propup stuff from Debian in our katie installation to make the resulting contents of dapper be sane
<mjg59> Keybuk: Sorry, phone call
<mjg59> Keybuk: Swapping eth0 and eth1 works
<mjg59> Keybuk: It's actually a 2915 rather than a 2200, but yeah
<Keybuk> right
<Keybuk> so what happened is the ipw drivers used to sleep for $SMALLNUM after sending a user-space request for firmware
<Keybuk> and userspace nearly always wasn't fast enough, so you ended up with a duffed driver
<Kamion> can we make ntpdate use ntp.ubuntu.com rather than ntp.ubuntulinux.org? the domain grates on me
<Keybuk> so they fixed that by actually moving the "once the firmware is loaded" stuff into a bottom half
<Kamion> (and ntp.ubuntu.com exists)
<Keybuk> but that means the kernel is free to do anything else, like load other drivers
<mpt> doko: By "looks like the same spec URL cannot be used for two specs :-/", did you mean the Launchpad URL, or the Ubuntu wiki URL?
<Keybuk> so what happens is the kernel loads ipwblah first, then the internal one
<Keybuk> but the internal one finishes first and gets eth0
<mjg59> Keybuk: Unfortunately, it's sort of necessary that these machines work correctly after boot...
<Keybuk> this doesn't seem to affect the installer ... I guess there's something different about the way it plugs hardware
<Keybuk> so that's why the eth0/eth1 need to be swapped
<Kamion> not all modules are available from the start; ipw2200 is probably udpkg'ed later than the internal one (which might be in the initrd, even)
<Keybuk> Kamion: yeah, that's another possibility
<mjg59> Keybuk: So, is there a nice easy fix?
<Keybuk> now obviously the userspace shouldn't fall flat on its face when faced with having to swap the names of eth0 and eth1 around (which it has to do)
<Keybuk> we did some fixing for that in breezy and actually did make it successfully swap them
<mjg59> This is stock Breezy 
<Keybuk> as you can see, because you have an eth0 and eth1 that are the same as the installer thinks they should be
<Keybuk> the trouble is that coldplugging then fouls up
<mjg59> Hmm
<Keybuk> because it was coldplugging eth0, which suddenly became eth1 under it
<Keybuk> and both coldplugs end up doing "ifup eth1"
<Keybuk> this is because network coldplugging is done by name
<mjg59> Fun
<Keybuk> we found this reasonably late in the breezy process, and I decided that a ground-up rewrite of that side of hotplug wasn't exactly a stellar idea
<Keybuk> initramfs broke the world
<pitti> hi trulux 
<wasabi_> Hey so there a GPG doc anywhere that explains the proper procedure when your key expires?
<doko> mpt: the "Specification URL"
<smurf> wasabi: the easiest way is to extend the expire date, re-sign it, and re-upload.
<mjg59> D'oh
* mjg59 finds an irritating bug in irda-utils
<ogra> doko, YAY, got answer from the hostel, thanks for helping with it :-D
<Keybuk> mjg59: I have an irritating bug in irda-utils ... it causes my machine to explode
<mjg59> Explode how?
<trulux> hey pitti 
<trulux> howya!
<trulux> (Hi all :))
<seb128> Lathiat: coming to UBZ?
<Lathiat> seb128: nope :(
<Lathiat> unfortunately there from australia is expensive, and i wasn't chosen for sponsorship
<DonChullio> Hi here is a very good Browser Game !!!! http://www.street-conflicts.de.ki !!!!! It's about Gangster and ...... !!!!!!
<mpt> and ......
* mpt will forever be left in suspense
<ogra> *grin*
<Treenaks> ogra: do you expect to have internet in Montreal? :)
<ogra> Treenaks, yup, why not ? 
<ogra> did they shut canada down ? 
<Treenaks> ogra: I don't know... maybe there are only very expensive wifi hotspots?
<ogra> the hostel that just confirmed my booking has free wireless
<Treenaks> cool
<Treenaks> ogra: which one is that?
<infinity> s/cool/normal/, really.
<infinity> Canada is all about the plentiful bandwidth.
<ogra> http://www.hostellingmontreal.com/en/home.aspx?sortcode=2.6.5
<infinity> (moving from Canada to Australia sucked)
<mpt> damn
<Treenaks> infinity: don't do that then ;)
<infinity> Too late.
<ogra> Treenaks, apparently proven that they have connection, doko is already there and is online
* mpt just finished his booking at the Montreal hostel that has the WORST INTERNET KIOSKS IN THE WORLD
<Treenaks> mpt: which one?
<ogra> mpt, when will you arrive ? 
<mpt> Treenaks: the Hostelling International one
<ogra> doko, btw, they offered me a single room :)
<Treenaks> I booked at the "auberge alternative", only 500m from the Holiday Inn
<mpt> It's a bit cheaper than ogra's, though
<ogra> Treenaks, we'll all move over to to the holiday inn once the conference starts...
<Treenaks> ogra: Yes, you paid-for people will
<Treenaks> ogra: The holiday inn was booked full almost from the announcement
<ogra> Treenaks, thats why i didnt really care where i stay for the three nights
<Treenaks> :)
<mpt> ogra: about midday on the 30th
<ogra> mpt, and you go to a hostel ??
<mpt> ogra: Just from the 11th to the 13th
<ogra> oh, k
<Treenaks> I pay $20 (canadian)/night for 9 nights
<Treenaks> which I thought was affordable :)
<mpt> It'll do me good to have an Internet-less weekend
<ogra> *shudder* 
<ogra> no internet ...
<Treenaks> "no internet".. that exists?!
<Lathiat> haha
* Treenaks heard horror stories of places like that
<\sh> ogra: u don't need internet..
* ogra wonders why the mulitverse blackdown package isnt mentioned with a singel word on http://help.ubuntu.com/starterguide/C/ch03s02.html
<ogra> that really sucks
<\sh> ogra: update the toolchain ;)
<ogra> mdke, any reason for that ? you dont need 1.5 at all for a working plugin...
<ogra> the description there is a highly advanced task... looks like ubuntuguide
<Keybuk> mjg59: hang hard, or kernel panic ... we've talked about it before
<mjg59> Oh, yes
<mjg59> I remember
<mjg59> I think it's because the southbridge isn't set up properly, or something mad like that
* \sh can't attend to CC today :(
<trulux> in 10 minutes, we'll start a ameeting over #ubuntu-hardened
<Keybuk> the best distribution-related name since "woody" ;)
<trulux> hah
<Lathiat> haha
<hunger> join #ubuntu-hardened
<mxpxpod> pitti: ping
<mdke> ogra, file a bug and/or update the relevant wiki pages
<wasabi_> Oh wow.
<wasabi_> I just upgraded slapd from hoary to breezy
<wasabi_> and it blew away my ldap db
<Kinnison> be grateful. ldap is nasty
<Kinnison> now you are freed from the shackles of ASN1
<Kinnison> and BER
<Kinnison> and DER
<Kinnison> and the true evils of cn, dc and ou
<YokoZar> Hmm, ran out of disk space entirely while running through dpkg.  Shouldn't there be a warning that I'm really really low somewhere?
<ajmitch> pitti: ping
<wasabi_> Oh I see what happened.
<wasabi_> Wow nice big bug.
<robertj> wasabi: ouchie. What happened?
<wasabi_> Looks like the postinst script tried to backup my db, stop slapd, then recreate and restore it.
<wasabi_> but failed in the middle.
<robertj> did it at least get the backup done?
<wasabi_> yeah
<wasabi_> looks like it
<wasabi_> That script needs to be refined a bit. It never asked me if it should even try.
<wasabi_> And there was no reason for it to try it looks like.
<wasabi_> And that entire methodology would break in the case of having multiple DBs
<pitti> ajmitch, mxpxpod: pong
<mxpxpod> pitti: could you try running devhelp in breezy on ppc?
<ajmitch> pitti: #ubuntu-hardened, if you can spare the time
<ajmitch> just the pre-UBZ meeting
<pitti> mxpxpod: I do that regularly
<pitti> ajmitch: actually I can't
<pitti> ajmitch: I'm about to leave
<mxpxpod> pitti: it segfaults for me
<ajmitch> pitti: that's ok
<pitti> mxpxpod: I don't remember that, but I'll try it tomorrow
<mxpxpod> pitti: I backtraced it and it's something to do with the firefox libgtkmozembed.so
<mvo> Diziet: your automatic updates spec sounds similar to my "unattend upgrades" spec 
<mxpxpod> pitti: anyway, gotta get going... I'll ping you tomorrow about your test results :)
<pitti> mxpxpod: I'll be mostly offline tomorrow, I'm travelling to Montreal
<mxpxpod> ah, ok
<mxpxpod> pitti: I'll ping you next time I see you, then
<pitti> mxpxpod: just file a bug :-)
<mxpxpod> ok, will do
<mxpxpod> later
<pitti> WFM
<Nafallo> j^: your bind9 lacks dpatch as build-dep and FTBFS on my amd64 :-).
<Surak> Hello, I have a question. What happened with getty logins at breezy live? 
<Nafallo> j^: the rest of the nm-packages is built for amd64 on http://www.magicalforest.se/~nafallo/packages :-)
<Surak> I mean, they're no longer there. Which prevents the shutdown messages from appearing somewhere.
<Surak> typing ctrl-alt-fx does nothing.
<TerminX> Surak: this isn't a support channel
<j^> Nafallo a thats cool. i will fix the build-dep for dpatch in that case
<j^> though it should be part of the official bind package at some point
<Surak> TerminX: This is not support. I suspect that there's something wrong, and want to know before posting a bug.
<TerminX> Well, you could always ask in the /correct/ channel, which would be #ubuntu at this point
<Surak> I tried in three different machines. There are no VTs on them.
<Surak> If this were intended to be support, I would have done it already.
<jbailey> mdz: You asked last night about initramfs/usplash tighter integration.  The initramfs-tools pieces are all in already, it just needs the glue in the kernel postinst/postrm scripts.
<jbailey> mdz: After that, everything can use update-initramfs
<seb128> elmo: around?
<Nafallo> mjg59: ping
<wasabi_> Don't suppose anybody is familiar with any effort to package iSCSI for Ubuntu/Debian?
<salgado> hi there
<jbailey> salgado: hi. =)
<salgado> jbailey, not sure if you remember, but we have a diskless setup here at async
* wasabi_ works on packaging iscsitarget
<salgado> and now I decided to start using the stock kernel instead of compiling our own all the time
<salgado> I used mkinitramfs and got an initrd that works fine, apart from not setting the hostname it gets from dhcp
<jbailey> salgado: Sorry, what's an async?
<Amaranth> async in this case is a company
<salgado> jbailey, async is kiko's company name
<jbailey> Ah, okay.  Making sure that it wasn't something like rsync, but not quite. =)
<jbailey> Eh?  I thought kiko worked for Canonical.
<jbailey> But either way.
<jbailey> Hmm, the hostname is usually set by setting /etc/hostname, right?
* jbailey tries to remember if it's also cached by the kernel
<Mithrandir> : tfheen@vawad ~ > find /proc/sys -name hostname
<Mithrandir> /proc/sys/kernel/hostname
<Mithrandir> fsvo cached
<jbailey> Right, with the sethostname call.
<ajmitch> hi
<jbailey> Heya Andrew.
<salgado> we used to generate the nbis with mknbi --ip=dhcp and that used to work just fine. that is, we just specify the hostname in dhcpd.conf
<ajmitch> morning jeff
<jbailey> salgado: Right.  The trick is 1) Figure out if the klibc dhcp client fetched that information 2) Set the hostname with it when we get it.
<jbailey> salgado: Do you have a box handy to test with?  If not, I can fire up the laptop and check.
<jbailey> Mithrandir: Thanks, btw. =)
<salgado> jbailey, yes, I have
<salgado> how can I check that?
<jbailey> salgado: Cool.  If you add 'break' to the kernel command line, it'll drop you into the shell, I *think* before the dhcp client is run.
* jbailey checks.
<jbailey> Right, it is.
<jbailey> salgado: If you can bring a machine up to that point, we can see what you get out.
<salgado> jbailey, cool. I'll do it
<salgado> jbailey, ok, I got an ash prompt
<jbailey> salgado: Cool.  Your network drivers and such should all be loaded.  Can you do ipconfig DEVICE (like ipconfig eth0 or whatever), please?
<salgado> jbailey, done. got host, domain, address, gateway, etc. 
<jbailey> salgado: Okay, cool.  Let's step it the rest of the way by hand to see if this will be enough.
<jbailey> . /tmp/net-${DEVICE}.conf
<jbailey> That should load in a pile of variables.  You can cat it to see what's there.
<salgado> right. I can see HOSTNAME there
<salgado> and it's set correctly
<jbailey> salgado: Cool.  Let's try echo ${HOSTNAME} >/proc/sys/kernel/hostname
<salgado> okay, done
<jbailey> Then: nfsmount -o rw -o retrans=10 ${ROOTSERVER}:${ROOTPATH} /root
<salgado> done
* Nafallo goes to sleep, gnight
<jbailey> salgado: umount /sys
<jbailey> salgado: umount /proc
<jbailey> salgado: exec run-init /root /sbin/init
<salgado> done
<salgado> okay, hostname set correctly. :)
<jbailey> Nice.  So there's one line missing from the script to keep you happy. =)
<jbailey> Well, three if you want [ -z "${HOSTNAME}" ] , to look pretty.
<salgado> should I add it to the 'nfs' file?
<jbailey> But anyhow, would you mind filing that in bugzilla?  It just needs to say subject: "NFS should honour HOSTNAME setting", with a body of "scripts/nfs should set the hostname if available from the net-${DEVICE}.conf file"
<jbailey> salgado: Yup, for now just edit /usr/share/initramfs-tools/scripts/nfs, and add it right after the . /tmp/net-${DEVICE}.conf
<salgado> sure
<salgado> jbailey, there's another issue I had...
<salgado> we used to have a line like this: option root-path "192.168.99.4:/export/hoary,v3,rsize=16384,wsize=16384,tcp"; in our dhcpd.conf
<salgado> but everything that comes after the comma seems to be treated as the rootpath
<YokoZar> quick, someone name a windows EXE to test my wine package with.
<jbailey> YokoZar: sol.exe
<YokoZar> ok, one I can grab off google
<jbailey> YokoZar: Oh, then putty.
<YokoZar> hmm, ok, putty :)
<jbailey> salgado: I don't know then dhcpd site of the NFS root.
<YokoZar> Ok, works, great
<wasabi_> dh_install doesn't seem to be able to rename, does it?
<wasabi_> alas.
<jbailey> salgado: But from where it got put, that seems right.
<jbailey> salgado: I'm guessing there''s probably some other property that ought to be set.  What there any other obvious ones in the net-${DEVICE}.conf file?
<jbailey> wasabi_: Cannot, correct.
<salgado> jbailey, sorry, I'm not following you
<jbailey> salgado: When you ran cat /tmp/net-eth0.conf in the initramfs, did you see any extra variables in there that might be useful for extra NFS options?
<salgado> I thought about setting NFSOPTS in initramfs.conf as I saw it in the 'nfs' script
<salgado> I don't recall having seen anything related to mount options
<jbailey> Right, but that means an extra level of customisatoin.
<jbailey> If it's possible to get the DHCP server to hand it out automatically, that would be ideal.
<salgado> indeed
* salgado reboots the test machine to check everything that is in /tmp/net-eth0.conf
<jbailey> I see that SUNW supports:
<jbailey> # SrootOpt, NFS mount options for the client's root file system
<jbailey> option SUNW.root-mount-options code 1 = text;                       #optional
<salgado> no luck. the only thing I see there is ROOTPATH, which is even truncated. :-(
<jbailey> salgado: Looking through the ipconfig code, it's not one of the options.
<jbailey> salgado: Dunno if there's something standardish that you can use.
<jbailey> For now you have the initramfs.conf file as an option, anyway.
<jbailey> Perhaps file that as a wishlist item and suggest that we honour option SUNW.root-mount-options "rsize=8192,wsize=8192,noxattr";
<salgado> I guess that's okay for now. kiko already experimented a lot with different options, so I don't think we'll ned to change this soon
<cevizoglu> how does checkinstall know where files are going to end up?  does it use the kernel to do so?
<Amaranth> cevizoglu: it uses installwatch
<Amaranth> This monitors <command> and logs using the syslog(3) facility every created
<Amaranth>    or modified file.
<Amaranth> that's what the installwatch README says
<cevizoglu> ahh, thx  :)
<wasabi_> There a guide on proper creation of module source packages
<wasabi_> ?
<YokoZar> You know what's exceptionally annoying?  The Synaptic "add custom repository" window has no name (and therefore is invisible on the taskbar) and jumps to the very back when you click another window, so you have to minimize everything to find it again.
<YokoZar> Sometimes even a modal dialogue box is better than that ;)
<cevizoglu> ugh, modal dialogs are the number one factor in poor user experience, imho
<carstenh> jbailey: ping
<YokoZar> Is it too early for breezy backports?  I'm about ready to have Wine 0.9 into Dapper universe ;)
<madsen> Hey!
<madsen> Apparently no one in #ubuntu knows, or cares to answer what stat64() does... I've got an strace from a bad, bad mono install that's full of failing stat64()'s...
<cevizoglu> madsen, try man stat
<madsen> oh! :)
<tseng> stat looks at a file
<tseng> stat is the 64 bit equivenlant i imagine
<madsen> That's weird, 'cause I'm on 32 bit...
<slomo> the 64bit are for large files...
<madsen> Hmm, ok...
<slomo> madsen: what fails there? mono looks for files which aren't there?
<madsen> slomo: "stat64("libc.so.6", 0xbfb15b84)         = -1 ENOENT (No such file or directory)"
<tseng> thats perfectly normal
<tseng> its trying to walk LDPATH or so
<tseng> to find its so
<tseng> it will find it in /lib and move on
<madsen> Hmm, ok... I'm just trying to find out why my mono is so screwed up.
<tseng> can you be more specific without throwing in red herrings please?
<tseng> what is the symptom
<madsen> tseng: Well, there's an open() call to /lib/libc.so.6 way before the failing stat64()...
<tseng> sigh
<tseng> what is the *symptom*
<madsen> tseng: Sorry, I was writing that when you asked...
<tseng> ie, the reason you are looking at a trace to begin with
<madsen> tseng: I know, I know... :)
<madsen> tseng: All mono apps fail with the same non-descriptive error message....
<madsen> "Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object"
<slomo> madsen: what's above that?
<madsen> That goes for beagle, monodoc, banshee etc.
<tseng> im guessing there is a lot surrounding that
<tseng> above and below
<slomo> i expect a missing assembly
<tseng> please add it to a pastebin
<madsen> slomo: Nothing but that...
<tseng> pastebin.ca is nice
<madsen> Ok, listen... There's only that single line!
<jbailey> carstenh: pong
<madsen> Nothing but my call to (beagle|banshee|monodoc) above it - and nothing but my bash promt below...
<tseng> mono --debug /usr/lib/beagle/Best.exe
<tseng> anymore for that?
<madsen> tseng: Hang on, trying that. :)
<zakame> hi all
#ubuntu-devel 2006-10-23
<shawn_home> I hope your not abandoning 'apt' in favour of 'smart' or give the option of letting people use apt still
<KurtKraut> shawarma_away, I think we are dating with smart but far from merrying with it
<KurtKraut> shawarma_away, actually, if I'm not mistaken, smart only complements apt. It does not subistitute apt
<shawn_home> the wiki says otherwise
<shawn_home> https://wiki.ubuntu.com/SmartPackageManager
<shawn_home> 'We need to evaluate how to make a migration from apt to smart possible and painless and what features/changes are required to make smart the first-class package manager for Ubuntu.'
<KurtKraut> shawarma_away, take a look at http://labix.org/smart
<shawn_home> hmm
<shawn_home> oh?
<shawn_home> interesting
<sivang> doko: don't we have python-egenix-mx::mxUID somewhere? isn't it not packaged?
<doko> sivang: we should, what doesn't work?
<sivang> doko: do you know which package mxUID resides in?
<sivang> I couldn't find it
<sivang> doko: hmm 'we should' means we have it or do not have it? :)
<sivang> doko: I checked the source package, it seems we do not ship mxUID
<doko> sivang: I'll look at it tomorrow; which package does need it?
<sivang> doko: none that I know of , besides hubackup that is going to need it. I can help by providing a debdiff to the package to include this as well, but I haven't checked yet if it was not included due to license issues or so
<sivang> doko: I'd like to create UUIDs from python and mxUID seems to be a good solution.
<doko> sivang: please do file a bug, it doesn't sound RC at the moment ...
<sivang> doko: no, it's not, it's all Feisty stuff indeed.
* sivang files a bug
<sivang> doko: thanks though :)
<fabbione> morning
<Fujitsu> Hey fabbione.
<Vaske_Car> I have a problem that #ubuntu could not help me with. My internet is very slow and it need 5-7 seconds to open web page. Same computer with Windows partition working fine. I had exactly the same problem with Debian as well. Can anybody help me with this?
<crimsun> utterly the wrong channel.
<theCore> Vaske_Car, open a support request on https://launchpad.net/distros/ubuntu/+tickets
<infinity> Gnar.
<infinity> mdz: Your firefox upload was FTBFS.
<fabbione> EEEKKKK
<ArrenLex> How come kuickshow was taken out of the ubuntu repositories for dapper?
* jack_wyt is away: 
* jack_wyt is away: 
<crimsun> ArrenLex: kdegraphics (4:3.5.2-0ubuntu4) dapper; urgency=low    * Do not create kuickshow package (needs imlib)
<ArrenLex> I see. And why is imlib a problem?
<Amaranth> imlib is in universe, kdegraphics is in main
<ArrenLex> Wow, what an annoying reason not to include a package...
<ArrenLex> Also, how come mplayer is in multiverse? It's GPL.
<crimsun> ArrenLex: there are a number of reasons why imlib is a problem, the least of which is security maintenance.
<crimsun> mplayer builds with non-free components, therefore it's in multiverse.
<ArrenLex> Really? Which components are these?
<Amaranth> I always thought it was there because of the obvious patent issues.
<crimsun> the ones that reside in multiverse, like faad2, x264, and so on
<ArrenLex> Amaranth: The patent issues are with w32codecs, not with mplayer... mplayer relies on libavcodec for free codecs, which is in the repos already anyway.
<crimsun> since the binaries generated from those source packages resides in multiverse, then mplayer source /must/ be in multiverse.
<ArrenLex> Why not just compile mplayer without faad, then?
<crimsun> that was considered and rejected. Currently mplayer is the only media player that can play the vast majority of formats by default.
<Amaranth> ArrenLex: w32codecs has _copyright_ issues, completely different.
<ArrenLex> I see.
<Amaranth> w32codecs is illegal to distribute in every country in the world that honors copyrights
<Amaranth> That's all but a handful, as far as I know.
<rmjb> bug #67606
<Ubugtu> Malone bug 67606 in dmraid "dmraid is initialized before udev" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67606
<ArrenLex> I see.
<ArrenLex> Thanks a lot for all the help!
<fabbione> rmjb: are you experiencing the problem or just bouncing random bugs around?
<rmjb> I wanted to get the link
<rmjb> I'm experiencing the problem, and I'm working on it... hope I'm doing the fix correctly
<fabbione> rmjb: -> #ubuntu-motu
<fabbione> the pkg is not in main
<fabbione> and not supported
<rmjb> yeah I know, the bug bot is in that channel also?
<fabbione> dunno
<fabbione> i don't hang there
<rmjb> just checked, it seems to be...
<fdsd> hey guys, I am writing an app that will image harddrives, does anyone know how I can read the name of a macintosh Volume, like for example the name of the drive is "Macintosh HD" but in linux how do I find this info? where is it stored?
<Lathiat> fdsd: that'd likely be stored within the HFS+ data for the filesystem, see 'libhfsp' perhaps
<Lathiat> hal may also be able to tell you
<fdsd> Lathiat, thanks, Yeah hal does, but I dont have gnome installed on the livecd I created, and Im sure there isnt a command line mode for HAL
<fdsd> or is there?
<Lathiat> well i dont know of any tools off hand to do it but you certainly could write something that queried it from a console utility
<tfheen> hal has a dbus interface, just use that
<fdsd> ah cool
<infinity> lshal is a CLI for hal.
<fdsd> oh nice
<infinity> There's also hal-get-property, for finer-grained searching, if you know what you're looking for.
<fdsd> I just need it to output the name of the drive
<fdsd> what do you guys think, If I have a failing harddrive is it better to turn off dma with hdparm to try to get data off?
<tfheen> shouldn't matter
<fdsd> ok
<infinity> Dropping down to PIO modes can help you get corrupted data off, if that's what you want.
<infinity> Since UDMA modes do more anal CRC checking and such, you'll get more errors (and more files will refuse to copy).
<infinity> But dropping to a slower mode won't make the drive any less broken, it'll just make it less obvious.
<fdsd> vol_id works perfectly
<fdsd> infinity, ah
<fdsd> infinity, cool, I have a script that will mount failing drives and copy the data off and I was wondering if setting it to PIO mode would help things
<fdsd> wow vol_id is awesome, works perfectly
<fdsd> Do you guys know of any way to put the x86 iso and the ppc iso on the same CD, I have got them down to about 200mb~  and since they are going to only boot on x86 macs and powerpc macs I would like to make one CD,  and since I can option boot and select the bootable volume it doesnt matter if its not bootable on a "PC"
<tfheen> you should be able to by just fiddling with mkisofs options
<fdsd> hmm
<fdsd> I havent been able to figure it out since the ppc bootable iso is very specific and needs to be a hybrid hfs/iso
<tfheen> oh, casper might need to be taught about it too.
<fdsd> true
<fdsd> thats not a big deal
<tfheen> which would be a tad of work, but certainly not impossible.
<fdsd> im comfertable modifing the initrd files
<fdsd> it would be nice to figure out a way to make a multi volume iso using two iso files..lol
<pitti> Good morning
<ajmitch> morning pitti 
<tfheen> pitti: hiya, you were supposed to upload some language-support packages; did you get around to that?
<pitti> tfheen: yep, I did that at Saturday
<pitti> tfheen: the new m-f-locale-all is also in
<tfheen> pitti: excellent, thanks.
<ajmitch> fabbione: you filed bug 67686?
<Ubugtu> Malone bug 67686 in Ubuntu "[feisty]  please package libvirt" [High,Confirmed]  http://launchpad.net/bugs/67686
<ajmitch> it's on the spec, why does it need to be done before feisty opens?
<fabbione> ajmitch: yes
<ajmitch> I've got packages mostly done, so I might as well reassign to myself
<fabbione> ajmitch: because i am already updating the packages that i maintain
<fabbione> ajmitch: up to you.. i just need that thingy
<fabbione> i know zul does all the xen stuff.. 
<fabbione> so virtualization and that .. = zul :)
<ajmitch> bah, not all :)
<ajmitch> he has his silent helpers
<fabbione> ajmitch: ok so stop complaning and work silent slave^helper
<fabbione> :P
<pitti> tfheen: what's your deadline for uploading simple bug fixes for edgy? someone pointed me at bug 61687; it's a mere s/dapper/edgy/, but requires a new firefox upload
<Ubugtu> Malone bug 61687 in firefox "in EDGY, searchplugin 'debsearch' searches for packages in dapper" [Undecided,In progress]  http://launchpad.net/bugs/61687
<dholbach> good morning
<tfheen> pitti: I just uploaded a new firefox since the last one ftbfs-ed.  I don't think I want any more simple bug fixes in; -updates.
<pitti> tfheen: alright
<tfheen> I guess it should really be on the release checklist.
* tfheen goes to add.
<ajmitch> tfheen: how about a fix for iptables (not yet built) that just adds -fno-stack-protector?
<ajmitch> fixes bug 66681
<Ubugtu> Malone bug 66681 in iptables "libipt_icmp.so: undefined symbol: __stack_chk_fail_local" [Unknown,Unknown]  http://launchpad.net/bugs/66681
<janimo> Riddell: is a11y on the kubuntu CD working well?
<pitti> tfheen: hm, an FTBFS fix for 2.0+0dfsg-0ubuntu1?
<tfheen> pitti: yes
<pitti> tfheen: the .changes on e-changes looks weird, no orig.tar.gz
<tfheen> pitti: uh, that'd be weird.  It did almost build, though
<pitti> tfheen: maybe the -changes emails just don't contain orig.tar.gz file lines, I never checked
<Administrator> is the kernel_panic acpi issue already fixed in 2.6.17 ( acpi_hw_low_level_read ) bug 61848?
<Ubugtu> Malone bug 61848 in linux-source-2.6.17 "[edgy]  kernel panic after last update" [Undecided,Confirmed]  http://launchpad.net/bugs/61848
<fabbione> Administrator: you already asked in #ubuntu-kernel 2 seconds ago. If the bug is open it means that has not been fixed
<Administrator> when will this be fixed?
<fabbione> not in edgy..
<Administrator> 2.6.18 is already out, when will this be uploaded to edgy?
<fabbione> edgy is about to be released in 4 days.. there will be no .18 
<Administrator> you guys releasing edgy while people have kernel panics? 
<pygi> Administrator: dude, I seriously suggest you calm down
<tfheen> Administrator: yes, we do that.
<fabbione> Administrator: yes.
<Administrator> I need to deliver 500 pc running edgy
<tfheen> Administrator: now, please let us concentrate on the release.  There will be no changes to the kernel in edgy.
<Administrator> they all have via chipsets
<test> irc client borked. 
<tfheen> ajmitch: uh, that's quite bad, but I think we'll put that in -updates.
<test> So I will just have to use the fix that is suggested by the mailing list
<ajmitch> tfheen: alright, just getting a fix together for it to test 
<ajmitch> fabbione: libvirt packages are 95% done :)
<fabbione> ajmitch: ok
<rideout> dholbach, Riddell: are we going to updated qt for the security release qt just made, or provide it in the security repo after the release (by either using 4.2.1 and 3.3.7, or via backported changes) ?
<rideout> s/updated/update/
<dholbach> rideout: that's something where you'd like to have keescook and pitti in the loop :)
<rideout> of course
<rideout> but, at this late stage in the game, how is such a thing handled?
<dholbach> how big are the changes?
<tfheen> rideout: it's a normal security fix and we haven't held up the release for those in the past.
<tfheen> so I'm not going to hold it up this time either; normal security queue is best.
<pitti> the packages are ready
<pitti> but I agree that fixing this post-release works just as wlel
<pitti> well
<rideout> cool, I was just curious, either is ok with me
<rideout> dholbach: I'm running a diff now, Trolltech's security annoucement is way to vague to know what they changed
<rideout> dholbach: "Fixed a potential security issue which could arise when transforming images from untrusted sources." This affects only QImage and maintains both forward and backward compatibility (source and binary) with Qt 4.2.0. 
<pitti> dholbach, rideout: Riddell already has a patch for it, it's quite small and straightforward
<pitti> so, no need for further research
<dholbach> super
<rideout> great
<Riddell> it should be in the upload queue
<infinity> pitti: Feel like looking at a fetchmail build failure?  It looks to be l10n-related, which is one of your specialties.
<pitti> sure
<infinity> pitti: Want me to bounce a log, or will you just reproduce it locally and play from there?
<pitti> infinity: I'll look on the launchpad log, but I'll reproduce it locally anyway
<infinity> pitti: LP log is fine, autotest log isn't.
<pitti> oh, I guess there won't be an LP log; nevermind, will try locally
<mdz> infinity: why didn't I get email about the FTBFS?
<infinity> pitti: Relevant bit is this:
<infinity> rm -f ja.gmo && /usr/bin/msgfmt -c --statistics -o ja.gmo ja.po
<infinity> ja.po:8: nplurals = 1...
<infinity> ja.po:162: ...but some messages have 2 plural forms
<infinity> /usr/bin/msgfmt: found 1 fatal error
<infinity> 619 translated messages.
<infinity> make[1] : *** [ja.gmo]  Error 1
<infinity> mdz: See, I think there was a failure to communicate there.  I was told that we weren't ready for widespread rollout of the notify_owner feature, and when a large number of people hopped on IRC to complain about suddenly being spammed in the last (and final) mass-give-back for edgy, I quickly turned it off in the config.
<minghua> sounds like a broken translation to me
<infinity> mdz: Hence whyI pinged you IRC about it instead, though.
<mdz> infinity: spammed how?
<infinity> mdz: I'll talk to cprov, but I think we need a way to say "this build's already sent a notification, never do it again".  Otherwise, every mass-give-back will tell people over and over again that a package that's been failing for months still is.
<infinity> mdz: There was one Debian maintainer who is active in LP (but doesn't maintain anything in Ubuntu) who was surprised to get notified about build failures in his Debian packages, and then others who were just non-plussed about getting a mess of mails from the mass-retry.
<mdz> I see
<mdz> I didn't realize retries weren't accounted for in the original spec
<tfheen> ogra: why isn't the edubuntu amd64 artwork fixed yet?  Isn't it going to be fixed?
<fabbione> morning mdz
<infinity> mdz: The concern was discussed, but clearly didn't filter down to the implementation phase.
<infinity> mdz: And I'd been told that we weren't turning on notify_owner until post-release, so was going to discuss the remaining details then.  Oh well.
<infinity> mdz: Dealing with retries all through the soyuz buildd code needs some table changes and some rethinks, this isn't the only feature that could desperately use a distinction between "first try" and "the rest".
<seb128> tfheen: are uploads still approved? what about http://paste.ubuntu-nl.org/27946/ (fix gimp.desktop translation domain so the menu item is translated)?
<infinity> seb128: tfheen was hoping to close the archive for anything <= ship.
<ogra> tfheen, working on it 
<infinity> seb128: Unless it's critical.
<seb128> it's not critical for sure, it's "only a translation"
<tfheen> seb128: is that useful without updating the langpacks too?
<seb128> tfheen: yes, it makes the translations being used
<infinity> Argh, speaking of <= ship, we still have a mess of stuff in the queue. :/
<seb128> that's only for the menu item
<seb128> not for gimp itself
<tfheen> seb128: oh, so it'll read "Gimp image editor" in all languages?
<infinity> tfheen: Care to run through the queue with me, and we can accpet or hold (for later acceptance if rebuilding CDs, or rejection if not) each?
<ajmitch> tfheen: universe uploads will still be accepted through?
<tfheen> infinity: please.
<seb128> tfheen: correct, that's what it does atm
<tfheen> seb128: -updates, then.
<seb128> -proposed you mean?
<infinity> tfheen: Kay, let me get a list without universe.
<tfheen> seb128: well, yes, and then -updates.
<seb128> I'm not sure I feel like started the whole -updates procedure for it
<tfheen> ajmitch: talk to dholbach about that, I have enough with main.
<jdub> mdz, BenC: http://kernelslacker.livejournal.com/57802.html
<seb128> I'll keep that somewhere for later
<infinity> tfheen: :
<infinity>   112718 | S- | kdelibs              | 4:3.5.5-0ubuntu3     | 13 hours
<infinity>          | * kdelibs/4:3.5.5-0ubuntu3 Component: main Section: kde
<infinity>   112717 | S- | kde-guidance         | 0.7.0-0ubuntu4       | 13 hours
<infinity>          | * kde-guidance/0.7.0-0ubuntu4 Component: main Section: kde
<mvo> can someone from the archive-admins please take care of bug #67436? firefox-locale-tr needs to be removed 
<tfheen> Riddell: ^^ what is the debdiff for those?
<dholbach> jdub: it's needed for desktopsecure in dapper-commercial... about "*disable* some of the anti-rootkit features the kernel employs" I don't know...
<infinity_> How convenient.
<infinity_> I either hung irssi or screen.  Pick one.
<infinity_> tfheen: What was the last line that got through on my paste?
<tfheen> infinity_: 11:18 < infinity>          | * kde-guidance/0.7.0-0ubuntu4 Component: main
<infinity_>   112688 | S- | qt4-x11              | 4.2.0-1ubuntu6       | 41 hours
<infinity_>          | * qt4-x11/4.2.0-1ubuntu6 Component: main Section: libs
<infinity_>   112687 | S- | qt-x11-free          | 3:3.3.6-3ubuntu3     | 41 hours
<infinity_>          | * qt-x11-free/3:3.3.6-3ubuntu3 Component: main Section: libs
<infinity_> Right.  Done, then.
<jdub> dholbach: i know what it's for; doesn't mean it's right ;-)
<infinity_> Those two are security fixes, they can be rejected and go to -security if you'd prefer.
<pitti> infinity, tfheen: ok to upload http://people.ubuntu.com/~pitti/tmp/fetchmail.ftbfs.diff ?
<mdz> jdub: I wouldn't expect BenC to patch common code for the sake of those modules, so whatever craziness they employ is limited to users who decide to use desktopsecrue
<mdz> desktopsecure, rather
<tfheen> pitti: looks good to me.
<simira> BenC: do you want any log references for a suspend-problem? (won't resume) In case, which ones?
<pitti> tfheen: ok, uploaded
* infinity grumbles.
<infinity> Okay, should be back for good now.
<infinity> I hate computers...
<ogra> mvo, do you happen to have an amd64 edubuntu install left ? i installed i386 over mine, and need to test the edubuntu usplash fix
<mvo> ogra: I have one left I think, yes
<mvo> ogra: you need a upgrade test?
<mvo> ogra: or a fresh install test?
<ogra> i only need to know if that looks ok -> http://people.ubuntu.com/~ogra/edubuntu-artwork-usplash_0.1.0-45_i386.deb
<infinity> tfheen: Right, so, back to the queue. :/
<ogra> upgrading the package should suffice
<tfheen> infinity: use a pastebin?
<ogra> err
<ogra> argh
<mvo> :) no amd64 pkg?
<ogra> crap ... indeed i have no amd64 chroot left either
<ogra> grmbl
<mvo> ogra: I can build it here
<mvo> ogra: just point me to the source pkg
<infinity> tfheen: http://cerberus.0c3.net/~adconrad/queue.txt
<infinity> tfheen: publisher is still manul right now, BTW, so we can shove things in ASAP, if you approve anything.
<ogra> mvo, scp'ing ... takes a second the tgz is big
<infinity> tfheen: And firefox is still building, so not losing any time yet. :)
<tfheen> infinity: fetchmail is ok.
<tfheen> what is the changelog for the pppoeconf change?
<tfheen> ditto for ubuntu-docs
<Gloubiboulga> tfheen, bug 54383 for pppoeconf
<Gloubiboulga> bug #54383
<infinity>  pppoeconf (1.10ubuntu3) edgy; urgency=low
<infinity>  .
<infinity>    * Remove broken zenity support, backport from Debian pppoeconf 1.12
<infinity>      (Closes Malone: #54383)
<gnomefreak> Gloubiboulga: bots are being rebooted
<Gloubiboulga> gnomefreak, ok
<tfheen> infinity: pppoeconf approved.
<infinity>  ubuntu-docs (6.10.4) edgy; urgency=low
<infinity>  .
<infinity>    * Updating omf files for getting-help
<infinity>    * Removing es_ES locale for aboutubuntu (duplicate of es) - bug 66819
<tfheen> Gloubiboulga: any idea about xfce4-appfinder?
<tfheen> infinity: debdiff looks sane?
<Gloubiboulga> tfheen, not at all
<infinity> tfheen: Need to make one.  Sec.
<ogra> infinity, i got a mail about nbd FTBFSing on ia64 and have no clue whats wrong there
<tfheen> ogra: don't care about ia64 for now.
<infinity> ogra: I couldn't care less about ia64 failures at this point.
<infinity> (Well, I could care less, I suppose...)
<infinity> Okay, debdiff on ubuntu-docs takes forever...
<pitti> tfheen: ah, thanks for sneaking the debsearch firefox fix in; now we have two accepted 2.0+0dfsg-0ubuntu2 versions on -changes, let's start the race :)
<ogra> tfheen, oki
<ogra> mvo, its up on p.u.c, 0.1.0-45
<infinity> pitti: That's cause I accepted it and then rejected it from the accepted queue.
<pitti> ah
<infinity> pitti: Could be fun to send "just kidding" messages to -changes when that happens, but it's pretty rare. :)
<mvo> ogra: ok, I will check it out now
<ogra> ta
<tfheen> infinity: what does the xfce4-appfinder changelog look like?
<infinity>  xfce4-appfinder (4.3.90.2-0ubuntu2) edgy; urgency=low
<infinity>  .
<infinity>    * debian/patches/00_fix_crash_on_start.patch: Fix crash on starting
<infinity>      based on patch from Xfce bugzilla. (LP #51373)
<infinity> tfheen: http://cerberus.0c3.net/~adconrad/ubuntu-docs.diff
<infinity> 1.2MB.  Ugh.
<tfheen> infinity: xfce4-appfinder seems to come from janimo, so approved.
<Kamion> we should probably do something about iptables :-/
<Kamion> anyone looking at that?
<Kamion> (bug 66681)
<ajmitch> Kamion: I was 
<Ubugtu> Malone bug 66681 in iptables "libipt_icmp.so: undefined symbol: __stack_chk_fail_local" [Unknown,Rejected]  http://launchpad.net/bugs/66681
<infinity> Kamion: FTBFS, or actually runtime-broken?
<Kamion> infinity: runtime
<infinity> Oh, needs -fno-stack
<tfheen> Kamion: seems to just be icmp, though
<infinity> How the heck did it ever get that symbol defined in the first place?  That should be a build failure, not a runtime failure.
<infinity> Woo.
<Kamion> it's a shared object, so gcc won't complain about missing symbols
<infinity> Oh, fair point.
<Kamion> if it were a fully linked executable, it'd be a build failure
<infinity> Yeah.  DSOs, for the loss.
<Kamion> s/gcc/ld/ I guess
<tfheen> Kamion: verified, it's just ICMP, so I think -updates is appropriate.
<Kamion> tfheen: disagreed
<Kamion> $ for x in `dpkg -L iptables | fgrep .so`; do nm -D $x | grep -q stack_chk && echo $x; done
<Kamion> /lib/iptables/libipt_conntrack.so
<Kamion> /lib/iptables/libipt_icmp.so
<Kamion> /lib/iptables/libipt_rpc.so
<Kamion> /lib/iptables/libip6t_icmpv6.so
<Kamion> conntrack's kinda bad to lose?
<mdz> conntrack = important
<Kamion> /lib/iptables/libip6t_policy.so
<infinity> Yeah, conntrack is my friend.
<tfheen> ok, agreed then.
<tfheen> ajmitch: go ahead.
<infinity> ajmitch: -fno-stack-protector in CFLAGS should fix it up nicely.
<infinity> ajmitch: And once you've uloaded, be so kinda as to update wiki.u.c/GccSsp? :)
<ajmitch> infinity: sure
<infinity> dholbach: Since ajmitch is busy working on main for us, want to do some quick universe queue approvals with me?
<ajmitch> infinity: certainly
<dholbach> infinity: sure
<infinity> dholbach: http://cerberus.0c3.net/~adconrad/queue.txt
<tfheen> infinity: I don't fee comfortable with the -docs update; it touches too much of the build system.
<tfheen> mdke: ^^ ; Can we put it in updates instead?
<dholbach> infinity: fai, fai-kernels, eclipse, eclipse-pydev are approved
<infinity> tfheen: If it fixed scrollkeeper spew, I'm all for it (cron.monthly hates me), otherwise, I'm with you on the "man, that's big and fiddly".
<dholbach> infinity: libadabindx is fine too
<Gloubiboulga> infinity, texmaker has been approved by ajmitch yesterday, and scite by siretart on bug 61033
<Ubugtu> Malone bug 61033 in scite "Tabs don't function properly under edgy" [Undecided,Needs info]  http://launchpad.net/bugs/61033
<infinity> Erggh, there were two eclipse uploads in there.
* infinity grumbles and goes to look.
<mdz> good, firefox built now
<dholbach> infinity: enigmail-locales too
<tfheen> infinity: it's more that I don't want to touch the build system at this point.
<dholbach> infinity: wherami too (bug 67499)
<Ubugtu> Malone bug 67499 in whereami "testssid uses wrong interpreter" [Low,Fix committed]  http://launchpad.net/bugs/67499
<infinity> And the eclipse uploads were identical.  Phew.
* infinity rejects a random one.
<heno> tfheen: FYI, I uploaded new winfoss tarballs on saturday (/w FF RC3). I take it you still pull those into builds automatically?
<heno> (or is it all on manual now?)
<infinity> tfheen: Done with the main queue, or have a few more before I kick the publisher?
<infinity> dholbach: azureus, user-he, adasockets, nautilus-script-manager, gch?
<dholbach> infinity: azureus is fine too - looking up the others
<infinity> gch was an FBFS fix from StevenK.
<dholbach> gch is fine too (bug 65453)
<Ubugtu> Malone bug 65453 in gch "[UNMETDEPS]  gch has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65453
<mvo> ogra: bootup splash looks ok, splash-down looks strange (but that might be X confusing the grafic board), I can give it another go on a different graphic board
<dholbach> i suppose that nautilus-script-manager is bug 67542
<Ubugtu> Malone bug 67542 in nautilus-script-manager "enable script doesn't expand ~" [Medium,Fix committed]  http://launchpad.net/bugs/67542
<dholbach> if that's it - looks fine too
<infinity>  nautilus-script-manager (0.0.5-0ubuntu4) edgy; urgency=low
<infinity>  .
<infinity>    * Change script shell to /bin/bash (Closes: Malone #67542)
<ogra> mvo, that would be great, thanks 
<tfheen> heno: yes, thanks.
<tfheen> infinity: no, I'm happy.
<dholbach> infinity: ok, fine with me
<tfheen> infinity: Riddell apparently isn't around to answer for the k* stuff, so I'll defer those.
<Fujitsu> adasockets 1.8.4.7-4 fixes the unmet dependencies, I was looking at it yesterday... I'm not sure what's in -2ubuntu1, but a sync would be preferable, wouldn't it?
<infinity> dholbach: Probbaly the wrong fix (dash expands ~ too, i's just more picky about how you quote it), but whatever, it'll work.
<dholbach> infinity: user-he is a unmetdeps fix - fine too
<dholbach> infinity: i wouldn't want it to go through n+1 iterations now. :-)
<infinity> dholbach: adasockets is another StevenK gnat special.
<Kamion> heno: automatic
<Kamion> heno: though builds themselves are on manual
<dholbach> infinity: ok, looks good
<infinity> Okay, that clears the universe queue completely, publishing the world.
* dholbach hugs infinity
<heno> Kamion: k, thanks
<infinity> Err, wait.
<infinity> tfheen: Are we doing anything other than -server on sparc? (like an alternate?)
<infinity> tfheen: Cause firefox isn't done there.
<infinity> Actually, we need another cycle for ppoe anyway.
* infinity publishes.
<ogra> does anyone here have two abtteries in a i386 laptop and sees bug 60442 ?
<Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Confirmed]  http://launchpad.net/bugs/60442
<ogra> *batteries even
<dholbach> ogra: I think it was Lure who had one
<ogra> he's not here :/
<tfheen> infinity: not that I know of, no.
<infinity> ogra: It's a well-known bug...
<ogra> seems upstream fixed it in CVS on friday ... the fix is small enough that i'd apply it, but not if i cant get it tested
<infinity> ogra: It's triggering events on battery state rather than whole-system state.
<infinity> ogra: Two batteries (and one dying completely) is an esoteric enough setup that it's fine for -proposed/-updates post-release.
<ogra> well, mjg59 complained about it being a regression
<ogra> and the patch is really small, i wuldnt mind to get it in before release: http://bugzilla.gnome.org/attachment.cgi?id=75163&action=view
<infinity> It is a regression, certainly, but we're in the death march right now.
<infinity> tfheen: Your call of course, boss. :)
<ogra> i know
<ogra> infinity, well, discussing it without having anybody to test the patch is a waste of energy anyway :)
<tfheen> ogra: -updates.  I want to get the CDs done today and I can't do that if I have to empty a battery first.
<ogra> lol, ok
<infinity> tfheen: Use a fork.
<tfheen> infinity: I'd like to be able to use the battery later too.
<infinity> Oh, picky. :)
<tfheen> you knew that already. :-)
<infinity> ajmitch: How's that iptables coming along?
<ajmitch> infinity: just building it again to test on the laptop, should only be a couple of min
<infinity> ajmitch: Sweet, thanks.
<mvo> ogra: no shutdown bootsplash at all on the second machine (that is probably because it is a nvidia card) - oh, one more thing. on bootup the progress bar looks very strange (as if random black pixels have been inserted)
<Kamion> mvo: I fixed that post-RC
<Kamion> shutdown bootsplash on amd64?
<ogra> but is it recognizeable as progress bar ?
<mvo> ogra: it is. it just looks a bit garbled
* pitti creates https://wiki.ubuntu.com/Apport; a Denglish -> English check would be appreciated
<mvo> Kamion: could you please have a look at #67436 and remove mozilla-firefox-locale-tr from the archive?
<Fujitsu> pitti: I'll take a look..
<mvo> it causes havoc and there is m-f-l-tr-tr that replaces it
<pitti> Fujitsu: cheers
<pitti> mvo: oh, I can also add a -tr transitional package if necessary
<ajmitch> oh good, iptables fix worked, debdiff is at http://ajmitch.net.nz/debuild/ubuntu/tmp/iptables.debdiff
<infinity> ajmitch: Looks poifect.
<ajmitch> k, should hit the queue soon
<mvo> pitti: that would be good as well, its just that the current package causes trouble
<infinity> Many happy returns.
<pitti> mvo, tfheen: a word from you and I'll upload a new m-f-locale-all with a transitional -tr package
<mvo> pitti: the -tr package is universe anyway - but it needs either a transitional package or must be removed 
<pitti> mvo: removing would be better, but that doesn't help dapper upgrades
<mvo> right
<pitti> mvo: and mozilla-firefox-locale-tr-tr is in main
<mvo> *nod*
<pitti> hm, it was in main for dapper already
<pitti> but dapper's -tr wasn't a transitional packge
<infinity> So this is a longstanding bug, then.
<Kamion> it needs both a transitional package and removal of the old source
<infinity> Not an upgrade issue, per se.
<pitti> however, the current -tr source/binary shuold be removed nevertheless
<Kamion> oh, hang on, dapper had m-f-l-tr-tr
<Kamion> do we expect to have been installing m-f-l-tr in dapper?
<pitti> Kamion: right, but dapper's -tr wasn't a transitional package
<Kamion> yeah, I know
<infinity> Did dapper's -tr work?
<infinity> If so, people may have installed it.
<sivang> re
<pitti> Kamion: language-support-tr in dapper used -tr-tr, which was fine
<infinity> If not, who cares?
<pitti> it's just an issue for manual installations
<Kamion> infinity: it would have installed due to the l-s-tr dep, but I doubt it worked
<pitti> and dapper's -tr was uninstallable anyway
<Kamion>  Depends: mozilla-firefox (<< 1.0.99 ) | firefox (<< 1.0.99) | language-support-tr
<mvo> it causes firefox removals if installed
<Kamion> installable, but not functional
<infinity> dapper's wouldn't have worked.
<infinity> Yeah.
<infinity> We all got there at the same time.
<Kamion> yeah, no need for a transitional, I'll just remove it
<infinity> So, I say just remove it and be done with it.
<infinity> No dapper user would have it installed.
<pitti> infinity++
<mvo> thanks
<Kamion> done
* infinity gets ready to re-run the publisher for iptables. :/
<infinity> Any other last-minute stuff for the CDs?  Speak now.
<infinity> And quickly.
<mvo> infinity: -live or -alternate? or both?
<infinity> mvo: yes.
<tfheen> I need to pop out for a minute, but I'll be back before the publisher run finishes.
<mvo> infinity: I would like to upload a workaround for #58424 in the dist-upgrader. but if it doesn't go on the CD that would not be too terrible
<infinity> mvo: These are probably not going to be the final CDs anyway, but we can all hope.  Right?
<infinity> This is my hopeful face!
<mvo> infinity: hehe, good point
<tfheen> infinity: shh!
<Fujitsu> pitti: That page should now be perfect :P
<Kamion> still doing archive admin, but I think mostly universe now
<Kamion> I'll warn if anything mainish shows up
<Kamion> and going through ubiquity bugs, but they're practically all busted CDs
* ajmitch only has universe things to get in from now
<pitti> Fujitsu: ah, thanks
<infinity> I have a few universe bugs to clean up in my "spare time" before release too.
<infinity> Haven't focussed there, with all the main hubbub.
<sivang> infinity: hub-bug? :)
<sivang> err, bub
<infinity>   hubbub
<infinity>        n : loud confused noise from many sources [syn: {uproar}, {brouhaha},
<infinity>             {katzenjammer}] 
<infinity> I rather like brouhaha as well.
<sivang> oh, cool
<AnAnt> what should I do if I asked a question on #ubuntu+1 & ubuntu-users mailing list several days ago, yet got no answer 
<AnAnt> ?
<infinity> Discover the answer yourself?
<pitti> AnAnt: file a support ticket on launchpad?
<AnAnt> k
<dholbach> tfheen, Riddell: are you ok with me uploading:  http://daniel.holba.ch/temp/kubuntu-default-settings.ebdiff ?
<AnAnt> thanks
<ogra> mvo, i updated the package on p.u.c with a different progressbar, could yo0u test again ? should look better now
<mvo> ogra: ok
<ogra> thanks again :)
<mvo> ogra: usplash down is fixed too :) ?
<infinity> dholbach: We have a couple of other KDE things in the queue in a holding pattern already.  Can you upload it, so we don't lose it, and when Riddell's around, we'll decide if it should be rejected or accepted.
<ogra> nope, i dunno whats wrong there
<dholbach> infinity: alrighty
<ogra> mvo, usplash down is fixed in usplash, noztt in the artwork 
<ogra> you need 0.4-33 installed
<pitti> infinity: do you already have a victim^Wvolunteer for the python-qt4 FTBFS?
<mvo> ogra: ok, I will make sure that its full upgraded
<Riddell> dholbach: good with me
<infinity> pitti: tfheen and I made an executive decision to close the gates for FTBFS fixes, any from now on will go to -proposed/-updates post-release, so the fixes aren't lost (and security is made a bit simpler)
<dholbach> Riddell: uploading.
<pitti> ah, ok
<infinity> pitti: Err, for anything <= ship, that is.
<pitti> infinity: I just took a look at the remaining unassigned edgy milestone bugs, and that one caught my eye
<infinity> pitti: But I'm pretty sure pytohn-qt4 is on riddell's CDs. :)
<infinity> Actually... Why is it in main at all?  Now I can't find it in the seeds...
<infinity> Must be a build-dep or something.
<pitti> -- edgy/main amd64 deps on python-qt4:
<pitti> hwdb-client-kde
<infinity> Yeah, just got there.
<infinity> So, definitely a no-go.  That's in -desktop
<pitti> I would have some time to fix it
<infinity> pitti: Milestone it for "later", please.
<pitti> alright
<infinity> And give it an edgy task, too.
<infinity> So we don't just fix it in feisty. :)
<Kamion> ok, all actionable archive admin done
<infinity> It sounds like the sort of package that might get a security vuln or twelve.
<Kamion> I'll just do a quick round of the usual checks
<pitti> infinity: bah, there's no 'edgy' release in LP yet
<carlos> Kamion: could you provide me with a tarball of translations that are part of final Edgy's installer?
<infinity> pitti: Oh, fun. Nevermind, then.
<tfheen> pitti: just milestone it for later, then
<carlos> Kamion: to update the statistics in Rosetta
<pitti> yup, done
<Kamion> some universe NBSes to be done, but the updated binaries aren't there yet
<Kamion> carlos: did you try looking in the usual place? :)
<pitti> so I guess it's now definitively too late to promote command-not-found
<carlos> Kamion: do you keep it up to date?
<Kamion> -rw-r--r-- 1 cjwatson warthogs 256271 Oct 23 05:41 template.pot
<Kamion> carlos: yes
<carlos> Kamion: ok, I thought I should ask an update every time ;-)
<Kamion> 24 5,11,17,23 * * *     cd ~/installer-po && ./extract-templates /srv/archive.ubuntu.com/ubuntu
<infinity> Kamion: edgy's NEW queue is filling up again too.
<carlos> ok, cool
<pitti> tfheen: desktop seed still depends on command-not-found, shall I unseed it?
<carlos> Kamion: thanks
<Kamion> infinity: oh, good point, I'll do that
<tfheen> pitti: I thought it was brought into main?
<Kamion> tfheen: I hope not at this point
<pitti> tfheen: I just did the MIR, but it's not promoted; at least it's the only thing in anastacia
<infinity> Never was promoted.
<Kamion> tfheen: apparently it doesn't exit 1 when a command isn't found ...
<pitti> but it's a bit late for promotions
<Kamion> as in, when being called as a bash hook
<tfheen> gnr.
<infinity> Ew.
<Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/guidance.debdiff http://kubuntu.org/~jriddell/tmp/kdelibs.debdiff
<Kamion> so I'm kind of not very convinced about promoting it
<tfheen> so we need to unseed that and upload new *-meta?
<infinity> meta should be fine.
<pitti> tfheen: the package ubuntu-desktop doesn't depend on it
<Kamion> -meta won't depend on it
<infinity> germinate ignores packages it can't resolve.
* pitti will take care of unseeding and merging then, unless someone objects
<Kamion> perhaps somebody could check that an ./update in all *-meta packages does nothing
<tfheen> pitti: thanks.
<pitti> yes, I can do that
<pitti> Kamion: ^
<Kamion> ta
<infinity> Kamion: I have to run off for ~15-20... If the buildds go idle before I'm back (unlikely, but it might happen), can you by-hand a publisher run at that point?
<Kamion> infinity: ok, I'll check once I've done NEW
<infinity> Kay.  Back in a few.
* netjoined: irc.freenode.net -> brown.freenode.net
<tfheen> Riddell: you should set SHELL=sh -e in debian/rules when you do multiple commands in a single make rule or otherwise catch and fail on errors.
<pitti> Kamion: For the record, I filed a bug for that
<mvo> ogra: new version looks better. not perfect but a lot better
<ogra> ok
<ogra> do you think its enough for final ? 
<mvo> ogra: and usplash-down works too
<ogra> yay !
<tfheen> Riddell: also, what is:
<tfheen> -#define MODULE_DIR "/home/jr/src/guidance/new/kde-guidance-0.7.0/debian/tmp/usr/share/apps/guidance"
<tfheen> +#define MODULE_DIR "/root/guidance/kde-guidance-0.7.0/debian/tmp/usr/share/apps/guidance"
<tfheen> ?
<tfheen> why does it hard code paths in .cpp files?
<mvo> ogra: yes, its just two pixels that look strange at the start
<ogra> ok
<Kamion> pitti: thanks; could you reproduce it yourself?
<pitti> yes
<Kamion> pitti: I only heard about it second-hand
* ogra uploads then ... mvo thanks a lot for the help :)
<mvo> ogra: interesstingly the usplash-down looks correct 
<Riddell> tfheen: I'd have to ask the author to find that out, but it hasn't caused us problems so far
<sivang> hi mnepton 
<tfheen> Riddell: is that a generated file?  If so, it should be removed on clean.
<tfheen> Riddell: in kdelibs.diff, you changelog doesn't say anything about what you changed.
<mvo> doko: any idea about https://launchpad.net/distros/ubuntu/+source/python-gnome/+bug/60361?
<Ubugtu> Malone bug 60361 in python-gnome "fails to install" [High,Confirmed]  
<Riddell> tfheen: more information is on the bug report https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/63325
<Ubugtu> Malone bug 63325 in kdelibs "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Low,In progress]  
<Kamion> ok, NEW's empty
<Kamion> buildds are still building eclipse
<tfheen> Riddell: that information should still be in the changelog.
<Riddell> tfheen: I can add and re-upload if you wish
<mdz> tfheen: I've uploaded another firefox with a small javascript-only patch blessed and requested by upstream: http://people.ubuntu.com/~mdz/temp/firefox.diff
<mdz> tfheen: if anything happens which leaves a window to do another build, please roll it in
<doko> mvo: that's a file conflict; one of the packages should be fixed, or a conflict be added.
<tfheen> Riddell: apart from that, the fixes looks ok-ish to me, but my C++ isn't that good, so I hope you've tested it.
<tfheen> (approved)
<mvo> doko: a conflict might be the easiest option for now
<Riddell> tfheen: thanks, what happened to katapult?
<tfheen> Riddell: nothing; I haven't seen a debdiff.
* Riddell tracks one down
<tfheen> mdz: will look at it now
<tfheen> mdz: oh, shiny.
<Kamion> tfheen: shall I accept that now?
<tfheen> Kamion: kdelibs and kde-guidance, yes, please.
<Kamion> tfheen: I was asking about firefox, but ...
<pitti> Kamion: 'No changes found' for all four *-meta
<tfheen> Kamion: I'd like to test the fix first.
<Kamion> tfheen: ok. kdelibs and kde-guidance accepted
<Lathiat> hrm why does the launcher have a firefox icon but the program itself doesnt
<Kamion> tfheen: unapproved: firefox/2.0+0dfsg-0ubuntu3 kubuntu-default-settings/1:6.10-61 katapult/0.3.1.3-0ubuntu5 ubuntu-docs/6.10.4 qt4-x11/4.2.0-1ubuntu6 qt-x11-free/3:3.3.6-3ubuntu3
<Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/katapult.debdiff
<Riddell> tfheen: I understand that Mez spoke to you about those patches previously
<infinity> Kamion: Okay, back.
<tfheen> Riddell: he spoke to me about the _bugs_ previously.  He said he'd get the patches back to me, but never did.
<Kamion> infinity: hi. your buildds are still churning
<infinity> Kamion: So I see. :)
<ogra> tfheen, http://people.ubuntu.com/~ogra/e-a.debdiff ?
<Riddell> tfheen: right.  they're large patches but come from the current released version
<tfheen> Kamion: please accept firefox.
<doko> tfheen: would you consider fixing http://www.openoffice.org/issues/show_bug.cgi?id=70601 ?
<Ubugtu> OpenOffice.org bug 70601 in Presentation "Crash in Draw and Impress by pressing the Del key" [Patch,Started: ]  
<infinity> tfheen: kubuntu-default-settings is a tiny patch that fixes a crasher in icon themes.  I told dholbach to upload it "in case we accepted the other KDE stuff".
<tfheen> infinity: yeah; approved.
<Riddell> tfheen: http://kubuntu.org/~jriddell/tmp/qt3-edgy.debdiff http://kubuntu.org/~jriddell/tmp/qt4-edgy.debdiff  the patches is from trolltech
<infinity> doko: An OOo build seems pretty unacceptable at this point, unless it's critical.
<tfheen> ogra: edubuntu-artwork looks good; I'm assuming you've tested the images.
<ogra> i'm just doing a last local test, mvo confirmed bug 66726 to be fixed
<Ubugtu> Malone bug 66726 in edubuntu-artwork "edubuntu artw ork has funny colors on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66726
<infinity> tfheen: firefox and k-d-s accepted.
<tfheen> Riddell: you're happy with the katapult change?
<tfheen> Riddell: I'm fine with it, apart from dreadful changelog which doesn't document what's changed.
<Riddell> tfheen: yes
<infinity> Oh, crap, that was xubuntu-default-settings.  I can't read.
<seb128> is the splash screen supposed to be not-colored now on amd64?
<ogra> seb128, its supposed to be 16 cols
<ogra> like the dapper one
<seb128> it's not
<infinity> tfheen: 
<infinity>  xubuntu-default-settings (0.23) edgy; urgency=low
<infinity>  .
<infinity>    * etc/xdg/xfce4/mcs_settings/desktop.xml: Do not show system menu by default
<infinity>      on right click. Enable latest edgy wallpaper
<infinity>    * etc/xdg/xfce4/panel/tasklist-2.rc: Do not make buttons flat in taskbar,
<infinity>      keep it how it was in dapper.
<seb128> ogra: https://launchpad.net/distros/ubuntu/+source/usplash/+bug/67545
<Ubugtu> Malone bug 67545 in usplash "usplash appears black and white" [Undecided,Confirmed]  
<infinity> tfheen: I accepted that by accident.  Shall I pull it back out before I publish, or is that alright?
<seb128> ogra: http://librarian.launchpad.net/4922303/22-10-06_1325.jpg
<infinity> tfheen: It's from janimo.
<seb128> it was fine 2 weeks ago
<ogra> seb128, oh, neat
<seb128> it was half broken for RC
<seb128> and now it's like that
<ogra> hmm, edubuntu is fine it seems ...
<tfheen> infinity: that's fine.
<ogra> are you up to date with everything ?
<tfheen> seb128: it's grey, yes.
<seb128> ogra: not the icon theme, which should not matter for splash
<ogra> indeed
<infinity> katapult/0.3.1.3-0ubuntu5, ubuntu-docs/6.10.4, qt4-x11/4.2.0-1ubuntu6, qt-x11-free/3:3.3.6-3ubuntu3
<infinity> tfheen: Do we want any of those before I publish?
<seb128> tfheen: that's expected? and the progress bar not being centred with no background color is expected too?
<ogra> seb128, i rather meant usplash itself, not the artwork
<tfheen> infinity: katapult accepted, qt4-x11, xt-x11-free accepted.
<seb128> ogra: usplash is uptodate
<infinity> tfheen: Any pending uploads being discussed?
<infinity> tfheen: (that we want to wait for)
<tfheen> infinity: no, just go ahead.
<infinity> Going ahead. :)
<tfheen> seb128: the artwork I got from fschoep is greyscale in the 640x400 version, yes.
<seb128> hum, k
<seb128> the bar still looks bugged though
<tfheen> yes, fschoep moved it to x=160 instead of x=212
<seb128> tfheen: and the "no background color" is considered as a bug too? because having vertical bars on the screen like that looks weird too
<tfheen> seb128: I haven't seen that, I think.
<seb128> tfheen: http://librarian.launchpad.net/4922303/22-10-06_1325.jpg
<seb128> tfheen: it already looked like that with RC
<tfheen> seb128: yes, the offsetting is something I'm working on fixing now.
<seb128> tfheen: http://people.ubuntu.com/~seb128/boot.jpg that's from RC on my desktop
<tfheen> seb128: yes, that looks fairly centered to me?
<seb128> right, that one is
<seb128> I'm asking about the "no background color"
<seb128> for the bar
<Kamion> I thought that had been fixed post-RC
<tfheen> oh, that it's black.  Well, I didn't have any other colour.
<Mirv> yes, the amd64 usplash looks completely broken and ugly, even if it's partially meant to be like that
<Mirv> seb128: that is i386 I guess? those vertical bars are quite ugly in that, too, though it's better than amd64
<seb128> Mirv: no, it's amd64
<seb128> on i386 I've the svga splash which is fine
<Mirv> seb128: oh, ok, so you have color at least, and centred, unlike in that report and on my computer
<seb128> Mirv: the screenshots was with edgy RC
<seb128> Mirv: now it looks like not centered
<seb128> the artwork has changed since RC
<Kamion> I think the colour removal on bogl-using systems (amd64 and powerpc) was deliberate to avoid overloading the 16 colours available
<tfheen> Kamion: it certainly looks like it.
<Mirv> Kamion: yeah, that -> http://librarian.launchpad.net/4922303/22-10-06_1325.jpg just doesn't look like something that's actually working
<tfheen> I can fix the offset progress bar, but I won't change the background colour.
<Mirv> ok the grey is ugly, but the vertical lines in blackness is just something that looks like an error
<tfheen> not once it starts filling
<tfheen> IMO
<seb128> I think it looks really weird 
<Kamion> I agree with seb
<Kamion> may be hard to fix now, though
<Mirv> well, my impression of it when it's running is that something is really wrong, like some bit would cause errorenous pixel output every x horizontal pixels etc.
<tfheen> too late to fix that now.
<tfheen> I can center it, that should make it look better.
<tfheen> seb128: can you verify that changing the first instance of .progressbar_x to 212 makes it look decent for you?
<tfheen> (in usplash-theme-ubuntu.c in usplash-theme-ubuntu)
<seb128> tfheen: trying
<mjg59> Kamion: There's 256 colours available on some bogl systems
<infinity> (like my vesafb system)
<infinity> (which uses the regular svga artwork)
<mjg59> And all PPC ones
<tfheen> usplash doesn't really care, it just "happens" to use 16 colour for 640x400 and 640x480, while > 16 for everything else.
<infinity> Oh, really?  We're not doing switching based on the palette depth of the current fb as well?
<tfheen> I don't think so
<infinity> Something for feisty, I guess.
<tfheen> it just happens to work quite well
<ogra> tfheen, edubuntu-ar5twork uploaded, please leat it through if it hits the queue
<ogra> *let
<jsgotangco> Yay
<tfheen> ogra: didn't I approve that two hours ago?
<ogra> well, rather one hour ago, but i wanted to test it on all possible resolutions before ... that took some time
<tfheen> oh, ok.
<tfheen> so no different than the diff you pasted then?
<tfheen> infinity: please approve edubuntu-artwork
<ogra> exactly
<infinity> tfheen: Accepted.  I also have an xfdesktop4 and a partimage in the queue.
<infinity> janimo: We're heading into the final stretch here, can you communicate about these uploads from here on in. :)
<tfheen> partimage is universe => EDONTCARE.
<infinity> Right, so it is.  Brain fart.
<janimo> infinity: ok, as long as it does not slow you down or anything plese keep accepting them :)
<infinity> dholbach: partimage, StevenK upload for bashisms.
<infinity> janimo: it's more a question of "we'll be rolling CDs soon, and it's easier if you're a part of that process".
<ogra> i wonder why the manually approved packages never end up in my edubuntu-changes ML filter the headers look the same ...
<infinity> Releasing Xubuntu after we close edgy for uploads won't work very well. :)
<janimo> infinity: sure I'll be watching the CD rolling closely
<infinity> ajmitch: Alive?
<ajmitch> still
<infinity> 06:03 < infinity> dholbach: partimage, StevenK upload for bashisms.
<infinity> ajmitch: ^^
<ajmitch> approve it
<infinity> Danke.
<infinity> tfheen: You have a usplash artwork fix pending?
<tfheen> infinity: awaiting confirmation from Seb that it makes him cry less.
<janimo> Kamion: if it's too late for the xubutu patch to casper/ubiquity in bug 67703 then, can at least the CD be modified to show the v2,v3 and m2 options? Those will work at least partially because of inheriting the ubuntu gconf settings
<Ubugtu> Malone bug 67703 in casper "support xubuntu a11y options" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67703
<tfheen> janimo: that'd require a gfxboot-theme-ubuntu upload, wouldn't it?
<janimo> tfheen: hmm, probably, so not a build server only thing.
<tfheen> janimo: in that case; no.  Sorry.
<janimo> tfheen: if it's tool late for that too, than I'd like to know so I can remove the gnome packages from the liveCD if they cannot be triggered 
<heno> janimo: do they have menu entries in XFCE ATM?
<tfheen> janimo: it's too late for changing casper or gfxboot-theme-ubuntu, yes.  I'd like it if xubuntu was ready at the same time for rolling final images.
<mdz> and those are both packages which are used in Ubuntu as well
<heno> janimo: what would be your main reason for removing them, to keep the CD image lean?
<seb128> tfheen: with 212 it looks centered correctly
<tfheen> seb128: excellent
<tfheen> infinity: please review and approve usplash-theme-ubuntu when you have free cycles.
<janimo> heno: there are no menu entries on the liveCD only for v1, but that does not work
<tfheen> janimo: I'd recommend releasenoting it and leaving the images as they are, but your choice.
<janimo> heno: do you think that orca and gomme -mag could be used if not started automatically?
<janimo> heno: well I guess users could reach those options if they typed access=xx at the kernel cmdline by hand
<heno> janimo: they can happily be started from the command line, though some online docs would be useful
<heno> true
<janimo> heno: ok, but orca is only going to be on the liveCD since ubiquity does not install it
<heno> some people have been using xubuntu with magnification on older systems with good results
<janimo> heno: do you know if kubuntu a11y is working on the installed system?
<janimo> heno: as in the liveCD setting being copied over correctly
<infinity> tfheen: Done, and done.
<infinity> tfheen: I'm showering, and heading to bed soon.  I'll put stuff back on auto when I get out of the shower if Kamion doesn't want to drive.
<heno> janimo: I'm not sure if kubuntu ubiquity installs and configures the right things by default, no
<heno> I've only tested Live and on my existing desktop system
<tfheen> infinity: ok.  Hopefully we should be able to make images RSN
<janimo> heno: I ask because the ubiquity hook for kubuntu looked a bit weird
<janimo> suggesting it would not install on the system
<heno> janimo: the kubuntu hooks still look a bit greek to me, I would only know by testing
<Riddell> I don't think it does work
<Riddell> heno: what's the status of kubuntu winfoss?
<Kamion> tfheen: actually, adding v2,v3,m2 to the CD is just a debian-cd change
<janimo> Kamion: awesome
<Kamion> (it's in isolinux.cfg)
<janimo> heno the change to kubuntu hooks is in the patch for bug 67703 
<Ubugtu> Malone bug 67703 in casper "support xubuntu a11y options" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67703
<janimo> it sees to install to /root as casper, instead of /target
<janimo> s/sees/seems/
<Kamion> janimo: surely in kubuntu the relevant packages are in desktop?
<janimo> Kamion: yes
<Kamion> then the ubiquity hook does not need to ensure that they stay installed
<Kamion> that's only necessary if you don't want them in desktop
<heno> Riddell: I uploaded a new version Saturday. I'm still waiting for sfllaw to see if he can help me track the Server 2003 issue. It runs fine from CD here on my XP system
<janimo> Kamion: it's just the sedding that is done on /root
<janimo> Kamion: I do not mean apt-install. Maybe I missed something though
<Kamion> janimo: v2, v3, and m2, but not m1? currently you only have v1
<janimo> Kamion: v2, v3 and m2 laucnh gnome apps via the gconf keys
<janimo> v1 m2 and m3 do not have the xubuntu specific sed invocations
<tfheen> Kamion: coolie
<Kamion> m3 isn't supported anywhere
<Kamion> janimo: do you mean "v1 m1 and m3 do not have ..."?
<Kamion> please be really careful about typoes when discussing this stuff :)
<janimo> Kamion: yes, I mix them up all the time
<Kamion> janimo: so should I remove v1?
<janimo> Kamion: so those which set exec_ats are run by xfce as well
<janimo> Kamion: yes, since the one line cp cannot be added at this point
<janimo> so leave v2 and v3 which laucnh orca, and m2 which launches onboard
<Kamion> janimo: done
<Kamion> infinity: happy to drive for a while at least
<janimo> Kamion: re Kubuntu I meant that ubi seds in /root/etc/kderc whereas it maybe should in /target?
<janimo> Kamion: thanks
<tfheen> Riddell: please close the kde-guidance bugs which were fixed by the latest upload
<infinity> Kamion: Okay, cool.  Then I'll leave it to you.  Current publisher should be done in ~5 mins, and I'm off to bed.
<Kamion> janimo: yeah, that's a bug in the ubiquity hook for Kubuntu. will fix in bzr now, but not upload unless tfheen wants it
<tfheen> dholbach: ditto, please close the kubuntu-default-settings bug you fixed in your upload
<tfheen> Kamion: can you byhand the next run once firefox and usplash-theme-ubuntu are built?
<Kamion> tfheen: yep
<janimo> Kamion, tfheen: if you'll decide on new casper upload for the kde fix then please consider the rest of the patch as well, that fixes ubuntu and magnifier
<janimo> s/'ll//
<tfheen> janimo: make sure it's checked into bzr.
<janimo> heno: btw do you know why onboard doe snot have an Esc key?
<sladen> tfheen: is there a way to flag things like  http://librarian.launchpad.net/4922841/typo-fix.diff  for edgy-updates ?
<janimo> tfheen: I have no access to casper bzr AFAIK
<tfheen> janimo: it's owned by core-dev, and even if not, you could have nagged us to merge a branch of yours. :-)
<tfheen> sladen: I don't think we have the edgy-updates milestone yes.
<tfheen> yet
<tfheen> mdz: can we have an edgy-updates milestone, please?
<sladen> janimo: bzr branch http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk casper
<janimo> tfheen: I made no branch just used the old style patch in LP :)
<Kamion> sladen: he can check it out and commit directly rather than faffing with branches
<mdz> tfheen: yep
<Kamion> bzr checkout ...
<mdz> tfheen: done
<tfheen> mdz: thanks.
<Kamion> er, bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk
<tfheen> sladen: there, now you should have an edgy-updates milestone
<Kamion> (can't checkout http)
<iwj> Oh, looks like Mozilla are releasing Firefox 2.0 as I speak.
<janimo> Kamion, tfheen: the patch is at bug 67703 but if you prefer I can commit to bzr instead of you applying
<Ubugtu> Malone bug 67703 in casper "support xubuntu a11y options" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67703
<tfheen> iwj: it's already in the archive.
<Kamion> janimo: stick "[ Colin Watson ] " above my change in debian/changelog and prefix yours with "[ Jani Monoses ] " so we know who did what
<janimo> actually I have casper checked out just did not make a branch asI thought I'd only have one patch
<Kamion> (or just use dch)
<iwj> tfheen: Oh, I'm behind the times.
<tfheen> janimo: uh, no, that change is wrong.
<janimo> tfheen: the whoe patch?
<janimo> whole
<tfheen> janimo: you need to make sure the file exists before copying, ext
<tfheen> etc
<tfheen> http://librarian.launchpad.net/4924565/cas.diff
<tfheen> is wrong
<janimo> tfheen: does the hwole script fail if cp fails?
<iwj> tfheen: You mean 2.0rc3 ?
<Kamion> tfheen: it's not actually set -e ... but checking would suppress unnecessary error messages
<janimo> tfheen: I ran both ubuntu and xubut nliveCDs with that 30accessibiity scrtipt and had no probs
<heno> janimo: it's a minimal layout with mostly letter keys on level 1 and Function keys, etc. on level 2
<iwj> Oh, no, packages.ubuntu.com is a bit out of date.
<tfheen> iwj: no, I mean https://launchpad.net/distros/ubuntu/+source/firefox/2.0+0dfsg-0ubuntu3
<Kamion>    firefox | 2.0+0dfsg-0ubuntu3 |          edgy | source
<heno> (click the 'tabs' on the right)
<tfheen> janimo: no, it won't fail, but it's bad style.
<janimo> heno: one cannot activate the xfce menu (ctrl-esc)using only onboard AFAIK
<janimo> tfheen: I tried to keep it clean, so one line instead of 3 :)
<pitti> hi iwj
<janimo> basing it on the fact it shoulkd not fail
<Kamion> janimo: casper shouldn't assume particular files on the filesystem image
<tfheen> janimo: well, I'd like to make all the scripts set -e and log errors properly sometime during the fawn cycle.
<janimo> Kamion, tfheen: agreed, I just wanted to keep the patch at minimum as long as it is working
<tfheen> janimo: I'd rather have it correct and clean. :-)
<janimo> tfheen: fine by me, so all sed and cp will be guarded by an if
<sladen> tfheen: thanks
<tfheen> janimo: thanks.
<mvo> tfheen: please have a look at http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061023.1441.diff and let me know if it is ok. very minor update + the fix we talked about at saturday for the compiz upgrade problem (bug #58424, at 54 duplicates right now)
<Ubugtu> Malone bug 58424 in update-manager "Can't calculate the upgrade with unofficial mesa/compiz packages " [Low,Confirmed]  http://launchpad.net/bugs/58424
<janimo> tfheen: should I remake the patch and post to LP? Or bzr?
<heno> janimo: the ctrl key can be made sticky (click it twice), then navigate to level 2 and click Esc -- does that work?
<mdz> tfheen: why are we building a new upstream release of eclipse?
<sladen> shawarma: bug me about that fix after release and I'll upload it via edgy-updates
<tfheen> mdz: it's universe.
<heno> janimo: alternative layouts are easy to make and the user can have custom ones
<janimo> heno: hmm, I think I did not discover level 2, that's why I thiught esc was missing
<tfheen> mdz: ask dholbach; I don't do universe.
<heno> ok :) It needs to be more discoverable, true
<Kamion> mdz: it's only ia64, the rest are done
<tfheen> mvo: you trying to set a new record in dupes or something? :-)  What's the diff from what I ok-ed on saturday?
<Kamion> firefox accepted on amd64 and powerpc; waiting for i386
<mdz> tfheen: it still ties up buildds for hours, so I think you should be in the loop on those decisions
<mdz> i386 should be finished any moment
<mdz> 60 needs-build currently
<mvo> tfheen: its i18n updates, a fix for a logging format bug and a bit more logging. very minor, I can do you a diff without the compiz fixup if you want 
<mdz> maybe half of those CD contents
<tfheen> mvo: you've tested it with and without the unofficial compiz installed?
<mvo> tfheen: yes
<tfheen> mvo: approved.
<mvo> tfheen: thanks!
<mdz> firefox/i386 seems to be just cleaning up after the build
<mdz> yep, finished
<Kamion> yep, will start the publisher in a sec
<tfheen> remember to wait for usplash-theme-ubuntu :-)
<Kamion> oh, no, need to wait for usplash-theme-ubuntu on !i386
<Kamion> yeah :)
<Kamion> and in fact kubuntu-default-settings and edubuntu-artwork would be nice too ...
<tfheen> we need kdelibs too for kubuntu
<tfheen> which just started
<dholbach> tfheen, mdz: the old version was uninstallable and the new one will work better for people (re: eclipse)
<Kamion> kdelibs takes nearly an hour on i386; it can wait for the next publisher run
<tfheen> my thought too
<dholbach> tfheen: closed the kubuntu-theme-thingie bugs.
<tfheen> and the qt updates aren't done either
<tfheen> dholbach: cheers
<mdz> tfheen: seems worth sending a release update to -devel-announce including the latest freeze guidelines
<Kamion> publisher running
<Kamion> (not final, but hey)
<janimo> tfheen: updated patch http://librarian.launchpad.net/4928898/cas.diff
<tfheen> Kamion: thanks
<tfheen> janimo: looks good with an appropriate changelog.
<janimo> tfheen: so should I commit to bzr?
<tfheen> janimo: please do.
<janimo> and add changelog to debian/changelog I assume. will do
<tfheen> yes, correct
<janimo> dholbach: thanks for fixinf kubuntu-default-settings
<dholbach> janimo: de rien
<dholbach> it crashed control-center too :)
<Riddell> dholbach: thanks from me too :)
<dholbach> anytime :)
<CarlFK> http://cdimage.ubuntu.com/daily/current/  and http://cdimage.ubuntu.com/ubuntu-server/daily/current   17-Oct  - no updates in a week?
<tfheen> CarlFK: correct, I'm about to build new images now.
<janimo> dholbach: see, the reporter was right :)
<Kamion> CarlFK: everything's on manual for release preparation.
<CarlFK> tfheen: ok - thought maybe they went somewhere else
<janimo> tfheen, Kamion: commited xubuntu options and fixed v2 for ubuntu to casper bzr
<tfheen> janimo: cheers
<Kamion> Riddell: could do with KDE advice on bug 67024
<Ubugtu> Malone bug 67024 in ubiquity "[EDGY]  charset issue when installing with Norwegian language." [Undecided,Confirmed]  http://launchpad.net/bugs/67024
<ogra> hmm, i just upgraded firefox here
<ogra> the themeing of the search input field seems a bit broken now
<Kamion> don't tell me we need another firefox-theme-ubuntu
<jsgotangco> ogra: i dont notice it?
<tfheen> ogra: how broken?
<mdz> ogra: looks exactly the same here
<tfheen> it looks fine to me, at least.
<Kamion> I don't see any problems with ubuntu2
<mdz> and we didn't change anything about the appearance
<mdz> I've checked my fresh install + upgrades in vmware and it looks fine sa well
<Kamion> Riddell: bug 67302 and dups - where does KDE get its locale from these days? has that changed?
<Ubugtu> Malone bug 67302 in ubiquity "local settings after install wrong" [Undecided,Needs info]  http://launchpad.net/bugs/67302
<Kamion> I'm just trying to reproduce the bug now
<Riddell> Kamion: KDE doesn't have its own built-in charmap table, but Qt probably does
<dam_ned> I am looking for someone running i810 to confirm bug 67196
<Ubugtu> Malone bug 67196 in xserver-xorg-video-i810 "mouse pointer disappears after switch to console" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67196
<ogra> jsgotangco, tfheen, mdz, http://people.ubuntu.com/~ogra/Firefox.png
<Riddell> Kamion: KDE should get the timezone and locale from the system, although you can override the locale in KDE if you want to change it
<Kamion> so how come this broke from dapper->edgy?
<mdz> ogra: that's just you
<ogra> its minor, but noticeable
<jsgotangco> i can't reproduce this
<Kamion> that looks like the breakage from firefox-theme-ubuntu < 0.5.4 or so
<tfheen> ogra: I can't reproduce that on i386, or any of my two amd64s.
<Kamion> it's identical to what I was seeing for a few days a week or two ago
<mdz> ogra: try a fresh profile
<ogra> oh, wait i only upgraded ff ... 
<ogra> firefox-theme-ubuntu is older ...
<Kamion> you're way out of date. :)
<jsgotangco> heh
<Kamion> Riddell: do you know where I'd find the Qt one?
* tfheen twiddles thumbs as he waits for the publisher to finish
<Kamion> it's just running cron.germinate
<mdz> i386 is up to date except for kdelibs
<Kamion> aka nearly done
<mdz> in terms of builds
<shenki> a note on the new firefox build: I'm still seeing the old blue globe as the app's taskbar/window icon. is this intentional?
<Kamion> that changed for me this morning
<jsgotangco> i have the firefox logo now
<tfheen> mdz: same goes for amd64.
<Kamion> oh, no
<jsgotangco> ummm the menu still uses the globe it seems
<Kamion> the icon on the panel changed, but the taskbar / window icon didn't, you're right
<Kamion> and yes, the .desktop file too
<shenki> yep, that's what I was trying to say Kamion
<jsgotangco> uh oh
<Kamion> mdz: ^--
<mdz> Kamion: the .desktop is fine; you just need to log out
<mdz> it gets cached
<jsgotangco> ahh
<Kamion> ok
<ogra> or kill thze panel if youre that evil :)
<mdz> not sure what happened with the taskbar icon
* jsgotangco tries
<Riddell> Kamion: I'm not sure I understand what you think the problem is with bug 67024
<Ubugtu> Malone bug 67024 in ubiquity "[EDGY]  charset issue when installing with Norwegian language." [Undecided,Confirmed]  http://launchpad.net/bugs/67024
* tfheen sighs.  Why isn't https://launchpad.net/+builds ordered by arch by default?
<mdz> Kamion: there must have been some debian hackery I missed
<mdz> ah, yep.  in the install target
<Kamion> Riddell: typing UTF-8 characters into input fields displays replacement characters (rectangles), but only in certain locales
<Kamion> Riddell: which implies to me that something in the widget set is confused about the character encoding it's supposed to be using
* tfheen starts building ubuntu livefs-es
<Riddell> Kamion: the widgets should always use utf-8, it should only convert the encoding when it writes something out
<pitti> http://people.ubuntu.com/~cjwatson/anastacia.txt \o/
<bddebian> Howdy folks
<tfheen> Kamion: is the publisher back on auto?
<jdong> hey, is there an XSession.d equivalent for GDM?
<jdong> i.e. for running a command on GDM startup?
<ogra> yes XSession.d :)
<jdong> ogra: but that runs after the user logs in
<jdong> I need something to run right when GDM initializes the X server
<jdong> (namely to throttle down my video card)
<janimo> jdong: /etc/gdm has also preSession hooks
<jdong> ok
<tfheen> jdong: /etc/gdm/Init, I think
<jdong>  /etc/gdm/Init looks good
* jdong gives it a shot
<tfheen> I'm out for a bit, need to pick up some food.  I'll probably be back before the live images are done.
<Kamion> tfheen: is now
<janimo> oh, so new firefox now has the upstream icon
<jdong> yay, thank you doko for azureus and eclipse and friends :)
<mdz> ok, I think all of the builds for CD contents are up to date now
<mdz> tfheen: ^^
<Kamion> the publisher's on auto; when this run finishes I'll take it off and run it manually again
<mvo> tfheen: I would like to upload a fix for a crash in lock-package in synaptic. http://people.ubuntu.com/~mvo/tmp/synaptic_0.57.11ubuntu13.debdiff <- debdiff. 
<shawarma> sladen: why wait?
* shawarma assumes sladen has infinite memory and knows what I'm talking about.
<mdz> mvo: I think it would be best to queue that for -updates
<mvo> mdz: I agree that it is not criticial, but the fix is trivial. if something else comes up that requires CD rebuilding, maybe we can consider it then?
<melvin> does anyone know how can i install netbeans, eclipse, mono, monodevelop and kdevelop?
<bhale> good question for #ubuntu
<melvin> connect #ubuntu
<bhale>  /join #ubuntu
<sladen> shawarma_away: well, because it's release next week and we're in freeze
<Kamion> mdz: so, ndiswrapper
<Kamion> mdz: I don't think the upgrade thing is fixable in edgy; it will have to be release-noted that you have to downgrade ndiswrapper-utils
<Kamion> mdz: but it may be worth quickly sticking ndiswrapper-utils-1.8 into ship and ship-live
<Kamion> I believe that those utilities are needed for the version of the kernel driver that we're now shipping, and it's only <30K
<mdz> Kamion: I thought we already did that
<Kamion> not as far as I can see; we have ndiswrapper-utils in there
<mdz> grrr
<Kamion> which is transitional and depends on -1.1
<mdz> I assigned that bug to someone who acked they would take care of it
<mdz> infinity: ping ^^
<Kamion> he may have blocked on the hideous upgrade problem of doom
<Kamion> can't say I blame him; it was enough to make elmo agree to work around dak's version constraints in Debian
<Kamion> anyway, I can commit the seed change now and do the promotion, and that will be that; I think that's all we can do
<mdz> Kamion: so what's the "oops" solution?
<Kamion> one extra line in each of ship and ship-live
<mdz> just add -1.8 to the CD so that users can clean up the mess?
<Kamion> yeah
<mdz> please do
<Kamion> they need -1.8 anyway
<Kamion> and that's almost orthogonal to the upgrade issue in any case, even though they're glommed into the same bug
<Kamion> mdz: also, we were going to demote nvidia-glx-legacy to universe, weren't we? I still have that seed diff uncommitted
<mdz> dholbach: my vmware test box, after applying all edgy updates and rebooting, has a solid color background rather than the proper wallpaper
<mdz> Kamion: yes
<mdz> oh, this one had custom wallpaper selected
<mdz> by mark
<doko> dholbach, ajmitch: please have a look at http://people.ubuntu.com/~doko/edgy/azureus.debdiff
<mvo> tfheen: I found another dist-upgrader problem: http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061023.1700_all.diff <- very small diff, but important because if the old cdrom source from the previous distribution is kept around sysinit will still be considered essential and that causes apt to think it should be reinstalled
<Nafallo> ouch
<mvo> Kamion: if something gets demoted now, could I please get a quick ping? because the upgrader needs to know about this
<Kamion> mvo: oh, really? ok
<Kamion> mvo: nvidia-glx-legacy and nvidia-glx-legacy-dev demoted
<Kamion> mvo: do you need to hear about all demotions through feisty development, or will you scan for most of those automatically?
<mvo> Kamion: it scans for them automatically, but at this stage I would like to know so that I can run the script to check manually 
<Kamion> ok
<mdz> tfheen: have you been in touch with sfllaw regarding validation?
<ogra> tfheen, https://features.launchpad.net/distros/ubuntu/+spec/live-cd-share-live-cd should we discuss that in MV ? or should it just be added to feisty goals as is ? i'd like to look into integrating ltsp/liveCD in feisty
<sfllaw> mdz: We talked this morning.
<sfllaw> mdz: I'm phase-shifted a bit so that I'm mostly on European time.
<sivang> re
<Ng> which package should live-cd bugs be filed against?
<Seveas> Ng, depends on the bug
<Ng> although I think this one is probably there already (amd64 not rebooting)
<Kamion> Ng: that's either usplash or casper, hard to say
<Kamion> my guess is usplash
<Kamion> but I could easily be wrong
<Seveas> Kamion, heh, I would have guessed upstart 
<mdz> sfllaw: the test cases need to be distributed more effectively this time; have you spent some time on that?
<Ng> I think it might be upstart too, it leaves me with a flashing cursor and hitting ctrl-alt-del tells me it's going to kill the rc6 script, then doesn't do anything
<Ng> I'll have a search, thanks
<mdz> sfllaw: I also updated the validation process doc to be more explicit about informing individuals of their test case assignments; please review it (would be a good idea to subscribe to the page)
<sivang> mdz: is this about hardware validation ?
<heno> hi sfllaw, could you tell me if bug also affects Ubuntu CDs on your VMware+Server 2003 setup?
<Kamion> mdz: should I accept these dist-upgrader uploads?
<sfllaw> heno: It does not affect Ubuntu.  Only Kubuntu.
<Kamion> mvo: does the dist-upgrader already deal with downgrading ndiswrapper-utils?
<mvo> Kamion: no - I don't know about this issue?
<mvo> Kamion: what bugnumber?
<heno> sfllaw: hm, that's odd. I'll do a closer comparison. If I make some tarballs later can you download and burn to CD to test for me? (just the winfoss part of the CDs)
<Kamion> mvo: it's related to bug 59983
<Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
<sfllaw> heno: I can.  Though the smaller the better.
<sfllaw> Also, the ICO files you use don't work well on Windows 2000.
<Ng> there we go, filed as bug 67765
<Ubugtu> Malone bug 67765 in upstart "RC live CD cannot reboot on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67765
<dholbach> doko: looks good
<Kamion> mvo: http://people.ubuntu.com/~james/tmp/ndishell.txt describes the horrible, horrible pain
<dholbach> mdz: so the background is 'all good' again?
<mvo> Kamion: thanks, having a look now
<Nafallo> pitti: hi! new langpacks for 6.10 will go in 6/11, right? :-)
<pitti> Nafallo: it'll take a while due to our new StableUpdatesPolicy, but around that date, yes
<mdz> dholbach: well, it isn't, but it's not a problem with the package
<mdz> dholbach: it'll be fine when I reinstall it :-)
<mdz> Kamion: I know nothing about any dist-upgrader uploads
<dholbach> mdz: ok :-)
<mdz> sfllaw: please acknowledge
<sfllaw> mdz: Pong.  Found and read your page.
<sfllaw> mdz: Also, we can distribute i386 and amd64 more, but powerpc is a loss.
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/tmp/dist-upgrader.diff
<Kamion> looks ok to me but I was asking more WRT buid scheduling
<Kamion> tfheen: are you doing CD image builds?
<Kamion> sfllaw: I can help with powerpc this time
<Kamion> although not with erase-disk or auto-resize tests
<sfllaw> Kamion: Thanks.
<sfllaw> Kamion: I see you've done some alternate CD Kubuntu.
<sfllaw> Can I put you down for more of that?
<mdz> Kamion: er, how old is this upload?
<Kamion> sfllaw: yes, although note that I'll be in London tomorrow and Wednesday so it's dependent on access to machines there ...
<mdz> Kamion: some of these changes I swear were reviewed and approved last week
<mdz> those first two hunks are very familiar
<Kamion>   112919 | -- | dist-upgrader_200610 | -                    | 26 minutes
<Kamion>          | * dist-upgrader_20061023.1721_all.tar.gz Format: DIST_UPGRADER
<Kamion>   112831 | -- | dist-upgrader_200610 | -                    | 2 hours 50 minutes
<Kamion>          | * dist-upgrader_20061023.1441_all.tar.gz Format: DIST_UPGRADER
<mdz> Kamion: we have elmo's ppc laptop here
<Kamion> yes, I think they were approved last week as post-RC uploads :(
<mdz> Kamion: which can be beaten into submission
<Kamion> I'm happy to abuse it
<mvo> mdz, Kamion: I have a pending fix for #59983 in the upgrader as well (testing it as we speak)
<mdz> mvo: it's time to stop changing the upgrader as it's going on the CDs
<dholbach> seb128: was the gimp upload accepted?
<seb128> dholbach: no
<mvo> mdz: ok, fair enough. I'm sorry about #59983 but it wasn't on my radar until a couple of minutes ago :/
<dholbach> seb128: it'd be nice to have (to get dbg symbols for it) :)
<mdz> it's been on the 6.10 list since RC or so
<tfheen> mvo: dist-upgrader> approved.
<mvo> tfheen: thanks
<tfheen> mvo: why are you changing the translations there each and every time?
* Kamion attempts to reconcile mdz's and tfheen's comments and spins confusedly
<tfheen> ogra: happy to discuss it.
<mvo> mdz: right - I meant I was aware of the general problem but that not the upgrader should fix it
<seb128> dholbach: don't tell me
<seb128> dholbach: there is already a gimp-dbg though
<mdz> mvo: it's time to start spinning CDs and this upgrader hasn't been tested sufficiently yet
<mvo> tfheen: because the upgrader does not use language packs so I use the latest rosetta stuff to make sure that the translations are as up-to-date as possible
<mdz> mvo: I'm sure I saw several hunks of this diff last week, though; why didn't they get uploaded?
<sfllaw> tfheen: Please let me know when you start uploading new ISOs.
<tfheen> mvo: stop doing that.  non-language-pack translations had a deadline a week and a half ago
<sfllaw> I want to get as much of a start on other people as possible, because the validation lab's connexion is terrible.
<tfheen> I don't want us to accidentially pull a bad translation and cause problems becuase of that.
<mvo> tfheen: ok
<mdz> let's agree on a reasonable deadline for the final upgrader for next time
<mdz> tfheen,mvo: ?
<tfheen> mdz: reasonable deadline> agreed.
<mvo> mdz: agreed
<mdz> tfheen,mvo: please agree :-)
<mdz> I think RC
<mvo> tfheen: by RC time ?
<Kamion> so what am I doing for right now? accepting, rejecting, ...?
<tfheen> sure, that's fine.
<mvo> it would be good if the latest upload could make it ...
<tfheen> Kamion: stop the publisher, please.
<mvo> but I understand your concerns 
<tfheen> while we discuss
<Kamion> tfheen: already done
<tfheen> ok, thanks.
<mdz> the 2006-10-17 changes were approved ages ago, but it's now a week later
<tfheen> I think it looks sane, we'd need to wait until this publishing run finishes, but that's just it, isn't it?
<mdz> -            if entry.uri.startswith("cdrom:") and entry.dist == "breezy":
<mdz> +            if entry.uri.startswith("cdrom:") and entry.dist == self.fromDist:
<mdz> that's fine
<mdz> as is demoted.cfg
<tfheen> so it'll cost us about 30 minutes.
<mdz> and the logging
<mdz> and the try/except
<mdz> the rest of it I'm not so sure about
<tfheen> you're unsure about the compiz stuff?
<mdz> that's working around a tainted system
<tfheen> it is.
<mdz> so I'm indifferent, since the code seems isolated enough to that case
<dholbach> (and quite a bunch of people did that)
<mvo> mdz: I did upload a dist-upgrader_20061017.1916_all, was it rejected or something?
<mvo> mdz: this bug has current 55 duplicates (the compiz upgrade issue). this is why I work around this at all, otherwise I wouldn't have cared, but apparently a lot of our users are using it
<tfheen> mdz: I was convinced by mvo's bug-of-doom with 54 dupes.
<mdz> if we change the upgrader now, we don't get started on validation until tomorrow
<Kamion> tfheen: yes, this upload won't need buildd time
<tfheen> mdz: it needs 30 minutes.
<tfheen> Kamion: have you spun live cds or should ?
<Kamion> livefs builds can proceed without this
<Kamion> tfheen: I haven't
<mdz> they do need building
<Kamion> tfheen: which livefses have you done?
<tfheen> Kamion: just ubuntu
<tfheen> I'll do edubuntu and kubuntu now
<mdz> tfheen: it needs 30 minutes to get into the archive, then it needs to be _tested_
<Kamion> tfheen: might as well queue up xubuntu too
<mdz> tfheen: your call
<tfheen> mdz: mvo has already tested it locally, so I'm willing to take it.
<tfheen> both in the compiz-from-wherever and regular case
<tfheen> I'm not saying we don't need more testing, just that it already has seen testing.
<mdz> the upgrader has more test cases than anything else we ship
<mdz> it depends on which packages the user happens to have installed
<mdz> which even among supported packages is pretty boggling
<mdz> happy for you to make the call on whether to include it, so long as it doesn't end there
<mdz> it needs regression testing
<tfheen> ok, so accept + call for extra and explicit testing of the upgrader, then?
<mdz> ok
<tfheen> mvo: you're happy with the current version?  No bad gut feelings or "maybe this isn't right" or anything like that?
<mdz> it'll be very difficult to find a substantial number of real systems to do upgrade testing at this point though
* mvo will ask the 55 duplicates of the compiz failure to re-test for a start
<mdz> mvo: aren't their systems already partially or mostly upgraded? or did it fail early?
<mvo> mdz: it fails early with a error
<mdz> mvo: ok, that's a great idea then
<tfheen> ok, let's take it then.
<mvo> ok
* dholbach hugs mvo
<mvo> thanks
<tfheen> Kamion: upgrade-notifier approved.
<Kamion> accepted
<tfheen> thanks.
<Kamion> I'll drive the publisher by hand and then set back to full auto
<tfheen> is there anything else unapproved?
<Kamion> ubuntu-docs, which IIRC was explicitly not approved?
<tfheen> correct.  I've asked mdke for an updated package which doesn't touch the build system which will go in if we end up doing respins, else it'll go to -updates.
<dholbach> tfheen: he mailed you back already - not sure if you noticed
<tfheen> dholbach: oh, I didn't see that before.  Thanks.
<janimo> tfheen: so the casper a11y fixes are post edgy?
<dholbach> tfheen: it's good I read your mails, hm? ;-)
<tfheen> dholbach: yeah.  Good somebody does.
<tfheen> :-)
<tfheen> janimo: unless we happen to need a respin, yes.
<janimo>  tfheen: ok, thanks
<tfheen> dholbach: if I had seen that mail before, I would have accepted ubuntu-docs.  Oh well.
<mdz> Riddell: there's a report in the forums of bug 56587 on kubuntu
<Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Fix released]  http://launchpad.net/bugs/56587
<mdz> Riddell: is the usplash artwork sorted?
<mdz> Riddell: see http://www.ubuntuforums.org/showthread.php?t=280540
<Riddell> mdz: it was fixed just before RC to a 16 colour image
<tfheen> Kamion_: is the publisher done?
<Kamion_> tfheen: yes
<tfheen> yay.
* tfheen starts spinning install cds.
<mdz> are livefses still in progress?
<Kamion> publisher back on full auto; I'm off in about ten minutes
<mdz> no more main builds pending
<mdz> only azureus it seems
<Kamion> that should be a quick build; I checked before approving it
<mdz> mvo: can you tell what's going on in bug 64615? it's not clear to me whether it's a maintainer script or part of the package management stack which is aborting
<Ubugtu> Malone bug 64615 in courier-authlib "apt-get broken after upgrade to edgy eft (courier-authdaemon package)" [Undecided,Confirmed]  http://launchpad.net/bugs/64615
<tfheen> mdz: edubuntu livefs-es building, there's a problem on king I'm working with Ng to resolve
<mvo> mdz: I think it is a broken maintainer script, but I haven't reproduced it yet so I'm not sure  (I do this now)
<mdz> mvo: thanks
<tfheen> mdz: problem fixed (there was a stray process chewing all the CPU it could get), so we'll have CDs in a little while.
<Kamion> I'm out for much of the evening. Call my mobile if necessary
<tfheen> Kamion: enjoy your evening
<tfheen> ubuntu alternate CDs up
<tfheen> mdke_: sorry about the miscommunication. :-(
<mdz> tfheen: I'm not seeing new alternates
<mdz> tfheen: nm
<ogra> whoops
<ogra> all others are gone ...
<tfheen> edubuntu alternate up
<ogra> yep
<ogra> how did you shrink it so much ...
<ogra> ?
<ogra> 686M feels tiny 
<tfheen> I used a chainsaw.
<ogra> could you spec that for uds ? :)
<tfheen> attacking-edubuntu-with-chainsaw? :-)
<ogra> yeah :)
<LaserJock> well, we did have edubuntu-cd-diet
<tfheen> ogra: I just build the things, I don't watch what's on every variant's disk.
<jdong> would this size insanity one day drive us to squashfs 3.1 + LZMA?
<LaserJock> but the chainsaw spec sounds more interesting
<tfheen> jdong: squashfs 3.1, yes.  lzma, no.  It's too resource intensive, IIRC.
<ogra> tfheen, i know, that wasnt serious ... i was just astonished that we lost 10M
<ogra> (on alternate)
<jdong> tfheen: yeah, I noticed that when Puppy Linux tried LZMA.... the savings are noticeable, but the CPU usage was unbearable on all but the most modern PC's
<tfheen> it would be interesting to see if we could turn up the block cache and down the VFS cache.
<tfheen> since that'd put more blocks in cache => faster access
<pitti> tfheen: can I fill up the CDs with langpacks tomorrow (leaving some breathing space)?
<pitti> I have to leave now for Taekwondo unfortunately
<tfheen> pitti: sounds like a plan
<pitti> cool
<tfheen> kubuntu alternate up
* Riddell cheers
<mdz> tfheen: we should fill the CDs at the same time that we get final langpacks
<tfheen> mdz: modulo a megabyte or two, then.
<tfheen> otherwise agreed.
<mdz> tfheen: right
<mdz> tfheen: in fact maybe we should push it back so that langpacks don't change between RC and final
<mdz> that would let us work out CD size earlier
<mdz> tfheen: anyway, short version, please insert the langpack selection step into the process docs
<Kim^J> When will 7.04 be out for alpha/beta testing ?
<tfheen> langpacks currently have their deadline the same day as RC, though
<tfheen> mdz: already done.
<tfheen> Kim^J: we'll release milestones throughout the whole cycle, as we did for previous releases.
<mdz> tfheen: yes, hence pushing it back farther
<mdz> Kim^J: beta will be in March
<fabbione> Kim^J: sometimes after 6.10 is released perhaps
<Kim^J> tfheen: I wanna be alpha tester when that's about to happen...
<Kim^J> Ok
<Kim^J> Testing Edgy right now... Doing really well... Some irritation bugs though.. but they seem to have disappeared...
<tfheen> Kim^J: you can upgrade from edgy to feisty once feisty opens.  It'll be a rough ride in the start, but you're free to try out.
<Kim^J> There are some broken packages too...
<Kim^J> kxdocker is VERY broken.
<Kim^J> Won't start, wrong conf file for it. and there are nothing really installed...
<mdz> Kim^J: we have a bug tracker for issues like that, but most of our attention is focused on the core (main) and not universe
<Kim^J> SuperKaramba where quite buggy too... Didn't save the things installed ny it...
<Kim^J> kk... well... just myu thoughts on edgy...
<Kim^J> What do I need to know to get involved with helping getting Feisty stable?
<jdong> Kim^J: are the kxdocker and superkaramba problems filed in launchpad?
<mdz> Kim^J: we'll start to work on feisty after edgy is released
<Kim^J> jdong: Should I do that?
<Kim^J> mdz: I know... But what should I know to be able to help.
<jdong> Kim^J: well, it's always the first step towards getting a fix....
<Kim^J> kk
<Kim^J> gonna report some then
<Kim^J> kxdocker is already reported...
<Kim^J> Just 100MB left of the copying... :D
* Kim^J is reinstalling Edgy Eft.
<tfheen> ubuntu desktop CD up
<mdz> Kim^J: your question is very broad, so you get a very broad answer: https://wiki.ubuntu.com/ContributeToUbuntu
<Kim^J> tfheen: Huh?
<Kim^J> Uploading Ubuntu CD?
<mdz> Kim^J: we're in the process of preparing the Ubuntu release, and we use this channel to coordinate that work, so we appreciate keeping things quiet in here during this time
<Kim^J> Ok...
<tfheen> Riddell: kubuntu livefs-es done, I'll build desktop cds once lithium is free.
<mdz> ubuntu alternate succeeded here
<mdz> sfllaw: time to begin a test cycle
<tfheen> edubuntu live up
<sfllaw> Resetting Testing/Current.
<sfllaw> tfheen: Can I set all the image versions to 20061023?
<ogra> sfllaw, please leave the edubuntu testing procedures links in there :)
<sfllaw> ogra: OK.
<tfheen> sfllaw: yes.
<mdke_> tfheen: no worries. Are we there yet?
<tfheen> mdke_: I've decided that I'll accept the docs if we need to reroll the CDs, if not it'll go to updates.
<tfheen> kubuntu desktop CDs up
<mdke_> tfheen: alright.
<Riddell> tfheen: thanks
<tfheen> mdke_: I think we want to roll new CDs to get them filled up with langpacks.
<tfheen> mdke_: so it's fairly sure that the update'll make it
<mdke_> tfheen: cool! Do you need anything more from me? 
<mdz> kubuntu i386 alternate ok
<tfheen> mdke_: no, your email telling me that the build changes were just for the website was needed and helpful clarification enough.
<ogra> woah, the edubuntu live one shrunk even more ...
<mdz> tfheen: could you build DVDs as well?
<tfheen> mdz: yeah, I'll just do ubuntu-server first.
* ogra fires up the rsyncs and goes for dinner and a bit TV ... bbl
<cbx33> ping lucas 
<lucas> pong
<tfheen> xubuntu alternate done, xubuntu livefs-es building
<cbx33> lucas, I'm looking at the motu-tools scripts
<lucas> mine is multidistrotools
<lucas> motu-tools is \sh's
<cbx33> oh?
<mdke_> tfheen: great. Thanks and good luck
<cbx33> did you build the pacakge?
<cbx33> it had your email as the maintainer
<heno> sfllaw: can you put kubuntu live CD winfoss high up on your testing list? I'll only be around for another 2-3 hours today
<cbx33> on REVU
<sfllaw> heno: Sure.
<sfllaw> heno: If you give me tarballs of the windows part, I can even work with you interactively.
<sfllaw> I'm keeping marginally insane hours right now.
<cbx33> lucas, http://revu.tauware.de/details.py?upid=1160
<lucas> ah
<heno> sfllaw: http://people.ubuntu.com/~henrik/winfoss/edgy/kubuntu/20061021/
<cbx33> is that not yours?
<heno> That's what's in the current CDs
<lucas> it is
<cbx33> can I ask a question?
<lucas> it's nearly one year old
<lucas> you can remove it from REVU
<cbx33> oh.....ok
<cbx33> there is a newer one?
<lucas> I'll upload to debian or directly to universe
<heno> though be browser part has not changed for a long time
<lucas> yes, see https://wiki.ubuntu.com/MultiDistroTools
<cbx33> cos  a line apt-get -o Dir=$ID/ -o Dir::State::status=$ID/var/lib/dpkg/status update doesn't work
<heno> nor is it different between ubuntu and kubuntu
<cbx33> it throws back this E: Could not open file 01/var/lib/apt/01/var/lib/dpkg/status - open (2 No such file or directory)
<cbx33> thanks lucas 
<lucas> np
<cbx33> ok I'll get the bar 
<cbx33> bzr
<cbx33> bbl
<sfllaw> heno: Oh good, it's much smaller than an entire CD.
<sfllaw> heno: Downlodaing.
<heno> sfllaw: right. Just untar and burn to a CD, so that start.exe etc. ends up in the CD root
<sfllaw> heno: Will do.
<jdub> the new usplash is great
<jdub> as is the polish to the gdm theme (rather than the proposed replacement)
<sivang> jdub: whom do I send email to to have my blog aggregated on planet.u.c ? :)
<jdub> sivang: read the sidebar (you don't)
<jdub> ah, and a nice new background
<jdub> hooray
<wasabi_> Do launchpad teams have email addresses @something?
<mdz> tfheen: is edubuntu/install/i386 current?
<sivang> jdub: right, thanks
<mdz> wasabi_: no
<wasabi_> Sounds like a good feature!  =)
<mdz> launchpad is not a mailing list manager (yet)
<sfllaw> heno: Looks like the links work now.
<sfllaw> heno: Thanks.
<sfllaw> heno: I will test with the CD images.
<heno> sfllaw: Thanks! AFAICT those tarballs contain the same stuff as the last run of CDs did. So either something went wonky in the build or in your VMware setup.
<heno> I'll be interested to hear how the images fare :)
<sfllaw> heno: As will I.
<sfllaw> heno: The VMware setup is the same, because I've been using the snapshot-revert feature of VMware.
<heno> sfllaw: if it goes wrong again, could you reboot your VM and try from a clean start?
<heno> ok
<sfllaw> Of course.
<heno> sfllaw: I'll be fairly busy in the next 1.5 hr with the a11y meeting, but do ping if disaster strikes :)
<ajmitch> morning
<Nafallo> morning ajmitch:-)
<keescook> ajmitch: permission to upload clamav to plug two security holes?  diff visible on bug 66510
<Ubugtu> Malone bug 66510 in clamav "Security vulnerability in ClamAV" [Undecided,Confirmed]  http://launchpad.net/bugs/66510
<ajmitch> keescook: yes please
<keescook> ajmitch: thanks; done
<Seveas> wasabi, are you wearing your asbestos underwear?
<ajmitch> hi Seveas 
<Seveas> ola
<ajmitch> Seveas: now why would you ask such a thing?
<Seveas> ajmitch, he's posting ideas on the libc list
<Seveas> that should only be done when wearing asbestos underwear
<Seveas> ask pitti (or any of the zillions ofother flamed people)
<pygi> so what if they flame? their damn problem :P
<Seveas> Ulrich Drepper doesn'tflame
<Seveas> he toasts
<pygi> anyway, sleep ^_^
<pygi> he can't touch me, bleh :)
<pygi> now, night night :P
<tfheen> ubuntu-server and xubuntu-desktop up
<tfheen> dvds building
<_ion> Are the built images already available somewhere?
<zorglu_>  q. i rebooted, my root partition reached its 'maximal mount count' and a fsck has been launched, it faileds and display a red 'FAILED' for one second and *automatically* rebooted. not letting me time to read the whole message. is this normal to get this automatic reboot ?
<T`2> anyone here familiar with usb booting with grub?
<tfheen> T`2: this is not a support channel
<T`2> tfheen, well, this is ubuntu dev related though ;)
<tfheen> T`2: oh, how?
<T`2> just trying to package ubuntu onto a USB stick
<wasabi_> Heh. my "update-menus" utility has vanished.
<cbx33> T`2, hehe
<T`2> but so far i haven't figured how to make grub automatically figure the device mapping when it comes up
<cbx33> hows it going?
<wasabi_> Resulting in breakage.
<T`2> cbx33, am able to boot, but i need to map the device manually when i make the boot iamge
<mdz> tfheen: cron will bring down the DVDs for me so that I can test them in the morning
<T`2> its not a universal dd'able iamge
<T`2> s/iamge/image
<BenC> T`2: #grub?
<tfheen> T`2: just install to an usb stick and it'll work.
<tfheen> T`2: or follow https://wiki.ubuntu.com/LiveUsbPendrivePersistent
<cbx33> ahhh
<cbx33> can't remember how I did it now
<tfheen> mdz: great.
<tfheen> they're building now
<T`2> tfheen, oh syslinux based.. hrmm
<cbx33> tfheen, thats how I did it ;)
<T`2> BenC, idle 
<zorglu_> nobody for my 'why fsck reboot automatically after faillure' question ?
<BenC> zorglu_: fsck can initiate changes that require a reboot
<zorglu_> BenC: automatically ? i mean without me having to press a key ?
<BenC> zorglu_: Yeah, because pressing a key is not userfriendly :)
<BenC> it's also not "headless" friendly
<BenC> would be nice if the whole fsck thing took place before root was mounted, to avoid that, but that's a spec that would need to be written :)
<zorglu_> BenC: well announcing your root partition produce a fsck faillure without letting the user read the message, is not exactly what i call userfriendly 
<zorglu_> BenC: if pressing a key is the problem, waiting for 10s is an alternative
<BenC> zorglu_: It's not a failure, it's that fsck exited with an exit code that is supposed to tell the OS to reboot
<BenC> if it were a failure, it would dump to singleuser
<zorglu_> oh ok
<zorglu_> well i am reassured for my root partition (which mount without issue btw)
<zorglu_> but my point remains about letting the user know what is happening (a delay or a key press will do)
<BenC> the problem comes from root being mounted and fsck modifying the filesystem in a way that is not easy to martial back throught the VFS, so a reboot is required to unmount the rootfs and remount it
<zorglu_> i understand, i dont complains about the reboot, more about 'displaying a very frightning message, without letting the user knows what is going on'
<BenC> sure
<BenC> file a bug against the scripts that check the rootfs
<simira> BenC: want any log references for a suspend bug(won't resume)? In case, which?
<zorglu_> BenC: ok
<nictuku> hi, I'd like to draw your attention to #63450. It's a severe bug, IMO.
<nictuku> the postinst script is not indempotent, so upgrading from dapper to edgy will fail in many cases
<BenC> simiar: dmesg
<BenC> simira: ^^
<zMott> are they going to be any more updates
<mdz> only if the sky falls
<zMott> okay
<mdz> why?
<zMott> there are some issue with gaim
<jk> seems to fall a heck of a lot from the sky here :P
<zMott> needing a better irc
<zMott> client
<tfheen> mdz: ubuntu-docs wasn't accepted due to a misunderstanding about the build system being changed (which this was just the web site build system), so I think I'll accept that before building new images with more langpacks tomorrow.
<mdz> tfheen: ok
<mdz> zMott: the gaim developers hang out on #gaim
* Ng had gaim die on him just now. didn't get a bug-buddy though
<zMott> thought there was something flakey with it
<simira> BenC: I have a problem with dmesg, as I have to boot after suspend, to get up and running...
* Arador installs kopete just for IM'ing
<stgraber> Someone can have a look at bug 67355, it's pretty annoying for swiss french users to have their keyboard missing in edgy ?
<Ubugtu> Malone bug 67355 in syslinux "Only one keymap is available for Switzerland" [Undecided,Confirmed]  http://launchpad.net/bugs/67355
<BenC> simira: Ah, right, /var/log/kern.log then
<Sp4rKy> hi :)
<nixternal> hi ;)
<sid> Anyone have a page with information about the firefox logos(the trademarked ones), and the trademarked "Firefox" that just uploaded to ubuntu.com for edgy?
<Burgwork> sid: in what way?
<sid> Burgwork: Well was there some legal(license) between Mozilla Foundation and Canonical Ltd.?
<Burgwork> sid: read -devel
<sid> Is there any info about that on the website somewhere
<sid> k, thanks
<Burgwork> no, there isn't
<Burgwork> https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021981.html
<sid> interesting
<sid> thanks Burgwork
<Burgwork> could we use deb-tags and tasksel (or something similar), to replace metapackages?
<tkamppeter> doko, tfheen, are you there?
<LaserJock> I think that's kinda in the works with tasksel
<Burgwork> LaserJock: but to replace all metapackages?
<LaserJock> one step at a time :-)
#ubuntu-devel 2006-10-24
<LaserJock> I believe *-live are replaced with tasks in Edgy
<Burgwork> what interests me the most is on-the-fly task switching
<LaserJock> Burgwork: yeah, I don't know how feasible that is right now
<LaserJock> I don't know a whole lot about it, but it looks like most of the current tasksel stuff works on tags in the .debs
<LaserJock> and I wouldn't think that would lend itself well to "on-the-fly"
<mjr> a,21
<Riddell> sfllaw: did the kubuntu winfoss get fixed?
<Kamion> ogra: your CDs probably shrunk because linuxprinting.org-ppds was finally pulled back out of desktop post-RC, IIRC
<tkamppeter> ogra, so it was finally decided to ship without manufacturer-supplied PostScript PPDs?
<tkamppeter> People have complained that the PostScript printers were not fully functional.
<tkamppeter> Kamion, or  should we split the linuxprinting-ppds package, as I suggested earlier.
<Kamion> tkamppeter: we're not making any further changes there for edgy now
<Kamion> the linuxprinting.org-ppds seed change was agreed and done weeks ago; it's just that we forgot to upload the metapackages for a while
<Kamion> and it's nothing to do with ogra, so don't bug him about it
<Quash> I'm having trouble loading the Live Desktop on 6.10 RC.  I get a black screen at the desktop stage.  No one on #ubuntu channel can figure it out.  Can anyone help?  I've also filed a bug report with more details.
<Quash> I want to hash out the problem to provide further details for the bug report, as I think it may become a problem for a number of people when 6.10 is release Oct 26.
<Kamion> try the safe mode at the boot screen?
<Kamion> (which forces X to use the vesa driver)
<Kamion> anyway, can't stay to debug, as I need to go to bed in order to get down to Canonical HQ at a sane time tomorrow morning
<Fujitsu> Goodnight, Kamion.
<robitaille> Quash:  what is the bug number of the report you have filed?
<sfllaw> Riddell: Haven't gotten that CD yet.
<sfllaw> Riddell: I think so, but only when mkisofs from heno's tarball.
<Quash> robitaille: Bug #67487
<Ubugtu> Malone bug 67487 in Ubuntu "Install 6:10 RC Failure: Black screen at Live Desktop Stage" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67487
<tkamppeter> Kamion, sorry, I wanted to write "Kamion" instead of "o gra".
<Quash> Yes, in launchpad.  That's it.
<tkamppeter> Kamion, and in the next version (7.04), we can perhaps reorganize the printer drivers on the CD completely, as there we will probably have automatic driver download from FSG OpenPrinting.
<Kaleo> BenC: bug 56090 about the pwc drivers is stagnant
<Ubugtu> Malone bug 56090 in linux-source-2.6.17 "Regression: Webcams using pwc driver produce all-grey images" [Undecided,Confirmed]  http://launchpad.net/bugs/56090
<Kaleo> The bottom line is an important regression for webcams support
<BenC> Kaleo: That's because we cannot include the "working" pwc driver due to questionable code
<BenC> there's lots about it on the l-k mailing list
<Kaleo> I see
<Kaleo> I did not read the thread
<Kaleo> Do you have any good pointer ?
<BenC> not off hand
<BenC> search for "pwc patent linux"
<BenC> something along there
<Kaleo> there was indeed a problem of NDA a while ago
<Kaleo> but the driver was replaced by Luc Saillard's
<sivang> jdub: you have an idea how to make headers, and how to get rid of the annoying underline although in original post only the linkified word is underlined problem in planet? (my feed is hosted on advogato)
<jdub> i have no idea what that sentence means.
<sivang> jdub: actually I have no idea why I wrote it that way ;)
<sivang> jdub: so, if you take a look at my aggregated post on planet, you'll see that the header is the date which is redundent and useless, and that some text is underlined uneccessarily
<sivang> jdub: the orig post in advogato doesn't have this, and I wonder :)
<jdub> the date thing is due to advogato not having titles, but providing the date in the <title> element
<jdub> yo ucan't fix that
<sivang> ah, crap okay
<jdub> the underline is due to <a> instead of </a> in your markup
<sivang> jdub: this is the markup http://paste.ubuntu-nl.org/28023/ , AFAICT I haven't missed the closing anchor tags
<sivang> oh crap, I did
<sivang> jdub: thanks ;)
<AlexFicelle> Hi!
<zMott> is gaim going to get fix's
<robitaille> looking at gaim's bug reports, 71 are currently open, 11 new filed in the last 7 days still open; 7 of those seem to be related to a crash in one form or another
<sivang> zMott: what's your crasher?
<zMott> sent off the bug debug dump to launchpad
<zMott> gaim, can handle ctcp 
<lexual> Can anyone help me out. There is now a patch available for an important epiphany bug: https://launchpad.net/products/epiphany/+bug/56610
<Ubugtu> Malone bug 56610 in epiphany "Automatic search from address entry doesn't work anymore" [Unknown,Confirmed]  
<neuralis> sivang: around?
<sivang> neuralis: here, yes
<sivang> neuralis: what's up?
<ajmitch> neuralis: going to be at MV?
<neuralis> ajmitch: for a few days, aye
<neuralis> ajmitch: why?
<ajmitch> just wondering, there's a bit of server-realted stuff to talk about
<neuralis> certainly, yeah
<ajmitch> including updates on network-auth
<neuralis> how did your soc end up? i never quite figured out what the outcome was
<ajmitch> mostly there
<ajmitch> we'll be using it for feisty, it seems
<neuralis> sivang: are you considering supporting things like incremental backup to an external HDD within hubackup, or do you see that as outside of the application's scope?
<neuralis> sivang: i don't at all get excited about backing up to cd/dvd, but if i could do clicky incremental backups over ssh and/or to an external drive, that'd be rocking.
<sivang> neuralis: I don't consider it completely out of scope, however as people noted to me there are a couple of CLI solutions that enable that, I want to look at GUI wrapping them at some point, but first I want to concentrate on delivering something for the common "non tehcnical" user use case, e.g., slices and CD/DVDs
<sivang> neuralis: there seems to be a tool I've investigated today, written in python, called cedar-backup2
<sivang> neuralis: might be a good candidate for a sich
<sivang> *such
<sivang> neuralis: it's currently in universe, though
<ajmitch> sivang: if it's worthy, write up a MIR for feisty
<sivang> ajmitch: yes, right after I write a MIR for hubacukp and dar ;)
* sivang adds to the TODO
<ajmitch> there are a few things I need in main, too :)
<sivang> hehe
<sivang> neuralis: cedar-backup2 also supports automatic periodical backups, so that functionality could go in as well
<neuralis> well, i think remote systems are a bit of a stretch, but backing up to an external hdd would fit nicely within hubackup, simply as a different backend.
<neuralis> if you're open to patches, i might even provide it (with activation only if rsync is found on the system).
<sivang> neuralis: that might already be supported using the current infrastrucutre, and if so, could be just a day of work. Would you be as so kind to see if we've got a bug about that and/or open if not?
<sivang> neuralis: I
<sivang> neuralis: I'm more then open for patches :)
<neuralis> okay, i'll look into it
<neuralis> i would imagine you don't support incremental backups, which are pretty key to making backups to an external hdd really useful.
<sivang> neuralis: you see, even now you can choose an external hd as the backup target (using stock GNOME file selector sensitive to pluggable media)
<sivang> neuralis: the code for making incremental backups is already there
<sivang> neuralis: it's just needs adjustment in ordre to work using the new UI workflow
<neuralis> ah, interesting.
<sivang> neuralis: this already worked to some extent in the prvious version (dapper's) as I thought ot support X local to Y pluggable device backups.
<sivang> neuralis: but during UDS Paris the team of UI and usability people and I realized we need to break this funcitonality in order to create less clutter and confusion in users.
<sivang> neuralis: compare the dapper and edgy spec and you'll see the "log" ;)
<sivang> woops, I've killed a kitten
<sivang> neuralis: so now the restore functionality and diff backup is going to be integrated into the mime type association handler
<neuralis> sivang: interesting
<neuralis> sivang: are you going to be in mv?
<sivang> neuralis: I wish, but no :-/
<neuralis> ah, okay. i'll look at the code if i have a bit of time, and then we can talk about some of this again.
<sivang> neuralis: cool, thanks.
<neuralis> sure.
<sivang> neuralis: if you don't find my on IRC please email me, I'd hate to miss your input on this.
<neuralis> sivang: not a problem.
<jjesse> has anyone been successffull booting ubuntu or kubuntu on the new intel q965 chipset? cause i am unable to
<lastnode> imbrandon, ping please
<zMott> quit  
<lexual> There is a bug that I reported for hoary. The bug no longer appears in edgy. I want to close the bug, but I'm not sure what status to give it.
<jjesse> fixed released
<jjesse> is what i would give it
<lexual> jjesse: even though I haven't released a fix, and am not aware of where/when a "fix" was released.
<jjesse> welll i guess you could reject the bug, but if it was "fixed" somewhere between hoary and edgy i would asume a fix was made
<lexual> ok, worksforme would seem to make a lot more sense if it was available.
<infinity> lexual: Someone released a fix,even if it wasn't you.
<infinity> lexual: What's the bug?
<lexual> infinity: I guess it's somewhere in xorg 7.0 or 7.1
<lexual> https://launchpad.net/distros/ubuntu/+source/xorg/+bug/12301
<Ubugtu> Malone bug 12301 in xorg "hsync/vrefresh not remembered; monitor off at boot is bad" [Wishlist,Confirmed]  
<lexual> now works with edgy
<infinity> Oh, that's a messy bug with all sorts of tangents.
<infinity> Don't clos eit, please, but just add a comment saying that things work for YOU as you expect them to.
<lexual> cool
<whiprush> stupid question but was the EOL for Hoary announced?
<irvin> whiprush, yup
<whiprush> ok, I either totally missed it, or I can't do simple arithmetic
<ajmitch> hey whiprush 
<whiprush> hi aj
<ajmitch> what's up?
<whiprush> nothing, just wondering when exactly support for hoary ended.
<whiprush> can't find anything on u-d-a
<ajmitch> yeah, I didn't see it announced
<ajmitch> lp still lists it as supported
<ajmitch> but it's past the 18 month mark
<ajmitch> should have gone EOL on the 8th
<whiprush> yeah just wondering
<whiprush> since the mirror is getting some 404's, so I thought I might have been mistaken
<irvin> it was announced on ubuntu-security-announce
<whiprush> there it is, thanks irvin 
<ajmitch> so someone just needs to flick the big switch on launchpad as well
<whiprush> in the past there was an announcement and LWN story, etc. etc.
<whiprush> probably why I missed it
<wasabi> So, I'm fighting the unwinnable battle. Anybody wanna help? :)
<ajmitch> whiprush: http://old-releases.ubuntu.com/releases/
<ajmitch> wasabi: which one?
<wasabi> New NSS table: realm
<ajmitch> ah
<wasabi> I'm patching up libc to support it now, to make sure my heads on straight.
<whiprush> ajmitch: I know where it is. :D I was just serving out 404's to some people from my mirror looking for hoary.
<ajmitch> heh ok :)
<whiprush> which reminded me of "hey, I don't remember a mail ..."
<ajmitch> sorry, I haven't read the u-s-a mail
<ajmitch> and the mail states it goes EOL on the 31st, nice
<ajmitch> wasabi: briefly explain why you must have this new table :)
<wasabi> MOstly because it's the most preferable way to solve the problem. The long discertation is on libc-alpha
<ajmitch> yeah, that's why I said briefly
<wasabi> http://sourceware.org/ml/libc-alpha/2006-10/msg00076.html
<wasabi> =)
<ajmitch> it's a long email for me to read :)
<wasabi> For cross realm auth.
<wasabi> The first one is "how do I display a drop down of realms in GDM?"
<wasabi> The second one is "how do I not make every nss lookup contain every remote LDAP server in a large enterprise".
<wasabi> s/contain/contact/
<wasabi> Drop down could be hacked into GDM hard coded. It would just be fugly.
<wasabi> The second would require circumventing nss for every app.
<wasabi> Which obviously is not ideal.
<ajmitch> definitely not a good solution to just bypass nss
<ajmitch> or hack it into gdm
<wasabi> It's not a solution at all.
<ajmitch> since you have to hack it into everything that needs it
<ajmitch> ok, I managed to wade through that email
<wasabi> You should read the post. :)
<ajmitch> no replies to it yet?
<wasabi> Nope. Just posted it today though.
<wasabi> It really is the proper solution. This probably is at the core of nss...
<wasabi> how do you seperate lists of users and groups by some named division of management.
<ajmitch> yeah, your suggestion sounds sane at a glance
<wasabi> Also, we still must hack user@REALM names.
<ajmitch> though how much opposition there'll be to extending NSS is yet to be seen
<wasabi> Part of this will also be "fixing" every app that stores any thing long term not using the uid.
<wasabi> Yeah.
<jelmer> nss is somewhat standard so it'll be a lot harder to modify it
<jelmer> then to extend it
<ajmitch> hey jelmer 
<jelmer> s/then/than/
<wasabi> Yeah. It looks like people have been okay with adding tables over the years.
<wasabi> Just not with modifying any of the structures.
<wasabi> So, passwd is not changing, period.
<jelmer> hey ajmitch, wasabi 
<ajmitch> how would you lookup users in a realm though?
<wasabi> jelmer: Samba guy?
<wasabi> ajmitch: New functions like getpwent
<wasabi> getpwent_rlm or somethign
<jelmer> wasabi: jup
<ajmitch> wasabi: he's our friendly samba contact :)
<wasabi> Probably make up a "realm id"
<jelmer> is there any reason why workstations would generally have more than one realm?
<wasabi> Yes. cross realm auth.
<jelmer> or are you going the Apple way and installing a KDC on every workstation ? ;-)
<wasabi> jelmer: You've seen Windows on an AD in a large forest?
<wasabi> On the login screen you have a choice of this computer and all of the realms.
<jelmer> wasabi: right, but the main difference is
<wasabi> But you can also access resourses on those remote realms.
<wasabi> And programs need to be able to resolve SIDs 
<jelmer> they have SID's to identify users, we only have uint32s
<wasabi> Yup.
<wasabi> That sucks.
<wasabi> The best and only solution I can come up with is name spacing the uid space.
<wasabi> https://wiki.ubuntu.com/NetworkAuthentication/ScratchPad  <--- there
<jelmer> that would have to happen in the file system as well though :-/
<wasabi> Nope.
<wasabi> Same 32 bits.
<wasabi> We have limited space compared to windows though, but I've taken a look at the AD setups I've seen, and don't think we're hitting a wall.
<wasabi> Who will have more than 4096 realms?
<wasabi> heh
<fabbione> morning
<wasabi> jelmer: Of course, when we're joining to AD, the new 2003 creates unique UIDs for us apparently.
<wasabi> Not sure if that is cross forest though.
<ajmitch> morning fabbione 
<jelmer> wasabi: Ugh
<wasabi> I suspect it will be, and stored in teh GAC.
<ajmitch> jelmer: I see you got tp3 of samba out :)
<wasabi> jelmer: Yeah. Well. Other suggestions? :)
<wasabi> I think this is hte best I can do with 32 bits.
<wasabi> jelmer: 1048576 users, which isn't that big.
<wasabi> But I've never seen a single domain with that many, yet.
<wasabi> You start having to forest for other reasons way before then.
<Seq> does anybody know the proper way to kill "maintainer-script-calls-init-script-directly"?
<ajmitch> Seq: invoke-rc.d in the maintainer scripts?
<wasabi> And the likely hood of a collision in a merge of two companies is "low", with random 11 bit domain ids
<wasabi> 2048 I mean, actually.
<jelmer> wasabi: I still think it's plain ugly though.. 
<wasabi> I agree.
<wasabi> But it needs to start happening.
<wasabi> We need to get our systems into this space before people will fully understand the problem.
<jelmer> Well, do you really want ot be able to select realms that way?
<Seq> ajmitch: thank you very much
<wasabi> jelmer: I want to be able to access cross realm resources.
<wasabi> Including file shares, such as NFS.
<jelmer> before hacving proper kerberos integration?
<wasabi> And SSH.
<wasabi> Especially SSH.
<zMott> using irc, and was wondering what is the best irc client for ubuntu?
<wasabi> jelmer: This is part of that.
<wasabi> They all go together.
<jelmer> wasabi: I can see the use for that, I really do. 
<jelmer> I'm just wonder whether this might be a bridge too far for initial kerberos/ldap support
<wasabi> Also, I do not honestly believe we will be backing outselves into a corner.
<wasabi> Since we are already in the same corner.
<wasabi> At some point, somebody will be unsatisfied with static length UIDs, and they'll have to fix it.
<wasabi> But that is not a change that is possible to push at this point.
<wasabi> Too much politics.
<jelmer> Yeah, that's /a lot/ of politics
<jelmer> as it requires richer (non-POSIX) interfaces
<wasabi> I think the addition of a simple realm table, some functions to qualify searches of passwd and group based on realm, and a more robust libnss-ldap, that take that into consideration, can get us a long way.
<wasabi> And I think it's possible.
<wasabi> Where libnss-ldap can be configured to locate remote ldap servers of remote realms.
<wasabi> And query those for remote users.
<jelmer> and so you're going to add a bitprefix to remote users?
<jelmer> to prevent clashes with local uids?
<wasabi> To any network user, yes.
<wasabi> This will be defined in libnss though, so you can override it just like you can now.
<wasabi> libnss-ldap that is
<jelmer> what about matching uids on NFSv4? 
<jelmer> or winbind-created uids?
<wasabi> Doesn't really solve the problem except with NFSv4.
<wasabi> tars need to work.
<wasabi> ya know?
<jelmer> tars?
<wasabi> backups of user data.
<wasabi> You need to be able to extract it and retain perms.
<jelmer> NFSv4 has its own way of sharing uids across the network and so has Samba
<wasabi> Yeah. I know.
<wasabi> Well, do YOU have a domain with more than a million user accounts?
<wasabi> Also are you going to be at umv? :)
<Fujitsu> wasabi, I would presume a number of enterprises do.
<wasabi> Me too, and I *suspect* they are cross realm.
<wasabi> Which is only be being unable to imagine a building that can fit a million people.
<wasabi> s/be/me
<jelmer> wasabi: no, but even if I did - this breaks winbind and NFSv4 mounts across hosts
<wasabi> How so?
<Fujitsu> Maybe, but not necessarily. It's very possible to have a cross-campus domain.
<wasabi> winbind doesn't need to assign uids.
<wasabi> NFSv4 can map, on string name, and still works.
<jelmer> no, but it needs globally shared uids
<wasabi> globally?
<jelmer> well, it needs them to be shared globally if you want matching uids on differnet workstations
<wasabi> Yes. How does this break that?
<wasabi> It actually circumvents it.
<jelmer> because if somebody copies a file foo from host a to host b, host b will mask the uid for that file
<wasabi> libnss-ldap is used to deliver the "enoughily" unique UID to the workstation.
<jelmer> wasabi: I won't be in mv unfortunately, too busy with uni :-/
<wasabi> The tools for "our directory server" will generate that based on the namespacing of the uid.
<wasabi> Everybody elses still has to do something.
<ajmitch> jelmer: unfortunate, would have been good to have you there
<wasabi> I actually do this at work now, just by hand.
<wasabi> Yeah, i'd love a samba person there.
<wasabi> Do any work/live in the area?
<wasabi> This obviously is core to what they're doing.
<jelmer> Yeah, Jeremy (who is with Novell) lives in San Jose
<whiprush> anyone in google?
<whiprush> jelmer: you think he'd be interested in dropping by?
<wasabi> idra already gave me a mouthful about how I should just use winbind. I do understand where he's coming from, but there is a lot I can't ignore.
<wasabi> Like, the whole, we'd like this to work on fully free LDAP/KDC configs, and keep about the same.
<wasabi> Where winbind is pretty irrelivent.
<jelmer> wasabi: I don't think you sould be using winbind, mainly just that
<jelmer> using uids this way is going to come back to haunt you
<wasabi> I know. But not using them at all doesn't solve a problem.
<wasabi> Forced into a corner.
<wasabi> I don't take this lightly. =)
<wasabi> I know, somebody somewhere is going to hit a duplicate rid, if this takes off.
<wasabi> Less likely a duplicate uid.
<wasabi> But it's going to happen.
<jelmer> Well, people will complain if two users with the same name turn out to have diffent uids
<wasabi> Well, not likley to happen...
<wasabi> username@REALM
<wasabi> Forced into that corner too. ;)
<jelmer> Well, there's no way to merge realms, right?
<wasabi> Define merge?
<jelmer> combine them to be one
<wasabi> Technically it would operate the same as MS's does.
<wasabi> They have a tool.
<wasabi> Regenerates SIDs, I believe.
<wasabi> Basically just scripts making new users in the new realm.
<jelmer> It'll probably define an alias in the new domain pointing at the old sid
<wasabi> Hmm.
<wasabi> reading.
<jelmer> so that you can still access your old files
<wasabi> Yup, you're right.
<wasabi> Well, this is why I say that creating our own directory server is going to be a multi year task.
<wasabi> And that we can tackle the client side a bit easier.
<wasabi> There is SO MUCH to consider in a fully directory service.
<jelmer> whiprush: jeremy might be interesting in attending, though I'm not sure what Novell's policy is on attending Ubuntu conferences :-)
<jelmer> whiprush: And that's why I think cross-realm authentication should be step (2)
<jelmer> single-realm authentication and integration is going to be useful for a lot of people
<whiprush> jelmer: I don't mind sending a mail. I was more interested in Jeremy the Samba Hacker more than Jeremy the Novell Employee. :D
<wasabi> I just work in too many places who would be really disappointed by not being able to access remote resources properly.
<jelmer> wasabi: Is there at least going to be an option to turn off this behaviour?
<wasabi> And, I guess, I'd rather get forests using unique UIDs now, vs planning to create conflicting ones now.
<wasabi> jelmer: All I'm doing is standardizing a bunch of methodologies and fixing a bunch of existing tools, which will set this up. libnss-ldap needs love, libpam-krb5 needs love.
<wasabi> We need a realm table for the thing to be useful.
<wasabi> libnss-ldap will still have as many configuration options as it does now.
<jelmer> As long as I can turn off the uid trick, I'm happy :-)
<wasabi> Dunno what you mean by that?
<wasabi> This is something that happens on a server that nobody has created yet. :)
<wasabi> The uid trick has nothing to do with the client.
<wasabi> Hell, you can put whatever you want into your LDAP.,
<jelmer> sorry, s/can/will be able to/
<jelmer> wasabi: what exactly would this be useful for for remote SSh though?
<wasabi> Tying the thing together, so admins don't have to go through mental gymnastics to copy files.
<wasabi> You put a file on a share, you expect to be able to ssh someplace and get it.
<jelmer> sure, but that's kerberos cross-realm authentication - why does that need uids?
<wasabi> Because the system you log into needs to map your login name to a uid, in order to create said files.
<jelmer> I can copy stuff to foo@someothercompany as long as I've got jelmer@VERNSTOK.NL in .k5login on my account there
<jelmer> but you'll be using the uid of your account on the remote server anyway, that's the nature of ssh
<jelmer> or am I misunderstanding you?
<wasabi> Well, I don't know if you're seeing the entire picture. I don't really mean "ssh works!" as much as "assumptions made by the admin using ssh hold true as they should."
<wasabi> tar czvpf somestuff; scp somestuff me@remotebox.remotecompany.com:/tmp
<jelmer> if you do an scp that way, then the remote file will be owned by 'me' anyway
<wasabi> Sure, but the stuff in it won't.
<jelmer> not by whoever you are on the local host
<jelmer> right
<jelmer> so if you locally have files that are owned by root (0) that you tar
<jelmer> and then upload
<jelmer> then the remote root user would own the files - how's uid mapping going to solve that?
<jelmer> or is root's uid going to be != 0
<wasabi> Solve what? That worked as intended.
<wasabi> There's no uid mapping...
<jelmer> ok, so if that worked as intended, what are you trying to solve?
<jelmer> sorry for being ignorant :-)
<wasabi> Well, I don't know why you insist on tarring files owned by root.
<wasabi> When I make files I tar files owned by users.
<Fujitsu> jelmer: The other UIDs on the system need to be consistent throughout the network.
<wasabi> For backups that is.
<jelmer> Fujitsu: Yes, but adding a prefix to the uid isn't going to solve that
<wasabi> Of course not. But it eases the job of keeping them unique for any given 2 domains that want to interact.
<wasabi> You have a 1/2048 chance of getting screwed.
<Fujitsu> If we don't have the prefix, then massive conflicts will occur, and the world will explode.
<wasabi> Which is better than a "everybody start numbering at 10000" like they do now.
* jdub takes out planetary insurance.
<fabbione> hey jdub 
<jelmer> 1/2048 is pretty high imho
<wasabi> I agree. =)
<wasabi> But it's better than 1/1
<Fujitsu> jelmer: it is very high, but there's not much that can be done with 32 bits :(
<jelmer> I'd rather be screwed constantly than occasionally, that way you know what you're up against
<wasabi> It is, honestly, the best we can do.
<jdub> morning fabbione!
<wasabi> Haha.
<wasabi> That's an interesting position to take.
<Fujitsu> Until we want to take the non-trivial step of moving to 64-bit or so UIDs, 1/2048 is really the best that can be done.
<wasabi> Fujitsu: MS has... "unlimited" length SIDs
<jelmer> wasabi: also, and this is the samba dev in me talking, what if both realms talk to a 3rd realm ADS realm and both run winbind?
<Fujitsu> wasabi, how do they manage that!?
<wasabi> Fujitsu: The structure contains a length.
<wasabi> Fujitsu: Each workstation does have a local ... 32 bit uid it uses, keeps a kernel map of SID->UIDs that is basically cleared on reboot.
<wasabi> UIDs never leave a process.
<wasabi> SIDs are used for all storage and communication.
<wasabi> We're not in that situation.
<Fujitsu> True...
<wasabi> Fujitsu: the first domain you create gets basically a "domain component" of the sid, users created in it append to it.
<wasabi> sub domains extend the firsts sid
<jelmer> the limit is 16 rids in one sid if I'm not mistaken
<wasabi> Oh. Well, that's ungodly huge.
<jelmer> yep, and they're globally unique...
<jelmer> a 
<wasabi> As much as possible. =)
<wasabi> ie, every RID is very large and very random.
<jelmer> well, some of them are hardcoded
<jelmer> such as the BUILTIN domain, administrator user
<wasabi> jelmer: I guess what I hope to solve with this, is to get a basis for where we're heading towards... which is either going to be a massively huge UID, or a better schem.
<Fujitsu> It wouldn't be that difficult to use the MS idea, would it? It's non-trivial to adjust the UID size throughout every application that uses UIDs, but it wouldn't be difficult to make FSes take larger ones; ACLs are already abitrary in length...
<wasabi> I want to solve the client side, because I believe it's possible. ;)
<wasabi> The "uid namespacing" is something that needs to be considered when we start our own LDAP server infrastructure.
<jelmer> Fujitsu: fixing the applications is really really a lot of work
<wasabi> Until then, the admin of the LDAP server is responsible for creating unique UIDs.
<wasabi> WIndows 2003 R2 now does it for us automatically.
<jelmer> Fujitsu: + upgrading the existing fs installs
<jelmer> Fujitsu: and breaking posix compliancy
<Fujitsu> jelmer: I said it's non-trivial to do the applications...
<Fujitsu> But it has to be done at some point.
<Fujitsu> (the FS stuff)
<wasabi> I want to be wise to the policitcal situation.
<wasabi> Current Linux people simply do not understand.
<jelmer> Fujitsu: I think nontrivial even is an understatement :-)
<wasabi> Seriously.
<Fujitsu> We can't live with 32 bits for ever, I don't think.
<wasabi> I want to get our systems into those situations, where we're pushed, and people are forced to think.
<wasabi> When Canonical gets over a million users in a companies domain on their LDAP server, they'll have the clout to do such a change.
<wasabi> They do not now. Nobody does.
<jdong> when mvo wakes up, tell him I said thanks for dist-upgrader... that thing is just amazing :)
<jelmer> wasabi: I agree it's a bad scheme at the moment
<wasabi> I think it solves more problems than the local winbind idea.
<wasabi> Additionally, the winbind idea simply doesn't work on non MS domains.
<Fujitsu> Local winbind is really hackish, IMO.
<jelmer> winbind isn't supposed to fix this sort of thing
<wasabi> Yeah, I know.
<wasabi> But it sort of makes the problem go away.
<wasabi> You join, and it works, until you try to do something that requires matching UIDs.
<wasabi> Most admins of course have NFI what that even means.
<jelmer> you can share sid->uid mappings with winbind
<jelmer> they can be in LDAP
<wasabi> Fujitsu: Take NTFS. It has a table of SID->NTFSID mappings. Basically each FS has it's own concept of a unique user.
<wasabi> That's a static length, because allocating blocks of an huge SID is not efficient.
<wasabi> But userspace never sees that, ever.
<jelmer> another solution, one which we're pursuing in Samba4
<jelmer> is optionally storing a SID in an xattr when possible
<wasabi> That's interesting.
<wasabi> But I really don't want SIDs on the Unix box.
<Fujitsu> jelmer: I was thinking of using them, because they have arbitrary length.
<jelmer> wasabi: well, you can use whatever you want - for example, I think using the UUID of the machine they come from (mac address?) or something would make sense
<jelmer> not sure how well tar et al cope with xattrs though
<ajmitch> some tar variants have support for them
<Hobbsee> hey ajmitch 
<ajmitch> it's needed for things like selinux labelling
<ajmitch> hello Hobbsee 
<Fujitsu> Afternoon Hobbsee.
<jelmer> ah, right
<Hobbsee> hey Fujitsu 
<wasabi> whiprush: Does that gossip/telepathy thing work?
<jelmer> anyway, time to get to uni - bye!
<wasabi> bye!
<wasabi> thanks for the convo!
<ajmitch> jelmer: see you later :)
<Fujitsu> Bye, jelmer.
<wasabi> libc compiles slowely. =(
<Fujitsu> wasabi, what are you doing to it?
<wasabi> adding a new nss table
<Fujitsu> Oh, you're actually doing that?
<wasabi> yeah
<wasabi> seems to not be the hardest thing in the world to do
<Fujitsu> (that's quite an impressive email you sent to libc-alpha)
<wasabi> people read that list?
<ajmitch> wasabi: sure
<ajmitch> isn't it fun reading?
<wasabi> I'd rather clean my ears.
<Fujitsu> Wouldn't it be nice if we could migrate easily to, say, 64-bit UIDs in everything?
<ajmitch> Fujitsu: you'd find it'd be quite painful
<Fujitsu> ajmitch: there was an `if' there...
<wasabi> Well, it took Linux hitting the 16 bit mark before anybody did the migration to 32 bit.
<wasabi> Lets learn from that, nobody is going to do shit until we hit the 32 bit mark.
<wasabi> ANd that's "ok"
<ajmitch> and you can see that 32 bits just isn't enough for everyone
<Fujitsu> wasabi, we've hit a barrier here because of that limit.
<wasabi> Because of 32 bit limit?
<Fujitsu> Yes. You can't easily split it into two reasonably-sized pieces.
<wasabi> We're imagining we will hit it eventually, in an IRC channel.
<wasabi> Which is quite different from a customer dropping our product because of it.
<Fujitsu> When did Linux migrate to 32 bit?
<wasabi> Looks like 2.3
<Fujitsu> Oh, so not too long ago...
<Fujitsu> That's only 6 or 7 years...
<wasabi> Well, wish somebody had spoken up about realms back then. It's a very simple concept, and has been done for ages.
<wasabi> Look at NT4 if you want. =/
<Fujitsu> Yeah :(
<Fujitsu> What to do, what to do...
<wasabi> Well, I wish I could get realm put into passwd cleanly, but that's obviously not happening.
<wasabi> Hey wonder if gecos has a field for that.
<Fujitsu> Why not?
<wasabi> passwd is posix.
<wasabi> Extending it would break "everything"
<Fujitsu> Hm...
<Fujitsu> We need a POSIX-ng!
<wasabi> Well, no reason to change the semantics of passwd... just add another table with new semantics.
<wasabi> If there are APIs to query a list of users within a given realm, and a nss module can translate that into a DNS SRV lookup on a remote DNS server, and a LDAP query on that remote server, all's good.
<Fujitsu> What would the format of that table be?
<wasabi> name:rid:display name
<wasabi> maybe just name:rid
<Fujitsu> Yeah, I see no point for display name.
<Fujitsu> That'd be really nice to put into passwd :(
<wasabi> Could learn from past lessons and add like, 8 string fields to it.
<wasabi> JUST IN CASE
<wasabi> So, I expect some new method like... setpwent_rlm(rid)
<wasabi> Or similar.
<wasabi> me->bed
<wasabi> night
<ajmitch> night wasabi 
<Fujitsu> 'night, wasabi.
<BHSPitLappy> GRR.
<fifteenrabbits> yeah?
<BHSPitLappy> dapper went windows on me.
<Sp4rKy> hi there
<Sp4rKy> i need some information about the ubuntu user creation process in the live CD
<Kamion> apt-get source casper and look in scripts/casper-bottom/10adduser
<Sp4rKy> Kamion: i'll do :)
<Sp4rKy> in fact, i want know if the process uses /etc/skel when it creates the ubuntu user
<Kamion> it uses user-setup to do the hard work (apt-get source user-setup; it's an installer component)
<Kamion> it uses adduser, so yes
<Sp4rKy> ok
<Kamion> (user-setup uses adduser under the hood)
<Sp4rKy> because i'm "forking" the UBuntu live CD to an Ebuntu version
<Sp4rKy> and i need the ubiquity icon in the bar
<Kamion> the same script handles that for other versions, actually
<Kamion> by explicit copying of desktop files
<Kamion> copying to some other enlightenment-specific location, or prodding enlightenment in some way or whatever would be ok
<Sp4rKy> yep
<Kamion> I recommend against putting stuff specific to ubiquity in /etc/skel, because it will then be hard to rip it out for the installed system
<Sp4rKy> i've just need to create all the .e rep in /etc/skel
<Kamion> I recommend against that. easier to just shove it into the bar in 10adduser
<Sp4rKy> i don't understand ?
<Kamion> as in, after the user has been created, create the files in its home directory, appropriately owned
<Sp4rKy> (i'm french, and my english isn't good) :/
<Sp4rKy> ok
<ajmitch> Sp4rKy: are you using proper packages for ebuntu this time?
<ajmitch> hey pitti 
<Kamion> you have to create those files dynamically anyway, as they should not end up on the installed system so they shouldn't be in the squashfs
<Sp4rKy> ajmitch: i use our package
<ajmitch> Sp4rKy: I mean ones that aren't made with checkinstall :)
<Kamion> so you might as well just create them directly in the user's home directory rather than messing about with /etc/skel
<jsgotangco> ajmitch: i dont think he's the guy who did the checkinstall
<Sp4rKy> ajmitch: :)
<ajmitch> jsgotangco: I know he's not :)
<Sp4rKy> ajmitch: we try
<Sp4rKy> Kamion: yes ..., so create it in the 10adduser script ?
* ajmitch would rather see e17 packages in universe for feisty where possible
<pitti> Good morning
<Sp4rKy> hi pitti 
<Sp4rKy> another question :
<Sp4rKy> the bin/ and program/ rep only contains windows applications, right ?
<pitti> hi Sp4rKy, moin ajmitch 
<Sp4rKy> Kamion: where are the casper script in the live ?
<Sp4rKy> i don't find them :/
<infinity> Sp4rKy: In the initramfs.
<Sp4rKy> :)
<Sp4rKy> infinity: initrd maybe, no ?
<infinity> Well, the filename has "initrd" in it, for backward compatibility with bootloaders, but I assure you it's an initramfs. :)
<Sp4rKy> ok :D
<Sp4rKy> i have to go
<Sp4rKy> thx for your help :)
<tfheen> pitti: I have accepted the ubuntu-docs upload.  Once that is in, please do fill up the CDs with langpacks.
<tfheen> pitti: but make sure to leave a little space, I'd hate having to reroll because you were too optimistic. :-)
<pitti> tfheen: is 5 MB okay?
<tfheen> that's plenty
<pitti> or do you expect larger changes still?
<tfheen> I was thinking more like 1-2MB
<infinity> 5MB is a lot.
<pitti> tfheen: what about oo.o-l10n? will there still be an upload?
<infinity> doko_: ?
<tfheen> pitti: what about oo.o-l10n?  I don't have any email about that and can't find it in my scrollback
<pitti> tfheen: ISTR that there was another upload planned, but I didn't see one
<tfheen> pitti: maybe I'm just ignorant or something, but I can't remember about it.
<tfheen> s/about//
<tfheen> I can't write English either.
<pitti> tfheen: ok, I'll do the langpacks now, and *if* there should really be another oo.o upload, I'll do immediate adjustments
<tfheen> there won't be a full oo.o upload, that's for sure.
<tfheen> waaay to late.
<pitti> (-l10n, I meant, sorry)
<pitti> even that is likely too late anyway
<tfheen> I was hoping to have the images done last night be the final ones, code-wise.
<pitti> wow, there's really plenty of space on the desktop CDs
<highvoltage> :)
<Burgundavia> have we removed gthumb yet?
<pitti> ogra: shall I fill up edubuntu CDs for you with langpacks as well, or do you have other plans for that?
<pitti> ogra: and do you aim for 650 MB or 700 MB images?
<tfheen> pitti: he's been doing 700MB images forever, afiak
<tfheen> afaik, even
<pitti> funny, ogra has always had the tightest images, and now there are 50/86/66 MB free on the lives
<jsgotangco> yes i was a bit confused when i saw the build today
<tfheen> I'm not exactly sure what's happened there.
<jsgotangco> "we got space"
<jsgotangco> heh
<tfheen> I just hope we haven't run into a bug in germinate
<pitti> tfheen: well, the images have been that small for quite some time now
<tfheen> pitti: you're telling me when you're done?
<pitti> tfheen: yes, I will
<tfheen> thanks
<Kagou> hi
<pitti> tfheen: ok, I adjusted ship and live accordingly; hm, AFAICS this doesn't even require a -meta upload?
<tfheen> it doesn't, afaik.
<tfheen> it requires the publisher to run so it picks up the new Task headers.
<infinity> publisher's doing it's thing in a sec.
<infinity> There, publisher going.
<pitti> tfheen: right, ./update shows 'no changes found' after updating live, and ship has never required a -meta upload
<pitti> tfheen: Kubuntu CDs are full, and I'm not sure about edubuntu; I'd rather wait for ogra
<tfheen> I can do ubuntu first.
<tfheen> once the publisher is done
<doko_> infinity: ?
<infinity> doko_: Were there plans for a final OOo-l10n upload, or is what's in the archive what we're shipping with?
<infinity> pitti: We removed the *-live packages, so we could mangle livecds with nothing but seed changes.
<pitti> infinity: sweet
<Burgundavia> infinity: you planning on nuking the meta packages altogether?
<infinity> Burgundavia: No, just *-live, since it's not an end-user package.
<Burgundavia> right
<infinity> Running germinate... .........
* infinity gets out and pushes.
<doko_> infinity: I do have a new export from rosetta, and updates for eo and ku. but ... I do have to make OOo packages for -proposed/-updates anyway. 
* infinity nods.
<infinity> So we'll call what's in the archive final, then?
<infinity> tfheen: publisher done and back in full-auto.
<infinity> tfheen: And no new OOo-l10n, apparently.
<infinity> tfheen: So, let the CDs fly.
<tfheen> infinity: hooray, thanks.
<tfheen> asking because my brain just stopped working: I need to rebuild the livefs-es, right?
<infinity> tfheen: Yes, pitti updated live.
<infinity> tfheen: And ubuntu-docs is in desktop (which is on the livefs)
* pitti hopes that squashfs compression is roughly equal to .deb compression
<pitti> tfheen: ^ if not, then I need to adjust the live seed again
<infinity> Vaguely similar.
<pitti> I only have hard data for .deb sizes, so alternates should get fine
<infinity> squashfs should be a bit better in some cases, since it's got largers streams of data to work with.
<pitti> I'm only concerned about the 'squashfs gets it worse' case, then I ruined a livefs build
<infinity> And locale data is highly repetitive, so compressing it all together instead of per-language should yeild better results, one would think.
<tfheen> pitti: you'll get some numbers in a little bit
<pitti> right
<dholbach> good morning
<janimo> hi dholbach
<BHSPitLappy> hooooooo
<dholbach> heya janimo
<tfheen> ubuntu, kubuntu alternate up
<tfheen> edubuntu install images up
<fabbione> tfheen: is ubuntu server up?
<tfheen> fabbione: it was up last night.  Langpacks are slightly less interesting to you, I guess.
<fabbione> tfheen: yeah just making sure
<dholbach> hey seb128
<seb128> hi dholbach
<dholbach> I find bug 66769, bug 66779 and bug 67784 slightly worrying
<Ubugtu> Malone bug 66769 in ubiquity "Ubuntu 6.10 Desktop for i386 installation crashes on squashfs_read_data (Oops: 0000 [#1] )" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66769
<HeXiOn> hello
<Ubugtu> Malone bug 66779 in ubiquity "Ubuntu 6.10 Desktop for i386 installation crashes on zlib_inflate_codes" [Undecided,Rejected]  http://launchpad.net/bugs/66779
<Ubugtu> Malone bug 67784 in linux-source-2.6.17 "Edgy RC1 is crashing in the installation at 47%" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67784
<HeXiOn> there's an application installed by default in edgy (it wasn't in dapper) that manages remote control keys. Anyone knows what application it is and how to deactive it????
<dholbach> I'll do some installs on i386 now too and see if it still happens
<tfheen> dholbach: aiui, Colin described those as "mostly bad CDs"
<dholbach> tfheen: I downloaded a new .iso, burned on a new CD, got a new cd drive and did a cd test
<dholbach> and the people in the bug reports did those tests too
<dholbach> anyway - I'll let you know how the fresh installs go
<tfheen> dholbach: if you manage to reproduce them, please put a dmesg into the bug reports.
<dholbach> tfheen: alrighty
<fabbione> ajmitch: why do you need xen-utils to build libvirt?
<ajmitch> fabbione: I need libxen3.0-dev
<fabbione> afaict libxen-dev is enough
<ajmitch> yes
<fabbione> so that B-D can be dropped
<ajmitch> some of that packaging is probably before I split libxen* from xen-utils-3.0
<fabbione> ok
<ajmitch> that's why I did the xen split in the first place :)
<fabbione> yeah make sense.. just asking if i missed something when i did build it yesterday
<mdz> re-morning
<ajmitch> I'll check it over, I haven't used it on my laptop with xen yet
<ajmitch> hi mdz 
<ajmitch> xen 2.6.17 has some issues on amd64 currently
<fabbione> ajmitch: ok.. i just need the pure library as B-D really
<fabbione> i am not using xen itself
<ajmitch> ok
<tfheen> xubuntu alternate up
<fabbione> but it's required for the redhat-cluster-suite support for xen fencing
<ajmitch> interesting
<ajmitch> just rebuilding it without the xen-utils b-d 
<fabbione> the cluster suite has always been able to run inside xen.. but it was lacking a method to "reboot" a xen virtual machine
<fabbione> and this xen support is pulling in a lot of crap
<fabbione> i guess i am going to split xen support in another package
<ajmitch> some of their other xen stuff is a bit too RH specific
<fabbione> ajmitch: please fix the errors i /msg to you
<ajmitch> great, rpath warnings
<mdz> pitti: what happened with langpacks?
<mdz> pitti: the current desktop CD is only 661M
<pitti> mdz: I updated the seeds this morning and new images are currently building
<mdz> pitti: oh, I saw a new build for 20061024 and assumed it was that. what was the earlier build for then?
<mdz> oh, it just now went up
<pitti> hm, strange
<pitti> the alternate CDs are filled up nicely now
<mdz> so we are talking about the same build
<pitti> but http://cdimage.ubuntu.com/daily-live/20061024/ is still to small
<pitti> tfheen: do the live scripts pick up changes directly from the launchpad seed branch?
<cjwatson> they should now, but there's still a small delay
<cjwatson> 20 minutes should cover it
<cjwatson> sorry, I'm being unclear, they actually get it from http://people.ubuntu.com/~cjwatson/seeds/
<tfheen> the desktop CDs just finished
<cjwatson> since they aren't in ubuntu-core-dev they can't fetch from sftp directly, and the delay on http://bazaar.launchpad.net is roughly the same as that on my seed mirror
<tfheen> but those images look too small, agreed.
<pitti> tfheen: ah, so the desktop images you just built are *not 1024?
<cjwatson> check the livefs build log ...
<tfheen> pitti: "not 1024"?
<cjwatson> tfheen: I just uploaded a new gfxboot-theme-ubuntu that fixes a crasher when you select any keymap that doesn't have an associated locale (there are 20 such keymaps)
<pitti> tfheen: timestamp 20061024
<cjwatson> not saying we have to use it, but if we're going to rebuild anyway I think we should
<tfheen> cjwatson: arg. :-/
<tfheen> cjwatson: what needs to be rebuilt for that to take effect?  just the live images?
<tfheen> pitti: which langpacks did you add?
<tfheen> (for ubuntu live)
<cjwatson> tfheen: all images, no livefses
<tfheen> cjwatson: ok.  I think I'm fine with that.
<tfheen> sfllaw: are you coordinating testing and such?  I haven't seen any mails from you on the subject?
<cjwatson> I can live with it being only on desktop images if you've already got final alternates
<pitti> tfheen: xh pt ru ja de fr aa af am an as ast az be ber bg bo br bs bua ca ceb co cs csb cy da dv dz el eo et eu fa fi fil fo fur fy ga gd gl grc gu he hr hu hy ia id for all arches
<pitti> tfheen: and a couple more for i386
<cjwatson> wow, that's a lot
<pitti> well, we had a lot of space to burn :)
<tfheen> cjwatson: we're almost down to 650MB CDs..
<tfheen> (without langpacks)
<cjwatson> tfheen: http://people.ubuntu.com/~cjwatson/tmp/gfxboot-theme-ubuntu.diff FWIW
<mdz> pitti: which do we have language-support for?
<pitti> mdz: just -en, as usual
<sfllaw> tfheen: I did send out an announcement of the new RC.
<tfheen> sfllaw: where to?
<mdz> pitti: but we have input methods for some of them?
<mdz> pitti: which do we have input support for, I should say?  rather than oo.o translations
<sfllaw> tfheen: Mmm, standard testing addresses.
<pitti> mdz: yes, the general scim stuff is in -desktop
<sfllaw> Not to warthogs though.
<pitti> mdz: we do not have the particular Chinese/Taiwanese scim maps
<tfheen> sfllaw: last email I have from you is from Thursday at least.
<tfheen> (in my inbox)
<mdz> pitti: we've said that we should not ship translations without input method support
<sfllaw> tfheen: Well, it's been a day, so I will send out e-mails to remind people to do another pass at Testing/Current.
<janimo> tfheen, Kamion: since you do rebuild anyway culd you consider the new casper too?
<pitti> mdz: hm, we have always shipped Chinese, I just added some less common languages today
<tfheen> janimo: that'd require a livefs rebuild, so no.
<tfheen> kubuntu desktop cds up.
<pitti> so we should revisit the scim stuff soon for feisty
<mdz> pitti: I know, and sabdfl specifically said not to do it without the input packages
<tfheen> those seems good, space-wise.
<fabbione> sfllaw: want to update testing/current with the new iso info?
<cjwatson> we're going to have to rebuild livefses to take zh *out* - it's not clear that that is worth it ATM
<cjwatson> we're going to have to => we'd have to
<mdz> cjwatson: I wasn't suggesting it, but now that you mention it, we're rebuilding anyway
<sfllaw> tfheen: Did you spin another set of CDs?
<cjwatson> mdz: not livefses yet
<mdz> edgy-desktop-i386 is 661M
<tfheen> sfllaw: yes, with more langpacks.
<sfllaw> tfheen: OK.  Rsyncing again.
<sfllaw> tfheen: Is this 20061024?
<sfllaw> And which ones?
<tfheen> sfllaw: sounds right.  All.
<tfheen> sfllaw: those aren't final-final, we want Colin's fix for gfxboot-theme-ubuntu too, but I'd like people to start testing now.
<cjwatson> mdz: hmm, yes, I thought the livefses had been rebuilt to actually pick up pitti's language pack changes but apparently not yet
<tfheen> mdz: that'll be fixed as soon as the edubuntu livefs build finishes and I start an ubuntu one.
<sfllaw> tfheen: Please send me a note over IRC when you spin new ones?
<sfllaw> Thanks.
<tfheen> sfllaw: I can tell you explicitly, sure.
<cjwatson> hmm, drat, missed the publisher with gfxboot-theme-ubuntu
<cjwatson> I'll put it onto cron.infinity^Wcjwatson once this run finishes
<pitti> mdz: ok, all scim tables together are about 10 MB
<mdz> pitti: we can't make a change like that now
<pitti> the problem is, we have little to no feedback about the scim stuff ATM
<mdz> we'll leave it alone
<cjwatson> tfheen: please hold off buildlive until the seeds are finalised and I push a seed update
<mdz> just please don't let this happen again for feisty
<pitti> mdz: alright, I'll keep it in mind. We desperately need more testing in that area
<pitti> or testing at all
<tfheen> pitti: file a bug, milestone it later and we'll revisit it.
<pitti> yes
<tfheen> cjwatson: uh, seed update for what?
<mdz> pitti: we do get some testing, there's even a team in launchpad
<cjwatson> tfheen: as in until I run update-seeds on rookery to make sure it's *really* up to date this time
<mdz> it's generally after release though
<mdz> mvo: what happened to bug 57081?
<Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing: user database file can be corrupted, which render the whole package useless" [High,Confirmed]  http://launchpad.net/bugs/57081
<cjwatson> since it doesn't seem to have been for the last livefs build
<tfheen> cjwatson: oh, sure.  I just noticed that the kubuntu live ones I built were ~700 MB as they should.
<tfheen> cjwatson: that was just the ubuntu seed, I think.  But, please go ahead.
<cjwatson> the cron job probably kicked in before you built kubuntu
<dexem> carlos, ping?
<tfheen> I guess so, yes.
<carlos> dexem: pong
<dexem> carlos, do you have 5 minutes to talk? :P
<cjwatson> tfheen: right, seeds are definitely up to date now
<carlos> sure
<tfheen> cjwatson: good.
<sfllaw> Testing/Current updated.
<sfllaw> Everyone's off to the races again.
* dholbach grabs the wiki lock
<mdz> tfheen: server from yesterday is still current, right?
<ogra> pitti, feel free to do what you want :)
<pitti> ogra: ok, so I add both kde and gnome langpacks and fill alternate and desktop to 698 MB?
<ogra> pitti, 686M is the biggest install iso i have and 648M the biggest live one ...
<sivang> re
<ogra> pitti, yep
<pitti> E/Desktop:      50      85      66
<pitti> E/Alternate:    12      40      29
<pitti> ^ free MBs for i386/amd64/powerpc 
<ogra> yup
<cjwatson> mdz: lrwxrwxrwx  1 tfheen cdimage 8 Oct 23 19:26 cdimage/www/full/ubuntu-server/daily/current -> 20061023
<dholbach> then i could have just kept on using 20061023
<dholbach> grmbl
<mdz> cjwatson: current as in "will not be rebuilt", not "has not been rebuilt" :-)
<fabbione> sfllaw: netboot line on the wiki is borked.. missing | somewhere
<sfllaw> fabbione: Overzealous deleting on my part.
<fabbione> sfllaw: i just need to make sure what i need to test
<sfllaw> I have to admit that Wiki syntax is not very good for tables.
<sfllaw> fabbione: Thanks!
<fabbione> sfllaw: broken again..
<fabbione> there is a preview button.. you know :)
* cjwatson reassigns scads of bugs to the kernel
<cjwatson> I wish squashfs weren't quite such an oops-o-rama
<fabbione> sfllaw: server image is still 23. it won't be regenerated with extra langpacks
<tfheen> mdz: -server is still current, yes.
<sfllaw> Ah.
<sfllaw> tfheen: That's not "All".
<sfllaw> fabbione: Fixed.
<sfllaw> tfheen: Reverted Server CD testing.
<tfheen> sfllaw: ubuntu-server keeps slipping my mind since it's published as ubuntu, not -server
<sfllaw> Ah.
<sfllaw> I'll ask next time.
<tfheen> pitti: hmm, so edubuntu still needs a livefs rebuild?
<pitti> tfheen: I'm changing the seeds ATM
<tfheen> pitti: oh well, ok.
* tfheen goes to rebuild ubuntu livefs-es
<tfheen> cjwatson: anything against that?
<mvo> mdz: the user-database corruption problem is fixed with the new version of scim-chewing/libchewing. as for the rest (discussion about the pro/cons of {GTK,QT}_IM_MODULES) I didn't want to switch that 3 weeks before the release. my gut feeling is that we should switch to scim-bridge for edgy+1, but I would like to discuss this with some people who use scim on a daily basis
<pitti> tfheen: committed; will do edubuntu/alternate seed changes now
<mvo> mdz: oh, this was of course about #57081
<tfheen> pitti: thanks.
<cjwatson> tfheen: nope
<mdz> mvo: the best place for that information is in the bug report; as it is, the last comment is me asking you to look into it and then nothing further
<tfheen> ubuntu livefs-es building
<tfheen> cjwatson: tell me when the gfxboot fix is in the archive and I'll spin alternates and desktops then.
<mvo> mdz: right, sorry for not following up there :/ I will do this now 
<mdz> tfheen: if so, there's no point in testing the current build
<pitti> tfheen, ogra: edubuntu/alternate seed changes committed as well now
<tfheen> mdz: it's better to have people test it for other regressions than having them sitting twiddling thumbs.
<cjwatson> tfheen: I'm publishing the source now
<ogra> pitti, thanks :)
<tfheen> cjwatson: thanks.
<seb128> tfheen: I don't think people just "twiddling thumbs" when they are not testing CDs :)
<ubuntu_demon> hi
<mdz> tfheen: seb128 has a point; we are borrowing developers as testers :-)
<tfheen> mdz: do you have a hidden armada of testers you haven't told me about so we can stop borrowing developers? :-)
<tfheen> kubuntu desktop ready for testing
<tfheen> sfllaw: ^^
<mneptok>  /m tfheen please don't discuss Matt's multiple personality disorder on public channels
<mneptok> oops.
* tfheen ruffles mneptok
* mneptok purrs contentedly
<sivang> mneptok: heh
<tfheen> mdz: but well, you have a point.
<tfheen> better to not wear people out.
<mdz> tfheen: no, but that means we should spend their time as usefully as possible
* pitti currently only plays around with some new stuff for feisty, so give me a call when you need something release-ish done
<sfllaw> mdz: Should we wait until the gfxboot fix comes out?
<mdz> sfllaw: yes
* seb128 tries to catchup with the 400 desktop bugs waiting for a reply
<sfllaw> OK.
* sfllaw twiddles thumbs.  ;)
<sfllaw> Man, that's actually difficult.
<seb128> sfllaw: desktop bugs are waiting for some hand 
<mdz> sfllaw: how about updating the wiki page to show which images are real candidates in need of testing
<sfllaw> I'm just kidding guys.
<sfllaw> tfheen: I'm confused by what I'm blocked on.  I think I can let people test the server CD and EdgyUpgrades.
<sfllaw> Does gfxboot affect Kubuntu and Edubuntu as well?
<fabbione> sfllaw: gfxboot yes but only i386/amd64
<fabbione> sfllaw: but server CD boots with gfxboot too iirc
<cjwatson> correct
<cjwatson> but we don't necessarily *have* to rebuild it
<fabbione> well nobody did test them yet.. might as well doit
<cjwatson> though dunno, the server CD might have more people with weird keymaps? hard to tell
<cjwatson> (dvorak is one of the affected keymaps)
<mdz> I use dvorak but didn't know until today that it could be selected in gfxboot
<cjwatson> publisher is messing around with death row at the moment
<cjwatson> mdz: I did it just for you
* fabbione would like to know if he should continue with server cd testing or not
<fabbione> mdz: you are sitting close to cjwatson .. can you please tickle an answer out of him? :P
<mdz> fabbione: wait for the final build
<fabbione> ok
<mdz> tfheen: I recommend not delaying further for anything but showstoppers to leave enough time for a full test cycle
<sfllaw> tfheen: Please let me know when certain classes of images come out.
<sfllaw> I'll enable them on Testing/Current.
<iwj> root@samual8:/media/hda4/ian# rsync cdimage.ubuntu.com::
<iwj> rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<tfheen> sfllaw: server cd is testable, upgrades are testable.
<sfllaw> tfheen: Merci.
<cjwatson> hmm, yes, rsync from cdimage is unhappy here too
<cjwatson> Spads: ^-- ?
* Spads checks
<Spads> okay, I see a lot of rsync clients at the moment
<tfheen> fabbione: unless you complain loudly, I won't redo the server CDs for the gfxboot problem.
<fabbione> tfheen: well i would prefer to have stuff in sync.. let headacke if we get bug reports
<fabbione> s/let/les
<fabbione> EKKKEKEKE
<fabbione> less
<Spads> iwj: which IP are you rsyncing from?
<tfheen> fabbione: that invalidates all your testing, though.
<iwj> 193.201.200.170
<fabbione> tfheen: the server CD are all old except mvo and mine
<fabbione> 2 tests against 12
<cjwatson> Spads: I was rsyncing from my laptop here
<fabbione> oh actually
<fabbione> 4
<fabbione> there is also dholbach 
<cjwatson> i.e. 10.90.90.75 but I don't suppose that matters ;-)
<tfheen> cjwatson: publisher done?
<cjwatson> tfheen: yeah, but buildds don't seem to be picking up g-t-u; I've pinged malcc
<tfheen> cjwatson: thanks.
<fabbione> tfheen: well up to you.. as i said i would prefer to have them in sync
<tfheen> fabbione: ok, let's wait for g-t-u to crawl through the buildds + publisher, then.
<fabbione> tfheen: ok perfect
<Spads> what happens if you specify the cdimage target explicitly?
<cjwatson> ah yes, ::cdimage/ works
<cjwatson> iwj: ^--
<iwj> Oh, it's started working.
<dholbach> fabbione: what about me?
<fabbione> dholbach: -server images testing.. we are going to roll out new images for g-t-u fixes
<dholbach> fabbione: alright
<iwj> Urr, except that there is no 20061024 dvd.
<tfheen> cjwatson: seems to have succfully built now?
<tfheen> https://launchpad.net/distros/ubuntu/+source/gfxboot-theme-ubuntu/0.2.10
<cjwatson> ah yes, thanks
<tfheen> iwj: not yet.  There will be one soonish.
<tfheen> iwj: just rsync the one in current for now.
<iwj> I got that one yesterday (overnight, in fact ...)
<iwj> So I'll go and buy a working dvd writer now.
<tfheen> ah, ok
<cjwatson> publisher running
<mdz> gfxboot doesn't affect powerpc or sparc, right?
<cjwatson> correct
<fabbione> mdz: right
<iwj> Unless I should wait a minute or two to start my rsync ...
<mdz> sfllaw: so those two arches should be clear to test
<cjwatson> iwj: publisher will take at least 20 minutes
<cjwatson> then there's CD image build time, and DVDs won't be first in the queue there
<tfheen> I'll do desktop CDs first, since those are the quickest.
<iwj> cjwatson: Ah, OK.
* iwj departs.  Back in 30-40m depending on the headwind.
<thom> whiprush: i want to talk to you about ubuntu-update-server when you're around
<dholbach> tfheen: http://daniel.holba.ch/temp/syslog http://daniel.holba.ch/temp/dmesg http://daniel.holba.ch/temp/debug
<tfheen> syslog is 403
<dholbach> just a sec
<dholbach> should work now
<tfheen> cjwatson: ^^ can you take a look at that?  It looks.. worrisome.
<ogra> xfs ?
<mdz> dholbach: reproducible?
<tkamppeter> doko, tfheen, are you there?
<mdz> dholbach: and does it pass an integrity test?
<dholbach> mdz: yes to both questions
<mdz> dholbach: which iso?
<fabbione> hmmmmm
<dholbach> mdz: ubuntu i386 dvd 20061023
<cjwatson> dholbach: it's one of the billion "kernel oopses on bad CD" bugs
<mdz> hmm, the previous DVD worked fine for me
<mdz> haven't tested that one
<mdz> will give it a try in vmware now
<cjwatson> you have a bad disk or a dirty drive lens or something along those lines
<dholbach> cjwatson: i doubt it's a bad cd
<cjwatson> did you integrity-check it?
<dholbach> cjwatson: i downloaded a new iso, burned it on a new cd, bought a new cd drive and integrity-checked it
<dholbach> bug 66769 bug 66779 bug 67784  are similar bugs
<Ubugtu> Malone bug 66769 in ubiquity "Ubuntu 6.10 Desktop for i386 installation crashes on squashfs_read_data (Oops: 0000 [#1] )" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66769
<Ubugtu> Malone bug 66779 in ubiquity "Ubuntu 6.10 Desktop for i386 installation crashes on zlib_inflate_codes" [Undecided,Rejected]  http://launchpad.net/bugs/66779
<Ubugtu> Malone bug 67784 in linux-source-2.6.17 "Edgy RC1 is crashing in the installation at 47%" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67784
<cjwatson> yes, and they're all kernel bugs
<cjwatson> I just haven't reassigned them yet
<cjwatson> 0xfffffffb is Z_BUF_ERROR
<tfheen> cjwatson: I wonder if we might be running into some kernel weirdness because we mount the squashfs twice or something
<cjwatson> so I'm prepared to believe it's a kernel bug caused by something other than a bad CD, such as a borderline CD and not dealing with re-reading on errors correctly or something
<tfheen> it'd still be a kernel bug.
<cjwatson> but I doubt it's anything VFS-level
<tfheen> publisher done?
<cjwatson> and it's *not* an installer bug
<cjwatson> oh, yes, it is
<tfheen> ubuntu desktop build running
<tfheen> argh
<tfheen> I forgot to exclude powerpc from the build. :-(
<dholbach> cjwatson: I was not trying to apportion blame. Sorry, if it sounded that way.
<cjwatson> tfheen: you can ctrl-c
<tfheen> cjwatson: done, re-running
<cjwatson> dholbach: I know, I just have a billion of those bugs and there's absolutely nothing I can do
<cjwatson> and most of them I remain convinced that it's a hardware problem
<cjwatson> tfheen: (ideally you tweak etc/.next-build-* after ctrl-c'ing so that it reuses the build number ...
<tfheen> dholbach: what would be very interesting is if you can reproduce that problem in vmware.
<cjwatson> )
<tfheen> cjwatson: I didn't.  Oh well
<tkamppeter> tfheen, ping
<cjwatson> I would love the kernel to react less violently to that particular problem
<fabbione> crimsun: ping?
* iwj returns
<tfheen> tkamppeter: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<cjwatson> returning EINTR and letting userspace retry would be good
<cjwatson> or just retrying in squashfs
<cjwatson> I don't know if retrying will help, though; it could be that zlib_inflate doesn't cope with short reads in particular places
<dholbach> tfheen, cjwatson, mdz: anything else you'd like me to investigate apart from running it in vmware (which I'd need to set up)?
<tfheen> dholbach: not that I can think of offhand, no.
<dholbach> ok
<tfheen> ubuntu desktop CDs up.
<tfheen> sfllaw: ^^
<dholbach> cjwatson: I think it happened to mvo too with his new t60
<tfheen> kubuntu desktop CDs spinning.
<tfheen> dholbach: is this an SMP or UP system?
<dholbach> up
<cjwatson> tfheen: should I leave the publisher on manual?
<tfheen> cjwatson: yes, I think so.
<tkamppeter> tfheen, what is the state about foo2zjs?
<tfheen> tkamppeter: did you ever ask anybody to upload it?
<tfheen> kubuntu desktop cds up.
<tfheen> sfllaw: ^^
<tkamppeter> Yes, I have sent several e-mails to you and doko_.
<tfheen> cjwatson: edubuntu seed mirror is current, right?
<ogra> pitti just updated it for th elangpacks afaik ...
<tkamppeter> tfheen, doko_, bug 65618
<Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Medium,Fix committed]  http://launchpad.net/bugs/65618
<tfheen> tkamppeter: no, you didn't.  Matt sent an email on Sunday evening saying "this can be approved if it hits the archive before monday morning".  You sent an email on Monday evening asking about progress, which is far too late.
<tfheen> tkamppeter: the gates for edgy have been closed, so please follow the procedure for uploading to -proposed.
<mdz> tkamppeter: (http://wiki.ubuntu.com/StableReleaseUpdates)
<sladen> shawarma: make your case to Kamion/theen---if you get the nod, I'll upload it
<tfheen> Ubuntu Alternate CDs spinning.
<tfheen> sladen: edgy main upload?  No, too late.
<cjwatson> tfheen: dunno if it was, but it is now
<sladen> shawarma: ^^note
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs |  Edgy is so frozen, you would not believe
<tfheen> cjwatson: thanks.  Can you verify that pitti's langpack fixes is there?
<tfheen> (sorry about pestering)
<tfheen> pitti: did you update the xubuntu seeds too?
<cjwatson> tfheen: timestamp: Tue 2006-10-24 11:39:18 +0200
<cjwatson> ^-- most recent change
<ogra> tfheen, looking at my current checkout it looks fine
<cjwatson> dholbach: gnade upload from doko in unapproved, new upstream version?
<tfheen> ogra: good, thanks
<tfheen> edubuntu livefs-es building
<dholbach> cjwatson: that's ok
<tkamppeter> tfheen, soory, I am in Lexington, I will propose it to be an official update on the site which mdz mentioned during or after the Ubuntu Summit in Mountain View. Perhaps I ask the author to fix it upstream and then I take his new upstream version.
<kervel> hello, is there anything one can do about bugs with a known fix already on launchpad (eg sync with debian) ... noteedit in edgy is unusable now, and the bugfix is on launchpad ..
<cjwatson> dholbach: ok, thanks
<tkamppeter> So don't worry, I will update the bug report telling that it will com e as update after the Mountain view week and in Edgy+1
<cjwatson> kervel: uh, I synced noteedit a while back?
<kervel> ah, i just saw it ... sorry
<ajmitch> kervel: I see only 1 open bug against noteedit
<kervel> cjwatson i put it on hold .. sorry for the fals report 
<tfheen> tkamppeter: ok, thanks.
<tfheen> kubuntu alternate up.
<tfheen> sfllaw: ^^
<Riddell> woo
<highvoltage> :)
<tfheen> Riddell: uh, sorry.
<tfheen> I'm not sure how I managed to not see that my prompt wasn't there, but it's not done yet.
<tfheen> sfllaw: ^^
* Riddell waits in anticipation
* tfheen thinks simon is going to have a lot of ^^-s in his lastlog. :-)
<tfheen> Riddell: ppc is the final one already, though.
<tkamppeter> tfheen, mdz, bug 65618 updated.
<Ubugtu> Malone bug 65618 in foo2zjs "Package broken/incomplete, missing firmware files" [Medium,In progress]  http://launchpad.net/bugs/65618
<cjwatson> kervel: so nothing for us to do?
<Riddell> tfheen, cjwatson: current kubuntu alternate amd64 is 701M, was there an issue about >700MB causing problems even if it's below the standard CD limit?
<tfheen> Riddell: it should be ok with those images, I think.
<cjwatson> yeah, it's best to keep it < 700 * 1024 * 1024 if you can
<cjwatson> it's .5MB over
* Keybuk still hasn't quite trained his fingers for the "2.8" in the path to killev
<Keybuk> that should so be in /usr/bin
<tfheen> Keybuk: killev?
<Riddell> cjwatson: what about that powerpc image?
<Keybuk> tfheen: kill evolution's little bonobo hinderances
<tfheen> Keybuk: pkill evolution doesn't do that for you?
<Keybuk> tfheen: no, that just kills the main binary
<Keybuk> not e-d-s, e-a-n, e-i-e-i-o, et. al.
<tfheen> Keybuk: you know the difference between pkill and killall?
<Keybuk> tfheen: ?
<tfheen> : tfheen@thosu ~ > pgrep -l evolution
<tfheen> 5303 evolution-alarm
<tfheen> 5336 evolution-data-
<tfheen> 5355 evolution-excha
<tfheen> pkill would have killed those
<tfheen> it does substring matching.
<Keybuk> tfheen: doesn't make them disconnect from the panel, etc.
<Keybuk> which usually causes the clock to crash
<tfheen> oh, maybe not
<Keybuk> taking the panel with it
<Keybuk> I'd file bugs, but seb would just ignore them at me :p
<mdz> dholbach: DVD installs fine in vmware
<dholbach> mdz: I try a dvd text install now
<ogra> Keybuk, evolition --force-shutdown is the current right way, killev is dead
<ogra> (since ages)
<Keybuk> what's the difference?
<ogra> dunno
<tfheen> Riddell: kubuntu is done now.
<tfheen> sfllaw: ^^
<ogra> but seb told me once i should use it this way
<ogra> i dont think evo even ships killev anymore
<Keybuk> it must do, I just ran it
* dholbach doesn't have killev
<Keybuk> dholbach: do you have evolution installed? :)
<dholbach> pfffft, of course
<dholbach> but not the    keybuks-small-helpers    package ;)
<mdz> we still have oaf-slay though
<cjwatson> Riddell: what powerpc image?
<dholbach> bonobo-slay? :)
<Keybuk> syndicate scott% dpkg -S /usr/lib/evolution/2.8/killev
<Keybuk> evolution: /usr/lib/evolution/2.8/killev
<Keybuk> dholbach: ?
<mdz> sfllaw: wiki needs updating for the current builds
<mdz> sfllaw: we're at 24.1/2
<dholbach> Keybuk: ok, looked in the wrong place
<Keybuk> dholbach: where did you look?
<dholbach> in /usr/bin
<Riddell> cjwatson: http://cdimage.ubuntu.com/kubuntu/daily/20061024.1/ 700M  is that too big?
<fabbione> hmmmm
<fabbione> cjwatson: did something change in the seeds that might pull in oowriter on netboot/netinstall for LAMP server??
<cjwatson> Riddell: no
<cjwatson> cjwatson@lithium:~/cdimage/www/full/kubuntu/daily/current$ echo $((700*1024*1024))
<cjwatson> 734003200
<cjwatson> cjwatson@lithium:~/cdimage/www/full/kubuntu/daily/current$ ls -l edgy-alternate-powerpc.iso
<ogra> Riddell, 734003200 is the limit :)
<cjwatson> -rw-rw-r--  2 tfheen cdimage 733802496 Oct 24 09:12 edgy-alternate-powerpc.iso
<mdz> Riddell: there will be an .OVERSIZED file if so
<tfheen> edubuntu alternate images done.
<cjwatson> fabbione: http://people.ubuntu.com/~cjwatson/germinate-output/edgy/rdepends/ALL/openoffice.org-writer is --> that way
<tfheen> sfllaw: ^^
<ogra> grmbl
<Riddell> mdz: that's not the case for the amd64 CD there
<ogra> pitti... you miscounted ...
<cjwatson> .OVERSIZED doesn't trigger on 700*1024*1024 at present
<cjwatson> it probably ought to, in theory
<fabbione> cjwatson: ok.... it's the usual langpack's stuff
<tfheen> xubuntu alternate spinning.
<fabbione> pitti: we need to review these langpack situations... we can't pull in oowriter on server /netinstall stuff
<cjwatson> hmm, there's an argument that it's a d-i bug
<cjwatson> shouldn't be installing language-support-* on servers
<cjwatson> I might be able to fix that in preseeds, not sure
<cjwatson> which would be quick
<cjwatson> what the ... it's *supposed* to be preseeded already
<fabbione> cjwatson: this sparc.. i am not sure we preseeding anything from the a.out image
<cjwatson> fabbione: you're not using silo?
<cjwatson> we do configure silo.conf to use the standard preseeds
<fabbione> cjwatson: on netboot? no.. you boot directly the image
<fabbione> yes that's from CD..
<cjwatson> fabbione: I blame your dodgy architecture then :)
<fabbione> cjwatson: i blame langpacks :)
<fabbione> cjwatson: why do we need to blame eachother when we can blame pitti?
<Riddell> tfheen: I've altered the kubuntu ship seed, could you rebuild amd64 alternate CD?
<fabbione> cjwatson: there is tilo.. perhaps we can use that one.. -> feisty anyway
<tfheen> Riddell: yes, in a little bit.
<Riddell> thanks
<cjwatson> fabbione: no, your installation will be wrong in other ways too. just document that you should boot with preseed/url=http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/data/edgy/preseed/ubuntu-server/ubuntu-server.seed
<cjwatson> ("just")
<tfheen> xubuntu alternate done
<tfheen> sfllaw: ^^
<cjwatson> or "pkgsel/language-pack-patterns= pkgsel/install-language-support=false", which I guess is actually shorter in this case
<fabbione> cjwatson: eeeekkkk
<mdz> sfllaw: ping
<fabbione> cjwatson: ok.. testing that one
<Treenaks> http://news.bbc.co.uk/2/hi/technology/6080048.stm
<sfllaw> mdz: Pong.
<tfheen> Riddell: kubuntu amd64 rebuilt
<tfheen> sfllaw: ^^
<mdz> sfllaw: <mdz> sfllaw: wiki needs updating for the current builds
<mdz>  sfllaw: we're at 24.1/2
<mdz> tfheen can give you a complete list of what's ready
<tfheen> ubuntu, kubuntu daily-live ready
<tfheen> ubuntu, kubuntu, xubuntu, edubuntu daily ready.
<pitti> arrgh, oversized
<tfheen> still not there: edubuntu live and ubuntu-server
<tfheen> pitti: which?
<pitti> apparently squashfs compression is much worse than .deb compression
<pitti> tfheen: daily-live/20061024.2/ (Ubuntu)
<tfheen> pitti: *sigh*, ok.  Can you strip the live seed a bit, then?
<pitti> I'll do, but I can only guesstimate
<cjwatson> cjwatson@lithium:~/cdimage/www/full$ find -path \*/current/\*.OVERSIZED
<cjwatson> cjwatson@lithium:~/cdimage/www/full$
<pitti> I'll be generous
<cjwatson> hmm, no, that's obviously wrong
<pitti> and for some reason the powerpc CD didn't grow at all
<pitti> ogra: see above, hard to guesstimate squashfs compression
<cjwatson> ah, better
<cjwatson> 1~./daily-live/current/edgy-desktop-amd64.OVERSIZED
<cjwatson> ./daily-live/current/edgy-desktop-i386.OVERSIZED
<cjwatson> ./edubuntu/daily-live/current/edgy-live-amd64.OVERSIZED
<cjwatson> ./edubuntu/daily-live/current/edgy-live-i386.OVERSIZED
<cjwatson> ./edubuntu/daily/current/edgy-install-i386.OVERSIZED
<pitti> fabbione: why do you want to pull in oowriter on server?
<ogra> pitti, i'm talking about install, not live
<cjwatson> pitti: it's d-i installing language-support-en
<tfheen> pitti: oh, I just rebuilt amd64 and i386 because they should have been enough, except that we wanted the new livefs there too.
<fabbione> pitti: it's the other way around.. i do NOT want it
<dholbach> pitti: because vim and emacs suck - oowriter is the one-true-editor
<fabbione> pitti: but langpacks pull it in
<tfheen> sfllaw: ok, ubuntu desktop not ready after all.
<pitti> fabbione: I see, but what's pulling it in?
<pitti> fabbione: no, language-pack-* does not pull in any oo.o stuff
<fabbione> langpack-something...
<cjwatson> pitti: language-support-en does
<pitti> fabbione: only language-support-* does
<pitti> right, but I didn't touch that
* cjwatson wonders if he is invisible
<fabbione> ywah
<cjwatson> pitti: it's not your fault
<fabbione> cjwatson: yes it is :P
<pitti> cjwatson: ah, ok; sorry, still catching up with reading backlog
<cjwatson> in feisty, remind me to make pkgsel not install language-support-en if the desktop isn't installed or queued for installation
<fabbione> pitti: well in one way or another we get there.. i am testing Colin's fix
<tfheen> cjwatson: file a bug, mark it later.
<pitti> tfheen: it seems that the ubuntu/powerpc/desktop image did not pick up the seed changes?
<cjwatson> tfheen: will do
<tfheen> pitti: no, it's a different bug.  I just didn't rebuild the image.
<tfheen> (because I'm a moron)
<pitti> ah, ok; I'll chop off 12 MB as well
* dholbach hugs tfheen
<tfheen> dholbach: thanks dude
<ogra> ok, the edubuntu install iso should be fine again 
<pitti> ogra: thanks, I was just about to fix it
<pitti> tfheen: ubuntu live stripped down
<ogra> pitti, i dropped zh and pt
<ogra> what did you drop from ubuntu live ? 
<tfheen> cjwatson: seed mirror update, please?
<pitti> ogra: about a dozen langpacks
<ogra> which ones :)
<tfheen> ogra: does that mean you need a rebuild?  If so, of what?
<pitti> ogra: (et eu fa fi fil fo fur fy ga gd gl grc gu he hr hu hy ia id)
<ogra> pitti, thzanks
<pitti> ogra: oh, no, sorry, those were just moved; I dropped is it jbo jv ka kab kk km kn ko ku ky la lb lg li lo lt lv mg mi mk
<ogra> tfheen, install i386  ...
<ogra> tfheen, working on a live seed fix ...
<pitti> ogra: shall I fix your lives, too?
<pitti> ogra: sorry for the trouble, btw!
<ogra> pitti, that'd be nice so we have similar langpack sets
<cjwatson> tfheen: done
<ogra> pitti, i expected it, we never had a release where it fitted on the first attempt ;)
<tfheen> anything else we need to hold on for livefs-es?
<Riddell> tfheen: kubuntu alternate amd64 hasn't changed size, is there something that needs to happen before it picks up the language pack list from the seeds?
* pitti blinks
<tfheen> Riddell: yes, Colin needs to update the seed mirror.  Done now.
<tfheen> Riddell: spinning new amd64 update now
<tfheen> ubuntu livefs-es building.
<pitti> tfheen, ogra: edubuntu/live seed downsized; this *should* make all isos fit again
<tfheen> Riddell: amd64 isos done
<tfheen> sfllaw: ^^
<tfheen> sfllaw: that gives us a .3 for all isos, but the images are the same as for .2 and .1
<tfheen> ogra: do you want new i386 and powerpc ISOs?
<tfheen> cjwatson: edubuntu seed mirror up to date?
<ogra> tfheen, since amd64 is oversized as well, i think i need a full set of live 
<ogra> for install i386 would suffice ...
<tfheen> ogra: you want a new powerpc one too, since I forgot to rebuild that.
<cjwatson> tfheen: yes
<ogra> oki
<tfheen> ARCHES="powerpc i386" for-project edubuntu cron.daily spinning
<sfllaw> tfheen: Oy!
<sfllaw> So confusing.
<tfheen> sfllaw: what's confusing?  The copying of ISOs?
<sfllaw> No, the point releases of images.
<ogra> the numbering ?
<tfheen> sfllaw: how would you rather number them?
<ogra> why dont you point to /current and just veryify they point to the right iso each update ?
<sfllaw> tfheen: Oh, I don't think there's a better way.
<sfllaw> The iterations are just difficult to track.
<cjwatson> ogra: because then people aren't explicitly conscious of what they've tested
<ogra> hmm, right
<sfllaw> OK, I've been up for too long.  I must have a nap.  Will be back in a couple of hours.
<tfheen> ogra: ppc and i386 still oversized.
<ogra> meh
<tfheen> curiously, apache and ls disagree about how big a megabyte is.  Or rounding rules.
<ogra> tfheen, hmm, looks like there was no change at all in these isos ? 
<Keybuk> tfheen: so do your disk and ls, probably
<ogra> didnt it pick up the seed change ?
<tfheen> Keybuk: not by 1MB out of ~700.
<tfheen> ogra: apparently not.
<tfheen> cjwatson: any idea about that?
<ogra> we're at rev 542 fwiw
<ogra> probably just a race condition
<tfheen> Colin's mirror is at 540
<ogra> ah
<cjwatson> cjwatson@rookery:~/public_html/seeds/edubuntu-edgy$ bzr revno
<cjwatson> 542
<tfheen> that changed in the last two minutes
<cjwatson> may've just updated; the cron job was a minute ago
<ogra> seems we were to fast on the trigger
<tfheen> oh well
<tfheen> ARCHES="powerpc i386" for-project edubuntu cron.daily
<tfheen> running
<tfheen> again
<ogra> thanks :)
<cjwatson> oh, gar, my mirror is from http://bazaar.launchpad.net
<cjwatson> so the delay is that much greater
<cjwatson> will look at that early feisty
<tfheen> cjwatson: thanks.  We should be good now, though
<cjwatson> mjg59: please can we have fewer things that need changing for new usplash command-line calling conventions? (uswsusp hook in initramfs-tools)
<cjwatson> tfheen: yep
<tfheen> cjwatson: can you file a later bug about it?
<cjwatson> tfheen: done
<tfheen> ogra: alternate build done.
<tfheen> sfllaw: ^^
<mjg59> cjwatson: I'm not quite clear on what you mean
<ogra> tfheen, now that looks nice :), thanks a lot !
* ogra fires up rsync ...
* tfheen ruffles lithium:~tfheen/bin/livestatus
<fabbione> cjwatson: that cmdline works..
<fabbione> cjwatson:  i also filed a bug on pkgsel
<tfheen> so, once this livefs build is done, I'll rebuild all of the ubuntu desktop cds and then the edubuntu ones.
<tfheen> nothing else needed, right?
<cjwatson> mjg59: the hook in initramfs-tools that calls /sbin/resume is the third thing that needs to be updated for the amd64 reversion
<cjwatson> fabbione: I'd already done that
<cjwatson> I'll dup
<fabbione> oh ok
<Riddell> tfheen: hmm, no change in size for amd64 alternate kubuntu
<tfheen> Riddell: probably got bit by the same bug as the others, then.  Retrying..
<fabbione> cjwatson: should we add something to the ReleaseNotes perhaps?
<cjwatson> it's not a new problem
<fabbione> yeah i know, but it got worst in edgy :)
<fabbione> at least on sparc.. but hey
<tfheen> ogra: building edubuntu livefs-es now.
<ogra> thanks 
<tfheen> Riddell: done
<Riddell> tfheen: perfect, thanks
<Keybuk> ogra: bug #67833
<Ubugtu> Malone bug 67833 in metacity "wrong URIpath drug'n'droped with mouse" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67833
<Keybuk> no
<Keybuk> ogra: bug #67383
<Ubugtu> Malone bug 67383 in ltsp "Udev seems to fail on LTSP thin clients, local device support affected" [Medium,Unconfirmed]  http://launchpad.net/bugs/67383
<Keybuk> :p
<ogra> Keybuk, ah, yes i wanted to ask about that one ... i suspect its a kernel bug but the syslog doesnt show anything
<Keybuk> ogra: why would it be a kernel bug?
<ogra> the udev error is the only indicator there
<Keybuk> you have several extra programs run by udev rules compared to the default?
<ogra> dunno, but the system seems to get extremely slow
<Keybuk> system gets slow => show me a bootchart
<ogra> we have one rule that runs two different scripts (one that triggers mounts and one that unmounts)
<Keybuk> do you use /dev/null in that script?
<ogra> not that i'm aware of, i'll look
<ogra> ogra@edubuntu:~/packages/ltspfs-0.4.3/scripts$ grep dev/null *
<ogra> remove_fstab_entry:    umount -l ${DEV} 2>&1 >/dev/null
<ogra> Keybuk, ^^^
<ogra> but the remove part isnt triggered on boot
<Keybuk> ok
<ogra> highvoltage, are you around ? 
<amachu> hi
<mjg59> cjwatson: Ah, right. I'm not really sure how this can be done better.
<Keybuk> it should create /dev/null first though
<ogra> highvoltage, we're talking about bug 67383
<Ubugtu> Malone bug 67383 in ltsp "Udev seems to fail on LTSP thin clients, local device support affected" [Medium,Unconfirmed]  http://launchpad.net/bugs/67383
<tfheen> ogra: you're aware that 2>&1 >/dev/null != >/dev/null 2>&1 ?
<Keybuk> static char *first_list[]  = {
<Keybuk>         "/class/mem",
<Keybuk>         "/class/tty",
<Keybuk>         NULL
<Keybuk> };
<cjwatson> mjg59: something in usplash to get usplash arguments, maybe
<ogra> tfheen, as long as it supresses output :)
<Keybuk> tfheen: it won't
<Keybuk> uh, ogra it won't
<Keybuk> that'll make sure that errors are placed on standard output
<mjg59> cjwatson: Sorry, I'm being horribly slow today. You mean have usplash parse the config file?
<cjwatson> 2>&1 => dup *current* fd 1 (i.e. stdout) onto fd 2
<cjwatson> >/dev/null => open /dev/null, dup onto fd 1
<tfheen> : tfheen@thosu ~ > echo blah >&2  | cat 2>&1 > /dev/null
<tfheen> blah
<cjwatson> think about it in terms of syscalls, remember that they're done in command line order, and it makes more sense
<ogra> in any case its not relevant for the bug ...
<ogra> Keybuk, /dev/null will exist at some point and i dont see how local device access should be slowed down by it
<cjwatson> mjg59: not sure. not a "right now" thing anyway
<Keybuk> ogra: it won't be ... I don't think udev is to blame at all
<Keybuk> cjwatson: except for pipelines, but let's not confuse the poor boy <g>
<plb> any chance of getting gaim beta 4 and flash 9 in edgy before release? 
<Keybuk> plb: none.
<cjwatson>  /topic
<ogra> flash 9 ?
<ogra> if its released probably :)
<plb> bah why not? people have been waiting years for flash 9
<plb> ogra: flash 9 beta is out
* ogra dounbts we'll see a flash release before new year
<cjwatson> edgy is FROZEN
<plb> works better than 7
<cjwatson> very, very solid
<gnomefreak> plb: not on everyones system
<tfheen> edgy is at roughly 0K.
<gnomefreak> i have seen alot of people complaining
<cjwatson> universe and multiverse are still a little bit slushy, but I'd be pretty cautious about big new things that require lots of user testing
<thom> plb: if they've been waiting years they can wait another 6 montsh
<plb> I've seen a few complain but not many
<plb> heh
<cjwatson> main and restricted are entirely locked down
<plb> toss that crap in the nonfree section =P
<Keybuk> cjwatson: so my scary util-linux patch is out? :p
<highvoltage> ogra: sorry, been in a meeting
<tfheen> Keybuk: any scary patches from you are out until feisty opens, yes.  :-P
<Hobbsee> tfheen: you mean they'll be welcome even then?  :P
<plb> how about an early release like firefox and fedora 6 ;] 
<highvoltage> ogra: so if I understand correctly, the error message isn't a problem, just ugly?
<tfheen> plb: no.  Please stop disturbing the developers working on preparing the release.
<ogra> highvoltage, do you have a syslog from a local device access attempt ?
<ogra> highvoltage, i'd like to see whats actually causing the slowness ... the bootlog isnt very informative
<mdz> Riddell: I just did a fresh kubuntu OEM install, and got the KDE crash handler on login
<mdz> Riddell: kdesktop crashed
<Riddell> mdz: not good, I'll try out OEM
<mdz> Riddell: sorry, ubiquity install
<mdz> wrong vm
<Riddell> mm, even worse
<highvoltage> ogra: I don't have access to an edubuntu machine at the moment, when I get home I'll send that syslog to you first thing
<mdz> Riddell: only oddity was that it failed to open the sound device (due to another vm using it)
<mdz> Riddell: emailed details
<Keybuk> tfheen: aww, I just wanted to rewrite mkswap to check the partition for an existing swap or hibernate partition and reuse the same UUID :)
<tfheen> Keybuk: you're like three months late for that to go in. :-P
<Keybuk> tfheen: how about udev just swapon'ing any block device with a swap signature? :)
<ogra> Keybuk, ++
<wasabi> Especially hot pluggable ones that you can yank our unexpectidly.
<Keybuk> wasabi: the kernel copes just fine with that ;)
<ogra> i have that in ltsp for feisty ...
<wasabi> heh.
<ogra> Keybuk, not true
<Keybuk> it does
<Keybuk> it's entirely happy to run the OOM killer if needed
<wasabi> sounds insane.
<wasabi> Yeah, but a running app was on the device.
<ogra> if i kill an ndb device where i already use swap space in ltsp the client will die
<ogra> where should it put the swapped data ?
<Keybuk> wasabi: heard the one which goes "Doctor, it hurts when I do this" ?
<cjwatson> wasabi: don't yank out block devices that might have swap on, then
<wasabi> Eh. Sorry. It seems silly. What if I was putting in a drive just to see what was on it?
<HrdwrBoB> then you get free extra swap
<wasabi> ANd it happened to be an old Linux drive... Nobody is going to check if something auto enabled swap
<HrdwrBoB> and you get to wonder what's using the partition table when you reload it
<cjwatson> this would only be at boot
<HrdwrBoB> and why it doesn't work
<tepsipakki> hi.. I'm trying to reinstall initscripts on edgy, but /etc/network/if-up.d/mountnfs is not created for some reason
<tepsipakki> I'm trying to reproduce some weird problems with nfs
<ogra> cjwatson, the way i understood Keybuk we'll have a udev rule that generally matches all swap devices
<Keybuk> tepsipakki: "reinstall initscripts" ?
<ogra> that wouldnt restirct it to boot
<wasabi> What's the point anyways?
<tepsipakki> Keybuk: well, unpacking it would be enough :)
<cjwatson> at boot> perhaps not
<Keybuk> wasabi: of swap?  none, just buy more memory
<wasabi> I mean, the point of auto enabling.
<Keybuk> 2GB is a reasonable minimum :)
<cjwatson> Riddell: what package do I need to install to get Qt Designer to know about KListView widgets?
<Keybuk> wasabi: solves the "I ran mkswap, and now my fstab UUID is wrong" problem
<cjwatson> tepsipakki: it's probably a conffile; use dpkg --force-confmiss
<wasabi> Oh.
<tfheen> Riddell: kubuntu dvd up
<tfheen> ubuntu desktop running
<Riddell> cjwatson: should be kdelibs4-dev
<tepsipakki> Keybuk: that did the trick, thanks
<Riddell> cjwatson: else kde-devel should bring in the rest
<wasabi> I'm only against it because I know I'd probably hit it. I mean, I've done weird stuff like put swap on a usb disk temporarily.
<mdz> Riddell: it didn't happen on the second login
<cjwatson> Riddell: ok, thanks
<mdz> Riddell: I've saved a vmware snapshot where it crashed if you need more info
<wasabi> I don't erase that disk immediatly after... I set it aside and use it again later.
<wasabi> I'd hate to plug it into a system later to get a file off and have some app swap to it, then pull it.
<Keybuk> you shouldn't just pull it anyway ;)
<mdz> true, and the eject process could deactivate the swap
<wasabi> True. Guess you've got me then. What about SATA?
<wasabi> Same deal?
<Keybuk> what about SATA?
<wasabi> I have a stack of 4 hard drives sitting here I have to go through soon... so I'll be plugging them into my SATA ports and seeing what's on them. Guess I just have to be careful to swapoff them.
<wasabi> I suspect that'll bite people.
<tfheen> wasabi: just like you should umount them, yes.
<wasabi> Except I had to actively mount them to begin with.
<wasabi> It didn't do it behind my back.
<Keybuk> maybe it will in feisty ;)
<wasabi> Heh.
<wasabi> Actually I'd be fine with that.
<wasabi> As long as the expectations remain the same for any device you plug in.
<mdz> ogra,tfheen: is edubuntu up to date?
<wasabi> I do sort of view swap as a bit more dangerous than some vfat partition though.
<wasabi> I pull vfat all the time. If I know I didn't alter it, it's cool.
<wasabi> The kernel handles it fine, nothing is killed.
<ogra> mdz, live is building
<ogra> mdz, install should be fine
<tfheen> mdz: livefs-es are done, I'm building ubuntu desktop cds now, will do edubuntu live cds once that's done
<tfheen> (then I'll do DVDs, then ports)
<wasabi> Some of my running applications could have been swapped to the disk though, pulling that will trash them.
<mdz> tfheen: oh, ubuntu desktop CDs aren't up to date yet?
<mdz> I swear you said they were
<ogra> mdz, only language pack changes ...
<mdz> <tfheen> ubuntu, kubuntu daily-live ready
<wasabi> Oh also... no. I found a downside.
<tfheen> mdz: they were oversized.
<wasabi> Does a swap partition have a partition length check?
<mdz> argh
<tfheen> mdz: sorry. :-(
<wasabi> So it will refuse to mount if the size of the disk it's on != the size the fs expects.
<tfheen> uh, wtf?
<pitti> tfheen: it seems the recent seed change wasn't picked up?
<Keybuk> wasabi: in the name of all that is holy and good in this world, WHY WOULD YOU DO THAT?!
<wasabi> Keybuk: md/raid1
<iwj> cdimage.ubuntu.com is broken again
<wasabi> My swap partitions on my servers are on md devices.
<iwj> Spads: rsync: connection unexpectedly closed (0 bytes received so far) [receiver] 
<Keybuk> wasabi: that wouldn't show up as a swap partition, it'd show up as a partial md block
<ogra> wasabi, wow, you have md/raid on usbsticks ? 
<ogra> intresting :)
<Keybuk> RAID-1 MIRROR SWAP!
<wasabi> Keybuk: raid1, it's show up as the underlying device.
<tfheen> pitti: *sigh*, yes.
<wasabi> /dev/sdNY would still be a valid partition.
<Keybuk> wasabi: we don't mount devices, we mount block devices (aka partitions)
<ogra> iwj, works fine here
<Keybuk> yes, but it wouldn't be a swap partition
<Keybuk> it'd be an md partition
<wasabi> md puts metadata at the end.
<Keybuk> they still show up as md
<wasabi> It's perfectly mountable manually.
<wasabi> I get into this all the time with lvm/md probe orders.
<wasabi> where lvm will actually detect the underlying md device as the lvm pv
<ogra> iwj, there is a connection restriction ... only two from the same IP are allowed iirc
<wasabi> and screw everything up
<Keybuk> heh
<iwj> ogra: I'm testing from my colo and no-one else there is rsyncing.
<ogra> hmm
<iwj> And it doesn't work from here via NAT and DSL either.
<iwj> cdimage.ubuntu.com A INET 195.248.90.25
<StevenK> wasabi: md_component_detection = 1
<Spads> iwj: okay, lemme check
<ogra> i'm geeting my recent edubuntu isos just fine atm 
<iwj> ogra: Say   rsync cdimage.ubuntu.com::  and what does it say ?
<wasabi> StevenK: device_size_prompt = no actually makes the problem go away.
<mdz> working fine here
<wasabi> evms. =)
<wasabi> StevenK: But the point remains, Keybuks auto-swap-mounter will need an equiv to md_component_detection
<Spads> iwj: load is heavy
<ogra> iwj, what kind of syntax is that ?
<iwj> ogra: Standard syntax for an anon rsync.
<mdz> one of them
<iwj> Spads: So it just hates me ?
<iwj> mdz: Right.  It's less typing than the same thing in URL format :-).
<wasabi> brb
<Spads> iwj: have you tried the cdrom/ target specifically?
<Keybuk> wasabi: there's a whole bunch of specs for MTV registered
<ogra> iwj, ah, i always use rsync rsync://cdimage....
<Spads> or rather the cdimage/ target
<Keybuk> udev-lvm, udev-evms, udev-device-mapper, udev-mdadm
<ogra> but you are right, new connections are refused here as well
<iwj> Spads: Ah, if I say   ...::cdimage  it works.
<Spads> yeah
<wasabi> Keybuk: Yeah.
<Spads> cdimage doesn't have a default stanza and it doesn't list
<wasabi> I registered myself to show up on everything having to do with md and lvm and evms.
<cjwatson> tfheen: sorry, I'll start comparing seed revnos against an sftp update from now on
<tfheen> cjwatson: my fault just as much.  Ubuntu livefs-es are running now at least.
<elmo> I've increased the limits on cdimage, try again now
<mdz> iwj: ^^
<iwj> elmo: Thanks.
<tfheen> mdz: ubuntu and edubuntu livefs-es didn't pick up the seed changes because I forgot to ask Colin to do a publisher run.  He's doing so now, which will make the next build reasonable.
<mdz> tfheen: so I should abort this test install, ok
<tfheen> mdz: yes.  Again, sorry.
<tfheen> I'll say when we have reasonable images.
<tfheen> alternate should be good, since it doesn't require a publisher run, but livefs-es need it.
<bddebian> Howdy
<doko_> mvo: ping
<mvo> doko_: pong
<tfheen> cjwatson: publisher done?
<cjwatson> tfheen: yes
<tfheen> ubuntu livefs building again.
<pschulz01> Greetings...
<pschulz01> What is being done about files that regularly need updating?
<mdz> they are regularly updated
<pschulz01> I have submitted a couple of bugs.. regarding usb.ids and pci.ids.
<pschulz01> Neither of these have been updated for 6 months.
<cjwatson> those are in packages we sync from Debian
<cjwatson> our default system doesn't actually care about them except for display, AFAIK
<Keybuk> correct
<cjwatson> so they are not a high priority
<cjwatson> for hardware detection, the kernel's module device tables are used
<elmo> cjwatson: so what you're saying is that they are not a priority that need prioritising?
<juliux> hi all, upgrade vom dapper edubuntu to edgy edubuntu is here working without problems
<juliux> also the update for the nvida driver
<Spads> elmo: dream the impossible dream
<Nafallo> pschulz01: man update-pciids
<CarlFK> grep irc /var/log/installer/syslog  "pkgsel: Entity 'irc-server' not defined" which may be a proximate error to something a few 100 lines up (that I am trying to find the beginning of)
<Keybuk> elmo: we synergistically leverage contributions from our Debian colleagues thereby reprioritifying them to a matter of collaboration
<CarlFK> from edgy-alternate, for those that don't know me :)
<fabbione> you guys give me headake!
<cjwatson> irc-server the what?
<cjwatson> CarlFK: full log please
<pschulz01> Nafallo: What about usb.ids.. aahh there's one of those as well :-)
<CarlFK> cjwatson: that's what I said. coming iup
<KurtKraut> There is a serious bug in Edgy's Ubiquity (67082) that makes the root filesystem unrecognized. This makes Ubuntu unable to install. Anyone could tell me is this will be fixed before 26th ?
<elmo> iwj: ping
<KurtKraut> This problem so so frequent that it was reported 3 times in different IDs.
<cjwatson> KurtKraut: that makes it considerably less frequent than many other problems. :-)
<cjwatson> KurtKraut: AFAIK that problem only happens if you go back and forward between gparted and the mount points page and make different selections each time
<cjwatson> which makes it merely bad rather than a showstopper
<cjwatson> I haven't seen it in test installs so far
<KurtKraut> cjwatson, hmm... yes, you're right. But I guess when a bug makes the system unable to install, people tend to think 'of, this still beta and someone will fix', and doesn't report it.
<cjwatson> I'll believe you when the bugs about failed installs stop rolling into my inbox
<CarlFK> cjwatson:  http://dev.personnelware.com/carl/temp/Oct24/a/syslog
<CarlFK> 3.5mg - want it zipped?
<KurtKraut> cjwatson, ok, but let us be straight to the point... any chance this problem being fixed before Edgy release ?
<cjwatson> KurtKraut: contrary to what one person in that bug report claims, bug 67254 is a different problem
<Ubugtu> Malone bug 67254 in qtparted "Kubuntu : partition display problem" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67254
<cjwatson> KurtKraut: I'm afraid not at this point
<crimsun> fabbione: pong
<cjwatson> we've already frozen solid and will only stop for absolute showstoppers
<cjwatson> if we have to reupload ubiquity for some showstopper reason, I'll consider it
<cjwatson> but at present I don't actually know what the problem is, and, without having reproduced it locally, attempting to fix it is risky
<KurtKraut> cjwatson, I do understand. But what should a bug have to be considerated a 'showstopper' for instance ?
<fabbione> crimsun: sorry.. i need 5 minutes right now.. i will ping you back soon
<cjwatson> KurtKraut: for a start, there would have to be no documentable workaround
<cjwatson> KurtKraut: I'm not attempting to say that this isn't an important bug, but I'm afraid I just don't think it's release-critical - we have finite and increasingly little time available
<cr3> on several occasions, I have encountered images > 700M under cdimage.ubuntu.com/daily-live/current. is that normal considering this is a daily-live directory?
<iwj> elmo: pong ?
<cjwatson> cr3: well, to start with, it's only worth reporting if there isn't a .OVERSIZED file present
<cjwatson> cr3: secondly, I just lowered the size limit a little bit. According to Media Motion who ship our pressed CDs, the real limit is actually a little over 700MB, and our scripts were told the figure they gave us
<cjwatson> cr3: but we've since heard of some rare cases where it really does have to be <= 700 * 1024 * 1024, so I just dropped the size limit to take account of that
<KurtKraut> cjwatson, I'm talking here with the guy who reported the bug. He asked me to come here and ask because he is not fluent in english (neither I am :P)
<cr3> ok, so I'll get some dvd-rws to test for now, no problem
<elmo> iwj: I've had several dapper -> edgy upgrades where the default font choice in gnome went from subpixel -> best shape which makes my fonts in gnome-terminal look like crap.  is this known and if so, is there a bug about it somewhere?
<cjwatson> KurtKraut: the primary thing I need is /var/log/syslog and /var/log/partman attached to the bug
<cr3> cjwatson: thanks for the explanation though, I'll notice the .OVERSIZED file next time
<cjwatson> as a rule, screenshots don't help me much
<cjwatson> CarlFK: no thanks, unzipped is fine
<KurtKraut> cjwatson, I'm asking him to reproduce the problem and post these files you've asked.
<cjwatson> KurtKraut: thanks
<cjwatson> there is a duplicate with log files, so it's not critical
<cjwatson> also a precise description of exactly what steps he took in the partitioner would be good
<KurtKraut> cjwatson, he's taking notes of the steps he done and I'll translate it to english
<pirast> is it planned to make xorg autodetect hardware?
<pirast> otherwise ill create a spec
<CarlFK> cjwatson: lots of "dpkg: warning - ignoring pre-dependency problem !"  too
<cjwatson> CarlFK: unimportant
<CarlFK> ok
<cjwatson> CarlFK: oh, that's not an installer bug, that's some documentation file that's broken
* cjwatson stops caring
<cjwatson> CarlFK: it's probably an ubuntu-docs bug
<cjwatson> (from the looks of the filenames)
<cjwatson> CarlFK: to be more verbose, "ignoring pre-dependency problem" is entirely normal when you're bootstrapping a chroot from nothing and half the pre-deps simply aren't there yet, but will be later
<Keybuk> pirast: it's being developed upstream; we'll pick it up when they release a version with that in
<CarlFK> ok - if you arn't worried, I'm not either :)
<cjwatson> debootstrap extracts all the required packages first (dpkg -x) so it doesn't actually cause a practical problem
<tfheen> .. and the race is on, king and royal are both almost done with royal about 40MB in the lead.  The end of the race is about 100M away, so this is exciting.
<pirast> Keybuk, k.. thanks :-)
<iwj> elmo: Err, it's not know by me.  There was some fontconfig subpixel configuration change I was involved in but aside from that you might be better off asking seb128 ...
<iwj> s/know&/n
<Keybuk> pirast: the spec would roughly end up being "hurry up and wait"
<cjwatson> iwj: (that was the reason I directed elmo to you - it sounded like it might be a related problem)
<Keybuk> tfheen: you should listen to workrave, and take breaks, y'know
<tfheen> Keybuk: I've been outside today and all.  Just release bounciness.
<pirast> Keybuk, yeah.. I won't create a spec then :-) One more question, is there any timeplan when the upstream feature is done?
<iwj> elmo: is the problem that the symlinks in /etc/fonts/conf.d related to *-bitmaps.conf are wrong ?
<tfheen> .. king is catching up, about 30MB behind now, but royal is _almost_ there..
<tfheen> and royal won.
<tfheen> there, cron.daily-live running for ubuntu, edubuntu livefs-es building.
<CarlFK> cjwatson: can you give me a 30 second look at:  http://dev.personnelware.com/carl/temp/Oct24/a/late_command.sh.txt  and give me a tip on how to make the "# chroot $TARGET" not confuse the installer?
<Keybuk> pirast: wrong channel to ask that I'm afraid, you'd need to speak to the Xorg guys directly
<cjwatson> CarlFK: 'chroot /target' spawns an interactive shell and then sits there; it does not mean "run the rest of this script in the chroot"
<pirast> Keybuk, yeah, thanks anyway :-) i though that you'd know :-)
<cjwatson> CarlFK: just use apt-install instead of chroot /target apt-get install and you should get progress bars and everything
<iwj> elmo: If it's the subpixel thing, it's related to fontconfig-config 2.3.2-7ubuntu2, which is an attempt at #56682.  It wasn't possible to preserve all previous handmade configuration.
<iwj> bug 56682
<Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,Fix released]  http://launchpad.net/bugs/56682
<cjwatson> CarlFK: from the looks of things you're confusing a shell script with a series of commands typed at a shell prompt :)
<cjwatson> (the 'exit' down near the bottom of the script needs to go as well)
<CarlFK> cjwatson: I got the feeling that the 'apt-get update' run in the installer enviroment wasn't updating the /target, but now that I think about it, it should.  either way - I don't need more of your time now :)
<CarlFK> cjwatson: the exit was just to skip the rest of the script 
<cjwatson> CarlFK: apt-get update> you were correct to start with; it won't
<cjwatson> there is no "apt-get" binary in the installer environment
<elmo> iwj: I don't think it's related to that
<cjwatson> CarlFK: you don't need to run apt-get update there, though; just preseed apt-setup properly instead of munging sources.list by hand
<cjwatson> CarlFK: apt-setup has a facility for preseeding "local" mirrors - see the installation guide for examples
<elmo> iwj: well depending on what a sane /etc/fonts/conf.d is meant to look like
<cjwatson> CarlFK: in edgy final apt-setup has been fixed so that you shouldn't need to manually force in the official mirrors anyway
<iwj> elmo: Well, by default you'd have 30-debconf-no-bitmaps.conf 10-defoma.conf as symlinks and a bunch of random *.conf files, including no-* and yes-* in some cases.
<elmo> iwj: http://people.ubuntu.com/~james/tmp/fonts-dir.txt
<mdz> tfheen: what's the ETA for a new candidate?
<slomo_> cjwatson: does ubiquity copy the complete filesystem or only the files belonging to a package and then run the maintainer scripts the same way as for a normal installation of the package?
<cjwatson> slomo_: it just copies the complete filesystem, and then runs some manual fixups
<iwj> elmo: Hmm.  20-debconf-sub-pixel.conf is part of why it's not the way you want it to be.
<cjwatson> slomo_: in general any maintainer script that might do anything hardware-specific needs to be re-run by ubiquity
<slomo_> cjwatson: including /var? then we need a fixup for dbus in feisty... but well, we can care about that then :)
<tfheen> mdz: ubuntu is just done
<tfheen> sfllaw: ^^
<Keybuk> slomo_: what does dbus put in /var?
<cjwatson> slomo_: all files
<iwj> elmo: Oh, no, the problem is that you asked for subpixel and it turned that off, right ?
<cjwatson> slomo_: all files on the squashfs, that is, not on the live session
<tfheen> sfllaw: as in, ubuntu desktop for all arches is up.
<iwj> elmo: This is controlled by the debconf value fontconfig/subpixel_rendering
<cjwatson> slomo_: and does dbus in edgy strictly speaking require this?
<elmo> iwj: yes
<slomo_> cjwatson, Keybuk: a machine uuid that should be unique among machines and is recommended to stay the same way after reboots (/var/lib/dbus/machine-uuid iirc)
<elmo>   fontconfig/subpixel_rendering: Always
<CarlFK> cjwatson: thanks for the tips - things are working pretty good for me as is - I may ask for more after edgy is up and away 
<slomo_> this will be created by the init script if not present already
<elmo> hmm
<cjwatson> slomo_: that would need to be reconfigured, yes
<cjwatson> CarlFK: ok
<Keybuk> slomo_: is this so Fedora can find out how many users they don't have? :p
<Keybuk> why does a machine-local bus need a world-unique id?
<BenC> tfheen: ping
<tfheen> BenC: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
<slomo_> Keybuk: no... for ssh -X kind of sessions it's needed
<Keybuk> slomo_: that can be a per-boot id though, no?
<Keybuk> it doesn't need cross-reboot persistance?
<slomo_> Keybuk: it can... but the dbus guys recommend to keep it always the same as people will most probably begin to assume that something called "machine-uuid" is always the same
<Keybuk> why have the file at all?
<BenC> tfheen: re bug 62135, I have a trivial fix and upload ready for it
<Ubugtu> Malone bug 62135 in mesa "Support for Intel 965 (GMA X3000) doesn't work" [High,Confirmed]  http://launchpad.net/bugs/62135
<Keybuk> system bus starts, generate a uuid, and just uses it
<cjwatson> yeah, just pass it as a command-line argument?
<cjwatson> or do clients need to know it?
<tfheen> BenC: please follow the procedure at https://wiki.ubuntu.com/StableReleaseUpdates
<BenC> tfheen: No uploads allowed for edgy release?
<tfheen> BenC: no
<tfheen> BenC: unless you find something earth-shattering.
<slomo_> Keybuk: no idea... the only way why it makes sense to store it is to have it persistent... well, let ubiquity remove that file and we're done and don't need to worry about it anymore...
<cjwatson> not for main, anyway
<cjwatson> slomo_: ideally, it wouldn't require any hacks in ubiquity at all
<BenC> tfheen: it's super trivial, and without it, i965 users will have broken GL (meaning all GL apps will just show a black/gray screen)
<cjwatson> but removing the file's fine if that's the only way
<Keybuk> slomo_: but why does it need to be persistent? :p
<whiprush> thom: I'm around if you want to talk about that spec
<BenC> tfheen: It's a one line change to a Makefile to set CC=gcc-3.4 for i965_dri.so only, and build-dep on gcc-3.4 for i386 and amd64
<tfheen> BenC: well, it's just too late.  Release is in less than 48 hours.
<slomo_> Keybuk: no idea... better ask the dbus guys... i can't think of a reason other than having it because it could be implemented ;)
<Keybuk> the dbus guys are on scary crack most of the time
<sjoerd> Keybuk: it doesn't have to be persistent
<Keybuk> then why is it persistent?
<Keybuk> why go to the trouble of having it persistent if it doesn't need to be?
<BenC> tfheen: Tried last week to get with you about it, but didn't get a response on IRC..I'll update the bug report
<sjoerd> because they rather had it in /var/lib instead of /var/run, because it might be usefull to be presistent..
<Keybuk> but why write it at all?
* sjoerd has tried to push them to put it in /var/run instead.. to no avail
<Keybuk> if it doesn't need to be persistent, it doesn't need to be in a file
<Keybuk> that means you don't need any of the reading or writing code
<sjoerd> oh, the sessions busses need to read it
<Keybuk> can't they get it from the system bus?
<slomo_> the session bus could ask the system bus, no?
<Keybuk> they are kinda connected, after all
<thom> whiprush: i spammed you in private message :-)
<Robot101> slomo_: bus daemons don't open bus connections to other buses
<sjoerd> The only guarantee dbus needs at this time is that the key stays the same untill the box is rebooted...
<sjoerd> and that the key is different from the one on other boxes
<Keybuk> right... so it could generate it when the system bus starts
<cjwatson> BenC: I know it's no good now, but if you'd just uploaded it then we'd have seen it in the unapproved queue and could have decided out of band :-/
<BenC> cjwatson: Makes sense, didn't think about that
<sjoerd> Keybuk: i totally agree with you and tried pushing to put in in /var/run.. So it is indeed created on boot when the system bus is first started.. But the dbus upstream guys didn't like it :(
<tfheen> BenC: oh well, sorry about that. 
<BenC> good thing is, it isn't an install issue, so it's quite alright being in edgy-updates
<whiprush> thom: not registered so I don't think you can see my reply, so yes, that sounds awesome.
<BenC> tfheen: understandable, you're pretty busy...I'll get it into edgy-updates
<thom> whiprush: ah, arse
<thom> ok
<sjoerd> Keybuk: please send your comments to the dbus list, it might not be too late....
<whiprush> thom: sec, let me freenode myself.
<Keybuk> sjoerd: they don't like me on there :)  I challenge their fragile little world
<sjoerd> then we're doomed to use /var/lib blah :)
<Robot101> sjoerd: if you think havoc's talking shit, tell him :P
<Robot101> ask him what the use case is for persistent uuids
<sjoerd> Robot101: i've tried last night on #dbus and on the dbus list, i had my share for now
<Robot101> let me have a go :D
<sjoerd> :)
<Keybuk> sjoerd: we're not doomed to do anything
<Keybuk> we have a distro
<Keybuk> HAND ME THE BUG SPRAY!
<Keybuk> </jdub>
<sjoerd> hehe
<poningru> rofl
<Keybuk> we're probably going to have to patch out system service activation
<whiprush> thom: I apparently can't use a nickserv for more than a week without losing the password. Got IM?
<Keybuk> along with whatever hal tries to do as well
<Keybuk> so we can get messy in there <g>
<sjoerd> hehe
<sjoerd> the system service activation scares me too..
<sladen> whiprush: change the password to something memorable, like "ubunflu", or "you suck" :)
<Keybuk> that dbus list thread turned out to be mostly me talking to a wall, from what I could tell :-/
<sladen> whiprush: seveas might be helpful in getting it back
<JanC> are the final translations already in the edgy repositories?
<tfheen> edubuntu livefs-es done; live images building.
<thom> whiprush: heh, sure. 
<iwj> elmo: Hmm.  Well the fontconfig machinery is working I think but I'm not sure I really understand the gnome side very well.
<pepsiman> JanC: looks that way
<ogra_> tfheen, thanks 
<JanC> then something is wrong with them I fear  :-/
<tfheen> JanC: oh?
<cjwatson> JanC: if it's just missing translations, then those can be fixed by post-release updates
<JanC> I get several complaints about wrong or missing Dutch translations that are okay on my system (using the daily language pack builds) and have been okay for weeks to months
<cjwatson> JanC: nl isn't one of the language packs on the live CD, which may be the reason
<pepsiman> daily langpacks stopped building at translation freeze too, they should be the same
<JanC> that's weird
<highvoltage> 
<JanC> I'll look if I can compare them
<highvoltage> 
<pitti> tfheen, sfllaw: Testing/Current says 'out of date' for all disks; is desktop 24.4 ready to test or are we waiting for some bug fixes?
<tfheen> pitti: desktop 24.4 is current, but sfllaw is asleep.  Please fix the wiki page and go ahead with testing.
<pitti> yesmasta
<pitti> tfheen: alternate as well?
<tfheen> pitti: yes.
<pitti> rock
<iwj> tfheen: Oh, good.
<ogra_> tfheen: either lithium is slow with copying or i miss a powerpc live iso
<ogra_> ah, it was only slow
<iwj> tfheen: You mean 24.1 ?
<iwj> cdimage/daily/20061024.1
<cjwatson> iwj: daily-live
<iwj> Ah.
<iwj> Err, no, not `ah'.  I mean, for the alternate.
<cjwatson> sfllaw: I'm taking Ubuntu desktop i386 and giving Keybuk Kubuntu desktop i386
<cjwatson> since we're both in the office and I've already started on the former anyway
<Keybuk> note that Keybuk's ability to test large numbers of candidates is limited to his access to the vmware box here
<pitti> cjwatson: can you please ping me when you have finished editing TEsting/Current?
<cjwatson> whoever updated Testing/Current forgot to tag old PASS/FAIL with the old build numbers
<cjwatson> pitti: just did
<ogra_> heh, i wanted to ask the same
<pitti> ah, thanks
<ogra_> pitti: could you add 20061024.2 as the live candidate for edubuntu ? (its out of date currently)
<pitti> ogra_: sure
<ogra_> thanks :)
<pitti> tfheen: server 20061023 is considered current?
<JanC> *fuck*
<pitti> JanC: now? here?
<JanC> this is the second time during edgy that the Dutch tranlations have been reverted to an old faulty state   :-(
<JanC> this isn't funny anymore  :-(
<pitti> Riddell: Testing/Current says Kubuntu live 20061024.2, but there's only 24.1
<cjwatson> JanC: but you said the language packs were fine?
<cjwatson> iwj: I think 24.1 is fine for alternate but I'm not sure
<cjwatson> iwj: yeah, looks ok
<JanC> the daily build that I probably still have installed yes, the package in edgy apparently not...  :-(
<cjwatson> JanC: should be fixable post-release if pitti knows the problem
<pitti> JanC: edgy's packages are from last Friday; I don't know of any problem with them
<JanC> It's probably all reverted in launchpad too
<iwj> cjwatson: Oh, good.  Because that's what I've got on this CD :-).
<jordi> does anyone know how big aprox. is a ubuntu mirror of the three latest distros?
<tfheen> pitti: no.
<jordi> say, in this moment, edgy, dapper and breeze, for i386
<jordi> s/breeze/breezy/
<pitti> tfheen: ok, then I put server to 'out of date'
<tfheen> pitti: please just make it 20061024 if that's not available yet.
<pitti> tfheen: oh, ok
<fabbione> tfheen: did you roll out new server images for all arches or only i386/amd64?
<tfheen> pitti: as in "build running"
<tfheen> fabbione: I started all arches now, but I can just do i386/amd64 if you'd like
<fabbione> tfheen: that's fine
<fabbione> i can restest sparc very quickly
<tfheen> fabbione: fixed to just do i386 + amd64
<fabbione> tfheen: ok...
<JanC> right, so rosetta has "forgotten" our translations fixes again...   :-(
<JanC> this isn't funny anymore  :-(
<cjwatson> #launchpad maybe?
<tfheen> I'm off for a roleplaying session for a few hours.  If there's anything urgent, I have my cellphone.
<pitti> argh, rescue mode bombs out -- this worked until RC
<ogra_> pitti: yeah, same here
<fabbione> pitti: how does it bomb out?
<pitti> with a read dialog box saying that it failed to start
* pitti is just filing a bug
<pitti> ogra_: ^ FYI
<ogra_> bug 60423
<Ubugtu> Malone bug 60423 in rescue "freeze after exiting rescue shell" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60423
<ogra_> i just saw that one
<ogra_> but it starts fine and also runs a shell in the target system ... for me its only the reboot/shutdown thats failing
<fabbione> oh interesting
<cjwatson> yeah, I haven't diagnosed 60423 yet, but sounds different from pitti's problem
<pitti> cjwatson: indeed it's different, I filed bug 68005 about it
<Ubugtu> Malone bug 68005 in debian-installer "rescue mode fails" [Medium,Unconfirmed]  http://launchpad.net/bugs/68005
<pitti> 60423 is around for ages, but it doesn't break the actual rescue mode
<pitti> on the bright side, cdrom-check now reboots properly \o/
<pitti> tfheen: did you deliberately fix bug 28033? it's still open, but doesn't happen to me any more (both on amd64 and powerpc)
<Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Medium,Confirmed]  http://launchpad.net/bugs/28033
<Riddell> pitti: fixed
<wasabi_> Heh. We do have a ton of specs don't we.
<wasabi_> There should be some note someplace that making a spec with no intention or ability to implement it is mean.
<cjwatson> pitti: Oct 24 16:01:15 rescue-mode: no partitions found!
<iwj> pitti, cjwatson: alternate rescue wfm on i386.
<pitti> ugh, it asked me for four partitions
<pitti> cjwatson: ah, wait, that was on the other system
* pitti seems to get confused doing three test installations at the same time
<pitti> cjwatson: sorry
<cjwatson> pitti: do you still have that image running?
<pitti> cjwatson: unfortunately not, already wiped
<pitti> I'll try it again after the current installation
<cjwatson> pitti: if you get the same error, please tell me the output of 'list-devices partition' on tty2 (and dig into that with 'set -x' and such if you can)
<pitti> cjwatson: I *thought* the image had an installation, but I was wrong
<jdong> is bug 63558 going to get any attention?
<Ubugtu> Malone bug 63558 in usplash "Latest usplash leaves my consoles corrupted" [Low,Confirmed]  http://launchpad.net/bugs/63558
<pitti> cjwatson: yup, will do
<jdong> it appears to affect all ATI video cards, and results in unusable/garbled VT's
<jdong> this is a regression... usplash worked fine on these cards up to bzr revno 90 or so
<sladen> jdong: I thought mjg59 had default with the usplash+ATI issue, is it still there?
<pitti> argh, that's the second attempt to fix other people's edits; please respect locks
<jdong> sladen: as of this morning my ATI laptop still has garbled VT's when using usplash....
<pitti> cjwatson: works fine now
<cjwatson> pitti: hmmmmmmmmmmm
<cjwatson> pitti: ah, if there were indeed no partitions, that would be it :)
<pitti> cjwatson: since I'm only secondary tester for amd64 I do these in vmware; I wiped the disk *brown paperbag*
<cjwatson> heh, ok
<cjwatson> just running the publisher again to publish some universe stuff
* fabbione tries to install edubuntu-server/edubuntu/xubuntu/ubuntu/kubuntu in one go
<fabbione> let see what happens..
<fabbione> this is a valid config from netboot/netinstall :)
<fabbione> BUM!
<pitti> oh, the progress bar in usplash is now at the very top screen border -- is that intended?
<mdz> pitti: it isn't here
<pitti> might be a vmware glitch, but it worked earlier
* pitti will check when he does a real install
<fabbione> ogra: ping?
<lucas> mmh, I have an horizontal line about 1cm below my mouse cursor on edgy with the fglrx driver
<lucas> does this ring a bell ?
<mvo> lucas: I have seen this before, is this a setup with working dri maybe (check your xorg.0.log)?
<fabbione> cjwatson: ping?
<pitti> Kamion: current amd64/alternate does not install language-support-en; is that known?
<pitti> cjwatson: ^
<pitti> Kamion: oh, if the publisher isn't running, then no wonder why the postgresql-8.1 dapper-security upload doesn't come through; any chance to slip it in?
<siretart> is usplash on amd64 delibrately back/white, and the progress bar at the top of the screen?
<sladen> siretart: sounds like what pitti mentioned at 18:01
<siretart> sladen: oh. (1901 for me, but anyway)
<siretart> thanks
<siretart> pitti: no, I see that on my amd64 as well
<pitti> must have changed recently
<siretart> pitti: is usplash black/white for you as well?
<Toadstool> siretart: I have the same issues on my amd64 laptop
* sladen wonders who the first person to file a bug is going to be...
<tfheen> pitti: http://launchpad.net/bugs/28033 > yes, I fixed it.  At least I think I fixed it.
<Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Medium,Confirmed]  
<tfheen> siretart: it's greyscale on amd64 by design
<pitti> mvo, sfllaw, other testers: please verify that language-support-en gets installed (check OO.o help); it doesn't for me
<siretart> tfheen: ah. I see. I fear bug reports about usplash on amd64 being 'broken' because of that. is there a rationale for that behavior?
<sladen> siretart: I suspect that it's to do with palette handling
<siretart> I like the black/white one. really. Its just that I fear bugs because of confused users
<siretart> perhaps we just make the logo read: ubuntu - amd64 edition or something like that
<cjwatson> pitti: I ran the publisher a moment ago, which I think included postgresql-8.1
<pitti> cjwatson: cheers
<cjwatson> pitti: haven't encountered alternate not installing language-support-en; bug me
<pitti> cjwatson: done, bug 68017, and just followed up
<Ubugtu> Malone bug 68017 in debian-installer "does not install language-support-en" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68017
<pitti> cjwatson: might again be due to saying 'no' to 'download additional language support'
<ogra> fabbione: ?
<cjwatson> pitti: indeed
<cjwatson> DDTT
<cjwatson> pitti: it's a dup of another one of your bugs, I'm afraid ;-)
<fabbione> ogra: does ltsp-build-chroot REALLY forces you to have an edubuntu CD ?
<ogra> nope
<pitti> cjwatson: yeah, it just occured to me too late
<ogra> but edubuntu is the only flavor that uses it by default
<ogra> fabbione: you need to use expert to run it on non-edubuntu systems
<fabbione> ogra: one sec.. i need to show you the exact error message
<fabbione> Oct 24 18:58:51 ltsp-client-builder: no CD-ROM found ! Not installing ltsp chroot
<ogra> oh, right
<fabbione> ogra: note that this was a netboot/netinstall
<ogra> yep
<ogra> it needs teh CD
<fabbione> that's a bug
<ogra> s/teh/a/
<pitti> cjwatson: do you want OEM configurator bugs filed directly against oem-config or d-i?
<pitti> cjwatson: (it messes up the locale)
<ogra> fabbione: feel free to file it ... but it was never intended that its used for non Cd installs ... so its rather a whishlist bug :)
<cjwatson> pitti: oem-config
<pitti> mdz: re usplash> might be special for the amd64/nvidia usplash (which is just gray)
<cjwatson> pitti: hopefully oem-config should get a lot less crap with simplify-oem-install or whatever the spec is called; planning on merging it into ubiquity
<fabbione> ogra: what package would that be? and no it's not wishlist.. i might have a local mirror from where to install a bunch of servers.. why on earth would i want to download an extra cd?
<pitti> the original locale was de_DE.UTF-8, but it changed it to de_DE
<pitti> ...@euro
<ogra> fabbione: it was written for edubuntu CD installs in first place ... i simply never had a request for it to work in netboot installs ... 
* ogra goes for some food while the amd64 install runs
<janimo> pitti: do all apps put their tranlations in language-pack-XX-base by default? I wonder why system-config-printer has no .mo files in there
<pitti> janimo: it might not have been imported in time, no idea
<fabbione> ogra: well you still didn't answer my question.. against what package you want the bug?
<iwj> pitti: Sorry, I think I may have just trashed your edit on TestingCurrent.
<pitti> yup, just saw it
<iwj> tfheen: Is there going to be a 20061024 DVD ?
<iwj> pitti: Should I redo my edit or are you merging ?
<pitti> iwj: already fixed
<iwj> Ta
<mdz> we believe we've isolated bug 60938 and it justifies building a new livefs
<Ubugtu> Malone bug 60938 in linux-restricted-modules-2.6.17 "ath_hal missing from modules.dep" [High,Confirmed]  http://launchpad.net/bugs/60938
<Keybuk> publisher running again
<amep> I am testing the Edgy 20061024 (15:51) AMD64 desktop install disk. When I start it I get an error message from GNOME: "There was an error starting the GNOME Settings Daemon. [...]  Activation of org.gnome.SettingsDaemon timed out [...] "
<amep> Where could I get more info to attach to a bug report? The message itself doesn't seem that useful.
<Keybuk> update-initramfs scares me
<Keybuk> I swear that it just picks a random kernel off the disk
<mvo> pitti: language-support-en is installed here (edubuntu/live install)
<mvo> firefox has no launchpad-integration support anymore? known?
<mvo> oh, sorry
<mvo> I take that back
<pitti> mvo: I answered 'no' on 'download complete language support' (since I had no network), that was the problem
<mvo> pitti: aha, ok
* mvo reboots to test another cd, bbl
<Keybuk> pitti: "why doesn't it do this if I tell it not to" ?
<pitti> Keybuk: that's not the point, language-support-en should always be installed
<pitti> Keybuk: the problem is that the question is confusing and doesn't do just one thing
<pitti> 'download complete support for your [German]  language' != 'do not install any language-* at all, even if available on the CD'
<Keybuk> I like the fact that message is always in English
<Keybuk> just to drive the point home
<Nafallo> haha
<ogra> fabbione: ltsp-client-builder is a part of ltsp ... file it against that ...
<Keybuk> faster pussycat, publish...publish...
<shackan> Keybuk, it does? (update-initramfs just updated the generic kernel, while I'm using 686)
<Keybuk> shackan: it did? oh good
<Keybuk> we don't know why that does that yet
<Keybuk> other than it might be locale specific
<shackan> scary
<nixternal> heh, now i know why my kernel went back to generic yesterday..messing with usplash, i did update-initramfs
<Keybuk> kernel went back to != this bug
<Keybuk> that's just a grub order
<pitti> ogra: ouch, sorry, just broke your lock
<pitti> bah, this note should really be flashing red, not in the same gray as the normal one
<ogra> pitti: unless you test edubuntu that should do no harm
<pitti> no, I didn't
<Riddell> \sh_away: I don't think Kamion is from the US
<sfllaw> $
<mdz> 
<Keybuk> 
<abattoir> 
<Nafallo> mdz: moved? :-)
<mdz> no more so than usual
<Nafallo> oki :-)
<pitti> mdz: so we're going to have new live CDs? shall I mark the current ones as obsolete in Testing/Current, so that testing focuses on alternates for now?
<Keybuk> we'll need new alternates too
<pitti> Keybuk: hmkay; there go 3.5 hours of testing, but the bug seemed bad enough
<tfheen> iwj: there'll be a dvd, yes.
<iwj> tfheen: Right.  Well, I think I'll pick that up tomorrow.
<fdsd> hey guys, what is more reliable? rsync -av or cp -av on a dying drive?
<jcole> why doesn't ubuntu have this feature -> http://www.thecodingstudio.com/opensource/linux/screenshots/original/Fedora%20Core%206/44.gif
<LaserJock> jcole: rough guess, people haven't coded/ported it yet?
<mvo> sfllaw: do you have a test-system with a intel ICH6 or ICH7 ide chipset?
<Burgwork> jcole: that is system-config-xfree86
<mvo> sfllaw: I wonder if you can reproduce #66779 on it? the bug might be releated to the hardware that is used
<Burgwork> jcole: it needs to be tested and then ported
<Arador> anyone has a clue about #67957 , is something expected to happen in dapper -> edgy so that it only behaves OK in clean installs?
<jcole> Burgwork: oh ic, this is some special redhat app... not gnome
<Riddell> how do I do the validity check on the power pc CDs?
<Burgwork> jcole: system-config might be a good place to start with that umbrella stuff
<mantiena-baltix> pitti: hi
<mantiena-baltix> pitti: what you think about updating language packs today or tomorow ?
<pygi> mantiena-baltix: I think it won't happen :P
<mantiena-baltix> pygi: so, Polish and Lithuanian f-spot and other language fixes will not be into final edgy version...
<pygi> mantiena-baltix: seriously doubt it ^_^ But I'm not the one in charge :P
<pitti> mantiena-baltix: it won't happen
<pygi> yay, I was correct for once :P
<pitti> mantiena-baltix: next round of updates will be at start of November
<rmjb> hello, if I delete my initrd from /boot will I get it back by running update-initramfs -c?
<sfllaw> mvo: Yeah, we do.
<sfllaw> mvo: Let me ask cr3.
<mvo> sfllaw: thats great, thanks. I will try to reproduce the problem here again with my local test-machine
<cjwatson> Riddell: boot with 'check'
<sfllaw> mvo: It's the same machine as was reported by Marc.
<keescook> should there be an "Examples" folder in the edubuntu live CD?
<Riddell> cjwatson: hmm, that's what I guessed and tried on the DVD, I'll give it another shot though
<sfllaw> mvo: I can try to reproduce and run tests, if you like.
<mvo> sfllaw: great! I really wonder if a install works fine on this
<ogra> hmm, my laptop hardlocks with the broadcom driver loaded 
<ogra> (amd64) 
<sfllaw> mvo: Are there any options you want me to pass in to get more verbose logs?
<mvo> sfllaw: no, if it is really a kernel problem then the dmesg output should be enough
<cjwatson> tfheen: any idea how the rebuilds are going?
<sfllaw> mvo: There's already a dmesg from that machine in the bug report.
<cjwatson> keescook: yes, should be on the desktop
<cjwatson> not a huge deal if it isn't, although it would be a bug
<ogra> not on edubuntu, no
<cjwatson> oh, you're right, example-content isn't in edubuntu-desktop
<cjwatson> keescook: ogra's correct, ignore me
<keescook> cjwatson, ogra: okay, good.  no new bugs.  :)
<ogra> if we ship on 2 CDs and its still missing then it will be a bug :)
<ogra> hrm ...
<ogra> dropping the sbcm firmware makes the amd64 install boot just fine ...
<ogra> *bcm
<ogra> woah
<ogra> who translated my FUSE entry in the users and groups tool to german ...
<ogra> that became a horrible long sentence ...
<sladen> * bdale and various people are around west ken/shepard's bush for dinner
<mvo> cjwatson: I would like to reopen bug #66779 because I got it with two different CDs (one burned with low-speed and check ok on a brand-new cdrom)
<Ubugtu> Malone bug 66779 in ubiquity "Ubuntu 6.10 Desktop for i386 installation crashes on zlib_inflate_codes" [Undecided,Rejected]  http://launchpad.net/bugs/66779
<cjwatson> mvo: please reassign it to the kernel; I can't fix it
<cjwatson> interesting that it's certain chipsets
<cjwatson> we may have to release-note that :(
<mvo> cjwatson: the data is still sparse, but it looks like it. unfortunately (if the assumption is true) it is the kind of chipset you find in most modern laptops
<cjwatson> mvo: does the alternate CD work on those laptops?
<cjwatson> if so we have a documentable workaround
<mvo> cjwatson: not sure, I need to check that. I'm waiting for sfllaw to confirm on a lap machine
<sfllaw> mvo: Apparently, it's unreproducable now.
<sfllaw> 16:41 < cr3> sfllaw and EtienneG: go right ahead with that VAIO, I haven't been 
<sfllaw>              able to reproduce the problem. I've been testing 20061024.1 which 
<sfllaw>              has not had a problem so far.
<mvo> sfllaw: it happens for me during the fs-copy (at around ~40-50%)
<cjwatson> it's probably somewhat random
<cjwatson> I was suspecting failure of squashfs to deal with short reads earlier, but I was really just thinking out loud
<cjwatson> careful analysis of the various oopsen might well help
<Sp4rKy> hi
<Sp4rKy> please, i want modify the initramfs file which is in the live cd (casper/initrd.gz), what's the way ? gzip -d initrd.gz , cpio -i < initrd , and after ?
<Sp4rKy> for recreate it ?
<keescook> pitti: you already made note of the busted "rescue" mode, yes?
<pitti> keescook: in the sense that it hangs after exiting the rescue shell, yes
<pitti> that bug is there for ages
<cjwatson> BenC: I'd appreciate your feedback on those zlib_inflate* oopsen as soon as you can
<cjwatson> mvo: could you tell mdz about your findings when he returns? I believe that he and Scott are having dinner
<keescook> pitti: on edubuntu (PPC), the rescue mode just flat fails to start.
<keescook>  /devicepath/install/powerpc/vmlinux: Unknown or corrupt filesystem
<Sp4rKy> please, some help about the way to compil an initramfs systeme
<pitti> keescook: I didn't see that yet, please discuss with cjwatson and file a bug
* keescook nods
<tfheen> cjwatson: all rebuilds with the exception of dvds are done.
<BenC> cjwatson: ok
<tfheen> iwj: dvds are building now, they'll be done in an hour or so, iirc
<visit0r> I tested upgrade from dapper to edgy, now my DVB devices are not detected...
<visit0r> known issue?
<visit0r> in addition, a whole bunch of python packages are kept back
<keescook> cjwatson: I didn't see any obvious duplicates, so I filed bug 68077.
<Ubugtu> Malone bug 68077 in Ubuntu ""rescue" fails to load kernel on PPC edubuntu Desktop CD" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68077
<visit0r> never mind, sudo /etc/init.d/udev restart made them appear again
<jdong> wasn't there some talk earlier today about dysfunctional rescue mode?
<jdong> probably a different issue
<pitti> yes, indeed
<jdong> never mind my rambling :)
<pitti> jdong: that was me trying to use rescue mode on a totally blank disk
<jdong> pitti: LOL, ah , I see
<jdong> I guess rescue mode ain't that magical
<keescook> this disk passes disk check, I'll snag the .3 alternate and see how it behaves too
<KurtKraut> cjwatson, are you there ?
<pitti> tfheen: it is correct that alternate 20061024.2 does *not* yet have the new initramfs-tools?
<tfheen> pitti: which new initramfs-tools?
<pitti> tfheen: 0.69ubuntu19, with the fix for bug 60938
<Ubugtu> Malone bug 60938 in linux-restricted-modules-2.6.17 "ath_hal missing from modules.dep" [High,Confirmed]  http://launchpad.net/bugs/60938
<tfheen> pitti: I have not approved any upload which fixes that bug.  At least I can't remember having done so
<pitti> the images are quite fresh, that's why I wondered
<honzasch> Hi, first time here. May I have just a small comment to some glitches in Czech localization of edgy installer or not good place or time now?
<pitti> tfheen: somebody must have, I just got it though dist-upgrade
<tfheen> honzasch: I'm sorry, but it's way too late to change that now.
<pitti> tfheen: and mdz wanted new images for this bug
<keescook> pitti: I didn't have the 0.69ubuntu19 update on my 20061024.2 edubuntu (it downloaded after install)
<honzasch> OK, no problem.
<pitti> tfheen: the new desktops (24.5) have that new version
<pitti> keescook: right, that's what I'm saying; the newly spun Ubuntu alternates don't have it, but desktops have
<tfheen> pitti: I can't see any discussion of that here, and mdz have not said anything about this to me, by email or by phone.
<pitti> tfheen: so you didn't spin the 20061024.2 alternate images?
<pitti> anyway, /me goes to bed now and tests the new images tomorrow, assuming that there will be yet another alternate rollout
<Lure> tfheen: 07:51	mdz	we believe we've isolated bug 60938 and it justifies building a new livefs
<Ubugtu> Malone bug 60938 in linux-restricted-modules-2.6.17 "ath_hal missing from modules.dep" [High,Confirmed]  http://launchpad.net/bugs/60938
<Lure> tfheen: from http://people.ubuntu.com/~fabbione/irclogs/ubuntu-devel-current.html
<tfheen> Lure: thanks.
<tfheen> I'm so not happy about that, but I'll discuss that with mdz in the morning.
#ubuntu-devel 2006-10-25
<mdz> evening
<mdz> tfheen: is that you building dvds?
<mdz> tfheen: I did a full set of desktop CD builds, but only ubuntu for alternate
<mdz> tfheen: we need new alternate builds all around
<mvo> mdz: have you seen bug #66779 already? it seems to prevent me from installing edgy one of my test-systems. i have no idea if this is a real problem or just affect some machines/hw configurations
<Ubugtu> Malone bug 66779 in linux-source-2.6.17 "Ubuntu 6.10 Desktop for i386 installation crashes on zlib_inflate_codes" [Undecided,Confirmed]  http://launchpad.net/bugs/66779
<mdz> mvo: so far we have no compelling data; the problem seems media related but more sensitive to random access than sequential
<mdz> it curiously seems more common now than at beta, but the relevant kernel bits are unchanged
<mvo> right. I just wanted to be sure that you know about it because it hit me with two different CD-Rs on the same machine
<mvo> lets wait for sfllaw and see if he can reproduce it
<mvo> but I need to catch some sleep now :)
<sfllaw> I'm almost done grabbing the new images.
<dcstimm> hey guys, I am looking to remove the "Press Enter to shutdown" question at the end of the livecd shutdown, do you guys know where that script is located?
<dcstimm> nevermind
<zMott> is there a way to display full meta data on photo's or music...etc by moving the mouse over the file..
<dcstimm> do you guys know what initrd file the shutdown files are read from the one in /boot/initrd.gz or the one on the root of the cd in /casper?
<dcstimm> for the livecd?
<BenC> cjwatson: ping
<cjwatson> BenC: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
<BenC> I hate these auto-ping-replies
<Nafallo> :-)
<BenC> cjwatson: is live-cd using squashfs v3 or v2 format?
<ogra_> keescook, you saw bug 66726 on powerpc ?
<Ubugtu> Malone bug 66726 in edubuntu-artwork "edubuntu artw ork has funny colors on amd64" [Low,Fix released]  http://launchpad.net/bugs/66726
<keescook> ogra_: correct.  usplash on edubuntu both live and install CDs still had busted colors
<ogra_> keescook, with exactly the same effect as shown in the screenshot ? 
<ogra_> i nearly cant belive that since we dont use 16 colors in ppc
<dcstimm> hey guys, where is the shutdown script in the initrd file for knot3?
<dcstimm> livecd
<keescook> yes, though the picture isn't very crisp
<dcstimm> I have been searching all though initrd and I cant find it
<dcstimm> I found it in 6.06
<dcstimm> but not in knot3
<keescook> ogra_: this is on my G4 PowerBook.  What would you like me to pull for details/debugging?
<ogra_> keescook, its fine on my G4 ibook and i wouldnt know why the 16 color pic should be used on any powerpc ...
<ogra_> thats a bit irritating ... especially since the picure is nearly completely black since yesterday
<ogra_> (the 16 color variant)
<keescook> hmm
<ogra_> its a bit weird that you see an amd64 specific bug there
<keescook> might be nv-specific?
<ogra_> could you try to take a pic with a digicam or something like that and attach it to the bug  ?
<dcstimm> anyone know?
<keescook> ogra_: sure thing.  I just need to find my camera charger. :)
<ogra_> well, its fixed for michael ... so i doubt its nv specific
<keescook> actually, now that I'm watching closely, the usplash goes completely away (except for the progress bar) after a little while.  I didn't notice that during the initial test (doing too many things at the same time, it seems)
<keescook> everything goes black except the green progress bar.  I'll snap a pick of that too
<ogra_> oh
<ogra_> thats another bug
<keescook> so I've got two bugs now.  :)
<ogra_> you mean while the bouncing progressbar is active ?
<keescook> yup
<keescook> but before that the colors are trashed.
<ogra_> yep, i saw that too and heard about it from ubuntu users as well
<ogra_> hmm
<ogra_> its supposed to look like that: http://people.ubuntu.com/~ogra/usplash_640_480.png
<dcstimm> Do you guys know what file in the initrd file controls ejecting the cd when shutting down the ubuntu livecd?
<keescook> dcstimm: I don't, sorry.  :(
<dcstimm> it used to be /lib/casper/shutdown
<dcstimm> now I have no clude
<ogra_> keescook, its not urgent btw, i doubt we'll have many rebuilds of the CDs before tomorrow and will fix the bug through upgrades post release ...
<dcstimm> clue
<jaebird> I just wanted to let y'all know about the kernel panic i have in the i386 desktop live cd. it is all in bug 63283
<Ubugtu> Malone bug 63283 in ubiquity "Live CD will not boot on my PC." [Undecided,Needs info]  http://launchpad.net/bugs/63283
<keescook> ogra_: okay.  I'll upload pictures tomorrow.  Do you want any lspci or similar output?
<ogra_> might make sense ... 
<keescook> wow!  I can eject the CD while the livecd is running.  Hah.  oops
<ogra_> keescook, known problem ...
<ogra_> pitti enabled unlocked CD drives for the desktop in general because so many people complained :)
<ogra_> now we'll have many people complaining that they can eject the live CD :)
<ogra_> hmm, i thought we were supposed to have new isos 
<dcstimm> anyone know where the option to press enter (when shutting down) is on the new livecds?  I want to remove that
<Nafallo> ehrm, why?
<dcstimm> because its not working for me
<dcstimm> in 6.06 it was easy I just removed read x > /dev/console
<dcstimm> in knot3 and rc I cant figure it out
<Nafallo> okidoki
<dcstimm> any idea?
<Nafallo> no
<ogra_> ok, no new isos to test .. then i'll take some hours of sleep ... 
<keescook> ogra_: should the artwork bug be reassigned to usplash?
<keescook> (or a new bug opened?)
<dcstimm> anyone know why they switched from a nice progress bar that moved from left to right to one that moves back and forward a million times with usplash boot?
<Fujitsu> dcstimm: because the progress bar didn't move at a reasonably constant speed.
<dcstimm> Fujitsu, yeah but now I have no idea if its really doing anything
<dcstimm> Fujitsu, is that setting inside the usplash-artwork.so file?
<dcstimm> so if I removed that file and inserted one from before would it still act the same?
<Riddell> doko_: please test kubuntu amd64 dvd text install, I've had it fail with the same corrupt package on two dvd media so I'd like someone to check it
<jdong> dcstimm: huh? when did this happen?
<jdong> did I miss something?
<jdong> mine only seems to move forward
<dcstimm> jdong, in rc
<jdong> though I gotta admit it'd be alot more entertaining if it went both ways
<jdong> dcstimm: hmm, really....
<jdong> my progress bars seem to move forward only
<dcstimm> jdong, I have showed it to ALOT of people and they dont like it
<dcstimm> jdong, iv only used the ppc livecd 
<jdong> no kidding, if it goes back and forth nobody's gonna like that
<dcstimm> jdong, maybe its a livecd only thing?
<jdong> I'm using i386
<jdong> maybe it's a livecd thing
<jdong> on the final installs for amd64 and i386, I haven't noticed that behavior
<dcstimm> weird
<dcstimm> Im wondering if I use a old knot3 usplash file if it would change that
<dcstimm> iv made a couple with different graphics
<dcstimm> jdong, any idea where the script is located that controls the shutdown of the ubuntu livecd?  Lately its been broken, in knot3, its all black but you have to press enter to have the machine to shutdown, in rc, it comes up with usplash_write text saying to press enter but it doesnt shut down the computer..
<dcstimm> so I have settled with knot3 for now, and I want to go in and remove the option to have to press enter
<jdong> I don't know...
<jdong> should be all in rc6.d
<dcstimm> with in the filesystem.squash or initrd file?
<jdong> I'd guess filesystem.squash
<dcstimm> ok
<bddebian> Howdy
<dcstimm> jdong, found it, its inside of /etc/init.d/casper
<jdong> bddebian: it seems like the azureus god has done his work :D
<bddebian> jdong: I saw that :-)
<jdong> too bad there's still no tray icon
<jdong> fix that :)
<dcstimm> jdong, thanks for the tip, I didnt realize that they had moved it from the initrd file to the local fs
<bddebian> jdong: Your fingers broke or something? :)
<dcstimm> bddebian, lol
<jdong> bddebian: my fingers don't work with java
<bddebian> heh
<jdong> bddebian: and chances are if I touch it the whole main window will disappear too!
<Hobbsee> tfheen: how frozen is universe
<Hobbsee> ?
<Chad110> hey guys, got a quick rdiff-backup question
<Fujitsu> Hobbsee: I'm pretty sure we're as normal for the past week (ie. approval by UVF team for everything).
<Hobbsee> Fujitsu: edgy releases tomorrow, the archives close at some point
<Fujitsu> main closed yesterday, universe is still open for a while yet, I believe.
<Hobbsee> right
<Fujitsu> Ask ajmitch, he's the resident god in this timezone.
* Hobbsee pokes ajmitch 
<ajmitch> watch it..
* Hobbsee watches it
* Hobbsee stops, and pokes ajmitch again
<Hobbsee> ajmitch: when does universe freeze?
<ajmitch> I haven't heard
<Hobbsee> awwww
<ajmitch> probably when I'm told that they won't accept any more
<Hobbsee> heh
<Fujitsu> I'd presume it'd really be at dholbach's disgression, although probably a few hours before release to let the mirrors get into a consistent state.
* Fujitsu curses au.a.u.c for being inconsistent all the time.
<zul> oh goody i can upload another xen kernel hah!
<Hobbsee> zul: *g*
<Hobbsee> Fujitsu: i found a better mirror than that
<ajmitch> zul: what do you want to break now? :)
<Hobbsee> ajmitch: everything, as usual
<Fujitsu> Hobbsee: which do you use?
<Hobbsee> Fujitsu: deb http://mirror.pacific.net.au/ubuntu edgy main restricted universe multiverse
<Fujitsu> You could have just said pacific.net.au :)
<Fujitsu> They're in sync, are they?
<Hobbsee> seems to be *fairly* up to date - i've not found anything that it doesnt have
<Hobbsee> afaik, yes
<Hobbsee> Fujitsu: i could have - but i had to look it up
<Fujitsu> The official one often fails to update for a day or two, or has a newer Packages without the actual debs...
<Hobbsee> yeah, i noticed that
<Hobbsee> annoying thing
* Hobbsee is off for a while
<tom47> where are the desktop backgrounds stored in ubuntu?
<tritium> tom47: /usr/share/backgrounds
<tritium> also see /usr/share/pixmaps/backgrounds
<tom47> ty
<tom47> what colour depth are they in general?
<tom47> i ask because when the screen'dims' as part of logging out it looses "smoothness" in graduations of colour and i was wondering why
<fabbione> morning
<zul> hey fabbione 
<fabbione> hi zul
<whiprush> mdz: is there anything blocking on getting NetworkAuthentication approved for -mtv? What are we missing?
<cjwatson> BenC: we just call mksquashfs with no (interesting) options; IIRC that's v3
<BenC> cjwatson: I'm pretty sure I found the bug, and it's fixed upstream
<BenC> it describes it as a rare problem with SMP + multiple squashfs mounts
<cjwatson> BenC: we've seen it on UP too, I'm afraid
<cjwatson> though there might be multiple problems
<BenC> cjwatson: Basically it was using a single data set to keep track of streams to zlib, and it was trumping it with bad data
<BenC> cjwatson: There were about 6 other bugs of lesser degree mentioned in the upstream changelog
<BenC> one other one was huge stack usage, that's now being handled with dynamic data allocations
<cjwatson> BenC: can you mail me references to the patches, and I'll discuss with mdz when I get to the office?
<BenC> deep stack usage could also cause problems, but I'm not sure it is the same thing
<BenC> I can email you the diff I applied to the edgy kernel for squashfs
<cjwatson> BenC: I think we'll probably release what we've got and try to publish an -updates CD ASAP that people can use if they're having problems
<BenC> it's pending if you decide an upload is warranted
<BenC> cjwatson: Basic work around I think is "use the alternate CD"
<cjwatson> but that depends on how widespread the breakage is
<cjwatson> BenC: right, if that's a workaround, that's great
<cjwatson> mvo thought earlier that ICH6/ICH7 systems were affected
<cjwatson> which scared me into suspecting something at the disk controller layer
<BenC> no, I suspect those are just the more common dual core machines
<cjwatson> if it's isolated to squashfs, then indeed we can just recommend the alternate CD
<pitti> Good morning
<cjwatson> BenC: yeah, if you can e-mail me that diff, that would be good, thanks
<cjwatson> BenC: I'll get to the office within 3 hours from now; will you still be around?
<cjwatson> BenC: if not, could you upload that kernel so that it can sit in the unapproved queue?
<pitti> cjwatson: the alternate CD is still out of date (20061024.2 has the very same .debs that .1 has, it didn't pick up the new initramfs-tools); can you please spin new images so that testing can continue?
<cjwatson> then we'll have the option ... we might well reject it
<cjwatson> pitti: building
<cjwatson> in screen - I'm about to get a train
<BenC> cjwatson: current git has two other patches in it...one is a headers_install fix for ia64 (touches nothing non-ia64), and the other is the addition of pata_marvell, which is a case of, it doesn't work now because we don't have a driver, so adding it can't hurt
<pitti> cjwatson: cheers
<BenC> cjwatson: I email the diff for squashfs, and the changelog, and upload
<pitti> sfllaw: ping
<sfllaw> pitti: Pong.
<sfllaw> How can I help you?
<pitti> sfllaw: we have new alternate and desktop CDs, I upgrade the matrix now
<pitti> sfllaw: shall I just clean out all the results so that it's easier to read, or use 2006old-pass?
<pitti> tfheen: we need new server images (due to new initramfs-tools), I'm going to mark it as out of date in T/C for now
<pitti> tfheen: likewise Kubuntu DVD
<khext> doko_: ping?
<pitti> tfheen: rest of {,k,ed}ubuntu is current
<tfheen> pitti: thanks.
<doko_> khext: ?
<khext> doko_, hi, can i talk with you in private?
<sfllaw> pitti: Oh.
<Kagou> hi
<sfllaw> pitti: Sorry, got in a conversation.
<pitti> sfllaw: I keep the results and use the 'old' syntax for now
<sfllaw> pitti: The instructions on Testing/Current say to drop PASSes that don't have comments.
<pitti> sfllaw: ah, I see
<tfheen> Hobbsee: I don't do universe, talk to dholbach or ajmitch or somebody.
<pitti> whoa, editing this page is real work
<Kagou> doko_: can you please have a look at Bug #66519 (for confirmation or workaround)
<Ubugtu> Malone bug 66519 in openoffice.org "form and queries wizard (Oo Base) don't work" [Medium,Unconfirmed]  http://launchpad.net/bugs/66519
<Hobbsee> tfheen: okay.  i thought you might know anyway :_
<Hobbsee>  * :)
<sfllaw> Has anyone else experienced the installation CD not rebooting when it claims it should?
<mvo> sfllaw: I have seen this too
<mvo> sfllaw: thanks a lot for your testing on the vaio, good that you can't rerproduce it
<sfllaw> mvo: Have you filed a bug?  I can't find one in Malone, but it might be reported anywhere.
<sfllaw> mvo: No, I did on the fifth try.
<mvo> sfllaw: no, it was very late yesterday when I have seen it
<sfllaw> mvo: See bug 65106.
<Ubugtu> Malone bug 65106 in linux-source-2.6.17 "oops in zlib_inflate_fast" [High,Fix committed]  http://launchpad.net/bugs/65106
<sfllaw> I don't know if the new desktop CD has a fix for this, though.
<mvo> probably not yet
<doko_> Kagou: the queries wizard does work for me, both java runtimes
<pitti> ok, test matrix is cleared and has updated timestamps
<Kagou> doko_: forms wizard also ?
<dholbach> good morning
<Kagou> hey dholbach 
<sfllaw> dholbach: Morning.
<dholbach> hey Kagou
<dholbach> hiya sfllaw
<dholbach> how's it going guys?
<sfllaw> New CD.
<sfllaw> More rsyncing.
<dholbach> apart from the squashfs issue something we really need to worry about?
<sfllaw> It's all good.
<Kagou> doko_: i look if it's a localisation (french) problem
<Kagou> doko_: are you using the same version like me or your updated (2.0.4-2ubuntu0) version of oo ?
<dholbach> sfllaw: you heard of a test kernel with the squashfs fix?
<infinity> dholbach: Mind if I do a last-minute fix to apache1.3, and then execute that UVF php4 merge (for security patches and such)?
<sfllaw> dholbach: No, I haven't.
<infinity> (Yay for spending the last two weeks on main and ignoring universe completely... Go Adam)
<dholbach> infinity: i'm your no1 fan if you do
<sfllaw> dholbach: Hmm.
<sfllaw> dholbach: BenC mentioned one in http://launchpad.net/bugs/65106
<Ubugtu> Malone bug 65106 in linux-source-2.6.17 "oops in zlib_inflate_fast" [High,Fix committed]  
<doko_> Kagou: yes
<dholbach> sfllaw: yes and it's "fix committed"
<sfllaw> I presume it's in the archive, then.
<dholbach> no, there was no kernel upload for a while
<dholbach> it's "fix committed" not "fix released"
<sfllaw> Oh, sorry.
<dholbach> I thought YOU of all knew that ;-)
<sfllaw> You're right.
<dholbach> i hope there'll be a test kernel :-/
<sfllaw> I hope so too.  It would be pretty bad if the squashfs thing got released.
<mvo> lets wait for the release managers, but I will happily test any fix. my machine seems to be a good test-candidate :)
<pitti> sfllaw: so, better to hold off CD testing until we get new images with that fix?
<dholbach> mvo: same here
<pitti> since we tested yesterday's pretty thoroughly and today we just have the new initramfs-tools, it wouldn't make sense to fully test them all if they will be thrown away anyway
<dholbach> pitti: I think BenC is in bed now - so it'd take a while to get it uploaded, no?
<sfllaw> pitti: Upsettingly, I think so.
<pitti> dholbach: right, that's a problem, but doesn't change the testing situation
<dholbach> pitti: yeah, right.
<sfllaw> A new kernel definitely requires going through everything.
<sfllaw> :(
<pitti> so if tfheen wants that fix in maybe we should phone Ben out of bed
<sfllaw> tfheen: Ping?
<pitti> fabbione: or, do you know how to handle this kernel upload?
<dholbach> sfllaw: he went for a dogwalk
<sfllaw> BenC was around an hour ago.
<sfllaw> But I guess he isn't any more.
<fabbione> pitti: sorry?
<sfllaw> It is pretty late.
<fabbione> pitti:  i wasn't paying attention to IRC
<pitti> fabbione: we need a new kernel upload to fix bug 65106
<Ubugtu> Malone bug 65106 in linux-source-2.6.17 "oops in zlib_inflate_fast" [High,Fix committed]  http://launchpad.net/bugs/65106
<pitti> fabbione: it's holding up new CDs and thus testing
<fabbione> pitti: BenC did upload already.. it should be in the queue
<pitti> ah, cool
<dholbach> oh nice
* dholbach hugs BenC
<pitti> so cjwatson only needs to approve it
<fabbione> pitti: it's waiting cjwatson, mdz and tfheen foobar
* pitti hugs BenC, too
* sfllaw hugs BenC.
<sfllaw> If only tfheen could spin images with the new kernel before approval.
<fabbione> guys do you realize that it will take AT LEAST 12 hours to get new images with the new kernel?
<fabbione> (assuming it builds)
<dholbach> fabbione: if that fixes the issue - i'm happy to test
<fabbione> dholbach: it will invalidate ALL the tests...
<fabbione> dholbach: i don't mind testing, it's just hell of a lot of work at less than 24 from release
<fabbione> and we are not sure it will fix anythihng
<dholbach> fabbione: it's not because I'm bitten by the bug - I know how to install an alternate cd or upgrade from dapper - I'm just quite sure that we've only seen the tip of the iceberg of people being not able to install
<fabbione> dholbach:  it only bites on SMP or CoreDuo machines.
<sfllaw> If people get random errors in the middle of install, it will all be filed against Kamion.
<sfllaw> fabbione: Dude, do you know how many Core Duo machines there are out there?
<sfllaw> Every laptop manufacturer has basically jumped on this chips.
<fabbione> sfllaw: no, i don't have one yet.. want to ship me one?
<sfllaw> I wish I could.
<sfllaw> But they can't leave this office.
<sfllaw> Want to move to Montral?
<sfllaw> It's a beautiful city.
<sfllaw> With lovely women.
<pitti> ok, let's hope that tfheen's dog returns soon, so that his owner can decide about this
<fabbione> sfllaw: <- married with a kid... and no.. i don't like Canada :)
<sfllaw> Hey, it's OK to look.
<sfllaw> You told me that yourself.
<sfllaw> I distinctly recall.
<fabbione> ahahha
<dholbach> fabbione: i don't use an smp machine and it still happens to me... we use an smp kernel for everybody, no? 
<sfllaw> Yes, we do.
<sfllaw> The laptop I have here is a Core Duo, though.
<fabbione> dholbach: do you have a coreduo or dual core or Core duo?
<fabbione> or whatever.. something with more than one core
<fabbione> or more than one thread
<carlos> pitti: ping
<dholbach> fabbione: no, I don't - it's a p4
<pitti> carlos: pooonngggg
<tfheen> BenC: we have the problem on UP systems too, AIUI.
<carlos> pitti: I just fixed edgy-updates
<carlos> not sure whether your script already failed
<pitti> ah, right, I need to fix my scripts
<fabbione> dholbach: time to upgrade? :P
<carlos> pitti: we have already 500 updated .po files
<dholbach> fabbione: to have the same issue again? no, don't think so
<fabbione> ehhe
<Kagou> doko_: in fact query and form wizards run well if i remove sun-jre and use the 1.4.2 fsf java implementation
<Kagou> i edit the bug
<doko_> Kagou: ohh?
<doko_> Kagou: yes, you're right ...
<Kagou> doko_: i'v changed description of Bug #66519
<Ubugtu> Malone bug 66519 in openoffice.org "query wizard (Oo Base) doesn't work with Sun 1.5.0 java" [Medium,Confirmed]  http://launchpad.net/bugs/66519
<Kagou> doko_: thank you for confirmation :)
<mdz> morning
<pitti> hi mdz
<dholbach> good morning mdz
<mdz> pitti: I am not very convinced by the SMP explanation for 65106
<mdz> errors like that have been seen on uniprocessor systems as well
<pitti> mdz: *having no idea*, WFM
<Keybuk>   112996 | S- | camorama             | 0.18-0ubuntu1        | 19 minutes
<Keybuk>          | * camorama/0.18-0ubuntu1 Component: universe Section: gnome
<Keybuk>   112995 | S- | linux-source-2.6.17  | 2.6.17-10.34         | 1 hour 50 minutes
<Keybuk>          | * linux-source-2.6.17/2.6.17-10.34 Component: main Section: devel
<Keybuk> tfheen: ^
<Keybuk> dholbach: ^
<dholbach> Keybuk: camorama fix is good - please approve
<dholbach> Keybuk: upstream gets n+1 duplicates filed about crashes in ubuntu that are fixed in that version
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/daily/edgy-updates/ WOO!
<carlos> pitti: ;-)
<carlos> stub: hi, could you give me a patch number and db review for https://devpad.canonical.com/~jamesh/pending-reviews/carlos/launchpad/bug-2322/full-diff ?
<carlos> stub: jamesh did already the code review 
<carlos> so I just need the db number to merge it
<jamesh> carlos: wrong channel
<carlos> hmm
<carlos> right...
<carlos> jamesh: thanks ;-)
<tfheen> fabbione: ubuntu-server done.
<tfheen> kubuntu dvd done.
<tfheen> sfllaw: ^^
<fabbione> tfheen: ok thanks
<sfllaw> tfheen: Merci.
<doko_> tfheen: the second kubuntu DVD today?
<tfheen> doko_: hmm?  It should be the first one, iirc.
<doko_> tfheen: but about 1hour ago?
<tfheen> doko_: oh, I might have taken a bit to notice it was done, yes.
<doko_> ok, got the right disc
<mdz> dholbach: it's time to stop accepting uploads for anything but a showstopper, including universe.  we should have dedicated access to the publisher if we need to act quickly
<dholbach> mdz: alright, will pass it on
<infinity> mdz: I had one security/ftbfs upload for php4 in universe pending for dholbach that I was about to upload, should I just scrap that?
<mdz> infinity: yes please, need all eyes on this oops
<infinity> mdz: Alright.  I'll just get it shoved into edgy-security later then, or something.
<doko_> Riddell: kubuntu DVD text install works for me, both yesterdays and todays DVDs
<cjwatson> mdz: FWIW, I've reviewed the proposed squashfs diff (FWIW since I'm fairly kernel-illiterate) and it does look pretty sensible - it's all switching from static or stack allocation to heap allocation, and practically nothing else
<cjwatson> mdz: would like to talk about it when you get to the office, anyway
<cjwatson> in confcall with tfheen
<mdz> cjwatson: yes, it's eminently sensible but so far we have no reason to believe that it's related to our bug
<mdz> cjwatson: tfheen is preparing a test live CD, dholbach is trying to isolate where the problem began in edgy, Keybuk is testing SMP vmware, mvo doing some other experiments
<mdz> we're not acting until we know what we're dealing with here
<mdz> I'm coming in to the office now
<pepsiman> tfheen: I have a problem with usplash-theme-ubuntu on AMD64.  The debdiff may explain it: http://rafb.net/paste/results/HawE0C96.html  Look at line 22
<pitti> pepsiman: we just fixed that
<pitti> pepsiman: (not sure whether tfheen already approved it, but it was discussed and tested)
<pepsiman> pitti: ah ok, thx
<cjwatson> mdz: yeah, I've just caught up on #canonical
<doko_> ajmitch, dholbach: please approve http://people.ubuntu.com/~doko/edgy/eclipse.debdiff, fixing crash on amd64
<Fujitsu> doko_: We're rather frozen, AFAIK...
<cjwatson> doko_: eclipse will block the buildds for some time, and we need agility right now
<cjwatson> doko_: so I'm strongly inclined not to accept that
<infinity> doko_: mdz declared universe closed for "anything but showstoppers" a few hours ago.
<infinity> Or, rather, an hour ago.
<doko_> cjwatson: ok, didn't see that. will have to go to -updates, if a window doesn't open again
<cjwatson> tfheen: that hung on the ubiquity timezone page
<cjwatson> I'll try again and check exactly what's mounted
<cjwatson> hmm, I wonder if vmware has hung; I can't reset the VM
<sivang> morning
<cjwatson> sorry, wrong channel
<sfllaw> cjwatson: I noticed that Dapper's ubiquity timezone page had a magnifying glass cursor for zooming in.
<sfllaw> But I don't notice that in Edgy's ubiquity.
<sfllaw> Did you pull that out, or is that a minor bug?
<cjwatson> it should still be there; I haven't touched that
<cjwatson> sfllaw: don't see it here either; I think it's a minor bug as a side-effect of some of the back/forward rearrangements
<cjwatson> well spotted
<sfllaw> cjwatson: Didn't even notice until I saw the old one.
<sfllaw> Shall I file?
<cjwatson> yes please
<seb128> hi
<seb128> grumpf, hate my dsl provider
<seb128> lot of packets lost and timeout all over the place since this morning
* mvo hugs seb128
* seb128 hugs mvo back
* sivang hugs seb128 and hands me a bucket full of healthy unbroken packets.
<sivang> s/me/him/, ofoucrse
<sfllaw> 9/g 25
<sfllaw> Whoops.
<dholbach> is that part of the a/s/l game or what? ;-)
<ubuntu_demon> hey :)
<sivang> hey dholbach, ubuntu_demon
<ubuntu_demon> I'm going to be more in #ubuntu-devel from now on because UDS Mountain View is coming closer. And this will be an interesting time because Edgy is almost to be released.
<sfllaw> dholbach: Yeah, I'm a "g".
<dholbach> sfllaw: I always knew it
<sivang> heh
<ubuntu_demon> dholbach: I spoke to Josh of ubuntuos.com It's a podcast by normal Ubuntu users. He's searching for some Gnome people to attend his podcast. Would you be interested if and when you have the time for it ?
<ubuntu_demon> hey sivang :)
<dholbach> ubuntu_demon: I got the mail - thanks for asking again... we're currently in the release, so please not before the release is done
<giftnudel> ah, hey sivang
<ubuntu_demon> dholbach: I didn't know josh already sent you an e-mail :). I told Josh already that it would be probably somewhere after Edgy's release if you would be interested
<dholbach> ubuntu_demon: and I'm not sure I'm 'gnome' person enough
<sivang> hi giftnudel, what's up?
<giftnudel> sivang: nothing special, what about you?
<ubuntu_demon> dholbach: by the way I'm not on the podcast. But when I spoke to Josh I thought : "maybe daniel can tell something about telepathy on ubuntuos"
<Nafallo> known that the progressbar on amd64 usplash is at the top instead of under the logo?
<Nafallo> hi btw
<sivang> giftnudel: fine, working on finishing the backup control file support , btw the bug from today that you commented I'm sure was experienced with the dapper old version.
<giftnudel> sivang: yes, although we should find a better place for the backups then .hubackup-data, maybe ~/Backups or something like that
<sivang> giftnudel: You mean, as the default in the target selector ?
<giftnudel> sivang: yes, something that an inexperienced user is likely to find
<sivang> giftnudel: each user can choose whatever suits him...that's why I feel it's not a problem the fact its a hidden folder.
<giftnudel> sivang: yes, we will see how many bug reports we will get about that
<giftnudel> sivang: it isn't really that important
<sivang> giftnudel: hmm as its a very easy and quick change
<giftnudel> sivang: I'm not talking about the temporary data, but more about the permanent storage of a finished backup
<sivang> giftnudel: right, so the temporary data will stay there, but the default in the selector should be changed, as it is auto-chosen when there are no optical media devices in the system.
<sivang> giftnudel: so better make it visible and easy to understand and find.
<giftnudel> sivang: I think changing the default would make sense, and I need to properly fix the issue with the nonexistant directory, so it gets only created if it is really needed
<giftnudel> sivang: yes, that's what I mean
<sivang> giftnudel: okay, I'll commit this change now then, re: directory missing, your one liner seems to already fix that, and create the dir only if it is needed no?
<giftnudel> sivang: no, it creates the directory everytime, even if not needed
<giftnudel> sivang: that made sense since we would have needed it anyway, but with ~/Backup, this is not true
<sivang> giftnudel: so the directory would have to be created only if the users either:
<sivang>  1) lacks an optical drive and this is selected as the default
<sivang>  2) Choose to backup there wilfully
<sivang> ?
<giftnudel> sivang: I think a more general approach like: create it if the backup is stored there (no matter how it got selected) is better
<giftnudel> sivang: you already do that in BackupEngine, so I only need to make sure, the necessary options (like slice size) is determined _after_ the directory is created (this should be easy)
<sivang> giftnudel: right, so that means we would just have to fix the free size detection code to not choke 
<giftnudel> yes exactly
* sivang hugs giftnudel
<sivang> :)
<giftnudel> I will fix this now, shouldn't be to difficult
<sivang> giftnudel: I'm starting to owe you too many beers ;)
<sivang> giftnudel: thanks
<giftnudel> sivang: no problem, as long as I'm motivated and have time, things are easy, just hope that I don't get bored:)
<sivang> giftnudel: when you do , let me know ;-) I think we've got enough so we will not get bored at least until edgy+1 opens.
<giftnudel> sivang: yes, I think so
<Nafallo> Keybuk: thanks for the quick fix :-)
<Keybuk> Nafallo: to?
<Nafallo> Keybuk: the usplash-thingie on amd64 :-)
<Keybuk> oh
* Keybuk is in the office
<Nafallo> :-)
<gnomefreak> guys is edgy's universe repo down or just having issues?
<Fujitsu> gnomefreak: what do you mean by down?
<fabbione> gnomefreak: closed basically
<gnomefreak> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/edgy/universe/binary-i386/Packages.gz  Sub-process gzip returned an error code (1)
<gnomefreak> during update
<gnomefreak> closed for uploads yes but should still run normally with apt-get
<Fujitsu> That's not uncommon... But it really shouldn't be happening now.
<Fujitsu> Maybe wait a few minutes...
<elmo> that is uncommon
<gnomefreak> its been like this for last 3ish hours
<elmo> that should not happen on archive.ubunut.com - ever
<Fujitsu> elmo: Sure?
<elmo> Fujitsu: yes
<elmo> it's also not reproducible for me
<Nafallo> or for me
<Fujitsu> Hm, I'm sure I've seen it before... Maybe just a local issue like gnomefreak is having now, as it's not reproducible for me either.
<gnomefreak> i checked with others and they ate having same issue
<elmo> gnomefreak: try rm /var/lib/apt/lists/archive.ubuntu.com* as root and try again
<mvo> gnomefreak: a proxy issue maybe?
<elmo> if it happens again, you have a broxen (perhaps transparent) proxy between you and archive.ubuntu.com
<gnomefreak> looks better
* gnomefreak dont use proxy
<giftnudel> sivang: http://paste.ubuntu-nl.org/28236/
<elmo> gnomefreak: your ISP might
<gnomefreak> oh good point and i was just on phone with them :(
<realist> At first glance, it looks like gzip returning the error?
<gnomefreak> realist: thats what made me think it was archives
<gnomefreak> seems to be downloading ty elmo 
<giftnudel> sivang: that should work for an instant, but I think we should put the slice size detection completely in the backup engine
<realist> Or is that just because gzip doesn't have the Packages.gz to work with?
<cjwatson> realist: sure, but that could happen if a "transparent" proxy is returning incorrect data
<gnomefreak> nope still failing
<cjwatson> apt uses byte-ranges
<cjwatson> I suspect that with the help of incompetent web servers/proxies it could be assembling bits of multiple different gzipped files
<cjwatson> which is so not going to work
<gnomefreak> i can ping it
<cjwatson> ping won't help
<realist> I didn't even know proxies were capable of doing that? :-/
<cjwatson> TBH your best bet is to wait for a bit
<gnomefreak> thats fine just thought it should be known if its not me
<cjwatson> realist: byte-range requests are hard to implement correctly, and transparent proxies are literally impossible to implement correctly
<cjwatson> doesn't stop lots of people from trying
<realist> What do you mean by byte-range requests?
<mvo> gnomefreak: you may try: "apt-get update -o Acquire::http::No-Cache=True"
<Chipzz> realist: http allows you to skip to a certain point in a file
<realist> apt doesn't request the whole Packages.gz?
<Chipzz> realist: ie, continuing a download
<elmo> MVO
<Chipzz> (err, resuming)
<cjwatson> realist: it might retry if it were interrupted part-way through
<elmo> mvo: a) can apt please put it's version  number in it's user-agent string
<gnomefreak> mvo: same
<mvo> gnomefreak: hmm
<elmo> mvo: b) can we pretty please with a cherry on top, disable pdiffs by default for edgy (via -updates)
<mvo> elmo: pdiffs are disabled in the edgy version of apt ?!? 
<elmo> mvo: our archive doesn't support them, so it's n million users x updates wasted 404 hits
<elmo> mvo: are you sure?  I'm seing hits on archive.ubuntu.com of apt users trying to use them
<fabbione> elmo: might be debian users with mixed sources.list?
<mvo> elmo: some debian users? or a backport? let me check
<cjwatson> it could be Debian users ... what fabbione said
<elmo> FREAKS
<Fujitsu> Hahahah
<fabbione> elmo: NO! USERS!
<mvo> elmo: version number>    Req += "User-Agent: Ubuntu APT-HTTP/1.3\r\n\r\n";
<elmo> mvo: that's the version number of the apt method
<elmo> mvo: the debian/ubuntu version+revision would IMO be more useful, but it's just an idea, not a big deal
<elmo> s/apt/http/
<mvo> elmo: ok
<fabbione> elmo: can i upload glibc-2.5 to all the releases? we can see immediatly who in debian uses mixed sources.list :P
<jdub> mvo: elmo's "just an idea, not a big deal" thoughts often come back as "i told you so" :-)
<mvo> elmo: about pdiff, I just checked, we haven't even merged that branch in ubuntus apt :)
<mvo> jdub: thats why I immediately added it to my todo list :)
<jdub> ;-)
<mvo> gnomefreak: can we debug that failure in ~30 min in #synaptic maybe?
<gnomefreak> mvo: thats fine 
<elmo> mvo: ok, cool, thanks - now I'll go cry in the corner about all the people trying to hybridize debian+ubuntu
<Fujitsu> elmo, that's a very good idea.
<gnomefreak> mvo: im there just let me know when is good for you. i have other things i can be working on :)
<fabbione> elmo: it might be ubuntu users that did pull a better apt-get from debian... if that makes you feel better
* mvo hugs elmo
<giftnudel> yeah, I heard rumors that newer version == faster download ...
<Fujitsu> giftnudel: so you'd better go and tell everybody to upgrade to the latest crack right away!
<giftnudel> Fujitsu: well, that seems to be that way in gentoo, doesn't it ;)
<Nafallo> giftnudel: for debian, that might be true... ;-)
<BenC> mdz, cjwatson, tfheen: From my understanding of the code changes, I think it should be possible to trigger the zstream bug without SMP
<mdz> BenC: yes, we decided the same
<mdz> BenC: but we've decided to go with a workaround in casper instead, to avoid rolling new kernels
<sivang> giftnudel: right, should work. we can move slice size detection into BackupEngine.py or better, put it in fsMisc.py as it's a general purpose functionality
<giftnudel> sivang: hmm, yes, that's a good idea to put it in fsMisc
<giftnudel> sivang: I'll see if I have time to do that right now, if not, then until monday ...
<giftnudel> sivang: if you find out a lot of cdrecords error messages, then please tell me (I need as much as I can get for the pexpect stuff)
<sivang> giftnudel: yes, if I get finished with hurestore and mime type association stuff, I'll start creating a list of those and put it on the wiki somewhere, if you have anything already pushed into your branch let me know I'll  pull and continue as well
<giftnudel> sivang: I have done the most important part already, I'm just missing the UI integration and some error messages
<giftnudel> sivang: I will publish that at some state
<sivang> giftnudel: Cool, what bits of UI intergration are you missing ?
<giftnudel> sivang: The stages I have done are Starting, Burning, Fixating, I need to somehow put this together to a percentage and some nice strings
<giftnudel> sivang: I'll send you the CDburner, it's really not a lot of work done, but it works that way
<sivang> giftnudel: feel free to not push until you are happy with it, I was not meant to rush anything.
<giftnudel> oh no, I will not push that, since it hasn't been tested at all
<giftnudel> sivang: but just so that you know what I have done
<sivang> giftnudel: sure thing, I appreciate it :)
<giftnudel> sivang: oh well, the fsMisc stuff is not that easy, but I need to go now, have fun ;)
<macmadiath> Just joined the IRC channel to drop a note, say hi, say I upgrades from Dapper to Edgy on my laptop.
<pitti> macmadiath: did you encounter any problem with the upgrade?
<lool> pitti: hey
<lool> pitti: just saw you proposed an updated in the cdbs bts for cdbs-edit-patch
<lool> pitti: I'm writing my third cdbs-edit-patch today, so I'm worried things get incompatibly in
<macmadiath> the upgrade wouldn't run from the cd.  Had to create a iso, mount the iso then run the upgrade.   mainly due to the fact the cd was mounted noexec
<lool> pitti: but I also wanted to share with you some intersting fixes
<pitti> lool: hi
<pitti> macmadiath: yes, the wiki proposes to do 'sh /cdrom/cdromupgrade', which worked fine
<pitti> macmadiath: any other problems?
<lool> pitti: 1) cdbs-edit-patch always exits with non-zero (patch in the Debian BTS), 2) it tries patches in bogus order, like simple-patchsys did
<lool> (I've just sent the patch, so it's not visible yet, but it's a simple s/0 1 2/1 0 2/)
<pitti> lool: ah, nice
<lool> I suppose it's a bit late for an edgy upload though
<macmadiath> pitti: but no problems. sound worked fine, wireless card fine, haven't had any issues yet.
<pitti> lool: I submitted my changes to Debian, not sure whether they got accepted yet
<lool> pitti: they were not yet
<pitti> macmadiath: splendid! :)
<lool> pitti: actually, I extended cdbs-edit-patch to run any command
<pitti> lool: but I won't fix this in the next four weeks, so plenty of time for coordination ;)
<macmadiath> pitti: missed that part about using sh to run the update.
<lool> (instead of a shell)
<lool> pitti: ok, nevermind we'll see later then
<macmadiath> pitti: just wanted to give a thumbs up.
<pitti> macmadiath: I'm sure we'll figure out a better way for feisty, such as update-notifier offering you to run it for you (instead of just offering you to call the package manager); mvo?
<pitti> macmadiath: thanks a lot for the feedback!
<pitti> lool: ah, what is an interesting use case for something else than a shell?
<lool> pitti: a relibtoolize command, or a simple cp
<slomo_> pitti: or sed
<pitti> ah, right, a cdbs-edit-patch --command autoreconf 99_autoreconf.patch sounds interesting
<lool> pitti: I also wrote a "svn-do" wrapper which will export a tree handled via svn-bp and copy back the changes
<lool> pitti: it's simply cdbs-edit-patch 70_relibtoolize autoreconf
<lool> pitti: and directly frmo svn: svn-do cdbs-edit-patch 70_relibtoolize autoreconf
* iwj winces at the stacked revision control systems.
<iwj> `I keep my CVS repo in bzr and all my bzr branches in svn ...'
<lool> iwj: hmmm sounds nice, does that exist yet?
<lool> I'm in the chaining-mood lately, I proposed debuild should call svn-buildpackage if from svn, which could call pbuilder-buildpackage which should call dpkg-buildpackage
<Keybuk> no less insane than putting bzr branch metadata in a source package
<Keybuk> apt-get source usplash
<Keybuk> cd my-branch; bzr merge ../usplash-0.x
<lool> Keybuk: I find that alright
<iwj> Keybuk: That's not quite the same, I think.
<pitti> apart from utterly cluttering the diff.gz
<cjwatson> that's a branch distribution method
<lool> pitti: oh that isn't with wig and pen stuff?
<tfheen> iwj: I keep my dotfiles in svn, cvs and bzr with commits going into both svn and bzr.. :-)
<cjwatson> no different from publishing it over HTTP
<lool> pitti: I thought it was some usplash.bzr.orig.tar.gz
<iwj> The main problem with it is that it makes debdiff give unhelpful answers.
<lool> too bad then
<cjwatson> lool: wig and pen doesn't really quite exist yet ...
<pitti> lool: wig&pen is still only on paper, or did I miss something?
<iwj> Why oh why oh why is rsync apparently downloading the whole of this dvd again ?
<pitti> and with the NoMoreSourcePackages spec lurking, it might never actually exist
<lool> cjwatson: oh, I thought it was announced like a lot of months ago
<cjwatson> lool: only half of it
* pitti -> lunch
<lool> cjwatson: but that we shouldn't use it because of saege -> etch upgrades
<cjwatson> only unpacking, I think
<cjwatson> ICBW, check d-d-a
<pitti> ah, right, but dpkg-source -b support is missing; I remember playing with unpacking
<mvo> pitti, macmadiath: yes, this is implemented in the update-notifier in edgy already. we haven't backported it though to dapper
<lool> http://lists.debian.org/debian-devel-announce/2005/06/msg00010.html
<iwj> So given that I'm not affected by the squashfs bug, I take it it's worth me investigating this dvd when I actually ahve it (which might be shortly if I'm lucky).
<cjwatson> iwj: yes, we should also get confirmation that we haven't broken systems that worked
<iwj> cjwatson: Right.
<iwj> I take it new desktop cds will be around when they've been crunched by all of the relevant gears.
<cjwatson> yes, the gears are crunching as I type
<cjwatson> the ... middle set of gears
<iwj> This whole business is very hurry up and wait.
<iwj> We should make the operating system a tenth of the size and then it would all be ten times quicker.
<cjwatson> the livefs build process could be speeded up a fair bit; there are a number of ideas in the pipeline
<Keybuk> iwj: put it all in the initramfs! :)
<cjwatson> iwj: it was all much quicker before we started caring about live CDs :-)
<cjwatson> actually probably not that much; cdimage was slower then
<bddebian> Howdy
<iwj> Yay, I have the dvd.
<dholbach> iwj: all images are being re-rolled - but at least rsyncing should be very quick
<iwj> dholbach: Yes, but based on last time I think I can assume the dvd will be too late for me to wait for it.
<iwj> I'm going to do some tests here now with this one and then I can do a quick check with the new one.
<dholbach> I'm not sure how long it's going to take, but I think it won't be that long.
<cjwatson> tfheen: I'll build desktop CDs as the corresponding live builds finish
<tfheen> cjwatson: cheers.
<cjwatson> Ubuntu DVD could actually be done pretty soon
<cjwatson> I can do for-project ubuntu cron.daily-live; for-project ubuntu cron.dvd
<iwj> cjwatson: Oh ... how soon ?
* cjwatson counts on fingers
<cjwatson> iwj: within the hour
<cjwatson> desktop CD takes about five minutes to build, DVD takes <30
<cjwatson> the combination of which is around the same as a livefs build, so it all parallelises quite well
<iwj> Since I have this DVD now I will do a test install with it anyway.
* cjwatson nods
<iwj> I fancy some hurry up rather than some wait :-).
<tfheen> DVDs rsync quickly enough, though.
<Keybuk> is hurry up a Class A drug?
<cjwatson> stoppit and hurryup
<cjwatson> possibly rather UK-specific
<robertj> how long after the images are finalized is it before they hit all of the mirrors?
<dholbach> ubuntu-server and ubuntu-alternate are ready for testing (20061025.1)
* dholbach does a ppc server install
<cjwatson> robertj: out of our control in many cases, especially depending on the value of "all"
<cjwatson> (we have a LOT of random cdimage mirrors)
<robertj> cjwatson: ahh, I figured that all the http://www.ubuntu.com/download/ were nightly or something
<cjwatson> ubuntu/desktop ready for testing (20061025)
<cjwatson> robertj: many are
<robertj> but not a strict criteria for inclusion then, eh, free bandwidth is free I suppose :)
<PSUSI> anyone have any ideas on what could cause udevtrigger to block for 3 minutes during bootup?  or how to further debug it?
<dholbach> http://wiki.ubuntu.com/Testing/Current updated
<cjwatson> hmm, DVD taking a little longer than I thought; working on it though
<tfheen> cjwatson: it helps that we're fighting for I/O capacity.
<iwj> Has anyone else tried evolution from the livefs ?
<seb128> iwj: what do you call livefs? The desktop CD? not today but during previous runs I did, why?
<iwj> The DVD in livefs mode, in this cas.e
<iwj> It hung for me, which I've just reported as bug 68195.
<Ubugtu> Malone bug 68195 in evolution "evolution hung on the live dvd" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68195
<cjwatson> I usually start evolution at least, but rarely go any further
<iwj> Yes, it's a faff to go through the setup.
<seb128> iwj: I'll try reproducing it later
<iwj> seb128: Ta.
<PSUSI> anyone know how I could figure out what udevtrigger is waiting on for 3 minutes?
<cjwatson> tfheen: is the "live CD doesn't reboot when you press enter" bug filed? I can't find it
<tfheen> cjwatson: I thought I had fixed that?
<Keybuk> PSUSI: do you have /var/log/udev ?
<tfheen> cjwatson: if not, please file it again.
<PSUSI> hrm... not sure
<PSUSI> this is in the initramfs on my home machine
<cjwatson> tfheen: it's possible you fixed it for svgalib but not bogl
<Keybuk> PSUSI: udevtrigger waits in the initramfs?!
<Keybuk> are you sure it's udevtrigger and not the while loop in mountroot?
<PSUSI> Keybuk: yes
<tfheen> cjwatson: it's casper, not usplash, iirc.
<Keybuk> PSUSI: udevtrigger --verbose
<PSUSI> the boot scripts start udevd, then call udevtrigger and it blocks for me for 3 minutes+
<Keybuk> which udevtrigger is it?
<PSUSI> hrm... ok, I'll try adding --verbose... that should make it give some reason for why it is waiting?
<Keybuk> it will be called with arguments
<PSUSI> yea... called with a bunch of args to wait on buses and such
<cjwatson> tfheen: oh yes, there it is, I'll dup
<Keybuk> PSUSI: that's very rare
<PSUSI> my usb drivers and everything else gets loaded fine, then it just sits there for over 3 mins waiting for udevtrigger to continue
<Keybuk> ok
<Keybuk> this is kinda hard to debug
<PSUSI> once it continues it mounts the root fs just fine and goes on
<Keybuk> hang on
<Keybuk> UDEVTRIGGER hangs?!
<Keybuk> not udevsettle?
<PSUSI> yea
<PSUSI> prety sure... I don't recall seeing udevsettle
<Keybuk> can you check that
<PSUSI> it was 1 am last night when I decided to get some sleep, but the last thing I remember was putting some messages before the calls in the script to udevd and udevtrigger, and they both came out before all the drivers loaded, then sat there waiting
<Keybuk> do you have the offending hardware in front of you now?
<PSUSI> and from looking at the scripts after udevtrigger, the next thing that goes on is it says it is mounting the root fs... which is the next thign I saw after the long pause
<PSUSI> no... it's at home
<Keybuk> ok
<Keybuk> not much else I can suggest
<PSUSI> ok.... I'll add the --verbose when I get home
<Keybuk> it's likely not udevtrigger though
<Keybuk> but udevsettle
<PSUSI> what exactly is udevtrigger supposed to do?  so far I gather that it causes the kernel to play attach events for all the hardware it knows about and wait for udev to finish processing them?
<PSUSI> what's udevsettle?  I don't recall seeing that one
<cjwatson> udevsettle is "wait for udev to actually finish processing events"
<cjwatson> udevtrigger is "send events for everything"
<cjwatson> explaining those the other way round might've been less confusing :)
<PSUSI> hrm... so trigger does not block?
<Keybuk> right
<PSUSI> it sounded like it was meant to wait at least for the busses to all appear or something
<PSUSI> pci, usb, etc
<PSUSI> how does udevsettle decide when it is all "done"?
<Keybuk> compares the kernel sequence number to the udev sequence number
<PSUSI> could udev itself be blocking while trying to process some rule that invokes a callout?
<Keybuk> yes
<PSUSI> hrm....
<Keybuk> udevsettle exits when /dev/.udev/uevent_seqnum and /sys/kernel/uevent_seqnum are equal
<Keybuk> note that udevtrigger may call udevsettle if given "-s"
<Keybuk> we do that for one of the calls
<PSUSI> ahhh
<Keybuk> udevtrigger iterates /sys and writes "add" to any "uevent" file found there
<Keybuk> the various arguments to it limit the amount of /sys it iterates
<PSUSI> ok... so most likely it is udevd that is blocking on a callout right?
<dholbach> http://wiki.ubuntu.com/Testing/Current updated
<cjwatson> Ubuntu DVDs available for testing (20061025)
<Keybuk> right
<Keybuk> or the kernel isn't sending an event
<Keybuk> but thinks it has
<PSUSI> how could I trace that?
<Keybuk> with tools that aren't in the initramfs
<PSUSI> well, I could add them ;)
<Keybuk> if you're happy modifying the initramfs, add udevmonitor to it and a job control shell so you can background it and see its output
<Keybuk> what happened to make it break?
<PSUSI> edgy did ;)
<cjwatson> Kubuntu daily-live (20061025) ready for testing
<Riddell> thanks
<Keybuk> that's interesting
<PSUSI> when I upgraded to edgy, the new kernel failed to boot at first because of a dmraid bug and the new kernel refusing to accept the slightly wrong parameters... fixed that by upgrading dmraid and now I have this problem...
<Keybuk> normally it happens because, as you say, udev blocks on a callout
<Keybuk> except there aren't any callouts in the initramfs
<PSUSI> there aren't?
<cjwatson> Riddell: may take a little while more to mirror
<Keybuk> no
<PSUSI> hrm....
<Keybuk> well
<Keybuk> other than the persistant storage ones
<Keybuk> and modprobe
<Keybuk> the storage ones could hang I guess, if you have a bad block device
<PSUSI> aha!
<Keybuk> but that's the same as dapper
<PSUSI> could they be hanging up on the fact that I'm booting from a raid0 so the first disk's partition table shows partitions that don't fit on it?
<Keybuk> could be a modprobe hanging
<PSUSI> iirc, there were some changes in the new kernel about how that is handled
<Keybuk> don't think so, they mostly just ioctl() the devices to find out their serial number, filesystem id, etc.
<PSUSI> well the last thing I see before the pause is the usb drivers loading and finding all the usb hardware... first thing after is the script saying it is mounting the root fs
<Keybuk> that doesn't mean much
<Toadstool> 14
<Toadstool> uhuh sorry
<PSUSI> hrm.... so they wouldb't get hung up trying to read a partition that is not accessible?
<Keybuk> that should just error
<PSUSI> of course, if they were then I'd see the kernel complaining about it... which I don't, so...
<Keybuk> hang is bad
<Keybuk> verbose should reveal what hangs
<Keybuk> it prints the sysfs paths as it visits them
<PSUSI> k
<Keybuk> the one before the hang is the one that hangs
<PSUSI> aye
<pitti> iwj: for the record, evo works fine for me on current amd64/desktop
<iwj> pitti: Hmm, perhaps it's the particular message.
<iwj> I'm doing another test myself.
<iwj> Hmm.  My laptop's livecd session has crashed.
<iwj> Err, livedvd even.
<iwj> I have been having a bit of trouble with the dvd drive which is probably responsible.
<fabbione> neuralis: ping?
<neuralis> pong
<cjwatson> iwj: it would be very interesting to know if this is fixed by the new DVD build
<cjwatson> iwj: or is this the old build?
<iwj> cjwatson: It's the old build.
<iwj> cjwatson: but I have just failed to reproduce it.
<cjwatson> iwj: today's discoveries seem to implicate squashfs in a lot of things we previously thought were live CD reading problems
<pitti> bah, amd64 CD check looks quite ugly with the text being in dark gray over black; but *shrug*
<cjwatson> in which case the new build should fix it
<cjwatson> pitti: that's fixed on powerpc
<cjwatson> there's a bug filed
<cjwatson> broken on i386 too, according to mdz
<iwj> cjwatson: If it was a bug and not a dvd reading problem, then it's probably some racey thing.
<Keybuk> pitti: console text?
<cjwatson> iwj: correct
<pitti> cjwatson: it's the special 16-color amd64 usplash theme; shouldn't affect ppc at all
<cjwatson> iwj: it's a static struct in the squashfs module that shouldn't be static
<pitti> Keybuk: text on usplash
<iwj> cjwatson: Err, right.  I meant, my evo hang felt like a racey thing.
<cjwatson> it's possible that it was a subprocess segfaulting or getting corrupt data off squashfs or something
<iwj> Yes.  I didn't look at the kernel log unfortunately.
<cjwatson> .xsession-errors might be worthwhile to check in future too
<iwj> Point.
<cjwatson> iwj: if you didn't see, a new DVD build is available now
<cjwatson> so if you have time to test that, that would be very good
<iwj> Yes, I'm downloading it now.
<cjwatson> thanks
<iwj> Unfortunately due to complex logistics I end up rsyncing the images using the testbed machine, which means I can't be downloading and testing at once, unlike for the much smaller cds.
<iwj> That evo hang looks like it's going to be an annoying unreproduceable thing.
<iwj> cjwatson, tfheen: Unless you have an objection, I propose to stop this testing so I can go climbing in my usual way today; if you need more stuff doing I can log on again when I get back at around 2200Z.
<iwj> I'll be able to give this new dvd a quick runthrough first though.
<cjwatson> iwj: if you can manage enough of a quick runthrough to confirm that ubiquity works, that would be very good
<cjwatson> that's what we're most bothered about
<iwj> cjwatson: I think that should be doable.
<cjwatson> thanks
<iwj> BTW, it occurred to me to wonder - what happens if you install packages into your livesystem with synaptic and then run ubiquity ?
<iwj> Or worse, do the two simultaneously ...
<cjwatson> iwj: shouldn't interact at all
<cjwatson> but feel free to try it
<cjwatson> iwj: ubiquity copies the read-only squashfs
<iwj> I did, and it broke, but I think that was because I hibernated it while synaptic was downloading.
<iwj> I like breaking stuff :-).
<cjwatson> I'm not entirely sure what hibernating the live CD does :-)
<cjwatson> I'm sure we disabled that, but it keeps coming back like the proverbial bad penny
<cjwatson> Kubuntu DVD 20061025.1 ready for testing
<iwj> I mean I hibernated the install that ubiquity made.
<cjwatson> oh right
<cjwatson> uh, I don't understand
<cjwatson> you said "install packages into your livesystem with synaptic"
<cjwatson> that can't have been the same synaptic that you hibernated in the install that ubiquity made
<iwj> cjwatson: That's right.
<cjwatson> um, ok.
<iwj> cjwatson: I both installed packages with synaptic in the live image while ubiquity was running, and then later, when booted from the install that made, I ran synaptic again and hibernated it while it was downloading packages files.
<iwj> The latter wasn't a huge success and produced bug 68202/.
<Ubugtu> Malone bug 68202 in apt "corrupted file from download, not recoverable without messing about" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68202
<cjwatson> ah, right. I'm pretty confident that the results of synaptic in the live image will have been thrown away
<iwj> Good.
<mvo> iwj: bug #68202 is strange, if the md5sum check fails, apt should (in theory) just delete the file (or rename it to FAILED or something)
<Ubugtu> Malone bug 68202 in apt "corrupted file from download, not recoverable without messing about" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68202
<cjwatson> we do run apt outside the chroot, but I believe I've now entirely pointed it at /target ... there is a slight possibility of bugs there
<cjwatson> (there was a bug there in dapper)
<cjwatson> apt wasn't looking at /target/var/lib/dpkg/status, IIRC
<cjwatson> Edubuntu live 20061025 ready for testing
<iwj> This install's looking good.
<zMott> There is a major bug issue...
<fabbione> zMott: bug number?
<zMott> when using search, to find many items..(.pdf), the search display 1420 .pdf, I then selected a couple hundred, to copy to another hard drive...
<fabbione> zMott: bug number?
<zMott> However, it would appear only 43 got copied...
<zMott> then the copy window quite
<zMott> quits
<zMott> this is the bug
<fabbione> zMott: did you file a bug in launchpad?
<fabbione> if not please do so
<zMott> launch pad did not pop up
<fabbione> http://launchpad.net/ ->
<zMott> well
<neuralis> zmott: sounds like a nautilus problem, not release critical; file a bug, and if it can be tracked down, it'll be addressed in edgy-updates.
<iwj> mvo: I kept the file.
<mvo> iwj: thanks
<zMott> okay.. I will file this with launch pad, thought lauch pad was built in
<iwj> That is, the broken file.  I wiped the rest of the install.
<iwj> If it's helpful I'll attach it to the bug report when my testbed has finished rebooting - ie, next week :-).
<neuralis> zMott: thanks.
<zMott> reporting noew
<zMott> now
<zMott> okay, done here the link; https://launchpad.net/distros/ubuntu/+bug/68221
<Ubugtu> Malone bug 68221 in Ubuntu "nautilus bug copy from search window...." [Undecided,Unconfirmed]  
<iwj> cjwatson: Works.
<iwj> Now I must go and catch my train.
<cjwatson> iwj: great!
<zMott> Hey guess what: that same bug was there in 6.0.6.1 distro too...
<cjwatson> please add that as a comment to the bug report rather than commenting here
<cjwatson> then it is archived for when a developer looks at it
<zMott> ummm, this is the devel list..
<zMott> did both
<cjwatson> zMott: correct, this is the developer coordination channel, not a forum for users to file bug reports
<cjwatson> please do not report bugs in this channel
<cjwatson> we are preparing a release right now and need to focus
<cjwatson> Edubuntu DVD 20061025 ready for testing, except ogra's gone away, d'oh
<dholbach> ogra: <cjwatson> Edubuntu DVD 20061025 ready for testing, except ogra's gone away, d'oh
<__keybuk> ogra: ping
<ogra> dholbach: i'm never away :P
<ogra> just switched machines
<ogra> __keybuk: ?
<__keybuk> ogra: ltsp-management-gui status is Beta Available -- why does it need discussion at MTV?
<ogra> ergh
<ogra> sjremnant: because there are new and different features to be discussed now that it should become an upstream tool at some point
<ogra> i havent had time to update the spec yet
<sjremnant> ok
<dholbach> Gloubiboulga: new Xubuntu CDs rolled
<Keybuk> April 1st
<Keybuk> I'm so changing the Ubuntu Dance music to the song from Lugradio
<Gloubiboulga> dholbach, danke
<dholbach> Gloubiboulga: de rien
<Gloubiboulga> :)
<seb128> Riddell: where does kdm get the locale to use for the login screen?
<pitti> seb128: oh, it doesn't use /etc/environment?
<seb128> pitti: I'm asking because I just did a kubuntu install and login screen is to english instead of french
<seb128> pitti: the .mo has the translations for those strings and /etc/environment has LANG=fr_FR.UTF-8
<Riddell> seb128: it uses whatever is in the /etc/kde3/kdmrc file, which we default to English, it's a bit crap
<cjwatson> I needed to have been told about that change so that I could deal with it in ubiquity
<seb128> Riddell: ok, so having english login on a french install is normal situation?
<cjwatson> Riddell: could you post the necessary information to the ubiquity bug that's already filed about this?
<seb128> normal or "known"
<cjwatson> seb128: it's certainly a known bug :-(
<seb128> cjwatson, Riddell: ok, thank you
<Riddell> cjwatson: ok
<Keybuk> man, I so want /sbin/ioctl
<pitti> Riddell: uh, English default regardless of the locale; you are aware that you can be punished in France for using 'computer' instead of 'ordinateur'? :)
<crimsun> mdz: is it too late to request a simple rebuild of a universe package to close bug 68225 ? I've verified that simply rebuilding (no changes) against current Edgy's python2* results in a fixed python-biggles package.
<Ubugtu> Malone bug 68225 in python-biggles "Biggles package missing most files" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68225
<mdz> crimsun: I'm afraid so, see /topic
<mdz> crimsun: you can propose it for edgy-updates though
<crimsun> mdz: thanks
* pitti wonders what the tons of pkgsel XML errors are about that appear while the 'Cleaning up' stage of alternateinstall
<Keybuk> that usplash bug is weird
<mdz> pitti: scrollkeeper-update
<yacoob> Just a question, is there going to be a release tomorrow?
<mvo> yacoob: there is one planed for tomorrow
<pygi> yay, release ^_^
<yacoob> mvo, did you, by any chance, have any insights on whether it's going to stand up to the schedule? :)
<dholbach> yacoob: https://wiki.ubuntu.com/Testing/Current
<dholbach> you can help testing
<yacoob> (potential debian switchee here, I don't know all releveant places to look for info :)
<mvo> yacoob: the chances are good actually
<dholbach> yeah... if oyu look at the page: nearly all of the tests passed
<mvo> PASS is GOOD :)
<yacoob> good :>
<yacoob> (nice idea for end-user testing)
* pitti feels near to passing out, too
* dholbach hugs pitti
<fabbione> pitti: eh..
<dholbach> DINNER
<pitti> dholbach: good idea! /me asks gf
* dholbach cracks the whip and gets people to work on https://wiki.ubuntu.com/Testing/Current before ;-)
<dholbach> pitti: if she cooked you a dinner? ;)
<yacoob> This is why I'm thinking about switching, debian seems to be more and more about ideology, and not about end-user experience...
<pitti> dholbach: well, prepare -- we usually don't cook in the evening
<fabbione> pitti: pizza time? :)
<dholbach> pitti: I think I'll just run to an Arab place and get a shawarma or something
<pitti> fabbione: don't tease me too much :)
<dholbach> desrt: your power thingie arrived today
<fabbione> pitti: dude.. at least you have gf that still can care of you..
<pitti> dholbach: shawarma? he's online, but why do you want to eat him? :)
<fabbione> pitti: my wife throws food at me from the door step
* dholbach slaps pitti
<pitti> fabbione: ouch, she's throwing up?
<pitti> dholbach: (seriously, I have no idea what a shawarma is)
* pitti is spoilt by Dner
<fabbione> pitti: no, she launches it across the room and feed me like a pig in a cage or something
<pitti> fabbione: rotfl
<fabbione> pitti: given it's 3 days i don't get out of it if not for sleeping
<pitti> fabbione: mine got used to my ear being /dev/null in these days :)
<dholbach> pitti: http://de.wikipedia.org/wiki/Schawarma http://en.wikipedia.org/wiki/Shawarma
<fabbione> pitti: i will remind you of that after you two will get married
<pitti> dholbach: thanks for the link, but where can I download it?
<pitti> dholbach: *hug*
<dholbach> :)
* dholbach hugs pitti
<dholbach> bon apptit
<sivang> pitti_live: you want to download shawarma ? :)
* sivang yums at the thought of shawarma in Pitta bread.
<Treenaks> pitti bread?
<highvoltage> hee hee
<ulaas> hi, where is the alacarte icon?
<ulaas> gone on purpose?
<seb128> ulaas: 
<seb128> $ dpkg -L alacarte | grep png
<seb128> /usr/share/icons/hicolor/22x22/apps/alacarte.png
<ulaas> ah no! :) i mean in the menu..
<pirast> ulaas, system -> settings
<pirast> ulaas, -> menu structure
<ulaas> pirast: settings?
<seb128> preferences
<ulaas> ahhhhh
<ulaas> menu layout
<ulaas> damn
<seb128> you can right click on the panel labels too
<pirast> lol :-) trying to translate the menus into german on the fly :-)
<seb128> there is an "edit menu" item
<ulaas> seb128: mine is menu layout
<ulaas> which is not very nice..
<seb128> ulaas: right click on the panel label
<seb128> you get a menu
<seb128> the item should mention edit, no?
<ulaas> seb128: on the menu panel applet. yes
<seb128> k, that's normal there
<seb128> feel free to open a bug on alacarte if you think that "Menu Layout" is not a good title
<ulaas> seb128:under system->preferences it is "menu layout"
<seb128> I know
<seb128> I was saying:
<seb128> <seb128> you can right click on the panel labels too
<seb128> <seb128> there is an "edit menu" item
<ulaas> seb128: sure thing. thanks
<ulaas> i will think about the title. maybe it is okay.
<mdke> seb128: since you're here, do you know if the epiphany addressbar search fix is likely to be accepted for -updates?
<seb128> mdke: no idea, let it been accepted upstream to gnome-2-16 first
<mdke> seb128: sure, I mean in principle
<seb128> mdke: my opinion is that we should give it a try on edgy+1 and upload later if it works fine
* mdke nods
<mdke> that sounds sensible
<fabbione> crimsun: btw there is no ReleaseNote entry for the alsa stuff.. any plan to add the note?
<crimsun> fabbione: I asked in ubuntu-doc about that yesterday
<ajmitch> morning
* keescook waves hi
<crimsun> fabbione: yes, I plan to add it; I'll go through that procedure shortly if there's an errata section in place
<sivang> hey keith80403 
<sivang> oops
<sivang> hey keescook 
* dholbach looks at http://wiki.ubuntu.com/Testing/Current
<dholbach> still quite a bunch of empty spaces
<dholbach> pitti: heya - how was dinner? :)
<fabbione> crimsun: ok... better hurry up
<crimsun> fabbione: is there some other place I should be looking (e.g., wiki)?
<dholbach> http://wiki.ubuntu.com/EdgyReleaseNotes ?
<fabbione> https://wiki.ubuntu.com/EdgyReleaseNotes
<crimsun> ah, ok. Thanks.
<dholbach> it still has my evolution screenshot in it
<dholbach> I hoped somebody would replace it ;)
<keescook> sivang: howdy.  :)
<pitti> dholbach: good :) and your's?
<dholbach> pitti: it took AGES to get it, but it was quite good :)
<crimsun> fabbione: added, thanks.
<beligum> Hi all, what's the release date for edgy ?
<seb128> beligum: tomorrow
<dholbach> ogra: my edubuntu ubiquity starts in french!
<mvo> beligum: but you can test it today if you feel like it
<mvo> dholbach: did you configure it to start in french?
<dholbach> mvo: not that I know of
* dholbach restarts the box, restarts the installation
<ogra> weird
<mvo> dholbach: is the rest of the desktop french?
<dholbach> seb128: did you login to my box again?
<dholbach> mvo: no, was english
<seb128> dholbach: ?
* mvo blames seb128
<seb128> ah
<seb128> no ;)
<mvo> ... and his secret agenda
<dholbach> hehe
* dholbach hugs seb128
<beligum> great
* seb128 hugs dholbach back
<beligum> Btw, someone interested in the ScreenKast package for universe? http://revu.tauware.de/details.py?upid=3140
<beligum> I started working on it to get it in the official repository list, but ran out of time
<Riddell> beligum: yes
<beligum> Riddell: great !
<beligum> What do you need ?
<Riddell> beligum: a poke to revu it I guess
<Riddell> beligum: it's too late for edgy I'm pretty sure
<beligum> yes, I know
<beligum> poke in ubuntu-motu ?
<dholbach> ogra, seb128: it's all good again ;)
<dholbach> ogra, seb128: cosmis rays... or something
<Riddell> beligum: it's KDE so a poke in #kubuntu-devel as well may help
<dholbach> although I don't rule out french hackers making fun of my french
<pirast> night, have a great releaseday tomorrow :-)
<ogra> dholbach: the lang switches if you select something in teh first window ... i bet you double cliecked or something when the window appeared
<dholbach> ogra: that would not be as funny as french hackers, you must admit
<beligum> Riddell: done
<ogra> dholbach: indeed :)
<seb128> dholbach: I tried kubuntu in german like one hour ago!
<dholbach> seb128: how was it?
<seb128> blue
<pygi> lol ^_^
<pygi> seb128: no kidding?:P
<seb128> ;)
<seb128> I'm not used to KDE nor to german :p
<seb128> it was ok though, icons make it easier ;)
<Riddell> kubuntu in edgy is more purple than blue
<seb128> right
<seb128> I had some english strings though
<dholbach> ok... I think everybody has to take that as a compliment from seb128 :-)
<seb128> dunno what german translators are doing :p
<dholbach> could have been worse than "blue" ;)
<seb128> dholbach: hehe ;)
<seb128> in fact I don't like "apply" button don't closing dialogs
<seb128> it was with the language selector I think
* yacoob always uses LC_MESSAGES=C tries to 
<yacoob> s/tries to//
<seb128> that might be language selector being weird, the GNOME one does the same :p
<seb128> it's a mvo-ish
<seb128> having apply and ok on the same dialog
<seb128> both applying the changes, one closing the dialog and the other not
<seb128> I find that just confusing :p
<seb128> gnome-app-install does the same
<mvo> seb128: thats how the HIG wants it
<seb128> mvo: no other app do that
<seb128> I would prefer: "apply" "close"
<seb128> close just closing without doing anything
<seb128> and apply applying
<seb128> rather than "cancel" "ok"
<mvo> seb128: yeah, I guess that needs to be re-thought
<_ion> "close" "apply" rather
<seb128> _ion: I was listing options, not order
<_ion> That's the order all the other Gnome apps use.
<seb128> we are not speaking about implementation details yet :p
* mvo hugs seb128
* seb128 hugs mvo back
<seb128> pitti: pkg-create-dbgsym should make the -dbgsym Conflicts on the -dbg if there is one?
<pitti> seb128: right, but that's not yet implemented
<seb128> ah k
<seb128> I thought it was
<seb128> no need to open a bug then ;)
<pitti> feel free to do so, otherwise I might forget
<seb128> or I could open one as a wishlist
<seb128> ok
<seb128> doing that then
<pitti> seb128: thanks!
<beavis> hile, I updated dapper to edgy RC, the installation stopped at the nfs update. It asked me what to do with my exports
<seb128> pitti: np ;)
<beavis> oops I mean hi ;)
<dholbach> beavis: hello... you might want to try #ubuntu or #ubuntu+1
<beavis> after that it was only possible to ctrl-c
<LaserJock> is there a definitive time when Edgy Universe will be closed?
<beavis> dholbach, In the mail from Simon Law "Testing installation" he told to report problems here
<sfllaw> beavis: Hi.
<sfllaw> beavis: This is the channel for volunteering to do testing.
<dholbach> beavis: I just thought you had better chances there, sorry.
<beavis> I volunteered to do testing ;) but it completely screwed up my installation 
<seb128> sfllaw: #u-d ?
<seb128> sfllaw: I though that was  #u-r
<sfllaw> seb128: #u-r is more of a release managers round table.
<seb128> so where should be take ubuntu devel discussions now?
<seb128> s/be/we
<sfllaw> Oh, here.
<seb128> ah, k
<seb128> I didn't understand your "This is the channel for volunteering to do testing." then
<sfllaw> When I sent out the e-mail, we were doing lots of installation talking in this channel.
<bettsp> Hi, the dev information in KernelCustomBuild on the wiki seems out of date; none of the commands work with the Edgy linux-source package
<bettsp> Most of them throw "No Rule to make target"; what's the current way to build the Ubuntu kernel?
<pitti> sfllaw: FYI, I covered the whole Ubuntu/amd64/desktop+alternate range now
<beavis> sfllaw, well pressing on show differences on nfs upgrade causes a freeze, which can only be stopped by pressing ctrl-c, unfortunately the installation doesn't finish after that, so my X didn't come up again
<sfllaw> Riddell: You claim that Kubuntu PPC's check CD fails.
* sfllaw hugs pitti.
<beavis> just a heads-up to probably check this area again
<sfllaw> pitti: I'm going to fill in the holes for Kubuntu alternate.
<sfllaw> pitti: Do you want to do Kubuntu desktop for amd64?
<Riddell> sfllaw: yes please
<Riddell> sfllaw: PPC desktop check fails for me, just runs live CD
<Riddell> sfllaw: apparantly it works for ubuntu so maybe I'm just imagining it but I don't think so
<sfllaw> Riddell: Hmm.  Is the MD5SUM correct for that image?
<sfllaw> Oh wait.
<sfllaw> You're saying it just runs the live CD?
<sfllaw> It doesn't even do a check?
<Riddell> sfllaw: yes
<sfllaw> Can you check the MD5SUMS and if that works out, file a bug?
<Riddell> sfllaw: same for DVD, but alternate PPC CD works
<keescook> sfllaw: do you know if the Ubuntu DVD is supposed to have a working "rescue" mode?  (it's listed, but don't work)
<keescook> (this is with PPC)
<sfllaw> keescook: I'm sorry, I don't know.
<sfllaw> I presume yes.
<sfllaw> I can soon tell you if it works on i386/amd64.
<keescook> sfllaw: okay, cool
<bettsp> BenC: What's the correct way to build the Edgy kernel? I saw your name in the changelog
<bettsp> The wiki has old info
<BenC> bettsp: the wiki info isn't old
<sfllaw> keescook: Is the rescue mode in the menu?
<pitti> sfllaw: if you have the time, can you please attempt an expert install on amd64? I get a garbled screen after a few dialogs, I'll file a bug with a screenshot
<sfllaw> pitti: I can get expert working.
<sfllaw> But there are problems with the dialog boxes.
<bettsp> BenC: When I try any of the commands, I get "no rule to make target", using the linux-source package in Edgy 
<BenC> bettsp: the build guide that I wrote is the suggested way
<BenC> bettsp: Use git repo
<sfllaw> keescook: Bug 66881
<Ubugtu> Malone bug 66881 in debian-installer "Help text is misleading or inaccurate for boot methods" [Medium,Confirmed]  http://launchpad.net/bugs/66881
<sfllaw> pitti: Bug 66883 and bug 67076
<Ubugtu> Malone bug 66883 in cdebconf "Codeset selection dialog has poor layout" [Medium,Confirmed]  http://launchpad.net/bugs/66883
<Ubugtu> Malone bug 67076 in cdebconf "Can't see selection of font face" [Undecided,Unconfirmed]  http://launchpad.net/bugs/67076
<pitti> sfllaw: ah, nevermind, already known as bug 66883
<pitti> sfllaw: right, yay my initial IRC lag (I'm good now)
<sfllaw> pitti: Stylish.
<keescook> sfllaw: hm, I'm not sure if 66881 is quite right.  /me digs
<sfllaw> keescook: I don't see a menu item for expert mode.
<sfllaw> Not on the DVD.
<keescook> sfllaw: "rescue"?
<pitti> sfllaw: ok, then I covered the whole range now
<sfllaw> keescook: Sorry.
<sfllaw> keescook: I only see:
<sfllaw> Start on install Ubuntu
<sfllaw> Start Ubuntu in safe graphics mode
<sfllaw> Install in text mode
<sfllaw> Install in OEM mode
<sfllaw> Install a command-line system
<sfllaw> Check CD for defects
<sfllaw> Memory test
<keescook> I filed bug 68077 but that was closed by having "rescue" removed from the menu.  :)
<sfllaw> Boot from first hard disk.
<Ubugtu> Malone bug 68077 in Ubuntu ""rescue" fails to load kernel on PPC edubuntu Desktop CD" [Undecided,Fix released]  http://launchpad.net/bugs/68077
<keescook> I think this is PPC-specific (the yaboot list, etc)
<sfllaw> Albeit, this DVD is slightly old.
<dholbach> expert is hidden in the F<x> 'menu's
<dholbach> sfllaw: slightly old?
<sfllaw> dholbach: By about two days.
<ogra> you must hit F6 twice ;)
<pitti> sfllaw: you can't use F6 on the DVD?
<sfllaw> Actually, F6 twice doesn't work on this DVD.
<keescook> pitti: did you find working rescue modes on any of the PPC isos you tried?
<sfllaw> Nor does "Rescue mode" seem to be listed.
<pitti> keescook: sure
<pitti> keescook: boot the 'rescue' image :)
<pitti> keescook: see Testing/Current
<keescook> pitti: hm. DVD is busted for rescue then.  :(
<pitti> keescook: I have bug 60423
<Ubugtu> Malone bug 60423 in rescue "freeze after exiting rescue shell" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60423
<pitti> keescook: but the actual rescue shell works
<pitti> keescook: (live CD does not have rescue mode, just alternate)
<keescook> does it follow that the _DVD_ doesn't have rescue since it's just a big live?
* dholbach does some Alternate i386 ubuntu installs
<sfllaw> keescook: It does.
<keescook> sfllaw: okay, cool, I will amend 68077
* dholbach stifles a yawn
<keescook> is there a bug filed for the Known Issue "When shutting down or rebooting the AMD64 or PowerPC LiveCD..."?
<pitti> keescook: bug 58503 ?
<Ubugtu> Malone bug 58503 in Ubuntu "Ubuntu 2060831.1 i386 and amd64 Desktop CD install hangs after ejecting CDROM" [Undecided,Needs info]  http://launchpad.net/bugs/58503
<doko_> ogra: F6, are you testing Fedora CD's? ;-P
<mdz> keescook: it's documented in the release notes
<keescook> mdz: that's why I was asking, there was no link for it in https://wiki.ubuntu.com/EdgyReleaseNotes shall I add it?
<pitti> mdz: oh, EdgyReleaseNotes has outdated background/splash screen screenshots
<pitti> keescook: there is
<pitti> keescook: 'The following notable bugs are known to exist in the final release:', second point
<FireRabbit> a few screenshots say "Upload new attachment" next to them on that page
<loonix> Ok, edgy version if freetype I assume uses the autohinter? Not the BCI? i am trying to find out for sure
<keescook> pitti: it's described, but there is no link to the LP bug.
<pitti> keescook: ah, I see
<keescook> whew, I'm not crazy.  :)  I've added it.
<mdz> keescook: yes, please add a link
<pitti> keescook: sorry
<keescook> mdz: done.
* jdong smacks xchat
<mdz> pitti: I gave Keybuk a usplash screenshot which he said he would fix up to replace that one
<mdz> and it looks like he did
<pitti> right
<FireRabbit> do you need a new login screenshot?
<pitti> mdz: I meant the gnome splash
<mdz> FireRabbit: looks that way
<mdz> I don't know how to do the drop shadow; perhaps it's a gimp plugin?
* jdong hugs xchat, and smacks konqueror for stealing x-www-browser
<pitti> mdz: right, there is a gimp plugin (I used it once for creating a hackergotchi)
<dholbach> pitti: where is your hackergotchi? where is your blog? :)
<FireRabbit> where in gimp is the shadow option?
<pitti> dholbach: I don't have a blog, I just put it on https://launchpad.ubuntu.com/people/pitti
<ajmitch> dholbach: blog? not everyone needs one of those :)
<dholbach> ahh ok :)
<yacoob> ajmitch, impossible! web 2.0 is here!
<ajmitch> yacoob: sorry, I'm still stuck at 0.x
<tormod> I see there's a new "Known bugs" section in the release notes. Feel free to pick from https://wiki.ubuntu.com/EdgyReleaseNotes !
<yacoob> Drats. We should send you some rounded boxes then.
<tormod> I meant https://wiki.ubuntu.com/EdgyKnownIssues (bummer)
<_ion> Kernel crash if PATA port is used on SATA cards needing the sata_promise kernel module (e.g. SATAII150 TX2plus)
<_ion> Worksforme
<_ion> 00:06.0 Mass storage controller: Promise Technology, Inc. PDC20375 (SATA150 TX2plus) (rev 02)
<doko_> hrm, got a black/white splash screen for some reason ...
<keescook> doko_: bug 67545 ?
<Ubugtu> Malone bug 67545 in usplash "usplash appears black and white" [Undecided,Confirmed]  http://launchpad.net/bugs/67545
<dholbach> doko_: amd64?
<FireRabbit> well http://orion.extremeboredom.net/~eric/DropBox/edgy-gdm-theme-small.png this is the best i can do
<doko_> keescook: dholbach: yes, exactly
<keescook> pitti, mdz: what do you think of a link from the release notes to https://wiki.ubuntu.com/Apport in the "Crash Reports" section?
<mdz> keescook: very nice, I didn't know about that page
<mdz> oh, it didn't exist until recently
<mdz> yes, that seems appropriate to link
<keescook> mdz: yeah, very new.
<mdz> I need to get some sleep; back in the morning
<mjg59> mdz	Night
<keescook> cya mdz
<ajmitch> night mdz 
<sabdfl> night mdz
<mdz> mjg59: will you be around tomorrow?
<Fujitsu> 'night, mdz.
<dholbach> night mdz
<mjg59> mdz: I'm in London now
<mjg59> mdz: Ought to be around tomorrow - I can turn up wherever is useful
<mdz> mjg59: I'll be at the fieldwave office in the morning and probably linuxworld later on
<mdz> sabdfl: what on earth are you doing awake?
<mjg59> mdz: Cool. I'll see you there in that case
<dholbach> cr3: please tell me when you're don with the wiki
<sabdfl> mdz: jetlag will do that
<sabdfl> mdz: thanks for the oracle heads-up
#ubuntu-devel 2006-10-26
<Cyorxamp> Hi gays
<Cyorxamp> dexem_away is gay but away
<Cyorxamp> Oh it rhymes
<Cyorxamp> lool is gay too
<Cyorxamp> You know would be easy if I knew who was an op
<Cyorxamp> Then I could insult the right people to make the job go quicker
<Cyorxamp> lucasvo he is a gay
<Cyorxamp> Burgwork, was gay, till he gave it up
<Cyorxamp> gnomefreak... there you are
<Cyorxamp> Send your gay friends round!
<Cyorxamp> I can get around that ban in edubuntu too easy, can u make it tighter?
<Cyorxamp> double check kubuntu, xubuntu, offtopic and +1 as well just incase
<Cyorxamp> tseng is gay, Burgwork is gay
<Cyorxamp> gay gay gay gay gay
* mode/#ubuntu-devel [+o tseng]  by ChanServ
<Cyorxamp> yey!
* mode/#ubuntu-devel [+b *!*=Cyorxamp@*.112.21.19.bbplus.ptn-ag1.dyn.plus.net]  by tseng
* Cyorxamp was kicked off #ubuntu-devel by tseng (tseng)
<Fujitsu> Thanks tseng, he's been around.
<shackan> thanks
* mode/#ubuntu-devel [+b *!*@*.112.21.19.bbplus.ptn-ag1.dyn.plus.net]  by tseng
* mode/#ubuntu-devel [+o Fujitsu]  by tseng
<tseng> in case he is determined enough to come back
<tseng> i will be gone in an hour or so
<gnomefreak> he is
<Fujitsu> OK.
<Fujitsu> He will come back, believe me.
<gnomefreak> tseng: every channel hes working on
<tseng> gnomefreak: sigh
<Fujitsu> (thanks)
<tseng> Fujitsu: he msg'd to tell me he could get around my ban
<gnomefreak> its been a 3 month battle with him
<gnomefreak> tseng: proxy if he has one and dont think he does
<gnomefreak> tseng: +d JackONeill
<Fujitsu> Ah, so that's what +d does...
<Fujitsu> That's trivial to get around, of course...
<gnomefreak> :)
<Fujitsu> Has he hit #[xk] ubuntu yet? I haven't seen him.
<pygi> Fujitsu: #u-meeting
<gnomefreak> hes in -meeting now
<Fujitsu> Fun.
<Fujitsu> I knew there was something I normally had on my autojoin list but forgot this reinstall... 
<Fujitsu> Doesn't large-scale trolling like this warrant something more than seperate-channel bans?
<bhale> yes, ask staff
<gnomefreak> Fujitsu: i cant contact any of the IRC ops i know
<bhale> #freenode
<Fujitsu> nalioth is staff, isn't he?>
<bhale> yes
<gnomefreak> we have 2 in -ops but neither are around
<bhale> seriously, #freenode
<gnomefreak> or ignoring the kline i asked for
<FireRabbit> someone named cyorxamp has his phone number published on his website
<FireRabbit> gotta wonder..
<bhale> has someone talked to #freenode?
<bhale> or shall I do it myself
<FireRabbit> same person that has an acount on the ubuntu forums
<gnomefreak> bhale: i talked to a staff 
<bhale> gnomefreak: nice
<gnomefreak> i waitiing for reply
<gnomefreak> been waiting
<bhale> ugh
<bhale> you cant join #freenode?
<bhale> i hate this network
<gnomefreak> bhale: you op in fridge?
<bhale> no
<gnomefreak> bhale: its #freenode-social and you need +v
<bhale> i see that
<bhale> and it angers me
<gnomefreak> is you use /stats p it will give you list of staff online
<bhale> OFTC lets me talk to the staff
<bhale> when I have a problem
<psusi> vg=${ROOT#/dev/mapper/} << that takes what is in the ROOT variable and strips off the /dev/mapper part right?
<psusi> hrm... yea... I think I found the 3 min hang during boot... it's the LVM script
<psusi> yea... someone changed the LVM script to keep polling to see if the lvm volume shows up for 180 seconds if the root device name starts with /dev/mapper
<psusi> this is no good... hrm..
<psusi> looks like it was Fabio
<psusi> fabbione, ping
<psusi> hrm... would be really nice if certain common tasks between packages didn't have to be duplicated... such as updating the initramfs... be nice to just do it once after all 3 packages that require it have been installed, instead of after each one
<keescook> ah, sweet.  solved the G5 thermal issues
<yacoob> Dear developers, answer me this. Ubuntu is created from snapshot of debian unstable. The packages get frozen at some time, and after release are getting only security updates.
<keescook> Now if I only knew the Right way to do it.  :)
<yacoob> But does such freeze also affects multiverse and universe repos?
<LaserJock> yes
<yacoob> Mhm. So I get rather stable base.
<yacoob> I was afraid that *verses are running target, aka debian unstable :)
<FireRabbit> nope, should be stable
<psusi> no... but.... we do have the backport repo again don't we?
<keescook> yacoob: nope, they get frozen too.  That's why I started using Ubuntu for all my servers.  :)
<yacoob> keescook, well, for most things server-wise I'm fine with debian stable + a little bit of backports
* Nafallo only runs Ubuntu everywhere... :-)
<keescook> yacoob: I had a lot of developers wanting pretty modern stuff, which is why I like it.  :)
<Nafallo> why is Ubuntu marked as not spelled correctly _in_ Ubuntu? :-)
<yacoob> understandable. Mine are simple boxes :>
<psusi> I upgraded my server at work from breezy to dapper a few weeks ago..... only problem was that the tightvnc server was no longer able to locate the rgb database since it moved so emacs broke
<psusi> took me a few weeks to get around to solving that one
<keescook> yacoob: for simple stuff, yeah, debian stable is good.  a have a friend that sticks to that for the same reason.  :)
<yacoob> I wonder how many folks were switching from debian to ubuntu...
* Nafallo holds his and up
<Nafallo> insert hand somewhere :-)
<yacoob> similar reasons? :>
<Nafallo> well, I got involved in and in love with the project that had an official amd64-distro :-).
<Nafallo> after that there where no turning back to the rather stale debian.
<Nafallo> here we can do new stuff, break the ice.
<yacoob> hehe.
<yacoob> Well, I got a bit fed up with debian. 
<Nafallo> right. the one and only biggest reason for me was after all the flamewars :-P
<Nafallo> Ubuntu was just... nice :-)
<yacoob> I love the idea, infrastructure, and got used to it in many places
<yacoob> but it was hit with a paralysis, I think
<yacoob> trying to be the perfect saint distro, last firefox dispute... :/
<Nafallo> hmm, might be,
<yacoob> it's not what end-users want to deal with :)
<Nafallo> I'll still use it. and I switched to epiphany half a year ago ;-)
<Burgwork> keescook: any thoughts? https://wiki.ubuntu.com/Website/LifeCycle
<Burgwork> keescook: long term plan: move that page to the website
<psusi> does lvm really place the dev nodes for the volume group in /dev, while the volumes themselves are in /dev/mapper?
* psusi wonders why this script was written this way
<Nafallo> psusi: no. /dev/vg/lv
<psusi> ohh, /dev/vg is a directory?
<Nafallo> psusi: /dev/mapper/vg-lv are just some kind of "nice way" to access them.
<psusi> I see.... the yea, the script is waiting for a directory to show up that never does because I'm using dmraid, not lvm.... the device already exists in /dev/mapper, but the script is looking for the vg directory
<Nafallo> how nice of it :-)
* psusi needs to poke fabbione when he gets back.... time for beer and jazz now
<yacoob> time for old-fashioned sleep
<sfllaw> 8/g 25
<sfllaw> Bleh.
* yacoob hopes to find a release in the morning :>
<sfllaw> Time to go to bed.
* Nafallo talks to a geeky gentoo girl about... stuff :-P
<yacoob> ohhh, ask her to show you her use flags :D
<yacoob> "Wanna unroll some loops with me?"
<Nafallo> lol
<Nafallo> we've already been there. I reminded her of her gf before we went to far ;-)
<Burgwork> mdz: Hoary EOL didn't make it to -announce
<jdub_> oh man, moser is now posting to d-d-l
<ajmitch> excellent :)
<Fujitsu> Hahah.
<Fujitsu> What fun.
<Burgwork> jdub_: I was commenting on that earlier in the day
<Burgwork> I feel bad, knowing that we are kind of responsible
<ajmitch> it's only a small essay
<jdub_> "let's try this user-abusive stuff that was done 10 years ago and regarded as a complete failure"
<jdub_> "*even back then*"
<jdub_> "and we *hated* users back then"
<Nafallo> hehe
<bddebian> Howdy
<Hobbsee> hey bddebian 
<jono> hey
<bhale> hello jono
<Artemis3> hi
<jono> hey
<ajmitch> hey jono 
<jono> hows it going, busy night? :P
<bhale> ARE WE THERE YET?
<bhale> is about all
<jono> heh
<jono> I am pissed and tired and aching
<ajmitch> and also questions about when feisty opens (or releases)
<zul> is it done yet? how about now
<jono> but wantedto check in
<jono> Ubuntu won best distro award tonight again :)
<zul> sweet..
<ajmitch> sweet
<Artemis3> i want to help seed torrent images...
<Fujitsu> Is Feisty released yet? Is it usable?
<jono> heh
<bhale>  /kick Fujitsu 
<Fujitsu> I've seen similar things two or three times this morning in #ubuntu.
* mode/#ubuntu-devel [-o bhale]  by bhale
<Hobbsee> hi jono 
<bhale> jono: i dont think we have done anything innovative in a long time
<jono> hey Hobbsee
<bhale> jono: if Novell ever gets their act straight we would be relegated to the back seat
<jono> bhale: doesnt matter, we kick arse and take names anyway :P
<bhale> not that Best Distro is anything more than fluff in most contexts
<jono> hehe yeah
<bhale> rock on
<bhale> http://fedora.redhat.com/
<bhale> good day to download ubuntu
<infinity> We don't have to innovate; we're brown.
<bhale> ugh.
<_ion> upstart?
<bhale> we do innovate by changing the shade of brown every 6 months
<ajmitch> morning infinity 
<infinity> Oh, upstart is innovative, but not in the sorts of ways most end users would ever care about.
<tritium> "What can brown do for you?"
<bhale> _ion: yes users are horribly excited
<infinity> (Or, rather, not in ways they SHOULD care about, though plenty seem to have opinions)
<Fujitsu> The biggest user experience change in the world, upstart.
<Artemis3> i like chocolate
<infinity> *shrug* .. Edgy was a fast and messy cycle.  I suspect feisty to be a bit more fun.
<bhale> didnt mean to kill jono's buzz
<Nafallo> infinity: aye!
<bhale> infinity: BerylByDefault!
<Fujitsu> The short cycle really stifled any big changes, I think (other than upstart)
<Fujitsu> bhale: YES!
* Nafallo looks forward to make everything upstartisch ;-)
* Fujitsu looks forward to seeing somebody being crushed by a certain somebody when they shoot down BerylByDefault.
<Hobbsee> Fujitsu: :D
<bhale> who will be crushing who, I wonder
<Fujitsu> I presume we all know who will be doing the crushing.
* _ion looks forward to the planned changes being implemented in upstart.
<jdub> Fujitsu: it wasn't the cycle, it was the desires of the hackers. :-)
<bhale> yes I am sure BerylByDefault will all end in tears
<bhale> big salty ones
<Fujitsu> Tears, as well as a mess on the ground where somebody has been stepped on.
<bhale> it horribly conflicts with LaptopHardwareSupport
<ajmitch> we'll see
<ajmitch> beryl may improve sufficiently by then
<Fujitsu> ajmitch: It's got 4 months, has it not?
<bhale> something like thaqt
<jdub> i really don't like the messaging that beryl == community version
<ajmitch> approximately
<bhale> jdub: i dont like that hackers run around trying to wrap their brain around gnome-session-save
<ajmitch> jdub: having the shiny word 'community' does imply a lot, doesn't it?
<bhale> i spelled it out in no unclear terms
<jdub> bhale: hrm?
<bhale> jdub: less-than-clueful beryl guys
<bhale> guy wanted to make a .desktop file for beryl --replace
<bhale> holy crap, miguel posted a gtk# roadmap
<bhale> i only asked 2 years ago
<jdub> heh
<bhale> Coming Soon: data binding
<bhale> this will be hot
<ajmitch> not that the 5 page presentation has much roadmap info
<ajmitch> "All the cool kids use Gtk#"
<bhale> you're right, this is useless
<bhale> but I can dream
<bhale> most of the problems will be solved by being forced into the gnome release cycle
<jdub> bhale: it's a pity they're going to do data binding at the Gtk# level though
<bhale> jdub: I guess so
<bhale> doing it in C and then marshalling into proper objects is surely more work to make a nice interface
<bhale> the codename for mono 2.0 is Sirloin
<RadiantFire> marshalling in C isn't that horrible, there is a nice makefile that can autogenerate the code for you :-)
<bronson__> Is there an easy way to get rid of *.dpkg *.diff.gz *.changes *.upload *.dsc in my build directory?
<bronson__> Just clean things out?
<bronson__> Or do all developers set up their own alias for that?
<bronson__> I find that once I upload a package, I have no interest in having all that cruft hanging about.
<_ion> Well, debclean --cleandebs removes *.{deb,changes,build} files from parent directory, but not the rest.
<fabbione> morning guys
<ogra> ugh
<ogra> time for bed ... fabbione is up
<ajmitch> morning fabbione, ogra 
<bronson__> _ion: thanks.
<bronson__> I'm looking at the changelog for the postfix package...  It's got 2.2.2 and 2.2.3 releases interleaved.
<bronson__> But those releases start with different source bases right?
<bronson__> How does the single changelog file get used for different original sources?  Isn't it more convenient just to keep a postfix-2.2.2 build tree and a separate postfix-2.2.3 tree?
<keescook> Burgwork: lifecycle wiki> yup, looks right for the dates.
<_samuel> hello
<_samuel> when will 6.10 be out?
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<BHSPitLappy> jdong, connection difficulties? :)
<jdong> BHSPitLappy: more like trying to make xchat behave
<jdong> it decided to magically send user list to /dev/null
<jdong> and it took me 20 tries of zapping xchat.conf lines to get it back
<Kagou> hi
<pitti> Good morning
<Nafallo> morning pitti :-)
<Fujitsu> Hey pitti.
<BHSPitLappy> good 2am
<pitti> so, did any catastrophes turn up?
<Fujitsu> pitti: Who knows. You're the only major dev to be in here for quite some time... I presume everybody is congregating in #canonical... :S
<pitti> Fujitsu: not really, #ubuntu-release is where most of the action was yesterday
<pitti> but yesterday all looked good
<Fujitsu> Today is good, but... you know... people discovered .pool and posted it to digg?
<Lathiat> heh
<Lathiat> yay for trying to get mirrors updated first
<Fujitsu> Yeah...
<Fujitsu> Can we get a big red `GO AWAY' put on the top of that page?
<tfheen> Fujitsu: it'll happen for fawn, yes.
<Fujitsu> tfheen: Oh good... It's been dugg, makes an appearance in #ubuntu every 20 or so seconds...
* Fujitsu speculates.
* Nafallo waits for .torrent ;-)
<Fujitsu> Can we introduce a bug into the installer that, say, blows up some hardware, and then push that to the mirrors for people to discover... Then fix it at the last minute? That would turn people of getting the non-official ISOs :P
<tfheen> Fujitsu: we could zero out the first 64 blocks of the ISO.  That'd make it rsync quickly, while being unbootable.
<Lathiat> tfheen: hrm thats not the silliest idea
<Fujitsu> I was thinking how it could be made to rsync quickly, yes :P
<maswan> .. or we could just not care?
<Lathiat> assuming everyone rsyncs
<Fujitsu> Lathiat: The mirrors do, which is all that matters.
<maswan> distribute them 600 should work for most mirrors too, except you'd only distribute them to the mirrors that sync directly
<Lathiat> i assume the mirrors dont sync from releases.  then ?
<tfheen> we have a two-tier setup internal to the DC too, afaik.
* Fujitsu runs off to dinner.
* Lathiat nods
<maswan> tfheen: well, yeah, but that could be fairly easy to solve
<maswan> tfheen: as long as you control the rsyncd.conf you can enable downstreams mirrors to get it
<maswan> anyway, my vote is for: *shrug* and not caring about silly diggs
<sivang> morning
<mdz> Burgwork: it wasn't sent to -announce
<tfheen> maswan: did we manage to run se.releases out of disk space?
<FireRabbit> hey the EdgyReleaseNotes page on the wiki still has the old artwork in the login screen shots, etc.... is anyone already working on this?
<Artemis3> pool is cool and all, but where are the torrents? torrents should always go first :P
<tfheen> Artemis3: 6.10 isn't released yet.
<Artemis3> ...
<Artemis3> yes yes whatever
<FireRabbit> someone jump the gun on ubuntu.com?
<Artemis3> just want to help seeding
<tfheen> FireRabbit: there was some miscommuncation there, yes.
<Fujitsu> tfheen: That's caused a lot of confusion in #ubuntu :S
<tfheen> Fujitsu: yes. :-(
<tfheen> we'll try to do better in six months
<Fujitsu> Hopefully :)
<Fujitsu> Having a default page for .pool would help things a lot.
<infinity> Causing confusion in #ubuntu is, admittedly, not very hard.
<FireRabbit> :)
<Artemis3> it has a . so its "hidden" isn't?
<Artemis3> i'd say torrents first :P
<FireRabbit> if nobody else is working on the release notes wiki page i can update the screenshots.. but i dont want to overstep anyone
<Fujitsu> infinity: Very true.
<dholbach> GOOD MORNING
<Artemis3> hi
<FireRabbit> hey
<maswan> tfheen: not that I can see
<maswan> tfheen: edubuntu/.pool/edubuntu-6.10-install-powerpc.iso
<maswan> tfheen: (current file, still rsyncing)
<tfheen> maswan: ok, so you're just not done yet.
<tfheen> you tend to have a gillion gbit/sec so I was surprised.
<maswan> tfheen: well, the backend store is a moderately fast nfs box
<maswan> tfheen: that's why we have a mod_disk_cache[hacked]  setup to scale to a gillion Gbit/s
<tfheen> maswan: ah.  :-)
<maswan> tfheen: seems to be going at 2M/s now, but that changes a bit over 
<tfheen> maswan: sounds good.  I'll go find some breakfast, then
* maswan wanders off to work, having just had breakfast
* yacoob parses backlog
<yacoob> cheer for hurry :)
* Fujitsu applauds fabbione.
<Fujitsu> Thankyou thankyou thankyou :D
<Artemis3> clap clap clap
<yacoob> fap fap fap?
<ajmitch> evening all
<Fujitsu> Hi ajmitch.
<seb128> what log file is used by the alternate installer?
<jordi> hmm
<mvo> seb128: wasn't that /var/log/installer/ ?
<maswan> tfheen: done
<jordi> is anyone else see firefox being closed when  you log into gmail?
<tfheen> maswan: hooray! :-)
<seb128> mvo: no such directory
<seb128> neither to / nor /target
<mvo> :/
<seb128> some package fails to install with alternate install from edubuntu i386 DVD
<dholbach> jordi: no, not here
<seb128> I get the red screen with the error and can switch to the VT with the log, there is no enough scrollback to figure the issue though
<jordi> dholbach: I have a box here where it's perfectly reproducible
<dholbach> jordi: any funky plugins?
<seb128> jordi: close, like "crash"?
<dholbach> jordi: ubuntu edgy firefox 2.0?
<jordi> brand new .mozilla/firefox
<jordi> "The program 'Gecko' received a X Window System error."
<infinity> seb128: syslog?
<dholbach> .xsession-errors?
<jordi> The error was "BadMatch (invalid parametre attributes)"
<jordi> yeah, that's in .xsession-errors
<jordi> this was a dapper box just upgraded
<seb128> infinity: that is a good reply
<seb128> fuse-utils not being happy
<infinity> Ugh.
<infinity> edubuntu-server task...
<jordi> dholbach: wow this is weird
<dholbach> jordi: hm?
<seb128> ogra: 
<seb128> Oct 26 08:01:21 in-target: Setting up fuse-utils (2.5.3-2.1ubuntu4) ...
<seb128> Oct 26 08:01:21 in-target: creating fuse device...
<seb128> Oct 26 08:01:22 in-target: creating fuse group...
<seb128> Oct 26 08:01:22 in-target: Adding group `fuse' (115)...
<seb128> Oct 26 08:01:22 in-target: Done.
<seb128> Oct 26 08:01:22 in-target: FATAL: Could not load /lib/modules/2.6.17-10-386/modules.dep: No such file or directory
<seb128> Oct 26 08:01:22 in-target: dpkg: error processing fuse-utils (--configure):
<seb128> ogra: known?
<jordi> dholbach: firefox crash
<dholbach> jordi: did you try to get a backtrace or check the strace?
<jordi> not yet
<jordi> I was trying to see if this was happening elsewhere
<jordi> ** Message: plugin_get_value 1 (1)
<jordi> I get a bunch of these
<seb128> ogra: https://launchpad.net/distros/ubuntu/+source/fuse/+bug/68344
<Ubugtu> Malone bug 68344 in fuse "Error while loading modules.dep, break edubuntu install" [Undecided,Unconfirmed]  
<jordi> hrm, disabling javascript "solves" it
<jordi> epiphany doesn't crash
<jordi> as soon as gtalk logins in gmail, it crashes firefox
<seb128> use epiphany ;)
<jordi> I do :)
<jordi> my workmate doesn't
<jordi> this will make him have an epiphany :)
<tfheen> jordi: gmail works fine for me.
<tfheen> (using ff, i386)
<jordi> does it spew any message on the console?
<dholbach> jordi: did you try an strace or a backtrace?
<jordi> I tried attaching gdb to it
<jordi> *** glibc detected *** gdb: double free or corruption (!prev): 0x09833200 ***
<jordi> hrm
<jordi> stracing
<dholbach> lloydinho: http://daniel.holba.ch/temp/PICT1459.JPG http://daniel.holba.ch/temp/PICT1464.JPG (instead of holiday pictures ;-))
<lloydinho> dholbach: awesome. Now you can prove what a lousy anthropologist I am. :-)
* dholbach hugs lloydinho
<lloydinho> Threatening the locals and drinking their beer.
* lloydinho hugs dholbach
<lloydinho> :-)
<dholbach> I thought otherwise... you were doing great ;-)
<dholbach> not "going to bed early" like doko
<jordi> dholbach: I can't get anything too sensical from this strace
<lloydinho> heh. doko was being the sensible one, for sure.
<doko> ?
<dholbach> ... for once :)
<jordi> http://pusa.uv.es/~jordi/ff.bz2
<ogra> seb128, no, not known ...
<ogra> weird
<dholbach> jordi: and doing a backtrace and breaking on gdk_x_error?
<seb128> brb
<dholbach> jordi: I can't make heads or tails of it, sorry
<cjwatson> I wonder if that edubuntu fuse thing is specific to the DVD somehow
<cjwatson> can't immediately think how but I suppose it's possible
<ogra> well, fuse-utils is installed in the same way in the CD installer
<infinity> cjwatson: I assume it applies to any installation that installs edubuntu-server in the initial package selection.
<jordi> dholbach: I still don't get anything :|
<cjwatson> depmod should be run at the end of base-installer
<infinity> cjwatson: (And may get fuse-utils installed before linux-image)
<cjwatson> infinity: I really, really doubt that's happening here
<infinity> Oh, hrm.  So this Should Not Be(TM)?
<cjwatson> indeed ...
<cjwatson> I need the full syslog
<cjwatson> "in-target" also does rather imply that it's after base-installer
<ogra> it is
<cjwatson> I doubt base-installer uses in-target - it assumes too much infrastructure
<ogra> edubuntu-server gets installed after -desktop
<ogra> its the very last thing that gets installed usually
<cjwatson> surely at the same time
<cjwatson> as in, in the same tasksel run
<ogra> yep
<infinity> So, the kernel's installed at this point, and even if it didn't do a depomod for some sick reason, LRM and initramfs-tools both would have "tried harder" to get a modules.dep in place too.
<infinity> Oh, wait.
<infinity> cjwatson: Does that CD pick a target kernel that differs from the install kernel?
<infinity> (I assume yes, since the DVDs get all the kernels, and do hw-based selectoin)
<ogra> doesnt seem like
<infinity> THAT's why the modprobe is wrong.
<ogra> /lib/modules/2.6.17-10-386/modules.dep
<infinity> Cause it'll modprobe for the running kernel, and we don't have modules for that.
<ogra> thats the same one the install CD installs
<infinity> ogra: Yeah, exactly.  The DVD boots with -386, but the chroot has -generic installed.
<infinity> (Guessing)
<ogra> argh
<ogra> thats tricky ...
<infinity> cjwatson: Is my guess on for this one?
<infinity> (that would break on ppc/ppc64 too)
<infinity> Oh, wait, no, it wouldn't.,
<ogra> i'll try soon, my rsync just finished the DVD
<infinity> Cause those pick the kernel at boot time.
<infinity> seb128: Do you have the full syslog from that DVD failure?
<seb128> infinity: yep
<infinity> seb128: Post it please? :)
<seb128> infinity: chinstrap, my userdir
<infinity> Oct 26 07:37:39 base-installer: info: Using kernel 'linux-image-generic'
<infinity> Bingo.  I win.
<tfheen> can we work around this using preseeding?  (Force it to install both kernels)?  If so, we can roll new edubuntu DVDs and test those and then release those tomorrow
<infinity> Ugly solution, but I guess it could work.
<infinity> Or is there a preseed to just turn off base-installer's automatic kernel selection instead?
<ogra> i'm fine with that, as long as we have an edubuntu DVD
<tfheen> I didn't say it was pretty. :-)
<infinity> That might be less ugly.
<ogra> loosing i386 would be very odd 
<cjwatson> infinity: ah yes, the DVD might well do that
<cjwatson> we can preseed it
<cjwatson> um, give me a minute ...
<cjwatson> we can't force it to install both kernels, but we can force it to install just -386
<infinity> That seems the best solution right now.
<ogra> it installs -386
<ogra> we need to install just -generic if the DVD boots with it, or am i wrong
<infinity> Other way around.
<infinity> The DVD boots -386, it auto-selects -generic as the better kernel and installs that.
<ogra> doesnt the DVD boot the -generic ?
<ogra> ah
<cjwatson> what infinity said
<ogra> right
<ogra> my bad
<cjwatson> the problem is that -386 ISN'T there
<ogra> argh
<cjwatson> I mean, isn't installed
<cjwatson> technically, this preseeding change affects all edubuntu images
<cjwatson> (i386)
<cjwatson> actually, yeah, that's a point, how does this not affect the normal CDs?
<cjwatson> edgy-alternate-i386.list:/pool/main/l/linux-source-2.6.17/linux-image-2.6.17-10-386_2.6.17-10.33_i386.deb
<cjwatson> edgy-alternate-i386.list:/pool/main/l/linux-source-2.6.17/linux-image-2.6.17-10-generic_2.6.17-10.33_i386.deb
<cjwatson> base-installer should pick -generic there too
<infinity> The normal CDs don't have -generic in ship?
<infinity> Oh, they do?
<cjwatson> tfheen: HOLD
<infinity> Then it should affect both, yeah.
<fabbione> the normal CD probably don't install fuse by default?
<cjwatson> it should
<cjwatson> in the edubuntu-server install
<tfheen> cjwatson: holding.
<ogra> right, it does
<infinity> cjwatson: That's the ubuntu-alternate list, no?  I don't see -generic in edubuntu-install.
<cjwatson> oh, you're right
<cjwatson> ok, phew, false alarm
<cjwatson> right, so technically this preseeding fix affects all Edubuntu images, but it'll be a no-op for CDs, so we won't rebuild
<ogra> right
<tfheen> since dvds go to releases.ubuntu.com, I was planning on holding them off for a few hours anyway.
<mdz> cjwatson: so the issue is limited to the edubuntu DVD, yes?
<tfheen> s/go/don't go/
<cjwatson> tfheen: they go to cdimage
<cjwatson> mdz: yes, only i386
<mdz> we can pull it
<cjwatson> I've already rolled out the debian-cd fix
<cjwatson> it can trivially be rebuilt with no archive changes
<cjwatson> s/fix/workaround/
<tfheen> cjwatson: please don't do that yet.
<cjwatson> yeah, I'm not going to until you're finished with releases.u.c
<tfheen> good, thanks.
* ..[topic/#ubuntu-devel:tfheen] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs |  Edgy is released.
<ajmitch> tfheen: well done
<crimsun> 'grats, all.
<tfheen> congrats everybody
* ..[topic/#ubuntu-devel:cjwatson] : Ubuntu Development (not support, even with edgy ... or feisty) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Edgy is released.
<StevenK> tfheen: Nice!
<ajmitch> good work everyone :)
<cjwatson> tfheen: can I rebuild the edubuntu i386 DVD now?
<elkbuntu> nice work everyone :)
* StevenK looks for the annoucement.
<tfheen> cjwatson: yeah, should be fine.
<StevenK> tfheen: So now you're off to sleep for 3 days? :-)
<ivoks> congrats
<tfheen> StevenK: we still have xubuntu, ports and DVDs to do.  But _then_.
<ogra> yippie !
<StevenK> tfheen: Heh
<cjwatson> $ bzr push --create-prefix sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.feisty
<StevenK> Neat.
* sivang opens a bottle of champage
* ajmitch fetches
* StevenK creates Edgy ISOs to take to the office tomorrow.
<yacoob> allright, where do I suck up to? :)
<tfheen> cjwatson: AIUI, you don't need create-prefix any longer.
<cjwatson> habit :)
<seaLne> should torrents work? they aren't listed on http://torrent.ubuntu.com:6969/ and get rejected
<dholbach> sfllaw: I think you can stop testing the CDs now - we just released
<thom> well, there's the benchmark - http://www.j5live.com/?p=266
<sfllaw> dholbach: Yay!
* sfllaw hugs dholbach.
<sfllaw> But not really, because I am hacking up a lung.
<sfllaw> And I would hate to give dholbach the plague.
<dholbach> oh no! not the plague again!
<ajmitch> what a way to celebrate the release
<ajmitch> sfllaw: I hope you get some rest :)
<cjwatson> ogra: updated Edubuntu i386 DVD available
<cjwatson> seb128: would you mind retesting edubuntu/dvd/i386/server ?
<ogra> ok, it will take me some time to rsync
<cjwatson> 20061026
<Ng> congrats on the release :)
<Artemis3> congrats
<imbrandon> cen someone fix the BT tracker please "rejected by tracker - Requested download is not authorized for use with this tracker."
<cjwatson> Artemis3: btw, we deliberately don't put torrents up until we're done, because at any point up to the last moment we might have to stop and respin for some showstopper
<seb128> cjwatson: not at all, will take some time to rsync, burn a new DVD and redo an install though, I'm starting on it now and will have lunch while it's working
<cjwatson> Artemis3: .pool is just there so that third-party mirrors can be there in advance of the general public; if we have to respin, it typically does not take long for them to rsync updates
<Artemis3> cjwatson, i understand that, what i mean is to distribute bittorrent only first, and then, couple of hours, or a day layer the rest
<cjwatson> Artemis3: I don't see us doing that, no
<cjwatson> thanks for the suggestion but it has been made before and we've decided against it
<Artemis3> ok just wondered about it no problem
<imbrandon> cjwatson, are we "official" now ?
<cjwatson> imbrandon: yes
<imbrandon> kk thanks
* bhale hugs tfheen 
<imbrandon> the BT will be updated soonish? ( i like to seed for people )
<imbrandon> great work fellas btw , everyone ( too long of list to go though )
<cjwatson> imbrandon: it should be, but IIRC torrent.ubuntu.com is having load problems
<Artemis3> dht is working tho
<imbrandon> cjwatson, ok no worries, rsycing now anyhow still
<Artemis3> get the torrents :)
<cjwatson> dht?
<seaLne> torrents are fine now
<imbrandon> dist host tracking
<cjwatson> ah, good
<cjwatson> I'm not convinced, torrent.ubuntu.com:6969 lists lots of ancient images that were deleted long ago
<cjwatson> elmo: ?
<cjwatson> oh, well, maybe not ancient, but definitely gone
<imbrandon> yup working now
<imbrandon> seeding *-desktop.iso's
<yacoob> hm
<yacoob> how come there are >1 images of same type?
<yacoob> (namely, dapper-alternate-i386)
<cjwatson> yacoob: old daily builds
<cjwatson> I'll purge those
<tfheen> imbrandon: torrent.u.c is getting there now.
<imbrandon> tfheen, yup yup, got my seeds on two networks running now
<imbrandon> thanks
<cge> tfheen: It is working, or it is going to be working soon?
<tfheen> cge: it's working for some of the images, but not all
<cge> tfheen: ah
<elmo> cjwatson: looking
<ubuntu_demon> My congratiolations to you all! 
<mdz> thanks
<highvoltage> good job, Ubuntu team, and congratulations!
<highvoltage> especially on the innovative stuff like upstart.
<highvoltage> inovation++ :)
* sivang awaits anxiously for feisty to open to upload stuff ;)
<ajmitch> sivang: patience..
<StevenK> sivang: Give them a few days to get over releasing Edgy first. :-)
<shackan> does anybody know what happened to chmj ?
<sivang> true, I said I was anxious , nothing more :)
<sivang> I believe a week could go between rlease and reopneing
<ubuntu_demon> bye guys
<cjwatson> shackan: he's working for impi linux now
<shackan> cjwatson, thanks
<pirast> congratulations everyone to the release of ubuntu 6.10 :-)
<tfheen> maswan: we're not maxing out your 2gbit? :-(
<yacoob> upstart makes me wonder
<yacoob> that's pretty brave, isn't it?
<Spads> edgy, even.
<highvoltage> *very* :)
<Robot101> yacoob: it's in a compatibility mode, mostly it just behaves like init :)
<Keybuk> well, it always behaves "like init" :)
<yacoob> Robot101, aw, so I won't stumble around looking for my /etc/init.d? :)
<Keybuk> it will always run init scripts in /etc/init.d and /etc/rcX.d because that's the easiest way to maintain backwards compatibility
<Keybuk> and it's also the most sane way to develop it
<Keybuk> otherwise I'd need to work solidly and convert every single package on the same day
<Keybuk> with the compat stuff, I can do them one at a time
<Nafallo> tfheen: time is only 13, schools stop at 15 or so, don't they? :-)
<highvoltage> Keybuk: it is awesome though. an init replacement is long overdue. props to you for making Ubuntu such a trailblazer :)
<mnepton> Upstart is a fanatstic idea. i just don;t know if i really trust the people behind it, though.
<Keybuk> mnepton: ?
<mnepton> (mostly because Keybuk won't buy me candy)
<Keybuk> I haven't said I won't buy you candy :)
<Nafallo> hehe
<Keybuk> I also haven't said I won't throw you in SF Bay :p
<tfheen> Nafallo: and the US is still mostly asleep.
<mnepton> Upstart is a fanatstic idea. and the team behind it is comprised of the exact people i would choose.
<yacoob> highvoltage, as long as trailblazer don't turn into shooting star... :>
<Keybuk> yacoob: but they'
<Keybuk> er so pretty ...
<Nafallo> tfheen: yea. but are they using the se. one?
<Keybuk> (gnargh, WHO PUT US KEYBOARDS ON THESE PIECES OF CRAP?!)
<yacoob> well, as for me it's only a "whoa, interesting change"
<Nafallo> Keybuk: the vendors!?
<Nafallo> :-)
<yacoob> I'm fine with standard init schema
<mark> Won't mirror without dists/edgy-updates/main/debian-installer/binary-amd64/Packages.gz signature in Release at /usr/bin/debmirror line 1300.
<elmo> t.u.c should be happier (or getting that way) now
<Gloubiboulga> tfheen, is there anything we (Jani or I) need to do for the xubuntu release?
<tfheen> Gloubiboulga: tell me if you don't want to release.  I was planning on doing xubuntu right after the ubuntu and kubuntu dvds were published
<tfheen> (which is happening now)
<Gloubiboulga> tfheen, I'm happy with a release, but I'm going to mail Jani to have his agreement
<_lemsx1_> I want to congratulate you guys for the new release!
<tfheen> thanks. :-)
<_lemsx1_> way to go. seriously. I've been evangelizing (switching people to Linux) a lot more than ever ;-)
<_lemsx1_> my goal for 2007 is to convince my boss to trial Linux on the desktop at work ;-)
<TheMuso> On behalf of the a11y team, I'd like to thank all the devs for supporting us to get a lot of accessibility related features into Edgy. I believe this is the most accessible release of any Linux distro to date, and things can only get better from here. Thanks for your help and support guys. Much appreciated.
<tfheen> TheMuso: feisty'll be even better.
<tfheen> TheMuso: you coming to UMV?
<TheMuso> Unfortunately not.
* dholbach hugs TheMuso
<heno> For feisty we'll aim for Just Works braille support do deafblind people can do an independent install as well
<heno> That will definitely be a first :)
<TheMuso> heno: Just works braille won't be nearly as easy as one might think, as there are a lot of serial Braille displays around.
<TheMuso> Mine is one of them.
<StevenK> There's like what, ten different protocols?
<tfheen> since standardisation is for wimps
* StevenK is trying to remember the emacspeak config question.
<_lemsx1_> umm... the shipit requests will be Edgy or Dapper? there is no way to choose
<heno> TheMuso: Right, but Dave and I have a plan (Dave being the brltty maintainer)
<TheMuso> Oh nice.
<ogra> _lemsx1_, dapper only
<heno> TheMuso: I'll forward you some emails
<TheMuso> The hardest bit I think will be auto-detection.
<TheMuso> heno: Cool. I'd be very interested to have a look.
<_lemsx1_> ogra: thanks. good to know
<heno> Will have to use a very simple config system when that fails
<TheMuso> Yeah.
<_lemsx1_> ogra: will Edgy be shipped?
<heno> TheMuso: will forward now
<TheMuso> Thanks.
<gnomefreak> lemsx1: only for loco teams that were approved
<heno> it's party in the wiki too
<gnomefreak> _lemsx1_: please keep general edgy topics/ support in #ubuntu this is a development channel
<TheMuso> So what voip solution is being used for the next UDS? Has that been finalized yet?
<tfheen> TheMuso: SIP, I think.
<TheMuso> Oo nice.
<tfheen> and conference phones, or something.
<maswan> tfheen: sure you are
<tfheen> I wonder how that'll work out in practice
<TheMuso> Yeah.
<ogra> tfheen, surely better than paris
* StevenK might have to make an effort to attend some sessions.
<tfheen> maswan: now we are, yeah.  We were just dibbling around 1.5Gbit for a while.
<TheMuso> How many hours behind UTC is the UDS location?
<StevenK> -5, from memory
<TheMuso> StevenK: Thanks.
<maswan> tfheen: ah, boring :)
<Spads> No
<gnomefreak> i hop emore than that
<TheMuso> Looks like I'll have to do all-nighters.
<Spads> -8
<Spads> West Coast
<gnomefreak> im -4
<StevenK> Oh right.
<Nafallo> maswan: you have like 2.5Gbit, or?
<Spads> PST8PDT
<TheMuso> Become a night owl for a week.
<gnomefreak> they are -7 or -8
<maswan> Nafallo: the uni has 2.5, ACC has 2
<Spads> -7 now, -8 during UDS
<StevenK> TheMuso: Heh, if I do that, my manager won't like it very much. :-P
<gnomefreak> thats sounds right
<TheMuso> StevenK: My sympathies.
<Nafallo> maswan: then we need to push 100Mbit more then ;-)
<TheMuso> Added to that, I think we'll be +11.
<ogra> cjwatson, rinning the edubuntu DVD install in qemu here, base install just picked -386 ... seems to be fine 
<_lemsx1_> gnomefreak: yes, I know that. I just figured you guys would know better about that topic. Is development going on today? I thought you were celebrating or something :-)
<TheMuso> Wow. Gets confusing quickly.
<ogra> *running
<StevenK> TheMuso: It so doesn't, they'll be 19 hours behind us.
<gnomefreak> _lemsx1_: with releases every 6 months there is no time to celebrate ;)
<tfheen> thom: regarding matching fedora -- we've torrented out about 2.5k images already.  A bit more than an hour into the release. :-)
<lotusleaf> Thank you to all the developers for another beautiful release.
<TheMuso> StevenK: I just worked that out.
<_lemsx1_> gnomefreak: lol. I know. well, keep up the good work
<TheMuso> Um ok.
<siretart> congrats for the release!
<TheMuso> Thats not too bad.
<TheMuso> Start at approx 4 in the morning.
<TheMuso> I can do that.
<StevenK> It probably means most of the sessions will be going on while I'm working.
<leonel> THANK YOU ALL for edgy ..  GOOD WORK  EXELENT WORK  thank  you all  again 
<thom> tfheen: yah :-)
<TheMuso> heno: Thanks.
<tfheen> Gloubiboulga: gotten a response from janimo yet?
<Gloubiboulga> tfheen, no :/
<tfheen> Gloubiboulga: ok, I can just hold off for a while, then
<Gloubiboulga> he was fine with the 20061023 isos, so I guess he'll be fine with the new ones
<tfheen> ogra: you're making sure the edubuntu dvd gets testing?
<ogra> tfheen, its running
<ogra> diung a qemu install and already saw -386 passing by
<ogra> so it looks good, but i want it to finish first 
<tfheen> I hope you're planning on testing the live bits, etc too?
<lritter> can someone perhaps have a look at this one
<lritter> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63418
<Ubugtu> Malone bug 63418 in linux-source-2.6.17 "CPU soft lockup during bootup" [Medium,Confirmed]  
<ogra> tfheen, sure, but there was nothing that could have affected them 
<ogra> so i dont expect regressions
<doko> cjwatson: kubuntu-meta was accepted for edgy?
<janimo> Gloubiboulga: sure, we're ready :)
<janimo> tfheen: xubuntu latest images good to go
<Riddell> doko: where?
<doko> Riddell, cjwatson: bug 66923
<Ubugtu> Malone bug 66923 in kubuntu-meta "kubuntu-desktop doesn't depend on openoffice.org-kde" [High,Fix released]  http://launchpad.net/bugs/66923
<Gloubiboulga> janimo, ok :)
<Riddell> doko: yes, that got in
<doko> Riddell: but not on the CD?
<Riddell> doko: was when I tested, kubuntu-desktop on my amd64 depends on openoffice.org-kde
<sladen> ogra: do you have release notes/fodder about what's in Edubuntu 6.10 ?
<ogra> sladen, yup
<sladen> ogra: I couldn't see it anywhere obvious on the Edubuntu site (eg. Frontpage, download links)
<ogra> but we're still fiddling with the website and i still test the last change to the DVD
<ogra> http://www.edubuntu.org/Download
<cjwatson> doko: yes
<sladen> ogra: I was thinking more http://kubuntu.org/announcements/6.10-release.php or http://www.ubuntu.com/news/610released
<ogra> https://wiki.edubuntu.org/EdgyAnnouncementEdubuntu
<mark> it seems like the Release files under dists/edgy-{updates,security,backports} are not up to date
<ogra> RichEd will send it out as soon as we have sorted our stuff
<tfheen> janimo: yay, good.
<cjwatson> mark: I think those will be sorted out next time the publisher runs, but we have a few other things to do first
<mark> I can imagine :)
<mark> congratulations with the release, btw
<cjwatson> thanks
<cjwatson> I'll check out the Release files once we're back in somewhat normal operation
<mark> thanks, that'll make my mirror work again
* simira celebrates the release with some marcipan cake
<Nafallo> ooh
* Nafallo joins simira on that one :-)
<bhale> EdgyReleaseNotes still mentions Beta several times
* maswan will be making cake tonight
<janimo> Riddell, ogra, you both have separate announcements and send them to ubuntu-announce as well I assume?
<ogra> janimo, yep
<Riddell> janimo: yes
<janimo> thanks
<ogra> i think Riddell sent his already
* janimo wonders whether all the LTSP 5 thing should be mentioned wrt the xubuntu alternate CD as well
<Riddell> I did, I should poke mdz to check and let it through
<Riddell> mdz: polite poke
<ogra> janimo, as you like 
* hunger is waiting for feisty now:-)
<janimo> Gloubiboulga: can you think of anything new I missed from the RC annoucnement that should be mentioned?
<hunger> Congratulations on getting edgy out!
<janimo> Gloubiboulga: gnome-app-install and new panel applets is what I can think of now
<Gloubiboulga> janimo, I need to read it again 
<janimo> ogra: yes, I am reluctant since I haven;t tried LTSP out and had no feedback so I could not claim all those LTSP-5 features working
<janimo> as I am not sure they are all server side or you tweaked gnome and other system bits to have it all working
<janimo> I'll settle for juste mentioning LTSP as for dapper
<ogra> did you solve the "users can shutdown the server in xfce" bug ?
<janimo> ogra: partly. The user can solve it by editing xfce kiosk settings file.
<ogra> ah, great
<janimo> ogra: for dapper even that did not work
<ogra> is that documented anywhere ?
<janimo> ogra: I'm afraid not, I guess we'll have to add it to the newly launched website :)
<ogra> we have requests about that bug from time to time ...
<janimo> ogra: indeed the bug is in LP and is open AFAIK
<ogra> right
<Gloubiboulga> janimo, I can't think of anything else...
<janimo> ogra: there was no LTSP/xfce testing I know of during edgy, at least I got no feedback so I wouldn;t be surprised if bus started showiung up starting today :)
<janimo> Gloubiboulga: I'll mention the new site as well
<janimo> s/bus/bugs/
<Gloubiboulga> janimo, good idea
<ogra> janimo, ok, i'll prepare for a bugflood then :)
<janimo> ogra: :)
<highvoltage> janimo: sorry, I did test an early RC of the xubuntu alternate cd with ltsp and it did work (meant to provide it sooner, I know it's way too late now)
<ogra> yay, fuse-utils installed fine this time ... cjwatson sees it worked .... 
<ogra> *seems
<highvoltage> janimo: for what it's worth, in the new LTSP there's a script where you can test LTSP using qemu as a thin client, that will make it easier for you to test it in the future
<highvoltage> ogra: \o/
<cjwatson> ogra: great
<cjwatson> tfheen: wanna publish edubuntu DVDs, then?
<cjwatson> oh, aren't xubuntu DVDs going to have the same problem?
<tfheen> there are no xubuntu DVDs
<tfheen> so no.
<cjwatson> that works :)
<mvo> janimo: have you any idea about bug #68027 ?
<Ubugtu> Malone bug 68027 in update-manager "sudo update-manager -c -d crashes during xubuntu upgrade" [High,Confirmed]  http://launchpad.net/bugs/68027
<tfheen> cjwatson: care to archive the xubuntu beta release too?
<mvo> janimo: or, for that matter. have you seen it during a normal upgrade?
<cjwatson> tfheen: done, not synced
<tfheen> cjwatson: I just started a sync, I can do another one in ten minutes or
<tfheen> +so
<tfheen> ogra: tell me when you want your DVDs published
<seb128> I've an edubuntu alternate install from DVD running atm
<seb128> should be fine to confirm if the bug is fixed soon
<janimo> mvo: I have only done clean installs of edgy recently so did not encounter the bug
<janimo> as I commented there I have no idea why it happens
* janimo looks again at LP
<janimo> highvoltage: so xubuntu LTSP works ok?
<mvo> janimo: I really wonder why it happens on xubuntu but not on ubuntu (even if I install there with a  clearlooks theme)
<janimo> mvo: wird, I thought at first that it had to do with the alternate depends in xubuntu-meta. Now I have no idea
<highvoltage> janimo: it worked ok with the first xubuntu alternate beta. I do regret that I didn't have time to test with any newer iso's
<janimo> mvo as those changes slightly since dapper
<janimo> highvoltage: well let's hope it did not break in the meantime :)
<highvoltage> janimo: for sure :)
<highvoltage> I can't think of a reason that it would break.
<mvo> janimo: i reproduce it here in a upgrade test and this error (from gtk) took down the complette desktop, only the background was visible, everything else gone with gdk errrors. pretty scary :/
<janimo> releasing xubuntu is half faith, half Q&A
<tfheen> janimo: xubuntu images should be published now.  Please check torrents, etc
* tfheen goes to have a break
<janimo> mvo: could be a gtk bug that is so evil that is only triggred on xubunt?
<janimo> tfheen: thanks
<mvo> janimo: it must be something like this. might be a ordering issue. if e.g. clearlooks is upgraded before gtk and the gtkrc is reread then this might trigger it. but I have no idea why a) gtkrc is re-read b) gtk does not ignore that problem
<Fujitsu> tfheen: You deserve one!
<mvo> janimo: I'm sorry, I only reproduce it yesterday so I didn't managed to figure out what exactly went wrong :/
<mvo> janimo: /usr/share/themes/Clearlooks/gtk-2.0/gtkrc:59: error: unexpected identifier `animation', expected character `}' is what makes it crash, but I just checked, gtk itself is upgraded before this happens
<janimo> mvo: well it's ok, we can just tell people to reinstall and not recomment dist-upgrade for now.
<janimo> but  it is weird how come ubuntu escapes this
<mvo> indeed
<janimo> mvo, is there a way to recover from the crashed dist-upgrade?
<janimo> mvo: should I explicitely mention in the release note not to use dist-upgrade?
<mvo> janimo: the usual dance: "dpkg --configure -a ; apt-get install -f ; apt-get dist-upgrade ; apt-get install xubuntu-desktop" 
<mvo> janimo: when do you plan to send those out? will I have time to do another upgrade test "by-hand" (i.e. without the upgrader on a terminal)?
<janimo> mvo, if you wish I can wait
<janimo> mvo so is this something that can be solved now that the archive is frozen?
<janimo> mvo, so there's no hurry 
<mvo> janimo: hard to say, but probably not :/ 
<janimo> mvo either way I can hold off the announcement until you think we have some workaround or advice
<janimo> or anything worth holding for :)
<gnomefreak> mvo: update-manager is for buuntu/k/x/ed right?
<gnomefreak> ubuntu/k/x/ed
<janimo> mvo I assume it's the same error with apt-get dist-upgrade?
<mvo> gnomefreak: in general yes, but we are currently investigating a issue with xubuntu - we may have to recommend not using it there
<mvo> janimo: that is what I would like to figure out
<gnomefreak> mvo: kubuntu is fine though
<Gloubiboulga> janimo, the usual dist-upgrade is OK
<Gloubiboulga> I tested it yesterday
<janimo> is upgrade-manager doing something smarter than apt- dist-upgrade besides being better looking?
<seb128> janimo: yep
<seb128> janimo: the dist-upgrader mode you mean?
<gnomefreak> janimo: it should grab missing -desktop packages downgrading libgl1-mesa-glx if user is running compiz/xgl/stuff
<seb128> janimo: it's installing resolving conflicts, remove deprecated packages, install new packages on update, etc
<gnomefreak> downgrade maybe wrong term
<janimo> ok, I have only  used upgrades form one release to another once I think, so am not very familiar with what these tools do
<ogra> tfheen, the edubuntu DVD iso is definately fixed now ... starting a live/ubiquity test to be safe now ...
<seb128> tfheen, ogra, cjwatson: edubuntu i386 alternate install worked fine for me too with the updated DVD
<ogra> seb128, thanks for the test :)
<seb128> np
<doko> pitti: are ve, ts, ss, ns/nso unsupported languages?
<pitti> doko: we have langpacks for -ts
<pitti> but none for the others
<doko> pitti: are the locales available?
<gnomefreak> have the dvd images been released?
<_lemsx1_> gnomefreak: people are downloading the cdimages.ubuntu.com/dvd/current one
<gnomefreak> ok ty
<jsgmobile> Its at cdimage.u.c
<morgs> http://releases.ubuntu.com/6.10/MD5SUMS only lists md5s for -rc- images...!?!
<gnomefreak> morgs: yes
<pitti> doko: yes, locales are available
<cjwatson> morgs: looks fine from here; reload
<vinze> Jani told me to talk to you
<vinze> Because there's a problem with the Xubuntu torrents
<janimo> vinze: hi
<vinze> Hey
<janimo> vinze: I think it's tfheen that we need to tell
<vinze> Wasn't I talking to him? :S
<janimo> vinze: you did not talk to anyone in particluar :)
<infinity> What's the problem with the torrents?
<vinze> I messages him with "hey" and then I though he said "ehy" :S
<vinze> Anyway, you get an error message
<vinze> Requested download is not authorized for use with this tracker. 
<Nafallo> oh. that bug again...
<vinze> Can it be solved?
<Nafallo> I guess the admins are aware. they was last time.
<Nafallo> Znarl, elmo ^ just in case
<infinity> 08:05 < elmo> infinity: but in this case, it's not a tracker problem
<infinity> 08:05 < elmo> there's no released xubuntu stuff in the torrent tree on lithium
<infinity> tfheen: ^^^
<vinze> So what to tell in #xubuntu?
<Nafallo> vinze: that's in being worked on :-)
<ogra> vinze, to wait ...
<vinze> OK
<vinze> Thanks
<Nafallo> s/in/it/
<seb128> there is no distro team meeting today, right?
<jdong> seb128: have you been able to reproduce the nautilus 100% CPU bug?
<seb128> jdong: no
<jdong> :(
<jdong> man that sucker is annoying
<zul> seb128: no according to the topic
<Nafallo> jdong: I have that from time to time.
<jdong> seb128: have any of the posted backtraces been useful?
<seb128> jdong: no
<Nafallo> jdong: almost always when the totem-thumbnailer is running...
<jdong> seb128: what would be needed to be more helpful?
<jdong> Nafallo: I get it when doing a download, or encoding an AVI, and viewing that folder in nautilus
<jdong> it doesn't happen immediately, but give it a bit of time and it'll spike CPU usage
<jdong> hitting refresh really helps it along though
<seb128> jdong: sending a patch
<Nafallo> jdong: sounds about right.
<Nafallo> I have that on my amd64.
<seb128> jdong: I've a backlog of around 380 desktop bugs atm, I don't have an afternoon to spend on that one, sorry
<jdong> seb128: ok...
<jdong> seb128: do you think Dapper's nautilus would build/work in Edgy? :D
<bhale> jdong: it would rebuild alright
<bhale> and run
<jdong> that might be worth my time to do...
<jdong> this bug is pretty crippling for me... have to spend my time worrying about telling nautilus to look away any time I do something
<jdong> :)
<seb128> jdong: I doubt that's a nautilus bug
<jdong> hmm, you think it's gnome-vfs or something?
<seb128> gnome-vfs2 inotify code yep
<seb128> and downgrading gnome-vfs2 would not be a piece of cake
<seb128> really not
<jdong> no it wouldn't
<seb128> new gnome-vfs2 uses dbus etc
<jdong> hmm, maybe I'll go check FC6
<seb128> you have faster to reinstall dapper
<jdong> see if they have the bug
<seb128> why wouldn't they?
<seb128> we don't patch gnome-vfs2 for that
<jdong> seb128: they might've fixed it in their distro, but it hasn't reached upstream yet? 
<seb128> I doubt of it
* jdong is hopelessly optimistic
<seb128> I looked at FC patches before edgy for a bunch of tarballs
<seb128> and gnome-vfs and nautilus were some of them
<seb128> and I grab patches useful
<seb128> I don't think there was anything for that issue
<tfheen> cjwatson: doesn't publish-release always put stuff in the torrent tree?
<cjwatson> tfheen: not if you're only pre-publishing
<cjwatson> tfheen: but otherwise yes
<tfheen> elmo: /srv/cdimage.ubuntu.com/www/torrent/xubuntu/releases/edgy/release seems pretty populated to me?
<tfheen> elmo: do we just need a new sync-mirror?
<infinity> seb128: How do you add arbitrary headers with Evolution?
<infinity> seb128: RichEd needs guidance, and I use Tbird, mutt, and mailx exclusively. :)
<seb128> infinity: I think you don't
<infinity> seb128: Crazy talk.  And they call this an MUA?
<seb128> to be honest I never had to add one I think ;)
<seb128> upstream wishlist about that: Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.
<seb128> ups
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=201186
<Ubugtu> Gnome bug 201186 in Mailer "ability to add custom headers in composer" [Enhancement,Reopened]  
<infinity> No activity for over a year.  Guess that answers that.
<elmo> tfheen: it hadn't come through - forcing a sync now
<sivang> hi
<pirast> hi sivang
<sivang> hi pirast 
<sivang> hmm, loco team channel logs are also on fabbione 's machine?
<fabbione> sivang: no
<fabbione> you need to ask smurf 
<sivang> fabbione: okay, thanks, I actually need stuff removed from there
<sivang> I've had some bad politically incorrect spammer over
<cjwatson> sivang: I wouldn't stress, if it's the same guy who's been on lots of other Ubuntu channels, I'd advise just ignoring him
<sivang> cjwatson: do you recall nicks?
<smurf> sivang: I can edit the logs if absolutely necessary, but ...
<fabbione> smurf: my policy is not to edit them...
<fabbione> smurf: otherwise it becomes a mess
<ogra> sivang, Cyorxamp
<keescook> howdy all
<gnomefreak> he was taken care of if i understood correctly by staff :)
<ivoks> smurf: btw, locobot_3 has wrong URL under ircname
<smurf> ivoks: thanks, will fix
<ivoks> smurf: it misses 's' :)
<tfheen> elmo: thanks.
<agutierr> hello all. I have a question about preseed. Someone knows how I can preseed security host ?
<cjwatson> apt-setup/security_host
<zMott> what with all the new mono items 
<zMott> is this part of the new frame work?
<Windkracht8> Hello, does anyone know when qt 4.2 will be available in the Ubuntu repository's?
<cjwatson> Windkracht8: it's already there - libqt4-core, libqt4-gui, libqt4-dev, etc.
<cjwatson> edgy
<Windkracht8> cjwatson, but not for dapper
<cjwatson> Windkracht8: no
<cjwatson> it won't ever be in dapper
<Vaske_Car> does anybody know why I get dark background as soon as X start? Turned off PC yesterday normaly and today it does not start..
<Windkracht8> I just looked at my mail, I
<Windkracht8> 've got a new mail from ubuntu-announce, looks like I'm updating
<Windkracht8> Why aren't we getting free cd's for edgy?
<blueyed> Is there a channel for the website? http://www.ubuntu.com/products/GetUbuntu/download?action=show&redirect=download does not work with Konqueror (the javascript click-open part).. :/
<blueyed> ..probably because of the invalid HTML on that page..!
<Windkracht8> 6 euro for a cd!
<LarstiQ> tempting
<cjwatson> CDs will be sent out to local community teams for local distribution, to save on shipping costs
<Burgwork> mdz: is there a reason the EOL was not sent to -announce? previous ones were
* Windkracht8 going to update
<Windkracht8> bye all
<heno> fabbione, BenC: does the server kernel have the speakup module?
<heno> we've had people wanting to install it that way
<BenC> heno: yeah, it does
<heno> cool, thanks
<surak> seb128: ping
<seb128> surak: pong
<surak> seb128, I have a strange bug here. I have a postscript file, which doesn't show very well in both evince and gv. Logically I would suppose the bug is in ghostscript. However, gs-esp shows it fine.
<surak> this confuses me. Where should I post the bug? :)
<seb128> evince and gv probably
<surak> gv opens up a warning, in blank, about ghostscript. evince says "loading" forever.
<sladen> surak: can you file a bug and attach the file
<sladen> surak: and CC me
<surak> sladen: will do
<LarstiQ> BenC: attached some info to bug 61743, hope it will be of use 
<Ubugtu> Malone bug 61743 in linux-source-2.6.17 "invalid opcode on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61743
<surak> Let's see if launchpad can handle the file. I didn't gzipped it, it's about 77mb - duh
<seb128> surak: better to gzip it then
<bddebian> Howdy
<surak> hi
<mdz> Burgwork: yes, it was decided that it was not relevant to enough of the folks on that list
<keescook> I need a bigger desk
<mdz> Riddell: didn't get your earlier poke; you'll need to tell me what it was about
<pitti> keescook: too many bags with sweets, candy, and bubble gum? :)
<Riddell> mdz: just the kubuntu ubuntu-announce post
<keescook> pitti: hah.  no, the trick-or-treat candy is safely hidden in the kitchen.
<surak> sladen: https://launchpad.net/distros/ubuntu/+source/evince/+bug/68412
<Ubugtu> Malone bug 68412 in evince "Evince doesn't show a .PS file correctly." [Medium,Needs info]  
<Burgwork> mdz: hmm, ok. I would consider EOL to be a fairly major announcement
<keescook> it's so nice to use edgy on my i386 laptop.  everything works.  :)
<jdong> keescook: obviously you need to put beryl or something on it then :D
<keescook> jdong: heh.  I did earlier; it got reinstalled a few times over the last few days, though.  :)
<jdong> hehe
<jdong> I gotta admit, it's fun
<jdong> and beryl's making it a lot easier than compiz from before...
<keescook> jdong: that's for sure!
<sladen> surak: remember to bzip2/gzip the file next time :)
* sladen downloads it at 100Mb, compresses, downloads at 4Mb
<mdz> Burgwork: how many ubuntu-announce subscribers are still running hoary?
<Burgwork> jdong: I am deeply concerned about the beryl fork
<Burgwork> mdz: probably not many, but it is an announcement, one that needs to be widely shared
<jdong> Burgwork: I don't know nearly enough about the circumstances of the fork...
<surak> sladen: I already pressed the "send" button before verifying its size. Then I got afraid of cancelling and doing something bad in launchpad. And I was curious if LP could handle it :)
<jdong> so I can't really make an informed opinion about it
<Burgwork> jdong: my issue is more that if we choose beryl, we are diverging from what everybody else is doing, for no clear gain
<jdong> Burgwork: the beryl-manager is one  good reason
<jdong> and its effects are definitely better to me
<Burgwork> WMs must be rock solid
<jsgotangco> its already a fork, so its not everybody now, there are sombody doing another thing
<jdong> Burgwork: beryl-manager hasn't crashed on me yet... I've only crashed it once by sending a kill to it
<jsgotangco> s/are/is
<Burgwork> jsgotangco: it existing and us shipping it are two different things
<jdong> to test beryl's fallback
<jdong> and beryl falls back to metacity very well
<Burgwork> then we maintain two WMs
<Burgwork> which truly sucks
<jdong> Burgwork: no matter what there will be a group of people interested in maintaining beryl....
<jdong> I'm sure the same can be said about compiz
<jdong> anyway
* jdong is off for a few hours....
<Burgwork> jdong: something existing and us shipping it are two different things
<Burgwork> there is lots of stuff in universe we don't much care about
<jdong> Burgwork: true... but still
<jdong> anyway
<jdong> I really don't care which is default
<jdong> as long as it's good :D
<jsgotangco> well you can't force people to do something thats not interesting for them
<jdong> but I'd still like to see beryl in a Ubuntu repository
<jdong> rather than a 3rd party one
<Burgwork> yes
<_ion> seveas: Please upload falcon to feisty, btw. :-)
<mdz> Riddell: done
<Riddell> now it feels like a proper release :)
<agutierr> Someone knows something about this message on ubuntu edgy installer: Please presss one of these keys: ,, p....
<agutierr> :??
<_ion> What about it?
<_ion> Are you sure it's ,, and not e.g. ?
<Burgwork> agutierr: that is for determining keyboard type
<agutierr> Umm
<agutierr> I am using preseeds
<agutierr> is there a way to omit this question ?
<agutierr> (thanks)
<surak> it assumes things wrong for me all the time. If I press comma once, it says "wow! you're using a belgium keyboard"
<surak> :)
<_ion> The installer asks whether you want to run the detection thing, doesn't it?
<_ion> If it doesn't ask you to press comma and you press comma, what else could it do?
<surak> it can ask before for a specific layout or it can try to detect
<zMott> riddell: what with the mono components...
<Riddell> ?
<zMott> when I upgrade today... notice allot of mono this, mono that..
<zMott> is this part of the new frame work..
<Riddell> nothing to do with me
<zMott> just asking
<zMott> Mark, made a comment, about festy fawn
<zMott> that will have some new underpinning
<zMott> Riddell: its it true.
<iwj> Oh, bugger.  I just updated my xen install to edgy and now X is badly broken.
<highvoltage> iwj: ouch
<iwj> Yay, another hard crash.
<tfheen> iwj: what arch?
<iwj> And it works just fine not inside xen.
<iwj> i386
<iwj> My graphics is
<iwj> 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G] /GE Chipset Integrated Graphics Device (rev 01)
<iwj> Using the vesa driver doesn't help so I suppose it's probably something with Xen.
<dholbach> cjwatson, fabbione: whenever you have the time again - could you look at bug 59620? I was asked to look at it because there is some sort of quarrel going on, but I guess I'm not apt enough myself to judge. Thanks a lot!
<Ubugtu> Malone bug 59620 in parted "This ext2 filesystem has a rather strange layout (newer ext2/ext3)" [Undecided,Needs info]  http://launchpad.net/bugs/59620
<highvoltage> iwj: for what it's worth, in my experiences with edgy the vesa driver has caused me quite some problems, perhaps there's been some big changes with it upstream
<iwj> I last updated this install about two weeks ago.
<iwj> IIRC
<dholbach> pitti: apport-retrace is so GOOD STUFF!
* dholbach hugs pitt
* dholbach hugs pitti
* pitti hugs dholbach 
* dholbach hugs pitti
* dholbach hugs pitti
<keescook> hehe
<pitti> whoa!
<surak> :)
* Robot101 hugs dholbach 
<Robot101> :)
<dholbach> hey Robot101
<dholbach> Robot101: how's it going?
<zul> hey pitti 
<pitti> hi zul
<dholbach> pitti: we just need more dbgsym packages
<Robot101> dholbach: got a pair of very obscure and annoying to fix bugs
<dholbach> Robot101: good luck with that!
<ajmitch> morning all :)
<dholbach> heya ajmitch
<keescook> hiya ajmitch 
<Seveas> HUGS FOR EVERYONE -- thanks for another great Ubuntu release
* pitti hugs Seveas 
<highvoltage> *hugs*
<Amaranth> hehe
<Amaranth> I've got a guy PMing me saying "tell the devs thank you"
* iwj files bug 68440.
<Ubugtu> Malone bug 68440 in xorg "X does not work, causes crash" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68440
<iwj> Damn, I should change the title to mention Xen.
<surak> Amaranth: perhaps he/she is too shy to say for him/herself
* ajmitch hugs pitti & Seveas 
<Robot101> I've got edgy running under a xen domain atm
<Amaranth> surak: i think he doesn't want to bother you
<Robot101> lots of warnings at bootups about not being able to access /dev/mem
<iwj> Robot101: Hmm.  Do you have a working X server ?
<Robot101> iwj: I'm XDMCPing
<iwj> Err, you mean, the Xen domain is running the xdmcp server ie the X clients ?
<iwj> In my case the Xen domU is running the actual X server.
<iwj> Sorry, dom0
<Robot101> dom0 is etch and runs the X server, domU is edgy and is running the clients
<iwj> I suppose I could try etch instead :-).
<ajmitch> though you shouldn't be having problems with edgy anyway..
<Robot101> is that screwed up checksumming crap fixed upstream yet?
* ajmitch runs edgy as dom0 just fine with the i810 driver
<Robot101> I've got ethtook -K foad off die die die stab in all of my network scripts/interfaces too
<iwj> Robot101: I haven't heard about it being fixed.
<Robot101> oh, actually
<iwj> ethtool> Quite so.
<Robot101> the X server asserted
<iwj> Did you see my rant about it on xen-whereever ?
<Robot101> yeah
<Robot101> it doesn't work for backend drivers, so you lose anyway
<zul> iwj: which rant?
<iwj> ajmitch: Oh, you too.  Mine is using i810 too.
<iwj> zul: The one about checksumming.
<zul> ah ok
<iwj> Robot101: Quite.  Dreadful, isn't it.
<Robot101> I had to turn off DRI to make the X server work
<iwj> Turn off DRI.
<iwj> OK, I'll try that :-).
<iwj> I only barely know what DRI is ...
<iwj> Try that> when it's finished rebooting again.
<iwj> checksum rant: http://lists.xensource.com/archives/html/xen-devel/2006-03/msg01001.html
<zul> you know it would be nice to hear these bug reports earlier ;)
<iwj> zul: Yeah, but I didn't want to break my machine by constantly taking the edgy updates.
<iwj> You know how it is.
<zul> yeah i nkow
<highvoltage> iwj: a 4 month release cycle doesn't leave much time for bug hunting :)
<Robot101> iwj: when it was crashing for me I got some abort() or assert error
<iwj> Robot101: Lucky you, an error message :-).
<Robot101> yeah it didn't bring the machine down or owt
<iwj> 30 boots => fsck time
<zul> iwj: its complaining about missing /dev/wacom
<sladen> zul: the symlink creation code will do interesting things is the PNP ID for the wacom was detected, but the serial driver hasn't loaded
<sladen> zul: /is/if/
<iwj> Nope, disabling DRI didn't help.
<iwj> zul: Well, err, I don't think that's really a complaint, is it ?  I don't have a wacom tablet :-).
<zul> :)
<zul> iwj: which kernel is this 2.6.17/2.6.16?
<iwj> 2.6.17
<ajmitch> hi slomo 
<iwj> You can see from the Xorg.0.log
<zul> okies ill have a look at it again
<slomo> hi ajmitch :)
<iwj> I think I'm going to give up on this for now.
<zul> try with 2.6.17
<yacoob> It's pages like this that makes you go 'Okay... what's wrong with the world...?'
<yacoob> http://wherethehellismatt.com/
<jdong> http://thatisntreallyontopic.com/
<yacoob> Sure. Shutting myself up right away.
<yacoob> (with offtopic content, that is)
<iwj> zul: I _am_ using 2.6.17.
<zul> ah ok..
<iwj> ajmitch:, Robot101: what boot options are you passing to xen, if any ?
<ajmitch> nothing unusual, just the root filesystem
<Robot101> on domU: root=/dev/sda1 ro
<Robot101> on dom0: root=/dev/md0 ro console=tty0
<iwj> Right.  Err, but what about    kernel /boot/xen-3.0-i386.gz    where I have no options at all.
<ajmitch> nothing extra there
<Robot101> ditto
<zul> all i have is noreboot and i havent done anything funky
<iwj> Hmm.  Oh well.
<iwj> Perhaps some X expert will have a clue.
<iwj> I'm off to the pub.
<iwj> Thanks for your help, anyway.
<Robot101> ooh, carlton
* Robot101 has a bike now
<iwj> I need a shower first, so I'll be about 30m ...
<iwj> See you there ?
<iwj> bikes++
<Robot101> I'll ponder it, I've found a bug with google talk's server and I'm chatting with a googler who just arrived at work about it (doh)
<iwj> :-)  Have fun ...
<Robot101> yay timezones
<rgl> hi
<eXistenZ> Hey, there is some kind of bug in gnome-edgy.
<eXistenZ> When I try to move an icon from the left part to the right, the icon turns into yellow with a question mark inside.
<seb128> eXistenZ: what do you mean "from the left part to the right"?
<seb128> eXistenZ: please use launchpad for bugs too, or #ubuntu for users questions
<eXistenZ> seb128, I mean, try to make a shortcut for the terminal in your gnome-panel, put it in the left side, then move it (by dragging it) to the right side, and it will turn into yellow with a question mark
<seb128> eXistenZ: that might be https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/59431
<Ubugtu> Malone bug 59431 in gnome-panel "panel launchers get emptied after left mouse button drag&dropping twice" [Unknown,Unconfirmed]  
<eXistenZ> seb128, indeed
<frandavid100> hello! how can I add a new page to wiki.ubuntu.com?
<yacoob> hm, is there an udeb for installer with iwpriv?
<seb128> frandavid100: type the page name and it'll ask if you want to create it
<frandavid100> really?
<seb128> frandavid100: yep
<seb128> wiki.ubuntu.com/YourTitle
<eXistenZ> seb128, what about that bug?
<frandavid100> thanks guys!
<seb128> eXistenZ: that's the bug you were speaking about
<seb128> frandavid100: np
<eXistenZ> seb128, yes. Has it been fixed?
<seb128> eXistenZ: no, you would not have it if that was the case
<seb128> eXistenZ: and the bug on launchpad would be closed
<yacoob> looks like there is no iwpriv. Oh well.
<frandavid100> could you guys give this spec a look? https://features.launchpad.net/distros/ubuntu/+spec/cafebuntu
<frandavid100> What would I need to get it going?
<frandavid100> no comments?
<Burgwork> frandavid100: looking
<frandavid100> thanks Burgwork
<frandavid100> :)
<Burgwork> frandavid100: that should in an informational spec
<yacoob> Hm. When are there going to be shipits for 6.10?
<Burgwork> breaking out each of the various pieces needed
<Burgwork> yacoob: no shipit for edgy
<yacoob> why is that?
<yacoob> too edgy? :>
<Burgwork> no, dapper si supported for longer
<Burgwork> frandavid100: figure out each piece of the tech: lockdown, payment, wine, etc.
<Burgwork> one spec for each piece
<frandavid100> aha
<frandavid100> and that spec with links for them all right?
<goliath23> hi
<Burgwork> frandavid100: well, the spec would be informational, and the other specs would depend on it
<Burgwork> frandavid100: you going tob e in MTV?
<frandavid100> who me?
<Burgwork> yep
<frandavid100> you surely don't mean the music channel do you?
<Burgwork> mountainview
<nixternal> lol
<goliath23> I think there is a major problem with the update from dapper to edgy. /usr/bin/perl is killed everytime it's called from dpkg or apt-get with the message "stack smashing detected"
<Burgwork> goliath23: please file a bug
<frandavid100> don't really know what it is or how I could be
<Burgwork> this is not the place to report bugs
<Burgwork> frandavid100: no worries then
<goliath23> i'm stuck with a half updated system here.
<goliath23> X not running and so on.
<Burgwork> frandavid100: write all those pieces out, then create implementation specs for each
<goliath23> any idea how I could disable "stack smashing protection"?
<Burgwork> frandavid100: there is already a guest-login spec from edubuntu
<Burgwork> take a peek at that
<frandavid100> I'll do my best Burgwork
<Burgwork> frandavid100: no worries. Ask for feedback often
<frandavid100> thanks for the advice Burgwork
<frandavid100> gotta have some dinner, later!
<Burgwork> frandavid100: no worries
<goliath23> could anyone of you guys please help me out with a i386 perl executable somewhere on a webspace thats compiled without SSP?
<goliath23> maybe that gets started to fix things here. 
<pitti> goliath23: -v ?
<goliath23> obviously the new perl executable in edgy is compiled with a new stack smashing protection that somehow has false positives on my desktop pc .. on the laptop everything is fine
<pitti> goliath23: right, we use SSP by default now
<goliath23> pitti: -v of what? perl? v5.8.8
<pitti> goliath23: no, on your problem :)
<goliath23> ah, :)
* goliath23 calls himself with -v.
<pitti> goliath23: I use Perl quite regularly, I didn't notice any problem with it; what does it break?
<goliath23> so I changed sources.list and replaced dapper with edgy. then aptget update and apt-get dist-upgrade. somewhere in between dist-upgrade failed. now I get messages about missing dependencies if I call apt-get and it suggest a "apt-get -f install" if I do that, it tries to remove xserver-xorg, but the post-installation script is killed by SSP
<goliath23> and not only with removing xserver-xorg. it also fails on manual dpkg operations on other packages.. always with the same message.. : *** stack smashing detected ***: /usr/bin/perl terminated
<goliath23> leaving me in a quite undesirable situation :
<goliath23> :)
<pitti> weird
<goliath23> so maybe a perl executable as it was in dapper would help me to get at least something running again.
<goliath23> one that was compiled without SSP
<pitti> goliath23: let's continue this in /query
<BHSPitLappy> anyone else notice that some of the descriptions are wrong, in http://releases.ubuntu.com/edgy/ ?
<david__> pitty: ich muss doch wieder zurck und recovery starten, sobald der versucht X hier zu starten hngt er sich auch
<david__> brb
<Goliath233> pitti: still here
<Goliath233> ?
<Goliath233> pitti: ?
<pitti> Goliath233: yup; /msg please
<Viaken> Edgy rocks. Nice job. ;)
<Goliath233> pitti: I can't the registered username is still taken
<Goliath233> private msgs are disabled for non registered nicks
<Goliath233> pitti: please join me in #ssp-problem
<psusi> fabbione: ping
<yacoob> why isn't *buntu using differential packages list with apt?
<pitti> yacoob: doesn't work well for us
<pitti> yacoob: Debian has one update per day, Ubuntu has 24
<yacoob> hm? stable ubuntu gets 24 updates per day?
<yacoob> wait, you mean the upload cycle?
<pitti> yacoob: no, the development release does
<pitti> yacoob: but *-updates and *-security lists are so small, it's not worth the effort IMHO
<yacoob> hmm. Perhaps.
* Toadstool hugs * for edgy
<yacoob> ok, and what's problem then with dev? too much load on server to generate the diffs?
<pitti> yacoob: with 24 Packages.gz updates per day there would be a *lot* of diffs
<Amaranth> couldn't you only flip it on for final releases?
<Amaranth> although after that it's not worth it, like you said
<Amaranth> alright :P
<darkyoshi372> Hi all, I have a suggestion to make. I tried to set up file sharing between Edgy and a Mac, but after about an hour, I gave up. It should be very easy to set up files haring with a GUI, especially NFS, which is native to Linux. Perhaps there could be a little app in +1 that sets up a network for you, once you know the security risks involved?
<Nafallo> darkyoshi372: dude, that app exists :-)
<darkyoshi372> huh?
<Nafallo> darkyoshi372: system -> administration -> shared maps or something like that. I'm using Swedish personally.
<darkyoshi372> shared folders?
<Nafallo> darkyoshi372: and #ubuntu is for support btw :-)
<darkyoshi372> I know, I STILL couldn't set it up
<darkyoshi372> I don't want support
<darkyoshi372> I'm suggesting this as a feature
<jdong> darkyoshi372: this isn't where you suggest features either
<Nafallo> darkyoshi372: worked for me yesterday. if it didn't work, file a bug :-).
<darkyoshi372> okay...
<Nafallo> the feature is already there :-)
* darkyoshi372 makes funny are movements while whispering "make it easier! make it eassiiieeeerrrr....
<pitti> yay hal 0.5.8.1
<yacoob> w32codecs seems to be MIA.
<pitti> Riddell: still here?
<yacoob> Anyone can point me to some working copy and perhaps update the wiki on the issue?
<jabra> http://www.ubuntu.com/download/releasenotes doesn't have the release notes yet
<jabra> just fyi
<Chipzz> yacoob: no, w32codecs is in no way an official ubuntu or debian package, nor will it ever be
<Chipzz> it can't be because it's basically *illegal* to distribute it I think
<Chipzz> so I think you're on your own here
<yacoob> Chipzz, all well and sound, but I mean that the wiki is no longer valid :>
<yacoob> and I bet many folks use it anyway, thus my question.
<Chipzz> yacoob: use google? there are plenty of places you can download a w32codecs package from
<Chipzz> and while I agree that the wiki should be up-to-date
<Chipzz> this is not the correct place to complain about the wiki
<yacoob> Right.
<Chipzz> I think the forums would be more apropriate
<pitti> even better, just fix the wiki :)
<Chipzz> pitti: can anyone edit the wiki? :)
<LaserJock> yacoob: talk to #ubuntu-doc for wiki issues
<pitti> Chipzz: sure
<LaserJock> Chipzz: yes
<_ion> Hmm, whoever is the upstream of w32codecs (mplayer devs?) have got the files from *somewhere* (microsoft.com? apple.com? real.com?). Perhaps someone should make something not unlike msttcorefonts that downloads the official wmplayer, quicktime, realplayer etc. and extracts the dlls from them.
<pitti> _ion: Microsoft is the upstream :)
<Chipzz> pitti: not microsoft exclusively I think?
<_ion> s/upstream/midstream/ ;-)
<Chipzz> :)
<pitti> and Microsoft permits usage and downloading the TTF fonts, but not the codecs
<Chipzz> _ion: I have serious doubt about the legality of the zip-file on the mplayer site btw, but that's their problem really ;)
<wasabi_> MS doesn't permit that naymore.
<wasabi_> But their existing license was non revokable or something.
<wasabi_> So, somebody mirrored them on sf.net
<sivang> wasabi_: the fonts ?
<wasabi_> Yes, the fonts. 
<sivang> yes , they don't allow it.
<mirak> hello
<mirak> are you sure generic kernel are 100% sure ?
<pitti> http://www.microsoft.com/truetype/fontpack/win.htm -> oh, "oops"
<mirak> because I really have kernel crashes since they were introduced into edgy
<yacoob> just out of curiosity, how many of you actually have w32codecs installed?
* pitti uses amd64 and thus doesn't
<_ion> The script could represent the user with a confirmation dialog that says "Normally you don't have rights to extract the codecs from these programs. Do you have an express written permission from Microsoft, Real and Apple to do that?"
<_ion> :-P
<LaserJock> yacoob: I don't
<yacoob> _ion, add '*wink*wink*' at the end :>
<mirak> does anyone reported crashes when using generic kernels ?
<pitti> yacoob: so far I met very few to none videos which mplayer doesn't grok with native codecs
<Chipzz> pitti: just wondering btw, while (for the end-users) linking to the w32codecs deb is the sane thing to do, has anyone looked into the legal aspect of doing that? or is canonical not accountable for the content of the wiki's?
* psusi is with pitti
<yacoob> pitti, i have plethora of old stuff in various crazy formats
<yacoob> I ditched vivo, at least... :)
<psusi> my ubuntu install is pure floss
<pitti> Chipzz: German juristiction makes the link owner responsible for the linked target
<pitti> so I wouldn't like to set one
<pitti> yacoob: old stuff shouldn't be a problem - the very latest codecs might be
<yacoob> pitti, huh? That's ridiculous...?
<psusi> how utterly retarded
<yacoob> (link target thingy)
<pitti> e. g. WMV often gives problems, but most of my vids are mpeg-4 (in .avi)
<wasabi_> To be honest, I believe the US leans strongly in that direction too.
<wasabi_> And again, to be honest, I'd agree with it.
<wasabi_> You can't show somebody how to break the law, recommend they do so, and not have some responsibility.
<yacoob> it's so just happens that I have most of the stuff gathered on my stuff LV, so I'll run through it and quickly see.
<Chipzz> would saying "just google for w32codecs ubuntu debs" or linking to a google search be any better?
<yacoob> perhaps link to mplayer's page would be good?
<yacoob> http://www.mplayerhq.hu/design7/dload.html has them, plus instruction where to put it
<Chipzz> yacoob: but they don't have debs
<pitti> so what?
<pitti> it's about unpacking a tarball in /usr/local...
<yacoob> targz should be fine
<yacoob> provided edgy's mplayer will look there
<_ion> pitti: Then you don't get the updates automatically with apt-get upgrade.
<pitti> ... or whereever
* pitti is sure that somewhere out there is a w32codecs deb
<_ion> debian-multimedia.org IIRC
<StevenK> I thought it was linked to from RestrictedFormats ?
<Chipzz> pitti: considering the efforts ubuntu goes through to make everything easy for the user, unpacking a .tar.gz isn't quite user-friendly
<pitti> Chipzz: I agree
<yacoob> aw, shoot :/
<pitti> Chipzz: however, *I* wouldn't like to put such a deb on my homepage, and I guess this is true for most devs
<Chipzz> pitti: that's why I said that linking to the mplayer page may not be the best idea
<yacoob> kaffeine still fails to play .avi from smb share :(
<Chipzz> pitti: hence the link to google search?
<pitti> Chipzz: something blurry like 'search the web for a w32codecs deb package' might do
<pitti> gdebi does the rest :)
<yacoob> I wonder whether it's \ in the MRL that confuses the smb plugin...
<StevenK> -rw-r--r-- 1 steven users 13M 2005-11-16 15:32 w32codecs_20050412-0.0_i386.deb
<StevenK> Hrrm.
<StevenK> It seems when I did my install, there was a pointer to a .deb
<_ion> stevenk: That is a *VERY* old version.
<StevenK> Well, this machine did start off with Breezy...
<ajmitch> _ion: about the same version that I have
<ajmitch> 20050412-0.0
<_ion> Hence the need for updates with apt-get. :-) Of course, the legal issues hinder that.
<ajmitch> yep, looks the same
* ajmitch manages fine without it on amd64
<Chipzz> $ dpkg -l | grep w32
<Chipzz> ii  w32codecs                             20060611-0.0                         win32 binary codecs
* _ion has ran into many wmvs that only work correctly with a new version of w32codecs.
<_ion> s/ran/run/
#ubuntu-devel 2006-10-27
<yacoob> well, SOME wmvs don't render up... I guess I'd better look for the pack :>
<sivang> hmm, jono is not here
<pygi> sivang: nop ^_^
<sivang> pygi: hey dude
<pygi> sivang: hey ^_^
<cjwatson> BHSPitLappy: what's wrong with them? (I can change that page)
<ajmitch> hi mdz 
<Burgwork> ajmitch: or not
<ajmitch> oh well :)
<LaserJock> where does mdz work from?
<ajmitch> depends
<ajmitch> around release times, I think he heads to the office in london
<LaserJock> ah
<Burgwork> he is the UK right now
<LaserJock> where is he normally?
<Burgwork> cali
<pitti> good night
<ajmitch> night pitti 
<Riddell> pitti: you pinged?
<FireRabbit> is the webmaster here?
<Burgwork> FireRabbit: file a bug against the product ubuntu-website
<cjwatson> I've added an ubuntu-7.04 milestone; dated 2007-04-01 for now because I don't know the exact dat
<FireRabbit> ok
<LaserJock> cjwatson: sounds optimistic :-)
<ajmitch> I think the suggested date by sabdfl was the 19th
<FireRabbit> https://launchpad.net/products/ubuntu-website/+bug/68492
<Ubugtu> Malone bug 68492 in ubuntu-website "Incorrect description of how to obtain torrents" [Undecided,Unconfirmed]  
<Burgwork> FireRabbit: thanks
<FireRabbit> with the mirrors overloaded, this is not a good thing
<sivang> sladen: were you close to Jono in LinuxWorld london, I spotted you in some of the photos.
<jono> sivang, which photos?
<sivang> ah! you're here :)
<sivang> jono: http://nikbutler.wordpress.com/files/2006/10/jonoinflow.JPG
<ajmitch> jono!
<G0SUB> jono: I have sent you a mail wrt edgy cds and ubuntu-in
<jono> hey ajmitch :)
<jono> G0SUB, cool, will check mail tomorrow
<G0SUB> jono: that's fine :) it's actually about changing the shipping address from the one I provided earlier (if possible)
<sivang> jono: do you know who was the Zend guy David Morely tried to explain, and I quote "yes, we give it away rather than sell it. Amazing." ? ;-)
<sivang> jono: (this was about jokosher)
<psusi> fabbione: ping
<jono> G0SUB, cool
<jono> sivang, hehe
<jono> :P
<G0SUB> jono: fine, thanks :)
<jono> dave morley apparently got quite pissed off at people thinking Jokosher was a money making scheme
<ajmitch> jono: so it's not your secret plan to extort millions?
<jono> ajmitch, no, I plan to make money from selling guns to frustrated gentoo users :P
<sivang> ajmitch: HEHE
<ajmitch> jono: well our original loco contact (pre-plug) has gone back to gentoo now :)
<sivang> jono: my last job was Zend, I was curious if I knew the guy :)
<jono> ajmitch, hah!
<jono> sivang, oh cool
<G0SUB> it's aweful to see how Oracle ripped off RHEL to create their own distro
<G0SUB> and the name, my god. it's super-aweful
<sid> Can someone confirm a bug for me with gnome-panel?
<sid> if you left click and drag an icon in the gnome-panel to the right, and back to the left, does the icon lose all it's information? ie name/icon etc
<G0SUB> sid: on which release? edgy or dapper?
<sid> edgy
<LaserJock> not here I don't think
<G0SUB> sid: couldn't reproduce it here ...
<sid> LaserJock: You left clicked and draged an icon to the right in the panel, then back?
<sid> I got 2 people in #ubuntu to reproduce it
<LaserJock> sid: oh, now I got it
<sid> I didn't see anything on launchpad, but I'm not sure if I'm looking good enough
<LaserJock> it doesn't matter where you drag it or how far
<LaserJock> if you do a left click and drag it somewhere
<LaserJock> and then left click and drag it somewhere else it loses everything
<LaserJock> if I move it properly via middle click it's fine
<psusi> fabbione: ping
<glick> howdy
<glick> hey are there any kernel hackers in here?
<Hobbsee> glick: i suspect they're all out celebrating
<glick> heh yeah i spose so
<glick> i got my question answered in kernelnewbies on OFTC
<melvin> hello
<glick> hello?
<glick> hey what files do i need to install to compile kernel modules?
<glick> i mean packages?
<nixternal> build-essential, bin86, kernel-package, libqt3-headers, libqt3-mt-dev
<nixternal> there are some decent howto's int he forums i believe as well that will tell you everything you need
<glick> nixternal, is there a howto on how to build a kernel the ubuntu way?
<glick> heh
<glick> read my mind
<nixternal> well, that i don't know about
<nixternal> the "ubuntu way" is just to "apt-get upgrade"
<fabbione> apt-get build-dep linux-source-2.6.17 if you are in edgy
<fabbione> but please ask these questions in #ubuntu
<nixternal> we let the kernel devs build them for us
<fabbione> this is not a support channel
<glick> is there a kernel dev channel for just the ubuntu kernel?
<glick> cause i know ubuntu kernel isnt vanilla
<fabbione> glick: a development channel is not where you ask how to build a kernel
<fabbione> it's where you submit patches to improve or fix bugs
<glick> fabbione, where would you ask then?
<fabbione> #ubuntu
<glick> ubuntu channel is for beginners and general help, most people arnt building kernels
<highvoltage> #ubuntu is for all support
<fabbione> IIRC there is an #ubuntu+1 for slightly more experienced users
<Seveas> #ubuntu+1 is for development releases
<Seveas> but since there is no such thing right now, #ubuntu+1 is closed
<fabbione> Seveas: dude you are spoiling the fun :)
<fabbione> and feisty is open in LP btw..
<Seveas> That's my job ;)
<Seveas> hmm, I should make a feisty-changes rss feed
<fabbione> the list is open
<Seveas> have there already been uploads?
<fabbione> one, sitting in NEW
<fabbione> but i strongly suggest not to use it
<Seveas> heh
<fabbione> it's there only for bootstrapping feisty toolchain
<Seveas> I won't switch to feisty until december or so
* fabbione is running feisty already on 3 arches
<fabbione> well but i cheat
<fabbione> i have all the toolchain here :)
<ajmitch> glibc 2.5?
<fabbione> yes
<ajmitch> excellent :)
<fabbione> and .19-rc3
<highvoltage> wow :)
<ajmitch> yeah I saw benc's topic change in -kernel
* Hobbsee idly wonders what would happen if you tried to boot from that
<fabbione> Hobbsee: it works here on ppc/sparc/i386.. but it's still missing a bunch of specific ubuntu drivers
<Hobbsee> i expect it would cause large amounts of doom, but i wonder what exactly whould happen
<glick> can we stick to non homo-erotic names for ubuntu releases?
<glick> just a thought
<Hobbsee> fabbione: that in a chroot, or on a partition?
<glick> my opinion
<fabbione> Hobbsee: live
<Hobbsee> fabbione: wow, cool
<ajmitch> Hobbsee: it's not too different from upstream 2.6.19-rc3, afaik
<Hobbsee> ahh okay
<fabbione> not at the moment it is not
<fabbione> Hobbsee: oh add ia64 to that list
<Hobbsee> heh
<infinity> Seveas: Do we have an RSS feed for feisty yet?
<Seveas> infinity, I'm having trouble creating one
<Seveas> my mailserver is borking
<infinity> Seveas: (If you need a message to the list first, I can pop the first source package through)
<Seveas> no need to
<Seveas> courier rejects the subscription mail without any indication why
<infinity> Special.
<Seveas> ys
<Seveas> and I have to go to work now, soit will have to wait until this evening
<infinity> Well, that just unacceptable for a volunteer effort. :P
<Seveas> sue me ;)
<Seveas> anyway, bbl
<infinity> Seveas: If I statr passing stuff through now, can you pick up old messages an inject them in the feed, or will they just get lost?
<Seveas> I'll inject them
<infinity> Okay, cool.
<infinity> Later, then.
<jdub> 15:08:46 (1.34 MB/s) - `ubuntu-6.10-desktop-i386.iso' saved
<jdub> yay ;-)
<ajforgue> that's slow
<jdub> yeah, that's a dumb way of reporting
<jdub> it was
<jdub> 15:00:04 -> 15:08:46
<jdub> stupid wget
<Fujitsu> jdub: Which mirror?
<sladen> jdub: I didn't know you had wet-string that fast in Oz!
<fabbione> jdub: you are still slow :)
<Fujitsu> fabbione: But you seem to have the most ultimate hardware on the planet, so probably the ultimate connection as well :P
<fabbione> Fujitsu: i don't have ultimate hw.. no
<fabbione> (6.53 MB/s) - `edgy-desktop-i386.iso'
<fabbione> this switch sucks
<Fujitsu> OK then, have ACCESS to :P
<fabbione> not even on my internal lan at 100Mb i can cheat
<_ion> (259.31 MB/s) - `ubuntu-6.10-alternate-i386.iso'
<Burgundavia> https://wiki.ubuntu.com/Hansreiser <-- thoughts?
<Fujitsu> O_o
<fabbione> Burgundavia: offtopic.. please remove and let's lock that account
<Burgundavia> fabbione: can't lock, but I can ask
<Fujitsu> fabbione: Sounds good, if we can get it locked...
<G0SUB> any idea where I can file a bug report on usplash? launchpad says it doesn't use malone for bug tracking
<Fujitsu> G0SUB: launchpad.net/distros/ubuntu/+source/usplash/+filebug should do it.
<G0SUB> Fujitsu: ah, thanks
<G0SUB> the problem that I have with usplash is if I add vga=791 as a kernel parameter the spalsh screen becomes off-center and vga=789 simply borks the splash by making it way too large and the text wraps around
<sladen> yup, stick those in the bug report aswell
<Kagou> good morning
<jdub> fabbione: ha ha :-)
<jdub> fabbione: i just upgraded my modem so i get adsl2+ speeds. woo.
<pitti> hey jdub!
<fabbione> jdub: my ISP started offering adsl2+ yesterday
<fabbione> i need to check it
<jdub> yo pitti 
<jdub> congrats to everyone on the release :-)
<Hobbsee> hey jdub 
<jdub> morning Hobbsee 
<Hobbsee> jdub: IT'S NOT MORNING!
<Hobbsee> jdub: arent you in my timezone?  :P
<jdub> i always say good morning
<Hobbsee> true, but still
<tfheen> good morning, Sarah
<Hobbsee> hey tfheen :)
<Hobbsee> tfheen: glad release is over?  :)
<tfheen> Hobbsee: yeah.  It's great fun, but really exhausting too.
<Hobbsee> i'll bet
<ajmitch> hi tfheen 
<tfheen> it'll be nice to have a couple of somewhat quiet days before leaving for the conference.
<tfheen> hiya Andrew
<mdke> morning all. Good job
<SimSie> morning
<SimSie> hows the new release going?
<infinity> tfheen: "quiet" days of bootstrapping a new release, you mean? :P
* infinity is hoping for some "quiet"  in the week after the conferences.
<fabbione> infinity: quiet after MV is utopia.. we need to open the gates and start merging.. we better enjoy the quietness in writing specs :)
<tfheen> infinity: I didn't say all of the company had a couple of quiet days..
<mantiena-baltix> Hi all
<mantiena-baltix> pitti: are you alive ?
<janimo> mvo: morning, any news on the upgrade bug?
<janimo> mvo: should I recommend dist-upgrade in the release ann?
<mvo> janimo: no, sorry. nothing new. 
<janimo> mvo, so I'll say clean reinstall is recommended, or be prepared to unbreak te system?
<lifeless> bug ?
<mvo> janimo: a apt-get dist-upgrade should work as well, I have a theory now what triggers the crash
<mvo> janimo: update-manager rereads/validates the icon-theme after the install so this may trigger the problem. I'm still in the dark *why* the problem exists
<janimo> mvo: thanks, I'll recommend dist-upgrade then
<lifeless> what is the poblem ?
<janimo> mvo:  it may be a different set of icon themes being installed in xubuntu/ubuntu cause some corner case bug
<janimo> lifeless: update-manager crashes while upgarding xubuntu dapper to edgy
<janimo> lifeless: does not affect ubuntu
<mvo> lifeless: https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/68027 <- pretty spectecular, the crash takes the whole desktop with it
<Ubugtu> Malone bug 68027 in update-manager "sudo update-manager -c -d crashes during xubuntu upgrade" [High,Confirmed]  
<lifeless> mvo: wow, nice fuckage
<dholbach> good morning
<jsgotangco> hi
<dholbach> hiya Jerome
<ajmitch> hey dholbach 
<dholbach> hey Andrew
<pitti> mantiena-baltix: hi
<BHSPitLappy> Keybuk, !
<Keybuk> BHSPitLappy: ?
<BHSPitLappy> I've been idling in here for a couple of weeks, just in hopes of catching you in here.
<Keybuk> oh?
<BHSPitLappy> yep.
<BHSPitLappy> pm?
<Hobbsee> Keybuk: sounds like you're famous :P
<BHSPitLappy> celebrity status achieved!
* BHSPitLappy is with a local tabloid
<fabbione> Keybuk: that's the moment in which you need to change your status from blogger to submarine and start to hide...
<janimo> any ubuntu-announce moderator in here?
<janimo> got rejected for the announcement mails, whereas they got queued for approval last week
<janimo> elmo: ^^
<infinity> janimo: Did you rememebr to add an "X-Ubuntu" header?
<janimo> infinity: I have no idea what that is, have not used it so far
<infinity> I'll take that as a "no", then. :)
<janimo> infinity: :)
<janimo> I am also not user if I could do that from gmail
<janimo> s/user/sure/
<infinity> janimo: -announce will drop anything on the floor that's lacking such a header.
<janimo> infinity: ok, I'll remember for future mails
<infinity> janimo: I can resend it for you, if you mail it to me, and tell me who it should be From.
<janimo> infinity: ok, a moment
<janimo> infinity: sent it to you 0x3 address, From field the one you receive it from
<janimo> 0c3
<infinity> Alright.
<infinity> I should start charging for this service.. (had to do it for RichEd for edubuntu too)
<infinity> janimo: Don't you have an ubuntu.com address?
<infinity> janimo: Might look a bit better to send it from there.
<janimo> infinity: I do, you can use jani@ubuntu.com then
<infinity> Will do.
<janimo> thanks
* infinity fixes your word-wrapping a bit...
<infinity> janimo: Sent.
<janimo> infinity: thanks for the word-wrapping as well
<cjwatson> BHSPitLappy: so, what was the releases.ubuntu.com mistake you were asking about?
<BHSPitLappy> cjwatson, descriptions were off.
<BHSPitLappy> for example, the bittorrent I downloaded said traditional download or something
<cjwatson> yes, some of them do seem to be incorrect
<cjwatson> BHSPitLappy: thanks, I'll look into that
<cjwatson> BHSPitLappy: for future reference, https://launchpad.net/products/ubuntu-cdimage/+filebug is the best place to report problems with cdimage.ubuntu.com or releases.ubuntu.com
<BHSPitLappy> mmk
<BHSPitLappy> the installer on the official cd doesn't work, somebody should look into that too.
<BHSPitLappy> "Prepare mount points"
<BHSPitLappy> "!   No root file system."
<ogra> imbrandon, ping
<BHSPitLappy> I beg to differ, ubuntu.
<imbrandon> ogra, pong
<ogra> imbrandon, would it be possible to have the old categorization for the imported artwork in a.u.c ?
<BHSPitLappy> but eh, I guess I'm not allowed to install ubuntu in a reasonable, acceptable configuration
<infinity> BHSPitLappy: Sarcasm is less effective than well-formed bug reports.
<imbrandon> ogra, yea actualy i was working on that, its on my hdd but not quite ready to upload yet
<ogra> the edubuntu category had a ton of pics, now i have to got through a quite complicated navigation to get to them
<ogra> ok
<ogra> thanks :)
<imbrandon> np :)
<BHSPitLappy> infinity, I don't know... directed in the right places, ...
<BHSPitLappy> anybody know shuttleworth's cell number?
<dholbach> BHSPitLappy: Please cut it... you can't expect anybody to be motivated after your little taunts. 
<Hobbsee> especially just after a release, too
<BHSPitLappy> come now, lighten up a little.
<Hobbsee> dholbach: do you want help with your merges for feisty too?
<Hobbsee> dholbach: (not that we have to deal with them yet)
* dholbach hugs Hobbsee :-)
<cjwatson> BHSPitLappy: thanks for your releases.u.c report; fixed, as well as fixing the root cause of the problem
* Hobbsee hugs dholbach.  i thought you might like that.
<dholbach> hehe :-)
<Hobbsee> dholbach: of course, i'd be a lot happier to deal with them if it wasnt icky gnome :P
<BHSPitLappy> cool
<cjwatson> BHSPitLappy: on the other hand you've now convinced me not to look at your installer report, and I'm the person you need to look at it
<dholbach> Hobbsee: hahahaha - wait until seb128 sees that
<Hobbsee> dholbach: :D
<ajmitch> Hobbsee: glutton for punishment?
* mnepton glares
* seb128 hugs dholbach
<cjwatson> funnily enough we did test the installer before releasing it, so it's obviously not "doesn't work"
<mnepton> KDE is used by the same people that bolt US$10K of crap to a US$3K car. GNOME is used by people with a bit more taste. :P
<Hobbsee> cjwatson: do you want to deal with https://launchpad.net/distros/ubuntu/+bug/68559 ?
<Ubugtu> Malone bug 68559 in Ubuntu "I can't install ubuntu into existing root partition. (I need to delete and re-create it)" [Undecided,Unconfirmed]  
<Hobbsee> cjwatson: i cant think of a way to do it diplomatically
<Hobbsee> ajmitch: seems so
<tfheen> mnepton: "taste" and "USD" in the same sentence? :-)
<Keybuk> mnepton: oddly enough, it used to be the other way around
<mnepton> tfheen: the american dollar, great on a cracker!
<cjwatson> Hobbsee: diplomatically?
<Chipzz> Hobbsee: save the fangirlism for somewhere else please
<mnepton> Keybuk: yeah, i remmeber 2001. :)
<Hobbsee> Chipzz: huh?  want to explain that?
<Hobbsee> cjwatson: something other than "we've decided not to do things this way, be quiet"
<Chipzz> 11:19 < Hobbsee> dholbach: of course, i'd be a lot happier to deal with them if it wasnt icky gnome :P
<cjwatson> Hobbsee: that would be incorrect
<cjwatson> Hobbsee: it's a bug, not an intentional decision
<Hobbsee> cjwatson: oh, okay then.  i thought that you had decided not to let them install with an unclean /
<cjwatson> Hobbsee: I have, but that's a different error. Note how in screenshot number 4 he's opted to format /
<Hobbsee> oh, oops
<Hobbsee> yeah
<Keybuk> DEBUG:root:debian: kde-style-serenity 1.4-1
<Keybuk> ... is that the "You can't take my CRACK! from me!" style? :p
* mnepton wonders if EtienneG filed the megaraid-sas/initramfs bug
<cjwatson> OH
* cjwatson sees the bug, argh
<Keybuk> cjwatson: thank god we tested the installer, eh? :)
<dholbach> Chipzz: !??!
<cjwatson> Keybuk: won't show up in all configurations, but ...
<Chipzz> why refer to it is "icky gnome"? is that really necessary?
<ajmitch> Chipzz: we understood that she's joking
<dholbach> Chipzz: it's a long-standing joke
<Fujitsu> Chipzz: Yes, it's Hobbsee :P
* mnepton hands Hobbsee a </sarcasm> for future use
<Hobbsee> Chipzz: please meet the :P. 
<mnepton> Hobbsee: try that with me! i taste like chicken! oh, and sulfur.
<Chipzz> well, I don't like kde at all either, but I try to keep my opinion for myself ;P
<dholbach> Chipzz: and Hobbsee merged and worked on a bunch of GNOME packages, so I don't see why you should critize her in that way when it was obviously a joke...
* mnepton tastes like chicken!
<mnepton> BAWK BAWK BAWK!
* Fujitsu takes a bite from mnepton.
<infinity> mnepton: megaraid_sas got in at the zero hour.
<mnepton> (everybody point and laugh at the monkey and stop the arguing, please) :)
<infinity> mnepton: And no, the bug was never filed, I don't think, just communicated by a few over IRC.
<mnepton> infinity: want a doctrail for it?
<infinity> mnepton: Couldn't care less; it's fixed now.
<mnepton> oOoOoOoOo!
<mnepton> niftay.
<infinity> https://lists.ubuntu.com/archives/edgy-changes/2006-October/008054.html
<infinity> The 5th last upload that got in. :)
<Chipzz> dholbach: maybe I'm just not getting the joke... :P
<mnepton> infinity: spnedid
<mnepton> "splendid," too.
<Chipzz> dholbach: but I think that if I were to refer to kde as "a piece of crap" the whole time I would politely be asked to sod off ;P
<cjwatson> BHSPitLappy: looks like I should be able to fix that installer bug, anyway
<ajmitch> Chipzz: just drop it
<Chipzz> yea I will
<Hobbsee> good.
<Hobbsee> Keybuk: when will MOM start running again, for reference?
<BHSPitLappy> cjwatson, nice to hear. the circumstances in that bug report are a spot-on match to mine, incidentally.
<Keybuk> Hobbsee: running currently
<Keybuk> usually takes 6-9 hours for the first one
<Keybuk> though you can't upload yet, so it's moot ;)
<cjwatson> BHSPitLappy: workaround is to delete and recreate the partition
<Hobbsee> Keybuk: oh nice.  so feasible time to start merging is...?
<BHSPitLappy> too bad the bug made it into the official ISO, though. maybe an early 6.10.1 ?
<cjwatson> (since you have to reformat it anyway, that's not a big deal)
<BHSPitLappy> cjwatson, understood
<Keybuk> Hobbsee: when you can upload
<infinity> Keybuk: Sure she can, we just won't approve the uploads. :)
* Hobbsee wants to do something apart from studying.  or not studying
<Hobbsee> infinity: what, even if they dont contain crack?  :P
<cjwatson> BHSPitLappy: yeah, not sure. point releases are a big chunk of work for the whole team so we'll have to discuss it
<dholbach_> Chipzz: Hobbsee does real work in here, maybe that's a difference :-)
<Hobbsee> Keybuk: the next question is "when can i upload again?"  if i havent done tried your patience too much :P
<Keybuk> Hobbsee: when the toolchain and buildd chroots are ready
<ajmitch> Hobbsee: "soon"
<cjwatson> Hobbsee: you can upload, it just won't go anywhere for a bit. :)
<Hobbsee> gah.  i think i'm  pulling teeth.
<cjwatson> (feisty exists, but is frozen)
<Hobbsee> cjwatson: yeah, well.  that's not helpful
<infinity> Hobbsee: Seriously, you could upload now if you wanted to, it'll land in the unapproved queue.  But for the sake of being able to test-build your uploads with the new toolchain, you might want to wait until we have glibc/gcc/etc in.
<Hobbsee> so i'd heard
<cjwatson> Hobbsee: it's true, though ...
* Fujitsu likes the `EXPERIMENTAL' title that feisty has on LP.
<infinity> Fujitsu: Not anymore.
<ajmitch> Hobbsee: besides, you need to leave some packages for everyone else
<cjwatson> Fujitsu: that's already been changed to FROZEN
<Hobbsee> infinity: yeah, i understand that.  and then i'm wondering on how long that will be, which was more my original question :P  iirc, edgy's toolchain didnt start on the day after dapper's release?
<Fujitsu> cjwatson: Is there a functional difference?
<Keybuk> Hobbsee: next week sometime, if you want a thumb-in-the-arse estimate
<cjwatson> Fujitsu: yes - FROZEN means (a) uploads are queued for manual approval, (b) LP actually considers feisty as the "current release"
<infinity> Hobbsee: It's being worked on right now, whilst also working really hard on watching Black Books DVDs.
<Hobbsee> Keybuk: okay, that's what i wanted to know :)
<BHSPitLappy> cjwatson, well, the workaround should probably be published readily for others' sake, somehow.
<Hobbsee> infinity: sounds good to me.  and DVD watching is very cruical for such things :)
<infinity> Hobbsee: It's a good way to stomach working out of hours, yes. :)
<mnepton> oh man, i can see the tin-foil hat crowd in #ubuntu having a f-ing *field day* with Feisty being frozen
<Hobbsee> infinity: indeed.
<cjwatson> BHSPitLappy: I will do, yes
<Keybuk> infinity: you have hours? :)
<Fujitsu> mnepton: Yes, especially as it's labeled `pre-release freeze', or was last time I checked.
<ajmitch> mnepton: want to go & stir up some trouble?
<mnepton> here we go ....
<infinity> Keybuk: Not so much a set time when I do and don't work, but I theoretically have a contracted number per work that I'm meant to put in.  That number has never matched reality, but a man can dream. :)
<mnepton> ajmitch: i'd rather insert scorpions into my urethra
<Hobbsee> ajmitch: yes!  lets stir up some trouble :P
<BHSPitLappy> mnepton, way to brighten up the conversation as usual
<ajmitch> mnepton: graphic, but accurate..
<mnepton> BHSPitLappy: everyone has to have a super-power ...
<Hobbsee> infinity: since when does contract hours equal real hours?
<infinity> Hobbsee: Not once since I graduated high school. :)
<Hobbsee> infinity: :)  even then?
<mnepton> infinity: you graduated high school?
* Fujitsu notes that nobody in #ubuntu must see /distros/ubuntu/feisty, as it says `Status: Pre-release Freeze'... People were asking yesterday, when it wasn't even listed, if it was released yet :P
<BHSPitLappy> lucky me, I've never graduated high school.
<cjwatson> BHSPitLappy: https://wiki.ubuntu.com/EdgyReleaseNotes
<infinity> mnepton: Filthy government lies implied that it would somehow improve my future.
<mnepton> infinity: well, i don't make romantic overtures to high school graduates, so i guess that diploma is helping you a *little*
<infinity> mnepton: I assumed that had more to do with age than educational level.
* Keybuk never graduated high school
* mnepton sidles over
<BHSPitLappy> cjwatson, nice
<mnepton> hey big boy. you look both hot and like you've never read "The Iliad"
<BHSPitLappy> should I bother trying to count the levels on which that was disturbing
<mnepton> BHSPitLappy: well, you never graduated high school. so your count might not take too long nor go too high. ;)
<BHSPitLappy> oh no, now he's going to retaliate with a crack that I can't even count
<BHSPitLappy> ahh
<BHSPitLappy> predict'd! (though not provably, due to my typing sloth)
<BHSPitLappy> mnepton, I'm due to graduate in about 7 months, so we'll see where that goes.
<mnepton> ach so
<mnepton> and now, i officially feel old.
* mnepton continues decomposing
<BHSPitLappy> yay, the nitrogen cycle is finally proving useful.
<mnepton> quiet, necrotroph!
<BHSPitLappy> bully!
* yacoob rearanges mnepton into stack of compost
<mnepton> that requires rearrangement?
<mnepton> you're too kind.
<sjoerd> pitti: thanks for the hal sync mail!
<pitti> sjoerd: hi!
<pitti> sjoerd: my pleasure; I'm just playing around with all the new crack :)
<sjoerd> nice :)
<Robot101> ffs
<Robot101> beagle takes 550MB on this box
<Robot101> is that normal?!
* cjwatson prepares the traditional vim upload
<pitti> cjwatson: ' * Recognize feisty as valid Ubuntu release' ? :-)
<thom> cjwatson: :D
<cjwatson> pitti: near enough, yes
<pitti> oh, that reminds me, do we need to manually subscribe feisty-changes?
<cjwatson> I think so, yes
<slomo> pitti: yes
<pitti> slomo: yes what?
<pitti> slomo: oh, subscribe
<slomo> pitti: yes ;)
<slomo> btw, when will feisty be open for general uploads?
* mark wonders why ubuntu keeps insisting that he's in .au while he's actually on the other side of the globe
<pitti> mark: 'ubuntu'? he?
<mark> edgy and me :)
<mark> it did that in dapper, it still does in edgy... it's never asked me anything
<Fujitsu> mark, meaning it uses the Australian mirror?
<mark> yes, and has locale en_AU.UTF-8
<fabbione> mark: i think there is a bug opened for that already
<mark> okay
<Fujitsu> mark: Did you install using the Live CD, and selected a language that is strange for the country you selected?
<mark> no, I'm just upgrading now... but I'll try a fresh install later
<mark> it's just a bit annoying, .au mirrors are *very* slow from here ;)
<cjwatson> mark: was this a dapper install from the desktop CD?
<cjwatson> mark: if so, it's a known problem fixed in the edgy desktop CD installer
<mark> yes it was
<mark> okay
<cjwatson> just munge /etc/apt/sources.list to taste
<cjwatson> and /etc/environment, for the locale
<mark> sure, I did
<mark> after killing the upgrade process ;-)
<StevenK> mark: The .au mirrors are slow from here, too. :-P
<surak> Wow! This is amazing: https://launchpad.net/distros/ubuntu/edgy/+bugs
<seb128> we almost fixed them all ;)
<surak> Well, if this is not the way to look for edgy bugs, then I must be really dumb (or there's something weird with LP)
<Fujitsu> surak: The latter, cut the edgy/.
<seb128> surak: your URL list bugs with an edgy backport task
<surak> seb128 : What I did what going to launchpad, distributions, ubuntu, 6.10, and then bugs. I think this would be the logical step for looking for bugs specific to edgy. But perhaps this is offtopic, since this is a LP usability issue.
<surak> (IMHO)
<seb128> surak: you have bugs specific to edgy ;)
<surak> Actually, I do :-D
<seb128> surak: all other bugs apply to feisty too (are not specifc to edgy then)
<seb128> right, it's a launchpad UI issue
<Keybuk> main
<Keybuk> Locally Packaged    1122
<Keybuk> Unmodified          399
<Keybuk> Needs Sync          306
<Keybuk> Needs Merge         518
<Keybuk> Locally Repackaged  109
<Keybuk> Modified            210
<Keybuk> ------------------  --
<Keybuk> TOTAL               2664
<StevenK> Keybuk: Do those number overlap?
<Keybuk> no
<StevenK> numbers, even
<Keybuk> universe
<Keybuk> Locally Packaged    700
<Keybuk> Unmodified          4989
<Keybuk> Needs Sync          2370
<Keybuk> Needs Merge         433
<Keybuk> Locally Repackaged  65
<Keybuk> Modified            667
<Keybuk> ------------------  --
<Keybuk> TOTAL               9224
<sivang> Keybuk: merge preperations ? ;)
<Keybuk> sivang: aye
<sivang> Keybuk: cool
<Fujitsu> Keybuk: What are the first and last two categories in those lists?
<Keybuk> Fujitsu: locally packaged means the source doesn't exist in Debian
<Keybuk> Modified means that the version in Ubuntu is greater than that in Debian, but not 0ubuntu (ie. modified, with nothing to merge)
<Fujitsu> Keybuk: That's what I guessed, but there surely can't be, THAT many new ones!?
<Fujitsu> OK.
<Keybuk> language packs
<Fujitsu> Of course! I thought the numbers in main were rather large.
<sivang> can anybody tell me if completing apprenticeship implies reciving a diploma for it or is it just experience ?
<zul> probably depends on the location
<sivang> zul: okay, thank
<gnomefreak> why doesnt dbg work?
<gnomefreak> gnomefreak@EdgyEft:~$ dbg firefox
<gnomefreak> bash: dbg: command not found
<gnomefreak> am i missing something?
<gnomefreak> ignore that
<gnomefreak> need more coffee
<yacoob> hm.
<yacoob> is there a place where one can read up on organisation of Ubuntu, release cycles, and it's interaction with Debian?
<dholbach> yacoob: https://wiki.ubuntu.com/UbuntuForDebianDevelopers might help, if you're familiar with how Debian works
<yacoob> I'm more or less are. Thanks :)
<yacoob> (started to think to apply for Debian maintainership, but luckily I ran out of free time)
<StevenK> Hah
<bddebian> Howdy
<yacoob> ok, this page solves second part of my question. And the first one?
<fabbione> yacoob: start from wiki.ubuntu.com.. there are tons of links to the structure
<fabbione> what you are looking for as equivalent on NM is MOTU
<yacoob> Righto.
<yacoob> now, will wiki fit into my palm... :>
<yacoob> Hm, does that mean that main is kept in order only by Canonical folks? :>
<StevenK> Nope.
<yacoob> Ok, I'll read up, I'll... :>
<pitti> mvo_: SRU proposals need to go to mdz, not to security@
<pitti> mvo_: (could also just *look* like you sent it to security@, and I just got the bug echo though)
<seb128> we have planned to a "reduce delta with upstream" week for ubuntu-desktop next week, are other people interested to have that for non-desktop too? What would be the right place, #ubuntu-bugs?
<seb128> I've created https://wiki.ubuntu.com/DesktopTeam/UpstreamDelta for the desktop packages by example
<seb128> and I know we have a bunch of desktop patches that should go upstream
<seb128> not sure if people are interested to hand on #ubuntu-bugs next week and reply to people who want to do the same for non-desktop packages by example?
<Keybuk> seb128: random bug ... gnome-power-manager always seems to use the scalable icons, not the 24x24 one
<mvo_> pitti: I didn't send it to security
<seb128> Keybuk: we have patches pending feisty opening for that
<Keybuk> ok
<Keybuk> who knows much about x fonts?  (of the old fashioned kind)
<Keybuk> this program wants -times-normal-r-*-*-9-....
<Keybuk> where would I get that?
<segfault> woo!
<ogra> Keybuk, xfonts-{75,100}-dpi
<Keybuk> ogra: that only has 8px in it
<Keybuk> not -9-
<ogra> hmm
<ogra> probably in one of the -transcoded or -european packages then ...
<Keybuk> it's as if a scalable font is missing
<Keybuk> aha! /usr/share/fonts/X11/misc was missing from my font page
<Keybuk> path
<ogra> hmm
<ogra> intresting xfontsel hasnt it here either
<Keybuk> xtrkcad is happy now
<ogra> i hacve 8,10,12 etc ... but no 9
<mrmojo> hello
* BenC unleashes temporal doom
<mrmojo> someone needs to change ubuntu webpage
<mrmojo> "#
<mrmojo> # CD Image for Apple Macintosh PowerPC based desktop and laptop computers" is very misleading
<mrmojo> should be CD Image for PPC based Apple Macintosh
<Keybuk> err, that's what is says
<Keybuk> "PowerPC based desktop"
<cjwatson> he's gone
<cjwatson> damn drive-byers
<BenC> not to mention it should add IBM POWER5
<BenC> too many places to update that info
<zul> BenC: doom and gloom?
<BenC> zul: "All I wanna do is run my zoom zoom in her boom boom"
<zul> BenC: heh..
<Mez> is there a wiki link for the -proposed and -updates process?
<janimo> mdz: hi, can you let the xubuntu announcement through?
<mdz> janimo: done
<janimo> mdz:  thanks
<Mez> mdz: what is the process for having something added to -updates nowadays ?
<mdz> Mez: http://wiki.ubuntu.com/StableReleaseUpdates
<Mez> mdz: what is meant by "sever regressions
<mdz> Mez: a regression is when functionality which was previously working stops working
<mdz> as opposed to something which never worked
<Mez> mdz: so for example, having katapult not launch on systems not using en-gb and also not interacting with amarok would count? 
<zyga> hi
<Keybuk> Mez: has katapult ever launched on those systems?
<Keybuk> has katapult ever interacted with amarok?
<Hobbsee> yes
<Mez> Keybuk, yes :P
<Gadi> infinit, Keybuk:  I hope you'll excuse this as not being 100% a devel question, but I have an initramfs prob that I have been wrestling with in dapper for 2 days...   it has to do with booting by volume label (root=LABEL=)
<Keybuk> mdz: so in dapper, katapult both launched AND interacted with amarok?
<Mez> Keybuk, yes it did :P (assuming you're talking to me)
<yacoob> Hmm.
<yacoob> I ignited a flame few windows to the left, about how much ubuntu takes from Debian.
<Keybuk> Mez: is the fix trivial?
<Gadi> I have one image that boots by label fine, which is a breezy dist-upgrade to dapper.  another image that is a straight dapper install fails with:  ALERT!  /dev/disk/by-label/...  does not exist
<Mez> Keybuk: a couple of patches
<Hobbsee> Mez: fixed the bookmarks section as well?
<Keybuk> Gadi: that implies the label is wrong or not available
<Gadi> does the udev in initramfs need a particular pkg installed in userspace to make this work?
<Gadi> but vol_id returns the label fine
<Gadi> and it doesnt croke on LABEL in /etc/fstab
<Mez> Hobbsee, what was up with the bookmarks section ?
<Hobbsee> Mez: the ones in firefox - katapult doesnt bring them up anymore
<Keybuk> Gadi: kooky
<Gadi> heh
<Keybuk> does it work in edgy?
<Gadi> havent tried 
<Gadi> trying to keep my sample space of problems small ;)
<Gadi> Keybuk: when it drops me into the initramfs shell, should I be able to see a /dev/disk/by-name....?
<Keybuk> Gadi: yes
<Keybuk> does the directory exist at all?
<Gadi> no /dev/disk at all
<Gadi> what needs modprobing to get it?
<infinity> Gadi: Your drive controller.
<infinity> Gadi: What sortof controller is in that machine?
<Gadi> its on the ide drive
<Gadi> I modprobed ide-disk
<Gadi> still no /dev/disk
<infinity> Gadi: Do you have /dev/sd* or /dev/hd*?
<Gadi> yes - /dev/hdc, /dev/hdc1
<Gadi> which is correct
<sbalneav> back
<Keybuk> Gadi: does /sbin/udevd exist?
<Gadi> infinity: also note, that if I change to root=/dev/hdc1 it boots fine
<Gadi> Keybuk: it exists and is running
<Keybuk> Gadi: does /lib/udev/vol_id exist?
<infinity> udev would have to be running, or he'd have a static device tree, not just /dev/hdc{,1}
<Gadi> Keybuk: yes
<Keybuk> Gadi: what does "/lib/udev/vol_id /dev/hdc1" say?
<Gadi> it returns the correct label info
<Keybuk> you see ID_FS_LABEL_SAFE=... ?
<Gadi> yes same value for ID_FS_LABEL_SAFE and ID_FS_LABEL
<Keybuk> does /sys/block/hdc/removable exist?
<Keybuk> or /sys/block/hdc/hdc1/removable ?
<Gadi> yes and its value is 1
<Gadi> oh wait
<Keybuk> ok
<Keybuk> that's why you don't have any labels ;)
<Gadi> wait
<Gadi>   /sys/block/hdc/removable is 1
<Gadi> but, /sys/block/hdc/hdc1/removable  does not exist
<Keybuk> then the label and uuid for hdc will not be available
<Gadi> thats ok
<Keybuk> removable ide devices are teh suck
<Gadi> ah
<Gadi> so, will I not get a label for hdc1 as well?
<Keybuk> right
<Gadi> how come it works on the other image, tho, I wonder
<Keybuk> bet that's not a removable disk
<Gadi> no, they both are
<Gadi> they are both CF chips
<Keybuk> or is exposed through the SCSI layer and is thus /dev/sd* ?
<Gadi> nope
<Gadi> I just swap one for the other
<Gadi> same lot
<Gadi> er, slot
<Keybuk> identical hardware?
<Gadi> CF slot on ide bus
<Gadi> yep
<Keybuk> same chipset and revision?
<Gadi> 100%
<Gadi> same board
<Keybuk> on the other one, reboot with break=mount on the kernel command-line
<Keybuk> check /sys/block/.../removable on there too
<Gadi> ok
<Keybuk> I expect that doesn't have it
<pitti> mdz: do we still support X multiseat?
<Gadi> Keybuk: well, actually, right away I see a few diffs:
<Gadi> 1.  Doesnt support usb keyboard (had to switch to PS/2)
<Gadi> 2.  no /dev/hdc{,1}
<Gadi> (even after modprobe ide-disk
<Gadi> 3. only /sys/block/ram* exist
<Gadi> is there something else I should modprobe when I break this way?
<Keybuk> not especially
<Keybuk> we don't support CF that well
<Keybuk> so I'm not that surprised it's broken
<Keybuk> especially for your root filesystem :p
<Gadi> but, this is the CF that boots!
<Gadi> lol
<Keybuk> you did break=mount ?
<Gadi> yup
<Gadi> btw, it has no /dev/disk either
<Gadi> yet boots fine
<Keybuk> nothing other than ram in /sys/block ?
<Gadi> yup
<Keybuk> uname -r ?
<Gadi> 2.6.15-23-386
<Gadi> (on both chips)
<Keybuk> fun
<Gadi> only real diff between the 2 is that one is dapper straight and the other is dapper off of dist-upgrade
<Gadi> and the dist-upgrade is the one that boots
<Keybuk> oh, wait
<Keybuk> sorry
<Keybuk> . /conf/initramfs.conf
<Keybuk> . /scripts/functions
<Keybuk> run_scripts /scripts/local-top
<Keybuk> that'll make the necessary bits show up
<Keybuk> (where "." is part of the command)
<Gadi> right
<Gadi> running...
<infinity> Someone should shove "source" in dash, for the sole purpose of disambiguating IRC instructions.
<Gadi> yes
<Gadi> now I get /dev/disk
<Gadi> lemme check /sys/block
<infinity> I guess I could just "alias source='.'" in initramfs's init, so we have it there for giving instructions. :)
<Gadi> hey hey
<Gadi> so, /sys/block/hdc/removable is 0 here
<Keybuk> right
<elmo> what's right click on a mac?
<Keybuk> elmo: F12
<Gadi> so, what sets that?
<Gadi> not the kernel?
<Keybuk> Gadi: kernel
<Gadi> but, Im using same kernel
<Gadi> ?
<infinity> Gadi: Is this just two different CF cards being swapped out of the same reader?
<Gadi> yes
<Gadi> its an CF slot on the ide bus
<infinity> Curious.
<Gadi> ah, wait
<Gadi> there is one diff
<Gadi> the one that boots has 2 partitions, but the one that doesnt has 1
<Gadi> maybe thats what the kernel uses to determine if its removable?
<infinity> Shouldn't, but it wouldn't surprise me either.
<Gadi> strange criteria
<infinity> Is GRUB installed to the MBR on both, to the first partition, etc?
<Gadi> first partition on both
<infinity> If it's installed on the first partition, what's on the MBR?
<Gadi> good question
<infinity> One could have a DOS MBR, one could be blank/gibberish.
<infinity> That could relate.
<infinity> ANy number of subtle things.
<Gadi> maybe - thanks guys
<infinity> If anyone feels like following that codepath instead of guessing, be my guest. :)
<Gadi> I think you've given me enough to crack it
<infinity> Also, is the first partition set "bootable" in both cases?
<infinity> Blah blah blah.
<Gadi> well that is a yes for sure
<infinity> (Since I have no idea what criteria may be used to determine one CF card is removable and the other is a static disk..)
<Gadi> right
<Gadi> I think I am going to repartition this bad boy and see if it boots
<Gadi> and if not, ill investigate the MBR
<Gadi> thx again
<infinity> Have fun. :)
<infinity> If you discover something cool/interesting, do come back and share with the class.
<infinity> I'm getting curious now, but not curkious enough to dive into the kernel and actually divine the answer from the code.
<infinity> (Almost, though..)
<giftnudel> infinity: let's wait 5 minutes and see if you get bored, you might then :)
<pingar> HEI!
<pingar> whoops. wrong window.
<giftnudel> pingar: hello anyway :)
<elmo> anyone got a macbook pro?  the hotkeys/function keys don't seem to work at all
<elmo> this is a slightly large flaw when you need f12 to right click
<mjg59> elmo: Why did ejb leave Debian?
<infinity> elmo: We only set up the F12/right-click thing on powerpc machines.
<elmo> infinity: DOH
<infinity> adconrad@royal:~$ tail -n 4 /etc/sysctl.conf 
<infinity> # Emulate the middle mouse button with F11 and the right with F12.
<infinity> dev/mac_hid/mouse_button_emulation = 1
<infinity> dev/mac_hid/mouse_button2_keycode = 87
<infinity> dev/mac_hid/mouse_button3_keycode = 88
<infinity> No idea if that would even work on an i386 kernel, but you can try.
<infinity> elmo: ^^^
<elmo> mjg59: he was kicked out?
<elmo> infinity: no dice
<infinity> Yeah, didn't figure it would work...
<elmo> any reason  fglrx wouldn't work on a macbook pro?
<infinity> The lack of a VGA BIOS may confuse it.  No idea, though.
<mjg59> elmo: If you're booting in bios compatibility mode, it should work fie
<elmo> mm, I don't know what Colin did
<elmo> cjwatson: ?
<infinity> There's a claim that the dapper kernel supports mouse button emulation...
<infinity> On some random website. :)
<infinity> Oh, not so random, it's desrt's page.
<elmo> god I can't even get to the terminal on this thing
<elmo> this is such a cluster #"$Y#
<infinity> But it's pretty, so that counts for something.
<tfheen> infinity: I beg to disagree.  The macbooks are ugly. :-)
<elmo> tfheen: luca says "thanks"
<infinity> tfheen: As a sleek, black IBM lover, I agree.
<elmo> ok, so I can't get to terminals because there ARE no consoles - apparently
<elmo> WTF
<infinity> No appropriate console driver in the kernel for macbooks?
<infinity> If you were booting with bootcamp, you'd likely get a classic PC-style VGA-text (or vesafb or vga16fb) console out of it, I suspect.
<mjg59> elmo: Or he may have jumped. Not sure.
<elmo> macbookpro != well supported hardware
<elmo> mjg59: no, I am sure
<mjg59> I'm being given awfully vague information
<elmo> sorry, the "?" was rhetorical or something
<mjg59> Now I'm even more confused
<mjg59> :(((((
<elmo> mjg59: I can give you more details but a) later and b) probably off-chan? (this one at least)
<mjg59> elmo: Sure, no problem
<elmo> infinity: where's this page?
<elmo> I've got everything except hotkeys and right click now
<mdz> Mez: katapult completely failing to launch sounds severe, yes
<mdz> Mez: but how is it that no one noticed until now
<mdz> ?
<superm1> I was considering starting a project that would focus around a customized live cd with ubuiqity modified and tailored much more towards mythtv setup and associated applications to go with it.  Should I write a spec for this, or how is the best way to go about it "officially"?
<infinity> elmo: http://desrt.mcmaster.ca/macbook.xhtml
<infinity> elmo: You can do right-clickwith xmodmap, if you don't care about it working in the console, but the theory is that there's a kernel driver that should be making a bunch of hotkeys (and the right-click emulation) work.. At least, if I'm reading the page right.
<elmo> this page is full of lies
<elmo> it's like "merged in dapper, fixed in dapper"
<elmo> and none of it works in edgy
<mjg59> It all was
<mjg59> If it's reverted in edgy, that's because the patches got lost at some point
<elmo> ok, then edgy is full of ugly ugly ugly regressions for this machine
<mjg59> Complete absence of bug reports that I've seen, I'm afraid
<mjg59> And no hardware here
<mjg59> That does suck, though
<mjg59> Can you file a bug against the kernel?
<mjg59> We'll presumably be pushing an update at some stage...
<infinity> I'd have expected desrt to track edgy and whine loudly if this stuff broke...
<mjg59> Yeah, I'd have thought
<mjg59> Unless it all ended up macbook (not pro) specific, or something crack like that
<infinity> Though it's pretty telling that we only had one MacBook user (or only one willing to file bugs)
<Mez> mdz: it has been noticed, in July ... but I only found out about it lately...
<mjg59> Well, the installer doesn't work
<infinity> mjg59: His page mentions Pro and non-Pro off and on, so I assume some of it's been tested on both.
<cjwatson> elmo: ctrl-alt-fn-f1 might work to get to consoles (press in that order)?
<cjwatson> or ctrl-cmd-... - try the various combinations
<cjwatson> elmo: if this is Luca's box, there are definitely consoles, because I used them
<cjwatson> elmo: I set it up to boot using refit. I think it's in BIOS compatibility mode but I'm not certain
<cjwatson> elmo: the mac_hid configuration thing is a bit of a mess. I think the right answer may be just to change the defaults in the kernel rather than messing about further with procps
<cjwatson> elmo: but yeah, mac_hid would kind of need to be available in the kernel ...
<elmo> cjwatson: when I stopped gdm remotely, it went to a blank screen
<elmo> cjwatson: and none of the combos I tried got me to a combo, but *shrug* that's less important right now, I worked around it by ssh-ing in
<cjwatson> elmo: did you try chvt 1?
<cjwatson> elmo: alternatively it could be that X buggered up the console
<elmo> cjwatson: ah, no didn't occur to me
<cjwatson> elmo: oh, hmm, might be worth trying fbdev? it'll be slower, but might work better ...
<cjwatson> maybe vesa doesn't know how to restore whatever the heck the fb is on the macbook (I forget)
<cjwatson> elmo: installing that machine was why I suddenly made myself the assignee for intel-mac-support, because it was such a nightmare to make work at all
<elmo> cjwatson: yeah, it's a horror show, it's looking a little better now
<elmo> with the addition of restricted and fglrx, I've got decent X, sound, and wireless at least
<thom> is that a core duo or a core2 duo?
<elmo> not sure, the laptop (and it's owner) have left for the day
<thom> ah
<thom> cos i was thinking about acquiring a core2 duo one as a desktop replacement
<doko> mdz, cjwatson: still working? if yes, please see bug 68380 and bug 68396
<Ubugtu> Malone bug 68380 in eclipse "eclipse for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68380
<Ubugtu> Malone bug 68396 in openoffice.org "openoffice.org for edgy-updates" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68396
<Flk> mjg59: m0000000000000
<mjg59> Flk: Ha
<mdz> doko: please email
<cjwatson> elmo: oh good
<Gadi> infinity: do you know what the event loops issue is in udev wrt accessing removable devices on the ide bus?
<Gadi> Im thinking about just changing that rule in my initramfs
<jonh_wendell> How can i proceed to suggest a new version of a package (in main)
<jonh_wendell> just open a new bug against the package?
<G0SUB> what is the use of the ``terminal multiplexor[sic] '' service in Edgy?
<G0SUB> I am curious about what it does
<Burgwork> jonh_wendell: yes, but it would be for feisty, not edgy
<Burgwork> jonh_wendell: which app?
<jonh_wendell> Burgwork: rdesktop. Just filled the bug 68701
<Ubugtu> Malone bug 68701 in rdesktop "New version (1.5), sync from debian" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68701
<jonh_wendell> Burgwork: and about edgy-updates?
<Burgwork> nope
<jonh_wendell> :(
<G0SUB> jonh_wendell: if and only if it has a dataloss bug, we can publish a new version via edgy-updates
<Burgwork> it can backported
<jonh_wendell> ok, i understood
<jonh_wendell> btw, is the way the bug was reported correct?
<sladen> cjwatson: I have a HP DL360-G5 here which doesn't get any further than the first blue installation screen.  Same on dapper and etch
<mantiena-baltix> pitti: hi, are you alive ?
<neuralis> sladen: which screen is that? keyboard selection?
<sladen> neuralis: just after keyboard selection for Ubuntu;  just before keyboard selection for etch (might have got them switched, each cycles takes $time)
<neuralis> sladen: ilo2 bug, most likely, there's a patch; i spoke to benc about it, but he thinks it's in ubuntu's kernel already
<neuralis> sladen: debian bug 384202
<Ubugtu> Debian bug 384202 in installation-reports "Failure on systems with HP iLO 2" [Important,Closed]  http://bugs.debian.org/384202
<neuralis> sladen: (rather, he thinks it should even be in the dapper kernel, where i can replicate your problem; .17 upstream should have it, so it really ought to work with edgy)
<neuralis> sladen: as a temporary measure, you can start in expert mode and simply bypass the keyboard selection step.
<G0SUB> edgy seems to be way more resource hungry than dapper
<G0SUB> it took > 15 minutes on a machine with 256 MB RAM to load the live CD
<pygi> G0SUB: no, not really =)
<pygi> G0SUB: I tried running it multiple times on 256MB machines
<ubuntu_demon> G0SUB: what kind of machine ?
<G0SUB> pygi: running? or loading the live CD?
<G0SUB> ubuntu_demon: it's a newish celeron based laptop
<pygi> G0SUB: well, running the live cd, which means it also had to load ;)
<G0SUB> pygi: odd.
<ubuntu_demon> G0SUB: probably some bug somewhere I'd guess
<pygi> G0SUB: what's the drive? QDC as always? :P
<G0SUB> pygi: it certainly has some issues with laptops. i should investigate where it stalls
<G0SUB> pygi: don't know, it's not mine.
<pygi> G0SUB: what's with drive's DMA?
<G0SUB> pygi: in any case, the newer usplash (though fantastic) has some issues with vga=xxx kernel param
<G0SUB> pygi: DMA is surely on
<pygi> G0SUB: about vga, I know :-/
<azeem> G0SUB: did you try the noapic boot option?
<G0SUB> pygi: any fixes?
<G0SUB> azeem: no. what does it do?
<pygi> G0SUB: you could try running vga=normal 
<sladen> neuralis: thanks for the work-around.  Good news is that latest etch daily works
<G0SUB> pygi: well, normal will be just normal. I want vga=791
<azeem> G0SUB: how long did booting the dapper livecd take on that notebook?
<pygi> G0SUB: right, well it has it's problems =P
<pygi> that's just usplash :P
<pygi> it had even more serious problems before :P
<G0SUB> azeem: the hdd install is < 45 secs. don't remember the live cd one. in any case, far far less than this one.
<G0SUB> pygi: I sure hope they will be fixed.
<pygi> G0SUB: in -updates perhaps, dunno
<azeem> G0SUB: then I suggest you try noapic, it fixed a similar symptom for a notebook I tested
<G0SUB> azeem: trying right now
<G0SUB> azeem: nope, didn't help.
<azeem> :-/
<G0SUB> azeem: it took a LOT of time to go past the squashfs stage and then got stuck at loading GDM (I see the gdm background and cursor)
<G0SUB> may be the CDROM drive is to blame
<G0SUB> pygi: do you know what major changes has been made to usplash this time?
<ubuntu_demon> I reported a bug today. On my girlfriend's pc with a real crappy monitor she can't see usplash while booting. She only sees a black screen.
<sladen> ubuntu_demon: does the monitor power off?
<ubuntu_demon> I don't know whether it should be assigned to usplash or initramfs-tools or the kernel. Here's the bug : https://launchpad.net/distros/ubuntu/+source/initramfs-tools/+bug/68647
<Ubugtu> Malone bug 68647 in initramfs-tools "[maybe initramfs-tools or usplash?]  black screen during usplash. Ubuntu boots fine" [Undecided,Unconfirmed]  
<ubuntu_demon> sladen: it appears to just show a black screen. It's old crappy 14" monitor.
<ubuntu_demon> sladen: I always have to turn the monitor off by pressing the off button .. that's how old it is ;)
<ubuntu_demon> sladen: it appears to not get any signal until gdm is reached
<ubuntu_demon> sladen: but I'm not sure. I'm no expert at monitors 
<G0SUB> sladen: can you kindly take a look at bug 68545 too? is there any fix for it?
<Ubugtu> Malone bug 68545 in usplash "Behaves incorrectly with a custom vga=791 kernel parameter" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68545
<stgraber> ubuntu_demon: what's the value of the vga= parameter in /boot/grub/menu.lst ?
<Mez> evening sladen
<ubuntu_demon> stgraber: There's no vga= option by default I tried vga=normal. it didn't help
<ubuntu_demon> I turned of the lights in this room. It really gets no signal while usplash .. it emits no light at all 
<pygi> G0SUB: Dunno really, but I was using usplash since ages ago from cvs 
<pygi> G0SUB: splashy also, and it seems to behave a bit better
<pygi> tho it also had the vga= problem at start
<jonh_wendell> any firefox guy here?
<G0SUB> pygi: splashy is what i used way back ...
<pygi> jonh_wendell: just ask what you need ^_^
<jonh_wendell> pygi: look at bug 68510 please
<Ubugtu> Malone bug 68510 in firefox "firefox crashes when looking at google maps" [Undecided,Needs info]  http://launchpad.net/bugs/68510
<jonh_wendell> should i reject it or ask for more tests?
<pygi> o joy, flash :P
<sladen> ubuntu_demon: does the monitor go on standby?
<sladen> ubuntu_demon: or is the monitor old enough to not do things like standby?
<pygi> jonh_wendell: you could ask to try to provide "howto crash ff in that particular case"
<pygi> jonh_wendell: if no usable response withnin few days, close
<pygi> jonh_wendell: my suggestion:)
<ubuntu_demon> sladen: I *think* the monitor is too old to be able to go on standby
<jonh_wendell> pygi: ok, thanks
<G0SUB> bah! it seems stellarium on i386 is completely broken
<sladen> evening mez
<ubuntu_demon> I filed the bug to initramfs-tools because I didn't know whether I should file it to usplash or initramfs-tools
<G0SUB> ubuntu_demon: can you check if stellarium works?
<ubuntu_demon> G0SUB : not related to this usplash/initramfs-tools/? bug right ?
<G0SUB> ubuntu_demon: not at all. different bug
<ubuntu_demon> G0SUB : thought so ;) wanted to make sure
<ubuntu_demon> G0SUB : I'll try it on my laptop then ;)
<G0SUB> ubuntu_demon: try anywhere, it seg faults when i try to run it here (i386)
<ubuntu_demon> G0SUB: okay. I will try it with my current running generic kernel 
<ubuntu_demon> G0SUB: doesn't segfault here. At what moment does it segfault ? What's the link to the bug ?
<G0SUB> ubuntu_demon: I am reporting the bug. let me investigate it a bit first
<ubuntu_demon> G0SUB: I'm running the latest Edgy generic kernel with an intel Core Duo
<G0SUB> ubuntu_demon: i am on the default kernel too, but a P-4 M proc
<pygi> sivang: ping?
<ubuntu_demon> G0SUB: I'm not on the default kernel which is 386 AFAIK. I installed linux-generic
<G0SUB> ubuntu_demon: i am on the generaic one too. IIRC on edgy generic is 686 or 586
<ubuntu_demon> G0SUB: okay :)
<G0SUB> ubuntu_demon: man, the core dump is 18 MB !!
<ubuntu_demon> G0SUB: :)
<G0SUB> (gzipped)
<ubuntu_demon> Does anyone have any insight in : https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/68328 it's about hibernate/suspend for my laptop
<Ubugtu> Malone bug 68328 in linux-source-2.6.17 "suspend-to-ram and hibernate-to-disk don't work properly." [Undecided,Unconfirmed]  
<ubuntu_demon> I'm especially wondering whether I can provide more useful information somehow for that one
<ubuntu_demon> I will be away for a bit 
<ubuntu_demon> (offtopic : I will stay logged on and will check back after I watched naruto)
<bluefoxicy> did anyone teach Edgy to not start X until something figures out what video card we have and if it's changed from last boot and updates X?
<bluefoxicy> or is my soon to be attempted switch to an nVidia FX5200 going to result in my computer booting to "X KEEPS CRASHING HELP :(" mode?
<bluefoxicy> (yes I'll find out when I actually try; the question is more posed as a reminder that this definitely needs to be addressed some day)
<bluefoxicy> (But I'm curious too, I know upstart's able to do stuff like this.... :)
<G0SUB> ubuntu_demon: bug 68724
<Ubugtu> Malone bug 68724 in stellarium "Stellarium crashes at start-up" [Undecided,Unconfirmed]  http://launchpad.net/bugs/68724
<ajmitch> morning
<surak> night, ajmitch. Where are you? :-)
<ajmitch> surak: New Zealand
<ubuntu_demon> good night guys :)
#ubuntu-devel 2006-10-28
<ProN00b> sorry for the troll, but every ubuntu release is crappier than the one before
<Mez> hmm... who here uses mutt 
<_ion> Morning.
<_ion> mez: /me
<Mez> _ion: how do I set mutt so it uses local mail, but when sending email, uses my ubuntu.com email address instead of the local email address?>
<_ion> set from="foo@bar"
<Mez> where?
<_ion> Uh, .muttrc
<soothsay> !rules
<mcrandello> does anyone know offhand how to get the specific version of madwifi drivers that shipped with dapper? or which version to look for off the madwifi site? 
<keescook> wow do I love apt-proxy.
<ajmitch> hehe
<ajmitch> I was just lamenting that it was breaking for me
<ajmitch> as it is known to do at times
<keescook> yeah, I've had to restart it a few times here and there, but wow are my builds faster now.  :)
<ajmitch> yep, it is useful
<Seq> If I have an idea for a modification to a package, do I submit that in launchpad as a specification or a bug?
<_ion> A bug, probably.
<infinity> Seq: If it's going to cause controversy/discussion, it's a spec, if it's going to require real work and planning, it's a spec, if it's a small change that is likely to be accepted without much thought, it's a wishlist bug, if it's a broken behaviour, it's a bug.
<infinity> (In the last case, it's a bug that could lead to a spec, if the way to fix it isn't immediately obvious)
<jsgotangco> wow that's an excellent one sentence explanation of (almost) all things
<Seq> awesome, thanks infinity
<desrt> if people ask me how to upgrade to edgy using only the GUI, what do i tell them?
<Seq> it is just to split the gaim pixmaps into another package from gaim-data to have replacement icon packages. It may be undesirable, which is why I wasn't sure where to file it.
* Mez pokes desrt
<desrt> goodday
<desrt> going to mountainview?
<Mez> desrt, I wish ;)
<ajmitch> desrt: are you?
<desrt> ya
<ajmitch> great
<desrt> you?
<desrt> it'll be nice to see everyone again :)
* Mez cant afford to and well... although I hope to be there more for feisty... well... maybe next time
<ajmitch> yes
<desrt> i hope daniel silverstone is going to be there
<desrt> i haven't talked to that kid in ages
<infinity> He doesn't work for us anymore.
<desrt> oh.
<desrt> that sucks pretty strongly :(
<desrt> where is he now?
<jsgotangco> nokia?
<desrt> that's daniel stone
<jsgotangco> ooppss
<jsgotangco> sorry
<jsgotangco> yeah
<jsgotangco> he blogged about it before where he is going
<infinity> having fun with embedded systems somewhere.  Don't recall.
<desrt> 18:55 [homenode]  -!- Kinnison [n=dsilvers@spoo.flarn.net]  has left #canonical [] 
<desrt> ah.
<fabbione> neuralis: ping?
<neuralis> fabbione: what's up?
<fabbione> neuralis: hey dude.. just upgraded my ALOM and it's working fine. They also added ssh support.
<fabbione> neuralis: you really want to update and rerun setupsc
<neuralis> fabbione: i updated the day we spoke, it's working great.
<fabbione> oh ok
<fabbione> perfect
<neuralis> aye. thanks for telling me, though.
<fabbione> no problem
<mhb_> hi all ... does someone know if GRUB localisation (probably set up during installation) is possible?
<Nafallo> hi all
<Nafallo> I've just upgraded to feisty. two upgradable packages but no mail to feisty-changes?
<infinity> I think feisty-changes still needs to be moderated to whitelist mail from soyuz.
<infinity> Just a shot in the dark, I'm not the listadmin.
<Nafallo> oki :-)
<Nafallo> just wondering
<infinity> No point in "upgrading", mind you.
<infinity> It'll take us a few days to get the toolchain bootstrapped before anything interesting happens.
<jono> are people getting a font hinting problem in firefox and openoffice.org in edgy?
<Nafallo> yea, but now I wont forget it later :-)
<azeem> hi Barry
<bddebian> Howdy ;-)
<gnomefreak> does any release of debian use dash for default?
<mark> hmm either the korean mirror is not very stable or yahoo's network has issues
<sladen> gnomefreak: edgy
<gnomefreak> sladen: debian didnt release edgy ubuntu did
<fabbione> gnomefreak: none
<gnomefreak> fabbione: just edgy
<gnomefreak> thats what i thought
<fabbione> gnomefreak: you asked "Debian" that means none
<fabbione> i know about edgy
<gnomefreak> trying to get frostwire fixed for edgy without having users do it
<gnomefreak> so i emailed them and i will send them the fixes if they need them after i look at it
<Fade> frostwire looks like a nice app.
<Fade> argh. it's javaware. :(
<gnomefreak> is there anything stopping us from putting it in the repos either uni or multi.
<gnomefreak> Fade: limewire and frostwire are both javaware. i think amule and nicotine are not
<Fade> I wonder if it compiles with gcj
* gnomefreak perfers not to use any
<gnomefreak> Fade: no not that ive seen
<Fade> *nod*
<gnomefreak> or someone hasnt tried it
<gnomefreak> i can try that this week sometime but my packaging knownledge is slim i guess just changing depends in control to gcj and trying ti should tell us
<Lathiat> hrm whats the time period on LTS releases
<Lathiat> hrm nm 2 years
<Nafallo> Lathiat: I'm not sure there is a time-period for them, are there?
<xhaker> well.. it's a pitti i didn't find pitti here =)
<Nafallo> it's weekend ;-)
<Nafallo> and not any weekend. weekend after release :-P
<xhaker> heh
<xhaker> just filed a bug and wanted to confront pitti with his discrimination against European portugues people. haha
<Nafallo> :-P
<xhaker> portuguese*
<xhaker> Nafallo, do you happen to know if Feature freeze = no new packages ?
<Nafallo> it's not
<xhaker> well.. dumb question i know.. but what i really want to know.. is if now that edgy was released can new packages be uploaded?
<Nafallo> for feisty, and after the toolchain is bootstrapped, yes :-)
<xhaker> uploaded to edgy i mean
<xhaker> :(
<Nafallo> I find it hard to imagine. infinity? :-)
<xhaker> pitti must have forgot about myspell-pt-pt it's not in the repositories
<xhaker> i forgot about it.. i should have filed a bug earlier
<xhaker> haha
<Nafallo> how nice.
<Lathiat> Nafallo: well ir ead somewhere theyre coing out eveyr 2 years
<Lathiat> Nafallo: which would make sens gtiven you need migration time before the 3 year desktop support runs out
<Nafallo> yea, makes good sence :-)
<Nafallo> 3 normal, 1 super, 3 normal, 1 super... :-)
<illovae> hello :)
<illovae> infinity: hello are you available for a question please ? (sorry for my english but it is not my native langage)
<eric__> The Edgy repositories seem to be going really slow for me (10-20 k/s) as I'm trying to upgrade to Edgy. Is this happening for everyone?
<infinity> illovae: You're in luck, I'm awake, even though it's 4am on a Sunday morning. :P
<illovae> erf oups sorry
<illovae> oh i see on launchpad you are living in australia > i'm really sorry
<illovae> i can wait for my question...
<infinity> Don't apologise, I wouldn't answer if I wasn't around. :)
<infinity> What's up?
<infinity> illovae: ?
<jdub> heh
<illovae> infinity: yes sorry i'm here
<illovae> so my question
<illovae> :)
<illovae> i love the game doom and i discover the release doomlegacy on multiverse
<infinity> jdub: What the heck are you doing awake at this hour?  I thought I was the token insomniac.
<illovae> i'm running edgy on a powerpc
<illovae> and i tried to pbuild your deb-sources of it for ppc
<MrKeuner> I would like to thank the Ubuntu and Debian communities for such a good release. I am impressed with it a lot. I did one Upgrade and one clean install and everything went perfect. Keep up the excellent work guys. thanks again!
<illovae> but i have some problem
<illovae> so my question is : is it possible to compile a deb with pbuilder of your deb-sources of doomlegacy
<infinity> illovae: I'm pretty sure I have nothing to do with doomlegacy. :)
<illovae> ?
<infinity> It's entirely possible that I was the last person to upload it...
* infinity checks.
<illovae> infinity: are you adam conrad ? > that is the name in the changelog
<infinity> doomlegacy (1.41release-2ubuntu1) breezy; urgency=low
<infinity>   * Adjust {build-,}depends for the xorg -> mesa GL/GLU transition.
<infinity>  -- Adam Conrad <adconrad@ubuntu.com>  Wed, 31 Aug 2005 01:52:10 +1000
<infinity> Yup, that would be me.
<illovae> lol :)
<infinity> I know nothing of the source package at all, except for that one fix. :)
<illovae> arf ok...
<infinity> (I tend to fix a lot of things in the archive)
<Toadstool> illovae: as I told you on #ubuntu-fr, there is i386 asm in the source code. this is why the Debian maintainer used Arch: i386
<Toadstool> (hi here by the way)
<illovae> Toadstool: yes but i changed it for the nasm for ppc :)
<infinity> doomlegacy isn't really maintained in Ubuntu and, as it turns out, it's not really maintained in Debian either (it's orphaned, maintained by the QA group)
<illovae> Toadstool: i made all the appropriate changes for using it on ppc > but it appears there is a problem with sdl
<Toadstool> illovae: that won't help, registers, instructions, etc are different
<illovae> infinity: arf ok
<illovae> Toadstool: yes i think you are right
<illovae> ok so
<illovae> infinity: thanks for the help
<illovae> and i'm sorry for disturbing you
<illovae> Toadstool: thanks too :) i will try to check how is it possible to use doomlegacy on powerpc > i checked the official website and there is a release for mac os X > so it might be possible :)
<Nafallo> infinity: meep :-)
* Nafallo ponders to start filing syncrequests for feisty ;-)
<infinity> Nafallo: Err, we'll autosync sometime next week.
<Nafallo> infinity: not things with changes that can be dropped :-)
<infinity> Nafallo: You can certainly start gathering up sync-with-overwrite requests, though (for modified packages that should be synced)
<infinity> Nafallo: Queue 'em up, sure.
<Nafallo> goodie! :-)
<Toadstool> great! let's get started then :)
* Nafallo hopes requestsync works :-/
<Nafallo> hmm
<Nafallo> I got a 404 from the changelog page. I shouln't send this bug then ;-)
<rgl> hi
<ArrenLex> Is it just me or is there a bug in apt which makes the -t switch unusable since edgy?
<AstralJava> I see a -t switch only in aptitude.
<ArrenLex> It used to exist in apt-get; I've used it many times.
<AstralJava> apt-get --help shows no such thing.
<ArrenLex> http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
<ArrenLex> 3.8
<ArrenLex> First command listed.
<_ion> If i want a package from another distro (or version of one), i usually build it from the source.
<ArrenLex> I've done it exactly that way and all has been fine.
<ArrenLex> I guess the functionality has been removed or something?
<ArrenLex> If so, why?
<AstralJava> jaska@jjod600n:~$ apt-get --version
<AstralJava> apt 0.6.45ubuntu14 for linux i386 compiled on Sep 27 2006 23:43:26
<AstralJava> ^^ in Edgy.
<ArrenLex> Yes, I have the same, in Edgy.
<ArrenLex> apt-get --version
<ArrenLex> apt 0.6.43.3ubuntu2 for linux i386 compiled on Apr 18 2006 19:46:38 <--- in dapper. This one worked.
<ArrenLex> Oh, hold on. That one doesn't work either...
<ArrenLex> Bah. It was taken out a while ago, then.
<Nafallo> infinity: if I upload stuff to feisty, do they stick in a queue then? :-)
<infinity> Nafallo: Yes, it'll end up in the unapproved queue.  I may prefer if you don't just yet, though, so I don't have to wade through the queue while we're bootstrapping.
<Nafallo> infinity: alright. I'll just keep things dputable then :-)
<cjwatson> Lathiat: there's no set interval between LTS releases. When we asked Mark at the last distro team meeting, he said that the next one would simply be whenever the time felt right to support what we currently had for 3/5 years.
<Lathiat> cjwatson: ah ok
<Lathiat> cjwatson: i guess it would make sense tho to release before the 3 years is up.. 
<Lathiat> arguably
<Nafallo> hmm, I should merge pbuilder ;-)
<Nafallo> I hope they've fixed the 100% at satisfy-depends bug...
<mycroes_lappy> Hi all, can you guys tell me what's the best way to get nvidia drivers for my custom kernel?
<mycroes_lappy> don't tell me you guys never ran a custom kernel
<mycroes_lappy> :P
<Nafallo> mycroes_lappy: I newer ran a custom kernel on Ubuntu
<mycroes_lappy> are you an ubuntu dev?
<Nafallo> s/w/v/
<Nafallo> :-)
<Nafallo> MOTU
<mycroes_lappy> ?
<Nafallo> universe maintainer
<mycroes_lappy> ok
<mycroes_lappy> nice
<mycroes_lappy> I'm a long time gentoo user
<mycroes_lappy> but I'm using mostly gnome apps
<tritium> mycroes_lappy: #ubuntu is the support channel where your questions should be asked
<mycroes_lappy> and recently I used i686-pc-linux-gnu and almost no optimizations
<mycroes_lappy> tritium, I know, but the problem is there's noone there able to answer my questions
<mycroes_lappy> of over 1000 users noone ever compiled a custom kernel ;)
<tritium> mycroes_lappy: sure there are
<mycroes_lappy> tritium, currently, I'm just asking questions in here, but I think I might be able to give back soon...
<tritium> mycroes_lappy: some have
<mycroes_lappy> tritium, I tried twice but no reaction at all
<mycroes_lappy> friend of mine who used ubuntu for a while said I might be better off asking this kind of questions in -dev
<Nafallo> mycroes_lappy: he was wrong :-)
<mycroes_lappy> lol
<ajmitch> morning
<jdong> -EWRONGTIMEZONE
<Chipzz> mycroes_lappy: the wiki has all kinds of information about compiling kernels
<mycroes_lappy> Chipzz, yeah, but it's all so much that it became hard to find stuff
<mycroes_lappy> Chipzz, I did learn a bit already though
<Chipzz> mycroes_lappy: there are basically 2 ways
<Chipzz> either use kernel-package (make-kpkg)
<mycroes_lappy> Chipzz, hold
<mycroes_lappy> Chipzz, the kernel was not the problem :P
<Chipzz> or recompile linux-image
<mycroes_lappy> Chipzz, I needed nvidia drivers for a custom kernel
<ispiked> iwj: ping
<Xoritor> can one of you guys pull a packages from debian-unstable?
<Xoritor> fvwm was updated to 2.5.18 but ubuntu edgy still has 2.5.16 (for that matter what happened to .17?)
<Xoritor> or am i going to have to compile it all from sources?
<Nafallo> Xoritor: edgy is released as Ubuntu 6.10
<Xoritor> right... 
<Xoritor> so are you saying no "upgrades" ?
<Nafallo> only security or "my god the package ate my harddrive and mother"
<Xoritor> ok so your telling me no right?
<Nafallo> right
<Xoritor> then can you enlighten me on why .17 was not pulled at the least?
<Nafallo> we where probably in the freeze already.
<Yagisan_> Nafallo, nice description
<Nafallo> Yagisan_: :-P
<Nafallo> Yagisan_: it's true ;-)
<Xoritor> ok thx
<Yagisan_> Nafallo, apparently I did a "my god" moment a day or two ago
<Nafallo> Yagisan_: oh?
<Nafallo> Yagisan_: some package ate your mother? :-)
<Yagisan_> Nafallo, I forgot to remove a testbuild from my private repo queue before syncing
<Nafallo> hehe
<Nafallo> oops :-P
<Yagisan_> Nafallo, I have received some 57 and counting bug reports via email, and my xchat won't stop flashing
<Nafallo> hehe, popular repo :-)
<Yagisan_> Nafallo, and as it is an "unreleased" package of some upstream source, they will be rather unhappy with me when they find out
<Nafallo> ouch :-/
<Yagisan_> Nafallo, yep :'( I need to explain why I release before schedule. I'll blame it on the excesses of my birthday on the 27th
<Yagisan_> Nafallo, oh - and it pumps garbage out the speakers - thats the bug
<Nafallo> Yagisan_: happy post-birthday :-)
<Nafallo> haha
<Yagisan_> Nafallo, if you have a brown paper bag, could I borrow it
<Nafallo> I think you can have it ;-)
<Yagisan_> Nafallo, it fits perfectly
<Nafallo> :-P
<Yagisan_> Nafallo, 58 emails ... and I just pushed out an update. I need some sleep now.
<Nafallo> Yagisan_: gnight :-)
<mrmojo> why does ubuntu default to 12hr clock :-/
<ispiked> mrmojo: because most normal people in the USA use 12-hour format? :P
<mrmojo> well i chose UK and i'm still getting this silly format
<mrmojo> XP & OSX know to use 24hr clock when the user selects UK
<mrmojo> as their locale
<ispiked> mrmojo: file a bug?
<mrmojo> will do
<_ion> The 12 hour format would be just fine and dandy if it weren't so totally bereft of logic. :-) First AM goes from 12 to 1 to 11, then PM goes from 12 to 1 to 11. GOTO 10.
<_ion> 0..11 would be just fine.
<mrmojo> lol it always makes me laugh when americans use 12hr formats for planes and train times
<zyga> _ion: that mearly proves that GOTO IS EVIL
<zyga> :>
<mrmojo> but americans love making life hard for themselves then wonder why all their companies outsource :D
<_ion> Oh well, at least they use seconds, minutes and hours.
<Burgundavia> mrmojo: please leave your prejudices at the door
<mrmojo> calm down
<zyga> (someone might not make comments about the metric system and british currency logic)
<mrmojo> the US still uses 'british currency logic' in some financial markets
<mrmojo> and it was only 1999 when they dropped it for stock pricing
<Burgundavia> mrmojo: I am calm. I am merely asking you to leave your prejudices at the door
<mrmojo> well, not british currency logic, but something nearly as silly
<zyga> while we're at it let's bash 8.3 filesystems and call it a day, it's getting late for some of us already (yawn)
#ubuntu-devel 2006-10-29
<Mirv> hmm
<profoX`> How is upstart linked to teardown? is teardown integrated in upstart now?
<mrmojo> is there plans for a GUI bug reporter in feisty?
<mrmojo> something like goto system --> report bug or similar, it would come up with a little program which woudl allow you to take a screenshot, add a few details and quickly publish a bug
<imbrandon> wouldent work out well as you need to search for already reported bugs similar to yours ( but most dont think about that it seems by some of the dupes )
<profoX`> imbrandon: the way kde bugreports work is that it automatically searches for possible related bugs after you type in a title and some keywords of your bug before actually writing the bugreport
<profoX`> imbrandon: a gui program could also show that by using a wizard, first enter a title and some keywords, and then show possible matches.. click on a match to open the bug report in your browser.. and have a button to cancel the bugreport or to continue writing it..
<AngryElf> what's the logic in not having specific branches of the kernel anymore? i.e. now there is just 'generic'
<mdke__> you'll find a long thread about it on the -devel mailing list
<imbrandon> profoX`: true, if it was done right :)
<profoX`> imbrandon: yes, but when's the last time we did something wrong ^^
<profoX`> j/k
<imbrandon> :)
<jdong> cjwatson: what are your feelings as to -backports building against -updates?
<jdong> cjwatson: for cases like bug 63452
<Ubugtu> Malone bug 63452 in Baltix "Please backport brasero CD burning tool from Ubuntu Edgy" [Low,Confirmed]  http://launchpad.net/bugs/63452
<sid> elkbuntu: Do you have the results for the last Ubuntu poll?
<sladen> what's the build tool that splits off the .po files for the language packs
<Evaso2> hi guys anybody developing launchpad is here?
<sladen> Evaso2: #launchpad
<Evaso2> sladen: thanks
* gnomefreak would guess its weekend most wont be very active
<Nafallo> sladen: package-strip-translations? :-)
<Nafallo> pkgstriptranslations even
<sladen> nafallo: ta
<rmjb> Hello cjwatson, I'd like to get some advice on putting through an SRU for a broken universe package
<Burgundavia> rmjb: which package?
<rmjb> dmrid
<rmjb> dmraid
<Burgundavia> rmjb: file a bug with your patch attachedc
<rmjb> https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/68294
<Ubugtu> Malone bug 68294 in dmraid "[SRU]  Freeze Exception Request for dmraid" [Medium,Unconfirmed]  
<rmjb> and https://launchpad.net/distros/ubuntu/+source/dmraid/+bug/54246
<Ubugtu> Malone bug 54246 in dmraid "DMRAID stopped to work in kernels > 2.6.15" [Undecided,In progress]  
<rmjb> the last one had the deb and source packages
<rmjb> s/had/has/
<Burgundavia> ah
<Burgundavia> rmjb: is dmraid completely broken? that is not clear from the bug report
<rmjb> I'm not sure, I've seen two people in the forum thread say it works for them on edgy, but lots more say it doesn't
<rmjb> upgrading usually works
<Burgundavia> ok, in order for that SRU to pass, you need more than that
<Burgundavia> detail those forum reports
<rmjb> do universe SRUs follow this same process: https://wiki.ubuntu.com/StableReleaseUpdates
<rmjb> ?
<Burgundavia> yes
<Burgundavia> afaik
<Burgundavia> the rules are a little lighter because it is universe
<rmjb> I'll need to file a new bug or the UVFe one is enough?
<rmjb> once I get more info I can just reassign it to... mdz?
<Burgundavia> the latter, no idea
<Burgundavia> the one you have it probably good enough
<Burgundavia> just change the title
<Burgundavia> oh wait, you have already done that
<rmjb> it's that next step that has me confused
<Burgundavia> which one?
<rmjb> dholbach did
<Burgundavia> the actual SRU?
<rmjb> what to do now... has be confused
<rmjb> yeah
<Burgundavia> you at the SRU page?
<rmjb> yep
<Burgundavia> in the propose stage
<Burgundavia> you have a bug number
<Burgundavia> you need a better statement about impact
<Burgundavia> ie: edgy's dmraid doesn't work
<Burgundavia> period
<Burgundavia> here are the people that have tried it
<Burgundavia> rmjb: here is what I would also do
<Burgundavia> rmjb: get the latest dmraid into feisty
<Burgundavia> asap
<rmjb> feisty is out??
<Burgundavia> archives are open
<Burgundavia> no idea about general uploading
<rmjb> need to talk to an motu to get it in there then
<Burgundavia> but back to the SRU
<Hobbsee> Burgundavia: toolchain is still building.  general uploads next week or so, was the guess
<Burgundavia> Hobbsee: ah
<Burgundavia> rmjb: anyway, you have about 50% of what you need for the propose phase
<Burgundavia> of course, IANAUD
<rmjb> I'm going to link to the thread that has the users' reports: http://ubuntuforums.org/showthread.php?t=266807
<rmjb_> dmraid was broken for 8 users in the thread
<rmjb_> Burgundavia: I've updated the SRU bug, should I assign it to an SRU team?
<Burgundavia> rmjb_: no idea
<rmjb_> yeah... me neither... the report looks better now?
<rmjb_> #68294
<Fujitsu> rmjb: motu-uvf is the team for SRUS.
<Fujitsu> *SRUs
<rmjb> so it's at the right assignee then... cool
<Flk> mjg59: heard ur had a night of drunken debuachery yesterday lol :P
<jdub> having switched on WPA on my AP, i now understand why people like/want pam-keyring
<rmjb> hello I'm looking for advice on packaging a java app
<rmjb> I have the dependency to java-gcj-compat-dev right now, is that right?
<rmjb> or can it be replaced with something "slimmer"?
<Burgundavia> rmjb: you need to talk to doko
<rmjb> thanks Burgundavia
<Burgundavia> no worries
<ukubuntu> If feisty is to be more about integrating multimedia, is it going to include codecs etc? I notice that Freespire, a derivative of lispire has these in its core install, but I do not know how they got around the legal aspect of codecs in non-proprietary software
<Hobbsee> include codecs?  no.  maybe download them from somewhere
<bhale> the only way to distribute most codecs legally is to obtain a paid license
<mdke> ukubuntu: the idea is to make them easier to install
<apokryphos> like ximian team did with helix
<mdke> semi-automatically
<ukubuntu> Ok, I know I use easybuntu to help at the moment, 
<mdke> hopefully even easier than that
<bhale> fluendo, the company behind gstreamer, is working on license-able plugins for gstreamer
<bhale> for a small fee
<ukubuntu> kewl :)
<bhale> they are giving away an mp3 decoder
<ukubuntu> I see. 
<ukubuntu> Obviously the ultimate is to make it real easy for the non-tech user if possible
<ukubuntu> And just a quick thanks to all involved in Ubuntu, it continues to astound me :)
<bhale> rock on
<ukubuntu> I am sure you have heard it before, but it does not hurt to reiterate :D
<Czubek> when is planned to unfreeze feisty?
<Hobbsee> Czubek: a week after the last person asked
<Czubek> Hobbsee: 5 XI?
<fabbione> Czubek: when the toolchain is ready
<Czubek> fabbione: What?
<Czubek> fabbione: You mean something like this: https://wiki.ubuntu.com/FeistyToolchainRoadmap?highlight=%28toolchain%29
<fabbione> Czubek: i mean new kernel, new glibc, new binutils, new gcc
<fabbione> and a test rebuild of the archive before we open the gates
<Czubek> Yes, so it's written on wiki, thanks.
<Czubek> Is, there any wiki for this specification: https://features.launchpad.net/distros/ubuntu/+spec/network-roaming ? Or should I create one from template?
<mark> what's the best way to preseed/skip all the "detect keyboard layout" bits in Edgy?
<bddebian> Howdy
<shackan> uh oh, it.archive.ubuntu.com seems down
<mark> and kr.* is not very stable...
<highvoltage> hi. I can't find the ubuntu manifesto on the website. does it still exist?
<gnomefreak> is it safe to remove libc6 to install the right version as long as you dont reboot?
<yacoob> gnomefreak, I think it would be, as long as you do it in one go. Any new process created in between will fail.
<yacoob> And because dpkg launches scripts... the answer is no I think :)
<gnomefreak> ok ty
<Amaranth> gnomefreak: yeah, you don't want to remove libc6 :P
<Amaranth> i wonder how dpkg manages to upgrade it
<tfheen> it unpacks it with .dpkg-new appended to the name, then renames it afterwards.
<Amaranth> ah
<Amaranth> i figured it was something like that
<cjwatson> mark: preseed console-setup/layoutcode to the layout name (X-style), and if you want a keyboard variant, preseed console-setup/variantname too
<cjwatson> mark: sorry, make that console-setup/variantcode
<madduck> after dapper, you guys snapshotted sid; when did this happen, and under what conditions did you import new versions from sid to fix problems, and until when?
<cjwatson> madduck: after every release, we merge everything from Debian; this process is continuous until upstream version freeze
<cjwatson> (see EdgyReleaseSchedule in this specific case)
<cjwatson> madduck: after UVF, we take new versions as it seems appropriate. Shortly after UVF, it's generally quite lenient, getting stricter as we approach release
<cjwatson> the release team apply common sense
<yacoob> hm
<yacoob> linux lacks something like growl for mac osx
<tfheen> yacoob: what is growl?
<yacoob> tfheen, pop-up system. One demon to display them, any application can register and throw message to be displayed
<yacoob> various styles, fully configurable
<yacoob> it gained critical mass, so most of the apps already come with growl support
<tfheen> yacoob: like, the notification daemon?
<yacoob> something like that I think.
<tfheen> which lives in.. the notification-daemon package. :-P
<shackan> notification-daemon is already there..
<Arador> it's something done by apple, or a third-party app?
<yacoob> Arador, third party
<yacoob> shackan, the thing is, not enough support. Still :)
<tfheen> I have plenty enough of notifications, thankyouverymuch.
<Amaranth> indeed, i get too many as it is :P
<MrKeuner> hi, what else do I need other than build-essential in order to create deb packages?
<cjwatson> the build-dependencies of the package in question
<MrKeuner> dpkg-parsechangelog: error: cannot open debian/changelog to find format: No such file or directory
<MrKeuner> dpkg-buildpackage: unable to determine source package is
<MrKeuner> why do I get these?
<cjwatson> once you have build-essential installed, you can run 'dpkg-checkbuilddeps' in an unpacked source package to see what's missing, or use 'apt-get build-dep <package>'
<cjwatson> MrKeuner: because you haven't cd'ed to the right directory
<cjwatson> assuming you just unpacked a source package and are trying to build it
<cjwatson> if you're trying to create your own package, then you need to read more :-)
<MrKeuner> I am trying to compile amyedit, unpacking it and entering the directory with configure script etc. and then running dh_make && dpkg-buildpackage -rfakeroot
<jdong> cjwatson: would you object to Backports compiling against -updates in addition to -backports?
<cjwatson> MrKeuner: then you need to read more documentation about creating packages
<cjwatson> dh_make is not intended to be used without manually checking its output
<cjwatson> it's not entirely automagic
<cjwatson> jdong: I don't think so, no
<jdong> cjwatson: where should I go to further advance this proposal?
<cjwatson> jdong: talk to infinity
<jdong> ok
<MrKeuner> hmm, dh_make output says that: Could not find amyedit_1.0.orig.tar.gz can that be due to missing packages to be installed?
<MrKeuner> Or OK could you direct me to a good resource for self compilers
<simira> cjwatson: the people wants photos of your labraweiler!
<Treenaks> s/the people/simira/
<Treenaks> :P
<imbrandon> !package guide
<mc44> hmm would it be a good idea to tell people "no, bad user" if they try and apt-get dist-upgrade
<imbrandon> hum dosent work in here, MrKeuner "/msg ubotu package guide" for the url
<madduck> cjwatson: why did you guys then stay with mdadm 2.4.1-6 or edgy, and not follow the 2.5 chain? because of the one-month-in-experimental period?
* madduck is curious to know to better optimise for the future.
<madduck> i think my work of the last 4 months fixes many of your raid problems with edgy...
<madduck> anyway, i better call it a night.
<jordi> does anyone know of cases of ubuntu not going back one hour last night?
<Treenaks> no
<Treenaks> maybe if people set the wrong time zone..
<ajmitch> morning all
<aragorn_elessar> hi at all!
<aragorn_elessar> it's normal that the "disks" entry is absent in the System-->Administration menu of edgy ?
<Seveas> aragorn_elessar, this channel is not for support
<Seveas> try #ubuntu
<cjwatson_> simira: once I find the camera :-)
<cjwatson_> madduck: we'll take it in feisty. Mostly, we eyeballed it post-UVF and it just seemed to have too high a volume of changes that we didn't have the in-house expertise to review accurately and which might well have required consequent changes elsewhere
<amnezia> having found some issues while upgrading to edgy, should I file bugs against something or should I talk to someone first about those?
<tepsipakki> amnezia: look for duplicates first
<elmo> ugh - we ended up releasing with an ndiswrapper-utils in edgy that's << dapper?
<cjwatson> elmo: I couldn't see any way to fix it
<cjwatson> given the Depends generated by the module source in dapper
<tfheen> cjwatson: we could have transitioned the -utils package to be generated by ndiswrapper-utils1.8?
<cjwatson> tfheen: AIUI the module source package in dapper produced binaries that had a tight << Depends on ndiswrapper-utils which shafted us
<tfheen> gnr, og
<tfheen> ok, even
<cjwatson> I don't remember all the details now (they were really slippery) but I looked at it at the time and couldn't see anything remotely sane to do :(
<tfheen> ok
<cjwatson> aside from "document and pray we never run into this again"
<tfheen> can we do anything remotely sane for feisty?
<cjwatson> it shouldn't be a problem for feisty any more?
<cjwatson> well, apart from the lingering future problem of dapper->next-LTS upgrades, but I was hoping we could just teach the dist-upgrader to do the downgrade if necessary
<tfheen> yeah, that's doable
<cjwatson> ndiswrapper-utils is supposed to be transitional now and will eventually go away, I'm told
<tfheen> (we do it for some compiz bits, at least)
<cjwatson> that's for the benefit of unofficial repositories, but yeah
<elmo> should I file a bug about it so we don't forget?
<tfheen> elmo: yes, please.  And milestone it "later" so we don't end up forgetting
<cjwatson> elmo: for what, the dist-upgrader?
<elmo> cjwatson: yeah
<cjwatson> IIRC it's already in mvo's branch (he tried to upload it before freeze but there were too many other changes and it got refused), but sure
<cjwatson> IIRC is not necessarily reliable of course
<elmo> err, heh
<elmo> bug 45550
<Ubugtu> Malone bug 45550 in ndiswrapper "Broken dependency of kernel module" [Medium,Unconfirmed]  http://launchpad.net/bugs/45550
<cjwatson> yow
<cjwatson> heh, so nobody could've been using those modules anyway
<cjwatson> whoops
<cjwatson> 33 "later" bugs - eek
<tfheen> cjwatson: that's not too bad, really.
<elmo> reported as bug 69158 in any event
<Ubugtu> Malone bug 69158 in ndiswrapper "ndiswrapper-utils downgraded from dapper" [Undecided,Confirmed]  http://launchpad.net/bugs/69158
<elmo> (hmm, I wish there was a way to hyperlink bugs in malone..)
<tfheen> I think it linkifies "bug #1234"
<Ubugtu> Bug 1234 on http://launchpad.net/bugs/1234 is private
<tfheen> heh
<elmo> haha, that's a great bug too
<kingos>  hello, is there a plan to release a new version of binutils for edgy? I am a c++ developer, and there is an important bug in binutils (3111) that makes edgy almost unuseable for development ...
<tfheen> kingos: uh, which bug is that?
<tfheen> bug 3111 is about something else entirely
<Ubugtu> Malone bug 3111 in launchpad-buildd "Use gzip python library instead of sys call for compressing buildlogs" [Medium,In progress]  http://launchpad.net/bugs/3111
<Chipzz> kingos: weird that the buildd's don't have much trouble building c++ packages then?
<kingos> tfheen: binutils 3111
<kingos> Chipzz: only if linking with -g
<kingos> Chipzz: ie. development!
<Chipzz> kingos: that's what the buildd's do, yes
<kingos> http://www.mail-archive.com/bug-binutils@gnu.org/msg02052.html
<kingos> I am seeing that bug and it is super annoying ... linking took 5 seconds on dapper, 3-4 minutes on edgy
<tfheen> "ld being slow" isn't something we'd issue an update for, no.
<kingos> argh
<kingos> so what are my options?
<tfheen> use the dapper binutils?
<Chipzz> being patient? :P
<kingos> tfheen: can I force install an old binutils or something? won't that break everything?
<tfheen> kingos: why would that break anything?  Just downgrade.
<kingos> tfheen: thanks
<madduck> cjwatson: fair enough. i'll look at mdadm with fabbione for feisty. I agree that 2.5 had too many changes, I spent a shitload of time on it. :)
#ubuntu-devel 2007-10-22
<mekius> bryce: that's pretty good news :)
<mekius> bryce: 7.3 sounds like it will be quite nice given all the issues I've had with monitor support and dual displays
<mjg59> mekius: There's nothing especially relevant in 7.3 from that point of view
<bryce> well, yeah what mjg said
<mekius> hmm
<mekius> Then why is that the big selling point of xserver 1.4?
<bryce> what'll fix that is better xrandr support in the drivers
<mjg59> It's not
<mekius> that you don't need to have all the monitor config :/
<bryce> input hotplug
<mekius> well xrandr then
<mekius> of course it does come down to the drivers like you say
<bryce> and actually I've heard mixed reviews about the state of input hotplug right now
<mjg59> 7.3 was the first full Xorg release with randr 1.2, but xserver 1.3 (which we shipped in gutsy) has the full protocol implementation
<mekius> well afaik, there is no driver which fully supports xrandr 1.2
<mjg59> ATI and Intel both support it
<bryce> there's still so many bugs in -intel and -ati (not only about xrandr, but...)
<bryce> I anticipate bug work for -ati and -intel is going to occupy the majority of my time for hardy
<bryce> presently I've been focusing on just trying to lay groundwork for getting more people more deeply involved in driver debugging, as I think it's going to require a broad effort to get things squared away properly
 * lamont notices that X moved to vt9, wonders why
<calc> how do you create an ellipse in gimp?
<Keybuk> with the ellipse tool?
<Keybuk> it's the second one :)
<calc> i see an ellipse select tool but not one that draws an ellipse
<Keybuk> right
<Keybuk> so select the ellipse
<calc> maybe i am just a n00b ;)
<Keybuk> then stroke it
<calc> oh
<calc> how do you do that? :)
<Keybuk> Edit -> Stroke Selection
<Keybuk> select a line width, or tool, or brush
<calc> ah! :)
<calc> thanks for the help
<calc> i'm making an image for a bug report and needed to circle something on it
<Keybuk> :)
<Keybuk> the nice thing about the way gimp does it is you can make any shape just by combining selections
<Keybuk> though it's a big obtuse
<goalieca> I was having an /sbin/modprobe abnormal exit error on the 2.6.22 series of kernels. This would happen during boot and leave it hanging with "loading manual drivers"
<goalieca> however the feisty kernel, and my newly compiled 2.6.23 kernel both function
<goalieca> this is on amd64
<t3318> hi
<t3318> anyone know how to lock icons on desktop?
<mjg59> t3318: I've no idea, but #ubuntu is the right place to ask support questions rather than here
<t3318> yes
<t3318> but I've asked this question many times there
<t3318> but noone has answer
<t3318> :(
<t3318> I think Developers may have some idea
<t3318> if developers have no idea, I don't know where to find answer :(
<Hobbsee> this is still not a support channel.
<Hobbsee> dont think you can, actually
<lamont> heh.
<lamont> so if I tell xchat to use the tree instead of tabs for channel switcher, and then don't actually join any channels on a server, then that entry in the tree is labeled '<none>'
<lamont> and private message windows don't change that
<Chipzz> Hobbsee: in gnome I think you can
<Hobbsee> Chipzz: how?  i didnt see it
<Chipzz> t3318: maybe sabayon is what you're after?
<Hobbsee> but i didnt look thru the registry, etc, either
<Chipzz> not sure if that is what you mean though
<Chipzz> sabayon is a tool for system administrators to preconfigure and lock-down gnome
<Burgundavia> Hobbsee: sabayon and gconf will let you do it
<Hobbsee> Burgundavia: right.
 * Hobbsee checks if we install sabayon by default
<Hobbsee> no
<Hobbsee> right :)
<Chipzz> heh
<Chipzz> this is weird
<Chipzz> when I run powertop, I see this coming up every now and then:
<Chipzz>    0.5% (  1.0)          ifconfig : b44_open (b44_timer)
<Chipzz> so I was wondering what spawned that
<mjg59> At a guess, I suspect it's your ethernet driver?
<Chipzz> and replaced /sbin/ifconfig with a small shell script logging ifconfig's command line args to a file in /tmp, and then invoking the real ifconfig
<Chipzz> but no files get created?
<mjg59> Uhm.
<mjg59> You've presumably ifupped your device at some point?
<Chipzz> yes
<mjg59> So...
<Chipzz> but ps aux | grep ifconfig yields no results
<mjg59> Correct. Ifconfig isn't running any more.
<Chipzz> so it is not an already running ifconfig
<Chipzz> so
<mjg59> It's a kernel timer
<Chipzz> why does it show up in powertop then?
<mjg59> Because it's causing wakeups?
<Chipzz> yes
<Chipzz> but if it is, like you say, a kernel timer, then it ought to show up in powertop like this:
<Chipzz>    0.5% (  1.2)     <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer)
<Chipzz> (or something like that)
<Chipzz> powertop has different "notations" for user space and kernel space programs
<mjg59> No
<jdong> Chipzz: well.. is 1 wakeup per second really bugging you?
<mjg59> It's a kernel timer that was triggered by a userspace process
<mjg59> Therefore it shows the process that triggered it
<Chipzz> jdong: it isn't, but I'm actually curious why it's doing that
<mjg59> Because you run ifconfig, it opens the device, opening the device causes a timer to start running
<Chipzz> which keeps running even after ifconfig has exited?
<mjg59> Assuming you wouldn't prefer the interface to be immediately downed after ifconfig exits, yes
<Chipzz> hrrrm
<Chipzz> I was assuming that something was wrong in our udev rules or something, which kept invoking ifconfig every few seconds
<Chipzz> apparently I'm wrong then :)
<pwnguin> so this isnt a recurring thing, just an artifact of ifconfig setting up some timeouts and exiting
<mjg59> Correct
<mjg59> Strictly it's the kernel that sets those up, ifconfig is just asking the kernel to bring the interface up
<mjg59> b44 just doesn't seem to have interrupts for this sort of thing
<pwnguin> hey, speaking of laptop kernel stuff, is tifm still in the ubuntu kernel?
<jdong> pwnguin: yes?
<nxvl> i cant build hardy with pbuilder, i have downloaded debootstrap from the mirrors and it doesn't work
<YokoZar> I had an application crash and now I have no mouse movement, but I do have terminal inputs. What should I do to file a proper bug?
<YokoZar> (plugging/replugging mouse doesn't wokr)
<nxvl> reportbug
<YokoZar> Well, without mouse movement (and not knowing how to reenable it without doing ctrl-alt-backspace) if I go to do that I'll spoil whatever data I can grab here.  Just wanted to know if I could dump some file first
<nxvl> heh
<nxvl> reportbug is a program to make bug reports from the terminal
<YokoZar> oh, heh.  Yeah.  Still, there won't be any info from there that I couldn't get by just going to launchpad at this point.
<YokoZar> Is there a way to reload just the mouse system of X?
<YokoZar> Or do I need to do a full ctrl alt backspace?
<YokoZar> All processes related to the app I was running are no longer running, so nothing should keep locking the mouse
<Burgundavia> nxvl: reportbug does not work in Ubuntu
<Burgundavia> YokoZar: what is locked the mouse is likely X
<Burgundavia> logout
<Burgundavia> and this really isn;t a support hcannel
<nxvl> Burgundavia: so why is it on the mirrors?
<YokoZar> Burgundavia: I know, but I'm talking about how to file a good bug here :)
<YokoZar> Anyway, thanks.  bbl.
<nxvl> Burgundavia: is debootstrap ready for hardy or it isn't?
<Burgundavia> I have no idea
<nxvl> mmm
 * calc notices he will soon get beat up about the 1ubuntu5.1 update, apparently OOo can't handle 32bpp bitmaps
<sladen> nxvl: apt-get source and find out :)
<m1ke> Anyone here use a solid state hard drive?
<jdong> m1ke: offtopic?
<m1ke> jdong, you the man as this is where you hang out at.  ;)
<dholbach> good morning
<ION_> Good morning, and MERRY CAPS LOCK DAY.
<dholbach> HEY ION_!
<pitti> Good morning
<dholbach> heya pitti
<manchicken> mhb: ping
<dholbach> hey thekorn_
<dholbach> so how's hardy looking? :-)
<manchicken> Actually, I'm looking for mvo...
<manchicken> mvo's UTC+0300, right?
<liw> manchicken, if he's in Germany, that's UTC+0200 right now
<manchicken> Okay.
<manchicken> So that's what, 8041?
<manchicken> 0841*
<dholbach> yes, he usually gets up a bit more late :-)
<dholbach> also he might be at ubucon germany
<manchicken> Righto.  I'm at 0142, just trying to figure out libapt a bit.
<manchicken> Seems like he's the only one that's quite cracked that nut.
<dholbach> you could say that :)
<manchicken> Oh, believe me, I am saying that.  And what a nut it is.
<manchicken> And I'm trying to pry open that coconut with a toothpick...
<manchicken> Is anybody else having trouble getting python-mode loading in emacs22?
<sladen> manchicken: it doesn't matter if other people are you not.  If _you_ are having trouble loading python-mode in emacs22, then that is a bug
<sladen> manchicken: for me, python-mode got uninstalled, so you may need to reinstall it
<manchicken> sladen: Well emacs22 is supposed to have one.
<manchicken> And if I `M-x load-library python` in emacs then I get some font-lock-mode goodness, but not the really slick python-mode that I came to know and love under emacs21.
<sladen> manchicken: I'm sure emacs22 is supposed to bigger, better and bolder
<sladen> so far the only one I can confirm is that its bigger
<manchicken> So emacs22's built-in python mode seems to suck, if what I've got of it is the right fella.
<manchicken> Well its supposed to have UTF8 support.
<manchicken> IIRC
<manchicken> Which would account for the bigger.
<sladen> might aswell install the external python-mode you've grown to know and love under emacs21
<manchicken> Which requires emacs21
<sladen> Depends: emacs21 | xemacs21-bin | emacs-snapshot | emacsen
<manchicken> Submitted bug #155681
<ubotu> Launchpad bug 155681 in emacs22 "python-mode seems broken in emacs22" [Undecided,New] https://launchpad.net/bugs/155681
<sladen> emacs22 Provides: emacsen
<sladen> manchicken: responded, is it still broken?
<manchicken> Nope
<manchicken> I've tried that one several times, too :)
<manchicken> I gave you the output of the install though.
<sladen> manchicken: can you paste it into the bug report, along with the output of from the two command lines I've just included into it?
<manchicken> I did :)
<manchicken> sladen: replied
<manchicken> Alright, I've gotta go to bed.  Catch you later.
<S^n1x> does any one here knows what's the purpose of the ~/.local directory ?? why it will mass up ur system if the permission is set to something else ????
<Mithrandir> S^n1x: this is a channel for development of Ubuntu, not a support channel.  Please ask in #ubuntu.
<S^n1x> ok, thanks
<dholbach> hey seb128
<dholbach> hey raphink
<seb128> hello dholbach
<raphink> hi dholbach && seb128
<seb128> hey raphink
 * Hobbsee waves
<raphink> hi Hobbsee
<highvoltage> *hugs* all round
<Hobbsee> *hugs highvoltage back*
<sladen> hey, hey, don't show too much faviouritism.  There's 211 people on this channel, and they'll all be wanting a hug at this rate
<Hobbsee> sladen: oh well :P
<Hobbsee> sladen: although, the ones talking are the ones likely to want hugs.
<pwnguin> well, when everyone hears hobbsee's handing out free hugs
 * sladen stands around uncomfortably looking at the ceiling
<pwnguin> it'll be more popular than #u-r-p
 * RAOF hugs Hobbsee, and coffee, and the nvidia drivers that inexorably leak memory with compiz
 * highvoltage is glad he still got a while there still was one available
<highvoltage> insert a "hug" somewhere between "a" and "while" :)
 * Hobbsee refuses to hug RAOF, as he didnt come to the release party.  nyah :P
 * RAOF is a sad panda.
 * pwnguin is a skull panda
 * RAOF has a skull.
<RAOF> And a raven.
<RAOF> It's all very gothic.
<pwnguin> so do you bother informing nvidia their drivers leak, or just silently wait for nouveau to become the official nvidia driver?
<RAOF> pwnguin: Point me to a damn nvidia bugtracker, and I'll file bugs.
<pwnguin> oh, i never said there was one
<RAOF> Yeah.  The least they could do is actually have somewhere to constructively bitch at them.
<pwnguin> they have a forum
<pwnguin> but i guess its not constructive really
<Hobbsee> forumsdonotmakegoodbugtrackerskthxbye
<pwnguin> no they dont
<pwnguin> spacesmakegoodfriendswithworks
<Hobbsee> seb128: ping
<pwnguin> Hobbsee: the question is, do you push for nvidia to adopt a bug tracker, or hope they fold under their own weight?
<seb128> hey Hobbsee
<Hobbsee> seb128: new gnome seems to work fine here, btw (from -proposed)
<seb128> Hobbsee: cool, thanks ;-)
<RAOF> pwnguin: Neither.  I bitch on irc!
<Hobbsee> pwnguin: you dont buy nvidia cards.  easy fixed.
<RAOF> pwnguin: But I'll plump for the latter.  Maybe with the panacea of open specs.
<dholbach> RAOF: linux-bugs@nvidia.com
<pwnguin> Hobbsee: what do i buy then?
<Hobbsee> pwnguin: intel cards.
<pwnguin> ok.
<pwnguin> newegg link?
<RAOF> pwnguin: ATI cands, soon, hopefully.
<Hobbsee> pwnguin: and of course, the most effective bitching is done on livejournal, which is not syndicated to planet, nor anywhere else.
<Hobbsee> pwnguin: i'm not in the US.  now newegg here.
<pwnguin> well the point was that intel doesnt sell cards
<pwnguin> they sell chips
<Hobbsee> oh, nyah.  well, wahtever.
<pwnguin> RAOF: has novell published a source repo or anything like that for their alleged efforts?
<Hobbsee> the point is that you buy cards from a manufacturer where you dont have to give a damn about compatibility, as they have open drivers, and it all Just Works :)
<pwnguin> heh
<pwnguin> except when this manufacturer is mythical
<RAOF> pwnguin: Doesn't gutsy already have the first whack at that driver?
<pwnguin> RAOF: i donno
<pwnguin> its got an open ati driver for some stuff, but i think you knew that
<RAOF> pwnguin: There's -ati, -fglrx, -avivo, and something like atihd which is the new open driver.
<pwnguin> Hobbsee: if you want an amd motherboard, you cant get intel video =(
<Hobbsee> but why do you want an amd motherboard?  :)
<pwnguin> ive no idea. i already have one. when i bought it, intel didnt even do 64 bit
<sladen> the only AMD based motherboard it'd be worth having is the OLPC one;  which is at least open down to the core
<pwnguin> or maybe you really like opterons
<pwnguin> and their fantastic hypertransport cores
<pwnguin> at which point, you likely dont care for video at all
<Hobbsee> pwnguin: as you might be able to see, i'm not much of a hardware geek.  i just want it to work :)
<pwnguin> sure, but perhaps you could realize that hardware exists before the dawn of choice
<Hobbsee> true :)
<sladen> I have this laptop, it has a builtin keyboard, UPS, nipple and screen.  Covers most of what I need
<Hobbsee> sladen: i'm not that bad ;P
<sladen> oh, I am
<sladen> if it's ain't black, send it back
<pwnguin> I don't recall the Ubuntu core principles being "Free of charge, because you'll need to buy a new computer to run it"
<pwnguin> :)
<pwnguin> anyways, hopefully ati will make good on it's suggestions of open drivers
<pwnguin> and in some cases, one can at least say, "trade your card for an ati" or something
<pwnguin> but im not sure if one bothers asking nvidia to set up a public bug tracker if it might lead to a less buggy closed driver and clamp demand for an open driver
<pwnguin> there's also linux-bugs@nvidia.com and a bug report script
<pitti> doko: our current debhelper dh_python adds '2.5' as version, but Debian didn't do this; I think we can drop this since it's a no-op now, and packages should use dh_pycentral or dh_pysupport; is that ok?
<doko> pitti: it' not a no-op for unconverted packages (which we might still have in some dark universe corners)
<pitti> doko: ok, I'll keep it for now
<Hobbsee> cjwatson: remind me...we don't need to request sync request of build* versions of programs in ubuntu, do we?
<Hobbsee> (and if this is true, why are build*'s showing up in the merge-o-matic?)
<Mithrandir> Hobbsee: no, you shouldn't need that.
<Hobbsee> Mithrandir: good, OK.
<vegpuff> hi, any idea about https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/25931 ? i am not able to start hal
<ubotu> Launchpad bug 25931 in dbus "Failed to initalize HAL." [High,Incomplete]
<vegpuff> i am not able to detect my hardware because of that
 * Hobbsee suspects #ubuntu is a more appropriate channel
<vegpuff> Hobbsee: i couldn't find any solution for this @ #ubuntu
<vegpuff> being a high, incomplete bug, i prefered to check the status with the dev's
<ogra_cmpc> you should do that on the bugtracker then :)
<vegpuff> ogra_cmpc: :) okay
<DktrKranz> pitti, mind looking at bug 112729 ?
<ubotu> Launchpad bug 112729 in bootcd "[bashism] /usr/share/bootcd/bootcd-run.lib: 144: Syntax error: "(" unexpected" [Medium,Fix committed] https://launchpad.net/bugs/112729
<slomo> mjg59: did you forward all your hal patches upstream?
<ogra_cmpc> seb128: what would happen if i disable the cron.monthly scrollkeeper-update, would only my docs be out of date or could worse stuff happen ?
<seb128> ogra_cmpc: probably nothing, it's call by the postinst of packages installing scrollkeeper documentation
<ogra_cmpc> well, cron runs it as well
<ogra_cmpc> i'll disable it then
<ogra_cmpc> (it pulls teh classmate out of business for 1h if it runs)
<seb128> ogra_cmpc: ah, that's a rebuilddb, not an update called in the cron
<ogra_cmpc> ah
<seb128> ogra_cmpc: it's mentionned on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95402
<ubotu> Debian bug 95402 in scrollkeeper "strange symlinks in /var/lib/scrollkeeper/" [Normal,Fixed]
<seb128> looks like that's a "rebuild the database every now and then in case it would not be correct"
<seb128> not sure if it still makes sense
<ogra_cmpc> i'll look (takes a while to get FF up here :) )
<seb128> ogra_cmpc: I would say it doesn't make sense, users would notice breakages before the cron run
<ogra_cmpc> right
<ogra_cmpc> asac: i saw there was a mobile browser specced for UME, is that going to happen ?
<pitti> DktrKranz: looking
<pitti> DktrKranz: done
<DktrKranz> pitti: thanks
<asac> ogra_cmpc: hmm
<ogra_cmpc> using FF on the classmate gets quite painful over time (disk IO sucks so the fuller the cache the worse it gets)
 * ogra_cmpc wonders how UME solves that
<asac> ogra_cmpc: hmm ... i remember that bug.
<asac> ogra_cmpc: thats something we should definitly look into for UME ... the patch would be beneficial for you as well i guess
<ogra_cmpc> yeah
<asac> ogra_cmpc: i think i looked into this once and the problem was that on unix there is no implementation of "get_memory_pressure" ... or something like that
<ogra_cmpc> well, the spec looked like you planned to slim down the xul backend as well
<asac> which should return a measure of how much memory is utilized ... the result of that is used to discard the cache
<asac> ogra_cmpc: i haven't drafted the spec ... do you have an url?
<ogra_cmpc> i.e. using epiphany doesnt help much, must be gecko thats slowing down
<ogra_cmpc> https://blueprints.launchpad.net/ubuntu/+spec/mobile-browser
<seb128> ogra_cmpc: what about using epiphany with webkit? it's not ready yet but maybe for hardy...
<asac> seb128: news on whether epiphany devs plan to make the rendering engine pluggable vs. compile-time switch?
<seb128> asac: no, I've read nothing indicating that for the moment but the 2 flavors can be installed together
<ogra_cmpc> seb128: i was planning to have a look at it ... currently it doesnt behave any differently to FF here it renders the fonts more appropriate though
<ogra_cmpc> but i think UME will have to solve that anyway ,,,,
<seb128> ok
<Mithrandir> ogra_cmpc: hm?  Why would we have to care about epiphany in ubuntu-mobile?
<ogra_cmpc> currently it takes several munites for me to load planet here (thanks to quim gil and his pic collections :)) www.heise.de (not many pics loads instantly though)
<ogra_cmpc> Mithrandir: you dont, but i suspect you wont just use the firefox we have without customizations :)
<Mithrandir> ogra_cmpc: we're using midbrowser.
<ogra_cmpc> thats the one from the spec above, right?
<Mithrandir> ogra_cmpc: yes.
<ogra_cmpc> wher can i get it ? seems not packaged
<Mithrandir> midbrowser | 0.1.6c-0ubuntu1 | gutsy/universe | source, amd64, i386, powerpc
<Mithrandir> midbrowser | 0.1.6c-0ubuntu1 | hardy/universe | source, amd64, i386, powerpc
<Mithrandir> seems about as packaged as it gets to me
<ogra_cmpc> hmm, right, i'm just blindc
<Mithrandir> ogra_cmpc: oh, sorry, I thought you were talking about pluggable backends to epiphany.  The memory pressure thing I'm less sure what we'll do about.
<ogra_cmpc> Mithrandir: its mainly disk IO i'm concerned about
<ogra_cmpc> all operations from ram are fine here
<ogra_cmpc> but as soon as pics get stored it starts to suck up all IO
<asac> ogra_cmpc: so your problem is not the "in-memory" cache, but the disc cache?
<ogra_cmpc> asac: yup 2Gig USB flash disk
<ogra_cmpc> its pretty slow in general already
<asac> ogra_cmpc: you sure the IO you see is not swap?
<ogra_cmpc> there is no swap on this system
<ogra_cmpc> that would kill teh diskk pretty fast :)
<asac> ogra_cmpc: does ffox get OOM frequently for you?
<ogra_cmpc> no, it doesnt reach that point at all
<ogra_cmpc> it rather makes the system die on IO before it runs out of ram
<asac> ogra_cmpc: but it worked before, right?
<asac> or was it always that way?
<ogra_cmpc> it was always slow
<ogra_cmpc> it got worse between feisty and gutsy though
<asac> slow != dying
<asac> ok
<ogra_cmpc> well, on this HW slow == dying
<ogra_cmpc> to much disk IO and the system gets totally unresponsive
<ogra_cmpc> the probs with teh oom scheduler only showed in ltsp for me
<asac> ogra_cmpc: ltsp is even less memory or what?
<ogra_cmpc> can be, yes
<ogra_cmpc> classmate has 256M
<ogra_cmpc> but runs the whole sys and desktop in this amount
<ogra_cmpc> ltsp can run with 48M
<ogra_cmpc> and ojnly runs teh X server and login manager
<ogra_cmpc> *but* the habit of ff using (and X allowing the client to) up all available ram on teh Xserver makes teh clients hardlock
<ogra_cmpc> on the classmate i dont run out of ram, but being able to tweak the cache settings might also resolve a lot
<iwj> cjwatson: Would you be able to get me copies of glibc-2.6.1-1ubuntu1.{dsc,diff.gz} ?  They seem to be before my archived snapshots window.
<iwj> glibc (2.6.1-1ubuntu1) gutsy; urgency=low
<iwj>  -- Matthias Klose <doko@ubuntu.com>  Tue, 28 Aug 2007 13:04:00 +0200
<asac> ogra_cmpc: about:config ... search for cache
<iwj> cjwatson: Or who should I ask ?
<asac> ogra_cmpc: i assume you already did that ... didn't you?
<asac> ogra_cmpc: e.g. browser.cache.disk.enable
<asac> ogra_cmpc: there is even ... browser.cache.memory.enable
<iwj> cjwatson: If it's easy then having 2.6.1-1ubuntu3 too would be useful.
<asac> ogra_cmpc: looks like setting both to false should disable caching completely
<doko> iwj: https://edge.launchpad.net/ubuntu/+source/glibc/2.6.1-1ubuntu1 (and more general https://edge.launchpad.net/ubuntu/+source/glibc/) at the bottom of the page
<iwj> cjwatson: Oh, if I URL-hack the source it works.
<cjwatson> iwj: they should be fishable out of launchpad
<pitti> iwj: get it from here: https://edge.launchpad.net/ubuntu/+source/glibc/2.6.1-1ubuntu1
<cjwatson> ... yes, as above :)
<ogra_cmpc> asac: hmm, i'll try, thanks
<iwj> I tried this https://edge.launchpad.net/ubuntu/hardy/+source/glibc/2.6.1-1ubuntu1
<ogra_cmpc> midbrowser takes 3min to load planet as well here btw
<iwj> and didn't spot `hardy' in the URL.
<cjwatson> iwj: from the links at the top of /ubuntu/+source/glibc ?
<iwj> cjwatson: Yes.
<cjwatson> if you use the links further down (in the big list rather than the what's-in-each-release table) then it works
<iwj> I picked the top one and edited the URL.
<iwj> Indeed.
<asac> ogra_cmpc: let me know if it works/helps
<manchicken> Anybody sighted mvo this morning?
<Hobbsee> manchicken: he went mad, so we shot him.
<asac> manchicken: iirc, he is not available today
<manchicken> Hobbsee: Nooooo!  He's our only hope for libapt.
<Hobbsee> manchicken: too bad.  it's your job, now.
<manchicken> Is there anybody else who knows this stupid library?
 * Hobbsee doesnt,b ut wants to learn it at some point
<asac> manchicken: is it really urgent? otherwise he will probably be avail tomorrow.
<manchicken> We should force nixternal to document it.
<Hobbsee> sounds good.  voluntell him to
<manchicken> asac: I'm just trying to work on but #104182.
<asac> bug #104182
<ubotu> Launchpad bug 104182 in adept "Adept allows removal of essential packages without warning" [High,Confirmed] https://launchpad.net/bugs/104182
<manchicken> asac: Much thanks.
<manchicken> asac: If you read my second-to-last comment, I think that if left unchecked this could pose a bit of a script-kiddie risk
<asac> manchicken: i agree that this is a bug ... but security? ... no i don't think so.
<manchicken> asac: I didn't say security for sure, I just said that I think I can see how it would be a low but still somewhat potential security risk.
<manchicken> asac: You read my terribly clever script-kiddie scenario?
<manchicken> Aww, weak.  My emacs issue got bumped to debian.
<asac> well ... if users execute a script they get from a 3rd party with sudo ... they risk more than just loosing libc ;)
<manchicken> Yes.
<manchicken> Except that scripts can actually execute themselves with sudo, so if the user didn't read the script (because maybe they don't know how to read scripts) they're at just as much risk as the unwise who intentionally execute scripts as sudo.
<manchicken> All they'd have to do is run it.
<saispo> xen ubuntu kernel have a git repository ?
<manchicken> We're targetting not only folks like ourselves with our distro, but we're also targeting the average desktop user... so we kinda need to keep their experience level in mind.
<pitti> ajmitch: FYI, I merged tzdata and uploaded it (in the queue now)
<pitti> seb128: all gutsy-proposed updates except of pango accepted
<pitti> doko: you had a question/concern about the pango update? it's in gutsy-proposed now
<doko> pitti: I'm happy if OOo still works. this should be tested
<pitti> seb128: ^ did you try this?
<pitti> the patches look reasonably straightforward and isolated, but a test can't hurt, right
<asac> please test FF as well
<asac> (for pango updates)
<asac> seb128: ^^
<seb128> pitti, doko, asac: isn't the purpose or proposed to get testing because sending things to update?
<seb128> s/or/of
<pitti> seb128: right, but it should be tested before, too :)
<seb128> pitti: do I look like somebody who randomly upload things without testing ? ;-)
<asac> seb128: yes .... i just want to be sure. do we have any figures on how many people participate in testing proposed?
<seb128> asac: no idea
<asac> seb128: definitly ;)
<seb128> heh!
<pitti> seb128: no, you don't, and I wasn't implying you were; doko just raised a "*mumble* pango please ask me before" some days ago
<seb128> pitti: I do run most of the updates for some time before uploading even to unstable distros, especially base libs
<seb128> pitti: ok, I've read the diff, look to upstream bugs opened since the new version and tested locally
<pitti> seb128: I can take that as "yes, ffox and OO.o still work with that pango" :)
<seb128> pitti: now feel free to deal with doko request the way you prefer ;-)
<asac> pitti: ;)
<seb128> pitti: yes
<ogra_cmpc> asac: thanks disabling the disk cache helped a little bit though i just discovered errors from teh ralink driver here, might be related
<pitti> seb128: /me hugs seb128, thanks
<seb128> for my usecase of those, which means basic testing
<seb128> since I'm neither a firefox or openoffice fanboy
<asac> ogra_cmpc: which cache did you disable?
<asac> memory + disc ... or just disc?
<seb128> I just open and randomly click and load some examples
 * seb128 hugs pitti back
<ogra_cmpc> asac: since my probs are mainly disk related and i have enough ramj i disabled the disk cache ... planet loads in a usable speed now
<asac> ogra_cmpc: ok ... if you get oom after some browsing try to turn of memory cache as well
<asac> ogra_cmpc: try that for your ltsp issues
<ogra_cmpc> asac: i'll try in ltsp
<asac> ogra_cmpc: hopefully it will release x server resources for you as well
<ogra_cmpc> i dont expect that i'll hit oom on the classmate though
<ogra_cmpc> (the final image will have a ulimit for memory anyway )
<iwj> Are we expecting recent security updates to have broken ipw3945 somehow ?
<Hobbsee> iwj: no?
 * agoliveira feels fortunate. Never had an issue with ipw3945
<iwj> This is my Mum's laptop which has mysteriously stopped working.
<bdmurray> Riddell: I haven't see the new Kopete in gutsy-proposed.  Do you know where it is?
<Riddell> bdmurray: it's actually kdelibs that got updated
<Riddell> (twice)
<Riddell> bdmurray: https://bugs.edge.launchpad.net/ubuntu/+source/kdelibs/+bug/153500 and https://bugs.edge.launchpad.net/ubuntu/+source/kdelibs/+bug/155144
<ubotu> Launchpad bug 153500 in kdelibs "Kopete crashes on startup" [High,Fix committed]
<iwj> Hmm, wired connection maybe not working either.  I blame network-mangler.
<Riddell> bdmurray: also https://bugs.edge.launchpad.net/ubuntu/+source/qt-x11-free/+bug/145709
<ubotu> Launchpad bug 145709 in qt-x11-free "7.10: Qt3 /etc/qt3/qtrc owner root result in ugly appearance" [Undecided,In progress]
<Riddell> bdmurray: and finally https://bugs.edge.launchpad.net/ubuntu/+source/adept/+bug/153889
<ubotu> Launchpad bug 153889 in adept "feisty dist upgrade check does not work" [High,In progress]
<bdmurray> I'll see what I can do today
<StevenK> ogra_cmp1: midbrowser
<StevenK> Er, gah
<ogra_cmp1> heh
<ogra_cmp1> thanks
<asac> iwj: feisty?
<iwj> asac: t
<iwj> asac: I discovered it was the hardware kill switch.  This is very hard to debug remotely and although the driver knows what's happened it doesn't tell the user.  I was able to fix it quite quickly after we got the machine connected with a wire and I could log in.
<iwj> asac: I've filed bug 155867.  (Not sure the package is right.)
<ubotu> Launchpad bug 155867 in network-manager "kill switch induces mystifying failure" [Undecided,New] https://launchpad.net/bugs/155867
<mjg59> iwj: The mechanism used to provide information about kill switch status is currently non-standard across different wireless drivers
<pitti> mjg59: new hal 0.5.10 only supports pm-utils; do we want to go that route, too?
<mjg59> Yes
<iwj> mjg59: Joy.
<pitti> mjg59: Debian does that, too
<iwj> mjg59: But thanks for the info :-).
<mjg59> pitti: Hurrah
<mjg59> Then we can gradually kill off acpi-support
<sladen> poor acpi-support
<sladen> so we start working on a whole new sets of laptop hacks now?
<mjg59> No, we merge them over
<pitti> mjg59: and pmi, too, right?
<mjg59> Yeah
<mjg59> As long as stuff's calling hal, nothing should breaj
<unggnu> hi all
<ogra_cmp1> what about policykit ?
<ogra_cmp1> will we use that too now ?
<pitti> not in my initial merge at least
<pitti> (I'm currently doing the hal merge to 0.5.10, fresh in incoming :) )
<unggnu> I have a question for closing bugs. There are many bug reports according to package 915resolution. Most of them should be fixed through new Intel driver in Gutsy. Should they be marked as Fix released since 915resolution most likely has the same problem or invalid because it works with another version?
<ogra_cmp1> well, i would suspect pm-utils might need i9t
<pitti> I'm still not 100% confident about it, and need to review it
<pitti> ogra_cmp1: why should it?
<ogra_cmp1> no idea just because they were developed hand in hand ?
<ogra_cmp1> (or do i mix up stuff ?)
<pitti> ogra_cmp1: if Debian enables it, I'll do as well, of course
<pitti> ogra_cmp1: consolekit will be important for hardy's revamped hardware detection (but we have that already)
<ogra_cmp1> yeah, i fear that in ltsp already
<ogra_cmp1> getting ldm consolekit aware will surely be fun :P
<pitti> wow, with the removal of hal-device-manager, our hal delta to Debian shrinks to something actually manageable \o/
<ogra_cmp1> what happened to h-d-m ?
<pitti> ogra_cmp1: there's a new independent project, gnome-device-manager
<ogra_cmp1> cool
<daSkreech> Hello
<daSkreech> Who should I speak to about smolt?
<persia> daSkreech: It depends on what you want to do.  If you need help with smolt, you want #ubuntu.  If there are bugs in smolt, you want #ubuntu-bugs.  If you are patching or packaging smolt, please ask a specific question: many people here can help.  If you would like smolt to be packaged, please open a bug in launchpad.
<daSkreech> Is ubuntu making any plans to align itself with the smolt project?
<sladen> sounds very the Ubuntu hardware database
<ogra_cmp1> daSkreech: we already have a hardware db but i think there are efforts going on between the teams
<ogra_cmp1> daSkreech: cr3 is on teh hdwb team
<daSkreech> hi cr3
<daSkreech> ogra_cmp1: Yes but wouldn't a hwdb that pulls info from multiple distros be more useful ?
<ogra_cmp1> daSkreech: well, depends on the purpose ... i think there is data where it makes sense qand data where it doesnt
<daSkreech> ogra_cmp1: true but ubuntu can run it's own staging smolt server for where it doesn't make sense
<keescook> slangasek: heh, I guess my (redundant) +1 was about 8 hours too late.
<ogra_cmp1> at least it was something positive :)
 * slangasek chuckles
<infinity> vorlon: Do you nick hilight "correctly" here, for people who refuse to acknowlege your newfound professionalism?
<Nafallo> oooh... infinity :-)
<jdong> pitti: hey, you gotta sec? ScottK and I would like to talk to you about SRU'ing azureus...
<pitti> jdong: can you please mail me? I need to run in 5 minutes
<Nafallo> infinity: mail delivery fixed now? :-)
<ScottK> jdong: Please cc me on the mail.
<jdong> ok
<infinity> Nafallo: Been doing Real Work first, while I fix mail stuff in the background...
<infinity> Nafallo: (tomorrow, I imagine, it'll stop bouncing, cause I'll get around to cleaning out the mess)
<asac> iwj: the kill switch issue is known and is a driver bug
<Nafallo> infinity: kewl. screwed our ticketer a bit ;-)
<infinity> Nafallo: I live to give.  Or annoy.  Whichever.
<asac> iwj: bug 121415
<ubotu> Launchpad bug 121415 in linux-ubuntu-modules-2.6.22 "[gutsy] ipw3945-based wireless doesn't work after booting with wireless switch off" [Medium,Confirmed] https://launchpad.net/bugs/121415
<Nafallo> infinity: :-)
<infinity> Nafallo: If my bouncing mail resulted in finding bugs in peoples mailers (namely, the fatal flaw of not realising that sometimes mail doesn't actually get there), then I did well. :)
<Nafallo> infinity: hehe. it was more the amount of notices about it not being able to deliver ;-)
<slangasek> infinity: yes... :)
<infinity> vorlon: Excellent.
<slangasek> keescook: I think there's a blog post hiding in there, btw.  "It only took a weekend for me to be accepted as a MOTU, why did it take two whole months for me to get a Debian account?  I guess Debian doesn't care about new contributors, I should just work on Ubuntu instead." >:)
<lamego> slangasek, getting such conclusions about the lack of "care" from Debian is a bit excessive don't you think ?
<slangasek> lamego: sorry, I suppose the context for that comment is not obvious to everyone here, but I've been a Debian developer for almost 7 years... :)
<cr3> daSkreech: hi there
<lamego> sorry, just caught that phrase, and it did seem a bit rude
<daSkreech> cr3: hello
<daSkreech> cr3: Whats up in the hardware world of ubuntu?
<cr3> daSkreech: we're working very hard towards having a practical interface for providing hardware compatibility information with ubuntu
<Riddell> what's the part of ubuntu that detects newly inserted printers?
<slangasek> Riddell: hal+cups?
<cr3> daSkreech: you mentionned earlier whether we might consider aligning ourselves with smolt and there's no such plans right now. that is something I've had in mind though, but it's too early to know for sure
<daSkreech> cr3: what does it depend on?
<Riddell> slangasek: I mean the bit that pops up a UI
<cr3> daSkreech: it currently depends on a strict XML format which can be generated by the hwtest project on Launchpad or by any other tool
<slangasek> Riddell: well, hal-cups-utils seems to be the package that triggers the pop-up, by sending a dbus message
<slangasek> Riddell: I don't know what catches it though
<daSkreech> cr3: ubuntu does or smolt does?
<slangasek> (com.redhat.NewPrinterNotification)
<daSkreech> cr3: Sorry the question was what would ubuntu using smolt depend on?
<daSkreech> hi ompaul
<ompaul> hi
<cr3> daSkreech: in using smolt, do you mean posting to the smolt daemon or using the smolt information gathering library?
<daSkreech> Well If you were posting to the smolt daemon you could run a ubuntu hosted staging server then pass on generally useful info to the "main" smolt gathering library
<daSkreech> cr3: so I guess posting to the smolt daemon
<daSkreech> since I don't know that there are any restrictions to using the gathered information already
<keescook> slangasek: heh.  no kidding, I'm still waiting for my DD-ness.  :)
<cr3> daSkreech: the posting could be done either server side from Launchpad or client side from hwtest. I don't know about the former but the latter can easily be extended to post the information wherever and also extended to gather whatever additional information might be required from smolt.
<daSkreech> cr3: so smolt should be an option for people in hardy?
<cr3> daSkreech: if you write it, we could probably make a package for extending hwtest to post to smolt :)
<cr3> daSkreech: otherwise, I can't make any promises
<daSkreech> that would be nice :)
<xipietotec> anyone know why firefox is kerning fonts weirdly? I was allready using the libfreetype6 patches in feisty, and had no problem, now since upgrading to gutsy, my font literally gets letters kerned over eachother.
<slangasek> xipietotec: yes, that's bug #37828
<ubotu> Launchpad bug 37828 in firefox "Text rendered incorrectly in presence of ligatures and justified text" [Medium,In progress] https://launchpad.net/bugs/37828
<Chipzz> holy fsckeroni
<Chipzz> firefox just went ballestic on me
<Chipzz> decided it needed to grow 80MB in pixmaps just by scrolling :(
<xipietotec> why would they go back to doing things the broken way in gutsy? even if the way in feisty was somewhat hackish, it didn't really cause any problems
<xipietotec> oddly, it only happens on some pages, and using the liberation fonts it don't happen
<slangasek> yes, because not all fonts have ligatures
<slangasek> it wasn't a problem in feisty because the font upstream made specific changes to accomodate the firefox bug
<slangasek> and decided not to do that anymore in the gutsy timeframe
<juliux> hi
<juliux> why i cant read https://bugs.launchpad.net/bugs/155545 ?
<geser> juliux: I guess because it got marked private (for whatever reason)
<juliux> geser, so nobody can read this bug?
<geser> juliux: the security team and subscribed persons (incl. the reporter)
<juliux> geser, ok
<xipietotec> juliux, I suppose there are reasons to make a bug private, e.g., if you found a security flaw that other people would be unlikely to exploit or discover without your knowledge, that's a good reason to keep quiet about it until a fix.
<Keybuk> oops, my nipple just fell off
<lifeless> did it hurt ?
<lifeless> and btw, put yourself on quotes :)
<Keybuk> lol
<Keybuk> no
<juliux> xipietotec, geser thanks
<cjwatson_> xipietotec: often happens by accident too (reporter checks the checkbox "this is a security vulnerability" either by mistake or because it's a tickybox)
<bryce> ogasawara: bug 149639 could probably use more triaging attention; we bumped it to kernel from X since the user is having kernel panics rather than X crashes.  Probably needs a better title too.
<ubotu> Launchpad bug 149639 in linux-source-2.6.22 "Xorg crashes very frequently" [High,Confirmed] https://launchpad.net/bugs/149639
<ogasawara> bryce: ok, I'll take a look
<manchicken> Hmm... no mvo.
<Keybuk> holiday today
<juliux> manchicken, mvo had to work last saturday;)
<Keybuk> juliux: hey, he wanted to work!
<Keybuk> in fact, he demanded he be aloud to work :p
<juliux> Keybuk, i think forced him to work on saturday;)
<juliux> Keybuk, he was at ubucon with an ubuntu devel talk;9
<goobsof2> I'm running ubuntu feisty, and I can't download the dependencies to build openssh-client.  Can someone help me?
<goobsof2> sudo apt-get build-dep openssh-client
<goobsof2> E: Build-dependencies for openssh-client could not be satisfied.
<robertj_> can someone help me out with some google juice: what is the blinking _ called in the terminal?
<Robot101> cursor?
 * robertj_ smacks head
<tonyyarusso> Who maintains the debian installer for the alternate CD these days?  I know cjwatson used to, but I thought I heard he was passing it off now.
<slangasek> I haven't heard that
<slangasek> I have seen him doing uploads
<tonyyarusso> Oh.  All righty then.  I'll still harass him with feature requests until he tells me otherwise then.  :P
<tonyyarusso> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/debian-installer/+bug/155987 is what I wanted to point out :)
<ubotu> Launchpad bug 155987 in debian-installer "Installer doesn't support mounting existing encryption volumes" [Undecided,New]
<cjwatson> goobsof2: you have mail
<cjwatson> tonyyarusso: d-i is modular, so I sort of hope that somebody other than me can take care of the encryption bits ...
<cjwatson> there's quite a lot of d-i to take care of :)
<tonyyarusso> cjwatson: Makes sense.  Any idea who was responsible for adding the encryption stuff upstream in Debian?
<cjwatson> tonyyarusso: David HÃ¤rdeman and Max Voxeler
<cjwatson> (see the partman-crypto changelog)
<tonyyarusso> cjwatson: Do they have LP accounts I can subscribe?
<cjwatson> I have no idea. I'd mail them
<tonyyarusso> Ok, will do.
<goobsof2> You know I was actually drilling down just as you suggested and it seems I've got a bogus version of libcairo2.  1.4.10-1turner3~feisty0.1 instead of 1.4.2-0ubuntu1.
<goobsof2> libcairo2-dev: Depends: libcairo2 (= 1.4.2-0ubuntu1) but 1.4.10-1turner3~feisty0.1 is to be installed
<goobsof2> I'm trying to figure out how I can replace that one package without un-installing everything that it depends on.
<cjwatson> goobsof2: sudo apt-get install libcairo2/feisty # ?
<cjwatson> possibly with --reinstall
<tonyyarusso> cjwatson: is that changelog in the debian-installer package, or elsewhere?
<cjwatson> tonyyarusso: in the partman-crypto source package
<cjwatson> debian-installer is just the build system
<goobsof2> genious.  That's a ton.  Now it all works.
<cjwatson> goobsof2: good stuff
<tonyyarusso> doh
 * tonyyarusso enables source packages
<cjwatson> tonyyarusso: though if you're doing serious work on d-i then it's best to have a full upstream checkout: svn+ssh://svn.debian.org/svn/d-i/trunk
<goobsof2> I didn't even know about that install syntax...
<cjwatson> then it's in packages/partman/partman-crypto/
<tonyyarusso> cjwatson: I don't know enough to do work - just reporting
<cjwatson> tonyyarusso: in fact, it might be better to forward it as a Debian bug
<cjwatson> and then add a bug watch to the LP bug
<tonyyarusso> cjwatson: good point
#ubuntu-devel 2007-10-23
<tonyyarusso> cjwatson: so should this be filed against partman-crypto instead of d-i then?
<cjwatson> yes, I already reassigned the LP bug
<cjwatson> (debian-installer is a reasonable starting point for alternate installer bugs, though)
<tonyyarusso> cool
 * tonyyarusso tries to figure out Debian bug reporting....
<cjwatson> tonyyarusso: http://www.debian.org/Bugs/Reporting
<slangasek> tonyyarusso: I'm pretty sure that bug is already filed in Debian, it's at least been a known issue for some time
<tonyyarusso> cjwatson: yeah, reading that now.  I'm fond of pretty web interfaces though.
<tonyyarusso> slangasek: Really?  I'll look again then...didn't see it in the list.
<slangasek> hmm, you're right, no open bug on partman-crypto about it
<slangasek> so someone's tracking it in their heads instead of in the BTS, sigh
<cjwatson> slangasek: (I checked before saying anything ;-))
<cjwatson> unless it's actually on some other bit of partman or d-i
<tonyyarusso> There was a note about a separate page for partman-crypto-dm, I should look there.
<tonyyarusso> nvm, nothing there
<cjwatson> partman-crypto-dm is a binary from the partman-crypto source package; bugs.debian.org/src:partman-crypto would find it
<slangasek> cjwatson: well, it certainly belongs to partman-crypto AFAICS, so if it's on another package, also bad :)
<cjwatson> quite so, just sayin'
<grndslm> how can i dowload the source to the gnome weather applet??
<mjg59> grndslm: #ubuntu is a better place to ask this sort of question - this channel is for development of Ubuntu itself, not development using Ubuntu
<mjg59> Though check the manpage for the apt-get command and look for the source option
<grndslm> i reallize, but they can't tell me what package it would be in
<grndslm> ...or source
<mjg59> You can use dpkg to find out which package a file is in
<grndslm> it's not working
<jetole> hey guys
<manchicken> hiya
<jetole> hows it going manchicken ?
<manchicken> sleepy
<jetole> huh, I usually am but I got a good 9.5 hours last night
<jetole> I have a question about initramfstools, would this be the place to ask?
<jetole> alright, well I will ask and we will take it from there...
<jetole> I like having an encrypted root, I mean I really like it and I think it was a great feature to be added to gutsy gibbon but I prefer luks myself
<RAOF> Um.  It is luks.
<RAOF> I think, at least.
<jetole> huh, I just had to erase a lot, it is luks that we are using now?
<jetole> lemma turn to my laptop and take a look before I ask
<jetole> I had some issues setting up encryption with the installer on my 4 disk desktop too
<jetole> even if I only worked on one disk
<jetole> when it was done installing grub failed with a error 15
<jetole> huh, your right, it is luks
<jetole> well I am gonna ask my question anyways since I have an installed system to luks partition and this has always worked for me in previous installations
<RAOF> This channel isn't for support, so you may be better off asking somewhere else. :)
<jetole> typically I setup luks, then run the installer and have it install to the luks partition with /boot elsewhere, then after install before I reboot, I modify /etc/cryptab, fstab, and /boot/grub/menu.lst, run update-grub && update-initramfs -u
<jetole> well I figure my question is about to delve into something that this channel will contain the only people who know the details
<jetole> should I still head out?
 * jetole also thought it was a good place to ask programmer to programmer
<jetole> ok, well...
<RAOF> Maybe.  If it's a bug, then #ubuntu-bugs may be more appropriate.
<jetole> I am not sure if it is
<RAOF> You can ask, but it's quite possible no-one will answer
<jetole> alright, fair enough
<jetole> when I run update-initramfs my system doesn't seem to do the cryptroot thing
<jetole> now I saw all these components in the initramfs-tools dir
<jetole> but when I cpio'd my current initrd I didn't see it installed
<jetole> and I was wondering if I am supposed to enable this somewhere / somehow
<jetole> or if it is a bug
<jetole> EOF
<RAOF> Well, I dunno.  It may be a result of the work to fix the installer-setup cryptroot stuff.  Possibly.
<jetole> since I have my old / backed up to one of the disks and did a diff one the two initrd's new+old, I might just manually add the missing files to /etc/initramfs-tools/
<jetole> could be
<cjwatson_> make sure the cryptsetup package is installed
<jetole> I looked over initramfs.conf and mkinitramfs and didn't see anythign worth touching
<jetole> cjwatson: yes, that part was obvious
<cjwatson> since it ships the necessary initramfs hooks
<jetole> cjwatson: it does but they are in the /usr initramfs dir and not etc so I think I am going to add them manually
<cjwatson> they shouldn't be in /etc
<cjwatson> /usr/share/initramfs-tools is not copied to /etc/initramfs-tools or anything like that
<jetole> well the crypthooks etc are not installed in my current initrd
<cjwatson> no /sbin/cryptsetup?
<cjwatson> the stuff in .../hooks/ isn't meant to be installed in the initrd
<cjwatson> "hooks" in initramfs parlance are scripts that are run when building the initramfs that are responsible for copying bits in dynamically
<jetole> it is, but I ran a recursive diff on the one that worked on feisty and the one on gutsy and I am missing ...
<jetole> Only in ./old_init_dir/conf/conf.d: cryptroot
<cjwatson> I understand that there is a problem, but it would be nice to try to fix it properly rather than randomly copying stuff in, so that we can make it work for more people :)
<jetole> well I guess thats the only one
<jetole> understood, I was under the assumption myself that data that was used was copied
<jetole> my mistake
<cjwatson> perhaps you aren't using UUID device names?
<cjwatson> in /etc/fstab and /etc/initramfs-tools/conf.d/resume
<jetole> in /etc/crypttab and /etc/fstab I am....
<jetole> conf.d/resume?
 * jetole looks
<cjwatson> that may not be relevant
<cjwatson> I'm just tracing through the cryptroot hook and looking for places where it can bail out before creating conf.d/cryptroot
<jetole> I also changed root in grub/menu.lst to point to /dev/mapper/linux as before it had it in kopt but in kopt_2_6 it pointed to the uuid of dev/mapper/linux
<cjwatson> it may be easier for you to do that on your system with the aid of 'set -x'
<jetole> set -x does what?
 * jetole mans bash
<cjwatson> 'help set'
<cjwatson>         -x  Print commands and their arguments as they are executed.
<jetole> fair enough, I set this command and then I run what?
<cjwatson> no
<cjwatson> put it on the second line of /usr/share/initramfs-tools/hooks/cryptroot and then run update-initramfs -u again
<cjwatson> you should get a trace
<jetole> ok
<jetole> waiting for vim to load, I am in the encrypted root on the live cd
<jetole> cjwatson: you want me to look for something in perticular here? is this something you want pastebin'd?
<`23meg> jcastro, https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/134361/comments/6 is probably of interest to you
<ubotu> Launchpad bug 134361 in transmission "Could you update Transmission please?" [Wishlist,Confirmed]
<cr3> is there a kernel parameter which can prevent graphics mode from kicking in? ideally, this would provide a full login rather than a recovery mode login.
<jcastro> `23meg: thanks for the tip
<cjwatson> jetole: I don't know exactly what I'm looking for, so pastebin is good
<cjwatson> jetole: (btw, while I know the initramfs system reasonably well, I'm far from an expert on the cryptsetup stuff, so it is possible that I am not the guru you need; also, I'm going to bed soon ...)
<`23meg> jcastro, you're welcome; would you like me to pass similar info requests on to you when I come across them?
<jetole> ok, will do now, so far I see it loading appropriate modules i.e.: dm-crypt, dm-mod, aes, sha256... anyways, will post now and continue reading after I post
<jcastro> `23meg: absolutely, feel free to leave me pm's or mail me directly
<`23meg> jcastro, will do
<jetole> cjwatson: http://pastebin.com/m357ba14f
<jetole> I will brb, laundry should be done
<Burgundavia> jcastro: we should probably look at transmission as our default bittorrent client
<jcastro> Burgundavia: is this like a spec or are you just thinking outloud?
<Burgundavia> the latter
<Burgundavia> feel free to make it a spec, although it probably should merely be added to the discussion of reducing duplication
<cjwatson>         # If keyscript is set, the "key" is just an argument to the script
<cjwatson>         if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
<cjwatson>                 echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
<cjwatson>                 return 1
<cjwatson>         fi
<Burgundavia> cjwatson: are you leading the discussion on the reducing-duplication topic in Boston?
<cjwatson> jetole: you're tripping that check. Figuring out why that explicitly prevents the node being added to conf.d/cryptroot is off the limits of my knowledge
<cjwatson> Burgundavia: it's part of my track
<cjwatson> Burgundavia: so I guess I will be coordinating it; but, if history is anything to go by, that session will have a fair sprinkling of doing as well as discussion
<Burgundavia> cjwatson: right, poor you. Is there a spec, should I start one and get some stuff on the wiki page?
<cjwatson> Burgundavia: no, it doesn't need a spec
 * lamont wonders how to make half-tone characters actually be readable on his LG LCD display
<cjwatson> Burgundavia: unless there are particular things of interest that can't just be done straight away
<jetole> scared myself for a second, have a linux shirt I only wore once and after putting laundry away it was awol but it was on the couch in the living room
<cjwatson> Burgundavia: I expect those will come up on the day
<jetole> cjwatson: well thanks for your help anyways
<cjwatson> jetole: hope it gets you a little further, at least
<jetole> I will continue to look, if I have to add it myself I will but I want to find a legitimate solution
<jetole> cjwatson: it definitly does
<jetole> I am going to read the rest now
<cjwatson> Burgundavia: though if you have something to add, feel free to create a spec and dump it into the status whiteboard for now; I don't think it'll need a wiki page yet
<jetole> oh shit, I think I just found the problem cjwatson
<jetole> and it was my problem
<jetole> lemme try this and if it works I will let you know
<Burgundavia> cjwatson: ok, that works
<jetole> cjwatson: yeah I found it
<jetole> fstab had the uid and crypttab had the name linux, the uuid pointed to /dev/mapper/linux but because the names were different update-initramfs never saw it
<jetole> now the new initrd has a cryptroot
<jetole> in both conf.d and scripts/local-top
 * jetole is gonna reboot into what should be a working gutsy gibbon
<jetole> oh and cjwatson you saved my ass with set -x
<cjwatson> oh, fantastic, I never knew that - "wildcard" is translated into German as "Jokersymbol" or "Jokerzeichen"
<cjwatson> it makes sense, but just sounds cool :)
<jetole> well it worked, I am in gutsy
<jetole> and wow if wmv support ever good on here
<jetole> I never looked into the details but it looked good on mplayer in feisty and constantly choppy in totem/vlc
<jetole> ok, I am not sure if you would be the guys to ask, but just let me know if not, would dpkg --get-selections on feisty work for gutsy?
<Chipzz> jetole: in what sense?
<jetole> dpkg --get-selections allows you to backup your list of installed packages and dpkg --set-selections allows you to set them for installing
<jetole> ... it doesn't used version numbers at all
<Chipzz> yes I know that :)
<jetole> so I am wondering if I can install my package list from feisty
<Chipzz> that's the whole point, right?
<jetole> you know, without fubar'ing my system
<Chipzz> normally you can
<jetole> ok
<jetole> lol
<jetole> so hopefully it wont screw me over?
<Chipzz> but I don't think it's the recommended way of doing thing
<Chipzz> s
<Chipzz> well
<jetole> well suppose I have my whole feisty installation backed up into a chrootable dir, what would be the recommended way?
<Chipzz> hrrrm one sec
<jetole> I need to order myself some dinner
<Chipzz> k back
<jetole> I have been playing with gutsy too much tonight
<jetole> sure
<Chipzz> the recommended way of upgrading is update-manager
<Chipzz> it makes sure you have certain packages needed for your system to work installed
<Chipzz> but
<jetole> well I had some issues with that because I always use a custom encryption method
<Chipzz> since you even know about dpkg --get-selections at all, I suppose you, to some degree, know what you're doing :)
<Chipzz> now I'll say this
<jetole> I do, like I said though, I am just not sure if it's safe
<Chipzz> this laptop was originally installed with errr
<Chipzz> dapper or the release before that
<Chipzz> I apt-get upgraded my way through edgy en feisty
<Chipzz> and it didn't break :)
<Chipzz> there are a few commands that can help you out when the upgrade breaks though
<Chipzz> you know about "apt-get -f install" and "dpkg --configure -a" ?
<jetole> yeah...
<jetole> typically I have found it easier to do a whole install but i
<jetole> didn't back up last time
<Chipzz> now for what it's worth
<Chipzz> doing a clean install has its advantages too
<jetole> well the clean install was done
<Chipzz> removes old cruft from your system, and makes sure you got the packages with the new features for feisty installed
<jetole> and I have feisty in a directory now
<bluefoxicy> Guys here's an idea
<bluefoxicy> apport should figure out how to fix broken crap
<bluefoxicy> Whenever thunderbird crashes I REMOVE compatibility.ini FROM THE PROFILE DIRECTORY.
 * jetole looks at apport
<Chipzz> bluefoxicy: I hardly think apport is relevant here ;)
<bluefoxicy> It just crashed 10 times in a row when I tried to open a message (even tried to delete the message), I removed the file, it works.  I do this all the time D:
<bluefoxicy> Chipzz: pitti wrote it!  :D
<Chipzz> jetole: apport is a program that hanles program crashes and makes it easy to submit a bug report including backtrace
<jetole> never heard of it
<jetole> but I will statr using it
<Chipzz> it can automatically install -dbg packages to give you a meaningfull backtrace iirc
<bluefoxicy> but, there's just ... recurring issues that have quick fixes <.<  Need something to easy fix things.  I just re-initialized my whole home directory (vacuumed over a lot of stuff, left out a lot of configuration, let .gconf reset) to get desktop effects to not crash my machine because I don't know what's busted x_x
<jetole> well I guess for now I am going to use dpk --set-selections
<jetole> and hope it works
<bluefoxicy> but anyway
 * bluefoxicy wanders away
<bluefoxicy> (welcome to my 5 minutes of ADD)
<Chipzz> jetole: btw, if I may give you one hint
<jetole> fresh install so if it crashes, well I still have my backups
<jetole> yeah?
<Chipzz> it's always a good idea to upgrade apt and dpkg to the latest versions before upgrading
<Chipzz> first, before doing the rest of the upgrade, that is
<jetole> I know but it did have some issues with my encryption but I had a backup of the whole system
<Chipzz> and there is one minor issue with the dpkg --set-selections thing
<jetole> whats that?
<Chipzz> don't know if you care about that though
<Chipzz> you'll loose the information of which packages were automatically installed as dependencies in your old system
<jetole> hmmm
<Chipzz> but that's a minor issue I think
<Chipzz> not really sure if there's a way to backup that information (I think there is though)
<jetole> well I know that has always worked on the same distro if you need to do a reinstall
<jetole> but I have never tried it after an upgrade
<Chipzz> well since your importing the whole list of packages installed on your old system, you'll also be explicitely installing the dependencies, so they won't be marked for automatic removal
<jetole> ah, I see what your saying
<Chipzz> (I think)
<jetole> ah well, I will just reinstall what I need
<jetole> no, your right
<Chipzz> btw, I recommend apt-get dselect-upgrade after dpkg --set-selections
<jetole> I have typically just used dselect but I think it's the same thing
<joeamined> hi folks
<joeamined> i'm a student in computer engineering, i'd like to contribute in ubuntu
<jdong> joeamined: #ubuntu-motu
<joeamined> jdong, anf ubuntu-dev is for what exactly ?
<jdong> joeamined: for developers to coordinate activity directly related to development of Ubuntu
<jetole> lol
<joeamined> ah okay
<jdong> joeamined: not for discussions like this -- developers read scrollback of this channel and are irritated by random noise :)
<joeamined> okay
<jetole> yeah... sorry but I had a legitimate question when I came in that #ubuntu would have not known s!@# about, my last question though probably wasn't for this room
<jetole> despite the official purpose of the channel though, you have to admit, some questions do belong to where they are proposed to the people who actually write the code
<pwnguin> sad :( liferea wasn't able to handle google tech talks as a label
<pwnguin> and now the label's gone
<pwnguin> bug fixed, i guess
 * Hobbsee wonders when the next open office upload will be done
<pwnguin> 30 meg downloads to remove a file? sounds great!
<Hobbsee> exactly.
<DaSkreech> Whole Os upgrades to get some securoty? great!
<Hobbsee> oh, awesome!
<Hobbsee> it looks like update manager actually obeys dpkg pinning now!
<CarlFK> where is the place to log suggestions?  (in addition to "import key from file" add "dl key from url")
<CarlFK> (... in synaptic)
<mpt> CarlFK, what kind of suggestions?
<mpt> Do you mean a way to make Synaptic easier to use?
<dholbach> good morning
<lifeless> es
<Hobbsee> de?
<StevenK> fi?
<ion_> en_FI
<liw> wha'?
<ion_> Ever heard a Finnish athlete or a formula driver being interviewed in English? Thatâs en_FI.
<Mithrandir> what's kinda amusing is en_DK actually exists as a language code.
<Hobbsee> morning pitti!
<pitti> Good morning
<StevenK> Morning pitti
<ion_> Hi
<tepsipakki> is there an easy way to copy the SpecTemplate, or should I just copy the code?
<pitti> tepsipakki: usually you create a new page and select it as the template in the list to the left
<tepsipakki> pitti: ah, that simple. thanks :)
<sladen> ion_: en_FI: a very slimmed down language consisting that has a limit of maximum sentence length?
<ion_> sladen: And mohr importtantly, a suhrttan acksent.
<tepsipakki> doko: would you consider updating sun-java6 in feisty? The current version has problems with eclipse
<tepsipakki> JVM crashes sometimes
<gnomefreak> tepsipakki: yeah thats beena long time bug, i had posted a debdiff for it but the domain i was using (given by a member of community) was closed its too big for LP to handle
<gnomefreak> atleast the update 2 fixed it iirc and update 1 is in feisty
<gnomefreak> tepsipakki: https://bugs.edge.launchpad.net/ubuntu/+source/sun-java6/+bug/122442  this maybe your crash or not
<ubotu> Launchpad bug 122442 in sun-java6 "Memleak in Sun Java 6 on ubuntu feisty" [Wishlist,In progress]
<tepsipakki> gnomefreak: update 1 is not in feisty..
<tepsipakki> build 1.6.0-b105
<gnomefreak> tepsipakki: i know that is the one i had debdiff for so we could move to update 1
<gnomefreak> i had updates confused its been a while since i did that
<tepsipakki> why bother, straight to the latest one ;)
<gnomefreak> agreed at the time update 1 was latest it wasnt even in gutsy at the time of that bug
<tepsipakki> update 3 is in gutsy
<tepsipakki> # Problematic frame:
<tepsipakki> # C [libc.so.6+0x6d688] strcmp+0x8
<tepsipakki> that's from the current version. I'll ask the reporter to test update 3
<tepsipakki> (a local student)
<soren> If a postinst has an upgrade quirk (if dpkg --compare-versions "$2" le blah; then foo; fi) that checks for version that is pre-dapper, it should be ok to drop it, right?
<tepsipakki> soren: AIUI yes
<soren> Goody.
<tepsipakki> since pre-dapper releases aren't supported anymore, and neither is upgrading breezy -> hardy :)
<pitti> mjg59: do we actually need this hal SSB bus support patch for anything? there are no bug numbers referenced in your changelog, and upstream didn't apply it yet because they are waiting for an update to the spec (http://lists.freedesktop.org/archives/hal/2007-April/008078.html)
<pitti> mjg59: same with the memstick patch: no upstream bug, no LP bug in th changelog, nothing on hal@l.f.o, nor in git head
<pitti> mjg59: what is the use case for this? can you please forward it upstream with some explanations?
<sladen> pitti: Sonics Silicon Backplace, I suspect it'll be some on-chip wifi/similar cores that are directly connected without even CI
<sladen> PCI
<sladen> ..be for some...
<soren> StevenK: I'm doing the devscripts merge, by the way..
<StevenK> soren: Fair enough
<soren> ...unless of course, you've mostly already done it?
<sjoerd> pitti, sladen: ssb is used in some linux based access points that can run *wrt.. Iirc on those based on broadcom chipset
<pitti> sjoerd: and it is actually useful in hal?
<pitti> anyway, I ported over the patches, but eventually those should go upstream
<sjoerd> Unless ubuntu runs on some embedded devices with a similar chipset, no not really :)
<iwj> Yay.  `(i) The bug contacts for apt (Ubuntu) have been subscribed to this bug.   Page not found.  Theres no page with this address in Launchpad [etc]'
<pitti> mjg59: btw, if you have a hal ubuntu branch checkout, please re-do it; I recreated the ubuntu bzr branch from scratch as a proper fork from the Debian svn (through bzr-svn, pushed to LP as 'debian')
<pitti> asac: yay for xulrunner!
<asac> pitti: thanks for confirming this ;)
<ScottK> pitti: Have you gotten a chance to review jdong's email on azureus yet?
<pitti> ScottK: not yet, sorry, will do ASAP
<ScottK> pitti: No trouble.  I look forward to seeing your reply.
<mjg59> pitti: Yeah, I'll sort those out
<pitti> mjg59: thank you
<CarlFK> mpt:  "a way to make Synaptic easier to use?"  yes  I added it to: https://wiki.ubuntu.com/IdeaPool
<pitti> $ submittodebian
<pitti> ImportError: No module named debian_bundle.changelog
<pitti> dholbach: ^ what's the trick to make it work here? looks like a missing dependency
<dholbach> oh
<dholbach> python-debian, I guess
<pitti> ah, python-debian
<dholbach> pitti: soren wrote it
<soren> ?
<soren> Oh.
<soren> Install python-debian.
<pitti> that should be a dependency then
<soren> pitti: ^^
<soren> Sure, I'll add it right away.
<pitti> yep, that worked, thank you!
<soren> np :)
<pitti> soren: if you are at it, how do you feel about incorporating https://wiki.ubuntu.com/Bugs/Debian/Usertagging into submittodebian?
<soren> pitti: It's already there, actually.
<soren> pitti: reportbug needs a patch to support it.
<pitti> soren: hm, not in the current version at least; maybe in unapproved?
<soren> pitti: ...so it's disabled.
<pitti> ah, I see
<Hobbsee> soren: feel free to merge it, and add that too
<soren> I'll upload it when Hardy opens.
<Hobbsee> cool.  then you can be bitten by the TIL principle :)
<soren> Tell me about it.
<soren> I'm just happy I haven't touched something like dpkg.. Eeek!
<soren> I took a quick peek at the merge.. I haven't slept since!
<soren> (ok, it was this morning, so it's not that strange, but still!)
<Hobbsee> soren: i've uploaded that before.  it was very scary.
<Hobbsee> soren: apt and mesa are also fun packages to upload.
<soren> I can only imagine.
<Hobbsee> actually, apt's just a horror package.
<soren> Personally, I would just have bribed mvo to do it.
<pitti> soren: hm, submittodebian did not tell mutt to attach the patch; I had to fish it out of /tmp, copy it to a sane file name, and attach it manually
<Hobbsee> soren: that may have been teh smarter move.  but it tends to be quicker to Just Do It, rather than by the Nag Mvo Every Day method.
<soren> pitti: /me blames reportbug :)
 * Hobbsee blames soren, for not merging/dealing with it earlier.
<soren> pitti: Could you file a bug about it? I'm a bit tied up right now and is likely to forget all about it.
<pitti> soren: yes, can do
<Mithrandir> soren: but dpkg is lovely.
 * soren hugs pitti 
<Mithrandir> soren: a bit of rough love, admittedly.
<soren> Mithrandir: <g>
<pitti> dendrobates: dtghadgtnadgtnad? were you born in Wales or so? :)
<dendrobates> pitti: Is that hard to pronounce in German?
<tepsipakki> Hobbsee: mesa is no horror anymore, since it began using a patch system (quilt, but anyway) :)
<Hobbsee> tepsipakki: haha.
<pitti> dendrobates: I got as far as "dtg" when my throat deformed to a knot
 * ogra_cmpc trise to get the knots out of his tongue
<Hobbsee> tepsipakki: it's still got all the libs differing by one letter.
<soren> Ooh!
<dendrobates> pitti: that was me angrily banging the keyboard because
 * pitti flushes the hardy queue
<soren> Whee!
<dendrobates> pitti: I had to recover my nick yet again.
 * Hobbsee has an alias for nick recovery.
* pitti changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
 * Hobbsee UPLOADS LOTS OF CRACK!
<tepsipakki> omg
 * pitti flushes the first round of pending autosyncs, too
<Kmos> oh yes :)
<Kmos> pitti: danke
<Hobbsee> pitti: lets sync debian-installer.  i think that would be fun.  and adept.
<Hobbsee> pitti: can we sync the entire debian kernel, too?
 * ogra_cmpc humps asac's leg
<ogra_cmpc> xulrunner !!!!
 * Hobbsee covers eyes
<ogra_cmpc> my first seed change in hardy will be dropping FF, yay
 * ScottK takes video
<ogra_cmpc> *g*
 * Hobbsee wonders hwat happened if someone requested a sync of the kernel.
<asac> ogra_cmpc: hehe :)
<Hobbsee> er, what would happen.
<Mithrandir> Hobbsee: they'd get told off?
<Hobbsee> Mithrandir: hmm.  might be fun to try.
<ScottK> Hobbsee: Save it for near a milestone when the archive admins are really tired.
<Hobbsee> ScottK:
<Hobbsee> ScottK: i'm listed as one of them myself.  i'm unsur ehow well tha twould go :P
<ScottK> Ah.  Right.  Forgot about that.
<Mithrandir> ScottK: then we might not just tell somebody off, but actually yell. :-)
 * Hobbsee ponders if that would be amusing or scary.
 * ScottK thinks it'd be amusing to watch it happen to someone else ;-)
 * Hobbsee has already set off a whole bunch of work alarms tonight, so is somewhat game :P
<Hobbsee> but seeing as they have a 30 min response time, it's easy to get away :)
<tepsipakki> I'll hold the new xorg-server 1.4 until broken keymaps with input-hotplug are resolved (bug in evdev)
<tepsipakki> the new hal includes the .fdi file for it
 * ogra_cmpc grumbles ... why the heck isnt pidgin capable of running fullscreen
<tepsipakki> does anyone know if the rooms at hotel@mit have power outlets for european devices?
<Mithrandir> probably not.
<elmo> they don't
<tepsipakki> figures
 * TheMuso is just taking an adapter anyway, as it will be needed at some point.
<StevenK> All of the devices I'm bringing at this point will work for 110V, which is nice.
<TheMuso> StevenK: Likewise.
<ogra_cmpc> most modern powerbricks have autosensing though
<jdong> ogra_cmpc: yeah, just need adaptor for the shape of the plug...
<ScottK> And even if you get it wrong, 220v device in 110v outlet just doesn't work.  The reverse is often more spectacular.
<Mithrandir> heck, even modern computer PSUs seems to be autosensing.
<tepsipakki> I'm trying to find a suitable wire for the lenovo laptop charger
<tepsipakki> should be somewhere..
<jdong> Mithrandir: not autosensing per se... most I've seen still use the 110-240 switch deal
<jdong> Mithrandir: the cheap ones I've sacrificed to experimentation do fatally brown out on the wrong setting
<Keybuk> I need to file a critical bug against myselkf
<StevenK> Keybuk: Oh?
<Keybuk> I took the battery out of my laptop, so I could put the larger travel battery in
<Keybuk> since I'll want that for the Boston flight
<Keybuk> checked charge before I did, and thought "hmm, could do with emptying it first, so it gets a full charge cycle"
<Keybuk> so I pulled the power cable out, and then put the battery n
<Keybuk> ...
<StevenK> Haha
<jdong> Keybuk: haha, nice :)
 * jdong still sad launchpad.net/jdong was declined because I am not an open source project
<mc44> jdong: gpl your dna ;)
<Keybuk> jdong: as iwj has said in the past, we need to be able to file bugs on people
<Keybuk> mc44: his DNA is almost certainly patented
<jdong> mc44: I wish I could, but isn't providing your DNA to minors illegal in most places? ;-)
<jdong> Keybuk: I tried registering myself as a product :D
<mc44> Keybuk: yeah, I wonder if the prior art argument works there ;)
<manchicken> mvo: About time m8 :)
<manchicken> mvo: You got a second to answer a question that I've probably over-simplified and haven't been able to answer on my own?
<mvo> manchicken: sure
<manchicken> mvo: If I have a package entity in libapt, how do I determine the package's priority?
<manchicken> I'm trying to put in a warning to help prevent removal of important packages.
<manchicken> Or at least warn folks when they're trying to purge libc :)
<mvo> manchicken: I would check for the flags: pkgCache::Flag::Important and pkgCache::Flag::Essential, give me a sec, I dig out a code example
<manchicken> Much thanks.
<mvo> manchicken: something like: http://paste.ubuntu.com/1238/ should work (if you have a pkgCache::pkgIterator for the package, but I assume you have
<manchicken> Well I'm trying to remember where this is...
<manchicken> If I weren't in the office today this would be much easier.
<manchicken> BTW, those who remember me complaining about python-mode in emacs22, (re bug #155681) dpkg --purge python-mode fixes it and makes the world a happier place.
<ubotu> Launchpad bug 155681 in python-mode "emacs22 and python-mode do not play together" [Undecided,Incomplete] https://launchpad.net/bugs/155681
<ogra> apt-get install vim ?
 * ogra runs and hides
<manchicken> ogra: No, that just makes the world a sadder place.
<ogra> thats a very subjective view :)
<Kmos> I agree with ogra :)
<Hobbsee> ogra: lets just purge emacs from the repos.
<Amaranth> gedit ftw
<minghua> Does anyone else get a mail to -devel-discuss list dated March?
<ogra> Amaranth: wow, do you know anyone really using it in actual development ?
<Amaranth> <--
<gaspa> soren: I see... :(
<soren> gaspa: Huh?
<gaspa> qemu
<gaspa> thanks, anyway.
<soren> Oh.
<soren> Yes, sorry about that.
<soren> There's still plenty of merges to do, if you want to help out!
<gaspa> np, the next time, i'll worry ask before make anything ;)
<gaspa> sure.
<gaspa> soren:  but is  http://dad.dunnewind.net/universe.php updated? it doesn't seem so
<ScottK> It's generally updated hourly.
<soren> gaspa: I think it only runs once a day.
<soren> Oh, really?
<ScottK> MoM is less frequent.
<soren> Well, the qemu upload didn't hit the archive until just about an hour ago.
<gaspa> qemu is still open
<gaspa> ah,ok.
<Adri2000> DaD universe is updated at :30 each our (and main at :00)
<Adri2000> (btw last update's time is written at the bottom of the page)
<Solarion> http://nicubunu.blogspot.com/2007/10/distro-deathmatch-werewolf-versus.html
<Solarion> Vote for the gibbon!
 * tonyyarusso can't...is actually feeling pretty disappointed :(
<tonyyarusso> Is BenC awake by any chance?  I was wondering if you could explain the issues causing the bugs relating to no virtual terminals when using vga= options other than normal in Gutsy.  ('tis quite annoying, so hoping there's a really good explanation)
<Hobbsee> mvo: can you tell me how to fix https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-restricted-extras/+bug/152358 ?
<ubotu> Launchpad bug 152358 in ubuntu-restricted-extras "Xubuntu Restricted Extras has no entry in Add/Remove..." [Undecided,New]
<Hobbsee> it's a desktop thingy, which i think was your domain?
<mvo> Hobbsee: sounds like a desktop file missing. I can check the repo
<Hobbsee> mvo: thanks.
<Keybuk> and *that* time was GNOME Power Manager being somewhat optimistic about the battery charge
<mjg59> If it's the first time you've put the battery in for a while, it'll be entirely uncalibrated
<Keybuk> I suspect it's the first time it's ever put this battery in
<Keybuk> though shouldn't it at least use the battery's own guess in that regard?
<mjg59> I believe that it does, in the absence of any other information
<mjg59> If the battery has been sitting on a shelf for a while, the battery will have no idea either
<mjg59> A lot of the battery figure comes from monitoring how much energy has gone in and how much has come out. If it's been slowly self-discharging, that's going to be wrong
<Keybuk> ah, true
<Keybuk> it's the travel battery, so it's been on the shelf since ... Seville :p
<Chipzz> ogra: I think there are some other things wrong with pidgins GUI too ;P for example, why the view log dialog has to be modal :S
<ogra> Chipzz: well, usually i dont use pidgin but i'm to lazy to install xchat here
<agoliveira> Keybuk: IIRC, right after I bought my asus notebook I had to run a calibration routine on the bios to have an acurate report from the batery.
<Riddell> mvo: is there a UDS sessions for LTS upgrade?
<seb128_> Riddell: does that need discussion? "make it work" ;-)
<Riddell> seb128_: there's always some amount of how to make it work
<pitti> well, as long as we keep all the transitional code in maintainer scripts until after 8.04 release, it shouldn't get too bad; then u-m mainly needs to sort out things like which packages to additionally install/remove
<pitti> ISTR seeing changelogs which dropped transitional code, but I don't remember which any more
<mvo> Riddell: not that I know of, might be good to have one, also there is a spec from last uds
<Riddell> mvo: should I register it?
<Riddell> we'll need to look at porting the Kubuntu upgrade tool to dapper
<mvo> Riddell: yes, I think that is sensible then
<mvo> Riddell: to register a session about it I mean
<Riddell> mvo: I've proposed lts-upgrades for UDS Boston
<DktrKranz> has ubuntu autosync already turned on?
<cjwatson> DktrKranz: started today; not quite finished the first pass yet though
<DktrKranz> cjwatson: thanks.
<DktrKranz> cjwatson: do you know when it will be fully functional?
<cjwatson> no
<DktrKranz> ok, thanks anyway
<cjwatson> it is in progress, that's all I'm prepared to say :)
<bryce> this looks odd - http://merges.ubuntu.com/main-trend.png
<calc> bryce: what is odd about it?
<calc> the lines on the left should be on top of the color right?
<calc> or something else?
<calc> hmm actually thats not quite right the color should extend to the left
<calc> and there are no new lines for gutsy
<geser> pitti: Hi, can an accepted upload to gutsy-proposed be removed from it?
<pitti> geser: only until the publisher runs
<pitti> cjwatson: do you have some time to look into dapper's d-i linux installation for lbm? do you want a bug report for it?
<cjwatson> pitti: do we have current images I can grab and hack on, that have l-b-m seeded?
<pitti> cjwatson: ah, no; if you need that, we'll need to wait until tomorrow
<pitti> cjwatson: kernel was FTBFS, new one is almost built (and then lbm and lrm can build over night)
<cjwatson> pitti: it would help
<cjwatson> this is a little bit weird and I'd rather not try to get it right first time without something to test on
<pitti> cjwatson: ok; CDs should be there tomorrow morning
<cjwatson> thanks
<pitti> cjwatson: I just hoped to get test CDs done by Boston
<cjwatson> we want to install l-b-m unconditionally?
<cjwatson> (on new installs but not upgrades)
<pitti> cjwatson: if that isn't much work, do you reckon the d-i changes could be done tomorrow?
<cjwatson> yeah
<pitti> cjwatson: yes, that was the idea AFAIK
<pitti> BenC: ^
<cjwatson> pitti: probably something like http://paste.ubuntu.com/1250/
<highvoltage> LaserJock_: that you?
<pitti> cjwatson: s/\(linux\|linux-image\) looks funny; I didn't know that this DTRT
<cjwatson> pitti: should do, what do you think is wrong with it?
<cjwatson> sed takes basic regexes unless given -r
<pitti> it looks a bit indeterminate
<pitti> like, linux-image-generic could go to linux-backports-modules-generic or linux-backports-modules-generic-image
<cjwatson> $ echo linux-generic | /usr/lib/initramfs-tools/bin/busybox sed 's/\(linux\|linux-image\)/linux-backports-modules/'
<pitti> if sed always prefers to replacte the longest possible match, it's fine of course
<cjwatson> linux-backports-modules-generic
<cjwatson> $ echo linux-image-generic | /usr/lib/initramfs-tools/bin/busybox sed 's/\(linux\|linux-image\)/linux-backports-modules/'
<cjwatson> linux-backports-modules-generic
<cjwatson> sed should always take the longest match yes
<pitti> cjwatson: yeah, I didn't doubt that you tested it, just mentioning that it looks a bit funny :)
<cjwatson> that is generally true of regexes
<cjwatson> I hadn't actually tested it before you asked ;-)
<J-Unit> 24520 jdong     35  19 1707m 653m  724 D    2 64.8  46:31.76 trackerd
<cjwatson> "If the RE could match more than one substring starting at that point, it matches the longest." regex(7)
<J-Unit> Dear Jesus and Santa: Tracker should not use 2GB RAM
<J-Unit> Thanks,
<J-Unit> P.S. Sorry about those jokes last week. I didn't mean it seriously. I hope I still get gifts for christmas.
<lamont> if I do dapper->gutsy, I assume that we should be filing bugs (against what?) so that they get fixed for the dapper->hardy update-manager thang, yes?
 * lamont pokes cjwatson 
<cjwatson> lamont: dunno why you're poking me ... but 'update-manager' typically unless it's clearly a package bug
<mvo> lamont: what cjwatson said, what packages/problems have you seen when you tried the upgrade?
<lamont> mvo: it mostly came in the form of file also exists in bar type errors, and the fact that evms needs to be eliminated if one wants to live.
<lamont> I just have another machine to upgrade, so I figured I'd actually be pedantic about it.
<mvo> lamont: ok. i expect that missing conflicts/replaces will be a large chunk of the problems
<lamont> mvo: and those are package bugs.  nice for you. :)
<BenC> pitti, cjwatson: Yeah, lbm on livecd, and d-i should be default
<pitti> BenC: thanks (we won't rebuild live CDs, BTW)
<BenC> ah, right, server only
<sistpoty> hi folks
<LaserJock> sistpoty!
<sistpoty> hey LaserJock
 * slangasek waves
<sistpoty> hi slangasek
<sistpoty> is there any reason why nvidia-settings is in restricted instead of main? (looking at bug #59945)
<ubotu> Launchpad bug 59945 in sensors-applet "no nvidia support" [Undecided,Confirmed] https://launchpad.net/bugs/59945
<sistpoty> actually debian/copyright only says gpl-2, and I didn't spot any deps/build-deps from nvidia-settings outside of main (but have looked only 5 secs at these though)
<cjwatson> nvidia-settings> because it came from Debian contrib
<cjwatson> and doesn't it only drive the closed nvidia driver?
<Pierre> yes
<slangasek> sistpoty: at a guess, I'd say it requires nvidia-glx-legacy to be useful but only Recommends it because it's a virtual package provided by the per-kernel bits which may not be packaged or may only become available later
<Pierre> and hello (first :)
<slangasek> correction, nvidia-glx-legacy is a real package that depends on the kernel bits
<cjwatson> or because generally userspace stuff tries to avoid expressing dependencies on kernelspace things by means of package dependencies, because it causes problems / doesn't work right if you have multiple kernels installed
<cjwatson> I hope gouki enjoys the EISDIR from his quit message
<sistpoty> ok... what do you think then would be the right fix for the aforementioned bug? duplicate the source to multiverse (which imho is ugly)?
<cjwatson> I think I'm OK with a source in universe building a binary in multiverse as long as it has no non-free components itself (i.e. it's only Debian contrib-style)
<cjwatson> but the source could always be moved to multiverse and build a binary in universe if somebody has a problem with that
<sistpoty> cjwatson: but it would have to b-d on s.th. from restricted, wouldn't it?
<sistpoty> cjwatson: ah, if that's possible, cool :)
<cjwatson> the source package would probably have to go in multiverse then
<cjwatson> but that's OK, it can still produce a universe binary
<cjwatson> our closure rules aren't quite the same as Debian's
<cjwatson> though, hmm, that does feel kind of icky
<cjwatson> I think universe actually technically can build with restricted
<sistpoty> even better, that would mean less stress then :)
<cjwatson> "Secondly, enabling NVIDIA support would be an Ubuntu-specific change to the package, so the Ubuntu packager would have to make it." sigh why do people say that in Ubuntu bugs? you file an Ubuntu bug because you want Ubuntu to make a change
<Pierre> btw, they are completely broken on amd64 with serie 8x
<sistpoty> ok, I'll start out with a patch for nvidia-settings then (as the header isn't shipped atm.) thanks for your help!
<Pierre> == crash
<cjwatson> do please make sure that the restricted build-dep doesn't influence the binary in universe in any way, though
<cjwatson> and it might be a problem later if the package is ever to migrate to main
<sistpoty> what do you mean with influence? if I get it correctly, nvidia-settings only ships a static library, so it would definitely have an effect on sensors-applet
<cjwatson> err, the actual binary in universe? I thought you were talking about creating a separate binary
<cjwatson> linking a library from restricted into an executable in universe is not acceptable
<sistpoty> ah, ok, got it... so I create two binaries where one goes into multiverse, right?
<cjwatson> building a source package in universe and having it produce a binary package in universe (which only uses stuff from main and universe) and a binary package in multiverse (which is not limited in that way) is OK, provided that the binary is only in multiverse due to dependencies and not because it is itself non-free
<cjwatson> if the source package only produces one binary and that requires non-free things and so is in multiverse, then the entire source package should be in multiverse
<cjwatson> your choice
<sistpoty> that would be the easiest thing, not too sure if that's desirable though
<bryce> are backports of lrm feasible?  (bug 156325)
<ubotu> Launchpad bug 156325 in fglrx-driver "New fglrx 8.42.3 to Gutsy" [Undecided,New] https://launchpad.net/bugs/156325
<bdmurray> Riddell: bug 153889 requires verfication for Feisty and Gutsy correct?
<ubotu> Launchpad bug 153889 in adept "feisty dist upgrade check does not work" [High,In progress] https://launchpad.net/bugs/153889
<Nafallo> mbiebl: I SO agree with your last post on upstart-devel :-). KISS FTW.
<Riddell> bdmurray: yes, in feisty it didn't show when it should have and in gutsy it showed when it shouldn't have
<bdmurray> Riddell: okay, I was unable to verify the fix for gutsy
<Riddell> bdmurray: it still showed?
<bdmurray> Riddell: Yes, after launching Adept in the system menu and then clicking Fetch Updates
<bdmurray> I put it all in the bug
<Riddell> bdmurray: that's with 17.1?
<Riddell> running kdesu adept_manager?
<bdmurray> I ran it from System -> Adept Manager which then prompted for my password
<bdmurray> I could try it via kdesu adept_manager if that would make a difference
<Riddell> shouldn't do
<Riddell> but give it a shot anyway :)
<Riddell> and obviously make sure it's adept-manager and adept-common ubuntu17.1
<Riddell> it definately solves the problem for me
<bdmurray> okay, I think I see my problem then
<bdmurray> just installing adept from proposed is not enough?
<bdmurray> If so that isn't obvious from the bug report or verfication steps
<Riddell> "adept" is just a meta package
<Riddell> maybe we should add versioned depends to it
<Keybuk> *sigh*
<Keybuk> evolution takes so long to build
<ion_> Thereâs a cure for that. Do all builds under valgrind for a month. After that, everything seems to build quickly.
#ubuntu-devel 2007-10-24
<BigPick> Afternoon all.
<fujin> Heh, It's becoming impossible to find an answer in #ubuntu, and it's kinda development related - anyone able to tell me what I need to do to add a package to my local repository? I've created a full feisty mirror with apt-mirror, and now wanna setup another mirror for my handrolled packages
<BigPick> Got me there. I've never done a repo.
<fujin> Blast.
<fujin> We've done one here to save traffic, 50~ or so Ubu boxes.
<fujin> and I figured I'd be able to hand-roll packages and toss them in, but that didn't work
<fujin> so there must be some kind of package signing/cache indexing or something
<slangasek> apt-ftparchive
<slangasek> I don't think that does signing, so if you want a gpg-signed repo that's an additional step
<fujin> ah, I don't think I've got a signed repo
<fujin> unless apt-mirror automagically generated a key
<slangasek> apt-mirror should copy the signature from the original mirror
<fujin> oh. blast.
<fujin> I assume what I'm trying to do will involve creating an entirely new mirror, to provide overrides to the packages in my apt-mirror
<slangasek> that would probably be best
<fujin> Indeed.
<fujin> Are you aware of any documentation explaining how to do such a thing?
<slangasek> other than apt-ftparchive, not really?  pretty off-topic for this channel by this point, though
<fujin> Arg.
<fujin> well, thanks. Sorry for breaking the topic
<fujin> Ah, Think I found something concering apt-ftparchive and moreso how to use it. Thanks slangasek :)
<Chipzz> fujin: btw, you may want to look at apt-cacher or apt-proxy or the likes instead
<Chipzz> (to set up a local mirror)
<Chipzz> thuogh they have proven to be buggy in the past, dunnow if the issues got resolved
<Hobbsee> er, do we actually need gstreamer0.10-esd if we have no esound nwo?
<Hobbsee> that'll give us more space, too
<Hobbsee> bugs--
<tonyyarusso> Hobbsee: Sorry.....  I found, therefore I filed.
<tonyyarusso> ;)
<Hobbsee> tonyyarusso: :P
<ajmitch> we got rid of esd now?
 * ajmitch had some fun issues with it this morning
<StevenK> I thought we had.
<ajmitch> I hope so
<Hobbsee> 68 down to...48.  nice!
<ajmitch> still in main, but appears to not be dragged in
 * ajmitch should happily purge it thrn
<Hobbsee> ajmitch: yeah, we did for tribe 4, iirc.
<ajmitch> I wonder how many others have it installed still
<StevenK> I think my machine purged it during the upgrade.
<ajmitch> my laptop hasn't, sadly
 * ajmitch had to ssh in & kill it this morning in order to get a desktop running
<ajmitch> I wonder if it can be demoted to universe for hardy
<Burgundavia> if upstream goes with PA, then we shoudl proably go the same way
 * TheMuso wonders whether the PA issues that are holding it back are fixed.
<StevenK> Aren't the PA issues that are holding it back called "upstream" ?
<TheMuso> Yes, and according to pitti, they are fixed.
<StevenK> As in, upstream themselves. :-)
<ajmitch> StevenK: oh he's not that bad
<abarbaccia> hello all, i'm having trouble repacking a source package
<abarbaccia> the package is lirc-modules-source .. i just want to make a package which has a patch applied to it already
<Hobbsee> O.O!!!
<lifeless> don't you mean .oO ?
<lifeless> :)
<elkbuntu> o.O?
<Hobbsee> whichever.
<Hobbsee> the printing detection actually *works*!
<mbt> Not sure if this is the correct room, but just a quickieâdoes anyone know how long it takes OOo to build on a 64-bit uniprocessor AMD at/about 2 GHz?
<ScottK>  IIRC It takes ~12 hours on the Ubuntu buildd.  Dunno what they have.
<mbt> Does that include the language files?  My build seems to be going on 24 hours now, and I am trying to build it to test a fix for one of the bugs in LP
<ScottK> I think the language packs are separate, but don't know for sure.
<mbt> k, thanks.  I am hoping that it's done tomorrow.  I thought I'd have testing packages that would confirm a fix for LP 131526 by this afternoon
<ubotu> Launchpad bug 131526 in openoffice.org "[gutsy] OpenOffice crashes/hangs on errors in current gtk theme" [Critical,Confirmed] https://launchpad.net/bugs/131526
<TheMuso> Hobbsee: What? You expected otherwise?
<Hobbsee> TheMuso: i thought it only worked for USB printers.
<Hobbsee> i usually have to configure it all in kubuntu
<TheMuso> oh.
<TheMuso> and what connection does the printer in question have?
<Hobbsee> it's on the lan
<Hobbsee> via an ip address
<Hobbsee> (ie, not connected to any other machine)
<TheMuso> oh ok
<TheMuso> what protocol?
<Hobbsee> TheMuso: ipp, iirc
<TheMuso> Ah ok.
<LaserJock> I had to set mine up still
<LaserJock> but it's pretty easy
<LaserJock> a lot better than stupid Windows
<StevenK> My printer was fairly easy to set up, but my set up is a little strange, since my wife also wants to print.
<chowmeined> Is there a wiki page that goes through installing the rest of the debug symbols?
<RAOF> chowmeined: Looking for https://wiki.ubuntu.com/DebuggingProgramCrash ?
<chowmeined> thanks
<RAOF> Hey, anything I can do to help get working drivers :)
<chowmeined> what would be a good set of packages to get symbols for? i got xorg-dbgsym but i still have a bunch of ?? in my backtraces
<RAOF> xserver-xorg-core-dbgsym?
<chowmeined> yea i installed that one
<RAOF> libdrm?  Oh, you can't get that one.
<chowmeined> oh but im using the package you made.. that has debug symbols in it yes?
<MacSlow> Greetings everybody!
<chowmeined> er.. probably not
<chowmeined> hmm
<StevenK> Morning pitti
<pitti> Good morning
<StevenK> pitti: NBS has neatly exploded, too.
<pitti> StevenK: yeah, due to the giant buildd backlog
<pitti> StevenK: I'm afraid we need to let it settle for some days and ignore it
<liw> buildd backlog? huge numbers of new packages?
<StevenK> pitti: Yeah, I figured that. Some of it looks legit,.
<StevenK> liw: Autosync from Debian.
<liw> ah, right
<StevenK> liw: There's >1,500 pending builds.
<liw> I'm so aware of what's going on that it's scary, aren't I?
 * StevenK chuckles.
<pitti> liw: huge number of automatic syncs from unstable
<StevenK> liw: I've been doing this since Dapper, I have a little headstart.
<adop> My system freezes when it comes back from sleep. It has something to do with the disk controller, but it is very difficult to debug since i have no access to it after it tries to wake-up. Could someone direct me how to debug this problem?
<desertc> Tighter ALSA integration, please!
<Hobbsee> pitti: oh, i had a question for you.
<pitti> Hobbsee: oooh, questions!
<Hobbsee> pitti: yes.  is esound ever going to make it back onto the cds?
<pitti> Hobbsee: over my dead cold body, I hope
<pitti> Hobbsee: in hardy I hope that pulse is mature enough
<tfheen> pitti: well, as we say, that can be arranged.
<tfheen> ;-P
<Hobbsee> pitti: good.  then is there any point of keeping the gstreamer plugin for esd on all the cds?
<chowmeined> adop: sure its not video?
<Hobbsee> pitti: unfortunately, i'ts only 39kb, but you might want it nuked anyway :)
<pitti> Hobbsee: contrary to other things, size does *not* matter here :)
<Hobbsee> pitti: oh, why not?
<pitti> Hobbsee: esd is a horribly broken evilness
<Hobbsee> pitti: end question - can i nuke it off the -desktops?  :D
<pitti> Hobbsee: it often causes desktop lockups, bad A/V desynchronization on video playback, and other nastinesses
<Hobbsee> i know esd is otherwise evil, yes ;)
<StevenK> And so is evms, coincedence?
 * Hobbsee did a whole bunch of ubuntu-meta bug triage today, you see.
<pitti> Hobbsee: yeah, I don't see a reason to keep the gstreamer backend, but that isn't packaged separately, is it?
<Hobbsee> pitti: it's seeded separately
<adop> chowmeined, pretty sure, since the hdd led stays lit, and after i reset the bios says it cannot find a hd. I have to turn off the machine and then back on to be able to boot again
<pitti> gstreamer0.10-esd - GStreamer plugin for ESD
<pitti> indeed
 * pitti aims his gun
<Hobbsee> hm, i wonder if we even *have* hardy seeds yet
<Hobbsee> aww, can i do it?
<pitti> Hobbsee: sure we have
<chowmeined> adop: what controller do you have? and/or have you looked through bug reports to find something similar?
<pitti> Hobbsee: please
<Hobbsee> pitti: OK.  i made the mistake of touching the gutsy seeds today then.  whoops.
<pitti> Hobbsee: please bzr uncommit and push --overwrite as adequate then
<StevenK> It's scary that bzr has uncommit
<Hobbsee> apparently the brain hastn adjusted that gutsy isnt the development release anymore
<StevenK> Hobbsee: That will probably take until the first freeze.
<pitti> argh argh -changes spew
<Hobbsee> pitti: the other question - should i only do one, and it'll merge over?
<pitti> StevenK: it's a live saver at times :)
 * TheMuso will only be happy with audio once speech can be put through the chosen framework.
<pitti> Hobbsee: yes, please
<Hobbsee> pitti: i give you an either or, and you say yes.  try again.
<Hobbsee> oh wait, no i didnt.
<Hobbsee> ignore that :)
<pitti> Hobbsee: change in ubuntu, merge to other branches, please
<pitti> who am I to argue against a long pointy stick :)
<Hobbsee> pitti: ah, okay, so do the merge as well.  gotcha.
<Hobbsee> hehe :)
 * Hobbsee hugs pitti
<adop> chowmeined, it is nForce4, and the strange thing is that it appears that there are very few reports of simmilar problems, with no solution
<chowmeined> adop: if you add your, "this happens to me too" and then give them a bunch of information you can get the bug people to try and help you
<chowmeined> adop: https://help.ubuntu.com/community/ReportingBugs
<adop> chowmeined, i have asked this in the bug team, but i haven't gotten any reply yet. I'll try filing the bug with the official procedure. Thanks for your help
<chowmeined> adop: thank you for taking the time to report this
<Hobbsee> pitti: here's your gun back.
 * pitti takes back the water pistol
<Hobbsee> pitti: also, what are your thoguhts on https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/138825 ?
<ubotu> Launchpad bug 138825 in ubuntu-meta "{k,x,ed,u}buntu-desktop depends on packages which should be in ubuntu-standard" [Undecided,New]
<Hobbsee> (seeing as i'm in a seed-cleanup mood)
<StevenK> But they shouldn't.
<StevenK> They might be common packages, but they're all desktop.
<pitti> Hobbsee: some might, but keep in mind that -standard is installed on CLI and server installs
<Hobbsee> pitti: that's more or less what i was thinking
 * fabbione makes some more space for hardy on the local mirror
<pitti> stuff like bc,  dc, screen, unzip would fit, I guess
<StevenK> I thought screen was already in -standard, TBH
<pitti> bug updated
<ion_> Perhaps there should be a ubuntu-desktop-base, on which *buntu-desktop would depend.
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<ion_> Howdy
<pitti> wow, how can https://edge.launchpad.net/+builds have ~ 10 idle machines?
<pitti> those buildd slackers...
<pitti> good morning ogra
<ogra> morning
<StevenK> pitti: Maybe they're protesting.
<pitti> guess I was just (un)lucky and they just took a breath; they are busy again :)
<StevenK> pitti: Based on my observation, the buildds say they are idle while they are cleaning up after the last build, and uploading.
<soren> Gawd, I suck at following howto's.
<slangasek> trouble w/ the CD customization?
<soren> How'd you guess? :)
<slangasek> where are you stuck?
<soren> Nowhere in particular.
<slangasek> ok :)
<soren> I just don't follow recipes very well.
<soren> I need to understand stuff first.
<soren> Especially when the howto in question doesn't exactly deal with the problem, I'm faced with, but only a slightly related one. It's hard to make educated guesses in these situations.
<soren> Too many years of trying to help out users who get stuck following badly written tutorials or howto's have made me very suspicious. I don't like following howto's unless I know I could have written it myself.
<slangasek> well, that's one I could probably have written myself, so if you have specific questions just ask :)
<soren> That's the problem, really. Since I have limited knowledge of the domain, it's hard to ask intelligent questions. On the flip side, I guess this is a valuable lesson for me to remember when I'm writing howto's for others, so it's not all bad.
<liw> soren, I'm in the same boat, more or less: I strongly prefer to look things up myself, even if that makes things take longer
<liw> but it breaks down when the docs aren't there, or are really hard to find
<soren> liw: True.
<liw> on the third hand, I think it makes me more efficient in the long run to know how to look things up, rather than knowing whom to ask :)
<soren> Exactly!
<soren> I also feel much better being able to say that I've done so and so becuase that's what I found to be the most sensible approach, rather than "I did so and so, because it said so on a random wiki page".
<soren> If I were baking, I could refer all I wanted to the recipe that said to use a teaspoon of sugar and a pound of salt, it'd still taste awful.
<pitti> soren: with that ratio it will for sure :)
<Fujitsu> What keeps killing the buildds today?
<Fujitsu> I have seen them all with builds ~25 minutes old on a number of occasions over the past 12 hours, with no logs.
 * ogra guesses the mass imports keep them busy
<Fujitsu> ogra: That shouldn't really cause that...
<Fujitsu> But I guess if drescher is busy with syncs...
<mmeenagh> hello
<mmeenagh> just a quick prob with eclipse it doesnt recognize the apache server
<mmeenagh> exit
<pitti> lool: ooh, congratulations to MOTU! *hug*
<lool> pitti: Thanks!
<highvoltage> jono: did you hear they're going to remove the word "gullable" from the Oxford dictionairy?
<jono> highvoltage: yeah, right :P
<highvoltage> jono ftw!
<soren> Ohh, shiny! A popup just told me that the battery level on my wireless mouse is about to run out. I've never seen that before. That's pretty cool.
<Hobbsee> soren: your task for hte next release is to make it go and find another battery for you, and insert it.
<soren> Hobbsee: I might actually be able to get it make a battery show up at my doorstep... I wonder if you can order a rent-by-the-minute servant on the internet that can come by and actually insert the new battery..
<Hobbsee> soren: hehe :)
<Treenaks> I wish that battery thing understood bluetooth mice
 * soren hands Treenaks the hal source
<soren> Go fix it.
<TheMuso> 3~/c
<TheMuso> ugh
<soren> *headdesk*
<dendrobates> soren: ?
<soren> dendrobates: Well, let's just say that just *thinking* about pointing a vmware instance at a different iso doesn't make it happen.
<dendrobates> soren: your just not thinking hard enough.  :)
<Mithrandir> soren: clearly you need to enable the mind control input device
<soren> dendrobates: Possibly, but what I lacked in intensity, I sure made up for in time spent doing it.
<soren> Mithrandir: http://surl.dk/360/ ?
<soren> Mithrandir: Do they still look like that?
 * persia wonders which mind control devices are supported by the default gutsy kernel
<Mithrandir> soren: I think you can portable ones those days.
<persia> soren: http://openeeg.sourceforge.net/doc/links-biopsy.html is a good list of links for manufacturers, if you're interested.
<soren> wow..
<soren> eBay doesn't seem to have any of that stuff.
<persia> soren: The trick is drivers.  I've only heard of drivers that 1) are proprietary, 2) only provide for data logging (although one could write a userspace daemon to do things), or 3) are over-customised for paraplegics, and not very handy for general use.
<soren> persia: And you know this... how?
<persia> soren: I've been researching equipment for a wearable with a mind-control interface and augmented-reality feedback for the past 7 years.  Currently, I get about 3 hours on my goggle batteries, look like a freak if I actually wear it outside, and am limited to the HandyKey for input, which doesn't work well for high-motion situations.
<persia> The goal is something like the Terminator interface, only in color rather than monochrome red (and I'm willing to wear sunglasses, rather than wait for magnetic rings to warp my optical nerves)
<soren> persia: Just for fun?
<persia> soren: Well, mostly.  I have fantasies of plugging a projector into my jacket, and having slides just work during a presentation, but that's about as close as it gets to anything related to something serious.
<soren> <g> Cool.
<ogra> hmm, i wonder whats the reason behind making squashfs'es created with mksquashfs executable by default
<Riddell> asac: flash doesn't work currently on amd64 in firefox right?
<ogra> wasnt there a wrapper for that ?
<tepsipakki> Riddell: gnash works somewhat
<tepsipakki> even with youtube
<asac_> Riddell: it should
<asac_> Riddell: at least i use flashplugin-nonfree here without any problems
<Riddell> asac_: does it set itself up automatically?
<asac_> Riddell: yes ... just installing flashplugin-nonfree does all the magic
<asac_> e.g. depend on nspluginwrapper ... create the wrapper during postinst et al
<smagoun> dpkg question: I have packages A + B installed. A includes file F. I modify B to include a diversion of file F using dpkg-divert. dpkg won't install B', it complains that F is already installed as part of A. If I uninstall B then install B', B' installs just fine and the diversion of F works. Why doesn't B->B' upgrade work without first uninstalling B?
<gilligan_> i am interested in the upstart process of providing an early job-controlled shell.. it first closes any open file descriptor, then starts  a new session and open()'s /dev/console  with CTTY set ?
<dee> hello. Jono has said I should ask here. :) Will https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/121978 be fixed in Gutsy? Or will there be no internet for standard users till april?
<ubotu> Launchpad bug 121978 in linux-restricted-modules-2.6.22 "Unknown symbol in module fcpci.ko" [Medium,Confirmed]
<sladen> dee: that's ISDN related?
<sladen> dee: so does that mean that ISDN is broken---probably the biggest affected would be German users
<Riddell> ogra: please review patch at end of https://bugs.edge.launchpad.net/ubuntu/+source/hwdb-client/+bug/17595
<ubotu> Launchpad bug 17595 in hwdb-client "failure to parse xorg output leads to a hung gui." [Medium,Confirmed]
<dee> sladen: not only. fcdslsl is also broken.
<ogra> Riddell, looks fine
<dee> sladen: and yes, that's the reason why I'm asking. German users will have a little problem now. :(
<Riddell> ogra: can you test it works for you?
<ogra> Riddell, i have no system that has no xrandr support
<Riddell> ogra: so test it on a system with xrandr support
<ogra> ah, i can reproduce the second error
<ogra> bt i cant patch the binary :/
<zul>  /win 10
<Riddell> ogra: it's python, no binary involed!
<ogra> Riddell, i was trying to patch /usr/bin/hwdb-gui directly
<Riddell> ogra: best to patch the source package and build
<Riddell> ogra: I've attached a cleaner patch now
<ogra> i was to lazy to build a package for it :P
<ogra> the script doesnt get modified during build so i would have expected it to apply properly
<Riddell> ogra: get anywhere with it?
<ogra> building the package atm
<ogra> installing
<ogra> Riddell, works fine shoot it up :)
<Riddell> ogra: thanks
<dee> sladen: could you help or was this just a statement above. What can I do that this will be fixed?
<ogra> Riddell, thanks for doing the work
<cjwatson> doko: please see bug 156720, as it looks like it was your merge that dropped thig
<ubotu> Launchpad bug 156720 in glibc "IPv6 link-local interface lookup fix regressed from Feisty to Gutsy" [Undecided,New] https://launchpad.net/bugs/156720
<cjwatson> this
<lamont> cjwatson: is -updates there by default on install?  upgrade?
 * lamont is wondering if it's sufficiently bad to warrant -security
<cjwatson> should be there for both
<cjwatson> some people might choose to remove it
<lamont> ok
<cjwatson> it's not appropriate for -security IMO
<lamont> ok
 * lamont takes notes as he does yet another dapper->gutsy upgrade
<doko> cjwatson: oops, never checked in
 * lamont struggles to remember how to tell apt to explain why it's holding a package back
<Lutin> infinity: around ?
<wasabi> There a doc that explains the process by which an ubuntu dist upgrade modifies sources.list?
<soren> lamont: libdevmapper1.02, by any chance?
<lamont> yep
<lamont> but it's a totally off-the-wall behavior, since udev somehow manages to just remove itself from consideration
<soren> The new udev has a Breaks: libdevmapper blah... apt in Dapper doesn't understand Breaks, does it?
<soren> Gah, sorry, gotta run.
<lamont> mvo: wow.  outside of first installing libc6 and libpam-runtime, and the vim bug (156734), and removing evms, dist-upgrade to gutsy is happy on -server
<mvo> lamont: nice! dapper->gutsy :)
<lamont> yeah, dapper->gutsy
<dee> hmm should I push my question until someone can answer?
<dee> or is it helpful if I push the bug in malone every week? I don't think it will be faster solved then.
<lamont> dee: that depends  on the question...
<dee> ok, I repost it. :)
<dee> hello. Jono has said I should ask here. :) Will https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/121978 be fixed in Gutsy? Or will there be no internet for standard users till april?
<ubotu> Launchpad bug 121978 in linux-restricted-modules-2.6.22 "Unknown symbol in module fcpci.ko" [Medium,Confirmed]
 * achiang waves at lamont
<lamont> mvo: so... update-manager on a machine with feisty (and obviously some strangeness in sources.list) yields feisty-updates and then declines to notice that gutsy exists....  any clues?
 * lamont points mvo at achiang and watches
<lamont> hrm... I wonder if he took the evening off..
<lamont> :-)
<achiang> ok to flood here? looking at about... 8 lines
<dee> lamont: so you could not help either? who can help?
<lamont> dee: it might get fixed in gutsy-updates.  gutsy itself is closed
<dee> ah, quick answer. ^^
<lamont> achiang: just /query mvo. :-)
<dee> lamont: and what can I do so that it will be fixed?
<dee> about 50% of German users have such a network card.
<dee> okay, maybe 30...
 * lamont checks around
<lamont> achiang: the other option is to use tcpdump or a proxy or such on your machine to see what it's fetching, which might lend some clues
<lamont> dee: I'm going to see what else should be in an upload, and then I'll upload a new lrm to gutsy-updates
<dee> lamont: many thanks.
<bmm> It might be the wrong place to ask, so feel free to boo me to another channel. I want to use something else than vfat on my usb stick, but don't want user permissions stored on it. Is there a filesystem or option I can use instead?
<dee> the whole German Community will thank you then. :)
<sbalneav> bmm: um, why?
<lamont> bmm: I'm pretty sure the real filesystems all know about users and perms...  why would you ever want to not store them?
<lamont> their lack in vfat is seen as a major flaw in vfat
<bmm> lamont: when you move from linux box to linux box, you want to be able to edit and remove those files on all those boxes. Which means you would either set umask different or add mount options to the fstab.
<lamont> right
<bmm> (Those are the two options I can think of) but I don't have any rights to change the /etc/fstab as I'm not root on all.
<lamont> or have the same uid everywhere you go.
<lamont> iz trust question...
<sbalneav> Then why not use vfat?
<lamont> or do you really want to plug your private files into some random machine?
<bmm> lamont: It's a work pc, so I trust it and I don't have the same uid
<sbalneav> Is it just between a work and home machine you're sharing?
<bmm> lamont: also, I trust my home box not to start executing stuff from the usb stick or getting hacked by an invalid filesystem ;-)
<bmm> sbalneav: yes, for the example I am. I real life, my girlfriend also has ubuntu now.
<dee> lamont: Probably all modules fcdsl2, fcdslsl, fcdslslusb, fcdslusb, fcdslusb2, fcpci, fcdsl, fcdslusba, fcusb, fwlanusb, fxusb are concerned.
<lamont> right
<sbalneav> Well, probably then it would simply be easier to make sure the userid's are the same, with the one work box that's not under your control.
<sbalneav> Barring that, vfat would be your best bet.
<bmm> sbalneav: yeah, I'm getting to the point where I can't see a way out of vfat. Still, I think I may have to file a bug with somewhere like ext3 or the like... Thanks!
<sbalneav> Well, there's nothing wrong with ext3.  You're simply wanting two things that are basically mutually exclusive.  I'm still a little unclear as to why you didn't want vfat :)
<profoX`> BenC: mjg59: I just rolled in from the #ubuntu-classroom chat where I posed this question. sabdfl told me to ask one of you two instead: "follow up on laptop usability: Suspend/resume does not work for many people with swsusp or uswsusp. I myself have very good experiences with a TuxOnIce patched kernel. Has it already been proposed to include that patch by default in Ubuntu, and if not, why not?"
<BenC> profoX`: No, and because I've never heard of it before
<bmm> sbalneav: It's not that I don't want vfat, it's just that I didn't think it was cool and it's getting old in my mind ;-)
<profoX`> BenC: it's the new name for Suspend2
<profoX`> ( http://www.tuxonice.net/features )
<BenC> oh, in that case it's because it's way too invasive for us to include
<BenC> plus it requires lots of untested (on ubuntu) userspace changes
<BenC> profoX`: and "does not work for many people" is a bit arbitrary and misleading...stock suspend/resume works for most people
<mjg59> profoX`: There are basically no situations in which tuxonice will work and the in-kernel suspend won't.
<BenC> mjg59 would have much more to say
<profoX`> mjg59: what happens if there is not enough free SWAP space to perform a suspend action with swsusp?
<mjg59> profoX`: It will resume again
<profoX`> meaning it will not suspend, right?
<mjg59> Correct. swsusp2 doesn't magically fix that.
<sistpoty> hi, anyone who'd like to sponsor me an update for nvidia-settings (bug #156362)?
<ubotu> Launchpad bug 156362 in nvidia-settings "should ship NVCtrl.h and NVCtrlLib.h" [Undecided,New] https://launchpad.net/bugs/156362
<BenC> sistpoty: most likely that wont get fixed until hardy
<sistpoty> BenC: the debdiff is for hardy ;)
<BenC> the -2.6.22 package isn't though :)
<profoX`> mjg59: TuxOnIce is able to compress the data, and it can suspend to a swap partition and an extra swapfile at the same time if necessary, so I do think that it would work better.
<sistpoty> BenC: hm? what -2.6.22 package?
<BenC> profoX`: in that rare case, yet
<BenC> sistpoty: linux-restricted-modules-2.6.22 is not going to remain in hardy very long (like maybe a week or two)
<lamont> BenC: .24?
<BenC> lamont: hopefully
<lamont> kewl
<sistpoty> BenC: ah, I see. so I should defer nvidia-settings for later?
<Lutin> BenC: would you mind having a look at bug #129910 ?
<ubotu> Launchpad bug 129910 in linux-source-2.6.22 "tty[1-6] are active but display nothing in Gutsy" [Undecided,New] https://launchpad.net/bugs/129910
<BenC> sistpoty: nvidia-settings is a package out of linux-restricted-modules-2.6.22, or no?
<sistpoty> BenC: no, it's a standalone package
<BenC> sistpoty: oh, then I'm not sure what to do with it
<sistpoty> (but I guess it makes use of the nvidia restricted kernel interfaces)
<BenC> we don't maintain it
<sistpoty> BenC: upload my debdiff? *g*
<BenC> we == kernel team
<BenC> sistpoty: who was the last uploader for that package?
<lamont> lrm uploaded
<lamont> dee^^
<BenC> lamont: thanks
 * lamont lunches
<sistpoty> BenC: iirc mvo was, but I'd need to check to be sure
<sistpoty> yep
<dee> lamont: wow.... don't know the English expression but you will get a "Fleiss-Bienchen"... ^^
<sistpoty> dee: that's a busy bee ;)
<dee> sistpoty: do you have something like this in ... erm, England or US or whereever you live?
<ogra> sistpoty, but i think what dee meant was rather lamont deserves a gold star :)
<sistpoty> dee: well, I'm from germany actually :P
<ogra> dee, sistpoty tarnt sich nur :)
<sistpoty> haha
<dee> sistpoty: that help's a lot. ^^ ogra: correct, something like a star.
<ScottK> Much better than I feared.  It sounded like something unpleasant to my English speaking ear.
 * sistpoty admits that he didn't use the term Fleiss-Bienchen yet *g*
<dee> ScottK: Never... Maybe German is a unpleasant language. ;)
<Hobbsee> dee: it's a very harsh one, yes
<ogra> dee, watch the great disctator from chaplin ... i think it outlines pretty well how others hear us :)
<ScottK> Every language has it's own voice that's right for it.  They don't always harmonize well.
<dee> ogra: I know the movie, but only in German.
<ogra> the speeches he holds are in some weird self inveted tune
<dee> *putitonmy-ToRent-list*
<sistpoty> ogra: Jawoll! *g*
<ogra> :)
<dee> that means "to rent", not Torrent ... before someone will complain. ;)
<dee> so, I'm off here. bye and thanks again.
<Hobbsee> jcastro: just beat it until it submits to your will.  problem solved.
<mvo> sistpoty: hello, what was that about nvidia-settings?
<Hobbsee> mvo: you broke it.
<mvo> i did?
<Hobbsee> mvo: of course you did.
<sistpoty> mvo: I've got a small patch to ship the headers for the library... see bug #156362... mind sponsoring me?
<ubotu> Launchpad bug 156362 in nvidia-settings "should ship NVCtrl.h and NVCtrlLib.h" [Undecided,New] https://launchpad.net/bugs/156362
<Hobbsee> mvo: and even if you didnt, we'll blame you anyway.
<mvo> Hobbsee: pfffff :)
<Hobbsee> mvo: :D
<sistpoty> mvo: (it's in order to build sensors-applet with nvidia-support...)
 * Hobbsee hugs mvo
 * mvo hugs Hobbsee
<mvo> sistpoty: sure, that should be fine
<sistpoty> :)
<sistpoty> thanks mvo
<mvo> sistpoty: upload, thanks for the diff!
<sistpoty> mvo: thanks!
<sistpoty> are auto-imports now listed on the hardy-changes list as well?
<soren> They've always been?
<sistpoty> soren: no, there was a separate -auto-changes list (or s.th.)? but I'm just curious though... right now, I can still handle the traffic *g*
<Tritonio> hello eveyone. i don't know if this is the right channel but I have a nautilus related question to ask...
<Tritonio> i want to open a window showing the contents of a folder with one of them selected. Like the "explorer /select \path\filename.ext" command in windows... I want to do the same but with nautilus.
<soren> sistpoty: https://lists.ubuntu.com/archives/ubuntu-changes-auto/  suggests that this changed during the Dapper cycle. Quit living in the past, Stefan! :)
<sistpoty> soren: damn... I guess I've noticed this now, because I don't have my filters set up at work *g*
<soren> ;)
<sistpoty> <- old bastard
<soren> :)
<LaserJock> oh my gosh, gmail's got IMAP now ...
<keescook> Hm.  How do I make changes to the /var/lib/dpkg/status Conffiles list?
<TMM> I have a question: there's a bug in ncpfs in gutsy, and I'd like to fix it, is there an official maintainer for it or something? How do I go about that?
<TMM> I mean, I need to discuss what to do with someone :) because the appropriate fix seems to be to downgrade :) it appears that the ncpfs code in the kernel and the user space stuff doesn't use the exact same interface
<tepsipakki> hmm, sync requests aren't being handled yet?
<LaserJock> TMM: you might want to have a look at https://wiki.ubuntu.com/StableReleaseUpdates
<ScottK> tepsipakki: The first autosync just finished this morning and is still building.
<TMM> LaserJock: I'll have a look, thanks
<tepsipakki> ScottK: ah, fair enough :)
<tepsipakki> didn't check the queues
<TMM> LaserJock: right now it just plain doesn't work, not in any scenario
 * lamont bets mvo is sleeping
<mvo> lamont: almost
<lamont> mvo: what exactly triggers update-manager to decide that gutsy is available?  wanna point me at the right file in the source?
<sistpoty> keescook: why would you want to do that? (and is this really a conffile?)
 * lamont brb
<glatzor> lamont: Core.MetaRelease
<mvo> lamont: http://changelogs.ubuntu.com/meta-release
<lamont> mvo: and if there is no ubuntu.com archive in sources.list?
<lamont> or does it always fetch that URL regardless?
<mvo> yes
<lamont> interesting.
<lamont> the situation here is: given a (stale?) sources.list pointed only at internal: update-manager says "up to date".  add an ubuntu.com archive and apt-get update: then even if you change sources.list back, update-manager recognizes gutsy.
<lamont> I would blame the "transparent" proxy if it wasn't a continuing issue since gutsy release.
<lamont> and the proxy only caches things for 24 hours
<mvo> lamont: that is update-manager under gnome, right?
<mvo> lamont: what does lsb_release -a output on this system?
<lamont> could be cli... let me check
<mvo> the kde has a bug like that
<mvo> fixed in gutsy-proposed
<lamont> ah, ok.
<lamont> what should lsb_release -a say?
<mvo> something with gutsy in it
<lamont> something with gutsy in it --> no upgrade, since we're already tehre?
<lamont> there?
<mvo> yes
<lamont> ok.  that gives me the ammo I need.
<lamont> do we know how it gets there?
<ScottK> mvo: My Kubuntu install has Gutsy.
<mvo> lamont: lsb_release is part of the lsb-release package (if that is what you mean :)
<lamont> I meant do we know why lsb_release is deciding to report 'gutsy'...
<lamont> and I suspect that it's because we upgraded that package to the gutsy version, or that something wrote /etc/lsb-release
<mvo> that sounds plausible
 * mvo is away for some minutes
<lamont> and s/gutsy/feisty/ will make update-manager happy for those poor afflicted ones?
<lamont> the trend seems to be that they first see feisty-updates, and then it reports that all is well and current after the upgrade to current feisty-updates finishes
<lamont> so I wonder if maybe u-m is the guilty one???
<cjwatson> sistpoty: it was an accident - they weren't supposed to have gone to the -changes list
<keescook> sistpoty: well, procps used to use /etc/init.d/procps but then (a while back) switched to procps.sh, and are now switching back to just plain "procps".
<keescook> sistpoty: but it doesn't install the new procps file because (I am assuming) it is marked as "obsolete" in the dpkg status file
<cjwatson> I think that's worth checking rather than assuming it
<cjwatson> dpkg conffile handling is a bit subtle
<keescook> cjwatson: yup.  if I remove the "obsolete" entry manually it works as expected.
<mvo> lamont: hm, that sounds all a bit odd. you say that for people update-manager comes up and offers an upgrade, then they apply some updates and the next time it is run, the update option is gone?
<lamont> update-manager comes up, tells them that feisty-updates is what they need.  they run that update, and then run update-manger again, and it says "you're up to date"
<mvo> lamont: and no "upgrade to gutsy" button anymore. or was it never there?
<lamont> nope.  and changing sources.list to point to u.c and dist-upgrading makes us then decide that gutsy is an option
<lamont> I'll work on actually duplicating it later this week
<lamont> or at UDS.
<lamont> today/tomorrow I'm in a meeting all day
<mvo> lamont: ok. they use the version of update-manager from feisty-updates I assume? because then it should be fine. you could check ~/.update-manager-core/meta-release and see if that contains gutsy. the file is requested with no-cache headers, so it should hopefully get through the proxy just fine
<mvo> lamont: it would be cool to debug this issue
<lamont> ok
<lamont> I have a machine I can drop feisty on to test the update.
<Kmos> can someone update command-not-found database on gutsy ?
<mvo> lamont: I understand this is a problem in your company network?
<mvo> Kmos: it was updated a couple of days before the release
<mvo> Kmos: what is wrong with it?
<lamont> all of the users I've heard it from have been internal to the company network, yes
<lamont> and the company is known to have proxies that are not-so-transparent.
<mvo> lamont: but http access to files outside of the network works, just through a (forced/transparent) proxy?
<lamont> correct.
<Kmos> mvo: i tried startupmanager and it didn't show any package for it
<Kmos> it's that normal ?
<lamont> if you don't specify a proxy, you get one.  and that proxy doesn't expire Packages/etc in less than 24 hours, which means that it's perfectly normal and common to have the md5sum check fail
<mvo> lamont: ok, thanks. that makes the picture more complete. I wonder if the meta-release file is stale in the proxy as well, but then it changed more than 24h ago, so it should be refreshed by now. strnage
<mvo> Kmos: I get: $ startupmanager
<mvo> The program 'startupmanager' is currently not installed.  You can install it by typing:
<mvo> sudo apt-get install startupmanager
<lamont> mvo: right
<lamont> so now I have what I need to be able to walk someone with the issue through figuring out the evil that IT has done
<lamont> unless it's our bug. :-(
<mvo> lamont: feel free to file a bug and paste the content of our conversation so that it is not forgotten
<Kmos> mvo: i don't get that
<lamont> ok.  I'll assign it to me, even.
<mvo> lamont: it might be a u-m bug as well, I start to hate proxies, give us all sorts of problems
<Kmos> kmos@bash:~$ startupmanager
<Kmos> bash: startupmanager: command not found
<lamont> update-manager honors $http_proxy, yes?
<Kmos> command-not-found is already the newest version.
<mvo> lamont: yes
 * lamont will file the bug tonight, when he's not on his laptop
<stgraber> Kmos: updated system or clean install ? (I have command-not-found working correctly on a clean install here)
<mvo> Kmos: I assume command-not-found-data too? it works here on a fresh install (just tested on my test-vm)
<Kmos> mvo: installed too
<Kmos> stgraber: upgraded from feisty, since tribe-3 ou -4
<mvo> Kmos: odd, what does "/usr/lib/command-not-found startupmanager" output?
<Kmos> with all latest updates :)
<Kmos> kmos@bash:~$ /usr/lib/command-not-found startupmanager
<Kmos> The program 'startupmanager' is currently not installed.  You can install it by typing:
<Kmos> sudo apt-get install startupmanager
<Kmos> it's correct..
<Kmos> something with my bash script ?
<mvo> Kmos: could you please check /etc/bash.bashrc? there should be something with command-not-found at the bottom
<Kmos> # if the command-not-found package is installed, use it
<Kmos> exactly
<Kmos> http://pastebin.com/d573711ba
<Kmos> it points to /usr/bin/
<Kmos> and not /usr/lib
<mvo> Kmos: do you have a /etc/bash.bashrc.dpkg-new (or something similar)?
<Kmos> mvo: nop
<Kmos> maybe i didn't overwrite the bash in some update, but really don't know
<mvo> that was my guess now (conffile prompt answered with "keep old version")
<Kmos> :)
<Kmos> i need to change it manually
<mvo> yes
<Kmos> thanks =)
<mvo> cheers :)
 * mvo should go to bed soon
<Kmos> mvo: good night
<Knuckles> Hello all!
<Knuckles> I read the article about joinning the ubuntu developement team
<Knuckles> and I want to do it
<Knuckles> but I can't know exactly what kind of competences are necessary to do that
<Knuckles> as, wich languages do i have to know, etc.
<Knuckles> Sorry for those messages, I didn't read the subjet. Mea Culpa
<ScottK> Knuckles: If you are just getting started, #ubuntu-motu is a better place to start.  Helping newcomers is part of their mission.
<Knuckles> Yep
<Knuckles> I read this channel subject and saw that after posting
<Knuckles> Thank you for your help.
<dogwater> Sooo which update would ya say broke my wifi last night, lol
<desrt> dogwater; you're more likely to find out in #ubuntu
<tonyyarusso> BenC: ping?
 * lamont wants working video on his ATI Radeon mobility 1600 without using fglrx
<jdong> lamego: heh, good luck?
<lamego> jdong, hum :) ?
<lamego> ah, was lamont
<lamont> jdong: well, I got video back, but with fglrx
<jdong> lamego: ok, when 3 letters are the same, you are asking for mistabbing from me :)
<lamont> with feisty, I -HAD- non-fglrx video working.  nfc how though.
<jdong> lamont: what? what driver?
<jdong> avivo?
<lamont> exactly
<lamont> I wish to hell I knew.
<lamont> for that matter, how do I get the X server to dump config, or tell me the driver name?
<jdong> lamont: well the only other driver that runs on the card is avivo and VESA
<jdong> lamont: /etc/X11/xorg.conf
<lamont> I wonder if it was avivo
<lamont> jdong: you can boot without xorg.conf in gutsy.
<lamont> but no config to read then
<jdong> lamont: xorg.0.log
<lamont> and reverseparse that log. ew.
 * lamont tries avivo
<jdong> lamont: I was totally unaware that avivo had xvideo acceleration...
<Amaranth> no no, if you start it without an xorg.conf file it dumps out what config file would match what it's using in the log
<Amaranth> I think, anyway. Haven't tried it in awhile
<lee_pepper> Hey does any one know any thing about intellectual property crimes, and open source??
<ion_> Nope, no-one does.
<lee_pepper> ouch
<cjwatson_> I think you should ask a less vague question
<cjwatson_> but if you need a lawyer, this is not the place
<pwnguin> and if you need a paper for ethics class, this is also not the place ^_^
<ion_> And if you need a hand committing an intellecutual property crime, this is not the place either. :-)
<desrt> and if you're trolling to find out if we even recognise the term "intellectual property" as having a particular meaning, this is apparently also not the place? O_o
<Spads> keep your property laws off my intellect, thank you.
<lamont> avivo FTL.
 * desrt thinks lee_pepper is getting more than s/he bargained for :)
<jdong> lamont: I don't know if radeonhd would work with the X1600?
<jdong> or if it has xvideo for that matter
<lamont> it screamed about video 0 being live with no outputs
<jdong> O_O
<lamont> I figure I'll make it my project at UDS next week,.
<desrt> holy crap UDS is next week
<desrt> :D
<Mithrandir> it is
<Mithrandir> scary thing.
<desrt> colour me excited
<desrt> Mithrandir; attending?
<Mithrandir> desrt: of course.
<desrt> with guest?
<lifeless> desrt: you coming ?
<Mithrandir> desrt: no. :-(
<desrt> lifeless; wouldn't miss it :)
<lifeless> excellent
<lifeless> see you there :)
<desrt> Mithrandir; that's unfortunate
<desrt> lifeless; you will :)
<Mithrandir> desrt: indeed.
<xhaker> Boston right?
<desrt> mhmm
<desrt> pretty close to MIT
<Mithrandir> at MIT, I thought?
<jdong> desrt: technically on campus
<desrt> just down the street from, actually
<jdong> Cambridge :)
<desrt> the hotel isn't on the campus...
<jdong> desrt: I can see the building out of my window.
<tonyyarusso> cjwatson_: Say, I have a kernel-related question if you have a moment.
<desrt> is the conference in the hotel or at the university?
<jdong> hotel, I thought
<desrt> the hotel is technically on campus?
<jdong> desrt: well how do you define on campus?
<desrt> i don't know -- that's the problem :)
<jdong> desrt: going by the MIT "all campus buildings have a building number" rule, than no
<jdong> then*
 * desrt google mapsed it and there seems to be a rather clearly defined "this is MIT" area
<jdong> desrt: going by the "there's more buildings further from it, so campus encovers the radius", then yes
<desrt> ah... so there is a core campus and outlying buildings
<jdong> desrt: right
<jdong> desrt: and near the east side MIT owns a huge number of biotech skyscrapers
<cjwatson_> tonyyarusso: I think you may be talking to the wrong person - I'm not a kernel hacker
<jdong> that are technically MIT property but most of our mortal undergrad souls never get to enter :)
<desrt> i grok.  thanks for the info
<jdong> sure thing
<tonyyarusso> cjwatson_: could be - I guess I'm mis-thinking today.  Darn :(
 * tonyyarusso wants his bloody consoles back
<cjwatson_> #ubuntu-kernel maybe
<tonyyarusso> I'll try that
#ubuntu-devel 2007-10-25
<soren> lamont: Are you tagging the dapper->hardy upgrade bug reports?
<keescook> cjwatson_: when would be a good time to look over procps with me?  I've put my merge up if you want to see the disappearing conffile trick...  http://people.ubuntu.com/~kees/hardy/
<cjwatson_> keescook: I'm supposed to be on holiday now and packing. UDS?
<cjwatson_> I'm only still here to try to finish off PS3 stuff and get this dapper installer work tested
<keescook> cjwatson_: works for me -- I'm in no rush.  :)
<keescook> I can't even do the stuff I want to do with sysctl until 2.6.23 lands.  ;)
<bdmurray> jdong: you commented on 145123 - I'm trying to recreate it
<Solarion> woo hoo!  the gibbon is giving the werewolf a run for his (her?) money!  :)
<khatahn> hi, if this is the wrong place to ask, please point me to the right place: now that Gimp 2.4.0 final is released, is it going to be officially available for gutsy somehow, or is -rc3 where it's going to stay?
<cjwatson> khatahn: gutsy will remain at its current version. At most, the final release may become available in backports
<khatahn> firefox is some kind of exception then i assume?
<Solarion> khatahn: you mean the security update?
<khatahn> i guess so
<cjwatson> khatahn: we have to exempt firefox because we can't otherwise reasonably provide security updates for it
<cjwatson> but it is definitely an exception (and one we'd like to cease, if upstream practices were to improve), not the general rule
<khatahn> ok, thanks for the information
<cjwatson> (FAOD I doubt the way firefox is handled will change in the near future though)
<Solarion> interesting.  ubuntu's ifconfig reports MiB as MB, but debian's reports MiB as MiB.
<achiang> so, my system is hanging hard after an upgrade to gutsy. i've filed a bug, attached a sysrq-t dump, dmesg, and lscpi
<achiang> anything else useful to include?
<chowmeined> uh oh
<chowmeined> somebody made a mistake
<TheMuso> chowmeined: For what?
<chowmeined> the new thunderbird broke a bunch of stuff
<chowmeined> all the pages are filled with XML parsing errors after upgrading
<TheMuso> ah
<chowmeined> thats my initial sensationalist description of the problem
<chowmeined> ill refine it in a bit
<desrt> hmm.  fascinating.  ubuntu causes laptop harddrives to die before their time
 * desrt wonders if that has anything to do with his laptop harddrive dying before its time
<mathiaz> zul: you should also send your email about Xen In Hardy to ubuntu-devel
<mathiaz> zul: or ubuntu-devel-discuss
<zul> mathiaz: sure
<zul> mathiaz: sounds reasonable though?
<mathiaz> zul: yes. I've just quickly read the email.
<mathiaz> zul: I don't have a lot of experience with xen (for now).
<mathiaz> zul: so I can't really comment on it.
<mathiaz> zul: but from what I've read, it seems reasonable.
<Amaranth> it looks like bug 59695 got dugg
<ubotu> Launchpad bug 59695 in acpi-support "default value in power.sh potentially kills laptop disks" [Wishlist,Confirmed] https://launchpad.net/bugs/59695
<Amaranth> just checked, my load count is 580000 after 18 months :/
<mjg59> Amaranth: By default, power.sh does nothing
<Amaranth> mjg59: sure but powertop told me to enable laptop mode :/
<mjg59> Amaranth: If powertop told you to jump off a cliff, would you?
<Amaranth> if it got me 5 minutes extra battery life...
<mjg59> If you enable aggressive power management, then yes, your hard drive life will be shorter
<jdong> bdmurray: I suspect it's a problem with the way the new fglrx 8.42 works...
<jdong> bdmurray: also, mouse-pasting seems to work in gnome-screensaver!
<mjg59> If your BIOS defaults to programming your drive to have aggressive power management, then that's an issue with your BIOS rather than us
<jdong> IMO that's also a security breach
<jdong> especially since now we give "Leave MEssage" a cleartext textbox that can echo back clipboard contents
<jdong> bdmurray: lol, I just read your comment on the bug... ignore my comments before the last comment :)
<jdong> anyone else think bug 146862 shoudl be tagged as a security bug?
<ubotu> Launchpad bug 146862 in gnome-screensaver "Should not allow to paste in the Leave Message box" [Medium,Triaged] https://launchpad.net/bugs/146862
<jdong> it discloses the contents of the clipboard before locking the screen
<tonyyarusso> jdong: seems reasonable to me
<tonyyarusso> I'm not really the person to ask, but if you're just looking for general populace feedback, there you go.
<jdong> tonyyarusso: thanks; I'm just wanting to make sure I'm not completely out of line in thinking that's a security problem
<tonyyarusso> jdong: np :)
<tonyyarusso> I can't really think of an instance where it would be a problem for me personally, but in a corporate environment it certainly could be.
<jdong> tonyyarusso: the problem is more serious with mouse-paste IMO -- anything a user might've accidentically selected while manipulating or reading would be accessible from the clipboard buffer...
<jdong> by someone else...
<tonyyarusso> jdong: yeah
<jdong> I mean the point of locking your screen is primarily privacy from people walking by of what you were doing
<tonyyarusso> jdong: Unless of course you happened to close the application, and that other clipboard bug cleared it for you.  :P
<jdong> tonyyarusso: rofl :)
<jdong> tonyyarusso: two bugs make a security feature.
 * tonyyarusso still gets very very irritated with how Gnome handles copy and paste between apps....
<jdong> tonyyarusso: more of a problem with the X11 clipboard protocols...
<jdong> tonyyarusso: KDE's workaround (a competent clipboard manager) seems good... but not without its limitations
<ion_> Indeed, i can lock the screen, click âLeave Messageâ and paste the clipboardâs contents to the textbox.
<jdong> ion_: yeah... I am shocked by how many screensaver vulnerabilities there are this release :(
<jdong> ion_: there's currently a compiz-related one where you can kill the screensaver
<ion_> As a concept, the âLeave Messageâ thing is really neat.
<jdong> ion_: yeah, without a doubt it's awesome
<smallfoot-> http://www.linux-hero.com/rant/explanation-ubuntu-hard-drive-wear-and-tear -- please fix this
<ion_> File bug reports at Launchpad.
<jdong> smallfoot-: we've heard and were discussing this arleady
<ion_> (That oneâs already there.)
<jdong> smallfoot-: the story's on digg, we don't need 10,000 people coming in here one by one asking for a fix...
<smallfoot-> okay, but you need to fix it immediatly, and make a patch
<smallfoot-> this is an very important issue, i dont want my hard drive be crashed
<sbalneav> smallfoot-: The fix is right in the article
<smallfoot-> if it happen in windows, microsoft would release a patch to fix it, you must patch too
<mjg59> smallfoot-: Does it happen to you?
<TheMuso> c
<TheMuso> ugh
<smallfoot-> i dont know
<TheMuso> wrong tab
<smallfoot-> yes, but i cant recommend ubuntu to friends, if it will destroy their hard drives
<tonyyarusso> ...
<tonyyarusso> smallfoot-: mine's not dead yet, so I'd take issue with "will destroy"
<mjg59> smallfoot-: The summary is that Ubuntu does not touch the power management settings on your hard drive.
<mjg59> If your hard drive behaves like that, it's because your BIOS tells it to
<smallfoot-> then why this guy made post in digg.com?
<mjg59> smallfoot-: You'd have to ask him that
<smallfoot-> oh ok
<smallfoot-> he have hitatchi
<smallfoot-> i have samsung
<jdong> smallfoot-: the article is incorrect
<smallfoot-> ok
<smallfoot-> i dont need worry?
<jdong> smallfoot-: he must have set ENABLE_LAPTOP_MODE=YES in acpi-support
<jdong> smallfoot-: in a greedy attempt to get more battery life
<jdong> smallfoot-: laptop-mode might set an aggressive powersaving mode like this... it's not default config
<jdong> smallfoot-: also, many articles on "power saving" under Linux recommend similar tactics
<smallfoot-> oh
<jdong> smallfoot-: we cannot stop users from trying things like this :(
<smallfoot-> ok
<tonyyarusso> (doesn't laptop-mode get automatically enabled by the installer if it thinks the machine is a laptop?)
<mjg59> tonyyarusso: no
<smallfoot-> i went into services in ubuntu, and it had both APM and ACPI enabled, i only need ACPI, why both enabledf?
<jdong> tonyyarusso: no, it doesn't....
<mjg59> smallfoot-: Because you can pass an argument to the kernel to tell it to use apm instead of acpi
<tonyyarusso> mjg59: Oh.  It is at least installed by default if not enabled...right?  (Or I've *completely* lost it)
<mjg59> tonyyarusso: Yes
<tonyyarusso> k
<jdong> 67:# Switch to laptop-mode on battery power - off by default as it causes odd
<jdong> 68-# hangs on some machines
<jdong> tonyyarusso: ^^
<jdong> 69-ENABLE_LAPTOP_MODE=false
 * ajmitch wonders what a 'sane' load cycle count is supposed to be
<jdong> ajmitch: one that predicts the hard drive having > 2yr life?
<ajmitch> jdong: well my laptop is coming close to 2 years of age, running ubuntu from about the first day I had it :)
<ajmitch> I'm sure that I had laptop mode enabled at some point
<ajmitch> so I see a count of ~240K
<smallfoot-> i bought my comptuer in  2007, ACPI is the successor to APM, i dont need APM
<smallfoot-> APM is old technolgoy, i have new computer, and must use new technology!
<ajmitch> mine's an acer, so having a broken BIOS is a given
<ion_> âWelcome to the Ubuntu Settings Wizard. How many months do you want your laptop HDD to last? [   24 ]â
<mjg59> smallfoot-: Then it's using ACPI. Don't worry.
<smallfoot-> ok, but i disabled APM, cuz i dont want to waste resources like Windows Vista
<smallfoot-> i want a mean, lean, clean, machine, thats fast!
<smallfoot-> FULL POWER!
<smallfoot-> use little resources, run fast, quick, responsive
<mjg59> That's fine. It's not running anything APM related.
<mjg59> http://mjg59.livejournal.com/77672.html has a description of the issue
<smallfoot-> ok, i disabled it anysays
<smallfoot-> oh
<chowmeined> set your BIOS to wait a reasonable amount of time
<Solarion> mjg59!
<chowmeined> depending on how you use your laptop
<jdong> smallfoot-: also see http://www.thinkwiki.org/wiki/Problem_with_hard_drive_clicking#Possible_Cause_and_Speculation
<jdong> smallfoot-: it seems like a lot of laptop drives are culpable to this behavior, even without help from laptop-mode
<mjg59> Solarion: Mm?
<Solarion> mjg59: hi.  :)
<chowmeined> smallfoot-: then do it this way...
<smallfoot-> i dont have laptop
<smallfoot-> laptop are for girls, im real men, i use desktop computer, with 19" screen!
<smallfoot-> with real keyboard, and real mouse!
<chowmeined> smallfoot-: dont use a GUI, dont use a hard drive (flash drive instead), and dont use wireless
<smallfoot-> and im gonna buy a 22" screen
<Solarion> smallfoot-: that explains your back pains, then.  :)
<jdong> FWIW, I have a 3-y-o laptop with load cycle count 877074
<jdong> and it's still alive and doing well
<smallfoot-> Solarion, laptop is more ergonomic?
<Solarion> smallfoot-: than a desktop, yes.
<Solarion> backpack-wise, anyhow
<smallfoot-> chowmeined, flash drive expensive, and i need the GUI, i dont want use 1960 computer, i must have GUI
<chowmeined> lol
<chowmeined> computers in the 1960s didnt have consoles
<mjg59> Anyway. Unless anyone has any technical issues they want to bring up, could you move this conversation elsewhere?
<chowmeined> they had punch cards and other nonsense
<mjg59> The level at which it impacts Ubuntu is pretty obvious
<jdong> mjg59: on the other hand, would it be sane to do some monitoring of load cycle counts via a periodic cronjob, and if it increments alarmingly fast pop up a notification balloon of some sort?
<mjg59> jdong: I don't know that that value is guaranteed to be an actual measurement of the number of load cycles
<mjg59> If it turns out that a large number of BIOSes are programming this oddly, then we ought to be more proactive. But that's still us defending ourselves about poor BIOSes, not a fundamental failure of Ubuntu.
<jdong> mjg59: defending the user against poorly designed hardware, when we can, is a definite plus
<jdong> I agree strictly speaking it's not the responsibility of the OS
<mjg59> Yes, I'd agree. But it's a bonus if we do, not a failure if we don't.
<chowmeined> sure logically it is
<jdong> now the other question I have....
<chowmeined> but people will see it as a failure
<jdong> if you drop your laptop once, would park-on-idle have paid off?
<chowmeined> especially with sensationalist postings on digg flying around
<tonyyarusso> At least now I know how to get on Digg.... :P
<jdong> I expect the disk head crashing down on data parts of the hard drive would be a bad thing (tm)?
<chowmeined> jdong: backups pay off
<tonyyarusso> "UBUNTU WILL MAKE YOUR MOUSE EXPLODE!!1!"
<jdong> chowmeined: backups will always pay off, but that's not the question I'm raising
<jdong> mine is assessing the benefits vs harm of aggressive idle management
<chowmeined> i think thats a different thing however
<chowmeined> at least.. the laptops that sense they are falling and park the head
<jdong> chowmeined: yeah, that is different
<chowmeined> i dunno
<chowmeined> i dont drop my laptop
<jdong> chowmeined: I don't think anyone intends to drop their laptop
<jdong> well if they do, then they don't deserve one and should send it to me :)
<TheMuso> lol
<chowmeined> when will there be builds of hardy available? i want to get a head start fixing bugs, since its LTS.. id like it to work as well as possible
<chowmeined> there were some serious issues in gutsy unfortunately
<jdong> chowmeined: awesome, that's the spirit :)
<chowmeined> like ralink wireless drivers being very very flakey
<TheMuso> ug
<jdong> chowmeined: that's not really gutsy's fault, unless I have drifted out of date with that project
<jdong> chowmeined: serialmonkey's team has produced a driver that's problematic in a SMP setting
<chowmeined> well i think it was considerably more people than that
<jdong> chowmeined: the Ubuntu default kernel is SMP... which means it'll affect everyone running the generic kernel
<godlkwrth> Can anyone explain to me why the apmd init script never gets run
<chowmeined> jdong: oh.. thats right, sorry i forgot about that
<mjg59> godlkwrth: It does, so no
<godlkwrth> in feisty
<mjg59> Oh, wait. Maybe it doesn't. How odd.
<mjg59> Ah, I don't have apmd installed
<jdong> chowmeined: I hung around upstream's form a lot 2 years ago, and looked a lot at the project.... My final conclusion was that there was no real hope for unhacking those drivers for SMP support, but they needed a rewrite...
<jdong> chowmeined: seems like they're doing a rewrite and today they still have SMP problems :-/
<godlkwrth> ALSO
<mjg59> godlkwrth: Ok. If you have apmd installed, the init script it provides will be run.
<godlkwrth> is it true that /etc/hdparm.conf gets parsed everytime a harddrive is added
<mjg59> No?
<godlkwrth> apmd is installed by default
<jdong> godlkwrth: it's run once at bootup by the hdparm init script
<mjg59> As far as I know, it's only read when /etc/init.d/hdparm is run
<godlkwrth> it appears that there is udev rule that runs /lib/udev/hdparm everytime a hd device is added
<mjg59> godlkwrth: Then /etc/init.d/apmd is run by default shortly after you enter multiuser mode
<godlkwrth> just try running it
<godlkwrth> it doesn't run
<godlkwrth> there are links in rc4.d and rc5.d for it
<godlkwrth> but it doesn't work
<mjg59> godlkwrth: What do you mean, "it doesn't work"?
<jdong> I don't have an APM BIOS, so I can't run it.
<godlkwrth> these are serious problems
<mjg59> godlkwrth: What do you mean, "it doesn't work"?
<godlkwrth> and it doesn't matter what BIOS you have
<godlkwrth> try running it, it does nothing
<jdong> godlkwrth: is ACPI enabled currently?
<mjg59> godlkwrth: That means you don't have APM
<godlkwrth> every PC has APM as well as ACPI these days
<mjg59> godlkwrth: No
<jdong> godlkwrth: totally untrue
<mjg59> godlkwrth: You can't run APM and ACPI simultaneously
<mjg59> The ACPI spec explicitly prohibits that
<godlkwrth> well, ubuntu would have us
<godlkwrth> looking in the runlevel directories
<mjg59> godlkwrth: Yes. We try to run apmd, in case your system is running in APM mode.
<mjg59> If your system isn't running in APM mode, then the script does nothing.
<mjg59> The decision to run your system in ACPI mode rather than APM mode is made right at the start of kernel boot
<mjg59> So long before any init scripts are run
<godlkwrth> there are no acpi and apm "modes"
<godlkwrth> they are either supported or not
<mjg59> godlkwrth: I'm sorry, you're wrong.
<TheMuso> godlkwrth: You are talking to a guy who eats this stuff for breakfast. :)
<jdong> lol, no kidding...
<mjg59> godlkwrth: See section 15.3.1 of the ACPI 3.0 spec, for instalce
<mjg59> 15.3.1 Placing the System in ACPI Mode
<mjg59> "                                                       When control is passed to the operating system, OSPM
<mjg59> will check the SCI_EN bit and if it is not set will then enable ACPI mode by first finding the ACPI tables,
<mjg59> and then by generating a write of the ACPI_ENABLE value to the SMI_CMD port (as described in the
<mjg59> FADT). The hardware platform will set the SCI_EN bit to indicate to OSPM that the hardware platform is
<mjg59> now configured for ACPI.
<mjg59> "
<mjg59> So yes, the kernel puts the platform into ACPI mode on boot. From then on, you can't make APM calls.
<godlkwrth> modern BIOS support both, I can power off my computer with APM (if acpi isn't supported)
<godlkwrth> i.e. I start with noacpi kernel arg
<jdong> if you start with noacpi, then yeah, acpi is off.
<mjg59> godlkwrth: If the kernel never puts the system in ACPI mode, you can use APM if the platform supports it. Many modern systems don't support APM at all.
<mjg59> You can never use APM and ACPI simultaneously.
<godlkwrth> I can also poweroff my computer with APM EVEN IF ACPI is on
<mjg59> No, you can't.
<mjg59> Whatever you think you're doing, it doesn't involve APM calls.
<mjg59> You can't make APM calls if the kernel has enabled ACPI. The APM code is disabled.
<godlkwrth> you still can't explain why the script doesn't work...
<mjg59> The script does nothing because you're in ACPI mode, and so can't use APM
<godlkwrth> the script doesn't do any detection of ACPI
<mjg59> Correct. It checks for APM.
<mjg59> And you have no APM because the kernel has enabled ACPI, so won't let you use APM.
<godlkwrth> doesn't explain why the script is in the default runlevel and isn't enabled
<mjg59> It is enabled
<mjg59> It's there so that if your computer doesn't support ACPI or if you've disabled ACPI, it'll run apmd
<mjg59>         if (PM_IS_ACTIVE()) {
<mjg59>                 printk(KERN_NOTICE "apm: overridden by ACPI.\n");
<mjg59>                 apm_info.disabled = 1;
<mjg59>                 return -ENODEV;
<mjg59>         }
<mjg59> Line 2259 of arch/i386/kernel/apm.c from the kernel
<mjg59> PM_IS_ACTIVE will evaluate to true if ACPI is enabled, since switching to ACPI mode is done some time before the kernel gets around to initialising the APM code
<jdong> mjg59: I think he's saying he actually does not have an apmd script symlink in rc2.d
<jdong> which I cannot explain either -- it's default
<mjg59> jdong: Then he's deleted it
<jdong> mjg59: put plainly, yeah.
<mjg59> Or some other piece of software has. Regardless, it's not our fault :)
<jdong> mjg59: can we please set laptop-mode.conf's default -B mode when activated to something other than the most aggressive?
<jdong> mjg59: maybe a value near 200 or 150?
* mthaddon changed the topic of #ubuntu-devel to: LP going down in 15 mins for approx 1 hour for update - Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<fabbione> smurf: ping?
* mthaddon changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild!
<gilligan_> morning.. does scott james renmant, the guy behind upstart ever hang out in here ?
<Burgundavia> gilligan_: keybuk is your man, and yes
<Burgundavia> gilligan_: although upstart-devel is a probably a better place to ask questions
<gilligan_> burgundavia: ah, great..thanks ;]
<gilligan_> if only there was sucha channel ;] or where you referring to a ml ?
<Burgundavia> no worries
<Burgundavia> gilligan_: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
<gilligan_> s/where/were
<gilligan_> ah ok
<Burgundavia> figured that was the next question
<Burgundavia> gilligan_: if you are anywhere near Boston, there is an Ubuntu Development Summit next week
<gilligan_> burgudavia: i'm afraid i'm stuck in south Germany hehe
<chowmeined> so #ubuntu+1 isnt open yet?
<gilligan_> burgundavia: is there some where I could find information about how the ubuntu build system (building the actual distribution/cd-image) is implemented ? there is some info on organizational matters on the devel wiki but no technical details
<tepsipakki> asac: you probably know, but n-m has issues with ipw3945; dbus needs to be restarted after suspend/hibernate
<tepsipakki> this on a thinkpad X60
<sladen> shouldn't need to restart dbus;  just /etc/dbus-1/event.d/*NetworkManager* restart
<tepsipakki> sladen: ah, right.. good to know. Now I can't suspend anymore, though :)
<tepsipakki> works once
<sladen> sudo pmi action suspend force ?
<tepsipakki> I could suspend from the logout dialog
<sladen> click cancel, try again
<tepsipakki> hmm, now it works
<tepsipakki> I'll try reboot
<sladen> tepsipakki: sometimes somewhere in asycronous dbus message soup, there'll be a timeout
<minomit> server man ..
<asac> tepsipakki: can you please try the ~ppa3 package from my ppa?
<asac> (its technically a downgrade ... but please test it anyways)
<asac> tepsipakki: https://edge.launchpad.net/~asac/+archive
 * asac back to holiday
<tepsipakki> asac: sorry, and thanks, will try :)
<tepsipakki> it's so quiet today, so I guess pretty much everyone is having a day off ;)
<ogra_cmpc> slackers
<tepsipakki> my thoughts exactly :)
<ogra_cmpc> :)
<TheMuso> Or packing, and getting ready to fly out to the states.
<ogra_cmpc> pfft, excuses excuses
 * TheMuso is packed actually, and is working his way through merges. :p
 * ogra_cmpc will pack tonight
<siretart> http://archive.ubuntu.com/ubuntu/dists/gutsy-{updates,security,backports}/Contents-i386.gz is missing. is this intended or a (known) bug?
<bryang> probably something simple, but -- what exactly triggers update-manager on say feisty to know that gutsy upgrade is available (for some reason when pointing to a local full mirror, clients don't see this), yet pointed to a archive.ubuntu.com mirror triggers this ?
<zul> is there going to be voip again for uds again?
<Hobbsee> zul: i hope so.  Spads should know.
<Hobbsee> it's going to be a problem if it doesnt.
<Hobbsee> bryang: i'd guess it's the published release announcement.
<Hobbsee> bryang: (on archive.ubuntu.com, but probably not mirrored to your mirror)
<bryang> Hobbsee: what file(s) would that be ?
<Hobbsee> i dont remember.  i don't know enough about it :)
<bryang> fwiw, I mirror (via rsync) archive.ubuntu.com::ubuntu (so pretty much everything)
<Hobbsee> mvo would be able to tell you
<Hobbsee> but not for the next few days.
<Hobbsee> (oh, yes, that's where all the canonical people are)
<bryang> okay, thnx Hobbsee
<bddebian> Heya
<OldPink> Guys, I've fixed a reported bug on launchpad. It's my first time doing this, and have uploaded all resources and information to apply the fix. Who do I notify/what do I do to get it included in Gutsy/Hardy? See: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/155436
<ubotu> Launchpad bug 155436 in linux-source-2.6.20 "iPod won't mount in Gutsy on 2.6.20-16 kernel" [Undecided,Fix committed]
<ScottK> OldPink: 2.6.20 isn't the Gutsy kernel.  Try #ubuntu-kernel.
<OldPink> ScottK: Thanks, I'm already there. Just excited about getting my first bugfix in :P
<blueyed> Can somebody pretty please approve the nomination for gutsy SRU on bug 149641? Without the Gutsy task it does not appear in ubuntu-sru's list and the noise (users complaining) won't get less when waiting longer. The fix is quite simple and taken from upstream/Debian.
<ubotu> Launchpad bug 149641 in logcheck "logcheck fails when auth.log.1.gz missing" [Undecided,Fix released] https://launchpad.net/bugs/149641
<blueyed> It would be great if someone even would sponsor the upload right away.. :)
<ScottK> blueyed: You ought to subscribe ubuntu-main-sponsors to the bug if you haven't.
<blueyed> ScottK: ok, done. I've thought that it would have to get approved by ubuntu-sru before..
<blueyed> ..and the nomincation approved.
<ScottK> blueyed: Ah.  Didn't realise it was an SRU.  Nevermind.
 * ScottK should read more carefully.
<PhinnFort> which package contains debugging symbols for dolphin?
<PhinnFort> I'm experiencing some crashes related to the fish-protocol
<ogra_cmpc> there are usually -dbg packages for all apps
<PhinnFort> not dolphin, the default file manager in kubuntu
<PhinnFort> so I suspect they've crumpled it together into kdebase-dbg or something
<ogra_cmpc> yeah, kde packqaging is sometimes a bit confusing
<PhinnFort> you don't say...
<PhinnFort> partly blame on the kde devs, who send out large bundles with apps, which have to be split
<ogra_cmpc> yeah
<Amaranth> !debug
<ubotu> For help debugging your program, please see https://wiki.ubuntu.com/DebuggingProcedures
<Amaranth> PhinnFort: https://wiki.ubuntu.com/DebuggingProgramCrash
<PhinnFort> Amaranth: thanks
<IntuitiveNipple> Anyone familiar with the inner workings of gtk+2.0, and object memory allocation (on x86_64) ?
<slangasek> how "inner"?
<IntuitiveNipple> very :) see my last comments on bug #124336 - there appears to be a random issue with the pointer returned by gtk_list_store_new() being invalid and causing a segfault. I'm building a modified gtk+2.0 now to try and pinpoint it, but was hoping to get some suggestions or clues as what to look for.
<ubotu> Launchpad bug 124336 in network-manager-applet "nm-applet crashed with SIGSEGV in gtk_combo_box_set_model" [Medium,Confirmed] https://launchpad.net/bugs/124336
<slangasek> IntuitiveNipple: I expect the problem is not that the pointer is invalid, but that it's being stored in an incorrect type; this is a common error
<slangasek> IntuitiveNipple: particularly with gtk, which inherited a type system from gtk 1.2 where it was valid to use "int" and "GType" interchangeable
<slangasek> y
<IntuitiveNipple> Thanks... that makes sense based on my instinct, although I'm having a hard time finding an argument as to why it is so random
<IntuitiveNipple> I was looking for 32-bit/64-bit size issues but not found any so far in nm-applet
<IntuitiveNipple> I've just added a further comment which shows the pointer values returned by gtk_list_store_new() - does that give any clues?
<slangasek> IntuitiveNipple: for starters, could you try using %p to print the pointer values instead of %lX?
<IntuitiveNipple> I prefer lX when I'm not sure of the size of the values, but sure
<slangasek> well, for one thing, %lX is a signed integer, which gives confusing output for pointers :)
<IntuitiveNipple> Here's the output: http://pastebin.intuitivenipple.net/80
<slangasek> fun
<Chipzz> IntuitiveNipple: I think all hell would break loose if what you're saying is actually correct
<IntuitiveNipple> Chipzz: Well, it's happening for quite a few people using 64-bit, but not for 32-bit... I've been seeing it for several months but assumed someone else had fixed it during development.
<Chipzz> IntuitiveNipple: if what you're saying would be true, just about every gtk app in ubuntu would be crashing
<Chipzz> so, not very likely :P
<IntuitiveNipple> I'm not 'saying' anything yet, I'm looking at the symptoms and trying to pinpoint the fault
<IntuitiveNipple> The essence of it is, the fault almost always occurs but seems less-frequent when there's debugging code inserted (which could imply a timing issue of some kind). First time I built a debug-version of nm-applet I couldn't get it to fail.
<Company> IntuitiveNipple: i would blame gtk_list_store_set()
<IntuitiveNipple> Company: Once I've got the debug libs ready, hopefully it'll shed some light on it
<IntuitiveNipple> Company: There are some memcpy() calls that depend on a sizeof() in gtk_list_store_set_n_columns() - I'll keep an eye on them
<Company> IntuitiveNipple: that and gtk_list_store_set is a varargs function
<slangasek> IntuitiveNipple: har. prototype for wso_wpa_create_phase2_type_model is missing
<slangasek> IntuitiveNipple: if you check the build log, I expect you'll see "warning: conversion makes pointer from integer without a cast"
<IntuitiveNipple> you're kidding!?
<Company> ouch
<Company> missing include :(
<slangasek> IntuitiveNipple: nope.  I just stepped through the code, wso_wpa_create_phase2_type_model returns the right value and then it gets corrupted in the assignment
<slangasek> Company: missing prototype; there's no include in the tree that defines this function
<IntuitiveNipple> Gotchya! well spotted
<Company> slangasek: that's even worse
<IntuitiveNipple> Hmmm, that doesn't explain why the value reported *inside* wso_wpa_create_phase2_type_model() is incorrect also when the segfault occurs
<slangasek> AFAIK the segfault doesn't happen inside type_model() though?
<IntuitiveNipple> No it doesn't, well not so far!
<IntuitiveNipple> I'll add the prototype and see how we go. It doesn't surprise me since that function looks to be a copy/paste of wso_wpa_create_key_type_model()
<IntuitiveNipple> I've added it to wso-private.h, now to test
<slangasek> wso-wpa-eap.c: In function 'wso_wpa_eap_new':
<slangasek> wso-wpa-eap.c:296: warning: implicit declaration of function 'wso_wpa_create_phase2_type_model'
<slangasek> yep, there it is. :)
<slangasek> wso-wpa-eap.c:296: warning: assignment makes pointer from integer without a cast
<IntuitiveNipple> I missed that in all the fuzz. I'm so used to so many releases being shipped with warnings I rarely check them anymore
<IntuitiveNipple> It seems to be working, I'll attach the patch to the bug report
<slangasek> yep, looks fixed here too
<IntuitiveNipple> Thanks for that... saved me a lot of messing about. I wonder why the pointers look different inside the function though.
<slangasek> such as?
<slangasek> as for shipping with warnings - yes, remembering to look for this stuff in build logs when dealing with 64-bit bugs is an important lesson, one I haven't yet internalized myself :)
<IntuitiveNipple> slangasek: The pointers reported just prior to the segfault are like 0x2aaab003eeb0 whereas when it doesn't segfault they're like 0xcf9e10, and that is reported from *inside* wso_wpa_create_phase2_type_model()
<slangasek> IntuitiveNipple: I'm pretty sure you'll find that those two values don't correspond to the same iteration
<slangasek> 0x2aaab003eeb0 is a reasonable pointer value on amd64, but doesn't survive pointer->int->pointer conversion
<slangasek> 0xcf9e10 is also a possible pointer value; it could also be a truncated value which happens to look saner than the others because it was sign-extended with 0s in the high bits instead of 1s
<IntuitiveNipple> They're both 'proper' pointers without any conversion going on at the point they are reported (unless printf("... %p"...) is doing something
<slangasek> ok. then mainly that just points to the allocation happening in different memory blocks each time, for no particular reason other than what memory was available at the time for use in malloc()
<IntuitiveNipple> It seems to be fixed anyhow :) Yeah, somehow the allocation location being 'high' looked to be upsetting it
<slangasek> sure, because that's the case where pointer->int->pointer breaks
<slangasek> (specifically, it breaks whenever you have bits above bit 31 set)
<IntuitiveNipple> is there a tag (for launchpad) along the lines of needs-packaging to notify the core-devs the package needs updating?
<slangasek> (numbering the bits from 1, that is -- bits above 32 break because they're lost to truncation, bit 32 itself breaks because int->pointer results in sign extension)
<slangasek> IntuitiveNipple: I believe the procedure is to prepare a package, send the debdiff to the bug, and subscribe ubuntu-main-sponsors
<tepsipakki> slangasek: hey, you have archive-admin powers? If you have time, would you care to do some syncs so xorg-server could get built?
<slangasek> tepsipakki: afraid I don't have time at the moment
<tepsipakki> slangasek: ok, no worries
<gspr> If I have found a bug in a package, and a patch that at least works around it, should this be reported to Launchpad, or should I contact the package maintainer directly?
<chowmeined> put the bug on launchpad and link it to the maintainer's bug tracker, then submit the patch to the maintainer
<chowmeined> thats my guess
<gcarrillo> hi
<gcarrillo> general question: is installing the foo-dev packages the same as downloading the source for the foo project?
<gcarrillo> such that by installing the foo-dev package, i can cd to a well known location in the filesystem to work on that proj's source?
<slangasek> no
<slangasek> -dev packages generally contain the headers, symlinks, and static libs that you need in order to develop /against/ the package in question
<gcarrillo> oh i see
<gcarrillo> oh right
<gcarrillo> there should be a seperate package for the source i suppose
<gcarrillo> thanks
<gcarrillo> is there a channel for application development?
<gcarrillo> i see that this is not it in the title ;)
<slangasek> not an Ubuntu-centric one, that I know of
<gcarrillo> i'll try ##linux-coders on this server
<gcarrillo> looks about right
#ubuntu-devel 2007-10-26
<theacolyte> Interesting, may have found a security hole, maybe not
<theacolyte> Using the built-in desktop sharing feature, the password authentication feature does not work
<theacolyte> The client asks for a password, but the password fails auth
<theacolyte> The ONLY way it works is without a password
<gcarrillo> hey guys
<gcarrillo> if im running gutsy and i installed the pidgin-dev packages
<gcarrillo> and downloaded the pidgin source
<gcarrillo> i can expect it to build correctly right?
<gcarrillo> You must have libxml2 >= 2.6.0 development headers installed to build.
<gcarrillo> i get that message
<crimsun> no.  apt-get build-dep pidgin.
<gcarrillo> cool, let me try that
<crimsun> (you've mistaken pidgin-dev for pidgin-dev's build-dependencies.)
<gcarrillo> i see
<gcarrillo> that's pretty cool
<gcarrillo> crimsun: that worked, thank you
<crimsun> np.
<DShepherd> when are the gnome 2.20.1 updates going to hit the ubuntu repos?
<sebastian^> good morning folks :)
<pwnguin> interesting.
<pwnguin> google fixed liferea
<xivulon>  I am getting closer to wubi-7.10 release, would you guys mind testing it? http://wubi-installer.org/devel/minefield/
<xivulon> Please make any comment on http://ubuntuforums.org/forumdisplay.php?f=234
<annma> hi people
<annma> anyone is already in Boston?
<jordi> crimsun: ping
<Tonio_> archive admin available ?
<Hobbsee> Tonio_: very unlikely, what were you after?
<Tonio_> Hobbsee: about ppa, isn't there a way to drop a package ?
<Tonio_> Hobbsee: searched for that option for hours without any success
<Hobbsee> Tonio_: no.  ask in #launchpad, usually, and they can do it, or file a launchpad question on soyuz
<Hobbsee> archive admins cant do it
<Hobbsee> or just upload a newer version
<Hobbsee> apparently we're supposed to get it partway thru this cycle.  but they originally said with the rollout yesterday - so who knows when it will *actually* get done.
<Tonio_> Hobbsee: I hope the option is comming along in the next future
<Tonio_> Hobbsee: thanks for the infos :)
<Hobbsee> Tonio_: no problem
<_mastro_> guys.. i've this bug: https://bugs.launchpad.net/bugs/157286 and i want to recompile my kernel without libata to see if i'm right supposing the problem is there... i've downloaded the kernel source (apt-get install linux-source-2.6.20-generic) make menuconfig starting from my actual 2.6.20-generic configu and changed: cpu optimization (Pentium 4), removed new libata support from device driver and readded the depr
<_mastro_> ecated old sata support i compiled with fakeroot make-kpkg --initrd .... linux_image linux_header) installed the deb packages and rebooted.. after the initrd image when it should start reading from this it don't do anything else... it stay there forever until i hit CTRL+ALT+CANC what's wrong??? i've compiled a lot of kernel on debian without having this issue... what am i missing?
<ubotu> Launchpad bug 157286 in ubuntu "System really slow like if no DMA from Edgy" [Undecided,New]
<bddebian> Heya
<TheNewAndy> I have a patch for apt-url which I think others might find useful, but I'm not
<TheNewAndy> so familiar with how to go about getting it reviewed/accepted.
<TheNewAndy> I imagined that posting it as a 'bug' on launchpad would be the best way
<Hobbsee> TheNewAndy: have a look at https://wiki.ubuntu.com/MOTU/Contributing
<TheNewAndy> but launchpad says that it doesn't use the launchpad bug tracker
<_mastro_> please can you help me debug a kernel problem with ubuntu? i've custom compiled it removing the new sata/pata architecture from device driver (the one that make /dev/hda become /dev/sda) but when i try to boot it stop right after the initrd image, when it should start reading from disk, it stop there and the only thing i can do is pressing CTRL+ALT+DEL and choose another kernel
<mdomsch> is there a specific package owner for each package in main?
<Hobbsee> mdomsch: some of them.  not all.
<persia> mdomsch: Not exactly.  Many people focus on a few packages, and some teams claim some packages, but it's not a one-to-one mapping.  For each package, there is at least one assignable person.
<Hobbsee> mdomsch: looking at who's uploaded it recently should give you an indication
<mdomsch> Hobbsee, where do I see who uploaded a package?
<mdomsch> I see the Maintainer line (e.g. if it came straight from Ubuntu) in the control file
<Hobbsee> mdomsch: aptitude changelog <packagename>
<Hobbsee> mdomsch: you can query launchpad about it, or you can also look up changelogs.ubuntu.com
<Hobbsee> the first and third tend to be quicker.  teh first is my preference.
<mdomsch> but the name in the changelog is who made the change, not necessarily who uploaded into Ubuntu
<mdomsch> e.g. the hwdata package
<mdomsch> but that's a fair start
<Hobbsee> mdomsch: ah, true
<Hobbsee> mdomsch: if you want to know who actually uploaded it (and keep in mind, it's the person in the changelog if they're a core dev), go to lists.ubuntu.com/<release>-changes, and decrypt the gpg key :)
<Hobbsee> havent found a faster way than that
<Hobbsee> LP may show the info now.  they keep swapping what they do and don't show.
<Hobbsee> mdomsch: by version number, hwdata looks synced.
<Hobbsee> the autosyncer is on from that point, so it's likely from that.
<mdomsch> Hobbsee, it's synced to debian, but debian pulls from fedora
<Hobbsee> (some of the maintainers of main packages are in debian, not ubuntu)
<Hobbsee> mdomsch: right.  ie, fedora-specific stuff?
<mdomsch> that's fine, thanks.  I'm just trying to get some coordination around this package
<mdomsch> and understand who the players are
<Hobbsee> ah, right
<mdomsch> Fedora generates the package, debian pulls it, ubuntu pulls from debian
<Hobbsee> mdomsch: for that one, looks like fedora and debian.  doesnt look like nayone from ubuntu specifically is touching it :)
<Hobbsee> yup
<Hobbsee> or, at least, until the autosync gets turned off.
<mdomsch> so I can either poke 3 distros to add a pile of monitors, or I can get it into fedora and wait
<Hobbsee> probably.
<Hobbsee> it's not that hard to push, if you want to get it here.  no idea about debian.
<Hobbsee> of course, they might look favorably if you say who you are, and such :)
<Hobbsee> and go "he must know what he's talking about.  we'll take it"
 * mdomsch emailed noel@debian about how he does it
<Hobbsee> cool
<Hobbsee> dude, this downloading at 0.9kBps is *not* cool!
<Hobbsee> s/kBps/KBps/
<mdomsch> I've got a little script that downloads all the new monitor files from support.dell.com every week, and generates diffs against Fedora and Ubuntu now
<Hobbsee> nice!
<Hobbsee> mdomsch: like i say, if you know what you're doing, it's not hard to get sponsorship into main.
<mdomsch> so folks won't be able to complain that their newest 2407WFP-HD monitor isn't listed in displayconfig-gtk
<Hobbsee> so you dont have to wait for all 3 distros
 * Hobbsee nods
<Hobbsee> i'm impressed - ubuntu actually detects my correct monitor, now!
<Hobbsee> first release!
<ScottK> Hobbsee: Does Kubuntu benifit from this too or does it use another list?
<Hobbsee> it's only taken since edgy.
<Hobbsee> ScottK: no idea, tbh.  i think it uses another list.  i think it's also buggy, so no one uses it.
<Hobbsee> ScottK: 915resolution is what i've used in the past, just to make the screen readable, without me gouging my eyes out
<ScottK> Bummer.
<Hobbsee> pity mdomsch didnt show up a couple of releases ago.  i could have hounded him to fix ti :)
<mdomsch> hehe
<Hobbsee> (while it was still broken)
<Hobbsee> speaking of which, i should find another battery at some point.
<Hobbsee> not worth it at this point in the year, though
<Hobbsee> mdomsch: maybe i'll just blame you anyway.
<ScottK> Hobbsee: Getting to a common list (or Kubuntu can also understand the Ubuntu list) would seem like a worth Kubuntu feature goal.  Particularly for an LTS release ...
<Hobbsee> ScottK: it would be useful if it actually used the displayconfig backend.  but i've no idea how much common code there is.
<Hobbsee> X, and display related stuff is not my forte - i tend to stay away, so it doesn't break.
 * ScottK knows there is some because in Feisty there were some conflicts.
 * ScottK too.
<Hobbsee> ScottK: i'm deeply unimpressed about how i cant seem to remove the xserver-xorg-video-i810 stuff without X breaking, though.
<Hobbsee> i seem to need both that and -intel.
<Hobbsee> or at least, under kubuntu i do.
<tepsipakki> that's true
<Hobbsee> last i knew, they conflicted, so...
<Hobbsee> or i'm remembering wrong :)
<Hobbsee> tepsipakki: why?
<tepsipakki> well, -intel has issues with some chips
<tepsipakki> so -i810 is still here
<tepsipakki> and the dependancy chain goes up to {k,}ubuntu-desktop, so removing the metapackage would mean removing -desktop as well
<Hobbsee> tepsipakki: i seemed to be able to remove it with great problem - i just had no X :)
<tepsipakki> fingers crossed that we actually can drop -i810 during hardy :P
<tepsipakki> oh
<Hobbsee> tepsipakki: or is 965 an issue-filled chip?
<ScottK> tepsipakki: So my 2 year old hardware will become unsupported?
<Hobbsee> er, without great problem
<tepsipakki> ScottK: which is that?
<tepsipakki> ScottK: debian doesn't have -i810 since -intel 2.0 came out
<ScottK> OK, so i810 is supported in that?
<tepsipakki> ScottK: sure, every chip, but some of them have issues
<tepsipakki> Hobbsee: how does it break?
<ScottK> tepsipakki: OK.  I know almost nothing about video, so I get excited when I see talk of what looks like removing support for what I have.
<tepsipakki> heh
<tepsipakki> Hobbsee: speaking of which, you are an archive-admin?-)
<Hobbsee> tepsipakki: i get dropped at a console, with no X.  i don't remember more specifics than that, as it was a while ago.
<Hobbsee> tepsipakki: FSVO archive admin, yes.
<ScottK> FSVO?
<Hobbsee> for some value of
<tepsipakki> Hobbsee: so you can't do syncs?
<ScottK> Ah.  Yes.
<Hobbsee> tepsipakki: correct.
<tepsipakki> bummer
<Hobbsee> yeah, i know.
<tepsipakki> great that the archive is open, but a first batch of syncs would've been equally nice :)
<tepsipakki> Hobbsee: do you happen to have "i810" in xorg.conf, instead of "intel"?
<Hobbsee> tepsipakki: yeah.
<Hobbsee> tepsipakki: buildds still have plenty to build, due to the autosync.
<Hobbsee> but i'd imagine it'll take a couple of weeks
<Hobbsee> (conferences and such)
<Hobbsee> ah, this one is using intel.
<tepsipakki> they do? I see that the new xserver is being rebuilt (and failed) on and on :)
 * Hobbsee wonders why she has an xorg-ati installed
<Hobbsee> ahhh
<Hobbsee> well, they did last i checked
<Hobbsee> tfheen: may be around
<Hobbsee> but i think he's in the air by now
<zul> tepsipakki: well it is a new dev cycle :)
<tepsipakki> Hobbsee: you probably have all that xserver-video-all depends on :)
<tepsipakki> zul: ah, the pain! :)
<Hobbsee> tepsipakki: yeah.  but cant it pick my card, and deal?
<Hobbsee> tepsipakki: it's not like i'm going to swap out my video card :)
<tepsipakki> Hobbsee: not yet, but it'll be discussed at FOSSCamp & UDS
<Hobbsee> xserver-xorg depends on it
<Hobbsee> tepsipakki: cool :)
<tepsipakki> autoloading based on the pci-ids that the drivers have
<Hobbsee> tepsipakki: can i safely remove the rest?
<tepsipakki> yes
<tepsipakki> but it'll save you like 2MB :)
 * Hobbsee shrugs
<antoranz> Hi guys! I'm having problems linking (static) to libalsa09.a
<antoranz> can anybody give me a hand here?
<antoranz> forget it... the channel is not for application development under ubuntu... but maybe the problem is raleted to ubuntu
<antoranz> in the SYMBOL of libalsa09.a (from the libao-dev package), snd_pcm_open (and close) are undefined (I think). Is that normal?
<antoranz> SYMBOL TABLE; I mean
<ScottK> Hobbsee: Are universe packages being allowed to build right now?
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_format
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_channels
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_rate_near
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_buffer_time_near
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params_set_period_time_near
<Hobbsee> ScottK: i think so
<antoranz> 00000000         *UND*  00000000 snd_pcm_hw_params
<Hobbsee> !paste | antoranz
<ubot3> antoranz: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<ScottK> Hobbsee: OK.  Thanks.
<ScottK> For both the answer and the kick.
<Hobbsee> ScottK: no reason why they wouldnt be
<ScottK> OK.  I've got stuff that's been sitting around for a long time, but no trouble.
<persia> ScottK: Main autosync gets priority...
<ScottK> OK.  That'd do it.
<Adri2000> soren: are you going to re-merge pbuilder? (we need the new version to fix a pbuilder-dist bug), or can I do it? (I'll ask you to upload it for me then :))
<ScottK> Adri2000: That or just make it work with the current pbuilder.
<Adri2000> ScottK: ah. I'm still waiting for your solution
<ScottK> Adri2000: Make the authoritative source for the package one I can use and I'll be glad to.
<Adri2000> I'm not sure to understand what you mean
<ScottK> Adri2000: You keep that package in a bzr repo and I don't do bzr.  I'm not learning a new vcs to fix a bug.
<Adri2000> ScottK: http://adrishost.homeip.net/~adri2000/ubuntu/pbuilder-dist
<ScottK> What about it?
<Adri2000> wget it, cp it, edit the new one, diff it with the new one you edited to create a patch you can give me
<glledo> has somebody noticed in Gutsy that Firefox -> Help -> Release Notes pops up Edgy release notes?
<mdke> glledo: the only way to find out for sure is to search for a bug
<glledo> didnt find any
<glledo> ok, lets submit it
<mdke> then I suspect that no one has
<glledo> doh, bug 140998
<ubotu> Launchpad bug 140998 in firefox "Firefox: View Source > Help > Release Notes links to Edgy release notes in Feisty and Gusty (dup-of: 138968)" [Undecided,New] https://launchpad.net/bugs/140998
<ubotu> Launchpad bug 138968 in ubufox "The Release Notes Menu on firefox shows ubuntu 6.10 notes" [High,Fix committed] https://launchpad.net/bugs/138968
<Kopfgeldjaeger> hi
<warsocket> Does anyone here how to hide the output from checkinstall when callled in a c program  via system("checkinstall args > /dev/null"); or popen("checkinstall args"));
<ion_> fork, close stdout, open /dev/null, exec. Now please read the topic.
<warsocket> kk tnx
<IntuitiveNipple> Anyone about can give me some quick guidance for doing SRU updates for hardy and gutsy-proposed ?
<LaserJock> IntuitiveNipple: you won't be doing an SRU for hardy
<LaserJock> IntuitiveNipple: and for Gutsy have a look at https://wiki.ubuntu.com/StableReleaseUpdates
<IntuitiveNipple> well no but... step #1 is to create an update for hardy, then one for gutsy-proposed
<IntuitiveNipple> I am doing/have done... my questions are more about technicalities
<LaserJock> ah, well yes, you want to make the changes first in Hardy usually
<LaserJock> IntuitiveNipple: ask away and see if anybody knows
<IntuitiveNipple> like... is it a case of simply adjusting the changelog entry to read "gutsy-proposed" for the SRU, or does control need some kind of change too?
<_bernie> hello, I'm looking at the Boston UDS info in the wiki
<LaserJock> IntuitiveNipple: changelog
<IntuitiveNipple> I was looking at the emails in gutsy-changes and they show the 'gutsy-proposed' that makes it look like it came from 'control' not changelog, so I was somewhat confused
<_bernie> I can't find a more a more specific agenda...
<IntuitiveNipple> oh good. So, are these steps correct?
<IntuitiveNipple> 1. grab the latest source package from the hardy repo, apply the changes, create the debdiff
<LaserJock> _bernie: http://people.ubuntu.com/~scott/uds-boston-2007/
<IntuitiveNipple> 2. grab the latest source package from gutsy-proposed (or, if there isn't one) gutsy, apply the changes (make sure changelog is for gutsy-proposed and LP # is quoted), then create the debdiff
<_bernie> thanks
<_bernie> LaserJock: is there anything planned for 27 and 28?
<LaserJock> I don't think so
<IntuitiveNipple> 3. Upload both to the LP bug with a rational for why and then Nominate it for release?
<IntuitiveNipple> s/rational/rationale/
<LaserJock> IntuitiveNipple: I would get the fix into hardy first
<LaserJock> make sure it works
<LaserJock> then file the SRU
<LaserJock> but basically you're on the right track
<IntuitiveNipple> In these two cases I know they work on Gutsy.
<_bernie> mako_: hey!
<_bernie> mako_: are you going to attend to UDS?
<IntuitiveNipple> LaserJock: What's the procedure for testing them with Hardy if I'm not running a Hardy install?
<LaserJock> IntuitiveNipple: you can use a chroot or pbuilder environment
<LaserJock> or VMware, VirtualBox, etc.
<IntuitiveNipple> ahh of course... pbuilder! I've got them set up for every other release, but I'm on the kernel ACPI team so I rarely stray into packaging... but I'm hacking a few bugs atm
<LaserJock> IntuitiveNipple: one of the reasons to test in Hardy first is typos or packaging mistakes
<IntuitiveNipple> LaserJock: I assume the same applies to testing in Gutsy then? Especially when the changes are trivial
<IntuitiveNipple> I've just spent the afternoon writing a script to automate package-updates into two commands after discovering what a minefield it is!
<LaserJock> IntuitiveNipple: yes, even more so in gutsy-proposed
<IntuitiveNipple> Right... I'll crack on with these debdiffs now ... thanks alot :)
<mako_> _bernie: yes, i will attend uds
<theacolyte> Interesting, may have found a security hole, maybe not -- Using the built-in desktop sharing feature, the password authentication feature does not work -- The client asks for a password, but the password fails auth -- The ONLY way it works is without a password
<_bernie> mako: I'm trying to devide which days to go... do you have any particular plans?
<mako> _bernie: i haven't figured it out yet
<mako> but i haven't really looked much either
<Mez> mako *hugs* long time no see
<Nafallo> theacolyte: sounds like a fault in the client.
<Nafallo> theacolyte: try with another client.
<mako> Mez: i'm around
<Mez> mako, still with OLPC?
<theacolyte> Nafallo: already did, realvnc and ultravnc
<mako> Mez: yep
<Mez> good to hear ;)
<sbalneav> Up at 0500 tomorrow, on the plane by 7:30, at Boston by 14:00
<sbalneav> mako: What's the quickest way from Logan? Subway or Taxi?
<mako> sbalneav: quickest? taxi
<mako> sbalneav: like $25-30
<mako> sbalneav: alternately take the silver line and red line.. i think i edited the wiki directions
<mako> it's not really that much longer
<sbalneav> cool.
<sbalneav> thx
<wasabi> I notice apport stopped asking me to submit things, a month ago.
<LaserJock> wasabi: I think they turned that off for release so the general user population wasn't bugged about it
<LaserJock> and we didn't get a flood
<wasabi> Ahh.
<Nafallo> theacolyte: weird
<IntuitiveNipple> Yeah, bug #137406 (and duplicates) covers it. I *had* created a patch but some random search earlier dropped me on an email from Matt Z detailing why it was disabled for R.C.
<ubotu> Launchpad bug 137406 in update-notifier "apport stopped working" [Low,Won't fix] https://launchpad.net/bugs/137406
<theacolyte> I'll just put in a bug report probably
<evan_pi> I just created a blueprint for simplifying the Removable Drives and Media window, and the feature specifications page said I should announce it here.
<evan_pi> The window currently requires the user to enter the bash command of the program. This is complicated for new users, who don't know the first thing about the cli. I propose that it be updated to use gui drop-down lists like in the Preferred Applications window.
<evan_pi> The spec is at https://blueprints.launchpad.net/ubuntu/+spec/simplify-removable-drives-and-media
<evan_pi> Is anybody out there?
<LaserJock> evan_pi: I think it probably meant the ubuntu-devel mailing list
<LaserJock> evan_pi: or maybe better ubuntu-devel-discuss
<evan_pi> It mentioned the devel-discuss mailing list and the irc channel
<LaserJock> ok :-)
<IntuitiveNipple> Is this correct? "apt-get source -t hardy <package>" fetches the gutsy source even though the hardy repositories are enabled in /etc/apt/sources.list
<Amaranth> IntuitiveNipple: Isn't it 'apt-get source foo/hardy'?
<IntuitiveNipple> is it?
<Amaranth> I believe so
<IntuitiveNipple> I was going by the man pages and the --help
<IntuitiveNipple> no, that doesn't work
<IntuitiveNipple> It *seems* as if it fetches the source for the installed binary version, regardless
<LaserJock> actually
<LaserJock> I think it grabs it from the first deb-src it finds
<LaserJock> unless that bug has been fixed, which is possible
<IntuitiveNipple> That's very annoying - is there an alternative way to automatically find the location of a source package that isn't currently installed/part of the current release?
<IntuitiveNipple> All I want to do is automate generating the debdiffs for hardy and gutsy-proposed, grrr
<geser> IntuitiveNipple: I tried it here and "apt-get source -t hardy package" (or -t gutsy) behaves as expected
<IntuitiveNipple> really? what've you got in your /etc/apt/sources.list ?
<geser> IntuitiveNipple: does the package has an other version in hardy already?
<IntuitiveNipple> There's one version in hardy repos
<IntuitiveNipple> I wonder if it is because i've only added the deb-src lines to sources.list
<geser> IntuitiveNipple: see my test in http://paste.ubuntu-nl.org/42289/
<geser> IntuitiveNipple: I've also only added the deb-src line, run apt-get update and it worked
<IntuitiveNipple> that's what I did here, too
<geser> IntuitiveNipple: which package do you try?
<IntuitiveNipple> update-notifier (devscripts works for me too)
<IntuitiveNipple> It is apparently there: http://packages.ubuntu.com/hardy/source/update-notifier
<geser> yes, as hardy starts as a copy of gutsy
<geser> currenty gutsy and hardy has update-notifier 0.61
<IntuitiveNipple> hmmm... why would apt-get fetch from gutsy's location if one exists for hardy? Is it some kind of bug in the releases files do you think?
<geser> no, but does it matter if you get the source for 0.61 from gutsy or hardy (they should be identical)
<LaserJock> I think it picks from the earlist source if there's more than one
<LaserJock> it is the same files
<IntuitiveNipple> The changelogs should have different 'release' strings, and that's crucial for what I'm doing
<LaserJock> no, they don't
<LaserJock> the changelog will only change with a new upload
<IntuitiveNipple> ahhh.
<geser> there was no upload of update-notifier for hardy till now (only the archive copy from gutsy)
<LaserJock> with a pool archive structure for a given version the files are all the same, regardless of release
<IntuitiveNipple> ok, so help me understand this. Why does apt-get fetch from the gutsy repo - presumably there's something in the sources files that is over-riding my using the -t release-target
<IntuitiveNipple> ahhh... so what you mean is, it's linked on the server?
<LaserJock> that's all they do
<IntuitiveNipple> hmmm but that still doesn't explain why apt-get fetches from the hardy repo
<LaserJock> point to where in the pool you can get the file
<geser> I guess because it sees that it can fetch the hardy version also from the gutsy archive which is listed before the hardy one
<IntuitiveNipple> hmmm
<IntuitiveNipple> geser: that'd suggest re-ordering the deb-src lines might affect it... worth a try
<SEJeff> IntuitiveNipple, If the versions are the same, why generate a debdiff? It seems like maybe you are doing something wrong?
<LaserJock> I think it doess affect it, last I tried
<IntuitiveNipple> Nice one geser! Re-ordering the deb-src lines in sources.list so hardy is first has solved it
<LaserJock> I agree with SEJeff
<IntuitiveNipple> SEJeff: I'm automating my debdiff patch-creation procedure so once I've solved a bug I call a script and it does the job for me, including updating the changelog, version, release to release-proposed (for SRUs), and so on
<IntuitiveNipple> So I need the current source, dupe it, apply the patches, update the changelog, debuild, then create the debdiff
<SEJeff> Which means you should increment the version
<SEJeff> Like 1.2.3-2 or -ubuntu0 or whatnot. The versions still are not the same
<IntuitiveNipple> The version wasn't a problem, the problem was apt-get was ignoring the -t option and it seems, from what geser suggested, that the order of the deb-src lines in sources.list affects that... and now it appears to be solved
<SEJeff> So it doesn't make sense that downloading a package of the exact same version from one or the other repo should matter.
<SEJeff> If I download sysutils 1.0 from the gutsy or hardy repo, it is still the same source
<SEJeff> (pretend that is a valid sysutils ver)
<IntuitiveNipple> It does, because although for that specific package the contents are identical, I need to be sure the script will work for all circumstances
<SEJeff> Use case of why it would break being?
<SEJeff> This seems like a process problem that you can fix with error checking and defensive programming to me.
<SEJeff> IntuitiveNipple, Your idea is really cool though. A lot of people would appreciate it
<LaserJock> IntuitiveNipple: your real question is if -t is respected if they *aren't* identical packages
<SEJeff> LaserJock, And if they aren't identical packages + the version number is the same, an MOTU should be flogged :)
<LaserJock> SEJeff: sure, but I think he's wanting non-identical version numbers
<IntuitiveNipple> SEJeff: The process for bug-fix updates, as explained to me, is to first create a fix for the developmeny release (hardy) which might or might-not have the same version as gutsy (doesn't matter if it does or doesn't), then do the same for gutsy-proposed and create an SRU. My script reduces the packaging step in each case to two commands.
<IntuitiveNipple> LaserJock: The path used by apt-get is now reported as being hardy when i use -t hardy so I'm happy - as long as it is consistent
<SEJeff> ok
<LaserJock> IntuitiveNipple: I don't want to necessarily discourage you, but that sounds like a really bad idea :-)
<SEJeff> *nods*
<LaserJock> SRUs need lots of focused attention to every detail
<geser> IntuitiveNipple: I guess "apt-get source -t gutsy update-notifier" tells you that it got it from hardy now.
<LaserJock> and there's no way that a bug fix in hardy will apply the same to gutsy, etc.
<LaserJock> so I would really discourage automatic SRU scripts
<IntuitiveNipple> All I do now is "debdiff-package.sh [-g <package> [-t release] [--proposed] [-b base-dir]]", apply the fixes to the source, and then do "debdiff-package.sh" and it does the whole job for me
<IntuitiveNipple> geser: Grrrr yes!
<crimsun_> jordi: pong
<IntuitiveNipple> LaserJock: The two releases are dealt with separately, totally independently - two passes of the process
<LaserJock> right, but still
<LaserJock> so  you script changes the version and release, and makes a debdiff, and that's all?
<IntuitiveNipple> I simply take the patch from my development tree, apply it to the source, and it gets packaged. I will do that for hardy and again for gutsy-proposed, with two sets of testing. But the script saves me messing about on the command-line
<LaserJock> so it doesn't do any more than I mentioned?
<IntuitiveNipple> It fetches the current source, dupes to the .orig directory, stops to let me apply the changes, then runs diff, asks for the patch title, suggested the name of the patch-file, runs dpatch, then updates the changelog version and possibly release (to -proposed) and asks me for the filenames and description of each change which it formats and adds to the changelog, adds my sig, then calls debuild and finally debdiff
<IntuitiveNipple> I get a set of y/n prompts at key points with the option to over-ride
<LaserJock> k
<LaserJock> that doesn't sound too bad
<geser> IntuitiveNipple: what happens if the package doesn't use dpatch?
<LaserJock> I wouldn't do it, but well, that's me
<IntuitiveNipple> geser Then I do it manually
<IntuitiveNipple> I rarely mess with packages so when I do I don't want to be pissing about re-remembering all the steps.
<LaserJock> but for me it's remembering the steps that makes me confident in what I'm doing
<LaserJock> as perhaps the steps have changes since last I did it
<LaserJock> but that's just me
<IntuitiveNipple> I prefer automated tools to handle repetitive tasks; I focus on the stuff the computer can't do
<LaserJock> I do everything manually
<IntuitiveNipple> Working on the kernel is so much easier than messing about with packages :)
<LaserJock> I can understand that, but I find many packaging taskes are not really repetitive
<IntuitiveNipple> The only involvement I'll have is applyin bug-fixes, so the steps I need to be involved in will generally be the same everytime
<LaserJock> except if they change ;-)
<IntuitiveNipple> which basically boils down to creating a debdiff and attaching to an LP bug report for someone else to deal with
<IntuitiveNipple> Easy enough to amend the script to deal with changes, and then forget it again
#ubuntu-devel 2007-10-27
<Kopfgeldjaeger> n8
<bobesponja> bug 1
<ubotu> Launchpad bug 1 in ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<chowmeined> are there any plans to add like a way to detect which ACPI settings to use? like some kind of auto ACPI configuration system that will allow suspend etc work on more machines?
<sladen> chowmeined: could you spec it;  the man question would be /how/ to present such an interface?
<chowmeined> no interface, just uses like dpkg-reconfigure and runs a bunch of tests to detect the configuration, the drivers in use etc.. then sets whatever needs to be tweaked to make suspend work for that config
<chowmeined> for example, i just installed ubuntu 7.10 on a latitude d600.. to make suspend work, only a few settings in /etc/default/acpi-support needed to be changed
<chowmeined> so.. why not automate that
<sladen> chowmeined: in the cases where the settings /are/ known, they are automated
<chowmeined> oh ok, so where can i add rules? id like to submit to wherever these need to go so they can be fixed for these types of computers
<sladen> chowmeined: see /usr/share/acpi-support/Dell*.config
<chowmeined> ok, thanks
<sladen> chowmeined: yes, bank on, once you figure out the correct rules for your machine, (and how to identify it), https://launchpad.net/ubuntu/+source/acpi-support/+filebug with the name of your laptop in the subjet
<chowmeined> ok, i work for an organization and we have lots of types of computers (standard model dells but).. it'd be nice to have them automatic for hardy
<chowmeined> i plan on testing hardy alphas extensively on our systems to make sure they will work
<sladen> chowmeined: that would be very helpful;  there'll be a switch to pm-utils so that will need testing across them
<sladen> chowmeined: and if the testing is done before release, it should make it into the final release for Hardy
<chowmeined> is there a blueprint for that?
<chowmeined> i guess i can google for it
<sladen> the pm-utils switchover, no, I don't think so
<sladen> https://blueprints.launchpad.net/ubuntu/+spec/pm-utils-integration
<chowmeined> oh there it is
<mneptok> insobox: could you please change your client's $REALNAME?
<mneptok> and ident
<LaserJock> hmm, I didn't know you had ops ;-)
<mneptok> LaserJock: i don't tell anyone, as i want people to have faith and trust in the project :)
<boitono> You lazy nerds!  Your new update crashed his computer, tell my boyfriend how to fix it NOW!!
<somerville32> boitono: Hello. Please see #ubuntu for support.
<Keybuk> boitono: first we'd have to know the problem
<ebrahim> persia, Salaam!
<persia> ebrahim: Shalom
<ebrahim> persia, Are you Persian?
<persia> ebrahim: No (and my Farsi is weak).  I was assigned this username when I first received a unix account (ages ago), and maintain it out of tradition.
<mneptok> ebrahim: wa-aleykum a-salaam :)
<ebrahim> persia, :D nice! You've been lucky to receive such a username.
<persia> ebrahim: Yes, indeed :)
<ebrahim> mneptok, :) Do you know Persian? or Arabic?
<mneptok> ebrahim: no, i'm an American. :)
<mneptok> ebrahim: Euro-American, precisely
<ebrahim> mneptok, so were do you know the answer to Salaam?
<mneptok> ebrahim: i care about manners and etiquette?
<mneptok> :)
<mneptok> bismillah, no? :)
<ebrahim> mneptok, :) Yes!
<soren> Adri2000: Sure, just go ahead with the pbuilder merge.
<Hobbsee> soren: congratulations, oh new overlord
<soren> Hobbsee: er?
<Hobbsee> soren: MC
<soren> Hobbsee: I've been stuck on a plane all day. I haven't a clue :)
<soren> Hobbsee: Oh, cool.
 * soren goes t osee the results
<soren> The so-called hi-speed internet at this hotel is not very impressive.
<Hobbsee> hah
<Hobbsee> how fast is it?
<soren> That's a very impressive vote.
<Hobbsee> they're probably comparing it to au
<soren> I think they're comparing it to smoke signals.
<soren> Bad ones.
<slangasek> I'm content to compare it to .au
<Hobbsee> haha
<Hobbsee> soren: have you found the beer yet, though?
 * Hobbsee is greatful that sevilla had a good internet connection.  at least downstairs.
<soren> Oh yes. There's a reason I'm still aweake.
<soren> And can't spell "awake"
<soren> (the last bit is not really true)
<soren> It's hard to type properly with this much latency between key press and the character showing up on the screen.
<Hobbsee> soren: just how bad is it?
<Hobbsee> soren: like, what speed are you actually getting?
<jdong> soren: ooh you're at the hotel?
<jdong> soren: does the hotel use MIT internet, or the hotel chain's?
 * jdong looks out his window in the direction of the hotel :)
<mpt> Hotel chain's
<jdong> mpt: oh well, that sucks :(
<soren> Hobbsee: From the time I press a key until I see the character, I'd guess it's slightly less than a secon.d
<soren> jdong: I have no clue.
<jdong> soren: are you on the 18.0.0.0/8 subnet?
<soren> Nope.
<slangasek> eew? 18.?
<soren> 172.17.0.0/16
<soren> Oh, publically? Hang on, i'll check
<jdong> slangasek: hey! what's wrong with our subnet? :)
<Hobbsee> soren: yummy.
<Hobbsee> soren: ssh'd out, presumably...
<soren> External IP: 12.172.70.2
<jdong> soren: heh that's Hilton's block
<jdong> that sucks
<soren> Quite. I expect elmo has set up something decent downstairs.
<soren> Otherwise, I'll go nuts.
<jdong> soren: just come on campus and steal some drops :)
<Hobbsee> if he can get off the netsplitting server, taht'd help :P
 * soren needs sleep
<ajmitch> already? :)
<soren> It's 6:40 AM in my body's timezone.
<jdong> soren: pfft in MIT time that's the finishing touches on a problem set :)
<ajmitch> jdong: I thought that was when you started assignments?
<jdong> ajmitch: shhh ;-)
<soren> jdong: Does your day start at 1 AM in MIT time?
<jdong> soren: days never end in MIT time :)
<soren> jdong: :p
<jdong> until a suicide monday, then we finally get 24hr sleep :)
 * soren goes to sleep
<soren> g'night.
<jdong> night
<Hobbsee> night soren
<blahdeblah> Hi.  Does anyone know whether there is an effort within Canonical or the Ubuntu community to create a web-based update management service for Debian & Ubuntu machines (i.e. an equivalent to RHN for Red Hat or WSUS for Windows)?
<blahdeblah> Before i embark on such an endeavour, are there any efforts in this area that i should check out?  (Adapting another distribution's tool?  As a module of a larger monitoring/management package?)
<Hobbsee> blahdeblah: landscape sounds similar, but i don't know of the details
<blahdeblah> Hobbsee: Got a link?
<Hobbsee> blahdeblah: i'd guess https://launchpad.net/landscape but i'm not affiliated with it, so cant tell you more
<blahdeblah> Cool - thanks.
<Mithrandir> hi Hobbsee
<Hobbsee> Mithrandir!
 * Hobbsee hugs Mithrandir, then stomps on his feet
<Hobbsee> Mithrandir: you in boston yet too?
<Mithrandir> I'm lying in bed, pondering breakfast, so please don.t
<Mithrandir> no, incoming plane from Oslo was delayed, so I missed my connection
<Hobbsee> urgh :(
<Mithrandir> plane leaves in about 3.5 hours
<Hobbsee> i'm surprised the sydney people didnt get delayed too, (on the sydney flight)
<Hobbsee> ahhh
<stgraber> Mithrandir: :(
<Mithrandir> shit happens, I'll be around tomorrow
<Hobbsee> Mithrandir: true.  less beer for you, then.
<Mithrandir> indeed. :-(
<Mithrandir> but I got maemo mapper up and running here, which is nice.
<Hobbsee> :)
<ajmitch> GPS app?
<Mithrandir> ajmitch: yup
<ebrahim> Where can I find info on ubuntulog?
<imbrandon> ebrahim, i'm pretty sure its one of seveas's bots , prod him
<ebrahim> imbrandon, found https://help.ubuntu.com/community/InternetRelayChat#head-3764552ccef65ea78b1fd8d16bee097a5ca6c76c in #kubuntu-devel ;)
<Amaranth> imbrandon: iirc fabbione actually runs ubuntulog
<Kopfgeldjaeger> hi
<ksivaji> is it possible to integrate kget with opera
<pitti> Good morning
<Hobbsee> morning pitti!
<StevenK> Morning pitti
 * pitti hugs Hobbsee from the US east coast
 * Hobbsee hugs pitti back from australia
<Hobbsee> pitti: how many people have you hugged in the last 24 hours, then?  :)
 * Hobbsee suspects pitti went on a mass hug-a-thon
<pitti> Hobbsee: not that many yet actually, I arrived pretty late, so I only met 10 guys or so
<Hobbsee> pitti: awww
<Kmos> ubotu is down, anyone can re-start it ?
<Hobbsee> news at 11.
<Hobbsee> Kmos: if they could have, they would have already done so.  long ago.
<Kmos> :-)
<Hobbsee> and htey cant from here anyway
<Kmos> Hobbsee: maybe only seveas has access to it
<Hobbsee> Kmos: and based on the fact that seveas is not in this channel...
<Kmos> he's not on irc :(
<Hobbsee> which probably means that his, and ubotu's connection is broken.
<Kmos> ok
<Adri2000> soren: pbuilder merge : http://adrishost.homeip.net/~adri2000/ubuntu/toupload/pbuilder_0.174ubuntu1.debdiff ; I changed gutsy to hardy in pbuilderrc. this is not test-built yet because of some latex unmetdeps.
<Hobbsee> Adri2000: he'll be at breakfast
<Hobbsee> Adri2000: pbuilder depends on latex now?
<Adri2000> Hobbsee: build-depends on dblatex yes
<sits> hi there
<sits> is this the wrong channel for Launchpad devs?
<Kmos> sits: #launchpad
<sits> Kmos: thank you
<Hobbsee> Adri2000: how weird.
 * minghua heard some story about texlive stuff uninstallable in hardy, too.
<Adri2000> Hobbsee: it seems to be used for the doc
<Hobbsee> Adri2000: ahhh, okay.
<persia> Two problems: imbalanced builds (should be OK soon), and an update required to libkpathsea.  Not huge, but needs attention.
<minghua> persia: Do you know more details about the required update to libkpathsea?  Is it poppler related?
<Burgundavia> popey: you around?
<persia> minghua: I'm not entirely sure.  I'm guessing it's security related.  Should be fixed with when the merge is done.
<minghua> persia: I see, thanks.
<Hobbsee> Kmos: hi.  i see removal requests.  if any are wrong, should i mark them as wontfix, yell at you, get someone else to fix them, or all of the above?
<Hobbsee> Kmos: as a start, do all the packages actually *exist* in ubuntu?
 * Hobbsee does not plan to spend time explaining, for you to then "forget" in an hour.  again.
 * popey is around
<popey> shame burgundavia isn't
<sladen> popey: you made it?
<popey> yes
<popey> there was a mess up on the trains, so we ended up getting a bus part of the way
<popey> i wrote it up on the uds page in case others need that info
<popey> quite a number of canonical ppl here already
<popey> sladen: when do you get here?
<sladen> popey: *cough*.  get where... ?
<Kmos> Hobbsee: the ones to remove exists at ubuntu
<Fujitsu> Kmos: Have they been removed from Debian already?
<Kmos> Fujitsu: yep
<persia> Kmos: Are they required to support upgrades from Dapper?
<Fujitsu> Aren't Debian removals processed automagically>
<Fujitsu> *?
<sladen> popey: made it to ReykjavÃ­k, have a talk to the LUG in an hour an a half
<popey> ahhh
<persia> Fujitsu: Depends.  Not usually.
<popey> when do you hit boston?
<Kmos> persia: that i don't know, if they'll break the upgrade
<mjg59> popey: Hm. Silver+Red sounded easier, really...
<persia> Kmos: You'll want to test that before the package gets removed.  We need to support Dapper upgrades for a while yet.
<popey> yeah, we had 5 people each with different directions
<popey> christ knows how
<popey> mine was a print of the wiki page which was deemed "to verbose" so was dismissed :)
 * Hobbsee hums, taps fingers.
<Hobbsee> i wonder how hard it would be to find the old log, to save persia a whole lot of typing.
<persia> Hobbsee: If it weren't for repeating things, I'd have nothing to say :)
<Kmos> persia: one of them is merged into first package.. bug 157659
<persia> Kmos: You don't have to tell me.  You have to explain in the bug, clearly enough that there's no question, and document all your testing.
<Hobbsee> Kmos: that *doesn't* say if it's goign to break when upgrading from dapper.
<mjg59> Time for some switft breakfast, I think
<Kmos> https://bugs.edge.launchpad.net/ubuntu/+source/lckdo/+bug/157663 -> this one is now included in moreutils
<Ubotwo> Launchpad bug 157663 in lckdo "Please remove lckdo from Ubuntu Hardy" [Wishlist,New]
<Hobbsee> mjg59: yes.  leave this channel, before you start throwing things at the wall
<Hobbsee> TheMuso!
<Hobbsee> Kmos: now actually read what persia said.
<popey> breakfast was indeed good mjg59
 * popey ate too much bacon
<Hobbsee> mmm...bacon
<popey> for a given definition of $too_much
<Kmos> Hobbsee: i need to explain.. i think i've explained in description, i try to explain the best
 * StevenK didn't have any bacon.
<Chipzz> persia: well, to be honest, I don't think it's fair to hold that particular thing against Kmos... I don't dare to start yo imagine how many packages were removed during the past 3 release cycles without taking that into consideration
<Hobbsee> Kmos: clearly you *havent* else we wouldnt be telling you what we were above.
<persia> Chipzz: LTS.  Hardy is the next LTS.  We *must* support Dapper -> Hardy upgrades.
<Chipzz> persia: I *know* that
<Hobbsee> Chipzz: most people actually thought about things (as in, the case where something is replaced by something else), and fixed them.  Kmos doesn't.
<Chipzz> persia: but it's very much possible similar breakage already *was* caused during the edgy/feisty/gutsy cycles by some oversight when removing packages...
<persia> Chipzz: Perhaps you're right.  I'll check the removal logs.
<Chipzz> persia: can you be 100% sure that no-one has made such a mistake yet? I think you can't...
<Hobbsee> Chipzz: btw, the sponsors tend to catch that sort of thing.  which is why kmos got such a grilling over it last time.
<Hobbsee> Chipzz: we cant.  but 2 wrongs dont make a right, and at least attempting to get the vast majority correct would be good.
<persia> Chipzz: No, I can't.  That's why I'm checking.
<Hobbsee> persia: i wonder if there's a script that can check it all.
<Hobbsee> persia: as in, dapper --> gutsy upgrade, and see what falls over
<persia> Hobbsee: One could create such a script.  Set up a chroot.  debootstrap Dapper.  Install everything from the removal log.  dist-upgrade.  Trap errors.
<Chipzz> persia: uptil now dapper -> hardy upgrades were barely considered; I am pretty darn sure that, especially early in the edgy cycle, this was not taken into consideration/overlooked
<Hobbsee> Chipzz: uh, no.  they've *long* been getting considered.
<Hobbsee> Chipzz: what evidence do you have for your claim?
<persia> Chipzz: I'm not sure about that.  I know we are keeping a number of transition packages just for that reason.
 * Hobbsee doesnt even recall Chipzz working with packages.
<Chipzz> Hobbsee: I don't, but I tend to be fairly familiar with debian and ubuntu, and I read most of what's being said in here (but in most cases I tend to keep out of the discussion)
<Hobbsee> Chipzz: based on how it's usually spoken about in -motu
<Hobbsee> i can see why you would see it's not said here.
<Hobbsee> all the main people *know* that they have to support dapper --> hardy, so there's no need to discuss it, is there?
<Hobbsee> therefore, i cant see your claim as being valid :)
<persia> Chipzz: That's probably it.  Most of the "we keep until later" discussion has happened in candidate removal bugs.
<StevenK> There's a need to dicuss *how*, but not *why*
<Chipzz> Hobbsee: also, I have seen remarks that testing dapper -> hardy upgrades was only going to get started to be tested during the hardy cycle
<Hobbsee> Chipzz: actual physical testing.  yes.
<Hobbsee> Chipzz: but it's not hard to go "i'm removing something, it's being replaced by something else, i'll fix it while i'm at it".  that's very different from physical testing.
* Riddell changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, even with hardy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Hardy opened, go wild! | FOSSCamp in #fosscamp
<Riddell> (FOSSCamp in #fosscamp)
<Chipzz> Hobbsee: the bottom line of what I'm saying is, while I'm not a big fan of Kmos at all, I *do* think you (plural) are being a bit harsh on him with regard to to the dapper -> hardy issue
<Chipzz> I think he'll not be the only one to oversee such issues
<Chipzz> s/oversee/overlook/
<Kmos> Chipzz: i'm the black cheap =)
<Chipzz> Kmos: and with good reason for that too...
<Kmos> Chipzz: not always
<Hobbsee> Chipzz: all the people get grilled on it
<Hobbsee> Chipzz: of course, usually people understand the problem a little quicker, and only need the explanation once.
<Kmos> the are here to learn, and things from the past, shouldn't be merged with the present
<Kmos> Hobbsee: and you know if it will break or not ? you talk to me as I'm a MOTU and not a user that likes to contribute
<Hobbsee> Kmos: aren't you attempting to become a MOTU?
<Chipzz> Kmos: but I do agree that archive removal requests are best let to people intimitaly familiar with the archive
<Hobbsee> Kmos: your wiki page says as much
<Hobbsee> Kmos: i dont really care who you are - i care if you repeatedly try to break the archive - no matter who it is.
<Chipzz> s/let/left/
<Kmos> Hobbsee: i don't say there i won't be one right now
<Kmos> *want
<Kmos> i need to learn a lot of things first
<Kmos> and with that, come my mistakes
<Hobbsee> so, to you, consistent mistakes on the same issues are perfectly acceptable, because you're only a user trying to help, not a guy wanting upload rights?
<Kmos> Chipzz: i just check some debian removals, and two of my requests are merged into another packages that are already in hardy
<Kmos> Hobbsee: i like you to consider me as that now.. when I officially candidate as MOTU, you can give me right in the head
<Kmos> Hobbsee: i'll remove it from my wiki =)
<Hobbsee> Kmos: has it occured to you that there are other people who also want to help out, and if you consistently use up the majority of help on offer, due to not actually learning anything, and making the same mistakes over and over again, that you're not helping, and you're just wasting our time?
<Kmos> Hobbsee: yeah.. but in that questions of upgrade breakage.. you don't think you're asking too much for me, even you don't know if it will break
<Kmos> or not
<Kmos> wiki is updated
<Hobbsee> ...
<minghua> Kmos: No, I don't think Hobbsee is asking too much.
 * Hobbsee ponders any sane response that comes up from that.
<Hobbsee> beyond writing to the mailing list, posting this log, and saying that kmos is clearly unsuitable - and that prefernece of help should be given to those who actually listen to it, and care about getting things right.
<Kmos> Hobbsee: do what you want..
<minghua> Kmos: If you are proposing a removal, you are supposed to know if it will break things or not, not Hobbsee.  If Hobbsee has questions, you'd better have good answers, or at least a "sorry, I didn't think about that, I'll think about now", and add that to bug report.
<Kmos> minghua: i've commented bug 157663
<Kmos> because of that
<Hobbsee> mneptok: i think i have a job for you.
<Hobbsee> Kmos: why dont you care about getting the stuff right?
<minghua> bug 157663
<Fujitsu> minghua: ubotu is dead.
<Hobbsee> minghua: i dont think this bot supports that
<Hobbsee> Ubotwo: ping
<Ubotwo> pong
<minghua> bug #157663
<Hobbsee> Ubotwo: bug 157663
<Ubotwo> Hobbsee: Error: "bug" is not a valid command.
<Hobbsee> nope
<Fujitsu> Hah.
<minghua> Oh well.
<Kmos> Hobbsee: I care, but I don't know everything.. if i've written all the things needed
<Hobbsee> Kmos: yet, when you get things explained to you, you dont seem to listen and actually remember the stuff.  at all.
<Hobbsee> hwo do you explain that?
<minghua> Hobbsee: So someone explained the LTS->LTS upgrade issue to Kmos before he filed bug 157663?
<Hobbsee> minghua: oh yes.  crywrap removal, to stunnel4
<Hobbsee> minghua: he finally got it, then.
<Hobbsee> minghua: that was feisty.  i know, because i had the honours.
<Kmos> Hobbsee: you don't have never explained me about this thing of removal package and how to do it.
<Hobbsee> Kmos: do you want me to show you the fscking logs?
<minghua> Hobbsee: ...right.  I won't waste my time here, then.
<Kmos> Hobbsee: don't needed
<Kmos> it's lunch time
<Hobbsee> Kmos: really, don't lie, when things are publically logged.
<Hobbsee> all it will prove is how you are.
<Hobbsee> er, how you are lying.
<Kmos> Hobbsee: you told me about that crywrap -> stunnel4
<Hobbsee> Kmos: which was the LTS->LTS upgrade stuff.
<Kmos> Hobbsee: https://bugs.edge.launchpad.net/ubuntu/+source/singularity-data/+bug/157659
<Ubotwo> Launchpad bug 157659 in singularity-data "Please remove singularity-data from Ubuntu Hardy" [Wishlist,New]
<Kmos> this one won't break anything
<Kmos> it's merged into singularity package
<soren> Where's ubotu?
<Kmos> i think it won't break
<Kmos> soren: down
<persia> Kmos: Please document the reasoning in the bug, rather than in IRC.  The people who will make the final decision need to see the documentation, regardless of whether it works, or if we all agree.
<Hobbsee> soren: seveas' connection appears to have fallen over
<ScottK> Kmos: This isn't the first time you've been grilled over not getting removal requests right.
 * Kmos lunch time
<Kmos> ScottK: I know =)
<ScottK> Kmos: There is really no point in going through telling you stuff, you forget, make the same mistakes, and we tell you again and it's a big suprise to you every time.
<Hobbsee> ScottK: but remember, according to kmos, he's only a user who wants to help, so shouldnt be required to actually get things right.  unless i'm misreading what he says above, of course.
<ScottK> Kmos: You REALLY need to find something to focus on that you do, in fact, know how to do.  I've no idea what that would be, but please find it.
<Hobbsee> ScottK: getdeb, perhaps?
 * ScottK <-- AFK - Has better things to do.
<ScottK> Hobbsee: No, it's fairly clear he doesn't know how to package software.
<soren> Hobbsee: I'm just reading a bit of backscroll here.. Is the dapper->hardy upgrade stuff documented on the wiki somewhere?
<Hobbsee> soren: it's certainly in a spec
<Hobbsee> soren: and has been discussed since dapper.
<soren> I know, I know.
<soren> I'm just wondring if it's appropriately linked on the MOTU pages or some such.
<Hobbsee> so, it will be in the wiki somewhere, yes.
<Hobbsee> soren: unsure, tbh.  we usually raise it with people when they do their first removal request, etc.
<persia> soren: It may not be.  We don't tend to provide much prescriptive documentation, more information on how to use tools and processes, rather than what to do with them.
<minghua> soren, Hobbsee: In the lckdo removal case (bug 157663), I think gutsy->hardy upgrade is affected, so it's not only LTS->LTS upgrade issue.
<soren> persia: Yeah. I'm just thinking it might be worth the time to actually write this particular bit down.
<persia> soren: Perhaps.  I'm tempted to wait until after the MOTU wiki cleanup is more complete before adding much, just to reduce the coordination headache of the transition.
<Hobbsee> Kmos: new packages get done by the autosyncer, btw.
<Hobbsee> Kmos: how do you thikn that all the other new packages get in?  someone requesting them all individually?
<StevenK> I didn't think the autosyncer did that.
<StevenK> I thought they were done semi-automatically by -archive guys
<Hobbsee> StevenK: well, they get stuck in source new, sure, but afaik, they get pulled there by the autosync
<StevenK> Hrm. I'll bug pitti when I see him
<Hobbsee> freecol
 * Hobbsee goes to look
<Fujitsu> It's not the normal autosyncer, but there is another script run manually every so often that pulls them in.
<Hobbsee> Fujitsu: ahhh.
<Hobbsee> Fujitsu: based on the size of the new queue, i'm unsurprised that they haven tdone it yet
<persia> In gutsy, the NEW queue was processed agressively starting around mid-UDS.  I would expect the same this time.
<Fujitsu> Hobbsee: As well as the build queue being too big for Soyuz to handle properly, yeah.
<Hobbsee> persia: when people got bored of sessions?  *g*
<Hobbsee> Fujitsu: fun
<persia> Hobbsee: I can't speak to motivation :)
<Kopfgeldjaeger> bcm43xx firmware makes 23 GB traffic in one week
<Hobbsee> hiya jono
<Hobbsee> agoliveira
<Hobbsee> bah.
 * Hobbsee kicks her tab completion
<calc> Hobbsee: hi
<Hobbsee> hi calc!
<StevenK> jono: You know, your laptop comes with a keyboard. :-P
<agoliveira> Hobbsee: Did you call me?
<Hobbsee> agoliveira: only by accident.
 * agoliveira feel unloved :(
<StevenK> Awww
 * StevenK tickles agoliveira more
 * agoliveira moves to other room
 * Hobbsee hugs agoliveira
 * agoliveira wipe the tears and see the sunshine for the first time today...
<Hobbsee> agoliveira: you can tell everyone else at the conference that you shouldnt all get klined now.
 * agoliveira is eating the "s" today...
<lifeless> Hobbsee: thanks!
<Hobbsee> agoliveira: that can be your calling :)
<Hobbsee> lifeless: :)
<lifeless> now if only I irc'd from the conference so that I'd care :)
 * StevenK smirks
<Hobbsee> lifeless: they havent put the cloak in yet, but they should realise it's a harmless IP - at least, if they've read their mail.
<jono> StevenK: hehe
<StevenK> jono: You don't like the laptop keyboard?
<ompaul> Hobbsee, as soon as they see the mail they should wrap the cloak aound it - can only be done by senior staffers
<Hobbsee> ompaul: yeah, thought so.
<Hobbsee> guten tag, ogra
<Hobbsee> found any nice cats yet?  :)
<ogra> hallo sarah
<ogra> nope, boston seems to be no cat city
<Hobbsee> awww
<ogra> at least not one for stray cats :)
<Hobbsee> aww
 * ScottK imagines stray cats being unlikely to survive the Boston winter.
<ogra> which winter ?
<Hobbsee> boston has *multiple* winters?
<stgraber> well, it's warmer here than in switzerland :)
 * Hobbsee thinks that violates all that she learnt about seasons :)
<Hobbsee> stgraber: what's the normal temp of switzerland/
<ogra> i mean ... i brought all these warm sweaters and now is sit here in a t-shirt... sweating
<ogra> s/is/i/
<Hobbsee> ogra: ah.  hence, s/which/what/
<stgraber> Hobbsee: was something like 2Â°C the day before I left :)
<ogra> ah
<Hobbsee> stgraber: oof.
<ogra> same in .de
<ogra> hah !
 * ogra just found out why his evolution crashes all the time ...
 * ogra reboots
<TheMuso> ogasawara: The hotel is too warm IMO.
<TheMuso> ugh
<TheMuso> ograThe hotel is too warm IMO.
<stgraber> TheMuso: +1
 * TheMuso opened the window in his room to let some fresh air in. it was crazily warm overnight. I didn't sleep with much on me.
<TheMuso> As in, bed clothes.
<calc> any gnome/totem devs around?
<calc> i have an ogg that appears to crash totem on 7.10
 * stgraber sleeps well, having no sleep for 40hours certainly helped :)
 * calc needs to hunt down seb128 here on the 3rd floor to show him
<TheMuso> stgraber: Aye.
<TheMuso> stgraber: i had a 20 hour trip, ad only managed to get 2 hours of sleep, if htat.
<TheMuso> and even
<TheMuso> And even now I am still a little tired, as I got up earlier than I really needed to it seems.
<stgraber> TheMuso: I maybe slept for 30min in the plane but not much more, way too noisy and I don't seem to easily sleep in plane
<TheMuso> stgraber: I can sleep most places, but planes are the exception, so I know what you mean.
<calc> i found that i must be allergic to down, woke up with red itchy eyes
<TheMuso> calc: Re that ogg, have you looked atht ehtags with vorbiscomment? Could there be anything in the tags that could cause totem to crash? And have you tried totem-xine?
<TheMuso> ugh typing not soo good either. :p
<calc> haven't tried totem-xine yet
<TheMuso> mm ok.
<stgraber> if that works with -xine, best would be to find another gstreamer based movie player and try with it
<stgraber> so you can check if that's totem or backend related
<calc> yea
<calc> hmm actually its not vorbis its an ogg video so vorbiscomment pukes on it
<stgraber> calc: maybe ogmtools and ogminfo
<stgraber> (never used it)
<calc> hmm its actually not the file
<calc> X Error of failed request:  BadAlloc (insufficient resources for operation)
<calc> i keep getting that for some reason
<calc> it happens in totem-gstreamer totem-xine xine so far
<Hobbsee> memory?
<calc> i have plenty free
<calc> bryce_: any ideas what cause that?
<calc> Riddell: you are next to me... any ideas what cause BadAlloc when you aren't low on ram for displaying stuff in X?
<seb128> calc: looks like a video driver issue
<mvo> calc: compiz?
<seb128> or that
<calc> no compiz here
<calc> on i945
<Hobbsee> mvo!
<Riddell> calc: do other videos work?
<seb128> intel or i810?
<mvo> hey Hobbsee
<calc> i810 that should be intel, right?
 * calc wonders why it was set to i810
<seb128> you can try the other one
<StevenK> Hrm. Mine is currently set to i810
<calc> works
<calc> so it didn't like the i810 driver apparently
<TheMuso> Lovely.
<blueyed> calc: we have a fix ready for the gtk crash in OOo (bug 131526). Can you sponsor the upload/look at it?
<calc> blueyed: for hardy?
<calc> blueyed: i have a bunch of fixes to go in for gutsy-updates if that is what you are positioning it for
<blueyed> calc: for hardy and gutsy-proposed
<blueyed> calc: sweet! I've just found bug #155125, too - which has a patch also already.
<calc> blueyed: can you email me at ccheney@ubuntu.com with this log and any other information you think is pertinent
<calc> i am running to another meeting, bbia 5m
<blueyed> calc: ok
 * calc back
<calc> blueyed: when things calm down a bit i plan on uploading to a ppa for testing the fixes
<blueyed> calc: you don't want to do this.. I've been accused of causing DOS with my OOo upload. And actually the i386 build is likely to fail anyway.
<timbobsteve> can I ask a question about custom usplash? or should I ask in #ubuntu ?
<calc> blueyed: that is why it will be in a ppa
<calc> blueyed: vs gutsy-proposed
<calc> blueyed: https://help.launchpad.net/PPAQuickStart
<Hobbsee> calc: give it a few days - people want to get *some* stuff built in between 3 ooo uploads, and a whole bunch of langpacks
 * calc must be confused about what other OOo uploads
<Hobbsee> calc: buildds are unusable for anyone else at the moment - have been for a couple of days
<blueyed> calc: I've been talking about my ppa. i386 is likely to fail there (at least my build failed)
<calc> blueyed: ah ok
<calc> i'm waiting to see what other major bugs pop up, and i would like to get openoffice.org-base issue resolved as well in 1ubuntu5.2 if possible
<calc> i'm not sure yet how much work that will be
<calc> you uploaded 3 ppa's in one day?
<Hobbsee> calc: 2 days.
<calc> ok so probably within 24hr anyway ;)
 * Hobbsee didn't check the hours :)
 * calc thinks he is trying to kill the buildds ;
<calc> ;)
 * Hobbsee just went looking for "why are people complaining about why their stuff isnt built yet"
<calc> ppa is autobuilt right?
<StevenK> I think the autosyncer ran as well.
<Hobbsee> calc: it does the queue automatically, yes
<calc> Hobbsee: ok
<Hobbsee> calc: and main gets preference, i expect
<StevenK> Main does
<Hobbsee> yes, but i'm unsur ehow much of that goes for ppa too
<bryce_> calc: sounds like the -intel bug in Xv Peter has a fix for perhaps; I can point you at the .deb later if you want to see if it fixes
<joejaxx> jono: there is an existing blueprint for live-cd-share-live-cd i proposed it for uds-boston on lp
<Supremus> pitti, hello
<Supremus> pitti, could you please check bug 103489
<warsocket> where sould i go with a question about a programming technique to hide console output from other programs form my c program. I intent to submit my program to ubunut when its done.
<dooglus> hi all.  I would like to make an ubuntu package of ImageMagick using a recent release.  Where can I find instructions for doing so?
<warsocket> this channel or another?
<nixternal> dooglus: https://wiki.kubuntu.org/PackagingGuide
<dooglus> nixternal: thanks
<nixternal> no problem...dooglus, you can also check out #ubuntu-motu for packaging help
<dooglus> nixternal: when I make the package, is there any chance it would be used by ubuntu?  the version currently shipped is very old, and misses quite a few featues, like the ability to optimize animated gifs
<nixternal> you can create a debdiff for the updated package, and yes there is a chance it would be used, as long as you did the package right...you could also submit it to revu.tauware.de as wel
<Supremus> pitti, could you please check bug 103489
<pitti> Supremus: not ATM, sorry (in a discussion round)
<Supremus> ok
<jdong> hmm, XSBC-Original-Maintainer trips up pdebuild-internal
<jdong> somehow it thinks the name of the output debs is the value of XSBC-O-M
<TheMuso> Lovel/c
<TheMuso> ugh
<TheMuso> lovely
 * jdong tries to reproduce again
<jdong> cp: cannot stat `../<test@foobar.xsbc>': No such file or directory
<jdong> reproduced
<coffeedude> Q: printing URL for the specifications mentioned?
<jdong>    for files in $(sed -rn '/^Files:/,${s/.* ([^ ]+)$/}' ../${CHANGES}); do
<jdong> that's the line that must be broken
<jdong> any sed overlords around?
<jdong> got it
<jdong> should SRU's to gutsy-proposed 0ubuntu1 rleease be 0ubuntu1.1, or 0ubuntu1.1~prop1?
<jdong> soren: ping
<StevenK> Mithrandir: You look like I feel.
<warsocket> Whats the best approch if i'm looking for ppl to join my unifiedinstaller project (Wiki: https://wiki.ubuntu.com/Spec/UnifiedInstaller)
<Mithrandir> StevenK: heh. :-)
<Mithrandir> StevenK: I feel quite awake, but I'd like another beer soon.
 * StevenK hasn't had a drink at all.
<StevenK> I have a feeling I will be face-planting in my bed upstairs early tonight.
<Mithrandir> I've had close to a bottle of wine today.
<Mithrandir> I think.
<StevenK> If you don't remember, you've drunk too much. Or too little.
<TheMuso> StevenK: I think I'll be doing something similar. I'm awake now, but still feel somewhat tired.
<Adri2000> Mithrandir: may I bug you to push that sru to -updates please ? https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/152918 it's been more than a week and there are more than two "works for me"
<Ubotwo> Launchpad bug 152918 in audacious-plugins "Try to replace libcurl.so from audacious-plugins-extra" [High,Fix committed]
<Mithrandir> Adri2000: done
<Adri2000> thanks
<Adri2000> Mithrandir: should I update the bug or are you going to do it?
<Mithrandir> Adri2000: please do it you
<Adri2000> ok
<soren> jdong: wazzup?
<jdong> soren: saw you touched pbuilder a lot
<jdong> soren: discovered this puppy this morning, and got a debdiff for it: https://bugs.edge.launchpad.net/ubuntu/+source/pbuilder/+bug/157867
<Ubotwo> Launchpad bug 157867 in pbuilder "pdebuild-internal broken when XSBC-Orig-Maintainer used because of faulty sed command" [Undecided,New]
<jdong> it's a 1-liner and should be SRU'able, and of course applied to Hardy too
<soren> jdong: I'm a bit surprised that hasn't been triggered before.
<jdong> soren: as am I :)
<jdong> but the original sed matches any fields below Files:
<soren> sure, sure, i get it :)
<soren> But any X-* fieldn lands down there, AFAIR.
<jdong> yeah, it appears that way
<soren> Ah... I get it.
<Adri2000> (don't forget there is that pending upload for hardy: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/pbuilder_0.174ubuntu1.debdiff :))
<soren> Most of the other custom fields are XS or XB, and hence don't land in changes.
<soren> Adri2000: I know, I know.  :)
<soren> I actually can't think of anything else that uses XC fields.
<nachito> hi
<nachito> hola
<nachito> hi
<nachito> hi
<nachito> :(
<mebrahim> nachito, Hi!
<mebrahim> nachito, :D
<nachito> hablemos en espan^ol
<nachito> spanish??
<SLaPoet> nachito: de donde?
<nachito> de Chile
<nachito> y tu ocmpadre?
<SLaPoet> nachito: un momento
<nachito> ok
<SLaPoet> nachito: #ubuntu-cl
<SLaPoet> ayudad  en espanol
<SLaPoet> that's about all the spanish i know
<ompaul> !es
<Ubotwo> Si busca ayuda en EspaÃ±ol por favor entre en los canales #ubuntu-es, #kubuntu-es o #edubuntu-es, allÃ­ obtendrÃ¡ mas ayuda.
<keescook> mvo: I have a usb stick for you
<mvo> keescook: thanks!
<keescook> mvo: sure!  :)  took a while to compress.  :)
<mvo> keescook: its taking a while here to uncompress too :)
<keescook> heh
<simira> mvo: are you in Boston yet?
<mvo> simira: hello! yes I am
<simira> mvo: lucky you :p Could you rl-ping Tollef is you see him? He's been idle for an hour now, and I'd like to talk to him before I go to sleep.
<simira> s/is/if
<soren> How often does MoM run these days?
<mvo> simira: sure, I will tell him if I run into him, he was here a couple of minutes ago but left the room
<simira> mvo: thanksalot :) Have a nice time over there! (still not jealus :p )
<mvo> simira: thanks :)
<soren> Adri2000: Your pbuilder merge looks good, thanks. I'll merge it with jdong's patch and upload in a bit.
<jdong> soren: fantastic, thanks
<soren> jdong: Do you have the lin to the bug report handy?
<jdong> soren: soren https://bugs.edge.launchpad.net/ubuntu/+source/pbuilder/+bug/157867
<Ubotwo> Launchpad bug 157867 in pbuilder "pdebuild-internal broken when XSBC-Orig-Maintainer used because of faulty sed command" [Undecided,New]
<soren> jd	Thanks.
<jdong> sure thing
<jdong> thank you :)
<soren> Adri2000: It doesn't build due to latex annoyances.
#ubuntu-devel 2007-10-28
<Kopfgeldjaeger> n8...
<mbt> Is there a way to see if a package that is in Debian will make its way into Ubuntu?
<persia> mbt: Not exactly.  If a package is in Debian unstable, it will automatically make it's way into the Ubuntu Development release between the archive open and DebianImportFreeze, unless it is on the sync blacklist.
<mbt> persia: Thanks... is that list available onlin?
<mbt> *online?
<persia> mbt: You can check the associated dates from https://wiki.ubuntu.com/HardyReleaseSchedule, and the blacklist from http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
<mbt> Sweet, thank you :)
<persia> mbt: In addition, some packages may be imported from Debian manually anytime until FeatureFreeze, although that is not guaranteed.  Packages that are missed are usually brought in after the archive for the next release opens.
<mbt> Okay.  Was just curious, because I found a useful package and it's not in Ubuntu yet, but it is in Debian unstable.  I suppose that means that it doesn't need a Launchpad bug filed to ask for it to be brought in, since it is not listed on the blacklist, correct?
<crimsun_> (correct.)
<mbt> Alright.  Thanks!
<persia> mbt: Correct.  If it were after DebianImportFreeze, and the new package contained some feature considered important for the next release, one would file a wishlist bug.  In most cases, it's best to let the syncs happen without intervention.
<slangasek> lifeless: so, you seem to be the opensync maintainer... were you in pitti's opensync BoF? :)
<alex-weej> asac: hey
<alex-weej> up?
<slangasek> lifeless: more to the point, I want opensync-motosync working and it doesn't seem compatible with the version of opensync in Debian/Ubuntu
<TheMuso> slangasek: I've been thinking of updating that opensync stack for hardy.
<TheMuso> As I ran into a similar problem with my new Nokia 5700 phone.
<TheMuso> Hopefully it can be done in Debian.
<TheMuso> And we only need sync.
<Keybuk> slangasek: I do wish you'd let me *fix* broken graphs before you link to them in major announcements
<LaserJock> Keybuk: you know if we're going to have VoIP this UDS?
<Keybuk> I believe we are
<stgraber> argh, internet is just so slow... who is downloading ? :)
<Keybuk> PYTHON SUCKS
 * Keybuk goes back to Perl
<Keybuk> no, wait, I'm not that desperate
<TheMuso> lol
<Keybuk> cjwatson_: you have to sync-source on multiverse too, ya know :p
<lifeless> slangasek: I wasn't; I was in a meeting
<coffeedude> evening
<KingPython> i upgraded to gutsi,but when i tried to install a package from source code ,it allways gave me this message: http://paste.ubuntu-nl.org/42420/
<jdong> KingPython: this is a developer channel, not a support channel
<KingPython> but from support channel ,they said me you must to ask this question to developer chanel
<jdong> KingPython: who told you that?
<KingPython> his nickname tekteen
<jdong> KingPython: I don't think he meant that; I think he was trying to join #ubuntu-devel and accidentally typed it into the channel :)
<KingPython> none help me,so how can i learn solve of this problem??
<jdong> KingPython: wait for the netsplit to end and everyone to rejoin and you might get a better answer; at any rate this channel is not appropriate for receiving support
<KingPython> jdong: is this a hard qustion?
<jdong> KingPython: your system shows external modifications... i686-pc-linux-gnulibc1 is not normal
<KingPython> jdong: what can i do?
<slangasek> it's a question that didn't make it to some of us across the netsplit, anyway
<jdong> slangasek: ./configure on his gutsy thinks it should be building against i686-pc-linux-gnulibc1
<slangasek> er... ok then :)
<jdong> apart from the nostalgia, I don't know what is wrong :)
<slangasek> could be a broken config.guess/config.sub, too
<TheMuso> c
<Keybuk> KingPython: what does /usr/share/misc/config.guess say?
<Keybuk> (note: may have to install autotools-dev)
<KingPython> ok wa
<KingPython> t
<slangasek> lifeless: I think I'm going to sit here and hack on opensync for a bit, I want to get opensync-motosync up and running locally while I have access to bluetooth people :)
<KingPython> Keybuk: i installed it now,but it isnt working
<Keybuk> "isn't working" ?
<KingPython> yes that isnt solve my problem
<Keybuk> ?
<KingPython> Keybuk:/usr/share/misc/config.gues said to me: i686-pc-linux-gnulibc1
<DShepherd> does anyone know when the gnome 2.20.1 release is going to make it into the ubuntu repos?
<jdong> DShepherd: I already see a lot of it in gutsy-updates...
 * DShepherd checks to see if he has the gutsy-updates repos
<Keybuk> KingPython: wow
<slangasek> lifeless: so if you'd like to make use of any of that in an updated package for sid/hardy, that'd be keen
<slangasek> KingPython: in that case, you've done something very strange indeed to your system
<Keybuk> KingPython: that sounds like you've overwritten your libc with something very very wrong
<Keybuk> at this point, I would recommend nothing less than a reinstall
<KingPython> no i didnt work on it
<KingPython> but i can reinstall libc
<slangasek> that requires __GLIBC__ to be defined in <features.h>, but not set to a value >= 2; or for __ELF__ to not be set
<Keybuk> given that you've managed to do something as drastic as that
<slangasek> do you have a features.h in your local directory where you're running these commands?
<Keybuk> there's no telling what else is wrong
<DShepherd> jdong, i have the gutsy-updates repo. i havent seen any gnome 2.20.1 releases for any app
<DShepherd> jdong, is there anthoer repository i need?
<jdong> [jdong@jdong:tmp/Starcraft]$ apt-cache policy file-roller         (10-27 22:59)
<KingPython> yes i have this file
<jdong>  *** 2.20.1-0ubuntu1 0
<jdong> DShepherd: sorry, gutsy-proposed...
<slangasek> KingPython: ah.  that's the problem then
<jdong> DShepherd: it's not an official final update yet
<DShepherd> jdong, i have the gutsy-updates repo. i havent seen any gnome 2.20.1 releases for any app
<jdong> DShepherd: it's in testing (proposed) status
<DShepherd> jdong, is there another repository i need?
<slangasek> KingPython: features.h in your current directory seems to be conflicting with the system header, and causing config.guess to misdetect
<KingPython> yes
<slangasek> that's an awesome error condition \o/
<jdong> slangasek: lol, indeed. that's special
<KingPython> what can i do now?
<DShepherd> jdong, http://paste.ubuntu-nl.org/42421/ -- my source list
<slangasek> KingPython: name features.h to something saner that doesn't conflict with a well-known system header. :)
<jdong> DShepherd: you can add the gutsy-proposed repo to get these updates, but be advised it is a TESTING repository and may still contain bugs
<Keybuk> slangasek: that doesn't occur for me
<DShepherd> jdong, ok. I will wait
<jdong> DShepherd: unless there's a specific reason why you must have 2.20.1 now, I'd recommend just to wait
<DShepherd> jdong, thanks...
<DShepherd> jdong, no.. no reason. i will wait
<Keybuk> slangasek: the only way I can make that happen is with CC="gcc -I."
<DShepherd> jdong, thanks for the information though I appreciate it
<jdong> absolutely welcome
<slangasek> Keybuk: perhaps he's also missing libc6-dev?
<slangasek> Keybuk: do you have libc6-dev installed?
<slangasek> sorry
<slangasek> KingPython: do you have libc6-dev installed?
<KingPython> slangasek: i can install lib6c-dev
<Keybuk> WHY is that not a dependency of gcc ?!
<slangasek> KingPython: right.  the combination of having ./features.h, and not having libc6-dev, would explain this behavior
<slangasek> Keybuk: because gcc works just fine for compiling kernel and bootloader code? :)
<KingPython> ubuntu isnt find this package
<Keybuk> slangasek: that's a Debian reasoning :)
<Keybuk> "it's not a *dependency*"
<slangasek> why yes, thanks for noticing
<Keybuk> "If I think very hard I can invent a mythical use case for why somebody who clearly isn't in their right mind to begin with might want one package and not the other"
<Keybuk> making that not a dependency assumes that there is somebody out there who *only* compiles boot loaders
<Keybuk> and never, ever compiles anything else on their machine
<KingPython> and when i write gcc -V </dev/null >&5,it says to me
<KingPython> bash: 5: Bad file descriptor
<KingPython> but i read this in config.log
<slangasek> KingPython: libc6-dev, not lib6c-dev; perhaps that transcription error made it to your install attempt?
<KingPython> yes it can be true
<jdong> transcription error.... *brings back memory of last week's bio exam*
<KingPython> oops a new error :)
<KingPython> error: C++ preprocessor "/lib/cpp" fails sanity check
<compbrai1> Is there a standard python library for processing preseeds/dealing with debconf crap?
<KingPython> i firtsly see this error
<liw> KingPython, do you have the "build-essential" package installed?
<KingPython> hmm
<KingPython> no but now i am isntalling
<KingPython> and very thanks for help me
<KingPython> and a new error again :checking for X... configure: error: Can't find X includes. Please check your installation and add the correct paths!
<KingPython> source code compilation very hard in ubuntu
<KingPython> :(
<Keybuk> compiling anything from source requires the appropriate development libraries
<Keybuk> this is true of any distribution
<KingPython> yes i know but
<Keybuk> the package will tell you what its dependencies are
<Keybuk> you need the "-dev" versions of the appropriate packages
<KingPython> why when install ubuntu ,that are came easy
<Keybuk> ?
<KingPython> yes i know but what is mean of x error?
<slangasek> but surely gcc should depend on x-dev ;-)
<KingPython> hehehehhe
<KingPython> i feel like stupid
<slangasek> KingPython: if you install xorg-dev that will give you the main set of X includes
<KingPython> ok i will try
<KingPython> its near 34 mb
<KingPython> dont problem
<KingPython> ok i downloaded ~80 mb but altought i didnt installed anything,but if i use synapthic i will install this package about ~4 mb ,so how can it do this?
<KingPython> *synaptic
<KingPython> so synaptic more clever than me :)
<KingPython> ok thanx for everything ,i installed it from synaptic and it takes 345 kb
<OpenSorce> any new SRU since for 7.10?
<OpenSorce> ok, guess not...thanks
 * Keybuk stares at gdb
<OpenSorce> I know you guys are (quite understandably) but can anyone tell me if there is an SRU in the near future, the website doesn't say
<OpenSorce> *are (quite understandably) busy
<Hobbsee> OpenSorce: there are plenty.  you didnt say what about.
<persia> OpenSorce: The best way to check the status of updates is to check the archive.  There are usually updates in queue.  If you are experiencing a specific issue, you might do well to check the bug tracker to see the progress on that issue.
<Hobbsee> OpenSorce: if you read the UWN, you will see a whole lot of them.
<OpenSorce> Thank you.....and my next question, will these updates be part of the downloadable 7.10 iso or something a user will have to add on post install?
<Hobbsee> OpenSorce: the latter.
<OpenSorce> Hobbsee, so anything broken in 7.10....such as wifi....will still be broken until the user updates
<Hobbsee> theoretically
<Hobbsee> assuming it's not pebkac error - in which case, an update probably wont fix it anyway
<OpenSorce> Hobbsee, excellent...you just saved me 3 days work, thank you :-)
<Hobbsee> no problem
<OpenSorce> persia, thank you for your help as well
<OpenSorce> Hobbsee, would you find this statement accurate: "Further questioning of developers gave me the following information. The wifi issues may be resolved in future Stable Release Updates, however the downloadable iso of Ubuntu will still have the issues until the user can connect to the internet and download the update. Which a person who relies on wifi for internet cannot do."
<Hobbsee> OpenSorce: you're writing for a magazine?
<OpenSorce> Hobbsee, I am a journalist, yes
<mneptok> what issues?
<OpenSorce> mneptok, 6 out of 6 machines that we tested with various wifi adaptors could not be set up by new users.
<Hobbsee> OpenSorce: can you define which wifi chipsets?
 * Hobbsee suspects they were mostyl broadcom, or required ndiswrapper to use.
<mneptok> PCI? PCI-E? Cardbus? ExpressCard? USB dongle (shudder)?
<OpenSorce> Guys, I asked our IT guy to submit bug reports for them which I believe he has done
<Hobbsee> bug #'s?
<Hobbsee> there are a fair few, and most of them dont have enough information to track down the problem.
<Hobbsee> although, granted, it's a good question of how broadcom firmware is suppsoed to be downloaded, when you have no wifi :P
<OpenSorce> Hobbsee, no clue...not my area....I just review distros for new user fitness
<Hobbsee> OpenSorce: it would be helpful if you could chase your guys, and find them.  in current form, your statement is not fair.
<OpenSorce> Hobbsee, but it is accurate, correct?
<Hobbsee> not really.
<OpenSorce> Hobbsee, okay.....what's part is inaccurate?
<persia> OpenSorce: Or, possibly, publish the specific devices with which it didn't work.  Alternately, it would be interesting to know if the difficulty was with the configuration or the support.
<Hobbsee> OpenSorce: you have an implicit assumption in your statement there that all drivers are free, and that they can all be included on the cd - and it's a bug that they arent.
<Hobbsee> OpenSorce: if you have any broadcom card, and therefore no wifi, we can never fix that - until broadcom decide to open source their drivers.
<mneptok> OpenSorce: your statement sounds as if there are known bugs we can fix. that is not the case.
<OpenSorce> persia, I'm not publishing the 6 machine test results in this article I feel it's too detrimental to the distro
<Hobbsee> OpenSorce: would be helpful if you gave them to us - perhaps so we can actually push said SRU's.
<OpenSorce> mneptok, with all due respect, other distros handle it flawlessly
<mneptok> OpenSorce: if the vendor does not provide hardware information, or an open driver, there's is precious little anyone at any distro, anywhere, anytime, can do about it
<persia> OpenSorce: Hrm.  I can't speak for everyone, but I'd prefer a specific list of things that didn't work to a general statement as you've quoted above.
<mneptok> OpenSorce: the exact same hardware?
<LaserJock> OpenSorce: hi again :-)
<Hobbsee> mneptok: do some distros actually distribute the broadcom stuff illegally?
<Hobbsee> mneptok: actually, stuff like suse probably does - in their commercial block
<OpenSorce> LaserJock, hi! I came to get the status of the SRUs you mentioned and seem to be drawn into another discussion again :-)
<mneptok> Hobbsee: could be. i don't have a SuSE entitlement.
<LaserJock> OpenSorce: well, we like to fix things
<LaserJock> OpenSorce: and help as many users as we can
<Hobbsee> but cant wave the magic wand to fix them :)
<mneptok> Hobbsee: i doubt Novell is stupid enough to put the ndiswrapper gun to their support head. fwcutter ... maybe ...
<OpenSorce> mneptok, I am unsure if we are dealing with broadcom chips or not.....I do know that we tried the same test with another distro that setup wifi on the machine with little or no user action
<Hobbsee> OpenSorce: which was the other distro?
<OpenSorce> s/machine/machines
<Hobbsee> mneptok: yes, quite possibly.
<OpenSorce> Hobbsee, Mandriva 2008.0
<Hobbsee> OpenSorce: do they also isntall mp3 codecs by default, etc?
<mneptok> Hobbsee: they'd have to do some fancy detection and auto-blob-grab.
<Hobbsee> mneptok: which is hard, considering that most of them are hidden on cds :)
<OpenSorce> Hobbsee, mp3s played out of the box, so i would assume so, yes
 * mneptok speaks as if intimately familiar with fwcutter. heh.
<Hobbsee> OpenSorce: then that's why
<Fujitsu> mneptok: We have single-click fwcutting now, don't we?
<mneptok> Fujitsu: see last
<Hobbsee> OpenSorce: ubuntu chooses to not include non-free components by default, excluding certain drivers for wifi cards.
<Hobbsee> OpenSorce: which are all that are allowed to be redistributed in binary form.
<mneptok> nicaffeine. biab.
<Keybuk> Hobbsee: note that you're just assuming the driver for the wireless cards was non-free
<Hobbsee> Keybuk: granted.  which is why i keep asking for the bug # :)
<OpenSorce> Hobbsee, that's understandable....but it does make *nbuntu a less than perfect choice for new users
<Keybuk> OpenSorce may have found a completely legitimate problem
<Hobbsee> Keybuk: indeed.  but for the majority of users, it seems to be the "i've bought non-free hardware, and it dont work"
<Keybuk> although if it were six different laptops, I would be surprised
<Keybuk> since our test coverage would have revealed problems
<Hobbsee> exactly
<OpenSorce> Keybuk, on the test system that we use it has an older D-Link DWL-120+ usb wifi adaptors
<Keybuk> and something as serious as wide-spread wireless non-functioning would have definitely halted the release
<OpenSorce> Kubuntu thinks it's a wired device
<Keybuk> OpenSorce: have you tried the same device with Ubuntu?
<Hobbsee> i wonder if that's a mangler thing
<Hobbsee> that's at least been detected.
<OpenSorce> Keybuk, no I only review distros that use KDE as the primary wm
<Keybuk> OpenSorce: did you use the same wireless device for all six laptops?
<OpenSorce> Keybuk, no
<OpenSorce> Keybuk, and they weren't all laptops
<Keybuk> what were the wireless devices in the other laptops?
<Hobbsee> oh, interesting.  mandriva has a free adn a non-free version now too
<OpenSorce> Keybuk, I'm not sure.....our IT supposedly filed bug reports for each
<OpenSorce> Hobbsee, we debated over whether or not we should review only free distros but in the end we determined that a brand new user neither knows no cares about the difference
<OpenSorce> If I could make one recommendation it would be that *buntu include ndiswrapper in Live CD and generic install
<Hobbsee> ndiswrapper is on the live cd
<Hobbsee> that wont help you if you don't have the windows drivers, of course
<OpenSorce> Hobbsee, it's not found from the CLI in live cd mode....path issue?
<Hobbsee> and most people dont even seem to use ndiswrapper, so i'm unsure of the point of using it by default
<LaserJock> Ubuntu has been a blessing for me when it comes to wifi
<LaserJock> it's the only distro that will work out-of-the-box
<OpenSorce> Hobbsee, in the Mandriva tests our users just popped in the driver disks when the system asked and it set it up
<Hobbsee> OpenSorce: on the cd, but not installed.
<Hobbsee> right
<OpenSorce> seems like a simple thing really
<OpenSorce> From what I gathered it gives a choice of using a native driver if one is present and also offers the ndiswrapper version in if it does not work
<OpenSorce> LaserJock, I wish mine had....it would have simply been another review
<Hobbsee> where the latter is provided by a user driver disk, i take it
<OpenSorce> Hobbsee, yes it asks for the driver cd.....very much like windows I would imagine
<Hobbsee> OpenSorce: on the cd, but nto installed.  http://releases.ubuntu.com/gutsy/ubuntu-7.10-desktop-i386.list
<OpenSorce> Ok, well sent the last revision of the Kubuntu article to my boss and posted a copy on one of my websites. Thanks for your help again guys. Sorry I don't more information about the hardware that failed :-(
<LaserJock> OpenSorce: mind giving use a link?
<LaserJock> *us
<OpenSorce> LaserJock, sure: http://bigcatlinux.com/kufailure.html
<OpenSorce> tear it apart :-)
<OpenSorce> and before anyone asks, the system specs are listed in the final printing
 * Fujitsu is confused.
<Fujitsu> Why is that article on another distribution's site?
<OpenSorce> Fujitsu, it's one of mine.....just a temporary place to put it until priniting
<OpenSorce> we email the distro as a courtesy to let them see the articles prior to general release
<OpenSorce> I'm beginning to think that we should stay away from reviewing "free" distributions altogether though.....it just isn't fair to rate them with the same criteria as non-free
<Hobbsee> OpenSorce: i love the fact that youv'e mentioned *no* hardwrae specs in there at all
<Hobbsee> FYI, hardware keys work for almost everyone.
<OpenSorce> and before anyone asks, the system specs are listed in the final printing
 * Hobbsee comes to the conclusion that you guys arent running a fair test
<OpenSorce> Hobbsee, distros that fal generallly draw that conclusion it seems
 * Hobbsee also likes the incorrect grammar, and thought a reporter would have correct grammar, in order that the work is taken seriously.
<OpenSorce> *fail
<Hobbsee> can i ask *where* this is being published?
<OpenSorce> Hobbsee, this is a "pre-edit" copy
<OpenSorce> Hobbsee, I am not allowed to say
<Hobbsee> OpenSorce: also, nowhere does it state that kubuntu does Compiz-Fusion by default.  we actively say that they cant.
<Hobbsee> s/cant/dont/
<Hobbsee> OpenSorce: you're going on ubuntu features, and expecting them to show up in kubuntu - and blasting them when they dont..  this is unfair.
<Hobbsee> if ti looked identical to dapper, you clearly need your eyes checked - GUI looked quite different, colour-wise, at least.
<OpenSorce> Ubuntu.com says that compiz-fusion is installed by default.... kubuntu.com doesn't mention it at all....it's easy for a new person to assume that it would be the same on either version
<Hobbsee> kubuntu doesnt mention it because it's not there.
<Hobbsee> well, kubuntu gets a blasting there, and pieces of it are relevant.
<OpenSorce> Hobbsee, ok....but a new user still might expect that Kubuntu would be the same as Ubuntu with KDE instead of Gnome
<Hobbsee> a lot of it isnt, and there's a fair few jumps of incorrect things there.
<Hobbsee> and i could say something about the professional style, or lack of it.
<Hobbsee> but hey, you didnt ask for a review of your review, did you?  :)
<OpenSorce> Hobbsee, we do it from a new user perspective....not what I see but what I new user would see....
<OpenSorce> Hobbsee, you may as well attack my writing style....it's the last thing
<Hobbsee> OpenSorce: but, you are predisposed to hate it, and that comes thru in your writing.
<OpenSorce> Hobbsee, that isn't true....but I think a new user would hate it
<Hobbsee> kubuntu could do with a lot more work - people know that.  i think your review is inaccurate, though.
<Fujitsu> And - why Kubuntu?
<Hobbsee> Fujitsu: they only want to do kde-based distros.
<OpenSorce> Fujitsu, what he said
 * nixternal prints it out and takes it to the john
<Hobbsee> she.
<OpenSorce> pardon
<Hobbsee> it's a pity that you dont review the best, no matter waht the DE is.
 * Hobbsee wonders why a whole lot of new users seem *not* to hate it, then.
<OpenSorce> Hobbsee, ok.....you guys tell me that Ubuntu would be a better choice for new users than Kubuntu.....that the wifi issues would be resolved in that version....I will do my best to get my boss to let me review it
<Hobbsee> OpenSorce: some of them will be, sure.
<OpenSorce> ok, anyone else?
<Hobbsee> but, for the rest, see above.
<nixternal> KutoiletPaper
<nixternal> ya, I said it
<OpenSorce> Hobbsee, I dare say that you may not have as much contact with new users as our research department does
<OpenSorce> nixternal, haha!!
<Hobbsee> perhaps.
<OpenSorce> nixternal, wonder if i can get away with changing the article name to that
<nixternal> I have to admit though, I can't make sense of the article
<Hobbsee> i've only seen what type your group is by your conduct, and your article.
 * Hobbsee has a fair idea of what goes on in #kubuntu
<nixternal> OpenSorce: I don't care what you change it to, it should be title "My Biased Opinion - W/O a Proper Premise"
<OpenSorce> nixternal, I didn't list my personal feelings because they are irrelevant to new users
<Hobbsee> yet they show in your work.
<Fujitsu> OpenSorce: Were the six machines you tested on, perchance, the same model?
<OpenSorce> personally, I like Ubuntu.....I like that it takes the old stale Debian distro puts new software in it and makes it a true modern distro....for even slightly experienced users I recommend it
<Fujitsu> It's very unlikely that they'd all have no multimedia keys, need restricted drivers, all have broken restricted drivers, and all have broken wireless..
<Hobbsee> Fujitsu: unless they're extremely esoteric, and use non-sane defaults.
<OpenSorce> Fujitsu, I didn't state the results of any test except the test on the "test" machine in that article
<Hobbsee> that doesnt answer the quesiton
<nixternal> heh, first time I ever looked at BigCat Linux..it looks familiar though, it has that Steve Jobs feel to it :p
<OpenSorce> Fujitsu, and we didn't do full reviews on the other machines....LaserJock suggested we try other machines to see if the wifi problem was isolated so we did
<Daskreech> Hobbsee: Machine have hardware "defaults"?
<Hobbsee> oh, i see.
<OpenSorce> nixternal, I'm not here to discuss BCL
<Hobbsee> Daskreech: sure.  most machines will give the same keycode for crt/lcd switch.
<Daskreech> ah
<OpenSorce> Fujitsu, and since we didn't do complete tests on the other machines I made no mention of the 6 machine test in the article
<Hobbsee> OpenSorce: so you picked the worst one?
<Hobbsee> sounds like malicious use of the "facts" to me.
<OpenSorce> Hobbsee, well considering wifi didn't work on any, I hardly see how that's true
<Hobbsee> OTOH, i could write a review saying that kubuntu works perfectly on my machine.
<Hobbsee> OpenSorce: you havent told us what machiens they were.  read above.
<OpenSorce> Hobbsee, then you should
<Hobbsee> and the other machines i tested.
<Hobbsee> but, i've already seen a very good review from a guy named Brian Delacey, published in a good magazine, and preferred to give him a quote.
<Hobbsee> so don't see the point.
<Hobbsee> besides, your review looks like a blog post.  i'd prefer to contribute to actual, proper reviews.  *shrug*
<Daskreech> OpenSorce: I'm sorry I wasn't here. What are you asking?
<OpenSorce> Hobbsee, Brian does very good work.....I wish I could write as well as he does
<Hobbsee> OpenSorce: learn it :)
 * nixternal feels a blog post coming on...but pulls the plug on the server to prevent it!
<Hobbsee> OpenSorce: what is your affiliation to the site that it's on?
<OpenSorce> Hobbsee, why does that matter?
<Hobbsee> OpenSorce: because it makes you biased against non-mandriva distributions, as you participate in a mandriva-spinoff.
<Hobbsee> OpenSorce: and to not put in a disclaimer about that will make your work less credible.
<Hobbsee> did you not study report writing in school?
<OpenSorce> Hobbsee, ok....Big Cat Linux is a sort of sub-distro I am basing on Mandriva....it is NOT for new users and thereby does NOT produce a conflict of interest
<nixternal> Hobbsee: this is the same thing that the PCLOS crew did, so no worries, let them publish it and get on with it
<Hobbsee> OpenSorce: ah, but it's still based off mandriva, so this is clearly your preferred distribution, hence you'll compare everything to mandriva, and not note any of mandriva's pitfalls.
<OpenSorce> Hobbsee, and I would base it on ANY other distro that works
<Hobbsee> OpenSorce: but, by all means, publish your article.  You'll just lose (presumably more of) your credibility.
<OpenSorce> Hobbsee, whatever you need to tell yourself sweety.....see you guys next release
<Hobbsee> good riddance.
<nixternal> just so you know, Mandriva didn't work with my WiFi card (Broadcom) and Kubuntu does...so maybe I should right a ....good he left
<Hobbsee> haha
<Hobbsee> i never thought i'd end up blasting a guy over writing style, and inaccuracies in his writing, in a computer channel.
<Hobbsee> i nevr thought i'd need to know that information again :D
<nixternal> just me right?
<nixternal> haha
<Hobbsee> but hey, now i feel like blogging.
<nixternal> hahahahaha, damn you!
<Hobbsee> reminding people about primary and secondary sources, and bias and such.
<nixternal> I can't be mean in my blogs anymore, there are way to many blog cops out there, and if I am mean, then Google won't hire me :p
<Hobbsee> heh
<Daskreech> I would
<nixternal> lord knows I get the phisherman Google headhunters emailing me
<Fujitsu> That's a pre-edit copy... I'd certainly hope so.
<Daskreech> Oh I read a thing in maxim today that chicago is the toughest City in the US
<nixternal> pre-pre-pre-pre-pre-pre....you get the idea :)
<Hobbsee> Fujitsu: uh, yeah.
<Daskreech> So it would be local pride :)
<nixternal> Daskreech: ya, we beat up people just for fun
<nixternal> Daskreech: the only reason we were rated the meanest, is because Maxim was to scared to go to Detroit
 * Hobbsee shakes her head some more.
<nixternal> hahaha
<nixternal> stop shaking, you might lose something there
<Hobbsee> you tell people it's not as good as mandriva, then you wonder why they all say they hate it, and mandriva rocks.
<Hobbsee> yeah, no shit, and -2000 points for a fair test.
<Tm_T> :(
<Tm_T> but he can write!
<nixternal> speaking of Mandriva, I still have to interview them
<Tm_T> there's no "like d000d"
<Hobbsee> all i want to know now is what he writes for, to see if any other of their work is any better.
<nixternal> umm, is this a Kubuntu takeover by chance? I just realized where we were
<Hobbsee> nixternal: no.  he asked here, anyway.
<Tm_T> nixternal: sssshhh
 * nixternal sneaKs bacK to the land of K
<nixternal> btw, it was LaserJock's fault for all of that
<Tm_T> nixternal: Kood, I do too (its Kooler place anyway)
<LaserJock> nixternal: what's my fault?
<nixternal> LaserJock: everything
<nixternal> oh nos, me goes
<Tm_T> LaserJock: definately everything
<Tm_T> nixternal: remember the almighty KDE!
 * Tm_T hides
<Tm_T> OpenSorce: hello dear, I missed you
<OpenSorce> Tm_T, hi :-)
<Fujitsu> O_o
<Hobbsee>  /kb OpenSorce now go troll somewhere else.  Clearly, you missed the /topic
<Hobbsee> idiot.
<Hobbsee> no point banning a proxy, anyway
<LaserJock> Hobbsee: I'm not really sure that helped the situation :/
<Hobbsee> LaserJock: perhaps not.  the guy is going to troll in the article anyway.
<Daskreech> LaserJock: Last time he was here he was asking for some sort of official sanction that the devs agree that Kubuntu is a failure
<Daskreech> LaserJock: If you can think of something that would help the situation I'd love to see you try
<Hobbsee> LaserJock: now, i think that telling him to FOAD would be somewhat appropriate, but also unhelpful
<LaserJock> well, ignoring him would be the best way to go, IMO
<LaserJock> he's just looking for a reaction
<LaserJock> and he got one
<Hobbsee> next time i'll just remove him.
<Daskreech> LaserJock: he's been around for two solid weeks
<persia> Pacificity is likely best.  It's more satisfying to be able to write "and I was banned from IRC for attempting to get an update on the situation" instead of "I found the live-support options limited without a paid support contract".
<LaserJock> Daskreech: yes, I know, I delt with him on Release day
<Daskreech> LaserJock: did it help?
<LaserJock> I thought so
<LaserJock> he said he appreciated us looking into the issues
<LaserJock> I realize is review is totally whacked out, but it'd be nice to retain the "but the devs seem cool"
<Hobbsee> LaserJock: as in, give him lots of PR speak back, without telling him anything?  :)
<Daskreech> Did he tell us anything?
<LaserJock> Hobbsee: no, but not kicking him off the channel would an inbetween ;-)
<LaserJock> at the time he wasn't doing anything that would warrant a kick
<ajmitch> it's done now, anyway
<LaserJock> very true
<Hobbsee> woot!  scrapped article!
<Hobbsee> seems the guy cares somewhat about his credibilty after all - particularly when we've pretty much found out who he is.
<jdong> whoo, this LP scraper works
 * jdong feel so proud of his 10 minutes of work :)
<jdong> now, I can lpget azureus/hardy and it scrapes Launchpad for the source packages
<jdong> no need to keep sources.list up to date
<Fujitsu> Hobbsee: What?
<Hobbsee> Fujitsu: <OpenSorce> Ok, as charming as this conversation is, I've decided to scrap the Kubuntu article altogether....it causes too many hard feelings and my objectivity is in question so I think I'll stick with positive articles only henceforth
<Fujitsu> Yay!
<Hobbsee> Fujitsu: some people went sleuthing.
<Fujitsu> jdong: LP is getting a feature whereby you can dget http://launchpad.net/ubuntu/<series>/<sourcepackage> or similar in 1.1.11.
<Fujitsu> Hobbsee: What was revealed?
<Hobbsee>  Not really....I also used to sell insurance....but you know that if you went to shawnpeterman.com....and I have a daughter named Sarah :-)
<Hobbsee> [17:30] <OpenSorce> In any case, I used to write for the Linux Is Freedom Endeavor years ago and some of my articles got picked up my larger venues and published then when Lindows threatened me with a lawsuit I changed the name I write under.....I'm also gay and have a gorgeous boyfriend.....anything else you want to know? :-)
<Hobbsee> Fujitsu: not overly much.
<Hobbsee> but enough
<Hobbsee> like his home # and such :)
<Fujitsu> Hah.
<jdong> Fujitsu: hmm, what do you mean?
<jdong> Fujitsu: what would the URL return?
<Fujitsu> jdong: You run dget on it, and it will grab the latest version of the source package.
<jdong> Fujitsu: ah, ok, that's very cool
<jdong> that'd be so much better than scraping LP with a ruby script
<Fujitsu> Yeah.
 * jdong wonders if he can quickly turn his scraper into a madison clone too
<jdong> *grin*
<Fujitsu> jdong: rmadison -u ubuntu?
<jdong> Fujitsu: how often is that updated?
<Fujitsu> jdong: AFAIK it doesn't have to be.
<jdong> Fujitsu: even better :)
<Fujitsu> Probably queries the DB directly.
<Fujitsu> (the CGI on the other end, that is)
 * jdong wonders if he can write a heuristic for getting the name of a package to backport
<jdong> from a LP bug title
<jdong> I'm thing, filter out "please" "backport" "from" "to", all Ubuntu release names, and inverse-spellcheck
<jdong> whatever's left is probably the package name
<Fujitsu> Heheh.
<jdong> :)
<slangasek> lifeless: the nicest thing I can say about scons is that there are no .la files to purge
<slangasek> also, insomnia is irritating
 * slangasek tries sleep again
<Hobbsee> hiya slangasek
<dhosta> Has anyone in here had any luck running rationals Purify on Ubuntu?
<persia> dhosta: You might get a better answer to that question on either #ubuntu or some rational contact point (although you may not)
<dhosta> rationalÅ forums are a dead end, and #ubuntu is tragic :/
<pwnguin> i dont think the solution to either of those problems is taking developer attention away from the things they're already doing
<persia> dhosta: Yes, unfortunately both are true, hence the qualifier.  It's just that people in this channel tend to be developing Ubuntu, and don't tend to use rational products.
<ivoks> khm...
<ivoks> telnet ntp.ubuntu.com ntp
<ivoks> dead?
<Hobbsee> odd way to do a ntpdate...
<ion_> Since when does ntp use tcp?
<ivoks> eh, you're right...
<ivoks> but still... service is unavailable
<fabbione> Amaranth: not anymore. it's Canonical IS running it now
<Spads> try now
 * Fujitsu notes he has never seen europium running ntp, at least since ntp.ubuntu.com was pointed at it.
<CyberSnooP> Upgrading to gutsy on my server generated a 0-byte initrd and made the new kernel unbootable
<CyberSnooP> Is there any information I can gather to help create a good bug-report?
<CyberSnooP> (before i'm manually trying to fix al the things, that is)
<minghua> CyberSnooP: It's weekend, I'm not sure many people are around.  You can also trying asking in #ubuntu-bugs and #ubuntu-kernel.
<stgraber> actually there are many people around but probably having breakfast before fosscamp :)
<CyberSnooP> Weekends are a good time to update your home server I'd say :-P
<CyberSnooP> Oh, okay. Well, I don't want to be cross-posting in IRC too much, but I'll try in #ubuntu-kernel
<IntuitiveNipple> Is there a meta-package for installing a 'correct' LAMP server, or alternatively a recommendation on which packages to install for Apache2 + PHP5 that avoids the endless loop of conflicts between pure apache2 + mpm-worker (which needs to use FastCGI for PHP5)  versus php5 wanting to install libapache2-mod-php5 + apache2-mpm-prefork ?
<Fujitsu> IntuitiveNipple: You need mpm-prefork for PHP.
<Fujitsu> It's not threadsafe.
<Mithrandir> apache2 depends on a-mpm-worker | a-m-p, so there's no conflict there
<Keybuk_> \o/  Bug #158040
 * Keybuk_ fully rescinds the death order on BenC
<IntuitiveNipple> And php5 depends on apache2-mpm-prefork, which when selected (in Synaptic) *deselects* apache2-mpm-worker
<Fujitsu> launchpad bug #158040
<Ubotwo> Launchpad bug 158040 in tracker "tracker doesn't leave any for the rest of the class" [High,New] https://launchpad.net/bugs/158040
<Keybuk_> you have to say "Launchpad" now?
<IntuitiveNipple> Keybuk_: That bug might explain why I couldn't add inotify watches for one of my own processes... maybe tracker had exhausted the per-user limit
<IntuitiveNipple> I was trying to fin a way to get the inotify library to report *all* inotify watches in operation but there doesn't seem to be way to check
<IntuitiveNipple> s/fin/find/
<Fujitsu> Keybuk_: ubotu is broken (got lost in a netsplit), and the backups require `launchpad bug'
<Hobbsee> Keybuk_: temp bot
<liw> Keybuk_, oh, I didn't know that inotify requires doing things per directory -- I thought there was some wildcard that you could use to apply for everything in a filesystem, and stuff like that
<Mithrandir> liw: that'd be useful, so no, we don't have that.
<liw> I guess I shouldn't blindly assume people do good designs
<Keybuk_> Mithrandir: I'm very tempted to implement a recursive inotify
<Keybuk_> assuming it's easy in the kernel to get the parent directory
<Mithrandir> Keybuk_: I think I whined about that not existing about two minutes after you first explained inotify to me. :-P
<Keybuk_> either that, or remove the ridiculous limits on the number of inotify instances
<Mithrandir> it makes much more sense to just have it be a glob, IMO
<Keybuk_> glob would be hard I think
<Mithrandir> also, that limit might explain why tracker was never happy on my system.. 113k directories in ~
<Keybuk_> yeah, 8000 directories is about ~/.gconf only or something
<Mithrandir> why isn't .gconf just a single file?
<Keybuk_> ask desrt
<Mithrandir> it could be, like, an sqlite db or something.
<Fujitsu> Mithrandir: Because we're not the Windows Registry?
<Mithrandir> desrt: whine.
<ion_> I was under the impression that tracker includes .dirs
<Mithrandir> desrt: ^^
<liw> I have 411 entries under .gconf
<tepsipakki> dconf  should change that
<ion_> mithrandir: Yeah, sqlite should be just about perfect for it.
<Mithrandir> Fujitsu: using a zillion xml files changes that?
<Fujitsu> Mithrandir: I'm sure it does, somehow.
<Mithrandir> well, technically gconf has pluggable backends.  I guess I should write one that is less insane.
<Mithrandir> .. one which plugs into a revision control system, preferably.
<Fujitsu> That sounds nice.
<ion_> Well, you could just use sqlite and create a database schema that does history.
<Mithrandir> ion_: that doesn't give me merging.
<liw> Mithrandir, optionally plugs in (or optionally doesn't plug in), for people who keep their $HOME in a vcs already, perhaps?
<Keybuk> Mithrandir: http://thread.gmane.org/gmane.linux.kernel/391851
<Mithrandir> liw: htat's the idea, yes.
<tepsipakki> http://live.gnome.org/dconf
<Mithrandir> Keybuk: looks useful.
<tepsipakki> let's get that in hardy :P
<tepsipakki> "hardly"
<Mithrandir> tepsipakki: dconf still has the minor disadvantage of being vapourware, doesn't it?
<Mithrandir> Hobbsee: the crazy american tourist is here!
<Hobbsee> Mithrandir: heh :)
<Hobbsee> Mithrandir: are you going to get him to try to buy you some beer?
<tepsipakki> Mithrandir: maybe so, but some code at http://git.desrt.ca/
<Mithrandir> Hobbsee: given the legal drinking age here is 21, I think he might have trouble buying.
<Hobbsee> Mithrandir: worth a shot, anyway :)
<Mithrandir> tepsipakki: I could just find desrt around here and prod him.
<tepsipakki> Mithrandir: oh :)
<spasticteapot> What's being done to improve battery life?
<spasticteapot> For example, I have to run Laptop_mode manually, and I can't even get USB autosuspend to work.
<MacSlow> Greetings everybody!
<alex-weej> hi MacSlow
<mjg59> popey: Your Nokia PSU is 230V only
<twi1> hi
<twi1> what happened to the linux-image-debug* packages?
<crimsun> they're still there in gutsy
<twi1> mmh, not for powerpc
<slangasek> lifeless: score, opensync 0.33 built and the python bindings are unusable out of the box \o/
<StevenK> Unusable, neat.
<Hobbsee> dholbach!
<dholbach> hi Hobbsee
<luk_> hi dholbach, hi Hobbsee
 * Hobbsee waves sleepily to luk_
<dholbach> hey luk_
<geser> Hi dholbach
<lifeless> slangasek: woot!
<Keybuk> GOD DAMNIT GNOME POWER MANAGER!
<StevenK> Dear.
<Hobbsee> Keybuk: it's just taking it's commands from the boss, on irc.s3kr3t.hobbsee.org....
<Hobbsee> nothing major
<siretart> asac: didn't you say yesterday you had an updated network-manager package in your ppa? I fail to spot it on https://edge.launchpad.net/~asac/+archive
<twi_> mmh no mention in git log why CONFIG_DEBUG_INFO was removed from powerpc/config
 * Hobbsee wonders when pidgin will go thru gutsy-security
<Riddell> mdz: http://obso1337.org/hci/kde/Kubuntu_Installation_Usability_testing_June_2007.pdf
 * StevenK grumbles.
<StevenK> Why does autogen depend on base-files 4.0.1?
<Mithrandir> StevenK: for GFDL or something?
<StevenK> Hrm. That might be it.
<StevenK> Now I need to merge that. Or beg doko or something
<minghua> GFDL?  or GPL v3?
<StevenK> Ah. GPL-3
<asac> siretart: its ~ppa3
<siretart> asac: but the verison in gutsy is even 'higher'. so I have to downgrade to get the 'fix'?
<asac> yes
<asac> i should upload a higher version ... but i will rather go for sru directly
<black_13> i notice that ubuntu is very seemless in its start up to xorg
<black_13> and is this dependent on using grub as a bootloader?
<crimsun> no, it's not.
<crimsun> [dependent on grub]
<keescook> mjg59: woohoo!  I've fixed another person's suspend problems.  :)
 * pitti hugs keescook
<jdstrand> pitti: are you planning on adding a blueprint or something for backup solutions for UDS?
<jdstrand> (I didn't see one)
<pitti> jdstrand: it's not a topic for hardy
<pitti> jdstrand: we can dump the bullet point list into a wiki page, of course
<jdstrand> hardy+1?
<pitti> jdstrand: yes
<jdstrand> bummer...
<jdstrand> but I understand
<chowmeined> what are the plans for hardy?
<mjg59> keescook: Sweet!
<keescook> mjg59: and I just finished dumping my notes: https://wiki.ubuntu.com/UnderstandingSuspend
<twi_> did you already branch the kernel for herdy?
<jdstrand> http://ch.tudelft.nl/~arthur/nss-ldapd/news.html
<siretart> keescook: thanks for doing this!
<keescook> siretart: you bet; I'm glad to have something to reference for myself now too.  ;)
<calc> i noticed that ooo-langpacks isn't on the official schedule for UDS yet(?)
<calc> its on the wiki description list but not on the time schedule
<pitti> calc: it might be a dynamically scheduled one?
<pitti> calc: those will be done right before starting each day next week
<calc> pitti: oh ok
<slangasek> keescook: mjg59 says you have a library to be sponsored
<StevenK> pitti: Ping
<pitti> StevenK: pong, right over here :)
<StevenK> pitti: I saw you, just don't want to yell over the room. :-)
<StevenK> pitti: I was looking at anjuta, and one of its Build-Depends looks to require base-files 4.0.1
<stgraber> ^^ two people talking on IRC when they are in the same room ...
<StevenK> stgraber: There are other dicussions going on. :-)
<pitti> StevenK: hm, seems for hardy it was only bumped to ubuntu6, but not merged
<StevenK> pitti: Agreed.
<pitti> StevenK: seems you just voluntold yourself to do that :-P
<stgraber> StevenK: MOTU room ?
<StevenK> pitti: Well, my problem is the changelog for base-files. Would you mind glancing at it and seeing if you think it's sane.
<StevenK> pitti: http://changelog.debian.net/base-files
<StevenK> stgraber: Yup.
<pitti> StevenK: ok, I read it; I think it's alright, and we archive admins already do the GPL version check with new sources
<pitti> StevenK: I see that this will magically 'break' a lot of copyrights, but if Debian goes that route, I think it's ok for us, too
<StevenK> pitti: Yes, that was my problem, too. I'm happy to merge it and upload it. Do you want to eyeball the debdiff, or just throw it up?
<pitti> StevenK: that sounds simple enough to me, go ahead
<mathiaz> soren: would you mind having a look at bug 130836 ?
<StevenK> pitti: Should I bother with ubuntu-devel -> ubuntu-devel-discuss ?
<StevenK> pitti: (For the Maintainer field)
<pitti> StevenK: if you spot it, feel free to correct the Maintainer: field
<StevenK> pitti: Uploaded/uploading
<chx> hi. https://blueprints.launchpad.net/sprints/uds-boston-2007/+roadmap this has a typo Improve Windows integration as a sever and a client for Ubuntu <= either sewer or server. both would fit Windows :P
#ubuntu-devel 2008-10-20
<jdong> pitti: eep do we have a regression of bug 95368 on our hands?
<ubottu> Launchpad bug 95368 in hal ""Cannot remove directory" on unmount due to stale .hal-mtab entries" [High,In progress] https://launchpad.net/bugs/95368
<jdong> seems like 4 users have reported it on Intrepid
<TheMuso> .c
<jdong> Password:
<TheMuso> heh
<slangasek> TheMuso: I guess that means you think that yes, we should fix it for intrepid? :)
<TheMuso> slangasek: Yes, I'm going to look into it today.
<slangasek> ok
<slangasek> how is bug #274124 coming along?
<ubottu> Launchpad bug 274124 in pulseaudio "Race condition in pulseaudio loading for GNOME session" [High,Confirmed] https://launchpad.net/bugs/274124
<slangasek> will we get an upload today?
<TheMuso> slangasek: Just have to slap the solution into the package. On my agenda also.
<ScottK> superm1: Would you please look at the last comment in Bug 207473 and see if there's anything Dell specific that could be at issue.
<ubottu> Launchpad bug 207473 in hal "Screen brightness double level changes" [Medium,Confirmed] https://launchpad.net/bugs/207473
<ScottK> slangasek: Would you please accept milter-greylist?
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.  That's the libspf2 transition we discussed at the last release meeting done then.
<slangasek> yep \o/
<jdong> setting up Gutsy VM's really takes you back....
<jdong> it's amazing how much we've progressed in just a few release cycles.
<calc> slangasek: sorry i thought we were supposed to get special approval for any upload during final freeze
<TheMuso> slangasek: Just uploaded the pulseaudio race condition work-around.
<persia> TheMuso, Should that cover device recognition as well, or just desktop sounds?
<TheMuso> persia: just the desktop login sound race condition.
<persia> OK.  I'll file a bug then.  Thanks.
<TheMuso> persia: Whats the problem?
<persia> TheMuso,: I rebooted with a USB interface connected, and only the USB interface shows in pavucontrol : the onboard is missing for output (but is present for input).
<TheMuso> persia: That could be the race in effect there.
<TheMuso> i.e canberra-gtk-play has the onboard card, so pulse can't grab it.
<persia> That's what I was thinking.  I'll retest with the new one before I file the bug then.
<TheMuso> persia: What session manager is this with? gnome-session, or something for mobile?
<persia> gnome-session : this is my primary laptop.
<TheMuso> Ok then.
<persia> I think -mobile uses gnome-session as well, and -mid doesn't use pulse.
<TheMuso> Right.
 * persia 's -mobile HW is currently on loan
 * TheMuso nods.
<persia> TheMuso, Just as a counter-case, as long as I don't attach the USB device until my session is live, this doesn't happen, so it's not a core problem, and easily worked around for release.
<TheMuso> persia: Right.
<persia> linux-rt and friends uploaded.
<ScottK> slangasek: I've packaged and tested the clamav RC.  See Bug #286176.  The debdiff is painful and makes it look worse than it is.  I had to add one line to the freshclam postinst after I made the debdiff.
<ubottu> Launchpad bug 286176 in clamav "FFe Request for Clamav 0.94.1 RC" [Undecided,New] https://launchpad.net/bugs/286176
<ScottK> slangasek: What else would you like to see in the FFe?
<ScottK> slangasek: I went ahead and uploaded it so you can review/accept/reject from the queue
<slangasek> calc: all uploads during final freeze have to be approved by the release team; that doesn't mean the approval has to happen /before/ you upload, because they'll be held in the queue anyway :)
<slangasek> TheMuso: thanks, will review :)
<slangasek> ScottK: right, I'll have a look shortly
<ScottK> slangasek: I'm heading to bed, so I guess I'll find out what you decided in the morning.
<slangasek> persia: I'm a bit confused by the linux-rt upload; the changelog seems to bear no relation to the previous version?
<slangasek> seems to have motu-release ack though, so approving (and closing bug #281276 by hand)
<ubottu> Launchpad bug 281276 in linux-rt "Upgrade linux-rt to 2.6.27" [Undecided,Confirmed] https://launchpad.net/bugs/281276
<persia> slangasek, From what I understand, it was completely rebased on the new kernel, and the previous source was not used in it's construction.
<slangasek> hum, ok
<persia> With luck, we'll be able to come up with some sane way for the packages to interact in jaunty : the kernel team has been very busy with preparing both 2.6.26 and 2.6.27 this cycle.
<slangasek> btw, it appears that bug #229499 remains unfixed in this upload
<ubottu> Launchpad bug 229499 in linux "Latency regression with real time kernel and dynamic ticks feature" [Undecided,Fix released] https://launchpad.net/bugs/229499
<slangasek> (the only linux-rt bug that was targeted to intrepid)
<persia> Bother.  Thanks for pointing that out.
<StevenK> slangasek: I've just uploaded linux-lpia-meta, if you'd like to cast your eyes over it
<slangasek> StevenK: accepted, thanks
<StevenK> slangasek: Thanks!
<pitti> Good morning
 * wgrant escapes quickly.
<Treenaks> hi pitti
 * Hobbsee throws pitti a gummybear, and a bit of chocolate cake
<pitti> TheMuso: festival has already been in main, so I just adjusted recommends, not demoted festival; likewise, flite is already in main (the library only), I guess it's a build dep
<TheMuso> pitti: right.
<pitti> jdong: it has never really been fixed
<dholbach> good morning
<Hobbsee> morning dholbach
<dholbach> hi Hobbsee
<NCommander> directhex, ping
<tkamppeter> pitti, I have fixed an important bug in the CUPS package (bug 286048) on the Debian BZR.
<ubottu> Launchpad bug 286048 in cups "RELEASE FREEZE EXCEPTION: When requesting n copies, n*n or even n*n*n copies get printed" [Critical,Fix committed] https://launchpad.net/bugs/286048
<pitti> tkamppeter: saw your mail; I'm currently building the package
<directhex> NCommander, be quick, i need to go to work in 8 minutes
<NCommander> directhex, how's hardware support on ia64
<NCommander> directhex, I'm rebasing the -ports kernel to 2.6.27, and it seems whoever did the ia64 kernel press and held enter during make config, so most of the drivers are compiled out unless I'm loosing my mind
<tkamppeter> pitti, did the release team already accept it?
<directhex> NCommander, AFAIK pretty good (i run SLE on the kit at work)
<NCommander> directhex, will you be willing to smoke test the ia64 kernel once I finish rebasing?
<pitti> tkamppeter: I need to upload it first :) and yes, I'll accept it afterwards (it is your upload, I'm just sponsoring)
<directhex> NCommander, i doubt i'd be able to i'm afraid, it's production kit
<NCommander> know where I can find someone with some spare ia64 hardware?
<tkamppeter> pitti, are you in the release team?
<pitti> tkamppeter: yes
<tkamppeter> pitti, I have some other bugs where I am not sure whether we should make a freeze exception:
<pitti> tkamppeter: if the fixes are obvious and easy, and you have packages prepared, please upload them
<tkamppeter> pitti: bug #284444
<ubottu> Launchpad bug 284444 in system-config-printer "Printer Configuration Program Crashed" [Medium,Triaged] https://launchpad.net/bugs/284444
<pitti> tkamppeter: at this point, we can accept those until this afternoon, but they must *really* be safe
<tkamppeter> pitti, the s-c-p fix is uploaded.
<tkamppeter> pitti, after uploading I get
<tkamppeter> Rejected:
<tkamppeter> Signer is not permitted to upload to the component 'main' of file 'system-config-printer_1.0.5+git20080819-0ubuntu6.dsc'.
<pitti> tkamppeter: oh, someone needs to extend your upload ACL for that; mdz, whom to ping for that?
<tkamppeter> It is strange for me. The message which one usually gets on an after-freeze upload is different.
<pitti> tkamppeter: yes, I think your upload ACLs were put in place recently, and they forgot s-c-p
<tkamppeter> mdz has removed my general core-dev right, probably he assumed that my ACL is in place, but probably no one touched it.
<tkamppeter> mdz, can you set the upload ACLs in Launchpad? Or did you do it already? Has Launchpad perhaps a bug?
<tkamppeter> pitti, I can send you the two packages, so that you can upload them, as I do not know until when my upload gets fixed.
<pitti> tkamppeter: ok
<pitti> oh, happy Feisty EOL day!
<pitti> kees, jdstrand: ^ happy? :)
<tkamppeter> pitti, the packages are now on http://www.linuxfoundation.org/~till/tmp/ubuntu/intrepid/fe/
<tkamppeter> It is all tested, the packages actually fix the reported bugs and Ghostscript two PDF-workflow-related upstream bugs in addition.
<tkamppeter> On Ghostscript I have mass-tested all built-in drivers with a script which creates a queue for every driver, passes a job through it, and then checks for errors and a reasonable output size.
 * fabbione hugs pitti 
 * pitti hugs fabbione back; Padre!
<superm1> ScottK, it's actually a kernel bug
<superm1> ScottK, caused by the way the BIOS allows for multiple different video cards
<superm1> ScottK, more or less bug 226981
<ubottu> Launchpad bug 226981 in linux "Hardy: FN-up/down keys change brightness too rapidly on DELL XPS m1330" [Low,Confirmed] https://launchpad.net/bugs/226981
<superm1> ScottK, i'll add the upstream kernel.org bug tracker for the bug
<superm1> ScottK, that and at least one of those bugs is mis appropriately marked as a duplicate.  if there are *any* hangs associated with it, it's a kernel bug about key releases; bug 261721
<ubottu> Launchpad bug 261721 in linux "X never sees brightness key release events" [High,Triaged] https://launchpad.net/bugs/261721
<NCommander> hey DktrKranz
<DktrKranz> hi NCommander
<NCommander> DktrKranz, I verified the GNAT packages work :-)
<DktrKranz> we've finished! \o/
<DktrKranz> yes, I noticed, thanks ;)
<NCommander> SO now what happens?
<NCommander> (I assume you need to get the archive admins to push to -updates, right?
<DktrKranz> martin already copied to updates
<NCommander> WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
<directhex> i wonder if i could convince the powers that be on the ubuntu forums to add "--prefix=/usr " to the swear filter
<NCommander> :-)
<NCommander> ah, it feels good to finally finish that gnat transition
<DktrKranz> sure. I'll adjust the spec accordingly soon
<DktrKranz> and eventually track for regressions/pending issues, just to make sure we have really finished
<NCommander> Probably the first/only transition to be done entirely through -updates ;-)
<NCommander> DktrKranz, the packages weren't installable. Anything at this point is an improvement
<DktrKranz> I hope to avoid those in the future
<NCommander> We have to make sure our version of gnat stays in sync with Debian
<DktrKranz> gnat-4.2 is no longer here
<DktrKranz> and I hope 4.1 will go away soon
<NCommander> We can NBS it out on Jaunty
<NCommander> it won't be that difficult
 * NCommander just needs his MOTUship ;-)
<DktrKranz> go for it, then ;)
<slangasek> I don't think you mean NBS
<NCommander> er
<NCommander> Just removing the rdepends and getting rid of it
 * NCommander drinks his coffee
<slangasek> why are you drinking coffee at 3am?
<DktrKranz> let's think of it for jaunty, maybe together with debian maint
<NCommander> slangasek, cause I woke up at 12:00
<seb128> NCommander: broken timezone!
 * slangasek scratches his head
<amitk> mvo: MacSlow: new libgksu works great
<MacSlow> amitk, sweet news ... thanks for the feedback!
<DktrKranz> slangasek: thanks for noticing my bad upload, I was definitely under crack :)
<mvo> cool, thanks amitk!
<NCommander> amitk & seb128 I have a sleep disorder
<directhex> 48 hour days?
<slangasek> DktrKranz: that's what I'm here for... :)
<DktrKranz> hehe
<slangasek> NCommander: you don't think drinking coffee at 3am is a cause of disorder?
<tkamppeter> pitti, when you approve Ghostscript, then take also the new foomatic-db which I have put onto the same URL now. This foomatic-db has a workaround for a bug in Ghostscript removed.
<seb128> NCommander: stop working so much and go to bed ;-)
<NCommander> seb128, I woke up after 12 hours of sleep at 0:00
<tkamppeter> pitti, the removal of the workaround is also covered by the Ghostscript mass testing which I did.
<pitti> tkamppeter: gs and scp are done
<MacSlow> mvo, can I mark LP #275172 fixed then?
<seb128> hey pitti!
<ubottu> Launchpad bug 275172 in gksu "libgksuui crashes on statup in the blur code on some systems" [Medium,In progress] https://launchpad.net/bugs/275172
<pitti> tkamppeter: does the workaround hurt for anythuing?
 * pitti hugs seb128, bonjour
 * seb128 hugs pitti
<seb128> pitti: how are you?
<tkamppeter> pitti, the approval message of gs appeared some seconds ago.
<MacSlow> mvo, or do we need more positive feedback about the crasher being fixed?
<pitti> seb128: quite okay, and you?
<seb128> pitti: good, I got over my cold and slept enough during the weekend, ready for a GNOME marathon today ;-)
<mvo> MacSlow: I think its fine to close it now we got positivie feedback and no negative
<slangasek> so who here is good at debugging threading race conditions?
<mvo> MacSlow: feel free to add "please reopen if you still experience this problem" or something like that
<tkamppeter> pitti, so can you approve foomatic-db, too? It only removes the workaround for a bug which is now fixed in gs (bjc600/bjc800).
 * NCommander runs really fast from slangasek 
<pitti> tkamppeter: you can't upload that either?
<NCommander> slangasek, what has race conditions?
<slangasek> NCommander: libgstpulse or libpulse
<NCommander> Deadlock?
<tkamppeter> pitti, I will try. Perhaps in the ACL only somne packages were forgotten.
<slangasek> segfault on shutdown (and possibly at other times)
 * NCommander winces
<NCommander> That sounds evil to fix
<slangasek> well if it was trivial I wouldn't be trawling for people good at thread debugging. :)
<NCommander> slangasek, is there an upstream bug?
<slangasek> I have no idea
<DktrKranz> pitti, mind copying ocamlsdl (bug 249355) to hardy-updates? It doesn't show up in pending-sru page, but it has been verified long ago.
<ubottu> Launchpad bug 249355 in ocamlsdl "ocamlsdl and lablgl conflict over Raw" [Undecided,Fix committed] https://launchpad.net/bugs/249355
<pitti> DktrKranz: thanks, done
 * DktrKranz hugs pitti 
 * pitti hugs back DktrKranz
<MacSlow> mvo, should I also close all the duplicates on LP #275172 ?
<ubottu> Launchpad bug 275172 in gksu "libgksuui crashes on statup in the blur code on some systems" [Medium,In progress] https://launchpad.net/bugs/275172
<tkamppeter> pitti, I also cannot upload foomatic-db. Seems that the new Launchpad with ACLs is not yet installed.
<pitti> bah
<MacSlow> mvo, or link to the comment thread of it pointing out we've a fix in place?
<mvo> MacSlow: just mark them as duplicates of the fixed one
<pitti> tkamppeter: does the workaround actually hurt anything?
<mvo> MacSlow: thanks for cleaning that up!
<tkamppeter> pitti, the workaround only leads to more PDF->PS and back conversions, slowing down the printing and the probability of a bug is higher than when the PDF is passing through straight to the printer driver.
<tkamppeter> The patch is very small and only affects the Ghostscript command lines for the two bjc600 and bjc800 drivers, nothing else in the Foomatic dataabse is changed.
<pitti> ok
<superm1> whoops pitti, when you took discover1 out on friday, it broke mythbuntu live disk builds.  can you or whomever is manning the approval queue today let mythbuntu-meta 0.30 through to allow the dailies to get building again?
<pitti> superm1: uh, sorry; I checked reverse dependencies, and there was nothing left
<superm1> that's odd.  it was a recommends for mythbuntu-live
<MacSlow> mvo, hm... the dups don't let me add a comment ... well then they point to #275172 anyway so people should find it anyway.
<MacSlow> hey njpatel, sabdfl
<superm1> er by 0.30, i meant 0.31.  I think 0.30 was in the archive already
<pitti> superm1: FAILED: mythbuntu-meta (The source mythbuntu-meta - 0.30 is already accepted in ubuntu/intrepid
<njpatel> hey hey MacSlow
<pitti> superm1: oh, checkrdepends doesn't check recommends, that'd be it
<superm1> pitti, yeah i just saw i uploaded the 0.30 again by accident.  0.311 should show up now
<pitti> tkamppeter: okay, uploaded
<slangasek> superm1, pitti: mythbuntu-meta accepted
<pitti> slangasek: bah, I get permission errors on the queue page again; I accepted some xfce package, but the other brings an error
<pitti> slangasek: does that happen for you as well?
<slangasek> I don't use the web interface except for testing :/
<slangasek> superm1: hmm, ok, xorg-driver-fglrx (containing libAMDXvBA.so.1.0, bug #271794) is in multiverse, not restricted... has somebody demoted it as part of component-mismatch cleanup since you filed that bug?
<ubottu> Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794
<jussi01> anyone know where to find the file: libopenal.so.0 ?
<Mithrandir> jussi01: libopenal0a: /usr/lib/libopenal.so.0
<Mithrandir> jussi01: apt-file is your friend.
<jussi01> Mithrandir: yeah, I tried it, obviously wrongly as it returned nothing...
<jussi01> jussi@Galaxy:~$ apt-file search libopenal.so.0
<jussi01> jussi@Galaxy:~$
<jussi01> Mithrandir: thanks though :)
<cjwatson> tkamppeter: the LP database certainly *thinks* you're allowed to upload system-config-printer
<cjwatson> tkamppeter: http://paste.ubuntu.com/60035/
<cjwatson> tkamppeter: looks like an LP bug, unless the ACLs were changed between that upload being rejected and me looking at them
<cjwatson> (that's output from './edit_acl.py -p till-kamppeter query' in lp:~kamion/+junk/ubuntu-archive-tools)
<RAOF> jussi01: That's an old and apparently horribly library.  Feel free to poke upstream into linking against libopenal.so.1
<RAOF> s/y l/y buggy l/
<persia> jussi01, There was a transition to make that go away in intrepid.  Did something get missed?
<persia> RAOF, Well, it's mostly only horribly buggy if you don't have a creative card, although it's still buggy if you do (just not horrible).
<RAOF> persia: Heh.
<lool> mdz: Do you think the iwl3945 issue is fixed by disabling ftrace?
<lool> I thought it would only affect module removals
<tkamppeter> cjwatson, I got a mail from mdz that he has fixed (upodated) my ACL.
<mdz> lool: there were several independent reports that the problem did not recur with -7.12
<mdz> lool: can you reproduce it?
<lool> I will try to do some reboots; I couldn't get the hang reliably before though
<mdz> cjwatson: the ACLs were changed between that upload being rejected and you looking at them (by me)
<lool> Will confirm in the bug
<jussi01> persia: in intrepid it seems to be known as libopenal1
<wgrant> jussi01: Right, it broke ABI fairly recently.
<lool> mdz: Eh just got your comment in the bug report
<persia> jussi01, That's an entirely different piece of software : openal-soft vs. openal.  The new one is based on a community fork of some code creative released open-source.
<jussi01> persia: ahh...
<tkamppeter> cjwatson, mdz, I have done a test upload now and it works. The package waits for FE approval now. Please reject it. And thank you for the quick fix.
<mdz> tkamppeter: good, thank you
<didrocks> slangasek, pitti : I have done the fix for nautilus-share, see bug #212098
<ubottu> Launchpad bug 212098 in nautilus-share ""easy" file sharing not notifying about logout/login" [High,Confirmed] https://launchpad.net/bugs/212098
<mdz> cjwatson: is it possible yet for uploads which originally target intrepid to be redirected to jaunty when it's open, or do they still need to be re-uploaded?
<slangasek> pitti: any chance that you could look at that one?
<slangasek> tkamppeter: that's the system-config-printer upload that you're saying should be rejected?
<tkamppeter> slangasek, yes, the 0ubuntu7.
<tkamppeter> Pitti, has sponsored my upload of the 0ubuntu6 which contains an actual bug fix and so I did not have anything left to upload for testing. So I have created an unchanged 0ubuntu7 only for testing.
<slangasek> ok, rejected
<mdz> slangasek,cjwatson: to ask the real question, I have changes which are ready for upload but which aren't appropriate for 8.10. what should I do with them?
<mdz> james_w: perhaps there's a branch where I could commit them? ;-)
<slangasek> I like that as an answer... :)
<james_w> mdz: hopefully shortly
<mdz> james_w: this is alsa-driver fwiw
<tkamppeter> Ubuntu got article of the day on German Wikipedia: http://de.wikipedia.org/wiki/Wikipedia:Hauptseite
<mdz> pitti: do you have a rule of thumb for when apport package hooks should go in apport itself vs. in the package?
<pitti> mdz: hm, hard to put into words; usually I prefer "in the package", but for things like the kernel it's both easier and less conflict-ful (several versions in parallel, etc.) to ship it in apport
<pitti> slangasek: 212098> yep, will do
<mdz> pitti: I've written one for alsa-base which I'm inclined to put into the package
<pitti> mdz: another thing is, if it would be the only package delta, I'd also be inclined to put it into apport instead
<pitti> mdz: but we have a delta anyway, so I agree, putting it into alsa-base is more appropriate
<mdz> pitti: it will use the upstream alsa-info.sh script, which is currently not installed, so it needs to be modified to install the script anyway
<mdz> pitti: however, once it's there, I expect that e.g. pulseaudio will want this info as well, which makes me wonder whether it should go in apport.hookutils
<mdz> pitti: or if hooks should invoke other packages' hooks
<pitti> mdz: if there's any doubt, I don't mind at all to put it into apport for now; it's arch:all and builds quickly, so not disruptive to the RC
<pitti> mdz: (OTOH we'll disable apport for the final release anyway)
<pitti> ok, need to rush to the post office before they close; bbl
<mdz> pitti: I was planning to hold these changes until post-8.10 anyway
<pitti> ah, ok :)
<mdz> pitti: though, if you will upload apport anyway for some reason, then please do merge my hookutils branch
<pitti> mdz: the only upload I planned so far is to disable it; but I can merge it in trunk, sure
<james_w> if I see a pointer with the value 0x10 in a stacktrace, is that usually indicative of a particular problem?
<slangasek> james_w: uninitialized pointer is my first guess
<slangasek> second guess is "somebody took an offset from NULL"
<mdz> james_w: if you can trust the value it's showing you (watch out for debugger unreliability, compiler optimization, etc.), then that pointer is likely invalid
<mdz> james_w: my first guess would be "int value assigned to a pointer"
<mdz> james_w: URL for the stacktrace?
<persia> james_w, If you are looking at a member of a structure, the pointer to the structure is probably null.
<james_w> I believe threads may be involved, but from what I can see the pointer is assigned NULL, and then next shows up with 0x10
<james_w> it's only in gdb currently, I'll extract it to a file
<mdz> james_w: sounds like the debugger is lying to you
<mdz> it unfortunately does that a lot
<james_w> damn
<mdz> james_w: add a printf to dump the value of the pointer at the same spot and see what that says
 * wgrant recommends the use of -O0, too.
<mdz> wgrant: indeed
<wgrant> That can make gdb much less useless.
<james_w> hmm, apparently valid pointer that time, but still SIGSEGV
<wgrant> Valid meaning it points to something, or just doesn't look so bogus at a glance?
<seb128> james_w: try using valgrind
<james_w> ah, no, it's invalid, just not as obviously as invalid as 0x10
<wgrant> valgrind is good until it starts segfaulting.
<seb128> james_w: valgrind often gives you good clues
<seb128> wgrant: it doesn't segfault often for me
<slangasek> james_w: so the reason you're looking at this pointer is that it's the cause of the SEGV?
<wgrant> seb128: Neither, but I've encountered a couple of particularly nasty situations where it does.
<slangasek> (did you post a url to the stack trace that I missed somehow?)
<ogra> seb128, my evo is acting up recently ... since a week or so it forgets its password ver often (i never had to type it in in hardy or before), if i get up in the morning i get recieveerrors and have to rstart it to even get my first chunk of mail
<ogra> *restart
<slangasek> wgrant: valgrind and gdb both beat analyzing core dumps by hand, so...
<wgrant> slangasek: This is true.
<james_w> http://paste.ubuntu.com/60057/
<slangasek> james_w: and 'list' is the pointer that was showing as 0x10 before?
<james_w> yup
<james_w> I'm pretty sure at least, it was yesterday
<slangasek> and this latest stack trace is after rebuilding with -O0?
<james_w> no, I haven't rebuilt, I'll try that now
<james_w> but I appear to have turned this crash from a race condition to a consistent crash every time, I don't know if that is good or bad
<slangasek> good :)
<james_w> also, is there a way from a glib program to get a thread id for the thread the code is executing in?
<james_w> I wonder if I misunderstood which thread was which here
<slangasek> I'm not sure any thread ID you would get from inside glib would usefully correlate to how gdb identifies your threads
<slangasek> definitely needs a rebuild with -O0, the line number in the backtrace doesn't match the function name
<james_w> this is a patched consolekit
<james_w> bug 269651
<ubottu> Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,In progress] https://launchpad.net/bugs/269651
<slangasek> james_w: http://launchpadlibrarian.net/18690266/consolekit_0.2.10-1ubuntu9.diff, then?
<slangasek> james_w: hrm, does this happen to be on amd64?
<slangasek> james_w: I ask because of the use of GUINT_TO_POINTER(), which certainly *sounds* suspect, but I can't find a definition of it anywhere in libglib2.0-dev...
<slangasek> OTOH, it's plausible the indices really are integers in this case
<persia> pitti, Would you have time for some questions about HAL?  I want to export an input.joystick property for joysticks so evdev will be able to not grab them, so that joystick-driven games can work again.  It was suggested you were the expert on these things.
<james_w> slangasek: I don't have amd64 to test, sorry.
<james_w> ah, I mean, no, it's i386
 * slangasek nods
<slangasek> ogra: is there a MIR for cbflib anywhere?
<slangasek> ogra: you uploaded rasmol back in June with a build-dep on it, but it's still in universe
<bigon> could someone have a look at bug #258192 ? there is a patch present on the lp
<ubottu> Launchpad bug 258192 in dhcp3 "problem with paths and binding to ldap server" [Medium,Confirmed] https://launchpad.net/bugs/258192
<ogra> slangasek, i did ?
<ogra> slangasek, hmm, must have been sponsored for LaserJock, i'l check
<ogra> *i'll
<slangasek> well, your name is in the changelog, not much of a "sponsored" upload :)
<pitti> persia: right, in fact I was planning to do the same
<pitti> persia: but last week, joysticks were recognized as 'mouse', and /dev/input/js0 didn't have a hal entry at all; however, there was an -evdev fix in the meantime
<persia> pitti, Then I guess my first question is: is it faster for you to help me learn how to do it, or just to do it?
<persia> The -evdev fix made pressing a joystick button stop crashing X, but with the current HAL, there's no way for evdev to not detect joysticks as mice.
<ogra> well, its just a matter of having an .fdi and making it load the mouse driver, no ?
<persia> HAL not having anything for /dev/input/js0 isn't the issue so much as HAL having an entry with input.pointer for /dev/input/eventX for joysticks.
<pitti>   info.capabilities = {'input', 'input.mouse'} (string list)
<pitti> bah
<pitti> persia: well, it is an issue
<persia> ogra, That means writing an .fdi file for *each* joystick.
<ogra> persia, no, only one with a match line for every joystick
<wgrant> We already have about a dozen joysticks whitelisted.
<persia> pitti, well OK, but not something that I think of as intrepid-critical.
<pitti> persia: before we can apply the "local foreground console access" schema, we need a hal entry with /dev/input/jsX
<wgrant> But that's nowhere near all of them.
<persia> ogra, Right.
<wgrant> And it's a crazy idea.
<ogra> whats crazy about that ?
<pitti> no, writing FDIs for individual joysticks is a bad idea
<persia> pitti, That makes sense.  My concern is the regression that all the games don't work today.
<pitti> after all, the kernel already *knows* it's a joystick
<pitti> udev creates a proper device for it, after all
<pitti> persia: right, if you aren't in plugdev (we don't do that by default any more)
<james_w> http://pastebin.com/f1d86e7e2 is consolekit with -O0
<slangasek> james_w: have you tried under valgrind yet?
<persia> pitti: Except that if I run jstest as a user from a VC after killing X, it works.  If I run jstest as a user from within X it doesn't work.  X seems to be grabbing exclusive access to the device.
<ogra> slangasek, meh, you are right ... hmm, i would like to talk to laserjock first, he knows more about it than me but wont be around before the evening i guess
<persia> laserjock will likely be around in about 2-3 hours.
<james_w> slangasek: yes, is there a way to get it to show symbols?
<persia> pitti, So, that doesn't feel like a group access issue.
<ogra> ok, afternoon then :)
<pitti> persia: hm, if I chmod 666 the device, jstest /dev/input/js0 works fine for me
<slangasek> james_w: when valgrind gives an error, it'll show the names of any functions it knows
<ogra> how about using inuattach instead ?
 * persia tries again
<ogra> *inputatach
<ogra> bah
<james_w> slangasek: adding the G_SLICE and G_MALLOC env vars that the wiki page for valgrind suggests made it not crash it seems
<slangasek> ah, heh
<james_w> slangasek: ah, the stacktrace looked the same at least
<ogra> persia, it auto-maps joysticks to /dev/input/mice
<ogra> where you should have access to as normal user
<seb128> james_w: under valgrind? valgrind often workaround crashes but still displays errors
<slangasek> james_w: if using malloc instead causes it to not segfault, chances are you have an allocate/free mismatch
<slangasek> s/segfault/throw errors/
<slangasek> like seb128 says, valgrind's job is to find memory errors /before/ they become segfaults, so yeah, you generally have to read the output
<james_w> ah, it's got "Address is 8 bytes inside a block of size 12 free'd" coming from my new emit_removals_in_idle function
<james_w> ah, got it I think
<pitti> persia, ogra: so frankly I have no idea how -evdev works, but looking at hal debug output when plugging in a joystick might help
 * ogra would recommend an inputattach handler for hal that should dtrt and map the device as a mouse
<pitti> ogra: mouse? but that's what it specificallly shouldn't be...
<pitti> ogra: it is a mouse in hal right now, but that's wrong
<ogra> pitti, i thought it shouldnt be a keyboard
<pitti> ogra: the corresponding /dev/input/eventXX thingy is a mouse in hal, and /dev/input/js0 doesn't exist at all
<ogra> ah
 * ogra misunderstood than
<ogra> *that
<pitti> ogra: anyway, so what's your idea about?
<pitti> ogra: how should we teach hal about this new device?
<persia> The HAL-mapped mouse even supports all of WXYZ, so if you've some gamepads, one stick navigates, and the other scrolls.  It's nice.  It's just the games that I'm testing more now to make sure they aren't still broken.
<ogra> my only idea would be to find device classes and make an fdi
<ogra> but thats what you deliberately didnt like :)
<persia> ogra, Well, better would be to define a new info.capabilities
<pitti> ogra: oh, device class is fine
<pitti> ogra: I mean I didn't like FDI files with joystick vendor/product IDs
<ogra> but you need to find a common denominator
<ogra> which means to collect tons of lshal outputs from joystick owners first to find the right thing to match
<wgrant> The kernel knows what is a joystick.
<wgrant> So hal can find out.
<wgrant> And hal should publish it as a new input.joystick or similar cap.
<persia> ogra, The kernel knows it's a joystick, that's not the issue.  The issue is how to present this to HAL clients.
<cjwatson> mdz: I'm fairly certain they still need to be reuploaded when jaunty opens
<cjwatson> mdz: I have an 'unreleased-packages' script which greps for UNRELEASED at the top of changelogs in my working trees, which means I can leave them on my disk and be reasonably certain not to forget about them
<ogra> persia, well, if the kernel knows hal cqan get that info and match the fdi aganst it i think
<ogra> persia, i'll look for my old sidewinder later today and see what i can find out :)
<wgrant> ogra: HAL needs to export it somehow. That is the key.
<persia> ogra, Right, which gives us a nice simple .fdi file for xserver-xorg-input-joystick.
<ogra> right
<wgrant> Rather than the awfulness that is the current one.
<ogra> there is one currently ?
<persia> ogra, Right now, we can't do that because HAL doesn't tell us that it's a joystick.
<wgrant> There is.
 * ogra looks
<wgrant> See /usr/share/hal/fdi/policy/20thirdparty/10-x11-joystick.fdi
<wgrant> (part of xserver-xorg-input-joystick)
<ogra> ah, thats why i didnt see it :)
 * ogra installs and takes a look
 * persia wishes js_demo wasn't embedded in flightgear : flightgear is just *so* big.
<ogra> split it out
<ogra> we did the same for inputattach back in dapper
<persia> ogra, Which problem are you trying to solve?
<pitti> ah, I don't have xserver-xorg-input-joystick installed either
<ogra> wgrant, that file doesnt look so bad though
<ogra> though 10- might be wrong
<persia> pitti, Until we export something for a sane .fdi file, that package probably isn't as useful as you'd think.
<wgrant> ogra: It doesn't detect most joysticks.
<ogra> thats likely to be overridden by something else
<persia> (Especially because X is already getting 4 axes from /dev/input/eventX)
<pitti> persia: ugh, indeed that file looks pretty useless
<persia> pitti, It was tjaalton's first quick workaround when trying to deal with the problem.  Having input.joystick or something would be much preferred by all.
<pitti> *nod*
<mdz> ogra: inputattach and perhaps something like js_demo should probably be moved into input-utils upstream
<ogra> mdz, good ide, i'll take care for that in jaunty (i'll have to discuss a lot of touchscreen stuff upstream anyway)
<slangasek> mvo: no bug numbers in the changelog for this update-manager upload?
<persia> mdz, jstest which is the more common way to do it is part of the joystick package.
<ogra> persia, xserver-xorg-input-joystick or joystick ?
<james_w> ugh, this is worse that I thought
<ogra> persia, it should be in xserver-xorg-input-joystick
<persia> ogra, joystick.  It contains jscal and jstest.  Everything you want to play with a joystick.
<persia> No, it should be either in joystick or in input-utils.  It doesn't belong in xserver-xorg-input-joystick
<persia> It uses the kernel interface, not the X interface.
<mvo> slangasek: the DistUpgrade/xorg_fix_intrepid.py stuff comes from forum feedback, the glade file has a bug, sorry for that
<mdz> persia: inputattach is useful for more than joysticks, and joysticks don't seem to warrant their own package apart from all other input devices (input-utils is 16k, joystick is 14k)
<mvo> slangasek: there is anohter one pending, apparently the nvidia drivers do not work anymore on cpus without SSE support
<mvo> so we need to test for this :/
<persia> mdz, Sure.  merging joystick into input-utils seems sane to me.
<slangasek> mvo: awesomesauce \o/
<ogra> mdz, it has an intuitive ame though ... thats the only pro argument i see
<ogra> *name
<slangasek> Riddell: is there a bug number for this scim-bridge change?
<ogra> input-utils proably should provide joystick and merge all the tools in
<mdz> persia,ogra: someone should mail the upstreams and see what they think
<Riddell> slangasek: I don't think so, let me check
 * ogra wonders if joystic is even active upstream
<ogra> the mentioned url in the package descriptopn is a dead link
<slangasek> Riddell: in your language-selector upload, the changelog and the source diff say opposite things...
<ogra> persia, do you know if joystick upstream is active at all ?
<ogra> and if so, where ?
<persia> ogra: no idea
<Riddell> slangasek: scim-bridge is a continuation of bug 203334
<ubottu> Launchpad bug 203334 in scim-bridge "scim-bridge-client-qt4 requires scim" [Undecided,Fix released] https://launchpad.net/bugs/203334
<Riddell> slangasek: it not only needed scim but a running scim
<pitti> Riddell: how do current langpacks look KDE wise now?
<Riddell> pitti: still incomplete, but we know why and we're working around it
<Riddell> slangasek: hmm, best reject that langauge-selector upload until ArneGoetje appears so I can clarify what's actually needed
<slangasek> Riddell: ok, done
<slangasek> Riddell: the kubuntu-meta change should be ok to let through though, right?  It doesn't depend on the language-selector change in any way?
<persia> pitti, What did you test with jstest?  I just updated to latest everything, and when I'm running X, both jstest and js_demo show the device, but don't receive any events.  When I'm not running X, both show events.  I continue to suspect that evdev having an exclusive lock on /dev/input/eventX is blocking events on /dev/input/jsX
<Riddell> slangasek: correct (it's also a request from arne and I don't have any details but I do as I'm told :)
 * slangasek winces
<pitti> persia: well, I move the stick and press the buttons, and I see the corresponding actions in the output numbers
<persia> pitti, That's precisely what I'm not seeing.  Which architecture?
<pitti> persia: i386
<persia> Hmm.  I'm amd64.  I wonder if that might affect it.
<pitti> persia: for me, "xinput list" doesn't  change if I plug in the joystick; does it for you?
<pitti> persia: and do you have gameport or usb?
<pitti> persia: I have usb
<slangasek> er... this wouldn't have any relation to the broken xinput headers on amd64 that were fixed the other day, would it?
<wgrant> pitti: Do you have -joystick installed?
<mdz> mvo: comments on bug 267749?
<wgrant> slangasek: No.
<ubottu> Launchpad bug 267749 in libflashsupport "Please remove libflashsupport source+binary from archive" [High,Fix released] https://launchpad.net/bugs/267749
<slangasek> ok
<pitti> wgrant, persia: no, I don't have x-x-input-joystick installed
<wgrant> pitti: I'm on i386 and my USB joystick shows up and does annoying mousey things.
<wgrant> pitti: That would do it.
<pitti> well, I don't *want* it do mouseish things, I want it to work in games :)
<persia> wgrant, I also don't have xserver-xorg-input-joystick installed.
<pitti> but I think that's pretty independent
<pitti> persia: ideally /dev/input/eventXX would be the joystick "mouseish" thing for X, while /dev/input/js0 is the game thingy
<persia> pitti, I do show my device in xinput list
<wgrant> persia: Do you have some other fdi file, then?
<persia> wgrant, Nothing non-default.
<wgrant> Hmm.
 * persia tries a different joystick
 * pitti installs x-x-i-j and compares
<mvo> mdz: sorry, the answer is yes, but I wll add code that ensures it goes away even when the user decides to skip the cleanup
<mvo> mdz: it looks like it does not have any useful purpose anymore
<mvo> mdz: s/code/a entry in the config/
<mdz> mvo: in fact it is actively harmful
<mvo> right, one more reason than
<persia> Well.  I tried three joysticks.  Either I win the .fdi lottery or pitti does.
<persia> All of mine behave the same : xinput list changes, and jstest doesn't work.
<pitti> +"Mega World USB Game Controllers"id=9[XExtensionKeyboard]
<pitti> persia: with x-x-i-j installed, I get that in xinput list ^
<persia> pitti, Odd.  I really don't have that package installed, and my joysticks work in X, and don't work in games.
<ogra> mdz, it might still be useful on networked connections in ltsp, i didnt find the time to test it yet, but in that case it cn go into a PPA
<pitti> persia: but even with the package installed, jstest still works
<pitti> persia: you sure you chmod 666'ed the device?
 * ogra actually tries it out in a vm *now*
<persia> pitti, well, I'm in plugdev.
<persia> chmod 600 gives a different issue : jstest reports "Permission denied".
 * persia tries with 666 just in case some other user is critical to making this work
<pitti> persia: ok I'm not in plugdev, but 660 should be fine for you then
<pitti> persia: right, you'd get EPERM with insufficient privileges, not a non-working jstest
<pitti> bah, and why did my X crash when I purged x-x-i-j ...
<jcristau> with a grabbed device, you'd get a non-working jstest
<persia> pitti, Yeah, changing to 666 doesn't make any difference.
<jdstrand> pitti: re 'happy?'> \o/
<persia> jcristau, So the question becomes : why isn't evdev grabbing pitti's joystick?
<pitti> persia: erm, it does, if I have -input-joystick installed
<persia> Does anyone else have a joystick?
<pitti> mouse emulation works fine
<jdstrand> pitti: though, it always does make me a little sad when one is EOL'd...
<ogra> persia, in some moving box in the basement
<persia> pitti, Mouse emulation works fine for me too, but I don't have to install xserver-xorg-input-joystick.
<jdstrand> (not from a security support standpoint of course!)
 * ogra goes digging
<pitti> I just recently bought an USB one, it's all dosbox' fault
 * persia installs an i386 box
<pitti> intrepid's version is too good, it runs TIE fighter and X-Wing
<pitti> (Wing Commander, too)
<wgrant> persia: On i386 a USB one is grabbed by evdev if I have -joystick enabled.
<wgrant> I wonder if a HAL restart might be required to pick up the new file?
<pitti> wgrant: no, that should work now
<persia> wgrant, But I don't have -joystick installed, and I rebooted even.
<wgrant> Blurgh.
<pitti> persia, wgrant: http://paste.ubuntu.com/60085/ is what I get from hal when plugging it in
<ogra> http://paste.ubuntu.com/60086/
<ogra> thats what i get from dmesg
<persia> pitti wins
<ogra> yeah, hal sees input,input.mouse
 * wgrant grabs his joystick again.
<pitti> ogra: oh, a Sidewinder, the only good MS product ever :)
<ogra> yeah
<pitti> ogra: unfortunately mine has a gameport connector and thus doesn't work any more :(
<ogra> well, they ake some good mice and keyboards as well :)
<ogra> though i dont own any :)
 * wgrant feels dirty to now have two old Microsoft input devices plugged in.
<persia> pitti, Why doesn't it work?  Is it just that your hardware doesn't support it?  Do you want a USB gameport?
<wgrant> pitti: Where'd you pull that hal log from?
<ogra> wgrant, why, thats the only area where they dont produce crap :)
<ogra> --no-daemon --debug ?
 * persia likes some microsoft mice
<pitti> wgrant: sudo /etc/init.d/hal stop; sudo hald --verbose=yes --daemon=no
<wgrant> ogra: Indeed, this Basic Optical Mouse and SideWinder 2 have lasted well.
<ogra> or dbus-monitor
<wgrant> pitti: Right, just wondering if it logged somewhere by default.
<wgrant> Thanks.
<pitti> persia: well, I played with lots of module options of my old SB 128 (es1371), but it just wouldn't appear
<persia> pitti, When was this?  gameport joysticks shouldn't have worked for Edgy, but should have worked for Dapper and Feisty (and earlier and later)
<pitti> anyway, I let you figure this out, need to turn my head towards some RC bug fixes, sorry
<pitti> persia: like three weeks ago, under intrepid on my amd64 test box
<persia> No problem.  Thanks for testing.  That it works fine for you indicates it's probably something you can't fix :)
<pitti> persia: well, it doesn't work perfectly just yet
<pitti> persia: I'd need the device to appear in hal, so that we can attach dynamic ACLs to it
<pitti> persia: but apparently you have a completely different problem then :/
<ogra> hmm
<persia> pitti, yeah.  I'll take a look at gameports again next :)
<ogra> ogra@osiris:~$ sudo jstest -c /dev/input/event12
<ogra> Driver version is 0.8.0.
<ogra> Joystick (Unknown) has 2 axes (X, X)
<ogra> Segmentation fault
<ogra> neat
<wgrant> Nice!
<ogra> ogra@osiris:~$ sudo jscal -c /dev/input/event12
<ogra> jscal: error getting version: Invalid argument
<pitti> persia: I just gave up and bought a Thrustmaster for some 20 bucks
<ogra> thats even better
<wgrant> ogra: What if you try /dev/input/js0?
<pitti> ogra: are you really supposed to use the "eventXX" ones? /dev/input/jsX WFM
<persia> ogra, It doesn't work with the event interfaces
<ogra> wgrant, nothing
<wgrant> jstest works here, as well as working the pointer.
<ogra> it doesnt segfault though
<wgrant> ogra: Without -c?
<ogra> haha
 * ogra just notices js0 is bound to his tuchscreen
<ogra> thats so wrong
<wgrant> persia: So I can have my joystick working as both a pointer and in jstest.
<ogra> ok, works fine with js1
<persia> wgrant, Right.  I'm becoming convinced it's an architecture thing.  I'm just waiting for the i386 install to complete, and I'll confirm that.
<pitti> didrocks: oh, does the "restart your session" messagebox *only* has OK? it should have something like "Restart" "Cancel"
<wgrant> persia: It could still be a config issue.
<pitti> persia: my amd64 box still has an ancient ubuntu install, but I will reinstall it with the RC candidates for testing anyway
<pitti> persia: so then I can test it there
<wgrant> But I've seen so much 64-bit unsafeness in X stuff lately I wouldn't be entirely surprised.
<pitti> persia: s/ancient ubuntu/ancient intrepid/
<jcristau> persia: what does lshal say about your joystick (x11_driver, in particular)?
<ogra> ancient intrepid ?
<ogra> heh
<persia> jcristau, evdev
<pitti> ogra: well, it's still from the day when I got my dell docking station and stopped using my amd64 box as a work station
<didrocks> pitti: non, it as a "closed" button also
<didrocks> no*
<ogra> yeah, desktops for working are so last century :)
<jcristau> persia: there's your problem then
<pitti> didrocks: ah; I'll test it now
<persia> jcristau, Yep.  But that it isn't happening for pitti and wgrant makes it more interesting.
<jcristau> persia: if it said joystick, jstest would probably work..
<jcristau> persia: that just means their joystick is matched by x-x-i-joystick's fdi file, and yours isn't
<jcristau> afaict
<tjaalton> probably so
<ogra> http://paste.ubuntu.com/60089/
<ogra> mine neither
<persia> jcristau, Except it's working for pitti when x-x-i-j *isn't* installed.
<wgrant> When my joystick wasn't matched by -joystick's fdi file, it wasn't recognized by evdev either.
<wgrant> So it worked.
<pitti> persia: well, hang on
<wgrant> Somehow persia's is recognised by evdev.
<pitti> persia, jcristau: If I install x-x-i-j, I get js mouse emulation in X.org, and jstest works
<persia> All *three* of mine are recognised by evdev
<persia> pitti, And if you uninstall it?
<pitti> persia, jcristau: if I don't have x-x-i-j, I don't get js mouse emulation in X.org, and jstest works
 * ogra adds his to the fdi
<pitti> so for me it behaves just fine, AFAICS
<wgrant> pitti: But you don't see it in `xinput list` in the latter case?
<doko> hmm, wondering why "file <java class file> just prints "data"
<persia> For me, I get mouse emulation and jstest doesn't work, regardless of whether x-x-i-j is installed.
<pitti> wgrant: I do
<jcristau> pitti: ok, so x-x-i-evdev doesn't recognize yours
<jcristau> might depend what buttons/axes it pretends to have
<pitti> jcristau: the only real problem for me is that hal doesn't know about /dev/input/js0, but that's entirely unrelated to x.org
<persia> Mine tend to have a lot of both.
<mdz> slangasek: my rfkill issue is mysteriously resolved.  is yours?
<slangasek> mdz: which one?
<slangasek> the "hw switch breaks the driver" one, or the "sysfs interface changed out from under us" one?
<pitti> RF kill doesn't work with network-manager (did work in hardy)
<mdz> slangasek: the one I described in 193170
<mdz> slangasek: er, 193970
<ogra> http://paste.ubuntu.com/60090/ there we go
<mdz> slangasek: i.e., that the state in sysfs didn't change when I flipped the switch
<pitti> mdz: should that be /sys/class/rfkill/rfkill0/state ?
<pitti> it's "2" for me regardless of the switch position
<ogra> persia, add yours to the fdi and check again
<mdz> pitti: see perseus:[/sys/class/rfkill] # toggle kill switch
<mdz> er
<slangasek> mdz: nope, not fixed here
<mdz> pitti: see https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970
<ubottu> Launchpad bug 193970 in linux-ubuntu-modules-2.6.24 "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Undecided,New]
<persia> ogra, That's not a useful solution.  That only fixes it for my equipment.  We're not going to get a complete list.
<mdz> argh, https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/linux/+bug/193970/comments/60
<ogra> persia, not for intrepid, no
<mdz> pitti,slangasek: /proc/version_signature?
<ogra> persia, but for intrepid adding the ones we know about would already help a bit
<jcristau> persia: right. the fix is to have hal tell us what's a joystick
<pitti> mdz: 2.6.27-7.12-generic
<persia> ogra, We're never going to get a complete list.  Trying to do so is sisyphean.
<slangasek> Ubuntu 2.6.27-7.10-generic
<ogra> persia, but its not the time to add heavy hacks to hal now
<pitti> mdz: (just booted a couple of times to verify the iwl3945 boot hang)
<persia> ogra, For x-x-i-j, I slightly agree with you.  For my problem, I completely disagree.
<mdz> pitti: what was the state of the switch when you booted?
<ogra> i totaly agree with you, just not with the timeframe :)
<pitti> mdz: killing enabled, i. e. no wifi (it's usually docked and on eth, so I don't need it)
<persia> ogra, The solution might be to add a note to the release notes that Intrepid is known not to work for gaming with a number of joysticks.  I just want to avoid complaints.  Fixing it would be nice, but it's not the only option.
<ogra> for intrepid it seems sanet to me to have the ones we know about added to the fdi
<ogra> *sanest
<mdz> I usually boot with it enabled (wifi disabled), but this time I booted with it disabled because I happened to have been testing for bug 258804
<ubottu> Launchpad bug 258804 in linux "WARNING: at /build/buildd/linux-2.6.26/drivers/usb/serial/usb-serial.c:322 serial_write_room+0x72/0x80 [usbserial]()" [Unknown,Confirmed] https://launchpad.net/bugs/258804
<persia> ogra, If you like.  I think that's a waste of time, as there are more types of joysticks than most other accessories.
<pitti> mdz: right, same for me (wifi disabled almost every time)
<mdz> pitti: maybe boot with it in the other state to see if that's a factor?
<pitti> mdz: trying
<liw> mvo, ping
<ogra> persia, well, the kernel seems to know its a joystick here, no matter what x driver sits on top ... how does your dmesg look like if you plug it ?
<liw> mvo, https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/285657 -- do you have comments on that bug in system-cleaner?
<ubottu> Launchpad bug 285657 in system-cleaner "system-cleaner - should not offer or warn when removing one of the last two installed kernel versions" [Undecided,New]
<mvo> liw: let me have a look
<mdz> Keybuk: any luck with confirming 263059?
<Keybuk> mdz: still downloading updates
 * Keybuk really wants a faster internet connection
<pitti> mdz: 263059 looks pretty good now, several positive tests
<persia> ogra: http://paste.ubuntu.com/60092/ would be a sample
<Keybuk> I don't really understand why ftrace would break this though
<ogra> woah
<ogra> unplugging my joystick killed X
<Keybuk> unless you have a tracer, isn't it just 5 no-op instructions?
<lfaraone> dholbach: ping
<persia> ogra, See, that happened for pitti also.  Doesn't happen for me.
<ogra> persia, [  972.048320] input,hidraw0: USB HID v1.00 Joystick
<ogra> i think the kernel knows enough to make hal set a capability here
<pitti> for me it crashed when unplugging joystick and purging x-x-i-j
<ogra> for me it just crashed when unplugging
 * ogra tries again
<mdz> pitti: yes, I went ahead and marked it closed, but rtg and Keybuk are skeptical
<ogra> hmm, this time it survived
<persia> I can attach and unattach : the only annoyance is EV_ABS interfering with the mouse pointer until I touch the appropriate axis.
<mvo> liw: in the past we did not remove kernels at all because of concerns like this. but now with the last-known-good kernel feature I think its much less critical
<Keybuk> mvo: that feature is disabled in intrepid
<mvo> is it?
<liw> Keybuk, the last-known-good-kernel feature?
<mdz> mvo: that was the plan, but it wasn't ready for 8.10
<ogra> hmm, doesnt happen again
<liw> ok, then it sounds like system-cleaner should not remove kernel images
<mvo> liw: ok, please take back what I just said
<liw> mvo, do you agree with not removing kernels?
<mdz> liw: I think it should.  if it doesn't, nothing else will.
<ogra> bah, now i have to boot all my VMs again
<mvo> maybe not select it by default?
<mvo> (select for removal by default)
<mdz> liw: this was actually the original reason that *both* system-cleaner and last-good-boot were conceived!
<mvo> mdz: update-manager will too, all but the running one on upgrade
<pitti> mdz: updated 193970
<mvo> (all of the previous release)
<mdz> mvo: oh, good, I didn't relaize that
<mvo> I think it should be fine because it keeps the running one
<liw> so would it be ok if system-cleaner keeps it hands off kernels, for now, and we rely on update-manager to get rid of them on upgrade? until we can figure out a reliable heuristic for this
<dholbach> lfaraone: pong
<mdz> liw: I think update-manager's heuristic is a pretty good one
<mdz> liw: keep the most recent kernel, plus the one which was being used when that one was installed
<ogra> mdz, fyi flash sound in ltsp works fine without libflashsupport
<cjwatson> I agree that system-cleaner should remove kernels, just be a little more selective about it
<cjwatson> this is system-cleaner's highest-priority purpose
<liw> for me, the reason for system-cleaner to exist is to add relatime to fstab, but I seem to be in the minority
<mvo> ogra: is removal of libflashsupport ok for ltsp too?
<liw> ok, I'll change system-cleaner to follow update-manager's heuristic
<ogra> mvo, yep, just noted that on the bug
<mvo> ogra: cool, thanks
<cjwatson> there are certainly other important reasons, but that's why it got cranked up the foundations agenda
<mdz> liw: what does relatime have to do with system-cleaner?
<liw> mdz, system-cleaner adds (or offers to) relatime to ext2/ext3 filesystems in fstab if not there already
<ogra> .oO(would be nice if system cleaner could display the package description at least, i have a lot stuff in there of which i dont know what it actually is)
<mdz> liw: why?
<liw> ogra, that's a fair request, please file a bug about it
<ogra> liw, will do
<cjwatson> mdz: it is useful to have something that does the things that update-manager does post-upgrade in case you didn't actually use update-manager
<Keybuk> is it useful to have two implementations of that though?
<mdz> cjwatson: but update-manager doesn't mess with relatime afaik
<cjwatson> /usr/lib/python2.4/site-packages/DistUpgrade/DistUpgradeQuirks.py:        " add the relatime option to ext2/ext3 filesystems on upgrade "
<lfaraone> dholbach: Hey, how would I register a DocBook collection of docs for FooPackage with yelp/scrollkeeper so that they show up in yelp?  (for documentation-only packages)
<liw> Keybuk, no, but having it in both tools sharing the same implementation should be ok
<mdz> cjwatson: interesting, I don't remember that happening on my systems
<Keybuk> liw: agree
<cjwatson> Keybuk: ultimately update-manager and system-cleaner should be built from the same source
<liw> Keybuk, ergo, python-fstab ;-)
<cjwatson> same way as ubiquity and oem-config should be built from the same source
<mdz> oh, it was added in intrepid after I had already upgraded
<mvo> mdz: if you upgraded early it may have not been around
<cjwatson> https://wiki.ubuntu.com/CleanupCruft mentions this
<liw> mdz, see, you need to run system-cleaner... :)
<persia> lfaraone, Probably a better question in #ubuntu-motu
<dholbach> lfaraone: best to ask the fine people in #ubuntu-doc
<mvo> cjwatson: liw and I should have a session about this at next UDS
<Keybuk> interesting
<cjwatson> yes. noted
<mdz> liw: it should be installed by default and run automatically; if users have to go out and find it, then it will not be effective
<Keybuk> so the update-manager quirks only get run if you actually do a dist upgrade
<cjwatson> it is installed by default now
<Keybuk> so all the post-beta quirks get missed if you upgrade at beta?
<mvo> Keybuk: yes
<cjwatson> Keybuk: this is why they need to be accessible some other way too
<Keybuk> do we announce new quirks anywhere so people can manually fix their systems?
<cjwatson> release notes
<lfaraone> dholbach: ah, kk.
<mvo> Keybuk: all that u-m does needs to go into the release notes too for people using apt-get
<ogra> liw, bug 286394 for you
<ubottu> Launchpad bug 286394 in system-cleaner "system-cleaner should display the package descriptions on demand" [Wishlist,New] https://launchpad.net/bugs/286394
<liw> ogra, vielen Dank
<lfaraone> persia: these are -docs packages for packages in main.
<Keybuk> cjwatson: or have something run as part of an ordinary upgrade that sorts out quirks
<ogra> :)
<mvo> right
<pitti> mvo: what's the status of the compiz screensaver fix? you wanted to do the upload yourself, you said?
<pitti> mvo: (I have 1:0.7.8-0ubuntu5 prepared and tested, FYI)
<liw> mvo, next question: https://bugs.launchpad.net/bugs/285746 -- I don't think there's much we can do to distinguish obsolete packages and those installed via dpkg -i, or some other way bypassing sources.list, is there?
<ubottu> Launchpad bug 285746 in system-cleaner "System cleaner removes explicitly installed third-party packages" [Undecided,New]
<mdz> liw: if the user intentionally disables relatime, will system-cleaner notice and leave it alone?
<mvo> pitti: see #ubuntu-release - I think the compiz changes have problems, they case white-screen screensavers on nvidia
<pitti> mvo: oh, darn
<mvo> pitti: I posted a fix for xserver-xorg-core that should DTRT
<liw> mdz, if users tells system-cleaner to ignore relatime, then system-cleaner will remember that and not enable it itself
<mvo> pitti: now its a bit scary to change that now so I did not upload into into intrpeid without bryce or tjaalton looking at it first (I asked firday for that)
<pitti> mvo: alright, thanks for the heads-up
<mvo> pitti: we could go with the compiz change, that would be not worse than what we had in hardy (+plus that it seems like the wrhite screen problem is easier to trigger with the latest nvidia drivers, but that is just a theory)
<mdz> liw: so if I disable it manually, system-cleaner will offer to put it back the next time it runs, but only once (if I say no)?
<liw> mdz, correct
<pitti> mvo: uh, _usr_bin_update-notifier.117.crash
<pitti> mvo: I thought it wouldn't run for the guest session?
<mvo> pitti: it should not :(
 * pitti files it
<mvo> pitti: please
<mvo> thanks
<pitti> mvo: ah, already there, bug 285075
<ubottu> Bug 285075 on http://launchpad.net/bugs/285075 is private
<liw> mvo, so, is there a way to distinguish between a no-longer-available-via-apt-get package and a user-installed-via-dpkg-or-outside-apt package?
<pitti> mvo: I did some duplication cleanup
<mvo> liw: not right now we would have to add code to do that
<mvo> liw: something worth to discuss though
<liw> mvo, add code where? apt?
<mvo> liw: libapt, yes
<liw> mvo, right, so there's nothing system-cleaner can do about it right now
<mvo> pitti: thanks
<mvo> liw: nothing that I can think of at least
<liw> mvo, I'll note that in 285888, thanks
<liw> er, not that bug
<liw> mvo, 285746 -- that one, I'm getting confused with this deluge of bugs :)
<mvo> pitti: hm, that is a strange bt - does yours show similar charackeristics?
<pitti> mvo: I didn't have a symbolic one, but the bug description matches, and the nonsymbolic one, too
<mvo> pitti: thanks, I try to reproduce
<kwwii> pitti: I have an update for the human-icon-theme (adding a 16x16 logout icon to fix a bug), seb128 mentioned that we might be able to include it in intrepid...do you think that is still possible?
<pitti> kwwii: yes, if it's a nonitrusive change and we'll upload it really really quickly
<pitti> mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/387 -> TBH I'd just drop the "getlogin()" bit; it might return NULL, and I don't think we should ever start u-n for any system user
<liw> in 285748 the bug submitter talks about locked or pinned packages in synaptic, but I don't see a way to do that kind of thing, what am I missing?
<liw> oh, "Lock" is in the "Package" menu, not in the popup menu
<liw> that locking is probably the same as "hold" in dpkg
<tkamppeter> pitti, according to the mail notifications I got you have only uploaded foomatic-db but not accepted it into Intrepid. Can you do so? Thanks.
<pitti> tkamppeter: done some five minutes ago
<kwwii> tedg: do you know the bug number for the logout icon getting cut-off?
<mvo> pitti: ok, fine with me
<pitti> mvo: NB, I'm by no means sure that this is the reason for the crash
<mvo> pitti: updated in bzr, it check it out
<mvo> pitti: I mean, I check if i can reproduce the crash
<kwwii> tedg: nevermind, I found it in my email
<tedg> kwwii: Heh, I found it too.
<liw> mvo, is markedKeep in python-apt the same as hold in dpkg?
<tedg> pitti: Thanks for sponsoring the FUSA upload.
<ogra> tedg, fyi, all chnges of the recent upload work fine in ltsp, no regressions
<cjwatson> python-apt markedKeep means "this package isn't going to be changed"
<mvo> liw: no, that is just for the session
<mvo> liw: its not persistant
<cjwatson> in other words to undo a markInstall you do a markKeep
<cjwatson> (e.g.)
<mvo> liw: there is nothing in python-apt (at this point) to set the old status
<mvo> (unfortuantely)
<liw> mvo, cjwatson: I'm still grepping the synaptic sources to find out for myself, but do you know off-hand what the "lock" thin in the Package menu does? hold in dpkg?
<mvo> liw: it modifes the apt preferences in /var/lib/synaptic/preferences
<tedg> ogra: Great!  We've now dashed people's hopes that they could do any of those system management things ;)
<mvo> liw: its a bit of a old wart
<ogra> :)
<liw> mvo, interesting, I don't have that file :)
<mvo> liw: I think the right answer is  add support dpkg hold into python-apt, synaptic
<liw> mvo, is there currently a way to query the synaptic lock setting from outside synaptic?
<mvo> liw: did you actually put anything on hold?
<mvo> liw: yes, give me a sec
<liw> mvo, good point, I didn't
<liw> now I see it
<Koon> kwwii: about the FUSA icon bug, apparently if you switch to a theme that uses default gnome icons, it uses a 16x16 greenman icon. Maybe we are just missing a 16x16 shutdown button ?
<mvo> liw: cache._depcache.ReadPinFile("/var/lib/synaptic/preferences")
<mvo> liw: fixing that for jaunty would be really cool
<Koon> (though 16x16 is a little small)
<tkamppeter> pitti, thanks
<liw> mvo, ack for jaunty; but I'll use that in intrepid in the time being, thanks
<kwwii> Koon: yes, I added a 16x16 icon the new theme package
<Koon> kwwii: great :)
<mvo> liw: in __init__ somewhere I think its somewhat expensive
<mvo> Koon: have you seen the fix for the screensaver issue? did you had a chance to test it?
<kwwii> the reason for that is that before it was shown at 22x22 and now it is in the system tray which has padding to it and uses 16x16 icons (which we did not have before)
<Koon> mvo: yes, tested ok, and commented on the bug
<Koon> mvo: looks cleaner than the un-undirect hack.
<mathiaz> slangasek: I'd like to upload a new landscape-client package to fix bug 285030. Do you have any issue against it?
<ubottu> Launchpad bug 285030 in landscape-client "private-pre-intrepid to intrepid upgrade of landscape-client -> landscape-{common,client} fails with file ownership conflict" [Undecided,New] https://launchpad.net/bugs/285030
<mvo> Koon: yeah, I think its the right fix, however it make me a bit nevous to change dix/window.c one week before release
<tedg> Okay, so I have a weird bug.  It seems like Nautilus starts, but doesn't draw the background or any windows.  Even clicking on places won't open a window.  Kill Nautilus doesn't help.  I can't find any error messages.  Anyone know where I could look for debug info?  Starting from the command line does literally nothing.
<Koon> mvo: the proper fix is to disable screensavers entirely, the whole concept is flawed in those years of greenhouse effect chasing.
 * wgrant is disappointed that the translucent panel background isn't configured on upgrade.
<Koon> we could make a gesture for the planet and get rid of a few hundred bugs :)
<liw> Koon, I'm in favor of removing screensavers entirely (at least from the default install) :)
<mvo> Koon: I like that!
<kwwii> wgrant: there is a good reason for not putting the panel background in the theme itself: that causes bugs (the about window then uses the panel bg tiled)
<tjaalton> mvo: maybe posting to xorg@l.fd.o would attract the right people?
<Koon> liw, mvo: the idea is to make it look like a political statement rather than a lazy workaround :)
<wgrant> kwwii: But it makes it look so much better... I only noticed it when I was testing the guest session functionality.
<mvo> tjaalton: yeah, I will do that next, I was hoping for feedback on #xorg-devel first
<mvo> Koon: lol
<tjaalton> mvo: yep, maybe wrong timezone for that ;)
<kwwii> wgrant: glad to hear you like it :-)
<kwwii> wgrant: if you set it by hand be sure to open gconf-editor and add the stretch functionality
<wgrant> kwwii: I just reset my panel config.
<wgrant> Getting rid of that flat grey is excellent.
 * Koon tries
<didrocks> pitti: thanks :)
<pitti> didrocks: thanks to you!
<didrocks> pitti: I will upload an SRU next week :)
<didrocks> for hardy
<jdong> whoa, since when did we have CONFIG_EXT4DEV?
<liw> cjwatson, mvo, do you think it'd be appropriate for system-cleaner to purge packages instead of just removing them? I'm a bit afraid that it would remove important config files too easily, but it does leave some cruft
<cjwatson> liw: perhaps in jaunty; I don't think we need to worry about it for intrepid
<liw> cjwatson, ack, at least that gives us time to think about it
<cjwatson> liw: I agree it's cruft but it usually isn't terribly large in terms of disk space
<cjwatson> and you would want (for example) to have it list already-removed-but-not-purged items as cruft
<liw> yup
<liw> but I don't want it to remove a package and then show it up as cruft _again_, since it has config files remaining
<persia> Koon, When dropping screensavers, can we only drop them by default?  I still have some monitors that expect that sort of treatment (unless you provide non-DPMS blanking another way)
<wgrant> persia: Is a standard blank screen screensaver not good enough?
<Koon> kwwii: yes, the panel background looks great. The workspace selector and the windows list seem to be one pixel too big though (or did I miss something when I switched it on ?)
<persia> wgrant, The standard black screensaver is fine.  I thought the idea was to drop the entire screensaver infrastructure in preference to DPMS.
<persia> (just dim the screen, and then shut off when not in use)
<kwwii> Koon: to be honest I think it has more to do with the panel screwing up the sizes than anything else...at times I get icons and stuff which is too big, then I log out and back in and they are normal size
<Koon> kwwii: ok, will try that out :)
<wgrant> persia: It would have to be able to be blanked for screen locking to be effective.
<persia> wgrant, Well, only if you rely on authentication mechanisms that benefit from visual feedback.
<cjwatson> liw: yes - still, post-intrepid I think
<wgrant> I think my main gripe with the default theme is now the unlock dialog.
<wgrant> gksu's Compiz one looks very nice.
<Keybuk> mdz: rfkill0/state doesn't change with the kill switch for me either
<superm1> slangasek, I'm pretty confident that single library (libAMDXvBA.so.1*) will be able to be split into it's own multiverse package.  I'll be splitting it up todayish so hopefully that can be cleaned up
<mdz> Keybuk: does it depend on the state of the kill switch when the module is loaded (see bug 193970)
<ubottu> Launchpad bug 193970 in linux-ubuntu-modules-2.6.24 "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Undecided,New] https://launchpad.net/bugs/193970
<Keybuk> mdz: yes, just added a confirmed to that bug
<james_w> Is anyone willing to review http://paste.ubuntu.com/60125/ for me?
<james_w> the SIGSEGV I was getting this morning was using freed memory, I had to re-jig quite a bit to stop that happening.
<mvo> Mirv: I can not reproduce the bug #286363 - can you and if so, how?
<ubottu> Launchpad bug 286363 in gnome-app-install "app install translations trigger an annoying bug" [Medium,Triaged] https://launchpad.net/bugs/286363
<mvo> Mirv: I htink I know what causes it, but I would like to be able to verify
<mvo> Mirv: nevermind, I can now
<cjwatson> Riddell: I just noticed that Qt has a segfault handler; do you know if it properly re-raises the segfault so that it's visible by apport?
<Riddell> cjwatson: it does?  where?
<cjwatson> Riddell: src/corelib/kernel/qcrashhandler.cpp
<Riddell> cjwatson: if I kill -SEGV a Qt app it gets an apport report in /var/crash
<cjwatson> ok, good
<cjwatson> I just asked due to a bug report in which I saw a log message from that function
<cjwatson> so wasn't sure if the reporter could expect to find a dump in /var/crash
<tjaalton> mvo: ajax read the patch, and while he thinks it should be higher in the server it looks ok and should work
<tjaalton> mvo: well, it has been proven to work already..
<kwwii> pitti: if case you hadn't noticed I sent the source package url's in an email
<pitti> kwwii: I'm just processing them
<mvo> tjaalton: thanks, just read it. ok, that sounds good, do you plan a upload soon? or should I do it?
<kwwii> pitti: killer, thanks so much (sorry for wasting your time this late in the cycle)
<tjaalton> mvo: well, if you can think of a version number to use, then sure I can upload :)
<pitti> kwwii: it's not "wasting" :), no problem
<tjaalton> mvo: because we now have -2build1, and -2 is unreleased
<pitti> kwwii: both uploaded (too lazy to reply to mail)
<wgrant> tjaalton: -2ubuntu1 is all we can do...
<tjaalton> wgrant: yeah, probably
<mvo> tjaalton: do you build from git? should I branch from your repo?
<pitti> mvo: u-n upload> oh, you could reproduce the crash, and it was indeed the getlogin() == NULL issue?
<tjaalton> mvo: git, no need to branch?
<tjaalton> mvo: but I can add the patch there, it's trivial
<mvo> tjaalton: meh, my git foo is *so* weak :) if you don't hdate if when I upload it and just give you a debdiff, that would be me a happier man (or you just commit it )
<tjaalton> mvo: heh, yeah I'll do it
<tjaalton> I guess the patch for bug 261977 can go in as well
<ubottu> Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
 * pitti hugs james_w for his consolekit debugging
<james_w> hey pitti, I hope I got it this time
<mvo> thanks tjaalton!
<liw> kwwii, there's a volunteer making an icon for system-cleaner, and he's asking me questions I don't know about; could you give 274714 a quick peek?
<kwwii> liw: sure
<kwwii> liw: btw, I started an icon for that but never got very far, sorry
<Koon> ogra: please comment on https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/280123/comments/3
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/280123/+text)
<Koon> ouch.
<ogra> Koon, on my way
<liw> kwwii, no worries, I don't think an icon is necessary, merely nice
<liw> kwwii, a really good dark theme is important, on the other hand, thanks for that ;-)
<Koon> ogra: basically, I find dhcp3-server too dumb to react correctly to an interface addition
<ogra> Koon, i'm fine to go with what we have now for intrepid ... all i was worried about was that NM would break ltsp installs which doesnt seem to be the case, but i thik we shoud revisit it for jaunty and sanitize it a bit
<Koon> ogra: ok, will untarget 8.10 then, and keep it on the radar
<ogra> Koon, we should robably even consider to port dhcpd over to upstart and solve the probs one and for all in jaunty (if Keybuk manages to get upstart ready for us though :) )
<Keybuk> ?
<Keybuk> why would that be ported to upstart?
<ogra> Keybuk, dont we want all initscripts replaced with upstart events at some point ?
<kwwii> erm huh??? "Sorry, there was a problem connecting to the Launchpad server."
<Keybuk> one day
<Keybuk> no rush there
<kwwii> liw: I wrote a big nice comment but it seems the server keeps timing out
 * cjwatson takes a deep breath and dives into component-mismatches.txt
<liw> kwwii, oh dear
<liw> kwwii, at the same time my X crashed, this must be connected... :)
<ogra> Keybuk, no, but there is no point to fiddle with workarounds in sysvinit script over and over if we know we can fix it the right way :)
<kwwii> lol, no doubt
<davmor2> tseliot: ping
<tseliot> davmor2: yes?
<davmor2> you're working on jockey is that correct?
<slangasek> mathiaz: 285030> go ahead
<tseliot> davmor2: yes
<slangasek> superm1: hmmm, if that lib can be split into its own package completely, then what even uses it?  Should we just not bother shipping it?
<superm1> slangasek, it's used by the driver "if" you attempt to use their accelerated mpeg2 playback
<davmor2> tseliot: is there a reason for the delay in the progress bar when installing a driver?  There seems to be a quick flash and then nothing till about 52%
<slangasek> superm1: ah
<superm1> slangasek, by using XvMC in mplayer or similar
<tseliot> davmor2: you might want to ask pitti about this
<davmor2> pitti: ^
<persia> pitti, I did some more testing, and investigation about HAL and joysticks.  It seems that on amd64 10-x11-input.fdi is successfully mapping info.capabilities including input.mouse to input.x11_driver evdev, but that despite the same content of the files for i386, this doesn't work, which by chance makes joysticks work.
<tkamppeter> pitti, in bug 286080 someone complains that CUPS stops working when he has the resolvconf package (is in universe) installed. Would you fix the AppArmor conf for Intrepid?
<ubottu> Launchpad bug 286080 in cupsys "cups fails to print to network printer if resolvconf package is installed (apparmor)" [Undecided,New] https://launchpad.net/bugs/286080
<liw> kwwii, LP just e-mailed me your comments, thanks!
<kwwii> liw: hope that helps
<kwwii> liw: after thinking about it, they might want to use an existing screwdriver (and broom if it also already exists) and just put them together
<slangasek> tkamppeter: that's not a bug in the cups apparmor policy, it needs to be added to apparmor's nameservice abstraction.
<tkamppeter> slangasek, so it has to be moved to the apparmor package?
<slangasek> tkamppeter: already done (with difficulty, LP is being very slow right now)
<tkamppeter> slangasek, you are sure that apport is providing this part?
<psusi> does anyone know if there is a a developer mailing list for e2fsprogs?  I can't seem to find one...
<slangasek> tkamppeter: yes...
<cjwatson> ogra: do we want xserver-xorg-video-amd in main?
<cjwatson> I see that hardy had -geode so my guess is no
<ogra> cjwatson, i dont think so, geode should replace it anyway already
<ogra> its a transitional package afaik
<cjwatson> done, with any luck
<sbeattie> is denemo moving to universe?
<slangasek> ArneGoetje, pitti: there seem to be some language-pack-foo-base packages missing, that leave us with uninstallables: arn, bra, pap, syr
<mdz> cjwatson: http://people.ubuntu.com/~mdz/temp/Screenshot-QEMU.png
<pitti> davmor2: progress bar> python-apt doesn't give me anything better :(
<persia> pitti, The other alternative is to use synaptic as a backend, which gives a slightly nicer progress bar (update-manager does this by default)
<persia> Just set everything up with python-apt, and then call synaptic to apply the changes.
<davmor2> pitti: I just wondered as it looks to all intents like it is doing nothing I always check my hd lights by default on any progress bars due to issues with d-i so that was the only reason I knew it was doing stuff :)
<mvo> davmor2: what is the problem with the progress bar?
<davmor2> mvo: you get a quick flash of brown and then nothing till 52% so it just looks like it has stalled.
<mvo> davmor2: on what operation?
<davmor2> mvo: installing nvidia driver from jockey
<mvo> davmor2: oh, right. I think/guess the issue is the dkms compilation
<davmor2> mvo: it stay's on 0% until it hits 52% and then works as expected.
<tseliot> pitti: does the download  of packages increment the progress bar in jockey?
<pitti> tseliot: only in very coarse steps unfortunately
<pitti> I think it's doing the entire unpack/configure step in one big chunk
<cjwatson> mdz: just jigdoing down the CD now
<calc> grr launchpad seems to keep timing out on me :(
<pitti> download is a little better AFAIR
<pitti> persia: synaptic> right, I just need to find a way to integrate that in an upstream friendly manner
<persia> calc, There's been a lot of that in the last few hours.  LP devs are chasing.
<persia> pitti, Yeah, that's the less easy bit.
<persia> Maybe try synaptic, and fall back to python-apt if it isn't available?
<cjwatson> lool/persia: does mobile need wireless-tools/wpasupplicant? this is regarding bug 61618
<ubottu> Launchpad bug 61618 in ubuntu-meta "wireless-tools,wpasupplicant in -minimal" [Wishlist,Fix released] https://launchpad.net/bugs/61618
<persia> cjwatson, Does NM need those?  If so, yes.
<persia> cjwatson, MID too.
<persia> Mobile will get them from desktop-common
<cjwatson> network-manager depends on wpasupplicant, but not wireless-tools
<cjwatson> it's perhaps best to add that anyway just to reduce risk
<geser> zul: have you some time to look at the debdiff at http://paste.ubuntu.com/60169/ for bug #286450?
<ubottu> Launchpad bug 286450 in xen-3.3 "libxen3 and libxen3-dev have bogus Replaces: versions" [Undecided,New] https://launchpad.net/bugs/286450
<cjwatson> dendrobates: do you want to have wireless and WPA support installed by default on servers, or is it OK for people to have to install packages to get it?
<dendrobates> cjwatson: We have always installed by default previously, correct?
<cjwatson> yes
<mdz> cjwatson: the one I tested was actually 20081013
<mdz> I'm rsyncing the latest now
<cjwatson> dendrobates: having it in minimal is awkward for various reasons but we could put it in the server seed (rather than server-ship) if you want to keep it
<dendrobates> cjwatson: I would not want to change that at htis stage then.  We can look at making it optional for 9.04
<pitti> persia: calling synaptic directly doesn't work, since the install is done in the d-bus backend (no $DISPLAY, root user)
<cjwatson> dendrobates: ok, I'll move it to server
<persia> pitti, Ah, in that case, yeah, you need python-apt.
<pitti> persia: so providing this kind of "backend does callback to GUI which then runs synaptic as root" is incredibly hairy, and the reason why I didn't do it in the first place
<persia> "incredibly hairy" is an understatement :)
<pitti> persia: I actually want to use packagekit in a future version, BTW
<pitti> anyway, dinner time
<dendrobates> cjwatson: cjwatson: ta
<cjwatson> dendrobates: (the practical difference here is that it makes it easier for people to remove)
<cjwatson> ArneGoetje: are you still working on the remaining needs-review .pot files?
<cjwatson> ArneGoetje: the five most recent are actually important
<zul> geser: maybe this afternoon or later tonight
<doko> anybody here who could test the cacao-oj6-plugin on powerpc?
 * calc kicks lp
 * calc is trying to do bug triage but no access to lp is hampering that
<persia> doko, If nobody answers, you might ask in #ubuntu-powerpc, although it's not always very active.
<slangasek> ogra: oh, it looks like rasmol can be demoted now, that's a much easier solution
<mdz> cjwatson: <kirkland> mdz: dendrobates: i am able to reproduce the problem
<cjwatson> I'm part-way through a test install now
<cjwatson> kirkland: ^-
<kirkland> cjwatson: the grub menu.lst has root=/dev/dm-0
<cjwatson> grub is not supposed to be used for LVM installs.
<kirkland> cjwatson: hmm, really?  my desktop is grub+lvm+encryption
<Chipzz> cjwatson: so is my server
<cjwatson> if lvdisplay "$bootfs" | grep -q 'LV Name' 2>/dev/null || [ -e "$(dirname $bootfs)/control" ]; then
<Chipzz> (same as kirkland)
<cjwatson>         if ! is_sataraid $bootfs && ! is_multipath $bootfs; then
<cjwatson>                 log "/boot is a lvm volume ($bootfs), cannot install grub"
<cjwatson>                 exit 1
<cjwatson>         fi
<cjwatson> fi
<cjwatson> grub-installer/debian/isinstallable
<Chipzz> ah ok, I have a seperate /boot which is not on LVM
<cjwatson> oh, I suppose partman-auto-lvm sets up a plain /boot
<cjwatson> ok
<kirkland> cjwatson: ah, okay
<cjwatson> never mind then, that's a red herring
<cjwatson> I'll work on this
<kirkland> cjwatson: well, i'm arguing that root=/dev/dm-0 is not correct, on an lvm setup
<kirkland> cjwatson: it should be  root=/dev/mapper/vg0-lv0 or some such
<cjwatson> it should be /dev/mapper/ubuntu-root shouldn't it?
<cjwatson> give me a minute to reproduce this far enough that I can discuss it intelligently
<kirkland> cjwatson: /me on standby
<cjwatson> the UUID stuff in grub has the standard set of guards around it for LVM, RAID, etc.
<cjwatson> it looks like it has functioned as a canary regarding the /dev/dm-0 breakage
<slangasek> hrm, would this be related to the change to not munge device names to uuids in update-grub?
<slangasek> /dev/dm-* wasn't one of the options excluded by convert_kopt_to_uuid() previously, so update-grub would replace that with the UUID when it saw it
<cjwatson> kirkland: did you reproduce this with encryption or without
<cjwatson> /dev/dm-* is wrong anyway
<kirkland> cjwatson: without
<cjwatson> we shouldn't be using enumerated names when there are perfectly good fixed ones
<slangasek> yes, it's wrong, just wondering if this is what exposed the problem
<kirkland> cjwatson: that's on today's amd64 server iso, 763148b72316ab202b4df2a8373708f1
<cjwatson> it's possible; note this is different from the UUID change that mdz is probably thinking of :)
<mdz> cjwatson: my install ended up using UUID for the GRUB root device but not for the kernel root device
<calc> anyone happen to remember the url to see the full top 100 bug stats on LP?
<calc> i seem to have lost the bookmark to that
<mdz> cjwatson: I couldn't tell which one was causing the failure though
<cjwatson> mdz: likely the former, but the latter is a problem too (using /dev/dm-0)
<cjwatson> fixing the latter will make the former stop happening
<cjwatson> because /dev/mapper/* is excluded from UUID handling, as is usual
<cjwatson> I wonder if /target/dev has been unmounted or something
<kirkland> mdz: what did your kernel line have root=?
<mdz> cjwatson: anything i can do to help?  I hadn't opened a bug yet but can do so
<mathiaz> kirkland: where you also prompted for activating serial ATA RAID configuration when doing you test install in kvm?
<mdz> kirkland: http://people.ubuntu.com/~mdz/temp/Screenshot-QEMU.png
<kirkland> mathiaz: no
<cjwatson> mdz: give me five minutes, please
<kirkland> mdz: yup, same as mine
<kirkland> well, different UUID (thankfully)
<slangasek> cjwatson: bugger, there's definitely a bug in my grub change, I assumed grub-install was setting the root device to the UUID on install and it's apparently relying on update-grub to do this
<mathiaz> kirkland: hm - ok.
<cjwatson> mathiaz: that only happens if you have dmraid metadata on your disks
<slangasek> cjwatson: though I have root on LVM and when I installed, root was correctly pointed to /dev/mapper, so that doesn't fully explain this behavior
<cjwatson> mdz: I can reproduce the problem so should not need further information
<mathiaz> cjwatson: well - this a kvm install with standard qcow2 images
<ScottK> slangasek and cjwatson: It looks like ubuntu-policy was promoted to Main without the normal review and it now dep-waits on a build-dep in Universe (pstoedit).  At this point would it be better just to demote it so mdz's upload will build?
<cjwatson> mathiaz: so is mine, and I don't see this
<cjwatson> I'm ok with demoting ubuntu-policy
<slangasek> ack, demoting it
<mathiaz> cjwatson: are you using virtio block devices?
<mathiaz> kirkland: ^^?
<ScottK> Wahoo.  One off the out-of-date list then.
<cjwatson> mathiaz: no
<kirkland> mathiaz: looks like slangasek nailed the problem
<cjwatson> kirkland: uh, I think these are two orthogonal problems
<cjwatson> one is exposing the other
<slangasek> kirkland: except not all of it, I don't know why /dev/dm-0 would be chosen as the name for the rootfs in the first place
<kirkland> slangasek: ah, okay
<slangasek> does someone have / on a plain disk partition, that they could test for me?
<kirkland> slangasek: yup
<kirkland> slangasek: what do you need?
<slangasek> kirkland: mv /boot/grub/menu.lst{,.saveme}; update-grub -y; diff -u /boot/grub/menu.lst{.saveme,}
<cjwatson> ah, /dev/dm-0 is coming from findfs
<slangasek> kirkland: and post me the results - I'm pretty sure you're going to have root=/dev/fiddlefaddle1 instead of root=UUID=nomnom
<kirkland> slangasek: okay, i'm updating the vm to current intrepid now
<slangasek> kirkland: (and once you have the diff, you can restore the original menu.lst)
<kirkland> slangasek: ;-)
<Mirv> mvo: thanks, works great! wouldn't have guessed pyxdg as the culprit.
<mvo> Mirv: thanks a lot for finding the problem itself, fixing it was relatively painless
 * mvo hugs Mirv
<mathiaz> kirkland: hm. Could you confirm that you're using ide block device rather than virtio block device? It's probably irrelevant to the bug discussed above - but I may have found another one.
<kirkland> mathiaz: i am not using virtio at the moment in my testing of the current problem
<mathiaz> kirkland: ok. Thanks.
<mathiaz> kirkland: so virtio block devices are detetected as having dmraid data
 * cjwatson will get back to this after dinner
<kirkland> mathiaz: hmm, how so?
<kirkland> mathiaz: that might actually be related to cjwatson's finding that findfs() is pointing at /dev/dm-0
<mathiaz> kirkland: I don't know. If I boot a vm with a virtio block device I get a message stating that Serial ATA Raid devices have been found
<cjwatson> findfs the binary, not findfs the function
<cjwatson> as in e2fsprogs
<kirkland> cjwatson: erg, /me was looking at the wrong code then
<cjwatson> virtio/dmraid> nothing whatsoever to do with findfs, that's in hw-detect
<cjwatson> anyway, will look after dinner
<mathiaz> cjwatson: ok. I'll file a bug against hw-detect then
<psusi> does anyone know if there is a a developer mailing list for e2fsprogs?  I can't seem to find one...
<mathiaz> kirkland: if I boot a vm with an ide block device that message doesn't appear.
<kirkland> mathiaz: the _same_ vm?
<mathiaz> kirkland: yes
<mathiaz> kirkland: just changing the configuration in libvirt and I've got the Serial ATA Hardware RAID message printed during the install (in case the vm is started with virtio block devices)
<psusi> mathiaz: are you running the vm with a virtual disk image you took from a real hard disk?
<psusi> and if so, was that real hard disk ever part of a sata raid set?
<mathiaz> psusi: nope - it's a qcow2 image file created with qemu-create
<mathiaz> psusi: or qemu-img rather
<psusi> hrm... interesting... can you run dmraid -r in the vm and see if it says it sees raid devices?
<kirkland> slangasek: http://pastebin.com/f52871f2b
<kirkland> slangasek: (sorry for the delay--distracted)
<slangasek> kirkland: no problem - I'm still fighting with update-grub to get a proper minimal fix
<mathiaz> psusi: dmraid -r states that no block devices found
<mathiaz> psusi: I ran the command above just after the message was printed in the installer
<psusi> hrm.... strange...
<tseliot> slangasek: what do you think about these changes to the nvidia section of release notes? http://pastebin.com/m7d083dfa
<tseliot> slangasek: I have warned mvo against this, therefore Update Manager will deal with the SSE problem too
<slangasek> tseliot: hands full at the moment, sorry; I'm aware of the SSE issue and have already approved mvo's upload to address this in update-manager, I agree we should comment it in the release notes but have no time to review specific text at the moment
<tseliot> slangasek: ok, no problem
<cjwatson> psusi,mathiaz: hw-detect uses dmraid -c -s
<cjwatson> mathiaz: what does that print?
<mathiaz> cjwatson: same message: no devices found
<cjwatson> mathiaz: is that absolutely literal? capitalisation, etc.?
<mathiaz> cjwatson: same message: no *block* devices found
<doko> lool, seb128: I don't want to have pyopengl in main. can we make it a suggests in gnome-games instead?
<slangasek> kirkland: can you pull from lp:~ubuntu-core-dev/grub/ubuntu, build a package, and test?  the kopt diff should disappear now
<cjwatson> mathiaz: I need the precise text
<kirkland> slangasek: k
<mathiaz> cjwatson: "no block devices found"
<cjwatson> interesting, hw-detect tests against "No RAID disks"
<cjwatson> TheMuso: ^-
<pitti> lool: can we talk about sorting out elisa dependencies tomorrow morning? (sorry, need to leave now)
<kirkland> slangasek: Branched 863 revision(s) .... correct?  :-)
<slangasek> kirkland: yes
<kirkland> slangasek: okay, done
<kirkland> slangasek: menu.lst is back to what it was before
<slangasek> kirkland: ok, thanks
<kirkland> slangasek: thank *you*  :-)
<slangasek> cjwatson: grub 0.97-29ubuntu44 uploaded, kirkland has confirmed that root=UUID= is being set correctly again on initial menu.lst creation; can you review?
<slangasek> or should I let you fight with the installer and unblock it myself?
<kirkland> pitti: ping
<kirkland> pitti: regarding bug #284443, i'm not going to fix that in ecryptfs-utils;  i added a task a task for you guys to decide if it merits a note in the gdmsetup interface
<ubottu> Launchpad bug 284443 in gdm "ecryptfs does not work with gdm auto-login" [Undecided,New] https://launchpad.net/bugs/284443
<doko> kees, bryce: does inkscape need python-uniconvertor?
<cjwatson> slangasek: that grub change makes sense to me
<cjwatson> slangasek: accepted
<slangasek> thanks
<slangasek> (and sorry)
<cjwatson> I'll see if I can do something about the /dev/dm-0 thing, although I can't decide whether that's release-critical
<Mirv> mvo: heh, no problem. I've reported some other gai bugs as well but they are quite minor in comparison. possibly bug #283950 since without fixing it one cannot install free java plugin via gai.
<ubottu> Launchpad bug 283950 in gnome-app-install "[intrepid] Replace icedtea-gcjwebplugin with icedtea6-plugin in gnome-app-install" [Undecided,New] https://launchpad.net/bugs/283950
<Mirv> maybe that's icedtea6-plugin bug also, perhaps it shouldn't conflict with the transitional package since that doesn't make the transitional package very functional
<slangasek> cjwatson: I guess that depends on the reasons for not converting /dev/mapper/* to UUID, since those probably also apply to /dev/dm-*
<slangasek> i.e., /dev/dm-* is wrong, but UUID= may also be wrong
<mvo> thanks Mirv
<cjwatson> slangasek: the reason for not converting /dev/mapper/VG-LV to UUID is that VG-LV already uniquely and reliably identify the device
<cjwatson> slangasek: I'm not sure whether the same holds for /dev/dm-*, i.e. whether that enumeration is stable
<slangasek> cjwatson: ok - so it's not a concern that UUID= will be less robust for things like multipath?
<slangasek> I don't think /dev/dm-* is stable in the general case
<cjwatson> I'm not entirely certain about multipath, but at least for LVM it's simply that we don't need it
<cjwatson> the reason findfs shows /dev/dm-* is that that's what shows up in /proc/partitions
 * slangasek nods
<cjwatson> it does have some /dev/mapper/ logic, but it's only as a fallback in case it can't find the primary name
<cjwatson> or at least what it thinks of as the primary name
<slangasek> then it doesn't sound like fixing the /dev/dm-* bit is RC
<cjwatson> I'm wondering if it's better to change e2fsprogs (simpler change, but more risk of unforeseen consequences) or grub (more complicated change, but much more contained)
<cjwatson> I'd like to know first whether hardy did /dev/dm-*
<slangasek> well, it didn't for me
<slangasek> nor did intrepid when I installed it, around alpha-4/5
<cjwatson> then it seems to me that there is a risk of regressions here
<cjwatson> I suspect that this is a recent e2fsprogs change ...
<slangasek> yes, that's fair
<ogra> slangasek, hmm, looks like rasmol ftbfs
<slangasek> ogra: no, it failed to upload
<slangasek> we'll see if we can clear that up
<ogra> i got build logs
<ogra> right, not failures
<ogra> didnt look close enough
<ogra> ah, well, hppa failed though
<slangasek> well, it FTBFS on hppa, but everything does
<ogra> yeah, ftbfs seems a normal condition for everything on hppa recently
<slangasek> not everything, just everything that transitively depends on glib2.0
<ogra> ah
<slangasek> so, you know, "Ubuntu"
<ogra> heh
<cjwatson> slangasek: I suspect this in e2fsprogs 1.41.1-1:
<cjwatson> +  * Make the blkid library more efficient for devicemapper devices,
<cjwatson> +       mostly by no longer using the libdevmapper library.
<slangasek> huh
<slangasek> sounds likely :/
<mathiaz> cjwatson: TheMuso: I've filed bug 286538 with my findings about SATA Raid with virtio block devices.
<ubottu> Launchpad bug 286538 in hw-detect "virtio block devices are detected as SATA RAID devices" [Undecided,New] https://launchpad.net/bugs/286538
<cjwatson> mathiaz: I assume this isn't release-critical, it's just an ugly warning, right?
<cjwatson> mathiaz: oh, err, if you carry on does partitioning work?
<mathiaz> cjwatson: hm - I don't it's release-critical. Although it's warning message I wonder what happens if the end user selects yes - activate raid arrays.
<mathiaz> cjwatson: partitionning works as expected.
<cjwatson> oh, virtio is /dev/vd* isn't it?
<kirkland> cjwatson: yes
<mathiaz> cjwatson: correct.
<siretart> asac: is there something left to do for wpasupplicant in bug #272185?
<ubottu> Launchpad bug 272185 in network-manager-applet "[Intrepid] iwl3945 + iwl4965 -- network-manager will not connect to a WPA EAP (Enterprise) network (disassociating by local choice (reason=3) )" [High,Fix released] https://launchpad.net/bugs/272185
<mathiaz> cjwatson: ok. Nothing breaks even if the end user chooses to activate the RAID arrays.
<mathiaz> cjwatson: So it's just a warning message that may be disturbing.
<cjwatson> mathiaz: I bet it's http://paste.ubuntu.com/60209/
<mathiaz> cjwatson: seems like a good candidate. Could SATA Raid device name start with a v ?
<cjwatson> no idea
<cjwatson> this totally isn't for intrepid
<mathiaz> cjwatson: agreed.
<bryce> doko: it's not a hard dependency; it provides some file import/output converters
<doko> bryce: please either write a MIR, or change it to a suggests for intrepid
<bryce> doko: I think currently it only provides a few file formats, but going forward I understand it'll be gaining more
<bryce> hmm, okay will do
<cjwatson> slangasek: what do you think of http://paste.ubuntu.com/60216/ ?
<slangasek> cjwatson: excess use of fork :), but looks good
<lool> doko: I have no strong opinion on opengl in gnome-games
<lool> pitti: Sure
<lool> pitti: I talked to upstream, and we want libvisuall-plugins
<slangasek> (excess use of fork --> stat -c %t:%T, one stat call per device)
<lool> pitti: So I'll look at promoting it
<cjwatson> aha, good point
<doko> lool: ok, if I move to a suggestion?
<cjwatson> http://paste.ubuntu.com/60218/ then
<slangasek> if by 'good' you mean 'nitpicky' :-)
<slangasek> yep, looks good
<asac> siretart: i dont thinks so. didnt i invalidate the wpasupplicant task yet?
<lool> doko: Best to check with seb, not enough data on my side
<doko> lool, will do tomorrow. same for python-gtkglext1
<lool> same answer :)
<asac> siretart: hmm. if it turns out that its still happening then wpasupplicant might be a candidate for this again.
<calc> bryce: yea we will have UTC-0800 to UTC+0800 represented in our group
<bryce> calc, :-/
 * calc thinks we should all move to europe ;-)
<cjwatson> slangasek: hmm, works fine until I reboot and findfs complains about /dev/dm-* not being present ...
<slangasek> hmm, findfs gets called after reboot?
<cjwatson> /etc/init.d/checkroot.sh
<cjwatson> so it fails to check the root filesystem
<slangasek> doh
<cjwatson> I'm wondering if this is a bug in the udev rules shipped in the installer
<cjwatson> <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/d/devmapper/dmsetup_1.02.27-3ubuntu1_i386.deb | fgrep .rules
<cjwatson> -rw-r--r-- root/root      1262 2008-08-27 03:17 ./etc/udev/rules.d/65-dmsetup.rules
<cjwatson> <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/d/devmapper/dmsetup-udeb_1.02.27-3ubuntu1_i386.udeb | fgrep .rules
<cjwatson> <cjwatson@riva ~>$
<cjwatson> is it just me or is that screwy?
<slangasek> hmm, udev doesn't supply the rules centrally?
<cjwatson> slangasek: no, depends on devmapper and mdadm for some of them
<cjwatson> slangasek: ok, I talked through this on the phone with Keybuk
<cjwatson> slangasek: we think that the problem is as follows: missing dmsetup-udeb udev rules => /dev/dm-* exists when it shouldn't, and /dev is bind-mounted onto /target/dev => findfs UUID=foo returns /dev/dm-* *and caches it in /etc/blkid.tab which persists across reboots* => findfs in installed system returns the same value
<cjwatson> slangasek: as far as we can tell, simply restoring the dmsetup-udeb udev rules will fix all the problems at once
<cjwatson> slangasek: except for the fundamental problem that blkid caches stuff across reboots which is the basic difference between blkid and vol_id, so that'll eventually be fixed by using vol_id everywhere
<cjwatson> (probably)
<Keybuk> that findfs is going to bite us in lots of other interesting ways
<Keybuk> I'm surprised it hasn't been already
<slangasek> so do we know where the dmsetup udev rules went?
<cjwatson> lost in a merge from Debian, where waldi did it wrong
<slangasek> ah
<slangasek> so on track for recovering them? :)
<cjwatson> it's a one-liner
<cjwatson> just need to figure out how to test it
<cjwatson> Keybuk: does udev inotify-monitor /etc/udev/rules.d
<cjwatson> ?
<cjwatson> Keybuk: actually, never mind, the question is moot I think
<Keybuk> yes
<Keybuk> ah, I see why that findfs fails in this sense - it overrides UUID=foo to be /dev/dm-0 because that's in the blkid cache
<Keybuk> which will promptly fail to check, and therefore bail out
<Keybuk> _but_ if findfs simply returns nothing, it will use /lib/init/rw/rootdev (?! why not /dev/root ?!) instead
<Keybuk> the other failure mode we tend to see is negative - in that a UUID that vol_id is sure exits, blkid is sure doesn't - so that will fall back to use /lib/init/rw/rootdev
<Keybuk> there may be a bug where findfs returns a different block device than vol_id for a given uuid - but that's gonna be pretty rare
<cjwatson> any time devices change between boots and blkid has the old one cached, findfs and vol_id will return different block devices for a given UUID
<seb128> slangasek: you don't want to accept the evolution-* updates? earlier is better, especially that upstream is not around next week so if changes are required better now
<slangasek> seb128: I was still looking at them; people keep piling more fixes in the queue...
<seb128> slangasek: right, I noticed that, I was just wondering if that was supposed to be a fifo queue ;-)
<slangasek> not entirely :)
<cjwatson> ok, dmsetup-udeb test in progress now
<seb128> slangasek: the diff are probably hard to read, the svn snapshot was a patch in the debian directory
<cjwatson> after typing in the entire rules file by hand
<slangasek> ah, twitch
<cjwatson> slangasek: oh, in case it wasn't clear, the udev rules are in dmsetup just fine, it's just that the debian/rules code for copying those into the udeb was wrong
<slangasek> cjwatson: ah :)
<slangasek> seb128: is anyone taking care of mail-notification and evolution-jescs, which will also need rebuilds?
<slangasek> seb128: e-d-s accepted, btw
<cjwatson> slangasek,Keybuk: bingo
<seb128> slangasek: we have active desktop contributors which will do those and I'll do the sponsoring
<seb128> slangasek: thank you!
<psusi> ok, I am confused as all hell.... make works normally to build/clean/etc this project, but the only thing in the makefile is this:
<psusi> all check clean distclean install mostlyclean uninstall:  @echo "You need to use GNU make (version 3.70 or later)." >&2
<NCommander> StevenK, ping
<NCommander> StevenK, I'm told the linux-lpia-meta upload adding linux-firmware isn't right
<slangasek> bryce: did mvo end up talking to you (or anyone) about this scary xorg-server change?
<TheMuso> cjwatson: disk-detect checks for "No RAID disks" because there may be several disks in a machine that do not have RAID data, and others that do, or thats how I understand it. That was already there when I started doing my dmraid work.
<NCommander> hey TheMuso
<TheMuso> Hey NCommander. Seems I got kicked off at some point, even though my net was still active.
<cjwatson> TheMuso: I'm just in general uncomfortable with human-readable-string checks, and would prefer something based on exit codes (perhaps extending the underlying tools where necessary)
<NCommander> TheMuso, nice. I successfully have a 2.6.27 linux-ports kernel :-)
<cjwatson> psusi: check for other makefiles (e.g. GNUmakefile)
<NCommander> TheMuso, (sorta, there is some sorta makefile bug that prevents it from building the powerpc-smp/powerpc64-smp kernel)
<TheMuso> cjwatson: dmraid has no exit codes that are of any use.
<wgrant> TheMuso: Australian Internet being active? Complain to your ISP.
<cjwatson> TheMuso: hence extending
<psusi> cjwatson: heh, yea, I found it ;)
<TheMuso> cjwatson: If you mean extending dmraid, then its impossible to do and make sure its stable for intrepid.
<cjwatson> TheMuso: sure, I didn't mean for intrepid
 * TheMuso nods.
<TheMuso> I'll look at it for jaunty, if I can get over the crap nature of dmraid as it stands.
<TheMuso> mathiaz: I'll get to that bug in my bug mail, assuming its filed against one of the installer components of dmraid itself.
<mathiaz> TheMuso: it's filed agains hw-test and the dmraid package itself.
<mathiaz> TheMuso: as discussed with cjwatson this is not release critical for intrepid
<cjwatson> hw-detect.
<cjwatson> (hwtest is something else)
 * TheMuso nods.
<Keybuk> I so read that as hw-detest
<Keybuk> which just about sums up my feelings about it
<cjwatson> now now, it still has some useful functions
<nxvl> Keybuk: heh
 * Chipzz pokes TheMuso
<Chipzz> TheMuso: I had a problem a while ago with an ubuntu-server install
<Chipzz> a server with hardware RAID was detected as having software RAID
<Chipzz> and with hardware RAID I do mean *hardware* RAID ;)
<Chipzz> not the crappy el-cheapa semi software raid
<Chipzz> (el-cheapo)
<cjwatson> Chipzz: that problem is why we now ask a question instead of Just Doing It
<cjwatson> Chipzz: bug 279288
<ubottu> Launchpad bug 279288 in partman-base "User interface exception request: Ask the user if they wish to activate dmraid arrays." [High,Fix released] https://launchpad.net/bugs/279288
<Chipzz> cjwatson: ah ok, I was wondering if there was something I could do to help debug why it did that
<cjwatson> Chipzz: it seems that you had something looking very much like dmraid metadata lying around on your disks, regardless of the current state
<TheMuso> Chipzz: SOunds like the disks were from a dmraid/Fake RAID array, and they still have the metadata on them. Some BIOSes are very bad in not cleaning up the metadata if the user turns the feature off.
<Chipzz> TheMuso: no, the RAID is presented as 1 SCSI disk to the OS
<Chipzz> (mirroring raid)
<Chipzz> so that would be unlikely, right?
<TheMuso> Chipzz: thats not what I'm talking about. What I am saying is that the disks still have what looks like dmraid metadata on them, from a previous setup, basically what cjwatson was saying.
<psusi_> anyone got any idea why gcc would not complain about multiple definitions of main with -02 but does with -O0?  this is fubar... how did this ever compile?
<TheMuso> Which is why dmraid picked up on them and activated them.
<Chipzz> TheMuso: which wasn't the case. the previous install was a debian install
<Keybuk> psusi_: warnings are dependant on optimisation level
<Chipzz> and some attempts to install ubuntu-server on it I guess
<TheMuso> Chipzz: Right.
<Chipzz> well, actually I'm incorrect
<psusi_> Keybuk: a vilotion of ODR is not a warning though... it's a link error, hands down
<Chipzz> the previous install was a VmWare ESX install
<Chipzz> dunnow if that does anything weird to the disks though
<Keybuk> psusi_: neither -O0 or -O3 are linker options
<Keybuk> so I'd guess from your description that you're only talking about warnings at compile stage
<Keybuk> and simply haven't tried to link yet
<psusi_> Keybuk: yea... I know... which is why this is so odd... all I do is change the -O setting in the debian/rules, and it makes it work or not... the makefile is apparently linking several objects into a library, one of which contains a main definition
<Chipzz> TheMuso: but anyway, I succeeded with installing ubuntu-server on it, but wasn't happy with the settings wrt LVM/encryption I had, so I reinstalled ubuntu-server a second time
<psusi_> and then it links this library with another file with its own main to produce a binary
<Chipzz> by which time the dmraid remnants should have been gone
<Keybuk> psusi_: one fails, another doesn't?
<Chipzz> and the 2nd install still wanted to install dmraid
<psusi_> with -O2 it actually works, which it shouldn't... when I set -O0 to try and debug something else, it fails to build
<TheMuso> Chipzz: Well the dmraid metadata is usually always at the end of the disks.
<Chipzz> TheMuso: any (non-destructive) tests I can run?
<Keybuk> psusi_: maybe one of the main()s get optimised out at compile-time
<Keybuk> so the linker only ever sees one?
<TheMuso> Chipzz: TO be sure you have no metadata lying around, you can run "sudo dmraid -rE" to erase it.
<psusi_> hrm....
<Chipzz> TheMuso: well the server is installed, so the problem is gone AFA I am concerned, so that won't be necesarry anymore ;)
<Chipzz> but if it can be of any help to you, I can do some tests if you want to?
<psusi_> Keybuk: I can't see how that could happen though, and objdump shows main in both the object and the library yet the linker links them just fine as long as I build with -O2
<Keybuk> psusi_: nothing can introduce random appearance and disappearance of a behaviour during debugging quite as effectively as a compiler's attempt at optimisation
<psusi> Keybuk: so does this look like a bug in gcc to you then?
<Keybuk> psusi: no, not until you can explain why it behaves that way
<TheMuso> Chipzz: No I think all is ok at the moment.
<Keybuk> it doesn't sound like it's producing invalid code, so it's just a curious behaviour that might amuse
<Chipzz> TheMuso: btw, I have encryption set up on the box
<Chipzz> TheMuso: maybe that would be the reason for dmraid?
<Chipzz> or is dmraid not needed for encryption?
<bryce> slangasek: no not so far
<slangasek> bryce: huh.  well, the upload is in the unapproved queue, could you give a professional opinion on whether I should accept it? :)
<bryce> ok, how do I view the unapproved queue?
<slangasek> bryce: bug #278112, if you don't have the bug number
<psusi> Keybuk: is there any time gcc is supposed to accept a library and an object as inputs to link when both contain definitions of main?  I wouldn't think so, but man I'm not sure which end is up now
<ubottu> Launchpad bug 278112 in xorg-server "Screensaver doesn't start" [Medium,In progress] https://launchpad.net/bugs/278112
<bryce> thanks
<slangasek> probably easier to review the debdiff he posted there
<superm1> slangasek, do you want me to post a debdiff for splitting that fglrx package up somewhere to review how I did it, or just upload it and you'll take a look then?
<slangasek> superm1: upload please
<superm1> slangasek, okay
<slangasek> uploads to the unapproved queue give me an implicit debdiff :)
<Keybuk> psusi: you'd have to prove that was what it was doing
<cjwatson> bryce: queue should be accessible from https://launchpad.net/ubuntu/intrepid/+queue
<Keybuk> I'd be more inclined to believe that something else was happening
<psusi> Keybuk: objdump foo.a -t | grep main and objudump bar.o -t | grep main show they each have a main, which they should seeing as how there is one in bar.c and one in a source file that is compiled and linked into foo.a
<Keybuk> does objdump work on a .a file? :p
<slangasek> no
<psusi> umm.... yea?
<slangasek> oh, objdump -t does, yes
<bryce> cjwatson: aha
<Keybuk> does it?
<psusi> yet somehow these two files are linked to produce a working binary.... but only if I leave -O at 2 in the rules
<Keybuk> psusi: assumingly it discards one of them
<slangasek> yes, gcc is good at throwing stuff out of .a files that it doesn't need
<bryce> slangasek: ok the patch looks alright to me, although I'm curious if there are implications you're concerned about?
<psusi> Keybuk: yea... but it shouldn't... and why does it only do it with -O2?
<Keybuk> psusi: why shouldn't it?
<slangasek> bryce: I'm always concerned about the implications of patching the core X server :)
<Keybuk> as slangasek says, gcc has a long and honourable history of ignoring bits of .a files
<psusi> Keybuk: because it violates the One Definition Rule
<Keybuk> what One Definition Rule?
<Keybuk> we're talking about gcc not g++, no?
<psusi> THE ODR that is part of C and C++ ;)
<Keybuk> there is no ODR in C
<psusi> ?!
<slangasek> C is odrless
<Keybuk> and deadly
<psusi> no way
<Keybuk> way
<psusi> the linker always complains if you try defining two symbols with the same name
<psusi> it has to; it has no way of knowing which one you want
<Keybuk> it's hard for you to justify such a statement when talking about an issue where the linker isn't complaining ;)
<psusi> well, then why does it complain with -O0 ;)
<Keybuk> because with optimisation enabled, gcc discards various bits of .a files first
<Keybuk> including, assumedly, your object file with main() in it
<Keybuk> so by the time it comes to link, it only has the one from the object file
<RicardoPerez> Hi! Can anybody test if left-arrow key goes slower than right-arrow key when you previously do: xset r rate 10 50
<RicardoPerez> Thanks in advance
<psusi> why would it disgard the main in the library when optimizing though?
<slangasek> bryce: so should I go ahead and let this xorg-server change in?
<psusi> it's referenced.... so it shouldn't discard it
<slangasek> no, "main" is referenced
<slangasek> and it already has one of those, so it can toss out the other one
<psusi> how is that not a mal formed program in C?
<slangasek> why are we even having this discussion?  Why have you not simply fixed your code to not put functions named "main" in a static lib?
<Keybuk> why should it be malformed?
<psusi> because I'm not sure how this crazy makefile is working
<psusi> Keybuk: ODR ;)
<Keybuk> that's C++
<psusi> I could have sworn that came from C
<Keybuk> nope
<psusi> and it's absolutely insane not to have it
<Keybuk> C doesn't have rules
<slangasek> haha
<Keybuk> C has gaping chasms the standard refers to as "undefined"
<Keybuk> or their other favourite cop-out
<Keybuk> "implementation defined"
<Keybuk> I'm not entirely sure that the C standard even talks about linking
<slangasek> I'm not aware that it does
<cjwatson> it talks about *linkage*, which is related but not the same thing
<cjwatson> actually, it does talk about linking a bit
<cjwatson> e.g. 5.1.1.1 "Translation units may be separately translated and then linked to produce an executable program"
<cjwatson> elsewhere it says that if an identifier has both internal and external linkage then the result is undefined
<Keybuk> yeah, was just reading 5.1
<bryce> slangasek: yes I think it should be fine
<cjwatson> many things are erroneous C (in the sense that they are not defined) but compilers/linkers are not required to produce diagnostics for them
<slangasek> bryce: accepting, thanks
<bryce> slangasek: no red flags are jumping out; not likely to cause crashes or serious regressions, just a 2-line change, etc.
<slangasek> bryce: so you don't think it's going to cause horrible memory leaks by returning early? :)
<superm1> bryce, has the fix to xorg-server regarding nv that you posted been tested/decided upon yet?
<Keybuk> cjwatson: 6.9.5 maybe?
<TheMuso> cjwatson: thaanks for the patch to dmraid, I just need someone to test the patched version with virtio block devices. mathiaz How do you set up a vm with virtio block devices, so I can test this?
<Keybuk> that's about the closest I can see
<Keybuk> but amusingly, by its very working, appears to exclude main() :p
<cjwatson> Keybuk: you have a different version of the standard than I do; my 6.9 ("External definitions") only goes up to .2 ("External object definitions")
<mathiaz> TheMuso: are you using libvirtd or kvm from the command line directly?
<cjwatson> I should get an updated version at some point
<Keybuk> cjwatson: I have BS ISO/IEC 9899:1999 (C99 inc TG1)
<Keybuk> http://www.amazon.co.uk/C-Standard-British-Standards-Institute/dp/0470845732/
<slangasek> superm1: better than a -XlibAMD would be using the debian/shlibs.local that I suggested in the bug report
<TheMuso> mathiaz: I usually use libvirt.
<slangasek> superm1: this lets you statically declare that libstdc++.so.5 is contained in the package libstdc++5 without build-depending on it, which is a pretty safe thing to assume, and safer than assuming that the lib dependencies of libMDXvBA.so will remain constant
<mathiaz> TheMuso: ok - so I'd suggest that you dumpxml the configuration of the host and modify the section about drive definition
<slangasek> superm1: also, if you're calling dh_shlibdeps -XlibAMD, then ${shlibs:Depends} will be /completely/ empty for this package, so no lib deps other than libstdc++5 will be picked up either
<superm1> slangasek, ah yeah, that's a valid repercussion
<TheMuso> mathiaz: Right, what do I change?
<slangasek> superm1: have I explained adequately for you to reupload with that change?  if so, I'll reject this package back out of the queue
<superm1> slangasek, yeah.  let me make it and verify that it still handles correctly locally and i'll reupload
<slangasek> ok, thanks
<mathiaz> TheMuso: in the disk definition, change the target element to : <target dev='vda' bus='virtio' />
<TheMuso> mathiaz: Right thanks.
<mathiaz> TheMuso: the important part is that the dev attribute starts with v
<mathiaz> TheMuso: and the bus is virtio
<TheMuso> mathiaz: Right.
<mathiaz> TheMuso: then reload the configuration of the machine with the define command from virsh
<TheMuso> mathiaz: Ok thanks will get that tested.
<ArneGoetje> slangasek: those language codes don't have locale data available, that's why there is no language-pack-base package and the language is unusable. To fix this we need locale data for those languages.
<slangasek> ArneGoetje: ok, where do we get such locale data? :)
<slangasek> seeing that these packages will block DVD builds until they're either fixed, or removed from main
<cjwatson> let's just remove those packages?
<ArneGoetje> slangasek: then remove them for now. We can't support them anyways.
<cjwatson> I don't see a good reason to keep them
<slangasek> fine with me, yes
<cjwatson> ArneGoetje: can you fix langpack-o-matic not to generate them again
<cjwatson> ?
<cjwatson> until locale data exists
<ArneGoetje> slangasek: actually, langpack-o-matic should have just skipped them if there is no locale data available... I will take a look at it.
<slangasek> ok; nuking the packages, in the meantime
<ArneGoetje> cjwatson: will do
<slangasek> ArneGoetje: also, language-support-extra-de is uninstallable; I'm thinking you don't want me to nuke that one
<cjwatson> it's also not seeded ...
<cjwatson> all the other language-support-extra-* are in universe
<slangasek> oh, perhaps that's why it's uninstallable
<ArneGoetje> slangasek: the translation teams for those languages would need to generate locale data and submit them to upstream glibc
<cjwatson> yeah
<slangasek> right, I'll demote that shortly then
<cjwatson> I've demoted it
<slangasek> ok
<ArneGoetje> cjwatson: yes, the l-s-extra packages belong to universe.
 * lamont wonders if there's a good writeup somewhere on using a bluetooth headset on hardy
<lamont> or intrepid, for that matter
<ScottK> lamont: If you're on KDE it'd really simple since it's currently broken.
<StevenK> NCommander: Yeah, I've been thinking about it, and lpia-lrm should Depend on it
<lamont> ScottK: lol
<superm1> lamont, sco or a2dp?
<superm1> lamont, if a2dp, just pair with it, and drop this http://paste.ubuntu.com/60294/ in ~ and go.
#ubuntu-devel 2008-10-21
<cjwatson> kwwii: bug 286677, FYI
<ubottu> Launchpad bug 286677 in human-theme "[regression 0.28.3] /usr/share/themes/Human/gtk-2.0/gtkrc:273: Unable to locate image file in pixmap_path: "panel_bg.png"" [Medium,New] https://launchpad.net/bugs/286677
<cjwatson> (might not be as high as Medium, I don't know if it has other consequences)
<kwwii> cjwatson: dooh, another stupid mistake
<kwwii> cjwatson: easy to fix, silly to make, I made the source package from the wrong dir
<kwwii> cjwatson: fixed first thing tomorrow
<kwwii> and I am kicking myself in the butt for not noticing
<cjwatson> kwwii: thanks
<cjwatson> kwwii: might not make RC at this point, what's the consequence of that?
<cjwatson> we could probably slip it into final if the change is really easily reviewable
<kwwii> cjwatson: if it causes a noticeable error somewhere it is worth fixing
<cjwatson> oh, I agree
<kwwii> and the fix is really easy, just remove the crap I added trying to work around the panel background stuff
<cjwatson> I was just wondering if it would cause the desktop to visibly explode or anything
<kwwii> I know exactly what I did, I just made the source package from the wrong dir
<kwwii> really, really dumb on my part
<cjwatson> mkdir empty && cd empty && dh_make? ;-)
<cjwatson> anyway, bed
<lamont> superm1: ~/WHAT?
<kwwii> cjwatson: well, I did change things after that change...more like re-applying the changes I added today to the bzr repo and making new source packages
<kwwii> this really makes me sorry for the work pitti did including it...he trusted me (I did not notice any problems but my system is so messed up in the meantime I doubt it notices anything)
<kwwii> I hope he is has as much patience as I do time to make mistakes
<kwwii> cjwatson: thanks very much for noticing this and bringing it to my attention
<kwwii> I will fix it asap
<kwwii> cjwatson: here is a new source package which fixes my (stupid) mistake:
<kwwii> http://sinecera.de/human-theme_0.28.4_source.changes
<StevenK> kwwii: A debdiff with the changes would help a lot
<kwwii> StevenK: the only difference is that I removed one definition of the panel bg (which I also forgot to add to bzr and therefor the problem)
<kwwii> I can recreate the old stuff (already changed it locally and added it to bzr)
<kwwii> if it is really important
<kwwii> I'll take care of this first thing tomorrow
<kwwii> in fact, I noticed I made the same mistake twcie
<kwwii> twice
<kwwii> ignore that url, I will fix it tomorrow and include a debdiff
<kwwii> sorry for the wasted time
<superm1> lamont, ah sorry :) ~/.asoundrc
<lamont> ta
<superm1> slangasek, i'm not convinced debian/shlibs.local will resolve this, as indicated by: http://paste.ubuntu.com/60304/plain/
<NCommander> ah, superm1
<NCommander> ugh
 * NCommander twichs
 * NCommander checks the libstdc++ source package
<superm1> well it provides the appropriate shlibs
<superm1> but it's in universe and wont be available at package build time
<superm1> so debian/shlibs.local was hopefully going to work around as necessary
<NCommander> superm1, why do you need such an old libstdc++ ?
<superm1> i dont, but AMD seems to think their library does
<superm1> gotta work around their mess unfortunately
<NCommander> Is this a multiverse package we're talking about?
<superm1> it's multiverse, but should be in restricted
<NCommander> I assume no source
<superm1> once this is sorted out, the source package will be restricted
<superm1> and the binary will be multiverse
<superm1> yeah no source :(
<NCommander> (why is it in multiverse?)
<NCommander> Argh
<NCommander> What is it specifically?
<superm1> graphics driver and some acceleration libraries
<NCommander> Oh
<NCommander> More ick
<superm1> the driver will be in restricted, the libraries in multiverse
<NCommander> If its just premade binaries, why does it need to build depend, you can explicately set the depends if shlibs can't find it for some reason
<NCommander> or is it half source available, half no-source?
<kwwii> StevenK: the debdiff does not offer anything..the only change is two lines in two gtkrc's
<NCommander> ^- superm1
<superm1> NCommander, well it doesn't need build depends, but the shlibs should be checked dynamically because they can change release to release
<superm1> NCommander, (and actually have in the past)
<superm1> but i'm not sure why shlibs.local isn't overriding like it should be in this case
<NCommander> Simply build-dep on the non-dev package
<NCommander> That will get the .shlib file installed from libstdc++3, but prevent gcc 3.3 from being pulled in
<NCommander> Its probably the sanest solution of the bunch
<superm1> NCommander, well the problem is that all of gcc-3.3 is in universe
<NCommander> OH!
<NCommander> The restricted package is the one tha thas the issue
<NCommander> The only sane thing you can do is to promote libstdc++3 by itself. If the driver depends on it, I don't think you can work around that
<superm1> well the idea was that the "source" package would live in restricted, and its binary graphics driver would too.  this library would be in multiverse and thus allowing libstdc++5 to be in universe still
<kwwii> StevenK, cjwatson: debdiff is apparently supposed to be run on the dsc files? I tried it with the debs but that spits out nothing
<NCommander> superm1, *twich*
<superm1> NCommander, yeah.  but this shlib-deps problem aside, it'd be a "functional" solution
<kwwii> StevenK, cjwatson: whereas the debdiff for the dsc files is this: http://sinecera.de/human_theme.debdiff
<kwwii> which shows the necessary changes
<bryce> superm1: tjaalton reviewed it; I think it needs tested/validated first to make sure it does indeed fix the issue
<NCommander> Can a package from main/restricted create binaries in universe/multiverse?
<NCommander> superm1, thats against Debian policy for instance ...
<bryce> superm1: if you could test it and report that it does solve the issue, that would help
<NCommander> (well, main/non-free, you can do main/contrib)
<superm1> bryce, would you mind pushing it to a PPA?
<bryce> superm1: there was a small alteration timo suggested, to make it only pick -vesa on non-ppc, etc. that should be easy enough to add
<superm1> NCommander, well slangasek said that would be okay to do.
<superm1> NCommander, and actually i know of a package i already touch that does something like that
<superm1> NCommander, the lirc source package is in main, and has a library in main.  it has a few binary packages in universe however
<NCommander> point taken
<ScottK> NCommander: If any binary is in Main, the source needs to be in Main, but unneeded binaries can and should be in Universe.
<superm1> NCommander, so these points aside, that error i posted, do you see anything blatant that stands out about what's wrong with that method of working around this?
<ScottK> NCommander: See the Sendmail package for an example.
<NCommander> superm1, give me a minute
<NCommander> I normall have issues groking shlibs files in general
 * NCommander whacks superm1 
<NCommander> wait
 * NCommander unwhacks
<kwwii> StevenK: is that debdiff good enough? (/me is just learning deb packaging, it is an honest question)
<superm1> NCommander, so perplexing eh?
<NCommander> superm1, what happens when you add -v to dpkg-shlibsdeps?
<superm1> http://paste.ubuntu.com/60316/
<NCommander> Uh
 * NCommander figured it out and promptly smacks superm1
<NCommander> shlibs.local requires the library to be installed
<superm1> gah.
<NCommander> It won't work if libstdc++5 isn't installed
<superm1> well that's counterproductive then
<NCommander> shlibs.local is designed to solve a very specific problem :-)
<superm1> NCommander, okay well then I think the only solution is to hardcode the shlib dependencies, and -xlibAMD when running dpkg-shlibdeps
<superm1> agreed?
<slangasek> superm1: -Ldebian/shlibs.local should be unnecessary and may be confusing it
<superm1> slangasek, i added that because it wasn't working
<superm1> slangasek, but it's the same behavior without it there
<slangasek> superm1: hmm.  ok, then it's failing because it wants to find the library first before honoring the shlibs; grr, I don't think it did that before buxy rewrote it
<superm1> slangasek, well in any case, this library only has two shlibdeps anyhow, libc6 and libstdc++5.  will just have to watch in the future if that changes
<slangasek> ok
<superm1> i caught another problem with ia32-libs similar by messing with this though, so it was a good exercise
<superm1> i'll push it up
<slangasek> sounds good
<kirkland> anyone know why the manpages-posix-dev package is in multiverse?  <- cjwatson ?
<slangasek> kirkland: it's in non-free in Debian and probably wasn't revisited?
<kirkland> slangasek: yeah, hasn't been touched in ~3 years
<kirkland> okay, it's not hurting anything ...  just dealing with some wonkiness for the manpage repository
<ScottK> lool: Did you see there's a gedit-plugins upload pending?  Is it one we want?
<rascov> If I want to send a patch of GNU screen to Ubuntu official package, what should I do? (just porting new function from FreeBSD)
<persia> rascov, https://wiki.ubuntu.com/Bugs/HowToFix might be a good place to start.
<Chipzz> rascov: also, #ubuntu-motu (cfr topic) ;)
<rascov> persia Chipzz: thanks :)
<Chipzz> rascov: though the changelog mentions CVS head was merged at Jun 02, 2008
<Chipzz> dunnow how recent that new function is
<rascov> In Ubuntu, is there a person like port maintainer or commiter in FreeBSD ?
<ScottK> rascov: In Ubuntu it's mostly done on a team basis rather than specific people for specific packages.
<rascov> Should I contact the team if I wish to add a new function ?
<ScottK> rascov: Generally the best thing is to file a bug against the package with your patch.
<RAOF> Hey, has nvidia-glx-96 been updated to actually work with Xserver 1.5?
<RAOF> It seems jockey is recommending nvidia-glx-96 to someone, and I thought we'd stopped doing that on the basis that it won't work.
<rascov> ScottK: I see, thanks
<tjaalton> superm1, bryce: also, the patch should be verified to not force vesa when not using an xorg.conf
<RAOF> In fact, why are the nvidia-glx-{96,78} in the archives at all?
<RAOF> Are we hoping nvidia will release a drivers that support 7.4 and we can push them in?
<tjaalton> "they are working on it"
<tjaalton> or something like that
<tjaalton> correct quote would be; aaronp: "I'm working on it"
<tjaalton> but who knows when that happens
<RAOF> Indeed.  What do we _do_ about this?
 * tjaalton twiddles thumbs
<RAOF> There are currently two large packages in the archives which do nothing but break 3d.
<tjaalton> I think they are waiting there for an SRU
<ScottK> RAOF: xserver-xorg-video-radeonhd isn't one of those packages is it?
<superm1> just like fglrx was going to wait for an SRU if it ever came
<RAOF> ScottK: No; that can only break 3d for people with ATI cards; nvidia-glx breaks it for _everyone_ :P
<ScottK> Ah.
<RAOF> And that driver also has the advantage of a possibility of working.
<ScottK> Because there was a user, who I generally consider reliable, who reported 1.2.3 working with 3D
<RAOF> I don't know if our mesa is new enough for that, but I believe the very latest radeonhd _
<RAOF> + mesa + drm _does_ do 3d.
<tjaalton> radeon/radeonhd for r5xx has had 3d since mesa-7.1, and we have 7.2
<dholbach> good morning
<RAOF> tjaalton: Really?  Cool.  You learn something new everyday :)
<RAOF> And forget it just as quickly, sadly.
<dholbach> doko: do you haven an idea about this:
<dholbach> <maco> Setting up five-a-day (0.58~hardy1) ...
<dholbach>  pycentral: pycentral pkginstall: not overwriting local files
<dholbach>  pycentral pkginstall: not overwriting local files
<StevenK> dholbach: "not overwriting local files" is a hint
<dholbach> StevenK: maco was having these problems in #ubuntu-bugs
<StevenK> five-a-day is trying to install files that already exist
<dholbach> StevenK: it was an upgrade :)
<StevenK> Hum
<StevenK> Argh, libcamel in NBS again?
<fabbione> kees: ping?
<slangasek> StevenK: upload the reverse-deps and we can make it go away? :)
<fabbione> kees: please let me know (via email.. i guess you are deeply asleep) if you need patches for CVE-2008-4192, CVE-2008-4579 and CVE-2008-4580
<fabbione> kees: the fixes upstream are extremely simple but i just don't have time to look into all the packages in Ubuntu
<StevenK> slangasek: Plotting to
<pitti> Good morning
<\sh> moins pitti :)
<StevenK> Morning pitti
<lool> morning
<lool> ScottK: I have no idea about gedit-plugins; I saw some discussion around it on #ubuntu-desktop yesterday
<lool> ScottK: http://paste.ubuntu.com/60403/
<lool> Now you know as much as I do
<StevenK> pitti: Could you be tempted to approve my linux-lpia upload? :-)
<pitti> kirkland: ok, I'll reply in the bug
<pitti> kirkland: done
<pitti> StevenK: why doesn't linux-lpia simply depend on linux-firmware instead of shipping a copy?
<slangasek> isn't that exactly what it does?
<StevenK> pitti: It does
<slangasek> pitti: sorry, just accepted linux-lpia-meta
<pitti> StevenK: ah, then the changelog is confusing
<pitti> slangasek: no problem, I was just curious about what it actually does
<StevenK> It meant the binary packages linux-lpia{,compat}
 * StevenK looks at the NBS list for libcamel
<pitti> StevenK: you mean you moved the dependency to another package?
<StevenK> pitti: It moved from linux-lpia to linux-image-lpia, to mirror what linux-meta does
<pitti> StevenK: right, that makes sense
<pitti> lool: libvisual-plugins pulls in jack, that needs to be dropped when moving it to main
<mdke> if someone could sponsor an upload for bug 286829 I'd be grateful
<ubottu> Launchpad bug 286829 in ubuntu-docs "Please update ubuntu-docs from bzr" [High,New] https://launchpad.net/bugs/286829
<pitti> kwwii: no problem; well, I didn't upload it completely blindly, I built, installed, and restarted my session, and it still looked okay :)
<pitti> kwwii: anyway, you need to tell me what this bug is actually all about; to me, it just looks like if someone used the temporarily broken package with the wrong file name "Darkroom", he'd get that on upgrade
<lool> pitti: Ok
<pitti> kwwii: looking at your new package now
<pitti> StevenK: libcamel NBS> eww GNOME 2.24.1
<StevenK> pitti: Yes.
<pitti> StevenK: libtotem-parser is part of gnome, so seb128 will do that himself
<slangasek> it's already done
<pitti> but we should do that evolution-jescs thing
<pitti> slangasek: oh, great
 * StevenK removes totem from his list
<StevenK> My no-change rebuild of evolution-jescs builds
<StevenK> Just waiting for mail-notification and I can upload them
<slangasek> though it was done a bit later than the rest of the stuff in main, so there was an intervening CD run that's oversized because it has two copies of libcamel on it :-P
<StevenK> Hah
<pitti> kwwii: I added (LP: #286677) to the changelog, please do in bzr, too; before I upload this, can you please explain why the bg_pixmap definition was introduced, and why removing it is the right thing?
<mdke> slangasek: how tight is CD space at the moment? the recent build i did of the new version of ubuntu-docs is 1.7MB bigger than the version in the archive
<mdke> slangasek: if that's a problem, we'd have to look at reducing the package
<StevenK> pitti, slangasek: Both my no-change rebuilds build locally, uploading them.
<slangasek> mdke: we have approximately zero space for new stuff - why are the docs so much bigger suddenly?
<mdke> slangasek: basically, ubuntu-docs ships translations which are 40% translated or more, that means that in the import of translations I did from Rosetta, people have made a lot of progress on translation
<mdke> slangasek: we can try adjusting the figure of 40% upwards in order to reduce the package
<slangasek> mdke: and they're not shipped in separate binary packages?
<mdke> slangasek: no, it's all in ubuntu-docs
<slangasek> mdke: what this comes down to is that in order to find you 1.7MB of free space on the CDs for the doc translations, I would have to drop langpacks
<slangasek> that doesn't sound like a winning trade to me
<StevenK> pitti: How can I debug why CK run in Xsession.d doesn't set DISPLAY or active?
<mdke> slangasek: I guess we should try and see how big ubuntu-docs works out with shipping translations which are 50% complete, rather than 40%
<pitti> reallistically, a 40% complete documentation pretty much requires the reader to understand English anyway..
<mdke> yes, I wouldn't have a problem with going up, even to 60%
<pitti> I thought for that reason we set the bar to like 70% earlier?
<pitti> but yeah, I'm fine with adjusting it to min(sanity,cd space)
<mdke> it's always been 40% in previous releases, mainly to encourage translations, but if there is an issue with disk space, it makes sense to increase it
<pitti> StevenK: is $DISPLAY actually set in 90consolekit?
<mdke> slangasek: unfortunately, ubuntu-docs takes about an hour to build and I have to go to work, but I will leave it running a couple of test builds at 50, 60, and 70%
<StevenK> pitti: Lemme check
<mdke> slangasek, pitti: I guess I'll drop the request for sponsoring until that further investigation is done
<StevenK> pitti: Yes, it is set
<StevenK> pitti: As in, stuffing a echo "$DISPLAY" > /tmp/foo in 90consolekit results in :0
<emgent> morning people
<pitti> james_w: the CK fix sounds like an excellent SRU candidate
<pitti> StevenK: hm; then I'm afraid this needs a gdb session
<pitti> StevenK: let me try it here with the Xsession.d script
<james_w> pitti: if it's not RC material then I agree.
<StevenK> pitti: Bug 285054 updated
<ubottu> Launchpad bug 285054 in Ubuntu Intrepid "Can't mount USB keys in xinit sessions" [High,Incomplete] https://launchpad.net/bugs/285054
<pitti> james_w: we could upload it right after RC, too
<seb128> hey james_w pitti
 * pitti hugs seb128, great GNOME marathon yesterday!
 * seb128 hugs pitti, thanks
<pitti> StevenK: a-haa! XDG_SESSION_COOKIE is already set
<james_w> pitti: that's your call. I would appreciate review and testing, as I'm not completely confident
<seb128> pitti: we still have some slots for non-CD updates today?
<james_w> hey seb128
<james_w> great work on .1 :-)
<pitti> seb128: -> slangasek; but since most of main is on the DVD, the answer might be "no"
<seb128> ah DVD
<StevenK> pitti: Right
<StevenK> pitti: Now to figure out why it's set
<slangasek> yes, those big evil fat CD things
<seb128> slangasek: hey
 * slangasek waves
<seb128> so I'm not clear what we should do from now
<pitti> StevenK: how do you start X?
<StevenK> pitti: Via startx
<pitti> StevenK: from an init script?
<lool> pitti: I'm pretty sure it's the xinit support i'm pointing at in the bug report
<StevenK> pitti: An upstart script
<lool> StevenK: Check out xinit from git and see whether they merged support for CK
<lool> it should be reverted from xinit, it can not work from there
<pitti> StevenK: the only other thing that creates sessions I'm aware of is libpam-ck-connector
<seb128> slangasek: will some updates be accepted after rc and should we work on SRUing now?
<pitti> lool: yes, I agree; wasn't aware of that
<pitti> but there shouldn't be a PAM session in upstart scripts or init scripts, so that wouldn't be it
<lool> I commented as such in the upstream bug, but I bet they merged the patch nevertheless
<seb128> slangasek: the new pidgin (changelog on http://developer.pidgin.im/wiki/ChangeLog) for example
<slangasek> seb128: some will be accepted after RC, to be sure; including the bits of GNOME that haven't made it through yet
<lool> pitti: Actually we use "su"
<seb128> slangasek: ok thanks
<pitti> lool: !
<lool> So there might be a pam session
<pitti> lool: that uses PAM
<StevenK> Maybe we want to use su - -l
<lool> No
<lool> pitti: is pam-ck the default nowadays?
<pitti> lool: yes
<lool> ohh
<lool> that's probably the issue then
<pitti> /etc/pam.d/common-session
<pitti> sessionoptionalpam_ck_connector.so nox11
<pitti> eww, seems weechat doesn't like tabs
<lool> Then we can simply clear the CK session when launching startx; env ignore or seomthing
<lool> StevenK: Try with env -u XDG_SESSION_COOKIE in the upstart job
<pitti> lool: that would be a working hack, I just wonder why ck-connector should be made more clever
<StevenK> lool: Geh? In which bit?
<lool> pitti: Hmm what we would need is for the Xsession.d script to check whether there's a running CK session and provision the DISPLAY info in it
<lool> Instead of just considering presence/abscence of a running session
<pitti> right
<pitti> since we're going to start a new one for a different tty
<lool> StevenK: /etc/event.d/session; use env -u XDB... between su and startx
<StevenK> Hm. That didn't seem to help, and I still have XDG_SESSION_COOKIE in the env dump
 * StevenK forcibly restarts the job
<StevenK> lool: "env -u XDG_SESSION_COOKIE; startx -- -br" doesn't look to help
<lool> StevenK: Without ;
<StevenK> That seems to give me a session that sets x11-display
<lool> StevenK: is it active?
<StevenK> Yes
 * StevenK checks if he can mount a USB key
<StevenK> I can! \o/
<StevenK> pitti: Does that hack not make you ill?
<pitti> StevenK: It's not exactly aesthetically pleasing, but *shrug*, if it works :)
<pitti> StevenK: my preferred solution would be to fix 90consolekit to call ck-launch-session if there's an existing cookie which does not belong to an X11 one
<pitti> but mapping cookies to sessions isn't possible as normal user
<pitti> so we'd need some proper support for this in CK itself
<pitti> james_w: ah, that CK test case works tremendously well
<StevenK> pitti: Sure, so this is a last-minute OMG-it-works-ship-it hack
<pitti> StevenK: absolutely fine for me
<lool> StevenK: Hmm where do you say you get this?  in mid?
<lool> StevenK: it's not supposed to pull libpam-ck-connector
<lool> It's derived from minimal, not desktop-common
<StevenK> lool: Yes
<lool> StevenK: Is this a recent install, or an upgraded system?
<StevenK> lool: This is the most recent daily
<lool> I think it's worth fixing it for systems with libpam-ck-connector (like mine, I use startx!)
<StevenK> libpam-ck-connector is installed
<lool> StevenK: Weird, any rdeps?
<lool> Oh consolekit
<StevenK> Yup
<StevenK> We probably shouldn't fiddle with that
<lool> Well I seriously think we don't need it in mid/mobile
<lool> But that's not a fix, and it's late to drop it in this cycle anyway
<pitti> StevenK, lool: FWIW, I'm fine to drop the Recommends: libpam-ck-connector from consolekit
<lool> pitti: I think it should be downgraded in next cycle
<lool> As to allow us not to pull it
<pitti> lool: *-desktop pulls it in already anyway
<lool> Yup
<pitti> lool: depends; if we upload james_w's patch soon, we can as well drop it
<lool> pitti: what's the patch?  bug #?
<pitti> lool: bug 269651
<ubottu> Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,In progress] https://launchpad.net/bugs/269651
<lool> Nice one
<StevenK> pitti: Could you be convinced to accept ubuntu-mid-default-settings and contacts in unapproved?
<pitti> StevenK: done
<StevenK> pitti: Danke
<tjaalton> pitti: hey, I'm having second thoughts about not installing the wacom.fdi by default.. people seem to be more upset about not being able to use their stylus OOTB than making it more complicated to get the full functionality working (eraser/cursor etc). So reverting the change would fix bug 282203, ok to upload?
<ubottu> Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Wishlist,Triaged] https://launchpad.net/bugs/282203
<pitti> StevenK: please close bug 285054 manually, it didn't have a package attached
<ubottu> Launchpad bug 285054 in Ubuntu Intrepid "Can't mount USB keys in xinit sessions" [High,Incomplete] https://launchpad.net/bugs/285054
<pitti> tjaalton: you can upload, but I can't accept it right now; this needs to wait until after RC
<pitti> tjaalton: also, I'm not sure whther this kind of change is appropriate now; we had the current setup for quite a while, so changing it now might introduce other regressinos?
 * pitti actually likes the term "regressino" as a "small regression"
<tjaalton> pitti: it was changed since beta
<tjaalton> pitti: also, bug 261977 is reviewed and fix committed
<ubottu> Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
<tjaalton> but post-RC is fine
<pitti> tjaalton: ok, ok; worth discussing then, can you please upload and subscribe ubuntu-release?
<pitti> tjaalton: 261977> nice, thanks; will go in post-RC, too
<tjaalton> pitti: sure, will do
<persia> pitti, abogani asked me if http://paste.ubuntu.com/60432/ would be an acceptable debian/copyright for l-r-m-rt.  WOuld you accept that, or do you want something more traditional?
<pitti> persia: ah, it has the madwifi license/copyright now, good; WDYM with "more traditional"?
<pitti> persia: the ltmodem copyright isn't entirely clear, but then again our main l-r-m isn't either
<pitti> so, good enough for me
<persia> pitti, I can't find any license reading the source for ltmodem.  In good news, AnAnt is finalising a dkmx+modass compatible multiverse package to let us drop that for jaunty.
<persia> Thanks.  I'll upload.  For reference "more traditional" would be something following http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
<pitti> persia: ah, ok; let's not be too fussy about it
<persia> uploaded.
<pitti> mvo: does the screensaver now actually work for you? I just get a black screen
<mvo> pitti: it did in my tests, let me double check
<mvo> pitti: what screensaver is checked in your screensaver preferences?
<mvo> pitti: what card/driver?
<pitti> mvo: "Weltraum"
<pitti> mvo: 945GM/intel
<pitti> mvo: in the screensaver prefs, the preview works fine, but ctrl+alt+l or gnome-screensaver-command -a just give me a black screen
<pitti> mvo: it doesn't immediately return any more, so the "does not activate" part is indeed fixed
<mvo> pitti: I just tested on my nvidia system and it seems to be ok. but I'm upgrading my intel system as we speak
<StevenK> pitti: Sure, closing
<mvo> pitti: hm, seems to work for my intel system, strange
<mvo> pitti: I keep a open eye on the bugreports
<pitti> mvo: ok, thanks for testing
<mvo> pitti: could you please run "gnome-screensaver --debug --no-daemon" and sent me the output ? that might give me a clue
<mvo> (you probably have to kill the running one fist)
<pitti> mvo: http://paste.ubuntu.com/60453/ is after killing, starting in debugging, and gnome-screensaver-command -a
<pitti> mvo: oh, maybe it's because my original CK session was ruined (I did some CK debugging and killed it several times)
<pitti> mvo: I'll try it again with a good session in a bit
<mvo> pitti: thanks! the line "[gs_job_start] gs-job.c:446 (12:35:58):	 No command set for job." looks a bit supicious
<mvo> pitti: that looks like for some reason g-s-s thinks that it does not need to start a screensaver (or can not?)
<alex-weej> where has the bluetooth services control gone?
<alex-weej> the new bluetooth preferences from bluez 1.8 is missing the services tab
<alex-weej> and there's no discoverable way to enable file transfers now
<persia> alex-weej, Which flavour?
<alex-weej> 8.10
<persia> alex-weej, Flavour, not release.
<alex-weej> Ubuntu
<persia> e.g. Mythbuntu, Xubuntu
<alex-weej> Ubuntu Original, Organic, Full Fat
<Ng> alex-weej: I see that too
<persia> Oh.  RIght.  I suspect that's bug #283064.
<ubottu> Launchpad bug 283064 in gnome-bluetooth "intrepid: bluetooth can not receive files" [Undecided,New] https://launchpad.net/bugs/283064
<alex-weej> persia: but also things like i can't set up input devices or anything
<persia> alex-weej, That's surprising.  Try clicking the bluetooth applet : it should open the device wizard.
<alex-weej> i have already "set up" the weejPhone
<alex-weej> so it doesn't show up in the list
<alex-weej> setting it up again just says it was successfulyl set up
<alex-weej> no way to configure anything
<alex-weej> as an input device, audio device, network device
<persia> What are you trying to configure?
<alex-weej> anything. like an input device.
<persia> Ah, it is supposed to auto-detect that from the capabilities available.  If your device supports multiple capabilities, and it doesn't work, file a bug.
<alex-weej> hm, i can start the remote control on my device and use it fine
<alex-weej> it just seems weird that there is no way to configure any of this
<alex-weej> it's all-or-nothing
<persia> It's supposed to just work.
 * StevenK selectively empties
<StevenK> Err
 * StevenK selectively empties NBS
<NCommander> morning StevenK
 * StevenK waves
<pitti> mvo: still no screensaver love with a fresh session
<mvo> pitti: could you give me the gconftool-2 -dump /apps/gnome-screensaver/ please?
<mvo> pitti: does it work without compiz?
<Mirv> asac: hi. I attached a patch to bug #286421, could you see about it soon. it's the only visible menu i18n problem in default installation at the moment.
<ubottu> Launchpad bug 286421 in network-manager-applet "[8.10] nm-connection-editor menu item untranslatable" [Undecided,New] https://launchpad.net/bugs/286421
<Mirv> asac: the deadline for translations is on Thursday, so before that it should get uploaded, imported to Rosetta (hopefully fast now) and translated by people
<pitti> mvo: http://paste.ubuntu.com/60492/
<pitti> mvo: works in guest session with metacity
<asac> Mirv: hmm. i will see what i can do
<asac> have to do a few things. then will look
<Mirv> asac: ok.
<pitti> does anyone else have two "Screen saver" entries in system -> prefs? I just noticed that xscreensaver also has an entry there
<Mirv> (the patch fixes the problem for me, I build packages at PPA)
<StevenK> pitti: There's a bug about it
<persia> pitti, I have two.
<StevenK> Which was dealt with by slangasek
<pitti> StevenK: seed change?
<StevenK> pitti: 5.07-0ubuntu2 upload of xscreensaver.
<pitti> hm, which I have
<Riddell> evand, cjwatson: looks like ubiquity still doesn't work on the post-wubi install stage, it just shows a blank block
<pitti> StevenK: ah, that won't work for updates
 * pitti purges xscreensaver
<cjwatson> Riddell: sounds like bug 285626, which we have been unable to reproduce directly?
<ubottu> Launchpad bug 285626 in ubiquity "blank window on livecd with "Install" boot option" [Undecided,New] https://launchpad.net/bugs/285626
<cjwatson> Riddell: do you have a kwin crash in /var/log/installer/dm?
<cjwatson> or indeed /var/crash
<StevenK> pitti: Is there something to be done for updates?
<Riddell> cjwatson: mm, yes
<pitti> StevenK: I don't think we can; conflicting to it would be wrong
<wgrant> pitti: I advise caution when responding to that guy on launchpad-users. He's the one who writes bug reports with 2000 word paragraphs while drunk, and insists that people keep breaking into his computer before he finishes the installation.
<tjaalton> pitti: albert damen found out why evdev stole the joysticks on 64bit systems: https://bugs.freedesktop.org/show_bug.cgi?id=18150
<wgrant> pitti: He's also grand master of filing bugs which mention at least 12 different things that might be bugs, but are too vague and separate for it to be clear.
<ubottu> Freedesktop bug 18150 in Input/evdev "evdev detects non-existing button as mouse button" [Normal,New]
<pitti> wgrant: I had my reply halfway typed before I realized that it was utter <censored>, so then I just finished it quickly
<pitti> wgrant: thanks for the warning
<pitti> tjaalton: ooh
<tjaalton> pitti: so applying it to the driver should fix joysticks (but not x-x-i-j though, but it's not that important IMHO)
<tjaalton> I didn't realize it was an amd64-only problem..
<pitti> tjaalton: hah! nice catch
<pitti> so it rotated 1 << something into oblivion before casting it to 64 bit
<wgrant> pitti: He might also send some OpenDocument presentations to you soon, most of which reference screenshots in /tmp, and apparently prove the problems which he has so far failed to describe.
<persia> pitti, Nice find.  THanks.
<tjaalton> pitti: ok to milestone this?
<wgrant> And he keeps accusing eBay people of tampering with his RAM.
<pitti> tjaalton: please do; feel free to upload, so that it's ready in the queue right after RC
<tjaalton> pitti: yep
<stefanlsd> wgrant: do you still have the bzr mplayer hardy source?
<persia> stefanlsd, Isn't it still in bzr history on LP?
<cjwatson> seb128: can you remind me how I run the retracer on a .crash file by hand?
<cjwatson> the maze of twisty scripts on ronne is confusing me
<stefanlsd> persia: somehow the hardy branch got messed up and couldnt be synced, and consequently was deleted.  so wanted someone with it to repush it
<seb128> cjwatson: there is no easy way I think, usually that's 'log into the retracer, copy the cookie, use apport-retrace there'
<persia> stefanlsd, Ah.  I see.  Never mind.
<cjwatson> I've already downloaded the .crash file and copied it onto ronne; do I have to have it talk to LP?
<cjwatson> alternatively I suppose I could arrange for the retracer to attack the bug
<seb128> cjwatson: do you try to get a stacktrace or do you try to get it retraced the standard way?
<persia> cjwatson, If you have a local .crash file, just call apport-retrace foo.crash with the right dbgsym packages installed.
<seb128> cjwatson: ie do you debug why a retracing is not working or do you just want a stacktrace?
<cjwatson> well, the latter is fine but the former is what I actually want :)
<cjwatson> persia: I don't really feel like installing all of KDE in order to get a stacktrace
<cjwatson> it's from somebody else's system, not mine
<persia> cjwatson, "local" to ronne, I was guessing.
<seb128> cjwatson: log into the corresponding retracer and use apport-retrace there
<cjwatson> the tools seem to be out of date - they run dchroot -c gutsy ... /hardy.tar.gz
<seb128> cjwatson: ie, apport-chroot login chroots/intrepid.tar.gz
<seb128> apt-get install wget
<seb128> wget your .crash
<seb128> apport-retrace .crash
<cjwatson> apport-chroot isn't installed in the base
<seb128> just screen -r
<seb128> and attach whatever retracer you need
<cjwatson> nor in the intrepid chroot
<seb128> you can ctrl-C a running instance
<cjwatson> err, screen -r what?
<seb128> screen -r on ronne
<seb128> it'll list the retracers availables
<cjwatson> There is no screen to be resumed.
<seb128> ssh ubuntu-archive@ronne.ubuntu.com?
<NCommander> Its offical
<cjwatson> oh, ubuntu-archive
<NCommander> My flight is booked for UDS Jaunty
 * ogra curses the new panel sliders ... why did they decide that using cursor keys for brightness and volume shouldnt work anymore
<amitk> pitti: we have a problem where ath5k works on some machines (eeepc) and madwifi on others (samsung q1) with same pci id. Can jockey handle a case of platform specific quirks on what module to blacklist based on platform being loaded on?
<tseliot> amitk: is there a way to tell one arch from the other?
<tseliot> (for jockey)
<tseliot> amitk: e.g. telling lpia from 386
<persia> tseliot, Except that it's not arch-specific.  The same problem happens on different i386 installs with different devices with the same pci id.
<tseliot> persia: ok, is there a way to tell one device from the other then? (e.g. with lspci)
<persia> tseliot, Well, I suppose one could look for textual clues in the strings, but with an identical pci id, I wouldn't be surprised if those matched mostly.
 * persia doesn't have an affected device, but has seen lots of discussion
<amitk> tseliot: dmidecode info perhaps
<tseliot> persia, amitk: ok, maybe dmidecode could do it (it has to be run as root though). Any links to bug reports related to this problem?
<persia> ogra, Did you file a bug about this already?
<ogra> persia, ?
 * ogra reads backlog
<persia> Q1 wireless
<ogra> persia, yes
<tseliot> ogra: link?
<ogra> persia, bug 284354
<ubottu> Launchpad bug 284354 in linux-lpia "AR2424 on Samsung Q1 loads both ath_pci and ath5k modules" [High,Triaged] https://launchpad.net/bugs/284354
<heno> *** RC candidate images are up - http://iso.qa.ubuntu.com - please help test. coordination in #ubuntu-testing ***
<amitk> tseliot: bug #182489 for the eee pc
<ubottu> Launchpad bug 182489 in linux-restricted-modules-2.6.24 "Atheros wireless (AR5007) not working on various laptops, including the ASUS Eee PC" [High,In progress] https://launchpad.net/bugs/182489
<ogra> hmm
 * tseliot has a look at the bug reports
 * ogra would know which driver is used now ... 
 * ogra blacklists ath_pci 
 * amitk ships ogra with every ubuntu-mobile download
<ogra> err ...
<ogra> s/would know/would like to know/
<ogra> :)
<ogra> ... rebooting
<ogra> amitk, ok, usual prob, with ath_pci blacklisted NM doesnt see any network, iwlist doesnt see any network ... creating one manually pointing to my essid just ends in NM not being able to connect
<ogra> lsmod shows: ath5k, mac80211m led_class and cfg80211 being loaded atm
<ogra> *mac80211
<ogra> i have a wlan0 interface though
<ogra> switching that now and will then install lbm
<amitk> ogra: ack. let me know if lbm improves things.
<kirkland> pitti: you around?
<ogra> amitk, what would be the sideeffect of lbm being in the image in case that works ? any negatives you could imagine ?
<amitk> ogra: it isn't 'supported'
<ogra> amitk, well, -mobile and -mid are built from universe :)
<amitk> ogra: also, sometimes it can contain updates for other modules that might not be desired for a particular device
<tseliot> ogra: do lshal and lshw show anything about the network device(s)?
<ogra> hmm
<ogra> tseliot, the ids that are in the bug
<zul> pitti: I uploaded bacula which drops mt-st to a suggests since Im pretty sure no one has a tape drive on the server team however I should be getting one eventually
<ogra> amitk, hmm, apt doesnt seem to know linux backport modules
<amitk> interesting... atleast it is found on the q1
<cjwatson> Riddell: I don't suppose you could get me the kwin crash file?
<cjwatson> Riddell: the one in the bug is with a slightly older version and I don't seem to be able to retrace it
<ogra> amitk, not for me
<amitk>  ogra: apt-cache search linux-backports-modules
<amitk> WFM
<Riddell> cjwatson: ok, give me a minute or four
<cjwatson> ta
<Riddell> cjwatson: but do you think the kwin crash is the cause?  kwin recovers and the window manager crashing shouldn't affect the applications
<ogra> amitk, ah, udate helped :)
<ogra> *update
<pitti> kirkland: back from lunch, hey!
<kirkland> pitti: heya, so i was posting about the ecryptfs/gdm issue
<kirkland> pitti: as far as the installer goes, ecryptfs-setup-private is only in the server installer (as far as i understand)
<pitti> kirkland: and in the alternate one
<kirkland> pitti: right, i mean "not the graphical ones"
<kirkland> pitti: and i couldn't find a particular package to "conflict" with...
<pitti> kirkland: right, ubiquity only offers autologin, not ecryptfs setup
<pitti> kirkland: no, it shouldn't conflict package-wise, but option-wise
<pitti> kirkland: I thought d-i would offer autologin
<ogra> ok, lbm installed, blacklisting ath_pci again
<kirkland> pitti: hmm, not that i've ever seen
<cjwatson> Riddell: I'm not sure, it's just the obvious difference between non-working and working ...
<pitti> kirkland: hm, so this issue seems to be pretty moot then
<cjwatson> d-i doesn't offer autologin right now
<kirkland> pitti: i agree... i was "passing the buck" to you :-)
<ogra> amitk, success !
<kirkland> pitti: i can add a one-liner to the command line dialog
<kirkland> pitti: that says that it won't work with auto-logins
<pitti> kirkland: well, it's still an issue when you manually set up ecryptfs with an autologin system
<kirkland> pitti: but that seems pretty friggin obvious to me
<amitk> ogra: \o/
<pitti> kirkland: but I really don't think we can solve this principal difference
<kirkland> pitti: i'm hoping to have a python-gtk gui for Jaunty
<pitti> s/difference/conflict/
<ogra> amitk, loaded are: ath5k, lbm_cw_mac80211, lbm_cw_cfg80211 and led_class
<kirkland> pitti: there's some community contributed code to that effect
<pitti> kirkland: actually
<pitti> kirkland: is there anything in ~/Private if it's not mounted?
<kirkland> pitti: a symlink
<pitti> kirkland: it would be nice to have  README.txt there which says "If you can see this, run this command" kind of explanation
<pitti> kirkland: and that file could also point out things like automount
<amitk> ogra: sounds like lbm should be installed by default in the -mobile image
<kirkland> pitti: actually, that's pretty much what's there
<kirkland> pitti: ln -s /sbin/mount.ecryptfs_private "$MOUNTPOINT"/"THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again"
<Keybuk> kwwii: when I select the Darkroom (he he) theme, the panel doesn't change background colour?
<ogra> amitk, i'm a bit scared about the modules you mentioned that might come in additionally
<pitti> kirkland: hm, so how about adding the autologin explanation there?
<kirkland> pitti: i think you're right...  replace that symlink with a small readme of FAQ
<amitk> ogra: it is usually for new hw enablement. We used it to provide alsa backports for Hardy. No plans to do that for intrepid yet.
<pitti> kirkland: oh, the symlink idea is nice as well, though
<kirkland> pitti: right now, it's just an "informatively named" symlink to the binary that will try to mount your data again
<ogra> amitk, *yet* :)
<kirkland> pitti: it doesn't work in the autologin case, though
<pitti> kirkland: hm, that provides clickable mounting which is nice indeed
<ogra> thats the scary part :)
<kirkland> pitti: that's the idea ;-)
<amitk> ogra: i know. lbm will never have guarantees. But lets see if this motivates rtg to backport all this into the kernel by default
<kirkland> pitti: because your login passphrase never made it into your keyring, the clicky after autologin doesn't work
<pitti> kirkland: ah, it uses gnome-keyring?
<kirkland> pitti: no
<ogra> amitk, is there a kernel update planned before release ?
<kirkland> pitti: the kernel keyring
<pitti> oh, that keyring, sure
 * ogra wouldnt have thought so
<Riddell> cjwatson: http://muse.19inch.net/~jr/tmp/_usr_bin_kwin.999.crash
<amitk> ogra: yes
<cjwatson> thanks
<kirkland> pitti: the pam_ecryptfs module takes your login passphrase, decrypts ~/.ecryptfs/wrapped-passphrase, and adds the decrypted key to your kernel keyring, which is used to mount
 * ogra prepares boxes of german beer to send to rtg to bribe 
<ogra> or even to BenC1 :)
<BenC1> ??
<ogra>  ogra prepares boxes of german beer to send to rtg to bribe
<ogra> :)
<kirkland> BenC1: something about sending free beer your way ... nothing important ;-)
<BenC1> ogra: I'm not sure what you're asking for, but for boxes of german beer, I'll do just about anything
<pitti> kirkland: so the GTKish solution would then detect that and ask you for your password?
<ogra> BenC1, apparetnly the lbm ath5k solves all our probs in mobile and amitk told me there is another kernel upload planned before release :)
<BenC1> There is?
<kirkland> pitti: well, my 2 cents are "Hell no!  There's no good reason why you'd want to have encrypted data, that automatically gets decrypted if you login"
<ogra> so i was hoping german beer could get it in :)
<kirkland> pitti: sorry, "if you auto login without a password"
 * BenC1 is surprised to hear another kernel upload is planned for RC
<pitti> kirkland: hm, maybe you misunderstood me
<ogra> BenC1, RC != release
<ogra> i just want it fixed in final
<kirkland> pitti: oh, my bad...
<ogra> and adding lbm to the seed smells a bit risky
<BenC1> ogra: I would suspect that it would be post release then :)
<ogra> though that would be my fallback for mobile
<ogra> oh
<ogra> well, that leaves me with lbm then
<kirkland> pitti: basically, someone filed a bug and submitted some decent, beta code that would act as a python-gtk front end for ecryptfs-setup-private
<kwwii> Keybuk: nope, setting a panel bg just causes a bug in the about panel and stuff so although we include a bg I did not set it in the theme itself
<pitti> kirkland: if clicking on that magic symlink would pop up a dialog which explains what's going on and asks me for my password, and then mounts ~/Private, why whould that be bad?
<kirkland> pitti: ooooooh.....
<pitti> kirkland: leaving aside security aspects of how to design the dialog, and how to implement it in general
<kirkland> pitti: sure, that sounds find
<kirkland> fine, even
<pitti> kirkland: just how it would loook to the user
<kirkland> pitti: the user could do it, by running ecryptfs-insert-wrapped-passphrase-into-keyring, and then mount.ecryptfs_private
<kirkland> pitti: but those are both CLI's, no GUI (yet)
<pitti> kirkland: wrap it into gnome-terminal -e :-P
<pitti> TEH ULTIMATE GUI
<kirkland> pitti: cool....  how well does that work for KDE?
<kirkland> :-P
<pitti> kirkland: x-terminal-emulator
<ScottK> kirkland: Thanks for thinking of us.
<Keybuk> kwwii: that's a shame
<Keybuk> it makes setting the theme kinda ugly
<kirkland> ScottK: :-)
<lool> pgraner: Around?
<lool> pgraner: When is the first intrepid-updates kernel?
<lool> pgraner: We're basically stuck for the ath5k/madwifi situation with some hardware, and lbm isn't an option
<pgraner> lool: talk to amitk he is working on that issue
<amitk> pgraner: but you know about updates schedule :)
<lool> pgraner: nice try
<lool> pgraner: 16:07 < amitk> lool: dunno. ask pete
<lool> stack overflow people
<kirkland> pitti: is there something simple that i can use to prompt for a password?
<kirkland> pitti: graphically?
<pitti> kirkland: you can probably abuse gksu, or at least libgksu
<pgraner> amitk: I thought you were going to get that fixed up for release, no? I haven't looked at updates yet...
<kirkland> pitti: i thought about gksu, but i'd need it to feed me the password
<tseliot> kirkland: what about zenity?
<kirkland> pitti: oh, wait
<kirkland> --print-pass,
<pitti> kirkland: gksu --print-pass
<kirkland> tseliot: is zenity better across gnome/kde/xfce?
<amitk> pgraner: it works with lbm. I am currently diffing the in-kernel ath5k code with lbm ath5k to see how big
<lool> pgraner: I understand we don't have any new kernel upload anymore
<tseliot> kirkland: no, I guess not. There's a kde equivalent too
<amitk> lool: we DO have a kernel upload, maybe not before RC
<lool> amitk: Ok; good news then
<pitti> kirkland: gksu -p -m "Foobarize your system" works quite well indeed
<kirkland> tseliot: pitti: okay, i'm straying much further away from the server, and from intrepid responsibilities, i fear ;-)
<ogra> pgraner, the question is simply will we have another kernel upload before final
<pitti> kirkland: heh, yes; let's keep all this for jaunty
<ogra> pgraner, where the fixed ath5k could be included
<kirkland> pitti: i'll revisit then
<pitti> kirkland: sounds like these desktop guys should handle that
<pitti> oh, wait...
<kirkland> pitti: :-)
<pgraner> ogra, lool, amitk: I'll know more later today
<lool> amitk: The solution of pushing an ath5k update in the RC is good for me; otherwise, I recommend disabling ath5k for everybody until it works for everybody; I'm not sure the claims that it worked for some eeepc users in some network configs are enough to have preference for athh5k and break wifi for others
<mvo> Riddell: what can/should we do about virtualbox-ose and kde upgrades? my suggestion would be to have "virtualbox-ose-legacy" that can read the old snapshots and make the default of the debconf question to not fail
<lool> s/in the RC/after RC
<lool> Otherwise, I can also imaging including a fixed ath5k in the first intrepid-updates kernel if taht's early enough
<lool> *imagine damn
<amitk> lool: NAK. madwifi _doesn't_ work for some people, but ath5k works. So disabling it is not an option.
<ogra> lool, hard to upgrade on mobile devices that *only* have wlan though
<lool> amitk: I'm only suggesting to disable it for some PCI ids
<ogra> amitk, mdwifi only doesnt work if *both* modues are loaded
<lool> Did you get reports that madwifi wouldn't work on these PCI ids?
<lool> I know madwifi regressed in terms of hardware support, but I have yet to read that it affected the Q1U's PCI ids or, the eepc's
<amitk> lool: bug 182489
<lool> *eeepc
<ubottu> Launchpad bug 182489 in linux-restricted-modules-2.6.24 "Atheros wireless (AR5007) not working on various laptops, including the ASUS Eee PC" [High,In progress] https://launchpad.net/bugs/182489
<ogra> the real prob is that one doesnt replace the other apparently and you need to manually have to maintain a blacklist file
<ogra> but if we have the fix and another kernel upload will happen it should definately go in
<lool> amitk: not the same pci ids
<lool> amitk: Anyway, let's first exhaust the option of updating ath5k post RC which might make everybody happy and is probably one of the options requiring the least amount of work
<pitti> tjaalton: oh, is bug 271138 really that easy?
<ubottu> Launchpad bug 271138 in xorg "mouse and keyboard unresponsive when gdm first runs" [High,Confirmed] https://launchpad.net/bugs/271138
<amitk> lool: ack, looking at the ath5k diff now
<lool> Thanks :-)
<tjaalton> pitti: for some it is
<tjaalton> pitti: but the other bug is just weird
<pitti> tjaalton: libhal_ctx_init() failure is weird anyway and a bug by itself, but I hope it's just a followup effect of having all these bogus input.keymap properties
<tjaalton> pitti: right, it's a likely candidate
<pitti> liw: the RC images still have systme cleaner in apps -> system tools; are you aware of that? would be really good to fix that for the final
<rtg> why is the spell checker in Thunderbird lobotomized? It redlines all kinds of stuff that is obviously correct. Is it because the language selected is en_ZA?
<liw> pitti, I know, I'm working on an update
<kwwii> TheMuso: which package is the ubuntu-studio gtk theme in?
<kwwii> erm, skip that I found it
<Riddell> mvo: will that work?  it sounds like hassle
<Riddell> kirkland: kde has kdialog
<kirkland> Riddell: cool, thanks :-)
<Riddell> pitti: jockey-kde doesn't seem to do very much for this broadcom wifi
<pitti> Riddell: it doesn't show any drivers, or enabling them doesn't work?
<Riddell> pitti: it shows a driver but clicking Activate just results in it being greyed out and nothing else apparantly happening
<tedg1> Okay, I'm taking the bait.  rtg: Why are you en_ZA?
<pitti> hey tedg1
<pitti> Riddell: hm, can you please start it from a terminal? does it throw an exception?
<tedg1> Good morning pitti
<rtg> tedg1: dunno, but I switched it to en_GB as soon as I noticed. This was a clean install, and I chose Boise as my timezone.
<Riddell> pitti: no nothing on stdout
<Riddell> (or stderr)
<tedg1> rtg: Exactly, because en_GB make so much more sense for Boise.  :)
<pitti> Riddell: ok; does it show b43 or wl?
<pitti> Riddell: and do you get a progress bar at all?
<rtg> tedg1: well, its not like there are a wealth of choices.
<rtg> though, there is an option to download more dictionaries.
<Riddell> pitti: it says "Broadcom STA wireless driver"
<Riddell> pitti: no progress bar
<davmor2> Riddell: there is no progress bar it should just work after a reboot.  Did for me anyway.
<mvo> Riddell: it is hassle :/
<rtg> slangasek: disabling FTRACE is gonna cause an ABI bump. Are you OK with that?
<davmor2> Riddell: is this on kubuntu?
<liw> interesting. I have a possibly broken usb memory stick that when inserted kills compiz, gnome panel, and possibly more
<liw> or else my desktop machine is acting weirdly for other reasons
<Riddell> davmor2: yes
<Riddell> mvo: I'd be tempted just to release note it if it's trouble
<davmor2> give me a few minutes I'll see if I can reproduce it on my laptop
<tseliot> Riddell: does jockey-gtk work for you?
<Riddell> tseliot: that was my next idea
<tseliot> Riddell: if it does, then I'll see if I can find the problem in the kde ui and possibly fix it
<liw> perfectly repeatable: insert key, system goes haywire. oh well, I'll debug that later
<Riddell> tseliot: jockey-gtk works fine
<tseliot> Riddell: ok, I'll have a look at the code and see what I can do
<Riddell> tseliot: good luck
<tseliot> Riddell: does Jockey work for you with other drivers (if you use other proprietary drivers)?
<davmor2> Riddell: try it once close jockey then open jockey and try it again
<Riddell> tseliot: I don't use other proprietry drivers
<Riddell> davmor2: doesn't help
<tseliot> ok
<davmor2> worked on live like that for me.
<davmor2> tseliot: I'm installing it I got nvidia gfx and broadcom wifi
<tseliot> davmor2: and sometimes you don't get any progress dialog, right?
<davmor2> tseliot: not with the wifi I think is installed to quickly and I don't think it downloads the driver I always do with nvidia
<tseliot> davmor2: aah, maybe the driver is already available in the linux-restricted-modules
<davmor2> tseliot: it's the broadcom sta (dell/canonical) driver iirc
<pitti> ogra, cjwatson: as for bug 276317, should there even be something like "edubuntu netboot"? I thuoght edubuntu was just an addon CD nowadays?
<ubottu> Launchpad bug 276317 in edubuntu-meta "Intrepid: Netboot.  Edubuntu meta doesn't include things like OO.o or FF" [Undecided,New] https://launchpad.net/bugs/276317
<tseliot> davmor2: ok, this should help me track down the problem.
<cjwatson> I've commented on the bug
<cjwatson> there's no intrinsic reason not to test it using netboot but it's not all that valuable
<pitti> tseliot: ah, I just discussed it with Riddell in /query; seems we should be able to reproduce this wiht a fake modalias, since it seems to be a problem of -kde, not with particular hardware
<ogra> pitti, i havent touched edubuntu since hardy, but edubuntu-desktop clearly depends on ubuntu-desktop so it should be installed
<cjwatson> edubuntu-desktop does not in fact Depends: ubuntu-desktop
<cjwatson> although you should certainly install it
<ogra> Depends: ubuntu-desktop, atomix, edubuntu-artwork, edubuntu-artwork-usplash, gcompris, gcompris-data, gnome-icon-theme-gartoon, gpaint, kalgebra, kalzium, kanagram, kbruch, khangman, khelpcenter4, kig, kmplot, kpercentage, kstars, ktouch, ktuberling, kturtle, kwordquiz, libpcre3, marble, parley, step, tuxmath, tuxpaint, tuxpaint-data, tuxpaint-stamps-default, tuxtype, xaos
<cjwatson> oh, sorry, yes
<ogra> thats what i get from apt-cache show edubuntu-desktop
<cjwatson> I assumed it was in alphabetical order and only looked at the end ;-)
<ogra> ah :)
<tseliot> pitti: yes, I was thinking of adding some new test to the test suite
<cjwatson> I suppose it's possible that Recommends aren't getting pulled in
<ogra> mvo, why was the "compiz doesnt blank screen" bug closed ? i still see it on all devices
<pitti> tseliot: once we figure out where the problem is, that would be great, yes
<davmor2> pitti: tseliot: I just tried on live cd I got it to go green but if memory serves you need a full reboot for it to activate completely
<pitti> davmor2: for wl? yes
<pitti> davmor2: alternatively, some rmmoding of all b43 and ssb stuff, and modprobing wl
<davmor2> pitti: well broadcom sta :)
<pitti> davmor2: yes, that's the "wl" kernel module
<ogra> mvo, fully upgraded
<cjwatson> davmor2: where's the edubuntu netboot test procedure?
<ogra> but it doesnt show up on https://bugs.launchpad.net/ubuntu/intrepid/+bugs so i assume its been closed ?
<davmor2> works fine on Ubuntu just waiting for the kubuntu install to finish so I can try it there shouldn't be long
<davmor2> cjwatson: http://iso.qa.ubuntu.com/qatracker/result/2054/170 is the tracker details
<cjwatson> heno: I think we should take edubuntu netboot off the tracker. Do you agree?
<ogra> ++
<cjwatson> davmor2: doesn't exactly go into much detail on "select a distro flavour to install" - that isn't a canned selection in the installer
<davmor2> cjwatson: https://wiki.ubuntu.com/Testing/Cases/NetbootInstall is the test case
<heno> cjwatson: agree
<ogra> tough it would be intresting to know why the dependency isnt properly fulfilled
<heno> ogra: should d-i install recommends?
<ogra> heno, afaik
<cjwatson> davmor2: how did you select it?
<heno> it's only the recommended packages of ubuntu-desktop dropping out
<cjwatson> yes, d-i should install recommends
<cjwatson> the edubuntu-desktop-addon task doesn't include the edubuntu-desktop metapackage
<cjwatson> that might be relevant
<davmor2> cjwatson: standard install until it gets to selection and it is in the list along with edubuntu-kde desktop
<cjwatson> davmor2: you need to select Ubuntu desktop too
<calc> when is iso.qa going to get openid?
<cjwatson> davmor2: this is sort of a bug and it ought to work without that, but it isn't worth spending time testing it
<davmor2> cjwatson: but it pulls in the majority of gnome correctly it's only certain packages that are missing
<cjwatson> davmor2: yes, I know.
<cjwatson> davmor2: really isn't worth our time working on it at this point
<davmor2> :)
<davmor2> I just test it ;)
<cjwatson> heno and I agree that you should stop :)
 * heno nods
<cjwatson> it's an interesting bug and there's clearly something wrong in the internals, but the actual use case isn't one we care deeply about
<cjwatson> ah, the bug is that tasksel invokes apt-get with --no-install-recommends
<cjwatson> it almost always doesn't matter because the tasks are generated with recommends included
<davmor2> np's
<cjwatson> but it happens to matter in this case
<Caesar> pitti: I don't think #214041 has been fixed in hardy-updates, as the worklog on the bug suggests
<Caesar> Could you take a look please?
<cjwatson> davmor2: ok, committed a fix for post-intrepid just for the hell of it
<davmor2> :)
<cjwatson> thanks
<davmor2> tseliot: right kubuntu installed now
<tseliot> good
<ogra> mvo, bug 278112 is clearly not fixed for me anywhere
<ubottu> Launchpad bug 278112 in xorg-server "Screensaver doesn't start" [Medium,Fix released] https://launchpad.net/bugs/278112
<ogra> mvo, and amitk just reorted the same
<ogra> *reported
<cjwatson> Riddell: http://muse.19inch.net/~jr/tmp/_usr_bin_kwin.999.crash is 403
<cjwatson> Riddell: could I have it back? :)
<jdong> mvo, ogra: Confirm here too. The screen starts nodding off to blankness and comes right back. kinda like me during class, but that's a different concern :)
<ogra> jdong, lol
<ogra> jdong, please comment that on the bug so mvo is aware
<ogra> (not about your shool habits but about the non fixage :) )
<davmor2> tseliot: I think it might be the trigger for policykit
<tseliot> davmor2: why do you think so?
<davmor2> i'll paste the output it's been called but I get not window
<tseliot> ok
<hwilde> is there any way to really debug why livecd dumps to busybox initramfs ?
<\sh> pitti: do you have a moment?
<\sh> zul: ping you were the last one who touched mysql-server in hardy...for updates
<\sh> zul: I think I found a serious regression
<zul> \sh: ??/
<davmor2> tseliot: http://paste.ubuntu.com/60569/
<\sh> zul: check this out :)
<\sh> zul: http://paste.ubuntu.com/60570/
<\sh> zul: paste number one of mysql-server 5.0.51a-3ubuntu5 (before applying 5.0.51a-3ubuntu5.1)
<davmor2> tseliot: I'll double check it with nvidia
<tseliot> davmor2: ok, thanks
<pitti> mvooooooooooo
<pitti> mvo: http://people.ubuntu.com/~pitti/tmp/upgrade-note-description.png :(
<\sh> zul: http://paste.ubuntu.com/60571/
<pitti> \sh: just ask, please, busy with dozens of things ATM
<cjwatson> meeeeep
<cjwatson> I wonder if that was my fault
<davmor2> tseliot: same thing
<\sh> zul: paste number two with mysql-server 5.0.51a-3ubuntu5.1 applied...same database structure, different data inside, but you get the point
<Keybuk> cjwatson: it's all your fault
<cjwatson> Keybuk: thpppppppppt
<\sh> pitti: I'll  work with zul on it, because he touched it last , thx anyways :)
<Keybuk> oh, wait, you're not a manager now :p
<hwilde> plz I am stuck in busybox initramfs :/
<pitti> Caesar: it was supposed to, but of course you could experience a different bug
<pitti> \sh: okay, danke
<\sh> zul: the result is totally different...first paste is correct, second not, but second is in -updates ,-)
<tseliot> davmor2: can you install policykit-gnome and try again?
<davmor2> np's
<tseliot> davmor2: ?
<davmor2> no probs
<tseliot> ah, the apostrophe confused me a bit
<cjwatson> pitti: I'm sort of inclined to blame intltool ...
<pitti> mvo: filed as bug 287046, for tracking
<ubottu> Launchpad bug 287046 in update-notifier "interactive upgrade hooks description shows all translations" [Undecided,New] https://launchpad.net/bugs/287046
<Caesar> pitti: I mean in terms of package versions
<Caesar> Did the right version actually get in?
<davmor2> tseliot: that worked but it looks ugly as hell :)
<tseliot> pitti: ^^
<pitti> Caesar: yes, but ages ago
<Caesar> pitti: hmm
<pitti> davmor2, Riddell: argh, it seems that the kde .desktop file doesn't actually start it as root
<pitti> davmor2, Riddell: (no policykit in KDE); can you try to start it as root?
<davmor2> pitti: policykit is installed I just installed policykit-gnome
<pitti> I mean a PK auth agent
<davmor2> pitti: I'll try it now
<davmor2> looks like it might work pitti need to reboot first 2 ticks
<Caesar> pitti: don't mind me, I can't read diffs properly
<pitti> Caesar: ah, *phew* :)
<Caesar> We've got another issue we'll try to get fixed upstream
<davmor2> pitti: Riddell: kdesudo jockey-kde seems to work fine
<Riddell> I was using sudo
<davmor2> Riddell: I just installed the nvidia driver with no issues :(
<tseliot> Riddell: does it work if you install policykit-gnome and launch jockey-kde without sudo?
<Riddell> davmor2: that's a happy face sentence :)
<Riddell> tseliot: dunno that computer is in the middle of an upgrade test just now
<Riddell> will need to wait ten minutes
<cjwatson> looks like single-line translated strings in intltool-merge are just screwed
<davmor2> Riddell: it was meant to be a confused face but I hit the wrong button :)
<tseliot> Riddell: ok, let me know
<cjwatson> intltool-debian handles that file slightly better but not by a whole lot (it at least manages to translate Description but still screws up Name)
<davmor2> tseliot: did for me :)
<tseliot> davmor2: thanks to you we have found a bug. Maybe Riddell is affected by a different bug? We'll see
<Riddell> what bug did davmor2 find?
<cjwatson> this is all rather confusing because po-debconf gets it riight
<cjwatson> right
<davmor2> tseliot: Riddell found it I was just confirming it :)
<ogra> pitti, was cups in hardy recently updated ? i have ltsp users complaining it broke jetdirect printing
<mathiaz> james_w: I think it's a matter of policies
<mathiaz> james_w: we have a bunch of other programs that listen on localhost by default
 * RainCT wonders if anyone here happens to know how .desktop and similar files are translated
<mvo> ogra: could you please attach the log from "gnome-screensaver --debug --no-daemon" ? and attach the version of xserver-xorg-core? and ensure that the xserver got restarted?
<seb128> RainCT: usually they have a .in which has _Name= and _Comment=
<james_w> mathiaz: sure, I understand and probably agree with the policy, just given the reporter I just wanted to make sure it was given some attention.
<seb128> RainCT: intltool understand those correctly
<mvo> jdong: could you please do the same please as the stuff that I just asked ogra about? (two lines above)?
<mathiaz> james_w: right - I think I'll post a quick answer to state that we've heard their concerns
<ogra> mvo, yes, i can, but as i i said before it behaves the same if i purge gss
<mvo> ogra: hm, that sounds like its a different issue then
<mathiaz> james_w: and given the current position in the release cycle, we won't look into the issue within the next two weeks
<RainCT> seb128: Do you happen to have some example of how to get the strings from there into the POT and how to generate the final files (not involving Makefiles :))?
<ogra> mvo, it works if i xset -dpms or disable gpm
<mvo> ogra: and without compiz its all good?
<ogra> or disable compiz, right
<mvo> ogra: or the same with/without compiz?
<mvo> hmmmm
<seb128> RainCT: list the source in the potfiles and run intltool-update
<ogra> mvo, it goes away if i uncheck the gconf option mentioned in the bug though
<mvo> ogra: the unredirect fullscreen wndow?
<mvo> ogra: what video card/driver?
<pitti> ogra: see https://edge.launchpad.net/ubuntu/+source/cupsys; there was a security update
<ogra> mvo, intel 945GM on my lappie ...
<mvo> jdong: is that a intel card for you too?
<ogra> mvo, same on the Q1
<mvo> ogra: thanks, I have a intel system here (i965) I can try wit hthat
<mvo> ogra: could you do a recursive gconf unset for g-p-m and see if that helps?
<ogra> nope, not yet
<ogra> pitti, hmm, nothing strikes me as jetdircet related
<pitti> ogra: no, it isn't; they are all pretty low-profile
<ogra> yeah
<kirkland> is there something i can use in ecryptfs-setup-private to validate a user's login password?  something that they can run as themself
<mvo> ogra: ok, thanks. I check it out after dinner
<jdstrand> kirkland: unix_chkpwd may do the trick
<kirkland> jdstrand: awesome, thanks
<pitti> lool: so, for elisa -bad, we'd need to drop the recommends on -ugly and libvisual-plugins; any alternatives to that?
<jdstrand> kirkland: you plan to call it from within ecryptfs-setup-private?
<kirkland> jdstrand: yes.
<kirkland> jdstrand: see bug #259631
<ubottu> Launchpad bug 259631 in ecryptfs-utils "Cannot open Private directory after a reboot" [Undecided,Incomplete] https://launchpad.net/bugs/259631
<jdstrand> kirkland: ok-- check gnome-screensaver for an example of how to use it
<kirkland> jdstrand: users are entering their login password (twice, mind you) incorrectly
<kirkland> jdstrand: and moaning about encrypted private not being mountable
<jdstrand> heh
<kirkland> jdstrand: grep -r unix_chkpwd on the gnome-screensaver source doesn't turn up any hits
<kirkland> jdstrand: nor does pam_unix
<jdstrand> kirkland: src/gs-auth-helper.c
 * calc wishes he had a faster connection
<calc> downloading isos takes a long time :\
<jdstrand> kirkland: ext_run()
<jdstrand> kirkland: the source has 'PASSWD_HELPER_PROGRAM' which ends up being unix_chkpwd for us
<kirkland> jdstrand: hmm
<jdstrand> kirkland: you'd likely want to do the same since you're an upstream
<kirkland> jdstrand: can i do something like this in shell?
<kirkland> jdstrand: sure
<kirkland> jdstrand: but ecryptfs-setup-private is shell code
<kirkland> jdstrand: running unix_chkpwd from the command line get's a slap on the wrist
<jdstrand> kirkland: oh yeah (I keep forgetting which is shell and which is C)
<jdstrand> kirkland: it has to be invoked correctly, and is careful not to put the password on the command line
<jdstrand> (which ends up in proc)
<kirkland> jdstrand: right
<jdstrand> kirkland: I messed with that from shell a while ago, and ended up writing a small C program for it
<cr3> is there some command line utility to manage /etc/gdm/gdm.conf
<ogra> cody-somerville, does /cdrom/dists/intrepid/universe exist on xubuntu CDs ?
<ogra> (or rather dists/intrepid/universe)
<cody-somerville> ogra, for live or alternat?
<ogra> cody-somerville, alternate, i'm trying to fix a ltsp build failure without breaking xubuntu :)
<ogra> since i need universe in xubuntu but dont have it on ubuntu CDs
<jdstrand> kirkland: one option for you is to write a small C wrapper for unix_chkpwd and accept input from stdin, then you could do 'echo pass | wrapper ...'. this is safe for us because 'echo' is a shell builtin for dash and bash
<kirkland> jdstrand: k
<kirkland> jdstrand: i'll have a look at that
<jdstrand> kirkland: beyond that, I don't have anything otoh
<kirkland> jdstrand: thanks, this helps
<NCommander> ScottK & StevenK ping
<superm1> pitti / slangasek, tjaalton mentioned that the nv chosen when it shouldn't be bug was going to be a post-rc fix.  is there anything that i'd be able to do in helping test the fix or verify it's not breaking that would allow it to go in at RC instead?
<cjwatson> mvo: are the language-selector changes I just committed OK, do you think?
<calc> can you do an inverted status search?
<calc> eg -TRIAGED to get all but triaged bugs?
<james_w> calc: advanced search has a checkbox for each status
<pitti> superm1: it's not a matter of testing, it's a matter of respinning CDs
<calc> oh ok so i just have to check each one except for what i want to leave out?
<superm1> pitti, ah, that's too bad then.
<calc> well inverting wouldn't really work well anyway because it would show closed bugs, heh
<pitti> cjwatson: do you know why c-m insists on guile-1.6? I don't see why autogen would pull it in, it b-deps on guile-1.8 only
<lool> pitti: As I was saying, we need to promote libvisual-plugins
<lool> Will file a MIR for it and review it
<lool> You already hinted we need to change it first
<pitti> lool: right, if it drops jack, all is well
<pitti> lool: is dropping the -ugly recommends ok?
<mvo> cjwatson: ooh, you attacked #287046 already? wonderful!
<kirkland> dendrobates: i have confirmed slangasek's grub fixes....  install to LVM works fine in today's server ISO
<mvo> l
<mvo> cjwatson: looks perfect, thanks a lot for looking into it!
<ScottK-palm> NCommander: pong
<cjwatson> pitti: autogen/ia64 only
<cjwatson> pitti: (dependency, not build-dep)
<pitti> cjwatson: ah, ok; so I'll just ignore it
<cjwatson> mvo: should I upload this, or is there likely to be more language-selector stuff to come?
<mvo> cjwatson: please upload it, I have nothing for language-selector pending right now
<pitti> cjwatson: do you have any idea why po-debconf should recommend: libmail-sendmail-perl ?
 * pitti just went through all the perl stuff in c-m and boiled it down to four anchors
<cjwatson> $ dpkg -L po-debconf | xargs grep Mail::Sendmail
<cjwatson> /usr/bin/podebconf-report-po:eval q{use Mail::Sendmail;};
<cjwatson> podebconf-report-po pulls in a few bits
<cjwatson> libmail-box-perl too
<pitti> oh, podebconf-report-po; I didn't really see a link between debconf i18n and mailing, that's id
<pitti> s/id/it
<cjwatson> I couldn't really decide what to do with those myself
<ogra> who can approve uploads for CD fixes ?
<ogra> (whom do i have to talk to for an ltsp-client-builder fix that breaks alternate ?)
<pitti> ogra: is it OMGbreakingeverything?
<ogra> pitti, it is "breaks ltsp builds completely"
<pitti> ogra: respinning is *very* expensive, so everything which isn't essential for installation -> post-RC
<ogra> hmm
<ogra> that wont get us any ltsp tests though
<ogra> fix is trivial http://paste.ubuntu.com/60602/
<pitti> hm, argh
<ogra> but i suppose its fine after RC worst case
<pitti> ogra: that affects kubuntu alternates, too?
<ogra> can it be let through so that it gets in in case another respin reason shws up ?
<ogra> all alternates apart from xubuntu
<ogra> the original fix went in to support xubuntu-artwork-usplash on non CD builds
<pitti> I don't see it in the queue
<ogra> its not uploaded yet
<ogra> i wanted to ask first :)
<pitti> ogra: it should be uploaded either way
<ogra> oki
 * ogra does
<ogra> did anyone else note weird focus behavior with alt-tab ?
<ogra> i often end up having the focus on a different window than the one in front after alt tabbing
<pitti> ogra: ok, let's do it then
 * pitti disables alternates in tracker
<mvo> pitti: is the retracer working? it looks like bug 286915 has no symbolic trace yet
<ubottu> Launchpad bug 286915 in update-notifier "update-notifier crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/286915
<mvo> (6h old)
<pitti> ogra: ubuntustudio is not affected either, I suppose?
<ogra> pitti, i dont think they have ltsp
<ogra> pitti, and mythbuntu uses universe
<pitti> ogra: ok, just ubuntu and kubuntu then
<ogra> right
<pitti> ogra: hm, how did that change since beta?
<ogra> pitti, it was fixed after beta
<pitti> ogra: apparently not then?
<ogra> 5.1.28-0ubuntu1
<ogra> had the fix, it regressed in beta
<pitti> ogra: I mean the fix you just uploaded, http://launchpadlibrarian.net/18772938/ltsp_5.1.29-0ubuntu3_source.changes
<ogra> it was working in beta (due to being regressed from hardy for teh whole cycle), the fix was uploaded on oct 11th (sfter beta)
<ogra> *after
<ogra> that was bug 281196
<ubottu> Launchpad bug 281196 in ltsp "xubuntu won't build without the universe repo defined in 000-basic-configuration in the Ubuntu plugins folder" [Undecided,Fix released] https://launchpad.net/bugs/281196
<ogra> pitti, between the upload and today nobody tested ltsp builds from CD
<pitti> ogra: ok, you are 100% sure about the fix?
<ogra> it works fine for non CD builds but due to the fact of universe not being on ubuntu CDs it breaks there
<ogra> pitti, i havent tested it myself, i'm up to my ears in -mobile tests but i'm sure the --components main,restricted sets the right options for ltsp-build-client
<ogra> since that was the default until we added the xubuntu fix
<stgraber> pitti: I also had a look at the debdiff and I'm pretty sure it'll fix bug 287098
<ubottu> Launchpad bug 287098 in ltsp "LTSP fails to install from Ubuntu Alternate" [Undecided,New] https://launchpad.net/bugs/287098
<stgraber> ogra: is there an easy way to test it ? (other than rebuilding a cdimage)
<pitti> oh, this bug shuold have been mentioned in the changelog
<ogra> pitti, it was filed after my upload :)
<stgraber> pitti: I opened the bug after ogra uploaded the fix
<pitti> ogra: accepted, please close the bug manually then
<pitti> ah, heh
<ogra> will do, thanks
<stgraber> ogra: I closed the bug
<ogra> thanks :)
<davmor2> Riddell: did you get the jockey thing sorted?
<kees> lool, seb128: something broke in libv4l/cheese -- gstreamer v4l doesn't seem to work any more.
<pitti> cjwatson: ah, libmail-sendmail-perl has no further dependencies and 0 bugs, I'll just review and promote it
<superm1> pitti, given the RC DVD hasn't been created yet (AFAIK), will it be possible to adjust the components for the pieces of fglrx pre-rc so that it can now get included on that RC DVD, or will that need to be post-rc too?
<pitti> superm1: that should be possible, since it will be a while until we can actually build DVDs
<pitti> slangasek: ^ ok for you, too?
<slangasek> yes, that's ok with me
<slangasek> that needs to be re-seeded somewhere?
<pitti> superm1: is it already seeded?
<superm1> pitti, no it's not seeded yet. we were waiting for it to be in the right component before breaking the DVD again
<pitti> superm1, slangasek: moved to restricted
<pitti> erm, hang on
<pitti> 2008-10-21 18:07:06 WARNING 'fglrx-installer' has no binaries published in intrepid
<pitti> WTH?
<superm1> check NEW
<pitti> oh, NEW
<superm1> the library was moved into it's own binary package
<pitti> right, that
<pitti> NEWed to multiverse
<NCommander> superm1, I see you resolved your library issues
<superm1> NCommander, well just the workaround that you and I discussed yesterday to not use dpkg-shlibdeps
<NCommander> superm1, its an ugly situation
<pitti> superm1: ok, I think I sorted out the remaining overrides (fglrx-modaliases -> main, libamdxvba1 -> multiverse, rest -> restricted)
<superm1> pitti, well fglrx-amdcccle doesn't need to be restricted i dont think.  it's equivalent for nvidia (nvidia-settings), where's that live?
<pitti> superm1: main :)
<superm1> pitti, ah okay :)
<pitti> superm1: it's GPL and needed for both universe and restricted pacakges
<pitti> superm1: so what should we seed? jockey-common already pulls fglrx-modaliases
<pitti> so just fglrx-kernel-source and xorg-driver-fglrx ?
<pitti> do we need xorg-driver-fglrx-dev ?
<pitti> tseliot: ^
<superm1> pitti, i think just xorg-driver-fglrx
<superm1> that will pull in fglrx-kernel-source
<superm1> the -dev doesnt need to be seeded
<pitti> ah, indeed
<pitti> and it Recommends: fglrx-amdcccle
<pitti> so that needs to be in restricted, too
<pitti> ok, seeding done
<superm1> okay thanks
<liw> mvo, I fear I don't know python-apt (libapt?) well enough to understand how your suggestion on dealing with the Synaptic pin settings ("lock package") should be done; do you have further advice?
<cpufreak> top
<cpufreak> ww.
<pitti> infinity: do you have a magical stick to tell king and terranova "nah, I don't actually want this DVD livevs any more" and cancel it?
<lool> kees: Weird, I tested yesterday and it worked
<slangasek> ogra, tjaalton: I'm skeptical of accepting the fix for bug #282203 at this stage; it's my understanding that hotplug doesn't work well for tablets no matter what you do, and it sounds like re-adding the fdi will cause regressions for users on upgrade
<ubottu> Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Medium,Triaged] https://launchpad.net/bugs/282203
<lool> kees: both with cheese 2.24.0 and 2.24.1
<lool> kees: It breaks for you?
<slangasek> tjaalton: so I don't think that really qualifies for a two-days-before-RC accept
<lool> kees: Works just fine here
<tjaalton> slangasek: well, regression when upgrading from hardy, yes
<tjaalton> slangasek: if they use more than just the stylus
<slangasek> tjaalton: which I understand the kind of users who have tablets tend to do :-)
<mvo> liw: did my snippet not work?
<liw> mvo, cache._depcache.ReadPinFile("/var/lib/synaptic/preferences")
<liw> mvo, that works, but what do I do next?
<tjaalton> slangasek: yeah, your call :)
<mvo> liw: that should be all required, no?
<liw> mvo, my code (based on your initial code) checks for isInstalled, installedDownloadable, candidateDownloadable, and _pkg.VersionList -- based on those, it still determines that the package is cruft
<lool> kees: Could you check your upgrade logs and see which package regressed here?  I'm using libv4l 0.5.1 BTW
<kees> lool: hrm, after a full update and reboot, it seems fine.
<kees> lool: I must have seen some kind of intermediate breakage.
<lool> pitti: Supposedly, gstreamer-plugins-ugly is just to play the format supported only by plugins in this package; I'm downgrading to suggests as well
<kees> lool: sorry for the false alarm  :P
<tseliot> pitti: yes, we don't need the fglrx -dev package
<tseliot> superm1, pitti: from what I remember amdcccle is proprietary
<liw> if I want to programmatically sort a list of kernel packages into order by version number, and they follow the linux-image-$VERSION pattern, I can just sort the package names, right?
<pitti> tseliot: yes, the question was just about restricted vs. multiverse
<lool> kees: Some people seemed to say that the cam would only work once
<lool> kees: I suspect it needs clean shutdown or something
<pitti> tseliot: it's in restricted now, since xorg-driver-fglrx recommends it
<pitti> lool: ok, thanks; so that, promote libvisual-plugins, and drop jack from the latter is the way to go now?
<lool> pitti: jack is shlibs borkeness I think
<tseliot> pitti: yes, it should stay in restricted
<mvo> liw: hm
<mvo> liw: let me update the code
<tseliot> pitti: I mean, good choice
<lool> pitti: What's the path between libvisual and jack?  bdeps?
<lool> I don't like removing jack this late, it could break ubuntu studio or something
<lool> Actually the bdep is suspicious, I see references to jack in the upstream code, but no dep
<pitti> lool: yes, it b-deps on it; curiously enough it doesn't seem to *binary*-depend on jack
<lool> Yeah, I suspect the configure check fails for some reason
<lool> looking at build log
<kees> lool: works multiple times for me, even after a -9 kill.
<lool> checking for LIBJACK... yes
<lool> pitti: I think it simply isn't installed
<lool> drwxr-xr-x root/root         0 2007-11-26 11:44:10 ./usr/lib/libvisual-0.4/input/ => no jack
<pitti> lool: ah; so removing the b-dep now wouldn't actually change anything
<ia> hello, everybody. I've found out some intresting bug and will be very appreciate, if someone else check it, because i'm not sure, that someone else have this issue - http://bugs.launchpad.net/ubuntu/+bug/287134 :-)
<ubottu> Launchpad bug 287134 in ubuntu "In "Intrepid" beta for correct password enough only 8 correct chars" [Undecided,New]
<lool> pitti: it never goes into input/jack for some reason
<lool> SUBDIRS = $(build_input_plugins)
<mvo> hm, who can prod the retracer? bug #286915 has no backtrace and it would be nice to have one
<ubottu> Launchpad bug 286915 in update-notifier "update-notifier crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/286915
<lool> Input plugins            : alsa mplayer => no jack
<liw> ia, I cannot reproduce that
<bryce> I got to run a friend to the train station; be back after lunch
<lool> pitti: I'm kind of WTF, build_input_plugins="" is reset in configure.ac for no apparent reason
<lool> pitti: Anyway, will report to Debian and will remove bdep
<pitti> lool: splendid, thanks
<pitti> lool: I'm somewhat grateful about this bug, though, since it allows us to drop it without changing runtime behaviour :)
<pitti> lool: I'll review libvisual-plugins for MIR after dinner
<lool> pitti: Yeah, incredible coincidence :)
<lool> pitti: I'm dropping libesd0-dev bdep for the same bug...
<superm1> pitti, post rc, i'm going to have an extra hook to add for bluetooth stuff that's used in pm-suspend.  would you rather see it land in the bluez package for now as a patch, or in the pm-utils package as a patch?  I'm been waiting for the pm-utils maintainer to ack it before i brought it up, but it's looking like that might not happen in time
<lool> pitti: Frankly libvisual-plugins is not the cleanest; I got lintian errors and last upload in Debian was a year ago (albeit there's no reported bugs and it's the latest upstream version), the upstream site is more or less broken
<dashua> mvo: Synaptic Quick Search is fixed.  Thank you :)
<mvo> dashua: excellent, thanks for testing it :)
<dashua> Np
<sleon> i have a problem, that after i hibernated my computer, it stopped starting with acpi mode on
<ogra> slangasek, well, its a "at least something that works" approach i'd say
<slangasek> ogra: you're saying that it's better to handle it through evdev?
<slangasek> er, s/evdev/hotplug/
<ogra> well, hal-input is the future
<ogra> so you would have at least something that works with the desired model
<slangasek> but it would still be a regression for hardy users; there's no reason we need to ship every available bit of the "future" in a release, if it gives an inferior user experience
<ogra> i plan to put up a howto for touchscreen users for which i havent gotten evtouch data yet to create .fdi files, i assume that could be extended for wacom users and how to set up your device
<ogra> though for touchscreens *everything* is an improvement to the former situation ...
<ogra> the prob is that the actual regression is between gutsy and hardy
<ogra> for wacom
<slangasek> howso?
<ogra> we shipped all the tablet default sections in gutsy, they were dropped because users without wacom devices complained about the warnings in the xorg logs
<ogra> so hardy didnt ship any default sections for wacom users and they had to set them up theirselves
<slangasek> ok, but anyone who had configured their tablet manually in X for hardy is now going to have it broken again if we enable this fdi file
<ogra> right
<RainCT> wb seb128
<ogra> which imho wuld be ok if we offer a way to show them how to adapt to the new config
<pgraner> slangasek: ping
<slangasek> ogra: "offer" how?  release notes?
<slangasek> we might as well leave the package as it is and release note everything, I think
<slangasek> pgraner: moo
<ogra> release notes pointing to a howto that explains how to create a fdi file
<seb128> hi RainCT
<ogra> well, the trasition will have to happen anyway, we just postpone the prob
<pgraner> slangasek: we need to upload one more kernel to address some last min issues, rtg is ready any time, wanted to make sure it was cool with you before we proceeded
<ogra> and with the request to users to file their created .fdi files jaunty would have all data available early
<pgraner> slangasek: not an abi bumper, just some regression cherry picks and a few device enablers that are isolated and not a big risk
<slangasek> ogra: the problem only exists because we have incomplete support for these devices via hotplug, and should be resolved for jaunty; we can do that just as well without breaking the hardy->upgrade path for users...
<slangasek> pgraner: which last-minute issues?
<ogra> slangasek, well, currently all i hear is that it doesnt work on upgrades either
<RainCT> seb128: I've added .ephy-extension.in to po/POTFILES.in but running "intltools-update -p" doesn't include the strings for _Name nor _Description from it into the .pot. Any idea what could be wrong? (It's up on lp:epiphany-extensions-extra, if you want to look).
<ogra> juliux is a typical candidate here btw
<slangasek> ogra: I'd like some solid confirmation of that in the form of a bug report
<slangasek> ogra: I'm not going to risk breaking the upgrade path based on hearsay
<ogra> juliux ^^^ mind adding info to the bug ?
<mdke> pitti, slangasek: on ubuntu-docs, shipping translations with 70% translation or more results in a package size of 2.9MB (as against 2.3MB the current archive version). How does that sound?
<pgraner> slangasek: XFS barrier support, intel G45 motherboard support
<seb128> RainCT: I'm not a libtool wizard and I've other things to debug but it might use the filename, you said that was a .desktop before
<juliux> hm?
<ogra> slangasek, i personally wasnt involved in tablets at all i only looked after touchscreens, i'm wiling to do so for jaunty though but wasnt aware o wacom probs until very recently
<slangasek> pgraner: do you have a bug number for that latter issue?  Anyway we are at this point not going to be able to get it in for RC without a lot of pain; I'm not happy with the idea of pushing a new kernel between RC and final either, but probably will if that's what we have to work with
<slangasek> pgraner: there are also a number of other targeted and milestoned linux bugs, such as bug #259157 and bug #284354 - are those in progress somewhere?
<ubottu> Launchpad bug 259157 in network-manager "[MASTER 0.7 regression] atheros/madwifi and orinoco drivers not supported" [High,Triaged] https://launchpad.net/bugs/259157
<ubottu> Launchpad bug 284354 in linux-lpia "AR2424 on Samsung Q1 loads both ath_pci and ath5k modules" [High,Triaged] https://launchpad.net/bugs/284354
<RainCT> seb128: I said ".desktop and similar files" :)
<ogra> slangasek, at least the second one ws discussed in the kernel team meeting today
<seb128> RainCT: dunno what is similar to a .desktop, what I said was for a desktop before
<pgraner> slangasek: 259157 won't happen before RC ath5k is a mess upstream and we don't have good answer other than it is going to go as is and we'll hopefully get it cleaned up in a update
<RainCT> seb128: that it also has Name and Description entries, and epiphany-extensions is doing it like that too (but using autotools)
 * ogra likes to note that he is massively unhappy about that we wont release ubuntu-mobile with working wireless for most mobile users that way
<slangasek> pgraner: will 259157 happen /after/ RC, then?  if so, I think we're better off with a single kernel upload for the lot, instead of breaking our necks to get one in pre-RC and then having another post-RC
<pgraner> slangasek: 284354, amitk is working on it
<RainCT> seb128: uhm, renaming it to .desktop.in works
<RainCT> *it works
<pgraner> slangasek: not for awhile, thats why we wanted to get these in before
<RainCT> seb128: well, go debug your stuff, I'll see if I get it working :)
<RainCT> seb128: thanks
<slangasek> mdke: I believe all the images can spare 600k at this point, yes
<lamont> Function `cairo_pdf_surface_create_for_stream' implicitly converted to pointer at /build/buildd/gtk+2.0-2.14.4/modules/printbackends/lpr/gtkprintbackendlpr.c:212
<lamont> stupid gtk2.0
<mdke> slangasek: I'm trying 75% to see if that will squeeze a bit more out, I think that's a fair percentage to go up to
<lamont> gtk+2.0, that is
<slangasek> mdke: feel free, but I think 600k is already something we can live with (after the last round of pruning that pitti had to do :/)
<slangasek> pgraner: "not for a while" as in, you believe 259157 is now SRU material?
<mdke> slangasek: thanks very much. I'll give 75% a try and then re-ask for sponsoring of the upload
<pgraner> slangasek: yep, there is not a solution upstream or much we can do ATM. rtg wants to hold off until a better solution develops
<lool> pitti: I pushed a bunch of libvisual-plugins uploads, as I got hooked into fixing it's packaging; I think the package is quiet upstream and in Debian, working decently in its current version, and not risky security wise, so I think we can promote it as being relatively pure logic; the two inputs currently enabled are alsa and mplayer, so I think there's no high risk here
<tseliot> slangasek: I showed my (3 lines) changes to the release notes to pitti and he said that they looked good. The grammar should be ok too: https://wiki.ubuntu.com/IntrepidReleaseNotes#nVidia%20%22legacy%22%20video%20support
<[diablo]> good evening #ubuntu-devel
<[diablo]> guys, could anyone please tell me the name of the script that is (iirc) from Dell for rebuild nvidia drivers
<pgraner> slangasek: for the Intel G45 https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/285572
<ubottu> Launchpad bug 285572 in xserver-xorg-video-intel "X freezes right after login when using EXA on G45 machine" [High,Triaged]
<RainCT> [diablo]: hi, there's #ubuntu for support
<pgraner> slangasek: this is a two part patch one goes in X, that bryce has put in X, the other is needed in the kernel
<robertj> is there a VM somewhere that runs the automated unit tests nightly?
<tseliot> [diablo]: it's DKMS
<[diablo]> RainCT, nod...
<pgraner> bryce: can you confirm pls?
<[diablo]> sorry
<[diablo]> thanks tseliot ! cheers dude
<slangasek> tseliot: I'm not keen on suggesting in the release notes that users should run grep commands to find out if their system supports SSE
<slangasek> tseliot: isn't it possible to enumerate the systems that don't support SSE?
<tseliot> slangasek: what do you mean by enumerate?
<slangasek> tseliot: list
<pgraner> ogra: did you see amitk's comments in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/284354/comments/7
<ubottu> Launchpad bug 284354 in linux-lpia "AR2424 on Samsung Q1 loads both ath_pci and ath5k modules" [High,Triaged]
<tseliot> slangasek: aah, writing a list of all the CPUs which don't support SSE
<slangasek> tseliot: i.e., "486, Pentium, Pentium Pro, and AMD-whatsit", or similar
<ogra> pgraner, that has a lot of potential for post release breakage in it
<slangasek> the list of SSE-less CPUs that work with Ubuntu is fairly short, isn't it?
<pgraner> rtg: ping
<rtg> hmm?
<ogra> pgraner, i'd like to avoid shipping lbm as a default package if possible
<amitk> so here is the issue for bug #284354
<tseliot> slangasek: ok, I think it can be done. I'll let you know when it's ready
<ubottu> Launchpad bug 284354 in linux-lpia "AR2424 on Samsung Q1 loads both ath_pci and ath5k modules" [High,Triaged] https://launchpad.net/bugs/284354
<amitk> mobile wants to blacklist ath5k
<TheFiller> Are the ISO images of the alternate CD of the stable version (8.04) updated regularely?
<amitk> but same pci id is working with ath5k for eee pc users
<pgraner> rtg: 259157.... slangasek was asking on timeframe, I told him after GA due to upstream issues, sound right?
<ogra> amitk, well, correctly said, mobile would like the driver from lbm in the default kernel image
<slangasek> pgraner: the X fix for 285572 is in the unapproved queue, yes
<slangasek> TheFiller: they're updated as part of point releases, on an approximately 6-month cycle
<rtg> amitk: what will they use for their WPA solution?
<rtg> pgraner: yes
<amitk> ogra: that can't happen the diff is too big
<pgraner> slangasek: not sure I was told that bryce was adding it in via amitk
<amitk> rtg: nothing, since there is no madwifi module in wpasupplicant
<slangasek> TheFiller: this applies to 8.04 because it's an LTS (long-term support) release, it's not true of other Ubuntu releases
<TheFiller> slangasek: Thank you. Does this also hold true for the 'normal' desktop CD? Or is this updated more often?
<slangasek> pgraner: that was a statement, not a question :-)
<slangasek> TheFiller: the same.
<rtg> amitk: which means LBM (if they want WPA)
<TheFiller> slangasek: Thank you
<amitk> pgraner: slangasek: so we are good for the 285572 then
<pgraner> slangasek: sorry my bad then
<amitk> rtg: correct
<RainCT> seb128: about bug #285695, I guess the change he did is that one you suggested to him (rename ~/.local)
<amitk> ogra: seriously, why would you want to default to supporting only wep?
<ubottu> Launchpad bug 285695 in nautilus "Nautilus asks for user password when launched" [Low,Incomplete] https://launchpad.net/bugs/285695
<ogra> amitk, ??
<slangasek> amitk: well, I haven't agreed to accept the changes yet before RC; I'm not keen on having to reroll all the CDs /again/ for this
<ogra> amitk, with the ath5k from lbm everything works flawless
<seb128> RainCT: rigjht, I was just asking in case he had a look to what setting exactly there is creating the issue
<ogra> amitk, currently by default two drivers are loaded for the same device
<amitk> ogra: ath5k in lbm is ok. but it is _NOT_ going to be integrated into the kernel
<ogra> amitk, right, but i dont see a sane way of intregrating lbm in the default seeds
<slangasek> amitk: btw, an 'ubuntu-8.10-beta' milestone for this bug is definitely unrealistic at this point :-)
<amitk> so going by that assumption, your only choice is madwifi
<amitk> slangasek: oops.
<ogra> which is the current default
<ogra> slangasek, modprobe timeshift :)
<ogra> its the kernel team you deal with ;)
<pitti> rtg, BenC1: hm, CDROM_DRIVE_STATUS is evil in the intrepid kernel (bug 283316); you don't happen to know about this, and whether this is considered a bug or a feature?
<ubottu> Launchpad bug 283316 in hal "intrepid - ejected dvd media is inserted right back in" [High,In progress] https://launchpad.net/bugs/283316
<ogra> amitk, i'll discuss it with lool but i think we agree that we would be unhappy of carrying lbm as a dep of any of the meta packages
<ogra> the change wouldnt happen before RC anyway
<rtg> pitti: I noticed you have to be pretty quick.
<slangasek> amitk, pgraner: when was the decision made to target this bug to intrepid?  it looks like the first follow-up from the kernel team was about 10 hours ago; if this had been discussed with the release team sooner we could have planned to include it in the CD pulse that we're halfway through at the moment, now I instead have to evaluate whether this change alone justifies rerolling everything or else waiting to batch it with other pending fixes
<amitk> ogra: noted. And kernel team agrees that shipping a new ath5k at this stage is not a option because all the drivers will have to be bumped up to match the headers required by new ath5k
<ogra> all solutions apart from getting teh working driver from lbm into mainline are resulting in releasing a broken wlan support for final
<pitti> rtg: I was just told about it today; my laptop's external CD drive can't mechanically close, so I never noticed myself so far
<ogra> which is very odd as it will lose us people from the community which was our (or rather my) main focus for this release with the mobile image
<slangasek> amitk, pgraner: also, is EXA default on this hardware?
<slangasek> s/on this hardware/with this driver/
<rtg> pitti: same here (no mechanical door)
<amitk> slangasek: it was brought to my attention a few hours ago. So not a long time has passed. And the patch seemed fairly simple and straight-forward
<amitk> slangasek: but I would be willing to pull it from the kernel release if it is causing major headaches.
<pitti> rtg: so given that the documentation says that there is a possible CDS_TRAY_OPEN, I'd consider this a bug
<slangasek> amitk: the question isn't whether the patch is straightforward; there's a larger picture here
<rtg> pitti: I do have a couple with drive motors somewhere. I'll test it.
<amitk> slangasek: agreed. I didn't see that picture and stand rebuked.
<slangasek> amitk: re-rolling all the CDs for a kernel fix is costly when we're this close to RC; it costs us time for the actual builds, and it also costs us testing resources
<rtg> pitti: I remember a patch to the eject package awhile back. I wonder if that messed something up.
<pitti> rtg: no, it's not related to that
<jcristau> slangasek: yes, exa is the default. i'm not sure it's relevant to the bug though.
<pitti> rtg: I updated the bug title and added a comment
<pitti> rtg: I'm looking for an upstream bug now, and try to find the commit that changed it
<pitti> rtg, BenC: oh, do we use a different kernel driver for CD-ROMs in intrepid? ide-cd vs. some SCSI emulation thingy?
<rtg> pitti: its possible, I haven't followed the SCSI layer very closely.
<BenC> pitti: there's ide-cd and sr_mod, but they both use cdrom.ko for low level, IIRC
<pitti> ide-cd.ko exists in hardy, but not in intrepid
<slangasek> amitk, pgraner: ok, please go ahead with the linux upload with those two fixes (285779 and 285572); I haven't decided yet whether to accept those packages before RC, but I will definitely try to if the opportunity presents iself
<slangasek> itself
<cody-somerville> slangasek, btw, if you're considering rerolling the rc, I'm in favour.
<cody-somerville> We forgot to update our docs so everything still says 8.04
<cody-somerville> Well, we didn't forget, we were waiting on someone but they didn't come through
<slangasek> cody-somerville: I assume you mean xubuntu?  We can do individual rerolls with much less pain
<pitti> BenC: there is a related commit (not for this bug, though) which seems to indicate that ide-cd and SCSI use different ioctl implementations: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=210ba1d1724f5c4ed87a2ab1a21ca861a915f734
<cody-somerville> slangasek, aye
<slangasek> BenC: is there an update to linux-firmware in the pipe for the copyright problem?
<slangasek> cody-somerville: are the fixed docs uploaded? :)
<cody-somerville> slangasek, Okay. I'm going to sponsor NCommander's upload once it is ready and then I'd like to reroll Xubuntu.
<BenC> pitti: hmm...well, unless something changed in sr_mod between hardy and intrepid, nothing should be different
<slangasek> cody-somerville: ok - the actual reroll will probably be held until we have a decision on the kernel stuff
<BenC> pitti: I doubt many people were using ide-cd in hardy
<pgraner> slangasek: ack
<BenC> slangasek: I might have something partial done...tracking down all this firmware is difficult
<rtg> slangasek: you'll get some other baggage in the kernel upload for free. I pulled in the stable tree updates from 2.6.27.2 a couple of days ago.
<pitti> BenC: ah, so we were using sr_mod in hardy, too? that's a good data point
<slangasek> BenC: understood... :)  Even if you don't think you'll have it all tracked down for final, please plan to upload at least a partial fix
<BenC> pitti: Oh yeah, most ATA controllers were handled by libata and not ide.ko as far back as feisty
<BenC> slangasek: deadline?
<slangasek> BenC: Sunday, for best results
<BenC> slangasek: No problem then
<pitti> BenC: hm, I'm a bit lost then; above git commit was actually the last change to sr_ioctl.c, and it happened in January (thus hardy should have it)
<pitti> superm1: having the patch in pm-utils is fine, at least for intrepid (if upstream refuses it, we have to re-negotiate  it)
<superm1> pitti, okay, i've put the debdiff on a bug and subscribed ubuntu-release for now then, and i'll plan to upload after rc and someone on release looks at it
<[Relic]> What do you do if a fix has been submitted but seems only to work in 32bit versions and not 64bit version of 8.04 (an LTS fix)?
<RainCT> [Relic]: complain about it on the bug report
<ryu2> j #ubuntu-de-offtopic-offtopic
<ryu2> sorry :/
<Riddell> cjwatson: ubiquity changelog is still UNRELEASED for the version uploaded yesterday, I'll change that to intrepid and assume there's no other changes that havn't been committed
<cjwatson> Riddell: who uploaded it?
<cjwatson> Riddell: please get them to commit
<slangasek> asac: since the kernel team says their side of 259157 is not fixable prior to release, is it possible to get the driver tweaks back into NM in that same timeframe?
<TheMuso> kwwii: ubuntustudio-look is the source package.
<Riddell> cjwatson: you're in the changelog line
<cjwatson> Riddell: surely not. https://lists.ubuntu.com/archives/intrepid-changes/2008-October/009050.html says Evan uploaded it
<Riddell> ah, but it was evand indeed
<cjwatson> Riddell: besides I bind all my bzr checkouts so I don't generally have this problem ;-)
<cjwatson> Riddell: in future I really prefer it if commits don't happen until after this is done properly so that tags are accurate
<cjwatson> call me anal if you wish :)
<cjwatson> but the way you did it means that there is no possible correct location for the tag
<Riddell> cjwatson: I didn't know ubiquity had tags
<cjwatson> Riddell: debcommit -r sets them automatically
<asac> slangasek: no ... there are no driver tweaks for atheros
<asac> in NM
<slangasek> asac: so without the kernel fix available, our only other option is release notes?
<asac> slangasek: i lengthy explained that in the kernel team meeting
<slangasek> asac: sorry, I need the less-lengthy explanation for RMs that are juggling very sharp CDs :-)
<cjwatson> Riddell: can I uncommit this, tag it properly, and put your change back at the end?
<asac> slangasek: short version: for ath NM tweaks cannot be added back in a reasonable time.
<slangasek> asac: ok - release-noting then, thanks
<Riddell> cjwatson: sure
<asac> slangasek: i suggested to the kernel team to gather feedback and blacklisting ath5k for those that we know that work with ath_pci in a SRU
<slangasek> ok
<asac> for those == pci ids
<asac> unfortunatley we have no detailed infos what ids those are
<slangasek> cjwatson: bug #204272> my investigations lead me to believe we have a horrible, horrible thread race somewhere in gstreamer/pulse, I haven't updated the bug at all because I don't have anything conclusive and am not even sure my crash is the same one
<ubottu> Launchpad bug 204272 in pulseaudio "totem-gstreamer crashed with SIGSEGV in pa_stream_write()" [High,Confirmed] https://launchpad.net/bugs/204272
<rtg> slangasek: uploaded linux_2.6.27-7.13
<rtg> I'm fleeing for awhile. I'll check back in a few hours.
<slangasek> rtg: thanks
<cjwatson> Riddell: done (you'll need bzr pull --overwrite if you're branched, though I think if you're using a checkout then bzr up should be enough)
<cjwatson> Riddell: I used arcane trickery to uncommit but then merge back the uncommitted change, so it shows as a branch
<cjwatson> well, I suppose I could just have done branch+uncommit+commit+merge but I didn't ;-)
<Riddell> cjwatson: thanks, hope that didn't cause you too much trouble
<cjwatson> no trouble
<cjwatson> I just find it useful to have all the "i"s dotted close to release so that we can do accurate archaeology if need be :)
<slangasek> kirkland: have you seen bug #285269?
<ubottu> Launchpad bug 285269 in grub "grub error 15 after intrepid-beta install" [Undecided,Confirmed] https://launchpad.net/bugs/285269
<cjwatson> slangasek: that definitely seems like a bug
<cjwatson> evand: ^-
<cjwatson> the code below handles boot_device that way ...
<kirkland> slangasek: cjwatson: Hauke  wrote 17 minutes ago that it's fixed for him in 20081021.3
<slangasek> er
<slangasek> how did that happen? :)
<cjwatson> kirkland: he's describing a different problem
<cjwatson> silly people conflating bugs
<slangasek> right
<kirkland> erg
<cjwatson> I've cranked the bug up to triaged/high/ubuntu-8.10
<slangasek> ah, is that why my attempt to approve the nomination is hanging
<cjwatson> could be :)
<cjwatson> I'll see if I can reproduce
<kirkland> cjwatson: i'm trying here
<kirkland> slangasek: cjwatson: the beta iso's were busted for me too...  i reported and fixed that last week
<cjwatson> busted how?
<cjwatson> anyway, the convert_to_uuid stuff wasn't added until somewhat post-beta
<kirkland> cjwatson: see the last couple of grub/mdadm patches you sponsored for me
<cjwatson> ok
<cjwatson> but forget about LVM/md, that isn't what this bug is describing
<kirkland> cjwatson: okay, i'm testing now
<cjwatson> if you read the description
<cjwatson> it's talking about perfectly ordinary block devices, but you just happen to have a separate /boot
<cjwatson> slangasek: is this "release-note for RC, fix for final" territory or will you want to squeeze a fix into RC somehow?
<slangasek> cjwatson: the former
<cjwatson> thought so
<Riddell> tseliot, pitti: girlfriends laptop now reinstalled with a hardy->intrepid upgrade and jockey-kde is working better, it offers me broadcom STA and b43 and ATI drivers
<Riddell> tseliot, pitti: ATI and b43 resulted in a blank warning dialog, STA installed and is working well
<pitti> Riddell: you ran jockey-kde through sudo? we still need to fix the .desktop file to make it work through the menu
<slangasek> evand, cjwatson: bug #280515 was fixed in grub-installer, wasn't it?
<ubottu> Launchpad bug 280515 in grub "Flash drive boot - menu.lst errors" [Undecided,New] https://launchpad.net/bugs/280515
<tseliot> Riddell: blank??? With some button?
<pitti> Riddell: blank warning dialog? that sounds bad
<Riddell> pitti: I ran it through the systray icon
<pitti> Riddell: yes, that works (I fixed that recently to go through kdesudo)
<jarnos> Why is mapivi 0.9.1 rather than mapivi 0.9.7 is added to the universe repository of intrepid? They differ a lot: http://mapivi.sourceforge.net/mapivi.shtml#news
<Riddell> the .desktop file needs vmvmvmvmvmvmvmvm
<Riddell> no, it doesn't
<Riddell> it needs X-KDE-SubstituteUID=true
<tseliot> Riddell: did you try installing policykit-gnome?
<cjwatson> slangasek: sounds like 282037
<cjwatson> slangasek: oh, it's only bug 282037 if the install was *from* a flash drive
<ubottu> Launchpad bug 282037 in ubiquity "grub-installer defaults to (hd0) which is the installation medium in the case of USB installs" [High,Fix released] https://launchpad.net/bugs/282037
<cjwatson> slangasek: it ought to have been fixed by the addition of UUIDs
<kirkland> cjwatson: i have reproduced the problem here
<Riddell> tseliot: yes
<kirkland> cjwatson: slangasek: shall I test the proposed fix?  http://launchpadlibrarian.net/18655689/xxxx
<Riddell> tseliot: currently it says I should restart for the ATI driver, so I guess I'll do that
<kirkland> looks reasonable ^
<tseliot> Riddell: and are you getting a blank dialog with some button or what?
<tseliot> Riddell: e.g. a blank progress dialog
<slangasek> cjwatson: I thought that's what the "not CD image" comment meant, but it's of course ambiguous
<slangasek> kirkland: yes, please test && commit
<kirkland> slangasek: commit?
<slangasek> kirkland: to the grub bzr tree?
 * kirkland doesn't have commit access, but i'll put it somewhere mergable
<slangasek> oh, right
<slangasek> do that then :)
<Riddell> tseliot: I rebooted, now I have both broadcom STA and ATI drivers enabled (it no longer offers me b43)
<Riddell> tseliot: if I click to disable ATI driver it just disabled the top listwidget and nothing much happens
<Riddell> tseliot: I suspect the blank error dialogue was from when i had no network
<tseliot> Riddell: yes, that's likely to be the cause but the dialog shouldn't have been blank
<tseliot> Riddell: and you should've seen a progress dialog when removing the driver too. Have you ever seen a progress dialog in jockey-kde (in intrepid)?
<Riddell> tseliot: yes, when installing broadcom STA
<tseliot> Riddell: hmm... ok I'll do some testing tomorrow so as to see if I can reproduce the problem. Thanks for your feedback
<cjwatson> kirkland: the comment change in http://launchpadlibrarian.net/18655689/xxxx is bogus; the rest should be OK
<kirkland> cjwatson: i'm trying to figure out the best way to test this, since this is in a deb, not a udeb
<pitti> BenC: I reported the CD-ROM ioctl bug upstream, let's see whether someone finds something
<kirkland> cjwatson: i'm not sure you've shown me that -fu yet
<cjwatson> kirkland: 'sleep 3600 || true' after the apt-install block in /usr/bin/grub-installer, then edit the code in /target/usr/sbin/update-grub, then kill the sleep process
<slangasek> kirkland: install; mv /boot/grub/menu.lst{,.bak}; update-grub -y?
<slangasek> or that
<cjwatson> s/then edit/wait for the installer to reach the sleep, then edit/ of course
<kirkland> cjwatson: slangasek: thanks, i'm on it
<NCommander> ScottK, I did plan to become a formal backporter. jdong already said yes, pending MOTUship
<kirkland> cjwatson: slangasek: test successful
<kirkland> cjwatson: slangasek: regression testing required?
<slangasek> kirkland: regression-testing> test that it also DTRT with a single-partition install? :)
<kirkland> slangasek: let me push a bzr branch, and then i'll test that
#ubuntu-devel 2008-10-22
<kirkland> slangasek: lp:~kirkland/grub/285269
<kirkland> slangasek: said regression test succeeded
<slangasek> kirkland: great
<slangasek> cody-somerville: do you have that xubuntu docs fix yet?
<cody-somerville> slangasek, I'm going through the motions now to review and then hopefully upload
<slangasek> cody-somerville: ok.  I've just stopped the publisher in order to do one last accept && rebuild run for everything before RC; if you can get it uploaded in the next 15min or so that's ideal, otherwise I'll defer xubuntu until the next publisher run and rebuild you then
<cody-somerville> slangasek, test building and test installing and then you'll have the upload
<slangasek> bryce: are you on top of bug #277709, or should I subscribe u-m-s?
<ubottu> Launchpad bug 277709 in mesa "Xorg crashed with SIGSEGV in i830_emit_state" [Unknown,Confirmed] https://launchpad.net/bugs/277709
 * bryce looks
<bryce> what is u-m-s?
<slangasek> ubuntu-main-sponsors
<bryce> ah, no need for that.  the patch is probably fine, just adds an if check. but I want to look at the original code to see where this comes in
<bryce> I'll take care of it once I've finished my current task
<slangasek> ok
<slangasek> superm1: ping
<slangasek> superm1: unping
<bryce> slangasek: yep patch looks perfect.  shall I upload?
<slangasek> bryce: yes please
<slangasek> apachelogger: why are there no bugs referenced in this kdeutils upload?
<slangasek> bryce: do you have a minute to be a sounding board for me on bug #282203?
<ubottu> Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Medium,Triaged] https://launchpad.net/bugs/282203
<bryce> slangasek: sure
<apachelogger> slangasek: I didn't find one, ScottK however complained about gz files not being opened properly, I can explain the problem if you want
<slangasek> bryce: so the request is to enable the fdi file by default that will let the tablet be picked up for input hotplugging; this will only work for the stylus, which is why I was avoiding the change
<slangasek> apachelogger: explain it in a bug and subscribe ubuntu-release, please
<apachelogger> slangasek: ok
<slangasek> bryce: but from the attachments in the bug, it's not enough to use the same xorg.conf from hardy on intrepid in order to get full tablet support, because hotplug is all-or-nothing and you have to list *all* your input devices there, including those that didn't have to be spelled out in hardy?
<slangasek> bryce: do I understand that right?
 * bryce nods
<slangasek> ok
<slangasek> that means anyone who needs full tablet support *must* edit xorg.conf, whether on upgrade or new install; so it doesn't hurt us anything to use hotplug by default
<slangasek> accepting then, thansk
<bryce> yeah as I understand it the issue is something to do with -evdev not handling devices that consist of multiple pieces (tablet, stylus, eraser,...)
<bryce> however I don't know exactly what work's required to get all that going.  It's something on my "if I had time, I'd..." list
<slangasek> ogra was talking about needing more fdi files
<slangasek> I'll hit him up for some release notes text tomorrow
<bryce> cool
<slangasek> augh, where did bug #276857 come from
<ubottu> Launchpad bug 276857 in hal "libhal_ctx_init() returns FALSE, causing Xserver to fail to set up keyboard/mouse" [High,Triaged] https://launchpad.net/bugs/276857
<slangasek> oh, it came from you :-P
<bryce> slangasek: came from ted
<slangasek> ok :)
<bryce> slangasek: got assigned to me since it looked X-ish, but tracing it down, it seems more hal/dbus-ish
<bryce> it's not 100% obvious to me that it's not just a wonky system
<bryce> us developers tend to beat up our systems pretty thoroughly
<slangasek> sure, it's clearly not common-case
<slangasek> cody-somerville: how goes?
<cody-somerville> slangasek, I'm having a little difficulty finding the button to disabling the draft watermark.
<cody-somerville> slangasek, However, I could do the upload now if you need me to
<slangasek> take whatever time you need, just checking whether I should be waiting on you
<slayton> where can I download the intrepid nightly builds?
<cody-somerville> slangasek, Well, you did give me a timeframe
<cody-somerville> slangasek, The changes that need to be made are made
<cody-somerville> slangasek, This is extra
<slangasek> cody-somerville: but that sounds like an "extra" that still needs to be done before release?
<slangasek> mdke: what's the status of ubuntu-docs?
<cody-somerville> slangasek, right - but not critical for release candidate
<cody-somerville> slangasek, so when you want me to upload and can't wait any longer, just shout
<slangasek> cody-somerville: if you're going to continue working on it today, I can wait for you to figure it out or give up for the night :)
<apachelogger> sladen: bug 287312
<ubottu> Launchpad bug 287312 in kdeutils "ark not working properly with gzipped files" [High,In progress] https://launchpad.net/bugs/287312
<cody-somerville> slangasek, okay. I'll upload in 5-10 minutes.
<slangasek> apachelogger: thanks
<bryce> slangasek: 277709 uploaded
<cody-somerville> slangasek, okay, found it. testing then will upload.
<superm1> slangasek, i assume the pings were about the NEW bluez-compat?  it should end up in universe, it's not supported by upstream at all, but is there to appease anyone that runs into troubles using the wizard and wants to use the old hidd, dund, pand
<slangasek> superm1: yes, thus the un-ping :)
<cody-somerville> slangasek, uploaded
<slangasek> thanks
<Awsoonn> wrt bug 141920, why is an e-book of diveintopython a depend of ubuntu-desktop?
<ubottu> Launchpad bug 141920 in zope2 "Page Templates not working correctly" [Medium,Fix released] https://launchpad.net/bugs/141920
<Awsoonn> bug 241920 rather
<ubottu> Launchpad bug 241920 in ubuntu-meta "Remove diveintopython from default install" [Wishlist,Incomplete] https://launchpad.net/bugs/241920
<superm1> Awsoonn, from what i can see in bzr history, it was imported from the warty seeds in 2004, and then at revision 910 was set as a recommend instead of a depend
<slangasek> as for the "why", the short explanation is "because Mark wants it there"
<slangasek> so that Ubuntu is more useful for bootstrapping people into the land of python programming
<nellery> sadly, the link that's supposed to open the ebook from help.ubuntu.com does nothing
<slangasek> nellery: help.ubuntu.com is a wiki; if the link is wrong, fix it?
<Awsoonn> superm1: thanks much. :)
<nellery> https://help.ubuntu.com/8.04/programming/C/ar01s01.html
<nellery> it's the official docs
<nellery> it's supposed to open up the file in your system
<slangasek> hmm, the link itself points to the right place
<slangasek> either it's a firefox security issue (no following links to local files), or something is wrong that I'm not catching
<ajmitch> probably the former, I can't get the link to do anything on hardy
<Hobbsee> that link works for me on intrepid
<Awsoonn> link fails for me on intrepid
<ajmitch> Hobbsee: clicking on the dive into python link from the wiki?
<Hobbsee> hrm, wait.
<Hobbsee> no it doesn't.
<Hobbsee> although copying and pasting the link works fine
 * Awsoonn confirms Hobbsee 
<Awsoonn> on a slightly related note to another project of mine, is it possible to analyse a webcam stream at a pixel level in python?
 * NCommander clicks the StevenK light
 * StevenK ignores it
 * Hobbsee sets NCommander on fire, to create morelight
 * NCommander fights himself
<CarlFK>  sudo apt-get install dvgrab; Reading package lists... Done; Segmentation fault (core dumped)
<CarlFK>  apt-get[11206]: segfault at df21a958 ip b7f765f7 sp bfc2bb20 error 4 in libapt-pkg-libc6.8-6.so.4.6.0[b7f40000+bf000]
<CarlFK> that was on a 12 hour old ibex box
<TheMuso> CarlFK: The only thing I can think of is bad hardware.
<slangasek> CarlFK: is it reproducible?
<slangasek> if not, --> hardware
<CarlFK> well, I hit uparrow, enter, and it happened again.  does that count?
<slangasek> yes; now please give us a backtrace, because such crashes aren't debuggable from just the kernel's segfault log
<CarlFK> slangasek: do I do: $ sudo gdb, or |run sudo apt... in gdb?
<slangasek> CarlFK: sudo gdb
<CarlFK> slangasek: http://dpaste.com/86031/
<slangasek> CarlFK: please file a bug on apt; you'll probably need to provide a copy of /var/lib/apt/lists - this problem isn't reproducible for me
<CarlFK> slangasek: is this the same bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/111934
<ubottu> Launchpad bug 111934 in apt "crash in pkgDepCache::CheckDep" [Undecided,Invalid]
<slangasek> it might be, but it's not possible to say for certain without debugging symbols
<CarlFK> how ironic: $ apt-get source apt; Reading package lists... Done; Segmentation fault (core dumped)
<CarlFK> um, does apt-get source apt give me a source that will have debuging symbols? line 31 of rules is export CXXFLAGS = -O0 -g -Wall   whole file: http://dpaste.com/86032/
<icanhas> pitti: do you really have a fan club?
<TheMuso> CarlFK: You can install debugging symbols from ddebs.ubuntu.com I think it is.
<CarlFK> TheMuso: put that in sources.list and apt-get what?
<TheMuso> CarlFK: Can't remember. Its on the wiki somewhere.
<TheMuso> CarlFK: I just remembered that repo existed.
<CarlFK> wow, google only has one hit
<StevenK> Given his apt crashes, he probably can't apt-get install debugging libraries
<CarlFK> hmm
<CarlFK> good point (which I already confirmed, then forgot )
<CarlFK> wget and dpkg might help
<CarlFK> http://ddebs.ubuntu.com/pool/main/a/apt/  do I want a .ddeb?
<persia> CarlFK, The ddeb contains the symbols stripped from the binary at compile time on the buildd.  IF you're building locally, just pass DEB_BUILD_OPTIONS="nostrip"
<calc> what is the cd test channel?
<persia> calc, #ubuntu-testing includes image testing
<calc> ok
<EvanCarroll> anyone use vimperator extention for firefox?
<persia> EvanCarroll, You may be interested in Bug #286225
<ubottu> Launchpad bug 286225 in vimperator "[intrepid] iceweasel-vimperator: Depends: iceweasel (>= 3.0~) but it is not instalable" [Undecided,Confirmed] https://launchpad.net/bugs/286225
<EvanCarroll> persia: no, I'm not using the deb for the install
<EvanCarroll> I'm using the xpi
<persia> EvanCarroll, Ah.  In that case, I suspect you'll do better to contact the vimperator devs directly.
<EvanCarroll> it just broke today I've been syncing with Ibex daily.
<CarlFK> slangasek: http://dpaste.com/86056/
<CarlFK> 124	../build/include/apt-pkg/cacheiterators.h: No such file or directory.
<CarlFK> help...
<slangasek> CarlFK: you have the debugging symbols, which is what's important.  Please get the output of 'bt full' and file a bug report against apt with that information
<CarlFK> yay.  thanks
<slangasek> I can't do much to help you directly with the bug, I'm not an apt developer and I'm rather tied up with the release candidate preparation right now
<CarlFK> no problem - I can work around it easy enough -
<EruditeHermit> hey, will the UDS at googleplex in December be open to all or do you need a pass to attend?
<persia> EruditeHermit, Should be open to all, although there may be passes issued if complex security requires it.  Just register your attendance in Launchpad to make sure you're on the list.
<EruditeHermit> persia: I can register even if I am not an Ubuntu developer?
<EruditeHermit> persia: and if I am unable to attend for any reason, it doesn't matter right?
<persia> EruditeHermit, Sure, if you're going to be there.
<EruditeHermit> most likely
<persia> If you aren't able to attend, please unregister, as it helps with planning space, etc.
<EruditeHermit> ok
<CarlFK> and food count :)
<calc> ugh fosscamp yet another thing that needs openid :)
<dholbach> good morning
<bryce> heya dholbach
<dholbach> hi bryce
<slangasek> morning
 * Koon wonders if his morning is the same as slangasek's
<Koon> good morning :)
<Mithrandir> slangasek: you in london, or just very confused, tz-wise?
<slangasek> Mithrandir: "it's always morning somewhere"
<slangasek> I was replying to dholbach's greeting, really :)
<Treenaks> slangasek: it's always _Friday_ somewhere! :)
<slangasek> but: good morning, all!
 * dholbach hugs slangasek
<slangasek> Treenaks: you're weird
<slangasek> :-)
<Treenaks> slangasek: thanks :)
<persia> Treenaks, It's only Friday about 29% of the time.
<Treenaks> persia: wait.. we're still only on one planet? :)
<persia> Treenaks, unfortunately.  Please fix.
<\sh> hmmm
<\sh> dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed.
<\sh> Aborted (core dumped)
<\sh> did anybody see this with latest apt-get failing for some reason and a dpkg --configure -a afterwards?
<Mirv> I wonder if anyone besides asac could put the simple i18n fix in at bug 286421? I'd just be hoping the menu item would have time to get translated for the release.
<ubottu> Launchpad bug 286421 in network-manager-applet "[8.10] nm-connection-editor menu item untranslatable" [Undecided,Triaged] https://launchpad.net/bugs/286421
<lool> morning
<stgraber> hi lool
<dholbach> does anybody know how to change tags in Ogg Videos?
<slangasek> I think I change them with exfalso :)
<StevenK> Yay, exfalso
 * dholbach tries it
<dholbach> exfalso did not work for me
<dholbach> I used python-mutagen
<slangasek> huh, ok
<slangasek> fwiw, exfalso depends on python-mutagen
<dholbach> Traceback (most recent call last):
<dholbach>   File "/usr/share/quodlibet/formats/__init__.py", line 52, in MusicFile
<dholbach>     return _infos[ext](filename)
<dholbach>   File "/usr/share/quodlibet/formats/xiph.py", line 151, in info
<dholbach>     raise IOError("file type could not be determined")
<dholbach> IOError: file type could not be determined
<dholbach> :)
<slangasek> neat
<dholbach> that was when I renamed the .ogv to .ogg (it would not show up when I used .ogv)
<lool> Theoritically you can do it in rhythmbox in the properties of a song, but it depends of installed plugins and open bugs :)
<lool> oh videos
<lool> Banshee supports videos, but dunno whether it allows editing their tags
<slangasek> oh, right, it was a video file; yeah, quodlibet was only ever written to handle audio
<dholbach> nevermind - mutagen saved the world again :)
<tjaalton> slangasek: is it possible to roll new images for the "unsupported" archs post-release?
<slangasek> tjaalton: generally, no.  It's not impossible, but we're not going to want to spend a lot of time chasing fixes for archs that weren't ready at release time
<tjaalton> slangasek: ok, there's bug 281610 which only affects big-endian archs and is being debugged with upstream..
<ubottu> Launchpad bug 281610 in ubuntu-ps3-port "[regression, intrepid] Xorg servers broken "No core keyboard" and "failed to initialize core devices"" [Critical,In progress] https://launchpad.net/bugs/281610
<tjaalton> slangasek: hopefully a fix is ready by the weekend
<lool> Are intrepid-updates open?
<slangasek> no
<seb128> slangasek: hi, what is the best way to put "to be synced on debian" updates on your list? I think doing a sync would bypass the queue
<seb128> slangasek: http://packages.qa.debian.org/g/gstreamer0.10/news/20081022T071707Z.html for example
<dholbach> seb128: I just reviewed the vinagre and gnome-applets updates
<seb128> dholbach: thanks
<seb128> dholbach: reviewed or uploaded? ;-)
<dholbach> just so you do them as well :)
<dholbach> in the process of uploading
<seb128> dholbach: "don't", right? ;-)
<dholbach> doing ubuntu-docs now too
<dholbach> seb128: right :)
<seb128> dholbach: danke!
 * seb128 hugs dholbach
<pitti> Good morning
<StevenK> Morning pitti
<seb128> hey pitti
<seb128> pitti: good catch on the f-spot issue ;-)
<slangasek> seb128: file bug, subscribe ubuntu-archive, tell StevenK not to accept it without me looking at it first? :)
<pitti> seb128: hey Seb
<pitti> seb128: I just asked the right questions :)
<pitti> seb128: ah, pity; seems that f-spot didn't make it for the current rebuild :(
<seb128> pitti: right it's in the queue
<pitti> but well, will be in final at least
<StevenK> slangasek: I've not done any accepts off my own bat.
<seb128> yet
<seb128> ;-)
<slangasek> heh
<seb128> slangasek: the desktop images are being rebuilt?
<slangasek> yes
<slangasek> they were meant to be done by now, but I'm stalled until IS can kill a hung livefs job for me
<cjwatson> lool: it's possible to upload to intrepid-proposed, but the upload will be held until intrepid is out
<lool> Ok; that's what I wanted to know, thanks
<cjwatson> slangasek: how long has that been stalled, and whom have you asked so far?
<pitti> lool: thanks for your libvisual/elisa uploads
<pitti> lool: I was a bit scared first, since libvisual changelog doesn't mention dropping jack, but component-mismatches doesn't mention jack any more
<lool> pitti: Did you expect me to write a formal MIR for libvisual-plugins, or are the comments on IRC enought to promote it?
<slangasek> cjwatson: noticed it was a problem ~1h ago, pinged IS on IRC and was working on other things; just about to ring elmo
<lool> pitti: libvisual changelog doesn't mention dropping jack?  you mean the upstream changelog?
<pitti> lool: no wiki page, but a bug report would be good, together with your recommendation (you are ~ubuntu-mir now, too :) )
<pitti> lool: no, debian/changelog
<cjwatson> slangasek: ok, ringing or SMSing elmo sounds reasonable about now
<cjwatson> and is what I was going to suggest ;)
<lool> pitti: I did mention it in 0.4.0.dfsg.1-2ubuntu1!?
<lool>   * Drop libjack0.100.0-dev bdep as even if it's detected correctly by the
<lool>     upstream configure.ac, the list of input plugins to build is reset later
<lool>     in this file.  Incidentally, this allows promoting libvisual-plugins to
<lool>     main in Ubuntu without promoting jack.
<lool> pitti: Will file bug
<pitti> lool: wasn't in https://lists.ubuntu.com/archives/intrepid-changes/2008-October/009191.html
<lool> pitti: I see; I uploaded ubuntu1, 2, and 3, but only 3 was accepted and saw you could only see the changes from -3
<lool> pitti: Full changes listed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503018#5
<ubottu> Debian bug 503018 in libvisual-plugins "watch file" [Wishlist,Open]
<lool> pitti: #287409
<lool> slangasek: I don't know how high #281610 is on your radar, but you should be made aware that it breaks Xorg for many ports (ppc, sparc, hppa at least); not sure how useful it is to release live RC images for these arches with this bug in place
<slangasek> yep, tjaalton brought it to my attention
<tjaalton> lool: it's updated, I'll fire up my PS3 tonight and try to debug it unless Dan beats me to it
<slangasek> I think we'll probably skip releasing RC images for the ports because of that bug, they don't get formal testing on our test matrix anyway
<lool> tjaalton: I think RC is tomorrow AIUI
<slangasek> so we either will or won't get testing feedback from the dailies
<tjaalton> lool: it is, so it won't make it to RC
<seb128> mvo: bug #273930 is the oosplash bug I was speaking about before
<ubottu> Bug 273930 on http://launchpad.net/bugs/273930 is private
<pitti> seb128: hm, opening the intrepid iso with "archive mounter" isn't happy; it just hangs nautilus
<seb128> pitti: stacktrace?
<seb128> oh oh, just crashes nautilus trying on the hardy iso
<pitti> does CD image writing work through nautilus-cd-burner for anyone else? for me it just immediately says "error writing to the device"; direct cdrecord works fine
<seb128> pitti: I did burn isos this way yesterday, didn't try yet today
<pitti> seb128: shouldn't have changed
<seb128> pitti: is that on the livecd or on an installed system?
<pitti> seb128: installed system
<pitti> oh
<seb128> pitti: gconf-editor, apps, nautilus-cd-burner, enable debug and run nautilus-cd-burner --source-iso=iso on a command line?
<pitti> seb128: I used a very old medium which just can do 4x speed
<pitti> seb128: and I selected 11x in n-c-b
<pitti> that might be it
<pitti> seb128: will do that for the next image I'll burn, thank you!
<pitti> oh, burnproof is disabled by default
<seb128> pitti: no it's not
<seb128> pitti: nautilus-cd-burner automatically does burnproof when recording non audio cds, the key is there to force the behaviour for other the library and on audio cds
<pitti> ah
<seb128> pitti: <pitti> seb128: hm, opening the intrepid iso with "archive mounter" isn't happy; it just hangs nautilus
<seb128> pitti: are you sure it didn't crash rather?
<seb128> pitti: ie, got stucked while apport was working
<pitti> seb128: I do have a crash report, /me looks at it
<seb128> pitti: it's likely http://bugzilla.gnome.org/show_bug.cgi?id=547468
<ubottu> Gnome bug 547468 in GIO "crash in Home Folder:" [Critical,New]
<seb128> pitti: or bug #259343
<ubottu> Launchpad bug 259343 in nautilus "nautilus crashed with SIGSEGV in g_str_hash(), mounting ISO" [Unknown,Confirmed] https://launchpad.net/bugs/259343
<smurf> pitti: bug #283316 is not a problem with opening the CDROM
<ubottu> Launchpad bug 283316 in linux "opening /dev/scd0 causes tray to be closed" [Unknown,Confirmed] https://launchpad.net/bugs/283316
<smurf> opening with O_NDELAY set doesn't close tray; AFAIK that's what HAL does for all devices
<pitti> smurf: oh, thanks for pointing out; I'll do that in my test script
<pitti> seb128: I filed it as bug 287419
<ubottu> Bug 287419 on http://launchpad.net/bugs/287419 is private
<pitti> seb128: unusable stack trace, I'll wait for the retracer and then compare
<seb128> pitti: what arch do you use?
<pitti> seb128: i386
<seb128> pitti: ok
<smurf> pitti: I have restored the original bug titles
<pitti> smurf: I'm debugging it further now; with O_NONBLOCK and the ioctl it doesn't open either
<pitti> smurf: I build a debuggin hal version now and gdb through the addon
<smurf> pitti: Maybe the ioctl closes the tray when some other process opened it without O_NDELAY afterwards?
<smurf> pitti: anyway you mean s/open/close ;-)
<slangasek> mvo: hi, could you mark feisty obsolete in meta-release please?
<mvo> slangasek: sure, will do
<yao_ziyuan1> i lost chinese input on gnome and kde4 deskotps yesterday
<yao_ziyuan1> i use ubuntu 8.10 + kde4
<realist> How *not* to report a bug.
<Hobbsee> realist: we keep telling him that, and he never learns.
<jdahlin> libtool 2.2.4 on intrepid breaks quite a bit of software, is there a plan to downgrade, or at least provide 1.5 packages?
<StevenK> Such as?
<jdahlin> afaik gnome libraries (glib for instance)
<StevenK> libglib2.0 in the archive built with it
<seb128> jdahlin: talk to Keybuk, but what about fixing upstream to be compatible with the current tools?
<jdahlin> well, glib itself parses .la files, these parts are no longer working properly
<slangasek> eh? why does glib parse .la files?
<jdahlin> g_module_open is a dlopen wrapper, it's useful for it to work without having to install libraries
<Keybuk> so glib hasn't been updated?
<jdahlin> apparently not
<Keybuk> someone should do that ;)
<slangasek> sigh.  if it's useful for it to work without having to install libraries, why is it wrapping dlopen instead of libltdl? :(
<Keybuk> slangasek: indeed
<jdahlin> Keybuk, do you have an idea why shrext_cmd in libtool --config is set to an empty string?
<jdahlin> *shrext_cmds
<Keybuk> it isn't
<Keybuk> # Shared library suffix (normally ".so").
<Keybuk> shrext_cmds=".so"
<jdahlin> it is on the copy of libtool in my source tree
<Keybuk> libtoolize issue?
<jdahlin> no idea
<Keybuk> gnome's autogen has a bug where it manages to get it utterly wrong
<jdahlin> oh?
<Keybuk> assumedly "they wanted it to work without having to use the perfectly good tool already available to do it"
<Keybuk> run "autoreconf -v -i -f" on your tree
<Keybuk> and configure again
<slangasek> Keybuk: pssh, now you're making them sound like Qt
<jdahlin> Keybuk, doesn't change anything.
<jdahlin> Oh, perhaps this is only because I haven't removed all *.la files on my system yet
<Keybuk> jdahlin: you don't need to remove .la files
<jdahlin> Keybuk, I do, they tend to break builds
<Keybuk> no, they don't
<Keybuk> they fail because the build is wrong
<Keybuk> but most people disagree that it's wron
<Keybuk> on Linux, libtool replicates a build failure that happens on things like Solaris
<Keybuk> so people remove .la files blindly believing it to be stupid
<jdahlin> I don't care about Solaris
<jdahlin> If someone wants to port my software to other OS, it's up to them to fix it, not me
<Keybuk> your package is likely failing because you have mixed pieces of both libtool 2.2 and libtool 1.5 in your source tree
<slangasek> I remove them with my eyes open, believing that replicating Solaris build failures is stupid
<slangasek> :P
<Keybuk> slangasek: but you cause build failures with static libraries as a result :-/
<Keybuk> pkg-config does alleviate this pain of course
<jdahlin> who cares about static libraries?
<slangasek> ^^ what he said :-)
<Keybuk> slangasek: we stills ship them :)
<pitti> smurf: bugs updated again (primary discussion now in the upstream bug)
<smurf> pitti: thanks, that looks like it's going to be some work to figure out
<pitti> smurf: yeah :/
<smurf> pitti: if you need a fast machine for bisecting the kernel, I can probably help
<smurf> I can't do it myself, right now I only have one computer in the office and I need that for actual paying work :-/
<pitti> smurf: I need to find some time to do the same test case on earlier kernels, indeed
<pitti> but probably not this week, too much release stuff going on
<pitti> smurf: but building my stripped down monolithic kernel takes like 5 minutes, that's not a problem
<pitti> downloading them takes more :)
<mok0> Is there a tutorial for using LP for packaging somewhere?
<mok0> (including managing upstream sources)
<pitti> seb128: hm, n-c-b works now; seems to have been a /dev/scd0 permission glitch
<doko> after kernel upgrade my X61 doesn't boot anymore, hangs in "Checking battery state ..:"
<heno> eeek
<heno> doko: anything here that looks suspicious: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/285779/comments/4 ?
<ubottu> Launchpad bug 285779 in linux "XFS Barrier support broken in 2.6.27" [High,Fix released]
<doko> my, works after a power off
<heno> *** new RC-candidate ISO images posted with updated kernel - please help test! ***
<pitti> heno: hm, still 20081022, or even newer ones/
<pitti> ?
<pitti> I just finished burning
<slangasek> Riddell: request for https://wiki.kubuntu.org/IntrepidIbex/RC/Kubuntu for me to link from the announcement
<slangasek> pitti: those are the ones
<heno> *** image links and reporting on http://iso.qa.ubuntu.com - coordination in #ubuntu-testing ***
<slangasek> cody-somerville: request for https://wiki.ubuntu.com/IntrepidIbex/RC/Xubuntu for me to link from the announcement mail
<Riddell> slangasek: will do
<slangasek> superm1: request for http://mythbuntu.org/8.10/rc for me to link from the announcement mail :)
<heno> pitti: the last desktop ones are just trickling in
<heno> 20081022
<heno> pitti: the message wasn't really targeted at people like you who are ahead of the game ;)
<pitti> heh, *phew*
<cody-somerville> slangasek, preparing
<tseliot> slangasek: is it better now? https://wiki.ubuntu.com/IntrepidReleaseNotes#nVidia%20%22legacy%22%20video%20support
<cody-somerville> slangasek, is https://wiki.ubuntu.com/IntrepidIbex/RC/Xubuntu suppose to be release notes or release announcement?
<cody-somerville> or I guess what you're now calling "TechnicalOverview"
<slangasek> cody-somerville: whatever you want me to link to from the ubuntu-announce release announcement; it would parallel the TechnicalOverview, yes
<slangasek> tseliot: looking
<smurf> pitti: Hmm, I'm afraid that when this problem seriously shreds somebody's CD (or finger), this bug is going to be RC in a hurry. :-/  I hope that I can dig up some free time myself this week, but no promises unfortunately
<pitti> smurf: at the very least it will become an early SRU, yes
<slangasek> tseliot: hmm, linking to wikipedia - I'll have to clear that with the webmaster, but it looks better to me, yes :)
<tseliot> slangasek: yes, I thought that if users want further information they could look up SSE on wikipedia
<pitti> on mounting kvm images> losetup /dev/loop0 test.img works fine, and fdisk -l /dev/loop0 shows me partitions; is there any way I can actually get things like /dev/loop0p1 to get to the partitions?
<pitti> kirkland: ^ maybe you know?
<wgrant> slangasek: Is somebody going to fix the "GNOME Logout Applet" section in the release notes soon?
<slangasek> tseliot: what does update-manager do if the CPU /doesn't/ support SSE?  Refuse to upgrade?  Migrate them to nv?
<slangasek> wgrant: release-noting is definitely on my agenda for the morning
<tseliot> slangasek: it should display a warning about the fact that the nvidia driver won't work and, if users accept to proceed with the installation, Update Manager will use the "nv" driver
<wgrant> slangasek: Just checking that it hadn't been somehow overlooked, as other parts have changed.
<slangasek> tseliot: I've adjusted the section now in a way that I think is more logical; does it look ok to you still?
<tseliot> slangasek: it looks good to me
<slangasek> tseliot: great, thanks
<tseliot> you're welcome
<slangasek> ogra: I've opened a release notes task for bug #282203; you talked about having users provide feedback to help generate correct fdi files for jaunty - could you write a brief explanation of this for release notes inclusion, possibly with a pointer to the wiki for more detail?
<ubottu> Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Medium,Fix released] https://launchpad.net/bugs/282203
<Keybuk> evand: aiiieeee make the timezone selector STOP!!! arrrrgh
<ogra> slangasek, will do, i was also planning a howto for creating your own .fdi files but that howto wont happen this week
<slangasek> ogra: understandable - we shouldn't include the whole howto in the release notes anyway :), but maybe that's part of what we link to
<ogra> right
<slangasek> Keybuk: I thought he did make it stop?
<ogra> i would like to provide a link there
<Keybuk> there should be a secret key combination in the live cd X server that displays the disk info on screen
<slangasek> ogra: assigned the task to you; if you can't get to it today, kick it back to me and I'll put in a placeholder for RC
<ogra> ok
<tseliot> Riddell: do you know of any kde apps which have to be launched with root privileges (apart from jockey)?
<pitti> StevenK: can you give me a list of the main->universe source/binary demotions which you'd want to keep in main for mobile? http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<StevenK> pitti: hildon-control-panel*, libfakekey, libhildonhelp, libxsettings, maemo-af-desktop*, matchbox-keyboard, midbrowser, osso-af-settings, python-hildon and tasks
<Riddell> tseliot: adept
<pitti> StevenK: libxsettings is only needed by libmatchbox and matchbox-window-manager, both of which are in universe
<tseliot> Riddell: but doesn't that acquire root privileges after it's launched?
<StevenK> pitti: Then drop it from that list
<Riddell> tseliot: the whole app runs as root
<liw> er, um: https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/287225 -- "Uses Windows conventions for file types". of all the things I imagined people would complain about system-cleaner, that was not one of them
<ubottu> Launchpad bug 287225 in system-cleaner "Uses Windows conventions for file types" [Undecided,New]
<tseliot> Riddell: hmm... ok maybe I confused it with the system updater
<pitti> StevenK: thanks; I demoted the rest
<Riddell> tseliot: /usr/share/applications/kde4/adept-manager.desktop
<pitti> Riddell: demoting arts binary to universe is okay? kdelibs4c2a still depends on the library, but nothing pulls in arts any more
<Riddell> tseliot: which has X-KDE-SubstituteUID=true
<pitti> Riddell: or should it be seeded?
<Riddell> pitti: hmm
<Riddell> pitti: arts package itself is empty, I can put it in supported
<tseliot> Riddell: yes, I tried "X-KDE-SubstituteUID=true" but it doesn't seem to help with jockey. I have noticed that we jockey is launched by autostart and its icon shows up in the system tray I can click on that icon and jockey works well
<pitti> Riddell: hm, it doesn't look that useful; well, your call
<Riddell> tseliot: that's because pitti made it run through /usr/lib/kde4/libexec/kdesu
<pitti> tseliot, Riddell: but that's not due to the desktop file
<pitti> if you want to run it as root right from the start, I assume you have to add kdesudo to the Exec= in the .desktop? or should X-KDE-Subst be enough?
<Riddell> right from the start being when you start it from the applications menu?
<Riddell> X-KDE-SubstituteUID=true should do that
<tseliot> Riddell: where is the script/or source of the daemon which launches all the scripts in autostart in kde?
<Riddell> tseliot: what are you wanting to autostart?
<Riddell> I think it's ksmserver which does the autostart stuff
<tseliot> Riddell: I would like to know whether the autostarter has root privileges or not
<Riddell> it doesn't
<tseliot> as calling jockey with kdesu doesn't seem to solve the problem
<tseliot> hmm...
<Riddell> mvo: incomplete-language-support-qt.note seems broken, is that on the radar?
<james_w> could an archive admin please reject gambas2 from unapproved? The amd64 build is being done for the existing package on the LP side.
<mvo> Riddell: could you make me a screenshot?
<slangasek> james_w: done
<james_w> thanks slangasek
<pitti> james_w: done
<pitti> oh
<slangasek> :)
<james_w> nice try pitti :-)
<pitti> "FAILED: gambas2 (Queue item already rejected)"
<pitti> heh
<pitti> "FAILED: You are too slow!"
<tseliot> Riddell, pitti: problem solved :-)
<Riddell> tseliot: ooh?
<tseliot> Riddell, pitti: I only had to add TryExec=jockey-kde to the desktop file (in addition to X-KDE-SubstituteUID=true)
<pitti> oh, what does that do?
<tseliot> it doesn't work without the TryExec
<Riddell> aah
<Riddell> pitti: makes it work :)
<mvo> Riddell: cjwatson fixed some breakage in the note the other day
<tseliot> Riddell: yes, definitely :-P
<Riddell> mvo: all the translations are on one line
<tseliot> pitti: shall I commit/push this change?
<pitti> tseliot: please
<pitti> tseliot: (to trunk)
<pitti> tseliot: also, there is still the "jockey-kde doesn't install wl" issue, right?
<cjwatson> Riddell: that should be fixed if you upgrade ...?
<cjwatson> I'm pretty sure I fixed incomplete-language-support-qt.note as well
<tseliot> pitti: I'll test that too
<cjwatson> $ deb-extract-file /mirror/ubuntu/pool/main/l/language-selector/language-selector-qt_0.3.15_all.deb ./usr/share/language-support/incomplete-language-support-qt.note | grep ^Name | head -n3
<cjwatson> Name: Incomplete Language Support
<cjwatson> Name-ast.UTF-8: Sofitu a llingua incompletu
<cjwatson> Name-ca.UTF-8: Suport d'idioma incomplet
<Riddell> cjwatson: yep, that sorts it, thanks
<cjwatson> it's still an intltool/intltool-debian bug but I haven't had time to file that
<mvo> cjwatson: I can reproduce the language-selector problem you mentioned, its indeed because the package list is not updated. I can add code that detcts that and presents a dialog, but it will break the string freeze
<cody-somerville> slangasek, https://wiki.ubuntu.com/IntrepidIbex/RC/Xubuntu
<slangasek> cody-somerville: looks good to me: )
<cjwatson> mvo: maybe that's worth it given that the change is for improved translation in general
<mvo> cjwatson: fine with me, I work on the code then
<cjwatson> thanks
<ogra> hmm, is seb128 off today ?
<ogra> heh, speaking of the devil
<ogra> seb128, hey ... i have a slight themeing prob with the shutdown dialog
<mvo> Riddell: what do you thiink about a session at uds about langauge-selector ? like making the delta between the fontends smaller (e.g. verifyInstalledLangPacks should really be in common code) - we oculd also discuss a dbus/PK infrastrure, I have some code that make it all nicer with dbus
<Riddell> mvo: sounds good
<seb128> ogra: is that me that you call devil? that's an error ;-)
<ogra> seb128, is that the original upstream one or do we use any patches for the suspend and hibernate items ?
<ogra> seb128, we all know youre an angel :)
<seb128> ah ah, not quite either ;-)
<seb128> anyway
<seb128> ogra: I guess bug #274889 is your issue
<ubottu> Launchpad bug 274889 in gnome-session "the new session dialog should use other icon names" [Low,Incomplete] https://launchpad.net/bugs/274889
<ogra> seems if i use the gnome icon theme (which we do in mobile because human doesnt scale properly on the panel) i end up with the missing icon for suspend
 * ogra reads
<ogra> seb128, yeah, looks like it
<seb128> ogra: ok, it's late to change the naming now for intrepid though and there is no better suggestion
<seb128> ogra: vuntz added the icon they are using in opensuse to the upstream bug, that could be shipped in gnome-session or something though
<ogra> that would be good
<ogra> else i could ship a link to the gpm icon in ubuntu-mobile-default-settings but that would only be an ugly workaround
<pitti> cjwatson: I uploaded a new mail-spf-perl which gets rid of three more perl modules in c-m; all the remaining ones are just due to the po-debconf recommends; unfortunately its failure mode isn't very good; if I'd fix that to say "You need to install libmail-box-perl for this program to work", would you consider that as sufficient?
<cjwatson> pitti: I thought it already did
<cjwatson>                 die "The --postpone and --mutt options require the ".
<cjwatson>                     "perl Mail::Box package. Please install the Debian ".
<cjwatson>                     "libmail-box-perl package if you want to use these ".
<cjwatson>                     "options. No mail written or sent.";
<pitti> ah
<pitti> if you just call it, it says "Can't locate Mail/Box/Manager.pm in @INC"
<cjwatson> weird
<pitti> cjwatson: where do you see that?
<cjwatson> podebconf-report-po line 1160
<pitti> cjwatson: --help aborts with that perl error, and it's not in the manpage
<cjwatson> oh, meh, that 'use' is wrong
<pitti> does the eval {require} already import it?
<cjwatson> use Mail::Box::Manager => import Mail::Box::Manager, I suspect
<cjwatson> use compiles to BEGIN { require; import } basically
<cjwatson> and it's not wrapped in eval or anything so that bypasses the conditional
 * pitti tests
<pitti> cjwatson: that works for the uninstalled case, but I still get lots of errors
<pitti> cjwatson: anyway, I'll look at that further, thanks
<pitti> ah, touching the folder helps, works now
<pitti> cjwatson: ok, I'll send that fix to Debian and upload with the recommends dropped
<cjwatson> cool, thanks
<james_w> "Please use the interactive user interface to use action edit!"
<Hobbsee> tseliot: not sure if anyone's talked to you over this, but have you seen 228649 and 239115?
<tseliot> Hobbsee: let me have a look
<Hobbsee> tseliot: if they're not valid anymore, etc, please mark them as such :)  Thanks
<tseliot> Hobbsee: I've marked them as invalid since those packages are no longer available in intrepid
<Hobbsee> tseliot: sweet, thankyou :)
<tseliot> Hobbsee: you're welcome ;)
 * Hobbsee wonders if anything happened about nvidia 96 drivers, and such
<mvo> cjwatson: hm, on a fresh alternate install (without network) the "deb cdrom:" source is commented out - have you seen this before?
<cjwatson> mvo: that's odd, I'll try it after lunch
<cjwatson> mvo: oh, hang on, no, that's deliberate
<mvo> cjwatson: I'm curious, why is it done that way?
<cjwatson>   * Always disable the CD at the end of installation if no mirrors are
<cjwatson>     present, even if it's a complete CD. These days it's more irritating
<cjwatson>     than not, and inserting the CD on a desktop system will produce a prompt
<cjwatson>     anyway.
<cjwatson> apt-setup 1:0.31ubuntu1
<mvo> aha, ok
<cjwatson> that should actually have read "if any mirrors are present", I think
<wgrant> Oh, good. That has been annoying me for years.
 * pitti reads server team meeting notes and hugs frozen bubble
 * mathiaz points pitti to zul - he started everything!
<james_w> do you install frozen bubble by default on server installs?
<pitti> mathiaz: anyway, does it have a libaa backend for ssh ?
<mathiaz> james_w: yes - but shussh... it's an easter egg
<liw> pitti, if you ask me, Frozen Bubble should be removed from Ubuntu, and all developers should be required to run a kernel that prevents it from becoming installed
<Treenaks> liw: what about moon-buggy?
<liw> pitti, it's too addictive...
<pitti> liw: then you need to remove dosbox, too
<zul> frozen bubble is just too addictive and must be removed
<pitti> heno, all: Ubuntu DVD RC images now available and added to the tracker
 * pitti stomps on zul's feet
<sivang> pitti: frozen bubble in server team meeting notes? :)
<heno> zul: I'll trade it for the expert install I'm just starting ;)
 * zul goes file a launchpad report
<heno> pitti: thanks
<qah> Hello. Is anyone there?
<qah> Oh. I think I have the wrong chat anyways. :)
<Hobbsee> liw: why does system-cleaner install with no icon?
<liw> Hobbsee, because nobody has made an icon
<Hobbsee> liw: oh :(
<Hobbsee> liw: tried emailing the ubuntu-artwork list or something asking someone to make one?
<liw> Hobbsee, yes
<Hobbsee> oh
<Hobbsee> no dice, apparently.
<cody-somerville> Hobbsee, just open up gimp :P
<liw> (I don't intend to spend a lot of effort on an icon that I don't think is in any way important, though)
<Hobbsee> liw: tha't strue.  it might just be ncie to have.
<Hobbsee> cody-somerville: i suck at graphics...
<liw> Hobbsee, on the other hand, people asking me about the icon about a dozen times a day is becoming to motivate me
<Hobbsee> liw: hehe, sorry :)
<liw> Hobbsee, for whatever reason, people care less about having all their kernels removed than about the icon ;-)
<Hobbsee> haha
<Hobbsee> that's true
<directhex> kernels are overrated. art is all about first impressions!
<broonie> If you make their system unbootable they won't eb able to get online to complain.
<liw> broonie, they will just use a live cd
<liw> broonie, to file a bug that THERE WAS NO ICON for removing kernels, obviously :)
<liw> more seriously, I hope to have _something_ as an icon for the next upload
<liw> also, not removing quite so many kernels
<Hobbsee> liw: attempting to poke around
<Mirv> cjwatson: I don't know if you tested the fix for bug 287046, but while it does include all the translations besides fixing the original problem, the translations aren't actually shown because of some probably small glitch. installed from today's daily which has 0.3.15.
<ubottu> Launchpad bug 287046 in language-selector "interactive upgrade hooks description shows all translations" [High,Fix released] https://launchpad.net/bugs/287046
<Mirv> (s/tested/tested in non-English/)
<jdong> there's a debdiff and about 5 whiny people on bug 274844... release folks, is there an opportunity to fix this before release or shall we wait for SRU?
<ubottu> Launchpad bug 274844 in transmission "transmission crashed with SIGSEGV in g_markup_escape_text()" [Unknown,Fix released] https://launchpad.net/bugs/274844
<jdong> (the patch looks slightly hairy, it's a minor rewrite of a tooltip-popping routine)
<bluefoxicy> Here's a thought
<bluefoxicy> When Ubuntu goes into official beta, most packages are stable, right?
<bluefoxicy> i.e. not much is realistically going to change by release (in 8 days)
<Hobbsee> RC, you mean?
<Hobbsee> and we hope not
<bluefoxicy> how about update-manager having a setting to fetch information about an upcoming release, and X days before release begin downloading the packages
<pitti> -- intrepid/main build deps on xscreensaver:
<cjwatson> Mirv: I wasn't able to test it all the way through, no
<pitti> kdeartwork
<pitti> o_O
<cjwatson> Mirv: sounds like a new bug though
<bluefoxicy> that way on release day it can say, "Hey!  New version!  :D  Want to install?"  YES and no download
<mvo> cjwatson: a first draft for the language-selector text: http://paste.ubuntu.com/60994/ - review welcome :)
<cjwatson> Mirv: I'm reasonably confident that the actual .note file in language-selector is in the right format now
<Hobbsee> pitti: what about it?
<cjwatson> bluefoxicy: an absolute buttload changes between beta and release
<bluefoxicy> (Possibly this is better if there's bittorrent based package distribution)
<cjwatson> look at intrepid-changes ...
<bluefoxicy> cjwatson:  hm. Nods.  So not so great?
<cjwatson> mvo: looks fine
<pitti> Hobbsee: it's the only thing that keeps xscreensaver in main, and it doesn't sound like something a package wouldneed to buid-depend on
<Hobbsee> pitti: ahhh.  Now, iirc, there was a reason for that.
<cjwatson> bluefoxicy: RC->release not so much changes, but even then it gets a new set of language packs
<pitti> Hobbsee: if we keep it, we also need to promote xli, or drop its recommend:
<cjwatson> bluefoxicy: so I'm a bit sceptical - I'm also concerned that it would ramp up server load right when it's most critical for us to get urgent work done
<bluefoxicy> cjwatson: Yeah, I'm worried about server load, hence the bittorrent comment.  I'm just thinking about last time I upgraded.
<bluefoxicy> it spent 2 days downloading packages.
<cjwatson> bittorrent has not exactly been what you might call an unalloyed success on the server side
<Hobbsee> pitti: from vague memory, i *think* there are no, or very few screensavers, if it's not there.  OTOH, it's not used a lot, as it's not part of kubuntu-desktop.
<cjwatson> the tracker is absolutely horrible to run and it gets worse the more files are involved
<bluefoxicy> damn
<cjwatson> I realise it's good client-side which is why we keep running it
<bluefoxicy> didn't someone develop trackerless bittorrent?
<cjwatson> dunno
<bluefoxicy> there was a big deal made about how they "decentralized" bittorrent
<bluefoxicy> in a special fork
<Hobbsee> pitti: check in #kubuntu-devel though, i'm not sure if it's changed for kde4
<bluefoxicy> and then it went nowhere
<Riddell> pitti: kdeartwork needs to build-dep on xscreensavers so it knows what screensavers exist, it then creates .desktop files for those screensavers so kde can use xscreensavers through its settings
<Hobbsee> there we go
<pitti> Riddell: ah, thanks
<tseliot> Riddell: can you modify the .desktop file of jockey-kde according to what is in the diff (only the lines in green) and see if you can reproduce the problem with the wirless driver? http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/496
<Trewas> bluefoxicy: there's trackerless bittorrent (with two variants even, mainline and azureus)... but no matter how you look at it, bittorrent sucks for distributing lots of small files
<Riddell> tseliot: ok, once this upgrade test is done
<tseliot> ok, thanks
<bluefoxicy> Trewas:  interesting.  My big problem with bittorrent is you can't alter the torrent, i.e. you can't add/remove files to/from it at leisure and have clients update
<pitti> Riddell: my suspicion is that kdesudo kills $XDG_SESSION_COOKIE from the environment, or something like that, which apparently doesn't happen if the .desktop file starts it as root
<Riddell> pitti: what is that needed for?
 * bluefoxicy sets his computer to install the new beta; he runs -proposed, he might as well run an 8-days-from-release candidate.
<mvo> pitti: dosn't sudo do that (clean the environment from everything it does not know about) - or is that key added to the exceptions?
<pitti> Riddell: usually it's the session program's cookie to get PolicyKit privileges f
<pitti> Riddell: I don't really see why you'd need it if the program is already running as root
<Mirv> cjwatson: ok, created a new bug for language-selector (bug 287556)
<ubottu> Launchpad bug 287556 in language-selector "Post-installation note translations not shown" [Undecided,New] https://launchpad.net/bugs/287556
<pitti> Riddell: but maybe PK/CK insist on it, and I don't really see what other difference kdesudo could make
<pitti> mvo: no, it kills it as well
<pitti> mvo: but on Ubuntu we have policykit-gnome, so we don't need to run it as root in the first place
<pitti> so far it's really just one possible explanation
<mvo> cjwatson: I have a look at #287556 next, I'm hacking on l-s anyway right now
<cjwatson> ok
<cjwatson> I sort of suspect it's in update-notifier rather than language-selector but ICBW
<mvo> cjwatson: I kind of suspect that too, but I will double check
<mvo> hm, I wonder why the "details" expander in language-selector is expanded by default
<Mirv> mvo: probably a bug, too. it makes the actual list height very small.
<dholbach> mathiaz: haha :)
<\sh> cjwatson: did you see the behaviour, that the linux-image post-install wants to write the UUID of / into menu.lst instead of /boot UID? I did a reinstall of my system this morning with the latest beta alternate image, and it was unbootable
<dholbach> (re: server team minutes) :)
<cjwatson> \sh: yes, it's fixed
<\sh> cjwatson: cool
<pitti> Kubuntu DVD images available on cdimage and ISO tracker
<cjwatson> \sh: bug 285269
<ubottu> Launchpad bug 285269 in grub "UUID conversion fails to handle separate /boot" [High,Fix released] https://launchpad.net/bugs/285269
<mvo> http://people.ubuntu.com/~mvo/tmp/ls.png
<cjwatson> excellent
<Mirv> mvo: are you that quick?! :)
<\sh> dholbach: at least the hadn't achmed, the dead terrorist in da house...he would have said: "Silence, I'll kill you"..."if you remove bubble" ,-)
<liw> Mirv, yes, he is
<stgraber> mvo: liw told me you could know about: http://www.stgraber.org/download/langpack-notify.png ?
<dholbach> \sh: eh?
<mvo> Mirv: actually I had a debug a crash in python-apt first, otherwise I would have been even quicker .)
<\sh> dholbach: http://www.youtube.com/watch?v=1uwOL4rB-go <- don't you know him? :) great show
<dholbach> no, I guess not
<mvo> stgraber: what version of language-selector is that? could you please check?
<\sh> dholbach: have a look and rotfl. :)
<mvo> Mirv: now I just need to find the bugnumber again :)
<Mirv> mvo: while you are at it, you could possibly even squash also the second part of the bug - ie. it does not check whether support for Default Language is actually installed (second part of bug 135752, first one being this apt-get update)
<ubottu> Launchpad bug 135752 in ubiquity "language packs are not installed if network is not available during install" [Medium,Confirmed] https://launchpad.net/bugs/135752
<Mirv> mvo: well, that's the original bug I just made the other bug duplicate about
<stgraber> mvo: it's today's desktop image, hang on a sec
<stgraber> mvo: 0.3.15
<mvo> stgraber: oh, bad. that was supposed to be fixed
<mvo> oh well
<cjwatson> stgraber: blink
<cjwatson> I *fixed* that in 0.3.15, I'm sure it's fixed in the archive
<Mirv> stgraber/mvo: that's different from the previous bug, the first note that is shown is at least fixed in today's build
<cjwatson> stgraber: quick reproduction path?
<Mirv> cjwatson: it's about reboot, not about language support this time
<cjwatson> oh, hang on, that's a different message
<cjwatson> right
<stgraber> mvo, cjwatson: What I did is: Install OEM in english using the latest Desktop, then in the oem assistant, choose french, open the session and enable the langpack in language-selector (it wasn't installed by the oem assistant)
<cjwatson> I'll go fix it in update-notifier too
<kirkland> pitti: use fdisk when you have the entire disk attached to /dev/loop0 to find out the offset of the partition you want, then use that offset with losetup -o52428800 /dev/loop1 foo.img
<pitti> kirkland: oh, nice, thanks
<pitti> kirkland: it seemed odd to me that kvm images were almost, but not quite, mountable
<kirkland> pitti: :-)
<kirkland> pitti: yeah, the above is slightly klunky
<liw> pitti, you may want to look at kpartx (in package of the same name)
<kirkland> pitti: i wouldn't be surprised if someone in #ubuntu-virt has a better method
<pitti> /dev/loop0p5              37         401     2931831   83  Linux
<kirkland> pitti: but that's worked for me in the past, and i use it infrequently enough that i haven't gone looking for something else
<pitti> kirkland: ^ so for that this would be 37*512 or so?
<kirkland> pitti: exactly
<kirkland> pitti: i just googled and came across this, with a bit more explanation: http://www.docunext.com/blog/2007/07/08/losetup-working-with-raw-disk-images/
<pitti> Units = cylinders of 16065 * 512 = 8225280 bytes
<pitti> hm, maybe not
<kirkland> pitti: what's your units set to?
<liw> kpartx does all the setup automatically, to allow you to mount the partitions in a kvm image (raw image file format)
<stgraber> mvo, cjwatson: Do we have a bug about it or should I file a new one (and if yes, against what package ?) ?
<kirkland> pitti: can you pastebin your fdisk -l for me?
<pitti> kirkland: ah, that article is exactly my problem, too
<pitti> kirkland: http://paste.ubuntu.com/61007/
<pitti> kirkland: I actually just wanted to get two small text files into that kvm instance
<mvo> Riddell: does kubuntu has something list "install-apckage update" ?
<liw> pitti, http://files.liw.fi/temp/qemu-minimize has an example (that might still work) for how to use kpartx
<pitti> kirkland: first I tried to set up the pan0 interface, which didn't actually work, second I tried that "mount image" approach, and when I got stuck at that as well, I just typed the files by hand
<cjwatson> oh, it is in language-selector, I'm just stupid
<cjwatson> stgraber: please file it on language-selector so it can be marked release-critical
<stgraber> ok
<Riddell> mvo: yes, kdesudo install-package --update
<pitti> kirkland: "u" helps, yes; that's much better
<kirkland> pitti: switching the units, cool
<mvo> Riddell: thanks
<Mirv> mvo: 277526 was the Intrepid/High bug about also the lack of apt-get update in l-s, if you need that bug number for changelog.
<pitti> kirkland: hm, except that it doesn't actually work :(
<stgraber> cjwatson: bug 287573
<ubottu> Launchpad bug 287573 in language-selector "Junk in the notification message after installing a new language pack" [Undecided,New] https://launchpad.net/bugs/287573
<cjwatson> thanks
<kirkland> pitti: what format is your disk image?
<kirkland> pitti: raw, qcow or something else?
<cjwatson> stgraber: fixed in bzr
<mvo> Mirv: what is the difference between them? should they be merged?
<cjwatson> sorry for missing that first time round
<mvo> cjwatson: woah, that was *quick*
<cjwatson> I already had it in my tree before he filed it, since we'd been talking about it :)
<stgraber> cjwatson: great, thanks
<mathiaz> cjwatson: I've filed bug 287571 - I don't think it's critical for the RC release. But it may point to a bigger issue.
<ubottu> Launchpad bug 287571 in partman-auto "expert_recipe fails with "Can't have partition outside the disk" message on amd64 while working on i386" [Undecided,New] https://launchpad.net/bugs/287571
<kirkland> pitti: try: kpartx -av /dev/loop0
<pitti> argh, X crashed again
<kirkland> pitti: then look in /dev/mapper
<pitti> kirkland: format> nothing special really, I created it with DD
<pitti> "dd" rather
<cjwatson> mathiaz: thanks, will have a look
<kirkland> pitti: good, that's this simplest case
<kirkland> pitti: i just learned/tested the kpartx method discussed here: http://equivocation.org/node/107
<mvo> Riddell: review of commit "r209" in language-selector would be much appreciated (my qt foo is still not good, but it should be ok)
<kirkland> pitti: it is remarkably simple
<pitti> liw, kirkland: indeed, kpart seems like the very solution to that; thanks for that hint!
<kirkland> pitti: i figured there had to be an easier way that fdisk | bc, but it worked for me ;-)
<pitti> kirkland: hm, the output is promising, but where do these nodes actually appear?
<kirkland> pitti: ls /dev/mapper
<pitti> aah
<kirkland> pitti: i have a loop0p1
<kirkland> pitti: you should be able to mount that
<pitti> for i in  /dev/mapper/loop0p*; do sudo vol_id $i; done
<pitti> \o/
<pitti> splendid
<pitti> kirkland: *hug*
<pitti> that's too good to not blog about it actually
<kirkland> pitti: undo with umount, kpartx -dv, losetup -d
<kirkland> pitti: :-)  go for it
<pitti> kirkland: but you discovered it, do you want to?
<pitti> heh, ok
<kirkland> pitti: it's all you ;-)
<kirkland> pitti: i just read someone else's blog: http://equivocation.org/node/107
<pitti> kirkland: oh, ok; no need to duplicate it then
<kirkland> pitti: i'll blog a pointer to it, how about that?
<pitti> kirkland: sounds good; spread the love :)
<kirkland> pitti: get the planet.ubuntu world over to that link ;-)
<Riddell> mvo: looks good to read over it, how do I test it (how do I make "No language information available")?
<mvo> Riddell: sudo rm /var/lib/apt/lists/* :)
<mvo> Riddell: or just move the files away, less destructive
<mvo> Mirv: hm, I just tested the noticiation thing with german and I got it fully localized - but its no longer a fully fresh install
<Riddell> mvo: works great
<Riddell> bryce: I just got hit by bug 271138, are you going to upload that fix today?
<ubottu> Launchpad bug 271138 in gdm "mouse and keyboard unresponsive when gdm first runs" [Medium,Confirmed] https://launchpad.net/bugs/271138
<davmor2> any ubuntustudio devs here?
<mvo> Mirv: its not translated at all for you (the note)?
<mvo> Mirv: is the header translated? what is the output of "locale" on your system? I will try to reproduce
<Riddell> bryce: actually I don't know if it is that bug, I have evdev installed
<tseliot> Riddell: can I see your xorg.conf and your /var/log/Xorg.0.log ?
<NCommander> seb128, good morning
<seb128> hello NCommander
<NCommander> seb128, how goes your day?
<tkamppeter> Riddell, hi
<seb128> NCommander: ok, doing intrepid rc testing and some GNOME updates
<seb128> NCommander: how is yours?
<Riddell> tseliot: http://muse.19inch.net/~jr/tmp/xorg/
<Riddell> tkamppeter: hi
<NCommander> seb128, attacking my inbox, getting ready for the Xubuntu RC testing, and then attending a memorial service
<tkamppeter> Riddell, can you add yourself as bug contact for system-config-printer-kde? You have written it, so for you it should be easiest to fix bugs in it.
<Riddell> tkamppeter: "Subscribe to bug mail"?
<tkamppeter> Riddell, I think so.
 * ogra curses evo ... its the third time i have to supply my password today 
<tkamppeter> Then I do not need to subscribe you to every appearing bug any more.
<Riddell> tkamppeter: I've subscribed me and kubuntu-bugs
<tkamppeter> Riddell, OK, thank you.
<tseliot> Riddell: your xorg.conf looks good. It might be the same bug
<tseliot> Riddell: oh and did jockey work as expected?
<Riddell> tseliot: no, since I can't log in to X :(
<tseliot> Riddell: does it help if you comment out the whole ServerLayout section in your xorg.conf?
<jcristau> Riddell: looks like hal doesn't list any input devices. what does lshal say?
<Riddell> tseliot: no
<ogra> is hal even running ?
<Riddell> ogra: yes
<jcristau> ogra: if hal isn't running that usually shows up in the log
<ogra> ah
<Riddell> jcristau: http://muse.19inch.net/~jr/tmp/xorg/LSHAL
<ogra> i didnt know X became that intelligent :)
<jcristau> hrm. no x11_driver property anywhere.
<doko> jcristau, bryce: when do you plan to upload the fix for #281610 (wanting to know if I should delay a openjdk-6 upload)
<tseliot> Riddell: can you try this xorg.conf? http://pastebin.com/m7c7113d
<ogra> does /etc/default/console-setup exist ?
<jcristau> doko: debian not affected, so not my bug :)
<ogra> (and have XKB variables set)
<jcristau> the xkb stuff shows up, just not x11_driver..
<ogra> oh, wait, right
<Riddell> tseliot: what's the plain url for that?
<Riddell> ogra: yes (if you're talking to me)
<tseliot> Riddell: http://pastebin.com/pastebin.php?dl=m7c7113d
<ogra> Riddell, i was, but as jcristau pointed out, hal sets them, i missed that
<tjaalton> doko: would need a confirmation first that it works
<tjaalton> doko: probably after RC
<tjaalton> bryce: ^^
<Riddell> tseliot: yay, that works
<tseliot> Riddell: great :-)
<jcristau> that's not a fix though. something hal is broken
<Riddell> strange how this only happens on upgrades and not on new installs
<Riddell> and only with this machine
<Riddell> tseliot: so, what was I to test with jockey?
<tseliot> Riddell: can you modify the .desktop file of jockey-kde according to what is in the diff (only the lines in green) and see if you can reproduce the problem with the wirless driver? http://bazaar.launchpad.net/~jockey-hackers/jockey/trunk/revision/496
<tseliot> jcristau: yes, I know. I wanted to give him his keyboard and mouse back ;)
<jcristau> fair enough :)
<tseliot> Riddell: we transition users to the new input hotplug (which is supposed to work) during dist-upgrades
<Mirv> mvo: after fresh install from today morning's build with no network connection, all english, locale says fi_FI.UTF-8 for all
<Mirv> mvo: and to the previous question, 135752 and 277526, now combined, are about lack of apt-get update plus not offering installing support for the default language, 287556 is this new bug about non-localized note
<Mirv> mvo: the strings are all there in the .note file, though
<Mirv> mvo: is it perhaps because 0.3.15 has eg. "Name-de.UTF-8" instead of "Name-de_DE.UTF-8"?
<mvo> Mirv: I check, but I got a german translation on a non-networked install. but I will double check
<Mirv> mvo: can I trigger the note somehow myself after first clicking it away?
<Riddell> tseliot: adding that change to the jockey-kde.desktop file I start jockey thruogh the applications menu and I can install and uninstall drivers
<Riddell> tseliot: yay :)
<pitti> rocking
<mvo> Mirv: yes, please run sudo touch /var/lib/update-notifier/user.d/* ; sudo touch /var/lib/update-notifier/dpkg-run-stamp
<pitti> Riddell, tseliot: so it seems the .desktop fix is the only thing we need then?
<pitti> I'll upload that now
<tseliot> pitti: yep
<tseliot> Riddell: thanks for testing the fix
<Riddell> tseliot: thanks for fixing
<tseliot> ;)
<mvo> Mirv: that was a install with the desktop or the alternate disk (I don't think it makes a difference, but I want to be sure)
 * ogra curses ... ok, that starts getting annoying ... evo asked the fifth time for the passwprd now 
<Mirv> mvo: yeah, still English. desktop CD, in virtualbox.
<pitti> Riddell: uploaded, waiting in unapproved now
 * tseliot thinks that ogra should switch to kmail
<ogra> tseliot, haha
<pitti> mutt FTW!
<Mirv> mvo: might there be some part of German support on the CD that enables slightly more? like, if one goes to language selector, Finnish is selected as the "Default Language" even though only English is listed at all in the Supported Languages above
<tseliot> ogra: it what I did ;)
<superm1> ogra, didn't I lobby well for you switching to tbird after I told you about those extensions?
<ogra> well, i'D rather have evo behaving instead of switching
<ogra> but having to type my PW ten times a day just gets to annoying
<sebner> ogra: what about TB?
<ogra> sebner, that would be my second choice after evo
<tseliot> ogra: ok, pay someone to type in the password for you then? :-P
<ogra> tseliot, i'm not so good in writing up NDAs ;P
<seb128> use gnome-keyring?
<sebner> ogra: for me it's my first choice before evo but anyhow. good boy :)
<ogra> seb128, isnt that used by default ?
<seb128> right and it makes you unlock the gnome-keyring and not enter passwords again
<ogra> seb128, i never changed anything in my evo setup ... and always used g-keyring
<seb128> and it asks you for password?
<ogra> but since about two weeks its constantly asking for my pop PW
<ogra> just popped up *again*
<seb128> run seahorse, go to edit, preferences and see what keyrings are available and what is the default one
<seb128> did it ever store it? or it asks every time?
<seb128> is your server not reliable?
<ogra> its gmail
<mvo> the new ubiquity partition manager gui is pretty nice, but not the most friendly to color blind (or partially color blind) people
<ogra> should be reliable enough
<ogra> and it didnt do that before
<ogra> unless google changed something recently the server should be fine
<seb128> mvo: you still have the lists which is text only ;-)
<mvo> pff
<evand> mvo: Can you please file a bug on that
<jdstrand> slangasek: hi!
<jdstrand> slangasek: I just uploaded a fix for bug #287533
<seb128> mvo: just curious but what makes easier for you? adding rounds, lines, etc?
<ubottu> Launchpad bug 287533 in libvirt "[regression] cannot use more than one vcpu" [High,Fix committed] https://launchpad.net/bugs/287533
<ogra> seb128, hmm, it doesnt list my pop PW in seahorse
<seb128> mvo: or that's the colors choice?
<seb128> ogra: do you have several keyrings listed?
<seb128> ogra: it could be trying to store it or read it in the wrong keyring
<jdstrand> slangasek: it's a one liner (debdiff in bug) and likely important for ISO testing SMP
<mvo> seb128: the color choices are not ideal, the second and third are too close for me, something in the color (e.g. a shape) would help
<mvo> gnuplot gets this tright for example with the different shapes for the points
<ogra> seb128, it shows my gpg key and my ssh key in the first tab in seahorse ... my gpg key has two subkeys
<seb128> ogra: don't bother about those
<seb128> mvo: I see
<ogra> where do i look then ?
<seb128> ogra: edit, preferences, the tab lists what keyring?
<ogra> login ??
<ogra> nothing else in there
<seb128> ok, that's not a "store in the wrong keyring" issue then
<ogra> i dont see anything evo related in the passwords tab though
<seb128> you should open a bug on bugzilla.gnome.org, or ask on #evolution on the GNOME irc
<seb128> that's weird
<seb128> your passwords should be there
<seb128> the network manager and evolution passwords are stored there
<ogra> i have a googlecal, an ldap pw for the directory server some NM networks ... oh, and i see the smtp one for canonical
<ogra> but nothing for pop
<ogra> and one sftp for a local machine
<calc> Riddell: bug in #ubuntu-testing alt oem install broken see bug 218144
<ubottu> Launchpad bug 218144 in ubuntu "Kubuntu KDE4 Alternative amd64 OEM installation failure" [Undecided,Confirmed] https://launchpad.net/bugs/218144
<ogra> remember password is checked in evo for both, pop and smtp
<ogra> i sadly dont have the time to debug it further right now
<mvo> Mirv: hm, no luck. fresh install without network but the german notification appears fine (in german) - I will try finish next I think (after dinner)
<cjwatson> Mirv: perhaps the locale isn't generated, but the installer ought to do that
<calc> cjwatson: who should 218144 be assigned to?
<cjwatson> calc: at least partly me, I just hadn't got round to doing so yet
<calc> ok
<cjwatson> calc: could you file a separate bug on gnome-app-install (was that what you used? Add/Remove... is gnome-app-install) for the package manager bug?
<cjwatson> I'd rather not create another task for basically an unrelated problem
<mvo> calc: what bug is that?
<mvo> Mirv: thanks, I try with finish next, what is finish spelled like in finish (I guess that sounds a bit stupid now :)
<Keybuk>        The two descriptors do not share file descriptor flags  (the  close-on-
<Keybuk>        exec  flag).  The close-on-exec flag (FD_CLOEXEC; see fcntl(2)) for the
<Keybuk>        duplicate descriptor is off.
<Keybuk> does anyone else think that's repeating itself a little?
<Keybuk> and perhaps incrementally clarifying
<calc> cjwatson: i didn't file the original bug but i can take a look later today to see if that bug still exists (the original bug is from april)
<cjwatson> calc: oh, sorry
<calc> colin king filed it, isn't he a kernel guy?
<mvo> calc: what is that add/remove issue you mentioned?
<cjwatson> yeah, I commented on the bug
<cjwatson> I guess I saw the leading C and didn't read further :)
<calc> mvo: bug 218144
<cjwatson> mvo: it was Colin King, see bug 218144
<ubottu> Launchpad bug 218144 in oem-config "Kubuntu 8.10 OEM Installation fails (amd64/i386)" [Undecided,Confirmed] https://launchpad.net/bugs/218144
 * mvo looks
<calc> cjwatson: i noticed late last night that issue still exists in the kubuntu installer and just followed up to it once someone found the bug report for me
<Mirv> mvo: firstly, it's Finnish with two "n":s, and in Finnish it's "suomi" :)
<Mirv> mvo: installed in German, but indeed German is one of the rare languages that has some language packages on the CD. works there.
<superm1> pitti, fglrx didn't make it onto the 20081022 dvd, but it was using up to date seeds (1361 revisions).  are you sure  the components are set correctly for the packages? ? Unknown supported-kernel package: fglrx-kernel-source
<steveire> Hi. Which channel gnome developers use? I tried gnome-devel, but that's empty
<superm1> and a few others too.  will it be troublesome that xorg-driver-fglrx is Recommends libamdxvba1 when resolving this since that is supposed to be multiverse?  I've got to do one more upload of it anyhow for a metabug that cropped up, so if it needs to be dropped to suggests, i can do that now too
<kirkland> pitti: http://blog.dustinkirkland.com/2008/10/mounting-kvm-disk-image.html
<steveire> Anyone?
<liw> steveire, upstream gnome developers are probably on the irc.gnome.org network
<steveire> liw: Ah, right thanks
<pitti> steveire: what liw said, on #gnome-hackers
<steveire> pitti: Found it. thanks
<pitti> superm1: fglrx-kernel-source | 2:8.543-0ubuntu3 | intrepid/multiverse | amd64, i386
<pitti> superm1: argh, fixing
<superm1> pitti, it looks like all of the binaries are in multiverse, not just that one
<pitti> superm1: just saw that, too; weird, I'm 100% sure I moved them yesterday
<mathiaz> pitti: will you have some time before release to process the obm MIR? bug 259776
<ubottu> Launchpad bug 259776 in obm "MIR for obm" [Undecided,New] https://launchpad.net/bugs/259776
<pitti> mathiaz: it's targetted to intrepid? I haven't reviewed it previously (was lool), but if it's urgent, I'll make sure that it gets reviewed ASAP
<pitti> mathiaz: (I'm pretty busy with release preps and archive consistency cleanups, sorry)
<sylvaing> mathiaz: if you are questions about obm i'm here ;-)
<mathiaz> nijaba: ^^?
<superm1> pitti, so will the recommend libamdxvba1 thing be a problem for adding this to the dvd since it's cross component, or will that just get ignored and be no trouble?
<sylvaing> mathiaz: i'm uploader of obm
<pitti> superm1: yes, it needs to be suggests
<superm1> pitti, okay i'll drop it to suggests then in this upload for the metabug
<pitti> superm1: thanks
<oliver_g_1> kirkland: wanted to ask about bug 279049
<ubottu> Launchpad bug 279049 in ubuntu-manpage-repository "Should provide simple shortcut links to manpages" [Undecided,Fix committed] https://launchpad.net/bugs/279049
<Riddell> wgrant: ping
<oliver_g_1> is there a test site where this is already implemented?
<kirkland> oliver_g_1: -> /msg
<Riddell> wgrant: your patch to x11proto-input adds "BOOL delete" which breaks c++
<Riddell> tjaalton, bryce: either of you know where to find a fix for that?  I hear upstream may have fixed it
<bryce> Riddell: have a link to the patch or the bug it fixed?
<bryce> sounds like it just needs to be changed to a name other than 'delete'
<tjaalton> Riddell: no commits to inputproto
<bryce> since obviously that's a reserved c++ keyword
<bryce> aha, 100-Add-Device-Properties-X-Input-1.5.patch
<tjaalton> we've had that for some time now..
<bryce> Riddell: I'll take care of it, thanks for pointing it out.  Can you file a LP bug if there's not one already, so we have something to attach the fix to?
<bryce> tjaalton: well it wouldn't show up unless someone tried to compile a C++ code against that header
<bryce> tjaalton: so no surprise it'd show up via KDE work
<bryce> it's clearly a bad C/C++ thingee
<tjaalton> http://cgit.freedesktop.org/xorg/proto/inputproto/diff/?id=fabe087cebb11c6a2600e57c6f7a52fda2efea29
<bryce> tjaalton: thanks
<bryce> icky hack
<bryce> hrm, this is not going to be an easy thing to fix
 * bryce ponders
<tjaalton> why?
<bryce> tjaalton: well we'll need to fix anything that's using that delete structure member as well
<tjaalton> ok
<bryce> Riddell: can you give some more detail about where this issue cropped up?
<liw> surely the right fix is to rename the field for all users, not just c++ code?
<bryce> liw, that would be my idea as well, which is why I said this was an icky hack
<bryce> but I understand why they did it this way - if it gets changed, then we have to rebuild everything that uses it
<bryce> I wish upstream had put in a cleaner fix
<Riddell> bryce: someone was compiling qt 4.5
<liw> I wish C++ hadn't invented a new keyword ;-)
<bryce> liw, when we converted inkscape to C++ we had a whole mess of issues like this
<bryce> objects had a "class" member we had to change to "klass" throughout
<jcristau> liw: rename for all users -> change users
<jcristau> liw: rename for C++ -> no change for existing users
<liw> bryce, yeah... either no new keywords should be added, or keywords should be in a namespace of their own... one language I know used all-uppercase for keywords and forbade that for user symbols
<liw> jcristau, I realize that, but it's still a kludge
<jcristau> (admittedly, for something like GetDeviceProperty that's never been released, changing it for everyone might have been better)
<pitti> liw: invented a new keyword> has it? new and delete are in C++ for ... ever
<liw> pitti, compared to C, it did invent them; C still doesn't have those keywords, so they're new to many C programmers
<pitti> liw: right, but then you compare two different languages
<pitti> that's not really a fair complaint :)
<persia> pitti, Except that C++ permits #include of C headers, rather than expecting bindings as do most languages.
<persia> So it's potentially buggy for any C programmer to write headers that aren't also C++ compliant.
<pitti> I thought that's why you should wrap them into some namespace "C" thingy?
<liw> and unless said C programmer _knows_ C++, they can't know they're breaking C++ inclusion
<liw> pitti, it doesn't provide a full C compatibility; keywords is one example where it breaks
<pitti> that's true, yes
<superm1> pitti, can you nuke fglrx-installer_8.543-0ubuntu4.dsc from unapproved?  Someone just responded to another bug that we can squeeze a fix into, so I'll just add it and redo the upload?
<pitti> superm1: *boom* gone
<superm1> thanks pitti
<slangasek> jdstrand: "ISO testing SMP"?
<jdstrand> slangasek: yes. virt-manager won't let you specify more than 1 VCPU in the guest when using kvm
<liw> jdstrand, oh?
<jdstrand> slangasek: I tend to do 2 CPUs in the guest, for variety when doing ISO testing
<slangasek> jdstrand: accepting libvirt implies a respin of ubuntu-server; are there testing resources available in the server team to give us full test coverage in the next 8 hours or so if we do that?
<jdstrand> slangasek: so I upped it to 16, since that is what our version of kvm can support
<jdstrand> dendrobates: ^
<liw> oh, it really doesn't
<jdstrand> slangasek: I figured getting it into the archive and then have it be on the next CD would be enough...
<jdstrand> slangasek: but I don't allocate resources, or respin the CDs, which is why I came to you directly ;)
<slangasek> jdstrand: we prefer to keep the skew between the CDs and the archive to a minimum at the point of the RC
 * jdstrand nods
<slangasek> so I'd prefer to not accept this until after the RC, really
<jdstrand> slangasek: whatever you decide-- I just wanted you to know what was happening
<slangasek> if the server team as a whole (or dendrobates) thinks there are resources to test after another respin, and want me to push the button, I'm happy to do that
<dendrobates> slangasek: we can retest, if you will respin.
<slangasek> dendrobates: can, or want to? :)
<dendrobates> slangasek: We will retest.  I would like the fixed libvirt to get in.
<jdstrand> slangasek: out of curiosity, will Ubuntu QA Tracker notify me as soon as they are respun?
<slangasek> dendrobates: ok, accepted; expect the new images to be available in about 2-2.5h
<slangasek> jdstrand: if it normally notifies you, then yes
<jdstrand> ok (it does)
<mvo> Mirv: installing in finish is cool, I had no idea you have so many "Ã¤"s :)
<Treenaks> mvo: You've never seen German, have you? :P
<slangasek> kein Deutschesprache fÃ¼r mvo
<slangasek> s/kein/keine/
<ion_> Ã¤Ã¤liÃ¶itÃ¤
<mvo> heh :)
<pitti> Ð¯ ÑÐ¾Ð»ÑÐºÐ¾ Ð¿Ð¾Ð½Ð¸Ð¼Ð°Ñ Ð²Ð¾ÐºÐ·Ð°Ð»!
<ion_> É¥ÇÉ¥
<directhex> ya tolko ponymayou voksal? now, the verb is "i understand"
<directhex> but i don't remember "tolko" or "voksal"
<Treenaks> directhex: "Bahnhof"
<pitti> directhex: ÑÐ¾Ð»ÑÐºÐ¾ -> only, Ð²Ð¾ÐºÐ·Ð°Ð» -> train staion
<pitti> station
<pitti> directhex: "I only understand train station" is a common phrase in German meaning "I don't get it"
<directhex> pitti, ah yes, i remember the latter now. i don't remember tolko though.
<directhex> germans speaking russian? stalin lost!
<Treenaks> pitti: Ð¿ÑÑÐ¼Ð¾Ð¹
<directhex> man, i haven't done any russian for a decade
<Treenaks> directhex: since the iron curtain thing?
<pitti> Treenaks: Ð¢Ð¾Ð²Ð°ÑÐ¸Ñ!
<Treenaks> oh wait, that's almost two decades already
 * Treenaks feels old :(
<pitti> directhex: worse. Treenaks is Dutch :)
<ion_> That word has been copied to Finnish almost as-is.
<directhex> pitti, i know that one
<mvo> Mirv: I can reproduce the problem with finish just fine, I'm debugging now
 * lool 'night folks
<superm1> doko, i  was just about to upload another fglrx-installer with another bug fix that included the fixes you just uploaded.
<doko> superm1: sorry, didn't see that.
<doko> just wanted to get rid of ia32-libs
<superm1> doko, no problem, i'll just bump the number and merge yours
<doko> thanks
<mvo> liw: system cleaner does not have a icon?
<pitti> doko, superm1: anything I should reject again?
<liw> mvo, https://bugs.launchpad.net/ubuntu/+source/system-cleaner/+bug/274714
<ubottu> Launchpad bug 274714 in system-cleaner "System Cleaner Has No Icon" [Low,Triaged]
<superm1> pitti, yeah if you can, i'll just upload mine with the additional changes (which included doko's)
<mvo> thanks liw
<pitti> superm1: done
<pitti> james_w: I'm inclined to upload your consolekit fix to the queue now, to be accepted right after RC; do you have some doubts or negative feedback about it?
<joaopinto> grub is automatically adding me entires for kernels no longer available, any idea where it get's that list from ?
<slangasek> TheMuso, persia: no test results in yet for UbuntuStudio?
<pitti> cjwatson: debian-installer in hardy-proposed just went to the -21 kernel, which is now in main; can I just copy-package that to -updates, or did that require manual copying of some files? (I faintly remember something like that in dapper.1)
<cjwatson> pitti: requires manual copying, want me to take care of it?
<pitti> cjwatson: not really urgent, has time until after release; I was just curious
<cjwatson> I can do it, it's OK
<pitti> cjwatson: thanks
<pitti> Riddell: I think it becomes urgent to get bug 280295 into hardy-updates; was the -proposed version tested by anyone
<Riddell> bryce: http://cgit.freedesktop.org/xorg/proto/inputproto/diff/?id=fabe087cebb11c6a2600e57c6f7a52fda2efea29
<ubottu> Launchpad bug 280295 in adept "do not offer upgrade to intrepid automatically" [Undecided,Fix committed] https://launchpad.net/bugs/280295
<pitti> ?
<cjwatson> you have to copy dists/<foo>-{proposed,updates}/main/installer-i386/<date> and update the current symlink, and you have to do this while the publisher isn't running or else do it in dists.new
<bryce> Riddell: thanks
<Riddell> pitti: I tested it, I've not heard anything from QA
<bryce> Riddell: however I'm wondering if there are corresponding source file changes for that
<pitti> Riddell: that's fine, it was an easy patch; I'm more concerned about miscompilations or so
<pitti> Riddell: if you used the .deb from -proposed, that's good enough for me
<liw> .deb! he said .deb! see! I'm not the only one!
<liw> (sorry)
<kees> moquist: ping
<slangasek> liw: heh
<pitti> liw: what's wrong with it?
<pitti> liw: did we switch to rpm without me noticing? :-)
<Riddell> bryce: you're the X man, not me :)  do you know the committer?  peter.hutterer@redhat
<liw> pitti, I had a bug filed against system-cleaner for being too much like windows because I say ".deb package" instead of "Debian package"
<moquist> kees: pong
<pitti> liw: welcome to the difference of normal human people and developers :-P
<cjwatson> liw: you forget, people who've been Debian developers since before Ubuntu existed don't know how .deb is supposed to be spelled
<bryce> Riddell: yup
<pitti> it's an, erm, "deb"...
<bryce> Riddell: aka whot.  He's a good guy and puts out well-thought-out code
<Riddell> bryce: are you able to ping him and find out if there's code changes needed?
<cjwatson> pitti: no, it was the dot he was complaining about
<bryce> Riddell: hang on, I may be able to figure it out directly
<bryce> Riddell: I've asked whot on #xorg-devel.
<pitti> Riddell: so, did you test with a local build or with the hardy-proposed packages?
<Riddell> pitti: I'm pretty sure I tested with hardy-proposed, but it was a while ago and I can't help feeling I should double check
<sbeattie> Riddell|pitti: is there an obvious way to test that one?
<james_w> pitti: I think the bug would be good to fix, my only concerns are that I am way out of my comfort zone and there has been no upstream review.
<sbeattie> as in, will the current adept ask me about upgrading?
<pitti> james_w: yeah, I wish William would take a look at it
<pitti> sbeattie: not until we release intrepid, I'd think
<Riddell> sbeattie: install adept from hardy-proposed, edit /etc/hosts add "193.28.45.42 changelogs.ubuntu.com", run adept and refresh packages
<james_w> pitti: I can't believe we're the only ones hitting it
<Riddell> check if Version Upgrade button appears
<pitti> james_w: no, but we are the only ones having apport :)
<sbeattie> Riddell: awesome, thanks, I'll go about verifying that fix.
 * james_w hugs apport
 * james_w hugs pitti 
 * pitti hugs james_w back
<bryce> Riddell: ok, got the question sorted out, I'll put in the patch
<ajmitch> bryce: was nvidia-xconfig/nvidia-settings ever a supported way to write out xorg.conf?
 * ajmitch had X fail to parse the config file due to a stray RGBPath, was wondering if bug 278055 should be confirmed
<ubottu> Launchpad bug 278055 in nvidia-settings "nvidia-settings generates broken xorg.conf files" [Undecided,New] https://launchpad.net/bugs/278055
<pitti> sbeattie: there's a bunch of pending SRUs with recipes, too (like #256891); I did a few verifications now, but I can't test my own uploads
<sbeattie> pitti: yes, sorry, I've been focusing on intrepid, so hardy SRUs have stalled a bit.
<pitti> sbeattie: that's fine; intrepid is more urgent ATM :)
<bryce> ajmitch: I wouldn't call it supported, but I think it was used by an appreciable number of users.  jockey would be the supported way.
<ajmitch> bryce: right, it's just something that bit me on upgrade the other day
<ajmitch> I suspect that my xorg.conf was written out before jockey was around
<mvo> Mirv: I uploaded a fix for the notification translations, please let me know if it fixes the issue for you (when you have time) - thanks a lot for reporting it and for your detailed testing \o/
<mdke_> is anyone able to sponsor the upload of ubuntu-docs requested at bug 286829
<ubottu> Launchpad bug 286829 in ubuntu-docs "Please update ubuntu-docs from bzr" [High,New] https://launchpad.net/bugs/286829
<mdke_> ?
<calc> cjwatson: we found another issue, rescue mode on ubuntu alt doesn't work
<cjwatson> eek
<calc> cjwatson: heno was wondering what package to file it against
<cjwatson> 'rescue'
<calc> ah ok
<cjwatson> rescue hasn't changed for ages
<calc> cjwatson: it fails when trying to enter rescue mode after all the prelim stuff is setup, at least for me
<calc> cjwatson: i think heno managed to get a better error message out of it than i did
<heno> filing a bug, just a sec
<heno> cjwatson, calc: bug 287788
<ubottu> Launchpad bug 287788 in rescue "8.10 RC rescue mode fails to start shell n root device" [Undecided,New] https://launchpad.net/bugs/287788
<calc> cjwatson: i saw a failure to enter rescue mode (different screen)
<cjwatson> it wasn't i386 rescue mode with amd64 installs was it?
<heno> oh?
<calc> i can see about screenshoting it after i am done with my current test, assuming i can still reproduce it
<calc> heno: yea it was a different message but still a red screen one
<heno> cjwatson: indeed it was
<cjwatson> heno: can't do that
<calc> cjwatson: mine was i386 on i386
<calc> cjwatson: but with two ubuntu installs on the hd
<cjwatson> you can execute a shell in the installer environment, but an i386 rescue CD can't execute an amd64-compiled shell
 * heno retries 64-on-64
<calc> cjwatson: how is it supposed to work with two linux installs on the drive, come up with an option of which to choose?
<cjwatson> calc: yes
<calc> ok
<cjwatson> indeed it should just give you a menu of all your partitions
<calc> ok
<cjwatson> it's known to handle the case where there are no partitions rather poorly, but that isn't what you're describing ...
<calc> well i'll try to reproduce it and get a screenshot asap
<calc> unfortunately i started another install before fully investigating it
<seb128> calc: hi, why did you close bug #273930?
<ubottu> Bug 273930 on http://launchpad.net/bugs/273930 is private
<heno> I've closed my bug. I'll try i386->i386 too
<calc> seb128: apparently it was a mistake on the wrong bug or something like that
<seb128> calc: ok, because the crash is still there using the intrepid candidate
<calc> seb128: does this just happen on upgrade?
<calc> seb128: i couldn't reproduce it on i386
<calc> seb128: liw saw it on amd64 running off the cd
<seb128> calc: no, that was on kvm i386
<calc> seb128: the dupe that liw attached was on amd64
<seb128> calc: clicking to open several example-content examples
<calc> seb128: before they can load, or just doing it generally?
<seb128> calc: openoffice is slow to start, just double click on several example in nautilus and wait a bit
<calc> ah ok
 * calc is tracking down another bug right now
<liw> calc, I get it even if I double-click on just one thin in nautilus, and then do nothing, waiting patiently for OO to start and then boom (just did that, again)
<seb128> calc: that's not an important issue, I was just wondering why you closed the bug, you didn't add any comment there and just closed
<calc> ok
<calc> i was going through hundreds of bugs and must have closed the wrong bug
<seb128> ok, so it should be reopened
<calc> yep already reopened it
<seb128> I was just not sure if it had been discussed on IRC and closed after that or something
<seb128> or if that was an error
<seb128> thanks
<NCommander> hey ScottK
<ScottK> Heya
<bryce> hmm, I'm getting timeout errors when nominating bug 284603 for intrepid
<ubottu> Launchpad bug 284603 in x11proto-input "/usr/include/X11/extensions/XIproto.h contains reserved C++ keyword" [Critical,Fix committed] https://launchpad.net/bugs/284603
<TheMuso> slangasek: My day yesterday had just about finished by the time new studio isos were done. I'm going to do them today.
<calc> yipee it gave me the error message again
<slangasek> TheMuso: ok
<calc> it seems to do it every time for me
<slangasek> calc: "the error message"?
<calc> wtf
<calc> "rescue-mode: no partitions found!"
<calc> oh does this not work with encrypted lvm?
 * calc scrolls up
<calc> can't see where that was discussed now
<calc> cjwatson: ping
<calc> slangasek: do you know much about rescue mode?
<slangasek> not really
<calc> slangasek: ok
<calc> well its not working for me, colin was here until a few min ago :\
<cjwatson> calc: I'm here
<calc> cjwatson: ah ok
<calc> cjwatson: it says no partition found for encrypted lvm
<cjwatson> luks != dm-crypt, right?
<calc> cjwatson: i can try running it against a regular install and see if it works for it
<cjwatson> it only supports luks at the moment; Debian bug 404261
<ubottu> Debian bug 404261 in rescue-mode "rescue-mode: should support encrypted disks" [Wishlist,Open] http://bugs.debian.org/404261
<cjwatson> huh, bizarre, that description is wrong. Should be "rescue-mode: should support loop-aes and plain dm-crypt encrypted disks"
<calc> cjwatson: no idea, i just did a intrepid lvm encrypted install according to the test case then rebooted to see what the error was that rescue mode gave me
<cjwatson> I'll give it a quick try here, thanks
<calc> cjwatson: iirc it also failed in a similar manner for two regular installed partitions but i may be wrong, i'll give it a try again
<calc> cjwatson: or if you have extra machines to test with try to do a regular + resize install then see if it fails
<cjwatson> that would definitely be more surprising
<calc> it said failing step is: "Enter rescue mode"
<calc> then alt-f4 mentioned the no partitions bit
<calc> i'll try to do a quick multi install and check it again
<cjwatson> the encrypted LVM failure is definitely plausible - I don't think it's RC but it ought to be fixed
<cjwatson> if it's failing with plain partitions then I think that's RC
<calc> bug 287807
<ubottu> Launchpad bug 287807 in rescue "rescue: fails for lvm encrypted install" [Undecided,New] https://launchpad.net/bugs/287807
<calc> i filed that one, now working on the regular case failure, i'm pretty sure it was a regular case
<calc> well i'll verify whether it happens on a truely regular case install
<cjwatson> ok
<calc> i'll start with a regular install test it, then do a resize and see if it still works
<lfaraone> Hey, there's a fix to example-content (the FLAC audio was poor, new version uploaded to the main bzr repo and accepted) in bug 208561, is there a way I can get some more attention from the main sponsors? (rc is out tomorrow, of course)
<ubottu> Launchpad bug 208561 in example-content "Speex Audio file is a non-ideal bit-rate" [Low,Fix committed] https://launchpad.net/bugs/208561
<persia> lfaraone, RC is frozen now for image testing.  It is exceedingly unlikely to be changed for RC.  It may be reviewed post-RC if considered release critical.
<lfaraone> persia: Well, it represents ubuntu poorly.
<lfaraone> persia: wait, we're testing the rc before we release it for testing :)
<lfaraone> ?
<persia> Yes.  Every milestone image (Alpha, Beta, RC) gets a couple days of testing to make sure that it isn't completely broken, and is a good basis for widespread testing.
<lfaraone> persia: (By that, we're supposed to be showing off the best that free software / formats / ubuntu can offer)
<persia> There's a daily image every day, but depending on the state of the archives, it might not boot, or not install, or not run X, etc.  By not uploading for a couple days, we can make sure that we have something worthy of testing.
<lfaraone> persia: Ok. I'm wondering if this would be considered release-critical. (reg. potential is low)
<calc> lfaraone: that reminds me i should fix up one of the OOo files in example-content as well
<calc> lfaraone: it uses invalid fonts and don't get replaced properly due to fc bugs
<calc> :\
<lfaraone> calc: lol.
<persia> lfaraone, You could certainly raise it to the release team, but if accepted, it will be post-RC (I hope, as otherwise there is even less sleep for many)
<lfaraone> persia: kk. How do I go about doing that?
<persia> lfaraone, Actually, I'm not sure who would be the best person to represent a candidate example-content fix to the release team.  Maybe calc who seems to be contemplating another change to the same pacakge (and who you've already notified)
<calc> persia: i won't have time to work on it until i get done with testing images :\
<calc> i haven't fixed the document yet so i'll have to see how hard it is to fix
<lfaraone> calc: What's the probability of it being accepted? (so I can tell the uploader)
<calc> slangasek: ^
<calc> lfaraone: slangasek would know more than me
<lfaraone> calc: kk.
<persia> calc, I wouldn't expect you to :)
<calc> considering the document was written with an invalid font in the past sometime i am not sure what font i need to use to get it to layout right now
<calc> it was subsituted with something but not sure what
<james_w> pitti: would it be reasonable to roll the patch on 287723 in to the consolekit upload, or should that be an SRU?
<slangasek> lfaraone, calc: changes to example-content are low-risk and should be straightforward to verify; I'd be happy to take that speex file fix after RC
<slangasek> (didn't I see it in the queue already?)
<lfaraone> slangasek: cool, thanks!
<kees> slangasek: what's the best way to answer the question "is source package XYZ on any release media?"  (i.e. I have an intrepid security update for moodle and I want to know if I should wait 1.5 weeks or upload it now)
<slangasek> lfaraone, calc: yes, the example-content fix is already in the unapproved queue and will be accepted after RC
<slangasek> kees: the best way to answer the question is to ask me to run a grep command on antimony :-P
<lfaraone> slangasek: coolio.
<slangasek> kees: moodle is in edubuntu
<kees> slangasek: can you grep for moodle on antimony?  :)
<james_w> kees: I was just trying to write a script to do exactly that :-)
<calc> ok
<kees> james_w: yeah, it'd be handy
<kirkland> slangasek: sweet, what about "expect"?
<james_w> not sure if antimony has more information than we can piece together from elsewhere.
<kees> slangasek: okay... I will wait.
<slangasek> kees: not sure it follows that you have to wait?
<kees> slangasek: will you do a respin between RC and Final of edubuntu?
<slangasek> james_w: I'm just grepping */daily*/current/*.{manifest,list}; the info is available elsewhere
<slangasek> just not as directly
<slangasek> kees: yes
<slangasek> kees: specifically, we should get WinFOSS off of there since it's not supported anymore
<kees> slangasek: okay, then should I upload it now, and you can accept it as you see fit, or should I wait to a specific time?
<james_w> thanks, now is obviously not the time to discuss it, but lets get something in ubuntu-dev-tools for next cycle.
<slangasek> kees: expect is on mythbuntu
<slangasek> kees: upload now is fine, that's what the unapproved queue is for :)
<kirkland> slangasek: expect was mine ;-)
<kees> slangasek: okay, thanks.  done.
<kirkland> slangasek: thx
<superm1> slangasek, we're testing alternates tonight for mythbuntu, there was troubles with virtualbox hanging during install, but i'm blaming virtualbox at this point. will get back to you with results later
<calc> cjwatson: totally broken for me
<calc> doesn't even work for the single install case
<cjwatson> gosh. OK, I'll investigate, thanks
<calc> gave me the same no partitions found as with the lvm one
<slangasek> kirkland: expect is on mythbuntu
<slangasek> :)
<kirkland> slangasek: ;-)  but not on the server?
<slangasek> nope - there's pexpect there, but not expect
<kirkland> slangasek: interesting, thanks.
<calc> cjwatson: and fdisk -l shows the partitions
<superm1> kirkland, you expecting to be breaking expect?
<cjwatson> yeah, it doesn't use fdisk though
<calc> cjwatson: ok, just stating that it is actually there although it doesn't see them
<kirkland> superm1: :-)  no, i was considering adding a dependency on it
<cjwatson> calc: what does 'list-devices partition' say?
<calc> nothing
<superm1> kirkland, what dependency?
<cjwatson> that'll be it then. Wonder what that's about
<kirkland> superm1: there have been multiple people that have run ecryptfs-setup-private, and entered their login passphrase wrong.  twice.
<calc> cjwatson: this is being tested on vmware 6.5, not sure if that will matter in the debugging
<kirkland> superm1: i need a method to verify their passphrase is correct.  unix_chkpwd seems to be it, but it's proving more difficult to implement that i'd have though.
<cjwatson> calc: I'll let you know if I can't reproduce it
<calc> ok
<kirkland> superm1: so i have about 5 lines of expect code that takes their input password and tries to su to themself and run /bin/true
<calc> cjwatson: feel free to call me on my cell if i'm not around and you need more debugging
<cjwatson> ok
<calc> cjwatson: i may eat dinner in the next hour or so
<cjwatson> thanks
<superm1> kirkland, yeah it's a really nifty little tool
<kirkland> superm1: however, you just triggered a light bulb..........
<kirkland> superm1: what is?
<kirkland> superm1: expect?
<superm1> expect
<calc> cjwatson: i'm going to just redescribe my current rescue bug since it seems more general than i originally filed
<cjwatson> fine
<calc> list-devices disk outputs nothing as well
<calc> cd works
<calc> i think the others don't apply for my test vm
<calc> list-devices usb-partition works when i stick a thumb drive in
<calc> and list-devices partition also shows the usb thumb drive too (not sure if that is supposed to happen)
<cjwatson> basically seems to indicate that your disk driver isn't loaded
<calc> and disk shows the thumb drive
<calc> cjwatson: erm wouldn't that cause it to not show up in fdisk -l though if the kernel driver wasn't loaded?
<calc> or do you mean some other sort of driver
<sbeattie> pitti: when I try to run sudo in the guest session, I'm getting an apparmor rejection on capable for Xsession's profile
<sbeattie> I'm not sure it's a bug or intended behavior that guest session stuff can't run setuid programs.
<cjwatson> calc: well, you'd think so ... list-devices just looks in /sys/block/ basically
<calc> yea
<calc> i'm looking in the script to see if i can determine what is wrong
<cjwatson> list-devices partition is really just a reformatting of ls /sys/block/*/*
<cjwatson> well, ish
<calc> well the sda1 etc are there in sys
<cjwatson> it does do filtering obviously
<calc> if i understand it is looking for /sys/block/sda/sda1/sys ?
<calc> or maybe i am misreading this code
<cjwatson> try 'udevadm info -q env -p /block/sda/sda1'
<cjwatson> and look for ID_TYPE
<calc> udevadm unknown command
<cjwatson> !
<ogra> woah
<calc> its there but it returns that as the response
<cjwatson> seriously? udevadm is in the d-i base system
<calc> i even tried /sbin/udevadm -q env -p /block/sda/sda1
<cjwatson> udevadm info
<cjwatson> ass I said above :)
<cjwatson> as
<calc> anything after the info?
<cjwatson> 23:50 <cjwatson> try 'udevadm info -q env -p /block/sda/sda1'
<calc> ah ok
<calc> that works
<calc> should i capture that for the bug report?
<calc> udevinfo outputs the same info
<cjwatson> udevinfo == udevadm info except for the way it's obsolete
<cjwatson> sure
<calc> ok
<calc> done
<calc> hmm there is no ID_TYPE
#ubuntu-devel 2008-10-23
<cjwatson> that would do it ...
<calc> there should be an ID_TYPE for a partition, correct?
<cjwatson> yes
<cjwatson> ata_id or scsi_id or whatever should set it
<calc> ok
<cjwatson> we need that in order to filter out CDs, tapes, and other garbage that's uninteresting here
<cjwatson> this is going to be vmware-specific
<calc> is it, or just the device vmware is emulating?
<wgrant> Riddell: That wasn't actually my patch - it's upstreams, and I didn't pull it initially. I just altered it.
<cjwatson> well, yes, but it could be that one of the relevant ioctls is failing or something
<calc> oh ok
<cjwatson> is this vmware's LSI Logic device?
<cjwatson> or BusLogic?
<calc> it claims to be a PIIX4 IDE and LSI Logic (depending on which it is on)
<calc> ah the LSI
<calc> i checked the pci id
<cjwatson> calc: '/lib/udev/scsi_id --export --whitelisted -d /dev/sda', please?
<calc> nothing output
<jdstrand> slangasek: would http://cdimage.ubuntu.com/ubuntu-server/daily/20081022.1/ be the new images? they showed up much earlier than 2 hours so I wanted to be sure
<cjwatson> calc: try that with UDEV_LOG=debug set in the environment and tail syslog afterwards?
<cjwatson> (this really needs Keybuk ...)
<cjwatson> Keybuk: batsignal
<calc> ok
<cjwatson> it's probably actually a kernel bug, but scsi_serial.c is not entirely trivial so you never know
<calc> still no output in /var/log/syslog
<calc> and no output to screen
<slangasek> jdstrand: er, those are them, yes
 * jdstrand nods
<slangasek> and now, much later than two hours, I'll post them to the tracker :P
<slangasek> sorry
<jdstrand> heh
<cjwatson> calc: well, this depends on how far you're willing to take it; my next step were I in front of the machine would be 'udpkg -i /cdrom/pool/main/s/strace/strace-udeb_*' and then strace the scsi_id invocation above
<cjwatson> since it seems like this needs some digging
<calc> the ending of the strace shows an ioctl on /dev/sda and then close
<cjwatson> can you screenshot that?
<calc> yea
<calc> done
<calc> actually there are several ioctls apparently
<calc> that got all of the interesting bit from the strace at least that i saw when scrolling up
<calc> the other bits were just loading libraries afaict
<james_w> hmm, AdminKit
<ArneGoetje> calc: since openoffice.org translations are now installed with the regular language-packs, is it still necessary to install the openoffice.org-l10n-$lang packages, or can I drop the dependencies in the language-support-writing packages?
<cjwatson> ArneGoetje: they are?
<ArneGoetje> cjwatson: at least they are marked as being exported into the langpacks in Rosetta
<cjwatson> I don't see them in the current output
<ArneGoetje> cjwatson: hmm...
<cjwatson> and wouldn't they have to be exported to gsi?
<ArneGoetje> cjwatson: no idea about that
<ArneGoetje> cjwatson,calc: forget that question...
<calc> ArneGoetje: yea they aren't as far as I know
<ArneGoetje> calc: then they shouldn't be exported into the langpacks either, right?
<calc> yea they shouldn't and afaik they aren't being export to them
<ArneGoetje> calc: how do we currently handle them? Seperate export from rosetta and then building new oo.o-l10n packages?
<ArneGoetje> calc: at least some templates are marked as being exported in rosetta... will change that then.
<calc> currently not exported but will be doing that with the first jaunty upload, i have to rearrange some bits in the build also since the rosetta stuff was changed
<calc> they changed it about a week or two ago
<calc> iirc
<ArneGoetje> calc: ah...
<slangasek> jdstrand, dendrobates: how goes the server testing?
<jdstrand> I'm personally working on it-- I know at least two others started
<jdstrand> and we were all told to do it :)
<kirkland> slangasek: i've downloaded, working on another patch, will be testing server iso thereafter
<calc> hmm the server iso got rebuilt today?
<slangasek> calc: yes, at server team's request
<calc> oh ok
<calc> i noticed it resyncing on my machine
<Keybuk> cjwatson: am here now
<Keybuk> just checking in on my way to bed
<Keybuk> there is no ID_TYPE in the udevdb
<cjwatson> Keybuk: yeah, I got that far but couldn't see why
<cjwatson> bug 287807
<ubottu> Launchpad bug 287807 in udev "[vmware 6.5] rescue: fails to find partitions" [Undecided,New] https://launchpad.net/bugs/287807
<Keybuk> because it doesn't come from udev
<Keybuk> it's from the kernel uevent
<cjwatson> err, doesn't scsi_id write it?
<Keybuk> udev doesn't bother caching that stuff in its db, since you can get it by reading /sys/block/sda/sda1/uevent
<Keybuk> no
<cjwatson> ./extras/scsi_id/scsi_id.c:629:                 printf("ID_TYPE=%s\n", type_str);
<Keybuk> unless I'm misfollowing your problem
<cjwatson> scsi_id clearly hates that device - calc tried running it by hand at my direction and it wasn't printing anything
<cjwatson> and udevadm info prints ID_TYPE for me
<cjwatson> so the test is not intrinsically wrong AFAICS; if it were, it would fail everywhere
<calc> i'm still here if any debugging is needed
<Keybuk> could you recap the problem for me
<cjwatson> calc: let me
<calc> ok
<cjwatson> Keybuk: symptom is that rescue mode fails to detect partitions on calc's vmware emulated disk
<Keybuk> ok
<Keybuk> do other people's vmware work?
<cjwatson> Keybuk: on drilling down, this is because udevadm info -q env -p /block/sda/sda1 doesn't return any output (including ID_TYPE)
<cjwatson> haven't heard from others; I don't have a working vmware setup at the moment
<Keybuk> calc: no output at all?
<calc> i was the first person to test rescue mode afaict
<cjwatson> the emulated disk is LSI Logic, which is SCSI
<cjwatson> so scsi_id ought to print something useful, AFAICT
<cjwatson> calc: rescue mode does work for me - I've confirmed
<cjwatson> this is definitely "hardware"-specific
<calc> cjwatson: it returns output but not ID_TYPE
<cjwatson> oh, sorry, yes
<cjwatson> the screenshot is in the bug
<calc> http://launchpadlibrarian.net/18807930/bug287807.png
<Keybuk> calc: could you pastebin me the output of that udev command?
<Keybuk> ah great
<calc> Keybuk: its in that screenshot
<Keybuk> thanks
<cjwatson> ID_PATH and ID_FS_*
<cjwatson> list-devices goes "no ID_TYPE, mustn't be a disk then, better skip it"
<calc> Keybuk: there is a screenshot of strace of scsi_id also
<cjwatson> since it wants to skip other non-disk things like CDs and tapes
<Keybuk> cjwatson: that logic will bite you later, but it's not this bug ;)
<Keybuk> calc: what's the url of that?
<cjwatson> Keybuk: explain that to me later :)
<calc> http://launchpadlibrarian.net/18808130/bug287807-2.png
<Keybuk> calc: scsi_id doesn't output anything?
<calc> Keybuk: nope nothing at all
<cjwatson> '/lib/udev/scsi_id --export --whitelisted -d /dev/sda' was the invocation
<cjwatson> copied from 60-persistent-storage.rules
<calc> yea that ^
<Keybuk> ok, so that's the problem here
<Keybuk> anything in dmesg?
<calc> not that i recall
<calc> well not while running those commands anyway
<calc> i'll boot back into it and see
<Keybuk> calc: could you try it on /dev/sda1 instead?
<calc> iirc i ran '/lib/udev/scsi_id --export --whitelisted -d /dev/sda1' also with no output
<calc> i'm getting back to the rescue stage now
<Keybuk> cjwatson: did you test rescue mode in vmware or something else?
<calc> fwiw vmware < 6.5 doesn't seem to work with the intrepid kernel
<calc> at least not without some sort of kernel update
<calc> er tools software update for the kernel
<calc> i see in log this:
<calc> rescue-mode: no partitions found!
<calc> i can screenshot that if useful, but i think we already well past that point
<Keybuk> right, that fits because d-i can't find any partitions
<Keybuk> because it's iterating udev info
<Keybuk> and udev has no info about it
<Keybuk> because scsi_id isn't returning anything
<calc> scsi_id sda1 outputs nothing to screen
<Riddell> sbeattie: how did that adept hardy test go?
<Keybuk> if you strace it
<Keybuk> does it have the -EINVAL on the same ioctl?
<calc> ran as: /lib/udev/scsi_id --export --whitelisted -d /dev/sda1
<calc> lets see
<Keybuk> could you try something else for me
<Keybuk> /lib/udev/scsi_id --export --whitelisted -d /dev/sda1 -s 3
<calc> is the ioctl the 3 or the hex number?
<calc> the hex number looks like a memory address to me :)
<Keybuk> ah, -s doesn't work directly
<Keybuk> /lib/udev/scsi_id --export --whitelisted -d /dev/sda1 --sg-version 3
<calc> nothing with --sg-version 3 added
<Keybuk> damn
 * Keybuk tries to remember how to get into rescue mode <g>
<calc> last ioctl was: ioctl(3, SG_IO, 0xbf8002d0)
<calc> Keybuk: heh last option on the menu :)
<Keybuk> boot from first hard disk?
<calc> oh no not that
<cjwatson> Keybuk: kvm
<calc> hmm i thought i had hit the last option on the menu
<cjwatson> Keybuk: "rescue a broken system"
<Keybuk> it's the last option on the alternate
<Keybuk> it's not on the live
<Keybuk> I remember now
<cjwatson> yes
<Keybuk> calc: vmware 6.5 ?
<calc> yes
<Keybuk> confirmed here
<calc> i have vague memory of the drivers vmware used were slow to convert to udev so this might be a driver issue
<Keybuk> it's not a "convert to udev" issue
<calc> er i mean sysfs
<Keybuk> the driver appears to simply not implement SG
<calc> oh?
<calc> but it still gets a sg0 device?
<calc> actually those might be for the ide
<Keybuk> SG is an ioctl set for querying scsi devices
<calc> so it can have a scsi generic device without supporting SG?
<Keybuk> right
<calc> oho k
<Keybuk> cjwatson: how do I install strace on this thing?
<cjwatson> Keybuk: udpkg -i /cdrom/pool/main/s/strace/strace-udeb_*
<Keybuk> yeah getting -EINVAL again
<cjwatson> isn't there some old ioctl that predated SG_IO?
<Keybuk> honestly, I don't think this thing wants to tell anyone what it is
<slangasek> ... VMware+scsi?
<Keybuk> I bet I know why this worked before
<calc> slangasek: yea
<slangasek> isn't that the combination you're not supposed to use, or was that only for CDs?
<calc> Keybuk: because we forgot to test it? :)
<cjwatson> SCSI is what VMware recommended for hard disks when I last used it
<Keybuk> calc: we're good at that ;)
<calc> slangasek: thats default combo, scsi disk and ide cd
<cjwatson> calc: no, I used to do all my testing in VMware
<slangasek> ok, right
<cjwatson> calc: and indeed I may have developed rescue mode at least partially in VMware
<calc> i did a typical setup for the vm and just installed into it
<Keybuk> I do all my testing in vmware
<calc> cjwatson: ok
<Keybuk> though for obvious reasons, I've been focusing on desktop testing recently ;)
<Keybuk> oh arsebiscuits
<Keybuk> cjwatson: you remember how I said udev info wasn't really a stable interface?
<Keybuk> and that relying on it might one day bite you? :p
<cjwatson> as it happens, no
<Keybuk> well
<cjwatson> are there any stable interfaces for hardware detection? :-P
<Keybuk> a while back, the kernel people finally realised that hinting to userspace that something was either a disk or a partition would be jolly helpful
<cjwatson> I've just got used to having to keep up
<Keybuk> so all block devices include a DEVTYPE=disk and DEVTYPE=partition in their environment
<Keybuk> scsi_id used to have a "fallback to sysfs and figure it out" mode
<Keybuk> but the only really useful thing that did was set ID_TYPE to disk or partition
<Keybuk> since we have DEVTYPE now, and everything in udev uses that instead
<Keybuk> that code was dropped out of scsi_id
<Keybuk> so on vmware, scsi_id outputs nothing - because the driver doesn't implement that ioctl
 * slangasek writes a blog entry, "You think you want your userspace to be able to talk to your kernel, but you're wrong"
<Keybuk> slangasek: I've written many blog entries about the kernel's attitude to userspace
<slangasek> what you really want is your userspace to talk to gregkh so he can talk to your hardware :-P
<Keybuk> cjwatson: so, in summary, list-devices is relying on the existance of an environment variable in the udevdb that isn't there anymore
<Keybuk> and isn't there, because it's deprecated in favour of a different one
<Keybuk> and just to really make your day complete
<Keybuk> that different one won't be in the udevdb either, because it comes from the kernel uevent, and udev doesn't bother caching that stuff
<cjwatson> ok, so I just need to grep the uevent?
<Keybuk> I have a fairly sick suggestion
<Keybuk> actually, let's not call it sick
<Keybuk> let's call it "preserving existing behaviour"
<cjwatson> Keybuk: unfortunately CDs get DEVTYPE=disk too
<Keybuk> sure, they're disks
<cjwatson> still, we need to be able to tell them apart
<Keybuk> I think ID_CDROM is still there
<Keybuk> how about I add this udev rule somewhere
<cjwatson> is that likely to keep on working? :-P
<cjwatson> I'm happy to add DEVTYPE checking as a fallback if ID_TYPE (which seems more precise when available) isn't there
<Keybuk> ENV{ID_TYPE}!="?*", ENV{DEVTYPE}=="?*", ENV{ID_TYPE}="$env{DEVTYPE}"
<Keybuk> that would cover other cases we haven't found yet
<Keybuk> there's bound to more than d-i's list-devices relying on this
<cjwatson> mm, that sounds reasonable
<Keybuk> and we can figure out how to update it later
<cjwatson> although d-i's list-devices was expecting ID_TYPE=disk for partitions, since that's what was there before
<cjwatson> so ideally, emulate that
<Keybuk> really?!
<cjwatson> yes, it was describing the physical device not the block device I think
<Keybuk> hmm
<Keybuk> that's a tricky rule
<cjwatson> and you can still see that if you're on a device that supports the right ioctls
<Keybuk> it would end up saying that any block device is a disk
<cjwatson> $ udevadm info -q env -p /block/sda/sda1 | grep ^ID_TYPE=
<cjwatson> ID_TYPE=disk
<cjwatson> only if there wasn't some other ID_TYPE
<Keybuk> meh. it'll do for now ;)
<cjwatson> let me know if it's going to be ID_TYPE=partition because I'll need to account for that
<cjwatson> as will anything else using the udevdb for this
<Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="hd*[0-9]|sd*[!0-9]|sd*[0-9]|sr*", ENV{ID_TYPE}="disk"
<Keybuk> something like that maybe?
<Keybuk> after that
<Keybuk> # list-devices disk
<Keybuk> /dev/sda
<Keybuk> /dev/scd0
<Keybuk> # list-devices partition
<Keybuk> /dev/sda1
<Keybuk> /dev/sda2
<Keybuk> /dev/sda5
<Keybuk> --
<Keybuk> is that right?
<Keybuk> it lists the cdrom, did it used to do that?
<Keybuk> cjwatson: ^
<cjwatson> I don't think so
<Keybuk> list-devices cd still says /dev/scd0
<cjwatson> let me check though
<Keybuk> cdrom_id may have had ID_TYPE=cdrom and that's been dropped too
<cjwatson> err, somebody who actually has a hardy CD handy would be faster ...
<Keybuk> hmm, I don't have a hardy install with a CD-ROM
<Keybuk> how strange
<StevenK> cjwatson: I have a Hardy Live CD handy-ish
<cjwatson> ata_id said ID_TYPE=cd, and that doesn't seem to have changed
<cjwatson> scsi_id might have stopped saying so
<cjwatson> cdrom_id didn't output ID_TYPE=anything in hardy
<Keybuk> right
<Keybuk> ata_id doesn't get called
<Keybuk> I have 7.10 handy
<cjwatson> maybe just KERNEL=="sr*", ENV{ID_TYPE}="cd" for compat
<cjwatson> (obviously with the other conditions)
<TheMuso> /c/c
<Keybuk> hmm
<Keybuk> yeah it had ID_TYPE=cd before
<Keybuk> ok that seems to work
<Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="hd*[0-9]|sd*[!0-9]|sd*[0-9]", ENV{ID_TYPE}="disk"
<Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="sr[0-9]*", ENV{ID_TYPE}="cd"
<Keybuk> as 65-id-type.rules
<Keybuk> list-devices shows /dev/scd0 for "cd", /dev/sda for "disk" and /dev/sda[125] for "partition"
<cjwatson> Keybuk: that sounds good
<Keybuk> http://people.ubuntu.com/~scott/udev_124-7.debdiff
<Keybuk> mind a quick review?
<cjwatson> (can we get this bug targeted and milestoned and such?)
<cjwatson> sd*[!0-9]|sd*[0-9] isn't that equivalent to sd?*
<Keybuk> just done that
<cjwatson> ?
<Keybuk> was typing a comment
<Keybuk> cjwatson: I was replicating the exact condition from persistent-storage.rules
<cjwatson> how about cciss?
<cjwatson> since it's in persistent-storage.rules :)
<Keybuk> I don't know that those are :p
<Keybuk> are they disks or cd-drives, or something else?
<calc> Keybuk: should the bug be attached to the kernel also for that driver to be updated?
<Keybuk> calc: I find such bugs somewhat ... pointless
<calc> ok
<cjwatson> cciss => RAID controller => disks
<Keybuk> ok, added
 * Keybuk uploads
<cjwatson> thanks!
<Keybuk> and now, to the bedmobile!
<NCommander> hey geser__
<slangasek> jdstrand, kirkland: server testing still ongoing?
<kirkland> slangasek: yeah
<kirkland> slangasek: pam question for you
<kirkland> slangasek: specifically unix_chkpwd
<kirkland> slangasek: i can get this to work from the command line:
<kirkland> slangasek: echo "passwd\0" | /sbin/unix_chkpwd "username" nullok
<kirkland> slangasek: that works well, as expected
<kirkland> slangasek: as soon as i put that into a script, though, i get rc=7
<kirkland> slangasek: is that by design?
<kirkland> slangasek: is there a way to work around that?
<slangasek> 7 is 'PAM_AUTH_ERR'
<slangasek> it is, generally, by design; this script is not meant to be called by anything except pam_unix
<slangasek> it's a helper script /for/ pam_unix, not an interface /to/ pam_unix
<kirkland> slangasek: hrm
<slangasek> as for why it fails, I'd guess that when you put it in a script, it's being run under dash and dash is laughing at you for using \0 ?
<kirkland> slangasek: i've tried a handful of escapes
<slangasek> maybe you want echo -n "passwd" or printf passwd
<kirkland> slangasek: k
<sbeattie> Riddell: I commented on the adept bug for hardy-proposed
<kirkland> slangasek: server raid installs look good
<slangasek> kirkland: good-o - are you going through the test cases on http://iso.qa.ubuntu.com/qatracker/test/2104 or http://iso.qa.ubuntu.com/qatracker/test/2105 ?
<kirkland> slangasek: i'm testing more interesting raid setups than that ;-)
<slangasek> well, we kinda need to be sure that the standard tests are also covered
<kirkland> slangasek: sure, i'll do those too
<slangasek> there /shouldn't/ be anything that's changed in the last reroll that would affect them, but still
<superm1> slangasek, are there some known issues with the alternates hanging in the middle of package installs in virtualbox?  i can still switch VTs in the VM, but it's just sitting there not doing anything for 25+ minutes on bash-completion
<kirkland> slangasek: i'm on amd64
<slangasek> superm1: sorry, I haven't heard of anything like that
<superm1> slangasek, okay let me see if this hardware supports kvm, and i'll try that instead
<ScottK> Wasn't Riddell mentioning some long hangs.
<ScottK> I think he uses amd64
<superm1> this was i386
<ScottK> Ah.
<ScottK> Mixed my lines on the scroll
<slangasek> the long hangs were with DVDs, not alternates
<ScottK> Ah.
<jdstrand> slangasek: fyi-- all my assigned iso tests passed just fine
<jdstrand> dendrobates: ^
<dendrobates> jdstrand: good deal.
<superm1> slangasek, what was decided about those long DVD hangs?
<kirkland> dendrobates: my iso testing was fine too
<dendrobates> kirkland: also good.
<kirkland> slangasek: do you have time to sponsor an ecryptfs upload, fixes two bugs?
<persia> kirkland, That requires respin of *all* the CDs.  Can it wait until post-RC?
<persia> (and DVDs and USB images)
<kirkland> persia: post-RC is fine
<ScottK> persia: Accepting requires that, not uploading.
<kirkland> pre-ga
<persia> ScottK, Good point.
<kirkland> upload can wait for tomorrow then
 * persia was fearful of another repeat, having spent the past 24 hours chasing image rebuilds as much as anything else.
<superm1> slangasek, okay alternates look good for mythbuntu.  looks like Virtualbox just hates me, but kvm likes me
<calc> hmm some tests still not run on kubuntu/ubuntu (/me gets back to working on them)
 * calc hopes we get 2.6.29 with ext4 install support in jaunty
<wgrant> calc: We have ext4dev in Intrepid.
<calc> wgrant: yea it went out of dev status a few weeks ago and will be in 2.6.28 as regular fs
<calc> wgrant: can we install using ext4dev in intrepid already?
<wgrant> I don't think so.
 * calc read that 2.6.28 will need a lot of already existing stablization patches for ext4 to be ready to be used
<calc> so maybe by 2.6.29 it will have shaken out enough to be usable
 * TheMuso is not sure he will go near it for a few kernel releases. Let those who are willing to risk their data try it first. :p
<Hobbsee> evand: you around?
<calc> TheMuso: heh :)
<calc> TheMuso: i should have done that for XFS
<TheMuso> When I heard that one couldn't use XFS accross  32-bit and 64-bit install, I decided never to touch it.
<calc> if i read correctly both opensuse and fedora's next releases will support it, not sure if they will default to it or not
<calc> TheMuso: oh ugh
<ScottK> calc: Ugh is TheMuso's line.
<calc> TheMuso: didn't know about that, when i used it was well before amd64 arch was released
<TheMuso> calc: That was a year ago or so, but things may have changed.
<TheMuso> ScottK: har har har.
<ScottK> Actually not for a long time that I've seen though.
<ajmitch> TheMuso: issues like that scare me
<TheMuso> ajmitch: me too.
<TheMuso> Hense staying away from XFS.
 * persia likes to use the oldest filesystem supported by Mr. Tso.  It's always fairly reliable, if perhaps not fast or featureful.
 * ScottK recently had to unbork a ReiserFS system that was set up long enough ago that was a reasonable choice.
<ScottK> That was 'fun'.
<sbeattie> persia: you and me both. I prefer to keep my data in exchange for giving up whatever 5-10% performance gain the others may offer (having seen several ex-coworkers lose data thanks to reiserfs)
<persia> sbeattie, Note however that we probably play just as much catchup as anyone else.  I suspect there's a lot of data we'll both want to move off ext2 soon enough.
<persia> (and from what I understand, my latest disk doesn't behave like the old ext2 versions anyway)
<Hobbsee> evand: added to the bug, enjoy :)
<TheMuso> I got burnt by reiserfs early on, have never touched it again.
 * NCommander uses ext3 and jfs
<dholbach> good morning
<dholbach> can somebody accept the ubuntu-docs, example-content, vino and gnome-applets uploads from yesterday? :)
<dholbach> errr, vinagre
<dholbach> instead of vino
<persia> dholbach, CDs haven't been pushed to release yet.
<persia> s/release/releases/
<slangasek> superm1: the long DVD hangs were really just ubiquity having to calculate a very large list of files for its "do I copy this part of the fs or not" handling, AFAIK; can probably be optimized better, but otherwise not a bug per se
<slangasek> kirkland: not until Friday, frankly
<slangasek> superm1: glad to hear the alternates check out
<slangasek> (also, glad to now have this info on the iso tracker :)
<slangasek> dholbach: certainly not, not until RC is released
<TheMuso> slangasek: studio all done, at least from my perspective.
<slangasek> good, good
<slangasek> gah, why is the iso tracker not loading for me
<TheMuso> its slowhere too.
<TheMuso> here
<lool> morning
<slangasek> kirkland, jdstrand, dendrobates: I see zero test results for server i386 following that last respin...
<Koon> slangasek: I'm on it
<slangasek> Koon: excellent, thank you
<Koon> slangasek: won't be able to do all tests though, anything special that might have changed since yesterday ?
<slangasek> Koon: nothing that should have affected any of the test cases
<slangasek> but we need re-testing anyway
<Koon> sure
<slangasek> saivann: why is bug #285323 "triaged"?  that implies that a developer has all the information needed to fix the bug, but if that refers to yourself, why did you need another person to confirm it before marking it 'triaged'/
<ubottu> Launchpad bug 285323 in xorg "Loosing keyboard and mouse control when changing screen brightness with fn + arrow under intrepid" [Undecided,New] https://launchpad.net/bugs/285323
<pitti> Good morning
<StevenK> Morning pitti
<geser> Hi pitti, StevenK
<pitti> james_w: that's the question I asked myself; I'd really like to see it in the final, so that the live CD works as well, but I'm not sure how many other people tested it
<pitti> james_w: however, I really gave it a good beating (stresstest script, VTs, several Xes, etc.) and it works really well
<pitti> sbeattie: oh, it affects all setuid programs, not just sudo? I have to look; there are probably not many you'd want guest to run, though
<sbeattie> pitti: that's my guess, but I haven't verified.
<sbeattie> pitti: I may be mis-guessing as to what it affects; I'm verifying now.
<sbeattie> pitti: sorry, you're correct. It must be the post-auth setuid() call that's failing, not the ability to start the program. That seems like a legit rejection then, even if sudo doesn't explain it very well.
<pitti> sbeattie: yeah, I guess the output isn't very nice
<sbeattie> pitti: I think the ideal solution would be for the default configuration of sudo to not allow the guest user to run sudo.,
<pitti> sbeattie: you mean add that to the apparmor profile?
<pitti> sbeattie: that's tricky, currently apparmor doesn't allow "set substraction"
<sbeattie> pitti: no
<pitti> I. e. it can't say /usr/bin/* but not /usr/bin/sudo
<sbeattie> pitti: actually, with deny rules, which should be intrepid, you should be able to say exactly that.
<sbeattie> should be in intrepid's apparmor, that is.
<pitti> sbeattie: hm, it's not in man apparmor.d then
<sbeattie> (but I *highly* doubt it's very well tested at all)
<sbeattie> pitti: shocking! (or not)
<pitti> sbeattie: indeed I wish there was an access mode "none'
<pitti> so that I could write
<pitti>   /usr/bin/* rmix,
<pitti>   /usr/bin/sudo none,
<pitti> that worked in grsecurity, but I haven't found a way to model it in apparmor
<pitti> in grsecurity, then user would then not even "see" sudo
<sbeattie> pitti: http://developer.novell.com/wiki/index.php/Apparmor_2_3#Deny_rules
<pitti> sbeattie: nice!
<sbeattie> pitti: the initial approach I was thinking of, and is probably a much safer last minute change, would be to deny in sudoers the guest user the ability to do anything in sudo.
<sbeattie> or, honestly, this could wait for an SRU.
<pitti> sbeattie: it's just a cosmetical thing anyway, I guess
<sbeattie> yeah
<pitti> sbeattie: however, sudoers is already configured to not allow anything for guest
<pitti> sbeattie: at least it says "operation not permitted"
<pitti> it could say "stomp yourself at your foot, a measly guest user does not have such powah"
<pitti> sbeattie: I'm a bit scared about adding guest to the default sudoers
<tkamppeter> pitti, hi
<pitti> it wouldn't work for upgrades anyway, and the guest user is only temporary, and folks might already have a real guest user
<pitti> hi tkamppeter
<tkamppeter> pitti, I did a tiny bug fix on foomatic-filters, see http://pastebin.ubuntu.com/61399/
<tkamppeter> Would you take it into Intrepid when I upload it?
<pitti> tkamppeter: no, that should become an SRU
<tkamppeter> pitti, OK. I only wanted to ask.
<pitti> tkamppeter: can you please open an Ubuntu bug about it and subscribe ubuntu-sru? we can already upload it to intrepid-proposed, but it won't be accepted until after the release
<pitti> tkamppeter: sorry
<tkamppeter> It is also not that much important, I only asked because it was an obvious one-liner. With the PDF workflow this code does perhaps even not get touched.
<tkamppeter> pitti, so I will upload Foomatic 4.0 final into Jaunty as soon as I have released it upstream.
<sbeattie> pitti: okay, you're correct, even if you allow the guest-session apparmor profile what it needs and set a passwd for guest, sudo claims the guest user isn't in sudoers and so doesn't let it do anything.
 * sbeattie shuts up about it now.
<torkel> pitti: do you have any plans of updating your v4l-dvb-dkms ppa package? Mostly for a newer v4l-dvb snapshot, but also add it to Intrepid?
<pitti> torkel: not right now; from my side it was pretty much just an experiment
<pitti> in hardy it's utterly hard to get it truly right, becaue of the separate linux-ubuntu-modules headers
<pitti> I tried for an hour or two and gave up
<pitti> and intrepid's kernel is fairly recent, so many cards work OOTB now
<pitti> torkel: want to adopt it? :-)
<torkel> pitti: not af9015 based cards :-(
<pitti> so with intrepid supporting my card OOTB I have nothing to test with, and no real incentive either any more, I guess
<torkel> pitti: well. I can take a look at it, but I can't promise anything, and I really don't have the time adopt it fulltime :-)
<pitti> torkel: for intrepid maintenance should actually be easy; git pull, run script, test, done
<pitti> torkel: it would be much more intersting for hardy, if anyone could ever figure out how the heck to build kmods properly against linux and lum
<pitti> torkel: erm, s/git/hg/ :)
<torkel> everything needed are in your ppa package? Execpt for the v4l-dvb source?
<pitti> torkel: I'm not sure whether it includes the make-dkms.sh script
<pitti> torkel: if not, I just put it at http://people.ubuntu.com/~pitti/scripts/make-v4l-dkms.sh
<pitti> torkel: that builds a dkms.conf from the checked out hg tree
<torkel> pitti: thanks a lot. Now I have something to do on my vacation next week :-)
<pitti> torkel: hehe
<pitti> doko: the remaining rdepends of gcc-4.1 are linux-ports and klibc; I guess that won't change for intrepid, so would you mind if I promote g++-4.1 libmudflap0-dev libstdc++6-4.1-dev? they are pulled in with recommends
<doko> pitti: please keep the old c++ out of main, if possible. it's really not needed.
<pitti> doko: then we need to upload gcc-4.1 to drop the recommends
<doko> have to see why it is pulled in
<pitti> doko: gcc-4.1 recommends libmudflap0-dev, libstdc++6-4.1-dbg recommends libstdc++6-4.1-dev
<doko> pitti: the latter should be fixed in the seeds
<doko> I'll drop the first one to a suggests
<pitti> yeah, we can demote libstdc++6-4.1-dbg easily
<pitti> doko: ^ done
<doko> thanks
<pitti> hm, so what pulls in g++-4.1
<pitti> ah, libstdc++6-4.1-dev depends on it
<pitti> so that should be fixed with the demotion
<pitti> doko: is libmudflap0-dev in main really bad enough to warrant a gcc-4.1 upload at this stage?
<doko> pitti: I would like to keep it outside.
<cjwatson> calc: if it's out of development status, we should certainly be able to support ext4 in jaunty
<directhex> cjwatson, is it backward-compatible? and still ass-slow at deletes?
<cjwatson> how should I know? :)
<directhex> you're smart!
<cjwatson> also busy
<cjwatson> so I don't tend to do much in the way of random filesystem exploration when it isn't something I need to do
<pitti> calc: do you know openoffice.org-emailmerge? It's recommended by -writer, so either we need to drop the recommends, or promote -emailmerge to main and thus install it by defautl
<pitti> calc: the latter would avoid another OO.o upload, but is of course subject to feature freeze
<pitti> calc: do you know aobut the status/sanity of this package?
<davmor2> tseliot: did you and Riddell get to the bottom of the jockey-kde issue?
<pitti> davmor2: iz kdesudo weirdness; I uploaded a package which fixes the desktop file (thanks to tseliot), so it should be good after RC
<tseliot> davmor2: ^^
<davmor2> pitti: okay cool.
<pitti> doko: can you please look at the line with "gcc-4.3" on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt ?
<pitti> Riddell: ./kubuntu.intrepid/desktop: * (gnupg-agent) # for SMIME e-mail support
<pitti> Riddell: nothing depends on gnupg2 or gpgsm, and nothing else rdepends on gnupg-agent; is that still actually relevant?
<doko> pitti: this is expected. these are powerpc and hppa things. I'll seed gcc-4.3-locales gfortran-4.3-multilib libstdc++6-4.3-pic
<pitti> doko: ah, ok; right, c-m has quite a bunch of ia64/linux-ports bits I'm just going to ignore
<pitti> but at least some of those look releavant
<pitti> doko: you seed them to supported-development in ubuntu.platform?
<doko> pitti: ?
<doko> new section in development?
<pitti> doko: <doko> I'll seed gcc-4.3-locales [...]
<pitti> doko: platform.intrepid has a "supported-development" component
<pitti> seems like a good fit to me?
<pitti> doko: gcc-4.3-locales should probably go to universe, though
<pitti> doko: since it's empty (stripped and shipped in langpacks)
<pitti> cjwatson: do you happen to know about linux-firmware? it also builds nic-firmware, scsi-firmware, which aren't seeded/depended on by anything
<cjwatson> I'll seed those, d-i uses them
<pitti> cjwatson: oh, seems they are actually udebs without being named "-udeb"?
<Riddell> pitti: ScottK tends to know best about that
<pitti> Riddell: okay, thanks
<cjwatson> pitti: that isn't a universal naming scheme, by far
<cjwatson> most of d-i's core udebs aren't -udeb
<pitti> ScottK: nothing depends on gnupg2 or gpgsm, and nothing else rdepends on gnupg-agent; is that still actually relevant?
<pitti> ScottK: ./kubuntu.intrepid/desktop: * (gnupg-agent) # for SMIME e-mail support
<cjwatson> -udeb is mostly for when we want a .udeb equivalent of something that's already a .deb
<pitti> cjwatson: ah, ok; thanks
<amitk> should this command work?  apt-get source gtk-vnc=0.3.6-2ubuntu2
<pitti> amitk: no, because that version doesn't exist anywhere
<pitti> amitk: well, you can dig out old versions from Launchpad, but they aren't indexed in Sources.gz
<directhex> pitti, gnupg-agent is evil.
<amitk> pitti: 0.3.4-0ubuntu exists, but apt-get source doesn't work for that version either http://www.nic.funet.fi/pub/mirrors/archive.ubuntu.com/pool/main/g/gtk-vnc/python-gtk-vnc_0.3.4-0ubuntu2_amd64.deb
<amitk> or am i going about this all wrong? How do I get a source-controlled tree so I can revert to a specific version?
<directhex> pitti, ( http://bugs.debian.org/499569 )
<pitti> amitk: that's the hardy version; so if you have deb-src for hardy main in your apt sources, it should work
<pitti> directhex: oh, seems we should sync that then, perhaps?
<directhex> pitti, i would. it would fix f-spot hanging for at least some users. but i didn't get enough confirmations that it did the right thing to push for it
<liw> someone's made an icon for system-cleaner, http://launchpadlibrarian.net/18814154/C%3A%5CDocuments%20and%20Settings%5Cmarcorodrigues%5CAmbiente%20de%20trabalho%5Cicon_sc%5Csc_ico_24x24.png -- what license should I ask him to use?
<pitti> liw: cute!
<pitti> liw: well, any free license is good really, but ideally GPL or at least CC-BY-SA
<directhex> liw, WTFPL
<directhex> dfsg-free and simple for anyone to understand
<cjwatson> liw: the same licence as the application
<cjwatson> (would be my preference)
<liw> cjwatson, yeah, mine too
 * liw points at Kmos :)
<persia> liw?
<mvo> liw: that is nice
<liw> (Kmos made the icon)
<persia> Oh, excellent!
<pitti> seb128: I'm uploading file-roller with the p7zip recommends dropped to suggests (we have never installed it anyway by default); I think everything else is too late now
<seb128> pitti: we didn't? we should ... but right if that's late for intrepid
<pitti> seb128: yeah, something to consider for jaunty indeed
<pitti> seb128: but it's fairly big, in universe, and not really tested
<seb128> ok
<juliux> mdz: ogra gaves me a hint that you are working on the brigthness keys on ibm thinkpad, i have a x41 tablet and the keys are not working properly atm, if i press a the key it takes a long long time after there is a reaction, if i should test anythin give me a ping;)
<mdz> juliux: I fixed a problem where they didn't work at all.  it's known that they work slowly on some models, but I have not investigated the reason for that
<mdz> juliux: if you find the relevant bug report, let me know as I do have a system which exhibits this behaviour
<StevenK> They work fine on my X40 if that's a useful data point
<mdz> StevenK: hardware or software controlled?
<mdz> this seems to affect the software-controlled ones
<mdz> there's about a 1-second delay for me
<StevenK> mdz: I'm guessing it's hardware, but how do I check?
<mdz> StevenK: lshal |grep brightness
<mdz> StevenK: and if it works even when acpid/hal/etc. aren't running
<StevenK> mdz: They work even if the machine is in the middle of booting
<mdz> StevenK: hardware
<mdz> (firmware, but who's counting)
<cjwatson> asac: could you join #ubuntu-release?
<ScottK> pitti: Yes.  To make S/MIME and GPG signing work in Kmail you need gnupg-agent (which was a spec'ed capability starting with Gutsy).  If it's not in the Kmail depends/recommends, it should be.  Please leave it seeded.
<pitti> ScottK: okay, sure
<pitti> ScottK: so we should probably fix debian bug 499569 then, since it's isntalled by default in Kubuntu?
<pitti> ScottK: i. e. sync, or backport the fix
<ScottK> pitti: Yes.  I agree we want that fix.
<ScottK> Urgh.
<directhex> yay
<asac> cjwatson: sure
<pitti> ScottK: can I leave investigation to you or another delegate? I'm still 120% busy with component-mismatches and an urgent kernel bug
<ScottK> pitti: Yes.
<pitti> ScottK: cheers
<J_P> hi all
<J_P> ubuntu 8.10 will be released with OpenOffice3 ?
<Hobbsee> J_P: no
<J_P> :-(
<pitti> doko: do you happen to know about libdv? it currently recommends oss-compat, which seems pretty crackful to me
<pitti> doko: I'm currently preparing an upload which drops that recommends, but I'd like to get a second opinion
<doko> pitti: no, just touched that for some build problem
<pitti> doko: ok, nevermind then
<seb128> persia: any news about the glibmm2.4 update?
<persia> seb128, No feedback at all.  Sorry.  Please don't let that hold you up : if you could mention "Thanks to Mitsuya Shibata" in the changelog, that'd be great : he's not worried about changelog credits.
<persia> (at least based on several other conversations about other packages)
<seb128> persia: ok
<persia> Err.  s/changelog credits/Changed-By: credits/
 * ogra wonders if he's the only one seeing broken focus handling since a while 
<ogra> i see no bug about it on any of the lists
<pitti> ogra: compiz behaves badly when switchign virtual desktops; it otherwise works quite fine, WDYM?
<ogra> pitti, atl tab often leaves the focus in the former window for me
<ogra> i.e. o often type IRC text into the firefox url bar recently though having the xchat win in front of me
<kwwii> liw: http://sinecera.de/wiper24.png --> how about that? the vacuum cleaner looked like a little blob at 24x24
<ogra> whom do you want to crucify on that  ?
<pitti> a razor?
<cjwatson> last I checked a cross had a bit at the top as well ;)
 * persia likes http://launchpadlibrarian.net/18814154/C%3A%5CDocuments%20and%20Settings%5Cmarcorodrigues%5CAmbiente%20de%20trabalho%5Cicon_sc%5Csc_ico_24x24.png : still good at 24x24, and harder to confuse with the letter T
<kwwii> it's supposed to be a squeegee :p
<ogra> probably put a baloon with "SQEEEEK !" on it ? :)
<persia> At 24x24, that's flyspeck 3, which isn't very legible.
<ogra> heh
<ogra> how about a looking glass ....
<ogra> ... shipped with the CDs
<ogra> ;)
<kwwii> as an interesting side-point you should see the other definition of squeegee (spelled squeegie)...nasty though, be warned
<persia> !ohmy
<ubottu> Please watch your language and topic to help keep this channel family friendly.
<persia> :p
<kwwii> I thought about a little housewife in apron, talking on the phone with a duster in one and and a vacuum in another but somehow that didn't work at 24x24 pixels :p
<kwwii> perhaps if she was also dancing a jig it would be clearer
<StevenK> kwwii: "Why doesn't System Cleaner also cook?"
<ogra> that brings up the question about her secret boyfriend on the other end of the phone as well ..
<persia> Ummmm ...
<kwwii> StevenK: hehe, don't get sexist on me
<mathiaz> pitti: server i386 testing completed
<mathiaz> pitti: esx is the only one missing and I don't have access to an ESX environment.
<mathiaz> pitti: so I think we're good to go with -server
<pitti> mathiaz: rock, thanks
<ScottK> pitti: On the gnupg-agent bug, it doesn't seem to be reproducable in Intrepid Kubuntu.  If you have a moment to ponder, would we be better off to take the fix 'just in case' or leave it be I wonder?
<elmo> how do I get the full range of mixer options back? :(
<pitti> ScottK: if it isn't OMGbreakseverything, we should leave it for an SRU
<ScottK> pitti: OK.  Thanks.
<directhex> ScottK, did you log out/in after installing gnupg-agent? and you're definitely on i386?
<ScottK> directhex: I didn't do the test.  I'll double check.
 * ScottK has been getting kids out the door to school.
<directhex> pfft kids. sounds like effort
<ScottK> directhex: Did you try to reproduce it?
<ScottK> directhex: Definitely.
<directhex> ScottK, not recently. i'll try and find the time this afternoon, but by the time I have a VM installed...
<ScottK> directhex: You've seen it in the past though?
<calc> pitti: emailmerge package allows for being able to send emails via mail merge so yea its useful to have in main
<directhex> ScottK, the sigblk problem? yes. on upgrade installs only though, due to gnupg-agent being left behind from an old release
<calc> pitti: iirc it used to be in writer directly
<ScottK> directhex: Not a lot we can do about that in Intrepid then.
<directhex> ScottK, well, if they upgrade to intrepid and get a non-buggy gnupg-agent, issues go away, no?
<directhex> brb, catching a bus
<ScottK> Yes.  The real question is is the Intrepid one non-buggy
<pitti> calc: could you install it and do some testing whether it works properly? If we promote it now, it'll land on the final CDs, so we should better make sure it works
<calc> pitti: afaik it was on hardy cd as well but as part of -writer
<calc> pitti: i have it installed i will see if i can send out a merged document with it
<pitti> calc: thanks
<tseliot> persia: I have fixed this bug and provided upstream with a patch: https://bugs.launchpad.net/abiword/+bug/284857
<ubottu> Ubuntu bug 284857 in abiword "Abiword crashes on using "Create and modify styles..." from the format menu" [Unknown,Confirmed]
<tseliot> pitti: would a debdiff be ok for this bug? ^^
<persia> tseliot, Thanks for that.  I can't upload abiword, so you'll need to find another sponsor.
<tseliot> persia: ok, no problem ;)
<pitti> tseliot: absolutely, although it sounds like an SRU
<persia> tseliot, Looking at your patch, I no longer pretend to understand why it works in Xubuntu and not in Ubuntu.
<tseliot> pitti: SRU or FFE?
<pitti> tseliot: FF? I thought it's a bug fix?
<tseliot> persia: I have no idea
<tseliot> a bugfix
<tseliot> pitti: a bug fix in Intrepid
<tseliot> persia: do you know if the problem affects Hardy too?
<pitti> tseliot: so, no FF :) I really meant SRU, unless you can convince slangasek (my feeling is SRU, though)
<tseliot> pitti: do you call them SRUs after the RC is released?
<pitti> tseliot: lol :)
<pitti> tseliot: no, SRU -> after the final
<tseliot> pitti: and why did you call it SRU if I can provide a fix now?
<pitti> tseliot: just to avoid large uploads/rebuilds after RC
<persia> tseliot, No idea.  I only heard about the bug because someone asked for help in #ubuntu-motu.  I pointed them at the Xubuntu devs as the most likely to be interested, and I added the comment to the bug.
<tseliot> pitti: do we really want to release Ubuntu with an annoying bug which I fixed with just one line?
<tseliot> persia: ok
<pitti> tseliot: the patch is probably fine, I'm more scared about misbuilds at this time
<pitti> tseliot: see yesterday's libvisual-0.4-plugins debacle
<NCommander> persia, what about Xubuntu?
<pitti> tseliot: a mere rebuild broke the entire desktop
<tseliot> pitti: ouch
<NCommander> Thats impressive
<persia> NCommander, abiword bug.
<tseliot> NCommander: bug 284857
<ubottu> Launchpad bug 284857 in abiword "Abiword crashes on using "Create and modify styles..." from the format menu" [Unknown,Confirmed] https://launchpad.net/bugs/284857
<persia> elmo: pavucontrol?
<ScottK> pitti: Revised story on gnupg-agent: Bug confirmed on Intrepid by multiple sources.  The bug in the previous upload is also confirmed.  I think we should sync after the RC is out.
<pitti> ScottK: previous upload> you mean -2 to -3?
<ScottK> Yes
<ScottK> It's also a very small fix.
<pitti> ok, great
<pitti> thanks a lot for testing
<ScottK> NCommander: ^^ Thanks for testing.
<NCommander> :-)
<NCommander> pitti, I think the abiword issue can be fixed via SRU at release
<calc> got my passport/visa back today
<calc> fedex decided it would be funny to ring the doorbell about 7 times quickly, luckily my son didn't wake up
<calc> hmm chinese visa takes a whole page
<ArneGoetje> calc: same for any other country's visa. ;)
<directhex> nah, cuban visa doesn't
<directhex> doesn't get permanently attached to passport either, though
<ArneGoetje> directhex: hah... I wonder why... ;)
<calc> ArneGoetje: ah ok
<calc> directhex: hehe
<calc> directhex: if they didn't you probably wind back there in gitmo :\
<bryce> calc, where'd you need a visa for?
<directhex> calc, yeah, probably. yay for the world police :/
<calc> bryce: beijing for ooocon
<bryce> ahh
<ogra> bryce, his flight to mountainview is probably going via peking :)
<ArneGoetje> calc: when you arrive in beijing, only take the red taxis which show the fee on the door. don't listen to the guys at the airport who want to have 400 yuan for a trip to downtown... that's rip off. :)
<calc> ArneGoetje: ok
<ArneGoetje> calc: 80 ~ 100 yuan is normal for a trip to downtown, depending on where you go.
<calc> ok
<Keybuk> Riddell: daily -> Install worked for me again
<Riddell> Keybuk: from the desktop CD?  ubiquity started?
<Keybuk> yup
<Riddell> Keybuk: without the desktop starting?  is there any background?
<Keybuk> there is no background
<Keybuk> if I unmaximise the window, behind is black
<Keybuk> but strangely if I maximise and unmaximise again, behind is grey
<Riddell> Keybuk: anything in /var/crash ?
<Riddell> Keybuk: could you attach /var/log/installer/dm to bug 285626 ?
<ubottu> Launchpad bug 285626 in ubiquity "blank window on livecd with "Install" boot option" [High,Confirmed] https://launchpad.net/bugs/285626
<Keybuk> how do I look in there?
<Keybuk> how do I get to a shell?
<Riddell> Keybuk: control-alt-F1
<Keybuk> oh, duh
<Keybuk> sorry, I was trying to find KDE-like Run dialogs :p
<Keybuk> Riddell: works if I disable acceleration emulation too
<Keybuk> Riddell: attached log to the bug
<liw> kwwii, now I have an embarrassment of riches to choose from... I'll ponder, thanks
<bryce> kwwii: I really like the new background.
<bryce> kwwii: have you gotten much feedback so far?
<kwwii> bryce: yes, quite a few people like it :-)
<bryce> kwwii: cool
<kwwii> liw: well, I think I will keep working on another idea, not so sure I like the squeegee
<mib_950n06> join #ubuntu-release
<mib_950n06> sorry, ignore that plx
<bluefoxicy> o guys
<bluefoxicy> I have some little things about Intrepid
<bluefoxicy> like, it would have been nice to have OpenOffice.org 3
<bluefoxicy> Maybe have the Firefox plug-in in main
<bluefoxicy> oh and also
<bluefoxicy> damn imageshack
<bluefoxicy> http://i33.tinypic.com/33y2i3q.jpg
<bluefoxicy> It'd be nice if it didn't spend, oh, 3 minutes saying "Loading hardware drivers" at boot.
<bluefoxicy> (3:30 boot time?)
<saivann> slangasek : Concerning bug #285323 , this bug has enough information so a developer can take a look at it and start working on a fix (however I can't know if developer has all information needed to fix the bug, but enough to start working on that bug). That's why I marked it as "triaged". The affected hardware, logs and steps to reproduce are clear and confirmed by two person.
<ubottu> Launchpad bug 285323 in xorg "Loosing keyboard and mouse control when changing screen brightness with fn + arrow under intrepid" [Undecided,New] https://launchpad.net/bugs/285323
<jdong> bluefoxicy: the openoffice.org thing is a dead horse at this point...
<mib_950n06> that's a long time, have you tried pressing ctrl+alt+f1 to see what it's doing when booting?
<ScottK> jdong: Got a moment for a backports policy discussion?
<saivann> slangasek : Is "triaged" status a problem here in your opinion?
<jdong> ScottK: yeah, I've gotta leave this class in 5min though
<ScottK> Should be enough.
<jdong> k
<ScottK> jdong: Shortly I want to backport clamav 0.94.1 Intrepid -> Hardy.
<ScottK> The problem is that avscan upstream has vanished and avscan doesnt' work at all with later than 0.92.
<ScottK> jdong: So I'm considering the hack of making the backports clamav conflict with avscan so it doesn't get installed and break it.
<ScottK> Or maybe breaks is better (I need to look_
<ScottK> )
<jdong> ScottK: I was going to sugest that too. either breaks and/or conflicts, whichever makes Update Manager scream less
<jdong> ScottK: but I think the idea is reasonable
<bluefoxicy> jdong:  Even OpenOffice.org loads faster than Ubuntu now.
<ScottK> jdong: If an rdepend can't be fixed up to work with the new version, it seems better than not doing the backport.
<jdong> bluefoxicy: yeah you've got some weird bug going on there in your bootup sequences
<ScottK> jdong: Thanks.
<bluefoxicy> jdong:  what should I file, besides a bootchart screen shot?
<jdong> ScottK: sure thing. In this case I agree -- better to give the new clamav and drop support for one of the rdepends
<ScottK> OK.  Great.
<jdong> ScottK: make a note of this in the backport's changelog though
<ScottK> Of course.
<jdong> cool :)
<tseliot> cody-somerville: it looks like a new debdiff for abiword is already available. Let me know if there's something else I can do
<cody-somerville> tseliot, you provided the actual patch
<cody-somerville> tseliot, so, w00t w00t, thanks :)
<tseliot> cody-somerville: thanks to you for the upload ;)
<cjwatson> TheMuso: shouldn't bug 287862 be on ubuntustudio-meta rather than ubuntu-meta? also, if it's critical, it needs to be targeted and milestoned
<ubottu> Launchpad bug 287862 in ubuntu-meta "UbuntuStudio sounds do not play unless ubuntu sound theme is	installed." [Critical,Triaged] https://launchpad.net/bugs/287862
<psusi> TheMuso: ping... any chance of getting in a quick fix to dmraid that fixes a regression by disabling an incorrect dpatch before the release?  see bug #287751
<ubottu> Launchpad bug 287751 in dmraid "[Intrepid] dmraid 5 error: "raid4-5" not in kernel" [Undecided,In progress] https://launchpad.net/bugs/287751
<cjwatson> psusi: I've targeted that by virtue of it being a regression
<cjwatson> TheMuso: please do try to get that one in
<cjwatson> (if it makes sense to you obviously)
<psusi> k... just need to disable that dpatch is all... not sure why but the target name used to be wrong in the kernel so BenC patched dmraid, and now the kernel has it right, so the patch needs disabled
<cjwatson> psusi: are we confused because the module name is still dm-raid4-5, perhaps?
<psusi> hrm... maybe....
<cjwatson> dm-raid4-5.c:#define    TARGET  "dm-raid45"
<cjwatson> lovely
<psusi> I just know that when I looked in the kernel sources, it's raid45
<cjwatson> yes, it is
<BenC> psusi: I seem to remember this coming up early in the release, and I told someone that the kernel was going to remain stock with upstream and userspace needed to be changed to match it
<psusi> BenC: it looks like our kernel used to be 4-5, and the upstream dmraid was just 45, you made a dpatch to dmraid to change it to 4-5 to work with our kernel
<psusi> now it looks like our kernel is just 45, so the dpatch makes dmaraid fail
<BenC> psusi: I never created a dpatch
<BenC> psusi: There are no dpatch's in our kernel
<psusi> BenC: no, the dpatch is in dmraid
<psusi> you changed dmraid to use the target "raid4-5" instead of "raid45"
<BenC> psusi: Ok, right, I changed it to match the kernel module
<BenC> psusi: because, IMO, the kernel module sets the naming convention, and userspace needs to follow it
<psusi> well at last right now though the kernel module uses "raid45"
<cjwatson> BenC: the kernel module and the target name are different, though
<RainCT> uhm.. why does rosegarden depend on dolphine?
<cjwatson> look at .name in dm-raid4-5.c ...
<BenC> Ah, ok, then either someone changed the kernel (bad) or that dpatch is obsolete (good, get rid of it)
<psusi> yea, for some reason the module is named raid4-5, but the device mapper target it registers is "raid45"
<psusi> exactly
<cjwatson> let's do the latter, userspace is a hell of a lot easier to change now
<BenC> agreed
<psusi> yea, just need to remove the dpatch from 00list
<radix> hi all, I've nominated a small, upgrade-breaking bug with patch for intrepid: bug #288116
<ubottu> Launchpad bug 288116 in landscape "python-smartpm file overwrite with smartpm-core" [Low,New] https://launchpad.net/bugs/288116
<radix> oof, good timing
<radix> as I understand it, I need to get a member of the release team to look at it?
<cjwatson> radix: approved the nomination, please get a sponsor to upload that ASAP
<radix> cjwatson: thank you very much
<radix> will do
<mathiaz> radix: I'm on it :)
<radix> you guys rock :)
<mathiaz> radix: do you have bzr branch somehwere?
<radix> mathiaz: oh, no, actually I wanted to ask you about that -- the ubuntu-core-dev branch seems out of date
<radix> oh wait er
<radix> sorry, let me sort my brain out
<radix> scratch what I just said. I don't have a branch for this ticket, I can make one if you want
 * radix grabs a canned coffee
<pitti> anyone knows who is responsible for ubuntustudio?
<slangasek> TheMuso, persia, _MMA_
<pitti> TheMuso, persia: do you know about this linux-restricted-modules-rt in source NEW? good to accept?
<slangasek> saivann: rereading the official bug status descriptions, I guess that status is fine :)
<slangasek> saivann: so, ignore me :)
<bryce> slangasek: I just got hit by that gnome-terminal ^D crash again
<bryce> slangasek: did you find anything out about it?
 * bryce installs gnome-terminal 2.24.1-0ubuntu1
<bryce> er 0ubuntu2
<slangasek> bryce: I haven't had a chance to file a bug, no; I was going to try to reproduce it in a guest session first, to figure out what circumstances it happens in
<bryce> slangasek: I'll try running it in gdb and see if I can get a bt
<slangasek> bryce: I don't believe it's crashing
<slangasek> bryce: I think the damn thing is closing *on purpose*
<bryce> hmm
<bryce> well it's quite disruptive to one's workflow
 * bryce goes to look at gnome-terminal diffs
<slangasek> yes, yes it is
<soren> ^D closes gnome-terminal? How is that surprising?
<soren> Oh, it closes the window rather than the tab, perhaps?
<bryce> soren, it closes the entire application
 * soren doesn't use gnome-terminal these days
<soren> bryce: Oh, so *all* windows even. Yikes.
<james_w> does it close all instances of gnome-terminal?
<bryce> right
<bryce> james_w: yep
<james_w> ouch
<james_w> I think I saw that a couple of days ago then while making consolekit segfault while run from the terminal
<soren> james_w: Under normal circumstances, you only have one gnome-terminal instance even if you have multiple windows.
<james_w> ah, ok
<pitti> works fine here
<pitti> ^D just closes one window
<pitti> bryce: so it's likely that it actually is crashin
<pitti> g
<bryce> pitti: well I've not been able to reproduce the bug intentionally so far
<calc> my wife noticed on "The View" today they inserted a bit of the famous 'vote for president johnson' commerical and didn't reference it at all, was fairly pixelated
<bryce> looking through the diff, I wonder if it's some g_assert() getting triggered in some unusual condition
<bryce> hrm, but that should print something out...
<bryce> AHA
<bryce> **
<bryce> ERROR:terminal-tabs-menu.c:133:free_tab_id: assertion failed: (id >= 0 && id < \
<bryce> tabs_id_array->len * 8)
<bryce> .xsession-errors ftw
<soren> Any package depended on by a package that is Essential: yes ought to be essential itself, shouldn't it?
<NCommander> soren, not always
<soren> Seems odd.
<NCommander> soren, shared libraries must never be essential yes for instance
<soren> i would expect that to be a closed set.
<soren> NCommander: Hm... Good point.
<NCommander> soren, I have those occasionally ;-)
<soren> :)
 * soren wanders off for a bit
<slangasek> soren: the closure is "all packages marked Essential: yes, plus their transitive pre-dependencies"
<soren> slangasek: I see. I was just suprised that libpam-modules wasn't essential since base-files depends on it.
 * soren really wanders off
<slangasek> heh, actually, base-files is buggy for using Depends instead of Pre-Depends
<bryce> slangasek: ok I think I see what's going on
<bryce> this change occurred:
<bryce> -#define ACTION_VERB_FORMAT_PREFIX_LEN   (6) /* strlen (ACTION_VERB_FORMAT_PREFIX) */
<bryce> +#define ACTION_VERB_FORMAT_PREFIX_LEN   strlen (ACTION_VERB_FORMAT_PREFIX)
<slangasek> well that's pretty opaque, what did that do? :)
<bryce> the assert looks like this:
<bryce>         id = g_ascii_strtoull (name + ACTION_VERB_FORMAT_PREFIX_LEN, NULL,
<bryce>                                ACTION_VERB_FORMAT_BASE);
<bryce>         g_assert (id >= 0 && id < tabs_id_array->len * 8);
<slangasek> and how long is ACTION_VERB_FORMAT_PREFIX in practice?
<bryce> dunno
<bryce> oh I do know
<bryce>  #define ACTION_VERB_FORMAT_PREFIX       "JmpTab"
<bryce> so...
<bryce> hmm, actually the error could be with name
<bryce> well, at least I can file a sane bug report at this point
<bryce> slangasek: ah, already known as bug 286823
<ubottu> Launchpad bug 286823 in gnome-terminal "ERROR:terminal-tabs-menu.c:133:free_tab_id: assertion failed: (id >= 0 && id < tabs_id_array->len * 8)" [Medium,Fix released] https://launchpad.net/bugs/286823
<slangasek> bryce: escalate, escalate!
<slangasek> importance: planet on fire
<bryce> slangasek: allegedly already fixed in the latest gnome-terminal
<bryce> slangasek: dpkg -l gnome-terminal ?
<slangasek> bryce: er, which one is supposed to be the "latest"?  I don't think I even saw the problem until upgrading to 2.24.1-0ubuntu1
<slangasek> and I'm pretty sure I haven't accepted anything newer into the archive yet
<bryce> that's the latest
<slangasek> then the ^D crash is not fixed
<bryce> ok
<bryce> according to this bug, it's reproduced by opening >10 tabs then closing one.
 * bryce tries
<slangasek> right, I have > 10 tabs/windows open
<pitti> mvo: I'm a bit confused about bug 281363 -- I don't see postgresql anywhere in the log? do you see anythign in the log files which actually points out a problem?
<ubottu> Launchpad bug 281363 in postgresql-8.3 "package postgresql-8.3 8.3.3-1ubuntu1 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/281363
<bryce> hmm, nope
<slangasek> bryce: is that how you were seeing it before, opening multiple tabs?
<bryce> slangasek, do you launch gnome-terminal from .xprofile by chance?
<slangasek> no
<bryce> slangasek: yeah
<bryce> well, it occurs when closing the tabs
 * slangasek nods
<bryce> well, I've just put 2.24.1-0ubuntu1 on it, so will wait until I've reproduced it on that before reporting it.
<bryce> but I suspect it's related to 286823
<alex-weej__> is it out of the question to have virtualbox and kvm work at the same time?
<alex-weej__> virtualbox works way better for actual desktop OS virtualisation i find because it uses SDL. i can't get SDL to work with QEmu :(
<jcole> alex-weej__: the kvm kernel module somehow "locks" the vmx on the cpu
<alex-weej__> arse.
<jcole> alex-weej: the vbox kernel module does the same thing... perhaps if kvm and vbox decided to write a "sharable" kernel module
<alex-weej> ok
<vaughn> Quick question, sorry if it's the wrong place...is the 8.10 Release Candidate still on schedule for release today?
<alex-weej> only reason i use vbox is for the SDL and USB support
<jcole> alex-weej: you can have both the kvm and virtualbox apps installed but you can only run one at a time.. you will need to modprobe/rmmod the kvm/vboxdrv modules as necessary
<alex-weej> jcole: already doing that
<alex-weej> but thanks anyway
<jcole> alex-weej: ok :)
<jcole> perhaps someone can answer my question today :)
<jcole> im trying to install an ubuntu terminal server for our team with active directory authentication
<jcole> someone told me suse integrates better with ad (using yast) and that i should use it instead... is there a way to set it up on ubuntu/debian?
<Riddell> mvo: any idea what's up in bug 288267 ?
<ubottu> Launchpad bug 288267 in update-manager "Hardy Remix to Intrepid RC Network Upgrade Failed" [Undecided,New] https://launchpad.net/bugs/288267
<slangasek> mathiaz: not that we shouldn't fix bug #288218, but: what in the world are "tomcat6 webapps" doing checking the init script's "status" output in a postinst?  The interface for maintainer script / init script interaction is invoke-rc.d...
<ubottu> Launchpad bug 288218 in tomcat6 "tomcat6 initscript "status" action always return 0" [High,Fix committed] https://launchpad.net/bugs/288218
<NCommander> Well, I just got officially cited for XUbuntu
<slangasek> by a traffic cop?
<hyperair> hi. i'd like to bring attention to bug #284044
<ubottu> Launchpad bug 284044 in seahorse "seahorse passphrase dialogs don't accept input" [Undecided,Confirmed] https://launchpad.net/bugs/284044
<hyperair> i think this is a pretty bad regression
<ogra> probably a security feature against insecure passphrases ?
<hyperair> what dyou mean insecure passphrases?
<hyperair> it doesn't accept input!
<hyperair> i'm talking about gpg signing and everything that uses the agent
<ogra> so you cant type in an insecure one :)
 * ogra is joking
<hyperair> =.=
<jdstrand> slangasek: fyi-- the ecryptfs-utils upload I just did fixes a security issue and should get in before release. IMO it does not need a respin.
<jdstrand> kirkland: ^
<jdstrand> slangasek: hi btw! :)
<slangasek> jdstrand: noted; is there a bug referenced in the changelog, and have you nominated/targeted that bug for intrepid?
<jdstrand> slangasek: bug is in the changelog (bug #287908)
<ubottu> Launchpad bug 287908 in ecryptfs-utils "ecryptfs-setup-private potentially exposes passwords in the process table" [Critical,Fix committed] https://launchpad.net/bugs/287908
<jdstrand> slangasek: kirkland nominated it for Intrepid, and I approved it (hope that's ok)
<jdstrand> slangasek: I did not milestone it
<slangasek> jdstrand: ok, thanks
<slangasek> (if you could milestone it too, that would be good)
<jdstrand> slangasek: done. thanks
<pitti> calc: so are you happy with oo.o-emailmerge?
<pitti> slangasek: WDYT about this -emailmerge thing?
<slangasek> pitti: as I said earlier, I think that for such a small use case, even leaving the recommends: unsatisfied in main for release would not be beyond the pale
<pitti> slangasek: ah, right, I remember; sorry
<slangasek> pitti: so if there's concern that pulling it in would be the Wrong Thing, I would be ok with that, even though it leaves our component-mismatches list non-empty
<pitti> slangasek: it will be non-empty anyway
<slangasek> also, I *don't* want an OOo upload this week :)
<pitti> slangasek: neither do I :)
<pitti> slangasek: I don't think it's wrong; to the contrary, it was included in -writer in hardy, so not having it would actually be a regression
<pitti> slangasek: my concern is just that the change would happen so late in the game
<slangasek> ah, this is functionality that was included in -writer before?
<pitti> slangasek: (just parrotting calc here)
<slangasek> then I'm certainly comfortable with hauling it back in, as long as it fits
<pitti> Size: 6612
<pitti> slangasek: believe it or not :)
<slangasek> right :)
<pitti> python-uno is already on the CDs, I checked
<pitti> calc: so if you test it and give your thumbs up, we'll promote it
<pitti> otherwise we just ignore the recommends
<mvo> pitti: I replied in the bug
<mvo> Riddell: I replied in the bug
<pitti> mvo: so /var/log/apt/term.log != VarLogDistupgradeApttermlog.gz ?
<mvo> pitti: right, apt/term.log is the one that is written when apt-get or aptitude are used
<mvo> pitti: the other only gets created when the release upgrader runs
<mvo> pitti: might be worthwhile to add it to the package hook
<mvo> pitti: I think the reported mentioned that he used aptitude when the install failed?
<calc> pitti: yea thumbs up from me, it wasn't split out of writer until after hardy was released
<pitti> slangasek: ^ ok, then I'll promote it right after RC release?
<calc> it doesn't support gmail but i already filed an upstream bug about that
<calc> but for people who used to use it pre-intrepid its good to keep it there
 * calc sometimes wishes Novell would fork OOo already ;-)
<slangasek> pitti: yes, and then we should do some CD rebuilds to confirm everything fits since we have other post-RC package growth
<pitti> slangasek: absolutely; maybe we should just enable dailies again?
<slangasek> pitti: after RC is published, yes
<calc> i think the main reason it was split out was because it is a OOo extension and it made the packaging a bit cleaner
<calc> wow bug 264019 looks ugly
<ubottu> Launchpad bug 264019 in ubuntu-release-notes "unable to visit some websites and ftpsites with 2.6.27" [Medium,Fix released] https://launchpad.net/bugs/264019
<slangasek> it's only ugly if you use Verizon
<calc> ah ok
<calc> so like half the US ;-)
 * calc unfortunately doesn't have Verizon... so no FIOS either
<slangasek> "unfortunately", eh
<slangasek> Verizon are bastards; when I lived in Verizon territory in Beaverton, I went looking for CLECs instead for my Internet
<calc> slangasek: well the best i can get here from ATT is 3/0.5
<calc> and afaik there aren't really any useful CLECs here
<slangasek> calc: you could probably get a quote from Speakeasy?
<sharms> cjwatson - how can I change the gfxboot fg color and selected colors?
<mathiaz> slangasek: invoke-rc.d is used in the tomcat6-* postinstall script: http://paste.ubuntu.com/61689/
<mathiaz> slangasek: you mean that tomcat6 webapps postinstall scripts should not try to reload tomcat6?
<slangasek> mathiaz: I mean that they shouldn't call '/etc/init.d/tomcat6 status', which is what I thought was implied by your comment in that bug
<calc> slangasek: from what i recall looking at their site it wasn't any better
<slangasek> calc: they're "better" than Verizon in the sense that they're not devilspawn; I'm not talking about speed here :)
<calc> i could go to comcast and get higher bandwidth but they have caps i think
<calc> oh well att is ok just slow
<lool> 'night
 * slangasek waves to lool 
<mathiaz> slangasek: the root of this issue is outlined in bug 274365
<ubottu> Launchpad bug 274365 in tomcat6 "Installation over Sun JVM might fail if JVM is not yet configured" [Low,Fix released] https://launchpad.net/bugs/274365
<mathiaz> slangasek: hm - no - scratch that. It's not related.
<mathiaz> radix: do you have branch for bug 288116?
<ubottu> Launchpad bug 288116 in smart "python-smartpm file overwrite with smartpm-core" [High,Triaged] https://launchpad.net/bugs/288116
<hyperair> could someone take a look at bug #284044 ?
<ubottu> Launchpad bug 284044 in seahorse "seahorse passphrase dialogs don't accept input" [Undecided,Confirmed] https://launchpad.net/bugs/284044
<slangasek> superm1: http://mythbuntu.org/8.10/rc is currently empty?
<superm1> slangasek, <shrug> let me stab tgm4883.  one sec :)
<slangasek> ok :)
<mathiaz> slangasek: does that answer your question about tomcat6?
<slangasek> mathiaz: hmm, you said "scratch that" - so... no, I guess it doesn't :)
<mathiaz> slangasek: hm. scratch that refered to the bug number I gave.
<mathiaz> slangasek: my first answer is still correct -the postinst script use invoke-rc.d
<slangasek> mathiaz: ok, so the mention of 'status' in that other bug was a red herring?
<mathiaz> slangasek: other bug being bug 288218?
<ubottu> Launchpad bug 288218 in tomcat6 "tomcat6 initscript "status" action always return 0" [High,Fix committed] https://launchpad.net/bugs/288218
<slangasek> yes
<slangasek> or rather: the mention of maintainer scripts was a red herring
<mathiaz> slangasek: hm - not sure I totally understand what you mean. But the maintainer scripts were failing in the tomcat6-* postinstall script because status was always returning 0
<slangasek> why does the maintainer script care about status returning 0?
<mathiaz> slangasek: thus the postinstall script would proceed to try to restart tomcat6 even it wasn't running
<mathiaz> slangasek: it uses the status action to figure if the process is running or not. If the process is running it will try to force-reload it
<slangasek> then these postinstall scripts aren't using the policy-defined interface for maintainer script - init script interaction
<dvstin> intrepid is shipping with a screwed up pulseaudio configuration, they need to ship with libao-pulse if they are going to include pulseaudio so that sound capture works.. the libao-alsa doesn't work when pulseaudio is running.. how do I get someone to change this for 8.10?? :S (bug #285621)
<ubottu> Launchpad bug 285621 in linux-meta "pulse audio stops sound capture from working on thinkpad x300 hda-intel on intrepid" [Undecided,New] https://launchpad.net/bugs/285621
<hyperair> doesn't anybody here use seahorse?
<mathiaz> slangasek: so http://paste.ubuntu.com/61689/ is not policy compliant?
<seb128> hyperair: why did you subscribe me to this bug? and yes lot of people use seahorse and nobody is having this issue
<hyperair> seb128: well, you were the last one to upload seahorse
<hyperair> i thoughty ou might be able to help regarding that bug
<seb128> hyperair: do you use scim or something similar?
<hyperair> eh yeah
<seb128> hyperair: could you try not using it?
<hyperair> i could
<hyperair> but i'd have to log out
<seb128> hyperair: it could be a scim interaction bug
<hyperair> yeah
<hyperair> could be
<dvstin> it's annoying to write up a bug, find the root cause, find the solution, and watch it sit there and do nothing :(
<hyperair> dvstin: agreed
 * hyperair needs sleep bady
<hyperair> badly
<slangasek> mathiaz: according to policy, you should be able to call invoke-rc.d tomcat6 force-reload directly
<hyperair> seb128: doesn't fix the issue
<hyperair> i seti t to xim
<hyperair> but i noticed this: ** Message: could not grab keyboard
<slangasek> mathiaz: does tomcat6's init script support a force-reload that's separate from a restart?
<mathiaz> slangasek: hm - no.
<seb128> hyperair: scim is still running though?
<hyperair> oh yeah
<hyperair> i killall'd it
<slangasek> mathiaz: ok.  So this will end up doing a restart, but the whole point of invoke-rc.d is to keep maintainer scripts from starting services that aren't supposed to be started in the current runlevel
<hyperair> okay, now this is weird.
<slangasek> (or as defined by local policy-rc.d policy)
<hyperair> seb128: the second prompt works (after the first one fails)
<hyperair> but i have to focus another window and come bak
<hyperair> back*
<seb128> hyperair: did you try entering your password? there is a bug about the dialog not being colored as if it had the focus but in fact it has it
<hyperair> seb128: cursor's there. it stops blinking when i type, but nothing gets entered
<seb128> weird indeed
<hyperair> yeah
<hyperair> it seems that the second passphrase prompt fails to grab the keyboard
<hyperair> so the first passphrase prompt successfully grabs the keyboard, and then i can't type in anything
<seb128> hyperair: bug #66104
<hyperair> then the second passphrase prompt doesn't grab the keyboard, but i can type in stuff after focusing on some other text input, and then back on seahorse
<ubottu> Launchpad bug 66104 in scim "[Gutsy] scim: input freezes in various applications under XIM mode" [Medium,In progress] https://launchpad.net/bugs/66104
<hyperair> hmm XIM huh?
<hyperair> what other inputs should i use?
<seb128> hyperair: the issue seems to be a scim one rather a seahorse bug anyway
<seb128> but I've no real clue about scim, try talking to arne rather
<hyperair> hmm
<hyperair> i'll try tomorrow then
<hyperair> i need to get some sleep
<mathiaz> slangasek: ok. So IIRC policy-rc.d is mainly used to manage start/restart permission.
<mathiaz> slangasek: in which case using force-reload in the script would lead to problem.
<mathiaz> slangasek: considering that restart and force-reload are the same, would replacing force-reload with restart solve the issue?
<slangasek> mathiaz: ah, if it's not possible to manage the behavior of force-reload with policy-rc.d, that's something I was unaware of
<h4writer> hi, I just wanna thanks everyone from the ubuntu-development for they right choises (integration and development wise). In the previous ubuntu version I removed network-manager, because I thought wicd was better. I now can say I'm happy to switch to network-manager again and FINALLY have WPA working out of the box :-D :-D Happy user here :-)
<slangasek> mathiaz: if force-reload is identical to restart anyway for this init script, I would just call "restart" then, yeah
<mathiaz> slangasek: oh - I don't pretend that
<slangasek> mathiaz: well, I can't say I've tested that directly myself - and the invoke-rc.d code is horrible to behold
<mathiaz> slangasek: ok - so if the force-reload is switch to restart would you accept the upload?
<slangasek> mathiaz: also dropping the querying of 'status', or just s/force-reload/restart/?  If the other bug is fixed, I'm not sure that either change is necessary at this point in the release
<mathiaz> slangasek: hm - that is not sufficient - all of this is related to bug 274365
<ubottu> Launchpad bug 274365 in tomcat6 "Installation over Sun JVM might fail if JVM is not yet configured" [Low,Fix released] https://launchpad.net/bugs/274365
<tedg1> cody-somerville: Does Xubuntu use gnome-screensaver?
<cody-somerville> tedg1, yes
<mathiaz> slangasek: restart will try to start tomcat which will fail
<mathiaz> slangasek: because java is not setup correctly.
<mathiaz> slangasek: the workaround we've used is to add an error_handler of true in the tomcat6 postinst script
<mathiaz> slangasek: if the status check is removed, the postinst script will try to start tomcat6 anyway and will fail.
<mathiaz> slangasek: which is the error seen in bug 288218
<ubottu> Launchpad bug 288218 in tomcat6 "tomcat6 initscript "status" action always return 0" [High,Fix committed] https://launchpad.net/bugs/288218
<tedg1> cody-somerville: 'k
<tedg1> cody-somerville: Thanks.
<slangasek> mathiaz: ah.  then that answers my original question, "why does it care about status" :)
<slangasek> mathiaz: that's something I don't have an answer for within the invoke-rc.d framework, so I guess what you're doing is perfectly correct & necessary
<mdke> slangasek: I think ubuntu-docs is still in the queue, don't know if it is a convenient time to let it through?
<slangasek> mdke: I'm in the middle of trying to publish the RC, it's definitely not a convenient time to let it through
<mdke> slangasek: ok, i wasn't sure of the timetable. No worries
<wasabi> it is a bit annoying how parts of my desktop break while running an upgrade.
<wasabi> I wonder what a good general purpose solution to 'not breaking running applications during upgrades' is for us. MS solves it by file locking, and not completing the upgrade until reboot (all files are unlocked).
<wasabi> Should it be policy that a .deb preinst script should ensure files are not in use? Or what?
<wasabi> (given that you accept that it's broken now)
<lifeless> wasabi: I wouldn't say MS have solved it
<wasabi> Or should software simply be aware that it's files might change on the fly, out of order, and dependent services might stop unexpectidly.
<wasabi> in mye xperience, day to day upgrades on windows don't cause running apps to crash, or weird dialogs to pop up on teh desktop.
<wasabi> The upgrade pretends to install, and then if files were in use msi makes you reboot.
<lifeless> specifically its trivial to break apps on windows because help files and the like are opened on demand; if file locking was the solution upgrades there would look very different
<wasabi> Well, I don't see that happening in my usage of Windows. Though on principal I believe you are right.
<lifeless> wasabi: you have one part of the puzzle, I recommend you dig deep into orca and the msi service to understand what they do
<wasabi> I just did an upgrade of a few packages and a) xchat broke, throwing a message about ORBIT stuff failing b) a dialog box from an unknown application popped up saying it could not do something non-specific c) my fonts in nautilus went unantialiased.
<slangasek> What running applications are breaking during upgrade?  Unix /had/ this solved long ago by "software expecting files to change on the fly"
<wasabi> Heh.
<wasabi> oh, the unknown app was empathy failing because of dbus going up and down I *think*
<slangasek> oh, dbus
<slangasek> dbus is special :P
<wasabi> but I didn't spend enough time watching.
<slangasek> dbus is so very un-unix it's not funny
<wasabi> Curiously, why isn't 'dbus' just some client library that creates/manages well known pipe names in /tmp/user or something?
<slangasek> see previous comment
<wasabi> 'just because'?
<wasabi> lifeless: I've done a bit of work with MSI... but not taht much. I know about ref counting and the insanity it goes through. I *know* it is *crap*.
<wasabi> I'm just wondering what the proper solution is for us.
<lifeless> wasabi: I think its a ratchet problem
<wasabi> I'm trying to interpret that.
<wasabi> Just a matter of lack of time to polish?
<lifeless> wasabi: which is to say, its complex and needs many moving parts altered and fixed
<lifeless> and there is a high chance of new code being written badly because the current state is 'broken'
<lifeless> I don't think we need a bunch of new technical answers
<wasabi> Hmm. weird. Intreped just prompted to ask me if I'd like to replace /etc/update-manager/release-upgrades
<lifeless> as slangasek says, this is a new problem for us
<wasabi> Yeah.
<lifeless> by a ratchet problem I mean that we have to draw a line in the sand
<wasabi> Haha. Makes me wonder how hard it would be to actually redo the DBUS api as it stands today using plain pipes and stuff.
<lifeless> and say 'we won't let this get worse' - upstream changes that make it worse won't be included.
<lifeless> and then start at the bottom of the stack - things like dbus - and audit/fix/ and then work up
<slangasek> they tend to go unnoticed at the point of inclusion
<lifeless> slangasek: true
<lifeless> slangasek: 'revert' is not a dirty word though :)
<slangasek> no, it's just easier said than done
<wasabi> sigh. epiphany broken and won't launch anymore
<wasabi> dbus dead
<wasabi> So because I'm curious... what have you guys thought about configuration management during upgrade? Another example is dpkg just prompting me to decide what I want to do with smb.conf. What *is* the proper solution to this?
<slangasek> lifeless and I differ on that question :)
<lifeless> slangasek: I don't think we differ much really
<lifeless> slangasek: I know we differ on one aspect of how-to-avoid-prompts
<lifeless> slangasek: but I don't believe you think spurious prompts are good :)
<slangasek> true... :)
<wasabi> I guess the only 'real' way to fix it is to make samba support and upgrade old configuration files.
<wasabi> And repeat for every other app.
<wasabi> nice. bluetooth.conf
<slangasek> wasabi: in the specific case of smb.conf, I would like to know what your old smb.conf and your pre-upgrade /var/lib/ucf/cache/:etc:samba:smb.conf look like
<slangasek> because I consider every occurrence of an smb.conf prompt a potential bug
<wasabi> i can file a bug then if you'd like
<wasabi> basically my file was just joined to AD, had tons of idmap settings added, and I ran it through swat at one point
<wasabi> (because it autoconfigures it)
<wasabi> (autoformats I mean)
<wasabi> and i cannot open my browser to file a bug. nice.
<slangasek> oh, swat
<slangasek> then that's not a case we can manage, really, so no point in filing a bug
<wasabi> I only turn swat on and use it when I get cross eyed by unorganized options.
<wasabi> I just have it load/save the file.
<wasabi> just to format it. :0
<wasabi> Well, you can handle it. The file is still just a list of options.
<wasabi> The merge needs context
<calc> anyone happen to remember the url that describes how to enable apport?
<wasabi> The upgrade process should be able to parse the file, and option by option figure out if it needs to be converted, and then rewrite the file.
<wasabi> Not sure there's any alternative.
<sbeattie> calc: it's described in https://wiki.ubuntu.com/Testing/EnableProposed
<bdmurray> calc: https://wiki.ubuntu.com/Testing/EnableProposed
<lifeless> wasabi: 'the current UCF logic cannot handle that'
<wasabi> curious why is this the domain of ucf? it is appropiate for samba to be able to handle it's own configuraton file upgrade.
<wasabi> no?
<wasabi> it certainly possesses the authoritative code for reading the file and understanding the meaning.
<calc> sbeattie: ok
<lifeless> sure
<lifeless> however ubuntu knows that it first installs settings START
<lifeless> and then on an upgrade is installed UPGRADED
<lifeless> handling that delta is up to Ubuntu and the dpkg upgrade process
<lifeless> could that call into samba? sure; currently it uses ucf
<wasabi> Maybe samba should provide a utility that will do a three way merge. Load three settings file (original, custom, proposed), and a decision tree about what to write out.
<wasabi> I'm just wondering what it SHOULD be like, given infinite time. :0
<lifeless> wasabi: I find that that is usually pointless :P
<wasabi> I don't think so. I find it impossible to do day to day work without having some vision.
<lifeless> vision sure
<lifeless> infinite time, well thats a different case :P
<wasabi> wow nautilus just gave me an AWESOME error
<wasabi> I think it's nautilus.
<superm1> TheMuso, were you aware that pulseaudio caused gnome-sound-recorder to behave rather erratically?
<Mez> slangasek: it seems your wishes regarding the whole NM process have been granted ;)
<slangasek> Mez: I would say... no.
<Mez> well, closer to it anyways :P
<slangasek> wasabi: the usual cause for smb.conf merge conflicts is with the comments, which are there for a reason; if we're not going to provide the in-line documentation at all, then it'd be a piece of cake for ucf and we don't need samba to do anything anyway
<cody-somerville> superm1, Can you upload the patch provided in https://bugs.edge.launchpad.net/ubuntu/+source/abiword/+bug/284857 please?
<ubottu> Ubuntu bug 284857 in abiword "Abiword crashes on using "Create and modify styles..." from the format menu" [Unknown,Confirmed]
<crimsun> superm1: more precisely, is that with alsa-plugins (intrepid, of course) installed?
<superm1> crimsun, with a default install
<crimsun> superm1: I have a fix for that and will see about pushing it into ppa for testing
<superm1> crimsun, the length of the sound file shoots up to hours within seconds
<superm1> crimsun, and then hangs g-s-r
<superm1> killing pulseaudio and restarting gsr fixes it
<superm1> crimsun, okay
<superm1> cody-somerville, it's missing an ack from ubuntu-release
<sysadmin> Hmm. What happened to dpkg-reconfigure xserver-xorg -low showing otpions for drivers and stuff?
* slangasek changed the topic of #ubuntu-devel to: 8.10 RC released | archive: Release Freeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> wasabii: xorg.conf is 95% obsolete, therefore the maintainer script handling for managing it is 100% obsolete
<wasabii> sure, but X won't detect my video card anymore in intrepid. =(
<slangasek> this is a regression vs. hardy?
<wasabii> yup
<slangasek> if so, please file a bug
<slangasek> and nominate it for release
<wasabii> *sigh* no browser yet. have to hand edit xorg i guess. =(
<slangasek> or boot into "vesa" mode from the recovery menu
#ubuntu-devel 2008-10-24
<superm1> wasabii, bug 261977 possibly?
<ubottu> Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
<wasabii> nv isn't even chosen. xorg.conf just claims no devices
<wasabii> will give te vesa thing a try
<wasabi> Hmm. that fix thing just reruns dpkg-reconfigure
<wasabi> which i'd already tried.
<wasabi> there we go
<kirkland> is it more customary for program usage statements to be printed to stdout or stderr?
<kirkland> that seems like the type of question slangasek might be an authority on :-)
<slangasek> I've seen a mix of each, actually
<lifeless> kirkland: if you ask for help, then stdout
<slangasek> I assume that if I want to capture --help output to a pager, I need to use 2>&1, because it's not reliable not to - but there are some that send to stdout
<lifeless> kirkland: is better IMO
<kirkland> okay, thanks, guys
<lifeless> kirkland: bzr uses stdout for requested output and stderr for everything else
<lifeless> kirkland: --help is requested out -> stdout
<kirkland> lifeless: interesting, okay.
<lifeless> the goal being that 2>/dev/null should never discard important information and that |less should never have cruft
<kirkland> that seems reasonable
<cjwatson> yeah, I'm definitely with lifeless on this one
<kirkland> cjwatson: cool, thanks
<cjwatson> I often end up with def usage(stream, exitcode): and call it as usage(sys.stdout, 0) or usage(sys.stderr, 1), or something along those lines
<cjwatson> (if I'm not using a canned library)
<kirkland> cjwatson: yeah, i'm trying to standarise some of the ecryptfs-* output (not for intrepid ... upstream work)
<wasabi> See, perfect (if it works)
<wasabi> First launch of evolution began to auto convert my summary folders.
<GasFurnace> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<GasFurnace> you again
 * calc hopes amd64 works properly on his laptop now, doing a full reinstall to see
<calc> that would make it a lot easier to track down 64bit OOo bugs
<GasFurnace> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<lifeless> GasFurnace: why are you doing that repeatedly; the answer won't change
<calc> it works :)
<calc> just doesn't resume well on the cd for some reason
 * Hobbsee looks in
<TheMuso> Hobbsee: Was that strictly necessary?
<Hobbsee> TheMuso: yeah, i spoke to -ops - he's been trolling everywhere
<TheMuso> Hobbsee: fair enough then.
<cody-somerville> He got klined
<cody-somerville> He isn't coming back :P
<Hobbsee> TheMuso: i thought the nick looked familiar...
<TheMuso> Hobbsee: No.
<cody-somerville> TheMuso, He was doing the same thing in #xubuntu and #xubuntu-offtopic
<TheMuso> cody-somerville: Fun.
<Hobbsee>  and #kubuntu-offtopic, and ...
<Hobbsee> the forums
<TheMuso> I often wonder why people bother, knowing they'll just get banned.
<lifeless> they don't know that
<cody-somerville> "[21:33] <GasFurnace> i can do this all night"
<lifeless> knowing that requires thinking about the machinery of maintaining a good discussion forum
<calc> he can also get a k line :)
<LjL> cody-somerville: now he's found out he can't
<calc> ah i see he already did :)
<lifeless> and some folk don't know how to think
 * TheMuso is finding that some people don't know how to think more and more, and its shameful. :p
<Hobbsee>  well, if he isn't coming back on that ip...
<cody-somerville> Lets all hold hands for a moment, shall we?
<StevenK> And sing Kumbaya?
<philwyett> Morning all. Any of the release team to flag an RC bug too in the house?
<cody-somerville> StevenK, I got a job for ya :)
<cody-somerville> StevenK,
<cody-somerville> erm
<StevenK> cody-somerville: Thanks, I already have one.
<Hobbsee> philwyett: which bug?
<philwyett> https://bugs.launchpad.net/bugs/288461
<ubottu> Ubuntu bug 288461 in gimp "gimp menus always on top of images" [Undecided,New]
<StevenK> And how is it RC?
<philwyett> StevenK: That is from an hour old 8.10 RC install.
<StevenK> philwyett: No no, how is the bug release-critical?
 * StevenK tries to reproduce
<philwyett> StevenK:  It makes a core piece of software unusable on the desktop. So, I class that as fairly critical. ;-)
<calc> grr the add location option no longer has a find location option
<calc> er in the clock
<calc> oh it text completes now, heh
<StevenK> philwyett: Works fine for me with compiz
<Aero> hi, per colin watson's instructions on ubuntu-devel-announce today, i'm looking for someone from ubuntu-release team to acknowledge a fairly serious bug
<Aero> https://bugs.launchpad.net/ubuntu/+bug/259385
<ubottu> Ubuntu bug 259385 in ubuntu "Intrepid Compiz hangs on login for various hardware" [Undecided,Confirmed]
<Aero> (to those in #ubuntu+1, sorry for repeating myself)
<slangasek> -               &apos;linnuks&apos; is the heart of the Ubuntu operating system.
<slangasek> +               &apos;li-nuks&apos; is the heart of the Ubuntu operating system.
<Hobbsee> philwyett: I can't reproduce that.
<slangasek> mdke: ^^ that looks like a regression to me...
<philwyett> StevenK: Not tried yet with compiz enabled as not all people have it on. This happens using nv driver thus compiz not enabled.
<StevenK> Hobbsee: With or without compiz?
<Hobbsee> with
 * Hobbsee can minimise individual windows though, which seems to solve the problem, too
<Hobbsee> oh, i see.
<philwyett> If you look at my screenshot, the gimp has only one entry on the panel at the bottom which is also odd.
<Hobbsee> so it does.  Now, why doesn't mine have that?
<ajmitch> metacity issue?
<Hobbsee> i'm not sure.  or a nv issue
<Hobbsee> Aero: which video card are those on?
<Aero> looks like various
<calc> for some reason a lot of files on a freshly installed intrepid have group 999
<Aero> to my recollection, some people saying nvidia
<Aero> i'm affected and i have intel integrated graphics, i can get you more specific info in a sec..
<calc> slangasek: heard anything about that yet?
<philwyett> Hobbsee: I will add my xorg log to the bug report.
<Aero> i can't remember where in GNOME i go to get a list of hardware...
<Aero> sorry, i must have been imagining things when i said nvidia
<Aero> some saying ati, at least one other intel integrated like me
<Hobbsee> lspci, iirc.
<Hobbsee> strange.
<Aero> maybe it's actually two similar bugs?
<Hobbsee> could well be.
<Hobbsee> would be interestingto know what mvo says about it
<Aero> who's that?
<Aero> i attached my lspci
<StevenK> One of the Ubuntu developers, deals with compiz
<Aero> have i done my duty, y'think?
<Aero> eh, i'll hang 'round for another few hours.
<Hobbsee> Aero: yes, thanks:)
<Hobbsee> (to the having done your duty)
<Hobbsee> philwyett: i'm sorry, but I don't regard that as Release Critical
<Hobbsee> philwyett: does upstream have a patch, or a bug for it, yet anyway?
<Hobbsee> itmay get pushed as a SRU if it's small
<philwyett> Hobbsee: I will do some checking.
<mneptok> *smewch*
<Hobbsee> philwyett: https://bugs.edge.launchpad.net/ubuntu/+source/gimp/+bug/283115 is probably related to that (or a dupe).  erk.
<ubottu> Ubuntu bug 283115 in gimp "gimp 2.6: toolbox windows can't be minimized" [Undecided,New]
<calc> cjwatson_: i gave you bug 288479
<Hobbsee> mneptok: oh, thanks
<ubottu> Launchpad bug 288479 in ubuntu "Ubuntu 8.10rc Desktop amd64 - lots of files with gid 999" [Undecided,New] https://launchpad.net/bugs/288479
<calc> anyone else notice the gid 999 files on a freshly installed intrepid system?
<philwyett> Hobbsee: That is a bug and related, but not exactly a dupe. I will subscribe to that one too.
<philwyett> Hobbsee: Aha, this looks like the devs doing silly things and trying to confuse users again. :-/ http://bugzilla.gnome.org/show_bug.cgi?id=556896#c4 Using TAB will minimize and maximize the two dialogs.
<ubottu> Gnome bug 556896 in User Interface "Dialogs don't get minimized with single image window" [Minor,New]
<StevenK> cody-somerville: Uploading
<StevenK> cody-somerville: s/ing/ed/
<cody-somerville> StevenK, \o/
<ScottK> StevenK: Would you please sync gnupg2 to fix Bug 288061.  Hobbsee OK'ed it for ubuntu-release.
<ubottu> Launchpad bug 288061 in gnupg2 "gnupg-agent: modifies SigBlk mask of all processes spawned in the X session breaking unrelated software [i386 only?]" [High,Triaged] https://launchpad.net/bugs/288061
<StevenK> Only if slangasek okays it
<StevenK> syncs bypass the unaprroved queue
<ScottK> OK.  I thought it was anybody in the release team.
<Hobbsee> bug 281610
<ubottu> Launchpad bug 281610 in ubuntu-ps3-port "[regression, intrepid] Xorg servers broken "No core keyboard" and "failed to initialize core devices"" [Critical,Fix committed] https://launchpad.net/bugs/281610
<Hobbsee> StevenK: so they do?  darn.
<ScottK> StevenK: I'll upload it then so it gets in queue for his review.
<StevenK> ScottK: I'd prefer it was sync
<StevenK> sync'd
<ScottK> OK.  I was gonna use syncpackage to make it turn out like one.
<ScottK> But if you say not, I won't.
<Hobbsee> Aero: i'm not sure what relevance https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/281610 currently has to your bug.
<ubottu> Ubuntu bug 281610 in ubuntu-ps3-port "[regression, intrepid] Xorg servers broken "No core keyboard" and "failed to initialize core devices"" [Critical,Fix committed]
<icanhas> pitti: *poke*
<TheMuso> icanhas: pitti would be asleep at the moment. Maybe you should try and catch him when he is awake and around.
<icanhas> TheMuso: i thought people wake up when you poke them :(
<Hobbsee> icanhas: depends how loud their pc is....
<Hobbsee> icanhas: and the WAF of that is pretty low...
<calc> pitti will probably be around in ~ 5h
<icanhas> You devels really look out for each other, lol.
<icanhas> thank you :)
<kirkland> emgent_: hey dude, congrads ;-)
<kirkland> slangasek: still around?
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259631
<ubottu> Ubuntu bug 259631 in ecryptfs-utils "Cannot open Private directory after a reboot" [Undecided,Incomplete]
<kirkland> slangasek: users complaining about their ecryptfs private dir not available on login/reboot
<kirkland> slangasek: i got one of them to post their /etc/pam.d/common-session
<kirkland> slangasek: http://launchpadlibrarian.net/18812515/common-session
<kirkland> slangasek: that ain't gonna cut it ;-)
<kirkland> slangasek: i'm guessing their answered the pam-config question "poorly" (/me says in his best Last-Crusade voice)
<kirkland> slangasek: can you drop a comment or two in that bug, as to how these users might get their pam configs back in tip top shape?
<philwyett> Aero: Can you add your xorg log to the bug you are concerned with. The lspci -vvnn is throwing up a flag as it shows a vga controller but no sub display controller.
<calc> grr, i still can't run 64bit guests in vmware since my cpu doesn't have VT support :(
<calc> so upgrading to 64bit ubuntu didn't really help me that much
<ScottK> StevenK: Would you please do the sync in Bug 287697.  It's Universe, so I can OK it.  It fixes a remote excecution exploit.
<ubottu> Launchpad bug 287697 in mantis "Please sync mantis 1.1.2+dfsg-8 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/287697
<StevenK> ScottK: Done
<Aero> Hobbsee: come to think of it, my PS/2 keyboard and mouse broke at one point. they worked immediately after installing the beta, but an update broke them. i fixed by installing xorg-input-all, or something like that
<Hobbsee> Aero: yeah, that'll be a lack of -evdev installed.
<Hobbsee> that should have been fixed, too.
<Hobbsee> seems that it is
<Aero> shall i uninstall the input package and find out?
<Hobbsee> don't think that would be overly wise
<Aero> k
<ScottK> StevenK: Thanks.
<Hobbsee> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/284044 is collateral damage of the old gnupg2, isn't it?
<ubottu> Ubuntu bug 284044 in seahorse "seahorse passphrase dialogs don't accept input" [Low,Incomplete]
<Hobbsee> or am i not reading it properly
 * ScottK looks
<ScottK> Hard to say.  The particular bug I was wanting gnupg2 sync'ed for I don't think is that.
<ScottK> I do think there is something going on in the environment though because I've run into people with similar problems with pinentry-qt4 although it works fine for me.
<Aero> philwyett: done.
<Aero> or did you mean a different log? i assumed .xsession-errors
<Aero> but it looks like i attached that to my dupe already
<ScottK> StevenK: But 286622 looks like another good sync to do.
<philwyett> Aero: No, your /var/log/Xorg.0.log please.
<Aero> is that log only valid for the last login/boot? i've since logged in with metacity
<philwyett> Aero: I am after general info of what is going on from boot.
<Aero> ah, okay
<slangasek> calc: uh.  group 999? no...
<slangasek> StevenK: Hobbsee can approve exceptions for the release team
<Aero> done.
<Hobbsee> bug 286622
<ubottu> Launchpad bug 286622 in sshpass "Please sync sshpass 1.01-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/286622
<Hobbsee> ScottK: yes, it does.
<slangasek> kirkland: commented
<StevenK> Hobbsee, ScottK: I'll sync 288061 and 286622
<kirkland> slangasek: thanks a lot
<Hobbsee> StevenK: thank you.
<ScottK> StevenK: Thanks.
<Aero> i'm out - if i can be of any further help, leave me a note on the ticket.
<calc> slangasek: unfortunately i can't retest the amd64 install since my cpu apparently is too crap for vmware 64bit
<StevenK> calc: Missing a flag?
<calc> StevenK: i have no VT :\
<calc> apparently its required to get around a deficiency in the intel cpus, and mine doesn't even have taht
<calc> er that
<ScottK> StevenK: Would you please do the sync in bug 288515
<ubottu> Launchpad bug 288515 in wmibam "Please sync wmibam 0.0.1-2.1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/288515
<StevenK> ScottK: Done.
<ScottK> StevenK: Thanks.
<ScottK> I've got maybe one more that's building now and then I'm going to bed.
<calc> anyone happen to know where evolution stores its config data?
<calc> is it in .evolution or somewhere else?
<calc> for the accounts
<calc> ah its in gconf
<ScottK> Nevermind.  Going to bed.
<pabs3> does Ubuntu have the capability to sync packages from Debian experimental?
<ScottK> pabs3: Yes.
<pabs3> ah, cool, thanks
<ScottK> Be sure to explicitly specify that's where the needed package comes from.
<calc> crap i killed my evolution config :\
<calc> doh
 * calc should have backed it up before reinstalling
<ScottK> calc: A sign you should be using Kmail.
<calc> really a sign i should be asleep instead of doing things without backups :\
<calc> at least all my mail is on imap so i didn't lose anything :)
 * calc now remembers he also lost his filters and curses
<ScottK> StevenK: There's a stack of Universe sync requests in the archive queue.  Except for 286374, I think they're all worth doing.
<ScottK> Now off to bed.
<slangasek> calc: which install method did you use, and what files wound up as group 999 (some examples)?
<calc> slangasek: amd64 desktop manual partition reformatted my linux partition
<calc> slangasek: i don't remember which all files but definitely /cdrom /initrd.img /vmlinuz did as well as some others i can't recall now :(
<slangasek> ok, so this could be a livefs, kernel, or ubiquity bug...
<calc> something that was very odd was (at least iirc) the gid on the symlinks was 999 even when the files pointed to weren't
<calc> aren't the uid/gid supposed to match the pointed to file?
<cjwatson> uid/gid on symlinks is almost meaningless
<slangasek> no; you can create symlinks to files you don't own, and the symlink will be owned by you
<calc> oh ok
<slangasek> on Linux, it used to be that all symlinks were owned by root, IIRC
<calc> either of you know how to reset email password?
<slangasek> nope, sorry
<calc> i seem to have forgotten mine
<slangasek> I think you need to get IS to do it for you
<calc> ok, they seem asleep atm, i guess i will get them to fix it in the morning, already midnight here
<cjwatson> calc: thanks for the report, I've put it on ubiquity for now and will look at it
<calc> cjwatson: ok
<calc> cjwatson: from what i recall it seemed to only be files that would likely be changed during an install, and the root symlinked files
<calc> eg not unpacked packages
<cjwatson> mm, odd though because we copy off the squashfs
<calc> iirc it wasn't more than 10-20 files total
<cjwatson> and we do it as root ... it must be a pretty creative bug somewhere :)
<calc> unfortunately i can't easily attempt reproduce the bug since i don't have VT support in my cpu :(
<TheMuso> cjwatson: I noticed today that the ubuntustudio disks are not installing ubuntu-standard. Ubuntu-standard and its deps are on the disks, but don't get installed. Where should I be looking to solve this one?
<cjwatson> TheMuso: look in the Packages file - do the dependencies of ubuntu-standard have "Task: standard"?
 * TheMuso checks.
 * calc goes to bed, bbl
<cjwatson> night
<TheMuso> cjwatson: appears so.
<TheMuso> I've only really looked on i386, but I'll have a look on amd64.
 * TheMuso fires up a VM.
<cjwatson> TheMuso: ok, look in /var/log/installer/syslog after installation and search for ubuntu-standard - is it even trying to install it?
<TheMuso> cjwatson: no.
<TheMuso> ubuntu-standard is not in syslog.
<cjwatson> TheMuso: right. sounds like tasksel/limit-tasks is breaking it then.
<cjwatson> which'll be a tasksel bug I suppose
<TheMuso> Sounds like it.
<cjwatson> well, either that or a workaround in cdimage, I'll look ...
<TheMuso> cjwatson: Ok, thanks. I'm happy to help/poke myself if need be.
<cjwatson> TheMuso: I need to think a bit about the other users of tasksel preseeding, and what the right semantics are here
<cjwatson> TheMuso: can you file a bug about this?
 * TheMuso nods.
<TheMuso> cjwatson: No problem.
<pitti> Good morning
<geser> Guten Morgen pitti
<tkamppeter> pitti, hi
<tkamppeter> pitti, there is bug 288424
<ubottu> Launchpad bug 288424 in ghostscript "package ghostscript-x 8.63.dfsg.1-0ubuntu5 failed to install/upgrade: files list file for package `ghostscript-x' is missing final newline" [Undecided,New] https://launchpad.net/bugs/288424
<tkamppeter> and the Ghostscript source does not have a file list for ghostscript-x. The files are distributed to the binary package by moving them around via debian/rules.
<tkamppeter> pitti, is this a bug of dpkg-buildpackage?
<pitti> tkamppeter: it has got nothing to do with -buildpackage, it's on installation
<pitti> tkamppeter: so  if at all, it's a bug in dpkg, but I really doubt that
<pitti> tkamppeter: if the package installs well for you, it isn't a problem in the deb itself, and I'd assume a problem on the client side
<geser> I can't reproduce it with -0ubuntu6 on AMD64
<pitti> tkamppeter: such as full disk, corrupted memory, etc.
<pitti> tkamppeter: worth asking to attach /var/lib/dpkg/info/ghostscript-x.files
<pitti> and see how corrupted it is
<[reed]> which is better to use? -dbg or -dbgsym?
<pitti> [reed]: doesn't make much of a difference; -dbg is a bit easier, -dbgsym are available for more (ideally: all) packages
<[reed]> ok, thanks
<mdke> slangasek: it's discussed here: https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/275592 (but in any event, changing it is more trouble than it's worth because it would introduce an untranslated string)
<ubottu> Ubuntu bug 275592 in ubuntu-docs "awkward punctuation in "about ubuntu" docs" [Undecided,Fix committed]
<mvo> doko_: should icedtea6-plugin the default when searching for a java plugin in gnome app install?
<Mirv> mvo/doko_: since it's now impossible to install icedtea-plugin via g-a-i, I've reported it as bug 283950
<ubottu> Launchpad bug 283950 in icedtea-gcjwebplugin "[intrepid] Replace icedtea-gcjwebplugin with icedtea6-plugin in gnome-app-install" [Undecided,New] https://launchpad.net/bugs/283950
<Mirv> mdke: Dougie seemed to already change some of those, which resulted that there are already missing translations since the current templates in Rosetta don't allow for translating the changes strings
<tkamppeter> pitti, I do not have a /var/lib/dpkg/info/ghostscript-x.files, but a /var/lib/dpkg/info/ghostscript-x.list containing all the files belonging to ghostscript-x. Mine is OK, so I will ask the user to attach his.
<pitti> tkamppeter: sorry, that's it
<mvo> Mirv: I fixed it in bzr already, just wanted to confirm with doko that this is the right onw (I'm pretty sure it is)
<Mirv> mvo: right, I understood what you actually meant only after typing my message
<davmor2> Anyone do you have intrepid on a machine with bluetooth and can you connect to a phone?
<mdke> Mirv: what do you mean? The strings were uploaded to Rosetta a long time ago, no?
<tkamppeter> pitti, for me it looks like some disk-full problem. Here perhaps a better handling by dpkg would be needed.
<pitti> mvo: good morning
<pitti> mvo: mmmm, API change in that update-manager upload?
<Mirv> mdke: probably, but apparently the POT files at least didn't reach Rosetta since eg. the Ubuntu pronouncation in Rosetta is still "oo-BOON-too" while the English text is actually "oo-boon-too", thus no translation match
<pitti> mvo: there are some places in the code which still seem to pass a prompt, not an answer
<pitti> mvo: ./DistUpgrade/DistUpgradeViewGtk.py:        res = self.askYesNoQuestion(summary, msg)
<pitti> mvo: oh, sorry, it's the second arg, no worries
<mvo> pitti: yeah, the change was done a while ago, but it was missed in the textview unfortunately :/
<pitti> mvo: ok, looks quite consistent now
<mvo> thanks for the review!
<mdke> Mirv: that's odd, I'm pretty sure I uploaded the file myself. Weird
<pitti> mvo: EPARANOIA, sorry
<mvo> pitti: that is the right mindset at this time
<Mirv> mdke: yeah, no doubt, but I wouldn't be surprised at another import failure or something... maybe just for the about-ubuntu template or something
<mdke> Mirv: actually, looking at the pot template in the package, it seems it wasn't updated. Sorry about that oversight. Anyway, it won't result in the string being untranslated, it just means the translations will be based on the old string
<mdke> Mirv: I'll make sure it is updated for any post-release translations
<pitti> Riddell: new upstream version of kvkbd is sanctioned?
<pitti> kirkland: argh, password passing as CLI argument? oldest gotcha in the book... thanks for fixing that
<pitti> kirkland: for upstream, the passing as argument should be entirely removed; it sticks not only in ps, but also in .bash_history, etc.
<hunger> It would rock if somebody could add "OnlyShowIn=GNOME;XFCE;" into /etc/xdg/autostart/nm-applet.desktop before the release.
<hunger> Currently that applet gets started in KDE in addition to knetworkmanager applet.
<pitti> doko_: ca-certificates-java> the default file is installed as 644, making the cleartext password world-readable; and if you remove the default file, it suddenly uses a hardcoded default password ("changeit") instead of failing completely
<directhex> java in "fail" shocker ;)
<pitti> hunger: sounds like a good SRU
<Mirv> mdke: Ah, ok. It seems that the (old) translation isn't shown, though. But if it's just about-ubuntu, it's not that bad vs. all pot files.
<mdke> Mirv: yes, I think the problem should be limited to about-ubuntu
<pitti> doko_: gfortran-4.2 gobjc-4.2 want to go to universe, that's ok?
<pitti> doko_: libgcc4 libgcc4-dbg, too
<seb128> pitti, slangasek: could you look at bug #283551?
<ubottu> Launchpad bug 283551 in glibmm2.4 "HOST_NOT_FOUND symbol conflicts" [Low,Incomplete] https://launchpad.net/bugs/283551
<hunger> pitti: Bug number is #268803 by the way.
<hunger> pitti: I am at work, I can't do SRUs:-(
<pitti> seb128: http://svn.gnome.org/viewvc/glibmm/trunk/gio/src/error.hg?r1=544&r2=735 -> nice trick :)
<seb128> pitti: indeed!
<pitti> seb128: http://launchpadlibrarian.net/18823096/changelog.diff looks reasonable to me
<pitti> seb128: so please sync and close the bug
<seb128> pitti: to me too, technically that's a GNOME 2.24.1 update but since sync bypass the queue I asked for reviewed there
<seb128> pitti: will do, thanks
<pitti> (ack'ed in bug report)
<asac> doko_: what is icedtea-gcjplugin?
<mvo> Mirv: could you please attach the full logs in /var/log/dist-upgrade/* to #287551 ?
<asac> doko_: could you add the Npp- headers there too please?
<Mirv> mvo: ok, done
<mvo> thanks Mirv!
<Mirv> mvo: umm. now that I look through the logs myself, I realized that I had upgraded X and Mesa to non-hardy versions. so possibly just my problem, unless there is something very obviously wrong that would be good for robustness.
<mvo> Mirv: I checked and this problem comes from the change in the dependencies of language-support-fi - it now just suggests language-pack-fi instead of recommending it and that make apt think its a no longer used dependency
<mvo> it seems rather strange that language-support-fi recommends language-support-translations-fi (that pulls in OOo-l10n) but not lang-pack-fi
<pitti> mvo: in general, -support shouldn't pull in -pack
<Mirv> mvo: ok, thanks for checking, then there's a real problem
<pitti> mvo: so ideally -pack-fi should pull in -translations-fi, but we don't do that for known reasons (CD size)
<Mirv> pitti: language-pack-fi doesn't fit on the CD either (not since 6.10), so it shouldn't really matter
<mvo> right - I add a quirks handler that ensures that the right thing happens in u-m
<Mirv> mvo: great!
<Mirv> though the dependencies are probably same for most language packs?
<mvo> Mirv: yes, I add something generic
<davmor2> I found a regression from beta https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/288613 I can't get my pc to pair with my phone via bluetooth
<ubottu> Ubuntu bug 288613 in gnome-bluetooth "Intrepid: RC Regression.  Bluetooth no longer pairs correctly which it did in beta" [Undecided,New]
<pitti> hm, did we actually do rebuild tests for intrepid recently?
<seb128> pitti: new yelp in the queue which has rosetta translations
<pitti> seb128: how much bigger does the binary get?
<pitti> seb128: hm, shouldn't yelp translations be in the langpacks?
<pitti> libgphoto FTBFSes, yay
<pitti> ../libtool: line 827: X--tag=CC: command not found
<pitti> WTH?
<persia> pitti, Which gtkmm2.4 do you have?  The 2.24.1 one?
<seb128> pitti: run autoreconf rather than just autoconf to fix that
<pitti> seb128: I didn't do anything, just apt-get source and debuild -b
<persia> (and I believe the last rebuild test was for FeatureFreeze, and I'm not sure people chased all the discovered results)
<seb128> pitti: langpacks -> no because the xml are generated during the build and not using gettext
<pitti> persia: me? I don't have it installed
<bigon> pitti, I get this issue some times too
<seb128> pitti: there is likely a timestamp issue due to a patch which triggers autotools update no?
<bigon> try with updating libtool script in the pkg
<seb128> pitti: that's a "classic"
<persia> pitti, Sorry.  Just there were a number of reports of bits of GNOME FTBFS with the older gtkmm.
<pitti> -rwxr-xr-x  1 martin martin 219286 Oct 24 11:02 libtool
<pitti> seems it does get touched during build
<seb128> pitti: is there any patch changing a configure or makefile?
<seb128> pitti: look at the build log but I bet the autotools are ran on your box
<pitti> seb128: yes
<pitti> so I should purge autoconf/libtool temporarily
<seb128> either that or run autoreconf if your sources after applying the patches and debuild binary
<seb128> if -> in
<pitti> this will become an SRU, so I don't want to fiddle with that
<seb128> ok, so remove automake
<pitti>  gnome-common depends on libtool; however:
<pitti>   Package libtool is to be removed.
<pitti> ??
 * pitti radiates hate towards autof**k and purges cdbs, glade-gnome-3, and other stuff which violently depends on it
<seb128> pitti: remove automake might be enough
<pitti> seb128: don't worry; purging autoconf feels soo good :-P
<seb128> pitti: it'll only do the autotools update if automake is installed I think
<seb128> ;-)
<pitti> seb128: but good to know for the future, thanks muchly
<seb128> pitti: you're welcome
<seb128> pitti: the yelp update, installed size is not much of a difference, less than 300k, the documentation is static xml in the binary so no languagepack there
<pitti> seb128: you mean 300 kB in addition? hm, that's likely to cost us yet another langpack :(
<seb128> pitti: other alternative is to have the yelp start screen not translated
<seb128> pitti: bug #281281
<ubottu> Launchpad bug 281281 in yelp "need to be updated using rosetta translations" [Low,Confirmed] https://launchpad.net/bugs/281281
<pitti> seb128: not much we can do for intrepid; stuff like this should eventually use gettext at runtime, I guess
<pitti> seb128: so please upload
<seb128> pitti: already did
<seb128> pitti: it's waiting in the queue
<seb128> pitti: just curious but what languagepacks are currently on the cd?
<pitti> seb128: amd64: en and es
<pitti> seb128: i386: en es de pt bn
<seb128> urg
<seb128> not a lot
<lool> wow
<seb128> I guess it's late now for the evolution documentation split
<pitti> seb128: that's why I'm fighting for every byte :)
<mvo> Mirv: how did you install the finish language support initially (in 8.04) ? via langauge-selector?
<Keybuk> lifeless, cjwatson: I agree with both of you
<Keybuk> kirkland: imo, if someone runs --usage or --help then the output should be sent to stdout
<Keybuk> *but* if you give them usage instructions when they get something wrong, *that* should go to stderr
<Mirv> mvo: well it's an update from gutsy I think, originally probably at install time by having internet connection available
<pitti> seb128: in fact it's late for this kind of translation update, too (NonLanguagePackTranslationDeadline), but well...
<Mirv> mvo: interesting/cause might be that I briefly tested (the broken) hardy-proposed language packs, then manually installed the hardy-updates language packs
<cjwatson> pitti: well, that's the deadline for translators rather than for uploads, IIRC
<seb128> pitti: right, as said that's either that or no translation, etoomuchtodo, we should have those listed in a "todo before freeze" or something
<pitti> seb128: don't worry, it should be fine
<seb128> not easy to keep track of everything
<Mirv> mvo: (just occurred on my mind)
 * pitti hugs seb128
<mvo> Mirv: thanks, I'm trying to figure out what scope the problem is and it seems like its somewhat rare as installs via lanauge-selector should be fine, not sure about fresh installs yet
 * seb128 hugs pitti
<doko> pitti: will change ca-certificates-java
<doko> pitti: g* is ok, libgcc4* is main (hppa only)
<pitti> doko: out of interest, why does it need encrypted storage of certificates?
<pitti> doko: ah, thanks
<Keybuk> cjwatson: I have a bug for missing /dev/rtc - do we think that could be fixed before release or wait for SRU?
<doko> pitti: java knows only one keystore, so if you only have public certs, it can be world readable, but if you store your own certificate, it has to go into the same keystore
<cjwatson> Keybuk: do you know what's causing it?
<pitti> doko: you mean for your own secret key? other SSL keys are just stored in plain text and protected by file access bits; so that doesn't work in java?
<Keybuk> cjwatson: yes
<Keybuk> the kernel now calls is /dev/rtc0
<Keybuk> it needs a udev rule adding
<Keybuk> SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc"
<Keybuk> :p
<cjwatson> clock-setup does:
<cjwatson> # rtc-dev creates a /dev/rtc0, so set up a symlink
<cjwatson> # XXX This won't be needed once a new udev (116) that
<cjwatson> # handles the symlink gets into Debian.
<cjwatson> if [ -e /dev/rtc0 ] && [ ! -e /dev/rtc ]; then
<cjwatson>         ln -sf rtc0 /dev/rtc
<cjwatson> fi
<cjwatson> :-)
<cjwatson> though that doesn't persist after installation, it's just for hwclock
<Keybuk> where is clock-setup?
<cjwatson> this seems like the sort of thing that will bite us with hwclock not running
<cjwatson> so I'd say it should go into final
<Keybuk> how do you mean?
<Keybuk> it breaks vmware apparently
<cjwatson> hwclock uses /dev/rtc, doesn't it?
<Keybuk> not sure what hwclock uses
<cjwatson> hwclock/hwclock.c:1184:#define RTC_DEV "/dev/rtc"
<cjwatson> actually I think it might fall back to rtc0
<cjwatson> yeah, it does
<doko> pitti: yes, but you have only that one file, not separate files
<doko> asac: what is icedtea-gcjplugin?
<cjwatson> Keybuk: I think it can go into release though - it's trivial and we already know one thing it breaks, there could easily be others
<pitti> Keybuk: buildds pretty much caught up with the backlog; I agree about obvious and safe patches, today is the best day to get them in
<Keybuk> http://people.ubuntu.com/~scott/udev_124-8.debdiff
<Keybuk> ^ review for my sanity plz
<cjwatson> Keybuk: what happens if there manages to be more than one?
<Keybuk> there cannot be
<Keybuk> (reading the driver)
<pitti> or if /dev/rtc already exists for some reason?
<Keybuk> if there were, the first one allocated by that driver would win
<pitti> SYMLINK will just gravefully fail then?
<pitti> erm, "gracefully" *cough*
<Keybuk> pitti: if /dev/rtc exists and is a device node, udev preserves it
<Keybuk> if it's a symlink, it adjusts it
<Keybuk> if it's a file, it spits out a "stop mucking around with /dev" kind of error
<pitti> sounds good to me then
<Keybuk> oh, unless /dev/rtc is a device node with the same stat as the one it would be symlinking
<Keybuk> in which case it will replace it with the symlink
<cjwatson> oh, right, limited by driver
<cjwatson> Keybuk: fine then
<cjwatson> oh, um
<pitti> cjwatson: at which architectures does c-m look ATM?
<cjwatson> Keybuk: I believe it's not always rtc_cmos though
<cjwatson> isn't that arch-specific?
<Keybuk> cjwatson: chatting to upstream, the rtc cmos driver is the old one
<Keybuk> so it was the driver that used to be at /dev/rtc before
<cjwatson> although I suppose worst case is that other arches don't get the symlink
<Keybuk> the new drivers have different properties and behaviours
<Keybuk> so with the new subsystem, you may have a /dev/rtc0 when you didn't have a /dev/rtc before
<Keybuk> that rule won't symlink to /dev/rtc - but that seems correct to me - since it would never have been there before either
<Keybuk> there's not a case where after upgrade, /dev/rtc "vanishes"
<Keybuk> there just will be some systems where after upgrade, you have a /dev/rtc0 now
<cjwatson> I was thinking of efirtc and such
<Keybuk> I think that's covered in the rtc_cmos driver
<cjwatson> if you say so - it seems a bit unlikely since EFI isn't "PC-style RTC"
<Keybuk> possibly true
<Keybuk> but then that means they don't necessarily support the same ioctls either
<Keybuk> (according to Documentation/rtc.txt)
<Keybuk> I'm wary of just doing KERNEL=="rtc0", SYMLINK+="rtc"
<cjwatson> Keybuk: I think the rtc_cmos limitation is probably good enough
<Keybuk> at least that won't break anything that worked before ;)
<cjwatson> right
<tkamppeter> pitti, can you have a look at bug 288570? What would you say about its severity? SRU, Release notes entry? Or eben stopper for Intrepid?
<ubottu> Launchpad bug 288570 in ghostscript "Cups eats all hard drive space and print errors when using photo quality" [High,Triaged] https://launchpad.net/bugs/288570
<Riddell> pitti: kvkbd is good from me
<Mirv> mdke: hi. the new yelp didn't fix "Assistive Tools". do you remember/know what should still be done to translate that topic like before? upload ubuntu-modifed accessibility-guide instead of default?
<sebner> StevenK: ah mighty steven. thx for your comment on twiki. the problem is that there are only 6 days left until release and we are not sure what to do now (especially myself because I'm not that a web/server guy). any suggestion?
<emgent_> kirkland: ?
<pitti> cjwatson: apparently component-mismatches doesn't look at ia64 and hppa (otherwise it'd not complain about the -hppa kernel/ooo-dummy-ia64 stuff); it seems it does look at sparc, though? the inkscape and gcc-4.1 bits are done for i386/amd64/powerpc, just inkscape FTBFSed on sparc (some boost portability issue, it seems)
<tkamppeter> pitti, can you have a look at bug 288570? What would you say about its severity? SRU, Release notes entry? Or eben stopper for Intrepid?
<ubottu> Launchpad bug 288570 in ghostscript "Ghostscript eats all hard drive space and prints errors when printing with 1200 dpi" [High,Triaged] https://launchpad.net/bugs/288570
<pitti> tkamppeter: havent' forgotten about it, it's in my work queue :)
<pitti> tkamppeter: not a showstopper by any means, it only affects a small percentage of use cases, and such things can very well be fixed in an SRU
<pitti> tkamppeter: but as long as there isn't even a solution yet, we can't start an SRU either
<tkamppeter> pitti, so we simply wait for the upstream developers to fix it for now.
<persia> That, or work on it, and send the patches upstream.
<alkisg> Hi, on an acer 5920G laptop the "brightness-up" key does change the brightness, but it increases it 2 times, and also echoes a "Â±" character. It worked fine in Hardy. It does this both on X and on plain console. Which package could be the cause of this?
<StevenK> pitti: Please check and accept linux-lpia at your convience
<pitti> StevenK: done
<StevenK> pitti: \o/
<sladen> alkisg: once in hardware, once in software?  Or once via ACPI and once via  brightness-key -> gnome-settings-daemon?
<alkisg> sladen, I just press Fn+right key on keyboard, and I see the brightness going up twice. But the main problem is the Â± character which is echoed. Here's a more detailed description: https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/281951
<ubottu> Ubuntu bug 281951 in hotkey-setup "Acer Aspire 5920G Fn keys not working correctly" [Undecided,New]
<alkisg> So I wanted to try to debug this, but I don't know where to start
<sladen> alkisg: the character is the 177 keycode being sent
<alkisg> sladen, yes, but why does it send 6 keycodes? It should only send 2.
<alkisg> (like it did on Hardy)
<alkisg> sladen, what is between the kernel (which I assume works OK) and the showkey application? evdev?
<sladen> alkisg: grep -rE 'e0(4c|4e|54)' /usr/share/hotkey-setup/
<alkisg> sladen, /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e04c	$KEY_MACRO
<alkisg> /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e04e	$KEY_KPPLUSMINUS
<alkisg> /usr/share/hotkey-setup/atkbd.hk:setkeycodes	e054	$KEY_RESERVED
<sladen> alkisg: yes, they're 3 keys that are already defined in a normal keymap
<alkisg> This is the one I'm using? I thought it was acer.hk...
<sladen> atkbd is the base map, the kernel defaults
<alkisg> Uh, I see... but why 6 keycodes?
<sladen> alkisg: however, those 3 keys are already defined as doing $something_else,  and they are not overriden for your acer;  So create a new  acer-2500.hk  (copy the -1600) and add those three in to that file
<sladen> alkisg: not sure why six.  Either it's (1) Fn-down, Left, Something.  or (2) If a cyclic loop between gnome-power-manage and bak to ACPI
<alkisg> sladen, and I should map the first one to the brightness, and 'discard' (=RESERVED) the rest two?
<alkisg> sladen, and where do I declare that I want to use acer-2500.hk?
<sladen> alkisg: add a match to /etc/init.d/hotkey-setup
<alkisg> sladen, thank you very much! :)
<sladen> alkisg: see what effect nulling (RESERVED) each of those out has
<sladen> alkisg: and then we can move on to tackling HAL so that you get brightness notifications, but not a double change
<alkisg> sladen, thanks, I'll try it
<sladen> alkisg: ideally keep notes on the bug report as you go along, particularly so that things like this IRC conversation don't get lost
<alkisg> sladen, I'll post my finding (if any) on the bug report
<alkisg> sladen, for quicker testing, does setkeycodes take effect immediately?
<sladen> alkisg: setkeycodes does;  but if you do sudo /etc/init.d/hotkey-setup restart   that will cleanly save and resave the keymap
<alkisg> sladen, thanks again
<pitti> StevenK: octave-gpc was unfixable, you said? at this point I'm just going to ignore it and kill libhdf5-serial-1.6.5-0 (NBS)
<sladen> alkisg: which if you're testing different combinations is much more useful than doing random scibbles and not knowing what is currently in effect
<StevenK> pitti: Right
<StevenK> pitti: It's unfixable with octave3.0
<pitti> final house cleaning :)
<sladen> alkisg: plus, it'll close the DEFINES for the key names;  setkeycodes only knows about numbers
<superm1> davmor2_lunch, pong
<pitti> mvo: bug 231371 - has that actually been done?
<ubottu> Launchpad bug 231371 in soyuz "support dist-upgrader pocket copy " [Undecided,Confirmed] https://launchpad.net/bugs/231371
<pitti> mvo: I mean the manual copying
<davmor2> superm1: did you work with the bluez-gnome package?
<superm1> davmor2, yeah a fair deal
<mvo> pitti: no manual copy, I work around the lack of this in the meta-relase file by setting explict version. bad but works
<davmor2> superm1: https://bugs.launchpad.net/bugs/288613 I'm after trying to figure out what is going on with it.  Just after beta when the new applet came in it worked fine.
<ubottu> Ubuntu bug 288613 in bluez-gnome "Intrepid: RC Regression.  Bluetooth no longer pairs correctly which it did in beta" [Undecided,New]
<pitti> mvo: ok, *phew*; that scared me for a bit
<superm1> davmor2, so you've paired the same phone at beta, was that with the same install?
<mvo> pitti: it would be cool if that bug would be fixed in soyuz, but for now the workaround is doing its job, fortuantely the meta-release stuff is flexible enough
<mvo> hm, what was the url again to see the launchpad translations export queue?
<pitti> mvo: ok, so I can unsub u-archive@ from it?
<davmor2> superm1: No I'm a tester so I'm constantly re installing
<mvo> pitti: fine with me
<pitti> mvo: *export* queue?
<superm1> davmor2, hum okay.  are you sure you've removed the old pairing "from the phone"?
<davmor2> yeap
<superm1> davmor2, okay then the best thing you can do is stop the init script (/etc/init.d/bluetooth stop) and run sudo bluetoothd -nd from a command line and attach that output.  i'm at quite a loss where a regression may have developed.
<davmor2> superm1: Okay thanks for the help :)
<mvo> pitti: I'm wonder where my update-manager export is :)
<mvo> pitti: the translations export for it I mean
<superm1> davmor2, given that you're doing testing, if you can identify the versions of the packages that "did" work by running those live disks again and ensuring pairing works, it might help narrow down the regression.  i'm fearful that it might have been something in the kernel module that got updated though, since I don't recall any patches the last two weeks to bluez or bluez-gnome that would be expecting this to happen.
<pitti> mvo: might be the same fate as general ubuntu langpack exports -- takes aaaaages
 * mvo weeps a bit silently
<davmor2> superm1: dvd-rw's unfortunatley.  I downloaded the beta but that has the old applet in.  So it must of been shortly after that.
<superm1> davmor2, ah too bad.
<MacSlow> argl... why doesn't type-head/lookup in a GtkListView no longer work?
<MacSlow> know bug or disabled intentionally?
<davmor2> superm1: Meh It's not even finding the phone now I'll remove the bluez-compat package and try again
<persia> bluez-compat may well cause issues for those who don't *need* it.
<pitti> BenC: http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html -> l-b-m-virtual depends on linux-backports-modules-2.6.27-7-virtual, which doesn't exist; should it exist, or should the metapackage be dropped?
<BenC> pitti: ah, it should depend on lbm-x.x.x-server
<davmor2> superm1: Would Can't set link policy on hci0: Connection timed out (110) have anything to do with it?
<pitti> BenC: ok, that's just a simple linux-meta upload then; can you prepare it, please? (if you are busy, I can do it as well, I figure)
<superm1> davmor2, most definitely.  If it times out connecting, there's an issue there :)
<BenC> pitti: I can
<pitti> BenC: cheers
<pitti> BenC: then you have the honor of doing the upload which will make intrepid_probs empty :)
<davmor2> superm1: but it didn't happen on the older version of the applet in beta, I re-tried it and it connects flawlessly
<superm1> davmor2, well the only other thing that you can easily do to identify where the regression developed is to grab the older bluez and bluez-gnome packages off launchpad in reverse sequential order
<davmor2> superm1: I've added the out put from sudo bluetoothd -nd to the bug
<BenC> pitti: cool, done :)
<kwwii> mdke: sorry to say it, but I have to remove the panel background in Intrepid, so the screenshots of the panel/full desktop need to be redone
<davmor2> superm1: looking at it, it was probably the 30/09/08 that worked and the 07/10/08 that doesn't
<superm1> davmor2, 09/30/08?  I'd be doubtful there, bluez 4.x wasn't introduced until 10/7/08
<superm1> https://edge.launchpad.net/ubuntu/+source/bluez
<StevenK> superm1: So, he's saying it worked with 3.x and doesn't with 4.x?
<superm1> StevenK, well he said he paired with the new GUI, and the new GUI didn't work with 3.x
<davmor2> StevenK: I have it working fine with 3.x and when the new version came to the desktop I noticed the cahnge and tried it again.  That time it worked fine went through all the pages and gave me a pin to type into my phone, it then connected and I could browse.  Now it isn't
<davmor2> superm1: so how do I go about installing the older version?
<superm1> davmor2, you should be able to click versions on that link i just posted and get direct debs
<superm1> and just install them using dpkg -i
<davmor2> superm1: will I need to get the newer version off first or will it over ride it?
<superm1> it'll override it when you dpkg -i
<superm1> davmor2, i've got to step out, lets continue over pm though.  we probably should have earlier
<alkisg> sladen, I created an acer5900.hk and it solved the "Â±" character problem (but not the gnome-power-manager cyclic loop, I'll try to look into this later). I'm thinking of generating a correct acer5900.hk with all my laptop special keys (some other keys don't work).
<alkisg> sladen, to do this, I'm thinking of (1) dumping the original keycodes, (2) modifying the keycodes to match my laptop, (3) save these differences as acer5900.hk. Is this method correct? I mean, are all the differences I see specific to my laptop model, or maybe some belong to another .hk file?
<alkisg> sladen, then I'll upload the acer5900.hk to the bug report, commenting how I created it
<sladen> alkisg: stop hotkey-setup,  use showkey -s  and go around your keyboard, record the results
<bluefoxicy> 8.10 beta isssn't reading my CF reader anymore
<bluefoxicy> [88017.013901]  sdc: sdc1
<bluefoxicy> [88017.029588] sd 9:0:0:0: [sdc] Attached SCSI removable disk
<bluefoxicy> bluefox@icebox:~$ ls /dev/sd*
<bluefoxicy> /dev/sda   /dev/sda5  /dev/sda7  /dev/sdb   /dev/sdb2 /dev/sda1  /dev/sda6  /dev/sda8  /dev/sdb1
<bluefoxicy> honestly, I don't know what's going on.  The kernel seems to understand, udev maybe?
<Keybuk> bluefoxicy: anything in /sys/block/sdc ?
<zul> whats the kde file manager called?
<dendrobates> zul: dolphin
<zul> dendrobates: thanks
<dholbach> argh, how many times I already hit ctrl-alt-backspace accidentally
<jdong> there must be a more elegant way to hack this kernel config, but I haven't had enough coffee yet.
<jdong> bye bye, abi-check-*
<cjwatson> pitti:         for arch in [ "i386", "amd64", "powerpc", "ia64", "sparc", "lpia" ]:
<cjwatson> pitti: (re architectures in component-mismatches)
<munckfish> cjwatson: is it at all possible to do a one off daily build of the ports CDs so I can verify finally if install/boot is going to be possible on PS3?
<cjwatson> munckfish: alternate or desktop?
<directhex> it's a little late for it, but can i suggest demoting mono-dbg to universe? it contains managed debug symbols (i.e. nothing gdb can use), and i'm pretty sure none of ubuntu's fancy apport stuff deals with those. mono-jit-dbg is the package for crashes of mono itself, with stuff in /usr/lib/debug
<munckfish> cjwatson: ummm both?
<directhex> and that one's in main already
<cjwatson> munckfish: ok, running
<munckfish> cjwatson: although to be honest, I wasn't aware the live/desktop version was even possible on PS3, I've been testing the alternate
 * munckfish doesn't hold out much hope for the desktop version
<cjwatson> certainly used to be
<cjwatson> I put some work into that :)
<munckfish> cjwatson: ok well sincerely sorry I didn't give it any attention
<munckfish> cjwatson: How long do you think they need to run?
<munckfish> cjwatson: ie when should I look to download em?
<cjwatson> munckfish: alternate should be ready in 15/20 minutes or so
<directhex> the PS3 has enough RAM for live?
<munckfish> ok cool
<cjwatson> directhex: just
<munckfish> directhex: no it defaults to install not live apparently
<cjwatson> well, that's still live in a sense
<munckfish> cjwatson: live? seriously?
<munckfish> ok
<cjwatson> that may not be necessary any more mind you
<cjwatson> live should only need 256MB in 8.10 rather than 384MB in 8.04
<directhex> does intrepid at least boot though? that was kinda a downer for hardy
<munckfish> cjwatson: yay! you mean you managed to get it back down again!
<munckfish> cool
<munckfish> well there's something to try out in Jaunty I guess
<munckfish> directhex: yes it does, just
<munckfish> by the skin of our teeth it does
<munckfish> although we've just had to disable usplash
<ScottK> NCommander: I just pushed your fetchmail patch for Intrepid.  That's for assembling it.
<munckfish> directhex: it was working fine until about a week & a 1/2 ago
<directhex> munckfish, handy :|
<munckfish> directhex: but yes it will be installable and working
<directhex> munckfish, how many "nice things" have filtered down into ps3 linux yet? is switching from wired to wireless still a colossal pain in the read end? sensible ways to change resolution?
<bluefoxicy> bluefox@icebox:~$ ls /sys/block/sdc/
<bluefoxicy> bdi	    dev     holders  queue  removable  sdc1  slaves  subsystem
<bluefoxicy> capability  device  power    range  ro	       size  stat    uevent
<bluefoxicy> Keybuk: ^^^^^
<bluefoxicy> Keybuk:  (sorry, was trying to play Metallica)
<Keybuk> bluefoxicy: if you disconnect it and reconnect it while running "sudo udevmonitor -e" what do you get?
<bluefoxicy> sudo: udevmonitor: command not found
<bluefoxicy> Keybuk:  there's a udev update available.  Should I try updating?  (Can I do it without rebooting)
<pitti> lool, StevenK: that korou upload, is that sanctioned?
<Keybuk> sorry
<Keybuk> udevadm monitor
<lool> pitti: sanctionned?
<Keybuk> the udev update should not be relevant
<munckfish> directhex: the feature list for Intrepid on PS3 was: 1) installable, 2) working anything else is a bonus. There weren't too many folk contributing to it in this last cycle
<pitti> lool: "new upstream release", sounds a bit scary; I heard it's a mobile-ish package
<lool> pitti: It fixes very important bugs, notably one of the milestoned ones
<bluefoxicy> bluefox@icebox:~$ sudo udevadm monitor -e
<bluefoxicy> udevmonitor will print the received events for:
<bluefoxicy> bind failed: Address already in use
<lool> pitti: It's a new upstream release because StevenK is upstream for it, but we're the only users
<Keybuk> sounds like you're already running it somewhere else?  check ps
<lool> pitti: It's just bug fies
<lool> fixes
<bluefoxicy>  3003 ?        00:00:01 udevd
<bluefoxicy>  3009 ?        00:00:00 udevadm
<pitti> lool: oh, see #u-release
<Keybuk> bluefoxicy: interesting, kill that 3009 :p
<bluefoxicy> Keybuk:  parent is init.
<Keybuk> yeah, I suspect it's the one from udev's init script - curious that it's still running
<bluefoxicy> Keybuk:  did I mention it takes me 3:30 to boot?
<bluefoxicy> I viciously remove 'quiet' from  my menu.lst because I freaking hate the "let's show a non-moving status bar for however long it takes to run one init script so the system looks like it's hanged" bit
<Keybuk> sounds like you have some system problems ;)
<bluefoxicy> it hangs for 3 minutes at "Loading hardware drivers" or something :x  I filed a bug.  Could this be related?
<Keybuk> most likely
<Keybuk> what was the bug# ?
<bluefoxicy> Malone #288173
<ubottu> Launchpad bug 288173 in udev "Booting is slow (3:30) in 8.10 Intrepid" [Undecided,Incomplete] https://launchpad.net/bugs/288173
<Keybuk> ah yes, and it's waiting for information from you ;)
<Keybuk> this looks like a lot of the same problem
<bluefoxicy> ah cool.
 * bluefoxicy sighs.  All this just 'cause he wanted to upload photos of the beer he drank.
<Keybuk> if I were to hazard a guess, I would say that vol_id is failing on /dev/sdc1
<Keybuk> and that's stalling your boot
<Keybuk> and preventing the device from appearing as well
<bluefoxicy> hmm
<bluefoxicy> I just updated to the beta yesterday, when this started happening.
<davmor2> superm1: I need to go now but I've found out by upgrading from beta that 4.12-0ubuntu1 works ubuntu2 doesn't
<Keybuk> what if you mknod /dev/sdc and /dev/sdc1 yourself, and run vol_id on them by hand?
<bluefoxicy> Keybuk:  I'm not entirely sure the major/minor numbers I need.
<Keybuk> 8, 32 and 8, 33 :p
<bluefoxicy> brw-rw---- 1 root disk 8, 16 2008-10-23 23:36 /dev/sdb
<bluefoxicy> mmm, ok
 * bluefoxicy tries that then.
<bluefoxicy> Keybuk:  fdisk -l /dev/sdc hangs.  o_o
<bluefoxicy> bluefox@icebox:~$ sudo fdisk -l /dev/sdc
<bluefoxicy> ^C^C^C^Z^Z
<bluefoxicy> ................. wow.
<Keybuk> I suspect that's the real problem ;)
<Keybuk> that block device is not working properly
<bluefoxicy> yet it works in 8.04?
<Keybuk> it's a CF reader you say?
<Keybuk> can you disconnect it
<bluefoxicy> yes
<bluefoxicy> .... disconnecting it, oddly enough, deletes /dev/sdc*
<cjwatson> munckfish: back down> ogra got compcache integrated, which did the trick
<Keybuk> that's consistent at least
<bluefoxicy> Keybuk:  could it be a kernel bug?
<Keybuk> very likely
<Keybuk> do things work normally with your CF disconnected?
<Keybuk> is your boot normal speed?
<bluefoxicy> though oddly, fdisk hangs while the kernel reports [90857.562138]  sdc: sdc1
<bluefoxicy> I haven't tried
<munckfish> cjwatson: I don't understand?
<Keybuk> please try
<bluefoxicy> alright, let me clean up here and prepare for shutdown <_<
<bluefoxicy> Keybuk:  amuse yourself with this until I get back.  http://www.theonion.com/content/news/dollar_bill_on_floor_sends_wall
<munckfish> cjwatson: oh you mean the memory requirements - yes I see good
<bluefoxicy> Keybuk:  aside from me aborting a routine check of /dev/sda7, boot time was fast without that drive plugged in.
 * bluefoxicy installs kernel update and newer udev.
<cjwatson> munckfish: right
<bluefoxicy> Keybuk:  no luck here.  Updated the kernel and udev and no good.
<Keybuk> it's certainly a kernel issue
<bluefoxicy> Keybuk:  still better than Microsoft on a 6 year release cycle.
<munckfish> cjwatson: that desktop ports cd build anywhere near done? My bandwidth ain't so good at home and not long before I get my bus home :)
<cjwatson> munckfish: dunno, my shell hasn't come back yet
<munckfish> cjwatson: :S
<cjwatson> a live filesystem build tends to take around 45 minutes, and I can't remember if the powerpc and powerpc+ps3 ones parallelise
<cjwatson> so it could be an hour or so more
<munckfish> cjwatson: that's cool, I'll bag em from home later
<bluefoxicy> Keybuk:  confirmed the drive works by plugging it into another computer with 8.04.  http://photos-g.ak.facebook.com/photos-ak-snc1/v347/161/112/1033398210/n1033398210_168206_4776.jpg  :D
<munckfish> I got the alternate one already
<mdz> asac: I can reproduce bug 278095 here if I can be of help
<ubottu> Launchpad bug 278095 in firefox-3.0 "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,Triaged] https://launchpad.net/bugs/278095
<glatzor> evening mvo
<piquadrat> Any kernel devs around? I noticed a bug (launchpad #286285) which I consider to be quite serious. It fully loads the processor and grows kern.log, syslog and messages extremly fast.
<ubottu> Launchpad bug 286285 in linux "kernel 2.6.27-7-generic bug BUG: scheduling while atomic: swapper/0/0x00000100" [Undecided,New] https://launchpad.net/bugs/286285
<asac> mdz: how?
<mdz> asac: see the bug; it happens every time I run firefox to open a new tab in an existing window
<asac> mdz: any idea when that started for you?
<mdz> asac: I'm afraid not
<piquadrat> "extremely fast"  is at a combined 1.3MByte/sec for all three logs, to be precise
<mdz> asac: my best guess would be that char **environ is corrupted somehow
<asac> mdz: could you please try at-spi and drop the memory leak patch there (e.g. 01_from_svn_fix_memory_leaks.patch)
<mdz> asac: confirmed, there's an invalid pointer in char **environ
<asac> (if that makes the other patches not apply, just drop all)
<asac> hmm
<asac> the dupes start on 1st october
<asac> and that patch landed on 16th
<asac> so thats not it
<asac> there was an upload on 30th sep
<mdz> asac: it looks like something called putenv() with a string which is no longer mapped into memory
<asac> hmm firefox ;)?
<mdz> asac: I think it could be caused by, e.g., a shared library calling putenv() and then being unloaded
<pitti> mvo: can you please have a look at bug 288696?
<ubottu> Launchpad bug 288696 in gnome-panel ""Update information" tries replacing non-existent Quit button in brand-new user account" [Undecided,New] https://launchpad.net/bugs/288696
<mdz> asac: does firefox use putenv()?
<asac> mdz: unfortunately, have to go now. thanks for getting that info so far.
<asac> mdz: http://mxr.mozilla.org/mozilla/search?string=putenv
<asac> mdz: also maybe http://mxr.mozilla.org/mozilla/search?string=PR_SetEnv
<asac> (note: a bunch of code isnt in firefox/xulrunner that is searched on mxr)
<asac> mdz: but the remove client is quite a tiny piece of software
<asac> s/remove/remote/
<james_w> asac: you might be able to reproduce if you turn on accessibility in GNOME
<asac> james_w: good point ;) ... where?
<asac> mdz: maybe its a bad idea to access environ ina g_atexit callback?
<james_w> asac: /desktop/gnome/interface/accessibility
<mdz> asac: I wondered
<asac> mdz: i think we should try to get that env on startup
<asac> and hope that its fixed then
<james_w> asac: or System->Preferences->Assistive Technologies, and check "Enable assistive technologies"
<james_w> asac: it will require a log out
<asac> james_w: thanks. will try
 * asac logs out
<asac> james_w: mdz: ok so enabling assitive stuff triggers this. if you are not first i will try the workaround a suggested and maybe investigate whether putenv is used somewhere during a remote client run - over weekend
<calc> i upgraded from rc today and now evolution doesn't know i have any email config!
<calc> and i just finished setting up my filters, argh!
 * calc brb, rebooting hoping the upgrade didn't kill his evolution completely
<slangasek> mdke: right, I'm not suggesting it should be changed again for intrepid, but thank you for the bug pointer - I'm inclined to follow up and re-open, because the current "pronunciation" guide is useless to an English speaker
 * calc trying to start evolution again, /me crosses his fingers
<calc> argh!!!!!!!!!!!
<calc> the setup assistant came up again
<calc> seb128: heard from anyone that the new evolution update ate their setup?
<seb128> calc: no
<calc> hmm actually it doesn't look like it updated today
<calc> i wonder how it made my setup vanish :\
<calc> seb128: do you know where it stores the account settings?
<seb128> calc: gconf
<calc> seb128: do you know where in gconf: apps/evolution ?
<seb128> yes
<seb128> which is in .gconf on your disk
<calc> ok
<seb128> it has the server name, etc there but not the passwords, those are in the gnome-keyring
<calc> its all gone
<calc> :(
<seb128> disk corruption?
<seb128> try grepping in .gconf to see if that's still somewhere
<calc> doubtful everything was working fine until i reinstalled
<seb128> there is no reason an upgrade should change your user configuration
<seb128> reinstalled? I though you upgraded?
<calc> i did a reinstall, not just upgrade, yesterday, but after updating today and restarting evolution it lost all the data
<calc> well both
<seb128> you kept your user directory?
<calc> 1. i reinstalled last night with rc, 2. setup evolution and filters etc 3. updated from rc to todays packages
<calc> i completely reinstalled last night i just copied over a few things i needed
<seb128> gconf being one of those?
<calc> no just left it as it was, so yes i had to completely resetup evolution last night/early this morning
<calc> but then after updating from RC files to todays files all the config went away
<seb128> try grepping .gconf just to be sure but that's weird
<calc> but it looks like evolution didn't even update
<seb128> nothing touch user datas on upgrade
<seb128> that's only the gconf config? nothing else
<calc> grep -r -i gmail *  shows nothing and same for canonical
<seb128> evolution didn't change between rc and now
<calc> directly under .gconf
<calc> yea, weird stuff, if it happens again i will try to look at it closer
<calc> or if you hear any other reports maybe its not just my weird laptop ;-)
<calc> i'm going to immediately backup evolution as soon as i am done this time :)
<calc> at least all my filters are still there so i don't need to set them up again, just have to reassociate them to the right account once i resetup
<mvo> pitti: re #288696 - are you working on this right now? (I see yiu assigned yourself)
<mvo> pitti: (sorry for the late reply I was having dinner)
<RainCT> kees: Hey. You said on http://pthree.org/2008/10/23/shadowed-passwords/ that $6$ is the default for Intrepid, but I have $1$ here (clean install)
<RainCT> kees: or was the change done just a few days ago?
<kees> RainCT: well that's highly strange.
<kees> what does "grep pam_unix.so /etc/pam.d/common-password" show?
<kees> RainCT: ^^
<RainCT> kees: password[success=1 default=ignore]pam_unix.so obscure sha512
<RainCT> kees: but /etc/shadow says  rainct:$1$.....
<kees> RainCT: interesting.  well, if you change your password (or add a new user) it should switch to $6$.  I'll have to dig into the installer -- there must be something in there.
<RainCT> kees: oh, right, it changed now
<kees> evand: any idea how the installer builds the initial user's password hash?
<Mithrandir> I think it might be using chpasswd or perl
<Mithrandir> I can't remember, though
<lool> Good WE folks
<calc> cjwatson: bdmurray managed to reproduce the 999 issue
<calc> cjwatson: or rather he saw it earlier this past week
<maxb_> The X ABI issue which meant Intrepid needed a new fglrx... does that also cut the other way, and mean the old nvidia drivers are no longer compatible with the new X?
<maxb_> I just tried to downgrade to nvidia-glx-96 to see if it affects some graphics issues I was having, and got ABI errors.
<maxb_> In which case, the old nvidia-glx-NN packages probably need to be pulled from Intrepid?
<bryce> maxb_: yes, the two oldest -nvidia's have the same problem
<maxb_> Not much point shipping them in Intrepid, then?
<bryce> maxb_: I thought superm1 or tseliot had already removed them but you may want to ask them specifically
<maxb_> No, they have not been removed
<bryce> I'm fairly sure there is code in place to move upgraders with those drivers over to -nv
 * maxb_ wonders if mvo is around for a quick ack/nack on that question.
<bryce> maxb_: no I mean you should ask them for why they were not removed
<superm1> bryce, it sounds like those two packages need to be explicitly not providing the new abi
<superm1> like how tjaalton had fglrx for a little bit
<superm1> they're sticking around I believe in case NV decides to fix them so that they are SRU'able
 * tseliot nods
<maxb_> The problem at the moment is that the "Hardware Drivers" applet will happily let you switch to them
<tseliot> maxb_: https://bugs.launchpad.net/ubuntu/+bug/288662
<ubottu> Ubuntu bug 288662 in jockey "Incompatible Restricted drivers offered for Legacy Nvidia Cards" [High,Fix released]
<tseliot> it was fixed in jockey 0.5~beta3-0ubuntu5
<maxb_> aha, it's all in hand
<mvo> maxb_: yes
<leagris> hello
<leagris> Yet again, latest upgrade killed french locales for Firefox 3.0.3
<leagris> that's enough of this, sorry to rant, I'm tired. How can I help non english speaking friends family old aunt with this. To this regard it realy suck.
<leagris> that is the second time in 3 months the french translation for firefox dissepear
<leagris> Hardy heron is supposed stable, isn't it ?
<persia> leagris, There's a bit of a delay between the publication of an updated package and the publication of the updated language packs.  If you want to be sure to avoid that, wait until there is a language pack update when upgrading.
<persia> If you have any ideas how to better coordinate updates of translations for updated packages, we'd be glad to hear it, but for now, there's just no easy way to do it.
<leagris> persia, indeed. Each time I show the update icon on task bar, I click update and voila. My old aunt do the same because I told her Ubuntu has to be kept up to date to be ok and secure ;D
<ScottK> persia: If we didn't have a process that fundamentally seperated packages from translations then it might work out better.
<slangasek> even FF upstream fundamentally separates the software from the translations, though, so I don't think you'll get much help there
<slangasek> also, they don't use gettext --> fail
<leagris> thanks all, sorry for writing my frustration here
<persia> ScottK, True, although I like the extra megabytes for an image.
<ScottK> persia: The current system has advantages, but it has a lot of negative too.  In Kubuntu there are still obscure languages like German for which there is not yet a language pack (at least last I heard it was still pending).
<persia> ScottK, Isn't that just a problem for intrepid?  Has there been a history of it being broken?  (And yes, I agree it's *very* bad)
<pochu> do firefox stable updates break translations?
<ScottK> Well template acceptance was late (which is a common problem) but that masked a specific problem with the KDE4 templates that then got us where we are now.
<ScottK> So it has some unique factors, but they only aggravated a generally fragile situation.
<persia> pochu, All SRUs break translations.
<slangasek> pochu: firefox's l10n model is special
<slangasek> persia: er, no?
<persia> pochu, Or rather, all SRUs in main do.  firefox is *especially* bad, for various reasons.
<persia> slangasek, No?  Do you mean no because not all SRUs include string changes, or is there a mechanism I don't understand?
<slangasek> Normal packages only break translations when they break the source strings
<slangasek> firefox is special because its translations are bundled together with other stuff that breaks across minor revisions
<ScottK> I'm starting to feel we might be better off just to enable the upstream update method for FF and leave it at that.
<persia> So if people used konqueror and epiphany, they'd have less translation skew pain?
<persia> ScottK, That's a very slippery slope.
<ScottK> persia: Well they are pretty uniquely hard to deal with.
<superm1> pitti, have you been setting tags at all for non critical things in hal-info to make sure that you remember to close out bugs when the fixes land upstream?
<persia> ScottK, Well, yes, but allowing *anything* to have third-party updates seems dangerous to me.
<ScottK> True.  Perhaps we shouldn't ship it all then.
<slangasek> persia: yes, konqueror and epiphany have less translation skew pain.  At a minimum, anything that uses gettext for translation gets the benefits of partial translation for those source strings that haven't been changed.
<ScottK> My choice (if it were up to me) would be to turn the branding off and treat it like a normal package.
<ScottK> Also when we patch those packages it's usually our patch, not an entire upstream release.
<persia> leagris, As a partial solution for today, you might try the alternate browsers then.
<leagris> persia, I can use firefox in english, not realy impacting for myself. I just got a coll from my aunt telling me somthing like "help, I don't know what I did wrong but my firefox speaks english and its confusing. Would you please come and fix it when you are available?"
<persia> leagris, I understand.  Short term fix is epiphany for Ubuntu Desktop and konqueror for Kubuntu Desktop.  Longer term fix is waiting for firefox to go back to french.
<leagris> thanks all for your kindness
<leagris> especially persia
<leagris> have a nice weekend
<wgrant> Can I tell do-release-upgrade that I know what I'm doing and that it should get its hands off my damn sources.list?
 * davidm is away: 
<mvo> wgrant: is your sources.list all intrepid already? it is a bit stupid when it comes to this, there is no such option at this point, you could hack it in though
<calc> how do i switch to the guest user in intrepid?
<calc> i need to test a bug
<persia> fusa, as long as you have gdm-guest-session installed.
<calc> so it doesn't work with just regular login?
 * calc just added the fusa to test it out
<persia> Oh, should work for that too, but that's the answer to "How do I log into a guest user session in intrepid"
<persia> For switching, you want fusa.
<calc> ok
#ubuntu-devel 2008-10-25
<Nafallo> slangasek: hi :-)
<slangasek> Nafallo: hey-o
<Nafallo> slangasek: I haz release question :-)
<slangasek> I haz release answers!
<Nafallo> slangasek: since we are pushing this 3G thing quite a lot in the release notes, would a small update to hal-info be able to make it into the archive before final is made?
<slangasek> it has a chance, at least
<Nafallo> basically adding four usb device ids and have support for four popular nokia phones.
<Nafallo> their flagship N96 being one of them. that one is on every damn advertisement incl. mobiles in the UK right now :-)
<Nafallo> so support OOTB would be handy :-)
<Nafallo> slangasek: what do you think. should I prep a debdiff for it? :-)
<slangasek> Nafallo: sure
<Nafallo> slangasek: perfect. I'll go to work right now with it :-)
<superm1> Nafallo, while you're at it, if hal-info is being uploaded, squeeze 288888 in too maybe?
<superm1> bug 288888 that is
<ubottu> Launchpad bug 288888 in hal-info "Dell 5720 Sprint device not detected by NetworkManager" [Wishlist,Confirmed] https://launchpad.net/bugs/288888
<superm1> i already got it landed upstream
 * Nafallo looks
<wgrant> I'd imagine that hal-info will be getting a bit of SRUing.
<Nafallo> wgrant: we should support as much as possible, and if each new device comes of a cost of 5 character whitelisting I can't see a reason not too include something that cheap.
<wgrant> Nafallo: Yep.
<superm1> does hal have facilities for pulling fdi files from /etc too?  I'm thinking maybe a session about discussing a tool for generating an FDI file for testing purposes, and then filing a bug to get it added if it works properly
<wgrant> superm1: /etc/hal/fdi/policy
<wgrant> You can drop whatever you want in there.
<wgrant> I think I've altered all wiki docs to put things there rather than /usr.
<superm1> wgrant, yup that'd be exactly what I was thinking.  I'll think more about this type of tool and what would be involved then
<calc> does anyone know what kind of restrictions the guest account has? for some reason under the guest account OOo can't run
<wgrant> calc: They're very nasty. See /etc/apparmor.d/gdm-guest-session
<StevenK> Woot. NBS is empty
<Nafallo> superm1: ehrm. the dell usbid is different from the bug and in that commit you link to. can you confirm if it's 34 or 44?
<superm1> Nafallo, woops, that's a typo from when i made the patch to submit
<superm1> Nafallo, the one in the bug is right
<superm1> i'll send an email up to the ML
<Nafallo> superm1: ta.
<superm1> Nafallo, good eyes on that catch :)
<Nafallo> :-)
<Nafallo> slangasek: thoughts on bug 284961 ?
<ubottu> Launchpad bug 284961 in network-manager "Option 3G USB Modem (Gio225) not recognized, solution included" [Undecided,New] https://launchpad.net/bugs/284961
<Nafallo> slangasek: worth adding and hoping for testers before we release?
<slangasek> Nafallo: adding to what package?  The bug seems to be filed against two packages
<Nafallo> slangasek: hal-info
<Nafallo> slangasek: basically get it recognised as a modem and not support mode switching.
<slangasek> "not support mode switching"? what does that mean?
<calc> slangasek: it switches between mass storage and modem (aiui?)
<calc> i vaguely recall arne talking about them at uds
<slangasek> and we're going to include an .fdi file that prohibits using the device in the other mode?
<calc> the mass storage side has the windows driver in it, iirc
<slangasek> well, are we sure of that?
<calc> i'm not... ask arne :)
<slangasek> this doesn't sound like an obvious regression-free change to me
 * calc reading bug now
<slangasek> Nafallo: if you're not confident in the correctness of the fix per se, then please leave it for SRU
<calc> slangasek: i'd ask arne to review that bug
 * Nafallo checks up on ReZero
<calc> since he seemed to be heading up the 3g modem stuff at least used to be
<Nafallo> slangasek: oki. I agree :-)
<sistpoty> Keybuk | mdz: mind moderating my post to ubuntu-devel-announce?
<Nafallo> rezero is a utility to disable the ZeroCD (fake USB CD-Rom)
<Nafallo> temporarily at run time for Option 3G cards.
<Nafallo> slangasek: ^-- I think I'll let go of that one :-)
<slangasek> ok :)
<Nafallo> three bugs less \o/
<Nafallo> and four nokias and a dell card supported :-)
<asac> right, we shouldnt try to tackle modeswitch devices right before release ;) ... in future drivers should support that properly. only solutions available are hacky and not suitable for mass-rollout
<persia> I have two modeswitch devices : hardlocking in either mode would be very annoying.
<persia> (mine pass different USB device IDs, so I'm not affected by the bug, but I do use the use-case)
<Nafallo> slangasek: http://home.nafallo.info/bugs/hal-info_20081013-0ubuntu3.debdiff
<Nafallo> slangasek: also uploaded to my PPA
<Nafallo> already building -)
<Nafallo> on a 5U server ;-)
<directhex> 5u is a bad thing O_o
<NCommander> o_o;
<Nafallo> no necessarily :-)
<directhex> what makes good use of a 5u chassis?
<Nafallo> that box :-)
<Nafallo> anyway. forget I said anything :-P
<directhex> last 5u box i had was crashy junk :/
<slangasek> you're generalizing about servers based on their size? :)
<directhex> yes!
<Nafallo> ehrm. where did my binary go...
<wgrant> Nafallo: You'll see it in 8 minutes, or you can hack URLs.
<Nafallo> nice
<Nafallo> Oct 25 01:36:35 wizard pppd[3332]: remote IP address 10.6.6.6
<Nafallo> Oct 25 01:36:35 wizard pppd[3332]: remote IP address 10.6.6.6
<Nafallo> oops. sorry for double paste
<wgrant> Erm?
<Nafallo> but yea. it works :-)
<Nafallo> slangasek: want to sponsor? :-)
<slangasek> Nafallo: the RM is about the last person you should be looking for sponsorship from on release week..
<Nafallo> slangasek: hehe. I know. but you're like the only core-dev I can see awake ;-)
<slangasek> since that means either one fewer set of eyeballs on the upload than normal, or it means reducing the pool of available reviewers
<slangasek> asac: are you awake?
<Nafallo> went to bed a while ago :-)
<slangasek> pff
<slangasek> he was up 40 minutes ago
<slangasek> calc: hi
<slangasek> :)
<Nafallo> back
<Nafallo> flatmate is choking outbound with torrents :-/
<Nafallo> slangasek: I'm probably better of tracking down one tomorrow and sleep nowisch. :-)
<slangasek> ok - 'night :)
<kees> cjwatson_: hrm... for intrepid+1 it looks like we need to set "ENCRYPT_METHOD SHA512" in /etc/login.defs and then stop forcing md5 on installer users.  (I just added some details to bug 51551)
<ubottu> Launchpad bug 51551 in ubiquity "newusers uses crypt insted of md5" [Medium,Triaged] https://launchpad.net/bugs/51551
<Nafallo> slangasek: kees will sponsor. just to re-iterate, upload okay? :-)
<kees> ah-ha!  I can read scroll-back.... yeowch I'm tired.  :)
<Nafallo> lol
<Nafallo> good it's a simple debdiff then ;-)
<kees> yeah, looks fine, I'm shoving it now.  thanks!
<Nafallo> I kind of only had energy drinks at home... so I had three :-)
<Nafallo> perfect. thank you :-)
<kees> hehe   okay, g'night!
<Nafallo> kees: gnight :-)
<Nafallo> slangasek: hal-info waiting for approval. and with that, I'm going to sleep.
<Nafallo> :-)
<Nafallo> gnight
<ScottK> StevenK: If you have a moment, I'd appreciate you doing the removals in Bug #288949.  The package is in the joyous position of being neither installable nor buildable and it'd need to be completely ported to KDE4 to get out of that position.
<ubottu> Launchpad bug 288949 in boson-music "Please remove boson, boson-data, and boson-music source and binary: Boson is uninstallable and unbuildable in Intrepid" [Medium,Confirmed] https://launchpad.net/bugs/288949
<StevenK> ScottK: Will do, when I stop getting distracted
<ScottK> StevenK: Thanks.
<ScottK> I figured you might need a break for some fun.
<calc> if a source package builds lots of binary packages and one of the binary packages goes away in a new version shouldn't the old version of the binary package not be there to install either?
<wgrant> No, it just becomes NBS.
<wgrant> And an archive admin needs to remove it.
<calc> ah
<wgrant> But I thought it was said that NBS was empty a few hours ago.
<ScottK> It is empty.
<calc> openoffice.org-ogltrans on amd64 shouldn't still be installable on intrepid
 * wgrant checks.
<calc> unless i am misunderstanding something
<wgrant> It's arch-specific?
<calc> yes
<calc> there is a version for i386 still but the amd64 version is broken
<calc> so it went away for the newer builds
<wgrant> Bug #276629, perhaps.
<ubottu> Launchpad bug 276629 in soyuz "archive-cruft-checker doesn't pick up all cruft" [Undecided,New] https://launchpad.net/bugs/276629
<persia> The NBS script doesn't work for arch-specific : that requires a special "Please remove" bug.
<persia> (or just nudging an archive-admin)
<calc> oh ok, any archive admins around that can remove it? :)
<wgrant> Or a poke-StevenK.
<wgrant> Yes.
<calc> StevenK: poke-ing you :)
<ScottK> StevenK: Also for you list, vm-builder is hung up in binary New.  zul will buy the beer for that one.
<ScottK> you/your
<StevenK> ScottK: All done.
 * StevenK looks at NEW
<ScottK> Thanks.
<StevenK> ScottK, zul: vm-builder ACCEPTed
<ScottK> Great.
<NCommander> persia, ping
<NCommander> persia, I can confirm the cegui-mk4 maintainer has no clue what they are doing
<NCommander> persia, SILLY still isn't compiled in the latest upstream.
<NCommander> ^package
<persia> NCommander, You're saying it's complex enough that you think it needs an SRU rather than a quickfix?
<NCommander> Unless i'm mistaken
<NCommander> This is backports realm because we need a new library in intrepid
 * NCommander is still making sure the missing codec actually isn't packaged
<persia> NCommander, Thanks for looking.  Please comment at http://qa.ubuntuwire.com/bugs/rcbugs/
<NCommander> oh
<NCommander> persia, there is a second work around
<NCommander> Hold on
<NCommander> As long as a PNG supported backend is compiled
<NCommander> smc can be made to work
<NCommander> Given the list of codecs that support PNG
<persia> minimally invasive workarounds are where we are today :)
<NCommander> This can be fixed
<NCommander> persia, well, if this workaround holds water so the speak, we can fix this bug
 * NCommander first opens the debian bug, and points the maintainer to the build log
 * NCommander looks up how to re-open a bug
<StevenK> NCommander: For debbugs? found <number> <version>
 * NCommander nods
<NCommander> thanks
<persia> Does it need to be reopened in Debian?
<NCommander> persia, I'm cooking a fix now
<NCommander> persia, yeah
<NCommander> persia, not the smc one
<persia> Darn.
<NCommander> a bug in cegui
<NCommander> The maintainer is smoking crack since SILLY wasn't uploaded, and there are warnings in the build log about it
<NCommander> But I can fix smc in intrepid
<NCommander> persia, was there an Ubuntu bug?
<crimsun> TheMuso: #274124 likely needs another fix; at least one person has confirmed that 70pulseaudio fails whereas 59pulseaudio does not fail
<persia> NCommander, Not that I saw : just an entry on the RCbugs list.
<TheMuso> crimsun: Trouble is that will cause pulse to run before dbus, and pulse/hal etc uses dbus.
<NCommander> persia, ok, we need an ack from release because this adds a new feature (the library is compiled with an additional codec),
<NCommander> persia, and well, an ack in general since its final freeze
<crimsun> TheMuso: hmm, currently, is dbus invoked via the GNOME session script or via 75dbus_dbus-launch?
<TheMuso> crimsun: by the latter.
<crimsun> TheMuso: ok, so we're currently counting on 75dbus_dbus-launch completing before 70pulseaudio does?
<persia> NCommander, Then we need a bug, with a patch, and request to MOTU-Release.
<NCommander> persia, well, there are no code fixes, just a build-dep added
 * NCommander looks up what he needs in the FFe
<NCommander> After I confirm this fix work
<TheMuso> crimsun: it doesn't quite work like that. Each script adds their executable to the STARTUP variable, which the last file executes: 99x11-common_start
<TheMuso> 6/c
<NCommander> ScottK, what are your bug?
<NCommander> persia, woooo, cegui FTBFS :-)
<ScottK> NCommander: Mine was Bug #288931
<ubottu> Launchpad bug 288931 in clamav "clamd crashed with SIGSEGV in tcpserver()" [Undecided,New] https://launchpad.net/bugs/288931
<NCommander> Oh right
<crimsun> TheMuso: right, but we're still looking at a timing issue :-(
<NCommander> ScottK, the backtrace is kinda O_o;
<TheMuso> crimsun: Yes, but I'm not sure if pulse's functionality would be broken should we run pulse prior to dbus.
<crimsun> it doesn't appear to have broken, but I'll gather more testers in the next day
<TheMuso> ok
<ScottK> NCommander: I'd at least like to distill what's there into as reasonable an upstream bug as we can.  They're releasing a new version in a week and a half and their RCs don't usually get a lot of testing, so this is likely news for them.
<NCommander> ScottK, can you reproduce?
<NCommander> The backtrace is giving me very little so to speak
<NCommander> (it looks like thunderbird and clamav's talk to each other over sockets, and thunderbird sent a bad command causing the segfault)
<NCommander> But thats just specuation without some serious debugging
<ScottK> I haven't had any crashes here, but I don't have Thunderbird or said plugin.
<NCommander> Has that plugin been binary rebuilt against the new API/ABI?
<ScottK> It's a non-packaged plugin, but the clamd API is pretty stable.
<ScottK> It's libclamav that's all over the map.
<NCommander> I don't think this plugin compiles against any clam protocol
<ScottK> No.  It just talks across the socket.
<NCommander> My guess? Bad data
<NCommander> Granted
<NCommander> That shouldn't cause a segfault
<ScottK> Yes.
<ScottK> Crashes are by definition bugs.
 * NCommander grumbles
<NCommander> I have no real interest in weeding bugs out of clamav, but I can help improve the bug report if I can reproduce it
<ScottK> OK.
<ScottK> I'm less after a fix than I am an actionable bug report.
<ScottK> Let me see what I can do with reproducing.
<esac> any idea what happened to class_device_create in 2.6.27 ? my smart card driver is no longer compiling since it seems this function is no longer declared? or did ubuntu intrepid just screw something up in the default kernel config?
<esac> nevermind, i fixed it
<pitti> superm1: hal-info> I don't use tags, I just set them to fix committed
<Hobbsee> If anyone's trying to nominate bugs, but can't, please mention them in -release or something.
<mdke> kwwii: we don't have any screenshots of the desktop in the documentation
<mdke> Mirv: the string comes from the gnome-user-docs package, unfortunately it has quite a few problems in Rosetta at the moment so I think the translation will have to come post-release
<mdke> slangasek: saw your comment on the bug, that's fine yeah
<cjwatson> kees: md5 acknowledged for jaunty but I don't think we have time to fix and test it for intrepid now
<kwwii> mdke: cool, that's less work :-)
<ogra> ogra@osiris:~$ grep "Name\[de\]" /usr/share/applications/cheese.desktop
<ogra> Name[de]=Cheese-Website
<ogra> hmm, so why does my menu properly say "Cheese" in german ?
<asac> was fÃ¼r ein KÃ¤se ;)
<ogra> jau
<asac> KÃ¤se-Website (doesn't sound better for me)
<ogra> lol
<Treenaks> Webcam in German is Website?
<ogra> i'm just curious why that translation doesnt show up in my menu
<ogra> Traxer, definately not
<ogra> err Treenaks ^^^
<ogra> sorry Traxer
<Treenaks> ogra: is there a more specific de-DE entry also in the .desktop file?
<ogra> ogra@osiris:~$ grep "Name\[de" /usr/share/applications/cheese.desktop
<ogra> Name[de]=Cheese-Website
<ogra> nope
<ogra> and the geneic one is Name=Cheese Webcam Booth
<Treenaks> maybe the "-" is special?
<ogra> i have entries with a - in them in the menu, i doubt that
<ogra> i mean its great that that broken translation doesnt show up, but i dont get why it doesnt
<asac> ogra: for me cheese doesnt show up at all here
<ogra> intresting
<ogra> aha
<ogra> ogra@osiris:~$ ls .local/share/applications/cheese.desktop
<ogra> .local/share/applications/cheese.desktop
 * ogra removes
<asac> ogra: yeah. that was expected
<ogra> and now i see Cheese-Website
<asac> congrats
<ogra> asac, should be in Graphics
<asac> i still dont see it at all ... but i will remove that now ;)
<asac> indeed.
 * ogra files a bug about the broken translation
<asac> ogra: just fix it ;)
<asac> ok out for a while.
<slytherin> pitti: is it possible to revert the deletion of electric? You seem to have missed the fact that the package was updated in Ubuntu at version 8.07-0ubuntu1 and the orphaned version in Debian was 6.05-4.
<psypointer> hi
<psypointer> i'm in trouble with kubuntu 8.10. i'm getting dependency problems when installing kde. kdebase-workspace-data 4.xxx-ubuntu11 is installable, ...-ubuntu12 is needed. what can i do to install it with version 11?
<psypointer> or is this a known bug and i just have to wait till the repos are updated?
<ScottK> psypointer: 12 was uploaded last night.  Just wait.
<psypointer> ScottK: oh okay, just waiting for mirror sync, right? :>)
<ScottK> psypointer: Yes.  I have it in my updates here.
<psypointer> hmm okay. how often are the mirrors synced?
<ScottK> No good answer for this.  The most correct one I could give you is 'It depends'.
<ScottK> The build is still pending for sparc.  I assume you aren't on sparc?
<psypointer> you're right. i'm on amd64@de.archive.ubuntu.com :)
<psypointer> well, i'll just retry it in an hour. thanks for your help ScottK
<ScottK> amd64 is built, but it was after i386.  Good luck.
<psypointer> thanks, good bye
<psypointer> ScottK: on archive.ubuntu.com it's the actual version, works perfect, thanks
<bandie91> hi all
<bandie91> help, i wish to create a bootable live cd, with specific packages installed, and personalized dotfiles
<bandie91> is there any livecd-creator?
<kees> cjwatson: yeah, I have no interest in touching login.defs (or the installer) this late.  :)
<NCommander> hey BenC
<BenC> NCommander: hey....have you tried out your zinc account yet?
<NCommander> BenC, I can login, but I haven't pushed any source yet (been spending the weekend w/ mom)
<BenC> NCommander: As long as you can login, I'm happy
<NCommander> \o/
<NCommander> BenC, https://edge.launchpad.net/~ubuntu-kernel-team - out of curiosity, how do I get membership in this team ;-)
<ScottK> NCommander: I think I got my answer on the clamav crash.
<ScottK> Responses from the reporter included "I tried to install the Dazuko modules.  I'm not sure if I removed them or not."
<NCommander> ScottK, Dazuko?
<ScottK> It's a set of kernel modules to enable on-access file scanning.
<ScottK> It's used by some other Linux A/V products.
<NCommander> Oh I see
<ScottK> And last I checked, there was no easy way to make it work right with our kernel.
<NCommander> ScottK, ah good. GOt any more bug reports for me?
<ScottK> NCommander: Whacking stuff off the RC bug list is my best suggestion.
<BenC> NCommander: request it
<NCommander> BenC, request it how?
 * NCommander already applied to the team
<BenC> NCommander: ok, I'll check the member requests later today
<Pazzo> Hi @ll - installed latest Intrepid upgrades today, it messed up my sound support :-( Volume, mixers etc are ok, but there are just strange noises, no sound anymore (Fujitsu-Siemens Lifebook E-Series). Is anyone els experiencing the same problem?
<Pazzo> Sorry, wrong channel
<lukehasnoname> bug #16411
<ubottu> Launchpad bug 16411 in partman-lvm "Installer doesn't warn about unbootable config (/boot on LVM)" [Wishlist,Confirmed] https://launchpad.net/bugs/16411
<lukehasnoname> cjwatson: LILO apparently CAN'T boot into LVM'ed /boot. This bug occurred with me yesterday, and only because I tried installing Fedora did I get a warning about what I had been doing wrong.
<lool> Hmmpf [212572.448858] Xvfb[13814]: segfault at 2 ip 0000000000507665 sp 00007fffbdf60630 error 4 in Xvfb[400000+1b3000]
<lool> cjwatson: I guess mbr built fine in a lpia chroot for you?
<lool> Hmm and now klogd taking 100% CPU
<NCommander> StevenK, poke?
<cjwatson> lool: I can't say I remember, it was a long time ago
<cjwatson> I think I did try but I really can't remember how I set up the chroot
<wgrant> kwwii: Erm, why did you steal my panel background?
<wgrant> Removing it by default, sure.
<wgrant> But removing the actual file wasn't necessary.
<wgrant> Now my panels look crap again.
<elementz> hi everybody
<elementz> i am trying to change the position of the windows created by the notification-daemon. to my understanding, this is only possible through the app that is calling the daemon right? does the api actually offer means of placing the popups by coordinates?
<Nafallo> elementz: hi. please look at the /topic :-)
<elementz> Nafallo: k thx
<elementz> Nafallo: ubuntu-moto would be the proper channel then?
<Nafallo> elementz: #ubuntu
<Laney> Is there a hardy ppa for usb-creator?
<philsf> I'd like to file a bug against the graphical installer. what package should I use in lp?
<slangasek> philsf: if you mean the installer itself, ubiquity.  If you mean the liveCD environment, I'd have to think
<philsf> slangasek: the installer itself. I thought ubiquity was only the windows one?
<slangasek> ubiquity is the graphical installer in the liveCD
<philsf> ok, thanks
<slangasek> the windows one is "wubi"
<philsf> btw, it's a only a wishlist bug, no worries for intrepid :)
<philsf> wubi, that's right
<kwwii> wgrant: because it was not easily editable by a newbie
<kwwii> anyway...time for sleep
<wgrant> You could at least have kept the file in the package...
#ubuntu-devel 2008-10-26
<PovAddict> can apport be used independently of launchpad and Ubuntu packages?
<PovAddict> for example, is there any way for an app I compile from source to configure apport so that it handles its crashes (even though it's not from an APT package), and reports them directly to the developers?
<PovAddict> looks like it's not possible yet...
<cjwatson> PovAddict: ask pitti when he's around (European working hours)
<PovAddict> I actually found a wiki page about it
<PovAddict> about how it's "in plans" :)
<PovAddict> https://wiki.ubuntu.com/ApportForUpstreams
<PovAddict> btw why is the launchpad blueprint part of 'ubuntu' instead of 'apport'?
<jibel> doko: ping
<NCommander> cjwatson, you around?
<ytoox> how can I install TAO on ubuntu?
<ytoox> I mean, tao-opengl
<ytoox> hello?
<NCommander> ytoox, this isn't a support channel, please try #ubuntu
<ytoox> I did, but no one pays attention
<gQuigs> anyone looking at this: 285323
<gQuigs> bug 285323
<ubottu> Launchpad bug 285323 in gnome-power-manager "Losing keyboard and mouse control when changing screen brightness with fn + arrow under intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/285323
<NCommander> Does anyone know a good lightweight repo management tool I can run as non-root?
<ScottK> NCommander: Dunno if it qualifies, but did you look at falcon?
<NCommander> ScottK, never heard of it
 * NCommander wants to have an easy repo tool he can dump into his homefolder on zinc
<ScottK> OK.  Try that.  It's packaged.  Dunno if it fits or not.
<NCommander> I don't have root, so packages are kinda useless ;-)
<ScottK> Oh.
<NCommander> yeah
<NCommander> I want a place where I can easily upload built PowerPC (and other ports) kernels
<NCommander> ScottK, I think I can use reprepro, although I had to install libdb4.6 into a folder in my home folder
<ScottK> Good luck and good night.
<NCommander> thanks ScottK
<pitti> PovAddict: apport has an abstract "CrashDatabase", so one could implement this to do whatever with the reports; /etc/apport/crashdb.conf does the switching
<jussi01> anyone around? if so, can anyone point me to information about why we change libopenal in intrepid? ie. why it had an ABI change?
<Hobbsee> jussi01: when did it have an api change?
<wgrant> It broke ABI, not API, I believe.
<Hobbsee> oh
<jussi01> Hobbsee: not sure exactly, but its different intrepid
<wgrant> Why do you ask?
<wgrant> It's not abnormal to have ABI breaks.
<wgrant> In this case we moved to a different OpenAL implementation.
<jussi01> wgrant: I guess Im looking for a bit more information specifically on what changed
<jussi01> and why it change - what was broken in the old one that needed fixing
<wgrant> Bug #194919
<ubottu> Launchpad bug 194919 in openal "libopenal needs replacement" [High,Fix released] https://launchpad.net/bugs/194919
<wgrant> ABIs break. That's life.
<jussi01> yeah
<persia> jussi01, Because the old one was creative's and not being updated very much, and buggy, and trending towards greater hardware dependence.  We selected a fork that is hardware-independent, and much more active.
<jussi01> persia: ok, thanks a lot.
<persia> jussi01, Umm.  Actually, let me get you a real reason, as that's a bit off-the-cuff
<persia> Debian bug #494909 is probably a good reference
<ubottu> Debian bug 494909 in ftp.debian.org "RM: openal -- RoRA; superceded by openal-soft" [Unknown,Closed] http://bugs.debian.org/494909
<persia> Debian bug #473128 has more discussion
<ubottu> Debian bug 473128 in wnpp "ITP: openal-soft -- linux-port of the windows implementation of the" [Wishlist,Closed] http://bugs.debian.org/473128
<persia> jussi01, For even more detail, read the debian-devel-games ML archives.
<jussi01> persia: thank you very much, I appreciate your help. :)
<juliux> mdz: displaybrighness is still not working on my x41
<askand> Hi! Suppose I would try fixing bug 3235, that would mean adding some files to the defaultinstallation of Ubuntu, how would I do that? How does it work? Would I make a package installing those files?
<ubottu> Launchpad bug 3235 in nautilus "Install Template Documents" [Undecided,Confirmed] https://launchpad.net/bugs/3235
<NCommander> wow, such an old bug
<smarter> ArneGoetje: ping
<smarter> ArneGoetje: https://edge.launchpad.net/ubuntu/intrepid/+source/scim-bridge/0.4.14-2ubuntu4 << I don't understand this change, the new patch checks if scim-helper is running, but there is no binary named scim-helper on Ubuntu...
<smarter> so, the bug fixed by 0.4.14-2ubuntu1 is back
<smarter> and Kubuntu 8.10 has the 10/20 seconds at startup of each app
<smarter> did you test your change?
<smarter> ArneGoetje: just saw that the patch was completely disabled in fact, so my comment on scim-helper is not really relevant
<smarter> But we should revert to the state in -2ubuntu2
<smarter> Riddell: ^
<cjwatson> smarter: do you have the scim package installed?
<smarter> yes
<smarter> and skim
<cjwatson> smarter: I commented on the scim-helper thing when reviewing that change, but as you say the patch is disabled so it's not relevant
<cjwatson> Arne tells me skim should not be installed
<smarter> I tried removing skim but it doesn't work better
<cjwatson> as the bug in the changelog indicates, the state in -2ubuntu2 left GTK broken. We can't just revert to it
<smarter> wasn't -2ubuntu3 which broke GTK?
<cjwatson> I tested Arne's change in GTK when sponsoring it, but was unable to check KDE
<cjwatson> possible, I suppose
<munckfish> cjwatson: FYI just testing the desktop install CD for PS3 - not working :( - uses usplash of course which is one problem, second problem trying install_nosplash option is it can't mount /dev/loop0 or something - investigating
<cjwatson> munckfish: oh, will need to turn usplash off in cdimage too
<munckfish> cjwatson: ok
<cjwatson> ah, but that's no good if install_nosplash is broken ...
<smarter> cjwatson: according to the date of the bug, I'm pretty sure it's -2ubuntu3 which broke GTK
<smarter> so Riddell's change should be reverted
<munckfish> cjwatson: yep, I'm checking that out now will get logs and other info
<cjwatson> smarter: but he made that change for a reason, right?
<cjwatson> I'd like to know what that reason was!
<smarter> me too :P
<cjwatson> I don't approve of reverting changes without finding out what they were for
<munckfish> cjwatson: but good news is installed from alt installer on Friday night, the installer has a few scary moments but once installed everything is working lovely :D
<NCommander> hey munckfish
<cjwatson> smarter: so why would -2ubuntu2 help? all that did was just check whether scim is installed, and the dependency in -2ubuntu4 satisfies that without that patch applied
<cjwatson> smarter: in other words, -2ubuntu2 and -2ubuntu4 ought to be equivalent for KDE, aside from the focus fix
<munckfish> cjwatson: the one scary in the alt is it hangs for about 20/25 mins at 6% in "Selecting and installing software" section, watching the syslog it seems it's reading packages from the disk for about 10 mins with no log, then after a while it says "Extracting templates: 1%, ... 2%  ... etc"
<munckfish> NCommander: hi!
<NCommander> munckfish, see my email to ubuntu-cell?
<munckfish> oh not yet
<munckfish> haven't got my email on
<munckfish> (checking)
<cjwatson> munckfish: anything that isn't a showstopper, I'm ignoring right now
<smarter> cjwatson: hmm, you're right, sorry, the bug is there in -2ubuntu2 too, but not on ubuntu3 on KDE
<cjwatson> right, and ubuntu3 broke GTK.
<cjwatson> so why isn't scim running?
<cjwatson> smarter: are you using a locale where you would expect to use an input method?
<smarter> nop, fr_FR
<munckfish> cjwatson: sure of course wondered if you would be surprised by it thats all
<cjwatson> munckfish: vaguely heard of it, not worried at the moment though
<cjwatson> smarter: ok, so I tested the same kind of scenario in GTK and it was fine
<cjwatson> i.e. scim not running
<smarter> if I launch scim-panel-kde or skim, it works
<cjwatson> so perhaps we should move the check in that patch to the Qt4 agent
<smarter> (no delay on startup)
<smarter> that looks like a good idea
<cjwatson> or I suppose alternatively we could actually fix the check (scim-helper-launcher IIRC)
<cjwatson> scim-helper-manager
<cjwatson> smarter: if you launch scim-panel-kde, is there a scim-helper-manager process running?
<smarter> yes
<cjwatson> smarter: would you be able to build a test package for me from source to try it out, or would you need me to give you test .debs?
<smarter> I know how to build a package ^^'
<smarter> (I'm a MOTU :P)
<smarter> and I'm on amd64 so your .debs would not help me I guess
<cjwatson> that would depend where I built it :-)
<cjwatson> smarter: in that case, try just applying http://people.ubuntu.com/~cjwatson/tmp/scim-bridge.debdiff to -2ubuntu4
<smarter> ok
<smarter> hmm strange, it FTBFS
<smarter> http://pastebin.com/m29828974
<smarter> 00A0C0T0I0O0N0 0t0r0i0e0s0 0w0i0t0h0 0p0b0u0i0l0d0e0r00
<cjwatson> smarter: built fine for me
<smarter> built fine on a pbuilder too, strange
<smarter> your patch seems to work :)
<cjwatson> good, just testing with GTK now
<smarter> and no scim-{panel,helper,...} instance running
<cjwatson> have you tried in both fr_FR and in some locale that uses scim-bridge (e.g. zh_CN.UTF-8)?
<cjwatson> it would be helpful if you could - you just need to check whether you can type letters into an editor or something and have the input method widget appear
<smarter> 00A0C0T0I0O0N0 0t0r0i0e0s0 0t0o0 0i0n0s0t0a0l0l0 0o0t0h0e0r0 0l0o0c0a0l0e0 0u0s0i0n0g0 0q0t0-0l0a0n0g0u0a0g0e0-0s0e0l0e0c0t0o0r00
<smarter> *another
<cjwatson> your IRC client is screwed
<cjwatson> 16:01 <smarter> P0AP0AP0CP0TP0IP0OP0NP0 P0tP0rP0iP0eP0sP0 P0tP0oP0 P0iP0nP0sP0tP0aP0lP0lP0 P0oP0tP0hP0eP0rP0 P0lP0oP0cP0aP0lP0eP0 P0uP0sP0iP0nP0gP0
<cjwatson>                 P0qP0tP0-P0lP0aP0nP0gP0uP0aP0gP0eP0-P0sP0eP0lP0eP0cP0tP0oP0rP0AP0
<smarter> Oo
<persia> smarter, Is that UTF-8?
<smarter> no idea
<smarter> I didn't see that
<cjwatson> it's not UTF-8
<cjwatson> each character is surrounded by some control character junk
<cjwatson> it's only when you use /me
<smarter> Ã¼ber strange
<cjwatson> ok, that works for me except that it should be pidof scim-helper-manager >/dev/null
<apachelogger> smarter: no garbage here
<apachelogger> we learn: quassel ownes them all
<cjwatson> you're both using quassel and I guess it must be buggy then
<smarter> probably
<cjwatson> even smarter's CTCP VERSION output is broken, but apachelogger's isn't
<cjwatson> so perhaps smarter has some kind of "use my proprietary format" option checked
<apachelogger> smarter: do you run the core on your local machine?
<smarter> yes
<smarter> maybe I should restart it
<smarter> since there was an update today
<apachelogger> yes!
<apachelogger> that could have done it
<apachelogger> we screwed up a QByteArray ;-)
<cjwatson> ah yes
<cjwatson> scim-bridge uploaded
 * smarter test
<smarter> ^ better?
<cjwatson> yes
<cjwatson> thanks
<smarter> cool
<smarter> and thank you cjwatson for your patch :)
<cjwatson> smarter: did you have any luck testing in Chinese?
<smarter> I'm downloading it
<cjwatson> I'd feel better if we knew that it worked in KDE with scim switched on too - the fourth case out of four
<smarter> oh, it's installed
<smarter> what's the locale name of chinese?
<cjwatson> zh_CN.UTF-8
<mitsuhiko> is there a chance that wbxml2 is upgraded to 0.9.2-5 before release?
<cjwatson> mitsuhiko: what for?
<mitsuhiko> the current version seems to have a bug. my nokia phone can't sync with opensync
<mitsuhiko> the #opensync guys tell me to upgrade the wbxml2 lib
<smarter> cjwatson: LANG=zh_CN.UTF-8 LANGUAGE=zh_CN KDE_LANG=zh_CN kate, kate pops up, but there is no scim running
<mitsuhiko> http://libsyncml.opensync.org/ticket/153 <- related bug
<smarter> (and it's in chinese, afaik)
<cjwatson> smarter: you need to restart the whole session in Chinese for it to work properly
<smarter> hmm okay
<cjwatson> isn't there a language selection thing in kdm?
<smarter> nop
<smarter> I'll just change the language using qt-language-selector
<persia> mitsuhiko, simultaneous traffic in -motu points at Debian bug #487217 for wbxml2 (and #ubuntu-motu is probably the right forum for this discussion)
<ubottu> Debian bug 487217 in libwbxml2-0 "libwbxml2-0: Several SyncML flaws" [Important,Closed] http://bugs.debian.org/487217
<cjwatson> mitsuhiko: needs an Ubuntu developer to assess bug 267397 / bug 287838 and decide if it's a safe update at this point
<ubottu> Launchpad bug 267397 in wbxml2 "Sync package with debian" [Undecided,New] https://launchpad.net/bugs/267397
<ubottu> Launchpad bug 287838 in wbxml2 "msynctool of nokia 6120 crashes with 0x43 permission denied libwbxml" [Undecided,New] https://launchpad.net/bugs/287838
<smarter> cjwatson: and should I let skim installed or not?
 * mitsuhiko tries the debian package for a moment to see if that fixes the problem
<cjwatson> smarter: I don't believe Kubuntu installs it by default any more now
<cjwatson> mitsuhiko: we are five days before release, and any update needs an Ubuntu developer standing behind it and ready to fix any regressions at short notice
<smarter> but it's probably installed by the language-selector thing
<cjwatson> mitsuhiko: I would suggest that this might be better as a post-release update ...
<cjwatson> smarter: not as far as I know
<smarter> okay, I'll try without
<mitsuhiko> cjwatson: can it become any more broken? :D
<cjwatson> in fact, I'm pretty certain it isn't
<cjwatson> mitsuhiko: it could break other phones
<mitsuhiko> i can't sync a single nokia phone right now
<mitsuhiko> at least none with s60 on it
<mitsuhiko> is there someone in the ubuntu team that uses opensync i can talk with?
<cjwatson> I really can't say whether it's a good idea. Find a developer to investigate it. As persia said, #ubuntu-motu is a better forum
<mitsuhiko> okay
<mitsuhiko> thanks
<smarter> my system is still in french(probably needs a reboot or something else in the config) but I have scim running in the panel
<smarter> bbl
<cjwatson> smarter: and does typing in an editor go through the input method?
<ramvi> Hi, I'm unsure how to ask this question and where to ask it, but I hope maybe you could point me in the right direction: I have a svn server with a web page. How do I do that code accessable as the web page. So that I can make a changes and view it
<smarter> cjwatson: nop
<smarter> å¡é¾
<persia> smarter, That looks right.
<smarter> oh, it works if I choose some random stuff in the left-click menu of scim and then right click on a field --> IM --> scim-bridge
<smarter> at least with pure Qt apps
 * smarter tests with Kate
<smarter> hmm, it doesn't work but IIRC I need to define an env variable to make it work
<smarter> cjwatson: it only works on apps which let me change the input method(Kopete and Quassel, but not Kate or Firefox)
<smarter> but that's probably another problem
<cjwatson> smarter: ok, this sounds like scim configuration oddness rather than anything wrong with scim-bridge, so I'm content
<smarter> I am too :)
<PovAddict> pitti: thx for the info, I'll have a look at that file
<cjwatson> smarter: thanks for the testing
<zyga> hello, is there anyone interested in usb-creator && vmware && fixing small issue I have identified and resolved?
<zyga> I have found that attachning a USB disk enclosure does not allow you to make it bootable for some reason
<zyga> after digging for a second I found out that the issue is caused by HAL not thinking this device is removable, usb-creator does not consider non-removable devices
<zyga> I commented out that single dependency (on removability) and it appears to work fine
<persia> zyga, Surely that's a HAL bug though, rather than a usb-creator bug.
<zyga> persia: I'm going to report it for usb-creator first but I think you may be right
<zyga> still I'm not sure that usb-creator is doing the right thing to require removable devices
<persia> zyga, Hmm.  Well, when would you want to use it for a non-removable device?
<persia> I can maybe see the use case for mmc cards (where the storage isn't removable, because the entire interface is removable), but that's somewhat of a corner case.
<PovAddict> on Windows, if I do "safe remove" on one of the drive letters from my memory card reader, it "unmounts" the card reader, not the card... can't use reader again until I reboot
<PovAddict> would my card reader be considered a removable device by Linux's HAL? (can I check?)
<zyga> PovAddict: yes you can check
<zyga> w8
<zyga> PovAddict: I think you can use hal-device to see what hal thinks about your card reader
<PovAddict> it thinks it's four devices
<ScottK> lamont: Any chance you could give primero a kick and get it going again?
<zyga> I'm going to leave and reboot to my usb disk now
<zyga> if anyone is interested the bug is id: lp #289599
<ubottu> Launchpad bug 289599 in usb-creator "usb-creator does not work with usb/ide disk enclosure" [Undecided,New] https://launchpad.net/bugs/289599
<PovAddict> linux.hotplug_type = 3  (0x3)  (int)
<PovAddict> storage.removable = true  (bool)
<demontager> why alsamixer shows only one channel "Master"? Where is other tunes?
<elliotjhug> hi, this seems like the sensible place to ask this. Does anyone know what the source package is for the Main Menu in ubuntu (the default apps, places, system one)?
<persia> elliotjhug, gnome-menus
<elliotjhug> persia: Thanks
<NCommander> ScottK, you around?
<ScottK> For about 120 seconds
<ScottK> NCommander: ^^
<Laney> Tense! Will he make it back in time?
<ScottK> Nope.  See you all later.
<PovAddict> lol
 * Laney waves
<liw> is it still possible to get a program onto Rosetta (LP's translation thing) for intrepid?
<persia> liw, From traffic in -release, I think the final langpack builds just started, which would mean no.
<liw> dang. ok, serves me right for being late.
<persia> You might be able to get it into the langpack updates, but I don't have any idea how that works.
<PovAddict> the name 'Rosetta' is too overloaded :/
<Lycus> Is there a way to show the guest account available from user switching on the Login window list?
<CarlFK> is there an easy way to get python with debug symbols? my current plan is apt-get source python... build...
<PovAddict> python-dbg?
<NCommander> CarlFK, python2.5-dbg - Debug Build of the Python Interpreter (version 2.5)
<RainCT> CarlFK: uhm.. python-dbg?
<NCommander> lol
<CarlFK> bam bam bam!
<CarlFK> thanks
 * NCommander loves when answers come in stereo
<CarlFK> how many things have a -dbg version?
<PovAddict> apt-cache search -dbg | wc -l
<NCommander> CarlFK, most libraries do
<PovAddict> almost six hundred packages
<NCommander> 738
<PovAddict> 589 here :)
 * PovAddict has hardy
 * NCommander runs intrepid
<RainCT> error here xD
<NCommander> ahaha
<RainCT> E: Command line option 'd' [from -dbg] is not known.
<persia> And when there aren't -dbg packages, there are often -dbgsym packages available from ddebs.ubuntu.com
<CarlFK> hmm.. guess the count isn't what I was wondering ... just knowing about -dbg is all I need
<RainCT> ok, now 735
<RainCT> (with \\-dbg)
<RainCT> NCommander: did you use \\- too or am I weird? :)
<NCommander> YOur just weird
<RainCT> ah k, that explains it all
<CarlFK> http://dpaste.com/86899/  python import fg; g = fg.Grabber();  help(g) segfault.  is that a python problem, or ï»¿ï»¿fg.Grabber() ?
<CarlFK> persia: how do I use a .ddeb?
<CarlFK> fg came from http://antonym.org/libfg
<Rioting_pacifist> i have a pretty bad problem with lsusb #kubuntu and #linux wernt much help
<Rioting_pacifist> basically lsusb, lsmod, modprobe -r, rmmod all freeze up the terminal in which i use them (i can still type in it but nothing has any effect), i think its a pretty bad kernel bug and would like to try and find the cause to report it, any ideas?
<Rioting_pacifist> it was caused by loading up a beta webcam driver but i dont think freezing up the lsusb can be blamed on the driver
<johanbr> Sure it can. Buggy kernel modules can wreak all sorts of havoc.
<jdong> sounds like the module oopsed the kernel
<jdong> that's typically common of buggy kernel modules.
<jdong> look in dmesg for a stacktrace
<Rioting_pacifist> got the stacktrace, makes no sense to me should i pastebin it then pass it on to the webcam driver developers?
#ubuntu-devel 2009-10-19
<slangasek> dtchen: have you actually reproduced the behavior described in that comment on a karmic system?  The commenter says he's using Debian testing, and the *only* way I see that this shutdown script would be called twice is if the user has two symlinks to it by mistake
<dtchen> slangasek: I haven't been able to, but others have.
<slangasek> dtchen: what's their explanation for why it's being called twice on shutdown?
<slangasek> here, I see it being called once and failing because the logic is wrong
<dtchen> slangasek: yes, the logic in 5 is clearly broken. I haven't actually seen anyone explain why it's being called twice.
<dtchen> well, ubuntu4 *and* ubuntu5.
<slangasek> dtchen: so if nobody can explain why they're currently seeing it called twice, I think more analysis (and a more targeted fix) is called for
<dtchen> slangasek: okay
<YokoZar> slangasek: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498
<ubottu> Launchpad bug 369498 in ia32-libs "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress]
<YokoZar> Regardless I'm starting to see other bugs due to what I'm pretty sure is just out of date ia32-libs
<YokoZar> And there's probably security concerns for having month old libraries as well (since if any security issues were fixed in the past month they'd still be there in ia32-libs)
<slangasek> YokoZar: well, as I said the fltk1.1 FTBFS certainly should be fixed for release, but I don't think anyone's going to break their neck to make sure the fix lands with enough time to fix a 6-month-old ia32-libs bug afterwards
<YokoZar> slangasek: that bug's just a bonus, the main benefit is to freshen the packages
<YokoZar> the bug was meant as an example of the symlinks you were asking about
<slangasek> YokoZar: the symlinks mentioned in https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498/comments/63 ?
<ubottu> Launchpad bug 369498 in ia32-libs "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress]
<YokoZar> slangasek: asac: was patching the library to make it handle them as well (I believe the patch went in a month ago), but that hasn't been able to roll into ia32-libs
<Laibsch> Is there still a chance to get a sync ack'd for tegaki* packages?  Those are not widely used I think and upstream has apparently made the second alpha release in August.  0.1 does not work well and I think it would be good if 0.2 got more exposure.
<Laibsch> How does one prepare a debdiff for one of the meta packages?  xubuntu-meta in this case?
<Laibsch> doesn't seem to follow the standard procedure
<StevenK> It wouldn't, it's a based on a seed
<Laibsch> what to do then?
<StevenK> Laibsch: You propose a diff to the seeds, which can be checked out of bzr. I'd then suggest talking to cody-somerville
<Laibsch> OK
 * Laibsch is not a big fan of bzr
<jono> TheMuso, did you see https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/452458 ?
<ubottu> Launchpad bug 452458 in pulseaudio "Add rtkit Conflicts to force removal of rtkit for release testing" [Undecided,Fix released]
<jono> oops
<jono> http://0pointer.de/blog/projects/pa-in-ubuntu.html
<mdke> slangasek: ok, should I add iso-codes as a depends and do another upload? I inserted isoquery because it was giving me errors during the build when i didn't have isoquery installed
<slangasek> mdke: you should add it in bzr, no need for another upload right now
<tjaalton> not being able to cancel the forced fsck in karmic is a bug in what package? apparently it used to work at least in hardy
<slangasek> tjaalton: mountall
<slangasek> (if it's a bug at all)
<mdke> slangasek: bzr is broken at the moment, the branch is corrupted, but I'll certainly do it once I get that sorted out...
<tjaalton> slangasek: thanks
<slangasek> mdke: hrm, ok
<lifeless> mdke: corrupted?
<mdke> lifeless: I filed it as bug 454937
<ubottu> Launchpad bug 454937 in bzr "bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 0 bytes rather than 56795 bytes at 8853769 for "7eb3aa09b5969991699f71e8d264a6e5.pack"" [Undecided,New] https://launchpad.net/bugs/454937
<lifeless> mdke: did you have a power failure?
<lifeless> or crash
<mdke> lifeless: nope, it's the branch on LP that seems to be broken, no idea what happened
<lifeless> mdke: then its not a bzr bug; you should move it to launchpad-code
<lifeless> mdke: as in, it *might* be a bug, but the folk you need looking at it are the LOSA's.
<lifeless> which are best attracted by a question on answers.launchpad.net/launchpad
<mdke> lifeless: ok. I raised it on #bzr and it was suggested that I file a bug but I can also file a question on Launchpad
<lifeless> we like bugs indeed. and we'll want to track the cause
<mdke> ok
<mdke> I was getting the same error when trying to diff or commit to my local repository
<mdke> lifeless: question now filed
<asac> YokoZar: all good to go?
<YokoZar> asac: not with fltk1.1 still FTBFS...
<asac> YokoZar: is that somehow related to ia32 ;)?
<asac> sorry if i lack a bit context ... just started my day :)
<YokoZar> asac: it is, as ia32-libs script requires a syncing of all its component packages, and it freaks out if source and binary don't match
<YokoZar> asac: since the package FTBFS then the source archive is newer than the binary available
<asac> YokoZar: ah ok.
<asac> YokoZar: whats the status on FTBFS?
<YokoZar> asac: https://bugs.launchpad.net/ubuntu/+source/fltk1.1/+bug/445560
<ubottu> Launchpad bug 445560 in fltk1.1 "FTBFS: conversion errors" [High,Confirmed]
<asac> YokoZar: how many do rdepend on that`
<asac> ?
<YokoZar> asac: apt-cache rdepends libfltk1.1 shows 40 packages
<slangasek> how did libfltk1.1 end up in ia32-libs, in the first place?
<slangasek> ah, because someone wanted it for pose
<slangasek> YokoZar: you could just drop fltk from ia32-libs for this upload
<YokoZar> slangasek: that's not a bad suggestion
<asac> YokoZar: isnt that "match source + package" version check a safety belt that we could ignore if carefully checking that no other mismatches exist?
<asac> though in this case - with a potentially pending ABI bump - its probably better to keep it out of ia32 :)
<slangasek> asac: it's there to ensure we aren't shipping binaries that aren't built from the available source... which indeed is what would happen as soon as fltk1.1's FTBFS was fixed
<seb128> slangasek, hey
 * slangasek waves to seb128 
<seb128> slangasek, if I sync new gtk from debian that would bypass the queue right?
<slangasek> seb128: yes
<seb128> slangasek, want to you need to grant the sync, a debdiff online would do?
<slangasek> seb128: that would work
<seb128> ok, will do that then, thanks
<slangasek> pitti, seb128: amd64 has gone oversized again, I believe because of the latest langpack export; next langpack on the chopping block would be French - any ideas how we could free up 2MB somewhere else quickly instead?
<seb128> slangasek, not right now no but I can try having a look today
<pitti> Good morning
<seb128> hey pitti
<pitti> ScottK: if the input layer is okay (which seems to be the case), then you'd need to run powerdevil (or what does that in KDE now?) in debug mode and watch what it's doing
 * slangasek waves
<pitti> slangasek: hm, put on my list, but no offhand idea right now
<slangasek> pitti: heh, of course PowerDevil runs in-process in kded4, that must be fun to debug
<slangasek> pitti: ok, thanks
<seb128> it's all a french hater conspiracy
<slangasek> in the meantime, I'll bump French so we can get started with candidate ISOs
<slangasek> s/candidate/smoketest/
<seb128> slangasek, bump or dump?
<slangasek> seb128: bump off :(
<seb128> hum, k
<seb128> just from amd64?
<seb128> ie it's still on i386?
<slangasek> yes
<seb128> that's already something
<maco> pitti: power devil is right
<slangasek> seb128: c'est pas moi qui dÃ©teste le franÃ§ais, c'est GNOME qui ne veut pas partager les CD ;)
<seb128> on devrait faire du franÃ§ais le language officiel de GNOME!
<slangasek> d'accord
<mneptok> seb128: i'm allowed to hate the French after 3 years in Quebec. ;)
<seb128> mneptok, no you're not!
<mneptok> seb128: notre langue n'est pas le propre. c'est le "nouvelle" et "au courant."
<seb128> slangasek, http://people.canonical.com/~seb128/gtk.debdiff-simplified.gz http://people.canonical.com/~seb128/gtk.debdiff.gz
<seb128> slangasek, the simplified one is a debdiff with po and html filtered out
<mneptok> L'Academie ... pffft!
<seb128> slangasek, should be easier to review
<seb128> mneptok, tu fais des fautes de franÃ§ais!
<slangasek> haha
<mneptok> seb128: did you understand me?
<seb128> mneptok, no
<seb128> must be the accent
<mneptok> seb128: then these issues have not driven you *fully* crazy yet. carry on.
<seb128> ;-)
<jamesh> mneptok: does that mean that you can start hating New Mexicans in 2012?
<mneptok> jamesh: no, it means i can start hating European Spanish-speakers at that time :)
<slangasek> quÃ© va
<pitti> seb128, slangasek: hah! I just found 3.2 MB to free \o/
<mneptok> jamesh: tell Etienne he speaks a funny and outdated version of French. you'll get the whole "those people in Europe know NOTHING!" rant :)
<jamesh> so the Catalans will be safe then.
<seb128> pitti, german langpacks? ;-)
<pitti> seb128, slangasek: bug 385850
<ubottu> Launchpad bug 385850 in hundredpapercuts "Ship fewer screensavers by default" [Low,Fix released] https://launchpad.net/bugs/385850
<seb128> oh
<pitti> slangasek: mind if I do a new ubuntu-meta upload to drop rss-glx?
<seb128> I though that had been fixed ages ago
<slangasek> pitti: GO GO GO
<pitti> seb128: yes, the g-screensaver dependency, but not the u-meta one
<seb128> k
<pitti> viva la revolution!
<pitti> *cough*
<seb128> viva is spanish
<seb128> vive is french
<pitti> excusez-moi
<pitti> (I'm sure that's wrong as well)
<seb128> il n'y a pas de soucis ;-)
<seb128> (not that's correct)
<seb128> not->no,
<slangasek> ni de souris
<mneptok> es tiempo para mi siesta.
<mneptok> ai caralho. mi manos ...
 * mneptok tootles off to bed
<seb128> 'night mneptok
<mneptok> seb128: a bientot.
<mneptok> (i guess i should say "a tootle a l'heure")
<pitti> I put back french into the seeds
 * seb128 hugs mneptok
<seb128> ups
 * seb128 hugs pitti
 * seb128 hands mneptok a french dictionnary
<mneptok> dpkg ERROR: Your cowboy culture is an insult to humanity.
<mneptok> pitti: langpack works.
<slangasek> seb128: ack on gtk
<seb128> slangasek, thanks
<pitti> *chuckles*
<asac> YokoZar: do you know how to move forward?
<pitti> seb128, slangasek: did you already happen to talk about gvfs/rhythmbox?
<YokoZar> asac: basically I'm gonna remove fltk1.1 from ia32-libs
<seb128> pitti, no, I've other things on my plates if you don't want the change that's ok
<asac> YokoZar: ok. and the ftbfs in karmic will be fixed by someone :)?
<seb128> robert_ancell though it would be nice to get since some of the main podcast distributors will have the issue
<asac> YokoZar: otherwise i think getting most rdepends and checking with nm -D if something directly uses that symbol would help
<pitti> I'm a bit torn, Robert says that it breaks a lot of popular podcasts
<slangasek> mneptok: que duermes bien y que los cisnes de pesadilla no te coman
<YokoZar> asac: you'll have to beg slangasek about that (I believe the answer is "not unless someone checks all the rdepends for symbol breakage")
<asac> i am not here for begging ... just see that having apackage ftbfs that will add a symbol if that ftbfs is fixed isnt good ;)
<slangasek> YokoZar: no, I want someone to tell me that the symbols *can't* be used
<slangasek> checking all the rdepends is a poor second :/
<YokoZar> slangasek: I guess that means poking upstream fltk then
<slangasek> no
<slangasek> it means knowing the C++ ABI better than I do
<asac> ok. i am probably out of that set then ;)
<seb128> pitti, concerning the gvfs change not added to git 2.28 I'm not sure how they deal with api addition to gvfs in stable
<slangasek> asac: heh, you do a lot more C++ stuff than me
<seb128> pitti, usually stable series are feature frozen for GNOME
<seb128> pitti, I will check with gicmo when he's online
<pitti> seb128: I don't mind the API addition, but it changes existing code in daemon/gvfsbackendhttp.c
<pitti> hm, actually it just moves it around a bit
<seb128> pitti, I doubt many things use gvfs http anyway
<seb128> looking at bugs we get since we have gvfs the code is not working well for webdav
<seb128> so it's basically used for podcast and http steaming
<seb128> streaming
<seb128> I don't think it can break a lot
<seb128> out of podcast which is already not working...
<pitti> slangasek: so, the gvfs change is mostly just diff producing noise; I think that by itself is safe (will take a look at rb again)
<pitti> slangasek: it just adds a new function
<slangasek> pitti: if it looks safe to you then, go ahead
<ttx> slangasek: could bug 455114 be the root cause for bug 454362 ?
<ubottu> Launchpad bug 455114 in qemu-kvm "builds uninstallable package 'kvm'" [High,Triaged] https://launchpad.net/bugs/455114
<ubottu> Launchpad bug 454362 in eucalyptus "UEC node install from CD fails on installation of qemu-kvm" [Undecided,New] https://launchpad.net/bugs/454362
<slangasek> ttx: <sigh> yes
<ttx> slangasek: ok, will mark it as such
<james_w> oops, sorry
<slangasek> ttx: would you have time to fix qemu-kvm this morning?
<ttx> slangasek: I can try to find some. Let mle see if I understand the issue correctly
<ttx> james_w: any reason why the changes for qemu-kvm 0.11.0-0ubuntu5 are not appearing in lp:ubuntu/karmic/qemu-kvm ?
<james_w> let me look
<mvo> ttx: the fix should be pretty simple, just dropping the conflicts from qemu-kvm
<ttx> mvo: yes, I just saw the problematic diff. I'm on it.
<mvo> great, many thanks
<ttx> mvo: do you see any point in keeping the Provides and Replaces ?
<slangasek> ttx, mvo: I think you still need a versioned conflicts against the old version of kvm
<slangasek> there are numerous file overlaps between kvm 1:84+dfsg-0ubuntu11 and qemu-kvm 0.11.0-0ubuntu5
<slangasek> so probably Conflicts: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0)
<ttx> slangasek: ok, so a versioned Conflicts/Replaces... not sure the "Provides: kvm" makes any sense with transitional packages ?
<slangasek> ttx: I have no opinion on the Provides:, other than to note that changing it is not required in order to fix this bug
<ttx> ok.
<ttx> slangasek, mvo: I'm building a package to validate the following change: http://pastebin.ubuntu.com/296713/
<slangasek> ttx: are you sure the qemu conflict should be made conditional like that?
 * slangasek checks
<slangasek> ttx: yah, that's fine, there are no file conflicts between the current versions of the two packages; which probably means the versioned conflicts is a bit tighter than it needs to be, but not buggily so
<ttx> slangasek: ok
<ttx> I'll doublecheck with my package build in various scenarios.
<ttx> (whenever it finishes to build)
<ttx> slangasek, mvo: installs correctly but fails on upgrade scenario: http://pastebin.ubuntu.com/296732/
<ScottK> pitti: Thanks
<slangasek> ttx: strange, checking why that conflict didn't show up in my check of the Contents
<slangasek> ttx: has something changed that would cause /etc/qemu-ifup to be present in the qemu package?  Contents-i386.gz insists that this file is only found in qemu-kvm
<evand> mvo: In bug 439485, the Moblin CD doesn't have a Packages or Sources file, as it doesn't use extra packages.  This causes apt to say it's not a valid CD, and in turn pops up a warning in apt-setup/ubiquity.
<evand> mvo: The CD does however include a Release.gpg file.  So do you think apt not considering this sufficient a bug in apt, or should it continue to treat a CD without packages invalid?  I have a patch if you think it's the former.
<ubottu> Launchpad bug 439485 in ubiquity "APT error during installer" [High,Triaged] https://launchpad.net/bugs/439485
<slangasek> ttx: the archive confirms - how do you have /etc/qemu-ifup in a current qemu package?
<davmor2> pitti: Bug 450491 I just had it crash on me again is there any info you'd like me to add to the bug before I reboot the system?
<ubottu> Bug 450491 on http://launchpad.net/bugs/450491 is private
<pitti> davmor2: can you please just submit it again? perhaps your retrace will get better
<slangasek> oh gar, why am I now getting a 'low disk space' pop-up every 30 seconds? :P
<slangasek> I don't remember it doing that before
<pitti> hm, that should be a notification
<pitti> oh, perhaps it has an action
<slangasek> it does
<slangasek> my objection is that it's giving me the same notification repeatedly, instead of just giving it to me once at login
<slangasek> s/notification/pop-up/
<pitti> *nod* that sounds like a bug
<slangasek> and when I click 'ignore', it only ignores it for 30 seconds :P
<seb128> nothing which changed recently though
<slangasek> I suppose it's because my /home partition recently fell below whatever its threshold is
<seb128> I guess so
<slangasek> so every time it polls, it sees the partition has changed, so feels the need to ask me again
<slangasek> just in case the different freespace number changes my mind :P
<seb128> you can try to ping chrisccoulson when he's around
 * slangasek nods
<seb128> I think he had been looking at those issues
<slangasek> although, I'd rather he fix my crashing gnome-settings-daemon first :)
<davmor2> pitti: bug 455356
<ubottu> Bug 455356 on http://launchpad.net/bugs/455356 is private
<davmor2> that's the new one
<pitti> davmor2: thanks; needs retracing first
<davmor2> no probs
<mvo> evand: hm, can I see the patch that you have in mind please? I will now download the CD to see what it looks like, in general I think if the cd is not valid about should complain, but I need to see the moblin cd first to judge
<evand> mvo: http://pastebin.ubuntu.com/296733/ - sure thing
<ttx> slangasek: hm, that strange. That test was an update from a jaunty setup with kvm and qemu installed.
<chrisccoulson> slangasek - i hear you're getting repeated low-disk space notifications
<ttx> slangasek: I think the Provides plays tricks here
<slangasek> ttx: I don't think it's the Provides, no
<slangasek> ttx: jaunty qemu had that file; I think it's a dpkg bug in the handling of the Replaces
<slangasek> chrisccoulson: word travels fast ;)
<chrisccoulson> heh, it does indeed. you only get the notifications for internal volumes right?
<slangasek> chrisccoulson: AFAIK yes
<chrisccoulson> that's ok then. how much space is on the volume at the moment?
<chrisccoulson> the expected behaviour is that you will get the first notification when the free space drops to 5%, and you shouldn't get anymore notifications unless the free space drops a further 1%. in this case, they should not appear more frequently than every 10 minutes anyway
<chrisccoulson> and you should never get a notification for a volume that has more than 2GB free space either
<slangasek> chrisccoulson: 96% used; I've seen at least 4 of the notifications since my most recent login
<chrisccoulson> does the volume stay mounted the whole time, or do you ever unmount it at all?
<ttx> slangasek: yes, it keeps /etc/qemu-ifup in the dummy qemu filelist on upgrade
<slangasek> chrisccoulson: it's /home ;P
<slangasek> ttx: right - so I think we just need an unversioned Replaces: qemu
<ttx> slangasek: you read my mind
 * ttx is happy to have tested in various scenarios, now :)
<chrisccoulson> slangasek - i might need to give you a build of g-s-d later with some g_debug's in it so i can figure out what's going on
<TheMuso> jono: Yes, I have seen it. It was a result of myself and dtchen telling Lennart about where thigns stand re pulseaudio in karmic.
<jono> TheMuso, what can we do to help repair relations with Lennart?
<TheMuso> jono: I am not sure at this point, I need to sleep on it. I am still mentally scrambled after sed conversation, and need to sleep on it, and approach the solution with a clear mind.
<jono> TheMuso, sounds like a good idea
<jono> let me know if I can help
<TheMuso> jono: Ok thanks.
<jono> np :)
<Keybuk> pitti: about?
<pitti> hey Keybuk
<Keybuk> pitti: so, this INPUTCHAR usplash thing
 * Keybuk *cannot* get it to work
<pitti> Keybuk: you mean it doesn't work any more now?
<pitti> Keybuk: I didn't use it recently; maybe it got broken during all those console handling changes
<pitti> want me to write a test script?
<Keybuk> script isn't helpful ;)
<Keybuk> in C, I keep getting the open() call blocked
<pitti> ok, I'll first test it with a script to check if the usplash backend stuff is still working, and then try in C
<Keybuk> pitti: am I right in thinking that you have to continually send INPUTCHAR to usplash?
<Keybuk> and that after sending you have to open the outfifo, read (which will block for up to a second) ?
<pitti> Keybuk: the current implementation behaves that way, yes; I didn't want INPUTCHAR to block
<pitti> otherwise it'd be utterly hard to write shell scripts that use it
<Keybuk> ok, so at least my understanding is right
<pitti> Keybuk: (see man usplash_write)
<Keybuk> right, and the code
<Keybuk> it just doesn't tend to work :)
<pitti> ioctl(TIOCSCTTY): Operation not permitted
<pitti> oha
<Keybuk> yeah I see that one from time to time too
<pitti> Keybuk: confirmed, it blocks here and doesn't work
<pitti> Keybuk: http://people.canonical.com/~pitti/tmp/test-input.sh
<Keybuk> I don't think that code path has changed though?
<pitti> no, not since jaunty
<pitti> but terminal handling did
<Keybuk> which console did it output that ioctl error to?
<pitti> Keybuk: gnome-terminal (from where I started the sript)
<Keybuk> weird, it implies either
<Keybuk> ah
<Keybuk> no
<Keybuk> you need --background on that usplash call if you do that
<Keybuk> otherwise it's not a session leader?
 * cjwatson wishes packages would either use the autotools, or not use the autotools, not somewhere in between
<Keybuk> so try usplash -c -v --background
<cjwatson> attr, I'm looking at you
<pitti> Keybuk: --background? Should't -c do that?
<Keybuk> pitti: no -c is VT flip
<pitti> Keybuk: ah, seems --background isn't in the manpage
<Keybuk> pitti: -> cjwatson ;)
<cjwatson> oops
<pitti> instead of & then, I guess
<cjwatson> --background is to make it less racy
<cjwatson> so the terminal setup and fifo opening is synchronous, and *then* it backgrounds
<pitti> doesn't help to fix INPUT, though
<Keybuk> weird, your script works for me ;)
<Keybuk> cjwatson: though there's another race now which I have a fix for
<Keybuk> cjwatson: (mask SIGTERM out until after the init is finished :p)
<pitti> Keybuk: I updated the script to test "INPUT" as well (with a full line); hangs as well, though
<Keybuk> that's odd
<cjwatson> Keybuk,pitti: http://paste.ubuntu.com/296791/ was aimed at something else but may help here
<Keybuk> does it hang or does it timeout?
<cjwatson> esp. the tcsetattr crud
<Keybuk> cjwatson: the termios stuff is probably useful
<Keybuk> but the other bit is actually badly wrong
<Keybuk> it'd mean if you pressed escape at exactly the wrong ms, usplash would disappear but not fsck
<Keybuk> in fact, most input characters would get eaten by that code, rather than the INPUT checking code
<cjwatson> hm, ok
<cjwatson> well, I hadn't committed it yet because I hadn't got it all working :)
<cjwatson> although I'm not entirely sure I agree with your analysis
<cjwatson> INPUT sends usplash into a totally different loop
<cjwatson> I think you may be incorrectly assuming a sane main loop design? :)
<Keybuk> I'm thinking of INPUTCHAR here
<pitti> Keybuk: times out
<Keybuk> which is what we use to grab Escape
<Keybuk> pitti: that implies not locking then, just not seeing input
<Keybuk> cjwatson: INPUTCHAR is "check for escape", return to main loop
<Keybuk> so you then end up with two bits of code reading from stdin
<Keybuk> depending which one gets it, you get different behaviour
<cjwatson> this is true
<cjwatson> anyway, I meant you to try out the termios hackery and see if that helps
<Keybuk> that being said, it might be cute to replace INPUTCHAR with something else
 * pitti tries termios bits
<Keybuk> ESCAPE %d
<Keybuk> (when escape is pressed, send SIGHUP to %d)
<Keybuk> you could patch that into your code then :p
<mvo> evand: I followed up on #439485, I wonder if we can just make ubiquity ignore the error from cdrom.Add() ?
<ogra> pitti, fyi, pulsating usplash works fine on my armel images
<mvo> evand: maybe conditional on moblin
<pitti> ogra: thanks
<Keybuk> cjwatson: I don't think the termios fixes my problem though - because mine is that open() locks
<pitti> doesn't work, no
<pitti> still no input
<Keybuk> pitti: are you using the bogl or svgalib backends?
<pitti> Keybuk: bogl (with KMS)
 * Keybuk wonders whether that makes a difference
<pitti> Keybuk: I try it in kvm now (which uses svgalib)
<Keybuk> err
<Keybuk> W.T.F
<Keybuk> warcraft scott% md5sum karmic-moblin-remix-i386.iso
<Keybuk> 91e4f415767a45617f0cbfc5b0abd19c  karmic-moblin-remix-i386.iso
<Keybuk> warcraft scott% md5sum karmic-moblin-remix-i386.iso
<Keybuk> 26c3177ae594a3713b0e318e12e91e1b  karmic-moblin-remix-i386.iso
<Keybuk> the md5sum changed over time
<pitti> ext4?
<Keybuk> yes
<Keybuk> ext4 is scaring me
<slangasek> Keybuk: could you have a look at bug #453579, and see whether the mount-fiddling bits suggested there have any effect on your ext4 problems?
<ubottu> Launchpad bug 453579 in linux "corruption of large files reported with linux 2.6.31-14.46 on ext4" [Critical,Triaged] https://launchpad.net/bugs/453579
<Keybuk> slangasek: which mount-fiddling bits?
<slangasek> Keybuk: auto_da_alloc=0
<slangasek> Keybuk: is this ext4 on top of LVM or dm-crypt?
<Keybuk> no
<Keybuk> ext4 on top of hardware
<sladen> ogra: so how come you have pulsations and we poor x86 users don't?
<slangasek> Keybuk: ok
<sladen> Keybuk: I tried the scheduer=deadline and it made no difference
<pitti> Keybuk: test-input.sh doesn't work for me in KVM either, hmm
<slangasek> Keybuk: sorry, I guess auto_da_alloc=0 is a boot-time module option rather than a mount option
<pitti> sladen: pulsation> should be fixed since last Friday or so?
<ogra> sladen, heh, no idea, get arm HW then :)
<Keybuk> slangasek: isn't that the one about rename() and stuff?
<Keybuk> I'm seeing md5sums being wrong on single files
<Keybuk> and worse, md5sums *changing* on single files
<Keybuk> assumedly the change was when that file left the page cache
<slangasek> Keybuk: I don't know, I'm just trying to figure out if this links to any of the existing open upstream bug reports
<sladen> pitti: I see no pulsatations on boot.  If I should be seeing them, what is poking usplash to PULSATE?
<pitti> sladen: only on live system boot, not on installed one
<pitti> sladen: casper does
<sladen> pitti: is the /lack/ of that POKE/PULSATE also the reason that usplash vanishes back to text-mode after 20 seconds
<Keybuk> no
<pitti> slangasek: that's just the normal timeout
<pitti> (30 secs)
<pitti> or something is stopping usplash prematurely, of course
<pitti> which seems to happen for cryptsetup
<pitti> I regularly see the "Starting crypto disks" init message in a VT
<Keybuk> slangasek: I'm still not honestly 100% sure this isn't a hardware issue, since I seem to be able to replicate it more than most
<sladen> usplash is running for 20 seconds (by the stopwatch) and 23 seconds by the bootchart
<Keybuk> slangasek: the only thing that makes me think it isn't (and which is why I've mentioned it) is that mvo has reported users with the exact same problems
<Keybuk> (large debs being corrupted)
<Keybuk> I would assume that if there's definitely a filesystem bug here, people on true ext4 will see it quickly now they'll be downloading isos
<slangasek> Keybuk: I think it would be helpful if you would apport-collect your kernel information onto that bug from the affected system, so we at least have a point of reference for collating any other reports that come in
<tseliot> can anyone recommend me a package which updates the initramfs (maybe after adding a module) in a sane way in its packaging scripts, please?
<Keybuk> will do
 * tseliot is looking for an example
<Keybuk> tseliot: that's done by triggers
<pitti> case "$1" in
<pitti>     configure)
<pitti>         if [ -x /usr/sbin/update-initramfs ]; then
<pitti>                 update-initramfs -u
<pitti>         fi
<pitti> tseliot: ^ doesn't that do?
<tseliot> yes, it does
<tseliot> I was wondering what's the best practice to add new modules
<pitti> (it also wraps dpkg triggering correctly)
<sladen> tseliot: sudo update-initramfs ...
<tseliot> is it ok to add the module to /etc/initramfs-tools/modules
<tseliot> ?
<Keybuk> tseliot: no
<Keybuk> tseliot: use manual_add_modules in your initramfs hook
<tseliot> Keybuk: that's exactly what I was looking for
<tseliot> thanks everyone
<Keybuk> tseliot: the framebuffer hook is a great example
<tseliot> Keybuk: is it /usr/share/initramfs-tools/hooks/framebuffer ?
<Keybuk> yes
<tseliot> ok, thanks again :-)
<Keybuk> err, apport-collect crashed
<Keybuk> AssertionError: Need to have either "project" or "distro" option
<slangasek> apport-collect -p linux 453579 ?
<pitti> Keybuk: this should be fixed in 1.9.3-0ubuntu2
<Keybuk> ok
<Keybuk> slangasek: tried that ;)
<Keybuk> so, I guess first question worth trying
<Keybuk> anyone here on ext4? (installed fresh, not "upgraded" from ext3?)
<ScottK> Keybuk: Yes
<Keybuk> ScottK: if you wget an iso, md5sum it, sync and force a page cache flush, then md5sum it again
<Keybuk> do you get the same md5sums?
<ScottK> Keybuk: I'll check.  How do I sync and force a page cache flush?
<Keybuk> (as root)
<Keybuk> sync
<Keybuk> echo 3 > /proc/sys/vm/drop_caches
<ScottK> OK.  Just started downloading, so it'll be a bit.
 * Laney too
<Keybuk> pitti: I may, in fact, be a moron
<Keybuk> (on the usplash thing)
<Keybuk> I just looked at my code, and err, removed the close() syscall from before me reading from the descriptor
<mvo> Keybuk: could you please have a quick look over https://bugs.edge.launchpad.net/ubuntu/+bug/452090/comments/8 ? just want to be sure that sysvinit-utils is fine without the hard depends (AFAICS the recommends should be more appropriate)
<ubottu> Launchpad bug 452090 in apt "adept fails to upgrade from hardy -> karmic" [High,Confirmed]
<ion> keybuk: When i gdbâd a mountall crash last night, âif (stdin_io) nih_free (stdin_io);â lead into nih_assert (ctx->destructor != NIH_ALLOC_FINALISED) aborting. I canât figure out how that could happen from the code, though. :-\
<mvo> hm, rescue mode in karmic runs with quite a bunch of daemons enabled (like NM), jaunty did not. a bug or a design decision?
<pitti> doko__: bug 454621  says that they are for lucid; do we need them in main for karmic as well?
<ubottu> Launchpad bug 454621 in maven-repo-helper "MIR for maven-ant-helper and maven-repo-helper" [Undecided,New] https://launchpad.net/bugs/454621
<doko__> pitti: yes, packages b-d on it are now uploaded
<Keybuk> nope, that wasn't it either
<mvo> Keybuk: single user mode (e.g. grub rescue mode) in karmic runs with quite a bunch of daemons enabled (like NM, rsyslog), jaunty did not. is that a bug or a design decision?
<Keybuk> mvo: vague design decision
<Keybuk> mvo: single user mode is rather wishy washy
<mvo> Keybuk: could we document it somewhere (or return to the traditional behavior) please? maybe in the release notes
<Keybuk> depending on your POV, either too much is running or not enough is running
<Keybuk> there is no traditional behaviour here
<mvo> in my POV too much is running
<mvo> well, I used to be able to "mount -o remount,ro /" in single user mode, that was quite handy in some situations
<Keybuk> no you didn't
<Keybuk> that's not worked in many releases
<Keybuk> (unless by luck)
<jdong> heh Jaunty even started up a lot of things for that to work
<jdong> if I wanted ro I usually just init=/bin/bash
<Keybuk> mvo: that kind of thing hasn't really worked since udev came along
<Keybuk> I think we do need a proper recovery shell though
<mvo> it used to work for me most of the time, I don't mind that much that it changed, it would just be nice to document it in the release notes
<mvo> recovery shell++
<Keybuk> but that it should be done properly, not abusing "single user mode"
<Keybuk> in the sysv docs, the only difference between single user mode and multi user mode is the presence of login daemons/services ;)
<mvo> dholbach had a incident where dpkg crashed during replacing his libc and that was a pita to recover (on a vserver miles away)
<Keybuk> ie. switching from 2 to S/1 means killing X, getty and sshd
<Keybuk> a proper recovery shell shouldn't even be running things like udev, and instead should offer a step-by-step process to check and mount filesystems, etc.
<Keybuk> a bit more like windows F8 perhaps
<mterry> Where could I see a list of packages I've sponsored?  (i.e. I signed it, but it wasn't my changelog)
<mvo> friendly-recovery tries to cover a lot of this
<Keybuk> mvo: friendly-recovery requires /usr to be mounted ;)
<Keybuk> that's "too late" in recovery mode terms
 * mvo adds it to the lucid specs
<Keybuk> since then you need udev, probably mdadm or lvm, network-manager if it's on NFS, etc.
<pitti> zul: rabbitmq-server's init script isn't set -e?
<Keybuk> pitti: apparently Debian initscripts skeleton now says "NEVER USE -e"
<pitti> zu_: since you added the pkill without "|| failure-handling-code"
<pitti> oh
<Keybuk> pitti: I've seen people now filing bugs to remove -e from init scripts
 * pitti â¥ -e
<zul> pitti: no it isnt
<pitti> zul: thanks
<Keybuk> pitti: indeed, this is why Upstart forces it <g>
<pitti> excellent
<Keybuk> mvo: for me, the biggest bug with friendly recovery is that you can't get there if a filesystem check fails
<Keybuk> which is, err, precisely when you want it :p
<iulian> mterry: I'm not sure if such a list even exists.
<Keybuk> mvo: you really want *any* boot failure to automatically bring friendly recovery up
<mterry> iulian: hmm, I feared as much.  would be nice
<Keybuk> without requiring a special grub prompt
 * mterry will have to keep track
<Keybuk> and instead maybe use the grub prompt for an actual true safe mode (most services missing, safe drivers only, etc.)
<ion> keybuk: A mountall crash from current ~ubuntu-core-dev code â although not the one i described earlier, still trying to reproduce it while logging â http://pastebin.com/f6f1e0cea
<ion> keybuk: Dunno whether the âBad file descriptorâ message in the log is relevant.
<mvo> Keybuk: agreed, there is bug #385882 open aobut this
<ubottu> Launchpad bug 385882 in sysvinit "if fsck exits with error code 4 no way for non-experts to recover" [Undecided,New] https://launchpad.net/bugs/385882
<Keybuk> ion: valgrind would probably help with that one
<Keybuk> mvo: I think this is more spec work than bug work
<mvo> Keybuk: you mean its less work to just fix it than to write a spec for it?
<Keybuk> mvo: no, it's a lot of work to fix it properly, so we should design and spec it, rather than treat it as a simple bug fix
<ion> keybuk: Huh. A new kind of crash this time, not the nih_free assertion failure. http://pastebin.com/fd7325
<ion> keybuk: Iâll test with valgrind.
<mvo> Keybuk: aha, sorry. misunderstood. ok, I made a tomboy note about it and will add it as a lucid spec
<Keybuk> slangasek: apport collected my personal information and passwords, and put it in the bug for you ;)
<ion> :-D
<ion> The laptopâs fan is running like crazy with valgrind running in a VM. :-)
 * Keybuk hates usplash
<Keybuk> it's a buggy piece of shit
<pitti> +1
<pitti> and we kept bolting on hack over hack over time
<davmor2> Keybuk: when does xsplash replace it completely?
<Keybuk> davmor2: never
<davmor2> Nooooooooo
<sebner> Keybuk: then replace it with plymouth :P
<Keybuk> sebner: every time it's suggested, somebody points out that Plymouth is KMS only
<ion> keybuk: Ah, this seems to be the problem: nih_main_loop â nih_io_handle_fds â nih_io_watcher â nih_io_closed frees the io, then mountallâs progress_timer still does stuff with it.
<liw> . o O (how hard can it be to rewrite usplash from scratch, cleanly...)
<Keybuk> liw: that's what Plymouth is, arguably
<jdong> would it really hurt to just not splash at all before xsplash?
<ion> keybuk: http://pastebin.com/f499c1409
<Keybuk> ion: oh, double-free?
<Keybuk> ion: that's not the fsck_reader bug though, right?
<ion> keybuk: In this case, both mountall.c:3377 stdin_io->data = ... and mountall.c:3363 nih_free (stdin_io) happened after nih_io_closed had freed the object.
<ion> keybuk: Yeah, there seem to be two bugs which appear randomly. Iâll try to get a valgrind report for that one, too.
<cjwatson> jdong: that's what we tried in karmic, and everyone screamed
<jdong> cjwatson: heh. Seems like a lot of man-hours spent on a logo screen that shows up for 5-10s
<cjwatson> jdong: tell me about it
<Keybuk> jdong: then you get people like sladen spending ages screaming and whining that the logo shows up for MINUTES and DOES NOT PULSATE!
<tgpraveen> cjwatson: if the waiting time till xsplash is really small like say in karmic+1, then usplash won't be needed
<tgpraveen> right?
<cjwatson> tgpraveen: that was the theory in karmic
<jdong> Keybuk: it's supposed to pulsate?
<jdong> hahaha kidding!
<tgpraveen> yeah. and in karmic it didn't become possible. but is that the plan for lucid?
<Keybuk> trouble is, I'm spending my time tracking down why our piece of shit splash screen code keeps blocking on a fifo instead of figuring out why the boot is slow for some people
<jdong> I'd have to say the latter is more important than showing an early splash screen in the first place.
<Riddell> pitti: what's all this about X-Ubuntu-Gettext-Domain getting changed to X-GNOME-Gettext-Domain ?
<jdong> </captain obvious>
 * tgpraveen sees many forum posts with slow boot times
<Keybuk> jdong: I would agree, but I was overruled
<pitti> Riddell: the glib patch was sent to upstream, and SUSE is using it as well; our cdbs continues to use X-Ubuntu-
<Keybuk> and so now I spend my time debugging the splash screen instead
<jdong> Keybuk: :( shame... My sympathies
<pitti> Riddell: (glib looks for both now)
<Riddell> pitti: sakes, there's more in this world than glib
<pitti> Riddell: sure, but what's wrong with changing it in packages which use glib?
<Riddell> pitti: because those files are read by apps which don't use glib
<Laney> Keybuk: (I tried the md5sum thing and they were both the same, if nobody else got back to you)
<pitti> Riddell: ok; so does it need to be reverted for some packages?
<sebner> Riddell: don't forget your lovely k3b :-P
<Riddell> pitti: if there are packages in our archive which use this then they either need to be reverted to use X-Ubuntu or I need to update the kdelibs patch to look for X-GNOME
<Riddell> pitti: but who picked X-GNOME, could nobody think of a desktop agnostic term to use?
<pitti> Riddell: as I said, cdbs langpack.mk uses X-Ubuntu- for that
<pitti> Riddell: FWIW, we should just have "Gettext-Domain:" and the fdo spec guys should just accept it into the spec..
<pitti> it's X-<projectname>-<fieldname>
<Riddell> who are these mysterious fdo spec guys?
<Riddell> neither of the KDE guys listed at http://standards.freedesktop.org/desktop-entry-spec/latest/ are active
<Riddell> pitti: so does anything in Ubuntu use X-GNOME in karmic.  will it in lucid?
<pitti> Riddell: http://lists.freedesktop.org/archives/xdg/2005-June/005344.html was the original discussion
<pitti> Riddell: I don't plan to flip the cdbs default anytime soon
<pitti> s/anytime soon/until this gets resolved at fd.o/
<pitti> Riddell, slangasek, james_w: any of you doing syncs? there are unflushed packages in syncs/
<james_w> pitti: I was just flushing as you asked
<Riddell> not I
<james_w> should be clean now
<james_w> sbeattie: are you asking for removal in bug 414866? I can't see a clear action there.
<ubottu> Launchpad bug 414866 in pygpu "python-pygpu depends on non-existent python-cg" [Medium,Triaged] https://launchpad.net/bugs/414866
<Riddell> pitti: there seems to be one person involved in that discussion and he doesn't have his name on the spec. has upstream glib accepted the patch?
<pitti> Riddell: upstream glib> no, not yet
<pitti> james_w: thanks
<Riddell> pitti: so no packages have X-GNOME added by our packaging but does anything from upstream use it yet?
<pitti> Riddell: it's just used in SUSE and Ubuntu so far, I never saw it upstream
<pitti> and our patches for non-cdbs packages are ancient and all use X-GNOME as well
<pitti> I can't guarantee that _nothing_ is using it, obviously, that'd require a thorough archive grep
<Riddell> pitti: you mean they use X-Ubuntu?
<pitti> oops, sorry, yes
<Riddell> pitti: so I'll change https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Desktop%20Entries back to say X-Ubuntu, I'll also investigate what this means for KDE on suse (if they patch it of if they have no gnome .desktop translations) and what that means for KDE upstream
<pitti> ok, sounds fine
<pitti> let's keep X-Ubuntu- everywhere for now then
 * Keybuk is confused
<Keybuk> we have bcmwl-kernel-source on the USB key under pool/
<Keybuk> but not its dependencies?
<ion> keybuk: âNormally this just calls the close handler, or if not available, it closes the file descriptor and frees the structure (which may be surprising if you were hanging on to a pointer of it).â âthe documentation for nih_io_closed. Yeah, we got surprised by it. :-)
<Keybuk> ion: not really, just forgot I needed a close handler to clear the global pointer
<lool> cjwatson: I'm looking at why moblin remix has no Packages file; I started reading from the "ship-live" task handling and found that moblin has no "ship-live" seed; I plan adding an empty ship-live seed to not break debian-cd tasks #includes, but are there other required per-project seeds?
<lool> Do I want to create ship/blacklist/others as well?
<cjwatson> not unless you need the objects generated from them
<Riddell> pitti: do you have a reference for the glib patch being submitted upstream?
<Riddell> (for that docs page)
<tkamppeter> pitti, hi
<lool> cjwatson: Ok so I'm just adding an empty ship + ship-live http://paste.ubuntu.com/296916/
<cjwatson> sounds harmless
<Riddell> sebner: yo
<Riddell> sebner: k3b is in my PPA (~jr) I'm having trouble finding anyone to test it
<Riddell> sebner: so if you are able to test it that would be lovely
<sebner> Riddell: do you really want to dirty my lovely gnome with k3b? :P Sure I can install and start and play a little bit with it but currently no CD-R around
<Riddell> sebner: yes please, if you have a CD writer the main test I want is that it doesn't complain about a missing CD writer at startup
<sebner> Riddell: aye aye Sir!
<LaserJock> cjwatson: any news on bug #452429 and https://code.launchpad.net/~laserjock/debian-cd/edubuntu/+merge/13442
<ubottu> Launchpad bug 452429 in ubiquity "ubiquity and other packages are not removed after Edubuntu install" [Undecided,New] https://launchpad.net/bugs/452429
<pitti> Riddell: https://bugzilla.gnome.org/show_bug.cgi?id=569829
<ubottu> Gnome bug 569829 in general "Please support calling gettext() at runtime instead of shipping static translations" [Enhancement,Unconfirmed]
<tkamppeter> pitti, can you have a look at bug 437997? It is collecting a lot of duplicates and I have a 1-line fix for it.
<ubottu> Launchpad bug 437997 in system-config-printer "Freeze exception: system-config-printer.py crashed with UnicodeDecodeError in sub()" [Critical,In progress] https://launchpad.net/bugs/437997
<cjwatson> LaserJock: sorry, running behind ... so does nothing install the Edubuntu classroom server by default any more? I don't mind, would just like to double-check that
<cjwatson> public service announcements: bugs with tarballs attached are more hassle than bugs with individual files attached
<pitti> tkamppeter: please just upload
<cjwatson> LaserJock: 452429 is perplexing
<sebner> Riddell: I hope the other stuff which gets pulled in automatically doesn't hurt anything
<ArneGoetje> Hi, can someone please sponsor https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org-dictionaries/+bug/409813 for me? Thanks a lot!
<ubottu> Launchpad bug 409813 in openoffice.org-dictionaries "hunspell-hu, hunspell-vi and probably others hunspell-* conflict with thunderbird (unversioned)" [Undecided,Fix committed]
<cjwatson> ooh, hang on, busted manifest-desktop
<tkamppeter> pitti, already uploaded, bug updated.
<pollex> hi
<ScottK> Keybuk: md5sum didn't change for me, but it'd been sitting there done for a while before I checked the md5sum.  Dunno if it might not have already sync'ed on it's own
<Laney> I tried it and it hadn't written out
<LaserJock> cjwatson: well, I'm expecting a classroom server to be "Hit F4 and select LTSP and then edubuntu-desktop when the task selector comes up"
<LaserJock> cjwatson: but we don't have a distinct task for the classroom server
<cjwatson> isn't it edubuntu-server?
<LaserJock> no
<cjwatson> Task-Extended-Description: This task provides the Edubuntu classroom server.
<LaserJock> ah, well
<cjwatson> one of you guys might like to fix the seed headers then ;-)
<LaserJock> it's a tad complicated
<cjwatson> I've merged your branch, thanks
<LaserJock> edubuntu-server installs things like moodle
<LaserJock> and in the future hopefully other non-LTSP server bits
<LaserJock> but we used to call LTSP the "classroom server"
<LaserJock> so yeah, a bit confusing
<LaserJock> we've had such problems with moodle that I dropped edubuntu-server off the DVD for Karmic
<zul> asac: around?
<LaserJock> cjwatson: thanks
<asac> zul: yes.
<asac> zul: but a call in a few
<zul> asac: do you want to discuss augeas when you are off your call?
<asac> zul: yes. will be there for you
<zul> asac: thanks
<Whoopie> asac: Hi, I try to find out why NM uses /dev/ttyUSB0 instead of /dev/ttyUSB2 of my Sierra MC8775 3G card. Could you give me some hints where to start?
<Whoopie> asac: https://bugzilla.gnome.org/show_bug.cgi?id=598939
<ubottu> Gnome bug 598939 in ModemManager "ModemManager chooses wrong ttyUSB interface for Sierra MC8775" [Normal,Unconfirmed]
<ion> keybuk: A quick fix at https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/segfault-fix, but i havenât managed to track down the mnt != NULL issue yet.
<Keybuk> ion: 404
<Keybuk> oh, s/,$//
<Keybuk> ion: hah, obvious really
<ion> There should be a way to say âgdb *that*, and also valgrind itâ after you see an arbitrary crash on your screen. :-P
<Keybuk> ion: that's what core files are for
<sebner> Riddell: looks good to me. Thumbs up
<Riddell> sebner: it doesn't complain about missing CD writer?
<sebner> Riddell: nope, k3b shows me the (empty) writer above the directories. Played a little bit with preferences etc etc. Everything works fine. I need a mp3 plugin though
<Riddell> sebner: great, thanks
<doko__> ubuntu-archive: please process liboro-java in binary NEW (documentation package)
<smoser> slangasek, let me know when you want to chat about uec build output
<ion> keybuk: Meh, i donât seem to be able to reproduce that error.
<Keybuk> huh
<Keybuk> why does hdparm call sync?
<Keybuk> huh
<Keybuk> cjwatson: today's live image seems a little broken
<cjwatson> Keybuk: -v? worked for me
<cjwatson> (dinner)
<Keybuk> cjwatson: 19.2
<Keybuk> all icons missing, N-M didn't load, u6y not on desktop, etc.
<Qwell> So, hrm.  You guys froze the Asterisk package at an rc version?
<Qwell> That seems...err...  like a bad idea.  At best.
<Qwell> 10 days..  is there still time for an exception to be started/acted on?
<zul> can someone reject the php upload it shouldnt have gone there
<mdz> bug 455619 has now happened to me on two different machines; is anyone else seeing it?
<ubottu> Launchpad bug 455619 in linux "grub-pc removed, update-grub fails" [Undecided,New] https://launchpad.net/bugs/455619
<MausP> Hello. Have a question regarding the function of the graphical tool that does the distribution update.
<MausP> does it only change the sources.list && apt-get update && apt-get dist-upgrade?
<MausP> or is it more?
<hyperair> it is more.
<hyperair> there are some tidying up stuff that the update-manager does that isn't done by dpkg/apt
<MausP> hyperair: can the tidying up stuff be done manually? my background:
<MausP> I set up a internal mirror in our company for our internal users (about 20, slowly increasing *g*)
<MausP> because our internet connection is quite slow I want that they use the internal mirror for update to karmic
<MausP> at the moment on the mirror there is only jaunty
<MausP> but when karmic will be final, then I want to add karmic to the mirror
<MausP> I think the graphical updater changes sources list to a official xy.archive.ubuntu.com mirror
<MausP> and that is what I don't want because it  f*cks up our slow internet connection :-(
<johanbr> MausP, make your DNS give your internal mirror IP for xy.archive.ubuntu.com
<johanbr> or set up a caching proxy
<hyperair> MausP: change your /etc/hosts.
<hyperair> MausP: i've had this issue before.
<hyperair> MausP: i think there was some bug about it, to allow sysadmins to add their mirrors to the list of "ubuntu" mirrors.
<hyperair> MausP: what you can do is you can add your mirror to /usr/share/python-apt/templates/Ubuntu.mirrors
<Qwell> Any MOTU devs willing to hold my hand/walk me through trying to get an exception for a package?  The freeze exception process on the wiki isn't too helpful for this case, I don't think
<Qwell> They all suggest filing a bug with the changelog of an updated version and/or diff.  Neither apply in this case.
<hyperair> what case would this be?
<Qwell> The Asterisk package.  Karmic should not ship with 1.6.0-rc2.
<Qwell> err, 1.6.2.0-rc2
<hyperair> and instead ship with ...?
<Qwell> something released...
<Qwell> Latest 1.6.1.x would be appropriate.
<bostongeek24> hi
<davmor2> Qwell: I think the idea is that it gets tested now so it is fit for the lts next release.  It's been done deliberately
<bostongeek24> im new to the linux community
<davmor2> Qwell: have a chat on #ubuntu-server
<bostongeek24> im also just learning to program
<bostongeek24> i want to develop for ubuntu
<bostongeek24> what language is used to develop for ubuntu/debian?
<Qwell> davmor2: I'm confused about why that channel would be relevant
<bostongeek24> can people see what im saying?
<davmor2> Qwell: Asterisk is a Voip service and therefore server the package has mostly been handles by them and Daviey in particular
<bostongeek24> hello?
<davmor2> bostongeek24: yes
<bostongeek24> what language is used to develop for ubuntu/debian?
<Qwell> davmor2: I'm familiar with what Asterisk is. :)  This would be a MOTU issue though, wouldn't it?
<bostongeek24>  im currently learning python
<Qwell> bostongeek24: Your question is highly flawed.  Ubuntu is a basically a large collection of software.  There are many different languages involved.
<Qwell> bostongeek24: If there is some specific application (or set of applications) you're interested in, that may be a better start.
<bostongeek24> @Qwell not really
<davmor2> Qwell: Like I say Daviey is your man and the server team were dealing with it so there decision etc that's why I say ask there.  They are more likely to know :)
<bostongeek24> is there a place that lists all of the software in ubuntu and what language it uses?
<bostongeek24> like if i saw a list then i might see something i would like to develop for
<bostongeek24> ??
<bostongeek24> hello??
<Pici> bostongeek24: I don't know of a list that exists like that.  I'd look at package dependencies (and build-dependencies) to see what languages they are written in.
<bostongeek24> how do i do that?
<Pici> bostongeek24: apt-cache showsrc packagename.  You may also want to join #ubuntu-offtopic since #ubuntu-devel is more of a working channel
<[reed]> what's the channel where canonical's sysadmins hang out?
<[reed]> need to report an issue
<Pici> [reed]: Actually, theres #canonical-sysadmin
<[reed]> thanks
<kees> slangasek: I just uploaded libselinux with a fix for a total regression in python-selinux (all python modules went away).  the binary deb python-selinux is unseeded and in universe, so I'll leave it up to you when to push it wrt the RC ISOs.
<lool> cjwatson: Hey, in debian-cd r829 you dropped empty Packages files from CD; was this to save space?
<lool> cjwatson: We have a bug on the moblin remix CD that an APT popup appears when the CD is not an usable source
<lool> cjwatson: evand suggested this might be an APT bug, but I'm not sure
<lool> It seems ok for APT to reject this CD
<lool> cjwatson: So I'd like to perhaps revert your change, or keep one Packages file
<lool> bug is LP #439485
<ubottu> Launchpad bug 439485 in ubiquity "APT error during installer" [High,Triaged] https://launchpad.net/bugs/439485
<doko__> ubuntu-archive: please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/maven2/+bug/454826/comments/2
<ubottu> Launchpad bug 454826 in maven2 "sync requests (unstable -> universe) to get maven built" [Undecided,New]
<chrisccoulson> slangasek - i've uploaded a build of g-s-d to my PPA which makes the housekeeping plugin more verbose. would you mind running it with "--debug --no-daemon" and capturing the output as the low disk space warning appears a few times? it should hopefully give me some idea why it's not working
<chrisccoulson> https://edge.launchpad.net/~chrisccoulson/+archive/ppa is my PPA
<smoser> soren, slangasek i've updated https://wiki.ubuntu.com/UEC/Images/Publishing to cover the state of ec2 build processing.
<soren> smoser: I don't understand this: "LABEL must be set to the "label" for this promotion. That would be one like 'beta1' or 'rc' or 'release'."
<soren> Perhaps it's just "promotion", that confuses me.
<soren> I've never seen that word used this way.
<doko__> ubuntu-archive: and I missed a main sync, libcommons-lang-java, now in bug #446263
<ubottu> Launchpad bug 446263 in liboro-java "sync request (unstable -> main) for getting maven built" [Undecided,Fix released] https://launchpad.net/bugs/446263
 * ccheney hates bugs
<ccheney> just write everything in ada ;-)
<ccheney> shtylman: can you take a look at 452518 and verify it is the correct fix?
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<dupondje> could somebody give me a hint where to start searching in the code to fix this ?
<dupondje> cause its so annoying :(
<slangasek> Keybuk: "NEVER USE -e" -- augh
<slangasek> Keybuk: passwords> hmm, clearly my timing was off, I meant to collect those from the bug before you had a chance to change them ;)
<dholbach> Keybuk: did you have any luck with the vserver guys?
<slangasek> mdz: 455619> can we get a dpkg / apt log to try to figure out why grub1 was installed in the first place?  (grub1 / grub2 are supposed to conflict, there was a window when they didn't, the question is why grub was pulled in at all here and whether we can do anything about that)
<slangasek> zul: php5 rejected as requested
<mathiaz> zul: slangasek: what's the plan for samba 3.4.2 - bug 447360?
<ubottu> Launchpad bug 447360 in samba "FFE for samba 3.4.2" [Undecided,New] https://launchpad.net/bugs/447360
<doko__> slangasek: do you agree with the fltk1.1 solution proposed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551612 ?
<ubottu> Debian bug 551612 in fltk1.1 "missing symbols when built with GCC-4.4, which were added for GCC-4.3" [Important,Open]
<cjwatson> lool: I think it was to deconfuse something in the installer; please don't revert the change, but feel free to make it conditional on moblin or something
<slangasek> doko__: why does he believe it's safe?  That's the entirety of the question
<slangasek> mathiaz: I don't have any plan yet, do you need me to review that quickly?  Or do you want to just upload and have us pick it up from the queue?
<mathiaz> slangasek: well - I was just triaging the New,Incomplete bugs
<mathiaz> slangasek: I'll take it up with zul then
<lool> cjwatson: ok; that's the temporary fix I had in mind, but I can as well call it final  :)
<doko__> slangasek: my workaround would be to reference the methods in some other unused code
<slangasek> doko__: does that mean you know that it's *not* safe?
 * ccheney found out there are more kde4 bugs in OOo, argh!
<doko__> slangasek: no, but it looks more like a fix in GCC, with 4.3 introducing these new symbols. if you look from 4.2 -> 4.4, there are no missing symbols
<slangasek> doko__: ok - that's more convincing to me than anything else I've heard so far... go ahead and trim the symbols, then
<asac> doko: bug 455647
<ubottu> Launchpad bug 455647 in libjaxp1.3-java "package libjaxp1.3-java 1.3.04-3ubuntu3 failed to install/upgrade: trying to overwrite '/usr/share/java/xml-apis.jar', which is also in package libxalan2-java 0:2.7.1-2ubuntu1" [High,Confirmed] https://launchpad.net/bugs/455647
<slangasek> zul: I'm not going to give a freeze exception for fixing up LSB init script headers that we don't use
<slangasek> asac: missed targeting to release? (done)
<asac> doing many things in parallel ;)
<asac> thx
<bluefoxicy> so here's an interesting sit for you.
<bluefoxicy> I just unplugged my ISP's wifi router (they control it, I walked over to it and disabled it)
<bluefoxicy> they have another one nearby I can reach.
<bluefoxicy> the one I unplugged is broken; when it's plugged in, I can't connect to the wifi, as it fails to negotiate properly.
<bluefoxicy> when they plug it back in, I'll be redirected to it, and instantly lose internet.
<bluefoxicy> why can't I select specifically which router to use, by MAC address?
<slangasek> doko__: buildds still on manual for maven?
<doko__> slangasek: no, not anymore
<slangasek> doko__: ok, cool
<doko__> asac: yes, known, fixed by libxalan2-java which should be in the archive by now
<ccheney> bluefoxicy: KDE probably would let you do that ;-)
<ccheney> bluefoxicy: or maybe using /etc/network/interfaces directly
<ccheney> bluefoxicy: hmm actually it seems NM can do it too, or at least lets you type a mac in
<ccheney> bluefoxicy: whether it actually do anything with it i don't know
<ccheney> bluefoxicy: go to edit connection information
<slangasek> doko__: how does the new libxalan2-java fix it?  that looks like a missing Conflicts/Replaces from libjaxp1.3-java
<slangasek> smoser: sorry, I was up all night to get the ball rolling on ISO smoketesting, and am just now catching up with things today; I'll dig into UEC publishing here shortly and ping you back if you're still around
<bluefoxicy> ccheney:  that's non-obvious ;)
 * bluefoxicy clicks Edit, and the app freezes.
<ccheney> bluefoxicy: heh, works for me :-\
<ccheney> well the edit part anyway, didn't test the mac part
<bluefoxicy> ccheney:  oh, I'd just like to see the menu pop out so you can select from the APs
<ccheney> bluefoxicy: needing to set a mac address isn't common though so wouldn't be the default to pop up and ask you it on connection
<ccheney> bluefoxicy: ah yea that would be nice too
<bluefoxicy> ccheney:  I mean like put an arrow next to the signal strength, if I click it it pops out a submenu "hey here's all the APs related"
<bluefoxicy> so I can force instead of let it autoneg.
<ccheney> yea, normally the one with the strongest signal is the best one to use.. except in your case ;-)
<bluefoxicy> btw I'm on Karmic
 * ccheney is still on jaunty, will be upgrading in a few days
<bluefoxicy> heh one day I really want a Gentoo-like apt repo
<slangasek> no, we definitely don't want to give people an easy button for hard-associating with a particular AP
<davmor2> bluefoxicy: just go into n-m and delete yours for the time being
<slangasek> people will click it and not understand why their wireless has stopped working when they've roamed out of range of that AP
<bluefoxicy> i.e. I don't want to see 16MB files to download just to update 3 packages
<jdong> heh around here, the way the wifi is laid out, it's kind of evil...
<bluefoxicy> slangasek:  oh, because our users are complete retards then and wifi is harder than the special olympics?
<ccheney> slangasek: well it could be made easier than having to use iwlist
<jdong> there are places with two AP's located on different subnets broadcasting the same ESSID
<jdong> so if your wifi driver chooses to roam between the two, that's death
<jdong> (naturally they are in the process of putting all of the wifi across campus on the same subnet *cringe*)
<bluefoxicy> slangasek:  were you the same guy that decided that if Ubuntu prints status messages during boot (Loading Hardware Drivers... OK, Checking File Systems... OK) that the users will be "shocked" and will immediately cry that the computer is broken?
<slangasek> bluefoxicy: that's inappropriate for this channel
<bluefoxicy> slangasek:  Is it?  I asked in this channel about the 'quiet' option, and someone actually argued that if Grub prints out something like "Loading kernel..." and a bunch of text for half a second, the users would actually become shocked and confused, and it would impair their ability to use the computer
<bluefoxicy> this was like 5 releases ago though
<slangasek> bluefoxicy: your earlier comment.
<bluefoxicy> slangasek:  well that's the impression I get from some of the developers.  If it's not mind-numbingly simple on a level that almost if not definitely breeds stupidity, it's assumed that the user will somehow screw it up in every case and must be kept away from any such thing at all costs.
<slangasek> I didn't say "in every case".  You're putting up a strawman
<bluefoxicy> the thing is I don't want the simplest things like "Associate with a different AP" or "what stage is your boot process stalling at" to come down to loading up a recovery CD on a command line and having a deep understanding of all the various configuration files on a Linux system
<bluefoxicy> <slangasek> people will click it and not understand why their wireless has stopped working when they've roamed out of range of that AP
<bluefoxicy> ^^^ this argument is only significant if that's the majority of user experiences, and people aren't smart enough to figure out why this happens
<cjwatson> 23:21 <bluefoxicy> slangasek:  oh, because our users are complete retards then and wifi is harder than the special olympics?
<cjwatson> that needs an apology
<bluefoxicy> <slangasek> no, we definitely <-- And apparently you definitely think this is the case
 * ccheney hopes his OOo mailbox doesn't fill back up by tomorrow, heh
<slangasek> seb128: how's the GNOME queue looking?
<ccheney> did the apport retrace service die?
<seb128> slangasek, quite well, not sure what you want to know exactly though
<slangasek> seb128: when it will be settled so that I can start RC rolls
<seb128> slangasek, ie there is a few sponsoring request waiting and a bunch of things not updated yet
<chrisccoulson> i'm just about to do gnome-terminal ;)
<bluefoxicy> read(4, 0x1239620, 2048)                = -1 EAGAIN (Resource temporarily unavailable)
<bluefoxicy> poll([{fd=4, events=POLLIN}], 1, 24996
<slangasek> seb128: so probably not ready for rolls until tomorrow morning?
<seb128> slangasek, I don't think there is lot of importants updates waiting, I would appreciate to still have tomorrow morning to sponsor robert_ancell's work from his day and review some things though
<seb128> so it's your call
<seb128> if we can wait tomorrow 10utc that's nice
<seb128> if you want to roll earlier we can stop with what we will have when I go to bed in one hour or so
<cjwatson> slangasek: ubiquity upload likely to be coming soon as well (tonight, I think), but I'm still holding out hope that I can figure out what's up with wubi
<bluefoxicy> open("/usr/share/themes/Default/gtk-2.0-key/gtkrc", O_RDONLY) = 4 ... apparently it's stalling on gtkrc read?  *headscratch*
<slangasek> seb128: I'll probably do some interim rebuilds just to be sure everything is still on track, probably waiting for cjwatson's uploads, then do the final desktop rolls tomorrow after 10
<seb128> slangasek, sounds good, thanks
<seb128> slangasek, btw you are welcome to give an hand or sponsoring if you want, there is a bunch of updates on http://people.canonical.com/~dholbach/sponsoring/index.html
<slangasek> seb128: it's unlikely that I'll have time, and then I have to worry besides about whether I should get other eyeballs on it in the queue :/
<seb128> ok, no problem
<seb128> in fact there is 2 items waiting right now so we should manage
#ubuntu-devel 2009-10-20
<kees> asac: when you get a moment, can you take a look at bug 455151 please?
<ubottu> Launchpad bug 455151 in network-manager-applet ""disconnect" wired network leaves IPv6 running, only disconnects IPv4" [Undecided,Confirmed] https://launchpad.net/bugs/455151
<slangasek> kirkland: did you build test this eucalyptus upload before uploading? (FTBFS, not sure if it's because of your change or the rash of maven syncs that's to blame)
<slangasek> kirkland: sigh - looks like it's the maven syncs that are to blame, yes
<afmaway> Hey guys, I would like to setup a secure/restrict apt repository and grant users access based on certificates
<afmaway> is that possible?
<kirkland> slangasek: ack
<kirkland> slangasek: i did locally build my change (as always)
<kirkland> slangasek: that went fine on my side
<slangasek> kirkland: <nod> - I'm beating up on libgoogle-collections-java now
<kirkland> slangasek: ttx warned me about a bunch of java changes that might hurt us
<slangasek> kirkland: do you understand java build systems better than I do?
<kirkland> slangasek: i absolutely do not
<slangasek> heh
<slangasek> kirkland: bug #455931 opened; I'm making only slow progress, it would be good to have someone who knows java looking at this
<ubottu> Launchpad bug 455931 in libgoogle-collections-java "google-collections update breaks eucalyptus build" [Undecided,New] https://launchpad.net/bugs/455931
<slangasek> s/java/ant/
<smoser> slangasek, i'm here if you're around.
<slangasek> smoser: sorry, gotten sucked into this eucalyptus build failure now, and have to break for dinner shortly :(
<smoser> fair. whenever you have a chance. i'm gonna be done for the night here, though.
<smoser> that link i pasted above is, i think, mostly done
 * slangasek nods
<smoser> the promote to release should be pretty easy
<smoser> i just tested this process myself today.
<lifeless> slangasek: hi
<smoser> but, slangasek, i still need some direction at least on doing HEADER stuff.
<lifeless> slangasek: google-collect.jar is the symlink that may be needed
<lifeless> /usr/share/java/google-collect.jar -> /usr/share/java/google-collections-0.8.jar
<slangasek> lifeless: I think I've found where in the eucalyptus build it references this, I think we should just update eucalyptus with the new path; test building now
<slangasek> lifeless: thanks for looking, though
<lifeless> it may be an upstream change unrelated to the maven2 transition
<lifeless> that said, java building on debian/ubuntu is fundamentally broken :(
<slangasek> lifeless: it's not a new upstream version of the package <sigh>
<lifeless> the packages represent ABI's, so the binary names should be versioned like they are for C/C++ libraries.
<lifeless> slangasek: ah, _fun_
<Caesar> slangasek: is Ubuntu considering switching to eglibc?
<DGMurdockIII> what with the pluse audo support in ubuntu
<TheMuso> DGMurdockIII: What about it?
<DGMurdockIII> why is so buggy in ubuntu
<lifeless> as opposed to in ???
<dotblank> If anything its more stable then it was before
<DGMurdockIII> fedora
<ScottK> Caesar: Already switched
<sladen> Caesar: Debian switched for us
<dotblank> Im tired of people complaining about pulse....
<dotblank> I like pulse
<dotblank> Makes my life actually easier
<pwnguin> dotblank: http://0pointer.de/blog/projects/pa-in-ubuntu.html
<sladen> dotblank: http://bugs.launchpad.net/ubuntu/+source/pulseaudio/+filebug
<DGMurdockIII> ii like it to if you get it working right but with my ati all in wonder hd it took my 8 hourd to get my sound to work over HDMI using the all in wonder card
<TheMuso> DGMurdockIII: how is it more buggy?
<dotblank> hmm I see
<dotblank> well it works for me
<bryce__> vorian, -vmmouse is missing from main - LP #69780, #407816.
<bryce__> er
<ubottu> Launchpad bug 69780 in xserver-xorg-input-vmmouse "Please promote xserver-xorg-input-vmmouse to main" [Wishlist,Fix released] https://launchpad.net/bugs/69780
<ubottu> Launchpad bug 407816 in xorg "vmmouse should be in main (reverted to universe in intrepid)" [High,Triaged] https://launchpad.net/bugs/407816
<bryce__> slangasek, -vmmouse is missing from main - LP #69780, #407816.
<pwnguin> probably the best linux audio strategy is to ask what laptops the distro developers own and buy them
<pwnguin> because everything always "works for me"
<dotblank> wow ok that is stupid why cant they use that patch?
<DGMurdockIII> ii like it to if you get it working right but with my ati all in wonder hd it took my 8 hourd to get my sound to work over HDMI using the all in wonder card
<bryce__> slangasek, I've got a commit sitting in xorg's git to add as an explicit dependency on xserver-xorg-input-vmmouse - should I upload this, or is something more needed?
<DGMurdockIII> i sold not have to go througt all that trouble it should work out of the box
<TheMuso> DGMurdockIII: What version of Fedora are you comparing it against?
<DGMurdockIII> fedora 11
<TheMuso> DGMurdockIII: and what version of Ubuntu are you trying to use?
<DGMurdockIII> ubuntu 9.04
<TheMuso> Right, well 9.10 has changed a lot, so I suspect your problem is fixed in 9.10.
<DGMurdockIII> ok
<pwnguin> really, to make any claim about this youd need to know how many bugs were fixed, and how many are still remaining. but its worth a shot
<pwnguin> esp since you know it's possible to make it work
<slangasek> Caesar: no, because Ubuntu is already switched to eglibc ;)
<slangasek> bryce__: which package gets the dep on -vmmouse, how much does it change our CD sizes?
<slangasek> bryce__: anyway, please upload and I'll have a look at it in the queue
<bryce__> slangasek, its uploaded, package is 'xorg'
<slangasek> ok
<YokoZar> slangasek: can I have 8kb of cd space to put a missing icon in app-install-data? pretty please :)
<YokoZar> actually it's probably way less than that compressed
<slangasek> really?  if it's way less than that compressed, sounds like you're using the wrong image format ;)
<slangasek> we can spare 8k on the CDs, yes
<slangasek> bryce__: new files in the debdiff, not documented in the changelog: debian/local/Xsession.d/60x11-common_localhost, debian/local/dexconf.patch ?
<directhex> um... is it me, or is karmic unhappy about the idea of changing timezone?
<directhex> /etc/timezone seems unchanged by what i poke in system/administration/time and date - and it resets my changes to london time
<slangasek> works if I change it via gnome panel
<slangasek> bryce__: welp, the extra changes in the debdiff don't seem to imply any changes to the actual binary packages, unless they cause a build failure... so accepted, and hopefully it won't cause a build failure
<bryce__> slangasek, hmm
<slangasek> and -vmmouse promoted back
<bryce__> thanks
<bryce__> slangasek, 60x11-common_localhost I'm not sure where that came from
<bryce__> the dexconf.patch is stray from an earlier review, my bad.
<bryce__> damn git trees
<bryce__> slangasek, I'd like to upload a new version with these two files removed.  They shouldn't be there and I'd be more comfortable if they weren't.
<slangasek> bryce__: ok, go ahead
<jsgotangco> jcastro: damn dude you posted a very old pic! I look thin :P
<LaserJock> jsgotangco: and so young!
<YokoZar> slangasek: the image format is .svg ;)
<slangasek> oh, yes, xml, *definitely* the wrong format >:)
<slangasek> superm1: is anyone working on bug #438875, that you know of?
<ubottu> Launchpad bug 438875 in ubiquity "Mythbuntu expects 'enter' to be pressed at the end of install but does not show prompt" [Medium,New] https://launchpad.net/bugs/438875
<LaserJock> slangasek: is it possible to know with what revision of debian-cd the .isos have been built with?
<slangasek> LaserJock: I don't think that's logged anywhere, no
<LaserJock> slangasek: darn, oh well
<slangasek> LaserJock: is that information actually useful anyway?  Is there a public branch corresponding to the debian-cd used on the builder?
<kirkland> slangasek: that's going to have to be ttx
<slangasek> kirkland: for java?  already fixed
<LaserJock> slangasek: well, I assume so
<kirkland> slangasek: he's the best person for it
<kirkland> slangasek: oh, sorry, just reading scrollback now
<slangasek> kirkland: no problem :)
<kirkland> slangasek: sorry, been under the weather today, in and out of bed
<slangasek> LaserJock: that's quite an assumption; the builder is somewhat contained wrt network access, and I know the changes I make to debian-cd don't get published to the outside world as part of anything /I/ do...
<LaserJock> slangasek: I assume http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<LaserJock> is what gets used
<slangasek> LaserJock: oh right, people keep repeating that URL, and I keep forgetting it :-)
<slangasek> (that implies cjwatson pulls periodically, then, yes)
<LaserJock> I just expected an important change to show up and it appears it didn't
<LaserJock> so I'm wondering if it's because of the timing of the bzr merge or if I need to dig more
<LaserJock> sometimes I wish we had hourlies ;-)
<LaserJock> but I'm guessing you wouldn't like that very much
<slangasek> on account of it not working
<slangasek> LaserJock: what part of the change isn't showing up?
<slangasek> LaserJock: part of the change is the 'Install an LTSP server' option, which should certainly be easy to confirm/deny
<LaserJock> slangasek: yeah, problem is it's a "deny"
<slangasek> because bzr respects timestamps, I can't really tell whether the update was done before or after the edubuntu build; so if you don't see the boot option, I think we should just respin
<LaserJock> slangasek: k
<LaserJock> I need to check if Ubuntu Alternate has it
<LaserJock> first I'll check that the seed file is there
<slangasek> actually, the preseed changes are there in the current edubuntu AFAICS
<LaserJock> ok, yeah
<LaserJock> the ltsp.seed is on the DVD
<LaserJock> why the heck isn't it showing up
<LaserJock> anybody have an Ubuntu Alternate daily handy to check if LTSP is in the F4 menu?
<slangasek> LaserJock: you're looking at 20091020?
<LaserJock> yeah
<slangasek> yeah, I see the changes present in gfxboot.cfg as well
<slangasek> LaserJock: F4> what do you see in that menu? f4.txt doesn't mention anything about ltsp
<slangasek> there's f3.txt, which gives a list of boot methods; ltsp isn't mentioned there either
<LaserJock> in previous Ubuntu releases it's been in the F4 menu
<slangasek> what is the F4 menu?  I don't have a booted ISO in front of me, I'm trying to figure this out based on inspecting the scratch dir
<slangasek> the f4.txt isn't menu-y at all
<slangasek> it mentions 'rescue', that's it
<LaserJock> I have: normal, safe graphics, and Use driver update disc
<slangasek> ok
<slangasek> so that's all taken from gfxboot.cfg, indeed
<slangasek> I don't actively understand how that's supposed to work, though, so don't know why ltsp isn't showing up
<LaserJock> is 20091020 still being built for Ubuntu Alternate?
<slangasek> no, images only get built when manually triggered now
<LaserJock> I see
<LaserJock> well poo, why didn't this work
<LaserJock> I guess I need to download an Ubuntu Alternate and see if it works there as the seed file, etc. are the same
<TheMuso> LaserJock: It may be quicker to pull the debian-cd bzr branch and check there...
<slangasek> no, the changes in question are changes that he /pushed/
<slangasek> we just don't know why they don't work
<TheMuso> slangasek: ah ok.
<shtylman> ccheney: will take a look at it
<Laibsch> Hi ArneGoetje
<Laibsch> Can you briefly explain to me the difference and similarity between ttf-arphic-{ukai,uming}?
<Laibsch> They are just different styles, right?
<Laibsch> I'm asking because some packages recommend uming and others ukai
<LaserJock> slangasek: ok, so the Ubuntu Alternate from 20091019.1 has the LTSP F4 option
<Laibsch> ArneGoetje: What do you think about making {chinese,japanase,...} fonts provide the virtual package $lang-font and encourage packages to depend on that?
<Laibsch> brb
<ArneGoetje> Laibsch: what benefit would that have?
<Laibsch> that's like asking what benefit do virtual packages have
<Laibsch> These packages all provide essentially a similar functionality
<Laibsch> in different "implementations"
<Laibsch> why depend on uming for package A and ukai for package B when in fact the dependency for a Japanese font could be fulfilled by just any Japanese font
<Laibsch> ?
<ArneGoetje> Laibsch: different fonts have different styles and are made for different usages... do you really want to mix that up by suggesting "any" Chinese, Japanese, etc. font to packages?
<Laibsch> I doubt that the packager meant to depend on a specific style
<Laibsch> If they do, fine.  Keep that recommendation.
<Laibsch> It's more like that in 99% of the cases the packager wants to indicate that scim will not be really usable without a CJKV font, for example
<ArneGoetje> Laibsch: I would be OK with that if we limit this to desktop (screen friendly) fonts...
<Laibsch> that includes and excludes which fonts for example?
<ArneGoetje> Laibsch: includes wqy-zenhei (which is installed by default anyways), ttf-arphic-uming and exclude ttf-arphic-ukai, since that font is only suitable for high resolution devices, e.g. printers
<Laibsch> I see
<Laibsch> Why would scim-pinyin recommend ttf-arphic-ukai, then?
<ArneGoetje> Laibsch: a package which teaches CJK characters for example, would want to recommend ttf-arphic-ukai explicitly and display the glyphs in a larger font size.
<ArneGoetje> Laibsch: I don't
<Laibsch> you don't "know"?
<ArneGoetje> Laibsch: recommend scim-pinyin to use ttf-arphic-ukai
<Laibsch> other way round
<Laibsch> $ aptitude why ttf-arphic-ukai
<Laibsch> i   scim-pinyin Recommends ttf-arphic-ukai
<Laibsch> judging from your explanation
<ArneGoetje> Laibsch: I don't recommend scim-pinyin to use ttf-arphic-ukai
<Laibsch> that looks like the wrong font
<ArneGoetje> Laibsch: +1
<Laibsch> OK
<Laibsch> ttf-arphic is not screen friendly?
<Laibsch> ???
<Laibsch> ttf-arphic-ukai is not screen friendly?
<ArneGoetje> Laibsch: should be changed to Recommends: ttf-wqy-zehei | ttf-arphic-uming
<Laibsch> OK
<Laibsch> I'll see to that
<ArneGoetje> Laibsch: ttf-wqy-zenhei that is
<TheMuso> cd
<TheMuso> gah wrong tab
<ArneGoetje> Laibsch: ttf-arphic-ukai is a Kaishu font (brush stroke), which is great for teaching how to write characters, but only looks good on high resolution devices or at larger font sizes. Something which doesn't go well with 96dpi screens and 10pt font sizes. :)
<Laibsch> I see
<Laibsch> For Japanese I'm basically aware of three main font categories: Mincho, Gothic and those Kaishu fonts
<ArneGoetje> Laibsch: yes. For desktop/screen Gothic is preferred. Mincho is used for printed articles, Kaishu for calligraphy printings
<Laibsch> I like Mincho for everything
<Laibsch> It's softer and got the brushy feel to it while still being readable
<ArneGoetje> Laibsch: for Chinese we have similar categories: Heiti or Yuanti (= Gothic) for screen, Mingti/Songti for articles, Kaiti for calligraphy
<Laibsch> i see
<ArneGoetje> Laibsch: anyways, for Ubuntu I don't see the need for those virtual font packages, since we ship desktop friendly fonts for CJK by default on the LiveCD. For Debian those would make sense however.
<Laibsch> Ubuntu is not only the LiveCD
<Laibsch> I think it makes a lot of sense for Ubuntu as well
<Laibsch> And once it's in Debian, it's in Ubuntu, too, anyway
<superm1> slangasek, i had hearrd that it was fixed at some point, but i've not confirmed it myself yet
<superm1> with all the usplash changes and what not, i've seen mixed behaviors recently
<ArneGoetje> Laibsch: they are dependencies of ubuntu-desktop
<slangasek> superm1: seems like something we would want fixed, so would be good to know whether it /is/ fixed :)
<Laibsch> ArneGoetje: Which I for example have removed
<superm1> slangasek, yeah.  it should be the exact same behaviors on all *buntu disks too, nothing special for myth*
<superm1> slangasek, neither 1019 nor 10191.1 appear to have ISOs in the folders though, so i'll have to defer an hour or so until 1020 is made to verify
<slangasek> superm1: we're in manual mode on ISO builds; best is to ask me if you see something missing
<superm1> slangasek, Ah, then yes can you try to regenerate ours?  the last two haven't showed up
<slangasek> yep, doing an ISO-only rebuild now
<slangasek> (i.e., using the existing lives)
<slangasek> livefs
<superm1> thanks
<ArneGoetje> Laibsch: okay... what would be the best approach for such virtual packages?
<Laibsch> I'm in the process of opening a ticket on LP
<Laibsch> We can then collect the fonts that should be made to provide the virtual package
<shtylman> ccheney: patch is good
<Laibsch> once those changes are in Debian and/or Ubuntu, the next step is to adjust dependencies of the packages that hardwire their dependency on particular fonts
<Laibsch> and relax that to the appropriate virtual package
<maco> i'm getting differing advice from different devs (no surprise i guess). is it best to add, say, quilt to a package if patching it or to simply apply the patch? one says add a patch management system so syncs dont break it. other says whomever's doing syncs should know to check for merging being necessary. opinions?
<Laibsch> maco: my opinion is that if you can add a patch system like quilt or dpatch it's generally the better option
<ScottK> maco: The current advice is don't bother adding a patch system if Debian doesn't have one.
<ScottK> Laibsch: Why?
<maco> *snort*
<maco> its still a tie!
<Laibsch> no
<ScottK> No, not actually.
<Laibsch> ScottK is right
<Laibsch> I was talking about something else
<Laibsch> let me explain
<Laibsch> if you really manage a package (iow you are Debian package maintainer) then it's a good idea to install a patch system like quilt or dpatch
<Laibsch> it keeps things cleaner and more manageable imho
<slangasek> maco: "syncs" are a red herring; if you're patching it at all then whoever is nominating it for a sync needs to explain why those changes should be dropped, whether or not a patch system is used
<Laibsch> but scottk is absolutely right that if Debian does not have a patch system in place and you want to prepare a ubuntu1 package, then it's probably better to patch directly
<ScottK> Laibsch: That's one way to do it.  Using a VCS is all the rage too these days.
<Laibsch> how is that an alternative?  I use a VCS for my Debian packages, yet still use quilt when applying Debian-only patches
<slangasek> I don't agree that it's better to patch directly unless you *also* point the Vcs-* fields at a relevant repo
<Laibsch> So far, I'm using then as tools for different things
<ScottK> Laibsch: VCS of the full source, not just a debian dir.
<Laibsch> I see
<ScottK> slangasek: If you have free time, I just filed a couple of removal bugs.  The gtk1.2 cleanup appears incomplete.
<slangasek> ScottK: currently running the unapproved queue, can have a look at those after
<ScottK> No rush
<Laibsch> I'm still packaging tarball-releases only so far
<Laibsch> I'm packaging gnucash cvs for private use
<Laibsch> I'm sure the way I do it is a mess ;-)
<slangasek> kirkland: isn't this mpich2 upload missing a FFe, seeing that it's bumping sonames?
<slangasek> robert_ancell__: I'm uneasy with this gdm upload.  switching from g-p-m to devkit, the week of RC?
<slangasek> robert_ancell__: or is this the 21_dkpower.patch that we already had?
<slangasek> robert_ancell__: right, seems that it is - that's ok then
<slangasek> -DI_KNOW_THE_DEVICEKIT_POWER_API_IS_SUBJECT_TO_CHANGE - heh, nice
<slangasek> robert_ancell__: it looks like our local patch had support for hibernate in addition to suspend, though, and that's missing in the upstream code?
<slangasek> robert_ancell__: also, the path for at-spi-registryd is now wrong.  I'm not sure that it was right before, but it's definitely wrong now, /usr/libexec isn't part of the FHS
<slangasek> (the prefix was configurable before, now it's hardcoded, meh)
<slangasek> asac, pitti: seahorse-plugins is dropping epiphany-browser in time for RC?
<superm1> slangasek, well is the expected behavior that that question in bug 438875 is asked via usplash?  it comes up, but it's just sitting on a plane vt
<ubottu> Launchpad bug 438875 in ubiquity "Mythbuntu expects 'enter' to be pressed at the end of install but does not show prompt" [Medium,New] https://launchpad.net/bugs/438875
<superm1> *plain
<siretart> morning
<slangasek> superm1: I /think/ usplash is supposed to exit, then the question is supposed to be displayed
<siretart> dtchen: a friend pointed me to it yesterday, shouldn't /etc/libao.conf use pulseaudio by default in the package?
<superm1> slangasek, well if that's the case, then this is working "properly".  i recall in earlier releases the question was actually posed via usplash
<slangasek> superm1: yes, the code in casper is there to do that if usplash is still running; I think that's probably worth a bug report against usplash
<slangasek> but doesn't seem like a blocker
<superm1> slangasek, okay i'll close that original bug then and file a new one against usplash
<slangasek> ok, cheers
<robert_ancell__> slangasek, the gdm patch should be ok because we don't use the buttons in upstream for shutdown - 22_shutdown_menu reimplements them in the bottom panel
<slangasek> robert_ancell__: aha, confirmed
<pitti> Good morning
<slangasek> robert_ancell__: the at-spi-registryd bit might bear further looking into?  But accepting this upload, in the meantime
 * slangasek waves to pitti 
<pitti> slangasek: I talked about this with asac and seb128 yesterday, and the plan was to drop the recommends in the 2.28.1 upload
<slangasek> pitti: ok, so I should watch for that upload
<pitti> slangasek: btw, tzdata 2009o is out; would you mind if I sync that?
<slangasek> s/watch for/sponsor/ ;)
<slangasek> pitti: go ahead
<robert_ancell__> hey is anyone a pkg-config expert here? Bug 455614 was raised where Debian has removed a recommends from a .pc file, any idea why you would want to do that?
<pitti> it seems Argentina changed rules slightly (probably for the Saint Louis special case *sigh*)
<ubottu> Launchpad bug 455614 in libsm "don't mess with the pc file" [Undecided,New] https://launchpad.net/bugs/455614
<superm1> slangasek, re that alsa-utils thing from the other day, i can confirm reverting debian/init back to ubuntu3 from ubuntu5 does solve the problem too.
<slangasek> superm1: right - I haven't seen a fixed upload yet that just does this, however
<superm1> slangasek, yeah i was going to confirm with you that it's okay to upload such a thing first (after I confirmed that it really did fix it)
<slangasek> yes, please
<superm1> okay will do in a few min
<pitti> slangasek: seahorse-plugins> oh, you are going to? I'll sponsor the other bits then (gdm, g-d-sharp, etc.)
<slangasek> pitti, asac: well, the bzr branch doesn't yet have the epiphany change
<slangasek> and I would have to hunt down the upstream tarball; better if someone else does it, I think
<pitti> slangasek: *nod*
<pitti> slangasek: I'll talk to asac about the epy change when he's up and upload ASAP
<robert_ancell> TheMuso: Do you know about the Exec field in /usr/share/gdm/autostart/LoginWindow/at-spi-registryd-wrapper.desktop? It's changed in gdm-2.28.1 but I don't know what the effect is
<slangasek> robert_ancell: note that for the other instance of usr/libexec in the source, debian/patches/04_fix_external_program_directories.patch fixes this up
<robert_ancell> slangasek, yeah, the thing that's got me is there is nothing providing the current path.  So I'm thinking it may not make any difference what path is in there currently
<slangasek> robert_ancell: sure, that was my rationale for accepting it as-is :)
<robert_ancell> slangasek, :)
<robert_ancell> mvo, should the gnome-codec-install changes you pushed into bzr be released? bug 455131
<ubottu> Launchpad bug 455131 in gnome-codec-install "Update to 0.4.1" [Wishlist,New] https://launchpad.net/bugs/455131
<slangasek> mvo: does update-manager need an update yet to s/karmic/9.10/ for release?
<pitti> seb128: do you know the plan (how) to drop epy from seahorse-plugins? there's a sponsoring request for 2.8.1, but it doesn't have that change
<seb128> pitti, asac said he would work on that, I assigned the bug to him yesterday
<pitti> seb128: ok, thanks
 * StevenK blinks at autologin not working
<robert_ancell> StevenK, not working?
<mvo> slangasek: no, but I have a change for 431473 pending
<slangasek> mvo: ok, cool; DistUpgrade/ReleaseAnnouncement seems ready, wasn't sure if there was anything else needed
<mvo> robert_ancell: yes, the changes should be fine, I meant to do triage on the open bugs and see if there are low hanging fruits, but I did not manage to :/
<slangasek> mvo: is that the right bug number?
<StevenK> robert_ancell: I could have sworn Moblin Remix, UNR and desktop should autologin. Moblin Remix is at gdm, and I can't login
<mvo> slangasek: yeah, this time we have two release notes that we can switch more dynamically)
<mvo> slangasek: bug #434173
<ubottu> Launchpad bug 434173 in update-manager "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [High,Confirmed] https://launchpad.net/bugs/434173
<slangasek> mvo: good plan :)
<slangasek> mvo: ah yes, that bug number looks much better :)
<slangasek> StevenK: 2.28.0 or 2.28.1?
<slangasek> (not that it should matter, from what I saw of the code)
 * StevenK checks
<StevenK> Hm
<StevenK> "unknown user: ubuntu"
<StevenK> I suspect this is my own problem
<StevenK> Nevermind :-)(
<slangasek> mmk
<TheMuso> robert_ancell: I actually shipped a .desktop file in the at-spi package to work around the incorrect path given in the gdm wrapper desktop file, thinking that that file would be gotten rid of from gdm.
<slangasek> TheMuso: heh; so we can go on ignoring it, I guess
<TheMuso> slangasek: works for me.
<slangasek> TheMuso: please check that things still work as expected with the latest gdm, in any event :)
<TheMuso> slangasek: It doesn't break anything, noting from that desktop file gets started
<TheMuso> slangasek: Will do.
 * StevenK suspects the initrd he built is broken
<ArneGoetje> cjwatson: I just installed Ubuntu from the LiveCD with en_US as target language into a VM. Ubiquity pulled all the language-support and translation dependencies, but at 97% of the installation it purged some of them again together with all the other unused langpacks...
<slangasek> ArneGoetje: was there anything in the latest ubiquity that should help there? I don't remember
<ArneGoetje> slangasek: it is supposed to call check-language-support and install all the packages it gets fed from there... and it does that. I just don't know why some of those packages get marked for deletion afterwards.
<ArneGoetje> slangasek: namely language-support-writing and its dependencies.
<slangasek> ArneGoetje: right; no idea then, sorry
<slangasek> superm1: do you know if bugs 432660, 447204, 447395, 447413 need reopened on alsa-utils then?  (Bugs that were closed with the -2ubuntu4 upload)
<ubottu> Launchpad bug 432660 in pulseaudio "Master, Headphones and PCM muted at reboot" [High,New] https://launchpad.net/bugs/432660
<ubottu> Launchpad bug 447204 in alsa-utils "alsactl restore interferes with PulseAudio's volume restore" [Low,Fix released] https://launchpad.net/bugs/447204
<ubottu> Launchpad bug 447395 in alsa-utils "[Karmic] Randomly boot without sound" [Undecided,Fix released] https://launchpad.net/bugs/447395
<ubottu> Launchpad bug 447413 in alsa-utils "No sound (Dell XPS 1330M)" [Low,Fix released] https://launchpad.net/bugs/447413
<apachelogger> asac: ping
<seb128> slangasek, hey
<slangasek> seb128: hello
<seb128> slangasek, so we are mostly there for GNOME, we still have bug #455900 to fix before rc or karmic
<ubottu> Launchpad bug 455900 in compiz "closing launched windows does not return focus to original windows, this is bad for accessibility" [High,Confirmed] https://launchpad.net/bugs/455900
<seb128> and I'm not sure dxteam wants an updated notify-osd, MacSlow has been fixing bugs in a karmic bzr apparently
<seb128> otherwise I think we are done from the desktop side now
<slangasek> seb128: ok, great!
<slangasek> seb128: that doesn't include seahorse yet, though?
<seb128> slangasek, oh no, waiting news from asac for this one since he wanted to port to xul 1.9.1
<seb128> he said he would do that yesterday and upload
<slangasek> asac: ping?
<slangasek> pitti: hum, no builders currently building karmic on i386 or amd64?  anything that needs looked at there?
<slangasek> ah, official builders are all "Building private source"
<Laibsch> whois sistpoty
<Laibsch> He doesn't seem to be online
<pecisk> hi people, if PA wrongly detects my sound card, where in the source I should look at and against what I shall report the bug?
<Hobbsee> Laibsch: [18:56] [Notice] -NickServ- Last seen  : Oct 11 14:49:01 2009 (1 week, 1 day, 17:07:04 ago)
<Laibsch> quite a while
<pecisk> PA wrongly detects my sound card = it doesn't appear in Volume Settings => Output
<Laibsch> thanks, Hobbsee
<Hobbsee> Laibsch: you're welcome
<soren> Laibsch: He was here yesterday.
<soren> 16:56:20 *** sistpoty|work n=sistpoty@ubuntu/member/sistpoty has quit ["Back to work, really."]
<soren> From yesterday.
<soren> (UTC timestamp)
<TheMuso> pecisk: What version of Ubuntu are you running?
<pecisk> Karmic Koala last updates
<TheMuso> pecisk: Hrm ok. Do you happen to have the sl-modem daemon running?
<pecisk> TheMuso, not on this computer
<slangasek> pecisk: is there more than one user session active on the system, does your session show up in the output of ck-list-sessions, does getfacl /dev/snd/pcm* show your user?
<pecisk> TheMuso, there was laptop with sl-modem and there also Karmic didn't show sound card
<pecisk> but this is computer ir different matter
<pecisk> slangasek, one sec
<pecisk> slangasek, there is only one user
<pecisk> :)
<TheMuso> pecisk: You could try disabling pulseaudio auto-spawning, killing pulseaudio, and restarting it...
<slangasek> pecisk: what about the other two questions?
<pecisk> slangasek, I can't find getfacl command
<pecisk> shall I install something?
<slangasek> pecisk: the 'acl' package
<soren> Running "getfacl" should tell you this.
<pecisk> slangasek, what ck-list-sessions should show?
<slangasek> pecisk: your user's session
<soren> No command 'getfacl' found, did you mean: Command 'getfacl' from package 'acl' (universe)
<pecisk> slangasek, then it shows it so
<soren> Or some such.
<slangasek> pecisk: ok
<pecisk> installing acl...
<ogra> soren, it tells you the apt line for copy/paste as well :)
<soren> ogra: Yeah, I thought so. It just didn't for me, since I already had it installed :)
<ogra> yeah
<pecisk> slangasek, getfacl gives me report about all pcm devices and it shows that user:peteris has rw- for all of them
<pecisk> in fact
<slangasek> ok
<pecisk> my scenario here is complicated
<pecisk> it shows one device
<pecisk> which seems to be part of my multichannel card
<TheMuso> Ah, multi-channel card?
<slangasek> in that case I'll turn you back over to TheMuso, since we've ruled out consolekit :)
<pecisk> yeah :)
<TheMuso> pecisk: What card is it?
<pecisk> Terratech EWS88MT, uses ice1712 chipset, fully supported
<TheMuso> pecisk: Right, theres the problem right there, pulseaudio does not yet deal with those cards very well.
<TheMuso> pecisk: And there is already a few bugs filed about it.
<TheMuso> pecisk: So if you want to add your voice, feel free to look for bugs relating to ice1712 and pulseaudio.
<pecisk> I see
<pecisk> old PA didn't have huge problems :)
<pecisk> but I see that rather big changes happened
<TheMuso> Yeah well a lot has changed for PA in karmic
<pecisk> yeah
<pecisk> actually how that card detection happens in PA?
<TheMuso> pecisk: It uses udev to find the card, but it then uses various channel map profiles to work out how to control the volume/outputs of the card.
<TheMuso> pecisk: have a look in /usr/share/pulseaudio/alsa-mixer/
<TheMuso> I think users in those bugs have done something to try and get things working.
<pecisk> I see
<pecisk> ok, I will search LP
<pecisk> thanks for the tips :)
<TheMuso> pecisk: You're welcome.
<cjwatson> ArneGoetje: could I see the log? remember that ubiquity removes things that are in the live filesystem but that it determines aren't needed on the target system
<pitti> slangasek: doko moved them to manual yesterday, but this looks like something else
<cjwatson> but I may be misunderstanding you, and the log should make it clearer
<ArneGoetje> cjwatson: which log file?
<cjwatson> /var/log/installer/syslog
<doko_> pitti: ?
<slangasek> doko_: autobuilders
<cjwatson> slangasek: my guess on LaserJock's problem is that he got confused by the fact that the LTSP server option is only available when certain main menu items are selected (it doesn't work on a ubiquity-based install, for instance), but he left IRC so ...
<slangasek> doko_: the queue of needs-built packages gets longer, the autobuilders are off doing something else :/
<slangasek> cjwatson: oh, interesting
<doko_> yeah, another one ...
<doko_> # 48 "/usr/include/libvisual-0.4/libvisual/lv_defines.h"
<doko_> #define inline inline __attribute__ ((always_inline))
<doko_>  /usr/include/c++/4.4/powerpc-linux-gnu/bits/c++config.h:214: error: expected unqualified-id before 'namespace'
<cjwatson> one of these days, we'll have build pooling, and will be able to use PPA builds to bolster the distro at times like this
<cjwatson> build*d*s
<doko_> #if __GNUC__ >= 3
<doko_> # define inline                 inline __attribute__ ((always_inline))
<doko_>  /* Compiler specific optimalization macros */
<slangasek> doko_: bug #446478> this should be deferred, shouldn't it?  Since you ditched the testsuite-only fix
<ubottu> Launchpad bug 446478 in gcc-4.4 "testsuite failures in the ld testsuite on arm-linux-gnueabi" [Undecided,Confirmed] https://launchpad.net/bugs/446478
<asac> slangasek: seb128: i am doing seahorse now
<slangasek> asac: ok, cheers
<seb128> asac, thanks
<seb128> asac, robert_ancell did the upgrade cf sponsoring queue
<ArneGoetje> cjwatson: https://rookery.canonical.com/~arne/syslog
<asac> seb128: ok. i can pick it then
<ArneGoetje> cjwatson: at the end it removes language-support-en, which removes language-support-writing-en and all dependencies
<cjwatson> hmm, check-language-support doesn't output packages you've already installed, does it?
<cjwatson> that's the problem - how is ubiquity supposed to know which of the packages it already has installed it should keep?
<cjwatson> I think we'll need to add an option to check-language-support to change that
<doko_> slangasek: yes
 * sivang notes he just bugged sabdfl with some morning chitchat and was gently hinted ubunt  isin the thick of release and wish all devs good luck with the reelase and happy testing on ION Based hardware
<slangasek> ArneGoetje, cjwatson: is this bug #452516, effectively?
<ubottu> Launchpad bug 452516 in ubiquity ""Incomplete Language Support" for English" [High,Triaged] https://launchpad.net/bugs/452516
<cjwatson> slangasek: modulo the usual gripes about reopening bugs when the added code doesn't quite work ...
<slangasek> cjwatson: though no one seems to have closed that bug ever :)
<cjwatson> I thought I did
<cjwatson> huh, maybe not, how odd
<cjwatson> bug 434173
<ubottu> Launchpad bug 434173 in update-manager "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [High,In progress] https://launchpad.net/bugs/434173
<cjwatson> that's the one I closed; actually, yeah, bug 452516 is different
<ubottu> Launchpad bug 452516 in ubiquity ""Incomplete Language Support" for English" [High,Triaged] https://launchpad.net/bugs/452516
<cjwatson> 452516 is about the fact that we don't have complete language support for *any* language on the CD, and can't, and what to do about that
<cjwatson> since it is unsightly to declare that everyone has incomplete language support
 * slangasek nods
<mvo> lool: http://paste.ubuntu.com/297340/ is probably something you want to add to the debian package
<cjwatson> ArneGoetje: I'm thinking http://paste.ubuntu.com/297341/ - what do you think?
<cjwatson> also, should we stop including language-support-LL on the CDs, and maybe include language-support-writing-LL or something instead?
<cjwatson> hmm, language-support-LL still has interesting dependencies
<cjwatson> ArneGoetje: if language-support-LL is still useful, perhaps check-language-support should list it?
<lool> mvo: committed; thanks
<Riddell> evand: any quick ideas on bug 455580 ?
<ubottu> Launchpad bug 455580 in ubiquity "Kubuntu auto resize can not move slider" [Critical,Confirmed] https://launchpad.net/bugs/455580
<mvo> lool: thanks
<evand> Riddell: looking now
<lool> doko_: #455718
<doko_> bug 455718
<lool> doko_: Looks like xml-apis isn't ship in http://packages.debian.org/sid/all/libxalan2-java/filelist
<ubottu> Launchpad bug 455718 in libxalan2-java "libxalan2-java ships /usr/share/java/xml-apis.jar which is also in libjaxp1.3-java" [Undecided,Confirmed] https://launchpad.net/bugs/455718
<lool> doko_: So I guess we should explicitely disable the xml-apis target in rules
<lool> (in libxalan2-java)
<lool> doko_: Do you agree this is the way we want to fix it?
<doko_> lool: it is fixed, the gap between the builds was a bit longer than expected
<pecisk> TheMuso, found one bug, did a fix suggested in comments, works now
<pecisk> thanks
<TheMuso> pecisk: great
<TheMuso> pecisk: np
 * pecisk turns on Keane in full power
<slangasek> doko_: it's not fixed, there must be a missing versioned Replaces if you're seeing that error
<lool> doko_: I just updated again and I dont get any new .deb
<lool> I can add a replace in libjaxp1.3-java
<doko_> ahh, I hate <= replaces/conflicts: Conflicts: libxalan2-java (<= 2.7.1-2)
<doko_> adding this ...
<slangasek> oh, if the conflicts was there, why did it fail
<slangasek> ah, we had 2.7.1-2ubuntu1 before, right
<lifeless> doko_: what do you think of the idea of a ABI/header split for java packages - with the pom in the -dev
<lifeless> doko_: and/or making java binary packages have the 'soname' - the jar version - in the package name, so that multiple versions are able to be installed [to satisfy various maven dependencies more readily]
<joaopinto> mvo, is there any support on update-manager to fetch changelogs for packages from 3rd party repositories ?
<mvo> joaopinto: not currently, what repos do providem them? we can add it in lucid
<joaopinto> mvo, I am still researching on the subject, I would like to provide it for playdeb/getdeb
<joaopinto> the archive packages changelogs are extracted during build ?
<doko_> lifeless: do you volunteer to implement this?
<mvo> joaopinto: right
<doko_> we did discuss this at debconf, but for the reason to know when the ABI breaks.
<mvo> joaopinto: well, its more complicated during build from LP and later again with a script on changelogs.ubuntu.com
<mvo> joaopinto: I guess you could just that script too
<joaopinto> I check u-m source, I guess the main issue is how do you setup the changelogs source url from a custom respository
<mvo> joaopinto: the goal for lucid is to make it all LP based
<mvo> joaopinto: yeah
<TheMuso> /c/c
<joaopinto> mvo, a grep reveals, both http://changelogs.ubuntu.com/changelogs/pool... and http://launchpad.net/ubuntu/+source/%s/%s/+changelog
<joaopinto> LP is the one actively used ?
<mvo> joaopinto: the changelogs one, the other is just a fallback, the format is different currently
<joaopinto> ok, so an easy way to do it would be to use changelogs.repository_domain.com/ for non ubuntu sources
<mvo> joaopinto: but the goal is to switch to LP for the ubuntu ones (but it can/should support different sources if there is a need for this)
<joaopinto> there are some enterprise internal repositories which would also like to have this feature
<mvo> joaopinto: yeah, that sounds reasonable
<mdz> cjwatson: re: bug 455619, just mailed some analysis to the bug
<ubottu> Launchpad bug 455619 in linux "grub-pc removed, update-grub fails" [Undecided,New] https://launchpad.net/bugs/455619
<yoritomo> hello all
<mdz> slangasek: ^^
<cjwatson> mdz: I don't know how much we can do about this; the missing Conflicts was an error, precisely because there were files installed by both packages that didn't cause an error due to Replaces
<cjwatson> and that's the error that led to your /usr/sbin/update-grub going missing
<mdz> cjwatson: indeed. I guess I'm mostly looking for validation of my hypothesis, so that we have an explanation for what happened
<cjwatson> it won't affect jaunty->karmic upgrades, because the conflicts was there in jaunty
<yoritomo>  it has a bug with glipper which can't be reported by karmic, it crash everytime starting karmic,  and when i access to the logs i get this error on top on the window http://paste.ubuntu.com/297346/ which logs may i provide to you to fix that problem ?
<cjwatson> mdz: your hypothesis is completed by observing the Replaces fields; it seems correct to me
<cjwatson> mdz: I would like to see the older apt logs to see why grub-pc was pulled in
<joaopinto> hum, evern simpler, just use the repository base url+/changelogs/pool/..., no need for an additional hostname just for the changelogs
<mdz> cjwatson: is the conflict bug 410886?
<ubottu> Launchpad bug 410886 in vm-builder "VMBuilder doesn't work with grub2" [High,Confirmed] https://launchpad.net/bugs/410886
<slangasek> asac: your seahorse-plugins upload doesn't include any changes to the build-depends
<cjwatson> mdz: that's the bug due to which I noticed the problem, although it was actually about something else
<slangasek> asac: --> rejected
<asac> slangasek: argh ... gnome control.in i guess
 * asac wonders how often he needs to end up in that trap
<slangasek> mdz: analysis looks accurate, yes; have seen a couple of other reports of the same :9
<slangasek> h:(
<seb128> slangasek, pitti: ok, notify-osd for dxteam uploaded
<mdz> cjwatson: http://people.canonical.com/~mdz/temp/apt-logs-mizar.tar.gz
<seb128> slangasek, I'm done with changes now
<yoritomo> nobody interested by that bug ?
<seb128> slangasek, there is still a compiz fix coming from mvo before lunch
<pitti> seb128: thanks, will review
<seb128> slangasek, pitti: we are done for desktop otherwise I think
<pitti> seb128: great job with 2.28.1!
<seb128> pitti, danke ;-)
<joaopinto> mvo, this was already request 3 years ago: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/45129 :P
<ubottu> Launchpad bug 45129 in update-manager "update-manager should have per-package changelog locations (was: uses changelogs.ubuntu.com for all packages)" [Wishlist,Confirmed]
<joaopinto> requested
<pitti> seb128: well, we still need seahorse-plugins, no?
<mdz> slangasek: cjwatson: mightn't it fix the problem to just make a new grub upload, so that if grub-pc is removed, grub gets upgraded as well and /usr/sbin/update-grub comes back?
<seb128> pitti, right, asac is one this one, it has been uploaded and need a quick round because of control.in control
<asac> seb128: slangasek: searhorse-plugins reuploaded
<yoritomo> ok bye, have a nice day
<seb128> pitti, ^
<pitti> great
<seb128> pitti, oh btw glib gettext change doesn't translate X-GNOME-FullName=
<slangasek> mdz: if the new grub also adds a Conflicts to ensure the removal of grub-pc happens first, yes
<seb128> which is used in GNOME 2.28 by some programs now
<pitti> seb128: oh, we should fix that (for lucid)
<seb128> pitti, I don't think it's something we want to address in karmic now?
<seb128> ok
<slangasek> pitti: ah, you already grabbed seahorse-plugins?
<mdz> slangasek: that seems like a simple and safe fix which would avoid the fallout
<pitti> slangasek: reviewing notify-osd right now, will still take me some minutes
<cjwatson> mdz: yes, probably - I'll do that
<pitti> slangasek: I didn't touch seahorse yet
<mdz> cjwatson: it looks like I tried updating this system to grub-pc, but it didn't work (due to the error you can see in the bug description)
<mdz> perhaps I re-installed grub during the window where it didn't conflict
<slangasek> pitti: oh, confused by queuebot's delay :)
<cjwatson> mdz: I can't guarantee that it will avoid all fallout, since there may well be a period between removal of grub-pc and upgrade of grub in which update-grub is missing
<cjwatson> but I can't think of a sane way to do better
<slangasek> asac: why are all these xulrunner/firefox changes only landing now?  GNOME 2.28.1 I was expecting this week, because it wasn't out before, but why weren't these other uploads done last week?
<asac> slangasek: the transitional packages?
<slangasek> asac: any of it
<asac> slangasek: my bad. i wanted to get those RC bugs fixed and once i know that the fixes were good i did this stuff
<slangasek> asac: it makes for a very bad day when I have to wait hours longer than expected for FF builds before I can start rolling final ISOs
<asac> slangasek: yes, really sorry. i should have uploaded the stuff last night, but i was too tired and did want to do the final review of this upload after sleep
<asac> the important fix i needed for xulrunner 1.9 is bug 441552
<ubottu> Launchpad bug 441552 in firefox "[MASTER] Firefox 3.5 prompting to restart without installing new addons" [Unknown,Confirmed] https://launchpad.net/bugs/441552
<asac> 1.9.1
<Riddell> Keybuk: ubuntu desktop uses usplash still?
<slangasek> Riddell: yes
<slangasek> asac: xulrunner-1.9 transition package> is that really sensible?  Isn't the whole reason for the different package name that they have differing ABIs?
<asac> slangasek: for consumers that use only stable XPCOM components there was no ABI change
<slangasek> asac: is that an accurate description of all the reverse-deps of xulrunner-1.9 in Ubuntu? :)
<asac> slangasek: no. but now there shouldnt be anything left
<slangasek> asac: then why do we need a transition package?
<slangasek> asac: transition packages ought to be used only for leaf packages that users will install directly, or for -dev packages that are needed on an interim basis due to a large number of revdeps that need to be transitioned; AIUI, you've already /finished/ the library transition here, so I don't think this xulrunner-1.9 transition package helps us - AFAICS it can only hurt
<asac> slangasek: yes. but xulrunner is also a leave package for some users (sorry, had to say that) .... anyway, i trust your feeling on this, if you want me to remove the transitional packages and just upload the fix i can do that
<slangasek> asac: I strongly recommend it given the timing, yes
<slangasek> asac: rejected current upload
<asac> slangasek: ok thx. reuploaded with just the fix. making a removal bug out of the other bug then.
<slangasek> asac: thanks
<pitti> mvo: the g-c-install upload has a 200 line effective code diff..
<pitti> oh, there's some whitespace noise
<mvo> pitti: it should be much less and the changes should be pretty striaghtfoward
<mvo> let me look at the diff again
<pitti> http://pastebin.com/f7c91d8a7 is the effective diff
 * mvo nods
<pitti> mvo: and string changes..
<pitti> -             "â¢ These restrictions do not apply in your country "
<pitti> +             "* These restrictions do not apply in your country "
<mvo> that one is needed to fix a gettext issue
<pitti> (translatable)
<mvo> well, work around it
<pitti> how so?
<mvo> with the â¢ no translation works
<mvo> works
<slangasek> pitti: you can't have non-ascii in source strings
<slangasek> because .po files may be in a charset other than UTF-8
<mvo> I did unfuzzy all the strings, it should be fine (and I tested it with german)
<pitti> isn't that why .po/.pot have an encoding?
<pitti> slangasek: oh, you mean in case in that other charset, the â¢ char isn't representable?
<slangasek> pitti: yes
<pitti> mvo: unfuzz> ah, ok
<slangasek> ascii is the only common charset that gettext can guarantee
<pitti> ok, so that's fine, and the whitespace noise is ok, too
<pitti> the transient window fix is pretty intrusive and it doesn't seem OMGurgent?
<mvo> no, not OMG
<mvo> just nice
<pitti> mvo: did you test this in different scenarios? (e. g. synaptic running in the background and not)
<mvo> i did test, but not this particular case, I can do that now
<mvo> pitti: its fine with me if you reject it, I'm sorry for the lateness of the merge :(
<mvo> but I think its pretty safe from reading the diff/testing
<simon-o> Hi, I'm looking at a package which FTBFS. There is a new upstream version with a "rewritten" build system. Imho it would be the easiest to sync the package from Debian, but I don't know if this is ok, this late in the cycle...
<simon-o> http://launchpadlibrarian.net/31810058/buildlog_ubuntu-karmic-i386.givaro_3.2.10-1_FAILEDTOBUILD.txt.gz
<ScottK> simon-o: If the current package FTBFS, then we should consider it.
<jernst> YokoZar: hello, I just tried your âgnome-exe-thumbnailerâ package on karmic and wondered if you noticed the same problem as me : all icons are the same and nautilus says wrestool: file:///home/jernst/Bureau/Firefox%20Setup%203.5.3.exe: no such directory or file
<slangasek> asac: heh; firefox-3.0 landed in new because it adds an abrowser-3.0 transitional package, there's never been an abrowser-3.0 before
<simon-o> ScottK: Yes it FTBFS, I just tried it with pbuilder. The package from Debian builds fine
<YokoZar> jernst: I had noticed it.  I can't figure out why the error is there, because wrestool is definitely available
<YokoZar> (it's in icoutils, which is a dependency of teh thumbnailer package)
<YokoZar> when i run the thumbnailer script manually from the command line it works fine
<slangasek> YokoZar: because something is passing URL-encoded filenames to wrestool as an argument?
<YokoZar> slangasek: hmm, that would make sense as some crazy undocumented behavior
<slangasek> YokoZar: well, that's what the error message says to me
<YokoZar> what's the quick way to convert url-encoding to normal filename
<slangasek> use some corresponding g_ function
<slangasek> YokoZar: symbol table suggests g_filename_from_uri
<jernst> YokoZar: yes that's the problem, wrestool doesn't understand file://
<liw> YokoZar, http://library.gnome.org/devel/glib/stable/glib-Character-Set-Conversion.html#g-filename-from-uri
<YokoZar> slangasek: that's a C function the thumbnailer is actually a simple shell script :)
<YokoZar> hmm, so to fix my shell script I can choose between pulling in glib, crafting something in sed/awk, or 2 lines of python
<jernst> YokoZar: I thought about sed awk, seems a little bit too hackish ;-) what 2 lines of python are you thinking about ?
<YokoZar> jernst: import urlparse \ print urlparse.urlparse("foo").path
<liw> python -c 'import sys, urlparse; print urlparse.urlparse(sys.argv[1]).path' file:///home/liw/README (tested :)
<jernst> liw YokoZar : doesn't seem to work with %20 though (file:///home/jernst/Firefox%20Setup%203.5.3.exe)
<YokoZar> jernst: so it's not converting %20 to "\ "
<jernst> YokoZar:  that's the problem I see yes
<liw> is %xx defined for file: urls?
<YokoZar> yup urlparse.urlparse.__doc__ says it doesn't expand % escapes
<YokoZar> liw: good question, easiest way is to just build a test package and see, heh.  I'll do that now
<jernst> liw: nautilus uses %20 for spaces in URI sent to thumbnailers, I can see it here
<liw> hm, is one supposed to decode %xx first, and then the rest?
<asac> ArneGoetje: lang packs all ok?
<asac> ArneGoetje: did the full export happen?
<liw> hm, no, can't do %xx separately (silly me)
<YokoZar> liw: well how about urllib.unquote
<liw> python -c 'import sys, urlparse, urllib; print urllib.unquote(urlparse.urlparse(sys.argv[1]).path)' file:///home/jernst/Firefox%20Setup%203.5.3.exe
<liw> YokoZar, yeah
<jernst> YokoZar: http://pastebin.ubuntu.com/297380/
<jernst> wfm
<YokoZar> jernst: heh that's exactly what I wrote (except I used "deurled" for the filename)
<YokoZar> I believe we've just discovered the art of synchronous coding
<jernst> YokoZar: I guess so ! ;-) by the way thank you for your efforts to better integrate Wine in Ubuntu !
<simon-o> ScottK: I filed this as bug 456231.
<ubottu> Launchpad bug 456231 in givaro "Sync givaro 3.2.13-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/456231
<jernst> YokoZar: do you have already filed a bug for the automatic borders ?
<jernst> YokoZar: I was wondering why you don't compose your icon with a transparent background of the correct size to workaround the forced borders instead of using the frame ?
<YokoZar> jernst: it's intentional that the icon is small and in the middle, if that's what you mean
<YokoZar> but yeah the whole thumbnail is a bit big
<YokoZar> although putting transparent borders on it results in other weirdness in nautilus like extra spacing
<jernst> YokoZar: you mean you don't want to show only the icon (with maybe a small wine icon) and not the whole window arround it?
<YokoZar> jernst: the idea is to show just the programs icon if it's marked executable, and otherwise show it embedded inside a larger (generic) executable container
<Keybuk> pitti: random question of the day
<YokoZar> the point is to make executable applications (wine .exe, python files, elf binaries, etc) look visually distinct until they've been given explicit execute permissions
<Keybuk> you know how bcmwl-kernel-source is on the USB key pool?
<Keybuk> how are you actually meant to install that? :p
<YokoZar> once they have u+x then they can be presumed trusted and we use their embedded icon
<pitti> Keybuk: what's an USB pool?
<Keybuk> pitti: you know, on the Live image?
<Keybuk> the pool/dists directory and archive
<Keybuk> ship seed
<Keybuk> etc.
<pitti> ah; so, what's the problem with it?
<pitti> I wonder why we have it at all, though, it's dependencies should be very heavy
<pitti> gcc, make, and all that
<Keybuk> well, how do you use it?
<jernst> YokoZar: I see
<Keybuk> all of the deps are either in the same pool, or already installed
<pitti> Keybuk: jockey, or mere apt-get install
<Keybuk> I've never known how to *actually* use that key
<Keybuk> how?
<Keybuk> jockey doesn't appear :)
<amitk> tseliot: nvidia update blew up again (identically) http://pastebin.ubuntu.com/297390/
<YokoZar> jernst: it would be nice to not have nautilus force the size of thumbnails though
<Keybuk> pitti: if you start it from System, all it says is "No proprietary drivers are in use on this system"
<pitti> Keybuk: is the USB key archive actually added to apt sources?
<Keybuk> pitti: even if it was, it wouldn't work
<Keybuk> since the rest of the apt sources will fail
<Keybuk> because the driver in that pool is the network card driver ;)
<Keybuk> but no
<Keybuk> that archive is not in the default sources.list
<Keybuk> cjwatson: maybe you know?
<pitti> Keybuk: jockey won't display a driver whose package isn't available, so that would explain it
<pitti> hm, tricky; I don't think many people woudl appreciate if apt keeps asking them to insert their USB stick instead of just fetching packages from the net; but in this case it would be preferable indeed
<cjwatson> Keybuk: it's supposed to be added, can I see the installer syslog?
<cjwatson> well, hmm, is it. I think it is, for the moment
<cjwatson> whether that's a bug or not
<Keybuk> cjwatson: sure, one moment
<Keybuk> just doing the reboot to install wl ;)
<Keybuk> cjwatson: http://people.canonical.com/~scott/installer-logs.tgz
<cjwatson> of course, this is all emergent behaviour, we didn't sit down and think "let's put a pool on the USB stick"
 * slangasek chuckles
<cjwatson> oh, that's right, now I remember, we disable the cdrom source in sources.list if any other apt sources are present, so that the user doesn't get prompted all the time
<steveire> Hey
<cjwatson> so in short I have no idea how this is supposed to work automatically, although it's clearly available for manual use
<steveire> My laptop is doing its first hard drive check since I installed the beta
<steveire> It doesn't give any progress at all anymore.
<Keybuk> cjwatson: how do I do it manually? :p
<steveire> No 33% done or anything
<Keybuk> steveire: I *just* uploaded the fix for that ;)
<steveire> Keybuk: Cool.
<cjwatson> Keybuk: fiddle sources.list?
<Keybuk> cjwatson: 'cos basically I just run dpkg -i on the mentally expanded bunch of packages I know I need :p
<Keybuk> cjwatson: I'd have to comment out all the archive things, no? :p
<cjwatson> is that actually still true? I know it whines ...
<Keybuk> cjwatson: it appears to fail currently
<YokoZar> steveire: is it ext4?
<slangasek> chrisccoulson: was there any more information you need from me on bug #447431?
<ubottu> Launchpad bug 447431 in gnome-settings-daemon "gnome-settings-daemon dies with BadMatch" [Medium,Triaged] https://launchpad.net/bugs/447431
<cjwatson> Keybuk: obviously there are tricks you can pull with temporary sources.list files and such, but personally I'd just comment out the other lines
<steveire> YokoZar: I don't remember. How do I check?
<YokoZar> Whomever the fast archive admin was that just approved gnome-exe-thumbnailer after I uploaded it 2 minutes ago thanks :)
<steveire> fdisk -l doesn't tell me
<Keybuk> cjwatson: it's easier to just install it manually
<Keybuk> *but*
<Keybuk> since the whole point of *having* bcmwl-kernel-source there is so people can actually get their wireless working
<Keybuk> shouldn't this be much easier in general?
<cjwatson> it definitely should; until you just described this problem now, I didn't know it was difficult
<cjwatson> Michael's dynamic cdrom patch to apt should help a lot
<cjwatson> since that will make it possible to have 'deb cdrom'-type things in sources.list without having to worry about changing device names
<chrisccoulson> slangasek - i'm a bit confused about the trace actually. unless i'm misunderstanding something, "minor_code 7" corresponds to "XRRSetScreenSize", although perhaps i'm confused about what the minor_code really represents
<steveire> It was ext3
<chrisccoulson> anyway, if i understand minor_code correctly, then the trace is still running asynchronously. that might be because this is code loaded from a plugin, and perhaps the "--sync" option has no effect there (ie, XSynchronize is never called on the display connection)
<steveire> Although I think it also checked a different ext4 partition at the same time which also gave no feedback
<chrisccoulson> i need to ask on #ubuntu-x really
<slangasek> chrisccoulson: eh?  the plugins are separate X clients?
<cjwatson> steveire,YokoZar: doesn't matter which filesystem was in use anyway, usplash integration was just missing in the new mountall package
<cjwatson> as Keybuk said, fixed now
<YokoZar> ahh ok
<YokoZar> I thought there might have been a chance it just wasn't shown for ext4 since it was fast enough
<slangasek> chrisccoulson: I can confirm your understanding of the minor code, though
<chrisccoulson> slangasek - i don't think they are separate X clients. but the information about whether it runs synchronously or not is stored client side in the Display structure (i think), which might not be shared between plugins
<slangasek> chrisccoulson: hmm, that would be weird
<chrisccoulson> i'm just going to have a quick look at the xlib code, perhaps i'm misunderstanding it
 * Riddell hugs evand 
<evand> :)
<cjwatson> dpm: would you mind sorting out bug 363990 in LP and letting the translator know about the problem? it's the same as bug 409785, except for Hebrew
<ubottu> Launchpad bug 363990 in language-selector "gnome-language-selector crashed with TypeError in check_status()" [Undecided,New] https://launchpad.net/bugs/363990
<ubottu> Launchpad bug 409785 in language-selector "gnome-language-selector crashed with TypeError in check_status()" [High,Fix committed] https://launchpad.net/bugs/409785
<cjwatson> I'm annoyed that msgfmt --check-format doesn't catch this
<dpm> cjwatson, sure, on it
<cjwatson> I've checked other languages, it's just Arabic and Hebrew
<slangasek> bwuh, seriously, msgfmt --check-format doesn't catch that?  are the strings properly marked as format strings?
<cjwatson> yes, python-format
<cjwatson> I think it gets confused by plural forms
<cjwatson> or else its python-format handling sucks, I haven't checked ...
 * slangasek nods
<tseliot> amitk: let's see if doko knows what happened
<tseliot> doko: http://pastebin.ubuntu.com/297390/ (see the end of the file)
<tseliot> doko_: any ideas??
<doko_> tseliot: look at the sanity check
<tseliot> doko_: but reinstalling the nvidia package fixes it, right amitk?
<tseliot> which is weird
<Keybuk> not for the first time, I think we should generate a quiet noise on the sound card when there's hard-drive activity for SSD
<evand> haha
<amitk> tseliot: not this time. It didn't fix it with a reinstall
<tseliot> amitk: maybe try reinstalling the compiler instead. As doko said, the CC sanity check failed
<tseliot> well, as the dkms log said ;)
<amitk> tseliot: my compiler seems to work (just tried compiling some trivial programs)
<tseliot> doko_: ^^
<amitk> tseliot: in any case I've filed bug 456240
<ubottu> Launchpad bug 456240 in nvidia-graphics-drivers-180 "package nvidia-185-kernel-source 185.18.36-0ubuntu8 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [Undecided,New] https://launchpad.net/bugs/456240
<tseliot> amitk: ok, thanks
<zul> asac: ping
<dpm> ArneGoetje, re: bug 363990 and bug 409785, I see in the template's admin page that language-selector still has the checkbox for using language packs checked. If I understand it correctly, this will override cjwatson' fix, since the language pack translations will be used instead of the package's ones, won't they?
<ubottu> Launchpad bug 363990 in language-selector "gnome-language-selector crashed with TypeError in check_status()" [Undecided,Fix released] https://launchpad.net/bugs/363990
<ubottu> Launchpad bug 409785 in language-selector "gnome-language-selector crashed with TypeError in check_status()" [High,Fix released] https://launchpad.net/bugs/409785
<asac> zul: hi
<asac> zul: .symbols?
<zul> yep
<asac> zul: what info do you need?
<zul> how to do it basically
<asac> zul: cdbs?
<asac> zul: DEB_DH_MAKESHLIBS_ARGS = -- -c4
<asac> and add an empty .symbols files for your lib
<zul> that it?
<asac> i think that should make it fail and dump a patch with the symbols that you need to put in there
<asac> remember to remove the ubuntu revisions from the versions it chooses
<zul> ok thanks
<asac> zul: for cdbs thats it. yes.
<hadess> asac: way to work upstream
<hadess> asac: you were waiting until when to send me those gnome-bluetooth patches?
<seb128> lol
<asac> hadess: until i have time to argue
<asac> hadess: i will rebase and submit the rest
<seb128> I was ready to bet that was going to happen ;-)
<seb128> hadess, you know by being aggressive on bug reports etc you don't invite people are quickly drop a change your way
<asac> hadess: actually, i try to be a good upstream citizen :)
<hadess> seb128: aggressive on bug reports?
<seb128> hadess, and getting things nicely described in proper format etc can take a bit you don't always have when you are in a hurry
<hadess> asac: why do you ship 4 or 5 non-upstreamed patches?
<asac> hadess: for networkmanager for instance, i didnt add a single patch this cycle
<seb128> hadess, you tend to rant when the patch is not using proper git format, or the description lacks something you would have wanted to see there, etc
<hadess> seb128: you must have me confused with somebody else
<seb128> hadess, that's probably it
<hadess> seb128: i rant like that on shared-mime-info bugs, because there's a lot of work to be done on whatever reports we get
<hadess> and it's funny that i seem to have no problems working with other people either...
<hadess> anyway, i'm waiting for your updated patches
<asac> hadess: it was a deadline thing. usually i submit everything while doing. this one is an exception
<hadess> sconklin: what's up
<seb128> hadess, I don't think I've problem working with you, I just said I would not add a patch in a hurry on something you maintain
<seb128> hadess, you expect the submitter to do his side of the work which is fair but can take a bit
<sconklin> hadess: hi! it's been awhile, good to see you again
<asac> hadess: one reason also is that i did them after the .1 release - and i didnt think there would be a new .2 before we release so i lowered prio on that
<asac> hadess: will do better and give you the rest asap, ok?
<hadess> seb128: don't you think it would be better if you upstreamed the patch and marked it as needs-work instead of holding it back?
<asac> thats a mood point imo. nobody is holding patches back here. really
<jono> hadess, how do you feel the patches should be provided?
<hadess> asac: whether you were holding them back on purpose or not isn't the point
<jono> it seems that they were not purely because of time constraints
<jono> this just seems a miscommunication
<asac> in this case it was clearly a time constraints ... i did them as a side-job while working on other stuff
<hadess> asac: and now you're going to have a hard time rebasing them
<asac> hadess: yes, thats the pain i bought by not following up
<hadess> given that a good bunch of patches went in upstream
<jono> maybe a middle ground is for asac to just make his raw patches available and then rebase them when things are easier time-wise
<jono> particularly as we are a week from release
<jono> would that be acceptable, hadess?
<asac> thats what we do now ;)
<jono> thats what I originally thought
<hadess> asac: the problem is that you didn't do that...
<jono> hadess, can you think of a better solution, given the time constraints asac is talking about?
<slangasek> of course the raw patches are available
<asac> hadess: this one slipped through as release times are overly busy  ... more i cant say ... except that i am sorry
<asac> though i am not really sorry ;)
<asac> just see that we can work better together in future
<dholbach> pitti, slangasek: can we sync mootools from Debian? it'll make phpmyadmin installable again
<jono> hadess, would you be happy to be a little more patient with things, due to the release?
<dholbach> pitti, slangasek: do I need to go through all the release/archive-admin stuff?
<pitti> dholbach: any package that will go on DVDs or CDs can't right now
<pitti> we could sync it after RC
<hadess> jono: we have a release too, and i make a point of making upstream releases for all the distros
<pitti> dholbach: it would be better to have an RC bug for that, so that we can do it after RC and not forget
<jono> hadess, I agree, I just don't really know what the solution is when the problem is lack of time
<jono> brb call
<dholbach> pitti: hm? it's in universe
<pitti> dholbach: mono-tools is main
<dholbach> pitti: mootools!
<dholbach> :-)
<asac> hadess: this was one of the things that i also didnt have in mind. i always thought fedora releases 3 weeks or so after us ... just found out that you planned to release on 31st yesterday
<pitti> dholbach: oops :)
<asac> while talking to dcbw
<pitti> dholbach: ah, iti's a new package
<dholbach> yep
<hadess> asac: this isn't a fedora vs. ubuntu thing
<hadess> asac: this is me being pissed off as upstream for a lot of packages
<asac> hadess: ok, if its not just gnome-bluetooth i would like to help as good as i can.  if you want i can through whatever package you are upstream for and discuss all patches with you etc. ...
<pitti> hadess: understandable, but pretty much all distros (including Fedora) have shipped patches for years, so I don't see why you particularly pick on asac now when he sends a patch two days later..
<asac> hadess: is there a list of packages we should look at?
<hadess> pitti: because i've spent time fixing the exact same bug he did because he didn't send them upstream
<hadess> and i'm pretty sure his patches aren't enough to fix the problems either...
<pitti> so in the future, would it be a compromise to give a quick followup on the upstream bug "I have a fix for this, will send in two days"?
<asac> hadess: right. as i said above. i thought there was no way you would do a .2 release - that was the misjudment that led me to lower the upstreaming prio a bit, which made this fall off from radar and duplicated work.
<asac> shit happens
<pitti> so that you at least know about it?
<hadess> asac: why didn't you ask me instead?
<asac> hadess: instead of what?
<asac> instead of misjudging?
<hadess> pitti: that would certainly be better, although stuff like git-bz makes it easy to upstream patches
<dholbach> pitti: need a bug for mootools?
<hadess> asac: instead of not asking...
<pitti> dholbach: at it now
 * dholbach hugs pitti
<asac> hadess: i havent use git-bz ... i guess that would have helped me to not not upstream them instantly. will check that out. tahnks
<dholbach> rebooting - brb
<hadess> asac: git bz file gnome-bluetooth general <commit-ids>
<asac> hadess: asking failed because of the time-constraint thing i talked about. i did this in a night shift to meet some deadline together with other stuff.
<asac> hadess: thanks. do i need to setup password?
<hadess> asac: no, you do that from your git tree, and it will read your cookies from the browser
<asac> cool
<asac> good to know
<asac> hadess: so moving forward: i rebase stuff and give the rest to you. and in future i just submit all patches using git bz ;) ....
<asac> hadess: if you want me to help you on the other packages you are upstrewam for feel free to ping me
<asac> deal?
<hadess> asac: gnome-user-share, nautilus-sendto, shared-mime-info, totem, totem-pl-parser, rhythmbox, gvfs
<pitti> gvfs> our patches are either applied in git or in bz (and were sent there even before uploading)
<pitti> so that should be clear (I'm keen myself to keep it patch free)
<hadess> pitti: good
<fatal^> talking about patches.... http://patches.ubuntu.com doesn't seem to be very up to date anymore... are there some other place to look for patches?
<pitti> hm, merge-o-matic seems to not run any more?
<pitti> fatal^: looking for a particular package?
<slangasek> pitti: correct; I asked out loud about this a couple weeks ago, nobody admitted responsibility
<slangasek> (and the page lists no contact information)
<fatal^> pitti: not really.... I usually dig stuff out of the packages themselves, but it'd be nice if there was a more convienient way.
<cjwatson> Keybuk and doko are the contacts for merge-o-matic, AFAIK
<pitti> fatal^: for packages which we have in revision control, it's usually easier to pick them off the web UI
<fatal^> pitti: what's the url for that?
<pitti> fatal^: e. g. for gvfs: http://bazaar.launchpad.net/%7Eubuntu-desktop/gvfs/ubuntu/files
<pitti> -> debian/patches
<fatal^> thanks
<pitti> fatal^: https://code.launchpad.net/~ubuntu-desktop/ has all the GNOMEish packaging branches
<Keybuk> drwxrwsr-x  2 merge merge       4096 2009-09-10 13:05 .lock
<Keybuk> huh
<Keybuk> it's running
<Keybuk> oh
<pitti> stuck perhaps? running for over a month?
<Keybuk> yeah, read that date the wrong way round ;)
<Keybuk> right, it was locked out
<Keybuk> looks like IS locked it out after a reboot but then never re-enabled it
<Keybuk> BAD IS
<Keybuk> (given nick is in wtmp at that time ;p)
<EtienneG> happy 5th anniversay of Ubuntu to everyone!
<dholbach> thanks pitti
<dholbach> paulliu, lool: glad to see the moblin bits are in
<lool> dholbach: We're going to close the remaining syncs as it's too late for them to be processed
<lool> (too risky)
<lool> we'll just live with what we have now
<dholbach> hm, they're in universe and new packages - it's not like they'll cause regressions
<paulliu> dholbach: the problem is.. OEM team have to update moblin stuff before this week. So I've done it in Debian unstable first. If we sync those packages to too new versions we'll break.
<dholbach> ok
<hadess> asac: and i fixed more killswitch bugs and did another release just to spite you...
<kirkland> slangasek: erg, yes, probably it was missing an FFe.  I see it's been approved now.  Basically, the previous version we had was DoA (sync'd from Debian mentors in the interest of getting more testing on Karmic).  Finally, lucas just uploaded a working version to Sid.  I just figured it was worth a shot trying to sync that to Karmic.  If it was declined, I wasn't going to complain.
<slangasek> kirkland: "If it was declined" - cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-October/000634.html
<slangasek> kirkland: it's assumed that universe packages that have been uploaded are supposed to be there
<kirkland> slangasek: thanks
<slangasek> well, that means I noticed it because it generated a bunch of sudden NBSes and needed NEW processing :)
<asac> hadess: ok. not sure why you have to spite me though ... if it helps ;)
 * asac on a call now
<hadess> asac: that was supposed to be a joke
<hadess> asac: but i'm pretty sure that your patches aren't enough to fix the bugs i just fixed
<asac> ok thanks. will check out what you did and see if there is anything left to rebase
<superm1> slangasek, well for some of those bugs, the behavior was already reverted in ubuntu5.  i'll check with dtchen as for what he expects for the others
<slangasek> superm1: ok, thanks
<free> pitti, mathiaz: hi, bug #444743 is still not fixed, any blocker for the acceptance of the smart SRU in intrepid-proposed (see also bug #347983)
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable (https://launchpad.net/bugs/444743/+text)
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 503: Service Unavailable (https://launchpad.net/bugs/347983/+text)
<free> ?
<mathiaz> free: it's in the unapproved queued: https://launchpad.net/ubuntu/intrepid/+queue?queue_state=1&queue_text=
<mathiaz> free: waiting on the ubuntu-sru team to review the change
<free> mathiaz: I see, thanks for the pointer
<LaserJock> cjwatson: so it seems like the F4 menu misses several options on the Edubuntu DVD and I think on the Ubuntu DVD as well
<LaserJock> cjwatson: the .seed files are present and the gfxboot.cfg has entries, but the menu options don't appear in the end
<cjwatson> LaserJock: did you remember to select "Install in text mode" or whatever it is before pressing F4?
<cjwatson> LaserJock: the options in gfxboot.cfg, inc. LTSP, only apply to certain main menu items
<LaserJock> ohhhhhh
<cjwatson> if you press F4 directly at boot, you'll get those options suitable for the selected main menu item
<LaserJock> bah
<LaserJock> I'm an idiot
<LaserJock> let me go verify
<dtchen> superm1: in terms of alsa-utils, they're fine at Fix Released; they may need separate tasks for pulseaudio, etc.
<LaserJock> cjwatson: yep it's there, I'm an idiot
<dtchen> siretart: that's probably a good idea
<LaserJock> although it's not necessarily intuitive that the menu would be context sensitive
<superm1> dtchen, so does pulseaudio at some point call alsactl store?
<superm1> it's not clear what that flag is still used for since the pulseaudio stuff was reverted from ubuntu4 to ubuntu5
<cjwatson> LaserJock: I'm not entirely certain it's intuitive, but OTOH I'm not certain how it could be done better :) anyway it's not unique to Edubuntu
<LaserJock> cjwatson: no, and we can document it
<LaserJock> cjwatson: once you realize what it's doing, it's actually rather nice
<LaserJock> cjwatson: we wouldn't want people selecting LTSP and Ubiquity at the same time
<dtchen> superm1: err, there shouldn't be any flag at all, and no, PA doesn't invoke alsactl store, though it does sync its ctl status with ALSA's hw ctl status
<dtchen> superm1: perhaps I'm confused about which flag you're referring to?
<superm1> dtchen, http://pastebin.com/f7f047be9
<pitti> free: sorry, will catch up on SRUs after TB meeting; last week was a bit crazy due to karmic release
<dtchen> superm1: that flag isn't used anymore; it's not even present
<superm1> dtchen, well your upstart changes that backed it out were not accepted this late, not sure if you saw that
<superm1> so this is the smaller delta to back out just that flag stuff
<dtchen> superm1: yes, I'm aware. In the current ubuntu6, it's fine as-is.
<superm1> dtchen, ah i didn't realize that got pulled out of unaccepted already - that's my mistake.
<superm1> so what's the best approach to ensure that those other bugs closed from ubuntu4 and ubuntu5 don't see regressions from this?
<ccheney> shtylman: thanks
<dtchen> superm1: they won't AFA alsa-utils is concerned. Any problems must be in pulseaudio.
<superm1> dtchen, okay thanks
<slangasek> smoser: should we post the 20Oct uec build as an RC candidate?
<smoser> slangasek, i think so. http://uec-images.ubuntu.com/karmic/20091020/
<smoser> slangasek, but i did just now tag bug 407949 as targetted to karmic
<ubottu> Launchpad bug 407949 in ec2-init "ec2-init: ec2-set-defaults needs better defaults for non US/EU regions" [Medium,In progress] https://launchpad.net/bugs/407949
<smoser> slangasek, i need guidance on exactly how much grief there will be for requesting that change (possibly post RC if we choose to use the ones there).
<smoser> the source change is very trivial
<slangasek> smoser: I've cleaned up the make-web-indices integration for uec overnight; does http://uec-images.ubuntu.com/karmic/20091020/unpacked/ now look the way you think it should, is anything missing?
<smoser> http://pastebin.com/f35e24c27
<smoser> that has patch
<ccheney> slangasek: i will need to do another upload (if possible) for bug 452518, just got the patch last night, what do you think about when to do it? as an update or directly after RC, etc?
<ubottu> Launchpad bug 452518 in openoffice.org "table, numbering and image error when saving .doc file" [Critical,Incomplete] https://launchpad.net/bugs/452518
<slangasek> smoser: the next step is that I'm going to try to integrate populating the "EC2 published AMIs" table from a text file
<ArneGoetje> cjwatson: language-support-LL just pulls in the other language-support-{fonts|input|writing}-LL packages if available. This one exists only for upgrading. Language-selector won't install that package anymore, but the other language-support-{fonts|input|writing}-LL packages directly when the corresponding checkboxes are checked.
<slangasek> ccheney: how long does an OOo build take on armel these days?
<smoser> slangasek, so one thing to note is that as it is right now, the publish to ec2 occurs after checksum-dir is run
<ccheney> slangasek: last build took 18 hours
<james_w> ogasawara: hey, is the "ECC is not currently enabled in the BIOS" bug pattern needed due to kerneloops?
<ccheney> slangasek: oh no, 1 day 19 hours
<ccheney> slangasek: misread when it finished
<ttx> smoser: about bug 407949 > you nominated for karmic in "Ubuntu on EC2" project, not "Ubuntu", want me to fix that ?
<ubottu> Launchpad bug 407949 in ec2-init "ec2-init: ec2-set-defaults needs better defaults for non US/EU regions" [Medium,In progress] https://launchpad.net/bugs/407949
<jdong> out of curiousity, what are the armel builders? Real ARM systems or some sort of emulator?
<ogasawara> james_w: it is
<slangasek> ccheney: yeah, no way that's going in in time for RC.  If the kubuntu folks think this is urgent to have before release then we can shove it in after RC, otherwise SRU
<james_w> ogasawara: does it need to be a WARN_ON in the code?
<ccheney> slangasek: ok
<smoser> ttx, yeah. please.
<ogasawara> james_w: I'd need to check
<james_w> ogasawara: I would think that would be a better way to avoid the message
<ogasawara> james_w: agreed
<james_w> granted, it may not be the best way to do it at this point
<slangasek> smoser: I don't see a reason that it needs to be done in that order?
<ccheney> Riddell: opinions of when to do bug 452518, it causes files to be saved in the wrong format and in the instance of the bug report not save certain types of data in the file (apparently saved in a really old version of the format)
<ubottu> Launchpad bug 452518 in openoffice.org "table, numbering and image error when saving .doc file" [Critical,Incomplete] https://launchpad.net/bugs/452518
<ogasawara> james_w: I'd consider it a bandaid for now
<james_w> but to stop users getting that every boot just to be told "you can't report this" would be good
<james_w> ogasawara: thanks for being on top of it :-)
<Riddell> ccheney: after RC (Thursday afternoon) would be good then
<ccheney> Riddell: ok
<smoser> slangasek, it is just how it is right now. a build happens, and then another cronjob notices that there is a new build that isn't published.
<slangasek> smoser: do we care about having the daily build pages link to EC2 AMIs though, or do we only care for milestones?
<ArneGoetje> dpm: language-selector translations should not go into langpacks, no. I remember I have disabled theat before... no idea who enabled it again.
<smoser> slangasek, i think it would be nice if they did. so if we can make the header "generate header" such that it can be called once, and then again later , that would be really nice.
<smoser> the "again later" would just be when the publish-to-ec2 had finished. i could have it call the generate header, which would pick up the published-ec2-nightly.txt
<slangasek> smoser: in that case, I think it would make more sense to integrate it into a single cronjob
<siretart`> dtchen: I just wonder, since kubuntu doesn't use pulseaudio, wouldn't that break libao application under kde?
<ScottK> ccheney: Yes please (on fixing that).  I had that bug, but the doc in question wasn't one I could attach to a bug report.  Fixing that would be huge.
<pitti> free: done now
<slangasek> ogasawara: could the weather report pick up http://uec-images.ubuntu.com/karmic/current/karmic-uec-{amd64,i386}.manifest?
<free> pitti: awesome! thanks
<ogasawara> slangasek: yup, gimme a minute and I'll get it updated
<pitti> free: sorry for the delay
<slangasek> ogasawara: thanks!
<ccheney> ScottK: ok
<free> pitti: np
<smoser> slangasek, so you'd want the cronjob that did the build to finish only when build and publish and HEADER generation were done
<slangasek> smoser: yes
<smoser> i dont know why i dont like that :)
<slangasek> smoser: since each action is really dependent on the earlier actions anyway, there's not much point to having separate cronjobs... that just introduces a race condition
<slangasek> I don't know either :)
<smoser> but it would not be that hard to integrate it.
<smoser> there isn't a race condition
<smoser> the last thing done is 'link current' and the watcher only looks at current
<dtchen> siretart`: yes, that's why many of these settings were left at 'alsa'
<dutchie> is there an official opinion re: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/404435?
<slangasek> smoser: well, that's still a race in the sense that if the latest build hasn't finished yet, you get the old one published instead
<ubottu> Launchpad bug 404435 in update-manager "Bad spelling/grammar about ARMv6" [Low,In progress]
<dutchie> (specifically https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002752.html)
<dtchen> siretart`: in light of release, it doesn't make sense to bump it; I don't know of any libao apps that break because 'alsa' is used
<smoser> slangasek, well, thats covered. i will admit to a sub-second race condition, though.
<smoser> the race you're  mentioning is not an issue though.  the publisher script marks that its working on a dir with the $(readlink -f dir) name. and marks that it finished that also.
<smoser> i can take your suggestion to wrap it all up
<siretart`> dtchen: sure. I'm not going to touch it, but rather wanted to confirm my understanding of the issue here
<smoser> then the output will have publish-nightly-ec2.txt in it when you take over
<ArneGoetje> asac: mozilla looks translated to me, however it reports the version of the translations as 3.5.2 although I uploaded 3.5.3 already into Rosetta.
<smoser> slangasek, should we sign published-ec2-nightly.txt ?
<slangasek> smoser: I don't think that matters
<smoser> it contains the ids.
<smoser> a tampering with that file could allow someone to get their amis run appearing to be ours
<slangasek> smoser: except people are generally grabbing them from the header anyway, which isn't signed
<slangasek> if they're concerned about it, they can go directly to the AWS website, no?
<slangasek> indeed, we give them links right to the site
<smoser> they can definitely verify that 'canonical' published an image
<ScottK> Is the site https?
<smoser> so, slangasek, you can assume then that when a build finishes the output looks like it does for 20091020
<slangasek> smoser: ok, great
<smoser> it is not, but s/http/https/ works. so we should do that.
<smoser> slangasek, what script are you running ?
<slangasek> smoser: for what part?
<ScottK> smoser: I worry that without https and an appropriate cert, DNS cache poisoning attacks could still be used to give people wrong images.
<slangasek> smoser: for the header generation, it's make-web-indices - I've added a call to build-ec2-image
<smoser> ScottK, you're correct. so we absolutely should change the link to use the https
<smoser> right? that would calm your concerns ?
<smoser> its just a matter of 's/http/https/'
<ScottK> smoser: With an appropriate cert, I think so.  I'd ask kees to make sure
<kees> smoser: https with a valid cert is fine
<kees> smoser: that may need IS support, though, since www.ubuntu.com isn't https
<smoser> ah.
<smoser> sorry, i missed the point of ScottK's objection.
<smoser> the uec-images is not https available with valid cert. the amazon site is.
<pitti> ogra, lool: oh, how come that UNR is just 680 MB nowadays? I thought it was almost 1 GB before
<ogra> pitti, .iso restriction
<ScottK> smoser: Do you have it now?
<pitti> ogra: I thought it was supposed to be just installed from USB sticks
<ogra> not anymore, since karmic it should be installable from CD as well
<smoser> yes. i see what you were saying. and i dont hav ea solution for 'uec-images.ubuntu.com' is not https
<ogra> there was apparently demand
<pitti> mat_t: bdmurray_ says that the beep on the mini 9 is gone with yesterday's live images; can you confirm on current karmic?
<mat_t> pitti: thanks, will try to confirm it later today
<mat_t> pitti: will let you know!
<mat_t> :)
<pitti> mat_t: cheers
<bdmurray_> mat_t: also in alsamixer there is a beep option which might be the cause
<mat_t> bdmurray_: ok, I'll check it out, thanks1
<mat_t> !
<ogasawara> slangasek: ok, uec should be on the weather report now
<slangasek> ogasawara: thanks
<lool> pitti: We switched to ISO and went to make sure it fits the 700 MB bill
<lool> pitti: As some people even run it on regular laptops
<pitti> lool: nice; how painful was that? (I'm just curious)
<lool> Since UNR is supposed to have a lighter stack, it made sense to target 700 MB
<pitti> it's nice to be able to download/rsync it much faster now
<lool> pitti: For some reason it wasn't too bad; after I cleaned up the seeds to match the desktop we were already in the same zone, usually a bit higher than desktop; not sure why we're doing so good (it's suspicious!)
<lool> We did drop things like openoffice help IIRC
<lool> We miss things like brasero or the VNC stuff
<lool> xsane
<lool> and gimp and gdm-guest-session
<lool> I bet gimp saves us a lot
<lool> pitti: Basically excluding things which were expected to be unusable on the typical netbook made a big difference I guess
<pitti> lool: makes sense; thanks for the heads-up!
<pitti> lool: gimp is 6 MB (without documentation), but with docs it's like 20
<pitti> but indeed it doesn't make much sense to have by default on a netbook
<lool> pitti: I suspect gimp pulls a bunch of things
<lool> At some point it even pulled webkit  ;)
<pitti> you managed to keep webkit off the image? nice
<dholbach> Keybuk: did you get anywhere with the vserver people?
<Keybuk> dholbach: they made a karmic template that worked for them
<dholbach> oh, is that documented somewhere?
<dholbach> do you think we should get it into the release notes?
<Keybuk> I'll defer to slangasek on that one
<smoser> slangasek, so did we leave that you would put the ami from http://uec-images.ubuntu.com/karmic/20091020/published-ec2-nightly.txt into iso tracker ?
<lool> pitti: Oh no we did not
<lool> pitti: I mean gimp is a hog
<Keybuk> dholbach: certainly you can't upgrade a current vserver to karmic
<Keybuk> you have to start over with a new template
<lool> webkit is pulled by empathy so no luck there
<dholbach> Keybuk: ugh
<slangasek> dholbach: yes; can you open a bug on the ubuntu-release-notes project and suggest some text?
<Keybuk> (unless you can switch templates? I don't know much about vserver)
<slangasek> smoser: I think so?
<Keybuk> dholbach: you have to change your vserver to be one that actually has an init daemon
<dholbach> slangasek: no, I can't - I have no clue about how it gets fixed
<Keybuk> - then you need to disable things like /etc/init/udev.conf, /etc/init/mountall.conf, etc.
<dutchie> is there an official opinion re: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/404435?
<dutchie> (specifically https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002752.html)
<Keybuk> - and you need an /etc/init/vserver.conf that has initctl emit lines for the events that mountall makes
<dholbach> Keybuk: right, so the text should advise people to get in touch with their ISPs and restart the servers afterwards
<ubottu> Launchpad bug 404435 in update-manager "Bad spelling/grammar about ARMv6" [Low,In progress]
<lool> dholbach: moblin remix is built from universe + ppa; if we push a version which forces a library transition on us, we're screwed
<smoser> slangasek, so, please do that. (not meaning to nag, just didn't know if it was lost)
<Keybuk> (you probably need more for X to start too)
<dholbach> lool: ok
<lool> dholbach: (It's very fragile to build from universe + ppa)
<Keybuk> dholbach: if we're going to *have* release notes text, it should probably tell the ISPs what to do too :p
<dholbach> Keybuk: right
<dholbach> Keybuk: did anybody of them made notes about the config changes?
<slangasek> smoser: ec2 done
<ScottK> pitti: You may recall a private bug I filed against apport that you redirected to gdb.  I'm not comfortable with making the bug public, is there someone I should subscribe to it to give it a better chance of being looked at?
<mvo> dutchie: this is just about karmic vs 9.10 ? fixing it now is a bit of work as it quires manual unfuzzing the strings
<dutchie> mvo: though it'd be something like that
<pitti> ScottK: ubuntu-dev perhaps?
<ScottK> pitti: Thanks
<mvo> dutchie: given that very few people are likely to see it, I'm inclined to just leave it as it is
<slangasek> smoser: are we going to use the same filename, "published-ec2-nightly.txt", for the actual milestones?
<dutchie> mvo: Shall I mark it as Fix Released then?
<slangasek> smoser: oh, n/m, you cover this in the wiki
<Keybuk> dholbach: no idea
<Keybuk> dholbach: in the words of your boss, I give negative shit about vserver ;)
<smoser> right.
<dholbach> Keybuk: I realise :)
<dholbach> :-(
<dholbach> I'll try to find out
<dholbach> this sucks
<smoser> slangasek, i originally did not have the '-nightly' in it, but then when i went to publish a named release from a nightly dir, i realized i would overwrite the existing file (or refuse to do it becaues that file existed)
<mvo> dutchie: that is best I think
<slangasek> smoser: "daily" would've been more friendly to the existing scripts which all use this label, but no mind, I'll roll with it :)
<mvo> dutchie: we may need the string again for lucid, but IIRC there was no arm port in hardy, so hardy->lucid upgrades will not be a problem
<smoser> we can change that easily enough.
<dpm> ArneGoetje, I remember we discussed at the platform sprint that we could use langpacks for language-selector after release, but I don't remember having enabled it myself
<ScottK> mvo: You recall correctly.  No armel in Hardy
<smoser> almost certainly i can sed -i with 's/nightly/daily/'
<dpm> ArneGoetje, I remember we discussed at the platform sprint that we could use langpacks for language-selector after release, but I don't remember having enabled it myself
<asac> ArneGoetje: rosetta is not used for those that have .xpis ... remember?
<asac> ArneGoetje: what i wanted to verify is that the 1.9 and 3.0 lang packs are finally gone
<asac> and dont show up in the addons manager anymore
<asac> ArneGoetje: can you give an ack on that?
<rgreening> o/
 * rgreening sendds greetz from winnipeg
<asac> ArneGoetje: they were still left in last rounds -base packs
<slangasek> smoser: can we go with just "daily" and "release", then?
<asac> the idea was that they go away completely after the last full export
<smoser> you mean ditch 'milestone' ?
<slangasek> smoser: I don't think that at this level, we care about what kind of milestone it is - that just means more code I have to write to find the filename
<slangasek> smoser: whereas if it's daily vs. release, that matches the existing args to make-web-indices
<mvo> thanks ScottK
<smoser> ok. so that file, you want named as publish-ec2-daily.txt or publish-ec2-release.txt ?
<slangasek> smoser: yes, please
<smoser> you're ok with distinguishing 'milestone' other places (like the bucket names) , right?
<smoser> because we expect to leave those around, i'd like to separate them (in a sorted list) from actual releases... the 'milestone' bucket did that.
<slangasek> smoser: yes, certainly
<slangasek> (I don't see any mention of buckets on https://wiki.ubuntu.com/UEC/Images/Publishing, fwiw; does this correspond to "LABEL" there?)
<smoser> ok. then i will rename nightly to daily, and smash 'label' in publish-ec2-<name>.txt to fit daily/release.
<smoser> slangasek, in NamingConvention
<smoser> a beta/rc/alpha go into bucket named ubuntu-images-milestone-us
<smoser> a release goes into ubunt-images-us
<smoser> well, spelled correctly hopefully.
<slangasek> spelling is ovreraetd
<smoser> but label there is 'beta' or 'rc' or 'alpha1'
<smoser> the resultant published filename has that in it.
<ArneGoetje> asac: ack
<asac> thx
<asac> now i can sleep again ;)
<slangasek> smoser: http://uec-images.ubuntu.com/karmic/20091020/ updated now with the AMI table; not sure why this table renders differently from the one you had before, though
<smoser> slangasek, looks fine to me. i had copied and pasted some stylesheet stuff to get what was there.
<smoser> slangasek, it really looks great. thank you for your work on it.
<slangasek> smoser: well, I copy pasted the same stylesheet stuff from you, but it looks different :)
<smoser> oh well. who are we to question firefox's authority
<slangasek> anyway, if that looks ok, I think we have something now that we can use for publishing the RC
<smoser> i think so.
<smoser> so when we publish as RC, we'll:
<smoser> a.) copy 20091020 dir to 'rc' dir
<smoser> b.) publish to ec2 as 'rc'
<smoser> c.) make-indices
<smoser> d.) remove published-ec2-nightly
<smoser> probably swap c and d order
<smoser> anything else ?
<smoser> slangasek,
<tseliot> Keybuk: is there a patch which allows Moblin's  X "not to clear the screen until the desktop appears", as you said? If so, where can I find it?
<slangasek> smoser: actually, I was going to wire up publish-release to be able to do a-c for me
<slangasek> smoser: but not until after I get some sleep, I'm afraid
<smoser> thats fine. what do you mean by 'publish-release' ?
<smoser> is that another cdimage script ?
<slangasek> smoser: cdimage/bin/publish-release
<slangasek> yep
<smoser> awesome. i'll look at that. thanks again.
<slangasek> smoser: sure - thank you!
<slangasek> smoser: there are a handful of package updates that apply to UEC for RC: http://qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/uec-amd64.html - I think we should reroll the images / AMIs for this
<smoser> i'm ok with that. but then i have to ask if i can sneak in one other.
<slangasek> smoser: ok?
<smoser> ec2-init for bug 407949
<ubottu> Launchpad bug 407949 in ec2-init "ec2-init: ec2-set-defaults needs better defaults for non US/EU regions" [Medium,In progress] https://launchpad.net/bugs/407949
<slangasek> smoser: sure; get it uploaded and we can push it in
<smoser> i have to test the patch here, but i is viewable at http://bazaar.launchpad.net/~smoser/+junk/ec2-init.karmic/revision/33
<smoser> ok. let me run the test first although it surely seems like it should be fine to me.
<slangasek> smoser: I need to go get some sleep now; if pitti or cjwatson are around when you have ec2-init ready, please prod them about accepting it; in the meantime, I think the images that have been posted should be smoke tested
<smoser> slangasek, i just booted one, so at very least it boots in us / i386
<ArneGoetje> @core-devs: could someone please sponsor bug #409813 for me? Thanks!
<smoser> soren, ping
<asac> bug 409813
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/409813)
<smoser> soren, http://paste.ubuntu.com/297648/ or zul i'd appreciate your sanity check on that patch.
<smoser> i just tested in both ec2 and uec
<smoser> but just want to be sure.
<zul> smoser: looks sane
<tripzero> why doesn't ubuntu kernel maintainers include the tuxonice patches?
<jdstrand> mdz: fyi, bug #455832 is a regression from jaunty (I wasn't sure you got server team bug mail, so mentioning it here)
<ubottu> Launchpad bug 455832 in libvirt "segfault when attaching disk with same physical device" [High,Won't fix] https://launchpad.net/bugs/455832
<jdstrand> mdz: it also isn't limited to AoE, but seems any physical device (ie /dev/sdc)
<jdstrand> s/physical//
<mdz> jdstrand: thanks, please tag it as such
<jdstrand> mdz: since it is marked as "Won't Fix" for karmic, I'll add regression-release
<mdz> jdstrand: ok
<smoser> pitti, or cjwatson ping per slangasek's comment above. I've attached debdiff (bzr diff) at http://launchpadlibrarian.net/34061675/bug407949-catch-exception.diff to bug 407949 and requested sponsorship.
<ubottu> Launchpad bug 407949 in ec2-init "ec2-init: ec2-set-defaults needs better defaults for non US/EU regions" [Medium,In progress] https://launchpad.net/bugs/407949
<pitti> smoser: looking
<pitti> smoser: so ec2.get_mirror_from_availability_zone(availability_zone)
<pitti> smoser: won't need the same treatment?
<smoser> i put a comment there to that affect, but no.
<smoser> http://paste.ubuntu.com/297660/
<smoser> thats what it looks like.
<pitti> smoser: or is the try/except just meant to catch missing entries in ec2.location_locale_map?
<pitti> smoser: ah, good
<pitti> smoser: thanks, uploaded
<pitti> lool: accepting mobile-meta, since the images need a respin anyway for casper
<smoser> pitti, thank you.
<smoser> so, how do I know when that reaches archive ?
<smoser> i will respin UEC images at that point.
<pitti> smoser: we need to respin ubuntu server images with that as well, I guess?
<smoser> ubuntu server does not include ec2-init. only UEC.
<pitti> ah, good
<pitti> smoser: how about
<pitti> wget -q -O - http://archive.ubuntu.com/ubuntu/dists/karmic/main/binary-i386/Packages.gz | zgrep -A 10 'Package: ec2-init'|grep ^Version
<pitti> smoser: and check that it is 0.4.999-0ubuntu4
<pitti> then it should be ok
<smoser> pitti, thanks.
<dupondje> could some developper please check https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<dupondje> its such an extremely annoying job :
<dupondje> :(
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/391035)
<dupondje> nobody ? :(
<lool> pitti: we don't use mobile-meta in any image I think
<kees> pitti: what is the state of builders, I have a 3rd attempt at a jaunty kernel build coming in soon.  is there a preferred time for it?
<pitti> kees: fine from my side, we are rebuilding images for RC now, and have everything we currently need; I'd appreciate if you could just build one at a time, so that we keep one buildd for doko_'s maven efforts and possible emergency rebuilds; does that work?
<kees> pitti: it's just jaunty this time, the others are done.  i can't control per-arch builds.
<pitti> kees: per-arch isn't necessary; I meant one source building at a time
<pitti> kees: if it's just jaunty, that's fine
<pitti> thanks for coordinating
<kees> pitti: yeah, just jaunty.  thanks!
<pitti> smoser: new ec2-init is on the master archive (cocoplum), but not on archive.u.c. mirror yet
<pitti> smoser: where do you build the EC2 images? on antimony?
<smoser> nectarine is in data center
<smoser> its view of archive.u.c has it
<smoser> so i'll start them. thanks for the ping.
<pitti> smoser: right, please do verify the version there; I suppose it has a local mirror as well?
<pitti> smoser: our cdimage server (antimony) doesn't have it yet either
<pitti> so it might be in limbo on syncproxy
<smoser> i verified from nectarine with what you suggested above.
<smoser> so i think it should be good. it'll be a 10  minutes or so anyway before i start this.
<zul> how do I add testcases to the iso testing wiki?
<eviljussi01> +could anyone explain to me the rational for removing libstdc++5 from the karmic repos?
<geser> eviljussi01: it was carried over from Debian: Debian bug #536776
<ubottu> Debian bug 536776 in ftp.debian.org "RM: gcc-3.3" [Unknown,Closed] http://bugs.debian.org/536776
<eviljussi01> geser: right. thats really sad :( Im noticing several things that depend on it. :/
<dupondje> who can I contact for aptitude bug ?
<dupondje> did a bugreport
<dupondje> and seems like I found the fix for it
<zul> pitti: is it normal to have postgresql-8.3 and postgresql-8.4 installed at the same time when you are upgrading from jaunty to karmic?
<pitti> zul: yes; you should get a debconf note that 8.3 is obsolete, and instructions how to upgrade
<zul> pitti: ok just making sure
<pitti> we can't do db upgrades during dist upgrades
 * mneptok and co. are a few days from upgrading the MySQL universe :)
<dupondje> pitti: can I stalk you for the bugfix ? Its a quite annoying bug in aptitude, and got it fixed now. Would be great if it was fixed in Karmic
<dupondje> bug: https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<pitti> dupondje: please subscribe ubuntu-main-sponsors if you have a fix; sorry, I don't have time right now (busy with doing the RC release stuff)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/391035)
<dupondje> k
<avb1> guys, why there is so many dependencies to libgnome2-0 and libgnomeui-0? accordning to http://www.gnome.org/~fpeters/299.html only gnome-panel should depend on it
<avb1> ok, seems there is only gdm
<dholbach> avb1: if you look at http://www.gnome.org/~fpeters/299.html there's a bunch more for LibGnome and LibGnomeUi
<avb1> yes, in others :)
<avb1> most important is that gdm should not depend on it
<avb1> im wrong, /usr/lib/gdm/gdm-user-switch-applet depends on it
<pitti> smoser: please tell me when images are ready, and I should add them to the ISO tracker; or can you do that yourself?
<smoser> i will need help on that.
<smoser> i just started a build. its minimum 1 hour before everything is done and published to ec2, pitti
<pitti> smoser: ok, I think I can stay awake for another hour
<jdstrand> kirkland: fyi-- fta asked my about this in #ubuntu-mozillateam. is a failed install for an XP guest via virt-install/virt-manager/libvirt a priority for karmic? see bug #456602
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456602)
<kirkland> jdstrand: if someone has a tested patch, that I can eyeball, test, and sponsor, I'll gladly take it
<kirkland> jdstrand: but I'm in documentation mode at this point
<jdstrand> kirkland: this is a regression. can you add the appropriate karmic Won't Fix task, and add regression-release? this did work in jaunty and will like need to be in the release notes
<jdstrand> kirkland: I would do it myself, but since I am not the one making the call, it seems more appropriate for someone else to do it
<dupondje> I have a patch ;) tho not for that problem ;)
<kirkland> jdstrand: done
<wasabi__> NIce. Ya'll are coming to visit me this year (Dallas.)
<wasabi__> See that? "Ya'll". Get used to it.
<chrisccoulson> slangasek - would you mind trying to get an xtrace log of your g-s-d crash at some point (although you're probably quite busy at the moment ;))
<smoser> pitti, i'm sorry but it appears like its going to be another 30 minutes. build is going, publish to ec2 still running.
<smoser> i'd guess around 21:00 UTC you'll see http://uec-images.ubuntu.com/karmic/20091020.1 populated.  the file published-ec2-daily.txt will have the AMIs you need. (the format is like http://uec-images.ubuntu.com/karmic/20091020/published-ec2-daily.txt and you are concerned with the first 4 lines)
<pitti> smoser: sorry, I killed my X, had to reboot; were you saying anything to me?
<smoser> :)
<smoser> i'd guess around 21:00 UTC you'll see http://uec-images.ubuntu.com/karmic/20091020.1 populated.  the file published-ec2-daily.txt will have the AMIs you need. (the format is like http://uec-images.ubuntu.com/karmic/20091020/published-ec2-daily.txt and you are concerned with the first 4 lines)
<pitti> smoser: I still see the "[22:45:00] i'd guess around 21:00 UTC you'll see..."
<smoser> thats all.
<pitti> smoser: ah, ok; I was afraid I missed something before that, since that didn't include a highlight
<smoser> there was something before it, but the above is good
<pitti> ok, will poll for that and add to iso tracker when it appears
<pitti> smoser: so those are ec2 ami US/Europe i386+amd64
<pitti> smoser: is there a different place for "server UEC"?
<pitti> or shouldn't these be added?
<smoser> yes, the published-ec2-daily.txt contains the ec2 {eu-west-1,us-east-1}/{i386,amd64}
<smoser> for "server UEC" i think just reference 20091020.1 (and that url i posted with that number in it above)
<pitti> ok, thanks
<smoser> pitti, http://uec-images.ubuntu.com/karmic/20091020.1/ is updated.
<smoser> just use the information in the ec2 table
<smoser> have a nice night. i have to run now, and thank you for your patience.
<pitti> smoser: ok, that's UEC?
<pitti> smoser: no ec2?
<pitti> ah, I see
<smoser> at that link, there is a table of ec2 info
<smoser> ok.
<pitti> I'll just use the same build number then
<smoser> apparently slangasek made the published-ec2-daily.txt file not shown in the index.
<pitti> smoser: added
<smoser> thanks.
<smoser> pitti, i'm looking
<smoser> http://iso.qa.ubuntu.com/qatracker/build/ubuntuserver/all
<smoser> in the past, that has had the AMIs in paren for ec2 . ie, ami-8e5c77fa
<pitti> smoser: hm, I don't know how to do that, I'm afraid
<smoser> well where did you put the AMIs ?
<pitti> smoser: nowhere; I can just state a build ID
<pitti> s/ID/timestamp/
<pitti> like 20091020.1
<smoser> and it woouldn't take an ami there ?
<smoser> i think steve was just putting the ami there before. for the ec2 and for the UEC using the timestamp
<smoser> but maybe i'm wrong
<pitti> smoser: check now, that better? (added amd64 europe)
<pitti> it doesn't have a build timestamp any more, though
<smoser> yeah, i think thats what steve did before
<smoser> its fine.
<smoser> thanks again. i have to run now.
<smoser> have a good night.
<pitti> all updated
<pitti> bye!
<rickspencer3> g'night pitti
<pitti> oh, that was supposed to go to smoser
<rickspencer3> ;)
<seb128> siretart, hey
<seb128> siretart, do you know if anybody is working on libdvdread?
<seb128> siretart, there is a frequent crasher but there seems to be no active upstream there
<seb128> siretart, bug #435968
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/435968)
<seb128> ^ or if anybody knowns ;-)
<chrisccoulson> slangasek - i figured out why your g-s-d trace doesn't look right
<siretart> seb128: TBH: no idea, I didn't follow libdvdread lately...
<seb128> siretart, ok thanks anyway
<chrisccoulson> there is no call to _XReply in XRRSetScreenSize (which I'm sure is the call that generates the error), so you will never catch any errors synchronously on that call anyway
<chrisccoulson> the error will always be caught on the next call
<chrisccoulson> which is a pain :-/
#ubuntu-devel 2009-10-21
<slangasek> chrisccoulson: ok; so it's not synchronous, but does it still give us enough information to fix?  There can't be too many calls to XRRSetScreenSize in the code :)
<chrisccoulson> slangasek - there won't be many calls to it, but it would be good to get an xtrace log to see what parameters are being passed in the call
<slangasek> chrisccoulson: ok, I'll find the time somewhere to do an xtrace run; probably will be after RC
<chrisccoulson> i'm just looking at the very limited randr documentation for RRSetScreenSize, and it says this: "All active monitors must be configured to display a subset of the specified size, else a Match error results"
<chrisccoulson> but that doesn't say much. i think i'll have to just look at the server code instead
<slangasek> smoser, pitti: "in th past, that has had the AMIs in paren for ec2" - did that not work right on the first pass?
<slangasek> pitti: yes, we use the AMIs instead of the datestamps for EC2 on the tracker because that's the unique identifier within EC2 and how testers locate it (in theory you could re-bundle the same UEC image more than once for publishing to EC2, so the datestamp isn't unique)
<slangasek> chrisccoulson: anyway, to fix this properly, wouldn't libxrandr have to be fixed to make RRSetScreenSize /check/ for that Match error (_XReply)?
<chrisccoulson> slangasek - _XReply is for fetching the response back from the server (and also fetching the errors). However, it looks like the server doesn't actually give a response for RRSetScreenSize, and I assume this is why there is no call to _XReply there
<slangasek> ah
<chrisccoulson> libxrandr (and libx11) generally doesn't check returned errors either - it is up to the applications to trap the errors and deal with them appropriately
<chrisccoulson> in this case, the error goes untrapped because g-s-d is not expecting it
<smoser> slangasek, i think we got it worked out.
<slangasek> smoser: well, if it didn't publish right the first time, I'd like to understand why, since I need those scripts to work when I go to publish the RC on Thursday :)
<slangasek> superm1: mythbuntu candidate images are up; no known RC showstoppers remaining anywhere, please test
<slangasek> cody-somerville, luisbg, TheMuso: xubuntu, ubuntustudio are also up
<smoser> slangasek, everything worked fine.
<slangasek> smoser: ok, so pitti just didn't know to look at the table?
<smoser> slangasek, pitti just didn't know that we wanted the AMIs to appear as the "release"
<smoser> so at first he put 20091020.1
 * slangasek nods
<smoser> everything worked perfectly otherwise.
<smoser> as a point of reference, full build and publish took 95 minutes
<smoser> publish is about 65 of that i think. something around there.
<slangasek> smoser: ok, thanks - I'll be sure to schedule accordingly
<smoser> slangasek, but also remember that we can publish ahead of time, and just not set public
<smoser> setting public takes < 1 minute
<smoser> so if these RC candidates are going good, we publish them to RC but keep them private, then at "release time" we just flip them to public
<slangasek> smoser: right; I still have to remember to do the publishing far enough in advance :)
<smoser> once published as private we even have all the ami/aki/ari ids.
<smoser> yeah, theres almost no real reason to not do that right now
<smoser> as we can just delete private ones with no harm
<cjwatson> we do that kind of pre-publishing with the ISO images too
<cjwatson> different implementation but same goal
<smoser> slightly different implementation :) full of a lot less slop
<cjwatson> what I mean really is that there's already a "pre-publish stuff" slot in the schedule, to an extent
<smoser> right.
<TheMuso> Hrm. Is it known that usplash doesn't pulsate when asking for the encryption passphrase, or is that what is wanted now?
<TheMuso> Seems not.
<avb> guys, new bugfix release of a webkit is out
<avb> hope its not too late for an update
<avb> also can somebody update midori to 0.2?
<sladen> avb: https://wiki.ubuntu.com/KarmicReleaseSchedule  upstreamversionfreeze was a little while ago (Ubuntu is releasing in a week and a half!)
<avb> sladen: but as i know during this time its still allowed to upload minor updates, no?
<avb> issue is that 1.1.15.2 contains couple bugs which leads to crash and cosing some usability problems which was fixed in 1.1.15.3
<avb> this is just a bugfix release, no new features of code changes was introduced
<avb> all is kept for 1.1.16
<porthose> avb, then submit a FFe https://wiki.ubuntu.com/FreezeExceptionProcess good luck :)
<avb> porthose: thanks for a link
<avb> ill try
<avb> porthose: same policy goes for universe as well?
<porthose> they are different for main and universe read the doc :)
<avb> yes, i see now :)
<ajmitch_> as long as it's just bugfixes, you have a chance of getting changes in
<RPG_Master_> I had an Idea and the guys in #ubuntu-offtopic suggested I tell everyone here
<RPG_Master_> <RPG_Master_> When you go to make a file Public, Ubuntu should ask "Which are you going to be sharing this with, Windows or Linux?" Then decide which to install, gShare or Samba
<RAOF> RPG_Master_: Why not just unconditionally install samba?  What does setting up a FTP server & advertising it via zeroconf get you over just setting up a CIFS share?
<RPG_Master_> RAOF: It's FLOSS....
<RAOF> So's samba.
 * RPG_Master_ is 15 with no coding experience
<RPG_Master_> :/
<RPG_Master_> sorry for waisting your time :(
<RAOF> No problem.
<RAOF> It's not a waste of time if it ends up being interesting :)
<RPG_Master_> RAOF: so there is no benefit over Samba?
<RAOF> It probably has fewer buttons to tweak.
<RAOF> But I don't think it's got any obvious advantages, no.
<RPG_Master_> I just kinda assumed because samba is based off of a Microsoft product there must be a better way of doing file sharing...
<RAOF> Not really.  CIFS works.
<RPG_Master_> RAOF:  Well, thanks. At least I learned something :P
<RAOF> There's plenty of useful, good, Microsoft technology.  Just because it's Microsoft's, doesn't mean it's bad :).
<slangasek> samba isn't based off a Microsoft product; it's protocol-compatible with Windows filesharing
<RPG_Master_> Ah, so it was just used by Windows?
<slangasek> the protocol isn't even Microsoft's, it's IBM's ;)
<RPG_Master_> :P
<slangasek> (with a few decades of embrace-and-extend piled on...)
<RPG_Master_> Which is why its good :P
<RAOF> slangasek: Heh.  You learn something new every day :)
<RPG_Master_> RAOF: really :P
<slangasek> RAOF: somewhere there's a history of the fact that when Samba was getting started, it was because Tridge wanted to use it for connecting to *Unix* machines; then someone came along and said "oh hey, this works with Windows too!"
<spm> I miss some of the features that decnet had that went walkies when nt3 etc came out. ms-net v1 was embraced and extended by all sorts of companies.
<spm> gah. s/decnet/pathworks/
<RPG_Master_> Well then, we should change the name of the network folder to, say "Network Folders"
<RPG_Master_> :P
<RPG_Master_> Instead of Windows Folders
<RPG_Master_> Wait
<RPG_Master_> *Windows Networks
<slangasek> true, we should
<slangasek> I think that warrants a bug on the gvfs-backends package
<RPG_Master_> slangasek: Hey, I think I just contributed to Ubuntu :D
<slangasek> RPG_Master_: thanks :)
<RPG_Master_> Well, I am glad I could contribute *something* to ubuntu after all that its done for me... I want to hurry up and learn python so I can do more! :)
<pitti> Good morning
<pitti> slangasek: AMIs> the previous images didn't have AMIs, so I just added the build timestamps; I'm more educated now
<slangasek> pitti: morning
<slangasek> pitti: EC2 images /always/ have AMIs, they may just not have been posted there :)
<pitti> slangasek: ... in the tracker, I meant
<slangasek> (s/may just not have been/weren't/)
<pitti> yeah, I was just confused
<liw> hmm... this has happened twice now: something keeps adding a second keyboard layout to GNOME (US, in addition to my native Finnish), and then switching to it; I've deleted the US layout yesterday, and it's back today
<liw>  any suggestions?
<pitti> liw: did you have US selected in gdm?
<liw> pitti, no. the keyboard layout changed on the fly, suddenly, in the middle of typing
<liw> (not that I know of, that is; if it's US there, I didn't choose it)
<liw> (stupid US keyboard layout, not fit for humans ;-)
<pitti> it's the best ever for programmers :)
 * pitti switched from de to us a few years back
<pitti> suddenly vim, C, LaTeX etc. were so much easier :)
<pitti> liw: anyway, could you check this:
<pitti> gconftool -g /desktop/gnome/peripherals/keyboard/kbd/layouts
<pitti> this probably has fi and us right now
<pitti> liw: reset it with gconftool -u /desktop/gnome/peripherals/keyboard/kbd/layouts
<liw> produces [fi] but since I've already removed the extra layout, that is not surprising
<pitti> then log out, back in, and make sure that you select fi in gdm
<pitti> liw: or just keep it as it is, and log out/in with fi selected in gdm
<pitti> does either of those add us/
<pitti> ?
<liw> why does it matter what I have in gdm, since it worked fine for hours?
<pitti> liw: we had a recent change in gdm which fixed the selection of keyboard layouts that you pick in gdm
<pitti> liw: it was really spontaneously added while gnome was running?
<liw> yes
<liw> er
<pitti> or it was there all the time and you just didn't notice?
<seb128> pitti, he said that the layout changed during session use
<pitti> seb128: well, that's not the same
<liw> the layout changed in the middle
<pitti> you could accidentally press both alt keys or so
<liw> I don't know if the us keyboard was there from the beginning
<seb128> pitti, right
<pitti> it doesn't prove that the new layout was _added_ to the gconf key
<liw> pressing both alt keys does not seem have an effect
 * fatal^ switches keyboard layout on both-shift .... don't know if it's the default.
<pitti> liw: system -> prefs -> keyboard -> layouts -> layout settings can set a key combination for switching layouts
<pitti> fatal^: I believe nothing is the default
<liw> hm, gdm did have us as they default layout, how stupid of it
<liw> pitti, there is no key combo defined for switching layouts
<liw> (which is good, since if there were, I would be hitting it randomly and tearing my hair out)
<liw> if I choose US layout in gdm, and log in, I have US layout
<liw> however, that's not what happened this morning: I was typing happily for hours when it suddenly changed in the middle of a word
<liw> in the middle of a word with letters with umlauts, so less than a second earlier I still had the Finnish layout...
<pitti> liw: I meant, if you chose fi layout and didn't have us configured before, do you get us configured in GNOME after that?
<pitti> so, I have no idea what could have changed the layout then, I'm afraid
<liw> pitti, yeah, it's very mysterious; I'll keep an eye on things and see if I can debug further if it happens again
<liw> (too many moving parts and layers in computers these days, and I've put more in myself: keyboard -> kvm switch -> desktop machine -> kernel -> x -> gnome -> synergy -> laptop -> laptop's x/gnome stack *sigh*)
<soren> ~[5~[5~/win 43
<soren> nice.
<seb128> the examples directory on the current iso desktop is a blank document icon, bug?
<maxb> What order do I approach people to get a fix into karmic at this point? main-sponsors then release, or the other way around?
<pitti> maxb: since it can't go into RC any more, it's best to subscribe ubuntu-release to the bug and nominate it for karmic; you can sub the sponsors at the same time
<maxb> OK, sponsors are already subbed, just wasn't sure on the protocol of when to sub ubuntu-release
<slangasek> "nominate for karmic" - dunno if you look at that, but I don't
<maxb> evidently not, since I've had it nominated for karmic for a long time, and it hasn't garnered it any attention
<slangasek> yes, anybody can nominate, so nominations are really just noise today
<maxb> Sad, but given I don't have a suggestion how to fix it, I can't really complain.
<pitti> slangasek: I do if I get bug mail through u-release subscription
<slangasek> pitti: right, but the subscription's the important thing then, not the nomination :)
<seb128> pitti, want to win quite some CD space?
<pitti> but I don't watch the nomination bug list in general, indeed
<pitti> seb128: gimme, gimme, gimme!
<seb128> pitti, seems gnome-games documentation has not been langpacked for some reason
<pitti> seb128: you're proposing to replace GNOME with XFCE?
<seb128> and that's quite some images there
<pitti> :)
<seb128> I'm running baobab on the current iso
<slangasek> replace gdm with startx
<slangasek> /etc/init/startx.conf
<seb128> it's like 10 megs of documentation, if it was in langpack we could win some
<pitti> we aren't under serious space pressure for karmic, so I woudln't throw a lot of effort on it
<pitti> but if it's cheap, why not
<pitti> (like, a no-change rebuild)
<seb128> well, I'm wondering if it's just a matter of rebuild
<seb128> but it was uploaded on september 24
<seb128> but it was uploaded on september 24 which should be after your change
<pitti> but we can only do that if we're actually going to update langpacks again
<seb128> is there any way to see from the build log if the stripper was in place?
<pitti> sure
<seb128> oh right
<seb128> pitti, http://launchpadlibrarian.net/32242856/buildlog_ubuntu-karmic-i386.gnome-games_1%3A2.28.0-0ubuntu1_FULLYBUILT.txt.gz
<seb128> ^ build log
<slangasek> are we assured of having time to get the translations back into the final langpack export for release if we do that?
<seb128> hum
<seb128> "pkgstriptranslations: gnibbles does not contain translations, skipping"
<seb128> weird
<seb128> oh, translations, dog
<seb128> doh
<seb128> ignore that
<pitti> slangasek: the condition for that is that the langpack build is started after gnome-games finished to build on at least one arch
<pitti> (it doesn't go through Rosetta, it's just parked in soyuz)
<seb128> well it's not worth bothering if we don't have anything to put on the CD instead anyway
<seb128> but if we could add some extra langpacks...
<pitti> ArneGoetje: did you schedule another langpack export/build over the weekend?
<slangasek> pitti: oh, really?
<pitti> seb128: yeah, it'd just be an extra langpack
<pitti> slangasek: yes, it just uses launchpadlib to grab the built stuff straight from the librarian, which has it seconds after the build finished
<pitti> so, I think we should consider updating the langpacks again independently
<pitti> and if we do that, we could just as well do the rebuild, but then only on Friday
<slangasek> pitti: doesn't that mean translators also have no opportunity to extend/fix these translations?
<pitti> slangasek: correct; at least not in Rosetta, only by patching
<pitti> slangasek: long term this should be fixed, of course
<pitti> but given how documentatino translation works right now, it's a major project
 * slangasek nods
<pitti> i. e. their po files could be imported and changed in Rosetta, but you'd have to add them to the source package
<pitti> since documentation is translated at build time
<slangasek> sure
<pitti> slangasek: and then we of course need rosetta support for "translating" images :)
<slangasek> just make sure the images are all svg, and use po4a <cackle>
<pitti> seb128: hm, I think this case is a pkgstriptranslations bug
<pitti> I don't think we should mess with it in karmic any more
<seb128> right
<seb128> we don't really need to win space now anyway
<seb128> but would be nice to fix next cycle
<seb128> pitti, do you want me to file a bug?
<seb128> in which case what do I write in the bug? ;-)
<pitti> also, _shht_ we still need some potential savings up our sleeve for further releases :-P
<seb128> lol
<pitti> seb128: "gnome-games help not stripped", and a pointer to the build log should suffice
<seb128> pitti, ok thanks
<seb128> pitti, bug #457027
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457027)
<pitti> seb128: merci
<seb128> pitti, de rien
<apachelogger> asac: what do we do about the firefox installer?
<asac> apachelogger: not sure.
<asac> apachelogger: question is what _can_ we do
<asac> apachelogger: you think you can upload a package with all .po things sedded?
<asac> for after RC?
<asac> we should definitly check with Riddell
<apachelogger> well, I could push a package with string changes, utc could probably update the existing translations to match new template
<apachelogger> dpm: ping
<dpm> hey apachelogger
<dpm> it's about the above?
<apachelogger> dpm: aye
<dpm> if you upload a new package and it contains translations and a new template, they should be imported automatically, but you can ping us to double-check
<asac> have to run some errands
<asac> bb in 2h
<apachelogger> dpm: is there some tool to export all existing pos of a package?
<dpm> apachelogger, Launchpad can do that (exporting a tarball with all PO files). As the project maintainer you should be able to do that (let me give you the link). If you can't, you might be hitting bug 425578, in which case I can do the download for you, if you like
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/425578)
<dpm> apachelogger, try this link -> https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+export (it's from the main template page at https://translations.edge.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/)
<apachelogger> dpm: thanks :)
<dpm> np
<dpm> just let me know if there is anything else I can do
<dpm> apachelogger, also, now that I've got you here, do you think you could have a look at bug 439964?
<ubottu> Launchpad bug 439964 in kubuntu-firefox-installer "Non-latin characters are turned into ? in Firefox Installer" [Undecided,Confirmed] https://launchpad.net/bugs/439964
<apachelogger> huh
<apachelogger> dpm: http://aplg.kollide.net/images/osiris/snapshot047.png
<apachelogger> i'll incorporate the fix in the upload
<apachelogger> it's a one-liner anyway :D
<dpm> apachelogger, awesome, thanks
<seb128> hum
<seb128> is the "use the full disk to install" supposed to create a swap too?
<seb128> I got a "swap mounting failed" dialog asking if I want to change the partitions or continue
<cjwatson> seb128: it should create a swap partition
<seb128> cjwatson, http://people.canonical.com/~seb128/install.png
<seb128> cjwatson, any hint on how to get details about the issue?
<wolfe> wonderful
<wolfe> seb128: check the logs?
<cjwatson> blink, that's weird
<seb128> wolfe, what log?
<cjwatson> seb128: /var/log/syslog, /var/log/partman
<seb128> cjwatson, thanks
<seb128> invalid argument error
<cjwatson> or 'ubuntu-bug ubiquity' from inside the live environment, after exiting the installer
<seb128> swapon: /dev/sda5: erreur de lecture de l'entÃªte de zone d'Ã©change (swap)
<seb128> and the error is "invalid argument"
<seb128> cjwatson, ok, will open a bug, thanks
<cjwatson> "read swap header failed"
<wolfe> seb128: interesting..
<wolfe> seb128: you are using a new hard drive? what brand?
<cjwatson> (on something that's just been mkswapped)
<wolfe> also, is the swap at the very end of the hard drive?
<wolfe> I had an issue which was fairly common in certain hard drives where the space assigned didn't match the actual physical capacity. I'd receive such an error when it tried to read/write to the hard drive space which didn't exist.
<wolfe> or your hard drive could be going bad as well. :)
<cjwatson> or it could be an installer bug
 * cjwatson is happy to blame hardware but not as a first resort. :-)
<wolfe> cjwatson: if ithe hard drive is hitachi/ibm, I blame it first
<wolfe> or maxtor
<cjwatson> I don't, because that's a recipe for missing installer bugs until it's too late.
<seb128> cjwatson, wolfe: it's a kvm with a .img
<seb128> ie not real hardware
<wolfe> It still uses real hardware, heh
<wolfe> makes me want to ask if you're using software raid
<seb128> well I've no issue on my laptop out of that kvm install one
<seb128> doesn't mean it's not a hardware issue though
<seb128> I will retry before opening a bug
<cjwatson> if you have the logs, I'd prefer you opened a bug now before losing the evidence
<cjwatson> if it's not consistently reproducible, so be it, maybe we'll have to close it
<seb128> cjwatson, bug #457099
<ubottu> Launchpad bug 457099 in ubiquity "installation failed on swapon invalid argument error " [Undecided,New] https://launchpad.net/bugs/457099
<seb128> cjwatson, do you need any extra details before I try again?
<cjwatson> seb128: a detailed description of how you got into this situation, from kvm disk initialisation, would be good :)
<cjwatson> seb128: it looks to me as if, when you started up this instance of the installer, kvm was unable to recognise the previous swap partition as a swap partition; I wonder if that's related
<cjwatson> err s/kvm/libparted/
<cjwatson> seb128: also can you reproduce the error with 'sudo swapon /dev/sda5' from the command line?
<doko__> bug 436617
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/436617)
<seb128> cjwatson, ok, I added a comment to the bug, the kvm img I used had issues (ie wouldn't boot after a recent update) so maybe it's corrupted, I was expecting the use full disk to just reset it and make a clean install but maybe it's wrong expectation
<cjwatson> I think that is a sound expectation
<cjwatson> normally speaking anyway
<seb128> cjwatson, the desktop seems frozen after some gstreamer codec install though so I can't try the swapon, I will reboot the image
<rio> hi, i just came across a bug, that has been reported 2 years ago, but it's still unassigned, what is going on? :S
<rio> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/91389
<ubottu> Launchpad bug 91389 in network-manager "Support for more than one VPN simultaneously" [Wishlist,Confirmed]
<seb128> cjwatson, right, a swapon gives the same issue, the swap partition is screwed
<cjwatson> rio: too many bugs and not enough developers
<rio> :( i might check out the source and see what i can do next week
<seb128> example-content should really have an icon the the Examples desktop entry
<seb128> the white paper icon on karmic looks weird
<seb128> cjwatson, anything else required on this swap issue before I redo the partionning manually to workaround the issue?
<cjwatson> seb128: no, I don't think so
<seb128> cjwatson, ok thanks
<Keybuk> swap issue?
<seb128> Keybuk, corrupted swap partition breaking ubiquity install
<Keybuk> ah
<seb128> I though that a take over disk install would redo partitions too
<seb128> but apparently it doesn't
<seb128> and breaks on trying to swapon the corruption swap there
<seb128> corrupted
<cjwatson> it *does* redo the partitions actually, I can see that in the log
<seb128> weird that the partition is still corrupted then
<cjwatson> maybe not hard enough, or maybe there's a bad block under the .img file and nothing is noticing, or something; but it's definitely trying
<asac> apachelogger: so you found a solution?
<Keybuk> cjwatson: thought
<Keybuk> cjwatson: ssh shouldn't cache IP address hosts thingies for .local names
<Keybuk> sladen: about?
<pitti> Keybuk: hi
<pitti> Keybuk: are you okay with the proposed solution in bug 428435? (comment 50)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/428435)
<Keybuk> pitti: no, that will only lead to data corruption
<Keybuk> and frankly, screwing around with partition detection this close to release is a BAD IDEA
<pitti> I'm open for better suggestions
<pitti> but given that vol_id behaved like that since hardy at least, it seems to be the safest option right now
<pitti> I don't think we can squeeze in a proper migration solution at this point?
<Keybuk> why bother with a migration solution?
<Keybuk> this is one of those bugs that'll bite hard
<Keybuk> because you'll stop detecting valid ext4 partitions as a result
<seb128> hum
<seb128> ubiquity hates kvm there today or something
<seb128> I did rm the .img, created a new one using kvm-img and I still get install failure
<pitti> Keybuk: no, we don't
<pitti> Keybuk: migration> because you dist-upgrade your server and then it can't boot any more; not good
<pitti> Keybuk: if there was a case where mkfs.ext4 over luks ever left enough traces of luks, this would have broken in hardy
<Keybuk> we never migrated any other filesystem type this way
<Keybuk> there are numerous "my filesystem was fat and is now ext4" type bugs since hardy
<Keybuk> I just tell them to go away
<pitti> correct
<pitti> but so far we tolerated exactly that for luks-over-ext
<pitti> and karmic is the very first release whose cryptsetup behaves correctly finally
<pitti> (cf. the looong discussion we had in #u-release this morning with slangasek)
<Keybuk> this is surely fixable with a quick perl script, no?
<Keybuk> to zero the bits of the superblock that luks doesn't use
<pitti> I 100% agree that cryptsetup was buggy, and that blkid should behave the way it does now
<Keybuk> sounds a lot less hairy than rewiring blkid, with all the unexpected consequences you can cause
<pitti> but we can't go from "four releases broken" to "we reject existing installs" without at least offering some help to affected users
<Keybuk> sure, but wouldn't that help be better if it was help to fix their broken filesystem image
<Keybuk> rather than just carrying on honouring it
<pitti> sure
<pitti> that's why we proposed to do exactly that for lucid
<pitti> I don't want to keep that blkid behaviour forever
<Keybuk> right, but why not do it for karmic?
<pitti> -EINTRUSIVE?
<pitti> it needs carefully engineered/tested initramfs scripts at least
<pitti> which wouldn't even address broken USB sticks, etc.
<Keybuk> err
<Keybuk> you don't have to do that
<Keybuk> you can just have it available and give it to anyone affected
<pitti> and not just initramfs (for root), but also in mountall (for encrypted /home etc.)
<Keybuk> this is a lot less intrusive than major rewiring of our filesystem detection library
<pitti> Keybuk: you still need the logic to detect that at various places, like initramfs, init script, dk-disks/gnome/etc.
<seb128> cjwatson, I did apport-collect on https://launchpad.net/bugs/457099 for installation breaking using a new kvm-img just created do you think it's the same issue?
<seb128> cjwatson, ie local disk issue or something?
<Keybuk> you're saying that a quick perl script for anyone effected by the bug is somehow worse than rewriting code which can have unforseen consequences
<pitti> Keybuk: since right now it just silently breaks
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457099)
<pitti> Keybuk: it's not unforeseen; it just restores the behaviour that we shippped for several releases
<Keybuk> pitti: no you don't; we don't have that logic for any of the other problems
<Keybuk> pitti: you're not understanding me
<Keybuk> blkid is *complex* code
<Keybuk> this is not a one line fix
<Keybuk> in previous releases we had *different* code
<Keybuk> it's not a matter of reverting a patch, or porting a patch
<pitti> well, I wrote a thorough test script and am just looking into the code
<Keybuk> you would have to make some fundamental changes to blkid
<slangasek> Keybuk: a "quick perl script" is a lot less helpful to the affected users, most of whom will discover the problem only after rebooting to karmic, and if they have any partitions that get decrypted post-initramfs, they won't even be able to boot the old kernel to recover
<Keybuk> pitti: does your test script cover any cases that do not include luks or ext4?
<Keybuk> slangasek: it's a lot better than (say) breaking everyone who uses lvm right before release
<pitti> see bug; I tested luks/ext[234]/swap/vfat; I don't want to touch behaviour of everything except luks
<Keybuk> changes to blkid tend to have that effect
<Keybuk> pitti: that's my point
<Keybuk> changes to blkid tend to affect everything
<pitti> right, that's my intention :)
<Keybuk> one minor change to one prober has unforseen knock-on effects on the other probers
<slangasek> bleh, why is blkid this brittle?
<pitti> we'd fix initramfs/boot/dk-disks all at the same time
<Keybuk> slangasek: because what it's doing is brittle
<pitti> with the "if you see luks, stop detecting" change (pretty much what vol_id did)
<Keybuk> slangasek: it is examining a block device for a unique signature
<pitti> also, we have an internal test suite, now an external test script, and an image which reproduces this problem from a user
<Keybuk> I don't care about fixing the problem, and testing that the fix is successful
<Keybuk> I care about everything else you break in the process
<pitti> well, that's pretty much what already happened; new blkid breaks systems which worked before
<slangasek> Keybuk: but it's the *existing* behavior that consists of "if it matches more than one prober, curl up in a ball and rock in the corner"; how can any possible change be more brittle than the current behavior? :P
<pitti> and while admittedly they were broken to begin with, that makes little difference to upgraders who suddenly have a broken installation
<pitti> slangasek: well, if you detect two you might pick the wrong one and destroy data
<Keybuk> slangasek: that code is there for a reason
<pitti> but we already discussed that for this reason we shoul djust restore the "luks > everything else" special case
<pitti> since we know that luks was broken in the past
<Keybuk> take the FAT vs. ext4 issue
<slangasek> pitti: the proposal to change blkid at all is predicated on the notion that we it's possible to know what the right one is
<Keybuk> if you accidentally pick FAT when it was ext4, you screw the ext4 filesystem
<Keybuk> if you accidentally pick ext4 when it was FAT, you screw the FAT filesystem
<pitti> sure
<Keybuk> the problem is, over time, we tended to favour one or the other
<pitti> we all agree on those
<Keybuk> and then realised we were just bouncing between two different equal sized groups of people
<slangasek> Keybuk: yes, it's there because upstream punted by generalizing from cases where there's no right answer
<pitti> Keybuk: I doubt that they are equal-sized for luks/ext
<Keybuk> there are just as many people who mke2fs over a FAT filesystem (hard drive installs) as those who format ext disks as FAT (usb keys)
<pitti> Keybuk: I already demonstrated that ext* has not had that problem for years
<Keybuk> pitti: luks/swap is pretty common
<Keybuk> pitti: as is luks/anything else lvm
<pitti> whereas our isntaller used the broken cryptsetup since at least gutsy
<primes2h> mvo: Hello, could you have a look at this bug #344693 about update-manager please? :)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/344693)
<Keybuk> slangasek: if you think blkid's behaviour is wrong, then supply patches to fix it, and an address to receive all the bug reports ;)
<Keybuk> and promise that you will fix them all
<slangasek> nobody promises to fix all bug reports :P
<Keybuk> it comes with a free life-long contact with Ted Tso ;)
<slangasek> how about: I think its behavior is wrong, so I'll write a scathing blog entry ;)
<pitti> Keybuk: we did not say that blkid's behaviour is wrong
<Keybuk> pitti: going back through LP, LUKS vs. swap is the favourite case
<pitti> well, at least I don't say that
<slangasek> pitti: heh, I did
<Keybuk> slangasek: haha :p
<Keybuk> I think he already did
<mvo> primes2h: I have seen it. it requires unfuzzying a lot of translations
<pitti> Keybuk: my point is just to keep it wrong for karmic, to avoid having to rip apart several places to deal with the fallout
<cjwatson> seb128: it looks the same, but I haven't debugged it yet. What kvm-img format are you using, out of interest?
<Keybuk> pitti: and my point is, due to way the code works, I don't think it's easy to keep it wrong without causing more problems
<seb128> cjwatson, just "kvm-img create karmic.img 6800MB"
<seb128> cjwatson, whatever default format that is
<cjwatson> ok, I've been using -f qcow2 myself
<primes2h> mvo: do you mean we are not in time to do this because the tomorrow deadline?
<Keybuk> pitti: you'd certainly have to reopen the dozen or so "my swap partition is detected as LUKS" bugs
<mvo> primes2h: timming is not ideal. I wil try to get to it today
<primes2h> mvo: ok, thank you very much indeed. :)
<mvo> primes2h: I requested a LP export now for the unfuzzing
<Keybuk> slangasek: OOI, how do you think it should work?
<slangasek> Keybuk: given that no LUKS partition *can* be activated without external configuration telling how to decrypt it (i.e.: /etc/crypttab), I think in all cases it's safe to prefer LUKS over * if the alternative is returning no UUID at all
<lilli> hi
<liw> is it a policy decision that the ubuntuone-client* packages get forcefully added upon upgrade from jaunty?
<Keybuk> slangasek: but then that would you get bugs like "I reformatted by old LUKS partition, and it's still detected as LUKS" :)
<pitti> liw: that's the case for every upgrade; ubuntu-desktop dependencies determine what gets newly installed
<lilli> I was looking to create a bot that automatically runs debuild... How can I force debuild to be executed without asking anythings?
<Keybuk> or, more annoyingly
<Keybuk> "I repartitioned my disk, and a LUKS signature just happens to be at exactly the wrong point, and /usr doesn't mount"
<pitti> Keybuk: but that just means that the other mkfs is _also_ broken
<pitti> Keybuk: and if it is, it'd be broken with current blkid as well
<Keybuk> sure, this is exactly why we punted this problem to the mkfs tools
<Keybuk> hmm
<slangasek> Keybuk: "and /usr doesn't mount" - that doesn't seem to be a regression over the current behavior, though
<Keybuk> though I think slangasek is partially right here
<Keybuk> at least with crypto filesystems, there's no danger of mounting as the wrong type and having the mount succeed
<Keybuk> which is what the code is trying to guard against
<liw> pitti, even for recommends? that's pretty suboptimal :(
<Keybuk> in that case, it fits in with RAID
<Keybuk> (also no danger)
<pitti> liw: recommends are pretty much dependencies, yes; and a lot of new stuff that you probably want are recommends as well
<Keybuk> yes, I think slangasek gets +1 insightful
<Keybuk> http://people.canonical.com/~scott/slangasek.patch
<Keybuk> ^ now that *is* a one line fix
<pitti> that's why we just want to reintroduce the luks special case, no anything else (ext4 vfs. fat or so)
<liw> pitti, I'd like a solution that lets me remove a package and not get it forced one me on upgrades, but I see the problem that our dependency tools aren't up to it right now
<jdstrand> slangasek: do I need to tag/nominate/milestone a bug in any particular way for ubuntu-release-notes to make sure you see it for karmic?
<slangasek> jdstrand: just needs to have a task open on that project
<jdstrand> ok
<slangasek> jdstrand: extra points for offering some text :)
<jdstrand> slangasek: :)
<pitti> Keybuk: hm, I had expected to set BLKID_IDINFO_TOLERANT in ./shlibs/blkid/src/probers/luks.c
<liw> other issue I had with my upgrade just now: upon first login, epiphany wanted permission to access every password I had stored, even though I wasn't accessing any sites that required passwords; a) having to answer the same question for dozens of passwords separately is a tad annoying b) why does it want those passwords in the first place?
<Keybuk> pitti: that wouldn't have worked
<Keybuk> pitti: both filesystems have to be tolerant
<pitti> Keybuk: but I guess your approach of considering usage instead of fs is nicer
<primes2h> mvo: great!
<pitti> Keybuk: oh? blkid_do_safeprobe() just treats it as a boolean (anyway, I didn't test that yet, it was just what I was about to try)
<pitti> with that patch, ./test-luks-blkid.sh succeeds again
<pitti> $ blkid -p /tmp/ext3-luks.img
<Keybuk> pitti: any intolerant detected filesystem will set intol
<pitti> /tmp/ext3-luks.img: UUID="fa583620-b1ef-448c-b4c3-7aaa794849f8" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
<Keybuk> so if you have two matches, and one of them is intolerant, you get the ambivalent result
<pitti> and it also detects the previously broken image now
<Keybuk> thus LUKS + ext4, if LUKS is marked tolerant, ext4 isn't so it'd fail
<pitti> Keybuk: ah, right, read it backwards
<pitti> Keybuk: so, with this patch it passes internal test suite and my two tests
<pitti> mkswap seems to clean up the superblocks properly, I didn't notice breakage there in karmic (but did in hardy/jaunty)
<Keybuk> ok, sent the patch upstream
<pitti> Keybuk: oh, you want to keep it permanently? I assumed it'd be a tempoprary workaround until we can offer tools to point out the problem and fix it on your partitions?
<Keybuk> it fits the pattern
<Keybuk> we break out of RAID there because you need to activate them so you can't do too much damage
<slangasek> well, this is hardly an Ubuntu-local problem, I think it ought to be upstream
<Keybuk> slangasek is right that the same applies to crypto too
<Keybuk> and the crypto probers are lumped in with RAID in that section
<pitti> Keybuk: do you want to do the upload or shall I?
<Keybuk> I'm doing it
<Keybuk> since I bet you don't have git set up ;)
<pitti> not for util-linux
<pitti> ok, thanks
<pitti> ah, no debian/patches/
<Keybuk> no, it's maintained in git ;)
<Keybuk> (one of the few cases where the Debianish Vcs header is actually correct in Ubuntu's case too)
<Keybuk> kees: about?
<primes2h> mvo: BTW, this ( bug #456115) is even worse as bug concerning translations but we are too late now I think.
<ubottu> Launchpad bug 456115 in checkbox "System Testing (checkbox) has several not translatable strings " [Undecided,Confirmed] https://launchpad.net/bugs/456115
<LaserJock> slangasek: would it be possible to get an Edubuntu rebuild today?
<slangasek> LaserJock: certainly possible, but not something I would particularly advise - what's up?
<apachelogger> asac: aye, though, I need all sorts of freeze exceptions and a trademark exception from TB, so that the installer can ship the proper logo
<tseliot> Keybuk: who can I ask about what we should/could use to set the background at boot? Does the DX team deal with this?
<Keybuk> I think so
<LaserJock> slangasek: looks like cjwatson fixed bug #452429
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/452429)
<slangasek> LaserJock: ah, right
<asac> apachelogger: pleaes open bugs on the things
<asac> so i can comment
<mvo> primes2h: you should talk to cr3 about the checkbox bug, maybe its not too late
 * apachelogger first needs to find out which freezes we are exactly in right now :D
<primes2h> mvo: ah, ok. Thanks. :)
<slangasek> LaserJock: rebuilding now
<LaserJock> slangasek: awesome, thanks
<LaserJock> slangasek: do you know roughly how long those take?
<slangasek> LaserJock: I have no estimate for how long it'll take to build, though, since cjwatson has specifically changed the type of livefs build we're doing
<LaserJock> k
<slangasek> for all I know, this will blow up horribly with an oversized livefs or something
<LaserJock> heh
<LaserJock> I hope not
<apachelogger> asac: btw, bug 439431 ... I am still thinking that conflicts&replaces from the firefox side of things would be most reliable
<primes2h> cr3: Hello, Could you have a look on this bug #456115? It's quite a blocking one.
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/439431)
<asac> apachelogger: i would just open a single bug with RC freeze exception + UI exception
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456115)
<primes2h> cr3: Re-trying bug #456115
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/456115)
<primes2h> uff
<primes2h> cr3: bug #456115
<ubottu> Launchpad bug 456115 in checkbox "System Testing (checkbox) has several not translatable strings " [Undecided,Confirmed] https://launchpad.net/bugs/456115
<asac> apachelogger: just replaces would probably work too
<asac> apachelogger: ship same .desktop file ... replace ... and when firefox gets uninstalled it reappears
<cr3> primes2h: is it simply a question of grabbing the .po files from launchpad?
<primes2h> cr3: ehm, no. po file in fully translated.
<primes2h> cr3: but those strings are not present
<cr3> primes2h: ah, let me have a look then
<primes2h> cr3: in fact there were strings present in Jaunty but missing in Karmic
<ion> keybuk: I was looking at old bootcharts from intrepid and jaunty. They all have the same characteristics, with the HDD spending most of its time seeking. (Low throughput, full utilization).
<apachelogger> asac: that however requires installer updates to match latest firefox desktop file + prevents user from using older/newer firefox packages + possibly disrupts the UI appearance of kdesudo (since that thingy will only show icon and proper name if binary name == desktop file name)
<primes2h> cr3: and there are other new strings (in Karmic) that are not present at all
<asac> apachelogger: not sure what you mean
<primes2h> cr3:  I mean in the po's.
<asac> apachelogger: we ship firefox.desktop
<asac> thats supposely always the same
<apachelogger> we do?
<asac> yes
<apachelogger> oh, I though we had like firefox-3.5.desktop and stuff :)
<asac> otherwise your panel launchers would disappear
<asac> apachelogger: the non-default firefox branches have versioned desktop files
<asac> but the default ... which is what matters -- always ships firefox.desktop
<apachelogger> well
<asac> apachelogger:  dpkg -L firefox-3.5-branding  | grep desktop
<asac> /usr/share/applications/firefox.desktop
<apachelogger> it is getitng ugly
<asac> imo it would create the user experience you want
<apachelogger> changing the desktop file name means changing the desktop file's translation domain
<apachelogger> means even more intrusive change :S
<asac> apachelogger: ah ok
<Keybuk> ion: yeah, my laptop has certainly suffered for a few releases now
<asac> apachelogger: note that down for lucid then. not sure if the bug is really that bad that it needs to be addressed
<asac> if we know we have a the right approach in lucid
<apachelogger> agreed, postpone for lucid then
<ion> keybuk: Also, changing the IO scheduler didnât help.
<Keybuk> ion: the kernel team fixed cfq in a recent update
<Keybuk> so it doesn't perform worse than deadline again
<ion> Ok
<cr3> primes2h: strange, it seems that my setup.cfg and POTFILES.in are configured properly, not sure why my .in files aren't being detected
<asac> apachelogger: cool. so file a bug about the late change and list what changes this involves .. i will comment that part of these are necessary and try to poke around to get permissions etc.
<asac> apachelogger: maybe outline how we get the translation issue resolved diligently at this point
<apachelogger> aye aye
<asac> thx a lot
<primes2h> cr3: really strange. But It should be nice to have it fixed in time for the translation deadline (tomorrow)
<cr3> primes2h: I'm still looking into it, I'd like that too
<primes2h> cr3: thanks you very much :)
<primes2h> -s
<apachelogger> asac: bug 457228
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457228)
<asac> ok commented subscribed a few folks
<asac> lets see
<janito_> hello, I am trying to build an iso using a jaunty deboostrap, the grub meny shows nicely, the kernel gets loaded but I am just dropped into the initramfs prompt, what I am missing ?
<cr3> primes2h: I found the problem, I'll be pushing my changes and submitting for an sru shortly
<cr3> primes2h: err, I mean ffe.. we're not at sru yet :)
<primes2h> cr3: Thank you very much indeed. :)
<primes2h> cr3: As soon as the new po are ready, I'm going to traslate the italian one. Thanks again.
<slangasek> cr3: submitting for an ffe> you should arrange to upload directly to the freeze queue, to save a round trip with the release team
<primes2h> cr3: ...and I'll report it to translator ML.
<dconlon> Got directed here from ubuntu-bugs, on booting X hangs at 100% cpu if an xorg.conf exists. Am here for help and can give whatever time you need to debug this. (Full updated install, xorg 1:7.4+3ubuntu7) Perhaps an issue with the fglrx driver(version 2:8.660-0ubuntu4)
<cr3> slangasek: how do I do that?
<cr3> primes2h: should I upload the .pot file separately or something, or just uploading the new package should be sufficient?
<slangasek> smoser: will you take care of ec2 prepublishing for rc, or should I make sure I get that done today?
<slangasek> cr3: sponsorship queue?
<cr3> slangasek: I'm really clueless, I was just thinking of pinging mathiaz to review which should be pretty quick
<slangasek> that's fine
<cr3> slangasek: I could even drop by his home right next to the office and pester him in person too :)
<Keybuk> kees: what package supplies restorecon?  I can't find it
<slangasek> Keybuk: policycoreutils
<primes2h> cr3: maybe uploading .pot file separately should be quicker but I'm not sure
<smoser> slangasek, i will publish to private today after rounds of testing
<slangasek> smoser: ok
<slangasek> smoser: thanks!
<smoser> no problem. i think its at the point where you *could* do it
<smoser> :)
<Keybuk> slangasek: should whatever-that-does be done for every mount?
<slangasek> Keybuk: I'm not sure
<Keybuk> no, me neither
<Keybuk> SELinux is not normally high on my "I care" list
<Keybuk> but I'm feeling generous
<primes2h> cr3: tell me when you have done please so I can go on. Thanks
<Keybuk> pitti: could apport-retracer not lookup strings in .mo files and translate files back to English?
<Keybuk> Die werzelordnersystem ist kaput
<pitti> I hope that's not actually part of a real German .po file :)
<maco> so uh what's that 2nd word?
<pitti> Keybuk: we know the locale and thus the language, we just don't know the domain or which part of the string is literal and which are macros
<pitti> Keybuk: so, could be on a best-effort basis
<pitti> maco: root file system probably
<pitti> this is not really German
<Keybuk> oh, I just made that word up
<maco> oh ok
<Keybuk> the actual bug I was looking at was in Spanish
<liw> a heuristic based on package name and some fuzzy pattern matching to do reverse translations back to English would be awesome
<pitti> a better fix would be to not translate logged messages, though
<liw> apport should then include both versions of the text, of course
<liw> pitti, but sometimes the people who read log files need them in their native language :(
<liw> (everyone should just start using Finnish for everything, that'd solve all problems)
<pitti> so, we can request a package name -> list of domains mapping from rosetta
<pitti> and try all of those domains whether we find the string
<pitti> liw: you're too late; seb128 already proclaimed French as the universal language
<maco> pitti: what about translating them but having a numerical error code? that way the user can see whats up and the triagers can look at the list of error codes?
<maco> ...or i could read liw's next line
<Keybuk> liw: there's not enough time left before the sun dies to finish a sentence
<liw> maco, numeric codes would work if all apps used them, but alas...
<liw> Keybuk, but there's always time for another portion of Bananenkartoffeln
<tseliot> liw: why Finnish? Is it easier?
<liw> tseliot, yes: I knew Finnish by 3, but I still haven't been able to learn French
<pitti> liw: Bananenkartoffeln> eww
<apachelogger> pitti: ahoy, any suggestions on how to squeeze the changed translations for kubuntu-firefox-installer in?
<Keybuk> ooh, Stollen!
<Keybuk> it's nearly time!
<pitti> yummy
<pitti> apachelogger: you could upload them directly to Rosetta right now, including teh changed .pot file (not sure whether that'll work, though)
<pitti> dpm: ^ ?
<pitti> dpm: context: we're about to change some strings in kubuntu-firefox-installer (trademark issue, no choice); can we pre-upload that to Rosetta, so that they'll be part of the langpack export tomorrow?
<tseliot> liw: French should be even more difficult to learn than Italian is (and Italian is extremely difficult to learn) as it evolved more from Latin than Italian did. Spanish is much easier
<cjwatson> mmm Stollen. Hungry now.
 * apachelogger still got no po tarball to manipulate though
<pitti> apachelogger: alternatively I can manally merge them into the langpacks after building them; should't be too hard
<apachelogger> rosetta export queue must be longish
<apachelogger> ok
<davmor2> cjwatson: don't steal hunger that's just daft ;)
<pitti> apachelogger: so perhaps just grab the set of changed .po files, tar them, and mail them to me?
<cjwatson> davmor2: Stollen is an extremely yummy kind of German cake
<apachelogger> pitti: probably easiest ... once I've gotten the po files -.-
<pitti> I use to translate that as "christmas cake"
<davmor2> cjwatson: I know I was being daft :) It stops the insanity
<pitti> apachelogger: I thought you changed them in the source?
<cjwatson> pitti: I would, but it confuses English people as Christmas cake here is very different
<davmor2> pitti: just cake works over hear ;)
<apachelogger> pitti: the pos are currently only handled in rosetta, so I need to export them first and then apply the changes
<apachelogger> or rather, rosetta needs to export them :D
<jbicha> is anyone willing to sponsor my patch for bug 440098?
<pitti> apachelogger: ah, I see
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/440098)
<dpm> apachelogger, (pitti, thanks for the background info) you could upload a tarball with the new pot file and the po files. The imports queue is nearly empty, so it should get importing quickly.
<dpm> imported, I meant
<pitti> apachelogger: LP is a little on the unhurried side since yesterday :-(
<pitti> dpm: cool, so you can actually override the .pot files from package builds? nice
<pitti> apachelogger: ^ I think that's easiest then, and avoids cluttering the translations with the next update
 * apachelogger pets lp and hopes for the best
<dpm> pitti, yes, although we tend to do it only when necessary
<jayy_123> can anyone help me solve a speaker problem running Jaunty on a Thinkpad x200? No sound...
<apachelogger> dpm: do I have bump the revision dates to override the current rosetta versions?
<dpm> apachelogger, what are you trying to do? which revision dates you mean? The ones on the PO files?
<apachelogger> dpm: yes, po revisions
<slangasek> Keybuk: for the immediate case, did you get the Spanish translation you needed or did you work around it?
<slangasek> tseliot: what's difficult about Italian?
<Keybuk> slangasek: the dpkg term log disagreed with the subject of the report
<Keybuk> so I marked it as Invalid
<slangasek> mmk
<Keybuk> after repeating the spanish text out loud in a funny voice
<slangasek> heh
<tseliot> slangasek: tenses (a lot of irregular verbs), orthography, accents, etc
<dpm> apachelogger, just a question, so I get a picture of what you are trying to do. You downloaded translations from Launchpad, have a new local template and you are trying to merge them with some other translations?
<slangasek> tseliot: <handwave> :
<slangasek> )
<tseliot> hehe
<apachelogger> dpm: more like replace all occurances of Firefox with Mozilla Firefox
 * dpm is thinking
<primes2h> slangasek: tseliot: Italian language is even difficult for Italians themselves ;)
<apachelogger> åæç¾å¾·è¥¿ç¹ <- apparently that would be my name in zh_tw :D
<tseliot> primes2h: absolutely
<james_w> I finally have a diff for bug 307019: http://paste.ubuntu.com/298363/
<james_w> it's not very nice though
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/307019)
<james_w> adds a new string, and I'm not sure we can steal translations for it from elsewhere
<slangasek> primes2h: yes, but that's just because none of y'all are raised to speak it ;)
<dpm> apachelogger, so I think it will not be necessary to bump the 'PO-Revision-Date' of the PO files, but I'd update the 'POT-Creation-Date' of the POT template (intltool, xgettext or whathever you are using to create the template should have done it automatically)
<james_w> dpm: you will know better than me the issues involved in re-using a translation from elsewhere
<james_w> dpm: I re-used the string from gnome-control-center, but I assume that I would have to use the same accelerator to use the translations verbatim?
<dpm> james_w, looking...
<primes2h> slangasek: I told you that because I AM italian ;) :D
<slangasek> primes2h: giÃ  veduto :)
<dpm> apachelogger, actually, I'm told by danilo that LP doesn't look at 'POT-Creation-Date', so you shouldn't have to worry about that, either
<primes2h> slangasek: s/veduto/visto. QED :)
<slangasek> heh
<slangasek> mdeslaur: did you mean for your http://iso.qa.ubuntu.com/qatracker/result/3266/288 test to be marked as failed?  Did you experience any bugs other than the UbuntuOne bug you listed?
<dpm> james_w, I need some context here: which src package are we talking of?
<mdeslaur> slangasek: no other bug. UbuntuOne was part of the test procedure, so I marked it as failed
<mdeslaur> slangasek: should I change it to pass?
<slangasek> mdeslaur: I consider that a pass
<mdeslaur> slangasek: ok, changing
<dpm> james_w, and which new string is added?
<james_w> dpm: "Change Password..."
<james_w> in the .ui file
<slangasek> (at the level of granularity I have in the test tracker, if every bug that disrupted a test case meant the test is treated as failed, we'd have a uselessly large amount of red)
<dpm> james_w, ah, ok, sorry, I see it in the diff, thanks
<james_w> in gnome-about-me it is the same words, but "Change Passwo_rd..."
<mdeslaur> slangasek: np
<apachelogger> dpm: too late :)
<dpm> you're too quick!
<apachelogger> unfortunately :P
<nxvl> cjwatson: is there any documentation on how to migrate from ext3 to ext4?
<nxvl> Keybuk: ^^
<apachelogger> asac, pitti, dpm: all set for upload
<pitti> apachelogger: nice; so please go ahead, upload the new PO/POT to Rosetta and k-f-i to unapproved
<asac> apachelogger: great. so it seems you know what to do?
<dpm> apachelogger -> https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+pots/kubuntu-firefox-installer/+upload
<dpm> here you can upload the tarball
<cjwatson> nxvl: ext4.wiki.kernel.org
 * jdong silently grumbles about btrfs
<Keybuk> what's wrong with btrfs?
<jdong> Keybuk: just btrfsck
<dpm> apachelogger, remember that the tarball must contain both the POT and PO files, otherwise the translations won't get imported
<jdong> the documentation clearly states it works online or offline
<jdong> running it online ended in an abort()
<jdong> mail their list, and a developer tells me btrfsck doesn't support online fsck :)
<jdong> other than that, I love btrfs.... Now if only that grub-probe "bug" is fixed....
<Keybuk> now that btrfs and dpkg are friends, I must try it again
<nxvl> cjwatson: thank you!
<jdong> I've been running it as a root fs with btrfs modules/progs built from git
<jdong> pretty decent; performance at least matches-ish ext4
<jdong> the only annoyance is grub-probe can't find the device for /
<dpm> apachelogger, (all inside the 'po' directory) ^
<apachelogger> dpm: all queued
<jdong> (debian bug 540786)
<ubottu> Debian bug 540786 in grub-common "[grub-common] update-grub/grub-mkconfig doesnt work with btrfs as rootfs" [Normal,Open] http://bugs.debian.org/540786
<cjwatson> jdong: somebody posted a patch against GRUB Legacy to the upstream list, but it'll need fairly extensive work to port to grub2
<cjwatson> I'd like to make that happen, but we're not particularly close
<dpm> apachelogger, ok yes, I can see them.
<Keybuk> we should just port grub to use blkid, clearly
<apachelogger> pitti: package uploaded
<kees> Keybuk: thanks :)
<Keybuk> kees: for?
<jdong> cjwatson: *nods* yeah, reading up on the mailing list chatter, it does seem like significant work is involved
<Keybuk> the whole bootloader-needs-to-read-the-root-filesystem problem seems like a misdesign to me
<jdong> what would be the alternative?
<Keybuk> for example, having the boot loader understand a single common and simple filesystem
<Keybuk> FAT for argument's safe
<Keybuk> and placing kernels and initrds into that
<Keybuk> that way the boot loader can load the kernel and initrd
<jdong> that does sound more reasonable
<Keybuk> and they can worry about filesystem support for the root
<jdong> I suppose grub and such already do that, just beyond.
<jdong> for some inappropriate definition of "simple" filesystem *grin*
<kees> Keybuk: not won't fixing 456942.  ;)
<dpm> james_w, if it makes sense for the accelerator to be there, I'd just put the "Change Passwo_rd..." one on the .ui file, then you can be sure that the translations also match the original string. I believe if the original string doesn't have an accelerator and the translation has one, it will not be rendered as an accelerator, so that would be the worst case. So I think the best thing to do if you want this change to be transparent to translators and us
<dpm> ers is to use "Change Passwo_rd..." in the UI file and reuse the g-c-c translation
<kees> Keybuk: but, I'd like to see it fixes -- I tried to answer your questions, can you take a look at it again?
<james_w> dpm: the issue is that _R is already used on this dialog
<Keybuk> kees: I think I'm getting a reputation when people thank me for simply not "Won't Fix"ing their bug ;)
<kees> Keybuk: you're very literal in your bug handling.  ;)
<jdong> so what's the state/future of grub legacy? Is it just that grub2 is preferred, or is -legacy in the evil, not recommended, deprecated category already?
<james_w> dpm: so I could pick another for English, but it would then be very hard to pick one for translations that didn't collide with whatever they are already using on this dialog, correct?
<dpm> james_w, correct
<james_w> dpm: so as we are so late I think I would be better going with no accelerator?
<cjwatson> jdong: nobody at all is prepared to take upstream responsibility for grub legacy, and it's just quietly bitrotting
<cjwatson> jdong: of course, bootloaders are the sort of thing that can quietly bitrot more happily than most; there's unlikely to be any harm in staying with it if it's working for you
<cjwatson> jdong: but we didn't go so far as to automatically upgrade people to grub2 on upgrade to karmic, because dealing with initial installs was hard enough
<dpm> james_w, yes, but the accelerator will then have to be removed from the strings you pick up from g-c-c
<james_w> dpm: I think I can do that without breaking them?
<jdong> cjwatson: I see; just trying to figure out the most un-evil workaround for a btrfs based rootfs; right now I have an evil wrapper script around grub-probe; figure for now maybe using legacy grub would be cleaner
<dpm> james_w, I guess so, you've got superpowers!
<james_w> dpm: I can see underscores at least :-)
<Keybuk> kees: I'm still waiting for someone SELinux-related to actually join the Upstart ML and discuss what needs to be done there
<dpm> :)
<james_w> I just wondered if you were going to tell me of a language that uses purely patterns of underscores
 * Ng wonders why a future last mount time is a failworthy event on boot
<kees> Keybuk: nothing is needed there since the initramfs handles it.  :)  but, email Caleb Case (ccase@tresys.com) if you really want to find out.
<Keybuk> kees: I think Caleb is one of those people who objects strongly to that approach
<kees> Keybuk: anyway, will it be possible to get the tmpfs-mounts-call-restorecon-before-they're-marked-mounted fix in?
<Keybuk> he was being rather rude about me at LPC
<Keybuk> (not realising I was sat behind him at the time)
<dpm> james_w, not that I know of :)
<Keybuk> kees: dunno, it's RC tomorrow - and I don't really understand the problem yet
<kees> Keybuk: well, at the time, you were pretty unfriendly about putting selinux patches into upstart.  :P
<Keybuk> kees: absolutely untrue
<Keybuk> seriously
<kees> Keybuk: did you read my reply?
<Ng> http://mairukipa.tenshu.net/fsckishard.jpg - should I file a bug about that against mountall?
<kees> Keybuk: ok, I don't know the history there, just restating what he'd expressed.
<Keybuk> exactly, he was being rude and frankly making shit up
<Keybuk> that kind of thing is not likely to make me feel like I want to deal with him
<kees> I would assume "misunderstanding something" instead of "making shit up", but ok
<kees> Keybuk: right, it's RC, but without tmpfses coming up with the right labels, SELinux cannot sanely transition files, process, etc, that use a given mount
<Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000276.html
<Keybuk> is the relevant mail
<Keybuk> err, I mean
<Keybuk> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000273.html
<Keybuk> I think I'm being perfectly polite and wanting to support SELinux in those ;)
<kees> sure, and that's Chad not Caleb, but still, I'm not trying to fix that; I want to see mountall fixed.  ;)
<Keybuk> exactly
<Keybuk> but no, I'm not going to talk to Caleb ;)
<kees> Keybuk: does 456942 have enough information to justify calling out to restorecon?
<Keybuk> kees: I'd rather include the actual libselinux library calls
<kees> Keybuk: why?
<Keybuk> because fork/exec/wait/etc. is expensive!
<kees> expensive only on machines running selinux, but I'll go check.  I suspect it involves parsing config files, etc.  one sec
<Keybuk> no, not at all
<Keybuk> because every single mount will call restorecon
<kees> no.... policycoreutils is in universe.
<Keybuk> so?
<Keybuk> I still have to fork(), still have to exec(), but also then need to deal with ENOENT :)
<kees> what?  access("/usr/sbin/restorecon", X_OK) once at the start of mountall and just don't call it.
<kees> s|/usr||
<Keybuk> still seems easier to just copy the relevant couple of libselinux calls into mountall
<LaserJock> slangasek: it looks like Edubuntu 20091021 built OK, can the iso tracker get updated?
<Riddell> evand: what is it that creates the icon on the desktop to run oem-config-prepare after an oem install?
<Ng> oh it's fsck not mountall
<Ng> blah
<kees> Keybuk: it looks like there is a lot of logic in dealing with selinux contexts...
<evand> Riddell: scripts/install.py in ubiquity bzr, line 2170
<Riddell> evand: thanks, that's bug 386099 incase you're interested
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/386099)
<elops> I have a cronjob, whose last act is to shadow a section of the filesystem with lndir.  The cronjob succeeds for the most part, but lndir mysteriously only mirrors about 10% of the target path.  When I run the lndir command standalone, outside a cron job, it works fine.  Anyone have any ideas?
<slangasek> LaserJock: done
<elops> I have it purge the contents of the target directory, and then run "lndir /srv/nfsmount /work/localcopy" so that when I run test code each day, I don't alter the data on the nfs server, but can still save files.
<elops> each morning, I find I have 2 our of 10 of the folders that exist in /srv/nfsmount populated in /work/localcopy.  I then end up running the command manually, and get what I want.
<kees> Keybuk: http://people.canonical.com/~kees/restorecon.patch
<Keybuk> kees: coding style! :p
<kees> Keybuk: sorry, was trying to follow yours -- what would you like to see changed?
<Keybuk> that's nothing like mine! :p
<Keybuk> root_hook won't ever get run though
<Keybuk> you realise that? :)
<Keybuk> you actually don't need it, mountall asserts the root is always mounted when it starts
<kees> obviously I don't.  :P
<kees> ok
<Keybuk> (since otherwise what would mountall be on)
<Keybuk> just having that access() check in main() somewhere would be ok
<elops> the line from crontab: 30 0 * * * /srv/moritzhome/dbBackup/backup.sh
<elops> any ideas here?
<kees> Keybuk: refresh the URL.  what would you like changed with the style?
<Keybuk> kees: will just manually apply
<Keybuk> (and there's a crasher bug in your code there, but :p)
<kees> Keybuk: I can commit to the bzr tree if you like
<kees> what's the crasher?  (nih is still new to me...)
<Keybuk> s'ok, just committing it now
<Keybuk> kees: nih_local things need to be set to NULL
<kees> ah-ha
<Keybuk> otherwise you free uninitialised data for some code paths
<Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/karmic/mountall/ubuntu/revision/140
<kees> heh, internal server error, but yes, thanks!
<Keybuk> yeah, keep hitting reload
<Keybuk> LP gets there eventually
<Keybuk> you missed args out of the spawn() call too btw :p
<mathiaz> slangasek: is https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview the wiki page that will be used for release notes?
<kees> you caught and earlier revision
<mathiaz> slangasek: I'd like to add a section about mysql upgrades
<elops> WHAT does absolute link type mean?
<kees> Keybuk: I had cut/pasted spawn, replaced args with NULL briefly while researching nih_str_array_add, etc.  anyway, thank you very much, now SELinux has a chance at working again.  :)  That and with a pile of policy updates for the upstartifications, but that doesn't concern anything in main.  :)
<Keybuk> it would be nice to figure out how to get selinux and upstart to co-operate
<Keybuk> but selinux people don't tend to do the 'c' word
<kees> be nice, be nice. :)
<d33d> question - are there packages I can package if I learn it?
<kees> Keybuk: afaik, it's just a matter of the core of this patch: https://lists.ubuntu.com/archives/ubuntu-hardened/2007-November/000230.html
<Keybuk> kees: except that patch is wrong on so many levels
<kees> Keybuk: i.e. selinux_init_load_policy(&enforce); with a check of return code and enforcingness
<Keybuk> because it then doesn't enforce init itself
<Keybuk> and afaict, you can't reload the policy
<Keybuk> or have different policies for different groups of services
<kees> Keybuk: ok, well, if you want, restart that thread.  as it stands, this work fine from the initramfs via the external load_policy tool.
<kees> *works
<joaopinto> is there any documentation describing the official iso's build process ?
<davmor2> joaopinto: you need to pray the iso gods sacrificing small child in the name of the cd you require and then as if by magic it arrives ;)
<joaopinto> right :P
<LaserJock> davmor2: children? I've been sacrificing lolcats, now I know why my .isos have had problems
<joaopinto> I am trying to create a base iso without the using the initrd/config from an existing cd
<ion> It would be nice if Launchpad already had the lucid milestone for Ubuntu, or whateverâs needed so that i can push changes intended for lucid to lp:~ion/ubuntu/lucid/mountall/blahblah.
<ion> s/milestone/series/
<pitti> lool: I'd appreciate if you could confirm bug 457537, so that we can go ahead with cleaning up component-mismatches
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457537)
<joaopinto> I must have squashfs-tools mismatch
<slangasek> mathiaz: no, https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes
<Keybuk> clearly I am having a bad laptop month
<highvolt1ge> Keybuk: at least it's not a bad laptop /year/ :)
<mathiaz> slangasek: thanks - I've added a section about MySQL upgrades (5.0 to 5.1 transition and MySQL cluster support)
<highvolt1ge> (like I've been having)
<mneptok> Keybuk: try a different club?
<mneptok> oh .... wait. not what you meant by "laptop" in this context.
<highvolt1ge> I guess all these laptops are burning up with all this super-fast booting
 * mneptok puts his sequinned man-pantied back in the drawer
<ion> keybuk: I split the lucid fsck change to two commits for better readability. https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/lucid
<ccheney> is lp really slow today?
<pitti> since yesterday already
<ccheney> ok i thought my internet connection was buggy
<ion> keybuk: What happened to your laptop this time?
<Keybuk> ion: spare laptop has suddenly decided it's not interested in AC power
<ScottK> It if was his netbook (mini 10v), I'd have guessed it was "touchpad finally drove hime to throw it through a window".
<Keybuk> heh
<Keybuk> no, the XPS
<ccheney> ScottK: yea the mini 10/10v touchpad is fail
<ScottK> Based on my experience with it the next two netbooks we bought here were from HP.
<ccheney> at least it doesn't have the buttons on both sides of the touchpad like some netbooks, but still not very good
<jcastro> cjwatson: I have hardware to help test bug #413135; which DVD image do I need to test, i386, amd64, or both?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/413135)
<ScottK> jcastro: I got both of the primary plasma netbook developers signed up to do my open week session with me.
<jcastro> ScottK: awesome, could you mail me like a 2 line bio and/or pics for the glossy pdf? If not they won't be in the PDF (which isn't the end of the world but I'd like to have all speakers represented)
<ScottK> OK.  I'll ask.
<ion> keybuk: When mountall says âCLEARâ to usplash, nothing seems to happen. Is someone working on that?
<mathiaz> cr3: hey - reviewing checkbox 0.8.5
<mathiaz> cr3: processors_info.py has been renamed to processor_info.py - why?
<cr3> mathiaz: that was supposed to have been done in 0.8.4, but patching seemed to have failed for that renaming
<mathiaz> cr3: well - bzr probably handled that
<cr3> mathiaz: the original motivation for changing processors to the singular form is that checkbox now reports processor information and the processor count as part of that information
<mathiaz> cr3: the debdiff show a rename before 0.8.4 and 0.8.5
<mathiaz> cr3: ok - you may wanna document that in the changelog
<cr3> mathiaz: under 0.8.4, since it was originally done upstream in 0.8.4?
<joaopinto> why does the livecd the the livecd uses syslinux instead of grub, more customization?
<mathiaz> cr3: hm no - in the 0.8.5
<mathiaz> cr3: the actual diff happens in 0.8.5
<mathiaz> cr3: at least from a package point of view
<cr3> mathiaz: not upstream though
<cr3> mathiaz: ok
<Keybuk> ion: oh, someone should fix usplash ;)
<lool> pitti: Hey
<lool> pitti: Did you work on the gnome-user-guide split?
<Keybuk> cjwatson: so, you know how we go through the dictionary looking for words beginning with 'u' to name things?
<lool> pitti: I wonder whether it's normal that langsel offers to install gnome-user-guide-en when you first launch it, yet it's not seeded
<Keybuk> I've been going through Urban Dictionary ...
<lool> slangasek: Hmm or perhaps it was you working on that gnome-user-guide split
<Keybuk> lovely word, "umaga"
<Keybuk> nice name for a project
<pitti> lool: I didn't work on that, but why is it wrong?
<Keybuk> of course, it does mean Shrivelled-up Monkey Penis in Somoan, but I think that's a minor problem
<ion> keybuk: Heh, it seems it has been reported 1Â½ years ago. Bug #215666
<Keybuk> ion: the best bugs are the old ones
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/215666)
<lool> pitti: I had a report that this gets fired on initial install of UNR, on first boot; I think one needs to do slightly more to trigger the bug though
<lool> pitti: But my impression was that we were trying to seed a full english environment
<lool> It's a bit weird to finish install and then you discover by going to your prefs that you actually lack some stuff
<lool> pitti: Even on my karmic desktop, I dont have the package and langsel offers me to fix my system
<jcastro> cjwatson: nevermind the platform is in the bug title, the instructions mailed to me weren't clear. *whistles*
<pitti> lool: that's just the same as with any other language now, though
<pitti> lool: if you want to have it by default, please feel free to seed it, of course
<lool> pitti: It's not clear to me why we seed gnome-user-guide and not gnome-user-guide-en and we also always seed the en langpack
<lool> I dont think I mind having it in by default; I guess it makes sense to have an user guide by default; I just wonder whether this is inconsistent
<lool> Or perhaps that was done on purpose to save space, I'm not sure
<pitti> lool: gnome-user-guide is "C", i. e. en_US; -en is en_GB etc.
<pitti> lool: yes, it was; also for openoffice.org-en-{gb,za}
<pitti> that saved dozens of MB
<lool> pitti: Aha
<lool> pitti: So it's fine for me
<pitti> we just install en_US by default now
<lool> pitti: Isn't langsel confused if it tries to install -en for me though?
<lool> I have LANG="en_US.UTF-8"
<cr3> mathiaz: done
<pitti> lool: hm, looks like it then
<pitti> lool: hm, it only considers languages, not countries
<pitti> lool: so for "full" english language support it's actually justified (same as GB/ZA OO.o help and translations)
<lool> Hmm
<lool> pitti: perhaps ubiquity folks would have a good understanding of what we try to obtain upon install since they maintain the code pulling langpacks etc.
<lool> I actually saw the same thing in https://bugs.launchpad.net/ubuntu-moblin-remix/+bug/457479
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457479)
<mathiaz> cr3: checkbox 0.8.5 sponsored
<cr3> mathiaz: thanks!
<mathiaz> cr3: it's waiting in the unapproved queue
<cr3> primes2h: ^^^ the new .pot file should be made available shortly
<cr3> I wonder if launchpad will grab the new .pot file automatically
<mathiaz> cr3: I don't think so
<mathiaz> cr3: the package won't be accepted before RC is released (if it's accepted)
<cr3> mathiaz: I'll upload the .pot file separately then
<d33d> Newbie question - so .deb files are packages....so when someone is "packaging" are they creating these .deb files or is that 2 separate, totally different things?
<ttx> mathiaz: hey
<cr3> primes2h: I uploaded my latest po/pot files and they're in the import queue right now: https://translations.edge.launchpad.net/checkbox/trunk/+imports
<mathiaz> ttx: yo!
<ttx> mathiaz: do you have a UEC setup available atm
<mathiaz> ttx: hm - not *right* *now*
<mathiaz> ttx: I'm in the process of having hw for it
<mathiaz> ttx: cr3 is lending me two machines until RC is released
<mathiaz> EtienneG: are you using the hw for your UEC playground?
<ttx> mathiaz: I could use some confirmation on bug 457281 and bug 457283
<cr3> ttx: mathiaz and I share a symbiotic relationship: I depend on him for checkbox and he depends on me for hardware.
<EtienneG> mathiaz, yes
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457281)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457283)
<ttx> cr3: that sounds dirty
<EtienneG> mathiaz, btw, did someone ever tested running the cc on a different machine than the clc
<mneptok> ttx: you should see their spandex suits and space helmets
<EtienneG> yo mneptok
<mneptok> EtienneG: 'lu!
<mathiaz> EtienneG: hm - eucalyptus upstream was supposed to do that IIRC
<ttx> EtienneG: I think we have a test report from the eucalyptoids in multi-component mode
<EtienneG> mathiaz, ttx, I am jut wondering about a couple details of components registration
<mathiaz> ttx: I'll have a look at your bugs once I've got my UEC up and running
<mneptok> EtienneG: it's the coldest day here in New Mexico yet. 12C!
<mneptok> >:P
<ttx> mathiaz: cool thx
<EtienneG> ttx, I am not really interested in multi-cluster, I just want to register a cc to a clc that is not localhost
<ttx> mathiaz: haven't seen nurmi today
<EtienneG> mneptok, awesome!  Think about next July when the mercury 38C
<mneptok> EtienneG: rarely that bad. 35C is max here.
<ttx> mathiaz: so we could use confirmed bugs before tomorrow's eucacall
<mneptok> EtienneG: with 0% humidity
<mathiaz> ttx: okdokioikeodoko
<ttx> EtienneG: let me dig that report
<EtienneG> mneptok, pfft!  I would rather keep my -30C!
<EtienneG> no, really!
<mneptok> OMG, mathiaz is becoming Ned Flanders.
<smoser> its funny cause its true.
<ttx> EtienneG: I just fwded you an email thread talking about multi-cluster or multi-component tests
<ttx> EtienneG: that might help
<primes2h> cr3: Many thanks! :)
<ttx> EtienneG: documentation is in progress
<EtienneG> ttx, thanks a bunch
<EtienneG> ttx, I am just looking at a single-cluster setup, (clc+walrus) -> (cc+sc) -> (nc)
<EtienneG> I am at the step where I need to register the cc with the clc somehow
<smoser> Keybuk, you around ?
<Keybuk> yup
<ttx> EtienneG: that's what they call "multicomponent" -- not that well covered in what I sent you, I admit
<smoser> Keybuk, ec2-init has a startup script that runs via sysvinit
<smoser> previously (beta) output from this script went to console (which we could then see from the ec2/uec console-grabbing tools)
<smoser> since then, it has disappeared, and i see
<smoser> etc/init/rc.conf and etc/init/rc-sysinit.conf have changes to 'console'
<smoser> in them
<EtienneG> ttx, it is a start.  I will hammer nurmi if I have any question
<smoser> we want/need  to write output to the console, how should we be doing that ?
<Keybuk> smoser: "console output"
<smoser> right, if it were a upstart config
<smoser> but it is run via rc-sysinit. i'd like to not change your config files.
<Keybuk> oh, >/dev/console ? :)
<Keybuk> it was changed as a default because of the "No console messages during boot" rule imposed for karmic by Design/DX
<smoser> yeah, i realized the >/dev/console would have worked...
<smoser> my other option is configuring rsyslog to write there and running it through logger
<smoser> but even then, i'm not sure how i would guarantee myself that rsyslog would be up
<Keybuk> that works too
<EtienneG> ttx, got my answer in the email thread you sent: ssh keys need to be manually exchanged
<kirkland> dtchen: howdy
<kirkland> dtchen: i'm trying to debug what i think is a nasty pulse audio issue, affecting kvm, libvirt, and/or virt-manager
<kirkland> dtchen: sometimes the VM guest just "hangs" while booting
<kirkland> dtchen: it looks like a sound issue to me
<kirkland> dtchen: what can I do to try and debug this?
<kirkland> dtchen: basically, if i remove the sound device from the vm, it boots fine
<kirkland> dtchen: but sometimes, when the vm has a sound device, it hangs on boot
<kirkland> dtchen: strace of kvm shows it hanging at: futex(0xbafc20, FUTEX_WAIT_PRIVATE, 2, NULL
<cjwatson> jcastro: i386
<smoser> Keybuk, so if i want to go the rsyslog route, how can i guarantee that it will be up when /etc/init.d/ec2-init runs
<jcastro> cjwatson: it'll be 10+ hours before I can get the ISO, but will do my best to test asap
<cjwatson> joaopinto: because grub legacy wasn't what you might call exceptionally reliable at booting CDs, and we didn't want to try to switch both the installed system and the CD to grub2 at once. Furthermore, the graphical menu patch to grub2 hasn't landed yet so it would be a substantial regression in terms of prettiness at the moment
<cjwatson> Keybuk: umaga> hah
<cjwatson> jcastro: 3+ hours to jigdo .template here, then most of the rest should come off the local mirror
<joaopinto> cjwatson, tks
<cjwatson> jcastro: but I'll be away all day tomorrow
<primes2h> cr3: But is it sufficient to upload po/pot files in trunk?
<primes2h> cr3: Doesn't them need to be uploaded in Karmic directly?
<cr3> primes2h: I don't know, I'm not particularly familiar with translations
<primes2h> cr3: It's better to put them in Karmic checkbox queue
<primes2h> https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+imports
<primes2h> cr3: https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+imports
<primes2h> Those are the .pos used in language packs.
<cr3> primes2h: uploaded, is that better?
<Keybuk> smoser: you can't, it's started in parallel
<smoser> thats what i thought
<Keybuk> you can use openlog with LOG_CONSOLE of course
<Keybuk> so syslog() outputs to the console if syslog isn't up
<smoser> Keybuk, thank you. i'd like to avoid C here if possible. maybe this just needs to write to /dev/console
<primes2h> cr3: That's nice. Imported! Thank you very much indeed.
<joaopinto> cjwatson, is the desktop cd based on debootstrap+casper+ubuntu-desktop+ubiquity+casper => squashfs image ?
<joaopinto> ops, one casper :P
 * dupondje prays somebody includes fix @ https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/391035)
<EtienneG> mathiaz (or ttx, or whoever): do you have any idea what actually generate the ssh authentication keypair when installing eucalyptus?  I just installed eucalyptus-cloud and eucalyptus-walrus on a machine, and /var/lib/eucalyptus/.ssh is empty.  I am wondering it is a bug or if I forgot a step somewhere
<mathiaz> EtienneG: was it from an ISO?
<EtienneG> mathiaz, no.  I did a plain server install, and am going to do a so-called "multi-component" install
<mathiaz> EtienneG: right - that's why
<EtienneG> mathiaz: but I found the problem, and I am afraidit might be a bug
<mathiaz> EtienneG: IIUC the ssh key generation is done at install time
<mathiaz> EtienneG: and I think it's probably eucalytpus-cc that does so
<EtienneG> mathiaz, indeed
<EtienneG> mathiaz: but i am not quite sure it is correct.  You would need the keypair on the CLC
<mathiaz> EtienneG: if you install walrus/cloud on another machine, you'd probably have to copy the public key from the CC to the walrus/cloud
<EtienneG> mathiaz, or rather, you would need a keypair on the clc, and one on the cc (could be, but does not have to, be the same)
<Dink> Hellow, not sure if its here where I need to post this but I am currently running Karmic and something funky is going on. Initially when I logged in compiz.real was eating up all my cpu. I then changed "visual effects" to none and cpu went back to normal. I then looked at where I was logged in and it seems like gdm started on tty1 and not 7. All other tty seem to be unusable. If this is the wrong plac
<Dink> e to post this I apologize and please redirect me to the correct channel.
<EtienneG> mathiaz, ok, I will copy the keypair from the cc to the clc.  The multi-compoenents install needs to be sorted out anyway, it still requiremanual ssh key exchange
<mathiaz> EtienneG: yes - it's the same thing you need to do when you install the nodes from packages (instead of ISO)
<mathiaz> EtienneG: you need to copy the ssh key from the CC to the nodes
<mathiaz> EtienneG: usually euca_conf discover will tell you exaclty what needs to be done
<EtienneG> mathiaz, it does not anymore, at least not when registering a cluster on the clc
<mathiaz> EtienneG: oh probably
<mathiaz> EtienneG: I've seen that only when try to register nodes
<mathiaz> EtienneG: the case of registering a cluster on the clc hasn't been covered probably
<mathiaz> EtienneG: this needs to be documented at least
<mathiaz> EtienneG: (bug is welcome as well - but won't be fixed in karmic I think)
<mathiaz> EtienneG: (as there is a workaround)
<EtienneG> mathiaz, right.  This is actually to be fixed in euca_conf, IIUC
<mathiaz> EtienneG: I'd guess so as well.
<EtienneG> (looking now)
<ccheney> slangasek: ping
<EtienneG> mathiaz, 1455 line of shell .. .oh dear!
<EtienneG> I give up
<EtienneG> will check tht tomorrow ...
<slacker_nl> hello, has anything changed with the boot sequence that might explain "timeouts" on mounting file systems?
<slacker_nl>  i've been having some weird messages at boot, unable to mount partions x y and z hit esc to enter some kind of shell, laptop boots and all, with everything mounted
<ion> What kind of partitions are they?
<slacker_nl> ext3
<slacker_nl> ion: http://pb.opperschaap.net/74 fstab
<ion> Did i understand correctly â they are mounted correctly in the end?
<slacker_nl> ion: yes
<slacker_nl> the messages repeats itself several times
<ion> Thatâs probably just the usplash issue where the CLEAR command doesnât actually remove the message when it manages to mount the partition in question.
<slacker_nl> the biggest problem is, it isn't logged somewhere (at least, cannot find anything in my logs)
<slacker_nl> ion: you have a bug number for that issue?
<shtylman> ccheney: man...people really won't let that oo filepicker bug die... :)
<ion> slacker_nl: Bug #215666
<ubottu> Launchpad bug 215666 in usplash "fsck messages are not cleared from usplash when check is finished" [Undecided,Confirmed] https://launchpad.net/bugs/215666
<slacker_nl> ion: thnx
<slacker_nl> ion: but karmic is using xsplash right..
<ion> slacker_nl: X canât be started before important filesystems have been mounted, thus no xsplash yet when those messages need to be shown. For karmic, usplash handles them.
<ccheney> shtylman: heh
<ccheney> shtylman: its what happens when linux gets to easy to use ;-)
<shtylman> haha
<slacker_nl> ion: i see, yet, the same message appears when I get the kubuntu logo
<slacker_nl> ion: i'll make some screencast/pictures tomorrow so I can show you/add it to a bug report
<ion> keybuk: Ah. CLEAR doesnât do anything when not in VERBOSE mode. Should i patch usplash to always clear the text on CLEAR, or mountall to send CLEAR in VERBOSE mode?
<cjwatson_> ion: former sounds better to me
<ion> Ok, a moment...
<cjwatson> (gone for the night)
<dmoerner> is there a bug report referencing the removal of gcc-3.3 from karmic (like http://bugs.debian.org/536776)? I'm trying to convince a vendor that they really need to get rid of dependencies on libstdc++5 if they want to be competitive
<dmoerner> i can't find it on google, but obviously gcc-3.3 has been dropped
<cjwatson> dmoerner: according to the publication history (https://launchpad.net/ubuntu/+source/gcc-3.3/+publishinghistory), we just removed it in line with Debian
<ion> https://code.edge.launchpad.net/~ion/usplash/karmic (didnât test it yet, about to do that)
<joaopinto> dmoerner, https://bugs.launchpad.net/ubuntu/+source/gcc-3.3/+bug/418372
<ubottu> Launchpad bug 418372 in gcc-3.4 "removal request" [Undecided,New]
<cjwatson> ah, heh, that too
<dmoerner> joaopinto, cjwatson: thanks!
#ubuntu-devel 2009-10-22
<Keybuk> ion: former sounds good
<slacker_nl> ion: if you need a tester gimme a ppa to add and I'll test it for you
<ion> My VirtualBox seems to have serious issues. Still trying to get the VM booted in order to test the patch in action. :-P
 * slacker_nl goes to bed
<ion> keybuk: Yeah, verified https://code.edge.launchpad.net/~ion/usplash/karmic to fix the issue.
<natewiebe13> ion.. what issue does that usplash ppa fix?
<ion> natewiebe13: Bug #215666
<ubottu> Launchpad bug 215666 in usplash "fsck messages are not cleared from usplash when check is finished" [Undecided,Confirmed] https://launchpad.net/bugs/215666
<natewiebe13> ion: awesome.. been waiting for that one
<arand> cjwatson: I'm a bit worried about Bug #445067 , would I be right to be?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/445067)
<Keybuk> ion: could you mail that one to me
<ion> keybuk: Done
<Keybuk> ion: you have one of those slow hard-drives, right?
<ion> keybuk: A typical laptop HDD, yeah
<Keybuk> ion: sweet
<Keybuk> mind running a little test for me
<Keybuk> some manual work required
<ion> keybuk: Sure.
<ion> keybuk: Btw, the mountall 0.2.6 change breaks stuff. Even if there are mountpoints weâre waiting for, if try_mounts is called with newly_mounted == FALSE, mountall exits immediately.
<Keybuk> ion: argh
<Keybuk> hate hate hate
<Keybuk> anyway
<ion> How about just iterating through mounts every single time try_mounts is called? :-P
<Keybuk> http://zelda.netsplit.com/~scott/ureadahead.tar.gz
<Keybuk> download, unpack, configure, make
<ion> Will do
<Keybuk> that'll give you a src/trace binary
<Keybuk> write an /etc/init/trace.conf that execs it, piping the output somewhere
<Keybuk> e.g. exec /path/to/src/trace > /dev/trace.log
<Keybuk> +2>&1 I guess
<ion> I have sreadahead disabled at the moment. Should i do anything about that?
<Keybuk> no, that's fine
<Keybuk> was goign to say, disable sreadahead
<ion> :-)
<Keybuk> (but make sure it's installed so /var/lib/sreadahead/debugfs exists :p)
<ion> Yeah
<Keybuk> make the trace.conf start on startup
<Keybuk> or actually
<Keybuk> start on starting mountall
<slangasek> ccheney: hi
<Keybuk> hmm, no
<Keybuk> start on startup ;)
<Keybuk> the other won't work just yet
<Keybuk> then reboot
<Keybuk> and once back to your desktop send it SIGTERM
<Keybuk> it'll spit out a random dump of information
<Keybuk> I'd like that ;)
<Keybuk> in the output, I expect you'll see that for any given file, the number of "chunks" exceeds the number of "fragments"
<Keybuk> ion: I think the newly_mounted is a hold-over for when try_mounts wasn't a main loop function, so you could well be right - just get rid of that entirely and always try mounts
<ion> keybuk: trace: Cannot enable tracing: No such file or directory
<Keybuk> ion: odd, does it do that now if you run it?
<ion> It works correctly when started from a running system.
<Keybuk> odd
<Keybuk> maybe a race, /sys was mounted so /sys/kernel/debug existed but not /sys/kernel/debug/tracing
<Keybuk> I can fix that
<Keybuk> (sreadahead must be vulnerable to the same race though)
<ion> I could start with init=/sbin/sulogin and strace the binary to see whatâs going on.
<Keybuk> ion: tweak the code
<Keybuk> actually, right
<Keybuk> so that ;)
<Keybuk> boot with sulogin
<Keybuk> mount -t debugfs none /sys/kernel/debug
<Keybuk> then exec init as normal
<Keybuk> that'll fix it
<ion> Ok
<Keybuk> ion: any luck with that?
<ion> keybuk: Hmm, the output seems to be missing everything that happened during the bootup, thereâs only some desktop stuff in there, beginning with /usr/share/icons/gnome/icon-theme.cache
<ion> Nothing about e.g. xsplash, gdm, mountall, hal
<ccheney> slangasek: was going to ask you about rebasing on 3.1.1-5 when i do the upload, most of the changes i already have or are apparently from something you told rene to fix yourself?
<slangasek> ccheney: the debconf pre-depends?  I'll want to review the exact changes implemented, because even though it's a bugfix there's substantial risk of regression; the sooner you can upload that to the queue, the better
<ccheney> ok, so i can go ahead and upload early tomorrow morning and it won't disrupt anything?
<slangasek> ccheney: "early tomorrow morning" is later than I would prefer
<ccheney> i can try to do it tonight but its already 9pm here and takes a while to get a build done
 * slangasek nods
<ccheney> my new machine is installing atm but i can do the build on my laptop
 * ccheney will see what he can do
<slangasek> ccheney: if it's not there until tomorrow morning, it's likely that I won't get back to you with any feedback until Friday; but it's your call
<ccheney> ok will try to get it done tonight
<Keybuk> ion: odd, but that'll do for now
<Keybuk> just want to get an idea of the fragmentation pattern of your disk
<ion> keybuk: http://heh.fi/tmp/trace.log
 * ccheney is glad he has much faster internet access now :)
<Keybuk> ion: not hugely so, then
<Keybuk> ion: what filesystem are you using?
<ion> keybuk: ext4. I have a box with an older desktop HDD and ext3 nearby; it probably has lower throughput but faster seeking. And itâs been in use much, much longer than this laptop.
<ion> Should i get a trace from that box as well?
<Keybuk> if you can
<ion> keybuk: http://heh.fi/tmp/trace.log
<Keybuk> that looks good
<Keybuk> having more sreadahead problems with that one?
<Keybuk> /usr/lib/locale/fi_FI.utf8/LC_CTYPE (250 kB, 63 pages)
<Keybuk> @########################################################......
<Keybuk> @@@@@@@@@@##@@@@@@########@@#@@@@######@@######@@###@####......
<Keybuk> 1 fragments (228 kB), 27 chunks
<ion> I havenât measured the startup time difference between sreadahead enabled and disabled on the latter box.
<Keybuk> bet it hates it
<Keybuk> the pretty above means that for that file, 228/250 kB of it was in memory
<Keybuk> and in one long contiguous bit of the file
<Keybuk> but, on disk, that turns out to be scattered in 27 different places
<Keybuk> sreadahead would have tried to optimise that to one readahead() call
<Keybuk> it needs to be 27
<ion> Ok
<Keybuk> possibly with bits of other files in between
<Keybuk> in conclusion, sreadahead sucks
<ion> So, it readaheads in the wrong order in four simultaneous threads? :-)
<Keybuk> basically
<Keybuk> and fails to take into account it might need to read a chunk from file A, then a chunk from file B, then the second chunk from file A
<Keybuk> etc.
<ion> Yeah
 * Keybuk battles with FIEMAP
<ion> Would be nicer to store the trace data somewhere and have an idle priority program reorder the disk blocks based on it, attempting to get things physically into the order the system tends to read them in. No need for sreadahead anymore.
<ion> Next up: getting all filesystems to provide an interface for that. :-P
<Keybuk> you'd still want to read ahead
<Keybuk> but yes, it'd be nice to be able to feed the trace into defrag too
<ion> https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/karmic (didnât test yet, about to)
<Keybuk> ion: can you mail me that to remind me
<ion> keybuk: Ah, thatâs not good either. It ends up trying to mount stuff many times a second, even though nothingâs changed.
<ion> keybuk: Iâll send the email when i get it to work.
<ion> keybuk: Is the change in 0.2.6 really needed? If the mountinfo watcher notices something has been newly mounted, it calls mounted (mnt), which should cause try_mounts to be called with newly_mounted == TRUE.
<ion> I guess it is. /me looks at the log attached to bug #456806.
<LaserJock> slangasek: we've found that moving the database (mysql-server or postgresql) from Recommends to Pre-depends for moodle allows it to install. Can I upload that or is it too late?
<ubottu> Launchpad bug 456806 in mountall "mountall vomits a shell onto virtual console when you run vi" [High,In progress] https://launchpad.net/bugs/456806
<slangasek> LaserJock: bug #?
<slangasek> LaserJock: it's not too late to upload for release, but it's too late for RC
<LaserJock> slangasek: bug #440098
<slangasek> LaserJock: if this is bug #319868, then Pre-Depends is wrong
<ubottu> Launchpad bug 440098 in postgresql "Edubuntu d-i fails when using postgresql as backend" [Undecided,New] https://launchpad.net/bugs/440098
 * slangasek looks
<ubottu> Launchpad bug 319868 in moodle "package update-manager 1:0.93.34 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)" [High,Triaged] https://launchpad.net/bugs/319868
<slangasek> LaserJock: in fact, that's a good general rule for everything: Pre-Depends are wrong
<slangasek> LaserJock: the /existing/ Pre-Depends in moodle are /also/ wrong
<LaserJock> slangasek: I know, that's why I hated to even mention it
<LaserJock> slangasek: but it fixes the immediate issue is all
<slangasek> LaserJock: it fixes it *wrong*
<slangasek> *do not add Pre-Depends*
<LaserJock> k
<slangasek> Depends is the correct relationship
<LaserJock> will that make the DB server be configured before moodle?
<LaserJock> I wouldn't think there would be a difference between Recommends and Depends in that regard
<slangasek> then you haven't read the definitions of these package relationships
<slangasek> the *definition* of Depends is "packages that must be configured before the current package is configured"
<LaserJock> hmm
<mathiaz> LaserJock: not sure about the exact context - but neither mysql nor postgresql will be running in the installer
<mathiaz> LaserJock: even the package is configured correctly, the daemons are *not* started when d-i is running
<LaserJock> mathiaz: apparently it's not that their running that matters but that they're configured
<LaserJock> but I don't know why they're Recommends now
<mathiaz> LaserJock: if the moodle post install script tries to create databases which SQL statement, the databases need to be running
<LaserJock> I don't *think* it does but I'm not sure
<mathiaz> LaserJock: http://paste.ubuntu.com/298761/
<mathiaz> LaserJock: the postgresql server is *not* running
<mathiaz> LaserJock: which is expected in the installer
<LaserJock> mathiaz: has that changed within the last release or two (that the db server wouldn't be running)
<mathiaz> LaserJock: hm - no - it has been the case for a long long time
<LaserJock> I don't understand how this stuff seems to work in Debian and used to work in Ubuntu
<mathiaz> LaserJock: may be the moodle packaging has changed?
<mathiaz> LaserJock: and now it fails if it cannot connect to the server?
<LaserJock> no, the packaging was changed so that it *did* work
<LaserJock> it's a real mess though
<LaserJock> seems like people have tried for years to get a decent moodle package
<LaserJock> ok, just got a report  that sid has the same problem
<jbicha> slangasek: even if it's wrong, pre-depends allows the moodle install to work, as it is, some teacher may not understand why his software won't install and how doing a dpkg-reconfigure afterwards makes his software "more right"...to do the "more right" thing would take a full FFE pretty late, right?
<LaserJock> jbicha: if Depends works it's infinitly better than pre-depends
<mathiaz> jbicha: I don't see how Pre-Depends would work here
<mathiaz> the problem is that the database daemon is not running - whether it's a Depends or a Pre-Depends doesn't change IIUC
<LaserJock> I tested it with pre-depends and it worked quite well
<LaserJock> the app installed and I was able to set up moodle no problem
<mathiaz> LaserJock: from an iso install?
<LaserJock> no, on a desktop with no db server installed
<mathiaz> LaserJock: right - that will work correclty
<mathiaz> LaserJock: because the DB daemon will be running
<mathiaz> LaserJock: bug 440098 is about Edubuntu d-i
<ubottu> Launchpad bug 440098 in postgresql "Edubuntu d-i fails when using postgresql as backend" [Undecided,New] https://launchpad.net/bugs/440098
<mathiaz> LaserJock: ie an iso installation
<LaserJock> right
<LaserJock> how is the iso installation different?
<mathiaz> LaserJock: daemons are not started during an iso installation - as it doesn't make sense and would probably fail
<LaserJock> I see
<LaserJock> that would cause a bit of a problem, yes
<mathiaz> LaserJock: the daemon are installed in the chroot - but the system is not running from the chroot
<LaserJock> right right
<LaserJock> ok, so well, that isn't a big issue right now
<LaserJock> I already dropped it from the DVD
<LaserJock> but that's a very good point
<LaserJock> ok
<LaserJock> so if we upload the apache config fix (for IPV6) and move the server from Recommends to Depends
<LaserJock> then moodle should work for existing desktops
<mathiaz> LaserJock: hm - which server?
<LaserJock> mathiaz: the db server
<mathiaz> LaserJock: you wanna make moodle depend on postgres or mysql?
<LaserJock> it Recommends postgresql|mysql-server right now and needs a dpkg-reconfigure to work right
<mathiaz> LaserJock: IIRC the default in the config script is to use postgresql
<mathiaz> LaserJock: so recommending postgresql seems the best option
<LaserJock> well it's postgresql | mysql-server
<LaserJock> you should be able to use either
<LaserJock> but as slangasek pointed out you need Depends to have it configured before moodle
<LaserJock> which seems to fix the problem we've been seeing on the desktop installs
<mathiaz> LaserJock: well yes - unless the admin choose mysql as the backend
<mathiaz> LaserJock: in which case things won't work
<mathiaz> LaserJock: so you'd move postgres|mysql-server to a Depends?
<LaserJock> yeah
<jbicha> mysql works also
<mathiaz> LaserJock: right - seems like a good option
<jbicha> I'm going to try again as just a depends, thanks all for the time and the help
<LaserJock> I mean, it stinks because it's not all that easy to get a mysql backend because you have to get all the bits right
<LaserJock> but it should at least work if you're choose to install the mysql packages
<mathiaz> LaserJock: that means if you do an "apt-get install moodle" you'll get a postgresql backend
<mathiaz> LaserJock: if you do an "apt-get install moodle mysql-server" you'd have to choose the mysql backend
<LaserJock> actually apt-get install moodle mysql-server php5-mysql mysqlclient
<mathiaz> LaserJock: right - a Depends should be enough
<mathiaz> LaserJock: but it won't fix the installer failure
<LaserJock> no
<LaserJock> but that's ok for Karmic
<LaserJock> well, at least it's not on the Edubuntu DVD, it could be still on the Ubuntu DVD but I doubt many people will be installing it from there
<LaserJock> ok, I really got to get to bed
<LaserJock> mathiaz: thanks for the info
<LaserJock> slangasek too
<ccheney> was 'text editor' renamed to 'gedit text editor' on purpose?
<julien_c> ccheney: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/442417
<ubottu> Launchpad bug 442417 in ubuntu-docs ""Text Editor" changed to "gedit Text Editor" in Applications->Accessories" [Medium,New]
<ccheney> julien_c: ok
 * ccheney likes the new karmic artwork :)
<ccheney> julien_c: hmm so it sounds like someone just dropped a patch by accident and then isn't going to fix it?
<ccheney> slangasek: uploading new OOo now
<slangasek> jbicha: I've told you how to fix it right.
<slangasek> jbicha: I will not accept the wrong fix for this
<ccheney> wow my new system loads OOo so fast I can barely see the splash screen
<slangasek> mathiaz: why does the db server not start in the target under the installer?  I wasn't aware that we redirect invoke-rc.d there?
<ccheney> ~ 0.5s or so, can't even time it really
<mathiaz> slangasek: hm - I thought invoke-rc.d was redirected in the installer
<jbicha> slangasek: I thought you said I just needed to make the db server & debconf depends not pre-depends
<slangasek> mathiaz: I honestly don't know
<slangasek> jbicha: yes - which modulo mathiaz's concerns about the server not starting when running under the installer, is the right way to fix it.
<jbicha> slangasek: so my new patch is not necessarily a wrong fix now?
<slangasek> jbicha: I haven't seen the new patch, let me look
<slangasek> I was responding to your comment here on IRC
<shtylman> ccheney: specs?
<slangasek> jbicha: yes, that new patch looks fine, thanks
<ccheney> shtylman: core i7 860 @ 3.6ghz
<jbicha> slangasek: thanks again, I have to go to my real job now
<shtylman> nice!
<shtylman> ssd drives?
<ccheney> shtylman: 8gb ddr3 1690mhz :)
<ccheney> shtylman: no just a regular 1tb seagate drive
<shtylman> thats some nice stuff
<shtylman> you gotta put two ssd in raid 0
<shtylman> that will seal the deal
<ccheney> shtylman: yea i was tired of using my 3 year old system so upgraded, heh
<shtylman> nice
<shtylman> yea... doesn't compiling OO feel so much better
<ccheney> two ssd would cost about as much as my whole system, heh
<shtylman> don't have to be top of the line
<ccheney> yep ~ 54m or so
<shtylman> I found that standard ssd in raid 0 perform very well
<ccheney> ah
<ccheney> does linux do trim yet?
<shtylman> no idea...I think I hear it does
<ccheney> ok
<shtylman> but I ould be wrong on that
<shtylman> *could
<ccheney> iirc ext4 was going to get it soon back around UDS time but i haven't tracked its status
 * ccheney may be thinking of UDS jaunty though
<shtylman> hmm
<shtylman> maybe... ive been running ext4 on my ssds
<shtylman> but then again I havn't tuned anything
<shtylman> I just run stock options for now
<ccheney> ok
<cjwatson> slangasek,mathiaz: we do indeed stop services being started in /target during installation
 * cjwatson runs to catch a flight
<ion> cjwatson: Only 5Â½ hours of sleep? :-)
 * slangasek waves
<cjwatson> ion: more like 3.5
<ion> Ouch :-)
<liw> screen is supposed to be locked when suspending, right? mine isn't, what should I look at?
<StevenK> slangasek: Bug 456896 is asking for the removal of kaffe, but there's a bunch of rdepends. Debian removed kaffe about a week ago, so they've done the work for this, it looks like kaffe -> default-jdk, are you comfortable handling this before release?
<ubottu> Launchpad bug 456896 in kaffe "Please remove kaffe source and all binaries from Karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/456896
<StevenK> ScottK: In other news, the rest of your removal requests are done.
<ScottK> StevenK: Thanks.
<slangasek> StevenK: of handling what, updating the rdepends for the transition?
<liw> also, I keep hitting but #446031 still (just did), and it's starting to worry me
<slangasek> I think that's motu-release's call
<StevenK> slangasek: Yes.
<StevenK> ScottK: ^ ? :-)
<slangasek> liw: gnome-screensaver has been failing to lock-on-idle for me today; would suggest filing the bug there
<ScottK> StevenK: Looking
<ScottK> StevenK: Let's hold off on that one for now.  I'll look at it when it's not 1:30AM and I'm tired.
<liw> slangasek, #446191 has same symptoms as I do
<liw> hm, if I enable screensaver's locking, suspend locks, too; I guess I can live with that, though it's going to annoy me often
<slangasek> liw: different bug than mine then, I guess; I already have gnome-screensaver set to lock
<liw> let me see if I can trigger the screensaver and see if it locks...
<al-maisan> Good morning
<ccheney> memory bandwidth (tested via hdparm) on this new machine is immensely faster than my old box, 1.4GB/s vs 11.5GB/s
<liw> I must be doing something wrong, I can't get screensaver to trigger
<mneptok> liw: my screen doesn't lock when suspending, either. i can always open the laptop lid easily.
<liw> mneptok, heh
<slangasek> liw: well, my problem appears to be resolved after the latest reboot, leaving only the policy question, I guess
<slangasek> (and I'm of the opinion that one toggle for screen lock is sufficient)
<liw> slangasek, for the suspend? I won't oppose. I'm now more worried that my screesaver doesn't trigger at all
<liw> though less worried that my desktop's network doesn't come up at all
 * liw is generally worried this morning
<liw> http://paste.ubuntu.com/298845/ -- which setting there is wrong and prevents screensaver from working?
<liw> slangasek, is bug #411350 the on you get?
<ubottu> Launchpad bug 411350 in gnome-screensaver "gnome-screensaver not functioning" [High,Confirmed] https://launchpad.net/bugs/411350
<slangasek> liw: dunno, the problem's not reproducible for me now
<slangasek> superm1: bug #457896 - in a chroot, or not?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457896)
<slangasek> superm1: ignore that question, it's clearly not
<slangasek> superm1: please give me the output of 'sudo status idmapd; sudo dpkg --configure --pending; sudo status idmapd'
<superm1> slangasek, well i already resolved it by "sudo service idmapd stop && sudo apt-get upgrade"
<slangasek> superm1: sigh
<slangasek> superm1: I can't reproduce this problem, so that leaves me with no way to fix it :(
<slangasek> superm1: how about 'sudo status idmapd; sudo dpkg-reconfigure nfs-common; sudo status idmapd'?
<pitti> Good morning
 * slangasek waves to pitti 
<superm1> slangasek, http://paste.ubuntu.com/298853/
<slangasek> superm1: I think you put an extra 'service' in there, but close enough ;)
<slangasek> superm1: actually, what commands *did* you run?
<superm1> slangasek, $ sudo status idmapd; sudo dpkg-reconfigure nfs-common; sudo status idmapd
<slangasek> er, odd
<superm1> it looks like it tries to restart statd, gssd, and idmapd
<slangasek> which it's supposed to do - I don't know why the extra output is there, though
<slangasek> but that's reproducible for me when using dpkg-reconfigure
<superm1> would you like me to attach misc things that appear to be sourced like /etc/default/nfs-common /etc/exports /etc/fstab ?
<slangasek> superm1: feh, dpkg-reconfigure bypasses setting the DPKG envvar we look for; well, that explains the noise
<slangasek> superm1: you haven't modified /etc/init/idmapd.conf, have you?  (debsums -e -s nfs-common)
<superm1> return code was zero for that
<superm1> i dont recall ever touching it
<slangasek> ok
<slangasek> superm1: well, "idmapd start/running" is the wrong output, because there should be a PID.  Can you do a sudo stop idmapd && sudo initctl log-priority debug && sudo start idmapd, and send me whatever log spew upstart generates? (/var/log/syslog)
<superm1> slangasek, http://paste.ubuntu.com/298858/
<slangasek> superm1: ok, please run 'sudo rpc.idmapd -v -f' and show me the output
<superm1> slangasek, ooh this looks fun: http://paste.ubuntu.com/298859/
<slangasek> (the log shows that upstart got all the way to trying to run rpc.idmapd, and the process died immediately after invocation)
<slangasek> superm1: urk
<superm1> the only reason i could suspect that would have happened is if ubiquity decided to not copy that file during installation
<slangasek> superm1: ok, cool, Not My Bug ;)
<superm1> slangasek, yeah.... let me fire up a VM with a fresh install and see if that's still happening on current dailies too then
<slangasek> superm1: ok - I've sent the latest info to the bug but left it open, I'll leave it to you to further triage as you see fit
<superm1> slangasek, okay thanks.
<slangasek> ironically, we had two undesirable behaviors of upstart cancelling each other out (job is considered started even if respawning indefinitely; running 'start' on a started job fails), and the init script did the right thing, it just didn't give any useful feedback
<slangasek> davidbarth: can you tell me what the status of bug #419839 is? these tasks have been marked "fix committed", but I don't know if that's accurate at all and I don't know how to verify myself whether this is resolved
<ubottu> Launchpad bug 419839 in kdepim "Ensure proper usage of icons in the messaging menu" [Medium,Fix committed] https://launchpad.net/bugs/419839
<pitti> kees, mdeslaur, jdstrand: I just got a call from a friend that yesterday's kernel update rendered his machine unusable; some init scripts fail, and you can't even log into a VT ("/bin/bash: permission denied"); haven't tracked it down yet, since booting the previous kernel now gives the same result; did you happen to hear any other problem reports from anywhere?
<pitti> (jaunty)
<chrisccoulson> hey pitti - do you think we should revert back to the jaunty behaviour for screen locking on suspend, and fix bug 446191 before release?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/446191)
 * chrisccoulson prods launchpad again
<pitti> chrisccoulson: read LP and upstream bug now
<pitti> chrisccoulson: if we keep this gconf key disabled by default, we should revert, yes
<pitti> chrisccoulson: I'm just not sure whether we shouldn't enable screensaver lock as well by default
<pitti> chrisccoulson: my feeling is that it makes sense (as much as locking screen on suspend)
<pitti> chrisccoulson: but at this point of the release cycle it's bad to change behaviour like that, so I agree to just reverting to jaunty g-p-m behaviour
<chrisccoulson> yeah, i'm not sure about the default. i've always found it a bit strange that we turn the default to off
<pitti> chrisccoulson: what would that mean technically? change gnome-session to not look at the screensaver gconf key when suspending?
<pitti> seb128: ^ any opinion?
<chrisccoulson> i'll work on a patch later to revert back to the jaunty behaviour then. it will involve the same logic to what is already in g-p-m
<chrisccoulson> (i'll probably just copy and paste;))
<chrisccoulson> that will mean that the behaviour follows g-p-m policy, which is how it used to work
<seb128> chrisccoulson, is there a summary of jaunty and karmic behaviours?
<seb128> I'm not sure what it used to do and what it does now
<pitti> chrisccoulson: yes, that makes sense; so it will read g-p-m's gconf key instead of g-screensaver's?
<chrisccoulson> seb128 - in jaunty, suspend used to be proxied through g-p-m, and the decision to lock the screen was based on g-p-m settings, which are independent of the screensaver settings in Preferences -> Screensaver
<pitti> chrisccoulson: that's at least consistent with indicator-applet etc., so let's do that
<chrisccoulson> cool, i'll work on that. thanks!
<seb128> agreed with pitti
<pitti> chrisccoulson: many thanks
<chrisccoulson> excellent, thanks:)
<davidbarth> slangasek: hi; they are fix commited for gnome apps, in that we have checked that icons were used properly
<slangasek> davidbarth: ok, then that should be 'fix released'
<davidbarth> slangasek: we should mark that invalid for kubuntu apps however, as the priority here is with following platform UI guidelines more than Ayatana ones directly (KDE loves icons ;)
<davidbarth> slangasek: correct, let me update that
<slangasek> davidbarth: great, thanks
<seb128> I don't think it's obvious for users that it use the screensaver option
<seb128> using the gpm one is better
<seb128> davidbarth, fix commited = still open
<seb128> davidbarth, I've been confused by where the empathy fix has been commited too cf my comments
<seb128> davidbarth, ie is there any fix to cherrypick and upload?
<davidbarth> seb128: the tasks was a reminder to inspect the code, as the design team had introduced this additional visual requirement
<seb128> davidbarth, hum ok, still seems something you could track you of ubuntu package tasks if there is no ubuntu change required ;-)
<slangasek> seb128: AFAIK there isn't a gpm option for whether to lock the screen, only whether to blank it?
<seb128> slangasek, /apps/gnome-power-manager/lock/suspend
<slangasek> seb128: right, but not exposed in the UI
<slangasek> (and I don't think it should be...)
<seb128> right
<seb128> but I think it just makes sense to follow this setting
<slangasek> well, you can force it to if you also turn off "use_screensaver_settings" while you're in there
<slangasek> but I don't see why anyone would want a different policy when closing the lid than for other uses of the screensaver
<slangasek> OTOH, I think anyone whose screensaver isn't set to lock is crazy :)
<slangasek> (what else is a screensaver for? :)
<seb128> chrisccoulson, pitti: ^
<pitti> I said the same in the bug
<liw> I prefer to have my screensaver not lock (just turn off the screen to save power) when I'm at home, since the laptop is only turned on when I'm here (if I take the laptop with me, I'd like it to be locked on screensave)
<liw> but steve's considered me crazy for years, so that's ok :)
<slangasek> :-)
<slangasek> liw: I suspect that's really an approximation of the policy you /really/ want, though, which is "when the screen blanks at home, don't lock; when the screen blanks on the road, do lock" ?
<seb128> slangasek, you forget "and make coffee"
<pitti> presumably you then also don't want it to lock on suspend?
<slangasek> seb128: that's why it's KEY_COFFEE
<liw> hnghgh. I re-set my screensaver to blank the screen after 20 mins, not 1, and now it started working again -- after 1 min, not 20; it's as if it remembered the _previous_ setting
<slangasek> forget gnome-settings-daemon, I have Fn+F2 mapped to my espresso machine
<liw> slangasek, hm, yes. on suspend: always lock; on screensaver: when not at home or when there are people there that I don't know
<liw> or rather, that don't live there
 * slangasek nods
<ion> How interesting, i have Fn+F2 mapped to your espresso machine, too.
<pitti> is there a way in grub to say "stop in initramfs before booting the root fs?
<chrisccoulson> so, we're ok with restoring the jaunty behaviour for screen locking? (i couldn't work out what everyone agrees with)
<ion> pitti: break=mount
<chrisccoulson> pitti "break=<something>" appended to the kernel command line? (i can't remember what "something" is though)
<chrisccoulson> yeah, thats it:)
 * ion looked it up from /usr/share/initramfs-tools/init
<pitti> thanks
<mvo> I get messages on my (upgraded) test system that swap ID <long> remians to be mounted in usplash at bootup ~3-5 times with a delay of ~1sec between them  (then everything continues) - is that a known issue?
<Keybuk> mvo: yeah
<Keybuk> it's not an issue though?
<Keybuk> it's telling you why your boot is taking longer than 3s <g>
<slangasek> "I could be using the processor to mount your swap, but I wrote you this message instead" ;)
<mvo> heh :) I need a faster system obviously
<Keybuk> the fact they appear as separate messages, ion had a fix for
<Keybuk> (mountall is sending CLEAR, but usplash is ignoring it)
<Keybuk> it should just look like a static message, updated once a second
<Keybuk> slangasek: this is why splash screens are fundamentally silly <g>
<mvo> ok, cool
<liw> slangasek, hah, that reminds me of an optimization story: added some logging to a program to measure how long various parts of it took, and they were really slow; much hair pulling; took out log messages, system was faster than required
<liw> turned out writing lots of text to a graphical terminal emulator was really, really slow
<Keybuk> liw: see also: bootchart
<ion> usplash should have doublebuffering, so mountall could say âCLEAR, TEXT foo, TEXT bar, TEXT baz, FLIPâ and there wouldnât be visible flickering and scrolling on updates. :-P
<liw> Keybuk, sure, bootchart is a nice thing to have, this millennium
<Keybuk> liw: I mean that bootchart makes a big effect on boot speed
<liw> Keybuk, ah, I guess I'm not surprised there
<Keybuk> liw: it can up to double the boot time ;)
<Keybuk> ion: does Plymouth have double-buffering? :p
<Keybuk> ion: btw http://zelda.netsplit.com/~scott/ureadahead.tar.gz -- I'd appreciate another test ;-)
<ion> keybuk: Dunno. It should, it itâs supposed to be boot splash done right. :-P
<slangasek> Keybuk: btw, upstart readding 'sync on reboot' seems to have caused a regression for me, which I still need to get to the bottom of; the sync never returns, so my system hangs until I power it off :P
<slangasek> (may or may not be related to network filesystems being present)
<Keybuk> slangasek: that's odd ;)
<Keybuk> reboot always had a sync() in it
<Keybuk> except for a brief time
<slangasek> Keybuk: when was it first removed?
<Keybuk> slangasek: mid-karmic
<davidbarth> slangasek: i can't update the bug to mark it fix-released; access level issue as it's tracked by the release team i suppose (#419839)
<slangasek> Keybuk: so... before the conversion of everything to upstart jobs that would have caused reordering of the shutdown sequence
<Keybuk> slangasek: yes
<Keybuk> though unmounting things is still handled by the sysvinit scripts
<slangasek> davidbarth: release team tracking has no bearing on it, dunno what blocks you - I'll grab it now to fix though
<slangasek> Keybuk: yep - but shutting down NM isn't
<Keybuk> slangasek: NM was never sendsigs/omit.d either
<Keybuk> so it was always dead by that point
<slangasek> Keybuk: no
<slangasek> Keybuk: by no I mean yes, obviously
<slangasek> Keybuk: then the other possible complication is my own migration to NFSv4 during the period ;)
<Keybuk> from german import doch
<slangasek> that wasn't my problem, I was just asserting untrue things :)
<slangasek> well, I guess this would be fixed if I ever got around to implementing the "if all the networks are gone, lazy unmount" I've been meaning to
<Keybuk> I could remote the sync() :p
<slangasek> I'll try unmounting NFS before reboot, to confirm that's the source of the problem
<slangasek> "remote" it?
<Keybuk> remove it
<Keybuk> evan has rudely not supplied coffee :p
<slangasek> heh
<Keybuk> but removing the sync() could be bad
<slangasek> but your rationale for readding the sync seems... sound, yes
<Keybuk> it turns out that remounting ext4 read-only doesn't imply a sync
<Keybuk> as of somewhere mid-.31
<davidbarth> slangasek: works now, using a different way in LP
<slangasek> oh for the love of trapdoors
<slangasek> why does clicking once on a background in appearance preferences change my desktop background with no warning and no way to let me restore the custom image I was using before? :P
<ion> keybuk: http://heh.fi/tmp/trace-desktop.log (worse throughput, better seek time, ext3, old installation) http://heh.fi/tmp/trace-laptop.log (better throughput, worse seek time, ext4, recent installation)
<Keybuk> ion: both fairly fraggy then
<Keybuk> /usr/lib/locale/locale-archive (838 kB), 1 chunks (128 kB), 9 extents
<Keybuk>   [@@#%%%%%%%%@@#%@##@##@@###@#####..........................................]
<Keybuk>   [..........................................................................]
<Keybuk>   [..............................................................            ]
<Keybuk> that's kinda odd
<Keybuk> the %s are bits of the file that were in core memory, but had no extents on disk
<Keybuk> ext3 indirect blocks maybe?
<soren> Keybuk: What did you use to generate that map?
<ion> keybuk: Both fraggy? In the laptop trace, there arenât many entries with >1 extents. Or am i reading it wrong?
<Keybuk> soren: ureadahead
<ion> keybuk: http://pastebin.com/f9f77331 btw :-P
<ion> keybuk: Pretty pre-start
<Keybuk> heh
<Keybuk> oh, sorry, I opened the desktop log twice
<Keybuk> you're obviously right that your laptop is a lot less fraggy ;)
<Keybuk> this also explains why it's the "I upgraded from warty" crowd who also have the most problems with sreadahead
<Keybuk> soren: if you were after the technical explanation
<Keybuk> for each file, open() and mmap()
<Keybuk> then use mincore() to identify what bits of the file are in the page cache
<Keybuk> iterate over that to generate a series of in-memory chunks
<Keybuk> and use the FIEMAP ioctl() to convert that to a list of on-disk extents
<Keybuk> ie. that file has one contiguous chunk in memory, but is actually split across 9 disk locations including a gap
<ion> keybuk: So, after having made the determination that thereâs nothing wrong with the short try_mounts function, i spent 1Â½ hours crawling through the logic of mountall, trying to keep track of state from the log attached to the bug report, until i finally took another look at try_mounts and realized all = TRUE was set on the wrong side of the start of the while loop. ;-)
<Keybuk> ion: oh?
<Keybuk> how would that help
<Keybuk> elmo's problem was that by the time he got to try_mounts(), newly_mounted was FALSE, so it never determined that everything was mounted so never exited
<ion> Iâll pastebin what i think happened on his system, a moment...
<ion> keybuk: http://pastebin.com/m26780454
<Keybuk> ion: oh, that makes sense
<Keybuk> all needs to be set to TRUE at the top of the loop?
<ion> keybuk: http://bazaar.launchpad.net/~ion/ubuntu/karmic/mountall/karmic/revision/141
<Keybuk> ion: can you mail that to me? :p
<ion> keybuk: I already did. :-P
<soren> Keybuk: Does ureadahead exist anywhere except your laptop? :)
<Keybuk> soren: I gave ion the URL :)
<Keybuk> it's just the tracer code at the moment
<ion> http://zelda.netsplit.com/~scott/ureadahead.tar.gz
 * ion realized he just typed the command â/last ureaâ
<soren> Keybuk: Ah, there it is. Neat.
<Keybuk> ion: urea is an interesting name ;)
<ion> keybuk: Also, iâm quite certain itâs okay to have the delayed_exit call within the while (newly_mounted) loop. mounted() is called (and sets newly_mounted = TRUE) whenever mountall itself manages to mount something or it notices from mountinfo that something else mounted what it was waiting for. (As i mentioned, moving the delayed_exit call outside the loop caused the call to happen on every such main loop iteration that had newly_mounted == FALSE, which ...
<ion> ... was bad).
<Keybuk> yeah I think you're right
<Keybuk> I'll get elmo to test after RC
<ion> In fact, iâm totally certain itâs okay, but now that i said it, iâm sure someone bumps into some obscure code path that makes it not okay. :-P
<Keybuk> I'm truly horrified by how many corner cases there are in mounting filesystems ;)
<davmor2> Keybuk: will you hate me if I assign bug 457496 in your general direction.  /me runs for cover
<ubottu> Launchpad bug 457496 in usplash "fscking is ugly in usplash" [Undecided,New] https://launchpad.net/bugs/457496
<Keybuk> davmor2: ion already has a fix for that
<davmor2> Yay :)
<davmor2> can I assign it to you then ion
<ion> Well, iâve done all i can, someone with teh access just needs to upload it. :-P
<Keybuk> assign it to me, since I'll be the one to sponsor it in
<davmor2> Keybuk: sweet
<ion> Looks like a duplicate of bug #215666, though.
<ubottu> Launchpad bug 215666 in usplash "fsck messages are not cleared from usplash when check is finished" [Undecided,Confirmed] https://launchpad.net/bugs/215666
<pitti> kees, mdeslaur, jdstrand: unping, we solved it; local problem
<ion> pitti: Out of curiosity, what was the cause?
<pitti> ion: a backup cron script messed up permissions of /bin, /lib, etc.
<pitti> but I didn't have that idea on the phone, I actually had to travel here :)
<ion> Ah, you donât have teleport transportation in Germany yet.
<mantiena> hello all
<mantiena> evand: hi, today is translation freeze do you have any plans about updating Karmic ubiquity translations from launchpad ?
<evand> mantiena: ah, thanks for the reminder.  On it now.
<mantiena> I've found several problems in Lithuanian translation and I'm fixing these right now
<evand> okay
<evand> mantiena: do let me know when you're done
<slangasek> for ubiquity, or for ubiquity-slideshow?
<evand> ah right, the exception is only for the slideshow, if memory serves
<mantiena> evand: could you wait for ~2 hours, I wanna export debian-installer and ubiquity-debconf translations and test it in real installation (I wanna be sure to have final version without problems)
<slangasek> because the nonlangpack translation deadline was /last/ week
<dpm> slangasek, ubiquity-slideshow -> bug 452889
<ubottu> Launchpad bug 452889 in ubiquity-slideshow-ubuntu "NonLanguagePackTranslationDeadline exception request" [Medium,Triaged] https://launchpad.net/bugs/452889
<slangasek> dpm: yes, I'm just trying to clarify if that's what mantiena is asking after
<dpm> ah, ok
<mantiena> evand, slangasek: you will update only ubiquity-slideshow translations, not d-i and ubiquity-debconf?
<slangasek> mantiena: correct, no further updates are planned for those other packages unless critical bugs are found
<mantiena> evand: so, now I can fix only slideshow translations? you will not update ubiquity-debconf and d-i translations from launchpad.net ?
<evand> correct
<evand> sorry
<mantiena> evand: ok, I will work now only on slideshow translations, I will inform you when I finish
<evand> mantiena: thanks!
<ion> kees: Is your latest commit to mountall really the way to go? It leaves âcannot yet be mountedâ messages to the screen even after successful mounts. (Cc: Keybuk)
<ion> kees: IMHO, that part of mountall code should be left as it was; the CLEAR commands that were originally there will work as soon as my usplash change is published.
<Keybuk> I think kees's complaint is that it clears at all
<Keybuk> he likes verbose boot logging
<slangasek> having mountall clearing interleaved with boot messages from other services certainly seems problematic to me, for the !quiet case
<Keybuk> though I don't think his patch is right either
<Keybuk> because that means it'll always look like the "mountall singing about gold" case is scrolling text
<ion> To implement the thing *properly*, usplash or equivalent should have a socket that would listen to distinct connections, and it could provide each connection a variable-sized area for text output, keypress input, progress etc. and kill each area on the corresponding client disconnection. The user could switch between cryptsetupâs password request and mountall waiting for Esc with the tabulator. :-)
<ion> I guess that wonât happen for karmic. :-P
<ion> In fact, mountall probably should create a connection for each action currently in progress. Every one of them could have its own progress widget and listen to Esc separately.
<ion> (Of course, things could be multiplexed to a single connection, but that might be unnecessary optimization.)
<ion> keybuk: â :-)
<ion> The splash program could render the equivalent thing to text console as well, so clients wouldnât need to handle the console fallback themselves.
<slangasek> ion: they already have to handle the case where usplash isn't running, though?
<ion> So make this hypothetical splash thing a dependency. :-P If it doesnât manage to display a graphical splash, itâll at least open a pretty text UI on a VT.
<mvo> Riddell: hm, I'm still seening issues with my kubuntu hardy->karmic upgrade, now http://paste.ubuntu.com/299039/
<mvo> Riddell: it did work flawless for you?
<Riddell> mvo: it works flawless for me from a stock hardy Kubuntu install, that's not the same as working with a load of extra things installed as most users will
 * mvo nods
<mvo> Keybuk: could you please have a look at http://paste.ubuntu.com/299039/ (happens during hardy->karmic) - is the "invoke-rc.d udev reload" problematic ?
<cr3> primes2h: thanks for the email report about the anti-slashes in checkbox, those are unfortunately needed to indicate the following newline should be ignored. so, they're not meant to be like \n, they're meant to enable the template files to be more readable by having long lines wrapped
<asac> can we upload to karmic-proposed already?
<primes2h> cr3: Do you mean we have to report them also in the translated strings?
<cr3> primes2h: if you simply translate pagraphs as a single line, then you don't need any anti-slashes at all
<dpm> cr3, primes2h, thanks a lot for the work on getting those strings translatable and announcing it to translators! One question folks have been asking is how to translate strings such as https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+pots/checkbox/ca/25/+translate How should the translations be done in the case of backslashes? Just translate them as they are? Could they be perhaps substituted by newlines instead at some futute ve
<dpm> rsion?
<dpm> future, I meant
<cr3> dpm: \ != \n, it's actually the opposite, the anti-slashes are meant to express "no newline" :)
<dpm> oh
<primes2h> cr3: in the po the \ are reported as \\
<cr3> dpm: I didn't foresee this kind of problem and it's unfortunate that even newlines are being wrapped into a single line in the translation interface
<primes2h> cr3: and launchpad report it as \
<primes2h> in the translation UI
<cr3> primes2h: and how are the newlines reported?
<primes2h> cr3: in po is \n
<cr3> dpm: to answer your other question though: yes, this will definately be addressed early in the lucid cycle
<primes2h> and launchpad report it as a graphic symbol
<cr3> oh crap, there seems to be a bug in [type: gettext/rfc822deb] which is stripping out text!
<primes2h> cr3: example https://translations.edge.launchpad.net/ubuntu/jaunty/+source/xubuntu-docs/+pots/printing/it/64/+translate
<cr3> primes2h: I think I can workaround this problem for now, let me try something out...
<dpm> primes2h, I don't quite understand the problem there. Launchpad uses the graphical symbols to better highlight spaces, it's always been like that
<dpm> on the string you were pointing to ^
<primes2h> dpm: I was just explaining cr3 how launchpad show the \n
<dpm> primes2h, ok, gotcha
<pitti> jono: PAE kernel> 4 GB? I wish ..
<jdstrand> kirkland: are you planning a libvirt upload?
<jdstrand> kirkland: hi btw!
<kirkland> jdstrand: howdy
<kirkland> jdstrand: i don't have anything
<kirkland> jdstrand: why?
<jono> pitti, lol
<jdstrand> kirkland: cause I have something that could be incorporated into it
<jono> yeah this is the problem we are finding, few people have that hardware
<jdstrand> kirkland: but, if you don't, I guess I'll just SRU it
<kirkland> jdstrand: i wish i had a fix for the audio hangs, etc.
<kirkland> jdstrand: but i don't yet, sadly
<jdstrand> kirkland: did you see dtchen's comment?
<kirkland> jdstrand: nothing pending on libvirt on my side
<kirkland> jdstrand: yeah, i did
<kirkland> jdstrand: i'm still trying to tackle it from the qemu-kvm side
<jdstrand> kirkland: that would seem to be the best route, yes
<kirkland> jdstrand: i have a build of qemu-kvm in my ppa that completely disables support for the pa backend in qemu-kvm
<jdstrand> kirkland: though it working without the monitor is intriguing
<Martin_vW> Hello. I just uploaded my first package to a PPA; it's a patched version of libwnck. Of course, as soon Ubuntu releases a new version of libwnck, my version will get overwritten with the most recent one and I have to patch the new version too. Is there a way that e.g. Launchpad will inform me when this happens, so that I don't have to monitor libwnck myself?
<slangasek> jono: why does testing the PAE kernel require a 32-bit processor?
<slangasek> jono: the PAE kernel should also get used if installing i386 on a 64-bit processor
<jono> slangasek, thats what I was told by david who asked Colin
<slangasek> hmm
<pitti> hm, are there really people with a real 386 processor and 4 GB RAM?
<LaserJock> it was fairly common for LTSP servers not that long ago
<pitti> I meant "not 64 bit compatible"
<jono> slangasek, I can modify the testcases page if 64bit processors can be used in the test too
<slangasek> jono: insufficient info to tell if this is a game of telephone, or if there's some code path cjwatson is trying to debug that's specific to 32-bit procs
<slangasek> jono: however, 64-bit procs with 4GB of RAM are certainly much more plentiful, and installing Ubuntu from DVD on such a system should *also* install the PAE kernel, so at least someone could verify that
<jdong> pitti: unfortunately I've been brainless enough to secure 4GB RAM for a core duo laptop.
<jdong> needless to say, though, it doesn't support relocating that PCI memory window so even PAE is not useful on it :)
<pitti> jono: ^ hah, there walks your test victim :)
<jdong> don't we like PAE on i386 for its NX-emulating ability or something like that?
<jono> davidm, ^^ was Colin explicit in specifying 32bit?
<jono> pitti, aha!
<jono> jdong, can you test this?
<jdong> ahhhh!
<slangasek> we made PAE /better/ on i386 with NX emulation; we /like/ PAE for being able to address our memory ;)
<jdong> jono: unfortunately the machine is a server and can't be used to run random stuff right now
<jono> jdong, you won't completely blow it away on a whim? bah
<jono> :)
<jdong> hahaha! A couple people might get upset at me ;-)
<jdong> but I always enjoy taking critical machines down for fun experiments!
<jono> jdong, lol, I imagine
<jono> :)
<jono> no worries
<davidm> jono no, but that seemed to be the test point 64 bit machines can just access memory
<jono> right
<jdong> davidm: 64-bit machines with a 32-bit kernel can't :)
<jdong> I've got one of those at home too with 8GB RAM running XP.
<jdong> that's a good waste of 60% of the RAM.
<jcastro> I have hw for this guys, and the 32bit DVD image, should I go ahead and do it or have the images been updated since yesterday?
<pitti> jcastro: 20091020 is still current
<slangasek> jdstrand: any idea why RAID1/amd64 failed for you but worked for mathiaz?
<jdstrand> slangasek: no clue. I tried to provide as much detail as possible. If I were to hazard a guess, I'd look at partman first, cause I think I started to partition one way, then went back and did it for raid
<ion> Iâd like to switch most of my laptop to amd64, as soon as someone implements the multiarch spec. ;-) Dunno whether it makes any difference with desktop use, but the doubled number of registers should be a theoretical benefit at least.
<jdstrand> slangasek: I provided all the logs in the bug
<jdong> ion: about a 5% speedup on general stuff, as much as 20% on specially tuned routines.... and about 15% more RAM usage.
<slangasek> jdstrand: yeah, the logs don't give me much insight; it looks like grub is saying it can't find device 251,1 - is that supposed to correspond to /dev/md0?
<davidm> jdong, good point
<ion> RAM usage is not a problem, i always seem to have 1â2 GiB of free RAM.
<slangasek> seems a very strange error to affect only some testers
<pitti> ion: day to day use feels the same, but compilation is up to 30% faster for me (due to registers, I suppose)
<jdong> yeah compilers are A LOT faster
<jdong> forgot to mention that :)
<jdstrand> slangasek: it didn't. I checked that. I accidentally blew the machine away, but it was not 251, 1. I believe it was 9, 1
<jdong> ion: Well RAM usage contends with disk cache availability which sometimes is a cripple to performance at hand :)
<davidm> jcastro, test the memory detector code and see if you get back the correct amount of memory that is the critical question
<slangasek> jdstrand: hmm; what about vda1?
<pitti> ion: it's really just adobe flash that's missing; swfdec works well enough for me, though, so I don't care and don't need ia32-libs
<davidm> If you do, we have a logic bug, if you don't then the memory detection code needs to be fixed.
<pitti> brw-rw---- 1 root disk 9, 125 2009-10-22 16:03 /dev/md125
<jdong> ugh flash on 64-bit is in a nightmare-ish state on Karmic right now :)
<jdong> hopefully that clicking bug magically disappears by release
<pitti> slangasek: /dev/md is major 9, yes
<slangasek> pitti: what's major 251?
<maco> jdong: whats yours doing? on mine flash stops working if firefox's uptime is too high
<pitti> slangasek: firing up KVM to verify
<hyperair> md125? you seriously have 125 raid devices? O_o
<pitti> hyperair: no, that's the one that my devkit-disks test suite creates and uses
<jdong> maco: not accepting any mouseclicks unless both buttons are held or ctrl/shift are held
<jdong> maco: the bug is highly correlated with compiz being active.
<maco> hyperair: i think you read that wrong
<pitti> hyperair: I create an md from /dev/ram0, so that I can test dk-disks without actually destroying anything
<jcastro> davidm: ok, that shouldn't be a problem. Does it absolutely need to be on the real hw or is a VM sufficient? (struggling with my physical DVD burner at the moment)
<hyperair> ah cool
<hyperair> i see
<jdong> maco: that's bug 410407
<ubottu> Launchpad bug 410407 in flashplugin-nonfree "flash does not recognise mouse clicks" [High,Confirmed] https://launchpad.net/bugs/410407
<maco> jdong: lovely. and just soooo discoverable!
<keybuk> jdong: really?
<keybuk> 64-bit flash is delightful for me
<keybuk> for the first time in years, youtube works every time ;)
<davidm> jcastro, Real HW it seems to work in a VM
<hyperair> keybuk: agreed.
<jdong> keybuk: well I'm using flashplugin-nonfree from the repositories
<keybuk> jdong: oh, don't use that
<davidm> jcastro, but you don't need to do an install, just run the memory test first
<keybuk> go download the real genuine 64-bit deb from adobe.com
<jdstrand> slangasek: I don't have a virtual machine with virtio atm. I think pitti will be faster than I atm
<hyperair> there's a 64-bit deb?
<jdong> keybuk: :) native 64-bit flash used to crash on me quite an amusing amount...
<hyperair> i downloaded the tar.gz
<jdong> I guess I'll try that again.
<pitti> slangasek, jdstrand: confirmed; /dev/vda* is major 251 (that's kvm virtio)
<jdong> people on the bug report claim even gmail causes the crash
<davidm> jcastro, Then if the memory test is good, and you have time the install is worth while
<keybuk> flash, on nvidia, on amd64, with compiz
<davidm> And the more I think of it testing both on 32 but and 64 bit becomes more important
<jdong> keybuk: but do we plan on milestoning any fix for the bug? Kinda sucks that the magical default recommended way of using Flash on amd64 doesn't work.
<keybuk> now there's a combination forbidden to appear on question time
<jdstrand> slangasek: I can tell you I did tell it to boot in degraded mode
<slangasek> pitti, jdstrand: aha - thanks, if it's kvm-specific I'll leave it there for now
<slangasek> jdstrand: would be good to have this info added to the bug report
<pitti> slangasek: we already had weird kernel bugs with virtio+some particular image types (non-raw) in jaunty, didn't we?
<maco> question time? what is question time?
<pitti> I just use raw images, though, I never noticed problems
<jdstrand> I use qcow2
<slangasek> pitti: I don't know, I have no hardware with vmx
<pitti> jdstrand: right, that was the one which caused (guest) kernel oopes in conjunction with virtio earlier
<jdstrand> pitti: there were definitely problems in the past, but kirkland tells me they are fixed now
<pitti> slangasek: no, was just FYI; some of these bugs could still be there and manifest as bugs like that one
<pitti> but it's just pure hypothesis
<jdstrand> pitti: I can say the kernel didn't oops. it was a grub failure
<jdstrand> slangasek: I'll add it to the bug
<jdstrand> slangasek: I'm not totally sure we can chalk it up to kvm weirdness though. I know mathiaz uses kvm and bet he used virto too and didn't have the problem
<jdstrand> I can try to reproduce
<kirkland> jdstrand: pitti: yeah, i'm using virtio almost exclusively, without problem
<jdstrand> kirkland: do you use qcow2 or raw?
<kirkland> jdstrand: qcow2
<jdstrand> kirkland: would you mind peaking at bug #457687? I'm not up on how raid is setup in the installer
<ubottu> Launchpad bug 457687 in debian-installer "error: Running 'grub-install --no-floppy "/dev/md0"' failed." [Undecided,New] https://launchpad.net/bugs/457687
<jdstrand> peeking
<jdstrand> kirkland: keep in mind, /dev/md* is major 9 and /dev/vd* major 251
<ccheney> i installed karmic last night and noticed that the english localizations weren't completely installed, when i went to language support it asked me to install the rest, is that a known issue?
<kirkland> jdstrand: my focus is elsewhere at the moment; cjwatson re-did the raid grub install stuff for karmic and grub2
<dpm> ccheney, if I'm not mistaken, that might be bug 434173
<ubottu> Launchpad bug 434173 in update-manager "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [High,In progress] https://launchpad.net/bugs/434173
<slangasek> ccheney: known,milestoned,triaged...
<jdstrand> slangasek: you know, I *did* sete the bootable flag for each of the /dev/vd* partitions that made /dev/md0
<slangasek> jdstrand: surely that shouldn't prevent grub from being able to find the device?
<wasabi__> jcastro, you're coming to my city!
<jdstrand> slangasek: I really have no idea. I am just providing info (I'm no grub/raid expert)
<cr3> primes2h and dpm: I won't be able to do anything regarding the anti-slashes for this release, just ignore them for now
<primes2h> cr3: ok, but the question is...
<dpm> cr3, thanks for your work anyway. What's your recommendation for translators regarding the anti-slashes? Skip them or use them in the translations they do?
<primes2h> cr3: translated strings with \ will appear correctly?
<mantiena> evand: it seems translation process was slower than I planned... How much time I have for finishing ubiquity-slideshow translations?
<cr3> dpm: skip them
<evand> I *think* until the end of the day.  slangasek?
<cr3> primes2h: the problem is that if you use a slash, it will appear as is unless it is followed by a newline
<slangasek> evand: you're doing the upload, right?  whenever you need the cutoff to be in order to get the upload done today
<evand> I'll be here late working on the PAE bug, so evening BST.
<evand> err late evening, say 10pm
<primes2h> cr3:  if we put a \ on launchpad it's reported as a \\ in the po.
 * ion hopes lucid will have a non-crippled pulseaudio. :-)
<davmor2> ion: It's a lot better this time as far as I've seen, certainly more stable.
<ion> In karmic, flat-volumes and rtkit have been disabled. :-\
<ion> But itâs understandable, they came in too late to the release cycle.
<primes2h> cr3: On the other hand, does checkbox manage CR correctly on the UI if we don't put the \?
<cr3> primes2h: yes, lines are wrapped correctly
<mantiena> evand: can you tell how many hours I have for translation - I don't know your localtime, so, it would be simpler to know how many hours ;)
<cr3> primes2h: both in the command line and the graphical interfaces
<evand> mantiena: 5 and a half.
<primes2h> cr3: ok, so we'll put strings as one line only.
<cr3> primes2h: actually, fyi, the lines are merged by the parser when \ is followed by a newline, so it will be the same if you just don't use \ nor newline
<mantiena> evand: thanks
<cr3> primes2h: thanks!
<evand> sure thing
<primes2h> cr3: Thank you very much indeed! Could you please explain it in a email and send it to me so I can forward it to the ubuntu-translator ML? We would be really appreciate it.
<primes2h> cr3: I don't want to make a mess :)
<cr3> primes2h: will do, but give me a moment, I'm in the middle of too many things right now :)
<jdstrand> slangasek: ok, I reproduced it
<jdstrand> slangasek: I kept track of my actions and will update the bug with everything
<slangasek> jdstrand: ok, cheers
<ccheney> slangasek: hmm that bug looks like it was supposedly fixed over a week ago, but i still saw it on the oct 20 disk
<slangasek> ccheney: I don't know what bug you're looking at, but I'm talking about bug #452516
<ubottu> Launchpad bug 452516 in ubiquity ""Incomplete Language Support" for English" [High,Triaged] https://launchpad.net/bugs/452516
<ccheney> slangasek: oh oops i looked at the wrong one, bug 434173, apparently
<ubottu> Launchpad bug 434173 in update-manager "[karmic] Regression from 9.04 in getting fully translated Ubuntu installation" [High,In progress] https://launchpad.net/bugs/434173
<ccheney> ah 452516 does look correct :)
<cytotoxic> !ops
<ubottu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<maco> cytotoxic: whats that for?
<maco> oh gosh another one
<cytotoxic> ban me
<iulian> Yikes.
<maco> or you could just go away...
<slangasek> cytotoxic: why?
<ruku> Eee O: So excited about 9.10.
<ruku> Isn't the Release Candidate supposed to be out today?
<julien_c> ruku: yes according to the release schedule, but I think it will come out more towards the end of the day
<ruku> Hee. My friend invited me to his Windows 7 install party today. I'm hoping I get to bring a CD along. 83
<virtuald> ruku: just get a daily
<ScottK> ruku: The current candidate ISOs for RC status will almost certainly be it, so you can download that now.  Most of what's going on now is testing and documentation.
<slangasek> cody-somerville: will there be https://wiki.ubuntu.com/Xubuntu/KarmicKoala/RC for the RC?
<cody-somerville> Yes
<primes2h> cr3: Don't worry, I already did it due to the being in a hurry. Thanks anyway. :)
<slangasek> cody-somerville: now's a good time to post it, then :)
<slangasek> superm1: http://mythbuntu.org/9.10/rc - access denied?  can that be unblocked?
<cr3> primes2h: thanks muchly!
<superm1> slangasek, need to make sure that the mirrors are synched first.  few moments
<ruku> superm1, yeah. I heard not to download until the official announce was out
<slangasek> superm1: website mirrors?
<seb128> I'm surprised we didn't get extra bugs about bug #458250
<ubottu> Launchpad bug 458250 in example-content "Examples folder has no icon" [Undecided,New] https://launchpad.net/bugs/458250
<superm1> slangasek, download mirrors.  we have our download URL in there too
<superm1> we don't let cdimages.ubuntu.com take "all" the pain :)
<kees> jdong: PAE on i386 gets you _real_ NX.  Without PAE, i386 does the partial nx-emulation.  PAE gets you >3G memory ability, though.
<jdong> kees: *nods* gotcha
<slangasek> superm1: well, the mirrors can't possibly be current yet, because I haven't pressed the button?
<LaserJock> slangasek: do I need to write anything up for Edubuntu?
<slangasek> LaserJock: there's content is https://wiki.ubuntu.com/KarmicKoala/RCAnnouncement, which is fine; there's no need for you to write anything, I'm just making sure that any links I'm expecting from others based on past practice aren't going to be dead links
<slangasek> s/is/in/
<superm1> slangasek, yeah it looks like they aren't in order yet indeed.  so  iguess for now we can just link to cdimages, and then update it to the mirrors once they are ready
<superm1> slangasek, okay it's ready
<slangasek> superm1: ok - mirrors should be able to sync now, also
<superm1> thanks
<dpm> primes2h, thanks for your e-mail to ubuntu-translators
<primes2h> dpm: You're welcome :)
<primes2h> dpm: we are in a hurry, so I have tried to do all I could to help.
<dpm> primes2h, that was great, thanks
<Armageddon> hello guys, I have a question to ask... I think only you can help me out cause you know more about this
<Armageddon> I have a bluetooth on my laptop, used to work fine on 8.10, stopped on Jaunty, during the updates process it worked for a while and then another update made it stop again, I don't know which did any, and on Karmic is does not work either, any idea ?
<Q-FUNK> howdy! what's missing to get #456598 into Karmic?
<highvoltage> Q-FUNK: according to the bug report asac did fix it but the upload didn't make it to the archive
<Q-FUNK> highvoltage: that, I've already noticed.  I'm wondeirng what's missing to get it to make it to the archive.
<dupondje> can somebody check
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<highvoltage> Q-FUNK: sorry for have stating the obvious :)
<Q-FUNK> highvoltage: I wondered if it might be stalled by the general freeze or something similar.
<LaserJock> Q-FUNK: seems like a likely guess
<Q-FUNK> LaserJock: indeed so, but I need a binding answer.  right now, introducing this new FF just 2 days before the final freeze has proken this plug-in, which, in turn, breaks one language pack.
<Armageddon> Guys, I have bluetooth on my laptop, Toshiba Satellite A300-17G, AMD64 CPU with x86-64 Kernel, bluetooth used to work fine on 8.10, stopped working on 9.04 till one update made it work and I don't know which update did that, and then another update made it stop working again, now on Karmic it doesn't work either, any idea ?
<Martin_vW> I've uploaded a package to my PPA, but update-manager always displays a warning that the package is unauthenticated, although I've imported the key. I looked into the repository and noticed that there is no Release.gpg file... could this be the problem's source? http://ppa.launchpad.net/martin.von.wittich/libwnck-nodimming/ubuntu/dists/karmic/
<ccheney> Grr what is wrong with launchpad I can't upstream a bug because the page is fubar
<ccheney> bug 456434
<ubottu> Launchpad bug 456434 in openoffice.org "shouldn't use bmp bitmap files" [Undecided,New] https://launchpad.net/bugs/456434
<ccheney> click also affects project and some weird page displays that doesn't seem to have anything to do with OOo
<ccheney> argh someone fscked the upstream link for OOo
<ccheney> we really need ability to lock things like that to only bugsquad or some smaller group of people
<ccheney> someone decided to change the OOo upstream to ubslax
<ccheney> whatever that is
 * ccheney thinks he managed to fix it, but would be good to be able to find out who the joker is changing things to the wrong settings
<Riddell> mdeslaur: do you have anything I can test for the fix for bug 457985 ?
<ubottu> Launchpad bug 457985 in poppler "poppler 0.10.5-1ubuntu2.4 regression since -1ubuntu2.2" [Undecided,Confirmed] https://launchpad.net/bugs/457985
<mdeslaur> Riddell: I've added Okular to our test suite so it doesn't happen again
<mdeslaur> Riddell: the new updates are built, I'll push them out in about an hour
<mdeslaur> Riddell: I can put new binaries somewhere if you want to test. What release/arch do you want?
<Riddell> mdeslaur: jaunty i386 would be lovely
<mdeslaur> Riddell: sure, hold on a sec
<ccheney> whatever is going on it appears 'ubslax' people are linking a lot of packages upstream to themselves for whatever misguided reason
<ccheney> jcastro: any idea about the above?
<slangasek> ccheney: where exactly does that link to?
<slangasek> (is it even good faith, or is it spam?)
<ccheney> slangasek: https://launchpad.net/ubslax
<jcastro> ccheney: I just fixed one yesterday but I didn't know they did it for other things
<ccheney> slangasek: not sure what it is, but breaks upstream linkage
<jcastro> yeah, you need to delete their link
<ccheney> pidgin apparently is set that way, as was OOo until i fixed it
<ccheney> i imagine probably everything shown in their distribution list
<ccheney> eg openjdk-6 also shows it
<jcastro> ok the project seems to be a one person operation, I'll send the person a mail now
<ccheney> looks like there are only 10 packages in the list so its not too bad
<jcastro> ccheney: thanks for the tip
<ccheney> jcastro: thanks for the following up on it :)
<mdeslaur> Riddell: my apologies for the Orkut regression
<Riddell> mdeslaur: yay, package updates work
<mdeslaur> Riddell: cool
<mvo> Martin_vW: yeah, if the ppa has no release.gpg, that is the problem. I think that needs discussion with #launchpad or a bug against soyuz
<pitti> jdstrand: just posted a question to bug 456893; would be great if you could answer soon
<ubottu> Launchpad bug 456893 in evince "adjustment of tunables/home may be needed for evince and firefox-3.5 users" [Undecided,Incomplete] https://launchpad.net/bugs/456893
* slangasek changed the topic of #ubuntu-devel to: Ubuntu 9.10 RC released | Archive: Final Freeze! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> zul: please don't close MIR bugs.
<zul> slangasek: sorry
<pitti> slangasek: ooh, congratulations!
<slangasek> pitti: yes, please
<slangasek> heh, ECHN
<slangasek> AN
<slangasek> pitti: "thanks" :)
<jdstrand> pitti: done
<cumulus007> Hi, I'm a translator for the Dutch translation team on Launchpad and I noticed that lots of the Ubuntu documentation isn't localized to Dutch, while the translations are fully completed on Launchpad
<cumulus007> I think this is not really motivating and I'm wondering why this happens
<dpm> cumulus007, would you mind coming to the #ubuntu-translators channel to see if we can sort out what's happening?
<dpm> mdke, you might also be interested in that, if you are around ^
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 -> can somebody check to fix this crap bug ?
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<sebner> jdstrand: do you plan to do some sync processing (universe) tomorrow?
<pitti> lamont: any idea why crested is disabled?
<pitti> we're a bit low on buildd power right now (and have a full queue)
<pitti> Keybuk, doko__: does it actually make sense to accept this sreadahead upload? sparc is still busted due to the sigbus (but a patch was posted), and slangasek said that the -pthread issue is just for mipsen, which we don't care about?
<pitti> Keybuk: util-linux removes libs/blkid/Makefile.in and more Makefile.ins, but it doesn't b-dep on automake; was that intended?
<pitti> lamont, elmo: would you mind killing the build on rothera? the other buildd builds a newer gcc, and we need the horsepower now
<mdeslaur> Riddell: New poppler packages were published. Regression should be fixed now.
<elmo> pitti: done
<pitti> elmo: many thanks!
<lifeless> slangasek: are you aware of https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 ?
<ubottu> Launchpad bug 457688 in python-visual "libboost-python1.38 issues with __doc__ property in Python >= 2.6.3" [Undecided,Confirmed]
<ScottK> lifeless: I think it's SRU material unless ajmitch found a patch.
<lifeless> so
<lifeless> upstream python say 'not a bug, grab the new boost'
<doko__> pitti: I don't mind
<lifeless> but the new boost isn't released yet
<ScottK> Yeah.  ajmitch was trying to find the fix in their VCS yesterday.
<lifeless> oh cool
<ScottK> I don't think he succeeded though.
<Keybuk> pitti: those might be empty directories
<Keybuk> I run autogen before making the util-linux package
<Keybuk> did it FTBFS?
<pitti> Keybuk: I just reviewed the diff
<pitti> I accepted it anyway (more or less by accident)
<Keybuk> pitti: ok
<Keybuk> sreadahead > no harm in accepting it if the patch is right ;)
<ajmitch> ScottK: you're right, I didn't find anything yet
<pitti> Keybuk: I don't know whether the patch is right, I don't understand the -pthread change; I don't mind the sparc change, since it'll be broken either way
<mantiena> Hi evand, still not in bed ? ;)
<evand> mantiena: correct :)
<evand> mantiena: all set?
<mantiena> evand: still fighting with latest slide: ubiquity-slideshow-ubuntu-rhythmbox-totem
<evand> okay, I can wait a bit longer
<mantiena> evand: is seems I finished the Lithuanian translation of all ubiquity-slideshow-ubuntu templates :)
<evand> mantiena: great!  I'll import them now.
<trunet> hello guys
<trunet> look, I upgraded to karmic today
<trunet> and now I can't set a ipv6 address to a bridge I have
<trunet> # /sbin/ip ^Cdr add 2001:470:x:x::1/64 dev virbr0
<trunet> RTNETLINK answers: Permission denied
<trunet> the ip is masqued
<trunet> (there's an error in commandline, Ill post again)
<trunet> # /sbin/ip addr add 2001:470:x:x::1/64 dev virbr0
<trunet> RTNETLINK answers: Permission denied
<trunet> it works with ipv4 and setting this same ipv6 to a physical interface works too
<mantiena> evand: thanks for improving ubiquity - I was waiting for slideshow feature since 2005, I worked together with spanish guys, who created ubuntu-express installer, which was ubiquity predecessor and Baltix GNU/Linux 2005 (based on Ubuntu 5.10) installer, was with slideshow feature ;)
<evand> :)
<mantiena> evand: btw, ~12 hours ago I've fixed 2 important Lithuanian translation problems in gfxboot-theme-ubuntu package - previous translation used 2 words for translating "F5 Accessibility" and because of this "F6  Options" doesn't fit in ISOLINUX boot menu :(, are there any chances to see updated translations in final 9.10 CD's?
<evand> I don't believe so, but it's the release team's call to make (#ubuntu-release)
<maxwellian> Hi, can anyone point me in the direction of a document that clearly describes how to patch a package and then be able to install it to test it, and possibly revert back when I'm done?
<mantiena> evand: ok, I asked about this in #ubuntu-release. If you will need to make one more ubiquity build before release - please update d-i and ubiquity-debconf translations from launchpad, there I also have improved some translations today ;)
<rickspencer3> robert_ancell, hi
<robert_ancell> rickspencer3, hi
#ubuntu-devel 2009-10-23
<crypt-0> hi
<crypt-0> im having trouble with wxpython.
<crypt-0> it is well beyond the #ubuntu help channel.
<directhex> it's official: the only Ubuntu release whose Mono footprint is smaller than Karmic, was Edgy
<cody-somerville> is this.... good?
<directhex> cody-somerville, well, tomboy/f-spot take up 12 meg less room on karmic than intrepid
<directhex> and slangasek tends to like megs
<cody-somerville> :]
<Sp3c1alK> what's a good, current, website that walks through writing a driver for ubuntu?
<directhex> Sp3c1alK, what kind of driver?
<Sp3c1alK> networking, TCP/IP
<directhex> yeesh, that'll be kernel then
<directhex> there's nothing specific to ubuntu. you want something on kernel drivers - and network drivers specifically
<slangasek> ccheney: why did -human drop from a Depends to a Recommends of -gtk?
<Sp3c1alK> oh boy, I better test in a vmware machine then, heh
<wgrant> Is anybody else seeing the Examples desktop icon in Karmic RC as just a white page?
<StevenK> wgrant: I heard seb mention that, but I'm not sure if there is a bug
<robert_ancell> slangasek, can you look at the updates in bug 437167, bug 458709 and bug 458713 for Karmic?
<ubottu> Launchpad bug 437167 in deskbar-applet "libdeskbar-tracker does not install the module at the right place" [Medium,Triaged] https://launchpad.net/bugs/437167
<ubottu> Launchpad bug 458709 in brasero "Update to 2.28.2" [Wishlist,New] https://launchpad.net/bugs/458709
<ubottu> Launchpad bug 458713 in gnome-utils "Update to 2.28.1" [Wishlist,New] https://launchpad.net/bugs/458713
<ccheney> slangasek: followed the debian packaging convention, did it cause a problem for the seed? recommends are autoinstalled (aiui) and so should get pulled in anyway and its not a strict dependency of the -gtk package just should be there (eg more a recommends association)
<ccheney> slangasek: convention wrt debian packaging moving its tango dep to recommends in the past update
<slangasek> ccheney: "following convention" is not a good reason for a post-RC change
<ccheney> anyone know what happened to approx wrt its startup mechanism it seems to be missing its initscript
<ccheney> slangasek: did it actually change what is installed we automatically install all recommends at install time (right?) so its not a effective change?
<slangasek> ccheney: no, it doesn't change the automatic install, but it's still superfluous :)
<ccheney> ok :)
 * ccheney was hoping he didn't uncover more apt bugs
<ccheney> already hit one of those recently, heh
<ccheney> apparently apt had issues coping with one of my pre-depends
<snap-l> I'm not sure if I've hit a but with the postgresql upgrade. Would like a small hand to sort it out, if possible.
<snap-l> Having trouble logging into postgresql after upgrading to Karmic. I know there's a debconf message that needs to be followed, but I didn't get all of the info. Is there a way to get that info after the fact?
<snap-l> I don't think the upgrade from 8.3 to 8.4 happened.
<ccheney> hmm approx runs under inetd now
<crypt-0> does Karmic? have better SMP support?
<ccheney> does inetd not listen on localhost by default?
<virtuald> crypt-0: Karmic supports 4096 cpu's
<ccheney> hmm even using the external ip doesn't work
<ccheney> does inetd even work on karmic?
 * ccheney thinks it isn't installed or something
 * ccheney wonders how that works with packages needing inetd but not depending on any and none being installed by default
<ccheney> hmm nm it is installed
<ccheney> it seems it needed to be restarted
 * ccheney wonders why it wasn't running already though
<directhex> virtuald, thinking about it, why? there's no SSI hardware with that core count
<wgrant> snap-l: IIRC it will have installed a new 8.4 cluster, on 5433
<wgrant> Leaving the 8.3 cluster intact on 5432.
<snap-l> wgrant: OK, so how do I get the data from 8.3 to 8.4?
<snap-l> The instructions were displayed at a time when I couldn't really follow them. :)
<wgrant> IIRC pg_upgradecluster is what you want.
<wgrant> But I haven't done it in a long while...
<snap-l> sudo pg_upgradecluster 8.3 main
<snap-l> Error: could not get cluster default encoding
<wgrant> snap-l: The debconf prompt suggests that you will need to drop the 8.4/main cluster first.
<snap-l> There's no default encoding set, afaict.
<wgrant> But I don't know about that error.
<wgrant> And it is offtopic for here.
<snap-l> no worries.
<snap-l> Thanks
<crypt-0> (4096) i plan on 1 quad core :)
<pitti> Good morning
<pitti> ArneGoetje: can you please mark http://launchpadlibrarian.net/34200734/ubuntu-karmic-translations.tar.gz (the 20091023 export) as "current" in LP? it still says that the 20091008 one is current (which is even older than what we really have)
<pitti> dpm: good morning
<pitti> dpm: can you please mark http://launchpadlibrarian.net/34200734/ubuntu-karmic-translations.tar.gz (the 20091023 export) as "current" in LP? it still says that the 20091008 one is current (which is even older than what we really have)
<dpm> heya pitti, good morning. Let me have a look. Normally Arne takes care of this, so I just have to find out how to do it
<pitti> dpm: ah, don't worry; we can also wait for Arne
<evand> dpm: Just a heads up.  I've uploaded ubiquity-slideshow-ubuntu with the translations update, per bug 452889.
<ubottu> Launchpad bug 452889 in ubiquity-slideshow-ubuntu "NonLanguagePackTranslationDeadline exception request" [Medium,Fix committed] https://launchpad.net/bugs/452889
<dpm> evand, yes, I've seen it, thanks a lot!. I didn't remind you yesterday because I saw that (Lithuanian?) user already did.
<dpm> pitti, I'll try to find out, so at least I know how it goes. I'll just have to wait for the rosetta guys or Arne to turn up and ask them
<pitti> dpm: new packs are building now
<dpm> pitti, ah, brilliant
<mdke> dpm: on the Dutch issue, I hope you sorted it out - I think it is the same chap who filed a bug about it so he should have got the answer by now
<mdke> dpm: now that translated xml is stripped into the langpacks, he'll need to wait for those before the translations appear
<dpm> mdke, hi, thanks for coming back to me. I think we sorted it out, but it's pending on the next language packs to be built and released before we can check it out
<mdke> right
<dpm> mdke, yes :-)
<dpm> mdke, Martin tells me that they are building now
<mdke> awesome
<ion> Shipit problems? It appears iâve been sent a jaunty CD, even though i ordered a karmic one. #  1 CDs requested on 2009-10-16. 1 CDs were approved and sent to the shipping company on 2009-10-20. Please note requests usually take from 4 to 6 weeks to deliver, depending on the country of shipping.
<wgrant> ion: ShipIt likes to lie like that. I believe it means that the order has been approved and sent off.
<ion> wgrant: Alright, thanks
<jussi01> wgrant: you can order karmic cd's already? o.O
<wgrant> jussi01: For a few days now.
<wgrant> As usual.
<jussi01> wgrant: heh... shows how much I know... :D
<debfx> pitti: in hal-info there is a patch with the decription "Some Thinkpads have ACPI brightness controls ..." but it is much more generic as it checks for the existence of /sys/devices/virtual/backlight/acpi_video*
<debfx> is that intended?
<pitti> debfx: I'm not sure; that patch is ancient, and I didn't do it
<pitti> evand: does ubiquity-slideshow-ubuntu get translations stripped? or are they retained in the package? (langpack export is already done, and langpacks are building)
<evand> pitti: retained
<pitti> evand: great
 * pitti accepts
<lool> mvo: Hey there
<lool> mvo: I have an odd APT bug which I'm seeing right now
<lool> mvo: http://paste.ubuntu.com/299650/
<lool> mvo: Some sort of infinite loop where it gets the Release file over and over again
<lool> mvo: I think the server doesn't support if-modified-since/last-modified properly so it could be what causes the issue, but the mirror has been working fine in the last weeks, not sure why it would start doing that now
<debfx> pitti: could you consider adding my patch from bug #415023 to hal-info, it doesn't seem to fix the issue for gnome-power-manager but works with kde powerdevil
<ubottu> Launchpad bug 415023 in gnome-power-manager "brightness is broken on MSI WIND U100" [Undecided,Confirmed] https://launchpad.net/bugs/415023
<YokoZar> what is iwlagn and why is it at 100% cpu
<pitti> debfx: please assign to "pitti"
<pitti> debfx: probably not for karmic final any more, but it could become an SRU
<mvo> lool: let me have a look - is that reproducable if you run it again? if so, you could you please run it with "-o Debug::acquire::http=true" ?
<mvo> lool: and maybe -o Debug::pkgAcquire=true ?
<lool> mvo: http://paste.ubuntu.com/299653/
<lool> mvo: Hmm I connected to t
<lool> I connected to the server and I see a disk has failed
<lool> lighttpd reports things like 2009-10-23 11:16:14: (network_linux_sendfile.c.172) sendfile failed: Input/output error 7
<lool> 2009-10-23 11:16:14: (connections.c.615) connection closed: write failed on fd 7
<lool> mvo: So prob\
<lool> So probably not worth chasing
<mvo> lool: well, still a bug in the apt code to try this over and over again, is that the full http debug log?
<lool> mvo: No it repeats over and over
<mvo> exactly the same ? i.e. no other code than 200 OK ?
<lool> mvo: http://paste.ubuntu.com/299656/
<lool> mvo: that's all I see
<mvo> lool: thanks! let me check the code
<lool> mvo: It looks like APT just processes this gently
<mvo> lool: yeah, it seems like the server is sending it over and over again
<james_w> http://bruynooghe.blogspot.com/2009/10/no-permission-to-see-ubuntu-bugs.html <- points out that the release notes point to bug 354126 about the hibernation issue, but it is a private bug report
<ubottu> Bug 354126 on http://launchpad.net/bugs/354126 is private
<james_w> is that a typo in the bug number perhaps?
<lool> mvo: I took a trace
<lool> mvo: And opened it in wireshark
<lool> mvo: http://paste.ubuntu.com/299668/
<lool> that's one exchange
<lool> mvo: looks like the server claims to accept range specifications but doens't
<lool> mvo: Mind if I fix the server now?  do you want the trace?
<mvo> lool: thanks, I think I got what I need
<lool> mvo: thanks for having a look
<mvo> has someone seen something like bug #453444 (syslog filling up very quickly with message and rsyslog not catching that as dups?)
<ubottu> Launchpad bug 453444 in update-manager "/var/log fills up with "all noraml" messages @ about 575/sec fill up the available space" [Undecided,Incomplete] https://launchpad.net/bugs/453444
<slangasek> TheMuso: ubuntustudio-desktop still Recommends: hotkey-setup, but shouldn't... was that inherited from ubuntu-desktop at some earlier stage?
<pitti> ScottK, Riddell: jockey FTBFS> meh, seems python-kde4-dev suddenly stopped shipping pykdeuic4?
<Riddell> huh?
<Riddell> ok I'll look at that too
<pitti> lrwxrwxrwx 1 root root 53 2009-10-16 07:51 /usr/bin/pykdeuic4 -> ../lib/python2.6/dist-packages/PyQt4/uic/pykdeuic4.py
<pitti> which doesn't exist, hmm
<pitti> /usr/lib/pymodules/python2.6/PyQt4/uic/pykdeuic4.pyc
<pitti> /usr/share/pyshared/PyQt4/uic/pykdeuic4.py
<pitti> oh
<pitti> Riddell: this looks like fallout from the pycentral->pysupport migration?
<pitti> Riddell: want a bug report for this?
<Riddell> pitti: yeah go on
<pitti> Riddell: done (bug 458953)
<ubottu> Launchpad bug 458953 in kdebindings "pykdeuic4 does not work any more; broken symlink" [High,Triaged] https://launchpad.net/bugs/458953
<asac> stgraber: hey. wonder if you want a bug about pastebinit man page not really being helpful how to configure .pastebinitrc ?
<Riddell> ccheney: you're uploading openoffice KDE fixes today?
<slangasek> those should have already been uploaded?
<Riddell> maybe he already has
<Riddell> slangasek: yes looks like he has "Fixes wrong filter texts in KDE4 fpicker. (LP: #452518)"
 * slangasek nods
<logari81> should I use apport-collect to add information to a bug reported by someone else if I am affected by this bug to?
<logari81> quote:
<logari81> You are not the reporter of bug 434956.
<ubottu> Launchpad bug 434956 in xserver-xorg-driver-ati "screen backlight off after resume-from-suspend when using ATI KMS" [Unknown,Confirmed] https://launchpad.net/bugs/434956
<logari81> Is that really the bug you want to update?
<dpm> mdke, are you involved in kubuntu-docs packaging as well?
<Riddell> dpm: I think that's just nixternal, who's away this week
<dpm> Riddell, oh, do you know if anyone build kubuntu-docs before NonLanguagePacks deadline las week, then?
<dpm> built
<Riddell> dpm: last upload was four weeks ago
<dpm> Riddell, hmm, that means kubuntu-docs translations were not exported from Launchpad on NonLanguagePackTranslationDeadline and won't appear in the release
<dpm> it will probably have to be an SRU, then
<Riddell> dpm: well we can fix that but I suspect I've long since forgotten how to do it, maybe mdke can help
<dpm> Riddell, now docs translations are included in language packs, so first the package needs to be uploaded (with updated translations) and then the translations are released in the language packs. Since the last language pack before release is building right now, that's no longer possible, but I think it will make a good candidate for an SRU
<Riddell> dpm: where are they included in language packs?
<mvo> Riddell: do you have a idea about bug #457270 ?
<ubottu> Launchpad bug 457270 in update-manager "Kubuntu upgrade from 9.04 t0 9.10 beta failed" [Undecided,New] https://launchpad.net/bugs/457270
<mvo> Riddell: it fails in loadUi("dialog_changes.ui") and the error is very odd
<Christoph_vW1> mksquashfs in Karmic seems miss -le and -be options :/
<Christoph_vW1> but the man page displays them as valid options -and they work in 9.04
<Chris_vW> any idea how to work around the mksquashfs issue? I can't build my software without -le
<Riddell> mvo: no but it'll be a problem in python-kde4 rather than anything to do with update-manager, I'll reassign the bug
<mvo> Riddell: thanks
<dpm> Riddell, do you mean the location where they are installed? Actually, looking at the package I've got installed, it seems that it wasn't migrated to use langpacks, so if it were possible to export translations, rebuild the package with them and do an upload with only the translations changes before release would work. I don't know if that's doable. You are on the release team as well, what do you think?
<Riddell> dpm: I'd happily accept that into the archive, but I've forgotten the exact process to make the package
<dpm> Riddell, let me dig out the wiki page with the -docs documentation...
<Chris_vW> --> https://bugs.launchpad.net/ubuntu/+source/squashfs/+bug/459072
<ubottu> Launchpad bug 459072 in squashfs "missing options -le and -be in mksquashfs" [Undecided,New]
<lamont> so why is it that firefox comes up and sayz "Well, this is embarassing" and then I tell it to restore all of the tabs, and it goes "OK. done" ?
<hyperair> because it has?
<lamont> hyperair: because it fails the first try, and works just fine on retrying
<lamont> which would kinda indicate a, well, you know, bug. maybe
<hyperair> hmm maybe indeed.
<hyperair> maybe it was intentional!
 * hyperair hides
<pitti> kenvandine: desktopcouch> -slangasek| what do SSL URLs have to do with desktop-desktop syncing?
<lamont> I mean, it's really nice that it's so apologetic about it, even though my computer is never apologetic about anything it does.
<lamont> we need a patch to give firefox more personalities
<hyperair> hahahaha
<hyperair> while we're at that, we should give fsck some personality
<hyperair> i've had fsck scold me before
<hyperair> blaming me for something i didn't do (fscking a mounted rw partition)
<kenvandine> pitti, slangasek: desktop-desktop syncing happens with couchdb which uses ssl to talk to one another
<Chris_vW> hmm - looks like squashfs-tools v4 removed support for big endian
 * kenvandine doesn't know allot of those details though
<Chris_vW> then -be and -le should be removed from the man page in karmic
<kenvandine> but allot of what it does is REST calls to one another
<pitti> kenvandine: and it doesn't use SSL for desktop->cloud?
<pitti> kenvandine: i. e. why wasn't that broken all the time?
<kenvandine> pitti, it does
<kenvandine> but it doesn't serve to the cloud
<pitti> ah, it's SSL _serving_
<kenvandine> it is just a client of the cloud
<kenvandine> i assume
<kenvandine> they create a connection to each other, transfer tokens around etc
<sabdfl> what's iceape-flashplugin?
<pitti> sabdfl: iceape is Debian's name for firefox
<sabdfl> thanks pitti. seems to be a known issue with adobe-flashplugin update
<pitti> so I guess it's the flashplugin installer for it
<scheusso> hi. i'm using karmic rc with an intel 945GM(rev 03) (today's fresh install). does anybody know why direct rendering is only enabled when running as root? (my user is in video group, permissions of /dev/dri/card0 is 660, root/video)
<cjwatson> pitti,sabdfl: iceape is Debian's name for SeaMonkey, not Firefox - http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project
<pitti> ah, right, that was iceweasel
<scheusso> should i open a bugreport about this issue ?
<ccheney> Riddell: uploaded it yesterday
<Riddell> sorted, thanks ccheney
<ScottK> mterry: I've got a user who installed an early Alpha and then ended up on upgrade with no syslog at all.  Would you mind having a look at the upgrade log to see if there's anything we need to deal with for upgrades?
<jdong> Please close OpenOffice.org (including an eventually running
<jdong> Quickstarter).
<jdong> err the wording there is.... unusual?
<mterry> ScottK: am busy this second, but bug number?
<ScottK> mterry: Don't have a bug yet.  I'll ask the user to file it.
<mterry> ScottK: k, thanks
<Laney> dholbach: Do you know if example-content is going to get an icon for the desktop shortcut? Looks odd atm
<ccheney> jdong: probably written by a non-native english speaker :)
<dholbach> Laney: there's the symlink icon
<Laney> I just see a blank piece of paper
<Laney> is that the one?
<jdong> ccheney: yeah, my guess too. Would've just been easier to say a 1-liner like "OpenOffice.org must be closed to update it"
<dholbach> Laney: I had kind of an arrow the last time I looked (deleted the symlink now)
 * Laney is in a live cd
<Laney> dholbach: bug 458250 like that but on the desktop
<ubottu> Launchpad bug 458250 in example-content "Examples folder has no icon" [Undecided,New] https://launchpad.net/bugs/458250
<Laney> not sure if it matters
<ccheney> jdong: yea
<dholbach> Laney: hum... not sure
<jdong> ccheney: yeah I applied that update at the CLI, don't know what update manager would show you. If that same message... it's kinda scary :)
<jdong> maybe in Debian world, you actually need to explicitly convince an expert user why he has to close down his big WYSIWYG word processor ;-)
<ccheney> jdong: yea
<Keybuk> bryce_: how much do you care about nouveau failures today?
<mvo> mbiebl: hey! do you happen to know about issues with the rsyslog message duplication detection? there is bug #453444 that indicates its not quite working that well and I see my syslog filling with duplicated messages from the kernel as well
<ubottu> Launchpad bug 453444 in rsyslog "/var/log fills up with "all normal" messages @ about 575/sec fill up the available space" [Undecided,Incomplete] https://launchpad.net/bugs/453444
<mvo> (not quite with the same speed though :)
<cjwatson> Keybuk: is it possible that, when we mount the root filesystem from iSCSI in the initramfs, something is ripping it back out again? bug 457767
<ubottu> Launchpad bug 457767 in debian-installer "karmic: iSCSI root: boot hangs on starting iscsid" [Undecided,New] https://launchpad.net/bugs/457767
<Keybuk> no idea
<cjwatson> any suggestions on where to start looking?
<Keybuk> I don't even know how iSCSI is mounted
<bryce_> Keybuk, I'll care more later
<Keybuk> bryce_: ok, I'll hold off with the bug report then ;)
<cjwatson> Keybuk: nothing magic about the mount; logging into an iSCSI device causes the kernel to make new /dev/sd* devices available
<cjwatson> but it does require networking to stay up :)
<Keybuk> I don't know of anything that rips things down
<Keybuk> disks, networking, etc.
<mvo> mbiebl: is there a reason to not turn on RepeatedMsgReduction ?
<kees> Keybuk: so, what're your thoughts on the "CLEAR" bug I had?
<kees> Keybuk: it seems like slightly a matter of taste (at least the second CLEAR that I removed).
<kees> Keybuk: the first one that repeats regardless of fsck activity is, I think, correct to be removed.
<Keybuk> you need to CLEAR the screen between mountall updates
<Keybuk> so they appear to be at the same point on the usplash output
<kees> right, I didn't change that part.
<kees> Keybuk: i.e. I added a CLEAR before the "Filesystem checks are in progress:" section and removed it outside that check.
<kees> Keybuk: the only contentious change, possibly, is removing the CLEAR when it finishes.
<kees> I wasn't sure about the "displaying_bored" logic
<Keybuk> you want to clear the "I'm bored" bit
<Keybuk> I guess the problem from a non-quiet POV is that mountall's messages are going to be interleaved with others
<Keybuk> and usplash just flat out doesn't support that kind of model ;)
<Keybuk> I think we should just make sure the default case works (quiet), and worry about properly fixing (or throwing away) non-quiet for lynx
<kees> okay, I'll put the latter CLEAR back in.  are there other changes that need to go in?  I'd like to get this uploaded for the selinux fix too.
<Keybuk> there are other changes that need to go in
<Keybuk> please stop rushing
<kees> sorry, I'm trying to give as much time as possible to "stabilization" before final.
<Keybuk> an hour or thinking saves a week of bug fixing :p
<kees> :)
<LaserJock> anybody know the bug # for the issue with incomplete language support after install?
<slangasek> LaserJock: 452516 (on https://bugs.launchpad.net/ubuntu/karmic/+bugs?field.milestone=12698)
<LaserJock> slangasek: thanks, did you see my edubuntu-meta upload?
<slangasek> LaserJock: yes, that's why it's been accepted ;)
<LaserJock> doh, so it has
<Keybuk> bryce_: the fun thing about my nouveau failure is this message...
<Keybuk> [    2.734902] nouveau 0000:02:00.0: GPU lockup - switching to software fbcon
<Keybuk> that's the second nvidia card, without any displays plugged in
<apw> slangasek, i assume you want this dove-z0 meta change uploaded ?
<pitti_> dpm-afk, ArneGoetje, slangasek: argh; the new langpacks are missing quite a few .po files, such as gdm, evolution, glade3, gnome-games, gnome-panel-2.0, gtk2.0; what happened?
<pitti_> dpm-afk, ArneGoetje, slangasek: oh, seems it's just an old gettext on rookery
<pitti_> I'm too easily scared on a Friday afternoon..
<rafferty> anyone have luck with Sound on a Thinkpad x200 with Karmic?
<apw> rafferty, did you ask on #ubuntu+1 ?  that would be my first port of call
<rafferty> tried, no response.
<rafferty> is there an alsa irq?
<apw> its pretty close to release and people are running about like mad people i expect
<apw> slangasek, about?
<zul> anyone know why autofs would conflict would itself?
<Keybuk> sladen: about?
<Keybuk> (re: sreadahead issues)
<Notch-1> how can i stop cron to send tons of mails? or where i can set a valid address in order to avoid my /var/log/mail.* and /var/spool/nullmailer to grow VERY quickly?
<joaopinto> Notch-1, the support channels are #ubuntu and #ubuntu+1
<Notch-1> it's hard to get answer there, 1500 people... and it's a tricky question i think, so if you can help, please do it
<ScottK> Notch-1: It's explained in the cron man page and trouble getting an answer elsewhere doesn't make this a support channel.
<Notch-1> ScottK: yeah, my mans are very short, don't know why... anyway i finally figured it out thanks to wikipedia and some other 100 forums or so... it's not easy to undestand you guys, so i use to ask here, the source...
<wolfe> you know, I really wanted the name to be Orgasmic Koala or some inappropriately funny name ;D
<soren> Can someone with moderator powers for ubuntu-devel please let en e-mail through for me (from nijaba, subject: UEC appliance).
<cjwatson> soren: done
<soren> cjwatson: Thanks very much.
<directhex> cjwatson, did you hear the headline number i produced yesterday? f-spot&tomboy&deps footprint is down by 12 meg from Intrepid (6 meg from Jaunty)
<cjwatson> directhex: I saw, that's pretty cool
<directhex> sadly i think we're hitting the limits of what we can scalpel off
<flower> does aptitude on ubuntu ignores /etc/apt/preferences and /etc/apt/apt/conf?
<Keybuk> directhex: has Mono finally started doing shared libraries? :)
<directhex> Keybuk, in what way?
<Keybuk> if two apps both use Gtk#, do you still get two copies of Gtk# in memory?
<directhex> i haven't checked. i don't think so, but miguel or one of his team is better equipped to answer that
<lifeless> oh, whether it mmaps the file, or copies it in?
<Keybuk> in C, shared libraries are shared in memory as well as on disk
<Keybuk> with the PLT mapped copy-on-write so each app can have its own relocations
<Keybuk> but basically, the entire library memory is shared
<lifeless> all in userspace IIRC
<lifeless> right?
<Keybuk> in Mono, that never used to be the case, and each Mono app needed its own copy of each shared library
<Keybuk> because it did JIT independantly and stuff
<Keybuk> this meant the memory requirements of Mono apps were truly large
<flower> do you use aptitude or apt-get?
<lifeless> yes
<flower> does aptitude on ubuntu ignores /etc/apt/preferences and /etc/apt/apt/conf?
<flower> it seems that apt-get respects it, aptitude not
<hyperair> it shouldn't ignore
<hyperair> what option are you setting exactly?
<flower> for example: http://pastebin.com/m75f77936
<hyperair> what's version * supposed to be?
<flower> all versions
<hyperair> ah
<hyperair> basically disabling pulseaudio from being installed?
<hyperair> i don't see why you'd want to do that. =\
<hyperair> i mean just apt-get remove and it won't come back
<flower> that's another question
<hyperair> ?
<flower> why does aptitude ignore it, that's the question
<Keybuk> it probably doesn't
<hyperair> yeah. something else overrode it probably
<Keybuk> given "aptitude", probably the user
<flower> mmh when I test it with pavucontrol, apt-get doesn't install pulseaudio, aptitude does
<hyperair> aptitude purge pulseaudioblah, followed by aptitude hold pulseaudioblah
<hyperair> i think that should pretty much stick it in position
<Keybuk> flower: yes, but did aptitude tell you it was having to install pulseaudio to solve a solution?
<flower> Keybuk: no
<flower> strange...
<flower> aptitude hold doesn't work either, when testing it with pavucontrol
<Keybuk> don't use aptitude then ;)
<flower> it shouldn't happen... in Ubuntu
<dupondje> final is almost there :)
<dupondje> but still nobody fixed https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 :P
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<Keybuk> flower: why not?  we don't recommend people use aptitude
<joaopinto> dupondje, I don't think that's critical enough to deserver a post RC fix
<Keybuk> use synaptic or ubuntu software centre
<dupondje> joaopinto: I can understand ;)
<dupondje> did build own package now for it
<dupondje> it works here ;)
<flower> is it possible to remove aptitude or is tasksel very important?
<joaopinto> flower, man tasksel
<flower> joaopinto: I don't think I ever used that. Is that an alternative for apt-get?
<joaopinto> flower, read it's manpage :)
<flower> joaopinto: mmh yeah, try to understand it... looks handy for generating debian cds or something
<simon-o> fabrice_sp: Thanks for your comment on bug 459164 I'll take a look at it soon. And thanks for sponsoring my stuff :)
<ubottu> Launchpad bug 459164 in gnoemoe "FTBFS with GCC 4.4" [Undecided,New] https://launchpad.net/bugs/459164
<cjwatson> flower: tasksel is in ubuntu-minimal because the installer needs it. Unfortunately, removing it will also remove ubuntu-minimal, which is *permitted* but it does mean that you may have a harder time on upgrades
<cjwatson> one of these days I should make it dynamically installed or something
<flower> cjwatson: thanks!
<cjwatson> aptitude is definitely kind of heavy for a debootstrapped chroot
<fabrice_sp> simon-o, you're welcome. And thanks, for making Ubuntu better ;-)
<flower> cjwatson: but do you understand why aptitude doesn't listen to /etc/apt/preferences here?
<cjwatson> flower: I don't know about that
<mvo> if the release upgrader is used, ubuntu-minimal will be put back by it if missing. it does not like when its not there
<flower> cjwatson: you guyst always use apt-get?
<flower> *guys
<flower> *smart guys ...
<flower> ;)
 * mvo uses apt-get and is on his way to bed
<flower> apt-get install REM-sleep
<flower> good nicht
<flower> night
<arand> cjwatson: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/445067 is, to me, a rather nasty one, you think there's reason enough to worry/fix before final?
<ubottu> Launchpad bug 445067 in ubiquity "ubiquity overwrites VBR of extended partition" [Undecided,New]
<cjwatson> flower: depends what I'm doing. aptitude has a more capable UI, but I rarely bother
<cjwatson> arand: I'm pretty sure that we've never taken
<cjwatson> arand: ... much care to preserve extended boot records
<cjwatson> so I have a hard time justifying it as an OH MY GOD item?
<cjwatson> I'm guessing it's probably the fact that partman resizes extended partitions as needed
<arand> hmm, fair enough, but I'm kind of bothered since I keep grub there :/
<cjwatson> I'm certainly not denying it's a bug - it just doesn't seem like the sort of regression that means we'd need to use some of the very few hours we have left to fix it
<cjwatson> if it's demonstrated that it doesn't happen with older releases, that would increase the urgency
<arand> also, this happens even if the installer isn't touching the extended (e.g. installing to a different HD)
<cjwatson> um, why do you say extended boot records though?
<cjwatson> sda1 is *not* an extended partition
<cjwatson> your bug is very confusing
<cjwatson> you say you've installed grub to the extended boot record (hd0,4) (grub1 syntax, so /dev/sda5) - but then the dd commands you give are dumping from /dev/sda1
<cjwatson> which is it?
<wgrant> The website is still showing the beta. Shouldn't it advertise the RC now?
<arand> hmm, yea, it needs clarification...
<cjwatson> the technical term for /dev/sda1 is a primary partition. Extended partitions do not have device nodes. /dev/sda5 is a logical partition. GRUB, as far as I can see, will never actually install to the extended boot record (the boot sector of the extended partition), only to the MBR or to the boot sector of a primary or logical partition.
<cjwatson> arand: does that help clarify terms?
<arand> cjwatson: Ok, so I create an (what I would call) extended partition sda1, which contains sda5 and sda6 (which ubuntu is istalled to) in the installer I specified installing grub to sda1 (meaning I will have to chainload it, which I did by grub-root(0,4)-setup), I then ran ubiquity to install on a completely different haddrive, which meant that the chainloadable grub on sda1 was overwritten (mbr one still intact), resulting in
<cjwatson> it's not possible to create an extended partition sda1
<cjwatson> sda1 cannot contain other partitions
<cjwatson> so I cannot comprehend your report
<cjwatson> I suggest attaching installation logs to your bug report (/var/log/installer/syslog, /var/log/installer/partman)
<arand> Hmm, i'm sure that's how I did it in vbox... anyhow, my current system has sda4 as extended, and grub installed to it for chainloading, which will be overwritten if I try to install karmic to, for example, a usb stick
<arand> "grub installed" here meaning installed to the first 512 of it (afaik)
<cjwatson> arand: again, sda4 is not an extended partition, it is a primary partition
<cjwatson> arand: please stop using the word "extended" to refer to primary or logical partitions; it's really really confusing
<cjwatson> nothing that you'll find in /dev is an extended partition
<cjwatson> (hd0,4) in grub isn't an extended partition either
<sbeattie> cjwatson: fdisk confuses the matter like so: $ sudo fdisk -l /dev/sda | grep Extended
<sbeattie> /dev/sda3            3136      182401  1439954145    5  Extended
<arand> Sorry, but yea so does gparted in that case... : /dev/sda4 : filesystem: Extended, hence me calling it so..
<cjwatson> oh, hah, ok fair point
<cjwatson> in that case I take back my comments with some embarrassment :)
<cjwatson> it's very unusual to have sda1 as an extended partition of course, since some BIOSes can't boot if you do that
<cjwatson> so I offer that as partial defence :)
<cjwatson> arand: ok, sorry about that :-( in that case, it probably is just partman packing the extended partition, and not dealing with copying the boot records around. Exactly why it's doing that should be deducible from your installation logs, if you could attach them to the report please?
<arand> Hmm, I'm not completely sure how I managed to get sda1 as an extended on the vbox, anyhow, the machine with sda4 is the one where it matters, now I at least have something substantial to blame :) btw, is the logs saved to the installed system or are they lost as you exit the livecd?
<cjwatson> arand: they're saved to /var/log/installer/
<cjwatson> 22:34 <cjwatson> I suggest attaching installation logs to your bug report (/var/log/installer/syslog, /var/log/installer/partman)
<chrisccoulson> should we be adding "regression-release" tags to regression bugs now which are unlikely to be fixed before final but are candidates for SRU after karmic release (or still using "regression-potential")?
<Keybuk> so, this is on a hard drive
<Keybuk> wing-commander src# echo 3 > /proc/sys/vm/drop_caches
<Keybuk> wing-commander src# time /sbin/sreadahead --no-fork
<Keybuk> (some time passes)
<Keybuk> /sbin/sreadahead --no-fork  0.00s user 0.14s system 0% cpu 36.222 total
<Keybuk> wing-commander src# echo 3 > /proc/sys/vm/drop_caches
<Keybuk> wing-commander src# time ./ureadahead
<Keybuk> ./ureadahead --verbose  0.00s user 0.04s system 2% cpu 2.157 total
<sconklin> hey akgraner, you here?
<akgraner> yeppers
<akgraner> sconklin, what's up?
<sconklin> the feed tool I was trying to remember earlier and brain-faded on is just google reader - it's under the 'more' tab on your google home page
<sconklin> akgraner: ^^
<akgraner> sconklin, oh cool...:-)
<akgraner> I was just working on setting all that up
<jaka> anyone awake
<arand> cjwatson: logs attached now, does that comment make sense?
<jaka> was just wondering
<jaka> whats the major difference in lenny vs jaunty
<wasabi__> One's Debian, and ones Ubuntu?
<wasabi__> No?
<jaka> erm k
<wgrant> And one is a year newer.
<wasabi__> Is this a real question
<jaka> no actually
<jaka> nvm
 * ogra wondered that as well
<jaka> from a developer point of view
<jaka> whats great about kde to gnome
<jaka> and why has ubuntu chosen kde over gnome
<lifeless> jaka: Ubuntu is GNOME based
<lifeless> jaka: your question doesn't make any sense
<jaka> where's the channel for it
<lifeless> channel for what
<jaka> there's one for kde but not rfor gnome
<jaka> ubuntu gnome?
<cjwatson> arand: thanks, will trawl that when I get a chance
<lifeless> jaka: I don't think there is one. There is a channel for Gnome on the Gnome IRC network - see the gnome.org website for details
<cjwatson> arand: I think there are at least two bugs here ...
#ubuntu-devel 2009-10-24
<jaka> k
<arand> cjwatson: thank you, happy that it's being looked at, happy to provide more info if needed.
<JanC> jaka: the official Gtk/GNOME/etc. channels are on irc.gimp.net, for the Ubuntu GNOME desktop, #ubuntu-desktop on this network is the right channel though  ;)
<Keybuk> pitti: around?
<jaka> ok
<jaka> cool
<jaka> thanks
<Keybuk> eep
<Keybuk> with sreadahead, 90s
<Keybuk> with sreadahead modified to stay in the foreground, 73s
<Keybuk> *without* sreadahead, 71s
<Keybuk> !
<ogra>  bah
<ogra> throw it away
<lifeless> bam!
<lifeless> ssd ?
<Keybuk> lifeless: slow laptop hard drive
<lifeless> interesting
<lifeless> btw
<lifeless> have you considered getting blktrace traces and analysing for seeks ?
<Keybuk> (ureadahead, for those paying attention, 57s :p)
<ogra> whats *u*readahead ?
<Keybuk> ogra: my little project
<ogra> ah :)
<ogra> cool
<Keybuk> sreadahead -> super readahead
<ogra> he
<Keybuk> ureadahead -> Ã¼ber readahead
<Keybuk> <g>
<ogra> :)
<ogra> like Ã¼ber splash ?
 * ogra ducks 
<Keybuk> I thought that one was "userspace" :)
<Keybuk> still not really maxing out the disk on throughput though :-(
<wgrant> Maybe we need Unicode support in package names...
<cjwatson> "ultra readahead" to avoid that question. :-)
<ogra> heh
<JanC> for reference: I booted CRUX with XFce on a Pentium MMX @ 166MHz and with 64 MiB RAM from a 3200rpm disk in < 1 min four/five years ago...
<Keybuk> JanC: that's utterly irrelevant, but thank you
<JanC> it's relevant somewhat (I know Ubuntu provides a lot more convenience after that time)  ;)
<Keybuk> why aren't you still using CRUX with XFce? :)
<Keybuk> because it has roughly the same feature set as my fridge?
<JanC> it lacked CUPS & auto-configuration of PnP-devices (USB, etc.), otherwise it wasn't that far away from what Ubuntu did back then...
<Keybuk> *did back then* being the whole point here
<Keybuk> more features -> bigger footprint -> more to load off disk
<JanC> well, it should only read more if more is needed, which is still an issue
<Keybuk> JanC: feel free to fix it :-)
<JanC> hehe, I wish I could
<Keybuk> if you don't know how to fix it, how do you know it can be fixed?
<ogra> patches appreciated :)
<Keybuk> in fact, how do you even know you know what the problem is?
<JanC> Keybuk: I can see a lot of "useless" stuff being loaded by default, I understand some things in bootcharts that show where booting is sub-optimal, and I can see where the things you work on help with all that  ;)
<JanC> of course, booting an optimized kernel saved me a lot of time on that system, which isn't really possible on Ubuntu (currently)
<ogra> our only problem is that we dont still use linux 2.2 monolithic kernels
<JanC> that was a 2.6 kernel  ;)
<ogra> 2.2 would be even faster ;)
<ogra> and 2.0 even more
<JanC> but, mostly monolithic
<ogra> and would your granny have been able to set up the system you refer to ?
<JanC> one of the problems is that sometimes the software seems to need more time than we seem to gain from the hardawre improvements  ;)
<ogra> with say 10min intro from you
<JanC> ogra: obviously not, there is a reason why *I* (and probably you too) use Ubuntu
<ogra> :)
<JanC> but, I still consider it a reference, as that hardware was already outdated (4-5yo?) when I tried it 4-5 years ago
<JanC> if we get the same boot times now with auto-configuration as hardware from 8-10 years ago with pre-configuration, there is a lot of space for improvements
<JanC> the only problem is to find how  ;)
<ogra> you really cant compare the two
<JanC> yes & no
<JanC> you can compare the extra features & what extra hardware resources it needs
<ogra> and you definately cant make up something like "space for improvement" from comparing two unrealted things
<ogra> they are completely different by design
<cjwatson> to be honest, with that much difference in the software stack, you might as well just start optimising from scratch
<ogra> right
<cjwatson> you won't really get much out of a comparison
<JanC> ogra / cjwatson: I think that "magnitude improvements" by using a different software stack indicate that the current software stack is not optimal yet, even if it has improved a lot over the last 4 years  ;)
<ogra> it hasnt "improved", its largely completely new or rewritten
<Moonraker12> Can someone fix the gtk filechooser so that its possible to select a directory as well as a file in the same dialog ? / Its kinda unusable as is...
<ogra> Moonraker12, whats the bugnumber ?
<Moonraker12> ogra: Im asking the people of this channel. Not sure if theres a bug on it yet... ?
<ogra> so you didnt file one ?
<Moonraker12> To that regard.
<ogra> do that first
<Moonraker12> .
<Moonraker12> One more thing. I need a backup operator or network tech that wants to test some new additions to an application. One computer and another computer ith ssh is required to test it.
<Moonraker12> Its a backup / Restore thing.
<Moonraker12> ith/with
<Moonraker12> (Puny screen:)
<ScottK> ogra: Did you see our Kubuntu Netbook on freescale pic: http://www.flickr.com/photos/freeflying/4036438792/in/set-72157622515083587/
<slangasek> apw: right - thanks for the dove upload
<ogra> ScottK, nah, didnt see it yet, you didnt tell me the oem team tests for you ;)
<ScottK> ogra: Just on his free time.
<ScottK> He's been a Kubuntu user for a long time.
 * ogra didnt know
<Samus_Aran> does anyone know what in the world Ubuntu's partitioner actually *DOES* when it sits there for minutes "scanning the partition table" ?  there is no scanning needed, "fdisk -l" takes 1 second for 10 disks to gather the same information as Ubuntu's magical partitioner which takes 4+ minutes for those same 10 disks
<LaserJock> I'm pretty sure it probes for other OSes
<Samus_Aran> what does that even mean ?  that partition table specifies the type already
<Samus_Aran> NTFS, FAT32, Linux, etc.
<Samus_Aran> and even if it uses something to check the start of each partition for known filesystems, that wouldn't take more than at most 2 seconds
<Samus_Aran> 4 minutes is enough time to read gigabytes of data
<LaserJock> right
<LaserJock> I'm just saying that it does more than fdisk -l
<Samus_Aran> and it repeats this ridiculously long scan when you do almost anything
<Samus_Aran> nothing more than an fdisk -l comes up on the screen, so I don't see what use any other scanning is
<Moonraker12> Samus_Aran: Why dont you debug it and see if anything is actually wrong or if its acting securely ?
<Samus_Aran> Moonraker12: who said anything about security ?  I said it is mind-bogglingly slow
<Moonraker12> Samus_Aran: Do you code much Assembly and C btw ?
<Samus_Aran> Moonraker12: why do you ask ?
<Moonraker12> Samus_Aran: "Securely" To see if it can handle the partition or disk in the intended way.
<Moonraker12> Dike
<LaserJock> Samus_Aran: do you have this problem on the Desktop CD or Alternate CD?
<Samus_Aran> LaserJock: the gui installer, I don't remember what the text installer does
<LaserJock> I think the gui installer does a bit more work, it could be something unusual is happening
<Samus_Aran> Moonraker12: what do you mean by "handle" the partition in the intended way ?  partition tables exist so that operating systems don't need to do any scanning, the partition table tells a possible OS what is already there
<LaserJock> I've never had it take more than say 5-10 seconds
<Samus_Aran> this scanning takes mere milliseconds on a modern computer
<LaserJock> well, it does more logic than that
<Samus_Aran> LaserJock: then you've only ever used a computer with one hard disk and probably only 2-3 partitions
<Samus_Aran> try a ten disk setup
<Moonraker12> > Samus_Aran: No, i cant code but i can think (Spleesh:)
<Samus_Aran> and it doesn't cache this ridiculously slow scanning, so any time you change anything, it's back to scanning it all over again
<LaserJock> Samus_Aran: right, that's not a common setup I guess. I have no idea
<Samus_Aran> LaserJock: even with just 4 disks it takes about 30 to 45 seconds on a modern computer
<Samus_Aran> there is no benefit to the end user of these slow scans, and a great deal of downside/frustration
<Samus_Aran> no other distros do this, they all work fine
<Samus_Aran> that's why partition tables exist
<LaserJock> it does more than look at the partition table though
<Samus_Aran> which it shouldn't do
<LaserJock> you can see if the Alternate CD gives you better performance
<Moonraker12> Samus_Aran: Yould like the possibility for the program to destroy disks instead of it taking you a few seconds longer Microsofty
<LaserJock> Samus_Aran: well, it's doing things that most users will find useful
<Samus_Aran> this is a problem which everyone faces.  even 10 seconds (and that's very fast for its scan) is far too long, as it will repeat this scan every time you modify the partition
<LaserJock> I've not experienced that
<Samus_Aran> LaserJock: name one thing it does which the user will find useful ?  (this does not include the regular partitioning)
<LaserJock> well, I believe it looks for what other OSes are installed so it can make recommendations
<Moonraker12> Samus_Aran: And how would you have coded it, Oh wise one ?
<Samus_Aran> Moonraker12: how could it destroy disks ?  do other distros destroy disks ?  the answer is no.
<Samus_Aran> Moonraker12: by reading the partition table, like every other partitioning app out there.
<Samus_Aran> Moonraker12: no other distros have any issues
 * ogra points Samus_Aran to #ubuntu-installer 
<Samus_Aran> is there a listing somewhere of all the Ubuntu channels ?
<Samus_Aran> there seems to be dozens
<Moonraker12> Samus_Aran: Well, would you rather have an extra check or would you like to rely on the retvals of the nibblers ?
<ogra> there surely are
<Samus_Aran> Moonraker12: I would like the Ubuntu partitioner to behave like every other partitioning app out there.  which work completely fine.  in 18 years of x86 partitioning, I've never had an issue that a regular partitioning app doesn't handle
<ogra> do other distros have tools like wubi or offer you to import settings from other OSes ?
<ogra> afaik partman scans the content of the partitions as well ... tht simply takes its time
<Samus_Aran> ogra: if it's taking so long because it's looking for settings, then it should ask the user if they wish to import settings before it spends a huge amount of time scanning
<ogra> well, there is definately a very valid reason why it behaves as it does
<Samus_Aran> and why would it rescan every time you change a partition ?
<Samus_Aran> if it was looking for settings, its job is done after the first scan
<ogra> as LaserJock suggested, compare with the alternate installer, if the live installer behaves largely differently, file a bug
<Moonraker12> Samus_Aran: And in those 18 years (3) you have managed not to learn coding hat so ever as you said.
<Samus_Aran> Moonraker12: I don't know what that sentence is supposed to mean
<ogra> Samus_Aran, its not done ... the partitions changed to be 100% safe it needs to scan again
<Moonraker12> Samus_Aran: It means youre lying, you entered after 2003
<Samus_Aran> ogra: it is the one that changed the partitions, it knows what the changes are, there is no need to rescan.  if hda1 had windows, and you erased hda1, obviously there's no more windows
<Samus_Aran> Moonraker12: I've been using x86 since the 8088
<ogra> well, talk to the devs
<Samus_Aran> Moonraker12: you don't know me, so stop lying
<ogra> there is definately a reason why d-i/ubiquity are not using fdisk -l
 * Moonraker12 *Snickers*
<ogra> and there is definately a reason it needs to scan again
<Samus_Aran> Moonraker12: C=64 then 8088 with IBM DOS and Phoenix DOS and later onto MS-DOS
<Moonraker12> Samus_Aran: Say something you havnt said during the past 6 years that can convince me...
<Samus_Aran> ogra: what is the reason for scanning again ?  it is the one that changed the partitions, it knows the changes
<ogra> Samus_Aran, ask the developer of partman, i didnt write it
<Samus_Aran> Moonraker12: I don't even know you, why are you acting like you know me ?
<ogra> but i know he doesnt do stuff without a very valid reason
<ogra> if fdisk -l would be enough he would use it, be sur
<ogra> e
<Moonraker12> Samus_Aran: It can be good for you.
<Samus_Aran> ogra: who is the developer of partman ?
<ogra> he is hanging around in #ubuntu-installer
<ogra> all people contributing to partman in ubuntu are i belive
<Samus_Aran> Moonraker12: your English is very difficult to understand.  what can be "good for me" ?
<Moonraker12> I piss on you
<Samus_Aran> Moonraker12: not on IRC you don't...
<Moonraker12> Hard to understand ?
<ogra> though there are plenty of debian devs contributing to it as well
<ogra> Moonraker12, please mind your tone
<Samus_Aran> Moonraker12: your English is very poor, and you assume you know me.  as far as I know, this is the first time we've ever met (other than earlier today in #Ubuntu)
<Moonraker12> Samus_Aran: Youre a notorious liar. Im sorry my mother language is poor. I feel rich myself.
<Moonraker12> what an ass
<ogra> Moonraker12, please ...
<Moonraker12> done.
<Samus_Aran> Moonraker12: how am I a "notorious liar" ?  we've never even met.  maybe you have me mistaken for someone else ?
<Samus_Aran> Moonraker12: and I didn't say your mother language was poor, I said your English communication is poor.
<Moonraker12> No, from all i can tell youre an "IMCP" from Microsoft. Let me know if you can convince me of the opposite. Otherwise, please do not speak to me.
<Moonraker12> Im not poor on any way.
<Samus_Aran> Moonraker12: what is an IMCP ?  I'm not anything from Microsoft.  I don't own or use any Microsoft products.  I have exclusively used GNU+Linux since 2001... look at my FreeNode cloak, given to me by lilo for helping out many hundreds of hours in ##Linux
<Moonraker12> I have coded for the public domain etc since 1994. What as you previous nick then ?
<Moonraker12> as/as
<Moonraker12> was
<Moonraker12> Bad keyboard
<Samus_Aran> Moonraker12: you don't know me at all.  why are you attacking me ?
<LaserJock> ok people, this is getting ridiculous
<Samus_Aran> Moonraker12: I have used Samus_Aran for the past seven years on here...
<LaserJock> Samus_Aran: I would suggest trying the Alternate CD and seeing how that performs in comparison as a first step
<LaserJock> Samus_Aran: and filing a bug would be good
<Samus_Aran> LaserJock: okay
<Moonraker12> It is, isnt it. Samus_Aran: How come ive never seen you before on any irc network, having been on them 24/7 since atleast 2000 ?
<LaserJock> as right now people are trying to fix critical last-minute bugs
<LaserJock> and really don't have time to do the problem justice
<ScottK> Moonraker12: It's really off topic for this channel.
<LaserJock> but a bug report will help them track the issue
<Moonraker12> Done, as i said a long time ago.
<Samus_Aran> Moonraker12: that is ridiculous.  there are hundreds of thousands of people on IRC -- obviously you do not know all of them.
<ScottK> Samus_Aran: It's off topic for you too.
<lifeless> Samus_Aran: Moonraker12: both of you please stop
<lifeless>  /ignore each other if you have to, but let us focus on the release. Thanks.
<Samus_Aran> lifeless: does Moonraker12 normally attack everyone that comes in this channel out of the blue ?
<Moonraker12> We are ok no.
<jdong> what on earth is in the last 3 pages of my scrollback?
<lifeless> Samus_Aran: you're continuing the conflict at this point; that question is itself escalatory.
<chrisccoulson> jdong - you haven't missed anything important
<LaserJock> Samus_Aran: we know Moonraker12 just as much as you
<lifeless> so please, stop.
<Samus_Aran> LaserJock: okay.  they were talking like they were a regular here.
<Moonraker12> Samus_Aran: Settle down now. I didnt mean any harm, just probe you a bit.
<Samus_Aran> lifeless: fine, but I really don't appreciate asking a legitimate question then being attacked and accused of being a Microsoft mole and only having used computers since 2003 and a liar.  it isn't easy to not respond to that crap.
<Samus_Aran> anyhow, I'm out of here now, #Ubuntu-installer is the correct channel for my question.
<bryce_> goodness
<jdong> heh indeed....
<chrisccoulson> slangasek - i can't remember if i mentioned to you already - i uploaded a patched version of g-s-d to my PPA a few days ago, which might give some insight as to why you see frequent low-disk space warnings (i added lots of debug messages to it)
<chrisccoulson> would you mind trying it at some point, and showing me the debug output?
<Moonraker12> bryce, jdong: Sorry for that. It was required on a grander scale of things plus i dont like it when people say my English / American / Europeean etc isnt good enough for them. (Thats their first line of defence).
<Moonraker12> As they dont have a second line ;)
<slangasek> chrisccoulson: actually, at this point I'm not sure the frequent warnings aren't simply due to the frequency with which I have to restart g-s-d due to the xrandr bug; at least, /now/ I only see it once per restart
<slangasek> chrisccoulson: so I'd much rather focus on that bug
<chrisccoulson> slangasek - that actually makes more sense. i've tried very hard to recreate the disk space warning problem here, and couldn't get it to break
<chrisccoulson> did you manage to run it through xtrace yet?
<slangasek> no
<slangasek> will try to do so this weekend
<slangasek> I have pinpointed a reproducible sequence as well now, which might be enlightening; will post it to the bug
<chrisccoulson> thanks. i'll take a look at it then. hopefully it will show up something obvious
<chrisccoulson> a sequence of events to trigger it will be useful too
<slangasek> chrisccoulson: 1) boot, 2) plug in a VGA monitor with a higher resolution than the LCD, 3) hit the button :)
<slangasek> (it always happens on the first time after plugging in the VGA monitor)
<chrisccoulson> quite simple then. did you also say you were having issues with resolution reverting to 1024x768 when opening the lid too?
<slangasek> chrisccoulson: yeah, still having some sort of problem there; lower priority for me
<chrisccoulson> slangasek - i noticed this in the gnome-desktop code a few days ago, which might just be a coincidence:
<chrisccoulson> * Pick some random numbers. This should basically never happen */
<chrisccoulson> output->pref_width = 1024;
<chrisccoulson> output->pref_height = 768;
<slangasek> heh
<chrisccoulson> anyway, sleep time for me now!
<slangasek> ok, 'night :)
<otrewyi191> hi
<spaettzAway> xx
<billisnice> my gimp will act like it is loading and then disappear.
<slangasek> ccheney: hmm, just noticed (on upgrade) that the latest OOo-common also bumped xfonts-mathml from a suggests to a recommends... hoping that doesn't cause any space problems or introduce any regressions, since this wasn't included on the images at all before.
<doko_> yup, it wasn't just bug fixes, but an ooo-build and debian merge as well :-/
<slangasek> yeah.
<pengo> hi
<pengo> can someone please re-open this bug as it's still getting reports? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/150872
<ubottu> Launchpad bug 150872 in ubiquity "Installer should not list removable media in /etc/fstab" [High,Fix released]
<slangasek> pengo: the latest comments in the bug talk about USB sticks, which would be an entirely separate bug and should be reported separately
<pengo> slangasek: no, that's the same bug
<pengo> slangasek: caused by the same fault anyway.. i'm pretty sure there are duplicates that mention USB
<pengo> it's a very annoying bug
<pengo> oh well good night
<logari81> totem user experience:
<logari81> 1) u try to open a wmv file after a fresh installation of karmic
<logari81> 2) u are prompted to install additional codecs "Windows media video 8 & 9"
<logari81> 3) the installation of the corresponding packages ends successfully
<logari81> 4) u get the following error message
<logari81> http://files.ubuntu-gr.org/forum/logari81/Screenshots/Screenshot-Totem%20bug.png
<logari81> 5) u try to reopen the file
<logari81> 6) it works
<logari81> is there any chance to get this annoying defect fixed until the end release?
<evand> logari81: please file a bug using `ubuntu-bug totem`
<slangasek> TheMuso: I don't see any explanation in 450214 of why e2fsprogs is thought to be misbuilt?
<logari81> evand: done #459772, I think it is the kind of detail the 101 papercuts project was thought about, it is a pity that a new user will have to confront with such an error message.
<evand> logari81: I think it's a normal run of the mill bug, not a usability bug, which is what the papercuts project is tasked with.
<logari81> evand: ok, it is not a usability issue, u are right
<cjwatson> slangasek: 450214> TheMuso told me on IRC that after he'd fixed the swap problem he found that mke2fs failed in the same way, and that rebuilding e2fsprogs with -O2 fixed it for him
<flower> why does /etc/apt/preferences not work in Ubuntu (jaunty), at least this example doesn't work: http://pastebin.com/me179d8a
<flower> it works in Debian
<slangasek> cjwatson: ack, accepted then
<Keybuk> sladen: still not around?
<flower> and nobody seems to be able to answer my question...
<Keybuk> flower: this isn't a channel where you ask questions, try #ubuntu
<flower> Keybuk: you're right, I asked it there... but they asked me if I meant /etc/apt/sources.list maybe :/
<ccheney> slangasek: oh :(
<flower> and if I'm right that it aint working properly in Ubuntu it seems to be more like a dev topic
<Keybuk> flower: no, see the topic
<Keybuk> if you think something isn't working right, file a bug
<flower> mmh ....
<flower> ok....
<apw> pitti, slangasek, bug #422536 appears to not be a kernel issue at all, but an apport false positive ... pitti i wonder if you could confirm, and let us know if this can be fixed in apport easily
<ubottu> Launchpad bug 422536 in linux "EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded." [Medium,Triaged] https://launchpad.net/bugs/422536
<bluefox_> how much RAM do I need to run karmic?
<bluefox_> Mem:   3800308k total,  1164784k used,  2635524k free,   115840k buffers
<bluefox_> Swap:   787072k total,        0k used,   787072k free,   418048k cached
<bluefox_> this is what I Get logging into Gnome and running xterm and top immediately.
<bluefox_> Nautilus has a 780M VMA space with 149M resident and 22M shared, it's the most memory hungry process on the list; next is Xorg with 232M, 91M, 28M
<bluefox_> so the top two make up about 250M of RAM usage.
<JanC> bluefox_: if you have enough swap (and enough time), 64 MiB is enough  ;)
<JanC> 256 MiB should be enough for basic use
<bluefox_> JanC:  Just logging in takes me 680MB of non-cache
<JanC> and virtual memory includes mmap'ed files & binaries
<bluefox_> JanC:  I know what VMA consists of
<bluefox_> JanC:  lookat the used/buffers/cache numbers.
<bluefox_> 1164784 - (115840 +  418048)
<bluefox_> 630896
<JanC> bluefox_: mmap'ed files & binaries aren't included in "buffers" & "cached" AFAIK, while they can be "removed" from RAM if needed (as they exist on disk anyway)
<bluefox_> IIRC "cache" is VFS cache and buffers are mmap() buffer cache
<bluefox_> but point taken.
<JanC> well, the live-CD supposedly boots with 256 MiB RAM & no swap  ;)
<bluefox_> memory management and analysis is crap on linux :(
<bluefox_> it's like "there's X ram in use but we don't really know how much is needed and how much is stale crap"
<JanC> well, you certainly need more numbers than just those
<bluefox_> JanC: I still say the real test is the Quake test.
<bluefox_> I used to run Quake on 64M Windows 98SE o_o
<bluefox_> 32M was comfortable, I had a lot of ram :D
<bluefox_> (Quake used to run on a 33MHz 486DX with 8M of RAM, though)
<JanC> and memory management isn't that bad actually, e.g. Windows doesn't mmap libraries
<bluefox_> yeah
<bluefox_> JanC: the OOM is broke bt.
<bluefox_> btw.
<hyperair> what's wrong with mmap?
<JanC> Windows will copy libraries to RAM and then from there to the swap file, thus you have 2 copies of the DLL on disk  :P
<bluefox_> I made the mistake of leaving Evolution open for a few hours and it eventually ate several gigs of ram, then my PC froze
<hyperair> fun
<bluefox_> it froze after I noticed Evolution's RES in top, and started typing 'killall' :P
<bluefox_> killa-- aww damn.
<JanC> Evolution like to freeze from time to time, not related to RAM  ;)
<bluefox_> no, my WHOLE MACHINE froze.
<bluefox_> it became unusable
<hyperair> well livecds cannot be used as benchmarks imo
<JanC> I have Evolution open for > 1 month sometimes...
<hyperair> while they're meant to be somewhat usable, a significant portion of your RAM is used for storing files.
<bluefox_> it takes me that long just to open Evolution....
<JanC> with > 3 GiB of mail in IMAP accounts
<bluefox_> heh, it actualyl does take me 10-15 minutes to open evo
<maco> JanC: wow. ive never had >1 month uptime. crap...3 days is a long time for me
<hyperair> JanC: seriously? i'm always running evolution --force-shutdown.
<bluefox_> I have more mail stored in Thunderbird, which opens quick
<hyperair> JanC: stupids thing hangs whenver the network acts up.
<hyperair> stupid*
<bluefox_> two accounts in Evo, which takes 10-15 min to open
<JanC> yeah, Evolution sometimes doesn't like network hickups
<JanC> and it opens quick enough, closing it takes much longer  ;)
<JanC> (syncing with the IMAP server first)
<bluefox_> JanC: I can't get evo to open quick
 * bluefox_ maybe strace -t it, or strace -r, to get timing information and wtf it'sd oing.
<bluefox_> JanC: lots of lseek() and read()
<JanC> that's normal, but shouldn't take 10 min  ;)
<bluefox_> itpops up a box"Do you want to makeevolution your default mail client?" and I Click no, then the waiting begins
<JanC> eh
<JanC> it has to download a lot of messages maybe?
<bluefox_> and tons of disk activity
<bluefox_> okthat was quick
<bluefox_> 14:43:49 to 14:47:39
<bluefox_> so evolution's faster now than it was pre-karmic
<bluefox_> MUCH faster.
<arand_> partman-basicmethods is part of the installer (udeb package), and I want to test a recent patch for it, can anyone hint me how?
<evand> arand_: anna-install openssh-client-udeb; scp your changes in.
<evand> before you get to the partitioner, of course
<arand_> evand: ok, cheers
<evand> arand_: sure thing
<evand> arand_: for what it's worth there's also #ubuntu-installer, where we handle installer development
<arand_> evand: Yea... I just bothered cwatson into patching a partman bug and now I've no clue how to test the patch :/
<evand> heh, I'm in and out tonight, but I can give you a hand if you run into any trouble and I'm still around.
<TheMuso> This is weird. Both a juanty and karmic box here have gone back to eastern Australian standard time, instead of being at eastern daylight savings time... Weird.
<TheMuso> hrm ok seems my phone is an hour fast, not my machines.
<lifeless> TheMuso: its 0800
<lifeless> (well just before)
<TheMuso> lifeless: Yes, I know.
<lifeless> TheMuso: cool; just offering external data
<TheMuso> My phone seems to have decided to act weird on me for some reason.
<maco> theyre sneaky like that
<TheMuso> Its to do with having changed the time on my phone manually due to $telco not doing it correctly via auto-update at the dayliht savings time. Now that has finally come through, and its put my phone out an hour.
 * dtchen frowns at libsdl/src/audio/{alsa,pulse}/ in Karmic
<lifeless> TheMuso: are you with vodafone?
<TheMuso> lifeless: no telstra
<lifeless> TheMuso: I wish voda would do times in .au
<lifeless> they epically fail here
<pgraner> pitti: Bug 422536
<ubottu> Launchpad bug 422536 in linux "EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded." [Medium,Triaged] https://launchpad.net/bugs/422536
<TheMuso> slangasek: re hotkey-setup, it was inherrited. I can upload a new meta to remove it, if you wish to purge it from main etc.
<TheMuso> s/main/the archive/
<wamty> ubuntu is a whole lot better when it doesn't ask you for the password every time you need to change something or install something.
<wamty> why it does that?
<ahe> wamty: for security reasons but #ubuntu is a much more appropriate place to ask such questions
<TheMuso> /c/c
#ubuntu-devel 2009-10-25
<symptom> hello, can anyone point me towards a good tutorial on how to build drivers for Linux
<TheMuso> symptom: What kind of driver?
<symptom> something really simple.  Just trying to learn.
<TheMuso> symptom: Yes, but drivers for X, and drivers for sound cards for example, are done somewhat differently.
<TheMuso> i.e X drivers are in userspace, and sound drivers are in kernelspace.
<slangasek> TheMuso: hotkey-setup was already gone from main, I've now purged it from the archive, I suggest you drop the recommends, yes :)
<TheMuso> slangasek: Ok will do. I've also been asked by the otehr studio devs to remove empathy from the default install but ship pidgin on the disks, not being installed. That will also be included in the meta upload. If you feel its too late for such changes, it can be reverted.
<ScottK> TheMuso: I think it's really up to Ubuntu Studio to decide what it wants to do on that.
<TheMuso> ScottK: Right, I was thinking more about how late things are to be changed etc, anyway I'll push the meta once its updated.
<ScottK> We haven't started working on final ISOs yet, so I think it's fine.
<TheMuso> Right.
<ous335> hi i need help with ubuntu, my wireless is not working
<lifeless> #ubuntu
<ous335> plz help
<ScottK> ous335: This isn't a help channel.  Ask in #ubuntu.
<ous335> how do i go there
<ScottK> The same way you got here, but instead of joining #ubuntu-devel, join #ubuntu
<hrickards> Should a bug report be marked as a duplicate if the two errors reported are very similar but not the same and the cause of the error is the same?
<joaopinto> hrickards, if the bug causing the message is the same, they are duplicates :)
<hrickards> joapinto: Oh yeah. Nice way of putting it. :)
 * hrickards feels like an idiot after the way joapinto put it. :(
<gizero> In Jaunty you could quicly switch user by selecting the other user's name in the drop-down menu in the top-right corner of the screen. In Karmic you have to choose Switch User... there instead and it brings you to the regular login dialog. This is so much slower; my girlfriend and I constantly switch back and forth between our accounts. Why was this change made?
<lifeless> gdm got rewritten
<lifeless> the facility to figure out what other users have sessions was broken by that, and has not yet been recreated.
<lifeless> there is a bug open on one of the indicator/messaging projects, and it should be fine in lucid
<gizero> lifeless, Excellent, nice to know the feature wasn't removed intentionally
<gizero> Looks like it's bug 425550
<ubottu> Launchpad bug 425550 in indicator-applet "[Karmic Alpha 5] no fast user switching in indicator-applet-session (dup-of: 422052)" [Undecided,New] https://launchpad.net/bugs/425550
<ubottu> Launchpad bug 422052 in indicator-session "Menu should list users if more than 1, fewer than 7 are on the system" [High,Fix released] https://launchpad.net/bugs/422052
<lifeless> gizero: claims to be fixed, are you fully up to date?
<gizero> Yeah, I installed the RC yesterday, and installed all updates in Update Manager 15 hours ago
<wgrant> lifeless: It was sort of reverted.
<wgrant> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk/revision/47
<gizero> wgrant, Shounds like the bug should be reopened then
<wgrant> gizero: Probably.
<TheMuso> slangasek: Do you have any objection to dropping pt and es langpacks from powerpc Ubuntu CDs to ensure the alternate is not oversized?
<cjwatson> TheMuso: dropping langpacks as necessary for size is usually fine
<sebner> mighty cjwatson , some friend asked me about grub invaders. Should still be in grub2, right? Not seeing it though
<TheMuso> cjwatson: ok
<cjwatson> sebner: never heard of it
<cjwatson> sebner: if it's some kind of grub extension, I expect that it would require a rewrite to work with grub2
<cjwatson> sebner: if it's something that you boot from grub, then it should be reasonably easy to get it to work wiith grub2
<sebner> cjwatson: space invaders in grub. I've found an old mail in debian archive about fixing it in grub2 .. from 2007 though
<sebner> boot from grub iirc
<cjwatson> sebner: afraid I don't know, don't really have time to focus on fixing up games :)
<sebner> cjwatson: yeah, really np
<sebner> cjwatson: there is a package grub-invaders. Wondering if this was installed default or included in grub some time in the past. Anyways, thx for you help
<cjwatson> it was never installed by default
<switchgirl> hi in karmic sd cards don't auto mount
<switchgirl> anyone working on that?
<spaetz_> karmic kernel started oopsing continously now
<spaetz_> CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
<Kano> cjwatson: why is iso-scan not working with ext4 partitions
<Amaranth> anyone else being told they're being removed from ubuntu-devel due to excessive bounces?
<Amaranth> I can't believe gmail would be bouncing regular list mail but not the notice of removal...
<dtchen> Amaranth: yes, at least two others (maco and me)
<maco> oh didnt know you got one too dtchen. why didnt you say so when i mentioned it this morning?
<Laney> yeah everyone got one I think
<Laney> it sounds like that anyway
<jelkner> jono: are you here?
<maco> jelkner: hi jeff!
<jelkner> maco: hi
<jono> jelkner, yeah
<jono> :)
<jelkner> i have a problem with an unassigned high priority bug that is destroying my life
<jelkner> (i exaggerate a little, but not much ;-)
<maco> haha
<jelkner> https://bugs.edge.launchpad.net/ubuntu/+source/libxcb/+bug/419501
<ubottu> Launchpad bug 419501 in libxcb "apport-kde assert failure: python: ../../src/xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed." [High,Triaged]
<jelkner> i kills gasp
<jelkner> around which i've built all the python teaching materials i use
<jelkner> so i won't be able to run karmic
<jelkner> i didn't want to be a pest
<jelkner> so since it was a high priority bug i figured i'd just wait
<jelkner> but with release this week
<jelkner> it doesn't look good for me
<jono> jelkner, ahhh thats a shame
<jono> looking at the bug now
<jelkner> the bug is in debian squeeze also
<jelkner> i checked yesterday
<jelkner> i'm downloading fedora 12 now to see if it has the same problem
<jono> jelkner, what would like me to do to help?
<jelkner> jono: explain to me how the bugs get assigned
<jelkner> and if there is anyone i could talk to about this
<jono> jelkner, it gets assigned to whoever volunteers to fix it
<jelkner> ahh
<jono> unless a platform manager assigns it to a member of their team
<jelkner> can one talk to a platform manager?
<jelkner> and make an appeal
<jelkner> is there a bounty process or something?
<jelkner> i *really* would like to see this fixed
<jelkner> and i can't fix it
<zooko> jelkner: there is no bounty process, but I guess you could always try offering people money and see if they accept.  :-)
<jelkner> i don't even know who to ask
<jelkner> zooko: r u interested?
<zooko> Your best bet is probably to generate specific, reproducible facts about it, such as whether it also happens in Debian and Fedora, what exact version first introduced it, etc.
<zooko> jelkner: sorry, I am not.  I am just trying to help.
<jelkner> it has to do with the new x library i believe
<jelkner> i've filed bug reports, but they came back as duplicate bugs
<jelkner> so i'm perfectly willing to do what you suggest, zooko, i just don't know how
<zooko> Yes, filing a bug report is certainly the first step.
<jelkner> that's why i'm here
<jelkner> been there, done that
<jelkner> months ago
<zooko> Well, do you know how to compile different versions of the X libs in question?
<jelkner> i guess i could
<zooko> If, for example, you could identify that version X didn't have this problem and version X+1 did, that would help.
<zooko> By the way, I'm not an Ubuntu dev, just a random person hanging out trying to help, but my guess is that it is too late to get this fixed for Karmic.
<zooko> Fortunately Karmic isn't the end of the world.
<maco> might be SRU-able...
<dupondje> hmz, final grub2 came out ...
<dupondje> will it get into Karmic ?
<maco> jelkner: if you can play around and find out when in the libxcb version history the bug was introduced....
<maco> dupondje: grub2 is in karmic...
<dupondje> beta4 :)
<dupondje> but the final 1.97 came out today
<maco> oh
<cr3> what's a good format for documenting a project? I have often seen text files under a doc directory in the root of projects, but I'd rather stay away from pure text to allow for greater formatting. so, what is most common? docbook? straight html? latex?
<arand> dupondje: at this stage, probably not, unless the bugs it fixes are serious...
<GodfatherofEire> Would this be the right channel to make a suggestion to the dev team or should I go to #ubuntu-motu?
<GodfatherofEire> specifically for something to keep in mind/think about for lucid.
<arand> dupondje: but that is not in any way an official answer, (I'm no dev)
<dupondje> :)
<dupondje> trying to get grub2 working with dmraid :s
<maco> cr3: docbook is common
<maco> GodfatherofEire: say what it is and go from there?
<maco> GodfatherofEire: or try the ubuntu-devel-discuss mailing list
<GodfatherofEire> maco, it would be with regard to the empathy IM client replacing pidgin, add to that that libempathy is a requirement for the message notification applet.
<maco> if youre one of the people upset that pidgin was replaced, its been discussed to death
<GodfatherofEire> maco, its not just that, its not ready for full scale deployment
<maco> i doubt theyre gonna switch back after one release with it. more likely, submit bugs to empathy upstream and try to get them looked at
<GodfatherofEire> If it had everything there, and if the notification applet didnt depend on libempathy (which takes up space, as its basically just the same as pidgin-data)
<GodfatherofEire> maco, they already know whats wrong with it (like, no /msg, /join, /quit etc, protocols for IRC)
<GodfatherofEire> as well as lack of password support, which pidgin already has
<maco> and im sure at least some of that'll be fixed by lucid anyway
<GodfatherofEire> like they say, "if it aint broke, dont fix it"
<maco> if you know C you could probably help...?
<maco> i assume empathy is C...most gnome is
<GodfatherofEire> not too familiar with C, although it probably wouldnt take very long to learn
<GodfatherofEire> and is it just me or does that also screw up the user switcher (the set status functionality)?
<GodfatherofEire> (its removal)
<GodfatherofEire> lastly, are you guys ever gonna fix the log out sound, or is it just gonna be one of ubuntu's quirks?
<Julien13012> HI Everyone
<Julien13012> Do someone know the release day of 9.10 ?
<Laney> thursday
<Julien13012> 29th ???
<dtchen> Julien13012: https://wiki.ubuntu.com/KarmicReleaseSchedule
<Julien13012> thanks
<cjwatson> dupondje: I'm not planning on putting the final grub 1.97 into karmic. I'd hoped that it would be released a week ago, in which case I'd absolutely have tried, but it's really too late now and I don't think I can justify it
<cjwatson> dupondje: it's not going to make any difference to dmraid over 1.97~beta4
<dupondje> yea true :)
<dupondje> trying to get dmraid & grub2 working atm
<dupondje> seems its a no-go :(
<cjwatson> that's why the installer defaults to grub legacy for dmraid right now
<dtchen> evand: thanks for the mailing list work!
<evand> dtchen: elmo did the hard work, but thanks
<dupondje> cjwatson: I know :) just like to try :)
<dupondje> btw, could you get https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 into Karmic ? its quite annoying bug for me in aptitude
<ubottu> Launchpad bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<dupondje> but prolly not important enough to get in it anyway :)
<cjwatson> that doesn't look release-critical, I'm afraid
<cjwatson> and the patch is pretty suspicious, what if somebody has a >400-column terminal?
<cjwatson> that should be allocated dynamically rather than statically
<dupondje> true
<dupondje> tho the bug should still get fixed ;)
<cjwatson> I'm certainly not going to last-minute a patch that improperly fixes an issue affecting a small number of users in a way that can easily be worked around - sorry
<cjwatson> I suggest looking into dynamic allocation, and getting that sorted out for lucid
<dupondje> true :) the patch could been better ;)
<dupondje> had Jaunty since Alpha 4
<dupondje> Karmic since Alpha 2
<dupondje> Lucid since Pre-Alpha ? ;)
<ericrw> droid
<ericrw> [that should've been, "/join #android".  (this is not the droid I am looking for)]
<cjwatson> dupondje: brave, alpha 1 tends to be "the first point at which we could get it to work at all"
<Keybuk> cjwatson: I wouldn't even go that far
<Keybuk> Alpha 1 (especially this time) is "something booted for someone, ship it!"
<didrocks> ScottK: concerning the quickly crash, I'm waiting for pitti's feedback tomorrow on python-distutils-extra to know if he will revert his change
<ScottK> didrocks: python-distutils-extra is in Main, so unless this affects a lot of packages, I'd plan on fixing quickly.
<didrocks> ScottK: ok, I don't know how to avoid python-distutils-extra moving my .desktop.in file in data/ directory, but I'll try to find a workaround.
<ion> keybuk: Any thoughts about bug #458389 vs. bug #215666? :-) I still think usplash could simply disable the CLEAR command when in verbose mode. I donât see leaving old status messages to the screen with a normal, quiet boot, as a good thing.
<ubottu> Launchpad bug 458389 in mountall "usplash receives repeated "CLEAR" commands while in verbose mode" [Low,Fix committed] https://launchpad.net/bugs/458389
<ubottu> Launchpad bug 215666 in usplash "fsck messages are not cleared from usplash when check is finished" [Undecided,Confirmed] https://launchpad.net/bugs/215666
<Keybuk> ion: didn't you send me patches for those?
<Keybuk> that's a good idea, if you haven't, send me a patch! :)
<Keybuk> I'll do the pending usplash and mountall bits tomorrrow
<Keybuk> (or when I get out of the bath in a bit :p)
<ScottK> didrocks: Universe has a later cutoff than Main, so even if pitti does change python-distutils-extra back, we'd have time to revert any quickly fix you might come up with, so I'd say please go ahead if you figure it out.
<ion> keybuk: Keesâ changes are kind of conflicting with my patches. My commits were made before those changes; they didnât take the âstuff cleared from the screen when in verbose modeâ issue into account at all.
<Keybuk> ion: if you think your patches are better, I can review them and work out which to take :p
<Keybuk> I like your idea that CLEAR just doesn't work on verbose - it makes an amount of sense
<Keybuk> or maybe works more like the console?
<Keybuk> where we don't clear, but we don't repeat either?
<didrocks> ScottK: ok. I'll try some stuff (just going to bed and think about it first ;)) and keep you in touch.
<ion> keybuk: In the bug comments, Kees disagrees with my idea that CLEAR could be disabled in verbose mode.
<ScottK> didrocks: OK  Have a good night.
<Keybuk> ion: Kees may not be right ;)
<Keybuk> if you can give me a patch, I'll have a think
 * Keybuk bbl
<ion> keybuk: Iâll do that.
<EagleScreen> dkms is unable to install bcmwl kernel module in 9.10
<ScottK> EagleScreen: Not true.  I did it on Tuesday.
<EagleScreen> it cannot do it now
<EagleScreen> i have installed Kubuntu right now with alternate CD
<EagleScreen> how can I find out why dkms cannot install the module?
<EagleScreen> I have installed the package directly, not using jockey
<EagleScreen> there is an error when dkms tries to install the module
<Keybuk> wow
<Keybuk> I'm glad we left the back door in karmic, so I can read your screen and see that error
<Keybuk> it totally helps
<Keybuk> otherwise we wouldn't have a clue what was wrong, and wouldn't be able to help
<Keybuk> <g>
<azeem> by the time you wrote all this, you could've fixed it already!
<Keybuk> azeem: we secretly have fixed it, we're just not realising the fix because we're mean :p
<EagleScreen> this is the error in terminal http://pastebin.ca/1643123
<Keybuk> EagleScreen: ok, I have to be fair; that is the world's most useless error
<Keybuk> is there a /var/log/dkms or something similar?
<EagleScreen> yes this is /var/log/dkms_autoinstaller: http://pastebin.ca/1643124
<EagleScreen> not much neither
<Keybuk> EagleScreen: ok, now look in /var/log/dmesg
<Keybuk> can you pastebin that too?
<ScottK> Also in fairness I didn't use jockey either.
<EagleScreen> dmesg: http://pastebin.ca/1643125
<EagleScreen> (var7log/dmesg)
<ScottK> My swag is since he's using Kubuntu, there's no policykit integration and some piece of jockey lacks some permission it needs
<EagleScreen> ok, I think i have found the problem
<EagleScreen> buid-essential is not installed
<EagleScreen> shouldn't dkms or dkms packages depend on it?
<Keybuk> yeah, that's arguably a bug
<Keybuk> Depends: module-init-tools, gcc, make | build-essential | dpkg-dev
<Keybuk> so if you had make or dpkg-dev already installed, it wouldn't drag in b-e
<EagleScreen> make and gcc are installed
<Keybuk> yeah that'd be why then
<Keybuk> I'd file a bug about that
<Keybuk> *and* I'd file a bug that "fail" is the most it can manage for an error
<EagleScreen> thanks a lot
<azeem> EagleScreen: I think that was an encouragement that *you* should file those bugs
<EagleScreen> yes
<ion> keybuk: Ok, pushed to https://code.launchpad.net/~ion/usplash/karmic and https://code.launchpad.net/~ion/ubuntu/karmic/mountall/karmic
<ion> keybuk: The mountall branch also contains the try_mounts fix.
<Keybuk> ion: I see -r334 and -r145
<Keybuk> is that right
<Keybuk> ?
<ion> keybuk: Yes, the latest commit messages should be âUndo recent CLEAR changes...â for mountall and âReverse the ignore logic...â for usplash.
<Keybuk> ok
<Keybuk> hmm
<Keybuk> *thinks about the usplash patch*
<Keybuk> CLEAR should certainly work when !verbose
<ion> And when itâs verbose, multiple clients may be outputting text (say, sysvrc scripts and mountall), and either might accidentally CLEAR something the other one wanted to show.
<Keybuk> yeah, but that's just a usplash design flaw
<ion> which can be worked around for karmic with a single â!â removal. ;-)
<Keybuk> yeah but it's wrong for the fsck case
<Keybuk> you'd get scrolling progress text that's ugrly
<Keybuk> I think kees's patch is part right, and yours is too
<Keybuk> we should only display the bored text once, without a CLEAR, and not update it once a second (unless maybe things change?)
<Keybuk> but usplash should always honour CLEAR
<Keybuk> that way the only time it is used is when an fsck is happening, to keep it all at the same point on the screen
<Keybuk> does that make sense?
<ion> Yeah, that should work. I was just a bit reluctant to change the progress display logic that much this near to release, thinking the usplash workaround would be good enough for now.
<Keybuk> yeah, I just don't like *inverting* logic right before release ;)
<Keybuk> invertion leads to surprises
<Keybuk> at least enabling something doesn't so much
<ion> True
<ion> In the surprise case, that would still only lead to text being left on the screen.
#ubuntu-devel 2010-10-25
<avo> Hey. So I've got a simple python TCP socket client/server thing going. Except when I try to restart the server soon after it shutting down (like 20 seconds), I get the error: socket.error: [Errno 98] Address already in use. What gives? Thanks!
<ebroder> avo: That's a "feature". You need to set the SO_REUSEADDR socket option
<enki> i'm running out-of-the-box ubuntu maverick on amazon ec2 with an EBS root volume, and an additional EBS volume for logs, both on ext4. i've had repeat half-crashes, with the volume becoming partially unresponsive (task blocked for more than ... seconds) and high load in WAIT
<enki> http://pastebin.com/eZh7mSZH
<jorgenpt> wc
<malte> hi
<\sh> moins
<malte> can anyone tell me, what the file debian/libgtk-2.0-0.symbols does?
<malte> for some parts of it I need to do the same on gentoo, so I need to understand how it works
<malte> the file is part of the package gtk+
<malte> http://bazaar.launchpad.net/~ubuntu-desktop/gtk/ubuntu/annotate/head:/debian/libgtk2.0-0.symbols
 * malte is away: Gone away for now
 * malte is back.
 * malte is away: Gone away for now
 * malte is back.
<Hobbsee> !away | malte
<ubottu> malte: You should avoid noisy away messages and -nicks in a busy channel like #ubuntu, or other Ubuntu channels; it causes excessive scrolling which is unfair to new users. Use the command "/away <reason>" to set your client away silently.  See also Â«/msg ubottu GuidelinesÂ»
<geser> cjwatson: if you have some time after UDS, could you sponsor my vim merge (bug #662276)? It's a classical debdiff as the packaging branch is out-of-date for some time due to an UDD bug.
<ubottu> Launchpad bug 662276 in vim (Ubuntu) "Merge vim 2:7.3.035+hg~8fdc12103333-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/662276
<Riddell> is there a UDS IRC channel?
<ebroder> #ubuntu-uds
<geser> Riddell: https://wiki.ubuntu.com/UDS-N/RemoteParticipation
<fagan> Riddell: its #ubuntu-uds for general conversation and #ubuntu-uds-<room name> separated by -
* sladen changed the topic of #ubuntu-devel to: 10.10 released on 10/10/10 at 10:10:10UTC!! | UDS: #ubuntu-uds | Natty is open, more SRUs for Maverick | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<LLStarks> keybuk, if i could have a moment of your time, i'd like to know if there will be any work towards implementing delta debs for natty. also, you mentioned upcoming changes to ureadahead a few weeks ago, what did you have in mind?
<Keybuk> LLStarks: I've no idea on delta debs, sorry
<Keybuk> and the ureadahead changes haven't worked out yet
<ebroder> LLStarks: I don't think there were any blueprints on delta debs
<ebroder> (There was one on "incremental updates", but that's changing update-manager to break updates into multiple apt operations)
<Laney> lundberg)
<Laney> >> (1=1 |#crumbs    2=2 |#php       3=3 |#short.bus 4=4 |#haskell
<Laney> >> (5=5 |#toast~ers 6=6 |#debian-uk 7=7 |#relax     8=8 |#deb~n-cli
<Laney> sorry
<ion> https://blueprints.launchpad.net/ubuntu/+spec/apt-sync
<ion> Not very active
<Laney> turns out my nametag activates the touchpad
<ebroder> ion: That's not scheduled for UDS
<LLStarks> okay. thanks.
<LLStarks> ebroder, https://blueprints.edge.launchpad.net/ubuntu/+spec/performance-desktop-n-install-footprint
<cr3> what might be an appropriate project to report a bug against dbconfig-common?
<crimsun> cr3: as in a Launchpad project or another source package in Debian/Ubuntu?
<cr3> crimsun: I was thinking Launchpad but, if I should report a bug elsewhere, I'm easy
<crimsun> cr3: I might be misinterpreting your question (I interpreted it as "what package might rdepends dbconfig-common?")
<cr3> crimsun: heh, that I could figure out :)
<cr3> oh wait, found it! nevermind :)
<nemo> So. I have a new theory as to why I'm getting:
<nemo>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<nemo>  1252 root      20   0 1027m 631m 303m S    9 16.5 866:33.70 Xorg
<nemo> I'm thinking maybe it might have to do w/ cronjobs using dbus
<nemo> 'cause surely if others were getting X11 sucking up a gigabyte almost of memory after a few days of use, you'd have a lot more bugs
<nemo> gonna disable my dbus cronjobs and see if things are better behaved
<Daviey> jussi: Can you create a blueprint for your improving default irc client session?
<Daviey> jussi: even if it's just a title and holding page without content.
<jussi> Daviey: Im working on it as we speak..
<Daviey> super!
<jussi> Daviey: help me with the correct naming? is this right? Ubuntutheproject-n-improving-the-default-irc-client
<Laney> there's a default irc client?
<hyperair> empathy, obviously.
<jussi> Laney: lol, yes...
<jussi> Laney: its pretty poor though
<Laney> well, empathy has IRC support, indeed
<jussi> so was that correct naming? anyone?
<Laney> needs team name
<jussi> Laney: I thought Ubuntuthe project was that...?
<Laney> no, that's track name
<jussi> yeah, I added community in it :)
<Daviey> jussi: I wonder if packageselection is a better track?
<jussi> Daviey: I dont think so, as this is about improvements to the program, not selecting a different one
<jussi> not that it matters overly.Â 
<Daviey> jussi: Okay, well - check the definition - http://uds.ubuntu.com/tracks/
<RobOakes> Hi, does anyone know if the plenary sessions at UDS are being streamed?
<kklimonda_> RobOakes: I don't think so. They are recorded though
<RobOakes> I'll have to look it up.  I was kind of interested in the Design Guidelines presentation.
<RobOakes> Does anyone know which IRC room is being used for Bonaire2?
<micahg> RobOakes: should be #ubuntu-uds-bonaire2
<RobOakes> Thanks micahg.
<smoser> james_w, or barry or someone can you point me at the UDD sessions at UDS
<malle> can someone tell me, what debian/libgtk-2.0-0.symbols does?
<malle> I need to do some of it on gentoo, too and I'm a little stuck here, cos I don't know how the file works
<tumbleweed> malle: it's a list of symbols included in the library, used to pick up ABI breakages and generate correct versioned dependancies
<tumbleweed> see the deb-symbols manpage
<malle> tumbleweed: thanks
<malle> tumbleweed: I'm a little stuck here... I want to port appmenu to gentoo and gtk+ just won't compile. on #ayatana I was told it could have something to do with the mentioned file
<tumbleweed> malle: pastebin your build failure
<malle> tumbleweed: hang on
<malle> tumbleweed: http://pastebin.ca/1973200
<malle> tumbleweed: the same happens with gtk+-2.22.0
<tumbleweed> malle: I don't know much about gtk+ but that's not in any way releated to .symbols files (which are called by the debian build process, outside the makefile you are using). Looks like missing library headers.
<geser> malle: looks like you missing a include or some declarations: "error: âubuntu_gtk_menu_shell_activate_mnemonicâ undeclared here (not in a function)"
<malle> tumbleweed & geser: I thought that, but I can't find any patch among the ubuntu patches that contains that function except for the ubuntu menu proxy patch wich I already applied
<geser> malle: see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk%2B2.0/natty/annotate/head:/debian/patches/043_ubuntu_menu_proxy.patch
<malle> geser: that's the patch I applied
<malle> geser: wait, I used different revision - lets see
<malle> geser: the differences are minimal, though
<malle> geser: same failure, as expected
<geser> malle: perhaps you have more luck in #ubuntu-desktop next week (when everyone is back from UDS)
<malle> hm, I'll try
<malle> geser: unfortunately I don't understand much of C, so I can't actually interpret the messages well
<malle> geser: thanks for your help anyway
<bdrung> ebroder: i was faster :P
<ebroder> hrm?
<bdrung> ebroder: the sync request
#ubuntu-devel 2010-10-26
<kklimonda_> hey, can someone with upload rights take a look at bug 658069 ?
<ubottu> Launchpad bug 658069 in gvfs "Empty files written over gvfs by some editors" [High,In progress] https://launchpad.net/bugs/658069
<crimsun> kklimonda_: uploaded
<kklimonda_> crimsun: thanks
<lucidfox> bah
<lucidfox> it's not enough for Planet Ubuntu posters to just shove Twitter links in my face, now they post Twitter screenshots. In big letters.
 * lucidfox sighs
<Laney> twitter is so offensive to you that you can't even stand to look at screenshots?
<kklimonda_> what is the "twitter screenshot"? A screenshot of twitter website? :)
<AnAnt> Hello, how do I compile a plymouth plugin ? I mean what are the flags I should give to gcc to get a proper .so file for plymouth plugin ? I do know what libs to link against
<anon^_^> this is probably a topic that's usually better suited to #ubuntu, but I was hoping for Ubuntu-dev feedback
<anon^_^> or maybe you can point in a better direction
<anon^_^> can someone explain the rationale behind the switch from gnome to unity?
<anon^_^> hmm actually probably better suited for #ubuntu-uds
<\sh> anon^_^: well..other timezone now...and your correct dude to raise the question is jono ... he wants to answer all questions
<Copernic_> is there a irc channel for the ubuntu security team?
<jpds> Copernic_: #ubuntu-security ?
<Copernic_> k thx
<twb> It's -hardened
<twb> At least, that's what I've been using...
<twb> #ubuntu-security appears to be "join only", which IIRC is a freenode bug when it tries to redirect you to a channel you're already in
<AnAnt> Hello, how do I compile a plymouth plugin ? I mean what are the flags I should give to gcc to get a proper .so file for plymouth plugin ? I do know what libs to link against
<twb> AnAnt: I don't know, but maybe "apt-get source" an existing plugin and have a look at how they do it
<AnAnt> twb: I did apt-get source plymouth, but it has a little complex build system (configure script, libtool), and the build log doesn't show what goes on
<twb> AnAnt: maybe there is e.g. a kubuntu plymouth plugin that is simpler?
<AnAnt> twb: it is also in the plymouth source package
<twb> Bummer
<twb> I haven't had much luck with code that canonical/ubuntu produces themselves; YMMV.
<twb> About all I know how to do with plymouth is to change the purple background to black
<AnAnt> twb: anyways, do you know how to produce an .so file from a .o file ?
<twb> I can't remember; ask ##workingset
<twb> It's something trivial
<AnAnt> twb: thanks
<nascentmind> Hi. When I install a dbg library. The next time I compile and link will it be using the dbg version of the library?
<nascentmind> or do i need to restart my machine?
<ebroder> nascentmind: The -dbg libraries just have debugging symbols. They don't actually change the library
<nascentmind> ebroder: yes so would it be loaded next?
<ebroder> The next time you attach gdb or something, the debugging symbols will be found
<ebroder> You could probably kick gdb to find them without even restarting it, but I can never remember how to do that
<nascentmind> ebroder: I am not finding it
<nascentmind> when I step into it doesn't go into the function of the library.
<andreoli> hi, can a PPA host kernels targeted to different distros (lucid and maverick)?
<micahg> andreoli: yes
<andreoli> thx
<micahg> andreoli: you just have to worry about the 2GB limit
<andreoli> ok, I'll wipe out old packages
<andreoli> I get this: EE: Previous or current ABI file missing!
<andreoli> I am pretty sure the current maverick kernel version is 2.6.35-22.35
<andreoli> The git log tells me it is actually 2.6.35-22.36
<andreoli> 2.6.35-23.36, sorry
<micahg> andreoli: well, that might be what they're working on, but 22.35 is in the repos ATM
<andreoli> ok thx
<andreoli> then I maybe forgot to push "skipabi=true" in rules.d/amd64.mk
<lifeless> kees: ping
<lifeless> bony 8, mate! [sec input needed for arm ppa discussion]
<DktrKranz> cjwatson: hi! if you're doing more archive stuff, mind adding an entry for ubiquity in sync-blacklist? There are chances to see a completely unrelated ubiquity source in Debian, so it won't be overwritten by accident.
<pitti> DktrKranz, cjwatson: I'll do that ^
<DktrKranz> pitti: thanks!
<pitti> done
<DktrKranz> ty
<ebroder> cjwatson: It looks like the current lua grub-extras don't have a way to get the output from a command, just the return code
<ebroder> So getting the lspci output could be difficult
<ebroder> Might be easier from a parsing standpoint to just add a lua function to iterate over PCI IDs
<ebroder> (Keeps us from having to parse the lspci output)
<BUGa_badmood> o/
<lag> maco: Can you let me know when you're back online please?
<maco> lag: hi!
<BUGa_badmood> hey maco
<maco> lag: are you in the kernel session right now? i just walked in
<lag> maco: Yep, I'm sitting next to you! :)
<BUGabundo> aha
<ebroder> *sigh* How do I deal with http://pastebin.ubuntu.com/520340/ ?
<ebroder> (I know it's because I'm not branching off of ~vcs-imports/grub/main, but I don't know how to override that logic)
<ajmitch> looks like one of the lp branches needs upgraded, you may want to check in #launchpad for the right way to go about it
<ebroder> I appear to have attracted the attention of an LP developer sitting behind me, so I'll bug him more after this session :)
<ajmitch> oh good :)
<cjwatson> ebroder: understood
<cjwatson> geser: vim> ack, will do
<cjwatson> ebroder: maybe there should be a different LP project for each of the GRUB extras, since they really aren't the same source base
<geser> cjwatson: do we have to keep the whole history of vim merges? the history is currently 9x larger that the remaining changes itself
<ebroder> cjwatson: In any case, barring superhuman bzr manipulations, I have a patch at r20 of lp:~broder/+junk/grub2-extras-lua-enum-pci. Is there a list to e-mail to get that pulled upstream?
<showard> Hi - I'm looking for someone to upload an SRU to maverick-proposed. It has already been approved by the SRU team. It's for the vino package and can be found at bug #652961
<ubottu> Launchpad bug 652961 in vino (Ubuntu) "vino-server won't start (SIGSEGV) when UPnP is enabled (SRU)" [High,Triaged] https://launchpad.net/bugs/652961
<cjwatson> geser: I don't have a strong opinion.  it would be good to keep at least recent history though
<cjwatson> ebroder: grub-devel at gnu.org
<geser> cjwatson: I'll think about where to draw the line for the next merge (I think about keeping the merge entries since lucid). Currently the last Ubuntu changelog entry is for warty from Sep 2004
<geser> cjwatson: btw do you have an opinion on bug 572627?  disabling setting "syntax on" by default would fix it but probably make other people unhappy again
<ubottu> Launchpad bug 572627 in vim (Ubuntu) "ftdetect scripts not loaded from directories added to runtimepath" [Undecided,New] https://launchpad.net/bugs/572627
<crimsun> geser: true, but we can't please everyone.  We should also just loudly publicize the change.
<ari-tczew> who is familiar with .desktop files? I have to determine MimeType. does my .desktop is correct with standards? http://paste.ubuntu.com/520405/
<crimsun> ari-tczew: see desktop-file-validate(1) in the desktop-file-utils package
#ubuntu-devel 2010-10-27
<psusi> is anyone over at UDS?  I didn't realize until today that it's actually across town from me, instead of on the other side of the world, and I'm debating bailing on work tomorrow to crash it
<psusi> but I'm trying to figure out when the most opportune time to go would be and what I would do
<achiang> psusi: http://summit.ubuntu.com/uds-n/2010-10-27/
<psusi> yea... I don't really see anything there that jumps out at me as I need to go to...
<psusi> though some face time with scott james remnant and cjwatson would not be amiss...
<psusi> hehe... I actually got to meet DJ Delorie from redhat last week in california at the Renesas Devcon....
<ggeorgy> from h
<micahg> pitti: can you accept my -proposed ubufox upload before the Linaro freeze
<jdstrand> dpm: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/626178
<ubottu> Launchpad bug 626178 in Ubuntu Translations "ufw package contains mo files" [Low,Triaged]
<neeraj> Hi, I am maintaining sugar packages for ubuntu. At present we have "sugar-0.88" in Maverick. At that time this package was synced from debian. Now for NAtty we want to rename the package to sugar-0.90 and replace the 0.88 one. But still we don't want to break sugar-0.88 users
<neeraj> I mean on running upgrade, they should be able to install "sugar-0.88"
<crimsun> neeraj: I'm unsure where your question is.
<neeraj> crisum, when a user runs upgrade on "sugar-0.88" then it get replaced by "sugar-0.90". Here appart from changes in files, the package name also changes.
<neeraj> The real messy situation is that even though the in the package names we have provided "sugar-0.88", "python-jarabe-0.88", but while installing they get installed in folder named "sugar", "jarabe" at revelant places.
<crimsun> neeraj: I think that's diametrically opposed to your desire to keep both packages parallel-installable.  Also, we should have this conversation in #ubuntu-motu, probably.
<neeraj> First I tried to install "sugar-90" manually, then it gave me conflict error that the contents are same as in sugar-0.88, but when I added sugar-0.88 in the control:: Replaces, Conficts fields, the error didn't go away
<stgraber> akgraner: ping
<neeraj> crimsun: Ok. Thanks for pointing that out. :)
<darwin> hello everyone
<darwin> does anyone know if it's possible to install ubuntu from a gentoo box that has no cd-reader?
<micahg> darwin: USB?
<darwin> micahg: don't have a usb drive available atm
<darwin> :(
<darwin> i sold my macbook pro yesterday and i'm stuck with this pentium 3 box for a couple of weeks
<darwin> :)
<slangasek> bdrung: so... who hand-picked eclipse-cdt for syncing from Debian unstable in the middle of the eclipse-cdt session? :)
<tumbleweed> darwin: grab an installer netboot image file and tell grub to boot it ( http://archive.ubuntu.com/ubuntu/dists/maverick/main/installer-amd64/current/images/hd-media/ )
<cjwatson> note that that only works if you don't need to repartition the disk that you're running the disk image from
<bdrung> slangasek: i don't know.
<slangasek> bdrung: huh, ok :)
<slangasek> bdrung: I went to go do a batch sync of new packages into natty and was surprised to find that it was already in the queue... :)
<darwin>  lol
<darwin> tumbleweed: you rock
<tumbleweed> cjwatson: oh good point
<darwin> thnx
<tumbleweed> darwin: ^ not what cjwatson said
<tumbleweed> note
<bdrung> slangasek: oh, you wanted to know who put eclipse-cdt into the queue? that was me.
<darwin> i could keep the current partitioning so i guess im all go
<slangasek> bdrung: ah; how was that injected?
<bdrung> slangasek: syncpackage
<slangasek> hmm
<bdrung> but for new package sync request are better
<slangasek> strange, LP appears to be giving me .changes files from the queue without GPG signatures
<slangasek> bdrung: I disagree - having the archive admins batch-sync such packages from Debian as is supposed to happen is better :)
<bdrung> slangasek: it was removed in karmic. would the batch-sync pull the new version of eclipse-cdt?
<slangasek> yes
<slangasek> hmm, eclipse-cdt is already in natty right now
<pitti> slangasek: would ubufox maverick SRU be okay linaro-wise?
<slangasek> so the one in the queue is redundant
<pitti> slangasek: I'll review/accept linux-meta, since that goes together with the linux SRU
<slangasek> pitti: what changes are in the SRU?  We have images pulling firefox, so we want to be sure that's in good shape
<pitti> slangasek: fixes link to release notes and changelog (from lucid to maverick)
<pitti> looks straightforward
<slangasek> pitti: yeah, that's fine
<pitti> right now you land on the lucid LP pages
<slangasek> pitti: thanks for asking :)
<pitti> ok, thanks
<cjwatson> bdrung: I heartily agree with slangasek - please don't work around us being slow to process new packages in bulk, ask us instead
<pitti> slangasek: btw, would you have a minute at some point to review the lucid udev SRU? (it's from me)
<slangasek> pitti: I hope so - I got partway through the review then got yanked away
<pitti> oh, cool
<pitti> thanks
<tumbleweed> pitti: re bug 666494 it's in the queue
<ubottu> Launchpad bug 666494 in glusterfs (Ubuntu Lucid) "Data Corruption bug in GlusterFS 3.0.2" [High,Fix committed] https://launchpad.net/bugs/666494
<pitti> tumbleweed: ah, ok
<poolie> meeting now about bzr and ubuntu in #ubuntu-uds-curacao12
<micahg> pitti: thanks
<kpoman> hello to all ! guys, I had a failed upgrade. now everythiing is stuffed... and the machine is 2500km from here. I need to resume an upgrade via ssh. help !
<benste> searching for a software-center developer -- someone here ?
<manusheel> benste: Hi Benste.
<benste> hi - could you tell me which kind of authentification it uses ? - because the auth isn't working anymore in multiple gnome parts too - but no one knows what to do - because all thought it would be gksu - which is working finde
<benste> sry finde â fine
<benste> manusheel: do you know something about this ?
<psusi> should be policykit
<benste> psusi: k looks like I'll have to troubleshoot this after dinner :-)
<benste> thanks for the information
<benste> psusi: thank you very much reinstalling solved the whole issue
<tmzt_> hmm, so this might be a *little* pre mature but is there any interest in a build a native test image for running ubuntu mobile/touchscreen images on modern/recent Android devices as an installable .apk alongside Android?
<Jewkonia> Hello Everybody
<Jewkonia> My name is Jewkonia
<Jewkonia> ikonia's Jewish cousin
<dmart> micahg: hi there, here's the wiki link for the ARM porting info you were interested in:
<dmart> micahg: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<micahg> dmart: thanks
<rhys_> So I'm trying to roll my own package. I need to package the newest version of the Amanda project, which is currently just pulled straight from Debian.
<rhys_> The packaging system is gigantic. The last place I worked on packages was Archlinux, where there are 2 tools (pacman and abs) which do absolutely everything. To create any package, you needed 1 bash script + diffs.
<rhys_> Debian/Ubuntu seems to have every tool in triplicate that all do different things. Is there any link spamming I can get from more experienced packagers for Ubuntu?
<rhys_> Oh. http://summit.ubuntu.com/
<rhys_> nobody is on IRC
<rhys_> lol.
<RAOF_> !packagingguide
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<maco> sure we are..just in other channels
<maco> also, there's #ubuntu-packaging
<ogra_ac> maco, not true, i'm here
<maco> well i was refering to the #ubuntu-uds-* channels
<ogra_ac> :)
<maco> are you here? i havent seen you
<maco> where here = uds
 * ogra_ac is in bonnaire 6
<ogra_ac> -n
<soren> ogra_ac: ...you are?
<soren> I thought I was.
<ajmitch> heh
<ajmitch> surely the room isn't that big?
<soren> It's not.
<soren> Hence my confusion.
 * ogra_ac looks underneath the chairs for soren
<soren> Oh, I'm in 8.
<soren> Never mind :)
<ogra_ac> lol
<ogra_ac> forgot your glasses ?
<ajmitch> an easy mistake to make, I'm sure :)
<soren> Does it actually say anywhere on the inside of the rooms which room it is?
<soren> I couldn't find a sign, so I looked at the schedule :)
<ogra_ac> soren, on the IRC screen
<soren> Clever you.
<ogra_ac> heh
<bdrung> doko: bug #667446
<ubottu> Launchpad bug 667446 in eclipse-cdt (Ubuntu) "Missing dependency on eclipse-pde" [High,New] https://launchpad.net/bugs/667446
<doko> bdrung: thanks. I see this is usually hidden, because recommends are installed by default
<slangasek> pitti: bug #667436> by "discussed with the community", you're not referring to Linaro, are you?  Linaro has no requirement for this to be in maverick :)
<ubottu> Launchpad bug 667436 in eclipse-cdt (Ubuntu Maverick) "eclipse-cdt for Linaro 10.11" [Undecided,Confirmed] https://launchpad.net/bugs/667436
<m_101> hi!
<m_101> i'm searching to have symbols while i debug using gdb
<m_101> i've been following this guide : https://wiki.ubuntu.com/DebuggingProgramCrash
<m_101> installed the corresponding aircrack-ng symbols
<m_101> but not symbols with coredump
#ubuntu-devel 2010-10-28
<Lex79> cjwatson: can you add in kubuntu set of packages koffice-l10n and kde-l10n-* ? also, it doesn't make sense have language-pack-kde-* (they are signed by  automatic language-pack builder) it make sense have kde-l10n-*. Thanks
<cjwatson> Lex79: please mail me about it, I'll need to figure out how to add wildcard exceptions.  (also I don't think it's worth putting in effort to actively remove language-pack-kde-*)
<Lex79> cjwatson: ok
<gaspa> someone knows if there 's a tag for bugs about  fail to build with gold linker?
<tumbleweed> gaspa: such bugs are tagged in debian (see the natty open announcement email)
<gaspa> tumbleweed: but in debian they still build, often
<gaspa> (anyway, let's see..:P)
<tumbleweed> yeah, but someone has been running rebuilds with gold
<gaspa> tumbleweed: well, i'd like to see some diff to see the fixes...
<tumbleweed> I don't know of a tag on the ubuntu side. There's a wiki page with a list of the early fixes, but I don't think people are updating it.
<gaspa> tumbleweed: link?
<tumbleweed> https://wiki.ubuntu.com/RobSavoye/GoldFixes
<gaspa> tumbleweed: thanks  alot
<tumbleweed> yeah, I don't see that many people forwarding patches to debian for this... http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=no-add-needed;users=peter.fritzsche@gmx.de
<gaspa> tumbleweed: ever faced things like Â«unrecognized option '-Bsymbolic-functions;-Wl'Â»
<gaspa> ?
<tumbleweed> gaspa: haven't seen that
<gaspa> tumbleweed: pity, thanks ;)
<jemadux> i am not a devel , but i want to know... in natty will have uninity instead of gnone ?
<sebner> jemadux: du mean unity instead of gnome-shell?!
<jemadux> yes this i mean
<sebner> jemadux: gnome-shell != gnome, it's just a part of it but the answer is yes
<jemadux> gnome shell == part of gnome 3 ?
<Oli```> Hey does anybody know what state a window has to be to be able to overlay the panel?
<sebner> jemadux: jes
<sebner> *yes
<jemadux> ok :)
<jemadux> unity is a fork of gnome shell ?
<StevenK> It is not
<jemadux> and why dont make a version of ubuntu called unibuntu ? and leave to 11.04 with gnome-shell ? :p
<om26er> can anyone please sponser bug 636161 ? (upstream recommended)(sru approved)
<ubottu> Launchpad bug 636161 in gexiv2 (Ubuntu) "shotwell crashed with SIGSEGV in gexiv2_metadata_get_orientation()" [Medium,Triaged] https://launchpad.net/bugs/636161
<Riddell> ttx: server natty kolab rescheduled for tomorrow at 11:00/16:00 in #ubuntu-uds-curacao12, if one/some of your people could be there that would be lovely
 * ttx looks
<ttx> zul_: do you think you can go ? I need to be in the automated testing / Hudson one
<zul_> sure
<ttx> zul_: or find someone else more interested than you are :)
<maco> kees: that ptrace change that breaks debuggers in 10.10... emails say to put 0 in /proc/sys/kernel/ptrace_scope but when i try to echo | tee it tells me that file doesn't exist. how do i debug?
<kees> maco: where did you find that path documented? (it's the old path)
<cjwatson> maco: cjwatson
<cjwatson> err?
<cjwatson> maco: /proc/sys/kernel/yama/ptrace_scope
 * cjwatson is not a kernel configuration path
<kees> maco: the correct path ... what cjwatson said faster than me :)
<maco> kees: i was grepping emails
<maco> cjwatson: thanks
<kees> maco: ah-ha, okay. it was discovered that gdb lost the "education" patch it had -- I actually just uploaded the fix for that to proposed
<kees> maco: but the release notes and things hsould have it updated.
<tseliot> pitti: ping
<pitti> tseliot: pong
<tseliot> pitti: can we talk a bit about jockey some time today?
<pitti> tseliot: I'd have time today at 12:00
<pitti> tseliot: my afternoon is full already
<nemo> hm. ok. I disabled all my cronjobs that use gconf, and Xorg is no longer steadily sucking up memory.
<tseliot> pitti: great, shall we meet at the front desk (where Michelle and Marianna are) by then?
 * nemo searches for known related bugs
<nemo> s/gconf/dbus/
<pitti> tseliot: yes, sounds good
<tseliot> pitti: ok, I'll see you there then
<m_101> hi!
<m_101> i found weird behavior with Unity interface
<m_101> :(
<m_101> Unity kind of "restart" when i change tabs in Kile
<svwilliams> has anyone had the issue with Unity that if you hibernate the images on the bar to the left become white blocks?
<svwilliams> when you return
<hrw|uds> hi
<hrw|uds> someone remember which kernel version does ubuntu udev require?
<ebroder> hrw|uds: udev generally requires a kernel *at least as new* as was released with that version of ubuntu
<hrw|uds> ebroder: sure, but I have a board which has 2.6.31 only so far and we want to get buntu working on it with this version
<ebroder> hrw|uds: Then you probably either need to look at karmic (or at least karmic's udev) or be prepared for some potential pain
<rhys> did anyone ever notice that http://packages.ubuntu.com/lucid/gnuplot-nox package pulls in a ton of X11 libraries?
<rhys> its not actually "nox"
<geser> which ones? I don't see any X package in depends for that package
<ChogyDan> geser: maybe it is groff
<rhys> Its groff
<rhys> http://packages.ubuntu.com/lucid/groff
<rhys> those pull in alot more
<rhys> is there a flag to apt/dpkg to shut off installing "recommended"
<rhys> ?
<psusi> --no-install-recommends
<ebroder> or --without-recommends if you're using aptitude
<\sh> rhys: in /etc/apt/apt.conf.d/99norecommends paste the following:http://paste.ubuntu.com/521508/
<\sh> dunno if aptitude respects apt configurations
<ebroder> \sh: It should
<\sh> ebroder: I try to avoid aptitude ;)
<ebroder> \sh: I'm less opinionated about it than I used to be now that apt-get's resolver got better
<rhys> interesting
<rhys> should groff be suggested and not recommended?
<\sh> rhys: depends?
<\sh> rhys: which packages
<\sh> s/s$//
<rhys> \sh, for the "gnuplot-nox" package
<rhys> i am not familiar with the policy on what recommends should be
<rhys> it just seems strange to me that "apt-get install gnuplot-nox" gets "groff" which gets a bunch of X11 libraries.
<\sh> Well, recommends only says (as I interpretate it), that it will install additional packages which will give the app in the to be install package more functionality...which is for desktop ok, regarding a server, I would always go without recommends...
<micahg> I thought recommends is for packages that would be used with the package in most scenarios
<\sh> micahg: well, they are not "Essential" for the functionality...but gives eventually more functionallity...well, on servers I always deploy apt without recommends installation...especially on vmware machines, with openvm-tools...
<micahg> \sh: right, essential is depends
<rhys> ah. right
<\sh> micahg: when zf 1.11 is out and reaching natty..you get again some work ;)
<micahg> \sh: heh, no problem, maybe I'll be MOTU by then and we can backport officially :)
<\sh> micahg: I thought you wanted to be motu at the end of UDS?
<micahg> \sh: yes, but we'll see
<\sh> micahg: good luck :)
<micahg> \sh: thansk
<micahg> *thanks
<Keybuk> kees: I saw this http://fedoraproject.org/wiki/Features/RemoveSETUID and thought of you
<kees> Keybuk: yup. Debian and Ubuntu need to support fscaps first. https://wiki.ubuntu.com/Security/FilesystemCapabilties
<kees> Keybuk: Fedora is just bringing this idea back up because of the recent libc vulnerabilities
<Keybuk> indeed
<kees> which isn't very helpful because at least something will still have CAP_SYS_ADMIN, and that's virtually everything anyway. :P
<ebroder> Are they going to drop sudo or something?
<ebroder> Push everything through PolKit?
<kees> ebroder: the ultimate goal has always been to get rid of sudo in favor of PolKit, yeah.
<Keybuk> kees: ah, I remember this - we can't do fscaps because we use squashfs for the live cd
<ebroder> Keybuk: Doesn't squashfs have xattr support?
<ebroder> (at least in theory)
<Keybuk> squashfs barely has permissions support ;-)
<Keybuk> in fact, we're lucky it does directories
<cody-somerville> lol
<bmm> I've got a python package with a setup.py which defines "entry_points" containing "console_scripts", which easy install will create into a file in the bin directory but cdbs does not seem to understand that.
<bmm> Any tips, do I need to symlink, patch, or is there a way to configure cdbs to understand that?
<ebroder> bmm: What does cdbs need to understand about that?
<ebroder> If you're using the python-distutils.mk class, it should run (something like) setup.py install, which will install the script into (something like) $(DESTDIR)$(PREFIX)/bin, in which case everything will be fine
<bmm> ebroder: ok, I'll have to check again then..
<bmm> ebroder: Ok, it's not working yet, but I'm to tired to finish it today. I'll have a look at it tomorrow or something. Thanks for the response!
<ebroder> bmm: Hmm...it's possible that cdbs is passing some weird argument that keeps the setup.py script from creating the script (like --one-version-centrally-managed or whatever that argument is called)
<bmm> ebroder: I'll write that down for tomorrow :)
<ebroder> Hmm...I can't magically build a URL for ".dsc file of the current version of <package> in <release>", right? I have to hit the API?
<dholbach> ebroder, apt-get source? :-)
<ebroder> dholbach: For arbitrary values of <release> :)
<dholbach> ebroder, -t :)
<ebroder> Thet let's me pull from different pockets but not, say, get a maverick source package on a lucid machine
<dholbach> chdist might be easier
<ebroder> whoa...
<ebroder> Never seen that before
<ebroder> Although I still don't think that actually solves this particular problem; I'll just use the API
<dholbach> ebroder, what exactly are you trying to do? just get a source package from a different release?
<ebroder> I'm trying to write a script that does that. (This is eventually going to be for backports testing)
<geser> ebroder: something like "pull-lp-source" in u-d-t?
<dholbach> ebroder, to me chdist looks like a good idea for using that :)
<ebroder> geser: Uh...yeah. Something exactly like pull-lp-source :-P
<ebroder> Thanks for that
<micahg> stgraber: are you interested in merging pidgin?
<stgraber> micahg: not really
<micahg> stgraber: ok, thanks
 * micahg will prepare a merge later
<stgraber> micahg: I just happen to be the last uploader because a colleague of mine needed a patch from upstream to be applied to our package. Latest upstream should have it so this delta can be dropped.
<micahg> stgraber: right, I figured as much, but wanted to ask anyways
<Riddell> skaet: ping
<skaet> Riddell: hi
<slangasek> ogra_ac: since you appear to be able to reproduce bug #652035, can you confirm the fix for SRU verification?
<ubottu> Launchpad bug 652035 in alsa-lib (Ubuntu Maverick) "libasound2 not finding usb sound card" [High,Fix committed] https://launchpad.net/bugs/652035
 * ogra_ac checks which one that is
<ogra_ac> slangasek, comment 11 isnt enough ?
<slangasek> ogra_ac: if you can confirm that the fix crimsun uploaded to his ppa is identical to the one that was in the SRU queue?
<ogra_ac> slangasek, already done
<ogra_ac> i commented
<slangasek> ogra_ac: ok, thanks!
#ubuntu-devel 2010-10-29
<ebroder> I realize that users should never see it at all, but could we suppress the "getpwid_r(): failed due to unknown user id (0)" warning from plymouth/glib by just creating a bogus /etc/passwd in the initrd?
<ebroder> (with an entry for root)
<slangasek> ebroder: that's the appropriate workaround, I believe.  Bug #649917 - test it out, submit?
<ubottu> Launchpad bug 649917 in plymouth (Ubuntu Maverick) "GLIb-WARNING **: getpwid_r(): failed due to unknown user id" [Undecided,New] https://launchpad.net/bugs/649917
<ebroder> slangasek: Will do
<GanonKiller> there is a bug with alsa & VLC
<GanonKiller> VLC failed to initialize your sound output device (if any).
<GanonKiller> Please update alsa-lib to version 1.0.23-2-g8d80d5f or higher to try to fix this issue.
<ebroder> slangasek: You're not interested in seeing this SRU'd, are you?
<slangasek> ebroder: I am, actually; this issue generates a lot of bug mail noise that is obviously not helpful for fixing the underlying plymouth issues
<ebroder> slangasek: Ah, good point. If I can get something working, I'll try to push it back to Lucid too
<slangasek> ta
<GanonKiller> there is no update
<slangasek> GanonKiller: please file a bug against the vlc package, then with the command 'ubuntu-bug vlc' - this is not a bug reporting channel
<ebroder> Hmm...why does lp:ubuntu/plymouth not have the 0.8.2-2ubuntu5 version Riddell from the beginning of the month?
<slangasek> ebroder: bug #653832
<ubottu> Launchpad bug 653832 in Ubuntu Distributed Development "Import fails with "trying to import version ... again"" [High,Triaged] https://launchpad.net/bugs/653832
<slangasek> (http://package-import.ubuntu.com/status/)
<ebroder> blargh
<miked> looking for php/java project to hack on
<miked> very much newbie, anyone needs help?
 * ebroder squints
<ebroder> So plymouth in the initrd is only enabled if the FRAMEBUFFER option is set, which is done by casper but not the default install?
<slangasek> ebroder: it's only in the initramfs if we have something else in the initramfs that *needs* to prompt or show progress; otherwise it's only started post-initramfs so we can get to the real rootfs faster
 * ebroder nods
<ebroder> well, i've hacked it into my initramfs, and hacked an /etc/passwd into my initramfs, and that doesn't seem to be enough to suppress the error. maybe i need an nsswitch.conf too or something?
<slangasek> hmm
<slangasek> probably
<ebroder> (i thought libc would fall back on compat or files or something if there wasn't an nsswitch)
<ebroder> hmm...nope, making a fake nsswitch.conf ("passwd: compat") and copying /lib/libnss_compat* into the initrd doesn't seem to be enough either
<ebroder> ah - libnss_compat has dependencies
<slangasek> nss_files is really what you want
<slangasek> and leave out nss_compat, that's just overhead
<ebroder> ok
<jmehdi> could someone help me, I'm remastering ubuntu live cd and I have a problem with plymouth...
<pavolzetor> Hallo
<pavolzetor> I have reported bug a while ago
<pavolzetor> and also posted patch
<pavolzetor> but no one cares
<pavolzetor> https://bugs.launchpad.net/ubuntu/+source/liferea/+bug/653995
<ubottu> Launchpad bug 653995 in liferea (Ubuntu) "reversed order of items in indicator applet and missing icons" [Undecided,New]
<pavolzetor> anyone?
<corecode> hey
<corecode> i've been reading for an hour already, but i can't find a simple solution for uploading a debian packge into my ppa
<corecode> without having to edit the changelog
<corecode> what's the preferred way to tell the system to build this in, say, maverick instead of unstable
<kklimonda_> you have to change the changelog
<corecode> that seems excessive
<corecode> for example bsd-mailx has version 8.1.2-0.20100314cvs-1
<corecode> there is no ubuntu either
<corecode> how does that work then?
<kklimonda_> by that do you mean "how do I upload it to ubuntu ppa" ?
<corecode> i don't understand
<kklimonda_> that's probably because I'm still half-asleep.
<corecode> ditto :)
<kklimonda_> oh, I understand
<kklimonda_> bsd-mailx in the 8.1.2-0.20100314cvs-1 version doesn't have an ubuntu release in the changelog because it has been synced from debian directly.
<kklimonda_> but you can't do that for PPAs
<corecode> but i can't do that for my ppa?
<corecode> if i wanted to build versions for jaunty, karmic, lucid and maverick, i'd have to do 4 manual modifications, run a debuild, then a dput?
<kklimonda_> yeah, at least for now. The problem is that you can't have the same package with the same version but different pockets in the single ppa
<kklimonda_> so you have to upload them separately anyway.
<kklimonda_> okay, I have to go for a breakfast
<corecode> yes i realized that
<corecode> shouldn't there be an easy way to specify the "pocket" during dput or debuild?
<corecode> without having to change the changelog
<StevenK> Nope, the pocket is figured from the .changes file
<corecode> ok
<corecode> so, can that pocket be changed when creating the changes file?
<corecode> i'm quite certain i saw a way to do that some time ago
<corecode> but i can't find it, of course
<StevenK> No, dpkg-genchanges can't do that
<corecode> that's a bit unfortunate, isn't it?
<corecode> not sure i understand completely - do i upload a source package or a binary package?
<sladen> corecode: source.  *only*
<sladen> corecode: the build machines (buildds) compile it
<corecode> i see
<corecode> thanks
<corecode> so it says that packages in debian sid will automatically appear in ubuntu
<corecode> is that so?
<corecode> or only for packages that already exist in ubuntu
<tumbleweed> corecode: the archive admins will periodically review new pcakages not yet in ubuntu and sync them in
<corecode> aha
<Copernic__> is it easy to program something in Ubuntu? I'm used to Java, did do some C++, but thats 10 years ago :)
<Copernic__> for ubuntu*
<corecode> i don't think that it makes any difference to any other unix
<Copernic__> I guess I should just try :)
<corecode> type your code, compile, run
<Copernic__> corecode, I was thinking about implementing this http://brainstorm.ubuntu.com/idea/24525/
<corecode> i see
<corecode> good luck
<Copernic__> hehe
<Copernic__> I never programmed something for linux before
<corecode> i honestly think that idea is silly at best
<corecode> and i have no experience in gui design or development
<Copernic__> corecode, I came to this idea becaus the apparmor profile for firefox is disabled
<Copernic__> https://wiki.ubuntu.com/SecurityTeam/FAQ#Firefox%20AppArmor%20profile
<Copernic__> I thought that users should be able to change this if they wanted to
<corecode> they can, can't they
<Copernic__> it's something only a technical user would do
<corecode> of course
<Copernic__> haha you don't see the problem do you :)
<Copernic__> the general public isn't technical
<corecode> right
<corecode> so they won't know about apparmor
<corecode> or what it means
<Copernic__> indeed, and I was under the impression that apparmor is pretty important, because if some security threat is knocking at your door, it probably came with firefox or evolution
<corecode> quite likely, yes
<Copernic__> corecode, thats when I was starting to worry about the security for the general public :)
<corecode> then you need to fix it so that the default will work
<Copernic__> corecode, I'm guessing they tried that
<Copernic__> bbl, I'm going to take a 20min nap :)
<corecode> how do people do automated uploads?
<corecode> don't they use passphrases on their gpg keys?
<kklimonda_> corecode: I have a separate account (with separate key) for automated uploads.
<corecode> and that key doesn't have a passphrase
<kklimonda_> and now I don't do that anyway since launchpad has gained the ability to create nightly builds.
<kklimonda_> right
<corecode> from bzr branches?
<corecode> how can it do a nightly build?  i thought the changes file has to be updated
<kklimonda_> you can read more about recipes here: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
<kklimonda_> the idea is that launchpad branches your code (along with the debian/ subdirectory) and then bumps the changelog for every release.
<corecode> ah
<corecode> yes, that would be convenient
<corecode> hm.
<corecode> seems that package *is* in ubuntu
<corecode> somehow i could set information that this package is in ubuntu or debian
<corecode> but i can't find it anymore
<hooke> i've always been curious about how the grahics driver works,but i couldn't find any resources about this.anyone  can give me some  suggestions?
<micahg> pitti: thunderbird on Ubuntu was deferred till Natty + 1, but we have a few work items to get the ball rolling
<pitti> micahg: thanks for the heads-up; I targetted it to natty, do you want this spec for the "get the ball rolling" parts, or want me to untarget it again?
<Ian_Corne> thunderbird in replacement of evince?
<Ian_Corne> err evolution?
<JontheEchidna> james_w: ping
<micahg> pitti: for me it doesn't matter, if jcastro needs it for his work item, then we can leave it targetted for natty
<pitti> micahg: ack; we can always postpone/untarget later then
<pitti> micahg: what's PGO?
<micahg> pitti: Profile Guided Optimizations
<pitti> micahg: we were wonering about what priority https://blueprints.launchpad.net/ubuntu/+spec/other-desktop-n-firefox-pgo-builds shold have
<micahg> pitti: well, chrisccoulson has done most of the work already for it, but AFAIK, upstream isn't even doing this yet, so it's a nice to have, but not critical
<micahg> pitti: we'll get a start speed increase if we can get this done though, so that might impact it as well
<pitti> micahg: thanks; are you okay with being the approver for that one?
<micahg> pitti: well, if you like, seems a little weird though
<pitti> micahg: for the purpose of peer review; I can be the approver, too, but I'm afraid I know nothing about PGO
<micahg> pitti: if it's just peer review, I'm happy to do it
<pitti> micahg: thanks
 * micahg still needs to read more on it
<hallyn> didrocks: regarding alt-t in terminal in 10.10 unity, you marked that triaged - is that bc it's fixed upstream, or for some more subtle reason?
<didrocks> hallyn: triaged is "the issue is known and confirmed". Upstream has an idea of where the issue is in that case.
<andreserl> slangasek: ping?
<magedragon25> maybe I can get some help here....I compiled my first kernel last night...I wanted a kernel specific to my hardware, but I think it compiled as a 32bit kernel. It stalled at the splash screen. Any tips on what to do next time, and how do i track down what went wrong this time
<hallyn> didrocks: ok, thx - slightly different from teh two other definitions of 'triaged' i've heard :)  i was hoping it was more of a 'the fix is definately upstream'.  but thanks
<didrocks> hallyn: no, this is "fix commited" in the upstream task
<hallyn> alrighty.  (then i'll hold off a bit on upgrading the netbook)
<james_w> hi JontheEchidna
<JontheEchidna> james_w: hi, I was looking at policykit-1 looking at merging it/updating it to the latest upstream release. The second half of the 03_complete_session patch doesn't apply anymore due to upstream changes: http://paste.ubuntu.com/522254/
<JontheEchidna> is the patch safe to drop, or do changes need to be made to it?
<james_w> JontheEchidna, see the upstream bug report. I think it is still needed
<james_w> JontheEchidna, actually, that half can be dropped I think
<JontheEchidna> james_w: ok, cool
<Cheery> I'd like to find some mechanism that lets me turn a virtual terminal to the opengl context for a duration of the executing program.
<Cheery> gotten it was impossible while back then. but what about now?
<Cheery> how quiet..
<hawkal> Please can someone tell me where I can find out more about the 64bit netboot install e.g package list/ source code? I would like to take a look at the guts of it.
<hawkal> I tried looking in cdimage.ubuntu.com but I couldn't see anything relevant to the netboot installs a part from iso files
<cjwatson> apt-get source debian-installer - the stuff in build/ is the build system, the stuff in doc/ is documentation on how a bunch of stuff around it works.  you'll need to apt-get source additional packages from the package lists there in order to inspect individual components of the installer
<cjwatson> https://wiki.ubuntu.com/Installer/Development
<hawkal> Thank you very much cjwatson
<shadeslayer> pitti: ok you will probably get the mail 2 times, the first time i forgot to sign the key and just sent the keys
#ubuntu-devel 2010-10-30
<psusi> on the livecd, isn't update-grub supposed to be disabled when installing a new kernel?  how is that done?
<psusi> hrm.. it is intentional that logging into the gnome desktop adds your uid to the acl for /dev/sr0 right?  what component is responsible for that?
<flyguy> hi
<flyguy> what happened to #ubuntu ? everyone is banned?
<flyguy> what is the min size needed for netbook ubuntu installation
<ebroder> psusi: update-initramfs is disabled on live cds (although it attempts to heuristically detect live usb as a different thing). it's done by /usr/share/initramfs-tools/scripts/casper-bottom/43disable_updateinitramfs (which gets copied into the initramfs)
<psusi> ebroder, yes, but what about update-grub?  I'm looking at a bug report of update-grub failing on a liveusb, but update-grub shouldn't even be run there should it?
<ebroder> psusi: To my knowledge, there's nothing to *keep* it from being run
<ebroder> But given that live everythings use syslinux right now, it probably shouldn't be run
<ebroder> (s/sys/iso/ as necessary)
<timtootin> can someone point me to where to begin developing programs for ubuntu
<psusi> ebroder, so what component should the bug be filed under?  it's currently on linux and that isn't right.... maybe it should be grub2?  or should it be casper?
<ebroder> psusi: If anything, it's a casper bug
<ebroder> psusi: Although attempting to hunt down every command that it doesn't make sense to run on a live cd is something of a sisyphean task
<psusi> ebroder, ok... I was looking into why it's run and it seems the grub2 package installs a file in /etc/kernel/postinst.d which gets run by the kernel package postinst script... so either casper should remove this file, or it should be modified to not do anything when on a livecd, or the kernel package I suppose could be run to not bother invoking it maybe...
<psusi> why do you say that?
<ebroder> timtootin: What sort of stuff are you looking to do?
<ebroder> psusi: Ah, I had forgotten about the /etc/kernel hook. Yeah, I think it probably makes sense to do the same thing to update-grub in casper that we do to update-initramfs, in that case
<psusi> which is?
<ebroder> Move it out of the way and replace it with a no-op shell script
<ebroder> Look at the file I referenced earlier
<psusi> have casper remove the script, or modify the script to check some sort of variable that casper sets to say you're on a livecd dummy?
<ebroder> casper can remove the script - because it's a live cd, the change isn't persisted
<ebroder> (or if it's a live usb, you never want to run update-grub at any point, even in the future)
<ebroder> Did you look at the file I mentioned?
<psusi> I don't seem to have it
<psusi> hrm... but I guess that makes sense, so I'll reassign the bug to casper
<ebroder> You don't generally have the casper package on an installed system. Grab the source - should be easy to find in there
<ebroder> psusi: Can you subscribe me to your casper bug? I'd like to follow along. (I'm ~broder on LP)
<psusi> ebroder, done... bug #667578
<ubottu> Launchpad bug 667578 in casper (Ubuntu) "Kernel Upgrade on 10.10 Live USB runs update-grub" [Medium,Confirmed] https://launchpad.net/bugs/667578
<ebroder> ty
<ebroder> Ugh. That description is...only barely helpful
<ebroder> psusi: Are you interested in developing a patch for this? If not I can probably come up with something quickly
<psusi> I know hardly anything about casper
<ebroder> Ok, cool. I'll go ahead and take a stab at it, then
<psusi> though I wonder if this shouldn't really be fixed in grub2..
<psusi> I mean should the package really fail to be configured if it can't install the boot loader?  if you (re)install it to the hard disk while booting from a livecd, you will run into the same problem and casper won't help there
<ebroder> There are some assumptions baked into grub that if the package is installed, then the bootloader is too. It's possible that behavior is a bug
<psusi> that's what I was thinking...
<psusi> you should be able to install the package into a chroot without having the boot loader be installed anywhere...
<ebroder> What version of grub are you using? grub2 doesn't seem to ship an /etc/kernel/postinst.d file
<psusi> 1.98+20100804-5ubuntu3
<psusi> psusi@faldara:/usr/src$ dpkg -S /etc/kernel/postinst.d/zz-update-grub
<psusi> grub-pc: /etc/kernel/postinst.d/zz-update-grub
<ebroder> Changed in maverick, apparently
<psusi> how did it work before?
<ebroder> Uh...I guess /etc/kernel/postinst.d is the transition path from away from /etc/kernel-img.conf
<psusi> I was wondering about that... it looked like the kernel package postinst had code that looked to that conf file to see if it should run lilo or some other boot loader... but grub was suspiciously absent
<ebroder> I still think I lean towards a casper fix. The reason update-grub is *erroring*, instead of simply being useless, because we're running on top of this screwy aufs-mount thing
<ebroder> If / was a real filesystem, I suspect update-grub would run without problem
<ebroder> But in any case, I'm not actually sure I know how to fix this in a way that will work if/when the livecd transitions to grub (or a user builds their own casper-based system using grub)
<psusi> what does the livecd using grub or not have to dow ith anything?
<psusi> oh foo, I'm too tired and drunk to figure this out now... just going to go to bed and think on it for tomorrow...
<uni4dfx> anyone know, will the old gnome-panel applets still be usable in Unity?
<YokoZar> slangasek: if you don't give me multiarch this release, I'm going to add every single dependency of gstreamer0.10-plugins-good to ia32-libs
<switchgirl> hi i have found a security hole
<switchgirl> epiphany webbrowser allws scripts to run othr applications
<bilalakhtar> !filebug | switchgirl
<ubottu> switchgirl: If you find a bug in Ubuntu or any of its derivatives, please file a bug using the command Â« ubuntu-bug <package> Â» - See https://help.ubuntu.com/community/ReportingBugs for other ways to report bugs - Bugs in/wishes for the IRC bots (not Ubuntu) can be filed at http://bugs.launchpad.net/ubuntu-bots
<switchgirl> i am on a dating site, they play a sound to say there is anew message and it started the movie player app i use - the file played automatically
<andreserl> It is not correct to have a meta-package that Depends on libraries right?
<geser> what is the purpose of that meta-package?
<andreserl> geser: there's was a package libcluster-glue that contained shared libraries. Now, that package has been splitted to one package per library (By Upstream/debian). However, he is also making libclucster-glue depend on all of the splitted libraries
<andreserl> geser: using it as a transitional package. is it correct to do that?
<geser> andreserl: so it's more a transition package to not break the current dependencies?
<geser> yes
<andreserl> geser: http://pastebin.ubuntu.com/522770/
<andreserl> geser: ok then :). Thanks
<s|icer> hey guys
<s|icer> i'm trying to set up my email, but thunderbird isn't accepting it.
<s|icer> i think because i used an alternate domain, hushmail.com lets you use hush.com, so my email is slicer@hush.com
<s|icer> so when i use imap.hushmail.com and pop.hushmail.com, it will connect to the servers, but it kicks slicer out as an invalid username
<azeem> s|icer: please ask in #ubuntu
<s|icer> this doesn't have anything to do with ubuntu
<s|icer> i'm just trying to get all the dev gear going
<s|icer> with my launchpad account and whatnot
<s|icer> how imperative is it that i have said email account?
<night_fox1> Hi. I'm having problems linking with libtool. My library gets linked, but then when I try and link against it, I get "undefined reference to foo" where foo is a function the library. How can I sort this out?
<azeem> night_fox1: this channel is for Ubuntu development, not development on Ubuntu, please ask elsewhere
<night_fox1> azeem, I can't find a channel that deals with the gnu build system, so I was hoping someone might be able to help me out. Where do you think would be the best place to ask?
<azeem> #gnu?
<night_fox1> azeem: ok, i'll ask there.
<flyguy> hi
<flyguy> are most people bannecd from #ubuntu?
<flyguy> i don't understand why I am banned
<slangasek> most people are not banned in Ubuntu, but this is not the channel where you'll find people who can help with that - try #ubuntu-ops
<slangasek> in #ubuntu, I mean :)
<phenom> Is there any way to pursuade Canonical to not replace Gnome with the buggy/incomplete Unity?
<phenom> :)
<OdyX> phenom: being sabdfl ? :->
<phenom> I bet if I offer Shuttleworth a crisp $20 he will reconsider.
<phenom> :)
<SpamapS> phenom: Unity is buggy today.. but do you really think it will stay that way?
<phenom> SpamapS, considering ubuntu's poor quality control, yes I do.
<SpamapS> phenom: poor in relation to what?
<phenom> Every upgrade breaks something, and reinstalling fresh every upgrade has scaringly enough become a viable solution to ubuntu's poor quality control
<phenom> I'm not hating
<SpamapS> poor is a relative statement. who or what is it poor in relation to is all I'm asking.
<phenom> But if you ask me, ubuntu, needs to stop rushing, and get back to working on things like system stability
<SpamapS> phenom: we just wrapped up a UDS where testing was a huge focus
<phenom> SpamapS, I mean, poor as in I don't trust sudo apt-get dist-upgrade at all any more. I have been forced to reinstall fresh because I was tired of fighting bugs incroduced with each upgrade.
<SpamapS> phenom: thats not even a supported way to upgrade.
<phenom> SpamapS, Do you think a change as big as a newer UI should require a bit more testing/feedback?
<SpamapS> phenom: I do think that Unity will be buggy as a desktop shell for natty.
<SpamapS> I think natty is probably the last one where new big stuff like that should be introduced.
<SpamapS> after that, really big changes need to wait for after 12.04
<phenom> right
<SpamapS> and if you think about it, by making Unity the shell for netbook edition in maverick means there is a set of bugs on the lowest performing hardware... once those are fixed on netbooks, more powerful machines should fly
<phenom> I'd just like to see ubuntu ease in to such a big change, instead of forcing people onto something which would potentially introduce a lot of problems.
<phenom> And maybe oppfer users the choice to try it, like make a "unibuntu" of sorts, before ditching gnome in it's entirety
<phenom> I mean, I can install whatever UI I want, so it is sort of 6 in one hand tree deuces in another, but the rapid dev in asthetics over quality spooks me out a bit is all
<SpamapS> Ubuntu is easing into it. If you look at the LTS release cadence.
<phenom> Well I hope so. I'd hate to see more fragmentation in the linux community
<SpamapS> "The latest crack" is almost a cliche in discussions about people who want new stuff. We all know it is crazy to get the hot new stuff.. but its just soooo fun
<phenom> :)
<SpamapS> phenom: Yeah, that was discusse at UDS as well. sabdfl specifically addressed it in the keynote by relating it to the "Peoples Front of Judea vs. Peoples Judean Front" from Monty Python.
<s|icer> if i created a gpg key with an old email that i have now changed, should i create a new key with the new email? its not like i can't still use it, the emails just don't match.
<SpamapS> s|icer: keys can have uids added
<s|icer> SpamapS: ah, ok
<SpamapS> s|icer: gpg --edit $keyid
<SpamapS> s|icer: or your favorite gui tool of course
<s|icer> SpamapS: how do i get launchpad to update said change?
<SpamapS> s|icer: just add the key again
<s|icer> SpamapS: I just did a gpg --edit-key <keyid> and then did adduid, added the correct one, then did 1, deluid and killed the first one.
<s|icer> SpamapS: however, now the new one says [ unknown] next to it, the original said [ultimate] next to it, but i did a trust, 5 (ultimate)
<SpamapS> s|icer: was the old email bad, or have you just lost access to it?
<s|icer> well, without paying a fee, i didn't have access to their IMAP/SMTP
<s|icer> so I just changed to a different provider.
<s|icer> but I made the gpg key before I realized that.
<s|icer> but i was wanting my key to reflect the proper email
<SpamapS> yeah, I would too. I wonder if you can just add a comment to the old one though.
<s|icer> well, i deleted it. i haven't saved my changes yet though
<SpamapS> s|icer: were it my key, I'd want to keep the old email but have something in the key that says "xxx@foo.com no longer accessible"
<s|icer> well, heres what i'm looking at now.
<SpamapS> s|icer: though technically it might be reused
<s|icer> pub  *****/********  created: 2010-10-30  expires: never       usage: SC   trust: ultimate      validity: ultimate
<s|icer> sub  *****/********  created: 2010-10-30  expires: never       usage: E
<s|icer> [ unknown] (1)* Sheridan Roberts (The Slicer) <slicer@gmx.com>
<s|icer> Command>
<SpamapS> That means there is just the one uid
<SpamapS> which is what you wanted.
<s|icer> yeah, but my concern is the "unknown"
<s|icer> i was trying to get it to say "ultimate"
<s|icer> though i wonder if that raelly matters
<s|icer> i could just make a new key.
<s|icer> i haven't done anything with it yet.
<s|icer> because i saved, resent the key to the keyserver
<s|icer> then reactivated it on launchpad
<s|icer> still has the old uid
<BUGabundo> guud evening
<BUGabundo> remember: today changes DST
<mtaylor> anybody got a pointer to upstart packaging info for lucid? I'm backporting something, and having a debian/blah.upstart file works in maverick, but doesn't seem so much to in lucid... do I just suck?
<mtaylor> nevermind ... pebkac
<GanonKiller> has combat arms been developed for meerkat yet?
<fagan> GanonKiller: this channel isnt for questions like that. You need to ask the developers of that game if they are porting it.
<fagan> This channel is for development of ubuntu
#ubuntu-devel 2010-10-31
<ebroder> ScottK: is it reasonable to INVALID a backport request for a bug fix? There's a separate bug tracking an SRU for the same fix
<ebroder> (bug #666204; sru request is bug #619015)
<ubottu> Launchpad bug 666204 in maverick-backports "Please backport dictionaries-common 1.5.15 to Maverick" [Undecided,New] https://launchpad.net/bugs/666204
<ubottu> Launchpad bug 619015 in dictionaries-common (Ubuntu) "dictionaries-common versions of ispell.el and flyspell.el break recent emacsen" [Undecided,Fix released] https://launchpad.net/bugs/619015
<ebroder> slangasek: i've been just pressing escape as soon as plymouth shows up to see the warning. more reliable than finding the right planetary alignment to see it :)
<Kaleo> hi
<Kaleo> there is a bug in maverick fixed in the natty package and I cannot find the documentation for the process of requesting a backport of the fix
<Kaleo> here is the bug: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/664531
<ubottu> Launchpad bug 664531 in xdg-utils (Ubuntu) "xdg-email fails with Ubuntu 10.10" [Undecided,Confirmed]
<ebroder> !sru | Kaleo
<ubottu> Kaleo: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Kaleo> ebroder: thank you very much
<ebroder> np
<slangasek> ebroder: oh; feel free to amend the test case
<BlackZ> lucidfox: bug #608159: are you working on that merge?
<ubottu> Launchpad bug 608159 in liferea (Ubuntu) "Please merge liferea 1.6.4-1 from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/608159
<lucidfox> BlackZ> no
<BlackZ> lucidfox: ok, if you don't mind, I'd merge it :)
<corecode> hey
<corecode> i'm trying to package a setuid binary, but somehow that doesn't work
<corecode> is there something special i need to do?
<corecode> the permissions appear unchanged, already in the staging area
<debfx> corecode: dh_fixperms might remove the setuid bit
<corecode> ah, thanks
<corecode> that's it
<corecode> or not :/
<corecode> ah yes
<dylan-m> d
<iulian> e
<BUGabundo> f
<azeem> dylan-m: please don't do that
<corecode> any suggestions how to run a single command on bootup from a package?
<corecode> provide an init script?
<corecode> or add a @reboot line to cron?
<debfx> corecode: I'd go with an init script or upstart job
<corecode> i'd like to keep it compatible with debian
<corecode> do they use upstart?
<debfx> no
<corecode> ok
<debfx> don't forget to check in the init script if the package is still installed
<ggeorgy> hi
<highvoltage> persia: debian has yet another definition for 'flavour': http://wiki.debian.org/DebianPureBlends
<bgamari> Scott Remnant in the house?
<highvoltage> bgamari: he's Keybuk on irc, so doesn't seem so
<bgamari> Is it common that distribution specific changes to kernel parameters exposed through /proc/sys are changed in the kernel tree instead of /etc/sysctl.conf?
<bgamari> Scott seems to think that if a change in the default swappiness were to happen it should happen in the kernel tree
<bgamari> which seems a little strange to me
<bgamari> isn't this the precise reason we have sysctl(8)
<ogra_ac> bgamari, well, not if you can convince upstream to take the change
<ogra_ac> its one piece less to maintin
<ogra_ac> *maintain
<ogra_ac> sysctl is to override defaults
<bgamari> ogra_ac: Precisely
<bgamari> ogra_ac: Upstream will not take a change in the default swapiness
<bgamari> this seems quite clear
<bgamari> especially not a change to what ubuntu should be using in its desktop distribution (probably between 10 and 30)
<bgamari> I suspect Scott was suggesting that the swapiness should be changed in the ubuntu kernel tree
<bgamari> but still, as you said, sysctl is to override defaults
<bgamari> why would we pollute the ubuntu tree with patches that have no hope of making it upstream when there is a perfectly good mechanism for overriding this value in userspace?
<ebroder> sysctl can also be used to set defaults. c.f. /etc/sysctl.d/10-zeropage.conf
<ebroder> err, reading the comments, i guess that's actually a bad example
<bgamari> Either way, this insistence on going through the kernel tree is one of the few reasons #516834 hasn't moved forward
<bgamari> we have known that the current swapiness is ill-suited for desktop use for almost a year
<bgamari> s/known/recognized/
<bgamari> it's been known for far longer than that
<ebroder> reading the discussion, i agree with Keybuk. and it looks like the reason the bug isn't making any progress is because people were being stubbornly unhelpful while JFo was trying to triage
<ebroder> (primarily that the different kernel flavors give you the distinction you want to figure out what swappiness should be set to, which you don't have in the procps package)
<bgamari> ebroder: Perhaps there could be packages containing bits of server- or desktop-specific configuration (e.g. sysctl.d files)
<ebroder> we have that already. linux-image-generic vs. linux-image-server
<bgamari> true
<bgamari> I guess that would be the appropriate place in that case
<bgamari> ebroder: It's true that people weren't particularly helpful
<bgamari> but it's also true that a vague request for "testing" with no further qualification isn't going to get you particularly useful responses
<ebroder> bgamari: people were actively unhelpful and antagonistic to the guy whose job it is to figure out what bugs the kernel team should be paying attention to. i think the result was fairly predictable
<bgamari> fair enough
<bgamari> ebroder: The problem with dropping a file in sysctl.d from linux-image-* is that there is no dependency on procps
<bgamari> ebroder: Is it acceptable to carry a file in package A that has no use without package B, while there is no relationship between A and B
<ebroder> is there not a config flag or something to set the default swappiness?
<bgamari> let me check
<ebroder> hmm...looks like not. that might be a good resolution - come up with a CONFIG_SWAPPINESS or whatever, because that's easy to frob on a per-flavor basis
<bgamari> doesn't look like
<bgamari> it
<ebroder> and that might be upstreamable
<bgamari> definitely
<bgamari> I'll try working up a patch
<bgamari> ebroder: patch attached
<ebroder> bgamari: i'm not really qualified to pass judgement, but that looks reasonable to me
<ebroder> should CONFIG_DEFAULT_SWAPPINESS depend on CONFIG_SWAP or something like that?
<bgamari> probably
<ebroder> (i don't really have a good understanding of how kconfig works)
<bgamari> I'll fold that in and send it out as an RFC to see how repulsive the kernel folks find it
 * ebroder nods
<bgamari> I don't have great hope
<bgamari> but you never know
<maco> hi ben
<bgamari> by this logic, the kernel should expose all sysctl knobs in Kconfig
<bgamari> maco, hey!
<bgamari> long time
<maco> aye! get back down to dc for a visit! :P
<bgamari> heh, we'll see what happens
<bgamari> First I have to pass my quals up here
<bgamari> I probably shouldn't even be doing coding work at the moment
<bgamari> but a man can only take so much physics
 * sanchaz brb
<debfx> ScottK: what's blocking no-change backports? it's been over a month since you approved gcc-3.3 and virtualbox
#ubuntu-devel 2011-10-24
<pitti> Good morning
<pitti> SpamapS: I answered to 876959 yesterday
<micahg> http://packages.qa.debian.org/d/dpatch/news/20111024T000209Z.html \o/ dpatch  deprecated for new packages in Debian...
<StevenK> This is terrible news.
<micahg> StevenK: that's is deprecated or only for new pacakges?
<StevenK> No, that it is deprecated at all.
<StevenK> quilt can go DIALCF
 * micahg â¥ quilt
 * RAOF can get right behind StevenK's quilt hate.
 * micahg wonders why people hate quilt
<StevenK> quilt push -a ; quilt new ; edit file ; OHDAMNITIFORGOTQUILTADD
<pitti> for more extensive edits there is also quilt shell
<StevenK> I just want a patch system, not a VCS wannabe
<StevenK> And a buggy VCS wannabe, at that.
<micahg> StevenK: src format 3 FTW, just make your changes debuild -S, you have a patch :)
<StevenK> Ugh, format 3
<micahg> I love it, no more forgetting quilt add...
<RAOF> Although now you get to play the game of disentangle the multiple patches!
 * nigelb <3 quilt as well.
<nigelb> StevenK: Its even more awesome when you use quilt with UDD.
<nigelb> ;)
<nigelb> (that's the only quilt use case I absolutely hate)
<dholbach> good morning
<speakman> gmorning!
<speakman> Where can I find unity-2d-panel source? It's having problem adjusting it's width on multi monitor setups.
<speakman> (on launchpad that is)
<htorque_> hello everyone! i keep seeing problems reported with read-only file systems by users that followed some guides involving the recovery mode (as this seems to have changed in oneiric).
<htorque_> wouldn't it be more convenient to offer a 'read-only' menu item rather than making users first use 'remount' and then 'root'?
<geser> speakman: https://code.launchpad.net/~unity-2d-team/unity-2d/oneiric (project page is https://launchpad.net/unity-2d)
<speakman> geser: thx m8 :)
<speakman> (I'm about to post a bug report for this, but are there any tools to print the current resolution of each monitor attached?)
<speakman> Using Xinerama
<StevenK> Is there any magic I need for apt-cache to show long descriptions again?
<pitti> StevenK: it always did?
<cjwatson> no magic should be needed.  perhaps your mirror has failed to mirror the Translations-* files?
<StevenK> Oh
 * StevenK kicks apt-mirror
<cjwatson> debmirror works fine
<StevenK> I suspect I'm back to a postmirror script to wget the en translations
<cjwatson> StevenK: do please file a bug against apt-mirror about this, though
<StevenK> cjwatson: I got distracted by writing a suitable postmirror script, but will do
<StevenK> cjwatson: Already filed: https://bugs.launchpad.net/ubuntu/+source/apt-mirror/+bug/368419
<ubottu> Launchpad bug 368419 in apt-mirror (Ubuntu) "apt-mirror i18n files" [Wishlist,Won't fix]
<cjwatson> hmph
<StevenK> cjwatson: Exactly what I thought
 * cjwatson comments
<RAOF> speakman: xrandr --verbose
<speakman> RAOF: I'm on Xinerama so xrandr doesn't work. I used nvidia-settings GUI instead.
<OdyX> tkamppeter_ : any idea when openprinting.org will see life again ? (linuxfoundation.org/â¦/openprinting works though, so maybe just a matter of redirects)
<zyga> hi
<zyga> I'd like to report a bug but I'm not sure which component is responsible for this
<zyga> I cannot shut down my clean-install oneiric
<zyga> selecting shut down simply logs me out, selecting shut down from lightdm does nothing
<zyga> is it a lightdm bug?
<pitti> could be a lightdm or consolekit problem
<zyga> pitti, any clue on where to look, syslog has nothing while I try to shut down
<pitti> no idea, perhaps start with filing a bug against lightdm, to include /var/log/lightdm/lightdm.log
<pitti> that might have a clue
<pitti> also ~/.xsession-errors when you try to shutdown from your session
<zyga> pitti, thanks for the hint, I'll try to shut down now
<SpamapS> pitti: thanks
 * SpamapS should not be awake but stupid smoke alarms went off because their batteries had died
<SpamapS> http://people.canonical.com/~clint/bootchart.png .. anybody know what would cause check-new-relea to be run at boot time?
<SpamapS> I think its update-motd
<cjwatson> /etc/update-motd.d/91-release-upgrade -> /usr/lib/update-manager/release-upgrade-motd -> /usr/lib/update-manager/check-new-release
<OdyX> cyphermox: fyi, usb-modeswitch linked against libjim uploaded to Ubuntu. Tests and comments appreciatedâ¦
<OdyX> meh. s/Ubuntu/Debian/
<SpamapS> cjwatson: ahh thats why greps didn't work
<SpamapS> seems like we could delay a bit... its a rather busy command
<SpamapS> or am I reading the rather non-decipherable colors wrong and its a zombie most of the time? :-P
<pitti> SpamapS: certainly not; checking apt stuff during boot is ridiculously expensive
<pitti> (or anytime during login, really -- it causes VT logins to hang for a long time)
<pitti> at least they used to in the past, it took about 5 seconds for me
<SpamapS> pitti: all of update-motd feels like something that can wait until the first login.. or 5 minutes after first boot even.
<pitti> SpamapS: btw, red means "iowait", i. e. processes blocking on disk activity (usually waiting for data to read)
<SpamapS> pitti: "red" ?
<pitti> on rotary disks, the heavy apt stuff can block quite a bit
<SpamapS> I see only white
<pitti> SpamapS: on the bootcharts
<SpamapS> or blue
<pitti> I see a fair amount of red on your charts
<pitti> you don't seem to have an ureadahead cache
<SpamapS> dpkg-reconfigure ureadahead maybe?
<pitti> presumably this is from a boot right after you changed something in the boot sequence (perhaps you installed bootchart and this is the first boot after it?)
<pitti> or that :)
<SpamapS> no after 10 slow boots I got frustrated
<pitti> usually, after you do this, you boot to a desktop, wait for a minute, remove all old charts, and reboot again
<SpamapS> this is the third boot-chart measured boot
<SpamapS> but, seriously, no red
<SpamapS> its like we have a different pallete or something
<pitti> your CPU gets bored to death, the entire boot is one huge big red IOwait condition, and your HDD doesn't get to shovel more than some 5 MB/s into the RAM
<pitti> SpamapS: I'm looking at http://people.canonical.com/~clint/bootchart.png
<pitti> SpamapS: well, it's a relatively light red, more like pink
<SpamapS> yeah, I see pink, blue, white, no red
<SpamapS> the colors are fairly hard to distinguish from one another
<SpamapS> they mostly just look like shades of gray
<pitti> really? there are only four: white, black, blue (CPU), pink (IO wait)
<SpamapS> except the green ;)
<pitti> ah, right
<pitti> so your boot is entirely stuck on utterly slow data reading
<pitti> in theory ureadahead ought to help there quite a bit
<pitti> you have one or two peaks with 40 MB/s, but most of the time only a tiny fraction of that
<SpamapS> yeah I wonder why ureadahead hasn't been updated
<pitti> SpamapS: try a comparison with disabling that apt script?
<SpamapS> since 9/20!
<pitti> SpamapS: if it is, you should have /var/lib/ureadahead/*pack
<SpamapS> oh I hav eno packs, just debugfs
<SpamapS> hm
<pitti> SpamapS: do you have /etc/init/ureadahead.conf ?
<SpamapS> yes indeed
<pitti> hm, so perhaps it fails for some reason to write the pack files
<SpamapS> it was in fact running during bootchart
<pitti> SpamapS: http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100622-standard.png
<SpamapS> are we graphing bootchart somewhere btw?
<pitti> that's from my utterly slow latitude d430, its disk really sucked (20 MB/s)
<pitti> but even there ureadahead saved some 30 or 40 seconds
<SpamapS> I swear we do *way* too much manual testing
<pitti> SpamapS: yes
<pitti> http://reports.qa.ubuntu.com/reports/boot-speed/
<pitti> the beginnings of it, anyway
<SpamapS> cool
<SpamapS> I'm going to reboot with console output in /etc/init/ureadahead.conf
<SpamapS> I think you may be right that its not writing the pack files
<pitti> SpamapS: oh, how do you get the console output of a job?
<pitti> so far I kludged that with something like "exec 2>/tmp/log; set -x" in the pre/post-start scripts
<SpamapS> pitti: ctrl-alt-f7 ;)
<pitti> (to debug these particular parts)
<pitti> ah, ok; no magic cookie
<SpamapS> might end up in /var/log/boot.log too
<SpamapS> but thats hit or miss
<SpamapS> pitti: I think jhunt is working on a dmesg-like thing for job output buffers
 * SpamapS reboots...
<ogra_> hmm, is mom not working (or did we stop isung it) 8 merges for main doesnt look much
<Laney> ogra_: Think you clicked on the manual link :-)
<Laney> look above
<pitti> https://merges.ubuntu.com/main.html looks fine
<ogra_> Laney, lol, yeah, you are right
<ogra_> thanks !
<Laney> i did the same the other day
<cjwatson> and no we have not stopped using MoM
<ogra_> obviously ... as long as the user can read it even works as expected ;)
<SpamapS> pitti: ok, so I just realized I uninstalled/reinstalled bootchart between runs... i wonder if something it does during its install removes the pack files. They're there now
 * SpamapS needs to go back to sleep. Stupid smoke alarms
<pitti> SpamapS: yes, bootchart changes the boot sequence; the pack files are removed, triggered by changes to /etc/init
<SpamapS> pitti: thats what I thought.. so my first 2 were probably more accurate ;)
<pitti> cjwatson: do you have an opinion about bug 873401? should live-build not write a header to the md5sum.txt file, or can we fix gfxboot's checksum thingy (I don't know which package that is) to ignore the header?
<ubottu> Launchpad bug 873401 in live-build (Ubuntu) "Check disc for defects failed with a iso images built using ubuntu-defaults-image" [Low,Triaged] https://launchpad.net/bugs/873401
<cjwatson> the latter.  I'll deal with it
<cjwatson> and it has nothing to do with gfxboot :)
<pitti> I thought so, but for the lack of a better name :)
<pitti> what part does that, OOI?
<cjwatson> see the bug
<cjwatson> (reassigned and such)
<pitti> ah, casper, nice
<pitti> thanks
<leex> slangasek: I guess it was removed by upgrading to 11.10
<leex> slangasek: there should be some docu that states that fact, would have helped me a lot
<leex> slangasek: thanks for the info ;)
<cjwatson> it would have taken specialised gymnastics to have libc6:i386 installed before upgrading to 11.10
<cjwatson> the only people for whom that should have been true would have been people working on multiarch implementation, really
<oimon> tkamppeter: i wonder if you can help - i've been after a particular ppd file (pxl1010.ppd) since linuxprinting.org went offline - can you advise where i can get it?
<tkamppeter> oimon, this is in the source of foomatic-db. Do "apt-get source foomatic-db" and you find the XML files for it in /deb/source/.
<oimon> tkamppeter: excellent, many thanks :)
<tkamppeter> oimon, to build the Ubuntu package with it, edit db/source/driver/pxl1010.xml removing the "<obsolete ...>" line.
<oimon> cheers - any news on when the website is coming back btw?
<tkamppeter> oimon, every week they say "next week", on UDS I will look into getting another hoster ...
 * StevenK stares at apt.
<StevenK> W: Failed to fetch copy:/var/lib/apt/lists/partial/silver_ubuntu_dists_oneiric_main_i18n_Index  Encountered a section with no Package: header
<StevenK> I thought the index wasn't supposed to have any Package: headers ...
<cjwatson> kees: I'm stealing your jasper merge, per your comments of a few days ago that you weren't going to have time for a while
<cjwatson> StevenK: I bet you have an out-of-date apt from oneiric beta-1.  upgrade it
<StevenK> By hand, I guess
<cjwatson> no need for that
<cjwatson> apt-get update has updated enough stuff that you can 'apt-get install apt' now
<StevenK> And yeah, that chroot is a bit stale
<StevenK> cjwatson: Sorted, thanks.
<cjwatson> this is bug 871731 which we decided to accept
<ubottu> Launchpad bug 871731 in Release Notes for Ubuntu "Direct upgrades from beta-1 will produce annoying error message" [Undecided,Fix released] https://launchpad.net/bugs/871731
<cjwatson> you may remember it from LP conversation just pre-release :)
<kirkland> SpamapS: update-motd doesn't get run until login
<kirkland> SpamapS: should not affect boot time
<kirkland> Spads: something else must be running that apt-check
<soren> kirkland: I'm not sure that's true.
<soren> kirkland: Hang on.
<kirkland> soren: oh, hmm, actually
<soren> kirkland: The mounted-run job runs update-motd.
<kirkland> soren: ah, you're right ...
<speakman> My pulseaudio session daemon seems to stop sometimes (I think it's Flash doing something). How do I best turn on debugging of the daemon?
<speakman> (I've been running it in the foreground most of the day but of course nothing happens)
<tkamppeter> pitti, hi
<speakman> hm it just died. saying "Killed". wtf?
<cjwatson> that sounds like the out-of-memory killer got it; I bet you'll find something in /var/log/syslog and/or /var/log/kern.log
<cjwatson> (it's possible some other process was at fault)
 * cjwatson upgrades to precise
<cjwatson> WCPGW
<ogra_>  good luck :)
<nigelb> I'm surprised by brain interpreted WCPGW /very/ fast.
<nigelb> s/by/my/g
<cjwatson> apt-get did tell me that there were some ocaml-related uninstallables (which I'm working on clearing), but otherwise it seems OK at least at that level
<speakman> cjwatson: no debugging was enabled. Just changed that in /etc/pulse/daemon.conf. I'll watch syslog for error messages.
<cjwatson> OOM killer events will get logged by the kernel regardless of pulseaudio logging levels
<ogra_> you should find it in dmesg
<SpamapS> kirkland: something was running check-new-release early in the boot.. update-motd was thought to possible be it.
<SpamapS> possibly even :p
<cjwatson> SpamapS: do you think you could merge gdal?  it needs a rebuild for the libjpeg transition, and if it needs to be merged anyway ...
<SpamapS> cjwatson: sure, will merge it today.
<cjwatson> thanks!
<luist> heyâ¦ if im installing a symbolic link when building a package, will it get the real file to build?
<cjwatson> not quite sure what you mean, maybe an example would help
<speakman> are there any #ubuntu-pulseaudio sort of channel?
<luist> well in my debian/install i have:  myApp       usr/bin
<luist> but myApp is a sym link to where the executable really is
<cjwatson> where is that symlink created?
<cjwatson> and where is the real executable?
<stgraber> geser: ping
<doko> hmm, who did score up the powerpc builds?
<luist> cjwatson: its in the development folderâ¦ :P
<luist> cjwatson: on the same level, but diff folder
<cjwatson> luist: sorry, I don't think that answers my question.  Perhaps you could put the whole source package somewhere?
<cjwatson> doko: me - trying to get some multi-level transitions done and it's easier if all architectures keep up
<cjwatson> doko: what's the problem?
<luist> cjwatson: i dont see whats so hard to understandâ¦ im putting a symbolic link in the install list and i want to know if its gona pack a broken link or the real file
<cjwatson> luist: there are a couple of different things you might mean and I need specifics.  Please can I see the whole source package?
<cjwatson> I don't have time to guess
<doko> cjwatson, hmm, I did rescore openjdk-6 for the security update
<cjwatson> (answered doko in /msg)
<cjwatson> luist: you see, the answer depends on things like whether the symlink is absolute or relative, and whether it's statically present in the tarball, created in a Makefile or similar, or created with dh_link
<cjwatson> luist: and on whether the real path to the executable is installed in the package
<cjwatson> luist: this kind of thing is much easier to tell without lots of going back and forth by just looking at a source package, if that's at all possible
<Daviey> doko: Did you have any comments about the php5 debian package you merged?
<smoser> slangasek, i'd be interested in your feedback on https://code.launchpad.net/~smoser/ubuntu/oneiric/isc-dhcp/lp857524/+merge/76791 . cjwatson would also be nice as i know you've touched that package (i think for installer primarily).
<cjwatson> smoser: I agree with Marc; there's no reason not to update this file atomically
<cjwatson> please refactor the patch to do so (it sounds like that's what the code did originally)
<smoser> cjwatson, actually i dont think you can accomplish that
<smoser> with read-only /etc/
<cjwatson> I don't care how narrow a race condition is; it's either there or it isn't.  Actually a narrow one is worse than a wide one.
<cjwatson> if /etc is read-only then you can't write to /etc/resolv.conf either
<smoser> ah, yeah, i just have to find the  target of the link if its a link
<smoser> and put the temp file on *that* filesystem
<cjwatson> if /etc/resolv.conf is a symlink to somewhere writable, then update it atomically there
<cjwatson> right
<mdeslaur> smoser: you could follow the symlink and create the tempfile wherever the real resolv.conf turns out to be located
<mdeslaur> heh
<smoser> anyone else want to repeat ?
<smoser> :)
<cjwatson> narrow worse than wide> because it's harder to debug
<mdeslaur> smoser: I'm not afraid of a write race, I'm more afraid of a read race while the address is being renewed
<smoser> mdeslaur, well that'd take a lockfile via some mechanism to address, right?
<cjwatson> yup, and that would be absolute hell to debug, so let's not doom our successors to that
<cjwatson> no, mv into place is enough
<cjwatson> prevents reading an incomplete resolv.conf
<smoser> cjwatson, i didn't understand "narrow worse than wide>"
<cjwatson> 16:13 <cjwatson> I don't care how narrow a race condition is; it's either there or it isn't.  Actually a narrow one is worse than a wide one.
<smoser> oh. regarding the race.
<smoser> cjwatson, quick question.
<smoser> in the case where there is no /etc/resolv.conf, the old chown / chmod would fail.
<smoser> should i explicitly set root:root 644 on it then ?
<smoser> or let the normal umask/uid/gid of this script be used.
<cjwatson> I'm not sure.  Does the normal umask/uid/gid produce the right answer?
<smoser> well this would be running as root, called through ifup
<smoser> so i assume uid:gid is right
<cjwatson> smoser: if it produces the right answer then I think I would be happy to just use the defaults
<smoser> cjwatson, test here shows root:root 644.
<smoser> so we'll go with that.
<cjwatson> ok
<leex> hi, since you guys have been helpful yesterday, I would like to be helped again ;) when I boot I am dropped a non functional root shell instead of starting slim,xdm,gdm or ... I can switch to a different tty and just startx as a workaround, but I would like to get slim working again ;) the only thing that went wrong, judging from the syslog is [   18.189682] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro. Does anyone have an idea where to sta
<Daviey> infinity: *poke* bug 759545 .. if you have an idea of how to resolve this, i'd be most appreciative of a fix for alpha 1 :)
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<leex> ubottu: thanks, I will study it, brb
<ubottu> leex: I am only a bot, please don't think I'm intelligent :)
<infinity> Daviey: That gives me a month and a bit to ponder it?  I'm okay with that schedule. :P
<leex> ah, that wasn't related to me ;)
<smoser> infinity, regarding the grub2 bug above, i'd really appreciate it if you could also address the general need for local modification to /etc/default/grub
<smoser> right now, the cloud-images modify that file for good reason, and set:
<smoser>   GRUB_CMDLINE_LINUX_DEFAULT=console=ttyS0
<smoser> also we modify GRUB_HIDDEN_TIMEOUT_QUIET, GRUB_TERMINAL, GRUB_TIMEOUT
<leex> some additional information: running 11.10, fsck done didnt help
<slangasek> smoser: I defer to cjwatson, he seems to have the bases covered
<smoser> agreed.
<leex> http://paste.ubuntu.com/718018/ that's my dmesg output
 * ogra_ glares at http://qa.ubuntuwire.org/ftbfs/ and wonders why it thinks evas and ecore are parts of ubuntu-desktop
<cjwatson> They're in the ubuntu-desktop package set in precise.  I'm not sure why or who put them there (wasn't me).
<ogra_> ah, i only checked for the task in the package description in oneiric
 * ogra_ isnt really up to speed with precise yet
<ogra_> i just found it weird to have them in a supported set
<cjwatson> Quite.  I'll see what happens when I run the script to sync up with seeds.
<micahg> cjwatson: would you mind if I did an audit of the various package sets at some point this cycle? some stuff does look out of place?
<cjwatson> micahg: not at all although I don't promise to change anything ;-)
<micahg> heh, ok
<cjwatson> autogeneration is what makes them manageable at all
<micahg> cjwatson: so, core, and the CD related sets are only autogenerated?
<cjwatson> yes
<micahg> ok, that will make this interesting then :), maybe there's a bug somewhere
<cjwatson> there's a small exception list for moving things out of "more privileged" sets when e.g. the desktop team actually functionally maintains things in core
<cjwatson> but I don't want to take it further than that
<cjwatson> ogra_: should be fixed next time it updates
<ogra_> it seems to also generate unr and netbook atm
<ogra_> cjwatson, great
<ogra_> i assume the two above will vanish as well then
<micahg> cjwatson: makes sense, but when I see universe stuff in core, I start to wonder, I will do some digging at some point
<cjwatson> micahg: that was a bug and should be gone now.
<micahg> cjwatson: excellent, thank you
<cjwatson> I'm not quite sure what happened, possibly a Launchpad bug on initialising the distroseries, but I can't quite tell at this point since there's little auditing.  I've made a mental note to check this out when Q opens to see if the same thing happens
<cjwatson> It's not too big a deal since I always blat over it with an autogenerated list at some point anyway.
<cjwatson> ogra_: unr and netbook - no idea
<cjwatson> I'll go and have a look
<ogra_> both  should be officially gone
<ogra_> though i'm not sure anyone ever deleted the seed branches from the respective seeds
<micahg> cjwatson: the other puzzling thing was something like awstats in core which seems like it should be in the server packageset, any ideas about that? (no rdepends)?
<cjwatson> it seems to have copied some from much older series, which is odd
<cjwatson> micahg: check germinate output
<micahg> cjwatson: ok, thanks
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/awstats - seeded
<cjwatson> my guess as to what's happened here is that LP has made precise packagesets be the union of those in all previous series, rather than the immediately previous one
<micahg> ah, that seems bad
<cjwatson> but I've run out of time to investigate this right now and it's not super-urgent
<Riddell> ogra_: could you renew my membership of canonical-arm-dev?
<ogra_> sure, one sec
<micahg> cjwatson: ok, if I get time, I"ll dig more and file bugs as appropriate (probably not until after UDS)
<ogra_> Riddell, you got one more year :)
<Riddell> thanks ogra, I shall savour every day of it
<leex> Can anyone confirm that there is no /etc/inittab on ubuntu 11.10?
<Riddell> leex: yes
<leex> Riddell: thanks
<leex> Riddell: still searching for my strange "dropped to root shell after boot"-bug
<slangasek> dropped to a root shell, or dropped to a login prompt?
<leex> slangasek: dropped to a login prompt would be ok ;)
<slangasek> I'm asking which happens
<leex> slim just stopped working, and I get a root shell instead
<leex> [   14.546502] init: failsafe main process (796) killed by TERM signal ... [   14.588677] init: lightdm main process (1053) killed by TERM signal
<leex> http://paste.ubuntu.com/718075 that's the whole dmesg
<slangasek> the only cases in the 11.10 boot sequence that will give you a root shell are 1) booting in recovery mode (booting with 'recovery' on the kernel commandline), 2) booting with 'S' as the runlevel target, 3) a critical failure in mountall causing it to drop to a root shell for you to fix your filesystem
<slangasek> do you know if any of these apply to your case?
<leex> slangasek: I did a shutdown -rF now, before comming here
<leex> slangasek: I did not select recovery mode
<leex> slangasek: how can I check for the runlevel target?
<slangasek> the runlevel target would also be on the kernel commandline (normally) - since your dmesg doesn't show that, it's probably not runlevel S either
<slangasek> however, this dmesg shows processes being killed by SIGTEMR
<slangasek> SIGTERM
<slangasek> that's not at all normal
<slangasek> did you use SysRq to kill the jobs?
<leex> slangasek: y
<leex> slangasek: no
<slangasek> ok
<leex> slangasek: I just enter my luks password, nothing else
<leex> I justed upgraded from 11.04 recently, but that's a week ago. and I havent had the issue til today
<leex> should I file a bug report?
<slangasek> you might want to check if you have any modified files under /etc/init or /etc/init.d, or anything in either of those directories not belonging to a package; or if you have put anything unusual in /etc/rc.local.  This doesn't look like an Ubuntu bug, it looks like something has run amok in your startup sequence and is killing off processes
<leex> hmm, I will check, have to leave office now though. I will have a look at and tell you lator
 * ogra_ sees gdm in the dmesg output
<leex> but I didn't touch any of these files by hand
<ogra_> how did you do your upgrade from 11.04 exactly ?
<slangasek> ogra_: the upgrade from 11.04 is expected to leave gdm installed, and that's not the bug
<leex> ogra_: upgrade manager
<infinity> I have a hard time seeing this as an upgrade bug anyway.  Worked fine for a bit, exploded today.  And, seriously, what runs amok and kills everything, including rc?
<leex> infinity: ack
<infinity> My kingdom for sane init logs.
<slangasek> infinity: define? :)
<slangasek> infinity: better yet, define in Orlando :)
<infinity> slangasek: Can I just hand-wavingly say "something a lot more verbose than his dmesg output that would tell me WTF happened there"? :)
<slangasek> infinity: you can, but that's not actionable :)
<slangasek> we do have working /var/log/boot.log
<infinity> With nothing else to blame, I'd guess sendsigs is being run in runlevel 2.
<infinity> Which would be... Special.
<slangasek> and you can boot with --verbose
<ogra_> slangasek, ah, i wasnt aware it leaves gdm in place
<slangasek> infinity: right, also notice the gap in timing of the SIGTERMs... one batch at 17s after boot, another at 39s after boot
<slangasek> thigns are getting killed *twice*
<slangasek> maybe sendsigs is in both /etc/rcS.d and /etc/rc2.d :P
<slangasek> leex: ^^ make sure there are no symlinks to /etc/init.d/sendsigs in either of these directories, please
<leex> have to go home now, but if you have an idea on how to track this bug, please let me know. btw here is my boot.log http://paste.ubuntu.com/718082
<infinity> slangasek: Though, that still wouldn't do anything bad.  sensigs start is a no-op.
<leex> slangasek: I will do, back in about an hour
<slangasek> in any event, sendsigs is *not* supposed to kill anything that's attached to an upstart job
<slangasek> infinity: it could be a K link?
<infinity> That would be even more special. ;)
<slangasek> this whole scenario is unambiguously special
<infinity> If this proves to be an upgrade bug, I think we're getting ever closer to discovering the long-sought-after secret to punching people in the face over the internet.
<slangasek> leex: fwiw, your boot.log shows that your system *is* entering single-user mode, *after* having started runlevel 2: "* Starting System V single-user mode compatibility"
<slangasek> infinity: see? we have logs
<slangasek> we just need to line wrap them properly
<infinity> slangasek: Oh, I may have missed the bit where a log was provided. :)
<slangasek> infinity: it was provided after you asked :)
<infinity> Also, I can't read.
<slangasek> leex: this message comes from /etc/init.d/single, which is somehow being invoked.  Up to line 60 of your paste, everything appears to be correctly starting runlevel 2, then all of a sudden, with no indication of runlevel change, /etc/init.d/single has been called.  I suspect there's a wrong link to this script in /etc/rc2.d.
<infinity> Indeed.
 * infinity wonders if one of the many "user-friendly" rc editors is to blame.
<infinity> Or something.
<infinity> leex: For the record, on a stock install you should see this:
<infinity> adconrad@cthulhu:~$ ls /etc/rc?.d/???single
<infinity> /etc/rc1.d/S90single
<infinity> (And no other links)
<superm1> Daviey, if it's got my fixes, yeah that sounds good
 * Daviey tries to remember context
<superm1> Daviey, python mysqldb
<Daviey> ah!
<Daviey> superm1: Are you handling the sync?
<superm1> Daviey, you can go ahead if you'd like
 * Daviey tries the whizzy webui
<superm1> I don't have a precise schroot set up yet, and don't plan on getting to that until after UDS probably
<leex> re ;) reading backlog
<Daviey> seems the option has been disabled.
<Daviey> gah
<leex> infinity: sysv-rc-config
<leex> infinity and slangasek how to figure out what's wrong?
<slangasek> leex: covered in scrollback - having any links to 'single' outside of /etc/rc1.d is wrong
<leex> lrwxrwxrwx 1 root root 16 2011-10-20 14:16 S90single -> ../init.d/single*
<leex> :D
<leex> in rc2.d
<leex> slangasek: can I just remove that?
<slangasek> sysv-rc-config isn't a package in the archive.  Where did you get it... and why did you think to run it on your systeM?
<slangasek> leex: yes, you can and *must* remove it
<slangasek> oh, it's called sysv-rc-conf, maybe
<leex> sry, sysv-rc-conf
<leex> slangasek: will restart and check whether it is ok
<slangasek> leex: in the future, when asking why your system doesn't boot, "I ran a runlevel editor recently" would be pertinent information to mention ;)
<smoser> cjwatson, please re-review https://code.launchpad.net/~smoser/ubuntu/oneiric/isc-dhcp/lp857524/+merge/76791 . it uses tmpfile and move now.
<smoser> generally, what is the right way to do ask such a thing? am i supposed to hit 'requeest another review' ?
<leex> slangasek: I am sorry :/ I forgot about it, I know that it would have been good to tell you.
<leex> oh yeah it fixed it
<slangasek> :)
<slangasek> hallyn: fwiw, bug #880996 is a duplicate... yes, qemu-system-ppc doesn't work, we know
<ubottu> Launchpad bug 773031 in qemu-linaro (Ubuntu) "duplicate for #880996 openbios for sparc and ppc still missing for 11.04" [Undecided,Confirmed] https://launchpad.net/bugs/773031
<leex> I will note not to use sysv-rc-conf again :)
<hallyn> slangasek, sorry, i should've looked for a dup
<leex> slangasek: any recommendations for a rc editor?
<slangasek> hallyn: no worries
<hallyn> slangasek, i still was wondering if he was actually trying to boot a ppc .img with qemu-kvm
<slangasek> leex: I'm afraid not.  The last I looked, none of them presented a very good interface
<leex> slangasek: ok, then I will read some tut on how to edit them by hand ;)
<leex> slangasek: fixed the slim rc config and anything is back to normal
<leex> yeah, thanks everyone for helping me!
<slangasek> YokoZar: so, ia32-libs is out of the picture now.  any thoughts on how to split the 32/64-bit parts of wine to be installable for 12.04 without use of biarch?
<infinity> slangasek: wine1.x = metapackage that depends on wine1.x-32 on i386 and wine1.x-32 & wine1.x-64 on amd64, ship wine1.x-32 only on i386, done?
<infinity> (And make wine1.x-64 depend on wine1.x-32, for people who blatantly avoid the metapackage, since I suspect 64 would actually need 32 to be fully useful, though I'm not sure)
<slangasek> infinity: does that mean you're volunteering to do the conversion? ;)
<infinity> slangasek: It really doesn't.
<infinity> slangasek: I know somewhere between nothing and very little about wine, see the part where I'm not even sure if wine64 needs wine32 to function (though, I'd guess it does, based on what I know about win64 and win32).
<infinity> Well, s/function/function usefully/
<jcastro> pitti: ok you should be seeing a schedule update now
<killown> What does the unity developers thinks that the "show desktop icon"  isn't  usefull?
<killown> Very annoying shortcut key ctrl+alt+d ...
<Quintasan> tumbleweed: GZ
<tumbleweed> Quintasan: eh?
<Quintasan> Aren't you on DMB tumbleweed?
<dobey> hrmm, no patch pilot?
 * dobey wonders who to bug for sponsoring, with some people already in/headedfor orlando
<tumbleweed> Quintasan: as of very recently, yes :)
<tumbleweed> Quintasan: thanks :)
<LaserJock> cjwatson: awesome blog post! I love the +1 maintenance team idea
<Quintasan> You're welcome. :-)
<YokoZar> slangasek: Yes, there's a whole procedure to go through on Wine's wiki.  I'll take care of it.
<YokoZar> Also what infinity said
<barry> tumbleweed: how did i miss the fix for syncpackage? ;)  has it landed already and i missed it?  was there an open bug and i missed it?  in any event, glad you fixes those issues
<tumbleweed> barry: it's in unapproved since this morning
<tumbleweed> we were waiting for the previous SRU to be approved first
<barry> tumbleweed: just curious, was it my bug report that triggered your fix, or was this another case of ships crossing in the night?
<tumbleweed> I'd already fixed it in trunk a week or two ago
<tumbleweed> then slangasek ran into it again on the weekend and I prepared an SRU, but it was blocked until this morning
<barry> tumbleweed: cool.  i must have looked at the wrong branch.  yay tho!
<barry> (i did search the bug tracker but didn't find anything)
<tumbleweed> the bugs live in the ubuntu source package, and the code in the lp project
<tumbleweed> IIRC the discussion about it happened on -release. But u-d-t discussion also often happens in -motu
<barry> tumbleweed: cool.  i wasn't around much this weekend.  i did look in the source package bugs, but i looked in the source package branch too, which is how i missed it
<barry> tumbleweed: no worries.  glad it'll be fixed.
<tumbleweed> :)
<kees> cjwatson: cool, have at it
<barry> tumbleweed: i see the debdiff attached to the dup'd bug.  note that my patch also fixed the printing of the url that 404'd, but i don't see that in the debdiff.  you might want to consider that too, as what's currently printed isn't much help in figuring out what went wrong (e.g. you're misled to think that packages.debian.org is offline)
<tumbleweed> barry: true, although this is a known issue if you are familiar with requestsync
<tumbleweed> I'll apply that to trunk
<barry> thx
<slangasek> YokoZar: hmm, where's wine's wiki and where is this page, OOI?
<cjwatson> smoser: done
<cjwatson> LaserJock: thanks :)
<YokoZar> slangasek: http://wiki.winehq.org/Wine64ForPackagers
<RAOF> YokoZar: Does that mean that we'll likely be having a WoW64 wine build on amd64 in Precise?  Cool!
<YokoZar> RAOF: yeah, it's something I've been putting off until after multiarch
<RAOF> Sweet.
<slangasek> ah, do we currently not have any win64 support at all?
<slangasek> perhaps I misunderstood the state of the art
<broder> WoW64 is 32-on-64, right?
<YokoZar> slangasek: Right, we don't build Wine in 64 bit mode at the moment.  It's straight forward to make a 64 bit only Wine, but it's fairly useless.
 * slangasek nods
<YokoZar> broder: Yes, a bit confusingly named
<YokoZar> broder: even more confusingly is that the windows "system64" folder actually contains the 32 bit dlls I think
<broder> YokoZar: yeah, that's how i remembered it working, too
<SpamapS> woot, MBA has graphics .. but.. touchpad broken now. DOH
#ubuntu-devel 2011-10-25
<RAOF> SpamapS: With linux 3.1?
<SpamapS> RAOF: been following this https://help.ubuntu.com/community/MacBookAir4-2
<SpamapS> RAOF: not sure which magical thing it did to enable the graphics, but it disabled the touchpad :(
<SpamapS> ahh
<SpamapS> it patched bcm5974 for the 4,2
<SpamapS> but the 4,1 only seems to work with the regular 3.0.0-12-generic version
<SpamapS> all is well now
 * SpamapS does a dance
<SpamapS> XRANDR .. [check]
<SpamapS> ooo suspend/resume even works
 * SpamapS can actually consider *not* lugging his 15" MBP to UDS now
<SpamapS> w00t
<RAOF> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: RAOF
<RAOF> Bah.  It's really annoying that I can't change the status on any of these merge proposals.
<micahg> RAOF: you need a tech board member most likely
<RAOF> Yeah, I know.
<broder> it's unfortunate that nobody actively working on udd is on ~ubuntu-branches
<RAOF> Or to be a member of ubuntu-branches.
<broder> otherwise i would advocate the "harass them until they fix it" approach
<RAOF> James Westby's in ~ubuntu-branches :)
<broder> i thought he was doing linaro stuff these dyas
<RAOF> Oh, yeah.  He is, isn't he.  Damn!
<ajmitch> that would make things a bit awkward
<ajmitch> maybe the TB should be asked to look at the ownership of those branches
<stgraber> RAOF: either poke me with the changes you want or make a list in your e-mail to ubuntu-devel (assuming you'll send one at the end of your shift)
<RAOF> stgraber: Ta. I'll be sure to list them all in an email then.
<smoser> how do i force debuild to create a .dsc that references the .orig file ?
<micahg> smoser: -S -sa
<smoser> thank you, kind sir.
<micahg> you're welcome
<wgrant> RAOF/micahg: Or escalate the bug.
<RAOF> wgrant: Know what that bug is, offhand?
<lifeless> broder: james_w is in online services now
<wgrant> lifeless: Wha?
<wgrant> When did that happen?
<lifeless> danilo -> linaro
<lifeless> james_w -> jml's offsider
<wgrant> Ah, interesting.
<wgrant> Makes sense, though :)
<wgrant> RAOF: Bug #540250 looks relevant, but is meant to be fixed...
<ubottu> Launchpad bug 540250 in Launchpad itself "Cannot edit merge proposals for packaging branches" [High,Fix released] https://launchpad.net/bugs/540250
<wgrant> Ahh.
<wgrant> Now I remember.
<wgrant> RAOF: What's an example merge proposal?
<wgrant> Is it for a stable series?
<RAOF> wgrant: Yes, I think they are.
<RAOF>  is ahttps://code.launchpad.net/~om26er/ubuntu/natty/libdbusmenu/dbusmenu-fix-618587/+merge/71892n is an example.
<wgrant> Right.
<wgrant> That would be the problem.
<wgrant> MP edit access is delegated to people with edit access on the branch. And upload permissions don't grant branch write access to stable series.
<wgrant> Because those branches are meant to be frozen.
<wgrant> I'm not sure if there is a bug for this...
<RAOF> Aha.
<micahg> smoser: you also want to use -vOLD_UBUNTU_VERSION when merging from Debian
<wgrant> Bug #612391
<ubottu> Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391
<wgrant> If you can escalate that, it might get done :)
<smoser> micahg, thanks... too late though. i should have know that.
<micahg> smoser: I try to remember to check the source.changes file to make sure the other entries are there before uploading
<RAOF> wgrant: Sweet, thanks for that.
<slangasek> YokoZar: multiarching -dev packages> that's not relevant, you don't get to build-depend on packages other than those for the current arch...
<YokoZar> slangasek: Err yeah you're right, multiarch is the solution that works around that problem
<YokoZar> slangasek: cause we build the 32-bit bits on 32 that have the 32 bit dev packages
<slangasek> yep - at least, I hope it works around it :)
<YokoZar> slangasek: do you know the status of OpenCL by chance?
<RAOF> Just as long as the WoW64 stuff can use the 32bit build :)
<YokoZar> RAOF: Yup.  I may have to do some weird copying in the package build script though, as we (unusually) want some files to be part of multiple packages here
<YokoZar> RAOF: namely in the 32 bit package as well as the 32 bit foreign package
<slangasek> the 32-bit package is not a different package than the 32-bit foreign package
<slangasek> it's one package, built on i386 and installable on either i386 or amd64
<YokoZar> slangasek: actually nevermind, that's the proper way to do it, have the 32 bit-only package depend on that too
<slangasek> yep
<slangasek> YokoZar: I don't think I know what opencl is
<YokoZar> slangasek: It's the library for getting the graphics cards to do GPU tasks without actually being 3d rendering, if I remember right
<slangasek> YokoZar: ok; not my department :)
<micahg> slangasek: I thought that the amd64 buildds could use 32 bit packages, is that not correct?
<YokoZar> Current Linux implementations may be driver specific (eg, only in the proprietary NVidia packages...despite the openness)
<slangasek> micahg: nope
<YokoZar> micahg: You can depend on a package that only has a 32 bit component, but you can't build-depend on that.
<slangasek> micahg: there's no way to specify it in build-deps, for starters
<micahg> slangasek: so how does one build a 64 bit app that has some 32 bit components?
<YokoZar> micahg: The rationale for this that made the most sense when I was learning it to just imagine that each architecture has to be built separately and independently.  So things like cross-arch build-deps don't work, while binary dependencies do (unless your package itself is a reverse depends...)
 * micahg thought wine was like that
<slangasek> micahg: if it requires anything beyond the compiler and libc to build the 32-bit stuff, it should be done as an i386 package and use multiarch to install it
<micahg> ok
<YokoZar> micahg: This is why we're discussing Wine, as it needs some unusual splitting to make 64/32 mode work on 64.  The executive summary is the 32-bit parts are being built on 32.
<YokoZar> whereas in oneiric they're built on 64 via ia32-libs
<RAOF> YokoZar: What are you particularly interested in re: OpenCL?
<micahg> I guess that makes sense, someone had a question a few weeks ago about pbuilder using the amd64 and i386 sources, I guess I gave the wrong answer (I thought that was normal for oneiric)
<YokoZar> RAOF: Wine already has an implementation of it so any Windows app that uses it would need it to work
<YokoZar> RAOF: I'm not sure what Windows apps use OpenCL off the top of my head though
<RAOF> YokoZar: Ah, ok.  Currently there's no real solid open implementation standardised, which means there's no standard way to depend on it.  In the P+1 timeframe I'd expect us to have an open implementation, possibly even in precise.
<YokoZar> RAOF: Well, I hope I can speed things along by being your use case then ;)
<RAOF> Hm.  There doesn't seem to be a Khronos ABI for OpenCL.  Fundamentally it's likely that you'll end up wanting to Depend: or Recommend: libcl1 or somesuch.
<pitti> Good morning
<pitti> jcastro: right now it says "error updating", but will try later
<ajmitch> morning pitti
<pitti> hey ajmitch, how are you?
<ajmitch> good, how are you?
<pitti> pretty well, although still a bit tired, thanks!
 * ajmitch wishes that the long weekend here was a few days longer :)
<RAOF> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> doko_: FYI, keeping binutils in proposed queue, as the previous SRU hasn't been verified yet
<pitti> doko_: if you want the second upload in -proposed now, please reupload with -v to include the previous changelog
<pitti> slangasek: how did you build samba? http://launchpadlibrarian.net/83357418/samba_3.5.11~dfsg-1ubuntu2.1_source.changes doesn't have a Launchpad-Bugs-Fixed: header
<micahg> pitti: FYI, bug 881250, SRU period might need to be truncated
<ubottu> Launchpad bug 881250 in tzdata (Ubuntu) "Clocks in Ukraine move back October 30, 2011" [High,Triaged] https://launchpad.net/bugs/881250
<pitti> micahg: yes, we generall move them to -updates right after verification, as they often tend to be urgent
<pitti> there's a tzdata 2011m already
<micahg> right, already in unstable
<tkamppeter> pitti, are you not on the Sprint?
<pitti> tkamppeter: no, I'll arrive on the weekend; only for UDS
<tkamppeter> pitti, interesting, as technical lead of the desktop team.
<dholbach> good morning! :)
<pitti> tkamppeter: it's a DX sprint
<pitti> tkamppeter: seb128 and didrocks are there
<tkamppeter> pitti, OK, thought it was an all-Canonical Sprint.
<tkamppeter> pitti, good to know to know who is in which time zone currently.
<cjwatson> wgrant: I'm pretty sure it's not just that bug.  During the Oneiric release cycle, well after that bug was fixed, developers were unable to reject MPs for Oneiric branches.
<wgrant> cjwatson: That's worrying. If you can find a current example, I would love to see it.
<cjwatson> wgrant: Try bug 728012 instead.
<ubottu> Launchpad bug 728012 in Launchpad itself "ubuntu developers are not able to reject merge proposals on official packaging branches they can upload to" [High,Triaged] https://launchpad.net/bugs/728012
<micahg> cjwatson: he later added Bug #612391
<ubottu> Launchpad bug 612391 in Launchpad itself "Cannot change status for merge proposals that target a released series" [High,Triaged] https://launchpad.net/bugs/612391
<wgrant> Let's see.
<cjwatson> micahg: Indeed, but AFAIK this still happens for development series.
<micahg> ah
<cjwatson> wgrant: Unfortunately I have sufficient privilege that it's hard for me to hunt out an example myself, but I guess anything for precise on the sponsoring list should do it.
<wgrant> The problem here is probably that upload permissions don't grant review privileges.
<wgrant> And there's no review team set.
<wgrant> So only ~ubuntu-branches has those superpowers... hm.
<micahg> wgrant: here's an example: https://code.launchpad.net/~samuel-taylor/ubuntu/oneiric/pidgin-skype/fix-for-657125/+merge/75701
<cjwatson> I think we'd like it to be keyed off upload permissions rather than setting a single team.
<cjwatson> micahg: that's a released series
<wgrant> cjwatson: Indeed.
<micahg> I don't think I could've changed it before eitehr
<wgrant> It currently checks for membership in one of (branch owner, branch reviewer, LP admin).
<wgrant> Which made sense until package branches.
<wgrant> Because branch editing was restricted to the branch owner and LP admins.
<jamespage> does anyone know if there is a tool already in main that will convert markdown to html?
<wgrant> So isPersonTrustedReviewer should probably just check if they can edit the branch or are in the review team.
<micahg> I can change this one: https://code.launchpad.net/~barry/ubuntu/precise/ubuntu-dev-tools/bug-881049/+merge/80253
<ubottu> Launchpad bug 80253 in debconf (Ubuntu) "Can't launch ubiquity on 20070117 feisty-desktop-i386.iso" [Undecided,Fix released]
<wgrant> micahg: To Approved/Rejected?
<tumbleweed> jamespage: python-docutils
<micahg> wgrant: no, but I don't think I can ever set those
<wgrant> Right, that's the bug.
<cjwatson> micahg: I can; that's the bug.
<jamespage> tumbleweed: sweet - thanks for the pointer
<micahg> cjwatson: wgrant: sorry for the noise
<cjwatson> that's ok
<cjwatson> man, switching from homegrown scripts to pull-lp-source and pull-debian-source has improved my life surprisingly much
<pitti> I find them quite nice, saves having tons of deb-src lines
<pitti> s/saves/avoids/
<pitti> jcastro: guidebook seems better now, thanks!
<jamespage> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
 * dholbach hugs jamespage
<\sh> doko_, do you mind when I take some of the  universe packages (from MoM) with your last uploader  name tag?
<jamespage> why can I 'Reject' some merge proposal but not others?
 * jamespage scratches his head
<lifeless> jamespage: natty / not-natty
<lifeless> jamespage: there is a bug.
<doko_> \sh, not at all
<doko> pitti, can we move the first one to -updates first?
<pitti> doko: that's what happens by default if you don't want to replace the current SRU, yes
<pitti> (still needs verification, as I said)
<\sh> doko, thx
<\sh> btw...are there any hints on how to fix format-security issues?
<doko> pitti, done the verification
<pitti> \sh: usually it's from something like printf(variable), i. e. handing a non-constant string to a function which evaluates % format codes
<pitti> \sh: a common pattern is to prepend a "%s", if you really don't want interpolation
<\sh> pitti: I just saw this error inside
<\sh> pitti: I just saw this error inside a function which is using gtk_message_dialog_new
<\sh> and I'm not sure if gtk_message_dialog_new(...,...,...,...,"%s",message) is enough
<pitti> \sh: using "%s" for the message will work fine
<pitti> \sh: as I said, it depends: if message is _supposed_ to have format strings in it, then this will break
<pitti> but if it's not, then "%s" is fine; then any % characters in message will appear verbatim
<\sh> pitti, kk :) thx :)
<Daviey> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<Daviey> bug 881361, impact not yet determined.  Non-default package.
<ubottu> Launchpad bug 881361 in puppet (Ubuntu Precise) "puppetmaster-passenger fails to install with puppet 2.6.4-2ubuntu2.5" [High,Confirmed] https://launchpad.net/bugs/881361
<Riddell> jasoncwarner_: can you approve the desktop-p-kubuntu specs for uds-p please https://blueprints.launchpad.net/sprints/uds-p?searchtext=kubuntu
<jamespage> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jdstrand> Daviey: mdeslaur is looking into it now
<Daviey> jdstrand: yep, tracking in #ubuntu-server. Thanks.
<mterry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<sabdfl> hello folks
<ogra_> hey sabdfl
<pitti> hey sabdfl, how are you?
<sabdfl> great thanks pitti, enjoying orlando already :-)
<pitti> sabdfl: twisting^Wsprinting by the pool âª â« ?
<ogra_> pitti, grrr, you implanted an earworm !
<ogra_> :)
<ion> Not to me.
 * ogra_ guesses thats a matter of age :)
<ogra_> or of musical taste
<mdeslaur> pitti: it seems linux-ec2, linux-mvl-dove and linux-fsl-imx51 on lucid got binaries demoted to universe...was that intentional, or a script error?
<mdeslaur> pitti: I got them moved now, but want to make sure it's not a script issue
<GunnarHj> pitti: are you there?
<jamespage> doko: OK if I pickup the jffi merge? its borked at the moment in precise
<doko> jamespage, sure
<jamespage> doko: ta
<psusi> do I have to register for UDS if I'm not staying in the hotel ( I live nearby ), or can I just drop by?
<ogra_> psusi, you should register in LP, so people know you are there and can i.e. subscribe you to sessions they want you to attend etc
<ogra_> its not about the hotel, but about the automatic scheduler that needs to know you are there
<psusi> ok
<ogra_> 8unless you just want to hang out in corridors indeed :) )
<jcastro> psusi: please register in LP, that's how they figure out the food and stuff
<ogra_> oh, food, right :)
 * ogra_ forgot about that unimportant bit
<psusi> hehe.... I'm not sure how much time I can get away from work to get over there, but I definately want to do some meet and greet as long as everyone's in town
<jcastro> that would be awesome
<RoAkSoAx> is merges.u.c no longer been updated?
<jbicha> I was surprised at my first UDS that lunch was included for all attendees, free OS and free food? sweet!
<tumbleweed> RoAkSoAx: it should be. Don't forget we're syncing from testing
<cjwatson> it's running right now, indeed
<cjwatson> looks healthy to me
<RoAkSoAx> tumbleweed: ahh right!!
<RoAkSoAx> thought we were from unstable
<tumbleweed> cjwatson: any opinions on bug 881288? you were vaguely around for that conversation...
<ubottu> Launchpad bug 881288 in ubuntu-sponsoring "Syncs using the LP API are showing up as sponsored uploads" [Undecided,New] https://launchpad.net/bugs/881288
<cjwatson> I'm afraid I've been failing to get my head around the details of that thus far
<cjwatson> it's probably better to bring it up with LP folks
<tumbleweed> ok, I'll file a bug
<hallyn> Was trying bzr merge-package again;  is there a reason why it doesn't first pop all quilt patches and rm -rf .pc in both trees?
<slangasek> pitti: samba> oh, sorry, built it in a Debian env by mistake, forgot to watch out for the closure header
<Daviey> slangasek: Hey!  Are you looking at the samba issue?
<slangasek> Daviey: no
<slangasek> I was looking at an unrelated samba issue
<Daviey> slangasek: Would you be able to, please? :)
<Daviey> over 100 dupes now :(
<pitti> mdeslaur: no, of course not intentional -- it's the usual "LP picks random components" problem; I thought that would be uncovered during verification
<mdeslaur> pitti: ok, cool, thanks
<dobey> anyone notice any issues with builders? i uploaded something to my PPA 40 minutes ago, and LP is saying "Start 2011-10-26"
<slangasek> Daviey: I certainly don't hold a maintainer lock on the Ubuntu package, I'm not sure why it waits on me - there seem to be several different proposals for addressing it, someone should just pick one and upload it?
<Daviey> slangasek: Well, there reason i'm turning to you is because you were vocal in the discussion - and clearly understand the package and issue.
<slangasek> Riddell: ScottK has a significant number of merges that he's TIL on for https://merges.ubuntu.com/main.html - with him taking a break, are these a concern for the Kubuntu team?
<slangasek> Daviey: sorry, I probably should have just kept my mouth shut on the bug to begin with ;)  I was meaning only to provide a historical perspective of why the code is the way it is
<rbasak> slangasek: this is also a Debian bug and you're a maintainer :-)
<slangasek> rbasak: yeah, but the bug hasn't been tripped in Debian yet and I'm likely to be painfully slow about deciding how I want to fix it there
<slangasek> so you guys should pick whatever fix that you think is appropriate to cover the gap now
<Daviey> slangasek: Well, the frustrating thing is that we could have had 'a' fix before release, but we held back pending a better solution.
<rbasak> slangasek: wouldn't it be nice if debian and ubuntu agreed how to fix it so we don't have to carry a delta and/or the delta gets carried upstream?
 * Daviey launches a *sigh*
<rbasak> slangasek: it's just a waste of effort if we fix it one way and then debian chooses to fix it another
<slangasek> rbasak: it's easy enough to fix it twice and in the meantime it's causing pain for users
<slangasek> so more effort is being wasted talking / worrying about it than would be wasted by implementing 2 different fixes
<rbasak> Well I did submit a patch and it got rejected on the basis of being unsuitable. So I'm still waiting to hear from somebody what will be suitable.
<Daviey> cjwatson: Do you have thoughts on this?
<rbasak> Or should I just keep submitting patches without any feedback in the hope that one will be acceptable?
<Daviey> It is really, really frustrating that we blocked on this for us to just throw anything into an SRU
<infinity> rbasak: I don't think your patch would have fixed it anyway, after we investigated what was happening.
<rbasak> infinity: fine, but that's not my point.
<slangasek> Daviey, rbasak: frankly, I think the *right* fix is to make update-inetd more robust by not depending on perl-modules; but that's not quick, and won't necessarily help the current round of upgrade breakage
<infinity> rbasak: Mangling update-inetd to not require perl-modules would certainly help, but it won't necessarily be upgraded before samba, which is irksome.
<htorque_> hi all! i sent a mail to -devel which didn't yet come through. anything wrong with it?
<cjwatson> Daviey: at this point I am not sure that adding another semi-informed opinion is going to help matters; too many cooks and all that
<cjwatson> my opinion was to move update-inetd to the prerm, but AIUI slangasek had a reason not to do that
<slangasek> I had a reason why I didn't think update-inetd in the prerm was actually the right thing to do
<slangasek> doesn't mean it's not an appropriate workaround to fix users' upgrades in this case
<infinity> Actually, it doesn't solve the upgrade issue.
<slangasek> also, I'm still not sure update-inetd is guaranteed to be reliable in that case
<infinity> It's not.
<slangasek> because unpack perl -> unpack samba -> unpack perl-modules would still break
<infinity> The real problem is that perl-modules is completely broken when it's half-configured during the 5.10->5.12 transition.
<infinity> What's curious is that unpacking perl-modules 5.12 on a clean system allows update-inetd to work fine. :/
<infinity> It's only the bizarre half-upgraded state that breaks.
<infinity> Making the release upgrader forcefully re-order perl/perl-modules to upgrade as a unit might work around it, but it's obviously not the solution.
<cjwatson> well, that's because the modules all move from /usr/lib/perl/5.10 to 5.12 ...
<cjwatson> (isn't it perl-base/perl-modules that matters?)
<infinity> Err, that.
<slangasek> so as I look at the postrm, I'm actually not sure at all why the non-purge case is being handled here instead of in prerm
<slangasek> and we probably should just move that
<infinity> slangasek: Oh, I'm still convinced the maintainer scripts are a bit wrong, but either way, changing them won't actually make a difference here.
<infinity> The synthetic reproduction of the bug isn't actually the bug that's being duped 100 times (the latter is an upgrade thing, not people removing/purging in weird orders)
<Riddell> slangasek: we'll get them done right enough, although I'm on holiday for the two weeks after UDS so it may not be immediate
<slangasek> yes
<slangasek> Riddell: ok - no hurry, just thought I'd check if it's something on your radar
<elgaton> Hi, I'm fixing a small bug (missing dependency in debian/control) and have a few questions: 1) should I generate the patch against the debian/ directory only (as explained in https://wiki.ubuntu.com/MOTU/Contributing) or a debdiff? 2) Since I need to get a sponsor for my patch and I'm working on the fix, is it right to subscribe ubuntu-sponsors and add the "patch" tag to the LP bug, but to set the bug status to "In Progress" and assign it to myself?
<elgaton> Thanks.
<slangasek> infinity: right - I just looked at tkamppeter's report, and see no perl, so perl-modules is already broken by that point
<cjwatson> however, if it were in the prerm, then you could force things with Depends: perl, couldn't you?
<slangasek> nope
<infinity> Depends gives you unpacked, not configured.
<slangasek> this is the "everything's ok, we're just upgrading and things are currently broken, don't mind our dust"
<slangasek> infinity: er, no
<rbasak> yeah I couldn't find a way to simulate what's happening during an upgrade as dpkg doesn't have an --unconfigure that I could find, so I had to do combinations of --purge and --unpack. So I triggered _a_ problem with the same root cause, but not the problem people are seeing
<cjwatson> if you get the sequence of unpack/configure events, you could issue them by hand starting from a natty chroot
<slangasek> infinity: depends is meant to give you configured; it's just that there are corner cases where configured doesn't mean usable. ;)
<Daviey> (sorry for being absent, chairing a meeting)
<slangasek> (because dpkg doesn't care that a dependency of an already-configured package has been removed)
<cjwatson> slangasek: update-inetd configured doesn't mean usable in this case, but perl configured should
<cjwatson> or maybe perl-modules configured
<infinity> slangasek: Eh?  perl-modules is pretty clearly unconfigured in these upgrade logs.
<slangasek> infinity: can you give me an example log?
<slangasek> (that shows perl state)
<Daviey> btw, there are two tracking bugs now
<infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/856309
<ubottu> Launchpad bug 862129 in samba (Ubuntu Precise) "duplicate for #856309 samba postrm depends on packages not guaranteed to be configured" [High,Triaged]
<Daviey> bug 877852 is the second master bug (due to LP bug)
<ubottu> Launchpad bug 877852 in samba (Ubuntu) "samba failed to install when updating from ubuntu 11.04 to 11.10" [Undecided,Confirmed] https://launchpad.net/bugs/877852
<slangasek> infinity: oh, that's interesting; it shows both of perl and perl-modules unpacked at version 5.12
<slangasek> and actually, at this stage there's no strong guarantee that the dependencies are even unpacked, let alone configured... only postinst gets that as a hard guarantee
<slangasek> (but apt tries to DTRT)
<slangasek> possibly the problem is perl-base not being unpacked yet?
<infinity> slangasek: perl-base is configured.
<slangasek> sure
<slangasek> but not at the new version?
<infinity> slangasek: Yes.
<infinity> slangasek: Search through the terminal log.
<slangasek> oh
<slangasek> right, found it
<infinity> slangasek: perl-modules is unpacked, perl-base is unpacked and configured, samba explodes, perl-modules is never configured.
<slangasek> this is what we get for using unreliable interpreters like perl; let's rewrite update-inetd in python
<infinity> I'm too sick to detect reliably if that was sarcasm.
<slangasek> a pity
<rbasak> I'm not sure it'd be that hard to rewrite update-inetd to not depend on perl-modules
<rbasak> File::Copy: `cp`; File::Temp: `tempfile`. Well, close.
<slangasek> infinity: right, I can't reproduce the problem by just plucking the relevant perl bits out of that log
<infinity> slangasek: It's been a couple of weeks now, but ISTR it couldn't be reproduced by just unpacking perl-modules on a clean chroot, but could be reproduced by unpacking perl-modules 5.12 over perl-modules 5.10... Or something like that.
<slangasek> infinity: I had perl-modules installed
<infinity> Actually, what's responsible for setting @INC?
<slangasek> dunno, but something clearly has it set to the old path
<slangasek> the initial value appears to be embedded in libperl
<slangasek> (where I would expect)
<slangasek> so how can perl be 5.10.1 after perl-base 5.12.4 has been unpacked?
<infinity> Except that libperl is unpacked at 5.12 at that point too.
<slangasek> yeah, and if it wasn't, you'd get a linker error
<infinity> Okay, so, perl-modules configuration is a red herring anyway, since perl-modules doesn't have a postinst.
<infinity> unpacked == configured.
<barry> jtaylor: ping
<jtaylor> barry: pong
<infinity> slangasek: Nevermind, I've gone crosseyed grepping that log.  libperl and perl-base are upgraded after samba's unpack failure.
<infinity> slangasek: Which then leads to wondering why we get perl-modules upgraded so early, if it depends on perl (>= 5.12)
<barry> jtaylor: hi.  i'm looking at merging m2crypto from wheezy and i have a few questions.  since you touched the package last i thought i'd ask you.  first, i don't want to step on your toes if you've already started working on this
<infinity> slangasek: (Well, okay, perl gets unpacked early too, but libperl and perl-base don't come until much later -- after samba)
<jtaylor> barry: with what do you ahve an issue?
<jtaylor> I had actually hopped it could be synced for precise with the new debian maintainer
<barry> jtaylor: second question: you removed proxylib.py because it was nonfree, but i don't see any bug report in ubuntu or debian about that.  wouldn't it be best to report that in debian and it get managed there?
<barry> jtaylor: ultimately, that's my goal too
<jtaylor> barry: yes it turned out to be free after all
<barry> jtaylor: excellent, we can drop that delta
<barry> jtaylor: i think we can also drop the dhpy2 and sslv2 deltas
<jtaylor> I failed to remove it correctly (readded via a patch) but the debian maintainer asked the author who said it was free
<infinity> slangasek: So, the reproduction steps would be "install perl 5.10 and update-inetd, unpack perl-modules 5.12, watch things (obviously) fail"
<jtaylor> barry: one of the patches contains two seperate changesets
<barry> cool.  so i just need to double check the d/control and d/rules changes you made and if those are in the debian version, then i think we can sync
<barry> jtaylor: can you think of any other reason why we can't just sync?  (i'm guessing "no" since you suggested it above :)
<jtaylor> does the debian package enable the tests?
<barry> ah, maybe fix_kill_signal.patch too
<barry> jtaylor: that's the d/rules change i need to double check
<jtaylor> changelog does not mention it :/
<jtaylor> bad, because 21.1-1 in debian was broken which would have been caught by the test
<barry> yep, it doesn't run the tests
<jtaylor> so no sync, the tests are important
<barry> jtaylor: okay, i'll merge it and forward all the deltas to debian
<barry> all *remaining* deltas
<barry> jtaylor: thanks
<jtaylor> this splits one patch into two http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/m2crypto/cosmetics/revision/25
<infinity> And a cable guy is here.  Might lose internets intermittently for a while.
<jtaylor> but I guess that should be in debian already
<barry> jtaylor: i think so, but thanks for the link; i'll double check it all
<slangasek> infinity: ah, right
<hallyn> well this is odd.  I do a 'bzr merge-package', and it randomly removes some source files (which are all identical in both trees)
<slangasek> hallyn: curious.  what branches?
<hallyn> slangasek, lxc from precise and sid
<hallyn> (I first did 'quilt pop -a; bzr remove .pc; bzr ci' in both)
<hallyn> diff -Nrup src ../lxc-sid/src shows no differences before the merge-package attempt
<hallyn> after, things like src/lxc/arguments.h go away
<slangasek> hallyn: hmm, the 'bzr remove .pc' is going to cause problems later, given that you don't actually have access to push that change to the sid branch
<hallyn> oh i dont want to push that to the sid branch :)  i just did 'bzr merge-package ../lxc-sid'
<hallyn> then i'll quilt push -a; bzr add .pc'
<hallyn> if i don't do that, then bzr gets all confuddled about the 'conflicts' in .pc
<slangasek> right, but that means the branch you're merging doesn't match the UDD branch anymore
<slangasek> so it will cause problems for future merges
<hallyn> hm, it keeps track kof that?
<slangasek> yes, the .pc conflicts are a horror, but doing it this way just defers the reckoning
<hallyn> in the end i was probably going to just sling back a debdiff anyway :)
<slangasek> ah
<slangasek> if you're not pushing to *either* branch, then that's fine ;)
<slangasek> but in that case, maybe MoM would be easier?
<hallyn> i don't know, in the past bzr-mergepackage has don e agreat job (and now, apart from this glitch, debian/ is all settled for the sync)
<hallyn> i've not used MoM though.  but purely by hand it was a bit hairy.
<slangasek> bzr merge-package output (w/o munging .pc): The merge resulted in 28 conflicts. Please resolve these and commit the changes with "bzr commit".
<slangasek> conflicts from MoM's merge: 14
<hallyn> how does one run mom?
<slangasek> 'grab-merge lxc'
<slangasek> it downloads the pre-staged merge from merges.ubuntu.com
<slangasek> (from ubuntu-dev-tools package)
<hallyn> slangasek, ok, thanks - i'll try that for my next merge for practice.  For this one i think i'll just build the debdiff now and be done with it :)
<slangasek> hallyn: and the Contents conflicts in src/lxc/ are because this is a new upstream version, meaning that there are *two* merges happening - first one for the upstream, then one for the packaging
<hallyn> hm?  there shouldn't be a new upstream version
<slangasek> hmm
<slangasek> that's how the output reads to me, but I see that you're right
<slangasek> ok, I don't know what's causing that conflict then
<stgraber> hallyn: for LXC, the easiest is probably to just take the Debian package, re-apply the few patches we have on top of them (unless dlezcano feels like releasing ;)), re-add the upstart stuff and the cgroup-lite change (as I guess Debian doesn't have cgroup-lite yet), I guess that's pretty much it for LXC
<slangasek> however, it is probably related to the 'criss-cross merge' warning at the top
<hallyn> stgraber, yes, that's what it amounts to :)
<hallyn> stgraber, i'll let you review if you don't mind
<stgraber> hallyn: I guess we can probably convince Daniel to release a new LXC at the end of next week (assuming we'll push some more stuff to git at UDS), then our changes should be back to a minimal set
<hallyn> stgraber, that'll be nice
<stgraber> hallyn: sure, send me the debdiff and I'll review + upload if it looks good
<hallyn> thx
<hallyn> slangasek, i'll have to go read up on criss-cross merge later :)
<slangasek> hallyn: summary: branch A merged into branch B, now you're merging branch B into branch A.  In this case, I think it's because the new upstream version was introduced separately on each branch
<stgraber> hallyn: I also need to look at libnih again with James Hunt, once this one is ported to multiarch (he may have already done it on his laptop ;)), I'll commit support for containers using non-native architecture (using qemu + a multi-arch version of libnih and upstart)
<slangasek> not an error at all, just means bzr's poor little brain sometimes gets confused about what it should do with such a merge
<stgraber> hallyn: then we'll be able to use "-a armel" on x86 and get a working container
<hallyn> cool
<hallyn> i was meaning to look at libcap2 wrt multiarch.  haven't yet though.
<slangasek> stgraber: yes, jhunt and I have multiarch libnih sorted out, I guess he'll be pushing soon
<stgraber> slangasek: awesome! I might be able to show a working armel or powerpc container on x86 as a lightning talk on Friday then
<stgraber> (unless I discover that something else than upstart heavily depends on ptrace() in our boot sequence :))
<slangasek> heh
 * slangasek thinks that over briefly
<slangasek> nope, shouldn't be anything else
<stgraber> well, obviously strace and gdb won't work in that container, but you already get that behaviour using a simple chroot with the qemu-<arch>-static stuff
 * slangasek nods
<slangasek> neither of those should be triggering at boot ;)
<hallyn> stgraber, is linux-any a valid target in ubuntu debian/control?
<hallyn> well, debuild doesn't warn me about it...
<hallyn> vim syntax highlighting just doesn't like it maybe :)
<geser> hallyn: yes, linux-any is valid and also supported by LP
<hallyn> thx
<mterry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<adam_g> if i'm about to propose a merge for an SRU to a package that doesn't have an lp:ubuntu/$release-updates/pkg branch, do i just propose merge into lp:ubuntu/$release/pkg instead?
<mterry> adam_g, yeah
<mterry> adam_g, I think that's typical
<adam_g> mterry: thanks
<Daviey> adam_g: UDD is messed up for SRU's :/
<Daviey> The target should be -proposed, but that would never have a -security upload in there, messing up the stacking.
 * micahg wonders if one can branch from -updates and propose a merge against -proposed
<maco> dont see why not
<micahg> depends on how the branches are stacked on LP
<slangasek> micahg: you can branch from -updates and propose a merge against -proposed *if there's already a -proposed branch to target*...
<slangasek> it'd be really nice to be able to do UDD-driven SRUs - i.e., build-from-branch for all SRUs, so the SRU team just lands the branch to approve the upload
<slangasek> but that's not high on the priority list, I think :)
<hallyn> stgraber, our /etc/default/lxc has been storing MIRROR= for lxc-create (along with the RUN= for /etc/init.d/lxc).
<hallyn> stgraber, with the new debian package, the pre-inst does 'rm /etc/default lxc' if that file has 'RUN=' in it
<hallyn> stgraber, then it creates a new one in .postinst
<hallyn> are we ok with that?
<stgraber> hallyn: is it looking for ^RUN or for RUN? if it's simply looking for RUN, that means destroying a configuration file for everyone on upgrade which I really don't think we should do
<stgraber> we could instead look at the md5 of the file or some similar approach to only replace it if it's indeed the exact same one that was shipped with the earlier version
<hallyn>                 if grep -qs 'RUN=' /etc/default/lxc
<hallyn> ok,
<hallyn> so i'm thinking i'll just sed over the file to get rid of RUN ?
<hallyn> i hate adding more delta from debian, but...
<stgraber> why did he remove RUN= to start with?
<hallyn> he switched to having /etc/lxc/local/ store data about autostart
<hallyn> and now added LXC_AUTO=ture anyway
<hallyn> true that is
<hallyn> so really, i don't know
<stgraber> fun...
<hallyn> he's in #lxcontainers usually so we could ask him,
<stgraber> I'm wondering why he's actually messing with it in postinst instead of just shipping the file as conffile and letting dpkg deal with it
<hallyn> right.  dunno
<hallyn> for that matter i don't know why he's changing the mechanism for choosing autostart containers anyway
<stgraber> I'd much rather carry and extra delta with Debian than removing a user's configuration file without warning (or even changing it)
<stgraber> *an
<hallyn> ok.  so get rid of both?
<hallyn> (pre+postinst)?
<hallyn> maybe i should just push what i have to you, and let you decide :)
<hallyn> it's all looking good aside from that bit
<stgraber> yeah, I think the easiest is to get rid of that change and have the new init script check for RUN=yes instead of LXC_AUTO=true
<hallyn> you think thta's better than shipping a new lxc.default with LXC_AUTO=true and letting the user decide (with comments inthe file to help)?
<stgraber> oh, and that means that config files are no longer in /etc/lxc/auto/? what's that new /etc/lxc/local thing? ...
<hallyn> iirc you symlink containers in there
<hallyn> that you wnat autostarted
<hallyn> no, wait
<stgraber> hmm, in Oneiric I'd simply symlink their config into /etc/lxc/auto and they'll auto-start, that was working fine!
<hallyn> no, debian/local is just for his own scripts
 * stgraber starts to think we should just move the init script and all that stuff into the upstream branch and be done with it, no more distro delta ;)
<hallyn> worth discussing at uds.  especially once we start introducing our own network bridge for default config :)
<hallyn> stgraber, ok, LXC_AUTO defaults to true. but it's new.  so, should I just keep the same lxc.default we've had and avoid debconf questions, or should I add LXC_AUTO to our lxc.default so ppl know about it?
<hallyn> in either case, I figure I'm nuking .preinst and .postinst
<hallyn> (defaults to true if it's not in /etc/default/lxc, i mean)
<hallyn> i'll add it in.
<rbasak> slangasek: thanks, re: bug 862129
<ubottu> Launchpad bug 862129 in update-manager (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129
<mwhudson> so my x220 completely reliably suspends and resumes
<mwhudson> once
<mwhudson> the second resume fails, 100% of the time
<hallyn> stgraber, http://people.canonical.com/~serge/lxc-sync.debdiff is working for me
<stgraber> mwhudson: do you have cgroup-bin installed? if so, replace it by cgroup-lite
<mwhudson> $ dpkg-query -W cgroup-\*
<mwhudson> No packages found matching cgroup-*.
<mwhudson> although hm, now things are just being strange
<mwhudson> i tried to reproduce using pm-suspend and it worked, but i'm on ac power now
<soren> stgraber: If that were the problem, the second *suspend* would be failing, IIRC. Not the second resume.
<mwhudson> and then i closed the lid and it didn't seem to suspend properly and when i opened the lid again it went to mirrored displays
 * mwhudson filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881647
<ubottu> Launchpad bug 881647 in linux (Ubuntu) "lenovo x220 fails to resume more than once" [Undecided,Confirmed]
<stgraber> soren: last I had this bug was a while ago, couldn't remember if it was the second suspend or resume that was hanging because of cgroup-bin :)
<gord> my x220 suspends/resumes fine 100% of the time no matter how many times i do it =\
<mwhudson> gord: oneiric?
<mwhudson> hm
<gord> yup
<mwhudson> hm
 * mwhudson remembers something else
<mwhudson> gord: does shutdown/reboot work properly for you?
 * hallyn doesn't have a single laptop, of many, that'll suspend/resume right now :(
<gord> yeah all works fine
<gord> saying that though the X220 has quite a few customisations you can make so we might just have different hardware
<stgraber> hallyn: any reason you kept lxc.template and lxc.config?
<mwhudson> gord: yeah, likely i guess -- i have i7, ssd, intel wifi
<hallyn> the .template is just for his default/lxc tweaking script?  guess that can go.  I thought lxc.config had something to do with the -dbg or -dev package
<gord> intel wifi here, i3 and hd
<mwhudson> hm
 * mwhudson plays around -- will probably drop off :)
<hallyn> I see now
<hallyn> my bad
<hallyn> yeah both of those can go
<stgraber> hallyn: lxc.config prompts the user for the debconf keys from lxc.templates, my understanding is that these two were used for the templating of the defaults file done by the scripts you removed
<stgraber> hallyn: ok, removed and added a comment to the changelog, continuing the review :)
<hallyn> stgraber: well, do you think we should rather keep the pre/postinst and add saving of MIRROR?
<hallyn> I don't like all that code for something like that;  but ...
<stgraber> hallyn: any reason not to move lxc-start-ephemeral to that new local directory?
<hallyn> stgraber, no, and lxc-is-container coudl go there too
<stgraber> ok, I'll move them
<hallyn> is that location conventional?
<stgraber> first time I saw that, I saw some others use debian/scripts/ too, I don't remember reading about a standard location
<barry> any buildd admins around who can rescore a PPA build for me?
<stgraber> I'm not too sure what to do with /etc/default/lxc to be honest, moving to debconf may be interesting but we need to make sure we don't end up prompting everyone who'll be upgrading from oneiric or lucid
<stgraber> barry: link?
<barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/2877224
<barry> stgraber: https://launchpad.net/~barry/+archive/python/+build/2877225
<barry> (the first is amd64, second i386)
<barry> stgraber: thanks!
<stgraber> barry: there you go for a very small bump ;)
<barry> stgraber: awesome, very nice! thanks
<stgraber> hallyn: I'd be tempted to go without debconf for that initial merge, then if we feel the need, merge/extend that bit later in the cycle
<hallyn> stgraber, if you don't want the user to be prompted, then we should undo the changes i made to lxc.default altogether?
<stgraber> hallyn: I don't want to have them prompted when they didn't touch the config file. I'm fine with prompting them if they changed something
<mwhudson> well that was a bit strange, it suspends and resumes fine on ac power
<mwhudson> and pm-suspend is fine, but if i close the lid on battery power, then pm-suspend it oopses
<hallyn> ok
<stgraber> hallyn: any reason " debian/lxc.install - README gets (mis-)installed under --with-rootdir." isn't in Debian? doesn't that affect them too?
<hallyn> no, bc they don't use --with-rootdir=/usr/lib/lxc/root
<hallyn> which means, lxc-sshd wont' work for them
<stgraber> ok
<stgraber> hallyn: http://paste.ubuntu.com/719149/
<hallyn> I assume lxcguest.install and lxc.install got updates reflecting the new locations for lxc-start-ephemeral and lxc-is-contaienr?
<stgraber> I updated your section a bit and listed the changes I made
<stgraber> yep, I dropped the lines from these two
<stgraber> IIRC he simply copies everything from local to usr/bin
<hallyn> great.  looks good, thanks.  regarding the README, of course I don't know WHY it ends up in .../root
<hallyn> stgraber, thanks
<stgraber> rest of the diff looks sane. I haven't looked at exactly what's changing in the diffs but that's what they have in Debian, so that should work :)
<stgraber> I'll upload it now and will hopefully test it soon (need to upgrade a VM to precise, only have containers at the moment)
<lifeless> hallyn: btw did I file a bug about rmmod working in containers ?
<lifeless> [by default]
<stgraber> lifeless: I'd be happy to +1 on that bug report ;) it's a major pain when upgrading containers
<lifeless> stgraber: I have a rmmod iwlagn; modprobe iwlagn thing I run regularly.
<lifeless> stgraber: my host is 64bit, containers 32bit.
<lifeless> stgraber: finally I bind mount home into them, so I have a shared bash history...
<lifeless> stgraber: guess what happened when I didn't check the host portion of my prompt, and my wifi did its 'I'm going to suck' thing.
<stgraber> err, my eyes don't work today ;) I read mknod instead of rmmod which is a completely different issue though just as annoying :)
<lifeless> stgraber: heh :)
<stgraber> lifeless: oh, and what happened to the kernel when you did that? :)
<lifeless> stgraber: anyhow, iwlagn was removed, then modprobe failed spectacularly
<lifeless> I can't recall if it tried to insert the 32 bit version or quite what went wrong
<stgraber> I've noticed something similar with my automated d-i testing in a container, d-i tries to modprobe/insmod quite a bunch of modules into my kernel ;)
<lifeless> stgraber: yah, that will be similar
<stgraber> for now I simply override modprobe and insmod with a simple "exit 0" ;)
<lifeless> bug 850687
<ubottu> Launchpad bug 850687 in lxc (Ubuntu) "Should disable cap_module by default" [Wishlist,Triaged] https://launchpad.net/bugs/850687
<stgraber> hallyn: user namespaces will solve all that right? :)
<hallyn> yup!
<hallyn> they already solve that - you just can't then use the container :)
<stgraber> hallyn: "can't then use the container", because of the VFS part?
<hallyn> lifeless, stgraber, well if the modprobe/rmmod one seriously bugs you now, then we should push the fix into the package instead of wiating for an upstream release...
<hallyn> i thought it ws just a security concern
<lifeless> hallyn: bit of both
<hallyn> stgraber, not just that, there are lots of places that we default to denying containers privilege to resources which they own anyway
<hallyn> if i can get this last set of 8 patches into the kernel, then we can work on relaxing the security checks (and handling files)
<stgraber> hallyn: did any of that patch that was written/pushed during the sprint make it to the kernel? I'd have thought the pid ns attach and reboot/shutdown one would be upstream by now...
<hallyn> no, it didn't.
<hallyn> daniel's laptop got stolen, and eric's been busy with his dayjob
<hallyn> so both lxc-attach and reboot patches got lost
<hallyn> i'm hoping we can push both again next week
<slangasek> ouch
<hallyn> yeah
<stgraber> argh, didn't know for Daniel's laptop, that really sucks...
<hallyn> that also postponed some merging of lxc patches
 * hallyn tries hard to not be tied down to any one machine or phsyical location :)
<stgraber> at least we have the patches on lkml/git, it's just going to be short if we want these upstream for 12.04
<stgraber> unless we can convince our friend in the kernel team to carry these as an Ubuntu delta ;)
<hallyn> a few 6-packs might help
<hallyn> but, maybe I should see if we can prod to have those pushed this week
<stgraber> if that's what it takes, I'm sure we can get some ARM server company to sponsor that :)
<hallyn> excellent
<stgraber> hallyn: lxc uploaded
<barry> stgraber: that amd64 build is going in the wrong direction.  first 2 minutes, than 9 minutes, now 14 minutes 'til it builds :).  no need to change anything, i just thought it was funny.  the i386 build gave me the information i need.
<hallyn> stgraber, great, thanks.
<stgraber> barry: interesting ;) I'm guessing that's because the buildds are busy with long running builds
<barry> stgraber: that, or there's a little robot on an exercise wheel behind lp's web ui, rolling dice and laughing at us.  your explanation seems more plausible, but i'm sticking to mine.
<stgraber> :)
<hallyn> stgraber, http://people.canonical.com/~serge/lxc-drop-sys_module.debdiff  (though that's against my tree, but apply against yours)  if you wanted to quickly push a fix for cap_sys_module too.
<hallyn> (actually i wonder if dropping cap_mac_admin will end up breaking packages)
<hallyn> (that'd be fun)
<stgraber> hallyn: is cap_sys_module also restricting reading the module list  (lsmod)? just wondering as I think we want that change anyway, I'd just need to update my default config when doing d-i testing
<hallyn> no. lsmod should still work
<hallyn> i can lsmod as unprivileged user
<stgraber> good
<stgraber> what's cap_mac_admin doing? don't remember seeing that one before (do we have a list of all the cap_* somewhere? :))
<hallyn> uh, sure - linux-2.6/include/linux/capability.h :)
<hallyn> LSMs use that to gauge who can change policy
<stgraber> got to love kernel documentation :)
<hallyn> and mac_override, who can bypass it
<hallyn> so I assume this will keep containers from loading apparmor policies.
<hallyn> we need to talk to jjohansen at uds about apparmor namespaces and how to handle all of this, of course
<hallyn> well, oneiric container starts up fine though (without those caps)
 * hallyn installs apache2 as another test
<stgraber> so we'd probably have to revert the cap_mac_* ones once we have the apparmor namespace change done in lxc or will that just work without the capability?
 * stgraber has no clue how apparmor actually works (if that wasn't clear ;))
<slangasek> in a way that is comically incompatible with how selinux works :)
 * jjohansen reads back scroll
<dobey> is there an update to make pbuilder/etc know about precise, on older Ubuntus yet?
<barry> tumbleweed: rock.  thanks for the confirmation.
<slangasek> (Debian bug #634081 is a beautiful thing)
<ubottu> Debian bug 634081 in slapd "/usr/sbin/slap* hard links break SELinux" [Normal,Open] http://bugs.debian.org/634081
<tumbleweed> barry: you did make it nice and easy :)
<sbeattie> stgraber: capabilities(7) contains an overview of what each capability is, though definitely not in enough detail.
<barry> tumbleweed: :)
<hallyn> stgraber, well, amusingly, cap_mac_admin will be targeted at the user namespace
<hallyn> so we shouldn't have to relax the check *if* we can use them
<hallyn> wait - no they wont
<hallyn> so yes, probably :)
<tumbleweed> dobey: running into any particular problems?
<dobey> tumbleweed: i can't do pbuilder create to make a chroot for it?
<tumbleweed> dobey: on what release?
<dobey> on 11.04
<tumbleweed> dobey: right. natty and maverick haven't got debootstrap backports
<tumbleweed> I think there's also a ubuntu-dev-tools/distro-info thing I need to do for one or two of them
<dobey> what's the best way to make a pbuilder chroot then? is there a base.tgz i can just download from somewhere?
<geser> dobey: cd /usr/share/debootstrap/scripts && sudo ln -s gutsy precise
<tumbleweed> what geser said :)
<dobey> ah ok
<stgraber> hallyn: I'm confused ;)
<hallyn> stgraber, so yes, we may end up re-enabling mac_admin in containers
<stgraber> hallyn: ok :)
<stgraber> hallyn: I'll wait for LXC to build on everything, then push that extra change then
<hallyn> depends on what we can do with apparmor namespaces
<hallyn> stgraber, ok, thanks.  and hopefull i don't break anyone...
<hallyn> (maybe libvirt in a container - but who'd do that? :)
<stgraber> at least I seem to remember jjohansen being marked as essential for the LXC session at UDS, so we'll hopefully know more then
<hallyn> yup
<jjohansen> heh yeah I am planning on being there, but I can provide info now if you would like
<jjohansen> currently apparmor need MAC_ADMIN to load policy
<jjohansen> but I am more than open to discussion revisions/changes that maybe needed.
<hallyn> jjohansen, are there any packages that will just fail to install or run without MAC_ADMIN?  or will they just not end up installing a policy?
<jjohansen> hallyn: the packages shouldn't fail, but the policy will fail to load
<hallyn> jjohansen, fwiw, if, when apparmor namespaces are done, a child namespace will be contained by an overall policy, then I think we can let containers have CAP_MAC_ADMIN.
<hallyn> cool
<jjohansen> right, even as they are right now the child namespace can't manipulate the parent's namespace with CAP_MAC_ADMIN, but that doesn't mean much as it has access to the rest of the system if it wants.
<hallyn> jjohansen, i suppose i should check for any apparmor uds sessions too
<jjohansen> hallyn: heh if your interested sure, but don't feel compelled, we can discuss lxc bits in lxc sessions, etc
<hallyn> ok, great!
<hallyn> hm, there seems to be a bug in tunctl.  'tunctl -u 1000' is *not* making 1000 own tapN
#ubuntu-devel 2011-10-26
<Lirodon> Just wondering, is that "OEM mode" still there?
<slangasek> Lirodon: yes
<bryceh> jcastro, mind adding https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-xorg to the schedule?  Sorry, I should have registered it earlier but it slipped my mind.
<slangasek> bryceh: linked to the sprint; that should let it get scheduled by the autoscheduler
<slangasek> (if you "propose for sprint", it goes in the queue fwiw)
<pitti> Good morning
<ajmitch> morning pitti
<pitti> mdke: replied to your langpack mail; TL;DR there is still time to do an ubuntu-docs upload
<Laibsch> tumbleweed: you asked me if things about getting patches applied regress.  Well, I just stumbled across bug 697788 again.  And I think that no reaction after three months is pretty bad.  Almost as bad as during the worst times.  I had already forgotten about this one.
<ubottu> Launchpad bug 697788 in icecc (Ubuntu) "No log output when launching iceccd" [Undecided,Fix released] https://launchpad.net/bugs/697788
<Laibsch> I don't think I'm the only one with this problem, am I?
<broder> Laibsch: why isn't ubuntu-sponsors subbed to that bug?
<ajmitch> broder: even if they were, would it show on a list, since the main bug task is fix released & the nominations aren't marked as accepted yet?
<broder> oh ugh. yeah, you're right
<Laibsch> broder: dunno.  to be honest, processes change about every 6 months, so I have a hard time keeping up. Let me ask the other way round, what's the purpose of ubuntu-sru?
<Laibsch> I know everyone is doing their best, I'm not necessary complaining.  But things can be pretty frustrating.
<broder> Laibsch: for at least the last year, it's the list of people who approve SRUs after they've been uploaded by a sponsor
<Laibsch> s/necessary/necessarily/
<ajmitch> one major problem I see is a LP timeout when trying to review nominations - no wonder it got missed
<Laibsch> so, I subscribe the sponsors team and they in turn subscribe the sru team? I don't even need to worry about ubuntu-sru?
<broder> Laibsch: that's right
<Laibsch> OK
<Laibsch> I'll try to remember that (until the next time it's changed) ;)
<broder> Laibsch: that's also the process that's documented on !sru (and has been, since we made this change)
<broder> ahem
<broder> !sru
<ubottu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
<Laibsch> I can't reread wiki pages every time I want to get a patch accepted ;-)
<Laibsch> seriously, this changed so frequently, it's hard to keep up unless you hang around in IRC every day
<Laibsch> maybe I'm too old and too long with Ubuntu ;-)
<ajmitch> possibly, this changed ~15 months ago from what I can see
<broder> most of the time, we change processes because we're trying to make it easier, and for people who don't already know the old way, i think the new approach is a definite improvement
<Laibsch> yes
<Laibsch> and I agree that many processes were improced recently
<Laibsch> most notably the sponsorship process
<Laibsch> that's why I noticed that recently things were taking their time again, maybe just bad luck.
<broder> i'm fairly confident there was mail to...a mailing list at the time we made the change, but i can't remember which one it would have been
<Laibsch> broder: you are overestimating the time I can spend with reading mailing lists, wiki, etc.  One can spend half the day doing that and then I'm sure one is up to date on most of the processes ;-)  I simply can't.
<broder> yeah, i was hoping i'd find an e-mail to ubuntu-devel-announce, but it looks like it was just discussed on ubuntu-devel
<Laibsch> I wouldn't have read either </sheepish admittance>
<broder> (https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030999.html was the post, for reference)
<Laibsch> thx
<Laibsch> broder: that actually concerns only the second part of the process (the one that I don't deal with due to lack of privs)
<broder> hmm...that's true. i think i was familiar enough with what jdong was proposing that i could read into the sponsorship process changes, but re-reading the e-mail, that's not obvious
<Laibsch> it's not always clear to me what is and what isn't in the queue and at what position.  There was http://reports.qa.ubuntu.com/reports/sponsoring/ posted here, yet I'm not fully sure how to read that list.
<broder> ah, sure. "queue" is referring to two different things
<broder> there's the sponsorship queue - which is your link
<broder> but for srus (and new packages and near-release freezes and such), LP puts the upload into a queue to be accepted by an archive admin
<broder> (that's http://launchpad.net/ubuntu/precise/+queue or similar)
<Laibsch> I guess what I'm saying that the process (and thus the content of the queue) are a bit opaque to people who don't do this stuff at least daily (I'm doing a fair bit)
<Laibsch> I see. I don't think I'm concerned at all by the second queue you mentioned.
<Laibsch> what priv is necessary to be able to approve series nominations?
<micahg> Laibsch: upload rights or series driver
<Laibsch> which one is more straightforward to get?
<Laibsch> I'm an SRU type of guy, I fiddle too much with my computer already.  Can't have it break every 6 months on top of that ;-)
<micahg> Laibsch: upload rights I think, you can ask for tasks here or in #ubuntu-motu as appropriate and someone can usually accept for you
<Laibsch> would be nice to be able to do that on my own ;-)  I think I have pretty far-reaching privs in bug-control
<ajmitch> micahg: so MOTU can approve nominations for universe packages?
<micahg> ajmitch: indeed, and PPU for theirs as well
<Laibsch> ah, the dreaded ubuntu-membership comes first
<RAOF> Not necessarily.
<Laibsch> Well, it seems that me working mostly behind the scenes has so far not helped me ever become anybody in terms of ubuntu-devel membership.  Becoming a DM OTOH was painless and a breeze.
<Laibsch> ubuntu-devel as in "dev in ubuntu" not core-dev, but anything upload-related.  and as opposed to -bugs where I hardly ever run into something I cannot fix on my own.
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<RAOF> Laibsch: Have you applied for MOTU, or for upload rights to a packageset you work in?
<Laibsch> I tried to apply for normal membership once and that was such a terrible experience that it put me off ever trying again.  It was a total insult (and I stayed up until 5 in the morning on top of it!)
<Laibsch> Essentially, I was told the equivalent of "you are overqualified for simple membership, application rejected"
<Laibsch> wtf
<Laibsch> :-O
<RAOF> The ubuntu-membership thing appears to be not well advertised.
<Laibsch> maybe that's agood thing ;-)
<RAOF> No, I mean that it's not something you (generally) apply for; it's something that is a bonus part of something more interesting.
<Laibsch> may I ask that somebody accept the lucid task for bug 697788 to get the ball rolling?
<ubottu> Launchpad bug 697788 in icecc (Ubuntu Hardy) "No log output when launching iceccd" [Undecided,New] https://launchpad.net/bugs/697788
<RAOF> Or, at least, it's not something developers should ever need/want to apply for; it grants no development privilegdes.
<RAOF> Hm, already been done?
<Laibsch> ah nice, must have been done in the last 2 minutes or so
<Laibsch> RAOF: even if there was no need for a dev to apply for membership only, it should not be rejected based on that ground. It pissed me off to NO end.
<Laibsch> how am I to know whether I am already a dev or mere mortal member?
<RAOF> Yeah, that seems a bit unnecessary.
<mdke> pitti: thanks for the reply. The discussion in #ubuntu-translators appears to have been completely wrong...
<mdke> pitti: I will try and do the upload today, and ping you to approve it (if you don't mind)
<pitti> mdke: please
<pitti> mdke: I have the langpack export, but I'll wait a bit for this to land
<pitti> it's enough to have the package built
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<mdke> no one happens to know off the top of their head what this build error means?
<mdke> make[3]: execvp: /bin/bash: Argument list too long
<mdke> I get it quite a lot and can work around it but if there is an easy fix...
<geser> IIRC you get this when bash expansion of "*" (and similar) generates too many arguments (like "ls *" in a directory with many, many files)
<mdke> yes, it is trying to install too many files
<mdke> geser: so I take it from your answer that there is no easy work around?
<geser> you'll need to split the calll into several somehow, either calling it first on "a*", then "b*", ... or with find and xargs
 * mdke nods
<mdke> that's comfortably beyond my skills :)
<mdke> ok, thanks for the pointers
<mdke> pitti: uploaded version 11.10.5
<pitti> mdke: yay, thanks
<mdke> pitti: I won't be able to test the -proposed built package until this evening after work, but the one I built worked fine. Anyway it should be enough to get the translations I guess. If there is anything please send me an email as I'll be out of irc contact
<pitti> mdke: ok, will do
<pitti> mdke: just waiting for the diff to appear on LP, then I'll review this
<mdke> pitti: fine, I'll be around for about 30 mins. Please ignore the changes to the html/ directory, I have rebuilt the theme for the website and this isn't used in the package build process, but we keep it in the bzr branch
<mdke> pitti: the diff will be huge anyhow because of all the new translations
<mdke> when I added them to the bzr branch there was a diff of 120755 lines
<pitti> mdke: accepted
<TLE> pitti, mdke: Hey guys, sorry about the bumpy start :|
<pitti> TLE: no harm done :) package is building now, once that's done I can prepare the langpacks
<pitti> the LP export is ready
<mdke> pitti: fantastic, thanks. TLE: no worries
<TLE> pitti: so by all indications it looks like there will be new language packs ready by thursday I gather, in that case I will give the translators a heads up
<pitti> ev: can you please do bug 606134? I can't push to the branch
<ubottu> Launchpad bug 606134 in Ubiquity Slideshow "ubiquity-slideshow-ubuntu package has outdated translations in Ubuntu 10.04." [High,In progress] https://launchpad.net/bugs/606134
<ev> pitti: sure thing
<jamespage> please could the NEW jenkins-htmlunit + osgi-* binary packages be accepted into precise - ta
<micahg> dholbach: I thought we were waiting for libraries to mirgate to testing before ACKing syncs? (bug 881822)
<ubottu> Launchpad bug 881822 in cogl (Ubuntu) "Sync cogl 1.8.2-1 (main) from Debian unstable (main)" [Undecided,Triaged] https://launchpad.net/bugs/881822
<dholbach> micahg, I'll bear that in mind for the next syncs I look at, but in this case I checked the upstream changelog and they consisted of almost only fixes and one of them was requested by the debian maintainer
<ricotz> dholbach, micahg, hi, these are stable release updates for gnome 3.2 which eventually should get into oneiric-proposed too
<micahg> dholbach: ok, but it's less about the package itself than its rdepends when it comes to libraries (AIUI)
<micahg> ricotz: indeed, but oneiric-proposed also has a waiting period before migration :)
<ricotz> micahg, right, but it seems better to have them in precise first :) to avoid diversions
<dholbach> I understand the reasoning and agree that waiting in some cases might bring up problems in rdepends testing new code paths, etc - and as I said: I'll bear that in mind next time
<micahg> ricotz: indeed, I appreciate you trying to do things properly, it wasn't so much about this case as in general
<micahg> dholbach: thanks, I trust your judgment here :)
<dholbach> still I checked the diff, no soname changes, there were memleak fixes in there, it came with a recommendation from the debian maintainer, so I felt sufficiently convinced that it was a good idea to sync - if we want to wait for things in testing no matter what, I must have misread the memo about it :)
<ricotz> micahg, no problem, but isnt it reasonable to have libraries transitioned asap to avoid rebuilds of rdepends later
<micahg> ricotz: yes, if there's a soname bump it makes sense to get it in early, but there's a tradeoff of making sure that the new version is adequately tested w/the rdepends, in this case there's no soname bump, so as dholbach said, it's less important
<ricotz> micahg, alright, i will keep that in mind
<micahg> ricotz: then again, syncing from Debian is usually better than a -0ubuntu1 upload as long as the changes are sane, so YMMV
<pitti> Riddell: do you know which branch https://launchpad.net/ubuntu/+source/kubuntu-docs/+changelog was committed to?
<pitti> Riddell: I checked lp:kubuntu-docs, ~ubuntu-core-doc/kubuntu-docs/natty (which is what Vcs-Bzr says), ~ubuntu-core-doc/kubuntu-docs/oneiric, ~ubuntu-core-doc/kubuntu-docs/precise, but they all stop at natty
<Daviey> doko: Does a sync of libpam-krb5 from sid make sense?  Seems to include your multiarch changes, and other goodies.
<doko> Daviey, sure
<\sh> moins
<\sh> micahg, you are sure that with latest dpkg -Werror=format-security was disabled?
<cjwatson> sure or aware?
<cjwatson> I'd talked to the security team previously, their main desire was to get it into dpkg-buildflags output, they weren't pushing for it to be in the environment by default
<cjwatson> "disabled" is misleading
<\sh> cjwatson, well...then I wonder why I get all those errors
<\sh> xap_UnixDialogHelper.cpp:833:18: error: format not a string literal and no format arguments [-Werror=format-security]
<\sh> cc1plus: some warnings being treated as errors
<\sh> abiword as an example
<\sh> using cdbs
<cjwatson> \sh: cdbs fetches dpkg-buildflags output directly - that one would fail in unstable too
<cjwatson> I'm only concerned about the ones that were failing just in Ubuntu
<cjwatson> cdbs users have to fix their problems more quickly
<\sh> cjwatson, looks like
<cjwatson> fail in unstable> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643344
<ubottu> Debian bug 643344 in src:abiword "abiword: FTBFS: xap_UnixDialogHelper.cpp:833:18: error: format not a string literal and no format arguments [-Werror=format-security]" [Serious,Open]
<pitti> TLE, mdke: new langpacks look good, have the latest ubuntu-docs translations, and also the missing deja-dup/games/etc. mallard help
 * pitti sends builder-wards
<\sh> cjwatson, that's it...and 2.9.1 is fixing that upstream, but this is development release and {x,l}ubuntu don't want a development version (which I can understand)
<\sh> bah..I'll get back to my patch for fixing those buggers.
<cjwatson> they're trivial to fix
<cjwatson> the main reason I disabled the export-to-environment part in dpkg for that flag was that it was causing silent configure test failures, and I was worried about misbuilds if we were doing that differently from Debian
<cjwatson> well, silent configure test failure anyway; I only noticed one, which happened to result in a build failure later - but I was more worried about the ones I wasn't noticing
<cjwatson> now, the same may be happening for cdbs packages, but at least we're in sync with Debian on that part
<cjwatson> All distro buildds appear to be dead.  I've raised it on #launchpad-dev.
<ogra_> tkamppeter_, ping
<tkamppeter> ogra, hi
<tkamppeter> ogra_, hi
<ogra_> tkamppeter, hey, i'm trying to get my hp laserjet 1018 wortking on my arm netbook
<ogra_> tkamppeter, in natty it just worked to run hp-plugin or hp-plugin-ubuntu ... seems in oneiric i get a gpg erros for the file it downloads
<tkamppeter> ogra_, this printer needs a firmware file and due to the Linux Foundation desaster the Official download from HP is not back working yet.
<ogra_> tkamppeter, is there any way i could copy what it downloads from the natty install ? 8where does the .run file unpack its content)
<ogra_> i have a working driver on another machine, but i dont know which files to copy
<tkamppeter> ogra_, you can use an alternative download, run "sudo getweb 1018" on the command line.
 * ogra_ tries
<TLE> pitti: awesome
<pitti> cjwatson: really? they look ok from here
<ogra_> tkamppeter, that prints sihp1018.img, anything i need to do additionally now ?
<pitti> cjwatson: a minute ago all five i386 builders built different packages than now
<tomreyn> hi. is there a process to request removal of a package because it is not sufficiently maintained?
<pitti> cjwatson: oh, you mean they fail to build everything?
<pitti> tomreyn: yes; please file a bug against it with a rationale, and subscribe ubutnu-archive
<cjwatson> pitti: all the builds just flip back to needs-building after a couple of minutes, failing to leave a log
<tkamppeter> ogra_, it should have dropped the firmware file in /lib/firmware/hp, check whether it landed there.
<cjwatson> pitti: I've been watching it for a while now
<\sh> tomreyn, which package? :)
<pitti> cjwatson: ah, right
<ogra_> tkamppeter, yes, it did
<tomreyn> \sh: https://bugs.launchpad.net/ubuntu/+source/indicator-weather
<tomreyn> pitti: thanks
<tkamppeter> ogra_, if you unplug and replug your printer or turn it off and on again, the firmware should get loaded into the printer (letting the printer make its startup noise twice).
<ogra_> tkamppeter, oh, i forgot to mention, its a network (ipp) printer
<TLE> pitti: if they are all good to copy to proposed, let me know when they land there
<pitti> TLE: just followed up to the mail
<pitti> TLE: I'm uploading to -proposed
<tkamppeter> ogra_, the alternative mechanism only works with the printer connected via USB.
<pitti> we just need the buildds back, cf. what cjwatson said a few monents ago
<pitti> TLE: ^
<ogra_> tkamppeter, ah, thats bad
<ogra_> tkamppeter, and there is no way to get the driver from the other machine through just copying it ?
<tkamppeter> ogra_, the printer itself has only an USB connector, did you connect it to a router? Does HP's software support this configuration?
<cjwatson> pitti: wgrant appears to be looking into it
<TLE> pitti: ok
<pitti> wgrant: thanks muchly
<\sh> tomreyn, did you encounter d0od@freenode and ask him about the bugs?
<wgrant> Only because nobody else is :)
<cjwatson> well, yes ...
<ogra_> tkamppeter, it works fine from all other machines, it is a small printserver running cups it is attached to
<tkamppeter> ogra_, so than it probably has its firmware, supplied by the CUPS server to which it is connected. Your ARM box does not need to supply firmware to the printer then.
<ogra_> tkamppeter, ipp://printsrv.local:631/ipp is what i use on the other machines, the machine i have the issue with is just a new install that does not have the binary bits
<ogra_> oh
<ogra_> i needed it in the past
<tkamppeter> ogra_, the server should also provide the driver for the printer. You can print through a raw queue from the client. If the server's queue is intentionally set up raw, you need a free-software-only (as there is no closed-source plug-in from HP for ARM) driver. This driver is foo2zjs. You have to switch the driver of the queue from hpcups or hpijs to foo2zjs.
<ogra_> ok, i will try
<tomreyn> \sh: no, can you explain how s/he relates to this package?
<tomreyn> \sh: i looked at their mailing list archive and found this, though: https://lists.launchpad.net/weather-indicator-team/msg00096.html
<\sh> tomreyn, https://launchpad.net/indicator-weather <- this is the main project page of indicator-weather and d0od is the maintainer ... so eventually he's not aware of the bugs reported on the package in ubuntu
<tomreyn> \sh: nickserv tells me d0od: Last seen  : Sep 27 08:49:28 2011 (4 weeks, 1 day, 02:33:00 ago)
<tomreyn> I assume he will be one of the "developers [who] either have lost the will to continue contributing or have lack of time".
<\sh> tomreyn, yeah looks like...
<\sh> tomreyn, just file the removal of this package
<tomreyn> \sh: I still can't spot the reference to d0od on https://launchpad.net/indicator-weather - can you help me? I see "Vadim Rutkovsky" listed as "driver", whose IRC nickname would be roignac.
<\sh> tomreyn, when you click on the maintainer on the project page
<\sh> d0od
<\sh> Driver:
<\sh> libohso-maintainers
<\sh> tomreyn, see privmsg
<ogra_> tkamppeter, i got it working now, thanks for the help !
<ogra_> GRRR
<ogra_> so i spent 2h to get my printer working on my netbook for printing my eticket ... just to find out that us-airways does the checking through a flash based page !
<ogra_> *checkin
<ogra_> grmbl, silly world
<ogra_> (which is indeed not helpful on arm where no flash plugin exists)
<OdyX> .oO(lightspark ?)
<ogra_> OdyX, doesnt help at all there is no accel for it for arm
<ogra_> it runs but with 0.5fps or less
<OdyX> ogra_: compiled against libgles though
<ogra_> yes, its still 100% SW rendering
<cjwatson> LP builders are gradually coming back online now
<ogra_> oh, sweet, dexconf is finally dead !
<highvoltage> that must be from before my time, I don't even know what dexconf is.
<hyperair> debconf X frontend?
<highvoltage> ah
<hyperair> at least, i think.
<hyperair> http://manpages.ubuntu.com/manpages/hardy/man1/dexconf.1.html
<hyperair> highvoltage: generate Xorg.conf, apparently.
<ogra_> right
<ogra_> it used to be the connecting bit between xorg and debconf
<Laney> it's been removed a few months
<ogra_> one of the worst hacks debian ever had
<Laney> but yeah, yay
<pitti> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ogra_> Laney, i only saw tjaalton's bug right now, i used to follow xorg, but not anymore
<Laney> at least in debian it was ~february ish
 * dholbach hugs pitti
 * pitti hugs back dholbach
<Daviey> mterry: heya, would you be able to look at bug 875818, please?
<ubottu> Launchpad bug 875818 in libnetfilter-conntrack (Ubuntu) "[mir] libnetfilter-conntrack" [High,New] https://launchpad.net/bugs/875818
<Daviey> it's dep-waiting dnsmasq
<mterry> Daviey, sure!
<Daviey> mterry: thanks!
<slangasek> RoAkSoAx: you have redhat-cluster's merge marked as 'please do not touch', and people have been complying and not touched it since 2009... :)  Is that something that should get merged this cycle?
<RoAkSoAx> slangasek: yes, we have a newer version in Ubuntu  3.0.12-2ubuntu5 and merges.u.c shows 3.0.2-5
<RoAkSoAx> slangasek: so it might be a bug from merges.u.c?? on the other hand, this cycle we are planning a new upstream release that contains huge changes in comparison to the old rhcs source, and we are wroking with the debian maintainer
<slangasek> RoAkSoAx: oh, interesting
<slangasek> cjwatson: ^^ for some reason merges.u.c doesn't know we have a new upstream version of redhat-cluster in precise?
<cjwatson> RoAkSoAx: yes, can you file that on bugs.launchpad.net/merge-o-matic?
<RoAkSoAx> slangasek: that;'s not only bveen in precise but since oneiric
<RoAkSoAx> cjwatson: sure
<cjwatson> since maverick
<jdstrand> it would be ideal to get ruby1.8 demoted
<jdstrand> wrong window
<apw> ev, just doing and install and tried the > next to teh current operation which opened a text panel, very small and 100% empty for then and forward; i presume that is not expected
<slangasek> apw: hey, do you know if aufs implements inotify on the backend?
<apw> slangasek, unsure why ?
<slangasek> apw: because upstart doesn't manage to automatically reread /etc/init from a LiveCD
<apw> slangasek, lets say "probabally" is most likely the answer
<apw> slangasek, ahh well we know that overlayfs is not doing inotify quite right
<apw> slangasek, and that is what is in use on the livecds
<slangasek> this causes install failures if you want to configure a package in the livefs that adds an upstart job
<slangasek> apw: oh, we're using overlayfs now, not aufs?  alrighty
<slangasek> is that inotifilessness tracked anywhere?
<apw> slangasek, awsome, so glad that we test things before release
<slangasek> it's not a common scenario
<apw> slangasek, ahhh probabally not actually, i was going to file a bug at release sprint and then went ill
<Daviey> mterry: bug 875818, should i just removed the versioned shlibs?  That version predates Lucid.
<slangasek> why are you installing a server into memory on a liveCD
<slangasek> etc
<ubottu> Launchpad bug 875818 in libnetfilter-conntrack (Ubuntu) "[mir] libnetfilter-conntrack" [High,Incomplete] https://launchpad.net/bugs/875818
<apw> slangasek, will get the bug filed and let you know the number
<slangasek> apw: ok.  I have a couple of prospective dupes once available :)
<apw> slangasek, deep joy :/
<mterry> Daviey, that could work.  Ideally whichever path is more palatable to the Debian maintainer so we can sync in future.  I'd suggest a .symbols file, but just having plain -V is quicker if you want to get something in now
<apw> slangasek, that reminds me, if the disk is not persistant you can use a commandline override to select aufs for a CD boot
 * apw forgets the exact incantation but its something like UNIONMOUNT=aufs
<apw> perhaps UNION=
<cjwatson> union=aufs
<slangasek> apw: filing that for future reference... I'm not sure the people hitting this bug are even meaning to do this
<slangasek> the bug reports are mostly pretty vague
<slangasek> I just happen to have one follow-up from someone who self-diagnosed correctly, and it matched what I had seen when doing ubiquity debugging
<apw> bug #882147
<ubottu> Launchpad bug 882147 in linux (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,New] https://launchpad.net/bugs/882147
<stgraber> that one kept us busy for a while at the release sprint ;)
<slangasek> oh, did it?
<slangasek> bdmurray: so there are bugs in launchpad that should be duped to bug #882147
<ubottu> Launchpad bug 882147 in linux (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,Triaged] https://launchpad.net/bugs/882147
<stgraber> slangasek: yeah, we noticed it when trying to debug ubiquity with a "tail -f /var/log/installer/debug" and didn't get anything :)
<slangasek> bdmurray: any "start: Unknown job:" error message received while running on the livefs
<bdmurray> slangasek: including persistent usb?
<slangasek> bug #857406 is an example of this... unfortunately there's no dpkg log, but the error message is in the bug description, and CasperVersion is set
<ubottu> Launchpad bug 857406 in rpcbind (Ubuntu) "Failed to install rpcbind" [Undecided,Incomplete] https://launchpad.net/bugs/857406
<slangasek> bdmurray: yes
<stgraber> slangasek: then noticed "watch -n1 tail /var/log/installer/debug" worked fine, inode numbers were identical too and eventually tracked it down to a overlayfs issue, then the kernel guys noticed it was the missing inotify support in overlayfs (or broken inotify support, can't remember the details)
<stgraber> slangasek: anyway, wasn't considered critical back then, just very annoying for debugers :)
<slangasek> bdmurray: is it practical to find the matching bugs?
<broder> ...huh, tail -f uses inotify now? i thought you had to pull inotail out to get that
<slangasek> stgraber: what broder said - kinda weird that tail needs inotify
<slangasek> but yeah
<bdmurray> slangasek: would they generally be package install failures? those get tagged but livemediabuilds don't so that would be a bit more challenging
<slangasek> bdmurray: I don't really know i they're package install failures; the one I know about was apparently filed by hand
<stgraber> stgraber@castiana:~/Desktop$ strace tail -f /var/log/syslog 2>&1 | grep -i notify
<stgraber> inotify_init()                          = 4
<cjwatson> tail -f inotify> changed in coreutils 7.5
<stgraber> inotify_add_watch(4, "/var/log/syslog", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
<stgraber> broder, slangasek: ^ :)
<cjwatson>   tail --follow now uses inotify when possible, to be more responsive
<cjwatson>   to file changes and more efficient when monitoring many files.
<bdmurray> slangasek: well I'll see what I can do
<broder> fancy
<slangasek> bdmurray: thanks
<cjwatson> if inotify_init returns <= 0 it falls back to polling
<cjwatson> I'm guessing that in this case support is present but brokene?
<cjwatson> *broken
<slangasek> cjwatson, stgraber: how future
<apw> cjwatson, right present but not working as one might expect
<slangasek> present because the kernel supports it, broken because the fs doesn't
<stgraber> apw: do you remember if inotify_add_watch actually fails on overlayfs?
<apw> stgraber, no i don't think so, the issue is that things get attached to the wrong versions i think
<apw> stgraber, anyhow its on my list to investigate with upstream
<cjwatson> slangasek: inotify_init only tells you if the kernel supports it; but it also calls inotify_add_watch and falls back to polling if *that* fails, and that should be able to tell whether the fs supports it
<slangasek> cjwatson: ah, sure
<stgraber> cjwatson: except that on this specific case, inotify_add_watch actually added a watch on the read-only branch instead of the copy-on-write one, so didn't fail, just wasn't doing anything useful :)
<cjwatson> right, indeed
<bdmurray> slangasek: so bug 8733358 seems like a likely duplicate - correct?
<ubottu> Error: Launchpad bug 8733358 could not be found
<bdmurray> bug 873358
<ubottu> Launchpad bug 873358 in samba (Ubuntu) "package samba 2:3.5.11~dfsg-1ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/873358
<stokachu> vanhoof, yo s0n
<slangasek> bdmurray: 873358> yep!
<Sarvatt> stokachu: he's in st lucia for his honeymoon :)
<stokachu> Sarvatt, ahh finally tied the knot
<stokachu> is it normal for the builds in ppa to take anywhere from 1-2days to start?
<slangasek> not "normal", but there was a dispatcher problem earlier today which I think explains the current backlog
<stokachu> slangasek, ok thanks
<bdmurray> slangasek: well, I only found a couple
<slangasek> bdmurray: ah, alright
<slangasek> duping them?
<bdmurray> done
<slangasek> is this representable as a bug pattern?
<bdmurray> yes
<slangasek> cool... will you take care of that as well?
<slangasek> probably will only ever catch a small smattering of bugs... but they'll be among the more confusing for anyone to try to triage correctly :)
<bdmurray> slangasek: what package would 'start: Unknown job' be translated in?
<slangasek> translated?  I don't think we have any l10n for upstart messages
 * slangasek checks
<bdmurray> ah great
<slangasek> well, there are upstart.mo files in the archive.. so I guess that bears checking...
<Daviey> Can an AA promote libnetfilter-conntrack src and bin, based on bug 875818, please?  (-dbg package doesn't have anything holding it in main tho.)
<ubottu> Launchpad bug 875818 in libnetfilter-conntrack (Ubuntu) "[mir] libnetfilter-conntrack" [High,Fix committed] https://launchpad.net/bugs/875818
<barry> so, here's a packaging question i'm not sure how to handle.  i'm working on a new claws-mail-extra-plugins that re-enables gdata_plugin from upstream cvs.  the source branch itself has directories for each of the individual plugins (21 of them).  i `bzr rm` the old directory, `bzr add` the new cvs snapshot directory.  none of the d/* files really need to be changed.  the problem is getting a new orig.tar.gz with the new
<barry> subdirectory. this will be a 2ubuntu2 package so the previous upload already got c-m-e-p_3.7.10.orig.tar.gz.  what's the right way to build the source package for this scenario?
<Laibsch> Can somebody please confirm the lucid task for bug 881806 so it doesn't fall through the crack again?
<ubottu> Launchpad bug 881806 in icecc (Ubuntu) "icecc does not remove cleanly" [Undecided,Fix released] https://launchpad.net/bugs/881806
<slangasek> bdmurray: there are a few translations, it seems. http://paste.ubuntu.com/719918/
<tumbleweed> Laibsch: approved
<Laibsch> thanks
<slangasek> Daviey: done
<Daviey> slangasek: thanks!
<slangasek> barry: why the 'bzr rm && bzr add'?
<barry> slangasek: udd ;)
<slangasek> barry: that sounds like a wrong turn to me, but maybe I don't understand what you're doing
<barry> slangasek: but i'm not particularly wedded to using udd for this task, if `apt-get source` is a better route
<slangasek> so you've bzr rm'ed the upstream directory, and bzr add'ed another one with the same name?
<barry> slangasek: bzr rm gdata_plugin-0.2; bzr add gdata_plugin-20111026cvs
<slangasek> to your root question, there are two ways to do this
<slangasek> 1) use the -2ubuntu2 package version you already mentioned, and carry the cvs snapshot bits entirely in the .diff.gz
<slangasek> 2) concoct a new upstream version number (following the rules embodied in dpkg --compare-versions, to avoid it interfering with future upstream releases), generate a "release" tarball for this version by whatever means you find appropriate, and import it with bzr merge-upstream
<slangasek> and then use -0ubuntu2 as the revision number
<slangasek> personally, given that it's CVS, I would go with option 1)
<tumbleweed> as a variation on 1: it's a 3.0 (quilt) package, one can include the directory in debian and move them around in debian/rules
<slangasek> tumbleweed: that's only a variation in that it's technically no longer a diff.gz :)
<tumbleweed> slangasek: well, the question is, are the changes to that directory representable as a patch
<barry> i think the one complication is that i can't have both directories when the build starts (the current rules don't support that, not that i couldn't change them)
<barry> tumbleweed's suggestion sounds rather appealing actually :)
<tumbleweed> yes, if you are going with 1, either you want to use the old version in the directory name rather than the new one, or you want modifications to rules
<slangasek> oh, so the directory name changes and you can't have them both present? yuck
<slangasek> barry: what happens if you just push the cvs snapshot into the directory named gdata_plugin-0.2?
<barry> slangasek: right
<barry> slangasek: hmm, that might work too actually.  it'd be a little white lie, but i can make that clear in d/changelog or in a readme
<barry> and i think those changes *would* be representable as a diff
<tumbleweed> think of it as bugfixes to 0.2 :)
<barry> tumbleweed: yeah :)
<barry> tumbleweed, slangasek thanks.  i'll try that and see how it goes
<slangasek> barry: cool
<GTRsdk> Where is the Ubuntu Unity Dash icon stored on the hard drive?
<Ursinha> GTRsdk, maybe you can find that out by dpkg -L package
<GTRsdk> It appears that the icon is not in the package
<GTRsdk> I am guessing it is the distributor logo (Ubuntu logo) that is what is being used
<stokachu> is /etc/default the equivalent to /etc/sysconfing on fedora/rhel?
<slangasek> SpamapS: are you continuing to chase bug #859075?
<ubottu> Launchpad bug 859075 in sysvinit (Ubuntu) "Oneiric does not shutdown" [High,Confirmed] https://launchpad.net/bugs/859075
#ubuntu-devel 2011-10-27
<TheMuso> slangasek: Ok so I am working on the separate libpulsedsp package for pulse, however it turns out that pulseaudio-utils has lintian overrides for libpulsedsp.so. How can these effectively be used in the case of a multi-arch same package like libpulsedsp?
<slangasek> TheMuso: you can use a wildcard for the path, so */libpulsedsp.so in the libpulsedsp package
<TheMuso> slangasek: Thats not what I was thinking of. I am aware of the wildcard, but the override file is owned by both the amd64 and i386 version of the package... How does that get resolved?
<slangasek> TheMuso: as long as the file contents are the same, the file is shared
<TheMuso> slangasek: Oh ok great.
<TheMuso> Anybody else on oneiric using sbuild and schroot for precise finding that dbus is starting in their chroot for any packages depending on dbus?
<broder> ooh, does that mean that upstart chroot support is working now?
<TheMuso> I don't know.
<TheMuso> But I earlier found that I still had lots of chroots mounted, because they had running processes in them.
<broder> hmm...so schroot tries to kill off all processes in the chroot before unmounting it
<broder> but /etc/init/dbus.conf has respawn
<TheMuso> Haven't looked into it, but that sounds possible.
<broder> does your chroot have a /usr/sbin/policy-rc.d file?
<TheMuso> just a sec, I'll check.
<TheMuso> I don't appear to.
<broder> you probably want one
<broder> something like "#!/bin/sh\nexit 101"
<broder> and chmod +x it
<TheMuso> Oh ok.
<TheMuso> Thanks
<broder> (see also the invoke-rc.d manpage)
<broder> mk-sbuild should handle all of that setup, though, for future reference
<TheMuso> I find mk-sbuild a bit too generic for my needs, so I've got scripts that derive from it. I'll just extend them. :)
<Laibsch> good morning
<Laibsch> does the verification-done-lucid tag also trigger the "green" state in http://people.canonical.com/~ubuntu-archive/pending-sru.html?
<RAOF> I believe the answer to that is ?yes?.
<Laibsch> OK.  I set it on a bug about 17-18 hours ago, but it did not trigger anything so far.
<pitti> Good morning
<ajmitch> morning pitti
<slangasek> TheMuso, broder: yes, chroot support works in upstart now, and policy-rc.d is the right workaround for a build chroot :)
<micahg> TheMuso: can you extend the core-dev membership in ubuntu-audio-dev
<TheMuso> micahg: sure
<TheMuso> micahg: For what reason?
<TheMuso> In any case, it should never expire, so changing.
<micahg> TheMuso: because I got a nice e-mail asking to have it extended :), thanks for the permanent membership :)
<dholbach> Guten Morgen Berlin! :)
<gs_> hello all. I am doing a project in which I need to read .deb files. Is there any library or interface available which I can use in my program to read these files. If this is a wrong channel Please forgive me and if you could suggest me some other channel for query regarding apt ?
<gs_> hello all. I am doing a project in which I need to read .deb files. Is there any library or interface available which I can use in my program to read these files. If this is a wrong channel Please forgive me and if you could suggest me some other channel for query regarding apt ?
<gs_> Please reply
<dholbach> gs_, which information do you need?
<RAOF> gs_:  You'd be looking for libapt and friends.  Or just extracting them; they're simple archives.
<StevenK> gs_: If you're an Ubuntu machine, 'man 5 deb' tells you about .deb files
<StevenK> If you're *on* an Ubuntu machine
<RAOF> Or if you *are* an Ubuntu machine that would work, too.  (If you *are* an Ubuntu machine, awesome!  Please tell us where the AI research has succeeded ?)
<ajmitch> heh
<gs_> dholbach: I need information regarding some library or interface which can be used for reading debian files
<gs_> Actually I am writing a system restore like application for ubuntu
<gs_> which will save the current state of packages and then restore them when needed
<gs_> RAOF: ok. using these libraries I can get list of the files which a package is intending to install ? and If i need details about the contents of those files then ?
<dholbach> gs_, sorry, I meant: which information in the packages are you after?
<RAOF> gs_: Probably, but I wouldn't do it that way; I'd just expand the .deb and list the files in the data.tar.*
<gs_> dholbach: I am looking for list of files in the package and their contents so that I can determine what changes have occur to the system
<gs_> RAOF: so we can convert .deb file in tar.gz archive ?
<RAOF> gs_: Note that what you want to do is impossible in general; the packaging can (and will in some circumstances) use programatic means to create or modify files on the filesystem.
<ajmitch> also the original .deb may not be on the system still
<RAOF> gs_: The .deb file contains two .tar.* files; control and data.
<Chipzz> RAOF: md5sums?
<ajmitch> iirc not every package has a list of md5sums
<Chipzz> RAOF: this isn't very ingrained in debian, but IIRC in rpm based distro's ALL files have their md5sum stored
<gs_> RAOF: like when we open a deb file in gdeb we can get the list of all files so I thought there might be an existing library for doing that
<Chipzz> ajmitch: yes and that's a defect imo
<RAOF> gs_: Yes, there is; tar.
<RAOF> Chipzz: Does the rpm packaging format not have a way of generating files at install time?
<Chipzz> ajmitch: regardless, merely pointing out that RAOF's statement is incorrect and it is possible in theory
<Chipzz> RAOF: at does; it also has the concept of ghost files which debian lacks
<gs_> OK. So there is a tar and then how will I read that tar ? After extracting it ?
<Chipzz> s/debian/dpkg/
<gs_> Ya I know the package file might not be on the system. In that case I think I would need to download the package file from internet ?
<RAOF> Chipzz: No, it's not possible in theory.  I've worked on packages whose postinsts process existing files on the filesystem and incorporate state from other files, then write out a new conf file.
<RAOF> Chipzz: That package cannot have a pregenerated md5sum for all the files it generates.
<ajmitch> gs_: in terms of libraries, I know of python-debian which you can use to inspect the contents of a .deb
<Chipzz> RAOF: that statement is simply silly; you can't account for /home/* either
<gs_> ajmitch: Could you please give me some link related to that library ?
<RAOF> Chipzz: True, but that's not owned by the package manager.
<Chipzz> RAOF: you could argue that config files aren't either
<gs_> Could you please provide me some suggestions regarding how to implement a system restore like application for ubuntu
<gs_> I have two approaches
<gs_> in one approach I will use a copy-on-write and save-on-delete approach
<gs_> so that I will take care of all the files in system directories
<ajmitch> gs_: I'd have to look on google for info about it, but the package is just named 'python-debian', I don't know what is available as a library for other languages
<RAOF> If you're allowed to use magical filesystems, then btrfs + apt-snapshot-btrfs does all this for you; it takes a snapshot of the system state on each apt transaction that you can roll back to.
<gs_> ajmitch: ok I will search for that thanks for helping.
<gs_> ok thats quite nice, how much space would that system occupy ?
<gs_> But that would require user to reinstall the whole system with "/" on brtfs ?
<RAOF> It's copy-on-write, so roughly the changed set size.
<RAOF> It would indeed require / to be a btrfs partition.  It also has other constraints (there need to be appropriately named subvolumes, home needs to be a subvolume)
<gs_> ok, that would be not good as users need a reinstall for using the system
<gs_> If I implement that approach in my program would that be possible
<gs_> I can put hooks to the filesystem
<gs_> so whenever a file is written I can make a copy
<gs_> Or I can have this package approach
<gs_> in this approach I will create a package whenever user creates a restore point
<gs_> I will use this package to restore the system to an earlier state
<ajmitch> if you're looking at creating a package, take a look at dpkg-repack
<gs_> Ok thanks and could you please provide some feedback on my approach
<RAOF> I suspect it might be easier to do something similar to a combination of etckeeper and oneconf+snapshotting.
<RAOF> ie: store a list of all the packages which are installed + all the modified stuff (/etc /var)
<gs_> RAOF : ok, like these files are in /var/lib/dpkg/info
<gs_> ?
<gs_> now for the modified stuff /etc /var is it better to create a separate package or implement a copy-on-write approach?
<Chipzz> gs_: imo your approach is not the best approach anyway
<Chipzz> files in /usr aren't interesting anyway
<micahg> slangasek: you made a change to pygments back in jaunty that suggested python-chardet shouldn't be a recommends: https://launchpad.net/ubuntu/+source/pygments/0.10-1ubuntu2, python-chardet is now in main, do you still feel it shouldn't be a recommends?
<Chipzz> if those change, the change is probably invalid, and you probably want to restore from the package anyway, so you probably shouldn't care about these
<gs_> chipzz : So please could you provide me some suggestions in how can I improve this
<slangasek> micahg: I feel nothing about it, do whatever you think is best ;)
<micahg> slangasek: thanks :)
<Chipzz> you probably want to focus on config files, and maybe files in /var
<Chipzz> I would look into ucf and try to integrate with that
<gs_> ok so files in /var are more imprtant and /etc also
<Chipzz> and figure something out for other files in /etc that aren't managed by ucf
 * ajmitch rather likes etckeeper
<gs_> sorry but what is ucf ?
<Chipzz> dpkg --get-selections will give you a list of packages installed
<Chipzz> apt-cache show ucf?
<Chipzz> /srv, /usr/local and /opt are interesting candidates too
<gs_> ok thats easier
<gs_> but like if some of the files installed by a package are damaged then ? Do I need to recopy those files or reinstalling the package would be a better option ?
<Chipzz> users aren't supposed to write in /usr, since that's owned by the package management system; if they do, they're probably wrong, for example they have compiled from source and installed in /usr, which is a cause of havoc anyway, and most likely the kind of situation you want to recover FROM, not TO
<Chipzz> gs_: like I pointed out, if those files are damaged, you can restore them from the package; which is exactly why they are not interesting
<gs_> Ok so I would ignore the files present in /usr
<gs_> or better I could clear /usr to a fresh installed system state
<gs_> and if the files in /bin or /sbin are damaged then ?
<gs_> I would get a list of installed packages and then reinstall those packages ?
<gs_> Better I need to see which packages have missing files
<gs_> and so those only *system packages* need to be downloaded and reinstalled ?
<gs_> Also is there any documentation describing exact steps performed by the system when any package is installed ?
<gs_> or I could  see that by browsing apt-get or dpkg code ?
<fhd> How is the Ubuntu stance towards Vala? Good idea for apps primary targeting Ubuntu?
<fhd> Don't want to alienate. The typical choices seem to be C++ or Python.
<cjwatson> fhd: well, it's listed on developer.u.c - http://developer.ubuntu.com/resources/programming-languages/vala/
<cjwatson> fhd: I believe Unity lenses are typically written in Vala, for example
<fhd> cjwatson: Java is also listed, haven't seen many Java apps in Ubuntu
<fhd> cjwatson: But if the Unity guys use it...
<cjwatson> fhd: it depends where you look
<Daviey> I can't understand why ruby-stomp has seeminly never been in Ubuntu.  Is it blacklisted?
<Daviey> https://launchpad.net/ubuntu/+source/ruby-stomp , no publishing history
<Daviey> Been in sid since Jan 2009
<geser> Daviey: https://launchpad.net/ubuntu/+source/libstomp-ruby ; the source package got recently (this month) renamed from libstomp-ruby to ruby-stomp
<cjwatson> Daviey: it's not blacklisted, but attempting to sync it says http://paste.ubuntu.com/720566/
<cjwatson> we have what might politely be called an abysmal lack of crowdsourcing for this kind of thing
<cjwatson> so basically somebody needs to say "yes, dear archive admins, please throw away the existing Ubuntu-specific package and replace it with this one with a different source package name from Debian"
<cjwatson> well, not Ubuntu-specific, Ubuntu-modified
<Daviey> cjwatson: it needs AA intervention, or can i just sync with --force?
<Daviey> (geser: thanks)
<cjwatson> Daviey: you can syncpackage it if you've checked that none of the Ubuntu modifications are still needed
<cjwatson> (although it'll land in the NEW queue, but that's trivial)
<Daviey> cjwatson: Great, thought so - thanks
<cjwatson> it wasn't just an upstream update, James made some packaging changes too
<Daviey> Yeah, seems i sponsored it :)
<cjwatson> unfortunately I'm not sure syncpackage notices the Ubuntu modifications to matching binary packages
<cjwatson> which is IMO a syncpackage bug if true
<cjwatson> yeah, doesn't require --force, buggily
<Daviey> Thanks.
<\sh> hmm...anybody with upload powers can use syncpackage now? (instead of using requestsync)
<Daviey> \sh: Yes, but requestsync is still needed for sponsored sync's
<\sh> Daviey, sure, what I mean is i.e. for universe uploaders who are doing the merge/sync  run now
<Daviey> \sh: yup
<\sh> Daviey, nice :)
<Daviey> \sh: $ syncpackage -d (wheezy|sid) -r precise foobar
<cjwatson> we should update docs and stuff
<cjwatson> there are still some limitations, e.g. not usable for sponsored syncs
<Daviey> and no karma.. "oh well"
<\sh> Daviey, no need to sign ? or does it do it automagically?
<cjwatson> no need to sign
<cjwatson> it doesn't sign, it copies the publishing record from Debian
<Daviey> Incidently there is the 'beta' webui method, https://launchpad.net/ubuntu/precise/+localpackagediffs .. a bit whizzy for some.
<\sh> let's try :)
<\sh> so I need --force to overwrite ubuntu modifications
<\sh> cjwatson, what does this mean: syncpackage: Source package gauche-c-wrapper is blacklisted.
<cjwatson> an obscure way of saying that it has Ubuntu modifications which need to be reviewed.  Use --force
<cjwatson> Daviey: please don't use or recommend that - it doesn't and can't apply Ubuntu-specific policy
<cjwatson> (well, s/can't/won't/ perhaps)
<Daviey> cjwatson: wow, it doesn't do ACL?
<cjwatson> there is more policy than ACL
<cjwatson> it can't do things like handling packages with Ubuntu-specific modifications with more care
<cjwatson> use the API tool and pretend the UI doesn't exist
<Daviey> cjwatson: You mean it doesn't give a warning to say, "Are you sure you want to overwrite ubuntu changes?"
<cjwatson> no
<cjwatson> essentially because the way to detect that isn't particularly consistent across derivative distributions and Launchpad officially doesn't know about it
<Daviey> Does syncpackage care greater than checking for 'ubuntu' in the version string?
<cjwatson> that's what it does, but Launchpad doesn't do that
<cjwatson> in general we can do much more sophisticated things using an API tool because we don't have to make them fully general for all derivative distributions
<cjwatson> (+localpackagediffs was designed principally for Ubuntu derivatives and requested by Linaro, not for us)
<cjwatson> oh, syncpackage also detects fakesync-requiring situations, I don't think +localpackagediffs does (or if it is it's less helpful about it)
<cjwatson> and syncpackage allows you to sync from suites other than the single nominated "derivative parent" suite (currently Debian testing)
<cjwatson> and deals with closing bugs which I don't think +localpackagediffs currently does
<cjwatson> etc.
<Laney> think it got that one
<Laney> well, you can't nominate an additional bug
<cjwatson> could be
<TLE> pitti: hey, we saw some lang packs in -proposed, are they all good to go?
<pitti> TLE: good for testing, anyway, yes
<pitti> German looks fine
<TLE> pitti: great, thanks
<SpamapS> slangasek: re bug 859075 , I have laid no claim to it, though I do think its something wrong with the order in which we bring down the network and unmount things.
<ubottu> Launchpad bug 859075 in sysvinit (Ubuntu) "Oneiric does not shutdown" [High,Confirmed] https://launchpad.net/bugs/859075
<doko> pitti, bdmurray: why do we still get reports like https://bugs.launchpad.net/ubuntu/+bug/882445?
<ubottu> Launchpad bug 882445 in Ubuntu "package openjdk-6-jre 6b23~pre10-0ubuntu5 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New]
<pitti> we can write a pattern for it, to avoid further reports
<pitti> I'm fairly sure I've seen that --fsys-tarfile bug somewhere
<pitti> let's take bug 773172
<ubottu> Launchpad bug 773172 in update-manager (Ubuntu) "corrupted filesystem tarfile - corrupted package archive" [Undecided,Expired] https://launchpad.net/bugs/773172
<pitti> doko: added bug pattern, closed as dupe
<doko> pitti, thanks
<zyga> did postgresql change the default listen port for 9.1?
<zyga> it was 5432 and now I can see 5433
<pitti> zyga: no; presumably you still have an 8.4 cluster around which is on 5432; check pg_lsclusters
<zyga> ah
<zyga> pitti, so after having both installed I need to tweak something to get the default port back
<zyga> yeah, I have 5433 used now, I removed my 8.4 cluster earlier today
<zyga> thanks
<Daviey> Anyone know of a prior example of an SRU introducing a new src package?
<Daviey> (as a dep)
<Daviey> Or rather, the SRU requiring a new source package which is a dep.
<SpamapS> Daviey: meaning the src package would effectively be "NEW" for -proposed ?
<Daviey> SpamapS: yes sir
<tumbleweed> talking of this, can an AA process bin-NEW for my botan1.8 SRU?
<geser> Daviey: I guess you would need a good rationale for this
<Daviey> geser: that some upstreams are really bad at following their own policy? :)
<Daviey> right, soren? :)
<SpamapS> Daviey: how big is this new dependency? Might it work embedded in the source?
<soren> SpamapS: I dont' see how that would be preferable.
<SpamapS> soren: if its a 1 file python module or something that is better.
<soren> Daviey: We have had kernels come in this way. Backported kernels from newer releases back to the most recent LTS.
<Daviey> SpamapS: yeah, checked that.. it's not just one .py
<Daviey> SpamapS: but embedding a whole module, need to start worrying about upgrade paths.
<soren> SpamapS: Even then, it seems questionable.
<soren> Precise will have it in a separate package. That's what we'll test.
<soren> Right?
<soren> And once validated, will backport to Oneiric.
<soren> I'm just not sure I think breaking two rules (embedding "foreign" libraries in other source packages + not staying close to how you're solving the same problem in the dev release) is necessarily better than breaking something that isn't even a rule, AFAICT (uploading new source packages to -proposed).
<cjwatson> yeah, I'm not aware of a rule against new source packages in -proposed; it's certainly unconventional but not forbidden TTBOMK
<cjwatson> if the purpose of the fix meets the SRU rules, then I wouldn't exclude it simply on the basis of requiring a new package
<cjwatson> although it would have to have a good reason
<soren> Yeah.
<soren> ...and avoiding embedding it in the source package that depends on it isn't that good a reason, IMO.
<soren> Didn't the openss{l,h} blacklist stuff come in its own source package?
<cjwatson> yes
<cjwatson> albeit through -security not -proposed, but whatever
<soren> Yeah, but that usually has a higher barrier of entry, not lower.
<soren> Anyway, I think we agree :)
<slangasek> SpamapS: well, a) one of the commentors is having the problem with USB disks, not network mounts, b) we've been through all this before with network-manager being killed before umountnfs.sh and that's been fixed - so if something's regressed I think it's on the NM side of the equaton
<Wismon> Hi, I'm new to Ubuntu development (bug fixing) and fixed a bug the other day, uploaded my branch to Bazaar and made a merge request. I'm just wondering what the next logical step would be? I read about the sponsoring process but have to admit I don't really get how it works in reality. I just don't know if I should simply wait for now or if there's something more I should do. Maybe someone more knowledgeable than m
<Wismon> e can point me in the right direction?
<Wismon> </wall of text>
<SpamapS> slangasek: I do think that eventually we'll find the problem outside of sysvinit. I have it assigned to sysvinit because thats where the debugging has led the investigation thus far
<slangasek> SpamapS: ok
<Riddell> Wismon: is the package has a likely team or person who might upload it you can politely ping them
<Wismon> Riddell: Hmm, I think I found one person... Thank you, I'll try that!
<kirkland> mterry: hiya
<mterry> kirkland, hi!
<kirkland> mterry: fyi, ecryptfs-verify-private just landed in precise
<mterry> kirkland, oh, that didn't get into oneiric?
<kirkland> mterry: nope, sorry
<mterry> hmm
<kirkland> mterry: needed an FFE
<kirkland> mterry: i never filed it, don't know if anyone else did either
<kirkland> mterry: was it you who was asking for this?
<kirkland> mterry: or someone else?  seb maybe?
<mterry> that means it's probably easy to break your system in oneiric by enabling autologin (the patch I added to gnome-control-center used verify-private if available)
<barry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<smoser> am i the only one having problems ssh to bazaar.launchpad.net ?
<smoser> (ie, i can't push a branch)
<smoser> $ ssh bazaar.launchpad.net
<smoser> ssh_exchange_identification: Connection closed by remote host
<jelmer> smoser: it appears to be fine here ("No shells on this server.")
<smoser> carp.
<smoser> it doesn't like me from 2 different systems (same key/user, but its not just my laptop thats foobarred)
 * micahg hugs barry for the mail to UDD
 * barry is glad he remembered!
<Daviey> smoser: odd, i am getting the same.. I used to get No shells on this server.
<Daviey> dave@voodoo:/tmp/test$ bzr push lp:~davewalker/+junk/delete_me
<Daviey> Created new branch.
<Daviey> dave@voodoo:/tmp/test$ ssh davewalker@bazaar.launchpad.net
<Daviey> ssh_exchange_identification: Connection closed by remote host
<smoser> others in #launchpad  are echoing my issues.
<Daviey> smoser: but push seemed to work
<smoser> it was refusing 30 seconds ago
<smoser> but now seems good.
<rbasak> slangasek: I was just looking at bug 881579 and noticed that you did a merge today, but the bug is still present. It's a missing '\' in debian/samba.if-up
<ubottu> Launchpad bug 881579 in samba (Ubuntu Precise) "syntax error in /etc/network/if-up.d/samba" [High,Confirmed] https://launchpad.net/bugs/881579
<rbasak> slangasek: I was going to fix it but if you're working on it anyway...
<slangasek> rbasak: hah, fail.  Sorry for not noticing that.  Feel free to fix, I've moved on to other things already
<rbasak> slangasek: well I'm going to need you to sponsor it anyway... :)
<slangasek> rbasak: ok, pushing
<rbasak> slangasek: thanks!
<TheMuso> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, TheMus
#ubuntu-devel 2011-10-28
<bjsnider> doko_, ping
<TheMuso> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMus, barry
<Darxus> I have spamassassin building on launchpad automatically using the /debian/ info that I've included in upstream trunk.  But I can't get it to build from the command line.  "debuild -us -uc" is complaining about a lack of an .orig.tar.gz file.  I've seen some mention of generating that .orig.tar.gz file, but not how.  What am I missing?
<bjsnider> Darxus, tar xcf spamassassin_version.orig.tar.gz path/to/directory/with/code
<Darxus> I was just going to try that.  There's no.. flag to some build command to do it?
<bjsnider> you also want to --exclude=debian what any git/svn
<Darxus> bjsnider: No I've actually synced the debian build directory with spamassassin's trunk.
<Darxus> Looks like it's working though, thanks.
<bjsnider> the debian directory shouldn't be in the orig tarball
<Darxus> It is.
<Darxus> Well.
<Darxus> Okay.
<bjsnider> that's what the debian.tar.gz, which gets created automatically, is for
<Darxus> Yeah I misunderstood what you were saying.
<Darxus> #bzr mentioned instead of manually running tar you can use the -sa option to debuild.  Which isn't very documented.
<bjsnider> the whole point of the orig tarball is that it's the unmodified code, so if you put the packaging scripts in there, you can't call it orig anymore
<Darxus> Oh, no, I'm confused again.
<Darxus> Well, the original unmodified code actually has a copy of the packaging scripts.  I synced it from the .deb package to upstream trunk.
<Darxus> To ease automated building on launchpad.
<Laibsch> SpamapS: I think you recently ran into problems with suspend, didn't you?
<bjsnider> Darxus, are those the scripts you're actually using?
<Darxus> bjsnider: Yes.
<StevenK> Darxus: It is documented. debuild's manual page says it will also take the same options that dpkg-buildpackage does.
<jbicha> Darxus: generally, it's better not to have the debian/ directory upstream; it gets complicated if Debian, Ubuntu, or another similar distro needs to adjust the packaging
<bjsnider> Darxus, in the changelog, what is the date of the most recent entry before your changes?
<jbicha> Darxus: see https://help.launchpad.net/Packaging/SourceBuilds/Recipes to make building easy from two different bzr branches, one for upstream, one for debian/
<Darxus> bjsnider: Not sure I understand what you're asking.  Currently in trunk it's Sat, 14 May 2011 12:06:12 -0700, while I'm waiting for a commit of the change from v 3.3.2-2.
<bjsnider> so they haven't updated the build scripts in 5 months
<Darxus> jbicha: I think part of the reason I did this is because when I set it up, that couldn't handle importing debian packages that had two original tarballs, as the spamassassin one does since the rules were split out to a separate tarball.
<Darxus> bjsnider: Okay?  Still curious where you're going with that.
<bjsnider> there might be newer debian scripts in debian itself
<bjsnider> what's the rules tarball called?
<Darxus> bjsnider: There is.  I just filed a bug with a patch to apply the change.
<bjsnider> and if the ubuntu version of spamassassin has an ubuntu tag in it, eg. 0ubuntu1, there are ubuntu-specific changes you need to look at
<Darxus> It doesn't.  It hasn't for a long time.
<bjsnider> cool
<ScottK> Nope.
<ScottK> spamassassin is slightly complicated as it has both the spamassassin tarball and their rules tarball packaged together.
<bjsnider> i imagine the rules would be updated quite often
<ScottK> Once you've installed it, they update online.
<bjsnider> cool
<ScottK> The new tarball doesn't need to be updated more often than a new release.
<Darxus> Where is the.. source for the ubuntu package of spamassassin on launchpad?
<bjsnider> apt-get source spamassassin will grab that
<ScottK> It's the same as Debian's anyway.
<Darxus> Yeah but I want to look at it on launchpad.  I recall there being errors on importing it or something, related to the multiple original tarballs.
<ScottK> Perhaps the bzr branch for it, but that doesn't affect Ubuntu.
<Darxus> ScottK: Maybe?  Where is that?
<ScottK> Source is at https://launchpad.net/ubuntu/+source/spamassassin
<ScottK> bzr branch is at https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/spamassassin/precise
<ScottK> The branch is way out of date.
<ScottK> But that's not relevant for the Ubuntu archive.
<Darxus> Yeah, I was wondering where the log is showing the import errors for lp:ubuntu/spamassassin.
<Darxus> I did get the package building locally from spamassassin trunk, documented at the bottom of http://wiki.apache.org/spamassassin/SyncDebianPackaging
<twb> In a lucid upstart job, is the least-worst way to set euid to do "exec su nobody -c frobozzd" ?
<jbicha> could we get ubuntu-dev-tools synced from sid as distro-info conflicts with the current precise version?
<doko_> micahg, go ahead with the swig1.3 removal. looks I forgot to remove the source package
<micahg> doko_: yeah, I just realized, there's nothing to it (all build-deps except for 2 packages which I can fix/upload)
<dholbach> good morning
<tumbleweed> jbicha: sorry about that (ubuntu-dev-tools uninstallability) just did a new upload to sid (0.134) that can be synced as soon as lp picks it up
<bdrung> tumbleweed: can you SRU the sponsor-patch changes?
<Laney> will ubuntu-dev-tools ever stop being SRUed?
<SpamapS> when the sun rises in the west
<bdrung> Laney: when you write ten times more test cases that we currently have
<geser> Laney: short before precise release you can stop SRUing ubuntu-dev-tools (for oneiric) :)
<\sh> doko_, you have too many packages on MoM ;)
<tumbleweed> bdrung: I'll prepare an upload if you can find someone who'll verify it :)
<tumbleweed> Laney: it probably didn't help that we did a bunch of uploads during FF
<bdrung> Laney, tumbleweed: without the upload during FF, we wouldn't have the support for syncs in sponsor-patch at all
<tumbleweed> also true. We approved those for a reason...
<micahg> barry: still piloting?
<barry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMus
<barry> micahg: oops
<micahg> barry: care to sponsor something anyways?
<barry> micahg: sure.  i'm just about to head to lunch though.  is it urgent?
<micahg> barry: after lunch would be fine :)
<barry> cool :)
* infinity changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: none
<micahg> cyphermox: would you mind if I merged xapian-core?  there's depwait on it in precise
<micahg> cjwatson: will you get mad at me if I create and leave NBS until after UDS (if I promise to fix for alpha1)?
<micahg> cjwatson: ooh, nevermind, no NBS :)
<cjwatson> micahg: no, but I may try to clean it up before you if you do ;-)
<cjwatson> speaking of
 * cjwatson processes the big pile of NBS removals now that the installer has built everywhere
<micahg> cjwatson: heh, I wouldn't mind help if I end up kicking off some transition :), but this case was a false alarm
<cjwatson> ok
<micahg> barry: when you get back, Bug #883112
<ubottu> Launchpad bug 883112 in python-cups (Ubuntu Precise) "python-cups no longer depends on libcups2" [High,Confirmed] https://launchpad.net/bugs/883112
<barry> micahg: thanks, i'm on it
<barry> micahg: fwiw, i actually can't reproduce the bug in an oneiric chroot, but i'm still okay with uploading the fix
<micahg> barry: you get a depends in an oneiric chroot?
<micahg> it's not in the release version of python-cups
<micahg> barry: you probably can't reproduce since libcups2 is installed by default
 * micahg guesses severity should be medium then...
<barry> micahg: that could very well be!  the depends did show up, so the patch looked good and i uploaded it
<micahg> barry: thanks!
<barry> np!
<micahg> gah, the ball was dropped on bug 881250...
<ubottu> Launchpad bug 881250 in tzdata (Ubuntu Precise) "Clocks in Ukraine move back October 30, 2011" [High,Triaged] https://launchpad.net/bugs/881250
<micahg> tremolux: ^^
<micahg> slangasek: ^^
<slangasek> micahg: have there been uploads?
<slangasek> I've never done a tzdata update personally, I'm not sure if there's a script to follow?
<micahg> slangasek: I don't know if anyone's seen the bug besides pitti and myself (I guess that's bad)
<micahg> slangasek: no uploads from what I can tell, I have no idea how it works either, it's usually tremolux sponsored by pitti, unfortunately, I'm trying to get an update out by eod, could you drive this?
<micahg> slangasek: a different update :)
<slangasek> micahg: I'm not sure that I'm going to be able to get to it
<slangasek> barry: ^^ could you have a look at this bug?  tzdata apparently needs updates for all supported releases today, because another clueless national government has changed their mind about clocks on short notice
<infinity> What a surprise.
<nigelb> WIN.
<nigelb> Which government?
<infinity> Ukraine.
<barry> \o/
<nigelb> \o/
<nigelb> Also, UDS is amazingly timed.
<nigelb> Its in that period where US is off DST and europe isn't.
<barry> slangasek: i can look into it, but i also have no idea how it works ;).  i'm in the middle of a bunch of related patches right now, but i can look at this next
<barry> er, not related to tzdata, related to each other :)
<infinity> I can poke at it if tremolux doesn't pop his head up and claim it in the next ~hour.
<nigelb> infinity: Glad to see you're back from vacation/away time :)
<slangasek> barry, infinity: ok, thanks - I can process the SRUs once uploaded
<barry> infinity: okay cool.  just follow up here if you do get to it so we don't step on each others toes
<micahg> pitti mentioned before they ussually migrate to -updates as soon as their verified (what that means idk)
<micahg> s/their/they're/
<slangasek> I would expect "verified" to be "builds, installs, tells you what time it is"
<infinity> Does it have to tell you accurately?
<barry> accurately for what frame of reference <wink>
<slangasek> yes, hence "tell you what time it is", not "tell you a time that it isn't"
<infinity> slangasek: Picky, picky.
<infinity> I'll go grab a snack and see if tremolux (nick hilight ahoy: tremolux, tremolux, tremolux) comes back.  If not, I'll get packaging.
<infinity> nigelb: A girl I met on said vacation gave me some sort of plague that I intend to bring to UDS.  I've since sworn off both vacations and women.
<nigelb> infinity: Oh no.
<nigelb> Ubuflu!
<sbeattie> infinity: we're grateful you haven't sworn off plagues.
<infinity> sbeattie: That would be a much more reasonable thing to do, and I'm hardly known for that.
<infinity> Anyhow.
 * infinity -> late lunch.
<tremolux> infinity, slangasek, micahg: hey all, here, I was traveling to a sprint and and now at a sprint and it's very consuming unfortunately, but I know we need these out..I can try to do these later tonight
<micahg> infinity: your incantation worked!
<tremolux> what is the timeframe, I can prepare the updates but just need sponsoring, and I can test them soon as they hit -updates
<tremolux> heh
<micahg> tremolux: well the change takes effect in <24 hours
<barry> i can certainly sponsor if no one else can, and slangasek can approve -proposed
<tremolux> barry: are you at home or in Orlando?
<tremolux> barry: (and thanks btw) :)
<barry> tremolux: still home.  i get there sunday night (after mark's talk).  you have the room to yourself for a few days :)
<infinity> I can push it through the queue if you can upload soonish.
<infinity> tremolux: Is there any particular trick to updating the package, or is it just pulling the latest upstream tarball and merging?
<infinity> tremolux: Cause if you can't get to it, I'm happy to.
<tremolux> infinity: it's a straight merge for everything but hardy, that one is a repack
<tremolux> infinity: you'd also want to make a test case and test  them all
<infinity> That second bit sounds like it's the real effort.
<tremolux> infinity: it's just slightly tricky, and I'm used to it myself
<infinity> tremolux: Why the repack?  Just because the hardy source format was a bit different, I guess?
<infinity> tremolux: Anyhow.  I'm happy to take the load off you and do the updates, if you want to do the testing?
<tremolux> infinity: yep
<tremolux> infinity: thanks! seriously :)
<tremolux> infinity: these might help: bug 876090 and bug 865750 (recent updates)
<ubottu> Launchpad bug 876090 in tzdata (Ubuntu) "2011l available" [High,Fix released] https://launchpad.net/bugs/876090
<ubottu> Launchpad bug 865750 in tzdata (Ubuntu) "2011k available" [High,Fix released] https://launchpad.net/bugs/865750
<tremolux> infinity: I just make a test case based on what's changed in the new data, and then test in chroots for each distro version
<infinity> slangasek: You have queue love.
<slangasek> well, at least it's not a plague
<infinity> I'll bring you that in two days.
<infinity> For now, you just get packages.
<slangasek> tremolux, infinity: btw, I heard something to the effect that Transnistria (Pridnestrovie) flip-flopped on the question of whether they were keeping DST this year; do we know whether 2011m reflects the latest status?
<infinity> slangasek: It contains a change for them.  I'm not sure which direction the flipping of the flop has gone.
<infinity> +# From Alexander Krivenyshev (2011-10-17):
<infinity> +# Pridnestrovian Moldavian Republic (PMR, also known as
<infinity> +# "Pridnestrovie") has abolished seasonal clock change (no transition
<infinity> +# to the Winter Time).
<infinity> ^-- That flip-flop, or a reversal again?
<slangasek> I think it reversed again after that
<infinity> Seriously?
<slangasek> 13:11 < aurel32> so Pridnestrovie just reversed the decision we pushed in 2011m to not to to DST (so they will go to DST)
<infinity> I hate people so much.
<slangasek> 13:12 < aurel32> taking the decision one week ago, reverting it a few days after, not sure, we want to push a new version for that
<infinity> Does aurel have a reference for this?
<Laney> wait and see what they do ;-)
<slangasek> infinity: dunno about references; but it seems Debian may wait until Sunday to see what the outcome is in practice
<infinity> slangasek: Well, we can't wait on the other change.  I suppose we could patch out the Pridnestrovie one, but we can just as easily push a reversal...
<slangasek> indeed
<infinity> slangasek: And you only accepted hardy?  Was that before this whole thing came up? :)
<slangasek> infinity: still accepting
#ubuntu-devel 2011-10-29
<slangasek> infinity, micahg: so I suppose these tzdata packages are built now and ought to be published; are we doing any verification on them?
<infinity> slangasek: I did a quick test to make sure things looked sane.
<infinity> slangasek: Not on every release, but they were all identical changes.
<slangasek> infinity: ok, copying
<slangasek> infinity, micahg: tzdata published
<pipalo> Good time everyone!
<pipalo> Can i get some help with this error http://mysticpaste.com/view/10459 - Patching xorg on 11.10 works fine on 11.04
<pipalo> !help
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<pipalo> !patience
<ubottu> Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<ome> net probe. anyhelp with http://mysticpaste.com/view/10459 ?
<cjwatson> well, the patch just needs to be adjusted to apply against the new source; that's normal for patches
<cjwatson> oh, but you're building the xorg source package?  that's odd, xorg didn't fail to build from source in 11.10.  perhaps a more complete transcript of what you're doing would help.
<cjwatson> (including how you got the source package.)
<ome> cjwatson, here is what I am doing http://bigbrovar.aoizora.org/index.php/2011/05/24/better-clickpad-support-for-ubuntu-11-04/
<cjwatson> I don't want to pick through that - please show me a full transcript of just exactly what you are doing
<cjwatson> from the start including error messages
<cjwatson> oh, you're adding a patch to the source package, from the looks of that
<cjwatson> then my previous comment stands, this isn't a procedure that can be performed for an arbitrary release without editing the patch
<cjwatson> if you don't know how to do that, then it's best to ask the patch author
<ome> I am not an expert but know a bit of programming and how stuff works under the hood.
<ome> but I am not sure what that error suggests, I know there is something wrong with a config file but not sure what to look for.
<cjwatson> no, the problem is that this is a patch for a different version of the software
<cjwatson> it requires a developer to update it
<ome> aight then, thanks for help.
<cjwatson> (I had a quick look, and while the fix to 203 is simple, there are several other changes required to subsequent patches as well)
<cjwatson> (and I'm not remotely confident that me doing a monkey-see-monkey-do patch refresh is going to result in a working synaptics driver)
<cjwatson> you can learn how patches work if you like and try to update it yourself; http://en.wikipedia.org/wiki/Diff#Unified_format
<ome> thanks cjwatson I will have a look.
<madnick> A virtual keyboard at the LightDM greeter would improve accessability, is anyone working on this for Ubuntu?
<gs_> hello all
<gs_> i am interested in writing system restore program for ubuntu
<gs_> this will be able to restore the package state
<gs_> of the system to an earlier saved state
<gs_> for that I need to scan package metadata of those packages which are installed on the system
<gs_> could you please help me in doing that ?
<sladen> gs_: you want the APT/Dpkg metadata
<sladen> gs_: dpkg --get-selections   and   dpkg --set-selections   should get you started
<broder> gs_: you may also want to look at apt-btrfs-snapshot
<jtaylor> or apt-clone (not the one in the repository)
<shnatsel> hi everyone
<shnatsel> I've just dropped by to say thanks
<shnatsel> Thank you so much for providing ubuntu-core archives, guys!
<shnatsel> that makes my life so much easier!
#ubuntu-devel 2011-10-30
<slangasek> lool: your udev upload to precise seems to include a lot of changes not explained in the changelog, including the disappearance of the entire test/ tree from bzr - was this intentional?
<micahg> slangasek: infinity: thanks for taking care of tzdata
<slangasek> micahg: no problem
<pipalo> Can someone upgrade this http://bigbrovar.aoizora.org/index.php/2011/05/24/better-clickpad-support-for-ubuntu-11-04/ patch for 11.10 please ?
<pipalo> http://tinyurl.com/1104patch
<f0x> hiii everyone, i want to know how i can become ubuntu developer
<micahg> f0x: https://wiki.ubuntu.com/UbuntuDevelopers
<f0x> actually michag i am much more noob, i want to know how much programming should i knw to contribute to ubuntu..??
<micahg> f0x: not necessarily much, but it helps (BTW, there are many non-programming ways to contribute to Ubuntu)
<f0x> i want to contribute in programming, i will learn stuffs that is needed for it..
<f0x> i knw cmd line prograaming in c/c++, a little bit of python and php too
<micahg> f0x: that should be plenty :)
<f0x> sure..?? i can start contributing to developing with this mch..??
<micahg> f0x: there are 2 types of components to programming in Ubuntu: packaging and fixing bugs, which would you be interested in (both is fine :))
<f0x> i don't knw if this programming does ever do any important stuffs,
<f0x> sorry, was disconnected
<f0x> i will like to do both, i am currently reading stuffs on exploitation, buffer overflow and stuffs , i think may be i would learn more in that way too, so both bug finding and programming
<f0x> micahg, there..??
<micahg> f0x: sorry, in the middle of dinner, can we chat in a bit?
<f0x> sure.. sure, thanks for reply anyway, and please carry on with your dinner, sorry to disturb you in between your dinner :)
<micahg> f0x: so, you mentioned C++ and PHP, are there apps in either of those languages that have open bugs in Ubuntu that you use (and would like fixed)?
<f0x_> after finishing the setup of tools like bzr and pbuilder, what next..??
<f0x_> https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Development/Devbeginnings
 * micahg wonders where that new developer guide is
<micahg> f0x_: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
<f0x_> how is this..?? http://developer.ubuntu.com/resources/
<micahg> that's good information, most of the site is geared towards people who want to make apps for Ubuntu, but there's plenty of good information for Ubuntu Developers as well
<f0x_> can't find any documentation focused on ubuntu developer's :(
<micahg> f0x_: http://developer.ubuntu.com/packaging/html/
<f0x_> looks informative
<f0x_> i think , i will have to start with bug fixing first.
<micahg> f0x_: sounds good, feel free to ask any questions here or in #ubuntu-motu
<f0x_> thanxx a lot micahg ,
<micahg> f0x_: you're welcome
<bluefoxicy> Anyone know what the current de-facto method is in Linux to hook into the kernel and intercept file system access?
<bluefoxicy> That's fuse, right?
<RAOF> bluefoxicy: Depends on what you mean - fuse is for implementing userspace filesystems, so you can certainly hook into a filesystem you *write*
<bluefoxicy> RAOF: upon executing /usr/bin/chromium-browser, it is recognized that an updated version is available and has been downloaded, that it is a security update, and the update is applied before launching.
<bluefoxicy> RAOF:  upon mmap(PROT_EXEC...), same is done for libraries
 * micahg turns his head towards the chromium update discussion
<RAOF> bluefoxicy: And you want to work out...?
<bluefoxicy> RAOF: how to implement that
<bluefoxicy> because I'm not sure what kernel facility lets me pause exec() or mmap() while i do other crap
<RAOF> Why would you pause exec()?  Wouldn't you just check for updates, download it, and then exec() the new thing?
<azeem_> maybe you need a LD_PRELOAD library which overwrites the libc calls, like libfakeroot=
<bluefoxicy> RAOF you'd still need to intercept exec() with another command and possibly tell the kernel not to exec() or to exec() something else so the parent process doesn't return a "not found" error and then 5 minutes later your stuff magically launches
<micahg> bluefoxicy: are you trying to implement a new feature here or is this something that exists?
<RAOF> bluefoxicy: What, why?
<bluefoxicy> micahg:  new feature
<bluefoxicy> magic management
<bluefoxicy> RAOF:  Because I wrote some silly description of a non-existent Linux distro a decade ago that included all kinds of crazy shit as features and I want to try implementing some of it
<RAOF> bluefoxicy: You could resolve a longstanding FIXME in the dynamic loader by figuring out how to reload libraries :)
<RAOF> bluefoxicy: No, I mean why would you need to intercept exec()?
<bluefoxicy> things like being nigh-invulnerable to certain classes of exploits (Ubuntu has that now, full ASLR and stack smash detection and the like), or having fancy administrative tools
<bluefoxicy> RAOF how would you do it?
<azeem_> how would Drepper do it
<cjwatson> just have the application check by itself, and then re-exec
<cjwatson> intercepting exec is massively overthinking the problem
<bluefoxicy> How would you make a system that detects the execution of a program, makes sure it's up to date before it's executed, update it if not, and do all this seamlessly
<cjwatson> I wouldn't
<RAOF> Oh, man.  That would be a nightmare!
<bluefoxicy> accounting for any shell, any UI, and any programmatic method ever coded or possible to code into any program attempting to exec() that binary
<RAOF> I think that's actually a bad idea; you're adding an indeterminate latency to all execute calls.
<RAOF> Because "makes sure it's up to date" involves hitting the internet.
<bluefoxicy> probably
<bluefoxicy> you're underthinking the problem though
<RAOF> And if it *doesn't* involve hitting the internet, then we've already solve this.
<bluefoxicy> 1)  This would be configurable, and has many ways of being implemented (including grabbing from a local repository in a large network)
 * cjwatson suggests not starting out with a solution statement
<cjwatson> ("intercept execve")
<sladen> mmmm, oh yes!
<bluefoxicy> and 2) "checking" for things being up to date doesn't mean "run apt-get update every time someone calls exec()"
<RAOF> bluefoxicy: But it fundamentally means "hit the network everytime someone calls exec()" - otherwise you'd just configure apt to check every 15 minutes and automatically install updates.
<bluefoxicy> (also, the consideration of checking, downloading, installing, etc, has all kinds of error conditions that need consideration, such as what to do if the package isn't downloaded already and the network is not working--obviously, you recognize that, and continue on yourway)
 * cjwatson can think of at least one application where execve is performance-critical - it's spectacularly the wrong layer for this
<bluefoxicy> shrug
<bluefoxicy> All I'm hearing is "this can't be done"
<bluefoxicy> cjwatson:  what application is this anyway?  Curious.
<cjwatson> man-db
<RAOF> I think we're saying that this *shouldn't* be done.
<cjwatson> not to mention zillions of little sysadmin scripts
<bluefoxicy> I don't see how man-db is critical on execve
<cjwatson> I dod
<cjwatson> I do
<bluefoxicy> besides what's the worst that can happen
<RAOF> Or, rather, that you should back up and describe the problem you're trying to solve at a higher level.
<cjwatson> it's already the slowest thing in Ubuntu upgrades
<bluefoxicy> it checks if ls is up to date one time?
<slangasek> the worst that can happen is that your code to do the checking, downloading, installing becomes a fun target for security exploits
<cjwatson> sorry, but you know, I've actually analysed this.
<cjwatson> execve is an inappropriate place for this, but that doesn't mean that if you back up and start out from a problem statement rather than a solution statement, that you can't still achieve your goal
<cjwatson> I would suggest considering things in terms of applications rather than executables
<bluefoxicy> how I wish I had web space
<bluefoxicy> http://img403.imageshack.us/img403/369/screenshotat20111030174.png THIS is from 2003-2004
<bluefoxicy> JIT updating and installation is a feature of Windows too isn't it
<RAOF> I don't believe so, no?
<bluefoxicy> published applications?
<RAOF> Published where?
<bluefoxicy> When you run them they update or install automatically from network media
<bluefoxicy> it's an active directory function
<bluefoxicy> you get an icon for Microsoft Word on your desktop, but if you run it Word isn't installed.  or it's the new version of word but you have the old version.
<RAOF> That might be why I don't know it.
<bluefoxicy> but when you run it, the new version runs, installed or not.
<cjwatson> there's a big difference between having a system that causes selected applications to auto-update/install and doing it for every executable
<cjwatson> you could do the former today with a wrapper script, quite seasily
<cjwatson> *easily
<bluefoxicy> whoa
<bluefoxicy> Korean
<cjwatson> what?
<bluefoxicy> <cjwatson> you could do the former today with a wrapper script, quite s[korean]easily
<cjwatson> er, no
<cjwatson> it was probably some lag-induced representation of a backspace
<bluefoxicy> æ¥æ¬èªããããããããã¾ããã
<bluefoxicy> anyway
<bluefoxicy> http://0install.net/ this is still interesting.
<bluefoxicy> cjwatson:  I seem to recall a guy that told people he was going to make buffer overflow vulnerabilities completely elective in about 2 months time
<bluefoxicy> that was in August 2001 ... he got laughed at if I remember right.
<bluefoxicy> in October 2001, he released PaX, which implemented a NX bit on i386 and a security policy that limited buffer overflows to causing program crashes.
<cjwatson> right, but it doesn't follow from that that everything that is criticised is correct :-)
<bluefoxicy> There are things that can be done, and there are things that haven't been done.
<bluefoxicy> cjwatson of course not
<bluefoxicy> but it does seem to be a design pattern that every significant invention is said to be impossible or at least a very bad idea before it's done
<cjwatson> confirmation bias
<RAOF> I don't think that's true at all.
<cjwatson> (if that implication holds, it doesn't hold the other way round)
<bluefoxicy> the light bulb.  Batteries.  Radio.
<RAOF> Right.  You don't see the vast majority of bad ideas which go on to become... bad ideas.
<bluefoxicy> A computer fast enough to make use of more than 32 megabytes of RAM in any meaningful way.
 * cjwatson would not be inclined to compare himself to Marconi, even by implication
<bluefoxicy> Man in space.  Government.
<RAOF> I'm not familiar with all of those, but were any of the actually considered to be impossible or a bad idea?
<bluefoxicy> Radio was not only considered to be impossible (communications at a distance), but also repeatedly considered impossible WHILE IN USE
<cjwatson> you're seriously advancing this as a defence of your idea?
<azeem_> it's the cold-fusion defense
<bluefoxicy> the lower frequency bands were the only bands for a while.  FM radio operates over a garbage band that's impossible to make use of.  VHF is completely useless because it breaks down out of direct unobstructed line of site and doesn't reflect off the ionosphere.  Same with UHF.
<cjwatson> a working implementation would be a better defence
<bluefoxicy> again and again with radio lol...
 * cjwatson tends to take the IETF line on this - rough consensus and running code
<bluefoxicy> cjwatson:  no, I just think it's worthwhile arguing that many good ideas are killed or just an uphill development battle because the vast majority of the world doesn't believe in them :P
<cjwatson> it's an utter fallacy though
<bluefoxicy> people are less interested in how to achieve a goal than they are in why that goal is unachievable
<cjwatson> and it's a waste of time
<cjwatson> if you seriously think it's a good idea, and don't think it's worthwhile listening to others, then just do it
<bluefoxicy> to the point that some ideas have faced such scrutinty in the past by which very rich folk have spent lots and lots of money campaigning against them because they're ridiculous, only to have some hack make it work and also have the market find out the end product is the most useful thing in the world at the time.
<cjwatson> ee what happens
<cjwatson> *see (gah, lag)
<RAOF> People don't spend money campainging against things which they consider impossible.
<cjwatson> but you can't expect to persuade other people by comparing yourself to the inventor of radio - if people dived head-first into every crazy idea that came along, they'd never have time for anything else :)
<bluefoxicy> Global warming, solar power versus the clean coal industry, there's a lot of people out there saying solar/nuclear/whatever doesn't work or is too far off or has hidden problems.
<RAOF> And if you *made* this work - or semi-work - then people would be more likely to take it seriously.
<bluefoxicy> (though that's mostly business and politics)
<cjwatson> ideas that are demonstrated to actually work, by means of a real implementation, have a better chance of people paying attention to them; that's an excellent filter
<bluefoxicy> heh
<bluefoxicy> anyway this tangent has gone too far
<bluefoxicy> I guess the only working hook is LSM
<RAOF> We don't, in general, have a shortage of good ideas; we've got a shortage of implementor-time.
<bluefoxicy> RAOF:  I've always got a shortage of implementor-time :P
<bluefoxicy> but that's what happens when people have day jobs
<bluefoxicy> I was a lot more useful when I didn't have a  job :(
<bluefoxicy> ah well.  Maybe I'll do something easier, like write a stock market analysis program that implements pivots and strength/weakness arcs.
<slangasek> cjwatson: could you slap zinoviev for not git tagging his console-setup uploads? :)
<cjwatson> if he ever came on IRC I would :)
<slangasek> drat :)
<cjwatson> micahg: FWIW, my reading of the xine-lib changelogs you quote is that the situation in natty was exactly the same as now; which doesn't mean we shouldn't fix it, but I don't think siretart's recent merge changed anything
<micahg> cjwatson: I am tired, maybe I misread, looking again
<micahg> cjwatson: ah, indeed, I took the don't build against system libs to mean don't build :(, but 1 new library was added
 * micahg will double check and then send a followup mail clarifying
<micahg> cjwatson: thanks :)
<cjwatson> are you sure?  he said "remove build-dependency on libvcdinfo-dev", which to me means probably building against the internal version
<micahg> ah, yes, probably...
<cjwatson> I guess a diff would be worthwhile to make sure, but it looks like four either way
 * micahg is doing that now
<micahg> cjwatson: verified that the same libs are being used (at least as far as the rules file goes), apology E-mail sent
<sbte> hey, can anybody here tell me why sensible-browser doesn't detect the default system browser in oneiric? And what to use instead to open urls in the default browser?
<micahg> sbte: xdg-open?
<sbte> micahg, that works with http:// prefixed indeed
<sbte> but most applications do use sensible-browser or x-www-browser, and I think it was handled correctly in natty
<micahg> we really should standardize on something, but I think that needs to happen in Debian first
<micahg> x-www-browser is alternative based so that usually will not DTRT
<sbte> sensible-browser should I guess. The webbrowser module in python seems to use it through the default url-handler for http which is set to sensible-browser %s
<micahg> sbte: sensible-browser defaults to alternatives, seems to be used to pick one out of a list of browsers passed to it and use what it finds or fall back to an alternative
<sbte> micahg, so maybe /desktop/gnome/url-handlers/command should be set to the xdg-open %s?
<sbte> micahg, do you know if xdg-open is installed on all gnome based systems? gnome-open seems to be the default, but it's not installed on oneiric at least
<micahg> not sure, it seems to be installed on most Ubuntu systems though
 * micahg will be back later
#ubuntu-devel 2012-10-22
<goddard> hello?
<TheMuso> ;/c
<robertzaccour> The only DE that recordmydesktop outputs 1920x1080 in is Gnome Shell. The others I tried recently (Unity, Xfce, KDE, LXDE) recordmydesktop outputs 1920x1072. Any suggestions?
<pitti> Good morning
<dholbach> good morning
<obounaim> Good morning everybody
<tkamppeter> Any thundderbird/email expert around here? How can my gmail account, 6 years of e-mail, 180000 mails take only 3.2 GB whereas my canonical accoung, 10 months, 2800 mails tages 27 GB?
<pitti> big attachments?
<tkamppeter> pitti, do your Canonical mails also occupy such a lot of space?
<tkamppeter> pitti, biggest attachment on a Canonical mail in my box is around 10 MB.
<pitti> tkamppeter: not more than usual, but I keep all in maildirs, and delete mail from lists
<tkamppeter> pitti, in maildirs they would continue occupying disk space.
<tkamppeter> pitti, I use the Canonical account via IMAP, should the inbox then not take space at all?
<pitti> I really don't know how Tbird keeps its mail
<pitti> but I would think that it does download it
<pitti> it would be a ridiculously bad user experience otherwise
<tkamppeter> I would like to have locally only some kind of cache, with mails longer not looked at only kept on the IMAP server.
<pitti> I use archivemail for that on my mail server, but that's not quite what you want
<pitti> $ du -hs ~/.mail
<pitti> 31M/home/martin/.mail
<pitti> :)
<jibel> tkamppeter, you can try to compact your mail boxes if TB is not setup to do it automatically.
<vibhav> Will it make sense to open merge requests now?
<vibhav> s/open/file/
<pitti> vibhav: for raring? sure
<vibhav> pitti: What about submitting debdiff's for them?
<pitti> https://launchpad.net/ubuntu/raring/+queue?queue_state=1
<pitti> raring uploads work, but they are held in unapproved until bootstrapping finished
<pitti> vibhav: same answer
<vibhav> yes!
<tkamppeter> pitti, I have found the problem: Until recently Thunderbird was managinmg IMAP accounts completely onm the remote server, now a recent update introduced taking local copies and so suddenly I had more 27 GB of old mails on my SSD. I have turned off the local copies now and deleted the huge INBOX file. Perhaps Thunderbird is sponsored by HDD/SSD manufacturers now?
<pitti> tkamppeter: I think something like "locally cache the last 4 weeks of mail" or so would be a sensible default indeed
<pitti> searching through older ones is okay to take some time, while looking at recent ones should be fast
<vibhav> pitti: You touched anthy last, could I preapre a merge for it?
<vibhav> prepare*
<pitti> vibhav: please do
<vibhav> thanks
<pitti> vibhav: thanks to you!
<tkamppeter> pitti, this is really missing, and there is also no function to delete old or otherwise unwished mails only in the local cache and not on the server.
<tkamppeter> pitti, so I could only manually remove the cache, by turning off caching, closing Thunderbird, deleting the INBOX file and starting Thunder bird again.
<pitti> tkamppeter: FYI, chrisccoulson is our TB maintainer, he might know how to do that in a better way
<pitti> tkamppeter: I have never used TB, so I have NFC about this, I'm afraid
<tkamppeter> chrisccoulson, I have some problem with Thunderbird. Most recently it seems to have changed defaults and it cloned the whole inbox of an IMAP account to the local disk, being 27 GB in my Canonical Inbox of 10 months. Now is there a way of something like keeping cache of the last 4 weeks? Or removing mails only from the local cache and not from the server?
<ev> mpt: I may have been wrong about this after all - still looking into it. But I've definitely fixed those three days.
<mpt> ev, have you seen bug 927386? It looks right up your alley -- the error tracker apparently being unusable in Ubiquity :-)
<ubottu> Launchpad bug 927386 in ubiquity (Ubuntu) ""Installer crashed" redundant with Error Tracker alert" [Wishlist,Triaged] https://launchpad.net/bugs/927386
<ev> on it
<ev> mpt: I've followed up on the bug
<tkamppeter> pitti, I have a problem with apport. In Quantal I get a crash window from time to time. When I agree with sending a bug report by simply leaving the default settings of the dialog the report never gets sent. Now progress bar window and and now call of the browser. I have observed that on four different computers.
<pitti> tkamppeter: it's sending errors to http://errors.ubuntu.com, not to LP; it's working as intended
<tkamppeter> pitti, this is the configuration made for end users, as they probably will no know how to write a bug report?
<pitti> right
<pitti> and we don't want to flood LP with bugs/crashes from stable releases
<tkamppeter> pitti, who gets access to this data? Can I go to ttp://errors.ubuntu.com/ find my data and get it into a bug report?
<pitti> ev: ^ I think that's possible for an user, if you figure out your hash, right?
<ev> pitti: correct - though currently only people in bugcontrol can access their own reports. We're fixing this.
<pitti> ev: tkamppeter should be able to as a developer
<ev> pitti, tkamppeter: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
<ev> pitti, tkamppeter: tack that on the end of http://errors.ubuntu.com/user/
<ev> (this is supposed to be in the preferences dialog, but for some reason a new version of activity-log-manager wasn't released in 12.10
<tkamppeter> ev, and how do I proceed?
<ev> tkamppeter: what do you mean?
<tkamppeter> ev, how do I access my data on errors.ubuntu.com.
<pitti> open above URL, there you see all reports that you sent
<ev> tkamppeter: I just explained. You run the first command that I pasted. That gives you a sha 512 hash. Then put it on the end of http://errors.ubuntu.com/user/ in your browser
<ev> so http://errors.ubuntu.com/user/deadbeefdeadbeefdeadbeef
<pitti> firefox http://errors.ubuntu.com/user/`printf $(sudo cat /sys/class/dmi/id/product_uuid)|sha512sum`
<ev> pitti: cheers :)
<pitti> tkamppeter: ^ this is a copy&paste command
<pitti> tkamppeter: you can bookmark this, it's a stable URL for each computer
<pitti> (NB "computer", not "user")
<ev> yeah, I should really change that
<vibhav> Is there a way to submit bugs for a ppa via apport?
<vibhav> a package in a ppa*
<vibhav> Only onnly blueprint\bug report on it?
<vibhav> s/only/or/
<pitti> vibhav: a PPA package can ship a package hook which sends bugs to the upstream project, if desired
<vibhav> pitti: Is that documented anywhere?
<pitti> vibhav: in /usr/share/doc/apport/package-hooks.txt.gz
<vibhav> thanks pitti
<mpt> ev, how much work will it be to add the 13.04 line?
<ev> very little. Just waiting for some reports to actually come through :)
<mpt> ev, and change the X axis I guess
<ev> mpt: to expand to 13.04 release?
<mpt> ev, either hard-coded to 2012-04-25, or soft-coded to the latest milestone registered for any release
<mpt> er, 2013-04-25
<ev> it already does the latter for 12.10 :)
<ev> but yeah, definitely need to make this automatic
<ev> fetching from Launchpad as you suggest
<ev> I get chills every time I hardcode the release numbers somewhere
<mpt> Chills are usually for good things...
<tkamppeter> ev, sorry, I overlooked your first pastes.
<ev> no worries
<tkamppeter> ev, pitti, now I can display my data in the browser, but how do I make use of this data set for a bug report, especially if I want to get the core dump into the retracer?
<pitti> tkamppeter: errors.u.c. does retracing on its own
<tkamppeter> pitti, so I only add a link to the appropriate OOPS to the bug report?
<pitti> tkamppeter: we don't usually file bugs for the stable release; but at this particular point in time I guess you can do that
<pitti> (raring not open yet)
<tkamppeter> pitti, I will use it only in certain selected cases where an SRU would be appropriate.
<tkamppeter> ev, pitti, I have found a small usability problem in the web interface of https://errors.ubuntu.com/: OOPSes are sorted alphabetically by their UUID, which is absolutely useless, as UUIDs are more or less random numbers. It would be much better to sort them by date and perhaps also tell in the overview list in which package the problem occurred.
<ev> tkamppeter: I'm already aware of it. It's on my todo list.
<ev> thanks all the same though
<tkamppeter> ev, pitti, thank you very much.
<ev> sure thing
<ev> tkamppeter: in the interest of transparency, I've moved it into a bug report: https://bugs.launchpad.net/errors/+bug/1069743
<ubottu> Launchpad bug 1069743 in Errors "System page should be presented as a sorted table" [Undecided,New]
<vila> hi all
<vila> I'm upgrading to quantal and noticed that computer-janitor has been removed. How are the corresponding features handled now ?
<vibhav> Would it make sense to merge apt-cacher-ng 0.7.7-2 from sid? The changes in this version are a bit insignificant ( http://packages.debian.org/changelogs/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.7.7-2/changelog )
<Laney> no, leave a comment on m.u.c saying so
<vibhav> done
<infinity> jamespage: Regarding your openattestation upload in the precise queue.  Can you use release versions in  your version numbers instead of codenames?
<jamespage> infinity, I can yes
<infinity> jamespage: So, 1.5-0.12.04.0 instead of 1.5-0precise1, or something along those lines.
<infinity> jamespage: Thanks.  We're trying to break people of the codename habit, since the end of the alphabet's coming up, and it'll sort rather poorly. :P
<jamespage> infinity, OK
<seb128> infinity, easy solution, don't wrap, just append
<seb128> z -> za -> zb, etc :p
<infinity> seb128: *grin*
<infinity> jamespage: Oh, same complaint in the quantal queue, now that I look over there.
<cjwatson> * seb128 is now known as Excel
<cjwatson> (though not quite, it did Z AA AB IIRC)
<infinity> jamespage: For reference, I'm using versions like "1.6.0-0ubuntu0.12.10" for vmware-view-client.  Might want to use something along those lines.
<jamespage> infinity, ack
<infinity> cjwatson: Wasn't DOS drive lettering the same?
<cjwatson> infinity: I recycled those neurons years ago.
<cjwatson> infinity: https://en.wikipedia.org/wiki/Drive_letter_assignment suggests it was a bit more complicated than that.
<infinity> cjwatson: I wish I hadn't read that.
<infinity> cjwatson: Only Novell would have considered `: a reasonable drive designation.
<mlankhorst> infinity: of course! Lets use unicode designations
<mlankhorst> å®¶:
<Laney> Ubuntu â­
<vibhav> Laney: Ubuntu Community?
<bdmurray> seb128: is there a bug regarding .xsession-errors filing your disk? bug 1069402
<ubottu> Launchpad bug 1069402 in Ubuntu "Ubuntu fill all disk space of / in file ~/.xsession-errors" [Undecided,New] https://launchpad.net/bugs/1069402
<seb128> bdmurray, there is bug #1000775
<ubottu> Launchpad bug 1000775 in lightdm (Ubuntu) "[12.04] [ Precise] .xsession-errors getting spammed filling up the disk." [Medium,Triaged] https://launchpad.net/bugs/1000775
<seb128> bdmurray, that's the bug that lightdm doesn't limit the log or truncate it, that doesn't cover whatever buggy app is spamming the log which is an issue by itself as well
<bdmurray> seb128: right, okay thanks!
<seb128> bdmurray, yw!
<doko> mvo, python-apt ftbfs for python3.3
<mvo> doko: can you link to the ftbfs
<jamespage_> hallyn, around?
<doko> mvo, no, local build, deprecated function
<mvo> doko: on the product sprint right now, could you mail me the build link?
<mvo> doko: eh, sorry
<mvo> doko: build log I mean? or past the failure message please?
<doko> mvo, will do
<mvo> thanks
<mvo> doko: hints on how to reproduce also welcome, unless its very difficult
<doko> mvo: just build in a raring chroot
<hallyn> jamesh: what's up?
<hallyn> uh
<hallyn> jamespage: what's up?
<hallyn> jamesh: sorry, nm
<bdmurray> pitti: doe bug 1053749 belong somewhere else?
<ubottu> Launchpad bug 1053749 in ubuntu-drivers-common (Ubuntu Raring) "software-properties-gtk cannot launch" [High,Invalid] https://launchpad.net/bugs/1053749
<mitya57> doko: can you please sponsor my fix for sphinx ftbfs (bug 1069894)?
<ubottu> Launchpad bug 1069894 in sphinx (Ubuntu) "Shinx fails to build on raring" [High,Triaged] https://launchpad.net/bugs/1069894
<jacobw> hi, is this the right place to seek information on packaging? i'm looking for information about packaging xul extensions
<mitya57> jacobw: maybe #ubuntu-mozillateam will be a better place...
<jacobw> mitya57: thanks
<jbicha> slangasek: so now we have 2 bugs for the efi boot issue, bug 1069475 & bug 1069908
<ubottu> Launchpad bug 1069475 in grub2 (Ubuntu) "grub fails to boot unsigned kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1069475
<ubottu> Launchpad bug 1069908 in grub2 (Ubuntu) "Ubuntu GNOME Remix image don't boot on EFI systems" [Undecided,Confirmed] https://launchpad.net/bugs/1069908
<barry> cjwatson: i'd like to avoid having to always say 'raring-proposed' during normal development, and i'd like for only 'raring' to show up in apt-get sources and udd branches
<stgraber> barry: changelog and .changes file will just say raring and LP will then redirect to raring-proposed where it'll finally be copied to raring once it's all built and tested
<barry> stgraber: perfect :)
<stgraber> so for apt-get sources, it'll be raring, not sure how UDD will handle that stuff though
<barry> stgraber: that will be fun to see ;)
<ptomblin> Hi.  I just discovered (because one of my users knows how to contact me outside of email) that when I upgraded from 12.04 to 12.10 yesterday, it installed this package "mail-stack-delivery", which a) changed mail delivery from MBOX to MailDir b) removed half of my spam tests in postfix/main.cf
<ptomblin> The former is pretty important, because it didn't change dovecot imap to show maildir mail, so the users couldn't see any new mail - but that's probably a good thing because if it had changed, they wouldn't have been able to see their old mail.
<slangasek> ptomblin: according to the changelog, the mail-stack-delivery package has been present since oneiric; the precise version of the package definitely depended on it; so I don't think you've gotten to the root issue yet
<slangasek> ptomblin: in any case, you should probably file a bug on dovecot about the issue, and if you need further help debugging, #ubuntu-server is a good place to find experts
<ptomblin> Well, all I know is that I have a spent half the afternoon trying to undo the damage, and now my users are asking how I can get them all the mail they got in the last two days that's stuck in maildirs.
<ceolin> hey guys, is there a channel for appmenu or this one can be used ?
<jcastro_> #ubuntu-unity probably
<ceolin> jcastro_: thanks, i'll try there
<gruebert> Greetings.
<gruebert> Regarding UDC. . .
<gruebert> nexus 7.
 * gruebert hangs his head.
<gruebert> re: nijaba
<gruebert> oh, the silence.
<slangasek> gruebert: we could put on some background music
<gruebert> oerm.  Some requiem, perhpa.
<gruebert> perhaps.
<gruebert> So...  how mny babies do I have to eat to get a nexus7 howto?  cause, I might as well kill two birds with one stone.
<gruebert> I'm raring to go.
<gruebert> Is it possible to stream UDC?
<dobey> gruebert: you mean UDS? there will be audio streams available for it next week, when it starts, yes
<gruebert> sorry, yes.
<gruebert> I'm chomping at the bit to throw 13.04on my nexus7.
<gruebert> vnc is meh.
<dobey> barry: ping
<barry> dobey: pong
<jcastro_> We don't call them derivatives anymore do we, we call kubuntu, xubuntu, and lubuntu ... ?
<Laney> flavours
<jcastro_> ta
 * jcastro_ fixes the spelling and moves on
<Laney> you'd probably omit the u though
<Laney> pip pip
<dobey> barry: hey, so i tried to build dirspec nightlies on raring; but it seems py3versions -vr returns python3.3, which isn't getting installed. is py3versions -vr perhaps the wrong way to use it, and one should just use "python3" always in the packaging? or do I need to wait for python3.3 to get in as the default python3?
<darkxst> slangasek, can you confirm what changes were made to images for secure boot? it looks like the release cd always boots signed image? which was missing on ubuntu-gnome image
<barry> dobey: python3.3 should be a supported version in raring right now, with 3.2 still the default.  i think we're going to need an updated python3-defaults package, probably with the latest experimental version though
<barry> or unstable
<darkxst> slangasek, are there any other changes we need to make other than including signed kernel?
<dobey> barry: is there a way to Build-Depends on "all versions of python3" that isn't "python3.2, python3.3, python3.etc"?
<barry> dobey: "X-Python3-Version: >= 3.2" and BD on python3-all|dev *should* do it, and it is a bug if that doesn't work ;)
<dobey> ah ok. i just have python3, not python3-all
<dobey> will see if that fixes it; thanks
<dobey> barry: btw, are you in .dk already?
<barry> dobey: not yet.  i'm also distracted today and tomorrow finishing up work on a talk i give on wednesday ;)
<dobey> ah no worries. just wanted to make sure i wasn't bugging you too late in the day :)
<barry> nope :)
<xnox> barry: stgraber: well UDD will do what it does with current SRUs it will update both the -proposed & release branches. And hopefully it will be identical commits....
<xnox> as in shared history, but who knows.
<dobey> but time for me to head off anyway. later :)
<xnox> I had a quick chat but for example if you are working on a transition you may need dependencies from -proposed or test build against proposed if something did not cause the scales tip enough to copy the packages over.
<cjwatson> barry: everything should ultimately show up in lp:ubuntu/raring/blah, although possibly with "branch nick: raring-proposed" in some commits - I forget.  If something causes uploads to back up in -proposed it's possible that you may occasionally need to check out from -proposed to get the newest source.  otherwise it shouldn't be a major imposition
<barry> cjwatson: that sounds great, thanks.
<darkxst> cjwatson, can you confirm what changes were made to images for secure boot? it looks like the release cd always boots signed image? which was missing on ubuntu-gnome image
<darkxst> cjwatson,  are there any other changes we need to make other than including signed kernel?
<cjwatson> darkxst: make sure you have grub-efi-amd64-signed and shim-signed as well
<darkxst> cjwatson, ok will check, thanks
<cjwatson> I don't know how you construct your top-level ISO9660 image; live-build / ubuntu-defaults-image won't do the right thing yet, I'm afraid
<darkxst> cjwatson, we use the ubuntu image and rebuild the squashfs
<cjwatson> our debian-cd instance unpacks the debian-cd_info tarball from d-i and extracts /EFI/BOOT/{BOOTx64,grubx64}.efi from the grub/efi.img therein
<cjwatson> OK, that will save effort
<darkxst> but efi booting completely broke with the final release :(
<cjwatson> we ship grub-efi-amd64-signed and shim-signed as .debs outside the squashfs
<cjwatson> darkxst: I expect that it's only on some hardware
<cjwatson> unless you're saying that non-SB machines broke too, in which case it's not just about linux-signed
<darkxst> well it appears to be trying to boot the signed kernel on non-secureboot
<cjwatson> that's permissible
<darkxst> cjwatson, not when our image was missing the signed kernel
<cjwatson> sure, but in that case it's frankly bizarre that it would be trying to boot it ...
<cjwatson> so, sure, shove linux-signed in and see if it helps, but it smells of some other problem
<darkxst> cjwatson, grub config points to signed kernel?
<cjwatson> you mean when booting the CD itself or after installation?
<darkxst> yeh booting the CD
<cjwatson> oh, well, that's right there on the top-level iso9660 fs, you could just edit it!
<cjwatson> although probably better to include the signed kernel for the sake of the SB machines that get confused without it
<cjwatson> (it's not meant to be strictly required, but we haven't tracked down the bug that causes some firmware to throw a wobbly without it yet)
<darkxst> cjwatson, yes we have fixed that issue, anyway just wanted to check we arent missing other bits as well
<cjwatson> sure
<cjwatson> I don't think so
<darkxst> cjwatson, I meant the missing kernel is fixed (once we rebuild image)
<cjwatson> aye
<darkxst> cjwatson, do we need to include the ubiquity update also?
<xnox> darkxst: there was one ubiquity update to stop it from removing signed kernels at post-install cleanup. You _do_ want that update ;-)
<everaldo> cjwatson, so, we need also to ship grub-efi-amd64-signed and shim-signed as .deb ?
<everaldo> xnox, when we rebuild the iso it alerady includes ubiquity updates
<darkxst> everaldo, no it pulls ubiuquity from main
<everaldo> darkxst, oh :(
<everaldo> darkxst, can we build images with updates repo or just wget ubiquity ?
<xnox> You do want 2.12.15, and 2.12.16 is a nice to have.
<cjwatson> everaldo: darkxst said you were only rebuilding the squashfs, so you should already have that
<cjwatson> yeah, you need >= 2.12.15 if you're for some reason not building with -updates enabled
<cjwatson> it was all a bit of a mad rush towards the end
<cjwatson> everaldo: I wouldn't recommend just wgetting ubiquity; you'd need to get various associated packages as well
<cjwatson> copy it into a dedicated PPA if you have some reason not to just build with all of -updates
<everaldo> I don't see any problem to include updates
<everaldo> darkxst, do you see?
<darkxst> yes I think we can enable updates for the rebuild
<everaldo> ok, going to do it
<darkxst> it would be nice to get the e-d-s fix also, but that is still in proposed I think
<everaldo> darkxst, e-d-s ?
<darkxst> evolution-data-server (gmail fix)
#ubuntu-devel 2012-10-23
<darkxst> bug 1049028
<ubottu> Launchpad bug 1049028 in evolution-data-server (Ubuntu) "Unable to create gmail account" [High,In progress] https://launchpad.net/bugs/1049028
<everaldo> cjwatson, do you see any problem to include updates and rebuild an 12.10.1 iso for UGR?
<cjwatson> Not in general but I haven't looked at how UGR is laid out
<cjwatson> (Nor am I going to at 1am :-) )
<everaldo> cjwatson, just one last question them
<everaldo> how did you guys build the ubuntu iso? is it a custom script or live-build?
<cjwatson> live-build for the squashfs, a collection of stuff mostly involving debian-cd for the iso9660 container
<everaldo> humm, good to know, I will move our squashfs build to live-build for 13.04
<cjwatson> are you doing it by hand now or something?
<darkxst> cjwatson so its just a small script, that runs a bunch of apt commands in a ch-root
<everaldo> cjwatson, yes, debootstrap and apt-get install's on chroot
<everaldo> cjwatson, https://code.launchpad.net/~ubuntu-gnome-dev/+junk/iso-build-script
<cjwatson> I haven't looked, but live-build should be able to obsolete most handwritten scripts of that kind, yes
<everaldo> cjwatson, any tutorial or sample about how you guys use live-build?
<cjwatson> everaldo: google for my post to ubuntu-devel about it a year or so back
<everaldo> got it https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<everaldo> cjwatson, so simple... thanks :)
<jbicha> everaldo: I think that's deceptively simple, at least I wasn't able to figure it out but maybe I'm too impatient
<cjwatson> You'd have to hack on livecd-rootfs/live-build/auto/config a little
<cjwatson> Shouldn't be desperately much
<wookey> what's the package name of the thing that truncates changelogs on builds?
<lifeless> binary-pkg-mangler ?
<wookey> that's it
<wookey> but I searched for that and failed to find.
<micahg> pkgbinarymangler
<lifeless> that thing :)
<wookey> aha
<wookey> it's vital for multiarch otherwise your changelogs don;t match up
<micahg> do binNMUs have changelogs?
<wookey> yes. There was some discussion of this on debian devel
<wookey> you really want to take the binNMU change out of the changelog (and record it elsewhere) to avoid multiarch breakage
<wookey> it's been bodged for the time being in dpkg, I think
<cjwatson> wookey: But not so much of a problem for Ubuntu because we don't have single-arch binNMUs yet.
<cjwatson> (And not planned for the near future.)
<lifeless> cjwatson: I did a test for you to see whether you had regressed bug 803658 during Q cycle (and you had).
<ubottu> Launchpad bug 803658 in grub2 (Ubuntu) "grub-install /dev/mapper/isw_$UUID_$NAME0 failing with ICH10R raid 1+0" [High,Fix released] https://launchpad.net/bugs/803658
<lifeless> cjwatson: I don't recall reverifying for you; did you end up reproducing the setup and validating that you didn't regress it ?
<lifeless> cjwatson: or should I be ultra paranoid about upgrading that machine to Q ?
<cjwatson> lifeless: as I mentioned at the time, I managed to reproduce it in simulation with manual dmsetup commands, and I believe I fixed it, although it's true you never positively confirmed that
<cjwatson> It's not explicitly in the changelog because I fixed it before releasing 2.00-3ubuntu1
<cjwatson> (which was the first of the 2.00 merges to hit Ubuntu proper)
<RAOF> Hm. The 12.10 desktop installer doesn't seem to see the existing Windows 8 partition on this system; it thinks both discs have no partition table. That's not wonderful.
<RAOF> I guess it's time to redo that liveusb with a persistent partition so I can grab the logs.
<lifeless> cjwatson: kk, thanks
<TheMuso> RAOF: If I need to grab logs, and I used usb-creator to create the live USB drive, I go to a console, remount /cdrom read-write, copy logs, remount read-only to be safe, and shut down.
<TheMuso> Thats worked for me in the past.
<RAOF> TheMuso: Sounds good.
<RAOF> cjwatson: Actually, you're awesome at everything - does apport work in the liveusb environment?
<slangasek> darkxst, everaldo: so bugs 1069475 and 1069908 that jbicha was calling my attention to earlier are bugs with the CD and not with the grub2 package, correct?
<ubottu> Launchpad bug 1069908 in grub2 (Ubuntu) "Ubuntu GNOME Remix image don't boot on EFI systems" [Undecided,Confirmed] https://launchpad.net/bugs/1069908
<ubottu> Launchpad bug 1069475 in grub2 (Ubuntu) "grub fails to boot unsigned kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1069475
<darkxst> slangasek, yes
<darkxst> slangasek, we got stung by the late changes to secure boot ;(
<slangasek> darkxst: so I gather - sorry about that
<slangasek> darkxst: is there somewhere else those two bugs should be reassigned?
<darkxst> slangasek, we don't actually have a package for our build script currently,
<darkxst> slangasek, maybe just assign them to jbicha?
<slangasek> is there a launchpad project?  (since bugs can be reassigned from packages to projects, now)
<darkxst> it lives in jbicha's + junk folder, but if that is the case we should make a project
<slangasek> would probably be a good idea to :)
<grueblur> I can has nexus?
<grueblur> Surely a howto for 13.04?
<grueblur> When? So I can set my OMG.
<grueblur> I'll be in the saltmines.  Waiting, I suppose.
<grueblur> ;_;
<grueblur> Seven more days?
<grueblur> Bestturingssysteem.
<RAOF> As the proud father of a recently-newborn, than quit message is entirely wrong; there's nothing intuitive about the nipple :)
<sarnold> hehe
<darkxst> slangasek, how do I reassign bug to a launchpad project ?
<darkxst> (https://launchpad.net/ugr-iso-build)
<slangasek> darkxst: on the bug page, click the arrow next to 'grub2' under Affects; choose 'Project' and fill in the name
<darkxst> slangasek, ok, got it. thanks
<pitti> Good morning
<sarnold> pitti: isn't it insanely early for you?
 * slangasek waves to pitti
<pitti> bdmurray: I reassigned 1053749 to davmail, as several people seem to have reproduced it with installing this package
<pitti> hey slangasek
<pitti> sarnold: it's a bit earlier than usual, yes; but my head started working, can't sleep any more
<sarnold> pitti: heh, if the brain is already spinning, you might as well use it...
<slangasek> pitti: there's no davmail package in the archive; furthermore, the bug is in failing to handle an existing dpkg database
<pitti> indeed, just saw the LP error; I reassigned it to dpkg now and gave it a clearer title
<slangasek> it's not a dpkg bug either
<slangasek> this is existing data
<slangasek> dpkg can't possibly undo it; the consumer needs to cope with the encoding issue
<pitti> slangasek: so, back to "invalid" again then?
<slangasek> how is it invalid?
<slangasek> there's a crash on non-unicode input; this is a legitimate real-world situation; the client needs to cope with this
<pitti> ooh, I see, sorry
<slangasek> ok :)
<pitti> so, I guess I'll just intercept/ignore it in u-d-common
<skunk> where could I find the acer alps touchpad source code
<RAOF> skunk: Shared between the kernel and xserver-xorg-input-synaptics
<darkxst> is there anyway we can extpedite the evolution-data-server fix for gmail into -updates? Bug 1049028
<ubottu> Launchpad bug 1049028 in evolution-data-server (Ubuntu) "Unable to create gmail account" [High,In progress] https://launchpad.net/bugs/1049028
<darkxst> we are about to rebuild images to fix efi boot issues and would be nice to have that fix also
<darkxst> (images for ubuntu GNOME remix)
<RAOF> darkxst: How sure are we that the patch is safe?
<darkxst> RAOF: very sure, its just installing missing files
<darkxst> that said I guess there could be backs in the modules that it installs, since it has been broken since July
<darkxst> s/backs/bugs/
<RAOF> darkxst: Then I'll push it out now; it's had 3 days, and bugs in modules that weren't installed before are unlikely to be regressions.
<darkxst> RAOF, well they were moved in July , but no one even noticed since then
<darkxst> RAOF, and thanks
<RAOF> Yeah; we got UOA, which actually works :P
<micahg> darkxst:  RAOF: 3.6.0-0ubuntu3  is in the release pocket
<RAOF> micahg: Not according to my rmadison output?
<micahg> oh, eds, neverming
<micahg> *nevermind
<RAOF> micahg: Launchpad also seems to think that 3.6.0-0ubuntu3 is in quantal-proposed
 * micahg was looking at evolution
 * micahg really should go to sleep
<RAOF> Ah, yeah.
<RAOF> darkxst: Copied to quantal-updates (and raring).
<darkxst> RAOF, thanks
<darkxst> lol, how is this possible "UpgradeStatus: Upgraded to quantal on 2011-04-01 (529 days ago)"
<RAOF> System clock out of sync?
<darkxst> RAOF, yes that is a good explanation, but you might expect someone would notice that ;)
<darkxst> I have another patch that needs sponsoring bug 1064354, patch has been committed upstream also
<ubottu> Launchpad bug 1064354 in gnome-shell (Ubuntu) "When running lightDM user locking doesnt work" [Undecided,Confirmed] https://launchpad.net/bugs/1064354
<darkxst> RAOF, micahg, perhaps you could upload ^^ for me?
<mvo> doko_: python-apt is building again, but there is a test failure that looks like something in subprocess
<dholbach> good morning
<tkamppeter> pitti, hi
<hyperair> anyone here got a sandy/ivy bridge chip and is running unity?
<Laney> yes
<hyperair> Laney: could you try running powertop and seeing the rc6 stats?
<hyperair> it's under the idle stats tab
<hyperair> on my laptop it's stuck at 90+% active
<hyperair> i'm wondering if that's supposed to be the case or if unity's sucking.
<Laney> cc6?
<hyperair> O_o
<hyperair> no, it's RC6
<hyperair> under GPU
<Laney> don't see that
<hyperair> Active, RC6, RC6p, RC6pp
<hyperair> hmm
<hyperair> werid
<Laney> C{1,3,6}-IVB
<hyperair> weird
<Laney> anyway C6 is high
<hyperair> maybe you don't have rc6 enabled.
<Laney> dunno what it means though
<hyperair> it's supposed to go down to C7
<hyperair> mine spends most of the time in C7 for CPU
<hyperair> but the GPU is spending most of its time active
<hyperair> and since upgrading i've been getting these sporadic hangs
<hyperair> [16938.783806] [drm:__gen6_gt_force_wake_get] *ERROR* Force wake wait timed out
<hyperair> ugh
<doko> mvo: both for 3.2 and 3.3?
<RAOF> hyperair: Note that running powertop means that you'll have a blinking cursor on the screen, which means you'll be continually waking up the GPU for vsyncs.
<hyperair> RAOF: hmmm. meaning that it never goes into rc6 unless the screen is completely still?
<RAOF> hyperair: I don't know; I would assume that you'd still be able to get into rc6 even with a 60Hz timer. I'm just saying that powertop distorts the power metrics by running :)
<hyperair> RAOF: well i was working on emacs, and leaving powertop running in the background, so i don't think it really counts
<hyperair> but yes, blinking cursor
<RAOF> Yes, it does, because the blinking cursor still means wakeups even when it's not visible - because of composite, all windows are always âvisibleâ
<hyperair> ah right.
<hyperair> i actually just closed my terminal while leaving powertop running in screen and went away for the past 5 minutes, but when i came back it was 100%
<hyperair> heh
<doko> TheMuso, why is python3-louis an Arch: any package?
<mvo> doko: http://paste.ubuntu.com/1299692/ <- this fails in py3.3, but works fine in 3.2 and 2.7 - should it?
<doko> mvo, looking at the docs, it's found in 3.3.0 too
<doko> mvo: hmm, don't see anything documented. the only thing I read is: "When stdout or stderr are pipes and universal_newlines is True then the output data is assumed to be encoded as UTF-8 and will automatically be decoded to text. All line endings will be converted to '\n' as described for the universal newlines 'U' mode argument to open()."
<doko> but this is not 3.3 specific
<mvo> doko: right, I can clarify with barry later if you want and add a workaround for now, but it seems like this is a unintended break in the new _save_input() in the subprocess modules
<mvo> module
<doko> mvo: u"u" does work in 3.2??
<mvo> doko: no, just remove it there if you want to run the test
<mvo> doko: its only needed for 2.7 and 3.3, its illegal on 3.0-3.2
<mvo> (and in 3.3 its just doing nothing but makes porting easier)
<doko> looks like _save_input was added for the new timeout parameter. looks like a bug
<doko> mvo, can you add an issue to the tracker?
<mvo> doko: sure, let me do that
<cjwatson> mvo: I understood this as intentional - it certainly came up in python3-debian testing
<cjwatson> It's documented in "Frequently Used Arguments" in subprocess
<cjwatson> mvo,doko: http://paste.ubuntu.com/1299724/
<mvo> cjwatson: so it was a mistake that this was accepted before?
<cjwatson> That's my understanding
<mvo> ok, thanks
<cjwatson> I think you need to either not support 3.2, drop universal_newlines and do manual encoding/decoding, or do something clever I haven't thought of
<mvo> if sys.version_info[0] < 3 and sys.version_info[1]  < 3: ... <- not very clever
<cjwatson> can't remember if sending unicode to stdin with universal_newlines works with 3.2
<mvo> I will check
<doko> mvo: not more clever, but shorter: if sys.version_info[:2] < (3, 3)
<mvo> doko: good point!
<doko> mvo: at least for raring, it should be fine. we won't have 3.2 at the end of the cycle anymore, but 2.7 is another thing
<cjwatson> sys.version < "3.3"
<cjwatson> works too
 * mvo nods
<doko> yeah, assuming every alpha has the same behaviour
<doko> for both cases ...
<mvo> doko: ok, I prepare a upload
<doko> so now all public python3 modules in main should be available for 3.2 and 3.3 (pending apt, qt4, qscintilla2)
<doko> ScottK, ^^^
<mvo> doko: do you know if someone update the Ubuntu.info.in template already?
<doko> mvo: which package is this?
<mvo> doko: python-apt
<doko> mvo: no
<mvo> doko: ok, I do it now
<ScottK> doko: I have python-qt4 mostly ready.
<ScottK> Should be ready later today.
<doko> will you work on qscintilla too?
<ScottK> I didn't look at it yet, but I will.  No promises about today.
<mvo> doko: its ready now, should I upload?
<infinity> doko: Well done on the first FTBFS of the series. :P
<infinity> doko: (Is python3-dev meant to be python3.3 now, cause it sure looks like it's 3.2)
<doko> infinity, yeah, you're just too late with the eglibc update ;-P
<mvo> doko: uploaded, I will be back, lunchtime
<xnox> doko: python3-apparmor is a compiled extenstion in main and built against (default py3) 3.2 only as far as I can see.
<xnox> note the "python3 (<< 3.3)" deps.
<doko> xnox, yes, according to pitti, it's only built for the default version (although I think it should be built for every one)
<xnox> doko: Jamie and I were the last ones to look at it =) (providing py3 packages) and yes it cheats and builds against default only...
 * xnox ponders if that automatically means I should be fixing it....
<doko> xnox, heh, why not?
<xnox> =_
<xnox> =)
 * xnox creates a symlink in /usr/share/debootstrap/scripts
<mitya57> doko: will have a new fix in a minute.
<mitya57> fire alarm in my house, will do that later
<mitya57> :)
<SpamapS> ch /win 6
<xnox> doko: did you have to fix ac_python_devel.m4 anywhere yet to pick up multiarched/two python3.3-dev include locations?
<doko> xnox, pythonx.y-config --includes should be used, if present, else the hardcoded stuff should be used as a allback
<doko> but I don't know which ac_python_devel.m4 you refer to
<xnox> doko: ack. didn't know about pythonx.y-config. Well ac_python_devel.m4 is a copy-pasted m4 macro from the autoconf-archive which tries to use pythonx.y -c "import distutils.sysconfig; print distutils..."
<doko> xnox, and print exactly what?
<xnox>        if test -z "$PYTHON_CPPFLAGS"; then
<xnox>                 python_path=`$PYTHON -c "import distutils.sysconfig; \
<xnox>                         print distutils.sysconfig.get_python_inc();"`
<xnox>                 if test -n "${python_path}"; then
<xnox>                         python_path="-I$python_path"
<xnox>                 fi
<xnox>                 PYTHON_CPPFLAGS=$python_path
<xnox>         fi
<doko> xnox, well, this already fails with print not a statement anymore ...
<xnox> haha true =)
<xnox> it should work if that thing returns a single item though ;-)
<xnox> or something like (single item tuple?!)
<xnox> but fails with python3.3 due to two items returned.
 * xnox will use -config in a sec.
<doko> xnox, so call the function a second time with plat_specific=1, and if the two values differ, append it
<cjwatson> xnox: No, in Python 3 the requirement for parentheses in print() is a syntactic restriction, not dependent on the type of the argument
<cjwatson> Try it yourself: foo = (1,); print foo -> SyntaxError
<xnox> cjwatson: thanks.
<xnox> doko: ack.
<infinity> Bleh.  Someone really should fix https://bugs.launchpad.net/ubuntu/+source/libnih/+bug/997359
<ubottu> Launchpad bug 997359 in libnih (Ubuntu) "nih uses eglibc private symbol __abort_msg" [High,Confirmed]
 * infinity decides to have some lunch instead of arguing with computers.
<doko> infinity, in the past, I did the upload of a new version as ~pre something to work around this
<infinity> doko: Yeah, I've tracked down the workaround, it's still awful.
 * infinity really lunches.
 * xnox should do quilt push before copy pasting snippets of code. I did re-write print statements with sys.stdout.write when porting to python3....
<cjwatson> Usually better to use from __future__ import print_function and then print().
<cjwatson> sys.stdout.write is pretty clunky most of the time.
<xnox> cjwatson: apparmor maintains 2.3+ compat.
<cjwatson> Yeah, if you insist on prehistoric compat then you may need clunky :-)
<cjwatson> Gotta wonder what the point is though.
<cjwatson> I mean, Ubuntu 5.04 had 2.4 ...
<xnox> to make it "secure" ? I dunno.
<cjwatson> I doubt it :-)
<cjwatson> Probably nobody's thought about it properly.
<xnox> well apparmor is not ubuntu specific? or are we upstream?
<cjwatson> Err, the point is that if we were shipping 2.4 7.5 years ago then you'd think most systems actually capable of running current apparmor would have something a bit newer than 2.3.
<cjwatson> (OK, you want 2.6 for decent py3 compat, but even that we were shipping 3.5 years ago.
<cjwatson> )
<cjwatson> Though as it happens we are upstream for apparmor.
<cjwatson> I think part of my point is that it's kind of daft to require Linux >= 2.6.36 and also go through contortions to support an ancient Python.
<xnox> =))))
<xnox> maybe nobody touched the python bits in a while...
<ev> so `date --utc --reference=/var/log/installer +%s` will tell me the installation date. Is there anything that will (stably) give me the time of upgrade? The ctime off /etc/lsb-release?
<xnox> ev: hm... something does add "upgraded on..." in apport hooks. I saw that on launchpad bugs.
<ev> ahhh, so it does
<ev> the mtime off /var/log/dist-upgrade/main.log
<ev> cheers xnox
<xnox> =)
<xnox> ev: for me the modification time is 4th of january, but I am running quantal. I did $ apt-get dist-upgrade, instead of upgrade-manager -d
<xnox> so results from me are bogus :-P
<ev> yeah
<cjwatson> yeah, I don't know of a 100% reliable and stable way
<cjwatson> several semi-reliable and semi-stable ways which might produce something reasonable in aggregate :-)
<ev> hm, maybe we chould take the ctime off /etc/lsb-release if it's newer than /var/log/dist-upgrade/main.log?
<cjwatson> /etc/lsb-release will get you any base-files upgrade, perhaps one more recent than the dist-upgrade.
<cjwatson> Depends which way you want to err.
<cjwatson> You could parse /var/log/dpkg.log* for base-files upgrade timestamps *shudder*
<wookey> what is responsible for bringing in pkgbinarymangler? It's not part of build-essential, which kind of makes it seem like it shouldn be part of crossbuild-essential, but if I cross-build anything MA-same without it then it's uninstallable
<wookey> so it is fairly essential
<wookey> IS there any reason why it shouldn't be added to the crossbuild-essential dep-list?
<arges> ev, hi. should we schedule https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-ddebs  for usr-r? There are a lot of postponed items and this is still a huge concern for our team. thanks
<ev> arges: yes
<cjwatson> arges: does it need re-discussion or just implementation time?
<arges> cjwatson, both. I think there should be a bit of discussion
<cjwatson> Why?
<cjwatson> Generally we try to avoid rescheduling UDS sessions when we already know what needs to be done but just didn't get to it.
<arges> cjwatson, well we got the extra space I believe on the ddeb server, so do we need to re instrument apport, or can we use the existing code?
<cjwatson> We still ultimately need to replace this bodgy pile of hacks
<ev> yeah, I thought Adam or someone was going to teach the publisher to include ddebs?
<arges> cjwatson, yes. so perhaps there is still some value in discussion.
<cjwatson> arges: I don't see any
<cjwatson> It's been discussed to death
<wookey> :-)
<cjwatson> And another UDS session won't make it happen any faster :)
<arges> cjwatson, ok so basically its just time to get those work items done. so those get tracked in that same blueprint
<cjwatson> So that's just "re-target to raring", I think
<wookey> ooh it has a name
<cjwatson> which I have now done
<wookey> only 4 years till we run out of letters
<cjwatson> (possibly not in an optimal way, I just renamed the spec and left the done items there)
<arges> cjwatson, ok that will be fine. the big thing that (i believe) has happened is that those older ddebs aren't being deleted
<cjwatson> Until we run out of disk again
<cjwatson> I mean, they weren't being deleted for fun, they were being deleted because there was nowhere left to go :-)
<arges> cjwatson, sure. so being proactive about it would be good. if we are close then add more disks
<cjwatson> sorry, but pitti *was* proactive, he notified IS as soon as it started to be close to be a problem
<cjwatson> about two months before he had to start deleting stuff
<arges> cjwatson, ok didn't know that
<xnox> Why would anyone do "X-Python3-Version: << 3.3" ? it doesn't make sense.... as there is no version encoded paths with pure-python3 modules.
<dobey> xnox: maybe python3.3 broke something in that module?
 * cjwatson is in the odd position of hoping that a build finishes slower
<cjwatson> (because it'll give me a better migration test case that way ...)
<_jmp_> cjwatson: good to know, I saw pitti was stellar on it. I will talk w/ IS during UDS as its very important to us as well
<xnox> dobey: how would the maintainer know that back in 2012-04-04? =)
<cjwatson> The publisher changes are still the right longer-term fix, but they're a lot of work and they involve UE doing fairly significant Launchpad work, which we have some capacity for but only limited at this point
<cjwatson> So if you can get by with just avoiding running out of disk for a cycle or two more, that would be very helpful
<dobey> xnox: maybe they tried it against a local cpython build out of vcs?
<pitti> arges, _jmp_: FYI, I got an ack from IS to give it loads more space RSN, and it already got plenty of extra space, so we don't need to kill ddebs anytime soon
<_jmp_> cjwatson: yeah, they actually told us they will add enough disks to be space-problem-free for a while :) lets see :)
<arges> pitti, : )
<pitti> speaking of which, /me sets up ddebs for raring
<_jmp_> pitti: awesome!
<dobey> xnox: i'm only stating the only viable reason i can think of; not claiming to know why the person actually did it :)
<_jmp_> pitti :))
<cjwatson> pitti: Excellent, so hopefully infinity can spend time on the other zillion infrastructure things on his plate :)
<xnox> dobey: I understand =) I'm trying to prove the maintainer wrong now. The unit-test passes fine
<xnox> =)
 * xnox calls it lies that 3.3 is not supported
<cjwatson> xnox: no VCS logs or anything?
<xnox> cjwatson: the python3 support was added with "<< 3.3" without any reasons stated.
<xnox> python3-py package that is.
<xnox> doko: $ python2.7-config --includes = -I/usr/include/python2.7 -I/usr/include/python2.7
<xnox> which is funny
<doko> yes, know
<doko> n
<xnox> ack =) doesn't hurt anything.
<doko> python3.3 support for public extensions is mostly done for raring
<doko> barry, xnox, ScottK, mvo: thanks for the help
<doko> mitya57, any update on sphinx?
<mitya57> doko: the test suite fails with python3.3, I'm slooowly debugging it
<doko> ok
<mitya57> doko: if it's urgent, we can just disable the failing tests (but I don't really like that idea)
<doko> as long as sphinx works in raring, that's fine
<doko> I mean, keeping the ftbfs, and using the existing binaries
<seb128> slangasek, bdmurray, RAOF, SRU team: is there any plan to work on the queue backlog before UDS?
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<seb128> SpamapS, bug #1067356, come on ....
<ubottu> Launchpad bug 1067356 in geary (Ubuntu Quantal) "Missing .desktop file" [High,In progress] https://launchpad.net/bugs/1067356
<seb128> SpamapS, needed to file a full other paper work bug for a one liner included with the upload?
<seb128> hum
<seb128> who rejected my seahorse SRU and why?
<Laney> I asked for it
<Laney> because I uploaded the new upstream
<Laney> http://launchpadlibrarian.net/120749544/seahorse_3.6.2-0ubuntu1_source.changes
<SpamapS> seb128: As the last time we chatted over IRC about this turned rather emotional, I'll decline to respond here. Please take it up with someone else or we can chat about it face to face if you'll be here in CPH next week.
<seb128> SpamapS, can you put those back in the queue for other SRU team members to pick if you are not wanting to.
<seb128> ?
<seb128> Laney, ok, comment on the bug would have been good
<SpamapS> seb128: I don't know how, but I have been told there is a way to unreject.
<Laney> you can accept from rejected
<Laney> but not put stuff back into unapproved (AFAIK anyway)
<seb128> grrr
<Laney> so reupload if that's what you want to do :-)
<seb128> yeah, doing that
<seb128> hopping to get a SRU team reviewer more tolerant for the next review
<Laney> that reminds me to reupload glib too
<seb128> Laney, what was the issue with this one?
<Laney> i rebased the changelog instead of merging it
<seb128> SpamapS, I've reuploaded, please don't reject this one, just let somebody who wants to review it do it
<SpamapS> seb128: I more meant that you might want to take up a difference in policy with the others. But again, perhaps we should talk in person.
<seb128> SpamapS, there is no writen rule saying that a SRU has to be have a record bug for every changeset in the upload
<seb128> SpamapS, or if there is one please point me to it
<dobey> seb128: the wiki page implies they do; unless there's a microrelease exception
<seb128> dobey, "imply", where?
<dobey> https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload
<seb128> dobey, that upload is not a kitchen sink one, it has 2 fixes, one being a one liner for a segfault I've no testcase about
<seb128> e.g those bugs that never get verified
<SpamapS> seb128: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure  .. The first requirement is that one records these fields in a bug report.
<dobey> seb128: i'm not trying to argue that you're right or wrong. i'm just saying that my reading of that section (in combination with the main Procedure section above it, and the microrelease section below it) suggests that a bug needs to exist for each fix, and each fix needs to close those bugs in the changelog.
<seb128> SpamapS, well, I've those fields, I just included a one liner upstream fix because I though it would improve things and wouldn't be a big deal
<seb128> *shrug*
<SpamapS> seb128: that is the last I'll respond about it. as I said, I'd prefer that we discuss in person, or that you approach somebody else on the SRU team about this.
<seb128> SpamapS, fair enough
<seb128> SpamapS, thanks
<seb128> well in any case I've reuploaded, I don't intend to register a new bug and try to find a testcase for that a non reproducible segfault
<seb128> so if somebody wants to accept those fixes great, otherwise it will stay broken for users and I will have lost my time on the SRU
<dobey> seb128: well, you don't necessarily need to find a test case for extremely hard to reproduce bugs. if the code does the right thing to fix cases like that, it should be fairly obvious what the code is doing, and a simple "This is nigh impossible to force to happen, but the code is correct and obviously fixes this crash." for the [TestCase] in a bug.
<dobey> seb128: from the IRC conversation, it seems to me like the issue is more the lack of the bug, than the testcase itself, no? :)
<seb128> dobey, I batched 2 fixes in one paperwork trail, most SRU reviewers are not that picky and let those in
<seb128> when fixes are easy ones that can be tested,reviewed easily
<seb128> but whatever
<seb128> that is more discussion time that the topic is worth, I bring it at UDS with the SRU guys
<dobey> well, i don't know if my opinion matters, but i generally agree with having a separate bug for separate fixes. it helps with tracking the changes, in case some regression happens later with the fix; and it provides better information to the users about what is actually getting fixed, when they upgrade and look at the changelog entries.
<dobey> oh well :-/
 * xnox is confused why sbuild pyside gives me sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not going to be installed
<slangasek> xnox: sounds like uninstallable or un-co-installable build deps
<xnox> slangasek: I wish it would either tell me, or filter out and use the other alternative build-dep =)
<slangasek> xnox: well, "it" is apt and apt doesn't give very good diagnostics in this case unless you crank the debugging up :)
<xnox> something tells me that building 4.7really4.6 versions strings with libqt4-dev (>= 4:4.7.0) is not going to go down that well.
<xnox> meh... off to play volleyball =)
<xnox> slangasek: well at least pbuilder-dist is smarter - phonon-backend-null : Conflicts: phonon-backend which is a virtual package. The following actions will resolve these dependencies: and goes off to install phonon instead of phonon-backend-null
<slangasek> sbuild used to be smarter too, until it switched to using apt as its build-dep resolver :/
<mitya57> barry, doko: was there any change in python3.3 that could cause it to think that file name is "<string>"?
<micahg> xnox: you might need --resolve-alternatives
<mitya57> (maybe for some objects that are not really files but python3.2 thought them were)
<mitya57> I can't find anything related in the release notes
<xnox> micahg: thanks, I'll try that..... while sbuild is nice I find pbuilder more out-of-the-box friendly. E.g. my customisation file for sbuild is longer than the one I have for pbuilder-dist.
<xnox> arguably pbuilder-dist is a config wrapper.....
<mitya57> doko: I've spent three hours on that issue, and I give up, at least for today :(
<mitya57> maybe the best idea will be to ping upstream and make them fix the issue themselves
<mitya57> barry: you said you know upstream â maybe you can do that? â bug is https://bitbucket.org/birkenfeld/sphinx/issue/1008/test-failures-with-python-33.
<ceolin> hey guys, someone c
<ceolin> can tell me if appmenu requires a patched version of gtk and qt ?
<hyperair> Laney: are you by any chance seeing GPU hangcheck messages and getting these short spurious hangs with unity in quantal?
<maco> what's that debian.org site where you can look up a package, and it tells you what versions are in each debian release and ubuntu release?
<slangasek> maco: packages.debian.org?
<broder> snapshot.debian.org
<broder> oh wait, what slangasek said i think
<slangasek> though I had never heard that packages.d.o tracked Ubuntu versions
<maco> no, the pink site
<slangasek> the what
<jibel> maco, http://qa.debian.org/madison.php ?
<maco> nope
<maco> shows the last few bugs reported on that package too
<slangasek> well, if it's not linked from dex.http://dex.alioth.debian.org/ubuntu/ then I really don't know
<jibel> maco, http://packages.qa.debian.org maybe ?
<maco> jibel: yeah! thanks!
<maco> woah, 7 digit bugs in lp! O_O
<maco> i thought i'd pasted the bug number wrong. wow
 * maco scrapes the rust off the old packaging knowledge
<Laney> hyperair: not noticed that, no
<TheMuso> doko: A mistake on my part.
<dupondje> Got a really strange issue with LightDM, sometimes when I boot, I see the console cursor on tty7 (trough the lightdm window). If I then switch to tty1 for example, I still see lightdm visible (only partly). Is that a known bug?
<netdur> a dialog out of nowhere started asking me (every few minutes) for my gmail password http://imgur.com/q5T1S,frM7j
<netdur> it is modal and doesn't say which program is requesting access
<slangasek> netdur: do you remember clicking 'Install' on an in-browser dialog asking you if you want to enable the gmail webapp?
<slangasek> I believe that's what's causing the dialog.  I agree that it's not a very clear dialog though.
<xnox> ScottK: did you happen to have CMake fixes to query python3.3-config for --includes and --ldflags already?
<micahg> xprop | grep CLASS will tell you what program it is
<slangasek> netdur: so a bug report against the unity-webapps-gmail package may be in order
<netdur> slangasek: no I did not, I was using gnome-shell, I decided to give unity a try and this started spamming me
<xnox> ScottK: or will you be looking at pyside?
<slangasek> netdur: well, unity-webapps-gmail is not installed by default, so I'm not sure how that would happen without an explicit user request
<slangasek> netdur: if it's not the gmail webapp itself, it might relate to Ubuntu Online Accounts.  Not sure what package that would be though; if in doubt, probably report a bug against unity
<netdur> slangasek: all right, I will report bug against unity but for now, how do I disable it?
<slangasek> netdur: I couldn't tell you, sorry
<darkxst> netdur, remove any extra accounts from GOA!
<darkxst> netdur, and/or evolution
<netdur> darkxst slangasek is this dialog trusted, can I just type password to make go away?
<darkxst> netdur, yes but you will have duplicate accounts setup (adding gmail accounts was broken previously and any attempts would have just been queued up
<ScottK> xnox: No and no.
<ScottK> You might ask OdyX about getting pyside to work with 3.3.  He sometimes cares about both it and Ubuntu enough to do something.
<xnox> ScottK: ok =) my CMake is a bit rusty, but it's like waf but in ALL_CAPS I should be ok =)
<ScottK> It's not at all like waf in any way that matters ...
<ScottK> debfx might be able to help with CMake.
<xnox> ScottK: it was meant to be a joke =) none of them are alike in any useful way. I did port a couple of packages from autoconf to CMake with cross-building to win & mac. I should figure it out =)
<xnox> there are 16 packages left, before I can start py3.3 by default rebuild
<ScottK> Well.  "Like waf" is fighting words ...
<ScottK> Up there with "Like yada".
<infinity> ScottK: Your face is like yada.
<ScottK> python-qt 4 is kicking my behind.  It won't make it today.
<ScottK> infinity: ouch.
 * ScottK makes a note for when he's feeling like a bit of D&D in Copenhagen.
<xnox> So I checked my Guide and indeed waf was inspired by scons, but neither have direct ancestry to CMake.
<maco> i cant figure out if these are real words you're all saying
<ScottK> yada was real, but it's, mercifully, dead now.
<maco> http://wiki.debian.org/UsingQuilt <-- useful page
<infinity> maco: They're not only real words, they're all expletives.
<maco> i just used quilt without getting T'd off for about the third time ever
<infinity> Although, as much as it caused me no end of grief, I can't deny that 'scons' always made me a bit hungry.
<mwhudson> family channel!
<maco> (and thats without having used it in like two years)
<ScottK> Waf upstream is sufficiently distro hostile that it's impossible, by design, to package it usefully.
<jelmer> ScottK: I don't think it's impossible to have it packaged, but working with him to come to a good solution will take time/patience.
<xnox> waf upstream is highly responsive to issues on obscure platforms e.g. hpux and patches are written and offered for testing really fast.
<ScottK> jelmer: DktrKranz tried.
<xnox> ScottK: jelmer: I don't by the whole argument that waf compressed bz2 is evil, yet distributing windows binaries in original tarballs is ok with ftp-masters
<xnox> s/by/buy/
<jelmer> ScottK: I've tried as well, and have worked quite well with him.
<xnox> see lintian lab emited tags for hundrets of instances.
<jelmer> ScottK: (Resolving other issues that is)
<ScottK> I'm going on the results of DktrKranz trying.
<jelmer> ScottK: DktrKranz's way of working with him was quite confrontational too, and that just made things worse.
<ScottK> Hmmmm.  That's not usually his style.
<ScottK> xnox: the difference, IIRC, is you don't need the Windows binaries to build the package.
<jelmer> ScottK: actually, I retract that. The tone from several Debian developers towards waf upstream was very confrontational, rather than constructive.
<ScottK> ok.
<xnox> ScottK: little did people know about some of the debian packages =)
 * xnox walks away grinning
#ubuntu-devel 2012-10-24
<infinity> barry: Can you SRU bug #938869 to precise as well?
<ubottu> Launchpad bug 938869 in lsb (Ubuntu Raring) "lsb_release crashed with SIGABRT in Py_FatalError()" [High,In progress] https://launchpad.net/bugs/938869
<infinity> barry: From my reading of it, it's just as buggy there, it's just that we haven't (yet) seen a a crazy upstream package that, say, sets a py3.2 PYTHONHOME and breaks python2.7.
<infinity> barry: (Of course, the realisation that every other python script in /usr/(s)bin is wrong is a bit scary, but lsb_release does seem to be called an awful lot in these sorts of scenarios)
<barry> infinity: indeed about the scary bit ;).  let me just verify that i can break it in precise and i'll sru it there to if necessary
<infinity> barry: http://paste.ubuntu.com/1301515/
<barry> infinity: cool
<infinity> barry: Do I smell an ammendment to Debian Python Policy and a mass bug filing in the future?
<barry> infinity: probably so.  i will be out tomorrow giving my talk, but i plan on at least bringing it up on the d-p list asap
<infinity> barry: I'm not sure if it's sheer luck that this hasn't broken more often, or just proof that most of the python stuff in /usr/bin is useless. :P
<barry> :-D
<infinity> I have always wondered why lsb_release isn't a shell script.
<infinity> Other than language flavor-of-the-month-ism.
<infinity> Which is probably the reason.
 * barry licks python
<barry> er
 * barry likes python
<infinity> *snicker*
<infinity> I can take it or leave it, but I could frame it differently.  I really like Perl, but I still think lsb_release should be a shell script.
<infinity> Cause it does, well.  Nothing.  And hardly needs the massive memory footprint and load time to do all that nothing.
<slangasek> infinity: why would you expect this to be common breakage?
<slangasek> setting PYTHONHOME and then invoking system utilities seems crackful
<slangasek> the only case I'm aware of that we've seen so far is with vmware
<barry> slangasek: and what vmware is doing is crackful
<slangasek> yep
<infinity> slangasek: I'd expect it to be common if more of those system utilities were actually called by crackful third parties.  Luckily, most of the crack they call is likely all binaries.
<barry> slangasek: -s makes some sense too, but i bet few users are putting anything in their user site directory
<infinity> slangasek: I didn't claim the crack should happen more often, just that I suspect it probably does happen more often, and those people just don't call python binaries in the midst of their crack.
<barry> slangasek: i'd say: it's an important thing to do when writing system scripts, but we needn't freak out about it
<slangasek> right, exactly
<infinity> And yeah, I agree that it's not worth a crazy freak out.  But a transition to -Es over time doesn't sound like the worst idea.
<infinity> Anyhow, this all just came about from my "if we're fixing it in Q and R, we should fix it in P" thing, that's all.  Since we have 4.5 more years of P, I'm sure VMWare will at some point start shipping a bundled python3 that breaks P the way their bundled python2 breaks Q. :P
<infinity> I'm such an optimist.
<barry> infinity: sru'd and uploaded
 * barry -> eod
<infinity> barry: Thanks.
 * infinity processes those and EODs himself.
<hyperair> RAOF: turns out turning off semaphores really improved matters, and it's seeing something like 40-70% RC6pp residency now.
<hyperair> RAOF: i'm suspecting that the semaphores were also causing the random hangcheck messages i was getting.
<RAOF> Cool.
<vibhav> Does anybody know how to setup a raring pbuilder chroot?
<tsimpson> vibhav: create a precise chroot, change the sources.list to raring, and do a dist-upgrade
<vibhav> ah, I thought there was another way to do that
<tsimpson> erm, quantal, not precise
<tsimpson> there are always other ways, you're using linux after all ;)
<tsimpson> as a quick hack, sudo ln -s /usr/share/debootstrap/scripts/quantal /usr/share/debootstrap/scripts/raring
<tsimpson> then just create a raring builder as you would a quantal one
<vibhav> tsimpson: clever :)
<tsimpson> vibhav: it's not that clever, once you realize that every release after gutsy only adds another symlink :)
<tsimpson> vibhav: try here please
<vibhav> !ping
<ubottu> another contentless ping... sigh...
<pitti> Good morning
<vibhav> hey pitti
<vibhav> or rather, guten Morgen :)
<pitti> vibhav: hehe :)
<vibhav> :)
<sarnold> pitti: another early morning? :)
<pitti> sarnold: yeah; it's actually kind of my normal time now, depending on wether/how long I manage to sleep again after my wife gets up
<sarnold> pitti: oof :) too early for me, by a long shot... but if it gives you an afternoon to yourself, hooray :)
<pitti> right, that's the nice thing about it, and we have had stuff planned for pretty much every afternoon this week
<sarnold> :)
<DktrKranz> jelmer: huh? I really don't remember me behaving "confrontational"
<DktrKranz> jelmer: I proposed some solutions, neither of those worked for Thomas, and I had better things to do than fighting
<DktrKranz> jelmer: if you can get him convinced, feel free to reintroduce waf anytime
<DktrKranz> .oO(then you'll have to fight with the software with ports, but that's another story)
<lifeless> DktrKranz: you saw jelmers next line right? : 11:14 < jelmer> ScottK: actually, I retract that. The tone from several Debian developers towards waf upstream was very confrontational, rather than constructive.
<dholbach> good morning
<seb128> dholbach, salut
<doko> barry, slangasek: maybe -E, but not -s for all scripts. call it the unix way to have user and local stuff precedence about system stuff
<vibhav> Is it true that new uploads will go to raring-proposed?
<pitti> vibhav: yes, https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html
<doko> xnox, I can understand --includes, but why --ldflags?
<vibhav> ah, I was not aware of that. That idea sounds good too, nevertheless
<vibhav> thanks pitti
<pitti> vibhav: no, it doesn't sound good
<pitti> it sounds OMGWANTTHISNOWGREAT! :-)
<vibhav> heh
<pitti> aka "never break dist-upgrades due to arch skew again"
<pitti> and breaking ubiquity with a new glib, pygobject, etc.
<vibhav> yeah, archive skews are something fearfull
<vibhav> /win 9
<mlankhorst>  /alias 9 win 9
<ailo-w> apw: Hi. Just wanted to ping you about -lowlatency. I'm the kernel team guy in Ubuntu Studio, and the one who posted about it in the kernel mail list last month
<apw> ailo-w, good timing ... i have just finished redoing the P one and uploaded it to the kernel team PPA
<apw> ailo-w, we could do with some help confirming it works ok; if it is then the trees are both in a similar state and 'ready'
<xnox> doko: to get the multiarch -L path. Unless I am doing something wrong and compiler is finding it anyway =)
<doko> xnox, I think this would be wrong, although you should search for libpython3.3m.so
<xnox> doko: ok.
<jml> How stupid would it be to write code that assumes Contents-amd64.gz is alpha-sorted by FILE field?
<mlankhorst> depends how easy it is to avoid that assumption :P
<cjwatson> jml: I believe it's reasonably well guaranteed to be in strcmp() order by file
<jml> cjwatson: thanks.
<cjwatson> If you can avoid that assumption, do, but I appreciate that that file is large
<jml> cjwatson: will do. I'll muck around a bit to see whether I get any significant speed gains by that assumption, and then make a completely irrational assessment as to whether they are worth it.
<sawrub> hello all developers, i just installed 12.10 and i'm facing the long seen problem with the Atheros AR9485 WiFi under UBUNTU. Is there any fix on the way. the people at Fedora seems to have fixed the issue long back in July https://bugzilla.redhat.com/show_bug.cgi?id=736435#c8
<ubottu> bugzilla.redhat.com bug 736435 in kernel "kernel network driver ath9k causes connection problems with TP-Link TL WN951 Atheros AR5008" [Medium,Closed: wontfix]
<cjwatson> sawrub: #ubuntu-kernel perhaps better
<sawrub> but i'mm still facing the lockdown issue
<sawrub> i'm not able to enjoy the wifi.
<cjwatson> Sure, I'm just directing you to an IRC channel that's more specialised
<sawrub> the only solution that i can find on the net is to use compact wireless
<sawrub> http://ubuntuforums.org/showpost.php?p=11347273&postcount=63
<sawrub> and what will that be
<cjwatson> 11:54 <cjwatson> sawrub: #ubuntu-kernel perhaps better
<sawrub> ok...let me ask there..thanks
<ion> EXT4 Data Corruption Bug Hits Stable Linux Kernels http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
<mlankhorst> please don't link phoronix :(
<ion> Please donât âplease donât link phoronixâ.
<mlankhorst> :D
<OdyX> xnox: about PySide, I welcome co-maintainers and try to avoid any distro diff as much as possible. The version currently in experimental is the latest upstream.
<xnox> OdyX: ack. Well shiboken currently fails to build from source in quantal & raring. with any python.
<xnox> OdyX: no 3.3 shiboken, no 3.3 PySide =(
<xnox> bug 1070772
<ubottu> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
<xnox> the bug is interesting, the unit test passes but upon clean up python interpreter itself segfaults after/during cleaning up floats. Maybe barry or doko can look into it ^^^^
 * xnox is rebuilding in debian at the moment to see if debian is affected as well or not.
<xnox> OdyX: in debian shiboken builds fine....
<OdyX> xnox: eh :) It looks like a ubuntu python bug to me
<doko> xnox, hmm, mpi4py had someting similiar, was fixed in http://launchpadlibrarian.net/120852567/mpi4py_1.3%2Bhg20120611-1_1.3%2Bhg20120611-2.diff.gz
<xnox> doko: I'd agree with you, but the unit test passes in shiboken case (no asserts about ref-counts) it's just python segfaults after the unit-test has passed and said so.
<xnox> and it segfaults all pythons after passing the unit test in Ubuntu, but everything is ok in Debian.
<xnox> e.g. 2.7, 3.2 and 3.3 segfault on ubuntu, but 2.7 & 3.2 on debian does not.
<barry> xnox: interesting.  i won't have time to look at this before i head to the conference today tho
<xnox> barry: ack =) have fun
<cjwatson> xnox: refcounting bugs are like malloc arena corruption - the crash is often well after the cause.  I wouldn't rule out a bug in the extension just yet if I were you.
<xnox> cjwatson: thanks for explanation. ok.
<cjwatson> valgrind might help a bit, though probably won't tell you what got the refcount wrong, only what acted on it (if it is indeed a refcounting bug)
<barry> xnox: also, try it with a debug python
<doko> dpkg: error: triggers ci file contains unknown directive ``time''
<doko> E: Sub-process /usr/bin/dpkg returned an error code (2)
<doko> never seen that
<philballew>  ubuntu open week starts in #ubuntu-classroom in 5 minutes
<xnox> stgraber: thanks for trianging to ibus. Do you think there should be "keyboard-inputs-indicator" which combines keyboars & input methods?
<stgraber> xnox: I guess having ibus merged into the main keyboard configuration dialog and indicator would make sense, though there's the problem that they are separate projects and very likely aren't talking to each other...
<xnox> stgraber: you'd think keyboard layout people would have a common interest in like keyboards.... =)
<doko> barry, xnox: well, it's interesting that shiboken ignores the return values of the -dbg test runs, so it looks like the maintainer didn't care about failing test cases ...
<ScottK> mitya57: A diff against Ubuntu for python-defualts isn't very helpful.  I'd really need to see the diff against current Debian.
<mitya57> ScottK: bzr diff -r 56
<mitya57> that's why I used Debian branch as a base :)
<ScottK> OK.
<ScottK> It'll have to wait until I have enough brain power to figure out using bzr for a review.
 * ScottK virtually never does that.
<infinity> slangasek: Are we meeting today?
<slangasek> infinity: yes
<infinity> slangasek: Mmkay.
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<ScottK> What's the equivalent of getattr(sys, "pydebug") for python3?
<ScottK> (that's still False in the python3.2-dbg interpreter)
<ScottK> barry: ^^^
<cjwatson> ScottK: "d" in sys.abiflags, possibly
<cjwatson> ?
<ScottK> Thanks.
<ScottK> sys.abiflags[0] == 'd' works, but feels ugly.
<cjwatson> ScottK: is it a good idea to depend on the order?
<ScottK> Probably not.
<ScottK> I guess 'd' in sys.abiflags[0] is less ugly.
<cjwatson> Why [0]?
<ScottK> err without the [0]
<cjwatson> Right :)
<ScottK> The lack of sys.pydebug in python3 seems odd, but I guess I'll move on.
<doko> ScottK, hmm, I didn't re-add it for 3.3
<ScottK> 'd' in sys.abiflags works, so I'm not stressed about it.
<alexbligh> If I am packaging an program which contains shared libraries, Lintian is warning me that "non-dev-pkg-with-shlib-symlink", which I'm guessing means the shared library symlinks should not exist in the package. I can remove them, but what is it that runs ldconfig on install?
<cjwatson> Those are two unconnected questions ...
<cjwatson> The point is that .so links should generally go in a -dev package, not in the runtime package, because the only thing that needs the .so links (as opposed to .so.N) is the linker (ld) when building other packages against this library, not the runtime linker (ld.so)
<cjwatson> ldconfig calls are inserted into your package's maintainer scripts by dh_makeshlibs
<cjwatson> Incidentally, you don't need to guess what lintian messages mean; you can use lintian-info.
<alexbligh> cjwatson, ah. So if this is a not a -dev package I can simply delete all symlinks in /usr/lib in the dist directory that the makefile for the undebianised things builds?
<cjwatson> The details of exactly how to arrange it for any given build system vary.
<cjwatson> Generally you install it into debian/tmp/ rather than debian/your-package-name/ (which dh_auto_install will do by default if you have multiple binary packages, as you should in this case) and then have dh_install pick the right files to put in each binary package.
<alexbligh> actually, per the lintian-info thing, I think this is harmless
<alexbligh> yes, it's actually a copy of the dist directory.
<cjwatson> It is not the worst lintian error you could have, but it *is* generally wrong and should be fixed.
<cjwatson> People expect shared library packages to be done in broadly the same way as all other shared library packages.
<alexbligh> cjwatson, there are are LOT of things wrong with this package - I'm sort of looking for a quick and dirty hack and repackaging xen.
<cjwatson> The exception is if it's a private library that isn't intended to be exposed outside this program, in which case you should put it in a private subdirectory of /usr/lib, not in /usr/lib itself.
<cjwatson> Yeah, I'm not going to advise you on how to do things wrong, though :-)
<alexbligh> cjwatson, I appreciate that :-)
<alexbligh> dh_shlibdeps seems to complain if I start deleting symlinks.
<alexbligh> so I'll guess I'll leave it in horrible hacked state for now.
<cjwatson> Eh, the point isn't to delete symlinks
<cjwatson> The point is to put them in the right binary packages
<alexbligh> cjwatson, sure; what I'm saying is that if it's permissible for a 'small package', it isn't the worst sin in the world to do it on a larger package. Given the other horrors I have to contend with, I'm putting this in the 'mostly harmless' box :-)
<alexbligh> (permissible per the lintian-info notes)
<cjwatson> Yeah, I read those notes after I said that and I think they're far too lenienet.
<cjwatson> Or misphrased.
<cjwatson> I have a 50KB library package which does it right.  Can't get much smaller.
<alexbligh> after all, xen4.2 is a really small package (cough cough)
<xnox> doko: my python3-defaults package may be slightly wrong, as I have a broken symlink
<xnox> /usr/lib/pkgconfig/python3.pc -> python-3.3.pc
<xnox> it should be
<xnox> /usr/lib/pkgconfig/python3.pc -> ../../$(arch)/pkgconfig/python-3.3.pc
<xnox> or better for python3.pc symlink to be in /usr/lib/$(arch)/pkgconfig/
<xnox> ScottK: in CMake pkg_check_modules(PYTHON python-3.3) actually does the right thing.... if packages build using PYTHON_INCLUDE_DIRS
<xnox> the FindPythonLibs.cmake included with cmake itself kind of assumes there will be a single non-abi qualified include dir, which is not the case for the multiarched 3.3
<ScottK> A quick grep of the PyKDE4 source suggests it does not.
<ScottK> sip4 will DTRT with multiple include dirs, but I had to patch python-qt4 configure to take advantage of that.
<xnox> ScottK: sorry, do you say that FindPythonLibs.cmake is correct, and it's just that my package is doing something odd?! Where is yout python-qt4 ?
<ScottK> No, I said sip4 handles it.
<xnox> ok.
<ScottK> I didn't look at cmake
<ScottK> python-qt4 is ~done.
<xnox> ack.
<ScottK> Here's the configure patch: http://www.riverbankcomputing.com/pipermail/pyqt/2012-October/032049.html
<ScottK> In case you were wondering.
<xnox> Ah, I see what you did there =)
<xnox> nifty
<doko> xnox, meh, yes, but it's an arch indep package ...
<doko> would be nice if pkgconfig had a predefined multiarch macro when called as <triplet>-pkgconfig
<jdstrand> barry: hi! do you think that you could poke someone on http://bugs.python.org/issue13512? (CVE-2011-4944) the last comment is that it will be ported to 3.2 soon, but nothing happened with it. I fixed this in py3.2 in quantal with 3.2.3-6ubuntu3.1, but raring 3.3 and 3.2 need it
<ubottu> Python 2.6 through 3.2 creates ~/.pypirc with world-readable permissions before changing them after data has been written, which introduces a race condition that allows local users to obtain a username and password by reading this file. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4944)
<jdstrand> barry: it isn't a big deal, but it would be nice to get it applied upstream
<xnox> doko: last time this was brought up by wookey ( i think ) the "meta-packages" to select the default arch:any packages should also be arch:any.
<xnox> Otherwise multi-arch will not be able to do it's multiarch magic.
<xnox> cause it will not know how to do an M-A jump arch:all -> arch:any dep.
<doko> yeah, at least the libpythonX.Y-foo packages have to
<xnox> doko: where foo is dev ?
<xnox> =)
<doko> as dev, stdlib, etc
<xnox> well all of them to be honest.
<doko> haven't to be all, I think. why the packages with the binary symlinks?
<xnox> because otherwise I will not be able to do build-dep python3:any
<doko> hmm, maybe
<doko> ohh I hate this multiarch stuff now
<doko> xnox, should fixed packages be uploaded to the ppa, and then copied to the distro?
<xnox> doko: I am not sure =) but for one package I uploaded into both.
<xnox> doko: plus this round of uploads has slightly wrong changelog entries (i didn't pass --nomultimaint to dch, while my ~/.devscripts was setting it)
<xnox> so currently there are [ Joe Bloggs ] * Rebuild for python3.3 -- Dmitrijs Ledkovs
<xnox> entries =/
<xnox> doko: are you fixing up python3-defaults?
<doko> well, fixing will be splitting the packages ...
 * xnox haven't worked out how to bump the version in debian/changelog yet still have packages matching in version number with the real pythonX.Y default version number.
<xnox> doko: create .pc symlink at postinst? =)))))
 * xnox hopes slangasek doesn't notice this suggestion.
<doko> well, as a quick fix I consider adding this link into the libpython3.3-dev package
<doko> and removing it from the python-defaults package
<xnox> doko: but how would libpython3.3-dev know it's the default?
<slangasek> good way to avoid me noticing
<slangasek> since I have /hilight and /ignore confused
<doko> xnox, because it will be in the ppa
<xnox> doko: ok. what about the real fix.
<slangasek> what .pc files are you talking about?
<doko> later, not before uds
<slangasek> why would a .pc file not be shipped in the per-arch directory?
<xnox> slangasek: python3-dev ships symlink python3.pc -> python3.X.pc
<slangasek> ok, so if it wasn't already clear, python3-dev needs to be Arch: any
<xnox> slangasek: currenlty python3-dev is arch:all package, but since 3.3 is multiarched, the meta-packages should be "multi-arched" as well, which for really means arch:all -> arch:any
<slangasek> I have filed bugs in the past about this - python(3)-defaults need to be made arch: any
<slangasek> doko: ^^ you understand this, right?  We need to be able to specify the needed architecture of python3-dev for cross-building
<xnox> slangasek: all packages it builds? I looks like -doc can stay as arch:all, not sure about idle3 (it has python3 = ${binary:version} so probably arch:all as well)
<doko> slangasek, I do understand that it's not needed to make 3.3 the default. that's the priority for now
<slangasek> xnox: yes, sorry, was being overly brief there
<xnox> doko: the boost-defaults builds all packages as arch:any
<slangasek> doko: true
<xnox> ack.
<slangasek> xnox: AFAIK the only one we care about is -dev
<slangasek> doko: it's not the immediate priority, but it does need to be solved this cycle; I filed a bug about this about a year ago, and it blocks cross-bootstrapping
<doko> so, I'll prepare an python3.3 upload for the ppa
<xnox> slangasek: I thought we equally care a lot about "Build-Dep: python3:any"
<xnox> doko: thanks.
<slangasek> xnox: you only build-depend on python3 (instead of python3-dev) when you aren't building C extensions; therefore you don't care about the architecture of python3 being installed; so it can be Arch: all and rely on arch-all build-deps being implicitly Multi-Arch: foreign
<doko> slangasek, there will be so many python cross build failures ... none of the various python build systems supports cross building
<slangasek> doko: that's beside the point.  Not having Arch: any python3-dev is *blocking* fixing those things.
<doko> slangasek, you didn't, at least not for python3-defaults
<slangasek> doko: possibly the bug was only filed against python-defaults.  I can open a new task :)
 * xnox slangasek's bugs outlive python2
<doko> slangasek, better file a new one, your memory seems to be corrupted ;-)
<slangasek> doko: bug #934593, which you closed and didn't reopen after you reverted the change! :)
<ubottu> Launchpad bug 934593 in python-defaults (Ubuntu Precise) "python-all-dev, python-dev must be Arch: any for multiarch" [Medium,Fix released] https://launchpad.net/bugs/934593
<slangasek> (bug reopened)
<doko> ahh, that one
<xnox> So to fix the bug correctly: python3-dev should be arch:any package with symlink /usr/lib/$(arch)/pkgconfig/python3.pc -> python-3.X.pc
<slangasek> yes
 * xnox off to have dinner and will poke python3-defaults after that.
<doko> xnox, how do you track the packages which you fix for the test rebuild?
<doko> http://people.canonical.com/~xnox/py3.2/python3.2.html doesn't show any progress
<doko> slangasek, xnox: the proper fix is to split out libpython3-{stdlib,dev,dbg} packages *and* make all of these arch any
<slangasek> doko: what's the purpose of python3-dev, that would make it different from libpython3-dev/
<doko> slangasek, having the python3.3-config binary
<slangasek> doko: and is it really useful to split the python3-dev package just for python3.3-config?
<slangasek> it seems obvious to me that making python3-dev Arch: any is much simpler
<doko> probably simpler, but how do you install a host interpreter, plus a target python-dev?
<doko> most python build systems do use python as implementation for the build system
<slangasek> python3-dev Arch: any Depends: python3.3-dev Arch: any Depends python3.3:any, with python3.3 as Multi-Arch: allowed?  (Or Depends python3.3 with python3.3 as Multi-Arch: foreign, whichever is correct)
<doko> why should it be allowed, and not same?
<slangasek> assuming you mean foreign rather than same (since same is definitely wrong for an interpreter package): "allowed" would be correct if it contains libraries as well as the interpreter, otherwise "foreign"
<doko> well, libpython3.3-dev is m-a same, as libpython3-dev would be too
<slangasek> if libpython3.3 is M-A: same, and all the library bits are in libpython3.3, then python3.3 can probably be M-A: foreign
<doko> right, libpython3-{stdlib,dev,dbg} would be m-a same, and python3{,dev,-dbg} would be m-a foreign
<slangasek> doko: er, except then you're changing the policy for python build-dependencies
<doko> but then how do I build not using the "target" interpreter?
<slangasek> doko: right now, packages that build extensions build-depend on python3-dev.  Splitting libpython3-dev out of python3-dev, and making python3-dev M-A: foreign, means packages would have to build-depend on libpython3-dev to be cross-buildable
<slangasek> doko: apt will prefer to install the host version of any package that's marked Multi-Arch: foreign
<doko> yes, this was my intention
<slangasek> oh, I think I see the issue now
<slangasek> /usr/bin/python3-config is not the same on all architectures, right?
<slangasek> so it can't be in a M-A: same package
<doko> yes
<slangasek> ok
<doko> currently it's meaningless because it's written in python, but it will be replaced by a shell script again
<slangasek> so actually, I'm not sure it matters to have python3-dev as M-A: same... if it's M-A: none, it should still work
<slangasek> then when cross-building, Build-Depends: python3-dev gets you the target arch version of python3-dev and the host-arch version of python3
<doko> and python3.3-dev depends on python3.3, with  a different binary too
<slangasek> you can't install more than one copy of python3-dev side-by-side, but for a first pass I don't think that's required
<doko> ok, then let's delay the split of the python3-defaults packages for now
<slangasek> "python3.3-dev depends on python3.3" but that's ok, isn't it?  You should be able to use python3.3-dev:target + python3.3:host
<doko> no
<slangasek> why not?
<doko> I can't see how this would be right
<doko> if the build uses information from the sys or sysconfig modules, then these will come from the host, not the target
<slangasek> if I'm not mistaken, it's right because python3.3 is *just* the interpreter, and python3.3-dev depends on the interpreter (which is Multi-Arch: foreign) + the lib (which is Multi-Arch: same)
<slangasek> ok
<slangasek> but that's a problem with the build system not being cross-build-safe
<slangasek> I don't think there's any rearrangement of the interpreter packages that we can do to fix that
<slangasek> installing the target-arch python3.3 doesn't solve the problem for a true cross-compile situation where you don't have qemu
<slangasek> (such as, to pick a random example, aarch64)
<doko> yes, known
<slangasek> So I think python3.3-dev:target + libpython3.3:target + python3.3:host is still correct, and we just have to defer the fact that many build systems aren't cross-compile safe
<doko> the trick for distutils I am using is to set an env var to use the host python with the target standard library
<slangasek> but in the base system, there are a lot of *non*-python build systems being used which are cross-build-safe, they just need the right libpython available
<doko> which works ok, as long as I'm only relying on sysconfig, not on the builtin sys module
<slangasek> right
<doko> indeed, and my idea was to have these packages now build-depend on libpython3-dev
<slangasek> I still think it's better to keep everything build-depending on python3-dev; that way it doesn't require changing python policy or changing build-dependencies, and that change doesn't help cross-compile without qemu anyway so I think we should take our time to look for a better solution for those
<ScottK> Help.
<ScottK> In debian/rules for python-qt4, I have: configure: $(PYTHONS:%=pyqtconfig-%) $(PYTHONS:%=build-%/configure-stamp) $(PYTHONS:%=dbg-build-%/configure-stamp)
<ScottK> I've added the $(PYTHONS:%=pyqtconfig-%) rule.
<ScottK> If I run make -f debian/rules configure, then the pyqtconfig rule runs.
<ScottK> But when I build the package, it does not (even though the build/dbg-build rules do)
<ScottK> Any suggestions?
<doko> slangasek, well, that would be brainstorming session for uds. I don't think that it will require a change to the python policy, as everything still builds, and python policy doesn't touch multiarch. and the b-d change ... how many packages are cross-buildable out of the box anyway
<slangasek> ScottK: are you cleaning in between?
<slangasek> doko: python policy says what build-dependencies are supposed to be
<ScottK> No.
<slangasek> ScottK: is pyqtconfig-$ver a real file?
<slangasek> (pointer to source?)
<ScottK> No.
<ScottK> Let me publish this somewhere.
<doko> slangasek, so yes, keep it unchanged, change it where it's needed for m-a
<slangasek> doko: ok.  in the meantime, will we still get Arch: any python3-dev?
<slangasek> because that's still a blocker
<doko> yeah, for the first milestone
<slangasek> great, thanks :)
<ScottK> slangasek: http://kitterman.com/kubuntu/python-qt4_4.9.5-1ubuntu1.dsc should be dget'able.
<slangasek> dgotten
<ScottK> Thanks for having a look.
 * ScottK needs to get up off the keyboard.
<slangasek> do I need raring in order to build this, or should it be quantal-compatible?
<ScottK> off/from
<ScottK> You need raring.
<slangasek> ok
 * slangasek gets his raring chroot set up while looking
<ScottK> Actually, or my PPA.
<doko> ScottK, any quick idea where to fix the missing python include in boost?
<ScottK> doko: None.
<ScottK> ajmitch loves boost though.  Maybe he does.
<ajmitch> you're always trying to drop me in it
 * doko looks if he succeeds ...
<slangasek> ajmitch: doesn't knowing that you're wanted give a boost to your self-esteem?
<ajmitch> slangasek: that pun certainly causes tears
<slangasek> you're welcome
<xnox> doko: that page is *static* :-D
<Laney> xnox: I have a cool idea about ben
<Laney> it's in the skunkworks atm
<xnox> Laney: what processing ~/transitions/ ? Or scp'ing ben.native? =)
<jcastro_> Riddell: heya, you going to be @ UDS for the flavors plenary? I sent a mail to kubuntu-devel.
<cjwatson> doko: cross-buildable out of the box> possibly more than you'd think, at least as of quantal (or even precise); it's not great, but it's not completely hopeless either
<xnox> Laney: is ben backported to 12.04?
<doko> cjwatson, I'm just having my doubts with python related cross builds ...
<cjwatson> I think we had half the build system cross-building?
<cjwatson> er base system
<cjwatson> sure, I expect python's ecosystem will take a while :)
<doko> now trying to understand jam, to fix boost ...
<ScottK> At least I saved you dealing with sip.
<doko> ScottK, sip4 builds did finish, didn't see the python-qt4 upload ;-P
<ScottK> Not quite there yet.
<slangasek> ScottK: well, one thing is that you define a target for pyqtconfig-3.% but are patterning over $(PYTHONS) which includes python2
<slangasek> oh, but you have an explicit pyqtconfg-2.7 below
<ScottK> Yes.
<slangasek> so I suppose that should work
<ScottK> Running configure directly failed without that.
<ScottK> Switching to like I had it in sip4 doesn't help either.
<ScottK> configure: $(PYTHONS:%=build-%/configure-stamp) $(PYTHONS:%=dbg-build-%/configure-stamp)
<ScottK> build-%/configure-stamp: $(PYTHON3S:%=sipconfig-%)
<slangasek> +install-arch-3.%: pyqtconfig-%
<slangasek> that seems wrong?
<slangasek> (but is probably not relevant)
<slangasek> ScottK: oh; when I asked if these were real files you said they weren't
<slangasek> ScottK: but you're clearly touching them
<ScottK> They are real after I touch them.
<slangasek> so if you don't clean between builds, they won't be remade
<ScottK> Right, I remove them in clean.
<slangasek> ok
<ScottK> The problem is they never get touched at all, so I know the rule never ran.
<xnox> ScottK: or make sure the target ends in -stamp, then it will be auto-removed for you.
<xnox> with dh_clean.
<xnox> hm..
<ScottK> xnox: More automagic after it works.
<xnox> =))))))))))
<xnox> mvo are you about?
<ScottK> The install-arch thing is a leftover of a previous attempt.
<slangasek> ScottK: ah.  Nothing actually depends on your configure rule.
<ScottK> Hmmm.
<ScottK> That would do it.
<slangasek> the configure target depends on the configure-stamp targets; it should normally be the other way around...
<slangasek> er, no
<slangasek> that part is right - but then things should depend on configure instead of directly on the stamps
<slangasek> probably simplest to make the build-arch target depend on configure
<ScottK> OK.
 * slangasek tests
<slangasek> looks good-ish so far
<ScottK> I need to leave for the evening, so if you make it work, feel free to upload, although I'm not sure all the pushing stuff around in install-arch related to pyqtconfig is right (since I didn't ever test it yet)
<slangasek> gah, now you're going to make me review the whole diff :P
<ScottK> That or pm me yours and I'll finish it later.
<xnox> python3, arch:all package only needs to be built once with 'python3' interpreter with correct forward looking X-Python3-Version tag. Because pycompile does the rest at install time and there are no python3.X specific files/paths generated.
<xnox> True or False?
<Riddell> jcastro_: yeah I got that, no immediate volunteers from the community so sign up my name
<slangasek> xnox: TTBOMK that's correct
<xnox> slangasek: good.
<doko> xnox, I still would build for all supported versions to check for incompatibilities
<doko> an issue which currently not addressed is how to detect any diff
<xnox> doko: ok. but Build-Dep: python3 && building against py3versions -s is wrong =)
<doko> sure
<wookey> if this doesn't work: from util import get_fh_out
<wookey> what package am I missing?
<slangasek> wookey: that doesn't appear to be a standard python module.  What's the context?
<wookey> running 'multiarchify.py from johannes' bootstrap tools
<wookey> Ah OK, maybe that's why I can;t find it - must be in the rest of his code somewhere
<slangasek> must be
<wookey> I assumed there was some standard module
<wookey> ah yes - found it
<wookey> that script munges a packages file to make everything arch:all, M-A:none into M-A: foreign, which should woork round difference between ubuntu apt and libdose
<wookey> attempting to check this...
<xnox> doko: if you really want to build arch:all against all supported py3s then reject auto-upgrade-testing and feedparser and I will reupload fixing the build-deps to be python3-all, instead of building with python3 only.
<doko> xnox, rejected
<xnox> ack.
<xnox> doko: hmm... did you reject my proposal to reject those packages and hence accepted them. Or did you accept by mistake?
 * xnox is confused
<xnox> I just wanted to point out that drinking decaf coffee is great after 9pm =)
<chrisccoulson> xnox, drinking fully caffeinated coffee after 9pm is even better :)
<slangasek> nah; after 9pm you're just supposed to add whiskey to it to balance it out
<mwhudson> one of the pitfalls of uds is that it's easy for _everything_ you drink to contain alcohol or caffeine
<slangasek> mwhudson: I don't understand
<slangasek> how is this a pitfall? ;)
<mwhudson> (or, occasionally, both)
<mwhudson> slangasek: dehydration isn't a barrel of laughs :-p
<xnox> mwhudson: but one barrel whiskey is :-P
<barry> slangasek: hopefully you're not going to propose a foundations vs kernel team drinkoff
<slangasek> mwhudson: I prefer to think of it as distilling my inner geek
<StevenK> barry: That could end up with a large trip to the hospital
<mwhudson> xnox: i dread to think how much decent whisky is going to cost in the hotel bar
<barry> StevenK: i suppose i better pack my portable stomach pump
<StevenK> barry: Haha
<xnox> mwhudson: well, we are suppose to judge everything by mobile metrics now. So surely smaller in size, higher value and better kick is on the right path ;-)
#ubuntu-devel 2012-10-25
<ajmitch> mwhudson: stock up on the flight over?
<mwhudson> ajmitch: i guess duty free in london, yeah
<Tohuw> So, besides the apparently unmaintained procmon for Linux, how can I view a running snapshot of system calls in Ubuntu a la SysInternal's ProcMon for Windows?
<sarnold> Tohuw: probably strace is what you're looking for
<Tohuw> sarnold: Quite possibly, but how can I get strace to continuously follow. For example, "strace firefox" gives me very helpful data right up until firefox is fully launched, then quits. I played around with follow options and could not achieve what I want: follow system calls indefinitely
<slangasek> Tohuw: '-ff'
<Tohuw> slangasek: nope, still exits
<slangasek> mmm
<Tohuw> Ah, it's something to do with how firefox spawns the process. This works fine in gedit. I'd still like to see an easy option for monitoring *everything*
<slangasek> well, there are a few tools for monitoring everything, but nothing particularly easy AFAIK
<Tohuw> It's handy to see all the changes and system calls everything on the system is making. Yes, it spawns very, very long logs, but it's still wonderful
<pitti> Good morning
<obounaim> Good morning pitti,
<sarnold> Tohuw: hrm. if strace -f firefox doesn't actually follow all children of firefox, please file a bug.
<sarnold> Tohuw: if you want to see more system calls than just firefox, look into auditd; it can be configured to dump system calls and results. It is _extremely_ verbose, so be careful. :)
<vibhav> Good Morning
<vibhav> Hmm, /win 6
<vibhav> Sorry
<vibhav> The toolchain will be uploaded today, right?
<vibhav> ( according to https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule)
<dholbach> good morning
<darkxst> TheMuso, I hear you are from my part of the world
<pitti> wookey: FYI, pcre3 can be synced, newer upstream version in Debian contains newer config.{guess,sub} with aarch64; doing now
<pitti> wookey: (in case you are looking at merges)
<pitti> we need the new version for current glib
<pitti> infinity: OOI, why do we have all those armel/armhf PPA builders? do the "blessed" PPAs not use the distro builders any more?
<pitti> infinity: or do we plan on enabling arm for PPAs in general?
<pitti> cjwatson, doko_: is the thawing of raring blocked on doing some toolchain merges? (I'll do cdbs now) or do we want to wait for the "everything to -proposed" magic?
<dpm> pitti, cjwatson, could any of you add me to the uds-organizers team in LP? I'm told that as a track lead it will enable me to approve blueprints for the app dev track. Or do I need to send an e-mail to the Tech Board to request membership?
<pitti> dpm: added you
<dpm> excellent, thanks pitti :)
<pitti> cjwatson, doko: cdbs uploaded FYI
<ailo-w> Hi, I was wondering if someone could help me with tips on creating some blueprints. Like those done here https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio. I can see how I create one blueprint, like this one https://blueprints.launchpad.net/ubuntu/+spec/ubuntustudio-q-documentation. My question is, how do I create dependencies?
<cjwatson> pitti: waiting for the "everything to -proposed" stuff to finish landing; also I believe infinity is planning on a glibc upload
<cjwatson> pitti: the armel/armhf PPA builders are part of urgent work being done for PS
<pitti> cjwatson: ah thanks; so we are not particularly blocked on merges
<cjwatson> No
<pitti> cjwatson: so we have PPAs which can build for ARM now? nice!
<cjwatson> Well
<cjwatson> Only on explicit request and I think currently intended only for specific clients of the system
<cjwatson> I don't know the full details
<pitti> right, I didn't mean "all PPAs", just that they exist
<cjwatson> Some are Pandas, but they have no useful security and are very limited-access
<cjwatson> Most of the rest are qemu instances running on x86 boxes, AFAIK
<ailo-w> ..never mind. I'll ask someone specifically :)
<infinity> cjwatson: The pandas should be all gone from the PPAs.
<cjwatson> Good.
<cjwatson> Ah yes, mizar's now a disabled distro builder rather than a disabled PPA builder. :-P
<infinity> cjwatson: Yep.
<infinity> cjwatson: There's some vague hope that it won't be disabled after a reinstall.
<infinity> jodh: Around?
<infinity> jodh: Witness pitti's back-to-back commits to glib to first use __abort_msg, and then not:
<infinity> jodh: http://git.gnome.org/browse/glib/commit/glib/gtestutils.c?id=da66897950431870390f8dc3f798e24f23ffb8c8
<infinity> jodh: http://git.gnome.org/browse/glib/commit/glib/gtestutils.c?id=3658727cfa0eca8c66bc2cdff46992099caf0acd
<infinity> jodh: Methinks that NIH should just follow in the same footsteps here, regardless of how and when apport catches up.
<tjaalton> is raring open yet?
<infinity> tjaalton: It exists, but it's frozen while we hammer out some last-minute bits.
<tjaalton> infinity: ok, thanks
<infinity> jodh: And, in fact, I see no indication that apport was ever changed to embrace glib's method.  And one can only assume just due to its much larger number of consumers, that glib aborts far more often than nih.
<infinity> pitti: Say, am I missing something there, BTW?
<pitti> infinity: I initially wanted to re-use glibc's symbol, but was then told not to
<pitti> see gnome bug 594872
<ubottu> Gnome bug 594872 in general "Support storing assertion messages into core dump" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=594872
<pitti> infinity: so apport and friends now need to check both symbols indeed
<infinity> pitti: Yeah, reusing glibc private symbols is totally Bad and Wrong, I agree.
<pitti> eek, but indeed Apport doesn't
<infinity> pitti: I meant am I missing... Yeah. :)
<jodh> infinity: agreed. __nih_abort_msg or similar, as mentioned on bug 997359.
<infinity> pitti: So, let's fix apport to DTRT for glib.  And let's fix NIH to follow in glib's footsteps, and make apport also check for __nih_abort_msg, and life will be good.
<ubottu> Launchpad bug 997359 in libnih (Ubuntu) "nih uses eglibc private symbol __abort_msg" [High,Confirmed] https://launchpad.net/bugs/997359
<infinity> jodh: Right, shall we JFDI?  I'd love to see it finally not be an issue.
<jodh> infinity: yeah, i'm keen :)
<infinity> jodh: (Given I'm prepping a pre-opening glibc, this is part of the reason I suddenly care.  I'd like an nih landing first that doesn't have the *&#@%# private symbol linkage, so upgrading isn't a silly bootstrap dance)
<infinity> It also, interestingly, will take a pretty big load off apt's resolver on upgrades, I suspect.
<infinity> Given the importance of both libnih1 and libc6, and the messed up dependency apt needs to sort on every new upstream glibc...
<jodh> infinity: ok. I'll get this fixed in NIH upstream first...
<cjwatson> (this should be today, BTW; there's a decent chance the other blocker to opening will be resolved by EOD)
 * infinity gets back to glibc, to see about hitting this EOD deadline.
<hrw> will all raring uploads have to wait for approval?
<cjwatson> No
<stgraber> no, archive is just not opened yet
<cjwatson> Not long now
<hrw> ok, I uploaded first part of my cross compiler update to raring gcc
<xnox> So apparently  I need autoconf2.63 to build postgresql-9.1 which briefly existed in karmic&jaunty. pitti, do you have a stash of old autoconf?
 * xnox has a patch to make it build against py3.3 by default but it needs autoconf run =/
<pitti> xnox: uh? I'm building 9.1 just fine on lucid to quantal and squeeze to unstable with 2.69
<pitti> (or whicever is the default)
<pitti> xnox: oh, autoreconfig doesn't work?
<xnox> pitti: yeah, you can build but cannot patch configure.in & regenerate configure =)
<xnox> configure.in:22: error: Autoconf version 2.63 is required.
<xnox> Untested combinations of 'autoconf' and PostgreSQL versions are not
<xnox> recommended.  You can remove the check from 'configure.in' but it is then
<xnox> your responsibility whether the result works or not.
<pitti> xnox: https://launchpad.net/ubuntu/+source/autoconf/2.63-3ubuntu1/+build/988278 ?
<xnox> =)))))
<xnox> i386 build of autoconf 2.63-3ubuntu1 in ubuntu karmic RELEASE produced these files:
<xnox> autoconf_2.63-3ubuntu1_all.deb (deleted)
<pitti> oh, I thought LP would never forget anything
<cjwatson> We eventually expire pre-release binaries
<cjwatson> Though only several years later
<pitti> xnox: well, the source is still there, so I guess you could jusjt build it locally
<xnox> I found this build: https://launchpad.net/ubuntu/karmic/amd64/autoconf/2.63-2ubuntu1
<xnox> I think I'll do the reconf in a chroot.
<pitti> infinity: fixed in apport trunk, thanks for pointing out!
<infinity> pitti: shiny.  bug 997359 has apport tasks too, for after jodh settles on a symbol name (which, I assume, will be __nih_abort_msg)
<ubottu> Launchpad bug 997359 in libnih (Ubuntu Raring) "nih uses eglibc private symbol __abort_msg" [High,Confirmed] https://launchpad.net/bugs/997359
<pitti> infinity: right, that's straightforward to add then
<pitti> well, writing a test for it requires a build dep on libnih-dev, but oh well
<pitti> I'll make it fail gracefully if it's not there
<fabbione> morning guys
<fabbione> doko_: you around?
<pitti> hey fabbione, how are you?
<fabbione> pitti: doing ok.. waiting for you guys to show up in CPH for UDs
<fabbione> pitti: you?
<pitti> quite fine, thanks! looking forward to UDS indeed
<fabbione> and the beer... ;)
<fabbione> pitti: is doko_ still in charge of toolchain?
<fabbione> i think i found a bug in gcc, but i need to confirm
<pitti> yes
<fabbione> ok
<xnox> barry: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-python3 and https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python-versions are suspiciously similar
<seb128> xnox, barry: would be good to merge both, I doubt we have lot to discuss for desktop on the topic
<seb128> xnox, barry: I can drop the desktop one from the UDS schedule if that works for you
<xnox> seb128: if there specific packages you'd like to turn into workitems feel free to add them on foundations-r-python-versions spec. It was meant to be a "low-entry" for workitems =) as there is plenty to do.
<xnox> seb128: that would be best. Yes, please. =)
<seb128> xnox, ok, we don't have much remaining for desktop ... mostly system-config-printer that we plan to deprecate (it has its own blueprint) and u1 (which is rather u1 team than us)
<pitti> seb128: software-center?
<xnox> seb128: yeap & yeap. There is a big software-centre bit, but it's blocked on xapian, last time I checked.
<seb128> pitti, I don't consider that to be ours :p
<seb128> ours == desktop
 * seb128 looks at mvo
<pitti> ah, "team" vs. "image"
<xnox> seb128: what the pretty wallpapers? =))))
<seb128> pitti, yeah, we were speaking about merging foundation and desktop blueprints
<seb128> so I was on "what items on what team plate"
<seb128> U1 is also an issue
<seb128> but that's on online's services plates
<xnox> pitti: in which shape, form and where do you prefer postgresql patches?
<pitti> xnox: preferably, sent to pgsql-bugs@postgresql.org
<pitti> xnox: I'm happy to backport it to Debian then
<pitti> xnox: I'm on that list, so I'll see it
<pitti> xnox: (no need to be subscribed to post)
<xnox> pitti: I kind of want it into raring-proposed now, it's one of few packages that ftbfs with py3.3 by default.
<xnox> pitti: Ok, I'll submit the patch & upload into staging PPA and then we can decide where else it can/should go.
<pitti> xnox: well, go ahead and upload it then :) but please send it to upstream, too
<xnox> ack.
<pitti> xnox: I can grab the patch from LP, etc.
<pitti> or grab the upstream committed variant from git, etc.
<xnox> I cannot login into summit.ubuntu.com because of bug 881019 who can I contact about this?
<ubottu> Launchpad bug 881019 in Launchpad itself "Lp login is broken after account merge" [High,Triaged] https://launchpad.net/bugs/881019
<cjwatson> xnox: #is internal
<cjwatson> xnox: (though you might need to wait for US webops to come online)
<xnox> cjwatson: ack. thanks.
<infinity> pitti: http://launchpadlibrarian.net/121078084/libnih_1.0.3-4ubuntu11_1.0.3-4ubuntu12.diff.gz <-- Should indicate what apport needs to do to support libnih being fixed the same way as glib.
<apw> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: apw
<pitti> infinity: yep, will do
<infinity> pitti: <3
<cjwatson> slomo: Sorry, I'm going to reject these gst-* uploads.  Firstly, they'll be auto-synced tomorrow or thereabouts anyway, and it's better to have that ancestry where we can.  Secondly, if we just wait for a few more hours then they get to go through the -proposed migration stuff.
<xnox> I think lubuntu is smaller than libreoffice source package.
<slomo> cjwatson: ok, sorry
<cjwatson> (which will decrease risk of things being uninstallable)
<cjwatson> I understand dual uploads late in the cycle, but at this point I wouldn't recommend bothering :)
<tjaalton> i made a dodgy upload of xorg-server to quantal-proposed, could an archive admin drop it from the queue?
<pitti> tjaalton: there are two uploads
<pitti> tjaalton: drop the older one and keep the newer one? or otherwise?
<tjaalton> pitti: yeah the first one had an extra (disabled) patch on it, but they both were from the wrong branch :) mlankhorst, is it ok to push anyway?
<pitti> tjaalton: ah, so reject both?
<tkamppeter> pitti, chrisccoulson, you remember that (probably on Monday) I complained on this channel that Thunderbird clogged up my SSD with a 27G mailbox file from my Canonical Inbox? It seems that I got hitten by bug 1068921.
<ubottu> Launchpad bug 1068921 in Mozilla Thunderbird "Mailbox grows endlessly, heavy traffic" [High,In progress] https://launchpad.net/bugs/1068921
<tjaalton> pitti: yeah, i'll fix it later today
<pitti> tjaalton: ok, rejected both
<tjaalton> thanks
<bjaanes> Can someone here explain why dash does not show amazon results in Norway?
<Laney> cjwatson: can you help us with an ubuntu-desktop packageset query perchance? rhythmbox isn't in it. Do you know why?
<Laney> also seeded-in-ubuntu rhythmbox doesn't show it being seeded (only -dbg/dev/doc)
<seb128> bjaanes, that would be a question for the u1 guys, either bug or amazon doesn't provide that service in Norway
<stgraber> Laney: should seeded-in-ubuntu return anything at this point? I thought it was parsing .manifest and .list which we don't have yet (as we didn't spin any raring image yet)
<bjaanes> seb128, okey how can I get in touch with them?
<Laney> perhaps it is looking for raring-* - I thought it was just grabbing all the latest .manifests
<pitti> cjwatson: btw, we haven't forgotten about/ignored your britney/autopkgtest mail, but we need to fight with some firewall/set up http server etc. stuff
<Laney> stgraber: ah, yeah, it excludes all supported releases
<brendand> what is the source package of ubuntu-bug?
<Laney> laney@iota> dpkg -S /usr/bin/ubuntu-bug                                                                                                    ~
<Laney> apport: /usr/bin/ubuntu-bug
<barry> xnox, seb128: thanks for collapsing those blueprints down to foundations-r-python-versions.  also, don't forget the 13.04 spreadsheet of work: http://tinyurl.com/93kpvef
<barry> seb128: please review and add or let me know if anything obvious is missing
<seb128> barry, ok
<xnox> barry: thanks =)
<xnox> barry: about half of the rebuilds are done now in a ppa https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3
<barry> seb128, xnox: thanks guys.  oh and yeah, xapian is still a painful blocker.  last time i chatted with mvo about it, he thought there might be work underway to put a dbus front on xapian, which would alleviate the need for a py3 port of it (maybe).  do you know anything about that?
<barry> xnox: oh cool.  i had started to set up another ppa for this https://launchpad.net/~pythoneers/+archive/py33 but didn't get to populating it before i had to give my talk.  i think i'll just delete this ppa and start looking at the ftbfs in yours
<xnox> barry: ack. I think I did add you to mine. I created a new team, as i didn't know about ~pythoneers
<xnox> barry: me and doko have been crunching through them
<barry> xnox: we also have ~pythonistas but don't ask what the difference is :)
<barry> xnox: awesome!  what have you gotten to?  i can start working on others
<barry> xnox: and i should add you to pythoneers
<xnox> I am in progress on fixing: blender.
<barry> xnox: going alphabetically? :)
<xnox> barry: from here https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+packages if it's not build and has an X it needs looking into.
<barry> xnox: yep, that's the one i'm looking at too.  let's divide and conquer
<cjwatson> Laney: It's ended up in core, probably due to (build-)dependencies from other core packages.  The process for moving such things that are actually maintained by desktop folks to the desktop packageset is to mail me.
<cjwatson> pitti: No great rush, thanks.  I'd just like to have a clear idea by next week of what we're doing.
<xnox> barry: this one passes unit tests in 3.2, but not 3.3: https://launchpadlibrarian.net/120976604/buildlog_ubuntu-raring-i386.objgraph_1.7.1-1build1_FAILEDTOBUILD.txt.gz
<barry> xnox: probably the first thing to check is hash order dependencies
<xnox> barry: and shiboken is also a thing for you =)
<barry> xnox: yay!  my old friend shiboken (shibroken?) :)
<barry> xnox: i also want to look at passlib since i know that library a bit
<barry> xnox: so when you fix one are you uploading it to both raring and the ppa?
<xnox> all sounds good =)
<xnox> barry: for now yes. raring-proposed and the ppa.
<barry> xnox: yep.  cool.
<xnox> barry: ppa has 3.3 as default, while archive has 3.2 as default. Both have 3.2-3.3 as supported
<barry> xnox: perfect
<barry> xnox: i wish it was easy to copy packages from one ppa to another
<cjwatson> It is
<cjwatson> If you're finding it not so, I can help
<cjwatson> But there's clicky web UI for it and everything, as well as command-line tools
<xnox> barry: go to source ppa, and click "copy packages" on the package overview page =)
<xnox> barry: are you in ~ubuntu-rebuilds? I think I did add you...
<cjwatson> Indeed.  Or use copy-package from lp:ubuntu-archive-tools if you prefer the command line
<barry> xnox: i'm not, but ~ubuntu-core-dev is a pending member.  can you just add me explicitly?
<xnox> barry: welcome to the team =)
<barry> cjwatson: that's exactly what i was looking for: copy-package --ppa-name foo --to-ppa bar
<barry> cjwatson, xnox tho i don't think it's worth it in this case.  however, if for some reason we plan on keeping a py33-as-default ppa long term (and i hope we won't), we should move it to ~pythoneers
<xnox> barry: I think doko is eager to flip the switch. Not sure when, but the vibes I'm getting from him are before UDS.
<ogra_> vibes eh
<barry> xnox: i'm supportive of that.  gives us two days to whip that thing in shape :)
<xnox> ogra_: well... he is being conservative. if it was up to him it would be 3.3 default, drop 3.2, rebuild archive, done =)
<ogra_> heh, yeah, its a devel release after all :)
<mterry> barry, I somehow renamed the first column header in your python3 porting matrix to 'oauth' and can't fix it back
<mterry> barry, also, python3-oauthlib exists, and the python-oauth section should mention that
<barry> fixed
<xclaesse> Hello, any idea how I could work around this bug? https://bugs.launchpad.net/ubuntu/+bug/1071330
<barry> mterry: it does, but it's buried in a bunch of gobbledygook
<ubottu> Launchpad bug 1071330 in Ubuntu "bluetooth keyboard always reset to qwerty instead of azerty" [Undecided,New]
<barry> mterry: i suppose we should officially endorse oauthlib as the way forward
<mterry> barry, it mentions that a python3 port exists on the web somewhere, but not that it was in quantal
<mterry> barry, yeah probably
<mterry> it's in main and all that jazz
<barry> mterry: i know you submitted patches upstream.  have they been accepted yet? (i suppose i could try to dig out the link to that)
<mterry> barry, yes
<mterry> barry, let me find link
<mterry> barry, https://github.com/idan/oauthlib/pull/56
<mterry> barry, https://github.com/idan/oauthlib/issues/62 has a report about issues with 3.3 though
<mterry> My patch was only for 3.2
<barry> mterry: thanks.  dict ordering.  i'll take a look at that
<Laney> pitti: rejecting glib and pcre3 so that I can sync them into -proposed, per the new world order
<pitti> Laney: ack; I thought that would be redirected automatically soon
<Laney> not for copies
<cjwatson> Redirecting copies ended up being too complex an API that would be very hard to fix any more later
<cjwatson> Since the copy API is very explicit about what pocket it's going into
<pitti> ah, ok
<cjwatson> For now, use syncpackage -r raring-proposed; I've changed the default in bzr
<pitti> cjwatson: I guess we'd build that redirection into syncpackage then, i. e. rewriting the destination on the fly
<pitti> or that, thanks!
<cjwatson> Yeah, no point rewriting really since I expect -r is rather rarely used
<barry> xnox: i think it's best to build in the ppa, and only after it passes there, upload to r-p.  the reason is that some of the packages in the ppa have version numbers ahead of the archive, so it requires additional bumps to build in the ppa.  but those intermediate (ppa-only) versions can be thrown out when uploading to r-p.  passlib is an example of that.
<pitti> good night everyone
<cjwatson> And I'm happier changing defaults than adding magic
<xnox> barry: well I test build locally in sbuild, which has that ppa added. So i know it passes when I upload fixes to both =)
<mitya57> hey barry (finally you are here at the same time as I am!)
<mitya57> can you ask birkenfeld about one thing?
<barry> mitya57: sure
<mitya57> barry: I wonder whether he is going to fix https://bitbucket.org/birkenfeld/sphinx/issue/1008/test-failures-with-python-33
<mitya57> it's causing ftbfs in raring and I don't have enough sphinx experience to fix that myself.
<xnox> doko: I have a fix for blender, but I think I may have done a mistake in my python3-defaults, because I got a stray/unneeded python3.2 dependency via ${python3:Depends}
<barry> xnox: not quite though.  passlib is ftbfs in the ppa, but is a version ahead of raring afaict.  so i have to bump the version *again* for the ppa, but when i upload to raring, i won't need to skip that version number.  unless it has your ppa version# in r-p, but tools like rmadison and bzr branch ubuntu:passlib haven't caught up with that yet.
<barry> mitya57: let me check with him over in #python-dev
<mitya57> barry: whois says he is only at #pocoo and is offline there
<xnox> barry: yes, ppa has funny version numbers for some packages. I bumped all version numbers when doing rebuild. For most it's builX which doesn't matter, but for those that had ubuntuX it became ubuntuX+1 ahead of the archive.
<barry> mitya57: seems to be online on #python-dev, tho away
<barry> xnox: right.  that's really all i was saying :)
<xnox> barry: I see =) just keeping you on your toes. I guess I should have used copy-package to rebuild from the archive -> ppa. But oh well.
<mitya57> barry: oops, so my /whois lies :)
<barry> mitya57: i guess so :)
<barry> xnox: yeah, no worries.  just something to be aware of.
<xnox> barry: I was hoping to copy src from the ppa back to the archive, but that won't be happing now due to slightly wrong changelog entries in most of them (stray multimaintainer lines)
<mitya57> barry: thanks!
<barry> mitya57: i'm watching the issue now too.  i pinged birkenfeld over in #python-dev, but maybe he really is away :)
<mitya57> let's hope he reads his scrollback :)
<barry> xnox: /me -> lunch but i guess i'll set up my local sbuild to add the ppa so i don't have to wait 3 hours for stuff like this: https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+build/3929285 :)
<xnox> barry: yeah doko has rescoring them for me such that most of them were building instantly
<barry> ah.  say doko, can you rescore ^^ ? :)
<stgraber> barry: done
<barry> stgraber: thanks!
<seb128> bjaanes, the reason seems to be "there is no amazon in Norway"
<barry> xnox: did you add-apt-repository in your source:raring-arch schroot, or do you use sbuild --setup-hook, twiddle the config file, or something else?
<xnox> barry: install software-sources-common, add-apt-repository, then purge software-sources-common
<xnox> =)))
<barry> ok :)
<mitya57> s/sources/properties/ ?
<xnox> mitya57: barry: yeah something like that. Long winded and descriptive =)
<barry> xnox: something tells me this is going to be a meme: http://paste.ubuntu.com/1305272/
<bdmurray> mvo: could you a look at bug 1070035?
<ubottu> Launchpad bug 1070035 in ubuntu-release-upgrader (Ubuntu) "Can't install 'kubuntu-netbook'" [Undecided,Incomplete] https://launchpad.net/bugs/1070035
<xnox> barry: I think it dates back to an older meme, where packages worked with 3.2 only, which 3.1 was default and 3.2 supported, or something like that =)))))
<xnox> barry: it's certainly one of the common cases.
<mitya57> barry: is module.__loader__ gone in python3.3?
<mitya57> ah, it's new, the contrary :)
<mitya57> barry: what can this check mean: https://bitbucket.org/birkenfeld/sphinx/src/d7ac5e46307d/sphinx/util/__init__.py?at=default#cl-200
<mitya57> and what's its equivalent in python3.3 (if you know)?
<mvo> bdmurray: certainly
<mvo> bdmurray: I followed up in the bug, the root is that universe is not enabled, but I am a bit in the dark what the best fix is
<mvo> bdmurray: i.e. the user has only main enabled so he/she will not want universe packages but kubuntu-netbook is now universe, so its a bit tricky to decide whats the right course of action (enable universe automatically, fail with a better error message)
<bjaanes> seb128, That is true i suppose, but there is no problem buying from Amazon in Norway. I do it all the time. Its very popular over here.
<bjaanes> amazon.com works perfectly and ships to norway with most of their stuff
<seb128> bjaanes, well, I asked the U1 guys, that's the reason it doesn't work, there is no amazon.no
<seb128> bjaanes, right, that's a known "would be nice if that worked"
<bjaanes> seb128, okey - but is there any workaround?
<seb128> bjaanes, you should ask to Chipaca on #ubuntu-desktop
<bjaanes> seb128, Shall do, thank you for your help!
<seb128> bjaanes, yw!
<ceolin> hey folks, about the appmenu, is it requires patched version of gtk and qt to works ?
<doko> xnox, barry: rescored
<xnox> doko: \0/
<bdmurray> mvo: ah, thanks for looking
<Riddell> mvo: fail with a better error seems the most sensible, otherwise it's a security issue
<mvo> Riddell: thanks, yeah, a string change :/ I wonder if we can release note it at least
<mvo> so that everyone knows
<doko> xnox, barry do you have a list, who addresses which ftbfs? or who's working on what?
<xnox> doko: just finished/uploaded blender and morse-simulator (they were hard-coded to 3.2 so not an easy spot)
<xnox> doko: I'd like to look at boost.
<doko> xnox, sure, if you want to =) see my comment in the bug report what I figured out
<xnox> doko: looks like there is multiarch.jam in the wild http://code.ohloh.net/file?fid=6JCqBzlemTFqf5oPg9xW4FA-3BQ&cid=WGhTHTVrHL8&s=&browser=Default#L0
<alexbligh> what is approved Ubuntu way of resizing the console post boot? resizecons & SVGATextMode do not appear to exist.
<alexbligh> hmm, that's on Lucid. Allegedly resizecons is in precise
<alexbligh> packages.ubuntu.com has resizecons in package kbd: http://packages.ubuntu.com/search?searchon=contents&keywords=resizecons&mode=exactfilename&suite=lucid&arch=any - however installing it and dpkg -L on the package gives the manpage but not the binary. Any ideas?
<xnox> alexbligh: support is at #ubuntu or http://askubuntu.com
<xnox> doko: for boost, is doing dpkg-architecture -qDEB_HOST_MULTIARCH called cheating? =)
<doko> xnox, no, why?
<xnox> doko: I may have a patch then ;-)
<doko> nice
<xnox> doko: need to test it with both boost sources and both boost versions (4 source packages) =))) will take a while.
<doko> xnox: use osageorange for one build
<fabbione> doko: hey
<fabbione> doko: do you still maintain gcc/toolchain ?
<xnox> doko: ?????
<fabbione> doko: i think i found an alignment bug on amd64 but i need an expert to look at it
<doko> fabbione, heya, will you be at uds?
<barry> doko: i don't think we have a list.  i was just going to pick them off and mention it here so i don't duplicate work you or xnox is doing
<doko> if you're still in Denmark
<fabbione> doko: yes, it's behind the corner ;)
<fabbione> doko: yeps
<fabbione> i am still here
<doko> cool
<fabbione> doko: that means you will have to see my ugly face again :P
<fabbione> s/:P//
<doko> heh
<fabbione> seriously tho.. do you still maintain gcc?
<doko> yep
<fabbione> ok
<fabbione> doko@u.c ?
<doko> yes
<fabbione> ok.. sending
<barry> xnox, doko: either of you looking at dirspec?
<xnox> nope
<doko> barry, already fixed
<doko> as nose
<xnox> barry: too easy =)
<doko> now looking at lxc
<barry> doko, xnox: ah, okay.  i guess the ppa is just behind the times
<doko> barry, subscribe to raring-changes, and look what got uploaded
<barry> doko: i'm subscribed, but behind on those emails
<fabbione> doko: sent.. i tested different gcc in ubuntu and debian and fedora. same issue
 * barry catches up
<fabbione> doko: if it's a bug it's very old
<fabbione> doko: i just can't wrap my head around it... it doesn't make any sense
<cjwatson> that sounds like it ought to get a reduced test case and go upstream ...
<fabbione> cjwatson: i already have a reduced test case to the bare minimum
<fabbione> cjwatson: but there is no guarantee it's a bug. it might be my code
<doko> xnox, barry: lcx fixed, now looking at libguestfs
<barry> doko, xnox cool.  i'll do shiboken i guess
<xnox> barry: yeah it even fails to build in quantal.
<fabbione> doko: thanks tho! have a nice evening and see you soon (let me know if you need more info)
<addiks> hi, i have recently upgraded to 12.10 and noticed that unity now uses nux instead of geis for multitouch. In 12.04 i have patched unity to disable geis to be able to use ginn with my own gestures, but i dont know how to do that with nux. Anyone got a clue?
<doko> what am I doing wrong? http://paste.ubuntu.com/1305518/
<xnox> doko: make ate the first set of quotes?
<xnox> doko: passing -O2 directly to configure.
<xnox> doko: that's why I don't like inlining shell in makefiles, and instead prefer $(for ) make function loops, not shell loops.
<doko> xnox, no $ is evaluated by the shell, make doesn't see any quotes. thing is that at this point of expansion, it's too late
<xnox> doko: include /usr/share/dpkg/buildflags.mk
<xnox> is all you need?
<xnox> doko: yeah, you are right.
<micahg> doko: CXXFLAGS isn't being properly quoted
 * xnox off for a little while.
<micahg> doko: nevermind
<ScottK> If you're switching from a directory to a symlink in a package, it's my understanding that dpkg won't do that change for you.  What's the right way to handle that?  Remove the directory in the preinst?
<xnox> ScottK: spended of patches / uploads in debian recently. yes preinst snippets.
<xnox> ScottK: see debian-devel or recentish RC bug fixes...
<ScottK> xnox: Right.  The reason I ask is I just got one of those bugs filed on a package of mine and so I'd like to fix it.
<ScottK> Do you have a patch/snippet example you could point me at?
<xnox> ScottK: https://launchpadlibrarian.net/117993446/bitlbee_3.0.5-1.1_3.0.5-1.2.diff.gz
<ScottK> xnox: Thanks.
<doko> ScottK, uploaded a fixed qscintilla2
<barry> doko, xnox, ScottK shiboken is annoying.  one of the tests is segfaulting, and it seems consistent in ubuntu and debian chroots.  nothing upstream that i can tell :/  anyway, still investigating
<slangasek> jbicha: bug #1071008 sounds like it might be a gnome-remix package selection issue?
<ubottu> Launchpad bug 1071008 in update-notifier (Ubuntu) "Update Integration" [Undecided,New] https://launchpad.net/bugs/1071008
<jbicha> slangasek: yes, thank you
<slangasek> jbicha: ok - guess you'll reassign to an appropriate place then :)
<ScottK> doko: Thanks (re qscintilla2)
<doko> ScottK, won't file a Debian report
<ScottK> I'll take care of it.
<ScottK> python3-dbus.mainloop.qt is now an empty package.  Fixing that up.
<slangasek> infinite loop in under 3 seconds
<ScottK> It's not important until we care if the installer works.
<barry> xnox: still around by any chance?
<xnox> barry: just for you =)
<xnox> barry: i didn't manage to reproduce shiboken in debian chroot.
<xnox> barry: if it is, file a bug there as well.
<barry> xnox: otp w/slangasek, but how did you get the output in bug 1070772?  i get different failures
<ubottu> Launchpad bug 1070772 in shiboken (Ubuntu) "modelview_test.py segfaults python" [High,Confirmed] https://launchpad.net/bugs/1070772
<xnox> barry: right, so I peaked at the full environment variables of how the test is executed. I did the build and run it with exact same parameters but added -vv to python.
<xnox> barry: nothing fancy
<barry> xnox: ah.  so i'm inclined to punt on this bug, after reporting it upstream.  i'm going to leave the package ftbfs so it's more obvious if someone wants to fix it.  it's clearly unrelated to python3.x since it ftbfs in quantal, and crashes w/2.7
<xnox> barry: ack. I think it's fine it's not blocking.
#ubuntu-devel 2012-10-26
<xnox> barry: actual dictionary hash ordering build-failure: https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+build/3929037
<pitti> Good morning
<pitti> cjwatson: congratulations and thanks for setting up the -proposed stuff! it's great to see this in action at last
<pitti> apw: I subscribed you to bug 1070427, I asked a question about the kernel header provides/depends; that seems to break some cases ATM
<ubottu> Launchpad bug 1070427 in nvidia-graphics-drivers (Ubuntu) "fails to build due to missing kernel headers" [Undecided,New] https://launchpad.net/bugs/1070427
<ScottK> xnox: Is your python3 transition tracker updating?  I see uploads from yesterday that aren't reflected.
<ScottK> xnox: How goes cmake?  pykde4 is now waiting on it.
<dholbach> good morning
<fishor> hallo devs, i'm porting gnome-sound-recorder to gstreamer-1.0 and gtk3. My repository based on gnome-media with removed all deprecated parts. you can find it here https://gitorious.org/gsr/gnome-recorder/commits/master
<fishor> my question, do it make sense to target it for 13.04?
<mvo> barry: I took the liberty to upload the fix for #846044 now that its part of the upstream git, just fyi
<dagoaty> I am trying to write a preinst script for a package that supports the 'backup' functionality. I think I have this working but as far as I can tell only the installer supports the backup feature. Is there any commandline mode for dpkg which I can use to test my script behaves correctly?
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity, apw
 * dholbach hugs infinity
<doko> Sweetshark, when do you plan the first libreoffice upload?
<Pjotr> Hello, I have a question about ufw.
<Pjotr> Where can I find the default rules profile of ufw?
<Pjotr> mdeslaur: can you maybe tell me, which default rules profile ufw uses?
<mdeslaur> Pjotr: jdstrand ^
<jdstrand> Pjotr: look in /etc/ufw/*rules. you can also do 'sudo ufw show raw'
<jdstrand> (if it is enabled)
<Pjotr> jdstrand: that doesn't show a lot of rules... Is the default profile secure enough for the average home user, or do you advise adding extra rules?
<jdstrand> Pjotr: it is default deny. It is recommended for a home user, yes
<Pjotr> jdstrand: would ufw with the default profile negatively affect samba or torrents?
<jdstrand> Pjotr: the basic idea is that it is default deny for incoming. default allow with connection tracking for outgoing. it allows for things like dhcp and ping. it is a reasonable default but can be adjusted for your requirements
<jdstrand> Pjotr: as a samba client, it shouldn't in recent releases. you would be able to fetch torrents, you'd have to open up a port to serve torrents
<jdstrand> (you'd also have to open a port to serve clients)
<Pjotr> jdstrand: thanks for the information.... :-)  For now, this answers my questions about ufw.
<jdstrand> np
<ttx> jml: been trying undistract-me, installed from PPA... but it does not seem to trigger. Only works once I do . /usr/share/undistract-me/long-running.bash && notify_when_long_running_commands_finish_install
<jml> ttx: yeah. I've noticed that recently too
<jml> ttx: I could swear it worked befoe
<ttx> jml: I believe you ;)
<ttx> only half as fun if it doesn't work though :P
<jml> ttx: manually running '. /etc/profile.d/undistract-me.sh' works for me also
<jml> ttx: I suspect it's due to some weird login shell interaction
<ttx> jml: probably in the [ -z "$BASH_VERSION" -o -z "$PS1" -o -n "$last_command_started_cache" ] test
<jml> perhaps
<ttx> dmesg
<ttx> oops
<doko> jamespage, ping
<jamespage> doko, pong
<ttx> jml: can't see anything obvious, let me know if you find the solution :)
<jml> ttx: will do.
<doko> barry, xnox: in the py3.3 test rebuild are about ~200 packages, slangasek identified ~500 which might be affected. there's a small difference
<xnox> doko: 500 _binary_ packages that slangasek identified.
<doko> ok, so once boost is fixed, we should be ready to change the default?
<xnox> doko: more or less. (boost and it's python3-like rdeps)
<barry> python-oauthlib is pretty important, but i'll look at that (unless a fix is already uploaded but not in the ppa yet)
<barry> it needn't block the change though
<xnox> barry: testsuite failures for pure-python modules do not block us to switch default.
<xnox> barry: as e.g. python-oauthlib is installable with python3.3 as default.
<barry> has anyone looked at ubiquity?
<xnox> doko: do you have python3-defaults arch:all -> arch:any done?
<xnox> barry: local build is fine.
<barry> it only fails on amd64
<xnox> barry: ppa build "got killed" in the logs
<barry> hung for 150m apparently
<barry> in any case, doko i think we should do it
<doko> xnox, yes, will remove the header symlink again
<xnox> doko: ack.
<doko> barry, xnox: ok, then I'll wait for the boost builds to succeed, and the make 3.3 the default (which might be tomorrow)
<tsdgeos> is the "raring" part of the archive private on purpose?
<micahg> tsdgeos: what do you mean?
<tsdgeos> micahg: http://archive.ubuntu.com/ubuntu/dists/raring exists but gives 403
<tsdgeos> that's what i mean
<micahg> wfm
<tsdgeos> does it?
<micahg> yep
<yofel> wfm too
<tsdgeos> you guys in copenhagen?
<micahg> not yet
<tsdgeos> well, i'm blaming the network somehow
<tsdgeos> does not work from here, but works in a server i have somehere else
 * yofel isn't going
<tsdgeos> and it works for you
<tsdgeos> so obviously not a problem in the server
<develop7> Hello all. Is there any way to figure out which process handles particular keyboard shortcut?
<develop7> I'm going to fix https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1064345 myself, but have virtually no clue where to start from.
<ubottu> Launchpad bug 1064345 in gnome-settings-daemon (Ubuntu) "Inconsistent behavior for some keyboard shortcuts: user is able to bind them, but pressing them does nothing" [Undecided,New]
<Sweetshark> doko: ASAP, which means once I get all 3.7 deps in place.
<dagoaty> Is there any frontend to debconf I can use to test the 'backup' feature? I've only seen this working in the installer.
<rbasak> pitti: is there an easy way to test an apport hook? It refuses to even --save against my test package because it is "not an official Ubuntu package"
<rbasak> I haven't managed to find an option to do this anywhere, and there isn't any discussion of hook testing in https://wiki.ubuntu.com/Apport/DeveloperHowTo :-(
<barry> xnox: i think it's still worth having a discussion on 3.3/3.4.  the actual decision will probably be a rubberstamp, but in the past such sessions have been very good at bringing up collateral issues to think about
<xnox> barry: well currently it's scheduled in a strange place: clashes with building arm images, rapid archive bringup and a few other cool sessions for me =)
<barry> xnox: complain to your track chair :)
<barry> xnox: or make your participation essential and let the scheduler sort it out
 * barry now goes to check his own schedule
<xnox> barry: actually that does nothing. you need to as track chair to special mark somebody "essential" in the summit.
<Laney> I don't know that it does absolutely nothing
<Laney> but it's not a hard requirement like it appears
<slangasek> xnox: right, are you sure it has *no* effect?
<slangasek> all I know for sure is that there's an additional knob now
<xnox> slangasek: can you please accept this one for uds-r sprint https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upload-intermediary
<xnox> slangasek: there is a session, but summit doesn't "know" the blueprint link.
<xnox> although it's kind of done ?!
<slangasek> xnox: "accept" it?  That blueprint isn't marked as proposed for uds-r
<slangasek> probably because cjwatson doesn't think we need to discuss it? :)
<xnox> slangasek: I guess I got confused why it's linked from
<xnox> http://summit.ubuntu.com/uds-r/meeting/21333/archive-maintenance-software-hacking/
<slangasek> ahh, the url is there just as a reference
<xnox> slangasek: this blueprint is still on the schedule http://summit.ubuntu.com/uds-r/meeting/21074/foundations-r-landscape-fde/
<xnox> slangasek: but it was rejected from uds-r
 * xnox twiddled the "subscriber vs essential" and I'll look how that will affect the scheduler next time it reruns ;-)
<Laney> hmm, yeah, quite a number of conflicts
<rbasak> pitti: I found my answer by digging in the code. I can set APPORT_DISABLE_DISTRO_CHECK in the environment
<rbasak> SpamapS, jamespage, adam_g: FYI ^^
<jamespage> rbasak, nice
<cjwatson> dagoaty: pretty much any old debconf frontend, including the default of "dialog", supports backup if your script says "db_capb backup".  It is not at all installer-specific.
<dagoaty> cjwatson: Odd, I only seem to get an OK prompt with dialog.
<dagoaty> cjwatson: I even tried the example code at http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN217 with no success
<Snow-Man> what's w/ using sftp to upload to a ppa..?  docs indicate using: incoming = ~sfrost/<ppa-name>/ubuntu, but I'm getting an error that launchpad couldn't find a PPA named 'postgis' (even tho I see it on the website..)
<rbasak> Snow-Man: is that an email error? There's a known bug that the email error reports for upload failures name a random PPA that isn't yours
<rbasak> Snow-Man: (but in that case the error might still be valid - it happens to me if I use the wrong path)
<Snow-Man> rbasak: well, yes, I see the random PPA name, but in the body of the email it's saying "Could not find a PPA named 'postgis' for 'sfrost'.", even though when I go to: https://launchpad.net/~sfrost/+archive/ppa it says "postgis" at the top
 * Snow-Man randomly tries stuff
<Snow-Man> well, that's cute
<Snow-Man> Source/binary (i.e. mixed) uploads are not allowed.
<Necrosporus> Why there is no GUI option to disable advertising banner in software center?
<Snow-Man> missed *that* in the docs..
<ppetraki> I've got an upstart task that simply won't start. http://pastebin.ubuntu.com/1307508/
<ppetraki> all the parts of the script run fine, put it in a task, fails
<slangasek> ppetraki: do you have a /var/log/upstart/opengrok-index.log?
<ppetraki> slangasek, http://pastebin.ubuntu.com/1307525/
<ppetraki> slangasek, but it all runs fine from the shell
<slangasek> ppetraki: chances are there's something different in the upstart environment (which is mostly a blank slate) vs. the shell environment that makes the difference
<ppetraki> slangasek, so im sourcing a bash script, and then calling the funcs, is that supported?
<slangasek> ppetraki: oh, for one thing when you're sourcing that script at the commandline it's sourced by bash, and when you're running an upstart job the shell is /bin/sh == ash
<ppetraki> that's got to be it
<ppetraki> slangasek, http://pastebin.ubuntu.com/1307536/ confirmed
<slangasek> ppetraki: yeah, so I think you want to put your script into a separate file with an explicit #!/bin/bash, and then put 'exec myscript' in the upstart job
<ppetraki> slangasek, got it, thanks
<slangasek> Laney: you say you were seeing conflicts for sessions you were marked as 'participation essential' on?  Can you give me an example?
<slangasek> Laney: the scheduler seems to be doing an adequate job of warning me if p.e. subscribers have conflicts
<Laney> slangasek: I don't think I have conflicts like that, just ones where I subscribed non-essential
<Laney> should I expect doing that to influence the scheduler at all?
<slangasek> Laney: ok - expected behavior :)
<Laney> perhaps I'll have to upgrade some then
<slangasek> yes, that's what the flag is there for! :-)
<Laney> slangasek: also, how come https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-future-release-brainstorming got changed to declined?
<slangasek> Laney: we believe it's covered by the combination of the release-schedule session and the quantal-feedback session
<slangasek> http://summit.ubuntu.com/uds-r/meeting/21405/foundations-r-schedule/ + http://summit.ubuntu.com/uds-r/meeting/21047/foundations-r-prior-release-feedback/
<Laney> well, not if the latter is entirely backwards looking
<slangasek> Laney: having an entirely backwards-looking session that doesn't result in actions for the future would not be a productive use of time :)
<slangasek> are there specific things you think are not covered in the other two sessions, that would warrant a third?
<Laney> I'll just distribute the topics from the whiteboard
<Snow-Man>  c
<Snow-Man> erp
<jelmer>  /query barry
<jelmer> whoops
<jelmer> hi barry :)
<xnox> fgrep changed?! http://paste.ubuntu.com/1308437/
#ubuntu-devel 2012-10-27
<apw> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 (Quantal Quetzal) released!  | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<xnox> barry: what is the "right" solution when unit-tests rely on dict ordering?
<xnox> barry: use ordereddict in the unit-test or make the code use ordereddicts? or compare taking into account that it could be slightly "random"
<xnox> ?
<jtaylor> sort the result what is expected to be non-random?
<barry> xnox: sort
<xnox> barry: hmm... well looking into subunit build-failure it compares the final output which embeds pieces of random string. I'd rather not mangle that output but make subunit return sorted output in that field.
<xnox> otherwise the tests that use subunit will have to change depending if it's 3.2 or 3.3
<xnox> barry: also strangely we see hash ordering on 32 bit platforms, but not 64 bit...
<xnox> barry: jtaylor: please review for sanity https://code.launchpad.net/~xnox/subunit/hash-ordering/+merge/131732
<stedi> Hi, I need to "serialize" package versions version and revision parts (epoch is easy enough) so I can pick latest among several candidates using ordinary sort functionality (in databases). I have looked at verrevcmp function but am hesitant about just appending several order() results into a string of unsigned shorts. Or would this work?
<alexbligh1> I have an apache module packaged for debian. It has a conf file /etc/apache2/mods-available/mymodule.load. When I remove it (but not purge it), it leaves the conffile there, which is as expected I guess. However, this variously breaks apache. How do I ensure it is removed on a package remove? I guess I'm asking for it either to be treated not as a conf file, or removed if it is unchanged. This is for Lucid.
<alexbligh1> (if I rm it from my prerm script, it thinks the user has changed it, which in turn means reinstalling it won't reinstall the conf file)
<jelmer> alexbligh1: it shouldn't be an issue if the file is just in /etc/apache2/mods-available if the module is not installed
<jelmer> alexbligh1: only if the file is actually in /etc/apache2/mods-enabled (or symlinked there)
<alexbligh1> jelmer, hmm, that makes sense. I wonder why it is causing issues.
<jelmer> alexbligh1: the apache log should be of help - a directive in that file isn't understood by apache?
<alexbligh1> jelmer, I think the problem was that it wasn't doing the a2dismod, but removing the .so, and I got confused by the .load being there.
<alexbligh1> thanks for your help
<alexbligh1> ... though I'm sort of intrigued why they are conffiles anyway. Are they intended to be user editable?
<xnox> alexbligh1: hmm... well mods-enabled has symlinks to conffiles in mods-available. And apache reads conffiles to get the names & system settings for a particular loadable .so. Apache doesn't know where to find them and which onces to load and which onces not to load =)
<alexbligh1> xnox, no I meant why is the .load file a conffile (or, if you prefer why is mods-available in /etc/ not a symlink to elsewhere, or the files copied in on postinst and removed in prerm), given they are not user editable as far as I can tell, unlike (e.g.) sites-avaialble.
<alexbligh1> as the .load file hanging around makes no sense if the .so has gone.
<xnox> alexbligh1: I don't see a reason to ever modify them, but maybe I am not advanced user.
<xnox> no idea about handling.
<alexbligh1> aaaah, for what it's worth the bug is that if you remove, but not purge, an apache module, then someone a2enmods it, then it successfully creates the link and a2enmod does not error, but reloading apache fails even if the module is not used :-/
#ubuntu-devel 2012-10-28
<Ronnie2> Im trying to write my first lines of c code to add an indicator item to the messaging menu. Which -dev packages do i need to install. I got the following error: fatal error: messaging-menu.h: No such file or directory
<trism> Ronnie2: libmessaging-menu-dev
<Ronnie2> trism: E: Unable to locate package libmessaging-menu-dev (im on 12.04)
<trism> Ronnie2: that API was added in 12.10
<Ronnie2> oh, isn't it possible to write messaging items in 12.04?
<trism> Ronnie2: libindicate-dev
<infinity> It is, with a different API.
 * infinity assumes libindicator-messages-status-provider-dev relates too, but isn't positive.
<Ronnie2> trism: i still got the same error. Do i need to add some compiling flags and libs?
<infinity> Ronnie2: You'll always get that error on 12.04, the API you're writing to was new in 12.10.
<infinity> Ronnie2: You'd need to write to a different API (and include different headers) to do what you want on 12.04
<Ronnie2> infinity: is there some documentation on the API for 12.04?
<Ronnie2> is it this one: http://developer.ubuntu.com/api/ubuntu-12.04/c/AppIndicator3-0.1.html
<infinity> Ronnie2: Not sure, but the indicator-messages source package may be helpfully self-documenting.
<infinity> Ronnie2: That looks, at first glance, more like a reference for writing new indicators (rather that writing to the messaging indicator).
<infinity> Ronnie2: But I'm the wrong person to ask about all this.  If I knew how it all worked, I'd go fix all the stuff that broke in 12.10. :P
<nikolam> hi, anyone have an fresh info about integrating BTRFS (and root ZFS) snapshots in upgrade process, so One automatically have older version of the system to boot to, after upgrade?
* infinity changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2013-10-21
<pitti> Good morning
<ion> that
<dholbach> good morning
<pitti> cjwatson: I uploaded cdbs merge; do you want to merge debhelper yourself? (you're currently TIL)
<Noskcaj10> When will everything be ready for the archive to re-open?
<Noskcaj10> Or to upgrade to trusty
<pitti> Noskcaj10: you can already upgrade to trusty :) (I did already) but of course it's just like saucy at this point
<pitti> Noskcaj10: I take it will still be a few days until the toolchain is in place
<pitti> Noskcaj10: but you can already do uploads, syncs, etc.
<Noskcaj10> pitti, ok, thanks for the info. I'm upgrading now
<geser> is using "devel" or "trusty" (and update it for t+1) the preferred way to stay on the devel release?
<wgrant> apt doesn't actually like devel atm.
<wgrant> So you have to use trusty explicitly.
<wgrant> But once the implementation is complete you'll be able to just use devel
<Noskcaj10> Are we still trying to get python3 only for 14.04?
<Noskcaj10> pitti, do-release-upgrade and update-manager can't find trusty. How did you upgrade?
<pitti> Noskcaj10: edit /etc/apt/sources.list and s/saucy/trusty/ :)
<Noskcaj10> ok, i was hoping there was an "easy" way, i'll do that now
<mlankhorst> can someone accept all the xorg and mesa binaries in NEW for https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<Matt_91> hi everyone, maybe there is an error in resolvconf. it not include the file /etc/resolvconf/resolv.conf.d/base
<Noskcaj10> How do i sync from deb-multimedia?
<mlankhorst> stgraber: can I get a MRE for libdrm backport from saucy to raring/quantal/precise again?
<Noskcaj10> because a heap of the packages on http://qa.ubuntuwire.com/neglected/ need syncing from deb-multimedia
<Noskcaj10> TheMuso`, Do you have any plan to keep maintaining avidemux since you are the most recent uploader?
<cjwatson> pitti: oh, yeah, I'll do debhelper, thanks
<cjwatson> Noskcaj: deb-multimedia> most of those should probably be removed, but if you need a sync you'll have to do it manually (i.e. download / re-upload)
<Noskcaj> cjwatson, ok. Shall i start working on a list of stuff we take from deb-multimedia?
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<cjwatson> Noskcaj: If you like.  It was fairly misguided that we synced all that stuff in in the first place, IMO, but try to assess how useful/used they are
<Noskcaj> ok
<Noskcaj> Everything has a relatively high popcon, so i'll see what ones  are worth syncing tomorrow
<Noskcaj> cjwatson, Mind if i merge rfkill?
<pitti> wow, haven't looked at neglected for a while
<pitti> edgy-wallpapers | 0.9-0ubuntu2 | saucy/universe | source, all
<pitti> yay
<Laney> ooh
<wgrant> We pushed most of the deb-multimedia stuff out years ago, I thought.
<Laney> ubuntu-wallpapers only has >= karmic
<wgrant> But I guess there are bits left.
<Noskcaj> wgrant, libfame and ripmake are the main ones left
<cjwatson> Noskcaj: What's the rush?  In general all my merges are ones I intend to at least look at in the next week or so; I don't need help right now
<Noskcaj> ok, i'm just picking random packages on the merges page. I've not got much to do
<cjwatson> Noskcaj: If you feel the desperate urge to take merges, at least start with inactive developers
<Noskcaj> ok
<Noskcaj> i just remembered i have one or two merges of my own. What'd the process for merging from unstable if it's a non-ubuntu arch FTBFS?
<Noskcaj> *what's
<dholbach> can somebody remove my tornadio2 sync from the trusty new queue? I missed a message on the original bug report, sorry about that.
<dholbach> pitti, ^ maybe?
<cjwatson> dholbach: rejected
<dholbach> thanks a lot cjwatson
<mlankhorst> is there still a tb? it only shows mark shuttleworth as member
<pitti> mlankhorst: yes, everyone else timed out
<pitti> I mailed/pinged sabdfl about it several times
<mlankhorst> ok so if I want to get a mre for libdrm, pixman, and some x11 libs should I ask him? :P
<Saviq> lool, ping
<pitti> mlankhorst: best to mail the list as usual, we are still serving on an acting basis :)
<mlankhorst> oke
<cjwatson> dholbach: I've seen a few syncs from you landing in NEW - you know it's unnecessary to request those manually since they'll be done in bulk once auto-sync starts, right?
<cjwatson> (except in a few special cases which don't apply here)
<dholbach> cjwatson, I mainly synced them because they were in the sponsoring queue and I wanted to have something to report back... I guess it's causing additional work? in which case, I'd stop doing that
<cjwatson> dholbach: A bit - it requires manually accepting, whereas auto-syncs will sail through
 * dholbach nods
<dholbach> ok, understood
<cjwatson> It's not *wrong*, but it's a waste of the sponsored person's time requesting them, so they should probably be advised to do something more useful :)
<dholbach> they were filed before saucy release
<cjwatson> Yeah, although at a point when we were never going to accept new packages
<dholbach> yeah
<cjwatson> Anyway, not the end of the world, just in case you didn't know, since auto-sync of new packages is a fairly new thing (about 1.5 years)
<dholbach> yeah, I've heard of it - I think among the exceptions were blacklisted packages and packages from contrib and non-free, right?
<cjwatson> Blacklisted yes, packages from contrib and non-free no
<cjwatson> They're still auto-synced
<cjwatson> The main other exception is packages that used to be in Ubuntu and have been removed
<dholbach> all right, thanks
<mlankhorst> cjwatson: if I upload a package to -proposed, and that package only exists in -updates, it goes through NEW. Can this be fixed?
<cjwatson> mlankhorst: it's a known bug but is fairly hard
<mlankhorst> hm :(
<cjwatson> mlankhorst: the ancestry calculations are rather complex and implemented too many times
<cjwatson> mlankhorst: I'd like to fix it but I can't do it on the spur of the moment for you based on an IRC prod
<mlankhorst> ok
<cjwatson> It'd go through UNAPPROVED anyway, so it mostly only affects binary NEW
<mlankhorst> well no it ends up in NEW iirc
<cjwatson> mlankhorst: Yes, I know.  I mean that even if we fixed that it would still end up in UNAPPROVED.
<cjwatson> Which is manual review either way.
<cjwatson> And binary NEW is easy; so this isn't very high priority.
<mlankhorst> yeah but that does depend on someone accepting the binary new's manually, that part seems to be hard. I've been considering becoming an archive admin for that reason, to take some load off others. :s
<cjwatson> mlankhorst: Uh, that part is easy, might just need a prod
<cjwatson> It's not much load
<cjwatson> The number of binary NEWs due to this bug ever probably consume less effort than fixing the bug :)
<mlankhorst> perhaps but repeated prodding doesn't seem to help :P
<cjwatson> I don't remember seeing any prods from you about binary NEW.  Which packages?
<cjwatson> (And in which series?)
<mlankhorst> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<mlankhorst> all binaries in there
<cjwatson> mlankhorst: done
<mlankhorst> thanks :)
<cjwatson> mlankhorst: Oh, only three days old, so people will have been dead from release or preoccupied with opening trusty, pick one
<mlankhorst> well dno, I'm busy preparing lts-s backports :)
<mlankhorst> only needs a few sru's this time
<mlankhorst> 6 or so
<steveire> Any idea what the chances are of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708744 ever being solved? I'm wondering if I should build a workaround for it into CMake
<ubottu> Debian bug 708744 in clang "Debian patch uses wrong triple for arch-includes" [Normal,Open]
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<steveire> Riddell: apachelogger: Any idea ? ^
<apachelogger> doko_: ^ if you could have a look
<doko_> apachelogger, then make clang -target work ...
<apachelogger> steveire: ^
<steveire> doko_: ?
<doko_> $ clang -v -target arm-linux-gnueabihf --sysroot /home/stephen/rpi/rasp-pi -c main.c
<doko_> ignoring nonexistent directory "/home/stephen/rpi/rasp-pi/usr/include/x86_64-linux-gnu"
<doko_> doesn't seem to be a version out of the archive
<dholbach> woohoo! archive: open!
<steveire> doko_: It is from the ubuntu repos: http://pastebin.kde.org/pd5cusahh
<steveire> The triple x86_64-linux-gnu is appended for search, but arm-linux-gnueabihf should be appended instead. That seems to be the result of a debian patch
<doko_> steveire, I didn't look at clang cross builds at all. feel free to submit patches
<steveire> doko_: I'm asking you to remove a patch :)
<steveire> <doko_> apachelogger, then make clang -target work ... <<< What was this about?
<doko_> steveire, just removing the patch would be wrong too
<doko_> also please recheck with the llvm-toolchain-snapshot package first. you are citing patches applied for 3.0 ...
<steveire> aptitude search llvm-toolchain-snapshot gives no results.
<cjwatson> apt-get source llvm-toolchain-snapshot
<cjwatson> aptitude search only searches *binary* package names
<steveire> doko_: The 21- patch is indeed very different there. In conclusion, I don't know why the wrong triple is still appended.
<steveire> And /usr/include/clang/3.2/include/ is empty.
<steveire> ... which is what that patch currently adds to the search path.
<steveire> Is there anywhere else I could grep? Apart from debian/patches?
<xnox> Laney: barry: https://launchpad.net/ubuntu/+source/emacs-defaults/45.0ubuntu1
<wgrant> Oh good, no need to port emacs23 to arm64 then :)
<Laney> neat
<doko> didn't see a reason not to do that. and unseeded too
<xnox> doko: it's just all the r-depends will need porting/migrating to emacs24.
<doko> they all have alternatives
<xnox> but yeah, we need it.
<doko> tvoss, do the pretty printers work for you?
<tvoss> doko, yup
<tvoss> tkamppeter, ping
<cjwatson> jdstrand: Could you reupload apparmor to trusty so that it builds against perl 5.18?  I'd do it myself but lp:~ubuntu-core-dev/apparmor/master is out of date with your most recent upload.
<doko> barry, python compat ping
<cjwatson> doko: could you merge libhdate for the perl transition?
<doko> cjwatson, doing
<cjwatson> ta
<tkamppeter> tvoss, hi
<tvoss> tkamppeter, hey there, how are you?
<tkamppeter> tvoss, fine.
<tvoss> tkamppeter, cool :) do you remember our discussion at one of the last vuds's about readying our printing stack for on-demand printing on the phone?
<tkamppeter> tvoss, currently I am working on the print filters for PPD-less printing.
<tvoss> tkamppeter, I remember that you talked about slimming down the printing stack. did you have a chance to tackle that?
<tvoss> tkamppeter, ah, so ppd-less printing is a prerequisite, isn't it?
<tkamppeter> tvoss, that is one of my intentions, to split up the cups and cups-filters packages more and (for the phone/tablet only) use Poppler as renderer and leave out GS, dropping support for PS as input format.
<tvoss> tkamppeter, ack. Do you have a blueprint somewhere tracking those items?
<tkamppeter> tvoss, yes, to not need to keep PPD collections on the device and to make printers with known protocols work without printer setup tool.
<tkamppeter> tvoss, yes, there are Blueprints.
<tkamppeter> tvoss, https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind
<tkamppeter> tvoss, this is the main Blueprint.
<tkamppeter> tvoss, here is also one with the print dialog, for the GUI devs: https://blueprints.launchpad.net/ubuntu/+spec/client-1305-mobile-print-dialog
<tkamppeter> tvoss, there is also one about the PDF renderer, but we finally opted for Poppler.
<tvoss> tkamppeter, ack, I'm fine with poppler. I do see a work-item for color profile mgmt, though
<tvoss> tkamppeter, that is, in the main blueprint
<tkamppeter> tvoss, on the phone we can start without Color Management and add it as soon as it gets completely working in Poppler.
<tvoss> tkamppeter, yup, sounds good. So what is missing to have cups start on demand on the phone?
<tvoss> tkamppeter, I would think integrating it with upstart and its socket observer functionality shouldn't be too difficult
<tvoss> tkamppeter, also: for the scanner daemon: Would we really need it running all the time? I would think it should come up on demand if the user wants to print to something network local only. Does that make sense?
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> wgrant: You're touched-it-last for subversion; do you intend to merge it (new upstream, and for the perl 5.18 transition), or should I?
<wgrant> cjwatson: Feel free, though I'll hopefully get to them this week.
<jdstrand> cjwatson: ack
<doko> isn't it nice to have a sh** load of merge work to do after finishing some things late in the previous cycle? ;p
<tkamppeter> tvoss, yes, we could start it when the user opens the print dialog and stop it when the print queues get empty.
<tvoss> tkamppeter, sounds good to me then :) also: do we have a filter for google cloud print for cups?
<tkamppeter> tvoss, no, we do not have anything which prints as client into the Google Cloud. I think we need to implement this in the print dialog, as the Google Cloud is one of the user's personal resources, and CUPS only handles system resources, not per-user queues for example.
<tvoss> tkamppeter, hmmm, could we just run cups in a user session?
<tkamppeter> tvoss, a user account manager must log in the user on Google so that he can use all Google services, then a print dialog backend needs to list the user's cloud printers and the user can print on them, these should work fine when sending PDF to them.
<tvoss> tkamppeter, ah okay. mardy, do online accounts support that scenario?^
<tkamppeter> tvoss, theoretically CUPS can run in a user session, but it will get complicated for the packaging, the CUPS configs on desktop and mobile would be completely different then and Cloud Print only gets available for mobile.
<stgraber> mlankhorst: you'd need a technical board for that, unfortunately we all expired a bit over a week ago so I'll be happy to process that once the elections are over and if I get re-elected
<mardy> tvoss: if Google Cloud printing supports OAuth, yes
<tvoss> tkamppeter, ^?
<mlankhorst> stgraber: no lameduck TB?
<tvoss> tkamppeter, also: which packages would we need at a minimum on the phone? seeded that is?
<mardy> tvoss: looks like it does, so yes, it should be quite feasible
 * mardy needs to run out
<tvoss> mardy, ack and thx
<tvoss> doko, ping
<doko> tvoss, just ask
<tvoss> doko, any reason the static boost libraries are built without -fPIC for amd64?
<doko> tvoss, policy. Is there a reason not to use the shared ones?
<doko> xnox is our boosted expert
<tvoss> doko, well, for the sake of cutting a runtime dependency
<cjwatson> we don't duplicate code in the archive for the sake of cutting runtime dependencies
<cjwatson> as a general rule anyway
<doko> tvoss, there are a very few cases in the archive. but then these are called libfoo_pic.a
<cjwatson> and those are generally for very special cases
<tvoss> cjohnston, ack
<cjohnston> :-/
<tvoss> cjwatson, ack
<tvoss> cjohnston, sorry :)
<xnox> doko: thanks i'll look into removing boost static libraries all together, one day =)
<doko> never mind, xfuzz
<ogra_> doko, xfuzz ? shouldnt that be Mir-fuzz nowadays ?
<ogra_> :P
<james_w> hi xnox, do you need your udd changes deployed?
<tkamppeter> tvoss, I do not know about the authentication mechanism of Cloud Print. There is a simple program in Universe (AFAIK named cloudprint) which shares out local printers to the user's cloud print account, perhaps it contains hints.
<xnox> james_w: last time I've checked branch-distro was still in progress.
<tvoss> tkamppeter, ack
<james_w> xnox: ok
<xnox> james_w: if/when that finished I or wgrant can restart udd.
<james_w> xnox: ah, you can deploy yourself? perfect
<james_w> thanks for working on it
<xnox> james_w: i have access to that machine, but no access to lp:udd =) which is a bit backwards =))))
<james_w> heh
<xnox> james_w: can you add me to the team, please? =)
<tkamppeter> tvoss, needed are CUPS (made smaller by binary package splitting, no web interface, no online help, no command line printing), cups-filters (also made smaller by package splitting), Poppler AFAIK.
<james_w> so demanding!
<james_w> xnox: done
<xnox> james_w: thanks a lot =))))
<Ursinha> slangasek, hello :) are you still having this issue? https://bugs.launchpad.net/compiz/+bug/763148
<ubottu> Ubuntu bug 763148 in Compiz Core "Adding/Removing an external monitor causes open windows to move to another workspace" [Medium,Fix committed]
<doko> jamespage, maven induced mismatches: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<cjwatson> doko,jamespage: looks like it's due to a change in libjaxen-java?
<doko> cjwatson, yes,     - Use the upstream pom instead of debian/pom.xml
<doko>     - Switched to Maven to build the package
<arges> does anybody mind if I add the trusty symlink to precise's deboostrap?
<arges> or is somebody already working on this?
<Harbort> hey, does anyone know how the grub file grubx64.efi.signed is generated?
<Harbort> it contains absolute references to the ubuntu distribution, causing trouble for sub-distributions such as kubuntu!
<jamespage> cjwatson, doko: urgh
<doko> jamespage, be happy, up to now it's just one package ;)
<cjwatson> Harbort: most of it's in the grub2 package.  and exactly which reference are you talking about?  the /EFI/ubuntu path is correct for Kubuntu too
<xnox> cjwatson: apart from kubuntu, using /EFI/kubuntu path for some reason.
<Harbort> cjwatson: I mean that in the file grubx63.efi.signed there is a (unique) reference to /EFI/ubuntu. But since kubuntu 13.04, the dev of kubuntu decided to change the path for the kubuntu boot from /EFI/ubuntu to /EFI/kubuntu
<Harbort> xnox: exactly
<xnox> cjwatson: bug #1242417
<ubottu> bug 1242417 in grub2 (Ubuntu) "UEFI install broken on Kubuntu 13.10" [Undecided,Confirmed] https://launchpad.net/bugs/1242417
<xnox> cjwatson: and there are similar against ubiquity "finished kubuntu install, black screen, uefi no boot"
<cjwatson> Harbort: that Kubuntu change must be reverted
<xnox> Harbort: that's rather bug in kubuntu packages that modify it.
<Harbort> cjwatson: so in the end, it seems that if kubuntu could re-generate the efi image, changing the reference from /EFI/ubuntu to /EFI/kubuntu, it would work
<cjwatson> It's foolish
<cjwatson> Harbort: No, I'm not going to build separate signed images for Kubuntu
<cjwatson> It's pointless busy-work for no reason
<cjwatson> Kubuntu shouldn't have made that change without consulting the GRUB maintainer
<xnox> Harbort: you can't regenerate .signed easily, as it need to be signed by microsoft.
<cjwatson> xnox: no, please don't spread misinformation!
<cjwatson> that file is signed by us
<apachelogger> cjwatson: bug 1242417 so what do we do?
<xnox> cjwatson: oh, ok.
<ubottu> bug 1242417 in grub2 (Ubuntu) "UEFI install broken on Kubuntu 13.10" [High,Triaged] https://launchpad.net/bugs/1242417
<cjwatson> but nevertheless, it is cumbersome to generate other versions of it - they're referred to by grub-install etc.
<cjwatson> apachelogger: revert whatever changes you made to use /EFI/kubuntu
<cjwatson> And check with me next time?
<apachelogger> we only define GRUB_DISTRIBUTOR
<cjwatson> apachelogger: argh, not that again
<cjwatson> apachelogger: I'm tempted to revert all the GRUB_DISTRIBUTOR=kubuntu changes
<cjwatson> They cause far more trouble than they're worth
<apachelogger> I know, you'd think such a tiny thing would be a no-brainer xD
<cjwatson> The GRUB distributor here is Ubuntu - Kubuntu uses the same GRUB as all other flavours
<cjwatson> So it's really inaccurate
<cjwatson> But I know you were trying to handle branding :(
<cjwatson> apachelogger: I guess I will slather on some more complexity to deal with the complexity.
<cjwatson> Because what could possibly go wrong ...
<apachelogger> cjwatson: see bug comment for options, I am somewhat indifferent at this point ... though I'd argue that the maintainer scripts are misbehaving if they expect EFI/G_D to work and we don't support that
<apachelogger> lol
<apachelogger> cjwatson: actually another approach is to add slightly more complexity that allows changing the name that shows up in the created grub entries without changing GRUB_DISTRIBUTOR
<cjwatson> The maintainer scripts weren't misbehaving until Kubuntu broke the rules
<apachelogger> as you said, it's really just about the branding
<cjwatson> Well, I don't know, it may depend on which involves the larger patch
<lool> Saviq: pong, albeit I'm on leave until Thursday (inclusive), but perhaps I can help?
<Saviq> lool, just a quick question, hopefully: ideas on how should we tackle the /usr/bin/unity8 hack when upgrading the unity8 package (for automated testing in -ci jobs)
<Saviq> lool, we could ship a pre-inst script that would unmount it
<cjwatson> apachelogger: I don't think I want to change the menu generation - that's more likely to result in a patch that's more work to maintain going forward
<xnox> cjwatson: i think kubuntu is not the only one that customized GRUB_DISTRIBUTOR.
 * xnox goes to check.
<cjwatson> xnox: It's the only one I know of in the Ubuntu archive
<Saviq> or maybe adding a post-stop script to the unity8-setcap job (and stopping it) would be better
<lool> Saviq: Hmm that's a good question, but do we reboot then?
<lool> Saviq: Actually rather than invest in this, could we prioritize ripping this off?
<cjwatson> xnox: And it's the only one with support for it in other parts of the grub2 source package
<Saviq> lool, sure, what's the plan on that? bumping the rootfs to ext4?
<Saviq> lool, have we a bug? who do I talk about this to?
<lool> Saviq: My understanding is that we don't need the hack; first, we already start unity8 with a negative score, and second we could also simply restrain to positive scores; in both cases, we don't need the setcap hacks
<lool> Saviq: tvoss was working on the logic picking up scores; don't think we have a bug for this, but he had a WIP branch
<Saviq> lool, thanks, will follow up with him
<tvoss> lool, https://code.launchpad.net/~thomas-voss/unity-mir/less-aggressive-scores
<tvoss> Saviq, ^
<Saviq> tvoss, and that would rid us of having to setcap unity8?
<tvoss> Saviq, yup
<Saviq> oh cool
<Saviq> greyback, can you please prioritize ââ?
<greyback> Saviq: okey
<Saviq> greyback, thanks
<lool> greyback: Reason it's urgent is probably because it breaks ci runs of unity8 right now due to /usr/bin/unity8 being a bind-mount in the read-only images
<cjwatson> apachelogger: do you have any way to test fixes for this in trusty?
<greyback> lool: tvoss really? I don't see how changing OOM scores has any impact on that bind-mount problem
<apachelogger> cjwatson: yes, I only today noticed that my laptop supports UEFI and secureboot and that pile of madness ^^
<apachelogger> cjwatson: i.e. I have already tested if you change the build script to use EFI/kubuntu instead it works as expected
<lool> greyback: we thought we had to setcap /usr/bin/unity8 as to allow it to set OOM scores; it actually only needs this for scores lowers than itself, and we don't really need this
<tvoss> greyback, what lool says
<lool> greyback: we need to bind-mount it because we're using ext2 as the read-only base
<lool> greyback: we use ext2 due to limitations in our recovery ROM
<lool> (we should lift these too BTW)
<greyback> lool: interesting. Ok, thanks for the answer
<xnox> cjwatson: Ubuntu Studio also sets GRUB_DISTRIBUTOR to != Ubuntu, see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntustudio-default-settings/saucy/view/head:/etc/default/grub.d/50_ubuntustudio.cfg
<stgraber> cjwatson: looking at merges.u.c I appear to be TIL on grub-installer, should I let you deal with that one?
<cjwatson> xnox: Grr, well Ubuntu Studio will be even more broken, they need to revert
<cjwatson> I wish this trend hadn't been started without my consent
<cjwatson> It needs actual design rather than ad-hocery
<cjwatson> stgraber: Sure, I can take that
<stgraber> cjwatson: thanks
<slangasek> Ursinha: well, adding/removing an external monitor still moves windows around in ways that it shouldn't, but now they all stay on the same workspace..
<Ursinha> slangasek, right... well, in here it's pretty random, sometimes windows are all moved to the same workspace, sometimes they are in different workspaces but not where they're supposed to be
<slangasek> hmm
<slangasek> yeah, nothing quite that bad here
<Ursinha> slangasek, have you opened another bug for the remaining issue? I found one regarding fullscreen windows, that's not really the case here
<Ursinha> I have another bug in my intel driver that combined with this one is driving me crazy
<slangasek> Ursinha: I think there is one but I don't remember where
<slangasek> Laney, pitti: is bug #1240673 something that should get some attention in upower?  Seems to affect a wide range of Dell machines
<ubottu> bug 1240673 in upower (Ubuntu) "Reports 0% charged for fully charged batteries" [High,Confirmed] https://launchpad.net/bugs/1240673
<slangasek> ScottK: ^^ escalating to the upowers that be ;)
<ScottK> slangasek: Thanks.
<cjwatson> apachelogger: Perhaps you could try http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/trusty/grub2/trusty/revision/2359 ?
<Laney> Mmm, pitti's going to be better at debugging that than me
<cjwatson> apachelogger: If that works, I can do the upload to trusty, but I'd appreciate it if somebody Kubuntuish could take care of the SRU ...
<apachelogger> ok
<xnox> cjwatson: and about studio? revert. Or grub2 will start maintaining a list of "supported" ubuntu aliases.
<roaksoax> /win/win 3
<roaksoax> err
<cjwatson> xnox: Studio should revert for saucy
<cjwatson> xnox: Maybe we can figure out something for trusty
<cjwatson> xnox: I'm treating Kubuntu differently because it already had partial support in the grub2 source package - Studio didn't
<xnox> cjwatson: i wonder if kubuntu's snippet should include # WARNING! below only works due to special casing in grub2 packages
<xnox> cjwatson: to prevent more derivaties just looking up "how kubuntu did it"
<apachelogger> seems useful
<apachelogger> I'll add one
<xnox> distro-info-derivatives anyone?
<apachelogger> oh my
<cjwatson> xnox,apachelogger: I'll do something in the next Debian upload
<cjwatson> apachelogger: if you could leave the Ubuntu branch alone for the meantime it would help me be less confused about its state :)
<apachelogger> cjwatson: the snippet is in lp:kubuntu-settings
<apachelogger> I assume xnox was talking about the cfg file setting GRUB_DISTRIBUTOR
<cjwatson> apachelogger: ah, sure
<mdeslaur> don't we usually sync ltses from stable?
<apachelogger> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-settings/kubuntu-settings/revision/571
<xnox> mdeslaur: since britney migration available in ubuntu, we always sync from unstable.
<mdeslaur> xnox: ah! that makes sense I guess. Thanks.
<xnox> mdeslaur: cause we get all the same benefits, sans 10-day delay. (well RC-bugs in debian is something to keep an eye on)
<cjwatson> mdeslaur: we never synced from stable anyway - testing in the past.  but what xnox said
<mdeslaur> cjwatson: er, yes, I meant testing
<stgraber> arges: I'll take the ifupdown merge.
<arges> stgraber: ok. thanks
<bdmurray> slangasek: do you have any ideas on the problem in bug 1241487?
<ubottu> bug 1241487 in ubuntu-release-upgrader (Ubuntu) "Release upgrade aborts with error message" [Undecided,Confirmed] https://launchpad.net/bugs/1241487
<slangasek> bdmurray: is that after we fixed the gnome-bluetooth thing?
<slangasek> because that seems to be the same problematic loop as in the gnome-bluetooth case
<bdmurray> slangasek: yeah, I tried used the upgrader in -proposed and it still failed
<slangasek> hmm
<bdmurray> The following packages have unmet dependencies: libgdm : Breaks: gdm (< 3.8.3-3~) but 3.6.1-0ubuntu4 is to be installed
<bdmurray> that's from trying a dist-upgrade with apt
<slangasek> ok, the log also shows gnome-bluetooth in the heart of this
<slangasek> Investigating (0) gnome-shell [ amd64 ] < none -> 3.8.4-0ubuntu5 > ( universe/gnome )
<slangasek> Broken gnome-shell:amd64 Depends on gnome-bluetooth [ amd64 ] < none -> 3.8.1-2ubuntu2 > ( gnome ) (>= 3.0.0)
<slangasek>   Considering gnome-bluetooth:amd64 3 as a solution to gnome-shell:amd64 0
<slangasek>   Holding Back gnome-shell:amd64 rather than change gnome-bluetooth:amd64
<bdmurray> slangasek: so why does it choose not to install gnome-bluetooth?
<slangasek> dunno yet
<slangasek> walking back through the list, gnome-bluetooth isn't the root cause this time though
<slangasek> obex-data-server is the next one
<slangasek> bdmurray: in the reproducer environment, what do you get with just an 'apt-get install obex-data-server'?
<slangasek> (trying to install the saucy one, not raring)
<bdmurray> The following packages will be REMOVED: obexd-server
<slangasek> right
<slangasek> so they have a conflicting package installed
<bdmurray> hmm and that only appears in the installed packages list in the aptclone file afaict
<slangasek> bdmurray: obexd-server is brought via recommends from bluez-tools; I think the right solution is to figure out if that Recommends can be changed to obexd-server | obex-data-server, or possibly dropped altogether
<pitti> slangasek, ScottK: I'll respond with some debugging questions, shouldn't be too hard to reproduce in a test
<ScottK> pitti: Excellent.  I've got an affected system, so I'm glad to help out.
<apachelogger> cjwatson: r2359 fixes UEFI for trusty
<apachelogger> cjwatson: the bcfg entry still has Desc kubuntu though, not sure if that matters
<apachelogger> mh, one could argue it's part of the branding, I guess I am happy ;)
<doko> jamespage, can you take care about the maven issues? or should I?
<LeeJunFan> I have a bug, not sure which package to file under... btrfs /home on an encrypted volume (luks). Mountall doesn't wait for it during boot. It does ask for the password and calls cryptsetup to open it, but I have to manually call #mount /home after boot is complete.
<seb128> ev, could you have a look to https://bugs.launchpad.net/ubuntu/+source/activity-log-manager/+bug/1198681 ? it's ranked 7 on the saucy issues today
<ubottu> Ubuntu bug 1198681 in activity-log-manager (Ubuntu) "gnome-control-center crashed with SIGSEGV in on_properties_changed()" [Medium,Confirmed]
<juliank> python-apt 0.9 is now in the Debian archive, merging the Ubuntu changes; many bug fixes; and entries for trusty in data/templates/Ubuntu.info.in
<cjwatson> apachelogger: Yeah, I assumed you wanted to keep that bit
<cjwatson> apachelogger: Thanks for the test, I'll upload to trusty shortly
<hallyn> stgraber: would you mind pushing http://people.canonical.com/~serge/lxc-halt.debdiff to precise-backports?
<stgraber> hallyn: I can't push to backports (well, I can but am not supposed to)
<stgraber> hallyn: I think what we should do is test the saucy package on precise and if that works ok, then ask for a backport of that one
<stgraber> that should give the missing features some users have been asking for a while and get us rid of lxc-halt in the process
<hallyn> well i'm running daily ppa not saucy, but it works terrific for me on precise :)
<hallyn> ok, this just seemed like an easy way to avoid some cursing in our general directions
<hallyn> so after we test, we should talk to ... ScottK ?
<stgraber> yeah, same here. I'll try to find an hour or so to stress test the current saucy package on precise and if that works, then just ask a backport of that one
<hallyn> ok, thanks.  testing the getting-rid-of-anonpath right now
<slangasek> sarnold, jdstrand: so given that libestr is now a hard dependency of rsyslog upstream, I guess that the result of the audit is going to be "fix these bugs", not "you can't have this in main"...  would it be ok for me to upload the rsyslog merge to -proposed, and let it sit there waiting for build until the MIR is done?
<sarnold> slangasek: fine by me
<juliank> Damn. I wrote "Trusty Thar" instead of "Trusty Tahr" in python-apt 0.9.0. Stupid /me
<doko> apw, this has to build something on i386 ... https://launchpad.net/ubuntu/+source/linux-meta-ppc/3.11.0.3.5/+build/5127063
<apw> doko thanks, i'll have a look as it doesn't seem it should indeed, must be a control foul up
<YokoZar> Why is /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so  in the non-multi-arch p11-kit package?  :(
<slangasek> YokoZar: because it's a plugin for a package that only looks in /usr/lib/x86_64-linux-gnu/pkcs11/
<YokoZar> slangasek: Wine is still throwing this error:
<YokoZar> p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
<YokoZar> (on 64-bit).  So it seems to be trying to look there :/
<slangasek> I'm not sure why you're surprised that the 32-bit library looks in the 32-bit pat
<slangasek> ptah
<slangasek> $dir
<YokoZar> what I mean is I can't install both p11-kit:i386 and p11-kit:amd64 because they're not multiarch (not sure if that even makes sense in this case), but for some reason Wine is trying to find the p11-kit-trust.so library
<slangasek> yes; the package needs to be split up to support that
<slangasek> but that's a non-fatal error
<slangasek> which is why it hasn't been a priority for anyone
<YokoZar> slangasek: we did split gnome-keyring already though, somehow I must have been mentally lumping the two together
<sarnold> can someone please poke the retracers for bug 1232311 ? Thanks :)
<ubottu> Error: Launchpad bug 1232311 could not be found
<slangasek> sarnold: poke how?  It's marked as a failed retrace
<slangasek> sarnold: what are you expecting a retrace to give you that it didn't give you the first time?
<sarnold> slangasek: mostly I just don't understand them well enough to know which output means "retracers have done all they can" vs "retracer died and needs to be restarted" or something...
<sarnold> slangasek: thanks for looking, I'll just delete the coredump and open the bug if the retracers can't squeeze any more juice from that rock :) hehe
<slangasek> sarnold: when the retracer dies, you get nothing; when the retracer has done all it can, you get 'apport-failed-retrace'
<sarnold> slangasek: thanks :)
<slangasek> sarnold: and now that we've fixed cron mail, the retracers haven't been down for more than a day, fwiw
<sarnold> slangasek: <3
<brainwash> bug 1183580 is still not fixed, it has been reported long before final release, but the package maintainer seems to be inactive
<ubottu> bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1183580
#ubuntu-devel 2013-10-22
<siretart> infinity: is libav9 good to upload now? If not, what kind of coordination do you think would be best for this package? note that the transition has been completed in debian, but in ubuntu, we may have some additional undermaintained packages that break.
<infinity> siretart: I'm ready for it whenever, yeah.  I assume Ubuntu carries a delta that needs to be addressed.
<infinity> In fact, looks like the last uploader was me, for wgrant.
<infinity> siretart: Do you have Ubuntu sources ready for it?  I wouldn't mind giving it a once-over, and then letting it go.
<siretart> infinity: no, in ubuntu, we do have a delta because we need to handle libav-extra specially
<infinity> siretart: Right, the -extra thing, plus some aarch64 patches (though, we'd want those in Debian too)
<siretart> infinity: in debian, all dependencies are in main, ubnutu, libx264, xvid, lame, and many others are only in multiverse. that's why we need libav-extra
<wgrant> (they're in universe now, but close enough)
<siretart> aarch64 patches? send them upstream, I may even roll  them in a point release :-)
<infinity> They're from upstream.
<siretart> yeah, same problem.
<siretart> even better!
<infinity> none /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
 * infinity looks suspiciously at that, and wonders who to blame.
<infinity> Oh, look, it's upstart's fault.
<infinity> xnox: upstart is mounting devpts wrong, plz fix.
 * xnox thinks it's time for me to go to sleep.
<infinity> Convenient. :P
<slangasek> infinity: what's wrong about it?
<slangasek> infinity: ah, missing gid=tty and wrong mode?
<infinity> slangasek: Just mounts with defaults, no gid or mode.
<slangasek> yeah
<slangasek> really love that upstart and mountall both have to deal with mounting
<slangasek> really want to merge those :P
<infinity> Why aren't they?  The misguided assumption that mountall might be used from another init system?
<slangasek> no, it was a practical consideration at the time Keybuk was developing it
<slangasek> and no one's had the time since then to go back and merge them
<infinity> I'm puzzled as to which circumstances lead me to a mountall-mounted devpts and which lead to an upstart-mounted one.
<infinity> My laptop gets the gid/mode from /lib/init/fstab (so, I assume, mountall), but this dev board I just set up gets no gid/mode, so I assume it's from upstart.
<infinity> In neither case is there anything going on in /etc/fstab or other such oddities.
<infinity> The dev board has no initrd, which I assume confuses matters a bit.  Maybe that's the big difference.
<infinity> Oh, in fact, wasn't "no initrd" the use-case that led to upstart leaning to mount some kernel filesystems on its own?  This is coming back to me...
<infinity> s/lean/learn/
<slangasek> infinity: do you have an initramfs?
<infinity> In fact, maybe mountall never gets around to touching devpts at all, but on my laptop, we're carrying over the mount that initramfs-tools (correctly) set up in early boot.
<slangasek> yep
<slangasek> in practice mountall "can" mount these but never gets a chance because they're pre-mounted by the initramfs for most people
<slangasek> but in the initramfsless case, upstart has to mount them; this path is not well-exercised
<infinity> Well, I've been exercising it a bit in the last month. :)
<infinity> And other than the above gid/mode oops, it seems to largely work as expected.
<slangasek> heh, ok then. :)
<slangasek> maybe you want to just fix bug #1039887
<ubottu> bug 1039887 in mountall (Ubuntu) "fstab does not honor /proc mount options" [Medium,Triaged] https://launchpad.net/bugs/1039887
<infinity> slangasek: Fix, as in have mountall 'mount -o remount' everything in fstab?
<slangasek> infinity: maybe?  I haven't thought through what the right fix would be :)
<slangasek> but if mount options are missing, I don't think it should ignore that
<infinity> slangasek: Well, one could pull fstab into the initramfs, but that makes it much more system-specific than they usually are, plus every time we have one more "if you update this conffile, you need to re-run update-initramfs", it gets 5% less intuitive.
<slangasek> yes
<slangasek> also, that doesn't get you a free fix for the initramfsless, upstart-had-its-own-idea problem
<infinity> Indeed.
<infinity> Well, upstart's idea about devpts should be fixed regardless.
<infinity> But agreed that /lib/init/fstab and /etc/fstab should probably be reparsed by mountall even for already-mounted filesystem to fill in the blanks on sysadmin preferences.
<slangasek> yeah - fix upstart, but also make it less of a problem in the future for upstart's mount model to be out of sync
<ntzrmtthihu777> heyo. how hard, if possible, would it be to create an ubuntu iso that can boot live or install k/l/x/ubuntu?
<vimpulse> ntzrmtthihu777:  one ISO which gives you a choice of four Ubuntu flavors?
<ntzrmtthihu777> vimpulse: yep
<vimpulse> (followup:  in #ubuntu-offtopic, ntzrmtthihu777 mentioned that s/he wants this only for fun.  Flannel added that such a thing already exists, though s/he didn't recall where it's downloadable from.)
<ntzrmtthihu777> also, since the ubuntu iso has already broken the cd size limit, any thought given to bundling x86_64 and i386 versions into one iso, like arch linux?
<Flannel> vimpulse, ntzrmtthihu777: http://rww.name/grub2iso.html  talks about it (or its functional equivalent) (at the bottom)
<ntzrmtthihu777> Flannel: I know of this method, and have dones so before, but, since the differences are negligable between flavours there seems to be no reason to have multiple squasfs files and bloat up the iso image/usb stick
<vimpulse> ntzrmtthihu777:  This matter is probably offtopic here.  Please see my reply in #ubuntu-offtopic.
<Noskcaj> What happened to perl 5.14? I've just lost a stack of packages since it isn't working
<pitti> Noskcaj: it's spelled "5.18" now
<Noskcaj> Then i really need to fix some packages
<infinity> Noskcaj: There's a transition in progress.  If your packages are failing to build because build-deps aren't installing, just wait a bit and retry in a day or two.
<Noskcaj> No, i've lost a heap of installed packages
<infinity> ...
<Noskcaj> xchat and yarssr are my main issues
<infinity> You're running -proposed?
<infinity> I feel like perhaps we've told you a few dozen times that that's a very bad idea.
<Noskcaj> infinity: Unfortunately, i hear bad idea as "do this". I'll see what i can do with the (few) packages broken that i access
<ScottK> Noskcaj: We can't save you from yourself.  If you break stuff against explicit advice, you should really not bug the people who told you not to do it to help you fix it.
<Noskcaj> ScottK: of course, i just hadn't realised the break was because i had -proposed on
<ScottK> Noskcaj: If you've got proposed on, assume any break is because that.
<Noskcaj> ok
<ScottK> Seriously.  You're running a configuration that is completely and utterly unsupported that NO ONE is ever supposed to run.
<ScottK> Is that sufficiently clear or are you still thinking "I think he means I should do it"?
<Noskcaj> ScottK: Very clear. i hadn't realised proposed was on
<Noskcaj> You don't  need to get angry because of that
<zyga> good morning
<AtuM> can anyone tell me if the package openvswitch-brcompat will be available in 13.10 ? All I find is an outdated one.
<AtuM> I have openvswitch 1.10.2-0ubuntu2 installed.. I found openvswitch-brcompat version 1.9 for saucy..  brcompat is getting obsolete fast, but virt-manager still can't do without.
<halfie> hi
<halfie> is "-Werror=format-security" turned on for all packages by default?
<halfie> or is it ON only for packages built with DEB_BUILD_HARDENING=1 ? .. and how are packages made PIE *selectively* then?
<debfx> halfie: yes, if they use dpkg-buildflags (directly or through debhelper compat level 9)
<halfie> oh, can you please break that down for me?
<halfie> "-Werror=format-security" is ON for all packages, right?
<halfie> 2. how do I make a package PIE in Ubuntu
<debfx> export DEB_BUILD_MAINT_OPTIONS=hardening=+pie
<halfie> ah I see now, there are options besides DEB_BUILD_HARDENING=1
<halfie> it seems DEB_BUILD_HARDENING=1 is the default when building any package, correct?
<debfx> afaik DEB_BUILD_HARDENING is a hardening-wrapper thing
<halfie> debfx, yes, it is part of that wrapper.
<halfie> do you have this wrapper activated on official Ubuntu build machines?
<halfie> essentially, I want to understand if it is "safe" to turn on "-Werror=format-security" by default and system-wide?
<AtuM> How come udev rules are written so that /dev/disk/by-path/* drives include serial/model number? that beats the whole meaning of using by-path link
<AtuM> nevermin.. I'll ask on #udev
<mantiena-baltix> james_w: hi are you online?
<mantiena-baltix> hi all
<mantiena-baltix> could someone tell me when package sources import from debian will be enabled?
<mantiena-baltix> I need packaging folder from latest Debian package to build new release of gnome-shell-extension-weather, see https://answers.launchpad.net/udd/+question/237721
<ogra_> mantiena-baltix, i think it already is
<ogra_> ..."Trusty is now open for development, with syncs from unstable currently running." ...
<ogra_> from the ubuntu-devel ML
<mantiena-baltix> ogra_: but why William Grant (wgrant) said yesterday: package importer has been disabled since Friday in preparation for Ubuntu Trusty.
<mantiena-baltix> ogra_:  see https://answers.launchpad.net/udd/+question/237721
<StevenK> Package importer has nothing to do with syncs
<wgrant> mantiena-baltix: I reenabled package-import a few hours ago, but it will take a little while to catch up.
<wgrant> And it's separate from the sync mechanism.
<mantiena-baltix> wgrant: thanks, it seems I can expect today to see up to date lp:debian/gnome-shell-extension-weather , right?
<wgrant> mantiena-baltix: It could take 2-3 days.
<mantiena-baltix> wgrant: oh, maybe I can see the progress somewhere?
<wgrant> http://package-import.ubuntu.com/status/
<mantiena-baltix> thanks
<mantiena-baltix> bye
<smartboyhw> xnox: Bug 1242417
<ubottu> bug 1242417 in grub2 (Ubuntu) "UEFI install broken when GRUB_DISTRIBUTOR!=Ubuntu (e.g. Kubuntu/UbuntuStudio)" [High,In progress] https://launchpad.net/bugs/1242417
<xnox> smartboyhw: yes?!
<smartboyhw_> I'x
<xnox> smartboyhw_: ubuntu studio needs to revert that change, because grub* maintainer scripts do not consider Studio as an alias for ubuntu and restults in a non-booting Studio.
<smartboyhw_> xnox: Not sure if the
<smartboyhw_> linux-lowlatency kernel supports UEFI
<mlankhorst> probably does, why wouldn't it?
<xnox> smartboyhw_: thus studio-default-settings should revert in saucy & trusty, until grub2 supports multiple distributions.
<smartboyhw_> xnox: OK, I will tell OvenWerks
<xnox> smartboyhw_: kernel doesn't have much to do with UEFI, apart from optional modules to provide EFIvars via sysfs. But it does boot with UEFI fine.
<Laney> pitti: looks like ddebs needs to learn about trusty?
<Laney> also, hello!
<smartboyhw_> xnox: OK.
<mlankhorst> wow.. why does /var/cache/apt/archives/linux-image-3.11.0-12-generic_3.11.0-12.19_amd64.deb check on AMD64 whether the cpu is pae capable or not
<tkamppeter> HP wants to start testing HPLIP on ARM systems, can someone tell me where I find instructions to get started with Ubuntu development on ARM and also about recommended hardware?
<mlankhorst> https://wiki.ubuntu.com/ARM/Server
<tkamppeter> mlankhorst, thanks. Is there also something about the Ubuntu Desktop on ARM?
<mlankhorst> nah since that's reliant on hardware support
<mlankhorst> binary drivers
<mlankhorst> graphics on arm is a mess
<tkamppeter> mlankhorst, thank you very much.
<xnox> tkamppeter: for bringing up new ARM development boards, it's best to use https://wiki.ubuntu.com/Core
<xnox> tkamppeter: take ubuntu armhf rootfs + bring your own kernel + bring your own bootloader (usually part of the board anyway)
<pitti> infinity: FTR, I added trusty-ness to http://ddebs.ubuntu.com/dists/
<Laney> woot
<doko> jamespage, testng is another maven conversion
<brainwash> pitti: hey, any more ideas on how to debug bug 1184262? running logind in foreground doesn't reveal any useful information, and I'm not sure if the guys of in #systemd will help me with ubuntu's systemd/logind implementation
<ubottu> bug 1184262 in network-manager (Ubuntu) "[logind] stuck in PrepareForSleep, causing network and other services to not resume" [High,Confirmed] https://launchpad.net/bugs/1184262
<doko> jamespage, testng is another maven conversion (and it's b-d's too, guice and jcommander)
<doko> barry, could you look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg and handle webtest and python dependencies?
<pitti> brainwash: #systemd> right, it's most certainly something in between our patches and systemd-shim, so upstream can't/won't help
<doko> barry, the question being, if we want pypy in main ...
<pitti> brainwash: I guess next up would be debugging the exchanged messages/signals (https://wiki.ubuntu.com/DebuggingDBus) and see whether there is anything weird there
<pitti> brainwash: running /usr/lib/x86_64-linux-gnu/systemd-shim in the foreground might also reveal something
<pitti> brainwash: FTR, I ran my session for four days with two dozen suspends now, without any hitch..
<brainwash> pitti: so it's some sort of race condition or timeout occurring
<brainwash> because it does happen randomly
<pitti> presumably
<barry> doko: sure, i'll take a look
<brainwash> pitti: alright, I'll start to monitor everything from now on and report back, thanks :)
<pitti> brainwash: if that doesn't reveal anything either, the next step would be gdb, I guess..
<pitti> brainwash: but at that point I'd need access to an affected system, or some recipe how to reproduce it
<cjwatson> stgraber: FYI your lxc merge broke touch due to overly-strict parsing in lxc-android-config; fixed now in l-a-c but you may want to test merges to critical touch infra :)
<stgraber> cjwatson: doh, well, my pre-upload tests here do include touch, just not that particular init script... I guess I should include a full reboot test
<stgraber> that really should be: lxc-info -n android-dev -p|awk '{print $2}'
<stgraber> s/android-dev/android/ (android-dev is the one on my laptop)
<ogra_> stgraber, except that i hate awk with passion ...
<ogra_> :)
<ogra_> stgraber, fixed with a [[:space:]] now
<seb128> ogra_, you hater!
<ogra_> haha
<seb128> ogra_, wie gehts? ;-)
<ogra_> seb128, super !
<stgraber> ogra_: [[:space:]] should be good enough indeed. I'd still recommend using -p instead of the silly | grep pid
<ogra_> fixing the framework around the webapps atm :)
<ogra_> stgraber,  oh is that new ?
<stgraber> ogra_: nope, been there forever
<stgraber> without -p, lxc-info will attempt to get ip addresses and a bunch more info from the container which you don't use, so -p should make it more lightweight
<ogra_> stgraber, how about a --raw switch too that removes the silly header :)
<ogra_> (i.e. just returns the pid)
<stgraber> ogra_: we already have a feature request for that on github or LP, just need someone to write a patch for it ;)
<ogra_> stgraber, ok, will add that to the next upload
<ogra_> stgraber, i was wondering yesterday ... if someone has /usredata/.writable_image and flashes without --no-backup, will he get a writable image automatically ? (we should probably remove the file during flashing if thats the case)
<stgraber> ogra_: that's more of a question for sergiusens I think. At least the upgrader doesn't remove the flag, so if phablet-flash doesn't, then nothing does
<ogra_> yeah
<ogra_> i think as soon as i use phablet-flash you can assume i want it ro again
<ogra_> but i guess thats a philosophical question :)
<pitti> mvo_, cjwatson: is anyone already looking at the python-apt merge? I'd like to do it now to get "trusty" info into it (this breaks several things ATM)
<cjwatson> I'm not
 * cjwatson files an RT for trusty chroots on porter boxes
<mvo_> pitti: its hopfully just a merge, no? i.e. is there anything left that is ubuntu specific?
<pitti> mvo_: right; in the best case it's a sync
<mvo_> pitti: i mean, I'm happy to add trusty and do a debian upload :)
<pitti> mvo_: trusty already went into 0.9.0
<pitti> mvo_: our current delta is to add saucy and add "Multi-Arch: allowed" (both of which should go into Debian)
<mvo_> great
<mvo_> yeap
<Laney> I think they both did in 0.9.0
 * pitti verifies
<mvo_> apt should be the same btw, that is hopefully just a sync too
<pitti> yep, all in, nice!
 * pitti syncs
<pitti> jibel: ^ FYI
<mvo_> pitti: cool
<pitti> mvo_: I think apt still has some delta, e. g. 0.9.9.1~ubuntu3 sounds rather ubuntu specific
<pitti> (whereever that strange version came from)
<mvo_> pitti: ok, let me check
<brainwash> pitti: just a quick question, is systemd-shim supposed to run all the time?
<pitti> brainwash: no, it's dbus-activated and times out after some minutes
<brainwash> pitti: ah ok, thanks
<pitti> mvo_: oh, so looking at https://launchpad.net/ubuntu/saucy/+source/apt/+changelog it's probably not that bad
<pitti> mvo_: 0.9.9.1~ubuntu1 was just a merge from Debian anyway, so we mostly just need to look for the delta of the last two versions?
<mvo_> pitti: looks like it, I will merge the latest upload from infinity into the ubuntu branch now
<mvo_> pitti: there is a ubuntu/master branch in the git tree for the merging and I was utterly wrong about sync :) still a bit of a delta
<pitti> mvo_: so http://launchpadlibrarian.net/146396279/apt_0.9.9.1~ubuntu1_0.9.9.1~ubuntu2.diff.gz is in sid
<mvo_> pitti: great
<pitti> mvo_: http://launchpadlibrarian.net/149979633/apt_0.9.9.1~ubuntu2_0.9.9.1~ubuntu3.diff.gz isn't; perhaps/hopefully that's the only delta
<pitti> mvo_: oh, ubuntu/master has stuff which isn't uploaded?
<mvo_> pitti: its all uploaded, its just in there to make the merge easier
<pitti> mvo_: given that linux-tools is in Debian as well, that might be something for Debian, too?
<pitti> ah no, not with the full abi
<mdeslaur> siretart: could you please comment on bug 1243235?
<ubottu> bug 1243235 in libav (Ubuntu) "Please demote libav to universe" [Undecided,New] https://launchpad.net/bugs/1243235
<mvo_> pitti: yeah, looks like it might not be a perfect fit. I just did a git merge debian/sid in the ubuntu tree and it does not look too horrible should be a matter of some minutes to resolve the conflicts
<pitti> mvo_: splendid, thanks; I'm currently walking through https://merges.ubuntu.com/a/apt/REPORT and there's some more apparently
<pitti> mvo_: like cmdline/apt-key debian->ubuntu servers, etc.
<pitti> ah, and the dependency: debian-archive-keyring -> ubuntu-keyring
<pitti> mvo_: but that's pretty much it, so yes, the delta should be rather small
<mvo_> pitti: just fyi http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=shortlog;h=refs/heads/ubuntu/master should be good now
<mvo_> pitti: I gtg, can do a bit more testing/upload later tonight
<smartboyhw> cjwatson, xnox: To confirm, for Studio we should be reverting the changes in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntustudio-default-settings/saucy/revision/48 (file etc/default/grub.d/50_ubuntustudio.cfg)?
<cjwatson> smartboyhw: For the moment, yes
<smartboyhw> cjwatson, OK, so I shall do the changes?
<cjwatson> smartboyhw: Please
<xnox> smartboyhw: note, it's a conffline, hence rm_conffile with .maintscript snippet will be needed $ man dh_installdeb
<smartboyhw> xnox, OK
<smartboyhw> cjwatson, xnox: Rarely have experience with .maintscript, is http://paste.ubuntu.com/6283517/ correct?
<xnox> smartboyhw: test it, upgrading from previous package to that one should remove the file on disk.
<cjwatson> smartboyhw: needs a version
<cjwatson> Probably 0.50~ (note tilde)
<smartboyhw> cjwatson, the version = the version before the one I'll be uploading? (i.e. 0.49?)
<smartboyhw> oh
<cjwatson> read the dpkg-maintscript-helper man page.
<smartboyhw> xnox, cjwatson the fix works:)
<smartboyhw> cjwatson, https://code.launchpad.net/~smartboyhw/ubuntu/trusty/ubuntustudio-default-settings/fix-bug-1242417/+merge/192179 for you
<smartboyhw> Uh, wait
<zequence> cjwatson: Let me have a look first as well..
<zequence> cjwatson: smartboyhw is operating on his own behalf. He hasn't discussed any changed with ubuntu studio devs, Oven in particular who made those changes, so I'd rather we have some internal communications first, unless there's a really apparent solution
<xnox> zequence: point is that that change should have been cordinated with grub maintainer first, as simply setting that variable results in broken installs that cannot boot (at least on uefi). As matching changes are required in the grub package (some of which were in-place for kubuntu).
<seb128> ev, hey, did you see my ping about that activity log manager bug?
<xnox> zequence: thus it must be reverted in saucy & trusty, until more generic facility for menu-item branding is provided by the grub package.
<xnox> seb128: he is away on sprints and stuff =/
<seb128> xnox, yeah, but still online
<xnox> seb128: he uses irc bouncer/proxy.
<seb128> xnox, well, he wrote on IRC since
<xnox> ah.
 * seb128 needs to go for lunch
<seb128> bbl
<cjwatson> zequence: What xnox said.  The Ubuntu Studio developers who made this change didn't discuss it with me as grub2 maintainer.
<cjwatson> zequence: And as a result it is broken.
<cjwatson> zequence: smartboyhw is operating on my request, not on his own behalf.
<bdmurray> ev: have you and mpt talked about colors for 14.04?  I'm working on adding it to errors
<ev> I have no preference :)
<zequence> cjwatson: Well, no one is talking to the one who made the change, and changes were not made to our source
<zequence> I asked smartboyhw to remove the merge request, as it was towards the ubuntu source, and not the ubuntustudio source
<zequence> we have to have some kind of order in how we do things
<cjwatson> zequence: That order should have involved talking to the grub2 maintainer before doing weird things in /etc/default/grub.d/ :-P
<cjwatson> IOW creating support headache for me
<cjwatson> Please land smartboyhw's change
<cjwatson> (Even if to a different branch or whatever)
<ogra_> ev, huh ? not pink anymore ?
<ev> pink is best
<ev> best. best. best.
<ogra_> :)
<ev> (http://www.youtube.com/watch?v=n7-RetY7fGo)
<ogra_> haha
<zequence> cjwatson: I'm not against reverting the change itself. I'm being happily ignorant about the problems around it - allthough I'd rather see as many changes done upstream as possible, which I always tell the Ubuntu Studio devs (Oven I believe went forward following Kubuntu's example, and probably did not realize the full impact of it).
<zequence> cjwatson: Just that, this is the second time a change to ubuntu studio source is submitted, bypassing ubuntu studio branches
<saiarcot895> If there is a package that has a CVE that affects all supported versions, and that was fixed in Saucy (well, from Debian), can it go in as an SRU?
<zequence> cjwatson: And also, bypassing the devs themselves. That's all I'm worried about
<cjwatson> zequence: Sure, I expect Howard just didn't realise the right branch to target; happens with installer branches all the time
<xnox> saiarcot895: it maybe should go in as a security update, check with #ubuntu-hardened (ubuntu security team channel)
<saiarcot895> xnox: thank you
<tkamppeter> Anyone working with emacs here?
<esing> hi, I want to report a bug for ubuntu on launchpad, but I get this bug message when trying to report the bug  "Invalid OpenID transaction"
<Pici> esing: #launchpad would be a better place to ask
<esing> thanks for the hint
<infinity> siretart: So, when do you want to get started on this libav9 transition?  I'm ready whenever, as soon as you have libav/libav-extra ready to upload.
<arges> so i'm looking at bug 1121874, would it make sense to upload a trusty update even though the merge from debian hasn't happened yet?
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu Saucy) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,In progress] https://launchpad.net/bugs/1121874
<infinity> arges: I'd just do it as part of the merge, IMO.  We're hammering the builders enough as it is.
<arges> infinity: ack. also the fix needs to be SRUed for P/Q/R/S, that will need to wait until its in Trusty right?
<infinity> Not strictly speaking, no.  As long as I know the fix is in progress for T, it doesn't HAVE to be first.  We just need to know it's going to not get forgotten.
<infinity> Ideally, this should be forwarded to Debian (has it been?), so we don't accidentally lose it along the way.
<arges> infinity: it hasn't been yet. Its an upstart fix, so I'm guessing its something that could be forwarded
<arges> I wasn't sure if debian was using upstart of this was an ubuntu specific delta (i need to check)
<infinity> arges: Also, unless it's tied up in a transition, if you SRU to S, I could copy it forward to T.
<infinity> arges: The upstart job might be ubuntu-specific but, if it is, we should fix that and forward it too.
<infinity> rbasak: Are you going to be doing the mysql-5.5 merge?
<arges> infinity: ok great, I'll check that out. As for the copy forward that's fine but there isn't a hurry, just want to do the Right Thing
<infinity> arges: The Right Thing is to make sure the fix doesn't get lost and cause a regression.  There are many ways to skin that particular small mammal.
<mdeslaur> arges: I'd wait a bit before doing any mysql srus, I'm preparing security updates for the stable releases
<infinity> Oh, right, I forgot that he can't see those in the build queues. :P
<infinity> arges: PS: mysql security updates are hammering the builders right now.
<arges> mdeslaur: ok i'll wait
<arges> infinity: yea mysql is a beast to build
<infinity> The building is fine, the testsuite is... Extensive.
<arges> yea that's what i meant : )
<rbasak> infinity: I'm not sure. We know we need to catch up on it. I'll look at all the merges when I'm back after Linaro Connect
<infinity> rbasak: Kay.  mdeslaur is in the process of doing security updates, which will bump the upstream version, and I'll copy that from S to T when he's done.
<infinity> rbasak: But we may be behind on packaging changes.
<rbasak> OK
<infinity> mdeslaur: Well, assuming you do a saucy upload. :P
<mdeslaur> infinity: yes
<infinity> mdeslaur: Oh, also, while we're dealing with potentially sketchy hardware, if you have weird arm64 FTBFSes in the security PPA, let me know, and I'll sort them.
<infinity> mdeslaur: (Poking the one in there right now)
<mdeslaur> infinity: cool, thanks
<doko> mterry, it does effect testng because it uses maven ...
<mterry> doko, testng was already in main, but you mean the question of whether to promote maven or drop dep on maven?
<doko> the latter
<mterry> doko, I see
<mterry> doko, OK, will add back, sorry
<doko> unless jamespage wants to write hunders of MIRs ,p
<doko> hundreds even
<mterry> doko, I didn't look at maven yet
<mterry> I don't like the sound of that, no
<doko> mterry, see the dependency graph: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<doko> Source: cracklib2
<doko> Uploaders: Martin Pitt <mpitt@debian.org>
<doko> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724842
<ubottu> Debian bug 724842 in src:cracklib2 "cracklib2: FTBFS: error connecting to "www.oasis-open.org" (Connection timed out)" [Serious,Open]
<doko> https://launchpad.net/ubuntu/+source/cracklib2/2.9.0-1
<doko> pitti, ^^^
<roaksoax> /w/win 3
<stgraber> mdeslaur: mind if I steal that sudo merge from you?
<cyphermox> xnox: around?
<mdeslaur> stgraber: go right ahead :)
<doko> slangasek, would you mind if I merge pango1.0? librsvg waits on it
<mdeslaur> infinity: and...arm64 build failed in the secppa
<doko> mdeslaur, can't see what did fail and why. so you are on your own ...
<mdeslaur> doko: infinity can, and offered
<mdeslaur> doko: thanks
<infinity> mdeslaur: On it.
<mdeslaur> infinity: awesome, thanks
#ubuntu-devel 2013-10-23
<slangasek> doko_: I'll go ahead and upload it
<geofft> Hi folks. Almost any use of LD_AUDIT on amd64 on Precise/Quantal causes a segfault due to a bug in libc6 that's been fixed upstream
<geofft> The patch is fairly tiny (it just checks for null, mostly). Is it reasonable to expect an SRU for this?
<geofft> This bug makes latrace, for instance, completely useless
<infinity> geofft: Is there a bug filed?  With a pointer to the upstream fix?
<infinity> geofft: Expecting an SRU for something I haven't heard of until today is probably wishful thinking.  But I can certainly include it in my next SRU round if I know about it.
<geofft> Not yet. Just wanted to check it was worth doing so, or whether libc6 is too scary to be worth doing non-security SRUs for
<geofft> inifinity: Yeah, I'm totally happy to file a bug then describing it. Thanks!
<sarnold> hey geofft :)
<geofft> Oh, bad phrasing on my part, "expect" = "expect that a bug will be useful", not "expect it'll automatically get fixed"
<geofft> hi sarnold!
<infinity> geofft: File a bug and point me to it.  I do SRU glibc occasionally, as you can spot from the changelog.
<infinity> geofft: I won't SRU *just* for minor bugs like that, but if there are some easy cherrypicks I can do to make pepole happy at the same time as fixing more serious bugs, I'll do it.
<geofft> Do you want the standard SRU format [Impact] etc.?
<slangasek> yes :)
<infinity> geofft: If you're willing to do the full SRU template, go nuts.  Saves me the effort.
<slangasek> doko_: well, or I would upload it, except it doesn't pass its test suite
<slangasek> which is puzzling, because the error is obvious, the test is looking for a file in the build dir that it needs to look for in the source dir
<slangasek> doko_: the tests are broken with glib2.0 (>= 2.37.2), there's some goofy g_test_get_filename() function here that doesn't work.
<slangasek> which relies on setting G_TEST_SRCDIR, which nothing does.
<geofft> infinity: Filed LP #1243473. Let me know if you need more detail.
<ubottu> Launchpad bug 1243473 in eglibc (Ubuntu) "LD_AUDIT is broken on amd64" [Undecided,New] https://launchpad.net/bugs/1243473
<geofft> Relatedly, LD_AUDIT is the awesomest thing ever, and latrace is like ltrace that actually works. (Well, modulo that bug.)
<em> what kernel is the latest ubuntu using?
<sarnold> em: saucy's kernel version in the package name is 3.11.0-12.19
<sarnold> em: "Ubuntu 13.10 includes the 3.11.0-12.19 Ubuntu Linux kernel which was based on the v3.11.3 upstream Linux kernel. " https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes
<infinity> geofft: That should be enough, thanks.
<sarnold> geofft: cool, thanks for the fun new tool recommendation :)
<slangasek> doko_: ok, pango1.0 uploaded finally
<Logan_> doko_: Are you around?
<Logan_> Or cjwatson?
<infinity> Logan_: Just ask your question...
<Logan_> Bleh, okay. Thought it merited their specific attention for specific reasons. :P Is 14.04 deriving from unstable or testing? Because doko_'s email says that syncs are running from unstable.
<Logan_> But I thought LTS releases derive from testing.
<infinity> It's from unstable.  Now that we have proposed-migration, syncing from testing doesn't buy us much, and tends to just slow us down.
<Logan_> Alright, cool. https://wiki.ubuntu.com/LTS should be updated, then.
<Logan_> Why is ubuntu-dev-tools's syncpackage script defaulting to syncing from testing, then?
<infinity> Because someone didn't get the memo, I suspect.
<infinity> I'll fix that.
<Logan_> It doesn't seem that it was specifically set to that for trusty. I wonder if there's a config in there for every x releases deriving from testing.
<infinity>             if ubu_info.is_lts(ubu_info.devel()):
<infinity>                 dist = 'testing'
<infinity> That bit just needs to go away.
<Logan_> Oh, yup.
<Logan_> Want me to file a bug, or are you going to handle it?
<infinity> I'll fix it right now.  But for now, you can just use '-d unstable'
<infinity> Oh, xnox already fixed it.  Which is why I can't find the bits in bzr. :P
<infinity> Logan_: It's correct in bzr, it's just not been uploaded yet.  I assume bdrung will get around to pushing it to Debian and syncing soon.
<Logan_> Okay, awesome. Thanks for your help, Adam!
<infinity> Or maybe I'll upload it to Debian now, so more people don't end up confused.
<infinity> bdrung: Were you planning an ubuntu-dev-tools upload to sid?  Mind if I do one?
<Logan_> You might cause a conflict! :P
<Noskcaj> Is it ok to merge stuff from unstable now, due to proposed-migration?
<sarnold> Noskcaj: yes, that was discussed a few hours ago, and syncing from unstable is now the new desired state
<Noskcaj> sarnold: ok, thanks for the info.
<sarnold> Noskcaj: ubuntu-dev-tools's syncpackage script has apparently been fixed in bzr already, just not re-packaged yet
<pitti> Good morning
<sarnold> morning pitti :)
<ScottK> Noskcaj: Unless someone is known to be inactive, up until DIF you should check with the last person to touch a merge before doing it.
<ScottK> pitti: Your upower patch worked great.  I look forward to testing the SRU when it's ready.
<ScottK> Thanks.
<pitti> ScottK: nice; I'll prepare one today then
<sarnold> ScottK: DIF?
<ScottK> Debian Import Freeze.
<sarnold> thanks :)
<pitti> doko_: there's also a bug for it, debian bug 724842
<ubottu> Debian bug 724842 in src:cracklib2 "cracklib2: FTBFS: error connecting to "www.oasis-open.org" (Connection timed out)" [Serious,Open] http://bugs.debian.org/724842
<Noskcaj> ScottK: don't worry, i have asked myself ;)
<Noskcaj> smb: Do you plan to upload a newer dahdi-linux any time soon?
<Noskcaj> pitti: bug 1079605
<ubottu> bug 1079605 in initramfs-tools (Ubuntu) "[FFe] Please sync with the latest 0.113 from Debian testing" [High,Triaged] https://launchpad.net/bugs/1079605
<pitti> doko_: fixed cracklib uploaded to Debian, will autosync
<pitti> Noskcaj: yeah, infinity wanted to have a look at some point, but I guess he was busy
<Noskcaj> ok, thanks for the info
<pitti> Noskcaj: we have a quite a large delta, and some of it is hopefully not required any more, etc.
<pitti> Noskcaj: so if you feel like looking into it and making a first assessment of our delta, please feel free :)
<Noskcaj> pitti: I would have no idea where to start
<pitti> Noskcaj: ah, that's fine; I thought you asked because you considered doing the merge
<Noskcaj> Not for something that big, i was just checking that it hadn't been forgotten
<Noskcaj> That said, if anyone has merges for me to do, i've finished with all the packages that are in my name
<pitti> Noskcaj: if you want to steal some of mine, I'd be in your debt :) (but perhaps avoid aptdaemon)
<pitti> ScottK: upower SRU uploaded and bug updated for SRU, FYI
<geofft> Agh, I'm confused about multiarch. Why do libc6-i386 and libc6:i386 both exist?
<slangasek> geofft: libc6:i386 is just the native build of libc6 for i386.  libc6-i386 is a "biarch" (or "multilib") build of libc6, packaged for amd64, because some things aren't yet solved using multiarch
<slangasek> like, the compiler itself
<geofft> So I legitimately need both? OK
<slangasek> you legitimately need both if you have packages installed that depend on each :)
<Noskcaj> My requestsync keeps breaking, so would someone mind syncing visp and osgearth?
<bkerensa> software-properties-gtk seems to be epic broken in trusty
<bkerensa> its crashing pretty rapidly
<Noskcaj> bkerensa: It didn't open for me last time i tried
<bkerensa> Noskcaj: exactly it didnt open and whoopsie dialog popped up
<bkerensa> a quick look in syslog now shows a line a second of software-properties-gtk crashing and whoopsie sporadically trying to report it
<bkerensa> looks like there is not software-properties-gtk candidate for trusty either
<bkerensa> aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/trusty
<bkerensa> thats the issue
<Noskcaj> pitti: I've merged gpgme1.0 for you, have you got time to review the branch?
<pitti> Noskcaj: sure
<Noskcaj> plus you should be safe to sync visp
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gpgme1.0/1.4.3/+merge/192293
<Noskcaj> I'll try and work on psqlodbc now
<pitti> Noskcaj: oh, did the DD take the autopkgtest fix?
<pitti> Noskcaj: ah no, visp needs a merge
<Noskcaj> pitti: Looks like it from the changelog
<pitti> Noskcaj: plus, it never built on i386 for us due to a test failure
<cjwatson> what entry in the Debian visp changelog suggests that they took our change?
<pitti> Noskcaj: nope, I filed debian bug 726983 much later
<ubottu> Debian bug 726983 in visp "visp: autopkgtest failure due to stderr output from test program" [Normal,Open] http://bugs.debian.org/726983
<cjwatson> even a cursory debdiff makes it clear they didn't.  Please put more effort into verification or else don't request syncs
<cjwatson> otherwise you're throwing away other developers' work
<Noskcaj> crap, i was looking at a different package as well, i am sorry for wasting yourtime
<pitti> Noskcaj: gpgme uploaded, thanks
<bkerensa> Noskcaj: I found the problem its python-apt well slangasek found it :) but I am going to fix it
<Noskcaj> thanks bkerensa
<Noskcaj> pitti: no problem, i shouldn't have copy/pasted the chagelog though
<pitti> Noskcaj: oh, copy&pasting them is fine in general (everyone does that anyway), it just sometimes needs some trimming for the slightly different context
<Noskcaj> pitti: gpgme is FTNFSing, give me a minute to disable the bad (gnupg2) test
<Noskcaj> *FTBFS
<pitti> Laney: can you please add an autopkgtest override for bzr-builddeb? This has never worked, and is now blocking python-apt from propagating (new version fixes a lot of things due to the added trusty template)
<pitti> bkerensa: ^ FYI
<bkerensa> :D
<Noskcaj> pitti: It might be better if you fix the ftbfs for gpgme1.0 since my only fix is disable dh_auto_test (which fully works)
<Laney> pitti: okay, but "never worked"> someone should look into that, of course
<pitti> Laney: yes, of course; but it shouldn't block the propagation
<pitti> Laney: once the sync/build/binNEW rush settles down a bit, I'm planning to go through/fix/poke people all of the failures
<Laney> well, it's correct that it does as that is how the integration is specified
<Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-bzr-builddeb/
<Laney> why can't I see the details in the jobs?
<Laney> can in trusty
<pitti> Laney: right, but bzr-builddeb was failing in saucy, and it's not the new python-apt which breaks bzr-builddeb
<pitti> Laney: hm, I don't know why the later saucy builds are broken in that way
<Noskcaj> cody-somerville: Do you plan to keep maintaining catfish in debian?
<Noskcaj> If so, it really needs an upload. if not, please file a wnpp bug
<didrocks> pitti: ah, bzr-builddeb was already failing?
<didrocks> we don't have that traced, I was trying to reproduceâ¦ (but can't on my installed saucy machine)
<didrocks> and yeah, python-apt doesn't change a thing tried
<didrocks> Laney: pitti: I was tracking it as this is one of the last piece blocking us to resume releasing things to trusty
<didrocks> (we can't run the tests as add-apt-repository is failing as we don't have latest python-apt)
<bkerensa> Has trusty patch pilots officially kicked off yet?
<pitti> didrocks: you mean bzr-builddeb or p-apt?
<pitti> didrocks: ah, so p-a
<didrocks> yeah, p-a
<bdrung> infinity: i can do the upload now. do you want to add yourself and do the upload to unstable?
<Laney> I added the force-badtest
<Laney> but I don't think I'm a fan of "it wasn't me that broke the tests, so let's ignore them"
<Laney> We should have noticed when they started failing in saucy and fixed it then
<Laney> Not that I can actually reproduce the failure under run-adt-test :(
<pitti> no? I can
<Laney> I got it in a plain chroot
<Laney> missing python-distro-info test-dep but then there's one more failure
<ogra_> pitti, Laney i guess bug 1243573 is for one of you :)
<ubottu> bug 1243573 in Ubuntu system image "Timezone setting is gone after upgrade to Ubuntu Touch touchy" [Undecided,New] https://launchpad.net/bugs/1243573
<Laney> Ubuntu Touch touchy
 * Laney blinks
<ogra_> haha
<pitti> bug in our "synced" system-image writable-files mode?
<ogra_> pitti, probably, i didnt research it, there were so many errors with that upgrade
<ogra_> (apps all vanished, system-image-cli didnt allow me to switch channels etc)
<pitti> ogra_: (followed up to the bug)
<ogra_> thx
<bdrung> where to report recipe build failures to (that are caused by the build infrastructure)?
 * ogra_ guesses against launchpad
<cjwatson> bdrung: launchpad-buildd
<bdrung> thanks
<cjwatson> bdrung: but check the existing reports, there are a few standard ones in there that are blocked on host upgrades
<Laney> ogra_: I think the upgrade wiped out more than it should have
<Laney> I lost my accountsservice settings too
<ogra_> my U1 account stayed
<Laney> e.g. greeter background and it showed me the first run tutorial
<ogra_> and my wallpaper too
<ogra_> same for language
<Laney> I said greeter backgroudn on purpose
<Laney> the unity background stayed, and that is in gsettings
<ogra_> all apps were gone for me ...
<Laney> also had a new SSH host key, but I can't remember if that's expected when using phablet-flash
<popey> Laney: you lost data when going from saucy to trusty?
<Laney> my home directory is intact
<bdrung> cjwatson: i found the bug already reported: it is bug #1089615
<ubottu> bug 1089615 in launchpad-buildd "Source builds fail for packages with "3.0 (quilt)" format and unapplied patches" [Low,Triaged] https://launchpad.net/bugs/1089615
<ogra_> popey, i lost all apps here, data stayed
<popey> hmm
<ogra_> (i didnt have to newly log in to G+ but had to reinstall the app)
<Laney> pitti: argh, finally got it
<Laney> If you don't have libalgorithm-merge-perl installed then dpkg-mergechangelogs generates conflicts in some situations when it doesn't if you have it installed
<Laney> One of which is in the bzr-builddeb testsuite
<Laney> It's a Recommends of dpkg-dev
<pitti> Laney: ah, so somehow libalgorithm-merge-perl made it into my VM test, but not into your's?
<Laney> I must have had both python-distro-info and libalgorithm-merge-perl installed for the tests to succeed, but the jenkins VMs didn't
<Laney> so there's a difference somewhere between run-adt-test and those
<pitti> so they need to become test deps?
<Laney> in terms of dep installation
<Laney> and that, yes (well, I'm not sure if libalgorithm should actually be a real dep?)
<Laney> It's an implementation detail of dpkg-dev, but bzr-builddeb relies on calling that program to merge changelogs
<pitti> ah, so that's what one would need to uninstall to get back the old conflict markers
<Laney> old ones?
<pitti> I find that automatic changelog merging often sorts wrongly, and it's much less obvious what it damaged
<Laney> you mean within one entry?
<pitti> no, I mean it mis-sorts the older ubuntu entries in between the debian ones
<cjwatson> I often let it merge but then use "bzr shelve --destroy" to throw away the mis-sorting / other changes
<pitti> (often, anyway)
<cjwatson> particularly for changelogs in very old packages that contain misformatted junk at the bottom but I don't think it makes sense to reformat that in an Ubuntu delta
<pitti> but then again, it's been a while since I actually used bzr for merging, so maybe that got fixed
<Laney> Oh, well the testsuite allegedly checks for that
<Laney> Anyway, I'll just add them as test-deps I think
<cjwatson> pitti: FYI I rejected entangle as it was mistakenly uploaded to saucy.  Not sure whether you get notified as the sponsor
<alexbligh> Is there a way to make specific files in a .deb that are in /etc **NOT** conffiles? I have a directory similar to a .d directory which contains a bunch of stuff put there by the package and also a bunch of stuff put there by users. I don't want to delete the directory on package removal or I'll lose the user's stuff (so I don't really want to symlink out of /etc). However, I do want the individual files the pack
<alexbligh> age installed to be removed (because the new version tends to install other files with slightly different names). What's the best way to do this?
<pitti> cjwatson: argh, thanks; autofingers still need readjustment..
<pitti> cjwatson: reuploaded to trusty
<cjwatson> alexbligh: Use dpkg-maintscript-helper's tools to manage the upgrade changes
<cjwatson> alexbligh: And keep them as conffiles
<pitti> cjwatson: yes, I got a rejection mail
<alexbligh> cjwatson, are they on Lucid?
<cjwatson> alexbligh: (note that you can use debian/foo.maintscript to make this fairly easy; see dh_installdeb(1))
<cjwatson> alexbligh: It would be quicker for you to check than me, if you have a setup
<alexbligh> cjwatson, thanks, will do.
<cjwatson> alexbligh: But apparently not; on lucid the correct thing to do is to simulate the same actions by hand in maintainer scripts
<cjwatson> (carefully)
<alexbligh> cjwatson, complete brainfart here, target is Precise these days. Not enough tea.
<cjwatson> precise has dpkg-maintscript-helper so it's all much easier
<cjwatson> https://wiki.debian.org/DpkgConffileHandling if you need to backport to earlier releases
<alexbligh> cjwatson, thanks once more
<shadeslayer> tseliot: ping
<mardy> didrocks: hi! Any idea why this is failing? https://code.launchpad.net/~mardy/signon/packaging/+merge/190911
<shadeslayer> tseliot: I was looking at https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1224098 and preinst.in seems a bit weird to me, line 19-20
<ubottu> Ubuntu bug 1224098 in nvidia-prime (Ubuntu) "xserver wont start after nvidia-prime installation" [Undecided,Confirmed]
<shadeslayer> -s returns true if the file exists and size is greater than zero, but then there's a ! before it ... why?
<didrocks> mardy: reusty is not there yet, we are working on it
<tseliot> shadeslayer: let me have a look
<shadeslayer> ack
<tseliot> shadeslayer: it's obvious a bug (some leftover I assume)
<tseliot> *obviously
<shadeslayer> ack :)
<shadeslayer> tseliot: want to sponsor a upload ? :D
<shadeslayer> also, shouldn't checking -s suffice?
<tseliot> shadeslayer: I'll request an SRU for precise and saucy and upload. I'll need some help testing the fix (so that the SRU team can approve it)
<tseliot> yep
<tseliot> that's why I said "leftover"
<shadeslayer> roger roger
 * shadeslayer goes back to looking at bugs
<infinity> pitti: I'll be doing a bi-directional merge of initramfs-tools in the next week or two.  It's high on my list.
<pitti> infinity: ah, you can do changes in Debian, too? convenient
<infinity> bdrung: I did a bzr snapshot upload of ubuntu-dev-tools to Ubuntu, but whenever you do the Debian upload, you can just sync over that.
<infinity> pitti: I should hope I can, I've been upstream for it since it was written.
<bdrung> infinity: okay, i will do the debian upload now. do you want to SRU that fix to saucy?
<infinity> (Granted, not a very active upstream since maks took over)
<infinity> bdrung: I'm not terribly picky about SRUing it back, since I run the devel release, but if you want to push it back to saucy and maybe precise, go nuts.
 * pitti sets up trusty LP apport retracers
<tseliot> shadeslayer: are you available to test a package locally?
<shadeslayer> tseliot: not the nvidia-prime one :P
<shadeslayer> because I don't have a nvidia card
<shadeslayer> I just noticed the bug in another channel, and decided to investigate
<tseliot> shadeslayer: oh, never mind then
<mdeslaur> infinity: how did you fix mysql on arm64?
<cjwatson> mdeslaur: was it an ICE or similar?
<mdeslaur> cjwatson: yeah
<cjwatson> mdeslaur: some of the builders have reliability issues; looks like he gave it back on birch, which is the best of them
<mdeslaur> cjwatson: ah, cool. good to know, thanks
 * mdeslaur gives birch a cookie
<cjwatson> (birch has heat issues or something else that means we sometimes have to power it down for a bit, but it at least doesn't have random segfaults ...)
<mdeslaur> cjwatson: what kind of hardware are they?
<cjwatson> can't answer here just yet I'm afraid
<cjwatson> OK, I think the remaining bits of the Perl 5.18 transition (aside from waiting for builds and a few more no-change uploads) are (a) libdr-tarantool/i386 FTBFS (b) gdal FTBFS (c) libmongodb-perl FTBFS
<ScottK> pitti: upower SRU verified.  Thanks again for the quick turnaround.
<pitti> ScottK: nice, thanks
<ScottK> cjwatson: Just to double check before I accept this, you're OK with a grub2 SRU to fix the Kubuntu UEFI problem, right?  http://launchpadlibrarian.net/154805913/grub2_2.00-19ubuntu2_2.00-19ubuntu2.1.diff.gz
<slangasek> are Kubuntu the only ones setting GRUB_DISTRIBUTOR?
<ScottK> slangasek: I think Studio might have done so too,  but (and I didn't follow the details) there's some partial Kubuntu specific support for this already, so it's an easy fix, but for other flavors it'd be more complex.
<slangasek> mmk
<ScottK> I know Colin discussed it with shadeslayer  and apachelogger  before fixing in trusty, but (IIRC) he said the Kubuntu team needed to do the SRU.
<gdos> !bug 1243839
<ubottu> bug 1243839 in dwww (Ubuntu) "does not install completely. " [Undecided,New] https://launchpad.net/bugs/1243839
<gdos> !bug 1243859
<ubottu> bug 1243859 in dhelp (Ubuntu) "does not install completely (similar to #1243839)" [Undecided,New] https://launchpad.net/bugs/1243859
<doko> barry, any update on the component mismatches?  from my side we should make sure that both pypy and python-cffi build on arm64 before promoting it
<barry> doko: i agree with that.  i haven't done anything on it yet.  maybe tomorrow
<slangasek> bah, why does top in trusty clear the screen on exit?  who thought that was a good idea? :P
<slangasek> ev: so I have a strange issue here with apport; the crash file that I've managed to generate for unity8 on goldfish is missing a 'Package' field, which means apport-retrace will refuse to process it
<slangasek> ev: have you heard of such a bug, or do you have any idea what might cause it?
<ev> slangasek: have you run it through apport-cli yet?
<ev> something needs to call add_package_info or whatever the function is
<ev> whoopsie-upload-all will do this as well
<slangasek> hmm, is that something that needs to be run on the target system, I guess?
<slangasek> or at least, on some system where /usr/bin/unity8 exists
<geofft> isn't this the -R option to apport-retrace?
<geofft> apport-retrace --gdb doesn't work for me on /var/crash files, but --gdb -R does
<slangasek> well, since I'm cross-retracing it, I don't want it to wind up with package information from my host system
<slangasek> (particularly since unity8 isn't installed at all)
<slangasek> ev: so running apport-cli on it on the target system seems unlikely to finish any time soon
<slangasek> geofft: and -R seems to be insufficient, it still complains about the missing Package field
<ev> slangasek: yeah, you need to collect the additional data (via apport-cli or whoopsie-upload-all) on the phone itself
<slangasek> ev: hmm, challenging. :)
<ev> :) sorry
<slangasek> ev: yeah, apport-cli doesn't want to finish here (dies with 'Killed'), probably running out of memory
<ev> eep
<slangasek> perhaps I should spin up an emulator with a touch more than 90MB of RAM
<ev> emulator? is that actually working for touch stuff?
<slangasek> ev: no, if it were working I would not be trying to get a backtrace from unity8 ;)
<cjwatson> ScottK: Yes, I'm fine with it.  It'll need a grub2-signed upload afterwards.
<slangasek> but I do have a shell on it
<ev> :D
<slangasek> and am trying to get us to the next step
<ScottK> cjwatson: Thanks.
<stgraber> slangasek: based on what I'm seeing on real devices, I gues you'd need at least 512MB to have the emulator emulate something vaguely close to reality
<slangasek> quite possible :)
<slangasek> in fact, maybe trying to run it in 96MB of RAM is why unity8 segfaulted ;)
<slangasek> interesting, updating the config did not cause it to run with more RAM
<stgraber> considering it's taking almost 200MB on a physical device, that'd be a safe bet ;)
<slangasek> xnox: do you know how to get more than 96MB of RAM out of goldfish?
<slangasek> ah, guess it's just -memory
<rampageRipper> hello world,has anyone saved this page: books4electricians.blogspot.com?
<slangasek> cjwatson: what does the click run-user hook do on startup?  I'm seeing it do a whole lot of nothing here on goldfish and blocking the session startup, and I'm wondering if that's overall emulator slowness or miscellaneous system brokenness or what
<cjwatson> slangasek: It runs user hooks, which among other things is necessary to make .desktop files for preinstalled apps work properly
<cjwatson> slangasek: It shouldn't be doing anything especially exotic - you can look at the hooks in /usr/share/click/hooks/ with "User-Level: yes"
<slangasek> ok
<cjwatson> Which should be click-desktop, content-hub, upstart-app-launch-desktop at the moment (and click-desktop basically arranges to stub itself if upstart-app-launch-desktop is present)
<slangasek> well, now I just hung the emulator by running 'sync'
<slangasek> so yay
<cjwatson> I don't know what content-hub does
<slangasek> right, it's the content-hub that was runnnig
<slangasek> I wound up killing it to see
<ScottK> cjwatson: Who has to take care of uploading grub2-signed?
<cjwatson> ScottK: anyone really
<saiarcot895> What exactly is a debdiff? Is it just the diff of the sources?
<infinity> saiarcot895: Yeah, it's a diff between two source packages.
<infinity> saiarcot895: Or, that's the most common use of the tool and the term.  You can also debdiff binaries, which is handy. :)
#ubuntu-devel 2013-10-24
<smoser> cjwatson, around?
<smoser> anyone know... i have a system with 4 drives, trying to install to it.
<smoser> the bios has one of them marked as 'boot'
<smoser> is there any way to know which disk is boot to select that driver.
<saiarcot895> smoser: #ubuntu might help
<lifeless> saiarcot895: lololol
<lifeless> smoser: UEFI ?
<lifeless> smoser: or you mean just where to write the grub mbr?
<smoser> lifeless, yeah, which device to target with 'grub-install'
<lifeless> smoser: I'm going to guess that /dev/sda didn't work ?
<smoser> :)
<smoser> good guess
<lifeless> smoser: thats very odd
<lifeless> smoser: is it uefi w/gpt or ?
<smoser> mbr
<lifeless> smoser: so what I generally do there is grub-install all drivers
<lifeless> smoser: and have a mdadm /boot that is mirrored to all drives
<smoser> right.
<smoser> that was the first thougt at a solution
<smoser> but then if we give that drive (later) to something else
<lifeless> smoser: but...
<smoser> that blows away the grub on it
<smoser> then reboot will fail
<lifeless> smoser: when would you give the drive to something else?
<smoser> well after boot, but later.
<smoser> ie, i'd give it to ceph or something
<lifeless> smoser: I'm still not following the scenario
<lifeless> smoser: don't give ceph the full drive; give the drive two partitions - p1 is a 1G mdadm - part of /boot - p2 is a big blank device.
<lifeless> smoser: you give p2 to ceph.
<lifeless> smoser: you're looking at automating a robust answer for multi-drive bare metal ?
<smoser> right. maybe that is right.
<lifeless> smoser: for getting different setups, you want to pass in a raid descriptor as part of your machine type.
<lifeless> smoser: or flavor, or whatever your bm cloud calls such things ;)
<Noskcaj_> Is there away to find which apps still require python 2 on the iso?
<stgraber> apt-get remove --purge python2.7
<stgraber> that's usually pretty good at giving you a list
<infinity> Noskcaj_: If you don't want to fiddle with germinate to answer the question, a simple way would be to "apt-get install ubuntu-desktop^ ubuntu-live^" in a clean chroot, and then remove python.
<infinity> Ahh, I see stgraber beat me to that, sort of.
<Noskcaj_> Thanks for the info. I'll get a clean VM and try that
<pitti> slangasek: FTR, for crash reports that you didn't feed through apport-cli yet, you can run apport-retrace with -R; but then you need the same package versions installed there as on the system where the crash happened
<pitti> Good morning
<pitti> Laney: bzr-builddeb \o/ thanks!
<slangasek> pitti: right, which isn't going to be the case between a phone and a desktop, so
<slangasek> pitti: I think I assumed the package information was all gathered at the time apport runs for the crash; since to do otherwise means the files may change out from underneath before the data is gathered, resulting in skew in the reports...
<pitti> slangasek: right, but we check that at info collection time
<pitti> slangasek: the goal was to do as little as possible at crash time as you can't really control/suppress it as a user
<pitti> and only do the heavy lifting (querying packages, checking modifications, running hooks) when the user explicitly says "I want to report this"
<slangasek> understood, but it does mean there's the possibility of fuzz in the data being submitted as a result of package updates racing crash retracing
<slangasek> doesn't it?
<pitti> slangasek: apport does several checks for that, like "crash time must be > ELF modification time" and "ELF time at the time of crash must be equal ELF time at the time of data collection"
<pitti> otherwise the binary changed in between and gets rejected
<pitti> (well, the crash gets rejected, not the binary)
<slangasek> ah, right
<slangasek> so it doesn't cause bad reports to be submitted, at least - that's good
<pitti> it's a compromise
<pitti> but people complain about the background IO/CPU enough as it is already
<slangasek> yep
<infinity> pitti: You stole kmod from me? :P
<pitti> infinity: oh, were you going to update it? I didn't know you had a lock on it
<infinity> pitti: Nah, I don't care if you steal it, was just a bit surprised.
<pitti> infinity: how do you mean "steal"? it wasn't a merge
<infinity> pitti: I was TIL regardless, I'm not sure "not a merge" is the metric. :)
<pitti> well, I wish it was, Debian is several versions behind too
<pitti> infinity: interesting; I don't generally ask the TIL except for merges
<pitti> are we expected to now/
<pitti> ?
<infinity> I offered to co-maintain it with Md, but he claimed he didn't need the help. :/
<infinity> pitti: I don't ask TIL for bugfixes (clearly, I do a lot of them), but I tend to for things like a new upstream, since maybe they had plans.
<pitti> ok noted, I'll ask you next time about kmod
<slangasek> infinity: hey do you have plans for eglibc?  I was thinking about upgrading it to current CVS ;)
<infinity> slangasek: If you can find a current glibc in CVS, good luck.
<slangasek> actually, I just meant I was going to take the cvs source package and upload it in place of eglibc
<infinity> Oh, that could work.
<infinity> slangasek: Might need to patch gcc for s/-lc/-lcvs/ while you're at it.
<slangasek> no problem
<infinity> LDFLAGS="-liberty" MAKEFLAGS="-justice" CFLAGS="-for=all" make
<infinity> So sad that only one of those does something.
<sarnold> lol
<infinity> I suppose if I had ustice CPU cores.
<infinity> pitti: I suppose I could take TIL back by fixing your build failure. :P
<pitti> erk, missing xsltproc, sorry
<pitti> infinity: well, if you wish, otherwise I'll upload a fix
<infinity> pitti: I'm poking it now.
<pitti> thanks
<infinity> pitti: Hrm, are you sure we can drop check_builtin_kver?  I'd have to sort out how and when that's executed, but if it could ever be run and break on a buildd, we still need it.
<pitti> infinity: hm, why would you install trusty's kmod on a lucid machine/kernel?
<pitti> infinity: fine for me to put it back in, but it seemed like a rather obsolete extra check to me now
<infinity> pitti: You'd have it installed in any chroot building on a hardy-based buildd.
<pitti> (I hope you mean lucid)
<infinity> pitti: You wish I meant lucid.
<pitti> ah, I see
<pitti> infinity: we are running production machines which have been EOLed half a year ago?
<pitti> nice :)
<infinity> The function returns cleanly anyway, it's just noisy.  But I don't see any point in dropping the patch either.  *shrug*
<tarpman> pitti: infinity's comment made me curious. the sparc buildds (artigas and sejong) both appear to still be running 2.6.24 kernels
<pitti> tarpman: right, but they don't actually build anything newer than lucid any more
<tarpman> yeah
<pitti> (do they even do that?)
<pitti> I don't remember any more when we dropped sparc and hppa
<tarpman> https://launchpad.net/builders/sejong/+history seems to still build lucid updates
<pitti> ah, so we dropped it in karmic
<infinity> pitti: All the PPA buildds are hardy.
<pitti> infinity: erk -- then I guess we should reapply the patch to avoid some noise?
<infinity> pitti: Yeah, already uploaded.  But now I'm questioning this static/dynamic thing..
<infinity> bin/kmod on my system is dynamically linked.  Which is what I'd expect.  The new one isn't.  That seems suboptimal.
<pitti> according to upstream NEWS they did that to ease running from initramfs or other limited environments; and in the udev we want a static link anyway
<pitti> err, I can't type "udeb" for the life of it
<infinity> Erm, you what?
<infinity> udev links to libkmod directly, why would it care how /bin/kmod is linked?
<infinity> Oh, the udeb always was static.
<pitti> infinity: "udeb", "udeb", "udeb"
<infinity> The udeb was static, the deb wasn't.
<infinity> Which is correct, IMO.
<pitti> in a sense, "udev" wasn't totally wrong as it's built very similarly; udevd and udevadm themselves don't link to libudev
<infinity>         - kmod binary statically links to libkmod - if distro is only interested
<infinity>           in the kmod tool (for example in an initrd) it can refrain from
<infinity>           installing the library
 * infinity sighs.
<infinity> What if "distro" is interested in not having two copies of the library for no good reason?
<infinity> Oh well.
<pitti> I didn't find a switch to make /bin/kmod dynamically linked again, but I don't think it's a biggie so I didn't bother patching around
<infinity> I should statically link everything in libc-bin, in case distro is only interested in /usr/bin/iconv
<infinity> I'll argue this upstream if I find the energy, but no, don't care enough to fix it right now.
<infinity> I find "I don't know how to do library reduction to build an initrd" a pretty lousy reason for statically linking everything. :P
<lifeless> lsof 4 eva?
<lifeless> bah
<lifeless> I mean ldd 4 eva
<infinity> lifeless: Using lsof to discover library linkage could be a bit racy. :)
<UserError> What compiler flags and platform/march does ubuntu target for the 32 and 64bit platforms?
<lifeless> infinity: not to mention fatally buggy on platforms that map and close
<infinity> UserError: -mtune=generic on both, and -march=i686 on i386.
<UserError> thank you
<infinity> lifeless: ld.so still has it open for a fraction of a second.  lsof faster.
<lifeless> infinity: :>
<UserError> Is the add-apt-repository python 3 part going to be backported to LTS for the new features?
<UserError> on 2.7 or updated entirely
<lifeless> UserError: The only new features LTS gets are hardware support, anti-virus and similar updates, and firefox
<UserError> Oh, gotcha
<sarnold> details here https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<UserError> I don't suppose they would take kindly to asking for apt as an exception ;)
<UserError> or rather, a .py
<pitti> rbasak: hey Robie, how are you?
<pitti> rbasak: do you know when we'll get cloud images for trusty? It's currently rather inconvenient to run trusty autopkgtests
<ricotz> infinity, hi :), did libept1.4.12 broke abi? seems aptitude isnt happy with 1.0.10
<ricotz> aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs
<jibel> pitti, first images landed yesterday: http://cloud-images.ubuntu.com/trusty/20131023/
<pitti> jibel: hm, prepare-testbed still complains
<pitti> I guess no /current link yet
<Noskcaj> mdeslaur, Do you mind if i merge tiff?
<ogra_> pitti, hmm, seems we have a new powerd crash during tests of image #4 (http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/4:20131023:20131015/4795/sdk/) ... and i noticxe upower was the one suspicious change ... http://people.canonical.com/~ogra/touch-image-stats/20131023.changes ... any idea if your update could have caused that crasher ?
<pitti> ogra_: unlikely; upower fixed bug 1240673 with a very simple change (http://launchpadlibrarian.net/154787650/upower_0.9.23-1_0.9.23-2.diff.gz)
<ubottu> bug 1240673 in upower (Ubuntu Saucy) "Reports 0% charged for fully charged batteries" [High,Fix committed] https://launchpad.net/bugs/1240673
<pitti> ogra_: what's the crash?
<ogra_> pitti, see the first url, there is a .crash file
<pitti> ogra_: so unless this had a dell battery, it should behave identically
<ogra_> well, -1 had changes too
<ogra_> oh, that was -1
<ogra_> sorry
<ogra_> hmm, or i'm blind :P
<pitti> ogra_: well, for a few weeks now we had powerd crashes in every other test; is that a new one?
<pitti> (no data collected on that, so it's fairly useless)
<ogra_> pitti, it is the first time we have one in trusty
<ogra_> image 1 and 3 didnt have it
<ogra_> (2 failed to build)
<ogra_> hmm, sad, i was hoping to find an overseen g_type_init() or some such in the code, but seems that was removed in june
<pitti> can we fix whichever test runner that is to actually process .crash files?
<pitti> like that they are mostly useless
<ogra_> psivaa, ^^^ ?
<pitti> I thought we were using /usr/share/apport/whoopsie-upload-all or something similar in most test runners now
<ogra_> might be that the sdk test doesnt though
<psivaa> ogra_: ok if processing crash files is what's needed, ill take it upto doanac and plars about it
<ogra_> thanks
<doko> xnox, what is triaged in https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1015219 ?
<ubottu> Ubuntu bug 1015219 in gcc-4.7 (Ubuntu Precise) "Can't install lib64stdc++6 due to unmet dependencies" [Medium,Triaged]
<xnox> doko: a warm fuzzy feeling of the requester. Is it actually a bug that was fixed, or simply multi-arch was not properly available/enabled in 12.04?
<pitti> tyhicks, jdstrand: do you have any idea about bug 1244157 by chance? I'm pulling my hair out on that one, and it's not clear to me what changed on Oct 9 to break it
<ubottu> bug 1244157 in apparmor (Ubuntu) ""Failed name lookup - disconnected path" in dhclient D-BUS access" [Undecided,New] https://launchpad.net/bugs/1244157
<pitti> jjohansen: ^ I bisected this to https://launchpad.net/ubuntu/+source/linux/3.11.0-12.18, so something with your patches
<pitti> jibel: ^ FYI, as you were asking about the NM autopkgtest regression
<juliank> cjwatson: You wrote that bug 1132918 is a python-apt bug; but I don't see how size_to_str can return a non-unicode string in Python 3. Do you know what's happening there?
<ubottu> bug 1132918 in python-apt (Ubuntu Raring) "Ubiquity crashes after user creation" [High,Confirmed] https://launchpad.net/bugs/1132918
<cjwatson> juliank: I can't remember.  IIRC it's a string overflow or otherwise busted string data rather than non-unicode in any normal way
<cjwatson> juliank: I remember it not being at all obvious and taking a while to find
<xnox> juliank: as far as I remember one needed to use a funky locale to reproduce it, e.g. fi_FI.UTF-8 or some such.
<juliank> cjwatson: Thanks, that's all I need I think. APT uses sprintf() for printing, it should use snprintf.
<cjwatson> juliank: Oh maybe it was et_EE.UTF-8 or something
<cjwatson> I think xnox is right, there was some locale that returned non-ASCII data
<cjwatson> And apt/python-apt wasn't converting it
<cjwatson> sprintf/snprintf is probably a red herring
<juliank> cjwatson: I just wonder, because if you can decode the return value of size_to_str in Python 3 (which the changelog for ubiquity mentions), it cannot be a (unicode) 'str'. But size_to_str returns unicode here.
<juliank> If decoding means calling decode() on it
<juliank> As that method does not exist in Python 3 for str objects, only for bytes.
<cjwatson> Yes I know.  The relevant code is:
<cjwatson>             current_cps = apt_pkg.size_to_str(self.current_cps)
<cjwatson>             if isinstance(current_cps, bytes):
<cjwatson>                 current_cps = current_cps.decode()
<cjwatson> But it was clearly a workaround
 * cjwatson tries to remember how he reproduced this
<juliank> The Python object is generated by CppPyString which calls PyUnicode_FromStringAndSize(), I doubt that one returns a bytes object.
 * cjwatson resorts to grepping IRC logs
<cjwatson> juliank: At the time there was a non-breaking space in the thousands separator in at least some locales, but we may have dropped that which would make this harder to reproduce
<cjwatson> juliank: But it's also possible that code came from the period when we needed to deal with polyglot Python 2/3
<cjwatson> And in Python 2 I needed that to be reliably unicode
<cjwatson> juliank: However, the syslog in that bug postdates ubiquity switching to Python 3, so it can't be as simple as "just works in Python 3".
<cjwatson> Anyhow, the decode is irrelevant, it's after the crash site in this bug
<cjwatson> juliank: I think this bug occurs when you get non-ASCII text from the locale's numeric representation and try to feed it to PyUnicode_FromStringAndSize.
<juliank> The traceback said: File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 187, in pulse
<cjwatson> juliank: Well, I don't know if this was the original problem (it's weird that ubiquity would ever be in this locale), but here's a reproducer: http://paste.ubuntu.com/6294362/
<cjwatson> (Of course you have to have the et_EE locale generated first; note that that's a non-UTF-8 locale)
<doko> ScottK, is kgraphview unmaintained? I see you let it build with boost1.49 with your last upload
<juliank> cjwatson: OK, that makes sense then. But then it's a Python bug, as that is decoding the string.
<cjwatson> juliank: Seems more likely that there's some other function that would do the right thing
<cjwatson> I mean, Python certainly *can* decode from such encodings
<cjwatson> And PyUnicode_FromStringAndSize is *documented* as taking UTF-8-encoded bytes
<cjwatson> So it is the wrong function to call if the data might be non-UTF-8-encoded
<juliank> Seems true.
<cjwatson> I don't know the C API well enough
 * cjwatson drops a reproducer into the bug
<juliank> So, do I really have to lookup the message encoding of the locale and then use that one for decoding? There's no easy function for this available; I'd expect that to be a normal issue in Python development.
<cjwatson> I'm not sure, I'm afraid
<juliank> I don't think there's a sane way to support non-utf8 locales
<jdstrand> pitti: re bug #1244157
<ubottu> bug 1244157 in linux (Ubuntu) "[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access" [Undecided,Confirmed] https://launchpad.net/bugs/1244157
<jdstrand> pitti: are the network manager tests running in a container?
<pitti> jdstrand: no, plain VM or just plainly on my workstation
<jdstrand> that's very strange since I would expect massive bug filings if dhclient didn't work in the generally case
<jdstrand> s/generally/general/
<pitti> jdstrand: right, it doesn't happen with my "normal" NM either
<pitti> jdstrand: I'll still try to reduce the reproducer, but I asked jjohansen in case he already has an idea from that message
<jdstrand> pitti: yeah, I think we need jjohansen for this. if lxc or chroots aren't involved, then we need him
<jdstrand> pitti, jjohansen: I'm looking in https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-network-manager/1/ARCH=i386,label=adt/artifact/results/log and it looks like pbuilder (ie, a chroot) is involved
<jdstrand> pitti  (fyi jjohansen): can you update the profile to have:
<jdstrand> /usr/lib/NetworkManager/nm-dhcp-client.action flags=(attach_disconnected) { ... }
<pitti> jdstrand: no, we don't use chroots there; it just calls pbuilder-satisfydepends-classic to install the dependencies
<jdstrand> pitti (fyi jjohansen): and try again?
 * pitti sets up VM to avoid losing network
<jdstrand> pitti: where is pbuilder-satisfydepends-classic installing the dependencies if not in a chroot?
 * jdstrand is not a pbuilder expert
<pitti> jdstrand: into the currently running syste
<pitti> m
<pitti> jdstrand: it's just a helper tool to determine a set of packages from a Depends: line
<jdstrand> I see
<pitti> jdstrand: but in the reproduction recipe in comment #2 there's no chroot or pbuilder involved
<pitti> ok, I'm set up
<jdstrand> pitti: I think adding attach_disconnected is still worthwhile as a data point
<pitti> jdstrand: "sudo /etc/init.d/apparmor reload"?
<jdstrand> pitti: sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient
<pitti> jdstrand: oh, seems "reload" worked
<jdstrand> it would too, it is just more heavy-handed
<pitti> yay, so that's it
<pitti> what does that flag mean?
<jdstrand> so the paths are disconnected from a filesystem (ie, the leading '/' is missing). attach_disconnected will just put them on '/' and hopes for the best
<pitti> jdstrand: oh, I'm running the tests under an unshared file system
<jdstrand> pitti: can you update the bug that adding attach_disconnected helps as a workaround? the thing is, we shouldn't need attach_disconnected here
<pitti> jdstrand: as I'm mounting tmpfses over /run/NetworkManager and /etc/NetworkManager as to avoid disturbing/destroying files in the production system
<jdstrand> ah
<pitti> jdstrand: yes, currently doing that; I was just wondering because even setting the profile to "complain" didn't help
<ogra_> jdstrand, hmm, could it be that we borke netwporking for armhf desktop users who have to use a kernel with old apparmor ? bug 1231778
<ubottu> bug 1231778 in network-manager (Ubuntu) "wifi not working on Saucy Salamander" [Medium,Confirmed] https://launchpad.net/bugs/1231778
<jdstrand> well, attach_disconnected is exactly what you want
<pitti> jdstrand: the test could completely disable apparmor, but I'd rather test the whole thing as closely as possible
<jdstrand> pitti: I think this is a case for another sed
<pitti> jdstrand: (it'd be the first sed, but I see what you mean)
<jdstrand> pitti: oh, I thought we were doing a sed on something else as of a few weeks ago
<pitti> jdstrand: no, I fixed that properly in dbusmock
<jdstrand> ah, right
<pitti> (but that part isn't involved here; that was my first thought)
<pitti> these tests run without any mocking
<jdstrand> ogra_: no, that is different. no (relevant) apparmor denials in that bug
<ogra_> jdstrand, well, i just had someone debug it and he noticed that dns doesnt work at all with NM, while it works with /e/n/i ... seems i need to poke cyphermox then
<pitti> jdstrand: so the patches in -12.18 weren't really a regression but this is supposed to not work with an unshared fs namespace?
<pitti> jdstrand: i. e. is this "invalid"/"wontfix", or still a bug and the above is a workaround?
<jdstrand> jjohansen: fyi, seems that attach_disconnected is exactly what pitti needs-- he is mounting tmpfses over parts of the filesystem
<jdstrand> jjohansen: I'm not sure if there is another bug there, can you comment in the bug?
<pitti> jjohansen, jdstrand: not the D-BUSy parts, though; I guess it's the "unshared fs" which upsets it
<jdstrand> pitti: I'm not sure
<pitti> jdstrand: anyway, I followed up to the bug with a summary
<jdstrand> pitti: let's leave it open for now and let jjohansen comment when he gets back
<pitti> ack
<jdstrand> pitti: thanks
<pitti> jdstrand: thanks to you!
<pitti> Ran 23 tests in 221.487s
<pitti> \o/
<jdstrand> yw :)
<pitti> I'll come up with some seddery for now
<ogra_> jdstrand, there is an intresting line in dmesg of that bug though ...
<ogra_> [   59.264921] type=1400 audit(1380291018.856:28): apparmor="STATUS" info="failed to unpack profile" error=-71 pid=781 comm="apparmor_parser" name="/usr/lib/NetworkManager/nm-dhcp-client.action" offset=155
<ogra_> (and dhcp/dns is the bit not working apparently)
<pitti> wow, seems ogra_ and I stumbled over two completely different problems in the very same line of a profile :)
<ogra_> heh
<jdstrand> ogra_: hmm.. I have never seen that error befor
<ogra_> jdstrand, that device uses an android kernel without apparmor patches ... (but ubuntu config)
<ogra_> could that have any influence ?
<ogra_> (and no, this is lubuntu desktop, not touch)
<ogra_> :)
<jdstrand> ogra_: I would think that would be an influence, yes. I don't know this error condition-- that is coming from the kernel. normally the parser isn't run on profiles when apparmor is disabled/not available
<jdstrand> jjohansen: different issue> can you comment on backscroll between me and ogra_ going back 5 minutes from this message?
<ogra_> jdstrand, well, i think it is enabled (as the device copies the panda kernel config with HW specific adjustments) ... but only the version that is shipped in this kernel by default
<jdstrand> ogra_ (fyi jjohansen): ah, well that is probably explained by an old kernel with new userspace and new apparmor policy (nm-dhcp-client.action has dbus rules)
<ogra_> right, thats what i suspect
<ogra_> note that we have many (if not most) armhf users out there with such setups
<jdstrand> ogra_ (fyi, jjohansen): the parser I think should be able to handle that though since it is examining apparmor features in the running kernel though. there might be a bug there or for some reason what it needs to determine the feature set isn't present
<ogra_> the majority of our arm community uses their own kernels just with an ubuntu-core rootfs where they then install the desired -desktop package
<jdstrand> ogra_: honestly, if they are using their own kernel, it seems like they should really also be pulling back the new apparmor like the porters for touch do
<ogra_> jdstrand, 90% of these people just know how to flash their device ...
<ogra_> they always used the existing kernel binaries and an ubuntu userspace
<ogra_> (often even android binaries)
<ogra_> if we add a hard dependency on patching yoour kernel in our userspace we'll likely use that lot
<jdstrand> that seems problematic for a bunch of reasons. anhyhoo, like I said, there might be a bug there or something isn't setup right for that confiugration
 * jdstrand needs jjohansen to comment
<ogra_> s/in out/to use our/
<ogra_> jdstrand, it works fine with debian, or fedora
<ogra_> or whatever other distro they use
<ogra_> (though i guess fedora will soon cause similar issues by using systemd)
<jdstrand> yep
<cjwatson> doko: I'll take valadoc
<pitti> cjwatson: FYI, doko and I discussed valadoc
<doko> cjwatson, pitti was looking at
<jdstrand> like I said, apparmor_parser should be able to handle that aiui
<psivaa> pitti: ping
<cjwatson> "discussed" or "is going to fix"?
<cjwatson> I assume you need https://mail.gnome.org/archives/commits-list/2013-September/msg08896.html
<pitti> cjwatson: trunk builds against cgraph, but apparently too many other packages would need porting as well, so doko was going to bring back libgraph
<cjwatson> pitti: Yes, but that didn't obviously help
<doko> cjwatson, so I re-enabled libgraph again, however it looks like libcgraph and libgraph cannot co-exist in parallel anymore
<pitti> cjwatson: oh, ok
<cjwatson> pitti: We need to port everything, I think; it sucks but there it is
<pitti> so it seems we either port the five-or-so libgraph consumers or don't build cgraph?
<cjwatson> Let's just port, we already started
<pitti> at least until Debian gets the new version, so that we don't have to deviate so much
<pitti> cjwatson: ok
<psivaa> pitti: hey, we are seeing some issues with running webapps AP tests and appear to hit some dbus issues. so wondering if you'd be able to help
<cjwatson> pitti: so, OK if I cherry-pick the cgraph work from upstream?
<pitti> cjwatson: I just tried a trunk build, not a cherry-pick; but you need to disable the 0.16 bits (i. e. drop the libvala0.16 build deps), I didn't get that one to build
<cjwatson> Looks like 7b22bc146b318790552aa8ec1ece25a3a06d1316 and 0dcad4e7364c1f7c892ed0c0073a66aefa325b42
<pitti> but that's fine, we want 0.20
<pitti> psivaa: I have some three conversations and a meeting in 20 mins, after that?
<psivaa> pitti: sure, thanks :)
<pitti> psivaa: (or subscribe me to a bug or something)
<psivaa> pitti: we have not reported any bugs but i'll try and ping you after an hour
<pitti> jdstrand: added another question to the bug, perhaps you know this
<plars> pitti, psivaa, ogra_: yes, there seems to be some issue with inotify in whoopsie. I was looking at this recently and had some limited success with restarting whoopsie, then calling whoopsie-upload-all. But most of the time it seems like it will still timeout after failing for 30 minutes to see that the .crash file has uploaded
<plars> I'll look at it some more today
<ogra_> great, thanks
<pitti> plars: at least after that the crashes should have the packaging information
<jdstrand> pitti: yeah, just saw it. I don't think so
<jdstrand> pitti: but let's see what jj says-- there might be a bug and you might not need attach_disconnected
<pitti> jdstrand: I guess I could copy the whole /etc/apparmor.d into a tmpfs and move it over; but I'm not sure that would even work
<ev> plars: is inotify actually working on /var/crash?
<ogra_> ev, is inotify working omn bind mounted dirs ?
<ogra_> :)
<ev> you tell me! :-P
 * ogra_ doesnt know ... but /var/crash is a bindmount 
<pitti> oh, that woudl explain it
<pitti> if whoopsie starts first, sets the inotify, and *after* that you do the bind mount
<pitti> that would explain why restarting whoopsie makes it work
<ogra_> the bind mount happens from mountall
<pitti> as the original inotify is on an inode on the root fs
<ogra_> whoopsie surely doesnt start before mountall, does it ?
<pitti> no
<pitti> ok, would have been a nice explanation
<pitti> ogra_: so that's not done by writable-files?
<ogra_> writable-files are processed in the initrd
<ogra_> to create an fstab
<ogra_> eth actual mounting is done by mountall processing the fstab
<plars> ev: it would appear not since it needs to be restarted, but sometimes even that doesn't seem to be enough
<ev> hmm
<doko> cjwatson, pitti: looks like my graphviz upload re-enabling libgraph was not a good idea. you can't have these in parallel anymore. and configuring graphviz --without-cgraph doesn't seem to work either
<cjwatson> doko: Can we just go back to 0ubuntu2 and port everything?
<cjwatson> Fedora did that
<doko> yes, we have to
<xnox> stgraber: can we fix this: http://blog.bofh.it/debian/id_413
<xnox> ?
<seb128> xnox, stgraber, tedg: with the current upstart jobs, is it possible that unity-panel-service is started before dbus's session job?
<seb128> if so can we make it just start when the session bus is ready
<tedg> seb128, I don't think so.
 * tedg double checks
<seb128> tedg, you don't think that it's possible... or happening or...?
<tedg> seb128, No it's starting with gnome-session, which is started after dbus.
<seb128> tedg, we are getting indicators that hit g_error() code on init because there is no session bus, that's weird
<tedg> seb128, I don't think the restart bug is fixed in distro yet though.
 * seb128 wonders how that's possible if thing are correctly ordered
<seb128> tedg, what restart bug?
<tedg> seb128, When upstart restarts it doesn't save the environment variables, so then tasks can't find dbus.
<tedg> seb128, Looks like 0ubuntu8 is in trusty, but not saucy.
<seb128> tedg, "upstart restarts"? is that re-exec on update?
<tedg> seb128, We put a recoverable error in HUD to detect it: https://errors.ubuntu.com/bucket/?id=DBusSessionAddressNotSet
<charles> we're seeing this can't-get-bus-so-let's-crash happen in multiple indicators, and there are similar crashes that go back years in LP
<xnox> seb128: it shouldn't, but it can be sometimes.
<seb128> xnox, tedg: is somebody working on getting that upstart fix SRUed?
<xnox> seb128: re-exec on update upstart itself, or any it's dependencies upgraded. you can reproduce it with $ telinit u
<xnox> seb128: i dont' think that was in trusty yet.
<tedg> seb128, I assume, but I haven't verified.
<tedg> xnox, Oh, is that not in ubuntu8?
<xnox> seb128: tedg: there is merge proposal to fix it, but that's not merged in trunk yet.
<xnox> tedg: read changelog =) https://launchpad.net/ubuntu/+source/upstart/1.10-0ubuntu8
<xnox> tedg: there is no mentioning of the saving/restoring environment =))))
<tedg> xnox, Ah, I figured "super important" :-)
<xnox> (serialising, deserialising and preserving evn acroos restart)
<tedg> seb128, So apparently not fixed yet :-/
<xnox> tedg: ph, desktop stuff =) the host stayed up.
<xnox> tedg: but yeah, it's important and jodh is working on fixing it.
<seb128> tedg, xnox: who is working on it? jodh?
<seb128> xnox, ok, thanks
<xnox> seb128: tedg https://code.launchpad.net/~jamesodhunt/upstart/bug-1238078/+merge/190723
<jodh> tedg: I've fixed the issue, but we have a bit of a review backlog atm :)
 * tedg can click "approve", send me links!  ;-)
<cjohnston> cjwatson: when you get a chance, could you please ack my email to ubuntu-devel ref a UDS track name change?
<jodh> tedg: sorry, upstart devs only :). FWIW, that is the top priority branch to be merged.
<cjwatson> cjohnston: done
<cjohnston> thanks :-)
<cjwatson> sigh, it's unfortunate that trusty-proposed is a partial suite.  I'm either going to have to make librdf-trine-perl and libtest-rdf-perl uninstallable for a publisher cycle when the rest of the perl transition is done, or else force it in a complex way
<cjwatson> hm, maybe a faux package would do the job
<doko> ouch, wth did I package yapgcb for?
<stgraber> xnox: did you try it on Ubuntu?
<stgraber> xnox: because it won't work ;)
<xnox> stgraber: sounds good ;-) let me try it and see what happens.
<stgraber> xnox: apparmor will prevent you from re-mounting sysfs and will prevent any write under /sys
<doko> cjwatson, would you mind removing yapgvb?
<cjwatson> doko: can do, just give me a reason I can type into remove-package
<doko> based on libgraph, which doesn't exist anymore. last upstream 2009
<cjwatson> doko: done
<doko> two left kgraphview and ggobi
<cjwatson> I'm chasing the other things p-m is complaining about
<saiarcot895> When backporting a package, if the package depends on a backported package,....well, is this allowed?
<xnox> saiarcot895: yes.
<stgraber> cjwatson: can you rescore: https://launchpad.net/ubuntu/+source/ggobi/2.1.10-4ubuntu1/+build/5157602
<cjwatson> stgraber: done
<stgraber> it looks like it'll also need some of that autoconf-dev magic to build on arm64
<cjwatson> sigh, and massif-visualizer is one of the packages that's uncopyable due to an LP bug
<rbasak> pitti: I'll check
<cjwatson> Hm, now proposed-migration seems to have decided that graphviz doesn't need to go in with perl, wtf
<cjwatson> I guess I could decide not to care about that for now
<cjwatson> Oh, no it hasn't, it's just that libgv-perl is listed as broken now
<cjwatson> That'd be the connecting package
<stgraber> maybe the link between graphviz and perl was one of those packages that got removed/demoted
<jibel> rbasak, trustyÂ§20131023 is on cloud-images.u.c but there is no current/ directory and image is not listed in daily simplestreams json file
<jibel> trusty/20131023
<cjwatson> stgraber: No, it's just that on the last run graphviz was out of date so it didn't consider it at the output stage
<cjwatson> It'll reappear next run, I expect
<rbasak> jibel: I'll check with utlemming when he gets in
<jibel> rbasak, thanks! Also can you check with him to bring jenkins node ec2-tester back to life?
<rbasak> Will do
<mardy> thomi: hi! I'm having some trouble with autopilot, which seems has to do with the D-Bus timeout
<mardy> thomi: how long is it by default? is it possible to extend it (maybe with some env variable)?
<cjwatson> ok, working around the massif-visualizer problem
<borg_> Hi, the python-qwt5-qt4 package in the current saucy repository is broken. It results in an immediate segfault if used.
<borg_> I am pretty sure that there was just some kind of fault while the package was build.
<borg_> i rebuild the package from source and it works
<borg_> https://bugs.launchpad.net/ubuntu/+source/pyqwt5/+bug/1243102 (see last comment)
<ubottu> Ubuntu bug 1243102 in pyqwt5 (Ubuntu) "python-qwt5-qt4 segfaults immediately in saucy" [Undecided,New]
<borg_> who can i contact to rebuild and reupload the package?
<xnox> borg_: assigned to ScottK, he is the last one to touch the package, and should now if that is the case and how to deal with it.
<borg_> thx
<infinity> shadeslayer: Can you re-do that grub2-signed SRU without the trusty changelog entry in there?
<shadeslayer> infinity: sure
<shadeslayer> Riddell: ^^ still around to upload that for me?
<Riddell> infinity: shadeslayer: doing
<shadeslayer> cool
<infinity> Riddell: Also, please don't set Fix Committed on SRU bugs when you upload something.
<infinity> Riddell: In Progress is fine, but we use Fix Committed to mean we've actually accepted it to -proposed.
<Riddell> infinity: I know sorry I think I got confused on which was in -proposed
<rbasak> pitti, jibel: utlemming is working on it and expects to have something by EOD. Apparently we're not used to having customers this early in the cycle :)
<slangasek> Mirv: so in the authoritative configuration, the autopilot tests are being executed via phablet-test-run, connected how? adb?
<seb128> bdmurray, there? I'm not sure what to do with software-properties to re-inject the version you didn't commit
<infinity> ricotz: Known bug in 1.0.10, fixed in 1.0.11.  On the other hand, 1.0.10 is only in proposed, so the right answer here is in the form of a question: "Why are you running proposed?"
<seb128> I wonder if I should uncommit my update, push --overwrite, commit yours and redo mine on top of it
<seb128> I don't like much uncommit/overwrite though
<infinity> seb128: Just fix the changelog and commit?  Unless you're concerned about tags being sane too.
<seb128> infinity, I would prefer tags to match uploads yes
<infinity> If I were you, I'd just suffer with his upload being untagged.  But your VCS, your call. :P
 * seb128 shakes fist at people not using the vcs
<slangasek> seb128: branch from last common revision; commit bdmurray's changes on new branch and tag; merge that branch into your trunk
<infinity> seb128: Or, I can just accept your rejected upload, and then your tags will match, and his will just appear to have never happened.
<slangasek> oh, what you have committed in the VCS doesn't match the archive?
<seb128> slangasek, well, trunk has a tag for a version that got rejected now
<seb128> so that tag is buggy as well
<seb128> infinity, I start thinking that's easier
<slangasek> right
<infinity> seb128: Yeah, I'll just do that, and you can pretend none of this ever happened.
<seb128> slangasek, it matches my upload to saucy-proposed that Daviey rejected because there was one of bdmurray already in there (which was lower number/not in the vcs)
<seb128> infinity, thanks
<slangasek> gotcha
<seb128> infinity, slangasek: thanks
<infinity> seb128: Done.
<seb128> infinity, thanks
<bdmurray> seb128: sorry about that
<seb128> bdmurray, no worry
<robru> ogra_, ping? can I get you to seed webbrowser-app for trusty? https://code.launchpad.net/~robru/ubuntu-seeds/ubuntu.trusty/+merge/192564
<xnox> robru: have the extra dependencies that that pulls in been dropped?
<xnox> robru: specifically those that get pulled in by qtmultimedia?
<robru> xnox, i thought so? did mirv not get his updated qtmultimedia in?
<robru> xnox, if this isn't in, can somebody sponsor it? https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtmultimedia-opensource-src_5.0.2
<xnox> robru: no  it hasn't yet.
<robru> xnox, well can you sponsor/upload it please? it's ready to go
<xnox> robru: please wait until that branch is actually uploaded, built in -proposed and migrated to -release. Only then the seed change can go it.
<xnox> s/it/in/
<robru> xnox, so you're not going to upload it then? i don't have upload rights
<xnox> robru: Mirv didn't request that branch to be properly sponsored. Therefore it didn't appear on any sponsorship queues/reports and none of the sponsors patch pilots looked at it.
<xnox> robru: so it hasn't landed yet
<xnox> robru: i openend the task agaisnt qtmultimedia, linked the branched to the bug, made merge-proposal into the default packaging branch, subscribed ubuntu sponsors on the bug report.
<xnox> robru: soon it should appear on http://reqorts.qa.ubuntu.com/reports/sponsoring/
<robru> xnox, thanks
<xnox> robru: and then one of the sponsors will look into it in due course. I am extremely busy at the moment, and can't look into it.
<xnox> robru: once qtmultimedia task is "Fix released" then webapps seed proposal can be made. And you should request "ubuntu-core-dev" to review it, then it will also end up on the above sponsorship report to be merged/sponsored.
<Noskcaj> mdeslaur,
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/tiff/tiff/+merge/192569
<mdeslaur> Noskcaj: thanks, I'll take a look at it tomorrow
<Noskcaj> :)
<Noskcaj> Has anyone looked at bug 1234612 ?
<ubottu> bug 1234612 in memtest86+ (Ubuntu) "Please update memtest86+ to the latest 5.0.x release - memtest86 in Ubuntu 13.10 is 2 years old (v4.2.0)!" [Undecided,Confirmed] https://launchpad.net/bugs/1234612
<cjwatson> Noskcaj: level of interest in touching that at all without the Debian maintainer taking it very low indeed
<Noskcaj> cjwatson, not suprising. I've emailed the debian maintainer and will let everyone know if i get a reply
 * cjwatson leaves a bug comment to that effect
<cjwatson> Noskcaj: why e-mail directly, rather than filing a Debian bug?
<cjwatson> no obvious need for privacy here
<Noskcaj> will do now
<seb128> infinity, can you get the gnome-settings-daemon saucy SRU that is in the queue in? it fixes those keyboard problems a bit harder than the version in proposed is
<infinity> seb128: With extra gusto? :P
<infinity> ERROR: Queue has more than one upload of this source, please handle manually
 * infinity sighs and goes to look.
<seb128> infinity, both are from me, you can reject the older one
<seb128> the new one includes the 3 changelog entries
<sarnold> https://launchpad.net/bugs/1243969  has me confused how to proceed; flightgear needs an update. the reporter who provided a debdiff claims that archive flightgear can't rebuild against archive simgear because of a change in simgear made _after_ the flightgear package was built. flightgear now FTBFS as a result of the change in simgear.
<ubottu> Ubuntu bug 1243969 in simgear (Ubuntu) "buffer overrun through UDP input" [Undecided,Confirmed]
<sarnold> what's the next steps? get someone else to fix the ftbfs in an sru so that the security fix would then be small? or try to fix the ftbfs in the security update directly?
<infinity> sarnold: Fix the FTBFS in the security update, it doesn't make sense to do two uploads just to keep them isolated.
<sarnold> (does anyone know flightgear well enough to just say "add -lpthread to CFLAGS" or "do not under any circumstance try flightgear with threading"?)
<infinity> sarnold: Do you have a failed build log?
<sarnold> infinity: no, not yet
 * infinity gives it a whirl.
 * infinity gives is a very slow whirl...
<infinity> That's a lot of build-deps.
#ubuntu-devel 2013-10-25
<infinity> sarnold: Waiting for this test build to finish, but looks like it's a 1-line patch for you, and you can just include that in your security release.
<sarnold> infinity: yay \o/ :) thanks
<infinity> sarnold: http://paste.ubuntu.com/6298101/ <-- Test-built, seems to DTRT.
<sarnold> infinity: thanks!
<ScottK> xnox: Feel free to ask me if I'm willing to look at a bug, but assignment rights require a contract.
<ScottK> stgraber: Would you please have a look at the upstartification proposed in https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1244036 ?
<ubottu> Ubuntu bug 1244036 in quassel (Ubuntu) "Quasselcore should use an Upstart script instead of a sysv initscript" [Undecided,New]
<stgraber> ScottK: looks to me like he wants "start on filesystem and static-network-up" instead, but the start on condition he's using isn' wrong either. Just because I'm picky, the respawn stanza is usually put before the script section so it's easier to spot.
<stgraber> besides that, it should all work fine assuming quasselcore doesn't fork/daemonize
<stgraber> oh and hardcoding /usr/bin is usually not considered a good thing
<ScottK> So just excec quasselcore?
<ScottK> exec even
<ScottK> stgraber: ^^^
<stgraber> yep
<ScottK> Thanks.
<Mirv> slangasek: yes phablet-test-run works through adb
<pitti> rbasak: thanks (this early> rolling release!! *cough*)
<pitti> Good morning
<Mirv> robru: xnox: I didn't really push on getting the qtmultimedia in. as I was asked I provided some information and prepared the branch from my side, assuming someone working on the bug is doing the pushes. otherwise I'd have pinged a friendly core-dev about the branch or made the lp:ubuntu/* MP. doing that MP now as robru requested.
<robru> Mirv, yes, sorry. I don't have upload rights so I can't sponsor it or anything. but I really need that in ASAP please.
<robru> for trusty
<Mirv> yep the MP seems the best way to go, and I can ping also didrocks who can sponsor from the packaging branch directly
<robru> ok, great, thanks Mirv
<pitti> rbasak: so, we are producing cloud images, just no /current symlink
<Mirv> np
<pitti> rbasak: but "prepare-testbed -b 20131024.3 amd64" FTW :)
<mati75> hello
<mati75> I have question about upload patched packages to ubuntu repository
<pitti> mati75: (just ask your question)
<ricotz> doko__, hi, graphviz 2.34.0-0ubuntu4 missed to handle the soname bump "libgvc5: /usr/lib/libgvc.so.6"
<ricotz> pitti, hi
<pitti> hey ricotz
<ricotz> i am curious aren't there checks for the proposed pocket to catch something like that ^
<slangasek> normally, it's expected that such changes cause the package to fail to build entirely.
<ricotz> if there is no symbols file it wont fail
<slangasek> not true; if the library package is done sanely, it will fail to build when it tries to install files that aren't there
<ricotz> slangasek, right, but normally the soname isnt mentioned in the install file afaik
<ricotz> but yeah, that of course would catch it
<slangasek> if you have neither a symbols file nor a version-checking glob in your install rule, your library packaging is not sane
<ricotz> alright ;)
<mati75> my debian package was copied to ubuntu trusty, but to fine working in ubuntu needs patch
<mati75> now I add to ppa: https://launchpadlibrarian.net/154951693/spacefm_0.9.0-1ubuntu1_source.changes
<pitti> mati75: ah, thanks! happy to sponsor, do you have the link to the PPA?
<mati75> https://launchpad.net/~mati75/+archive/spacefm/+packages
<pitti> mati75: oh, what doesn't work with the global menu? (woudl be nice to report this as a bug to the unity guys so that it can be fixed)
<mati75> pitti: yes, here is upsteam bug report: https://github.com/IgnorantGuru/spacefm/issues/49
<mati75> pitti: ok, I try report to unity guys
<pitti> mati75: ah; probably not an upstream bug, but one in the unity menu; I'll add that link to the changelog, ok?
<pitti> mati75: uploaded with that
<mati75> pitti: ok
<borg_> Hi, i still have this problem with python-qwt5-qt4: https://bugs.launchpad.net/ubuntu/+source/pyqwt5/+bug/1243102
<ubottu> Ubuntu bug 1243102 in pyqwt5 (Ubuntu Trusty) "python-qwt5-qt4 segfaults immediately in saucy" [Undecided,New]
<borg_> it was assigned to Scott Kittermann but he unasigned it
<borg_> how do i get this package rebuild and reuploaded?
<borg_> the source of the package is ok, but the build package is broken (no idea what happend during the build process)
<doko> apw, aarch64 ping
<doko> chrisccoulson, hi, could you have a look at a libticaples merge this cycle?
<doko> ricotz, feel free to fix. the graphviz packaging is "interesting" ....
<xnox> =)
<pitti> I guess it's too late to hold back graphviz in -proposed for that..
<cjwatson> given it's migrated, yes
<brainwash> can a package maintainer or dev take a look at bug 1183580 please? the actual package maintainer appears to be inactive or just ignores this issue
<ubottu> bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580
<darkxst> cjwatson, I hear from upstream, that jenkins in running the glib installed tests, can we get the same for gjs?
<cjwatson> darkxst: that's up to the gjs packaging I expect
<Laney> It does that because I packaged the tests and made an autopkgtest for them
<Laney> so do that
<darkxst> Laney, ok will do, but how do I make an autopkgtest?
<cjwatson> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD
<Laney> You can probably copy debian/tests/* from glib2.0
<cjwatson> (linked from http://dep.debian.net/deps/dep8/)
<darkxst> Laney, cjwatson ok cool, I will work it out ;)
<Laney> darkxst: I think there's a bug that gnome-desktop-testing-runner always returns exit code 0 though
<Laney> so the tests actually always pass *cough*
<Laney> for example https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-glib-networking/9/ARCH=amd64,label=adt/console should have failed
<darkxst> Laney, then thats not a test !
<Laney> yeah the runner needs fixing
<darkxst> Laney, ok, and I need sleep! big weekend of MTB'ing ahead
<Laney> darkxst: maybe fixed in trunk actually, /me checks that
<Laney> have fun mtbing
<Laney> no, not fixed
<darkxst> will do! night!
<seb128> ev, is errors.ubuntu.com having issues? it doesn't seem to be replying, not sure if that's my connection
<seb128> well it's replying but failing to load reports
<pitti> seb128: timing out here, too, I don't even see the front page
<seb128> pitti, I've pinged #is about it, lamont said he's going to have a look
<seb128> pitti, hey, wie gehts? almost w.e for you?
<lamont> believed to be a known issue
<pitti> seb128: by and large, yes; just waiting for another ofono-phonesim fix to get published, and then re-re-re-running my messaging-app tests and hoping for the best :)
<seb128> pitti, ;-)
<pitti> slangasek: WDYT about a blueprint how to automatically do TRIMming on SSDs? high time for 14.04 LTS IMHO, and also quite embarrassing to have to explain that to every Ubuntu user around me..
<pitti> slangasek: (there are two well-known approaches, just needs some discussion what is the better default)
<stgraber> pitti: are you doing more than adding discard to any SSD+fs that supports it and doing an ATA wipe every once in a while?
<slangasek> pitti: sounds like a good topic
<pitti> stgraber: I create a cronjob to call fstrim every week
<pitti> stgraber: that can be generalized to iterate over mount points and checking if it's an SSD with TRIM capabilities, etc
<pitti> stgraber: I think that's better than "discard", but that's a subject for discussion I think
<pitti> stgraber: either way, whether discard or cron, we need to do it
<pitti> drives get excruciatingly slow (I got 1.5 MB/s!) after half a year or so without out
<pitti> s/out/it/
<stgraber> pitti: agreed. All my systems run on SSD here and have all been running with discard, haven't seen any obvious side effects and I have some with pretty busy SSDs running for 2-3 years now. But yeah, a vUDS discussion would be a very good thing as what we do by default is clearly wrong ;)
<pitti> stgraber, slangasek: ack, I'll register a BP Monday
<stgraber> pitti: thanks, can you subscribe me to it?
<pitti> stgraber: sure
<stgraber> awesome, thanks
<pitti> it's primarily a "pick your pain" decision anyway, slow delete vs. a rather unpredictable I/O load every week (or whatever frequency we decide)
<cjohnston> lool: did you get my email about the milestones for the trusty cycle?
<lamont> seb128, pitti: shoujld be back
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<roadmr> stgraber: hello, I see the checkbox-0.14.10 package made it into proposed, did the diff turn out to be ok after all?
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Noskcaj> rbasak, PING
<Noskcaj> rbasak, Do you plan to merge pysvn any time soon?
<brainwash> pitti: systemd-shim.c, line 118: the dbus signal does not get emitted occasionally after resuming from suspend. what could be the reason?
<brainwash> pitti: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/systemd-shim/saucy/view/head:/src/systemd-shim.c#L118
<rbasak> Noskcaj: not right now; do you want to take it?
<Noskcaj> rbasak, Sure
<rbasak> Noskcaj: thanks!
<infinity> Looks like at least one of the patches can probably be dropped.
<bdmurray> slangasek: how does trusty get added to extras.ubuntu.com?  bug 1244050
<ubottu> bug 1244050 in ubuntu-release-upgrader (Ubuntu) "upgrade to trusty fails because of failure to fetch from extras.ubuntu.com" [Undecided,New] https://launchpad.net/bugs/1244050
<infinity> Possibly both.
<infinity> Noskcaj / rbasak: Looks like both our patches made it upstream, I'll just sync pysvn.
<Noskcaj> infinity, ok
<rbasak> infinity: thanks!
<Noskcaj> It's a bit worrying that the actual maintainer of pysvn hasn't done much in the last 2 years
<slangasek> stgraber: extras.ubuntu.com> ^^ ?
<slangasek> bdmurray: I guess it's in some way an ARB function, but I'm not sure if the ARB is still a going concern
<stgraber> slangasek: can't do anything about it, no longer on the TB
<slangasek> stgraber: so it's a TB-controlled thing?
<infinity> What TB?
<Laney> Isn't it a mirrored PPA?
<stgraber> slangasek: you need someone on the TB or on the ARB to copy a package between an existing series and trusty in the PPA, wait for it to publish, then remove it
<stgraber> that way trusty is created on ppa.launchpad.net
<stgraber> and a bit later, that gets mirrored over to extras.u.c
<infinity> Which PPA is this?
<slangasek> and the ARB doesn't exist anymore either?
<slangasek> bdmurray: so... I guess you can assign it to the technical board :)
<infinity> I'm sure we can make this happen without a TB.
<infinity> stgraber: Which PPA?
<stgraber> infinity: https://launchpad.net/~app-review-board/+archive/ppa
<Laney> the ARB has members
<infinity> Nothing published there for saucy, either.  Shiny.  Though I assume the copy/delete trick happened.
<stgraber> yep, I did it back in saucy
<stgraber> http://ppa.launchpad.net/app-review-board/ppa/ubuntu/dists/
<stgraber> I believe the latest extras.u.c upload was in quantal
<infinity> Curious that no one's tried to get it to publish for all arches.
<infinity> Anyhow, if you can't find an ARB person to do it, we can get a duckie to.
<bdmurray> okay thanks
<stgraber> highvoltage, ajmitch: around?
<infinity> ajmitch: You arou... What he said?
<stgraber> if we had governance bodies who could make that decision, it'd be nice to get rid of extras.u.c with 14.04 since this clearly isn't used
<slangasek> stgraber, bdmurray: if extras.u.c should go away for 14.04 anyway, then that means we should really quirk it in u-r-u
<CajunTechie> Hey guys, off-topic I know but how do I get in touch with the folks at developer.ubuntu.com?
<stgraber> slangasek: it'd have to be discussed with the CC and TB, but since nothing was published in the past two cycles, it'd seem reasonable to consider this a failure and move on
<stgraber> in which case we'll indeed need some code to get it out of any system that used to have it enabled
<sarnold> CajunTechie: this is probably a reasonable starting point: https://bugs.launchpad.net/ubuntu-website-content
<CajunTechie> Sarnold: Nope. Not a mention of it on that site. Can nobody submit apps through developer.ubuntu.com right now?
<sarnold> CajunTechie: let's take a quick step back :) what are you trying to accomplish? :)
<CajunTechie> Sarnold: I'm trying to submit a new application. It worked last night for the original submission. Then I needed to update and it gives me a 400 error
<sarnold> CajunTechie: aha! thanks :) try #ubuntu-app-devel  ?
<CajunTechie> Thanks! Didn't know about that one. You're a life-saver Sarnold :-)
<sarnold> CajunTechie: happy to help, I hope you can get the problem sorted out quickly! :)
<Noskcaj> mdeslaur, Can you look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/libxrandr/libxrandr ? It builds, but the lintian warning about changes to the diff makes me unsure i did this right
<mdeslaur> Noskcaj: sure, when I get a minute
<ev> bdmurray: thanks for landing the t-series update to the retracer config
<bdmurray> ev: no problem, I also added T to errors
<bdmurray> ev: I haven't submitted an RT for the update though
<ev> bdmurray: we're literally working on the stagingstack retracers deployment now, so it won't be too long until we have proper cloudy retracers set up
<slangasek> chiluk: hi, I've just assigned bug #1242746 to you... it appears there's a regression reported in the procps SRU
<ubottu> bug 1242746 in procps (Ubuntu) "SIGSEGV when file2str reads zero bytes" [Medium,Triaged] https://launchpad.net/bugs/1242746
<mdeslaur> Noskcaj: looked good, uploaded, thanks!
#ubuntu-devel 2013-10-26
<ScottK> slangasek: re e.u.c: JDFI.  If anyone complains about it going away,  send them to the TB. The TB exists (or doesn't) to resolve technical disputes, not to design the OS.
<slangasek> ScottK: yes, I wasn't proposing to send this to the TB, that was stgraber :)
<ScottK> Ah. OK.
<slangasek> I only said to assign the bug to the TB to open e.u.c for trusty... if it's going away, we can just make it go away in the code
<ScottK> Right JFDI getting rid of it then.
<stgraber> ScottK: changing the various packages to stop putting extras.u.c in the distro is something that can be done at any point without TB approval, that's fine. The TB should still be the one making the decision to kill the delegation to the ARB, kill the team and update all the exceptions about extra repositories that were designed for the ARB.
<stgraber> so yeah, killing it from the distro can easily be done without a TB, killing it for good, will need a bit more paperwork and discussions, though that can be done later and shouldn't be a big deal anyway
<ScottK> Sooner the better.
<stgraber> agreed
<ScottK> So JFDI the distro bits and the rest can be cleaned up later.  I think any TB decision would be a formality at this point.
<highvoltage> hey stgraber, I haven't been on the ARB for a while
<jtaylor> does aarch64 in ubuntu have neon?
<jtaylor> I'm updating fftw, and wondering if I should preemptively enable its neon support on aarch64
<JanC> are there (expected to be) any Aarch64 processors that have no support for neon?
<xnox> there is neon for arm64 and it's been extended, over v7 offering. No idea if it's optional or mandatory.
<jtaylor> that shouldn't matter it does runtime detection
<jtaylor> so the compiler will accept the flagÃ
<jtaylor> the DEB_HOST_ARCH is arm64?
<stgraber> highvoltage: you're still in the team apparently, which is all I care about to get the archive fixed ;)
<infinity> xnox: neon is mandatory for aarch64.
<xnox> infinity: ah, cool.
<xnox> highvoltage: you are our south african back door! \o/
<jtaylor> the DEB_HOST_ARCH is arm64?
<highvoltage> stgraber: heh, ok
<jtaylor> seems to be, at least thats used in xorg
<stgraber> highvoltage: can you go to https://launchpad.net/~app-review-board/+archive/ppa/+copy-packages
<stgraber> highvoltage: then copy lightread from quantal to saucy (copy including binaries, no rebuild)
<stgraber> highvoltage: s/saucy/trusty/ sorry
<stgraber> highvoltage: once it's fully published in trusty, removed it from the archive at https://launchpad.net/~app-review-board/+archive/ppa/+delete-packages
<stgraber> highvoltage: (that's all so we get the trusty series initialized and can get the release upgrader to work again)
<infinity> cjwatson: Okay, you can stop with the transitions now.  I think you've firmly established ownership of the activity donut.
<infinity> xnox: You too, young man. :P
<xnox> infinity: direct SQL queries on the database do not count ;-)
<brainwash> can some dev or package maintainer take a look at bug 1183580 please? the debian library seems to work fine and would need to be synced
<ubottu> bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580
<brainwash> it's has been broken for months now and I feel like something needs to happen
<xnox> brainwash: librcc source package is in sync with debian, and what is in 13.10 and Trusty is same source as in debian.
<xnox> brainwash: to it's an ubuntu specific problem: e.g. when/how it was compiled, or our toolchain, or one of the reverse dependencies, etc.
<infinity> If the Debian binary works and ours doesn't, it may come down to toolchain differences, perhaps some flag needs setting to make it behave.
<brainwash> the actual package maintainer seems to be inactive, so any chance for a fixed package?
 * infinity can look at it when he gets home tonight, if xnox doesn't beat him to it.
<brainwash> thanks, I really hope it will get fixed in saucy :)
<xnox> brainwash: define "actual package maintainer"? =) ubuntu packages are collectively maintained, and debian maintainer doesn't have to look into ubuntu specific bugs.
<slangasek> fixing it in saucy requires an SRU; syncing the version from Debian is unlikely to be a valid SRU target
<xnox> slangasek: especially when saucy is in-sync with current sid ;-)
<brainwash> https://launchpad.net/ubuntu/+source/librcc
<slangasek> right, or even syncing the new upstream version from $wherever
<brainwash> does mention the name of the maintainer
<infinity> Well, if building the new upstream on Ubuntu works, there's probably a cherry-pick one can make from $upstream_vcs.
<infinity> If no one's done anything about this in the next ~8h, I'll poke it with a large stick when I get back from shenanigans. :P
<slangasek> Shenanigan's? https://plus.google.com/107394684970924577932/about
<highvoltage> stgraber: ok, copying lightread from quantal to trusty...
<highvoltage> "Requested sync of 1 package to Application Review Board PPA.
<xnox> Are debug symbols available for ppa:gnome3-team/gnome3 ?
<highvoltage> Please allow some time for this to be processed."
<highvoltage> stgraber: so what should I remove once it's fully published? lightread for trusty of for quantal or all of it?
<stgraber> highvoltage: the one in trusty
<stgraber> highvoltage: we just want LP to generate the pocket on ppa.launchpad.net but don't actually want anything in it at the end
<highvoltage> ah I see
<stgraber> highvoltage: I guess publishing should be done in ~10min, then you can remove it and we'll be good in another ~10min
<highvoltage> stgraber: ok, will check on the hour
<highvoltage> it's published, removin...
<stgraber> highvoltage: thanks
<highvoltage> hope it worked :)
<Noskcaj> Can someone look at all our ogmrip packages? many of them should either be removed or synced from deb-multimedia
#ubuntu-devel 2013-10-27
 * xnox is confused about Qt4 on ubuntu desktop cd....
<seb128> xnox, ubuntuone-qt-control-panel?
<seb128> xnox, ubuntuone-control-panel-qt rather
<xnox> seb128: yeah, and checkbox-qt & appmenu-qt.
<xnox> seb128: found bug #1130782
<ubottu> bug 1130782 in ubuntuone-control-panel (Ubuntu) "Port to Qt5" [Medium,Confirmed] https://launchpad.net/bugs/1130782
<xnox> seb128: i thought we are all about qt5 these days....
<seb128> xnox, we are, porting require resources though and the priority atm is not on porting existing code...
<xnox> seb128: true.
<cjwatson> infinity: haha.  anyone else is welcome to do the necessary :)
<rly> I compiled a custom kernel by following https://wiki.ubuntu.com/KernelTeam/GitKernelBuild -- Kernel Build and Installation --. After the sudo reboot action, there is no grub entry for the newly built kernel. Why is this the case?
<doko> considering to just throw away the debian changes in opus ...
<doko> hmm, better not, ron lee package ...
<ekarlso-> has apt-add-repository been removed in saucy?
<ekarlso-> I installed python-software-properties but it doesn't seem to be provieded ther
<brainwash> ekarlso-: software-properties-common provides apt-add-repository
<hyperair> gilir: ping
<hyperair> er nevermind, i'll poke you in #gtkpod instead
<brainwash> pitti: something has to be broken, because many people are affected by bug 1184262
<ubottu> bug 1184262 in network-manager (Ubuntu) "[logind] stuck in PrepareForSleep, causing network and other services to not resume" [High,Confirmed] https://launchpad.net/bugs/1184262
<brainwash> apparently only normal users are affected, no dev or someone with the needed knowledge to debug it :/
<ekarlso-> what can be wrong when apt-* bash completion doesn't work ?
<ekarlso-> I just re-installed bash-completion as well
<ekarlso-> nvm, had the wrong .bash* file
<ekarlso-> :)
#ubuntu-devel 2014-10-20
<TheClitCommander> rww, whats up
<TheClitCommander> rww, hi
<pitti> Good morning
<pitti> wgrant: would you be able to kick off a full utopic langpack export now, for the final release? (full export requested in LP already)
<pitti> wgrant: wednesday will be too old
<pitti> wgrant: sorry for missing that, all the traveling since Friday made me forget
<pitti> infinity, stgraber ^ FTR (otherwise I'll invent something)
<wgrant> pitti: Sure, let me see.
<pitti> infinity, jdstrand: bug 1382524 should be almost a no-brainer (splitting out existing code to a new package), and it's one of the release blockers; do you have a minute to review that MIR?
<ubottu> bug 1382524 in autodep8 (Ubuntu) "[MIR] autodep8" [Undecided,New] https://launchpad.net/bugs/1382524
<roaksoax> win 13
<infinity> pitti: Lemme look.
<infinity> pitti: No-brainer indeed.  Approving and promoting.
<pitti> infinity: ack, thanks
<cjwatson> rbasak: maas-cluster-controller is uninstallable on current server powerpc images and making my daily-checks output sad.  Does it need something like https://code.launchpad.net/~racb/maas/arm-syslinux again?
<cjwatson> well except that there's no syslinux-common on anything other than amd64/i386 nowadays
 * rbasak looks
<cjwatson> mvo: has anyone brought https://launchpad.net/bugs/1347834 to your attention yet?
<ubottu> Ubuntu bug 1347834 in ubuntu-release-upgrader (Ubuntu) "UnboundLocalError: local variable 'e' referenced before assignment in doUpdate, line 924" [Undecided,Confirmed]
<mvo> cjwatson: no, sorry, I have a look right now
<cjwatson> mvo: ta
<rbasak>   * For the time being, Marking all packages as amd64 and i386 only
<rbasak>     instead of any.
<rbasak> syslinux (3:6.03~pre18+dfsg-1)
<rbasak> Some multiarch magic might be needed here.
<lutostag> rbasak: I think we need syslinux for maas server side specifically -- ie running maas-cluster on arm64 or the like
<lutostag> rbasak: so if you need some help... :)
<Wizard> Hi
<rbasak> lutostag: right. A MAAS server installed on arm64 should still be able to manage amd64 nodes, for example.
<rbasak> So it should be able to get chain.c32 and the other pieces it needs installed from syslinux packaging.
<rbasak> It seems pretty late to be making drastic changes to syslinux packaging though.
<rbasak> lutostag: do we have any CI on this use case? Or do we not actually care about it?
<lutostag> rbasak: I dont think we do, it seems like something we do one-offs for due to lack of machines
<rbasak> lutostag: do you know how much we care about this problem?
<lutostag> rbasak: not sure how much of an impact it has...
<rbasak> lutostag: AIUI, it means it's impossible for a non-Intel arch machine to be a cluster controller right now.
<rbasak> lutostag: if we drop the dependency for non-Intel architectures, then that would mean that MAAS running on non-Intel will not be able to bootstrap Intel nodes.
<lutostag> roaksoax: ^^ moving syslinux from all -> x86,amd64 -- how important is it?
<cjwatson> lutostag: uninstallable packages on our released images is generally a sadness-making thing, aside from anything else
<roaksoax> lutostag: huh?
<cjwatson> bdrung,tumbleweed: want to check/upload the change I just committed to collab-maint/distro-info-data, following http://www.markshuttleworth.com/archives/1425 ?
<lutostag> roaksoax: "rbasak> lutostag: if we drop the dependency for non-Intel architectures, then that would mean that MAAS running on non-Intel will not be able to bootstrap Intel nodes."
<rbasak> roaksoax: maas-cluster-controller on non-Intel is uninstallable due to syslinux-common (supplying chain.c32, etc) no longer being available on non-Intel archs.
<rbasak> If we make it an arch-specific dep, then that'll make it installable but presumably leave it a little broken.
<rbasak> So I'm asking how important this use case is for us.
<rbasak> We could fix by dropping the dependency (but will affect functionality), reverting syslinux-common somehow to be available on the other archs, or declaring the appropriate multiarch bits so that the i386 or amd64 build can be installed on the non-Intel arch.
<rbasak> To me, the multiarch solution seems the best, and maybe least regression risk for this point in the cycle I guess.
<rbasak> Assuming that change would be acceptable to the release team.
<cjwatson> I'm afraid not
<rbasak> But do we actually need this functionality? Can we fix it by dropping the dependency on non-Intel maas-cluster-controller, losing that functionality, but not having to touch the syslinux pacakge?
<cjwatson> It would be non-trivially complex, potentially affect a bunch of other stuff, and it would be a lot of work to make our checks understand multiarch.
<cjwatson> rbasak: That sounds least invasive, albeit perhaps not globally ideal
<rbasak> Yeah it does seem to be far too late in the cycle to be discovering this. If it's a use case that really matters, that's a big QA failure.
<rbasak> roaksoax: what's your opinion on this?
<roaksoax> rbasak: otp
<rbasak> ok
<rbasak> cjwatson: understood, thanks.
<roaksoax> rbasak: so you are saying maas does not install on arm?
<roaksoax> rbasak: due to recent changes in syslinux packaging?
<rbasak> roaksoax: maas-cluster-controller does not install on powerpc, which is what I tested. But it looks like it applies to all that isn't i386 or amd64 too.
<rbasak> roaksoax: due to a syslinux change in packaging that landed on 1 July.
<rbasak> (AFAICT)
<cjwatson> I noticed it on powerpc but that may just be whatever happens to be on images.
<roaksoax> rbasak: well, I've seen it running on arm without an issue
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/utopic_probs.html and http://people.canonical.com/~ubuntu-archive/testing-ports/utopic_probs.html say that it affects arm64 and armhf too, between them
<cjwatson> roaksoax: it won't install on arm, today
<roaksoax> rbasak: but yeah, maas should be able to deploy i386/amd64 nodes even if it is runnong on ppc64el
<cjwatson> unless you go to some non-default lengths to sort out multiarch
<rbasak> roaksoax: should be able to yes. But how important is this use case? Because it appears to be broken, and at this time in the cycle our options are limited.
<roaksoax> rbasak: I would say it is important provided that we support running those arches
<rbasak> We support running arm64, yes?
<bdrung_work> cjwatson, how did you get the release date of vivid? just guessing or is there a release schedule proposal?
<rbasak> I'll file a bug then, thanks.
<lutostag> rbasak: thanks!
<cjwatson> bdrung_work: infinity and I agreed that it was better to guess (and thus have *something* in utopic that we can adjust later) than have nothing at all
<cjwatson> so that's the last Thursday in April
<infinity> doko: That python2.7 upload looks like a no-op to me, since ^gcc always matched regardless?
<bdrung_work> cjwatson, thanks and yes, guessing is better than nothing.
<bdrung_work> i uploaded 0.23 to unstable
<cjwatson> bdrung_work: great, thanks
<bdrung_work> you're welcome
<rbasak> Filed bug 1383332
<ubottu> bug 1383332 in maas (Ubuntu) "maas-cluster-controller is uninstallable on non-Intel architectures" [Undecided,New] https://launchpad.net/bugs/1383332
<infinity> rbasak: We could look at just flipping syslinux-common to arch:all.
<infinity> rbasak: If the 32-bit and 64-bit builds are the same.
<rbasak> infinity: yeah. I wondered why he changed it in the first place.
<rbasak> I think the builds are the same. For the bits that MAAS needs, anyway.
<rbasak> (I think those bits run in real mode)
<doko> infinity, no, it's set to <triplet>-gcc
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/bios/hdt.c32 and i386/usr/lib/syslinux/modules/bios/hdt.c32 differ
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/bios/sysdump.c32 and i386/usr/lib/syslinux/modules/bios/sysdump.c32 differ
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi32/hdt.c32 and i386/usr/lib/syslinux/modules/efi32/hdt.c32 differ
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi32/sysdump.c32 and i386/usr/lib/syslinux/modules/efi32/sysdump.c32 differ
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi64/hdt.c32 and i386/usr/lib/syslinux/modules/efi64/hdt.c32 differ
<cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi64/sysdump.c32 and i386/usr/lib/syslinux/modules/efi64/sysdump.c32 differ
<cjwatson> that's the complete diff -ru
<cjwatson> that might just be non-reproducibility
<infinity> doko: Ahh, didn't think the triplet case.  Check.  Thanks.
<cjwatson> it's probably OK
<cjwatson> and it was arch all until recently
<cjwatson> indeed it's arch all again in unstable now
<infinity> rbasak: Right, Colin's cherry-picking that change from Debian, so that solves that.
<cjwatson> ok, yeah.  I'll take that bug then
<rbasak> Oh, OK. Thanks!
<rbasak> I will follow up on the QA side of this though. If it's important, it should have been flagged months ago.
<xnox> darkxst: i haven't checked. I believe there will be another slideshow release, but I cannot confirm yet. I was going to look into it tonight.
<xnox> infinity: i'm barely around. What's up?
 * xnox should stop idling on irc when i'm not available.
<infinity> xnox: I don't remember, so it can't have been important.
<infinity> xnox: But I bet slangasek would like to yell at^W^Wtalk to you.
<xnox> infinity: are you on the right side of the pond to meet up and have dinner this week?
<infinity> xnox: On the left side.
<slangasek> xnox: he's on the left side of the pond
<slangasek> xnox: also, please to be fixing plymouth
<xnox> slangasek: i've noticed that you push overwrote plymouth branches. I haven't checked yet, what happen there.
<xnox> slangasek: i'm using 14.04 LTS and plymouth works great there =)))))
<slangasek> "push overwrote"?
<slangasek> xnox: yes, plymouth works great in 14.04, which is the release you didn't break it in :-P
<xnox> slangasek: was bad or really bad?
<infinity> xnox: A little from column A, a little from column B.
<slangasek> xnox: we're currently looking at bug #1362333, which is reproducible in a VM install - plymouth is doing something very broken with the passphrase input
<ubottu> bug 1362333 in ubiquity (Ubuntu) "After reboot of Ubuntu installation, password for LVM encryption is not accepted" [Undecided,Confirmed] https://launchpad.net/bugs/1362333
<slangasek> xnox: I have not seen this bug on my existing continuously-upgraded host install, but in a freshly-installed VM I will repeatedly type the passphrase at boot post-install and it won't work.  Then I'll use my backspace key, and things magically work
<xnox> slangasek: with upstart or systemd.
<infinity> xnox: upstart.
<slangasek> xnox: upstart, unless someone snuck in a change to the default init that I didn't notice ;)
<xnox> slangasek: i see a useful upload from andy. Did apw upstream that?
<xnox> ah, it's a cherry-pick, so yes.
<apw> xnox, ahh that one, yes it was upstream fixy fun
<xnox> slangasek: yeah, that bug is not funny. I'll be busy in a few, but will do ubuntu/debian work tonight, cause this bug sound like fun to work on.
<infinity> xnox: PS, there's a release in 3 days.
<ppisati> doko: FYI, perhaps you already saw that - https://www.mail-archive.com/linaro-toolchain@lists.linaro.org/msg04529.html
<apw> ppisati, are we expecting to see that "limit" come down through stable into older releases ?
<ppisati> apw: the gcc limit? it should
<apw> ugg
<ppisati> apw: and it seems T is affected - http://pastebin.ubuntu.com/8603452/
<apw> ppisati, yeah we need to know whether our compiler is patched for the issue on trusty, and then decide whether we should apply or not when it appears
<apw> doko, i hope you will know ;)
<sergiusens> pitti: hey, can we discuss adt with device constraints?
<voldyman> hey guys, i am making some changes in ubiquity, how do you test it?
<TheMuso> voldyman: You might have more luck getting an answer in #ubuntu-installer.
<slangasek> xnox: so I'm getting some interesting test results out of a hand-hacked cryptsetup initramfs script... such as 'plymouth ask-for-password' returning non-zero
<slangasek> xnox: and apparently I don't understand the semantics of POSIX shell 'read'
<brendand> stgraber, can i get added to https://launchpad.net/~ubuntu-qa-website-devel/+members?
<doko> tedg: ping on https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1382020
<ubottu> Ubuntu bug 1382020 in ido (Ubuntu) "ido ftbfs in utopic" [High,Confirmed]
<tedg> redirect ping bregma ^
<tedg> Oh, he's not online. That's a good trick.
 * tedg 's IRC Kung-Fu is weak
<tedg> doko, bregma was going to look into the xorg-gtest because it seems to not compile.
<stgraber> brendand: why?
<stgraber> (that's a privileged team with admin access over iso.qa.ubuntu.com, so I need a good reason :))
<stgraber> or we need to decouple the team from admin privileges over the production tracker, then I'd care a bit less about whose on it
<brendand> stgraber, i'm re-evaluating the qa tracker to be used again by QA
<brendand> stgraber, i'd like to play around with the dev instance - http://iso.qa.dev.stgraber.org/
<brendand> stgraber, i won't touch production - balloons will back me up
<brendand> stgraber, ?
<stgraber> brendand: try logging in again now
<stgraber> brendand: in theory I've given admin access to canonical-platform-qa on the staging instance
<brendand> stgraber, great thanks
#ubuntu-devel 2014-10-21
<tseliot> doko: any news on the two MIRs? (I saw you unsubscribed the MIR team)
<LocutusOfBorg1> hi, nobody wants to sponsor ettercap?
<LocutusOfBorg1> bug 1382848 :(
<ubottu> bug 1382848 in ettercap (Ubuntu) "[FFe] Sync ettercap 1:0.8.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1382848
<Madkiss> hi folks
<Madkiss> I'm building a pacakge for a PPA that needs dependencies from another PPA (the cloud team ppa for openstack icehouse on precise). How can I make the PPA auto builders use additional sources.list entries?
<LocutusOfBorg1> Madkiss, "Edit PPA dependencies" on your ppa page
<Madkiss> oih, hadn't seen that
<Madkiss> thanks!
<LocutusOfBorg1> you are welcome ;)
<flexiondotorg> I think I am seeing a regression in LightDM. Anyone here who I can quickly discuss that with? Maybe due to the recent fixed to address a double free in 1.12.
<Madkiss> LocutusOfBorg1: Okay. And how do I add external dependencies to other repos? the ubuntu cloud archive stuff isn't a PPA obviously
<LocutusOfBorg1> I don't get the question, but I think the answer is "you can't"
<Madkiss> I need to do " sudo add-apt-repository cloud-archive:icehouse" for the PPA.
<LocutusOfBorg1> add ppa dependency
<LocutusOfBorg1> you select "choose"
<LocutusOfBorg1> oh, indeed, then I don't think you can do it
<Madkiss> oh boy.
<LocutusOfBorg1> maybe you can with ubuntu-cloud-archive/icehouse-staging
<LocutusOfBorg1> you can with it, but I don't know if it is the same
<LocutusOfBorg1> maybe try to ask on #launchpad
<Madkiss> yeah, that could work
<arges> doko: hi. i'm testing ubuntu-toolchain-r. are there cross-compiler builds as well somewhere?
<doko> arges, sorry, not yet
<arges> doko: ok
<doko> arges, can you point me to a package which I could upload to a ppa? or maybe do it yourself?
<arges> doko: what needs to be uploaded? i was really just trying to test the ubuntu-toolchain-r with kernel compiles, and i wanted to test multiple arch builds. I could just try to find real hardware or emulate
<doko> arges, I assume a linux source package, of the most current kernel in trusty-updates/-security
<arges> doko: oh oh, you mean use a PPA and add your toolchain as a dep
<doko> arges, yes, but if you give me the package, I can upload to the ubuntu-toolchain-r ppa too
<tseliot> doko: what's the status of the two MIRs?
<doko> tseliot, looking
<tseliot> thanks
<arges> doko: i should be able to handle it. i don't want to mess up your ppa with a kernel build
<Hurri877> Hi I was wondering were I could get some help with git buildpackage?
<jnxd> didrocks, I recently installed UDTC and then through it android studio. Just wanted to know in case I wanted to remove the latter, what steps are necessary?
<Riddell> mvo: release-upgrade doesn't work when ran from a kubuntu package manager, https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1383786
<ubottu> Ubuntu bug 1383786 in ubuntu-release-upgrader (Ubuntu) "Kubuntu 14.04 â 14.10 "Could not calculate the upgrade"" [Undecided,New]
<Riddell> mvo: but it's ok when ran from do-release-upgrade
<Riddell> mvo: wibble, help
<LocutusOfBorg1> interesting, backportpackage seems to be not working anymore
<LocutusOfBorg1> bdrung, any idea?
<LocutusOfBorg1> distro_info.DistroDataOutdated: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
<bdrung_work> LocutusOfBorg1, you need to update distro-info-data (and probably distro-info, too)
<cjwatson> yes they're on their way
<cjwatson> waiting to be able to sync distro-info
<cjwatson> oh I think somebody uploaded that
<cjwatson> yeah I just need to unblock those, doing no
<cjwatson> w
<LocutusOfBorg1> yes, thanks :)
<bdrung_work> cjwatson, we have to apply the fix for distro-info to trusty (precise is not affected)
<cjwatson> bdrung_work: ok, if somebody uploads an SRU I'll review it
<Riddell> mvo: oh you're at a conference?
<mvo> Riddell: yes
<Riddell> whyever is there a conference on release week
<mvo> Riddell: do you need anything from me?
<mvo> Riddell: I don't know
<Riddell> mvo:  bug 1383786
<ubottu> bug 1383786 in ubuntu-release-upgrader (Ubuntu) "Kubuntu 14.04 â 14.10 "Could not calculate the upgrade"" [Undecided,New] https://launchpad.net/bugs/1383786
<stgraber> Riddell: the release sprint is at a company sprint and yeah that's pretty weird
<Riddell> mvo: "do-release-upgrade -m desktop -f DistUpgradeViewKDE" fails but works with the "-d"
<Riddell> mvo: is that expected?
<mvo> Riddell: hmmmm, it seems like its breaking on "startpar" which is now required
<Riddell> what's that?
<mvo> Riddell: I don't know
<Riddell> :(
<cjwatson> conference on release week> not our idea
<mvo> Riddell: what does apt list startpar give you?
<Riddell> Listing... Done
<Riddell> (on trusty)
<Riddell> mvo: â
<mvo> Riddell: hmmmm
<Riddell> mvo: I don't understand how it can be different due to the -d , I've set the dns to point to a server with utopic included in meta-release so it should be the same thing
<rbasak> doko: python-eventlet 0.13.0-1ubuntu3 fixed bug 1371291, right?
<ubottu> bug 1371291 in python-eventlet (Ubuntu Utopic) "FTBFS caused by PEP 466" [High,Triaged] https://launchpad.net/bugs/1371291
<mvo> Riddell: yeah, I don't see startpar at all anywhere, I wonder where it cmes from.
<mvo> Riddell: also "  MarkInstall startpar [ amd64 ] < none -> 0.59-3ubuntu2 > ( universe/admin ) FU=1" <- its in universe and required? very confusing
<arges> doko: so i am trying to test your ubuntu-toolchain-r, i setup cross-chroots with your PPA, but they seem to be failing on python installation issues (when installing deps for the kernel) this affects ppc64el and arm64 so far
<arges> doko: http://pastebin.ubuntu.com/8616765/
<Riddell> mvo: sorry I need to go out for a couple of hours, any idea you have appreciated
<mvo> Riddell: I look into it
<jibel> Riddell, does upgrade work with -proposed disabled?
<jibel> Riddell, startpar is only in utopic-proposed
<mvo> I think i know what is going on
<doko> arges, strange ... this ppa survived a whole archive test rebuild
<mvo> Riddell: so startpar is only available in proposed and priority is required, I uploaded a new version that lowers the priority, this should fix the upgrade
<cjwatson> mvo: eh that's ineffective
<cjwatson> mvo: correct fix is to get an AA to change-override :)
<cjwatson> mvo: I'll do that after your upload builds everywhere
<mvo> cjwatson: oh, sorry. you are right of course :) please reject and fix it there
<cjwatson> mvo: too late
<cjwatson> should be optional too :)
<mvo> cjwatson: want me to do another one?
<cjwatson> no
<mvo> ok, thanks
<cjwatson> actually this is weird
<cjwatson> priority-mismatches should be whining about this
<cjwatson> oh, we probably don't run that against -proposed
<cjwatson> ok, I'll fix after lunch
<xnox> pitti: do i remember correct, there was some init script or upstart job, to change the power/cpu scheduler after X seconds post-boot to improve battery life or some such.
<xnox> pitti: do you recall something like that? and if yes, where was it?
<pitti> xnox: it rings a bell, but I don't remember either where that happened :/
<xnox> pitti: i vague recall you were the author of that trick.
<xnox> unless i have it complete wrong.
 * xnox ponders what was that package which whole bunch of default sysctl commands et.al.
<sarnold_> procps?
<xnox> pitti: /etc/init.d/ondemand
<j1729> Hello guys. How are you doing ?
<j1729> are there bugs to fix or someway I can get started with contributing as a developer ?
<xnox> sarnold_: yes, that's the other package i thought it might be in.
<pitti> xnox: hah, indeed; with a lovely sleep 60
<infinity> xnox: You're thinking of /etc/init.d/ondemand from initscripts
<infinity> xnox: Oh, pitti got there.
<xnox> infinity: funny how it sleeps first, and only then determines if there are desired governors and then bails.
<xnox> infinity: would be nice to bail, before going for a sleep =)
<infinity> xnox: Meh, not that it matters much, really.
<ogra_> xnox, iirc we needed the sleep on nexus7 back then
<ogra_> (i dont remember why, but i guess it could go)
<bdrung> Laney: re #1381995, why not fix distro-info in trusty?
<Laney> I think it will be
<Laney> But don't want to block on that
<bdrung> it's a one line fix.
<Laney> Does that affect the SRU aging period?
<bdrung> no
<Laney> Also I am (maybe) going to -security and I don't know if that fix would.
<Laney> Soooo
<Laney> Yeah
<bdrung> okay, then let's keep the workaround, get distro-info fixed in a SRU and then let's see which date will be the final date
<cjwatson> pitti: language-pack-af upload seems to have gone missing: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#language-pack-af-base
<xnox> apw++
<alexbligh1> I'm trying to debug an upstart problem where 14.04 does not start an upstart script that runs on udev-finish in a container in lxc. When not in a container, it works. pstree doesn't show anything unexpected running. Any ideas where to start? The confusing thing is that this used to work ...
<zbenjamin> slangasek: thanks for helping with the gnueabi vs gnueabihf. I have a working qmake now :)
<xnox> alexbligh1: increase upstart verbosity, and see if the desired events are emitted.
<xnox> alexbligh1: also test if the job is valid.
<alexbligh1> xnox, if I start the job manually, all is well
<xnox> alexbligh1: sudo lxc-start -n container -- /sbin/init --verbose
<xnox> alexbligh1: in that case start-on conditions probably never fire. Oh, there is no udev nor udev-finish in containers =)
<slangasek> zbenjamin: huzzah
<alexbligh1> xnox, what /stops/ there being a udev in containers? I seem to remember coming across that before and disabling whatever stopped it, because I want udev in this instance
<cjwatson> pitti: accepted, thanks
<xnox> alexbligh1: you might want your job to start on (...) or not-container
<pitti> cjwatson: ah, you beat me to it; sorry about that
<pitti> (with accepting, I mean)
<xnox> alexbligh1: sorry or container that is.
<xnox> alexbligh1: chat with people on #lxcontainers about udev and device access....
<cjwatson> pitti: np
<cjwatson> I was in the queue anyway
<xnox> alexbligh1: in general udev runs on the host's kernel and doesn't affect what happens inside the container and one cannot per-se connect/disconnect devices from a container.
<xnox> one can choose to bind-mount / export them into the container, but that's about it.
<alexbligh1> xnox, I'm guessing something subtle has changed between 14.04.00 and 14.04.01
<xnox> alexbligh1: lxc gets a lot of bugfixes and new stable releases are pushed to trusty. chat on #lxcontainer they'll be able to help. And are very familiar with upstart inside the lxc containers.
<alexbligh1> xnox, thanks. upstart + containers = confusing.
<zyga> I have a small patch for python3.4 that memsets one structure that gets passed to a syscall, currently that struct has some uninitialized data (which is safe but makes some of my testing unreliable)
<mapreri> pitti: :) hi! might I hope for a last-day sync of scribus? it fixes the nasty #1383407 but it's a small patch (<http://www.mapreri.org/debian/debdiffs/scribus/1.4.4+dfsg1-1_1.4.4+dfsg1-2.debdiff>) quite harmless.
<pitti> mapreri: can I redirect you to #ubuntu-release, please? in meeting/busy/no powers any more to break the release freeze without asking
<mapreri> pitti: fine, thanks
<Laney> pitti: mapreri: bugfix, unseeded> still can sync
<Laney> oh, but scribus isn't unseeded :(
<mapreri> Laney: IIRC it's in edubuntu....
<mapreri> Laney: I'm submitting a FFE bug... I just wanted to get rid of https://bugs.launchpad.net/ubuntu/+source/scribus/+bug/1383407 before release...
<ubottu> Ubuntu bug 1383407 in scribus (Ubuntu) "Scribus spell check and hyphenation doesnt work" [Undecided,New]
<alexbligh1> xnox, thanks - you led me to the solution there.
<Laney> mapreri: No need for ffe
<mapreri> indeed it's not feature freeze, but it's the final freeze
<Laney> Yes, don't worry about a bug
<mapreri> Laney: I'm new to last-day uploads, what kind of permission I need? Might I use your message above as an ack and send a green light to my sponsor?
<Laney> I'll sync it, I just asked in #ubuntu-release if there will be new images comig anyway
<mapreri> Laney: ok, thanks. (I saw the message, but didn't understand it :))
<hallyn> arges: hi, the SRUs for qemu and libvirt to trusty are verified adn have baked for awhile, coudl they be promoted?  (security team has updates they want to push)
<Laney> mapreri: it is synced
<hallyn> infinity: https://launchpad.net/ubuntu/trusty/+queue?queue_state=0&queue_text=ipxe-precise   what is the next step to getting that out of NEW?
<infinity> hallyn: Someone needs to review it.
<infinity> hallyn: And yeah, I can promote the others.
<mapreri> Laney: thanks very much. will wait for acceptance now :)
<hallyn> infinity: cool, thanks
<arges> hallyn: i'll take a look
<arges> hallyn: oh looks like infinity got to it already
<arges> infinity: thanks
<goodwill> ppetraki: ping
<hallyn> arges: yup, thanks
<goodwill> hallyn: maybe you can help ... what in debian installer triggers multipath-udeb install?
<cjwatson> goodwill: disk-detect.sh in hw-detect
<cjwatson> from a user point of view you enable it by preseeding disk-detect/multipath/enable=true
<goodwill> cjwatson: right ... so I am trying to try out the new fixed udeb for multipath in proposed? should I install them in early_command then?
<goodwill> cjwatson: I ran disk detect manually ... but there is not /sbin/multipath
<ppetraki> goodwill, pong
<goodwill> ppetraki: still fighting multipath ;) ^^^
<cjwatson> goodwill: if it's in -proposed, usual advice is to just use apt-setup/proposed=true
<cjwatson> goo	don't run installer components manually
<cjwatson> (sorry, bit of lag)
<goodwill> cjwatson: I used the standard menu prompt and installed the DM-Multiparth support, which appears to install the module drivers
<goodwill> cjwatson: then I ran detect and that installed kpartx udeb
<goodwill> cjwatson: so far I failed to figure out how the multipath-udeb is installed though
<cjwatson> I told you above
<cjwatson> preseed disk-detect/multipath/enable=true
<cjwatson> that is, boot the installer with the additional kernel arguments   disk-detect/multipath/enable=true apt-setup/proposed=true
<goodwill> I guess a better question is: it preseeded only and not available in the user prompts?
<cjwatson> assuming this is netboot
<cjwatson> as far as I can see it is preseeded only yes
<goodwill> I see
<goodwill> okie
<cjwatson> (I don't know much about multipath specifically, just about the installer)
<goodwill> that explains it
<goodwill> cjwatson: was booting from mini iso for testing
<cjwatson> netboot mini.iso?
<goodwill> yeah
<cjwatson> yes that's the same as netboot for this purpose
<goodwill> right
<cjwatson> apt-setup/proposed=true causes the installer to fetch components of itself from -proposed as needed
<cjwatson> that's used for verifying SRUs
<goodwill> cjwatson: I am sorry what does SRU stand for?
<cjwatson> stable release updates
<goodwill> cjwatson: is there a way to do db_set on a command line?
<cjwatson> goodwill: debconf-set but it needs to be in the right context (don't have time to explain now); it's easier to just put that variable on the kernel command line, or use a proper preseed file if this is read late enough
<goodwill> cjwatson: I see
#ubuntu-devel 2014-10-22
<nudtrobert> beuno: hi, i'am from ubuntu kylin team and reached you via seb128. We deployed canonical-identity-provider for Ubuntu Kylin and there are some problem www-oops reported. I have send a mail attached the www-oops log. If you could have a look?
<mgedmin> does anyone know which package contains the translation for the syslinux boot menu (http://i.imgur.com/gSMVrYk.png) ?
<LocutusOfBorg1> hi Laney I forgot to ask a sync :/ virtualbox related
<LocutusOfBorg1> it is kbuild, fixing an RC bug, one line change
<LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/kbuild.git/commit/?id=0437af2183faedf5b9b065bc0910242afba1e53e
<LocutusOfBorg1> with never kernels rebuilding virtualbox fails because of the error threated as "fatal"
<LocutusOfBorg1> bug 1384075
<ubottu> bug 1384075 in kbuild (Ubuntu) "Sync kbuild 1:0.1.9998svn2695+dfsg-2 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1384075
<_nedR> guys.. Could someone shed light on why https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1170647 is not yet fixed?
<ubottu> Ubuntu bug 1170647 in Unity "After minimizing an external media, clicking on the "Files" icon on the Launcher doesn't restore the minimized window, but opens a new one" [High,Triaged]
<cjwatson> mgedmin: gfxboot-theme-ubuntu
<mgedmin> cjwatson, thanks!
<mgedmin> only none of the translatable messages in gfxboot-theme-ubuntu mention Ubuntu GNOME.  hm.
<cjwatson> Oh err it's possible that I forgot to add that :-/
<cjwatson> Too late now for utopic unfortunately - no way we'd get any reasonable number of translations even if I added it right now.  Could you file a bug to remind us not to screw this up for vivid?
<mgedmin> pull-lp-source gfxboot-theme-ubuntu utopic && cd gfxboot-theme-ubuntu-0.17.0 && grep -R 'Ubuntu GNOME' . -> no matches
<mgedmin> sure, I can file a bug
<mgedmin> I don't mind this getting fixed for 15.04
<cjwatson> Yeah, unfortunately we have to do this for each flavour because they're inflected differently in some languages
<cjwatson> (For an inaccurate analogy, think "an Ubuntu image" vs. "a Kubuntu image")
<cjwatson> And then there are the languages that transliterate the flavour names
 * mgedmin wants a large disk and the sources of all the ubuntu packages, for recursive greps
<geser> something like http://codesearch.debian.net/ and http://sources.debian.net/ but for Ubuntu would be nice, but it doesn't exist AFAIK
<beuno> nudtrobert, hi. So, my understanding is that deploying more SSO's is not something we'd want. I'd refer you to willcooke for that.
<nudtrobert> beuno, hi. we have talked about sso deployment in Auguest's Canonical-UbuntuKylin meeting
<nudtrobert> willcooke, hi, we, ubuntu kylin team, meet some problem in deploying canonical-identity-provider. if you could off some help to check the www-oops log?
<ogra_> barry, did you try to OTA a phonne today ?
<ogra_> seems we all have issues
<barry> ogra_: i have not.  could be problems with server?
<ogra_> yeah
<ogra_> i wonder if the proxy was put in place
<barry> ogra_: direct hits to system-image.ubuntu.com work.  can you get a shell on your phone?
<barry> ogra_: i'll be right back.  gonna go grab my phone
<barry> ogra_: very well could be the proxy.  i'm getting a 404 on  https://system-image.ubuntu.com/channels.json
<ogra_> ah
<ogra_> barry, hmm, i dont
<barry> ogra_: get a shell and do: system-image-cli --dry-run -vv
<barry> oh, hang on
<stgraber> ogra_: so IS is mirroring http but not https so if they two are out of sync you can expect a bunch of 404s
<stgraber> herb: any chance you can configure the system-image mirror to proxy things back to the original server when hitting 404 (I can probably dig the apache config to do that if that helps)?
<barry> ogra_: http://system-image.ubuntu.com/pool/ubuntu-e89654df318eb90327c644de47bbc4d752ff1a7547c0f5c49020ff0a15eaf10f.delta-ubuntu-f9096ef452d353fcdcd08220b83c907a3200bce9f2e26dee17653f914dc583d8.tar.xz:NETWORK ERROR
<barry> stgraber: ^^ http url gets a network error from udm
<stgraber> barry: right, which is to be expected if the mirror is out of sync
<barry> stgraber: ack
<beuno> nudtrobert, I understand. You should talk to him to figure this out
<stgraber> herb: something like http://paste.ubuntu.com/8627643/ should do the trick (completely untested)
<herb> stgraber: I'd rather not try that right now. I'll give it a whirl around lunch time though if that's already
 * herb would rather not break things while people are working
<stgraber> herb: ok, in the mean time, can you increase the sync frequency?
<herb> stgraber: it's running continuously
<herb> so... not really?
<stgraber> hmm, ok :)
<herb> I think I sleep it for 5 minutes between runs
<herb> just so we aren't hammering the origin
<stgraber> ok, seems odd that people are still hitting the 404s somehow
<herb> hmm. rsync was erroring out. I'm running a sync now manuall
<herb> y
<herb> I'll debug it after that finishes
<doko> rsalveti, can you get rid off the openjdk-6 b-d in gcc-i686-linux-android ? xnox already removed that for the arm toolchain
<doko> make[1]: Entering directory '/scratch/packages/tmp/gcc-arm-linux-androideabi-0.20130705.1/android'
<doko> build/core/main.mk:45: ********************************************************************************
<doko> build/core/main.mk:46: *  You are using version 4.0 of make.
<doko> build/core/main.mk:47: *  Android can only be built by versions 3.81 and 3.82.
<doko> build/core/main.mk:48: *  see https://source.android.com/source/download.html
<doko> build/core/main.mk:49: ********************************************************************************
<doko> build/core/main.mk:50: *** stopping.  Stop.
<doko> xnox, rsalveti: ^^^ \o/
<rsalveti> doko: we have a path for that in our repo
<rsalveti> need to find it though, on a meeting now unfortunately
<bdrung_work> cjwatson, ping
<cjwatson> bdrung_work: ?
<bdrung_work> i want to talk about your change in netcfg 1.21ubuntu2
<cjwatson> Er the chances of me remembering anything about the context of that now are basically nil
<cjwatson> It was eight and a half years ago
<bdrung_work> cjwatson, can it be that this was a workaround for bug #1307429?
<ubottu> bug 1307429 in ifupdown (Ubuntu Trusty) "Existing allow-hotplug devices do not come up" [Wishlist,Fix released] https://launchpad.net/bugs/1307429
<bdrung_work> cjwatson, specifying allow-hotplug works now as expected.
<cjwatson> I'm afraid I have no idea whatsoever
<cjwatson> If you want to propose a change there then I'd suggest talking with stgraber to make sure it's globally sensible
<bdrung_work> cjwatson, what do you mean with 'globally sensible'?
<stgraber> I'm assuming he means that allow-hotplug is globally supported, which it isn't at the moment
<cjwatson> no unexpected results in weird places in the stack that I don't know about
<stgraber> ifupdown does indeed support it now thanks to your change last cycle, but not all of the ifupdown hooks do support it
<stgraber> we've got a bunch of udev and ifupdown hooks that I believe still call ifquery and only care about auto
<bdrung_work> stgraber, do you know which ones?
<ogra_> herb, hmm, does that mean nobody can work until lunch ? (we all need to upgrade our phones to be on the latest images etc)
<ogra_> herb, oh, ignore me, seems my phone now upgrades fine
<ogra_> (thanks !!!)
<stgraber> bdrung_work: my guess would be at least bridge-utils and vlan, possibly ifenslave too
<cjwatson> mvo: can you have a look at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntustudio/+build/9479 and see if you can puzzle it out?  looks like an apt ordering bug, maybe, terrible time to hit one though
<cjwatson> I couldn't reproduce it locally (I was only driving lb directly rather than from a full launchpad-buildd setup though)
<mvo> cjwatson: indeed, that looks nasty
<smoser> anyone else see compiz (i think) lock ups in utopic ? basically i'm using system fine, and then screen freezes.  mouse moves, and even changes icon per content under it (ie, mouseover alink in firefox).
<smoser> when this happens i end up rebooting.
<smoser> kickinz1 was seeing this too.
<smoser> i'm not sure if its kernel or compiz.
<smoser> well, i opened https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384342 . i'm not sure if that is separate bugs or the same.
<ubottu> Ubuntu bug 1384342 in linux (Ubuntu) "kernel messages intel_crtc_wait_for_pending_flips correlate to compiz hang" [Undecided,New]
<slangasek> xnox: either you're trolling or you should ++verbose
<sarnold_> gaughen: tada! :) https://bugs.launchpad.net/ubuntu/+source/python-pysnmp4/+bug/1349868
<ubottu> Ubuntu bug 1349868 in python-pysnmp4-apps (Ubuntu) "[MIR] new build dependencies for ceilometer" [Undecided,New]
<maniaque> does anyone know about tzdata update of Ubuntu Server LTS? it was proposed at 17th
<mdeslaur> infinity: ^
<rsalveti> doko: the patch for that failure: https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/build.git;a=commitdiff;h=11c351df78fc05ac5a1c73153070901a1862106a;hp=35f35300cd920cfa438ecc0a8ef715dc9862e68c
<infinity> mdeslaur: I'll test and promote those this afternoon.  Sorry, been distracted by the release.
<mdeslaur> infinity: don't apologize to me, my timezone isn't changing :)
<pitti> cjwatson: for ssh's -o ControlMaster=auto and -o ControlPath=$path, is there any way I can tell the ssh multiplexer process to quit, or find out its pid to SIGTERM it?
<pitti> cjwatson: I can do the equivalent of ps ux|grep ssh.*$path, but that's a bit ugly
<pitti> cjwatson: I need it as it has the same stderr as adt-run, which causes a long hang on cleanup
<mlankhorst> pgrep ;-)
<mlankhorst> or grab the pid after forking
<pitti> I was hoping for someting slightly more elegant/robust, like sending a command to the socket or a pid file or so
<pitti> mlankhorst: that fork is under ssh's control, not mine
<geofft> pitti: ssh -O exit
<pitti> geofft: ooooh! just what I was looking for, thanks!
<pitti> cjwatson: unping
<cjwatson> geofft: thanks for finding that for pitti before I saw it :)
<pitti> working like a charm indeed \o/
<doko> rsalveti, fixed
<rsalveti> doko: great
<smoser> anyone want to look at my console log collection of amd64 "works" and ppc64el "does not work".
<smoser> something is different between
<smoser> amd64: http://paste.ubuntu.com/8632475/
<smoser> ppc64el: http://paste.ubuntu.com/8632478/
<smoser> for some reason ppc64el mountall never says: mounting event sent for /
<doko> jamespage, can you subscribe your team for the ceilometer deps?
<smoser> slangasek, ^ i know your busy, but as 'mountall' is involved, you're who i bother.
<smoser> i can get similar logs with '--verbose' on console.
<slangasek> smoser: did you work out what the 13th virtual filesystem is that hasn't successfully mounted?
<slangasek> smoser: virtual filesystems are mounted first before local filesystems are attempted (because fsck); so that's where it's getting stuck
<nemo> Hey folks. I ran into a pretty nasty crash, and wanted to show the devs the stack trace
<nemo> is there any way to copy it out of apport ?
<nemo> erm. that is what the ubuntu crash manager gui is called right?
 * nemo checks process list to be sure
<nemo> apport-gtk looks like
<nemo> there's a nice tree structure, but can't seem to ctrl-c to copy the stack trace, and there's no export as text option or anything as far as I can see
<nemo> aaand no likely looking files in /tmp
<cjwatson> pitti: Why does language-pack-af depend on language-pack-an-base?
#ubuntu-devel 2014-10-23
<smoser> slangasek, i'm pretty sure its /run .
<smoser> which is blocked on the mounting of /
<smoser> but somehow on intel this works.
<smoser> ie, the change that caused this failure was
<smoser> /etc/init/cloud-init-local.conf
<smoser> - start on mounted MOUNTPOINT=/
<smoser> +start on mounted MOUNTPOINT=/ and mounted MOUNTPOINT=/run
<slangasek> smoser: mmm.  Remind me the intended semantics of /etc/init/cloud-init-local.conf?  You don't /want/ to block the filesystem events from returning, right, you just want cloud-init-local to run only after / and /run are mounted?
<slangasek> smoser: did you ever try 'start on mounted MOUNTPOINT=/ and virtual-filesystems'?
<jamespage> doko: done (subscriptions)
<wouter> hi -- https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule suggests Utopic is to be released today. Is that still on schedule?
<mitya57> wouter: yes!
<wouter> okay, thanks
<hyperair> argh is the archive broken?
<hyperair> my upgrade crashed out
<hyperair> i've been running aptitude full-upgrade, and still have 1200+ packages to install
<hyperair> at least it's progress Â¬_Â¬"
<flexiondotorg> Is it too late to request some sync requests from Debian?
<flexiondotorg> There are some upstream fixes that landed in Debian a few hours ago for MATE.
<hyperair> is that in main or universe?
<hyperair> i think you can still request syncs for universe packages even after final freeze
<flexiondotorg> hyperair, universe
<hyperair> at least, it won't be impacting the iso images
<pitti> cjwatson: argh, because I can't type; new one coming
<pitti> nemo: you can use apport-unpack on the .crash file (see manpage)
<nemo> pitti: ah. thanks
<nemo> pitti: fortunately it turned out to be really really really easy to reproduce so they didn't need the bt
<nemo> but I'll remember that
<nemo> pitti: hm. where *is* the .crash ?
<pitti> nemo: aside from that, the .crash is just a plain text file, so it's quite human readable
<pitti> nemo: /var/crash/
<nemo> pitti: oh nice. yeah. I can just copy and paste this
<nemo> pitti: shame I couldn't just ctrl-c from the tool, but that might just be a limitation of the gtk widget
<pitti> nemo: there's a nice close button in the window title bar :)
<nemo> pitti: oh, I just mean if I ever run into an ubuntu user who hits a crash in our stuff, would be nice if I could just tell them to ctrl-c
<nemo> but. nbd for me, that /var/crash thing is pretty much perfect
<pitti> ctrl-c is spelled "Cancel" in GTK
<nemo> hm.
<nemo> that's how you copy in a fair number of gtk apps
<nemo> in fact, some, like gedit/pluma don't even let you use the X copy à² _à² 
<nemo> pitti: oh. btw, if you're curious about the crash, it is kinda funny. http://www.fnordware.com/j2k/jp2samples.html  save the jp2 link to a MATE 1.8 or 1.10 desktop and you'll get an infinite series of crashes and respawns of caja
<nemo> pitti: assertion in jp2 decoder - looks like they decided to move thumbnail generation into caja instead of keeping it in a separate process
<nemo> presumably for performance
<nemo> I mentioned it in #MATE so hopefully someone will fix it soon-ish
<nemo> only way to make it stop infinitely crashing and respawning is to move the image off the desktop
<nemo> I guess they could change the assertions to just aborting the thumbnail creation, but given how nutty image formats can be, thinking keeping this in a dedicated process might be safer in the long run. ah well.
<flexiondotorg> nemo, I am on the MATE team. Whats up.
<nemo> flexiondotorg: oh. are you in #MATE ? I mentioned it last night there and has been quiet since
<nemo> flexiondotorg: but. what I mentioned above. http://www.fnordware.com/j2k/jp2samples.html
<nemo> save the JP2 link to the Desktop results in infinite series of crashes of caja due to an assertion in jp2_dec
<flexiondotorg> Yep.
 * flexiondotorg goes testing in a VM...
<nemo> flexiondotorg: I nattered on a bit in there about how screwed up image/video (and audio) decoding can be, and how this is probably best kept out of important user stuff
<nemo> flexiondotorg: thumbnailer could be a dedicated process and such
<flexiondotorg> nemo, Confirmed.
<flexiondotorg> If you save it anywhere and view that folder it will crash Caja. Obvoiusly on the Desktop that create a burning fireball of death.
<nemo> flexiondotorg: yeah. I figured anywhere would work too
<nemo> flexiondotorg: I'd initially tried gdb --args caja /tmp
<nemo> but, was too much of a pain to keep my main caja from taking over
<nemo> that's why I dropped by here to find out how to get a trace from apport instead
<flexiondotorg> nemo, apport trpped it in my VM.
<nemo> yep
<smoser> slangasek, wrt semantics of cloud-init-local. i want to block.
<smoser> and i think virtual-filesystems would not block.
<slangasek> smoser: right; and it doesn't work so well to block both events when one might be dependent on the other
<nemo> flexiondotorg: by getting a trace from apport, I mean, I couldn't figure out how to copy a trace out of apport-gtk - that's why I came to #ubuntu-devel  and was told how to find the text in /var/crashes
<nemo> er. /var/crash
<flexiondotorg> nemo, What thumbnailer is used on your system?
<nemo> flexiondotorg: ummmmm.  well, this is caja 1.8.1 so I'm gonna guess that the crash means the thumbnailer is caja
<nemo> flexiondotorg: but in older versions and in gnome2, it was a separate process
<nemo> gnome thumbnailer or something
<smoser> slangasek, but why are they dependenton another ?
<smoser> other than /run not existing (which it does).
<nemo> flexiondotorg: for a large directory of images there was noticeable lag, probably due to repeated process respawn
<nemo> flexiondotorg: I'm guessing that's why they decided to move it in-process
<nemo> flexiondotorg: 'course that makes handling bad code a bit more interesting.
<nemo> flexiondotorg: a single dedicated process that could be passed urls might be a compromise
<smoser> slangasek, this would make sense to me, and i wouldn't have done the thing if it didnt work in intel.
<nemo> flexiondotorg: perhaps easier than ensuring all image parsing is rigorous and safe - over the years it seems image parsing is constantly a source of insanity, esp for obscure formats, or effed up ones like TIFF
<nemo> flexiondotorg: and, yeah, my recollection from messing around w/ AMP back in the day is that MP3 is just as much of a pain (the headers that is).  HTML is bad too - basically any format w/ a ton of implementers and a bit too broad a spec
<barry> lool: this is kind of old, but LP: #1276347
<ubottu> Launchpad bug 1276347 in ubuntu-download-manager (Ubuntu) "Some files are never downloaded (while under test)" [Undecided,New] https://launchpad.net/bugs/1276347
<roadmr> cjwatson: hey! I see ldlinux.c32 is now in the utopic netboot directory in archive.ubuntu.com, but according to my tests, 2 more files are also needed libcom32.c32 and libutil.c32, is it possible to also put them there?
<cjwatson> roadmr: the Debian bug indicated that that was unnecessary because they are now found by a path search
<cjwatson> we should dig into that if it is not in fact true
<cjwatson> roadmr: but I cannot deal with this right now, I'm working on releasing 14.10
<cjwatson> please hold until later
<roadmr> cjwatson: oh ok, I'll test that, and no problem, I can wait. Release yay, thanks!
<exarkun> Any chance anyone can comment one way or the other on whether the fix for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1274779 will ever appear in 14.04 or 14.10?
<ubottu> Ubuntu bug 1274779 in xserver-xorg-video-intel (Ubuntu) "[ivb] hang on pageflip (IPEHR: 0x0a000001 or 0x0a080001 depending on pipe)" [High,Fix committed]
<tjaalton> exarkun: what fix? upstream bug says it should be reopened
<tjaalton> ah, fixed in 3.17.. you'll have to wait for that
<tjaalton> unless the fixes are marked for stable@
<exarkun> tjaalton: It sounds like that means it won't be backported.  Is my understanding correct?
<exarkun> tjaalton: The fix will appear in whatever release of Ubuntu packages Linux 3.17, and not before?
<Pwnna> has anyone have issues with cryptsetup in 14.04?
<Pwnna> uhm. 14.10
<tjaalton> exarkun: otherwise someone needs to backport it to 3.13/3.16
<exarkun> tjaalton: Thanks.
<rsalveti> pitti: hey, were you the one complaining about rtm for emulator?
<rsalveti> it seems to be broken
<rsalveti> unity-system-compositor is a defunct process here
<pitti> rsalveti: yeah, we sat next to each other when I noticed :)
<pitti> rsalveti: oh sorry, actually not -- that was sergiusens
<rsalveti> pitti: yeah :-)
<rsalveti> pitti: I think I got what is wrong
<pitti> rsalveti: so I used ubuntu utoppic, that one still works (older unity or so)
<pitti> rsalveti: in rtm, unity failed with some EGL_BLAH error
<rsalveti> pitti: yeah
<rsalveti> pitti: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
<rsalveti> this is the reason
<sergiusens> EGL_BAD_MATCH
<rsalveti> I'm copying that over to rtm
<pitti> 'zactly
<pitti> rsalveti: oh, awesome
<mdeslaur> slangasek: so, reinstalled and didn't check the "download updates" box, and it still downloaded a whole bunch of updates during install :P
<mdeslaur> pretty curious
<slangasek> hmmm
<mdeslaur> just FYI
<mdeslaur> I'll file a bug
<slangasek> smoser: so what is the root filesystem device as listed in /etc/fstab, for your success vs. failure cases?
<slangasek> smoser: I see root=/dev/vda on the kernel commandline for both, but maybe /etc/fstab differs
<slangasek> smoser: in particular, if ppc64el lists something UUID= ish, mountall doesn't resolve that until udev announces the device's presence, which won't happen until virtual-filesystems is emitted
<smoser> slangasek, both success and failure
<smoser> $ cat /etc/fstab
<smoser> LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
<smoser> seemingly no change when i 'sed s,LABEL=cloudimg-rootfs,/dev/vda, /etc/fstab'
<doko> jamespage, can the neutron-plugin-nuage neutron-plugin-opencontrail neutron-plugin-sriov-agent ceilometer-agent-ipmi be demoted? if not please seed
<jamespage> doko, they can indeed
<jamespage> be demoted that is
<doko> ok
<smoser> wait. strike that comment.
<smoser> well. i had failed to actualy make the change. but the change doesn't seem to have affect.
<zerick> Has anybody used travis-ci.org to build debian packages ?
<geofft> zerick: paulproteus has some scripts to use pbuilder at https://github.com/paulproteus/travis-debcheck
<geofft> haven't played with them myself. I hear they're incredibly fragile but also work way better than you'd expect
<geofft> the use case is automated testing, not actually distributing the packages to anyone.
<zerick> I see
<slangasek> smoser: hmm ok
<smoser> maybe its a rathole.
<smoser> but i'm stuck on why this would be different per arch.
<smoser> it could just be race condition and luck on intel i guess.
<slangasek> smoser: is udev running at the point it gets stuck?
<smoser> slangasek, you have a suggestion on how to know that ?
<slangasek> smoser: hack the system to open a root shell somewhere that you can get access to it (VT?) in early boot
<zbenjamin> tedg: ping
<smoser> slangasek, not terribly easily. i'm just going to add a start on started job. and sleep N, then start printing debug info
<tedg> zbenjamin, Howdy
* cjwatson changed the topic of #ubuntu-devel to: Archive: closed | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<slangasek> smoser: so on the x86 machine you're passing 'ro' on the commandline, but not on the power one?
<smoser> same on both.
<smoser> passing 'rw' "fixes"
<smoser> slangasek, http://paste.ubuntu.com/8644088/
<pitti> mvo_: I filed bug 1384864 about what we talked about this morning
<ubottu> bug 1384864 in command-not-found (Ubuntu Vivid) "Please blacklist pg_ctl" [Undecided,Triaged] https://launchpad.net/bugs/1384864
<smoser> that is with 'my-debug.conf' providing the debug output there (http://paste.ubuntu.com/8644091/)
<mvo_> pitti: thanks, added and I am running the extraction again
<pitti> mvo_: danke!
<pitti> infinity: \o/
<zbenjamin> tedg: already solved, we talked in the coffee break about the UbuntuAppLaunch python typelib
<Mirv> doko: were you interested in gdb bugs as well? my vague memory served me poorly, but the "gcc" bug I mentioned was actually gdb bug #1332484. still there in utopic though, so there's nothing to backport.
<ubottu> bug 1332484 in gdb (Ubuntu) "GDB Demangler crashes in 14.10 and 14.04" [Undecided,New] https://launchpad.net/bugs/1332484
#ubuntu-devel 2014-10-24
<slangasek> smoser: right; so without udev running at that point (as I would expect), I don't see any way that mountall will know that the rootfs is available for mounting
<slangasek> smoser: I think this start condition (start on mounted MOUNTPOINT=/run AND mounted MOUNTPOINT=/) is fundamentally broken and I don't know how it ever worked for you anywhere, and I don't see any way to fix it if your intent is genuinely to block both events
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> (vivid auto-syncs starting shortly)
<crocket> Hi
<crocket> I want to install xubuntu desktop 14.04 on a virtual disk image via packer.
<crocket> Which preseed script do you recommend?
<crocket> packer automatically installs an OS using preseed/kickstart.
<LocutusOfBorg1> can I ask for a sync to vivid of lucene++? bug 1245105
<ubottu> bug 1245105 in lucene++ (Ubuntu) "[please sync lucene++ from debian] Mysteriously FTBFS on the distro builders" [Medium,Confirmed] https://launchpad.net/bugs/1245105
<LocutusOfBorg1> this way I'll be able to fix bugs prior to the freeze in debian :)
<LocutusOfBorg1> 10x
<LocutusOfBorg1> xnox, I think you proposed for a sync in that bug ;)
<LocutusOfBorg1> btw, congrats for the great release! :)
<crocket> Why is pkgsel/include ignored in preseed?
<crocket> openssh-server is not installed after setup.
<crocket> "d-i pkgsel/include string openssh-server build-essential debconf-utils" was ignored.
<crocket> Why?
<mgedmin> why is chromium-browser in utopic older than the version in trusty-updates?
<michele> hi there
<michele> i am on ubuntu 14.10, how do I get the development version? (I tried with 'do-release-upgrade -d' but it says no dev version available)
<geser> either wait till do-release-upgrade supports it again or modify your sources.list yourself
<mitya57> LocutusOfBorg1: lucene++ synced
<LocutusOfBorg1> mitya57, thanks!!!!
<LocutusOfBorg1> let's hope it will build, fox xnox's happynes (and mine of course)
<mitya57> For happiness of boost transition :)
<LocutusOfBorg1> yes of course ;)
<LocutusOfBorg1> wow the development has already started? I see buildd building a lot of packages... I thought some days were required for the import start
<LocutusOfBorg1> wonderful!
<smoser> slangasek, well, i dont know how it works on intel, but it does. with or without initramfs. it works everywhere with initramfs. and works in lxc.
<michele> geser: should I modify my sources.list to match with 15.04 codename?
<smoser> this came about because i wanted to write some status to /run. at first i just did it, but that sometimes failed (in race conditions with /run getting mounted).
<LocutusOfBorg1> is the arch:all now built on amd64?
<smoser> i guess if i have to i drop that and figure some way to try to write to /run
<geser> michele: yes, but if you need to ask then it's probably not a good idea if you switch that early
<geser> LocutusOfBorg1: yes
<coreycb> infinity, can we get ipxe-precise into trusty-updates?  hallyn says "i thought infinity had accepted it out of NEW"  (fyi jamespage)
<crocket> hi
<crocket> Where can I find a proper ubiquity preseed for ubuntu 14.04 trusty?
<jodh> stgraber: hi - could you bump the priority of this livecd-rootfs ppa build please: https://launchpad.net/~ubuntu-foundations-team/+archive/ubuntu/ubuntu-core-system-image/+packages ?
<stgraber> looking
<stgraber> jodh: done
<jodh> stgraber: thanks!
<crocket> Can anyone help me automate ubiquity with preseed?
<crocket> Or can I install xubuntu-desktop in ubuntu server installer?
<cjwatson> Use the server installer for what you want; you can't do package selection in ubiquity preseeding.
<crocket> cjwatson, Where can I find documentations about preseeding ubiquity?
<crocket> I can't find appropraite documentations
<cjwatson> https://wiki.ubuntu.com/UbiquityAutomation is all I'm aware of
<crocket> cjwatson, Then, it seems that ubiquity sucks.
<cjwatson> You're welcome to your opinion, but you are required to be respectful in Ubuntu channels.
<cjwatson> It has design criteria that do not match your requirements.
<cjwatson> So use something else.
<crocket> cjwatson, Can I invoke debian-installer from xubuntu iso?
<crocket> I guess not.
<crocket> Can I use https://help.ubuntu.com/14.04/installation-guide/example-preseed.txt for preseeding ubuntu server 14.04?
<crocket> The file says "for squeeze"
<cjwatson> crocket: It's probably simplest to use the netboot mini.iso.
<cjwatson> http://cdimage.ubuntu.com/netboot/
<crocket> cjwatson, why?
<crocket> cjwatson, I still need to provide preseed for it.
<cjwatson> Because that has the fewest dependencies on any particular set of packages, and you want to select your own.
<cjwatson> debian-installer isn't on the Xubuntu desktop image.
<cjwatson> And of course you need to provide a preseed file.
<cjwatson> https://help.ubuntu.com/14.04/installation-guide/example-preseed.txt should be a good start despite the erroneous header.
<crocket> cjwatson, Does the choice between netboot and iso make a difference in preseeding>
<crocket> cjwatson, Does the choice between netboot and iso make a difference in preseeding?
<crocket> By the way
<crocket> I don't know how to make packer use netboot image.
<cjwatson> Not really, it just means you don't end up with weird restrictions like maybe only being able to request packages that are on the image.
<crocket> cjwatson, Does ubuntu server iso impose such a restriction?
<cjwatson> crocket: I'm in a meeting and can't remember right now.  Feel free to try it.
<crocket> cjwatson, netboot is indeed better.
<crocket> I'm not sure if the same preseed can be applied to netboot as well as standard server iso.
<cjwatson> crocket: They're very similar, so normally you should be able to.  Not promising there are no details to sort out, but you can use it as a nearly perfect starting point.
<crocket> cjwatson, It is slow to download.
<cjwatson> Most people deploying netboot installation on >1 machine use a local mirror.
<crocket> cjwatson, No, I mean the netboot installer is slow to download packages.
<crocket> downloading mini.iso itself is fast.
<cjwatson> You probably want to preseed it to use your local mirror.
<cjwatson> The installer itself is basically just using wget, nothing fancy.
<crocket> wget is slow
<cjwatson> That would be rather dependent on where it's fetching from.  Like I say, preseed a local mirror.
<crocket> hmm....
<crocket> cjwatson, a local mirror of what
<cjwatson> Ubuntu
<sarnold> the archive
<cjwatson> Search for "mirror" in example-preseed.txt
<crocket> Ok
<crocket> "d-i mirror/http/hostname string jp.archive.ubuntu.com"
<crocket> Will I get a xubuntu desktop from netboot?
<sarnold> if you install the xubuntu metapackages
<crocket> sarnold, "tasksel tasksel/first multiselect xubuntu-desktop"
<crocket> Man...
<crocket> https://help.ubuntu.com/14.04/installation-guide/example-preseed.txt is not correct.
<crocket> https://github.com/mitchellh/packer-ubuntu-12.04-docker/blob/master/http/preseed.cfg is.
<crocket> For example....
<crocket> "preseed partman-lvm/confirm_nooverwrite boolean true" is not in the official documentation.
<MosesEX> rww, fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck
<MosesEX> fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck
<MosesEX> yay
<MosesEX> !ops | fuck fuck
<charles> darn darn darn darn darn
<crocket> Man
<crocket> Building a xubuntu desktop from mini.iso is a long journey.
<crocket> Retrieving thousands of packages!!!
<crocket> I'm going to die
<infinity> mvo_: Where do I find you?
<sarnold> infinity: security team room
<infinity> sarnold: Ta.
<ara> slangasek, hey! as part of your SRU duties today, could you please have a look to this pending sru in trusty, please?
<ara> slangasek, https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ubuntukylin-theme
<ara> slangasek, it has been in the queue since July, and it is needed for Kylin
<slangasek> smoser: yes, and I have no idea how or why it works for you; it's working for you /counter to the design/.
<slangasek> smoser: so I'm not going to try to debug the case where it /doesn't/ work when that is consistent with the design
<smoser> slangasek, idont understand why its counter to design.
<smoser> udev starts on virtual-filesystems
<smoser> which should be reachable
<slangasek> virtual-filesystems is not reachable, you're blocking the return of the mounted MOUNTPOINT=/run event
<smoser> yeah, you're right.
<smoser> something must be mounting /run
<dholbach__> mterry_, jodh: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1385444
<ubottu> Ubuntu bug 1385444 in upstart (Ubuntu) "lightm/upstart crash leaves 2 unity8 processes around" [Undecided,New]
<smoser> outside of mountall
<mterry_> dholbach__, neat
<mterry_> thanks
<dholbach> mterry_, jodh: anything missing in the bug report?
<jodh> dholbach: bug updated.
<dholbach> jodh, done
<dholbach> jodh, https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1385464
<ubottu> Ubuntu bug 1385464 in logrotate (Ubuntu) "logrotate fails to run, if status file is corrupt (logrotate running during reboot?)" [Undecided,New]
<tumbleweed> Laney: are you doing anything about distro-info in stable releases? #1381995 looks stalled, and doesn't mention the coupling with a distro-info update
<Laney> tumbleweed: It's not coupled
<tumbleweed> oh, you went with -29
<tumbleweed> duh
<Laney> And no, I haven't chased. :(
<tumbleweed> one less thing in my todo list :)
<ahoneybun> ping
<ahoneybun> darkxst: hello
<darkxst> ahoneybun, hi
<ahoneybun> hows it going ?
<dupondje> Guys. Is there a way to get a package synced into Utopic?
<dupondje> or just a small patch subset allowed?
<dupondje> (package = unetbootin)
<tumbleweed> dupondje: normal SRU rules. Small patches strongly preferred.
<dupondje> cause unetbootin is just useless now, can't create a good bootable usb
<tumbleweed> that does make getting an SRU approved quite easy
<dupondje> just debdiffed the new version vs the current in utopic, and its quite like only that issue that got fixed in the new upstream version
<dupondje> so guess we can just sync then?
<tumbleweed> put some effort into trying to find a minimal patch, first
<Noskcaj> When are the vivid bzr branches expected to be up?
#ubuntu-devel 2014-10-25
<_zerick_> Some shellshock patch just put /usr/sbin/nologin on some system users, is there any really important issue around this users?
<Noskcaj> dupondje, Did you make any progress on unetbootin?
<mitya57> Hi, I got a mail that one of packages failed to upload in Vivid: https://launchpad.net/ubuntu/+source/dhelp/0.6.21+nmu3ubuntu1. Is it a known issue?
<cryptohex> hey
<cryptohex> http://cryptohex.us.to/?page_id=287
<cryptohex> wanna develop AstaraOS together ubuntu
<cryptohex> i invite you to #AstaraOS-devel
<sladen> cryptohex: those instructions seem to be about Fedora
<cryptohex> no sladen
<cryptohex> x64 bit has tool
<sladen> cryptohex: and the URLs are to one of the Fedora download servers
<cryptohex> to convert source code to debian
<cryptohex> it call apt too
<cryptohex> what
<cryptohex> did fedora has rawhide and kernel 3.18-rc1
<cryptohex> not even fedora claim my source code
<sladen> cryptohex: could you give some context.  What *is* AstaraOS?
<sladen> cryptohex: is there an introductory page somewhere?
<cryptohex> AstaraOS is coded by The Most High
<cryptohex> We decoy it and name it fedora
<sladen> cryptohex: and what sort of things does AstaraOS do?
<sladen> cryptohex: and which types are users is it aimed at?
<cryptohex> AstaraOS is exactly same as linux
<cryptohex> with all packages that you never know
<cryptohex> such as blender
<cryptohex> crypto
<cryptohex> satelite kismet
<cryptohex> all there
<sladen> cryptohex: so these packages specialise it---for what types of users is it specialised?
<cryptohex> no all user at all level
<cryptohex> exactly look like fedora
<cryptohex> but this OS We sold to governor
<cryptohex> that's why you keep on heard there is AstaraOS
<cryptohex> but they outsource it to redhat
<sladen> which governor?
<cryptohex> all governor of the world
<cryptohex> governor mean goverment
<sladen> perhaps the first step would be write all this up in an introductory wiki page somewhere
<cryptohex> is part of g20 United Nations Project
<cryptohex> nah just write it for me sladen if you want
<cryptohex> this already been known for long
<cryptohex> We sold 2 version
<cryptohex> one  version which they backdoored again
<cryptohex> they got that shit again
<cryptohex> another version classified is this
<cryptohex> from ip .27
<sladen> perhaps you could write this up on https://plus.google.com/117769961985459927740/posts
<cryptohex> that's 0x71 (xc) Our
<cryptohex> i will
<cryptohex> take alook at http://getintopc.com
<cryptohex> xWindow 10 is windows 10
<cryptohex> and just update is windows 11 now
<cryptohex> this not microsoft too
<cryptohex> is Our code
<cryptohex> look like windows
<cryptohex> exactly  like windows
<sladen> that's wonderful.  This IRC channel is for discussion of development of Ubuntu
<cryptohex> check that website
<cryptohex> i know
<sladen> so at the moment this all sounds a little off-topic
<cryptohex> that's why i invite you to join Us
<cryptohex> you know linux take source code from gentoo
<sladen> I'm sure anyone interested will have the information to do so
<cryptohex> gentoo never publish it anymore
<cryptohex> that's why the package is just the same and the same
<cryptohex> just couple of patch and gui modify
<cryptohex> try the OS you'rself
<cryptohex> find me at #AstaraOS-devel
<cryptohex> if you want
<cryptohex> see ya
<maxb> How very bizarre. I really can't tell if that was a troll or someone very off topic and having difficulty communicating.
 * darkxst thinks cryptohex needs to improve his trolling skills ;) 
<sacarlson> where is a good place to go to find people to test some of my new software?
<sacarlson> they are packaged for ubuntu and mint
<xperia> hi all. could it be that ubuntu has some seriuos problem with multi threading on a Intel Dual Core Processor ?
<xperia> i have installed ubuntu on a Laptop beside Windows7 and i am not able to run multithreaded Programms in Ubuntu anymore in contrary to Windows on the same Laptop Machine. i tryed also to boot Ubuntu with the Boot Options ht=on and acpi=ht but when i do lscpu i dont see more than 1 Thread per CPU even the Processor has HyperThreading and MultiCore Support is enabled in the Bios.
<jtaylor> how many cpus does /proc/cpuinfo show?
<jtaylor> also what exactly does unable to run mean?
<xperia> jtaylor: just one second i am checking the logs to see if there are some strange problems. got a read error "unable to read, broken pipe"
<xperia> jtaylor: cpuinfo show two cores and two siblings. unable to run mean when i have a mutlithreaded programm then at maximum two threads are executed instead of say 8 or 16
<rbasak> xperia: it's up to your program to decide how many threads to use. Sometimes programs look in /proc/cpuinfo (or similar) to come up with a reasonable guess.
<rbasak> It doesn't matter if you only have one core. A program can still start as many threads as it wants.
<rbasak> So you'll need to look into the program you're running to see what it's detecting and how it decides how many threads to run.
<xperia> rbasak: the thing is that it use a simple Parallel For Loop and in ubuntu this Parallel For Loop is not executed in parallel like it executed in windows. in windows the Parallel Loop is executed at once multiple times while in ubuntu there is no parallel execution and for my surprise the whole programm just stall. something is very weired with ubuntu for sure. it is not the programm.
<xperia> i have read that there is some difference between the 64Bit Version of Ubuntu and 32 Bit Version. on my Ubuntu 32Bit Server edition the programms works very well but on my Ubuntu 64Bit Laptop Desktop the Programm does not work like it should.
<sacarlson> xperia: I haven't noticed any difference 64 32.  I just upgraded about 5 weeks ago and all seems to work the same
<rbasak> xperia: written in what language? It may be something to do with the language implementation.
<rbasak> Presumably the implementation is different between Windows and Linux?
<rbasak> You might need to tell it how many threads to use.
<CryoHexy> hey
<CryoHexy> why you call me here guys
<smecin-0x71> ckorn
<smecin-0x71> what's up
<rww> smecin-0x71: Is there something we can help you with?
<smecin-0x71> nothing i heard you want to call me here
<smecin-0x71> what do you want to ask
<rww> smecin-0x71: that's highly doubtful.
<smecin-0x71> ah okay than
<rww> ^ skraito, network problem who released a "distro" that is a Fedora ISO renamed and claims Jesus helped him do it, for anyone wondering about the tone
<NikTh> Hello people.
<NikTh> Upgraded to 15.04 from day one. Today I faced a little problem (proposed repos are enabled-always), with ofono package.
<NikTh> Funny thing here is, I didn't even know the existence of this package. Now I know :)
<NikTh> A .service file is missing and it cannot be installed properly. The weird thing is that NetworkManager does not start properly without ofono. Am I right ?
<Noskcaj> pitti, Should we sync gobject-introspection or is there something that needs waiting for?
<Noskcaj> If a package builds on ppc64le without autoreconf are we ok to start syncing from debian again?
<ari-tczew> cyphermox: do you have a plan for a merge network-manager 0.9.10 from Debian?
<cjwatson> Noskcaj: please preserve autoreconf patches, there may be future ports that need similar
<Laney> Noskcaj: just leave that for us to deal with please
<Laney> (gi)
#ubuntu-devel 2014-10-26
<Noskcaj> ok
<Laney> Noskcaj: Or make a PPA which depends on https://launchpad.net/~laney/+archive/ubuntu/gi/ and fix build failures there
<Noskcaj> i'll see if i can
<Noskcaj> anjuta needs deja-dup's tests fixed (dep chain stuff)
<Noskcaj> Laney, I'll do the aisleriot merge now, sorry for not checking is it was in a *released* upstream git
<Noskcaj> *if it
<HFSPLUS> rww, your a prick
<Unit193> You're*
<Noskcaj> *you're
<Noskcaj> crap
<rww> pretty cool guy*
<Noskcaj> beat me to it ;)
<HFSPLUS> Or do you not know that the unrighteous will not inherit the kingdom of God? Do not be deceived: neither the sexually immoral, nor idolaters, nor adulterers, nor men who practice homosexuality,
<Noskcaj> WUT
<ScottK> Thanks rww.
<rww> No problem. Guy has too much time on his hands and goes on tours around the namespace.
<Noskcaj> Laney, libmediaart can be synced from debian for the gi ppa. also all the mate packages and nemo
<Bluefoxicy> I still want to try running ssh as non-root :|
<Bluefoxicy> too much crap in openssl and openssh with protocol decoding and encryption routines and the like to go wrong as root.
<Bluefoxicy> rww:  what are idolaters?
<Bluefoxicy> I know what adulterers and idlers are.
<Aaron_26> hi everyone im having trouble with adobe air
<Aaron_26> i updated it and now i cant get league of legends to run
<Aaron_26> is there anyways i can downgrade and go back to my previous version?
<Noskcaj> Aaron_26, Try dota? Or on a serious note, ask in #ubuntu
<Logan_> Noskcaj: look what you did
<Noskcaj> ?
<xnox> slangasek: context++
<Noskcaj> laney, gir1.2-wnck-1.0 should be dropped since nothing uses it and has been dropped in debian
<Laney> Noskcaj: I won't keep track of these, if you can make a PPA which depends on mine and upload stuff there I can take those packages
<Laney> or else I'm just going to look at everything next week
<Bluefoxicy> There needs to be a tool to track down phantom space usage.
<Bluefoxicy>  18:30:49 up 1 day,  7:17,  2 users,  load average: 5.23, 1.55, 0.90
<Bluefoxicy> /dev/sda1        56G   45G  6.8G  87% /
<Bluefoxicy> 12G	/ # du -shx /
<Bluefoxicy> 12G of files using 45G of space.  Rebooting clears this.
<Bluefoxicy> No support for LVM2 cache-pool yet?
<Noskcaj-school> Laney: One other thing, should the versioning be the same as the final ubuntu release or ppa specific. Also, how did you copy staight from sid to ppa?
<Noskcaj-school> unrelated, you seem to have made a copy of xfwm4 at https://code.launchpad.net/ubuntu/+source/xfvm4 . Any reason for that?
#ubuntu-devel 2015-10-19
<pitti> coreycb: nova 2:12.0.0-0ubuntu1 consistently fails on ppc64el (http://autopkgtest.ubuntu.com/packages/n/nova/wily/ppc64el/) now -- is that just bad luck due to the flaky test, or did something in the startup scripts change?
<pitti> coreycb: this holds back the new nova and cinder
<pitti> Good morning
<pitti> jamesh: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mediascanner2 has been stuck in -proposed for 24 days already
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> it apparently makes ubuntu-desktop-next, ubuntu-pocket-desktop, ubuntu-touch, unity-scope-mediascanner2 uninstallable
<pitti> I suppose some cleanup is needed there -- mediascanner vs. mediascanner2?
<tjaalton> hrm, every time I change back to my user I get a dialog that prompts the password (org.fdo.accounts.change-own-user-data).. why's that?
<tjaalton> hitting cancel doesn't work
<tjaalton> seems to be polkit-agent-helper-1
<pitti> me too, I now get two screenlocks -- first the classic gnome-screensaver one (new and unwanted), then the lightdm one
<tjaalton> also, configuring software-center ran unattended-upgrades shutdown in the middle of dist-upgrade, that was a bit inconvenient :)
<Mirv> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: final freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv
<dholbach> good morning
<pitti> hey dholbach, wie gehts? happy wily week!
<dholbach> gut geht's - und dir?
<dholbach> and the same to you all :)
<pitti> prima, danke
<pitti> let's let the werewolf howl :)
<jamesh> pitti: sorry, was out getting lunch.  The hold up for mediascanner2 is https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859
<ubottu> Launchpad bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Fix committed]
<pitti> uh, the fix has been stalled for 14 days?
<pitti> well, if you don't need it for wily
<pitti> jamesh: thanks for pointing out
<jamesh> pitti: the short version is that qtubuntu-media has an explicit dependency on the libmediascanner-2.0-3 package despite not actually using that library anywhere.
<jamesh> we realised that the the libmediascanner package hadn't been renamed as part of the gcc5 transition despite it having cxx11 symbols
<jamesh> I missed this depenedency when putting together the landing.
<jamesh> pitti: I made a followup comment on the bug.  The fix Jim mentions doesn't seem to have anything to do with it, which would be why mediascanner didn't get unblocked.
<zzarr> Hello! I have the phablet-tools installed and still I get Unnamed
<zzarr> upps, that's not the entire message
<zzarr> "Are developer tools installed.. 0 ..developer tools are not installed." that's the message
<zzarr> don't mind the "Unnamed" it was in my clipboard for some reason
<seb128> bdmurray, do you know what's the issue with those retracing https://errors.ubuntu.com/problem/ca548de54520eed2ecd28da2c3d9413dd37f8f18 https://errors.ubuntu.com/problem/2ebfd81699a9dba286619318826c3c894a0475a4 https://errors.ubuntu.com/problem/450b4926ce084cb9a2f76872612446fb0ed62084?
<darkxst> seb128, they are probably retracing the ppa
<darkxst> ppa's?
<darkxst> possibly picking up ppa's without ddebs enabled
<zzarr> does QBluetooth work in OTA-7?
<zzarr> or is the apparmor rule not implemented yet?
<Mirv> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: final freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Mirv> zzarr: is there a bug open about that?
<zzarr> Mirv, not that I know about, I don't think it would be considered a bug, it's just not implemented yet (if not in OTA-7)
<Mirv> zzarr: apparmor policy changes would need a bug, a proposal and a check by security team. it won't happen by itself if there's not a bug about it, since there are a lot of apparmor denials happening and there's no process on checking all of those and doing something about those.
<Mirv> zzarr: I believe https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu is the correct package to file against
<Mirv> mentioning at least how the apparmor problem is triggered and what does it look like
<zzarr> I'll file a rapport if it's not fixed in the OTA-7 release which will be released today
<seb128> darkxst, thanks for the suggestion, could be
<LocutusOfBorg1> Unit193, can you please look at debian bug 802143?
<ubottu> Debian bug 802143 in virtualbox-ext-pack "virtualbox-ext-pack: doesn't use invoke-rc.d - leaves processes running after purge" [Serious,Open] http://bugs.debian.org/802143
<Laibsch> wgrant, cjwatson, infinity: I'd like to revisit discussion http://irclogs.ubuntu.com/2015/03/18/%23ubuntu-devel.html#t05:33 http://irclogs.ubuntu.com/2015/03/18/%23ubuntu-devel.html#t11:42 AKA "allow bug-control team to accept or reject release pocket nominations in LP"
<Laibsch> I'd hope it could be implemented soonish. Once the consensus is there (which I think it was half a year ago), it's more or less simply the flip of a bit in permissions.
<Laibsch> While we are at it, would some kind soul please accept nomination for trusty for bug 1287424 and if possible even move along the SRU?
<ubottu> bug 1287424 in mysql-workbench (Ubuntu) "Cannot install mysql-workbench with mysql-server 5.6 or mariadb" [High,Fix released] https://launchpad.net/bugs/1287424
<Laibsch> I already have other tickets for that software I'd like to get an SRU for eventually.
<cjwatson> I've accepted the nomination
<Laibsch> awesome. thank you, cjwatson
<cjwatson> I think the next step in that discussion was:
<cjwatson> <wgrant> infinity: I don't think that there would be serious issues with letting bug supervisors add series tasks without going through nominations, now that task deletion exists.
<cjwatson> Laibsch: I think it's something like http://paste.ubuntu.com/12860146/, but um.  May take a while to sort out all the details there.
<Laibsch> Wow, actually quite involved! I thought it was simply to set a permission bit in an authentication database table and not this much code change.  Well, I hope it can land soon.
<cjwatson> Laibsch: No, if you want to think of it this way it's more that several permission bits are currently conflated into one in an awkward way.
<cjwatson> So you can see why it didn't happen straight away ...
<doko> seb128, do you know the background why packagekit 0.9.x was pulled from proposed? I read https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1470655 but this doesn't have much background, and I can't find any in closed bug reports
<ubottu> Launchpad bug 1470655 in packagekit (Ubuntu) "Update to PackageKit 1.0" [Wishlist,Triaged]
<seb128> doko, because it's abi/api incompatible with 0.8 and aptdaemon (and maybe others) needed to be ported and Riddell (who did the update) preferred to revert
<seb128> doko, why?
<doko> seb128, because I was bitten by it, with -proposed enabled. is there a plan to do the 1.0 update for 16.04?
<seb128> doko, we are looking at doing it yes
<seb128> doko, I made aptdaemon depends on packagekit (<< 0.9) that should have forced apt to tell you there is a problem to resolve
<seb128> e.g remove aptdaemon or downgrade packagekit
<seb128> also that's the kind of issues than proposed users might hit
<jdstrand> Mirv: fyi, I wouldn't say there is no process. people need to file bugs. afaik, all the denials I'm aware of have bugs with comments on what needs to be done to fix them. some are policy adjustments, others are platform/sdk adjustments
<jdstrand> and no one has mentioned anything about bluetooth yet
<jdstrand> (to me at least-- in terms of policy)
<jdstrand> so yes, please file a bug
<jdstrand> (oh, and for bugs that need policy adjustments, I don't know of any that are open-- I definitely try to stay on top of those)
<smoser> Odd_Bloke, did you get what you needed wrt uefi images ? just now looking at week-old backscrolls
<smoser> fwiw: ppc64el boots with qemu-system-ppc64: https://gist.github.com/smoser/7a07d9f8929dc11b4ed9
<Odd_Bloke> smoser: Yeah, I think I did; thanks for the pointer to that gist!
<doko> seb128, Laney: I was looking into cross building openjdk-8/9, and seeing that the gnome stack isn't yet completely multi-arched. is this something we could look at for 16.04?
<seb128> it would be good to have, unsure who would be interested to work on that though
<Laney> feel free
<Laney> via debian wherever possible
<seb128> hum
<seb128> who broke launchpad bugs duplicates? ;-)
 * seb128 looks at wgrant and cjwatson
<seb128> bug_id: got 'unicode', expected int: u'1507332'
<seb128> when trying to mark a bug duplicate of another one
<cjwatson> seb128: bug with an oops id please, I'll track it down
<seb128> cjwatson, I don't get an oops
<cjwatson> seb128: what exactly are you doing?
<seb128> just that message in red
<seb128> opening https://bugs.launchpad.net/ubuntu/+source/gnome-system-log/+bug/1500806
<ubottu> Error: malone bug 1500806 not found
<seb128> click on "mark as duplicate" on the right
<seb128> I get the popup dialog to enter a bug
<cjwatson> oh
<seb128> I write 1500806
<seb128> and get the error I just copied in red
<cjwatson> it's a regression from the fix for bug 581748
<ubottu> bug 581748 in lazr.restful "10.10 milestone name corrupted in JS: 10.1" [High,Triaged] https://launchpad.net/bugs/581748
<cjwatson> you can work around it by middle-clicking the "mark as duplicate" link so that you get the HTML form rather than the AJAX one
<cjwatson> I'll see about an urgent fic
<cjwatson> *fix
<seb128> cjwatson, https://bugs.launchpad.net/launchpad/+bug/1507604
<ubottu> Launchpad bug 1507604 in Launchpad itself "bug duplicate dialog error, "bug_id: got 'unicode', expected int:"" [Undecided,New]
<seb128> cjwatson, thanks
<cjwatson> thanks
<seb128> cyphermox, is bug #1507330 known?
<ubottu> bug 1507330 in ubiquity (Ubuntu) "installer detail pane not opening" [Undecided,New] https://launchpad.net/bugs/1507330
<cyphermox> seb128: now it is.
<seb128> cyphermox, that's why I was pointing it ;-)
<seb128> cyphermox, I fixed a similar bug in apturl on friday, had to move the height_request property from the textview to the srolledwindows
<seb128> unsure what changed, I guess it's new GTK...
<seb128> that one might be similar
<cyphermox> if so, yuck
<doko> Laney, mediascanner2 is still blocked on qtubuntu-media, LP: #1500859
<ubottu> Launchpad bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Fix committed] https://launchpad.net/bugs/1500859
<Laney> see #ubuntu-touch
<seb128> cyphermox, totally non tested/random try, but maybe http://paste.ubuntu.com/12861228/
<seb128> cyphermox, if you know how to easy spawn the ubiquity UI to test
<cyphermox> bleh
<cyphermox> yeah, I know how
<cyphermox> worth a try I guess
<seb128> is there an easy way?
<seb128> out of download an iso, boot it in live mode and test from there
<cyphermox> yeah, I run an iso and change what I need
<cyphermox> ah
<seb128> lol
<cyphermox> I usually always have the isos ready, downloaded
<seb128> I'm downloading one
<seb128> I can test the patch if you are busy on other things
<seb128> just needs some 20 minutes or so
<cyphermox> it's fine I already was preparing an upload, and already had a vm with ubiquity spun up on it
<seb128> great
<cyphermox> almost.
<cyphermox> but not quite.
<cyphermox> oh wait, I did the change wrong
<cyphermox> yay
<seb128> ?
<cjwatson> seb128: I've asked for a rollback of the last LP deployment
<seb128> cjwatson, thanks
<cjwatson> Having trouble reproducing this in the test suite, but I can absolutely see it on qastaging :-/
<cjwatson> And setting a breakpoint on the relevant bit of JS hangs firefox
<seb128> cjwatson, is rolling back cheap? because the bug is easy to workaround so I guess if it's fixing today having it around for a few hours is not the end of the world
<cjwatson> Awesome
<cjwatson> seb128: Cheap enough and I'm not sure how long it will take me to fix
<seb128> k
<cjwatson> Since my first three attempts to reproduce in tests haven't gone anywhere yet
<seb128> dpm, pitti, wgrant, do you know why https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports is empty (out of the manual upload I just did)?
<seb128> the .po should be imported no?
<seb128> https://launchpadlibrarian.net/221324437/buildlog_ubuntu-wily-amd64.evolution_3.16.5-1ubuntu2_BUILDING.txt.gz has a translations tarball
<cjwatson> seb128: https://code.launchpad.net/~cjwatson/launchpad/fix-bug-picker-search/+merge/274910 and singing the I-hate-JavaScript song.  Hopefully we can roll this out again tomorrow
<seb128> cjwatson, nice, thanks for fixing it ;-)
<kirkland> rbanffy: nice :-)
<rbanffy> kirkland, ?
<kirkland> <rbanffy> In any case, byobu users who use mu font (all three of them, me included) will be happy to know I added a â« in late May.
<rbanffy> kirkland, :-)
<apw> rsalveti, yo, just looking at your rtl8812au upload, there are a number of files in here without clear copyright information though your copyright claims they are GPLv2, do you have some suplementary information to that effect ?
<hallyn_> xnox: did you see any problems in https://mentors.debian.net/packages/my ?
<hallyn_> uh, https://mentors.debian.net/package/netcf
<rsalveti> apw: I saw a few that were indeed missing, but minor headers and iirc (last time I check), those files were also in the upstream kernel (under another driver)
<xnox> hallyn_: i did not but have run out of time to upload it.
<xnox> hallyn_: i've set a reminder to do it tonight, when i am back home.
<xnox> sorry about the delay.
<rsalveti> apw: I can cross check again, but most of the ones that were missing are not even required by the build
<rsalveti> so they can be removed
<hallyn_> xnox: gotcha, thanks
<rsalveti> just didn't remove because the tarball is directly from the vendor
<apw> rsalveti, i'll see if i can confirm they are in the upstream kernel
<rsalveti> the hal ones under OUTSRC-BTCoexist are probably not, and not used during the build
<rsalveti> so I can upload without them
<rsalveti> let me check again which files are actually used
<apw> rsalveti, that is the sketchiest directory for use
<apw> suew
<apw> sure
<rsalveti> apw: in this case (since it comes from the upstream tarball), should I upload a new orig tarball without them or just make a patch to remove them?
<apw> rsalveti, we don't want them in the archive, so repacking +dfsg stylee seems appropriate
<rsalveti> alright
<bdmurray> seb128: I'll have a look at those crashs
<seb128> bdmurray, thanks
<gdfuego> I just filed a fun bug in Precise
<gdfuego> https://bugs.launchpad.net/ubuntu/+source/psmisc/+bug/1507681
<ubottu> Launchpad bug 1507681 in psmisc (Ubuntu) "killall with 65 arguments kills more than expected" [Undecided,New]
<bdmurray> seb128: One of the retraces failed in the following way - http://pastebin.ubuntu.com/12863467/. So apport did not return a crash signature.
<bdmurray> seb128: that's true for both the libunity crash and the trust-store crash. the missing debug symbol messages are incidental.
<seb128> bdmurray, the one you pastebined has an useful stacktrace though
<seb128> just missing the first symbol
<bdmurray> seb128: I think the any missing symbol is cause for apport to return None for a crash signature.
<seb128> bdmurray, oh, ok, do you know if that's by design or a bug?
<kdub> my thinkpad (x201 tablet) is having a tough time booting with the daily live usb stick made with usb-creator-gtk... could this be a uefi problem maybe?
<bdmurray> seb128: I think its by design - https://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/report.py#L1233 "If StacktraceTop has unknown functions or the report lacks any of those fields, return None.
<rsalveti> apw: should be all good now, let me know if you need any other info
<seb128> bdmurray, I think the intend was to avoid having one function being a signature
<seb128> but maybe pitti can confirm
<seb128> it feels like in that case we could do better, because ?? followed by 4 detailed function is useful
<bdmurray> seb128: I reported bug 1507711 about this.
<ubottu> bug 1507711 in Apport "crash_signature should(?) be created for stacktraces missing the first symbol" [Undecided,New] https://launchpad.net/bugs/1507711
<seb128> bdmurray, thanks
<infinity> seb128: Were you handling the component-mismatches promotions from your seeding, or shall I?  (I don't want to double-override).
<seb128> infinity, I did it
<infinity> seb128: Kay.  I'll wait for the publisher to catch up and look at the result.
<slangasek> hrm.  I just got email from google saying that a recently used device logged in insecurely to my google account, and it points to my IP address. Is Online Accounts not up to speed with current login protocols?
<ogra_> slangasek, you usually get that if you connect a device for the first time ...
<ogra_> well, i do
 * xnox gets that every time i login from an annonymous window. or e.g. logging out with one google account, to relogin with a different one.
<slangasek> ogra_: it's not a new device, it's my existing laptop
<slangasek> and I've never had his error before
<ogra_> token expired ?
<slangasek> pitti: http://autopkgtest.ubuntu.com/packages/p/python3.4/trusty/ results regressed between .1 and .3, with no relevant code changes.  Same tests pass in package build.  Could this be related to the recent lxc profile questions?
<Unit193> Heh, /var/lib/dpkg/info/keyboard-configuration.postinst: 1: /var/lib/dpkg/info/keyboard-configuration.postinst: udpkg: not found
#ubuntu-devel 2015-10-20
<pitti> Good ... ungodly hour of the day
<sarnold> hey pitti :) a pal in duesseldorf went to bed just two hours ago..
<sarnold> you're up entirely too early even by your usual standards :)
<pitti> yeah, I know.. I've been tossing around for an hour already, can't sleep
<sarnold> I hate that :(
<pitti> slangasek: you mean the regressions on i386/amd64? as arm and ppc always failed; that can't be LXC, as these are full VMs
<pitti> slangasek: "OSError: [Errno 14] Bad address" in the two test.test_socket.Recvmsg* tests, hmm; doesn't immediately tell me anything
<pitti> should even be the same kernel (trusty) on build and test
<pitti> weird that .2 has never been run
<slangasek> pitti: hmm ok.  I'm inclined to pass them to get this python3.4 SRU out, given that they passed on the package build; unless you see a reason not to
<slangasek> sadly, one of the SRU-linked bugs is specifically about testsuite enablement
<slangasek> (LP #1264554)
<ubottu> Launchpad bug 1264554 in python3.4 (Ubuntu Trusty) "python3.4 autopkg test failures" [High,Fix committed] https://launchpad.net/bugs/1264554
<sunweaver> robert_ancell: hi!
<sunweaver> I have just seen that you requested access to collab-maint a while ago.
 * sunweaver writes with his Debian Frontdesk hat on.
<sunweaver> You normally need a DD or a DM to sponsor such requests.
<sunweaver> As I have seen various portions of your code (actually, in one of my upstream projects I have started forking Unity Greeter... Ã¤hemm...) I can imagine signing that request for you.
<sunweaver> If you have a DD around you, who could send that mail, that would be more appropriate, though.
<pitti> slangasek: FWIW, this reproduces perfectly well in local qemu, so it's not related to the production environment
<slangasek> pitti: ok.  does it happen to also be reproducible with the ~14.04.1 package that previously passed?
<hyperair> huh, collab-maint requires DD/DM sponsorship now?
 * hyperair thought anyone could join collab-maint
<pitti> slangasek: that's not published anywhere, but I'll re-run, fish out hte debs from LP and downgrade; hang on
<Unit193> hyperair: https://lists.debian.org/debian-devel-announce/2015/08/msg00008.html
<hyperair> i see
<hyperair> thanks
<Unit193> sure thing.
 * hyperair should pay more attention to d-d-a
<Unit193> Not actually subscribed, I follow via archives.
<pitti> slangasek: nope, they fail the same way; kernel or underlying lib change?
<slangasek> not too many other libs underneath
<dholbach> good morning
<tjaalton> is there a bug about nfs mounts not getting mounted on wily?
<tjaalton> just installed a fresh machine and seeing this
<tjaalton> seems like a race
<tjaalton> trying to mount before it can resolv the server hostname
<seb128> tjaalton, I didn't see one, doesn't mean there isn't though ;-)
<seb128> dpm, pitti, wgrant, saw my question yesterday about evolution translations?
<wgrant> seb128: Are you sure they haven't been imported and pruned already?
<dpm> morning seb128
<pitti> seb128: sorry, missed it
<dpm> sorry, I didn't have the chance to look at it last night
<seb128> wgrant, unsure
<pitti> seb128: rÃ©pÃ©ter SVP?
<dpm> seb128, when did you do the manual import?
<seb128> wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports has no .po import listed
<seb128> pitti, ^ why is that not importing the .po from the source
<wgrant> https://translations.staging.launchpad.net/ubuntu/wily/+source/evolution/+imports
<pitti> the "failed" you mean?
<seb128> no
<wgrant> There were some pot autoimports on the 15th
<seb128> it doesn't import the actual upstream translations
<seb128> I mean the translations
<wgrant> What are the paths in the tarball?
<seb128> not the template
 * wgrant goes digging.
<seb128> the template is fine
<seb128> but e.g fr misses some 570 strings
<seb128> where the package has the translations
<dpm> seb128, hm, there still seem to be 2 templates. For which one did you do the manual import, for 'evolution' or 'evolution-3.16'?
<seb128> dpm, I tried to upload a fr.po yesterday, but apparently nowadays launchpad rejected those if they are not tagged
<seb128> dpm, I didn't do manual imports
<dpm> seb128, I'll removed the '*-3.16' one now
<seb128> thanks
<seb128> there were 2 templates in the import queue
<seb128> and I accepted them
<wgrant> Downloading the tarball to investigate, will be a few minutes.
<seb128> for some reason the default template name was -3.16
<seb128> wgrant, thanks
<dpm> yeah, it's a bit of a bummer that the template name is versioned, that doesn't go well with LP :/
<dpm> we need to fix it every single release
<dpm> same for e-d-s, IIRC
<seb128> yeah, but we had fixed it
<seb128> we discussed that in september if you remember
<pitti> seb128: would it perhaps be more practical to patch evo to use an unversioned template name? or too much to patch?
<tjaalton> uh, default crypted install creates a ridiculously small /boot (237M)
<seb128> pitti, I guess we could
<pitti> meh, bluez fails to install in a VM now
<dpm> that'd help us in not having to manually do the changes every release in LP, then the templates would be imported correctly on a new release and avoid the duplicate templates
<pitti> bluetoothd[1640]: Failed to access management interface
<pitti> bluetoothd[1640]: Adapter handling initialization failed
<pitti> and that fails apt
<dpm> wgrant, I'm going to move the -3.16 template out of the way and fix the path on the 'evolution' template to point to 'po/evolution-3.16'
<wgrant> dpm: Be wary of the POs, though.
<wgrant> Those paths must match also, and they're not versioned.
<wgrant> So if the current -3.16 template's POs have stolen the paths, we're in trouble.
<pitti> ah, bug 1506774
<ubottu> bug 1506774 in bluez (Ubuntu) "package bluez 5.35-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1506774
<dpm> wgrant, not sure if they have, if they have, then I'll just have some fun doing manual .po file approvals :/
<wgrant> I wonder if the POs might have been skipped because they would have tried to import into the disabled template, or something.
<seb128> dpm, well the .po are not in the queue atm
<wgrant> There's nothing else obvious wrong.
<dpm> but it seems they might not have, as the Catalan translation for -3.16 is empty
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server/+imports
<seb128> I guess that is buggy as well?
<dpm> oh, the path is already 'po/evolution-3.16.pot' on the 'evolution' template, so it seems we had fixed it indeed
<seb128> but that one only has one template
<dpm> so I think the issue is that I still hadn't moved the 'evolution-3.16' template out of the way, so LP was seeing two differently named templates with the same path
<wgrant> dpm: Where did you put the evolution-3.16 template?
<wgrant> I can't find it now.
<dpm> wgrant, I haven't put it anywhere yet
<dpm> I was going to, though
<dpm> wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution-3.16/+edit
<wgrant> Oh it helps if I don't typo it.
<dpm> :)
<dpm> wgrant, so I'm going to do this now with this template ^ https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration#Moving_templates_out_of_the_way
<wgrant> Hm.
<wgrant> I'm a little surprised that it allows them both to have the same path...
<wgrant> Yeah, moving it away is "fine" for now.
<dpm> wgrant, seb128, done. I assume the next upload (manual or via packages) should import all translations fine. Looking at e-d-s now
<seb128> dpm, before yesterday only one template was listed, I seemed to have created the other one by accepted  the .pot in the queue, but translations were not imported, did you change something wrong on the non -3.16 template?
<dpm> seb128, for which package now, evolution or e-d-s?
<seb128> evolution
<seb128> e-d-s I didn't touch
<seb128> so it's in a less confusing state
<dpm> me neither
<seb128> like no duplicate template there
<dpm> seb128, I think here's what happened:
<dpm> - evolution was fine: it had the right template name ('evolution') and the right path 'po/evolution-3.16'
<dpm> - On manually approving the 'evolution-3.16' template in the queue, LP created the second, duplicate template, and named it 'evolution-3.16'
<dpm> - Both templates had a path of 'po/evolution-3.16.pot', that's what LP looks at when importing the PO files and deciding where they should go
<dpm> - On seeing that the evo source package had two templates with the same path, it didn't know what to do
<dpm> that's my guess
<seb128> k
<seb128> well that can't be the issue with e-d-s
<dpm> In general it's best not to manually approve - it might take a while, but LP will do the auto-approval
<seb128> and that one also fails to import translations
<dpm> yeah, I don't know what's up with e-d-s
<dpm> it looks fine as far as I can tell
<seb128> :-/
<dpm> just one template, with the correct path
<seb128> evolution was in the same state before I screwed up things yesterday
<seb128> so I guess up for wgrant to debug on the launchpad side
<dpm> let me try to do a manual upload myself
<pete-woods> pitti: morning. I've got yet another bugfix for the network-manager template here: https://github.com/martinpitt/python-dbusmock/pull/16/files
<dpm> wgrant, I tried to manually upload translations to the evolution template and got OOPS-7aeb70f9bcfa7221a50373627e365a97 - could you tell me if the upload was nevertheless successful, or should I do another upload?
<wgrant> dpm: That was a timeout on the browser upload. You'll need to retry.
<dpm> ok, retrying
<dpm> still timeout :(
 * dpm tries chromium
<dpm> wgrant, hm, tried it with Chromium, similar result, but this time the upload was finished (Chromium showed me the percentage), but got LP "Timeout error" with OOPS-967981d90913c8f6e9b989c83b5fbdcd
<wgrant> dpm: I suspect it's unlikely that such a large upload (many files, mostly) will succeed :/
<dpm> wgrant, hm, so that effectively means that we cannot do manual translation uploads anymore? (i.e it's not uncommon for packages to have 40+ po files)
<wgrant> dpm: This hasn't changed since 2011 or so.
<dpm> wgrant, I've done manual uploads in the past, although the last one I did might have well been 1 or 2 years ago
<wgrant> How many files in total does the tarball contain?
<dpm> let me check
<wgrant> The total data size also matters somewhat.
<dpm> wgrant, 96 files, ~14MB
<wgrant> Hmm.
<dpm> well 14MB compressed, that is
<wgrant> dpm: I can try increasing the timeout once sysadmins are a bit less tied up.
<dpm> wgrant, or happy to provide the .tar.gz file if the translations can be uploaded in any way. seb128, I assume you tried a manual upload because we cannot do uploads so close to the release date, was your tarball as big as mine and did it not time out?
<seb128> dpm, I only tried to upload the fr.po but at first it's because I though french translations were outdated for some reason
<seb128> dpm, wgrant, what's the next step to figure out why e.g e-d-s is not importing translations from package uploads?
<wgrant> dpm: There's no other way.
<wgrant> seb128: I need to find time to look through the uploader to work out why the files are being skipped.
<wgrant> They don't meet the obvious blocking criteria.
<pitti> pete-woods: ah, thanks! note that wily is in final freeze, this might not land any more
<dpm> seb128, oh, I can just do the fr.po upload for test, that shouldn't time out
<seb128> dpm, I could as well, I just need to add a tag so launchpad doesn't reject it
<seb128> since apparently there was some feature added to block upload of non-launchpad-exported .po files
<seb128> or import of those rather
<seb128> dpm, but I'm not really interested in fixing french only
<dpm> seb128, yes, or if you upload it in a tarball together with the .pot file it should work, though
<dpm> seb128, well, but at least that will confirm whether the deduplication of the template worked
<seb128> dpm, e-d-s has no template duplication and the same issue
<seb128> but yeah
<dpm> seb128, yeah, as I said, after looking at it, I don't know what I could possibly do with e-d-s, but it'd be good to confirm if evolution uploads are workin
<dpm> g
<dpm> :)
<seb128> +1
<dpm> seb128, wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports - I uploaded the 3 files, will be watching in the next couple of hours if the importer does its work
<pete-woods> pitti: the stable overlay ppa is open for both vivid and wily now
<pete-woods> so you can land it there for both series?
<pete-woods> I think the plan is then to migrate all the wily packages from the PPA into X
<infinity> sitter: Around?
<sitter> infinity: yes
<infinity> sitter: Looking at your ubuntu-release-upgrader upload.  If you're hitting a 403 for the release notes, that might be a bug on our end? :P
<infinity> sitter: Do you have the URL it's reuqesting?
<infinity> requesting, too...
<infinity> Oh, or it might be the new python-versus-urllib mandatory ceritificate verification thing, if it's https.
<sitter> infinity: http://archive.ubuntu.com/ubuntu/dists/wily/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html?lang=en_US&os=ubuntu&ver=15.10
<Laney> BTW I accepted it but will leave it blocked in the hope that we can fix it this end
<infinity> sitter: urllib gets a 403 on that?  That makes no sense...
<sitter> tell me about it :P
<rbasak> hallyn_: you just need a DD to sponsor your netcf FTBFS fix, right, and then we can sync it in?
<sitter> I also tried with the vivid URL and that also yields 403, so I am not convinced this actually ever worked (I think I switched to the HTML URI in vivid)
<rbasak> hallyn_: maybe doko can help with that if xnox is unavailable?
<sitter> infinity: it should be 100% reproducible with python3-pyqt5 installed and sudo do-release-upgrade -m desktop -f DistUpgradeViewKDE
<Laney> In [9]: urllib.request.urlopen('http://archive.ubuntu.com/ubuntu/dists/wily/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html?lang=en_US&os=ubuntu&ver=15.10').code
<Laney> Out[9]: 200
<sitter> sudo do-release-upgrade -m desktop -f DistUpgradeViewKDE -d even
<sitter> http://paste.ubuntu.com/12875585/
<sitter> oh god
<sitter> Laney, infinity: it's apt-cacher intercepting and mangling the request
<Laney> ...
<infinity> sitter: Right, deleting from proposed then? :P
<sitter> infinity: yes please
<sitter> infinity: also SRU 1:15.04.14.3 from vivid-proposed
<infinity> sitter: Both gone.
<sitter> thanks and sorry for the noise
<Laney> sitter: Might be worth an apt-cacher bug though
<sitter> yup, but 1507953
<sitter> bug 1507953
<ubottu> bug 1507953 in apt-cacher-ng (Ubuntu) "cacher mangles release notes queries when set as proxy" [Undecided,New] https://launchpad.net/bugs/1507953
<rsalveti> apw: were you able to check my latest upload for rtl8812au? license should be fine now
<apw> rsalveti, ahh not seen it will have a look
<rsalveti> apw: cool, thanks
<dholbach> Laney, could it be that http://reqorts.qa.ubuntu.com/reports/sponsoring/ is broken?
<Laney> ES KANN NICHT SEIN
<Laney> ah crap :)
<Laney> can you run it manually and see what happens?
<Laney> I changed to the devel api - maybe needs re-authing?
<dholbach> hum
<Laney> I thought I checked after pushing that it was working...
 * Laney sucks
<dholbach> no you don't
<apw> rsalveti, i assume you have a device and have tested the resulting binaries from this source ?
<jamespage> pitti, I think we can drop golang-go.net-dev source package - the new source package has a transitional package for golang-go.net-dev
<dholbach> Laney, "No such source package: 'ubuntu-cve-tracker'."
<Laney> huh
<Laney> let me look at this
<rsalveti> apw: yup, that's how I'm accessing internet here :-)
<pitti> jamespage: oh, indeed; I'll remove the old one then, thanks
<jamespage> pitti, np - thankyou
<pitti> jamespage: done
<infinity> rsalveti: Accepted.
<rsalveti> infinity: apw: awesome, thanks
<infinity> rsalveti: Sorry about the delay but, hey, I promised it would make the release, and here you are. ;)
<rsalveti> infinity: haha, indeed, thanks man
<Laney> dholbach: hopefully fixed...
<rsalveti> infinity: just missing the bin new approval now :-)
<Laney> dholbach: ya, it's up to date
<Laney> and quite large :/
<Laney> part of that is because my new code picks up more branches now
<dholbach> Laney, does that mean I should run it a bit less often now?
<Laney> dholbach: nope, it means we should clean out more stuff
<dholbach> right
<Laney> I mean large in terms of number of items
<dholbach> I'll send a mail to u-devel
<dholbach> asking for some last-minute cleanup and stuff we want in as opposed to getting it in via sru
<rbasak> Is there a component-mismatches report for movements from main to universe?
<rbasak> python-jingo is in main, but AFAICT isn't seeded or pulled in by a seed.
 * rbasak isn't sure what he's missing
<cjwatson> That's kind of what the component-mismatches report is.
<rbasak> That's what I thought, but I don't understand why python-jingo doesn't appear in there.
<cjwatson> It's a build-dependency of python-django-compressor.
<rbasak> But http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-jingo/python-jingo doesn't seem to go any further than that - doesn't end up at a seed?
<cjwatson> That'd just be a bug in the rdepends output
<cjwatson> Follow to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-django-compressor/
<cjwatson> Then http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/rdepends/python-django-compressor/python-compressor gets you a seed
<rbasak> Ah OK, that is what I was missing. I assumed that no rdepends output meant that python-django-compressor was in universe.
<rbasak> Thanks.
<hallyn_> rbasak: i think xnox did it last night, but thanks
<xnox> hallyn_: well, and it was rejected cause i uploaded the old one, instead of the new one.
<xnox> hallyn_: i re-uploaded again this morning
<xnox> hallyn_: you should have accept email about it.
<hallyn_> xnox: thanks.  yeah i saw that reject last night, but this morning saw the package list on mentors was empty, so assumed you'd pushe dit
<rbasak> hallyn_: thanks. Not sure what that means to fix the FTBFS in Ubuntu though. Is that upload suitable to sync during final freeze?
<xnox> hallyn_: Serge Hallyn <serge.   hallyn@ubuntu.com>,
<xnox> netcf_0.2.8-1_source.changes ACCEPTED into unstable
<hallyn_> rbasak: did i not push a fix for the ftbfs to ubuntu?
<hallyn_> maybe i didn't, as i was waiting fo rhtis
<xnox> hallyn_: and https://tracker.debian.org/news/720083 with as almost built everywhere https://buildd.debian.org/status/package.php?p=netcf
<rbasak> hallyn_: not that I'm aware of but maybe I'm missing something?
<hallyn_> rbasak: prolly not.  i can push the minimal fix.
<rbasak> OK. Thanks!
<xnox> hallyn_: so... are you ready to be a DM with upload right to the package just by yourself in debian?
<hallyn_> xnox: was replying to email.  i am, i had asked slangasek about that for netcf+cgmanager
<hallyn_> (but he's pretty busy :)
<xnox> hallyn_: yeah interviewing people
<hallyn_> heh
<xnox> lol
<hallyn_> suppose it could be worse, i.e. if no applicants
<xnox> hallyn_: i guess i should sign your key as well to get you into the debian web of trust.
<xnox> hallyn_: well, i don't know. looking at canonical job feed the foundation postings seems to be ever open.
<hallyn_> xnox: at fosdem maybe?
<xnox> hallyn_: i think i said i would, but i didn't i don't think
<xnox> hallyn_: my main key is offline, so i'll need another location based reminder to do it.
<hallyn_> not sure what that means -s end you a postcard? :)
<pitti> dholbach: uh, MPs from 2012 ;)
 * pitti cleans up a bit
<dholbach> time to reject :)
<dholbach> thanks pitti!
<bdmurray> pitti: there seem to be some outstanding language-pack SRUs - https://launchpad.net/ubuntu/+source/language-pack-ja. infinity mentioned you usually take care of them...
<pitti> bdmurray: yes, these are the ones that didn't get tested, so we never published them (https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA)
<bdmurray> pitti: bug 1311396 mentions testing ja.
<ubottu> bug 1311396 in language-pack-ug (Ubuntu Precise) "broken translations results in traceback in new release notification" [High,Triaged] https://launchpad.net/bugs/1311396
<pitti> dholbach: what was that fix, btw? all those MPs like https://code.launchpad.net/~soren/nova/essex-stable-catchup/+merge/108049 are *not* against ubuntu
<pitti> bdmurray: ah, thanks!
<Laney> pitti: It lists all merges that uploading teams can do
<Laney> so ~ubuntu-server-dev has to take care of this MP
<pitti> Laney: that seems a bit excessive
<Laney> well it's a merge proposal that has been ignored for years
<pitti> Laney: well, maybe it's just because of all the old cruft and it'll get useful in the future
<Laney> which is pretty crap for the person that proposed it
<Laney> at least now it is in a list
<pitti> *nod*
<pitti> but most sponsors won't be able to actually do such a thing
<pitti> i. e. merge into a non-ubuntu branch
<pitti> it woudln't actually land anywhere
<pitti> and most folks won't have commit rights either
<Laney> well their review is requested
<Laney> one way to close it is to deal with that one way or another
<Laney> It's still tied to upload rights - i.e. core-devs should be able to take care of the MPs there
<Laney> should be more useful after we clean up all these old ones at the top
<Laney> jamespage: can your team help us to clear out the ancient openstack MPs that I just made come up on http://reqorts.qa.ubuntu.com/reports/sponsoring/ maybe? :)
<Laney> or should we mass-reject them all, or something?
<pitti> Laney: I'm going through invidividually ATM
<pitti> Laney: and check if they were already uploaded through some different means, are obsolete, etc.
<pitti> e. g. the ubuntu-server test cases have some fairly recent commits by cyphermox; not sure if that is still a thing, I thought we moved everything to autopkgtest
<pitti> but I'd keep these for now
<Laney> yeah, we have those still for the iso smoke testing
<Laney> pending -> current thingy
<cyphermox> pitti: that still was used for the pending-current job
<cyphermox> yep
<cyphermox> and I intend to fix it harder during the X cycle.
<pete-woods> pitti: found another bug in the settings management of the NM template: https://github.com/pete-woods/python-dbusmock/pull/7/files
<pete-woods> (hmm, I think I stacked the changes badly :$)
<pitti> Laney: ah, e. g. https://code.launchpad.net/~adri2000/python-heatclient/bash-completion/+merge/254921 is the first that actaully seems good and relevant :)
<Laney> sorry for the noise :(
<Laney> we would have not missed e.g. https://code.launchpad.net/~logan/ubuntu-gnome-default-settings/eog-override/+merge/259707 if we had this earlier
<pitti> Laney: yeah, seems good overall -- we just need to get the relevant teams to actually look at this
<Adri2000> pitti: interesting, I completely forgot about that :)
<xclaesse> mardy, after upgrade 15.04->15.10 my google account disappeared from evolution
<xclaesse> mardy, it's still configured in UOA
<jamespage> Laney, yeah - I'll look
<Laney> jamespage: thanks - pitti said he'd closed a load too
<mardy> xclaesse: is evolution enabled there (in the account)?
<xclaesse> mardy, yes
<xclaesse> mardy, just rebooted now, and my account is back...
<xclaesse> hm, but it re-download all my emails :(
<mardy> xclaesse: did you install some additional package meanwhile?
<xclaesse> nothing related to evolution
<Riddell> mvo: this ok? seems to contain a suspicious amount of noise http://launchpadlibrarian.net/221784898/ubuntu-release-upgrader_1%3A15.10.11_1%3A15.10.12.diff.gz
<mvo> Riddell: that looks ok, the demotion detection is automatcially run during build
<Riddell> mvo: thanks, accepted
<infinity> Riddell: I rejected it, actually. :P
<infinity> Riddell: And you accepted it from the rejected queue?
<infinity> Riddell: rly?
<Riddell> um, I'm pretty sure I didn't
<Riddell> why was it rejected?
<infinity> Riddell: Your email explained it. :P
<infinity> Riddell: The .11 changes weren't reverted.
<infinity> Riddell: Despite .11 being explicitly removed from -proposed as a bad change.
<infinity> Riddell: So, please give me a .13? :P
<Riddell> infinity: ah, someone didn't update bzr, I'll do that now
<chiluk> infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490 has now dropped into -updates for linux-lts-utopic, are you going to have time to integrate those kernels?
<ubottu> Launchpad bug 1481490 in linux-lts-utopic (Ubuntu) "Add sfc to nic-modules udeb" [Undecided,Fix committed]
<infinity> chiluk: I can find time, probably, but also in the middle of release week, so a bit swamped.
<dholbach> can somebody moderate my mail to u-d-a@ through?
<cjwatson> dholbach: done
<dholbach> thanks!
<coreycb> arges, can you reject horizon from the vivid upload queue?  we have an update coming to that.
<arges> coreycb: ok
<chiluk> infinity: yeah I figured as much.. just wanted to remind you.
<coreycb> arges, thanks
<arges> coreycb: done
<rbasak> doko: https://launchpad.net/ubuntu/+archive/test-rebuild-20151001/+build/8057346 should succeed with the python-django in Wily now. Not sure if that'll get synced from Wily to the test archive?
<infinity> pitti: You still around?
<cjwatson> rbasak: that would only be needed if the fix was in python-jingo - the test rebuild uses the primary archive for its build-deps
<cjwatson> rbasak: I've retried that build
<cjwatson> (and built)
<rbasak> cjwatson: ah. Thanks!
<hallyn_> ok an glib ppl around who could tell my why the string "/user.slice/user-1000.slice/session-1.scope" (read from a procfile with getline()) would be used as "[Invalid UTF-8]" ?
<hallyn_> d'oh
<hallyn_> nm
<rcj> arges, Where are the directions for building the kernel package?  I need to build wily patched with https://lkml.org/lkml/2015/8/11/742 to see if my external thinkpad keyboard starts scrolling again.
<rcj> arges, I'm asking because I'm finding 4 different kernel wiki pages and can't recall which is the right one to build the same code you'd get from installing the wily kernel
<arges> rcj: patch it, ensure you have deps installed and run 'dpkg-buildpackage -d' (that will be _everything_)
<arges> rcj: i do 'make deb-pkg -jN' for quick local packages though
<rcj> arges, thanks
<smoser> anyone know how to make systemd not switch vts back and forth during boot ?
<smoser> i'm booting a system like:
<smoser>  qemu-system-x86_64 -enable-kvm -device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 -m 1024 -curses -drive file=boot.img,if=virtio -kernel my.kernel -initrd my.initrd -append 'root=/dev/vda1 console=ttyS0'
<smoser> and it quite obnoxiously flipps back and forth between vts. i'd like to be able to use the scrollback buffer (shift pg-up). but since vts have been switched thats gone.
<arges> smoser: could you add 'vga=current' to kernel cmdline?
<smoser> will try
<barry> bdmurray: say, could you take a look at https://code.launchpad.net/~barry/ubuntu-release-upgrader/lp1485093 - it might be too late for wily, but i'd like to get it in asap for x so i can upload a fixed pex package
<smoser> arges, seems like systemd thinks i want to look at the seabios information.
<smoser> $ cat /proc/cmdline
<smoser> root=/dev/vda1 ds=nocloud-net;seedfrom=http://104.130.21.57:40885/ console=ttyS0
<smoser>  vga=current
<bdmurray> barry: I'll have a look.
<barry> bdmurray: thanks
#ubuntu-devel 2015-10-21
<pitti> Good morning
<dholbach> good morning
<dpm> seb128, wgrant, morning. Eventually, the manual .po file uploads for evolution got imported: https://translations.launchpad.net/ubuntu/wily/+source/evolution/+imports
<seb128> dpm, hey, good to know
<dpm> there is a caveat, though
<dpm> after long waiting and seeing that the .po files did not get imported automatically after the template had, I had to explicitly choose the template they belonged to
<dpm> then they got imported
<dpm> perhaps it was me being impatient and they would have been auto-imported, but after a few hours waiting, I wasn't sure
<TJ-> Has anyone seen this package-hold for aptdaemon. I'm not making sense of it since there's nothing in /var/lib/dpkg/status that shows the version dependency mentioned: "python3-aptdaemon : Depends: gir1.2-packagekitglib-1.0 (< 0.9) but 0.9.5-0ubuntu1 is to be installed"
<TJ-> Ahhh bug 1496292
<ubottu> bug 1496292 in aptdaemon (Ubuntu) "/usr/sbin/aptd:AttributeError:/usr/sbin/aptd@39:main:__init__:__init__" [High,Fix released] https://launchpad.net/bugs/1496292
<seb128> TJ-, you used wily-proposed and got a buggy version that got deleted later, you might want to sudo apt-get install python3-aptdaemon/wily
<TJ-> Yeah, I figured it out once I found the older changelog entry
<tjaalton> is there a way to narrow down the updates that hit wily around Sep 10th, because something triggers X crashes since then
<TJ-> tjaalton: Other that /var/log/apt/history* ?
<seb128> tjaalton, wily-changes list?
<tjaalton> TJ-: not mine, trying to figure out distro-wide what happened when
<seb128> tjaalton, which ones? do you have a bt?
<tjaalton> seb128: well kinda, gives some sort of an idea
<tjaalton> at least I can rule out some X stuff..
<tjaalton> dupes of https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1237904
<ubottu> Launchpad bug 1237904 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in OsAbort()" [Medium,Confirmed]
<tjaalton> 1495049 and up
<tjaalton> which was Sep 14th actually
<seb128> tjaalton, the first issue on e.u.c?
<seb128> that seems to be gdm trying to start a xserver when there is already one active
<seb128> they all have gdm options in their command line
<tjaalton> ah, that would be a good hint
<seb128> I pinged darkxst several time about it
<seb128> installing gdm on my test laptop also bricks it
<seb128> e.g no dm is starting
<seb128> so I think it's gdm screwed up
<seb128> tjaalton, the xorg logs all have
<seb128> [   451.402] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
<seb128> [   451.402] _XSERVTransMakeAllCOTSServerListeners: server already running
<seb128> [   451.403]
<tjaalton> good
<seb128> btw the xorg hook seems grumpy
<seb128> https://launchpadlibrarian.net/221676859/HookError_source_xorg_server.txt
<seb128>   File "/usr/lib/python3/dist-packages/problem_report.py", line 627, in __setitem__
<seb128>     assert k.replace('.', '').replace('-', '').replace('_', '').isalnum()
<seb128> AssertionError
<seb128> tseliot, ^
<tseliot> seb128: yay, something else failed. I'll look into that
<seb128> tseliot, thanks
<tjaalton> gdm didn't change since Aug 7th
<tjaalton> but it's some other change that triggers the bug then
<TJ-> tjaalton: looking at the DpkgLog attached to 1495049 shows the dates/packages recently updated; nothing entirely obvious, but libc-bin, dbus, systemd might be suspect
<darkxst> seb128, I still havent been able to reproduce on either of my systems
<seb128> darkxst, seeing the number of report you must have some users who can?
<darkxst> seb128, I will ask around
<seb128> thanks
<darkxst> seb128, do you have the e.u.c link handy?
<seb128> darkxst, https://errors.ubuntu.com/problem/27941445d596fb71be692b9008c0847d2ce6c428
<darkxst> emailed to QA team
<tjaalton> thanks
<TJ-> The common issue from the Xorg logs is the first session starts on VT7, fails, and the replacement starts on VT2
<seb128> darkxst, tjaalton, ^
<darkxst> TJ-, gdm should start on vt7
<darkxst> the user session should start on vt2
<TJ-> darkxst: but should the process on VT7 remain running?
<darkxst> TJ-, yes
<darkxst> and actually gdm should be running on wayland
<darkxst> for the FOSS drivers atleast
<darkxst> maybe it isnt since we don't seed xwayland yet
<TJ-> I'd suspect the first X server on VT7 owns/uses "/tmp/.X11-unix/" sockets and the 2nd server on VT2 tries to use the same socket
<cjwatson> should be a different name under /tmp/.X11-unix/ for each server - X0, X1, etc.
<TJ-> cjwatson: that's what I'd expect; unfortunately that info isn't available in the bug report logs. "_XSERVTransMakeAllCOTSServerListeners: server already running" certainly suggests something has the socket the user session wants
<seb128> TJ-, would the stacktrace help? if you tag the bug apport-request-retrace you can get a next one from the next duplicate (rather than having it cleaned by the retracer)
<TJ-> seb128: I was just wondering how we could do that; I'm not convinced the stacktrace in the master report is the same. I've been picking dupes at random and those after 1495049 all look different, most obviously ProcCmdline
<seb128> no, the master is not the same
<seb128> e.u.c launchpad batch OsAbort() errors it seems
<seb128> the master was a VT_ACTIVATE fail
<TJ-> added the tag
<seb128> but the recent ones are all gdm ones
<seb128> so I expect a new retrace is going to give us a new bt
<seb128> showing the gdm issue
<TJ-> I use KDE so I'm not familiar with the way gdm is running 2 X servers for (presumably the greeter) and the user session, but the ProcCmdline entries of all the dupes I've looked at are referring to the gdm owned X on VT7
<psychic_> quit
<ogra_> grrr ... why do pipes not work in the initrd when i use libc tools but work when using the busybox commands
 * ogra_ wonders if there is a trick 
<infinity> ogra_: One tool printing to stderr and the other to stdout?
<ogra_> hmm
<infinity> (Just a guess)
<ogra_> infinity, hah, no ... but seems - means something else
<ogra_> "/bin/wget -O - http://192.168.2.74:1500/ubuntu-15.04-snappy-armhf-rpi2.img.xz | /usr/bin/xzcat | dd of=/dev/mmcblk0" works fine
<ogra_> "/bin/wget -O - http://192.168.2.74:1500/ubuntu-15.04-snappy-armhf-rpi2.img.xz | /usr/bin/xzcat - | dd of=/dev/mmcblk0" doesnt
<pitti> ah, busybox wget not accepting - ?
<pitti> uh, odd
<ogra_> no, xzacat not accepting -
<ogra_> *xzcat
<ogra_> using the libc dd in that line gets even more weird :)
<ogra_> but yay ... my initrd installer constriction works
<davmor2> ogra_: lets just stick with because it hates you ;)
 * ogra_ wraps more duct tape around it 
<infinity> An initrd that grabs an unathenticated http URL and blats it to disk seems super secure.
<ogra_> yeah, awesome, aint it ? :)
<infinity> Also, that should be armhf+rpi2 ...
<davmor2> infinity: shhhhh you're not meant to notice that
<ogra_> it is the same machine the serial cable is attached to ... for image tests
<ogra_> infinity, it so should ...
<ogra_> well, effectively armhf+raspi2
<infinity> Or that, yes.
<ogra_> but that name was already used when i antered the snappy team :/
<ogra_> like the BBB image is called armhf-beagle or some such weird thing
 * ogra_ is curious how long that dd will actually take ... 
<ogra_> (really bad that busybox dd doesnt know the blocksize arg)
<seb128> wgrant, why did you reject https://code.launchpad.net/~cjohnston/launchpad/1260760-unset-source/+merge/229462? (I guess it was wrong bug would have been nice to comment about what was the issue)
<seb128> or asked differently, what launchpad dev to I need to pay a beer to to get https://bugs.launchpad.net/launchpad/+bug/1260760 fixed?
<ubottu> Launchpad bug 1260760 in Launchpad itself "editing an Ubuntu (gtk+3.0) bug unsets the source" [Undecided,Triaged]
<ogra_> wheee !
<ogra_> it boots (and only took ~20min for dd)
<dholbach> barry, do the two python sessions need a blueprint in LP for tracking work items and stuff?
<dholbach> (just noticed them in summit)
<barry> dholbach: maybe couldn't hurt although we all know what needs to be done.  mostly i want to make sure everyone's aligned with the plan
<dholbach> ok, wfm
<barry> brb
<infinity> rbasak: I have a weird juju testsuite regression in wily that's about to hold up the release, who do I talk to to debug this ASAP?
<rbasak> infinity: sinzui. I've asked him to join.
<rbasak> infinity: BTW, I'm quite bothered by https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1490110. It breaks upgrades for anyone with lxc and juju-local installed.
<ubottu> Launchpad bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Medium,Confirmed]
<rbasak> Which is Every Charm Developer I think.
<cjwatson> juju bootstrap totally works here on current wily, notwithstanding what the test suite is saying, but then I don't understand why it's failing
<sinzui> hi infinity can I help with a juju issue
<infinity> sinzui: Hey.  What do you make of https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/j/juju-core/20151021_155639@/log.gz ?
<rbasak> I can tell you what future-{local,manual}-provider do.
<rbasak> They fake a future release to make sure that the development release isn't broken as soon as it opens.
<rbasak> panic: osVersion reported an error: Could not determine series
<rbasak> That may be related.
<rbasak> The update to distro-info-data may be related.
<cjwatson> oh, I didn't notice that that was future-
<infinity> So, it's faking a future release incorrectly? :P
<rbasak> Hmm, maybe.
<rbasak> Do you happen to have a shell at the point the test breaks? Otherwise I can do it.
<cjwatson> I suspect that it is faking something insufficiently far in the future
<cjwatson> or maybe is confused by the last line having LTS in it?
<rbasak> It seems likely to me that this is a bug in my faking-the-future code.
<sinzui> Juju has a very stupid policy to hard coding known releases and treating them as everything that will ever exist. The reading of ubuntu.csv by juju ti to get a more current list.
 * rbasak is busy reproducing
<sinzui> cjwatson: infinity rbasak: this is the bug I think you are seeing https://bugs.launchpad.net/juju-core/+bug/1465317
<ubottu> Launchpad bug 1465317 in juju-core "Wily osx win: panic: osVersion reported an error: Could not determine series" [High,In progress]
<infinity> rbasak: Okay, so I think this bears investigation, as the test is clearly doing an oops of some sort, but now that I understand the scope, I'm also going to ignore the failure.  Thanks for pointing out the future bit.
<cjwatson> the hacked up file seems to have one more field than it should
<cjwatson> but I think it's always been that way, so WTF
<cjwatson> echo "${version},${codename},${series},${created},${release},${eol},${eol}" >> /usr/share/distro-info/ubuntu.csv
<cjwatson> looks like that's one more ,${eol} than there should be
<rbasak> I think that might have been intentional
<sinzui> infinity: cjwatson  what has changed between this builds? http://autopkgtest.ubuntu.com/packages/j/juju-core/wily/amd64/ to get the failure? If nothing changed, then I think a race condition is in the code where the wrong table of versions was read
<rbasak> version,codename,series,created,release,eol,eol-server
<rbasak> cjwatson: so two eol fields
<cjwatson> sinzui: new distro-info-data
<cjwatson> rbasak: oh, also, it's emitting dates that aren't dates
<cjwatson> rbasak: (ah, I forgot eol-server.  right)
<cjwatson> 2015-26-19,2015-26-20,2015-26-22,2015-26-22
<sinzui> ah. bugger. I really hate jujus design to fail with the unknonwn
<cjwatson> haha, I see the date problem
<cjwatson> created=`date -d '-2 days' +%Y-%M-%d`
<cjwatson> release=`date -d '-1 days' +%Y-%M-%d`
<cjwatson> eol=`date -d '+1 days' +%Y-%M-%d`
<cjwatson> %M should be %m
<cjwatson> don't know if that's the problem here
<cjwatson> it's probably not, but should be fixed!
<rbasak> Oops. Sorry. Thanks!
<rbasak> I might as well try that fix first and see if the error goes away.
<cjwatson> we think that's not the problem because the historical passes are at times that ought to have guaranteed an invalid month
<sinzui> rbasak: should I plan to rebase 1.24.7 on 1.24.6-0ubuntu3 packaging :)
<rbasak> sinzui: :)
<rbasak> sinzui: yes in theory, but a fix to the test should be trivial to merge.
<sinzui> rbasak: I have automated more of the certifification for Juju. It get less painful each time
<Odd_Bloke> Laney: Do we have a bug where we're tracking getting the UI needed to handle bug 1463072?
<ubottu> bug 1463072 in gnome-terminal (Ubuntu) "highlighting on left mouse double click ends at :" [Medium,Won't fix] https://launchpad.net/bugs/1463072
<rbasak> It's not /usr/share/distro-info/ubuntu.csv I don't think. Either /etc/lsb-release or /etc/os-release.
<rbasak> I think it's os-release.
<Laney> Odd_Bloke: I don't know if there is a bug, but I have asking upstream on my to do list for the beginning ish of the cycle (no promises given the URL case which is the reason most people want this has a different way to achieve the same thing)
 * ogra_ wonders if thats related to always having the quotes of a quoted string selected too on double click 
<infinity> ogra_: That was fixed.
<ogra_> (it used to only select the bits between quotes in earlier versions)
<ogra_> infinity, oh, in wily ?
<infinity> ogra_: Yeah.
<ogra_> i guess i found my first reason to upgarde then :)
<infinity> ogra_: It wasn't that the behaviour changed, it was that some tools (like wget) switched from using ' and " to using unicode pretty quotes.
<ogra_> yeah
<infinity> ogra_: And VTE/gnome-terminal didn't recognize those as boundaries.
<infinity> ogra_: But, yeah, that's fixed.
<ogra_> dpkg-buildpackage too ... that is where it annoys me most
<Odd_Bloke> Laney: I'm probably not going to chase you any more, as I've just switched to Terminator which does what I want. :p
<rbasak> sinzui: I think the future faking is working correctly, apart from the date month/minute bug that cjwatson pointed out that doesn't seem to be the problem here.
<rbasak> sinzui: it's something to do with how Juju is parsing /etc/os-release I think. If I revert os-release (but not the others, causing everything to be mismatched incidentally) then Juju works.
<rbasak> sinzui: however the faking is just making it look like there's a "Y" release and the machine is on it. One difference is that it claims that Y is LTS.
<sinzui> rbasak: understood. I think the issue is the bug I posted earlier. Juju specifies exact version instead of minimum versions. My bug is about stopping the hard coding so that all of us can upgrade.
<rbasak> sinzui: I think it's over to upstream to look further now please. I would also note that release dates faked aren't coherent (Y released before X) so if that's the problem then please let me know and we can make the faking smarter.
<rbasak> sinzui: I'm not convinced it's the same bug but I can see how it could be.
<rbasak> Though it seems unlikely that Juju is parsing dates as it didn't barf on impossible dates :)
<Laney> rbasak: Is is that you put "LTS" in VERSION_ID?
<Laney> At least deleting that seems to make juju version work here
<rbasak> Hmm. Good point.
 * rbasak tries
<rbasak> Yes, that's it. Thanks Laney. Sorry sinzui.
<infinity> Ahh, yes, VERSION_ID is always a number, LTS doesn't belong there.
<rbasak> Yeah I have two variables, $version which includes a potential LTS and $version_ that doesn't. VERSION_ID should be using the latter.
 * rbasak 's code pre-dates os-version, but never mind. He'll fix it.
<rbasak> infinity: do you want an upload if this fixes the issue?
<rbasak> I can fix the date thing as well.
<infinity> rbasak: It's not on any images, so sure.
<infinity> rbasak: It's always nice to have tests passing.
<rbasak> OK. Just testing my fix from scratch now.
<Laney> What if they test that you cry when slapped in the face?
<rbasak> Juju fix uploaded.
 * rbasak EODS
<infinity> rbasak: Ta.
<hallyn_> so bug 1490110 is looking weirder and weirder.  I guess actually do-release-upgrade is crashing, then apport crashes while trying to report on it bc do-release-upgrade's python version was upgraded (so /proc/self/exe is deleted)
<ubottu> bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Critical,Confirmed] https://launchpad.net/bugs/1490110
 * hallyn_ retries the whole shebang again with hopes of gdb attaching
<slangasek> pitti: so there are some duplicates of LP: #1504897 coming in... e.g. LP: #1508533
<ubottu> Launchpad bug 1504897 in nfs-utils (Ubuntu) "package nfs-common 1:1.2.8-9ubuntu10 failed to install/upgrade: Ð¿Ð¾Ð´Ð¿ÑÐ¾ÑÐµÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ ÑÑÐµÐ½Ð°ÑÐ¸Ð¹ post-installation Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ¸Ð» ÐºÐ¾Ð´ Ð¾ÑÐ¸Ð±ÐºÐ¸ 100" [Undecided,Incomplete] https://launchpad.net/bugs/1504897
<ubottu> Launchpad bug 1508533 in nfs-utils (Ubuntu) "package nfs-common 1:1.2.8-9ubuntu10 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Undecided,New] https://launchpad.net/bugs/1508533
<hallyn_> ok so when lxc is built for wily, the pkg builder adds a versioned dependency on dbus, a version which is > what's in vivid.   so do-release-upgrade from vivid fails bc dbus is too old.
<hallyn_> should lxc add a pre-depends on dbus for this, or should this be being handled by whatever is adding the depends?
<hallyn_> (this is still bug 1490110)
<ubottu> bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Critical,Confirmed] https://launchpad.net/bugs/1490110
<cjwatson> a pre-depends will only make any difference at all if you're expecting the new dbus to be unpacked and configured *when your preinst runs*
<hallyn_> cjwatson: i dunno.  when i pre-install the newer version of dbus, it still fails with
<hallyn_> invoke-rc.d: unknown initscript, /etc/init.d/lxc not found.
<hallyn_> which makes no sense since there is no /etc/init.d/lxc in the old pkg either
<rbasak> hallyn_: http://paste.ubuntu.com/12887946/ line 131 maybe?
<hallyn_> rbasak: that looks fine though
<hallyn_> i mean it should be updated, but at the moment it's fine bc the upstart job is shipped
<hallyn_> question is why is invoke-rc.d insisting on using the sysvinit job?
<hallyn_> rbasak: also you're supposed to be eod :)
<rbasak> So it calls invoke-rc.d even though there is no init.d script because it finds the upstart script
<rbasak> But upstart isn't present, so invoke-rc.d will do whatever it does when upstart isn't present.
<rbasak> That logic makes no sense.
<rbasak> I don't really understand how it is supposed to interact with systemd though.
<hallyn_> rbasak: 'invoke-rc.d lxc start' talks to systemd just fine
<hallyn_> at least, when i do it by hand
<hallyn_> obviously not during this upgrade :)
<hallyn_> but yeah, maybe this is just a kick in the pants to change this
<rbasak> hallyn_: could it be related to dh_systemd_start handling happening a little bit later in the generated postinst?
<rbasak> I can't see how though
<hallyn_> hm.
<hallyn_> btw i was thinking that mustve come from lxc.postinst but it does not, so that's just the autogenerated postinst code.... nothing lxc can do about it afaics
<rbasak> My hypothesis is that it's either a bug in dh_installinit/dh_systemd* or the way you're calling it in the package. Maybe if you drop the upstart job (rm_conffile etc) the problem will go away.
<hallyn_> can't do that, there are still upstart users
<hallyn_> like phone
<rbasak> Ah, good point.
<hallyn_> mbiebl_: pitti: hey, one of you good fellows around?
<hallyn_> we're looking at bug 1490110 .   the lxc package ships upstart and systemd jobs, not sysvinit.  upgrade from vivid to wily fails on invoke-rc.d lxc start insisting on there being a /etc/init.d/lxc, and we can't tell why.
<ubottu> bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Critical,Confirmed] https://launchpad.net/bugs/1490110
<TJ-> hallyn_: I saw something very similar with a user recently, using mongodb, and tracked it down to the postinst script incorrectly trying to use update-rc.d when there's an /etc/init.d/.legacy-bootordering
<TJ-> hallyn_: Hazy recall now, but I *think* the control flow was going via invoke-rc.d or similar
<hallyn_> TJ-: what should postinst be doing instea dof update-rc.d?
<TJ-> hallyn_: just gone back through my logs - terrible memory! It was actually showing up via (manually reproduced doing) "dpkg --configure  libpam-systemd"
<TJ-> hallyn_: "the root cause is a call to "update-rc.d systemd-logind defaults" "
<TJ-> hallyn_: if you're seeing the same/similar issue, lines 15-19 of the 14.04 libpam-systemd.postinst were the crux: http://paste.ubuntu.com/12739482/
<hallyn_> TJ-: the 'defaults' line, or also line 19?
<TJ-> hallyn_: I'm trying hard to recall! I *think* I originally though line 16, but then we did a "set -x" trace and it showed it was line 19 (invoke-rc.d)
<hallyn_> lxc is using invoke-rc.d to start some other things (mainly apparmor and dnsmasq)
<hallyn_> what did you replace that with?
<TJ-> hallyn_: Just found the log (the user changed nicknames): "dpkg-divert --local --rename --add /usr/sbin/invoke-rc.d" and "ln -s /bin/true /usr/sbin/invoke-rc.d"  and then undid it afterwards.
<rbasak> Wow!
<rbasak> That seems a bit...extreme :)
<hallyn_> TJ-: will try that, thanks much :)
<TJ-> rbasak: I was trying to get the user out of a broken "apt-get -f install" situation
<hallyn_> although, hm, i don't want invoke-rc.d t onot run
<sarnold> heh, I'd recommend asking one of the greybeards before going that far :)
<TJ-> hallyn_: right, I think it depends on which services require it, but as I said that was the root cause for the user I was helping
<TJ-> I seem to recall I found the work-around recommended on the -devel mailing list from some time back, or else in a launchpad bug comment
<TJ-> Not sure how sane this was, but I found myself saying: "...the reason that invoke-rc.d is failing
<TJ-> since it can't find the 'upstart' version of initctl, it tries to use sysv-init, and there is no sysv-init script for systemd-logind
<hallyn_> should this count as a bug against sysv-rc?
<doko> kees, is harderning-wrapper still maintained, or is it obsolete now?
<achiang> mdeslaur: hey, have there been any 14.04 security updates that might break LXC? trying to start a container and getting: lxc-start: conf.c: setup_pts: 1772 Permission denied - mount failed '/dev/pts/ptmx'->'/dev/ptmx
 * achiang decides to try and boot an older kernel to see if that is related
<pitti> slangasek: right, and bug 1502536 is essentially the same; I haven't yet managed to reproduce it
<ubottu> bug 1502536 in ofono (Ubuntu Wily) "package ofono 1.17.bzr6904+15.10.20150928.1-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [High,Incomplete] https://launchpad.net/bugs/1502536
<pitti> slangasek: but vila attached the apt-clone tarball yesterday; I guess this can somehow be used to reconstruct the original system
<rbasak> pitti: that looks like the same as https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1490110 that hallyn is working on
<ubottu> Launchpad bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Critical,Confirmed]
<pitti> hallyn_: hello; this was meant to be fixed in vivid's invoke-rc.d and service already, hmm
<pitti> hallyn_: actually sounds like the same issue I was just telling slangasek
<pitti> rbasak: right, these are by and large all the same
<rbasak> pitti: we currently have a reproducer
<pitti> rbasak: oh, you do? I tried umpteen scenarios for ofono and nfs-common
<rbasak> pitti: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1490110/comments/20
<ubottu> Launchpad bug 1490110 in lxc (Ubuntu) "package lxc 1.1.3-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 100" [Critical,Confirmed]
<rbasak> On Vivid install juju-local + lxc then do-release-upgrade to Wily.
<pitti> rbasak: note that for fixing upgrades it's enough to have the fix in -updates, so we don't need to respin for that
<pitti> just a 0-day SRU
<rbasak> ack
<pitti> rbasak: odd; from a vivid cloud image I tried installing nfs-common, ofono, then dist-upgrade and what not; but I"ll try with this
<rbasak> I used uvt-kvm
<sarnold> achiang: looks a bit like https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1504781
<ubottu> Launchpad bug 1504781 in lxc (Ubuntu Trusty) "lxc-test-ubuntu hangs forever in trusty-proposed with Linux 3.13.0-66: AppArmor denies /dev/ptmx mounting" [Undecided,Fix released]
<rbasak> I have the cloud image I used. I haven't tried multiple times so I don't know if there's something non-deterministic involved.
<achiang> mdeslaur: hm, yes. booting with 3.13.0-65-generic #106-Ubuntu allows my vagrant-lxc container to boot again
<achiang> and with 3.13.0-66-generic it is broken
<sarnold> achiang: see also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507959 -- it may be worth unduping those two?
<ubottu> Launchpad bug 1504781 in lxc (Ubuntu Trusty) "duplicate for #1507959 lxc-test-ubuntu hangs forever in trusty-proposed with Linux 3.13.0-66: AppArmor denies /dev/ptmx mounting" [Undecided,Fix released]
<achiang> sarnold: reading through the first one 1504781 certainly describes my symptoms
 * rbasak goes to bed
<achiang> running apt-get upgrade to get lxc 1.0.7-0ubuntu0.9 and will try with kernel -66 again
<achiang> brb
<achiang> Yeah, that fixed it. Thanks sarnold
<hallyn_> pitti: hi, so you have a handle on that bug?
<pitti> hallyn_: I duplicated/summarized it, but I don't have a working reproducer yet
<pitti> obviously it's some mis-handling in invoke-rc.d
<pitti> in vivid we added some handling for packages which don't have init.d scripts, but apparently there's some case where this doesn't work
<hallyn_> hm.  as rbasak said uvt-kvm makes it very easy, or you could do it with lxc-create -t
<hallyn_> uh, lxc-create -t ubuntu-cloud
<pitti> hallyn_: I'm running dist-upgrades in qemu
<pitti> so far I installed lxc and  juju-local, and now dist-upgrading
<pitti> which still works fine
<hallyn_> so it's something about the clou dimages then
<pitti> but so far indeed I didn't use do-release-upgrade, I'll try that next
<hallyn_> (which is what uvt-kvm uses)
<hallyn_> oh!
<hallyn_> ok
<pitti> hallyn_: no, I also got reports from desktops
<pitti> like vila's
<hallyn_> ok
<pitti> I can't imagine how apt full-upgrade vs. do-release-upgrade would make any difference, but who knows
<pitti> hallyn_: do you have a way to reproduce it?
<pitti> so far every reporter couldn't reproduce it after the dist-upgrade, any further dpkg-reconfigure, apt-get install -f, apt-get install --reinstall, sh -x invoke-rc.d etc. went fine
<pitti> ah! do-release-upgrade indeed!
<hallyn_> indeed :)
<hallyn_> does it set some weird configuration?
<pitti> imported/invoke-rc.d
<pitti> SRSLY?
<pitti> our dist upgrade tarballs have their own version?
<hallyn_> <blink>
<pitti> and lo and behold, diff -u /usr/sbin/invoke-rc.d imported/invoke-rc.d
<pitti> all the systemd support is missing
<Laney> umm?
<pitti> mvoooooooooooooooooooooooo
<hallyn_> phew
<Laney> because it wants to apply this diff to it?
<pitti> Laney: no, I ran diff between the version in wily.tar.gz (the release upgrader tarball) and the real invoke-rc.d from sysv-rc
<pitti> I updated the bug
<pitti> now, I don't have the slightest idea how this upgrade tarball is constructed
<pitti> bdmurray: ^ do you happen to know? or is that still all mvo's domain?
<Laney> pitti: I mean it has this copy because it has DistUpgrader/imported/invoke-rc.diff applied or what?
<Laney> (in the u-r-u source package)
<pitti> Laney: perhaps, yes
<Laney> does it just come right from here to the tarball?
<pitti> Laney: yes, I just unpacked it and looked at imported/invoke-rc.d
<pitti> do-r-u leaves it behind in /tmp/
<bdmurray> pitti: DistUpgrade/build-tarball.sh creates it
<cjwatson> and it's spat out as part of the ubuntu-release-upgrader package build and gets into LP via a raw-upgrader (or some such) dpkg-distaddfile
<cjwatson> raw-dist-upgrader, that's the one
<pitti> cjwatson: ah, so uploading u-r-u should do it?
<Laney> So yes, can fix the one in the package
<cjwatson> pitti: right
<cjwatson> (disclaimer: have not been following the rest of the discussion at all)
<pitti> cjwatson: do you know, would that also work when SRUing this? i. e. upload to wily-updates?
<pitti> I don't think we want to rebuild images for this
<pitti> (or maybe it's necessary, but checking options here)
<cjwatson> I believe so but would have to check
<bdmurray> pitti: yes, it would we just need to change the meta-release file url to point to -updates
<pitti> cjwatson: rest of the discussion is not that important; the essence is, the current wily.tar.gz upgrade tarball is buggy
<bdmurray> pitti: I already have an SRU pending for bug 1508539
<ubottu> bug 1508539 in ubuntu-release-upgrader (Ubuntu Wily) "KernelRemoval information not updated for 15.10" [High,In progress] https://launchpad.net/bugs/1508539
<cjwatson> oh that's it
<cjwatson> it gets the URL from http://changelogs.ubuntu.com/meta-release*
<cjwatson> (the various versions of that, there's an index at the top level)
<cjwatson> I think that's updated by hand but it can be made to point to -updates
<cjwatson> and indeed does for some series
<bdmurray> cjwatson: that's what I was saying
<pitti> bdmurray: ah good; mind if I reject your upload and add the invoke-rc.d update and reupload?
<cjwatson> bdmurray: right, indeed, just wanted to fill in the details
<bdmurray> pitti: no, that sounds find. What bug is this fixing?
<pitti> bdmurray: seems you didn't yet push the release tag to bzr anyway :)
<cjwatson> since I think this is poorly understood by a lot of devs
<pitti> bdmurray: bug 1504897
<ubottu> bug 1504897 in ubuntu-release-upgrader (Ubuntu X-series) "packages with only upstart+systemd without sysvinit fail to upgrade with do-release-upgrade: upgrade tarballs ship obsolete invoke-rc.d" [High,In progress] https://launchpad.net/bugs/1504897
<pitti> bdmurray: i. e. various packages failing to upgrade with "no such init.d script" and exit status 100
<bdmurray> pitti: so bug 1508247 then?
<ubottu> bug 1508247 in lxc (Ubuntu) "Upgrade failed due to lxc" [Undecided,New] https://launchpad.net/bugs/1508247
<pitti> bdmurray: yep, duplicated; similar to bug 1490110 (also already duped)
<ubottu> bug 1504897 in ubuntu-release-upgrader (Ubuntu X-series) "duplicate for #1490110 packages with only upstart+systemd without sysvinit fail to upgrade with do-release-upgrade: upgrade tarballs ship obsolete invoke-rc.d" [High,In progress] https://launchpad.net/bugs/1504897
<bdmurray> pitti: okay, I'll keep an eye out for those
<Laney> can we just take this diff into the normal invoke-rc.d in future?
<Laney> feel like this trap might come up again
<pitti> seems reasonably fine, yes
<pitti> for X we should really do that
 * Laney writes a note for friday
 * pitti taps foot for this looong pre-build.sh to finsih
<pitti> ok, uploaded
<pitti> can we test this somehow while it's in -proposed?
<Laney> I guess re-target http://changelogs.ubuntu.com/meta-release-development ?
<pitti> like temporarily pointing ^ to -proposed ?
<Laney> bdmurray: ^?
<pitti> I wonder if there's some secret option/env var to use a local file
<pitti> arges: ^ as you currently seem to do SRUs, would you mind looking at ubuntu-release-upgrader in wily? (I uploaded it, so don't want to self-accept)
<bdmurray> usually meta-release-proposed is used to point at proposed
<pitti> arges: this should probably become a 0-day SRU tomorrow
<pitti> arges: (sorry for the shameless abuse!)
<cjwatson> I think you can pass it a local configuration file too
<Laney> It's ok, I'm reviewing it
<TJ-> pitti: I did something with it some years ago; edited "/etc/update-manager/meta-release"
<cjwatson> stash it in /etc/update-manager/meta-release IIRC
<cjwatson> snap
<Laney> I've released 0-day SRUs before
<pitti> TJ-, cjwatson: awesome, thanks
<Laney> so don't feel too naughty accepting it with thise intention :)
<Laney> cjwatson: ah, feel free
<pitti> Laney: ack, thanks; you have more context now, too
<cjwatson> I'm not reviewing it
<Laney> oh
<cjwatson> my snap was to TJ-
<Laney> fair
<pitti> so once it's accepted/built, we can test the upgrade
<arges> pitti: will look
<pitti> arges: seems Laney is on it, so nevermind; thanks anyway!
<arges> pitti: oh I don't usually look at dev releases
<arges> pitti: ok ok
<pitti> arges: it's that gray area between dev and stable now :)
<lifeless> dable? stev?
<pitti> lifeless: almost-solid?
<lifeless> hmm, what do you call jellies that are nearly set ?
<pitti> cjwatson: while we can soak in your wisdom: how does http://changelogs.ubuntu.com/meta-release{,-development} get updated once this gets released? is that "vi" by someone with perms, or does that live in some bzr?
<TJ-> lifeless: Ready to eat
<pitti> (or "emacs" of course -- this ain't no flamebait)
<bdmurray> pitti: it lives in bzr but someone needs to put on the server
<bdmurray> pitti: ~ubuntu-core-dev/meta-release/ubuntu/
<pitti> bdmurray: ah, is that an RT?
<bdmurray> pitti: no, I have access
<pitti> bdmurray: ah, ok
<pitti> hallyn_, rbasak, Laney, bdmurray, cjwatson: thanks for your help -- nice teamwork!
<cjwatson> as do I, Michael, and Adam
<Laney> pitti: accepted, thanks
<Laney> modulo hotel wifi (done now)
<pitti> Laney: ok,thanks; it's getting late, so unless someone beats me to it I'll test it first thing in the morning
<Laney> I'm guessing you might beat us to being awake/online :)
<bdmurray> pitti: I can test it what should I have installed?
<Laney> (but if not, will do)
<pitti> bdmurray: I added a test case to bug 1504897 description
<ubottu> bug 1504897 in ubuntu-release-upgrader (Ubuntu X-series) "packages with only upstart+systemd without sysvinit fail to upgrade with do-release-upgrade: upgrade tarballs ship obsolete invoke-rc.d" [High,Fix committed] https://launchpad.net/bugs/1504897
<bdmurray> pitti: cool, thanks. Its also possible to just manually download the dist-upgrader tarball, extract it and run ./wily
<pitti> bdmurray: that'd be great, thanks; you also have sru-release and ~ubuntu-core-dev/meta-release/ubuntu/ powers, so we can land this by tomorrow
<pitti> bdmurray: ah, ./wily instead of do-release-upgrade -d?
<pitti> I don't see the spethial tarball on https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.10.14/+build/8156705
<bdmurray> pitti: do-release-upgrade -d does the checking of the metarelease file and stuff. I'm saying you can http://archive.ubuntu.com/ubuntu/dists/wily-proposed/main/dist-upgrader-all/current/ download wily.tar.gz and unpack it and then run it
<pitti> so that doesn't work through dpkg-distaddfile, but some other side channel I suppose
<pitti> bdmurray: ah, cool; so that's essentially what do-r-u does
<bdmurray> pitti: yes
 * pitti waves good night then, cu tomorrow
<Laney> night pitti
<pitti> "today" already :)
<sarnold> night pitti, see you in two or three hours? :)
<cjwatson> pitti: it really is dpkg-distaddfile, you just don't see it in the UI
<cjwatson> pitti: but follow the link to the build log and you'll see it being added there
<hallyn_> pitti: thank  you!
<cjwatson> (the modelling of custom uploads in LP's database is ... inadequate, which is why the web UI doesn't display them)
 * Laney showers, hopefully this is published shortly and I can check it
<bdmurray> Laney: I'm testing it already fwiw
<Laney> bdmurray: me too, but your internets are probably more internet than my internet
<sarnold> hehehe
<israeldahl> Hi all, can anyone point me to any documentation on building a custom PowerPC ISO.
<israeldahl> I have already built for x86
<israeldahl> 32 bit and 64bit are not hard to do (for me) using deboostrap and chroot... but PowerPC is harder does anyone know the secret?
<Laney> bdmurray: OK, finished(!) and I don't see those messages now
<bdmurray> Laney: neither do I
<israeldahl> Does anyone know where documentation to build a Power PC chroot is?
<israeldahl> I have PPC and x86.  I would like to do it on x86 (if possible) but would be willing to use PPC if I have to
<israeldahl> Does debootstrap work with chroot on PPC?
<sarnold> israeldahl: wouldn't debootstrap on the ppc work?
<sarnold> heh
<cjwatson> Native debootstrap always works.  Our own build processes rely on it.
<israeldahl> thanks cjwatson
<Laney> bdmurray: unless you want to take care of it I'll sru-release in the morning
 * Laney sleeps now, night
<israeldahl> cjwatson is it possible to use qemu or something to do it on x86?
<cjwatson> If you were doing it on x86 then in practice you would need to grab an existing powerpc image and use qemu-system-powerpc.  It would be slow.
<cjwatson> qemu-system-ppc, sorry
<cjwatson> In theory you can probably start the process with on-the-fly per-process emulation using qemu-user-static, but in practice you would run into trouble somewhere along the line with that approach.
<israeldahl> cjwatson you mean I would need to loop mount the iso and chroot in?
<cjwatson> If you have a powerpc system then the path of least resistance is definitely to use that.
<cjwatson> qemu-system-ppc != chroot.  Anyway, go native if you can.
<israeldahl> cjwatson thanks I will try it.  I have scripts for building on x86, so everything should be pretty much the same (except kernel names) but the process functions the same, correct?
<cjwatson> Then you don't need qemu and everything's much simpler and quite probably faster as well, unless your powerpc system is exceptionally slow.
<cjwatson> Right.
<cjwatson> Well, and the top-level ISO bits are a bit different.
<israeldahl> cjwatson does isolinux (this is precise based) work the same for PPC?
<cjwatson> It's not in a shape that you can run directly, but the stuff in "bzr branch lp:~ubuntu-cdimage/debian-cd/ubuntu debian-cd" (directory tools/boot/trusty/ etc.) at least shows you the options we use
<cjwatson> isolinux is x86-specific, and does not work in any way, shape, or form for powerpc
<israeldahl> cool thank you I will totally check it out!
<israeldahl> ok so I need yaboot and all that
<cjwatson> right, or in theory grub but our current images are yaboot-based
<israeldahl> Great cjwatson you have been very helpful!  I may pop back in after a few days if I need more insight
<israeldahl> you rock :)
<cjwatson> np
#ubuntu-devel 2015-10-22
<israeldahl> cjwatson can I ask you where your genisoimage stuff is for ppc?
<dholbach> good morning
<Laney> mvo: hi, nobody knows how to update changelogs.ubuntu.com, any chance you can teach? :)
<Laney> and hi!
<Laney> 1. bzr up; 2. cp; seems to be it
<seb128> Laney, what is to update on there?
<seb128> Laney, ignore that
<pitti> seb128: point to the update tarball in wily-updates
<seb128> yeah, stupid question :p
<pitti> we really don't want to respin for that
<mvo> Laney: sure! bdmurray also knows
<mvo> Laney: but yeah, its just that, update branch, cp in place (diff before for good karma) :)
<Laney> mvo: I'm guessing bdmurray is in bed now. :P
<Laney> mvo: how's it going, btw?
<mvo> Laney: indeed
<mvo> Laney: good, snappy is planed to release today as well
<mvo> Laney: so I'm excited about two releases at the same day!
<Laney> nice
<Laney> twins!
<mvo> lol
<mvo> Laney: and you? all good?
<mvo> 15.10 looks great on my machines so far
<Laney> yep, I'm in BF now rounding off the last corners
<rbasak> So I got bitten by a missing lvm2 after I do-release-upgraded to Wily yesterday, making my system unbootable.
<rbasak> I thought it got autoremoved, but now I'm wondering if I ever had lvm2 installed in the first place. I have been using cryptsetup on disk block devices directly for years. So device mapper but no LVM.
<rbasak> Is it possible that I never had lvm2 installed, it worked before, but latest cryptroot now requires lvm2 to be installed so that's why I broke? And could that apply to others?
<rbasak> No sign of lvm2 in /var/log/apt/ except when I installed it to fix the issue.
<infinity> rbasak: Are you saying cryptsetup and/or dmsetup has an undeclared dep on lvm2?
<rbasak> Maybe, yes. Although I can't find it in the code right now, my system seemed to be broken until I installed lvm2.
<rbasak> I did have another issue though so I'm not absolutely sure.
<rbasak> (and that wone was my fault)
<pitti> rbasak: and it wasn't just that this triggered an initramfs rebuild or the like?
<pitti> I just did like 10 test installs with encrypted swap at least, which does need a good chunk of the cryptsetup stuff
<pitti> (without LVM)
<infinity> A failed upgrade may have also failed to run update-initramfs, this is a fair point.
<rbasak> Hmm.
<rbasak> My upgrade did also fail because of the invoke-rc.d issue.
<pitti> a week or so ago I installed the wily daily with encrypting / and /home partitions, without LVM
<pitti> (i. e. manual partitioning), which worked fine too
<rbasak> So my case muddled multiple issues up so I'm not entirely clear on the individual issues.
<pitti> (as part of investigating bug 1506139)
<ubottu> bug 1506139 in systemd (Ubuntu) "15.10beta crashes encrypted swap partition" [High,Incomplete] https://launchpad.net/bugs/1506139
<rbasak> Also I failed to mount /boot on my first attempt to run update-initramfs on the failed booted system so that confused things further.
<pitti> rbasak: so if you can reproduce this somehow, running update-initramfs -u instead of installing lvm might be insightful
<pitti> rbasak: or, do you still have that system? does it still boot after purging lvm again?
<pitti> rbasak: invoke-rc.d issue is fixed now, btw
<rbasak> It's my main system.
<rbasak> I could try removing lvm2, making sure update-initramfs has run and then see what happens.
<pitti> rbasak: keep an ubuntu live system usb stick around, just in case :)
<rbasak> pitti: :)
<pitti> this do-release-upgrade bug was quite a bummer indeed :/
<rbasak> pitti: I have an external USB drive caddy thing that can make .iso files on it pretend to be USB CDROMs.
<rbasak> It has a menu thing on it so I can select what to boot. Very handy.
<infinity> rbasak: Neat.
<rbasak> So when I traced the problem yesterday, I was getting the error "cryptsetup: lvm is not available" sent to plymouth. I tracked that down in my initramfs to be coming from cryptroot, IIRC, after a test for /sbin/lvm.
<rbasak> But now I don't see that code at all, nor that string.
<pitti> wow
<rbasak> So I think I might have just had an out-of-date initramfs
<rbasak> Possibly caused by the invoke-rc.d failure? Though I did do an "apt-get -f install" afterwards so I'm surprised update-initramfs didn't run then.
<pitti> rbasak: how did you fix the upgrade, btw? apt-get -f install and another dist-upgrade?
<rbasak> Yes, which actually did nothing.
<rbasak> I did an autoremove after that, which removed a ton of things, but not lvm2 according to my logs.
<pitti> rbasak: apt-get -f install ought to have done a lot of stuff; it didn't?
<pitti> dist-upgrade, maybe not
<rbasak> Not that I recall
<rbasak> Logs say otherwise
<rbasak> No that's September. Hmm.
<rbasak> Yeah no sign of dist-upgrade having run in my logs. Presumably because it did nothing as I recall?
<rbasak> Anyway, I don't think that's related.
<rbasak> OK I figured it out
<rbasak> It's a useless error message, that's all.
<rbasak> If cryptroot can't find the source block device, it tries to activate LVM vgs. If that fails because lvm2 wasn't installed, then it prints "cryptsetup: lvm is not available".
<rbasak> Even though the root cause is that the block device doesn't exist rather than LVM not being available (which was irrelevant in my case)
<rbasak> Only after I installed lvm2 and re-ran update-initramfs did I see the real issue, which was that /dev/sda3 (or whatever) was missing because my printer made it become /dev/sdb3.
<cjwatson> your *printer*?
<cjwatson> please feed paper with printed bootloader to boot.
<rbasak> I didn't switch to UUIDs yesterday incidentally. I have no idea what to do about cswap because presumably the UUID will change every boot.
<rbasak> Yep. My printer.
<rbasak> Apparently it presents a disk.
<rbasak> I presume that disk has drivers for Windows or something.
<cjwatson> awesome.
<cjwatson> (or maybe you can send files to it that way?)
<cjwatson> it would make sense for a scanner.
<rbasak> My solution for now (because I don't know what to do with crypted swap) is to turn off the printer before booting.
<rbasak> It is also a scanner.
<rbasak> SO yeah, maybe.
<cjwatson> there's a luksUUID which can go in crypttab
<cjwatson> I think
<cjwatson> cryptsetup luksUUID thingy
<rbasak> Will that change every time if I used /dev/random for the swap key, though?
<cjwatson> then that goes as the second field in crypttab
<rbasak> And the "swap" option?
<cjwatson> I don't *think* so ...
<rbasak> Thanks! I'll try that.
<cjwatson> this is all vague memory though I'm afraid
<rbasak> Not now though. It's a pain to recover and it's my main machine so I'll be offline for too long I think.
<pitti> rbasak: you either use luks or you use /dev/random as a key, you can't have both
<rbasak> There is a bug in the cryptroot initramfs script I should report about the misleading error message though.
<cjwatson> ah I forgot /dev/random was non-luksy
<pitti> rbasak: but ecryptfs-setup-swap now uses an offset=1024 for a "random key" swap partition to preserve the partition type header and UUID
<pitti> rbasak: so you can use UUID= in crypttab, and it'll stay around
 * rbasak wonders what that has to do with ecryptfs
<pitti> this was one of the ancient bugs in ecryptfs which only got uncovered in vivid
<pitti> rbasak: ecryptfs-setup-swap is being used if you choose to encrypt your home dir, and that sets up a randomized encrypted swap partition
<pitti> rbasak: i. e. it's what the installer uses
<pitti> if you do this by hand, you can do whatever schema, of course
<rbasak> Ah. I'm not using ecryptfs
<pitti> but I recommend sticking to UUIDs, for the non-reliable names you mentioned
<rbasak> pitti: so with a crypttab of: cswap		/dev/sda1		/dev/random	swap
<pitti> rbasak: yeah, no uuids with that
<rbasak> I can made sda1 UUID and it'll work?
<rbasak> Because it does the offset thing?
<pitti> rbasak: /dev/random'izing the entire  partition doesn't leave anything stable behind
<pitti> rbasak: the approach of e-setup-swap is to mkswap on the partition normally, and use offset=1024 in crypttab to keep the first 1 KiB intact
<pitti> rbasak: then you can use the UUID of sda1 instead
<rbasak> So: cswap UUID=... /dev/random offset=1024,swap?
<pitti> yes
<rbasak> Got it. Thanks!
<pitti> rbasak: you can also literally use ecryptfs-setup-swap (after creating an unencrypted swap), that'll set up everything
<rbasak> Hmm.
<rbasak> I'm not keen on it using /dev/urandom.
<rbasak> Very little entropy available at boot. Many people's swap keys might end up the same.
<rbasak> (or from a limited set)
<rbasak> Maybe not so bad for bare metal. I don't know.
<rbasak> Anyway, thank all. I can make many improvements based on this.
 * pitti found http://www.2uo.de/myths-about-urandom/ an interesting read
<rbasak> "Linux's /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer."
<rbasak> That's the bit I mean.
<rbasak> After a while it's fine. But I'm not convinced about the entropy available in initramfs.
<pitti> rbasak: right, I wasn't saying you were wrong, just that it's an interesting read (I happened to remember while we were talking about it)
<rbasak> Ah OK, sorry.
<pitti> but nevertheless, hanging eternally in initramfs doesn't sound appealing either
<rbasak> It doesn't seem to hang much for me.
<pitti> and if it rarely/never hangs, then urandom is just as good as random
<rbasak> Agreed. I guess it depends on what failure case you want. I want hang rather than boot with poor swap key entropy :)
<pitti> rbasak: but yeah, feel free to talk kirkland into changing it to /dev/random (but I'm not convinced that this is a good idea especially for virtual envs)
<pitti> rbasak: well, what *I* really want is to stop creating swap partitions by default
<pitti> it's IMHO so utterly EBW
<pitti> if you set them up manually, fine
<rbasak> Why? EBW?
<rbasak> You want swap files instead, or no swap at all?
<pitti> rbasak: on machines with reasonaly much RAM, no swap at all; or at most dynamic swap files, yes
<pitti> rbasak: because they are usually just a waste of space, and we managed to screw them up for many years
<rbasak> A property of swap I like is that memory leaks or forgotten background process data ends up in swap, leaving my system RAM more available for buffers and cache (and less likely to OOM). Convenient on long lived systems.
<pitti> i. e. due to at least three different bugs we managed to set up systems without swap space since pre-trusty, and nobody complained :)
<rbasak> A property of swap I don't like is that thrashing happens instead of OOM in various error conditions.
<rbasak> I'd like some swap thrash detection that activates the oom killer.
<rbasak> I was surprised to see that my Ubuntu phone has swap in it.
<rbasak> I have a slow disk (never bought an SSD) so having plenty of RAM available for caching is important to me.
<popey> rbasak: I'd rather the shell and indicators were swapped out when webbrowser eats ram, than the shell getting oomkilled repeatedly
<popey> (obv I'd rather browser didn't eat ram, but hey, can't have it all)
<rbasak> popey: that's just a case of tuning the oom parameters and limiting memory available to apps though, right?
<rbasak> A swapped out shell and indicators reflects badly on the performance of the phone as a whole.
<popey> depends how quick you can swap them back in
<rbasak> And makes it difficult to kill the browser if I want, too.
<xnox> how to correctly mark upgrade bugs, to be flagged up?
<xnox> https://bugs.launchpad.net/ubuntu/+source/libsolv/+bug/1508921
<ubottu> Launchpad bug 1508921 in libsolv (Ubuntu) "possibly missing correct replaces/breaks" [Undecided,New]
<Laney> upload in the unapproved queue? :)
<xnox> Laney: hehe
<xnox> Laney: i would like to trow a toy out of my crib and claim i'm a customer =))))))))))))))
<xnox> anyway 1.2k packages to upgrade still
<doko> seb128, Laney: looks like a regression introduced with glib2.0? https://launchpadlibrarian.net/221953895/buildlog_ubuntu-wily-amd64.ubuntu-app-launch_0.5%2B15.10.20150817-0ubuntu1_BUILDING.txt.gz
<Laney> in what way?
<Laney> looks like a function which returns a bool is not doing so to me
<doko> well, it built before, now fails
<seb128> doko, seems like a but in ubuntu-app-launch bug
<seb128> yeah
<Laney> because they fixed g_return_if_fail to work
<seb128> doko, remember the bug I pinged you about recently that turned out to be a glib one
<seb128> that's what fixed that error to work
<seb128> doko, https://git.gnome.org/browse/glib/commit/?h=glib-2-46&id=ab26dd54337544275ff8bb61eb227aed83a8ed80
<doko> ohh, that one
<doko> hmm, didn't touch doxygen, but https://launchpadlibrarian.net/221968264/buildlog_ubuntu-wily-amd64.xorg-gtest_0.7.1-0ubuntu1_BUILDING.txt.gz ...
<doko> tjaalton, could you have a look at https://launchpadlibrarian.net/221956818/buildlog_ubuntu-wily-amd64.xorg-server_2%3A1.17.2-1ubuntu9_BUILDING.txt.gz ? this is with the binutils from the ubuntu-toolchain-r/power8 PPA
<tjaalton> doko: so it's not powerpc or ppc64el?
<tjaalton> hmm no, I see the bug now
<tjaalton> guess it has never built?
<tjaalton> oh amd64 too, I'm blind
<tjaalton> so why is it checking for Xmir twice?
<tjaalton> ..because it runs configure for two targets in parallel
<tjaalton> dunno why it fails, tbg
<tjaalton> *tbh
<tjaalton> can't find libmirclient, though it's installed
<tjaalton> I'll let ancell figure this out..
<smoser> anyone want to ack or violently nack my suggested patch https://code.launchpad.net/~smoser/ubuntu-dev-tools/lp1508948-rmadison-sid-is-unstable/+merge/275351
<rbasak> smoser: ah, you pinned that down in the end? Good job.
<smoser> \o/
<smoser> now i can use rbasak's git workflow without dget :)
<xnox> dget is dead =) use dgit!
 * xnox giggles
<smoser> we should improve https://github.com/basak/ubuntu-git-tools to just automatically do the imports.
<rbasak> Yes.
<rbasak> Though I also want to have a central place for imported git trees
<rbasak> And I think the plan is that eventually LP will have a git tree available for every package
<rbasak> At which point no need to import
<cjwatson> yes we definitely want to do dgit on LP
<cjwatson> including with default package repository locations so that it's lp:ubuntu/+source/SRC
<cjwatson> but I need to fix dgit to handle LP first
<xnox> \o/
* infinity changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<disposable> ls
<infinity> xnox: Going to come to the office to visit and pat us all on the back?
<xnox> infinity: today? tomorrow? =)
<infinity> xnox: In a couple of hours.
<Laney> Come help us open Xenial
<xnox> infinity: i am busy between 5:30 and 6:30. Coming before is cutting it close, so can come in after =)
<xnox> infinity: i'll text Laney
<pitti> pete-woods: released/uploaded dbusmock 0.16.1, and uploaded backports to vivid+wily overlay PPA
<pitti> pete-woods: sorry for the delay, release week "fun" and all that
<doko> barry, make python3.5 the default from the start, or wait until later?
<pete-woods> pitti: no worries. I understand you have a very busy role. thanks very much! :)
<doko> tvoss, great, the last MIR updated dropped the mir-client-platform-mesa-dev file ...
<doko> tjaalton, it's https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1509005
<ubottu> Launchpad bug 1509005 in mir (Ubuntu) "mir-client-platform-mesa-dev pkg-config file dropped" [Critical,Confirmed]
<tjaalton> doko: ah :)
<seb128> kgunn, ^
<kgunn> seb128: doko tjaalton ack, getting someone from mir team to hop on that
<barry> doko: i'd opt for the sooner the better.  do you think we should wait for uos or the sprint?
<doko> barry, I'm fine with it, but we probably need some quick fixing tomorrow and next week
<barry> doko: will you do an archive rebuild afterward making it default?  yes, let's get fixes in asap
<doko> barry, take this one, from yesterday, with 3.5 as the default: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20151021-wily.html  main only
<barry> doko: doesn't look too bad.  let's wait on django until 1.8 hits unstable
<doko> barry, why? it's in experimental, you could it sync from there too
<barry> doko: that's true.  i think there's still some question about the django stack compatibility w/1.8, but django itself won't be 3.5 compatible if we don't sync it.  let's do it
<barry> and we'll just follow debian during this transition
<doko> ok
<barry> doko: what's the eta for xenial opening?
<doko> should be ready tonight for toolchain uploads
<barry> doko: +1
<doko> barry, http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5.html
<barry> doko: ack
<Luke> alesage: ping
<alesage> Luke hi
<Luke> did you take the picture on your G+ background?
<Luke> of chicago
<alesage> Luke no I didn't
<Luke> do you know who did?
<Luke> looks awesome btw
<alesage> Luke hmm good q, might be able to trace
<alesage> Luke, glad you like it
<Luke> reverse search? yeah
<alesage> Luke, I must've encountered it here (reverse-search FTW) https://www.reddit.com/r/chicago/comments/2e51og/tilt_shift_of_downtown/
<Luke> cool thanks
<rcj> How do I make LP aware of the upstream git tree for a package such that MoM will take over and keep things fresh?
<rcj> Specifically http://pad.lv/u/keychain needs to know about https://github.com/funtoo/keychain
<sarnold> infinity: (from dasjoe in #ubuntu-server) is http://cdimage.ubuntu.com/releases/wily/release/ supposed to have only ppc64el and powerpc images? thanks  :)
<knome> slangasek, heya! thought i'd ping you about the xubuntu core merge proposals now; we'd totally prefer to merge the patches now without needing to rebase. and congrats for the release! :)
<cjwatson> rcj: MoM has no awareness of upstream trees, nor of upstream in general.  Its purpose is to merge things from Debian.
<cjwatson> rcj: And even then it's only informational, it won't do things for you.
<jgjl> Hi, yay for 15.10!
<jgjl> any hints where to find the poll mode drivers for DPDK?
<rcj> cjwatson, thanks for clearing that up
#ubuntu-devel 2015-10-23
<pitti> Good morning
<pitti> doko: uh, does xenial's gcc-5 change anythihng significantly? I did a test libpng run on ppc64el, and it crashes with "cc1: internal compiler error: Illegal instruction"
<pitti> (armhf is fine)
<pitti> doko: "Target POWER8 on ppc64el" -> that?
<pitti> doko: I suppose wolfe is not that yet
<pitti> infinity, slangasek, doko: ^ so if this is deliberate (I suppose it is), is there some power8 hardware which we could use for running autopkgtests? or should we stop testing xenial on ppc64el for now?
<dholbach> good morning
<mgedmin> how come some -dbgsym packages are available only for i386?  (e.g. gjs-dbgsym)
<seb128> mgedmin, what do you mean? https://launchpad.net/ubuntu/+source/gjs/1.43.3-2build1/+build/7778128/+files/gjs-dbgsym_1.43.3-2build1_amd64.ddeb
<seb128> (https://launchpad.net/ubuntu/+source/gjs/1.43.3-2build1/+build/7778128)
<mgedmin> huh
<mgedmin> my apt does this: http://paste.ubuntu.com/12900653/
<seb128> mgedmin, dpkg -l | grep gjs ?
<mgedmin> http://paste.ubuntu.com/12900658/
<mgedmin> (amd64)
<seb128> hum, your issue seems more a multiarch one
<seb128> sudo apt-get install gjs-dbgsym:amd64 ?
<mgedmin> gjs-dbgsym doesn't appear in the Packages file for amd64: http://paste.ubuntu.com/12900661/
<mgedmin> check http://ddebs.ubuntu.com/dists/wily/universe/binary-amd64/Packages
<seb128> pitti, ^
<mgedmin> libmozjs-24-0v5-dbgsym is another package with this issue
<mgedmin> while libglib2.0-0-dbgsym can be installed with no problems
<seb128> mgedmin, you can get the deb manually meanwhile
<seb128> unsure what's the deal with ddeb nowadays
 * mgedmin once again dreams about symbol servers
<seb128> we have them in launchpad but unsure if there is an apt index there
<pitti> hmm, no immediate idea; I'll put it on my todo list
<seb128> symbol servers?
<mgedmin> indexed by buildid's that are embedded in elf binaries
<pitti> http://ddebs.ubuntu.com/pool/universe/g/gjs/ also has them
<pitti> they are just missing in the index
<mgedmin> seb128, https://randomascii.wordpress.com/2013/02/20/symbols-on-linux-part-three-linux-versus-windows/
<seb128> mgedmin, I see, well ddebs with apport usually work fine, there is just an index/server issue there
<doko> pitti, slangasek: better stop then ... until you get hardware.
<pitti> doko: I'll re-ask on the RT ticket for getting ppc64el in scalingstack
<Mirv> dholbach: hmm, I'm not seeing any UOS calls on ubuntu-devel lists other than September's proposed dates
<dholbach> Mirv, how can I help?
<seb128> Mirv, it's on -announce
<seb128> Riddell, good luck for whatever you do next, I hope you have more fun that you had recently with all those discussions!
<Riddell> thanks seb128 :)
<cjwatson> pitti: I think you should be able to get access to bos01 scalingstack for autopkgtests.
<Mirv> dholbach: oh, announce as mentioned, no problem :)
<pitti> cjwatson: thanks; I pinged the RT again
<doko> jamespage, tyhicks:  https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1363356  looks more like an openssl update issue, seen for openstack too
<ubottu> Launchpad bug 1363356 in python-defaults (Ubuntu) "ssl.SSLEOFError: EOF occurred in violation of protocol" [Undecided,Confirmed]
<pitti> sil2100: is rtm 14.09 still a thing? i. e. do I need to keep running http://ddebs.ubuntu.com/ubuntu-rtm/, or can it be mothballed?
<sil2100> pitti: hey! I think the grace period for ubuntu-rtm/14.09 has now passed
<sil2100> I don't think there's any reason to keep that
<pitti> sil2100: ack, tahnks
<doko> pitti, apport autopkg test failures
<pitti> doko: yep,  known; fixed in trunk already
<pitti> doko: for the current version the hint is still in place
<pitti> hm, quite some regressions due to uninstallability
<pitti> doko, infinity ^ I'll retry them once the queue settled down
<doko> pitti, need to build some python3.5 extensions for that. waiting for gcc-5 to be published
<doko> barry, xnox: looking at http://people.canonical.com/~ubuntu-archive/transitions/html/onlypy3oncd.html  how up to date is this? e.g. libreoffice looks fine?
<xnox> doko: it is a manually updated list.
<xnox> doko: there is a script in the branch to regenerate said tracker....
<xnox> cause the seeds move often, and it's just a static list/table really.
<doko> xnox, which branch?
<xnox> doko: well the code lists it =)
<xnox> http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/view/head:/monitor/ongoing/onlypy3oncd.ben
<xnox> title = "Python3 only on CDs (xnox, barry, see lp:~dmitrij.ledkov/+junk/onlypy3oncd)";
<xnox> no idea if that is actually still usable though, may have bit rotted
<doko> ahh
<xnox> and that's not my lp id any more....
<xnox> so lp:~xnox/+junk/onlypy3oncd
 * xnox goes to try it.
<doko> ta
<xnox> doko: omg, that thing is a python2 script that connects to barry's spreadsheet....
<xnox> on google docs. I bet it's all wrong.
<doko> heh
<xnox> i bet what i should have done is download a binary package list, map them to source packages and validate none depend on python3.
<xnox> or rather none depend on python2 exclusively.
<xnox> doko: we don't have a current oustanding list is the short answer =)
<doko> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3 is the one I am tracking
<doko> so maybe better remove this tracker
<doko> barry, looks like python-coverage needs a new upstream. somehow important, because a lot of things are uninstallable until this gets fixed
<Mirv> doko: can you look at bug #1509356 , jgdx can't build on xenial because of that
<ubottu> bug 1509356 in pep8 (Ubuntu) "pep8 depends on python3-pep, not python3-pep8" [Undecided,New] https://launchpad.net/bugs/1509356
<doko> Mirv, mehh, typo ...
<pitti> ah, I saw quite some test failures due to that too, I think
<doko> fixing
<pitti> danke!
<Mirv> +1!
<mapreri> cjwatson: can you unblacklist scribus from syncing now that wily is out and xenial is on its way? :)
<doko> mitya57, https://launchpadlibrarian.net/222306433/buildlog_ubuntu-xenial-amd64.relational_2.1-1_BUILDING.txt.gz   the shebang really should be the unversioned python3 interp
<cjwatson> mapreri: done
<mitya57> doko, why me? I don't know what relational is
<mapreri> cjwatson: â¥
<doko> mitya57, but you are suspicious about pyqt ;p
<doko> or better, the suspect
<mitya57> Ok, I can take a look, not right now though
<stokachu> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: closed | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
<Odd_Bloke> wgrant: cjwatson: infinity: Which kernel package should I be using for powerpc?  linux-image-powerpc-smp?
<cjwatson> Odd_Bloke: The stock images have powerpc-smp and powerpc64-smp installed.  But for cloud images I'd have thought powerpc64-smp would be a better choice.
<cjwatson> Odd_Bloke: That's what the current LP builders are using.
<cjwatson> And surely anything you might want to run a cloud on has 64-bit support ...
<pitti> mgedmin, darkxst, seb128: ddeb indexes should be okay now, gjs and libmozjs* are at least there
<cjwatson> (You could tell lb to install both, but I don't know if it's worth the effort.
<cjwatson> )
<infinity> Odd_Bloke: Should just be powerpc64-smp
<Odd_Bloke> cjwatson: Ah, I think I must be labouring under a misapprehension.  I'm assuming that powerpc is to ppc64el as i386 is to amd64; have I got the wrong end of the stick?
<infinity> Odd_Bloke: That's the only one that will work the way we'll be booting in openstack.
<infinity> Odd_Bloke: powerpc *userspace* is 32-bit, but the vast majority of machines (including the KVM instances) are 64-bit, hence the 64-bit kernel.
<Odd_Bloke> Aha, right.
<cjwatson> (The analogy there also doesn't quite work because of the endian flip, but that's not relevant here.)
<infinity> It's entirely possible that the only person in the world who uses the 32-bit kernel is me. :P
<cjwatson> It was relevant on some pretty old hardware, indeed.
<infinity> Odd_Bloke: Anyhow, all you need to know is powerpc64-smp, boots in qemu-system-ppc64, same as ppc64el images do.
<infinity> (Even on x86, though the emulation isn't desperately fast)
<seb128> pitti, great, thanks
<mitya57> doko, bug for relational: debian #802781
<ubottu> Debian bug 802781 in relational "relational: Please fix X-Python3-Version value" [Important,Open] http://bugs.debian.org/802781
<infinity> doko: That openjdk-9 in wily-proposed, is that meant to become an SRU, or should it be moved to xenial-proposed?  (or just deleted, since it's FTBFS on armhf?)
<doko> mitya57, yep, this one too. still looking at pyqt5
<infinity> doko: Hrm, I guess it was NEW, hard to see how that could be an SRU.
<mitya57> What's wrong with pyqt5?
<doko> infinity, no, just remove it. already uploaded to xenial for the giflib soname bump
<infinity> doko: Alright.
<Odd_Bloke> infinity: cjwatson: Thanks for the explanation, very clear. :)
<doko> mitya57, /usr/bin/pyuic5: 2: exec: /usr/bin/python3.4: not found
<doko> without a dep on python3.4
<mitya57> doko, you did rebuild pyqt5, right?
<doko> mitya57, not yet
<doko> mitya57, but then it will still have a python3.5 shebang without a dep on python3.5
<mitya57> doko, I see, will commit a fix soon
<doko> mitya57, ta, then it will be good for to just do a rebuild =)
<doko> for me, even
<mitya57> Yes, and then I'll sync the new version from Debian when it's ready
 * doko tries to figure out the cantor ftbfs ...
 * infinity adds xenial to rmadison.
<doko> mitya57, http://launchpadlibrarian.net/222321211/pyqt5_5.4.2%2Bdfsg-1build3_5.4.2%2Bdfsg-1ubuntu1.diff.gz
<doko> calling dh_python3 with --shebang won't help
<mitya57> doko, thanks
<mitya57> Though I will place it in install-arch target
<doko> sure
<mitya57> committed
<doko> barry, are you looking at python-coverage, or should I?
<barry> doko: i am not yet.  i'm still trying to fix a very problematic debian bug to unblock a bunch of other things
<doko> ok
<doko> mitya57, I assume we can drop the preinst delta now?  https://patches.ubuntu.com/p/python-coverage/python-coverage_3.7.1+dfsg.1-1ubuntu3.patch
<Kaleo> doko, just filed https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396
<ubottu> Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [Undecided,New]
<Kaleo> broken by http://launchpadlibrarian.net/222126620/pep8_1.6.2-0.1_1.6.2-0.1ubuntu1.diff.gz
<bfiller> doko: thanks for your help on that one, it's currently blocking one of our dual landings
<doko> seb128, are you sure about the glibmm2.4 sync? mbiebl was asking me why we reverted that version. I'd like to reject it
<doko> bfiller, ???
<bfiller> doko: https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396
<ubottu> Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [High,New]
<seb128> doko, unsure, but why shouldn't we follow Debian? I don't know exactly why robert reverted it previous cycle
<seb128> and why are xenial uploads manually approved?
<doko> seb128, because it assumes c++11 in its header files, and you'll have to fix every reverse build dependency explicitly
<doko> still trying to get the toolchain into -release
<seb128> well, if Debian does that and we go the other way, does it mean we have to diverge on things they "fix"?
<doko> seb128, debian will have a compiler which defaults to c++14 in the end, xenial won't have this
<seb128> k, your call, I don't understand enough of what is involved to have an opinion
<doko> seb128, lets wait for the decision in debian; I think mbiebl_ is still unsure about it
<seb128> doko, note that the new gtkmm got synced in wily
<seb128> unsure if that's on the same line
<seb128> doko, ok
<doko> seb128, I don't know, in wily only glibmm had the c++11 header files
<seb128> k
<doko> I mean, it is fixable, but if debian doesn't do it because it gets "fixed" by a new compiler default, we have to do it
<seb128> yeah, let's wait for that then
<seb128> no hurry  in getting the new version
<seb128> doko, we have a pending libreoffice change to upload, it's a bit of a waste of builders to do a non change rebuild :-/
<doko> seb128, didn't see one in the queue =)
<doko> feel free to cancel and upload the new one
<seb128> doko, yeah, it's waiting sponsoring
<seb128> let me check with Bjoern
<doko> jamespage, zigo: please could you discard your openstack packaging rules, and just use plain pybuild for the future? this home grown template adds a lot of issues ... https://launchpadlibrarian.net/222329745/buildlog_ubuntu-xenial-amd64.python-json-patch_1.3-5build1_BUILDING.txt.gz
<jamespage> doko, sorry being dumb - what's the specific problem?
<jamespage> the openstack packaging rules don't do much with regards to actually building a py package from memory
<doko> jamespage, the problem (wily, and x) is that you always have a dependency on a versioned python3 interpreter
<doko> because the shebang is the versioned interpreter name
<jamespage> doko, please can you raise a bug - I'll discuss face-to-face with zigo next week in tokyo
<jamespage> I'm sure we can sort out a better way forward
<doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/python-rtslib-fb/+bug/1509422
<ubottu> Launchpad bug 1509422 in python-rtslib-fb (Ubuntu) "package uses versioned shebangs" [Undecided,New]
<jamespage> doko, so its the looping over py versions for install causing the problem right?
<doko> jamespage, yes. pybuild has support to call the default version last as unversioned interp
<mitya57> doko, yes we can drop that coverage delta
<doko> mitya57, now if that package would build ...
<mitya57> doko, it's pybuild automatic tests running thing that broke it. I think you can export PYBUILD_DISABLE=test and file a Debian bug for Ben so that he can look at that
<barry> doko: can you take a look at debian bug #802792?  i'd really like to get that patch into python-setuptools so i can start to unwind all the crappy broken workarounds in packages that are blocking other people
<ubottu> Debian bug 802792 in python-setuptools "Prune Debian artifact directories from SOURCES.txt" [Normal,Open] http://bugs.debian.org/802792
<mitya57> doko, let me check if it FTBFS in Debian too, if it does, I'll file a RC bug myself
<doko> barry, I'm afk in 10min, will look at it tomorrow
<barry> doko: ok thanks.
* infinity changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
<slangasek> pitti: the hardware is in scalingstack, you should be able to cut over to doing the tests on there
<slangasek> pitti: ... which is an answer you already got, ok :)
<smoser> slangasek, or pitti
<smoser> either of you,.
<mitya57> Archive open \o/
 * mitya57 starts breaking it
<stokachu> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zigo> doko: What exactly is the problem with the type of debian/rules I'm using?
<zigo> doko: It's been the way to do it for years, in order to support multiple versions of Python.
<zigo> doko: Like, when there was Python 2.6 and 2.7.
<zigo> doko: I'm always for improvements, so I'd be happy to read your advices, though I don't really want to use Pybuild.
<tumbleweed> and there are now much better ways?
<bdrung> is xenial open for upload?
<doko> zigo, you are hard-coding a specific python3.X version, generating a python3.y dependency. see LP: #1509422
<ubottu> Launchpad bug 1509422 in python-rtslib-fb (Ubuntu) "package uses versioned shebangs" [Undecided,New] https://launchpad.net/bugs/1509422
<doko> zigo people are then touch your packages twice for a transition, compared to not touching them using a python3 shebang
<zigo> doko: I still don't understand where the hardcoding is.
<doko> zigo, do you see that you end up with a python3.x dependency?
<zigo> doko: Isn't dh_python3 supposed to fix the shebang?
<doko> zigo, see dh_python3(1)
<zigo> doko: I'm not even overriding dh_python3, so if there's an issue, it really is with dh_python3 itself, no?
<zigo> doko: I've just had a look in rtslib-fb, and indeed, I see a python3.5 shebang...
<doko> dh_python3 doesn't override the shebang by default
<zigo> doko: Don't you think it should?
<zigo> doko: If the issue is to ask dh_python3 to do so, then I can do that...
<zigo> doko: That's "only" a few dozen of uploads, I'm not scared of that, if that helps you to do the transition.
<zigo> doko: Do I understand well that the issue is "only" the shebang?
<tumbleweed> zigo: why not use pybuild? It calls the default python3 as python3, not python3.X, so the shebang would be right in the first place
<tumbleweed> (I assume, that's what the dh python_distutils plugin always did)
<doko> zigo: this "only" costs people time.
<zigo> tumbleweed: Looking at the rtslib-fb package which we took as example, I'm simply using "dh $@ --buildsystem=python_distutils --with python2,python3", so nothing fancy.
<tumbleweed> zigo: you're overriding the build rules with your own loops
<zigo> doko: It is my time that we're talking about here, so the concern is only for me.
<doko> zigo: wrong, this time for people handling transitions, both in Debian and Ubuntu
<zigo> Sorry to hear that... :/
<doko> have the correct shebang, and I wouldn't even notice your build system ;-P
<zigo> doko: Is there a way to list all of the "broken" packages that I have, IE, all what's in the OpenStack PKG group with stuff in /usr/bin?
<doko> bdrung, don't break it ;p
<tumbleweed> also, zigo, (unrelated) if you pass --buildsystem=python_distutils to dh, you don't have to pass it to every dh_command in every override. It sets an environment variable to do that
<zigo> tumbleweed: Ah, thanks for the tip.
<doko> zigo: every binary package with a python2.Y or python3.Y dependency should be considered broken. there might be some exceptions
<doko> for python2.7 nobody cares anymore
<tumbleweed> hrm, we should probably have lintian rules for this
<bdrung> doko, i break enough stuff at my day job. so no need to break xenial at night ;)
<zigo> doko: I had a look in rtslib-fb, and the dependency really is python3:any, so I don't think there's an issue with dependency.
<tumbleweed> zigo: that's not the only dependency
<zigo> tumbleweed: What do you mean?
<tumbleweed> zigo: Depends: python-rtslib-fb, python3:any (>= 3.3.2-2~), python3.4
<doko> zigo: in sid:
<doko> $ apt-cache show python3-rtslib-fb|grep Depends
<doko> Depends: python-rtslib-fb, python3-six, python3.5, python3:any (>= 3.3.2-2~)
<zigo> Ah, right... :/
<doko> so you even pull in 3.5, even if it is not yet the default
<zigo> Well, that's because of the shebang, no?
<doko> yes
<zigo> Ok.
<zigo> I'll have a look asap.
<zigo> My little girl is crying, I have to take care of her now... :(
<doko> zigo, have a look with jamespage  next week ...
<tumbleweed> zigo: grep-aptavail -F Maintainer openstack | grep-dctrl -s Package,Depends -F Depends -r 'python[23]\.[0-9]'
<doko> tumbleweed, care to do that for all modules and following-up to debian-python?
<zigo> doko: The simple fix is to add an override of dh_python3 within openstack-pkg-tools and do a rebuild, but I'd need to list all of my packages that have py3 support and something in /usr/bin...
<tumbleweed> zigo: run that command
<doko> in debian, not ubuntu
<tumbleweed> doko: sure
<tumbleweed> you may want to change it to -s Source, and pipe through a sort -u
<zigo> tumbleweed: doko: That's 39 packages to fix. I'll do it.
<doko> zigo, please do it right, using pybuild. maybe do one package first, and get it reviewed?
<zigo> doko: Thanks, but I don't want to use Pybuild unless there's a good enough documentation.
<doko> well, docs are an issue
<zigo> I've read the wiki, and I can't override things which I wanted.
<zigo> Pybuild is fine for simple cases where you don't need to understand it.
<doko> well, python-rtslib-fb is a simple package
<tumbleweed> zigo: examples of things you need to override?
<zigo> tumbleweed: auto_clean, auto_build, dh_sphinxdoc, dh_installman, dh_auto_install, dh_install, dh_auto_test, dh_fixperms, dh_python{2,3} are things I often have to override.
<tumbleweed> zigo: I'm asking why more than what
<tumbleweed> I mean, an example of where you can't figure out howto get pybulid to do what you need
<zigo> tumbleweed: dh_auto_test to run unit tests in a custom way, dh_sphinxdoc to install the doc directly in the folder I need to in a reproducible way, etc.
<zigo> tumbleweed: The issue isn't for *me*, everyone who may touch the packages I work on should be able to understand without reading Pybuild internal code.
<zigo> As of right now, there's no good enough docs in pybuild to make that possible.
<zigo> I've tried.
<zigo> Failed... :(
<zigo> Then gave up.
<tumbleweed> I will admit that I've had to read pybulid source to do some things
<tumbleweed> but when you've done them, the result is fairly understandable to others
<zigo> tumbleweed: It's a CDBS-like approach.
<zigo> ie: black-magic commands which aren't auto-documented.
<zigo> I'm not saying I have a better approach to advise...
<zigo> (I don't...)
<tumbleweed> I don't find it that bad
<tumbleweed> really, come to #debian-python if you have problems with pybuild and people will help. esp piotr
<zigo> Not what I said! :)
<doko> only if you are on the common path, but it's underdocumented for common cases
<doko> and it's missing a test suite
<zigo> tumbleweed: Well, that's the other issue with Pybuild. I have to ask Piotr, and from the start, as you know, my relation with him hasn't been best.
<zigo> Also, just saying "ask the only and single author" is neither satisfying or scalable.
<tumbleweed> with all its problems, it's still way nicer than having those loops everywhere
<tumbleweed> he's not the only one who uses it, we're all gaining experience
<zigo> tumbleweed: I've been thinking about pushing some of that within openstack-pkg-tools itself.
<zigo> It wouldn't be hard to do so.
<tumbleweed> but it makes your packages even less like everything else in the archive
<zigo> What made me not do it is because I don't want to hide what the package does.
<zigo> tumbleweed: I don't agree with this.
<zigo> tumbleweed: The loops which I've been using are there because I saw it in many other packages.
<tumbleweed> right, and those are being replaced by pybuild
<zigo> tumbleweed: I'm convince that what you've seen in my packages, you'll see it elsewhere too...
<doko> then why do you use the dh sequencer at all? it has hidden anything how to call the upstream build system, for a long time
<tumbleweed> when I said "it makes your packages even less like everything else in the archive" I was replying to "pushing some of that within openstack-pkg-tools"
<zigo> doko: It took me a *very* long time to switch to the sequencer, and the only reason I use it is to make it more "new standard" that others like... :P
 * tumbleweed sees a pattern here :)
<zigo> tumbleweed: I'm ok to make the effort to switch to Pybuild at some point.
<zigo> Though I don't think pybuild has issues that must be fixed first, the first of which is documentation.
<zigo> sorry, badly phrased ... :)
<zigo> redoing it ...
<zigo> When there's going to be a good enough doc for pybuild, I'll reconsider.
<zigo> Otherwise, I'm too scared to use something which I don't understand fully.
<tumbleweed> sure
<tumbleweed> and yes, it is rather CDBS-like. But I don't know how one avoids that when doing what it does
<zigo> tumbleweed: Use the dh approach ! :)
<zigo> tumbleweed: ie: small shell scripts in /usr/bin doing what's needed.
<tumbleweed> it's a different type of problem, though
<tumbleweed> it's doing the same thing multiple times, in different environments
<zigo> doko: Is having "python3" in depends ok? Or it *must* be python3:any?
<zigo> (only)
<zigo> If i do:
<zigo> override_dh_python3:
<zigo> 	dh_python3 --shebang=/usr/bin/python3
<zigo> Then I get: Depends: python3, python3:any (>= 3.3.....)
<zigo> tumbleweed: Is this correct?
<tumbleweed> yeah, that sounds correct
<tumbleweed> I mean, it could simplify that to python3:any
<tumbleweed> but that's presumably dh_python3's problem
<doko> zigo: the qualifier doesn't matter. but if you want to build (and test) using all python3 versions, you have to b-d on python3-all
<zigo> doko: All of my packages already b-d on python3-all.
<zigo> That's well understood ... :P
<doko> well, your question was about: Is having "python3" in depends ok? Or it *must* be python3:any?
<zigo> doko: The *resulting* .deb has python3, python3:any (>= 3.3.....)
<zigo> doko: "Is this fine? or must it be only python3:any (>= 3.3....)?" was my question, o
<doko> zigo, this looks fine
<zigo> Ok, I was just checking... :P
<zigo> Thanks.
<zigo> doko: tumbleweed: I've done nearly half of the packages, I'll be done in 30 minutes for the other half...
#ubuntu-devel 2015-10-24
<zigo> doko: tumbleweed: All 39 packages fixed and uploaded ! :)
<Ben64> TJ-: !
<TJ-> Ben64: ?
<Ben64> i tried to reverse the steps and go from hex to decimal but ran into the negative number problem again
<Ben64> TJ-: this is what i finally came up with and it works... wondering if there was an easier way or how dumb my way is http://ben64.com/java/2.txt
<TJ-> Ben64: always an issue with Java and it always working with signed numbers
<TJ-> Ben64: so, do you want to take in a hexadecimal number as an alternative to a decimal, but do the same operation with it?
<TJ-> Ben64: let's move the discussion to -discuss :)
<Ben64> whoops, thought this was discuss
<doko> zigo, https://launchpad.net/ubuntu/+source/python-invoke/0.9.0-2/+build/8186253
<doko> zigo, https://launchpad.net/ubuntu/+source/python-ironicclient/0.8.1-3/+build/8186254 (accessing the network)
<doko> zigo, looks like you fixed all the python3-* packages, but not the python-* packages
<zigo> doko: I thought the issue was only for py3. Is there an issue with py2 too ?
<doko> zigo, yes, you have the direct python2.7 dependency, but I don't expect a python2.8, so it's more wishlist than anything important
<zigo> doko: I'll do it in less of a hurry as I update packages...
<zigo> On my way to the summit.
<doko> have fun
<doko> mitya57, reading https://github.com/sphinx-doc/sphinx/issues/1346  looks like the rtd theme is not the default? then why add it as an absolute dependency?
<mitya57> dobey, it's unconditionally imported upstream, https://github.com/sphinx-doc/sphinx/blob/stable/sphinx/theming.py#L30
<mitya57> but maybe I can make it optional :)
<infinity> mitya57: ITYM doko.
<mitya57> ouch, sorry
<mitya57> thanks infinity!
<doko> mitya57, cut the dependency at modernizr, should be fine now
<mitya57> doko, according to upstream modernizr is needed to support IE8, which we probably don't care about
<doko> mitya57, did you have a look at python-coverage?
<doko> mitya57, ohh, nice. fix it!
<mitya57> Yes, and I filed a bug in Debian. Meanwhile I suggest to just disable the tests
<mitya57> doko, did you only cut the dependency, or also removed it from sphinx_rtd_theme/layout.html?
<doko> mitya57, I cur modernizr's dependency on uglifyjs
<doko> cut even
<mitya57> doko, nice, I haven't even heard of slimit
<mitya57> though last commit in 2013, so it also seems dead :-(
<doko> mitya57, you know these things if you have to wade through the MIRs ...
<doko> won't change python-coverage, it doesn't block 3.5 as the default
<mitya57> Ok
<mitya57> doko, if https://github.com/sphinx-doc/sphinx/pull/2097 gets accepted, I'll drop dependency on sphinx-rtd-theme.
<mitya57> (and we'll be able to demote it and modernizr)
<doko> mitya57, but isn't alabaster the default theme?
<mitya57> yes, that's why I will remove only sphinx-rtd-theme, not alabaster
<doko> mitya57, if you want to help with http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5.html ... blender cigi-ccl elektra hyphy python-invoke are the blockers
<mitya57> doko, I can look at python-invoke
<mitya57> Can someone please reject python-invoke in wily? I am not yet used to typing xenial instead of wily :(
<mitya57> doko, please ^
 * mitya57 should probably start using 'devel' alias
 * mitya57 facepalms
<mitya57> ^^^ and metacity too (I uploaded it yesterday and didn't notice the mistake)
<doko> micahg, done
<mitya57> Thanks!
<mitya57> python-invoke uploaded to the right place now
<doko> mitya57, does sphinx really need jquery 1.11?
<mitya57> doko, not really, this is just the version upstream uses so I bumped the dependency to be safe
<roaksoax> doko: howdy! i hav a quick question.. is there any plan to address upgrades from applications that have migrations with django 1.6 in trusty to django 1.7 in X ?
<mitya57> doko, you can revert that to (>= 1.4) for Ubuntu
<doko> mitya57, infinity: new jquery depends on nodejs ... fun task for you vacation ;-P
<roaksoax> doko: as in, for an app that's in trusty with django 1.6 won't be able to upgrade to django 1.7 in X because migrations in between T and X are made, and X (django1.7) wont be able to apply those migrations
<mitya57> Maybe my idea about MIRing nodejs wasn't so badâ¦
<doko> roaksoax, I don't know about any plans
<doko> aren't updates 1.6 -> 1.8 from lts to lts good enough?
<roaksoax> doko: the problem is that django has change migration system that breaks backwards compatibility
<doko> mitya57, ok, next time, bump it in the b-d's too ;)
<roaksoax> doko: so say, maas 1.7 in trusyt, wont be able to upgrade to maas 2.0 in X becaue django 1.8 won't know how to handle the migrations created between 1.7 and 2.0
<mitya57> doko, bumping the b-d's is not really needed as it builds fine with the new version :)
<doko> roaksoax, well, I assume then you have to package a 1.7 subset?
<doko> or better rely on sound technologies in maas?
<ricotz> doko, could you please sync x264 from experimental
<doko> mitya57, this attitude is causing me some pain ... https://launchpadlibrarian.net/222652126/buildlog_ubuntu-xenial-amd64.sphinx_1.3.1-7ubuntu2_BUILDING.txt.gz
<doko> ricotz, does this start a new transition?
<mitya57> doko, I got the same for python-invoke, looking at why it's not installable
<ricotz> doko, yes, and can be done in parallel to x265 which got already syned
<doko> mitya57, libjs-sphinxdoc --> versioned jquery
<mitya57> oh, a circular uninstallable dependency :(
<doko> so how to build sphinx temporarily without alabaster?
<mitya57> doko, alabaster shouldn't depend on sphinx, I will drop that dependency
<mitya57> see debian #783794
<ubottu> Debian bug 783794 in python-alabaster "python-alabaster: Please do not depend on python-sphinx" [Normal,Open] http://bugs.debian.org/783794
<doko> wait, just removing the binaries
<mitya57> That should also work
<doko> xnox, any idea about https://launchpadlibrarian.net/222648448/buildlog_ubuntu-xenial-armhf.blender_2.75.a%2Bdfsg0-2ubuntu2_BUILDING.txt.gz ?
<hjd> I just discovered I can't see the xenial branches for packages under the code page on Launchpad. Is this expected since it is still early days?
<doko> we're not yet completely open
<hjd> ok :)
<mitya57> doko, so did you remove the binaries?
<doko> mitya57, yes
<mitya57> Ok to retry some builds then?
<mitya57> i.e. the sphinx one
<doko> still too early
#ubuntu-devel 2015-10-25
<gsilva> Hello all. I'm new to JS and I am interested to learn more to eventually master it. Be aware, I'm a complete stranger to programming. Can someone help me out for some time?
<TJ-> gsilva: Try "/join #javascript"
<gsilva> My idea is to contribute to open source projects and not just learn javascript
<gsilva> But thanks, I'll give it a try
<schnuppi> Hello
<doko> tumbleweed, mitya57: any idea about https://launchpadlibrarian.net/222742551/buildlog_ubuntu-xenial-amd64.python-altgraph_0.12~dfsg-2_BUILDING.txt.gz  https://launchpadlibrarian.net/222807666/buildlog_ubuntu-xenial-amd64.python-macholib_1.7~dfsg-2_BUILDING.txt.gz ?
 * mitya57 looks
<mitya57> doko, __init__.py trying to import itself using an entry point, weird
 * mitya57 looks further
<mitya57> doko, in macholib, even after fixing __init__.py, the tests still fail because they are trying to access some OS X specific files, so disabling tests should be fine
<doko> mitya57, who recommends this pattern?
<mitya57> doko, they seem to have the same upstream
<mitya57> doko, in altgraph, the tests work, I will prepare/upload the fix
<doko> ta
<tumbleweed> we really need a lot more buildslaves for autopkgtest :(
<mitya57> doko, both altgraph and macholib now built, will file debian bugs (one with patch) too
<doko> mitya57, ta
 * doko is now hand-patching generated swig files ...
<doko> http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5.html looks almost good ...
#ubuntu-devel 2016-10-24
<tsimonq2> What sort of "rules of thumb" are there when wanting to become a MOTU? I've gotten pretty familiar with the release process, so I'm familiar with the infrastructure and the rules associated with it. I just haven't done a *lot* of package uploading through sponsorship. I have a few packages I've gotten fixes to, but other than that, not much.
<tsimonq2> So I know I need to do more work before applying, but a lot of the documentation is horribly outdated. That's why I want to know what the general rules are here.
<tsimonq2> I also generally need experience here, so feel free to throw things at me. ;)
<pitti> Good morning
<ginggs> pitti: guten morgen! do we still need a separate fftw3-mpi since archive re-org?
<dholbach> good morning
<pitti> ginggs: if it only builds new binaries which can stay in universe, we can sync again (I didn't check precisely)
<ginggs> pitti: i'm not sure, that's why i asked.  why would we need to sync again?
<pitti> ginggs: ATM it seems our fftw3 package still has an ubuntu delta and doesn't build the mpi packages?
<pitti> ginggs: so I suppose syncing fftw3 and removing fftw3-mpi would do it?
<pitti> sorry, need to get offline for a bit
<ginggs> pitti: yes, but we already have 3.3.5-1 in proposed
<ilmaisin> hi
<ilmaisin> could some developer take a look at this: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1439771
<ubottu> Launchpad bug 1439771 in network-manager (Ubuntu) "wpa_supplicant[874]: dbus: Failed to construct signal after 'suspend'" [Medium,Confirmed]
<ilmaisin> as laptops and wlans are more a rule than exception today, it's quite important and i don't understand why it's only "medium" in importance
<ilmaisin> it's likely related to the systemd transition
<ilmaisin> is the answer "no, canonical doesn't want to fix bugs as it is now working with microsoft and wants to tarnish the reputation of desktop linux"?
<ilmaisin> difference, to, say, fedora is like day and night, in fedora, while it has problems of it's own too, fixing important "critical path" bugs is more like a matter of days rather than years
<Laney> If you want to troll Ubuntu, take it elsewhere.
<ilmaisin> Laney: i don't want to troll anything, i want someone to take look of the bug, trolling is only a desperate mean to achieve that
<infinity> ilmaisin: All the noise on that bug implies people are seeing several different bugs and dogpiling on.
<infinity> ilmaisin: As for criticality, if NM was entirely broken for everyone, we'd all be panicking, but literally all of us run Ubuntu on laptops and, clearly, it's not broken for all of us, so it's a bit messier to track down.
<infinity> ilmaisin: And insulting people is a really poor way to get your bugs addressed.
<infinity> ilmaisin: Turns out that's pretty demotivating.
<infinity> ilmaisin: (PS: Not everyone who works on Ubuntu is paid by Canonical, just as not everyone who works on Fedora is paid by RedHat).
<infinity> ilmaisin: So even if your conspiracy theories about Canonical were true (they're not), turns out other people could still upload a fix.  Or sponsor a fix with a patch you submitted even!
<Son_Goku> ilmaisin, being slightly constructive here, it's highly unlikely to be related to systemd
<Son_Goku> at least by this point, anywya
<Son_Goku> *anyway
 * Son_Goku pokes infinity
<Son_Goku> any progress on those patches?
<Son_Goku> you know the ones I'm talking about ;)
<ilmaisin> infinity: i just can't help being quite frustrated on ubuntu's seemingly passive aggressive approach to bugs
<infinity> ilmaisin: No distro has the manpower to fix every bug filed.  Or even to read them all.
<ilmaisin> infinity: i can get it reproduced by suspending and resuming the system until the problem reproduces
<infinity> ilmaisin: We're not "special" here.
<infinity> ilmaisin: I have RH bugs that go unread until the "this version is EOL, so we're autoclosing the bug" bot sweeps them up and I have to reopen them.
<infinity> ilmaisin: Everyone sucks at bugs.  The ened.
<infinity> end*
<Son_Goku> ilmaisin, the sad thing is, as a particular distribution becomes more popular, the amount of manpower available for dealing for each bug goes down
<infinity> ilmaisin: If you can reproduce it reliably and provide any useful debugging info, please do.  If it happened on all laptops, I'd have noticed it, as would countless others of us.
<Son_Goku> infinity: there's a tag you can add to keep the autosweeper from killing the bug in rhbz, btw
<infinity> Son_Goku: !!
<Son_Goku> we use it for long running DNF bugs that are taking a lot of time to fix
<infinity> Son_Goku: Does the bot tell me this and I've just never read closely enough, or is it a hidden feature?
<Son_Goku> it's a hidden feature of Bugzilla configuration
<Son_Goku> I forgot where it was documented for rhbz
<infinity> Well, spank me silly and call me Tilly.
<Son_Goku> give me a sec...
<ogra_> cant you just set it to triaged status ? whats the advantage of having a tag instead ?
<infinity> I should be sleeping, though.
<Son_Goku> Nooo :P
<Son_Goku> ogra_, if a bug is set to NEW and never gets any updates and whatnot, it autocloses
<infinity> ogra_: RH agressively closes bugs in obsolete series'.  Exactly what I've campaigned against in Ubuntu.  But, to each their own.
<ogra_> Son_Goku, ugh
<infinity> (Well, we close ones with a series target, but keep the devel target open)
<ogra_> yep
<ogra_> and never auto-close New i think
<Son_Goku> we used to leave Rawhide alone
<infinity> Each has its advantages.
<Son_Goku> but it kept piling up...
<ilmaisin> Son_Goku: the "as a particular distribution becomes more popular, the amount of manpower available for dealing for each bug goes down" thing sounds quite bad for me as that would mean that if linux on desktop gets more popular, it will choke to bug reports and fall apart
<infinity> Volume of bugs is a real problem.
<infinity> But so is closing valid bugs without a solution.
<infinity> Both suck. :P
<Son_Goku> there's no good way to deal with the problem, unfortunately :(
<Son_Goku> I wish there was
<infinity> ilmaisin: There are bugs in Windows that I've been aware of since 1994.  Software is like that.
<infinity> Some bugs get fixed.  Others don't.
<infinity> At least with free software, you generally have an avenue to complain a bit.
<infinity> And one where we don't charge you for the privilege!
<Son_Goku> infinity, I think if you add the keyword "Triaged" to the KEYWORDS field, it should stay open
<infinity> Son_Goku: I may ask you about that again the next time I get a bug closed against my will. :P
<Son_Goku> that and "FutureFeature", but I think "FutureFeature" is more about preventing the rawhide->release autoassigner
<ilmaisin> infinity: yeah, if microsoft had a public bug tracker it would probably collapse to flood
<Son_Goku> ilmaisin, the semi-public one already does
<Son_Goku> it's down on a regular basis because it needs manual pruning
<infinity> Yeahp.
<infinity> And that has nothing to do with the quality of their software, it's just the volume of users.
<infinity> Users are great.  Bug reports from users can be great.
<infinity> But they also generate a lot of work.
<infinity> And I don't mean "fixing bugs" work, I mean "reading bug reports" work.
<Son_Goku> pretty much
<Son_Goku> but volume of bugs always sucks
<Son_Goku> yep
<Son_Goku> I've been lucky so far with my own stuff in Fedora, but I know people who literally can't read bugzilla anymore because it just makes their brains explode
<Son_Goku> just too much bugs
<Son_Goku> and autoreporters like ABRT, Apport, etc. don't help
<ilmaisin> infinity: so you haven't ever seen you laptop to lose ssid list and can't reproduce it how i said?
<Son_Goku> again, great for making useful bug reports, but the required cognitive effort for dealing with them is still quite high
<infinity> ilmaisin: Nope.
<infinity> ilmaisin: Happens to my Android phone, but I know what that bug is.
<infinity> Never to my Ubuntu machines, though.
<ilmaisin> infinity: ok
<ilmaisin> infinity: what chipset do you have on the ubuntu laptop?
<infinity> Intel something
<infinity> 7265
<Son_Goku> fwiw, bcm wifi is just generally crappy
<ilmaisin> ok
<Son_Goku> a lot of issues are just caused by it being Broadcom
<Son_Goku> and there's not a damn thing we can do about it
<Son_Goku> on the Fedora side, Broadcom is our trickiest Wi-Fi module to support
<infinity> Yeah, we're not fans in Ubuntu either.
<ilmaisin> well, it's sometimes quite possible to work around hardware design flaws on os level, but not always though
<Son_Goku> and as far as I know, no one has perfectly nailed down BCMxxxx chipset support
<infinity> We attempt to "support" it, but there's only so much you can do when the "good" driver is close-source, and it's only barely better than the "bad" driver.
<Son_Goku> yep
<Son_Goku> and in our case, we can't officially recommend the closed-source driver like Ubuntu can
<Son_Goku> so...
 * Son_Goku shrugs
<Son_Goku> that said, nobody in Fedora really *wants* to, as the closed-source driver is crappy and destabilizes the kernel in weird ways
<infinity> The likely best option, if it's the driver being wonky, is to quirk it to remove and reinsert on suspend/resume, but I don't recall where that happens in the new world.
<infinity> Cause I haven't had to use said quirk in a long time.
<infinity> Possibly a snippet in /etc/pm/suspend.d
<Son_Goku> forcibly unloading and reloading the driver does work (oss or proprietary), as long as the hardware firmware didn't hang
<Son_Goku> which can happen too (!!!)
<Son_Goku> then you have to do a cold restart to fix :(
<infinity> Thanks, Broadbama.
 * Son_Goku experiences this fairly regularly on his MacBook Pro running Linux
<infinity> Okay.  I'm really asleep now.  Honest.
 * infinity goes.
<Son_Goku> :(
<ilmaisin> http://www.macrumors.com/2016/03/18/apple-supplier-broadcom-wi-fi-chip-business/
<ilmaisin> hmm
<ilmaisin> they maybe are going to quit that business
<Son_Goku> if it means Apple starts creating its own chips, we're screwed
<ilmaisin> yes, the problem seems to be "solved" when i make my system to unload the module before sleep
<ilmaisin> could that workaround be applied to the ubuntu packages somehow?
<ilmaisin> maybe the bug importance should be "High" instead of "Medium" as bcm chips are quite common
<Son_Goku> that's not for us to decide, that's for the bug triaging folks to decide
<ilmaisin> ok
<Son_Goku> but you can certainly comment about that as a possible solution
<ilmaisin> Son_Goku: done that
<ilmaisin> hopefully those snappy and flatpak things will free distro developer's time to deal with actual os issues instead of packaging every software that exists
<rbasak> I suspect that bug has become a catch-all for "wifi doesn't work after suspend" which is probably an entire class of bugs rather than just one bug.
<ilmaisin> rbasak: it's possible
<rbasak> In that case it rapidly becomes impossible for developers to tackle the problem at all, since the comments may refer to radically different root causes.
<ilmaisin> rbasak: though broadcom drivers appears to be a common factor there
<rbasak> I would file a separate bug report with a much more rigid description. "With hardware X, when I do a fresh install and then follow exactly the steps Y, I get behaviour Z, with log messages stating A and B. If X, Y, Z, A and B don't match, you aren't affected by this bug".
<rbasak> You might then find that you are actually the only person affected by your particular bug.
<rbasak> ilmaisin: sure, and with a collection of specific bugs (perhaps grouped together by a tag), a developer may be able to identify a common way of fixing all of them at once.
<ilmaisin> rbasak: i had a separate report on my case but i marked it as duplicate, but it was not as good report as you described
<rbasak> But until then, they really need to be separate bugs. Otherwise the bug will remain intractable and never get fixed.
<ilmaisin> rbasak: only if i had enough motivation to write long reports that won't in all likelihood lead to anything
<rbasak> If a hundred people are affected by a well-described bug, it will usually get addressed IME, because by that stage a capable Ubuntu developer is affected.
<rbasak> I'm sure there are exceptions though, and of course there's no guarantee.
<rbasak> More likely we have a hundred people affected by a hundred different bugs, so nothing stands out to get prioritised.
<ilmaisin> rbasak: and we need those 99 other people who are motivated to write long and detailed reports that won't alone lead to anything
<rbasak> Well, this is the Free Software ecosystem. Either bugs affecting many people get fixed by one of those affected, or by a sponsor interested in fixing bugs affecting many people, or by somebody who pays to get a bug fixed.
<rbasak> Or the bug doesn't get fixed.
<ilmaisin> i'll have to re-test if it affects the proprietary driver as well
<ilmaisin> it seems to be ok with the proprietary driver at least now
<loganade1> hoi
<loganade1> are you guys planning on doing another google code-in this year ?
<niedbalski> arges, ping
<x_7fffbad3> hello people! :) i want to add a custom menu at unity panel...can you give me some resources about this?
<dobey> unity 7?
<x_7fffbad3> it's `unity 7.4.0`
<dobey> you need to write an application indicator
<dobey> https://unity.ubuntu.com/projects/appindicators/
<x_7fffbad3> dobey: that's what i need...thank you for link+keywords ;)
<x_7fffbad3> dobey: next step: search -> program
<hjd_> Is the sync from Debian working differently in Zesty compared to other release cycles? I seem to remember that most packages were synced and built when the archive opened for development, but this time around it seems to work more gradually.
<jbicha> hjd_: I believe they're wanting to at least finish the perl transition first this time before starting autosync
<hjd_> jbicha: Ah, I didn't know. Is there anywhere I can see an overview of the transition state?
<jbicha> hjd_: click perl5.24 at https://people.canonical.com/~ubuntu-archive/transitions/
<hjd_> :)
<pitti> robru: FYI, autopkgtest refactoring into a britney Policy is going well! It's working now, I just want to clean up the code a bit now
<LocutusOfBorg> rbasak, can you please fix mysql-5.7?
<LocutusOfBorg> I need boinc to go in testing and it is blocked by this one. (and I can't use default-mysql package, because it is not in jessie-backports)
<LocutusOfBorg> thanks
<robru> pitti: oh cool, that was fast, thanks
<pitti> robru: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?h=policy-changes&id=1d9fc1756e
<pitti> robru: the britney.py changes are now minimal -- only instantiate the new policy; and it doesn't touch excuse.py at all any more except for a backwards compat thing that we'll drop soon (I'll mail you and apw about adjusting kernel matrix and bileto)
<robru> pitti: wow, very nice! That looks like a major reduction in maintenance burden
<robru> Eg easier to rebase on upstream changes
<pitti> absolutely
<pitti> also more stable against behaviour changes
<robru> Brilliant
<pitti> robru: I still want to clean up/refactor the apply_policy_impl() code, this looks horrible now
<pitti> but this will be completely internal
<robru> Right
<pitti> at least now all the tests pass again
<pitti> and in principle you can now hook your's after AutopkgtestPolicy
<pitti> I like this much better
<robru> pitti: ok will rebase, thanks again
<pitti> robru: britney might become a pretty girl some day :)
<robru> Hahaha
<dobey> pitti: just make her fast :)
<pitti> Britney Bolt
<pitti> daughter of Ursain :)
<pitti> Usain even
<pitti> robru: rebase> maybe wait until I land this in master? but of course you can already experiment against that branch
<robru> pitti: yeah I'll wait of course. Will rebase when ready
<sil2100> Just a heads up: I'm investigating the dbusada autopkgtest failures as seen after the dbus new upload in zesty (unrelated)
<pitti> robru: https://bileto.ubuntu.com/#/ticket/1710 failed to publish as it stumbles over the nonexisting zesty/libindicator (this was just a backport, so there are no zesty changes); is there a way to publish this that doesn't invalidate all teh automatic and manual testing?
<pitti> (I also forgot to tick the packaging ack, but that's the simple part)
<robru> pitti: too many cooks in this kitchen i think: https://bileto.ubuntu.com/log/1710/
<robru> pitti: please join our discussion in ci-eng
<pitti> robru: that's not a meaningful channel on either freenode or C?
<robru> pitti: #ubuntu-ci-eng
<robru> It's the channel for all things bileto
<rbasak> LocutusOfBorg: how so? You can't rdepend on mysql-5.{6,7} if you want to remain in testing.
<rbasak> LocutusOfBorg: for jessie-backports you'll either need a delta or someone needs to sort out mysql-common/mysql-defaults in backports.
<rbasak> LocutusOfBorg: see Debian bug 837615
<ubottu> Debian bug 837615 in src:mysql-5.6 "Don't include in stretch" [Serious,Open] http://bugs.debian.org/837615
<LocutusOfBorg> rbasak, so, mysql5.6 can't migrate and 5.7 too
<LocutusOfBorg> how can I see it migrate?
<LocutusOfBorg> ok, so let me do an upload with the default, sigh
<tjaalton> cyphermox: hi, what's the status of the xenial update for bug 1527727?
<ubottu> bug 1527727 in grub2-signed (Ubuntu Xenial) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,In progress] https://launchpad.net/bugs/1527727
<cyphermox> tjaalton: thanks for the reminder, I'll reupload that in a bit
<tjaalton> cyphermox: nice, thx
#ubuntu-devel 2016-10-25
<lfaraone> cyphermox: can you push the latest  version of `initramfs-tools` to git.launchpad.net? last I see is 0.125ubuntu2; yakkety has 0.125ubuntu5
<cpaelzer> good morning
<pitti> Good morning
<ginggs> morning pitti: does openmpi need a hint to run autopkgtests with gerris 20131206+dfsg-11ubuntu1 ?
<pitti> ginggs: yes, presumably; I'll try the same for vtk6
<pitti> half of the perl stuff will be the same I figure
<ginggs> pitti: thanks. do you know if there is anything different about the s390x environment for running autopkgtests?
<pitti> ginggs: i386/amd64/ppc64el are running in nova instances, i. e. QEMU; armhf  runs in lxd containers, s390x runs in lxc containers
<pitti> there's some work to move s390x into scalingstack, i. e. to provide full VMs; but until that, we use some hand-crafted setup
<ginggs> hmm, because I still see an error on s390x, which looks like the error when trying to run mpi programs in a chroot
<pitti> ginggs: does it happen on armhf too?
<ginggs> no, only s390x
<pitti> lxc and lxd are not that much different wrt. isolation -- if anything, there should be *more* problems on lxd as it uses user containers which are a bit more "strange"
<ginggs> pitti: would you ignore the s390x result for now, or should I try to work around that?
<pitti> ginggs: for which package? (presumably I would ignore it, yes)
<ginggs> pitti: sorry, still on gerris
<pitti> ginggs: ah, yes; I'm currently doing a mass-retry against -proposed (for the perl transition and also your's) and once that settles I'll go through excuses.html and sort out the rest
<cpaelzer> doko: I'd work on merging latest dovecot in zesty if you are ok with that
<cpaelzer> IIRC last time we did that at the same time :-/, so double worth to ask this time
<LocutusOfBorg> hi juliank does python-apt needs some updates for zesty?http://autopkgtest.ubuntu.com/packages/p/python-apt/zesty/i386
<LocutusOfBorg> and pitti fixed it ^^
<LocutusOfBorg> so, underscore testsuite has to run against python-apt/proposed
<pitti> LocutusOfBorg: or rather, I'll let p-apt land, and retry the failures afterwards
<pitti> but the queue is hopelessly long right now (I didn't even submit the non-s390x retries for perl), so settling this will still take a while
<juliank> This whole copy-last-distribution-and-change-name thing is a bit annoying.
<cpaelzer> doko: almost forgot - please ignore my former question I was looking at X instead of Y changelog
<pitti> juliank: couldn't this be derived from distro-info-data somehow?
<LocutusOfBorg> pitti, syncpackage distro-info-data?
<juliank> Well, it could be merged into that
<pitti> LocutusOfBorg: yep, indeed; doing
<juliank> python-apt also keeps around mirror lists, information about components
<juliank> And translate user-visible names for components and suites
<pitti> $ distro-info -f --devel
<pitti> Ubuntu 17.04 "Zesty Zapus"
<pitti> juliank: yeah, the "supported/unsupported/partner" bits are not there indeed
<juliank> Stuff like -proposed => Pre-released updates, -backports => Unsupported updates
<pitti> juliank: but given that the only kind of information I poured into the above upload was to s/16.10/17.04/, s/yakkety/zesty/ and s/Yakkety Yak/Zesty Zapus/, this is all in d-i-d
<LocutusOfBorg> ta!
<juliank> That's true. All the other fields are defined per distribution though, and then you have ParentSuite and stuff. It would require a lot of work to more generically describe this thing in some kind of "default" section
<stefanct> hm... is launchpad known to be broken atm? cannot submit a new bug for inkscape
<juliank> pff, it's broken half of the time I want to do stuff...
<stefanct> :)
<juliank> (gitlab is far worse)
<highvoltage> gitlab.com was upgrading this morning but has been working fine for me since the last hour or so
<pitti> juliank: right, some kind of "template" with macros for short/long name, version etc.
<juliank> Well. gitlab is so busy it tends to send out emails or git hooks 30 minutes after the event
<highvoltage> juliank: yikes
<Son_Goku> I've been okay on gitlab for the last hour or so
<Son_Goku> poking around with mir stuff
<pitti> xnox: your gerris retries should have used all-proposed=1..
<pitti> xnox: see conversation with ginggs earlier here
<Son_Goku> juliank, if I attach my own runner to my project, all of my issues tend to go away
<xnox> pitti, ah, true! how do i do all-proposed=1 in the url construct? &all-proposed=1
 * xnox did not know there is all-proposed.
<xnox> pitti, what's up with s390x? it seems unusual that it has the highest queue length.
<pitti> xnox: I mass-retried perl with --all-proposed on it (but not the other arches yet as they still have too much to catch up with)
<xnox> ah, i see.
<xnox> fair enough.
<pitti> xnox: I'm using some big hammers to try and get on top of the haskell+perl transitions
<xnox> pitti, could you ingoretest openmpi to let it through. It's actually good, and is holding up starting boost transition.
<xnox> unless it's two sizes too big of a hammer
<pitti> xnox: ok; seems vtk6 is a victim of some mysql uninstallability
<pitti> but indeed at some point it's easier to fix the fallout after these huge chunks landed
<doko> cpaelzer: please go ahead, the package belongs to the server team
<LocutusOfBorg> thanks pitti
<LocutusOfBorg> xnox, I did create a boost1.62 transition tracker, but I didn't fix it :/
<xnox> http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html looks ok.
<pitti> xnox: openmpi hinted
<xnox> it's too early to upload boost-defaults pointing at 1.62, as I usually like to have the new boost migrated into the release pocket, to avoid huge build ups in -proposed.
<LocutusOfBorg> xnox, this because you fixed it :) http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/430
<Laney> LocutusOfBorg: are you looking at mariadb ftbfs by any chance?
<LocutusOfBorg> Laney, I don't know how to fix it :/
<LocutusOfBorg> but it is in the long todo
<pitti> xnox: hinted gerris/390x as well now, so hopefully openmpi should land in the next iteration
<xnox> well. are all of these http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi.html in zesty-proposed and not in release? i guess i should check if these need fixing first.
<xnox> looks like there are still 8 potentially outstanding packages which would still clog it up.
<pitti> xnox: ok, so s/land/not being blocked by tests/ :)
<xnox> or maybe the tracker is bad. i'm not sure why it's bad to depend on mpich12
<pitti> xnox: indeed, e. g. bagel is missing its s390x build
<xnox> *** Error in `../TestSuite': malloc(): smallbin double linked list corrupted: 0x000002aa0fdda070 ***
<xnox> then it got stuck, then killed.
<ginggs> xnox, pitti: tracker is bad, bagel builds with mpich not openmpi
 * xnox pushes tracker update.
<xnox> well, we shall see what proposed-migration complains about now, if any.
<xnox> pitti, vtk6 should be hinted through, the only regression is known to pass with all-proposed.
<xnox> i would ask to hint boost1.60 over mongodb/armhf failure too. However, it does seem odd.
<xnox> ditto boost1.61
<xnox> sigh
<xnox> these three seem to be the ones that "Depends: openmpi" and thus block openmpi migrating.
<xnox> oh mongo ftbfs
<pitti> xnox: hinted liggghts/armhf
<xnox> for mongo, i'm podering to sync the modern mongodb from experimental.
<xnox> because 2.6 is acient.
<xnox> even juju-mongodb moved to 3.2
<xnox> 2.6 has FTBFS in debian too.
<xnox> https://tracker.debian.org/news/794834 looks sensible
<jbicha> xnox: I think mongodb doesn't build on all the architectures these days but maybe that's ok?
<xnox> jbicha, it fails on armhf, and i think that's ok.
<jbicha> mongodb 2.6 is eol upstream this month: https://www.mongodb.com/support-policy
<LocutusOfBorg> jbicha, lirc is fine in Debian
<LocutusOfBorg> totem works now, just sync from experimental when possible
<jbicha> LocutusOfBorg: thank you!
<LocutusOfBorg> thanks to you, I plan to do a transition, it shoulnd't migrate without rebuilding reverse-dependencies
 * LocutusOfBorg sets a ben file
<caribou> doko: infinity: mdeslaur: we have a potential fix for LP: #1584485 (libnss-winbind / libpam-winbind static libraries). Anyone interested in reviewing the patch ?
<ubottu> Launchpad bug 1584485 in samba (Ubuntu Yakkety) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
<mdeslaur> caribou: you should ask someone from the SRU team
<caribou> mdeslaur: well, yes, it will end-up on all releases so I guess that'd be better
<caribou> apw: bdmurray: pitti: slangasek: ^^
<LocutusOfBorg> anybody wants to try the new sbuild? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/7059276/+listing-archive-extra
<sil2100> doko: hey, do you have some gnat related knowledge? I stumbled upon some issues with gnat when trying to run dbusada tests or even no-change rebuild dbusada on powerpc, ppc64el and s390x
<pitti> caribou: the patch itself is fairly straightforward (well, I'm completely unfamiliar with the build system, but it basically says "link this statically")
<pitti> caribou: which seems reasonable, as long as it doesn't make it unreasonably large
<sil2100> doko: would you be able to help me out? To me it looks like this might be some toolchain issue, but I don't know ada at all
<caribou> pitti: thanks for checking. I'll check the difference in size before uploading
<caribou> pitti: I was wondering if this would require a Break/Replace on the previous version. Don't think so but just want to be sure
<pitti> caribou: no, I wouldn't know why
<caribou> didn't think so either, thanks
<infinity> caribou: A breaks/replaces against what? :P
<infinity> caribou: $package implicitly breaks/replaces/conflicts $package, cause, well, it's the same package.
<doko> sil2100: no, you didn't tell about the issue you have :-/
<caribou> infinity: B/R are still kind of nebulous to me so I'm always a bit worried to miss them
<caribou> infinity: still needs to do the readings you suggested
<doko> is there a replacement for iptraf?
<infinity> caribou: So, the thing I'd like to see (once this is tested to DTRT, etc) is something upstreamable and upstreamed, so we don't have to carry a hideous patch forever.
<infinity> caribou: Given the intense upgrade pain, I'm firmly of the belief here that if the rest of samba is linked dynamically (which is a reasonable option), those two bits should still always be static.
<caribou> infinity: understood, I've already asked for the WAF customization to be upstreamed
<infinity> caribou: So, the option should be there upstream to do it at the flick of a switch, and said switch should be proposed as the default (though if we have to differ with a --configure-option, so be it)
<caribou> infinity: for the rest, they already stated that those should be packaged with samba-libs
<caribou> infinity: here is the ML thread : https://lists.samba.org/archive/samba-technical/2016-October/116619.html
<infinity> caribou: Hrm.  Indeed, shipping them in samba-libs with the libnss/libpam packages only providing the config glue would work too.
<infinity> caribou: That could be the path of least pain if upstream isn't keen on the static approach.
<caribou> infinity: I still keep this in my LoS anyway
<infinity> caribou: The pam and nss modules are tiny, so that approach wouldn't bug me too much.
<caribou> k
<infinity> And they'd be inert by default if we keep the configuration bits in the libpam-foo/libnss-foo packages.
<caribou> infinity: there is a debian bug opened for that too, I'll bring it up there
<infinity> That seems to me a reasonable solution.  Wish I'd thought of it before I sent you down the static rabbit hole. :P
<caribou> infinity: I learned a lot during the fall :)
<infinity> Well, not a total loss then. ;)
<infinity> THis would effectively just be a 4-line patch to the current packaging.
<infinity> ie: remove the modules from the module packages, install them in the libs package, done.
<infinity> caribou: Of course, it gets a bit more complex, because both also depend on libwbclient0, which should probably just move to samba-libs.
<sil2100> doko: yeah, sorry, got preempted by a meetings - the issues I see are that when gnatbind-6 runs, it gets a lot of errors like: '"somethingsomething.adb" must be recompiled ("system.ads" has been modified)'
<doko> sil2100: get things resolved when packages are rebuilt?
<sil2100> doko: I saw that system.ads is part of gnat-6, not sure what they mean - since all those 'somethingsomething.ads' files seem to get built on during package build
<sil2100> No, a no-change rebuild of dbusada ends up with such a failure on the 3 arches, example log:
<sil2100> https://launchpadlibrarian.net/290714344/buildlog_ubuntu-zesty-s390x.dbusada_0.3.3-1build1~test1_BUILDING.txt.gz
<sil2100> There are also some 'obsolete' errors there for dependent libraries I guess, but the system.ads ones worry me the most
<sil2100> Similar issues when running dbusada autopkgtests
<doko> sil2100: looks like you need to rebuild dbusads's deps. you may want to ask the debian-ada team about it. I would have to do the same here
<sil2100> doko: ACK
<LocutusOfBorg> pitti, do you know why the new sbuild picks up dose and fails?
<LocutusOfBorg> it is here btw https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa
<slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 3?
<infinity> slangasek, stgraber, ... WHAT HE SAID.
<mdeslaur> slangasek: ack
<slangasek> :)
<slangasek> I notice the agenda wasn't updated
<slangasek> our next meeting is probably not Oct 11, 2016
<infinity> Potentially not.
<infinity> But I'm likely the chair, since I wasn't there on the 11th.
<infinity> So, meh.
<rbasak> Is anyone SRUing debootstrap to yakkety?
<rbasak> I hear that powersj has volunteered if not.
<rbasak> Does this need an SRU bug?
<rbasak> Looks like there have been SRU bugs in teh past.
<rbasak> arges, apw: ^?
<apw> rbasak, it would probabally want an SRU bug ... for tracking i'd say
<apw> i am not myself sru'ing it
<rbasak> powersj: ^ all yours.
<powersj> ok
<powersj> thx!
<rbasak> powersj: if you create the debootstrap and assign yourself, hopefully that'll flag a lock to others.
<rbasak> the debootstrap bug
<powersj> ok
<LocutusOfBorg> jbicha, pretty please, upload this lirc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper
<LocutusOfBorg> there is a typo that prevents smooth upgrades from debian
<LocutusOfBorg> from xenial/yakkety I mean
<jbicha> LocutusOfBorg: why don't you upload that to experimental and we can sync from there?
<LocutusOfBorg> jbicha, because the current one is broken
<LocutusOfBorg> I want to fix it and in the meanwhile I already asked the maintainer to fix it
<LocutusOfBorg> sorry, but it landed on -release, so I broke upgrade path
 * LocutusOfBorg is doing rebuilds of reverse dependencies right now
<jbicha> those running zesty already should expect some breakage
<LocutusOfBorg> jbicha, I prefer not from me  :)
<LocutusOfBorg> but as you wish
<LocutusOfBorg> I might upload it tonight in debian, so expect a sync request tomorrow
<LocutusOfBorg> that version fixes totem and upgrade path, this is why I prefer to see it uploaded right now, but one day might not make much difference
<jbicha> LocutusOfBorg: ok I uploaded it for you :)
<LocutusOfBorg> thanks, in the meanwhile I'm doing test rebuilds, and in case I'll upload a -3 in Debian with some build-fixes if there are some
<LocutusOfBorg> I don't have hurry now :)
<jbicha> too bad we didn't see that an hour or two ago before it migrated to -release
<LocutusOfBorg> yep indeed
<LocutusOfBorg> stupid typo
<LocutusOfBorg> and people are running upgrades from sid to experimental, not sure why they didn't open a bug
<LocutusOfBorg> jbicha, debian is not broken, because by chance, the library wasn't in multiarch location before, so the clash has been funnily avoided
<LocutusOfBorg> loool
<LocutusOfBorg> ubuntu had a multiarch location, so the path didn't change
<LocutusOfBorg> :)
<LocutusOfBorg> I see ~5 reverse-dependencies failing to rebuild, will look at them
<jbicha> it looks like you don't have -proposed enabled for that ppa
<jdstrand> tyhicks: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/comments/29
<ubottu> Launchpad bug 1580463 in im-config (Ubuntu Xenial) "Snap blocks access to system input methods (ibus, fcitx, ...)" [Medium,Fix committed]
<tyhicks> jdstrand: thanks! I'm hoping to do the apparmor testing by EOD
<jdstrand> good timing then :)
<jbicha> bdmurray: so webkit2gtk/yakkety is being blocked because of phased updates
<jbicha> https://errors.ubuntu.com/problem/31f280fa5539449d440e411a60b92bb28e48e41b has the same title at least as
<jbicha> https://errors.ubuntu.com/problem/53de313c8e0c7a05c093808248f8ce1ab17a1f21 (except the first is i386 and the second is amd64)
<jbicha> but the amd64 bug was found in the older webkit2gtk
<bdmurray> jbicha: Okay, I'll get that error taken care of, what about https://errors.ubuntu.com/problem/18b5e69225bd63387d958707585693d52919b7c4? Its curious there aren't any crashes with 2.14.0-1.
<jbicha> bdmurray: I don't know; I do know that the update fixes some crash bugs and I'm hoping it fixes more crashes than it creates :|
#ubuntu-devel 2016-10-26
<cpaelzer> good morning
<slangasek> rbasak: mariadb-10.0 seems to have a lovely SIGBUS on armhf at build time, that makes default-libmysqlclient-dev uninstallable
<pitti> Good morning
<cpaelzer> good morning Pitti
<pitti> hey cpaelzer, how are you?
<cpaelzer> pitti: fine fighting a weird FTBFS - just the right thing for a foggy morning
<cpaelzer> pitti: I hope you are good as well
<cpaelzer> pitti: I realized we see again in a few weeks
<pitti> cpaelzer: Fails To Be Fair and Sunny?
<pitti> cpaelzer: I am, yes!
<pitti> cpaelzer: indeed, next week Bucharest and start of Dec the cloud sprint
<cpaelzer> The Dec one for me
<rbasak> slangasek: ah. I want a delta to switch back to MySQL in Ubuntu anyway, so I'll do that now.
<LocutusOfBorg> thanks rbasak
<LocutusOfBorg> I retried once again mariadb
<LocutusOfBorg> it failed even on amd64 now
<LocutusOfBorg> isn't it possible to avoid such delta?
<rbasak> Exactly which delta do you mean?
<rbasak> The one against mysql-defaults?
<rbasak> I suppose I could dynamically adjust the control file. It seems more effort though.
<rbasak> I would like to do it eventually, but for the moment it seems easier with a delta.
<LocutusOfBorg> I think fixing mariadb-10 can save a delta and time
<LocutusOfBorg> I'm talking about stuff like gambas3, vtk6 and so on
<rbasak> I don't follow.
<LocutusOfBorg> they are entangled with mariadb-10 because of mysql-default
<Laney> If you fix mysql-defaults to be installable then things start being buildable
<Laney> rbasak: are you aware of https://launchpadlibrarian.net/290831960/upload_11078266_log.txt ?
<rbasak> No, I only just noticed that my upload was rejected. Thanks
<Laney> from a quick peruse, looks like mysql should stop building that package
<rbasak> Laney: yes, that's the plan. I didn't think I needed to do that right now to fix mysql-defaults though, as that should go higher?
<rbasak> Just my next mysql-5.7 upload.
<rbasak> (which is only a tiny delta from what is in sid)
<rbasak> This MySQL/MariaDB stuff is messy :-(
<Laney> rbasak: It means that mysql-5.7 can't be uploaded as it tries to publish an older version of a binary package
<rbasak> Yes, I will fix that.
<Laney> thanks!
<Son_Goku> tvoss, did you have any luck reproducing my issue with mir builds?
<cpaelzer> I'm currently on fixing a FTBFS caused by us having default ldflag "-Bsymbolic-functions" which Debian does not - to complete my personal Ubuntu history lesson I wanted to ask if anybody has a pointer/link to the reasoning to add it for us (it seems we have this for ages - 13.10 I think)
<jbicha> cpaelzer: not quite what you're asking but in gedit's rules file, we use   export DEB_LDFLAGS_MAINT_STRIP := -Wl,-Bsymbolic-functions
<cpaelzer> jbicha: yeah I found that in fox1.6, tango and lapack
<cpaelzer> jbicha: my fix is already based on that - just wanted to complete my understanding of the whole thing
<cpaelzer> jbicha: actually IMHO the best example is in fox1.6 is written by doko in a way to make it debianizable
<cpaelzer> jbicha: useful in case you want to get to no-delta with a package having just that left
<ginggs> cpaelzer: https://wiki.ubuntu.com/ToolChain/CompilerFlags links to an libxfont1 bug with some explanation
<cpaelzer> ginggs: thanks, that seems to be a bookmark worthy page for packaging in general
<arges> rbasak: did debootstrap get SRUd? (saw the message from earlier)
<rbasak> arges: powersj has bug 1636583. Not sure if that's ready for sponsorship yet (he hasn't subscribed ~ubuntu-sponsors)
<ubottu> bug 1636583 in debootstrap (Ubuntu) "SRU: Add zesty series link" [High,In progress] https://launchpad.net/bugs/1636583
<arges> rbasak: yea no debdiffs, but whats in the ppa seems correct
<rbasak> He'll be online in ~3 hours I think.
<arges> ok
<LocutusOfBorg> jbicha, please syncpackage lirc -d experimental -s costamagnagianfranco
<LocutusOfBorg> thanks
<LocutusOfBorg> ops -f
<dupondje> slangasek: https://packages.qa.debian.org/f/freetds.html guess this should get updated once :) I see your maintainer of it
<dupondje> its actually quite broken atm :(
<rbasak> src:mysql-defaults MIR should be a no-op. mysql-common is moved from a package already in main, and the rest is just metapackages.
<powersj> rbasak: arges: will make the debdiffs shortly
<JordiGH> What's the trust model for a PPA? Anyone can setup a PPA and possibly server malware from it, right?
<JordiGH> *serve
<rbasak> Correct. Though you can only upload "source", somebody could call a malicious binary "source" and upload that.
<rbasak> It would be a code of conduct violation of course, if that matters. In other words, it'd be removed upon notification I expect.
<JordiGH> I see, thanks.
<xnox> JordiGH, one must sign up for launchpad account; sign code of conduct; and upload open-source code only; but that's all procedural questions, indeed one can serve mallicious code; however when discovered, it would be blocked / removed.
<JordiGH> How is the source-only thing enforced? Files with null bytes are rejected?
<rbasak> It isn't enforced.
<xnox> JordiGH, nothing is enforced.
<xnox> (there are no technological barriers in place, any valid source package is accepted, and it should manage to generate binary debs)
<xnox> JordiGH, are you looking to host proprietary software with viruses? =)
<JordiGH> No, just purely hypothetically. Someone in #emacs got an Emacs from some PPA and it seems to be misbehaving. It's more likely that it was an error, not malice. Just curious how likely malice was possible.
<xnox> JordiGH, at one point the free UbuntuOne accounts hosted the leading pirated warez & movies share site contents in Turkey.
<Unit193> Hah really?  Niiice.
<JordiGH> Heh, well, from where I'm standing, filesharing isn't malice, although it's not nice to overwhelm Ubuntu's infrastructure with something it wasn't intended for.
<xnox> JordiGH, emacs in the ubuntu archive is good enough for most things. things that misbehave are possibly ELPA installed packages, or nightly builds which be definition are asking for trouble =)
<xnox> JordiGH, yeah, our sysadmins noticed the bill for all the download traffic.
<powersj> rbasak: uploaded debdiffs, however not sure if that really captured the fact that the files are symlinks :\
<rbasak> powersj: ah, in that case do you want to stick the source packages somewhere I can download them?
<rbasak> eg. people.canonical.com. Or alternatively I can use the PPA if the upload is identical except for the version numbers.
<powersj> I can upload the new versions to the ppa real quick that way you don't have to mess with the version number, does that work?
<rbasak> That has a tendency to mess up the PPA
<rbasak> Well, technically it won't, but any users of the PPA won't upgrade to the archive versions then.
<powersj> ah good point
<rbasak> I'm quite happy to mangle the version numbers. It doesn't really take any more effort.
<powersj> rbasak: ok then lets do that
<rbasak> OK looking
<rbasak> powersj: uploaded. yakkety needed to be 2.1, which I only noticed after uploading, so I uploaded a second one of 2.1. ubuntu3 will need to be rejected since it already exists in zesty.
<rbasak> arges: ^ still around?
<powersj> rbasak: my bad forgot to check zesty version
<caribou> I have yet another question about the samba static library story : given that I created pam_winbind-static & libwinbind-client-static libraries to be used to link winbind, those libraries should also be included in their respective package along with their shared counterparts right?
<caribou> pitti: this is the question I asked you yesterday
<pitti> caribou: why would we ship the static (.a) libraries?
<caribou> pitti: that's what I'm wondering now; it was not in the initial debdiff
<pitti> caribou: I would never ship a static .a library unless there is a very convincing reason to do so
<caribou> pitti: the reason behind the use of static lib is to avoid ABI breakage when samba upgrade samba-libs & libpam-winbind/libnss-winbind are not yet upgraded
<pitti> caribou: yes, I know, but that only applies to linking the built PAM module against it
<pitti> which is all internal to the package build -- there is no reason to also ship that built .a file
<pitti> which is what your question was about, no?
<caribou> pitti: yeah, I had second thoughts so I prefer to ask
<caribou> pitti: thanks for confirming my guess
<pitti> caribou: i. e. the package list shouldn't change, just that the PAM modules will get bigger and drop their dependencies to libsmb
<caribou> pitti: thanks, was being too cautious
<pitti> caribou: no worries, better safe than sorry when it comes to stable updates :)
<caribou> pitti: especially with samba & winbind; don't want to have all those users unable to login
<slangasek> rbasak: ok, I thought it was meant to be switching back, wondered what was happening there... packages have been building against the wrong implementation for 5 days now, we'll need to rebuild those the other way I guess?
<rbasak> slangasek: yeah I missed that I needed to apply a delta when autosync got turned on, sorry. Yes, we need to rebuild the other way. I think LocutusOfBorg is taking care of it.
<slangasek> ok
<slangasek> fwiw it wasn't autosync
<rbasak> Ah
<LocutusOfBorg> slangasek, I did the
<LocutusOfBorg> them
<LocutusOfBorg> they are listed in -release
<LocutusOfBorg> I BTW just looked for packages in update_excuses with "depends mariadb-10 (not considered)"
<slangasek> yep
<LocutusOfBorg> not sure if we have something that has never been rebuilt, and then not shown on that page
<rbasak> LocutusOfBorg: based on apt-cache rdepends libmariadbclient18 on zesty-proposed, I agree with that list.
<jbicha> bdmurray: I looked at https://errors.ubuntu.com/problem/18b5e69225bd63387d958707585693d52919b7c4 and all 3 16.10 reports appear to be from
<jbicha> /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so which is shipped by gnome-shell
<CliveGerard> Hi, it looks like I need some help - I've logged on to UbuntuOne and tried to create a "derivative subpage" - It seems to create it but wont let me edit it! Do I need special permission?
<CliveGerard> Is this a question for ubuntu-doc or somewhere else?
<jbicha> bdmurray: I figured out how to duplicate the bug with both the old and new versions of webkit2gtk so please set phased-updates to ignore that error, see bug 1636616
<ubottu> bug 1636616 in webkit2gtk (Ubuntu) "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitPluginProcess:11:WebKit::NPN_InvokeDefault:on_shell_signal:ffi_call_unix64:ffi_call:g_cclosure_marshal_generic" [Undecided,New] https://launchpad.net/bugs/1636616
<bdmurray> jbicha: Will do, thanks for digging into that!
<hallyn> mwhudson: hi, do you guys plan to backport golang 1.7 to xenial?  (I assume not, but have to start somwhere with my questions :)
<hallyn> mwhudson: apparently there is a bug with non-string keys serialized to json which is fixed in 1.7 (i'm not sure which commit it is unfortunately, only heard second-hand and haven't dug in yet); wondering how much work i'll have to do for that,
<hallyn> mwhudson: or whether i should just install from upstream and forget the golang package
<ogra_> barry, (noticing you are not in #snappy i'll ask here) ... did you ever test one of the dailies on your BBB ? i.e. http://people.canonical.com/~ogra/snappy/all-snaps/daily/
<ogra_> i tested it last about 10 days ago but had none of the issues you see
<ogra_> (it is a bit irritating that you run into so many probs)
<barry> ogra_: i haven't tested any of the dailies, i shoudl do that (and get on #snappy
<ogra_> the oops you see should actually be fixed in edge
<ogra_> we have a new linux-bbb snap there
<barry> ogra_: i did build with ubuntu-image -c edge
<ogra_> hmm
<ogra_> barry, in any case the oops comes from the onboard NIC, if you use a USB NIC it should be fine
<ogra_> (that is how i worked around it until ppisati landed the fix)
<barry> ogra_: ah, that must be why dhcp isn't working then?
<tdaitx> question about packaging a GPLv2 binary that links to GPLv3+ binutils: a developer I know asked me how to package hsdis for openjdk due to license conflicts... hsdis is made of 2 GPLv2 files that rely on binutils (GPLv3) for debugging, so it is clear that building and distributing that binary is trouble, are there other ways to package it that would avoid such trouble? maybe something similar to dkms where the binaries are build when the user
<tdaitx> installs it? are there packages with a similar story?
<ogra_> right
<barry> ogra_: i don't have a usb nic.  but let me try the daily
<barry> ogra_: today's daily still kernel oopses
<ogra_> weird, it didnt for me
<ogra_> (but that was when i tested the proposed kernel)
<ogra_> i'll test again tomorrow
<barry> ogra_: cool
<ogra_> barry, but no cloud-init i hope :)
<barry> ogra_: no cloud-init!
<ogra_> yay
<barry> progress
<ogra_> i'll have to check with paolo why the patch isnt there then
<barry> ogra_: cool, thanks.  let me know.  i'm going to move on to other things for the rest of the day
<ogra_> +1
<ogra_> (unless you want to fix the oops ;) )
<jbicha> bdmurray: how do I find my errors.ubuntu.com System Identifier to see errors reported from this computer?
<bdmurray> jbicha: /var/lib/whoopsie/whoopsie-id
<infinity> tdaitx: Which part of binutils does it link against?
<tdaitx> infinity, I haven't checked, just got the question a while ago and found a few posts/comments that no one had binaries because of license conflict
<tdaitx> infinity, what should I look for exactly?
<infinity> tdaitx: Well, look for what it's linking. :P
<infinity> tdaitx: The binutils source isn't under a uniform license.
<infinity> libiberty, for instance, is LGPL2+
<tdaitx> infinity, oh, I see, let me check that then, thanks for the heads up on this
<infinity> tdaitx: bfd is potentially more problematic, though it would seem almost no one pays attention to that conflict... :/
<infinity> tdaitx: But, the longer answer is that if it's linking GPL3+ code, the source in question should be licensed as GPL2+, and it'll become 3+ defacto when distributed as a whole.
<infinity> tdaitx: If it's 2-only, upstream might want to fix that, since they've created an impossible situation for downstreams.
<tdaitx> infinity, and folks had asked for oracle to do just that more than once, it's just 2 files, but they never did it
<infinity> Fun, fun.
<tdaitx> hsdis is only used for debugging, it's not exactly a part of openjdk
<mwhudson> hallyn: i have no real plans to backport golang 1.7 to xenial, no
<mwhudson> hallyn: you can install from ppa:~gophers/archive though
<tdaitx> infinity, it links to: bfb, libiberty, and opcodes
<infinity> Yeah, pretty sure bfd is GPL3+
<infinity> So, sucks to be you, basically.
<tdaitx> infinity, so, building it during package install (like dkms) is not an option?
<infinity> It's a hackish option, sure.  If you want the package to depend on a toolchain just for that.
<infinity> (honestly, the concept of dkms is pretty letter-of-the-law-but-spirit-of-a-complete-jerk anyway, but meh)
<tdaitx> yeah, I know
<infinity> The reason everyone gets away with it for dkms is because Linux upstream really doesn't care. :P
<infinity> binutils being an FSF project, they might care more.  OTOH, I suspect libbfd is used in all sorts of places it shouldn't be.
<tdaitx> infinity, anyway, any chance a package like that would be accepted? or would it have to live inside a ppa?
<infinity> Anyhow, legally, we could probably allow such an abomination in the archive.  Technically, is it really important enough to be worth the hassle?
<infinity> From a legal standpoint, PPAs follow the same rules as the archive.
<infinity> Anyone who uses PPAs to skirt the law is in massive violation of our TOS and, well, the law.
<tdaitx> depends on what "important" means... any user that needs to debug openjdk has to build hsdis by himself, which is a hassle
<tdaitx> but usually anyone looking to debug openjdk can probably figure out how to build it (still a hassle though)
<tdaitx> infinity, and I think that oracle's lawyers asked exactly how important it was for them to decide if they would allow the gpl2+ change... the last thread about it died after devs said they couldn't comment on it and had forwarded the issue to higher powers
<tumbleweed> win 62
<tumbleweed> err
<Unit193> Bingo.
<infinity> tdaitx: FWIW, RedHat's just taken the hard line of "incompatible license, go away" as well.
<infinity> tdaitx: I'm honestly more comfy with that, especially in terms of pressuring Oracle.
<infinity> tdaitx: If we come up with a sketchy legal hack, then they'll be less likely to listen to anyone about fixing the license.
<infinity> tdaitx: However, a README.hsdis that details *how* to build it would be an alright compromise.
<tdaitx> the situation has not changed for years, I doubt the right people care about it
<tdaitx> infinity, right, that is a good suggestion, I will see to at least have that file written down
<infinity> (ie: apt-get source openjdk && apt-get install build-essential binutils-source && make -C foo/bar BINUTILS=/usr/src/thing ARCH=whee)
<infinity> binutils-source is probably overkill, if you can make it work with binutils-dev, which already has the right static libs built.
<tdaitx> yeah, I think so
<tdaitx> infinity, thanks for the help =)
<infinity> tdaitx: So, I wouldn't even be against you providing that as a script that just DTRT, where I'm likely to want to draw the line is the package install triggering it automatically.
<infinity> tdaitx: But if you do it as a script, you can also write an autopkgtest that runs it (and throws away the results), so you can be sure that new binutils or new openjdk don't regress the magic.
<infinity> tdaitx: Then you can be fairly confident with saying "just run this if you need hsdis", and you're good to go.
<tdaitx> infinity, that is an awesome idea! and I have just added autopkgtests to the latest openjdk-8, so this is a nice addition
<infinity> tdaitx: Maybe bonus points if the script has a quick "this will combine incompatibly-licensed code from openjdk and binutils, this is fine for local use, but you can not redistribute it" confirmation before it does the thing.
<infinity> Which (a) sort of covers our butts, and (b) is a nice reminder of WHY we're making the user do this silly thing manually.
<tdaitx> indeed
<infinity> "If you think this is silly, please complain to Larry Ellison, PO Box #1234, Station M..."
<Unit193> Hah. :D
<infinity> Although, I have much larger complaints for Larry, if you happen to track him down. :P
<Unit193> infinity: BTW, any idea why src:geoip hasn't sync'd?  Is it still catching up?
<infinity> Unit193: autosyncs aren't on yet until we're sure Perl's in a happy place.
<infinity> Which it might be now.  I've not looked today.
<Unit193> Ah, I see.  Thought I saw some syncs slipping past already.  Sorry for the poke then.
<pitti> no, there are still two metric tons of rebuilds missing
<tsimonq2> infinity: To repeat myself from a few days ago, if there's something that I can help with that has an easy solution, don't be afraid to ping. ;)
<infinity> pitti: Well, I define "happy place" as "autosync won't break the world", not "it's ready to transition to the release pocket".
<pitti> well, we have openmpi+perl+mysql entangled already -- I think we should better wait until that landed
<infinity> Perhaps fair.
<mwhudson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mwhudson
<hallyn> mwhudson: ok thx
 * hallyn tries out how to use that archive
<mwhudson> hallyn: golang-1.X-go installs to /usr/lib/go-1.X so you'll need to add /usr/lib/go-1.X/bin to PATH
<hallyn> right, i'm doing this as part of a machine setup in a juju charm, so i'll need to redirect
<mwhudson> ah
<mwhudson> nacc: ayt?
<nacc> mwhudson: pong
<mwhudson> nacc: can you operate the git import machinery?
<nacc> mwhudson: yeah, which src package?
<mwhudson> nacc: aptitude
<nacc> mwhudson: ack, will ping you when its done
<mwhudson> nacc: awesome, thanks
<nacc> smoser: given that putting changelog entries in the commits is a 'nice to have', why don't we just not make it fatal when we can't obtain it?
<nacc> smoser: that would fix LP: #1636529 as well, afaict
<ubottu> Launchpad bug 1636529 in usd-importer "UnicodeDecodeError on package gmp and others" [Medium,Confirmed] https://launchpad.net/bugs/1636529
<mwhudson> LocutusOfBorg: hey, re https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1632357, has llvm-toolchain-3.6 been removed from sid or something?
<ubottu> Launchpad bug 1632357 in llvm-toolchain-3.6 (Ubuntu) "Sync llvm-toolchain-3.6 1:3.6.2-4 (main) from Debian unstable (main)" [Wishlist,New]
<mwhudson> LocutusOfBorg: or is there some strange bit of history here i'm not getting?
<nacc> it does look to be only in testing now
<mwhudson> and only at 1:3.6.2-3
<nacc> yeah, strange publishhistory says 3.6.2-4 got deleted 12 days ago
<mwhudson> this is why patch piloting is hard, 30 mins of poking to just get more confused
<nacc> mwhudson: https://packages.qa.debian.org/l/llvm-toolchain-3.6/news/20161014T115303Z.html
<nacc> mwhudson: looks like they are moving to 3.8/3.9 and maybe 4.0 only
<mwhudson> nacc: in which case syncing the package looks a bit pointless :)
<nacc> mwhudson: we only need 3.6 for clamav, aiui, and I believe folks were working on making that compatible with 3.8
<mwhudson> i guess we should consider following
<nacc> ack
<nacc> mwhudson: yeah, and it looks like libclamav7 in sid now just doesn't use llvm at all
<nacc> mwhudson: so presumably we need to merge/sync that and then we can demote, at least
<mwhudson> ah yeah, doesn't look like we're too far behind
<mwhudson> bit scary though :)
<nacc> mwhudson: yeah, i'd push back, probably, and caribou and LocutusOfBorg can resolve it :)
<jbicha> tumbleweed: you're in 62+ IRC channels? how do you get any work done?
<tumbleweed> jbicha: good question :P
<mwhudson> nacc: yeah
<mwhudson> nacc: how goes the aptitude import, what sort of timeframe should i expect?
<jbicha> I mean it would probably help if people like me aren't pinging you all the time either ;)
<nacc> mwhudson: it's up to karmic right now, hopefully w/in the next 15 minutes, presuming we don't get any parse errors :)
<mwhudson> nacc: ok
<tumbleweed> jbicha: naah, I was out getting coffee. Some of those are work channels. And many are idle. The rest I don't really read, but vaguely watch
<nacc> mwhudson: it's pushing up to the git repository now
<nacc> mwhudson: sorry it's taking so long, first imports take a while :)
<nacc> mwhudson: alright, pushed, https://code.launchpad.net/~usd-import-team/ubuntu/+source/aptitude/+git/aptitude
<mwhudson> nacc: thanks!
<nacc> mwhudson: np
#ubuntu-devel 2016-10-27
<mwhudson> @pilot out
<nacc> mwhudson: that didn't seem to take? :)
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<nacc> ah there it goes
<mwhudson> yeah i was wondering
<mwhudson> just slow it seems :)
<cpaelzer> good morning
<pitti> Good morning
<Saviq> pitti, hey, can you please restart this with all proposed http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#ubuntu-settings-components
<Saviq> we're missing a Breaks: there
<pitti> Saviq: done (you can't use request.cgi for unity?)
<Saviq> pitti, can I?
<pitti> Saviq: it checks if you can upload the package -- then you can also retry its tests
<Saviq> pitti, I think I never had that right - and even if, would it accept all-proposed as a parameter?
<pitti> Saviq: yes, &all-proposed=1
<Saviq> pitti, ack, don't have the rights to upload anywy
<Saviq> should probably work on that
<LocutusOfBorg> pitti, do you think indicator-location can use a newer llvm? I'm trying to remove llvm-toolchain-3.6
<pitti> LocutusOfBorg: no idea, I'm afraid
<LocutusOfBorg> ack :)
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/indicator-location/+bug/1637128
<ubottu> Launchpad bug 1637128 in indicator-location (Ubuntu) "please switch to clang-3.8 or newer" [High,New]
<LocutusOfBorg> do you know where I can find Mirv?
<pitti> LocutusOfBorg: normally here, but apparently out today
<LocutusOfBorg> I asked a qtcreator merge from Debian with a private message, because I want to get rid of llvm-3.6
<LocutusOfBorg> caribou, hi, did you have time to look at clamav merge?
<rbasak> oSoMoN: regarding webbrowser-app in the SRU queue for Yakkety, it seems that there are things in the diff not mentioned in the changelog with no bug reference. Is it bug 1599695 that is missing perhaps?
<ubottu> bug 1599695 in webbrowser-app (Ubuntu) "When running cmake from QtC on a webbrowser-app branch it fails" [High,Fix released] https://launchpad.net/bugs/1599695
<rbasak> oSoMoN: it would be nice if your changelogs made it easier to locate which bits of diffs correspond to which fixes. It isn't at all clear.
<barry> pitti: ping
<barry> pitti: i have an interesting autopkgtest question for you
<pitti> hey barry
<xnox> barry, systemd package does boot VMs in the autopkgtest.
<pitti> ok, so xnox knows the answer before barry even asked, well done :)
<xnox> pitti, i am speculating =)
<LocutusOfBorg> is the auto-import from debian working?
<pitti> as for qemu-in-qemu, that works, yes
<pitti> LocutusOfBorg: not yet enabled; I think it's better to land perl first, to not entangle it with even more transitions
<LocutusOfBorg> pitti, I guess so, but I would write this in the -release topic
<LocutusOfBorg> and probably I would transition xapian and boost before :)
<LocutusOfBorg> xnox, can we have boost1.63 directly? or is it too much work?
<LocutusOfBorg> they should have fixed openssl1.1, so we might save some time on the next transition
<barry> xnox: yeah, no, that's not my question :)
<xnox> LocutusOfBorg, boost 1.63 is not released.
<barry> pitti: is it possible to have different restrictions for different distroseries?  e.g. i needs-root for xenial but nothing newer
<pitti> barry: no, sorry; a test doesn't actually have a concept of a "distro series" -- it runs in whatever apt config/environment you put it in
<pitti> barry: you can emulate it by having two Test-Commands: with calling the same test script twice, and then the script runs/skips itself when it's (not) root
<pitti> barry: but that does sound strange :)
<pitti> barry: ISTM that this is a decision which should not be done by looking at the release, but at the actual property you need, so that it also works for backports and the like
<xnox> barry, you can have multiple paragraphs in debian/tests/control. one with needs-root, the other one without. And in the test do a check on distro-series, and e.g. exit 0 if run as root.....
<barry> pitti: i guess the script could test `lsb_release -cs` or some such
<pitti> barry: I'd strongly advise to not do that
<LocutusOfBorg> xnox, interesting, the watch file from debian/ picks it up https://qa.debian.org/developer.php?login=smr@debian.org
<xnox> barry, check for the version number of tools that you need to run with root/without root.
<xnox> capabilities, etc.
<pitti> barry: you can also always start as root, and drop privs to $AUTOPKGTEST_NORMAL_USER if you don't want them
<barry> xnox: that's what i was thinking but it might not be a good idea.  i know the code is dtrt.  iow, this is a fallback feature
<xnox> LocutusOfBorg, up until two weeks ago, we did not have ability to look into subfolders with sourceforge uscan redirector. And hightly builds in boost, use next release final version number.
<LocutusOfBorg> picked up by https://sourceforge.net/projects/boost/files/boost/snapshots/develop/
<LocutusOfBorg> yes indeed sorry for the noise
<barry> pitti: i really just want to emulate (or maybe actually execute) sudo when in xenial as normal user.  does $AUTOPKGTEST_NORMAL_USER require a password to sudo?
<xnox> LocutusOfBorg, read debian-devel =)
<LocutusOfBorg> xnox, all that spam? :)
<pitti> barry: that really depends on the testbed; you can of course drop something into sudoers.d/ yourself if you want to guarantee it (but then add breaks-testbed)
<barry> pitti: i mostly care about a.c.c, but that's not a bad idea
<barry> or maybe the least bad idea ;)
<barry> a.u.c
<pitti> barry: in cloud instances you have passwordless sudo, in lxc you don't
<pitti> barry: (that's just how it comes by default)
<barry> pitti: so something i have to arrange to be consistent
<barry> which is okay
<pitti> barry: but e. g. I sometimes run tests in my sid VM which doesn't have sudo at all (not something you care about, but I don't want to make that kind of assumptions in autopkgtest)
<barry> pitti: yep, that's entirely reasonable
<barry> pitti: thanks, that gives me food for thought
<rbasak> Laney: in your nautilus SRU, AFAICT some UTF-8 in debian/patches/0003-nautilus-canvas-Don-t-lay-down-desktop-icons-if-we-h.patch is unintentionally clobbered.
<mpt> â In the âCâ locale, the value of decimal_point is â.â, and the value of mon_decimal_point is ââ.â
<mpt> That canât be right, can it?
<mpt> An empty string as a decimal point
<mpt> (This from <http://www.gnu.org/software/libc/manual/html_node/General-Numeric.html>)
<Laney> rbasak: Shucks, I wonder how that happened as I didn't intentionally touch that file
<Laney> rbasak: jbicha broke it
<Laney> jbicha: I could have pushed my commit if you'd asked, probably just forgot
<jbicha> Laney: sorry, feel free to overwrite
<rbasak> That does look like a documentation bug to me.
<Laney> I already pushed another revision
<Laney> A documentation bug?
<rbasak> That was in response to mpt.
<rbasak> Sorry, I should give more context.
<rbasak> Oops.
<rbasak> Laney: sorry, I should give more context. :-)
<Laney> heh
<Laney> rbasak: I fixed it in bzr, can't be bothered to reupload though unless it gets rejected :-)
<Laney> Thanks for noticing!
<rbasak> Laney: thank you for the excellent SRU paperwork :)
<LocutusOfBorg> wow protoc is broken https://launchpadlibrarian.net/291064124/buildlog_ubuntu-zesty-amd64.gobgp_1.12-1_BUILDING.txt.gz
<LocutusOfBorg> probably in yakkety too
<Laney> I wonder if you can enforce quilt options in the source package
<Laney> (-p ab reprezent)
<jbicha> Laney: just patch quilt to change the defaults for everything! ;)
<Laney> the xnox method
<Laney> I think it was him that was advocating this last week
<xnox> yes
<rbasak> I would appreciate some way of developers using better quilt settings by default.
<brendand> is launchpad having an issue generating diffs?
<jbicha> I would like if quilt's patches by default would look more like git's format
<mpt> rbasak, yeah, looks like it
<rbasak> "-p ab --no-timestamps --no-index" is what I used, from https://wiki.debian.org/UsingQuilt
<rbasak> It's the extra diff noise created by no-op quilt refreshes with the default settings that bothers me the most.
<xnox> jbicha, GNU patch knows how to apply a few git things; GNU diff does not generate git-format patches; however i wonder if there are low level commands that git exposes such that quilt could use git for diff generation.
<rbasak> Makes reviewing take longer because I keep having to look up and down past the noise.
<jbicha> yeah, the fact that Step 1 on the wiki is to set those options seems an argument that they should just be made the default
<rbasak> There are uses for quilt outside Debian packaging however.
<rbasak> We want them the default for packaging uses, but others may want other things for the default when not doing packaging, and they use the package too.
<rbasak> (presumably)
<jbicha> make those users set a ~/.quiltrc then! since quilt can't be all that popular outside packaging
<xnox> rbasak, i'm all for shipping a sensible /etc/quiltrc or what not.
<rbasak> File a bug to change the default upstream? Or in Debian?
<sinzui> Is someone about to advise me on a grub configuration to boot an older kernel? http://pastebin.ubuntu.com/23388775/
<sinzui> rbasak: xnox ^
<rbasak> sinzui: sorry, all I know is that I've used http://askubuntu.com/a/216420/7808 in the past and it worked for me. You seem to have done it correctly, AFAICT.
<sinzui> rbasak: Small consolation that I read the docs right
<rbasak> sinzui: oh, is this on EC2 or something like that?
<rbasak> In that case, grub-legacy-ec2 is relevant.
<rbasak> If the host is using pygrub or similar.
<sinzui> rbasak: no, a ppc64el guest on a canonical network
<rbasak> I don't know if that's also special somehow.
<sinzui> smoser: ^ any advice on setting  default kernel in a ppc64el guest?
<sinzui> Oh, I think I need to use the uuid version
<smoser> i wrote this somewher.e..
<smoser> where did i write it
<xnox> sinzui, ubuntu always boots last configured kernel, so you can reinstall/reconfigure the kernel you want to boot and it will boot that by default.
<xnox> .... until next upgrade
<xnox> sinzui, if you don't want to move kernel, and don't want to receive security updates; you can remove the metapackage linux-generic-image or whatever the metapackage you use.
<sinzui> xnox: yeah, that was the stragey chosen a few months ago. Then I got the problem and want to keep the machine relaibly running
<smoser> i'm lokign, i wrote this dow. i sear.
<Laney> pitti: (from #-meeting) b1 calls promote-to-release
<pitti> Laney: thanks for the hint
<pitti> Laney: so that's what we'll need to teach about/parameterize for landing to -updates instead of -release
<Laney> Shouldn't be too hard to poke -updates in there
<smoser> sinzui, https://gist.github.com/smoser/93ba44ed30481df12577#file-boot-kernel is what i have had.
<smoser> and there is a link in that file to https://statusq.org/archives/2012/10/24/4584/
<smoser> oh, fudge.
<smoser> sinzui, though, on power8, grub doesnt actually load the kernel
<smoser> petitboot does
<smoser> so i do not know if such mechanisms would work.
<sinzui> smoser: oh! that explains a lot
<nacc> smoser: so i think at least some of the backoff you are doing would be specific to the environment; e.g., if `git fetch` fails, retry via a wrapper script to the importer?
<smoser> it may be a bug in petitboot if it does not.
<smoser> nacc, i'm not working on backoff, just suggested that we shoudl probably do that.
<nacc> smoser: right, but i mean in at least some cases, it's not an importer issue, but a how-you-run-the-importer (or where) issue
<rbasak> smoser: should the grub package even be installed in that case?
<rbasak> Seems a bit misleading.
<nacc> petitboot is only the bootloader in powernv mode
<smoser> nacc, i'm not convinced that i have a flakey network
<oSoMoN> rbasak, sorry if itâs not clear. the changelog mentions two bugs, which correspond to the two revisions in the SRU branch:Â https://code.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/+merge/308487
<smoser> until someone shows me other wise.
<smoser> ie, if reliability is an issue on the launchpad api side,then we shoudl fix better
<oSoMoN> rbasak, https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1543 fixes https://launchpad.net/bugs/1632620 and https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1544 fixes https://launchpad.net/bugs/1633439
<ubottu> Launchpad bug 1632620 in webbrowser-app (Ubuntu Yakkety) "No audio from webbrowser-app in 16.10" [Undecided,Confirmed]
<ubottu> Launchpad bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New]
<smoser> rbasak, grub is installed because it is what writes the files that petitboot reads
<smoser> petitboot parses grub2 config files
<rbasak> smoser: ah
<smoser> to some extent.
<nacc> smoser: i ran the exact command you ran on my machine at home and it worked without any exception
<smoser> i'm not sure whether or not it works for the "set default" and stuff.
<nacc> smoser: i'm not sure it's my responsibility to debug a bad network (given you've seen other network issues)
<smoser> sinzui, so the best thing for you to do on that system that has to stick on a kernel is probably just to only install that kernel or remove the meta-packages tahtt woudl get you new ones.
<rbasak> oSoMoN: where, for example, do all the changes in ua-overrides-desktop.js.in come from?
<nacc> smoser: what i'm asserting is that it's not appropriate for the improter to generically retry `git fetch` 3 times
<smoser> nacc, no. i've not seen any other network issues.
<smoser> i said the networking is not straight forward, we're using http proxy and such
<smoser> but i've never seen other things error as a result
<nacc> ok
<sinzui> smoser: yeah, I am doing that as xnox suggests. Not the best solutiuon, but it guarantees repeability
<smoser> sinzui, you maybe shoudl file a bug against petitboot
<smoser> https://github.com/open-power/petitboot
<sinzui> thank you for the pointer smoser
<oSoMoN> rbasak, thatâs https://bazaar.launchpad.net/~osomon/webbrowser-app/16.10-SRU1/revision/1544
<smoser> sinzui, 'grep -r grubenv' on that git checkout *does* show some hits
<smoser> so maybe they're  trying.
<smoser> have you actually tried the grub-set-default path ?
<rbasak> oSoMoN: I don't understand why that fixes an FTBFS.
<rbasak> oSoMoN: and I feel that this should be explained somewhere, eg. in a commit message, or in the SRU paperwork.
<oSoMoN> rbasak, running qmlscene inside xvfb at build time to determine the chromium version oxide is built upon proved to be unreliable, this change dynamically replaces the chromium version at runtime instead
<rbasak> oSoMoN: so you're changing runtime behaviour? I feel that this should be called out in the "Regression Potential" section of the bug!
<oSoMoN> rbasak, bug #1633439 mentions the original issue which was bug #1599695. I filed a new bug report precisely to make it clearer in a SRU context
<ubottu> bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New] https://launchpad.net/bugs/1633439
<ubottu> bug 1599695 in webbrowser-app (Ubuntu) "When running cmake from QtC on a webbrowser-app branch it fails" [High,Fix released] https://launchpad.net/bugs/1599695
<rbasak> oSoMoN: OK, so IMHO, that should be one bug with a task for each release. I think I follow now, thank you for the explanation.
<rbasak> bdmurray is sponsoring my SRU work so I'm not sure what exactly to ask for next.
<rbasak> I think I'd want clarity in the bug for whoever handles the SRU next.
<oSoMoN> rbasak, sorry for the confusion, I can see how itâs far from being obvious
<oSoMoN> rbasak, Iâll update the bug description to hopefully make it clearer
<rbasak> Perhaps dupe the bugs? I'm interested in bdmurray's opinion first though, before I ask you to make changes - since I won't be the one accepting it.
<rbasak> Thanks
<nacc> smoser: is it easy for you to retry the failures with master? (has a more generic retry on pull failure)
<bdmurray> oSoMoN: I think just using bug 1633439 is fine, but it'd be good to add test case information with sites to test that need the UA changes working.
<ubottu> bug 1633439 in webbrowser-app (Ubuntu Yakkety) "FTBFS on yakkety arm64: Invalid chromium version: ''" [Undecided,New] https://launchpad.net/bugs/1633439
<smoser> nacc, sure. i can just rm -Rf * and go again
<nacc> smoser: ok, let me look at a few more of the cases here, but that should, i think, catch the OSError ones if they are transient
<smoser> does master have my fix ?
<smoser> for utf-8
<nacc> we could bump the retry limit, too
<nacc> smoser: no, let me merge it if you've tested it now
<smoser> definitely need *some* sort of backoff
<smoser> what is there shoudl be good. i've tested it with 'gmp' which is what originally failed
<nacc> ack
<smoser> let me check though
<smoser> that it has commit messages :)
<smoser> rather than ''
<nacc> our current 'retry' is just to try 3 times, do you want me to add a sleep in between each retry?
<oSoMoN> bdmurray, Iâve just done that, in the [Regression potential] section of the description Iâve explained how to verify
<nacc> smoser: e.g., http://paste.ubuntu.com/23389014/ ?
<smoser> nacc, looks fine. http://paste.ubuntu.com/23389019/
<smoser> nacc, how long is that sleeping ?
<smoser> whats the range there
<nacc> smoser: the iteration count (i in 0-2)
<nacc> smoser: so a second to 4s, with fuzz
<smoser> i dont thin it has to be random. but some sleep is important for sure.
<nacc> we can start with this, let's see if it helps a bit
<nacc> smoser: looks good, the MR is good to merge then?
<smoser> yeah
<smoser> nacc, one random feature i'd like..
<smoser> is for a download cache outside of the workign directory for the package
<nacc> smoser: yes, that's one of the things we've talked about adding to the repository itself
<smoser> so that i could have a directory full of the thign that got downloaded (.dsc and .tar.gz and such) elsewhere.
<smoser> to the repository ?
<smoser> i personally do *not* want pristine-tar
<smoser> as i think that makes size of git repo go up dramitically
<nacc> there are ways, i believe, of caching recent versions in .git
<slangasek> smoser: have you measured this?
<slangasek> pristine-tar should provide very small deltas vs. the branches
<smoser> slangasek, no.
<smoser> slangasek, thats possible. its also possible that it doesnt really work.
<nacc> smoser: the other reason to go the pristine-tar route is compatibility with other tools
<nacc> smoser: but i'd file a bug (agains the importer) :)
<smoser> and i've pulled enough massive bzr trees to have non-scientific data making me think it sucks.
<nacc> smoser: master updated
<sinzui> smoser:  virsh is unhappy still on borbein: I see mesages about SMT. Do you have any insights http://pastebin.ubuntu.com/23389036/
<smoser> sinzui, http://bazaar.launchpad.net/~smoser/+junk/powerkvm-install/view/head:/setup-ubuntu
<smoser> run that
<slangasek> smoser: bzr itself seems to have never been as tight as git; I wouldn't attribute this to pristine-tar
<nacc> sinzui: smt needs to be off in the host to start the VMs
<smoser> slangasek, i said non-scientific data.
<smoser> :).
<smoser> if we want to add support to the importer, i'll run a big batch of uploads and compare .git
<slangasek> yeah, which is why I'm pushing back against the pristine-tar hate ;-)
<smoser> even if it were a small delta
<smoser> i'd be bothered.
<slangasek> heh
<smoser> i need to pull exactly one tarball, not the entire history of them
<smoser> but yeah, i'd be happy to be shown wrong by data
<slangasek> pulling a tarball + pulling a git branch, vs. pulling a git branch + pulling a set of small deltas
<smoser> theories are nice . you have one , i have one :)
<sinzui> thank you nacc I am setting it off
<smoser> i very well could be wrong.
<slangasek> :-)
<smoser> nacc, i committed 'returning ...' a debug message i think
<smoser> did you pull that?
<nacc> smoser: bah, can i elide that line?
<nacc> smoser: master updated
<smoser> nacc, you should print the error message at very least
<smoser> and WARN it
<smoser> so we can look for the actual error message even if we recover
<nacc> smoser: so next time when i ask if your MR can be merged, just say no.
<nacc> :)
<rbasak> slangasek: I thought pristine-tar was considered fundamentally broken and deprecated?
<nacc> smoser: what error message are you referring to? that's just printingout the changelog entry extracted from the tree?
<slangasek> rbasak: it has fundamental limitations; joeyh "deprecated" it, but it still has a maintainer and is widely used and the limitations haven't been a problem yet in practice
<smoser> nacc, sorry... in your 'except Exception'
<smoser> shoudl warn that
<smoser> on the retry
<nacc> smoser: oh duh, yeah
 * smoser notes how slangasek was quite on the whole "fundamentally broken" front when smoser was throwing hate
<smoser> :)
<nacc> smoser: what do you want me to warn? that we are retrying? so make that warn rather than print?
<nacc> smoser: or do you want the actual exceptoin?
<nacc> we'll raise it eventually if we can't recover
<slangasek> smoser: it's not fundamentally broken; it has a fundamental /limitation/
<smoser> nacc, 2 things
<smoser> a.) you might catch different onces
<smoser> b.) you might recover
<smoser> in both cases i want to see all the possible failure paths, not just the last.
<nacc> and i was going to say in b) i'd rather we didn't print anything :)
<nacc> it's irrelevant to an end-user if we do recover
<smoser> you can log.debug it if you want
<nacc> so i'd say it should be debug , if that's good by you?
<smoser> sure.
<nacc> smoser: is logging.debug(e) sufficient (given Exception as e)? Or do i need to format a string?
<slangasek> smoser, nacc: that limitation is that to reconstitute the orig.tar.foo from the pristine-tar branch requires a version of tools (tar, xz, gzip, ...) whose output is byte-for-byte equivalent to the one that was used at the time the pristine-tar delta was generated.  However, /in practice/, there haven't been any changes in any of the outputs since pristine-tar use began; and if there were, I
<slangasek> understand the pristine-tar maintainer is committed to providing the necessary glue (probably bundling older versions of the tools, or something)
<smoser> nacc, logging.debug("Source Package Download Error: %r", e)
<smoser> ?
<nacc> slangasek: yeah that's what i've read as well (in learning about the debian tools)
<nacc> smoser: ack on that
<nacc> smoser: master pushed
<smoser> nacc, i got to run for a bit. will try later.
<nacc> smoser: ack
<smoser> nacc, i thought you were saying you didnt want to print anything.
<smoser> oh... i see you didnt print the error message. only logged that. you did print a 'Failed to pull'...  i thought you were suggesting only do anything like that on failure (2 fails)
<nacc> smoser: i see what you meant earlier, which was the reason for failure could vary
<nacc> smoser: so i compromised :)
<smoser> sinzui, just for completeness https://github.com/open-power/petitboot/issues/24
<smoser> that fix would have to get into our firmwares, so its not coming any time soon
<sinzui> thank you smoser
<roaksoax> smoser: you should scalate that to push for a fix
<smoser> roaksoax, i'll scalate that!
<pitti> robru: did you change something in bileto wrt britney integration since yesterday or so?
<robru> pitti: maybe, why, what's up?
<pitti> robru:  the infra is getting bombarded with hundreds of identical content-hub and unity8 requests
<robru> pitti: for zesty?
<pitti> I killed the content-hub ones this morning and just now the unity8 ones (both are very expensive and block the infra, and we need it for zesty)
<pitti> robru: all releases
<pitti> robru: e. g. look at http://autopkgtest.ubuntu.com/running#queue-ppa-zesty-i386
<pitti> and the following ppa xenial amd64
<robru> pitti: I've been iterating at the db schema for the last few days, nothing that should really impact britney so much...
<robru> pitti: https://bileto.ubuntu.com/static/britney/last-run.txt one thing I noticed is that zesty results.cache 404s so maybe it's retriggering tests that it doesn't know already started?
<robru> pitti: should I turn on debug logging?
<pitti> four identical ubuntu-settings-components requests, three content-hub on amd64 (the fourth has a different trigger)
<pitti> robru: ok, that would explain zesty, but why v/x?
<robru> pitti: I dunno, did your autopkgtest-as-policy thing land yet? that would be my only guess, if there was a bug in that
<pitti> robru: and that's not the state of "I already requested this test", that's pending.json and your britneys  have their own
<pitti> robru: it did land, yes; it didn't change the pending.json, but it could be the time when this started
<pitti> robru: anyway, I'll symlink a zesty results.cache for now
<rcj> slangasek, Could you take a look at a livecd-rootfs mp? https://code.launchpad.net/~rcj/livecd-rootfs/zesty_grub/+merge/309517 It resolves a cpc zesty images build breakage for amd64
<pitti> robru: so, too late to debug this now, but if you could turn on verbosity that'd be useful; I killed all PPA test requests for now, but I have a feeling they'll come back by tomorrow..
<pitti> so I could check in the morning
<rcj> cyphermox, ^ in bug #1624096 it says you're backporting from zesty.  Will the shim/shim-signed file names remain constant during the backport?  Hoping so.
<ubottu> bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,Fix released] https://launchpad.net/bugs/1624096
<robru> pitti: ok will do. I'm reviewing my recent changes in iterate.py and I don't see anything substantial (it's just changing what json dict key names it accesses)
<rcj> Or maybe I got the root cause incorrect.
<pitti> robru: ok, not that then I figure; it looks like britney would lose/not write her pending.josn
<pitti> but verbose log should tell
<robru> pitti: ok, just turned it on. should see verbose logs in an hour or so. goodnight!
<pitti> robru: cheers!
<pitti> until then it hopefully chewed through the zesty queues
<slangasek> rcj: the filenames will change in the backport.  maybe we should try to figure out how to make this hook use grub-install, instead of hard-coding the filenames?
<pitti> robru: they come back faster than I can kill them; I temporarily disabled PPA queue consumption in the workers, this needs to be sorted out first
<robru> pitti: ok so no autopkgtests for bileto for today?
<pitti> robru: it's zero or infinitely many :/
<pitti> no updated last-run.txt yet, need to wait for that
<pitti> robru: actually the policy refactoring happened on Monday already
<pitti> robru: what did change yesterday was the removal of the backwards compat "tests/autopkgtest/" in the JSON
<robru> pitti: ah ok, got busy with other stuff, I'll try to finish up sourceppa quick
<pitti> but I thought that wouldn't have an effect on bileto as it was only grepping the .json for REGRESSION or RUNNING
<pitti> and it shoudln't affect the pending.json handling anyway
<robru> pitti: well bileto only uses the json to summarize it, there's no code in lp:bileto that would trigger autopkgtests from the json
<pitti> right
<robru> or yaml rather
<pitti> so, anyway, let's wait for the log; I don't have an off-hand idea what's wrong
<rcj> slangasek, I don't have history here.  I thought we had issues doing that in the build environment for grub uefi?
<robru> pitti: ok it's starting: https://bileto.ubuntu.com/static/britney/log_2016-10-27_21:40:02.txt
<robru> pitti: indeed the log says pending.json doesn't exist, it doesn't indicate writing one though
<slangasek> rcj: grub-install --target=x86_64-efi --no-nvram and your uncle is your namesake
<rcj> slangasek, I'll give that a go then.  Thanks.
<slangasek> rcj: oh, --uefi-secure-boot in there also
<rcj> slangasek, We do that not 10 lines later.  Hmmm.
<slangasek> huh ;)
<pitti> robru: hm, that's bad -- in e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/log/zesty/2016-10-27/21:12:07.log it does say that ("Updating pending requested tests in data/zesty-proposed/autopkgtest/pending.json")
<pitti> robru: oh, maybe it calls save_state() in the second stage only, which gets shortcut in bileto?
<robru> pitti: second stage?
<pitti> robru: that would make sense, given where it appears in ubuntu's logs
<rcj> slangasek, Do you think we can just drop the cp's on lines 73-75 since we're running grub-install on line 85 http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/033-disk-image-uefi.binary#L64
<robru> pitti: well I guess I configured britney wrong then? Can you find a problem here: https://git.launchpad.net/bileto/tree/britney/britney.conf.in
<pitti> robru: no, you didn't configure it wrong, it's just that the save_state() policy isn't being called with your config
<pitti> robru: but we actually want that to work (like before) to not run the seocnd-stage installability tester for you
<slangasek> rcj: yes, as that's exactly what grub-install is supposed to do for you
<pitti> robru: (care to take the BOOTEST out of that :) )
<slangasek> s/do for/encapsulate for/
<robru> pitti: ok. not clear to me why save_state isn't being called
<pitti> robru: so I think I know how to reproduce; setting UPGRADE_OUTPUT and HEIDI_OUTPUT to an empty value is how we agreed to disable those
<pitti> robru: thanks for your help, I think I have enough info now
<rcj> That's what I would think. So only explanation was that it wasn't odd in this env.  Where did this cp come from?
<slangasek> rcj: NB the grub_modules line is also pointless for amd64, a secureboot install doesn't let you add extra modules
<slangasek> rcj: also that shim copy never worked right, /boot/efi/EFI/BOOT/shimx64.efi would never be used (the right filename is bootx64.efi)
<rcj> hah
<rcj> Enlightening.
<rcj> I'll have a proper MP over tomorrow after running it through.  And thank you slangasek.
<pitti> robru: reproduced
<robru> yay
<pitti> robru: i. e. you can flip off verbosity again (if you care about the space, etc.)
<robru> pitti: ok thanks, I may leave it for a bit.
<pitti> robru: or you can as well halt the britneys for now, as they'll just wreak havoc
<robru> oh right
<robru> ok
<pitti> robru: so at least we won't lose anything -- for rollout we: (1) clear all current test requests, (2) roll out new britney, (3) next run (without pending.json still) will regenerate all requests
<pitti> I can do (1) easily, (2) happens automatically on your side
<robru> pitti: ok britney will be disabled shortly
<pitti> I have a fix
<cyphermox> rcj: sorry, I was distracted doing confusing work -- let me know when you have your livecd-rootfs change ready tomorrow and I'll be happy to review / merge it.
<cyphermox> fwiw I'm very much considering installing shim to /boot/efi/EFI/BOOT/BOOX64.efi by default as well as to the standard path, so that most setups work; but it will need to be done carefully
<cyphermox> (bootx64.efi and fbx64.efi along with a boot.csv in the right place will make fallback work correctly, but I'm worried about breaking Windows dual-boot)
<pitti> robru: fix pushed; you can update britney (needs reset-hard, I force-pushed) and let it run
<pitti> robru: sorry for the trouble
<robru> pitti: no worries, thanks for the fix
<pitti> robru: queues are clear; are there any currently running britneys after which I'll need to clean up again?
<pitti> robru: I also must remove the "ignore PPA queues" hack from the workers, once everything is in place
<robru> pitti: uh, yeah, https://bileto.ubuntu.com/static/britney/log_2016-10-27_21:40:02.txt is still going, not sure how many more it will trigger...
<pitti> robru: it now says "2016-10-27 22:21:08.969906 Completed in 0:41:06.929510."
<pitti> ?
<robru> pitti: ah ok, it's disabled now, but the last run shown happened after you asked
<pitti> robru: ok, seems quiet enough now; I put everything back to normal and drained the queues once more
<pitti> robru: I don't really want to wait another hour for the next run, but if we get a handful of duplicated tests now, it's not the end of the world
<robru> pitti: ok, safe to reenable?
<pitti> I'll check tomorrow morning
<pitti> robru: yes, as long as that updates britney
<robru> pitti: yeah that's automatic
<robru> pitti: HEAD is now at 4bc71e0 Drop backwards compatible autopkgtest excuse YAML structure
<pitti> robru: that's the one
<pitti> robru: the tame version of britney :)
<pitti> robru: cheers!
<robru> great
 * pitti waves good night
<robru> pitti: goodnight
<mwhudson> can someone set me straigh on how long i have to wait after publication before a build will use the built packages?
<mwhudson> https://launchpad.net/ubuntu/+source/golang-1.7/1.7.3-1ubuntu2 <- published an hour ago
<mwhudson> https://launchpad.net/ubuntu/+source/golang-context/1.1-1ubuntu4/+build/11088333 <- started 5 minutes ago but built with 1.7.3-1ubuntu1
<mwhudson> slangasek: ^ ?
<slangasek> mwhudson: you don't have to wait at all, after /real/ publication; but launchpad reports "published" at the start of the publishing cycle on ftp-master, which is $time before the new version is visible on the internal ftp mirror
<sarnold> mwhudson: I've heard "over two hours" earlier today...
<mwhudson> slangasek: hnngh
<slangasek> mwhudson: so if you care about this you should either poll your local ftp mirror to check it's availability, or (slower to update but a less expensive poll) check rmadison, or add a versioned build-dep so that the package dep-waits
<mwhudson> so i should wait until i see a "published" time on lp that's more recent than the published time for the builds i care about
<slangasek> however, 2 hours is unreasonably long, there must be something wrong on the infra side - sarnold who was discussing this?
<mwhudson> which would imply another publisher cycle has begun
<mwhudson> slangasek: yeah, i guess i should be adding a versioned dep really
<slangasek> infinity: do you know of any problems with pepo today? ^^
<slangasek> mwhudson: if it's working around a bug in a previous toolchain, that's usually not the preferred way, but it's better than nothing
<sarnold> slangasek: chris coulson, he said he was waiting ~two hours for firefox and thunderbird earlier today
<slangasek> hmm
<mwhudson> would make my shell script considerably more frigtening though...
<slangasek> there ought to be a way for us to set dep-waits explicitly through the API
<sarnold> slangasek: mdes laur also mentioned his nginx regression fix took a long time but he didn't give any numbers
<slangasek> (maybe there is and I just don't know it)
<infinity> slangasek: pepo's in the process of deleting lucid from /pool/, so it's likely in deep iowait.
<mwhudson> slangasek: yeah, it's a toolchain bug, adding versioned deps for this seems like it would be noisy
<slangasek> infinity: aha
<infinity> slangasek: A publisher run is just finishing up right now.
<sarnold> ouch that's a big delete :)
<infinity> But the load is through the roof, unsurprisingly.
<mwhudson> we don't have PCI flash for our archive mirrors yet? :)
<mwhudson> or one of those PCI-attached DRAM things
<infinity> Looks like this current publisher cycle is going to clock in at just over an hour.
<slangasek> someone told IS disk is cheap; so they gave us cheap disks to teach us a lesson
<mwhudson> hahahahaha
<sarnold> mwhudson: funny enough, pcie nvram is still quite slow onthe scale of things.. only like five times faster than regular sata ssd. 2.5 GB/s rather than RAM's 40-60 GB/s ...
<infinity> mwhudson: The mirrors have all sorts of fast, pepo itself doesn't.
<sarnold> slangasek: lol
<infinity> slangasek: build.dependencies is writeable, so it is in theory one could twiddle them via the API.
<nacc> smoser: do you have an updated set of the import-the-world failures with master?
<infinity> (This didn't used to be true when the feature was first implemented, I've never tried since)
<slangasek> infinity: ok now I know for the next time I have to do a ghc transition, ugh :)
<infinity> slangasek: Note that I've never attempted to write it from the API, I'm only trusting the docs to be accurate. :P
<nacc> cpaelzer: smb: do you have any patches pending for sru of qemu to xenial?
<infinity> slangasek: And "writeable" is pretty ambiguous, as it likely has strict permissions set as to *who* can write it.
<slangasek> phooey
<infinity> slangasek: But worth a try on a pending build somewhere.
<mwhudson> can you specify it when you create the build?
<mwhudson> or would you have to race the build starting?
<mwhudson> is there an ETA for debian autosync starting again?
<slangasek> or cancel the build, then set it?
<infinity> mwhudson: Well, you don't create the build...
<mwhudson> infinity: true
<infinity> slangasek: cancel/set/retry won't work, because of the way retry is implemented currently.
<slangasek> infinity: it wouldn't auto-retry once the dep-wait clears?
<infinity> slangasek: (retry pretty much blats the record to fresh, it's the thing we need to fix/mangle a bit to satisfy the wishlist for log history too)
<infinity> slangasek: Oh, ISWYM.  So, buildstate is also writeable (likely by the same permissions as dependencies), so you could cancel the world, then set the state to depwait and set dependencies, and that would likely DTRT.
 * mwhudson tries to remember how launchpad permissions works to figure out who can write to build.dependencies, gets lost, gives up
<slangasek> and dependencies is a flat string?
<slangasek> well, 401 for me
<nacc> smoser: fyi, timestamps adding to logging
<nacc> cpaelzer: fyi, usd-merge now should report a proper RC for that case
<nacc> smoser: the apt issue is that the usd-import-team repo is missing all the tags
<nacc> and i think the older pygit2 doesn't handle that as well
<nacc> smoser: im going to reimport apt and refresh the import-team repository
<mwhudson> what now?
<mwhudson> https://launchpadlibrarian.net/291117596/buildlog_ubuntu-zesty-ppc64el.golang-context_1.1-1ubuntu5_BUILDING.txt.gz
<mwhudson> -> Depends: debhelper (>= 9) but it is not installable
<sarnold> doesn't -everything- depend on debhelper (>=9)?
<mwhudson> and it built on amd64 against 1.7.3-1ubuntu1 even though i checked on archive.ubuntu.com
#ubuntu-devel 2016-10-28
<mwhudson> that  1.7.3-1ubuntu2 was published
<mwhudson> https://launchpad.net/ubuntu/+source/golang-context/1.1-1ubuntu5/+build/11088558
<cpaelzer> thanks for the RC nacc
<cpaelzer> nacc: only pending qemu SRU for Trusty, and incoming libvirt for Z/Y/X but takes while
<cpaelzer> nacc: so qemu in X is free for you if you got something
<cpaelzer> good morning
<pitti> Good morning
<smb> nacc, I got nothing pending (neither qemu nor libvirt) right now
<doko> LocutusOfBorg: please stop trying to discard needed llvm changes in Ubuntu
<LocutusOfBorg> doko, context please?
<doko> [Bug 1632357] Re: Sync llvm-toolchain-3.6 1:3.6.2-4 (main) from Debian unstable (main)
<ubottu> bug 1632357 in llvm-toolchain-3.6 (Ubuntu) "remove llvm-toolchain-3.6 from zesty" [Wishlist,Incomplete] https://launchpad.net/bugs/1632357
<LocutusOfBorg> doko, 1) llvm-toolchain-3.6 is removed in unstable, and -4 contains all the delta AFAIK
<LocutusOfBorg> https://packages.qa.debian.org/l/llvm-toolchain-3.6/news/20161007T184934Z.html
<LocutusOfBorg> 2) I would like to demote/remove it
<LocutusOfBorg> pretty sure I didn't drop stuff
<pitti> hey
<pitti> sil2100: it's simple, ppc64el is still squeaking under the perl load; amd64/i386 just caught up
<pitti> sil2100: it's in http://autopkgtest.ubuntu.com/running#queue-ubuntu-zesty-ppc64el
<pitti> i. e. queued
<LocutusOfBorg> the queue looks too green for perl
<sil2100> pitti: ah, thanks! :)
<doko> hmm, how do I make a haskell build verbose?
<doko> slangasek: ^^^
<LocutusOfBorg> doko, "-v"
<LocutusOfBorg> -v[0-4] gives you the right verbosity
<doko> LocutusOfBorg: passed to?
<LocutusOfBorg> ghc build
<LocutusOfBorg> "haskell build"  has no meaning, you want to build ghc in verbose mode or an haskell library?
<LocutusOfBorg> I did an hello world and used -v as flag
<LocutusOfBorg> it worked
<xnox> has arm64 switched to GLES by default for qt5?
<mitya57> xnox, yes, since 5.6.0+dfsg-2ubuntu1
<xnox> mitya57, ok, and is there non-GLES available for arm64? E.g. i know we do compile two types of qt stacks on some arches in ubuntu.
<mitya57> I think it works only in reverse direction...
<xnox> ok.
<nacc> smb: thanks!
<nacc> smoser: fyi, apt should import now (fixed the usd-import-team tree)
<nacc> LocutusOfBorg: did you see that -4 was removed from debian altogether though?
<LocutusOfBorg> nacc, yes, this is why the bug is now "please remove llvm-3.6 from zesty"
<LocutusOfBorg> btw I'm the one who is maintaining llvm-* in debian :)
<LocutusOfBorg> at least I'm partially working on it
<nacc> LocutusOfBorg: ack, i gathered as much :)
<LocutusOfBorg> and removing llvm-3.6 means, somebody have to merge qtcreator and clamav
<nacc> LocutusOfBorg: yep :)
<nacc> caribou: --^ i assume you are planning on that, or I can put it on my plate for z (for clamav)
<LocutusOfBorg> qtcreator needs somebody working on it, I don't feel confident enough in a merge
<nacc> LocutusOfBorg: delta seems pretty minimal, but yeah, probably deserves testing/experience by someone who knows :)
<LocutusOfBorg> nacc, if you have a patch I'm happy to test it
<LocutusOfBorg> a new release is needed for the compatibility
<nacc> LocutusOfBorg: ah
<nacc> LocutusOfBorg: i can look at it later today, maybe
<LocutusOfBorg> thanks
<LocutusOfBorg> I have permissions to work on it from the current maintainer
<ioria> hello ! i made a simple textual editor for .xpm icons... where i can upload it to share ?
<nacc> smoser: i think i can remove at least one call to dpkg-parsechangelog with a bit of reorg
<smoser> memoize makes magic faster.
<smoser> and removes 1/2 in my experience. i think for each branch we end up re-calling
<nacc> smoser: do you have the current list of failures?
<smoser> i can try to find
<smoser> nacc, at this point i think everything is working that i've gotten to.
<nacc> smoser: so the backoff fixed the download errors you were getting before?
<smoser> well, no. but i'm ignoring those for now.
<nacc> smoser: ok
<smoser> they still occur fairly regularly.
<nacc> smoser: note that i can't reproduce them
<smoser> but are you trying hundreds of packages ?
<nacc> smoser: are you running these in parallel?
<smoser> yeah
<nacc> ah
<smoser> but that really shouldnt matter.
<nacc> that's probably launchpad getting mad at you?
<nacc> :)
<nacc> i hope you talked to the launchpad folks first
<smoser> i'mi doing 16 at a time on that vm, load sits about 10
<smoser> well, i'm tyring more hard now to save the files i download (that was what i said i'd like as a feature)
<smoser> to be able to save .dsc and referenced files off to another directory.
<nacc> smoser: but why do you need them (generally)?
<smoser> i am a load, for sure, but i'm 16 connections... not like hundreds.
<smoser> just ro r-start it, but your'e right i dont really.
<nacc> ah ok
<nacc> yeah, to continue, but if you reuse the directory, it should just pick up from where it stopped (which would be where it failed to download before)
<smoser> this is true.
<nacc> that assumes it works :) which it does in my testing
<smoser> i am currently intrigued by the idea of pristine-tarball
<nacc> yeah, i think that's the direction we need to look at next
<smoser> i belive it can be added
<smoser> and given a tree with all the .dsc and .orig.tarball would be really easy.
<smoser> and even added in a one by one time.
<smoser> if we dont worry about a merge commit between upstream/ branches and ubuntu branches (or debian branches)
<nacc> right
<smoser> then i think we can just insert the upstream/tag files whenever
<smoser> and even re-order that branch and force-overwrite
<nacc> right, because nothing really depends on it, beyond for building purposes (afaict)
<nacc> smoser: i wonder if we can reuse gbp for this
<smoser> ie, no one should be depending on the state of that branch other than that it can recreate tarballs.  i think generally it would be nice to have the correct order if you logged it
<nacc> smoser: via import-orig or import-dsc maybe
<smoser> yeah.
<nacc> smoser: i will spend some time researching that today
<smoser> it says 'The sources are placed on  the  upstream  branch  (default:  upstream) tagged and merged onto the debian branch (default: master).'
<smoser> we wan the first 2 pieces of that import-orig but not the third
<nacc> yeah, there's also a --pristine-tar falg
<nacc> *flag
<nacc> "If you enable pristine-tar, delta files are committed to a pristine-tar branch if you call git-import-dsc or git-import-orig. When you build the package using gbp buildpackage, the exact tarball is regenerated using pristine-tar. "
<nacc> from https://wiki.debian.org/PackagingWithGit
<smoser> right. and clearly we want that :)
<nacc> yep :)
<nacc> i'll play with the options to see if we can get this working
<smoser> nacc, this one is awesome...
<smoser> http://paste.ubuntu.com/23393687/
<smoser> i'm pretty sure... unless i'm just being dumb that there are 2 different orig tarballs of the same upstream version there.
<smoser> and so downloader is saying that is imposible
<nacc> of differnt sizes
<smoser> yeah.
<nacc> does the changelog indicate if they broke or changed something?
<smoser> idont know. didnt really look
<nacc> smoser: the current changelog indicates 0.3.1-1 does not exist :)
<nacc> smoser: so probably 0.3.1-1 was a mistaken publish
<jgrimm> smoser, how's that cloud-init SRU coming along?
<smoser> :)
<smoser> working on it.
<jgrimm> :)
<slangasek> doko: haskell build verbosity> nooooo ideaaaa
<nacc> smoser: hrm, git-buildpackage does not like xgitified repositories
<nacc> barry: feel free to tell me this is just a bad idea, but i'd like to use git-buildpackage's python code to basically do what `gbp import-orig` does; however gbp is python2 and the importer is python3. Is my only option to call gbp directly (which doesn't work with our repository format, apparently)
<nacc> smoser: actually, to be specific, gbp doesn't like not having a .git unless it's a bare repository, rather than using an alternative GIT_DIR
<barry> nacc: first, it depends on whether the gbp code is even python3 compatible, which i don't know.  if it is (either by design or accidentally), then it's mostly a matter of getting it installed on a path that python3 can find it.  i'd try a virtualenv for that just to see if you can make it work
<nacc> barry: ack, thanks!
<barry> nacc: ack! :)
<nacc> https://github.com/agx/git-buildpackage/pull/16 looks to be the same issue i'm running into
<eu__> Hi all. I have installed Ubuntu Mate 16.10, AppArmor 2.10.95-4ubuntu5.1, QEMU emulator version 2.6.1, libvirtd (libvirt) 2.1.0. I'm create shared directory with virt-manager and successfully mount it inside guest. But i cannot nor write nor `ls' inside it. How to fix it?
<nacc> eu__: you probably want #ubuntu
<eu__> @nacc Sorry. Thank you.
<udevbot> Error: "nacc" is not a valid command.
<nacc> smoser: is there a reason you didn't convert all of the subprocess.run to run?
<smoser> nacc, i just missed it
<smoser> i noticed that today too
<nacc> smoser: ack, not a big deal, just wnated to check
<nacc> smoser: i'm working on switching us away from xgit-ified dependencies, and see if we can just use gbp as-is
<smoser> nacc, 558 total. 16 working. 524 pass. 18 fail.
<smoser> golang-golang-x-net-dev                  Unknown: AssertionError: source pkg version: 1:0.0+git20150817.66f0418-1 != changelog version: 0.0+git20150817.66f0418-1
<smoser> that one is interesting, then tehre is the gexiv2 error (different orig tarballs)
<smoser> and the rest are download errors
<smoser> http://paste.ubuntu.com/23395022/
<smoser> http://paste.ubuntu.com/23395027/ <-- i s gnutls28
<smoser> and /me goes
<smoser> wow
<smoser> $ du -hs firefox/git/
<smoser> 1.2G    firefox/git/
<smoser> and its not done
<slangasek> heh, golang-golang-x-net-dev has both 0.0+git20150817.66f0418-1 and 1:0.0+git20150817.66f0418-1 in its changelog
<nacc> urgh, and the 1: version's .dsc file says it's not an epoch bump, even though changelog does
<nacc> https://launchpad.net/debian/+source/golang-golang-x-net-dev/1:0.0+git20150817.66f0418-1
<rcj> cyphermox, When you have a chance, the livecd-rootfs change for cloud images is ready for review @ https://code.launchpad.net/~rcj/livecd-rootfs/zesty_grub/+merge/309517
#ubuntu-devel 2016-10-29
<cyphermox> rcj: ack
#ubuntu-devel 2016-10-30
<xnox> maxb, could you please verify the SRU https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1603436 using python-cassandra-driver from xenial-proposed?
<ubottu> Launchpad bug 1603436 in python-cassandra-driver (Ubuntu Xenial) "Regression in python2.7 SRU breaks python-cassandra" [Undecided,Fix committed]
<maxb> I'll try... though I may have to resort to installing xenial VM to do so at this point
<mwhudson> when is the autosync going to be turned back on
<mwhudson> ?
<tsimonq2> mwhudson: They're transitioning Perl.
<tsimonq2> mwhudson: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.24.html
#ubuntu-devel 2017-10-23
<juliank> slangasek: I forgot a few *stat*64 ones, _newselect(), and socketcall(), basically. But it's looking good now :D
<xnox> doko, rbasak - ruby2.5~preview1-1 is in debian new, hopefully we will take it as soon as it clears debian new. Or shall we open with ruby2.5 synced from like debian git or what not?
<rbasak> FWIW, I don't think server seeds ruby any more now, except via vim.
<rbasak> So wearing a server team hat, I don't have any particular opinion.
<doko> xnox: ohh, unstable. I assume that will migrate anyway. maybe let it migrate in Debian first?
<xnox> rbasak, sure, but you are available to help with the transition right?
<rbasak> Me with which hat? I'd like to help but I'm not sure where it would fit in with my rather large list of things I need to get done :-/
<xnox> rbasak, under the version currency mantra.
<xnox> foundations used to get tributes via +1 maint, but not any more =(
<doko> rbasak: ruby is sever owned ... but you didn't fix the ruby2.3 ftbfs either :-/
<rbasak> That's something for our managers to sort out I think.
<rbasak> Server is no longer pulling ruby into main.
<rbasak> We may have the bug subscription; it'd be irresponsible to drop that until the oldest release in which we _are_ pulling it into main EOLs.
<rbasak> But I don't expect the server team to be doing anything with ruby in B hile wearing a server hat.
<rbasak> *while
<rbasak> dpb1: ^
<xnox> dpb1, we need server team support for ruby2.3 -> 2.5, for ubuntu to stay version current. this cycle.
<xnox> dannf, it's booting! kind of =) i get to grub, which then tellsme that there is devicetree missing =(
<xnox> http://paste.ubuntu.com/25800503/
<sil2100> Laney: hey, I remember we had some discussion on the sprint about autopkgtests being re-run with 'vanilla-release' to see if the upload is actually related to the failure - do you know if I can somehow easily run such an ADT test in the infra?
<sil2100> Laney: i.e. a test with the machine only using the archive as is?
<xnox> sil2100, i use rerun button on the results, and then remove all triggers that then add &trigger=foo/1.23-4    such that foo is triggered by foo, with version from release pocket.
<xnox> to notice if something is regressed in the release all by-it-self already without anything new pulled in from -proposed.
<sil2100> xnox: where does the test result go then?
<xnox> on the package results page.
<xnox> e.g.
<sil2100> I mean, it'll just be accessible on the autopkgtest page for the package, right?
<sil2100> Ok
<sil2100> Let me try that then
<xnox> liek http://autopkgtest.ubuntu.com/packages/FOO/series/arch
<xnox> yeah
<Laney> right
<Laney> but I recommend running the thing yourself locally really
<ricotz> sforshee, hi, are you going to upload a 4.14rc6-based kernel to the ppa?
<sforshee> ricotz: yes, likely sometime today
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, jbicha, micahg, rbasak, sil2100: DMB ping.
<ricotz> sforshee, great, thanks!
<dannf> xnox: is this armhf? surprised qemu doesn't provide dt for it
<xnox> dannf, so i managed to run a magic qemu-system-arm -M dumpdts or some such, and then pass it back to qemu (which seemed redundant)
<xnox> dannf, but the kernel itself, I'm guessing is not loading the dts from EFI, and/or grub, or both.
<xnox> dannf, currently rebuilding linux on armhf with CONFIG_EFI and then will check grub code, to see if our grub has dts loading from UEFI tables on ARM, in addition to ARM64, it was refactored to be generic UEFI some time ago.
 * ogra_ has never heard of working armhf EFI support ... only about arm64 
<ogra_> (i'd be surprised if that worked)
<dannf> i'm pretty sure all the pieces are there
<dannf> i was asked to build the edk2 image for it (and did, it's in artful)
<ogra_> well, my experience stops at booting real HW ... :)
<Unit193> I've had to do some qemu tests for UEFI, both secure boot enabled and disabled.  That's as far as I got.
<xnox> and i have armhf uefi cloud image built
#ubuntu-devel 2017-10-24
<sarnold> bdmurray: hello! 1726297 hasn't retraced yet (CoreDump.gz is still attached), but was filed ~16 hours ago -- are the retracers happy?
<bdmurray> sarnold: I just had something retraced
<bdmurray> sarnold: Is it your bug?
<sarnold> bdmurray: no, someone else's, but it's currently private security, and I don't want to open it with a coredump still attached, but it'd be nice to get usable data out of it first if we can
<bdmurray> sarnold: do you know what arch the crash is?
<sarnold> bdmurray: x86_64
<bdmurray> sarnold: Hmm, well they tried! I'll dig into it tomorrow.
<sarnold> bdmurray: thanks! :)
<sarnold> bdmurray: a second similar case, x86_64, 17.10, 1726388 -- it also had the 'need-amd64-retrace' tag removed ~11 hours ago, but the CoreDump.gz is still attached and no new retraces
<fabbione> doko: do you still maintain toolchain in ubuntu?
<CoderEurope> https://www.youtube.com/watch?v=tE2PEzhA7IQ
<TJ-> sil2100: ping? re your comments on upstream dbus bug 95263: unix fd in-flight counting broken
<ubottu> bug 95263 in linux-source-2.6.20 (Ubuntu) "no sound kernel 11 and 12" [Undecided,Invalid] https://launchpad.net/bugs/95263
<TJ-> ubottu: you're not that intelligent you know!
<ubottu> TJ-: I am only a bot, please don't think I'm intelligent :)
 * TJ- nods
<smoser> nn
<sil2100> TJ-: hey! It's been a while since I last heard about that bug IIRC ;)
<TJ-> sil2100: do you have 5 minutes to talk about what you recall?
<sil2100> TJ-: hard to say, I wasn't directly encountering this issue, I was only a middle-man working on getting fixes released, not sure if I remember much of any importance
<sil2100> What do you need to know?
<TJ-> sil2100: Well, we have a user, maszlo, that both nacc and myself have been working with to debug an obscure issue. Lenovo T450, latest firmware, 17.10 upgrade from 17.04, acpi_osi="Windows 2015", etc. *only* when it starts on battery it fails to start. main reason is services fail because the rootfs is read-only. fsck in initrd succeeds, no issues.  *However* systemd-remount does remount rootfs
<TJ-> read-write but *something* causes it to be put back into read-only mode...
<TJ-> sil2100: ... we suspected laptop-mode-tools but having disabled that completely (.service and .timer and the polling) the issue still occurs. Then I noticed with "systemd.log_level=debug" that systemd starts reporting " Transport endpoint is not connected" and that eventually led me via systemd issue 2925 to dbus bug 95263
<ubottu> bug 95263 in linux-source-2.6.20 (Ubuntu) "no sound kernel 11 and 12" [Undecided,Invalid] https://launchpad.net/bugs/95263
<TJ-> sil2100: I checked 17.10 and saw we don't see to be carrying the fix from that dbus issue and wondered if you knew anything more
<TJ-> s/see/seem/
<jbicha> http://markshuttleworth.com/archives/1518
<sil2100> TJ-: give me a moment to look at the original bug again
<TJ-> sil2100: thanks.
<sil2100> TJ-: you said we're not carrying the dbus fix in 17.10?
<TJ-> sil2100: as far as I could tell from the changelog/version number, but the commit history looks a bit messed up since an accidental commit of the 1.11 branch into the 1.10
<TJ-> sil2100: plus it was 4am when I was looking, after 12 hours chasing this!
<sil2100> TJ-: ok, so from what I see we are carrying a fix for LP:#
<sil2100> eh, rogue enter
<sil2100> TJ-: ok, so from what I see we are carrying a fix for LP: #1591411 since zesty+ in dbus, but it's not the final fix that Simon proposed in the 95263 bug
<ubottu> Launchpad bug 1591411 in dbus (Ubuntu Xenial) "systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay" [Medium,Fix released] https://launchpad.net/bugs/1591411
<sil2100> I guess dbus has the workaround that Simon proposed a bit earlier in the discussion
<sil2100> i.e. we have this:
<sil2100> http://launchpadlibrarian.net/290293124/dbus_1.10.10-1ubuntu1_1.10.10-1ubuntu2.diff.gz
<sil2100> Do you think it's necessary to have the real fix, i.e. all the things mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=95263#c43
<ubottu> Freedesktop bug 95263 in core "unix fd in-flight counting broken" [Normal,Resolved: fixed]
<sil2100> ?
<TJ-> sil2100: hmmm, the follow-on dbus bug was only commited for 1.11.6 in July this year... https://bugs.freedesktop.org/show_bug.cgi?id=95619#c10
<ubottu> Freedesktop bug 95619 in core "_dbus_timeout_set_enabled doesn't reset timeout ticking" [Normal,Resolved: fixed]
<TJ-> sil2100: I'm not even sure if this is the cause of the issue as yet, but the fact we're seeing Transport endpoints missing and connection errors makes me think it is related to these at least.
<sil2100> TJ-: hmmm, maybe you could test that on a PPA-built dbus with all those fixes cherry-picked?
<sil2100> Sorry I can't be of much help, I didn't have this issue so I was only working on what people were reporting back to me
<TJ-> sil2100: I'll try to get the user to do that. After yesterday's marathon it'll be a few days before he's ready for that again. I'll talk to nacc too we can probably coordinate on it.
<sil2100> TJ-: ok, if you need any help in that just give me a sign
<TJ-> sil2100: same here, can't reproduce. this is the relevant dmesg, search for "Transport endpoint is not connected" to see where it seems to start the problems. http://paste.ubuntu.com/25804737
<TJ-> My problem is, how the heck does the root file-system get returned to read-only mode!?
<smoser> xnox: i'd really appreciate review of https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043
<smoser> if i dont get some, or a suggestion that there is another planned way to do this comming "really soon", then i think i'll just upload it.
<xnox> smoser, hm. I still want to review that =/ and i wanted to check how feasable it is to run systemd-networkd + netplan in the initramfs.
<xnox> smoser, plus some of your concerns are odd. For example, if there is netplan in the root filesystems, surely the current initramfs is specific to said root filesystem, and thus initramfs should have same networking configs, no?
<xnox> smoser, if initramfs is generic, the host is generic too, and not yet provisioned / configured, thus initramfs setup networking is fine for the target too.
<xnox> smoser, cause imho writting match any, dhcp in netplan and simply running netplan apply is better than ipconfig, dhclient, etc.....
<smoser> hm..
<smoser> "the initramfs is generic" is basically never able to be determined.
<smoser> and if someone gave kernel command line options, then they probably wanted those to be taken.
<smoser> xnox: i guess just please review that... you are welcome to review the implementation, but the description of what happens is in the commit message. i think its fairly complete.
<smoser> and you can see the rendered tests. they do not handle writing the
<smoser> 'match', (see line 113.. that is not excercised in test cases)
<fabbione> doko: thanks for taking care of https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1726711
<ubottu> Launchpad bug 1726711 in valgrind (Ubuntu) "valgrind reports invalid memory access on epoll_pwait call when invoked via epoll_wait" [Undecided,In progress]
<smoser> is bionic "open" ?
<smoser> can i upload?
<smoser> i'm sure nacc or rbasak know ^
<tumbleweed> launchpad doesn't even know about it yet https://launchpad.net/ubuntu/+series
<tumbleweed> and the topic tracks such things
<smoser> tumbleweed: gracias.
<TJ-> How should package A that 'knows' it'll break package B, and declares a "Breaks: B", handle removal of B during a do-release-upgrade ?
<tumbleweed> TJ- https://wiki.debian.org/PackageTransition
<nacc> smoser: per /topic, not open (and no ubuntu-anounce email yet)
<nacc> tumbleweed: there is a bb-series placeholder, which i believe will get renamed
<tumbleweed> yes, which means if you do an upload for bionic...
<TJ-> tumbleweed: 17.10 systemd declares "Breaks: laptop-mode-tools" but after a 17.04>17.10 d-r-u l.m.t remained. should that 'Breaks' be a "Conflicts" then?
<tumbleweed> Breaks should be fine, but that doesn't guarantee that systemd will win the fight
<tumbleweed> I presume it does for priority reasons, though? Not actually sure how safe that is
<nacc> TJ-: it's a versioend breaks
<nacc> TJ-: and the version in artful is new enough
<nacc> perhaps the version is wrong?
<bdmurray> If I want to report a bug about the desktop search feature in 17.10 is that gnome-shell too?
<TJ-> nacc: where do you see the version for the Breaks? I don't see it with apt-cache depends
<nacc> TJ-: apt show systemd
<nacc> TJ-: laptop-mode-tools (<< 1.68~
<nacc> added in systemd 229-6
<TJ-> nacc: that's a pain! apt-cache depends ought to show that!
<nacc> from debian bug #762018
<ubottu> Debian bug 762018 in systemd "systemd: v215 - rootfs left in read-only - not everytime" [Important,Fixed] http://bugs.debian.org/762018
<nacc> TJ-: --^ lol
<nacc> TJ-: that might be the same bug??
<TJ-> which is what we have with bug 1726930
<ubottu> bug 1726930 in systemd (Ubuntu) "System fails to start (boot) on battery due to read-only root file-system" [Undecided,New] https://launchpad.net/bugs/1726930
<nacc> TJ-: i wonder if l-m-t broke itself
<nacc> TJ-: would take some archaeology as to what was the 'fix' in 1.68 and wehther it's still there
<nacc> TJ-: I can do that in a bit
<TJ-> nacc: right. it looks like it re-broke doesn't it?
<TJ-> nacc: i've still not figured out how the rootfs returns to read-only mode even though systemd-remount returns success
<elbrus> Laney: can you confirm that https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=fe627aa was indeed only to catch NEW packages that FTBFS?
<mdeslaur> kees: TB?
<guest2239> any OP's in here?
<dax> (note for others: i just answered in another channel)
<powersj> nacc: Looks like `apt-cache showsrc src_package` and look for Section is one way of determining what component (universe vs main) a package is from?
<powersj> is there an easier/faster way to determine if something is in main vs universe vs multiverse?
<jbicha> a slower way is to use rmadison, you can also use a web browser https://people.canonical.com/~ubuntu-archive/madison.cgi
<xnox> powersj, seeded-in-ubuntu
<powersj> xnox, is it correct to say: if it returns any images a package is seeded in therefore it must be in main?
<xnox> powersj, no.
<xnox> powersj, ubuntu-desktop ubuntu-server and supported are in main.
<xnox> powersj, what is your actual quection? I find $ reverse-depends -r artful -c main -b src:foo -> what i use the most
<xnox> which tells me all the reverese depends of something, that are in main =)
<powersj> xnox: give a package or src package, is the package currently in main
<xnox> powersj, .... because, what?
<powersj> I think looking at the package-team-mapping at those 3 teams you point out and checking if the src package is present would be fastest in my case
<xnox> powersj, there is supported field on the package, for LTS, which is 5yrs for things in main.
<xnox> powersj, what do you actually care about, if it's in main or not? to check upload rights?
<xnox> there is ubuntu-upload-permission for that?
<xnox> there is ubuntu-upload-permission for that.
<xnox> powersj, what do you intend to do with the information that something is in main or not.
<xnox> powersj, also you usually need to include restricted too.
<bdmurray> sarnold: FYI I sorted out what was wrong and I'm gonna mark a bunch of failures for retracing
<sarnold> bdmurray: excellent, thanks!
<sarnold> bdmurray: that reminds me that some ofthe stacktraces I've seen in private bugs had far more memory contents in them than I've expected. I've deleted a handful of them before opening bugs up to the public, and that feels pretty new too
<bdmurray> sarnold: zip it
<bdmurray> sarnold: don't be bringing me more issues
<sarnold> bdmurray: hehe :)
<sarnold> bdmurray: https://bugs.launchpad.net/ubuntu/+source/dnscrypt-proxy/+bug/1703186/+activity
<ubottu> Launchpad bug 1703186 in dnscrypt-proxy (Ubuntu) "dnscrypt-proxy crashed with SIGSEGV" [Medium,Confirmed]
#ubuntu-devel 2017-10-25
<nacc> xnox: i'll sort it with powersj tmrw :)
<alkisg> Hi, software-properties-gtk offers this option: When there are security updates: *[Download and install immediately]/[Display immediately]
<alkisg> The default is causing issues in many installations here and for many reasons... For example, it's trying to access some Ubuntu repository via ipv6, and it hangs due to ISP or Ubuntu mirror issues, leaving apt locked even with the net problem gets resolved, with no visible indication at all, completely blocking the user from using apt, software centers etc.
<alkisg> I'd like to file a bug report to make a case in favour of switching the default to [Display immediately]. My question is, should I file this in Debian or in Ubuntu? (or it's a lost case anyway because it was already discussed somewhere?)
<infinity> alkisg: "I want to change the default because there's a bug" isn't a reason to change the default.
<infinity> alkisg: The correct answer here is to determine why it's hanging.
<alkisg> infinity, I did mention one possible cause
<alkisg> And the solution there is to fix the ISP and apt resuming after failures
<alkisg> We might be able to fix apt, but not the ISP
<infinity> alkisg: We can still fail gracefully if there's a network issue.
<infinity> The solution isn't "turn off everyone's updates becuase some people have crap networks".
<alkisg> Of course not. I'm only proposing going back to the default of 1 year ago
<infinity> The default changed for a reason.
<alkisg> Not to turn off updates, but to immediately prompt, as it was so far
<alkisg> Right, and I'm giving a reason for the opposite
<alkisg> That apt isn't ready for that
<alkisg> When the apt codebase matures enough, I would completely agree...
<infinity> Please file apt bugs for the behaviour you're seeing?
<infinity> The apt codebase is plenty mature.
<infinity> What you're seeing is called a "bug".
<alkisg> Another example. When I log in, I want to see the unattended upgrades progress
<alkisg> Whose bug is it that I can't see it? Apt or unattended upgrades?
<infinity> That sounds more like a feature request than a bug.
<infinity> I'm not even sure what you mean by "see its progress".
<alkisg> Apt downloading and installing security updates... I can't see or stop it
<infinity> Nope.  It's unattended.
<infinity> That's more or less the meaning of that adjective.
<alkisg> OK anyway I could make my case here (it's against unattended upgrades, not against apt), but I think it'll be best if I list all possible issues in a bug report,
<alkisg> would that be against debian, or against ubuntu?
<alkisg> Who is the policy maker there?
<infinity> Your request to be able to have some window into what's going on is an upstream feature request (and one likely to be denied, I'd expect, since that's entirely not the point of the package -- if you want to see and control your updates in progress, you don't want unattended-upgrades)
<infinity> The request to change the default option is an Ubuntu request, as it's a policy request, but I can flat out tell you that will be denied.
<infinity> The bug about apt (or perhaps a frontend) hanging on for dear life when the network sucks is an upstream bug, but you can file it in both places if you want.
<alkisg> I want to be able to use apt and not have it blocked with no visible indication in a default ubuntu install; I don't think I'm being unreasonable.
<infinity> "not have it blocked with no visible indication"?
<infinity> When you try to use apt while it's locked, it tells you pretty conclusively that it's locked.
<infinity> If that lock is being held by something that should have exited, that's a bug, yes.  Please file it.
<infinity> But there's no hidden "apt silently fails" behaviour here.
<alkisg> Suppose I have a laptop. And on some particular boot I'm using some form of connection that costs per GB. Shouldn't I be able to pause the unattended updates at that point?
<alkisg> (Btw, is there a "proper" way to stop unattended upgrades when apt fails and hangs forever? I'm using pkill currently, as apt-daily stop doesn't stop it)
<infinity> By disabling the automatic update option?  Yes.
<infinity> Giving users a kill button to murder apt mid-upgrade is asking them to shoot themselves in the foot, hard.
<infinity> Friendly interfaces don't tend to encourage users to break things.
<alkisg> An example that there are at least some persons sharing my opinion, is windows implementation of unattended updates, which does give an icon and one such option to block/postpone them
<infinity> Windows doesn't let you stop an update halfway through, which is what you asked for.
<alkisg> HCI is a big topic, and there are multiple views on interface design...
<infinity> It lets you postpone installation, which isn't the same as postponing the download, so doesn't much relate to your connnection scenario.
<alkisg> I see the icon, I click it, it brings up the options, it shows a bar "downloading", and I can stop it
<alkisg> If unattended-upgrades was able to do that, I wouldn't have any usage issues
<infinity> Ahh, maybe mine downloads too quickly to ever see that bit. :P
<alkisg> :D
<infinity> Yes, it's plausible one could write a nice little UI widget for the downloading part of unattended-upgrades.  Pretty big feature request, as it currently has no GUI bits at all, but doable.
<infinity> But it very much needs to be sure it's only interrupting the download, as interrupting the next part of an apt run is disastrous.
<alkisg> I fully agree that the "pause/stop/postpone" button should only be enabled when apt downloads and not when apt installs
<alkisg> And it's apt downloading that is causing most of the issues
<alkisg> Not apt installing...
<infinity> Sure.  Like I said, big feature request, but feel free to file it.
<alkisg> And some form of `service unattended-upgrades stop` that would stop when apt downloads
<alkisg> And not when it installs
<infinity> Might be able to tie it into something that already has GUI bits, like update-notifier.
<alkisg> So that I would be able to use it in server installs too
<infinity> You'll probably find less sympathy about the issue for servers.
<infinity> It's not a "common" use-case for servers to randomly swap between metered and unmetered connections.
<infinity> But, YMMV, I won't stop you from filing wishlist bugs.
<alkisg> E.g. I boot a server, try to run `apt dist-upgrade` and leave, but I have to wait for 10 minutes for unattended-upgrades to run before I can run my own apt command
<infinity> More importantly though, you should lay some blame and file some bugs about the hung processes.  That's much more important.
<alkisg> infinity, thanks for all the input, so I should be filing ubuntu bugs, not debian bugs, right?
<infinity> alkisg: File Debian bugs for code issues, Ubuntu bugs for policy issues, if you want to make sure the right people are seeing them.
<infinity> alkisg: "apt hangs when the network sucks" isn't a policy issue.
<alkisg> Gotcha. Thanks again. :)
<estan> tyhicks: hi there, did ext4 encryption with fscrypt make it in time for 17.10, or will it have to wait for 18.04?
<estan> tyhicks: asking because it was brought up on this (false) kernel bug where i participated (https://bugzilla.kernel.org/show_bug.cgi?id=197045) where ted tso suggested i "stop using ecryptfs, switch to ext4 encryption" :)
<ubottu> bugzilla.kernel.org bug 197045 in ext4 "renameat2 rename_noreplace" [Normal,Resolved: invalid]
<doko> fabbione: please could you do the SRU verification for the valgrind upload?
<fabbione> doko: i am totally lost on those new processes, how do I do that?
<doko> fabbione: read the instructions ;p
<fabbione> doko: i'll try. those machines are hooked up on a CI pipeline. it's a pain to do manual stuff
<fabbione> doko: not today tho.
<doko> fabbione: ok, just test the uploaded binaries
<fabbione> doko: ok, testing now. this meeting is too boring anyway
<fabbione> doko: tested, but i don't know the Lp mumbojumbo paperwork to validate the SRU. that you can do :P
<andrewsh> hi everyone
<andrewsh> who's responsible for patches.ubuntu.com?
<andrewsh> at least one packages there diffs against a wrong Debian package version (not currently part of any release)
<andrewsh> and I guess that also is the reason ubuntudiff.debian.net and deriv.debian.net do the same thing
<fabbione> doko: tested also on i386. it's all good Sir of the toolchains
<infinity> andrewsh: Examples are more helpful than abstract statements.
<infinity> andrewsh: But you might also be misunderstanding what patches.ubuntu.com is meant to represent.  It's not showing the Ubuntu delta to "current Debian", as that can often be enormous, depending on upstream version skew, it's showing the delta to the base version that package was forked from.
<infinity> andrewsh: Which may, indeed, be a version no longer published anywhere except snapshot.debian.net.
<infinity> andrewsh: Because that 3-line delta is far more interesting than wading through 3MB of goop.
<andrewsh> infinity: wpa
<andrewsh> https://patches.ubuntu.com/w/wpa/
<andrewsh> the patch here is from some random version not even in oldstable
<andrewsh> and its not useful at all, precisely because of "3MB of goop" in it
<andrewsh> not a couple of lines of diff
<andrewsh> is it possible to retarget it to 2:2.4-something Debian ships?
<infinity> andrewsh: That would be because Ubuntu doesn't have an epoch and Debian does.
<andrewsh> I mean, the best thing would be to ask Marc to rebase Ubuntu version to the Debian one
<andrewsh> but it would be very helpful if the diff was useful
<infinity> mdeslaur: ^
<infinity> mdeslaur: Any plans to adopt the Debian epoch in a future wpa merge?
<mdeslaur> andrewsh, infinity: sure, next merge will have it
<infinity> andrewsh: Short answer though, is no, it's not trivial to make a computer guess what was obvious to a human there.
<andrewsh> so there isn't a way to override the automatic guess, is that correct?
<infinity> Nope, but mdeslaur rebasing with the epoch will solve this particular issue.
<infinity> Arguably, we shouldn't have tried to produce a delta at all, since I can't fathom how it even decided to pick something as a common base when there wasn't one.
<infinity> So, I'm down with saying that it's a bug that there was a patch. :)
<infinity> Producing a better patch runs into deminishing returns of teaching a very generic system to be specifically clever in the face of oddball things that rarely happen.
<andrewsh> I think even a diff against the latest package for the same upstream version would be better than no diff at all
<doko> tsimonq2: again a new debhelper in unstable
<tyhicks> estan: hi - the kernel bits have been in place for a while but the userspace project didn't make it into 17.10
<infinity> tsimonq2: If you have a debhelper merge already prepped, please point me to it, but don't ask anyone to sponsor it for you, I need to do dpkg and debhelper in the same publisher cycle (or in a bootstrap archive) to avoid the dep/breaks loop.
<infinity> tsimonq2: (And I need to sleep before that happens)
<LocutusOfBorg> infinity, I can upload them
<LocutusOfBorg> oops, just wait for tsimonq2, I don't know where doko has dpkg
<LocutusOfBorg> we can do a silo upload
<estan> tyhicks: alright. do you think they will for 18.04?
<tyhicks> estan: the userspace package will certainly be in the archive - I'm not sure if it'll be officially supported the way that eCryptfs has been in the past
<tyhicks> estan: rolling out a new way to do user data encryption just before the LTS is risky
<nacc> slangasek: i know you're quite busy, so consider this asynchronous and not urgent resolve immediately. We ship debsign and gpg2 in the git-ubuntu snap so that we can sign uploads after building them (if --sign is passed). However, since we are shipping gpg2 and the host might be xenial with gpg1, there is a mismatch of configs (and gpg2 needs a gpg-agent running from gpg2) and we really don't want to
<nacc> modify anything in the user's ~/.gnupg if we can avoid it. What do you recommend we do? I'm trying to consider the various combos, xenial host, artful host, etc. Should we be installing and invoking gpg1 ? Will that work with a gpg2 as gpg setup like in artful?
<estan> tyhicks: yes, understandable. thanks for the info.
<tsimonq2> doko, infinity: ack, but I won't have access to my merge for the next 5 hours... if you don't want to wait, feel free to steal, but I would like to steal back next time ;)
<tsimonq2> I didn't set myself away by accident, and I can't scroll on mobile, so I will grep for other pings later
<powersj> bdmurray: re: https://code.launchpad.net/~james-page/merge-o-matic/ubuntu-opnestack/+merge/332297 looks merged, does it also need to be deployed somehow?
<bdmurray> powersj: I'm pretty sure I did that bit too
<powersj> not seeing anything at https://merges.ubuntu.com/ for openstack
<bdmurray> I see it on the server, digging
<bdmurray> powersj: sorted it was a missing symlink
<powersj> bdmurray: thanks! for future reference should that have been in the merge proposal?
<bdmurray> powersj: No that folder doesn't exist in the code.
<powersj> ok :)
<powersj> thanks again
<elbrus> Laney: did you see my question from yesterday?
<geofft> hi, can I get sponsorship for #1725110, an SRU request for syncing with Debian testing?
<geofft> LP #1725110
<ubottu> Launchpad bug 1725110 in config-package-dev (Ubuntu Artful) "config-package-dev 5.2 broke transforms" [Undecided,Confirmed] https://launchpad.net/bugs/1725110
<geofft> (or for backporting the patch, but if you sync with Debian testing, you get the patch, autopkgtests, and no other functional changes)
<gaughen> rbasak, arges I see you both are on the SRU team rotation for today, and there's an item roaksoax would like to be pushed to -proposed - https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1711760 (https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=resolvconf). Would either of you handle this request?
<ubottu> Launchpad bug 1711760 in resolvconf (Ubuntu Xenial) "[2.3] resolv.conf is not set (during commissioning or testing)" [Medium,Confirmed]
<Laney> elbrus: don't think so?
<Laney> elbrus: wait, something about a britney commit - did I forget to reply?
<elbrus> Laney: I didn't notice a reply, yes, about britney
<elbrus> question was: Laney: can you confirm that https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/commit/?id=fe627aa was indeed only to catch NEW packages that FTBFS?
<Laney> elbrus: IIRC it's for packages that aren't in testing
<elbrus> Laney: thanks, that means I have to check the code (if I am doing the right thing)
<Laney> I think it was something like an FTBFSed package with no binaries anywhere that was getting tests triggered
<elbrus> in https://github.com/Debian/britney2/tree/autopkgtest
<Laney> which doesn't usually work out so well
 * elbrus is preparing Debian to also do autopkgtest processing in britney
<Laney> ya, happy to see this work progressing, cool stuff!
<elbrus> just a heads up, I would love to have the Debian britney be more in sync with Ubuntu
<slangasek> nacc: I'm going to refer that question to xnox, who has more context on the state of play with gnupg compatibility across releases.  Especially where private keys are concerned, there are differences in the .gnupg directory layout between old and new, so you definitely need to be careful here
<elbrus> but I am no release manager...
<elbrus> so I try to keep things working for the Ubuntu setup while implementing it to the desires of the Debian RT
<elbrus> hope you appreciate that as well
<elbrus> otherwise I can drop some logic
<elbrus> Laney: by the way, all comments on my code in that branch are welcome
<nacc> slangasek: thank you
<nacc> xnox: let me know if you need more context
<nacc> slangasek: and completely agree re: private keys, that's what I'm trying to determine. It does look like once you do the upgrade and if gpg2 does any modifications to the private keys, they are not visible to gpg1. However, we don't actually expose gpg2 to the user as an application (although as classic, then can snap run --shell and then find the binary in the snap and run it if they chose to).
<slangasek> nacc: so, copying ~/.gnupg into private space, setting GNUPGHOME to point to the copy, and discarding it, on each relevant invocation of git ubuntu, would be possible
<slangasek> nacc: is this used for signing tags?
<slangasek> ah, no, for signing builds
<slangasek> so
<nacc> slangasek: yeah that's a good idea
<slangasek> why would I want git ubuntu to do my build?
<nacc> slangasek: right, just siging the builds
<nacc> *signing the builds
<nacc> slangasek: because we can get the orig tarballs from pristine-tar for you (or from LP)
<nacc> slangasek: and we can use a LXD cotainer to do the build in
<nacc> slangasek: it's just a wrapper for someone who doesn't want to setup sbuild
<slangasek> ok, the first bit is interesting to me, the second is less interesting
<Unit193> origtargz can get be the tarball. :3
<slangasek> could we not just invoke the system gpg?
<slangasek> instead of bundling
<nacc> slangasek: hrm, maybe i can do that with the debsign -p argument
<slangasek> nacc: well, or even just invoking the system debsign :)
<nacc> slangasek: right, but our goal is to not require the user to install deps
<slangasek> shrug
<nacc> slangasek: in that, they shouldn't really need to :)
<nacc> slangasek: yeah, i understand not your concern :)
<nacc> or i wish it was easier for my snap to depend on debs
<slangasek> I don't think it's a goal that people run git-ubuntu in an environment they haven't already configured for Ubuntu development
<nacc> slangasek: not for experienced developers, no. But for a drive-by contributor, per rbasak, I think it is
<jbicha> nacc: I think the other way around is more important: having debs depends on snaps
<slangasek> DEBEMAIL, DEBFULLNAME, etc.; there's setup involved
<slangasek> and I disagree that git-ubuntu should try to bite all of this off in one go before we even have adoption of the tool
<nacc> slangasek: and no one has to use `git ubuntu build`
<nacc> Unit193: didn't know about that command, thanks!
<slangasek> right, but re-synthesizing the tarballs from git without requiring a separate download is one of the killer features for me, so I *do* want that; I just also want it to integrate with my underlying dev environment instead of bundling
<slangasek> (bundling incompatibly, that is)
 * tsimonq2 disagrees that development tools should hard depend on snaps, I don't have snapd installed on my system and I don't think I ever will unless forced
<Unit193> nacc: It's a very nice version of "just get me the tar!"
<nacc> slangasek: yes, that will be exposed as `git ubuntu export-orig`, i thinkn
<nacc> slangasek: which parallels gbp
<nacc> slangasek: as i agree, that on its own is very useful :)
<nacc> slangasek: so you could just use clone, export-orig and do whatever you do now basically (I think)
<slangasek> so if you don't have debsign on the system, you don't have devscripts installed.  If you don't have devscripts installed, you don't have dch.
<slangasek> QED git-ubuntu w/o devscripts is not useful
<nacc> slangasek: right, which is why we have devscripts in the snap
<nacc> slangasek: but i see what you are saying
<slangasek> oh dear God no
<nacc> there is *no* dependency system currently
<nacc> slangasek: we don't expose any of devscripts to the user
<nacc> (as binaries)
<Unit193> This is sounding more and more like a "docker to fasttrack dev env setup", which I didn't think snap was made for.
<nacc> slangasek: if you would really like me to pare back to only shipping tooling that will just mostly not work in the general case, I can do that :) but I'd like that to be discussed with rbasak
<nacc> jbicha: you might be right, but that wouldn't solve my issues
<Unit193> nacc: You made slangasek fall over.
<nacc> Unit193: :)
<Unit193> As far as packages that depend on snaps, that seems very unideal.
<nacc> ragequit, maybe? :)
<jbicha> nacc: like it might be nice if Firefox would be a snap, I think we've wanted that for a while, but how do you upgrade users to it?
<nacc> jbicha: oh i know
<tsimonq2> Please oh please can we package it as a deb already?
<tsimonq2> (git ubuntu)
<nacc> tsimonq2: it's not easy
<nacc> tsimonq2: because of versioned dependencies
<nacc> tsimonq2: we don't want the build to be different on xenial and artful when building for xenial, e.g.
<nacc> (or the import, more importantly)
<tsimonq2> nacc: Why are the dependencies versioned?
<nacc> tsimonq2: i mean we need specific versions
<nacc> tsimonq2: because bugs exist.
<tsimonq2> Oh
<tsimonq2> nacc: Where's the code? :P
<nacc> https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master
<nacc> tsimonq2: --^
<nacc> tsimonq2: probably the biggest one is gbp
<nacc> tsimonq2: we have talked about doing a bunch of backports
<nacc> tsimonq2: but it's not a priority right now
<tsimonq2> nacc: Is code doing those backports and then prototype deb packaging welcome?
<nacc> tsimonq2: yep
<nacc> tsimonq2: and we'll hopefully have some tests from rbasak that can be dep8'd
<nacc> we do have some unit tests already, in the code
<nacc> and a very simple integration test (taht's slow) that tries to clone something, build it, and reimport it (without pushing it)
<tsimonq2> Excellent.
<tsimonq2> nacc: I just think it's *extremely* ironic that in order to use this set of tooling meant to develop *debs* you need to install a *snap*...
<tsimonq2> Maybe that's just me though.
<nacc> tsimonq2: i think it was the fastest way for us to get from A to B on every distro at the same time
<Unit193> No.
<tsimonq2> nacc: Except just like every other development tool we use (I think), am I wrong to expect people to use either Debian, Ubuntu, or a derivative?
<tsimonq2> nacc: I don't personally care if there's a snap, what's killing me is that there's no deb.
<nacc> tsimonq2: dunno, you don't have to with the way the snap is written :)
<nacc> tsimonq2: right, but having both means twice as much maintenance burden
<nacc> currenntly owned by me, basically :)
<nacc> tsimonq2: the other thing that will be hard with the deb is python compatibility
<nacc> for older releases
<tsimonq2> nacc: But I thought the maintenance burden with snaps was "supposed to be" less?
<nacc> tsimonq2: right it's low for the snap
<tsimonq2> nacc: Oh, I'm not worried about that.
<nacc> tsimonq2: but if you add a deb, then i'm presumably going to own that too
<nacc> tsimonq2: in 3 releases
<nacc> (and it's presumably going to need to be in main)
<nacc> tsimonq2: the snap lets me move a lot of faster than debs ever could
<tsimonq2> nacc: Why would it need to be in main? :)
<nacc> tsimonq2: i'm not trying to wage political war on the topic, i have hated getting the snap to work, tbh. But now that it does, it's really useful to have.
<nacc> tsimonq2: presumably it'd be a 'supported' thing if it ever becomse the primary development tool
<nacc> tsimonq2: perhaps not, I don't know
<tsimonq2> nacc: And my thing is that I don't like snaps. I don't want snapd installed because I have major performance concerns about it. If git ubuntu ever becomes the primary development tool, it should be available in the packaging format we're trying to build it on...
<tsimonq2> nacc: Yes there's fast turnaround time, but that could also be because nobody invested the time to make deb building automatic as well.
<tsimonq2> (for this particular case)
<nacc> tsimonq2: building the deb doesn't change at least 7 day turnnaround time
<nacc> tsimonq2: ulness you mean a PPA
<nacc> tsimonq2: i think i disagree with you because git-ubuntu is meta to the packaging format it generates
<nacc> tsimonq2: so it doesn't matter that it's not a deb, that's a philosophical thing to get over (or not)
<TJ-> wouldn't an LXC/LXD build bundle (of standard .deb packages) for the fixed-version build tooling be a better way to integrate with regular dev workflow?
<nacc> TJ-: that's essentially what the snap is
<nacc> TJ-: except we don't expose the individual commands
<nacc> levelset: I'm not trying to solve or replace everyone's tools
<tsimonq2> nacc: I get that it might be an extra turnaround time (that I'm willing to invest, by the way, I'm not giving *you* things to do) but you'll probably get a more *interested* audience. If you want to develop deb packages, you're likely running either Ubuntu or Debian.
<nacc> my theory is that experienced developers need nothing more than `git ubuntu {clone, export-orig, push}` where the latter two don't yet exist
<nacc> drive-by developers want `git ubuntu {clone, build, build-source, submit}` and git-cherry-pick so they can just get a upstream change, let us convert it to a quilt patch and get it to a developer than can sponsor it
<nacc> there are two very distinct audiences
<tsimonq2> And? In order to build it to verify it works, you need pbuilder or sbuild. Having that in a snap doesn't really sound feasible...
<nacc> tsimonq2: no, you don't.
<tsimonq2> nacc: Or something like that.
<nacc> tsimonq2: we use the host's lxd to spawn a container and do the build there. We don't ship lxd (it's our only external dependency)
<tsimonq2> nacc: But (correct me if I'm wrong) LXD isn't the most efficient way to do that.
<nacc> tsimonq2: it's pretty fast, tbh
<nacc> tsimonq2: i don't know about 'most efficient' or not, but I also don't care about that (yet)
<tsimonq2> nacc: Regardless, my point is that it should be a deb, we could talk about builders all day long :)
<tsimonq2> nacc: I'm willing to put that work in if it will be accepted.
<nacc> tsimonq2: I think we just disagree about "should" :)
<nacc> tsimonq2: yep, I would take it
<nacc> tsimonq2: as long as the deb's results always match the snaps
<nacc> snap's
<nacc> if there is a chance of a deb's import being different, it can't go in the archive
<nacc> that's relatively important
<tsimonq2> nacc: Which, with proper testing (both manual and automated), should be trivial, as long as the initial work is done.
<nacc> tsimonq2: *with* backports enabled, possibly
<nacc> tsimonq2: which the archive does't, afaik
<tsimonq2> nacc: Possibly, or the tools could just adapt given which tools are available to it.
<nacc> tsimonq2: adapt how? we assert hash stability, idempotency and reproducibility
<nacc> tsimonq2: if the deb won't do that, i really can't encourage its use
<tsimonq2> nacc: I'll have to look more into the code, but are the features that you are using from underlying tools brand new?
<nacc> tsimonq2: the gbp ones are relatively new (component tarball support, we don't yet use export-orig, but we might rather than spinning our own)
<nacc> tsimonq2: i'd need to check on the others for you
<nacc> tsimonq2: the other point about all of this is, if you aren't going to use git-ubuntu for whatever reason, you can just use git
<nacc> tsimonq2: and do your normal stuff and dput like usual
<tsimonq2> nacc: True. I'll have to think on it more and look into the tooling, but I'm thinking this might be possible.
<nacc> tsimonq2: cool
<tsimonq2> nacc: Also, think about it, are people more likely to Just Use Git or install snapd then snap install git-ubuntu-or-something and THEN use the tools they've never used before and learn new syntax?
<nacc> tsimonq2: snapd is installed by default
<nacc> iirc
<Unit193> Since I can't dput, I could adapt the bzr workflow for merge proposals (even how nasty it was.  Do changes, clone the bzr repo, rsync -avhP --delete-after --exclude *.bzr ./package-2.4.1/ ./package/  debcommit and push)  I personally like gbp+dput, though.
<tsimonq2> nacc: Not on all flavors. ;)
<Unit193> tsimonq2: Installed by default, yes.  Only Lubuntu doesn't, but that's because recommends are off and that tends to break stuff anywayâ¢
<nacc> tsimonq2: :)
<nacc> tsimonq2: there are significant gotchas to using git directly, btw
<jbicha> reverse-depends -r artful snapd
<jbicha> Unit193: all desktop flavors do include snapd
<nacc> jbicha: thanks, I hadn't looked at that yet
<Unit193> jbicha: You're pinging the wrong one. :)
<nacc> tsimonq2: I think, to be completely honest, a drive-by contributor will do what they are told
<nacc> tsimonq2: right now, they're told to use bzr (or that may be fixed now)
<nacc> tsimonq2: also, use the tool and see what you think first. Maybe you'll like it, maybe you'll hate it, I don't know. We have reasonable reasons, IMO, for doing things the way we have, and I'm responsive on bugs when they get filed. I'm not sure we can replace (and like I said, we don't really intend to) every workflow. But we don't want to break anyone's.
<jbicha> nacc: depending on lxd is interesting since Debian still doesn't have lxd :(
<nacc> jbicha: it's not a hard dependency
<nacc> jbicha: in that it's flag-controlled
<nacc> jbicha: also, lxd is a snap :)
<Unit193> Can't it use lxc?
<tsimonq2> nacc: I personally fixed the packaging guide to *not* use Bazaar.
<nacc> tsimonq2: yeah, that's what I was recalling :)
<nacc> tsimonq2: but think about how lonng that sat there
<nacc> Unit193: not currently
<tsimonq2> nacc: Well now it's better. :P
<nacc> Unit193: i suppose it could be taught, what we need in the lxc/lxd is not much
<nacc> Unit193: i just personally never use lxc, and lxd is readily at hand
<nacc> Unit193: would just need some code in gitubuntu/build.py
<Unit193> nacc: It's the reverse for me. :>
<nacc> Unit193: :)
<nacc> Unit193: feel free to file a bug, i think i can get that integrated without too much effort
<nacc> Unit193: we basically are assumign you already have lxd setup on the host (we use the host binary), same would hold true for lxc
<jbicha> nacc: why don't you use the lxd snap?
<nacc> jbicha: it wasn't available when i started adding lxd support
<nacc> jbicha: i think the plann is to migrate to lxd and its interface, yeah
<nacc> jbicha: but also, i was trying to avoid forcing current lxd-as-deb users to migrate to the lxd-as-snap (although perhaps they can both be isntalled at the same time? not sure)
<sarnold> I expect that would be insanely confusing
<tsimonq2> But again, I think so far out of everything I've tried, sbuild with /dev/shm is the fastest :)
<tsimonq2> I personally recommend that to anyone that I'm mentoring and they use it with little to no problems.
<nacc> sarnold: :)
<nacc> Unit193: as to your earlier point about docker-esque. Sort of accurate. As a snap, albeit classic, I did't want to have to wrap every call to every thing not in my code base with try/except with a useful error message and didn't want to pull every dep into our source. So our snap image is large and carries tools that most developers already have installed. As I said, we don't expose those as
<nacc> applications in the snap, although they are exeuctable if you knonw the voodoo
<nacc> tsimonq2: right, and I'm not standing in the way of you recommending that, or doing that yourself
<nacc> tsimonq2: if you want, i'll put a blurb in the code / manpage saying "tsimonq2 says this is shite performance, don't use it if you care about that" :)
<tsimonq2> nacc: Go ahead XD
<Unit193> Everyone likes their own methods, just like I use pbuilder with eatmydata.
<nacc> Unit193: agreed
<Unit193> \o/
<nacc> each subcommand is fairly independent of the other. So you can use just clone if you want, and do all your work with git and other tools (you might need to adjust the pristine-tar branches if you use that, but in general you're not going to be pushinng the pristine-tar data)
<xnox> slangasek, nacc - if current .gnupg is keyring based (gpg1) either gpg1 or gpg2 can manipulate it; if gpg2 is used on the kerying based .gnupg directory, it is converted to keybox format (gpg2) and gpg2 will from then on ignore the keyring based keys that are still left in the .gnupg folder.
<xnox> sladen, nacc - it is quite wrong for git-ubuntu to ship either gpg1 or gpg2, and it is wrong for it to touch .gnupg dir outside of the snap directly, because you don't know what's there, and you might not even be able to use any keys from there because one is using GPG keys on a smartcard / yubikey (quite common, given that yubikeys were given out for free at one of the last UDS)
<xnox> unping sladen
<nacc> xnox: ok, so it's best for me to just invoke the host gpg, got it
<nacc> (and by me, i mean debsign)
<nacc> xnox: thank you
<xnox> nacc, by default, ubuntu desktop runs gpg agent (default is gnome-keyring, but can be kwallet, gpg-agent, etc) and you simply should be talking to the agent / invoking host gpg yeah.
<tumbleweed> xnox: the yubikeys that were given out where HOTP-only (not gpg capable). But yes, sensible people use smart cards :)
<xnox> nacc, ideally yeah, debsign from the host.
<xnox> tumbleweed, darn, i thought it was version 4 later. maybe it was just a canonical only sprint post-uds.
<tumbleweed> probably
<nacc> xnox: right
<xnox> i've been having key material on smartcards (yubikey) after Laney exported my private key to stdout at one of the sprints....
<tumbleweed> :P
<sarnold> what a pal :)
<tsimonq2> heh
<mwhudson> hah
<jbicha> juliank: can you add bionic to python-apt? thanks
<juliank> Oh, yeah
<juliank> But afterwards we should really get rid of this stuff
<juliank> :D
<juliank> It's just copy and sed these days
<jbicha> use distro-info-data ?
<juliank> Well, we should probably move the additional data there
<juliank> And Cdrom should be CD-ROM I guess
 * tsimonq2 subtley pokes infinity to update the vim syntax highlighting for vim
<tsimonq2> Wow, that's redundant, I mean Bionic. :P
<jbicha> it's more of a metaphorical Cdrom anyway I guess!
<juliank> jbicha: uploaded
<jbicha> ð
<nacc> tsimonq2: oh also, we're goign to be relying on git-worktree being present, which, at least, isn't there on trusty
<tsimonq2> nacc: I don't personally care about trusty :)
<nacc> tsimonq2: just was an fyi, there is probably a dependency on git and git fixes that I'm not explicitly testing for
<tsimonq2> nacc: Ok
<dax> damnit, almost got there first
<Unit193> Could likelu punt ubuntucraze, dax.
<dax> (dear developer folks: someone with too much free time is currently mad at freenode. there may be some turbulance in IRC-land for a bit)
<sarnold> $~a ?
<tsimonq2> Unit193, dax: #ubuntu-desktop
<tsimonq2> Thanks.
<xnox> Unit193, thank you
<xnox> my push notifications to phone just went nuts =(
<Unit193> sarnold: Not identified.
<sarnold> Unit193: aha :) thanks <3
<Unit193> Sure thing!
<xnox> Unit193, #ubuntu-kernel
<tsimonq2> Jeez.
<xnox> but not #upstart, because nobody cares.....
 * xnox :`(
<TJ-> can we preemptively protect #ubuntu-discuss, if it hasn't been already?
<xnox> Unit193, #canonical-sysadmin
<tsimonq2> Beat me to it
<hloeung> dax: can you help with #canonical-sysadmin as well?
<Unit193> xnox: Not employed by them, can't do jack.
<xnox> honestly i thought the days of mIRC scripting and autokickbanning is the thing of a past
<xnox> Unit193, ack, thanks about the rest.
<xnox> Unit193, alerted a vanguard, maybe they can do it.
 * xnox left that channel for now.
<tsimonq2> xnox: All done.
<Unit193> xnox: ...You don't think the pinging might have done it?
<xnox> lol =)
#ubuntu-devel 2017-10-26
<bigon> what's the position regarding upstart service files? should they be dropped, I'm looking at rpcbind ATM in debian and the thing is still shipping upstart services
<bigon> rpcbind is a bit special as it needs to start early in the boot process, so I'm not 100% sure
<doko> xnox: https://launchpadlibrarian.net/343004345/buildlog_ubuntu-bionic-s390x.boost1.65.1_1.65.1+dfsg-0ubuntu1_BUILDING.txt.gz
<xnox> doko, yes.... how come i see no buildlogs myself anywhere?!
<xnox> ok now i do. never mind
<seb128> hum
<seb128> "[proposed-migration] gnome-session 3.26.1-0ubuntu6 stuck in bionic-proposed for 7 days."
<seb128> bionic isn't open for that long is it?
<doko> xnox: because you included .1 in the source name? ;p
<doko> seb128: just starting with new icu & boost
<xnox> doko, yes
<doko> feel free to add other transitions if you would like to
<seb128> doko, so that email is buggy ... who is looking after that service?
<doko> seb128: which email?
<seb128> doko, see the line just before my question
<seb128> the "<package> is stuck in bionic-proposed"
<sil2100> seb128: it was designed by robru, but since it's part of britney I'd say it's on Laney's plate now?
<Laney> no
<Laney> nice try :P
<sil2100> ;)
<Laney> I'd say file a bug on https://bugs.launchpad.net/britney/
 * sil2100 needs to figure out why bileto's autopkgtests are busted
<sil2100> Todayish
<seb128> Laney, thanks
<seb128> sil2100, so conclusion is that the issue is yours right? ;-)
<sil2100> nononono
<seb128> shrug, same email received again half an hour later
<infinity> seb128: It's not a bug in the britney bits, it's a bug in how I migrate things when I open a release.  Well, "bug".
<infinity> seb128: It was N days old because that's when it was uploaded to artful, and I seed bionic's britney history with artful's.
<seb128> k
<seb128> well it's minor
<seb128> just going to spam whoever did SRU uploads?
<infinity> There weren't that many copies forward, thankfully.  But yes, I suppose so. :/
<doko> LocutusOfBorg: please could you merge erlang and then have a look at couchdb?
<smoser> xnox: i like the arm64 name too. i'm *never* messed up and downloaded the wrong thing due to its likeness to amd64.
<jbicha> bigon: yes, upstart stuff should be removed https://lintian.debian.org/tags/package-installs-deprecated-upstart-configuration.html
<cjwatson> FYI, I'm going to be re-enabling the redhat-bugs LP bug tracker soon, so a whole bunch of bugs are going to get comment and status syncs from bugzilla.redhat.com
<cjwatson> seb128: ^- seems like the sort of thing you might notice and otherwise wonder about :-)
<seb128> cjwatson, ack, thanks
<cjwatson> it's been disabled for ~6y, so there's quite the backlog
<xnox> smoser, ha ha ha ha =) been there, done that.
<xnox> smoser, not sure that the AArch64 tag would be any better
<xnox> jbicha, but should be done with .maintscripts rm-conffile helper such that these jobs are removed on upgrade =)
<bigon> jbicha: and the "if init_is_upstart; then" as well I guess
<doko> Source and binary movements to main
<doko>  -----------------------------------
<doko>  o mathjax: fonts-mathjax libjs-mathjax
<doko>    [Reverse-Depends: libboost1.65-doc (MAIN), libjs-mathjax]
<doko> xnox: ^^^
<coreycb> bdmurray: hello, can you reject horizon 3:11.0.3-0ubuntu3.1 from the zesty upload queue please? there's another fix required to go with that.
<bdmurray> seb128: I agree about the increase in crash rate detection being bad for 0 day SRUs and I'll override those today
<seb128> bdmurray, hey, thanks
<nacc> slashd: i think i disagree with your definition of microrelease in LP: #1719671
<ubottu> Launchpad bug 1719671 in ubuntu-advantage-tools (Ubuntu Zesty) "[SRU] Microrelease : include recent version containing fips and livepatch" [Medium,In progress] https://launchpad.net/bugs/1719671
<slashd> nacc, ok can you explain why ?
<jbicha> bdmurray: could you consider releasing mutter & gnome-shell SRUs to artful today (7th day is tomorrow) since I'd like to upload another mutter SRU after
<bdmurray> jbicha: Are they fixing important bugs?
<jbicha> yes LP: #1725153 is important
<ubottu> Launchpad bug 1725153 in mutter (Ubuntu Artful) "Reintroduce headless mode in GNOME Shell" [Undecided,Fix committed] https://launchpad.net/bugs/1725153
<nacc> slashd: a microrelease doesn't introduce new features, it just fixes bugs (IMO)
<nacc> slashd: i consider the u-a-t update to be a major release update
<slashd> nacc, right so it'll fit more in the [
<slashd> 2.2. Other safe cases]
<nacc> slashd: yeah that's possibly true
<slashd> ... For Long Term Support releases we sometimes want to introduce new features ...
<nacc> slashd: tbh, i do't thikn we need any more justification for the SRU :)
<slashd> nacc, ok thanks for your 2 cents
<slashd> nacc, maybe I thinking too much for justifying it ;)
<nacc> slashd: yeah :)
<nacc> slashd: i plan on sponsoring it, i just haven't done it yet
<slashd> nacc, oh ok, I just been asked to do it an hour ago
<nacc> slashd: ah ok :)
<slashd> nacc, is it okay if I remove this from your plate ?
<slashd> nacc, i didn't know until now that it was officially on your todo list
<nacc> slashd: that'd be great :)
<nacc> slashd: if you have the cycles, please do :)
<slashd> nacc, I do have some cycle atm, ok thanks
<nacc> slashd: thanks!
<doko> jamespage: from the (ftbfs) ceph build in bionic ... -msse -msse2 -msse3 -mssse3 -mpclmul -msse4.1 -msse4.2
<dmj_s76> sforshee: So it appears that an alpha_support flag is preventing coffee lake intel graphics from working properly.
<dmj_s76> Still more testing to do to make sure the kernels in Artful and Xenial actually do work well with coffee lake, but it would be good to get treat coffee lake graphics as supported in Ubuntu.
<dmj_s76> https://cgit.freedesktop.org/drm-intel/commit/?id=eb371933cf4d3495d0899880b2e0e252ce9db517
<sforshee> dmj_s76: all that commit seems to do is make it not warn for coffelake, doesn't seem like that's going to help much
<sforshee> dmj_s76: as for the alpha_support flag, it looks like the kconfig option only affects the default value of the module parameter, so you should be able to test at least artful by just passing i915.alpha_support=1
<dmj_s76> sforshee: yes, we're running through testing with that parameter on artful right now.  It seems useful to change the default value since hardware is coming out already.
<dmj_s76> oh...I think that might not be the commit actually...
<dmj_s76> sforshee: https://cgit.freedesktop.org/drm-intel/commit/?id=e6b20bf1b77c24465393b5b1e12781110cedc12c
<sforshee> dmj_s76: yeah that one looks better. But we won't want to change the default unless it works well in 4.13.
<dmj_s76> sforshee: yes, that's why we're running tests now :)  I just wanted to raise the issue, since it appears there's enough time and (likely) a fairly simple fix.  Coffee Lake is fairly similar to Kaby Lake, so it makes sense the enablement wouldn't be too rough.
<dmj_s76> *enough time where supporting hardware on the current kernel is important.
<sforshee> dmj_s76: ack, let us know how the testing turns out
<tjaalton> dmj_s76: https://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=v4.13-cfl
<tjaalton> need at least those for cfl
<tjaalton> on top of 4.13
<dmj_s76> tjaalton: good find, thanks!
#ubuntu-devel 2017-10-27
<Unit193> So after the apport retracer runs, isn't it supposed to remove private data and make a private bug public?
<sarnold> mostly yes
<Unit193> https://bugs.launchpad.net/ubuntu/+source/variety there's a lot of recent bugs here that have been processed by apport, but are private.
<sarnold> curious. I can see them even though I thought I didn't have privileges to see "private" bugs, only "private security" bugs.
<Unit193> I have a little because of being Xubuntu dev.  A Debian developer maintains that package, and while not using Ubuntu he actually does try to keep on top of things.
<tsimonq2> Unit193: I can see those bugs, for what it's worth.
<tsimonq2> (I'm a member of the relevant Apport something or other team, something Brian Murray owns :P)
<Unit193> tsimonq2: That really doesn't help.  The question was: "Why doesn't apport set these public?"
<tsimonq2> Unit193: Well that's because the stacktraces "could" "possibly" have sensitive information.
<tsimonq2> Unit193: As far as I can tell, Apport does that for *, right?
<Unit193> It's supposed to review, debug a little, remove private, set public.  At least as far as I know.
<tsimonq2> I suspect that bdmurray might know the answer to that question.
<tsimonq2> I don't think it did it automagically, did it?
<Unit193> I have seen it do so in the past.
<tsimonq2> Oh? Got a bug number? I'm curious what it spits at the bug.
<Unit193> Not offhand.
<tsimonq2> Alright, that's fine, but if you happen to come across one, let me know.
<Unit193> tsimonq2: Though if you get bored and go through all of them before I do, that'd work too. :P
<tsimonq2> Unit193: Heh. I've been keeping myself busy enough lately :)
<bdmurray> Unit193: No apport is not supposed to the set the bug to public. It doesn't have the smarts to tell if there is sensitive data or not so that requires manual review.
<tsimonq2> Oh. Makes sense.
<sarnold> hrm. I thought I'd seen it open some bugs up.
<Unit193> â
<blahdeblah> Flannel, hggdh, Tm_T, Unit193: Are any of you ops in this channel & #ubuntu?  In the next hour or so I'm going to send an email about a brief service-affecting outage on Sunday at 23:00 UTC, and want to make sure we'll have someone who can op us briefly, or update topics for us.
<Flannel> Service outage for what?
<blahdeblah> Various web sites, incl. Launchpad git, ubuntu.com, canonical.com, etc.
<Flannel> Regardless, yes, we have people who can update topics.  Although I may not personally be around.
<blahdeblah> Who's the best person to ask at that time of the week?
<Flannel> blahdeblah: Go to #ubuntu-ops and let them know, and then topics will get updated.  That's the place.  Or #ubuntu-irc, but -ops is probably better.
<blahdeblah> thanks
<niedbalski> rbasak, ping
<niedbalski> tjaalton, rbasak could you please check the SRU for LP: #1657256? thank you.
<ubottu> Launchpad bug 1657256 in percona-xtradb-cluster-5.6 (Ubuntu Zesty) "Percona crashes when doing a a 'larger' update" [High,In progress] https://launchpad.net/bugs/1657256
<tjaalton> niedbalski: I'm about to EOW to start moving my office and everything after a 5mo evacuation, and this bug seems to be a tough one to go through with little time
<niedbalski> tjaalton, gotcha, fyi it's already in unapproved.
<tjaalton> noticed, still needs sru review
<cpaelzer> xnox: hiho - is there an override for systemd dep8 test on zesty already?
<cpaelzer> xnox: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/armhf looks rather consistently red
<xnox> cpaelzer, i'm not going to give you a straigh answer =)))))))) is there a "regression systemd/armhf" mentioned on a pending_sru page for you?
<xnox> cpaelzer, have you looked at the britney override hints for zesty?
<xnox> cpaelzer, do you know where to look both of those things up
<xnox> ?
<xnox> test-copy is known to fail, because test-copy binary is compiled too small and it is used as part of test suite. I am hoping to cherrypick test fix for that, and get systemd to become green.
<xnox> and there is a hint committed into zesty series of britney hints in the bzr branch by ~ubuntu-sru
<doko> mitya57: could you merge qtbase-opensource-src ?
<cpaelzer> xnox: I saw it in an pending-sru
<cpaelzer> xnox: and honestly I don't know if the overrides would make it not show up there or not
<cpaelzer> xnox: and I have to admit I didn't check the overrides yet, but I can
<cpaelzer> thanks for the answer
<cpaelzer> I didn't know there is a ubunut-sru branch of the hints
<cpaelzer> xnox: I beg your pardon but can you send me a pointer for that that is better than https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu ?
<cpaelzer> found it I think
<cpaelzer> all in https://code.launchpad.net/~ubuntu-sru
<cpaelzer> ok found all of them, learned about the per-release nature of the overrides now
 * cpaelzer ticks the "learned something today" checkbox :-)
<rbasak> Does udev definitely continue a RUN+= sequence if a script returns non-zero? I can't find the behaviour defined anywhere.
<rbasak> I mistake; I don't think it matters here. Though I'm still curious to know the answer.
<xnox> cpaelzer, however, it really should be hinted over =/
<xnox> cpaelzer, let me double check the report
<xnox> cpaelzer, ah! it is hinted, but needs more hinting due to security update.
* sil2100 changed the topic of #ubuntu-devel to: Artful Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<xnox> cpaelzer, https://code.launchpad.net/~xnox/britney/hints-ubuntu-zesty/+merge/332899 should make you happy, once merged.
<cpaelzer> xnox: thanks
<xnox> juliank, http://paste.ubuntu.com/25829628/ -> glob, regex, but why no relative full filename?
<xnox> juliank, had to do this # sudo apt install `find . -name '*.deb'`
<juliank> xnox: Needs to start with ./
<juliank> xnox: The reason is to make it easy to differentiate from real package names.
<xnox> juliank, not user friendly as there is no bash shell expansion for ./*.deb
<juliank> So, apt install ./*.deb would have worked
<xnox> juliank, but if there are no real package name.... it already tried glob and regex which are not real package names either.
<juliank> xnox: That expands normally
<xnox> trying by filename is sane.
<xnox> juliank, hm, ./*.deb does work, but this is the first time in my life that do such an expansion =)
<Faux> Never had a file named -? :)
<juliank> xnox: The autocompletion also only expands ./, I'd love to teach it to automatically turn filenames without it into that format. I don't like it either, but we really need to figure out things in general with command-line.
<xnox> Faux, i opened nautilus to remove that one!
<juliank> We just fixed Debian porterboxes dd-schroot-cmd to not accept package names starting with ./ or / in order to prevent people from installing locally built packages and gain root privileges.
<xnox> juliank, hahahahahaha
<xnox> cute
<juliank> The regex and glob thing should go away eventually, it's really unpredictable.
<juliank> Like, apt install foo1.2 -> installs foo1.2 if foo1.2 exists, otherwise installs anything matching regex foo1.2
<juliank> So I think long term we probably have package names, files, ? patterns, and ~ patterns
<juliank> And I guess ?file(path) or something
<juliank> aptitude's handling is OK, my goal is to get closer to that.
<juliank> xnox: I guess we should at least make apt check if the specified argument is an existing file, and then say: Please prepend ./
<xnox> juliank, yes
<xnox> it should check that the specified argument is an existing file, and say this is ambigious
<juliank> xnox: I guess one case where just respect any file name would break down is if you have a directory pkg with an extracted pkg, and do apt-get build-dep pkg and it's completely unclear if you mean the real package or the directory :)
<xnox> juliank, check that a file foo_18241-1_arch.deb exists, not a foo_18241-1_arch.deb folder =)
<juliank> build-dep can actually take both files and directories as arguments
<xnox> juliank, oh that works, hm i always did $ apt build-dep ./
<xnox> juliank, and imho it should actually just be $ apt build-dep
<xnox> juliank, and it should require to be in the top of the unpacked package
<xnox> juliank, just like the rest of ./debian/rules
<juliank> I'd like apt install ?build-depends(package) ?build-depends-file(...) ?build-depends-dir(...) or something
<xnox> juliank, nobody apart from you will remember that
<xnox> define an order and print a warning, if a particular order is used, but is ambigious.
<xnox> file/dir overriding pkg with a warning when specified without ./ is sane
<juliank> xnox: That's probably true. But apt-get build-dep could translate to that. And it gives you the ability to tweak build-dep installation, so you could manually specify an alternative
<xnox> what is build-depends-file? is that .dsc or debian/control?
<juliank> Well, that's really the same from our perspective IIRC
<xnox> my undertanding was that specifying dir, is actually translating dir -> dir/debian/control
<juliank> yeah
<juliank> I think so
<xnox> hence there is no build-depends-dir
<xnox> (underlying, it's syntatic sugar)
<juliank> right
<xnox> and when i do $ apt build-dep foo_1-1.dsc -> i do mean the file here locally, not the package name
<juliank> Anyhow, my plan is to sit down in January and define a proper pattern/package specification language and then implement that, starting with apt(8) and warning about incompatible uses in apt-get(8) for some time before switching that over
<xnox> imho you should ignore regex/glob/pkg-name if the argument ends with .dsc .deb /control
<xnox> and use file:/// syntax if something ends in .dsc .deb /control
<xnox> and declare that package names ending in '.dsc .deb /control' are broken.
<juliank> Let's just support all URIs :D
<juliank> apt install https://host/path/to/deb
<xnox> juliank, why not recursive glog too? $ apt install https://host/path/to/archive/*
 * xnox giggles =)
<juliank> xnox: /control might in fact be a valid release specifier like apt/xenial
<xnox> juliank, apt-url is built-in to fetch all the things, right right
<xnox> juliank, sigh
<juliank> xnox: It's at least not an adjective, so it won't be the next release codename :)
<xnox> juliank, warning + use local if ends in "/control .dsc .deb" is sane and say something like "use apt --no-file debian/control, if you mean to install a package called debian from a component called control"
<xnox> component? the term is suite, no?
 * xnox always confuses those things
<juliank> It's not component.
<juliank> APT calls it archive or codename, depending on what it is, but others might use suite or release or something
<juliank> In fact, APT has APT::Default-Release, so it also calls it release.
<xnox> ok so i'm not crazy for not knowing the term for the thing
<juliank> apt-get(8) calls it distribution
<juliank> xnox: The other thing also has different names, component, section, probably more.
<juliank> section (main) could easily be confused with section (admin), though
<juliank> oh, apt and python-apt are basically in an autopkgtest cycle.
<juliank> python-apt tests against apt 1.5 which fails, and apt 1.5 tests against old python-apt which fails too :)
<juliank> But I see some retries with newer versions, so at least its working there
<juliank> apt has test depends on python3-apt for one specific test case...
<jbicha> infinity: are you ok with me adding my patch from https://bugs.debian.org/879157 to bionic?
<ubottu> Debian bug 879157 in vim-common "vim-common: Set NoDisplay=true for vim.desktop" [Normal,Open]
<infinity> jbicha: Unsure.  I'm generally not a fan of terminal apps showing in GUI menus, but vim and emacs are sort of special snowflakes, being the preferred editors of most Linux users, despite being terminal apps.
<infinity> jbicha: And it works so seamlessly at least in GNOME (opens in my default terminal, with my preferred terminal size, etc) that it may as well be a GUI app.
<infinity> Heck, it feels more integrated than gvim. :P
<rbasak> gvim isn't bad as a GUI app.
<rbasak> At least unsuspecting users will be able to leave :)
<infinity> You can leave just by closing the terminal.
<rbasak> Doesn't that give you a scary warning?
<infinity> Nope.  Try it.
<infinity> Windows key -> vim -> enter -> close.
<rbasak> Interesting. I wonder how it manages that.
<rbasak> Oh
<rbasak> It just closes even if I make changes.
<infinity> Well, yes.
<rbasak> I stand by my claim then. gvim is better integrated :)
<infinity> I dunno.  I could go either way.
<jbicha> I believe GNOME is the most used desktop on Debian and it's hidden thereâ¦
<infinity> Yeah.
<rbasak> GNOME would :)
<jbicha> I did try to upstream it but I haven't had luck so far
<infinity> jbicha: I'll probably take this patch in.  I'd prefer to upload myself, so I don't lose track of TIL for merges.
<jbicha> ok, thanks!
<jbicha> my strategy to get it upstream now is to try to get distros to take my patch before asking upstream again
<infinity> jbicha: Yes, their justification for closing it was "both show up on Ubuntu and that's fine", which is a bit lolz, given you're from Ubuntu. :)
<infinity> jbicha: Oh, wait.  I was under the impression that this was a "new" feature.  We've been shipping this for years?
<infinity> Hrm.
<infinity> Now I'm less okay with removing it.
<infinity> Cause uers might actually be used to it being there in their workflow.
<jbicha> oh Fedora actually doesn't ship vim.desktop at all
<infinity> That could be a packaging bug rather than intentional.
<jbicha> the GNOME Activities Overview makes .desktops a lot more prominent than in Unity so it's more annoying now
<infinity> (ie: when it was added upstream, they may have just not noticed)
<jbicha> https://src.fedoraproject.org/rpms/vim/blob/master/f/vim.spec#_1205
<infinity> Intentional indeed.
<infinity> That is one ugly specfile.
<infinity> jbicha: While I'm waffling on this vim.desktop thing, do you... Oh look, you already fixed mozjs38, NEVERMIND.
<infinity> Well, "fixed".
<infinity> By skipping tests.
<infinity> Ick.
<jbicha> best fix
<jbicha> it's Cinnamon's fault that we still have mozjs38 in Ubuntu
<slangasek> bdmurray, jbicha, cyphermox, micahg, rbasak, sil2100: https://bugs.launchpad.net/bugs/1716770 is in the DMB's hands now regarding population of the ppu packageset, correct?
<ubottu> Launchpad bug 1716770 in ubuntu-community "[TB/DMB] New packageset ~personal-fossfreedom in Artful" [Undecided,New]
<jbicha> infinity: I did try applying https://github.com/mozilla/gecko-dev/commit/526416 but it's got RTL stuff going on and it didn't seem to work
<infinity> jbicha: Neat.
<infinity> jbicha: Though, that also seems to imply that it's just the test that sucks, and not the code being tested, so a bit more blase about the test being skipped.
<jbicha> infinity: you might like LP: #1728038 once edbrowse and libproxy publish and so on
<ubottu> Launchpad bug 1728038 in oolite (Ubuntu) "Remove ancient mozjs from bionic" [Undecided,New] https://launchpad.net/bugs/1728038
<cyphermox> slangasek: looks that way, yes
<sil2100> slangasek: I guess yes, thanks! We'll try to finally resolve the budgie packageset in our nearest meetings
<slangasek> sil2100: ok; but this is fossfreedom's ppu, so that is not blocked on that meeting, correct?  you have a list of packages ready to be added to that acl?
<slangasek> I would offer to jfdi this part, but last I knew I could create a packageset owned by the dmb but not add things to that packageset ;)
<sil2100> slangasek: let me do that now ;)
<slangasek> cool, thanks
<sil2100> fossfreedom: you have now been granted your rights for bionic, use this power wisely!
<jbicha> it looks like some s390x builders don't have bionic-proposed enabled? https://launchpad.net/ubuntu/+source/gnome-maps/3.26.1-1/+build/13629162
<cjwatson> that's not done on a per-builder basis
<cjwatson> that build was attempted in the release pocket, because it was on an arch that previously failed in artful, so was retried in bionic after being copied forward
<cjwatson> it'll be automatically retried once the new gjs makes it to bionic from -proposed
<jbicha> that's unexpected but ok
<cjwatson> it sort of makes sense, and since that kind of thing almost always only clears when dep-waits become available, it usually works out
<infinity> cjwatson: Speaking of add-missing-builds, is there still a backlog work item and/or bug somewhere to have that functionality rolled into series init?
<infinity> cjwatson: It's one of the few remaining reasons for ftpmaster shell.
<cjwatson> infinity: I don't think so ...
<infinity> Oh, lovely, icu59 forces c++11/gnu++11.  Derp.
<infinity> Do I turn icu into ifdef hell and submit upstream, or make the 2 C++ projects that fail use C++11?  Decisions, decisions.
<sarnold> are those two C++ projects C++14 or C++bad?
<infinity> sarnold: The latter.
<infinity> And oh my, just switching from gnu++98 to gnu++11 makes this thing explode SPECTACULARLY.
<infinity> So maybe doing the correct icu ifdef fix is smarter.
<infinity> (icu seems to have not noticed that they made their headers dependent on a C++ type that only appeared in C++11)
<sarnold> infinity: do we -need- those packages? :)
<infinity> sarnold: I mean, that's potentially up for debate, but it's still poor form to make a pretty core system library suddenly demand its rdeps use a certain language standard.
<infinity> Oh, I might be able to work around this with a -D
<sarnold> infinity: and yet I can entirely understand why someone would want to use C++11
<infinity> sarnold: Sure, but 6 years isn't actually a long time to expect the long tail to catch up.
<infinity> (sadly)
<sarnold> infinity: right
<infinity> sarnold: Using 11, or even 14 in your shiny leaf node application is awesome and encouraged, in a low level system library used by hundreds of consumers, a bit of guarding isn't too much to ask.
<infinity> Or maybe I live in a fantasy world.
<sarnold> infinity: just how much work is the ifdef hell? that might (a) already be done by someone else in their issue tracker (b) if not, would probably be something someone else would love to find stuffed in the icu issue tracker
<infinity> (Or, rather, using it in your low level library is also great, but exposing that through your ABI/API isn't)
<infinity> sarnold: Dunno, I'm trying to sort out if it might actually end up part of the ABI.  It might.  In which case, one can't fix this in headers, one would have to make a build-time choice, which sucks a bit.
<infinity> Well, my hack worked, so my carefactor just lowered a bit.
<sarnold> yay!
<geofft> anyone want to sponsor my SRU? it's a small fix, it's in universe, and it comes with autopkgtests :) LP #1725110
<ubottu> Launchpad bug 1725110 in config-package-dev (Ubuntu Artful) "config-package-dev 5.2 broke transforms" [Undecided,Confirmed] https://launchpad.net/bugs/1725110
<geofft> or is there a better place for me to ask for sponsorship? (#ubuntu-motu maybe?)
<nacc> geofft: looking
<nacc> geofft: so, iiuc, bionnic will auto get the fix when 5.4 syncs?
<geofft> yes
<geofft> I fixed it in Debian as soon as I got the bug report, that was just after artful's Debian import freeze
<nacc> geofft: ok, so I do't think i'd sponsor the 17.10 change, i'd just sync it (ow that the archive is open)
<geofft> so if an SRU that takes the form of syncing from Debian is a thing that can be done, that works. (or if the answer is "wait a bit for bionic then come back" that works for me)
<nacc> geofft: sorry, i meant that bionic needs the fix first
<nacc> geofft: and the right way for bionic to get the fix is to sync from debian
<geofft> do I need to do anything for that to happen? it's not patched currently so it should get auto-synced, right?
<nacc> geofft: yeah, i'm assuming the sync job is prety loaded right now, it might just not have hit it yet
<geofft> cool, I'll check back in a couple of days, thanks!
<geofft> nacc: at that point is the right thing to request sponsorship of the 5.4~ubuntu17.10.1 debdiff already on the bug, or do something else for the SRU?
<jbicha> nacc: autosync hasn't been turned on yet, but you're welcome to manually sync packages
<nacc> jbicha: ack, i know :)
<nacc> geofft: i don't think a full version update is immediately appropriate for an SRU
<nacc> geofft: i'm readingn the bug still, though
<nacc> geofft: meanwhile, I can sync it for bionic, at least
<geofft> thanks!
<nacc> geofft: would it be possible to list functional changes between 5.2 and 5.4 and why it is safe for SRU? it might be in there, but i'm having a bit of trouble parsing it out
<geofft> the only functional change is the bugfix. the other changes are autopkgtests, fixing examples/ so that autopkgtest works, adding .travis.yml and README.md (irrelevant for the package), and updating standards-version
<geofft> because I was not previously testing the examples, they were badly out of date :-(
<nacc> geofft: ah ok
<geofft> so it looks noisy
<nacc> geofft: right, i think that was the concern :)
<nacc> geofft: i also think we'll need to fiddle the versioning for 17.10
<nacc> geofft: oh nm, you used ~
<nacc> geofft: i do thnnk it might be missing an `update-maintainer`?
<geofft> woops, yes. sorry, I haven't done Ubuntu dev in forever :(
<nacc> geofft: np, i can run it locally, just easier to tick stuff off while i have you on irc :)
<nacc> geofft: https://launchpad.net/ubuntu/+source/config-package-dev/5.4
<geofft> nacc: nice, thanks!
<geofft> nacc: I ran update-maintainer and uploaded a new debdiff
<nacc> geofft: thank you
<infinity> geofft: FWIW, you could have asked someone to sync this into artful before release.  The Debian import freeze is a freeze on automatic imports, but manual syncs for bugfixes are much appreciated.
<infinity> (but indeed too late now, and yay SRU)
<geofft> infinity: yeah, I just completely failed to notice :(
<infinity> geofft: Life will probably somehow go on. :)
<karstensrage> hey infinity hope things are well, any chance we can revisit my packages?
<infinity> karstensrage: Oh crap.  Speaking of forgetting things.
<infinity> karstensrage: Yes, we absolutely ca.
<infinity> n
<karstensrage> i know you were busy with personal things
<karstensrage> so i havent wanted to bother you
<infinity> That was kind.
<karstensrage> so if you recall there was update to a package that already exists, so like a new version of upstream
<karstensrage> and there is going to be a new package that depends on it
<infinity> I have a feeling this webkit build might test the limits of my "build everything in RAM" strategy...
<infinity> karstensrage: Yep, an NSS module and a PAM module, IIRC.
<tsimonq2> infinity: How many builds does the arm builder build before the arm builder needs rebuilding?
<tsimonq2> *ahem*
<tsimonq2> I mean
<tsimonq2> What's up with arm builders? :)
<infinity> tsimonq2: Other than "they're a little over capacity right now"?
<tsimonq2> infinity: Why are they over capacity while the others are fine?
<infinity> tsimonq2: Because we don't have precisely identical capacity on all arches.
<infinity> (I feel like that's an obvious answer...)
<tsimonq2> infinity: My point is, ppc64el is fine and it only has 30 builders...
 * tsimonq2 shrugs
<tsimonq2> Maybe I'm missing something obvious.
<infinity> tsimonq2: 30 much faster builders.
<tsimonq2> Ah, gotcha.
<infinity> tsimonq2: Also, ppc64el only builds one arch, arm64 builds two.
<infinity> (arm64 and armhf)
<Unit193> ppc64el builders always seem to finish first, armhf tends to be last.  From what I've noticed.
<infinity> It's a game of leapfrog.
<tsimonq2> infinity: Interesting.
<infinity> For a couple of years, armhf was always the first done.
<infinity> Then we built up capacity elsewhere.
<infinity> Lather, rinse, repeat.
<tsimonq2> So then I wonder why we don't have more arm builders.
 * tsimonq2 shrugs
<infinity> See above, re: game of leapfrog.
<tsimonq2> I'm just asking because it's being a bottleneck.
<tsimonq2> Oh.
<infinity> In an ideal world, I'd put in a PO for a few hundred of every machine and never run out of capacity, but it's not an ideal world, and I'd prefer not to get fired for being a twit.
<tsimonq2> Heh.
<cjwatson> tsimonq2: One major reason is that server-class arm64 hardware has been a bit of a movable feast.  The generation we're using at the moment is really the first we have that's actually been server-class (not devboards, virtualisation-capable, etc.), but unfortunately it's no longer being manufactured and we haven't worked out what the next one along is going to be.
<cjwatson> tsimonq2: So at this point it isn't so much just a matter of "buy more of the same and plug it in" (when we heard it was going EOL, we bought up pretty much all we could ...), as "decide on a new platform, qualify OpenStack on it, etc.".
<cjwatson> tsimonq2: It's likely to be more interesting still because the hardware we have supports ARMv7 insns natively, which is nice for armhf build performance, but isn't actually required by the ARMv8 architecture.
<cjwatson> tsimonq2: So we'll have to be quite careful with the next generation of hardware to make sure armhf still builds reasonably.
<infinity> cjwatson: To the last point, most manufacturers are still opting into that, if we just avoid the ones that don't.
<cjwatson> (whatever that generation may be ...)
<infinity> My bet's on QC being a good possibility for next gen.
<cjwatson> infinity: Right, it's just another way to limit the field
<juliank> jbicha: We need to stop requesting new python-apt autopkgtest runs, there are 3 or 4 in the queue now. so wasteful...
<juliank> python-apt {"triggers": ["python-apt/1.4.0~beta3ubuntu1", "apt/1.5.1"]}
<juliank> python-apt {"requester": "jbicha", "triggers": ["apt/1.5.1", "python-apt/1.4.0~beta3ubuntu1"]}
<juliank> python-apt {"requester": "costamagnagianfranco", "triggers": ["apt/1.5.1", "sphinx/1.6.5-1"]}
<juliank> and
<juliank> python-apt {"requester": "juliank", "triggers": ["apt/1.5.1", "python-apt/1.4.0~beta3ubuntu1"]}
<juliank> oh man
<juliank> jbicha: Sorry, forgot :D
<juliank> * a :D
<jbicha> at least we only did one each, right?
<juliank> yeah
<jbicha> at least it's not one of the longer autopktests to run http://autopkgtest.ubuntu.com/packages/p/python-apt/bionic/amd64
<juliank> yeah
<juliank> I wonder what's happening with snapcraft on armhf
<juliank> with different errors even
<tsimonq2> cjwatson: Huh, interesting. Good to know.
<LocutusOfBorg> juliank, sorry, I triggered them on batch, because of armhf failures due to ENOSP
<LocutusOfBorg> they weren't "intentional"
<infinity> juliank: The one with no requestor was me.  The rest are all from terrible people. :)
<juliank> infinity: yeah
 * jbicha grumbles at qtdeclarative-opensource-src
#ubuntu-devel 2017-10-28
<mwhudson> infinity: the only armv8 server soc i'm aware you can actually buy right now doesn't implement aarch32 though
<mwhudson> unless i'm confused about one or more things
<hjd> Now that the bionic archive is open for development, has the automatic sync of packages from Debian started? I see a couple, like https://tracker.debian.org/pkg/eclipselink, which doesn't seem to have synced a newer version.
<hjd> I suppose bionic might sync from testing instead of unstable since its a planned LTS, but the newer version of eclipselink is available in testing too.
<infinity> hjd: autosync won't be enabled until after we've finished a manual transition or two.
<infinity> hjd: It'll be Soon(tm).
<hjd> infinity: Ok, sounds good :) Got disconnected for a second there, but got your soon(tm) message. Will check back later.
<LocutusOfBorg> infinity, do you have any clue about what toolchain change might have regressed casablanca testsuite on arm64 and ppc64el but not elsewhere?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/casablanca/2.10.0-1~build1
<LocutusOfBorg> I tried the old version and fails too...
<LocutusOfBorg> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
<LocutusOfBorg> this is where they took the code
<infinity> LocutusOfBorg: Not sure off the top of my head.  Could be the switch in the combination of gcc-7 and glibc-2.26 to use float128, which would give higher precision, and mess people up who are making precision assumptions.
<LocutusOfBorg> infinity, debian has older glib and it failed there too https://buildd.debian.org/status/fetch.php?pkg=casablanca&arch=arm64&ver=2.10.0-1~exp1&stamp=1509122627&raw=0
<LocutusOfBorg> I think I'll disable that test for now
<LocutusOfBorg> if you agree
<teward> this'll sound like a stupid question, but I assume that we're able to upload to Bionic now?
<teward> push updates and such, that sort of thing?
<teward> (I'm not awake yet hence asking)
<jbicha> yes but please don't upload unless you're awake ð
<teward> :P
<teward> jbicha: i'm awake enough to know when i have a package ready to push in to update nginx :P
<teward> i'm also sufficiently awake to communicate in a coherent manner.
<teward> Can't say anything about my mannerisms if someone decides to make my life hell, had to deal with noisy neighbors partying until after 1AM and as such I didn't sleep very well
<teward> the party stopped when the police I called came by and shut it down, but...
<teward> still doesn't mean I slept well.
<jbicha> new nginx should have TLS 1.3 support so yay from me :)
<teward> jbicha: if and only if OpenSSL has the support
<teward> we'd need latest OpenSSL for that, and I'm not sure what the state of that is.
<jbicha> oh
<teward> jbicha: remember that NGINX just interacts with the SSL libraries available for it at compile time
<teward> whether that be OpenSSL or LibreSSL or some other library alternative that NGINX works with.
<teward> in our case, it's OpenSSL, so I'd have to ask mdeslaur or the Security team what the state of the OpenSSL transition is, if there's gonna be one.
<teward> just like Apache too, if Apache code had TLS1.3 support, but OpenSSL was, say, Xenial's version, it'd not have TLS1.3
<jbicha> yeah, the transition might be after bionic (chaotic, if you willâ¦)
<teward> jbicha: yeah, when the OpenSSL transition happens, either everything'll need a build rerun, or I'll have to add a build-only version bump to force an nginx rebuild
<teward> though by that point, I'd expect there to be yet another NGINX update I"d have to push
<teward> my guess is that a full rebuild run will be run against the OpenSSL transition to find what builds and what doesn't.
<jbicha> https://release.debian.org/transitions/html/openssl1.0-rm.html
<teward> jbicha: yeah, that's an evil sign ain't it.
<teward> jbicha: i know that mdeslaur and others had held back on OpenSSL migration for some time but not sure what the state is still
<teward> i could ask but I don't care at the moment :)
<joelkraehemann> hi all
<joelkraehemann> Is this the right channel to ask to sync a debian package's version?
<jbicha> joelkraehemann: yes, but you can also run the syncpackage script from ubuntu-dev-tools to file a bug that sponsors will see
<joelkraehemann> jbicha: great thank you
<joelkraehemann> https://tracker.debian.org/pkg/gsequencer
<joelkraehemann> Where can I read more about the process of getting a sponsor?
<jbicha> https://wiki.ubuntu.com/SponsorshipProcess
<joelkraehemann> you are awesome
<joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
<joelkraehemann> ^^ there was once an old package
<joelkraehemann> What version of ubuntu should I use to build the package?
<joelkraehemann> 17.10?
<jbicha> if synced, it will end up in bionic (18.04)
<juliank> jbicha: I think people with sponsoring need need to use requestsync, not syncpackage
<Unit193> Correct, juliank.
<jbicha> joelkraehemann: ^
<joelkraehemann> Good to know
<joelkraehemann> I just compile the source code on ubuntu
<joelkraehemann> and run the integration tests
<joelkraehemann> note: they are disabled on debian
<joelkraehemann> ^^ by a patch
<joelkraehemann> all tests passed
<joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1728294
<ubottu> Launchpad bug 1728294 in gsequencer (Ubuntu) "Sync gsequencer 1.1.4-1 (universe) from Debian unstable (main)" [Undecided,New]
<joelkraehemann> Just recognized that there was introduced ld --as-needed
<joelkraehemann> Might be I am going to use it
<joelkraehemann> , too
<joelkraehemann> Note you should consider running functional tests in order to use this flag
<joelkraehemann> just commented what I was telling you
<mitya57> zul, jamespage: Is it OK to sync python-os-api-ref and python-pbr from Debian? The current versions are incompatible with Sphinx 1.6 and blocking its migration.
<mitya57> Otherwise please merge them, because I could not figure out what delta needs to be kept.
#ubuntu-devel 2017-10-29
<pisi2> jbicha: Hi, #1725821 This bug still affecting me. Will there be update for artful?
<pisi2> https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1725821
<ubottu> Launchpad bug 1725821 in mutter (Ubuntu Artful) "mutter 3.26 doesn't properly unredirect windows" [Low,Incomplete]
<jbicha> pisi2: yes, there is a proposed SRU in the unapproved queue. Once it's approved by the SRU team (later this week I hope), it will be built as a proposed update
<jbicha> and then if testing goes well, it well be released as a regular update a week or so later
<jbicha> I wasn't able to figure out a Test Case I could reproduce here with Intel graphics, so I used LP: #1725649 as the tracking bug for that issue
<ubottu> Launchpad bug 1725649 in mutter (Ubuntu Artful) "Fullscreen games lose "fullscreen" after an Alt+Tab" [Medium,In progress] https://launchpad.net/bugs/1725649
<pisi2> jbicha: thank you for information ð
<jbicha> pisi2: if you subscribe to 1725649 you'll get notified when the SRU team approves the proposed update
<jbicha> if you have a good test case, feel free to fill in 1725821
<pisi2> jbicha: is there way to help test team?
<infinity> jbicha: A test case would be nice, but a description would also be nice.
<infinity> jbicha: I suspect only a handful of people know what the title means.
<infinity> (And I'm not one of them)
<jbicha> infinity: but I can't reproduce the issueâ¦
<jbicha> I added a basic description with question marks, anyone actually affected should feel free to add more details
<z3ntu> Hey, is there any chance that debhelper 10.3+ is getting backported to xenial?
<z3ntu> Currently xenial-backports only has 10.2.2
<jbicha> z3ntu: what feature of the newer debhelper do you need?
<z3ntu> jbicha: meson build support
<jbicha> z3ntu: file a bug and ask Laney about maybe backporting it from artful (like was done for zesty)
<z3ntu> jbicha: filed a bug: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1728423
<ubottu> Launchpad bug 1728423 in debhelper (Ubuntu) "Backport debhelper 10.3+ to xenial" [Undecided,New]
#ubuntu-devel 2018-10-22
<FourDollars> Hi, I would like to make a patch for systemd on cosmic. Which branch should I target on? ubuntu/cosmic-proposed, ubuntu/cosmic-devel, applied/ubuntu/cosmic-devel, or applied/ubuntu/cosmic-proposed?
<FourDollars> Regarding https://code.launchpad.net/ubuntu/+source/systemd
<juliank> FourDollars: I think you want to submit a merge proposal against https://code.launchpad.net/~ubuntu-core-dev/+git/systemd/+ref/ubuntu-cosmic or just open a bug with a patch
<juliank> the importer repo is not really being used
<KOLANICH> Hello everybody. Can I speak to someone responsible for maintaining package archives?
<KOLANICH> I see I can't. So, here is the question: could you start providing delta debs? https://wiki.debian.org/Teams/Dpkg/Spec/DeltaDebs not debdelta, but delta debs, another format. Because some users are unhappy that to update firefox they have to download whole package. I gjess keeping the deltas between 2 latest versions is enough.
<juliank> Oh, KOLANICH
<juliank> that was weird
 * Laney smells a juliank sockpuppet :P
<FourDollars> juliank: I would like to open a bug and append a patch or just make a merge proposal.
<juliank> Laney: that does not seem very effective, but I'm happy to hear user interest
<juliank> FourDollars: Well then, do it
<FourDollars> juliank: ok thx
<ahasenack> tjaalton: hey, I noticed the openldap package has a debian/tests directory with some scripts in it, but no debian/tests/control, do you know when those are run?
<ahasenack> I don't see openldap listed in http://autopkgtest.ubuntu.com/testlist#index-o either
<tjaalton> ahasenack: no idea..
<tjaalton> ahasenack: looks like they just happen to share the same directory as autopkgtests
<tjaalton> those haven't been touched since 2008
<elektromacumba> hello, i'm under ubuntu 18.04.1 x86 and i'd like to customixe my initrd.img.*, but it's not in the usual format like in x64 version, the "file" command say "ASCII cpio archive (SVR4 with no CRC)" instead of classic gzip/cpio format. there is a way to unpack and customize it?
<coreycb> sil2100: would you be able to review the bionic upload for bug 1778771 ?
<ubottu> bug 1778771 in horizon (Ubuntu Bionic) "Backups panel is visible even if enable_backup is False" [High,Triaged] https://launchpad.net/bugs/1778771
<rbasak> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<balsaq> i noticed ubuntu does not fully uninstall packages when you ask it to do so leaving bits of useless files in the filesystem
<balsaq> the ubuntu software center should fully remove the package when the operator presses the remove button
<TJ-> balsaq: give an example please
<TJ-> balsaq: "remove" does not touch config files or files altered by the system administrator
<wxl> ^^ yeah, you need to purge
<balsaq> i noticed that , but i am saying there is no reason why u should have to do extra work to remove a package
<balsaq> when u press "remove" it should remove, purge clean or any other step u might need.
<wxl> you just need to use the right command and you won't have to
<balsaq> i know that too thanks
<TJ-> balsaq: no, the idea of "remove" is to keep config files in case the package is re-installed later
<balsaq> but there is no reason to make things with extra work for no good reason
<TJ-> balsaq: and the tools try to err on the side of caution
<balsaq> tj - pardon me  but that is not a good reason
<TJ-> balsaq: it is THE reason
<xnox> balsaq, use $ apt purge foo  or $ apt remove --purge foo
<balsaq> makes noi sense , because if  u want the package back it will put all thos files back
<rbasak> Unfortunately "remove" or "uninstall" is a bit vague. Different people have different expectations about what that means. For example, if you remove a database package, do you expect the database to be destroyed? As TJ- says, it's erring on the side of caution.
<rbasak> The same applies to local configuration customisations
<rbasak> Which is why configuration files are left.
<wxl> this is not new behavior............. not by any stretch of the imagination
<rbasak> They are typically tiny anyway. Do you have a specific problem when they aren't removed?
<balsaq> yes i do
<xnox> balsaq, there a few false positives, as currently .postrm scripts cannot declare that they are in-fact no-ops for purge, and thus packages get stuck in rc state, despite being clean on the system.
<balsaq> the problem i just told my OS to remove something and it did not do it comletely that is the problem
<rbasak> That's not a problem.
<wxl> it did exactly what you told it to do
<balsaq> it took the head off and left all the guts laying around
<wxl> no, it did an `apt-get remove`
<balsaq> 99 percent of the time when i person shoosed to remove the software thats exactly what they want
<rbasak> We know what it did, but I don't think you're going to get anyone to accept on this channel that it's actually a problem or that the behaviour should be different unless you can give us an actual broken use case.
<balsaq> i realize it is not a broken system
<rbasak> Please keep in mind that for every person who comes in asking the same thing as you, there are others who expect the complete opposite.
<balsaq> but when you do something you may aas well do it right
<rbasak> There will be someone who lost a database without expecting the system to do that, for example.
<wxl> in fact, there are many more
<rbasak> Ultimately the project has to make a decision on what the default behaviour should be for all users.
<cjwatson> Can you take this to the bug tracker please?  There's at least an argument that it should be possible to purge packages easily in the Software UI app (although I agree with others here that it's best for it not to be the default removal action, as it's irreversible)
<cjwatson> (There may well be a bug for this already - I haven't checked)
<wxl> if a user knows nothing, assuming complete purging is a terrible assumption
<balsaq> yes cjwatson thank you for that...i dont think it is a bug its just a bit of laziness
<wxl> while doing the opposite has no critical effect at all
<cjwatson> The bug tracker is where this sort of thing is tracked.
<rbasak> If you want the default to be changed, you're going to have to come up with a more compelling reason than "I disagree". There's also little point in arguing for the known cons that were already taken into account when the decision was originally made.
<balsaq> it could be developed like this instead:  when the operator presses REMOVE   a  pop up occurs   "do you want to remove this package completely" ?
<cjwatson> -> bug tracker
<cjwatson> IRC is not a bug reporting mechanism
<cjwatson> Anything here will be lost, unless you happen to get lucky and the specific people responsible for the program in question happen to be around
<wxl> i agree. this should go to the bug tracker. if a sound argument can be made there, i'm sure it could get resolved.
<balsaq> ok if you think so could one of you with experience please report the bug
<cjwatson> No, bugs should be reported by the person experiencing the problem
<wxl> you have the direct experience with the "problem"
<balsaq> well the simply install a snap package and then remove it and whoala you will be the man
<cjwatson> Use "ubuntu-bug /path/to/whatever/software/app/you/are/using"
<cjwatson> Haha you didn't even mention snaps earlier
<cjwatson> The entire discussion above is predicated on the assumption that you were talking about debs
<balsaq> well i  have a feeling this will happen using the software center no matter what
<cjwatson> No details -> terrible discussion
<balsaq> sorry but it came from the software center just as i said
<cjwatson> Removing a .deb removes everything except a tiny number of config files
<balsaq> all i am saying is if an OP installs from software center and removes from software center it should do it
<rbasak> balsaq: I suggest you read: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html - then you might understand our perspective better.
<cjwatson> Removing a snap, I don't honestly remember
<wxl> beat me to it rbasak!!!
<wxl> i literally had that in the clipboard
<wxl> tbh i don't know about snaps either. that's something worth exploring at the very least. you should file a bug.
<balsaq> i am saying that when a person removes any pkg from software center he should have the choice to fully remove it right at that moment no matter if it snap or deb thats all i meant
<wxl> then write a bug report
<cjwatson> You need to take this to the bug tracker, since as far as I know none of the people answering here work specifically on the software center UI.
<rbasak> If you're not prepared to sort out a bug report that explains what you mean and provides a place where we can clarify details, track progress and make decisions, then what you're saying will be politely ignored.
<sladen> balsaq: please repeat the process.  Taking a screenshot before, and after, after every step (eg. every mouse) click.  And attach all of these to a bug report
<balsaq> i couldnt possibly explain any better
<sladen> balsaq: (as politely as it can be said) at the moment, we haven't got *a clue* about the background, nor the details necessary to even start to look into this
<balsaq> ok
<balsaq> thanks
<cjwatson> Also, the implementation of the software center has changed radically between different versions of Ubuntu, and you haven't mentioned which you are using; a bug report is a good place to capture this.  The ubuntu-bug program can help you file it.
<balsaq> i am using the most current one i installed it clean yesterday  it is the lated LT 18 10 ubuntu desktop
<wxl> bug tracker
<cjwatson> I'm not asking you to tell us here :)
<balsaq> oh ok
<balsaq> sorry
<cjwatson> One of the points of ubuntu-bug is to gather this sort of information automatically so that people don't have to play twenty questions on IRC
<equinox> hi all... what's the policy/pattern used for the "-0ubuntu0.18.04" suffixes on package versions? (upstream maintainer working on packaging here)
<cjwatson> equinox: As an upstream, you wouldn't normally use that kind of security-update versioning, though it depends slightly on the situation; that comes from https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<equinox> cjwatson: i need to use /some/ suffix because the shlibs:Depends are different between 16.04 and 18.04 (libjson-c2 vs. libjson-c3)
<cjwatson> Oh, well if you're maintaining for multiple series then pretending they're security updates or similar and using the scheme from the wiki page above is reasonable enough
<cjwatson> This is presumably in a PPA or similar so you really just need to make sure that the version for the newer series is consistently >= the version in the older series so that upgrades are sensible
<equinox> we're actually maintaining back to 12.04 on older branches :D
<equinox> yeah
<equinox> (how would this work if the package was upstreamed and still needed the suffixes because the build result is slightly different between ubuntu releases?)
<cjwatson> It'd effectively be a downstream microbranch to do the backport
<cjwatson> Or somebody upstream would continue maintaining a PPA or whatever
<cjwatson> Packages in Ubuntu proper don't in general keep rolling to new versions in older series
<equinox> true... though if ubuntu rolls over to a new release while our package doesn't, there's again a situation where the same source version ends up with different build output due to shlib version differences
<xnox> equinox, we do not rebuild binaries.... each versioned binary is only compiled once, and is copied up. explicit uploads are required for rebuilds.
<xnox> ah, but you figured that, hence your question, never mind me
<balsaq> ok i have a ubuntu one account
<balsaq> wow launchpad timed out after all thiws work thus it didnot sully take my bug report
<balsaq> sheeesh
<cjwatson> you should be able to go back and try again
<cjwatson> it shouldn't have lost the text
<balsaq> well i can tell some went thru becasue i saw a note in there that said "simliar problemreported before"
<balsaq> apparantly noone knows how to integrte the purge command with the remove button in gnome-software
<balsaq> but im glad i have the ubuntu one now i see bugs all the time
<balsaq> in fact yesterday my icons from my icon launcher were "sticking" to my mouse pointer on screen as if they were magnetized...was very annoying on a fresh clean installation of ubuntu 18 10.
<balsaq> for some reaon it seems to have stopped now...
#ubuntu-devel 2018-10-23
<FourDollars> Hi, I would like to make a merge proposal on https://code.launchpad.net/~fourdollars/+git/systemd/+ref/ubuntu-cosmic/+register-merge to https://code.launchpad.net/~ubuntu-core-dev/+git/systemd/+ref/ubuntu-cosmic, but it always shows me the error.
<tarzeau> would it not make sense for ubuntu to have /etc/initramfs-tools/initramfs.conf with COMPRESS=xz (about 40% savings in /boot for the initial ramdisk) by default?
<cjwatson> I answered FourDollars on #launchpad
<FourDollars> xnox: Why is https://code.launchpad.net/~ubuntu-core-dev/+git/systemd/+ref/ubuntu-cosmic not in project or package namespace (as appropriate)? https://help.launchpad.net/Code/Git#Repository_URLs
<xnox> FourDollars, honestly, no idea. Project would be awkward for it (because this is not upstream code); and so would a package namespace (cause it is not git-ubuntu compatible one).
<xnox> FourDollars, do git format-patch; and attach them to a bug report?
<FourDollars> xnox: OK
<cjwatson> Package namespaces don't have to be git-ubuntu compatible
<cjwatson> You might not be able to merge it into lp:ubuntu/+source/systemd, but that's OK
<xnox> sure
<xnox> i'm looking at kernel team repos.... https://code.launchpad.net/~ubuntu-kernel/+git
<xnox> and i don't like that naming convention. As i'd rather have branches for series, not separate repos.
<xnox> cjwatson, is lp:~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd nice enough?
<xnox> (well "more correct")
<cjwatson> xnox: That's fine, and if it's the default repo for that owner/target then it can be abbreviated to lp:~ubuntu-core-dev/ubuntu/+source/systemd
<FourDollars> xnox: I have attach the patch on https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1799364. It is appreciated if you sponsor me.
<ubottu> Launchpad bug 1799364 in systemd (Ubuntu) "The wlan/bt hotkey doesn't work for all Dell Latitude and Precision computers" [Undecided,New]
<cjwatson> The kernel team repositories aren't a good general example to take; they have reasons for having series-specific repositories, but they aren't generally applicable
<cjwatson> (to do with size, number of refs, that sort of thing, IIRC)
<xnox> ok
<xnox> i'll see if I can migrate over to lp:~ubuntu-core-dev/ubuntu/+source/systemd
<cjwatson> Thanks
<FourDollars> :)
<xnox> FourDollars, hi. Your patch is actually not easy to review or merge =) it would be easier to just state "please cherrypick 9e2629919f0cd4d48d179fa5ae5e46c3267c1cdc"
<xnox> FourDollars, also did you simply use $ ./debian/git-cherry-pick 9e2629919f0cd4d48d179fa5ae5e46c3267c1cdc to generate that?
<FourDollars> xnox: OK. Let me try it.
<xnox> FourDollars, please don't =) i already did that locally
<FourDollars> OK
<xnox> FourDollars, basically, in systemd, we use that script for (bulk) upstream cherrypicks. And it results in slightly different patches generated.
<xnox> cause it uses gbp-pq
<FourDollars> xnox: OK
<xnox> see http://paste.ubuntu.com/p/mp8PMhxpMZ/ is the patch generated. It has no top level from line, but does have (cherry picked from....) message
<xnox> and then debian/changelog is also generated from git-dch, rather than edited by hand.
<xnox> but that's details of how systemd package is maintained in debian (and merged into ubuntu).
<xnox> FourDollars, in the future, "please cherrypick commits # # # # into dapper/hardy/feisty is good enough"
<FourDollars> xnox: OK
<FourDollars> xnox: I will do it again for bionic.
<xnox> and easier / doesn't require you to mess about with debdiffs, etc.
<xnox> FourDollars, which releases this change should go into?
<FourDollars> xnox: cosmic first and then bionic.
<xnox> cab01e9ecf1c69656785e64f5fc94cd4ed09e57f is post v238.
<xnox> FourDollars, ack, that's fine. I'll cherry-pick into both.
<FourDollars> xnox++
<xnox> let me try to migrate the repo too.
<xnox> FourDollars, what would be useful, is for you to contribute impact/testcase/regression potential for this SRU in the bug description at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1799364 I've copied in the stock template. Could you fill it out please?
<ubottu> Launchpad bug 1799364 in systemd (Ubuntu Dd-series) "The wlan/bt hotkey doesn't work for all Dell Latitude and Precision computers" [Undecided,New]
<FourDollars> xnox: OK
<seb128> cjwatson, hey. Do you feel like the comments on https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1785414 are enough to tag it verification-done?
<ubottu> Launchpad bug 1785414 in man-db (Ubuntu Bionic) "Backport seccomp sandbox fixes to 18.04" [High,Fix committed]
<seb128> juliank, hey, do you think you could get bug #1786486 verified? it's sitting in the verification queue for a while
<ubottu> bug 1786486 in fpc (Ubuntu Bionic) "upgrade from 16.04 to 18.04 uncalculatable due to fpc packages" [Undecided,Fix committed] https://launchpad.net/bugs/1786486
<seb128> tjaalton, hey there, did you see that Lukazs had a question on the SRU verification for bug #1789924 ?
<ubottu> bug 1789924 in mesa (Ubuntu Bionic) "Missing Intel GPU pci-id's" [Undecided,New] https://launchpad.net/bugs/1789924
<tjaalton> seb128: did now
<seb128> good :)
<cjwatson> seb128: Mm, sounds like I missed something else, but good enough for v-done - marked it as such
<seb128> cjwatson, thx!
<cjwatson> may as well get this much out the door
<juliank> seb128: I know. I can verify case 1 tomorrow, but not sure about 2
<juliank> um
<juliank> I can run that now
<juliank> this is hard
<juliank> Let's see
<seb128> juliank, thx
<juliank> sea-gull: I verified the minimal apt test case now, but I don't have the resources to do the u-r-u one atm. Maybe bdmurray can help there (verify u-r-u upgrade path in bug 1786486)
<ubottu> bug 1786486 in fpc (Ubuntu Bionic) "upgrade from 16.04 to 18.04 uncalculatable due to fpc packages" [Undecided,Fix committed] https://launchpad.net/bugs/1786486
<juliank> um
<juliank> seb128:
<juliank> sorry, sea-gull
<seb128> juliank, thx
<bdmurray> juliank: sure, I can do that
<seb128> thx bdmurray
<softwayer> Hi everyone! https://wiki.ubuntu.com/DebuggingProgramCrash#Installing_dbgsym_packages_from_a_PPA states a way to get dbgsym packages for my PPA, but actually they aren't there
<softwayer> So is there a way to setup generation of -dbgsym packages for my PPA?
<seb128> softwayer, in the +edit subpage you have a "publish debug symbols" checkbox
<seb128> build/publish checkboxes
<softwayer> great, thanks!
<FourDollars> xnox: I just filled the bug description of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1799364. If there is still any problem, please let me know.
<ubottu> Launchpad bug 1799364 in systemd (Ubuntu Dd-series) "The wlan/bt hotkey doesn't work for all Dell Latitude and Precision computers" [Undecided,New]
#ubuntu-devel 2018-10-24
<forester> hi. I do compile custom kernels. And I am not able to do this with 4.18 and 4.19. Maybe you know what to do?
<forester> And I have to change properties for clang-version.sh (enable execution)
<forester> I use ubuntu mate 18.04
<forester> therefore I still use 4.14 branch
<rbasak> xnox: please could you handle my comment in bug 1738153?
<ubottu> bug 1738153 in OEM Priority Project xenial "need backport the new scancode of dell-wmi for Microphone mute hotkey to xenial" [Critical,Confirmed] https://launchpad.net/bugs/1738153
<xnox> rbasak, unknown is a placeholder. so no keymapping is removed.... but is an indicator that a physical pressable key exists, and supresses kernel messages of `unknown key pressed`
<rbasak> xnox: OK, fair enough, thanks. I'm happy with the SRU verifiation for that bug then.
<balsaq> i found a bug in the package known as "GSmartControl"
<balsaq> when i installed it, it offered me a "launch" button but that button does not work...
<balsaq> i had to close it out, go find it in my OS, and relaunch it and then it worked.
#ubuntu-devel 2018-10-25
<ahasenack> does anybody know why my bileto build is fetching packages from a "stable-phone-overlay" ppa that I didn't add?
<ahasenack> https://bileto.ubuntu.com/#/ticket/3498 is the ticket
<ahasenack> https://bileto.ubuntu.com/excuses/3498/xenial.html is the failed build, which is fetching packages from that ppa
<ahasenack> it's a dependent package, not the package I uploaded to my ppa
<infinity> sil2100: ^^
<infinity> ahasenack: Wait, what?  I don't see the overlay in the builds anywhere.
<infinity> ahasenack: Or do you mean in the autopkgtests?
<ahasenack> infinity: yes, like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-3498/xenial/amd64/q/qca2/20181024_221441_cda16@/log.gz
<ahasenack> I tried to reproduce that failure, it didn't happen, then I checked package versions, and bileto used a different one from that stable-phone-overlay ppa, one that is not in xenial proper
<ahasenack> Get:37 http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu xenial/main amd64 qtbase5-dev amd64 5.6.2+dfsg-0ubuntu1~~xenialoverlay5~3 [950 kB]
<infinity> ahasenack: Yeah, definitely still a bug, but not as scary as what you implied by "my build is fetching..."
<ahasenack> example ^
<infinity> sil2100: bileto autopkgtests include the overlay even when the PPA doesn't.  That seems very broken (and how has no one noticed this?)
<ahasenack> probably because dep8 tests are not gating for srus?
<infinity> ahasenack: How would that matter?
<infinity> ahasenack: We don't trust bileto's tests for SRUs anyway, we re-run autopkgtests in-archive.
<infinity> (Same as for devel)
<ahasenack> don't know, just guessing
<infinity> I mean, these days, it would be explained by "almost no one uses bileto, and even fewer use it for xenial".
<infinity> But I'm surprised this bug wasn't noticed back when it was much more heavily used.
 * infinity shrugs.
<sil2100> ugh, stupid bileto
<ahasenack> the history is clear: http://autopkgtest.ubuntu.com/packages/q/qca2/xenial/amd64, logs don't show that ppa being fetched
<infinity> ahasenack: Err, right, cause that's not bileto.
<infinity> ahasenack: This bug is unique to how bileto is running autopkgtest.
<ahasenack> ok
<dosaboy> sil2100: hey, i have an sru thats been up for review for a while now any chance you could take a look https://bugs.launchpad.net/cloud-archive/+bug/1778771
<ubottu> Launchpad bug 1778771 in horizon (Ubuntu Bionic) "Backups panel is visible even if enable_backup is False" [High,Triaged]
<dosaboy> should be fairly straightforward as its a backport of a small patch thats already gone through upstream openstack and cosmic
<sil2100> dosaboy: hey! Sure
<dosaboy> sil2100: thank you
<tarzeau> where does gnome-software of ubuntu get the reviews/ratings data from? is that publicly available? read-only?
<tarzeau> could i get that data and feed it into http://phd-sid.ethz.ch/appstore/?chromium somehow easily?
<jbicha> tarzeau: it uses https://reviews.ubuntu.com/ but there is a proposal to switch to https://odrs.gnome.org/ which is used by all other distros
<jbicha> I don't think either are really designed to let people download the data in bulk
<tarzeau> jbicha: great links, will check them out
<tarzeau> both links not very helpful, indeed nothing to download in bulk, not even in small parts
<teward> tarzeau: the first one isn't useful because if you read: 'Currently, this website is only used by review moderators for Ubuntu Software Center.'
<teward> so there's no public access it seems.
<teward> the second you can see reviews but it doesn't provide a downloadable set of it.
<tarzeau> but the gnome-software has access to it
<tarzeau> sounds like stracing gnome-software and somehow figuring out stealing it from there, and make it look at all packages available
<teward> or a dedicated API internal to the software (and not generally end-user usable or 'public' to the world) - no way to tell unless you go digging.
<tarzeau> sounds like fun!
<jbicha> or you could talk to people :) I don't know who runs the Ubuntu site, but hughsie runs ODRS
<tarzeau> i tried to /query hughsie already, not online on freenode
<jbicha> maybe wrong time of day. When he's online, he's usually in #gnome-software on irc.gnome.org
<rbasak> tarzeau: strace? Just look at the code :)
<wgrant> / b3
<balsaq> i noticed a bug in ubunti 18 04 01, when i open settings, and attempt to dim my laptops display screen, the slider does not work...it slides back and forth as if it will brighten or dim the display but the display never changes.
<nacc_> !bug | balsaq
<ubottu> balsaq: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<nacc_> balsaq: this isn't the support channel as well, you want #ubuntu.
<balsaq> as developers i thought you might want to know that this was missed.
<nacc_> balsaq: i think you misunderstand the purpose of the channel (my opinion). you want the support channel and to file a bug.
<balsaq> i just told them too
<balsaq> thanks
<balsaq> how could an OS be sent out where you cant dim the ddisplay
<balsaq> they had that working back in the begining of time
<nacc_> balsaq: your single experience is not how an "OS" works.
<nacc_> balsaq: could be hardware, firmware or a bug.
<nacc_> balsaq: moving to #ubuntu.
<balsaq> i think the dimmer in setting is pretty self explanatory and i am using some of the most common hardware in the galaxy
<balsaq> what is that terminal command to report a bug
<balsaq> ok im in ubuntu thanks
<balsaq> my dimmer works in windows so i know my hardware works just fine
<rbasak> bdmurray: understood. I just meant that I should have noted it in the thread to save others the trouble of looking or attempting to do it when it was done already :)
<bdmurray> rbasak: Yeah, that makes sense.
#ubuntu-devel 2018-10-26
<TJ-> Would it be unusual for PhasedUpdate to break 'apt update'
<wxl> should we expect CVE-2018-14665 which is now in bionic and beyond to make its way back to xenial and trusty?
<ubottu> A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14665)
<wxl> the patch is tiiiiny which is thankful :)
<Faux> It's marked as unaffected: https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-14665.html
<ubottu> A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14665)
<wxl> oh wee
<wxl> what's DNE?
<Faux> Does Not Effect, or something like that. I don't know.
<wxl> well there's also "not-affected" so i would suspect that's not another indicator for the same thing
<wxl> ah does not exist
<Faux> Well, I've been horribly misreading those pages.
<wxl> which makes sensive given xorg-server-hwe-16.04 DNE's everywhere except for xenial
<wxl> s/iv//
<wxl> thanks Faux for pointing out the obvious for me
<rfleming> Hi.  I have a question in regards to how packages are moved from universe
<rfleming> particularly related to https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1637988
<ubottu> Launchpad bug 1637988 in gvfs (Ubuntu) "gvfsd-nfs not present in gvfs-backends, why?" [Wishlist,Triaged]
<rfleming> I do understand that an inclusion requisition was asked (https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598) but how long does this process normally take?
<ubottu> Launchpad bug 1746598 in libnfs (Ubuntu) "[MIR] libnfs" [Undecided,Confirmed]
<jbicha> rfleming: there is a backlog for main inclusion requests. Honestly that one is not a very high priority compared to others this year
<jbicha> btw, the Security Team is hiring: https://boards.greenhouse.io/canonical/jobs/1158266
<rfleming> jbicha: I see.
<rfleming> I don't know enough to be a contributor.
<rfleming> It's missed 16.04 and 18.04... maybe it'll be ready for 20.04
<sarnold> rfleming: guaranteed it'll get a security review before then :) but .. I have to say I'm skeptical of the reasons for a userspace nfs implementation
<sarnold> bdmurray:  Can't access efivars filesystem at /sys/firmware/efi/efivars, aborting --- is that really "success"?
<bdmurray> sarnold: On a system with BIOS yeah.
<sarnold> bdmurray: cool, thanks :)
#ubuntu-devel 2018-10-27
<Neffman> Does someone know how exactly the partion tables for the ISO9660 release files are getting created?
<Neffman> partition tables*, sorry
#ubuntu-devel 2018-10-28
<balsaq> here is some ubuntu wallpaper for the next edition of ubuntu https://imgur.com/a/Mn3C5q7
#ubuntu-devel 2019-10-21
<mwhudson> uhh
<mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/libguestfs$ pkg-config --libs python-3.8
<mwhudson> (ubuntu/devel)mwhudson@anduril:~/src/pkg/py38/libguestfs$
<mwhudson> that's not right?
<mwhudson> oh i see maybe it is
<dupondje> Hmmmm, just found something minor: https://launchpad.net/ubuntu/+source/openjpeg2 . The version in bionic is higher then version in disco/eoan
<dupondje> Causes not to get upgraded on dist-upgrade
<dupondje> ebarretto: ^
<seb128> dupondje, the content is the same though so shouldn't be an issue right?
<RikMills> I guess would only be if the -2 in disco was part of another library transition
<Laney> ddstreet: :(((( is there a bug report for that issue?
<dupondje> seb128: Don't think its really an issue indeed, just feels not clean. I always do a aptitude purge ~o after a dist-upgrade
<dupondje> and popped up :)
<seb128> right
<seb128> doko, hey, do you have any post explaining why dh-exec hacks like the one from https://launchpad.net/ubuntu/+source/pygobject/3.34.0-1ubuntu1 are needed with python3.8? also do you plan to forward those patches to the Debian BTS?
<ddstreet> Laney the patch to systemd's test references lp: #1748280, but that doesn't sound like what i see on canonistack in bos01; so maybe scalingstack doesn't have the same problem, but still takes 'too long' on some reboots, though i don't really know since i dont have access to scalingstack
<ubottu> Launchpad bug 1748280 in nova (Ubuntu) "'nova reboot' on arm64 is just 'nova reboot --hard' but slower" [Medium,Confirmed] https://launchpad.net/bugs/1748280
<seb128> mwhudson, hey, https://launchpad.net/ubuntu/+source/cracklib2/2.9.6-2ubuntu1 ... the changelog neither explain why  that diff is being added while the package was in sync/why it's needed, also it seems it could/should be forwarded to Debian. Can you please do that?
<doko> seb128: because it's not yet clear of dh-python can handle that
<doko> and all the mess, because 3.8 drops the m modifier
<seb128> doko, shouldn't we figure that upfront? rather than adding ubuntu delta?
<rbasak> ahasenack: good morning! I'm reviewing acme and certbot currently. Apart from my reviews, do you consider everything ready to upload now?
<rbasak> Both acme and certbot I assume - for Xenial and Bionic at least?
 * rbasak ponders Disco and Eoan
<ahasenack> rbasak: certbot is xenial and bionic, acme is xenial, bionic, disco
<ahasenack> rbasak: I don't have other planned changes, other than review comments
<rbasak> ahasenack: OK, so for acme that's andreas-guest/ubuntu-{xenial,bionic,disco}-andreas-review right?
<ahasenack> rbasak: yes, you should see ec0's branch ref in there too if you have it
<ahasenack> and my changes on top of his
<ahasenack> the hashes from ec0 match what you reviewed last from him
<rbasak> ec0's branch tips don't seem to be ancestors
<ahasenack> rbasak: this is what I see on my xenial review branch: https://pastebin.ubuntu.com/p/Zzz4BcxCTP/
<ahasenack> salsa-andreas/ubuntu-xenial is ec0's
<ahasenack> my fork of his branch
<rbasak> ahasenack: this is what I see: https://pastebin.ubuntu.com/p/sYXq3WjdDn/
<rbasak> (and more commits after that)
<rbasak> That's the fork point.
<rbasak> It's fine
<ahasenack> rbasak: he force-pushed I think
<ahasenack> his "Updated build dependencies to build on Ubuntu Xenial"
<ahasenack> you have e8782808a49a5657067b96aed18124be6b76c170 from aug 20th
<ahasenack> last one is at Sep 21 21:50:56 2019 +1000
<LocutusOfBorg> hello mitya57, https://buildd.debian.org/status/package.php?p=qtbase-opensource-src&suite=unstable looks like we have a bootstrap issue on arch:all?
<LocutusOfBorg> (sorry for using ubuntu channels, I didn't see you on oftc/#debian-devel)
<ahasenack> rbasak: what is that openssl 1.1.1 tag for bionic again?
<ahasenack> got another bug
<rbasak> ahasenack: bionic-openssl-1.1 thanks
<ebarretto> dupondje, sorry about that, I will get openjpeg2 rebuilt for disco/eoan
<dupondje> ebarretto: np :) just a minor thing I noticed :)
<dupondje> the tag should have been +build1 I suppose instead of build1 :)
<ebarretto> dupondje, actually ~build1
<ebarretto> ~ is lower than 2.3.0-2 and + is greater
<dupondje> aha k :)
<rbasak> ahasenack: +1 for both your acme and certbot branches, both for peer review and also for SRU accept
<rbasak> ahasenack: would you like to upload them? If you're not around, I can "sponsor" them
<ahasenack> rbasak: I'm here
<ahasenack> rbasak: I'll do it in a bit, could you please just confirm the hashes you +1ed?
<ahasenack> maybe in the ~canonical-server mps, for certbot?
<rbasak> ahasenack: actually the MPs for certbot have the wrong target branches, so I was ignoring them.
<rbasak> Let me put the hashes here
<ahasenack> rbasak: I wasn't sure how to target correctly, since these are backports
<ahasenack> I started from, say, cosmic-devel, and added changes for it to build on, say, xenial
<ahasenack> but that won't merge with xenial, there will be conflicts
<rbasak> acme: xenial 0907ce1; bionic 68149a9; disco a928edd
<rbasak> certbot: xenial 2fbc42e; bionic 97de715
<rbasak> I will check that the uploads match those before SRU accept
<rbasak> ("git ubuntu queue sync" makes it easy)
<rbasak> ahasenack: maybe best to avoid upload tags on these then?
<rbasak> I would base on the unapplied import tags of the backport source versions to preserve history.
<rbasak> I thought you did that for certbot at least
<rbasak> IIRC the acme branches are based on Debian VCS which won't be in git-ubuntu
<ahasenack> rbasak: right, acme I didn't start over
<rbasak> I suggest upload tags for certbot then, but not acme
<rbasak> (to be clear, you did exactly what I'd expect)
<ahasenack> ok
<ahasenack> I was wondering about upload tags
<ahasenack> for certbot (the git-ubuntu based one)
<ahasenack> rbasak: will you add something to the mps, or can I just paste this conversation there?
<rbasak> ahasenack: sorry, I didn't realise you were waiting. Go ahead and paste this conversation there if you like?
<rbasak> I see what you mean about the target branches now.
<ahasenack> ok
<ahasenack> thanks for the reviews
<ahasenack> rbasak: about target branches, it's like a merge from debian. The targed branch is debian/sid, but we are not really merging into that
<rbasak> Right, I follow now :)
<rbasak> It's because we have been overloading the target branches to get the preview diff right
<rbasak> Whereas this morning I tried to identify the MPs by target branch, which of course doesn't work with us doing that overloading.
<ahasenack> yeah
<ahasenack> rbasak: one more thing, for the changes file, should I use -v with the version in the target release?
<ahasenack> for example, certbot in xenial is 0.23.0-1~ubuntu16.04.1
<ahasenack> and we are backporting cosmic's 0.27.0-1
<rbasak> Good question!
<rbasak> I suppose that yes, that would be the most accurate.
<rbasak> Although
<rbasak> Actually, if there are any extra LP bug references, that might cause extra bugs to appear in the pending-sru report.
<rbasak> So now I don't have a good answer. I don't think it'll be particularly bad either way though, so I'll accept both unless someone tells me otherwise.
<rbasak> We can ignore any extra bugs in pending-sru easily enough.
<rbasak> And it'd be right to autoclose them if any of those bugs have open series tasks anyway.
<ahasenack> let me check the endresult of the changes file
<doko> jamespage, coreycb: why does ceph b-d on python3-all-dev ?
<jamespage> doko: I suspect that's a legacy thing - python3-dev should be sufficient as it only targets the default python3 version
<vorlon> oSoMoN: hi, so after the chromium deb->snap transition, all of my data appears to have been cleanly migrated to ~/snap/chromium/current/.config/chromium, however none of my saved passwords are available to the browser despite the sqlite db being present in the config.  Any hints?
<vorlon> oSoMoN: (this is with in-browser password store, not synced to google account)
<ahasenack> rbasak: certbot and acme uploaded
<mitya57> LocutusOfBorg: it will auto-solve itself
<mitya57> Actually, already solved
<mitya57> But please don't copy that to Ubuntu yet, I will do that myself
<rbasak> cyphermox: the ubuntu-server packageset has never had upload right delegated; that's all. Nobody requested it and nobody felt the need I guess.
<rbasak> rafaeldtinoco, marcustomlinson: congrats!
<rafaeldtinoco> rbasak: Thx Robie!
<Odd_Bloke> Given it's in universe and in sync with Debian, I don't know if anyone is paying attention to apt-file issues, but I just hit https://bugs.launchpad.net/ubuntu/+source/apt-file/+bug/1848768 in eoan and it has 3 other reporters too.
<ubottu> Launchpad bug 1848768 in apt-file (Ubuntu) "19.10: cache is empty. You need to run "apt-file update" first." [Undecided,Confirmed]
<marcustomlinson> rbasak: thanks :)
<rbasak> ahasenack: all accepted now, thanks! With build-deps correctly bumped, I expect the python-certbot builds to hit dep-wait until the python-acme builds are published
<ahasenack> yep
<infinity> vicamo, tseliot: The changelog on that backport-iwlwifi-dkms upload alters history to claim the previous upload was in focal, not eoan.  Please fix that and reupload.
<tseliot> infinity, I'll have a look and fix it, thanks
<infinity> tseliot: Ta.
<andrewsh> reposting again since apparently the Matrix gate lost messages (?)
<andrewsh> https://translations.launchpad.net/apport/trunk/+pots/apport/sk/+translate?field.alternative_language=cs&field.alternative_language-empty-marker=1&show=untranslated&memo=10&start=10
<andrewsh> I just noticed thereâs a lot of translations
<andrewsh> some of them hang there unaccepted for many years
<andrewsh> what can be done about that?
<mwhudson> seb128: yes, that should probably go to debian
<mwhudson> seb128: i'm a little bit uncertain about all this stuff
<lvh> Hi! Given a JSON-formatted USN entry (from database-all.json.bz2), how do I figure out if a particular release was never affected by an USN in the first place vs if it still needs a patch but it's not available yet?
<lvh> I think it's "the release is present as a key in the 'releases' object but no version is listed" but I'm not sure. That's certainly how the USN website appears to generate the HTML
<sarnold> hey lvh
<lvh> Hi :)
<sarnold> lvh: so, I'm about to head off to lunch.. and just moments ago pushed an update for that file
<sarnold> lvh: (a) probably #ubuntu-hardened will have more folks around who know that file (b) can you pastebin up what you're seeing that's causing trouble?
<lvh> Oh, it's not so much having trouble with any particular part of the file as making sure that I am correctly interpreting what that file is actually saying
<sarnold> aha :)
<lvh> Enjoy your lunch! I'm going to ask #ubuntu-hardened :)
<sarnold> thanks :)
<hallyn> when will archive re-open?  just looking for someone (maybe me) to sync edbrowse from debian :)
<mwhudson> hallyn: couple days
<hallyn> thanks
<jbicha> hallyn: it will auomatically sync to Focal soon since there aren't Ubuntu-specific changes
<hallyn> ah, ok
<hallyn> so i'm not needed :)  excellent
<hallyn> \o
<jbicha> I mean I appreciate you ð ð
<hallyn> lol :)
#ubuntu-devel 2019-10-22
<vicamo> infinity: tseliot: also rebuilt and submitted to my ppa in https://launchpad.net/~vicamo/+archive/ubuntu/backport-iwlwifi-dkms-proposed
<infinity> vicamo: Did that intentionally clobber the stack-clash changes?
<infinity> vicamo: Also, your changelog mentions updating a copyright, but I see no such change actually in the diff.
<vicamo> infinity: the stack-clash patch is for compiling under gcc-9
<vicamo> infinity: it's also landed to mainline kernel as https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=29be86d7f9cb18df4123f309ac7857570513e8bc
<vicamo> infinity: for copyright change, it's in debian/copyright
<vicamo> infinity: it's managed in git in https://code.launchpad.net/~vicamo/ubuntu/+source/backport-iwlwifi-dkms/+git/backport-iwlwifi-dkms/+ref/for-focal/bug-1848922/fix-build
<vicamo> infinity: the first time 7906-0ubuntu1 is uploaded, sponsor helped me to correct that copyright directly, and it's now also updated in my local copy.
<vicamo> infinity: that's why you won't find such diff
<vicamo> infinity: I can remove that line from changelog if that would be more appropriate
<LocutusOfBorg> mitya57, working on qt is really not in my wish list :)
<andrewsh> hi again, let me repost it here now
<andrewsh> there seems to be a lot of unaccepted translations for Slovak at Launchpad, theyâve been there for many years: https://translations.launchpad.net/apport/trunk/+pots/apport/sk/+translate?field.alternative_language=cs&field.alternative_language-empty-marker=1&show=untranslated&memo=10&start=10
<andrewsh> what can I do to help change that? is there a translation team or something I can become part of?
<andrewsh> also: who should I talk to to get necessary permissions to edit the wiki?
<octal_> Hello everyone. I'm experiencing a weird behavior regarding TCP and sendmsg system calls. Here is my scenario: I have a TCP server wainting for a certain number of clients to be connecting before sending them a batch of 128 bytes messages, 100 messages every batch, and then sleeping 1ms between each batch. I'm then measuring the time it takes to
<octal_> send a message to all clients. On Ubuntu16.04, kernel 4.4 with TCP_NODELAY enabled, I get a 50th time of ~750ns. On Ubuntu 18.04 with kernel 4.20 I'm getting ~5000ns with TCP_NODELAY and 1000ns without TCP_NODELAY
<octal_> Any idea why ? I can share my server and client code if needed
<mwhudson> Need to get 418 MB of archives.
<mwhudson> After this operation, 1425 MB of additional disk space will be used.
<mwhudson> this is not a lightweight package build then!
<mwhudson> LocutusOfBorg: did you report the problem with odb-api 0.18.1-8 to the maintainer?
<xnox> rbalint:  ddstreet: do you at all remember if we tried to backport/include https://github.com/systemd/systemd/pull/9158 in bionic or not?
<rbalint> xnox, i can't recall that
<ddstreet> i dont remember backporting it
 * xnox ponders why my brain remember it as a dejavu
<cpaelzer> rbasak: I see you answers to the uvtool merge coming in one by one - please consider all that I do not answer as "ok"
<rbasak> ack, thanks
<Mmike> Hello, good people. I'm trying to build a .deb package using pbuilder-dist, for my local use (curl is the package), and I'd like to skip tests, as I don't care much for them. Is there a way to tell pbuilder (or sbuild, for that matter) to skip tests and just build the package?
<dupondje> Mmike: you should adjust the debian/rules file for that
<amurray> Mmike: you could try setting DEB_BUILD_OPTIONS=nocheck
<Mmike> dupondje, yup, I was trying to avoid that.
<Mmike> amurray, thnx, trying now
<Mmike> amurray, seems nocheck is being ognored :) I'll adjust debian/rules
<tarzeau> is andreas moog here by chance? or someone knows him?
<tarzeau> amoog@ubuntu.com after all
<tarzeau> or maybe someone else can fix it in debian and sync it to ubuntu? https://bugs.launchpad.net/ubuntu/+source/libbinio/+bug/1839038 (i need it for ocp(opencubicplayer))
<ubottu> Launchpad bug 1839038 in libbinio (Ubuntu) "adplug+libbinio+memory mapped = crash on some files" [Undecided,Confirmed]
<sahid> slashd: o/ when will be the next developer membership board meeting?
<sahid> https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
<sahid> i would like add my application https://wiki.ubuntu.com/SahidOrentinoFerdjaoui/PerPackageApplication
<rbasak> sahid: they follow a pattern: every two weeks, alternating between 1500 and 1900.
<rbasak> sahid: please feel free to update the wiki with current meeting dates - we only have them listed there to save others from working it out.
<rbasak> (just take care to follow the pattern though please to avoid confusion)
<sahid> rbasak: ok thank you i will do that
<rbasak> I just moved bug 1849325 to curtin as I came across it, and that's more correct than for the bug to be against Launchpad. Not sure if that's correct for triage though.
<ubottu> bug 1849325 in curtin "18.04 Server Install - Software RAID setup crashes" [Undecided,New] https://launchpad.net/bugs/1849325
<powersj> rbasak, give it was during subiquity and had a curtin trace I'm good with that
<rbasak> Thanks!
<LocutusOfBorg> mwhudson, reopened the bug report
<LocutusOfBorg> sorry for not crediting you for the patch i found you had already told also that fix to the maintainer after crafting the same fix...
<LocutusOfBorg> how can it be *that* difficult to just apply a patch? :/
<rbasak> rafaeldtinoco: on block-proposed-<series> for SRUs, I don't understand your second paragraph with your questions.
<rbasak> What do you mean by "finishing the next SRU"?
<rbasak> Actually reading again I think I might understand what you're asking, but am not sure.
<rbasak> Do you mean what someone driving a future SRU who wants a further uploader to land needs to do?
<rbasak> Do you mean what someone driving a future SRU who wants a further upload* to land needs to do?
<rafaeldtinoco> yes
<rafaeldtinoco> sorry for not being clear enough
<rbasak> No problem. I'll respond to the thread, thanks
<seb128> bdmurray, hey. Did you manager to have a look at why eoan retracing are failing? Half of the top 19.10 reports on a weekly view are missing symbols/failing retries
<seb128> e.g
<seb128> https://errors.ubuntu.com/problem/fd929348e8a0d94304efaa3c0e86de13ed2acfe8
<seb128> https://errors.ubuntu.com/problem/3e80e42b3076f09542c1c3654871c897bbd1f12e
<seb128> https://errors.ubuntu.com/problem/99ee014259e65652496f09ed33b4d8f2d7de2f08
<seb128> https://errors.ubuntu.com/problem/50762846c553232d8fc30227e07ba39ff996418a
<seb128> https://errors.ubuntu.com/problem/50762846c553232d8fc30227e07ba39ff996418a
<seb128> https://errors.ubuntu.com/problem/b706258a6f378ab07c3e84f1f63aaa504743f214
<seb128> well, most of 19.10 starting errors it looks like :/
<Eickmeyer> Hey! Can I get some SRU love on bug 1849168?
<ubottu> bug 1849168 in carla (Ubuntu) "[SRU] Missing build dep libsndfile1-dev discovered" [Undecided,Fix committed] https://launchpad.net/bugs/1849168
<bdmurray> seb128: Not quite yet but I have some free time today and Friday
<mwhudson> LocutusOfBorg: thanks, and no worries about credit :)
<mwhudson> LocutusOfBorg: some worries about reading comprehension, yeah
<LocutusOfBorg> :)
#ubuntu-devel 2019-10-23
<mwhudson> ok pop quiz time what is going on here https://launchpadlibrarian.net/448056138/buildlog_ubuntu-focal-amd64.python-gevent_1.3.7-1build2_BUILDING.txt.gz
<Unit193> Looks like a build failure.
<mwhudson> +1 insightful
<Unit193> That looks fun, same file is in python3-greenlet-dbg and python3-greenlet.
<Unit193> Specifically if you look at https://launchpadlibrarian.net/447991806/python-greenlet_0.4.15-2_0.4.15-2ubuntu1.diff.gz
<Unit193> See why that'd be bad? :P
<mwhudson> oh yay
<mwhudson> thanks for chasing :)
<Unit193> Sure.  I guess I can't just make a sarcastic comment. :3
<mitya57> sil2100: hi, can you add focal support to bileto please?
<sil2100> mitya57: ah! Yes, let me bump the cache
<sil2100> mitya57: should be enabled in up to 30 minutes
<mitya57> sil2100: it works now, thanks a lot!
<LocutusOfBorg> Eickmeyer, hello, how can somebody sponsor a fix for LP: #1849168 if 1) there is no indication about which series are affected 2) there is no patch to sponsor ?
<ubottu> Launchpad bug 1849168 in carla (Ubuntu) "[SRU] Missing build dep libsndfile1-dev discovered" [Undecided,Fix committed] https://launchpad.net/bugs/1849168
<sil2100> yw!
<LocutusOfBorg> mwhudson, Unit193 do I have greenlet greenlight to upload a fix for it?
<LocutusOfBorg> doko, ^^
<Unit193> I just pointed out what went wrong.
<LocutusOfBorg> yes sure bug greenhighlighting you doesn't hurt!
<mwhudson> LocutusOfBorg: i'm all for fixing it, i guess doko can always reject it from the queue if he doesn't like it :)
<LocutusOfBorg> mwhudson, I think I already crafted a fix
<LocutusOfBorg> mwhudson, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10667371/+listing-archive-extra
<LocutusOfBorg> if you agree
<mwhudson> LocutusOfBorg: lgtm
<LocutusOfBorg> still have to debdiff debs
<LocutusOfBorg> feel free to upload if you like it, or I can do it and credit you :)
<LocutusOfBorg> I'm also going to update the debian bug report
<LocutusOfBorg> mwhudson, ping :) I have to replace keyboard and reboot laptop... please let me know if you want me to do it or not
<mwhudson> LocutusOfBorg: eh just update it, getting late here
<mwhudson> *upload
<LocutusOfBorg> thanks :D
<mwhudson> LocutusOfBorg: sorry if i was being ambiguous earlier
<LocutusOfBorg> I "just" woke up :D
<cgm____> Hi all, is there somewhere I can find the commands used to build the official Ubuntu netboot ISOs? Specifically the xorriso arguments
<rbasak> rafaeldtinoco: o/
<rbasak> rafaeldtinoco: Josh suggested I ask you to arrange a seed change so you can get familiar
<rafaeldtinoco> rbasak: morning o/
<rafaeldtinoco> rbasak: awesome, I read the docs already
<rbasak> Great! I want to get mysql-router seeded in Focal
<rafaeldtinoco> alright, let me go through it
<rafaeldtinoco> and ask you whenever I have questions
<rbasak> Actually, I should tell you what I really need, rather than presuppose a solution
<rbasak> What I need is mysql-router in main in Focal :)
<rafaeldtinoco> yep I thought it was that #)
<rafaeldtinoco> rbasak: do u have a MIR already ?
<rbasak> src:mysql-8.0 is in main already, and mysql-router is built from that
<rbasak> That's the closest we have to an approved MIR
<rafaeldtinoco> alright
<rbasak> cpaelzer: thank you for the uvtool reviews. I'm working on your emulation branch next.
<rbasak> I have a rebased/squashed version locally.
<cpaelzer> rafaeldtinoco: you reported a FTBFS on disco
<cpaelzer> rafaeldtinoco: I wonder what might have changed as the last build worked
<cpaelzer> and that was an SRU, there surely was no full bump of gcc in Disco since then
<cpaelzer> did you check what the reason whas that this now triggers?
<cpaelzer> or is that a local build, and not one in a "normal" build environment?
<rafaeldtinoco> cpaelzer: it was a local build indeed
<cpaelzer> then chances are this is "not-a-bug" (in disco)
<rafaeldtinoco> it can be related to an enabled (in my env) Werror of somesort
<cpaelzer> yes
<cpaelzer> you remember that if .ig tthen switch on developer mode thing
<cpaelzer> .git
<rafaeldtinoco> I noticed also that DEB_HOST_XXX variables are not set
<rafaeldtinoco> so it only works with dpkg-buildpackage basically
<rafaeldtinoco> i tried manually dh build, debian/rules build
<rafaeldtinoco> and always got errors
<rafaeldtinoco> and yes, there are chances of a false alarm
<rafaeldtinoco> sorry if that is
<rafaeldtinoco> i was more focused in the backport
<rafaeldtinoco> didnt think about being my build env, yes
<rafaeldtinoco> (or my build environment is broken, dont tell me that pls)
<cpaelzer> manual dh_... always calls for issues
<cpaelzer> build in sbuild, if it fails you can login, if it doesn't \o/ and it will always be clean made fresh for you
<cpaelzer> (if you have/want to build local)
<cpaelzer> rafaeldtinoco: I have thrown it into a PPA, if it doesn't fail I'll mark it won't fix
<rafaeldtinoco> yep, will do. thx and sorry if its just a noise
<cpaelzer> np rafaeldtinoco, I created enough nose with my quad-haproxy MPs going back and forther through two force pushes
<cpaelzer> so I flooded all your inboxes, we are even I guess :-)
 * rafaeldtinoco looks at thunderbird and thx proper filters
<cpaelzer> if paelzer then ->trash ?
<rafaeldtinoco> cpaelzer: it also has "conversation" extension, showing only 1 mail per thread for me
<rafaeldtinoco> #)
<rafaeldtinoco> and diff syntax highlight and compare extension
<rafaeldtinoco> thunderbird is pretty neat nowadays #)
<cpaelzer> isn't grouping threads the default everywhere these days?
<rafaeldtinoco> cpaelzer: yes, but not showing single lines per subject
<rafaeldtinoco> w/ no threads at all
<rafaeldtinoco> like google does
<rafaeldtinoco> cpaelzer: btw, i was checking qemu-arm folder
<rafaeldtinoco> there wasn't a closure on the barrier subject, right ?
<cpaelzer> not yet
<cpaelzer> stuck on upstream discussion
<cpaelzer> I haven't seen a major breakthrough
<rafaeldtinoco> my assumption is that marvell is still investigating
<cpaelzer> the last active participant was Jan Glauber IIRC
<rafaeldtinoco> why the data alignment caused mitigation (or not)
<rafaeldtinoco> (changing u32int -> u64int and so)
<cpaelzer> I had that on my radar as "waiting on upstream / waiting on partner" or is/was there pressure on you to go haead?
<rafaeldtinoco> no pressure, just missed the discussion
<rafaeldtinoco> i re-thought "maybe some conclusion happened and Im not aware of "
<rafaeldtinoco> lol
<rafaeldtinoco> but reading last emails, all I can see is that memory alignment changes behavior (likely because of cache alignment and cpu <-> coherency)
<cpaelzer> yep, they invalidate separately then
<rafaeldtinoco> causing more overhead for the HW sync (or less overhead) and making it more or less frequently
<rafaeldtinoco> yep
<cpaelzer> but that is not "a solution"
<rafaeldtinoco> exactly
<rafaeldtinoco> ok, my understanding is right then
<rafaeldtinoco> thx
<cpaelzer> yw
<cpaelzer> doko: you asked for python-tornado yesterday as it triggers issues with python 3.8 rebuilds
<cpaelzer> I think it is important to see that there is a newer 6.x but that was turned back to allow dependencies to follow
<cpaelzer> never the less look at the changelog https://metadata.ftp-master.debian.org/changelogs//main/p/python-tornado/python-tornado_6.0.3+really5.1.1-1_changelog
<cpaelzer> good old mwhudson has a change that sounds rather related "Bump ASYNC_TEST_TIMEOUT when running the autopkgtests as well"
<cpaelzer> or do we have that already ...
<cpaelzer> oh yeah, :-/ our Delta has that already
<cpaelzer> grml, I thought this might be easy ...
<Eickmeyer> LocutusOfBorg: 1) It's tagged eoan, and 2) Doesn't really need sponsorship as I have PPU on the package. Just needs the green light.
<cpaelzer> coreycb: he pinged you as well, please tell me that you have looked more at it and know what it is :-)
<coreycb> cpaelzer: hey sorry I've not had a chance to look yet
<coreycb> cpaelzer: let me wrap a few things up and look
<cpaelzer> sure, thanks for looking as well then
<cpaelzer> if you also don't see what might be going on let me know, then we can bang our head against the wall together
<LocutusOfBorg> Eickmeyer, this is not usually how SRU are done
<LocutusOfBorg> 1) you have to first fix focal
<LocutusOfBorg> 2) you have to correctly use "target to series"
<Eickmeyer> LocutusOfBorg: Upload is in queue for focal.
<LocutusOfBorg> ok so please wait for it to migrate before uploading to eoan
<LocutusOfBorg> [Regression Potential]
<LocutusOfBorg>  * None, simply adds a build dependency and patch to existing package
<Eickmeyer> Ok. I don't have the ability to target to series.
<LocutusOfBorg> meh, adding a new dependency has a lot of side effects
<LocutusOfBorg> e.g. enables code that wasn't built, changes behaviour and so on
<LocutusOfBorg> you might change this to "the current package is completely broken", adding the dependency makes it less sucky
<LocutusOfBorg> if this is true
<LocutusOfBorg> or try to see what changes in the build system in case the dependency is found
<cpaelzer> coreycb: I tried a few local build (maybe that helps you to find the right start): 6.0.3@unstable (worked), 5.1.1@eoan (worked), 5.1.1@focal (the reported timeouts), 5.1.1@focal-proposed (the reported timeouts), 6.0.3@focal-proposed (dependency issues)
<LocutusOfBorg> e.g. you could change it with something like "adding libsndfile enable the detection of various new plugins, otherwise unsupported, with the HAVE_SNDFILE preprocessor directive
<Eickmeyer> LocutusOfBorg: Unfortunately, that's not the case. It simply allows certain synthesizer plugins to actually make sound, which they weren't before.
<LocutusOfBorg> this list includes: aif aifc aiff au bwf flac htk iff mat4 mat5 oga ogg paf pvf pvf5 sd2 sf snd svx vcc w64 wav xi
<LocutusOfBorg> Eickmeyer, in any case, please try to be more verbose on the regression potential task, because it makes easier for release team to ack/nack the change
<LocutusOfBorg> in any case, LGTM
<Eickmeyer> LocutusOfBorg: Thanks.
<cpaelzer> coreycb: but since doko disabled the tests to be gating yo'll have to switch these back if you want to break on them
<cpaelzer> they are always triggered, just no more making the build fail
<rbasak> cpaelzer: when you have a couple of minutes, I'd like to chat about next steps for your armhf emulation branch please. More a process for adjustments since I'm juggling branches. Discussion of the technical details we can discuss in the MP.
<cpaelzer> rbasak: is the standup hangout ok ?
<rbasak> Sure
<cpaelzer> coreycb: in a failing build env you can switch between good/bad behavior by switching /usr/bin/python3 between 3.7 and 3.8
<rbasak> cpaelzer: you mean now or at standup time?
<coreycb> cpaelzer: ok thanks. sorry working on charm release as well.
<coreycb> cpaelzer: just starting to dig in
<cpaelzer> coreycb: no problem, I just though I kept you posted on how far I get working a bit on it in background
<cpaelzer> coreycb: to allow you a head start later on
<cpaelzer> If I find the time to do more I'll ping yu again
<tseliot> tjaalton, hi, I have updated nvidia 430 and 435 for this SRU. The nvidia-settings package is not ready yet, unfortunately
<tseliot> tjaalton, but I think I'll hold that off until the next nvidia update
<tjaalton> tseliot: was this a request to review them? :)
<tseliot> tjaalton, yes please, also, since you asked me about the SRU the other day
<tjaalton> right
<tjaalton> 435 is in new, also the previous upload
<tseliot> tjaalton, oh, so that was never approved
<tjaalton> or looked at
<tseliot> :/
<tseliot> vorlon, ^^
<tjaalton> actually
<tjaalton> I was able to ack it from the new queue, the old one
<tjaalton> now it should show a diff for the new upload :P
<tseliot> good, thanks
<blackboxsw> hi folks: probably a newbie schroot issue... I'm trying to share a directory into my schroot for collecting and sharing data after I destroy/clean the chroot for post-processing during an SRU test.   From `schroot --config` I can see my chroot base directory from the host and I `sudo mkdir ./host-data/subdir  $CHROOT_DIR/data; sudo mount -o bind ./host-data  $CHROOT_DIR/data; schroot -c <my-schroot> -- ls
<blackboxsw> /data`
<blackboxsw> The issue ^ is that I don't see the "subdir" from within the chroot's "/data" and any files i write there are also not persisted outside on the hostfs/host-data dir
<vorlon> tseliot: sorry, I can't tell from context what the request is
<LocutusOfBorg> cpaelzer, did you try the newer vbox for audio issues?
<LocutusOfBorg> I mean, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1840749
<ubottu> Launchpad bug 1840749 in virtualbox (Ubuntu) "Sound problems since 5.2.18" [Wishlist,Confirmed]
<LocutusOfBorg> maybe my prod to upstream worked
<cpaelzer> LocutusOfBorg: I didn't yet as  6.0.12 was failing hard
<cpaelzer> LocutusOfBorg: is there a newer one or a rebuild of 6.0.12 that is worth trying?
<cpaelzer> rbasak: I have tested the uvtool branch, found two needs for fixups but now it is good
<cpaelzer> rbasak: https://code.launchpad.net/~paelzer/uvtool/+git/uvtool/+merge/367641 contains what you need
<cpaelzer> it is your branch + the two fixups
<cpaelzer> That I think you can merge now
<cpaelzer> test results in the MP
<ahasenack> Laney: hi, is there a way to get the logs for the arm64 test that says "always failed" in this bileto ticket? https://bileto.ubuntu.com/excuses/3830/trusty.html
<ahasenack> it's not showing up in /running
<cpaelzer> LocutusOfBorg: I see 6.0.14 I'll give it a try after dinner
<Laney> ahasenack: "(always failed)" there means that there's no previous passes so it can't be a regression no matter what this run results in: http://autopkgtest.ubuntu.com/packages/ubuntu-advantage-tools
<ahasenack> Laney: but is there a current result?
<Laney> I dunno, britney should show that if there is
<ahasenack> maybe I should trigger it again, then the previous run will be this current one, and then it can show me something?
<ahasenack> switched the lander signoff to failed and back to approved
<Laney> how long has it been since it ran?
<ahasenack> Laney: I queued it at 14:51utc
<Laney> from the timestamp in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/trusty/amd64/u/ubuntu-advantage-tools/20191023_151338_fe98b@/log.gz I'm thinkning you should be a little bit more patient
<ahasenack> when it actually started I don't know
<ahasenack> ok
<Laney> you can do some URL hacks though
<Laney> e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/?format=plain&prefix=trusty/
<Laney> leads you to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty-ci-train-ppa-service-3830/trusty/arm64/u/ubuntu-advantage-tools/20191023_153416_fe98b@/log.gz
<ahasenack> so arm64 is done and green
<Laney> looks like it
<Laney> but proposed-migration will get that next time
<ahasenack> ok, thanks
<LocutusOfBorg> cpaelzer, TBH there is also a 5.2.34 in unapproved queue
<LocutusOfBorg> https://launchpad.net/%7Ecostamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages
<LocutusOfBorg> or here
<blackboxsw> ok, figured out the schroot bind mount problem  on my end. I was using mk-sbuild to create the schroot which sources /etc/schroot/sbuild/fstab config to setup mounts within the schroot instead of the typical /etc/schroot/default/fstab. Adding proper bind mount fstab declarations in /etc/schroot/sbuild/fstab got me the proper bind mounted /data dir in the sbuild-created schroot.
<doko> #if !defined(X86) && !defined(X86_64)
<doko> #   if defined(__x86_64__) || defined(__x86_64)
<doko> #       define X86_64
<doko> #   elif defined(__i386__) || defined(__i386) || defined(_M_I86) || defined(_M_IX86)
<doko> #       define I386
<doko> #   else
<doko> #       error Unrecognized architecture!
<doko> #   endif
<doko> #endif
<doko> so 2019 ...
<xnox> followed by inefficient assembly ?
<coreycb> cpaelzer: python-tornado 6.0.3-1 package runs py38 tests successfully on focal without the missing dependency python-sphinxcontrib.asyncio. I'll check with Julien to see if he knows if that package is in the works.
<coreycb> doko: are there any plans for backporting python 3.8 to bionic?
<doko> coreycb: yes, see #1835737. but the interpreter only. and I'm currently busy with the archive opening
<doko> jamespage also asked for it
<coreycb> doko: thanks in advance, that'll be very helpful. he'd mentioned it briefly. and no rush.
<kyrofa> Hey folks, quick question about rmadison: if it says "bionic/universe" it's pretty obvious that's in universe. Can someone confirm that if it just says "bionic" that means it's main? Any other component will be <repo>/<component>?
<infinity> kyrofa: Indeed, no component is main, all others will list one.  See, eg: nvidia-driver-430 in focal/restricted.
<infinity> kyrofa: This mirrors what you find in "Section" in the Packages headers (ie: apt-cache show $foo | grep ^Section), where main just shows the section, and others show component/section.
<infinity> I've been tempted to change rmadison to be explicit about main (not the first time this has been asked :P), but I'm pretty sure that would break any number of home-grown scripts I don't know about, so best not to.
<infinity> kyrofa: Arguably, this makes a lot more sense in Debian, where "main" is "basically everything" and "contrib" and "non-free" are "some bits we don't really care about because ew, licenses". :P
<infinity> But we use the same tools, and I don't think it occurred to any of us that the presentation should be different for Ubuntu until it was too late to change it.
<kyrofa> infinity, makes total sense, thank you!
<mwhudson> xnox, doko: so um, it turns out numpy builds have been ignoring test suite results for years, both in debian and ubuntu :/
<doko> \o/
<mwhudson> i guess it's reportbug -B debian time
<mwhudson> after coffee and meeting
<doko> please both numpy and python-numpy
<mwhudson> ah yeah
<doko> python-numpy (1:1.9.2~rc1-1) experimental; urgency=medium
<doko>   * debian/rules
<doko>     - don't ignore failures when running unittests; Closes: #721100
<mwhudson> well
<mwhudson> let's say i'm not convinced that is true
<xnox> mwhudson:  yes, but this one is very bad =)
<mwhudson> xnox: indeed
<xnox> mwhudson:  as in there clearly is s390x regression there. I did open a bug about it.
<xnox> mwhudson:  you find it, right?
<mwhudson> xnox: yes
<xnox> cool
<xnox> that's all there is for now =)
<mwhudson> well the report yes, bug no
<mwhudson>     x2 = np.array([0.0, 1.0, 2.0], ndmin=2)
<mwhudson> E   ValueError: ndmin bigger than allowable number of dimensions NPY_MAXDIMS (=32)
<mwhudson> uhuh
<mwhudson> at least if it's that simple to reproduce it shouldn't be too hard to diagnose, surely
<xnox> yes
<xnox> clearly 2 is miss-endianed
<xnox> or something else inside
<xnox> git bisect would be nice here
<LocutusOfBorg> mitya57, how is the bootstrap going? looks like idle?
<mwhudson> oh
<mwhudson> -    int ndmin = 0, nd;
<mwhudson> +    int nd;
<mwhudson> +    npy_intp ndmin = 0;
<mwhudson> i presume npy_intp is going to turn out to not be an int
<mwhudson> we can pass a long pointer to something expecting an int* right? it'll be fiiiine
<sarnold> "oh that compiler warning doesn't mean anything go ahead and ignore that"
<mwhudson> well luckily this is all passed to a variadic function
<mwhudson> so no pesky compiler warnings at all!!
<sarnold> ooh clever way to Improve Development Velocity!
<mwhudson> yeah npy_intp ends up being intptr_t
<mwhudson> hey hey guess what the offending commit message is!
<mwhudson> "MAINT: Minor fixes and cleanups"
<sarnold> well discovered :)
<mwhudson> upstream bug https://github.com/numpy/numpy/issues/14767
<mwhudson> testing patch in my ppa now
#ubuntu-devel 2019-10-24
<mwhudson> whyyy does python-twisted in focal-proposed have PyHamcrest in Twisted-18.9.0.egg-info/requires.txt
<mwhudson> rbasak, cpaelzer: https://git.launchpad.net/ubuntu/+source/twisted seems amazingly out of date, is that known?
<mwhudson> oh turns out in a very roundabout way to be because debian is ahead of ubuntu in some case in py2 removal
<mwhudson> sigh
<cpaelzer> mwhudson: yeah the repos are not updated, but it is in the whitelist - I'm doing a test import locally to see if this package stumbles over one of the known issues
<cpaelzer> it seems it wasn't imported after bionic (neither debian nor ubuntu)
<cpaelzer> thanks for the ping mwhudson
<cpaelzer> mwhudson: the reimport showed the signature of the issue which let me identify it as bug 1764814
<ubottu> bug 1764814 in usd-importer "awscli import fails: package_creator.display_name results in HTTP error 410: Gone" [Undecided,New] https://launchpad.net/bugs/1764814
<cpaelzer> so it is a known error
<mwhudson> cpaelzer: ok, thanks for looking
<mitya57> LocutusOfBorg: see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3831/+packages
<LocutusOfBorg> perl is almost ready to migrate FYI
<tseliot> vorlon, the 435 driver is in bionic NEW (not sure if just the binaries now) LP: #1844126
<ubottu> Launchpad bug 1844126 in nvidia-graphics-drivers-435 (Ubuntu Bionic) "Update NVIDIA the 430 series and introduce the 435 series" [Medium,In progress] https://launchpad.net/bugs/1844126
<tjaalton> tseliot: no it isn't?
<tseliot> tjaalton, then it needs to be moved to restricted, since it's in multiverse
<tseliot> (just checked)
<tjaalton> right
<tseliot> vorlon, so, the 435 binaries need to be moved from multiverse to restricted in bionic for LP: #1844126. Help would be welcome. Thanks
<ubottu> Launchpad bug 1844126 in nvidia-graphics-drivers-435 (Ubuntu Bionic) "Update NVIDIA the 430 series and introduce the 435 series" [Medium,In progress] https://launchpad.net/bugs/1844126
<tjaalton> usually #ubuntu-release is for archive things, someone else might act
<tjaalton> since there are other AA's
<tjaalton> tseliot, vorlon: moved now by apw
<seb128> bdmurray, juliank, bug #1849004 seems a regression from the recent xenial SRU
<ubottu> bug 1849004 in update-manager (Ubuntu) "update-manager stop to load update descriptions" [High,Confirmed] https://launchpad.net/bugs/1849004
<tseliot> apw, tjaalton  thanks
<rafaeldtinoco> morning o/
<bdmurray> seb128: noted - thanks
<seb128> bdmurray, hey
<seb128> bdmurray, did you get anywhere with the retracer problem? It's impacting our ability to tell what issues are impacting users on 19.10 :-/
<bdmurray> seb128: Did you hear I'm managing the Foundations team now? I'm a bit busy but hope to dig into it this week. If I got some core files would somebody be interested in trying to retrace them?
<sladen> bdmurray: {congrats,commiserations} !
<seb128> bdmurray, hey, I did, congrats :) It also mean you get the power to assign the work to somebody else in your team right? :p
<bdmurray> sladen: heh
<seb128> bdmurray, I would be happy to put it on a bug report on rls-ee-incoming but that's not targetting a package and we don't really have a workflow for those cases :/
<seb128> bdmurray, I'm happy to help/do some poking/try to retrace locally if that's useful
<bdmurray> seb128: If you could find an "easy" (not too many packages to download) crash that would be a good start.
<seb128> bdmurray, https://errors.ubuntu.com/problem/286e2d516e2a4bf784de60a0f3b2ac3281f80b8b , not trivial list but at least it's not a graphical/gtk application
<bdmurray> seb128: great thanks!
<seb128> np!
<vorlon> oSoMoN: kopano-webapp autopkgtests are failing again in focal because they try to install the chromium-browser deb.  "error: snap "chromium" has "install-snap" change in progress" - could you take a look at this? http://autopkgtest.ubuntu.com/packages/k/kopano-webapp/focal/amd64
<vorlon> oSoMoN: I suspect that what's happening is the deb postinst finishes while the snap transaction is still in progress, so there's a race
<doko> mvo: what is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/c/command-not-found/20191024_083904_d5c23@/log.gz supposed to test? it fails on armhf, but also locally for me ...
<infinity> doko: See the amd64 results.  It should be suggesting to install vim/vim-tiny/etc.
<infinity> Why it's failing on armhf only is a bit of a mystery.
<doko> infinity: would you mind overriding that for now, because a lot of stuff currently fails like that without proposed enabled: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/c/cloudpickle/20191022_091157_d74a8@/log.gz
<infinity> doko: That should be re-triggered with python-apt in the triggers, not overridden.
<infinity> (cloudpickle, that is... No idea what's up with command-not-found)
 * infinity retriggers cloudpickle.
<infinity> Oh, I see what you mean.  You want to override c-n-f to migrate python-apt, so it doesn't need explicit triggering.
<infinity> Yeah, I could maybe get behind that, if we make a note to figure out WTF is wrong with c-n-f.
<doko> yes, exactly
<doko> filing a bug report
<infinity> doko: Done.
<doko> infinity: LP: #1849709
<ubottu> Launchpad bug 1849709 in command-not-found (Ubuntu) "autopkg test only fails on armhf" [Undecided,New] https://launchpad.net/bugs/1849709
<doko> oSoMoN: please could you look at the libreoffice autopkg test failures in focal?
<seb128> bdmurray, bug #1848892 was not mentioned in your meeting today despite being high and rls-ee-incoming tagged, was it overlooked or skipped on purpose?
<ubottu> bug 1848892 in grub2 (Ubuntu) ""error: Unknown TPM error." after upgrading to grub 2.04" [High,Confirmed] https://launchpad.net/bugs/1848892
<bdmurray> seb128: it was overlooked, thanks for bringing it up
<seb128> bdmurray, thx
<oSoMoN> marcustomlinson, do_ko pointed out that the libreoffice autopkgtests started failing reliably in focal, something to look into (http://autopkgtest.ubuntu.com/packages/libreoffice/focal/amd64)
<oSoMoN> vorlon, I'll look into that
<vorlon> oSoMoN: cheers
<vorlon> oSoMoN: btw, do you have any feedback on LP: #1849163?  I have yet to find a way to successfully hack around this
<ubottu> Launchpad bug 1849163 in chromium-browser (Ubuntu) "after deb->snap transition, chromium loses my desktop keybinding theme" [Medium,New] https://launchpad.net/bugs/1849163
<oSoMoN> vorlon, not looked at yet, but it's on my to-do list
<vorlon> ok ta
<oSoMoN> vorlon, re- kopano-webapp, where are you seeing this "error: snap "chromium" has "install-snap" change in progress" ? All I'm seeing is failures because snapd is being killed during installation
<oSoMoN> interestingly I've started seeing similar failures on the automated tests for the chromium snap when they are run on arm64, it looks like a recent change in snapd makes it more memory hungry
<oSoMoN> I'll start a discussion on the snapcraft forum about this
<vorlon> oSoMoN: that particular error message I saw in an arm64 log indeed
<oSoMoN> aha!
<oSoMoN> vorlon, https://forum.snapcraft.io/t/installing-the-chromium-snap-in-test-environment-results-in-snapd-being-oom-killed/13864
<mwhudson> is it possible to get patch(1) to explain _why_ a patch is not applying
<sarnold> whenever I've asked that, looking for trailing spaces has usually been the solution
<sarnold> I've got this in my ~/.vimrc http://paste.ubuntu.com/p/3zWqK6BcdZ/
<sarnold> (yes it's a poor approach to this problem)
<mwhudson> in this case it turned out to be emacs and shell in different directories :(
<sarnold> probably no amount of vim config would help spot that :)
<mwhudson> next stupid question
<mwhudson> quilt push; quilt refresh --> patch is unchanged; quilt pop; dpkg-source -b . --> patches don't apply
<sarnold> ugh that's even worse. I can't recall now what worked for me in the past, but some combination of quilt push -a, quilt pop -a, and maybe application of this alias alias dq='export QUILT_PATCHES=debian/patches'
<mwhudson> ah no this is mismatch between the working directory and the orig
 * mwhudson stabs gbp in the face
<mwhudson> ok now quilt push is failing which is at least consistent
#ubuntu-devel 2019-10-25
<doko> oSoMoN, marcustomlinson: there is now also http://bugs.debian.org/943401
<ubottu> Debian bug 943401 in src:libreoffice "C++ Unit tests failing (Failure instantiating protector" [Serious,Open]
<ddstreet> xnox rbalint you know of any problems that using libnss-resolve might cause?  It seems harmless but it's separated and not installed by default, though I don't see any obvious reason for packaging it separately from the commit history, other than the other libnss plugins were separate at the time as well
<xnox> ddstreet:  so, it alone, doesn't work in chroots because it relies on dbus that doesn't cross chroot boundary. Where as 127.0.0.... forwarder can.
<xnox> ddstreet:  certain protocols that we don't like, are only available over libnss-resolve
<xnox> ddstreet:  so, libnss-resolve alone is not enough / not usable as a system resolver unfortunately. But it is a nice supllementary tool.
<xnox> if one wants lmnnr / zerconf resolution etc.
<xnox> (correct spelling to taste)
<ddstreet> it avoids limitations in the stub resolver as well, espeically on bionic
<xnox> also many applications do not use nss
<xnox> but yeah, it does help apps that do use nss
<doko> mitya57: do you have any idea about https://launchpadlibrarian.net/448402130/buildlog_ubuntu-focal-amd64.fiona_1.8.9-1_BUILDING.txt.gz ?
<doko> failing to find the extensions when trying to build the docs with 3.8, I saw that in another package as well, fornow I have no clue why it is failing ...
<doko> the extensions are built
<doko> ahh, I got it. /usr/share/sphinx/scripts/python3/sphinx-build is 3.7, but the 3.7 extensions are not yet built
* infinity changed the topic of #ubuntu-devel to: Archive: Open | 19.10 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Eoan | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<coreycb> doko: cpaelzer: I've uploaded python-tornado with py38 tests fixed up.
<ricotz> hello, please sync this early -- https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1849300
<ubottu> Launchpad bug 1849300 in vala (Ubuntu) "Sync vala 0.46.3-1 (universe) from Debian unstable (main)" [Undecided,New]
<Pharaoh_Atem> cyphermox: now that Ubuntu 19.10 is out, can you please take a look at this? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1824245/comments/8
<ubottu> Launchpad bug 1824245 in grub2 (Ubuntu Xenial) "Can't create a bootable disk by doing image creation on a loop device" [Medium,Triaged]
#ubuntu-devel 2019-10-26
<cyphermox> Pharaoh_Atem: no, I'm sorry I can't right now. I'm busy with other stuff that must take priority for the time being. I will get to it as soon as I have a chance
<cpaelzer> thanks coreycb
<LocutusOfBorg> Unit193, looks like jbicha syncd assaultcube-data...
<LocutusOfBorg> and assaultcube
<Unit193> Unfortunate.
#ubuntu-devel 2019-10-27
<jbicha> hmm?
<xnox> doko:  i've started boost 1.71 by default test-rebuilds in a bileto PPA and slowly going through the py3.8 / boost-without-py2 fallout and trying to make patches for all the affected packages.
<xnox> I will be uploading them to ubuntu, such that they all become "binNMU" safe to pick up new boost / new python3 / new cmake etc.
<xnox> and removing any hardcoded versions as I go along.
<sdk> Eh, last week, I asked on #ubuntu about a dependency tree problem I encountered with the netinst but no one was able to help. I know it isn't a support channel but I think some people here could help me find the best place to report the problem I'm facing. So here's my problem: On a minimal (with no Desktop Manager) netinst install, if I try to only install xorg, apt wants to install the whole ubuntu desktop (gnome shell
<sdk> and whatnot). However, I only want to install xorg so I can install only a WM like i3 after that. Further, this problem also occurs when I try to install packages like VLC or MPV. Btw, Configuring apt to not install recommended packages isn't an option since I want those packages for most of them. Like I said, there seems to be a problem with the dependency tree.
<jbicha> sdk: there are alternate dependencies available. The default dependencies are set intentionally.
<jbicha> one trick is to use a - suffix to avoid the package you don't want. For instance:
<jbicha> sudo apt install xorg gnome-terminal-
<JanC> you can also use --no-install-recommends for one command
<LocutusOfBorg> Unit193, you might add your patches on top of that so they become debian friendly?
<HokarPokar> Hey. I'm trying to cross-compile a python package for Windows x64. While compiling a source file, the mingw-w64 compiler throws an error "unknow multiarch location for pyconfig.h". I opened up the pyconfig.h and I don't see any includes for Windows target. Am I doing something wrong ?
<HokarPokar> Is the header not provisioned for windows ?
<HokarPokar> Forgot to mention, I'm running all of this from within a virtualenv created for python3.6
<Unit193> LocutusOfBorg: Nah it's not really related to patches, it's the packaging being weird.
