#ubuntu-devel 2005-06-06
<trulux> pitti: heya fellow
<pitti> trulux: you broke my box. twice. :-/
<trulux> pitti: lots of things to talk about :)
<trulux> pitti: what?
<pitti> trulux: more detailled, PAM
<trulux> pitti: PAM from pearls repo???
<pitti> trulux: if I install your PAM packages, I get "sudo: pam_authenticate: Module is unknown" if I try to sudo
<trulux> that's ajmitch's package
<pitti> trulux: yes, from your repo
<pitti> trulux: if I downgrade to breezy's PAM again, everything works
<trulux> pitti: my old pam packages are 0.78 and located at ./ubuntu.wip/
<pitti> trulux: ok, then I blame ajmitch
<trulux> ajmitch's are in the apt-get'able repo, so, I have no competency over them
<trulux> pitti: just don't blame, ask him for it
<pitti> of course :-)
<trulux> blaming is bad, I've learnt that lately.. Just give a **** to it if something goes wrong ;)
<trulux> pitti: now I need a bit of help from you, on the 2.6.12 sources thing
<trulux> pitti: it's still building and I left it doing so before I went to the cinema
<trulux> that was around 21:00
<trulux> looks like a loop
<trulux> or cross compilation
<trulux> either it's the first or the latter, i DON'T CARE, IT JUST SUCKS
<trulux> -ECAPS
<pitti> trulux: why you need to compile the kernel?
<trulux> 'cos I'm on hoary and the headers are not a real package but an hybrid of the sources, or it just looks like that
<pitti> trulux: you should consider that the source package builds many different flavors, that's what might appear as a loop
<pitti> trulux: no, the linux-headers package is a real deb
<trulux> could you send me a sanitized tarball of the direct kernel-headers directory in your /usr/src?
<pitti> trulux: just install it and you get the headers and Makefiles in /usr/src/linux-headers-2.6.12-1
<trulux> right, but it builds out of such thing
<trulux> OK
<trulux> will grab the flippin package
<trulux> today I had migrains again
<trulux> so, don't expect me to be less hard headed today ;)
<trulux> on the other hand, how's going the gcc-3.4 packages with SSP enabled?
<trulux> are they already available?
<trulux> pitti: btw, how was your weekend?
<pitti> trulux: was pretty fine, thanks. Enjoyed the sun, beach, and some BBQ :-)
<pitti> trulux: I don't work on SSP pacakges
<trulux> pitti: better than mine then
<trulux> pitti: well, it was decided in the meeting to enable it in the now deprecated gcc-3.4 ones
<pitti> yes, but I don't have time for that
<trulux> pitti: it's just doing -#
<trulux> de-comment the lines
<trulux> buildd it
<trulux> ;)
<Nafallo> omg! I had 8 dhclient3s running.
* Nafallo grabs bugzilla *
<Nafallo> pitti: when you derootified dhcp3, did you think of /var/run/dhclient.$if.pid?
<pitti> Nafallo: hm, I think so???
<Nafallo> pitti: I get permission denied on creating those files.
<pitti> hm, very odd, it starts as root...
<pitti> Nafallo: please file a bug, I'm too tired for today
<Nafallo> pitti: I think it's related to #10803
<pitti> Nafallo: right, thanks for reassigning
<Nafallo> pitti: np :-).
<JStrike> Urgh. Anybody know what channel sabdfl is on? I want to ask him if I may /msg a question
<pitti> JStrike: how about /msg him _this_ question? :-)
<Kamion> are you sure Mark's the right target for your question?
<JStrike> Then I am still /msg'ing him uninvitedly
<JStrike> Kamion : yep
<JStrike> Some advice really
<Kamion> you might also find mail a better bet
<mdke> if you want to find out what channel someone is on, you can do a /whois on them
<JStrike> I didn't want to send him an email. He probably gets a ton as is, but it seems I might have to
<JStrike> mdke : Thanks
<trulux> pitti: sorry of the delay, needed to get the meds for migrains, could you gimme the url of the headers .deb please?
<JStrike> mdke : Doesn't work
<mdke> JStrike, eh?
<mdke> check your Freenode window
<pitti> trulux: http://archive.ubuntu.com/ubuntu/pool/universe/l/linux-source-2.6.12/linux-headers-2.6.12-1_2.6.11.93-1.1_i386.deb
<trulux> pitti: OK, many thanks, you rock
<trulux> anyone with migrains here?
<Kamion> JStrike: he may not *be* in any channels right now. He's not in the private Canonical channel where he usually sits when he's actually paying attention to IRC.
<pitti> np ;)
<JStrike> mdke : That might be the problem. Using gaim. It did pop up a list with info though, but didn't say what channel he is on  
<mdke> JStrike, he's not on any
<mdke> trulux, computer screens are bad for migrains ;)
<JStrike> mdke : Weird. /msg NickServe info said he was
<Kamion> JStrike: some channels are secret and don't show up on /whois.
<trulux> mdke: mine is a TFT, I'm safe of the sync-of-the-death
<JStrike> Kamion : Oh. Well if he doesn't want to be disturbed, I can wait
<trulux> mdke: though I have good conditions to stand up even with the pain of 40C of fever (well, I can imagine Madonna's tits in my screen, indeed) 
<mdke> JStrike, that will tell you whether a person is online or not, it won't tell you what channels a person is in
<mdke> trulux, you have a 40 fever?
<Kamion> JStrike: busy people often work better with e-mail; they can deal with it in batch mode when they have time, rather than syncing up to somebody else's schedule
<trulux> mdke: not yet
<mdke> trulux, take it easy :)
<trulux> mdke: yeah, chill out around, my good arm chair in fron of the devel box and the wireless keyboard and mouse. it's good :)
<JStrike> mdke : Thanks. Will do
<mdke> ok...
<trulux> hey julien 
<julien> hello
<trulux> pitti: julien is a fellow with a very good background, skillful and willing to work together with me and you. I prefer to let him introduce himself
<trulux> pitti: he's the man we need, someone who can do real work and not bitch around
<pitti> Hi julien, nice to get to know you
<julien> thanks trulux 
<julien> Hi pitti, same here
<trulux> julien: my pleasure, It was great when I heard you were interested, and even more now that we may meet personally in France this summer
<julien> I have dicovered Ubuntu only a few weeks ago and I like the spirit
<trulux> pitti: julien is maybe one of the bests when talking on how NX and W^X principles work
<trulux> pitti: anyways, you'll know in the forthxoming weeks for sure
<pitti> yeah, thanks for the intro
<pitti> julien: would be great to see you rocking here :-)
<pitti> anyway, guys, I need some sleep
<pitti> good night, see you tomorrow morning
<pitti> ... actually _today_ morning :-)
<lifeless> is fl-cow synced from sid to breezy at this point ?
<doko_> lifeless: the ubuntu-changes
<doko_> lifeless: see ubuntu-changes
<lifeless> doko_: ?
<lifeless> is that a list? a webpage? a person ?
<doko_> http://lists.ubuntu.com/archives/breezy-changes/
<doko_> mailing list
<doko_> synced yesterday
<lifeless> cool
<lifeless> thanks
<doko_> one new subscriber ...
<lifeless> ?
<doko_> no more sync questions ;-)
<lifeless> 
<Amaranth> did foo sync? :)
<Amaranth> lifeless: what was that?
<lifeless> my wireless shitting itself
<lifeless> :[
<Amaranth> nice
<Amaranth> 0x7F
* Amaranth tries to remember if that's something important
<lifeless> doko_: probably wont subscribe .. I wouldn't have any need to read it for 99 days out of a hundred
<lifeless> doko_: so the question is .. will I remember it next time ;)
<Amaranth> lifeless: It'll also flood you out.
<Amaranth> lifeless: I subscribed right when the mom got turned back on.
<Amaranth> If I didn't delete mail every 5 minutes my mailbox would explode.
<ajmitch> Amaranth: that's when gmail is useful
<Amaranth> i left it overnight and came back to like 600 emails
<Amaranth> ajmitch: this was gmail
<ajmitch> heh :)
<Amaranth> i hadn't setup a label and filter yet
<Amaranth> after that i didn't bother
<lifeless> if only there was a web page you could put a package name in and get the status of it in each distro
<zul> there is...i forgot what it is called right now
<lifeless> 'package'   'ubuntu/breezy'   'ubuntu/hoary'   'debian/sid'  'debian/sarge'  'redhat'
<zul> bleah redhat
<Amaranth> lifeless: Do you know how many distros there are?
<lifeless> fl-cow    1.4-2   N/A   1.4-3   N/A  1.4-2
<lifeless> Amaranth: yes
* ajmitch could probably do something like that in a few minutes
<lifeless> Amaranth: by all I mean 'the ones soyuz is tracking'
<Amaranth> how can sid have a newer version?
<ajmitch> Amaranth: unmerged changes for ubuntu
<Amaranth> ah
<lifeless> Amaranth: that would indicate something pending sync, or failing to sync
* ajmitch will bbl
<dilinger> mako: *poke*
<jsgotangco> mornin'
<ajmitch> hi jsgotangco 
<jsgotangco> hey ajmitch how was your weekend
<ajmitch> fairly quiet, how about you?
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<jsgotangco> not bad although the rainy season is about to start here
* mode/#ubuntu-devel [-b *!*shermann@server3.servereyes.de]  by daniels
* mode/#ubuntu-devel [-o daniels]  by daniels
<daniels> elmo: if I upload xorg 6.8.2-10hoary1 to hoary-updates (hypothetically), two questions: one, do I need the .orig as well; two, I set the upload target to hoary-updates, right?
<fabbione> morning
<pitti> Morning
<mdz> pitti: morning
<pitti> Hi mdz
<[Chameleon] > what is the proper etiquite for editing items in the bounties list? I'd like to add a suggestion/comment to on eof the listed items.
<[Chameleon] > s/on eof/one of
<mdz> [Chameleon] : email JaneW
<[Chameleon] > mdz: I shall. Thank you.
<sabdfl> mdz: ping
<pitti> Hi sabdfl
<sabdfl> hey guys
<mdz> sabdfl: pong
<sabdfl> getting ready to MAKE THE PITCH at Guadec
* Amaranth is ready to watch
<sabdfl> mdz: quick thought re LaunchpadIntegration before it slips from my addled brain
<sabdfl> again
<fabbione> sabdfl morning 
* mdz braces himself for a requirements change ;-)
<Amaranth> went to bed really early so i could wake up at 1am my time to watch it
<fabbione> hey pitti
<fabbione> hey mdz
<sabdfl> would it be possible for the URL to include locale information?
<mdz> fabbione: morning
<sabdfl> hey fabbione!
<mdz> sabdfl: yeah, should be easy enough
<fabbione> sabdfl: good luck with your talk!
<sabdfl> what's cooking in clusterland?
<sabdfl> mdz: rock
<fabbione> sabdfl: biarch support for ppc64, package splitting, evaluation of impact in main (since we will need part of it in main)
<sabdfl> can i take that off my list of things to convey then? could you add it to sebs list or the spec?
<sabdfl> fabbione: awesome
<sabdfl> impact as in asteroid-rating?
<fabbione> sabdfl: if i will manage we will get the first init scripts too
<fabbione> sabdfl: no, the worst case is one or two packages to rebuild for a soname change
<sabdfl> ok, cool
<fabbione> sabdfl: but i still want to be 200% sure that it will work as it should :)
<fabbione> i am an italian paranoid.. and you know that :)
<sabdfl> parandroid
<fabbione> ahha
<mdz> sabdfl: yeah, I'll transfer it
<ajmitch> hello sabdfl, mdz & others :)
<sabdfl> mdz: thanksvery much
<mdz> sabdfl: which pitch is this one?
<sabdfl> that means we can take the guys straight to a page to translate their app into their language
<jsgotangco> hello
<sabdfl> AND we can display the instructions on that page in their language too :-)
<sabdfl> mdz: Guadec keynote
<sabdfl> will talk about collaboration as a primary objective of the desktop, as well as collaboration on the development side
<sabdfl> along the way singing the praises of baz, rosetta and malone
<mdz> sabdfl: in three-part harmony?
<mdz> four with ubuntu
<sabdfl> i've hacked up a nice little demo of translation sharing in real time between ubuntu and upstream on a local rosetta branch
<sabdfl> so i'm expecting the inevitable demo effect: 500 Application Error
<sabdfl> time to run
<mdz> break a leg
<jsgotangco> break a leg indeed
<ajmitch> hopefully the stream will be watchable from here
<mdz> is anyone here in the audience at guadec?
<ajmitch> I think ogra & seb were yesterday, if they're around
<jsgotangco> thats awesome
<pitti> Hey ajmitch 
<ajmitch> hi pitti 
<ajmitch> how are you?
<pitti> ajmitch: I downloaded the selinux-enabled packages from trulux' archive, but the PAM there broke my box
<ajmitch> pitti: that's no surprise :)
<pitti> ajmitch: fine and I enjoyed the summer during the weekend, thanks :-) and you?
<pitti> ajmitch: erm, if these packages are supposed to wander into main, they *must not* break my or anyone elses's box :-)
<ajmitch> there should be a note that they're not really ready - 0.78 has changed syntax, so anything putting files in /etc/pam.d using @include needs changed iff we're to use it
<pitti> ajmitch: specifically, I can't sudo any more: "sudo: pam_authenticate: Module is unknown"
<pitti> ajmitch: uh, that sounds a bit scary
<ajmitch> interesting, I wonder what happened to that module :)
<ajmitch> pitti: @include was a debian hack, I think, upstream had different ideas
<pitti> ajmitch: is there a safe upgrade path that can be implemented quickly?
<pitti> ajmitch: if not, I'd prefer applying the selinux extensions to the 0.76 version in breezy, if that's possible
<ajmitch> yes, backporting the patch to 0.76
<ajmitch> manoj is working on 0.79 for debian
<ajmitch> which may or may not be ready in time
<pitti> ajmitch: if it's questionable, then I'd feel better with the proven 0.76 version. would porting the selinux stuff be much effor?
<pitti> effort, even
<ajmitch> no, I don't think so
<ajmitch> it consists of changes to one module, and a new pam module
<ajmitch> hi JaneW 
<JaneW> morning ajmitch 
<bob2> aloha, JaneW 
<JaneW> hi bob2 *wave*
<jsgotangco> hello
<pitti> Morning JaneW 
<ajmitch> pitti: not sure where sudo got that pam_authenticate from
<ajmitch> since it doesn't exist in 0.76 either - I think it may have been a config change by me
<pitti> ajmitch: me neither, but after that my box was basically screwed and it wasn't obvious how to fix that
* ajmitch checks up
<ajmitch> sorry about that :)
<pitti> ajmitch: I didn't think about the selinux packages at first, so I thought it was a dist-upgrade breakage
<pitti> ajmitch: no worries, better I find out that 10.000 users :-)
<\sh> morning
<ajmitch> morning \sh 
<ajmitch> pitti: I think >100 angry developers would have found out before then :)
* pitti -> breakfast, cu later
<ajmitch> ok
<ajmitch> pitti: good, looks like selinux support is going into pam upstream (judging by changelog in cvs)
<Treenaks> ooh nice
<ajmitch> 0.76 is from 2002
<pitti> ajmitch: it will be in 0.79?
<ajmitch> pitti: 0.79 was released in march, it will be in 0.80
<ajmitch> it looks like pam_selinux was committed to cvs just 2 weeks ago
* Nafallo says good morning to all!
<trulux> ajmitch: yup, great
<trulux> pitti: will try to port it, I think I did in the past though I missed the patch in my archives
<pitti> Morning trulux 
<pitti> trulux: any success with vsecurity? or any problem you need help with?
<trulux> pitti: heyas fellow
<trulux> pitti: partially, I was horrified with the huge amount of API related errors, I can't imagine why that's so hard broken. with vanilla rc5 it just works out of the box
<trulux> pitti: after fixing the spinlock's pointer issues, I get the vsecurity_ops (the sec_ops struct of LSM) to cause another huge amount of issues
<trulux> pitti: I dunno really what's in Ubuntu sources that breaks it that hard
* pitti neither :-(
<fabbione> ????
<fabbione> trulux, pitti: mind to explain?
<pitti> fabbione: trulux said that the ABI of the 2.6.12rc5 pristine is significantly different from our's (e. g. spinlock functions)
<pitti> Hi carlos
<carlos> pitti, morning
<trulux> pitti: will check later
<trulux> bbl, class
<fabbione> pitti: i find that hard to believe, but we imported a big fat acpi patch that might have these bits...
<fabbione> pitti: but checking is not difficult... just grep in debian/patches
* pitti does
<fabbione> acpi is the only patch that comes to mind
<fabbione> i don't recall changing spinlocks around at all
<pitti> fabbione: we don't patch it, so that's indeed bogus
<pitti> fabbione: linux-source-2.6.12_2.6.11.93.orig.tar.gz is exactly 2.6.12rc5 upstream?
<fabbione> yes
* pitti slaps trulux :-)
<fabbione> given that the incremental diffs are not borked.. it isd
<fabbione> it is
<pitti> fabbione: our main concern was the declaration of spin_lock and spin_unlock(). In 2.6.10 they take a spinlock_t, in 2.6.12 a spinlock_t* (a pointer)
<pitti> fabbione: I don't believe that we patch such a fundamental issue
<pitti> ... and we don't
<fabbione> no we don't
* fabbione slaps trulux with a spinlock cluebat
<fabbione> ;)
<pitti> fabbione: ... but please don't forget to unlock him again :-)
<fabbione> hehehe
<fabbione> humpf.....
<fabbione> hmmmm
<mjg59> mx|gone: Hi
<[Chameleon] > Anybody else in here running Ubuntu on AMD64?
<tfheen> [Chameleon] : yes, why?
<[Chameleon] > I'm running into problems installing packages, mostly 3rd party, with regard to missing dependencies.
<[Chameleon] > I'm just wondering if I should instead go with 32-bit for now... or if maybe I can help get 64-bit packages available?
<[Chameleon] > I'm no pro, but I can learn.
<pitti> trulux: I verified in pristine 2.6.12rc5: "void __lockfunc _spin_lock(spinlock_t *lock)    __acquires(spinlock_t);" -> that _is_ a pointer
<tfheen> [Chameleon] : you're welcome to help out; join #ubuntu-motu if you'd like to do that.  If you give me a bit more precise error than "running into errors", I can try to help you.
<pitti> trulux: (I took 2.6.11 and applied the 2.6.12rc5 patch, just for double-checking)
<[Chameleon] > specifically, I'm looking to install some BreezyBadger stuff from the backports project and they don't seem to offer much for AMD64.
<[Chameleon] > Should I just upgrade to BreezyBadger?
<AndyFitz> Chameleon,  short answer.  no
<jsgotangco> AndyFitz, hey :)
<[Chameleon] > AndyFitz: too immature/unstable at this point?
<AndyFitz> jsgotangco, G'day mate
<tfheen> [Chameleon] : I would recommend asking the backports people; Backports are not supported.
<[Chameleon] > tfheen: OK.
<AndyFitz> [Chameleon] :  yeah pretty much.  you'll have to continuously apt-get dist-upgrade -you   and manually revise the packages .. stuff will break
<[Chameleon] > AndyFitz, tfheen: thanks
<pitti> funny, I just dist-upgraded, now I get a fancy dialog "XSession: [OK] " on login...
<Nafallo> pitti: X working?
<daniels> pitti: yeah, that's gdm being broken
<daniels> i tried to upload it on saturday night, but ended up uploading to unstable
<daniels> let me try again now
<pitti> Nafallo: yes, exactly as before (with broken Alt and Control)
<pitti> 
<daniels> s/unstable/hoary/
<pitti> uh :-)
<pitti> the issue is already known and fixed? Great, daniels! :-)
<Nafallo> pitti: hmm, last time I upgraded the damn thing wouldn't start ;-)
<Treenaks> uploading xorg to unstable would qualify as "bad" :)
<pitti> Nafallo: oh yes, I had to remove the "generic mouse" from the config
<pitti> Treenaks: actually, nowadays it isn't so bad any more since sarge is frozen
<Nafallo> well, locked hoary xorg works ;-)
<Lathiat> daniels: the keyboard stuff unbroken yet?
<daniels> Lathiat: locally, yes
<daniels> Lathiat: sudo ln -s /usr/X11R6/lib/X11/XKeysymDB /usr/lib/X11/XKeysymDB, should get you going in the meantime
<[Chameleon] > tfheen, AndyFitz: I'm going to "downgrade" to the i386 version... the current 64-bit deficiencies are too numerous at this time.
<daniels> pitti: uploaded
<pitti> great
<fabbione> daniels: xorg crack?
* pitti tries new keyboard trick
<fabbione> hmm what was the command to get all packages that builddep on foo?
<fabbione> (today i am really slow :/)
<pitti> daniels: nope, still no luck with above symlink
<pitti> xset: command not found
<pitti> grr
<daniels> pitti: sigh, you probably also need my awesome new libX11
<fabbione> pitti: that's because /usr/bin/X11 is empty
<daniels> pitti: yeah, that's fixed in -21, which I'll upload later
<daniels> fabbione: xorg crack later tonight
<fabbione> daniels: cool
<pitti> neat
<fabbione> pitti: do you happen to remember what is the command to show all the packages that build-dep on foo?
<pitti> fabbione: I wish I ever knew such a command
<pitti> fabbione: so far I used grep-dctrl
<fabbione> ah ok :)
<tfheen> fabbione: grep-dctrl?
<fabbione> yeah whatever is fine...
<pitti> fabbione: apt-cache rbuild-depends would be logical...
<fabbione> i just don't know grep-dctrl sintax :)
<fabbione> pitti: yeah
<pitti> 9955 root      15   0 70988  17m 5168 S 40.2  2.6   1:19.03 Xorg
<pitti> daniels: any idea why X.org constantly uses 40% CPU although I do *nothing*?
<fabbione> pitti: try to restart firefox :)
<fabbione> or mozilla
<fabbione> or thunderbird
<pitti> fabbione: it's not even open
<Treenaks> pitti: stat(); stat(); etc;
<daniels> pitti: no idea, sorry
<pitti> hm, ok
* pitti restarts again
<daniels> pitti: if you have another machine, you could ssh in and break on WaitForSomething with gdb and see what the events out
<daniels> s/out/are/
<daniels> i'm going to get dinner now, i'll be gone for a while
<pitti> bah, system -> logout just hangs now
<pitti> I hate you all
<[Chameleon] > heh
<pitti> (not literally :-) )
* pitti grabs killall
<pitti> ah, better now
<Lathiat> daniels: righton, im not running breezy for the moment anyway, once X has working xkb i'll jump back ship :)
<jdub> daniels: around?
<fabbione> dilinger: ping?
* jdub wonders wtf is going on with X
<jdub> daniels: by default, i'm getting crt output like xinerama
<jdub> daniels: but it's not 1024x768
<jdub> it's another screen
<jdub> can't xrandr it
<jdub> daniels: can i make X not create the other screen, and use i855crt?
<jdub> can i make the second screen do a sensible resolution?
<fabbione> Kamion: is there any reason why ssh in breezy reports a "Killed by signal 1." on each command? (including sftp or scp?)
<Amaranth> pitti: last time system->logout froze on me i had to kill gnome-panel
<Riddell> Mark's talk should be starting soon http://stream.fluendo.com/guadec/konig/
<jdub> Riddell: mark's talk is done :)
<fabbione> jdub: how did it go?
<Amaranth> finished an hour ago
<jdub> fabbione: hrm, ok
<Amaranth> jdub: what room is the topaz stuff going to be in?
<fabbione> only ok?
<jdub> Amaranth: um
<jdub> the big room
<Riddell> aw, did I sleep in?
<Lathiat> stupid dodgy uni wireless is nuking the streams
<Amaranth> Knigshalle?
<jdub> i'm not really sure
<Amaranth> that's the keynote room
<jdub> my talk is at 14:00, and i need daniel to fix my X ;)
<Burgundavia> lol
<Nafallo> I can see seb :-)
<jdub> i'll probably just turn it into images and use someone else's lappy
<Amaranth> you have 2 1/2 hours :)
<Lathiat> jdub: heh
<Lathiat> install hoary in a chroot and run X out of it :P)
<jdub> Lathiat: tempting
<jsgotangco> hey its seb
<opi> morning
<jsgotangco> morning opi
<Nafallo> anyone know what's in the Knig room now?
<spacey> who is talking atm?
<jsgotangco> gdesklets
<Treenaks> jsgotangco: no, who is he :)
<mx|gone> mjg59: still around?
<spacey> hmz stream is gone
<Nafallo> indeed
<jsgotangco> yeah
<mjg59> mx|gone: Hi
<jsgotangco> it just died
<bob2> Nafallo: lightning talks
<bob2> currently gdesklets
<mx|gone> mjg59: how hard would it be to upgrade pbbuttonsd in breezy from 0.6.6 to 0.6.10... 0.6.6 has some problems with kernel 2.6.12 that are solved in the newest version
<Nafallo> bob2: ooh, isn't that supposed to be in Bertha? ;-)
<mjg59> They didn't stream my talk :((((((((
<bob2> mjg59: did they record it?
<mjg59> mx|gone: Uh. It ought to be trivial
<mjg59> mx|gone: (Not my department, though :) )
<Nafallo> mjg59: I was irritated over that yesterday evening :-P
<mjg59> bob2: Nope
<mx|gone> mjg59: yeah, I figured...  I think it's thom's
<mx|gone> mjg59: how "trivial" is it?
<bob2> mjg59: bastards
<mx|gone> just copying the debian directory to the new source dir and updating the changelog?
<mjg59> mx|gone: If the newer version is in sid, it can be done automaticaly on request
<Robot101> mjg59: I would've watched it if it was streamed :(
<mjg59> (IIRC)
<Robot101> the streams are a bit crap today tbh
<mx|gone> mjg59: nope, it's not... they still have 0.6.6
<Robot101> they're crackly and sometimes fail to work
<mjg59> The network is shit today
<Robot101> they worked fine yesterday
<spacey> are they talking english or german ?:P
<Nafallo> Robot101: no, they where crappy yesterday to.
<Robot101> aha, one of these "click around the website" talks :D
<mjg59> Yeah, I might give up on these soon
<Robot101> are you visible on the stream? wave! :D
<mx|gone> mjg59: also, was it you that was working on networkmanager for ubuntu?
<tfheen> mx|gone: no, that's thom
<mjg59> mx|gone: I worked on the spec, but thom is supposed to be implementing it
<mjg59> Robot101: I'm at the front on the left
<mjg59> I just stretched
<Robot101> ... I've been working on it for 3 years ... its still early days ... 
<mjg59> OOH XGL
<bob2> blingtastic.
<mjg59> Indirect rendering
<mjg59> BLING
<bob2> is that seb about to talk?
<Robot101> its buffering now, bah
<Robot101> composting manager
<mjg59> It's fast
* bob2 hands Robot101 an 'o'
<mx|gone> mjg59: pbbuttonsd 0.6.10 is in experimental :)
<Treenaks> bb2: Roboot101?
* bob2 composts Treenaks 
<Robot101> this stream is ghetto
<Treenaks> bob2: composting manager?
<jsgotangco> WOW
<bob2> wow
<bob2> blingarific
<jsgotangco> did you see that
<Robot101> BLING
<Kamion> fabbione: I've been wondering about that. It's not all commands, but some.
<Burgundavia> bling?
<fabbione> Kamion: ok..
<jsgotangco> that is so cool
<Robot101> http://stream.fluendo.com/guadec/konig/audiovideo/java.php
<Kamion> fabbione: version in Debian experimental does it too
<mjg59> Oh god
<jsgotangco> jeezz did you see the corners
<mjg59> I am so glad that Mark isn't here watching this
<Robot101> mjg59: rofl
<jsgotangco> goodness
<bob2> daniels: can we do that for breezy?
<fabbione> Kamion: it's strange, but the command succeed..
<fabbione> Kamion: probably it's something wrong in the exit code?
<Kamion> well, signal 1 is only SIGHUP
<Kamion> my guess is it's a race condition ...
<mjg59> evince now
<Robot101> glbling
<jsgotangco> that was awesome
<Robot101> another inaudible question from the far back left
* Kamion will be out for most of today; my mother's ill, so I'm off to visit
<Robot101> this stream sounds like a steam train... tff tfff tfff tff
<fabbione> Kamion: take care
<jsgotangco> thats funny he's not presenting in full screen mode
<jsgotangco> ahh
<Burgundavia> can someone repost taht link?
<jsgotangco> http://stream.fluendo.com:8900
<jsgotangco> (totem)
<Burgundavia> bah
<Robot101> oh oh oh, someone ask him why in the windows port of gaim, the tooltips NEVER EVER GO AWAY
<mx|gone> jsgotangco: are these the 5 minute speeches?
<Robot101> lightning talks, yeah
<jsgotangco> lightning talks most likely
<mvirkkil> So how do I get x working again in breezy? :-/
<mx|gone> they need to speak up
<jsgotangco> i wanna see jdub
<jsgotangco> heh
<Nafallo> mvirkkil: I've downgraded all packages to hoary and locked the version ;-)
<mvirkkil> Nafallo: That's no fun ;) 
<Nafallo> mvirkkil: but it starts ;-)
<Nafallo> can't play with blam and stuff though :-P
<mvirkkil> Nafallo: Any eta when X will be fixed?
<Nafallo> mvirkkil: ask daniels ;-)
<mx|gone> man, they need to freaking talk into the mic
<jsgotangco> wow he just heard you
<Nafallo> mx|gone: if it wasn't high in the air it would be easier ;-)
<mx|gone> is that john palmeri?
<ogra> yep
<mx|gone> cool
<mx|gone> I'm guessing murray already went
<ogra> which murray ?
<mx|gone> cumming
<ogra> he was here 1/2h ago...
<mx|gone> ah
<Kamion> sheesh, there's an openssh 4.1 release already. I only just packaged 4.0
<fabbione> happy birthday ssh :)
<ogra> heh
<jsgotangco> brb
* [Chameleon]  is away: ZZzzz...
<mkde> awesome
<mkde> free streaming music
<Nafallo> lol
<mkde> top stuff
<mkde> hmm
<mkde> manu chao should steer clear of english i always feel
<pitti> doko: btw, how far is the C++ transition? I'm asking because of psql
<pitti> carlos: here?
<carlos> pitti, hi
<doko> it's done for main
<pitti> doko: cool
<pitti> doko: so it shouldn't interfere too much any more?
<doko> I don't think so
<Nafallo> yay. looks like jdub got it working :-)
<mkde> whats he speaking about?
<Nafallo> mdke: nothing yet. topaz 14:00
<mkde> local time?
<Nafallo> mkde: AFAIK yes.
<Amaranth> in 45 minutes
<mkde> ty
<Amaranth> C++ transition is done in main already?
<Amaranth> wow
<Nafallo> lots of time to make popcorn :-)
<mkde> Nafallo, 45 more minutes of music
<Amaranth> frozen pizza with taco cheese on top for me :)
<Nafallo> mkde: hehe, yea :-)
<mkde> Amaranth, hope you have strong teeth
<Nafallo> lol
<Amaranth> mkde: have you been putting the stream in a little window in the corner of your screen while you code too?
<mkde> *grins*
<mkde> i'm "writing an exam" while listening
<mkde> not getting much done tho
<Amaranth> gets in the way of some of my firefox and gedit tabs
<Amaranth> hehe
<mkde> i can't code sadly
<pitti> jordi: will you upgrade experimental to alsa-lib 1.0.9 soon?
<Nafallo> mdke: ey! did the music stop?
* mdke nods
<Nafallo> :-(
<mdke> Nafallo, we better get our own Manu Chao
<Nafallo> mdke: URL? ;-)
<mdke> erm
<mdke> play.com ?
<mdke> amazon?
<Nafallo> mdke: that's no good streams ;-)
<mdke> Nafallo, i don't have enough upload bw to stream i'm afraid
<mdke> 128 ;)
<Nafallo> mdke: yay. you got actually 4 times less than me :-P
<Nafallo> hmm, 3 and  even
<mdke> :/
<tseng> volunteers to test mono build on ppc?
<pitti> tseng: we can try it in the DC
<tseng> pitti: ok, i will make you a source package
<pitti> tseng: however, if there are any build deps missing, we have to wait until tomorrown, when thom and elmo are back
<pitti> tseng: (today is UK holiday)
<tseng> pitti: the build-deps are ok, i need to test a patch
<tseng> to fix FTBFS
<pitti> tseng: no, I mean if the build deps are not installed in the breezy dchroot
<tseng> oh.
<pitti> tseng: oh, the only thing that is missing is cli-common
<pitti> elmo, thom: can we please have cli-common in davis' breezy dchroot?
<pitti> tseng: if that is done, we are ready to go
<tseng> thanks pitti!
<pitti> tseng: how important is cli-common? I can just throw it against the wall and see which packages are building without it
<tseng> hm we can remove the dh_*cli* calls and build dep for purposes of testing
<pitti> tseng: if you give me a source package I shall test, that's fine
<tseng> oh and ${cli:Depends} from control
<tseng> k 5 minutes
<pitti> no hurry :)
<bob2> hey ogra, how's guadec?
* tfheen waves to ogra 
<Treenaks> ogra? where?
<ogra> ohra waves back
<ogra> oops
<ogra> watch the stream !!
<Treenaks> ohra is an insurance company in .nl
<ogra> jdub announces gnome 3.0
<Treenaks> ogra: which stream?
<Simira> :D
<tfheen> ogra: where are the debs?
<tseng> ogra: bong?
<tfheen> :)
<Treenaks> ogra: knig?
<tseng> what room
<ogra> main...
<ogra> koenigshalle
<ogra> tseng !!!
<tseng> pitti: can you get the orig.tar.gz?
<ogra> i just talked to miguel !!
<tseng> pitti: is uploading slowly
<pitti> tseng: I currently have the breezy version
<ogra> he really likes you
<Treenaks> ogra: and? :)
<tseng> ogra: yes?
<pitti> tseng: I only need diff.gz and dsc
<tseng> hah.
<tseng> pitti: http://tseng.ath.cx/mono/ppctest/
<ogra> and ordered ubuntu t-shirts for the whole of ximian :-D
<tseng> oh man
<ogra> yeah !!
<tseng> we  have tshirts?
<ogra> yep
<tseng> wheres that
<ogra> but mark had only one left
<tseng> oh oh through mark
<ogra> hehe :)
<mkde> we need to start selling ubuntu tshirts
<tseng> mark is talking today, yes?
<mkde> Simira had an idea for it
<ogra> yep
<tseng> :)
<Treenaks> heh... NOT mentioning ubuntu ;)
<ogra> mdke, we already have hem since sydney
<ogra> them even
<mkde> ogra, url?
<tfheen> mkde: Simira is working on a webshop so we'll have good-quality shirts available in Europe.
<tseng> only the devs do ogra
<mkde> tfheen, yeah
<Simira> mkde: I've done some work on it. We're ordering a bunch just after we've moved (so we have a decent address)
<mkde> Simira, awesome! :)
<Treenaks> coolness
<Simira> tfheen: shut up! It will take ages before I have that one online, at least if I'm going to work 50% from August...
<ogra> GO SLASHDOTTING !!!
<ogra> http://stream.fluendo.com:8900/
<ogra> in totem ;)
<Treenaks> ogra: totem in ubuntu is b0rken
<pitti> tseng: building
<tseng> pitti: thanks a ton
<Treenaks> ogra: ask Amaranth 
<ogra> Treenaks, only in breezy
<pitti> tseng: no worries :-)
<Treenaks> ogra: good point
<tseng> jdub++
<Simira> but I'll order enough t-shirts to ship to Europe as well, then... guess it can't cost that much more.
<ogra> but who is crazy enough to use breezy
<Treenaks> ogra: *raises hand*
<tseng> ogra: hell im crazy.
<bob2> Simira: did you like the ones from UDU?
<Amaranth> still building libxine with debugging symbols
<Amaranth> guadec will be over before i finish, at this rate
<Simira> bob2: yup (Tollef got me one). I'm ordering something similar.
<bob2> ah, cool
<Treenaks> I want one! (at least)
<Simira> *sigh*
<Simira> seems I just got myself more voluntary work...
<ogra> tseng, beware !
<ogra> :)
<Treenaks> ArseLinux?
<Simira> well, shipping t-shirts can't be that hard
<bob2> Simira: will they be orderable from outside europe?
<maswan> Simira: it might be lots of work though
<Simira> bob2: I'm sure it will be cheaper to order one from a local profile-stuff-dealer
<bob2> Simira: hmmm, good point
<tfheen> bob2: you should start webshop.ubuntu.co.au (or something) :-)
<bob2> haha
<Treenaks> "i-word" is innovation?
* Treenaks tries to imagine bob2 as a "real" store-owner
<Treenaks> (bricks/mortar)
<tfheen> what is the fish doing at the bottom of the stream?
<Treenaks> tfheen: ogg
<bob2> Treenaks: Papa Sideshow's T-Shirt Emporium
<bob2> tfheen: it's the xiph logo
<Treenaks> bob2: something like that..
<ogra> tfheen, kind of swimmin ?
<tfheen> it looks like a non-blown-up blowfish.
<Simira> huh
<Simira> ogra: not swimming, maybe, if he lies on the bottom?
<ogra> heh
<Simira> ;)
<tfheen> it's static and looks slightly confused.
<torkel> tfheen: wouldn't you be that too listening to jdub? :-)
<Amaranth> finally he said Ubuntu :P
<tfheen> torkel: he doesn't tend to confuse me, since I just respond by throwing crackful ideas at him.
<mkde> gosh he is an excellent speaker
<torkel> tfheen: :-)
<Amaranth> mkde: that's why he's in charge ;)
<bob2> bah, dns is fucked here
<tseng> bob2: dude just use the ip addresses
<bob2> I am, I'm just whinging
<tseng> jeez jdub
<mkde> *laughs*
<hunger> daniels: ping
<daniels> hunger: pong
<daniels> bob2: can we do what for hoary?  indirect rendering?
<Amaranth> indirect rendering? if you're talking mesa that's slow as hell
<Unfrgiven> hi all. i need a hand setting up a breezy chroot from sid. can i use the ubuntu package from the DebootstrapChroot page on sid?
<siretart> Unfrgiven: install the debootstrap package from breezy in your sid by hand. 
<siretart> Unfrgiven: the usual howtos/descriptions should work again
<Unfrgiven> siretart: when you say "by hand" you mean just a "dpkg -i" right? or manually tear apart the .deb? :)
<bob2> Unfrgiven: you need ubuntu's debootstrap, but otherwise it works the same as making a chroot of anything else
<siretart> Unfrgiven: yes. download the package from here: http://packages.ubuntu.com/debootstrap, select breezy, and do the dpkg -i thing :)
<Unfrgiven> bob2: siretart: thanks :)
<mkde> o_O
<trulux> heya
<pitti> Hi trulux 
<bob2> pitti: you're not guadec'ing?
<trulux> pitti: heya fellow, everything going well?
<daniels> pitti: yo
<pitti> trulux: <pitti> trulux: I verified in pristine 2.6.12rc5: "void __lockfunc _spin_lock(spinlock_t *lock)    __acquires(spinlock_t);" -> that _is_ a pointer
* mkde kicks the stream
<pitti> trulux: <pitti> trulux: (I took 2.6.11 and applied the 2.6.12rc5 patch, just for double-checking)
<pitti> daniels: he
<doko> ogra: your attachments for the C++ patches are all unusable ...
<pitti> bob2: no, we start our advanced dancing school today, I rather go to debconf5
<doko> @@ -1,3 +1,9 @@
<doko> +vtk (4.2.6-5ubuntu2) breezy; urgency=low
<doko> +
<doko> +  * CXX transition: rename libvtk4 to libvtk4c2
<doko> +
<doko> + -- Oliver Grawert (ogra) <hostmaster@grawert.net>  Wed, 25 May 2005 13:03:18
<doko> +0200
<doko> +
<trulux> pitti: of course, here we have a pointer too, I said on my blog: http://www.tuxedo-es.org/blog/archives/5-Some-2.6.12-rc5-API-changes-for-the-shake.html
<doko> the timezone is on a new line
<trulux> pitti: then I was on crack or something alike 'cos I was getting really weird shit. I will need to track back the last bk-commits made to the LSM framework 'cos the hook pointers seem fucked up
<ogra> doko, thats what dch -i did, i didnt change it
<ogra> i'll look into it as soon as i'm home... 
<pitti> tseng: uh, FTBFS
<pitti> tseng: I /msg
<trulux> pitti: from that point everything will be much easier, and I need to contact my friend from the Singapore D. of Defense who was working on some fixes for the new subject-based capability granting features
<tseng> pitti: k
<trulux> pitti: any due date?
<bob2> pitti: ah, right
<trulux> pitti: dead timeline or whatever-else you want to call it
<pitti> trulux: well, two weeks? porting the stuff shouldn't be so hard? what do you think?
<trulux> pitti: it would take less than a night if it tells you something ;)
<trulux> pitti: just that I've been preparing other SELinux crack for upstreams, and writing on my LSM 2005 presentation
<bob2> make jdub repeat the question
<bob2> the askwer in inaudible
<trulux> julien: heyas, there? poc code writing today ;)
<bob2> oh, go jdub
<trulux> julien: going to set up my testing box for the purpose, need to contact johnw for the attack vector test framework used in his paper, or I'll need to make our own one
<ogra> bob2, you havent seen the guy who asked... he needed the whole room to ask... walking from left to right 
<bob2> haha
<jordi> pitti: yes
<trulux> pitti: just to confirm, after applying http://pearls.tuxedo-es.org/patches/vsecurity/vsec-0.3-20050526-2.6.12-rc5-fixes.patch and fixing the spinlock issues, what do you get?
<tseng> ogra: beagle 0.0.10!
<ogra> yay !!
<daniels> is mono in main yet? :P
<tseng> i dont think so
<ogra> i suspect i'll have to wait for a fixed firefox until i can test on amd64
<tseng> no
<pitti> trulux: testing, takes a while (I reinstalled my system recently and need a ton of pacakges)
<Nafallo> ogra: together with Xorg that's my issues to ;-).
<ogra> bye, have to move on here
<tseng> cya ogra
<pitti> trulux: verified, I still get the spinlock errors
<pitti> trulux: you have to change them by prepending a & to get a pointer
<pitti> trulux: that worked fine for me
<trulux> right, then it all compiles OK?
<trulux> be sure to check that, or we are in a hurry then
<pitti> trulux: didn't check, I didn't create a patch of my mods
* pitti checks
<trulux> OK, could you just convert the reference to the pointers in the macros and check for compilation?
<trulux> be sure my patch is applied
<pitti> trulux: I just checked out the cvs head
<trulux> ok
<pitti> trulux: http://www.rafb.net/paste/results/qiAJcp44.html
<pitti> trulux: after that it works better
<pitti> but still fails
<pitti> trulux: can you please try to fix the rest, using linux-headers-2.6.12-1?
<pitti> trulux: just remove the "check" dependency of vsec, and do "make KERNEL_DIR=/usr/src/linux-headers-2.6.12-1/"
<trulux> pitti: sure!
<pitti> cool
* ..[topic/#ubuntu-devel:doko] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released! | MOM is awake! | Colony CD 1 released | gcc4 transition finished, breezy probably well broken, uploads of C++ packages in universe restricted
<tseng> daniels: ping?
<daniels> is mono in main yet? :P
<Nafallo> hehe
<tseng> daniels: no but my configure cant find scrnsaver.h right after i tell it exactly where it is
<tseng> daniels: im also going to force you to look at a libgdiplus cairo ftbfs one of these days :P
<daniels> tseng: haha
<daniels> tseng: so, um, with the xss thing, bounce me it
<Unfrgiven> hi again... apologies for repeat from #ubuntu-motu, i didnt get a response there. i've been looking to help out with the c++ transition. i know ive left it pretty late but i havent had much time recently. anyways, here i am. now im a bit confused looking at the wiki pages... it seems like everything on UniverseCxxTransition is done? or am i reading it wrong?
<tseng> dude i would have answered you there the same as here when I came to
<tseng> doko, ajmitch, and ogra are the main guys on that
<Unfrgiven> tseng: sorry mate, as i said i got no response there :/
<tseng> doko just sent a mail out about it I think
* Unfrgiven checks his e-mail....
<tseng> i know i saw one
<tseng> now where is it
<tseng> oh, its in the topic here rather
<Unfrgiven> tseng: ah i see... i was just about to say that i couldn't see anything on the -devel list.
<tseng> sorry im banging my head against beagle to see who gives in first
<tseng> just need to sneak it past a pbuilder now
<Burgundavia> tseng, and think, now you have a new version to play with
<tseng> yes
<tseng> with no dbus
<doko> Unfrgiven, look at https://www.ubuntulinux.org/wiki/CxxLibraryList
<Unfrgiven> doko: anything with an empty "who" column is a todo?
<doko> Unfrgiven: yes
<Unfrgiven> doko: ok excellent... ill get cracking on this tomorrow....
<Unfrgiven> doko: thanks. at least now i can have a crack at it and start transitioning.
<doko> please make an entry for each line, and submit the patch to bugzilla and have it reviewed before you upload
<Unfrgiven> doko: yep will do. i dont have upload permissions anyway :)
<Treenaks> tseng: did you upload 0.0.10 yet? :)
<tseng> Treenaks: almost
<tseng> (gosh)
<Treenaks> \o/
<Burgundavia> Treenaks, you get the award for the first person to ask him if it was uploaded
<Treenaks> Burgundavia: \o/
<tseng> it came out about 20 minutes ago
<Treenaks> tseng: crack-of-the-hour :)
<tseng> 2 hours, im sorry
<tseng> 08:04 -|- trow changed the topic of #dashboard to: www.gnome.org/projects/beagle | New 
<tseng>           Beagle Wiki is up | Beagle 0.0.10 has been released!
<tseng> its now 10:04
<Treenaks> "Angry Aardvark" anyone? :)
<tseng> it needs to pbuilder yet
<Burgundavia> nah, Gibbering Gibbon
<Burgundavia> cause those are noises you are going to make when it total fails
<Burgundavia> s/total/totally
<Treenaks> s/totally/horribly/
<Burgundavia> then we will need a channel for them #ubuntu-you-are-on-total-crack
<Treenaks> #ubuntu-crackheads
<Treenaks> shorter, easier to remember
<Burgundavia> and freenode senses that they are running GG, it redirects them to that
<Burgundavia> from #ubuntu
<bob2> #ubuntu-break-my-gentoo^w-brittle-hold-on-sanity
<tseng> dude freenode /versions me on connect now
<Burgundavia> does everybody
<tseng> bob2: gar someone posted my warty mono repo on a wiki page titled "break my ubuntu"
<tseng> bob2: i was pissed.
<bob2> tseng: haha
<bob2> yeah
<bob2> I tried to have a talk with those people a while ago
<tseng> we are having a meeting on wed. with the backports crew
<tseng> i spoke with them a few days ago
<Treenaks> tseng: do they understand versioning yet?
<tseng> Treenaks: no but they understand why they shouldnt muck around with something the size of mono
<tseng> its a start
<Treenaks> and when will ubuntuguide be fixed, so it'll be less crappy?
<Burgundavia> Treenaks, we are working with the author
<Burgundavia> Treenaks, it is not an easy process
<Treenaks> I get people who follow ubuntuguide in #ubuntu-nl all the time.. and they keep complaining about broken systems
<bob2> Treenaks: synaptic_0.56+revertedto+officialhoary+0.55+cvs20050406-1~5.04ubp1_i386.deb
<KaiL> ...wonderful version number ;)
* Treenaks breaks down in tears at that version
<tseng> the ~ is my personal favorite
<tfheen> bob2: it should grow a +crackcrackcrack in there too
<Burgundavia> tseng, they explain that on their faq
<Burgundavia> to allow "easy" upgrading
<tseng> i understand it
<tseng> i just find it silly
<bob2> it's an improvement on the warty backports
<bob2> which just upped the version number
<bob2> and fucked over people who went to hoary
<Burgundavia> I suppose getting stabbed in the gut is better than being stabbed in the gut AND both your eyes
<tseng> i like my eyes
<tseng> hm libgnomeui dllmap needed
<pitti> daniels: still here?
<Burgundavia> cya ll
<Unfrgiven> good night all....
<mvirkkil>  Is there any quick and easy way to get X working in breezy?
<mvirkkil> I mean the command line rules, but so does a 1600x1200 desktop ;)
<hunger> mvirkkil: That is a question for #ubuntu I think.
<mvirkkil> hunger: Ok. 
<hunger> mvirkkil: ubuntu did setup X automatically for me though.
<hunger> mvirkkil: 1600x1200 (with free ATI drivers).
<mvirkkil> hunger: Are you using an up to date breezy?
<hunger> mvirkkil: Yes.
<mvirkkil> hunger: Would you care to dcc me you xorg.conf (I
<hunger> mvirkkil: breezy has broken X at the moment though (not all keys work)
<mvirkkil> hunger: I had that. Then I rebooted and X would no longer start. Complains about the fixed-font not being found 
<ozamosi> mvirkkil, sounds like this would help you: http://ubuntuforums.org/showpost.php?p=183034&postcount=31
<mvirkkil> ozamosi: hunger helped me. It was just replacing the /usr/lib/X11 with /usr/share/X11 in the fontpaths
<fabbione> chmj: looks ok to me, but please mail kernel-team so that we can do open discussion
<fabbione> ops
<froud> mdz: breezy release schedule, when do you think you will have a list of the gui apps that will go into breezy?
<tseng> froud: you can start with the list thats in hoary
<froud> +?
<tseng> huh?
<froud> yes hoary +?
<tseng> gnome-app-install, some mono stuff
<tseng> nothing is really concrete at this point, i hope you arent publishing something
<froud> I am mostly instersted in the stock install
<froud> no planning
<froud> tseng: just trying to plan
<froud> Ubuntu User Guide and Quick Guide
<froud> need to consider how much addition work
<tseng> nothing major in -desktop
<froud> if not much we can include other work
<froud> in our schedule
<tseng> gnome-app-install seems to be added
<froud> is there a GNOME desktop update planned upstream during now and sept
<tseng> yes of course
<bob2> froud: ubuntu releases one month after the new gnome release
<bob2> it's not a coincidence ;p
<tseng> /usr/bin/ld: /usr/X11R6/lib/libXss.a(XScrnSaver.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
<froud> OK, got it. Thanks
<tseng> /usr/X11R6/lib/libXss.a: could not read symbols: Bad value
<tseng> uh oh ogra
<tseng> ill make him fix this later :P
<tseng> unless its daniels fault
<Amaranth> have any of you tried to use gnome-app-install lately? :)
<tseng> it seems to be less-than-working
<Amaranth> yeah, i just saw that too
<Amaranth> it's because of the new python-xdg
<Amaranth> the way to set the locale and WM changed
<wasabi> Fixed my DMA problems... it is sort of a Ubuntu problem, not hardware.
<Amaranth> we're about to release pyxdg 0.12, i'll look at gnome-app-install afterward
* froud off to feast
<eruin> wasabi, like not loading the correct modules at the right time?
<GheRivero> res people
<fabbione> daniels: you around=?
<bob2> 'tis 0140
<fabbione> tsk
<fabbione> :)
<bob2> hah
<bob2> just because you don't sleep... :)
<fabbione> clearly :)
<mdke> does anyone know what is causing this problem, which a few people seem to be getting recently. Apparently it comes and then goes away on its own:
<mdke> W: GPG error: http://us.archive.ubuntu.com hoary Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<Treenaks> mirror sync in progress maybe?
<mdke> hmm
<SEBest> hello anyone know how to convert an inode number in his fullpath?
<namtrac> daniels: any ETA on next X.org upload?
<\sh> anyone knows, if elmo moved python-qt3 to universe already?
<mdz> \sh: apt-cache should answer that
<mdz> \sh: it's currently in main
<\sh> mdz: saw it already
<mdke> mdz, got 30 secs?
* mdke watches the keynote speech from today at guadec
<mdke> i don't recommend the first 12 or 13 minutes
* mdke waits patiently
<Nafallo> mdke: ehm. the one with Mark Shuttleworth is filmed in the wrong room :-/
<mdke> no way
<mdke> i've waited 13 minutes to find that out?
<mdke> dammit
<Nafallo> I've downloaded the whole thing ;-P
<mdke> damn thats a bummer
<Nafallo> I'm glad I looked at it this morning ;-)
<mdke> any other recordings of it?
<Nafallo> not that I'm aware of.
#ubuntu-devel 2005-06-07
<jp> hi guyz
<jp> why the ubuntu packages are called: ubuntu1 ubuntu2 ubuntu3
<jp> ?
<jp> like education-workstation (0.803ubuntu1
<jp> ?
<KaiL> jp: to stay compatible with debian
<jp> KaiL thanks! :)
<jp> :P
<shaya> something's weird w/ evolution and gedit, ctrl combos seem to be only able to execute one function (evolution any ctrl-combo does ctrl-I import and gedit any contrl combo does ctrl-n new)
<sjmorgan> shaya: https://bugzilla.ubuntu.com/show_bug.cgi?id=10942
<jsgotangco> hola
<timelyx> thom: do you have time to talk about your work on the firefox ubuntu package?
* [Chameleon]  is back (gone 15:58:48)
<daniels> timelyx: it's 0329 where he is
<timelyx> daniels: yes, someone told me that
<timelyx> i'm willing to idle 24 hours for a response
* [Chameleon]  is away: I'm busy
* [Chameleon]  is back (gone 00:00:04)
<lamont> daniels: may I hurt you now?
<lamont>   x11proto-input-dev: Conflicts: libxi-dev (< 6.8.2-16) but 6.8.2-15hppa2 is to be installed
<lamont> xorg is annoying me
<lamont> daniels: so which version of xorg do I need to grab from the morgue and build so that I can build -20?
<fabbione> morning
<fabbione> lamont: according to the sparc logs, i did build -16 and -20 later on
<fabbione> bah everything is stalling around freeglut
<OddAbe19> it doesn't seem to busy in here, but what package provides libpthread.so.0
<OddAbe19> i get debug errors with totem and amarok
<OddAbe19> and that seems to be the culprit
<OddAbe19> hoary and gcc4.0 from backports (i believe)
<bob2> gah
<bob2> backports for development = you lose
<OddAbe19> well, i don't know, but either way
<OddAbe19> what provides that?
<OddAbe19> i've been all over google
<bob2> libc6: /lib/libpthread.so.0
<OddAbe19> synaptic shows gcc at 3.3.5 with 4.0 base installed
<bob2> gcc has nothing to do with running binary packages
<bob2> if you compiled amarok with gcc 4.0 from backports, you've lost anyway
<OddAbe19> na, didn't
<OddAbe19> installed via hoary universe
<OddAbe19> the safe way ;-)
<OddAbe19> i'm reinstalling libc6 now
<OddAbe19> damn, didn't work
<OddAbe19> this is where problems start in the debug 0xb74a4fc1 in __waitpid_nocancel () from /lib/tls/libpthread.so.0
<OddAbe19> #0  0xb74a4fc1 in __waitpid_nocancel () from /lib/tls/libpthread.so.0
<OddAbe19> #1  0xb7f63d97 in libgnomeui_module_info_get ()
<OddAbe19>    from /usr/lib/libgnomeui-2.so.0
<OddAbe19> my whole debug message is here http://home.comcast.net/~amsilveira/totem.txt
<OddAbe19> bob2, do you see anything that's of use?
<bob2> I would assume something from backports fucked up, but I have no idea what
<OddAbe19> damn, i run very little from backports
<OddAbe19> totem is one, i believe
<OddAbe19> firefox is the other
<OddAbe19> now getting /lib/tls/i686/cmov/libpthread.so.0 error, i installed libc-i686 package
<OddAbe19> i'm even getting that error with nautilus
<OddAbe19> meh
<OddAbe19> not much help
<OddAbe19> oh well
<Unfrgiven> ive got a problem with a pacakage i'm testing for the c++ transition. its called ocaml-nox but all other packages that depend on it depend on "ocaml-nox-3.08". in other words the maintainers have put the specific version number in the name. IMO this needs to be changed. does that sound ok? i'm going to remove the version number from the package name and the depends will become "ocaml-nox (>= 3.08)"
<OddAbe19> holy crap, new error root@ubuntu:/usr/local/lib # synaptic
<OddAbe19> synaptic: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
<OddAbe19> this sucks
<OddAbe19> >:-0
<fabbione> mdz: ping?
<fabbione> ah right.. it was bank holidays in the us
<jblack> Yeah. its veterans^wmemorial day.
<mdz> fabbione: yes?
<fabbione> mdz: can we promote ocfs2-tools to supported? and can i pre-seed the redclustersuite for supported? the latter is more important since it ships a build-dep for lvm2
<mdz> fabbione: if they pass review by pitti, yes
<fabbione> lvm2 seems to be the only package that will need a rebuild due to a lib soname change
<fabbione> mdz: pitti already checked redhatcluster and he said there is no security history on it, but i will ask him to review again
<fabbione> mdz: so you are good if pitti agrees on them...
<mdz> yes
<fabbione> by default we don't start the services
<mdz> if they have additional deps or build-deps from universe, of course, those need to be considered as well
<fabbione> so there are no open ports
<mdz> you are only talking about supported, not desktop
<mdz> so open ports are not an issue
<fabbione> mdz: none of them does. we can build them with stuff in main only iirc
<fabbione> mdz: no, not in desktop..
<fabbione> they are for servers and clusters
<fabbione> so it's pointless in desktop
<fabbione> but even if they get installed no daemons are started without user config
<pitti> Good morning
<fabbione> hey pitti
<mdz> night
<fabbione> night mdz
<fabbione> pitti: can you please checkout the code from ocfs2-tools and let me know if it passes your security paranoia checks? mdz asked for your review before promoting it from universe to supported....
<pitti> sleep well, mdz
<pitti> fabbione: alright, will do today
<fabbione> pitti: there is no rush.. just when you have time
<pitti> ok, fine :-)
<fabbione> pitti: soon i will have to push you a bigger package
<fabbione> pitti: for the same reasons
<pitti> fabbione: I *won't* review the kernel :-)
<pitti> (okay, call me lazy...)
<fabbione> pitti: ehehhe
<Treenaks> hmm.. X broken on amd64, powerpc?
<Treenaks> ( http://people.ubuntu.com/~lamont/buildLogs/b/beagle/0.0.10-0ubuntu1/beagle_0.0.10-0ubuntu1_20050530-1609-amd64-failed.gz )
<fabbione> Treenaks: hmmm
<fabbione> that's an interesting error i have seen yesterday
<fabbione> no, it's a wrong call to the linker from beagle
<fabbione> it shouldn't be calling gcc that way
<fabbione> but call ld
<fabbione> that fixed it for me
<fabbione> and the error appears on 64bit system only apparently
<Treenaks> fabbione: also on ppc
<fabbione> Treenaks: ppc is missing b-d
<Treenaks> oh wait yes
<Treenaks> nm
* Treenaks reads buildlog
<Treenaks> anyway - isn't this a bug in gcc, if it works on some archs, but not others?
<fabbione> Treenaks: nope.. it's a wrong call to the linker
<bob2> you shold be using gcc to link
<fabbione> i discussed it yesterday with doko and jbailey 
<bob2> unless you really really know what you're doing
<fabbione> bob2: in that case you need to call LD
<fabbione> or pass all the appropriate options to gcc :)
<bob2> hm
<fabbione> or call gcc in a sane way
<Treenaks> wow.. you also need libmono-dev to be able to run beagled
<Lathiat_> wtf?
<Treenaks> Lathiat_: libMonoPosixHelper.so vs libMonoPosixHelper.so.0
<seb128> hi
<vuntz> hey seb128 
<mvo> hi seb128 
<vuntz> hey mvo 
<mvo> hey vuntz!
<vuntz> so, seb128, where are you? ;-)
<seb128> hey vuntz mvo
<seb128> where is hidding pitti?
<bob2>  6998 root      15   0  728m  74m 3088 S  6.3 15.0   1275:06 Xorg               
<bob2> yay
<seb128> thanks daniels 
<seb128> daniels, if you have a local patch for xorg/xkb you just keep it broken to piss users?
<seb128> oh, pitti
<pitti> Hey seb128
<pitti> seb128: yes, I was absent for a bit
<seb128> np
<seb128> vuntz says than getting all the menu entries for .mo is not an option for gnome-panel
<vuntz> yeah
<pitti> vuntz: Hi
<seb128> cf the mail about languages-packs/desktop files
<vuntz> when creating the menus, opening all the mo files is definitely a bad idea
<vuntz> hey pitti 
<pitti> vuntz: you mean, generally converting desktop files to use gettext?
<vuntz> would the mo files be the applications mo files or other mo files?
<pitti> vuntz: the translations could still be cached if performance is an issue
<pitti> vuntz: the translations of the desktop files are *already* present in the application's mo file
<pitti> vuntz: since most (all?) upstream pacakges call intltool to produce the final .desktop from a .desktop.in and the translations from the po
<vuntz> indeed, but opening all the applications mo files would be really slow
<seb128> but .mo files are bigs
<pitti> vuntz: performance aside, do you agree that reusing the translations from the mo files is a good idea?
<pitti> vuntz: we can cache pre-translated desktop files
<pitti> vuntz: the point is just that packages do not need to deliver translated desktop files any more, so that you could update the translations easily
<vuntz> performance aside, yes, it is probably a good idea
<vuntz> pitti: did you see the recent thread on xdg about this?
<vuntz> markmc proposed another solution
<vuntz> let me find the link
<pitti> vuntz: no, I didn't; is there an URL?
<vuntz> http://lists.freedesktop.org/archives/xdg/2005-May/006920.html
<vuntz> but in fact, I don't know what exact problem you're trying to fix :-)
<pitti> vuntz: funny, merge translations at package installation time was an option we considered
<pitti> vuntz: ok, so a short intro of our goal
<pitti> vuntz: we try to strip off all translations from our application debs
<pitti> vuntz: import them into our translation platform (Rosetta)
<pitti> vuntz: and then ship per-language translation "language packs"
<pitti> vuntz: so users only install the translations they need
<vuntz> ok
<pitti> vuntz: and, more important, we can update the translations after a release without touching application packages
<pitti> vuntz: desktop files do not nicely fit into this concept
<pitti> vuntz: since they contain all translations at once; however, they already use gettext for generating them at build time
<vuntz> so, basically, there are two options: the mo option, and the merging at install time option
<pitti> vuntz: we discussed updating the installed desktop files in the language pack postinstall script
<pitti> vuntz: but that is pretty bad since (1) the installed desktop files would not match the files from the debs (debsums fails, etc.)
<pitti> vuntz: and (2) if a package is updated, you loose the translations since the desktop file is overwritten
<pitti> vuntz: in general, fiddling with files from debs is not an option at least for ubuntu/debian
<vuntz> but what about applications that are not using gettext?
<vuntz> mozilla, eg
<jdub> whiprush: ha ha ha @ blog title
<pitti> vuntz: we _can_ however ship updated desktop files in a parallel hierarchy (let's say /usr/share/applications-langpack)
<pitti> vuntz: and modify gnome to prefer files in this alternative directory
<pitti> vuntz: that's what we would do if the other proposal is not accepted upstream
<pitti> vuntz: other apps: we will eventually change the packaging to produce a pot+po files at package build time
<mdke> jdub, got 30 seconds?
<pitti> vuntz: so that we can import them
<vuntz> pitti: well, you should definitely send your proposal to xdg since it seems other people are trying to find a good solution to this problem
<pitti> vuntz: and also change the packaging to pull updated translations from rosetta and convert them back into OO.o/Mozilla format
<pitti> vuntz: Carlos already approached Sun, I think
<pitti> vuntz: shall we mail the xdg mailing list?
<vuntz> btw, the problem with /usr/share/applications-langpack is that you'll need to modify all the apps that needs to read .desktop files
<vuntz> pitti: I think you should
<pitti> vuntz: there shouldn't be so many
<pitti> vuntz: essentially two packages, I think
<vuntz> at least the panel, bug-buddy, nautilus, gnome-menus and probably a few others :-)
<pitti> oh, ok
<pitti> vuntz: yes, we know that it would be suboptimal and rather hackish, but it is the best we can do without upstream support
<vuntz> all the apps in GNOME that show applications at one moment (nautilus for the mime stuff)
<pitti> vuntz: you are a gnome upstream developer?
<vuntz> pitti: yep
<seb128> he's the gnome-panel maintainer
<vuntz> panel maintainer :-)
<pitti> ah :-)
<jdub> mdke: yeah
<vuntz> but it should really be worked on the xdg level
<vuntz> pitti: I think many people need to fix this
<pitti> vuntz: indeed
<jdub> sun are keen to fix this too
<pitti> vuntz: our change would be entirely optional
<mdke> jdub, great thanks. I was looking for the scripts used on UbuntuWorldWide, do you know if I can find em?
<pitti> vuntz: so it would be fully backwards compatible
<pitti> right, carlos already approached Sun
<pitti> vuntz: we essentially need two things: an additional (optional) field Translation-Domain:
<pitti> and code in the various apps that process desktop files to pull a translation from a mo file if it doesn't already exist in the desktop file
<jdub> mdke: oh, they're custom hacks - when i get home, i'll publish them
<jdub> mdke: if the kde people have already published theirs, grab those ones - i want to switch to them
<jdub> just haven't looked at it yet
<vuntz> pitti: as I said to seb128, I think it's really hard to do this on your side since many apps could add code that opens .desktop files
<mdke> jdub, i'll haven't seen the kde one yet, i'll check it out
<mdke> jdub, i was thinking it would be fun to get locoteams doing it
<pitti> vuntz: yeah, eventually there should be a library that processes these types of files (desktop/server/directory, etc.)
<vuntz> pitti: and it's not easy to find where
<jdub> mdke: they use an older version which is easier to customise
<jdub> mdke: dude, get them all using UbuntuWorldWIde itself - that's the point! :)
<vuntz> pitti: well, in GNOME, there was gnome-desktop, but we're moving to GKeyFile (from glib)
<jdub> mdke: that said, i could pull data from a number of wiki pages
<jdub> but i'm not sure that's a huge benefit
<vuntz> pitti: I imagine you could modify the glib code, but... wow... this would be weird
<mdke> jdub, sure the world one is great
<vuntz> pitti: it's not used only for .desktop
<mdke> jdub, but in the locoteam pages there is a request for teams to find out who lives where in the individual country, i figured a map would be a cool way to do it
<pitti> vuntz: right, as I said, .server, .directory, etc.
<vuntz> pitti: hrm... it's used for all ini-style files, so more than that
<vuntz> jdub: I need this for GNOME-FR too :-)
<jdub> mdke: i'd like to make zoomed views of different regions
<jdub> mdke: but it's hard
<mdke> jdub, *nods*
<dhimass_sby> hi all
<mdke> great talk yesterday btw
<jdub> thanks
<dhimass_sby> help me please
<jdub> seem to be getting good feedback about it
<mdke> :)
<dhimass_sby> anybody help me please
<bob2> dhimass_sby: this is a development channel
<bob2> not a help channel
<bob2> dhimass_sby: #ubuntu
<dhimass_sby> ok. sorry..
<dhimass_sby> bob2: can U tell me where should i ask something?
<bob2> dhimass_sby: #ubuntu
<mdke> jdub, i got the idea from http://www.uk.gnome.org/index.php?page=GnomeUKMarkers
<dhimass_sby> ok's thanks
<Burgundavia> jdub, what is this 10x10 thing?
<mdke> he suggested gnome should get 10% market share by 2010 iirc
<Burgundavia> ok
<jdub> you kinda have to watch the video
<Burgundavia> which talk?
<seb128> jdub's 
<torkel> Burgundavia: http://stream.fluendo.com/archive/6uadec/Jeff_Waugh_-_Project_Topaz.ogg
<Burgundavia> ah
<Burgundavia> seb128, debugging question, have you seen my xchat crash? I am wondering if it is one of my scripts and python 2.4
<seb128> no clue
<seb128> I'm at GUADEC atm
<Burgundavia> ok, I will do some testing
<seb128> and my laptop runs hoary
<jdub> seb128: woos :)
<seb128> which makes jdub happy ;)
<Treenaks> http://kvota.net/guadec/photos/some-happy-geeks.jpg -> Teh Seb?!
<lifeless> mjg59: ping
<mjg59> lif	Hi
<mjg59> lifeless: Gah. Hi.
<lifeless> mjg59: I've got my new X1 lappy :)
<lifeless> are you interested in acpi issues ;0
<mjg59> lifeless: Hngh.
<mjg59> lifeless: Shoot :)
<jsgotangco> hey its seb
<lifeless> it doesn't notice battery replacement
<mjg59> Fun
<lifeless> I filed that on bugzilla 
<lifeless> as I was sure it wasn't a PEBCAK 
<lifeless> restarting acpid 'fixes' it
<lifeless> there is a suspend key which works, and a hibernate which doesn't 
<mjg59> It's probably the rmmod of battery
<mjg59> Ok. Does pressing the hibernate button generate a keycode and/or a message in dmesg?
<lifeless> or battery isn't probing on resume
<lifeless> yes
<lifeless> atkbd.c: Unknown key pressed (translated set 2, code 0x8a on isa0060/serio0).
<lifeless> atkbd.c: Use 'setkeycodes e00a <keycode>' to make it known.
<mjg59> Right. Excellent.
<mjg59> Could you possibly add a wiki page with a list of the keycodes the hotkeys generate?
<lifeless> sure, any specific page ?
<mjg59> DellHotkeys? Something like that
<lifeless> ok
<lifeless> tomorrow probly
<mjg59> It just makes things easier to track
<mjg59> Sure, no problem
<lifeless> there are keys that don't appear to be noticed or obeatkbd.c: Unknown key pressed (translated set 2, code 0x8a on isa0060/serio0).
<lifeless> atkbd.c: Use 'setkeycodes e00a <keycode>' to make it known.
<lifeless> obeyed
<lifeless> bah
<Treenaks> I have a few of those as well on my Acer laptop
<mjg59> Treenaks: The key word there is "Acer"
<lifeless> hmm, or I suck
* mjg59 explodificates Acer
<lifeless> they are found when I try now :|
<lifeless> theres a 'battery status' one which is I presume a dell special
<mjg59> lifeless: So except for hotkeys and the lack of battery update, it all works?
<lifeless> essentially yes
<lifeless> the other fuckage is not acpi - its X
<mdke> mjg59, i have some keys on my compaq that don't show up in xev, can you tell me where to report it? on the wiki? xorg bugzilla?
<lifeless> I'm hoping daniels will be at LUV and I can pin him down ;0
<lifeless> mjg59: oh there is something, what is laptopmode meant to do w.r.t. powering down the laptop drive etc
<mjg59> mdke: Do they appear in dmesg?
<mjg59> lifeless: laptop mode doesn't spin down the disk itself
<mdke> mjg59, i don't know, i just tried running xev then pressing them, nothing
<mjg59> mdke: Run dmesg and see
<mdke> mjg59, i haven't got the machine right now
<mdke> but i will
<mjg59> mdke: Ok. When you have the machine, do that
<mdke> cool
<lifeless> mjg59: or set noatime or other such foo-niceties ?
<lifeless> mjg59: I'm getting 2/3rd what dell reckon the batteries should deliver new
<mjg59> lifeless: To a large extent, that's Linux driver support
<Treenaks> mjg59: what's the problem with Acer? (except for the battery crap)
<lifeless> mjg59: the cpu happy scales down to 600Mhz
<mjg59> Treenaks: They make shit laptops
<lifeless> ;)
<mjg59> And they change the design of their shit laptops every 3 weeks
<lifeless> mjg59: have I show you the jpg ?
<mjg59> lifeless: Nope
<Treenaks> mjg59: shit in the hardware of software sense of the word?
<lifeless> http://people.ubuntu.com/~robertc/newandold.jpg
<lifeless> the old being the hovercraft
<mjg59> Treenaks: Given a choice between 10 Acers and a 2 year old IBM, I'd go with the IBM
<jdub> hey
<jdub> so
<mjg59> lifeless: Hahahahahaha
<jdub> i have heaps of dhclient3 processes sitting around
<mjg59> Oh, are there any Acer employees in here?
<lifeless> mjg59: yeah, it is a little ike that ;)
<mjg59> jdub: Ungk.
<Treenaks> mjg59: well, my bank account disagreed, so meh
<mjg59> jdub: They're probably failing to get killed when the interfaces are ifdowned on suspend
<mjg59> And then a new one gets spawned on resume
<mjg59> Bugger
<jdub> have way too many for that
<mjg59> How many is way too many?
<mjg59> When was the last time you actually rebooted?
<jdub> like, ten
<jdub> last time i killed all of them was yesterday
<jdub> ;-)
<mjg59> And how many times have you suspended since then?
<fabbione> hey sabdfl 
<sabdfl> hey fabbione!
<sabdfl> morning ladies and gents
<\sh> morning sabdfl 
<Treenaks> hi sabdfl 
<fabbione> Source: rhcluster
<fabbione> Binary: libmagma-dev ccs gnbd-server libdlm1 rhcluster libiddev-dev fence magma-plugins fence-gnbd cman gulm libgulm-dev rgmanager libgulm1 gfs-tools libmagma
<fabbione> 1 magma gnbd-client libdlm-dev libccs-dev
<fabbione> uhuuhuh
<fabbione> it's coming! it's coming!
<fabbione> MUHA MUHA MUHA
* fabbione grins
<sabdfl> fabbione: have you heard of the HP SSI clustering project?
<Treenaks> fabbione: will we release it before Redhat? :)
<fabbione> sabdfl: yeps.. didn't dig into it yet...
<fabbione> Treenaks: ehhee
<fabbione> sabdfl: i did check http://gridengine.sunsource.net/ yesterday...
<fabbione> sabdfl: sun cluster grid is pretty famous afaik
<fabbione> but i will look at SSI as soon as i will do my first rhcluster upload
<jdub> probably twice
<fabbione> jdub: probably more :)
<fabbione> the init scripts are a royal pain
<fabbione> i think it's the last hacking in userland i need to do
<\sh> sabdfl: are u at the guardec or just left those "geeks" alone? :)
<mantiena> Hi all
<bob2> good lord
<bob2> how do I delete a file from nautilus's cd burning window?
<Treenaks> bob2: drag to trash
<bob2> using the gui hangs nautilus, since the smb share is inaccessible atm
<Treenaks> \o/
<Treenaks> uh.. where would nautilus store that data..
<Treenaks> some gconf key? ~/.nautilus?
<bob2> not in ~/.nautilus
<bob2> how utterly broken
* Treenaks hears the sound of bugs being filed
<bob2> and htf do I delete a file with nautilus?
<Treenaks> bob2: move to trash, empty trash
<bob2> that's the only way?
<bob2> dear nautilus,
<bob2> you suck
<bob2> love, rob
<Treenaks> bob2: you can set some preference afaik
<Treenaks> bob2: to "Add a delete function that circumvents the trashcan"
<Treenaks> bob2: and then you can rightclick -> Delete
<Treenaks> at least, in hoary
<bob2> hm
<bob2> which still hangs
<bob2> but thanks
<bob2> so, the trick was, pkill nautilus, then quickly umount the broken share
<Treenaks> scary
<opi> morning :-)
<thoreauputic> can we get an op to silence "ubuntufans" in #ubuntu please?
* hunger just wasted a night fixing up after a failed win update.
<mantiena> Kamion: hi are you online ?
<jdub> GOOD MORNING FREEDOM LOVERS
<ajmitch> hey jeff
<pitti> Hey screamin' jdub, 
<pitti> jdub: the conf is very loud? :-)
<mvo> hey jdub 
<jdub> :-)
<Treenaks> jdub: reached 10% yet? :)
<jdub> ;-)
<Kamion> mantiena: yes
<mvo> anyone familiar with libscim? I got a crash report that looks like it's caused by it
<mantiena> mvo: I'm not famialiar :(
<mantiena> Kamion: I wanna talk with you about fixing ubuntu bug #669
<Kamion> mantiena: I've just replied to the bug
<mantiena> ok :)
<Kamion> one forum at once, please :)
<mantiena> yes
<mantiena> Kamion: are there any preliminary realization of partitionprober now?
<Kamion> mantiena: read the end of the spec I referred you to
<Kamion> it's done for the moment, I just need to figure out how to hook it into partman and casper
<Kamion> though partconf-find-partitions doesn't handle labels yet
<pitti> sjoerd: I just sent a mail to ubuntu-devel, cc'ed to you which should interest you as well (g-v-m reimplementation/redesign)
<seb128> waouh
<koke> about GnomePanelEnhancements, for the menu...
<seb128> pitti, you are reworking everything, audio, sql, desktop, translations... :)
<seb128> there is no panel enhancements spec
<koke> is this what you are talking about?... http://koke.amedias.org/img/panel-menu-mockup.png
<pitti> seb128: well, read the main, this hotplug crap really needs a redesign from the ground up :-(
<seb128> that's random idea
<seb128> pitti, not get it yet
<seb128> I'll
<pitti> seb128: I rework the desktop? I thought that was your job? :-)
<seb128> DOH
<seb128> (didn't work)
<seb128> koke, upstream is no interested by such change now
<seb128> and the code is likely to change soon
<mvo> pitti: thanks for your mail about the g-v-m / event-notifier ideas!
<jordi> gnome-menu code to change again?
<jordi> yay.
<pitti> mvo: no problem, this is a long-standing itch...
<pitti> mvo: I think we two already developed some good ideas
<pitti> mvo: it's just ENOTIME
<seb128> jordi, no
<seb128> jordi, why?
<seb128> jordi, panel != menu
<jordi> oh, missunderstood
<mvo> pitti: yes :/ I'll reply and send the url to the wiki page that was created as a result of our discussion
<jordi> seb128: hmm, if you want to save mlview you really need to fix it now
<pitti> mvo: oh right, I completely forgot about that
<jordi> seb128: I tried to find the fix last night on CVS but the changelog wasn't too helpful :(
<jordi> so I went to bed
<seb128> jordi, drop it, I'm at GUADEC with no Debian and no GPG key
<pitti> seb128: you don't have it on an encrypted stick? :-)
<seb128> I'm running hoary :)
<pitti> oh, right
<seb128> xorg on breezy is not go
<Lathiat_> indeed
<seb128> jdub had to use my laptop to get a video output working :p
<jordi> seb128: if you can find the CVS or dodji can give it to you I'd prepare a NMU
<Lathiat_> daniels: speaking of which, that xkb symlink doesnt help, so if you want some debug voodoo let me know
<seb128> Dodji is away for VAC atm I think
<seb128> bad timing
<seb128> speaking about xkb bug?
<seb128> according to the bugzilla comment he has a working local patch
<seb128> but he seems to enjoy annoy people instead of using it :/
<Lathiat_> seb128: right, but he also gave me a symlink that should help and it doesnt so *shrug* not sure if its the same issue or what
<mantiena> Kamion: partconf-find-partitions 1.0.8 contains latest improvements or these improvements are available only in CVS ?
<Kamion> the former, and partconf's in svn not CVS
<vuntz> hi ogra 
<Kamion> I'm working on it now to remove reliance on devfs paths
<ogra> hey vuntz 
<ogra> :)
<fabbione> YAY for Kamion!
<fabbione> DEVFS MUST DIE!
<ogra> geez, 380 mails in ubuntu-users in 3 days i didnt read it
<mantiena> Kamion: when you planing to finish this ? I wanna make working partition detection in live CD this week
<Kamion> mantiena: no idea
<Kamion> mantiena: you don't need this latest change though
<Kamion> fabbione: er - devfs paths not devfs :)
<mvo> hey ogra 
<Kamion> mantiena: why the arbitrary deadline?
<fabbione> Kamion: i will kill devfs :) just make sure it's not required anymore ;)
<mantiena> Kamion: so, I could simply take partconf-find-partitions 1.0.8 and try to integrate it into casper ?
<Kamion> mantiena: depend on it
<Kamion> you don't need to take it
<seb128> pitti, I agree with your mail 
<mantiena> Kamion: yes, of course, I don't want to include it into casper udeb :)
<mantiena> deadline is for me - I released Baltix 0.8 beta (look at ftp://ftp.akl.lt/Linux/Baltix/Baltix-readme.txt ) was released 2 months ago, so I really need to upload a candidate version, but in this version I need to return automounting of existing partitions, because it was in all Baltix versions until I moved to Ubuntu live CD technology
<mantiena> s/was released//
<camilotelles>  Kamion: any news about UE?
<Kamion> ok
<Kamion> camilotelles: no
<Kamion> camilotelles: it's been the weekend and I've been visiting a sick parent
<mantiena> camilotelles: you are about Ubuntu Express ?
<camilotelles> mantiena: yes. 
<mantiena> camilotelles: I wrote live-installer udeb component (look at specifications here - http://www.gnoppix.org/wiki/index.php/LiveCDInstaller and sources+binary is here - ftp://ftp.akl.lt/users/mantas/live-installer/ )
<camilotelles> mantiena: We tried to do something, but our approach is not good enough.
<doko> elmo, seb128: gnome-doc-utils b-d on docbook2x, which is in universe. can the b-d be dropped, or should docbook2x prompted?
<mantiena> camilotelles: with help of this live-installer component you can simply install Ubuntu live CD to hard disk - just included all needed ubuntu-installer's and live-installer's udeb's into live CD (except of course base-installer udeb) and also use patch'ed casper from ftp://ftp.akl.lt/users/mantas/casper/
<camilotelles> mantiena: I taked a look to the spec page, looks good.
<Kamion> mantiena: I think a lot of that component can be deleted - the core looks reasonable though
<Kamion> as in there's a bunch of stuff left over from base-installer
<mantiena> camilotelles: while you tried I simply wrote working live-installer ;)
<camilotelles> mantiena: sure ;)
<mantiena> Kamion: yes, there are lots of commented code
<mantiena> Kamion: but live-installer works, and I think it's most important ;)
<mantiena> Now I can simply type install in Baltix 0.8beta and install live CD to hard disk :)
<Kamion> mantiena: have you reused the bootloader installer code from d-i?
<Kamion> if so, what approach did you take?
<seb128> doko,  I think the b-d could be dropped, need to mail the debian maintainer about thos
<seb128> this
<mantiena> Kamion: live-installer simply does the same like base-installer from d-i, so I don't need to modify any other d-i component's except casper ;)
<herzi> doko: ping
<Kamion> in that case how do you return control to d-i?
<ogra> moin herzi ;)
<herzi> hi ogra
<doko> herzi: pong
<doko> ogra: heh, time for CXX work?
<ogra> doko, soon....(still working through my mail backlog) 
<Kamion>  find-parts.c |  108 +++++++++--------------------------------------------------
<Kamion>  1 files changed, 17 insertions(+), 91 deletions(-)
<Kamion> I like diffstats like that
<\sh> ogra: mail is not important...u can do it while u r compiling ;)
<mantiena> Kamion: I don't need to return control to d-i, because I never take control from d-i ;)
<mvo> Kamion++
<fabbione> Kamion: it's enough that one of the insert is NOT a call to rm -rf / :P
<Kamion> mantiena: oh, you changed casper to just chroot rather than pivot?
<herzi> doko: did you find time for the gdb powerpc problem?
<ogra> \sh, i dont need to compile.... there are errors in my changelog entrys (no idea why dch wrapped the timestamps)
<mantiena> Kamion: base-installer doesn't need to return control to d-i, with live-installer is the same ;)
<Kamion> mantiena: I guess that increases memory consumption a fair bit though
<Kamion> mantiena: yes, I know, but casper does
<doko> herzi: the fix isn't included upstream, AFAIK.
<mantiena> Kamion: I just told that for correctly working live installer you need patched casper ;)
<Kamion> mantiena: yes, I hadn't looked at the patch
<Kamion> mantiena: unfortunately I'm fairly sure mdz doesn't want to do that with mainline casper, which is why we've been exploring other options
<Kamion> (but a live-installer component or similar is certainly one of the required pieces)
<mantiena> Kamion: it's very simple patch - I added one more debconf variable into casper (install-mode) and if this is set to true, then casper doesn't boot into filesystem.cloop, look at ftp://ftp.akl.lt/users/mantas/casper/
<mantiena> I contacted with mdz and it seems he is not agains my idea ;)
<Kamion> he isn't? that's surprising, I'd discussed something similar before and he didn't want it for UbuntuExpress ...
<Kamion> we can talk about that later
<mantiena> Kamion: yes, when mdz will be online :)
<Kamion> it would certainly make the code a lot easier, but it means that the user has to reboot the live CD into a non-default mode in order to do the install, rather than simply clicking on a menu entry
<mantiena> Kamion: that's is why Baltix 0.8 beta currently has 2 installers - one text mode installer, which is started by typing 'install' in isolinux prompt and one graphical installer with can be started from running live CD ;)
<mantiena> it would be nice to unite these into one, but this work is too big for me alone 
<camilotelles> mantiena: if you do the framework we can try to contribute.
<mantiena> but current situation isn't bad - previous week I got small job to make automatic linux installation for big Lithuanian computers manufacturer and it seems ubuntu-installer + live-installer component fits fine here, I just need to preseed some debconf values ;)
<mantiena> camilotelles: I think ubuntu developers are better for doing the framework ;-) I just wrote working live-installer and sligthly patched casper, it would be very nice if mdz would accept my patch ;)
<camilotelles> mantiena: sure.
<tseng|work> OEMInstaller is a breezy goal
<pitti> Treenaks: do you have some time to debug #11207?
<tseng|work> so it would be great if you could join in on that
<pitti> Treenaks: i. e. manual mount with pmount /dev/sda1 works?
<Treenaks> pitti: tonight maybe
<pitti> Treenaks: ok, in the meantime I upload a version with enhanced debugging output
<Treenaks> pitti: would building with DEB_BUILD_OPTIONS=nostrip be enough?
<Treenaks> ah ok
<pitti> Treenaks: I usually do stuff in the build-tree and call g-v-m directly from there
<pitti> Treenaks: so I don't need to rebuild the debs to test a change
<mantiena> tseng|work: hehe, ok ;)
<pitti> Treenaks: DEB_BUILD_OPTIONS=noopt should work
<Treenaks> pitti: ok
<mjg59> Oh, rock
<mjg59> Maemo has a obex gnome-vfs module
<Treenaks> mjg59: wow
<fabbione> hey mjg59 
<fabbione> mjg59: did you notice by any chance that 12rc5 seems to have a slower disk I/O? or is it just me on crack?
<mjg59> I haven't noticed, I'm afraid
<fabbione> mjg59: ok.. good :)
<mjg59> And Nokia is giving 50,000 to the gnome foundation
<Lathiat_> sweet
<Treenaks> phat
<jordi> w
<ogra> mjg59, hey, the wiki gets slashdotted now :)
<Treenaks> ogra: "well duh" :)
<ogra> heh
<Treenaks> ogra: still only 4 of us on there
* ogra counts 5
<ogra> but adding myself needed 3 trys.... my changes were just swallowed without conflict... strange
<Treenaks> ogra: yeah, I had to try 3 times as well
<ogra> that shouldnt happen....
<ogra> there should at least be a conflict, i dont want this to happen with a 100 line text i wrote
<mjg59> ogra: I got two notification mails for you
<ogra> hmm
* ogra looks where to file a bug for the wiki
<Treenaks> ogra: bugzilla?
<ogra> Treenaks, yes
<\sh> wiki slashdotted?
<Treenaks> slashdot wikified would be cooler ;)
<ogra> lol
<fabbione> uh? where has been /.ed?
<Treenaks> fabbione: no, mjg59 mailed -devel
<fabbione> no wonder :)
<ogra> :)
<pitti> Treenaks: I just uploaded a new g-v-m which could fix your bugs
<Treenaks> pitti: I'll try tonight
<pitti> oh, ogra, I just remembered that the hwdb patches need to be applied to breezy...
<pitti> ogra: do you have time to do that?
<Lathiat_> whats wiki  markup for a code block?
<Kamion> {{{ ... }}}
<ogra> pitti, i'll do that during this week, is hal ready so far (still go no working X server on my desktop but didnt upgrade the last 5 days or so)
<pitti> ogra: oh, it's ready for weeks now (modulo bugs :-) )
<ogra> (and my laptop is running hoary)
<ogra> oki
<pitti> ogra: my laptop, too :-) I just have breezy on my desktop
<ogra> i'll add them one by one then :)
<pitti> ogra: I think the actual new functions should stay the same, you just have to put them into a separate callout
<ogra> pitti, yep and in the linux2 direcory now :)
<bob2> the eclipse ui is pretty cluttered
<Robot101> Kamion: ping
<Kamion> Robot101: (handled on #debian-devel, I assume)
<Lathiat_> How do i insert a literal ` in the wiki?
<spiv> {{{`}}} would probably do it.
<spiv> (in monospace, though)
<Lathiat_> {{{}}} seems to put it in a block?
<Lathiat_> i dont want that? :)
<spiv> If there's no newlines in {{{}}}, it will be inline.
<spiv> (For moin markup anyway... I assume that's what we're talking about :)
<Lathiat_> oh ok
<Robot101> Kamion: yeah, cheers :)
<Lathiat_> sigh the wiki is so slow
<opi> Wiki related question: how do I put my code snipplet int this dotted area?
<opi> since HTML is not allowed, I can not use <div> :)
<spiv> opi: With moin markup, code snippets should be formatted as {{{ code snippet }}}.
<mvo> mjg59: should I report acpi failure for laptops against the "acpi-support" pacakge? 
<mjg59> mvo: What's the failure?
<mvo> mjg59: s3/s4 not working
<mjg59> mvo: Not working how?
<mvo> mjg59: I get the machine tomorrow, right now I'm just talking to a friend over jabber. s4 seems to bring the machine into sleep but when it comes back up it does not suspsend but do a normal boot. 
<sjoerd> pitti: nice, cool
<mjg59> mvo: Without knowing more about the issue, I can't say what it should be filed against
<mjg59> Pick something that looks likely and cc: me, and we can reassign it if necessary
<mvo> mjg59: ok, thanks
<Kamion> woo, I think I have MountingHDDFilesystems working for the install CD
<ogra> yay
<opi> spiv: thanks! :)
<pitti> Kamion: great :-)
<mantiena> Kamion: you have MountingHDDFilesystems working for the install CD ? could you show me the code ?
<lamont> beagle has non-PIC in shlibs too...
<lamont> fabbione: linking with ld is wrong.
<doko> tseng: ping
<lamont> that is, linking C with ld is wrong.  linking C++ with gcc is also wrong
<Kamion> mantiena: the only parts of the code I haven't checked in yet are the partman-specific integration bits, that won't be much use to you anyway ...
<Kamion> mantiena: but that's http://riva.ucam.org/~cjwatson/tmp/auto_mountpoints
<mantiena> Kamion: thank you
<Kamion> the live CD should be trivial, I'm looking at that now
<mantiena> Kamion: cool, then I will learn baz and try to upload my casper improvements to mdz (he asked me several weeks ago for this)
<Kamion> s/weeks/months/
<mantiena> Kamion: hehe, not more than 2 months, so I vote for weeks ;)
<stockholm> ogra: did you register for debconf and the debian-edu hacking?
<stockholm> or edubuntu hacking, if you want
<mantiena> where seb128 disappeared ?
<ogra> mantiena, he is at guadec.... not always online if the listens to talks
<ogra> (or probably just on the train back atm.)
<Nafallo> Mithrandir: morning :-)
<Mithrandir> hi Nafallo 
<thom> Mithrandir: firefox looks to be much better on amd64 with gcc-3.4
<Mithrandir> thom: like, not crashing if you move your mouse?
<thom> yeah, like that
<Nafallo> yay!
<Nafallo> thom: that's _really_ good news :-)
<ogra> hey thom no guadec for you ?
<Mithrandir> thom: so we're just going to go with gcc-3.4 for now and wait until somebody else cleans up the mess?
<ogra> i thought you planned to come too
<Mithrandir> hi ogra
<ogra> hey Mithrandir 
<Mithrandir> how's gu6dec?
<thom> ogra: sadly not
<thom> Mithrandir: yeah, i think so
<ogra> Mithrandir, i'm already home again... but it was great :)
<Mithrandir> ogra: it's until tomorrow, isn't it?
<ogra> nope until today
<Nafallo> ogra: you're going home instead of the parties? ;-)
<wasabi_> Some sort of postinst hook which recycled metacity/gnome-panel/nautilus/etc would be interesting.
<wasabi_> </random idea>
<lamont>  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -I../../include -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT @birnan@ -I/usr/include/X11/Xtrans
* lamont giggles at libice
<Kamion> oh god I hate shadow merges
<lamont> Kamion: much prefer the real ones? :-)
<lamont> daniels: libice needs your love
<lamont> redland-bindings needs python love, it appears
<lamont> checking Evolution version... configure: error: Evolution development libraries not installed
<lamont> ximian-connector needs love, too.
* mvo is away for ~2h to play hockey
<daniels> lamont: libice needs the version of xtrans I just uploaded to build, then a good kicking
<lamont> woot
<lamont> daniels: and libsm is waiting for libice?  or also xproto?
<daniels> lamont: xtrans built + accepted -> libice built + accepted -> libsm built + accepted -> xorg built + accepted
<lamont> ok
<lamont> daniels: of course, if you had used versioned build-deps, my life would be easier...
* lamont makes a note to go kick libice in a bit
<lamont> xtrans 0.2+cvs.20050513-1 is the right version?  or is that the old one?
<daniels> lamont: 20050530-1
<Lathiat_> man, how did i ever live with any less bandwidth than 1.5mbit
<lamont> ok
(dholbach/#ubuntu-devel) mdz: i'm going to reply to the mail (you CCed me in) and point to http://wiki.ubuntu.com/UniverseNewPackages (packages that got into ubuntu and may be picked up by debian developers)
<mdz> dholbach: ok, and please also discuss whether it is appropriate to file ITPs for those packages
<dholbach> mdz: i'll try to make up an opinion first :)
<fabbione> lamont: can you please grab http://people.ubuntu.com/~fabbione/993_hppa_has_no_dri.diff , stick it in debian/patches and do a full rebuild?
<lamont> fabbione: once the current build finishes...
<fabbione> lamont: sure
<fabbione> meh actuallt
<fabbione> that should be INCLUDES
<fabbione> lamont: ok.. same patch with proper names :)
<tarvid> ogra, rumor has it that you can recommend some modems
<tarvid> serial ports are disappearing
<ogra> tarvid, who gave you that idea ?
<tarvid> i suppose a USB modem would have some appeal for both desktop and laptop
<tarvid> ogra, venda suggested you might know about searchable hardware databases
<lamont> fabbione: previous build is mid-install now, so should be able to do the other shortly
<fabbione> lamont: i have no rush really....
<lamont> granted
<fabbione> lamont: but i can't test the patch locally
<ogra> tarvid, i maintain the hardware DB, but its not searchable yet :/ sadly....
<tarvid> i saw hints of conexant support but read of nightmares
<tarvid> usb modems require a kernel with support
<tarvid> i don't know if Ubuntu has that by default
<tarvid> i recently dodged a nic problem with my old thinkpad by replacing the mini-pci nic
<tarvid> looking for a modem which works out of the box
<camilotelles> ogra: do you mantain the hardware database? how can we contribute to it? where is the docs?
<Lathiat> tarvid: unless its a serial modem id ont think any winmodems etc work out of the box, but some can be easily configured with sl-modem-daemon/appoprriate kernel modules
<tarvid> sl is short for SmartLink?
<ogra> tarvid, sorry, but the data is only in flatfile yet, so grepping through the ~40000 files would take half a day currently.... i work on a SQL solution...but that takes its time
<tarvid> i hear rumors of USB modems working if kernel support is present
<mdke> camilotelles, just run it in ubuntu and it will load your feedback into the database
<tarvid> is that in the default kernel?
<camilotelles> mdke: thanks, where is the docs about this?
<ogra> camilotelles, the client is in Applications->System Tools
<mdke> camilotelles, no idea, but the program is super intuitive
<elmo> god damn it why does visudo default to nano? that's just evil and wrong
<Mithrandir> elmo: it uses sensible-editor, iirc
<ogra> camilotelles, there ae no docs yet
<ogra> elmo, dch  defaults to nano ;)
<camilotelles> thanks all.
<camilotelles> we have just received two new machines. We will try to run Ubuntu in both. One of these has a SATA RAID Array
<camilotelles> s/has a SATA RAID Array/ has a VIA SATA RAID Array/
<jbailey> Wow, lintian goes nuts if your postinst's first line is "#/bin/sh" by accident. =)
<Nafallo> hehe
<mdz> tseng|work: can you join us in #ubuntu-meeting if you're around?
<mdke> ok i just let my flatmate use my ubuntu computer. He was using a pen drive and couldn't figure out how to unmount it before removing it. He right clicked and got "unmount volume", which he didn't understand. Perhaps that should be changed to something more obvious?
<SchmeisserMartin> i just tried to join here with 'cd #ubuntu-devel'
<SchmeisserMartin> :-)
<diamond> mdke: you have a point
<diamond> mdke: volume is a nice precise technical term, but makes no sense to non-techs
<mdke> diamond, yeah, although i still took the piss out of him
<diamond> mdke: -)
<mdke> diamond, so is "unmount"
<diamond> mdke: ah. again, a good point. didn't even blink an eyelid at that one ,-)
<SchmeisserMartin> im trying to compile wired cause i want to try it and someone did a packaging request for it
<diamond> mdke: i reckon that counts as a bug
<SchmeisserMartin> make complains about something with wx...but im not that experienced ;-) ...can someone help?
<SchmeisserMartin> i randomly installed all wxwidget stuff i could find
<mdke> diamond, me too
<jnc> Mithrandir: pingage
<Mithrandir> jnc: pongtastic.
<venda> mako: you there? Need answers to questions on licensing issues
<St0n3-C0l> anyone here can help me with i810 video card ?
<jnc> Mithrandir: openoffice.org printing broke again for am64, FYI
<Mithrandir> jnc: I'm slightly aware of it, but haven't gotten around to fixing it yet.
<jnc> Mithrandir:  it was working lovely after you fixed it, then it done gone and broke with some breezy updates ;)
<jnc> Mithrandir: 'k
<Mithrandir> jnc: I just need to update the package
<jnc> Mithrandir: is it something i could hack real quick?  maybe a good addition for wiki
<Mithrandir> jnc: download the ooo-amd64 source package, do BUILD=0 sh ./fetch-and-build then dpkg-buildpackage and it should work.
<Mithrandir> it'll download half the universe, though
<maswan> Mithrandir: do you ahve time to take care of Ante? I'm working on mkaign cdimage.d.o hold together for the upcoming release
<venda> elmo: what version is docteam svn at?
<jnc> Mithrandir: with a 400gb drive, i hear you can download the whole internet
<jnc> :)
<Mithrandir> maswan: yes, I'm just asking people to Cc you so you're in the loop.  I'm handling them.
<maswan> jnc: /dev/cciss/c1d0p1     1.4T  604G  793G  44% /export/ftpmirror
<maswan> jnc: good luck? :)
* jnc drools
<maswan> Mithrandir: ah, good, thanks
<surak> wow
<Kamion> mdz: (no, I didn't upload it, but I guess you found that out)
<Mithrandir> jnc: /dev/md0              1,8T  569G  1,2T  33% /backup/backup0
<maswan> jnc: that's all available via http, so you better have a good compression algorithm. :)
<Mithrandir> s/jnc/maswan/. :P
<jnc> maswan: what would you suggest for a 1-2TiB size raid5 array?  i want redundancy for massive amounts of CC licensed music
<jnc> i mean, what filesystem
<Kamion> mdz: we did briefly build live CDs, but the cloops were being built against hoary instead of breezy by accident, last I checked
<Mithrandir> jnc: ext3 works fine for me.
<Kamion> lamont: what's the live CD status now? did that get fixed?
<jnc> good to know
<mdz> lamont: is someone other than you up to speed on the livefs build process (enough to get builds happening for breezy)?
<maswan> jnc: ext3 unless you need performance, then I'd go for xfs personally. but I have heard that some modern kernels have xfs issues.
<lamont> Kamion: last I looked it was still haveing challenges with ubuntu-* (for some value of *)
<lamont> I'll check on it.
<maswan> (perfromance = >100MByte/s)
<lamont> mdz: I think infinity is, but I'll make sure of that
<maswan> Mithrandir: /dev/sdf1             1.4T  1.4T   17G  99% /export/se1
<maswan> Mithrandir: work stuff. :)
<Mithrandir> maswan: nicey. :)
<jnc> maswan: the other thing i'm looking for suggestions on is what drive configuration to go with.   six 400GB drives? whether to use a hot spare or not
<dbernar1_> I repacked the libx11-dev & libx11-6 packages with the keys patch (ctrl key bug...)  https://bugzilla.ubuntu.com/attachment.cgi?id=2552. I have called it libx11-6_6.8.2-20-1. is it a good version number ?
<jnc> this is just for like, personal stuff. 
<dbernar1_> sorry to interrupt the meeting;)
<jnc> i'm worried that a drive will fail and i'll lose everything :/
<maswan> jnc: I'd go for a hot spare, unless you have a cold spare and are fairly sure to get access within a day if a disk fails
<jnc> dbernar1_: you're my hero
<jnc> i've been sending email messages prematurely for weeks
<dbernar1_> why?
<Mithrandir> jnc: try to get drives from different production series
<jnc> Mithrandir: ah, good idea
<maswan> jnc: but then, I have seen way too many disks fail at work to be comfortable with them at all. :)
<maswan> jnc: also, backups are good, raid or no raid
<Mithrandir> jnc: and make sure to run them for at least a few weeks before putting anything interesting on them.
<jnc> dbernar1_: Ctrl+X maps out to "send message" in evo when the broken xorg-x11 key problem is effective
<jnc> yea
<torkel> Mithrandir: make that months... :-(
<Kamion> lamont: that stuff should be fine now (this half-hour, anyway) according to http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html
<jnc> i'm very impressed with seagate drives for quiet noise levels and solid performance
<dbernar1_> jnc, thank you, I will tell the guy that was your answer to his question:-p
<gub> hi
<jnc> dbernar1_: sending half-finished emails has gotten me some blank looks and strange replies :)
<gub> I repacked the libx11-dev & libx11-6 breezy packages with the keys patch (ctrl key bug...)  https://bugzilla.ubuntu.com/attachment.cgi?id=2552.
<dbernar1_> gub...your question has been asked here.
<dbernar1_> I have called it libx11-6_6.8.2-20-1. is it a good version number ?
<gub> ok thanks :)
<lamont> Kamion: goodie
* lamont launches a test build
<fabbione> dbernar1_: it's better you avoid that... probably 6.8.2-20.0.1
<dbernar1_>  you're my hero & Ctrl+X maps out to "send message" in evo when the broken xorg-x11 key problem is effective  were the answers
<dbernar1_> and that one above from fabbione .
<gub> it's on http://hybrid-dev.net/ubuntu breezy main.
* tseng|work heads home
<gub> fabbione: ok
<gub> i'll change that
* jnc blinks
<jnc> i'm surrounded by robots?
<surak> jnc: ??
<Mithrandir> who gave us away?
<jnc> *snicker*
<elmo> mvo!
<elmo> mvo: your python-apt upload was unsigned, please resign + try again
<mvo> elmo: argggg
<maswan> elmo: trying a newer version of rsync now that is supposed to have a bit more talking-to-the-other-side stuff. :)
<mvo> elmo: sorry for the trouble. looks like it's not my day today
<mvo> elmo: see /msg :/
<lamont> dbernar1_: I'd call it 6.8.2-20keys1 or some such
<lamont> -20.0.1 is bad, since the archive stuff thinks that's a binNMU
<elmo> mvo: no prob, I've been waiting for an upload to test some katie changes
<gub> lamont: ... I just changed the name :)
<gub> version number*
<elmo> maswan: cool
<mvo> elmo: uploaded (signed this time)
<gub> lamont: with this number, is it working for uprade ?
<gub> I mean with 6.8.2-20keys1
<lamont> gub: will work for upgrade
<lamont> since -21 is bigger than -20keys1 which is bigger than -20
<lamont> (see also all the -NNNubuntuM versions in the archive...)
<jnc> maswan: are there higher performance network filesystems than NFS?
<lamont> fabbione: -20.2 building with your patch now
<fabbione> lamont: cool
<jnc> i have been unhappy with the speed provided by NFS in my setup, and I am unsure if that is due to NFS itself or the settings I have in use
<Kamion> lamont: is the debconf build stuck?
<maswan> jnc: nfs over udp and async should be limited by your network bandwidth.
* maswan tries to remember the other parameters
<gub> lamont: ?
<Mithrandir> maswan: wsize, rsize?
<maswan> jnc: Personally, I've done 2.5Gbit/s over nfs, but that was from ram. :)
<ogra> jnc, have rsize=8192,wsize=8192 ?
<maswan> Mithrandir: ah, yeah.
<lamont> gub: yes?
<lamont> Kamion: looking
<lamont> Kamion: remind me not to d-w on an arch: all package.  grumble
<lamont> (and fixed)
<Kamion> lamont: libqt-perl isn't arch: all?
<Kamion> lamont: (thanks)
<lamont> Kamion: could just be that I'm clueless today... :-)
<lamont> anyway, the d-w didn't clear for me, so I whacked it on the head
<Kamion> k
<maswan> elmo: no luck. with truss we've found out that we're done stating everything locally and then just select() for some minutes and then get Connection timed out
* Kamion -> off for a bit
<maswan> elmo: and no other mirror has any problems?
<elmo> maswan: nope, but not many people mirror off of this box
<SchmeisserMartin> i got my problem solved. wired seems to want wxgtk2.6
<maswan> elmo: I guess we're alone with AIX 5.1 and GPFS for mirroring anyway. :)
<elmo> heh
<Mithrandir> is there a good reason why the seeds aren't cachereved?  Apart from "nobody has done it"?
* ogra has the first green BreezyGoal :-D
<SchmeisserMartin> gj there!
<jnc> ogra: hmm
<maswan> elmo: mind if I set up another mirror and setup a proxy thingie there?
<elmo> maswan: hmm, how do you mean?  another mirror mirroring off syncproxy?
<jbailey> mdz: If you're doing initramfs stuff, I've just sent 0.5 on its way.  It includes a number of fixes that you'll want.
<jnc> ogra: congrats.  w/re NFS, is that rsize thing on the client side or server side?
<maswan> elmo: yeah, for a week or two
<maswan> elmo: and then ftp.acc updating from that
<ogra> jnc, mount option in the fstab
<dholbach> good night
<elmo> maswan: sure, no prob
<jnc> ogra: ah, i'm using the 'autofs' to mount an NFS share from debian GNU/Linux box server to the Ubuntu Linux client here
<jnc> i don't think it has that option
<mdz> jbailey: ok, am going to try to work on LTSP today
<jnc> ogra: then again, i have checked `mount` and it shows 
<maswan> elmo: even if currently my main project is debian-cd :)
<maswan> elmo: or rather, the building and mirroring stuff there
* jnc points to output from mount "rw,nosuid,nodev,hard,intr,rsize=8192,wsize=8192,addr=192.168.6.3" for ogra
<ogra> jnc, ah, ok
<ogra> jnc, so youre using it
<jnc> yeah looks like it heh
<jnc> oh well, it's not a big deal
<jnc> i'm thinking for the future if i have many terabytes of info i should expect more performance
<maswan> jnc: you might want to add proto=udp, nfsvers=3 ?
<jnc> interesting
<maswan> I'm not totally sure on this right now though, I'm not the nfs-tuning-guy at work. :)
* jnc =)
<jnc> thanks though
<jnc> i wanted to hear if i'm crazy or not for thinking NFS could be faster
<maswan> jnc: as I said, from ram I've served nfs at 300MByte/s :)
<maswan> jnc: that was mostly to test link aggregation though
<JaneW> ogra! is that green for real!?
<ogra> yep
<JaneW> WOOHOO!
<ogra> waiting only for the archive sync
<tseng> hi all
<tseng> doko: pong
<ogra> JaneW, mono is also near the green state... it got moved to main... but still has bugs to work on
<tseng> BOOGS
<lamont> fabbione: no go on your patch
<ogra> so ostly of the specced work is done
<tseng> make it yellow
<ogra> it is
<tseng> yay
<fabbione> lamont: bong...
<lamont> yellow-green?
<ogra> heh
<lamont> want the log again fabbione 
<lamont> ?
<fabbione> did the -I../../../.... get included in the call?
<fabbione> lamont: yes please
<mdz> fabbione: did you do the lm-sensors upload?
<lamont> fabbione: people.ubuntu.com/~lamont/buildLogs/x/xorg/6.8.2-20/xorg_6.8.2-20.2_20050531-1453-hppa-failed.bz2 
<fabbione> mdz: when???
* lamont feels slightly dirty.
<mdz> fabbione: 1:2.9.0-19ubuntu1
<mdz> the .dsc is signed with your key
<lamont> fabbione: didn't actually look to see what happened...
<pixelmonkey> I noticed that Ubuntu 5.04 has a "Hibernate this computer" option in the gnome menu.  I was wondering what gconf key I can set to enable that on my system (which was upgraded from Warty)
<fabbione> mdz: probably.. i can't remember
* lamont gets ready to go into town for several hours
* JaneW is buying you a beer next week!
<pixelmonkey> I can't tell if this is a default GNOME option or if it was added by the Ubuntu team
<mdz> fabbione: it looks like you dropped some of the ubuntu changes (specifically removing the kernel-source build-deps)
<fabbione> mdz: hmmmm ok.. i did a long time ago.. i really can't remember...
<kent> pixelmonkey, i also upgraded from warty and I do have that option in the logout-dialoge.
<fabbione> i will add it to my TODO list for tomorrow
<pixelmonkey> kent, yea, I think it really is just a gconf option that enables it
<pixelmonkey> kent, but I don't see it documented anywhere
<pixelmonkey> kent, I have swsusp2 working, it'd just be nice to have the option in the logout menu
<elmo> argh
<elmo> how do I get irssi not match on nicks?
<mdz> fabbione: Thu, 14 Apr 2005 21:36:28 +0100
<elmo> every time pixelmonkey speaks I get spammed
<mdz> fabbione: thanks
<fabbione> mdz: no problem.. 
<pixelmonkey> elmo, wow, that is some primitive matching it does, eh? :) pixELMOnkey
<fabbione> lamont: well apparently it didn't like #if defined(__hppa__)
<mdz> elmo: can you promote partman-auto-lvm to main?  it seems to be non-trivial
<\sh> guys...there r some issues with python-qt3 (main) and eric3 (universe), they should get some lovely updates for hoary...
<elmo> mdz: done, but FTRT, do source and binary separately to work around that prob
<mdz> elmo: ok, thanks
<mdz> elmo: also, xpdf seems to be in a weird state: E: /srv/ftp.no-name-yet.com/ftp/pool/main/x/xpdf/xpdf_3.00.orig.tar.gz (main/xpdf - breezy) already exists!
<elmo> mdz: you're promiting it? :/
<fabbione> elmo: we will have to test it in the early release cycle
<elmo> you can't demote, promote shared-between-suites without manual scariness ATM, I'm afraid
<elmo> fabbione: test?
<fabbione> elmo: installerlvmbydefault
<fabbione> or something like that
<elmo> oh, yeah
<fabbione> it needs partman-auto-lvm
<pitti> mdz: btw, did trulux/ajmitch ever ask you about approval to put the selinux-patched base packages into breezy?
<mdz> elmo: I don't think we have a choice; kpdf needs it
<mdz> pitti: no
<pitti> mdz: I tested them for three weeks now (just the patched packages, without any policy and disabled selinux)
<pitti> mdz: so far there is only one regresssion that ajmitch works on
<mdz> pitti: I don't have a problem with it in general, but I would like to see the list first
<pitti> mdz: yes, of course
<pitti> mdz: it touches essential parts of the base system (dpkg, pam, etc.), so if we do it, it is early breakage
<fabbione> lamont: simpler patch: http://people.ubuntu.com/~fabbione/993_hppa_has_no_dri.diff
<mdz> pitti: right
<mdz> pitti: I am most concerned about dpkg
<pitti> ajmitch: can you compile a list of affected pacakges?
<elmo> mdz: poppler based alternative isn't viable?
<mdz> my understanding is that we do not even have the code for dpkg yet
<mdz> elmo: wanna write one?
<pitti> mdz: oh, we have
<trulux> pitti: what regression? I dislike to get ignored on those things concerning my work
<elmo> mdz: no, but daniels made getting motif to work sound equally non-trivial
<pitti> mdz: AFAIUI Majoy and Keybuk have working patches
<lamont> fabbione: nice bat you have there.. :-)
<ajmitch> pitti: sure, I will
<lamont> fabbione: you want me to test that one?
<pitti> mdz: and Keybuk wanted to apply the patch soon anyway
<ajmitch> mdz: dpkg patch is working fine
<fabbione> lamont: yes please.. if you have time
<mdz> elmo: we could disable the reader and provide only the utilities, but that's sort of nasty, isn't it
<pitti> trulux: the pam breakage we talked about, that kills sudo
<mdz> Riddell: can anything be done about the xpdf-utils dependency on kpdf?
<pitti> trulux: that wasn't exactly your fault, I didn't blame you :-)
<ajmitch> trulux: the one I told you about, you're not being ignored
* lamont creates -20.3
<trulux> ajmitch: sorry, just migraines again and it's hard to deal with all the stuff
<pitti> mdz, Riddel: maybe we can make kpdf use poppler, just as we did with cups?
<jnc> ogra: serpentine fails to actually burn a CD
<ajmitch> trulux: best to step away from the computer when you feel like that :)
<jnc> you lose ;)
<ajmitch> jnc: worked for me last time I tried it :)
<jnc> interesting
<mdz> pitti: how did you do it with cups?  is there a poppler-utils or similar somewhere?
<jnc> ajmitch: GnomeBaker works for me
<trulux> ajmitch: yeah, I know, but I need to have a kernel patch finished today and it's simple stuff
<elmo> mdz: *shrug*, I'm not heavily vested, I'm just saying xpdf wasn't removed 'cos it's unpretty
<ogra> jnc, file a bug please
<jnc> ogra: will do
<Nafallo> jnc: works for me(tm) :-)
<pitti> mdz: no, not so far; I basically ported pdf2ps from xpdf-utils to libpoppler
<ogra> and assign it to hostmaster@grawert.net
<trulux> ajmitch: how are things going?
<trulux> mpt: ping
<mdz> elmo: I would very much like to support only one copy of xpdf
<lamont> fabbione: build launched, and I need to leave.
<mdz> pitti: where did you put it?
<lamont> back in about 7 hours or so. :-(
<pitti> mdz: I patched the pdf2ps.c code that is already in cups
<mdz> oh
<fabbione> and i need to go to sleep :)
<fabbione> lamont: you will tell me later :)
<pitti> mdz: so it's in /usr/lib/cups/pdftops right now
<lamont> right
<elmo> mdz: done
<jnc> ooh maybe i will then be able to send faxes
<jnc> that would be awesome
<mdz> elmo: done what?
<pitti> mdz: I didn't port the whole xpdf-utils suite so far
<mdz> pitti: I think kpdf probably uses pdftops too
<ogra> jnc, i have 5 reports of successfull burns from different ppl for now, you are the first for whom it failed....
<mdz> pitti: so maybe we should add it to poppler and ship a package of poppler-based utilities?
<pitti> mdz: if we can reuse it, we should create a poppler-utils
<elmo> \mdz: promoted xpdf, as you asked?
<jnc> ogra: :/
<mdz> elmo: oh, I thought we were in the middle of talking me out of that
<jnc> ogra: i *do* have a SATA optical drive
<jnc> teehee
<ogra> oh
<Nafallo> ogra: will get more tested when it's in ubuntu-desktop ;-)
<jnc> maybe that is a source for some troubles
<ogra> Nafallo, yep :)
<mdz> pitti: how much work was it to port pdftops to libpoppler?
<mdz> pitti: kpdf seems to want pdfinfo
<elmo> mdz: err.  I thought you were telling me to put code where my mouth is, so I gave up
<ogra> jnc, might be... can you burn data with nautilus propoerly ?
<mdz> and only pdfinfo
<jnc> ogra: yes
<mdz> elmo: I was, but then pitti volunteered :-)
<jnc> ogra: serpentine repeatedly asks me for a blank or rewritable disc
<pitti> mdz: I don't know the code, but if kpdf Depends: on xpdf-utils, then it should be along that line, yes
<pitti> mdz: yes, then we need to port the other tools, too (shouldn't be so hard, but requires a bit of time)
<ajmitch> trulux: fine, I'm at work at the moment, so can't reply immediately :)
<gub> ok the patched libx11-6&libx11-dev v.6.8.2-20keys1 are on http://hybrid-dev.net/ubuntu breezy main
<pitti> mdz: well, 20 to 30 minutes, not such a big deal
<mdz> pitti: I would be willing to bounty the lot
<ogra> jnc, can you switch off the g-v-m feature for a test and try again ?
<pitti> mdz: if we need it, then we should do it properly; I can port the suite and send it to upstream
<Nafallo> jnc: I'll try a burn and see if I can reproduce that.
<jnc> ogra: i do not understand "g-v-m"
<ogra> (the burn:// part)
<pitti> mdz: oh, even better :-) if we can get it on time?
<pitti> jnc: gnome-volume-manager
<jnc> jnc@baker:~$ serpentine | *** glibc detected *** realloc(): invalid next size: 0x0000000000d61820 *** | Aborted
<jnc> nice
<pitti> mdz: porting only pdfinfo should be very easy, though
<jnc> anyone else on amd64 using serpentine?
<Nafallo> jnc: yepp :-)
<ogra> my burner is broken over here... :(
<Nafallo> ogra: didn't I complain about that before? I can't remember :-P.
<mdz> elmo: it sounds like it's probably a lot easier than I thought to get rid of it
<jnc> okay i gotta get going.  will have to follow up tomorrow
<jnc> thanks again
<ogra> Nafallo, didnt you say it worked ?
#ubuntu-devel 2005-06-08
<mdz> ogra: do you think you could do the xpdf-utils/poppler thing?
<pitti> mdz, elmo: if kdpf is the last package holding xpdf, then it's worth the trouble of converting kpdf IMHO
<mdz> pitti: it is
<Nafallo> ogra: it did. but that was before cxx. anyway I'll try again now :-)
<ogra> mdz, which xpdf-utils/poppler thing ? i didnt follow
<wasabi_> So I was thinking. dhclient.conf should be configured to send his own hostname to the dhcp server by default.
<dholbach> jnc: when do you get that message?
<pitti> ogra: creating a poppler-utils package which contains the xpdf-utils tools ported to libpoppler
<Nafallo> wasabi: ++ :-)
<pitti> ogra: I already did pdftops, but we also need pdfinfo, and we should port the other tools, too (and send them back to upstream)
<ogra> pitti, what involves this "porting" ?
<ogra> C ?
<jnc> dholbach: i got that when i tried to start serpentine.   after rm -fr ~/.serpentine;  it works again
<dholbach> C++ for poppler, i think :)
<pitti> ogra: take <tool>.c, rip it out of xpdf-utils, and hack on it until it compiles with libpoppler-dev :-)
<ogra> ergh
<ogra> proting C to C++ ?
<mdz> elmo: if this works out and we can move it back, will it require a special elmo dance again?
<mdz> ogra: they are both C++
<ogra> argl...
<dholbach> jnc: i don't get that funky message
<wasabi_> I guess that would be properly done by dhclient.conf having a send-default-host-name option
<jnc> wtf.  it's burning the CD now
* jnc blinks
<jnc> ogra: false alarm maybe
<jnc> i didn't change anything
<jnc> oooooh
<jnc> g-v-m
<ogra> yep
<jnc> ogra: so ... that's a bug eh?
<mdz> ogra: if it's not something you feel confident about, no problem
<ogra> jnc, in g-v-m
<mdz> we ought to ask Riddell
<mdz> pitti: can you talk to Riddell about it?  your time zones are compatible
<jnc> oh.  i would have thought a bug in serpentine
<elmo> mdz: yes, sorry
<ogra> mdz, do i have time to ecide until tomorrow ? 
<jnc> i mean, GnomeBaker works fine with g-v-m running
<ogra> decide even
<fabbione> night everybody
<ogra> jnc, might be, but it doesnt use libnautilus-burn
<mdz> ogra: it's a small thing and I just want to get it done so that we can be rid of xpdf again
<jnc> ah
<dholbach> bye fabbione 
<pitti> ogra: maybe we can do some cow trading? I do the poppler stuff (I already know it a bit now) and you help me with the postgresql stuff? :-)
<ogra> mdz, i know, but i have to decide if i actually want to learn C++
<pitti> mdz: sure, will do
<mdz> ogra: if you would have to learn C++ in order to do it, it's easier for someone else to look at it, don't worry about it
<mdz> Riddell should be able to do it
<ogra> mdz, i'm ok with C and some OO langs so it should be a good task to learn it :)
<pitti> mdz: creating a minimal poppler-utils with just pdftops and pdfinto is a matter of ~ 1.5 hours
<mdz> pitti: yes, but you have too much work already, remember? ;-)
<pitti> ogra: ok, let's discuss this tomorrow with Riddell
<ogra> yep
<pitti> mdz: -> that's why I proposed the cowtrading :-)
<mdz> what a delightful package name: libxml-libxml-perl
<dholbach> :)
<pitti> let's talk tomorrow
<dholbach> pitti: i think ogra already said yes :)
<dholbach> pitti: or did you invite somebody else to the pdf party? :)
<pitti> bah, gtimelog doesn't really work well if you cross midnight...
<ogra> mdz, vunz made clear he cant do the xscreensaver changes in breezy time, thats a huge bunch of work i have extra now....so i'm a bit careful about extra work currenly....
<pitti> dholbach: oh, my irc output is a bit shuffled here, 10 seconds latency (small net problem)
<dholbach> *nod* ok
<pitti> ogra: fine for me if you want to do it :-)
<ogra> ok
<elmo> mvo: huh, why python2.4-apt?
<mdz> Kamion: bugreporter-udeb was intentionally retired, right?
<elmo> hmm, nm
<mvo> elmo: it's build now for both python2.3 and python2.4
<pitti> good night guys
<Nafallo> pitti: good night :-). see you tomorrow.
<mdz> pitti: night
<Kamion> mdz: yes
<Kamion> mdz: replaced by installation-report and save-logs
<Nafallo> jnc: what did you do to be able to burn? now I got that bug instead :-P
<dholbach> good night everyone :)
<Nafallo> night dholbach :-)
<Nafallo> jnc: nm. works.
<mdz> err, KDE doesn't require gnupg2 anymore?
<mdz> we went through all of that business for hoary just to have it go away?
<elmo> kde deps seem to be in massive flux
<mdz> leaving it alone for now
<ogra> Nafallo, ??
<mdz> I did a bunch of obvious stuff
<ogra> Nafallo, what was it ?
<mdz> trying to get a handle on the set of packages which pitti will need to review in order to sync up
<Nafallo> ogra: seems I had to kill g-v-m.
<ogra> Nafallo, :/
<Nafallo> ogra: that shouldn't be the correct approach though ;-)
<ogra> nope
<mdz> elmo: how do you calculate the reverse-depends stuff in anastacia?
<ogra> but i was suspecting its g-v-m
<wasabi_> Heh.
<wasabi_> If you select N/A in the Ubuntu device database creation thing for sound, the next page says "Video" "did you hear the text sound?" and offers no forward button or controls of any type.
<Nafallo> ogra: ehm... will be nice to see if this disk works. the bar didn't move since it started writing in record speed. just fixated.
<ajmitch> wasabi_: file bug :)
<ogra> Nafallo, tell me if it worked then....
<Nafallo> ogra: works.
<ogra> great...
<ogra> anothe bug to fix
<Nafallo> ogra: but an ugly bug ;-)
<elmo> mdz: it's just looking at germinate 'all' output
<mdz> elmo: ah, that explains why it's lying then
<Kamion> lying where?
<mdz> ogra: could you fix elementtree to stop building python2.2 packages?  it's trying to pull python2.2 into main
<mdz> Kamion: in anastacia output
<mdz> Kamion: it says it wants dialog because of alsa-utils, but it's an OR'd dep with whiptail, so it's actually something else
* mvo goes to bed now
<Kamion> ah, ORed deps occasionally confuse germinate yes
<mdz> Kamion: I think it's probably doing the right thing, just choosing an unintuitive package to list as the reason
<ogra> mdz, oops, how could that get past the python transition ?
<elmo> mdz: hum, that could be my fault
<elmo> I had hints for germinate, and recently updated to 2005 germinate and may have lost the hints, lemme check
<mdz> dialog                                    | dialog                          | alsa-utils                               | Santiago Vila <sanvila@debian.org>                                        |          180578 |            1048
<elmo> hmm, nope
<mdz> rdepends is unintelligible for the same reason
<ogra> mdz, working on it
<mdz> a ton of stuff depends on dialog | whiptail
<mdz> ogra: thanks
<Kamion> mdz: reason selection is often dodgy; I could probably try to make it pick the first non-ORed dep it encounters
<elmo> kamion; the problem is, given a or b, if b is already in main, it should favour b
<elmo> and currently doesn't AFAICS
<mdz> Kamion: I don't think it's worth it; doing the right thing seems Very Hard, and picking the first non-ORed dep doesn't sound much better than the status quo
<Kamion> germinate has no idea what's already in main
<elmo> Kamion: eh, "is already in it's idea of main" (i.e. 'all')
<Kamion> especially not when running in the archive configuration where it just gets a single Packages file
<mdz> Kamion: I would like to know what's going on in this particular case, though. it's starting to look like germinate is doing the wrong thing, actually
<mdz> there are only 15 packages which depend on dialog-but-not-whiptail, and they're all in universe
<Kamion> elmo: it's encountering dialog | whiptail before it's had a reason to explicitly select whiptail
<elmo> kamion: oh, right
* elmo goes back to sleep
<Kamion> seeding whiptail would fix that
<mdz> Kamion: does it matter which seeD?
<mdz> does it have to be minimal (where the dep on alsa-utils is coming from), or can it be supported?
<Kamion> I think supported would do, but let me do some experiments to test that
<elmo> germinate's begging for a test suite ;)
<elmo> [he says helpfully] 
<Kamion> germinate will spot that it can promote whiptail from an outer seed to satisfy the dep
* Kamion introduces elmo to the Ubuntu seeds
<elmo> in the same way the ubuntu archive is the test suite for katie?  good call :P
<Kamion> it's like WORKSFORME, only WORKSFORYOU
<Kamion> I have lots of directories scattered around in ~/src/ubuntu/germinate/ called 'pre' and 'post'
<Kamion> +? Unknown dependency dialog by defoma
<Kamion> +? Nothing to choose to satisfy defoma
<Kamion> hmm, it doesn't entirely like that
<Kamion> I'll dig
<Kamion> duh, it helps to run against main,restricted,universe,multiverse not just main,restricted. spethial
<sabdfl> kamion, the CoC suggests you should be sensitive to retards even when referring to yourself
<diamond> sabdfl: nice -)
<sabdfl> ah. he's ignoring trolls. sigh.
<Kamion> sabdfl: heh :-)
<Kamion> nah, I was just hunting down the libstdc++ porting howto for somebody on -users
<sabdfl> what's he porting too?
<Kamion> from libstdc++2.10 (pre-standard) to anything vaguely current
<sabdfl> btw, a mate of mine is trying to install hoary on a mini-mac, do we have any success stories on that?
<Kamion> well, pre-current-standard anyway
<Kamion> sabdfl: hmm, not that I know of, I think full support may need > 2.6.10 since it's pretty recent
<sabdfl> his name's richard braine (really) and i pointed him in your direction
<Kamion> the "buy benh a mini-mac" campaign on debian-powerpc was after we froze, I think
<elmo> does he have a friend called pinky?
<sabdfl> that would be me
<sabdfl> on bald days
<Kamion> sabdfl: yeah, I saw him on #-meeting, but he left before I got back; I'll mail him
<sabdfl> cool, thanks
<sabdfl> apparently it installed to console by xorg's not working, so it's not a totaly disaster
<sabdfl> i'm surprised google has no fixes
<JanC> I have a remark about http://udu.wiki.ubuntu.com/MountingHDDFilesystems
<JanC> once fstab has the right entries, people can use the gnome disk mounting panel applet
<JanC> it's easy to use but doesn't require auto-mounting of all NTFS/FAT partitions at boot time
<Kamion> oops, the snake got out, gave me a surprise :)
* Kamion restores it to the tank
* diamond_ hopes there is no metaphor involved here
<Kamion> JanC: you suggest making them all noauto by default; could do
<Kamion> diamond_: no :)
<diamond_> Kamion: that's ok then -)
<diamond_> Kamion: what kind of snake, if it's not to ot to ask?
<Kamion> amelanistic (i.e. orange) corn snake
* diamond_ updates the kamion stalking wiki
<maswan> diamond_: oooh! oooh! where is it? can I stalk Kamion too?
<Kamion> it's my fiancee's snake rather than mine
<diamond_> maswan: actually, i screwed up, i have to now officially deny it's presence here, but if you come around the back, i can let you know the dirty details
<diamond_> there is no kamion stalking wiki.
<Kamion> Heh, good, good. Fixing problems with the video output for now, looks
<Kamion> like DDC doesn't work with X, and not very well with radeonfb, because
<Kamion> of the stupid way Apple routed the DDC lines of the connector to the
<Kamion> "CRT2" DDC lines of the video chip... oh well...
* maswan heads around back to beg acceptance from the non-existing Kamion staking cabal
<Kamion> sabdfl: ^-- benh having just got his mac mini in early March
<Kamion> although he said screwing the DVI cable all the way in helped ...
<diamond_> maswan: -)
<Kamion> JanC: want to add that to a comments section at the end of that page?
<JanC> this wiki uses different accounts than the normal ubuntu site I guess ?
<Kamion> not sure, try your existing one first
<mdke> i've cut some things off the FrontPage of the wiki and put them in second level pages
<mdke> just in case anyone misses something
<doko> back again ...
<doko> Kamion,mdz,jbailey: the reason of the buildability of OOo2 in hoary (and not in breezy) is the addition of gjdoc as a java-gcj-compat dependency. that one sucks in antlr, and then kaffe and sablevm
<wasabi_> hi
<wasabi_> I think antlr is fixable. In fact I had thought I fixed it.
<mdz> Build-Depends: debhelper (>= 4), kaffe, fastjar, classpath, jikes-classpath (>=
<mdz> 2:0.12-1), autotools-dev, gcj-3.4, libgcj5-dev
<wasabi_> seems not.
<wasabi_> Oh yeah. I remember now. I didn't fix it.
<wasabi_> jbailey was going to work some cdbs magic on it.
<wasabi_> ;)
<wasabi_> Because it was a weird makefile build system.
<wasabi_> jbailey!
<jbailey> wasabi_: Is that the only blocker?
<Riddell> mdke: thanks for the link to Kubuntu :)
* wasabi_ shrugs. doko found it.
<wasabi_> I remember skipping over it ages ago because it was an odd build system.
<wasabi_> And I wasn't feeling up to it at the time.
<wasabi_> Doesn't look like that big of a deal now that I look at it again. I probably learned some stuff about Make since then.
<mdke> Riddell, fundamental i feel
<mdke> mako, ping?
<Kamion> * Chose dialog to satisfy defoma
<Kamion> *good* crack
<wasabi_> Think I've got it fixed.
<wasabi_> Heh. Yay for circles.
<Nafallo> is someone porting apt-cacher to apache2 or should I start working on that after I've been in bed for several hours? :-)
<Nafallo> seems it might be fun to have for NetworkWideUpdates
<wasabi_> doko, you aren't working on antlr, right? :0
<wasabi_> doko, I've got it fixed.
<sabdfl> Kamion: very cool. surprised apple capable of braindamage like that.
<mkde> hey guys
<mkde> mako just found this site www.ubuntu.it, it is a redirect of the main ubuntu.com site but with a pubblicity banner at the top for a company doing linux training
<mkde> crazy huh
<tseng> oh wow time for me to get flamebasted on osnews
<tseng> "mono 1.1 added to ubuntu"
<tseng> news flash.
<mkde> awesome
<tseng> this poor soul will be using gnome 2.10 for the next 5 years since I am "adding" mono to ubuntu
<tseng> im so mean.
<Nafallo> hehe
<mdz> jbailey: do you have an archive for initramfs-tools?  I'm pretty much guaranteed to have to make changes to it
<tim> does anyone know if there is are anymore ubuntu offshoots in development and where I can find info on them (like kubuntu) especially one for e17-ubuntu :P
<mdz> jbailey: at a minimum I need a hook facility so that I can get some additional scripts run at boot time
<jdub> morning boys and girls, and elmo
<tseng> good morning jdub!
<Nafallo> jdub: morning :-)
<tseng> tim: kubuntu is the biggest, but guadalinux and gnoppix are ubuntu based as well
<tseng> tim: im not sure there is a list.
<tim> tseng, thanks :)
<jbailey> mdz: I don't yet, although I've promised one to the guy who'll be doing the Debian merges.
<mdz> jbailey: who's that, out of curiosity?
<jbailey> maks.  He's expressed interested in the initramfs work and has been doing some bug fixing on the Debian initrd-tools stuff.
<jbailey> Not yet a DD.
<jbailey> Hmm, no debs for bazaar-ng.
<ajmitch> hi jsgotangco 
<jsgotangco> morning!
<jbailey> mdz: I'm going to go out for a walk in amoment - do you have any questions about the setup before I go>
<mdz> jbailey: nah, I'm going to have to do the first iteration by hand anyway
<jbailey> Cool.   /me goes for a walk.
<mdz> jbailey: so nfs root is working for you, right?  having some difficulty here
<mdz> "mount: No such device" "short read: 0 < 28"
<mdz> after successful ipconfig
<mdz> ah, need to specify the nfs module explicitly
<mark_al> hi, can anyone tell me how to capture lots of useful info to add to a bug report? its for a problem with a kernel module (snd-usb-audio) which worked fine in warty
<wasabi> Man. THe Java stack that is going to come along with Ooo2 is really going to screw up the idea of putting it all on one cd
<wasabi> Hmm, or maybe not.
<wasabi> gcj is awefully tiny.
<kent> wasabi, perhaps change it to "all in one dvd" ;)
<kent> and all in two CDs.
<Kamion> the one-CD thing is really non-negotiable
<Kamion> if OOo2 doesn't fit, we get to (a) trim it down (b) throw out other stuff (c) bin it :-)
<wasabi> The one CD thing has many benefits.
<wasabi> It's one of my fav features heh
<mdz> mark_al: it really depends on the bug
<mdz> mark_al: try in #ubuntu
<mark_al> cheers
<mdz> jbailey: the mount in klibc is giving me headaches
<mdz> it doesn't seem to pass all of the options correctly
<wasabi> mdz, i have uploaded a fixed antlr. it now builds with gcj-4 and friends. Problem is they are all in universe... so now antlr is.
<wasabi> The entire stack needs to jump over.
<mdz> wasabi: gcj-4 is in main
<wasabi> java-gcj-compat isn't, then.
<wasabi> that'll be....
<wasabi> ecj-bootstrap and java-gcj-compat.
<mdz> wasabi: I'll take a look at it once everything is built, so we can see the dependency chains
<Unfrgiven> how do i regenerate a makefile.in after changing makefile.am?
<mdz> Unfrgiven: autoreconf
<jbailey> mdz: nfsroot is working, yes.  I tested both regular boot and nfs boot today.
<mdz> jbailey: yeah, got that working, now only mount is causing me trouble
<mdz> it mounts, but apparently not all of the options make it to the kernel
<mdz> doing a similar mount later, with util-linux mount, does the right thing
<jbailey> Ugh. =(
* wasabi wondering what new super-cool features are on the horizon if ya'll are messing with nfsroot
<mdz> jbailey: if I set BUSYBOX=y, will that use busybox instead of uclibc's tools?
<jbailey> Could easily be a klibc bug then.  I haven't explored all of that.
<mdz> wasabi: ThinClientIntegration, for one
<jbailey> mdz: No, the only thing it does is call busybox if you drop to a shell (add break to the kernel command line)
<jbailey> I didn't want behaviour to change just because you wanted a sane shell for debugging.
<mdz> er, s/uclibc/klibc/ of course
<mdz> jbailey: anyway, other than that hangup, I've got thin clients booting
<mdz> to a shell
<mdz> by hacking up /usr/share/initramfs-tools/scripts/nfs
<mdz> what I really want is to let it mount an NFS root fs as normal, and then run a hook later which can set up the unionfs
<jbailey> Cool.  Will you email me your nfs stuff?  I'll hack in a script.  I tried an import earlier and wound up filing a bug on baz.
<mdz> jbailey: the hacking up was entirely thin-client specific except for two things
<mdz> 1. mkdir /tmp
<mdz> 2. . /tmp/net-${DEVICE}.conf
<mdz> but I'll send you a copy so that you can get an idea of my needs
<jbailey> Should the unionfs be set before init is called?
<mdz> jbailey: unless we want to go back to using pivot_root, yes
<jbailey> 'k
<mdz> init needs to run within the unionfs root
<jbailey> Okay.  I wasn't sure, since many filesystems mount readonly anyway.
<jbailey> root filesystems, rather.
<mdz> well, the unionfs is actually a separate filesystem, so we need to run inside it
<jbailey> Okay.
<jbailey> Will the nfs script you send include the options you need passed in?  I can check the klibc nfsmount code at the same time.
<mdz> jbailey: what's the trick to running the stuff in /usr/lib/klibc/bin?
<mdz> jbailey: yes, it does
<Kamion> lamont: debconf still isn't building
<Kamion> admin/debconf_1.4.50ubuntu1: Dep-Wait by buildd+vernadsky [important:out-of-date] 
<mdz> I was just going to test that hypothesis on a real system using klibc mount, but it doesn't run
<Kamion>   Dependencies: libqt-perl (>= libqt-perl_3.008-1.3build1)
<Kamion> lamont: that version looks bogus
<mdz> oh, it expects to find a klibc loader in /lib
<jbailey> mdz: They're not real ELF executables, that's why I didn't stuff them in the path.  It needs the klibc library in /lib
<mdz> jbailey: is there a trick I can use to get them to run, or do I need to mess with /lib?
<jbailey> mdz: If you copy the library into /lib they should run.
* mdz twitches at the cruft
<jbailey> mdz: I can include a symlink in the next upload (or just move the library) if that's worthwhile.
<mdz> jbailey: is it possible to run them from the build tree?
<mdz> I'm sure it's some silly C string handling bug or something
<mdz> in particular, this doesn't look right:
<jbailey> The last time I did it was before they had dynamic linking working, I don't know off hand.
<mdz>         if (extra->used_size)
<mdz>                 *extra->end = ',';
<mdz>         strcpy(extra->end, s);
<mdz> surely that should increment ->end rather than clobbering it?
<mdz> I think this code was written and never tested
<mdz> since a typical initramfs setup will never exercise it
<jbailey> Entirely possible.
<jbailey> I don't know how much of it was hacked out of the kernel or where it came from originally.
<jbailey> I know that it's targetted to be shipped with the kernel, though, so that seems likely.
<manulito> Hi, im a 25 year old cs-student from sweden, have some short questions about how to join a team, anyone have a few minutes to spare ?
<bob2> just ask your question
<bob2> (s)
<manulito> im planing to join some opensource devel-team after the summer, just wanna know what skills are needed and what i should improve on during the summer
<manulito> have some extra time to read/learn, and wanna get some pointers on what skills are important :>
<mdz> there is some sketchy stuff in there
<mdz>         if (newlen >= extra->alloc_size) {
<mdz>                 char *new;
<mdz>                 new = realloc(extra->str, newlen + 1);  /* +1 for NUL */
<mdz>                 if (!new)
<mdz>                         return;
<mdz>                 extra->end += new - extra->str;
<mdz> "new - extra->str" where "new"  is the return value of realloc and extra->str is some other pointer?
<bob2> manulito: depends on what you want to work on
<daniels> oh, creative
<daniels> extra->str was the original pointer
<mdz> manulito: it depends on what sort of projects you'd like to work on.  C programming and Python programming are both useful
<bob2> people generally work on things they care about
<daniels> so it's the delta of the length (newlen - oldlen)
<mdz> how do you figure?
<mdz> realloc is allowed to return you a pointer someplace far away in memory if it feels like it
<mdz> that may work if it never ever moves
<dilinger> wow
<dilinger> mdz: what are you looking at/
<mdz> dilinger: klibc
<dilinger> cute
<dilinger> doesn't extra->str already have the +1 for \0?
<mdz> it makes me want to die
<dilinger> and why can't extra->end += newlen - extra->alloc_size?
<dilinger> and yes, if realloc moves it.. extra->end is no longer valid, i would gueess
<mdz> dilinger: don't ask me; look at the previous snippet I pasted too
<daniels> mdz: hey, I'm just saying what the code is supposed to do, not what it necessarily actually does ;)
<mdz> daniels: I bet it does exactly that 99% of the time
<manulito> bob2: last 3 years in school have been different types of courses in programming etc, tho i never written anything real, i have no clue were to start, how to take the step from schoolproject -> real project
<dilinger> i assume the previous snippet just has a typo.  strcpy(++extra->end, s);
<mdz> and then randomly falls over if it grows beyond some unpredictable length
<dilinger> the purpose would be to simply add a comma if there's something already there (extra->used_size != 0)
<jbailey> mdz: The klibc realloc code might be dumb enough to just fail if it can't expand the code segment.
<mdz> dilinger: I understand what it intends to do
<mdz> but it's buggy
<dilinger> jbailey: nothing like writing code that depends on such a feature :)
<mdz> in more than one place
<jbailey> Frightening behaviour to depend on, though.
<mdz> somebody remind me why we need yet another libc implementation?
<jbailey> mdz: combination of size (not glibc), arch support (dietlibc) and licence (uclibc) IIRC.
<mdz> I'm not entirely convinced by the size argument
<mdz> yeah, glibc is huge
<mdz> but the stuff we're putting on top of it is *tiny*
<jbailey> We don't have the very-small requirement, but this stuff is intended to ship with the kernel as a standard set of utilities to run for early userspace.
<manulito> mdz: so improving my c knowledge is prehaps best way to start then?
<mdz> manulito: yes, in particular you could help me debug klibc's mount option parser :-)
<jbailey> For an embedded system, this would be beautifully small.
<zul> mdz: that must be fun
<manulito> mdz: might help you out in half a year or so :>
<mdz> this code could not possibly have ever worked
<camilotelles> anybody saw this? google is giving US$ 4.500,00 for studentes who wants to help open source 
<mdz> camilotelles: yes, we're one of their open source partners
<camilotelles> http://code.google.com/summerofcode.html 
<mdz> camilotelles: look at the list of participating organizations
<camilotelles> mdz: I saw this. Maybe it's interisting to put in the bounties page. 
<mdz> camilotelles: that's backwards; Google links to the bounties page
<camilotelles> mdz: ok. 
<wasabi> i swear, latest breezy update remapped all of my control keys in some way I have not yet figured out
<daniels> wasabi: x in breezy is currently 'interesting'
<wasabi> exciting.
<mdz> daniels: speaking of which, what's the plan wrt /usr/include/X11 vs. /usr/X11R6/include?
<mdz> there seems to be stuff in both places at the moment
<daniels> mdz: right.  everything will eventually move to the former.
<daniels> by 'eventually', I mean 'asap'
<mdz> I had something ftbfs because it didn't -I/usr/X11R6/include; not sure if that's a common failure or not
<daniels> it's reasonably common, yeah
<wasabi> It's nice to see all these long standing annoyances being fixed.
<daniels> most of them will go away when I've finished with xorg -21 and to -22, where I break out libX11
<wasabi> (/usr/X11)
<daniels> meaning that Xlib.h moves to /usr/include/X11, which is responsible for 99% of those failures
<daniels> (unfortunately, libX11 is also the most complicated library to transition, by far)
<mdz> jbailey: ok, got it working
<mdz> I fixed no less than 3 bugs in that 15-line function
<mdz> jbailey: are you sure we want to entrust the health and safely of early userspace to this thing?
<jbailey> mdz: That sounds way more fragile than I had expected it to be. =( 
<jbailey> My tests had all revolved around booting.  the udev maintainer (greg kh, who also does the minor security update kernels) bundles it in his packages and such too.
<mdz> unfortunately, that wasn't what was breaking unionfs
<mdz> it's now getting all of the options I gave it, but it isn't quite working right yet
<mdz> I can create files and delete files, and that all works properly
<mdz> but I can't clobber files
<jbailey> Is that likely to be a kernel problem or something still in the klibc utilities?
<mdz> likely to be a unionfs problem
<mdz> or just me not understanding it properly, but I think i'm doing it right
<mdz> jbailey: any reason why scripts/nfs uses $NFSROOT instead of the backward-compatible stuff that ipconfig helpfully provides?
<mdz> yeah, I can reproduce the unionfs difficulty in a non-klibc setup as well
<jbailey> ipconfig provides the NFSROOT variable?
<jbailey> From DHCP if available, I'm guessing?
<mdz> jbailey: see dump_device_config
<jbailey> I'll paste that into gedit for tomorrow.  Angie and I are going through things to get ready to move.
<mdz> I'm getting this bad feeling about unionfs
<mdz> I wonder whether knoppix does something about this, or just ignores the problem
<mdz> hmm, changing the nfs mount from read-only to read/write seems to fix it, odd
<mdz> unfortunately, klibc's nfsmount doesn't let me specify -r or -o ro
<mdz> oh, -o ro does work
<mdz> yay, working now
* dilinger reads the SMARTMonitoring wiki and hrms
<dilinger> interesting comment on the linuxjournal page, about smartd using dbus instead of email notifications and syslog
<dilinger> too bad the smartd code is clearly something that was not designed, but just kind of grew into the shape its currently in
<jbailey> mdz: Got the patch, thanks.
<fabbione> morning
<lamont> fabbione: -20.3 built.  congrats
<fabbione> lamont: rocking :)
<fabbione> mdz: ping?
<lamont> dpkg: error processing /home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/xscreensaver_4.16-1ubuntu13_i386.deb (--unpack):
<lamont>  trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in package libxt6
<lamont> daniels: you around???  ^^^
<lamont> where are the mono-bitches?
* lamont wonders if mono needs some bootstrapping love on ppc
<lamont> fabbione: so your patch will make it into daniels' -21?
<fabbione> lamont: did you push the patch to daniels?
<fabbione> ahha
<fabbione> ok
<fabbione> let's ask him
<fabbione> daniels: dude?
* lamont is going to sleep soon
* fabbione just woke up and he is dead tired
<daniels> lamont: the *what* now?
<fabbione> daniels: http://people.ubuntu.com/~fabbione/993_hppa_has_no_dri.diff
<daniels> lamont: i'll look at the xss thing, but, uhm, not my fault, yeah?
<fabbione> daniels: we figured why ati was not building on hppa
<lamont> daniels: it has an x in the name, though. :-)
<lamont> and then there's fabbione's patch for ati.. kthxbye. :-)
<fabbione> daniels: basically extensions/dpms.h is a valid include path when we include -I$(TOP)/include
<daniels> fabbione: is that to get dpms.h?
<daniels> yeah, that needs to be fixed in debian/patches
<daniels> that'll go in -21
<lamont> woot-ness
<fabbione> daniels: but for the ATI driver that path is available via $(DRIINCLUDES)
<fabbione> that is not available on hppa
<fabbione> so it needs to be forced
<daniels> well, alternately we just fix everything to refer to <X11/extensions/dpms.h> :)
<daniels> only reason I didn't catch that was because it was a new #include added in a patch
<fabbione> daniels: please note that there is definition of __hppa__ or HPArchitecture there.
<daniels> not in the original source tree
<fabbione> daniels: no no
<daniels> yeah
<fabbione> if you add X11/
<fabbione> you get to include the one in /usr/include/....
<daniels> fabbione: right :)
<fabbione> you really want to fix the Imakefile :)
<daniels> it works from within the source tree, because dpms.h is in exports/include/X11/extensions
<daniels> fabbione: eh, that's going to break with -21
<fabbione> nope. it's in xc/includes/extensions/
<fabbione> and it's part of the tree
<daniels> because dpms.h gets built externally, and is only available from within /usr/include/X11/extensions :P
<daniels> fabbione: right
<daniels> fabbione: and the tree builds up an exports directory
<daniels> -Iexports/include is always true
<fabbione> that is not used to get to dpms.h
<daniels> and BuildIncludes (or whatever it is) will symlink dpms.h from there
<fabbione> not in that case
<daniels> so exports/include/X11/extensions/dpms.h points to include/extensions/dpms.h
<daniels> trust me -- this is how I fixed it for r128 when lamont bitched earlier
<daniels> i just forgot to do radeon
<fabbione> ok
<mdz> fabbione: pong
<fabbione> mdz: http://people.ubuntu.com/~scott/ongoing-merge/lm-sensors/lm-sensors_ubuntu.patch
<fabbione> mdz: MOM did never see your patch to debian/control :/
<fabbione> that's why it got lost
<mdz> fabbione: that's very strange
<fabbione> mdz: well that's what i can see :(
<whiprush> howdy gents
<mdz> the changes are clearly present in 2.8.8-7ubuntu2
<whiprush> jdub: fridge!
<whiprush> hmm, I have a feeling that jdub is on a plane.
<fabbione> mdz: for some reasons MOM used a different orig as base for the REPORT
<mdz> fabbione: that MOM output is newer than the version in breezy
<fabbione> mdz: so iam not 100% sure if we lost other bits too, but i will look into it.. it was just to inform you
<fabbione> oh
<fabbione> that explain
<mdz> fabbione: so it is diffing against the current breezy version, which is already missing the changes
<mdz> check with Keybuk and see if he saves the old output
<fabbione> right
<fabbione> ok
<ivoks> 'morning
<pitti> Morning
<\sh> morning
<Burgundavia> when is the next cc meeting?
<fabbione> mdz: new lm-sensors on the way...
<fabbione> mdz: 2 things i find weird tho... so many changes passed unseen and that i never got a mail from bugzilla for a new merge request
<fabbione> hey pitti
<fabbione> pitti: 10128 it's all your :)
<Lathiat> hmm im hitting some bug in the installer where i setup an already formatted ext3 as / then when i hit finish and write changes it just goes back to the menu again
<Lathiat> could be somethign to do with installing on /dev/hde1 as the only disk or something as the same setup worked yesterday when it was hda, interesting.
<fabbione> daniels: checking for X11/extensions/xf86vmode.h... no
<fabbione> daniels: i think freeglut needs to grow an extra b-d
<pitti> Riddell: ping
<daniels> fabbione: whoohoo :\ let me take care of that now
<Mithrandir> daniels: any thoughts on how the NX stuff in universe should be done?
<fabbione> infinity: ping?
<daniels> Mithrandir: is 'not at all' a valid answer? :P
<daniels> Mithrandir: what's the build system like?  i've not looked at it
<Lathiat> daniels: Whats the rationale behind moving all the X stuff around into /usr?
<fabbione> infinity: unping
<fabbione> Lathiat: killing X11R6 ???
<fabbione> that is not even FHS compliant anymore iirc
<Lathiat> so its basically just getting rid of /usr/X11R6 ?
<Lathiat> because its 'wrong' ?
<fabbione> it's lovely how kdebindings build-deps on GTK :)
<Lathiat> haha
<daniels> killing /usr/X11R6 is FHS-compliant
<daniels> you just have to do it properly :)
<daniels> (i.e. turn it into a bunch of symlinks)
<daniels> but we're not FHS-compliant for a bunch of reasons anyway, so *shrug*
<Lathiat> daniels: im not whinging about how its going i was just wondering why it was being done :)
<Mithrandir> daniels: libXcomp uses an automake-ish system, some of the nx-X11 is really a forked Xfree/Xorg tree and uses imake.
<Mithrandir> daniels: "not at all" is not a valid answer, no. :-)
<daniels> Mithrandir: yet everything you tell me makes me lean further and further towards 'not at all' :P
<daniels> so, uhm
<fabbione> infinity: is the i386 buildd lagging?
<daniels> are the patches clearly articulated?
<daniels> like, is there a diff we could apply to the modular libX11 to enable it as a config option?
<Mithrandir> daniels: heh.  I wonder if they'll take patches to the build system so it'll be non-insane.
<Mithrandir> daniels: probably not.
<daniels> heh
<daniels> my enthusiasm is not increasing :P
<daniels> Lathiat: because when we get X11R7, having /usr/X11R6 will be strange
<Mithrandir> I should really find some of the upstream people and ask them if they want it integrated in xorg and how.
<daniels> Lathiat: and no-one's ever been to explain its existence except for 'hysterical raisins'
<Lathiat> daniels: :)
<daniels> Lathiat: so it's traditionally been everything in the X SI
<daniels> but that concept becomes meaningless with the modular tree
<Lathiat> right
<daniels> and arguably it became meaningless the minute the SI produced more than one binary package
<infinity> fabbione : Doesn't look lagging to me.
<infinity> fabbione : Is there a specific package you're concerned about?
<fabbione> infinity: ok... 
<fabbione> yes.. lm-sensors 1:2.9.1-1ubuntu1
<fabbione> infinity: it's up for all arches != i386
<fabbione> (at least in the buildlogs on people)
<infinity> fabbione : On i386, it's dep-wait on i2c-source.
<fabbione> ah crap
<fabbione> ok
<fabbione> i will have to upload ubuntu2
<fabbione> thanks
<infinity> fabbione : Let me know when you do, so I can clear the dep-wait.
<fabbione> hmm no
<fabbione> can you clear the d-w?
<fabbione> i removed the build-deps on it
<infinity> Cleared.
<fabbione> thanks
<fabbione> bbl
<sabdfl> morning fabbione
<sabdfl> what's  rockin' in ubuntu-land today?
<pitti> Morning sabdfl
<jsgotangco> hey sabdfl 
<Treenaks> sabdfl: working encrypted storage on USB sticks etc.
* Treenaks needs to dive into hal docs to start on that new formatter thing
<sabdfl> Treenaks: that's pretty cool. would that work with the live cd?
<Mithrandir> Treenaks: shiny.
<Treenaks> sabdfl: ask pitti - I think it would
* jsgotangco just deployed 2 5.04 servers to a client
<pitti> sabdfl: yes, it should already work for encrypted USB sticks and the like
<sabdfl> jsgotangco: the snowballing is growing quickly :-)
<pitti> sabdfl: there are still some issues with unmounting, but the mounting side is already "rocking" :-)
* jsgotangco wants to hug thom and daniels for "excellent" apache2.conf
<sabdfl> very cool
<pitti> Treenaks: btw, are you interested in hacking the floppy formatter to support other media and encryption? or rewrite one from scratch?
<Treenaks> pitti: yes, and I think rewriting is the easiest way
<Treenaks> pitti: all I need is a way to ask HAL for "all volumes that are not mounted"
<pitti> Treenaks: that's easy
<Treenaks> pitti: it probably is, but I can't find any proper docs on hal's dbus interface
<pitti> Treenaks: hal-doc package
<pitti> Treenaks: this is pretty fine
<Treenaks> pitti: just strip libhal_ and underscores from function names, and apply WikiCaps, I guess?
<pitti> Treenaks: hm?
<Treenaks> pitti: hal-doc contains api docs for the C libhal
<pitti> Treenaks: you probably want all the get_property() etc. cals
<pitti> Treenaks: ah, no idea for python, sorry
<Treenaks> pitti: I'll tear the device manager apart then :)
<infinity> fabbione : lm-sensors uploaded.
<mvo> morning infinity!
* infinity hides from mvo.
<pitti> Hi infinity 
<infinity> ... and pitti.
<mvo> haha, no worries :)
<pitti> hehe, /me wanted to haunt infinity with mozilla crap :-)
<infinity> mvo : Want to ping me via email with that arch repo info?
<mvo> infinity: yes, I will do
<infinity> pitti : Yeah, I knew you did.  I need to get some more test builds done to figure out what happened to your poor middle mouse button.  The rest seems good now.
* infinity goes to reboot the amd64 and turn it into a build host again for the evening.
<daniels> infinity: you can use mine if you want to keep on using the laptop
<pitti> infinity: do you still have your "ludicrous speed" machine to do builds on?
<infinity> pitti : Aye.
<pitti> infinity: otherwise we can use the DC
<pitti> ah, ok
<infinity> daniels : No one in their right mind WANTS to use my laptop.
<daniels> infinity: well, if you don't want to reboot the amd64
<infinity> Too late. :)
<infinity> Hrm.  That's kinda creepy and wrong-seeming.
<infinity> The latest Win32 SATA driver update seems to have silently updated my SATA controller's firmware too.
<infinity> Go VIA.
<Kamion> infinity: could you poke the debconf dep-wait for me, please? its syntax is wrong (look at the version)
<infinity> Kamion : Neat.  Should that just be cleared, or should I fix the syntax?
<Kamion> it can just be cleared
<infinity> Right.  Well, version "m" of libqt-perl is now available.  <cough>.. Go wanna-build.
<fabbione> infinity: great thanks
<Kamion> version "m"? boggle.
<infinity> Kamion : Well, "m" is higher than "libq..." :)
<infinity> Kamion : So, --pretend-avail libqt-perl_m clears the horribly broken dep-wait. :)
<JaneW> infinty! where you been hiding?
<infinity> JaneW : Didn't know I had been.
<JaneW> infinity: well actualy neither did I, but mdz though you had ;)
<infinity> JaneW : Oh, well I suppose I should fix that, then.
<Kamion> infinity: hahaha
<JaneW> infinity: anyway we were hoping for a status update on the breezy goals you are assigned to.
<infinity> JaneW : Ahh, let me tear through the list again this evening and I'll update them on the wiki and ping you via mail.  Cool?
<JaneW> infinity: perfect thanks
<Treenaks> pitti: there's a python example in the last few pages of the hal 0.5.2 spec
<seb128> daniels: any reason to not fix xkb/xorg?
<daniels> seb128: could you possibly be less patient?
<seb128> no
<seb128> I can't work with broken keyboard
<daniels> that's a concern
<seb128> you have a fix, just upload
<daniels> arguably I can't work with my panel killing my machine every other day
<daniels> dude, I've been shepherding all its prerequisites through
<daniels> which I was doing at 5am last night
<seb128> hum, I don't think the panel is such an issue
<daniels> i'm not withholding it because I hate you or anything
<seb128> I know, but you have no idea of the number of people who asked me why we are not fixing such an annoy bug during the GUADEC
<seb128> especially since there is a patch for days
<daniels> have you tried the patch?  it doesn't actually work.
<seb128> people send half written mails, close tabs instead of opening new ones and trash their job, etc
<daniels> so why are they using breezy?
<seb128> dholbach said than removing the part from the package patch works
<seb128> because they are GNOME upstream and working on 2.11?
<daniels> that will break different things, actually
<seb128> you want to kick them away saying to go back to jhbuild?
<seb128> that's not serious...
<daniels> look, there you go, I just killed my test build and uploaded -21
<daniels> i don't know if it will even build from source
<daniels> i'm not entirely convinced that I care at this point
<daniels> but enjoy
<seb128> thanks
<seb128> daniels: sorry to piss you, I know that's breezy is a working place, but the fact is than people are using it, that's broken for a while now and they are starting to be really not happy ... anyway thanks for fixing it :)
* fabbione attempts a breezy server netinstall
<seb128_> grumpf, dsl IP change .. if somebody said something to me for a few min please say it again :)
<bob2> but, regardless, 'wanna do?' is the coolest isp name, ever
<jsgotangco> bye bye
<mdke> bob2, really?
<mdke> i has always kinda bugged me that name
<Amaranth> 'wanna do?' maybe be the coolest, but 'cox' is the funniest ;)
<mdke> i/it
<mdke> yeah cox is cool
<bob2> 'chubby cox' is the coolest-named character on sealab, too
<Amaranth> *boggle*
<Amaranth> wtf
<bob2> he's a teen sensation!
<Lathiat> mdz: whats up with php5-imap ?
<pitti> daniels: ping
<Amaranth> if it's about X you might want to tell him tomorrow :/
<pitti> daniels: Debian fixed an important bug in gdb which I'd like to sync for Ubuntu. Our only change is #4132
<pitti> daniels: is this bug still an issue? our current version of gdb still uses type handling in the build-deps
<pitti> daniels: if it's not an issue any more, I'd just like to request a sync
<Kamion> type-handling is still an issue
<Kamion> and we don't have type-handling in the build-deps at the moment
<fabbione> pitti: is all public the crack?
<pitti> Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), tetex-bin, libncurses5-dev, libreadline4-dev (>= 4.2a-1), bison, gettext, debhelper (>= 4.1.46), dejagnu, gcj [!mips !mipsel] , gobjc, mig [hurd-i386] , cdbs (>= 0.4.17), quilt (>= 0.30-1), libkvm-dev [kfreebsd-i386] , libunwind7-dev [ia64] , flex | flex-old
<pitti> Kamion: the [platform]  thingies aren't type-handling?
<Kamion> I see no type-handling
<pitti> fabbione: yes
<Kamion> no, they are certainly not
<fabbione> pitti: ok
<bob2> type-handling: crack or no crack?
<Kamion> type-handling is a package
<Kamion> [...]  is simply an architecture-specific build-dependency
<pitti> ah, ok
<pitti> so we should merge instead
<Kamion> Build-Depends: autoconf, libtool, texinfo (>= 4.7-2.2), tetex-bin, libncurses5-dev, libreadline4-dev (>= 4.2a-1), bison, gettext, debhelper (>= 4.1.46), dejagnu, gcj [!mips !mipsel] , gobjc, mig [hurd-i386] , cdbs (>= 0.4.17), quilt (>= 0.30-1), libkvm-dev [kfreebsd-i386] , type-handling (>= 0.2.1), libunwind7-dev [ia64] , flex | flex-old
<Kamion> ^-- Debian gdb build-deps
<pitti> daniels: alright, do you want to take #11362? or shall I?
<pitti> daniels: yay new xorg :-)
<Mithrandir> pitti: is the key issue fixed?
<pitti> Mithrandir: I hope so, I'm eager to download the debs :-)
<pitti> Mithrandir: but it was uploaded like half an hour ago, so it'll build a while
<Riddell> pitti: morning
<pitti> Hi Riddell 
<pitti> Riddell: I saw your kdegraphics changelog, does that mean that the xpdf issue is already solved properly?
<pitti> Riddell: yesterday we discussed porting pdfinfo to libpoppler, similar to the change we did to cups
<Riddell> pitti: no, it's a quick fix doko asked me to do
<pitti> Riddell: ok, ogra wanted to port the xpdf-utils tools to poppler, and create a poppler-utils package
<Riddell> pitti: porting pdfinfo to libpoppler sounds great
<pitti> Riddell: so you could change the dependency to poppler-utils then
<pitti> Riddell: alright; can you please coordinate this with ogra?
<Riddell> so I have to teach ogra c++ then :)
<Riddell> he can teach me good python in return
<pitti> oh, porting these beasts is not a big deal
<Riddell> pitti: how different is libpoppler from xpdf?
<pitti> Riddell: it's actually the xpdf code
<pitti> Riddell: the libpoppler-dev package contains the xpdf headers
<pitti> Riddell: there is a much nicer interface libpoppler-glib-dev
<pitti> Riddell: which shuold be used in new apps
<pitti> Riddell: but for the sake of porting the xpdf utils, libpoppler-dev is fine
* Riddell considers portiong to libpoppler-qt-dev instead
<Amaranth> before i actaully implement this, does anyone think `ps -U $LOGNAME | grep kicker` is a bad way to see if you're running KDE?
<Mithrandir> Amaranth: yes, it's a terrible way, as I told you yesterday.
<Amaranth> explain?
<infinity> Amaranth : Sounds prett dodgy to me.
<infinity> Amaranth : I could be running kicker in a chroot under that username, running it on a different display (again, same username), or even debugging a private application which just happens to be called "kicker".
<Mithrandir> Amaranth: you can run multiple sessions at once.  You can't _know_ that the kicker you see is actually KDE's kicker.
<seb128> pitti: if somebody start porting xpdf-utils to poppler please mail ploppler-list before
<Amaranth> Got a better way?
<Amaranth> It's either this or fix kicker.
<Mithrandir> Amaranth: then fix kicker.
<pitti> ogra: see seb's comment ^ 
<Amaranth> No one will take my fix.
<Amaranth> Even if I knew how.
<pitti> seb128: right, so far I only did it for pdf2ps
<seb128> pitti: I've asked on #evince, apparently nobody is working on this and they think that's cool, but better to mail
<Mithrandir> Amaranth: what problem are you trying to solve?
<Amaranth> Mithrandir: Ubuntu installs KDE's applications.menu as kde-applications.menu (what was the fd.o menu spec for again?) so if the user is running KDE and that file exists I need to use it.
<seb128> pitti: k
<Mirv> hi, will Ubuntu be present at Debconf here in Helsinki? if you are planning to come, I could add my "Ubuntu Finland" part somehow to it :) (mainly just some banner or so pointing to www.ubuntu-fi.org)
<Mithrandir> Amaranth: no, that's not the problem you're trying to solve.  What are you trying to do?
<infinity> Mirv : Many Ubuntuites will be there.
<Amaranth> That's the exact problem I'm trying to solve. It's for smeg, my menu editor.
<seb128> Amaranth: you want to do a KDE editor now?
<seb128> I don't think KDE guys will be interested by a pygtk menu editor
<Amaranth> seb128: pyxdg developer uses KDE, others have requested it too
<Amaranth> even as gtk it beats kmenuedit :)
<seb128> bah
<Mithrandir> Amaranth: so you're trying to write a menu editor which should edit the KDE menu if the user is using KDE and GNOME otherwise?
<seb128> you always have people asking for something
<Amaranth> Mithrandir: yeah
<seb128> doesn't mean that's a good idea
<Amaranth> seb128: I thought it would be easy to implement.
<Amaranth> seb128: And it is on non-Debian based distros.
<seb128> ??
<seb128> the spec has nothing specific to Debian
<Mithrandir> Amaranth: have a "KDE menu editor" and a "GNOME menu editor" and make the menu editor DTRT depending on what it's called as and ask if it's called with neither.
<Amaranth> no, debian and ubuntu don't follow the spec
<infinity> Amaranth : And why not just give it command-line switched --kde and --gnome, and have it called differently from the two different desktops.  People calling menu editors from the command line would be a rare bunch.
<seb128> Amaranth: GNOME follows it :)
<seb128> but right, there is no way to follow the spec and have differents menus
<infinity> Amaranth : Or, along the lines of Mithrandir's suggestion, call it ksmed and gsmeg, harlinked, and edit different menus depending on its image name.
<seb128> Amaranth: how are other distro solving this? Same menu for GNOME and KDE?
<Amaranth> seb128: appearently
<seb128> I doubt of it
<Amaranth> seb128: i've only been talking to gentoo guys
<Amaranth> their menus are applications.menu in KDE
<seb128> ah ah
<Amaranth> xdg list has an interesting solution
<Amaranth> requires a change to the spec, but it's better than what we have now
<Amaranth> infinity: I like that first idea.
<Amaranth> what do you guys do for xfce? it seems to be using gnome's menus
<Amaranth> what really sucks in that app developers who expect to be able to drop things in ~/.config/menus/applications-merged/ are going to be hurting on ubuntu
<mjg59> Mm?
<mjg59> The long-term goal is for everyone to be using the freedesktop menu standard, surely?
<Amaranth> yeah
<Mithrandir> the whole idea of ~/.config is utterly crackful.
<mjg59> Which would mean having the same menu for KDE and Gnome
<Amaranth> It would be easier if <Menu>s had OnlyShowIn options.
<seb128> why?
<mjg59> There's an equivilent
<Amaranth> You could have one applications.menu with all the info in it and still show different menus on different DEs.
<mjg59> Though Gnome currently ignores it
<Amaranth> gnome-menus ignores a lot of things
<Amaranth> i found out the hard way that 2.10 didn't have support for <Layout>
<mjg59> Someone should write a patch
<Amaranth> i released smeg 0.7 and had people complaining :/
<Amaranth> what is the equivilent?
<Nuffing> cvd: ping
<Nuffing> oops
<bob2> printk: 998 messages suppressed.
<bob2> sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in;
<bob2>    program cdparanoia not setting count and/or reply_len properly
<bob2> go cdparanoia, it's your bithday
<mdke> quick idea
<mdke> how about extending the irc log bot to ubuntu-xx channels?
<bob2> if you want a channel logged, just tell fabbione 
<fabbione> mdke: bad idea
<mdke> *laughs*
<mdke> fabbione, ok np, i just wanted to ask
<fabbione> bob2: no.. i have too many chans already
<bob2> hah
<bob2> fabbione: you wanted to add more before :P
<mdke> we had one in ubuntu-it supplied by chris haas but it seems to have gone now
<fabbione> bob2: one/two is ok.. not 20 coming from ubuntu-xx
<fabbione> bob2: because freenode doesn't allow a client to connect to more than N chans at a time
<mdke> fabbione, is it a question of load?
<bob2> oh yeah
<fabbione> mdke: it is a question of bw
<bob2> I didn't realise there were so many
<mdke> right ok
<mdke> fabbione, maybe we could think about another one on a different server?
<mdke> its no biggie i guess
<mdke> the channels could do their own
<fabbione> mdke: i would prefer -xx to have their own log bots 
<mdke> k
<fabbione> or bot
<mdke> smurfix, thoughts?
<mdke> fabbione, are you italian btw?
<fabbione> i don't mind giving out the setup.. but i just can't handle all from here
<fabbione> mdke: yes
<mdke> fabbione, che bello. Sure I understand the bw issue
<mdke> maybe smurfix will be up for it, otherwise the channels can do their own
<Treenaks> heh.. theregister:
<Treenaks> London Undergound to trial wireless services
<Treenaks> (sub-title: Cockfosters)
<bob2> yeah!
<bandini> daniels, fyi. in the -21 upload I had to change maplink() of xbase-clients.postinst: s/\/usr\/X11R6\/bin\/xkbcomp/\/usr\/bin\/xkbcomp otherwise I'd get an install failure
<mdke> rock
<mdke> Treenaks, good news
<mdke> depending on price
<bandini> daniels, otherwise -21 rocks. thank you very much
<mdke> fabbione, so would you shoot me the scripts?
<Treenaks> mdke: what? the wireless thing or the "cockfosters" subtitle?
<mdke> both ;)
<mdke> cockfosters is a station i think
<bob2> you're missing the point entirely
<Treenaks> mdke: a few people here liked that name very much
<bob2> THIS TRAIN IS FOR COCKFOSTERS
* Treenaks points at bob2, daniels and jdub 
<fabbione> mdke: http://freshmeat.net/projects/irclog2html.pl/
<mdke> well since you guys copy all your names off us, you probably have one too ;)
<mdke> fabbione, thanks
<fabbione> mdke: i use this one to convert from text to html
<fabbione> mdke: and a normal irc client to log in text
<fabbione> mdke: on top of that i rotate the logs once a day (logrotate is already installed)
<fabbione> that's all you need
<mdke> ok i'll give it a try, thanks
<fabbione> mdke: it's pretty simple really.. the "difficult" part is to get a good irc text client to save the logs in a proper format :)
<mdke> which do you use?
<fabbione> i use BitchX
<mdke> oh yeah
<fabbione> but if you are not familiar with it, use irsii
<mdke> i haven't used bitchx
<mdke> so yeah maybe i will try irssi
<fabbione> use irssi or whatever is called than
<fabbione> bitchx is less userfriendly :)
<mdke> there is an xchat-text isn't there
<mdke> dunno what its like tho
<fabbione> mdke: remember that it needs to be able to join n channels automatically
* mdke nods
<fabbione> and save a log file per each chan
<fabbione> otherwise you will get only crap out of it
<bandini> coolness.. the last xorg upload (-21) fixed #11188
<mdke> fabbione, thanks for your help
<mdke> gtg
* bandini updates bz
<terrex> where I can read a new-devel-in-ubuntu guide?
<terrex> well, i first want to be a packager
<Amaranth> read the debian new maintainer's guide
<ogra> terrex, and join #ubuntu-motu ;)
<terrex> all in debian guide is applicable to ubuntu?
<ogra> nope, but all in debian guide is applicable to learn basic packaging
<terrex> ok thx to both
<ogra> the ubuntu specific things you learn in #ubuntu-motu currently... we are working on some kind of handbook.... but that takes its time
<terrex> aha
<Riddell> terrex: http://www.ubuntulinux.org/wiki/KubuntuPackagingGuide
<\sh> Riddell: we should remove cdbs ;)
<pitti> fabbione: any particular reason why you added ocfs2-tools.spec to the diff.gz? I though that was only for building rpms?
<Riddell> \sh: cdbs is especially mentioned in the Thanks section at the bottom for their support of KDE
<fabbione> pitti: meh.. that's generated at build/clean time
<fabbione> pitti: i will clean it in the next upload
<pitti> fabbione: ah, ok. no big deal, I just wondered about it's purpose
<fabbione> pitti: building rpm's? :)
<ogra> Riddell, but new packagers should learn debhelper first.... cdbs is for the time you already know anything
<fabbione> hey didn't you know we are supporting rpm now? :P
<pitti> fabbione: *gulp*
<pitti> fabbione: does Keybuk already know?
<fabbione> pitti: no idea
<fabbione> ;)
<pitti> fabbione: ./usr/sbin/ocfs2console -> this is a sudo thing?
<fabbione> pitti: what do you mean sudo thing?
<pitti> fabbione: you have to run it as root (sbin)?
<fabbione> pitti: yes
<pitti> fabbione: or can it be run as normal user for some status displays?
<fabbione> pitti: nope
<pitti> ok
<fabbione> it uses /etc/init.d/oc2b to gather and do stuff
<pitti> ... and the daemon runs as root, I suppose :-)
<jbailey> ogra: =)
<ogra> :)
<fabbione> pitti: the "daemon" is in the kernel
<fabbione> pitti: but the daemon reads the config generated by the config tools
<fabbione> it's a bit complex but it needs root
<pitti> fabbione: ah, you pass the conf with module parameters? (just started to look at the init script)
<pitti> or /proc or /sys ?
<fabbione> pitti: not even :) the module just read /etc/ocfs2/cluster.conf 
<zul> hey
<pitti> fabbione: ah, ok
<fabbione> pitti: the init script does some stuff
<fabbione> an it is invoked a lot of times for different things
<fabbione> ocfs2console uses the init scripts to start and configure the cluster
<fabbione> or stop it....
<pitti> ah, nice format tool
<fabbione> at the same time it updates the config and mount points (dynamically)
<fabbione> pitti: http://people.ubuntu.com/~fabbione/Screenshot.png
<fabbione> so you get an idea on how it looks like ;)
<pitti> fabbione: just started the console myself, nice :-)
<pitti> fabbione: some day I have to test this
<fabbione> pitti: you were talking about pgsql supporting clustering
<pitti> looks sexy
<fabbione> my question is what kind of clustering does it support?
<Mithrandir> fabbione: you have to reformat to change the number of nodes?
<pitti> erm, the postmaster itself doesn't really
<fabbione> if it can share the same db files between several pgsql instances 
<fabbione> than you really want ocfs2 in background
<pitti> there are projects (like slony-1) that provide replication in clusters
<fabbione> Mithrandir: it depends.. if you exceed the previous format.. yes afaik
<fabbione> Mithrandir: but setting it to a higher number of nodes is always a good idea
<Mithrandir> fabbione: why not always set it to INT_MAX?
<pitti> fabbione: you shouldn't share the files itself, if you need this you need a replication server, otherwise you will get locking issues
<fabbione> Mithrandir: because each node takes quite a lot of space in the metadata
<fabbione> pitti: ok..
<fabbione> Mithrandir: it takes around 128Mb for a 4 nodes?
<fabbione> or around that 
<fabbione> so approx 32Mb for each node
<Mithrandir> fabbione: ew, ok.
<fabbione> Mithrandir: but that's common to GFS too
<fabbione> so i think it's just something related to the distributed locking manager design
* pitti -> lunch
<Riddell> Kamion: are you able to make a bunch of changes to the kubuntu seed?
<Nafallo> daniels: why can't xbase-clients be configured? ;-)
<doko> ogra, daniels: xscreensaver and libxt6 conflict ...
<doko> Unpacking replacement libxt6 ...
<doko> dpkg: error processing /var/cache/apt/archives/libxt6_6.8.2-21_i386.deb (--unpack):
<doko>  trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in package xscreensaver
<ogra> grrr
<ogra> i'll change it ....
<Mithrandir> why is that file even in xscreensaver?
<ogra> Mithrandir, its the dir, not the file....
<Mithrandir> ogra: no, it's a symlink.
<ogra> i'll just depend on libxt6, than should be sufficiant
<Nafallo> I remove xscreensaver ;-)
<fabbione> Kamion: ping?
<Nafallo> s/e/ed/
<Nafallo> but xbase-clients still stuck on the xkbconf-stuff so... :-(
<daniels> bandah yes, forgot about maplink; thanks
<seb128> daniels: keyboard works fine now, thanks from me and a bunch of other people :)
<daniels> np
<Treenaks> group hug!
* mvo hugs daniels
<Mithrandir> daniels: I think the postinst script in -21 is broken since it requires /etc/X11/xkb/xkbcomp to be a symlink to /usr/X11R6/bin/xkbcomp
<daniels> Mithrandir: right, band<someone> pointed that out
<Mithrandir> daniels: again, not picking on you but rather trying to give you useful feedback. :-)
<daniels> yeah, cheers
<daniels> that was the thing from above 'bandah'; was stuck in scrollback, so didn't notice that band<tab> didn't do anything
<doko> daniels: overall, good progress ;-)
<Mithrandir> daniels: you expect me to read scrollback!? :P
<Burgundavia> daniels, nice work on xserver seen this error yet? /var/cache/apt/archives/libxt6_6.8.2-21_i386.deb:  trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in package xscreensaver
<daniels> Burgundavia: yeah, I blame xscreensaver :P
<Mithrandir> Burgundavia: yes, ogra is fixing that in xscreensaver.
<Burgundavia> ah
<Burgundavia> ok
<Burgundavia> always good to blam somebody else
* ogra glares at thegreen border around the balck screen on his monitor that is not even able to switch consoles and wonders what daniels, Mithrandir and doko are talking about
<doko> ogra: take off the sun glasses
<ogra> doko, ah, that might be it :_P
<ogra> :-P
<herzi> ogra: hi
<ogra> hey herzi
<lamont>  /usr/bin/gdk-pixbuf-query-loaders goes into a nanosleep (apparently) infinite loop on hppa.  grumble
<trulux> pitti: join -hardened please, could mdz and fabbione do the same, please?
<tfheen> trulux: mdz is probably not up yet.
<ogra> LA ime -> 5:4 am
<trulux> tfheen: OK, anyways I need a kernel guy there and pitti, and someone from the board
<ogra> 5:45 even
<pitti> trulux: mdz is asleep
<trulux> ogra: I stay awake 'till 7:00am sometimes
<daniels> trulux: any particular reason?
<daniels> trulux: (why you need someone there from tech board)
<trulux> daniels: yes, I need to explain why we need the SSP changes introduced into the kernel and on the Ubuntu Security Center, among that there has been a delay since mdz replied to the spec. announcement
<plovs> anybody know where I can find docs on how to modify the install-cd (live-cd i found)
<fabbione> trulux: no i am busy sorry....
<daniels> is email not an option?
<fabbione> trulux: what's going on?
<daniels> trying to get people from Europe and the US together on IRC is generally difficult
<ogra> the  Ubuntu Security Center ? whats that ?
<Treenaks> daniels: we should move the continent closer to either Australia or Europe
<Treenaks> daniels: or abolish time
<trulux> fabbione: I'm also pretty busy, preparing exams and the like. for free, I take some time for this today though won't be more than one hour. need to finish a few things
<daniels> fabbione: or just move everything closer to australia
<fabbione> trulux: i did kindly ask you already to plan meeting in advance
<ogra> Treenaks, there is some space in the southern middle between africa and india, we could try to squeeze it in there....
<fabbione> trulux: i have another meeting at 16:00 UTC
<daniels> trulux: again, I strongly suggest you use email
<trulux> daniels: indeed
<ogra> Treenaks, then it would be even possible to drive to .au by car ;)
<fabbione> trulux: so i need to get ready for it
<trulux> fabbione: OK, will try to fit in my personal agenda if it applies for the case
<fabbione> trulux: i am not asking you to join our meeting, clearly you are welcome too
<fabbione> trulux: i am asking you (again) to send out meeting invitations to the relevant people with a bit of notice
<fabbione> so that we can actually be there
<trulux> fabbione: I mean to fit a meeting proposal in my agenda
<trulux> nothing more
<fabbione> ok
<seb128> Amaranth: do you have any hoary version of smeg?
<Amaranth> seb128: It needs a patched gnome-menus, http://dev.realistanew.com/smeg/installsmeg gets it (x86 only).
<seb128> k
<seb128> and the current version depends on pygtk 0.12?
<Amaranth> yeah
<Amaranth> we're about to release pyxdg 0.12.1 though
<seb128> I've just packaged 0.12
<seb128> grrr, lack of communication
<Amaranth> heh
<Amaranth> reordering things isn't possible with hoary's gnome-menus though
<Amaranth> needs support for <Layout>, 2.11.x only
<seb128> and any plan to have breezy package ?
<seb128> I mean universe package
<Amaranth> i have one built right now, was waiting on pyxdg 0.12.1 to get into main before trying to get smeg into universe
<Amaranth> lintian reports no errors on the package :D
<Amaranth> or warnings
<Amaranth> that was a pita to get
<lamont> gok-input.c:237: error: 'struct _GokInput' has no member named 'open'
* lamont kicks gok
<lamont> daniels: libdc1394_1.1.0-2 needs your love
<lamont> ditto for mgetty_1.1.33-2 
<lamont> (X include path b0rked)
<sabdfl> fabbione: i havea desktop machine that hangs fairly predictably on a regular basis, running hoary
<sabdfl> it's a dell
<sabdfl> it's survived a couple of hours of memtest86+
<sabdfl> will leave it running for 24 hours
<Amaranth> anyone else getting xbase-clients complaining about an xkb symlink?
<\sh> sabdfl: what do u expect? it's a dell :)
<sabdfl> what can i do to help debug it if it is in fact a kernel issue?
<sabdfl> \sh: it's holding up under memtest
<mantiena> seb128: Hi, are you gnome-system-monitor's maintainer in Debian ?
<Burgundavia> sabdfl, might it be hdd issues>
<Burgundavia> ?
<fabbione> sabdfl: what kind of freeze do you get? hard?
<fabbione> sabdfl: temperature problem?
<sabdfl> hard
<sabdfl> fabbione: happens when the machine is idle, too
<seb128> mantiena: yep
<Nafallo> Amaranth: yepp
<sabdfl> has SATA drives
<fabbione> sabdfl: hmmmm 
<sabdfl> so it could be in that driver stack somewhere
<\sh> sabdfl: i know those issues...even windows xp is running slow on those machines...slow == u have 2 2ghz machine and a amd 1.4ghz...and windows xp is faster on this amd 
<Amaranth> Nafallo: Know a fix? :) I know it's because of the symlink hackery I was doing a couple days ago.
<fabbione> sabdfl: can you try to boot with acpi=off and see if still freezes?
<Nafallo> Amaranth: not yet ;-).
<fabbione> sabdfl: SATA is kinda.. well *cough*crap*cough*
<sabdfl> fabbione: will try that tomorrow when the memtest is done
<fabbione> sabdfl: thanks :)
<sabdfl> fabbione: SATA is, or the linux drivers for it are?
<fabbione> sabdfl: the latter
<mantiena> seb128: it seems there is a problem with gnome-system-monitor in Debian - after installing latest version directory /var/scrollkeeper is created, while other gnome packages uses /var/lib/scrollkeeper
<fabbione> sabdfl: and we have something bad in hoary (SATA related)
<fabbione> sabdfl: we are working on a possible kernel point release to get it fixed
<fabbione> but i am not aware of that kind of problems with it
<seb128> mantiena: that's quite OT here, #gnome-debian on irc.gnome rather
<fabbione> (like freezing the machine so badly)
<daniels> sabdfl: what sort of video card do you have?
<daniels> sabdfl: if ATI, try running with the vesa driver and seeing if that makes a difference
<sabdfl> ATI pciexpress
<jnc> fabbione: i use a SATA optical burner, plextor 712-SA
<daniels> sabdfl: hm.  running fglrx or not?
<sabdfl> running open source driver ati
<jnc> it worked w/ Ubuntu Hoary, where previously this would not work with any other distro
<jnc> i say that by comparison, Ubuntu function with SATA is much appreciated
<fabbione> there we go :)
<sabdfl> daniels: fglrx is not working, which is why i asked for a backport of the newest version to hoary
<fabbione> jnc: thanks for the info, but unfortunatly there is a problem with a patch that has been pulled from upstream that might cause data corruption on CD/DVD burners
<jnc> fabbione: oh
<daniels> sab	i see
<fabbione> jnc: it's a corner case but rather annoying
<fabbione> unfortunatly we have been told only a week ago :(
<jnc> fabbione: i'm happy it works at all
<daniels> sabdfl: i'm looking at a kernel issue now (drm), where missing irqs could potentially cause hangs, but that doesn't relate to this case
<jnc> say um, i have been getting a --configure error when upgrading xbase-clients for breezy today
<jnc> is the trouble with where /etc/X11/xkb/xkbcomp symlink points to?
<jnc> that's what dpkg is saying anyhow
<daniels> jnc: known issue
<jnc> thanks
<jnc> is there a quickie 1 liner i can do to make it go away for now ? ;)
<daniels> edit /var/lib/dpkg/info/xbase-clients.postinst, change /usr/X11R6/bin/xkbcomp to /usr/bin/xkbcomp, run sudo dpkg --configure -a
<mantiena> Kamion: Hi, did you ask mdz yesterday about my casper improvements ?
<jnc> daniels++
<Nafallo> daniels: thanx :-)
<jnc> it's kind of nice dpkg allows that type of flexibility
<jnc> i wasn't aware of it priro
<jnc> s/priro/prior/
<thom> if amd64/breezy users haven't updated firefox to 1.0.4-1ubuntu3 please can they do so and confirm the random segfaults are gone?
<jnc> thom: and god bless, if those random segfaults are actually gone
* jnc pokes dpkg
* ogra tries
<Treenaks> thom: is it normal that I had to upgrade from mozilla-firefox to firefox by hand?
<ogra> Treenaks, will be handled by ubuntu-desktop....
<Treenaks> ogra: ah coolness
<Kamion> Riddell: sure
<Kamion> fabbione: yo
<Kamion> mantiena: no, that's your responsibility
<mantiena> ;)
<fabbione> Kamion: did you notice that the new ssh uses a knew format to store keys in .ssh/known_hosts?
<fabbione> Kamion: for approximately 10 minutes you made my heart beat stop
<Kamion> fabbione: yes, I deliberately enabled it :-)
<mantiena> Kamion: then maybe you already integrated finding and automouting hard disk partitions with casper ?
<fabbione> Kamion: and broke ssh <tab completion> on host names
<Kamion> upstream ships with it off by default pending more testing ... I tried it out, seemed to work, figured I'd give them the wider testing
<Kamion> fabbione: fun, I didn't know it used that
<fabbione> Kamion: yeps it does :)
<Kamion> fabbione: you can turn off HashKnownHosts, I didn't make any attempt to convert existing files
<Riddell> Kamion: http://muse.19inch.net/~jr/tmp/kubuntu-seed.text
<fabbione> oh not converting files is ok
<Riddell> Kamion: should end up much the same as it is currently
<fabbione> i just ended up with a file that looked hacked
<fabbione> Kamion: and you really scared the shit out of me
<Kamion> mantiena: no, I was waiting for partconf to wend its way through various upload queues, and I have spent most of today dealing with starting to move house
<Kamion> mantiena: today is not a good day to hassle me because I am EXTREMELY ANNOYED after dealing with letting agents. :-)
<jnc> thom: seems to be okay
<Kamion> fabbione: heh. I did note it fairly clearly in the changelog
<jnc> thom: i can't be sure, though it isn't crashing yet;   so it's at least as good as the last revision 1.0.4-1ubuntu2 amd64
<Kamion> I suppose I could add a NEWS entry
<Nafallo> daniels: workaround for "could not open default font 'fixed';"?
<Nafallo> :-)
<jnc> bring the wrath of Kamion, and you will learn to deal with the consequences mewhahaha
<fabbione> Kamion: yeah.. well.. you know..
<Kamion> mantiena: I have untested code for that.
<daniels> Nafallo: edit /etc/X11/xorg.conf, change /usr/lib/X11/fonts to /usr/share/X11/fonts
<daniels> thom: should firefox fix random segfaults on i386?
<daniels> Kamion: agents> i feel your pain dude, spent half my day chasing them around also
<jnc> daniels: w/re the font thing, is Ubuntu supposed to run a font server?
<mantiena> Kamion: hehe, give me that code, I'm very good for testing :)
<Nafallo> daniels: ahh, you've moved around _everything_, haven't you? ;-)
<infinity> daniels : It should also give you back massages.
<Nafallo> daniels: thanx again anyway ;-)
* mantiena today found bug in baz register-archive command ...
<daniels> Nafallo: yeah ... the fonts moved ages ago though
<daniels> jnc: no, we don't run xfs by default
<ogra> thom, didnt crash yet... i'll try to edit a wiki page.... lets see if the cursor keys work now
<daniels> infinity: bonus
<Nafallo> daniels: I've pinned hoary til today ;-).
<daniels> heh
<Kamion> mantiena: ask me tomorrow, it's not worth it until I've at least got rid of the really stupid bugs
<Kamion> mantiena: and you'll need a new live CD build anyway, or an upgraded partconf-{find-partitions,mkfstab}
* jnc dances "w00000000t! the dreaded xorg-x11 shortcut keys don't work no more bug is fixed"
* ogra declares thom to be the hero of the day in the amd64 world
<ogra> thom, works fine here
<mantiena> Kamion: I'm planing to build new live CD tonight :)
<Nafallo> ogra: ++
<Nafallo> wtf!
<Nafallo> my panel has blinking stuff :-P
<Nafallo> scary!
<ogra> for gaim ?
<seb128> that's stuff not stealing the focus
<seb128> no
<seb128> for everything
<seb128> that's new stuff not getting the focus due to focus steeling prevention
<Nafallo> ogra: synaptics ;-)
<ogra> seb128, but there is a gconf key.... ?
<seb128> no, why?
<seb128> I've patched wnck for that
<ogra> to disable it :)
<Nafallo> seb128: kewl. I was more than a bit surprised though ;-)
<seb128> read the changelogs...
<ogra> glow effect ? 
<seb128> correct
<ogra> heh... nice wording :)
<jnc> seb128: glow effect is dorky.  i like it. thank you
<seb128> thanks!
<jnc> i feel like i'm being warned about impending doom
<Amaranth> seb128: we're finishing up some root editting things then should have pyxdg 0.12.1 and smeg 0.7.1
<seb128> k
<Lathiat> daniels: dude - why default 3 button emulationo to false?
<jnc> though, i am quite confused about the lack of "Terminal" on the rootwindow menu
<pitti> yes, me too
<pitti> why did it disappear?
<Lathiat> seb128: did that xorg upload fix the xkb thing?
<daniels> Lathiat: because it's buggy as shit
<daniels> Lathiat: basically, sometimes you just lose button events for a while -- particularly with evdev
<daniels> Lathiat: so instead of press-move-move-move-move-move-move-release, you get move-move-move-move-move-move-move-move-press-release
<Burgundavia> daniels, is that why sometime my mouse wheel stops working?
<Lathiat> daniels: ah :\ cus like, lots of laptop only have two buttons, i guess i should stop using middle click paste
<Micksa> I'm having an interesting kernel problem with my new laptop here
<Micksa> nothing wants to run :(
<Treenaks> Lathiat: shift+insert = your friend
<Micksa> what does it mean if during boot it says that "0x1f0-0x1f7 is already in use" (by libata apparently)
<Lathiat> Treenaks: hmm
<daniels> Lathiat: yeah, it bites, but it needs to get fixed upstream fist
<daniels> Burgundavia: nope
<hunger> Lathiat: You can configure the touchpad to act to multifinger taps.
<Lathiat> daniels: righton
<daniels> Burgundavia: well, probably not
<Lathiat> hunger: alps touchpad here
<Lathiat> hunger: not synaptic
<Lathiat> (and that doesnt work afaik on alps, and even if it does, you need a kernel patch which is so effort)
<ogra> seb128, oh, its really glowing :) i was expecting an annoying flashing like WinXP has .... thats actually cool
<seb128> Lathiat: yep
* Micksa cries
<Lathiat> seb128: it did?
<Lathiat> seb128: hmm, maybe i can upgrade
<seb128> correct
<seb128> ogra: I've found that on FC4 packages while searching for an another stuff 
<Micksa> what's this glow efect?
<Micksa> effect
<ogra> seb128, goo decision... i take back my former words, no gconfkey needed :)
<seb128> rock
<Burgundavia> daniels, in terms of debugging the issue, what can I do?
<ogra> seb128, yes, as you regulary do ;)
<jnc> Micksa: mostly users will notice it with gaim application, when they are typing in say oowriter and someone messages them
<daniels> Burgundavia: um, not terribly much, I'm afraid, unless you insert a whole bunch of debugging checkpoints into the server.  could just as easily be an actual hardware error ...
<Burgundavia> daniels, ouch, that is what I suspected. I have heard of other people having the issue. Just in FF though
<daniels> oh, bong
<daniels> might just as well be firefox being randomly weird :)
<Burgundavia> rofl
* Burgundavia wishes epip were better
<Kamion> Riddell: those seed changes are fine with me. Want to make them yourself? You have a chinstrap account now.
* jnc wanders back to work
<Riddell> Kamion: how do I do that?
<Kamion> Riddell: first, make sure you have bazaar >= 1.3 installed
<Kamion> (not strictly required but it will save me from explaining how to set up signing rules)
<Kamion> Riddell: then follow the first code block in http://www.ubuntulinux.org/wiki/SeedManagement, except substitute "kubuntu" in place of "ubuntu" throughout
<Kamion> Riddell: cd breezy, make the changes in line with the existing format, then 'baz commit -s "some description of what you did"'
<Riddell> Kamion: ok I'll try that, thanks
<jnc> Mithrandir++
<Mithrandir> hi jnc
<smurfix> mdke: 
<jnc> i presume you've poked openoffice to print again for amd64 platform; thanks
<Nafallo> pitti: testing #10803? ;-)
<pitti> Nafallo: no, my provider kicked me out
<Nafallo> pitti: ahh. evil.
<pitti> or, rather, it's back now and I could kick the modem
<Nafallo> :-)
<Nafallo> pitti: you understand what's happening yet? :-)
<pitti> Nafallo: didn't deal with it yet, but I think I know the reason; however, it works perfectly for me...
<Nafallo> pitti: lucky you ;-)
<pitti> dpkg: error processing /var/cache/apt/archives/libxt6_6.8.2-21_i386.deb (--unpack):
<pitti>  trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in package xscreensaver
<pitti> bah
<daniels> pitti: yes, xscreensaver bug, it's being fixed
<pitti> cool
<Nafallo> pitti: uninstall xscreensaver, install libxt6, install xscreensaver did it for me :-)
<Kamion> mdz: could you update your casper arch mirror on rookery?
<pitti> Nafallo: I tried sudo dpkg -i --force-overwrite /var/cache/apt/archives/libxt6_6.8.2-21_i386.deb
<hunger> daniels: Could you please fix the sequence in of the slave links in twm's postinst? Thanks!
<daniels> hunger: hm, I thought I already fixed that
<hunger> daniels: Not in 21.
<daniels> ah, right
<daniels> /usr/X11R6/bin/twm -> /usr/bin/twm, yeah?
<hunger> daniels: Nope
<hunger> daniels: One of the last lines contains "slave" followed by the man-page alternatives.
<daniels> right
<hunger> daniels: Those are in the wrong order.
<daniels> hunger: hm, how so?
<daniels> i mean, I don't know the syntax off the to pof my head, but it mirrors the syntax above
<daniels> pathname displayname target
* pitti restarts X in the hope to get a fixed Control key
<hunger> daniels: -slave x-window-manager.1x.gz \
<hunger>   /usr/share/man/man1/x-window-manager.1.gz \
<hunger>   /usr/X11R6/man/man1/twm.1x.gz
<hunger> daniels: That works for me... what you got does not.
<daniels> maybe I fixed that for -22, and not -21
<daniels> oh, I see
<daniels> hrm.
<daniels> maybe the entire thing is wrong
* ogra tries sudo apt-get install blam....
<daniels> Kamion: how well do you know update-alternatives?
<ogra> whoops ECHAN
<hunger> daniels: Dunno. I do not bother about the man page for twm:-)
<daniels> heh
<Kamion> daniels: I guess a lot
<hunger> daniels: xbase-clients postinst warning: /etc/X11/xkb/xkbcomp symbolic link points
<hunger>    to wrong location /usr/bin/xkbcomp
<daniels> hunger: yeah, that's fixed in -22 also
<Kamion> daniels: possibly not well enough
<hunger> daniels: There is no 22 yet.
<daniels> Kamion: update-alternatives --install /usr/bin/x-window-manager x-window-manager /usr/bin/twm 40 --slave /usr/share/man/man1/x-window-manager.1.gz x-window-manager.1x.gz /usr/X11R6/man/man1/twm.1x.gz
<daniels> hunger: not in the archive, no
<daniels> Kamion: does that argument order look right to you?  (ignoring the .1.gz vs .1x.gz hilarity)
<hunger> daniels: So how do I fix this issue manually?
<daniels> hunger: isn't it just a warning?
<daniels> hunger: if not, edit /var/lib/dpkg/info/xbase-clients.postinst, change /usr/X11R6/bin/xkbcomp to /usr/bin/xkbcomp, sudo dpkg --configure -a
* Nafallo -> phone, brb
<hunger> daniels: Dunno. xbase-clients do not install.
<daniels> hunger: in that case, do that
<hunger> daniels: start-stop-daemon complains about xdm not being in /usr/bin/X11, but I can not find out where that happens. Maybe it still was using some files of the previous version.
<daniels> hunger: i didn't know people still used xdm and twm :P
<hunger> daniels: I don't.
<hunger> daniels: But something keeps dragging those debs into my system....
<daniels> nice
<daniels> well, the bug-fixing is appreciated; thanks
<hunger> daniels: Having the install stop for some deb you know you will never need is even more annoying than having it just stop;-)
<daniels> well, that should be the last of the /usr/bin/X11 bugs gone
* Nafallo -> back
<hunger> daniels: Optimist:-)
<daniels> hunger: it's the only way I can get through my days :P
* Nafallo remembers the 'what could possibly go wrong?' release ;-).
<daniels> i think that one was the first in about three that actually built from source
<daniels> or maybe not
<daniels> no, it didn't.  go me.
<Nafallo> on amd64 it did :-)
<Kamion> daniels: ordering looks fine ...
<Kamion> daniels: (although use --quiet, too)
<Amaranth> seb128: pyxdg 0.13 is out
<fabbione> kernel-team meeting will start in 9 minutes in #ubuntu-meeting
<toresbe> ooh, thanks for the tip
<toresbe> wouldn't miss it for the world
<Kamion> nobody ever said that about meetings at the last place I worked
<fabbione> Kamion: ehehe
<Nafallo> Kamion: *s*
<toresbe> Kamion: isn't Ubuntu nice ;)
<thom> the flashing panel stuff is most odd
<ogra> thom, its not flashing, its *glowing*
<Nafallo> hehe
<ogra> thom, see the changelog :)
<thom> pfft, mere sophistry!
<pitti> tseng, tseng|work: ping
<ogra> pitti, oh, you want both personalitys ?
<pitti> ogra: hehe :-), I don't know which one he gets highlighs for
<shaya> is everyone having a problem getting xbase-clients to configure?
<shaya> in -21
<Kamion> OK, let's say I've mounted stuff in subdirectories of /media
<Kamion> how do I make it show up on the desktop?
<Kamion> talking about partitions on the hard disk here
<daniels> shaya: yes
<shaya> ok, no need to file a bug then
<shaya> but evolution works again, so I'm happy :)
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | Ubuntu 5.04 is released! | MOM is awake! | Colony CD 1 released | gcc4 transition finished, breezy probably well broken, uploads of C++ packages in universe restricted || yes, xbase-clients is broken.  no, it's not fixed yet.
<tseng|work> daniels: get on that
<daniels> it's already fixed in my local tree
<daniels> i just need to unbreak libx11
<daniels> i'd seriously get lynched if -22 broke keysym handling again
<ogra> pitti, when do i need to be ready with poppler... ? already looked and did some stuff, the code is quite similar
<daniels> tseng|work: speaking of 'get on that', mono?  universe? :)
<pitti> ogra: no surprise, poppler is essentially the xpdf code without the gui
<tseng|work> daniels: dude, out of my hands
<ogra> yep
<tseng|work> ogra: what came up with that yesterday btw?
<Kamion> daniels: mono's already in main?
<pitti> ogra: Riddell already fixed kpdf to drop this pdf info feature for now, but it would be nice to add it again for breezy
<daniels> Kamion: er, it is?
<Amaranth> daniels: If you broke keysym handling again I'd take away all your beer. ;)
<Kamion>       mono | 1.1.7-0ubuntu4 |        breezy | powerpc
<Kamion>       mono | 1.1.7-0ubuntu5 |        breezy | source, amd64, i386
<daniels> Kamion: bone-arse
<ogra> <- phone
<tseng|work> oh yeah, ppc is bunk for now
<tseng|work> upstream is working on the bug
<thom> beagle/amd64?
<Lathiat> kkkkkkkkw[6~[6~[6~[6~ee
<Lathiat> blah, sorry.
<tseng|work> thom: xorg!
<tseng|work> non-PIC libs
<Kamion>     beagle | 0.0.10-0ubuntu1 | breezy/universe | source, i386
<Kamion> that's still universe though
<tseng|work> any time someone wants to ship me amd64 hardware
<tseng|work> be my guest.
<Kamion> it's on the list for promotion; I assume it just needs to be seeded or something
<Kamion> /usr/bin/ld: /usr/X11R6/lib/libXss.a(XScrnSaver.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
<Kamion> ^-- beagle/amd64 failure
<tseng|work> indeed.
<pitti> thom: its on https://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue
<Kamion> so why're you using the static libXss?
<tseng|work> probably because i had to do nasty things for it to find the headers at all
<Kamion> hm, it doesn't look like it's being used deliberately, odd
<tseng|work> CFLAGS="-I/usr/lib/X11R6" or something like that
<tseng|work> is the temp hack
<Kamion> includes wouldn't cause that
<tseng|work> then it needs fixing upstream.
<tseng|work> i dont think they test on amd64 at all
<tseng|work> ogra met them at guadec
<Kamion> requiring PIC shared libraries is not unique to amd64 at all
<daniels> hrm
<tseng|work> its unique to !x86
<tseng|work> or at least brutal failures by not doing so is
<daniels> i have no idea why libXss.a is being used
<Kamion> sure
<Kamion> libtool is saying -lXss rather than /usr/lib/libXss.so (or whatever)
<Kamion> in the link line
<daniels> Kamion: right ... surely that should still be picking libXss.so, rather than libXss.a?
<Kamion> don't think so
<Kamion> it should be possible to investigate on i386, because the same link line appears there
<Kamion>            The linker searches a standard list of directories for the library,
<Kamion>            which is actually a file named liblibrary.a.  The linker then uses
<Kamion>            this file as if it had been specified precisely by name.
<daniels> Kamion: hrm
<daniels> oh, right
<daniels> linker, as distinct from gcc?
<Kamion> daniels: gcc-as-linker, yes
<daniels> daniels@catsby:~/x/xlibs/cvs/Xau% gcc -o foo -L/usr/X11R6/lib -lXss foo.c
<daniels> daniels@catsby:~/x/xlibs/cvs/Xau% file foo
<daniels> ldfoo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
<daniels> daniels@catsby:~/x/xlibs/cvs/Xau% ldd foo
<daniels>         linux-gate.so.1 =>  (0xffffe000)
<daniels> [...] 
<daniels>         libXss.so.1 => /usr/X11R6/lib/libXss.so.1 (0xb7fd1000)
<daniels> where foo.c is just int main(...) { return 0; }
<Kamion> yes, but try stracing gcc and watch what it opens?
<mantiena> Kamion: you still wanna see mounted devices in /media on desktop ?
<Kamion> mantiena: not sure
<mantiena> ;)
<Kamion> I'd like them to be a bit more visible than Places -> Filesystem -> /media -> ah, there they are
<mantiena> AFAIK in /etc/fstab should be user or users option for these devices
<daniels> Kamion: never opens libXss.a, only ever touches libXss.so
<Kamion> mantiena: how would that affect the desktop?
<daniels> Kamion: (i don't disbelieve you, btw, just trying to figure it out)
<mantiena> Kamion: then mounted devices will be shown also on desktop and at computer:// location
<Kamion> mantiena: oh, they will? how strange
<Kamion> where's the code that does that? I'm curious
<mantiena> at least on my system (GNOME 2.8) works like this
<mantiena> I think gnome-vfs does this
<Amaranth> that's hotplug+hal love
<Amaranth> if you mean when you put in a CD or plug in a USB drive
<Kamion> Amaranth: not quite
<mantiena> Amaranth: no, I'm about partitions in /etc/fstab
<Kamion> similar effect, but not that
<Kamion> doesn't seem to work
<mantiena> Kamion: :( maybe you can give me that partition automouting integration in liveCD code for testing - I'm building new LiveCD tonight, so it would be nice to test and fix bugs of course ;)
<Kamion> I asked not to be hassled today
<Kamion> sorry, but I'm getting there
* lamont__ wonders if daniels is awake
<mdz> Kamion: updated
* mantiena doesn't know when today will end in Kamion's time zone ;)
<mantiena> mdz: Hi, I've learned gnu arch a little bit ;)
<Kamion> mdz: doesn't seem to be?
<Kamion> mantiena: the more people prod me, the earlier it will be. If you let me be, I might be able to give you code later. :)
<bob2> lamont__: 0240, so "probably" ;p
<daniels> lamont__: trying to go to bed ...
<daniels> what has hppa broken now?
<mantiena> Kamion: thanks
<lamont__> daniels: nah... iz stup1d support question
<daniels> lamont__: go on ...
<lamont__> any clue how to switch an HP nc6000 from the internal display to the video port on the port replicator???
<daniels> lamont__: install i855crt, sudo i855crt on 1024x768@70
<daniels> adding 'swcursor' somewhere in that command line may or may not help
<daniels> in any case, breezy's i810 driver should support the little hotkey out of the box
<mdz> Kamion: oh, hmm. is casper still in the old --2004 archive?
<Kamion> mdz: yeah
<mdz> I'll update that as well
<Kamion> thanks
<mdz> I should move it
<mdz> I regret having ever fallen for the --year trap
<elmo> --year is CRACK
<Kamion>   CHECKSUM FILE(S) DISAGREE WITH
<Kamion>   DIRECTORY LISTING ABOUT WHAT
<Kamion>   FILES SHOULD BE PRESENT IN
<Kamion>   REVISION DIR OF ARCHIVE
<Kamion> go baz
<Kamion>   revision: casper--main--0--patch-24
<lamont__> E: Couldn't find package i855crt
<pitti> morning mdz
<elmo> baz in "THE GODDAMN SKY IS FALLING" mode
<daniels> lamont__: try i855-crt
<\sh> lamont_: yes.. don't use the port replicator...it's evil...i shot my nc6000 with it
<Mithrandir> Kamion: this may just mean "I couldn't run gpg".
<Kamion> Mithrandir: that would surprise me
<Kamion> this is a manifest-of-files complaint, not a content-of-files complaint
<Mithrandir> Kamion: I've had it mean that.
<Mithrandir> Kamion: oh, ok
<Kamion> oh ... it's still mirroring
<Kamion> that would explain it
<lamont__> daniels: couldn't find video mode
<mdz> pitti: morning
<Kamion> PANIC: Unknown error with arch_tree_show_rejects
<Kamion> oh, for god's sake
<daniels> lamont__: try 1024x768@60
<mdz> Kamion: do I need to rm -rf the mirror and redo it?
<mdz> Kamion: at any rate, I've branched it into matt.zimmerman@canonical.com (no year)
<lamont__> sudo xresprobe ati
<lamont__> id: 
<lamont__> res: 1400x1050
<lamont__> freq: 
<lamont__> disptype: lcd/lvds
<mdz> and future commits will go there
<mdz> there's a base-0 there, so perhaps baz will get over it
<Kamion> mdz: no, it was getting horribly confused by a conflict in my tree, I've fixed it by sympathetic magic now
<mdz> happy mailman day, growl
<Kamion> mdz: matt.zimmerman@canonical.com has no .listing files
<mdz> can't we just enable DAV on rookery?
<mdz> I have no idea how to add that to an existing archive
<daniels> mdz	-l
<daniels> mdz: (when running make-archive)
<daniels> lamont__: oh, ati
<mdz> daniels: run make-archive on an existing archive?
<wasabi_> So if I chown a file in /dev... should it stay chowned after a reboot?
<mdz> wasabi_: nope
<Kamion> change-archive
<wasabi_> I had though udev orwhatever recorded mods and stuff.
<wasabi_> guess i was wrong
<lamont__> daniels: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 
<mdz> baz: unrecognized command (change-archive)
<Kamion> oh, that only does signatures anyway
<Kamion> mdz: your baz is old
<daniels> lamont__: try atitvout, maybe
<lamont__> mdz: baz switch
<mdz> Kamion: my baz is the "release"
<daniels> lamont__: failing that, if you hit whatever hotkey you use, it might DTRT
<lamont__> daniels: hints on package name?
<daniels> lamont__: should just be atitvout.  if not, google knows the answer.
<Kamion> ah, I'm running breezy's
<mdz> lifeless: what do you think about putting the baz crack-of-the-day into breezy until feature freeze?
<Riddell> Kamion: seeds changes made, you might want to check it incase I messed up somewhere
<bob2> mdz: ssh to rookery, touch "=meta-info/http-blows", then run "baz archive-fixup sftp://rookery/..."
<lamont__> daniels: haven't finished interperting hyroglyphics yet
<daniels> lamont__: in any case, I really need to hit the sack now.  worst case scenario, Option "Clone" in xorg.conf/Device if you don't care about battery life
<bob2> mdz: (yes, the ui sucks)
<mdz> bob2: usage: baz archive-fixup [options] 
<Kamion> Riddell: personally I'd put newlines around the separator comments, but that's just style. looks ifne
<Kamion> fine
<lamont__> atitvout  detect
<lamont__> CRT is attached.
<lamont__> root@rover3:~# atitvout c
<lamont__> VBE call failed.
* lamont__ grumbles
<daniels> lamont__: looks like Clone it is
<Riddell> Kamion: ok, thanks
<lamont__> daniels: dunno
<daniels> lam	hm
<daniels> lamont__: it should just work when you start xorg with the crt attached
<Kamion> mdz: archive-fixup in 1.2 probably doesn't understand URLs
<daniels> but yeah, totally bedtime.  need to be up in 2h3m.
* lamont__ tries that
<mdz> Kamion: it doesn't understand any non-option arguments
<Kamion> mdz: archive-fixup -A <archive>?
<mdz> trying
<lamont__> well.. that worked..  now I just have to figure out how to close the lid without disabling both displays... :-)
<KaiL> daniels: xbase-clients postinst warning: /etc/X11/xkb/xkbcomp symbolic link points to wrong location /usr/bin/xkbcomp
<KaiL> ..?
* ogra wonders if daniels will dream of this question tonight....
<Kamion> mdz: that seemed to work, thanks
<thom> KaiL: topic
<KaiL> oops ;)
<Kamion> $ baz branch matt.zimmerman@canonical.com-/casper--main--0 colin.watson@canonical.com--2005/casper--automount--0
<Kamion> Segmentation fault
<mantiena> mdz: I wanna make a local mirror of casper archive, but command from baz help doesn't work on my system:
<mantiena> baz register-archive matt.zimmerman@canonical.com--2004-SOURCE http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004/
<mantiena> produces "usage: baz register-archive [options]  [name]  location" instead of creating local archive for mirroring as described in help :(
<mdz> mantiena: #arch
<mantiena> mdz: ok
<mdz> that's where the baz experts hang out
<mdz> we just muddle around here
<bob2> mantiena: (#arch, but baz register-archive http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004/)
<mantiena> bob2: I know this, but this creates archive with same name, but in baz documentation I've read, that for working in offline mode I need different name, that ends with -SOURCE
<bob2> mantiena: not in modern baz
<Kamion> I have to go, back in a bit
<thom> pitti: fyi, firefox in hoary onwards is pango enabled
<pitti> thom: oh, wrt this bengali user?
<mantiena> bob2: modern is > 1.3.2 ?
<thom> pitti: yeah
* lamont__ wanders off for a bit
<ogra> thom, they showed a cairo based ff at guadec ;)
<bob2> mantiena: in 1.3 you don't need -SOURCE
<thom> ogra: yeah; will be cool when it's performant
<ogra> thom, rotating, zooming of websites... and without stairstepping in the bitmaps, even if you zoom in really far :)
<elmo> pfft
<ogra> it was incredible
<mantiena> bob2: hehe, then it seems baz 1.3.2 prints outdated info when I type -h or -H :(
<ogra> ok, i admit, rotating of google has no real usecase :)
<bob2> mantiena: gah, sorry about that
<bob2> the help text needs a good long tidy up
<trulux> pitti: add -hardened to your auto-join :)
<mantiena> hehe, Debian has more up-to-date baz than ubuntu :-P
<pitti> hm, ok :-)
* Nafallo wants networkmanager :-P
<herve> hi
<herve> is the xbase-client postinstall failure is already sorted out
<herve> or should I post my proposal in the bugzilla?
<Nafallo> herve: read topic ;-)
<herve> thanks for the tip!
<Nafallo> herve: I believe it's done in daniels local -22 :-)
<herve> that's what I wonder
<Nafallo> herve: you can always post the proposal just in case ;-)
<herve> well, in case you want to fix it, edit /var/lib/dpkg/info/xbase-clients.postinst
<Nafallo> herve: yepp. that's what daniels told me :-).
<herve> and line 197, change path of /usr/X11R6/bin/xkbcomp
<herve> Nafallo, it worked for you?
<Nafallo> herve: yepp. I'm finally up2date on breezy :-).
<jdub> GOOD MORNING FREEDOM LOVERS!
<zul> hey jdub 
<tseng|work> hi jdub.
<pitti> Hi jdub, back home?
<jdub> nup!
<mdz> Kamion: did I ask you about lvm10-udeb already?
<jdub> at LHR atm
<mvo> hey jdub 
<Nafallo> hi jdub 
* thom throws peanuts at jdub
<thom> jdub: how long you there for/
<jdub> not long
<jdub> unfort
<thom> ahr :(
<mdz> Kamion: (that is, can it go away?)
<\sh> hula is excellent....i have to say
<ogra> \sh, say thanks to herzi, he packaged it and will be happy to hear about
* ogra wonders why herzi still hasnt applied for member
<\sh> herzi: thanks
<mako> alright.. we so have a meeting about backports soon
<\sh> ogra: but who will answer my damn stupid questions, concerning migrating cyrus-imapd spools to hula ;)
<\sh> and why is the imap connector not working
<mako> the agenda actually looks good
<ogra> mako, yes :-/
<\sh> mako: scratchpad ;)
<Burgundavia> ogra, you saw the post on p.g.o about building community around the newly FLOSSed directory servers?
<ogra> \sh, novell ?
<jdub> Mithrandir: aruond?
<mako> wow.. this is way better than the CC :)
<\sh> ogra: i need deeper help then novell ;)
<elmo> mako: where/when?
<ogra> Burgundavia, planet gentoo ? planet gnome ? pretty groundhogs ?
<mako> elmo: in #u-meeting in like 40 minutes
<thom> ogra: gnome; chris blizzard
<tseng|work> \sh: spools suck, use maildir
<\sh> i think i have some doggy poo on my hands somehow today
<ogra> elmo, https://www.ubuntulinux.org/wiki/UbuntuBackports
<\sh> tseng|work: its somekind of maildir with berk-db indicies
<ogra> thom, ah, yes.... i took a glance while testing blam, but didnt read it yet
<\sh> tseng|work: and i have 5g of it :( and 30 users 
<jdub> would be rad to get the directory server into universe for breezy, but will be challenging
<tseng|work> my firefox is effed after upgrade
<tseng|work> brb
<ogra> jdub, something for a MOTU hopeful ;) as hula was ;)
<jdub> someone very audacious :)
<ogra> :)
<ogra> jdub, herzi didnt even apply for MOTU, he just packaged it for us :)
<Burgundavia> ogra, gnome
<ogra> Burgundavia, yep
<Mithrandir> jdub: pong
<kierzko> hello
<\sh> i stop working for today...can't think anymore
<wasabi_> I'm having a weird pbuilder problem I can't figure out.
<wasabi_>     -> copying [./devel] 
<wasabi_> cp: cannot stat `./devel': No such file or directory
<wasabi_> That's the Section.
<wasabi_> I have absolutly no idea why it's doing that.
<wasabi_> It's like it's processing the Files: stanza of the .changes file and somehow thinking that's a file.
<wasabi_> oh wait a freaking sec
<wasabi_> if you read that please type /clear heh.
<dholbach> hellas
<ogra>  ****************** backports meeting in 15 min please join #ubuntu-meeting if you havent already **********************
<Mithrandir> ogra: no need to cause netsplits.
<mkde> lol
<mkde> damn gonna miss that meeting
<ogra> *giggle*
<mkde> it'll be a hoot no doubt
<jdub> oh rad
<Mithrandir> jdub: pong
<jdub> i'm here at the right time for the backports meeting
<jdub> Mithrandir: hey hey!
<jdub> Mithrandir: know of any sane rss plugins for mailman?
<Mithrandir> jdub: good talk at guadec.
<dholbach> 10x10! :)
<jdub> thanks!
<Mithrandir> jdub: nope, but should be easy to write one.
<jdub> :)
<dholbach> ROCK ON! :)
<Nafallo> 100x100 :-)
<jdub> i think ubuntu will be a bit part of 10x10 :)
<jdub> er
<jdub> big
<jdub> not bit
<ogra> it will be *the* part
<Nafallo> jdub: no doubt. I saw lot's of laptops running it on the streams ;-)
<Mithrandir> jdub: you mean RSS as "what are the last ten posts" or something like that?  With from, subject and first paragraph?
<jdub> Mithrandir: yeah, pretty much (though maybe more than 10)
<Mithrandir> jdub: you would need to maintain a bit of state between posts, but that's doable.  Should take an hour or two to write, I'd guess.
<elmo> err, what the FCUK
<elmo> *adelie.ubuntu.c 193.79.237.14    2 u  86m 1024  370    0.224  -23.456   1.308
<elmo> how is a server you last talked to 86 minutes possibly worthy of a '*' ???
<elmo> esp. given, in reality, my clock is 30 mins skewed
<Clint> must be SNTP where precision is optional
<Mithrandir> *sigh*
* Mithrandir kicks libXau for being the most useless library in the world.
<Mithrandir> daniels: any chance of libXau growing anything resembling useful functions in the next six months or should I just route around the damage?
<Mithrandir> argh.
<Mithrandir> xauth actually implements something resembling a useful library for libXau.  It should just become a real library or be merged into libXau
<abelli> bonne soir everybody
<ogra> abelli, https://www.ubuntulinux.org/wiki/UbuntuBackports
<abelli> it's an ambush everybody to the ground ..
<abelli> make no prisoners ..
<abelli> well when in mataro i pronounced the word "backports" someone attempted to my life .. 3-4 weeks later .. there was a backport project @ sourceforge .. and now this .. i'm an Omen.
<abelli> ogra: hu?
<ogra> abelli, all are in #ubuntu-meeting atm
<abelli> ogra: ahh i see .. 
<abelli> that was the meaning ..
<abelli> thank you.
<justdave> heh, cool.  PC World put Ubuntu Linux up alongside of Mac OS X 10.4 as best office software of the year. :)
<zul> justdave: url?
<justdave> http://www.pcworld.com/reviews/article/0,aid,120763,pg,3,00.asp
<herve> hey, the year isn't even over! :-)
<mkde> i was late to the meeting. Is the question of "why" to backport part of the agenda? has it already been addressed?
<ajmitch> mkde: the only mention has been that some users are addicted to upgrading.. :)
<Burgundavia> mkde, still meeting now
<mkde> Burgundavia, yeah i'm in the chan. Just seemed like that was v early on the agenda so i thought maybe i missed it
<herve> mkde, the meeting should be logged
<Burgundavia> mkde, it is going to be a long meeting
<mkde> herve, it will be, but takes a while to come up
<mkde> ajmitch, seriously that was the only justification?
<ajmitch> mkde: users wants them, what other justification is needed?
<ajmitch> apparantly quite a few users like them
<mkde> ajmitch, users might now know whats good for them though i suppose
<mkde> now/not
<herve> mkde, I guess it's mainly because users don't realize the amount of work needed
<mkde> herve, also I feel that users overestimate the benefit gained
<mkde> its part of the "i must have the latest version, regardless of detriment to my system, and even if i don't get anything extra from it" phenomenon
<herzi> ogra: btw, is there a way to get those packages directly in for me?
<ogra> herzi, become a MOTU, we're waiting for you since quite a while ;)
<herzi> that ubuntu supporter/member/maintainer stuff is quite complex and one needs to search through several pages (both wiki and website) to find out how things work, can you shortly describe the process for me?
<mkde> become member in the Community Council, become maintainer in the Technical Board, is that right?
<tseng|work> yes.
<ajmitch> what about the pay $$ to MOTUs? :)
<mkde> thats unofficial
<ajmitch> ah, right
<Kamion> mdz: yes, please kill lvm10-udeb
<herzi> so, for now i add my name to the community council agenda to become a maintainer, correct?
<mdz> Kamion: excellent, thanks
<ajmitch> herzi: CC agenda for membership
<ajmitch> TB agenda for MOTU maintainership
<herzi> okay
<elmo> can we kill the multiple lvms in base yet?
<Kamion> elmo: we already did
<Kamion> elmo: lvm10 got removed altogether, and lvm2 demoted to standard
<mantiena> good evening ;)
<Kamion> mdz: want to have a look at colin.watson@canonical.com--2005/casper--automount--0 ?
<Kamion> mantiena: you too, archive available at http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005/
<Kamion> mdz: I'm not sure it's quite ready to be merged yet; it needs more testing, the issue of how to make them accessible from the desktop is still open, and it doesn't handle labels properly (the install CD side relies on partman for those)
<mdz> Kamion: what does the output from partconf/mountpoint look like?
<mdz> I had thought it would use os-prober to come up with the labels
<Kamion> it seemed to fit better in partconf to me
<Kamion> it's kind of in an awkward intersection of functionality
<Kamion> I might move mountpoint and leave partconf-find-partitions where it is; not sure yet
<Kamion> mdz: you give it device name, filesystem, and optional label; it prints out either nothing (don't automount this) or a mount point
<Kamion> os-prober isn't ideal for labels because it doesn't link to parted and so can't extract those names
<mdz> oh, so this is factored out of os-prober now?
<Kamion> we could decide we don't care
<Kamion> it doesn't involve os-prober at all, for the moment
<Kamion> os-prober has loads of infrastructure for poking around inside partitions that we simply don't need
<mdz> if we're going to have a thing whose job it is to find labels for things, surely os-prober should use it
<Kamion> hm, I suppose
<mantiena> Kamion: cool, I looked at this about a hour ago but didn't find anything new. It seems now there are code, which I need :)
<Kamion> but
<Kamion> I was trying to make the behaviour identical to that of pmount
<Kamion> and I thought that used the partition name as label, and it's awkward to extract that from shell
<wasabi_> Interesting. Somehow last night I uploaded a new antlr to main.
<Kamion> I suppose I could write a helper C script in partconf which extracts the label, and then move the rest of the stuff to os-prober?
<mantiena> Kamion: partconf 1.0.9 will be ok for casper-automount ?
<Kamion> mantiena: that's what we're discussing
<Kamion> mantiena: it will work, but it may not be the ideal strategy
<Kamion> mantiena: I included dependencies for a good reason; look at them ;)
<pitti> night everybody
<dholbach> bye pitti
<Kamion> dholbach: do I get a bug report about libgetargs-long-perl? :-)
<dholbach> Kamion: erm, bugreport?
<Kamion> dholbach: I'm puzzled as to how you ran into a problem; it already build-depends on liblog-agent-perl, and the minimum version in question was uploaded to Debian in 2003
<Kamion> dholbach: I saw a change to a package I maintain in Debian on breezy-changes, and was wondering if I got a Debian bug report about it
<Kamion> (since it didn't look Ubuntu-specific)
<dholbach> Kamion: the package tries to download and fails, it re-tries and re-tries until the buildd gets annoyed
<Kamion> dholbach: but the build-depends change has no effect?
<dholbach> Kamion: lamont asked in #ubuntu-motu to please fix it
<Kamion> Depends: perl (>= 5.6.1), liblog-agent-perl
<Kamion> oh, crap
<Kamion> Depends, not Build-Depends. :-)
<dholbach> Kamion: sorry, i didn't realize you were the maintainer
<Kamion> oh, I'm not bothered, just generally suggesting that's the sort of thing we should be feeding back
<mantiena> Btw, I got several complains about slow LiveCD startup after Lithuanian liveCD distribution was moved from Morphix to Ubuntu framework. I have some ideas how to speed up the liveCD boot up
<dholbach> Kamion: i normally do... excusez-moi :)
<Kamion> np :)
<Kamion> (actually I probably had a rather quick trigger finger, should give you a chance to upload, have coffee, file bug, which is about the best I normally do ...)
<dholbach> so you suggest filing bugs at bugs.d.o?
<mantiena> Kamion: could some jobs (for example detection of DHCP server) be done in backgound (parallely) during liveCD start up ?
<Kamion> when it's something generally applicable that we fix, it's good for us to feed it back, q.v. debian-devel at the moment ;)
<wasabi_> I need a buildd kick. "lucene" is hung up dep-wait. Dependency is "j2sdk1.4"
<Kamion> mantiena: dhcp is hard
#ubuntu-devel 2005-06-09
<elmo> wasabi: err, does it?
<wasabi_> elmo, does it?
<elmo> nm
<mantiena> Kamion: why hard ? Knoppix, Morphix and other live CD technologies doesn DHCP detection in background, this decreased bootup time in ~5 seconds
<Kamion> mantiena: would require some redesign of the first stage
<dholbach> i'll be off to bed now
<dholbach> good night
<Kamion> meh, that would explain why I didn't write a helper to extract partition names
<Kamion> it's annoyingly difficult
* lamont__ disappears for ~5 hours
<tseng> doko: ping
<tseng> doko: ironpython they said is missing 1 or 2 c# 2.0 functions in mono, upstream says they need someone to file bugs so they can get fixed
<lifeless> mdz: nervous ;)
<tseng> doko: do you talk to ironpython upstream?
<Nafallo> hi JaneW! :-)
<uggwar> i just built a set of mono-1.1.7 packages and mono-utils lacks dh_netdeps. am i doing something wrong?
<Mez> can anyone help me with using the wiki - /query please
<uggwar> i am new to debian packaging...
<tseng> uggwar: yes.
<tseng> uggwar: its not dh_clideps in cli-common
<uggwar> what is the difference between netdeps and clideps?
<uggwar> i have dh_clideps
<tseng> uggwar: clideps is new and existing
<tseng> http://wiki.ubuntu.com/CLIPolicy
<uggwar> ok, so i should change the source package to use cli-scripts
<tseng> yes.
<uggwar> thanks alot!
<tseng> np
<uggwar> i've got work to do!
<uggwar> :)
<jsgotangco> morning
<mantiena> night ;)
<jsgotangco> heh
<Amaranth> mako: ping?
<Unfrgiven> jsgotangco: hey hows it going
<tseng> hi.
<tseng> Unfrgiven: im thinking we should have a piece on merging with debian
<tseng> Unfrgiven: maybe in a later chapter
<jsgotangco> hmm
<jsgotangco> wow you done with the doc already?
<tseng> Unfrgiven is drafting while i hack on mono bits
<jsgotangco> tseng, PackagingSystemDocumentation is all about deb packages?
<tseng> its taking longer than expected
<tseng> the what now?
* jsgotangco is reviewing udu specs
<Unfrgiven> tseng: hey dude. yeah good idea but ill need help on that topic
<Amaranth> does said documentation teach cdbs?
<tseng> Unfrgiven: sure
<tseng> Amaranth: yes.
<Amaranth> w00tage
<tseng> well, introduces
<tseng> not teaches.
<Amaranth> if you make a published book, i'll buy it ;)
<tseng> youll have a foundation
<tseng> the scope is very limited
<Unfrgiven> Amaranth: "Intro" developer docs :)
<Amaranth> oh
<Unfrgiven> Amaranth: there are plans to have an advanced reference book however that is still a long way away
<Nafallo> Unfrgiven: * for Dummies ;-)
<tseng> my boss ordered ldap for dummies
<Unfrgiven> Nafallo: I'd rather not insult the would be developer :)
<tseng> just so he could say on conferences "turn to page 5 in ldap for dummies"
* Nafallo couldn't resist :-)
<tseng> pretty cool.
<Amaranth> Ubuntu Packaging for Dummies - The beginner's guide to working on Ubuntu
<Nafallo> s/working on Ubuntu/becoming a MOTU/ ;-)
<jsgotangco> just give me a ring when the doc is done and needs to be reviewed and transformed
<Amaranth> can't use too many buzzwords on the front cover
<Unfrgiven> jsgotangco: will do... phone number? :P
<mdz> elmo: I demoted bugreporter-udeb from main to universe without realizing it was the same version as in hoary
<mdz> elmo: as a result, netinstalls seem to be broken
<Kamion> mdz: see #canonical
<Kamion> 01:32 < Kamion> elmo: I've got a patch to make hilarie understand udebs, if that would be helpful?
<Kamion> 01:33 < Kamion> elmo: jackass:~cjwatson/hilarie.patch - works with -n at least, although the pool_component stuff is icky
<Kamion> should've been here, sorry
<mdz> Kamion: even if I'd seen that, I wouldn't have known it was related to this issue
<Kamion> mdz: at the moment, hilarie needs to be run after a session of promotions/demotions to fix up symlinks
<mdz> is elmo asleep?  if so, I suppose I should move it back
<mdz> unless you have a better workaround
<Kamion> he was awake ~20 minutes ago; my patch works but I don't want to just apply stuff to katie without asking
<Kamion> (!)
<Kamion> mdz: moving it back is fine for now
<mdz> Kamion: moving the binary back worked, but source doesn't
<Kamion> it causes a slight installer issue on breezy netboots, but that's about it
<mdz> E: /srv/ftp.no-name-yet.com/ftp/pool/main/b/bugreporter-udeb/bugreporter-udeb_1.02ubuntu3.dsc (main/bugreporter-udeb - breezy) already exists!
<Kamion> bugreporter-udeb | 1.02ubuntu3 |        breezy | all
<Kamion> it's already in main
<mdz> that's the binary
<Kamion> oh
<mdz> I suppose I can just leave the source in universe
<Kamion> heh, the symlink is in the way I think
* Nafallo goodnight
<Kamion> mdz: meh, pmount/hal's mount point naming policy is a lot more complex than I thought
<Kamion> mdz: how much would you object to not attempting to reproduce it, and (to start with), just naming everything after the device name?
<Kamion> so /media/sda1 etc. always
<Kamion> we can do some kind of defaulting later, but it's looking painful to try to duplicate this
<Kamion> and I have not a lot of interest in an XML parser and HAL implementation in the installer ;)
<tseng> could you get hal to lookup a mount name given a device?
<Kamion> tseng: hal is not available at this time
<tseng> oh :(
<tseng> that is painful.
<Kamion> yes, you could, that's what pmount-hal does
<Kamion> but that requires lots of proto-desktop infrastructure
<mdz> Kamion: I wouldn't mind delegating the naming policy to pmount
<mdz> we don't need to know in advance, really
<Kamion> we discussed that in the BOF; see the notes
<Kamion> http://udu.wiki.ubuntu.com/MountingHDDFilesystems
<Kamion> pitti was not keen on relaxing the "no pmount from filesystems on local hard disks" policy
<Kamion> also, the install CD does need to know in advance, because it needs to present the default mount points to the user when they're doing manual partitioning ...
<mdz> I don't see the note you're referring to
<Kamion> currently configured to ignore hard disk filesystems, due to security concerns; not keen on relaxing that restriction, and any relaxation has to be considered very carefully
<mdz> I understand pitti's issue with local hard disks, but if the device is in fstab, this should be a non-issue
<Kamion> doesn't the fstab format require a known mount point?
<mdz> we could add a 'pmount' mount option or such
<mdz> it would be abusing fstab just a bit
<mdz> no more than, say, swap already does
<Kamion> this seems to be getting out of the realm of the relatively simple approach for which I had hoped
<mdz> *shrug* simple is better
<Kamion> and suddenly requires patching the world
<mdz> I expect it would only require patching pmount
<Kamion> I imagine other things that read fstab might care
<mdz> but if you have something which works, but doesn't have ideal naming, that's fine with me
<mdz> naming is polish
<Kamion> I'm more concerned about getting naming right in the install CD than in the live CD, I think
<Kamion> since the latter is transient by nature
<Kamion> (I can see the appeal of the fstab approach, incidentally; it's rather elegant. I just don't want to block a high-priority goal on that sort of thing :-))
<Kamion> mdz: ok, I'll see if I can get something sensible to happen with the default desktop, and then send you a merge
<Kamion> mdz: also, I just checked and the live cloop builds seem to be really building against breezy now, so I've re-enabled cron.daily-live on little
<Kamion> ... and cron.dvd
<Kamion> now all we need is a working kubuntu-desktop and I can turn the rest of them back on
<Kamion> night all
<mdz> Kamion: night and thanks
<jsgotangco> night
<jsgotangco> "a cete of badgers"
<jsgotangco> :)
<geppy> I'm wanting to write some configuration programs for Ubuntu, like those described on the "GraphicalConfigTools" page of the wiki.  Is it required that they be written in Python, or would I be able to write them in C?
<crimsun_> writing them in Python will speed their adoption
<geppy> But since there's a considerable amount of time left before Breezy comes out, would it really make a difference?  Or would they have to be re-written in Python?
<wasabi> thank the stars. I think I'm about to upload Eclipse.
<hunger> daniels: xkb is still broken for me:-(
<hunger> daniels: Nope, sorry, it is fixed! Just had to reload my shortcuts.
<mako> Amaranth: hey there
<daniels> Mithrandir: what sort of functionality are you after?
<jsgotangco> mako, hey
<daniels> haha
<gun> hello everybody
<mdz> wasabi: !
<mako> jsgotangco: hey dude
<wasabi> Eclipse sans Help
<jsgotangco> mako, got my mail?
<mdz> wasabi: looking over the archive/seed syncage, the only problematic bit I see remaining is libant1.6-java -> junit -> kaffe
<wasabi> Thought I fixed that ages ago.
<mdz> Build-Depends-Indep: debhelper (>= 4.1), kaffe (>= 1.1.1), jikes (>= 1:1.18-6), fastjar (>= 3.3.2), gjdoc (>= 0.7.2-2)
<wasabi> guess not.
<mdz> once that's resolved, we should be able to get libant1.6-java into main
<wasabi> Yeah i'll knock that out now.
<wasabi> The Eclipse I will be uploading will have it's help application disabled.
<wasabi> Which is probably fine.
<AndyFitz> jsgotangco,  http://www.inspirationline.com/Brainteaser/gaggle.htm     a troop of monkeys ,  a pandemonium of parrots     a rhumba of rattlesnakes 
<AndyFitz> my favorite will always be a business of ferrets
<mdz> wasabi: will it be compiled or interpreted?
<wasabi> Compiled.
<mdz> fantabulous
<wasabi> Sorta. ;)
<wasabi> You know much about the gcj compilation stuff?
<mdz> I have the 10,000-foot view
<wasabi> gcj is an interpreter, which is slightly overridden when a .so exists for a particular class.
<wasabi> So all the .jars stil elxist, and are still loaded.
<wasabi> But the code is never interpreted.
<wasabi> It's like an extra layer.
<wasabi> Just makes it bigger. ;)
<mdz> why is the .jar still loaded if a .so exists?
<wasabi> .jar's contain more than code.
<wasabi> Also, it's a hashing algoritm.
<mdz> but all the code is still loaded into memory?
<wasabi> A database of .class hashes -> .so mappings is made.
<wasabi> The classloader returns the .class stream, gcj finds teh .so from the hash of it.
<wasabi> Because classloaders can, and are overridden by applications in Java.
<wasabi> Eclipse for instance implements it's own for it's plugin system.
<wasabi> Yup. ALl loaded.
<wasabi> fixed junit uploaded
<mako> jsgotangco: umm.. probably :)
<jsgotangco> AndyFitz, i like "A murder of crows"
<jsgotangco> hehe
<wasabi> eclipse building
* wasabi prays
<mdz> wasabi: what are the build-deps of the new eclipse?
<mdz> well, this is clever
<mdz> if I exec run-init /root /sbin/init, it gets hung up forever in some weird unionfs file locking function
<mdz> but if I exec run-init /root /sbin/sulogin, and subsequently exec /sbin/init, everything runs smoothly
<wasabi> Build-Depends: debhelper (>> 4.0.0), sharutils, zip, unzip, gij-4.0, gcj-4.0, libgcj6-dev, fastjar, libant1.6-java, junit (>= 3.8), libxalan2-java, libxerces2-java, liblucene-java (>= 1.4.2), liblucene-java-doc (>= 1.4.2), libtomcat4-java, libjsch-java, libjsch-java-doc, libgtk2.0-dev (>= 2.4), libgnome2-dev (>= 2.6), libgnomeui-dev (>= 2.6), libxtst-dev, mozilla-dev (>= 1.7.5)
<mdz> beautiful, that's loads better than where it is now
<wasabi> Hell yeah.
<mdz> why a build-dep on a -doc package?
<wasabi> WEird package.
<mdz> heh, I bet
<wasabi> The -doc portion includes some example code which is actually used from eclipse.
<wasabi> Or at least referenced.
<wasabi> It might be an error in the lucene package. I don't know enouhg about it to know more than that right now.
<wasabi> The eclipse source package is 49M.
<wasabi> This should be fun.
<wasabi> The binaries are going to be about 110MB per arch.
<wasabi> For now.
<wasabi> =)
<wasabi> HAPPY DAYS
<wasabi> think we can fit it on the cd eh?
<wasabi> It'll be neat to be personally responsible for a few hundred mb in the archives.
<mdz> I think I can say without a doubt that we will have it on the DVD ;-)
<wasabi> hehe.
<wasabi> that's good to hear.
<mdz> we could create a "java edition" CD
<mdz> bump off some optional equipment like, say, openoffice to make room for eclipse ;-)
<wasabi> What about an actual optional CD?
<wasabi> Of Extras?
<wasabi> Seen some software do that, like Office.
<mdz> we've talked about that
<wasabi> You get the main application CD< and then another CD of additions.
<mdz> it would require some infrastructure we don't have yet, to make it work nicely
<wasabi> but only the first would be required for a totally usable install.
<wasabi> (unlike redhat!!! HA)
* wasabi restarts eclipse build after commenting out another unbuildable piece
<mdz> wasabi: http://people.ubuntu.com/~lamont/buildLogs/j/junit/3.8.1.1-4ubuntu1/junit_3.8.1.1-4ubuntu1_20050602-0417-i386-failed.gz
<wasabi> darnit, worked in my pbuilder
<mdz> hmm, it needs gjdoc
<wasabi> hmmm
<mdz> infinity: around?
<wasabi> java-gcj-compat is supposed to depend on that.
<wasabi> um.
<mdz> it does build-depend on it, but it didn't find it
<wasabi> noticed, trying to comprehend.
<wasabi> *chug*
<mdz> this is what it would look like if junit were in main and gjdoc in universe
<mdz> but they're both in universe at the moment
<wasabi> but it's not.
<geppy> The "Ubuntu device database collection" application outputs directly to ESD for the audio test.  Is there any reason why it shouldn't be patched to use the gstreamer sink in the gconf settings?
<mdz> geppy: it uses the GNOME sound API
<geppy> mdz: Harumph.
<mdz> geppy: probably that library call should switch to using gstreamer
<mdz> I think there was some talk about that
<geppy> Ah, alright.
<mdz> wasabi: odd, it found gjdoc fine the last time around: http://people.ubuntu.com/~lamont/buildLogs/j/junit/3.8.1.1-4/junit_3.8.1.1-4_20050418-0221-i386-successful.bz2
<mdz> seems like a buildd issue
<mdz> which is why I'm hunting infinity
<wasabi> there is no gjdoc is there
<wasabi> i bet it didn't make it to breezy from hoary or something silly.
<wasabi> I think actually I might know why this is.
<mdz> it's definitely there in breezy
<wasabi> wasabi@kyoto:~/tmp/gjdoc$ apt-get source gjdoc
<wasabi> Reading package lists... Done
<wasabi> Building dependency tree... Done
<wasabi> E: Unable to find a source package for gjdoc
<wasabi> it's not there.
<mdz>      gjdoc | 0.7.3-1ubuntu1 | breezy/universe | source, all
<mdz> is too
<wasabi> well why the heck can't I apt get it
<mdz> mizar:[/tmp]  apt-get source gjdoc
<mdz> Reading package lists... Done
<mdz> Building dependency tree... Done
<mdz> Need to get 738kB of source archives.
<wasabi> apt-cache show doesn't even show it.
<mdz> do you not have a -src line for universe in sources.list?
<wasabi> I do. I've been using it all night.
<wasabi> It is clearly there, and clearly updated.
<wasabi> apt-get update and try what you just did again
<wasabi> heh
* mdz apt-get updates
<wasabi> It's not in SOurces.gz
<mdz> oh, I've got hoary (and warty, for that matter) sources
<wasabi> Last time it built was in hoary.
<mdz> it's there in the db and it's there in the files on disk
<mdz> Sources is being regenerated as we speak; let's see if it reappears
<mdz> I had been moving things around earlier today and may have had poor timing
<wasabi> THis happened today too.
<wasabi> I've been building stuff all day that depends on gjdoc
<wasabi> in a pbuilder root I updated like, 8 hours ago.
<mdz> /dev/sda3             537G  505G  5.2G  99% /
<mdz> that's not so good
<wasabi> imagine if I had uploaded eclipse. ;)
<wasabi> oh wait aht's a ton of gb
<wasabi> heh
<wasabi> It makes me feel good that my desktop PC can hold the Ubuntu archive in it's entirity, though.
<jsgotangco> everything?
<wasabi> I have 700GB of space.
<jsgotangco> jeezz
<ajmitch> jsgotangco: surprisingly, that's not too much these days
<wasabi> not a lot at all.
<wasabi> with 400GB hds.
<wasabi> I have, 8 HD's of various sizes, patched together with evms
<ajmitch> my desktop is just 280GB, with 2 drives using lvm
<ajmitch> which is enough for development
<wasabi> At some point I got over having a seperate "server".
<jsgotangco> im just surprised
<wasabi> And just built a massive desktop
<jsgotangco> ive seen these tiny nas-wannabees from taiwan that hold at least 1TB on regular laptop drives
<ajmitch> nice
<bob2> bear in mind the canonical machines are scsi raid, not cheap ide, tho ;)
<jsgotangco> heh
<jsgotangco> of course
<wasabi> I sure wish I could find some sort of ATA/SATA rack mounted enclosure that I liked... something where you could just slide a drive in, and the OS saw it, etc. Somehow that supported both IDE and SATA. ANd was cheap.
<wasabi> I'd just set up a few at work and buy a ton of IDE drives and use EVMS
<wasabi> SCSI is expensive.
<Micksa> quick question
<Micksa> I have to compile my own kernel
<Micksa> how do I get it to make a kernel for just the one subarch?
<crimsun_> remove the others you don't want compiled from config/
<Micksa> ta
<wasabi> mdz, ever figure it out?
<mdz> wasabi: no, have to deal with some other stuff right now
<wasabi> k
<mdz> wasabi: try a no-change upload of gjdoc and see if that clears it up
<wasabi> k
<mdz> in fact there's a new version in Debian which needs merging anyway
<mdz> so might as well upload that, even better
<mdz> http://people.ubuntu.com/~scott/ongoing-merge/gjdoc/
<wasabi> Don't want to deal with it right now. They never implemented some important changes.
<wasabi> (such as the complete reorginization of the package i submitted patches for previously)
<wasabi> By no-change, you mean a version increment?
<Micksa> the kernel source from the archive should compile right? :)
<wasabi> eclipse isn't going up today heh.
<wasabi> stupid help system won't cooperate
<wasabi> frick that doesn't make any sense.
<wasabi> I added hoary's -src... updated, apt-get gjdoc, and it pulls it from breezy/universe
<Micksa> is there any reason to use a 686 kernel instead of a 386 kernel, apart from performance?
<crimsun> Micksa: highmem support, etc.
<crimsun> granted, that's arguably performance-related
<fabbione> morning
<crimsun> morn'
<lamont> mdz: still fighting junit?
<wasabi> I believe it just needs to be rebuilt.
<wasabi> I could upload a new one.
<lamont> given back on i386
<lamont> I could kick the others as well, I believe
<lamont> figured I'd wait and see how i386 did though...
<mdz> lamont: given back, meaning that ubuntu2 failed as well?
<mdz> lamont: thanks for looking at it
<lamont> mdz: uh... dunno which one I tried to give back - only had a log file for i386, but then mail is kinda throttled most of the time...
* wasabi still hacking out eclipse code
* lamont really actually looks at status
<mdz> lamont: it's still not showing up in Sources
<wasabi> gjdoc appeared in sources.
<mdz> something is broken on the archive end of things
<mdz> oh, sorry, i was looking at main
<wasabi> It was odd. I added a hoary -src line, updated, apt-get source, and it grabs from breezy. =/
<lamont> Exception in thread "main" java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.batch.Main not found in gnu.gcj.runtime.SystemClassLoader{urls=[file:/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar,file:./] , parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[] , parent=null}}
<lamont> that's ubuntu1, which is current
<mdz> wasabi: it grabs the most recent version by default
<lamont> did you just upload ubuntu2?
<mdz> ubuntu2 was uploaded a while ago
<wasabi> yeah, it was just odd that it appeared in teh space of 2 seconds. Confused me. ;)
<mdz> the source is in the archive
<lamont>  wanna-build -bi386/build-db -dbreezy --info junit
<lamont> junit:
<lamont>   Package             : junit
<lamont>   Version             : 3.8.1.1-4ubuntu1
<lamont>   Builder             : buildd+vernadsky
<lamont> uh......
<wasabi> funny. I don't have a ubuntu2 laying around here.
<wasabi> I would have if I had uploaded it.
<mdz> lamont: there are several gigs left, but this still makes me uncomfortable: /dev/sda3             537G  505G  4.8G 100% /
<lamont> which machine is that?  jackass?
<mdz>      gjdoc | 0.7.3-1ubuntu1 | hoary/universe | source, all
<mdz>      gjdoc | 0.7.3-1ubuntu2 | breezy/universe | source
<mdz> lamont: yes
<wasabi> that's gjdoc.
<wasabi> i think we're talking about junit.
<lamont> mdz: most recent junit is 4ubuntu1....
<mdz> oh, junit
<mdz> never mind
<wasabi> i think i just screwed up junit is all.
<mdz> but why hasn't gjdoc built?
* lamont gives back the failed gjdoc, too
<lamont> mdz: that has been elmo's pain of late, iirc
<wasabi> okay I have uploaded gjdoc 1ubuntu2
<wasabi> is that the one you're giving back?
* lamont gives back a bunch of universe packages with really short build logs.
<lamont> wasabi: yes
<wasabi> k.
<lamont> which really just means that you'll get to seen another log file...
<wasabi> this thing should email be build logs. ;)
<wasabi> s/be/me/
<lamont> heh
<wasabi> I always forget to go look.
<lamont> give it ~30 minutes, and you should see results
* lamont looks at the clock, considers mumbling something about sleep soon
* lamont sleeps
<fabbione> night lamont
<wasabi> oh my. Eclipse build got over the hump.
<mdz> how's junit looking?
<mdz> hmm, no build log yet
<mdz> infinity: can you check the status of junit?
<mdz> wasabi: what time zone are you in?
<wasabi> cst
<wasabi> cdt now maybe
<wasabi> it's 2 am here almost
<wasabi> I just did another upload of gjdoc, which should finalyl put it to rest.
<wasabi> junit should fall in line behind that.
<wasabi> If this eclipse build launches, even if it's full of erorrs, im uploading it.
<wasabi> Desperatly need to get this out there so other people can fix it for me!
<wasabi> (personal milestone)
<infinity> mdz : junit is currently building on all 4 arches.  Should be fine.
<mdz> wasabi: that's what break the worl^W^W^WOpenDevelopment is all about :-)
<infinity> Fine, except for the part where it's failed on i386...
<mdz> what's the nature of the failure
<wasabi> gjdoc needs to go before it.
<infinity> wasabi : It did.
<infinity> wasabi : This is a new failure.
<wasabi> ubuntu3? :)
<infinity> Setting up gjdoc (0.7.3-1ubuntu1)
<infinity> I'll kick it back.
<infinity> Thanks. :)
<wasabi> geeze. i've made 2 totally ass broken uploads of gjdoc in 2 hours.
* wasabi pats self on back.
<mdz> wasabi: that's what you get for staying up working on it until 2 ;-)
<wasabi> yeah
<wasabi> I wish a single eclipse build/test didn't take 30 minutes.
<infinity> When did you upload ubuntu3?
<infinity> The buildds are still building ubuntu2, apparently.
<mdz> wasabi: perhaps ccache needs to be extended for gcj
<wasabi> 2 should have broken pretty quickly.
<infinity> (when I say "building", I mean "failing, but claiming they're building")
<infinity> In other words, 3 isn't registered yet.  I'll wait longer. :)
<wasabi> mdz, it'd be nearly impossible to implement.
<wasabi> gcj, in the optimal use case, takes a .jar file and simply turns it into a .so file.
<wasabi> The .jar file is really just a ZIP of a bunch of .class files.
<wasabi> timestamps all over the place.
<mdz> are the .jar files being rebuilt as part of the build as well?
<wasabi> Yes.
<wasabi> RIght now I actually have the .so's disabled because they make the build take 45 minutes. ;)
<wasabi> It's not a very pretty picture really.
<wasabi> I'm going to have to work out some arch/arch-indep split.
<wasabi> For every -java package on the system.
<wasabi> And either the arch packages are going to have to be seperate source packages, or the entire build, arch and arch indep, will have to happen for every platform, for every java package.
<infinity> wasabi : junit will be retries as soon as your new gjdoc is built everywhere.
<wasabi> The Debian guys are a bit skittish about that.
* infinity considers going to add a few more hours to that 2 hours of sleep he had earlier.
<wasabi> infinity, cool thanks.
<wasabi> wasabi@kyoto:~/tmp/eclipse/eclipse-3.0.1/debian$ cat rules  | wc -l
<wasabi> 696
* wasabi weep
<pitti> Morning
<wasabi> =(
<mdz> pitti: morning
<pitti> Hi mdz
<wasabi> Okay so if I upload eclipse now, it'll hit multiverse.
<wasabi> eclipse in multiverse is perpetually hung at this point, so it probably needs to be poked, right?
<mdz> wasabi: perpetually hung?
<wasabi> Well, it can't possibly build.
<wasabi> Probably dep-waiting on things that wil lnever be.
<wasabi> So I guess I can just go ahead and do it, and get somebody to kick j2sdk1.3 when I'm done.
<wasabi> Oh. 'lucene' needs to be moved to universe (it's in multiverse)
<Treenaks> hi Jane :)
<wasabi> mdz, if you're still around, I found the hang up about all of this.
<wasabi> gjdoc depends on antlr which depends ong jdoc.
<wasabi> gjdoc
<wasabi> which isn't a big deal, except antlr is C++ as mentioned earlier and in main while gjdoc is in universe. ;)
<mdz> wasabi: is that what's tying up these builds?
<wasabi> yeah.
<wasabi> gjdoc makes documentation, so everything depends on it.
<mdz> we need to build a new antlr?
<wasabi> and gjdoc parses javadoc, and antlr is a abstract parser.
<wasabi> The antlr upload should build fine, it's just held.
<wasabi> A binary gjdoc exists from earlier.
<mdz> I didn't realize there was an antlr upload pending
<mdz> but that binary is no good?
<wasabi> The binary is fine.
<mdz> but it's in universe
<wasabi> But it's old.
<wasabi> yup
<mdz> I don't see any recent antlr build attempts
<wasabi> two choices. Either antlr needs to be moved back to universe, or everything else needs to be moved to main.
<wasabi> There haven't been. It's just sititng there.
<wasabi> It's part C++
<mdz> I don't mind moving everything to main once junit is fixed ;-)
<wasabi> junit is fixed, waiting on gjdoc, which is waiting on antlr. heh.
<mdz> I can certainly move antlr back to universe temporarily
<mdz> but we won't be able to retry the builds without infinity or lamont
<wasabi> That would help, if you move it to main, I can't work on it.
<mdz> who won't be around for hours anyway
<wasabi> I have no idea how I managed to upload antlr to main, actually.
<wasabi> I'm not supposed to be allowed to do that.
<wasabi> Could somebody have been monkeying with it earlier to try to get it thru?
<mdke> smurfix, ping
<smurfix> mdke: 
<mdke> ooh
<mdke> cool character
<smurfix> heh
<wasabi> Eclipse built.
<wasabi> Unf.
<Treenaks> what's with all the java uploads suddenly?
<wasabi> <---
<bob2> free java can run stuff now?
<wasabi> Yes.
<wasabi> Eclipse will be uploaded momentarily!
<bob2> does eclipse usefully work yet?
<wasabi> Yeah, it's pretty much complete.
<mdz> wasabi: I moved antlr into main today (yesterday)
<mdz> because its deps were sorted already
<wasabi> Ahh.
<wasabi> Hmmm.
* Treenaks still doesn't understand IDEs, but that could be me
<wasabi> antlr's depends aren't in mian.
<wasabi> main
<wasabi> oh, they are.
<wasabi> you moved java-gcj-compat too
<mdz> I've moved antlr (the binary only) back to universe temporarily so that you can try to break this cycle
<mdz> then it should move back, along with libant1.6-java, junit, libjaxp1.2-java and xerces-j
<wasabi> yes.
<wasabi> So, I am allowed to upload to main now?
<wasabi> Or just those packages?
<wasabi> I'm a bit confused about that.
<mdz> we don't have the capability to restrict at the package level, only at the component level
<wasabi> Because I've been uploading versions of this stuff all day, and it hasn't been complaining.
<mdz> you must have done it before I moved them
<mdz> in fact at least in some of those cases, I was waiting for your uploads to be built so that I could move them
<mdz> I think it would be a good idea if you started the process to be able to upload to main
<wasabi> Who do I talk to 
<wasabi> yeah
<mdz> wasabi: MOTU can provide guidance for that
<bob2> Treenaks: I tried running eclips the other week
<bob2> Treenaks: it was a 80MB download (+ JDK)
<wasabi> Eclipse installs
<bob2> and the default config shows you about 4 lines of code
<mdz> wasabi: nice!
<Micksa> unf unf unf
<mdz> wasabi: so on the other front, we need to 1) build antlr, 2) build gjdoc, 3) build junit, 4) move the lot to main
<wasabi> eclipse does not launch.
<Micksa> bob2: clearly all these people talking about it are crazy
<mdz> wasabi: ?
<wasabi> =(
<bob2> ouch
<wasabi> It's most likely because of my hacked help system
<wasabi> I'm going to upload it broken anyways and go to bed, because the .orig.tar.gz is 54mb
<Micksa> heh
<pitti> jordi: ping
<Micksa> welcome to packaging hell
<bob2> er
<bob2> uploading packages which are known not to work is a bit harsh
<mdz> wasabi: antlr doesn't depend or build-depend on gjdoc
<wasabi> it's going to multiverse, it's never built in ubuntu successfully before.
<wasabi> (previous version was non-free)
<jordi> pitti: pong
<wasabi> ANd I really need it someplace with bandwidth. ;) I can't keep sending people a 54mb file to take a look.
<pitti> jordi: about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309751 (mailutils vulns)
<pitti> jordi: oh, I /msg
<jordi> k
<wasabi> mdz, im sleepy, forgive me. =/
<wasabi> im bailing. can't do anymore.
<wasabi> night
<mdz> wasabi: so gjdoc just needs for antlr >= 2.7.5-6ubuntu3 to build?
<wasabi> yes.
<tepsipakki> how come does the hoary-installer (netboot) fail when it tries to retrieve lvm10?
<tepsipakki> this is a fairly new issue, I've installed successfully last week
<mdke> bug?
<tepsipakki> but where
<bob2> can you see it in the pool?
<tepsipakki> yes
<tepsipakki> maybe the installer has been updated? will check..
<tepsipakki> no, it's still the same
<tepsipakki> i'll try to raise the debug-level and see if it reveals something..
<tepsipakki> oh, yesterday it failed a lot earlier, it couldn't retrieve any udeb's
<bob2> that sounds way more like a local network issue
<bob2> read the log on console 4
<bob2> or 3, I forget
<tepsipakki> nothing there
<tepsipakki> of interest
<mdz> night all
<pitti> night mdz
<fabbione> night mdz
<fabbione> hey pitti
<pitti> Moin moin fabbione 
<elmo> Kamion: thanks, applied and run
<elmo> (tho bonus points for a ChangeLog entry, </drepper> ;)
<adn> hello here!
<tepsipakki> bob2: it wasn't a network problem, because it could wget preseed-files from the same server
<tepsipakki> it seems that the installer doesn't read BOOT_DEBUG at all
<Mithrandir> daniels: are you aware that /usr/bin/mkfontdir is broken?  It tries to run /usr/X11R6/bin/mkfontscale.
<doko> elmo: please sync java-gcj-compat and ecj-bootstrap from incoming (tomorrow experimental)
<Mithrandir> doko: is it you or somebody else who has uploaded an uninstallable ia32-libs?
<doko> Mithrandir: I uploaded zlib, building lib32z1 and lib32z1-dev as well
<Mithrandir> doko: why?  Is this change coordinated with Debian?
<doko> Mithrandir: lib32gcj6 needs it, the alternative was to add zlib1g-dev to ia32-libs
<Mithrandir> doko: why do we want lib32gcj6?
<doko> to remove the ooo-amd64 crap?
<Mithrandir> uhm, are you going to have 32 bit libraries of everything ooo build-deps on?
<doko> no, only for the libs, which are not in the ooo2 source
<Mithrandir> doesn't it build-dep on stuff like gnome and kde?
<doko> only for the gui integration
<Mithrandir> you're only giving me small, small pieces of the puzzle here.  Can you give me all of it rather than forcing me to drag it out of you piecewise?
<Mithrandir> what's the grand plan?
<doko> to build ooo using gcc -m32, as long as it's not supported for 64bit
<Mithrandir> that's a goal, not a plan. :-)
<doko> well, it's doable, if you have the libgcj support
<Mithrandir> again, what's the grand plan?
<doko> ?
<doko> don't know what you mean. anyway, I'm away for some hours
<Mithrandir> how are you going to just compile ooo without making 32 bit libraries of *gnome* and *kde*?
<tseng> doko:  we should talk about ironpython again sometime
<Mithrandir> doko: and this is totally uncoordinated with debian and with me, which is a bad thing.
<jdub> IRON PYTHON!
<jdub> GOOD MORNING FREEDOM LOVERS!
<tseng> doko: we need to get someone to be filing mono bugs to implement the missing 2.0 stuff
<Mithrandir> jdub: good morning
<tseng> hi jdub
<doko> tseng: yes, are you online tonight?
<tseng> doko: tonight as in 6-9EST, yes
<ajmitch> hello
<tseng> hi ajmitch 
<tseng> jdub: 10x10/05!
<doko> Mithrandir: what kind of coordination do you need? zlib does 64bit libs, so why not build the 32bit libs as well?
<tseng> jdub: to correspond with the breezy badger release.
<Mithrandir> doko: like, making sure there's appropriate conflicts in there?  Making sure that the change will go into debian too?
<tseng> jdub: WORLD TOUR
<jdub> heh
<ajmitch> and of that 10, how many would be ubuntu installs?
<jdub> ajmitch: we'll probably be the driving force :)
<ajmitch> I hope so :)
<tseng> ubuntu is the closest to stock gnome you can get with the least pain
<tseng> gentoo is closer but involves copious pain.. everyone else = patch-o-matic
<ajmitch> stock gnome, fresh releases, what more could you want?
<tseng> i have no idea how to get that s*ithouse hat out of my gnome menu
<tseng> on that certain other "community" distro
<jdub> tseng: we're going to have the ubuntu logo there for breezy ;)
<jdub> but it will be easier to change (just change icon themes)
<tseng> yep
<jdub> speaking of fedora
<tseng> andy showed me
<jdub> heelo drbyte 
<tseng> ColinCharleQueue!!
<ajmitch> evening drbyte 
<vuntz> tseng: doesn't changing the theme replace the hat with a foot?
<tseng> vuntz: changing the icon theme? I dont think so
<tseng> maybe.
<drbyte> hi jdub. i owe you something, this weekend i hope. been a bit busy
<drbyte> tseng: is there stuff there?
<drbyte> hi aj 
<drbyte> mitch
<vuntz> tseng: I have a foot here (Fedora at work ;-))
* ajmitch is just grabbing the jdub guadec talk now..
<tseng> drbyte: no no, it was my terrible sense of humor
<jdub> drbyte: sweet :)
<jsgotangco> jdub, UbuntuAtConferences?
<Lathiat> hmm, something break nsswitch in breezy?
<jdub> jsgotangco: hrm?
<drbyte> tseng: heh, right
<jsgotangco> jdub, CD Artwork *wink*
<tseng> speaking of conferences
<ajmitch> so is someone brave enough to try & package the fedora directory server?
<jdub> jsgotangco: hmm!
<tseng> ogra: did you find jelkner?
<vuntz> tseng: hrm... maybe you need to log out to see the new icon (panel bug)
<tseng> vuntz: ah.
<jsgotangco> jdub, brochures, flyers, etc for ubuntu@conferences desperately need artwork from the cd
<tseng> im sure we'll fix that for breezy, i have a foot fetish
<jsgotangco> (the cover at least)
<ogra> tseng, ?
<ogra> tseng, we are mailing regulary
<tseng> ogra: i asked if you saw jelkner to ask him to email me
<vuntz> tseng: I'm pretty sure it's fixed in 2.10
<vuntz> hi ogra :-)
<ogra> hey vuntz 
<maswan> drbyte: hey, I heard rumours that you guys are going to do a release this weekend too. want to compete with debian for network traffic? ;)
<opi> naa, everyone are running SID ;)
<maswan> opi: well, more likely Ubuntu by now, but.. :)
<Mithrandir> hi maswan
<opi> maswan: Sssh, that's a secret!
<jdub> mmm, hibernate means being able to switch batteries :)
<opi> jdub: or carry your laptop with broken batteries from one room to another (yes!) ;-)
<Lathiat> heh
<drbyte> maswan: june 6th; not a rumor, more of has always been the plan for FC-4 release
<maswan> drbyte: Heh. Well, we'll see then. :)
<Treenaks> Bring down the 'net!
<Lathiat> daniels: ping
<maswan> Yeah. I hope to see enough usage to flatline the university OC48. :)
<tseng> just dont saturate the mirrors.kernel.org pipe
<tseng> i need to grab fedora-updates off their nightly for work systems
<drbyte> maswan: is sarge /really/ releasing this time though?
<maswan> tseng: I don't know if they mirror debian-cd
<jsgotangco> brb
<tseng> they mirror fedora cds
<maswan> tseng: well, not my fault then. :)
<maswan> drbyte: I'd be really surprised if it didn't happen.
<RePo-MaN> can some one tell wot this server got to offer
<jdub> firefox is crashy-poo in breezy
<Lathiat> anyone know the cant open font fixed solution?
<pitti> Lathiat: I had this once, I adapted the font paths in xorg.conf to "/usr/share/X11/fonts/..."
<jordi> jdub: go epiphany :)
<Lathiat> thanks pitti 
* Nafallo says morning all!
<pitti> Hi Nafallo 
<pitti> Nafallo: just uploaded dhcp3 which should finally fix everything. Sorry about that one
<Nafallo> pitti: yea. I saw. about the download it when my cron.daily is finished :-)
<Mez> thom, you therE?
<Nafallo> pitti: it's not in the archive yet, is it?
<pitti> Nafallo: I just uploaded it and got the ACCEPTED mail, but it certainly needs another 20 minutes or so
<Nafallo> pitti: yea. thought so :-).
<ogra> pitti, any actions from my side for python2.4-gnome2-extras ?
<pitti> ogra: if you want to speed up the process, you could prepare an initial report :-)
<ogra> pitti, is there an exaple anywhere ?
<pitti> ogra: but if not, I'll do it at some time
<pitti> ogra: yes, there are examples linked from https://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue
<pitti> ogra: and there is also a pointer to the spec
<pitti> https://www.ubuntulinux.org/wiki/UbuntuMainInclusionRequirements
<pitti> as I wrote yesterday on -devel
<ogra> yep... sorry...
<ogra> i'll do the initial report :)
<pitti> cool, thanks
<ogra> but today is screensaver day around here :)
* ogra puts the "do not disturb" sign at the door
<Nafallo> ogra: ehm... you're looking at screensavers all day? :-P
<pitti> Nafallo: yeah, that's what we are paid for
<pitti> Nafallo: watch out for small bugs in the rendering and such
<ogra> Nafallo, i have to transition 4.21, its in the queue since a while... and 4.16 is broken, so first i'll see to have a 4.21 that actually builds to release X ... then i'll backport our changes
<Nafallo> pitti: hehe. looking for security vulnerabilities ;-)
<Nafallo> ogra: ahh, oki.
<pitti> Nafallo: yeah, if there is a security hole (a transparent spot that discloses parts of the user's desktop)
* Nafallo starts watching MatrixView on hoary ;-)
<JohnDong> hey everyone :)
<ajmitch> hello JohnDong 
<JohnDong> just wondering if anyone can tell me about FreeNX & Universe ... :)
<Mithrandir> JohnDong: what are you wondering about?
<JohnDong> if there's any immediate plan to get it into Breezy Universe
<Mithrandir> there is, look at the FasterNetworkedX spec.
<JohnDong> where is this?
<JohnDong> found it, nvm
<Mithrandir> http://udu.wiki.ubuntu.com/FasterNetworkedX ; first hit for fasternetworkedx on google. :-P
<JohnDong> yeah, I googled :)
<JohnDong> so what's a rough timeline for this?
<JohnDong> I mean, Kalyxo already has FreeNX debianized
<JohnDong> and Kanotix/Knoppix have been using it well for months now :)
<Mithrandir> except kalyxo's domain has expired. :-P
<JohnDong> alternate access URL's
<JohnDong> http://kalyxo-archive.mornfall.net/
<Mithrandir> ah, ok.
<Mithrandir> I'll talk to mornfall, then.
<JohnDong> awesome
<Amaranth> JohnDong: Isn't that one of the major things in backports that you worked on?
<Mithrandir> I need to vet the debs to make sure they're not utterly crackful, but apart from that it should be fine to just import them
<JohnDong> Amaranth: I just imported Kalyxo's packages, and they work fine. But due to the new restrictions this official move places on Backports, I can't pull source archives out of my ass anymoer
<JohnDong> excuse the expression :)
<ajmitch> JohnDong: don't worry, universe has had a general plan to import random crack anyway
<Mithrandir> ajmitch: I'm not going to sign any .debs which I'm not ok with.
<Amaranth> mako: ping?
<JohnDong> oh yes, also, what do you think about the legality of user-side downloading debs, like msttcorefonts?
<JohnDong> would Acrobat Reader done that way be OK for multiverse?
<JohnDong> Gentoo's been doing it like that for years now
<Kamion> elmo: thanks, I'll remember next time :-)
<ajmitch> Mithrandir: it wasn't about importing random binaries, but things like the apt-get.org source import
<Mithrandir> JohnDong: any particular reason why you're mentioning stuff which is all mine? :-)  (I'm lead for FNX and maintains msttcorefonts)
<JohnDong> just coincidence :)
<Kamion> tepsipakki: your installation problem was an archive problem, which was resolved as of about half an hour after when you asked; try again
<JohnDong> so, any answer for me? ;)
<Mithrandir> JohnDong: hm, the nx packages needs a bit of work, at least.  Their "Architecture" line is wrong, at least.
<George^Deka> im not running breezy but has envice been packaged yet
<thom> George^Deka: evince has been available since the middle of hoary
<Kamion> evince? yes, it was in hoary let alone breezy
<JohnDong> Mithrandir: ok, I guess they may not be 'correct' debian-wise... What about loader packages for restricted stuff?
<Mithrandir> JohnDong: installer packages are ok-ish, I think.
<JohnDong> Mith: ok-ish? So multiverse could have like transcode and w32codecs installers a la msttcorefonts?
<Mithrandir> JohnDong: I think so, but you shold really ask on -devel, I think.
<maswan> hmm.. does breezy have apache2.1 (with LFS) yet?
<maswan> damn. missed #ubuntu. sorry guys.
<Mithrandir> maswan: no, not yet.
<Amaranth> maswan: no, 2.0.x
<Mithrandir> maswan: thom has some httpd2.1 packages, afaik
<Amaranth> what's lfs?
<Mithrandir> large file support
<Amaranth> ah
<Amaranth> > 2GB?
<Mithrandir> mhm
<maswan> Mithrandir: Ok. Oh, well. Might as well do a hoary and a quick recompile myself then.
<Amaranth> You weren't going to run a server on breezy if it did have it, were you?
<JohnDong> LOL
<maswan> Sure, why not?
<JohnDong> who wants an apache2.1 backport for Warty?
<maswan> I mean, I'd test it first, for 10 minutes or so. Then I'd run a server.
<JohnDong> (just kidding, of course)
<Amaranth> JohnDong: Die. :)
<JohnDong> lol
<Amaranth> maswan: Well, breezy isn't guaranteed to be stable or secure, so good luck.
<maswan> I'm setting up a couple of temporary servers for the debian release.
<maswan> they are going to last perhaps one week
<Lathiat> maswan: which release?
<Nafallo> maswan: kewl! debian servers running ubuntu. I like that :-).
<Nafallo> Lathiat: sarge? ;-)
<maswan> Nafallo: Well, ftp.se.debian.org runs AIX. :)
<Lathiat> Nafallo: :)
<Lathiat> have we got a definate date on that?
<Kamion> daniels: are libxkbui1 and libxp6 supposed to have disappeared from breezy desktop?
<Nafallo> maswan: I know. that's not a branch of debian, is it? ;-)
<Amaranth> Lathiat: A couple days from now?
<maswan> Lathiat: So far nothing has turned up to speak against the weekend/monday release.
<thom> maswan: http://people.debian.org/~thom/apache-httpd2.1/
<Lathiat> Amaranth, maswan:nice
<tepsipakki> Kamion: thanks for fixing the archive.. I hope these aren't frequent ;)
<Kamion> tepsipakki: wasn't me, but yeah
<trulux> someone here has access to lwn.net's article on Kernel: Time to remove LSM???
<trulux> I need to read on that before something bad happens
<trulux> :(
<Kamion> it doesn't suggest anything happening immediately; you can wait
<Kamion> elmo: can we start running hilarie from cron.daily? I keep getting bug reports when people forget to run it manually
<robtaylor> mm, anyone know if breezy's gonna get hotplug-ng (or even if hotplug-ng is any good? ;)
<Mithrandir> robtaylor: probably.
<robtaylor> Mithrandir: so it seems good?
<Mithrandir> robtaylor: haven't looked to closely yet, but from what I hear, yes.
<robtaylor> groovy ;)
<robtaylor> might give it a try myself sometime then :)
<Amaranth> what's with all the -ng stuff?
<Amaranth> is this free software's version of 
<Amaranth> err
<Amaranth> free software's version of 'xtreme'
<Nafallo> Amaranth: next generation
<Amaranth> i know that
<Amaranth> it's a buzzword
<mjg59> Is restricted stuff that's on the CD installed by default?
<Lathiat> whats up with hotplug-ng
<Kamion> mjg59: if it's in the desktop seed or greater, ye
<Kamion> s
<Kamion> Lathiat: could you be more vague? :-)
<Lathiat> Kamion: hotplug-ng ?
<Kamion> "what's up with"
<Lathiat> no, that was my reply :)
<Lathiat> i was being more vague :)
<Amaranth> Lathiat: http://kerneltrap.org/node/4706
<Amaranth> kernel trap always has good explainations
<Kamion> Lathiat: ah :-)
<Lathiat> mmm that page doesnt render very well in w3m or links
<Lathiat> Kamion: :)
<Lathiat> bbl
<mjg59> The wiki is being very slow
<Amaranth> can someone whip up a little shell script magic for me?
<Amaranth> i need to know how much space all the dot files are using in my home dir
<Mithrandir> du -c ~/.??*
<Lathiat> du -shc
<Amaranth> 4.4G? damn
<pitti> Amaranth: ffox cache?
<Mithrandir> you use ccache or something?
<Amaranth> isn't the default ff cache 50MB?
<pitti> oh, right
<Amaranth> any way to get a breakdown of the what is using what?
<adamh> When I run python2.4-dbg, I can't import MySQLdb. Is there any way around that?
<pitti> Amaranth: use du -hsc .??*
<Lathiat> Amaranth: du -shc ~/.??* | less
<Lathiat> Amaranth: as i said earlier... :)
<Lathiat> Amaranth: nautilus thumbnails hurt too
<Amaranth> beagle
<Amaranth> 82M, damn
<Lathiat> |grep M is also usefull
<Lathiat> 82M is nothing :)
<adamh> And is there any way to install debugging symbols for a regular Python2.4 build, as a workaround?
<Amaranth> grep M is showing beagle using the most
<Amaranth> i would have thought .gnome2 would be a beast
<thom> 65M    /home/thom/.evolution/
<thom> um, that's 365
<thom> i don't even use evo
<thom> grah
<Amaranth> heh
<Mithrandir> thom: *chuckle*
<thom> 6.3G in dotfiles; 4.9 of that from ccache
<Amaranth> du -shc ~/.??* is only coming up with 138M
<Amaranth> ccache?
<Amaranth> du -shc ~/.??* also isn't showing everything
<Lathiat> well if you have dot dirs that are 1 or 2 chracters it wont
<pitti> Amaranth: du -hsdc ~/.[^.] ?
<pitti> erm, du -hsc ~/.[^.] *
<pitti> that works forme
<Amaranth> still 138M
<Amaranth> maybe that's the real value
<opi> du -hsc ~/.[^.] * | tail -1
<opi> to avoid mess ;)
<Amaranth> 138M, ok
<opi> emil@rude:~ $ du -hsc ~/.[^.] * | tail -1
<opi> du: `/home/emil/.aptitude': Brak dostpu
<opi> 3,0G    razem
<Amaranth> much better, that i can burn to a cd
<opi> I htink the dotfiles size is caused by some programs: .amula .mozilla ;)
<Nafallo> hmm
<Nafallo> 263M dotfiles ;-)
* Nafallo < shower, bbl
<jk24> Hi, the installer is broken for scsi disks, i've just post a bug on bugzilla
* Nafallo > here
<Lathiat> jk24: you incaluded all the pertitnant information right?
<Lathiat> jk24: such as your lspci output, etc
<jk24> Lathiat, not, because it's just a typo bug
<jk24> Lathiat, #11426
<Lathiat> hrm, ok
<Kamion> be wary of making sweeping generalisations from single examples of breakage
<Kamion> the installer is not broken for all SCSI disks
<jk24> Kamion, did you read the bug ?
<Kamion> yes. I'll look at it
<Kamion> ah, breezy installer. I did test the last release on a system with SCSI disks though
<Kamion> haven't tested today's daily yet ...
* Kamion goes to burn that
<jk24> Kamion, then, the problem here, is not an "scsi" issue, it's that the installer use /dev/scsi/......./disc3 instead of /dev/scsi/....../part3 
<jk24> Kamion, it's a typo
<Kamion> I understood the bug report, yes. I'll have a look
<Kamion> that would not be so simple as a typo though ... we'll see
<Kamion> partition->disk mapping is complicated
<jk24> Kamion, are the sources of the "current" installer available ?
<Kamion> yes, in the archive
<Kamion> lots of components
<wasabi> doko, what happened with java-gcj-compat and antlr? I notice the build-dep on antlr was updated to depend on a version of java-gcj-compat I can't find anywhere.
<smurfix> Anybody know if/when sabdfl will be back today?
<Kamion> jk24: please attach /var/log/syslog and /var/log/partman from the installer to the bug
<Kamion> huh, confirmed
<Kamion> well, that will help, always easier when I can reproduce it :)
<wasabi> lamont, have another multiverse package held up on a dep-wait. 'eclipse' hung up waiting for 'j2sdk1.3'.
<Nafallo> pitti: thanx. just tested the new dhclient3. I should rework my mirrorscripts :-P.
<Nafallo> pitti: thanx. just tested the new dhclient3. works :-).
<pitti> cool
<Nafallo> I should rework my mirrorscript though :-P.
<pitti> you already said that :-)
<Nafallo> ahh
<Nafallo> I didn't know xchat handled interfaceswitching ;-)
<Nafallo> (hence the recon)
<Nafallo> /recon even
<Mithrandir> ah, ok.
<mako> Amaranth: hey
<Amaranth> mako: long time at the park :P
<mako> 04:18 < mako> Amaranth: hey there
<Amaranth> oh, yeah
<mako> that was 12 hours ago
<Amaranth> 30min after i fell asleep
<mako> you weren't around
<Amaranth> so...
<Amaranth> you think you have a solution to my key troubles? :)
<Treenaks> Amaranth: your key troubles?
<Amaranth> i have no way of getting it signed
<Treenaks> Amaranth: where are you?
<Amaranth> sioux city, ia
<Amaranth> i already checked biglumber
<Treenaks> Aren't there a lot of Debian people in IA?
<Amaranth> not within 100mi of me, as far as i can see
<Amaranth> doesn't matter though, if they're not in sioux city itself i can't get to them
<Treenaks> Amaranth: organise some kind of gnome/ubuntu party and invite lots of people from everywhere ;)
<Treenaks> GUADAC ;) or something
<Amaranth> yeah, like my parents are going to like that...
<Kamion> jk24: ok, it's a parted bug
<jk24> Kamion, parted ?
<Kamion> yes, parted
<jk24> Kamion, why ,
<jk24> ?
<Kamion> because :-)
<Kamion>         if (_have_devfs() && !strcmp (dev->path + path_len - 5, "/disc")) {
<Kamion> that && should be ||
<Nafallo> that's a typo ;-)
<jk24> Kamion, is it parted that mount the partition ?
<Mithrandir> !strcmp is such a terrible way to test for equality.
<Kamion> no, but we use parted to get paths for partition devices
<jk24> ok
<winkle> ls
<winkle> err
<Kamion> actually might as well just drop the first half of the condition altogether
<opi> winkle: we used to have wordkick for ls on one # once ;-D
<mako> Amaranth: is there a lug in your town?
<opi> hi mako
<Amaranth> they say keysigning is a load of crap
<mako> Amaranth: any sort of computer or free software community
<mako> Amaranth: there only needs to be *one* person
<mako> Amaranth: who has a signed key
<jk24> Kamion, is there an cvs or an svn of ubuntu parted ?
<Amaranth> asked on the mailing list, no one said they had one
<Amaranth> all i got were replies saying keysigning was worthless
<mako> sioux city is not *that* small.. i think it should be possible
<mako> Amaranth: well, it's clearly not worthless to us
<bob2> how does on pronounce "sioux", anyway?
<Amaranth> soo
<Kamion> jk24: no
<Kamion> sorry
<mako> bob2: like sue
<bob2> mako: oh
<bob2> mako: that's a little disappointing
<Amaranth> thought it'd be more like suck? :)
<bob2> I thought the X might have a more leading role
<mako> good sci-fi name
<jk24> Kamion, is there a src package of the partman+parted ?
<mako> Amaranth: got any trips planned to anywhere else in the near future?
<Amaranth> no
<Kamion> jk24: all separate source packages, look in the archive
<Kamion> http://archive.ubuntu.com/ubuntu/pool/main/p/
<Kamion> it'll be fairly clear
<bob2> offlineimap seems to lose the "replied-to" status on messages pretty frequently
<pitti> yeah, I noticed that, too
<Amaranth> so i'm screwed, right? :P
<mako> Amaranth: i'm looking for something.. you should google, and such to try to find something
<Lathiat> hmm, backports doesnt have sources
<bob2> Lathiat: yup
<Lathiat> thats fucked, any idea why ?
<bob2> Lathiat: they say modifying the version and changelog doesn't require them to distribute  sources
<bob2> uses too much disk
<opi> bob2: :D
<pitti> seb128: btw, do you edit patches in cdbs+tarball packages very often?
<Lathiat> bob2: well, what license is debian/ under? :)
<bob2> haha
<Mithrandir> Lathiat: that varies.
<mako> Amaranth: there may be other options but they are (a) substantially more work for everyone involved and (b) only possible after there's been a major demonstrated effort that a keysigning is impossible
<seb128> pitti: I hate tarball in tarball so no, I don't have any such package
<pitti> seb128: ah, ok. I wrote a script last week that works exactly like cdbs-edit-patch for tarball packages
<pitti> seb128: maybe I even add it to cdbs-edit-patch proper
<mako> Amaranth: i took a train from boston to providence to get my first signature :-/
<seb128> good for you ;)
<Amaranth> mako: as a jobless teenager living with his parents in this shit town, my options are a bit more limited :P
<seb128> good idea, but jbailey is the cdbs maintainer if you need an ack to make the change :)
<Mithrandir> Amaranth: write a talk an get sponsorship to a conference somewhere.
<Lathiat> Amaranth: dont have a local lug with anyone interesting ?
<Lathiat> i had a couple DDs in my lug
<mako> Amaranth: i was a jobless teenerage at the time :-)
<Lathiat> problem is i dont have a drivers license or passport
<Lathiat> so gettin gmy key signed is practically impossible
<Amaranth> Lathiat: no one in my lug seems to care about keysigning
<mako> Lathiat: you can get a state ID
<Lathiat> mako: in australia ?
<mako> Lathiat: i'm sure
<infinity> Lathiat : Australian states issue photo ID, yes.
<infinity> Lathiat : It's just like a driver's license, but with no rights to drive.
<Lathiat> infinity: really?
<Kamion> passport can't be hard to get?
<Lathiat> infinity: why didn't anyone ever tell me this
<infinity> Lathiat : My girlfriend's little brother has one.
<mako> Lathiat: right.. people need id sometimes and there's reason they need to learn to drive to get it :)
<Lathiat> Kamion: yeh but there like $110
<Kamion> !
<Lathiat> which is money i do not have
<Lathiat> and ive never been overseas to get one
<mako> Amaranth: have you been trying to for a long time already.. i appears that you are giving up rather quickly
<infinity> Lathiat : Which state are you in?
<Lathiat> infinity: western australia
<infinity> Lathiat : I know for a fact that VIC and QLD issue them, I'd assume they all do.
<Amaranth> mako: about 6 months now
<Amaranth> mako: i just don't have the means to get anywhere
<Lathiat> i'll ring someone up and ask
<Lathiat> infinity: any idea of cost
<Amaranth> well, maybe only 4 or 5 months
<spiv> In NSW, you can get a "Proof of Age" card instead of a licence, but only until you're 25.
<spiv> http://www.rta.nsw.gov.au/licensing/proofofage.html
<infinity> Lathiat : Ask the dept of transport.  I believe they hande them (since it's the same photo process as a drivers' license, ubt without the licensing part)
<Lathiat> proof of age afaik you need to be over 18
<Lathiat> also
<Lathiat> no one accepts them as ID
<Lathiat> which is fucked, bu tthey dont
<Lathiat> (unless you a night club or whatever)
<spiv> Yes, and over 18, good point.
<mako> Amaranth: so there are people in sioux falls and loads in omaha i suspect
<Lathiat> see, im 17
<Lathiat> i don tthink i raised thsi point
<infinity> Ahh.
<Lathiat> my entire problem is that im under 18
<Lathiat> with no drivers license
<Lathiat> and passport is $lots
<Amaranth> mako: yeah, a couple in omaha
<aj> Lathiat: so grow up, duh
<infinity> Lathiat : At what age can you get a learner's license in WA?
<infinity> Lathiat : You couldjust go write the written test and get one. :)
<Lathiat> infinity: 17 something, i can get it now im just slack
<aj> Lathiat: passport lasts 10 years though
<Lathiat> aj: :)
<mako> Amaranth: i mean, i can also look for debain developers.. and we can google for people who do gpg stuff.. sign their messages, wahtever
<jbailey> pitti: If the patches are sane, I will not likely have any problems with them. =)
<Lathiat> wtf did openoffice get a security update for
<mako> Amaranth: i found one in sioux falls already
<mako> Amaranth: which seems slightly closish
<Amaranth> mako: i'd have a better chance of getting to omaha, actually
<Riddell> elmo: what's the status of kdevelop?  it can't find kdevelop_3.2.1.orig.tar.gz
<mako> Amaranth: ok
<mako> Amaranth: sclinux.org is your lug?
<Amaranth> anyone know why the pyxdg developer would get a 'pyxdg_0.13-0ubuntu1_source.changes REJECTED' email?
<Amaranth> mako: yeah
<infinity> Amaranth : Because you uploaded it to Debian instead of Ubuntu?
<Amaranth> i didn't upload it anywhere
<Amaranth> the only one that could have would be seb
<infinity> (Or someone did)
<mako> someone probably did
<Amaranth> but why would it go to the pyxdg dev and not seb128?
<infinity> It goes to the maintainer and the Changed-By, to catch as many eyes as possible.
<Amaranth> he has nothing to do with debian though, he is a gentoo developer
<Amaranth> mako: you can see in the mailing list archives that i finally went to them after trying to figure out what to do
<Kamion> Amaranth: because somebody managed to upload pyxdg_0.13-0ubuntu1_source.changes to Debian, not to Ubuntu
<Kamion> and Debian doesn't have a whitelist of whom it mails
<Kamion> and somebody put him in the Maintainer: line
<Kamion> wouldn't necessarily have been him
<bob2> does the signed .changes go anywhere so people can see who signed it?
<Kamion> it's not world-readable on newraff
<Kamion> (crypto-in-main))
<bob2> ah
<wasabi_> So like...
<wasabi_> Eclipse is uploaded.
<wasabi_> Can we have a party?
<bob2> wasabi_: does it run?
<wasabi_> Depends what you mean by "run".
<jk24> wasabi, eclipse is packaged ?
<wasabi_> Also what you mean by "packaged".
<bob2> uploading a 54MB source package that doesn't actually build anything usable seems a tad premature.
<wasabi_> Oh it builds. And it launches.
<wasabi_> Oh you said "usable?
<wasabi_> heh.
<ogra> wasabi_, so i can apt-get install it on my amd64 system and just launch it ?
<wasabi_> no. ;0 There are a LOT of issues to work out still.
<wasabi_> compiling for non-i386 is one of them.
<Amaranth> why did you upload again? :)
<wasabi_> So you can grab the source and help me fix it. Heh.
<jk24> wasabi, pckaged as i can apt-get install it ?
<bob2> jk24: except it's not usable
<jk24> bob2, why ?
<wasabi_> I see. Now I'm expected to explain why. ;)
<bob2> jk24: I don't know
<bob2> jk24: ask wasabi, he/she is the one who decided to upload it
<jk24> wasabi, where can i found it (by curiosity)
<wasabi_> What is your intent? To use it or to work on it?
<jk24> wasabi, just to see
<wasabi_> It's in breezy multiverse.
<jk24> wasabi, ok
<ogra> jk24, there are nice screenshots on the web :-P
<bob2> multiverse? I thought you built it with free java?
<wasabi_> bob2, eclipse 2 was in multiverse imported from Debian.
<ogra> bob2, see the java spec on the udu wiki
<seb128> Amaranth: is he subscribed to the PTS for the package?
<wasabi_> It can be promoted, but there is no point until it works.
<bob2> ogra: ah
<ogra> bob2, there are some dependency issues that wont be solved before breezy
<Amaranth> seb128: I don't know, he isn't answering. I doubt it though.
<elmo> Riddell: err, what?
<Amaranth> seb128: Oh, he is. That explains it.
<seb128> yep
<Riddell> elmo: kdevelop got rejected because it could fine kdevelop_3.2.1.orig.tar.gz but that file should already be uploaded
<mjg59> ogra: Is it possible to export DMI information from the hwdb?
<elmo> Riddell: the file isn't in the archive or in incoming
<ogra> mjg59, hmm, yes, with some work.... i'll have to move it to the DC to a faster machine first, now that i have access
<ogra> elmo, which mailadress is set for me for uploads now ? ogra@ubuntu.com ? 
<elmo> ogra: *@ubuntu.com is whitelisted
<ogra> great
* tseng forges goatse@ubuntu.com
<mjg59> ogra: Ok, cool. I'll need a stack of DMI structures in order to sort out hotkey support.
<ogra> elmo, i guess you need my updated key with the new adresses attached ?
<elmo> ogra: not really
<ogra> oki, great :)
<Nafallo> ogra: there where plans to be able to update records that's already there? ;-)
<Nafallo> ogra: I had backup of the dotfile and have repartitioned stuff :-P
<Lathiat> mjg59: DMI?
<ogra> mjg59, i wont come around to do that this week, today is my screensaver day and i have to merge some hal patches before i can think about hwdb...
<ogra> Lathiat, BIOS data
<Lathiat> ogra: ah
<ogra> Lathiat, sudo dmidecode
<Lathiat> oh wow cool
<mjg59> ogra: Yup, that's no problem - I'm in no huge hurry
<ogra> Lathiat, its also in hal
<Lathiat> yeh i noticed of late
<ogra> Lathiat, in the BIOS device in hal-device-manager (in hoary)
<Lathiat> dont see anything about hotkeys but?
<ogra> Lathiat, laptop ?
<Lathiat> yeh
<Riddell> elmo: is kdevelop in morgue?
<ogra> which model ?
<Lathiat> dell inspiron 8600
<ogra> does it have hotkeys ? 
<seb128> JaneW: I spoke about GnomePanelEnhancements with gnome-panel's upstream. The spec is a draft, we had no BOF about it and most of the point are going to happen upstream or a bad ideas. Should I mark the spec as "Deferred" or maybe discuss it with a mail on the list?
<Lathiat> eh
<Lathiat> yeh
<Lathiat> i have volume down, up, mute, plauy, stop , previous, next
<Lathiat> or is that not 'hotkeys' ?
<elmo>   kdevelop | 4:2.1.5.1-7 | hoary/universe | source, amd64, i386, ia64, powerpc
<elmo> ^-- Riddell:
<elmo>   kdevelop | 4:2.1.5.1-7 | warty/universe | source, amd64, i386
<elmo> Riddell: and you have an account, you can run find/ on the morgue, it's on rookery
<Riddell> good point
<KaiL> do we still need kdevelop 2.x?
<JaneW> seb128: yes it sounds like a deferred to me, however I would prefer mdz, kamion or the list to support that decision as well...
<Riddell> KaiL: it's a rename of kdevelop3 -> kdevelop
<bob2> kdevelop has been epochoed 4 times?
<seb128> JaneW: k, I'll mail the list with my comments on the Spec, thanks
<Riddell> bob2: the whole of KDE has been epoched 4 times, all < 2000 I think
<bob2> Riddell: ah, wow
<Nafallo> mjg59: hmm, Max Speed: 2500MHz. does that mean my processor hates me and only thinks it can do max 1600MHz?
<mjg59> Nafallo: What sort of machine do you have?
<Nafallo> mjg59: amd64 laptop, targa.
<mjg59> Nafallo: Cheap hardware often has complete lies in the DMI information
<Nafallo> mjg59: hehe, dang ;-)
<JaneW> seb128: thanks, feel free to update the goals page with deferred for now, pre-emptively ;)
<Lathiat> Nafallo: haha
<Nafallo> mjg59: thanx anyway :-)
<mjg59> For CPUs, it can often be the maximum speed the motherboard will support
<seb128> JaneW: ok
<Nafallo> dooh :-P
<Nafallo> mjg59: hmm. I see what you mean by lying ;-). 512+256 != 1024 last time I checked :-P.
<Riddell> well I'm confused, kdevelop has disappeared
<seb128> JaneW: about MenuEditor, GNOME will ship a simple menu editor with its desktop for 2.12 and Amaranth has smeg ... any reason to keep that on the bounty/spec lists? The spec is really light...
<Amaranth> hey, i could take it as a bounty ;)
<seb128> s/has smeg/is working on smeg/
<seb128> ah ah
<ogra> a ticket to the nearest next keysigning party
<ogra> ;)
<Nafallo> hehe
<Riddell> elmo: kdevelop's .orig was definatly uploaded and compiled, any idea how to find out what's happened?
<JaneW> seb128: so will that be something tracked for Breezy at all or not?
<seb128> we already have the GNOME one in main, which is a simple one
<seb128> and Amaranth has planned to maintain his one to universe afaik
<ogra> and we want to avoid redundancys
<seb128> so imho that's a "Completed" spec
<Amaranth> yeah, that's the plan
<Amaranth> was hoping it would be my path to MOTU, but without a signed key that's worthless, so someone else can do it ;)
<seb128> why?
<seb128> you can find a sponsor
<Amaranth> that's what i mean
<Amaranth> i have debs that are good and all
<seb128> Amaranth: have you talked with motu guys? 
<seb128> I'm sure it can be reviewed by 3 people today and uploaded
<Amaranth> seb128: will do
<Amaranth> well
<Riddell> Amaranth: poke me if you want
<Amaranth> i need pyxdg 0.13 in main first
<seb128> I've uploaded it this morning
<seb128> dunno why it's not built
<Amaranth> it went to debian?
<Amaranth> Riddell: aside from using gtk this thing is pretty nice for kde too :)
<seb128> no, this one got rejected
<seb128> then I uploaded to ubuntu :)
<elmo> Riddell: 298752
<elmo> (in Debian)
<elmo> we track Debian removals
<Riddell> elmo: ah hah, is it possible to override that?
<elmo> Riddell: why would you want to follow the Debian package naming?
<elmo> wouldn't
<Riddell> elmo: because a significant number of people have asked me not to, and I agree with them that it's confusing
<elmo> have you talked with the debian maintainer about it?
<Riddell> elmo: no response from him yet
<Riddell> but the other debian-kde devels sugge
<Riddell> but the other debian-kde devels suggest it's because they don't want the NEW queue
<Riddell> or they would change it
<seb128> lame excuse
<seb128> NEW is quite fast nowadays
<seb128> elmo: do you have an idea of where is hidding pyxdg 0.13?
<elmo> Riddell: I tend to agree with seb; and I'm worried about random divergence on the basis of something like that
<elmo> if you rename the package, all our sync tracking and MOM stuff breaks
<elmo> Riddell: but in any event, if you really want to go ahead, just reupload iwth the orig.tar.gz (-sa to dpkg-buildpackage, or upload it byhand after uploading the package)
<elmo> seb128: ah, katie broke.  yay
<Riddell> elmo: what's MOM?
<elmo> Riddell: your MOM.
<elmo> or Merge-O-Matic, take your pick
<Evaso> hi guys, i want try to backport somthing from ubuntu gnome-system-tools 1.2.0 in ubuntu to fix the modem applet problem permission with debian, anybody can help me?
<Riddell> elmo: right.  I'll discuss it with amu and make a decision, thanks for the info
<seb128> Evaso: I don't get the question
<seb128> which one works and which one is to fix?
* pitti taps foot while waiting for the damn wiki
<Evaso> seb128: on ubuntu works fine but on debian normal user, also if they are in the dip group, cannot start the connection with modem applet
<\sh> elmo: can u give me a pointer to this MoM tool?
<Amaranth> \sh: it runs automatically, files bug reports on packages that need manual merging, etc
<seb128> Evaso: look on debian/patches for the ubuntu packages, the patches are here
<infinity> \sh : http://people.ubuntu.com/~scott/ongoing-merge/
<\sh> Amaranth: i'm more interessted what software is behind :)
<elmo> seb128: fixed, now, should appear in next cron.daily, sorry baout that
<seb128> elmo: np, thanks for fixing it
<elmo> \sh: AFAIK the software isn't public ATM
<Evaso> seb128: here?
<seb128> debian/patches
<\sh> elmo: it's not http://www.inmaps.com/MOM.htm ?
<elmo> \sh: I doubt it
<Evaso> seb128: in the source package?
<daniels> Mithrandir: thanks
<seb128> correct
<elmo> .go daniels 
<daniels> Kamion: libxp6 should have if nothing depends on it, yes
<daniels> elm	?
<elmo> (it's your birthday)
<elmo> daniels: s#.#/# and you have an irssi command :/
<daniels> Kamion: don't know about libxkbui off the top of my head, would have to check it
<Evaso> seb128: probably could be this: +  * debian/patches/19_fix_initial_ppp:
<Evaso> +    - fix the problem that g-s-t does not set "noauth" for newly 
<Evaso> +      created connections?
<seb128> Evaso: dunno, should ask to mvo rather, he worked on that
<\sh> damn
<\sh> looks like I have to work on all this ocaml stuff
<Riddell> \sh: finish python-kde first :)
<\sh> give me 5 mins for ocaml ;)
<\sh> and then i need an main upper ;)
<mvo> ping doko 
<\sh> jo
<Evaso> mvo: do u know this bug?
<doko> mvo: pong
<\sh> Depends: libncurses5-dev, ocaml-base-nox (=${Source-Version}), ocaml-base-nox-3.08.3, ocaml-interp-3.08.3
<\sh> what is this? ocaml-base-nox-3.08.3 is a Provides in the same package :(
<pitti> jbailey: still no luck with ocaml for cdbs, btw?
<\sh> hmm......
<\sh> nice
<jbailey> pitti: I should give it another try.  Last time the build-deps were confused because of X.
<\sh> doko: all packages depending on ocaml should compile now with gcc-3.4? cause base is ftbfs with gcc4?
<pitti> jbailey: what do you use ocaml for in cdbs?
<jbailey> Generating a graph, IIRC.
<doko> \sh, I didn't look too hard at ocaml, but that looks like an interim solution
<jbailey> I could just stub that out, I doubt anyone looks at the one shred of documentation we ever did include. =)
<\sh> doko: i'm checking now the bug db of ocaml...cause there is at least one pack which depends on it
<ska-fan> Hmm, what's a media player in ubuntu that can play the guadec videos without stuttering sound and without frame drops?
<Nafallo> ska-fan: totem-xine
<kent> ska-fan, this channel is for development-related questions though..
<mvo> Evaso: modem-applet?
<Nafallo> ska-fan: what kent said. #ubuntu for userquestions.
<trulux> doko: heya
<trulux> doko: just talked to pitt, and he said we could provide a SSP-enabled gcc-3.3 in Breezy
<trulux> doko: what do you think= It would be just to forward copy the 3.4 patches to 3.3 debian/patches/
<trulux> and then enable the protector one and the rest
<thom> jbailey: dude, so we were wondering when cdbs will have mail handling
<jbailey> *mail handling*?
<ska-fan> Is there an #ubuntu-lounge or something like that that is not restricted to dev talk and not so crowded with people like #ubuntu?
<thom> it seems like the logical next step ;-)
<Mithrandir> jbailey: cdbs should so be able to read mail.
<jbailey> The GNU coding standards say that all good apps should include a pop3 client, IIRC.
<Mithrandir> jbailey: pop3?  We want IMAP, dude.
<thom> and TLS support
<Mithrandir> yeah.  And a lisp interpreter.
<Mithrandir> (did I say that out loud?)
<thom> and a windowing system
<jbailey> dilinger: HMm.  Should we rewrite cdbs2 in guile? 
<zul> visual basic is better
<Mithrandir> thom: X server in the build system?  Won't that be going a bit overboard?
<jbailey> zul: I suspect it won't compiler on hppa, don't want to annoy lamont.
<thom> Mithrandir: nah, it'll be fun
<zul> jbailey: lamont is easy to annoy and so much fun
<lamont__> jbailey: ??
<zul> lamont: just making sure you were awake :)
* lamont__ whaps zul
<zul> heh
<jbailey> lamont__: We were talking about you, not to you... ;P
<Mithrandir> jbailey: I want tetris too, when the builds take too long.
* lamont__ whaps jbailey with zul. :-)
<Nafallo> Mithrandir++
<ogra> thom, cdbsgtk ? 
<thom> ogra: cdbswm ;-)
<ogra> hehe
<lamont__> kobo-deluxe, not tetris Mithrandir 
<infinity> wasabi : That java/gjdoc stuff should all be sorting itself out now.
<Mithrandir> lamont__: both!
<Nafallo> is the kobo-stuff in main? ;-)
<jbailey> Anyone here remember bimodem?  So you could chat with the sysop when you did your uploads / downloads?
<zul> uh no
<Mithrandir> jbailey: yes.  And upload and download at the same time.
<doko> trulux: let's have gcc-3.3 in universe first. it's still used as a build-dependency on some packages
<\sh> jbailey: zmodem, bimodem, x and y modem :) 
<\sh> sometimes I'm using it :)
<pitti> Hi lamont__ 
<mdz> morning
<Nafallo> morning mdz :-)
<Nafallo> thom: how up to date is your networkmanager repo? builds on amd64?
<dilinger> jbailey: it may be better to include a guile interpreter in cdbs2, and have the individual modules written in guile.  oh, and the interpreter can be written in ruby.
<thom> Nafallo: totally not up to date
<thom> don't touch it
<thom> as soon as i get some licensing issues cleared up it'll be in the archive
<Nafallo> thom: oki.
<pitti> Hi mdz
<pitti> mdz: could you subscribe to http://www.ubuntulinux.org/wiki/UbuntuMainInclusionQueue ? I approved a few packages today, with a subscription you would be auto-notified
<mdz> pitti: cool, will do
<Simira> maswan: I forgot to cc the mail to you. But Tollef's birthday party will be next saturday. You're making him a cake, remember?
* pitti -> taekwondo
<KaiL> new nvidia driver - droped compatibility for older hardware :(
<dieman> hey
<dieman> why hasn't a udev related note been added to the hoary release notes yet?
<dieman> about linking in the cd-aliases.rules link.
<{Seb}> hey all
<{Seb}> btw, what happened in the backports meeting
<ogra> {Seb}, there will be minutes... 
<{Seb}> i know
<{Seb}> i read through them
<{Seb}> the IRC logs but I can't see what the solution is/was
<{Seb}> ogra: can you give me the basics?
<ogra> {Seb}, not now, sorry, i'm terribly busy
<{Seb}> ogra: one question, is mono 1.1.7 going or staying?
<{Seb}> ogra: i'm a beagle hacker :-)
<{Seb}> and this could decide my future with ubuntu
<tseng> i told him to leave it for now
<{Seb}> hey tseng
<ogra> {Seb}, it waits for some dependencys and will be in the default install in breezy
<{Seb}> i mean mono in backports
<ogra> given that its stable enough
<Nafallo> {Seb}: what tseng said
<tseng> but its still wrong.
<{Seb}> tseng: i saw my name got dragged into it
<tseng> i think I said you added that stuff on the beagle wiki about backports
<tseng> was all
<tseng> and that i failed to explain to you why the backport is broken
<Kamion> tseng: oh, I might not have told you, I figured out late last night what was up with beagle/amd64 building
<{Seb}> yep :-)
<tseng> Kamion: ah sweet!
<Kamion> tseng: it's an X bug - libxss-dev doesn't depend on libxss1
<Kamion> tseng: I told daniels about it
<tseng> Kamion: thanks!
<tseng> nice catch.
<{Seb}> well
<{Seb}> bye all
<Kamion> (so libXss.so was a dangling symlink)
<tseng> grr seb
<Nafallo> Kamion: rsync -rLtvz would work to bring the symlinks to universe into main and drop universe from my local mirror?
<mdz> wasabi: around?
<Nafallo> Kamion: or should I use -rLtvHz?
<Nafallo> s/to/from/
<Kamion> Nafallo: you may need to do two passes
<Kamion> Nafallo: see bin/anonftpsync in colin.watson@canonical.com--2005/cdimage--mainline--0 (http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005)
* Kamion goes off for the evening
<Nafallo> oki
<Nafallo> Kamion: thanx
<jnc> what's going on w/ libgtkhtml?
<jnc> libgtkhtml20 -> libgtkhtml2-0
<jnc> i don't understand that
<jnc> err it's universe
<jnc> hmm
<jnc> i think, nevermind what i was asking.    it's just that gnucash depends on some version of libgtkhtml that is no longer in breezy, and also a version of libofx which has been obsoleted
<srbaker> who do i speak to about the ubuntu bounties applicable for google soc?
<jnc> i hacked it up a bit and now it's working, so that's not anything i would say is bug-worthy
<philipacamaniac> Can I get someone to check my first deb package for errors or outstanding issues? It is at http://philipandjenny.com/wp-content/kubuntu-pkgmenu_1.3-0ubuntu1.deb
<Treenaks> philipacamaniac: have you run it through linda and lintian?
<philipacamaniac> I ran it through lintian, but I don't know linda
<philipacamaniac> lemme do that
<philipacamaniac> lintian was clean (for the most part)
<philipacamaniac> linda outputs nada
<uniq> you have to provide the source and the diff.
<philipacamaniac> okay, well, that's the thing - it's just a shell script. what is my source? The shell script?
<uniq> yes.. the source you use to build the package.
<philipacamaniac> okay so pretty much just a orig.tar.gz with the original files
<philipacamaniac> thanks
<mdz> jnc: if it's uninstallable, that's a bug, and should be reported to malone
<syndicate> I'm trying to build a .deb out of the fedora directory server, I am almost there, but it is looking for svrcore.h which should be a part of mozilla security stuff
<syndicate> does anyone have anything I can look for?
<doko> syndicate: packages.ubuntu.com, search for the file
<syndicate> dang
<syndicate> not on there
<syndicate> I guess I am stuck
<wasabi_> Eclipse runs.
<wasabi_> UnF.
<wasabi_> Okay! Uploaded!
<newz2000> I'm running into troubles using the new kickstart feature and not finding much help outside of one page in the wiki... Can anyone here help?
<wasabi_> I need somebody to do an upload of java-common to main for me.
<wasabi_> http://akita.larvalstage.net/~wasabi/java-common
<philipacamaniac> uniq: Do I create a separate debian source package, with packagename.orig.tar.gz and packagename.dsc as the contents?
<mdz> wasabi_: the new ecj-bootstrap uploaded today added unsatisfiable build-dependencies; we've tried to fix things up and hopefully it will retry soon
<mdz> meanwhile that whole stack is still blocked
<wasabi_> was that my fault or somebody elses?
<wasabi_> i dont remember what i did last night
<mdz> dunno, I think both you and doko uploaded it recently
<wasabi_> k. I have uploaded a new eclipse which builds and launches and works.
<Nafallo> baz seems great. my-id: invalid id (...) :-P
<wasabi_> And is suitable for main as far as I can tell. I need to go thru the entire dep tree.
<srbaker> wasabi, where can i download eclipse packages?
<wasabi_> multiverse.
<srbaker> wasabi, and does RDT work with it?
<wasabi_> RDT?
<srbaker> really?  wow
<srbaker> rubyeclipse.sf.net
<wasabi_> no clue. There is a lot of work to be done.
<srbaker> ahh
<wasabi_> On supporting plugins, etc.
<wasabi_> It does load plugins from /usr/local/share/eclipse
<srbaker> well, i'll keep using sun's java until it's working with RDT properly
<wasabi_> What does RDT do?
<wasabi_> Chances are if it's just a plugin and stuff, it'll work fine.
<wasabi_> If it's doing some crazy stuff, it might not. ;0
<srbaker> it's ruby support
<doko> wasabi_: it needs a sync from experimental, which will become possible in about 30 minutes.
<wasabi_> I know nothing about ruby. How is it called from Eclipse?
<wasabi_> JNI? Or just launching hte binary?
<wasabi_> etc etc... that is the stuff that matters.
<srbaker> wasabi, it calls the bin
<srbaker> hrm.  there don't seem to be prices listed with the ubuntu bounties
<wasabi_> doko, okay. My changes might already be in experimental. I have no idea who is keeping track of what on the Debian side.
<srbaker> i'm trying to figure out if i can afford to spend my whole summer working my ass off on bounties
<Amaranth> srbaker: If you mean for Google then it's them that pays you.
<srbaker> Amaranth, no, not google.  i'm not a student.
<srbaker> USD $4500 would be more than enough to make it worthwhile, though
<wasabi_> mdz, should I be adding myself to the technicalboardagenda for main consideration?
<wasabi_> or is there another more appropiate place to put it
<mdz> wasabi_: ask ogra or someone else from MOTU for guidance on the process
<wasabi_> yeah he said to do that. ;)
<wasabi_> just making sure!
<mdz> yay, ecj-bootstrap built
<mdz> srbaker: submit a proposal to me with a price
<doko> mdz, wasabi: ecj-bootstrap failed, because libant1.6-java is in universe
<mdz> doko: http://people.ubuntu.com/~lamont/buildLogs/e/ecj-bootstrap/3.0.1-3/ecj-bootstrap_3.0.1-3_20050602-2014-i386-successful.gz
<doko> ohh, yes, http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html was just updated
<srbaker> mdz, will do.  would it be acceptable to combine a few into one price?
<srbaker> mdz, i want to do system config tools and the simple backup solution one
<syndicate> If I wanted to file a bug against mozilla to be updated to provide the libsvrcore stuff, where would I do it?  In the universe bugzilla or the main one?
<srbaker> and maybe a third
<mdz> srbaker: it is preferable (I expect for both of us, in the end) to keep them separate
<srbaker> okay
<mdz> if we lumped them together, it would be all-or-nothing for all of them
<srbaker> okay, that's faie
<srbaker> fair
<srbaker> python is the preferred devel language, right?
<mdz> correct
<Nafallo> Kamion: dang. lot's of usefull stuff in there. would you like a kiss or something? :-)
<mdz> Riddell: are you around?  your last commit broke the kubuntu seed archive
<mdz> Riddell: you need to fix your umask to allow group writability, and chmod -R g+w /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0
<uniq> i think he's out.. said something about handing out cds.
<shaya> is there an issue w/ regular keyboard input in X now? (not ctrl-combos) I just restarted X and can't do any keyboard (as opposed to mouse which works fine) in X besides for ctrl-alt-backspace to kill it
<Zomb> /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o: file not recognized: File format not recognized
<Zomb> does anyone have an idea about what is going wrong there?
<Zomb> debsums does not display any faults
<Amaranth> seb128: pyxdg 0.14 is out, smeg needs it. Sorry about all these updates. :)
<Nafallo> Amaranth: lol
<Nafallo> Amaranth: will you ever put smeg in the archive? ;-)
<Amaranth> Nafallo: working on getting it into universe right now
<Amaranth> just need 0.14 to go with smeg 0.7.4 and it should be good
<Nafallo> hehe
<Nafallo> Amaranth: tomorrow you will want 0.15 to got with smeg 0.7.5 ;-)
<Amaranth> no no, i'm done :P
<Nafallo> hehe
<seb128> Amaranth: uploaded
<syndicate> this retarded piece of shit
<syndicate> !
<Amaranth> damn, that was fast
<syndicate> ok, this make file forces a specific installation directory, how can you make a deb of this
<seb128> Amaranth: yeah, users want smeg :p
<seb128> I don't want to make them angry :)
<Amaranth> seb128: I have users?
<seb128> apparently yep
<seb128> since some new user keep asking how to edit menu, and some other keep pointing smeg
<Amaranth> gnome-menus (>= 2.10) | kdelibs-data (>= 3.4) is the right way to depend on one or the other, right?
<herve> hi
<herve> seb128, ping
<Zomb> forget it, broken binutils caused that problem
<seb128> herve: pong
<seb128> Amaranth: yep
<herve> seb128, there's a new dia in debian I'd like to merge
<herve> seb128, mind I provide you a package to upload?
<seb128> not at all
<seb128> thank you for your work on it :)
<seb128> herve: you can use verbiste from debian/experimental, it works fine with GNOME 2.10
<seb128> herve: it's not synced yet for ubuntu due to the CXX transition
<herve> nice to hear, thanks
<seb128> np
<herve> seb128, hmm... it makes the panel hang
<seb128> oh?
<Nafallo> maswan: ping
<Amaranth> seb128: You should let me take the MenuEditor bounty as a part of Google's Summer of Code. :)
<seb128> Amaranth: I'm not handling bounties ....
<Amaranth> seb128: Yeah, but you said to drop it.
<dieman> heh
<dieman> even though its not a bounty, im interested int helping out with NetworkWideUpdates
<seb128> yeah, gnome-menus ships one, there is an another one on the GNOME CVS, and there is smeg which is opensource
<seb128> I don't think we need to bounty that objectively
<seb128> dieman: nice
<dieman> its something i really need
<dieman> i do it in a very non-auditable way right now, im never really, really sure all the machines are up to date
<dieman> im fairly sure.
<herve> seb128: panel hang is reproducible
<herve> even after reboot
<seb128> herve: utch
<seb128> when does that happen?
<seb128> remove the package to fix it?
<herve> it happens when I add the applet
<herve> the panel hangs and is likely to crash
<herve> when I manually kill it, gnome question about reloading it is hung too
<herve> no, a kill -9 puts it to reason :-)
<ajmitch> hi pitti 
<herve> seb128, found it: I had not updated verbiste-gnome... :-)
<herve> seb128, let me suggest strict dependencies!
<pitti> hi
<herve> hi pitty
<dieman> wow
<dieman> arch is cool
<dieman> finally forced myself to use it
<herve> yes it is
<Amaranth> you're using baz and not tla, right?
<pitti> dieman: yes, once you get used to it you'll love it :-)
<dieman> Amaranth: yeah
<dieman> i tried using tla and got the dreaded 'arch_archive_connect: attempt to connect to incompatible archive'
<dieman> and found this page: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-kernel-2005-03-17.html
<dieman> which was essentialy fabbione saying to use baz :)
<Amaranth> so, someone had a good idea on what to do with gnome and cvs
<Amaranth> migrate to subversion and mirror in baz
<Amaranth> baz mirror is read-only
<pitti> dieman: baz is *much* easier to live with
<herve> but tla and baz use the same archive format?
<Nafallo> pitti: oh yea? my-id: invalid id
<Nafallo> pitti: ;-)
<dieman> heh
<pitti> herve: not really
<pitti> herve: baz can read, write and create the tla format, but its native format is different
<pitti> Nafallo: erm, and the same id works with tla?
<Nafallo> pitti: dunno. never used tla.
<herve> pitti: good, that way is enough for me
<Nafallo> pitti: I'm new to all those rc-systems ;-)
<pitti> Nafallo: an user id must look like "Name <email>"
* ajmitch just started using baz a few days ago
* pitti uses tla and baz for ~ 1 year
<dieman> hmm
<Nafallo> pitti: did that. probably doesn't like  :-P.
<herve> Nafallo, yes, I had to forget the diacritics of my name
<pitti> Nafallo: oh yes, these beasts still have serious trouble with non-ascii chars
<dieman> it seems like NetworkWideUpdates is a bit less than I hoped for at the moment.  Mostly helps out people who don't already have a file distribution and command execution infrastructure of their 'pile of machines'
<Nafallo> dang. I have to go with Bjalevik then ;-)
<Nafallo> or change name :-P
<herve> seb128, I forget about dia for now, it's caught in the fire of cxx transition
<ajmitch> dieman: what do you want NetworkWideUpdates to be? pushing updates to a group of machines?
<dieman> ajmitch: i really should sit down and think about it more, right now i do similar to whats proposed with cfengine by running certain apt commands periodically.
<seb128> herve: k
<wasabi_> I have really given a lot of consideration to a Apt network update system. I have a lot of ideas. ;)
<dieman> what im interested in is having profiles of machines and having an agent try and bring machines close to that profile and alert me when it can't.
<wasabi_> Actually I started working on something awhile ago.
<herve> wasabi_, thanks for eclipse 3.0 by the way!
<wasabi_> np
<wasabi_> it work for you?
<wasabi_> It's totally unbuilt.
<dieman> either meaning that the packages are broken in some way, or that some security update isn't making it out there.
<wasabi_> But you can build it yourself!
<herve> haven't tried yet
<dieman> (checking versions and packages installed)
<dieman> on top of the profile, having allowed exceptions for certain machines and alerting to additional packages manually installed would be nice so I know if another administrator or one of our 'administrator users' is using extra software.
<dieman> so I have a good idea of what software we need to be sure to support in the future, etc.
<wasabi_> my apt update idea:   A daemon that simply manages an apt mirror.
<wasabi_> The daemon (thru a web interface) provides an interface to view what updates are proposed, and accept or reject them.
<wasabi_> Or schedule them.
<Nafallo> Kamion: ping
<dieman> staging systems like that would be nifty
<wasabi_> That's what MS does.
<wasabi_> Basically.
<dieman> especially if we can have the staff machines test updates
<wasabi_> The client machines simply apt-get update on a schedule. Reporting information could be sent to the server.
<dieman> and then the rest of the machines.
<wasabi_> I was going to do it in Mono.
<wasabi_> Back when I last thought about it.
<Nafallo> hmm, off for the evening it was.
<wasabi_> pretty easy to implement actually.
* Nafallo is glad he keep logs
<lifeless> Kamion: ping
<Nafallo> lifeless: he's off for the evening since som hours ago.
<lifeless> ah
<lifeless> probly moving some more foo
<pitti> jbailey: yay cdbs, thanks
<pitti> seb128: ^ that means that we now should get nice pot files for your gnome uploads :-)
<seb128> rock!
<dieman> ajmitch: did you catch any of that, or should we get some people together and brainstorm issues? :)
<pitti> seb128: so please upload the whole gnome now, kthxbye
<dieman> haha
<pitti> ;-)
<jbailey> pitti: Yup.  And if anyone asks why the shred of docs there were there is now gone, I'll give'em your number ;)
<pitti> cdbs had docs? *duck*
* lifeless wants to find a debian sponsor for gnu-smalltalk
<jbailey> pitti: Well it had a graph that noone looked at.
<jbailey> lifeless: Who's the packager?
<lifeless> brett cunly
<jbailey> lifeless: Is this an upload targetted at Sarge?
<lifeless> sorrru cundal
<lifeless> no, sid
<lifeless> gnu smalltalk is a year old, and it doesn't need to be.
<jbailey> Sure, I can do it.  Is he planning to take it over, or just do a single update?
<lifeless> hes been at this for a while, so I think is in it for the long haul : http://www.cundal.net/debian/
<lifeless> (Hes the current maintainer FWIW)
<ajmitch> dieman: I caught some of that, and I think it should be written down somewhere :)
<dieman> ajmitch: ok
<dieman> i'll write down that i should either harass the mailing list or make up a wiki entry
<dieman> about the idea
<dieman> i dont expect it to be a breezy goal, etc.
<dieman> i've got an idea from my experiences here, but i need to find other desktop admins and figure out how they've been doing things
<dieman> i've not met many people handling 50+ desktops (let alone nearly 300)
<lifeless> 50 is on the low side for an admin, should be > 100 per admin even with windows
<doko> elmo: lib32z1-dev and lib32z1 are NEW and should be moved to main. ia32-libs now depends on lib32z1, gcc-4.0 will build-depend on lib32z1-dev
#ubuntu-devel 2005-06-10
<ezequiel> hi ppl
<ezequiel> how can I create a .deb?
<Amaranth> ezequiel: google for the debian new maintainer's guide
<ezequiel> Amaranth, thanks
<ezequiel> 'cause I'd like to have my own anjuta2 deb =) long life anjuta2!
<ezequiel> (I still remember when it was just scaffold)
<lifeless> jbailey: so, did it look ok ?
<lamont__> what is it that calls ifrename?
<Mithrandir> lamont__: hotplug
<Mithrandir> /etc/hotplug/net.agent, it seems
<lamont__> yeah - just finally tracked that down...
<lifeless> when it misbehaves its a biatch
* lamont__ just discovered that the USB nic beat out the non-USB nic at boot time.. most annoying
<lamont__> didn't have the USB nic in /etc/iftab - hence the pain
* Mithrandir wanders off
<tseng> bye Mithrandir 
<allee> allee: udu.wiki: LaptopHardwareSupport:  Special Keys: Found no infos about add/help 'preconfiguring' them out-of-the-box for breezy
<allee> allee: How can on join/help on this topic?
<lifeless> does ubuntu watch wired ethernet for cable-insertion by default ?
<mjg59> allee: I'm working on that at the moment
<mjg59> With luck, there should be some support in Breezy next week
<allee> lifeless: no
<lifeless> allee: thanks
<mjg59> lifeless: That's part of NetworkMagic (which doesn't actually exist yet)
<allee> mjg59: great
<lifeless> mjg59: yeah, I was at the bof ;) can't blame me for hoping ;(
<Nafallo> license issues :-/
<allee> mjg59: via which pkgs will add the support so I can check them (I know several ways to do it ;)
<allee> mjg59: and contribute of course
<mjg59> allee: It'll probably be by adding a new package, to begin with
<allee> mjg59: care to sketch how it's planed to work?  Just to get the idea about the direction and used route
<lifeless> mjg59: I can't login to ubuntulinux.org at the moment
<lifeless> mjg59: is there somewhere else I can put the keycodes ?
<Amaranth> hrm, i wonder where johndong is
<allee> lifeless: oh, I did I miss a page for keycodes :(  URL?
<lifeless> allee: I promised to make one
<lifeless> but nologin == no keycodes
<allee> LinuxJones: k.  And I promise to add data when done
<allee> s/LinuxJones/lifeless/.   <Tab> got me :(
<lifeless> heh~
<mjg59> allee: Effectively the following:
<mjg59> allee: Bind machine scancodes to generic keycodes (using DMI to tell which set of scancodes to use)
<mjg59> allee: Configure those keycodes to do the right thing in X
<mjg59> allee: And for machines which generate ACPI events on hotkeys, generate a fake X keycode
<lifeless> mjg59: so ..
<lifeless> mjg59: where should I list the codes as I can't wiki them 
<lifeless> udu wiki ? 
<jbailey> lifeless: Sorry, I got distracted.  Where is the package? 
<mjg59> lifeless: LaptopKeycodes
<mjg59> Oh, argh. Wiki is broken?
<lifeless> my login is
<mjg59> Gah
<mjg59> Just stick them on a website somewhere, we'll add them later
<mjg59> Dell seem to use the same scancodes as Microsoft, which makes things easier
<lifeless> jbailey: 
<lifeless> http://www.cundal.net/debian/
<pitti> night
<Nafallo> pitti: night :-)
<Nafallo> dooh!
<allee> mjg59: DMI?  I'll try with dmidecode.  I'm not sure I find stuff like 'XFAudioRaise' (or so) there
<mjg59> allee: No, you won't
<lifeless> mjg59: people.ubuntu.com/~robertc/codes.txt
<mjg59> allee: That's not the issue. We need to know what pressing the key does. Once we know that, we can use the DMI information to know which set of scancodes to use on an arbitrary machine.
<mjg59> Once we have the scancodes, everything else is easy
<lifeless> mjg59: what dmi info do you need to id the dell ?
<mjg59> lifeless: Vendor name, model name
<lifeless> I'll put it in that file
<mjg59> (form DMI)
<lifeless> this foo:
<lifeless> Handle 0x0100
<lifeless>         DMI type 1, 25 bytes.
<lifeless>         System Information
<lifeless>                 Manufacturer: Dell Inc.
<lifeless>                 Product Name: Latitude X1                     
<lifeless>                 Version: Not Specified
<lifeless>                 Serial Number: 37VCF1S
<mjg59> Yeah, that stuff
<lifeless>                 UUID: 44454C4C-3700-1056-8043-B3C04F463153
<lifeless>                 Wake-up Type: Power Switch
<mjg59> But not the serial number
<lifeless> doh
<lifeless> well thats mine!
<lifeless> and its public record now :)
<Nafallo> hehe
<mjg59> (One of the things about the hardware database spec was working out what information we didn't want to send...)
<lifeless> mjg59: ok, its all in codes.txt
<lifeless> if someone could redact this log to strip that serial that would be nice.
<lifeless> fabbione: ^^ ?
<mjg59> lifeless: Ta
<lifeless> though I'm sure there are 4000 other logs being made
<lifeless> np
<lifeless> pure selfinterest here
<jbailey> lifeless: Does this guy IRC?  I would usually have the person do some cleanups before I sponsor.
<lifeless> you just Know that when I start using breezy I'll be looking for this to JustWork ;)
<lifeless> jbailey: dunno, though he is responsive on email
<lifeless> Brett Cundal <bcundal@cundal.net>
<allee> mjg59: Sorry now I'm confused. "We need to know what pressing the key does" for me means: check showkeys output for scancode and label it with 'logical description".  How is here dmi invovled?
<lifeless> his package has been uploaded many times, just his regular sponsor has gone busy/awol
<jbailey> lifeless: Did he ask you to sponsor this, or are we just snarfing it off his site?
<lifeless> so I wouldn't anticipate significant issues with the packaging itself.
<mjg59> allee: On system boot, we need to use the DMI information to work out which scancodes to use on a given machine
<lifeless> He asked me to help him find a sponsor
<lifeless> he asked on debian-mentors *months* ago
<mjg59> Dells use one set of scancodes. HP use another. Acer use a third.
<lifeless> jbailey: quoting: Sure... I just need a sponsor to upload the package. The package needs
<lifeless> to be looked at for packaging errors and whatnot, to see whether it's
<lifeless> suitable for inclusion in Debian... Since it's already in unstable and
<lifeless> the changes are fairly minor since the last upload, I would expect it
<lifeless> to be not much work. 
<allee> mjg59: Ah so DMI is only used to find out producer/model and that get's acociated with a scancodes config-file
<mjg59> allee: Exactly
<jbailey> lifeless: So far not much packaging work.  He has example scripts lying around that he doesn't need.  He renames the packaging without really saying why he does it.
<mjg59> Once we have the scancodes and the dmi information, we can ensure that on boot that stuff works properly
* jbailey tries a build.
<lamont__> mjg59: any ideas on how well suspend to {disk,ram} works on the HP NC6000?
<lifeless> jbailey: ok. want me to give it a once over first ? (I am interested in getting gst updated which is why my fingers are involved)
<jbailey> Nah, I've already gone over the packaging, verified that it's the same as upstream source, yada yada.  Now I'm just seeing if it builds. =)
<lifeless> ;)
<jbailey> lifeless: My Debian machine is an ia64. =)  It's currently FTBFS on that arch...
<lifeless> cool!
<lifeless> jbailey: 2.1.10 has updates that Paolo said should fix at the time
<lifeless> the FTBS is on 2.1.8 which June 2004
<lifeless> .. thus the desire to get 2.1.10 uploaded
<lamont__> eep.  off to training.  back in a few hours
<lifeless> jbailey: if it doesn't work, I'd love accesss to that machine to fix it ;)
<thom> if you need it i'll kick my ia64 bgack on to ipv6 and you can abuse that...
<lifeless> thom: thanks!
<mjg59> lamont__: Should be fine, but you need to blacklist i2c-i801
<mkde> ooh
<mjg59> (not sure why)
<mkde> hi mjg59, i was saying the other day about some of my laptop keys not working, you said to look in dmesg, i didn't find em
* thom -> bed
<mjg59> mkde: What sort of laptop?
<mkde> mjg59, its a compaq presario 2100
<mjg59> mkde: Ok. It's possible that it needs some magic.
<mkde> mjg59, i'm all ears
<mkde> mjg59, i feel sure that once upon a time the mute button used to work with linux
<mjg59> mkde: I'm afraid I don't have any old Compaq hardware, and it's basically been killed since the HP merger, so it's hard to get test kit
<mkde> mjg59, ok
<mkde> mjg59, is it likely to be a kernel or a xorg problem?
<mjg59> mkde: Kernel
<mjg59> mkde: Well, kernel-ish. X knows nothing about the keyboard.
<allee> mkde: Mute:  what does not work:  sound still on or xev show nothing/no keysym or showkeys gives nothing?
<mkde> nothing on xev
<mjg59> If pressing it shows nothing in xev and nothing in the kernel dmesg, then something needs to be done in the kernel
<mkde> to be fair, even the hotkeys that work don't come up in dmesg
<mkde> its strange that some work and others not
<allee> mkde: and on console:  gives showkeys any output?
<mkde> allee, what should I do to test?
<mkde> mjg59, so is it worth filing a bug upstream or just leave it you think?
<allee> mkde: ALT-CRTL-F1  login and run showkeys, then press not-working keys
<mjg59> allee: It's not really a bug, it's a missing feature
<mkde> is "showkey" the same thing?
<mjg59> Without the hardware, it's hard to tell what's going on
<mjg59> s/allee/mdke/
<mkde> mjg59, ok
<mkde> mjg59, if the hardware isn't made anymore i guess its not really worth us working on it
<allee> mkde: ops, yes showkey
<mkde> allee, gives nothing
<mjg59> mdke: Well, it's something I'll look at if I can find any information about it, or get hold of some of the hardware
<mjg59> But at the moment, I'm concentrating on current stuff
<allee> mkde: now I'm stuck :(
<mkde> mjg59, thats fine
<mkde> mjg59, if you ever have a old hardware fest I can bring this laptop along ;)
<allee> mkde: did you check linux-for-laptops archive for infos about keys for your model already?
<mkde> allee, will do now
<mkde> allee, linux-laptop.net?
<allee> mkde: yes and http://tuxmobil.org/mylaptops.html
<mkde> allee, yeah, this confirms my problem http://slist.lilotux.net/laptop/
<mkde> no biggie
<mkde> just in case there was a quick fix or i could report it somewhere
<mkde> the laptop works fine otherwise
<allee> mjg59, lifeless: what's the best way to get notified about changes in this area.  So I can jump in whenever I can contribute?
<mjg59> allee: At the moment, probably just to monitor the ubuntu-devel mailing list
<mjg59> I'll send something there once some code exists
<zul> mjg59: what kind of laptops are you guys going to be sending to testers?
<zul> im just curious
<mjg59> zul: IBM, Toshiba, Dell, possibly HP, possibly Apple, possibly Sony
<zul> cool
<mjg59> Mostly looking at the business end of the market at this point, then shifting down to the consumer end in future
<zul> nice
<allee> mjg59: uhm, well. 'nother list broad topic list ;)  Nevertheless I'll do.  Thx!
<mdz> ogra: aw, what happened to the xscreensaver prettiness?
<ogra> http://www.grawert.net/xss_mockup.png
<ogra> ;)
<ogra> working on it
<mdz> infinity: ping
<Amaranth> ogra: Change User?
<ogra> yeah
<Nafallo> ogra: wasn't you saying /users/ where to complain ;-)? not devs :-P.
<Nafallo> heh
<Amaranth> ogra: I'm saying it should say 'Change User' ;)
<Nafallo> mjg59: any amd64 laptops?
<ogra> probably "other user"....
<Amaranth> the people in the background are spooky
<ogra> hehe
<mjg59> Nafallo: None of the big vendors have really gone with them yet, so that may be Breezy+1
<ogra> that are the people behind ubuntu ;)
<Nafallo> mjg59: hmm. how long are you going to send out laptops? ;-)
<Amaranth> ogra: I'm saying the way they're presented are spooky.
<ogra> heh...
<mjg59> Nafallo: We'll be starting in a month or so, and we'll be doing it while we have money to spend on this project :)
<mjg59> Though the budget is not that big
<Amaranth> ogra: Either make them a bit more visible or drop them, I'd say.
<Nafallo> mjg59: kewl :-)
<mjg59> People will get to keep the machines if they file enough reports
<ogra> Amaranth, nope
<Amaranth> ogra: It totally creeps the hell out of my as is.
<Amaranth> s/my/me/
<allee> mjg59: no joke?  Testers can apply for a laptop?
<Amaranth> ogra: Can you make one without the people, just for comparison?
<ogra> nope
<mjg59> allee: Yeah. Read the mailing list :)
<Amaranth> ogra: What was the point of showing us then?
<mjg59> It'll only be 10 or so people getting them, and it'll be based on the amount of community involvement
<allee> mjg59: wasn't subcribed ;)
<ogra> Amaranth, mdz asked ....
<Amaranth> I wish I was a Member. :)
<Amaranth> I'd apply for one of those, I like breaking things.
<Amaranth> software, not hardware
<allee> mjg59: ah.  No problem I've nough of (Dell) laptops around me ;)
<lifeless> allee: I'm loving my X1 ;)
<mjg59> The Dell X series is all rebadged Samsung stuff
<mjg59> lifeless: Does it do suspend to RAM?
<lifeless> yes
<allee> lifeless: good too know now that the X300 is no longer produced.   How hardware support out-of-the-box?
<lifeless> and hibernate
<mjg59> lifeless: Hurrah. An improvement.
<mjg59> The X300 needed DSDT hacking.
<lifeless> doesn't bring the ipw2200 back correctly from hibernate, does from ram
<allee> mjg59: I had no succes with X300 here (with patched DSDT) :(
<KaiL> lifeless: unloading the module helps?
<mjg59> allee: Should work with stock Hoary
<mjg59> Chat to jdub about it at some point - it works for him
<Nafallo> baah, my laptop doesn't hibernate at all :-P
<Nafallo> it might have worked with hoary, but I'm not sure.
* allee retries ...
<Nafallo> (before adding rt2500 wlandriver ;-))
<lifeless> KaiL: oh yes, its trivial to fix
<lifeless> KaiL: rmmod, modprobe, its back.,
<KaiL> lifeless: maybe network modules should also be unloaded? They fail quite often...
<Nafallo> do we kill hotplug? that will bring my wlan right back in ;-)
<lifeless> KaiL: it is removed 
<KaiL> "should always" I mean..
<lifeless> KaiL: its not inserting properly straight after the from-hibernate resume
<allee> mjg59: X300: fn-suspend -> dead (power led on, black screen, ping: unreachable etc)
<mjg59> allee: Unf. Dunno.
<KaiL> get better Laptops :)
<mjg59> allee: Edit /etc/default/acpi-support and change USE_DPMS to false, then see if there's any text when it hangs
<KaiL> Samsung P35 works perfect for example (except SDIO, but that's anothr story)
<allee> KaiL: SDIO? what's that?
<allee> mjg59: I'll try
<KaiL> allee: Slot for SD-Cards
<KaiL> allee: Linux currently only supports MMC-Cards (that's more or less a subset of that) and only with a Winbond chip, not the used Ricoh
<allee> mjg59: ha, black screen instead of grub menu.  Great ;)
<mjg59> allee: ?
<bob2> Ricoh has support in 2.6.12, iirc
<mjg59> bob2: No, just Winbond
<allee> mjg59: powered off and and.  See the f2/f12 selection then screen is black no grub menu
<mjg59> allee: ?
<mjg59> allee: Suspend shouldn't power off
<KaiL> the Winbond is already in 2.6.10 (wbsd module)
<mjg59> Are you sure you're suspending and not hibernating?
<allee> mjg59: remember: the x300 was dead. 
<mjg59> allee: Dead how?
<mjg59> allee: Oh, hung?
<allee> [02:32]  <allee> mjg59: X300: fn-suspend -> dead (power led on, black screen, ping: unreachable etc)
<mjg59> Remove the battery and hold the power button down for a while
<Nafallo> gaah. I got a cheap_laptop(tm)
<Nafallo> Manufacturer: ACTEBIS (what happened to Targa?) ;-)
<KaiL> Nafallo: that doesn't mean anything. does it work?
<allee> mjg59: thx, grub menu back  (nice experience)
<Nafallo> KaiL: ofcourse ;-)
<KaiL> so who cares....:)
<KaiL> at least you don't need to fight with the pre-alpha drivers, windows users need to use :))
<Nafallo> hehe
<Riddell> mdz: do I still need to fix the permissions issue on the kubuntu seeds?
<KaiL> btw. is there any hardware known not to work, except those SDIO stuff and some broken ACPI tables?
<Nafallo> this amd64-laptop shipped with winxp home 32-bit for what it worth ;-)
<mdz> Riddell: yes, please
<allee> kail reminded me that it's late in europe ;)
<allee> Nite
<Riddell> mdz: hopefully that's it fixed now
<mdz> Riddell: testing
<mdz> Riddell: nope
<mdz> drwxr-sr-x  3 jriddell warthogs 4096 Jun  3 01:46 /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com/seeds/seeds--breezy/seeds--breezy--0/patch-6/++revision-lock/
<mdz> Riddell: that stuff all needs to be group-writable; set your umask to 00x
<mdz> and chmod -R g+w on the tree to fix what's already there
<mdz> jbailey: regarding #11135, you said you had a patch ready for review?
<KaiL> allee: good idea ;)
<allee> KaiL: yeap
<Riddell> mdz: do I change it on my local repository or on chinstrap?
<mdz> Riddell: on chinstrap
<Riddell> mdz: ah
<mdz> chmod -R g+w  /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com
<mdz> to fix the immediate problem so that I can commit
<Riddell> mdz: done
<mdz> Riddell: much better, thanks
<mdz> for the more permanent fix, make sure ~/.bashrc specifies umask 002
<Riddell> mdz: do I have to set the umask somewhere so it stays like that?
<Riddell> yep :)
<mdz> though I thought that was the default
<Riddell> mdz: it seems to be the default, but I had checked it out onto my laptop where the umask isn't set for group writable
<mdz> oh, that might explain why this has happened to a few others as well
<mdz> if the local permissions affect it
<mdz> but I don't see why that would be
<mdz> bob2: is that possible?
<Riddell> I'll put a note on the seed page on the wiki
<bob2> if you check it out, and the umask changes the permissions on-disk, they can get checked back in
<mdz> bob2: in this case, the issue is permissions on files in the archive itself (like ++revision-lock)
<infinity> mdz : pong.
<mdz> infinity: can I get a retry of antlr?
<mdz> it should succeed this time
<Clint> mdz: acls can make those problems go away
<infinity> mdz : Did the seeds get shuffled? :)
<mdz> Clint: acls can replace those problems with, newer, harder to debug problems ;-)
<mdz> infinity: seeds, versions, yeah
<infinity> mdz : Alright, bouncing it.
<mdz> I'm trying to unravel this chain of java stuff
<mdz> if antlr builds, that should unblock gjdoc, which should unblock junit, which should unblock (I think) libant1.6-java, which unblocks the world
<mdz> then we can move the lot into main and have free java apps in main
<mdz> wasabi says eclipse is nearly there
<wasabi> eclipse *is* there.
<wasabi> or will be when the buildds get sorted out. ;)
<wasabi> (and somebody uploads my java-common to main since I can't)
<infinity> mdz : Actually, it looks like ecj-bootstrap binaries are stuck somewhere (queue/new?).  It's in state "Uploaded", not "Installed"... If it was in the archive, antlr would have built already (I set the right dep-waits last night)
<wasabi> http://kyoto.larvalstage.net/~wasabi/java-common
<wasabi> oh my apache is segfaulting. heh.
<wasabi> http://akita.larvalstage.net/~wasabi/java-common
<mdz> infinity: very weird
<mdz> it's sitting in queue/unchecked
<mdz> but queue/REPORT says it was accepted
<mdz> ecj-bootstrap_3.0.1-3_i386.changes
<mdz> ACCEPT
<mdz> ecj-bootstrap_3.0.1-3_all.deb
<mdz>   to pool/universe/e/ecj-bootstrap/ecj-bootstrap_3.0.1-3_all.deb
<mdz> Accepting.
<infinity> mdz : Neat.  (the one in unchecked may have just landed there, I reuploaded it thinking it may have got lost)
<mdz> infinity: oh, so it did
<mdz> no idea where the previous one went, but we'll see how this goes
<infinity> Apparently, jackass has been acting up recently, and katie's been doing goofy things.  So, I'm not even willing to hazard a guess as to what might have gone wrong. :)
<infinity> (A couple of source uploads seem to have been accepted, had mail go to -changes, then head off into NerverNeverLand too)
<Traveler1> Does somebody knows where can I find some kind of documentation about multiseat package?
<mdz> infinity: possibly a side effect of all my teri'ing lately
<wasabi> mdz, do you mind uploading the java-common i posted?
<mdz> infinity: is there anything else that needs attention in the libant1.6-java chain?  I want to move it, junit, libjaxp1.2-java, junit into main today
<mdz> wasabi: done
<wasabi> thanks you
<mdz> daniels: what do you think is the best way to handle starting the X server on thin clients?  ltsp currently uses /etc/inittab, but I think a daemon with an init script would probably be more appropriate
<mdz> daniels: can we (ab)use one of the display managers for this purpose?
<infinity> mdz : Do we need to sync a new libant1.6-java from Debian still?  The one in the archive predates all this java buggery by several weeks.
<wasabi> Nope.
<wasabi> The ant in Ubuntu is radically different than the one in Debian.
<wasabi> Just waiting for Sarge to be altered in Debian.
<infinity> wasabi : Kay.  We've been pulling the other stuff from experimental, we don't want the experimental ant?
<wasabi> Uh. Um....
<wasabi> I can't say.
<wasabi> I don't know if they merged my changes into there.
<wasabi> Let me take a look.
<wasabi> They're even differnet source packages.
<infinity> Yay.
<wasabi> 'ant' in ubuntu produces libant1.6-java, 'libant1.6-java' in Debian produces libant1.6-java, in main
<wasabi> And a seperate 'ant' package in contrib does the rest.
<infinity> Ahh.
<wasabi> I unified them into one package, all compiled with free VMs
<wasabi> It's just too big of a change for Sarge, so Debian wants to hold off.
<infinity> Thanks, I was looking at the wrong source package. :)
<wasabi> It doesn't look like the right stuff is in experimental.
<infinity> wasabi : Is the current 'ant' build failure on breezy yet another "needs a newer gjdoc" dep-wait, then?
<wasabi> Hadn't noticed. Looking.
* infinity apologises for his ignorance, but he doesn't speak fluent java (or fluent java errors)
<infinity> Probably owing to the fact that there's been very little java stuff in main, historically. :)
<wasabi> excuse my slowness, my computer is falling apart at the seems.
<wasabi> epiphany now refuses to launch, along with nautilus. ;)
<gentoon> Breezy ready for testing yet?
<gentoon> I have a 40gb partition open
<Amaranth> gentoon: Are you comfortable in a shell (no X)?
<Amaranth> gentoon: Can you figure out complex linux problems without help?
<infinity> gentoon : It's always ready for testing, but definitely not ready for every day use.  (so, not ready for regular "end user testing")
<gentoon> No one can do that, thats why we have bugs and forums and docs
<gentoon> I know thats why i asked if its ready for "testing"
<Amaranth> #ubuntu users using breezy right now have agreed to not help people running breezy as a way of stopping casual users from trying to use it
<wasabi> Nobody?
<gentoon> And i work in pure CMI everyday all day at work
<gentoon> Thats very anti-productive
<gentoon> everyone thats testing it should talk to eachother
<wasabi> Good, so they shouldn't be testing, and they won't have to be talked to!
<gentoon> so you don't want people to test it yet
<Amaranth> gentoon: Users who know what they are doing and plunge ahead anyway are the ones that can figure out what is going on and file bugs.
<gentoon> okay thats what i was asking
<Amaranth> gentoon: It needs lots of testing, just not from casual users right now.
<gentoon> Well yea, but when testing new stuff, its nice to see known bugs, so ya dont run in circles that have been ran in my someone else
<tseng> eh it needs more testing of universe CXX apps
<tseng> and less people moaning about xorg
<gentoon> Now you have insulted me, by calling me a 'casual' user, i have been coding since before you were alive probably
<Nafallo> tseng: and monodeps ;-)
<tseng> gentoon: who called you that?
<tseng> we made a generalization that had nothign to do with you
<gentoon> Anyways, i offered i guess its back to SID
<tseng> but the situation in general
<gentoon> see ya guys
<gentoon> and good luck
<wasabi> bye! =)
<infinity> wasabi : So, the ant failure is...? :)
<wasabi> I don't know.
<wasabi> I can't even open a browser heh
* wasabi lynx!
<infinity> mdz : Feh.  ecj-bootstrap is still stuck in Uploaded (again).  We may need an elmo if someone else with rights to the archive can't figure out where it went.
<infinity> wasabi : wget http://people.ubuntu.com/~lamont/buildLogs/a/ant/1.6.2-2ubuntu3/ant_1.6.2-2ubuntu3_20050602-0708-i386-failed.gz
<wasabi> Hmm. Looks like an actual problem.
<mdz> 2005-06-03 02:20: ecj-bootstrap_3.0.1-3_i386.changes libchipcard_0.9.1-7_sparc.changes
<mdz> ecj-bootstrap_3.0.1-3_i386.changes
<mdz> REJECT
<mdz> Rejected: ecj-bootstrap_3.0.1-3_i386.changes: a file with this name already exists in the Accepted directory.
<mdz> Rejected: ecj-bootstrap_3.0.1-3_all.deb file already exists in the Accepted directory.
<mdz> Rejecting.
<wasabi> But it's caused by a bug in java-gcj-compat.
<wasabi> Which I thought I fixed.
<infinity> mdz : Okay, so it was properly accepted, just never got installed from accepted.  Fun.
<wasabi> Can it be built again?
<mdz> infinity: I'll kill it from accepted if you can reupload
<infinity> mdz : I can.
<infinity> wasabi : I can toss it back if you think it'll build on the second go.
<mdz> infinity: ready when you are
<wasabi> one second, making sure
<infinity> mdz : Always ready.
<mdz> infinity: killed
<infinity> There, re-uploaded.
<wasabi> Hmm. Actually I thought doko fixed this.
<wasabi> doko, ping. Was java-gcj-compat updated to depend on ecj?
<wasabi> infinity, it won't rebuild until I know what happened to the fix to java-gcj-compat, so don't retry it.
<infinity> wasabi : It depends on ecj-bootstrap (the version we're trying to get installed right now) | ecj
<wasabi> errr.
<wasabi> Oh I see. Heh.
<infinity> So, should I dep-wait ant on ecj-bootstrap? :)
<wasabi> I uploaded a temporary fix to Ant because I couldn't upload a real fix to java-gcj-compat (because it was in main)
<wasabi> There should still be a valid ecj-bootstrap binary.
<infinity> Not the version that java-gcj-compat currently depends on. :)
<wasabi> OH.
<wasabi> and then doko fixed java-gcj-compat with a bad version. ;)
<infinity> (Not the new version of j-g-c anyway)
<wasabi> So, I think where we're at is that j-g-c needs to be fixed, and I think doko was doing that.
<mpt> mdz: I was told yesterday that the wiki spec for LaunchpadIntegration is wildly out of date now -- Who should I be pestering to update it? Apparently I'm supposed to be helping with the design
<infinity> So, yeah.  If you tell me it will all magically work when ecj-bootstrap is rescued from oblivion, I'll retry ant shortly.
<wasabi> Java is so incestuest.
<mdz> mpt: truthfully? sabdfl ;-)
<mpt> ehhh
<infinity> wasabi : Don't feel bad.  Most big package sets are like this.  Heck, even X build-depends on itself.
<mdz> mpt: he has specified that he wants to add two items to the Help menu of applications which have a Help menu
<mpt> mdz: That's what I suggested originally, and got shot down :-P
<wasabi> We could fix j-g-c
<wasabi> I just can't upload it, because it's in main now.
<infinity> wasabi : What fix does it require?
<wasabi> So I was waiting for doko to do so.
<wasabi> IT needs to build-depend on ecj-bootstrap and runtime ecj-bootstrap.
<wasabi> I think it's missing a runtime depend.
<infinity> wasabi : No, the runtime dep is there.  It's just versioned too high to be useful right now.
<infinity> wasabi : S'what I said up there.  <point>
<wasabi> that's odd how my apt-cache showsrc doesn't show that
<mpt> mdz: In other news, I'd really really like to be contributing to fix the Ubuntu Help content (you were in the CC of a message I sent about it earlier), but *nobody* in the docteam can give me a step-by-step guide to how to modify the table of contents etc, other than pointing to scrollkeeper which seems to have almost zero documentation itself ... Who can I ask about that?
<infinity> wasabi : It'll sort itself when our poor wayward ecj-bootstrap binary finds its way to the archive.
<wasabi> Okay, just tear the version off.
<infinity> wasabi : showsrc doesn't show binaries. :)
<infinity> wasabi : Try just "show"
<wasabi> err. duh. ;)
<wasabi> Yes. Strip the versioned depend off.
<infinity> wasabi : But we need the new bootstrap anyway, according to doko...
<infinity> wasabi : So we may as well just fix that.
<infinity> (Or do we really?)
<wasabi> i dont' even remembe rwhat it fixed.
<wasabi> this is killing my brain
<lifeless> Kamion: for your scrollback edification, base-config is now pending a pysvn patch which I'm sending doko & elmo now
<wasabi> It doesn't. We don't really need it.
<mdz> mpt: there are practical problems with that UI, such as the fact that it involves modifying a huge number of applications, and some applications don't even have a help menu
<mdz> mpt: but it's what he wants at this point
<mdz> mpt: if you have already thought about it along those lines, feel free to update the spec accordingly
<lifeless> mdz: re baz COTM in hoary ...
<mpt> ok
<wasabi> ecj-bootstrap was updated to correct a build failure (because of an update to gcj-4.0.1)
<wasabi> And it was also synched with debian.
<wasabi> The existing binary works.
<mdz> mpt: regarding documentation, I don't know any more about that than you do, I expect.  it'd be a yelp question, try seb128. he should be able to point you to someone who knows, if he doesn't
<mpt> ok, thanks for your time mdz
<lifeless> mdz: uhm, its your call really. as upstream I would advise against, because IMO there is a difference between 'latest stuff that is pipelining in ' and 'CRACKOFTHEMOMENT"
<infinity> wasabi : Okay.  Then we have a few source packages with needlessely inflated build-deps/deps.  antlr is also waiting on that version, I think.
<wasabi> Yeah, I believe doko did that on accedent.
<infinity> mdz : Any sign of progress on that binary?
<mdz> lifeless: can we get 'latest stuff that is pipelining in', then?  currently our only options are COTM and releases
<wasabi> Or maybe he didn't. I don't know. ;)
<lifeless> mdz: as we release monthly, I don't see how - 
<mdz> ecj-bootstrap_3.0.1-3_i386.changes
<mdz> ACCEPT
<mdz> ecj-bootstrap_3.0.1-3_all.deb
<mdz>   to pool/main/e/ecj-bootstrap/ecj-bootstrap_3.0.1-3_all.deb
<mdz> Accepting.
<mdz> Accepted 1 package set, 907 KB.
<lifeless> but I could drop someone a mail that '1.5~200506021435 looks unbroken'
<lifeless> for instane
<lifeless> bob2: is 1.4.1 uploaded to debian yet ?
<wasabi> infinity, looks like ecj-bootstrap just fixed itself. ;)
<lifeless> :)
<mdz> lifeless: er, monthly?
<wasabi> rebuild j-g-c
<mdz> lifeless: bazaar in breezy is 3 months old
<wasabi> Actually it should kick itself off shouldn't it?
<lifeless> mdz: yes, and is the release-before last
<mdz> lifeless: ok, then scratch my previous request, and "can we please track the latest releases in breezy?"
<lifeless> mdz: sure thing, love to.
<lifeless> mdz: fabbione said that they sync via debian
<infinity> wasabi : It'll kick off when ecj-bootstrap is actually installed.  katie lies a bit when it says it's moved files to pool/... It actually means it's mapped them and scheduled them to be moved on the next cron.daily.
<lifeless> mdz: but if you were to pull directly, that would reduce some latency
<mdz> lifeless: debian has the same old version
<wasabi> "daily"?
<lifeless> yes, thus my ping to bob2
<infinity> wasabi : A misnomer from Debian.  It's daily in Debian, every 15 mins (I think?) with Ubuntu.
<bob2> mdz: debian has 1.3.2, which was the latest until last week
<infinity> wasabi : But still called cron.daily, just cause.
<mdz> bob2: lifeless just said it was the release-before-last
<bob2> lifeless: not yet, doing it now
<lifeless> mdz: it is
<lifeless> 1.3.2 released a week after hoary
<lifeless> actually, 1.3 did.
<mdz> a week after hoary was 2 months ago
<mdz> <-- confused
<lifeless> was it that long ? crap
<infinity> mdz : Can you tell if cron.daily is running on jackass?  Apparently it was taking forever and a day to finish its runs yesterday (something about elmo adding a second CPU to the box which slowed it down immensely)
<lifeless> 'monthly' is a little loose.
<mdz> infinity: yes, it is running right now
<wasabi> around here 'monthly' could mean 'every other hour'
<infinity> wasabi : Now you're starting to catch on. :)
<mdz> wasabi: where 'daily' means 'twice per hour'? ;-)
<wasabi> 4 times it seems
<infinity> Don't take my word for it.  I don't have direct access to jackass and I have a horrible memory.  COuld be every 30 mins. :)
<daniels> mdz: should be able to, yes
<bob2> mdz: hoary has 1.2, debian has 1.3.2
<mdz> bob2: right, and breezy has 1.3.2
<bob2> right
<mdz> wasabi: twice, :03 and :33
<mdz> infinity: ecj-bootstrap installed
<mdz> cron.daily looks to have finished
<infinity> Yup.  Everything's back on track.
<infinity> Huzzah.
<infinity> wasabi : Kicking back ant now.
* wasabi prays
<wasabi> I think what really caused all this problem is every package involved got updated, all at the same time. ;)
<wasabi> And they all broke in some way
<wasabi> And then got moved to main.
<wasabi> Not in that order.
* infinity hopes that ant and antlr succeeding will be enough to trickle down and magically fix the whole chain.
<infinity> wasabi : antlr doesn't need the new ant, does it?  (Please say no, cause they just started building in the other order)
<Amaranth> I think you guys are tackling more in the 6 months for breezy then red hat did for fedora core 4. :P
<wasabi> hmmm.
<wasabi> Shouldn't. ;)
<infinity> Good.  Looks like it was successful.
<wasabi> I can't wait to see Eclipse build. ;)
<wasabi> Oh, can you kick eclipse?
<wasabi> It's dep waiting on j2sdk1.3
<infinity> wasabi : Do you have a list of packages waiting to be untangled?
<infinity> (other than eclipse, which I'll smack around right now)
<wasabi> No, I don't.
<wasabi> I think we're pretty good off now.
<calc> how is gnome 2.11 coming along, i noticed 2.11.3 should be out next week
* calc also notices there is no webpage other than on live.gnome.org about 2.11 eg gnome.org/start/2.11/ doesn't exist
<calc> and no source tarballs for any 2.11
<wasabi> frick. i seem to have an unsolvable mess here on my hands.
<wasabi> I am confident if I exit X it won't launch again. ;)
<calc> yea X has been broken in various ways under hoary for several weeks
<wasabi> breezy.
<wasabi> X hasn't been broken in hoary has it? heh
<calc> erm yea oops ;)
<wasabi> ok, phew.
* calc can't remember what he is running :)
<dooglus> I discovered today that 'grep' is broken in hoary
<mdz> infinity: I want libant1.6-java, junit, libjaxp1.2-java and xerces-j
<dooglus> is there any way to get it fixed officially?
<mdz> dooglus: those are both pretty vague
<infinity> dooglus : Define "broken"?
<calc> from what i can tell the only two install bugs left are the xkbcomp and libxt issue
<dooglus> infinity: it uses all available CPU for as long as you let it in some cases.  it crashed my laptop 3 times today due to overheating.
<dooglus> infinity: try this:
<dooglus> yes | head -1000000 | LC_ALL=C grep . > /dev/null
<wasabi> uh.
<dooglus> it should run pretty quickly, right?
<wasabi> no.
<wasabi> yes never exits dude.
<dooglus> wasabi: it does when the 'head' tells it to
<infinity> dooglus : That's run a very fast infinite loop.
<wasabi> head doens't tell it to.
<wasabi> why would it?
<wasabi> yes outputs forever.
<Amaranth> whoa, why did no one tell me Alt+arrow reorders tabs in xchat?
<wasabi> head buffers, waiting for the last 100000 lines
<dooglus> head exits, which means the 'yes' gets a sigpipe
<wasabi> which of course never get there, as yes never stops
<dooglus> but that's not the point
<wasabi> when does head exit?
<dooglus> head -1 exits after printing one line...
<wasabi> print  the first N lines instead of the first 10; with the lead
<wasabi>               ing -, print all but the last N lines of each file
<dooglus> try it:  "yes | head -3"
<dooglus> you'll see, it's not an infinite loop
<Amaranth> wasabi: it doesn't infinite loop, i've tried it
<infinity> wasabi : Erm, yeah.  It does get a sigpipe.  Duh.
<wasabi> oh...
<wasabi> heh. ;)
<infinity> Anyhow.
<dooglus> so anyway...  of these 2 commands, the first works, very quickly, and the 2nd hangs, almost forever, eating all available CPU:
<dooglus> yes | head -1000000 | LC_ALL=C grep . > /dev/null    <- OK
<dooglus> yes | head -1000000 | LC_ALL=en_US.UTF-8 grep . > /dev/null   <- bad
<dooglus> can you reproduce that on breezy too?
<Amaranth> dooglus: so you've figured it out more?
<Amaranth> nice
<wasabi> java is eatting my mind
<wasabi> for some reason i can't comprehend that right now
<dooglus> Amaranth: it's a very old bug.  It just didn't get fixed in ubuntu as far as I can tell
<calc> wasabi: switch to mono?
<infinity> dooglus : grep in UTF8 has always been slow as a dog, no?
<Amaranth> using C took 0.5 real time, using en_US.UTF-8 took..well, it's still running
<Amaranth> infinity: Either other distros cheat and set C or this got fixed somewhere.
<mdz> dooglus: "grep is slow with UTF-8 locales" is not the same as "grep is broken"
<dooglus> infinity: yes, but that's not the problem here either - the problem is that due to a bug in the grep code, the algorithm takes a time propertional to the *square* of the size of the input file.
<mdz> at any rate, there's already a bug open about the performance issue
<calc> istr something about locales and something being slow before ;)
<dooglus> mdz: but it's stupidly slow - grep should be take linear time
<dooglus> that's what's broken about it.
<Amaranth> wow, en_US.UTF-8 is still running
<calc> of course that isn't very helpful, i recall redhat had some performance issues when they switched to using utf8
<dooglus> Amaranth: it will run all year if you let it
<Amaranth> red hat fixed them somehow
<dooglus> I think I have a one line workaround.
<Amaranth> as long as it doesn't cheat and set LC_ALL to C that's good
<mdz> dooglus: https://bugzilla.ubuntu.com/show_bug.cgi?id=1148
<dooglus> the problem at the moment is that for every match of every character, grep looks through the whole rest of the file to see which characters are multi-byte.
<dooglus> that's where the O(n squared) comes from.
<mdz> if you have further analysis that's not in that bug, please add comments there
<mdz> infinity: yes, it's a very old problem
<dooglus> mdz: that bug is badly out of date
<infinity> dooglus : Please update it, then.
<Amaranth> dooglus: congrats on figuring this out, was driving me nuts trying to understand it
<dooglus> infinity: could I ask you though - how is this _supposed_ to work?
<dooglus> it's a GNU application, but you get it from debian, and you also hack on it yourself.
<dooglus> and the redhat are hacking on it too - how do it all work - or how _should_ it all work?
<infinity> dooglus : We can fix it in breezy, push the changed to Debian, and the Debian maintainer will push the changes upstream.  If anyone in that chain decides the changes suck, we'll just carry them ourselves.
<dooglus> the fedora guys fixed it ages ago (see patch, here: http://cvs.fedora.redhat.com/viewcvs/devel/grep/grep-2.5.1-egf-speedup.patch )
<infinity> dooglus : Alternately, report the bug (and fix) to GNU, and we'll get the changes trickled down eventually.
<dooglus> redhat released an advisory about it, over a year ago.  but nothing happened to the GNU code
<infinity> dooglus : Odds are that RedHat would have pushed their changes upstream already, so there's a fair chance the GNU maintainer decided it wasn't elegant/correct enough.  That wouldn't necessarily stop us from carrying the patch, if it seems to work well enough and not cause regressions elsewhere.
<dooglus> infinity: that's what I don't understand - the GNU guys have been sitting on the bug for over a year too, doing nothing - same as the ubuntu guys.
<dooglus> here's the GNU bug: http://savannah.gnu.org/patch/?func=detailitem&item_id=3803
<dooglus> as far as I can see there's no comment from the GNU people at all
<dooglus> oh, my bad.  that's March this year - so they've only sat on it for 3 months.
<dooglus> Amaranth: did your grep finish yet?
<Amaranth> dooglus: I quit it.
<dooglus> is there anything useful I can do to help with breezy?  I've got a lot of debugging experience and nothing better to do with my time...
<wasabi> irssi. =/
<wasabi> Did it all get in?
<schweeb> dooglus: you could join #ubuntu-motu and help out w/ universe
<schweeb> dooglus: fix pkgs w/ build errors, etc...
<Amaranth> dooglus: filing bug reports is important
<dooglus> Amaranth: I'm a little disillusioned about that.  Last week I filed 3 and all 3 were shouted down, even though they were valid.  Now I see this massive problem with grep sitting in a bug report not being fixed...
<Amaranth> links to the 3?
<infinity> wasabi : Depends on what "it" was. I saw nothing from you before you dropped.
<wasabi> "it all" = "java"
<infinity> wasabi : Oh.  Still working on babysitting it.
<infinity> wasabi : ant and antlr are uploaded, waiting for them to hit the archive before another wave of stuff that depends on them can start.
<dooglus> Amaranth: they were all gentoo related.  Basically I was trying to install it by following the installation handbook, and filing documentation bugs whenever I found that the command they told me to type didn't work.
<jbailey> mdz: I've attached the patch to 11135 that I put into breezy.  I don't have a Hoary system handy that I can butcher atm, but I tested it when I wrote it.
<Amaranth> dooglus: oh, you're talking about another distro
<Amaranth> dooglus: MOTU loves getting bug reports ;)
<dooglus> Amaranth: yes, sorry.  I didn't make that clear.
<dooglus> what is MOTU?
<Amaranth> dooglus: It's about 20 guys managing 12000 packages, bugs tell them what to look at
<dooglus> master of the universe?
<Amaranth> yeah
<dooglus> heh
<schweeb> yep
<Amaranth> #ubuntu-motu
<wasabi> jbailey: don't suppose you heard a bout eclipse?
<jbailey> wasabi: Only your mention earlier that you uploaded a new version to multiverse.
<wasabi> gnome-panel needs to be rebuilt.
<wasabi> ... at least that it what I'm seeing
<wasabi> An actual corrupt .deb file?
<jbailey> Eh.  Because of eclipse?
<jbailey> Or did you context switch?
<wasabi> unrelated
<wasabi> context switch
<mdz> what about gnome-panel?
<wasabi> Hmm. Don't know if it's my fault or not... not sure how it could be.  dpkg-deb fails, subprocess killed by signal (Broken pipe)  --fsys-tarfile returned error exit status 2
* wasabi clears his apt cache
<mdz> infinity: ant meaning libant1.6-java?  (we do have an entirely separate source package called ant)
<wasabi> mdz libant1.6-java, the source package, is deprecated and should be removed.
<mdz> wasabi: ...
<mdz> I thought it was meant to supersede ant
<mdz> openoffice.org2 build-depends on libant1.6-java
<wasabi> No, exactly backwards.
<mdz> we had ant before we had libant1.6-java
<wasabi> source packages ant super ceeds source package libant1.6-java
<infinity> mdz : libant1.6-java is built from "ant"
<wasabi> source package ant produces BINARY package libant1.6-java
<mdz> infinity: yes, but libant1.6-java produces a libant1.6-java binary package which is newer
<wasabi> What? It does?
<infinity> wasabi : Is anything on your system NOT crashing?  (are you having hardware issues?)
<mdz> so currently, libant1.6-java builds libant1.6-java in breezy
<wasabi> not good.
<wasabi> shouldn't do that.
<wasabi> infinity: X issues.
<infinity> mdz : Erm, no, ant should be newer.. 1.6.2-2ubuntu3
<infinity> mdz : Though, only barely.
<mdz> hmm, did they swap again recently?
<wasabi> libant1.6-java needs to be removed. I don't know how that happened.
<mdz> I swear I recall someone (jbailey? doko?) telling me that we were intentionally superseding libant1.6-java with the libant1.6-java source package
<wasabi> that was me actually.
<wasabi> but that's not what I said
<wasabi> few months ago I think.
<mdz> yes, I see our conversation in March
<wasabi> Heck I think Hoary's copy works. ;)
<mdz> Mar 21 18:23:48 <mdz>   then once the dust settles, you can request removal of libant1.6-java
<wasabi> Dust never settled, haha.
<infinity> The dust must be settling right now?
<mdz> ...months pass...:-)
<wasabi> Yeah, this is the dust right here.
<mdz> well, if ant's libant1.6-java is newer now, we should be able to remove libant1.6-java source
<mdz> that's sufficient settling
<wasabi> It might not be newer, but it is "good enough".
<mdz> or did ant not build until just now?
<wasabi> We're going to have to maintain a fork of it until Debian adopts it.
<mdz> newer meaning "higher version number"
<wasabi> (sarge, blah blah blah)
<infinity> mdz ant just built and uploaded.
<infinity> Put a colon in there somewhere.
<wasabi> I was totally hoping to avoid that. ;)
<wasabi> They both come from the same upstream sources, so we can always just, upgrade to make it superceed properly.
<mdz> I've requested that libant1.6-java be removed
<mdz> then we can just continue tracking ant
<infinity> Oh, FFS.
<infinity> wasabi : ant needs a new upload.
<wasabi> It's main now. ;)
<wasabi> volunteers?
<bob2> lifeless: mdz http://crumbs.ertius.org/~rob/baz/
<wasabi> what's wrong with it?
<bob2> (in a few minutes)
<infinity> wasabi : 1.6.2-2ubuntu3 is a lower version than 1.6.2-2.1
<mdz> germinate seems to be choosing libant1.6-java's libant1.6-java over ant's libant1.6-java
<wasabi> Oh. Ya know. I sear back in the day I made an upgrade of libant1.6-java with a change log that clear said what was going on.
<wasabi> I guess that must have been the crack.
<mdz> infinity: isn't that what I was saying earlier?
<infinity> mdz : Yes, and I either can't read or... Can't read. :)
<wasabi> Debian made a NMU and that made it into Ubuntu.
* wasabi sigh.
<infinity> wasabi : So, we definitely want ant over the libant1.6-java?... So, I should just upload an identical ant package with a bunped version number? :)
<infinity> bumped, even.
<wasabi> Well, then you won't have merged the Debian changes.
<infinity> And then we need libant1.6-java blacklisted from autosyncs.
<infinity> wasabi : Well, if you want to merge the stuff from -2 -> -2.1, let me know. :)
<wasabi> I don't. Heck I can't right now. Can you upload a new copy, bumped version, to -2.1ubuntu0 or something silly.
<wasabi> Actually I guess it doesn't matter.
<wasabi> ubuntu1
<infinity> wasabi : The NMU was a 3-line patch.  I can pull it into our ant package, if that's desireable.
<wasabi> It is.
<wasabi> I need my GUI back.
<infinity> Alright, will do.
<emrysk> Mono is going to be in the Breezy base install, right?
<ajmitch> emrysk: yep, it most likely will be
<Amaranth> in main, don't think it'll be in desktop seed
<Amaranth> might not even be in ship seed, that cd is bulging
<ajmitch> Amaranth: depends if beagle or other apps get put in desktop seed
<jsgotangco> "if"
<Amaranth> smeg should be in desktop seed ;)
<ajmitch> Amaranth: if anyone ever uses it ;)
<jsgotangco> haha
<Amaranth> ajmitch: heh, i think i'm covered there
<ajmitch> probably
<Amaranth> typical #ubuntu converstation: "<foo> how do i edit my menus? <bar> use smeg"
<Amaranth> :D
<ajmitch> I don't know if system tools is the best place in the menu for it
<Amaranth> well, i wasn't too sure about that
<ajmitch> it can be moved 
<Amaranth> it made more sense when it had a root mode
<Amaranth> it still does, if you run it with --root
<infinity> mdz : Can we get libant1.6-java (the source package) blacklisted from syncs?  I've just uploaded the shiny new (correctly-versioned) ant right now.
<jbailey> w
<drbyte> ogra: ping
<drbyte> or actually, does anyone know where ogra keeps the code for his hardware database thing?
<ajmitch> grab the source package? I don't know if he has the code repository online
<drbyte> ajmitch: hmm, ok. what is it called? i dont actually have access to an ubuntu system atm (shock, horror)
<ajmitch> drbyte: hwdb-client
<drbyte> ajmitch: is there a hwdb-server too?
<ajmitch> not yet
<ajmitch> you'd have to ask him
<drbyte> http://packages.ubuntu.com/hoary/base/hwdb-client that's good. sweet
* jsgotangco dagger looks at drbyte
<jsgotangco> hehe
<drbyte> jsgotangco: dagger?
<jsgotangco> dagger = knife or something
<drbyte> you wanna knife me?
<drbyte> erps, why?
<jsgotangco> drbyte ajmitch: hmm, ok. what is it called? i dont actually have access to an ubuntu system atm (shock, horror)
<jsgotangco> hehe
<jsgotangco> just kidding
<drbyte> jsgotangco: hehe. right
<ajmitch> jsgotangco: remember he's still stuck with fedora
<jsgotangco> there's no rush
<drbyte> thanks ajmitch, jsgotangco 
<drbyte> gotta talk to ogra later i guess
<drbyte> or ogra, ping bytee if i'm not around. should be disconnecting soon
<jsgotangco> ok see ya
<dampjam> the i386 install: http, and torrent are corrupt on http://us.releases.ubuntu.com/releases/5.04/
<dampjam> the install fails on the bsdutils package
<dampjam> I am not sure where to report it
<jsgotangco> mako, ping?
<mako> jsgotangco: yes
<mako> was about to run to sleep.. but go ahead, you caugth me
<jsgotangco> oh i already sent it on email, i want to give it to the LugRadioLive guy but needs review as well
<jsgotangco> also had jdub on cc since this is Ubuntu@conferences stuff
<jsgotangco> brb
<fabbione> morning
<fabbione> daniels: you around?
<wasabi> dampjam: have you checked the md5 sums?
<mdz> infinity: I've already requested that it be removed entirely
<fabbione> morning mdz
<mdz> fabbione: morning
<dampjam> I have
<mdz> infinity: is the stack ready to move over into main?
<dampjam> I then downloaded the images from carroll.cac.psu.edu, they worked without a flaw
<mdz> infinity: ant junit xerces-j libjaxp1.2-java
<mdz> hmm, and classpath
<infinity> mdz : junit is building right now.  Checking on the others.
<wasabi> classpath isn't really neccassary when using gcj
<wasabi> Which we are doing.
<wasabi> gcj includes a complete native classpath compilation.
<Amaranth> nice
<Amaranth> so breezy is getting native eclipse in main?
<infinity> wasabi : xerces-j build-deps on classpath...
<wasabi> Among other things.
<wasabi> Does it?
<wasabi> It probably needs to be fixed then.
<Amaranth> rock
<wasabi> What is xerces-j for?
<Amaranth> mono in main, java things in main, this release is going to blow people away
<infinity> wasabi : Heckifiknow. :)
<Amaranth> it's an xml parser
<wasabi> I've never had my hands on it.
<wasabi> What depends on it?
<infinity> mdz : Your list all looks ready exceit for junit which has just been uploaded.
<Amaranth> libant1.5-java
<wasabi> That is deprecated.
<wasabi> mdz?
<mdz>    [Reverse-Build-Depends: libant1.6-java] 
<wasabi> Heh.
<wasabi> I suspect that's the old ant package?
<mdz> if ant doesn't use it, then we won't need it
<mdz> that's the libant1.6-java source package
<Amaranth> i'm looking at local stuff
<wasabi> Yeah, the last update this thing had, other than what you did to it recently, was in 2002.
<mdz> but ant uses it too
<wasabi> does it.
<mdz> oh, it uses xerces2
<mdz> from xerces2-j
<wasabi> yeah.
<wasabi> xerces-j i think was being dropped by Debian
<wasabi> I remember hearing something about it
<mdz> once everything is installed, I'll re-germinate and see how things look
<mdz> hopefully germinate will choose ant's libant1.6-java now, and things should be clearer
<wasabi> http://java.debian.net/    a wiki page MovingJavaToMain
* wasabi still at console.
<wasabi> X really is pretty screwed up isn't it. ;)
<Lathiat> heh
<mdz> bob2: how is the ~rob/baz/ stuff different from what's in breezy?
<mdz> wasabi: working OK for me
<mdz> I had to fix up that mouse business in xorg.conf a few days ago, but there have been updates since then and it's probably fixed
<mdz> wasabi: hmm, the picture is significantly more complex now
<mdz> and kaffe is back
<mdz> and jython
<wasabi> aheh.
<mdz> and xerces-j is still here
<wasabi> where'd they come from?
<Micksa> anyone care to help me out with a hoary PXE boot problem?
<Micksa> breezy is working fine but not hoary
<wasabi> mdz: the big X move is killing me.
<wasabi> Thing won't even start.
<mdz> http://people.ubuntu.com/~mdz/temp/java-main.txt
<mdz> that's the dependency chain leading back from openoffice.org2
<mdz> ant seems to pull in a *lot* more stuff than libant1.6-java was
<wasabi> Yeah, it does.
<mdz> jlex at least needs fixing
<wasabi> The old libant1.6-java was super minimal.
<mdz> and libbsf-java
<mdz> jlex pulls in kaffe, libbsf-java pulls in jython
<wasabi> what program are you using to generate this?
<mdz> anastacia
<wasabi> jython should be fine.
<mdz> it compares the current state of the archive to what germinate says it should be
<wasabi> What's it pull in?
<mdz> jython is way behind the times (python2.1); we don't want it
<wasabi> I remember these two.
<wasabi> Hmm.
<wasabi> bsf might require it.
<mdz> that would be most unfortunate
<wasabi> bsf is the bean scripting framework. It is a generic scripting framework for Java.
<mdz> someone was saying that jython was being updated for modern python
<wasabi> It includes a number of scripting engines, javascript (rhino), and jython
<wasabi> It might be disablable.
<wasabi> I remember being on this road before.
<mdz> why does javax-servletapi2.3 need bsf?
<wasabi> Hmmm. Not sure.
<mdz> that seems weird
<wasabi> Yeah it does.
<jblack> Is the netpbm / netpbm-free guy here, or somebody that knows a bit about those two packages? 
<mdz> I know a bit about them; best to just ask
<infinity> Indeed, ask away.
<jblack> Ok. We've already done an info file for "netpbm". Theres also a info file for "netpbm-free". There doesn't seem to be a netpbm-free package in ubuntu.
<jblack> (though there is a netpbm) 
<infinity> netpbm-free is the source package.
<jblack> It also has the same cvsroot and cvsmodule as netpbm. That means to me that its a duplicate. 
<infinity> The netpbm-free source package generates the netpbm binary package.,
<infinity> Is that the confusion? :)
<wasabi> Wait.
<wasabi> mdz, servlet2.3 doesn't depend on bsf that I can see.
<mdz> hmm, germinate doesn't usually lie about these things
<jblack> infinity: The confusion is that there's two info files that point to the same place. 
<mdz> I don't see it either
<infinity> jblack : Well, there hasn't been a "ntpbm" source package since 1998... So, "netpbm-free" is the canonical version.
<mdz> wasabi: oh, that's backwards
<mdz> wasabi: it's bsf that build-deps on servlet2.3
<wasabi> That makes sense.
<mdz> yes, much more so
<mdz> is free-java-sdk a sane thing?  I haven't seen it before
<jblack> infinity: ?? Isn't the canonical package in ubuntu is called netpbm ? 
<wasabi> free-java-sdk is some stupid thing that the Debian guys are into.
<wasabi> It's like java-gcj-compat, but it chooses a random JVM or something.
<infinity> jblack : Not the source package, no.  You do imports based on source package names, not binary, right?
<wasabi> Because they don't want to discriminate.
<mdz> infinity: yes
<wasabi> random build deps, uh huh.
<jblack> infinity: typically, we try to, yes. 
<infinity> jblack : apt-cache show netpbm, it's from the netpbm-free source.
<mdz> it seems to be committed to sablevm at the moment
<wasabi> oh?
<mdz> Depends: jikes-sablevm, fastjar, sablevm, classpath-tools
<wasabi> guess he won. ;)
<wasabi> Gadek (teh sable guy) is very loud spoken. Hehe.
<mdz> we currently have sablevm in main, though I don't recall why
<wasabi> I'd discard free-java-sdk actually.
<mdz> I think berkeley db or something build-deps on it
<wasabi> And discard sable, and fix bdb to build on gcj, in the long run.
<jblack> As it happens, I called it netpbm because ubuntu calls it netpbm, freshmeat calls it netpbm.
<mdz> yeah, db4.2 build-depends on sablevm
<infinity> jblack : Ubuntu calls the source package netpbm-free, though (same as Debian)
<mdz> sablevm AND gcj AND libgcj6-dev
<jblack> I notice at freshmeat.net there's a program called "netpbm-free" that is a CLI-interfaced image creation and manipulation program. is that what you're thinking. 
<wasabi> Well, I think our idea is that we'll have one "official supported JVM"
<wasabi> haha.
<wasabi> Yeah, tons of Debian packages do that.
<mdz> why?
<wasabi> They build Java pieces with one JVM.
<wasabi> Then build native versions with GCJ.
<infinity> jblack : The source package could be named back, since there's no netpbm-nonfree anymore, but I doubt anyone cares enough to do it. :)
<wasabi> The GCJ compiler traditionally SUCKS.
<wasabi> It's not really usable for much.
<jblack> also, sourceforge calls it netpbm, and the homepage calls it netpbm too. 
<wasabi> But we're using ECJ, which is supurb.
<jblack> even the cvs module is netpbm.
<mdz> jblack: it's always been netpbm upstream
<mdz> jblack: but in Debian it was split into netpbm-free and netpbm-nonfree
<infinity> jblack : Yes, it /IS/ netpbm.  Our source package was just split back in 1998 to -free and -nonfree, because of GIF patents.
<wasabi> Free Java is marred from years of having 10 VMs all at various levels of completion.
<fabbione> that are actually expired btw
<wasabi> Debian of course hilights that because all 10 VM developers are d-d's
<infinity> jblack : They were reintegrated in 2004 (when the patent expired), but the source package is still called -free, for hysterical raisins (or sheer laziness of people who didn't want to push a new source through queue/NEW)
<jblack> *click*. Ok. importd isn't going to be able to handle netpbm-free for you guys, because right now its dependant upon a different source for every product. 
<mdz> jblack: hmm?  it should be fine, there is now a 1:1 correspondence between the netpbm-free source package and the netpbm product
<wasabi> The kaffe fans always build with kaffe, the sable guys always use sable. A few people enjoy gcj. Some people use JamVM now too.
<mdz> fun
<wasabi> Each of those VMs include their own copy of classpath.
<wasabi> So, then you have the Classpath + VM guys.
<infinity> jblack : There is no netpbm source package at all, so as mdz says, there's a 1:1 mapping.
<jblack> mdz: its there as "netpbm" as the upstream name (we're supposed to use upstream names) 
<wasabi> Who pick a VM, and build with the VM against the classpath package instead of hte included one.
<wasabi> It's a real big mess. ;)
<jblack> Oh, I getcha. You guys'll branch it. 
<mdz> jblack: at this point, now that netpbm-nonfree is gone, it's simply a matter of the source package being named differently from upstream
<mdz> nothing more insidious than that
<jblack> I'll drop lifeless an email letting him know that you'd like it renamed. 
<mdz> like what renamed?
<mdz> wasabi: what do we do about classpath?
<jblack> Never mind. 
<wasabi> We ignore it.
<wasabi> And remove it from our deps.
<jblack> Thanks for the time guys
<wasabi> The plan is to support one official VM. At this point it's GCJ.
<mdz> and gcj includes its own copy of classpath?
<wasabi> Yes.
<mdz> ok, so in that case we also have the issue that libgnujaf-java and libjaxp1.2-java depend on classpath
<wasabi> So, all these uploads of Java crud I was doing a few months ago, basically I was just converting packages to gcj.
<mdz> and there are still more
<wasabi> Apparently.
<wasabi> I didn't have the cool tool you're using. ;)
<mdz> we ought to publish its output someplace regularly, if we don't already
<wasabi> I shall quickly patch up those two.
<mdz> are the other packages in that list sane already?
<mdz> if you could spend a little time writing a short howto for doing java packages the right way in Ubuntu, we could distribute this workload a bit
<mdz> or does something like that already exist?
<wasabi> Not really.
<wasabi> The problem is Java itself has no such howto.
<wasabi> C comes in autoconf, or a makefile.
<wasabi> Java comes in ... sometimes ant.
<wasabi> Free java more than not comes in a hacked together custom weird thing. ;0
<wasabi> We need a comprehensive policy, really.
<wasabi> Lots of ideas floating around, but few are written down.
<mdz> I mean along the lines of what you just told me
<mdz> use this compiler, this JVM, which packages to depend and build-depend on
<wasabi> Debian suffers from the same problem really. Just not many Java hackers.
<mdz> we have even fewer, I'm sure
<wasabi> JavaPackagingProcess maybe
<mdz> but given a clear direction to go in, we have quite a few people who are interested in getting packages into line with policy so that everything fits together nicely
<wasabi> I never updated that hting. =/
<mdz> of course, they have their hands mostly full with the C++ transition at the moment
<mdz> JavaPackagingProgress?
<mdz> I don't see a ...Process
<mdz> yeah, Progress has a bit of the right stuff
<wasabi> jeff had a page before, trying to find it
<wasabi> JavaIntegration. Out of date.
<Micksa> pfff, #ubuntu is no help
<Micksa> okay, I have a new laptop which won't run my existing install
<Micksa> and I don't wanna reinstall
<Micksa> I've narrowed it down to modules that need to be loaded in the initrd
<Micksa> I just gotta figure out which ones :)
<wasabi> only ones that should matter are the ones for hte storage device, right?
<Micksa> yeah. and loading other modules from the fs, but I think that's probably covered :)
<Micksa> that's what's broken incidentally. the existing kernel isn't detecting the hdd.
<wasabi> brb hope i got x fixed
<Micksa> who is working on eclipse? how is it going?
<infinity> wasabi : Better?
<wasabi> thank goodness
<wasabi> yeah.
<wasabi> reinstalled all of X from hoary.
<wasabi> There has got to be an easier way to figure out what consitutes "all of X"
<Micksa> haha
<infinity> As it becomes more modular, it'll be harder, not easier (but that's what dependencies are for)
<Micksa> "dpkg -l"gre[ ^x" 8)
<Micksa> er
<Micksa> "dpkg -l|grep ^x" 8)
<wasabi> I guess having a program that you can say "give me all of xserver-xorg" and it would spit out it's complete dependency chain
<wasabi> that might help
<Micksa> er, or even...
<Micksa> oh, forget it
<Micksa> depends on what you mean by "X" :)
<wasabi> mdz uploaded a fixed libgnujaf. What was the other one?
<infinity> <mdz> ok, so in that case we also have the issue that libgnujaf-java and libjaxp1.2-java depend on
<infinity>           classpath
<lifeless> hi 
<lifeless> I've found a bug in tk8.3
<lifeless> causes a broken build of gnu-smalltalk-2.1.x
<lifeless> whats the best way to get that fixed for breezy, and is there any point in doing a fix for hoary? (I'd like to get a fixed gnu-smalltalk in hoary-universe if possible)
<infinity> lifeless : File a bug, with a patch if you have one.
<lifeless> infinity: haven't found the cause...
<lifeless> but the vuild tkConfig.sh (/usr/lib/tk8.3/tkConfig.sh) has a CINCLUDE path it offers of '# no special path is needed'
<lifeless> ^^ WTF CRACK^^
<wasabi> Those two packages were uploaded. I'm going to bed now.
<Micksa> does init= get ignored by initrd or something?
<Mithrandir> init is done post-initrd
<Micksa> what if I want a shell inside initrd?
<Mithrandir> then you should set DELAY to something in mkinitrd.conf and press enter
<Micksa> kay
* Micksa wonders how much luck he'll have in there
<Micksa> how do I get the intstaller to do the initrd modprobe detection, without doing a complete install?
<Micksa> dammit, lsmod would be handy :)
<Micksa> how do you continue booting after the shell?
<lifeless> Micksa: these are more #ubuntu style questions
<Micksa> aw geez
<Micksa> I end up having to jump between here and there cos noone on there seems to know this stuff
<crimsun> this is a devel channel, please keep support questions in there :)
<lifeless> Micksa: if you are offering a ptch, or figuring out how to patch it, its on topic here ;)
<lifeless> if you are essentially just using it ...
<lifeless> bugs in main : are they still bugzilla ?
<Micksa> okay, I got one :)
<Mithrandir> lifeless: yes
<Micksa> I'm looking at the initrd scripts and by the look of it there IS no clean way to continue boot after the initrd shell
<Micksa> cos it gets exec'd, and in the middle of /linuxrc, which seems to do half the work
<Mithrandir> Micksa: then you do the rest of the stuff that /linuxrc does and execs /sbin/init from there.  Or you fix the problem, then reboot.
<daniels> fabbione: pong
<fabbione> daniels: what's the status with xorg -21?
<fabbione> broken xbase-clients is causing FTBFS in the buildd
<daniels> fabbione: within the next 24h, hopefully
<fabbione> daniels: ok
<lifeless> infinity: could you read https://bugzilla.ubuntu.com/show_bug.cgi?id=11444 and tell me if I've made sense ?
<lifeless> daniels: did X at any point tell apps that its include path should be '# no special path needed' ?
<daniels> lifeless: no.
<lifeless> daniels: ah well, not that source then ;)
<daniels> lifeless: best practice has been #include <X11/foo.h> (or <X11/extensions/foo.h, or ...) forever, and most apps are supposed to have been using -I/usr/X11R6/include since R6 (about ten years ago)
<lifeless> heh
<lifeless> tk8.3 has a spethial config value
<lifeless> see https://bugzilla.ubuntu.com/show_bug.cgi?id=11444
<lifeless> aw f*ckage
<lifeless> malone hates me
<infinity> lifeless : That's a pretty... Sparse bug report. :)
<lifeless> so I can't file the bug on gnu-smalltalk
<infinity> lifeless : What does that break, and how?
<lifeless> infinity: everything that builds against tk8.3 in the officially proscribed manner
<lifeless> infinity: such as the gnu-smalltalk blox environment
<infinity> Does it cause them to FTBFS, or produce broken binaries?
<lifeless> depends on the package
<Treenaks> yay for braindead upstream?
<lifeless> packages that /require/ tk will FTBFS
<lifeless> packages that have optional features will have those features silently disappear thanks to autoconf being nice
<lifeless> the latter is what lead me down this path
<infinity> lifeless : Alright, find one of those and link up the build log, svp.  Then someone might be able to make sense of why it's a bug. :)
<infinity> ("one of those" meaning "one that's FTBFS")
<lifeless> infinity: uh
<lifeless> why ?
<infinity> Alternately, point us at a broken binary.  I don't care.  Either.
<lifeless> try this : export CFLAGS="# this is not valid"
<lifeless> then build *anything*
<lifeless> it. wont. build.
<infinity> Okay, fair enough.  But I wasn't aware until just now that packages actually use tkBuild.sh to produce CFLAGS lines.
<lifeless> I've rebuilt tk locally via debuild, it generates a good tkConfig.sh file
<lifeless> so I can't give a source package patch.
<infinity> Keen.  And it almost certainly would have in the past as well.
<lifeless> I have to presume that tk's configure script went haywire and build crud, and thats had a knock on effect once it landed in the archive
<infinity> Alright, let me poke at it.
<lifeless> what I think is the right thing is a simple rebuild of tk on all platforms with broken file, and then a rebuild of anything that people report bugs on.
<lifeless> i.e. I'd like to have gnu-smalltalk rebuilt, as I know its broken - thats how I got into this path.
<infinity> it's right there in unix/tcl.m4.... Curious.
<daniels> lifeless: no-one uses smalltalk anyway
<lifeless> daniels: pfft
* Lathiat grins
<Mithrandir> infinity: tcl.m4 makes modern automakes cry.  Loudly.
<lifeless> infinity: fuxked upstream then... thats NOT a valid path for XINCLUDES
<lifeless> infinity: right, line 1769
<infinity> Mithrandir : I'm not surprised.  Have you read it recently?... It's making me cry.
<lifeless> infinity: I can give a patch to set that to "" rather than "# no special path needed"
<Mithrandir> infinity: no, I try to get rid of it from my system when I can.
<Mithrandir> s/infinity/lifeless/
<infinity> lifeless : The problem is a bit deeper than that.  Have you read tcl.m4?
<lifeless> infinity: read the related bit just now
<Mithrandir> lifeless: the day I could purge my system of tcl would be a very happy day.
<lifeless> well, gnu-smalltalk 2.1.10 has gtk support
<infinity> lifeless : It's a fundamental difference between what tcl.m4 thinks that variable will be used for and what it actually IS used for, AFAICT.
<lifeless> which I'm about to enable in the package, so yay. but 2.1.8 is whats in hoary
<lifeless> google tells me that it is meant to be a -I line
<lifeless> and meant to be a valid one
<infinity> It is in tkConfig.sh, yes.
<infinity> (is meant to be, that is)
<lifeless> tkConfig.sh.in is where tkConfig comes from
<lifeless> I think this is a fallow bug and that tk was built with X headers in /usr/include or a pre-set CFLAGS or some such
<lifeless> and we've simply finally exposed it
<lifeless> would you like a patch to correct tcl.m4
<infinity> Yeah, I see what they were trying to do.
<infinity> And why they're retarded.
<lifeless> lol
<daniels> i'm all about exposing crappy code that used to work
<infinity> I assume someone was hoping for the script to come out looking like:
<infinity> TK_XINCLUDES='' # no special path needed
<infinity> But just wasn't really paying attention to reality.
* Mithrandir hoorays for ChangeLog,v revision 1.100 in pkg-config cvs.
<daniels> Mithrandir: i thought it was all called 'pkgconfig' these days
<Mithrandir> daniels: nah, I'm moving it all to pkg-config from pkgconfig
<lifeless> ok, I have patch
<infinity> lifeless : Just changing it to a blank variable if it = "nope", I assume?
<lifeless> and init to nothing
<lifeless> theres about 4 places to change
<infinity> Or, not "nope", but empty.  Whatever. :)
<infinity> I only see two to change.
<infinity> The "nope" instance should stay.  It's breakage if there are NO X includes found at all.
<lifeless> uyhm
<lifeless> no, AC_MSG_RESULT is the feedback for that
<lifeless> if its meant to be a failure, that would be AC_MSG_FAIL
<lifeless> well, either way
<lifeless> the important bit is the two lines.
<infinity> Oh, it should fail.  Sure.  And tcl.m4 should be completely rewritten too.  I'm not going to fix either. :)
<infinity> But I'll fix the obvious breakage.
<lifeless> ok.
<infinity> Then I'll cheat and patch configure, cause i really don't want to see what an autoconf run will do to this.
* lifeless discards his patch
<lifeless> so the million dollar question .. will this rebuild get done for hoary ?
<lifeless> as an update ?
<infinity> Oh, nevermind.  I wouldn't be the first to rerun autoconf on this source recently.
<infinity> Guess I won't cheat.
<infinity> How many packages in hoary did it affect that would also need to be rebuilt?
<infinity> You might want to put such a list together, and slap that into the bug report.
<infinity> I'll fix it in breezy, though.
<jdub> GOOOOOOOD MORNING FREEDOM LOVERS
<Treenaks> hi jdub 
<Mithrandir> what's scary is jdub is actually saying that approximately 90 minutes after I've gotten up, for the last week.
<Mithrandir> and he's been travelling around half the world.
<lifeless> whats the reverse-depends tool ?
<fabbione> hey jdub 
<infinity> lifeless : apt-cache rdepends <package>
<Treenaks> Mithrandir: IRC scripting for fun & profit
<lifeless> apt-cache rdepends tk8.3
<lifeless> there you go.
<Mithrandir> Treenaks: I doubt it, since he says stuff afterwards which is jdub-responses to stuff people say to him.
<fabbione>   * Add support for KPKG_ARCH override required for powerpc64 kernels.
<Treenaks> Mithrandir: scary
<fabbione> ok.. now..
<fabbione> who will pay beer for it? :)
<Mithrandir> fabbione: svenl will?
<Treenaks> fabbione: come & get it ;)
<pitti> morning
<pitti> fabbione: so you'll upload rhcluster to universe first?
<fabbione> pitti: no.. it can't be uploaded to universe first...
<fabbione> germinate will pull in automatically in main
<fabbione> due to the b-d for lvm2
<fabbione> so it doesn't not matter where i upload
<fabbione> it will be sucked in main automatically
<fabbione> at least the source
<fabbione> and libdlm-dev libdlm1
<fabbione> the others will land in universe and it's fine for me
<jdub> heh
<jdub> nutballs :)
<fabbione> pitti: in any case it won't happen before the end of next week
<fabbione> pitti: some init scripts are missing.. even upstream :)
<pitti> fabbione: ah, ok. Well, I'm not in a hurry with it
<fabbione> neither am i
<fabbione> it's a quite delicate package to install all together
<fabbione> since it affects the boot process in an early stage
<fabbione> and there are some services startup order that still needs to be evaluated
<lifeless>  |blt
* pitti enjoys reading dholbach's enthusiastic MOTU reports :-)
<jsgotangco> hehe yeah
<jsgotangco> mvo, hi
<pitti> Hi carlos
<carlos> morning
<mvo> hey jsgotangco, morning all
<pitti> Riddell: here?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<doko> mvo: ping
<mvo> doko: pong
<jdub> shit, anyone read polish?
<jsgotangco> dzien dobry
<jsgotangco> hehe
<jsgotangco> opi is polish but he's nowhere now
<jsgotangco> chmj, hey how's it going
<robitaille> jdub,  #ubuntu-pl  (not sure if anyone is there...)
<pitti> Hey seb128 
<seb128> hey pitti!
<seb128> how are you? 
<robitaille> jdub,  forget about #ubuntu-pl...it's empty (http://www.ubuntulinux.org/wiki/LoCoTeamList is out of date...)
<pitti> hey second seb
<seb128_> hey hey pitti :)
<seb128_> I just have my daily IP change at 10:15 now, grrrr
<pitti> seb128_: you can't change that time?
<seb128_> I can, I just forget to reconnect before going to bed
<pitti> reconnecting at 4 am should be a good time...
<seb128_> yep, but I'm not awake at this hour
<pitti> seb128_: right, that's why it is a good time :-)
<seb128_> bah, I'm not the only one
<pitti> Hi vuntz_ 
<seb128_> hey vuntz_ vuntz :)
<vuntz_> hi all
<pitti> daniels: do you know about the repetitive postinst failure of xbase-clients because of some xkbcomp weirdness?
<vuntz_> pitti: isn't it the "yes, xbase-clients is broken.  no, it's not fixed yet." part of the topic?
<pitti> oops, right
<pitti> sorry
<vuntz_> :-)
<doko> ogra: ping
<doko> pitti: fabbione did give him a deadline ... ;-)
<fabbione> doko: no i didn't :)
<fabbione> but i am sure he will love to update asap, before strange things will happen to his house :P
<pitti> fabbione: like a 20 meters high solid metal "X" falling on his roof?
<fabbione> pitti: ahahha
<doko> we should sponsor an ad in a local newspaper: free beer at daniels until X is fixed ;-)
<Treenaks> :D
* Treenaks books a plane to Aussieland
<jdub> whoa, libmono in main
* jdub is doing a massive mirror sync
<jsgotangco> JaneW, hi
<jk24> Hi, i think there is a problem with xfonts-base : when it install it does a /usr/X11R6/bin/mkfontscale (i don't know where in the postinstall) but xutils install mkfontscale on /usr/bin, then after a dist-upgrade, Xorg cannot found the fixed font
<jdub> jk24: see topic :)
<jk24> jdub, not xbase-clients, xfont-base !
<jk24> :)
<pitti> seb128: I now have a prototype that dumps a /tmp/crashrep.<program>.<time>.txt with a crash report after a sigsegv/sigill/sigfpe
<seb128> pitti: rock
<seb128> pitti: is that public somewhere?
<vuntz> pitti: will this replace bug-buddy or is it only for non-gnome programs?
<pitti> seb128: I package it soon
<pitti> vuntz: depends, this is still to be decided, I guess
<vuntz> poor seb128... you will now have to handle all the GNOME crashes of ubuntu users...
<vuntz> bugzilla really has a scaling problem
<Kamion> s/scaling //
<Kamion> actually s/has/is/
<Mithrandir> Kamion: don't be mean to bugzille. :P
<Kamion> aww
<Mithrandir> uhm, s/lle/lla/
<pitti> vuntz: believe it or not, but seb128 bugged me to write this stuff :-)
<pitti> s/bugged/asked kindly/ :-)
<seb128> vuntz: what I want is automatic debug backtrace, because replying to 80% of the bug to say "install package1-dbg package2-dbg, read the debug page and send a debug backtrace" is not really funny
<vuntz> seb128: nod
<pitti> seb128: right now the package does not fetch any debug information from the net (well, there is none so far)
<pitti> seb128: once there is, I can enhance it to do so
<seb128> rock
<Riddell> pitti: hi
<pitti> Hi Riddell
<vuntz> pitti: great!
<pitti> Riddell: I wanted to ask you something about KDE langpacks
<pitti> Riddell: in the spec it was decided to split up the langpacks into -gnome, -kde, and -other
<Riddell> yep
<pitti> Riddell: so what should we do about kde-i18n-foo?
<pitti> Riddell: treat them specially and make them a dependency of l-p-kde-<lang>?
<pitti> Riddell: or just strip them normally and integrate the translations into the kde langpack?
<pitti> Riddell: the latter has the nasty effect that we have a bunch of empty kde-i18n debs around
<pitti> although, we don't 
<pitti> Riddell: kde-i18n also contains translated doc and help, right?
<Riddell> pitti: they do
<Riddell> pitti: if they weren't stripped they couldn't contain files from rosetta
<pitti> Riddell: yes, I would like to strip them, too
<pitti> Riddell: so that we only need to update the langpacks, not the kde-i19n packages after a release
<pitti> erm, ECOUNT
<Riddell> :)
<Riddell> pitti: how would the langpacks be updated without updating kde-i18n since that's where the updates would come from
<pitti> Riddell: I meant updates from Rosetta
<Riddell> pitti: but no updates from kde?
<pitti> Riddell: the upstream updates are imported into Rosetta automatically throught the stripping and import processs
<Riddell> pitti: but that process is only when a new package is uploaded?
<pitti> Riddell: yes, right
<pitti> Riddell: well, for Gnome I had a special script that pulled new translations from gnome cvs and put it into the langpacks
<pitti> Riddell: if we need sth similar for KDE, this can be done, I think
<Riddell> pitti: that sounds not too difficult
<Riddell> pitti: what happens with all the other gnome programmes?  if gnome 2.10.x comes out does ubuntu get the updates language packs from that?
<pitti> Riddell: if I crank up my script, we can do that
<pitti> however, not automatically
<pitti> unless the Rosetta guys (hi carlos) want to integrate this script into Rosetta proper
<carlos> pitti, we will integrate a way to get translations from upstream after an Ubuntu release, but we don't have an dates yet
<pitti> oh, cool
<pitti> seb128: http://people.ubuntu.com/~pitti/crashrep/ , testers appreciated
<seb128> thanks
<Treenaks> pitti: whazzit?
<pitti> seb128: basically, just install the two debs, and every newly started app should then generate a report
<pitti> (when it crashes, that is)
<seb128> should I drop bug-buddy?
<Treenaks> pitti: ooh.. will it ask if I want to submit that? :)
<pitti> seb128: I'm still testing the b-b interaction and if it is bad, then I add a conflict
<pitti> Treenaks: there is code, but I disabled it for now
<pitti> Treenaks: I set up a preliminary server on http://debcrash.piware.de
<pitti> Treenaks: it already has some test reports, but we need to spec this out
<pitti> Treenaks: for now you'll only get a flat file in /tmp
<jdub> pitti: couldn't we integrate the two?
<pitti> jdub: two?
<pitti> ah, b-b and crashrep
<jdub> b-b and crashrep
<seb128> use bug-buddy as the UI
<pitti> seb128: but b-b is ugly for beginners...
<seb128> what is so ugly with it?
<pitti> anyway, we should talk about the gui once the report system is stable
<pitti> right now it isn't
<pitti> it fails to generate stack traces sometimes
<Treenaks> pitti: where does it get the symbols?
<pitti> and we should have debug symbols before we actually throw this at people
<pitti> Treenaks: right now it can't
<pitti> Treenaks: later, from debug.ubuntu.com or so
<Treenaks> coolness!
<pitti> Treenaks: we want to strip the symbols on the buildds and put them there
<Treenaks> pitti: yeah, I heard something like that
<pitti> seb128: the main problem is that b-b is restricted to desktop applications, doesn't work with servers and for text mode
<Treenaks> pitti: how about reportbug then?
<pitti> seb128: and we have to modify it heavily to work with our db instead of submitting to gnome
<pitti> seb128: I think modifying it is possible
<seb128> for my part of the issue, which is "stop flooding us and upstream with zillion of useless bugs" that's fine
<pitti> seb128: but crafting an easy pygtk interface should be easier
<pitti> seb128: the code already has a small pygtk gui
<seb128> you want to send all the crasher to bugzilla.ubuntu?
<pitti> no
<seb128> do you have an idea of the number of crashers/week send by ubuntu users? :)
<pitti> seb128: they should becollected in something like http://debcrash.piware.de (that actually works right now!)
<pitti> seb128: nope
<seb128> nautilus get about 7-8 ubuntu crasher/days
<seb128> and that's one module
<pitti> seb128: if you uncomment the commented code in debcrash's main and disable the file_report, you'll get the gui
<seb128> I guess that's some hundreds crashers/week 
<seb128> vuntz|miam: any idea on this number?
<pitti> we shouldn't flood bz with that, at least not unfiltered
<seb128> how do you want to filter that?
<seb128> automatically dup?
<mvo> we talked about filters in the spec, it's a must IMHO :)
<pitti> well, filter by package, version, signal, and maybe by the function the crash occurred in
<seb128> a filter doesn't lower the number of bugs
<seb128> automatic close of dup is probably not a piece of cake
<seb128> especially than dups are often useful to get new informations on a bug sleeping as NEEDINFO
<pitti> Treenaks, seb128: http://people.ubuntu.com/~pitti/crashrep-gui.png
<pitti> it is *ugly* right now, but a demo
<tseng> white screen of death!
<pitti> the information needs to be presented in a much better form, but the gui shouldn't get any more complicated
<seb128> right
<seb128> bug-buddy is not really complicate
<seb128> pitti: what is bad about the crash dialog from bug-buddy? That's rather like your screenshot
<pitti> seb128: it's not really bad, but b-b has several screens of which most of them aren't interesting (gnome db update and such)
<pitti> seb128: if we want to use our own db we need to rewrite half of the code, and I don't like to do it in C
<pitti> seb128: but of course I will be fine with modifying bz if sb wants to do that
<pitti> s/bz/bb/
<pitti> seb128: still, we should first get the file dump perfect
<seb128> I don't really mind, but jbailey made the xmlrpc changes to bug-buddy just before hoary
<seb128> so it can speak to bugzilla.ubuntu.com by xmlrpc by example
<seb128> right
<pitti> yes
<pitti> seb128: files should already help us a lot, and we should get the debug stuff up and running
<pitti> seb128: without the symbols the traces are utterly useless
<seb128> that's my concern, I want debug backtraces out of the box
<seb128> the other points are bonus after that
<pitti> right
<pitti> seb128: let's try to get this file thing working for breezy
<seb128> yep
<pitti> seb128: did you already talk to lamont?
<seb128> I'll have a look on the buildd changes soon
<seb128> nop, planned for this afternoon
<pitti> cool
<pitti> seb128: I do some more testing now; the python code for trace acquisition looks rather ugly right now, but the much simpler version with Popen just doesn't work
<jdub> dear daniels, i am using windows until X is fixed. love, jdub.
<seb128> pitti: k
<seb128> pitti: another topic, are #11157 and #11242 for you? (audio hangs on pause by example)
<pitti> jdub: "use the text console, Luke"
<pitti> seb128: ah, on rhythmbox?
<seb128> yep
<seb128> pause play pause
<seb128> == hang
<seb128> dunno if that's a alsasink issue or an alsa one
<pitti> seb128: didn't dig into that so far
<pitti> seb128: some other guy on the ML mentioned that directly using alsa will cause problems, so the only thing that is left is polypaudio
<jordi> is polypaudio going for breezy again?
* jordi wonders about alsa 1.0.9.
<pitti> jordi: Erik de Castro told me that he fixed some major bugs in polypaudio
<seb128> we have alsa 1.0.9
<jordi> not that there's a lot of change wrt 1.0.9rc3 anyway
<pitti> well, we have rc3 so far
<jordi> ah.
* pitti tried to kick the Debian maintainer to package 1.0.9 final *duck*
<jordi> pitti: I'll see if I can release stuff to exp during the evening
<pitti> hehe, thanks
<jordi> Debian maintainers are worthless
<pitti> yeah, they are such slackers
<jordi> clueless, can't even mail mitre to get CAN assigned :)
<pitti> jordi: uh, yeah, it arrived :-)
<jordi> pitti: yup, I updated my changelog last night
<pitti> baz add *
<pitti> Failed to add id for path '{arch}'
<pitti> bah, can't this be fixed eventually?
<jordi> it's still not accessible from the CVE webpage tho
<pitti> no, that usually lasts a while
<seb128> anybody here has tried serpentine so far?
* pitti apt-gets
<seb128> pitti: k, that's a no :)
<jordi> *H*
<seb128> pitti: have you heard about it?
<jordi> err. s/H/G/
<ogra> pitti, i think we have a bug in g-v-m that affects the burning app that use the nautilus backend...
<pitti> seb128: not really
<seb128> pitti: k
<ogra> apps even
<pitti> ogra: $ serpentine
<pitti> Traceback (most recent call last):
<pitti>   File "/usr/bin/serpentine", line 34, in ?
<pitti>     from serpentine import SerpentineApplication, SerpentineError, operations, gtkutil
<pitti>   File "/usr/lib/python2.4/site-packages/serpentine/__init__.py", line 29, in ?
<pitti>     from mastering import AudioMastering
<pitti>   File "/usr/lib/python2.4/site-packages/serpentine/mastering.py", line 24, in ?
<seb128> ah ah
<pitti>     import operations, audio, xspf, constants, gtkutil
<pitti>   File "/usr/lib/python2.4/site-packages/serpentine/xspf.py", line 25, in ?
<pitti>     from xml.xpath import Evaluate
<pitti> ImportError: No module named xpath
<seb128> thanks pitti :)
<ogra> ugh
<seb128> what I was saying, 0 feedback
<seb128> I'm sure there is load of bug, it doesn't work for me neither
<pitti> "add dependencies, Luke"
<seb128> yep
<ogra> seb128, i know of about 10 people that tested it successfully now
<ajmitch> I've used it & it seemed to work
<seb128> make them mailing a list?
<seb128> so other people have the feedback too
* pitti installs python2.4-xmls
<seb128> we have 0 bugzilla entry about it
<ogra> but g-v-m 1. blocks the access to libnautilus-burn and 2. slows down ripping like hell
<seb128> and there is a ~10 mails post about the move to main
<seb128> how so?
<pitti> ah, now it starts
<pitti> ogra: add Depends: python-xml, please
<ogra> seb128, you have to disable autostart for the CD to speed up ripping it seems
<seb128> pitti: I'm the maintainer :p
<seb128> ogra: that's weird
<pitti> oh
<ogra> seb128, and  have no idea et what blocks the burning.... my hal/g-v-m journey starts next week... this week is screensavr :)
<vuntz> seb128: 109 bugs open by ubuntu users in one week
<pitti> seb128: looks rather nice
<seb128> vuntz: k, thanks :)
<pitti> but a lot of exceptions
<vuntz> seb128: most of them are NEEDINFO
<ogra> pitti, which ones ?
<pitti> ogra, seb128: http://www.rafb.net/paste/results/aFBEBx35.html
<vuntz> seb128: 19 UNCONFIRMED, 1 FIXED, all others are DUPLICATE/NEEDINFO/INCOMPLETE...
<ogra> pitti, thats intresting, since it worked for the other testers in here
<seb128> vuntz: do you have something to generate such stats or that's just bugzilla queries?
<vuntz> seb128: just queries
<ogra> pitti, i havent seen any tracebacks yet.... only bugs that stopped it from burning and were g-v-m related
<vuntz> seb128: I also chose a random week, but I suppose it's nearly always the same
<seb128> ogra: put an not-empty CD and try to record
<seb128> vuntz: ok, thanks
<ogra> pitti, could you open a bug ? 
<pitti> ogra: sure
<ogra> seb128, heh, thats obviously a usecase we didnt have yet :)
<pitti> ogra: but it doesn't really crash, it just looks a bit scary
<ogra> pitti, i'll look into it and talk with upstream about error messages ;)
<ogra> assign it to me ...
<pitti> ogra: so what's the bug title? "serpentine: various exceptions"?
<ogra> heh, yep
<seb128> ogra: my point is "why is there no public discussion" ?
<seb128> apparently you have pinged a bunch of user
<seb128> but made no feedback public
<pitti> bah, there is no "serpentine" package in bz
<ogra> seb128, they pinged me, in here
<ogra> pitti, t waits for python-gnome2-extras
<seb128> what about python-gnome2-extras?
<ogra> it is not in main
<pitti> ogra: #11447
<ogra> pitti, thanks
<jordi> pitti: hey, we've decided to upload 1.0.9 to unstable :)
<pitti> cool
<Lathiat> hmm shtoom wants twisted2 and thats not in hoary, d'oh.
<bod> Kamion: that sync the other day from experimental, is that now tracked?
<seb128> pitti: the rhythmbox hangs seems to be fixed with the new gst-plugins0.8, so probably an alsasink issue
<pitti> ah, cool
<pitti> seb128: will check after a dist-upgrade, it occurs to me, too
<seb128> k
<seb128> jbailey: have you read https://bugzilla.ubuntu.com/show_bug.cgi?id=11146 ?
<bod> if not, could you sync again please?  5.8.7 in experimental
<bod> elmo: about?
<pitti> seb128: hm, I don't even have this package installed
<pitti> seb128: still, rhythmbox hangs
<seb128> pitti: that's the source package, gstreamer0.8-alsa is the binary
<pitti> ah
<seb128> and I've just uploaded like 5 min ago
<jbailey> seb128: I have.  Now that cdbs is building again, I can look at the cdbs bugs.
<seb128> 0.8.9
<seb128> jbailey: k, thanks
<pitti> seb128: ah, that's why I still ecperience it, but I'm up to date
<seb128> yep, wait a bit
<seb128> get a lunch or something :)
<pitti> jbailey: btw, I just uploaded a new cdbs with a fixed gnome.mk
<jbailey> seb128: Do you need it for today?
<seb128> jbailey: not at all
<jbailey> pitti: Already uploaded or about to?
<Kamion> bod: no, experimental isn't tracked automatically
<pitti> jbailey: last time I erroneously put in an old version
<pitti> jbailey: uploaded
<jbailey> pitti: Ah well.  (Sorry sb, I tried. *g*)
<Kamion> elmo: please sync perl 5.8.7-1 from incoming
<pitti> jbailey: bad?
<seb128> jbailey: np :)
<seb128> pitti: no, was just about #11146 I guess
<jbailey> pitti: No worries, as seb128 said.  If it was about to, I'd have gotten you to add the 1 line patch from 11146 =)
<bod> Kamion: thanks.  Got the impression that it wasn't automatically synced in general, but wasn't sure if the sync from experimental was "sticky" if done once
<fabbione> thom: ping?
<Kamion> bod: nah, syncs from unstable happen automatically if there are no Ubuntu changes (technically, if the version in breezy doesn't match /ubuntu/), all else is manual
<bod> k
<Kamion> elmo: please sync libgetargs-long-perl from unstable
<lifeless> jbailey: ping
<jbailey> lifeless: here.
<lifeless> can you fix /usr/lib/tk8.3/tkConfig.sh 
<jbailey> lifeless: Finally finished your workday? =)
<jbailey> 'fix' ?
* jbailey sends it to the vet to be fixed.
* jbailey wishes the tcl and tk versions would stop reproducing.
<lifeless> )
<lifeless> https://bugzilla.ubuntu.com/show_bug.cgi?id=11444
<lifeless> theres a patch there for installed tk's ;)
<lifeless> or by hand, line 46 is corrupt
<lifeless> should be TK_XINCLUDES=''
<infinity> lifeless : It's already been fixed in breezy.
<doko> jbailey: rebuild with the "xorg in transition state" should fix it
<lifeless> infinity: I know
<lifeless> infinity: this is on his ia64, so unless its actually hit the archive
<lifeless> ...
<jbailey> lifeless: The ia64 is on debian...
<lifeless> jbailey: heh, has the same problem though
<infinity> Ahh.
<Amaranth> whew
<Amaranth> ubuntuguide doesn't tell people to use marillat anymore
<lifeless> infinity: could you file that particular patch in debian, or would you like me to ? ( I want to unbreak gst there too)
<infinity> lifeless : Too late for sarge, unless you can argue that it's so incredibly RC is should delay the release by a few days.
<infinity> lifeless : And good luck with that argument. :)
<lifeless> infinity: did I mention sarge ?
<infinity> Oddly, no.  I'm just very used to people in the last two weeks begging for last minute bugfixes.
<lifeless> noone uses debian stable
* lifeless cares about sid
<infinity> Say... Why is your beloved app compiling against an obsolete tk version anyway?
* Treenaks can officially say that we do not use any TK apps at the .tk registry!
<infinity> Didn't everyone transition to 8.4 in, like, 2002?
<lifeless> infinity: well now, thats an interesting question
<lifeless> I'll see if its just maintainer slackness
<jbailey> lifeless: That was one of the questions I had in the packaging. =)
<jbailey> That and why the useless {post,pre}{rm.inst} scripts. =)
<infinity> lifeless : tk8.4 has had this bug fixed for ages, it looks like.
<infinity> lifeless : Anyhow, I'll push the tk8.3 fix up sometime, but I doubt anyone cares much, since it is obsolete.
<lifeless> I'll see about updating the package then
<mvo> ping enrico 
<enrico> mvo: pong!
<enrico> mvo: just back from lunch
<enrico> mvo: what can I do for you?
* Nafallo says morning all!
<pitti> Hi Nafallo 
<jdong> hey guys
<Amaranth> hey
<jdong> just wanted to bring to your attention that blackbox and fluxbox conflict
<jdong> bsetroot's manpage is in both....
<jdong> i don't know how you guys would handle it; but it's definitely a packaging issue :)
<Amaranth> jdong: don't suppose you could accept smeg and my new gnome-menus in backports :)
<Amaranth> jdong: switching gnome-menus to the backports style version (~5.04ubp) makes it not break gnome-devel
<jdong> Amaranth: does your gnome-menus break ABI compatibility, though?
<Amaranth> not sure if the two functions removed are available externally
<Amaranth> i didn't remove them, they were removed on the 2.10 cvs branch
<Amaranth> so i'd say no
<jdong> Amaranth: why isn't smeg in universe yet, btw
<Amaranth> jdong: takes 48 hours
<jdong> Amaranth: oh, so you just tried to get smeg in universe?
<Amaranth> yeah, 12 hours ago
<jdong> Amaranth: well, if everyone around here is fine with the new gnome-menus, fine, backports it is, as soon as I see the universe packages :)
<Amaranth> MOTUNewPackages shows that it was uploaded, you can just be faster than breezy ;)
<jdong> lol
<jdong> k, where's you gnome-menus?
<Amaranth> the gnome-menus package is basically what 2.10.2 will be, if/when it's released
<Amaranth> http://dev.realistanew.com/gnome-menus
<jdong> k
<Amaranth> src dir has diff.gz, .dsc, and .orig.tar.gz so you can build it yourself
<fabbione> elmo, thom: i really really need one of you 
<enrico> _mvo_: welcome back
<enrico> _mvo_: if you want to tell me about libtagcoll1 problems, I'm here
<jdong> Amaranth: k
<mvo> enrico: my network is unstable :/
<jdong> Amaranth: 0.7.4?
<jdong> Amaranth: I'm gonna use  ubp-build.py http://dev.realistanew.com/smeg/latest/smeg.tar.gz
<jdong> Amaranth: diff.gz patches, location?
<jdong> never mind again :)
<Amaranth> http://dev.realistanew.com/smeg/0.7.4/
<Amaranth> i made a forum thread about this ;)
<jdong> Amaranth: uploading :)
<Amaranth> cool
<Lathiat> jdong: plz to have sources
<jdong> Lathiat: huh?
<Lathiat> jdong: arent you the backports guy?
<jdong> Lathiat: yes
* fabbione goes off line for a while
<Lathiat> jdong: Then, please to have source archives for backports :)
<jdong> Lathiat: this will happen naturally when I transition to the Ubuntu archive system
<Amaranth> Lathiat: he will, when he moves to ubuntu servers ;)
<Lathiat> oh you are?
<Lathiat> sweet
<jdong> Lathiat: for now, I see it as a unnecessary waste of space, time, and bandwidth
<Lathiat> jdong: i see it as a possible license violation
<jdong> Lathiat: all the sources are exactly the same, minus the version number change
<Lathiat> jdong: so, thats a change :) depends what license debian/ is under. :)
<Lathiat> and more to the point, its convenient for me when i want the sources to something :)
<Lathiat> but if your migrating to shit and then youo'll have it then rock on
<jdong> Lathiat: why not deb-src Breezy?
<Lathiat> jdong: well not all your stuff is from breezy for example
<Lathiat> (at least, if you include extras)
<jdong> Lathiat: either way; I will have sources soon....
<Lathiat> jdong: like i said, cool, rock on :)
<jdong> Lathiat: extras will have to be introduced into universe
<jdong> Lathiat: what packages, specifically ,are you interested in?
<Lathiat> jdong: isnt that an issue for some of the media stuff ?
<Lathiat> or java or something
<jdong> Lathiat: Extras will continue for restricted formats
<Lathiat> (im not sure what the issues are there)
<Lathiat> jdong: ah ok
<jdong> Lathiat: though I'm scared what legal issues I can run into :)
<Lathiat> just host it in sweden :)
<jdong> Lathiat: lol!
<Lathiat> (that was mostly serious)
<ogra> jdong, btw, do you build your packages already in a pbuilder ? you should make yourself familiar with it
<jdong> Lathiat: combine forces with debian-marillat
<Lathiat> jdong: sounds like a plan...
<jdong> ogra: pbuilder who?
<ogra> jdong, the build envoronment that imitates a buildd....
<jdong> ogra: yeah, reading docs. What's the difference between this and a chroot?
<ogra> it checks your dependencys ;)
<jnc> psst, amd64 devs;  bug #11453
<jdong> ogra: isn't that just an dpkg-buildpackage and apt-get build-dep ordeal?
<ogra> jdong, http://www.ubuntulinux.org/wiki/PbuilderHowto
<jdong> ogra: this looks like a wrapper around what I do already :)
<ogra> jdong, the nice thing is that if you know it builds reliable in a pbuilder, you can very much rely n the fact it will build on the buildd too.... where using a chroot that already holds dependency packages might fool you
<jdong> ogra: ah, ok
<jdong> ogra: I see how that works. So it's more useful if you're making a new package, right?
<ogra> i assume you dont rebuild your chroot everytime ;)
<jdong> ogra: once every week or two, I do
<jdong> ogra: I have a few scripts for that ;)
<ogra> nope, if you build any source package :)
<jdong> ogra: what's the chances deps for Firefox will change from 1.0.3 to 1.0.4?
<ogra> jdong, was just a hint, makes the life a lot easier if you work with buildds
<jdong> ogra: ok, thanks :). I'll see how it'll fit in with my build scripts :)
<ogra> jdong, that a thom question 
<jdong> ogra: laziness is keeping me at my scripts now
<ogra> yep
<jdong> so ogra, can I relay that fluxbox/blackbox bug to you guys?
<ogra> jdong, just file it
<jdong> ogra: I'm having trouble using malone
<jdong> ogra: system error
<Amaranth> yeah, malone was broken last night too
<jdong> screen -r
<Amaranth> sudo pbuilder build file.dsc and away it goes
<jdong> ugh wrong terminal
<ogra> jdong, then defer it :) in any case all bugs should end up on one of our bugtrackrs :)
<Amaranth> drops the results in /var/pbuilder/results/, iirc
<jnc> err who does ia32 libs?
<jdong> Amaranth: ubp-build.py packagename and away it goes... Drops it into the Ubuntu Backports mirror system iirc ;)
<Amaranth> heh
<Amaranth> can i have that script ;)
<Nafallo> jnc: seems to be doko atm :-)
<jnc> bwahaha
<jnc> let him deal w/ it
<jdong> Amaranth: http://ubuntubackports.org/ubp/projects/ubp-tools/ubp-build/
* jnc >:)
<jdong> Amaranth: still need a svn password to attack me, though ;)
<Amaranth> nice
<Amaranth> you even use psyco :)
<jnc> doko: hey buddy, somebody broke ia32-libs *cough*  bug #11453
<jdong> Amaranth: of course :) Why not?
<Amaranth> jdong: i'll modify this to use pbuilder
<jdong> Amaranth: pysco backport, too ;)
<jdong> Amaranth: awesome, that'd be interesting to have
<jdong> Amaranth: not really worth the effort though, depending on how long it'll be before I get on the the Ubuntu system
<doko> Nafallo, jnc: it's not broken, it's waiting
<jdong> Amaranth: which I assume the uploading procedure (at the very least ) will be very different
<Amaranth> why did you write your own argument parser?
<Amaranth> well, this could be useful for me
<jdong> Amaranth: I didn't know how else to parse arguments
<jdong> Amaranth: I'm a VERY traditional argv person :)
<Amaranth> hmm, maybe optparse wouldn't be useful there
<jdong> Amaranth: not like there's any arguments that need complicated parsing
<jdong> alright guys, I have to head back to class
<jdong> have fun :)
<jnc> doko: okay want to mark that bug invalid or should i do it?
<Nafallo> doko: I know :-). but you're still the one that cares for it atm, and that was the question ;-)
<doko> jnc: mark it pending
<jnc> thanks
<jnc> if a dep is broken, does that make it worthy of "blocker" status?
<jnc> as a gentoo dev i usually get annoyed when users mark things with high priority
<Amaranth> lmao
<Amaranth> uh_die()
<jnc> our deps are not broken as often as packages stop building for no apparent reason
<jnc> so, had to ask
<Kamion> very little justifies blocker status
<jnc> 10-4
<Kamion> we'd prefer that only to be used as a release management tool; we generally downgrade anything from blocker immediately
<tepsipakki> is ACPI enabled on the hoary live-dvd?
<tepsipakki> by default
<Kamion> should be
<tepsipakki> ok, my fellow worker has had problems with FC on a Thinkpad T42p ;)
<tepsipakki> so I burned him that dvd
<tepsipakki> burnt, even
<jnc> get teh aloe vera, 'cause someone got BURNED
<Kamion> wow, I managed to break grub-installer with MountingHddFilesystems
<Kamion> that was impressive
* jnc dies laughing alone
<Kamion> s/Hdd/HDD/
<Kamion> unintended-consequences-'r'-us ...
<Treenaks> Kamion: WikiStyle!
<Kamion> Treenaks: *shrug* I didn't create the page
<doko> elmo, Kamion, mdz: gcc-4.0 needs NEW/main love for lib32z1-dev and lib32z1
<SloMo_> Amaranth: I'm currently building your smeg stuff for ppc... when everything works fine I'll upload later to backports
<Kamion> jnc: ... but trivial's for spelling mistakes and stuff, dependency problems would always be >= normal
<Amaranth> SloMo_: cool
<Amaranth> SloMo_: you mean gnome-menus, right?
<Kamion> if in doubt, file bugs at normal (unless they're clearly enhancement) and let somebody else sort it out :)
<Amaranth> SloMo_: the rest is platform independent
<SloMo> Amaranth: yes
<nanomad> just a question...xbase-clients (broken now, i know...) also affects keys?
<SloMo> Amaranth: have you built a smeg*~5.04ubp1.deb? only found the breezy version... otherwise I'll just rebuild
<Amaranth> SloMo: jdong did
<SloMo> Amaranth: yeah right... I'll upload the gnome-menus stuff now, seems to work fine ;)
<Amaranth> fixes many things too
<Amaranth> if only it fixed layout support...
<SloMo> layout support?
<Amaranth> <Layout>
<Amaranth> part of the menu spec
<SloMo> ah ok
<Amaranth> that's why you can't reorder things if you're using gnome 2.10
<SloMo> it is fixed in gnome-menus HEAD, right? or is this fix for another problem:
<SloMo> 2005-05-30  Mark McLoughlin  <mark@skynet.ie>
<SloMo> 	Fix problem where menus and items mentioned in a <Layout>
<SloMo> 	after a <Merge type="menus"> or <Merge type="files">
<SloMo> 	Bug #305723
<Amaranth> that's the fix for a problem with <Layout> in HEAD that i reported
<Amaranth> but <Layout> is supported in HEAD, yes
<jnc> doko, elmo, Kamion, mdz:  FYI the bug for the lib32z thing is #11453, and i have marked it as suggested.
<SloMo> Amaranth: are you interested in german translations for smeg? ;) seems there is currently no support for gettext, but is it planned?
<Amaranth> it's planned, once i figure out how all the other python projects do it
<Amaranth> they all seem to have their own way
<Amaranth> i'm collecting translations though, please send them to alleykat@gmail.com
<Amaranth> make a list of the english text and the german for it
<Amaranth> oh, and make sure you say it's german, i have one that i'm totally lost on because i wasn't told the language in the email
<SloMo> Amaranth: ok, I'll send the translations later this day
<Amaranth> cool
<wasabi_> Hmm what happened to the better Ubuntu branded xscreensaver
<dilinger> i'd like to request the bouncing cow be replaced with other 3d ubuntu-ish things.  Bouncing ubuntu logos, bouncing naked people...
<thoreauputic> bouncing developers....
<siretart> bouncing bounces...
<maswan> bouncing elmo?
<siretart> lol
<SloMo> Amaranth: do you want them in .po-file style? or just a list with english/german translations?
<ogra> maswan, do you know a good 3d designer who could build us an elmo ? i'd be willing to hack that in ;)
<Amaranth> SloMo: just a list
<JaneW> ajmitch:ping
* maswan ponders
<Amaranth> jimmac? :)
<maswan> not really, the 3d guys I know are rather people involved in modeling textiles in mathematical ways etc
<maswan> or for that matter, doing realistic sand/gravel for simulators
* ogra would also take a sandy puppet of elmo.... graining while bouncing :)
<ogra> hmm, what about a bouncing warthg ?
<maswan> :)
<ogra> warthog even....
<dilinger> ogra: or badger?
<ogra> could anybody be religious offended ?
<ogra> dilinger, fear the badger cult *G*
<opi> did I hear someone says badger?
<opi> ;-)
<maswan> should we fear the badger cult more or less than the elmo cult?
<dilinger> ogra: for apr 1, some mushrooms could float across the screen horizontally
<dilinger> or something :p
<ogra> hehe
<thoreauputic> bouncing snakes would be scary, if you go the badger route...
<diego> ogra: is there anyone already writing the GraphicalConfigTools?
<ogra> diego, not yet, but i havent done the detailed app spec... 
<diego> ogra: hm..well i'm quite interested in helping with those. i'm not extremely experienced but i've worked with python/pygtk/glade enough that the 3 listed sound fairly easy
<diego> (and i really want to help out ubuntu because it rocks hehe)
<ogra> where i can, i will spec it out as a dbus driven app... you should probably have a look at that...
<diego> ok, great
<diego> ogra: can you give me an example of the functionality it would/could gain by being dbus-driven?
<ogra> i.e. having everything as a commandline app that accepts dbus messages from a gui, so you have in fact two apps
<diego> ogra: ah, i see. then there could be a curses-based interface too if someone wanted to write it?
<ogra> yeh
<ogra> so it could be usable for headless servers etc.
<SloMo> Amaranth: you have mail ;)
<Amaranth> cool
<lamont__> Kamion: ping
<Kamion> lamont__: pong
<diego> ogra: ok, i've just been reading about dbus. what's the plan to move forward on the GraphicalConfigTools?
<ogra> diego, wait a bit until i have written the detailed spec :)
<diego> ogra: yeah, ok. about how long is "a bit" though?
<ogra> we can discuss it then
<diego> a couple weeks or so?
<ogra> i think i'll come around to make it during the next week...
<ogra> today i'm busy with xscreensaver hacking... 
<diego> ok, great
<diego> the detailed spec will go into the udu wiki, correct?
* mvo is away for ~2h
<SloMo> Amaranth: have you read http://www.python.org/dev/doc/devel/lib/node322.html ? as far as i can see everything is explained there. if you're interested I can try to implement it
<ogra> diego,yes
<pitti> Morning mdz
<mdz> pitti: morning
<pitti> mdz: would you be opposed to introducing a tiny setuid root program in the eject package that maps a devmapper-device to its attached real device?
<pitti> mdz: the goal is to make eject handle encrypted (i. e. device-mapped) devices as well
<pitti> mdz: but without root privileges the mapping becomes very hackish
<pitti> mdz: (i. e. string matching on device name and hoping that the user didn't change it, and so on)
<fabbione> morning mdz
<fabbione> elmo: are you around by any chance?
<fabbione> or somebody with root on davis?
<Amaranth> SloMo: looks interesting
<Amaranth> SloMo: i'll have to figure out how to use it with glade files though
<SloMo> Amaranth: pygettext doesn't support glade files... you have to use xgettext to extract the strings
<Amaranth> SloMo: I am now in the realm of "no fucking clue". ;)
<Amaranth> SloMo: If you want to try to do it that'd be great. :)
<SloMo> Amaranth: and for displaying the translated string there is either something to set for glade in python or it works out of the box when you initialized gettext before loading the glade file. but i have no idea how one can say setup.py, that it has to build the .gmo files and install them later
<Amaranth> I can always set the strings in python.
<Amaranth> self.w('foo').set_text(_('File'))
<SloMo> sure but glade can do this on it's own
<Amaranth> yeah
<Amaranth> i'll look at how straw does it
<Amaranth> hmm, gtranslator
<zAo^> lo all
<Loevborg> hoary faling to set up /etc/hosts and /etc/network/interfaces correctly (to include loopback), is that a known problem? I guess it's rather difficult to figure out for a newbie.
<mdz> pitti: how can it do better if it has root privileges?
<pitti> mdz: it can use the libdevmapper functions
<pitti> mdz: but these require root
<mdz> pitti: they use /dev/mapper/control or something?
<SloMo> Amaranth: hm, i think i understand how straw does it ;) they've written their own setup.py and for glade... you can set the gettext domain with glade.XML and everything will work ;) the only tricky part is the setup.py, everything else is really easy
<zAo^> Loevborg, I installed several instances of Ubuntu, none failed to build /etc/hosts or /etc/network/interfaces. DHCP worked out-of-the-box
<Loevborg> zAo^, it probably has to do with my skipping the "network configuration" part of the installaion (because my wlan card doesn't work with the detected prism54 drivers)
<pitti> mdz: so far I use cryptsetup status, which gives an error when ran as non-root; now I'm writing a small app that uses libdevmapper directly
<zAo^> Ah, I will try that on my test machine next week :)
<pitti> mdz: probably /d/m/c, yes
<pitti> mdz: I didn't find a /proc or /sys interface
<Amaranth> SloMo: I'm glad one of us understands.
<dcraven> Amaranth: You have one, how does a project qualify for a forum in "3rd Party Ubuntu Projects"?
<Amaranth> dcraven: *shrug*
<dcraven> heh
<Amaranth> dcraven: smeg stuff was spamming the desktop forum and ubuntugeek made me a subforum
<Amaranth> i think mine was the first, but backports might have been there first
<dcraven> Amaranth: Ahh.. I see.
<Amaranth> if the project looks like it has a future and is being created and used by the ubuntu community i'm sure ubuntugeek will give you a subforum
<Amaranth> but you have to have something to show
<dcraven> Amaranth: Yeah. I was just curious about that. Might be handy some day. Cheers.
<mdz> pitti: it is a shame to add another setuid root program to the default install :-/
<mdz> pitti: but if it is tiny and auditable and has a definite value to add, that seems reasonable
<pitti> mdz: I think it's better than device string matching; I started with this, but it's really ugly
<pitti> mdz: if you have a better idea, then I'd appreciate :-)
<SloMo> Amaranth: the setup.py stuff is really complicated... hum... reminds me of automake/autoconf ;) I'll try to get sth working later or tomorrow and let you know
<Amaranth> SloMo: ok, cool
<\sh> can someone explain to me, how we can remove one package out of universe and replace it with another newer package from debian? 
<Mithrandir> \sh: "sync"? :-)
<\sh> the reason is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286700
<\sh> Mithrandir: but i have to touch it anyways...
<\sh> so the question is, how can i remove one package out of the repos?
<Mithrandir> \sh: why do you need to remove it?
<\sh> Mithrandir: gnuradio-0.9 is not maintained anymore, upstream dev has uploaded new version gnuradio-core-2.5 to debian
<Mithrandir> \sh: the package name is gnuradio-0.9?
<\sh> Mithrandir: gnuradio
<Loevborg> \sh, why not just "dpkg -i" the package file
<Mithrandir> \sh: then just upload a newer package?
<\sh> Mithrandir: ok, and what about the old one?
<\sh> oh yes
<Mithrandir> \sh: it'll go away, since it's superseded.  As long as the package name doesn't change.
<\sh> Conflicts: Replaces: 
<Mithrandir> no, those are totally different things.
<\sh> Mithrandir: but the name changed as well ;)
<\sh> at least the source name as I can see right now
<\sh> oh no...also the binary package name changed
<Mithrandir> \sh: if the source package name changes, but the binary not, don't worry, it'll be caught by rene
<\sh> Mithrandir: as I said, the binary package name changed as well
<Mithrandir> \sh: doesn't matter.
<mdz> pitti: I'm afraid I know very little about the dm crypto stuff
<pitti> mdz: I'll explain it in a mail
<\sh> Mithrandir: ok...then I will adjust the new package for breezy and source upload it then
<pitti> bye folks, have to go. nice weekend everybody!
<jnc> ehhh
<jnc> this may be a dumb person asking a question...    is the fact that OpenOffice asks me to "auto save", and this pops up and interrupts my use of the desktop, is that a bug?
<jnc> i want to really ask if that should be converted into ULTRA MEGA PULSATOR like gaim popup windows do
* Nafallo < phone
<mdz> am I the only one whose firefox is horribly broken?
<mdz> (in breezy, obviously)
<zul> broken as in how?
<mdz> mizar:[...nonical/seeds/ubuntu/breezy]  firefox
<mdz> /usr/lib/mozilla-firefox/firefox-bin: error while loading shared libraries: libfreetype&sg.6: cannot open shared object file: No such file or directory
<mdz> "libfreetype&sg.6" is interesting
<zul> no problems here
<mdz> just a couple of bits off from libfreetype.so.6
<fabbione> that looks so much like a patch stolen from a web page without text conversion
<mdz>         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7602000)
<mdz>         libfreetype&sg.6 => not found
<mdz>         hibexpat,si.1 => not found
<mdz>         libc,so.6 => not found
* Nafallo > here
<mdz> note the comma in the libc dep
* fabbione blames binutils
<dilinger> neat
<mdz> 84593149de55f308d04ef3461826b6e5  /usr/lib/mozilla-firefox/firefox-bin
<fabbione> mdz: what arch is that?
<mdz> i386
<seb128> 84593149de55f308d04ef3461826b6e5  /usr/lib/mozilla-firefox/firefox-bin
<seb128> same
<mdz> seb128: but your ldd output is sane?
<seb128> correct
<mdz> very weird
<fabbione> 84593149de55f308d04ef3461826b6e5  /usr/lib/mozilla-firefox/firefox-bin
<fabbione> mdz: ldd is ok here
<mdz> oh, those are indirect deps of some shared library
<fabbione> mdz: ld cache corruption?
<Nafallo> seb128: where have you hidden "run programs"? :-)
<mdz> not the bin itself
<mdz> I need to find which one
<fabbione> why i have the feeling that it will bring you to X?
<seb128> Nafallo: alt-F2
<Nafallo> seb128: aha. I need to put the keybinding back. thanx ;-).
<seb128> np :)
<mdz> what is linux-gate.so.1?
<fabbione> mdz: nothing to be worried about
<fabbione> it has been there forever
<mdz> is it new?  I don't remmeber seeing it before
<fabbione> but in previos versions of ldd it was just hiddeng
<fabbione> hiding it
<fabbione> mdz: i had the same concern when binutils was updated
<seb128> I don't have a such file here 
<fabbione> and kernel initrd generation was broken :)
<mdz> mizar:[/tmp]  objdump -x /usr/lib/libfontconfig.so.1 | grep 'NEEDED.*,'
<mdz>   NEEDED      hibexpat,si.1
<mdz>   NEEDED      libc,so.6
<mdz> 0ac9a59ec54622148a0ee49ae783d93e  /usr/lib/libfontconfig.so.1
<fabbione> mdz: what version of fontconfig?
<fabbione> or libfontconfig
<mdz> 2.3.2-1ubuntu1
<mdz> libfontconfig1
<fabbione>  bc04c04241ac216f50039c9cde89dff4  /usr/lib/libfontconfig.so.1
<mdz> bc04c04241ac216f50039c9cde89dff4  usr/lib/libfontconfig.so.1.0.4
<mdz> from the .deb
<mdz> interesting, so I have file corruption
<mdz> that's rather disconcerting
* fabbione waits a bug on the kernel.....
<mdz> I have not even had so much as an unclean shutdown in a long time
<fabbione> mdz: badblocks?
<mdz> -rw-r--r--  1 root root 344 2005-05-05 18:58 /var/lib/dpkg/info/libfontconfig1.list
<mdz> firefox definitely has worked since then, so it was corrupted on disk, not during install
<mdz> very bad, considering I would never have modified that file
<fabbione> mdz: i would suggest to check the hd for badblocks
<mdz> debsums shows no other corrupt files
<mdz> but it does find libfontconfig.so.1
<mdz> cosmic rays perhaps
<mdz> I will check badblocks
<mdz> but I have no I/O errors in my logs, so I doubt it will find anything
<fabbione> mdz: bad ram?
<fabbione> i am sure of one thing.. it's not a kernel error :)
<fabbione> mdz: what fs btw?
<mdz> ext3
<fabbione> .12rc5 ?
<fabbione> or .10?
<mdz> I have been tracking .12
<mdz> 2.6.11.93-1.1 right now
<fabbione> ok
<fabbione> in that config i really doubt it's a kernel problem
<fabbione> i386 + ext3 is one of the most tested bits
<fabbione> and i am using it here everywhere too
<mdz> yep, that's why I use it :-)
<mdz> badblocks showed no errors
<mdz> seems like probably memory corruption
<fabbione> mdz: i blame GTK!
<fabbione> yeah
<fabbione> that's more possible
<mdz> what a very interesting way for it to occur, though
<fabbione> mdz: you seem very excited by it :)
<fabbione> perhaps you want to debug it? :P
<stern_type> her name?
<mdz> wasabi_: I've updatedhttp://people.ubuntu.com/~mdz/temp/java-main.txt
<mdz> fabbione: no, I have already reinstalled fontconfig and started using firefox again ;-)
* Nafallo < movie(s), bbl.
* Nafallo is away: movie(s), bbl
<infinity> mdz : Despite it being a weekend, I'll pop in and out to help wasabi massage that stuff through some more, if he's working on it today.
<infinity> (Also, what am I doing still up at 3:30am?... I don't know either...)
<fabbione> mdz: ehhehe
<fabbione> infinity: you were supposed to go to sleep eons ago
<infinity> fabbione : I know, but then I got caught up in that other distro that's a hobby in my off hours.
<fabbione> infinity: oh damn :)
<infinity> So, basically, I've been nerdy all day and all night, and I think I'm going to shoot myself.
<fabbione> i am going out soon.. today is party :)
<infinity> Celebrating elmo's birthday?  Man, everyone seems to be.
<fabbione> now it's happenning exactly what i expected a few months back
<infinity> (Or are you more of a doko fan?)
<fabbione> infinity: i love both of them
<infinity> :)
* infinity heads to bed.
<Micksa> so how does one debug STR problems?
<infinity> For real this time.
<fabbione> infinity: good night
<Micksa> oh that's right
* Micksa pokes mjg59
<infinity> mdz : Tell wasabi to ping me via /msg if he needs help massaging his java chain.
<stern_type> they love jesus-'idol' so much,they put him in a state of pain with her
<dieman> ok
<dieman> im sold
<dieman> baz and the whole arch thing is the way to work
<dieman> i just used bazaar to merge in changes from phorum into a locally hacked copy of forum
<dieman> phorum, rather
<dieman> it works super, super, super well.
<Micksa> and it finished before you died too
<dieman> i did the last one by had
<dieman> hand 
<dieman> with diff
<dieman> it was very painful.
<Micksa> hukhukhuk
<dieman> this one had a whole 6 files conflicted. :)
<Micksa> you've merged using CVS right?
<dieman> yeah, thats painful too.
<dieman> i never could figure out how to get the controtions to get cvs to work for what i needed in this case.
<dieman> its probally possible, i guess.
<dcraven> Amaranth: If you are looking for internationalization guidance, there is pygnome-hello in the gnome-python package. It uses GNU autotools though.
<mdz> infinity: meaning you're *not* going to sleep?
<infinity> mdz : Meaning I'll probably be up again in a few hours.
<mdz> fun
<infinity> (This is merely a clever AI autoresponder.  Pay no attention)
<mdz> wasabi: looks like libxerces2-java is the last free-java-sdk package
* Micksa reads some blog
<Micksa> mjg doesn't respond well to being poked does he?
<daniels> pittyeah, known issue, will be fixed tomorrow (i.e. saturday)
<Micksa> I want STR love :(
<Micksa> right
<Micksa> I'll take a shot at this myself
<mdz> daniels: around?
<mdz> daniels: for ThinClientIntegration, I need to preseed xserver-xorg/config/inputdevice/keyboard/layout for reconfiguration, but this doesn't currently work
<maswan> thom: want feedback on your httpd2.1 packages?
<tseng> maswan: only if it requires him to do lots of menial work. in that case, he cant get enough.
<maswan> tseng: How about I whine meaninglessly about how it sucks, doesn't work, and is bad, but not actually tell him anything useful in how it is broken?
<tseng> oh, he loves that too
<maswan> great!
<maswan> thom: if you actually read scrollback, lots of /etc/httpd2.1/ was missing after install. Nothing worse (yet).
<\sh> hmm...any g++ geeks around?
<maswan> well.. with the exception that the large file support seems broken on amd64
<\sh> if a class is deklaring another class as friend, is the friend able to call a private constructor?
<\sh> s/deklaring/declaring/
<ska-fan> I think it should.
<jbailey> mdz: around?
<\sh> ska-fan: but it fails
<\sh> ska-fan: g++4 is complaining
<ska-fan> \sh: I'm really anything but a c++ expert, sorry
<ska-fan> \sh: try #c++
<ska-fan> there are very smart people there.
<ska-fan> ##c++ even.
<\sh> thx
<jdub> seb128: around?
<chrissturm> it could even be a bug in gcc 4.0
<jdub> mdz: around?
<jbailey> jdub: The Jeff's are a hunting, I see. =)
<jdub> heh
<jdub> mdz is hacking on ltsp
* Nafallo is back (gone 01:58:41)
<Nafallo> jdub: morning :-)
<Kamion> Nafallo: you pinged me last night?
<jdub> hey Nafallo 
<mdz> jdub: yes?
<mdz> jbailey: yes?
<Nafallo> Kamion: yea. the damn script wants to redownload the whole of main and restricted every sync when I use /pool/.
<Nafallo> Kamion: you got time to take a quick look at the script? :-)
<seb128> jdub: yep
<jbailey> mdz: Do you need any hooks so far in the initramfs beyond the script you sent me?  I'm doing up a similar set for mdadm and friends right now.
<mdz> jbailey: I need a hook wihch allows me to do what I was doing in that script, but at a later stage of the boot process
<mdz> that's it
<monolive> Anyone here familiar with ubuntu bounties?
<jbailey> mdz: The run-init at the end of that script is what chains to init.  Can you describe where you need the hooks to go?
<Kamion> Nafallo: well, uh, I tend to attack such problems with strace, so I'm not sure how much help I'll be :)
<mdz> jbailey: that script was only meant to show you what I was doing; it's not meant to exist in that form
<Kamion> Nafallo: definitely start by using rsync -v
<mdz> jbailey: the way it should work is: 1. mount root filesystem using the stock nfs script, 2. unionfs magic runs, 3. run-init
<Nafallo> Kamion: http://www.magicalforest.se/~nafallo/mirrorscript/
<jbailey> mdz: Cool, thanks.
<mdz> jbailey: so the unionfs magic would take whatever's on /root, slap a copy-on-write layer on top of it, and then proceed as normal
<Nafallo> Kamion: there are the scripts, and s/script/log/ for the logs :-P
<Kamion> (what's with the [[ ... ] ] ?)
<Nafallo> Kamion: I'm using the same as you I believe.
<Kamion> I would use [ ... ] 
<Kamion> anyway
<Nafallo> Kamion: stolen from maswan's script iirc ;-)
<Kamion> Nafallo: nothing's jumping out at me as obviously wrong
<maswan> I deny everything
<Kamion> bear in mind I'm not a professional mirror operator though - that was just what I needed to do to get cdimage to work
<Nafallo> Kamion: and it doesn't resync everything at your place? ;-)
<Kamion> no
<Kamion> but your script is fairly significantly different from mine, so that says nothing really
<Kamion> for one thing I only do two rsync passes
<Nafallo> Kamion: i used universe/ and multiverse/ in excludes only. but I don't think that should change anything significantly :-)
<Kamion> mine does unnecessary resyncs of some files which are main ->/<- universe symlinks, like yours
<Kamion> you sure that rsync -n is telling the truth?
<Kamion> you could try it on smaller subdirectories of pool to experiment
<Nafallo> Kamion: I tried without "pool/" and it does almost what it should. except that it plays with the daily-installerstuff.
<Nafallo> Kamion: oh well. I should hack a bit more on it.
<Nafallo> Kamion: I probably wouldn't want to use three sync against maswan's damn clusterstuff :-P.
<maswan> sorry?
<Nafallo> maswan: and _no_! you're _not_ innocent ;-)
<Kamion> daily-installer-* contains symlinks within itself, hence the two rsync passes in my mirror script
<Kamion> likewise installer-*
<Nafallo> those are not hard-links?
<Kamion> no, current -> <some directory>
<Kamion> you can't hard-link directories
<Nafallo> hmm, right. I read that yesterday in the middle of the night :-P.
<Nafallo> maswan: as I mentioned earlier it's still slow for me to get the file lists from you.
<maswan> Nafallo: does it take more than 5 minutes?
<Nafallo> maswan: yes. could be that I'm on 440k ;-)
<Nafallo> maswan: I thought you said it was the filesystem latency though...
<Nafallo> Kamion: ahh, hardlinks for instance installer-i386/20050317ubuntu5/images/netboot/pxelinux.0? :-)
<Kamion> cjwatson@jackass:~/ftp/dists/breezy/main/installer-i386/20050317ubuntu5/images/netboot$ ls -l pxelinux.0
<Kamion> lrwxr-xr-x  1 katie katie 32 May 10 19:35 pxelinux.0 -> ubuntu-installer/i386/pxelinux.0
<Kamion> Nafallo: that's a symlink
<Nafallo> hmm. I run it with --copy-links (-L) and this: " => " shows up in the log.
<Kamion>         -L, --copy-links            copy the referent of all symlinks
<Kamion> I mirror dists/ with --links, not --copy-links
<Kamion> (and --hard-links as well, although I don't think it's necessary)
<Kamion> the reason for two passes in my script is so that I can use --links on dists/ but --copy-links on pool/
<Nafallo> Kamion: yepp, I keep --hard-links everywhere.
<Kamion> Nafallo: yes, but if you're doing --copy-links on dists/ you will mirror stuff unnecessarily
<Kamion> --hard-links is pretty irrelevant, I think; can't think of anything in the Ubuntu archive that would be a hardlink
<Nafallo> hmm, I might clean some space on my lappy and try without -n in the last step :-P.
<Kamion> as I say, try in pool/main/a/a52dec/ or something
<Kamion> rather than the entire pool
<Nafallo> Kamion: will try that now
* Nafallo tries p/ without -n
<mvo> Kamion: I assume some python-apt code for #185424 wouldn't help you? i.e. a pyhton-apt based progress thing?
<Kamion> mvo: as long as it works with only the minimal seed installed, it's fine
<Kamion> although getting at python from base-config is a tad fiddly
<Kamion> but I should be able to use debconf.py, I suppose
<Kamion> mvo: I would like to see it in apt though
<Kamion> and I need aptitude to be able to call it
<mvo> Kamion: base-config is written in perl? or sh?
<mvo> Kamion: and it then calls aptitude to do the install work?
<Nafallo> Kamion: -n didn't lie. thanx anyway. I'm probably just need to hack on it a bit more :-P.
<Kamion> mvo: mix of sh and perl; yes, it does
<Kamion> bear in mind I really want to get this into Debian (it's a long-sought feature there too, and I want to avoid further base-config forkage since it's a nightmare at the moment), and requiring python would make life awkward there since python isn't in Debian's base
<mvo> ok
<Kamion> now obviously if big parts of apt move to python then that will have to change anyway, but I don't want it to have to happen *just* for base-config :)
<mvo> apt has a very limited knowledge about what dpkg does right now
<mvo> but I agree that it really should be done in apt itself :)
<mvo> I have a fairly good idea how it could be done in python-apt, that's why I initially tried to ask about that ...
<mdz> heh
<mdz> the HP amd64 workstations which go out with FreeDOS have a "designed for Windows" sticker which looks like this: http://people.ubuntu.com/~mdz/temp/notwindows.jpeg
<Treenaks> mdz: wow, you're on a mad ltsp hacking spree?
<mdz> this has been my first chance to put some solid hours into it since UDU
<mdz> I've got thin clients netbooting all the way up to a gdm login over xdmcp
<sivang> mdz: wow cool :-)
<Treenaks> mdz: rockage!
<sivang> Treenaks: howdy btw 
<Nafallo> mdke: lol
<Treenaks> mdz: does it work /after/ that? :)
<Treenaks> hi sivang 
<mdz> Treenaks: yes, that part's easy
<mdz> it's all server-side
<sivang> mdz: the logo came crossed like this?
<mdz> sivang: yes
<sivang> mdz: amazing :-)
<sivang> mdz: how much such a machine costs?
<mdz> I'm not sure how much that one was, but an HP amd64 workstation can be had for under $1k USD
* Nafallo is away: movie(s), bbl
<Treenaks> mdz: hmm.. nice
<Treenaks> mdz: what's the type number?
<Treenaks> uh
<Treenaks> model
<mdz> I don't know what the one in the photo is
<mdz> but a650e would be one example
<mdz> (pavilion)
<Treenaks> they don't exactly go out of their way to promote freedos
<mdz> jbailey: initramfs is now the only remaining piece of ltsp client setup which is not automated
<Treenaks> mdz: you can get a dx5150 with an amd64, 256M, 48x CD drive for $559.99
<Treenaks> ex. shipping
<Amaranth> a what?
<Treenaks> Amaranth: HP amd64
<Amaranth> needs at least double the RAM, probably has a crappy HD, and integrated audio/video
<Treenaks> http://h71016.www7.hp.com/dstore/MiddleFrame.asp?page=config&ProductLineId=429&FamilyId=2045&BaseId=13463&oi=E9CED&BEID=19701&SBLID=
<Treenaks> Amaranth: no doubt.. but I'd buy it, install ubuntu and provide it as a Samba server to my clients.. if I had any ;)
<\sh> someone working on g77 for 4.0?
<\sh> ;)
#ubuntu-devel 2005-06-11
<mvo> Kamion: I put some proof of conecpt code for #185424 into michael.vogt@ubuntu.com--2005/apt--progress-reporting--0. I think we can use this as a starting point for a better interface. once I have a bit more (a OpProgress like interface or something) I'll announce it on the deity list as well
* Kamion praises the mvo machine in absentia
<jcole> i installed vnc4server, but when i add 'Load "vnc"' to xorg.conf and restart X, the xorg log says it cannot find the vnc module... any insight to this? works in debian just fine
<jcole> #apt-file search vnc.so
<jcole> vnc4server: usr/X11R6/lib/modules/extensions/vnc.so
<jcole> is this module not compatable with xorg??
<Kamion> may be bitten by the /usr/X11R6 reorganisation, if this is breezy
<Kamion> don't know the details though
<jcole> it's hoary
<jcole> has does xorg "detect" a "valid" module?
<Kamion> no idea, I'd be inclined to strace it ... :-)
<mdz> gah, I think my RAM is quitting on me
<jcole> well... is there another way to access the gdm screen on an external box?
<calc> you can always use xdmcp
<calc> its likely slower than vnc though
<jcole> calc: ah, right
<jcole> calc: ya, it exports to vnc proto
<jcole> calc: oh, wait, you said xdmcp
<calc> or ssh into the box and just do x forwarding
<jcole> calc: ewwww
<calc> works fine if you have the bandwidth ;)
<jcole> calc: well, i'll just have him log in and run x0rfbserver
<jcole> the vnc X module is quite handy though on my debian system though... i'll figure it out later on ubuntu
<wasabi> When you add "vnc" to xorg.conf?
<wasabi> Huh huh huh?
<wasabi> What's that do?
<wasabi> oh interesting. never knew about that.
<jdub> later dudes, going away for the weekend :-)
<Kamion> jdub: have fun
<wasabi> don't really like it much either.
<wasabi> gdm should really be offering a VNC server.
<wasabi> Which should let you login to a new session, or resume an existing one.
<jdub> wasabi: see mark mcloughlin's talk from guadec
<wasabi> not seeing it
<bronson> I just tried to dist-upgrade to breezy and I can't get gdm to run.
<bronson> I fixed xbase-clients.
<bronson> After GDM finishes flashing, my VGA mode is fubar.  Reboot time.
<bronson> Known issue?
<tseng> bronson: X is broken = a known issue. it will be randomly broken for some time.
<wasabi> install X from hoary if you want it workingl.
<tseng> thats silly advice
<tseng> mixing dists can break things more
<KaiL_> install everything from hoary, if you want somethink working :)
<KaiL_> somebody should try to explain the people out there, that they can't compare the ubuntu devel versions with debian/unstable
<Amaranth> i'm fully upgraded in breezy without issues
<Amaranth> but i've had daniels help me get X running a couple times
<tseng> lets not all bother daniels every 2 days please.
<Amaranth> KaiL_: They could with hoary
<KaiL_> Amaranth: ?
<Amaranth> KaiL_: hoary was relatively stable from right after xorg stabilized
<Amaranth> which was about a month into hoary, wasn't it?
<KaiL_> you can use debian/sid for daily working (more or less), but ubuntu/breezy is currently _NOT_ made for daily use
<KaiL_> for that we have hoary
<KaiL_> developers doesn't care that much, if breezy currently doesn't work - it's only important, that it'll work in October
<Amaranth> KaiL_: That's not true. It needs to somewhat work.
<Amaranth> KaiL_: If they get no testing it won't work in October.
<Kamion> I care; if it doesn't work, I can't release test CDs
<Kamion> it doesn't have to work all the time, but it has to at least go through periods of workingness
<KaiL_> Kamion: you don't expect a working test CD soon, or? ;))
<Kamion> KaiL_: it's overdue
<Kamion> KaiL_: and bear in mind I am typically not just passively sitting back and waiting for stuff to work
<daniels> mdz: tricky.  i'll have a look later today and see how it goes.
<Kamion> KaiL_: it doesn't seem productive to hassle people at this precise moment, though
<KaiL_> Kamion: that's not what I mean
<KaiL_> it's only a bit annoying to explain people in the support chats, that they can not expect, that breezy works
<tseng> its pretty effective to let them figure that out for themselves
<KaiL_> this "do NOT use breezy, if you want something stable" seams not to be big enough ;)
<Amaranth> we've started a "no help if you're using breezy" thing in #ubuntu
<KaiL_> that might help
<mdke> Amaranth, *laughs*
<Amaranth> most users are satisfied with backports
<mdke> bit harsh maybe
<Amaranth> mdke: we try, anyway
<mdke> i'm gonna try breezy tomorrow
<Kamion> KaiL_: you said "developers don't care"; that's simply not true. I'm correcting misinformation, that's all.
<Amaranth> if someone is willing to use breezy right now they really should be beyond needing help in #ubuntu
<KaiL_> Kamion: doesn't care that much
<mdke> Amaranth, well... sometimes you can get help on complex matters in #ubuntu
<Kamion> KaiL_: not true either.
<KaiL_> =if even one package in hoary is not installable, there will be a bug very very soon
<Kamion> KaiL_: I care really rather deeply. It blocks my work.
<KaiL_> if this happenes in breezy, it's something for the todo list
<Amaranth> mdke: Well, it's not like we say "using breezy? FOAD" or anything. But if they bring up problems with X, etc and they're using breezy we tell them to go back to hoary.
* mdke nods
<Amaranth> KaiL_: uninstallable packages in universe are one thing, uninstallable parts of the desktop seed are another
<KaiL_> Amaranth: you run gnome?
<Amaranth> yes
<mdz> daniels: I think the keyboard guessing should only be done on first install, and not reconfigure
<KaiL_> with kde it's WAY more fun to use breezy
<mdz> daniels: of course, that breaks the live cd
<Amaranth> KaiL_: sucks to be you then, you were warned ;)
<Amaranth> although i have most of kde installed
<KaiL_> because there are still many apps in main (!), which can't be build with gcc4
<KaiL_> afaik there's nothing done in breezy/universe...
<Amaranth> main transition finished already, didn't it?
<Amaranth> KaiL_: that's a lie
<KaiL_> Amaranth: for kde packages
<Amaranth> https://www.ubuntulinux.org/wiki/CxxLibraryList
<Amaranth> dude, i have kicker and KDE libs installed
<daniels> mdz: right.  that's the problem, is that it's a probing-type thing.  hrm.
<KaiL_> Amaranth: and?
<mdz> daniels: I consider it in a different class than hardware probing, though
<mdz> hardware probing on reconfigure makes sense to me, but re-guessing the layout (especially if they've changed it) seems counter-intuitive
<Amaranth> KaiL_: as of right now kubuntu-desktop is installable
<KaiL_> Amaranth: amarok?
<Amaranth> KaiL_: if it's a part of kubuntu-desktop, sure
<KaiL_> k3b?
<KaiL_> kscreensaver?
<KaiL_> all NOT installable
<Amaranth> k3b isn't kubuntu-desktop
<mdz> daniels: it seems like the live CD is the odd man out; similar semantics make sense for both a user-initiated dpkg-reconfigure and the LTSP case
<Amaranth> KaiL_: What is your point?
<wasabi> mdz, so what's up with java/ :)
<mdz> wasabi: I sent you some messages in this channel earlier today
<wasabi> oh
<mdz> Jun 03 10:47:17 <mdz>    wasabi: looks like libxerces2-java is the last free-java-sdk package
<wasabi> ahh ok will grab it
<mdz> Jun 03 10:21:27 <mdz>   wasabi_: I've updatedhttp://people.ubuntu.com/~mdz/temp/java-main.txt
<KaiL_> only that the kde stuff in main is still not done and afaik nobody had time for the packages in universe
<Amaranth> KaiL_: and all of those _are_ installable
<KaiL_> Amaranth: in breezy?
<Amaranth> yes
<KaiL_> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html
<KaiL_> uninstallable packages:
<KaiL_> amarok(i386)
<Amaranth> not up to date
<Amaranth> i'll believe my computer over a static web page
<KaiL_> just ran apt-get update and it's still same
<Amaranth> no offense Kamion 
<Kamion> it's hardly static
<Kamion> I just updated it, so it's current with respect to the archive
<Amaranth> KaiL_: just ran apt-get update and they're still installable
<Kamion> they so aren't
<Amaranth> synaptic is lying to me?
<Kamion> you have pre-C++-transition libraries installed locally
<Kamion> try a fresh chroot
<Amaranth> ah :P
<Kamion> e.g.
<Kamion>           Depends: kdelibs4 (>= 4:3.4.0) but it is not installable
<Kamion> kdelibs4c2 | 4:3.4.1-0ubuntu2 |        breezy | amd64, i386, ia64, powerpc, sparc
<KaiL_> bingo
<Amaranth> ah well, KDE users get what they deserve :D
<Kamion> it needs to be rebuilt once all its libraries have been transitioned
<KaiL_> amarok needs some fixes to build with gcc4
<Kamion> Amaranth: anyone assuming breezy_probs.html is bogus usually turns out to be wrong, I'm afraid. :-)
<Kamion> at least since I made it mirror at the same frequency as archive updates a little while ago
<KaiL_> k3b doesn't look much better
<Amaranth> Kamion: that explains it
<Amaranth> last time i looked at it it was out of date
<Kamion> I really doubt that
<Kamion> this was a while back
<Kamion> people often assume it's wrong if they're testing in a non-fresh chroot
<Amaranth> well, someone it said was uninstallable installed
<Amaranth> err
<Kamion> that's no proof of anything; it's looking at whether it's installable with respect only to packages currently in main
<Amaranth> how can i have packages on my system that can't be setup in a chroot?
<Kamion> it might depend on stuff in universe, or it might depend on old packages that you still have installed but that have been removed from the archive since
<mdke> anyone speak spanish?
<mdke> i was wondering what those comments on the FrontPage of the wiki mean
<Kamion> most package managers provide a facility to search for obsolete packages
<Amaranth> yeah, the only 'obsolete' ones i have around are local installs
<Amaranth> except for the one package for enigma
<KaiL_> ia32-libs << compatibility libs to run i386 on amd64?
<KaiL_> I wonder, why it lists kleopatra as not installable
<KaiL_> ah, needs gnupg2 from universe
<wasabi> Odd.
<wasabi> Xerces2 no compile.
<wasabi> =(
* wasabi goes to eat.
<daniels> mdz: mmm, I suppose.  i was thinking of a Debconf question that you could set that got reset to defaul t(e.g. do_reprobe_keyboard).
<mdz> daniels: sounds reasonable; the default would be off, and casper would set it to true?
<mdz> and it would get bumped to true on initial installs?
<KaiL_> daniels: why don't you use "radeon" as default driver for ATI R200 cards? does that also break S3 as the commercial drivers do?
<tseng> KaiL_: the ati driver loads radeon
<KaiL_> afaik you get no DRI then...
<tseng> vs loading radeon explicitly?
<KaiL_> yes
<KaiL_> and I'd like to see "dynamic clocks" autoenabled for the mobile Radeon, that brings us a lot closer to XP in run time
<tseng> KaiL_: i already asked that, supposedly it greatly kills performance for some folks
<KaiL_> I think, those can disable it, if they really care
<tseng> erm
<KaiL_> those guys will also enable fglrx and kill S3 then :)
<KaiL_> most people I know ONLY care about run time
<tseng> i think you are wrong about the ati/radeon no accel thing
<tseng> i changed to radeon explicitly and its still sucking
<KaiL_> "still sucking"?
<tseng> yeah, like 230fps
<KaiL_> that's no DRI...
<KaiL_> R200?
<tseng> in that thing that daniels will beat me senseless for calling a benchmark
<KaiL_> (meany <=9250)
<tseng> no this is a AIW atm
<tseng> 0000:01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9600]  (Secondary)
<tseng> r200 is in my laptop
<KaiL_> RV350 -> needs fglrx
<KaiL_> or the r300-beta one ;)
<tseng> oh.
<KaiL_> don't ask me, which is worse *g*
<eruin> off-topic I guess, but do any of you have a link to a good read about highlights in gcc4?
* lamont__ tries to remember what the program was for things that don't support mii-tool
<KaiL_> http://gcc.gnu.org/gcc-4.0/changes.html ?
<dooglus> hi guys.  we've been having a flood of people in #ubuntu complaining about the us.archive mirror being down.  we tried asking the ops to mention it in the topic, but they all seem to be sleeping, so I put a 'onjoin' message in my client to tell people when they join.
<dooglus> it's got rid of the people asking about the downed mirror, but now we've got a flood of people complaining about the onjoin message...  :)
<dooglus> can any of you edit the topic please?
<lamont__> in #ubuntu?
<dilinger> is that a reentrant lamont?
<lamont_r> dilinger: roaming, dammit
<dilinger> ok.  i won't use you in any threaded applications, then.
<elmo> I've dropped us.archive.u.c, FWIW, it'll time out in the next 
<elmo> I've dropped us.archive.u.c, FWIW, it'll propagate in the next ~10 mins
<elmo> speak english well do i
<dooglus> thanks lamont_r 
<lamont_r> elmo: once it's had a chance to really time out, you want to change the #ubuntu topic, or kick me and I'll do it?
<Micksa> mjg59: ping
<Micksa> if I wanted to track down STR bugs, would I be better off using hoary or breezy?
<Micksa> which one would you guys prefer bug reports for?
<crimsun> breezy is the focus
<Micksa> fucking, debootstrap won't work :(
<Micksa> I can't create a breezy debootstrap :(
<Micksa> it just won't let me do it
<Micksa> hang on... I think I might have tricked it...
<Micksa> or not.
<stuNNed> crimsun: the prob with stuff not refreshing on nautilus desktop was due to human-icons afaik
<Reza_M> What's the goal of the ServerInstall project? A derivate dist or adding some futures to the standard One-CD ubuntu?
<Ssh_rdp> I Think it is a derative distro :)
<Reza_M> So, It's very similar to SBS
<Reza_M> SmallBusinessServer
<Mithrandir> uhm, what ServerInstall project?
<Reza_M> http://udu.wiki.ubuntu.com/ServerInstallation
<Reza_M> and http://udu.wiki.ubuntu.com/SmallBusinessServer
<Mithrandir> the ServerInstallation spec is still very early, it seems.
<Mithrandir> it doesn't appear to be a derivative, just some features added
<Reza_M>  Base install only option -> rapid installation, minimal questions, auto partitioning (config file defined?)
<Reza_M>  NO GUIs on servers
<Reza_M>  Central Admin Interface -> GUI on ubuntu desktop, html/curses interface, package selection/updates 
<Reza_M> The standard One-CD Ubuntu wants to have these futures?
<Mithrandir> it has most of it already.
<Ssh_rdp> Whats the goal of ServerInstallation?
<Ssh_rdp> I cant understand
<Reza_M> I think SBS is a Ubuntu Server with some other server futures. Is it?
<Micksa> grah
<Micksa> I'm trying to get a pxe boot going to test acpi stuff
<Micksa> I can get a cramfs working with the breezy kernel, which becomes readonly at boot
<Micksa> but a normal ext2 fs won't work
<Micksa> will with the installer kernel though
<Micksa> pff
<Kamion> Micksa: current debootstrap in breezy *should* be fine for breezy ...
<ajmitch> hi JaneW 
<tseng> hi JaneW, ajmitch, *
<ajmitch> & hi sabdfl, tseng 
<sabdfl> hey ajmitch
<tseng> morning sabdfl
<sabdfl> top 'o the mornin' to ya
<ajmitch> JaneW: you pinged yesterday?
<Kamion> two months and 18 days too late? :-)
<Kamion> (top o' the mornin')
<Micksa> kamion: it's dpkg that appears to be broken.
<tseng> ah silly me, who do I bother about moving my key to main upload keyring
<Micksa> kamion: something about mmap failing
<Micksa> on /var/lib/dpkg/available
<tseng> keyring@ I guess.
<Kamion> Micksa: ! what release are you running debootstrap on?
<Kamion> I've never seen that ...
<Micksa> breezy
<Kamion> Micksa: also, /var/lib/dpkg/available could be corrupt; try 'dselect update'
<Micksa> it was size 0 at the time
<Kamion> oh, fix that with 'dselect update'. :)
<Micksa> does that count as corrupt? :)
<Micksa> okay
<Micksa> didn't know you could rebuild available
<Micksa> how dumb am I
<tseng> lamont: /proc is not mounted on x86 buildd? f-spot ftbfs
<infinity> tseng : Is now.  Giving back the package.
<\sh> lamont: ping
* infinity puts on his rubber lamont mask.
<infinity> \sh : pong
<tseng> infinity: thanks!
<\sh> hehe...
<\sh> infinity: u have a nc6000 laptop? ,-)
<infinity> \sh : Ahh, no.  It's one small way in which lamont and I differ.  And hair colour.  <nod>
<\sh> infinity: hahaha...
<daniels> KaiL_: we use 'ati' as the default because it just delegates to radeon
<daniels> mdz: that's the one; every time we tripped that codepath, we'd set it back to false, so you don't get unexpected behaviours
<daniels> mdz: sound sensible?
<daniels> KaiL_: also, enabling DynamicClocks is *bad*.  it's not just performance implications, it's that it causes a whole bunch of random laptops to just randomly lock up.
<mjg59> daniels: Do we have any idea how to enable the CRT out on Radeons or Geforces?
<daniels> mjg59: radeons should happen automatically.  nfi about geforces.
<mjg59> daniels: "Automatically" how?
<daniels> mjg59: if you start X with a CRT plugged in, it should mirror
<mjg59> What if I plug in a CRT afterwards?
<daniels> ... you lose
<mjg59> (And what if the CRT has different DDC limitations?)
<mjg59> I... see
<daniels> if the CRT has higher limitations, it'll just expand
<daniels> if the CRT has lower limitations, it should set up scrolling
<mjg59> But it ought to be possible to rip that code out of the radeon driver and implement a userspace tool to enable/disable?
<daniels> um, sort of, yeah
<mjg59> Um. "Sort of"?
<sabdfl> how do i prevent the console from blanking?
<daniels> basically you want RADEON_CRTC_GEN_CNTL and RADEON_CRTC2_GEN_CNTL fiddling, et al
<mjg59> Ok, so it's mostly just basic register setup?
<daniels> but you'd also probably need to program the clocks for that mode
<daniels> i can't speak as to how complex it might be
<daniels> the best would be a way to kick the X server, but we don't have one of those at the moment
<mjg59> Hmm. So it has different clocks for internal and external? Yeah, I guess that makes sense.
<mjg59> Ideally we want to be able to trigger on hotkey events
<daniels> mjg59: well, on a laptop, it'd probably power down the crtc if you're just using lvds
<daniels> mjg59: so you'd need to bring it up and then punch in the right parameters to get the mode you so desire
<mjg59> Yeah
<mjg59> But there's existing code that does that in the X server, right?
<daniels> theoretically you could tell it to always assume a 1024x768 CRT and use a userspace tool to just force the clocks on and off
<elmo> sabdfl: setvesablank  [guessing though] 
<daniels> but that's, um, kind of nasty
<trulux> heya
<daniels> mjg59: yeah, mostly in radeon_driver.c
<sabdfl> elmo: thanks
<sabdfl> elmo: i'm trying to debug these lockups
<mjg59> daniels: My hacky thing was going to be to use whatever the screen resolution was at the time, and let people use xrandr to set that
<daniels> heh
<daniels> crtc always on -> no battery life though
<mjg59> Yeah
<mjg59> So have the display key generate an event that checks what hardware the machine has, checks what resolution the screen currently is and then calls the appropriate userspace tool
<mjg59> Then possibly hack the screen resolution app to update that whenever the user changes the resolution
<daniels> ideally we'd be able to HAL it up and have X get kicked on display hotplug events
* daniels waves his hands some more.
<mjg59> Yes. Yes, that would be the ideal solution.
<mjg59> If you can get that into 6.9/7.0, I will love you forever
<daniels> ha ha
<daniels> you do know we're releasing in like august, yeah?
<mjg59> Yes
<elmo> sabdfl: might be worth trying a 2.6.12 kernel at some stage too
<daniels> mjg59: cool
<tseng> elmo: are you the person to bother about putting my key in main keyring?
<mjg59> (I hasten to add that I won't be writing that)
<daniels> mjg59: soft.
<mjg59> Why will Intel not release 2D specs?
<daniels> mjg59: because they hate our freedom
<elmo> tseng: if you've got TB/CC approval, mail keyring@
<daniels> ergo, terrorists
<sabdfl> elmo: thanks, seems to have worked
<sabdfl> elmo: you at my place somewhere?
<elmo> sabdfl: mossop street
<mjg59> The only public information seems to be "The 2D registers are a combination of registers based on the Video Graphics Array adapter and others that Intel has added to support graphics modes that have color depths, resolutions and hardware acceleration features that go beyond the original VGA standard"
<mjg59> THANKS, INTEL
<tseng> JaneW: probably shouldnt link "ubuntu-meeting-current" as the log for 
<tseng> JaneW: Tb/CC, it doesnt stay relevant
<sabdfl> elmo: coolio. marianne is here, we'll be around!
<Nafallo> mjg59: where do you want the answers to the testing spec? wiki somewhere?
<mjg59> Nafallo: Nowhere yet
<mjg59> I want the spec to be sorted first
<Nafallo> mjg59: oh, oki :-)
<sabdfl> hi guys
<sabdfl> my desktop keeps locking hard, running hoary
<sabdfl> mdz told me to use alt-sysrq-t
<sabdfl> but all it says is "Show status:"
<sabdfl> and nothing further
<sabdfl> gdm is not running
<sabdfl> happens with and without acpi
<sabdfl> bios hs been updated to latest version
<sabdfl> any suggestions?
<sabdfl> elmo mentioned using a serial cable
<tseng> does the harddrive light go solid?
<mjg59> daniels: Hmm. There's some code in the nv driver to switch heads, but it's not clear whether that's for dual head PCI cards or what
* mjg59 considers finding an nvidia machine and then just dumping the registers in both modes
<tseng> jbailey mentioned checking for bad blocks.. but it took forever and wasnt the issue at all for me
<tseng> so id save it for last.
* Micksa poks mjg59
<Micksa> pokes, even
<Micksa> mjg59: your blogs are entertaining
<Micksa> also
<mjg59> Haha
<Micksa> MY LAPTOP WON'T SUSPEND PLS HELP
<mjg59> daniels: Also, nvtv seems to have some code for i810-based tv out
<mjg59> Micksa: Hmm. What laptop?
<Micksa> inspiron 6000
<Micksa> so far, on resume the screen is blank, attempting to blind-type commands doesn't work but sysrq combos do
<Micksa> haven't tried with X yet :)
<mjg59> Micksa: Ok, it's quite probably IDE resume issues
<mjg59> Micksa: Can you put /var/log/dmesg up somewhere?
<Micksa> you mean after the resume? :)
<Micksa> what parts of it?
<mjg59> No, the entirity of /var/log/dmesg after boot
<daniels> mjg59: is it calling through VBE, or poking registers?
<mjg59> daniels: Poking registers
<Micksa> okay
<daniels> mjg59: intriguing
<mjg59> Micksa: Is this Hoary or Breezy?
* Micksa takes out the bits that say "mounting /mnt/pr0n"
<Micksa> breezy
<Micksa> 2.6.12
<mjg59> Micksa: Hmm
<mjg59> Micksa: Less sure, then. There's a few things that will be going in in the near future that may help
<Micksa> google search for other peoples experiences gets more or less the same result with hoary at least
<mjg59> Micksa: Does caps lock work on resume?
<Micksa> um, hang on
<Micksa> I'm in the middle of trying to set up a minimal breezy on a ramdisk so I can narrow it down
<Micksa> (yes, I want STR that badly)
<Micksa> yes, capslock works
<Micksa> c'or, 56M initrd :)
<mdke> i'm trying the colony1 install cd :)
<mdke> is it likely to pick up an acx111 wifi card?
<Mithrandir> I thought it would, yes.
<mdke> seems not mine
<mdke> np
<mdke> looks like the firmware is missing
<mjg59> Micksa: Hmm. Do you have a serial por?
<Mithrandir> mdke: ah, that would make sense.
<Micksa> mjg59: yes.
<Micksa> on a USB port replicator.
<mdke> Mithrandir, maybe there is space on the install cd for more firmware, what do you think?
<mjg59> Micksa: Oh. No, that's unlikely to work, then.
<Mithrandir> mdke: would make sense, yes.
<mdke> maybe i'll file a bug
<Micksa> I fscking NEW that would come up :)
<mjg59> Micksa: Sorry, I mean that a serial port on a USB thing isn't going to be good enough for serial debug
<Micksa> yeah, I know
<pitti> Hey
<mjg59> If you had on-board serial we could figure out how far the system's got
* Micksa ponders opening the laptop and wiring in a proper serial port, just for a few seconds
<mjg59> Hahaha
<mjg59> Irritatingly, it probably has one
<mjg59> There's an ACPI spec for debug ports, which are just serial ports without a full connector
<Micksa> oh? interesting
<sladen> Micksa: if it's a modern laptop, it'll have the pins, since otherwise MS would help with porting
<mjg59> Micksa: Do you know if any of the current Inspiron range (1200, 2200, 510m, or 9300) work?
<Micksa> I got the 8200 working
<Micksa> er. no :)
<mjg59> Ok. I'll see if I can pick up one of them to debug on at some stage.
<Micksa> am I going to get anything out of testing off a ramdisk?
<mjg59> Hmm. It's /possible/
<mjg59> It really depends where it's hanging
<mjg59> Have you tried with init=/bin/bash ?
<Micksa> hmm, not yet
<mjg59> Try that first
<Micksa> I could I guess... um...
<mjg59> Boot with init=/bin/bash and then just mount /proc and echo -n 3 >/proc/acpi/sleep
<mjg59> Then see if it resumes
<sladen> mjg59: your testing page could probably do with a ''does the display looked screwed during the installer'' ?
<mjg59> sladen: Oh, true
<Micksa> I think I tried something like that and it still didn't power up the screen again. hang on.
<Micksa> no, blank screen
<mjg59> Yeah, powering up the screen is a separate problem
<mjg59> Is the machine running, though?
<mjg59> Does ls -R / do anything?
<Micksa> no
<mjg59> Ok, so the system isn't resuming fully. Sigh.
<sladen> mjg59: oh, I had a report of a machine that didn't come up after resume, but SAK worked
<mjg59> sladen: Yes, that's generally driver resume failure of some sort
<mjg59> Usually IDE
<mjg59> Micksa: And this is the latest Breezy kernel?
<Micksa> yes, 2.6.12-1
<mjg59> On its own, that doesn't provide much information :)
<mjg59> What's the package version?
<Micksa> um, well latest as of a few days ago
<mjg59> 2.6.11.93-1.1?
<Micksa> yeah.
<mjg59> Ok. Hm.
<mjg59> Can you send me a copy of /proc/acpi/dsdt ?
<Micksa> sure. address?
<mjg59> mjg59@srcf.ucam.org
<\sh> i need someone with a hp/compaq nc6000 laptop
<Micksa> hang on.
<Micksa> I'll do whatever I can to figure this out.
<Micksa> I have the ACPI spec, and I WILL read it
<Micksa> don't make me do it, cos I will
<mjg59> It's almost certainly the kernel drivers rather than an acpi spec issue
<mjg59> With the possible exception of us not doing anything with the _GTF method
<mjg59> Micksa: Oh, did you put /var/log/dmesg anywhere?
<Micksa> no. hang on.
<Micksa> http://knobbits.org/tmp/dmesg
<Micksa> http://knobbits.org/tmp/dsdt-i6000-a06.bin
<mjg59> Micksa: Ah!
<mjg59> Micksa: SATA drive
<Micksa> sata interface
<Micksa> the drive is actually PATA
<mjg59> Micksa: Right, yes, there's a patch to make that work. I'll try to get that into the next kernel.
<mjg59> At the moment, if you have SATA it'll all blow up
<mjg59> Micksa: Ok, I'll sort out a debpatch for fabbione and we'll get that into the kernel
<mjg59> With a bit of luck you'll be able to test it next week
<Mithrandir> mjg59: if you need testing of that on amd64, I'm all ears. :-)
<mjg59> Mithrandir: Before amd64 really has a prayer, someone needs to port vbetool to use x86emu
<daniels> yeah
<Mithrandir> mjg59: how hard is that?
<mjg59> Mithrandir: Not indescribably, but not something I have time for right now
<Micksa> mjg: if you can point me at the patch I'll be more than happy to test it :)
<Mithrandir> mjg59: would I be able to do it if I suddenly was bored during an afternoon?
<mjg59> Mithrandir: Yes
<Mithrandir> ok, I might become suddenly bored, then.
<mjg59> Mithrandir: Basically, we just need a shim to convert the lirc calls into appropriate x86emu ones
<mjg59> Uh, lrmi (not lirc)
<daniels> heh, lirc
<Mithrandir> mjg59: I've just skimmed the x86emu stuff, and it didn't look unsurmountable.
<mjg59> Mithrandir: On x86, we want to use lrmi rather than x86emu. On amd64, we have no vm86 mode so need to use x86emu
<mjg59> That also gives us the DDC code for video probing on amd64 for free
<Mithrandir> mjg59: hwinfo gives us that on amd64 for free already.  I've been poking daniels to use that for a week or so now.
<Micksa> oh great, amd64 trashed vm86
<daniels> Mithrandir: i've been busy fixing your keyboard :P
<mjg59> Micksa: http://lkml.org/lkml/2005/5/23/116
<mjg59> Micksa: More usefully, http://lkml.org/lkml/diff/2005/5/23/116/1
<daniels> plus, I have some reservations about hwinfo
<Micksa> mjg59: thanks muchly
<mjg59> t
<Micksa> now I just have to figure out how to get it into the ubuntu kernel :)
<Mithrandir> daniels: that's like the five last minutes, but yes.  :-)
<sabdfl> elmo: can we use hutte to test this damn upgrade script on a production snapshot?
<sabdfl> my desktop crashed again... and again
<elmo> sabdfl: sure
<\sh> gentlemen, if lamont shows up, he should ping me
<mjg59> sabdfl: You're sure this is related to an upgrade, rather than being bad hardware?
<daniels> \sh: try emailing him, dude
<tepsipakki> shouldn't rbscrobbler already be on the archive.. uploaded a month ago?
<fabbione> hey sabdfl 
<Micksa> is there a page on "ubunto kernel package hacking" that someone could point me to? :)
<Kamion> tepsipakki: rbscrobbler |   0.0.9r-1 | breezy/universe | source
<Kamion> tepsipakki: failed to build on all architectures
<fabbione> Micksa: not really.. what do you need to do exactly?
<Micksa> add a patch to the kernel and compile
<Micksa> preferrably for just the one subarch :)
<tepsipakki> kamion: heh, sweet
<fabbione> oh you are on #u-k.. let's keep the talk there
<Kamion> tepsipakki: it's build-depending on python-dev but doing -I/usr/include/python2.3
<Kamion> needs to become python2.4-dev and -I/usr/include/python2.4, probably, but test in a clean chroot to ensure it isn't relying on other things from the unversioned python-dev
<tepsipakki> will do, exams suck
<elmo> daniels: btw, I have a desktop here where the autoconfig stuff fails to generate a working config (LCD says "out of range"), it's a recent-ish onboard intel gfx, is that already known?  [I remember you told me about something to do with intel and X, but not what] 
<daniels> elmo: hrm, out of range shouldn't happen
<daniels> elmo: using d-sub or dvi?
<elmo> d-sub
<daniels> wack
<daniels> it doesn't say what frequencies it's trying to use, does it?
<elmo> hum, I don't think it did, in the xorg.conf file at least.  helpfully, of course, I've reinstalled it headless
<elmo> I'll reinstall X and reproduce
<daniels> er, sorry
<daniels> i mean the screen when you start X
<elmo> oic, no
<daniels> ahr, damn
<daniels> log would be handy
<Micksa> dammit, WTF is pid one taken by "[swapper] "?
<Micksa> I can't pivot! :(
<sladen> is that swsuspend coming out
<elmo> dpkg: ../../main/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
<elmo> Aborted
<elmo> kmeh
<Mithrandir> why is the cdbs-simple-patchsys so _UTTERLY_ unusable?
<daniels> it bites so hard
<pitti> Mithrandir: what is so bad about it?
<pitti> Mithrandir: cdbs-edit-patch makes it quite nice, at least for me
<tepsipakki> kamion: it worked
<tepsipakki> -I/usr/include/python2.3/ -> -I/usr/include/python2.4/
<Mithrandir> pitti: it blows up when some applications or deapplications fail, then goes "NANANANANA".
<pitti> Mithrandir: oh, well, that's why it's called "simple"...
<pitti> but that only really hurts without tarball.mk
* Nafallo puts on extra socks.
<Mithrandir> pitti: it should be called "unusable" instead.
<pitti> hm, works well enough for me, given that it was not actually intended to be used, but only as an example
<pitti> Mithrandir: I find dpatch ugly, do you know whether quilt is any better?
<pitti> Mithrandir: I only ever used quilt once 
<Mithrandir> pitti: quilt gave me headaches last time I looked at it.
<pitti> Mithrandir: so what is the best one in your experience?
<Mithrandir> pitti: dbs with tarball. :P
<Mithrandir> ooo's patch system is also _really_ nice.
<Mithrandir> it actually saves a copy of the patch so you can apply patch, edit patch, unapply patch and it works.
<Mithrandir> and why did /usr/share/dpatch/dpatch-run suddenly not become executable any more?
<pitti> Mithrandir: for me I still get along best with simple-patchsys
<pitti> no things you always forget about (patch lists, executable shell snippets, and so on)
<pitti> hrmpf, network breakage
<pitti> Mithrandir: did you say anything after the "quilt headaches"?
<Mithrandir> 14:56 < Mithrandir> pitti: dbs with tarball. :P
<Mithrandir> 14:57 < Mithrandir> ooo's patch system is also _really_ nice.
<Mithrandir> 14:57 < Mithrandir> it actually saves a copy of the patch so you can apply patch, edit patch, unapply patch and it works.
<Mithrandir> 14:59 < Mithrandir> and why did /usr/share/dpatch/dpatch-run suddenly not become executable any more?
<pitti> Mithrandir: right, I replied with "maybe dpkg 2 is the final solution -> like dbs, but without the tarball-in-tarball ugliness"
<pitti> Mithrandir: I always tend to forget that e. g. warty's dpatch does not yet have dpatch-run
<doko> pitti: can dpkg 2 more than one tarball?
<pitti> Mithrandir: and I generally find the concept of executable patches ugly; it's a patch, nothing more
<pitti> but that's just me maybe
<pitti> doko: ask Keybuk :-)
<pitti> Mithrandir: dbs with tarball is not bad, but if you like that, cdbs with tarball.mk is the same and you get the cdbs magic
<pitti> doko: for now I think that the orig.tar.gz _is_ the tarball which is unpacked in a build-tree/, then the patches are applied
<pitti> doko: there is a documentation about the concept of dpkg 2 somewhere
<mako> elmo: around?
<elmo> mako: yeah
<Mithrandir> pitti: well, true, but I would like not to have tarball for small stuff like pyblosxom
<pitti> doko: http://www.dpkg.org/NewSourceFormat
<pitti> Mithrandir: yes, and at the same time you certainly don't want OO.o's patch system for that :-)
<pitti> so dear Mr. dpkg maintainer, give us a system that is sane and makes everybody happy, kthxbye :-)
<mako> elmo: so i should really upload these goofy userlinux packages..
<Mithrandir> pitti: well, true.  Just the _very nice_ property of saving applied patches and using those to unapply.
<pitti> oh, yeah; and a standard script to edit them
<Mithrandir> *shrug*; I use emacs. :)
<pitti> Mithrandir: I wrote cdbs-edit-patch to make it much less pain 
<mako> elmo: it's eezy for breezy.. but mark also wanted them for hoary
<elmo> mako: you just need to upload them to 'hoary-updates', but please check  with mdz first that they'll be accepted
<mako> elmo: did you ever add my key to the uploaders?
<mako> it wasn't there last time i tried
<SloMo_> Amaranth: i hacked something together for the smeg localization... do you want to try it?
<elmo> mako: done, now, give it 30 or so to prop
<mako> elmo: awesome, thanks
<tepsipakki> credit?-) actually it was suggested by Kamion, I just tested the build on a clean breezy-chroot =)
<tepsipakki> damn...
<tepsipakki> wrong window..
* Nafallo is away: gone chopin.
<Nafallo> dooh
* Nafallo is away: gone shopping.
<pitti> ah, I already suspected culture :-)
<tepsipakki> "chopping" would've been quite disturbing ;)
* pitti thought about the musician Frederic Chopin
* tepsipakki thought knives
<pitti> bye folks, Carmina Burana awaits me (and some stuff before) :-)
<mdke> just did a colony 1 installation on my laptop and it went excellently without a hitch
<mdke> :D
* Nafallo is back (gone 00:42:23)
<Mithrandir> Nafallo: could you please turn off public away?
<Nafallo> Mithrandir: done
* tseng notices that "ondemand" cpufreq scheduler is much nicer than whatever powernowd does
<Lathiat> tseng: indeed
<Lathiat> tseng: it also doesnt fuck up on my cpu as much
<Amaranth> SloMo_: rock!
<Lathiat> tseng: powernwd has a habbit of getting stuck on 600mhz
<tseng> Lathiat: yeah when i rip cds it goes back to 600mhz
<Lathiat> tseng: which mroe to the point is a kernel drive issue
<tseng> and takes forever
<Amaranth> SloMo_: Got the emails, I'll look in to it a little more later today.
<SloMo_> Amaranth: ok, does it work for you or haven't you tested it so far?
<Amaranth> SloMo_: Haven't tested, I'm doing other things right now.
<SloMo_> Amaranth: ok, just let me know when something breaks ;) i'll be away the next few hours
<adn> hello people
<adn> I want to build my package for hoary
<adn> hmm, wait, let us read the doc :)
<thesaltydog> Kamion, ??
<adn> I am the maintainer for Debian's p7zip, and was asked by a user to have a ubuntu version for it
<adn> is http://adn.diwi.org/ubuntu/p7zip/ OK?
<zul> adn: you might want to check on #ubuntu-adn
<zul> sorry...#ubuntu-motu
<adn> ok
<Micksa> update-pciids isn't going to actually make anything work better huh :)
<Micksa> cept lspci
<tseng> mako: ping
<tseng> mako: id like to schedule a meeting sometime about MOTU-and-Debian.
<Micksa> mmmm, throbbing windows
<SloMoSnail> Amaranth: you have new mail... just changed one thing, should be ready for inclusion now ;)
<Amaranth> SloMoSnail: A user can still just run python setup.py install and have it install with the correct locale, right?
<Amaranth> SloMoSnail: Wait, it should install them all, but yeah.
<SloMoSnail> Amaranth: right... nothing more is needed for a user
<Amaranth> rock
<SloMoSnail> Amaranth: but you have to run update-locales.sh whenever you changed/added some strings in your programm
<Amaranth> that's fine
<SloMoSnail> Amaranth: hopefully this will run under all circumstances... otherwise we probably have to add some checks
<Amaranth> still working on some other stuff, will look at it ASAP
<SloMoSnail> Amaranth: and we have another build-dep: gettext must be installed... but i think python depends on it also
<Amaranth> pbuilder will tell me
<SloMoSnail> Amaranth: ok... i'll be away until tomorrow... so when something doesn't work write me a mail or something ;)
<Amaranth> ok
<lamont> \sh: I'm not here at 6AM most saturdays..
<lamont> admittedly, noon is a bit late-ish
<\sh> lamont: sorry ;)
<\sh> lamont: r u interessted to get your nc6000 runnin properly?
<lamont> define "runnin properly" - most things seem to work :-)
<\sh> lamont: irda
<lamont> ah - irda... I am still looking (these 10 years, it seems) for something I care about that requires working irda on my laptop....
<lamont> having said that, I suppose that the purist in me is probably interested in it a little bit.
<\sh> lamont: e.g. my nokia 6100 needs to sync with my kaddressbook e.g.
<\sh> if my cell breaks, I'm lost..my cell is my pda ;)
<lamont> ah, that would tend to make one care more, wouldn't it...
<lamont> was it you that said he'd been hacking on the driver but it still wasn't happy?
<lamont> brb
<\sh> lamont: yes...but now I need someone with nc6000 who could check if a solution is working
<lamont> \sh: but testing also requires an irda device...
<lamont> although I suppose I could try having my palm send something to it.
<\sh> lamont: well, the first step will be, to test if the irda device works at all :)
<\sh> lamont: with my first test, modprobe tried to insmod smsc-ircc2 >100 times
<lamont> modprobe for what?
<\sh> smsc-ircc2
<\sh> cause I have no clue where to put the "preinstall" section for modprobe
<\sh> there r two solutions
<\sh> http://jfenal.free.fr/linux/nc6000.php
<\sh> http://people.debian.org/~pxt/nc6000/
<\sh> both extra utils are kernel 2.6.x compatible
<\sh> but both need to have adjustments...1. parport must be disabled, 2. ttyS2 has to be disabled
<lamont> hrm.
<lamont> \sh: http://www.infoworld.com/article/05/05/23/21OPopenent_1.html
* lamont looks around for Kamion or mjg59 
<lamont> that'd be the solution I'd try first... :-)
<\sh> lamont: well
<\sh> lamont: do i tell u a secret, that the irda maintainer is working at hp?
<\sh> lamont: and he didn't fix this issue in the kernel module? ,-)
<\sh> lamont: _this_ is really annoying :)
<lamont> \sh: I wonder if his boss at HP pays him to work on that module, or if he does it in what little free time is left at the end of the day...
<\sh> lamont: HP should if not already 
<dooglus> using apt-get to go from hoary to breezy I see a whole load of errors about missing locales.  is that to be expected?
<dooglus> perl: warning: Setting locale failed.
<dooglus> perl: warning: Please check that your locale settings:
<dooglus>         LANGUAGE = "en_GB:en",
<dooglus>  eventually it gets to 'setting up locales'.  would it be better to do that first?
<kent> dooglus, breezy is going to be broken lots of time before it gets stable, even more broken that that ;)
<dooglus> kent: sure.
<dooglus> kent: I just thought I'd mention it.
<dooglus> last I heard even X wouldn't start...
<lamont> dooglus: you could always file a bug about the locales errors during upgrade...
<dooglus> lamont: i'll do that.
<kent> dooglus, I dont dare to use breezy becaus of those problems.  It seem sane to use it when it freezes to perhaps find bugs etc, but during this early time I guess people things change to much.. (but im no expert though..)
<calc> daniels: i noticed in -21 you mention a symlink from /usr/lib/X11/xkb -> /etc/X11/xkb but the symlink isn't installed for some reason
<calc> very very odd
<calc> the file shows like it exists when dpkg -L xlibs-data is run
<calc> erm nevermind
<calc> its there
* calc tries to figure out what dir he was looking in before
* calc coughs after determining what he did
<calc> sorry for being blind
<dooglus> I've got a question about apt-file and dpkg giving different results.  Can you explain the different paths shown here? :
<dooglus> root@chrislap:/home/chris # apt-file search bin/mkfontscale
<dooglus> xutils: usr/X11R6/bin/mkfontscale
<dooglus> root@chrislap:/home/chris # dpkg -L xutils | grep bin/mkfontscale
<dooglus> /usr/bin/mkfontscale
<tsume> hi there
<tsume> is there a patch for the xclients? or a temp hack?
<uniq> the temp hack i used was to put exit 0 in the /var/lib/dpkg/info/xbase-clients.postinst (or preinst don't remember which one, but it's printed in the error)
<tsume> hmm, okay I'll try. Minute
<uniq> it's a evil hack to force it.
<tsume> uniq: if I already upgraded to the broken client, what am I supposed to do to fix it? a reconfigure?
<uniq> tsume: after editing the file in /var/lib/dpkg/info/ you can run dpkg --configure -a
<tsume> uniq: what line did you place the exit 0?
<uniq> at the top somewhere.. directly after set -e
<tsume> oh :) heh. How dirty
<uniq> it's very evil :)
<tsume> now I feel filty
<uniq> didn't have the time to investigate.. i basically just needed it to check that another package installed cleanly :)
<tsume> hmm
<uniq> dpkg --configure -a didn't do it? 
<tsume> no
<tsume> it starts, but X doesn't display anything
<tsume> same as before that hack
<uniq> hum.
<uniq> well.. then the hack is for the wrong problem.
<tsume> :) maybe.. its because I'm trying to run 2.6.12?
<tsume> frek
<uniq> that souldn't be a problem afaik.
<tsume> I set the driver back to nv, and now I'm getting errors for font 'fixed' again
<uniq> heh.. great.
<tsume> I already rebuilt the nvidia driver again, so I didn't think it was that. The fonts are not correct
<tsume> uniq: what do your font paths say? :) If you don't mind
<uniq> i use a even more ugly hack there.. you don't want to know :)
<tsume> I don't care :)
<tsume> I'll unhack my system later
<tsume> I had the font paths changed, but they keep changing the stupid font paths
<uniq> i run breezy in a chroot.. and started xfs on hoary.. and added tcp/127.0.0.1:7100 in breezy to make it start.
<uniq> i didn't change the paths.
<tsume> it was the paths last time, and I had to change them again
<tsume> uniq: lol. I don't like your hack
<tsume> I want to know where the font paths are in this current change
<uniq> i know. i did that too.. once. i can check the backup of my old breezy /etc
<uniq>  /usr/X11R6/lib/X11/fonts/misc  and so on.
<uniq> is the last working config i had on breezy.
<tsume> ok fixed
<uniq> did it work? 
<tsume> I needed to run mkfontdir
<uniq> ah.
<tsume> you need to edit the sh script 'mkfontdir' the program it runs is no longer in /usr/X11R6/bin
<tsume> its in /usr/bin
<uniq> then i'll unhack one of my changes too :)
<tsume> then you make each directory, and Xorg will work again
<tsume> Xorg needs the fonts.dir in each font directory, or it won't start
<tsume> I'm a mr. know it all when it comes to problems, but some problems don't take 3 minutes like this one
<uniq> then i'm mr. make it work fast. :)
<uniq> and ugly :)
<tsume> heh
<tsume> I like fixing instead of hacking
<tsume> its so easy compared to your time-wasting-way :)
<uniq> as i said, i only needed it installed to test another package.
<uniq> didn't commit my change to a cvs or anything :)
<tsume> I need the latest and greatest for real work ;)
<uniq> i use hoary for real work for now.
<tsume> heh
<tsume> well, I can't stand bugs in old software
<dooglus> tsume: is there a trick to get 'gnome-terminal' working?  It's all black for me.
<dooglus> xterm is fine
<tsume> minute
<tsume> well..
<tsume> gnome's cdburning program was broken last time, so I had to install KDE
<uniq> tsume: i need a working system until my exams are done.
<tsume> the gnome burning tool wouldn't burn all the data to a disc. I had to place less on a DVD or cd for it to burn, like about 550MB when is supposed to hold 700MB
<tsume> uniq: breezy works more for me compared to hoary
<tsume> I constantly am a person who runs in to bugs.
<uniq> i use kde :)
<tsume> person.. I guess I could call myself a gremlin. I break software by nature
<tsume> dooglus: it works for me
<tsume> though.. the text is very unreadable. Could be my res.. buyt everything is blurry
<tsume> must be crappy gnome
<tsume> they are so behind in code evolution. They are dumb asses for wanting to integrate Mono in the environment
<tsume> my card is still running decent... 2250 fps from glxgears
<tsume> gnome is basically a big waste of time :)
<dooglus> tsume: I guess the problem is that no gnome apps are working at all, just basic X stuff
<tsume> dooglus: everything works here..
<dooglus> oh, I also don't see the gnome panel, or nautilus, or anything other than the xterms I start from a virtual console.
<tsume> dooglus: I'd have to see the system
<herve> hi
<herve> do I have to replace build deps mesag-dev libosmesa6-dev
<herve> or they are still valid packages?
<tsume> looks like I use fluxbox until the best desktop is fixed
<herve> wasabi, ping
<dooglus> interestingly, using kde instead of gnome seems to have fixed almost everything.
<tepsipakki> dooglus: my breezy runs fine with gnome..
<herve> mine too
<tepsipakki> check that all the relevant processes are dead before you login
<herve> ha yes
<mako> tseng: sounds totally rasonable
<herve> that is an issue with gnome
<tepsipakki> i had to reboot my laptop today for the first time in two months, and I've been running breezy from the day it was opened ;)
<tseng> mako: great, can we set up a time?
<tseng> mako: i didnt want to just dictate one :P
<tepsipakki> the reason being that the xorg.conf had wrong font-paths and restarting it messed my console (it stilla does, but at least it's usable)
<herve> tepsipakki, I doubt laptops are designed to run 24/24
<dooglus> when I try running gnome, I just see a completely blank desktop
<dooglus> it's a uniform brown though, not the black and white pixels you sometimes see
<dooglus> and the CD light on the pc keeps flashing.
<tepsipakki> dooglus: are you logging in from gdm?
<tsume> heh, well by using fluxbox, I increase my GFX card performance by 50 frames
<Mithrandir> tsume: glxgears is not a benchmark.
<tseng> holy crap X works.
<tsume> Mithrandir: no its not, but it means gnome and kde take too much CPU
<dooglus> tepsipakki: I am, yes
<tseng> tsume: does it?
<tsume> tseng: I just was in gnome. I tried glxgears, and the fps was exactly 2233.600
<tseng> why dont you decide cpu usage based on top or ps
<Mithrandir> or flipping a coin.
<tseng> instead of FPS.
<tsume> tseng: I don't want to nice every app I use :P
<tseng> i mean that might sound good in a game review hobbyist site.. :P
<tsume> well.. with relevence to graphics
<tseng> but its not real
<tsume> yes it is
<tseng> what is gnome cpu usage relevant to graphics
<tseng> the work should all be on your GPU
<tsume> tseng: no
<tseng> thats why you spent all that money on it
<tsume> tseng: if that were true, C# would be faster/better for writing games ;)
<tseng> erm
<tseng> im running glxgears for kicks
<tseng> its barely using 20% of my cpu
<tseng> which is scaled down to 600mhz
<tseng> all the work is on the gpu, thats the entire point of DRI and all that
<tseng> "direct"
<tepsipakki> dooglus: your session might be screwed somehow. try moving .gnome2/session out of the way
<herve> and I thought #u-d was having serious discussions :-)
<tsume> barely takes any on mine, which it doesn't matter, The screen still has to maintain the screen
<tsume> s/screen/card/
<dooglus> tepsipakki: OK.  I'll try rebooting too.
<tsume> tseng: you need to think out of the box
<tseng> oh man
<tsume> tseng: you have tunnel vision
<tepsipakki> dooglus: no need to, just make sure no gconfs or gnome* is running
<dooglus> there are 2 gconfs running...
<tsume> my eyes!
<tsume> light blue sucks on a white terminal :)
<tepsipakki> dooglus: so logout, wait for a sec and if they are still there, kill them..
<herve> dooglus, the b0rked one and the one you tried later
<herve> dooglus, rebooting will help cleaning out
<dooglus> herve: maybe.  or b0rked one and b0rked two :)
<herve> the b0rked twins
<herve> the new horror movie!
<dooglus> nope, still no good.
<tsume> tseng: now.. if I loaded all kinds of apps which had all these pretty effects on the GUI. my framerate would be lower like it should be because the card has to maintain the whole screen, not just the current application
<tsume> like having the screen filled with icons which also have AA enabled for the text
<herve> big deal
<tepsipakki> as if they keep the cpu/gpu busy..
<tsume> herve: 50 frames is a big deal here :) 
<tepsipakki> a static screen consumes only your eyes
<tsume> tepsipakki: no, they don't keep it busy. They just take a bit more to render so the rate drops a bit in gears
<tseng> if you were playing a game fullscreen, xdamage wouldnt be updating all your fancy window manager effects
<tseng> theyd not be visible
<herve> tsume, remember gnome or kde are desktop envs for people working
<tseng> so your use case stops at glxgears
<herve> not for seeing gears spinning faster and faster
<tsume> tseng: heh. If the person doesn't use games? ;)
<tseng> tsume: then he needs to turn off the flash whiz bang crap and get back to work, I guess
<tepsipakki> the only thing "moving" on my screen is the clock on the panel
<tsume> tseng: heh. Well there are some scientific GL based apps.  :)
<herve> althought I'd like to see more things like cairo exploiting the capabilities of my graphics card
<tseng> tsume: are there scientify GL based candy effects?
<tsume> tseng: :)
<tseng> s/y/ic
<herve> and speeding up screen refresh
<tsume> tseng: well, there are a few models which mutate and spin
<tsume> they don't take up the whole screen.
<dooglus> aaah... it wasn't a b0rked gconfd that was causing problems, but a b0rked nautilus...
<tepsipakki> dooglus: yes, it is a gnome-specific process ;)
<herve> tseng, let's ask blender folks if their productivity falls within gnome or kde ;-)
<herve> dooglus, I thought you rebooter
<herve> rebooted
<seb128> elmo: around?
<tsume> herve: it won't since the desktop isn't showing
<elmo> seb128: yes
<tsume> herve: unless you're a goob who uses blender in window mode
<seb128> elmo: can you sort gtkhtml3.8/main for evo build if that's not sorted yet?
<herve> tsume, same in a game, so big deal if glxgears loses 50 frames
<dooglus> herve: I am just about to.
<seb128> elmo: evo is broken due to eds maj for the moment
<tsume> herve: its 50 frames :>
<herve> tsume, and you talked about tunnels?
<tepsipakki> tsume: in this case about 2%
<tseng> herve: and boxes.
<elmo> oh god damn
<elmo> who pulled in the mono stuff while it depends on insane libgal from the 1700's?
<tsume> herve: :> maybe I really need those 50 frames
<seb128> not me 
<tseng> brandon@lappy:~$ apt-cache depends mono | grep gal
<tseng> brandon@lappy:~$ 
<herve> tsume, who needs glxgears anyway?
<tseng> ?
<tsume> herve: 50 extra frames is good if I'm modifying the engine
<herve> just run glxinfo to read "direct" or not
<elmo>  o gtkhtml3.0: libgtkhtml3.0-4, libgtkhtml3.0-dev
<elmo>    [Reverse-Depends: libgnome2.0-cil] 
<elmo>    [Reverse-Build-Depends: gtk-sharp] 
<elmo> tseng: ^-- which in turn pulls in gal
<elmo> (2.0)
<elmo> seb128: done
<seb128> elmo: thanks
<seb128> hum
<seb128> we still have gtkhtml3.0?
<seb128> WTF
<seb128> there is 3.2/3.4/3.6/3.8 since
<herve> seb128, I was stuck trying to transition a package using it a while ago :-)
<tseng> ok its: libgtkhtml3.0-dev (>= 3.0.10)
<tseng> this should be made 3.8 in ubuntu?
<seb128> 3.6 or 3.8 yep
<tseng> I can do that, np
<seb128> 3.8 is really new, 3.6 is the hoary version
<seb128> thanks
<tseng> so 3.6 then?
<seb128> should be fine
<dooglus> rebooting and "adduser"ing a new user has allowed me to use gnome.
<herve> dooglus, still not your own account?
<tseng> libgtkhtml3.6-dev (>= 3.6.0)
<tseng> off we go.
<dooglus> herve: that's the next thing to try :)
<dooglus> herve: my own account is ok without my ~/.gnome2 ...
<tseng> elmo: did you process my key yet? i need to upload mono first or this will all just take a dump on ppc
<dooglus> herve: and even with my .gnome2.  excellent.  I've no idea why it wasn't working before, but thanks guys.
<elmo> tseng: no, and I'm kind of busy with a debian emergency right now, sorry - I'll try and do it later
<tseng> elmo: k. i can do it some other time then. thanks for pointing it out
* tsume chuckles at mon
<tsume> +o
* tseng chuckles at tsume 
<tseng> here, have a 2% performance hit
<tsume> tseng: beagle needs to be rewritten in C++
<tseng> C..++?
<tsume> C++ :)
<tseng> hardly.
<tsume> yes
<tsume> CLucence is nice ;)
<\sh> woot?
<\sh> beagle in c++?
<tsume> \sh: would be sort of easy since C# is a lower generation of C++
<tsume> less features, less power.. so its easy to convert the code
<tseng> man could you stop that?
* tsume nudges tseng 
<tsume> :)
* tsume just sits with a silly grin
#ubuntu-devel 2005-06-12
<tsume> ho ha!
<tsume> I gained some extra speed by turning dithering and hwcursor off :P
<dooglus> CLucene, I think you mean?
<tsume> nvidia dithering sucks.. big time. Makes the text unreadable
<tsume> dooglus: yes :)
<dooglus> (google didn't offer the "did you mean CLucene" link when I googled for CLucence, so it took me a while to find it!
<tsume> brb, tweaking gfx card
<tsume> hehe
<tsume> lolo
<tsume> dooglus: my apologies
<dooglus> after all the warnings about breezy being broken, I can't notice anything wrong with it at all, other than a few little things
<tsume> dooglus: me either
<herve> seems you missed the worst
<herve> or it's just the eye of the storm
<tsume> :'( I lost some speed just by having nvidia module render the cursor
<tsume> its glitchy if I have sw render the cursor
<tsume> s/its/the mouse/
<tsume> oh well :)
<tsume> I don't need the extra speed badly.. yet :)
<tsume> actually, now that the crappy dithering is off, the rendering is now faster in every application :)
<tsume> dithering sucks anyway. Who in the right mind wants to go blind? :)
<Amaranth> SloMo_: Almost perfect, but you put some things in for translation that the user doesn't see. For instance entry.Show == 'Empty' comes from pyxdg, that needs to say 'Empty' no matter what language you're using.
<skora> howdy.
<mdke> hi skora 
<skora> skora, hey
<mdke> hmm
<skora> do you know where I can find it at ?
<skora> k
<skora> thanks
<mdke> skora, you msg'd me the question rather than asking it in the channel
<skora> oh sorry. I thought you messaged just to me before hand.
<skora> ack, sry again.
<mdke> *laughs*
<mdke> third time lucky
<skora> i was going to put that into main chan
<skora> hello everyone, i have a question about jdong's ubp-build.py script
<dooglus> I'm new to breezy.  What should I do when I see:
<dooglus> The following packages have unmet dependencies:
<dooglus>   splay: Depends: libid3-3.8.3 but it is not installable
<dooglus> E: Broken packages
<dooglus> should I (a) grin and bear it, (b) whinge here, (c) report it as a bug on bugzilla (d) none of the above?
<zul> a and c
<dooglus> thanks.
<dooglus> I'll do that.
<mjg59> elmo: Can we get MJ Ray removed from the keyring on the grounds that I'm sure his passport doesn't call him "MJ"?
<SloMo_> Amaranth: at that position I wasn't sure ;) well but if that kind of mistakes are the only ones... ;) everything else works?
<Amaranth> haven't actually run it
<Amaranth> just looking at the code so i can merge it to my 0.8 tree
<dooglus> sorry to be a pain, but I have 2 more questions:  1) is there a separate bugzilla for breezy?  2) is it OK to report 'universe' bugs, or aren't you interested in them?
<dooglus> (I'm sure I'll become useful at some point in the future)
<dooglus> I don't see anywhere on the bug reporting page where I can specify whether the bug is in hoary or breezy
<SloMo_> Amaranth: when you merged it, can you send me a copy of your 0.8 tree? then i'll send just patches against that when i have new changes
<Amaranth> SloMo_: I'll be putting it in my berlios.de svn repo
<Amaranth> https://developer.berlios.de/projects/menueditor/
<SloMo_> Amaranth: thanks... i'll have a look at it tomorrow... and now i'll go to sleep ;)
<Amaranth> night
<spanglesontoast> bit dead in here
<Amaranth> weekend
<zul> does anyone have an adm8211 based wi-fi card?
<fabbione> morning
<pitti> Morning
<fabbione> hey pitti
<pitti> gf is still asleep -> some h4ck time :-)
<fabbione> ehheh
<\sh> morning
<pitti> uh, doko uploading xorg :-)
<fabbione> pitti: let's deroot the kernel :)
<pitti> fabbione: let's run the kernel as nobody as user process on top of HURD
<\sh> python-kde3_3.11.4+snapshot20050316-0ubuntu2_source.changes ACCEPTED
<\sh> now it goes
<fabbione> pitti: yeah i guess doko got pissed at xbase-client breakage
<fabbione> pitti: nah.. on top of OS/2 or a windows kernel
* pitti makes an ugly noise
<fabbione> goody
<fabbione> time to do the last ppc64 test build and upload
<fabbione> no actually.. it's sunday :)
<fabbione> upload tomorrow :)
<\sh> fabbione: pray before u upload (only sundays) ;)
<fabbione> jamesh: why should i pray???
<fabbione> i know these kernels won't even boot
<fabbione> but at least i can make the buildd spending some extra CPU heating and increase universe entropy
<\sh> fabbione: cause it's sunday :) the day where u normally go to church and pray ;)
<fabbione> jamesh: given that you believe in church....
* \sh is not jamesh ;)
<fabbione> ops
<fabbione> sorry
<fabbione> well time to take my wife to scouts
<fabbione> bbl
<Treenaks>  argh! why must gfloppy be so floppy-centric
<pitti> Treenaks: I thought it was way easier to hack a new pygtk app?
<Treenaks> pitti: so did I
<Treenaks> pitti: until I /looked/ at the code instead of glancing over it
* pitti didn't even glanced
<pitti> s/d$//
<Treenaks> pitti: see also: http://bugzilla.gnome.org/show_bug.cgi?id=150782
<stern_type> yeah,i'm the guy
<stern_type> they didn't intended to get me  
<ska-fan> Hmm, ubuntu should provide a free dns service like dyndns: ska-fan.ubuntu-at-home.org
<\sh> for what?
<daniels> why not just dyndns.org?
<Lathiat> or $theothertentousandofdem
<\sh> hmm...i could setup a dyndns alike service on sourcecode.de or on linux-server.org
<bob2> or use them for something cool
<bob2> or sell them on ebay!
<\sh> hmm...
<\sh> no
<\sh> linuxshop.de and linuxmall.de are for selling ;) u want them? ,-)
<ska-fan> daniels: dyndns has no hostnames with ubuntu in them :)
<bob2> register ubuntu.dyndns.org and delegate NS records
<bob2> stupid smbfs
<bob2> it flakes out every 12 hours or so
<bob2> then breaks lsof output
<\sh> hahaha
<bob2> umounting and remounting would fix it
<bob2> if I could find out what is still using it
<mjg59> Run ls -R through /proc and see where it breaks
<bob2> mjg59: it seems to succeed
<mjg59> Haha
<mjg59> lsof ought to work, then
<bob2> lsof: WARNING: can't stat() smbfs file system /mnt/ooder
<mjg59> Oh, right
<mjg59> Oops
<mjg59> Well, ls -R through /proc and look for anything with a cwd or an fd in there
<bob2> hrm
<tseng> morn AndyFitz 
<AndyFitz> yo tseng   nite here   how goes ?
<tseng> good thanks
<tseng> whats up?
<shawarma> Do any of you guys have access to the wiki database? I can't log in. I get a Unicode decode error, probably because of a Danish character in my name...
<AndyFitz> chilling on a perfect sunday mate.    hows your weekend ?
<shawarma> ..and I'd like it to be changed, so that I can log in
<mdke> shawarma, can you login at http://launchpad.ubuntu.com and change the account details?
<mdke> shawarma, ?
<shawarma> mdke: Sorry, I was away..
<mdke> np
<tuhl> Any ideas when X will wok again?
<shawarma> mdke: Yup, I can. I didn't know they used the same user database..
<daniels> it works now.
<shawarma> mdke: Thanks!
<mdke> tuhl, i tried yesterday wasn't working, but several people in #ubuntu told me that theirs is working out of the box
<mdke> shawarma, np
<daniels> if you've fiddled symlinks yourself to get stuff working, you've likely broken your system
<daniels> else, the only other issue I know of is with manually-edited configuration files
<mdke> daniels, i did a clean colony 1 install and upgrades yesterday and X would start because of a font problem
<mdke> would/wouldn't
<mdke> is it worth filing a bug?
<tseng> did you dist-upgrade?
<mdke> yes
<tseng> thats already been fixed unless you editing xorg.conf
<daniels> mdke: no, already fixed in later versions
<mdke> hmm
<mdke> i wonder why it didn't work for me
<mdke> is it uploaded?
<daniels> yes
<mdke> :/
<mdke> i tried booting in single user and doing a -reconfigure, no dice
<mdke> daniels, if it is fixed, maybe my problem was another one?
<daniels> mdke: are you getting 'can't open default font "fixed"'?
<mdke> yes
<mdke> and the system crashes
<mdke> sort of
<daniels> firstly, check which version of xserver-xorg you have
<daniels> secondly, check what the FontPath entries are in xorg.conf
<mdke> they were /usr/share
<daniels> if they're /usr/lib/X11 rather than /usr/share/X11, change 'em
<daniels> i see
<mdke> as for the version, it was the latest from the archives
<mdke> everything was up to date except a couple of packages kept back like evolution-data-server
<daniels> what version is xfonts-misc?
<daniels> er, xfonts-base
<tuhl> mdke: the xbase-clients package based on xorg is broken
<mdke> i'm afraid I can't tell you specifically, i formatted, but it was up to date
<mdke> daniels, ^
<mdke> i'll reinstall again if you think it is worth pursuing
<mdke> have some time on my hands today
<daniels> tuhl: different issue
<daniels> mdke: sure, if you want to; i can't see how it would occur, from here
<mdke> the first dist-upgrade i did didn't go cleanly. x-window-system-core didn't get upgraded due to dependency problems, then I did a second dist-upgrade and it worked fine. could that be related to the problem?
<daniels> uhm, probably
<mdke> no idea why
<mdke> it was literally a clean install from cd then straight into synaptic for a dist-upgrade
<mdke> default sources.list
<mdke> oh well
<tuhl> hi 
<tuhl> I updated to the latest X11 packages
<tuhl> X still does not start
<tuhl> Fatal server error:
<tuhl> could not open default font 'fixed';
<tuhl> obviously there is a problem with xfs
<tuhl> where does it log to?
<daniels> a) this is a #ubuntu thing, b) we don't use fs at all, and never have
<tuhl> ok
<tuhl> I was used tio ferdora sorry
<tuhl> so there is a problem open fixed font...
<tuhl> who can I fix this? by reconfiguring X?
<tuhl> what is the reason why the DISPLAY env var is not set when I login by ssh?
<\sh> tuhl: no xauth?
<tuhl> \sh: which xauth: /usr/bin/xauth
<seb128> hi
<seb128> elmo, lamont: any idea of why evolution doesn't build?
<\sh> tuhl: then ForwardX11 yes in ~/.ssh/config ?
<tuhl> \sh yes
<tuhl> in /etc/ssh/
<\sh> tuhl: so xauth is on your remote machine
<\sh> ForwardX11 yes is in your local .ssh/confi
<\sh> X11Forwarding yes
<\sh> X11DisplayOffset 10
<\sh> in your remote /etc/ssh/sshd_config?
<mjg59> Hngh.
* mjg59 stares at Acer DSDTs
<martinhj> mjg59: did a fix on my Acer's DSDT table too once (on a TravelMate 620). The question is if the fix does any real difference
<daniels> \sh: because ssh is broken
<\sh> daniels: breezy?
<daniels> you need to sudo ln -s /usr/bin/xauth /usr/bin/X11/xauth
<\sh> in hoary it works
<daniels> \sh: yes
<daniels> i filed a bug on it pre-warty
* mjg59 figures out that most recent Acers have a standard way of notifying device removal
<\sh> daniels: surprise
<tuhl> daniels: thanks
<siretart> seb128: I'm reviewing a rather old package here: http://www.metallikop.com/ubuntu/grubconf_0.5.1-4ubuntu2.dsc. The changelog states that you created 0.5.1-4ubuntu1, but this version never got uploaded to the archive. Do you remember what happened to that package?
<seb128> siretart: ??
<martinhj> mjg59: what kind of devices is in question? IDE-devices in the module-bay?
<seb128> siretart: http://lists.ubuntu.com/archives/hoary-changes/2005-January/001417.html
<siretart> seb128: yes, I'm a bit confused, too
<mjg59> martinhj: Yes
<siretart> HAE?!
<siretart> why doesn't that version appear on packages.ubuntu.com/grubconf
<martinhj> mjg59: because of the thread about laptop testing specs on ubuntu-devel list?
<mjg59> martinhj: Yeah
<tuhl> my X11 is working again after modifying the fonts paths
<martinhj> martinhj: ok, I'm the one who suggested it in to the specs. It's been a future in Windows for many years. Would love to see it in Linux too.. so Windows does not poll the ide bus or anything like that, then?
<martinhj> eh, that was for mjg59 :-)
<mjg59> Windows doesn't do it at all - the system drivers do it
<mjg59> So it's all entirely manufacturer specific
<mjg59> For the 620, it looks like it may have to be polled. The 650 has notification.
<martinhj> ok
<martinhj> is there a standard the manufacturer should follow to have notifications so one could bug the manufacturers to get them to fix the BIOSes?
<doko> seb128: evolution: spamassassin is not in main
<mjg59> martinhj: Nope
<seb128> doko: oh, they made a Depends of it? I've not noticed, thanks
<seb128> doko: are you sure? The build log complains about a e-s-d lib
<mjg59> martinhj: Not as far as I can tell, at least...
<martinhj> mjg59: I cann still open a bug if you want to
<mjg59> martinhj: Yeah, please do
<doko> seb128: at least it cannot be _installed_ for that reason
<seb128> doko: it's not even built
<seb128> doko: my local tree has it a Recommends
<seb128> doko: I don't get it
<martinhj> mjg59: under what package?
<mjg59> martinhj: The kernel for now, and cc mjg59@codon.org.uk on it
<martinhj> ok
<anto9us> is anyone involved in the ubuntulinux.org web development here? I'm not sure but I may have exposed a security issue
<doko> seb128: libecall1.2-3 is not in main
<seb128> yeah, soname change
<mdke> anto9us, you can contact the webmaster or file a bug maybe
<doko> seb128: and why doesn't libedataserver1.2-dev depend on an old db4.1-dev?
<doko> seb128: better: and why does libedataserver1.2-dev depend on an old db4.1-dev?
<seb128> doko: why not?
<seb128> doko: it uses libdb4.1
<KaiL_> daniels: where there some significant changes in the r200 driver between the one used in hoary and the one in breezy? (maybe some performance fixed backported?)
<anto9us> mdke: I don't have the time or energy and this potential exploit may already be out in the open, I've sort of accidentily revealed it in #ubuntu, can I private message you?
<mdke> anto9us, i can't do anything about it
<mdke> maybe elmo can
<mdke> anto9us, but if you have the energy to talk about it here, you should be able to write an email to the webmaster
<Mithrandir> anto9us: give me the details and I'll see if I can get the attention of our internal web people.
<anto9us> mdke: I want to know if it's something that should be worried about
<daniels> KaiL_: none whatsoever
<KaiL_> ok
<scorpix> is there's any info about the next colony release?(Colony 2)
<shawarma> What is this Colony thing? I've heard it mentioned before?
<mdke> each testing release of breezy
<shawarma> mdke: I see.
<mdke> colony is the collective noun for badgers
<mdke> (apparently)
<shawarma> mdke: Oh.. :-) Of course!
<dooglus> www.badgerbadgerbadger.com
<mjg59>         if ((device->status.present) && !(old_status.present)) {
<mjg59>                 ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n"));
<mjg59>                 /* TBD: Handle device insertion */
<mjg59>         }
<mjg59> COCK.
<dooglus> I think you need a semicolon not a period after 'COCK'
<dooglus> hope that helps.
<kent> dooglus, perhaps it is "COCK" as in F*CK? :)
<dooglus> kent: I think so
<dooglus> I imagine he pasted that code by mistake.  Perhaps he's a MicroSoft employee and that's the source code for Lornhorn, and he just gave it away by mistake.
<mjg59> No, I'm just swearing viciously at the completely useless state of the kernel ACPI support for anything other than servers
<kent> dooglus, ;)
<dooglus> I don't know much about ACPI support, but I can help you develop your swearing if you like
<daniels> dooglus: it doesn't need any form of development whatsoever
<dooglus> daniels: I beg to differ.  If he thinks that "COCK" is swearing viciously, he's got a lot to learn.  ;)
<mjg59> dooglus: You might want to check http://www.livejournal.com/users/mjg59/
<dooglus> I would like to take this opportunity to withdraw my heartless allegations of swearing-n00biness.  You are the swear master.
<mdke> *laughs*
<mdke> my god he is
<dooglus> He knows how to call Adobe Acrobat an "utter, utter cockmonkey".  That's pretty advanced stuff.
<mdke> subtle criticism
<daniels> a link not to click for the easily offended: http://www.livejournal.com/~mjg59/31005.html
<dooglus> oh, I see what you mean.  hex arithmetic.  nasty.
<mdke> his avatar is a hoodie
* mdke slaps an asbo on mjg59 
<mjg59> That is so not a hoodie
<mdke> ;)
<mdke> too late now
<dooglus> looks like a cap with flappy ears to me
<mdke> the asbo is in place
<mjg59> It's Marvin the Martian
<mdke> = hoodie
<fabbione> dpkg-deb: building package `linux-image-2.6.12-1-iseries-smp' in `../linux-image-2.6.12-1-iseries-smp_2.6.11.93-1.2_powerpc.deb'.
<fabbione> whops.. ECHAN
<bob2> mdke: I'm pretty sure he was a Martian, not a jumper
<mdke> well he is dressed appropriately for a saturday night round east london
<dooglus> mjg59: I just read your Tuesday, May 17th posting about frequency scaling.  My P4 laptop suffers thermal death regularly in Hoary, but never in Mandriva.  If I run a "while(1);" loop in Hoary, the fan will run faster and faster and after 5 minutes the laptop will power down.  Any idea why Mandriva copes and Ubuntu doesn't?
<mjg59> Is Mandriva using ACPI?
<dooglus> append="devfs=mount splash=silent acpi=ht resume=/dev/hda5"
<dooglus> that's from the Mandrake lilo stanza
<mjg59> Hmm. I'm not sure if that disables the rest of acpi or not. I think it might do.
<dooglus> I've no idea why I have acpi=ht there, but I do, and it seems to give me a system that boots and stays up.  Which is more than I can say for ubuntu :(
<dooglus> I wouldn't normally run the CPU flat out for 5 minutes at a time, but with the buggy ubuntu 'grep' I find I'm accidentally doing it quite often
<daniels> it's not buggy, it's just not very performant
<dooglus> daniels: I think it is buggy.  Taking a time that's proportional to the square of the input file size instead of proportional to the size of the input file is a bug IMHO
<dooglus> daniels: it means that it's impossible to grep through any reasonably large file, due to not having enough hours in the day
<bob2> mandrake doesn't use gnu grep?
<dooglus> it does, but gnu grep has the bug
<dooglus> on my laptop, this command runs in about half a second:    time yes | head -999999 | LC_ALL=C grep . | wc -l
<daniels> fedora has a patch to fix it
<dooglus> on the same laptop, this command runs in about 40 hours:    time yes | head -9999 | LC_ALL=en_US.UTF-8 grep . | wc -l
<dooglus> that's a bug, right?  (oops - I missed a couple of 9's from that 2nd command)
<bob2> certainly worth ranting on irc about
<dooglus> bob2: :)
<mjg59> It's not buggy. It behaves correctly at all times.
<fabbione> i see no difference here
<fabbione> it takes 0.45 secs in both run
<fabbione> actually...
<mjg59> But utf-8 is much slower to deal with
<fabbione> with en_US is faster
<dooglus> fabbione: did you try:    yes | head -999999 | LC_ALL=en_US.UTF-8 grep . | wc -l
<fabbione> yes
<HrdwrBoB> real    0m0.339s
<dooglus> (6 nines)
<fabbione> yes
<HrdwrBoB> to 0.352s
<fabbione> time yes  | head -999999 | LC_ALL=en_US.UTF-8 grep . | wc -l
<fabbione> 999999
<fabbione> real    0m0.438s
<fabbione>  time yes  | head -999999 | LC_ALL=C grep . | wc -l
<fabbione> 999999
<fabbione> real    0m0.465s
<dooglus> grep --version ?
<bob2> fabbione: do you have en_US.UTF-8 generated?
<bob2> if not, presumably it falls back to C
<bob2> en_US is fast for me, en_AU is not
<dooglus> bob2: how can you tell which locale you have generate?
<dooglus> d
<fabbione> bob2: yeps
<fabbione> i don't use en_IT :)
<bob2> heh
<bob2> dooglus: I'm guessing grep sucks with utf-8 strings?
<bob2> dooglus: cat /etc/locale.gen
<dooglus> bob2: the problem is that grep runs over the whole input file for every match it does
<dooglus> bob2: so it takes quadratic time instead of linear
<venda> can anyone recomend an IDE for Python other than IDLE
<bob2> emacs/vim.
<venda> what about apps like Komodo
<venda> boa-contructor
<venda> bob2 what about eric3
<hunger> daniels: Please fix the slave link setup for twm's manpage in its postinst script.
<daniels> hunger: i still don't see what's wrong.
<daniels> (it's also sunday night)
<hunger> daniels: You do not need to do it now, but please include it in the next upload.
<tseng> hunger: do you have a patch?
<hunger> tseng: Yes, just talked to daniels about it.
<tseng> great, thanks.
<hunger> tseng: He argues that he is doing the right thing and I have a screwed up system somehow.
<Amaranth> shouldn't apt-file depend on curl?
<martinhj> mjg59: the bug-report ok?
<mjg59> martinhj: Yup, that's great, thanks
<mjg59> I may have some extra debug stuff for you to test at some point, but no urgency
<martinhj> mjg59: post it in the bugzilla or just mail me and I can add it
<seb128> Amaranth: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307833
<Amaranth> ah, good to know
<seb128> the maintainer disagree
<seb128> is that what is good to know? :)
<Amaranth> *boggle*
<Amaranth> how the hell can he disagree? it doesn't work without it
<seb128> read the bug
<seb128> it works if you configure it to use wget
<Amaranth> which is crack, how am i supposed to know that?
<seb128> read the bug
<Amaranth> i did
<Amaranth> i like the Depends: wget | curl
<seb128> I've reopenned, that's the right way to fix it imho
<Amaranth> just because the debian maintainer is braindead doesn't mean we have to be, it should 'Just Work' on install :)
<seb128> it'll
<seb128> but that doesn't mean we should let the bug for Debian and fix it for Ubuntu
<Amaranth> no, i'm not saying that
<Amaranth> just saying if he refuses to do anything i'll be submitting a patch for a MOTU
<seb128> it's already fixed IIRC
<seb128> there is a malone bug for it
<Amaranth> malone is broken
<seb128> how so?
<Amaranth> well, the main bugs pain gives an error and you can't file bugs
<Amaranth> s/pain/page/
* hunger thinks "pain" is rather fitting here...
<Amaranth> hehe
<Amaranth> i forget what that's called
<seb128> somebody has opened #920 about apt-file
<seb128> grrr
<seb128> dup of #715
<seb128> why people never look for a bug before putting a dup
<seb128> there is like 1 bug about apt-file
<seb128> 1 search to do
<Amaranth> yeah, i opened 920
<hunger> Sep128: When I tried I could not search in malone, so I do not even try anymore before reporting a bug there.
<Amaranth> because when i clicked the link to search i got an error
<hunger> sep128: But then I do avoid reporting stuff in malone altogether and pester the people here instead;-)
<Amaranth> no specific error, malone hides it behind an 'oops' page
<seb128> works here 
<seb128> I've closed the bug
<Amaranth> https://launchpad.ubuntu.com/malone/bugs/
<Amaranth> "Sorry, a system error occurred"
<seb128> that's not a correct URI
<Amaranth> that's what the report a bug page links to
<Amaranth> at the end of reporting a bug i got that error page too, i didn't even think it went through
<Amaranth> heh, everytime you expand the 'Follow up on this comment' box the middle column gets bigger
<{Seb}> i see there has been a new xorg package accepted into breezy
<{Seb}> does this fix X?
<Amaranth> best working X i've had yet
<Amaranth> dunno if a clean install of it works though
<seb128> depending of what bug you have I guess
<Amaranth> i've got lots of symlinks and stuff still hanging around
<{Seb}> i mean the one that doesn't let you start x!
<seb128> dunno about this bug
<Mithrandir> iz gtk bug, I guess.
<seb128> I guess so
<seb128> I don't use gtk :p
* Mithrandir ^5s seb128 
<Amaranth> seb128: I somehow have trouble believing that...
<Mithrandir> Amaranth: you didn't know?  seb128 is a die-hard kde user.
<Mithrandir> he learnt that habit from daniels when daniels maintained KDE; don't use the packages you break^Wmaintain.
<seb128> (not true, I use wmaker)
<Amaranth> of course, he just packages gnome to get his fix ;)
<tseng> you should see his 48px Kicker
<Amaranth> speaking of which, you should see the setup i have for testing smeg
<Amaranth> kicker on the left side, xfce4-panel on the bottom, gnome-panel on top
<Amaranth> i need another fd.o complient menu system to put on the right
<Amaranth> ah, now i have xfce on the right, kicker on the left, and gnome-panel on the top and bottom
<daniels> Mithrandir: hey, I was using KDE when I maintained it
<Mithrandir> daniels: hmm, I thought you weren't.
<daniels> {Seb}: there are lots of bugs that used to prevent you from starting X.  if you aren't comfortable fixing them, breezy is not the one for you (and it's a #ubuntu question, anyway).
<daniels> Mithrandir: nope, only stopped using KDE early 2004
<Amaranth> daniels: welcome to the dark side
<Riddell> daniels: what made you stop?
<wasabi> eclipse is now installable.
* wasabi clap.
<siretart> wasabi: you ROCK!
<wasabi> Runs to.
* tseng sees your eclipse and raises you a monodevelop.
<wasabi> tseng, oh so you guys have UML modeling tools now?
<tseng> hah, no
<zul> burn
<tseng> we are too tough for that.
<wasabi> fold?
<daniels> Riddell: kde being uninstallable in sid, actually
<tseng> we dont need any stinking uml :P
<wasabi> how about refactoring?
<siretart> yeah, let the flameware .NET against JAVA begin ;)
<tseng> sweet/
<wasabi> No need for that.
<wasabi> I'm a C# developer in real life.
<siretart> hehe
<wasabi> Hmm. Scratch the part about it running.
<Riddell> wasabi: Umbrello
<wasabi> eh?
<Riddell> for UML
<wasabi> oh.
<ogami1972b> hello channel- i am placing a bounty on .nsv support- anyone interested?
<hunger> ogami1972b: nsv support?
<ogami1972b> streaming video- i work hard to promote linux, but online multimedia support is often a deal breaker
<ogami1972b> problems with atomfilms, shoutcast, etc
<ogami1972b> well, i'm not a rich man, but i can wash dishes, walk dogs, proofread and data entry- and hey, lady developers...;)
<hunger> ogami1972b: You must be desperate to appeal to such a minority;-)
<lsuactiafner> root@infant-finite:~ # glxgears
<lsuactiafner> glxgears: relocation error: /usr/lib/libGL.so.1: symbol gnu_dev_makedev,
<lsuactiafner> version GLIBC_2.3.3 not defined in file libc.so.6 with link time reference
<lsuactiafner> anyone know how i can solve that?
<ogami1972b> i really like linux- but my circle of family and friends are all saltwaterchimp addicts- i am certain if i could say "yes, linux supports .nsv streams", it would be a done deal
<ogami1972b> so yes- i'll do just about anything
<dooglus> is evolution broken in breezy for everyone?  I can't see my task list for example
<dooglus> I don't see any mention of it on bugzilla
<zenrox> we need a kick in #ubuntu
<zenrox> 2 kicks
<zenrox> and bans
<mdke> there are kicks and bans
<mdke> in every irc network
<lsuactiafner> please, flooder
<zenrox> please
<mdke> oh i c
<mdke> try #freenode if no one here is awake
<zenrox> thares no ops in here 
<zenrox> lol
<zenrox> thats awake
<zenrox> crap
<zenrox> hehehehe
<ivoks> k-lined
<mdke> good
<zenrox> good
<mjg59> Oh, arse
<mdke> ;)
* mjg59 watches a laptop oops on the second suspend when irda is running
<mjg59> Hngh
<mjg59> Ah. I see. It's because the second serial port mysteriously vanishes after suspend.
<schweeb> mjg59: which laptop?
<dooglus> I found that evolution wouldn't show me any of my tasks, and was generally broken
<dooglus> so I downloaded and compiled the source
<dooglus> that fixed the problem, but it's for a newer version of evolution.
<dooglus> why wouldn't the source and binary packages be of the same version?
* mez yawns
<mez> anyone here on the PGP strong set and going to be in london on thursday
<Mithrandir> mez: there are ubuntu developers living in London, so I'd assume so.
<mez> yeah, I know there are, which is whty I'm asking to try and get their attention
<mez> evening mdke :D
<mez> wtfC521097Eossible to get in the strong set without meeting anyone
<mdke> hi mez 
<Amaranth> mez: not possible to get in the strong set without meeting someone
<Amaranth> mez: it wouldn't be a very strong set
<mez> Amaranth
<mez> aspparently, some idiot signed a RobotCA's key
<Amaranth> what?
<mez> key id
<mez> C521097E
<mez> is in the strong set
<mez> http://keyserver.kjsl.com/~jharris/ka/current/C5/C521097E
<mez> It's a robot CA
<mez> hmmles
<mez> that's pretty s**tty
<mez> now should I set to not trust that key, or not trust the key signing it? (or both)
<siretart> mez: http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0xC521097E
<siretart> that key has quite a lot of signatures..
<sivang> seb128: ping
<sivang> seb128: Bon Soir, any updates about lp integration?
<seb128> pong
<seb128> no
<sivang> seb128: ah ok, it's sunday so that's explains it
<mez> yeah siretart
<mez> It's like...a robot CA
<mez> It's pathetic
<mez> I dont know if I should even let it sign mine or not
<mez> it gets me in trusted, but I feel a bit ... wrong
<zyga> hello
<zyga> I've noticed that mplayer package lacks any script that would set up RTC on system startup
<zyga> so I've written a tiny script based on skeleton file in /etc/init.d
<zyga> I've looked up the package maintainer from the .deb file
<zyga> contacted him and sent him the file along with descriptions
<zyga> however - he says that he is neither debian nor ubuntu maintainer for that package
<zyga> could anyone help me contact appropriate person?
<lsuactiafner> zyga : you linked the RTC thing somewhere?
<lsuactiafner> i want to look @ it and run it
<zyga> lsuactiafner: wait, I will
<lsuactiafner> cool thanks
<lsuactiafner> if you dont have somewhre to upload ftp://ftp.puk.ac.za/outgoing/ is 900meters from me
<zyga> http://www.suxx.pl/mplayer
<zyga> :-)
<lsuactiafner> where is .pl?
<lsuactiafner> poland?
<zyga> hmm jun not jan
<zyga> lsuactiafner: yes
<zyga> lsuactiafner: slow?
<zyga> lsuactiafner: it runs on my home adsl so it might not be zappy
<lsuactiafner> Starting mplayer RTC setup script: mplayer-rtc./mplayer-rtc: line 30: /proc/sys/dev/rtc/max-user-freq: No such file or directory
<lsuactiafner> was quick to download
<lsuactiafner> i'm on a 5k/s dailup
<zyga> lsuactiafner: hmm :-)
<zyga> lsuactiafner: thanks I'll patch that
<zyga> lsuactiafner: done, now it checks the path
<lsuactiafner> k downloadin
<zyga> lsuactiafner: are you using mplayer?
<\sh> does anybody know something about HP and Ubuntu? Do they want to show up at linuxtag?
<lsuactiafner> yeh
<lsuactiafner> Starting mplayer RTC setup script: mplayer-rtc./mplayer-rtc: line 30: /proc/sys/dev/rtc/max-user-freq: No such file or directory
<lsuactiafner> what should be in /proc/sys/dev/rtc/max-user-freq?
<lsuactiafner> hmmm
<zyga> lsuactiafner: hmm? strange 
<lsuactiafner> kernel should support it
<lsuactiafner> let me check
<lsuactiafner> # CONFIG_RTC is not set
<lsuactiafner> lol
<zyga> lsuactiafner: btw are you sure you've got the newer version?
<zyga> lsuactiafner: I've added [ -w $RTC_PATH ] 
<lsuactiafner> no idea
<zyga> lsuactiafner:  grep for version
<lsuactiafner> version of what?
<zyga> grep Version mplayer-rtc
<lsuactiafner> btw got no idea what rtc is but that its for timing and that i get the rtc error effect when i use mplayer
<lsuactiafner> # Version:      @(#)mplayer-rtc  0.1 05-jan-2005 zyga@www.suxx.pl
<lsuactiafner> hmmmm
<zyga> old one
<zyga> lsuactiafner:  strange
<lsuactiafner> proxy maybe
<lsuactiafner>  [TXT]   mplayer-rtc             05-Jun-2005 22:01     1k
<lsuactiafner> refreshing
<zyga> lsuactiafner: with rtc mplayer syncs video and audio better
<lsuactiafner>  [TXT]   mplayer-rtc             05-Jun-2005 22:06     1k
<zyga> lsuactiafner: I use default kernel and max-user-freq is 64, mplayer wants 1024
<shaya> anyone here having X fail to start when they use breezy's X?
<shaya> becaues of font problems
<wasabi> read topic
<herve> hi
<herve> I am presented a patch setting "/proc/sys/dev/rtc/max-user-freq" to 1024
<herve> how do you feel about it?
<zyga> I've asked - no one replied ;-)
<herve> hehe
<zyga> okay sorry - no one replied with concrete info
#ubuntu-devel 2006-06-05
<LaserJock> hmm, well that was something I always wondered about, but it has been on the wiki page since I used it to make my first chroot
<infinity> LaserJock: If you're doing something silly like installing sudo in your chroots... Don't... Use sudo outside the chroot. "sudo dchroot -c dapper"
<LaserJock> oh for goodness sakes
<LaserJock> now I'm all confused
<enrico> Hi.  I have just deboostrapped a base dapper.  Is there a way to kick on the installer to have it finish the installation like it had been installed from the CD?
<LaserJock> I mean I  see what your saying (sort of) but we really need to take a look at that wiki page then
<infinity> Or, for extra fun user-switching hilarity "sudo dchroot -c dapper su - someotheruser"
<sivang> what's the current ncurses way to dpkg-reconfigure loclaes?
<sivang> (i.e. it doesn't offer you to add loclaes anymore)
<infinity> sivang: Install a langpack, happens automatically.
<sivang> uh-ha! thanks!
<sivang> infinity: there a commmon script all langpacks use to do that?
<infinity> LaserJock: jbailey's been hacking on a dchroot-manager tool.  I think I'll branch his bzr archive and stuff all my years of buildd and dchroot-admin knowlege into it, and maybe people can get more use out of that than a random wiki page.
<infinity> sivang: /usr/share/locales/install-language-pack
<infinity> sivang: See the postinst for any language-pack-??-base package.
<sivang> infinity: yep , thanks, so now if I want to just add a local without having to install all the langpack data, I need to manually use /usr/sbin/locale-gen ?
<LaserJock> infinity: yes, that would be good. My biggest problem isn't so much the wiki page but that I used the wiki page when I was writing the Packaging Guide
<infinity> sivang: Yeah, though a locale with no data is mostly useless (except for the time and date formats and such, I guess)
<sivang> infinity: yes, that waht I wanted to achive, thanks.
<skingsley> I installed the new version today and its great.  I was wondering if there is a personal financial application package for ubuntu.
<infinity> skingsley: -> #ubuntu
<infinity> skingsley: This is not a support channel.
* sivang tries to find the KDE dependency in the hebrew lang-pack support packagine
<sivang> package, even
* sivang finds langpack-he-bae
<sivang> base
<sivang> anyway, time to go to sleep
<sivang> night all
<sivang> infinity: don't stay up when you don't have to :)
<sivang> are there any DC admins around?
<infinity> sivang: What needs fixing?
* sivang sorry I lied about going to sleep
<sivang> infinity: I need to have a public ssh key added to humboldt so some people can upload stuff for me there... does that fall under your domain?
<infinity> Since I don't even know what purpose humboldt serves, I'll go with "no".
<sivang> infinity: okay, thanks anyway.
<infinity> You probably want elmo/Znarl.
<sivang> yes, do you know when they should be available ?
<mdke> sivang: not at midnight on a sunday
<mdke> sivang: an rt request will get them tho
<infinity> sivang: It's only barely Monday (00:03 BST) in London right now.  Give 'em time to end the weekend.
<infinity> And yes, RT it.
<sivang> how do I RT ?
<mdke> you email rt@admin.canonical.com
<infinity> -> /msg
<infinity> Or not. :)
<mdke> ah
<infinity> mdke: I was trying to avoid that landing in Fabio's IRC logs for spam crawlers. :)
* mdke goes into that hole in the ground that has just opened
* sivang joins mdke for even trying to wake up the admins on a sunday evening at high midnight
<bddebian> Howdy folks
<mdke> sivang: this hole isn't big enough for the both of us
<sivang> heh
<Kamion> mirak: there is no way to run d-i from a running system. While I realise this is not intuitively obvious, it expects to basically *be* the operating system, and doesn't at all like something else really running the show.
<Kamion> mirak: it might be possible to fix that one day, but it's a matter of fairly serious hacking (and tackling some fundamental issues like "how do you do partitioning when a root filesystem is mounted on that disk so the kernel can't re-read the partition table?"), not just configuration
<wasabi_> Not worth it. But it'd be useful to install to another system from inside d-i.
<wasabi_> Or another partition.
<wasabi_> Or even a chroot.
<wasabi_> (ie easier than debootstrap)
<Kamion> "install to another system from inside d-i"> I don't even know what that means
<wasabi_> err. from inside an existing system.
<wasabi_> For instance, plug in my USB disk, run d-i, install to it.
<Kamion> that's what I just said to mirak was impossible and might be fixed one day, and you said "not worth it, but <apparently the same suggestion>"
<Kamion> s/impossible/currently impossible/
<wasabi_> Thought you mentioned on the root file system.
<wasabi_> Yeah, ya did.
<Kamion> at the moment it's not possible to run d-i from a running system at all
<wasabi_> Yeah. I know.
<wasabi_> n/m I'm out. ;)
<Kamion> yes, installing to a different disk would make partitioning easier
<Kamion> in that case - but that's just one of the issues
<infinity> Kamion: WTH are you doing around at this time of day, anyway?
<Kamion> infinity: can't sleep; you know the score
<infinity> Kamion: Oh, I do at that (I haven't slept since sometime yesterday), I just figured you weren't in the same boat as me. :/
<jsgotangco> good morning
<Kamion> infinity: not normally, just occasionally
<Kamion> I've been writing DebuggingUbiquity on the wiki in the hope that people will create less of a mess in my inbox over subsequent weekends. ;)
<infinity> Heh.
<bddebian> heh
* jdub hugs Kamion 
<blanky> hey guys
<blanky> can someone please point me in the right direction in making an ubuntu based distribution, any information I can look at?
<jdub> mgalvin: ping
<jsgotangco> he must be sleeping already
<jdub> mgalvin: ahr?
<jdub> oh, reconnect
<jdub> yeah
<mgalvin> jub: howdy
<jdub> aha
<jdub> he's back
<jdub> new and improved
<jdub> mgalvin: UWN moderated and posted to the fridge!
<mgalvin> version 2.0
<mgalvin> cool, thanks! :)
<tseng> jdub++
<jsgotangco> coolies
<bddebian> Heya tseng, jsgotangco
<jsgotangco> hey bddebian
<tseng> hi bddebian, jsgotangco, jdub, etc.
<Burgundavia> hey tseng
<bddebian> Hi Burgundavia
<bddebian> tseng: Back from your trip?
<tseng> bddebian: yes
<jsgotangco> hey
<tseng> bddebian: got back friday night, if you recall the spot of weather we had then
<bddebian> Aye
<tseng> pretty awful
<tseng> for flying
<bddebian> I was out shoveling dirt in it :-)
<tseng> you mean mud
<bddebian> Yeah, it was at that point
<tseng> 95 was flooded
<tseng> a bunch of people pulled off
<bddebian> Joy
<mgalvin> jdub: just so you know, i am going to try and send off those UWN issues each saturday night (my time)
<mgalvin> the sunday paper :)
<jdub> haha
<jdub> rad ;)
<bddebian> Wow, I haven't heard "rad" in ages :)
<_ion> k-rad
<bddebian> k-rad?
<infinity> k-rad, it's even better than rad.  Which 80s did you miss?
<bddebian> I try hard to forget them :-)
<hit1983> how to install tomcat ?
<mgalvin> night all
<bddebian> Ask in #ubuntu?
<bddebian> Gnight mgalvin
<_ion> To be accurate, K-rad really means "ghay-radiant".
<mgalvin> night bddebian
* _ion just woke up. I'll try to sleep one more hour.
<infinity> bddebian: http://www.urbandictionary.com/define.php?term=k-rad
<bddebian> Like totally dude
<bgertzfield> I used to be k-rad in the 80s.
<bgertzfield> I dialed in with my 1200 baud modem to a k-rad pir-8 BBS
<jdub> hrm
<jdub> where's the real install documentation?
<jdub> hrm, maybe it's on archive
<infinity> It's generated from d-i, yes.
<infinity> If you mean the verbose and very informative docs that Debian publishes with new releases.
* bddebian whips out the sarcasm detector..
<infinity> At least... I thought it was generated from d-i... Now I can't find it.
<jdub> boh, foild
<jdub> yeah
<infinity> bddebian: No, I'm not being sarcastic, the Debian install guide is generally quite useful.
<jdub> maybe Kamion kills it from our archive
<jdub> for instance
<bddebian> infinity: I wasn't sure, hence the detector :-)
<jdub> the netboot page on the wiki
<infinity> It has wonderful instructions for l33t setups like bootp+tftp, plus general info on what the different installer bits do.
<jdub> talks about setting up tftpd with xinetd
<jdub> which is like
<jdub> ... huh?
<jdub> yeah, i'm trying to point someone to the netboot docs
<Burgundavia> jdub: most of the installation guides on the wiki are hideously out of date
<infinity> jdub: Just point them to the Debian docs.  They're the same.
<jdub> oh, weird
<jdub> http://ftp.ubuntulinux.org/ubuntu/dists/warty/main/installer-i386/current/doc/manual/en/index.html
<jdub> ^ care of google (first hit)
<infinity> http://www.debian.org/releases/sarge/debian-installer/
<jdub> no doc dir for dapper
<infinity> So, we distributed it in warty, but not in dapper?... Perhaps we just deemed it "unmaintained", and dropped it.  I dunno.
<infinity> Worth poking Kamion about sometime.
<infinity> Oh, this was the more proper link:
<infinity> http://www.debian.org/releases/sarge/installmanual
<jdub> i'll pass on the breezy one
<infinity> Oh, we still published it in breezy?
<infinity> Then  Isuspect we lost it as part of the soyuz transition.
<infinity> And perhaps no one noticed.
<Burgundavia> infinity: in there any sane reason to install PH5 from source?
<infinity> Burgundavia: Not that I can think of.
<infinity> Burgundavia: There may be reason to install more extensions from source than we build, but that can be done in about 5 seconds with php5-dev and phpize, much less effort than installing the whole mess.
<Burgundavia> ok
<infinity> Burgundavia: Why do you ask?
<Burgundavia> murdering useless wiki pages
<infinity> Yeah, I don't think "installing $foo from source" where $foo is a package we ship belongs on the Ubuntu wiki at all, TBH.
<Kamion> jdub: installation-guide package
<Kamion> jdub: doc.ubuntu.com
<infinity> It belongs in upstream docs, certainly.
<Kamion> http://doc.ubuntu.com/ubuntu/install/i386/
<Kamion> mgalvin needs to kick an update to the current package, though, to get rid of 6.04 and stuff
<infinity> Kamion: Ahh, we just stopped publishing is in installer-$arch, so I got confused.
<infinity> s/is/it/
<Kamion> yes, it's not in the archive in the old style any more because the manual got rearranged upstream
<infinity> Makes sense.  Just confused the bejesus out of me. :)
<jdub> oh
<jdub> Kamion: 'cos i looked at help.ubuntu.com; didn't expect it to be on doc.
* infinity didn't know there WAS a doc.ubuntu.com until just now.
<Kamion> I think mgalvin intended to put it on help.ubuntu.com once dapper was released, iirc
<bddebian> Heya \sh
<jdub> ahr
<Kamion> http://help.ubuntu.com/5.10/ <-- 403, fun
<\sh> good morning
<infinity> Yeah, I just noticed that. :)
<infinity> help.ubuntu.com appears to need some TLC.
* jdub covers his eyes from ETOOMANYSUBDOMAIN errors
<infinity> jdub: I tihnk doc.u.c is meant to be unstable docs, for the docteam and contributors, while help.ubuntu.com is aimed at end users.
<infinity> jdub: I think...
<Kamion> that was my understanding too
<Burgundavia> infinity: you are correct
<Burgundavia> mdke_ is coordinating the switchover
<infinity> Shame that help.ubuntu.com looks nearly useless currently.
<Burgundavia> the wiki documentation is about to move to a new wiki there
<jdub> yeah, but nothiing about the subdomains themselves indicates that :)
<infinity> yeah, it should probably be s/doc/docteam/ ... Or something.
<infinity> I'd expect doc and help to be aliases to the same vhost.
* \sh kicks dm-crypt, pam-mount and his sd card...work or die *grrr8
<jsgotangco> :/
<jsgotangco> its the same machine
* jdub thinks 'doc' is not clear enough as a subdomain anyway
<jdub> like
<jdub> google will index that stuff
<jdub> and people will find it anyway
<infinity> Well, I'm not entirely sure subdomains are clear to the non-geeky at all, period.
<jdub> and the ubuntu wiki has such extreme google juice at this point, it's just going to be a massive fight
<infinity> Tell your mom to go to "doc.ubuntu.com" and watch her type "www.doc.ubuntu.com"
<jdub> Fight For The Google Juice
<infinity> She totally will.
<jdub> Only One Will...
<jdub> Be Lucky
<jdub> s/Be/Feel/
<jdub> damn
<bddebian> hehe
<jdub> better remember that for next time
* jdub feels for the doc team, this is Hard Stuff
<Burgundavia> the google juice issue is not that big, because the existing wiki is going to redirect
<infinity> In related "mom and URL" things, has anyone ever actually tried to tell someone over the age of 50 to go to "Aitch tee tee pee colon slash slash slash dot dot org" before?  Doesn't work so well.
<jdub> i would not try to expose people over 50 to slashdot
<jdub> you awful person!
<infinity> jdub: It was in the 90s, they were selling a t-shirt I liked, I've since repented.
<infinity> jdub: To make up for it, not only have I not exposed any more aging folk to slashdot, I also stopped reading it myself somewhere around 2000.
<jdub> the naughties are all about repentence
<\sh> whatever slashdot is
<Burgundavia> tseng: is there a sane reason to install Mono from source?
<jsgotangco> docteam.u.c is used for svn
<infinity> svn doesn't have to be the root of a vhost, just host the svn at docteam.ubuntu.com/svn and have the docteam website at docteam.ubuntu.com
* infinity decides to nap for a bit until London wakes up, so he's a bit more alive when he tackles Kinnison.
<dieman> heh
<\sh> why the hell it's not possible to create a i386 pbuilder on amd64 with --debootstrapopts "--arch 386"?
<\sh> whereas a simple deboostrap works out of the bocx
<\sh> s/bocx/box/
<dieman> strange
<dieman> apache died
<dieman> on my mirror
<dieman> no idea why
<infinity> dieman: Nothing in the logs?
<infinity> \sh: --arch isn't mean for cross-arch bootstraps, it's just meant for cases when "dpkg --print-installaiton-architecture" is useless (or missing completely)
<dieman> hrm, does apache restart as part of the logrotate stuff?
<dieman> perhaps it just didn't come back right 
<ajmitch> afternoon all
<infinity> dieman: Yes, it does.  If your particular installation doesn't run any modules that break on graceful, change it to reload.
<\sh> infinity: then the documentation of pbuilder is totally useless
<dieman> ahh
<dieman> thats probally what happened
<infinity> dieman: I have yet to find the "right" solution to that one, and restarting is more correct for more people, due to module breakage. :/
<\sh> pbuilder create --distribution sid --debootstrapopts --arch --debootstrapopts i386 \
<\sh>   --basetgz /var/cache/pbuilder/base-i386.tgz --mirror http://ftp.jp.debian.org/debian
<dieman> i have no idea why it wouldn't have come back up though 
<dieman> odd
<infinity> dieman: /etc/logrotate.d/apache2 -> s/restart/reload/
<\sh> and then calling pbuilder with linux32 to build
<dieman> yah
<dieman> infinity: thanks
<infinity> dieman: If it was under really heavy load, it can take too long to go down and still be running when it tries to come up.
<dieman> aha
<dieman> thats what it was then is my guess
<infinity> I *think* I can fix that problem.
<dieman> it was under heavy load still, probally
<infinity> And probably will for etch/edgy.
<dieman> infinity: http://x2218-1.nts.umn.edu/cgi-bin/gtr.northernlights.gigapop.net.cgi?log=gtr.northernlights.gigapop.net_so-0_0_0.0
<infinity> (We already wait 60 seconds for it to die, mind you...)
<dieman> infinity: see the notch at 7am? :)
<infinity> But I think I can kill it better.  We'll see.
<dieman> looks like it was doing at least 50mbps on that connection
<dieman> so it was probally doing like 75mbps only
<dieman> sunday morning is slow
<dieman> heh, its already doing 40mbps
<infinity> \sh: I'm sure it's doable, but I'm not sitting in front of an amd64 machine right now, so can't experiment.
<\sh> infinity: with a plain debootstrap it works ... but not with the pbuilder wrapper
<\sh> strange
<\sh> infinity: works means: it fetches i386 packages and not amd64 packages
<infinity> dieman: apache2's init script will haunt me until the day I die.  It just grows hack upon hack.  It's dangerously close to becoming sentient.
<bddebian> heh
<infinity> dieman: I'll see if I can make make "restart" behave better in the next (with even more AI!) version I upload with 2.0.58/2.2.0 later today/tomorrow.
<dieman> heh
<jdub> infinity: i am sad that the old apache uber-log-rotation stuff doesn't exist anymore - the one that found all log files referenced by the apache config. i guess that's harder to do with logrotate itself.
* \sh is using gentoos apaches splitlog and uses SetEnv VLOG /my/log/dir to have nifty split up logfiles. split up by date (month-year) and vhost
<infinity> jdub: I still have the scary awk that made that go, and COULD perhaps do it again, but it was a pretty ugly hack.
<infinity> jdub: It has crossed my mind, though.  The last time we saw it was, what?  potato's apache 1.3.9?
<jdub> yeah, probably
<jdub> i loved it so much though
<jdub> it was one of the 'just works' things that really turned me on about debian
<jdub> attention to detail, etc.
<infinity> Okay, why do we not have libpam-keying in the archive?  (And any bets on how soon I upload it after edgy opens?)
<infinity> No more gnome-keyring password prompts, FTW.
<jdub> what does libpam-keyring do?
<infinity> jdub: I'll consider it for etch/edgy.
<infinity> jdub: pam_keyring allows you to authenticate your gnome-keyring via PAM...
<jdub> oh right
<jdub> nice
<\sh> keyring like in gpg-keyring?
<infinity> jdub: Which, if you're uber-lazy, could just mean having the same password for login and your keyring, and doing password falthrough.
<jdub> back to logs - how would it interact with logrotate?
<infinity> Or, you could be more tricky.
* jdub wonders if we can kerberise edgy
<infinity> \sh: No, the gnome-keyring, AKA: The irritating thing that stores wifi passwords and makes networkmanager no fun on every login.
<\sh> infinity: ah...like kwallet...same problem on KDEs site of the earth
* jdub hugs g-k, shields it from infinity 
<desrt> kerberise?  like security?
<desrt> infinity; haha.  funny you should mention that
<desrt> infinity; i wrote a program today!
<desrt> http://desrt.mcmaster.ca/random/keyring-unlocker.c
<desrt> oh yah baby.  no more hatred for me.
* infinity laughs.
<jdub> i love it how people are flickring their upgrades
<infinity> pam_keyring seems slightly more "correct", but unlocking will make me happy in the short run.
<jdub> with appropriate glee and hysterics about how easy it is
<desrt> pam_keyring is dapper-incompatible
* \sh wonders, if anyone of you ever tried cryptsetup and pam-mount to create a SD card for gpg keys, which mounts automatically to $HOME/.gnupg 
<Burgundavia> jdub: except when they break horribly
<infinity> Given that the only thing I store in there is my wifi passwords, and I'm perfectly happy with those being protected by filesystem permissions, I've always been annoyed at the extra security.
<infinity> desrt: Is it?
<desrt> \sh; that's hilariously insecure
<jdub> Burgundavia: why would anyone flickr that?
<desrt> infinity; it requires pam 0.99
<desrt> infinity; dapper has 0.7something
<infinity> desrt: No, there's a version for older PAMs as well.
<desrt> oh.  neat.
<\sh> desrt: the pam mount thing, yes, it was just a technological tryout 
<HrdwrBoB> yes, it shits me having to type in my password constantly
<HrdwrBoB> although, having an airo card, it doesn't actually WORK anyway
<desrt> the real solution would be to make an SD card (or perhaps more suitably, a USB device) which does onboard RSA key operations and has a secret key which it refuses to ever give to anyone ever
<infinity> jdub: Not sure how I'd make it integrate with logrotate, or if I'd have to scrap the logrotate config and go back to cron+savelog. :/
<HrdwrBoB> desrt: yes
<HrdwrBoB> it's also more expensive
<infinity> jdub: (Not that there's anything wrong with cron+savelog, just that people like centralised log rotation)
<\sh> desrt: the other possibility would be to make crypto key smartcards work out of the box for edgy (usb or pcmcia devices included ;))
<HrdwrBoB> and potentially disastrous for the user
<desrt> HrdwrBoB; shrug.
<HrdwrBoB> because all it takes is one idiot to lose their card and they lose all their data
<desrt> HrdwrBoB; s/card/passphrase/
<desrt> HrdwrBoB; same story, really
<HrdwrBoB> don't get me wrong it's a good idea, it's just that it's a bit more onerous
<HrdwrBoB> oh, passphrase, I was thinking you weren't using a passphrase at all
<HrdwrBoB> have purely physical security 
<\sh> HrdwrBoB: funny thing is, gpg does support key smartcards and 2-4 devices to read them, to create gpg keys and rings directly. but it does not work on dapper out of the box..tried it last week
<desrt> no devices suit my needs
* desrt needs something that can handle large RSA keys
<jdub> what's hilariously insecure about keeping your private key on a usb stick? it's only slightly less secure than keeping it on your laptop (and only because the usb stick is smaller)
<\sh> desrt: well, right now, the smartcards can handle only 1024 bit keys yes
<desrt> jdub; security is a relative term
<infinity> jdub: Except your laptop has a higher chance of being stolen than a random memoery stick does, so the stick becomes more secure.
<jdub> hilarious was the relative term i was questioning
<desrt> jdub; if you put a lot of effort into something (which it sounds like was the case) then you should expect to gain a fair deal of security
<jdub> infinity: yeah, now that's true too
<jdub> desrt: sticking your gpg key on a usb stick doesn't require a lot of effort
<desrt> jdub; for the amount of effort to implement the scheme described it makes almost entirely no difference
<desrt> jdub; encrypting the filesystem and hooking up pam-mount does
<desrt> and presumably, it's on a USB stick so that you can take it places
<desrt> meanwhile, any computer you plug it into could just make a copy of it
<desrt> plus, encrypted filesystem is totally redundant to having a passphrase on the key itself
<desrt> and the instant you enter the passphrase on some other computer .... let's hope you trust their box :)
<desrt> this is what i mean hilariously insecure
<desrt> having a token that did RSA ops is more secure because the box never has a chance to copy key data from the device
<jdub> a) why encrypt it? b) why stick it in an untrusted computer?
<desrt> well
<HrdwrBoB> covers it if stolen
<jdub> rhetorical questions
<jdub> don't waste your effort :)
<desrt> if you're only going to use it with your laptop anyway why not just store it on your laptop?
<HrdwrBoB> that said, nobody steals a USB key to get the gpg keys off it
<jdub> because laptop goes walkies
<desrt> fair, i suppose.
<HrdwrBoB> and if they are, they're going to be good, and are likely to get it anyway
<desrt> i've never lost a laptop.  i've lost a few usb devices....
* jdub has the laptop to show for laptops-go-walkies too :)
<jsgotangco> a usb stick is more likely to be reformatted once taken than a laptop
<desrt> jdub; when your laptop got stolen did it have key data on it?
<jsgotangco> (and also depends on the location where it was stolen i guess)
<\sh> let's have a short reminder: UBZ
<HrdwrBoB> a laptop running linux is going to be reformatted if stolen
<HrdwrBoB> that's pretty much ti
<desrt> \sh; but the noodles were SOOO good
<jdub> desrt: yes
<desrt> forever in my mind those noodles will be associated with jeff's laptop being stonel
<desrt> *stolen
<desrt> jdub; did you revoke?
<jdub> no
<desrt> good man
<\sh> desrt: for one day: absolutely 
<jdub> i'm a bad person, etc.
<desrt> ya right
<jdub> i don't bother with keysigning crap either
<\sh> desrt: and ajmitch
<jdub> just makes my eyes glaze over
<desrt> i promise you the person who stole your laptop (or the person they sold it to) booted it up, scratched their head for a moment, then reached for a windows install CD
<jdub> "wait -- i could be FISHING!!!"
<HrdwrBoB> desrt: no wa
<HrdwrBoB> way
<jdub> "wait -- i could be reupholstering the sofa!!!"
<HrdwrBoB> the person who stole it likely fenced it for some smack
<HrdwrBoB> and that person sold it to some other guy 
<desrt> HrdwrBoB; that's considered selling.  see above :p
<HrdwrBoB> and THAT person installed windows
<jdub> "wait -- i could be regrouting the shower!!!"
<infinity> jdub: I just had the most perverse idea to integrate it into logrotate, using "include" in unholy ways.
<desrt> HrdwrBoB; i use 'sold it to' under transitive closure :)
<jdub> infinity: elite!
<jdub> infinity: you can include the log definition?
<jdub> OH!
<jdub> of course you can
<desrt> jdub; you will sign my key at guadec.
<HrdwrBoB> desrt: yeah I skipped that part because it was in brackets, I would like a replacement parser please
<jdub> you're a sicko - good idea!
<infinity> jdub: Have a dummy rotatio directive that rotates nothing but runs a script that generated an include dir full of logrotate snippets, then include that directory.
<nomed> hi all
<infinity> jdub: It feels very, very wrong, and potentially fragile, but worth toying with before I dismiss it.
<Burgundavia> jdub: what is the mugshot repo again?
<desrt> people.ubuntu.com/~jdub/edgy
<jdub> deb http://people.ubuntu.com/~jdub/edgy/ ./
* \sh will only sign keys when I see an identity card of the "Transnational Republic"
<Burgundavia> cheers
<nomed> i'm connected using ssh to a breezy box .. i need to run a debootstrap .. but i get a really strange error :
<jdub> NOT THAT I AM RUNNING EDGY YET
<nomed> W: Failure trying to run: chroot /home/nomed/chroot mount -t proc proc /proc
<desrt> i heard edgy opened
* desrt gets excited
<nomed> is this a known issue ?
<Hobbsee> jdub: hehe.  of course not.
<desrt> nomed; #ubuntu is a better place for this question
<nomed> desrt, do u really think they can help me on this ?
<nomed> i've not seen even a bug on debootstrap in launchpad ..
<desrt> heh.  you could try #debian
<nomed> i can try anyway
* desrt asked a debootstrap question in #debian once and when i told them i was trying to install ubuntu they kickbanned me
* infinity goes to get his nap on before Kinnison wakes up.
<nomed> desrt, ehehe
<infinity> desrt: #debian is less than friendly, and not entirely representative of the project.
<infinity> desrt: When most DDs hop into #debian to help out, they end up leaving again within minutes.
<\sh> #debian moved to oftc anyways
<nomed> anyway it looks really strange ...
<jdub> infinity keeps mixing up his words
<jdub> he meant
<desrt> infinity; this was also back in the warty days when people weren't yet sure about if they hated ubuntu or what
<jdub> "#debian is less than friendly, and entirely not representative of the project."
<nomed> i can't even use mount as root on that "chroot chroot/" ..
<infinity> jdub: I meant the former, actually, but the latter certainly has more spin.
<infinity> jdub: I'm willing to admit that some DDs are nearly as hostile as #debian. :)
<\sh> nomed: sudo mount -o bind -t proc /proc /bla/chroot/proc doesn't work?
<infinity> jdub: Just not the project as a whole.
<nomed> \sh it works ..
<jdub> http://www.threadless.com/product/435/Blog
<desrt> what happened to mjg59?
<desrt> he used to be so much more angry
<desrt> he's all docile now
<infinity> He grew up a bit.
<nomed> the problem is that debootstrap uses mount within the chroot
<infinity> Now he's only angry when drunk.
<desrt> i enjoyed his omnipresent mean-streak
<\sh> nomed: well, it worked for me in breezy times, and works well in dapper times to create even hoary chroots ;)
<nomed> \sh, yep .. it works for me even on others breezy box ...
<nomed> and i can't figure out what's wrong there ..
<\sh> nomed: support answer no. 1 in windows IT: Please reinstall your OS ;)
<nomed> "googling" .. i've seen it 's an issue that exists ..
<nomed> \sh, i'm in italy and that's in belgium ..
<nomed> i'll ask them anyway what they did on that machine ..
<nomed> thanks you all anyway
<\sh> nomed: check the sources.list for any debian repositories ;)
<nomed> \sh, just breezy ...
<nomed> checked already ..
<\sh> http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html he is so right
<whiprush_> \sh: you were looking for me earlier?
<desrt> that article is extremely boring
<desrt> when you make a claim like that you better have the goods to back it up
<desrt> and he failed to deliver
<desrt> 6:             int mid = (low + high) / 2;
<desrt> 7:             int midVal = a[mid] ;
<desrt> that's one huge array if mid might overflow
<\sh> whiprush_: yes
<\sh> whiprush_: when I remember, you gave a talk about mass deployment of ubuntu desktops via kickstart, right?
<whiprush_> yeah
<\sh> whiprush_: do you have the presentation online somehwere?
<jsgotangco> that would be neat
<whiprush_> on my laptop, I can throw them up on the web when I get to work (about 9 hours from now)
<\sh> whiprush_: rock :) thx :)
<\sh> desrt: he said this
<\sh> desrt: but I see his article as proof of concept...it can happen anywhere in the world of binary sorts. it's the same assumption like (int)(64bit-64bit) == 32bit ;)
<kagou> hi
<mdke_> 04:06:25 < infinity> Shame that help.ubuntu.com looks nearly useless currently.
<mdke_> infinity: what's wrong with it?
<glick> hi
<glick> is anyone here
<glick> hello?
<HiddenWolf> mdke: it's a bit spartan
<HiddenWolf> glick: if there is something you'd like to discuss or ask, just do so.
<mdke> HiddenWolf: are you talking about the content?
<HiddenWolf> mdke: both content and presentation.
<glick> yeah is it purposefully that in .bash_profile if ~/bin exists it is prepended to your current PATH, shouldnt it be appended? i thought this was a potential security hole
<mdke> HiddenWolf: right. Can you send your suggestions to the ubuntu-doc mailing list please?
<HiddenWolf> mdke: I'll take a look and mail the list. :)
<HiddenWolf> I was about to wait untill the wiki got transferred.
<jsgotangco> hmm maybe a one page, mulitple page html tgz download would be helpful too
<jsgotangco> and a pdf tgz
<mdke> I'm just amazed that it could be described as "nearly useless"
<HiddenWolf> mdke: You'll not hear me say that
<mdke> pretty harsh critique of 6 months work
<mdke> 8*
<HiddenWolf> mdke: help.ubuntu has saved me literally dozens of explanations, it's very convenient to link to from irc. :)
<\sh> glick: where is the security hole? 
<jsgotangco> mdke: its not the content actually, its more of the presentation i'd say
<glick> \sh, in .bash_profile
<glick> \sh, shouldnt ~/bin be appended to the $PATH instead of prepended?
<\sh> glick: you mean prepending ~/bin ? i don't see any security risk there
<\sh> glick: because it should be just you who have access to your home
<glick> \sh, what if root account is installed and root issues a su in my home directory and i happen to have my own version of su there
<\sh> glick: to be honest, if you have your own su in your home, i would be wondered
<glick> or i go to someones computer and put a .bin with a sudo version that will send me me his password
<glick> oh yeah and a cd version that wont show the bin directory
<\sh> glick: then you had hacked his computer already
<glick> \sh, no not really
<\sh> glick: or this someone is really stoopid
<jsgotangco> mdke: i can hardly believe the the frontpage is 6 months work ;)
<glick> means i walked up to his computer in his user account, and am waiting for the root password
<giftnudel> \sh: well isn't the point rather, that it's easier to place something in ~/bin then in /bin?
<\sh> giftnudel: yes, but I wonder if someone is really so careless and let others on their homedir
<HiddenWolf> \sh: most people have a homedir for "dad" and one for "family"
<giftnudel> actually, it's kind of pointless anyway (as I realize now) if you have access to someones homedir, you can easily change his or her path
<\sh> giftnudel: the other way around, the first user has only sudo rights, so if he has an own version of sudo in his dir, he is responsible ;)
<giftnudel> hehe
<\sh> HiddenWolf: yes, but mostly dad is sudo master, and family is just using the computer, so dad can do what he wants anyways
<mdke> jsgotangco: the site is, as you know.
<glick> \sh, here is another senario
<giftnudel> so I don't think it's more insecure then appending it, since you just have to modify .bash_profile to PATH="~/bin:"$PATH or seomething similar
<glick> if you have a root account installed
<glick> admin comes over to my terminal, does a su
<looksaus> is there a way to get strikethrough text in the wiki? probably not, I suppose?
<jsgotangco> mdke: i think its just a matter of tinkering with the frontpage that is all
<glick> instead of a su -
<giftnudel> glick: this is the admins fault
<HiddenWolf> \sh: usually in a family the kids are in control of the computer, and can do what they want untill dad's work gets whiped out.
<\sh> glick: if admin has root account, he would use username: root as login name and does a chown <your user> afterwards
<\sh> glick: if admin has brain, he uses his useraccount and does a sudo because he can trust himself
<giftnudel> glick: I see your point, but I don't really think it matters that much
<\sh> glick: if admin is braindead, he's at fault
<\sh> HiddenWolf: that's the reason why families have "kids computers" and "dad computer named laptop" ;)
<HiddenWolf> \sh: chuckle
<giftnudel> glick: if you have access to someones homedir, replace the icon to the terminal with one that logs su & passwords and you are done too
<giftnudel> shortcut I mean
<\sh> HiddenWolf: no really...I'm dad, I'm root, that's the law ;) 
<\sh> HiddenWolf: and kids have a playstation
<HiddenWolf> ;)
<\sh> HiddenWolf: and when the kids are old enough they get their own computer to destroy ;)
<Hobbsee> \sh: that's a great way to run things :)
* Hobbsee destroyed her old laptop.
<\sh> speaking of brainded....
<giftnudel> glick: the following will do in .bashrc (or _profile): export PATH="~/bin:"$PATH and you have the same result
<\sh> how can someone destroy automake magic and remove DESTDIR support from it
<roh> hi there
<HiddenWolf> hey vuntz, what is the libgnome-applet soc project going to do, is there a proposal somewhere?
<roh> i'm searching for someone from the i386 kernelteam to discuss a bug. yeah ive read the topic, but since #ubuntu is scrolling rather fast noone there seems to has his hand in that packages
<HiddenWolf> roh: you can try #ubuntu-kernel 
<roh> ah thanks
<sivang> morning all
<Hobbsee> hey sivang 
* sivang hugs Hobbsee 
<sivang> Hobbsee: 'sup ?
* Hobbsee hugs sivang in return
<Hobbsee> i have to go to work soon - contemplatign dinner before or after it..
<ajmitch> before
<Hobbsee> hehe.  sounds simple.
<Hobbsee> ajmitch: crackers make good pre-dinner?
<ajmitch> no
<Hobbsee> too bad.
<Hobbsee> :P
<vuntz_> HiddenWolf: libgnome-applet is about creating a library making it really easy to write applets
<vuntz_> HiddenWolf: it will contain some widgets doing nearly all the work
<iwj> pitti: I was expecting those CVEs for firefox 1.5.0.4 ...
<iwj> Do you want me to dig them out myself from the mozilla.org release notes, or do you have some top secret source of your own ?
<Kamion> Keybuk: does udevplug ever exit non-zero?
<Keybuk> I don't think so, no
<Keybuk> it used to if the timeout happened, but that caused problems
<Kamion> ok, thanks - just investigating bug 48257
<Ubugtu> Malone bug 48257 in ubiquity "hw-detect mysteriously exits 1" [Normal,Unconfirmed]  http://launchpad.net/bugs/48257
<Keybuk> ah, no
<Keybuk> sorry
<Keybuk> it still does exit 1 if the timeout happens
<Kamion> the logs pinpoint the mysterious exit rather close to the end of the script, and udevplug is one of the few things called in there
<Kamion> (there are some others)
<Keybuk> ask them whether it took ~3 minutes
<Kamion> worth a try, asking, thanks
<ogra> hmm, is fabio on holiday already ? 
<iwj> Things shouldn't exit nonzero without stderr output.
<iwj> (Unless specifically requested eg diff --silent.)
<Kamion> Keybuk: btw, bazaar.launchpad.net doesn't seem to serve the same stuff from within the DC as it does from without, which is kind of problematic for seeds
<Kamion> Keybuk: try http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/xubuntu.edgy/ from rookery
<sivang> Kamion: that's the new place for edgy seed stuff?
<Kamion> sivang: will be, but isn't yet - an announcement will be sent out with details once it's all working
<Kamion> part of the point being to enable non-Canonical-employees who are ubuntu-core-dev members to commit to the seeds
<Keybuk> Kamion: this is a known bug, the thing that makes the http side uses an old bzr that doesn't support knits
<Keybuk> Kamion: it'll be fixed in the Tuesday rollout
<Kamion> Keybuk: um, but it displays something different from outside the DC (it doesn't 404)
<Keybuk> Kamion: yeah, it's a bzr repository with the knits missing ;)
<Keybuk> https://launchpad.net/people/ubuntu-core-dev/+branch/ubuntu-seeds/xubuntu.edgy
<Keybuk> /!\ Launchpad could not mirror this branch at 2006-06-04 19:20:03 BST.  The error was: [Errno 21]  Is a directory
<Keybuk> etc.
<Kamion> <cjwatson@cairhien ~>$ wget -S -O /dev/null http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/xubuntu.edgy/ 2>&1 | head | grep HTTP/1
<Kamion> cjwatson@chinstrap:~$ wget -S -O /dev/null http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/xubuntu.edgy/ 2>&1 | head | grep HTTP/1
<Kamion>   HTTP/1.0 200 OK
<Kamion>   HTTP/1.1 404 Not Found
<Keybuk> oh, I see what you maen!
<Keybuk> sorry
<Keybuk> I thought you were on about that the HTTP published stuff is entirely devoid of revisions
<Kamion> oh, no, I sort of expected that
<infinity> One of you needs to change the length of your nick...
<Kamion> :-)
<infinity> Watching a conversation between two people whose 6-character nick starts with "K" is very confusing.
<ajmitch> just slightly
<Keybuk> Kamion: that's damned strange, isn't it
<Keybuk> it's the same machine
<Kamion> I'm assuming the apache config is a bit borked
<Kamion> I think I'll just file an RT request about it
<ogra> infinity, just use a proper chat client, Kamion is green for me and Keybuk is blue in xchat ;)
<mdke> is there something strange about the dns servers in the datacentre? Apparently my blog is giving a 404 to the machine that servers planet, but the dns was changed last friday, and seems to have propagated everywhere else
<mdke> servers/serves
<thom> colours are evil, kthxbye
<infinity> ogra: I can do without multicoloured coworkers.
<ogra> thom, purist !
<ogra> infinity, well, its less confusing to have themm coloured :)
<infinity> Sure, and even less confusing to have them all associated with little cartoon characters, so we should all switch to MS Comic Chat!
<InfraRed> MS comica chat rocked
<InfraRed> # APPEARS AS ANNA
<\sh> whatever ms comica chat is...
<StevenK> \sh: Think IRC, but every line is a cartoon cell.
<ajmitch> a very worrying program
<\sh> StevenK: ah ok....then I don't need it...I have a cartoon every morning when I look in the mirror, that's enough of cartoons for the day ;)
* ogra wonders how that would look on release day in #ubuntu
<\sh> ogra: hmmm...like a manga comic? "crash bang boom" with wide open big eyes and whining japanese teenagers singing "Heidi, heidi"?
<ogra> well, might be, i doubt you could even read it because the pcs get replaced to fast :)
<ogra> *pics
<k3mper> hi, where can i get source package of dapper's default kernel image (i386)?
<\sh> k3mper: apt-get install linux-source-2.6.15
<\sh> k3mper: or you want the real source debian package which you get with apt-get source linux-image-2.6.15-23-<arch>
<k3mper> linux-source gets me 2.6.15.7-ubuntu1 but uname -r = 2.6.15-23-386
<ogra> and #ubuntu for such questions please
<\sh> oh yes, i forgot
<k3mper> ogra: i tried for 'few' minutes
<ogra> k3mper, still, this isnt a support channel
<Keybuk> who knows stuff about openssl?
<ogra> Keybuk, well, fabi made our certificate package ... i be he does a bit ...
<zul> heylo
<ajmitch> hey zul 
<zul> hey ajmitch 
<ajmitch> what's up?
<zul> [root@mail2 vqadmin] # vim .htaccess
<zul> [root@mail2 vqadmin] # /etc/init.d/httpd restart
<zul> Stopping httpd:                                            [  OK  ] 
<zul> what the hell
<Keybuk> ?
<Keybuk> you told it to restart
<Keybuk> did you mean "reload"? :)
<zul> meh..
<zul> need coffee or stronger
<ogra> httpd ? 
<zul> redhat
<ogra> ah
<ubijtsa2> the "restart" stanza often does '$0 stop ; $0 start'
* ubijtsa2 needs more tea vicar..
<sivang> yay
<sivang> network is working again
<holycow> !restricted
<holycow> ah we don't have ubotu here?
<holycow> k
<sladen> holycow: this is #ubuntu-devel, not #ubuntu
<mirak> hi
<sladen> mirak: hi. isn't it beautiful weather here today
<KaiL_> ..bah, the Wiki sucks
<mirak> it's cloudy
<mirak> in there, but it's hot
<mirak> sladen: where do you live ?
<sladen> mirak: London.  Occasionally.
<abattoir> Kamion: hello :) . I'm working on the Kubuntu OEM Installer. https://launchpad.net/distros/ubuntu/+spec/kubuntu-oem-installer
<abattoir> Kamion:do you think the spec needs any modification?
<sladen> mirak: you could ask kamion if there's a replacement for base-config rather than doing  passwd ; tzconfig ; echo ... > /etc/apt/sources.list
<Kamion> no there is no replacement for base-config at present
<abattoir> Kamion: and also, Riddell pointed me towards https://launchpad.net/distros/ubuntu/+spec/kubuntu-oem-installer
<mirak> Kamion: why was it dropped ?
<abattoir> sorry, http://people.ubuntu.com/~cjwatson/bzr/oem-config/mainline/menu/
<Kamion> abattoir: it's bizarre that stage 1 and 2 of your proposed design are that way round
<abattoir> Kamion: but that doesnt seem to have the files the 'oem-config' package in main does.
<Kamion> abattoir: go up a level
<Kamion> mirak: because it sucked horribly
<Kamion> mirak: doing it all in the d-i first stage is much, much better in the general case; yes, it does mean that it's a little harder to bootstrap a system without d-i though, but hopefully that can eventually be fixed
<mirak> d-i ?
<abattoir> Kamion: It was suggested that i first create a KDE Dialog-based oem-config, like the current GTK one first...
<mirak> Kamion: ?
<Kamion> mirak: debian-installer
<abattoir> Kamion: and then work on changing it to look somewhat like how i had shown in the mockup
<Kamion> abattoir: the code needs to have a decent frontend/backend separation first (your stage 2); only then will it be sanely possible to glue a KDE interface onto it
<Kamion> abattoir: to do that, I think it'll be necessary to totally upend oem-config and make it be laid out a bit more like ubiquity internally. I hope to do that fairly soon.
<Kamion> because that will help the gtk frontend a lot
<Kamion> at present you have to mess about with a large pile of different source packages
<abattoir> Kamion: how can i help in doing that :) ?
<Kamion> abattoir: I don't know, can you? look at the code :)
<abattoir> Kamion: I have already looked at the code.
<Kamion> might be easier to just have me do that bit though
<KaiL_> I guess, the "CommunityEdgyIdeas"-Page needs to be Split into several pages to reduce conflic#ts
<Kamion> since it's a major rearrangement touching bits of d-i
<abattoir> d-i:debian-installer?
<Kamion> abattoir: yes
<Kamion> abattoir: I suppose you could be working on the UI code for the KDE frontend in the meantime
<abattoir> Kamion: so how do you see the UI going?
<iwj> Kamion, mdz: re firefox 1.5.0.4 into dapper-updates: I don't really think we have much of a choice so we should just do it ?
<abattoir> something like my mockups?
<Kamion> abattoir: I'd remove e-mail and display picture from that UI markup; they don't seem to belong there
<iwj> (Last time we reviewed the patch, discovered that it was full of junk, and decided to proceed anyway.)
<abattoir> Kamion: ok, i thought so :)
<Kamion> (because the installer doesn't have anything to do with that stuff)
<Kamion> abattoir: I'd try to keep it moderately consistent with ubiquity's KDE frontend, personally
<abattoir> Kamion: also Riddell suggested that it was too 'stylised' so he asked me to send the mockup to mdy, which i did.
<Kamion> really mdy? you sure he didn't mean mpt?
<Kamion> mdy is a Canonical business type; mpt is our usability person
<abattoir> Kamion: he said mdy was Canonical's usability person
<Kamion> he misspoke
<abattoir> Kamion: oh ok.
<abattoir> Kamion: and about Stage 3?
<abattoir> Kamion: do you think that is unnecessary?
<Kamion> abattoir: I have no opinion on that; it's beyond the scope of oem-config at present
<Kamion> kinda like a project in two totally separate pieces
<abattoir> Kamion: ok. So i should start work on a KDE UI similar to ubiquity right?
<pygi> Keybuk, poke :)
<Kamion> abattoir: that's just how I'd approach it :)
<abattoir> Kamion: thanks a lot :)
<Kamion> I think I might try to glom all the bits of the oem-config gtk interface into one big glade file rather than the separate windows we have at present
<Kamion> separate windows means the UI tends to jump around a lot
<abattoir> Kamion: I'll hang around here, just tell me if you can when the backend is doen, or if i can be of any help :) 
<sivang> Kamion: or use notebooks to do layering
<Kamion> I may have a look at it this week if I finish the specifications I need to write
<Kamion> sivang: indeed, that's what ubiquity does
<Kamion> sivang: but that implies one big glade file
<abattoir> Kamion: ok.
<sivang> Kamion: right :)
<Kamion> damnit, why do the people who do the screenshots for shots.osdir.com try hard to avoid the advanced partitioner?
<\sh> KDEs advantage is that you can have notebooks (tabs) in one ui file and the widget forms in other files ;)
* sivang notes it's so nice to have the machine lock for few milliseconds every once in a while under high IO load. thanks lenovo for your super genious PATA-SATA bridge !
<\sh> Kamion: because they don't know how to use the advanced part of the partitioner?
<Kamion> \sh: doesn't really make a lot of difference if they're all in one package; the reason I had separate glade files was because they were in different packages, but that's turned out to be counterproductive
<Kamion> \sh: that seems unlikely; they are just trying to present the simplest path. it's kind of unhelpful when you're trying to research partitioner UIs though
<\sh> Kamion: well, the widget form itself will be an object of it's own...so you can handle it very dynamically
<mdz> iwj: how does pitti feel about it?
<Kamion> \sh: *shrug* no real benefit
<\sh> Kamion: it has when you do it the right way...it's better then to try to fill in qt/kde code into gtk lines
<Kamion> ok, can we please stop this conversation now? it is not helpful
<Kamion> you don't know the code
<\sh> Kamion: ubiquity? 
<Kamion> oem-config
<\sh> Kamion: no not oem-config, but ubiquity :)
<sivang> \sh: heh, I found this to complement the link I've sent you yesterday - http://slashdot.org/articles/06/06/04/2151244.shtml
<\sh> sivang: ah...I know that I forgot something...
<\sh> brb
<sivang> \sh: heh
<izm99> if I want to use a custom program with gnome-volume-manager, how do I do that?  I checked the gnome-volume-preferences command and it passes "%h" (which turns out to be a dbus message) to gnome-volume-manager-gthumb.  I just want the directory....
<izm99> aha.  found it.  `less /usr/bin/gnome-volume-manager-gthumb`  :)
<izm99> "hal-get-property"
<Riddell> mdz: can I upload this to dapper-updates? http://kubuntu.org/~jriddell/tmp/guidance.diff
<Riddell> I'll s/dapper/dapper-updates/ first of course
<mdz> Riddell: sure, let me know when it's in the queue and I'll approve it
<Keybuk> pygi: 'sup?
<pygi> Keybuk, just wanted to know what's going to happen with n-m this release
<pygi> is there gonna be any new upstream release or something?
<Keybuk> pygi: I'm not the person to ask
<pygi> Keybuk, hm,oki, who then? :)
<Keybuk> I'm not going to suggest any further integration work for edgy
<Keybuk> because I don't think n-m is mature enough, or, indeed, the Linux wireless stack is mature enough
<Keybuk> so my gut is that the only n-m changes in edgy will be getting it up to date and roughly in sync with any Debian packages that materialise
<pygi> ok, thanks for the answer :)
<Keybuk> as to whether or not there's a new upstream release, you'd be best off asking upstream :)
<pygi> indeed :P
<iwj> mdz: pitti seems to have been assuming that we'd do it as a matter of course, but I haven't had specifically this conversation with him.
<pygi> hm, just ran into this (considering i know we have one student working on samba configuring)
<pygi> http://www.gnomefiles.org/app.php?soft_id=1386
<iwj> I just had a conversation where he said `I'll send you some CVE's for the changelog' and I said `yes please'. 
<mdz> iwj: it's a holiday for him today, I believe; let's talk about it tomorrow
<Riddell> mdz: kde-guidance uploaded
<Riddell> mdz: what's the plan for gnome in dapper-updates and should I look at putting kde 3.5.3 there?
<ploum> hello
<mdz> Riddell: depends on what's in it
<mdz> Riddell: seb128 and dholbach uploaded the conservative parts of 2.14.3
<bddebian> Howdy folks
<Riddell> mdz: kde 3.5.3 hasn't been very conservative, so I think best to leave it then
<iwj> mdz: Ahh. OK.
<ploum> If I was seb128, I would have uploaded 2.14.3 with tons of bugs just before going on holliday
<Kamion> let us be thankful that you are not ;)
<bddebian> heh
<mdke> is 2.14.3 even on the horizon yet? 2.14.2 was only released last week
<\sh> ploum: lol...you mean improving the flying cars to fly even to the moon? ;)
<ploum> \sh: far beyond !
<ploum> You know, the kind of stories who begin with "In a galaxy far far away.."
<ploum> ;-)
<\sh> ploum: yes
<jsgotangco> hey sabdfl
<\sh> hi sabdfl
<ajmitch> hello sabdfl 
<ploum> hello
<ajmitch> ploum: but will the flying car have a pony?
<bddebian> Hello sabdfl :-)
<ploum> ajmitch: yes but not yours
<ajmitch> heh
<ajmitch> how sad
<zul> hi sabdfl 
<sabdfl> hello all you freedom fighter
<sabdfl> s
<sivang> hey there sabdfl 
<ploum> so for Edgy, we target the solar system. The entire galaxy for edgy+1   \sh, any idea of what will be next ?
<thom> ploum: a galaxy far, far away
<_ion> Well, the neighbour galaxies of course.
<\sh> ploum: sure, it's been the rest..
<ploum> of course..
<ploum> so, now that we have the plans
<_ion> After the whole universe, there are all the parallel universes.
<highvoltage> multiverses
<ajmitch> _ion: yes, multiverse
<pygi> ploum, ergh, parallel universe ? :)
<ogra> ploum, ubuntu works differently, you start in the universe far far away and work your way to the center of core-dev
<pygi> _ion, you got it before me :P
<ajmitch> ogra: where to from there?
<\sh> ajmitch: linus best buddy is the next step to perfection ;)
* pygi is happy because his application if first on gf :P
<ajmitch> \sh: nah, I'm a GNOME user ;)
<pygi> gnomefiles* :)
<\sh> ajmitch: see ;)
<jsgotangco> we keep on looking forward to beyond our solar system yet we still don't know what lies beneath our earth and oceans maybe some organisms that need ubuntu love heh
<ploum> aaarh ! too frustrating ! We are talking about conquering the whole universe, I can nearly feel it in my hand...
<ploum> but I have to finish my thesis first
<pygi> jsgotangco, indeed ;)
<ploum> jsgotangco: proud member of ubuntu-deep-oceans local team
<highvoltage> it will be harder to find ploum when he gets lost in the multiverse though.
* ploum will start ubuntu-mars
<jsgotangco> or ubuntu-middle-earth even!
* highvoltage will start his own planet with planetplanet :)
<bddebian> Tatooine
<ajmitch> jsgotangco: already got that
<pygi> We should really make that game that was proposed by one student for SoC
* ajmitch thinks this is getting slightly OT
<jsgotangco> ajmitch: no living in NZ doesn't apply :P
<ploum> highvoltage: I'm never hard to find. Follow the bad jokes...
<pygi> RPG where Ubuntu devs are "monsters" and you chase them down :P
<bddebian> haha
<ploum> must be a scary game
<pygi> bddebian, was really proposed by someone :)
<jsgotangco> i will definitely run when i get to face boss fabbione
<bddebian> That's too funny
<ploum> imagine : you are in a dark corridor.. little scary music and... suddenly !
<ajmitch> jsgotangco: a wise choice
<bddebian> jsgotangco: No kidding eh :-)
<ploum> Awesome ! Awesome !
<ploum> The terrible jdub monster with big eyes !
<jsgotangco> that's easy to beat
<ploum> (the "awesome" was the noise of the monster of course)
<_ion> The boss monster has to be sabdfl, naturally. You'd fight him in space.
<jsgotangco> you just need a bit spear with a shield bearing the KDE logo
<jsgotangco> s/bit/big
* pygi wonders why he even mentioned it :P
<bddebian> Yeah, nice going pygi :-)
<Hobbsee> hehe
<ajmitch> pygi: because you want to drag us all away from hacking on edgy
* Hobbsee wonders if she's stepped into an alternate channel
<Hobbsee> ajmitch: 
<Hobbsee> ajmitch: and this is a problem?
<pygi> ajmitch, lol :)
<bddebian> Is Edgy open already?
* Hobbsee has her first upgrade, waiting to go into the repos :P
<pygi> bddebian, nop I think :)
<Hobbsee> bddebian: silly!  you'll have to wait another two days for it to open now!
<_ion> Note to self: ask about Edgy tomorrow.
* bddebian whips out his MOTU Vorpal Weapon +5
<Hobbsee> bddebian: now dont make me get out my pitchfork :P
<bddebian> heh
<bddebian> TB Meeting tomorrow at 20:00?
<jsgotangco> bddebian: you've been playing too much Elder Scrolls lately
<pygi> bddebian, yup, If I am not mistaken
<pygi> lemme check
<bddebian> jsgotangco: Outlander ;-)
* bddebian is still debating whether to go to meeting or not. :-(
<pygi> bddebian, yes :)
<ploum> back to work
<ploum> bye
<mdz> Kamion: I presume you'll deal with accepting this kickseed upload yourself?
<Kamion> mdz: oh, yeah, can do - infinity said over the weekend that there was some problem with binary uploads to -updates so I was waiting to hear that that had been resolved
<mdz> Kamion: oh, hadn't heard about that
<jono> hey
* Kamion frees his last remaining installer branches from the clutches of baz
<Kamion> thank Christ for that
* ajmitch cheers
<mdz> Kamion: did Keybuk tell you about relocating the seed branches?
<Kamion> mdz: yes
<Kamion> waiting for Tuesday's LP rollout and a firewall fix in the DC to make it all work right
<Kamion> mdz: I'm very tempted to propose the no-more-devfs spec for edgy
<Kamion> if there's any release where it might actually get cleared out of the way, it's this one
<tritium> I'm installing from desktop CD behind a corporate firewall, and it appears the "Configuring apt..." step isn't going to timeout.  Is this true?
<mdz> Kamion: as you like
<Kamion> tritium: it will timeout *eventually* - may take a while though
<sladen> Kamion++
<tritium> Kamion: okay, thanks, it finally did.  Now same thing scanning the mirror.  If I set the proxy preference in the LiveCD session, will ubiquity use it?
<Kamion> unfortunately not; there are open bugs about it
<bddebian> Heya tritium
<Kamion> if you preseed mirror/http/proxy, it might honour that
<Kamion> (not 100% sure)
<tritium> No problem.  Thanks :)
<tritium> hi there bddebian
<Kamion> but it's more likely than any other option
<Kamion> I'd be interested to hear about it if preseeding mirror/http/proxy does work; you can e.g. boot the desktop CD and just put 'mirror/http/proxy=http://your.proxy:8080/' on the kernel command line
<tritium> hmm, let me write that down so I can try it...
<tritium> I'll try that Kamion, and report back to you later on.
<\sh> jesus, one upload
<bddebian> ??
<\sh> kde-guidance ;) 
<bddebian> Ah :-)
<Kinnison> Hi guys
<ajmitch> hello
* Kinnison will have to stop the buildd master in a bit for some maintenance patching which should get *-updates binaries working again
<Kinnison> just thought i'd warn you
<Kinnison> Then I'll get something on the job of re-processing the incorrectly rejected binary uploads
<bddebian> Hello Kinnison
<Kinnison> Sorry it has taken so long to resolve this
<bddebian> You should be ;-P
<bddebian> j/k
* Kinnison inverts bddebian and pops his head into a bucket of cold custard
<bddebian> Doh
<bddebian> Oh, mmm, vanilla :-)
<sivang> hehe
<robertj> isn't it a bad idea to send out links to non-locked wiki pages to announce?
<sladen> robertj: only be people trash them
<sladen> s/be/if/
<sfllaw> Hmm.  I lsot e-mail and I can't get it back.
<sfllaw> That's lousy.
<Kinnison> heh
<tritium> Kamion: I tried it as you suggested, but it does not work.
<jsgotangco> good night
<Kamion> tritium: oh well
<Kamion> thanks for trying
<tritium> no problem, Kamion.  Thanks for the suggestion!
<sivang> sfllaw: don't you have a backup ? :)
<sfllaw> sivang: The machine seems to have fallen off the Internet.
<sivang> sfllaw: ah, I see so no access at all? :-/
* Kinnison is reprocessing the failed binary uploads now
<Treenaks> 1
<ajmitch> 2
<pitti> Treenaks: 0!
<ajmitch> pitti!
<pitti> hey ajmitch 
<Treenaks> pitti: yeah, forgot the 'alt' there :)
<\sh> frohe pfingsten pitti
<pitti> \sh: gleichfalls!
<Treenaks> Tip of the day: don't go to Rome on weekends like this, it's packed ;)
* Treenaks just got back
<\sh> Treenaks: no wonder...all those catholic people want to see a german pope ;), we are pope and we are soccer ;)
<ajmitch> hehe
* \sh is asking for sanctuary at "Transnational Republic" for the time being ;)
<Treenaks> \sh: all you need now is the pope to bless the German team ;)
<\sh> Treenaks: hehe...oh well, germany won't win the championships...never 
<Treenaks> \sh: I don't really care who wins, as long as it isn't the Dutch
<\sh> join #ubuntu-anti-soccer
<Treenaks> ;)
<tseng> Treenaks: i thought you were dutch
* tseng hides behind \sh
<Treenaks> tseng: I am, but I hate football/soccer ;)
<zul> i think the americans are going to win ;)
* \sh hates soccer as well
<\sh> women beach volleyball is the sport...sitting in front of the tv and watching the sexy players ;)
* ogra thiks hating is way to much attention ... he just ignores soccer
<mjg59> \sh: Please don't alienate community members
<\sh> ogra: hey, i was born in dortmund, so I hate soccer by law..there are only 10 types of people in dortmund, soccer lover or soccer hate
<\sh> mjg59: alienate?
<Treenaks> \sh: with sexist comments, probably
<\sh> mjg59: whom?
<ajmitch> \sh: we've been known to have ladies around these parts..
<\sh> my apologies to all ladies in #ubuntu-devel 
<mjg59> \sh: Objectifying members of a group is a good way of alienating other members of that same group - I'm sure that's not what you actually meant, but it helps to perpetuate a vague atmosphere of this as a boys club, rather than an inclusive community
<\sh> mjg59: agreed
<mjg59> Let's keep this place welcoming :)
* bddebian "GROUP HUG" :-)
<_ion> Are there a lot of female developers who play beach volleyball professionally?
<LaserJock> wow, that's a niche group if ever I've seen one :-)
* highvoltage joins in group hug
<\sh> looks like that I need to buy some beers 
<highvoltage> JaneW plays volleyball well.
* \sh plays sometimes volleyball, too....so
<\sh> highvoltage: btw...how is the weather down in za?
<highvoltage> \sh: fabulous. we're having an indian summer. the last three days have been the best weather we've been having the last two years. sunny, no wind, no clouds... just right.
<\sh> highvoltage: jealous...but at least I found my biltong dealer ;)
<dieman> 
<dieman> ~/
<Keybuk> sabdfl: ping?
<G0SUB> pitti: hello!
<pitti> hello G0SUB 
<G0SUB> pitti: PM?
<pitti> G0SUB: mail perhaps? I have some RL stuff to do right now (I'm on holiday today)
<G0SUB> pitti: that's fine. see you tomorrow then :)
<pitti> G0SUB: great!
<G0SUB> pitti: I have started writing down my design ideas
<pitti> G0SUB: oh, nice; mvo and I shall look at it tomorrow
<G0SUB> pitti: that'd be great. I have a lot of things to discuss with you guys
<G0SUB> pitti: see you tomorrow then :)
<sivang> ah, good wifi at last
<tuhl> hi all 
<bddebian> Hello tuhl
<tuhl> is there any long term strategy for replacing the gnome system tools within ubuntu?
<Burgwork> tuhl, what do you suggest replacing them with?
<bddebian> kde system tools ;-P
<Burgwork> lol
<tuhl> as far as I see these tools are not maintained
<mjg59> tuhl: No
<Keybuk> tuhl: there is not
<mjg59> tuhl: If there is effort that would go into reimplementation, it should instead go into those tools
<Keybuk> please feel free to write a specification and register it in our spec tracker about what kind of strategies are available
<Keybuk> if you're up for doing the work, so much the better
<Burgwork> tuhl, yet another rewrite is madness
<bddebian> tuhl: What makes you say they are unmaintained?
<tuhl> I think the area of config tools is one of the weakest point within current distros
<Burgwork> yes, because each distro writes their own
<tuhl> bddebian: no news @http://www.gnome.org/projects/gst/news.html
<Burgwork> if they polled and worked on one for each DE, we would be in a much better place
<Burgwork> s/polled/pooled/
<sivang> tuhl: those tools are maintianed by Carlos Garnacho, if you take a peek at the code base there you you can see why it would be to reimplement them
<sivang> tuhl: *non trivial
<tuhl> What is Marks opinion on that topic?
<tseng> you could ask mark
<tseng> ah, he's left
<Burgwork> tuhl, I see commits to gnome-system-tools from 4 days ago
<sivang> Burgwork: carlos is working hard on these tools , thats no surprise
<sivang> Keybuk: would you know what would cause my eth0 (non wifi) to stop working every 5 minutes and force me to manuall run dhclient ?
<Keybuk> no
<sivang> (I installed n-m few days ago, but then saw how it configures dead wifi access and stops my work so I purged it and everything extra it dependend on)
<sivang> weird
<sivang> man, it just happened again
* sivang is lost
<sivang> hmm, at least when I leave it idle it doesn't halt
<giftnudel_> sivang: yes, dhcp?
<sivang> giftnudel_: what about it?
<giftnudel_> may that be a cause
<giftnudel_> I have a similar problem, I get messages in syslog showing an attempt to reconfigure every 300 sec
<giftnudel_> sivang: now I wonder why every 300 sec
<giftnudel_> sivang: I thought it was the dhcp server, but it sounds like it could be my problem
<sivang> giftnudel_: interesting, that seems to be the problem here as well.
<sivang> giftnudel_: yes, I can confirm now. that's interesting, I also got ipw2200: Firmware error detected. one time
<giftnudel_> me too
<giftnudel_> sivang: I also have an ipw 2200 wifi
<sivang> giftnudel_: I wonder how to make that recurring dhcp attempt stop
<giftnudel_> sivang: yes
<sivang> giftnudel_: seems that the addresses are leased for no more then max 300secs each time, that was causes it to redhcp every time
<\sh> killall -9 dhclient{3}?
<giftnudel_> sivang: yes, exactly
<highvoltage> hi Seveas 
<giftnudel_> sivang: but why is that overridden and not taken from the server
<Seveas> hi highvoltage 
<giftnudel_> sivang: funny, I see something funny, I have a request every minute!
<sivang> 22O3R
<giftnudel_> sivang:  I have n-m .6.2 installed, I think it was always there
<\sh> send dhcp-lease-time 3600; I commented this in ... I think that helped me a lot
<giftnudel_> sivang: Jun  5 22:04:00 localhost NetworkManager: <information>^IDHCP daemon state is now 3 (renew) for interface eth1
<giftnudel_> Jun  5 22:04:00 localhost dhclient: bound to 192.168.1.119 -- renewal in 241 seconds.
<giftnudel_> so for me it's n-m
<giftnudel_> it really tries to do that every 5 min
<giftnudel_> sivang: I don't think I have it at home though, so maybe that's the default, if the server doesn't specify anything?
<sivang> \sh: crap, is this a bug  ?
<\sh> sivang: sure it is..but it was there even without n-m
<giftnudel_> yes, so it's dhclient?
<\sh> sivang: but I wasn't sure if it was me, my network, my router, or the installation
<sivang> \sh: sorry for the other ping on -motu, I am just keeping crashing
<giftnudel_> \sh: I now think it's the installation
<sivang> \sh: also that ipw firmware error makes it restart the interface every few minutes
<\sh> sivang: I have atheros :)
<\sh> sivang: with n-m it gives me every few seconds a rescan
<sivang> ah, I see, maybe it due to the heavy dhcping
<\sh> sivang: no...because of something with atheros and wpa supplicant :(
<sivang> \sh: man, uncommented that line and got longer lease time at least
<giftnudel_> sivang, \sh: so where is the problem now, server problem because it doesn't specify a lease time?
<\sh> giftnudel_: I would say so :) or sending a lease time which the server doesn't like...
<\sh> giftnudel_: but I have a linksys with linux on board, so I wonder if it's really a dhcpd issue on the router
<giftnudel_> \sh: hm, I have some router here, I will have a look at it on wednesday, so then I can see, if it can provide a lease time
<\sh> giftnudel_: I would need to connect my laptop via cable to it..that's a nono right now ;)
<giftnudel_> ;)
<\sh> giftnudel_: drinking beer listening to manowar and trying to convince people to not bring in bots
<giftnudel_> well, the config file helps me a lot
<sivang> \sh: well, the dhcp problem is gone 
<\sh> giftnudel_: so it's the lease time...now we need to find out, if it's the server or the client ;)
<giftnudel_> I will find this out, for sure
<giftnudel_> \sh: but earliest on wednesday, if not friday ...
<giftnudel_> \sh: if you don't have access to the stuff, you need to wait for the passwords ;)
<\sh> giftnudel_: next weekend for me :)
<giftnudel_> ok, bye then
<\sh> giftnudel_: I'll drink some more beer to sleep well ;)
<sivang> \sh: I htink it's the server causing the problems
<sivang> \sh: I've done some testing now with xp, same behavior for me :-/
<\sh> sivang: hmm...what router?
<sivang> \sh: could also be that my network device got b0rked 
<sivang> man, I had to ifupdown just ot be able to complete the sentence
<sivang> \sh: it's a debian machine, my flat mate set it up
<\sh> sivang: check the config of the dhcpd of your gateway
<sivang> \sh: could a hardware b0rk cause this as well ?
<\sh> sivang: then we have the same hardware b0rk ;)
<\sh> sivang: which can't be ;)
<\sh> sivang: but I bet, it's the wireless cable ;)
<sivang> \sh: you mean, wifi is causing trouble ?
<sivang> and right about the same hardware b0rk ;-)
<\sh> sivang: dont
<\sh> don't think so...client or server bug, nothing else
<\sh> despite the normal glitches in wlan chipsets and not working properly on windows^Wlinux *cough*
<sivang> seems like a client bug, btw - I'm still getting the network halts even thouhg I uncommented the lease time override time
<sivang> I wonder why I did not see this a day ago
<sivang> it started only today, and there were no router changes to my understanding
<sivang> and only with the laptop
<sivang> weird
<\sh> sivang: as I said, I have this blackouts every few minutes, and it's n-m or wpa-supplicant.if i'm connecting via interfaces it works ( i have plain mac address verification )
<\sh> sivang: this said, I don't need wpa supplicant
<sivang> this is what I get in the kernel log:
<\sh> oh wow...300 questions about "how can I get ubuntu with xgl to work properly" 
<sivang> \sh: is there a way to completely disable the wlan chip ? (it's always lighed)
<sivang> \sh: where?
<\sh> sivang: kubuntu-de channel
<\sh> sivang: should support your laptop...I have a Fn key for that which works ;) it disables my bluetooth and wlan chip
<sivang> \sh: I disabled it now for good, funny on other times it just stopped after I pressed the Fn key and cam eback after a couple of secs.
<\sh> wtf is ebuntu?
<crimsun> E 0.17 snap?
<mdke> yes
<crimsun> generated by checkinstall for great eyestab justice iirc
<\sh> oh wow
<\sh> I know, I'll create Fluxubuntu ;)
<\sh> derived from fedora and suse packages via alien seeded into ubuntu-server ;)
<_ion> xbuntu  a version of Ubuntu with just plain X, no wm!
<_ion> sh: :-D
<\sh> then blubunut derieved from gentoo with a debian package which installs first ebuild then emerge is doing an emerge sync and emerge world ;)
<mdke> that would rock
<\sh> with blackbox as wm manager
<\sh> sure it will rock ;)
<_ion> I would buy ten of those.
<sivang> \sh: ah, okay, I now see that my problem was still apparent becuae I use a bridge machine (another ubuntu) which also is effected by this bug :-D
<\sh> sivang: fun ;)
<_ion> w2buntu with web 2.0!
<sivang> funny you said that _ion 
<\sh> ajubuntax 
<\sh> ubuntu with ajax wm 
<\sh> sivang: btw...I read the tim o'reilly article
<\sh> it's very true what he said about the changes of the IT market and the change of companies
<sivang> me and fsd
<LaserJock> ibuntu the ion3 derivative (alternatively the Ubuntu derivative done by Apple) :-)
<\sh> LaserJock: ah...it's already released..they just forgot the ubuntu in their release name...apple mac os x it's named ;)
<LaserJock> \sh: they must have done any ugly hack then. I'm running OS X atm and it doesn't seem nearly as polished as Dapper ;-)
<_ion> How about making ${package}buntu for each package in main, restricted, universe and multiverse? In those Ubuntu derivative the package would be installed by default.
<_ion> s
<\sh> LaserJock: oh you need the uber application...
<\sh> _ion: please write a spec for the paris dev summit ;)
<\sh> _ion: but I think we can agree on that here and now ;)
<LaserJock> I'm sure we could add some mass checkinstall capability to soyuz ;-)
* LaserJock runs
<\sh> LaserJock: we show opensuse how to create an open build service the right way..checkinstall and alien ;)
<sivang> \sh: true, but still, thinking that becoming web 2.0 complient could turn a company to be the super uber company is way high
<\sh> sivang: it won't there are things in our world where web 2.0 is not usable for..
<_ion> sh: The people who actually use the term "web 2.0" wouldn't agree with you.
#ubuntu-devel 2006-06-06
* sivang is still getting the halts
<sivang> where do they come from now?!
<sivang> \sh: right
<_ion> You want to drink some coffee? Use Web 2.0! Want to get married? Use Web 2.0!
<LaserJock> what the heck is Web 2.0?
<\sh> LaserJock: a webmail frontend with ajax 
<mdke> it is a buzz word for a website which is really cool
<sivang> hehe
<\sh> s/web2.0/launchpad/
<sivang> heh
* sivang away out&network-problems
<sivang> oops
<\sh> tim didn't even know, that it already existed..the uber web application, which can do everything..it's the launchpad..we can fly to the moon with it, we can dive into the water with it, it speaks different languages, and it provides us with (most of the year) daily freshmeat
<sivang> heheh
<sivang> anyway, still getting the halts after all the mockery in the dhclient.conf files,
<sivang> night all
<\sh> sivang: server then
<\sh> hmm RHEL 5 will only be released, if Xen is ready for production environment..
<Burgwork> \sh, RHEL5 right into Vista
<\sh> Burgwork: I hope RHEL5 is changing to .deb ;)
<\sh> Burgwork: no serious, release should be in december
<Burgwork> \sh, heh, I doubt it
<\sh> moins ogra
<\sh> oh reconnect..
<\sh> night everyone
<eXistenZ> I would like to work on the development of multilingual support in different programs, where do I have to start off?
<ReMink> I've created my first package and my repository _o/ he he 
<jcole> debconf: DbDriver "di_questions": could not open /var/log/debian-installer/cdebconf/questions.dat
<jcole> is the debconf installer questions now nuked?
<jcole> debconf-get-selections --installer
<Burgwork> eXistenZ, you want to do translations?
* Burgwork hugs Kinnison 
<infinity> Kinnison: Odd time for you to be around...
* Kinnison snogs Burgwork 
<Kinnison> infinity: Yah, just prepping for bed and realised I'd not reconnected the IRC proxy for you to be able to rant overnight at me :-)
<infinity> Ooo, overnight ranting!
<Kinnison> :-)
<Burgwork> ReMink, #ubuntu-motu can help you get that package into universe/multiverse
<ReMink> Burgwork: oO :D
<pianoboy3333> Where's a good pygtk/glade tutorial?
<Kinnison> infinity: Well, you know where to leave stuff for me
* Kinnison heads off to bedness
<Kinnison> ciau
<infinity> Kinnison: 'Night.
<robertj> has there been any discussion about trying to simplify MBR management through the gui?
<eXistenZ> Burgwork, Translations, but also I want to contribute in adding multilingual support to some programs which don't support that option.
<infinity> robertj: As a general rule, the MBR shouldn't BE managed.
<infinity> robertj: If your system booted after you installed it (which we'll assume is a "yes", if you're now at a GUI), a pretty utility labelled "Allow me to attempt to make my system unbootable" seems like a bad idea.
<robertj> infinity: that it does, but on a live cd or for a non-boot drive it might make more sense
<Burgwork> eXistenZ, for translations, try #ubuntu-translators
<Burgwork> eXistenZ, for the latter, file a bug and then work with upstream
<Keybuk> I'm so going to win the award for the longest edgy spec
<Burgwork> Keybuk, oh, which one?
<Keybuk> ReplacementInit
<Burgwork> oh, joy
<Keybuk> I decided it needed another five sections
<Keybuk> heh
<infinity> Keybuk: Do you think I can write a spec called "DoMyJob" and just do that while everyone else is getting on with the whizzbang features?
<Keybuk> infinity: I already do your job
<infinity> Keybuk: Mm hmm. :)
<Keybuk> all those bugs of yours I've fixed
<Keybuk> those packages of yours I've uploaded
<Keybuk> <g>
<infinity> Keybuk: Thpt .:)
<Keybuk> why does http://wiki.ubuntu.com/NoMoreNails sound like a spec?
<Keybuk> clearly this beer is bad
<eXistenZ> Burgwork, There is a major cups bug that hasn't yet been fixed, because of which I moved to windows temporarily until it is fixed.
<Burgwork> eXistenZ, if you haven't filed a bug, I shame you into doing it now
<eXistenZ> Burgwork, huh, I wish I was the only one who did.
<eXistenZ> Burgwork, https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/45099
<Ubugtu> Malone bug 45099 in cupsys "client 1.2.0 to 1.1.2x server over IPP: cupsdAuthorize: Local authentication certificate not found" [Normal,Needs info]  
<zul> heylo
<Who_> hi
<KaiL_> any kernel-dev awake?
<crimsun> -> #ubuntu-kernel
<bddebian> Howdy
<ajmitch> hi
<Lathiat> 702M    ubuntu/ubuntu-6.06-desktop-powerpc.iso
<Lathiat> thats too large for many cds, is that known?
<jsgotangco> good morning
<infinity> Lathiat: It fits on 700MB media.
<infinity> Lathiat: We gave up on 650MB media long ago.
<Lathiat> infinity: well someone has told me they couldnt get it to fit on a 700M cd for them
<Lathiat> might depend on the exact media/software i guess
<infinity> We certainly come in under the spec limit.
<Lathiat> hrm, interesting
<neuralis> Lathiat: an iso is an iso; it's size can't depend on media or software.
<neuralis> s/it's/its/
<Lathiat> neuralis: no but whether it will allow you to burn that size iso to the media certainly can
<neuralis> Lathiat: if it doesn't, it's broken.
<Lathiat> neuralis: im not disputing that :)
<infinity> Which OS, burning software, etc was being used?
<infinity> Could just be a bug.
<infinity> Or buggy CDR drive firmware.
<infinity> Who knows.
<Lathiat> nautilus-cd burner on breezy, could have been smaller media i guess
<Lathiat> i'll see
<Lathiat> cheers infinity 
<SymGeosis> Could anybody point me to where the Ubuntu file system layout policy is? While it is generally fairly obvious by looking manually, I'd like the offical docs. My wiki and google searches didn't turn up much.
<Fujitsu> SymGeosis, look for the Debian one, for starters.
<SymGeosis> Yeah, that didn't turn up much either. Though, it undoubtedly exists so I somehow missed it.
<infinity> SymGeosis: You want the FHS, there is no Ubuntu-specific standard (a standard with one vendor following it wouldn't make much sense.
<infinity> )
<SymGeosis> Yeah, I must be tired. I was just looking at Debian's page again. It's right at the top.
* SymGeosis smacks himself around a bit with a large stick of stupidity. =(
<jcole> where is the dapper sparc mini.iso?
<jcole> ie, here's the ia64 -> http://ports.ubuntu.com/ubuntu-ports/dists/dapper/main/installer-ia64/current/images/netboot/
<jcole> ah, got it -> http://ports.ubuntu.com/ubuntu-ports/dists/dapper/main/installer-sparc/current/images/combined/2.6/
<infinity> Note that sparc will (eventually) disappear from ubuntu-ports, since it's in the main archive now.
<bddebian> LASERJOCK! :-)
<LaserJock> bddebian:  jeeze, a little happy to see me?
<bddebian> LaserJock: Always :-)
<desrt> BenC, infinity, anyone?
<WebMaven> Well, I'm here.
<infinity> desrt: ?
<desrt> infinity; i need the opinion of a kernel hacker
<desrt> the problem is as follows
<desrt> when my laptop comes back from sleep IRQ9 is high
<infinity> desrt: You may want BenC... For my own sanity, I pretend to not know anything about the kernel.
<infinity> (but go ahead anyway)
<desrt> but the ACPI system doesnt think it ought to do anything about it
<fabbione> desrt: your HW is broken
<desrt> so i fixed this by always having ACPI 'ack' the IRQ even if it doesn't service it
<desrt> but...
<desrt> it's a level triggered IRQ
<desrt> so my machine basically spends 30+% of its time servicing this IRQ
<desrt> obviously not acceptable....
<desrt> so next i started to check the ICH7 configuration registers for differences
<desrt> (between powerdown and restart)
<desrt> i noticed one difference -- the SCI_EN bit
<desrt> before sleep it's enabled, after sleep it's disabled
<desrt> and reenabling it causes the flood of IRQ9 to stop
<desrt> so basically, i want to set SCI_EN on resume from sleep....
<desrt> BUT....
<desrt> i want this to go into the official version of the kernel (or possibly just dapper) and i need to know how i can make the code only effect my laptop
<desrt> so that's my story.  plz help :)
<infinity> Well, there are machine tables that can be used to white/blacklist out behaviours on different machines.
<infinity> However...
<infinity> If that register is being twiddled by the driver on init but not on resume, that's probably a general ICH7 bug, not specific to your machine.
<desrt> right.
<infinity> (Or does the driver never go near it, and your firmware is just setting up the hardware different depending on boot method?)
<desrt> well
<desrt> the driver knows what SCI_EN is
<infinity> So, is it the driver that's twiddling that bit on a clean boot?
<desrt> it only ever reads it, though
<infinity> Or is the register "pre-twiddled" before Linux even loads?
<desrt> no.  i think it's probably the bios.
<infinity> Kay.
<infinity> Is this still the MacBook Pro?
<desrt> macbook (not pro)
<infinity> Right, sorry.  MacBook Amateur. :)
<desrt> maybe it makes sense to copy the value of the PM1 register (where the SCI_EN bit lives) just before suspend and restore it on resume
<infinity> Before you go fixing Linux to work around firmware bugs, have you found somewhere to complain to Apple about it, in hopes that they'll fix the firmware and we will only have to work around the bug for a short while?
<desrt> dur?
<desrt> are you sure it's a firmware bug?
<infinity> If on boot that bit's high, and in resume, it's low, and that's causing a never-ending level interrupt, I'd call it a bug.
<infinity> But what do I know?
<desrt> maybe it's high because BIOS sets it high
<desrt> and maybe it's low because the BIOS doesn't run on resume
<desrt> seems pretty reasonable to me
<infinity> Err, it doesn't?
<desrt> very very little BIOS runs on resume
<infinity> (forgive me, I know nothing of MacBooks)
<desrt> only really enough to jump to our wakeup trampoline
<desrt> same on all systems
<infinity> Well, enoiugh BIOS runs on most systems to bring the hardware back to a sane state, generally.
<infinity> But yes, it's also sane for the driver to read registers that may corrupt, save state, and write them back out on resume.
<infinity> And that should be safe for all ICH7 systems, rather than being specific to yours.
<desrt> i say.
<desrt> so now two questions:
<desrt> what is the 'correct' place to insert this code
<desrt> and how do i conditionalise it?
<infinity> This is where we get into areas where you might want mjg59 or BenC, since I've never hacked at the sleep/resume stuff at all.
<desrt> k.  i think they're both doing a sleep/resume cycle of their own right now :)
* StevenK tries to figure why {q,}dvdauthor is broken on Dapper.
<pitti> Good morning
<Fujitsu> Hi, pitti!
<ajmitch> morning pitti 
<pitti> hi Fujitsu, moin ajmitch!
<Fujitsu> Hi.
<desrt> rawr.
<desrt> infinity; i've emailed the two of them now
<desrt> in the meantime /me enjoys laptop nirvana
* infinity blinks.
<infinity> smbfs isn't LFS-enabled?
<infinity> Guess it's time to switch to cifs...
<dholbach> good morning
<kagou> hi
<tepsipakki> is 'landscape-client' related to the RHN-clone that is under construction in Montreal ?-)
<infinity> tepsipakki: The package description should be enough to answer that.
<tepsipakki> should, yes.. I'm just fishing for more information ;)
<jadaz87> hm muy interesant
<ivoks> pitti: ping
<pitti> hi ivoks 
<ivoks> pitti: i noticed that cups works ok on older kernel
<pitti> ivoks: in which regard?
<ivoks> pitti: e.g. 2.6.9
<ivoks> pitti: browsing/printing with older cups 1.1.x
<ivoks> same network, same config
<ivoks> on one comp it works, on other it doesn't
<pitti> oh, interesting
<ivoks> on the one that works - 2.6.9 kernel
<pitti> ivoks: but wasn't 1.2.1 supposed to fix this?
<ivoks> i'm installing dapper kernel to confirm this
<ivoks> pitti: it doesn't :/
<ivoks> i even compiled from source, no change
<ivoks> and guys at easysw can't reproduce our problems
<ivoks> so... must be something else :)
<pitti> oh, right, I meant browsing/printing with cups 1.1.x
<ivoks> the thing is that easysw is aware of problems with cups <=1.1.17
<ivoks> but we have problems with every cups that's not 1.2
<pitti> ivoks: that's frightening
<ivoks> tell me about it...
<ivoks> i'm fighting with that for days...
<ivoks> i'll test this with new kernel later today...
<pitti> hey seb128 
<seb128> hi pitti
<ivoks> well, will be back later today...
<Kaloz> Failed to fetch http://hu.archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.15/linux-source-2.6.15_2.6.15-23.39.diff.gz  Could not open file linux-source-2.6.15_2.6.15-23.39.diff.gz - open (13 Permission denied)
<Kaloz> *g*
<Kaloz> oh, okay.. our proxy redirected it
<Kaloz> :p
* Kaloz is sleepy
<Kinnison> Morning all
<mdke> morning
<ajmitch> hi
<mdke> Znarl: around?
<Kamion> KaiL_: I don't understand your suggestion on CommunityEdgyIdeas/Kernel: "Squash FS support compiled into it"
<Kamion> KaiL_: we *have* squashfs support in our kernel (ok, as a module, but everything is a module where it sanely can be, and that can't really change), otherwise our live CD wouldn't work
<ogra> fabbione, ping
<fabbione> ogra: ?
<ogra> fabbione, are you aware of any heavy breakage of SiS cards ? 
<ogra> seems i have a user where the install breaks as soon as dexconf starts for hist card ...
<fabbione> ogra: as of 1st of June i am not the X maintainer anylonger... kthxbye
<fabbione> ogra: since it's up for adoption and you are the first one mentioning it, i guess you win :)
<ogra> either in the usual install (workstation) or even if the chroot building of the thin client runs 
<ogra> hrm ...
<dholbach> fabbione: that doesn't answer his question :-p
<ogra> i just didnt find any bugs that are directly assigned to xserver-xorg-sis
<jono> hi all
<fabbione> ogra: i am pretty sure you want to look at xorg...
<jono> has anyone been doing any kind of competative analysis of Dapper compared to Vista?
<dholbach> ogra: how about  https://launchpad.net/malone/distros/ubuntu?field.searchtext=xserver-xorg-driver-sis&search=Search ?
<fabbione> dholbach: well.. today is bank holiday.. so it's not like i am here.. you just imagine i am 
<ogra> fabbione, will do ... but its seemed very card specific, so i looked at the driver first, thanks
<fabbione> +
<fabbione> on the 6/6/6 you expect ME to do something sane?
<Daemon> jono: there were a few reviews around I believe that had a few comparisons, none that I know of since the full 6.06 release
<ajmitch> heh
<highvoltage> jono: i haven't seen someone write about it in-depth yet, but it's on the minds of many people
<dholbach> fabbione: I see - I just commented on your answer to a "are you aware of ..." question :-)
<jono> I am wrapping some projects up here, and if I get some time I figured it may be useful to do a shot by shot comparison to identify areas in which we can hammer edgy home :)
* dholbach congratulates his dad on his 60th birthday on 6/6/6 :)
<ajmitch> fabbione: I'm surprised you haven't found a willing maintainer yet
<ogra> dholbach, yes, thats what i was loopking at yesterday ... seems to have nothing in the list
<jono> I spent some time at Microsoft in Reading and used it and figured we need some assessment of Vista to help Edgy kick its arse :)
<ogra> dholbach, 60 on 666 ? thats evil :)
<fabbione> ajmitch: i guess you just volunteered :)
<dholbach> ogra: *I* know
<ajmitch> fabbione: do I look that crazy to you? :)
<fabbione> ajmitch: yes
<ajmitch> no need to answer that..
<fabbione> or are tyou trying to say that i am crazy?
<mjg59> jono: Can we secure your support in the RSS-pronunciation movement?
* fabbione looks evily towards ajmitch 
<mdke> jono: there is a marketing team, sort of. they might be interested in helping you out
<ajmitch> fabbione: you'd be crazy if you wanted to keep it all for yourself
<jono> mjg59: wah?
<mdke> jono: or are you more talking technical analysis than marketing?
<jono> mdke: oh cool
<jono> mdke: well, I was thinking primarily technical and usability
<ogra> dholbach, btw, seen bug 47638 and bug 47336 (seems there are more of these )
<Ubugtu> Malone bug 47638 in Ubuntu "Artifacts on application buttons" [Normal,Confirmed]  http://launchpad.net/bugs/47638
<Ubugtu> Malone bug 47336 in edubuntu-artwork "Redraws doesn't happen properly with Edubuntu GTK Theme" [Normal,Unconfirmed]  http://launchpad.net/bugs/47336
* jono is quite the usability pervert
<dholbach> ogra: yes, that's ati breakage
<dholbach> ogra: xrender and ati - all dups
<ogra> ah, then it seems restricted to i386
<mdke> jono, quite a lot of usability issues depend on upstream tho
<ogra> i dont see it on the ibook
<mjg59> jono: http://mjg59.livejournal.com/62931.html
<mjg59> And the link
<ogra> dholbach, thanks 
<dholbach> ogra: maybe specific to a certain hardware - *shrug*
<ogra> yep ...
<jono> mdke: agreed, but I was thinking the problem could be split into integration and upstream functionality - some elements we can control, but some need upstream cooperation
<mdke> right
<jono> who knows, if I get time to do this, it may not be actually all that useful, but I figured it would be something that could provide some food for thought
<jono> just need to open up my schedule a bit first :P
<makko> sabdfl: fedora and suse first release a non-commercial version and then they release a commercial one with most bugs fixed. i think the fact that they have two releases helps them a lot with perfecting their commercial release. i think it is very useful for ubuntu to also implement this strategy: first to have a HACKER'S RELEASE (or something like that; a bleeding edge release) and then, after about one month of bug fixing, have a longer time s
<makko> g like that).
<makko> sabdfl: otherwise, if we keep on releasing many flights or betas (the names of which don't sound so appealing for most users, so they won't download and try them), they will prefer to download none of them.
<makko> sabdfl: i am afraid so many flights more like confuse them.
<Mithrandir> makko: well, we won't release any more flights now, so..
<mdke> what's a group of efts?
<Mithrandir> mdke: I'm not sure, and I don't think anybody else is either.
<Daemon> makko: I think that's sorta in place, in fact edgy will start soon enough
<Mithrandir> mdke: so we might have to invent something.
<makko> Mithrandir: no flights will be released for edgy?
<mdke> heh
<mdke> jono: i listened to lugradio last night, was quite interesting. I haven't listened much before. I enjoyed the discussion on the FSF
<jono> mdke: cool :)
<jono> mdke: the latest episode was fun to record :)
<mdke> it sounds fun
<Mithrandir> makko: nope.  Like we didn't release any arrays or colonies for dapper.
<mdke> makko: they will be releasing unstable releases, but they will be called something else. "flight" was a word specific to dapper drake
<mdke> at least I hope they will be releasing unstable releases
<makko> mdke: whatever, but what do you think about my idea?
<mdke> makko: I don't have a view. I know nothing about release cycles
<makko> mdke: who's responsible for release cycles?
<Mithrandir> makko: I think it's a bad idea.  We get great responses to the alpha and beta releases and the team is too small for us to be able to do the QA and test for a month after a preview release.
<mjg59> jono: Really, I just want to hear you describe Web 2.0 as a bunch of RSS on air
<jono> mjg59: you got it :)
<mdke> haha
* jono grumbles something about the word beta, gradients and orange sunglasses...
<mjg59> And ideally mention a lugradio RSS feed
<jono> heh
<makko> Mithrandir: well, maybe not a month, but two weeks.
<mjg59> Which can be sucked using a variety of clients
<mjg59> But anyway
<jono> I don't know if I want to say, "keep up to date with LUGRadio episodes with arse"
<jono> right, back to work...
<jono> have fun guys
<Mithrandir> makko: how is this different from the tech preview/beta and release we have today?
<makko> Mithrandir: the naming matters a lot
<makko> Mithrandir: we want it to be the equivalent of redhat's and novel's commercial version, right?
<makko> Mithrandir: i mean, we want the final release to be that
<Daemon> makko: from a personal opinion, I like the current version of development where you just enable the newer repositories and keep updating. 
<makko> Daemon: what i suggest doesn't affect that
<Mithrandir> makko: no, we want it to be better.  We _don't_ want to have a "normal" and an "enterprise" version.
<Daemon> makko: have you seen how old some of the redhat versions are though?  That's what put me off the commercial releases
<Daemon> versions as in package / software versions
<ubijtsa2> Daemon: there is a reason for that
<makko> Mithrandir: no, we don't want that. instead, we want to have a HACKER'S RELEASE (bleeding edge) and a LTS RELEASE (or something)
<Mithrandir> makko: why?
<makko> Mithrandir: some users prefer novelty, some others prefer stability
<ubijtsa2> Daemon: most notably banks and financial institutions do not want to update every 3-6 months.. they want to update every 2-3 years
<Mithrandir> makko: we don't have the resources to make two different versions with different goals, so we have to make a tradeoff
<makko> Mithrandir: we can address both while this can also bring to us lots of more beta testers (which otherwise will hate the "beta" labeling and will prefer to wait for the "final" release until they try it first)
<makko> Mithrandir: i understand
<makko> Mithrandir: i haven't considered resources.
<Daemon> ubijtsa: I understand that side of it, but at the time they're already 6 months behind when they first install
<makko> Mithrandir: well, but what if it's more like a matter of naming? the LTS will be a tweaked HACKER'S anyway.
<makko> Mithrandir: a HACKER'S could be another name for PREVIEW.
<makko> Daemon: some people prefer to stay six months behind
<ubijtsa2> Daemon: tracking latest and greatest isn't an option for some, quite a lot are still on RHEL3
<Daemon> ubijtsa2: agree. O
<makko> Mithrandir, Daemon: a HACKER'S RELEASE sounds... quite appealing for much more people
<Daemon> I'm probably looking at it too much from a desktop pov
<Mithrandir> makko: I don't think so.
<mdke> makko: appealing in that the word "hacker" is commonly associated with criminal attacks on computers?
<ubijtsa2> peronally, I prefer the 6 month release schedule. But the work I do now requires me to think of the ones that require the long term stability, like the LTS releases.
<Daemon> makko: not to me, considering linux is meant to be the distro that's human friendly
<makko> Mithrandir: then we can chose another name for it, it's just that we should make it more like a purpose in itself, rather than a mere... beta.
<makko> Mithrandir: people love attained purposes more than unfinished products.
<mdke> but these products are unfinished, that's the whole reason they are called "beta"
<Mithrandir> makko: you're arguing that its purpose is to get testers.  Testers test stuff which is not finished, aka alphas and betas.
<makko> mdke: ok, i am not proposing the word "hacker", but <some appealing naming>.
<Kamion> mdke: the best two suggestions I have are "knot" (used for other amphibians, frogs/toads) and maybe "nest" (but that's just based on the fact that efts nest, it's not a real collective noun)
<ubijtsa2> how about the idea that was floated a while back, every fourth release is a LTS, gets much more QA etc, and the three intermediate releases are Desktop releases, more cutting edge stuff, more focussed on new stuff.
<makko> Mithrandir: yes, but we might also need feedback from casual users and casual problems. the more the eyeballs, the shallower the bugs.
<Kamion> my inclination is "knot"
<Mithrandir> Kamion: knot sounds like a good name to me.
<Kamion> ubijtsa2: we'll do occasional LTS releases when it makes sense to do so; we aren't going to tie ourselves to "every fourth", appealing though the regularity may be
<ogra> yeah, lets keep nest for the time we run out of suggestions :)
<jsgotangco> makko: honestly, not that its bad, casual users tend to file dupes
<makko> Mithrandir: for instance, this dapper lts still has some bugs which *could* have been detected much earlier if we had released an "appealing" version of dapper one month earlier.
<ubijtsa2> Kamion: I hear you, but some form of regularity (2-3 years) would be beneficial
<makko> jsgotangco: maybe you're right
<Mithrandir> makko: it's often less that we don't know of the bugs than that we don't have time to fix them.  More bugs doesn't mean more fixes.
<jsgotangco> we actually released a "Release Candidate" for general use and testing
<Mithrandir> s/bugs/bug reports/
<Kamion> ubijtsa2: it has to depend on when everything seems to be settling down to a place where we think we can commit to long-term support
<makko> Mithrandir: well, that's a good point
<Kamion> hopefully there'll be an appropriate point in about two or three years time
<makko> jsgotangco: yes, but we released it just one week before the final release. nobody has time to fix anything in less than seven days.
<ubijtsa2> Kamion: would it be possible to keep it in mind while working on the Desktop releases, to slowly steer it into a LTS release, maybe 18 months before making it a LTS?
<makko> jsgotangco: and why not naming it something else than "release candidate"?
<Kamion> makko: I disagree strongly. Particularly with regard to ubiquity, I got just about as many bugs as I could possibly deal with in each iteration (beta, beta2, flight7, rc), and fixed all the ones I considered high-priority and several more
<ajmitch> ubijtsa2: it's a matter of when other parts of the system seem to be at a stable point, like X, the kernel, etc
<jsgotangco> return of the release candidate?
<Kamion> makko: the problem was that the nature of the beast was such that I didn't find out about crashes late in the program's operation until I'd fixed the ones earlier in its operation
<Kamion> makko: actually we fixed several things between rc and release
<ajmitch> ubijtsa2: I don't think we'll have crazy insane stuff in all the releases up until an LTS release :)
<makko> Kamion: right. as i said, saying that "it's not like we don't get enough bug reports, it's just that we lack resources to fix them" is really a good point.
<Kamion> ubijtsa2: I expect we'll be thinking about it, yes
<makko> Kamion: i think two weeks instead of one would have been much better... 
<ubijtsa2> ajmitch: just thinking, if we know that we'd like rel+2 to be a LTS, don't include highly volatile stuff in rel and rel+1 just because they are cool :)
<makko> Kamion: i mean more than twice
<ajmitch> ubijtsa2: yep, I think that's how it's planned, which is why edgy will be rather.. edgy
<ubijtsa2> ajmitch: sounds sensible. 
<Kamion> makko: releasing dapper in December would have got more bugs fixed too
<Kamion> makko: but it would also have weakened the impetus on people from knowing that the release was soon
<Kamion> makko: you can't extend things forever
<Kamion> and honestly, we weren't *ready* for RC two weeks before release
<ubijtsa2> a release can't be perfect in all aspects.. it'll take forever if that is the aim.
<stub> Launchpad will be going down for its regular code update in 30mins time. Estimated downtime is 10 minutes. Wikis will be in read only mode during this time.
<jsgotangco> thanks
* jsgotangco saves work
<makko> Kamion: this is somehow strange: some other distros release even two rcs, not to emphasise that there was a six weeks' delay
<ubijtsa2> risk management, and structure for updates and security fixes is important..
<makko> Mithrandir, Daemon, mdke, ubijtsa2, Kamion, ajmitch: anyway, in fact, if i think better, i guess my suggestion is redundant. i think this is what is already intended by the LTS-like / EDGY-like distinction between releases. right?
<Kamion> makko: *shrug*
<Kamion> fundamentally most distros just chuck out test releases until they're ready to go
<Kamion> where "ready" is determined by all sorts of different things
<ubijtsa2> cmp with the kernel, they do -rc after -rc until the concensus is that it is good enough.
<Kamion> everyone's release process is different in some way
<mdke> from the little I've seen, open source development is pretty fast moving, and it's pretty hard to tame it. I imagine that release processes are an art form
<Kamion> there are hundreds of different ways to paint this bikeshed
<Mithrandir> can I have it ice-blue with penguins on?
* Mithrandir hides from Kamion's gauntlet.
<stub>  Launchpad Rollout cancelled, rescheduled for tomorrow around 03:00 UTC
* pitti invokes deb http://people.ubuntu.com/~pitti/langpacks/daily/breezy-updates/ ./ into life
<mdke> Znarl: around yet?
<Znarl> mdke : Hello!
<mdke> Znarl: hello :)
<mdke> Znarl: do you think it would be a good idea for me to open an RT for this wiki thing, or maybe arrange a time which is convenient to you to discuss?
<Znarl> mdke : A RT request may be a good idea.
<mdke> Znarl: alright. Is there a technical problem, or just lakc of time?
<eXistenZ> any developer responsible for the cups package here?
<Znarl> mdke : Lack of time.
<mdke> Znarl: ok, cool, I'll RT it
<pitti> eXistenZ: I'm the closest one
<eXistenZ> pitti, there is a major bug in cups. Which hasn't been fixed
<pitti> eXistenZ: just one? :)
<pitti> eXistenZ: seriously, is it in LP already?
<eXistenZ> pitti, Here it the bug: https://launchpad.net/bugs/45099 . It is very irritating that I have to move to windows everytime I want to print some document.
<Ubugtu> Malone bug 45099 in cupsys "client 1.2.0 to 1.1.2x server over IPP: cupsdAuthorize: Local authentication certificate not found" [Normal,Needs info]  
<pitti> eXistenZ: I plan to update dapper to 1.2.1 soon, but I need to catch up with some security updates before; also, I'll do a round of bug triage for cups bugs soon
<eXistenZ> pitti, That'll be gret.
<eXistenZ> *great
<pitti> Ubugtu: I have seen this error message regularly in my logs, but it doesn't have any ill effect
<pitti> eXistenZ: anyway, I'll look at the bug ASAP
<eXistenZ> pitti, When do you think the cups will be upgraded?
<pitti> eXistenZ: the last comments seem to indicate that this error message is irrelevant
<pitti> eXistenZ: end of this week, I hope
<eXistenZ> pitti, What do you think this error is about?
<pitti> eXistenZ: I have to read the bug in detail
<pitti> eXistenZ: it's on my list, but I can't do it right now, sorry
<eXistenZ> pitti, I get the same error, but with "stopped with status 3!"
<eXistenZ> pitti, that's okay.
<TheMuso> c
<eXistenZ> pitti, By the way, do you use vim or emacs? :)
<pitti> eXistenZ: vim, why?
<eXistenZ> pitti, I'm use vim as well =)
<jono> anyone know John Levin ?
<InfraRed> who doesn't 
<jono> what is his nick >
<Treenaks> jono: isn't he lilo?
<Treenaks> oh wait, that's Rob
<Treenaks> nm
<jono> hi is a UK ubuntu guy
<InfraRed> isn't he the guy in pirates of the caribbean ?
<jono> heh
<jono> any half way serious answers ?
<apokryphos> John Levin is lilo
<Riddell> jono: he's not on IRC much as far as I know
<jono> ok
<apokryphos> oh wait, that's Rob Levin
<jono> Riddell: did you want to do a KDE/Kubuntu BOF?
* apokryphos catches upw ith the conversation
<Riddell> jono: but he did the lugradio stand last year for ubuntu
<jono> cool
<jono> Riddell: do you have his email address?
<jono> I need to mail him about Ubuntu BOFs
<Riddell> jono: I think a stand and a talk will be enough for KDE/Kubuntu
<jono> just firmiing up the times
<Riddell> john levin <john@technolalia.org>
<jono> Riddell: cool
<jono> thanks dude
<mdke> jono: get on the ubuntu-uk list!
<jono> mdke: I should be, but my mail is rather maxed out with lists atm
<jono> right, lunch :P
<mdke> jono: would be a good place to drum up a bit of enthusiasm for LRL. Maybe a newsreader would be in order :)
<zul> heylo
<_ion> hilow
<pitti> hi zul 
<highvoltage> hey zul
<zul> pitti: still no upload yet?
<pitti> zul: no :/
<zul> meh
<pitti> carlos: ok, daily hoary/breezy/dapper langpack updates set up and cron'ed. I wait for today's run and check the results; shall I announce this to ubuntu-translators again, then?
<jsgotangco> \o/ pitti \o/
<carlos> pitti: I think so, yes
<carlos> pitti: thanks!
<sivang> re all
* sivang is online again but unknown for how long
<purserj> Quick question, why with fresh dapper installs is there no ld.so.conf file?
<kermitX_> minor bug in the gnome bittorrent client?  if you uncap the upload rate and later re-check that option, the cap never takes effect. you have to shut it down and restart it.
<_ion> purserj: Why should there be one?
<purserj> In my understanding you need it for linking libraries if you're building from source
<_ion> DESCRIPTION ldconfig  creates  the  necessary  links and cache (for use by the run-time linker, ld.so) to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and  in  the  trusted directories  (/usr/lib  and  /lib).
<_ion> The libraries are typically in those directories.
<_ion> \therefore no need for ld.so.conf
<purserj> so if there are libraries in say /usr/local/lib?
<_ion> Don't put libraries there.
<_ion> Rather use or create packages.
<tseng> and if you do
<tseng> you should know how to manage them yourself
<purserj> why the change?
<_ion> What change?
<purserj> the removal of ld.so.conf. It was in breezy but not in dapper?
<tseng> it wasnt in breezy
<tseng> not in a server install anyway.
<tseng> in the future, please pose support questions to #ubuntu
<purserj> not a support question, something like this is pretty integral to development on ubuntu
<_ion> This channel is about Ubuntu development, not about development on Ubuntu.
<_ion> See the topic.
<tseng> exageration doesn't help you, i have been developing on ubuntu for 2 years and I don't have such a file
<jono> Only 46 days until LugRadio Live!
<jono> oops
<jono> wrong chan
<sivang> Kamion: Just something for you to think about, IBM .IL Global Tech Group are allowing me to use their testing lab, when I'll choose, to test Ubuntu on the pSeries, so I thought we could arrange a day in which I will conduct boot testing etc, I will provide you with the error messages from my attempts , and you might try to provide me fixed small testing ISOs, so we can at least get the booting thing behind us. Do you think this is feasible to kil
<Keybuk> pitti: how do you feel about sysklogd and LFS support (or lack thereof)
<zul> hey Hobbsee 
<Hobbsee> hey zul 
<ajmitch> hello Hobbsee 
<Hobbsee> hey ajmitch, how are you doing?
<Kamion> sivang: your message was cut off at "feasible to kil"
<ajmitch> Hobbsee: going off to sleep in a minute or so
<pitti> Keybuk: oh, how big do you expect log files to grow? :)
<Hobbsee> ajmitch: mmm...sleep...
<Kamion> sivang: sure, whenever, just note that I will be on holiday and offline all of next week
<Keybuk> pitti: apparently on a news server it's quite common for them to get >2GB
<thom> heh
<thom> understatement of the hour
<Keybuk> like Clara's news server
<pitti> Keybuk: well, of course I'd welcome it :) you have a patch?
<Keybuk> pitti: I was looking through the changelog, apparently we've tried to fix this already
<Keybuk> well, Charles Majola tried to fix it
<Keybuk> so it may need some gentle repair work <g>
<Keybuk> I only ping'd you, because you tried to fix it before Charles did
<pitti> oh, did I?
<pitti> Keybuk: if I did, I lost all memory about it
<Keybuk> was pre-breezy
<pitti> Keybuk: one of etch's goals is full LFS support, so from that side we have good opportunities to watch out for :)
<thom> actually, the transit servers appear to be averaging just under 2GB per day transit logs from diablo
* pitti looks forward to the next sync/merge rave. new crack :)
<doko> mdz, Kamion: is qt-x11-free still sitting in the dapper-updates queue, or did I do a mistake uploading the package?
<Kamion> doko: http://librarian.launchpad.net/3008685/iRLv1uVqy6JbBjIsZa6PNOLwRTO.txt
<Kamion> guessing you forgot to sign it
<doko> Kamion: thanks
<Kamion> yep, looks like it
<mdke> elmo: around?
<iwj> pitti: I asked mdz for permission to put 1.5.0.4 into dapper-updates and he demurred and asked what your opinion was.  I am right in thinking that your opinion is like mine, `unfortunately we have no choice so we should do so'.
<iwj> ?
<pitti> iwj: well, I'd rather like to see it in dapper-security
<iwj> Is that more pushy than -updates ?  In which case I agree.
<pitti> iwj: and yes, we'll have enough to do with backporting this sh** to 1.0.x, I'm all for updating dapper to 1.5.0.4 (after appropriate testing, of course)
<pitti> iwj: we just need to make sure to not break gtkmozembed stuff
<pitti> iwj: 'pushy'?
<iwj> Not to break it worse than it is, you mean.
<iwj> I mean, is putting something in -security more likely to cause it to be installed than putting it in -updates.
<pitti> iwj: well, it fixes two handfuls of security bugs, so it should be -security
<iwj> testing> Quite.
<pitti> iwj: ah; well, nowadays -updates and -security are both on by default, so it doesn't matter so much from that perspective
<iwj> I have a pre-build here and I'll just turn it into a proper package and test it.
<iwj> Right.
<iwj> OK, I'll target dapper-security then.
<iwj> mdz: Re firefox 1.5.0.4, see ^
<pitti> -security is announced with an USN and instantly mirrored to security.u.c, that's the main difference
<pitti> iwj: and opting out of -updates is regarded fine, whereas noone should deactivate -security
<Kamion> yeah, what pitti said, I think -security is marginally pushier
<iwj> Right, good.
<pitti> iwj: btw, dapper-security doesn't work yet, I'll ping you once it does
<pitti> iwj: did you get the CVE changelog snippet?
<iwj> Yes.  Hence my question.
<iwj> dapper-security> Oh, right.  OK.  I'll build and test this thing in the meantime anyway.
<mdke> elmo: unping
<G0SUB> pitti: hello!
<pitti> hello G0SUB, how are you?
<G0SUB> pitti: I am fine now. 
<pitti> G0SUB: glad to hear; I heard from the terribly strong Monsun in the radio
<G0SUB> pitti: I have written down some of my ideas in the DesignDiscussion page
<G0SUB> pitti: yeah, Monsoon is coming here :)
<mdke> jdub: just saw your email (my email is going to the wrong server too like planet) - *winces at linguistic faux pas*
<pitti> mvo, G0SUB: can we 'meet' in 30 minutes to discuss about it?
<G0SUB> pitti: I am already in a meeting with mvo in #synaptic :)
<mvo> pitti: I'm writing a mail about it currently, can we do it in ~1h ?
<mvo> pitti: I'll CC you then
<pitti> G0SUB: ok, I'll join :)
<G0SUB> great
<pitti> mvo: works for me, although I will only have 30 minutes then; G0SUB, ok?
<G0SUB> pitti: fine
<dholbach> ogra: there's a new gnome-screensaver for -updates
<ogra> oooohhh :)
* ogra goes to look at the changelog
<ogra> dholbach, ta
<dholbach> de rien
<dholbach> liboobs 0.1.0 RELEASE!
<dholbach> mvo: ^
<jsgotangco> nice
<jsgotangco> does it go with libsexy?
<pitti> dholbach: liboops? :)
<mdke> boobs eh
<pitti> oh, libboobs
<pitti> dholbach: everything below version 2.0 is UNUSABLE!
<dholbach> jsgotangco: both go nicely with Ubuntu!
<jsgotangco> dholbach: then it should integrate well with pornview nicely
* Kinnison ponders writing libube
<mvo> dholbach: yeah!
<thom> i still think the parrott "-larry -Wall" one was best
<pitti> thom: there is a libarry? :)
<thom> pitti: they concocted one so they could have that in the compiler flags
<makko> why can't i connect to the x11 server in a root konsole (after i run "sudo konsole")? after i run "sudo konsole", i cannot open any x11 app from that konsole; but, after i run "sudo xterm", i can run any x11 app. how do you explain that? it doesn't look like a permissions issue to me.
* ivoks is loosing his mind
* Hobbsee reluctantly hands over ivoks' mind.
<Hobbsee> here you go..
<ivoks> eh...
<ivoks> i suggest we use lprng for edgy
<ivoks> :)
<makko> answer! i know you are there! :P
<ivoks> brb
<ogra> dholbach, do you know if g-s-s goes in with the general 2.14.2 upgrade or do i need to ask for separate permission from mdz ?
<leo__> Hi , I'm customizing a 5.10 live cd and I want to set my XkbLayout to "be" in my xorg.conf , how do i do this?
<dholbach> ogra: it's a 2.14.2 and if you can eyeball the changes and vouch for them, they're good to go, I'd say
<tseng> dholbach++
<tseng> hi
<dholbach> heya tseng
<jdong|coreduo> how many runlevel 2 services does gdm actually depend upon?
<jdong|coreduo> just for kicks, I moved S13gdm to S01gdm, and it does work
<jdong|coreduo> I've tested 10 bootups across two of my (faster) systems
<pitti> jdong|coreduo: X needs a properly set hostname, so it should depend on working network
<ogra> where did these come from, there is only one S13gdm in rc2.d on all my systems here
<jdong|coreduo> ogra: yeah, I know. I moved it from 13 to 01, so the first thing it does is start up GDM in runlevel 2
<jdong|coreduo> pitti: what would "happen" if hostname was localhost?
<jdong|coreduo> or unset?
<pitti> jdong|coreduo: I don't know TBH, I'm just parroting Daniel Stone
<ogra> jdong|coreduo, lol, sorry i read removed instead of moved
<jdong|coreduo> also, hostname is done in rcS, right?
<jdong|coreduo> ok
<jdong|coreduo> it shaves around 3-5 seconds to a login prompt
<jdong|coreduo> so no big deal at all
<jdong|coreduo> but it looks damn impressive :)
<jdong|coreduo> dapper's bootup is already plenty fast out-of-the-box
<jdong|coreduo> out of curiousity, are we to see GNOME 2.14.x updates through dapper-updates?
<jdong|coreduo> it sure is beginning to look that way
<HiddenWolf> jdong|coreduo: I believe so
<jdong|coreduo> excellent :)
<jdong|coreduo> good to see some bug fixes
* jdong|coreduo thinks back to Warty's nautilus FTP :)
<HiddenWolf> jdong|coreduo: dapper's nautilus is plenty screwed. :P
<bddebian> Morning folks
<jdong|coreduo> HiddenWolf: at least it uploads binary data fine :)
<jdong|coreduo> so I won't complain too much :)
<jdong|coreduo> morning, bddebian
<bddebian> Hello jdong|coreduo
<jdong|coreduo> are there plans for Edgy to use Initng?
<jdong|coreduo> or do we think we can get init to boot even faster?
<ivoks> pitti: good news
<mjg59> jdong|coreduo: If the hostname isn't set when X starts, there's the potential for authentication cookies to break in surprising ways
<bddebian> Is Edgy ready yet??
* bddebian hides
<tseng> bddebian: subscribe to edgy-changes and you can be the first to know
<bddebian> pfft ;-)
<ivoks> pitti: wb
<pitti> bah
<pitti> thanks
<ivoks> pitti: so, good news :)
<profoXP> Hello. How does the current suspend work ? (suspend to disk) is it using swsusp or suspend2 or ..?
<profoXP> Because it doesn't work well on all 4 pc's in my house (2 laptops, 2 pc's)
<ivoks> profoXP: that mostly depends on video card you have and video driver you use
<profoXP> ivoks, 3 pcs use ATI (2x fglrx [proprietary] , 1x radeon [too old for fglrx] ), one uses Nvidia (nvidia [proprietary] ).
<thom> bah, the tailor in dapper doesn't work with bzr 0.8
<ivoks> profoXP: that's 5, not 4 :)
<ivoks> profoXP: and this conversation is for #ubuntu, so let's continue it there, ok?
<profoXP> ivoks, are you sure
<profoXP> ivoks, well, they pointed me here
<profoXP> lol
<leo__> how is your xorg.conf generated on a livecd ?
<iwj> Just to confirm, we're expecting to have the distro meeting on Thursday at 0800Z ?
<sfllaw> That's what the calendar says.
<ogra> Z?
<sfllaw> Zulu time.
<ogra> heh
<Keybuk> mjg59: ping?
<Kamion> thom: IIRC they created an 'arry' directory so they could use -Larry
<Kamion> iwj: yes, that's what https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-May/000142.html says, and as far as I know there've been no changes to that
<thom> Kamion: ah, that was it yeah
<iwj> Kamion: Yes, that was my source.  I just wanted to double-check I hadn't missed a change ...
<Keybuk> Kamion: does d-i keep its own internal copy of bogl anywhere?
<Kamion> Keybuk: not to my knowledge; it uses bogl-bterm which is from the bogl source package
<Keybuk> right
<Keybuk> which appears to be a different bogl than the one in usplash
<Keybuk> ho-hum
<Keybuk> Matthew clearly used some black magics to pull a future version of bogl out of the ether :p
<Kamion> IIRC we hacked cfb support into usplash's bogl ...
<Kamion> I definitely remember doing something for powerpc
<Kamion> I thought Matthew said he'd sent the changes to Daniel upstream, but I may be misremembering
<Keybuk> it's the sudden implementation of bogl_move() I'm more interested in
<Keybuk> the other diff is mostly just indent changes, which aren't very mjg59esque
<Keybuk> (he's not one to go in and retab code just because he's in there)
<Kamion> usplash (0.1-9) breezy; urgency=low
<Kamion>   * Implement bogl_move for cfb, thereby porting to powerpc.
<Kamion>   * Draw everything in a 640x480 window in the centre of the framebuffer, no
<Kamion>     matter how large the framebuffer is.
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Thu,  8 Sep 2005 00:28:54 +0100
<Kamion> didn't do any reindentation there though
<Keybuk> fair enough
<jono> hey all
<Burgwork> hey jono 
<jono> hey Burgwork
<highvoltage> hey Burgwork
<highvoltage> hey jono :)
<jono> heya highvoltage
<highvoltage> how are things in kde land?
<jono> its nuts how difficult it is to download Vista from MSDN - I am looking into doing some competative analysis, and you just can't download anything without IE it seems
<jono> highvoltage: oh, I am not a KDE guy any more :)
<profoXP> jono, lol
<profoXP> jono, my friend runs vista beta2 in school
<profoXP> jono, he says his first impressions were good, but after some time he found out it's really sucky and buggy
<highvoltage> d'oh! for a moment i confused you with Riddell (long day)
<jono> highvoltage: I spent much of my time working on other stuff now, including LUGRadio in which we recently interviewed sabdfl
<profoXP> jono, and it requires alot of hardware power
<jono> highvoltage: heh, no worries
<highvoltage> i listened to that interview. i think lugradio is quite cool.
<jono> I think a solid idea of Vista will be useful for developing edgy specs
<jono> highvoltage: thanks :)
<profoXP> jono, i dont know. vista is just a "hack" of every other operating system. It uses ideas from Linux/KDE/Gnome/MacOS
<profoXP> its not really bleeding edge
<highvoltage> i think vista will be disappointing from what we've seen from the screenshots. it seems like windows XP with a darker, 'crystal' theme, with a sudo-like tool. it looks very boring even compared to dapper, imho
<profoXP> highvoltage, they just incorporate every single idea other people had
<profoXP> everything I have seen in both Live MSN and Windows Vista is a rip
<profoXP> then again, the whole history is a rip-off
<mgalvin> Seveas: ping
<highvoltage> they don't have a 11GB repository of great software :P
<wasabi> This is a bit off topic.
<jono> well I think they have some interesting ideas in Vista, but we will see,but this is off topic
<wasabi> A *bit*.
<highvoltage> sorry, yes. (me stops on this)
<profoXP> (i studied operating system history in my free time :))
<jono> right, meeting, later all
<profoXP> jono, good ideas. jup. but most are stolen (if not all)
<profoXP> later
<jono> have fun :)
<profoXP> hey guys, are you busy with improving native "suspend-to-disk" and "suspend-to-ram" support, so that it works out of the box after installing proprietary video drivers ? i fixed it for nvidia following this wiki entry : https://wiki.ubuntu.com/NvidiaLaptopBinaryDriverSuspend
<profoXP> I only tried suspend-to-disk yet
<profoXP> (Nvidia, ACPI)
<Tonio_> hello
<dieman> profoXP: have you filed a bug against something yet?  I'm guessing acpi-support would be a good choice.
<profoXP> dieman, nyea... i will.. i have to figure out more first :)
<Seveas> mgalvin, ?
<bddebian> Heya pygi
<mgalvin> Seveas: you have been hosting those -changes rss feeds right? would it be possible for you to host an ubuntu-news feed by any chance?
<mdz> ogra: changelog for g-s-s 2.14p2?
<ogra> mdz, i think i added everything to the debian changelog, wait, i'll upload it to rookery
<profoXP> Anyway, how does suspend work exactly ? on what is suspend based ? suspend2 or swsusp.. or where can i find alot of 'technical' documentation (the wiki doesnt have information like this)
<Seveas> mgalvin, how's ubuntu-news spread? Wouldn't using the fridge (which gives you rss 'for free') work better?
<ogra> mdz, http://people.ubuntu.com/~ogra/ChangeLog
<LaserJock> mvo: thanks :-)
<mgalvin> Seveas: well it was suggested that we create an rss feed for the new newsletter... i don't know if they will always end up on the fridge or if that is the best solutions (jdub might know)
<mvo> LaserJock: you are welcome :)
<mgalvin> Seveas: your feeds were the first thing that popped into my head
<Seveas> hehe
<LaserJock> mvo: I'm glad you mentioned Python, I totally spaced it
<jdub> mgalvin: it will always be on the fridge, *totally*... might even be worth making a category for it
<Seveas> those feeds are simply parse-mail-and-put-it-in-rss scripts that make quite a few assumptions about the input they get
<Seveas> jdub, rock!
<jdub> mgalvin: and with the upcoming upgrade to the fridge, it'll be easier for you to contribute directly
<mgalvin> jdub: that would be cool!
<mvo> LaserJock: no problem, keep me updated on the package
<LaserJock> mvo: np
<mjg59> Keybuk: Hi
<mjg59> Keybuk: I had to implement bogl_move from scratch - it was just a null pointer upstream
<Keybuk> yup, that's what I noticed
<Keybuk> just caused me a surprise :)
<Tonio_> mdz: hello ! sorry for bugging you with this, but did you have a look at the debdiff I sent you concerning streaming configuration in kubuntu ? we would like to get that eventually uploaded :)
<mdz> Tonio_: didn't see the email; when did you send it?
<Tonio_> mdz 5 days ago, let me check....
<Tonio_> mdz: hum.... I purge the sent folder.... maybe you can search with my email address (tonio@ubuntu.com)
<Tonio_> mdz: it was on 06/03 or 02
<Riddell> mdz: I have another dapper-update for review http://muse.19inch.net/~jr/tmp/qt.diff
<mdz> Tonio_: nothing from tonio@ubuntu.com in May or June
<Tonio_> mdz: gaps......... I will resend now ;)
<mdz> Riddell: ABI change?
<Riddell> mdz: shouldn't be, it only touches files in src/kernel which is internal to Qt
<mdz> Riddell: is it upstream already?
<Riddell> mdz: no, although the patch does come from upstream (trolltech)
<profoXP> The system log tells me that Ubuntu uses swsusp for suspending. Wouldn't it be better if we switched to Suspend2 ? I have a really hard time with getting swsusp working on all my linux boxes, but I never had any real problems with Suspend2 (except with fglrx, but there is a fix for that)
<profoXP> "Suspend 2 has a long feature list, including the ability to cancel a suspend by pressing Escape, image compression to save time and space, a versatile plugin architecture, and support for machines with Highmem, preemption and SMP."
<profoXP> Here is the status of working hardware: http://www.suspend2.net/status
<Tonio_> mdz: you should have the mail now
<pygi> hey bddebian  ;)
<Burgwork> Kinnison, haven't you moved yet?
<Kinnison> Burgwork: yes
<Kinnison> Burgwork: I moved a couple of weeks ago now
<Kinnison> Burgwork: If you're referring to the interview, it was done in april
<Burgwork> Kinnison, indeed, congats on the move
<Kinnison> Thanks
* Kinnison is busy almost every evening with painting etc
<Kinnison> Speaking of which I ought to go and look at doing some chores soon
<bddebian> Ah yes, the "joys" of home-ownership :-)
* Treenaks will be one from tomorrow morning
<Kinnison> I had that before. The issue is that I've gotta get the new house tidy :-)
<Kinnison> Treenaks: congrats
<Treenaks> Kinnison: thanks
* Kinnison has been a homeowner for nearly seven years now and I welcome you to the party
<Kinnison> I wish I could say it gets easier :-)
<Burgwork> sfllaw, ping (re: SoC mentoring)
<Tonio_> mdz: did you receive the mail this time ?
<mdz> Tonio_: yes
<Tonio_> mdz: great
<sfllaw> Burgwork: Pong.
<Burgwork> sfllaw, have you had a chance to chat with Parag M. Baxi, 
<sfllaw> I have.
<Burgwork> and?
<sfllaw> I should ping him again today.
<sfllaw> http://www.eden.rutgers.edu/~jigtopi/ghee22_blog/
<sfllaw> His development blog is sort of empty.
<Burgwork> sfllaw, I am deeply concerned about the focus his soc is taking and how it integrates into the rest of the Ubuntu
<mdz> mjg59,Keybuk: will you make it to TB in a couple of hours?
<sfllaw> Burgwork: I have asked him to consider how it would integrate with Ubuntu.
<Keybuk> mdz: I will
<Burgwork> sfllaw, yes, he and I had a long discussion in -doc the other day
<sfllaw> I'm afraid that what's going to happen is he's going to go careening off into snapshot-taking land, and do what he thinks is heavy-lifting.
<Burgwork> sfllaw, for me, the sanest place I think he can work is either on yelp or ubiquity
<sfllaw> It's actually not a big problem for a welcome-center application to occur.  For instance, an "intro-to-your-workstation" application would be a godsend for sysadmins.
<highvoltage> sfllaw: hey there. are you still interested in the dial-up team for ubuntu?
<Burgwork> sfllaw, sure, but that can be done in yelp
<sfllaw> Burgwork: Perhaps.  I find yelp's interface a bit icky.  But that makes sense.
<sfllaw> highvoltage: I am.
<Burgwork> sfllaw, yelps interface is icky because nobody is working on it
<sfllaw> highvoltage: In fact, it's on my TODO list to contact you when I've done so.
<sfllaw> Burgwork: Does this guy have the skills to hack on yelp.
<pygi> sfllaw, the student must have at least weekly reports on blog
<sfllaw> pygi: Yes, I have to ping him.
<mjg59> mdz: Yup
<highvoltage> sfllaw: great!
<pygi> Burgwork, may I suggest we go for a "global attack" on range of all students to see what have they done by now?
<pygi> and come up with a plan to make sure everything goes as planned
<Burgwork> pygi, sure, that sounds good
<Burgwork> sfllaw, yes, he did mention he knows more C than Python
<pygi> Burgwork, k, I'll be back around in like two hours
<pygi> is that appropriate for you?
<Burgwork> I will be and still at work
<pygi> oki, great then
<Burgwork> pygi, weekly reports on the blog would make that today
<pygi> I have student which did two reports already
<phanatic> pygi: who was that guy? ;)
<pygi> phanatic, you :)
<Keybuk> woohoo!  snapshot-stealer just ate another day
* Keybuk waits with excitement to see what is next
<Keybuk> 2005/09/29!
<Keybuk> only 9 months to go
<Keybuk> *sigh*
<bddebian> Huh?
<Keybuk> bddebian: trying to grovel together enough sources to run merge-o-matic again
<Keybuk> I'm "politely" leeching every single source every placed on snapshot.dn
<bddebian> Keybuk: Ah, nice :-)
<mirak> hi
<mirak> I don't understand why the installer doesn't propose pppoe config as a choice to connect to the internet
<mirak> if you don't have a router you can't connect to internet if you have dsl with pppoe
<mdz> you can, but you  need to configure it after installing
<mirak> mdz: yes but the installer asks before to connect to the net
<mirak> before you can even chroot to the target
<mirak> here if you don't have a router or a box that's the standart conection type for dsl
<mirak> with cable it's dhcp
<profoXP> ivoks, i fixed it on my ati laptop :)
<profoXP> ivoks, was something wrong with ndiswrapper
<ivoks> nice
<profoXP> ivoks, i have to rmmod ndiswrapper once, but for some reason it will still stay loaded as a module, but then suspend will work.. if i rmmod it twice, the system freezes.. very strange
<Keybuk> "UBUNTU WILL LOOSE MILLIONS OF USERS" ... that's nice, then they'll stop bitching on the bug that the fix didn't make it into dapper and will be in edgy instead
<Keybuk> *sigh*
<Keybuk> Malone so needs a "mute" button
<Keybuk> or at least a status that means no further information is required, and prevents anyone commenting
<Keybuk> :p
<infinity> Which bug is going to "loose" us millions of users?
<Keybuk> meh, I can never spell that word
<Keybuk> the one where we do bus enumeration in tree order, rather than logical id order
<Keybuk> so pick up Thinkpad docking station IDE controllers before the internal one
<Kinnison> What's gonna happen if we loose millions of users? Won't there be a big mess on the floor?
<Keybuk> so their hard-drive is hde when docked, hda when not
<jdub> Kinnison: not if we arm them with cricket bats and corkscrews!
<infinity> Ahh, I doubt you'd find milliolns of users who even own docking stations, but yes, an irritating bug.
<tseng> you can apperantly get kicked out of debian for using a bat
<Kinnison> jdub: Now you're talking!
<Keybuk> it's very irritating, because there's a few people who just won't shut up about it :p
* Kinnison goes to investigate his CD changer
<Kinnison> ciau
<Keybuk> "yes, it's broken; yes we'll fix it in edgy; now go away and stop bugging me!" :)
<infinity> I'd rather focus on getting d-i and initramfs to agree about module load order.  That's a more widespread detection bug.
<Keybuk> I think that may be part of it
<infinity> (Or stop having multiple drivers for the same hardware, whichever)
<Keybuk> yeah
<Keybuk> that bit would be nice
<bddebian> Bah, how boring ;-)
<infinity> The upshot is that that bug is now cleverly hidden on desktop installs, since we do hardware detection the same on the livecd and the installed system.
<trappist> Keybuk: can that be worked around with ide=reverse?
<trappist> (out of curiosity)
<infinity> But it still bites server installs, where it seems to matter for some Adaptec i2o controllers, at least.
<ivoks> urgh... why not set up greylisting on @ubuntu.com addresses? :)
<sladen> infinity: bug #6367
<Ubugtu> Malone bug 6367 in grub-installer "udev enumeration should use /sys/bus not /sys/devices" [Normal,Unconfirmed]  http://launchpad.net/bugs/6367
<infinity> sladen: I tihnk the docking station thing is a different bug from the "we have two drivers for adaptect i2o cards, and d-i and initramfs pick different ones"
<infinity> (Which leads to the installer thinking your root is /dev/i2o/hda1, while the installed system has /dev/sda1)
<infinity> Fun.
<sladen> okay, that one's a difference bundle of fun
<Keybuk> trappist: no
<Keybuk> infinity: ah, the i2o bug?
<infinity> Keybuk: Yeah.  Very irritating.
<infinity> Keybuk: Ideally, we should make sure the new driver (that uses the SCSI subsystem and plain SCSI devices) handles all the hardware that the old one does and just drop the old one.
<infinity> Keybuk: But that's still just covering up for the "d-i and initramfs disagree" thing, which should be fixed, obviously.
<Keybuk> I haven't ever gotten a straight answer out of Tollef which one is *right*
<infinity> Well, the new one is "right" for all the hardware it handles.  What we're not sure of is if it handles ALL the same hardware.
<sladen> a key thing for the upgrades is going to be able to predictably emulate the old assignments, so that they can be migrated to the new mapping
<infinity> This is true for lots of devices that will change names in edgy.
<Keybuk> sladen: easy, change everything to UUID= :p
<sladen> Keybuk: btw, when you discovered the cause of that bug at T-3.5weeks.  I think it should have gone in there.  It was only T-1week when I noticed that you'd found the solution
<Keybuk> does anyone know the probability of PATA-in-libata landing in edgy's timeframe yet?
<infinity> We should be almost entirely /dev/sd* in edgy.
<Keybuk> sladen: we thought about it, the problem was that the fix could well break a lot of other installs
<infinity> Keybuk: I'm banking on it happening.
<mjg59> Keybuk: Define "landing"
<Keybuk> ie. suddenly a lot of people's hde's becoming hda
<mjg59> In our kernels? Probably
<sladen> Keybuk: yeah, but that has happened (in reverse) anyway for approximately the same number of people doing an upgrade (and it's going to hit the same number on dapper->Edgy migration_
<mjg59> The upgrade manager should just migrate everything to uuids
<Keybuk> sladen: ah, the cunning plan about the dapper->edgy migration is we have to change them from hd* to sd* anyway, so they won't get bit <g>
<infinity> mjg59: That doesn't help server installs.
<mjg59> That can be done programmatically
<mjg59> infinity: Oh, crap.
<sladen> Keybuk: I would have rathered that it broke a $few people but stayed compatible with other distributions (every other distributor, aswell as hoary and edgy)
<Keybuk> sladen: and the sad, but true truth is that it's easier to cope with a bug you know than a bug you don't
<infinity> mjg59: We can't really use update-manager as a crutch to avoid proper upgrade paths.
<mjg59> Ok. udev hackery for the win, I guess
<Keybuk> this bug only affects hard-drive naming in a very, very specific circumstance that we can identify; and there is a known workaround
<mjg59> It's less of a problem with servers, since we can follow the enumeration rules ourselves
<Keybuk> changing the emumeration to logical based would likely break a lot of other things like non-harddrives
<Keybuk> mjg59: easy
<Keybuk> in the postinst (under the old kernel) read the uuid of every drive and change the mappings
<_ion> Will the edgy installer still create a swap partition? Using swap files allocated on demand would be cool.
<Keybuk> that way, when it boots, it works <g>
<Keybuk> _ion: they'd be cool, if we supported them, which we don't
<mjg59> _ion: While we still need swap partitions for hibernate, yes
<Keybuk> they flat out don't work in dapper, for example
<mjg59> Why does this Sony take such a ridiculously long time to charge?
<Keybuk> everyone gets enthusiastic, tries it, it breaks, they file bugs
<Keybuk> (not to say we can't make it work in edgy, obviously)
<Keybuk> but it should probably work before the installer does it by default :p
<sladen> _ion: if you want it, start a spec.  The main thing to work out are all the requirements that it would need, and which don't currently work
<kagou> hi ivoks 
<kagou> ivoks: i'v you built cupsys packages with alternate pstops filter ?
<ivoks> kagou: have i?
<ivoks> kagou: no
<kagou> ivoks: ok. i suspect pstops problem in a bug so i will try to compile cupsys with it (http://cups.org/links.php?V59)
<ivoks> kagou: yes, it might be... since only raw printing works :/
<kagou> indeed
<Kamion> mirak: the reason why pppoe isn't proposed is that nobody's ever written the code, and nobody with sufficient clue to hack on netcfg competently actually seems to have a pppoe line
<Kamion> _ion: extending partman to support swap files would be "interesting" ... well volunteered ;-)
<mirak> Kamion: ok
<mirak> I though it was some choice
<mirak> Kamion: but that would be really nice for newbies
<mirak> that's the main drawback here I  think
<mirak> we have lot of pppe
<mirak> o
<kagou> ivoks: Bug #34112 a patch is proposed
<Ubugtu> Malone bug 34112 in libgnomecups "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
<_ion> kamion: I'll consider that when i get better. :-)
<ivoks> kagou: this isn't related to cups? :)
<kagou> ivoks:  :) i hope this patch works
<infinity> Kamion: My connection is pppoe (though behind a router)... I can toss my router in bridge mode and do the pppoe connection from my laptop to hack...
<ivoks> kagou: yes, this is ugly bug
<ivoks> kagou: anyway, i can't apply it, but we can test it, right?
<kagou> right. i will test it tomorrow, at work See you later
<ivoks> kagou: bye
<pianoboy3333> Can anyone help me set up a svn on my website?
<Kamion> infinity: patches welcome, then :-)
* ogra wont tell Kamion that pppoe is the german standard proto for dsl, no he wont :)
<infinity> Kamion: Fell free to poke me about it post-Paris.  I've used the pppoe stack a few times here to debug stuff, so it's not entirely unfamilair to me.
<infinity> s/Fell/Feel/
<dieman> heh, i nearly forgot about the insanity of french national holidays
<dieman> luckily it doesn't look like the summit lands on one
<robertj> mdz: I wanted to give you an informal ++ on your automated backup server location idea
<dieman> i *used* to have a pppoe line
<Keybuk> I have a pppo? line
<Keybuk> but it's dealt with by the little black box plugged into it
<dredg> i ditched mine for cable. 6meg of joy
<mjg59> Keybuk: I'm pretty sure the entire UK is pppoa, even the LLUed ones
<Keybuk> I assume it is oA yeah, but I've never plugged anything into it to find out
<mjg59> Anyway
<mjg59> I've got 8Mbit ADSL now, so I'm happy enough
<mjg59> 802.11b is the weak point in my network now
* jdub can't wait until he's port-switched
<Keybuk> heh, my LLU is currently purring at ~20Mbit
<dredg> pity, ireland is pppoe everywhere (except from BT and only in certain exchanges and costs a bloody fortune)
<mjg59> Hm. I don't even have any 10mbit around any more
<Keybuk> which is rather nice
<Keybuk> bittorrent still sucks though
<jdub> 8Mbit with the current modem, then 24Mbit when i get a new one
<Treenaks> jdub: nice, I hope you live close to the CO then
<infinity> jdub: Who's your provider?
<jdub> internode
<jdub> currently on a telstra port though
<mjg59> My modem chipset is capable of 24mbit, but DLink have failed to provide an upgrade for the firmware
<infinity> Ahh, I'm with iiNet at 24Mb/s
<jdub> infinity: working well?
<mjg59> Keybuk: Do we not have pcmcia-cs in dapper-updates yet?
<jdub> they didn't halve your bandwidth when they halved their profits?
<mjg59> People still seem to be getting bitten
<infinity> Not too bad, though my line length is a bit long, so I only get ~18Mb/s on a good day.
<Keybuk> mjg59: should be
<mjg59> Keybuk: And update-manager definitely pulls from dapper-updates?
<Keybuk> mjg59: *mumble*
<Keybuk>  pcmcia-cs | 3.2.8-5.2ubuntu5 |        dapper | source, amd64, hppa, i386, ia64, powerpc, sparc
<Keybuk>  pcmcia-cs | 3.2.8-5.2ubuntu6 | dapper-updates | source, amd64, hppa, i386, ia64, powerpc, sparc
<Keybuk> assuming that the pcmcia-cs update is correct
* dredg thanks some random deity that he doesn't have to support dapper yet
<Keybuk> it would be worth finding such a person and getting them to check that after a reboot
<mjg59> (Do I mean update-manager? Pointy clicky breezy->dapper)
<Keybuk> I guess we'd have to ask mvo
<Keybuk> I thought it did
<mjg59> Heh
<mjg59> Or check the source
<Burgwork> can we code to update-manager to check if -updates and -security is not enabled and warn the user?
<Burgwork> s/we code/we add code/
<Keybuk>                     self.sources.add("deb", uri, self.toDist, comps)
<Keybuk>                     self.sources.add("deb", uri, self.toDist+"-updates", comps)
<Keybuk> oh, ick
<Keybuk> it only puts dapper-updates in if you had breezy-updates in 
<mjg59> Ah
<mjg59> Can we fix that?
<Keybuk> it's fixable, again ask mvo
<mjg59> No mvo to poke
<Keybuk> do we know somebody who has definitely been bitten?
<infinity> Err, but you wouldn't have the update-manager from breez-updates installed unless you have breezy-updates enabled, generally.
<infinity> (Unless you installed the deb by hand)
<mjg59> 37430 sounds like it happened recently
<Keybuk> infinity: aye, that's what I was just thinking
<infinity> So, while I think it's a bug, it's also one that shouldn't bite much.
<Keybuk> you wouldn't be using the update-manager that can do dist-upgrades
<mjg59> Or rather the latest comment in 37430
<mjg59> Maybe we should change the installation docs?
<mjg59> Not that it's likely to help, but still
<mjg59> Alternative would be to fudge pcmcia-cs into dapper itself...
<Keybuk> it does sound like it
<Keybuk> mjg59: we can't do that :-/
<mjg59> Keybuk: Policy or launchpad?
<Keybuk> both
<mjg59> I think in this case we could make an exception for policy - the problem is well understood. Launchpad is trickier.
<Keybuk> there's no evidence that he didn't get the update
<Keybuk> so I think that discussion is premature at this time
<mjg59> Can we ask?
<Keybuk> it's equally likely that the update does not fix the problem
<mjg59> Heh
<Keybuk> I've posted a comment asking
<infinity> mjg59: Changing the dist post-release is generally regarded as a Bad Thing.
<mjg59> infinity: Right, but having a distro that breaks some percentage of machines on upgrade is also a Bad Thing
<feilex> hi - i would like to chat to ( mark ) sabdfl - is he still around? - I have an internet security question
<Kamion> ... why do you need to talk to Canonical's CEO for that? :)
<stuNNed> test...can you read this?
<dredg> nope.
<Treenaks> stuNNed: Must be encrypted..
<stuNNed> probly :P
<stuNNed> how to use git?  i need to "git" a driver for ppc broadcom wifi and i will paypal....
<mjg59> stuNNed: The driver in dapper is pretty much what's in git currently, I believe
<mjg59> What problem are you having that you believe to have been fixed?
<stuNNed> checking...
<stuNNed> bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.
<Kamion> stuNNed: install bcm43xx-fwcutter and run /usr/share/bcm43xx-fwcutter/install_bcm43xx_firmware.sh as root (assuming you have another Internet connection on that machine)
<Kamion> we don't have legal permission to distribute the firmware in Ubuntu proper, I'm afraid; we've tried to contact Broadcom and got nowhere
<stuNNed> unfortunately linuxant doesn't do ppc 
<Kamion> yes, you shouldn't need linuxant with the instructions above
<stuNNed> where can i submit funds?  (small amount at the moment...inbetween jobs...)
<ogra> http://www.ubuntu.com/donations?action=show&redirect=Donations
<stuNNed> i donated to linuxant anyways...should i ask for refund?
<stuNNed> thanks ogra
<stuNNed> ogra: you guys need to use an easier way to donate than using a paypal account imho...alot of ppl don't trust ebay and affiliates...
<ogra> not my chioce
<stuNNed> send it up, if you will.
<stuNNed> Kamion: omg just run that command and it works?
<tseng> i don't see a reason to donate openly to ubuntu
<stuNNed> tseng: why?  are you in a fraternity?  what's the deal?
<tseng> it is well funded enough, if you want to support it buy a contract
<stuNNed> with what?  my measley two dollars?  best way is probly create bounty
<tseng> I guess.
<tseng> i am not aware of anything funded by ubuntu foundation atm
<tseng> I guess it might be a worthy cause someday
<stuNNed> dude i cannot afford a "contract" sorry and i think a way to quickly donate, easily, would benefit or no?  does it open the door for fraud or something are you thinking?  i don't get it.
<Kamion> stuNNed: should do
<Kamion> modulo driver flakiness
* Kamion -> bed
<stuNNed> Kamion: very brilliant, thanks.
<stuNNed> Kamion: good rest
<delire> is it proper to ask about a possible bug here before submitting? i can't find a simile in the bugtracker.
<tseng> delire: not generally, as the appropriate developer isnt even guaranteed to be listening
<tseng> if you file a duplicate bug after making your best effort, it will be marked as such
<delire> ok, i'll register it regardless.
<tseng> no real harm
<delire> cheers.
<tseng> thanks.
<jcole> anyone here know how to create a bootable sparc iso?
<jcole> mkisofs -r -J -o $(TEMP_MINIISO) -G /boot/isofs.b -B ... $(TEMP_CD_TREE)
<jcole> i get a "mkisofs: No such file or directory. Cannot open '/boot/isofs.b'." error
#ubuntu-devel 2006-06-07
<jono> hey
<mdke> evenin
<pygi> night
<Kamion> jcole: you'll need silo installed for that to work; otherwise, download silo_1.4.10-0ubuntu4_sparc.deb from the archive, 'mkdir boot1; ar p silo_1.4.10-0ubuntu4_sparc.deb data.tar.gz | tar zxf - -C boot1 ./boot/{isofs,second}.b', and change '-G /boot/isofs.b -B ...' to '-G boot1/boot/isofs.b -B ... boot1'
<Kamion> (the latter was derived from how debian-cd does it)
<jcole> Kamion: i'll try that
<jcole> Kamion: thatnks
<mdke> mmmm good news http://blogs.gnome.org/view/carlosg/2006/06/06/0
<nexu> when will ubuntu be ready to ship dbus 0.61?
<nexu> python-dbus 0.60 has a very annoything bug
<mdke> nexu: did you find it in our bugtracker?
<nexu> mdke: negative
<mdke> nexu: it's going to be difficult for it to get fixed if it isn't in there
<mdke> nay, impossible
<ajmitch> morning
<nexu> mdke: i heard dbus guys saying that ubuntu hasnt bumped the dbus to 0.61 due to some binary incompactibility with something i cant really remember what it was but that was from 2 months ago 
<nexu> heard from *
<Keybuk> when was 0.61 released?
<nexu> "there was a minor binary imcompatible change that required a rebuild of gnome-power-manager 2 months ago"
<Keybuk> it's likely that it was too close to our UpstreamVersionFreeze to be considered for dapper
<nexu> is there *any*  repo atm which has 0.61 dbus ?
<Keybuk> Ubuntu, no?
<Keybuk> we haven't opened our new development release yet
<mdke> nexu: if the bugfix is backportable, and you file a bug, you never know, it might be considered for Ubuntu 6.06
<nexu> mdke : i pretty much suck at bug reporting heh
<mdke> nexu: but the Ubuntu developers pretty much suck at fixing bugs they don't know about, so it's worth a try
<mdke> maybe they know about it already, maybe not
<nexu> mdke: haha ok, fair enough
<nexu> i'll give it a try
<nexu> gonna try to diff the python2.4-dbus source atm first
<nexu> see whats the difference
<nexu> that of ubuntu and dbus cvs
<mdke> good luck
<nexu> ty
<jcole> bug 46665
<Ubugtu> Malone bug 46665 in debian-installer "[ia64]  Failure to mount root filesystem after install" [Normal,Unconfirmed]  http://launchpad.net/bugs/46665
<Keybuk> *sigh*
<Keybuk> mom needs more hamsters
<Keybuk> jcole: ?
<jcole> Keybuk: sorry about that, we're talking about that bug in another room
<Keybuk> ah
<Keybuk> it's one of those general "d-i does things differently to udev" bugs :-/
<Keybuk> it would be nice if we could fix all of them
<svu> why not change ppc ubuntu builds to ppc64?
<Keybuk> they are ppc64s I think
<infinity> The builds, not the buildds.
<infinity> svu: There's no value in building binaries for ppc64 by default.
<svu> Keybuk, only the kernel. all the rest is ppc32, according to file /usr/bin/*
<infinity> svu: They just end up bigger and slower.
<Keybuk> svu: that's normal
<Keybuk> you don't want a 64-bit userland on ppc (or sparc)
<svu> infinity, why slower? wouldn't it take advantage of faster operations on long operands?
<mjr> cache-hogs
<Keybuk> infinity: heh, clearly it is getting late
<svu> Keybuk, why? why do people create 64-bit CPUs anyway?:)
<infinity> svu: we provide a 64-bit libc, and for specific applications that will benefit from being compiled for ppc64, that can be done.
<Keybuk> I think the AMD64 is pretty unique that it actually runs better in 64-bit mode than 32-bit, no?
<mjr> Keybuk, pretty much
<infinity> svu: In the general case, you lose performance.
<Keybuk> that's more the suckage of ia32 though
<infinity> Keybuk: Yeah, amd64's architecture changes made porting a huge win.
<mjr> Keybuk, pretty much :)
<infinity> Keybuk: But that's a rarity.
<svu> infinity, funny. Is there a special page in wiki regarding libc64 and all the apps taking advantage of 64-bit mode?
<infinity> svu: The same is true for sparc/sparc64, hppa/hppa64... You always want a 64-bit kernel, but you almost never want a 64-bit userland unless you know you do.
<Chipzz> I'm wondering if we couldn't optimize gcc to use 16-bit registers on i386
<Chipzz> or even 8-bit :P
* imbrandon64 shoves Chipzz off a 4bit cliff
<svu> infinity, what kind of advantage do I get with 64-bit kernel then?
<Keybuk> I still have the Osbourne 4 and 8-bit Microprocessor Handbook somewhere
<infinity> svu: The advantage of being able to run a few 64-bit binaries if you really need them?
<Chipzz> I was only half-kidding actually
<infinity> svu: And just the obvious case that on your hardware, people are probably testing the 64-bit kernel codepath more than the 32-bit one.
<ajmitch> Keybuk: nice, all I have is one on 6502 assembly 
<dieman> and you can actualy use your memory if you have it
<svu> infinity, :)) I see. I can run 64-bit binaries - but they are just not there in ubuntu:)
<dieman> whomever came up with PAE on i386 should be shot, too
<dieman> they should have just decided 'damnit, lets do something 64 bit'
<infinity> svu: What specific binary did you want t obe 64-bit?  Or is it just the principle of the thing?
<dieman> rather than confusing the hell out of people who dont know how PAE works
<Chipzz> a wild guess would be 40% or even 50% of all integer vars would fit in 16-bit containers
<dieman> and thinking they can allocate over 4gb of memory
<infinity> dieman: PAE is scary.
<dieman> infinity: yes
<dieman> infinity: you ever see the benchmarks that heanet.ie did with apache and pae?
<svu> infinity, well, just the principle. In particular, I wonder would all the build tools (autotools/gcc/ld/....) work faster if they were 64-bit. Also OOo
<dieman> infinity: 4GB was about the same peformance as 12GB
<dieman> infinity: but 32GB you'd actually be doing fairly well
<Chipzz> svu: OOo definately not
<Keybuk> svu: why would they be faster?
<mjr> svu, they wouldn't.
<dieman> infinity: (mostly acting as disk cache)
<svu> Keybuk, faster data operations?
<Keybuk> autotools is written in shell/perl -- that'd be hauling twice as much around, so be half the speed
<HrdwrBoB> at that point, you'd be better off with a RAMSAN
<infinity> svu: No, no, and no.  And OOo won't even compile on 64-bit systems.
<HrdwrBoB> (though I think everyone is better off with RAMSAN)
<Keybuk> svu: what makes you think 64-bit data operations are faster than 32-bit ones?
<Chipzz> svu: doesn't matter one bit for small integers
<HrdwrBoB> infinity: we're lucky it compiles at all
<svu> infinity, ok, I see.
<Keybuk> svu: unless you're dealing with >32-bit word sizes
<dieman> HrdwrBoB: they've got way too much disk though, i think
<dieman> HrdwrBoB: its not just for a few GB of files, its more like a few TB im guessing.
<svu> Keybuk, in SOME cases people use "long long", or even memcpy...?
<Chipzz> svu: less cache hits, especially with OOo
<dieman> HrdwrBoB: and i think they still use the apache disk cache module to pull popular files automatically to a striped raid
<Keybuk> svu: you win some, but lose a lot from the larger instruction and data sizes
<dieman> HrdwrBoB: and then an assload of ram for disk caching
<Keybuk> 64-bit is basically useful for doing complex integer math
<Keybuk> eg. SSL or MPEG or something
<svu> infinity, what about altivec extension? is it used by ubuntu?
<infinity> Keybuk: Or hauling massive datasets around.
<HrdwrBoB> dieman: well.. damn!
<Chipzz> svu: just about the only thing it does make sense for by default is things like memcpy, and those are in glibc
<dieman> HrdwrBoB: yah
<infinity> Keybuk: Some SQL servers seem to win from being 64-bit (if you have massive tables and indexes)
<svu> Keybuk, ok, I see now...
<Keybuk> yeah, that I can believe
<infinity> Keybuk: But for most SQL usecases, 32-bit wins, so you really need to KNOW that you want 64-bit before you take the hit.
<infinity> svu: ^^^^
<svu> Chipzz, yeah, that's what I meant - massive memory operations
<Keybuk> I always find it amusing that almost the only 64-bit app in Solaris 9 was "sort"
<Keybuk> it was the only one that benefited
<infinity> svu: As a general rule, if you think that a dedicated machine of some sort may benefit from having something specific recompiled (say, postgresql, for instance), we provide the tools for you to easily do that and benchmark.
<infinity> svu: Down the road, we intend to have better multiarch support, so it'll be trivial for us to provide ppc64 versions of certain libraries and applications that you MAY want 64-bit.
<infinity> svu: But, the general use cases for just about everything will show you that 32-bit wins.  If 64-bit wins for you, you're an oddity.
<infinity> svu: (ie: massive data warehousing, etc)
<svu> infinity, ok. I am not a gentoo person, I so I am not trying to squeeze every grain of performance - just trying to get a feeling, is there possible major win against the current arch...
<Chipzz> infinity: but you can't mix 32 and 64-bits libraries anyway, right/
<Chipzz> ?
<Keybuk> Chipzz: depends on the instruction set
<Chipzz> I'm thinking calling conventions for one
<infinity> Chipzz: Can't link both in the same memory space, no.  (or, not worth trying)
<svu> infinity, ok. But I did not get the answer regarding the altivec extension?
<Chipzz> svu: stuff like that is hand-coded assembly in most cases anyway
<infinity> svu: altivec is orthogonal to the 32/64-bit thing, and where we can use it effectively, we do (mplayer autodetects altivec support and uses it, libssl has an altivec optimised version, IIRC, etc)
<Kamion> svu: altivec needs to be hand-coded, as Chipzz says
<svu> Chipzz, I know - so I am asking is there that kind of assembly somewhere in kernel or openssl or smth
<infinity> Actually not positive about the libssl thing.  Does powerpc have hwcap support?
<Kamion> there are hand-coded versions of a few things, yes
<Chipzz> Kamion: not per se I think, but your compiler needs good support for it when you don't (which is only the case in recent gcc's)
<Kamion> ok, very very recent gcc can do automatic vectorisation
<svu> infinity, i know it is orthogonal, it was a separate question:)  do you ship altivec-optimized mplayer or libssl?
<Kamion> no altivec code in openssl
<infinity> svu: mplayer, yes.  A quick look at my PPC system seems to show that we don't do hwcap on PPC, so we can't pull the "multiple optimised builds" trick that we do on i386.
<svu> infinity, heh:( BTW, would xorg opensource drivers benefit of altivec anyhow (2D/3D accel)?
<infinity> svu: libssl doesn't do run-time capabilities detection, so enabling altivec there would result in a big SIGILL on systems like mine.
<svu> infinity, I see, so you would need plenty of libssl builds
<infinity> svu: And glibc support for hwcap selection on powerpc (which appears to not exist, afaict)
<svu> (actually at some point RH provided different rpms for openssl for 386/586/686 IIRC)
<Kamion> no reason we can't do hwcap on powerpc
<infinity> (See /usr/lib/i686/ on an i386 system, for instance)
<infinity> Kamion: Nope, should be trivial, we just don't appear to do so.
<Kamion> 'strace id' shows us looking at stuff like /usr/lib/tls/ppc7450
<infinity> Kamion: Heck, I'm committing hwcap to m68k reasonably soon.
<Kamion> which looks like hwcappery to me
<Kamion> and there are hwcap defines for powerpc in glibc
<infinity> Kamion: Oh.  So PPC does have hwcap, and we just don't use it?  Even better.
<Kamion> #define PPC_FEATURE_HAS_ALTIVEC         0x10000000 /* SIMD/Vector Unit.  */
* infinity wonders why libssl isn't using it, then.
<Kamion> dunno what that corresponds to in terms of ld.so, mind
<infinity> Mayve libssl just has crap hand-tuning on PPC so no one cares.
<svu> so, we are talking about ... err tiny patch to libssl?:)
<infinity> We're talking about a patch I don't much care about, since my system's a G3. :)
<infinity> If you can convince someone with a whizzbang CPU to care more than I do, go nuts.
<svu> infinity, oops:))
* desrt recently gave away his G4 powerbook for the macbook upgrade
<desrt> but i still have a cluster of G5s at work
* svu would bye g5 quadro to infinity...:)
<Kamion> oh, actually, I think infinity's right and we don't have proper glibc support for hwcap on powerpc
<svu> s/bye/buy
<Kamion> there's no _dl_string_hwcap implementation for powerpc
<infinity> Kamion: Hrm, but the strace above seemed to indicate otherwise...
<infinity> Kamion: It could just be implemented differently.
<Kamion> yeah, dunno where that was coming from, I have a feeling it was something generic
<Kamion> at any rate I'm not seeing the linker touching /lib/altivec or anything here, which I'd expect
<Kamion> and the only matches for '"altivec"' in sysdeps are in .machine directives in assembly code, which aren't relevant
<svu> ok, so it seems the only real use is mplayer...
<svu> thanks lads, you are just eye openers;)
<Keybuk> and nobody watches *that* much porn to make it a serious benefit? :p
<infinity> svu: I had tossed around the idea of buying a quad-core G5 at one point, but I weighed that against paying rent, and opted for the latter.
<infinity> svu: If you want to send me one, I won't complain.
<infinity> For now, the old 1GHz G3 is good 'nuff.
<svu> infinity, actually I won my dual G5 at linux-powerpc contest by IBM. I would never buy any mac from my pocket:)
* dredg uses mac as desktop all the time
<dredg> i end up not breaking it :)
<desrt> svu; i tried to enter that contest and failed.
<dredg> i use ubuntu quite a lot for work, but my machine tends to be broken a fair bit :)
<svu> desrt, I  was lucky. My application just had to be "configure/make/make install"-ed - and it worked :)
<dredg> so i use a mac for doing most things, and ssh when i need linux
<desrt> crikey
<desrt> i wrote an email to them saying "please let me port a compiler backend" and got rejected
<desrt> or, more precisely, they never even replied
* svu always felt shamelessly lucky about that contest
<svu> dredg, I am thinking about removing macos altogether - but not yet...
<desrt> holy crap!
* desrt wants to play chips challenge
<desrt> anyone have chips.exe laying around? :)
<desrt> oh yes.
<desrt>  /home/desrt/archives/old nt server/rlortie/bin/chips/CHIPS.EXE
<dredg> svu: i need one machine that works at all times, so i refuse to change/break/kill the OS on the machine :)
<desrt> that ws NEAT!
<desrt> wine CHIPS.EXE -> my machine instantly reboots
<desrt> i'm pretty sure that's not supposed to be possible
<Keybuk> isn't wine setuid root, or something crazy?
<desrt> nope.
<desrt> nor is wineserver
<svu> dredg, I have ubuntu for it:)
<desrt> i think i've found a security problem
<ajmitch> desrt: probably triggering kernel or X bugs, it's probably not unusual :)
<Keybuk> desrt: likely wine crashed X, which runs as root
<dredg> svu: right, the primary project i'm working on at the moment involves customising ubuntu for our users. if i put ubuntu on the mac i'd end up using it for testing or something :)
<desrt> Keybuk; and caused the kernel to reboot?
<dredg> i _need_ an unbroken machine :)
<dredg> it's a slippery slope ;)
<Keybuk> desrt: sure, X runs as root and does nasty things to the hardware
<svu> dredg, well, I am trying to balance between development of gnome and keeping relatively stable machine (which is also controlling my X10 stuff at home)
<Keybuk> desrt: it's very easy to get X to crash the machine hard enough to reboot it
<desrt> wrong.
<desrt> it's a kernel bug
* desrt just logged in via ssh with X forwarding and ran it
<desrt> the ssh server rebooted
<desrt> read: remote user can bring the sytem down
<Keybuk> ssh server rebooted?
<Keybuk> ssh servers don't reboot
<desrt> the machine running the ssh server :p
<Keybuk> it's a local root exploit
<Keybuk> not a remote one
<Keybuk> you ssh'd in with authorisation
<Keybuk> there's plenty of those
<desrt> heh.
<desrt> i didn't say it was 'remote root'
<desrt> it's probably not even local root
<desrt> just DoS
<dredg> svu: ow. good luck with that :)
<svu> dredg, thanks:)
<dredg> and this week i get to work on a laptop cos i'm in santa monica. like fun, but subtly different :)
<desrt> running under cedega freezes the system solid (but no reboot)
<BenC> so is edgy open yet? :)
<desrt> BenC; when do you think about this bug?
<desrt> BenC; it's probably related to somethng weird like allowing userspace processes to manipulate the local descriptor table
<Kamion> BenC: needs an LP rollout in about two hours
<BenC> desrt: which bug...I missed some context
<desrt> BenC; i can reboot my system over ssh 
<BenC> are you not supposed to be able to do that? :)
<desrt> i can do it from a normal user account just by running wine on an old windows game
<BenC> ah, wine
<BenC> wine is running as root?
<desrt> no.  i don't think so.
<BenC> if it's not running as root, then that's a super serious bug
<BenC> err, super serial
<desrt> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/48769
<desrt> finding out more...
<BenC> does it happen on console as well as over ssh?
<desrt> it happens when i use X directly and with X forwarding over X
<desrt> *over ssh
<desrt> afaik wine won't run without having an X server somewhere
<BenC> right
<BenC> can you email me a copy of that game?
<desrt> sure
<BenC> or do you have a copy?
<desrt> it happens with my totally unprivilged jail user too
<desrt> so it's not likely to be something like accessing the soundcard in an odd way
<BenC> I have wine running under amd64, so it may do something different
<desrt> i already tried running it on my friends dapper (amd32) box and it doesn't crash
<BenC> it does run in 32-bit mode, but the kernel's a bit different about it since it's emulation
<desrt> i attached to the bug
* desrt violates microsoft copyright via private bugs on launchpad :)
<elmo> desrt: err, don't do that
<elmo> seriously
<desrt> surely this falls under fair use :p
<elmo> no, it doesn't
<desrt> is it possible to remove attachments?
<desrt> damn.  it kills my laptop too :(
* desrt can't play chips anywhere
<DarkMageZ> chips challenge?
<desrt> rawr :(
<DarkMageZ> u using wine from the dapper repos?
<desrt> mhm.
<bddebian> Hey
<Toadstool> heya devs :)
<LaserJock> and then Caritas will soon be uttering, "ok, very very recent gcc can do automatic vectorisation" and "i know it is orthogonal, it was a separate question:)  do you ship altivec-optimized mplayer or libssl?" to quote
<LaserJock> crap
<LaserJock> sorry guys
<ajmitch> heh
<bddebian> :-)
<tale_> I'm trying to compile eye of gnome from cvs, can somebody help me configure my environment?
<Chipzz> tale_: no; this channel is about development OF ubuntu, not development WITH ubuntu
<Chipzz> and you want apt-get build-dep eog
<tale_> Chipzz: I'm trying to find some docs that help configure ubuntu for development
<Burgundavia> tale_: #gnome-love on gimp.net can help you with that
<tale_> ok
<tale_> I'll give it a try
<whiprush_> mako: congratulations
<tale_> where do the developers hang out to talk about developer stuff when not coordinating/
<tale_> ?
<Burgundavia> tale_: of GNOME or Ubuntu?
<mako> whiprush_: thank
<mako> s
<whiprush_> I see you wore the aviators for the wedding, heh.
<Burgundavia> mako: indeed, congrats you crazy married man
<mako> :)
<ajmitch> hey mako 
<mako> ajmitch: oi
<licio> oi?
<licio> oi means hello in portuguese
<stub> Launchpad will be going down in 20 minutes for its regular code update. Estimated down time is 10 minutes.
<pitti> Good morning
<ajmitch> morning pitti 
<Burgundavia> hey pitti, can you take a look at https://wiki.ubuntu.com/FirefoxFAQ
<Burgundavia> pitti: specifically the 2nd part
<Burgundavia> hey mvo
<ajmitch> morning mvo 
<Hobbsee> Burgundavia: that second part is pretty unclear - and isnt exactly correct, IIRc
<Burgundavia> Hobbsee: it needs to be fixed. I banged it out, hence the request for review
<ajmitch> ah firefox
<ajmitch> that flagship application of the free software movement..
<Hobbsee> Burgundavia: the idea is that ubuntu has security updates, and the minor versions of firefox are released due to their security fixes.  feature-only upgrades arent included in that - that's my understanding of it anyway
<Hobbsee> mmm...lovely firefox :)
<Burgundavia> Hobbsee: yep, but we backport FF because moz has a broken security policy
<Hobbsee> true
<mvo> good morning Burgundavia ajmitch
<Hobbsee> hi mvo 
<mvo> hi Hobbsee
<ajmitch> hey dholbach 
<dholbach> good morning!
<sivang> howdy all
<sivang> finally with a good network connection.
<pitti> hi sivang 
<sivang> hey pitti , 'sup?
<Hobbsee> hey sivang 
* sivang hugs Hobbsee 
* Hobbsee tries not to collapse on sivang 
<Hobbsee> :P
<sivang> it's pretty quite the last couple of days, which is goo :-)
<ajmitch> sivang: because we're all working hard
<sivang> ajmitch: nice, on specs? :)
<ajmitch> & SoC
<dholbach> <- bugs
<Hobbsee> bye all
<sivang> ajmitch: ah right, how is Net Quth going ?
* ajmitch is setting up kerberos & ldap by hand before moving on to automating it
<ajmitch> bye Hobbsee 
<ajmitch> sivang: going well enough, got plenty to work on :)
<sivang> cool 
* sivang is off to write the next version's HUB spec
* ajmitch should rewrite the selinux spec this week
* sivang actually goes back to finishing the u-devel backlog, only 1300 msgs to go
<pygi> sivang, finally ;)
<sivang> pygi: I had terrible network problems yesterday
<sivang> pygi: I've switched locations and am back to good
<pygi> sivang, I know, don't worry :)
<pygi> sivang, you are writing to HomeBackupNg I suppose?
<sivang> pygi: I think I will just refresh the already existing spec page. -NG should be saved to the more featureful versoin. for edgy, it's  okay to call it the same name, just this time make it with all the planned features that were planned for dapper. I will save the NG page for edgy+1 and take from there all the relevant ides for edgy version.
<pygi> sivang, ah, ok
<ajmitch> morning sabdfl 
<sabdfl> hi there ajmitch
<tepsipakki> sabdfl: when will we (=!Canonical) hear more about landscape?-) I can't wait..
<jono> hey ajmitch, sabdfl
<ajmitch> hi jono 
<mdke> is there a list of languages supported on the desktop cd?
<infinity> mdke: apt-cache show ubuntu-live
<nomed> mdke, the manifest file ?
<nomed> well.. apt-cache seems much better :)
<infinity> The manifest is more correct (in the sense that it matches the ISO, while ubuntu-live chould change the next time we upload it), but checking ubuntu-live's depends was a nice lazy shortcut. :)
<mdke> thanks infinity 
<mdke> argh, no italian
<mdke> welsh, but no italian
<jono> mdke: its a crazy world
<mdke> that is pretty crazy. Loads of ubuntu users in italy, no idea how many welsh, estonian, amharic, hindi users there are. Perhaps those language packs are just smaller
<pitti> mdke: we sorted first by number of people speaking a language (the 'top 12'), then just alphabetically
<mdke> pitti: number of people speaking a language in the worl, regardless of how large the linux/Ubuntu communities are?
* ajmitch wonders if we'll get a newer PAM in edgy.. debian still carries 0.79
<ajmitch> looks like the version numbers took a huge jump after 0.81
<pitti> mdke: yes, it was the least subjective measure we could come up with at the time we defined it
<fabbione> Kamion: ping?
<mdke> pitti: I can understand that, sure. It's a bummer for communities like -it with really large Ubuntu followings though. I don't really know what we can do to alleviate the problem either... there are some unofficial italian ISOs but obviously they aren't available from shipit.
<pitti> mdke: that's precisely why we avoided introducing hard-to-measure numbers, to avoid discussions like '... but we are more important'
<pitti> mdke: so we need an objective standard
<pitti> mdke: maybe we should change it in future releases, from #people to the percentage of translated strings
<fabbione> Kamion: unping :)
<pitti> mdke: that would mean to fit fewer langpacks on the CD, but might eventually be better, since bigger coverage usually means bigger community participation
<pitti> mdke: and it could have the interesting side effect of challenge :) (translation rave to win the space on CD :) )
<ivoks> we should kick gnome out, so we can put translations... for gnome :)
<mdz> mjg59: are you coming to Paris?
<Kamion> fabbione: er, ok ;)
<fabbione> Kamion: thanks anyway .. i figured :)
<carlos> pitti: hi
<pitti> hey carlos 
<ivoks> pitti: btw, if we are going for 1.2.1, do you think it's wise to enable snmp printer detection?
<pitti> ivoks: no, not for -updates
<ivoks> pitti: i agree
<pitti> ivoks: also, I think I rather backport fixes
<carlos> pitti: could we schedule our voip call to talk about language packs for Universe?
<carlos> pitti: I would like to have something already done before Paris
<ivoks> pitti: that's fine with me
<pitti> carlos: voip doesn't work well here, let's use the normal phone
<carlos> pitti: skype?
<ivoks> khm.. ekiga guys :)
<pitti> carlos: no, I have too much latency over the chain of wireless networks here
<pitti> carlos: I'll phone you
<\sh> pitti: getting rid of the printing problems? 
<carlos> pitti: no, don't worry, I could phone you using a voip gateway
<carlos> so it's not so expensive
<ivoks> \sh: actully, there is only one printing problem
<pitti> \sh: ... some :) at least we are about to kill bug 34112
<\sh> ivoks: hehe :) you did read kurts next article about your package? ;)
<ivoks> \sh: nope
<ivoks> \sh: kde domain are offten broken, so i don't visit them :)
<ivoks> \sh: lol those packages aren't dapper 1.2.1 preview packages :)
<\sh> ivoks: you are famous now ;) 
<ivoks> "add their own README.Canonical.gz"?
<mjg59> mdz: Nope
<ivoks> he has some issues that ubuntu and cups can't resolve :)
<mdke> pitti: yeah I see all your points about the objective standard. I was just trying to figure out what communities who have been left out can do to provide localised CDs
<giftnudel> lol, the black box while printing was a cups bug? and we bugged our prof + assistants at the university about it telling them they are too dumb to produce valid pdf files (they used powerpoint) ...
<pitti> giftnudel: shall I add '* Fix printing of broken PowerPoint PDF files" into the changelog? :-P
<giftnudel> hehe
<pitti> giftnudel: seriously, it's more of a side effect
<giftnudel> yes, I noticed
<giftnudel> but still it's funny
<ivoks> time to go... see you
<zul> heylo
<makko> my ubuntu has a strange behaviour: all my mc (midnight commander) file browsing is recorded in the bash_history like (in this format: cd `echo -en "..."`); what's even more interesting is that each number within a path is represented as some sort of escaped codes (as though it is writing any digit in its ascii code). any idea what this is?
<makko> my ubuntu has a strange behaviour: all my mc (midnight commander) file browsing is recorded in the bash_history (in this format: cd `echo -en "..."`); what's even more interesting is that each number within a path is represented as some sort of escaped codes (as though it is writing any digit in its ascii code). any idea what this is?
<makko> (corrected)
<Chipzz> makko: no support in this channel kthxbye
<makko> Chipzz: does it look like i'm asking for support?
<mdke> makko: yes, twice
<Chipzz> "any idea what this is?"
<fabbione> yes
<Chipzz> YES
<fabbione> makko: -> #ubuntu
<zul> certainly yes
<makko> Chip: i got around it! now i just wanted to talk about it as of something curious.
<makko> Chip: asking for support means asking for help. i am asking for debate.
<makko> Chip: never mind.
<Chipzz> then you should have asked differently
<Chipzz> 5 people agreed within 10 seconds that yes you were asking for support
<makko> Chipzz: please show me how
<makko> Chipzz: boy, i love these democratic arguments :)
<Chipzz> dunnow, don't care either
<Chipzz> makko: take this upstream or whatever
<makko> Chipzz: yes. and you have to agree it's quite curious.
<Chipzz> makko: since you are on irc, I suppose you can read
<jsgotangco> the point is we don't need more noise in this channel
<Chipzz> read the little thingies called letters please
<makko> jsgotangco: got it, and i agree.
<Chipzz> most of the people here don't even *use* mc so would have little or nothing to contribute to your "discussion"
<Chipzz> even if that were, in some bizarre way, relevant
<makko> Chipzz: well, is there anything else you would like to add? because, if not, i will leave the channel.
* Chipzz has nothing more to add
<makko> Chipzz: ok
<zul> shesh
<Chipzz> actually I did have sth to add... "Stop highlighting me" :P
<Chipzz> but that may have been too rude :P
<zul> pitti: ping
<pitti> hi zul
<sivang> mvo: hi , besides update-manager we also have an upgrade manager right?
<zul> pitti: did you have a look at my email?
<pitti> zul: I'm at phone right now, will TTYL
<zul> pitti: ok ill be around
<pitti> zul: re
<pitti> zul: thanks for the update, I'll update the wiki page and ubuntu-cve
<zul> ok should i upload it today or wait still?
<pitti> zul: please wait, the queue is eating uploads ATM
<pitti> zul: and I'd like to get a comment from Ben about the three issues that aren't fixed in hoary and breezy
<zul> pitti: yep no problem
<tseng> mdz: I am thinking on the topic of making beagle sensible on the edgy livecd
<tseng> mdz: we can build a static index of /home (example content and such) and then autostart beagled with all the indexers disabled
<tseng> mdz: as to not thrash the live system
<Mithrandir> tseng: we can't tell it to just look in /home?
<tseng> mdz: but how to handle having it behave differently on livecd than in install?
<HiddenWolf> tseng: I guess a problem would be to fit mono on the cd.
<Mithrandir> walking through that should be fast enough.
<tseng> HiddenWolf: sure it would
<tseng> Mithrandir: it does that
<Mithrandir> tseng: oh, ok.
<tseng> I am honestly not sure if it would be that bad on a fast box
<Mithrandir> tseng: I prefer to have all hacks related to the live cd in casper and not random other packages.
<tseng> it seems at first thought like something we would want to avoid
<tseng> I guess we will have a good idea when we respin the mono-live cd
<tseng> with dapper
<\sh> re
<Mithrandir> is there any way to reject specs which doesn't make sense?
<tseng> you mean mine?
<tseng> :P
<ogra> Mithrandir, i think only mdz and sabdfl can reject specs 
<Mithrandir> no, I mean https://launchpad.net/distros/ubuntu/+spec/livecd-apt-install-to-usbflash which is covered by the live cd persistency stuff.
<tseng> I wonder if we create a static index of home and leave all backends running
<tseng> if it would touch each file and then go to sleep
<Mithrandir> you need casper to mount / with user_xattr, don't you?
<tseng> it isnt required
<tseng> but it runs like crap w/o it
<Mithrandir> so you need it. :-P
<tseng> :)
<tseng> I have been running user_xattr since before UDU
<Kamion> Mithrandir: you could mutate it into a "polish up UI for livecdpersistency" spec
<Kamion> Mithrandir: (livecdpersistency is great, but it's kind of a kit of parts at the moment ...)
<Mithrandir> Kamion: true dat.. problem is, that's hard to do. :-)
<Mithrandir> (if not, I'd just have done it)
<Kamion> yeah, worth a spec then maybe so it gets resources assigned? :)
* Kamion notes that Debian seems to be in the middle of moving from console-tools to kbd
<Kamion> that'll be fun to merge
<Mithrandir> uh, to kbd?  Isn't kbd even more crufty than c-t?
<Kamion> Mithrandir: it alternates; one year one is more crufty, one year it's the other
<Kamion> this year apparently kbd is being maintained
<Kamion> (by Denis Barbier)
<Mithrandir> if we get lcxkb in, we'll have another implementation which can collect cruft, then.
<Mithrandir> (hopefully, it'll kill off both kbd and c-t)
<Kamion> doesn't lcxkb sit on top of one of them?
<Kamion> maybe not ...
<Kamion> I was just starting to write SaneInstallerKeyboard, hence why I noticed this
<Mithrandir> so far it sits on top of my head as a pile of ideas, mostly.
<Kamion> I'll link to zinoviev's console-setup
<Kamion> I realise it needs a perl->c rewrite but that might be easier than a nothing->c rewrite
<Kamion> given he's probably ironed out at least a few of the bugs
<Mithrandir> I'm thinking we want to write a library for parsing xkb file written since there's none so far.
<Mithrandir> and then we can write something on top of that.
<Mithrandir> that should make xkb upstream happy too.
<Kamion> I just don't want to throw away entirely what Anton's been doing, since apparently he does have something that actually works
<Mithrandir> sure, looking at it while rewriting it in C would work.
<Kamion> hmm, you know, I wonder if it's actually a problem that it's in perl; kbd-chooser wants a static list of keymaps rather than "everything expressible in xkb" anyway
<Kamion> so why not just precompile the list of stuff we care about at kbd-chooser build time?
<Kamion> the less we have to stuff in the d-i initrd, the better, anyway
<Mithrandir> true, but sizeof compressed /etc/X11/xkb < sizeof compressed /usr/share/keymaps
<Mithrandir> and not having an intermediate format is a win
<Mithrandir> while I agree having to write less software is better, too.
<sivang> geez, finally caught up with ubuntu-devel , that was long
<Kamion> well, this is why I wrote "investigate" in the rationale, I guess. :)
<mdz> tseng: sounds interesting, would be cool to be able to demo beagle on the live CD
<mdz> tseng: can it work on squashfs?
<tseng> mdz: you know what, I didnt think of that, no idea how it will work
<mdz> Kamion: didn't we all move from kbd to console-tools not too long ago?
<tseng> mdz: we are rolling mono-live with dapper, I will have a better idea what happens after that
<tseng> just thinking of ways to make a smooth experience on live fs
<tseng> i noticed it was on your EdgyIdeas
<Kamion> mdz: yep, about three or four years back; like I say, it appears to oscillates
<Kamion> s/s$//
<Mithrandir> mdz: the question is less whether it works on squashfs than on unionfs.  And I can't really see a reason why it won't.
<mdz> Mithrandir: if we want to ship it with a pre-generated index (and we do), then it would need to be stored in the squashfs
<Mithrandir> mdz: true.
<tseng> i dont know whether or not beagle-build-index makes any use of xattr
<tseng> i have a feeling it doesnt
<tseng> which would seem to make the underlying filesystem irrelevant
<pitti> mdz: what do you think about bug 34112? I'd like to see the updated package in dapper-updates, given the insane number of duplicates and people who are bitten by this
<Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
<pitti> mdz: the bug title is a bit misleading, btw, the ~/.cups/lptions part is already fixed in dapper
<mdz> pitti: it's long and the summary doesn't help; what's the issue?
<pitti> mdz: none of the printing options you set in the gnome print dialog becomes effective
<pitti> mdz: i. e. paper size, 2-on-1, gray or color, etc.
<pitti> mdz: and it's even impossible to print some PFDs, it only yields black boxes instead of pictures
<pitti> mdz: the last item is a bit magical, but I heard two reports that it's fixed by this as well
<bddebian> Hello
<ajmitch> hi
<zul> hey
<bddebian> Heya zul
<ajmitch> there is only zul!
<zul> thats is correct..
<Hobbsee> there are two hobbsees :(
<bddebian> ajmitch: I already said Hello to you in -motu :-)
<kagou> mdz, i can say as pitti that resolving this bug is really wanted/needed. Printing from gnome applications (using libgnomeprint, evolution/gedit/evince..., not OpenOffice, not firefox) do not works, or works really bad. it would be great to fix this bug
<bddebian> Is this still the cups bug?
<kagou> bddebian, yep
<mdz> kagou: I printed from evince recently in dapper and it worked very well
<mdke> I've printed several times today from evince
<pitti> then you never tried to alter any printer option
<mdz> that is possible
<pitti> I seldomly do, either, that's why I never noticed that
<kagou> mdz, try to change your settings to grayscale/draft. and reprint with evince
<pitti> well, I hardly ever print in the first place..
<kagou> mdz, some user force the use of their black carttridge, but evince do not matter and use 3 colors to render black (for example)
<mdz> kagou: why does changing the options trigger this problem?
<mdz> does it matter which setting(s) is/are changed?
<pitti> mdz: the problem is that changing the options doesn't work in the first place
<kagou> indeed
<pitti> mdz: 2 on 1, 4 on 1, grayscale, paper format, etc - it's all just ignored
<mdz> pitti: ignored is one thing; breaks printing is another
<pitti> mdz: I just ask because there's a neverending flood of bugs
<mdz> pitti: which is it?
<pitti> mdz: which is what?
<giftnudel> bug 34112 ?
<Ubugtu> Malone bug 34112 in libgnomeprint "gnome programs don't respect ~/.cups/lpoptions" [Unknown,Unknown]  http://launchpad.net/bugs/34112
<mdke> ah, that's right, 2 on 1 doesn't work. But it does successfully print
<mdke> so it's "ignored" rather than "breaks"
<pitti> yeah, it's just that 27 duplicates indicate that this really seems to bite a lot
<mdke> heh
<mdz> pitti: is the problem that the options are ignored, or that printing stops working entirely if you change an option?
<pitti> mdz: the former
<mdz> ok
<mdz> so kagou seems to be exaggerating the problem
<mdz> kagou: are you the author of the patch?
<kagou> mdz, no :)
<pitti> mdz: not being able to change the paper size and orientation is probably the thing that hurts most
<pitti> mdz: i. e. impossible to print landscape or on A3/A5/whatever
<pitti> so you can still print, but it might not actually be useful
<kagou> mdz, Bug #21722
<Ubugtu> Malone bug 21722 in gnome-cups-manager "A4 paper size unalterable in printer setup" [Medium,Needs info]  http://launchpad.net/bugs/21722
<mdz> pitti: who did write the patch?  is it upstream?
<pitti> mdz: Pascal de Vuyst; it's not upstream since upstream is dead for some time
<mdz> pitti: oh wonderful
<pitti> mdz: that's why it is in such a bad shape in the first place, people are concentrating on gtk print support 
<mdz> pitti: this has always been broken?
<pitti> mdz: I didn't check breezy
<pitti> shall I?
<giftnudel> I can test in 3 minutes (need to boot computer)
<mdz> pitti: if you can
<mdz> I do have a ~/.lpoptions which sets the page size, and that seems to work
* pitti -> booting breezy, brb
<kagou> mdz, under breezy ? or dapper ?
<mdz> kagou: dapper
<kagou> it's strange because i'v seen that libgnomecups or cups delete this ~/.lpoptions and create ~/.cups/lpoptions
<kagou> mdke, if you create this file by hand, be sure to do this in ~/.cups/
<kagou> sorry mdke , i mean mdz 
<mdz> kagou: I have a ~/.lpoptions
<iwj> mdz, pitti: I wanted to draw your attention to https://lists.ubuntu.com/archives/ubuntu-devel/2006-June/018506.html, about Firefox 1.0.8 and security support for it in Breezy.
<iwj> I would have CC'd you but then you'd get a mailbox full of `courtesy' copies so I thought I'd ping you on IRC about it instead.
<giftnudel> mdz: setting pagesize to A5 chops off the edges of the document
<giftnudel> mdz: setting 4-1 doesn't do anything for me
<pitti> mdz: doesn't work in breezy either
<kagou> mdz, may be you have created by hands ~/.lpoptions , but use g-c-m to change default printer and default parameters, and your ~/.lpoptions will be deleted and re-created in ~/.cups/lpoptions
<mdz> kagou: I have not
<mdz> pitti: the patch looks sane to me
<pitti> iwj: please note that it is possible to get split-out patches for 1.5.0.4 in mozilla's bugzilla and backport them one by one
<kagou> mdz, do you use g-c-m or kdeprint or ... ?
<pitti> iwj: upstream offered that vendors can even use the tags and other stuff for coordinating backporting
<pitti> kagou, mdz: ~/.lpoptions is the old location, it was deprecated in favor of ~/.cups/lpoptions at some point; this is entirely unrelated to 34112, though
<Kamion> iwj: s/Breezy/Hoary and Breezy/g, at least for the next six months. :-(
<Kamion> well, no, I guess it's just over four months now
<pitti> bah, Ctrl-W does *not* delete a word in xchat, sorry
<iwj> Kamion: OMG, hoary too ?  I haven't even _looked_ at hoary's firefox.  I dread to think.
<iwj> pitti: Yes, but that's not really the problem.  Split out patches is all very well but the real difficulty is the bugs we don't hear about and the ones where the code is all changed around.
<kagou> pitti, i know  that :) but mdz say that he have ~/.lpoptions and no  ~/.cups/lpoptions so it's a bug because using g-c-m DELETE ~/.lpoptions and create ~/.cups/lpoptions (tested here)
<Kamion> Hoary is supported until <counts on fingers> 8 October 2006.
<Kamion> also, top tip for console web browsing, 'ssh lists.ubuntu.com/archives/ubuntu-announce/' isn't useful.
<iwj> pitti: Also, we _know_ that their processes are hopeless so why would we think that their split out patches correspond to anything when the `security and stability' release with published release notes doesn't ?
<pitti> iwj: it'll just help to sort out the security relevant ones from all the other stuff
<pitti> iwj: true that
<iwj> pitti: Yes, but what about the security relevant ones they forgot to list in the changelog ?
<iwj> I really think our best bet is to follow the herd here.  At least that way most of the jungle will have been trampled by other people.
<pitti> iwj: right, upstream said that vendors might need to fish them out and mark as 'blocking-1.0.9' themselves
<Kamion> mozilla-firefox | 1.0.2-0ubuntu2 |         hoary | sparc
<Kamion> mozilla-firefox | 1.0.2-0ubuntu5 |         hoary | source, amd64, i386, ia64, powerpc
<iwj> Urgh.
<Kamion> mozilla-firefox | 1.0.7-0ubuntu0.1 | hoary-security | sparc
<Kamion> for the record
<Kamion> mozilla-firefox | 1.0.8-0ubuntu5.04 | hoary-security | source, amd64, i386, ia64, powerpc
<kagou> must go to the crib. see you later 
<jsgotangco> man
<Kamion> hoary-security seems close to breezy-security, since we dumped 1.0.8 in there
<pitti> yes, indeed
<pitti> even warty has 1.0.8 in -security
<Kamion> but obviously all the locales stuff and extensions would need to be fudged if upgrading to 1.5
<pitti> right
<Kamion> probably differently
<pitti> and all the gtkmozembed stuff, like epiphany, yelp, etc.
<iwj> pitti: Really ?  The API is so different ?  I thought it was quite narrow.
<pitti> upgrading hoary and breezy to tbird 1.5 might be reasonably easy
<iwj> I haven't tried it, it's true.
<pitti> mozilla might hurt in hoary
<pitti> but ffox is really painful
<iwj> If it's a question of having to rebuild epiphany et al then it's trickier.
<pitti> iwj: but my gut feeling is that it's still the least of all evils...
<iwj> I really don't fancy trying to cherry pick patches out of a swamp.  They're likely to be rotten.
<pitti> iwj: it's not only cherrypicking, the 1.5 codebase changed significantly
<iwj> Quite.
<pitti> which also implies that few people will continue to audit 1.0.x
<pitti> i. e. most of the 1.0 vulnerabilities will never even be known in the future
<pitti> iwj: just to get an idea, let's try to build the dapper firefox on breezy and see how much breaks
<iwj> pitti: That's a good idea.
<iwj> I've got a breezy here somewhere, let me dig it out.
<pitti> iwj: I have chroots, I can try it here, too
<pitti> having two people try it can't hurt
<pitti> (oh, I have an installed breezy here, too)
* pitti reboots back into dapper, brb
<iwj> egrep . /media/hda*/etc/lsb-release 
<iwj> There's one, hda4.
<iwj> Urrr.  It seems a bit busted.
<giftnudel> iwj: never touched since release?
<iwj> No, worse, I think I must have done some destructive test in it.
<iwj> Oh, well, reinstalls are quick :-).
<pitti> mdz: sorry for getting offline due to rebooting; did you already decide about 34112, or do you want to wait for more feedback?
<mdz> pitti: the patch looks sane to me
<pitti> iwj: 1.5.0.3 breezy build is running here
<pitti> mdz: yes, it's not really a bug fix, but the missing glue between the dialog and cupsAddOption()
<lemsx1> hello all
<lemsx1> infinity: ping
<lemsx1> infinity: that problem with libgcc_s.so.1 i was having was because -lgcc_s wasn't in the compile flags :-) just for future reference
<bddebian> Hello lemsx1
<mdz> mvo: update-notifier is still reminding me about language pack organization
* ..[topic/#ubuntu-devel:Keybuk] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html | Queue on manual for a bit; prod Keybuk for uploads to dapper-updates
<bSON> hi
<bSON> does ubuntu have any strategy concerning easy third-party installation?
<siretart> bSON: see https://wiki.ubuntu.com/ThirdPartyPackages and https://wiki.ubuntu.com/ThirdPartyApt
<pitti> mdz: so, fine to upload libgnomeprint?
<bSON> siretart: thanks
<bddebian> mdz: So, what do you have for me? ;-)
<mdz> pitti: yes
<mdz> bddebian: pardon?
<bddebian> mdz: You said to talk to you so what do you want me to do? ;-P
<mdz> bddebian: what I said was that I was available to help you if you had any difficulty in getting your packages reviewed and uploaded
<bddebian> :)
<iwj> Hmm, this new Breezy install's grub is broken.
<Keybuk> . o O { I wonder what would happen if I uploaded udev without udevplug? }
<Kamion> Keybuk: the installer would temporarily break, but possibly who cares ...
<Kamion> what else calls udevplug? initramfs-tools I guess
<Keybuk> that's what I'm just trying to find out
<Keybuk> casey needs more CPUs ;P
<Keybuk> or, probably, better IO
<Kamion> I think all the udevplug calls in d-i are consolidated into update-dev in di-utils now, and upstream I've made that call udevtrigger/udevsettle if available
<Keybuk> ok
<Keybuk> that's my vague plan
<Keybuk> port our udevplug extras into udevtrigger
<Keybuk> I could ship udevplug as a small shell-script if something uses it and doesn't fall back to udevtrigger
<Keybuk> e.g.
<Keybuk> udevtrigger "$@"
<Keybuk> exec udevsettle
<eXistenZ> Any cups developer?
<ivoks> maintainers?
<eXistenZ> yeah
<eXistenZ> when will cups be upgraded?
<ivoks> yup, what's on your mind?
<ivoks> eXistenZ: to 1.2.1?
<eXistenZ> yep
<eXistenZ> ivoks, I still cannot use my printer because of a bug in cups =/
<ivoks> well, that's what we are disscusing now
<eXistenZ> ivoks, I'm waiting for the next version
<ivoks> eXistenZ: does 1.2.1 works for you?
<eXistenZ> Where can I get it from?
<ivoks> no where
<eXistenZ> I believe it should've been fixed by 1.2.1
<ivoks> eXistenZ: what printer is that?
<ivoks> did you fill bug report?
<eXistenZ> ivoks, It is on a windows xp system, (HP DeskJet 710C)
<highvoltage> mvo: ping
<eXistenZ> ivoks, there is already a bug filed.
<mvo> highvoltage: pong
<ivoks> eXistenZ: on windows?
<ivoks> eXistenZ: so, this has to do with samba, right?
<highvoltage> mvo: who's the developers of gnome-app-install?
<eXistenZ> ivoks, nope, with some of the drivers.
<eXistenZ> ivoks, let me show you the bug
<mvo> highvoltage: that would be me I guess
<highvoltage> mvo: cool. any chance of changing the wording of "Show commercial applications"?
<ivoks> eXistenZ: bug numer would be enough
<highvoltage> it kind of implies that proprietary software is commercial, and free software not. i think it adds confusion to new users of free software.
<mvo> highvoltage: see bug 44925
<Ubugtu> Malone bug 44925 in gnome-app-install "proprietary != commercial" [Medium,Confirmed]  http://launchpad.net/bugs/44925
<eXistenZ> ivoks, This is from the cups error log: http://pastebin.com/765514 . I believe it is similar to the bug no. 45099
<ivoks> eXistenZ: i'm aware of 45099
<eXistenZ> ivoks, Can you please check out the error from my cups log
<ivoks> eXistenZ: did you, as i have proposed, change driver to raw/queue?
<eXistenZ> ivoks, Let me try
<janderso> [sorry if this is the wrong place to ask this]  why are ubuntu-desktop, ubuntu-standard, and ubuntu-minimal separate, rather than higherarchically dependent?
<eXistenZ> ivoks, why the right driver of the printer doesn't work?
<ivoks> eXistenZ: does raw works?
<ivoks> janderso: so you can remove evms, but still have ubuntu-desktop :)
<eXistenZ> ivoks, nope =/
<ivoks> eXistenZ: your problem has nothing to do with 45099
<ivoks> eXistenZ: 45099 is a IPP problem, windows, atm, don't do IPP sharing
<ivoks> eXistenZ: how is that printer shared from windows?
<ivoks> eXistenZ: over SMB?
<janderso> ivoks: I guess my main question is, why do I need ubuntu-minimal and ubuntu-standard if I have ubuntu-desktop?
<eXistenZ> ivoks, I'm not sure. But I have a windows xp OS here, and I can print well.
<ivoks> janderso: ubuntu-minimal installs set of some must have and some good to have apps
<ivoks> janderso: you can remove it if you want
<ivoks> janderso: i.e, if you don't want memtest86+, you can remove it
<eXistenZ> ivoks, After I install my printer, then I check its properties. I find out that there are no username or password, although I've set them up in the settings while configuring the printer.
<ivoks> janderso: but sill have ubuntu-desktop
<ivoks> eXistenZ: that's a known bug
<eXistenZ> ivoks, Is there a fix/workaround to this bug?
<ivoks> eXistenZ: can you print from remote windows to that printer?
<eXistenZ> ivoks, 
<ivoks> eXistenZ: not that i'm aware of, could you paste log from your error_log with raw as printer driver?
<eXistenZ> ivoks, yes
<eXistenZ> ivoks, sure
<eXistenZ> ivoks, it shows nothing other than the known: E [07/Jun/2006:19:54:16 +0300]  cupsdAuthorize: Local authentication certificate not found!
<ivoks> ok
<eXistenZ> ivoks, I wonder whether you can take remote desktop
<ivoks> i'm not help service :)
<eXistenZ> ivoks, Alright. I am not sure that it is something wrong that I did.
<eXistenZ> ivoks, because it worked wonders in breezy
<eXistenZ> ivoks, anyways, it is your own volition.
<ivoks> smb://username:password@machine/printer_share
<ivoks> that's syntax, you did it like that?
<janderso> ivoks: this _is_ a development issue, though: when I removed ubuntu-standard and ubuntu-minimal, I lost pcmcia-utils, and my pcmcia network cards stopped working
<janderso> ivoks: I had to go back and install pcmcia-utils myself; shouldn't that be a part of ubuntu-desktop?
<eXistenZ> ivoks, I try that, but nothing happens
<ivoks> janderso: err... removing ubuntu-standard and -minimal does not remove pcmciautils
<ivoks> janderso: you have removed it by your self
<ivoks> eXistenZ: ok
<eXistenZ> ivoks, Want to see the error when I configure my printer with the right configuration?
<ivoks> eXistenZ: i saw it
<janderso> ivoks: well, no; but I used deborphan to remove packages that were dependencies of ubuntu-minimal and ubuntu-standard (which I had removed) but not ubuntu-desktop (which remained on the system)
<ivoks> eXistenZ: fill a bug on LP
<janderso> ivoks: my point is, I think that pcmciautils should be a dependency of ubuntu-desktop
<ivoks> janderso: deborphan isn't AI
<ivoks> it's very simple tool
<eXistenZ> ivoks, I filled a bug, and it was removed as a duplicate for that 40599 bug
<ivoks> if nothing depends on it - remove it
<ivoks> janderso: you see that it would remove almost all tools :)
<ivoks> eXistenZ: oh, i see...
<ivoks> eXistenZ: i'll fix that
<janderso> ivoks: I know, I'm not blaming deborphan. I'm just wondering why ubuntu-desktop doesn't depend on pcmciautils
<bddebian> Is there a way to get reverse build-depends like apt-cache rdepends?
<eXistenZ> ivoks, Can I get 1.2.1 from somewhere & try it?
<bSON> hi
<ivoks> eXistenZ: fixes for 1.2.1, regarding this bug were implemented in our 1.2.0
<ivoks> eXistenZ: i doubt it will help you, but soon there will be new cups packages
<ivoks> eXistenZ: when we finish them, i'll let you now and you could test them
<ivoks> eXistenZ: ok?
<eXistenZ> ivoks, it is so irritating to move to windows each time I want to print a document
<ivoks> eXistenZ: yeah, i know... it's a bug, and we'll try to fix it, don't worry
<bSON> can anybody package a new version of compiz? (the last one not using glx 1.3 and therefore works with the actual version of dapper's libs)
<ivoks> bSON: that will not happen for dapper
<bSON> when does edgy eft development start?
<Keybuk> bSON: october :)
<Keybuk> we add two days every time someone asks
<Keybuk> and that many people have asked!
<bSON> oh
<crimsun> Keybuk: wow, nice vacation ;)
<fabbione> crimsun: you wish :)
<mdz> crimsun,pitti: is it worth revisiting polypaudio for edgy?  it seems to be revived
<bSON> thats important, now that dapper is no exciting everything-can-change beta more ;)
<crimsun> mdz: hmm, it does "suck less" than esd. Will need to read up on it now.
<eXistenZ> ivoks, Is it that difficult to put new versions of cups into a package?
<ivoks> eXistenZ: fixes from 1.2.1 will get backported to our cups package
<ivoks> some of them allready are
<pitti> mdz: I heard about it, but TBH I would rather get rid of esd entirely instead of reintroducing a sound daemon
<mdz> pitti: until all apps use alsa, I don't see how we can avoid a sound daemon
<Kinnison> pitti: are you advocating alsa+dmix or something?
<froud> Are there any apps going into dapper that still have no documentation?
<pitti> Kinnison: at least to the extend we have in dapper
<pitti> mdz: right
<pitti> mdz: and esound is dead anyway
<bluefoxicy> what does enlightenment use these days
<Keybuk> mdz: btw, can we really _not_ revisit network-manager for edgy
<Keybuk> it's on your EdgyIdeas page; and I just cannot see it being sufficiently more mature in four months time than it is now
<mdz> Keybuk: do we have another answer for WPA or switching wireless networks? that's all I really care about
<Keybuk> mdz: wpa can be set through /e/n/i -- and there's the usual gnome applet for switching wireless networks
<bluefoxicy> mdz:  someone really needs to get WPA into network-admin, but I don't think anyone's around that wants to code it
<bluefoxicy> Keybuk: I'm pretty sure you can point-and-click through wireless networks through network-admin configuration applet ... were you speaking of a panel applet that does this as well?
<mdz> Keybuk: since when does the gnome applet switch wireless networks?  I thought it just launched the awful network config tool
* bluefoxicy really, really doesn't like needing 2 or 3 configuration applets to do the single job of configuring networking... he just feels like something's really wrong when he has to tell users they need to bounce from place to place to do the simplest task possible.
<ivoks> fwiw, /me likes NM
<ivoks> :)
<_ion> <aol>Me too</aol>
<Keybuk> dunno, people keep telling me they switched through the panel applet and it broke n-m
<bluefoxicy> I haven't used NM TBH.  If you can do all the configuration through NM that you can through network-admin, maybe you should consider replacing network-admin.  I just don't personally think there should be 2 config applets to screw with the same thing.
<bluefoxicy> ... why am I talking?  *goes to play a playstation game*
<eXistenZ> ivoks, how can I restart cups? what is its process name?
<ivoks> eXistenZ: sudo /etc/init.d/cupsys restart
<bluefoxicy> pitti:  Edgy is using gcc 4.1 right?
<ivoks> there is no edgy :)
<sivang> at least not yet :)
<ivoks> edgy is a myth
<ivoks> an urban legend
<bddebian> hehe
<jjesse> does that mean i shouldn't have changed my sources.list from dapper to edyg yet :)
<bluefoxicy> you guys know what I mean -.-
<bddebian> Anyone know how Scribus determines it's default font?
<fabbione> jjesse: none of us will change to edgy for the next 3 weeks. 
<fabbione> because we know it's broken and it will break a lot
* bluefoxicy wants to know if FORTIFY_SOURCE, -fstack-protector, and/or PIE will be used in edgy
<eXistenZ> ivoks, what is the mode of files which everyone can see?
<eXistenZ> ivoks, 777?
<jjesse> fabbione: i was being sarcastic ;)
<fabbione> jjesse: i am not :)
<ivoks> eXistenZ: 555
<zul> Keybuk: thats another two days..
<ivoks> eXistenZ: 555 for dir, 444 for files
<bluefoxicy> I am rather certain attempting to PIE everything will be a pain in the ass ;)  A good bit breaks from it and then you have to disable pie specifically for those packages
<bddebian> fabbione: Think it would be worth trying to "fix" any packages using xmkmf for Edgy?  (I.E. not have them use xmkmf?)
<Keybuk> zul: it'll be November before infinity wakes up
<bluefoxicy> (PIE only affects main executables, not libraries)
<bddebian> hehe
<bluefoxicy> the other two should be minimally intrusive
<fabbione> bddebian: i am not an X maintainer anymore...
<bddebian> WHAT?
* fabbione will sit and do nothing for edgy
<bddebian> Doh :-(
<zul> wohoo!
<bddebian> fabbione: Who is going to maintain X?
<ivoks> bddebian: xorg :)
<fabbione> for once i won't need to go around trying to hide with my ninja/jedi skills from upset users
<bddebian> heh
* bluefoxicy has dapper-backports in hopes he'll get X 7.1 early.
<fabbione> bddebian: <sarcastic answer>I can't care less</sarcastic answer>
<bddebian> *sigh*
<ivoks> why does everybody wants to go with edgy? dapper is a great release
<fabbione> ivoks: it's already 6 days old!
<ivoks> do people like to have broken X or kernel?
<jjesse> they are bored with it already?
* Keybuk is already running edgy
<Keybuk> you guys are SO BEHIND
<bddebian> hehe
<ivoks> :)
<ivoks> Keybuk: tell us, tell us, is it broken? :)
<Keybuk> ivoks: yes :p
<ivoks> oh, no... i want some edgys! :)
<eXistenZ> ivoks, I sent a reply. Can you please check whether the files open?
<bddebian> ivoks: I don't necessarily want to run it yet, just trying to line up some tasks to make myself "useful" since apparently I'm useless so far :-)
<bluefoxicy> ivoks:  I am hoping to get Xorg 7.1 (working 3D driver maybe...), stack smash protection, and maybe (on a huge long shot) PIE.
<ivoks> eXistenZ: i won't be fixed today :)
<eXistenZ> ivoks, I know. Just check whether you can open them.
<ivoks> bddebian: nag, nag... you are allways useless :)
<eXistenZ> ivoks, I don't know whether I correctly set the mode.
<bddebian> ivoks: I know
<ivoks> i'll be rolling out dapper on server like ford did T-Model :)
<ivoks> eXistenZ: reply to what? there's nothing on 48173 yet...
<bddebian> pitti: ping?
<eXistenZ> ivoks, I sent you an email
<eXistenZ> ivoks, Do you mean you want me to attach files to the bug reply?
<ivoks> eXistenZ: https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/48173/+addattachment
<Ubugtu> Malone bug 48173 in cupsys "Printing on remote Windows shared printer doesn't work" [Medium,Confirmed]  
<eXistenZ> ivoks, Shall I compress the files?
<ivoks> don't compress cupsd.conf and printers.conf
<ivoks> error_log... well, if it's too big...
<eXistenZ> ivoks, Can I add more than one attachment for one thread?
<ivoks> eXistenZ: no, add each individualy
<sivang> Keybuk: so can I dist-upgrade already? ;-)
<Keybuk> sivang: no point
<Keybuk> no changes in the archive
<sivang> ah
<bddebian> Keybuk: Well get merging man! :-)
<Keybuk> bddebian: first we need a toolchain
<Keybuk> which is what broke when I installed it
<bddebian> Doh
<Keybuk> well, leaned in an unpleasant way
<Tonio_> hi all
<bddebian> Heya Tonio_
<eXistenZ> ivoks, ok, done. ;-)
<ivoks> eXistenZ: ok, i see it
<eXistenZ> ivoks, Do you know why I'm not allowed to give wiki.ubuntu.com/Existenz , but rather Existenz2?
<eXistenZ> ivoks, Some other user has taken it, although my user is eXistenZ, anyways.
<eXistenZ> Will vim7 be added to the dapper repos?
<tseng> no.
<mdz> eXistenZ: it can potentially go into dapper-backports
<bddebian> Heya tseng
<pitti> bddebian: pong
<bddebian> pitti: You do Scribus?
<pitti> bddebian: never touched it
<bddebian> Oh duh, I saw your name as creator and thought it was Maintainer, sorry
<ogra> pitti, you must have touched it if your name is in the crator field :)
<ogra> *creator
<ogra> bddebian, scribus is in main because of edubuntu, so that'd be the edubuntu development team (which is me in fact)
<pitti> bddebian: oh god, I just fixed the .desktop file for langpack support
<ogra> pitti, there is a bug open about the creator wording
<bddebian> pitti: :-)
<bddebian> ogra: Do you know how it determines it's default font?
<ogra> bddebian, QT i think
<bddebian> Well it's picking some weird ass font that breaks stuff :-)
<bddebian> Bug #45565
<Ubugtu> Malone bug 45565 in scribus "Can't enter text into textboxes in any way" [Critical,Confirmed]  http://launchpad.net/bugs/45565
<ogra> well, looks like upstream works on it so we'll get the fix in edgy
* bddebian hugs ogra :-)
<eXistenZ> ivoks, Is it a general or specific problem? what can I/we do about it?
<ogra> mdz, any word on the g-s-s upload ? 
<mdz> ogra: ?
<ogra> i dont see it on -changes
<Keybuk> where did you upload it to?
<Keybuk> when did you upload it?
<Keybuk> was it approved?
<Keybuk> who approved it?
<ogra> yesterday dapper-updates
<Keybuk> when did you get approval for it?
<ogra> and mdz asked for the upstream changelog
<ogra> Keybuk, no it apparently wasnt approved yet, thats why i pinged mdz ;)
<mdz> ogra: no one is notified when a new package lands in unapproved
<ogra> mdz, well, since you asked for the changelog i thought you'd still look at it
<Keybuk> (and half of gnome appears to be unapproved, currently)
<ogra> whee
<shadeofgrey> hello everyboidy
<highvoltage> hello shadeofgrey 
<shadeofgrey> i just did a fresh install of ubuntu using the new 6.06 installation CD and i love the fact that you integrated the livecd in with the installation system, so that people can test stuff and then immediately do an install
<shadeofgrey> but i have a pretty complicated question...
<shadeofgrey> my full ubuntu installation now resides on my primary disk -- hda -- but i have a previous installation of it on sda -- my third harddrive and i was just wondering what the best method for removcal of the old system is
<shadeofgrey> do i just use the drives portion of the system --> administration disk panel and format?
<Kamion> eXistenZ: the vim7 packaging has changed a fair bit, so personally I think it'll be a hard job to backport sanely, but fortunately not my problem ...
<tseng> Kamion: it builds clean on dapper
<eXistenZ> Kamion, Do you imply that you use emacs? :-)
<tseng> Kamion: but i am still not an advocate
<tseng> (of backports on the archive in general)
<Kamion> tseng: sure, but it builds a different set of packages :) so upgrade fun
<Kamion> eXistenZ: no, I use vim
<tseng> oh, yeah
<tseng> have to fight with apt a bit
<eXistenZ> Kamion, do you use vim6?
<tseng> I do, fwiw
<Kamion> actually, it might not be a different set of packages, could be wrong there
<Kamion> eXistenZ: on some machines, vim7 on others; that's not especially relevant though
<ivoks> urgh...
<ivoks> pitti: ping
<ivoks> anyone around with windows? :)
<Keybuk> yeah, they're all open though because it's hot outside
<Keybuk> I have a couple of doors too
<eXistenZ> ivoks, I can switch to windows.
<ivoks> eXistenZ: but i know your printer doesn't work on linux
<ivoks> Keybuk: this is serious :)
<Chipzz> Kamion: http://johan.kiviniemi.name/ubuntu/dists/dapper/
<Keybuk> ivoks: which version of Windows?  which architecture?
<ivoks> Keybuk: XP, if you have it on UltraSPARC, that would be fine :)
<Keybuk> XP or XP64?
<_ion> One might want to use the mirror at http://hassers.fi/ubuntu/dists/dapper/, as it's behind a 99x faster connection.
<ivoks> Keybuk: i just want to see can you/someone_else print from dapper to windows
<ivoks> Keybuk: i think that's irrelevant
<Keybuk> ah, windows is on my dapper machine, so I couldn't test that
<Keybuk> sorry
<ivoks> np
<ivoks> i'll find another victim :)
<Kamion> Chipzz: don't need it, thanks :)
<eXistenZ> ivoks, Are you sure the problem is in gs-esp?
<Kamion> I generally have very little interest in bothering with backports, except in cases where I have enough activation energy to just do the job myself
<ivoks> eXistenZ: ATM, yes
<ivoks> eXistenZ: but that could change... :)
<bddebian> What is the determining factor if something should be fixed in -updates, -backports, or just done in Edgy?
<eXistenZ> haha, nice.
<eXistenZ> ivoks, installing a newer version might help?
<ivoks> eXistenZ: there's no newer version
<ivoks> hm, it works ok
<ivoks> eXistenZ: mine deskjet 940c works ok
<eXistenZ> ivoks, network printer?
<bddebian> mdz: Still around?
<ivoks> eXistenZ: yes, shared on windows via smb
<eXistenZ> ivoks, Does it help if I get the printer and attach it to this computer?
<ivoks> eXistenZ: could you do apt-get --force-all --purge gs-esp
<ivoks> eXistenZ: and then apt-get install gs-esp
<ivoks> eXistenZ: yes, but try this first
<Kamion> bddebian: -updates needs to be reasonably safe, obvious, reviewable-by-humans-without-going-insane, and address known bugs
<eXistenZ> ivoks, force-all?
<ivoks> eXistenZ: yes
<Kamion> bddebian: other stuff should go to edgy, and may later be pulled into -backports by the backports team if there's significant demand for the newer upstream version (generally features)
<eXistenZ> ivoks, "--force-all is not understood"
<mdz> bddebian: yes
<ivoks> eXistenZ: ah, sorry, dpkg --force-all --purge
<bddebian> mdz: Have a minute or are you busy?
<mdz> bddebian: (if it was about your question, Kamion answered as I would have)
<mdz> bddebian: what can i do for you?
<bddebian> mdz: It's more general but I won't bother you if you don't have time
<mdz> bddebian: what is your question?
<bddebian> I would rather ask in /query if you are not opposed
<eXistenZ> ivoks, same =/ didn't work
<ivoks> ok
<ivoks> same error?
<eXistenZ> ivoks, I'll get my printer here. I'll check whether it is a network problem or a gsp-esp problem
<ivoks> eXistenZ: the thing is that gs-esp dies
<ivoks> eXistenZ: but that can be due lots of things...
<eXistenZ> ok
<eXistenZ> brb
<eXistenZ> ok, here is the printer :] 
<eXistenZ> ivoks, I got the same problem
<ivoks> you see...
<ivoks> eXistenZ: do you have ubuntu-desktop package installed? is this a breezy -> dapper upgrade or fresh dapper instalation?
<eXistenZ> ivoks, fresh; very fresh.
<eXistenZ> I'm going to get a new laser printer soon anyways
<ivoks> ok
<eXistenZ> maybe that will fix it
<ivoks> eXistenZ: but that'll not solve issues for other people
<eXistenZ> ivoks, I'm ready to give you anything that might help fix this problem.
<tritium> Against what should a bug be filed for vga settings via F4 selection not being preserved after live session on desktop install CD?
<ivoks> eXistenZ: there's nothing else i need
<ivoks> eXistenZ: error_log clearly says gs-esp dies
<ivoks> eXistenZ: now i just need time to figure out why :)
<Kamion> tritium: you mean after installation?
<mjg59> tritium: Either gfxboot or ubiquity
<mjg59> I'd guess, but kamion will know better
<Kamion> not gfxboot. ubiquity sounds good
<tritium> Kamion: yes (my /boot/grub/menu.lst doesn't contain any vga= settings)
<Kamion> but you lot made me deliberately exclude vga=
<tritium> I had selected 1400x1050, 32 bit, during installagin
<Kamion> because it breaks suspend/resume
<mjg59> Ah, yes
<Kamion> actually perhaps the right answer is to drop the option to use vga= from the live CD
<eXistenZ> ivoks, check out: https://launchpad.net/distros/ubuntu/+source/gs-esp/+bug/38060
<Kamion> which would be a gfxboot-theme-ubuntu bug
<Ubugtu> Malone bug 38060 in gs-esp "es-gsp crashes on various input causing a faliure to print" [Medium,Fix released]  
<tritium> It breaks suspend/resume?
<Kamion> yes
<Kamion> vga= -> vesafb -> no working resume
<Keybuk> same reason we don't use high-res in usplash
<mdz> is it not possible to unload vesafb later on?
<Kamion> I was under the impression that vesafb managing to be modular at all was a bit of a miracle, let alone unloading
<ivoks> eXistenZ: :* :* :* :)
<tritium> Oh, interesting.  I'll have to see if that fixes one of my bugs...
<eXistenZ> ivoks, this bug was filed before dapper
<ivoks> eXistenZ: no, during dapper
<mjg59> mdz: Nope
<mdz> eXistenZ: as were thousands of others
<ivoks> eXistenZ: install gs-gpl
<mjg59> mdz: Right now, there's no real way of unbinding framebuffer drivers from the console
<mdz> mjg59: the sab is very keen on a prettier usplash, maybe we could try it on desktops
<mjg59> mdz: Still breaks suspend/resume, but arguably we care less
<mdz> right
<Kamion> desktops have better displays for prettiness either
<mjg59> Kamion: Too?
<Keybuk> prettier usplash should be easy now, I've moved all of the hardcoded stuff into a struct the .so file exports
<Kamion> will you let me put vga= preservation back in on desktops? :)
<Kamion> mjg59: er, yes, too
<mjg59> I wonder how small we could get a kdrive-based splash solution
<eXistenZ> ivoks, just install it?
<ivoks> eXistenZ: did you?
<eXistenZ> ivoks, yep
<ivoks> eXistenZ: now: sudo update-alternatives --set gs /usr/bin/gs-gpl
<ivoks> eXistenZ: and then try to print
<Keybuk> mjg59: how would kdrive help?
<Keybuk> avoiding fb?
<mjg59> Keybuk: Yeah
<mjg59> Just use vesa
<Keybuk> what's kdrive's card support like though, I thought it was pretty bad?
<Keybuk> though I guess if it's vesa, it's enough
<Kamion> bogl is not exactly that big though, is it?
<mjg59> Kamion: bogl is pretty tiny, but ties us to a framebuffer driver
<Keybuk> bogl isn't big, but it needs framebuffer
<eXistenZ> ivoks, doesn't work =/ Do you want to see the error_log now?
<ivoks> eXistenZ: yes
<tritium> Kamion: I'll not file a bug, since it was intentional, then
<Keybuk> is there no small vesa !fb library?
<mjg59> Keybuk: libsvga?
<mjg59> Not sure if it actually does vesa, though
<bddebian> Heya tritium
<tritium> hi bddebian.  What's happening?
<mjg59> In principle we can do it, though
<Kamion> tritium: could you file a bug on gfxboot-theme-ubuntu about it? like I say I should probably take out that option on the live CD, since it isn't all that useful there and it causes confusion
<bddebian> tritium: Not much thanks, you?
<tritium> Kamion: okay, sure.
<Kamion> though I don't think we have any possibility of being able to detect laptop vs. desktop in gfxboot
<Kamion> so it may have to remain at least somewhat confusin
<Kamion> g
<Kamion> I'll leave the bug open for a while and reassign to wherever we eventually decide to fix it
<tritium> ok
<sladen> Kamion: just fetch the DMI and grep it (which is basically all that 'laptop-detect' does (oh, and laptop-detect looks for a battery too)
<jdub> Kamion: so, do you know much about the ld.so.conf "removal"? was this something we inherited from debian or upstream?
<sladen> Keybuk: I think some previous occasion you were asking about detecting amd64 vs. i386 on boot.  It's a bit (called "lm" == long mode) in the cpuid flags
<sladen> Keybuk: so then you can do your dual mode DVD's 
<Keybuk> sladen: the discussion was whether we could make an all-arch dvd
<sladen> Keybuk: my reckoning was, yes.
<sladen> Keybuk: look up "TriplePlay" on the wiki
<eXistenZ> ivoks, here is the link: http://existenz.googlepages.com/error_log
<sladen> Keybuk: if you ditch HFS booting on PPC and only go for HFS+ booting (which starts at +1kB) you might even get sparc+ppc to co-exist
<sladen> Keybuk: somehow Apple have managed i386 and ppc boot on their OSX disks, so you may even get Mactel i386 on there aswell
<mjg59> sladen: ?
<mjg59> sladen: The OSX DVDs are per-arch
<Kamion> sladen: patches welcome. "just" in gfxboot is never that easy
<Kamion> jdub: absolutely no clue
<sladen> Kamion: ?  re: detecting laptop/desktop in the boot loader?
<Kamion> sladen: yes.
<Kamion> sladen: it's all hand-coded assembly, and my x86 assembly is passable enough to fix minor bugs but I'm no superstar at it
<Kamion> sladen: and it would need to export an operator to the forth-like language too
<jdub> Kamion: i've heard a bit of (mostly pointless) whinging about it; does sarge have ld.so.conf OOTB?
<eXistenZ> ivoks, does gpl crash also?
<Kamion> jdub: absolutely no clue
<Kamion> please ask somebody else with clue :)
<Kamion> interesting that selecting vga= in the boot loader is apparently sometimes a workaround for xresprobe leaving you with a blank screen in the middle of the install
<Kamion> (d-i)
<mjg59> So a stripped Xvesa build is 800K
<mjg59> But depends on freetype and some other X libs
<mjg59> Could probably be made smaller by building against uclibc
<Keybuk> X is a bit heavy weight?
<mjg59> Keybuk: I'd imagine that we could probably do an X-based solution in under 2MB
<Keybuk> mjg59: it still seems rather over-kill
<Keybuk> 47K -> 2,048K is silly for a bit of shine
* sladen suspects that just-fixing-the-vesafb-driver-would-be-simpler
<Keybuk> especially for the initramfs, we're near the line already on the size of that
<mjg59> Keybuk: A quick play suggests that performance wouldn't be an issue - it comes up in well under a second
<sladen> kdrive on vesa?
<mjg59> As for size, well. I think that's going to end up depending on just how much Mark wants bling
<Keybuk> mjg59: it's not performace I'm worried about -- it's the fact we can't afford to load a 10MB initramfs!
<mjg59> Keybuk: Because?
<Keybuk> powerpc, amongst others, has size limits
<mjg59> Hm. Why?
<Keybuk> not to mention how long it takes to get off disk
<Keybuk> bootloader something-or-other
<mjg59> powerpc is actually less of a problem, since we can have sensible fb access anyway
<Kamion> yaboot; 6MB limit on netbooting
<Kamion> it's quite ingrained
<mjg59> Only on netbooting?
<Kamion> I *believe* so but wouldn't be prepared to swear to it
<Kamion> doesn't bigger initramfs => more memory use too?
<Keybuk> mjg59: libsvga seems to do vesa
<mjg59> Kamion: Only at boot time
<Keybuk> that would be a better idea, no?
<mjg59> Keybuk: Ok, that might be saner
<eXistenZ> ivoks, are you there?
<Keybuk> libvga is only 340K ... and would be a lot less with just the important bits used
<mjg59> Keybuk: Though, presumably, requires writing of actual real vesa code?
<Keybuk> could use the vgagl thing ... acts like a framebuffer, but entirely in userspace
<Keybuk> that seems rather more sane in general than X :)
<bddebian> heh
<Keybuk> if we can get X started that early, I'm sticking gdm in it, not a splash screen <g>
<Keybuk> or, at least some kind of login screen so when we have a real X we can start their session
<bddebian> a real X ?
<Keybuk> one not using vesa :p
<bddebian> Ah :-)
<Trewas> I asked earlier on #ubuntu but unsurprisingly no-one answered... ubiquity is mentioned to automagically install grub, but in a system with both SATA and PATA disks where it will go, /dev/sda or /dev/hda?
<Keybuk> which did you install to?
<Trewas> I'm only planning to install, but it would go to /dev/hda but the system boots from /dev/sda, where xp is
<Keybuk> if you install to hda, it will go to hda I believe
<Trewas> ok, I guess I can convince windows' boot-manager to start grub from another disk if needed
<Keybuk> I'd do it the other way, start windows boot manager from grub
<shadeofgrey> pardon my intrusion but the retard level in the main support channel is redlining
<Trewas> well, that might be easier but if ubiquity does not ask where it will install grub... :)
<shadeofgrey> all i need to know is this -- did you guys do away with the .fonts folder in each users home?
<shadeofgrey> and how do i take a whole crapload of fonts off a CD and put them someplace where they're abailable for acertain user?  i went hunting for the .fonts dir in my home, and there isnt one...  do ijust need to create one?
<Keybuk> shadeofgrey: this is not a support channel
<shadeofgrey> kwy:  yes im well aware of that.  unfortunatelyt theres no supporting going on.  i wouldnt just show up here unless it was important and i couldnt fiund helping hands elsewhere
<crimsun> shadeofgrey: I'll address that in #ubuntu
<shadeofgrey> oh!  hi crimsun!
<Keybuk> shadeofgrey: and if we start supporting people in here, then we will lose a channel where we can discuss development matters
<shadeofgrey> id id seen your name i wold have asked you
<shadeofgrey> Key:  dont get excited...  i apologise wholeheartedly fot the intrusion
<Keybuk> back in ~30 mins
<shadeofgrey> this will be my last stop here for the evening..  i just wanted to say taht you guys did a fabulous job integrating installation with the desktop live CD ...  everything was implimented very well and the procedure for a full install has gottren really sexy and streamlined...  id just like to take a minute and thank everybody for all their hard work
<shadeofgrey> in my opinion, 6.06 marks ubuntu's transition from adolescent angst into mature young adult...  now all we have to do is get the kernel laid, and ...  =)
<shadeofgrey> just kidding.
<shadeofgrey> anyway thanks very much everybody for making ubuntu what it is..  i know its easy for we peons to forget just how much effort blood sweat and tears go into each milestone release... i was on the dapper bandwagon since flight2, and i must say.,. thi s is by far the best release yet...
<shadeofgrey> im honestly awestruck by how far we've come since warty
<shadeofgrey> and we'd of never have made it without you and all your support teams and such
<shadeofgrey> anyway..  i just want you all to know that i havent forgotten you and fully appreciate the sacrifices in timeand effort that you guys and gals make willingly in the ongoing determined effort to keep ubuntu on track and totally free
<shadeofgrey> ...ubuntu kicks fedora's ass 
<shadeofgrey> good night all.
<bddebian> :-)
<eXistenZ> ivoks, still there?
<neutrinomass> If a spec requires the development of software (http://wiki.ubuntu.com/EasyUsbAdsl), is it appropriate to start a project at SF.net as a homepage or is something else preferred ?
<Keybuk> launchpad and bzr would probably be "preferred"
<neutrinomass> Keybuk: Launchpad can doSVN (or CVS) and you can upload files there, right? Can you have a homepage with "The status of this project is this, we need help on that, etc." ?
<Keybuk> neutrinomass: Launchpad can do bzr
<Keybuk> which is our preferred version control system
<neutrinomass> Keybuk: Ok, thanks. I'm not familiar with bzr so I'll have to look it up. :)
<Keybuk> it does not currently offer file upload, though that would be a great wishlist
<Kamion> not files, but you can push a bzr repository
<neutrinomass> Hm.. is that a showstopper for hosting projects there or can people do bzr checkouts easily ?
<Kamion> bzr get URL
<ogra> Kamion, you can push already ? i thought it only pulls from locations i give it
<Keybuk> ogra: you can push
<Kamion> where URL is http://bazaar.launchpad.net/~OWNER/PRODUCT/BRANCHNAME or something along those lines
<ogra> wow
<Kamion> ogra: we're going to be doing the seeds that way for edgy
<Kamion> in fact it appears to have been pushed already
<ogra> Kamion, yes i noticed that, i didnt know that was already a public feature beyond the seeds
<Kamion> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy/
<Kamion> sure, we just used an already-existing feature and Scott pushed for a couple of relevant bugs to be fixed and the fixes deployed
<Keybuk> yeah, seems the push finally went through just now
<Keybuk> admittedly, I had to corner lifeless and tickle him until he told us the already-existing feature existed
<Keybuk> and how to actually use it
<ogra> cool 
<ogra> lol
<ivoks> eXistenZ: hey
<eXistenZ> ivoks, great to see you back again.
<ivoks> eXistenZ: that file is binary file
* Kamion notes a bunch of the branches on https://launchpad.net/people/kamion/+branches are finally being pulled now
<eXistenZ> ivoks, binary?
<Kamion> anyway, bedtime
<ivoks> Kamion: i agree :)
<eXistenZ> DId I do something wrong?
<ivoks> eXistenZ: wait a second
<Keybuk> Kamion: I wonder what suddenly magically happened just now
<Keybuk> Kamion: do you think we should push the warty+ seeds as well, for historical value?
<Kamion> Keybuk: sure; I'll do it tomorrow unless you want to do it right now
<Kamion> I have checkouts of everything
<Keybuk> I'll probably do it, I also have checkouts
<Keybuk> want to make sure the pushed copies are up to date while I'm at it
<ivoks> eXistenZ: this is old log
<eXistenZ> ivoks, it is new!
<ivoks> eXistenZ: 20:27 is clock
<eXistenZ> ivoks, yep
<ivoks> eXistenZ: and it says that runing gs is esp
<eXistenZ> ivoks, ok, let me try now
<eXistenZ> ivoks, Using `/usr/bin/gs-gpl' to provide `gs'.
<ivoks> eXistenZ: paste news to bug you reported
<ivoks> eXistenZ: i'm going off now
<eXistenZ> ivoks, ok :] 
<ivoks> 'night all
<eXistenZ> ivoks, it is 12:30AM here
<eXistenZ> ivoks, I believe I should go too
* Keybuk takes the next item from the top of his TODO list
#ubuntu-devel 2006-06-08
<sivang> hey slomo , long time :)
* Keybuk notices a complete lack of ubuntu-server edgy seeds
<mdke> man, I was just going to do a breezy->edgy server upgrade
<Keybuk> yeh, right :p
<Keybuk> there's no such thing as edgy yet :p
<zul> Keybuk: what is it september now
<Keybuk> November
<sivang> it's June, the last time I check :p
<Keybuk> sivang: when we're opening edgy.
<Keybuk> it delays an extra two days everyone asks
<Keybuk> we're into November before it opens now
* sivang shuts up and goes to face the cornet before Keybuk will punish him to write 100 times "I will not ask when Edgy opens yet again" :)
<Keybuk> the cornet? :p
<Keybuk> you like looking at ice cream vans?
<sivang> erm,
<sivang> you know what I meant ! :-)
<sivang> s/cornet/corner
<ogra> WOAH
<ogra> Keybuk, do you still use your little fanboy applet ? 
<Keybuk> no, why?
<Keybuk> I never especially used it in the first place
<Keybuk> I just wrote it because I wanted to play with pygtk for a few hours
<sivang> Keybuk: what does the fanboy applet do?
<Keybuk> sivang: shows how many fans in your laptop are running
<ogra> i used it as a base for a cpu temp monitor and poorted that one to ppc when i boiught my ibook
<ogra> if i start it witch a resen ppc kernel here i get:
<ogra> [78143.253071]   <1>Unable to handle kernel paging request for data at address 0x00000000
<ogra> [78182.632552]  Faulting instruction address: 0xc01cc450
<ogra> [78182.632569]  Oops: Kernel access of bad area, sig: 11 [#4] 
<ogra> reproducable with every start of the applet 
<ogra> ugh, what did i type ? 
<sivang> Keybuk: is it packaged somewhere? could be useful no?
<ogra> if i start it with a recent ppc kernel here ...
<Keybuk> sivang: it isn't
<Keybuk> I don't even have the source
<ogra> BenC, is opening /sys/devices/temperatures/sensor1_temperature from a python script supposed to produce oops on ppc ?
<freeluna> exit
<ogra> hmm, even a cat /sys/devices/temperatures/sensor1_temperature produces it
<mjg59> ogra: As far as the kernel is concerned, reading from a file is reading from a file
<ogra> hmm, then i wonder why i get oppses ... the temperature monitoring appears to be fine (fans work if the load is high)
<ogra> *oopses too
<mjg59> Because there's a bug in the kernel?
<ogra> hmm, apparently ... but i'd expect the fan management to be broken as well if reading the temp doesnt work 
<bddebian> Hello
<ogra> unless thats not done in the kernel on ibooks ...
<mjg59> ogra: Why?
<mjg59> ogra: If you look at the backtrace, it's likely to be blowing up in a pathway specific to reading the sysfs attribute
<ogra> yep, there is something with sysfs_read in there ...
<Keybuk> urgh, libsysfs
<Keybuk> kill it now!
<Keybuk> oh, wait, kernel
<ogra> heh
<sladen> Keybuk / Kamion: the code to check for 64bit is already in gfxboot.  Use the primitive/keyword '64bit'   (yes, it's the only "keyword" that starts with a number.  *sigh*
<Keybuk> oh, cool
<sladen> so, now you want laptop-detect in there?
<Keybuk> \o/
<ogra> hmm, the oops is gone after a reboot
<sivang> hmm, why can't I see ubuiguity in the dapper archive?
<crimsun> (where are you looking?)
<crimsun> [hopefully http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/] 
<sivang> yes, thanks
<sivang> should get to sleep
<sivang> ;)
<tseng> man
<tseng> isnt it almost morning there now?
<sivang> almost :)
<sivang> 3:15am
<tseng> you're sick
<sivang> I know :p
<sivang> I just can't stop .. writing specs can be adictive 
<sivang> to be more precise, the investigation for them.
<sivang> hmm, I need stratus. /me joins debian-devel
<sivang> tseng: trying to gues when package wil lcome for python-notify
<sivang> anywaym I'm oyut. some sleep is needed. urgently :)
<sivang> night all!
<ajmitch> afternoon
<desrt> word.
* desrt needs a BenC 
<mjg59> desrt: Managed to get any further?
<desrt> mjg59; no.  i have new fish to fry
<desrt> stuff is acting really really oddly
<desrt> sometimes when i come back from sleep video isn't working properly (like vbestate doesn't restore properly or something)
<desrt> i just came back to my machine after it running for a while and the keyboard (but not the mouse) had stopped working
<desrt> and (possibly the cause of all of these things) the harddrive is seriously messed up
<desrt> on resume i get
<desrt> ata1: resume device
<desrt> ata1: disabling port
<desrt> then it fails this assertion:
<desrt>         assert (ata_dev_present(master) || ata_dev_present(slave));
<desrt> (twice)
<desrt> then my harddrive is gone so anything not in the filesystem cache is not accessible
<mjg59> Well, the assertion is unsurprising
<desrt> and my filesystem remounts read-only
<mjg59> Given the initial failure
<desrt> not.
<desrt> the 'disabling port' thing can come from only two possible failures
<desrt> i googled it and found your name on an LKML posting
<desrt> my problem seems to be that the bus reset that accompanies the resume is failing for some reason
<mjg59> Hm
<mjg59> Debug code a-go go
<desrt> well
<desrt> it doesn't always happen
<desrt> plus...
<desrt> sometimes the drive is flaky even before i sleep
<desrt> like i'll boot into gnome
<mjg59> Less fun
<desrt> (first time)
<desrt> and processes will randomly go into D-state
<mjg59> Any dmesg errors?
<desrt> which i (perhaps foolishly) assume is drive messup
<desrt> no dmesg errors :(
<desrt> do you know of flags i might be able to give to the kernel to make it run the sata controller in a slower-and-safer mode?
<mjg59> Nope
<mjg59> I don't think sata rally has that concept
<desrt> 193:       7767          0   IO-APIC-level  libata, uhci_hcd:usb2, ohci1394
<desrt> hmm.
<desrt> libata shares IRQ with my usb port
<mjg59> Should be fine
<desrt> i wonder.....
<desrt> well, maybe that's why my keyboard stops
<mjg59> Though I wonder more if it's another irq issue
<mjg59> Like your acpi one
<desrt> 201:     296839          0   IO-APIC-level  uhci_hcd:usb1, ehci_hcd:usb5
<desrt> keyboard appears to be on this usb though :
<desrt> :/
<desrt> (up-enter, up-enter repeatedly increments that counter)
<mjg59> Wonder if the interrupt controller is being set up correctly
<desrt> a valid wonder.
<mjg59> Does it boot with noapic?
<sladen> Keybuk: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.dapper/ is meant to be empty?
<desrt> yes.  but with noapic it locks up on resume
<Keybuk> it's not empty
<desrt> (remember you had me try this)
<Keybuk> celebrate the fantastic bzr archive format
<Keybuk> (it has a .bzr)
<Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.dapper/.bzr/README
<sladen> oh, you're right, there's a .bzr
<desrt> mjg59; i hate laptops. :(
<mjg59> desrt: Haha
<desrt> why does linux have to have so many bugs in it?
<HrdwrBoB> why do you have to buy an unsupported machine
<desrt> it's so pretty
<tseng> haha
<bddebian> heh
<desrt> anyway... i guess i'll instrument my kernel like crazy
<desrt> figure out the exact source of this problem
<desrt> the only problem is that at the time the kernel borks out i have no way of writing down the info from dmesg
<desrt> other than to remember it in my head (or if i have paper close at hand)
<desrt> wtf is libata-acpi.c?
<mjg59> Binds acpi resume methods to libata
<desrt> i see.
<desrt> how interesting.
<desrt> why doesn't it just have a normal suspend/resume function?
<mjg59> Because laptops can be wired in strange and wonderful ways
<desrt> i hate laptops.
<mjg59> Bay devices may need powering up in fun ways, for instance
* ..[topic/#ubuntu-devel:Keybuk] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html
<desrt> mjg59; think it might be caused by the drive not powering up fast enough?
<desrt> ok.  just as a test i booted it up with the harddrive removed
<mjg59> desrt: Doubt that
<desrt> it behaves -exactly- like the error condition i described
<desrt> like, sleep [remove hd]  resume
<mjg59> Right
<desrt> i'm ircing from it right now with the HD out :)
<mjg59> Weird
<desrt> well
<desrt> it's got a gig of RAM
<desrt> that's a lot of cache space
<mjg59> I need to spend some time looking into libata suspend/resume stuff
<desrt> would it be safe to sleep the kernel for 2-3 seconds inside the ata resume code?
<mjg59> Should be
<mgalvin> here we go
* mgalvin is on the edge of his seat
<mgalvin> ok no more cheesy lines...
<jsgotangco> ?
* Keybuk pushes mgalvin off
<mgalvin> :)
<mgalvin> is there any info about the *-proposed archives?
<mgalvin> jsgotangco: edgy uploads started a little while ago :)
<desrt> would i use a normal sleep or a spinning sleep?
<jsgotangco> ZOMG
<jsgotangco> heh
<Keybuk> mgalvin: none, and we're the archive team
<Keybuk> someone in Launchpad claimed to know something about them, but didn't want to talk about it
<mgalvin> i mean there name is obvious but...
<mgalvin> Keybuk: ah ok
<ajmitch> mgalvin: patience, we have to wait for glibc & gcc to break everything
<Keybuk> I believe they're a free-for-all upload place for things that might, one day, be uploaded to -updates
<bddebian> ajmitch: :-)
<Keybuk> ajmitch: I've been running both all evening, they're _fine_
* Keybuk even has the edgy kernel and everything
<mgalvin> sweet
<Keybuk> that's not so fine
<Keybuk> but we don't worry too much
<ajmitch> I've been running the edgy kernel, but not the rest :)
* mgalvin is just looking for UWN content :)
<bddebian> Got Xorg 7.1? :-)
<ajmitch> Keybuk: it's no fun if *something* doesn't break in the first few hours
* jsgotangco subscribes
<bddebian> To what?  Edgy-changes?
<Keybuk> mgalvin: basically, afaiui, proposed is a place for people to upload bug fixes for a released release
<Keybuk> but it's not mentioned in /etc/apt/sources.list, so is only available to people who really need to look for a package there
<Keybuk> so there is less restriction than -updates, which is enabled by default
<mgalvin> Keybuk: ah, great thanks :)
* desrt jokingly muses about the 'correct' way to sleep for several seconds from interrupt context
<Keybuk> desrt: on your back
<bddebian> heh
<desrt> msec_delay_irq() appears correct
<desrt> oi modules
<desrt> mjg59; wanna know something funny?
<desrt> mjg59; i think the excessive irq9 traffic was a good thing
<desrt> mjg59; it slowed the box down on resume
<desrt> mjg59; with my delay inserted i've done half a dozen suspend/resume cycles and i can't get the drive to fail to initialise
* desrt continues... :)
<desrt> heh.  NetworkManager isn't liking all the suspend/resume action.
<desrt> cpu -> 100%
<Keybuk> yeah, it does that
<Keybuk> see the 5th or 6th bug page
<desrt> welp
<desrt> 12th resume, no problems
<desrt> i think that's the cause of this bug
<desrt> now all that remains is the stupid D-state bug
<stuNNed> what can i do to get my creative microphoto to work in latest stable ubuntu? i randomly picked it up at bestbuy and gnomad2 project says it is semi-functional but i can't seem to get the latest gnomad2 installed...i'd ask in the help chann but most of the those questions seem to be very install-relateed...maybe we need a #novice-ubuntu, #intermediate-ubuntu you guys think?
<Burgundavia> stuNNed: if #ubuntu cannot help you, try the mailing list or the forums. This is not a suppor channel
<stuNNed> burgundy: yeah yeah i'll try the lists i guess :\
<stuNNed> it was the best best buy had to offer as far as linux compatability :(
<stuNNed> fucking shame it is
<Burgundavia> stuNNed: oh, and file a bug about it not working ootb
<stuNNed> Burgundavia: i'm on it thanks
<Burgundavia> stuNNed: cheers
<stuNNed> burgundy: thanks, cheers
<stuNNed> too bad i'm drinking coffee but i need it and it's a local blend :)
<Chipzz> stuNNed: how is that install-related?
<Chipzz> or are you trying to install ubuntu on this device? ;)
<stuNNed> Chipzz: haha that would be the great and no.  i'm saying #ubuntu is too install-related as far as content and there should be #ubuntu-new, #ubuntu-mediate, and #ubuntu-expert or something...
<Chipzz> I agree with you on #ubuntu-expert ; in fact I've made an argument for such a thing here in the past
<Chipzz> but it's a 2 way cutting sword
<Chipzz> 1) you split up support resources
<Chipzz> 2) you'll always have newbies who feel that for some reason, the rules do not apply to them, and will join ubuntu-expert and start asking newbie questions there
<stuNNed> if i want a bleeding edge ubuntu friendly kernel can i get this?
<stuNNed> well...your support resources should not center on irc imho
<mjg59> stuNNed: See https://wiki.ubuntu.com/KernelGitGuide
<mjg59> Current git has 2.6.17 in
<stuNNed> mj: thanks mate
<stuNNed> this git thing looks nice, things have developed/moved forward since last time i touched linux/ubuntu, anyone know of a good general ppc linux download site?
<Burgundavia> stuNNed: what sort?
<stuNNed> burgundy: i found one thanks: http://penguinppc.org/
<bddebian> stuNNed: Debian.  YellowDog.
<bddebian> Ubuntu :-)
<Burgundavia> bddebian: yellow dog is mostly big iron these days
<bddebian> Burgundavia: Really?
<bddebian> They used to have the best PPC thing going.. Hmm
<Burgundavia> they still are, bigiron ppc
<stuNNed> bddebian: i don't get it
<stuNNed> bddebian: are you salesperson?
<bddebian> Ah, like RS/6000 type?
<jsgotangco> really?
<bddebian> stuNNed: Don't get what?
<stuNNed> bddebian: your words
<Burgundavia> jsgotangco: one of the guys from our local lug works for them
<jsgotangco> ahh
<bddebian> stuNNed: Ah, just ignore me then :-)
<Burgundavia> jsgotangco: he does desktop stuff for them, but he says he is the only one left
* infinity wonders why someone in #ubuntu-devel would ask for a PPC Linux distribution to download...
<infinity> stuNNed: Ubuntu/PPC works well.
<infinity> Oddly enough.
<Burgundavia> infinity: no, really?
<fabbione> hmmm
<fabbione> jdub: ping?
<stuNNed> infinity: i didn't ask that at all.  you drifted into what bddebian said.  i asked of a good url that has ppc software besides what is available in ubuntu but i probly don't need it so :P
<bddebian> Ah, then I (we?) mis-understood your question
<infinity> stuNNed: About the only thing some place like linuxppc would have that we don't ship is stuff built for MacOS (like, say, BootX)..
* bddebian shudders
* infinity still has BootX on his PPC machine, since his firmware and quik never got along.
<bddebian> infinity: OldWorld?
<infinity> bddebian: Yeah, Beige G3.
<bddebian> Ah
<bddebian> Yeah, that's a bitch.  I still have an old WallStreet PowerBook laying around here somewhere
* bddebian needs at least a B&W G3, a Sparc, and an amd64 for Edgy :-)
<LaserJock> shesh
<LaserJock> I just want an Ubuntu box available all day
<bddebian> I got 9 PC's running here now, what's a few more? :-)
<tritium> bddebian: why get a B&W G3?  Get a BMW M3 :)
<LaserJock> 9?!?!?
<LaserJock> tritium!
<bddebian> tritium: I could go for that too :-)
<tritium> LaserJock: :)
<bddebian> LaserJock: +1 dead Debian StinkPad :-)
<bddebian> +3 now 3 Ubuntu boxes at work :-)
<LaserJock> :(
<LaserJock> my 1.3GHz P4 (my only Ubuntu box at work) got stolen by an undergrad
<bddebian> No kidding?  That sucks
<LaserJock> and my Ubuntu computers at home are usually turned off
<LaserJock> well, he wanted a mac, so it wasn't too bad
<LaserJock> I can still ssh into a bit
<bddebian> Mine should be.  My electricity bill is outrageous :-)
<LaserJock> yeah
<bddebian> Not as bad as when I had the Proliant 3000 running though :-)
<bddebian> That thing was a pig
<ajmitch> and I just have 2 machines that run at home...
<bddebian> ajmitch: Well 4 of them are Hurd boxen so they aren't up much.. ;-P
<LaserJock> lol
<infinity> I don't generally believe in turning computers off...
<ajmitch> neither do I, except for general hardware failure
<infinity> I just don't like killing hard drives.
<infinity> Which seems to happen every second time I hit a power switch.
<infinity> (Interesting side note: If an old drive motor suddenly decides to stop spinning, feeding it 24 volts on the 12 volt line will sometimes get it spinning long enough to rescue the data... Before it seizes)
<infinity> Don't try that at home, kids.
<ajmitch> how long before it starts to smoke?
<bddebian> Put it in the freezer :-)
<dieman> infinity: crazy
<dieman> freezer ive heard a lot too
<infinity> ajmitch: The last time I did it, it started smoking a bit about halfway through the copy job.  No flames were seen, however.
<ajmitch> I'd assume the drive controller would be running off the 5V line stil
<infinity> Yes, generally.
<infinity> The electronics are a bit delicate to overvolt.
<infinity> The motor, though, has it comin' when it goes and stops spinning.
<bddebian> heh
* ajmitch is not surprised to see a number of people on the forums eager to dist-upgrade to edgy
<dieman> hahaha
<mjg59> What could possibly go wrong?
<dieman> amazon prime fucked up
<dieman> and they shipped my package late
<dieman> so they upgraded me to next day for free
<ajmitch> it's also great to read what *must* be in edgy (or the world will end)
<dieman> i think porn must be in edgy
<dieman> or else
<bddebian> heh
<dieman> my coworkers took great enjoyment in the porn desktop
<Burgundavia> must have initNG!!! must have Thunderbird!!
<infinity> Thunderbird?
<infinity> What, the minor bump from 1.5.0.2 to 1.5.0.4 is killing people?
<bddebian> Oh yeah baby
<dieman> i think i'll die if nm doesn't speak gprs by next tuesday, really.
<ajmitch> must have xgl by default!
<dieman> also, aiglx
<dieman> at the same time
<Burgundavia> no, thunderbird over evo
<dieman> not surprising there
<Burgundavia> and KDE and GNOME on the same cd, with a question in the installer
<mjg59> And a pony
<dieman> i can't even really endorse my wife using evo these days
<Burgundavia> i suffer through it
<Burgundavia> tb is just as bad, in different ways
<bddebian> mjg59: :-)
<dieman> yah
<mjg59> Someone needs to stop evo from sucking, because in a lot of ways it's much nicer than Thunderbird
<dieman> i get tb to crash like once a month
<dieman> evo doesn't have sort by group, i think
<Burgundavia> they just need some vision
<mjg59> Little things. Like using evolution-data-server
<dieman> does it have labels?
<tritium> mjg59: agreed
<Burgundavia> eeds looks exciting
<dieman> it'd be nice if evo was a collection of seperate apps
<bddebian> eeds?
<dieman> eeds?
<jsgotangco> lunch brb
<Burgundavia> embedded eds, done by openedhand for maemo
<bddebian> Yeah, clears that right up ;-P
<Burgundavia> http://projects.o-hand.com/eds
<Burgundavia> http://projects.o-hand.com/
<Burgundavia> they are doing cool things there
<dieman> nifty
<mjg59> Why isn't evo showing me the guadec calander?
<dieman> because you aren't using a mac? ;)
<bddebian> Ah, that is some cool little apps
<Burgundavia> bddebian: the dates and contacts stuff are rocking
<Burgundavia> honestly we might want to consider them for edgy
<Burgundavia> bddebian: can i make you package them for universe at least?
<tritium> Where has bob2 been?
<mjg59> That's better. Killing e-d-s has made it happier.
<mjg59> tritium: An excellent question
<mjg59> If you find out, can you let us know?
<ajmitch> tritium: noone has seen him for quite awhile
<tritium> If I find out, yes, but...
* ajmitch wonders if he's still in canberra
<tritium> speaking of e-d-s, I finally figured out I _have_ to save my password in evo to get alarm notifications and appointments in calendar applet to work
<Burgundavia> tritium: that is dumb
<tritium> This is a security no-no where I work
<tritium> Burgundavia: yep
<bddebian> Burgundavia: Sure :-)
<Burgundavia> bddebian: excellent
<bddebian> OK, bedtime for this old man.  Gnight folks
<LaserJock> tritium: what, they don't let you put your password on you monitor at Sandia? ;-)
<tritium> good night, bddebian 
<LaserJock> cya bddebian 
<tritium> LaserJock: heck, why not?  In good news, they've finally allowed the MacBook, once they clip the wires to the iSight camera
<tritium> since it's a tool of espionage
<Burgundavia> tritium: where do you work?
<LaserJock> tritium: bahahahaha
<tritium> Burgundavia: Sandia National Labs
<LaserJock> I never thought of that
<LaserJock> The Jordanian guy in my lab just uses it to talk to his buddies back home
<Burgundavia> tritium: wow, "Securing the free and peaceful world through technology"
<tritium> yep
<Burgundavia> means you have nothing to do with developing technology that makes the world more peaceful or free :)
<tritium> Burgundavia: there are many research areas, so don't be so sure
<Burgundavia> sorry, just a cynical Canuck speaking here
<Rotund> anyone know if there is an extension to X to play with the mouse "on the fly" like the driver options (buttons, etc)
<tritium> No problem.  All the same, that's why I don't like to talk about it much
<Burgundavia> tritium: indeed
<robitaille> Burgundavia,  National Labs in the US do all sort of stuff (I worked 2 years at Berkeley National Lab)
<Burgundavia> robitaille: yep, I saw that. Some of it looks very cool (fresh water stuff)
<robitaille> but LBL is a different beast from Sandia
<LaserJock> my lab collaborates with Sandia lab in Livermore, CA
<LaserJock> totally not related to anything to DOE, but they pay for it so whatever
* tritium puts the worms back in the can
<LaserJock> hehe
<pitti> Good morning
<ajmitch> morning pitti 
<pitti> hi ajmitch 
<makko> any particular reason dapper (unlike breezy!) does not support a graphical grub menu *by default*?
<makko> \sh: any particular reason dapper (unlike breezy!) does not support a graphical grub menu *by default*?
<\sh> makko: right question, wrong person :) I have no clue, actually I don't like graphical grub menus
<makko> \sh: you are the right person! you are the only person that seems to be awake... and you just came.
<makko> \sh: i am thinking of newbyes. they are prejudiced against text envs, especially when they come from the suse or mandriva world.
<ajmitch> hey \sh, mvo 
<fabbione> makko: please stop flooding this channel
<makko> ajmitch: what about me?
<fabbione> asking the same question twice in 2 minutes IS annoying
<makko> fabbione: do i look like i am not aware of that?
* ajmitch sees that a few things are getting into edgy-changes
<fabbione> makko: apparently you are not aware of it, otherwise you would not have done it
<\sh> makko: I'm not the right person, because I don't have a clue about graphical screens in grub, not even in breezy...you can ask me about pyqt and pykde or njam or whatever, but not grub...kthx
<pitti> iwj: dapper-security works again, please feel free to upload firefox 1.5.0.4
<makko> fabbione: no, i was aware of it, it's just that immediately after i asked that i saw \sh joining and i wanted \sh to get it too
<makko> fabbione: you can follow the log and you'll see what i mean
<fabbione> makko: and what does let you think \sh is the right person to ask?
<fabbione> and yes i read the log and i saw the timing too
<makko> fabbione: i really thought everybody was asleep and, since \sh was just comming, i assumed \sh was not :)
<makko> fabbione: but sorry anyway
<makko> fabbione: i know how it looks
<makko> fabbione: by the way, do you have any idea whom i should ask that?
<fabbione> makko: zul
<makko> fabbione: thanks
<siretart> uuuh, first edgy uploads. nice! - are the chroots already set up?
<dholbach> good morning
<infinity> siretart: Still bootstrapping, but that shouldn't stop people from uploading sources.
<Kamion> makko: we didn't do grub gfxboot because it would have been terrifyingly unsafe for dapper, especially as syslinux gfxboot was known to have problems on some machines. So I said no.
<makko_> Kamion: maybe this is why mandriva uses a patched lilo?
<Kamion> makko_: in general pulling in graphical patches for bootloaders was not appropriate for dapper. I'm not interested in discussing it more than that just now.
<makko_> Kamion: thank you.
<arejensen> Hi. I think I might have found a bug in the pythoncard-tools package in universe. Im not quite sure if I should submit it using the ordinary webinterface? Ive tried searching the wiki and documentation but couldnt find any info on it.
<crimsun> arejensen: better addressed in -motu or -bugs, but yes, please file a bug in Malone against that package
<Mithrandir> just file a bug using Launchpad.
<arejensen> Thank you very much crimsun and Mithrandir. -bugs said "Channel for Bugdays" so I thought it was only for bugsquashingfests or similar and not for normal use. :)
<arejensen> <-- A bit tired. It said so on the homepage.
<mdke> morning all
<jsgotangco> morning!
<sfllaw> morn-ing.
<sfllaw> very sleepy.
<mdke> heh
<jsgotangco> ahh yes
* jsgotangco actually woke up at 4am for edubuntu meeting today
<sfllaw> It's 4:35 right now.
<Hobbsee> that's insane.  i really would stay asleep for that.
* Hobbsee hands sfllaw a cup of coffee.
<sfllaw> No good.  I'm immune.
* Treenaks hands sfllaw some pills he bought from a guy on the streeet
<Treenaks> -e
<sfllaw> Nice.
<Treenaks> those should keep you awake ;)
<Treenaks> (and loving everyone)
<ajmitch> heh
<ajmitch> morning sfllaw :)
<ajmitch> good to see you up & about at this fine hour
<sfllaw> ajmitch: Thanks.
<Kamion> infinity: any idea why I got a pile of rejects for those breezy-security uploads?
<Kamion> from katie
<pitti> Kamion: I think all of them have been recovered already
<Kamion> oh, hey, I got accepts for them all as well, wasn't reading properly
<Kamion> thanks
<infinity> Kamion: elmo got into a rather heated debate with katie, that's all.
<infinity> And now I'm going to go have a similar argument with glibc.
<Kamion> iwj: do you think you'll be able to merge dpkg this morning?
<Kamion> Keybuk: I know you're probably not starting the big sync yet, but eyeballing and manually syncing libselinux and libsepol would be helpful
<sfllaw> Oh no.  The sun's coming up.
<iwj> Kamion: I would have said yes but I'd underestimated the number of specs we were supposed to be proposing, so I'll be working on that first and on the breezy ff security update.
<Keybuk> Kamion: any particular reason?
<iwj> Kamion: Do we have MoM working for it or is it manual ?  (Not a big problem, but MoM would save a bit of faff.)
<Kamion> Keybuk: build-deps of dpkg which is needed for debhelper which is needed for d-i
<Keybuk> it needs the new ones?
<Kamion> iwj: that's a Keybuk question, but I believe not yet
<Keybuk> ok
<Kamion> Build-Depends: debhelper (>= 4.1.81), pkg-config, po4a, libncurses5-dev | libncurses-dev, zlib1g-dev (>= 1:1.1.3-19.1), libbz2-dev, libselinux1-dev (>= 1.28-4) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] 
<Kamion> libselinux1-dev | 1.28-2ubuntu2 |          edgy | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> iwj: I could have a look and run the result by you, if that's preferable
<Keybuk> once we have working chroots I'll confer with infinity whether he wants the fire hose on trickle or "OMG! THE ASWAN DAM HAS BURST!"
<iwj> I don't mind but that might save time if you're in a hurry.
<Kamion> yeah, it's just because the stack for me is quite deep
<Kamion> (and tottering)
<iwj> Kamion: I don't _think_ there should be anything controversial and they've taken nearly all of the patches I sent I think.
<Kamion> I eyeballed it earlier in the week and spotted just one thing that wasn't merged
<Kamion> but I'll do a more detailed review
<mdke> sfllaw: perhaps when your body clock is back to normal we can hook up and have a word about the WelcomeCenter project?
<sfllaw> mdke: Yes.
<sfllaw> mdke: What TZ are you on?
<sfllaw> I'm UTC-4.
<mdke> sfllaw: UTC+1
<mdke> that would be great
<sfllaw> mdke: I'll ping you when I wake up.
<sfllaw> With any luck, I won't catch you during dinner.
<mdke> sfllaw: that sounds great, I'll keep my ears open
* Kamion tries out 'bzr checkout' on the seeds to see how this mode works
<jdub> Kamion: have you tried bound branches yet? rocks!
<Kamion> that's what I'm trying ...
<Keybuk> "Houston, we have achieved ... CVS!"
<Kamion> haha
<Kamion> woo, bound-branch commits to the seeds work
<Kamion> I think we should recommend that mode of operation
<Kamion> it's much less prone to weird-shit pull/merge confusion
<Kamion> recommend> for the seeds that is
<infinity> Is there any way to force that mode of operation?
<infinity> ie: Mark the parent repository as one that can't be pushed to, or something equally draconian?
<Kinnison> Unfortunately not
<Kinnison> IIRC
<Keybuk> infinity: all bound-mode means it that bzr remembers to push after you commit
<Kinnison> Keybuk: It's all a transaction
<infinity> Keybuk: Right, but a way to force a branch to behave in a "centralised repository" fashion would be useful for rare cases where distributed RC is not ideal.
<Kinnison> Keybuk: if it can't push then it uncommits locally
<Kinnison> Keybuk: IIRC
<Kinnison> Keybuk: either that or it unbinds and then to rebind you need to pull/push/merge to get the lines in sync
<Keybuk> Kinnison: I think the commit fails and it suggests that you can unbind if you want and try again
<Keybuk> infinity: agree
<Kamion> it says "unbind, update, or commit --local" I believe
<Kamion> commit/push is a transaction, yes, or at least so the docs say
<Keybuk> aah!
<Keybuk> NOW I HAVE COFFEE!
<ogra> mdz, already asleep ? i'm not sure what to do with the debian ltsp branch
<bytee_> infinity: ping 
<infinity> pong.
<bytee_> had a question with package naming
<jdub> Keybuk: you can bzr get, as long as you bzr bind (which i think is clearer than 15 ways of bzr get/pull/checkout/obtain/adopt/acquire/kidnap/etc)
<ajmitch> jdub: at least it's not baz
<jdub> in soviet russia, baz branches you (like basil fawlty's car)
* Kinnison snickers
* Kinnison imagines jdub jumping up and down, flagellating a car with a bzr branch
<mdz> ogra: I am sleeping in 4-hour shifts these days
<mdz> ogra: I need about an hour to catch up on other things, though; can you send me email about this?
<jdub> mdz: http://fedoraproject.org/wiki/StatelessLinuxCachedClient
<Kinnison> mdz: trying that bizarre multi-nap sleepcycle thing?
<Kinnison> polyphasic sleep or whatever it's called
<mdz> Kinnison: not intentionally, it's just worked out that way
<Kinnison> mdz: heh
<sivang> morning all
* sivang reads distro team meeting backlog
<sivang> Znarl, elmo : ping
<Znarl> sivang : Pong?
<sivang> Znarl: Don't want to be pushy, but can anything be done to help RT #10636 ? :-)
<Znarl> sivang : I will have it done in a few hours for you.
* sivang *hugs* Znarl 
<sivang> Znarl: thank you!
<ogra> mdz, mail sent
* infinity does his first accidental REJECTED upload to dapper, and then gets his s/dapper/edgy/ on...
<Kinnison> Hehe
<infinity> The great irony, of course, is that it was a base-files upload that had s/dapper/edgy/ ALL OVER IT, except for the changelog.
<Kinnison> Now if I could work out why the Packages files for dapper are seemingly being rewritten I'd be happy
<jono> hey all
<infinity> Kinnison: apt-ftparchive config is wrong?
<Kinnison> infinity: Not afaict
<Kinnison> infinity: check it out in .../ubuntu-misc/apt.conf
<Kinnison> infinity: also the log from the last run didn't claim to have written them
<Kinnison> it's most odd
<infinity> They've definitely changed recently.
<Kinnison> Indeed
<Kinnison> I'm exceedingly confused
* infinity scratches his head.
<Kinnison> infinity: bloody typical, they didn't get updated this cycle while I was watching
* Kinnison sighs
* Kinnison -> shops for lunch and to clear head
<infinity> Kinnison: Err, yes they did.
<infinity> Kinnison: They're only 15 minutes old.
<Kinnison> Hmm, then they didn't get updated in the apt-ftparchive stage
<infinity> (Or, exactly an hour younger than they were the last time I looked)
<Kinnison> since that's when I looked
<Kinnison> So they're being touched during one of the post-publish phases
<Kinnison> OMG I've got it
<Kinnison> They're identical to edgy right now
<infinity> dupe checking?
<Kinnison> dsync is deduping them to the edgy ones
<infinity> That theory holds up when we see that amd64 (which has new binaries in it) hasn't been updated, while i386 has been.
<infinity> So, as soon as I push this base-files through, the problem (but not the bug) goes away.
<Kinnison> Indeed
<infinity> Well, that probably means you can follow up to the bug and reduce it from critical to major.
<infinity> I still suspect that dupe-checking should be skipped entirely for {Packages,Sources}. :)
<infinity> It means that any empty files are getting "re-generated" at each go too, right?
<infinity> (So, say, and empty dapper-security would be re-downloaded every hour)
<infinity> s/and/an/
<Kinnison> Probably
<Kamion> iwj: http://people.ubuntu.com/~cjwatson/tmp/dpkg_1.13.21ubuntu1_debian.diff (new diff vs. Debian)
<Kamion> iwj: http://people.ubuntu.com/~cjwatson/tmp/dpkg_1.13.21ubuntu1_ubuntu.diff.gz (new diff vs. Ubuntu Dapper, but enormous; 14MB uncompressed)
<Kamion> I'm amazed we apparently never remembered to add amd64 to archtable
<Kamion> Keybuk: mind if I sync libsepol and libselinux? I've test-built them (albeit with the dapper toolchain) and they're fine
<Keybuk> sure
<Keybuk> infinity: how are those chroots?
<Kamion> hmm, looking at Debian #317082, we ought to get dpkg in ASAP anyway due to the shlibdeps changes
<Ubugtu> Debian bug 317082 in libc6-s390x "Subject: libc6-s390x: missing depends on lib64gcc1" [Serious,Closed]  http://bugs.debian.org/317082
<Mithrandir> ogra: what do you think about adding thinclient-local-devices to paris?
<ogra> Mithrandir, https://wiki.ubuntu.com/EdubuntuEdgyIdeas ;)
<Mithrandir> ogra: it's not marked for discussion in Paris.
<Mithrandir> ogra: also, ActiveDirectoryIntegration is covered by NetworkAuth which ajmitch is working on as part of SoC.
<ogra> Mithrandir, i wont mark it before i have all specs written, i'll do that for the whole bunch on that wikipage tomorrow
<Mithrandir> ogra: ok
<ogra> Mithrandir, only the stuff above the "Additional suggestions" line will be paris stuff
<ogra> i'm aware fo AD work in the network auth spec :)
<zul> heylo
<pitti> hi zul 
<pitti> BenC, zul: gates for *-security uploads are open, so please feel free to upload (once the two missing patches are applied)
<Kamion> sladen: I knew about gfxboot's 64bit operator - that wasn't what I was asking for a patch for ;-)
<Daemon> the AD integration would be excellent, I just went through the manual process today and while it's not too difficult, full integration / wizard driven setup would appeal to a lot of people
<ajmitch> Daemon: using winbind?
<Daemon> yep
<zul> pitti: ok, i have to boot the hoary with the two missing patches which i should be able to do tonight i should be able to upload for hoary at least
<pitti> great
<infinity> Keybuk: Coming along... glibc/base-files on amd64 upset me, but moving on.
<Kamion> dpkg landing now
<Kamion> will dep-wait for a while
<zul> pitti: but now i have to go blow away redhat on our mail servers ;)
<Kamion> now for coffee, then debhelper ...
<Keybuk> infinity: we don't even have new gcc yet? :p
<infinity> It's happening.  Meh.  Relax. :)
<Keybuk> I'm very relaxed
* Keybuk gives infinity lots of hugs
<tseng> were libselinux and libsepol meant to go to dapper?
<tseng> dapper-changes seems to think so
* Keybuk looks at Colin
<jdub> Kamion: heh, closes line on dpkg is fun ;)
<sladen> Kamion: ah, I think keybuk wants the 64bit one and you want the laptop-detect one.
<Keybuk> that's ... err ... interesting
<Keybuk> where did they go?
<Kamion> tseng: the .changes said edgy
<Kamion> sladen: nobody asked me or I'd have told them
<Kamion> OH
<Kamion> /srv/launchpad.net/codelines/current/scripts/process-upload.py -d ubuntu -r dapper -C sync $DRYRUN $NOMAILS -v .
<Kamion> from sync-queue/process-incoming.sh
<Keybuk> jdub: mostly translations I'd expect ... dpkg tradition has always been a new bug for every po file update requested
* Kamion fixes that
<Keybuk> Kamion: oh, wow
<makko> any special reason ubuntu's /etc/bash.bashrc doesn't include "export HISTCONTROL=ignoreboth"?
<Keybuk> I wonder whether gcc-defaults went to the right place, then
<Kamion> Listing ubuntu/dapper (ACCEPTED) 2/2
<Kamion> ---------|----|----------------------|----------------------|---------------
<Kamion>    40811 | S- | libsepol             | 1.12-1               | 19 minutes
<Kamion>          | * libsepol/1.12-1 Component: main Section: misc
<Kamion>    40810 | S- | libselinux           | 1.30-1               | 19 minutes
<Kamion>          | * libselinux/1.30-1 Component: main Section: libs
<makko> would anybody prefer duplicate lines in their bash's history?
<Kamion> ---------|----|----------------------|----------------------|---------------
<Kamion> fuck's SAKE
<Kamion> makko: it's configurable because you can configure it. HTH
<makko> Kamion: i am terribly sorry
<Kamion> makko: I'm not swearing at you
<Kamion> I'm swearing at the STUPID SYNC SCRIPTS
<makko> Kamion: i know, but i damaged your table, right?
<Keybuk> oh, I _really_ want to know where gcc-defaults went
<Kamion> watch me not care
<Keybuk> it's not in ACCEPTED
<Keybuk> and it's not in UNAPPROVED
<Kamion> makko: IRC is lossy and stuff gets interleaved, I deal with it, you should too
<Kamion> Keybuk: version?
<makko> right...
<Keybuk> 1.36
<Keybuk> I'm making damned, damned sure that didn't end up in dapper by accident
<Kamion> tseng: thanks for the heads-up, rejected from dapper
<Keybuk> it's ended up in the pool
<Kamion> the publisher is running ...
<Kamion> it may well be in limbo still, but will end up in dapper I suspect
<Keybuk> Kamion: that would have gone in last night
<Kamion> oh, ok
<Keybuk> when we rammed it through LP with a sledgehammer
<Kamion> what on earth did you do to get "Accepted (via black hackery):" anyway?
<Keybuk> before infinity found a user who could update the distrorelease table
<Keybuk> Kamion: ~lp_publish/mail-again.sh
<Kamion> like we did last summer
<Kamion> oh-kay
<makko> Kamion: well, i agree i can configure it and so can everybody, but i think it would be nice for us to add that by default, do you agree?
<Kamion> I'll just not look shall I
<Kamion> makko: no, I don't
<mdz> jdub: interesting; that's how I would have done it too
<Keybuk> Kamion: would you like to mentally erase the last few seconds of conversation? :p
<mdz> jdub: (the stateless update thing)
<makko> Kamion: could you please briefly explain to me why?
<mdz> jdub: I suggest pointing fabbione and jbailey to that for mubuntu
<jdub> mdz: ok :)
<jdub> mdz: what's that m for?
<Kamion> makko: because in case of doubt it's least-surprise for people if we stay close to the default
<jdub> micro?
<fabbione> mdz: ?
<dholbach> -buntu?
<Keybuk> buntu
<Kamion> and I can see why people might want it the other way
* dholbach -> break
<fabbione> jdub: mind to enlight me?
<jdub> fabbione: mailng you now
<fabbione> jdub: ok thanks
* Keybuk breaks out psql
<Keybuk>    id   | distrorelease | pocket | status
<Keybuk> --------+---------------+--------+--------
<Keybuk>   90205 |             6 |      0 |      2
<Keybuk>  120614 |             7 |      0 |      2
<Keybuk>  120643 |             6 |      0 |      2
* Keybuk frowns
<Keybuk> so it thinks gcc-defaults 1.36 is in, err, dapper
<Keybuk> HOLY CRAP
<Keybuk> we're so damned lucky LP is not sure whether it's generating dapper Packages files today
<Keybuk> Kamion, infinity: do you think we should shut down the publisher for a bit?
<Kamion> hell yes
<Kamion> we need to audit dapper now
<pitti> oh, should I better stop publishing security updates then?
<Keybuk> publisher is down
<sladen> if it got as far as the mirror;  you might want to kill rsyncd to stop it spreading
<Keybuk> and is not running
<Keybuk> sladen: I don't mind if it's just the pool that has been mirrored
<sladen> Keybuk: you might be concerned if it's the Release file
<Keybuk> that's the kind of thing I'm just starting to look at
<Keybuk> need to see how far this has spread
<Keybuk>  120644 |               103625 |             6 |      0 |      2
<Keybuk>  120643 |               103626 |             6 |      0 |      2
<Keybuk>  120642 |               103627 |             6 |      0 |      2
<siretart> http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-defaults/gcc-defaults_1.36.dsc does exist
<Kinnison> Launchpad is *NOT* generating dapper packages files
<Keybuk> ok
<Keybuk> confirmed in the database, it's just those three syncs
<Keybuk> gcc-defaults, java-gcj-compat and ecj-bootstrap
<Keybuk> Kamion: looks like you rejected libselinux/libsepol in time
<Kamion> yep, was fairly sure I had
<sivang> hmm, I just got an edgy changes mail :)
<infinity> Keybuk: You're going to fix those before I get around to wanting to build them, right? :)
<Keybuk> infinity: first we fix the archive
<infinity> Picky, picky.
<Kamion> debhelper will be fun, it has new-X-in-Debian assumptions
<mdz> Kamion: hmm?
<Kamion>   * dh_installxfonts: /etc/X11/fonts/X11R7 is deprecated, back to looking in
<Kamion>     old location, and not passing --x11r7-layout to update-fonts-alias and
<Kamion>     update-fonts-scale (but still to update-fonts-dir). Closes: #366234
<Kamion> that sort of thing
* pitti celebrates the first dapper USN https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-June/000326.html
<siretart> pitti: is dapper-security still via dak or via launchpad?
<pitti> siretart: still the dak dance
<siretart> pitti: anyway. congrats pitti :)
<pitti> i. e. dak -> dak buildds -> special LP upload -> lp processing
<infinity> Kamion: We only have one font location change to migrate to match with Debian, afaik.
<infinity> Kamion: And that should be handled in our X packages, not in debhelper.
<Kamion> infinity: right, the problem is that dh_installxfonts generates packages that call update-fonts-dir --x11r7-layout
<Kamion> infinity: will we error out on that?
<Kamion> or can we just assume that we'll update whatever provides update-fonts-dir before anything that calls dh_installxfonts?
<infinity> Kamion: Err, the entry you quoted says that it DOESN'T call that.
<Kamion> "but still to update-fonts-dir"
<infinity> Oh, I missed that.
<infinity> Feh.
<infinity> Poke me about it tomorrow, and we'll make sure debhelper versus X won't explode?
<Kamion> I could just merge xfonts-utils myself
<infinity> Or do that. :)
<Kamion> I want to get this sorted out in my current awake-cycle, if that's OK, because debhelper's needed for d-i
<Mithrandir> does tasksel support debtags?
<Kamion> dunno, what would be involved in that?
<Mithrandir> I'm browsing spec suggestions to see if there are any interesting ones in there and came across https://launchpad.net/distros/ubuntu/+spec/debtags
<Kamion> Keybuk: sometime that's not RIGHT NOW, you probably want to fix the new dh_installudev to match your policy
<Keybuk> there's a dh_installudev?
<Keybuk> ok
<Keybuk> is it still chained to the wall of Marco's wrongness?
<Kamion> Mithrandir: I don't think anyone's ever done that in Debian, no
<Kamion> Mithrandir: but if we do tasksel, then I was intending for it to be linked to seeds
<Kamion> Keybuk: yes, WRT /etc/udev/ and symlinks in rules.d
<Mithrandir> Kamion: with each task being its own seed?
<Kamion> Mithrandir: something like that; I haven't thought it out in depth yet
* Mithrandir hugs Keybuk over https://launchpad.net/distros/ubuntu/+spec/automake-transition
<Keybuk> Kamion: ok, do you want me to fix it before you upload debhinderer?
<Kamion> Keybuk: if you want to send me a patch against debhelper-in-Debian now, I can apply it to the thing I'm rolling together
<Keybuk> Mithrandir: ooh, thanks for reminding me *add-to-meeting*
<Keybuk> Kamion: I'll do it when the fires are out :p
<Kamion> the problem with debhelper is that you have to coordinate with EVERYONE
<Keybuk> so ~10 mins
<\sh> so edgy will be only 4 months development time, right? 
<Hobbsee> !!!  LP added "search by recently changed"  - AWESOME!
* Hobbsee goes dancing around the room happily
<Kamion> \sh: 4.5 months, yes
<\sh> rocking
<jdub> smart doesn't seem to grok dpkg holds
<kiko> niemeyer wants to hear about that.
* jdub goes to find if smart has a bug tracker
<mdz> sivang: there seem to be both home-user-backup and edgy-home-user-backup specs, with nearly identical summaries
<mdz> sivang: both proposed for paris
<enrico> Mithrandir: the idea to implement that was to add a post-hook to apt-get update that would mark as 'to install' all packages matching a given tag expression.  Then when you run the package manager, it would do conflict resolution and so on
<sivang> mdz: yes, sorry, Keybuk was supposed to drop one of them for me. Please decline the edgy-*... , I eventually left it and made changes onto the original one, to allow for all the original subscribers to still track development
<Keybuk> sivang: you never told me which one
<Keybuk> you /quit
<sivang> Keybuk: ah, sorry, network issues probably :( 
<sivang> then my bad
<Mithrandir> infinity: would discussing https://launchpad.net/distros/ubuntu/+spec/early-userspace/ in Paris make sense?
<infinity> Mithrandir: I intend to do some initramfs work in edgy, especially dm-crypt and fakeraid stuff, but I'm not sure how much discussion it really needs.
<tseng> Kamion: no problem.
<pitti> ajmitch: still here?
<ajmitch> yep
<ajmitch> pitti: what's up?
<pitti> ajmitch: will you be in Paris?
<pitti> ajmitch: I wonder whether it makes sense to register an SSP spec
<ajmitch> no, I won't be there, sorry
<pitti> ajmitch: we should get some thorough tests going in edgy, and if it's successful, enable it by default in edgy+1
<ajmitch> a spec still sounds like a good idea :)
<ajmitch> yagisan has been doing a bit with that lately
<pitti> ajmitch: we already have two proactive security related specs, but they are way too big and need to be split
<mvo> hello enrico, I suppose you got my mail then :) ?
<ajmitch> pitti: I'm going to try & rewrite the selinux spec at least
<enrico> mvo: yes!  I was at work and I still haven't had the time to reply, but in short: YAY!!
<pitti> ajmitch: we have proactive-security-stage-1 and proactive-security
<enrico> mvo: I'm glad Dapper released and people got a bit of spare time ;)
<ajmitch> fun
* ajmitch checks them out
<pitti> ajmitch: I'll create an ssp spec and register it for Paris
<mvo> enrico: cool, thanks. I hope to be able to do some other smallish improvments too
<ajmitch> ok, I'll try & participate by voip or irc :)
<pitti> ajmitch: I'll talk about it with doko and jbailey (and infinity perhaps, for a parallel test archive)
<pitti> ajmitch: that would be nice :)
<enrico> mvo: mornfall has been having a look at the code
<mvo> enrico: ah, nice. I'll be happy to hear his feedback
<mvo> enrico: I'm not religious about the way it is done, any suggestions/feedback is welcome
<zul> ajmitch: paris is going to have voip?
<zul> doh..
<ajmitch> zul: I heard that something may happen
<mvo> Mithrandir: will there be a multiarch spec?
<jdub> 'apt in universe' > 'smart in edgy' ;-)
<mvo> jdub: be careful what you wish for ... it might get it ;)
<jdub> mvo: 8)
<mvo> mdz: the "smart-notifier" from you list is a update-notifier based on smart? or something else entirely?
<Keybuk> ok
<Keybuk> dapper crisis averted
<Keybuk> the packages are now where they should be
<Mithrandir> mvo: I'm not sure; 4.5 months is really not enough time to do it.
<pitti> ajmitch: https://launchpad.net/distros/ubuntu/+spec/gcc-ssp, feel free to subscribe
* ajmitch subscribes
<pitti> ajmitch: btw, do you have any plans wrt. selinux?
<ajmitch>  yes
<Kamion> Keybuk: ok, dh_installudev reminder then :)
<ajmitch> work with manoj, erich & rjc in debian, hopefully get stuff by feature freeze :)
<Keybuk> Kamion: yup, just switching state
<mvo> what was the consensus about SoC work? they should only be added if the person comes to paris, right?
<mdz> mvo: no, it's something else entirely (apt-cache show smart-notifier)
<jdub> mvo: "your disk is dying - stop upgrading all the time!"
<ajmitch> mvo: hm, I added mine to the sprint anyway. I guess it could be removed
<mvo> mdz, jdub: aha, that sounds useful
<ajmitch> since the majority of it was agreed on at ubz
<tseng> pitti: reading your ssp spec
<pitti> it's not yet a spec :)
<tseng> ok :)
<tseng> do you have an idea of how to do it per package?
<tseng> or the reverse
<tseng> oh, subarch
<tseng> ignore me
<Keybuk> Kamion: cron is going down for a bit again
<Keybuk> so unless you're particularly desperate, I'll do the dh_installudev bit after lunch
<jsgotangco> good evening
<mornfall> enrico: i'm in the right ubuntu-devel? :)
<mornfall> mvo: i had a quick look at the code, nothing deep, my only concern is how can i point apt at ddtp.debian.org for translations and something else for Package indexes
<Kamion> Keybuk: ok, I've been trying to figure out how packages actually use it
<mvo> mornfall: this is currently not supported, the translations have to be at the same place as the other stuff. a anoying limitation
<mornfall> but i suspect we are hitting sort of fundamental issues with sources.list
<enrico> mornfall: right, you're in the right one
<Kagou> hi
<mvo> mornfall: does the other stuff (update moved into libapt) look useful to you?
<mvo> i.e. will it help ?
<mornfall> mvo: i have only fetched the ddtp branch for now (bzr takes *insane* amount of time to get branches)
<mornfall> mvo: from your mail (enrico bounced it to me) i think it should be OK
<jsgotangco> mvo: hi! any tip on where to start debugging on a segfault to apt on a fresh dapper kubuntu?
<mvo> mornfall: yeah, it should be a bit better once I converted all my branches to the new bzr 0.8 format
<mvo> jsgotangco: a gdb backtrace would be a good start :) put it on a pastebin please
<jsgotangco> thanks
<mvo> mornfall: cool, thanks
<mvo> mornfall: I hope that the ddtp stuff gets up to some speed now that they have a working server again. that would be really good. I'm not religious about the implementation, the advantage is that it is here and seems to work reasonable well
<mornfall> mvo: any plans to push all this into say debian experimental?
<mvo> mornfall: it is in experimental already (the ddtp bits) - the update stuff is only a couple of days old, I wanted to wait for your/enricos feedback first :)
<mornfall> mvo: hmm i must have missed it then, that's why i fetched from bzr
<mornfall> mvo: well let me run bzr get for the update stuff and you can have more feedback when i get home in some half hour (which should be enough for bzr to finish :)
<mornfall> mvo: the branch is ListUpdateMethod?
<mvo> mornfall: yes, that is the branch. thanks, no rush :) 
<Kamion> Keybuk: you'll need to tweak the default priority and the way it automatically adds "_" (we want "-")
<sladen> Keybuk: would the udev bug also cause NIC to be renumbered.  at some point eth0 and eth1 swapped.
<sladen> Keybuk: but I can't place when
<mdz> pitti: are we going to try enabling SSP in edgy?  if so, during or after this initial round of toolchain updates?
<pitti> mdz: incidentially I just added a spec for that :)
<mdz> pitti: oh good, what's the name?  it's on my list and I'd like to link to it
<pitti> mdz: my feeling is to selectively enable it for some packages in edgy and do a test-build of the archive, and if that works, switch over in edgy+1
<pitti> mdz: https://launchpad.net/distros/ubuntu/+spec/gcc-ssp
<tseng> it is unfortunate that people are insistant on turning any proactive security roadmap into a giant spagetti monster that pulls in every technology on the market
<pitti> tseng: we should mark roadmaps as informational and split out the various things into separate specs
<tseng> pitti: yes.
<jdub> ROAR SPAGHETTI MONSTER!!!
<tseng> turning on ssp on things like apache, postfix will give us alot of bang for our buck
<pitti> right
<pitti> and enabling it per-package is easier to test
<ajmitch> tseng: but we have to HAVE IT ALL!!
<tseng> ajmitch: you don't have the line quite right
<thom> GOTTA CATCH EM ALL
<ajmitch> sorry
<tseng> ajmitch: if you dont do X, you leave your system wide open to attack!!
* ajmitch needs to learn from the pros
<tseng> :)
<ajmitch> it's part of the fun of the specs being linked to wiki pages. people can go & change around a spec quite nicely
<tseng> pitti: i think ASLR will be cheap and easy
<pitti> indeed
<pitti> but my favourite one is the stack protection
<tseng> they are very complimentary
<mdz> Kamion: for edgy, I want to have a new kind of server seed which is actually a set of packages to install by default on servers.  how do you think we should arrange it?  the current server seed would be more aptly named server-ship or such
<Kamion> mdz: ship-server, by analogy with ship-live
<Kamion> mdz: but exactly that change would be fine by me
<mdz> pitti: don't forget to propose gcc-ssp for paris
<ogra> Kamion, oh, we should also find a new name for the edubuntu server seed, i'm tired of all the merge conflicts ...
<pitti> mdz: I already did
<Kamion> ogra: mdz's suggestion would bring server more into line with you
<Kamion> in purpose if not quite in contents
<ajmitch> mdz: what would be in this new seed? 
<mdz> ajmitch: so far just evms/lvm/mdadm
<mdz> and powernowd
<jdub> and sshd?
<tseng> jdub++
<mdz> jdub: that's more debatable I think
<jdub> mdz: yeah ;)
<ogra> Kagou, well, as long as the contents still differ i dont really care about the naming ;) since the conflicts will persist
<Kamion> ogra: not to the same extent
<ogra> s/Kagou/Kamion indeed
<Kagou> :)
<Kamion> you have changes in several of the other seeds too - those aren't conflicts, they're intentional divergence
<ogra> well, i'd like a solution without conflicts ;)
<Keybuk> sladen: are they on different buses?
<Kamion> you don't have conflicts
<Kamion> you have divergence
<ogra> hmm, k
<Kamion> if the contents come more into line, then having to *resolve* conflicts during merges will be less frequent
<Kamion> they do not have to be identical for this
<ogra> ok
<Kamion> I also think the way you're doing merges is fundamentally broken which is not helping you
<mdz> Kamion: would you be fine with that change even if I made it right now?
<sladen> Keybuk: 0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)
<ogra> Kamion, i can only cherrypick most merges ...
<Kamion> ogra: there are a *lot* of instances in the Edubuntu seeds where bzr indicates that you just applied the diff, rather than doing 'bzr merge'
<sladen> 0000:04:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
<Kamion> ogra: that means you have to re-merge the changes later
<Kamion> ogra: no, I'm not talking about cherry-picking here, but routine merges
<Kamion> the evidence is in the seed archives
<Keybuk> sladen: PCIe?
<ogra> well, there is a lot in the ubuntu seeds that we cant ship in edubuntu
<Kamion> ogra: yes, but you still MUST use 'bzr merge'
<mdz> ogra: if that's true, then perhaps it's time to start fresh with edgy
<sladen> Keybuk: yes
<mdz> and do the merges correctly going forward
<Kamion> ogra: otherwise the next merge will try to do the same things again ... and again ... and again
<Keybuk> sladen: the udev bug could explain them getting swapped, but then there's no guarantee of order of those anyway -- taking a few extra seconds to load firmware would have the same effect
<ogra> if i cherrypick something, i usually get a conflict, which causes the merged changelogs to disappear
<Kamion> ogra: I have never seen that behaviour and I don't believe it
<Kamion> seriously
<Kamion> I merge stuff a lot
<ogra> so there is no trace in the changelog about the merge once i resolved a conflict
<Kamion> then you are doing something broken
<mdz> I must agree with Kamion, I've done this loads of times
<Kamion> this does not happen to anyone else doing merges
<ogra> well, i get a bzr message that this ot that file have a conflict 
<mdz> ogra: the next time that happens, ask for help
<Kamion> ogra: yes, and then you do 'bzr resolved' once you've fixed it
<ogra> i edit that file, type bzr resolved <file> and commit
<Kamion> mdz: a single correct merge will sort it out
<Kamion> (at the moment, due to a bzr bug, you have to 'rm .bzr/checkout/conflicts' after resolving everything)
<ogra> s/ot/or/
<Kamion> (bzr resolved is broken for knit branches)
<ogra> oooh
<Kamion> (or possibly for metadir checkouts, not sure)
<Kamion> ogra: this is not your problem though.
<Kamion> ogra: if this were your problem, you wouldn't be able to commit
<ogra> hmm, i had that behavior before knits already i think
<Kamion> you would get a message from commit saying that your tree was conflicted
<Kamion> it would not cause merge records to disappear
<Kamion> please also ensure you're using the version of bzr in dapper, in case you have a random snapshot from before it stabilised there
<ogra> no no, i use the latest dapper version
<Kamion> ok
<ogra> but i dont get why resolving eats the merge logs
<Kamion> please ask for help from #bzr next time that happens, and don't commit
<Kamion> 'bzr status' should show the merge logs
<Keybuk> how bad is ogra's tree at the moment?
<ogra> it does until i change the conflicting file
<Kamion> ogra: right, at that point, ask #bzr
<ogra> ok
<Kamion> Keybuk: I *think* I did a merge since ogra's last one, but I'll check
<ogra> but as i understand you you mean i should always merge everything, then commit and revert what i dont need ? 
<Kamion> s/commit and revert/revert and commit/
<Kamion> yes
<Keybuk> if it needs smashing, you can push --overwrite ubuntu.edgy, then copy his files over and commit again -- it'd throw away his history though, but at least give a consistent start point
<Kamion> if you don't, the next bzr merge will offer you the same thing and you'll have to make the decision again
<ogra> *commit and revert and commit ;)
<Kamion> no
<Kamion> absolutely not
<Kamion> the process of resolving the merge should include making it look how you want it to look, at each commit step
<ogra> well, that way i wont lose the merge logs at the moment :)
<ogra> ok
<Kamion> I'd rather you didn't commit any merges until you figure out what's wrong
<ogra> yep, understood
<Kamion> Keybuk: not too bad, there's a merge from me ten commits back
<Kamion> and I had to re-merge a bunch of stuff in that
<Kamion> hmm, perhaps something is wrong with the tree though
<Kamion> because there's a commit from Keybuk saying "merge kernel ABI bump" with no merge log
<mdz> mvo: what do you think about the idea of displaying urgency information directly in update-manager?
<Keybuk> iwj: I don't suppose you can recall what substance you were consuming when you decided dpkg should exec("rm") rather than calling unlink()? :p
<Kamion> in fairness it is rm -rf, but yeah ;)
<mvo> mdz: by checking the origin? or parsing the changelog? I think its a good idea, but if it is changelog based, it would require to download all the changelogs heads
<mdz> mvo: we'd have to either parse the changelog or maintain a new metafile
<Kamion> Keybuk: am I ok to sync po-debconf? build-dep for world
<mdz> mvo: (the metafile would basically pre-parse the changelog, I suppose)
<Keybuk> Kamion: yeah, it won't go anywhere for a bit
<Keybuk> except possibly into BREEZY!  </sarcasm>
<Kamion> that'd be funny. once
<mvo> mdz: fine with me, should I add a spec for this? or just make a note?
<mdz> mvo: a spec would be appropriate, assuming it interests you...propose it for paris and send me the URL so I can mark it on my wishlist ;-)
<mvo> mdz: ok, I'm on it :)
<ogra> so are we free to upload new crack already ? or is still something broken ? 
<Keybuk> ogra: hold off for now
<ogra> *twiddle* *twiddle*
<mdz> ogra: if you are bored, get your specs proposed for Paris as I asked :-P
<ogra> mdz, they'll be ready for you tomorrow morning as promised :)
<iwj> Keybuk: you think I should have used ftw ? :-)
<iwj> Given that I had the fork-and-exec machinery, it was less code.  Less code => less bugs.
<Keybuk> iwj: true, doesn't cope well with the dynamic-link loader vanishing during an upgrade though :p
<iwj> Keybuk: the dynamic link loader is NEVER permitted to EVER EVER disappear.
<iwj> Since (eg) dpkg does not trap ^C.
<iwj> And lots of other reasons.
<iwj> If your ld.so disappears then you are hosed.  DDTT.
<Keybuk> iwj: it disappears
<Keybuk> some bright spark moved the /lib64 symlink across two packages
<iwj> Do we have a way of getting firefox_1.4.99+1.5rc3.dfsg-1ubuntu3.diff.gz given that I seem not to have kept a copy.
<Keybuk> iwj: (context-switch) where was it published?
<Kamion> should be in the librarian
<iwj> Keybuk: that can be done with rename(2) I think.
<Kamion> oh, predates the librarian ...
<iwj> Keybuk: (1ubuntu3) early dapper.
<Kamion> yes, I'll fetch it from jackass for you
<iwj> Thanks a lot.
<iwj> My research indicates :-) that that's the one I want ...
<Keybuk> Kamion: while you're on jackass, could you tarball the morgue up for me and put it on rookery or chinstrap or some other machine I have access to
<Kamion> iwj: it's in http://people.ubuntu.com/~cjwatson/tmp/ with the dsc
<Kamion> Keybuk: urr, can't you get access? it's f'ing huge
<Kamion> I'd rather not have it transferred across the network twice :)
<iwj> Kamion: Thanks a lot.
<Kamion> 261468476       /srv/ftp.no-name-yet.com/morgue/
<Kamion> (KB)
<Keybuk> Kamion: see if you can rsync to cjwatson@casey:
<Keybuk> oh, 261KB ?
<Keybuk> meh
<Kamion> 261GB
<Keybuk> GB even
<iwj> Oh, damn, I've just remembered.  This breezy install mysteriously doesn't boot.
<Keybuk> meh, I'll have to do that
<Keybuk> seeing as I only want sources
<Kamion> I have access to casey ...
<Keybuk> Kamion: you should have yeah
<Kamion> I could try to rsync just sources
<Keybuk> Kamion: if you could that'd be great
<Keybuk> Kamion: (c-s) http://people.ubuntu.com/~scott/debhelper.ubuntu-udev.patch
<\sh> syncs to edgy are already running?
<Kamion> \sh: very selectively
<Kamion> we're bringing up the core first
<Keybuk> Kamion: ^R ... just cleaned up an odd diff
<\sh> Kamion: good to hear :) 
<iwj> Is anyone interested in the fact that I have a machine I can't install breezy on ?  If not then I'll carry on using that install as a chroot ...
<Keybuk> iwj: can you install dapper on it?
<iwj> Yes.
<Kamion> Keybuk: yup, looks like what I had in mind too
<iwj> And I _used_ to be able to install breezy on it.
<iwj> I suspect that it's something to do with the changes to the various other installs in the meantime.
<iwj> It seems to go wrong sometime in update-grub.
<Keybuk> XFS?
<iwj> (I know this isn't a proper bug report etc.; I'm just asking to see if it's worth actually collecting the info.)
<Keybuk> ah, no, you use real filesystems
<Keybuk> hmm
<iwj> No, no XFS.
<iwj> real filesystems> Sometimes I use reiserfs.  I don't think that counts ...
<Kamion> infinity: don't build debhelper until you've built dpkg
<Kamion> infinity: given that, should I upload debhelper, or hold off?
<iwj> Furthermore, this install doesn't have `ed' !
<ogra> take anjuta then :P
<iwj> Um, actually, this thing is clearly hosed; the sources.list has no network sources.
<iwj> *sigh*
<Kamion> that can happen if it couldn't talk to the network during installation
<Kamion> (in breezy anyway)
<iwj> But it could.
<Kamion> Keybuk: thanks, will upload either after I hear from infinity, or a few hours after that, depending on the answer
<infinity> Kamion: Go ahead, I have a running list in my head.  I'll do dpkg right after the toolchain mess.
<Kamion> infinity: libsepol -> libselinux -> dpkg -> debhelper
<Kamion> with publisher run between each
<infinity> FUN.
<Kamion> though dep-wait will enforce the first couple anyway
<iwj> mutter mutter selinux mutter pointless mutter mutter
<infinity> Guess that's my tomorrow. :)
<ogra> iwj++
<Kamion> I suppose I should test-build something with this debhelper; I have to go and play chauffeur now though, so it'll be an hour or so
<Kamion> debhelper won't be restricted to dep-wait though - it just Depends: dpkg
<Kamion> >= obviously
<Kamion> and since dpkg Build-Depends: debhelper now, it would be rather bad to build debhelper before the version of dpkg on which it Depends
<Kamion> (I thought that was kind of a silly move too, but ...)
<Keybuk> Kamion: it was supposed to b-d only on stable debhelper
<Keybuk> have the new guys broken that?
<Kamion> no, it's only debhelper 4.1.81, but I suspect the buildds will still be rather unhappy if the debhelper in the archive is uninstallable while trying to build dpkg
<Kamion> or while trying to build anything, for that matter
<Kamion> stuff's syncing to casey, btw, I'll check when I get back and let you know if it's done
<Kamion> it's up to 2005-09-27
<Keybuk> iwj: ... *blink* ...
<Keybuk> dpkg: error processing /home/buildd/build-202059-100120/chroot-autobuild/var/cache/apt/archives/lib32gcc1_1%3a4.0.3-1ubuntu5_amd64.deb (--unpack):
<Keybuk>  trying to overwrite `/usr/lib32', which is also in package fakeroot
<Keybuk> since when can directories conflict?
<iwj> There must be symlinks involved.
<iwj> Is it currently a symlink ?  And the new object is a symlink too ?
<iwj> etc. (similar questions)
<infinity> It's not a symlink, I just reproduced the same steps on an upacked copy of the same tarball.
<infinity> Entertainingly, the package unpacked right before it (libc6-i386) also contains /usr/lib32 and had no problems.
<iwj> It's not a symlink on the fs before, and not a symlink in the package ?
<infinity> Right, and right.
<iwj> And not diverted ?
<infinity> Nope.
<iwj> Freaky.
<infinity> Can you even get away with trying to divert a directory?
<iwj> That's definitely very wrong.
<iwj> I really really wouldn't :-).
<infinity> Well, not only is it wrong, but i can't reproduce it outside the buildd.
<Keybuk> infinity: 
<infinity> Which is even more wrong.
<iwj> But it's the kind of thing someone will try.
<Keybuk> lrwxrwxrwx root/root         0 2006-06-08 07:44:24 ./usr/lib32 -> /emul/ia32-linux/usr/lib
<Keybuk> ^ in libc6-i386
<iwj> And does that exist ?
<ogra>  /emul ?
<infinity> Oh, so is libc6-i386 overwriting the previous directory with a symlink?
<iwj> It should be fine to install a directory where there's a link to a different directory; dpkg will follow the link.
<iwj> ogra: does /emul/ia32-linux/usr/lib exist, I mean.
<infinity> Keybuk: Erm, I can install libc6-i386 just fine with no such craziness when I do it on a local copy of the same chroot tarball.
<iwj> If the symlink is in the same package you have to note that they're usually arranged to come last in the package fsys tarball.
<ogra> iwj, yes, thats what i was wondering, i never heard of /emul ever
<Keybuk> infinity: then try installing lib32gcc1
<infinity> Keybuk: Goes fine.
<Keybuk> infinity: ok, try it in the same run
<Keybuk> just unpack them both
<infinity> Keybuk: I did.  Went fine.
<iwj> same run> shouldn't make a difference.
<iwj> Order might make a difference.
<iwj> Err, of course the maintscripts might mess with it too.
<iwj> If you tell me exactly which files I should tar zvvtf and dpkg --contents I can attempt to predict the behaviour :-).
<ivoks> hi all
<pitti> hi ivoks
<infinity> Keybuk: OTOH, I think the whole link to /emul thing is clearly a bug anyway.. Let me find a Jeff to poke.
<iwj> Does this /emul symlink thing exist in the packages or just on the buildd ?
<ivoks> hi pitti 
<infinity> iwj: It's just in the package.  It's also not supposed to be there.  Getting that fixed.
<iwj> Right.  OK :-).
<infinity> iwj: I'm still curious as to why it works when I upgrade by hand, but not when the buildd does exactly the same thing, but whatever.
<ivoks> pitti: do you need help with that printing spec? :)
<pitti> ivoks: always :)
<mornfall> mvo: hmm, i don't use pkgCacheFile at all in libept
<ivoks> pitti: so, eggdrop will be or something else?
<pitti> ivoks: not sure about the gnome part, but since g-cups-mgr is dead upstream, and we want hal/dbus love anyway, it'll certainly be eggcups
<ivoks> eggcups, not eggdrop :)
<iwj> infinity: if the link target doesn't exist, dpkg will consider the existing directory and the new symlink to clash (and vice versa).
<iwj> I expect the buildd just does things in a slightly different order or something.
<infinity> iwj: The target existed.
<ivoks> (tired)
<infinity> iwj: It's shipped in the same package.
<iwj> No, _already_ existed.
<iwj> I'm not sure of the exact sequence of events if it's in the same package but I wouldn't be surprised if some combinations of attempts to do things didn't work.
<mdke> Znarl: here?
<mdz> Kamion,*: http://people.ubuntu.com/~mdz/temp/ubuntu-server.diff
<fabbione> mdz: why do you want to turn -server into a meta package?
<fabbione> mdz: something on that diff is weird tho
<fabbione> === added file 'server'
<fabbione> --- /dev/null	
<fabbione> +++ server	
<pitti> *** stack smashing detected ***: cmd-safe terminated
* pitti hugs gcc-4.1
<mdz> fabbione: that's the normal way to show diffs for added files
<fabbione> === renamed file 'server' => 'ship-server'
<ajmitch> pitti: testing with SSP?
<fabbione> bah yeah i know about added files
<fabbione> but why is it added?
<pitti> ajmitch: yep, in sid
<ajmitch> yay :)
<fabbione> there was already a server there
<mdz> fabbione: the current 'server' is 'included on the server CD'
<mdz> fabbione: so I rename that to ship-server
<mdz> the new 'server' is things to install on servers by default (and in some cases remove from standard)
<mdz> the inspiration was getting evms and lvm out of the desktop boot process, but I've been playing around with more
<fabbione> mdz: but there is a spec in your suggested list to install on LVM by default?!?!?
<mdz> fabbione: yes, that is not happening for edgy :-)
<fabbione> *eeekkkk*Cl4sh d3t3ct10n*eeekkk*
<mdz> and it's not clear that it's a good idea
<fabbione> i still would like to have lvm on dekstop
<fabbione> it's useful
<fabbione> even on a laptop
<fabbione> and yes i am WEIRD.. ok?
<ajmitch> nah
* ajmitch has lvm on his laptop :)
<dholbach> you're weird too
<dholbach> :-p
<ajmitch> heh
<Hobbsee> dholbach: +1
<Hobbsee> you beat me to it!
<jdub> fabbione: could it go in ship-seed/live, and be available for the installer?
<fabbione> jdub: i definetely want it on cd..
<fabbione> jdub: i might agree not installed by default
<fabbione> but it needs to be there
<mdz> fabbione: this isn't about what some people might want, but about the default
<mdz> for 99% of desktop users, evms and lvm just slow down the boot process and provide no benefit
<mdz> they are only where they are because we want them on servers
<fabbione> mdz: as i said.. i might agree on not installed by default, but i want them on cd.
<fabbione> mdz: i want to be able to keep installing my desktop on LVM.. i
<mdz> fabbione: sure, we can copy them to ship
<fabbione> mdz: yeah that's whay i just said :)
<fabbione> it's ok not installed by default
<fabbione> but with the option to have it if somebody wants it
<mdz> fabbione: do we need to add something to the lvm udeb to cause it to install lvm2?
<mdz> or does it already do that?
<mornfall> fabbione: no worries, i have lvm on laptop
<fabbione> i will need to check that in the installer.. there are at least 2 packages to check
<fabbione> mdz: probably an apt-install lvm2
<fabbione> or it's equivalent
<mdz> fabbione: I bet Debian already does it because lvm2 is not installed by default
<mvo> mornfall: hm, what would be a better place for the code then?
<fabbione> mdz: probably....
<jdub> mdz: (would you include lvm/evms on the desktop/live CD?)
<mornfall> mvo: it's not quite a problem for libept, i can add the hook call there easily
<mvo> mornfall: ok
<mornfall> mvo: i will eventually want to anyway, since i have very similar method there that throws exceptions on errors
<mornfall> mvo: i'll check what aptitude does in that respect
<mdz> fabbione: diff updated
<mdz> jdub: no, I wouldn't (except perhaps if we added support for them to ubiquity)
<jdub> mdz: (oh yeah, good point)
<fabbione> mdz: yeps.. lvmcfg does it.. i will need to update partman-auto-lvm, but that's easy
<fabbione> +=== Some weirdos like to use these on desktops ===
<fabbione> ROFL
<jdub> heh
<dieman> heh
<mornfall> mvo: what i thought, aptitude has yet another version of that class embedded
<mvo> mornfall: and synaptic has a different one too :/ but I should be able to fix both, usually daniel is pretty responsive to this kind of patches for aptitude
<jdub> mdke: http://iquaid.livejournal.com/10898.html
<mdke> jdub: yeah :)
<jdub> mdke: how good is the moin markup -> docbook stuff?
<mornfall> mvo: well, no matter, at least we have the hooks called which will mean that we should be able to get rid of apt-index-watcher
<mdke> jdub: in moin 1.5, rubbish; at the moment in mikko's soc project, already very good and will get even better
<Kamion> Keybuk: casey:~cjwatson/jackass-morgue/
<mvo> mornfall: yes, thats a good thing!
<jdub> mdke: tasty. :-)
<mdke> jdub: yeah, pretty cool
<jdub> mdke: not the steps towards solving this that i would've guessed/imagined 12 months ago
<mdke> jdub: I took this off the wiki and put it through the converter: http://mdke.org/tmp/Moin2docbook.png
<jdub> heh, nice
<Kamion> mdz: any reason not to make ship just include ship-server, rather than copying bits of ship-server into ship?
<Kamion> mdz: "include" => STRUCTURE plus cdimage changes, rather than putting ubuntu-server in the ship seed
<Kamion> jdub: LVM in ubiquity> see ubiquity-advanced-partitioner
<mdz> Kamion: they already had overlap, but you're right, it makes more sense that way
<Kamion> jdub: (LVM in ubiquity isn't an essential part of that spec, but I think that spec is needed before we attempt it)
<Kamion> mdz: but otherwise, looks ok
<jsgotangco> mdke: that is NICE
<mdke> yeah
* ..[topic/#ubuntu-devel:infinity] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html | Upgrading to edgy will break your amd64 system -- honest
<mdke> just amd64?
<ajmitch> infinity: yes, it's fun breakage too
<mdke> meh
<jdub> hooray, that means it works everywhere else!
<ajmitch> mdke: /lib64 symlink
* jsgotangco ignores the warning
<tseng> mdke++
<ajmitch> (iirc)
<infinity> ajmitch: Oh, I see you already tried. :)
<ajmitch> infinity: of course
<infinity> ajmitch: Foolish man. :)
<mdke> can we have some broken i386 action too for those of us without this crazy hardware
<jdub> Kamion: btw, gtk+ 2.10 is going to have 'assistants' (wizard/druid api)
<ajmitch> infinity: I did it in vmware, no loss :)
<mdz> Kamion: hmm, it would actually make more sense to have ship-common, ship-desktop, ship-server or similar
<jsgotangco> nice!
<infinity> mdke: I'll break i386 for you tomorrow.
<mdz> Kamion: if we want to factor out the duplication
<mdke> rock
<mdke> infinity: one per day seems reasonable
<jsgotangco> amd64 is hardly anything crazy :/
<_ion> Will m68k not be broken?
* jsgotangco hugs his workstations
<pitti> doko: ping
<infinity> _ion: I try not to break m68k, because unbreaking it takes too long.
<Kamion> mdz: what would be in ship-common?
* infinity heads to bed, assuming that jbailey will have a fixed glibc for him by the time he wakes up.
<Kamion> mdz: but sure, that approach would work
<mdz> Kamion: things we want in both which are not specifically server-oriented
<mdz> Kamion: e.g., the Development section
<mdz> and "Hardware and network access"
<Kamion> mdz: mm, true
<Kamion> fine by me as long as there's still a 'ship' there at the end of it with appropriate changes to STRUCTURE
<Kamion> though cdimage might need some changes anyway
<Kamion> but who cares, I'm going to ignore cdimage for a while until the installer is brought up
<infinity> Kamion: Ignore away.  If I feel the urge to build a CD or two, it'll become my problem. :)
<pitti> is there a possibility to specify a build dependency 'use package foo if it's available, but don't fail if not'?
<Kamion> mdz: ship-server should be 'boot minimal standard' in STRUCTURE, I believe
<infinity> pitti: No, if there was, I'd be using that in PHP (to avoid forking from Debian)
<Kamion> though that's probably an existing bug
<pitti> infinity: exactly; I want to keep postgresql backportable, but build-recommend libssp0-dev
<mdz> Kamion: diff updated
<infinity> pitti: Then you lose.
<Kamion> nod
<infinity> pitti: The hackish way to do it is to build-dep on something completely unrelated to your package as an OR.
<infinity> pitti: libssp0-dev | moon-buggy
<_ion> How beautiful. :-D
<mdz> moved libxp6 back out to ship, since some folks are offended
<mdz> by X libraries on servers
<pitti> infinity: right, the first thing that came into my mind was libssp0 | gcc, but that obiously doesn't work
<infinity> pitti: The trick is that the OR dep can't be something that would be pulled in anyway by the build-deps.
<pitti> infinity: I thought about this bogus | too
<mdz> infinity: any opinions on http://people.ubuntu.com/~mdz/temp/ubuntu-server.diff ?
<pitti> but I hoped there was a better way
<pitti> infinity: thanks
<infinity> pitti: Anyhow, that would be really, really silly, so I wouldn't recommend it. :)
<_ion> + * chkrootkit
<_ion> rkhunter would be nice in addition to that.
<jsgotangco> good night
<pitti> infinity: if we go for adding this to many packages, we'll loose backportability
<Kamion> infinity: oh, bugger, xfonts-utils is split out in Debian now
<doko> pitti: pong
<Kamion> but it's in xfonts-core in Dapper
<pitti> doko: do you happen to plan to add libssp0-dev as gcc dependency?
<ivoks> pitti: it's not like eggcups has active development :)
<tseng> mdz: cricket, aide, nessus < really?
<infinity> mdz: The structure looks backwards to me...
<mdz> tseng: really what?  really continue to ship them on the server CD?
<Kamion> I love this part of the cycle; it feels like playing with two giant subtly incompatible Meccano sets and trying to build something that stays up
<tseng> mdz: ah
<tseng> mdz: sure.
<pitti> ivoks: no upstream developer is interested in printing, it seems... :(
<mdz> I removed the bits from ship-server which I added to server
<mdz> infinity: how so?
<ivoks> pitti: yup, both in gnome and kde there is no development :/
<infinity> mdz: Well, either I'm reading the diff wrong, or all the stuff in "server" is what you wanted to have in "ship-server" and vice versa...
<infinity> mdz: I'm assuming you don't want nessus and cricket in regular ship...
<mdz> infinity: 'server' is stuff installed by default on server installed, and 'ship-server' is only included on the CD
<Kamion> server looks right to me ...
<ivoks> hm... time to write something new?
<Kamion> oh, but yes, nessus/cricket shouldn't be sucked into ship
<Kamion> so we do need ship-common
<Kamion> or to just duplicate for now
<mdz> Kamion: why, space considerations?
<mdz> Kamion: I'm inclined to do this in two steps, first repurposing server and then factoring out the common bits
<Kamion> mdz: well, that and we'd never have put them in ship ordinarily
<infinity> Yeah, ship just got bloated.
<Kamion> mdz: factoring> fine by me
<infinity> That was what was confusing me about this change.
<mdz> to that end, I've reverted that bit
<mdz> so ship-server and ship remain independent
<mdz> and I'm ready to commit what's published there now unless someone screams
<infinity> mdz: Okay, so "server" is meant to be a metapackage of "installed by default" stuff?
<infinity> mdz: I'm still questioning it in that case. :)
<mdz> infinity: at least a task, and presumably a metapackage too
<mdz> infinity: what's your concern?
<infinity> mdz: I see no reason to install lilo by default.  It'll be installed if they asked for it in the installer.  No reason to install the bloat of ia32-libs unless they need it, etc...
<mdz> infinity: I'm happy to put those back in ship-server if you mind
<Kamion> ok, apparently xfonts-utils (dapper) -> xfonts-{base,75dpi,100dpi,scalable,utils} (unstable)
<Kamion> whee
<infinity> mdz: I'm not sure how happy I am to make server installs go much beyond -minimal unless the user specifically requests certain tasks/metapackages.  I want a basic server install to be as bare-bones as possible to please the hardcore admins.
<infinity> mdz: And then add the tasks (like the LAMP stuff) in to satisfy the less hardcore.
<Kamion> er s/xfonts-utils/xfonts-core/
<mdz> infinity: so you object to having a server seed at all?
<infinity> mdz: Basically, yeah.
<mdz> bah
<Kamion> YM a server metapackage?
<infinity> mdz: There's no one thing you can define as "a server".
<mdz> it's pretty much all harmless command-line stuff
<infinity> mdz: I'm more for a set of tasks for common server setups (looks at Kamion's revive-tasksel spec)
<Kamion> what's miscfiles doing in server?
<infinity> mdz: Sure, it's all harmless stuff, but I never use bc ever.  And I only use zip and unzip on my workstattion.  And and.  The more we bloat it out with what user A wants, the more we add for user B, and eventually we have a server install bigger than the desktop.
<Kamion> why do I need the US Constitution, lists of postal codes, and a list of airport codes on my server?
<mdz> infinity: what inspired this was that there are packages in standard which are only there because people might want them on servers
<mdz> Kamion: reload
<Kamion> better
<infinity> mdz: I'm happy to slim down standard, I don't think that means they should be in a server seed.  Most server folk I talk to want their server setups as small as possible.
<mdz> infinity: we're not giving them much that they weren't getting already
<Kamion> we could just move them to ship-server and forget about creating a new server seed
<infinity> Kamion: Yeah, I'd be happy about that.
<Kamion> then we would have the 'server' name free for ogra again
<infinity> mdz: True, but if we're refactoring ANYWAY, why keep the bloat?
<mdz> infinity: because I didn't consider it bloat for server installs
<mdz> a few megabytes of administration tools wouldn't hurt
<infinity> mdz: Shall we schedule an "argue about server seeds" BoF? :)
<mdz> most of them were in standard because we found ourselves installing them on servers as a matter of course
<infinity> (Actually, I need to schedule something to discuss how we're going to do more server flavours)
<mdz> infinity: sure, but first, lvm2 and evms out of desktop ;-)
<infinity> And I think this falls into the flavour umbrella, as the "vanilla" flavour.
<Kamion> I plan to write up and schedule revive-tasksel before tomorrow evening
<infinity> mdz: I'm all for lvm and evms exiting desktop.
<infinity> mdz: I don't care if you just remove them from standard and cripple -server for now.  I can recover -server later.
<hunger> mdz: Noooo ! lvm is great to have on a desktop!
<Kamion> hunger: what's stopping you installing it?
<Keybuk> hunger: you can install them if you want them
<Keybuk> most people don't
<mdz> hunger: we already discussed this, with more or less the result that Kamion and Keybuk just explained
<hunger> Keybuk: Use lvm by default:-)
<iwj> Kamion: are you insterested in my Breezy woes or shall I just use debootstrap ?
<iwj> (Or for that matter fix up sources.list and blunder on)
<fabbione> mdz: did you slam lvm2 out of ship again?
<infinity> mdz: I'd rather revisit the whole -server thing while discussing tasks and flavours, so if you want to yank stuff from desktop, just do it.  Don't worry too much about what happens to server.
<Kamion> iwj: at this point, not so massively, if Dapper works ...
<iwj> Right.
<infinity> mdz: If you want to leave a note in the form of a mess of commented out crap in the server seed, that will be a fair hint. :)
<infinity> mdz: Something like "# XXX: This is the junk I pulled out of standard, figure something out -- mdz" will be enough for me to sink my teeth into in Paris when I actually decide to care deeply about this.
<mdz> infinity: that'd cause them to fall off of the CDs, of course
<mdz> but if you're not bothered...
<infinity> mdz: I don't much care what happens to the CDs in the next 2 weeks. :)
<infinity> Kamion: Please do propose the tasksel thing, so I can make server-tasks (when I write it up) depend on it.
<infinity> I don't want ubuntu-server to grow 10 boot options for different setup types.
<Kamion> oh ye gods, debhelper vs. X is gonna be complicated
* infinity goes to bed before he has a chance to digest Kamion's last line.
<Kamion> I could just let anything that attempts to use dh_installxfonts FTBFS
<Kamion> that might even be a good thing
<infinity> Kamion: That sounds quite reasonable for the short term, until we sort the world.
<Kamion> because otherwise an xfonts-encodings <-> xfonts-utils manual bootstrap has to happen first
<Kamion> Source: xfonts-encodings
<Kamion> Build-Depends-Indep: pkg-config, xfonts-utils
<Kamion> Package: xfonts-utils
<Kamion> Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common, xfonts-encodings
<Kamion> whee
<infinity> Kamion: We can do a manual bootstrap once the toolchain stuff is finally unbuggered.
<fabbione> we should really be fixing imake before doing ANY X upload
<infinity> Kamion: If you've got it more or less figured out in your head, put it to paper and email me the details.
<mdz> and for my next controversial proposal
<mdz> I want to install build-essential and linux-headers by default
<dholbach> fabbione: you mean  bug 28707 ?
<Ubugtu> Malone bug 28707 in imake "ProjectRoot set incorrectly" [Low,Confirmed]  http://launchpad.net/bugs/28707
<Keybuk> mdz: weren't you the one who originally didn't want to?
<Kamion> fabbione: is it fixed in Debian
<Keybuk> or was it a jdubism?
<Kamion> ?
<fabbione> dholbach: yes
<infinity> mdz: I thought the lack of gcc in desktop was intentional.
<mdz> Keybuk: the latter
<Kamion> Keybuk: was jdub
<fabbione> Kamion: yes
<Kamion> I always wanted to put the compiler and headers in desktop
<Kamion> but I lost
<mdz> Kamion: I'm undecided between standard and desktop+server
<infinity> I'm in the "no compiler on desktops" camp.
<Keybuk> I'd like them to be in desktop too ... the fact Linux came with a C compiler was the reason I discovered it
<mdz> but if we don't have a server installation set, we have to do standard
<wasabi> There needs to be a setting someplace to turn off this damned screen fading.
<infinity> wasabi: gnome-power-manager
<mdz> infinity: not on desktops or servers either?
<Kamion> regardless of what I think personally about compiler-on-desktops, it comes up in nearly every damn review
<wasabi> Naw, on the log out dialog and the gksudo dialog.
<Kamion> both in the media and from friends
<mdz> we live in a world where people need it *all the time* and expect to find it
<dholbach> how much space would it take?
<infinity> mdz: It's probably my buildd background (plus having people compile exploits remotely via random holes in CGI apps on webservers), but I've long been against having compilers installed by default anywhere.
<Keybuk> Kamion: how did that sync go?
<wasabi> infinity: Even the JIT that comes with Mono? :0
<mdz> dholbach: it would cost no space on the CD, and a trivial amount in the installed system
* Keybuk hands Kamion the missing "r"
<Kamion> Keybuk: ?
<Kamion> Keybuk: oh, right
<Kamion> the r goes *there*
<infinity> mdz: It's not a sticking point for me, mind you, it just means that I'll be removing ubuntu-standard on all my machines, then.
<dholbach> It's just because I know a lot of people who would never use it, even if it was there.
<Kamion> 16:00 < Kamion> Keybuk: casey:~cjwatson/jackass-morgue/
<Keybuk> infinity: you don't have a compiler on any machine?
<wasabi> What are some examples of desktop apps that require a compiler?
<infinity> Keybuk: No, I do all my building in chroots.
<dholbach> (and my feeling is that that's the majority of Ubuntu users.)
<Keybuk> Kamion: it finished?>
<Kamion> Keybuk: yes
<Keybuk> ok, thanks
<mdz> dholbach: that's true for a lot of what we ship; we have other reasons than "most people will use it"
<Kamion> infinity: damnit. slot po4a in before debhelper in your build chain
<mdz> wasabi: I don't know of any; what do you have in mind?
<wasabi> I don't have any.
<wasabi> =)
<mdz> wasabi: then what's the rhetoric behind your question?
<infinity> Kamion: I think it's high time for you to email me this dpkg/debhelper bootstrap recipe.  I'm too tired now to remember it when I wake up.
<wasabi> Why's it under dicussion?
<infinity> wasabi: I assume the reason it's wanted is for people to compile kernel drivers.
<wasabi> Ahh. It just hit me.
<wasabi> Vmware.
<infinity> I suspect that if we're not shipping enough drivers, that's a failing on our part, but what do I know?
<wasabi> The install process requires a compiler and headers.
<\sh> wasabi:you had a document about ip tuning for ftp servers...is it still available and when where can I find it? I don't have my own bookmark library with me :(
<Kamion> infinity: it is, but it's not always one we can correct
<mdz> wasabi: no desktop app depends on hdparm, parted, man, file, at, cron...
<infinity> vmware-player is now in the archive with pre-compiled modules.  People using vmware-server or vmware-workstation should, in theory, have enough clue to install a compiler.
<wasabi> \sh: That doesn't ring a bell.
<Kamion> infinity: ok, you'll have mail in a moment
<mdz> wasabi: "a desktop app needs it" isn't how we decide what goes in the default install
<wasabi> K. Well, my argument was swung when I thought of VMware. ;0
<mdz> vmware requiring a compiler is a bug
<\sh> wasabi: oh no...I mixed your nick with maswans
<infinity> Can anyone come up with a "user needs a compiler" use case that doesn't also diredctly map to "user wants to install something blingtastic and should probably know how to install a compiler?"
<\sh> just found it...gg: maswan ftp mirror
<\sh> et voila
<\sh> http://www.acc.umu.se/~maswan/linux-netperf.txt
<infinity> ie: how many drivers are there that we don't (or can't) ship that they'd need to compile themselves?
<mdz> infinity: it happens, and it happens a lot
<infinity> mdz: Fair enough.  Then it doesn't hurt my feelings terribly to add it.  <shrug>
<Keybuk> it should probably be only desktop though
<Keybuk> not server
<infinity> I do disagree with compilers on server for the previously-stated reason.
<mdz> I'm not a fan of security-through-crippling
<ogra> infinity, spca webcams, linmodems ...
<infinity> (The "hey, let's use our unprivileged www-data access to pop some source in /tmp and compile it" rootkits which are very prevalent these days)
<mdz> things which didn't have drivers when we released
<infinity> mdz: I don't view a system without a compiler as terribly crippled.
<mdz> infinity: you can solve that more effectively with chroot, or even noexec /tmp
<infinity> mdz: servers (with the exception of mass shell servers) are becoming very specialised devices these days.
<infinity> mdz: noexec /tmp and dpkg disagree.
<mdz> I see a compiler as a system administration tool
<mdz> infinity: all the better; you wouldn't want a rootkit using dpkg to install gcc ;-)
<infinity> I see "being able to compile" as a system administration tool.  Why that should happen on your production server, I have no idea.
<infinity> We do this whole binary distribution thing for a reason, IMO. :)
<Keybuk> funnily enough I've had someone rootkit my server before (via samba) and "helpfully" upgrade it after
<Keybuk> my inclination for not installing it on ubuntu-server isn't security-minded per se
<infinity> Keybuk: Hah, I never had anyone upgrade my box for me. :)
<Keybuk> it's that most sysadmins do care about not having compilers on there
<Keybuk> and if we ship it by default on server, we'll get flak ... just like we get flak for _not_ shipping it on desktop
<Keybuk> desktop people think it's "one thing they have to install"
<Keybuk> server people would think it's "one thing they have to remove"
<mdz> stories like this are very common:
<mdz> "How do I install GCC to Ubuntu Linux. My PC does not have Internet connection and so I will be installing it from the CD. also plz let me know from where can I download GCC. I am new to Linux."
<mdz> people who are new to Linux get help from people who use compilers
<infinity> mdz: Right, but "I am new to Linux, help" so doesn't mech with our -server install.
<Kamion> infinity: noexec /tmp and debconf disagree too
<thom> Kamion: yes, that's quite unfortunate
<infinity> Kamion: Arguably, this is a bug in both dpkg and debconf, who should be doing things differently.  Why a root-running process needs to use /tmp for random shell snippets, I have no idea.
<Keybuk> Kamion: heh, forget debconf ... dpkg won't work with a noexec /tmp
<Kamion> noexec /tmp is so screamingly pointless though
<Keybuk> oh, wait, infinity said that
<mdz> infinity: you're right there.  but what does mesh with our -server install is "new to ubuntu"
<Kamion> /lib/ld.so /tmp/foo HELLO
<mdz> and people coming from other distributions expect gcc
<Keybuk> Kamion: I thought that was supposed to not work now?
<thom> Kamion: the average script kiddy does not know you can do that; it fixes an awful lot esp if you're just doing web hosting
<fabbione> mdz: that'd be ex-gentoo users...
<mdz> fabbione: and ex-RHEL users
<fabbione> mdz: we can cope with that ;)
<mdz> and ex-SuSE users
<infinity> mdz: Could we compromise by having it in a pkgsel hook, so removing it won't remove any of our precious metapackages? :)
<wasabi> Curiously... how do people feel about the convergence between Desktop and Server?  MS/Apple style.
<mdz> infinity: fixing metapackages to be less all-or-none is something we should do anyway
<wasabi> are we ever going to be in a position to offer a GUI administration interface for our servers?
<thom> Kamion: s/fixes/prevents/ rather
<mdz> wasabi: yes
<Keybuk> wasabi: what would you like to administer?
<infinity> wasabi: I'm firmly against it for "real" servers.
<wasabi> Me? I'm fine with text. I know 90% of small business out there EXPECT graphics.
<wasabi> And we'll need it if we want their business.
<infinity> wasabi: But I don't mind the idea of a small-business-server setup with a GUI frontend... If we ever had GUI admin tools that didn't suck (we don't)
<Keybuk> I still want movibuntu
<wasabi> Haha.
<Keybuk> a derivative that looks like MovieOS
<Kamion> Keybuk: hmm, yes, you're right, somebody hacked that into ld.so obviously
<wasabi> Ubuntu Media Center Edition. ;)
<HiddenWolf> Keybuk: fluendo should be presenting a new media center app at guadec, you might get it. :)
<Keybuk> Kamion: actually it's just that access() says NO! now, and ld.so bothers to check that now
<Keybuk> iirc
<eXistenZ> hello ivoks 
<eXistenZ> ivoks, how are you doing today?
<infinity> wasabi: The line I walk with -server is that every time we want to add something for new users or small-business users, the people who make or break us (old UNIX hacks, mass hosting providers, corporate network admins) scream because our server install just got more moving parts.
<Keybuk> (otherwise it's a back door for exec'ing anything that's -x :p)
* bluefoxicy hides behind HiddenWolf
<infinity> wasabi: So, we need to be able to satisfy both groups with different setups.  Which I'm fine with.  But the GUI setup really isn't worthwhile yet anyway.
<infinity> wasabi: Home users running "servers" who want to put "Linux Administrator, OMG!" on their resume complain about the lack of GUI, but they're not the people using the product in production on thousands of machines either.
<bluefoxicy> bluefox@icebox:/tmp$ /lib/ld-linux.so.2 x/cat
<bluefoxicy> x/cat: error while loading shared libraries: x/cat: failed to map segment from shared object: Operation not permitted
<wasabi> You'd be suprised. :
<infinity> wasabi: Until the GUIs improve, my target audience is people like elmo and thom.
<wasabi> Yeah.
<bluefoxicy> Keybuk: You cannot mmap() permissions not granted on the underlying object.
<Kamion> bluefoxicy: yeah, I know that *now*, it used to work that's all
<Kamion> last time I had the argument WRT debconf
<bluefoxicy> Kamion: <Kamion> Keybuk: hmm, yes, you're right, somebody hacked that into ld.so obviously
<bluefoxicy> Kamion:  it's in the kernel.  :)
<Kamion> bluefoxicy: yes, you're repeating what others have said though :)
<iwj> 1.5.dfsg+1.5.0.4-0ubuntu0.breezy0 ?
<wasabi> Well, I'd probably agree then. Default server install is minimal, user has to install what he wants. Pretty much how MS does it now too.
<bluefoxicy> Kamion:  nod.  I'll refrain from quoting posix standard then.
<Kamion> bluefoxicy: I don't care :-)
<Kamion> iwj: check existing package versions, they use 5.10 and 5.04 for better sorting
<wasabi> Eventually UIs appear to make "install what he wants" friendly.
<Kamion> since "breezy" < "hoary"
<iwj> Kamion: Ah, that would help.  Yes, I was just thinking of ahoary and that way lies madness.
<Kamion> mozilla-firefox | 1.0.8-0ubuntu4.10 | warty-security | source, amd64, i386, powerpc
<Kamion> mozilla-firefox | 1.0.8-0ubuntu5.04 | hoary-security | source, amd64, i386, ia64, powerpc
<Kamion> mozilla-firefox | 1.0.8-0ubuntu5.10 | breezy-security | all
<iwj> Urr.  That's no good because we have a 1.5.0.4-0ubuntu1 already.
<iwj> In dapper.
<iwj> Well, dapper-security as soon as it comes out.
<Kamion> 0ubuntu0.5.10
<iwj> So 1.5.0.4-0ubuntu0.5.10 I suppose.
<pitti> iwj: use 1.5.0.4-0ubuntu0.6.06 then :)
<pitti> erm, yes, 0.5.10
<iwj> These version numbers are practically cancerous.
<pitti> iwj: btw, firefox is still not in the security queue
<iwj> pitti: Oh.
<pitti> iwj: so you can as well reupload the dapper update to be -0ubuntu6.06
<Keybuk> bluefoxicy: posix doesn't say ld.so has to use mmap
<iwj> s firefox_1.5.dfsg+1.5.0.4-0ubuntu1_source.changes security.upload.ubuntu.com Thu Jun  8 12:30:34 2006
<pitti> iwj: you didn't get a rejection mail?
<bluefoxicy> Keybuk:  true.  It just says mmap() has to obey underlying object permissions.
<iwj> pitti: No.
<pitti> iwj: maybe missing orig.tar.gz?
* pitti checks
<Kamion> pitti: katie should have mailed back about that even if soyuz doesn't
<iwj> .orig.tar.gz> Duh, stupid if me.
<iwj> s/if/of
<pitti> firefox_1.5.dfsg+1.5.0.4-0ubuntu1_source.changes
<pitti> REJECT
<pitti> Rejected: firefox_1.5.dfsg+1.5.0.4-0ubuntu1.dsc refers to firefox_1.5.dfsg+1.5.0.4.orig.tar.gz, but I can't find it in the queue or in the pool.
<infinity> iwj: Ideal time to change the version number then. :)
<Kamion> that's a katie message ...
<iwj> Yes :-/.
<infinity> Kamion: Yes, security is katie..
<bluefoxicy> pitti:  some extensions don't work with ubuntu firefox 1.5.0.3 but do with normal 1.5.0.3
<Kamion> infinity: right. so why didn't it send mail to iwj?
<bluefoxicy> pitti:  does the version string or anything in Firefox change?
<infinity> Kamion: Cause elmo recently mangled jackass, and it's now confused? :)
<Kamion> joy
<infinity> Kamion: (Or, I have no idea)
* bluefoxicy noticed this a long ass time ago with only one extension but didn't care so never mentioned it
<pitti> bluefoxicy: firefox -> iwj
<bluefoxicy> iwj:  same question.
<infinity> Kamion: But that's as good an explanation as any, given the odd issues we've had with jackass in the last day.
<iwj> You know that 6.06 == 6.6 according to dpkg ?  This is fine because we actually mean what dpkg thinks we mean, but I just wanted to check that no-one thinks that  1.20 < 1.3
<Keybuk> bluefoxicy: reference?  it does not appear to
* Kamion knows that, at least
<Keybuk> bluefoxicy: posix leaves it up to the implementation to define how the mmap flags map to the underlying file permissions
<iwj> bluefoxicy: Yes, the version number is modified appropriate for the ubuntu version but doesn't contain the ubuntu revision.
<infinity> iwj: Yes, we know that, but using 6.06 and 5.10 sorts better for human parsers.
<bluefoxicy> iwj: have you noticed any extensions deciding they don't like it for some odd reason?
<infinity> iwj: Like when scanning directory listings.
<iwj> infinity: Right.
<iwj> And also we definitely never want ever to say 6.6 at anyone because then they'll propagate it and deviant people will think 6.6 > 6.10.
<iwj> bluefoxicy: No, but I don't normally really deal with extensions.
<infinity> bluefoxicy: I have several 3rd-party extensions installed in my firefox, and they all get on fine.
<Kamion> Package: udpkg
<infinity> Well, okay, s/several/three/ it looks like... SessionSaver, PageRank, and Stylish.
<Kamion> Depends: libc6 (>= 2.3.4-1), libdebian-installer4-udeb (>= 0.42)
<Kamion> woo, working udeb shlibdeps
<Keybuk> :p
<infinity> Kamion: Oh, halleluja.
<infinity> Kamion: I also heard rumblings about working bi-arch shlibs?
<Kamion> although I need new libc6 before the shlibdeps work for that too
<Kamion> infinity: so the changelog saith
<Kamion> I haven't tried
<infinity> Kamion: That would be awesome.
<Kamion> right, I think this debhelper works well enough to upload
<Kamion> infinity: also, go to bed
<bluefoxicy> infinity:  I've had about 15, there was only ever 1 that bitched, it was a minor thing I don't remember what and it honestly isn't important.  *shrug*
<infinity> Kamion: Err, yes, sorry -- stop being interesting.
<jdub> mdz: gar re: compiler discussion. :-)
<mdz> jdub: sometimes, banging rocks together is a legitimate problem-solving technique
<mdz> especially if one of them is flint
<jdub> mdz: ha ha
<jdub> ha ha ha
<jdub> for both meanings
<mdz> I mean the mineral, not the gregarious American
<highvoltage> lol
<jdub> i was mostly laughing about the latter ;)
<ogra> lol
<ogra> me too :)
<jdub> mdz: i know it sounds a bit fundamentalist, but i think the statement of not having a compiler because we don't expect to require one is 'good'
<mdz> jdub: I think that our choice should be about meeting needs and not making statements
<mdz> jdub: we could wrap gcc so that it prints a message intended to make the user feel guilty, if it would make you happy ;-)
<mdz> jdub: I absolutely think we should maintain the attitude that it shouldn't be required for normal operation, but in the situations when it is useful, goddamn is it useful
<jdub> mdz: right, but it's as much a statement and commitment to ourselves as to our users.
<dholbach> I think Jeff was more implying that it should send a message to us, if a 'normal users' had to use it :-))
<Kamion> dholbach: sometimes that message is "doesn't proprietary software suck", but there's not a lot we can do about that
<jdub> mdz: we do make them very attainable, and we could make that much easier (by having sweet meta selections in g-a-i).
<mdz> dholbach: we can make the effort to address those use cases in better ways, where possible, without sacrificing the user's capacity to solve them today, by known and well-documented methods
<Kamion> somebody who knows it better than I do should merge cdbs after debhelper lands but before attempting to sync the rest of the world.
<mdz> I don't think that denying them a compiler motivates them to learn why they don't have one, and work to make the world better
<Keybuk> dholbach: can you do that?
<dholbach> mdz: I absolutely see your point. I'm now just trying to find out, how useful it would be without all kinds of development libraries etc. and maybe I should just shut up, as I don't have a very strong opinion on it
<Keybuk> I think it's mostly your diff, no?
<mdz> I think it stops them in their tracks and frustrates them (and the linux-savvy person trying to help them)
<dholbach> Keybuk: I can try
<Kamion> if you want to test it now, build {(libsepol -> libselinux -> dpkg), po4a} -> debhelper
<Kamion> from edgy
<mdz> dholbach: the primary use case I'm interested in is building kernel modules
<dholbach> Keybuk: dunno how much other diff we have - I guess pitti's langpack magic as well
<iwj> How wrong would it be to solve my autoconf problem in this firefox backport by running `autoconf && automake' on dapper in the tree ?
<Keybuk> ah, good point, there's that too
<mdz> dholbach: my proposal is build-essential + linux-headers
<pitti> dholbach: in which package? glibc?
<dholbach> pitti: cdbs
<pitti> ah
<pitti> right, mine and xubuntu's
<dholbach> mdz: I agree, that's quite useful
<pitti> Keybuk: shall I merge cdbs?
<Kamion> dholbach: most people who distribute semi-proprietary stuff for building on random people's systems go to large amounts of effort to avoid requiring extra development libraries
<Keybuk> pitti: if you can, that'd be great
<Kamion> dholbach: simply because doing so brings their own support costs down
<pitti> Keybuk: Debian has a lot of bug fixes, I'd love to upgrade
<pitti> Keybuk: ooooooorlright
<mdz> jdub: they're attainable, but not discoverable
<mdz> jdub: and g-a-i isn't a good answer on the live CD
<Kamion> pitti: please let infinity know to add it to the end of his build-dep chain of doom after debhelper
<pitti> Keybuk: in about an hour, need to do some RL stuff
<pitti> Kamion: ok
<jdub> mdz: that's why i said it ;) why isn't g-a-i a good answer? can't handle ship?
<Kamion> although it doesn't actually build-depend or depend, it does use some features from newer debhelper
<Kamion> e.g. dh_installudev
<jdub> mdz: could be another one of those things that is installed on live but removed on desktop
<Kamion> jdub: that process unfortunately slows the installer down quite a bit so it should be reserved for quite special cases
<Kamion> and also drastically different user experience on live CD vs. installed system confuses the user
<Kamion> so ubiquity tries only to remove stuff that really does only make sense on the live CD
<mdz> jdub: Installed-Size
<jdub> mdz: :)
<mdz> the headers alone are like 25M
<mdz> it's a lot of RAM to install enough stuff to build a kernel module on the live CD
<jdub> (yeah, thus the next alternative)
<mdz> jdub: then there's no way to get it on the installed system except downloading it
* dholbach hugs pitti
<dholbach> Kamion: yeah, I can see that.
<jdub> mdz: 'cos it won't fit in ship and in live?
<Kamion> jdub: correct
<Kamion> jdub: (well, ship-live and live)
<Kamion> ship doesn't go on the live CD
<jdub> yeah
* jdub teeters on the brink ;-)
<jdub> whoa, rad smart patch from mvo
<dholbach> What is the policy on -updates and -backports uploads? do they have to have satisfyable build-depends from ${stable_release} or can the build-deps be from -updates themselves?
<_ion> jdub: What patch?
<Kamion> right, I think I have to stop relying on dep-wait and wait for buildds now
<Kamion> cdebconf's build-dep is such that it won't reliably dep-wait on libdebian-installer on Ubuntu buildds, and I don't want to make infinity's manual bootstrap chain any longer
<Kamion> dholbach: I believe -updates allows build-depends: -updates, not sure about -backports
<iwj> pitti: 3rd go at 1.5.0.4 uploading to security.upload now.
<dholbach> Kamion: cool, so ekiga 2.0.2 would actually be possible for dapper-updates
<Kamion> _ion: see edgy-changes
<_ion> kamion: Thanks.
<Kamion> dholbach: check with infinity if you want to be sure
<dholbach> Kamion: yeah. thanks
<_ion> A nice patch indeed.
<dholbach> http://ftp.gnome.org/pub/GNOME/sources/ekiga/2.0/ekiga-2.0.2.news looks really good
<jdub> oh rad
<dholbach> but for that we'd need a new opal and new pwlib in -updates, it seems
<jdub> - Does not drown children anymore
<jdub> ^ great fix!
<Kamion> mdz: oh, BTW, *-meta needs a bit of a fix before it works with new germinate, but I think instead of fixing that I'm going to work on moving the guts of the update script into germinate
<Kamion> mdz: I might see if I can make it pull from bzr itself while I'm at it
<Kamion> mdz: however, that's for tomorrow
<Kamion> night all
<mdz> sure
<mdz> night
<dholbach> night Kamion
<ogra> night Kamion 
* ajmitch decides to go & sleep for a change
<mdke> does logging out restart X? I'd like an authoritative answer for a docs question
<mdz> mdke: it depends, but typically it only resets the X server
<mdke> mdz: so changes to X configuration are not applied?
<mdz> mdke: not reliably
<mdz> mdke: there is an option in gdm for this, which I think defaults to false
<mdz> mdke: dholbach can confirm for sure
<sivang> mdz: doesn't it have something like a 'reload' target as in regular daemons ?
<mdke> mdz: that is enough for my purposes, I think. Thanks
<mdz> sivang: yes, it does
<dholbach> It might be 'AlwaysRestartServer'
<Keybuk> right, I'm gonna go put my feet up for a bit
<Keybuk> may be back later
<mdz> dholbach: that's the one I mean, yes
<stuNNed> peaceful relaxing key
<stuNNed> keybuk*
<mdz> dholbach: if it's true, the server is always restarted, if false, it is usually reset
<mdke> right, great
<mdz> if reset, changes to the configuration file will not take effect
<zul> Kamion: ping
<tseng> mdz: did you have any special thoughts on beagle?
<tseng> mdz: it made its own line item on EdgyIdeas
* ogra applauds dholbach 
<mdz> tseng: my only thought is "make it go and see what breaks"
<dholbach> ogra: hm?
<ogra> dholbach, Accepted eog 2.15.2-0ubuntu1 (source)
<dholbach> ogra: Yeah :-)
<ogra> your first edgy upload :)
<dholbach> slowly.... :-)
<dholbach> ogra: nah - did deskbar-applet yesterday :-)
<dholbach> or this morning
<ogra> heh, oh, i thought that was dapper-updates 
<dholbach> there was one to dapper-updates as well
<dholbach> YAY for two GNOME releases :-)
<ogra> :)
<dholbach> what will your first edgy upload be?
<mdz> tseng: it deserves a spec detailing what will be necessary
<mdz> tseng: especially as regards the installer
<tseng> mdz: sure.
<tseng> the only thing needed on the installer side is defaulting /home to user_xattr
<pitti> dholbach: is dholbach_iconcache in Debian already?
<ogra> HAHAHA
<ogra> cool :)
<dholbach> pitti: it's in discussion with the gtk-gnome-debian folks
<pitti> dholbach: alright
<dholbach> pitti: they will need to make changes to it, so they can take the transition a bit slower
<sivang> ah, dhlobach_iconcache, what a snippet
<jdub> http://fridge.ubuntu.com/node/412
<jdub> ^ untz untz untz
<tseng> jewel case!
<tseng> snazy
* tseng orders
<dieman> rock
<dieman> sold by amazon even
<highvoltage> whohoo!
<dieman> so my damn prime membership counts for something
<desrt> $9.99?!
<desrt> crikey.
<tseng> its a dvd
<highvoltage> jdub: does ubuntu get some of that money back, at least?
<desrt> i'm sure it doesn't cost more than $1 to press a DVD and put it in a jewel case and wrap it
<tseng> desrt: so whats your point?
<dieman> is it the same as the dvd isos?
<dieman> or does it have extra features?
<tseng> i am sure it is
<desrt> tseng; seems expensive
<highvoltage> i'd be happy to py US$10 for ubuntu cd's if it means making ubuntu more sustainable.
<HiddenWolf> me too
<jdub> highvoltage: yeah, we do
<highvoltage> (off-topic, sorry, i'll stop)
<desrt> jdub; that's nice, at least
<jdub> highvoltage: where did those ubuntu pc stickers come from?
<dieman> one ad on google offers $.80 'retail ready' dvd stuff
<highvoltage> just a sec...
<desrt> jdub; have y'all considered an optional $1-per-cd donation type thing for shipit?
<desrt> jdub; just paypal or whatever
<jdub> desrt: remember that at some stage, ship it is going to go away :)
<highvoltage> jdub: http://linux-schlepptops.de/product_info.php?cPath=22&products_id=28
<desrt> jdub; sad :(
<ogra> desrt, feel free :) http://www.ubuntu.com/donations
<dieman> so for $12.05 more you get the book instead
<pitti> thank god, Debian's cdbs dropped type-handling and ocaml
<jdub> highvoltage: thanks
<iwj> firefox_1.5.dfsg+1.5.0.4-0ubuntu6.06_source.changes ACCEPTED at last!
<Burgwork> iwj,  I feel your pain
<iwj> Burgwork: thanks :-).
<pitti> iwj: yep, in my queue now :)
<iwj> pitti: My attempt at a 1.5.0.4 backport for breezy has been building for an hour or two now.
<pitti> that's a good sign already :) mine stopped after 10 minutes
<iwj> I had to cheat and generate `configure' on dapper.
<iwj> good sign> Quite.
<tseng> does anyone know if jbailey is still planning on axeing linuxthreads from glibc
<pitti> tseng: I thought that already happened?
<iwj> With a bit of luck it will bomb out somewhere in the debian/rules install step, rather than in the middle of the compilation.
<tseng> pitti: wow, i thought we skipped it for dapper
<iwj> pitti: I'll keep you posted.
<pitti>   * Drop LinuxThreads on all arches, require 2.6 on all architectures.
<pitti> tseng: ^
<tseng> cool
<pitti> tseng: in edgy (first upload)
<Burgwork> iwj, are you not going to have to backport 1.5.04 to hoary as well?
<tseng> mm looked at the wrong one
<tseng> cheers
<crimsun> pitti: the odd thing is that if you read the line below, it's confusing
<pitti> hey crimsun 
<crimsun> 'lo pitti :)
<pitti> crimsun: btw, shall we fix this alsa-lib path in dapper-updates?
<crimsun> pitti: I want to test more rigorously before committing that fix
<crimsun> pitti: as it stands now, we have a known workaround for the one corner case
<crimsun> pitti: is that palatable by you?
<pitti> sure
<crimsun> pitti: ok
<iwj> Burgwork: Yes, probably, but I think I'll start with breezy because I know how to do that.
<iwj> I have no real idea about hoary; it was rather before my time.
<Tonio_> hi
<iwj> Right, that's it from me for today I think.
<pitti> dholbach: do you think I can send the dh_iconcache stuff to Debian's cdbs? after all, it checks for its existence before calling it
<dholbach> pitti: I'm not quite sure, if we shouldn't wait with that until it's at least available in Debian's debhelper.
<pitti> dholbach: ok
<dholbach> Thanks.
<tseng> the Debian guys arent that crazy about iconcache iirc
* dholbach hugs pitti
<dholbach> tseng: the transition is not as easy for them as it is for us
<tseng> they don't have a dholbach 
<dholbach> tseng: but the discussions I had with some of the debian gnome folks were quite good.
<dholbach> . o O { he must be making fun of me... }
<tseng> :(
* dholbach hugs tseng
<tseng> hugs.
<mdz> tseng: only /home?
<jdub> mdz: arf, now you've hit the list with it! :)
<tseng> mdz: unless otherwise prodded, beagled is autostarted per user, and indexes in the confines of /home
<mdz> jdub: it seems the only sensible thing to do
<tseng> mdz: other paths can be included or excluded
<mdz> jdub: this channel isn't exactly representative ;-)
<jdub> mdz: i've been thinking about it a bit, and i reckon i could do a rousing speech about why we shouldn't. ;-)
<tseng> mdz: it would be sensible to do everywhere imo, I have yet to find an ill effect
<mdz> jdub: please do it in the thread then :-)
<dieman> the only thing i worry about beagle is if a pile of users start indexing about the same time
<dieman> against an nfs mounted home
<jdub> tseng: there's the system daemon for indexing everything else
<dieman> does beagle throttle back pretty well if its not getting the IO it wants?
<tseng> jdub: there isnt really such a thing
<tseng> jdub: a cronjob spawns beagle-static-index to do /usr/share/app and /usr/share/doc
<dsas> does beagle switch off when I'm using my laptop battery? Or will it just keep my hard drive spinning?
<jdub> tseng: yeha
<tseng> jdub: static indexes are loaded by beagled at start
<tseng> when i say sensible to do everywhere, I was referring to mounting user_xattr
<tseng> sorry that wasnt clear, there is alot of scrollback in between
<dieman> oh creepy, they are working on shared beagle indexes with disvoery by avahi
<dieman> discovery
<tseng> that would require a rework of the webservice, first
<dholbach> that's like wiki-ing porn! lovely
<dieman> ahh, its an SoC project
<dholbach> imagine it at an ubuntu conference! woohooo!
<dieman> http://www.advogato.org/person/kwa/diary.html?start=4
<pitti> dholbach: that gives 'Open Source' a fully new meaning -- 'open a source to all s3kr3t files of my wlan mates :-D
<dholbach> yeah, that's what we all love about it
* pitti gets content with new cdbs
<LaserJock> is edgy-changes open for business?
<Burgwork> LaserJock, yes
<dholbach> LaserJock: yes
<pitti> LaserJock: yes, you have to sub yourself, though
<LaserJock> pitti: ah, I wondered why I hadn't gotten anything yet, thx
<LaserJock> pitti: are you comfortable with tex packages? I know you've uploaded a few but ar you in contact with the Debian TeX maintainers?
<pitti> LaserJock: occasionally only, to forward security patches
<pitti> LaserJock: I know LaTeX a fair bit, but actually only little about the packaging
<LaserJock> pitti: is there  somebody in core-dev that does?
<pitti> LaserJock: hm, I doubt it. Mithrandir maybe, but he might not be a guru either
<LaserJock> I'm getting some pretty stern emails from the Debian TeX maintainers, but I can't find anybody in Ubuntu that really wants to touch it much ;-)
<LaserJock> I use it but like you I know virtually nothing about packaging it
<LaserJock> I can sort of keep track with the Universe side a bit but most the real bug action is in the Main pacakges
<pitti> so, cdbs test suite passes now, a xfce, gnome, kde package and postgresql build fine without any debdiff. did I forget anything?
<dieman> LaserJock: whats the stern emails about?
<dieman> LaserJock: i actually ahve users that depend on tex a lot
<LaserJock> dieman: that Ubuntu doesn't fix things fast enough, etc.
* pitti does his first edgy upload, wohooo!
<dieman> LaserJock: are there new bugs that ubuntu is introducing?
<dieman> LaserJock: or is this just 'you dont grab our less buggy packages with new bugs often enough'?
<LaserJock> dieman: more like we didn't get bug fixes incorporated from Debian fast enough
<LaserJock> dieman: not really stuff we are introducing
<LaserJock> anyway, I was just wondering if there was a core-dev contact for TeX packages, but it seems there really isn't
<Kamion> zul: pong
<Kamion> tseng: the installer change is actually not *entirely* trivial (not like seriously non-trivial, but needs a little code I think)
<Kamion> tseng: what's the spec? I probably need to be allocated a bit of time to do it
<tseng> i went to file one called ubuntu-integration
<tseng> https://launchpad.net/distros/ubuntu/+spec/beagle-integration
<tseng> but already here
<tseng> https://wiki.ubuntu.com/BeagleIntegration
<zul> Kamion: do you want me to take a run at grub for edgy?
<tseng> I brain-dumped to the wiki
<Kamion> zul: sure, if you like
<Kamion> IIRC the Debian package now has a lot of improvements
<Kamion> zul: but hold off a day or two
<Kamion> zul: we're still putting the toolchain and the packaging toolchain together
<zul> sure ill just get a jump on it though
<Kamion> yeah
<BenC> is dapper-security open yet?
<tseng> yes
<BenC> ok, thanks
<mjg59> Given an object file, is there any reasonable way to split it back into its constituant objects?
<sivang> mdz: do you know if the launchpad bug reporting tool would also serve as what I Have proposed in https://launchpad.net/distros/ubuntu/+spec/launchpad-login-app ? If not, I'd like to resuggest it for Paris, if it's not completely inappropriate.
<sivang> mdz: (the one of the SoC, that is)
<Kamion> LaserJock: yeah, we've never really had a TeX expert in core
<dieman> im lucky when i can figure out what the problem is with tex
<LaserJock> Kamion: well, I'm going to try to at least be a bit of a go-between. If I can at least forward bugs to Debian and get their opinion maybe I can at least poke somebody in core-dev to upload for me
<LaserJock> hmm, I have a lot of "at least"s in there
<Kamion> LaserJock: sounds good
<LaserJock> somehow MOTU Science has become the TeX target ;-)
<lucas> LaserJock: I packaged libgsl-ruby (ruby bindings for gnu sci lib), it will soon be in NEW in debian
<lucas> a "bindings for GSL" action might be an idea for MOTU Science
<LaserJock> cool
<cge> Is there a way to get a specific slightly older version of linux-source-2.6.15?
<ubijtsa> mdz: if you were after debate regarding installing gcc, I am sure you will get your wish :)
<mdz> ubijtsa: I admit to stirring the pot
<ubijtsa> mdz: but it is good to do so from time to time.. 
<ubijtsa> like the libdvdcss issue
<NuxTech> cge: see http://www.kernel.org/pub/linux/kernel/v2.6/
<ubijtsa> mdz: a suggestion would be to install it in the LiveCD image, but leave it on the install media for the installer images, and including a System menu-option to pull in full development (read gcc) tool-chain from net or CD.
<ubijtsa> the LiveCD environment is less vulnerable from a intrusion perspective.. 
<Kamion> please follow up on the mailing list so that suggestions are archived
<ubijtsa> Kamion: I can summarise and post later if you like, I'd like some opinion now if no-one mind contributing
<cge> NuxTech: Err, I mean the Ubuntu-specific changes, like changes in configuration between 2.6.15-19 and 2.6.15-22.xx
<bluefoxicy> guys, what exactly does ubuntu do when packages are built?
<bluefoxicy> any special patches to i.e. gzip, or strange gcc flags?
<NuxTech> oops - kernel, panic!
<Kamion> bluefoxicy: no strange gcc flags any more (we used to use a gcc wrapper that made sure e.g. gcc optimisation options were within sane limits, but that's turned off for edgy now)
<Kamion> bluefoxicy: pkgstriptranslations is installed on the buildds to do language pack munging on packages
<Kamion> bluefoxicy: and that's about it
<Kamion> everything else is in the package's debian/rules and descendant scripts
<bluefoxicy> Kamion:  I am getting reports back that ubuntu is PARTICULARLY unhappy with the mprotect() from pax, which is generally sane to use aside from a very small set of very special cases.
<Kamion> well if that's true then you can build it yourself with the regular packaging toolchain and find out
<bluefoxicy> Kamion:  Looking at oprofile, I'm noticing a lot of strangeness, for example gzip briefly executes code from what seems to be anonymous mappings.
<bluefoxicy> hmm.  I could yes.
<bluefoxicy> Kamion:  I'm pretty sure things shouldn't be executing the stack or anonymous mappings, even python seems to be executing a fair bit that way (which indicates code generation at runtime)
<bluefoxicy> I'll look into it.
<bluefoxicy> Kamion:  You won't use -O3 or anything insane like that on Edgy will you?  -O2 should be quite fine... -O3 optimizations typically can make code faster, slower, bigger, or smaller
<Kamion> we used to force -pipe and -mtune=pentium4 -march=i486
<Kamion> but -mtune=pentium4 -march=i486 is gcc default now
<bluefoxicy> that sounds sane.
<Kamion> and who cares about -pipe
<Kamion> bluefoxicy: -O3> it's up to the packages,.
<bluefoxicy> -pipe is a non-issue.
<bluefoxicy> Kamion:  on a side note, -funit-at-a-time should be sane (read a whole source file for processing, rather than going function by function.. makes optimizations work better)
<netdur> I'm trying to master livecd... I used to /etc/skel for default settings but it doesn't work anymore with dapper... what going on?
<bluefoxicy> but don't quote me on that, I heard of breakage back when it was first introduced ... I think in gcc 3.4
<Kamion> bluefoxicy: if individual packages want to use that, that's great, but until it's the gcc default, I doubt we'll force it
<Kamion> until/unless, that i
<Kamion> is
<Kamion> I imagine it only makes a difference on a small number of packages anyway
<bluefoxicy> Kamion:  I used it with gentoo, I recall it having a non-noticible impact but making a visible difference on very close examination.  It's been a while though.
<eXistenZ> any cups developer?
<Kamion> bluefoxicy: "non-noticeable impact but ... visible difference"> be consistent man ;-)
<Kamion> if it's not noticeable, it's not worth the risk of extra build failures we would have to spend developer time cleaning up.
<Kamion> or runtime failures, even worse
<bluefoxicy> Kamion:  not noticible i.e. it's not running faster, using less memory, etc.  The system is responsive and fast as is.
<Kamion> well, not worth it then
<bluefoxicy> Kamion:  visible difference i.e. glibc is 30k smaller or such.
<bluefoxicy> Kamion:  using a profiler would be good if I was any good at it ;)
<Kamion> if users can't tell the difference, it's not worth the risk to keep profilers happy
<Kamion> not across the board, anyway. individual packages can use it after testing if they want.
<bluefoxicy> umm
<bluefoxicy> Kamion:  you're on dapper right?
<mdke> EDGY
<bluefoxicy> I thought the devs weren't going to boot edgy for 3 weeks
<LaserJock> doko: ping?
<bluefoxicy> Kamion:  one of the gentoo guys is telling me that gzip has a really easy fix and it's in gentoo; and that locale should NOT have that behavior and the fix for it comes from DEBIAN
<doko> LaserJock: pong
<LaserJock> doko: did you change anything to fix bug #45292 and #44891 ?
<Ubugtu> Malone bug 45292 in sun-java5 "sun-dlj-v1-1 license could not be presented" [Low,In progress]  http://launchpad.net/bugs/45292
<Ubugtu> Malone bug 44891 in sun-java5 "Installation Fails" [Medium,In progress]  http://launchpad.net/bugs/44891
<bluefoxicy> <solar> start with gzip <solar> when it's building enable --disable-asm <solar> or what have you. the problem there is it's hand written asm
<sivang> don't we support bluetooth with some GUI ootb ?
<bluefoxicy> easy enough.  *checks portage and files a bug*
* sivang wonders if this is a good spec idea
<doko> LaserJock: these are fixed, we are waiting for 1.5.0_07
<LaserJock> doko: how were they fixed? in the java package itself?
<LaserJock> preinst script?
<bluefoxicy> wtf.
<bluefoxicy> QUESTION:  Who is in charge of glibc so I can tag this bug appropriately ~_~
<doko> LaserJock: yes
<LaserJock> doko: could I get that preinst script from you? I'm basing a package off of your debconf scheme and I ran into the same problem
* sivang finds gnome-bluetooth un universe, and arghs at the lack of any functionality at all :-/
<Burgwork> sivang, being worked on by mjg59 for gnome SoC
<doko> LaserJock: see https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/
<sivang> Burgwork: ah, cool
<sivang> Burgwork: a new tool are help to gnome-bluetooth ?
<bddebian> Heya
<Burgwork> sivang, a new stack, afaik
<LaserJock> doko: thank you very much
<Kamion> bluefoxicy: file it on glibc in malone; don't worry about who's in charge of it
<Kamion> LaserJock: if you installed off a pre-release live CD then 'dpkg-reconfigure debconf' and switch to dialog
<Kamion> bluefoxicy: gzip> not my package, sorry, no idea; could easily be it was fixed post-dapper-UVF and we never noticed
<LaserJock> Kamion: right, but I'm trying to create a package that handles that better
<Kamion> bluefoxicy: dapper/edgy> I don't see why it matters, but I have one system on edgy to test bringing up the packaging toolchain
<Kamion> LaserJock: the required fix is to handle db_input exiting with code 30 and print a nice message when it does so
<bluefoxicy> Kamion:  I got an obscene picture by opening gnome-terminal, typing 'banner f', highlighting the output, and middle-click pasting it somewhere wider.
<Kamion> assuming you're doing db_input critical
<bluefoxicy> I just want to know if that's normal
<LaserJock> Kamion: yeah, ok thanks.
<Kamion> bluefoxicy: it's an f, sideways
<bluefoxicy> http://rafb.net/paste/results/jkda4B98.html is what I got
<bluefoxicy> but I didn't enlarge gnome-terminal before hand
<Kamion> that's an f, sideways, with broken wrapping
<bluefoxicy> ... yeah.
<Kamion> nobody sensible has any time for you on that
<bluefoxicy> Kamion:  nod.  I'm trying to figure out why ld.so is using old_mmap() right now instead of mmap()
<bluefoxicy> Kamion:  just ignore me, I'm wasting air :)
<Kamion> yes, you do appear to be. please do it on a different channel
* bddebian hugs Kamion :-)
<bddebian> fabbione: ping?
<zul> hes probably sleeping bddebian 
<bddebian> Ah
<mgalvin> hmm, i notices some security? updates (libtiff, etc...) but did not ever see any upload notification via dapper-changes, does anyone know where/if the upload emails are sent?
<mgalvin> pitti: ^^^
<Kamion> mgalvin: security updates don't go to dapper-updates, but dapper-security; there's no upload notification for them, only USNs
<mgalvin> Kamion: ok thanks
#ubuntu-devel 2006-06-09
<jdub> mgalvin: (although you can often find interesting information on release+1-changes...)
<mgalvin> jub: indeed, already subscribed there ;)
<bluefoxicy> who is in charge of libc? (or should I leave a minor almost-bug unassigned)
<Keybuk> leave it unassigned, someone will assign themselves
<bluefoxicy> alright.
<sabdfl> mdz: 84 specs so far for uds-paris
<bddebian> Nice
<bluefoxicy> "gzip is free software...you should have received a copy of the GNU General Public License along with tar..." <-- gzip-1.3.5/debian/copyright
<bluefoxicy> parsechangelog/debian: error: badly formatted trailer line, at changelog line 5
<bluefoxicy>  -- John Moser <john.r.moser@gmail.com>  Thu 08 Jun 2006 11:32:00 -0400
<bluefoxicy> what... what?
<bluefoxicy> I don't understand this !@*^ing question.
<bluefoxicy> oh ffs.. missing a comma.
<Burgundavia> infinity: thank you for stepping in on that gcc thread
<infinity> Burgundavia: I already spent last night arguing about it on IRC.  TBH, I'm mostly ambivolent to the idea of it in -desktop (though I will fight tooth and nail to keep it off servers), but I feel the need to fight "random -desktop bloat with non-obvious use cases"
<Burgundavia> infinity: indeed. My concern was that it was the same people going around and around
<infinity> Also, I just got a shot of homesick in the mailbox this morning.  Gary Burns sent me a copy of Waydowntown.
* infinity sniffs.
<infinity> Burgundavia: Are you going to be in Paris as a doc-team rep?
<Burgundavia> infinity: work conflicts, so no
<infinity> Burgundavia: Damn.  I like you, cause you speak Canadian and I actually understand you. :)
<ajmitch> infinity: just yourself there for the server team?
<infinity> Oh well.
<infinity> ajmitch: And neuralis.
<ajmitch> ah good
<Burgundavia> infinity: no worries. I will catch you in October
<ajmitch> so you can at least have some discussion 
<ajmitch> wherever the october meetup may be
<Burgundavia> lets just say I am going to be in my office for 5 more working days the rest of June
<Burgundavia> the rest I will be travelling for work
<ajmitch> lovely
<infinity> ajmitch: Yeah, I doubt we'll be shooting for anything earth shatterring on the server side.  Server stuff tends to move at a stately pace for very good reasons.
<infinity> ajmitch: I do want to examine more "server installation options for idiots" stuff like the LAMP install, which seems to have been very well recieved.
<ajmitch> yes, a few of those would go down well, and lead towards that 'small business server' goal
<infinity> Samba 4 might actually release in edgy's timeframe, and I'd like to be prepared for that.  And Apache 2.2 will be in edgy before I get to Paris.
<infinity> But other than those, I can't think of any amazingly interesting upstream stuff.
<Burgundavia> infinity: Hula! they will release any decade now
<ajmitch> having samba4 in edgy could be interesting, as it has its own ldap & kerberos setup, iirc
<ajmitch> I've been looking at fedora directory server as well
<ajmitch> might try & get that in if it can build properly
<infinity> ajmitch: Yeah, it attempts to do the whole AD thing out of the box.
<infinity> ajmitch: Which might be cool, if I have the spare cycles to make it go.
<ajmitch> sort of makes what I'm doing relatively obsolete :)
<infinity> ajmitch: Given edgy's "we don't care if it's broken" release philosophy, I may even opt for tossing a samba4 beta in, just for fun.
<ajmitch> I didn't think it was even that close to beta
<Burgundavia> ajmitch: does Sun produce PPC java?
<infinity> ajmitch: It's passably useable.
<ajmitch> Burgundavia: not that I've seen
<ajmitch> they probably do, but I haven't had a ppc box to care about it
<infinity> ajmitch: I think I'll register some spec time to discuss the current state of affairs and see where to go from there.
<Burgundavia> ajmitch: does anybody? blackdown?
<ajmitch> blackdown did, I think
<ajmitch> I haven't kept up with the state of java
<infinity> The current state of java is, as always, "poor".
<Burgundavia> I am trying to rewrite wik.ubuntu.com/Java
<infinity> If Sun comes through on their half-promise to relicense it under a free license, ports should pop up nearly instantly.
<infinity> (Or the whole thing will just get eated by the GCC stack)
<Burgundavia> wiki.ubuntu.com/Java
<ajmitch> I should track down jelmer & see what samba4 stuff he has
<infinity> s/eated/eaten/
<ajmitch> hey AndyFitz 
<AndyFitz> heya ajmitch
<Burgundavia> infinity: do you know much about PPC Java?
<Burgundavia> infinity: unping
<fabbione> morning
<ajmitch> morning fabbione 
<tritium> it's night time, silly ;)
<ajmitch> tritium: I'm sure it is, somewhere :)
<tritium> yeah, here...good night :)
<ajmitch> good night
<ajmitch> sigh
<ajmitch> why did some user decide to add https://wiki.ubuntu.com/EdgyEft/Feature_Suggestions
<fabbione> ajmitch: delete the page :)
* ajmitch wants to delete some users.. :)
<bluefoxicy> Who is not particularly busy, because the dev I was annoying the fuck out of at 1am has gone to sleep and I have not got this package working quite right yet
<bluefoxicy> dpkg-genchanges: failure: cannot read files list file: No such file or directory  <-- wtf?
<bluefoxicy> also is there a more appropriate channel than #-devel or #-motu or whatnot to discuss building packages when you have no idea wtf you're doing and need help?
<ajmitch> no, -motu is generally the one
<bluefoxicy> oh ok
* bluefoxicy wanders back over there then.
<ajmitch> hey jsgotangco 
<jsgotangco> good afternoon
<Burgundavia> ajmitch: you can redirect that edgy page to https://wiki.ubuntu.com/CommunityEdgyIdeas
<ajmitch> Burgundavia: I will
<Burgundavia> ajmitch: with extreme prejudice, if you please
<ajmitch> Burgundavia: redirected
<Burgundavia> ajmitch: sweet
<pitti> Good morning
<Burgundavia> morning pitti
<ajmitch> morning pitti, how are you?
<pitti> hey Burg
<pitti> hi ajmitch 
<pitti> ajmitch: pretty good, and you?
<ajmitch> I'm good thanks :)
* ajmitch is wishing that the clock in vmware didn't drift all over the place by a few hours
* Treenaks pets ntpd
<ajmitch> yeah
<ajmitch> if only it'd actually keep up :)
<bluefoxicy> pitti:  morning.
<bluefoxicy> pitti:  can I pm you a couple things to look at before I sleep?
<pitti> bluefoxicy: sure, I just have to urgently finish something
<sivang> morning all
<ajmitch> hi
<sivang> hey ajmitch 
<ubijtsa2> moin moin
<dholbach> good morning
<dholbach> so you reckon, I shouldn't upgrade my amd64?
<ajmitch> depends on how brave you are
* sivang prefers the chroots
<ajmitch> it only took a few seconds to resolve the issue on my system
<ajmitch> only because I had a root shell open :)
<sivang> ah, you've dist-upgrades already to edgy?
<ajmitch> sivang: there's not really many changes yet
<sivang> but Colin and Scott said that most of the toolchain is missing
<ajmitch> yes, but that means I just don't get upgrades from dapper for those packages :)
<ajmitch> they're trying to get the chroots setup correctly for building
<pitti> hi dholbach 
<ajmitch> & everything in place before the floodgates open
<dholbach> heya pitti
* pitti quickly opens a root shell to survive the current dist-upgrade :)
<dholbach> hahaha
<dholbach> curiosity ...
<jsgotangco> lol
<ajmitch> pitti: it's just because I couldn't run sudo :)
<dholbach> it's good I sometimes read the topics
<sivang> well, for as long as I know pitti, he's doing it on a chroot :)
<dholbach> I think I would have done the upgrade myself later today ;)
<ajmitch> dholbach: I upgraded before it was in the topic :)
<pitti> sivang: of course *not*
* pitti regrets not having read the topic today
<ajmitch> sivang: I did this in vmware, not my main system ;)
<ajmitch> heh
<giftnudel> oh well, you could always boot from a live cd, and hey, where is the fun if you already know what happens before you try it
<ajmitch> giftnudel: no need to do that
<giftnudel> ajmitch: well, yes, but it still is an option ;)
<sivang> pitti: ah, oops
<ajmitch> where's everyone's sense of adventure these days? ;)
* sivang thinks if to dist-upgrade his thinkepad
<pitti> ajmitch: so, what exactly broke? I can't see any difference right after dist-upgrade
<ajmitch> pitti: /lib64 symlink
<pitti> apart from having killed my locale
<ajmitch> dpkg broke unpacking base-files, since it needed to depend on a newer glibc
<ajmitch> which is probably built & in the archive now
<cvd> Morning - Chris K here using cvds machine to get some emergency help
<pitti> ajmitch: what's it supposed to be? I have /lib64 -> /lib
<fabbione> cvd: go ahead dude
<ajmitch> pitti: that's right
<ajmitch> pitti: so nothing to worry about
<pitti> ajmitch: I already dist-upgraded yesterday, btw (now again)
<pitti> ajmitch: ah, thanks
<pitti> sudo works fine
<ajmitch> you'd quickly notice if it were broken.. not being able to run any programs at all
<cvd> Logged into Ubuntu this morning and went to change the wireless network connection 
<cvd> (I was at home last night using the home network)
<cvd> When I login this morning, the wireless option in Network settings is not there
<cvd> The only unusual event last night was that I ran our of juice and th machine went into an emergency shutdown
<fabbione> cvd: what do you mean by "wireless option"?
<cvd> Network settings
<cvd> Wireless connection is what I meant
<fabbione> i guess i will never be able to see that on my workstation...
<fabbione> anybody with a laptop?
<cvd> Instead I only have the Modem connection (I recall that there should be three options there)
<giftnudel> cvd: yes, modem, ethernet, wlan
<infinity> cvd: You mean in System->Preferences->Network?
<cvd> yep
<infinity> It doesn't show your wireless adapter at all?
<glatzor> sivang: I hope that this is sufficient :) https://wiki.ubuntu.com/HomeUserBackup/UI
<cvd> System > Administration > Networking on my machine
<infinity> cvd: Err, yeah, I meant that.
<cvd> not at all
<infinity> Awesome!
<infinity> cvd: I don't suppose it magically loves you if you reboot?
<cvd> Tried that twice
<infinity> Right, then.  I blame Fabio.
<fabbione> infinity: teh what?
<infinity> fabbione: Can you walk her through debugging with ifconfig and dmesg and stuff?  I need to get back to mangling glibc and chroots.
<fabbione> infinity: her -> him ;)
<fabbione> infinity: it's chriss there.. 
<fabbione> infinity: yeah i think i can try...
<infinity> Oh, I don't pay attention much.
<cvd> One machine down  - two staff out of action :-)
<cvd> Thank Adam
<fabbione> cvd: can you please send the output of iwconfig and dmesg somehwre we can read it please?
<cvd> Of course
<cvd> how?
<fabbione> at least dhcp3 is broken on ppc/edgy
<fabbione> cvd: good question...
<cvd> Just rebooted for the third time and the Ethernet connection has re-appeared
<fabbione> cvd: collect them on a usb stick and copy them somewhere?
<fabbione> meh
<cvd> Will reboot again and see if this thing heals itself
<fabbione> ok
<cvd> Actually that was the 4th time
<fabbione> cvd: i hate to say it... your laptop sucks
<cvd> And I thought getting the same laptop at Mark would logically mean that there were fewer problems
<cvd> 5th login - back to only the Modem connection
<jsgotangco> lol
<fabbione> cvd: i need you to collect dmesg
<fabbione> cvd: do this:
<fabbione> dmesg > debug.output
<fabbione> iwconfig >>  debug.output
<fabbione> lspci >>  debug.output
<fabbione> once that's done reboot till you get network
<fabbione> and send the file somewhere i can read it
<fabbione> (and no sorry.. Mark's laptop is older than your.. produced by IBM and not some cheap Lenovo thingy)
<cvd> Thats all in the Terminal services...?
<fabbione> you need to do it in a terminal and mnually
<pitti> bah, new libc breaks locales horribly
<fabbione> pitti: they also break dhpc on ppc
<fabbione> locale was already known
<cvd> Cool will get onto it
<jdub> hrm
<jdub> how do you get n-m to ignore an interface that you want to configure auto/dhcp?
<cvd> Fabio - Do you > mean return or simply the symbol
<shawarma> jdub: Put it into interfaces..
<infinity> jdub: You don
<giftnudel> jdub: doesn't it ignore it if it it is activated in the network-config?
<giftnudel> -it
<infinity> jdub: You don't.  Our n-m implementation assumes that it can take over anything that's dhcp/auto.
<jdub> shawarma, giftnudel: no -> auto+dhcp
<infinity> jdub: The only way to make it ignore it is to remove networkmanager.
<pitti> jdub: set any option in /e/n/interfaces
<jdub> infinity: can't set hostname or something token?
<fabbione> cvd: the symbol
<jdub> pitti: aha :)
<fabbione> cvd: execute the commands exactly as i pasted them.. 
<shawarma> jdub: I see. I thought it left it alone as long as the interface was mentioned in interfaces.
<jdub> shawarma: if it's configured auto+dhcp, NM will use it
<shawarma> jdub: Yeah, that makes sense.
<cvd> Fabbione:  'dmesg'  produces lots of information 'dmesg > debug.output' does nothing
<fabbione> cvd: the latter is writing all the output into the file called debug.output
<fabbione> i need the file once you have done
<cvd> okay
<fabbione> be aware of the ">>" in the next commands
<fabbione> it's important
<cvd> Fab: when you say reboot till you get the network  - can you explain?
<pygi> sivang, poke? :)
<fabbione> cvd: reboot -> does the network work? [yes|no]  -> yes -> perfect.. no -> reboot again
<fabbione> cvd: i need to look at that file to try to understand what's going on
<cvd> When you say the file do you mean the txt that was showing in the Term Services window
<cvd> And do you want me to grab it before I reoboot
<fabbione> once the file is written on the hd, you can just get the network up and send it via email.
<fabbione> cvd: all the commands you did run before, did write all their info into a file called debug.output
<fabbione> a txt file
<fabbione> this file is on your hd
<cvd> That would be where
<fabbione> now you need to find a way to show it to me
<fabbione> the easiest is to reboot, get the network to work again and send it via email
<fabbione> are we on the same page now?
<fabbione> otherwise use whatever way to send it to me..
<fabbione> it doesn't really matter..
<cvd> On it now
<glatzor> does anybody know what the mount option "unhide" does?
<glatzor> I don't understand the manual
<sivang> pygi: pong
<cvd> fabbione:  file should be with you
<pygi> sivang, pm 
<cvd> fabbione:  Problem solved
<fabbione> cvd: i am reading the log.. 
<fabbione> one minute please
<cvd> Not required issue resolved
<cvd> But thanks for the help
<fabbione> cvd: what was the issue?=
<cvd> Not sure I want to say it in public
<fabbione> cvd: if saying it in public will require the help of a shrink, we want to know it NOW
* jsgotangco listens
<infinity> cvd: Wireless adapter was a PCMCIA card, and it wasn't plugged in?
* infinity wonders if there's an even more embarassing explanation waiting.
<fabbione> infinity: there must be. it's a t60
<fabbione> no pcmcia wireless card
<cvd> CKenyon is now going to logon as himself and explain
<infinity> You can buy a T60 without wireless, though I'm not sure why you WOULD.
<fabbione> cvd: thanks lady
<\sh> dear god, please replace RPM with something better...kthxamen
<cvd> thanks fabbione 
<siretart> \sh: but it is defacto standard sanctioned by LSB!!!
<ajmitch> siretart: which shows how relevant it is
<infinity> fabbione: The T60 though, does have a hardware "wireless disable" switch.
<infinity> fabbione: So that's an equally fun bet for "embarassing explanations".
<fabbione> infinity: yes.. that's what i am thinking too
<fabbione> but i want to hear that
<ajmitch> infinity: would it cause the interface to not show up?
<infinity> ajmitch: It's meant to do so, yes.
<jsgotangco> yes
* jsgotangco laptop has a switch that works
<infinity> ajmitch: It's meant to hotplug it right off the PCI bus.
<ajmitch> interesting, I'm sure my acer does it differently
<ajmitch> right
<Ckenyon> Morning all
<Ckenyon> So where do I begin
<ajmitch> however acers aren't known for their great hardware
<siretart> the interface itself should show up, but i've seen drivers which need to be 'ifconfig up'ed so they advertise themself as 'wireless' device
<infinity> Ckenyon: Begin with the embarassing part.
<Ckenyon> The fact that I turned off the wireless switch on the front of the machine
<infinity> I win!
<ajmitch> infinity collects the pool
<Ckenyon> Or the fact that I triggered the alarm to the building when I walk in this morning
<jsgotangco> multiplier bonus!
<Kamion> d-i in having better technology than the rest of the system shocker ;-)
<Kamion> it would have noticed ...
<Ckenyon> Or the fact that I spend 20 minutes arguing with alarm company explaining 'No I am not a burglar phoning you as part of an elaborate ploy to stop you turning up'
<dholbach> haha
<ajmitch> ah, one of those days
<dholbach> Ckenyon: the rest of the day will be better! :-)
* dholbach hugs Ckenyon
<Kamion> (if anyone wants to fix GNOME to notice kill switches, see netcfg/netcfg-common.c:check_kill_switch() for how to detect it
<Kamion> )
<Ckenyon> Or the fact that that my effort to get in an hour early has now meant that I am two hours behind
* sivang wonders who is Ckenyon 
<Kamion> basically /sys/class/net/<interface>/device/rf_kill, at least for ipw2[12] 00
<infinity> Kamion: I assume that only works for RF kill switches.
<infinity> Kamion: (Some laptops use a more drastic "bump it off the PCI bus" approach)
<Kamion> infinity: ah, fun
<Ckenyon> sivang - Funny  - that's exactly what the alarm company said
<Ckenyon> Many thanks for the help - I look forward to meeting y'all in Paris
<sivang> Ckenyon: heh, what will you be up to in Paris?
<infinity> Kamion: Care to re-remind me about that preseed upload/build sometime when the buildds aren't all angrily bootstrapping edgy?
<\sh> siretart: well, reading the doc from redhat, RPM can do some OR dependencies like | in debian/control...somehow suse doesn't support this operator in sles9 :(
<infinity> Kamion: Say, Mondayish? :)
<infinity> Kamion: (Hopefully, we'll be back in fullauto then, and there'll be no need to remind me anyway)
<Kamion> infinity: I'm on holiday all next week
<Kamion> so not really, no ;-)
<infinity> Kamion: Oh, right.  That'll make this fun...
<Kamion> on holiday and nowhere near any computers, as it happens
<infinity> Kamion: Kay, I'll just make a mental note then.  Have fun VACing.
<infinity> Kamion: Toss a few back for me.
<Kamion> thanks
<infinity> (Only a few; I'm not Irish)
<Kamion> so somebody else will have to drive debian-installer uploads to -updates and such
<infinity> Kamion: Or we can do it in Paris, since Fabio will be at home anyway, sitting next the sparc test gear. :)
<infinity> (And we'll have the soyuz guys at arm's length to smack them if it breaks)
<Mithrandir> Kamion: you need to walk me through how to release sparc, too.
<infinity> s/if/when/, I fear.
* dholbach needs to learn the xrender-cairo-ati-whateveritis bug number by heart to dups more quickly :-(
<giftnudel> I think there should be weekly quizzes about the most frequent bug numbers
<sivang> Kamion: the IBM guy I'm supposed to meet wanted to set a meeting for next week, I'll tell him to reschedule and we could talk about it some more in Paris before I actually go and test there.
<dholbach> ah it's bug 34435
<Ubugtu> Malone bug 34435 in xserver-xorg-driver-ati "Cairo and ATI RENDER extension cause scrambled buttons in UbuntuLooks" [High,Confirmed]  http://launchpad.net/bugs/34435
<Ckenyon> sivang: The Edgey meeting in Paris
<Kamion> Mithrandir: I *think* something along the lines of 'ARCHES=sparc CDIMAGE_NO_PURGE=1 for-project ubuntu publish-release daily ../ubuntu-server/daily/$DATE server yes' should do it
<sivang> Ckenyon: cool, I suppose you are in close proximity to Claire then, if you used cvd's nick :-)
<Kamion> Mithrandir: (yes, hacky)
<Mithrandir> Kamion: what does CDIMAGE_NO_PURGE do?  Not remove the other arches?
<Kamion> Mithrandir: but if I were you I'd do 'cp -a cdimage/simple simple-backup' first and check HEADER.html, .htaccess, and MD5SUMS carefully before and afterwards
<Kamion> er, not cp -a
<Kamion> cp -al
<Kamion> Mithrandir: right
<Ckenyon> Based in London on the business team
<Mithrandir> Kamion: ok, I'll do that
<Kamion> hmm, cdimage will need a little work to pull from -security/-updates for the next dapper build IIRC
<infinity> Oh, halleluja, gcc-4.1 is sinally building everywhere.
<Kamion> particularly to pull d-i from updates. eek.
* Kamion prods hopefully
* \sh reads the thread about installing a compiler by default...*shrug* 
<\sh> I wonder how "
<\sh> A common reason to install a new driver on a Linux system is to gain
<\sh>  access to the Interne
<\sh> t
<\sh> is achieved by installing a compiler, because there is no internet connection. most probaly no one is coming to me, with the source module on disk or cd for the driver anyways
<Kamion> I dunno, I don't think it's unheard of
<infinity> I have exactly one piece of hardware with a source tarball on the driver disk.
<infinity> And it's a RAID controller, so the compiler being installed probably won't help me. :)
<infinity> (Might help to have it in -live, I guess)
* fabbione hands gcc-udeb to infinity 
<siretart> fabbione: great. but please start with a libstdc++-udeb first ;)
<\sh> infinity: this would be a real use-case for a gcc on -live...many driver sources are waiting in universe anyways, so we would provide more and more unsupported systems
<fabbione> \sh: that would horribly break at the first kernel abi bump
<\sh> fabbione: or sure :)
<\sh> s/or/for/
* ..[topic/#ubuntu-devel:infinity] : 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 | http://wiki.ubuntu.com/HelpingWithBugs | HAPPY DAPPER DAY! | https://lists.ubuntu.com/archives/ubuntu-announce/2006-June/000083.html
<infinity> (Upgrading to edgy no longer requires rescuing from a boot disk.  Probably still completely broken, but not "boot disk" broken)
<ajmitch> yay
<\sh> infinity: already a working edgy debootstrap package available?
<Kamion> \sh: no
<ajmitch> I think that will be 'soon'
<Kamion> I can do that as soon as I've finished fixing cdimage to pull d-i stuff from security/updates
<infinity> \sh: No point.  deboostrap dapper, make sources.list say "edgy", and you have an edgy chroot.
<infinity> \sh: The whopping two packages that will get upgraded when you do a dist-upgrade shouldn't be too much of a problem. :)
<\sh> infinity: hehe...
<fabbione> infinity: modulo dhcp breaking down :)
<infinity> fabbione: Who has a dhcp client in a chroot? :)
<fabbione> infinity: well i did upgrade live on my PB
<\sh> oh man..someone broke our nameserver...
<fabbione> I am a man! i run edgy!
<mdke> heh
<\sh> "And in the right corner, the man who is running Edgy from start, Ladies and Gentlemen, please welcome, Fabbione, the Italian Stallion...." 
<fabbione> rofl
<\sh> hehe
<sivang> godfather
* \sh needs a cigarette
<mdke> Znarl: ping
<Kamion> Mithrandir: ok, I *think* cdimage is set up to pull everything (including the installer) from -security and -updates if necessary for dapper builds now
<Kamion> Mithrandir: there's a certain amount of untested code in there, though, so feel free to bug-fix if necessary next week ...
<Kamion> )
<Mithrandir> Kamion: yay. :-)
<Kamion> (bzr branches are good if you do)
<Mithrandir> Kamion: it's bzr now, right?
<Kamion> yeah
<Mithrandir> coolie
<Kamion> see cdimage/.bzr/branch/parent and cdimage/debian-cd/.bzr/branch/parent for URLs
<Kamion> free of local diffs now, for your comfort and convenience
<infinity> Kamion: As far as you know, once I've done the toolchain bootstrap and the dpkg/debhelper/cdbs stuff, should we be okay to set the buildds to full auto?
<Kamion> infinity: that's all I know of
<infinity> Ooo, the GCC testsuite on i386 is half done...
* infinity pushes.
<infinity> Err, argh.
<infinity> It runs the suite twice?
* infinity frowns at doko.
<infinity> Once for -march=i486 and once for -march=i686
<infinity> Feh.
<doko> infinity: yes, that works mostly now, could disable that again
<Kamion> $ ../germinate/germinate.py --bzr -m http://riva/ubuntu/ -S sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds -s ubuntu.edgy -d edgy --no-rdepends
<Kamion> sweet, works
<Kamion> <cjwatson@cairhien ~/src/ubuntu/ubuntu-meta/ubuntu-meta-0.119>$ ../../germinate/germinate/update-metapackage.py --bzr dapper
<Kamion> [...] 
<Kamion> * Checking out sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.dapper/
<Kamion> that'll do nicely
<Keybuk> \o/
<Keybuk> sftp, not http?
<Kamion> can do either
<Kamion> http requires branch rather than checkout though
<Kamion> I used sftp to guarantee avoiding the supermirror-is-slow-to-pull-to-http problem
<Kamion> (and to demonstrate that it can be direct)
<jordi> Kamion: do you think using archive-copier is a good start to modify sarge's installer to build a pool out of the contents of a dvd?
<Kamion> I don't quite get what you mean
<jordi> So we want to build a pool out of the contents of the dvd at d-i time, so that after the reboot, base-config can use a file apt repo
<Kamion> oh right, sure, archive-copier's probably a reasonable place to start for that
<jordi> I wondered if modifying archive-copier to get it integrated in d-i would be sensible
<Kamion> modifying locally, sure, but there's no point for mainline d-i now
<jordi> Kamion: ok. archive-copier only copies to apt's cache iirc?
<Kamion> apt's cache, /var/cache/archive-copier/desktop/, /var/cache/archive-copier/ship/
<jordi> nm, the dvd already has a pool structure, so the copy is pretty straight forward
<jordi> nod
<jordi> ok, thanks!
<Kamion> needs a small bit of base-config integration to move the latter two into the right places at the right times to avoid being cleaned up by base-config etc.
<jordi> should I use breezy's, or the latest version in the pool?
<Kamion> may need apt-setup integration too
<Kamion> probably use breezy's, it's basically dead in dapper
<Kamion> I plan to drop it from the archive in edgy
<jordi> aha. I probably just need to drop the whole pool in /net/archive pool. reprepro can do the rest after d-i
<Kamion> yeah, it's easy enough to tweak the postinst
<jordi> yeah, I realised breezy looked like the best option from the changelog
<jordi> ok. I'll have a look
<jordi> thanks!
<Kamion> note it kind of relies on either Task or Archive-Copier-Set headers at present, but there's no reason you couldn't change it to copy everything minus base or something like that
<Kamion> have fun :)
<jordi> why minus base?
<jordi> the goal is to build a full mirror out of the dvd
<jordi> currently we install from dvd, then build a mirror from the dvd
<jordi> ie, two reads
<Kamion> oh, you want to copy the stuff that's already installed as well?
<Kamion> ok
<jordi> yeah
<Kamion> this is an automatic mirror machine installer or something?
<pygi> hey ogra 
<jordi> no, it's our classroom server installer. After the install, there's a script that builds a mirror either from http, dvd, or whatever you tell it to use
<jordi> then the classroom workstations can get installed from that server's mirror
<jordi> or update, whatever
<Kamion> ah, right
<pitti> jordi: hey dude, how are you?
<pitti> jordi: can I talk to you for some minutes?
<jordi> pitti: sleepy!
<jordi> pitti: totally
<pitti> jordi: so, carlos and I talked about langpack updating yesterday
<pitti> jordi: do you generally agree that it's a sane thing to upload new langpacks into stables on the 1st Monday of every month?
<pitti> jordi: so that the translators have a predictable schedule
<jordi> pitti: 1st of month sounds like a very easy date to remember by everyone.
<pitti> jordi: first Monday, to ensure it's a workday
<pygi> jordi, 1st monday :P
<pitti> (usuallY)
<jordi> oh lol
<jordi> did I comment I'm sleepy :D
<jordi> Ok, 1st monday is also easy to remember :)
<pitti> jordi: also, do you think we should do the first dapper update earlier? like, mid-month
<jordi> pitti: possibly, becasuse there's probably many last minute work that didn't make it
<jordi> i suggested this in some email exchange
<jordi> if it's not too expensive, I would do it
<pitti> jordi: not at all; we have daily sources and debs anyway on people
<pitti> jordi: it's just a matter of prodding an LP guy to upload them
<jordi> nod
<jordi> Then I think it's a good idea
<pitti> jordi: OK, so let's commit to June 14
<jordi> okay
<pitti> jordi: I'll write an announcement soon
<jordi> Yeah. I'll speak to mdke about documenting this officially in help.u.c
<zul> hey
<pitti> hi zul
<zul> hey pitti how is it going?
<pitti> zul: pretty good, *-security is finally fully working now
<zul> including my gpg key?
<Kamion> Keybuk: can you sync germinate from incoming, please? (or tell me I can do it)
<Kamion> I want to get the *-meta changes through before I go off on holiday
<Kamion> germinate 0.16
<Keybuk> sure, no problem
<Keybuk> Debian's incoming?
<Kamion> yeah
<Keybuk> done
<Kamion> thanks
* Kamion replaces *-meta's ./update with a very small shell script
<Kamion> (not a trout, for a change)
<Keybuk> mmmm....trout
<sivang> heh, roasted or boiled ?
<thom> raw.
<Keybuk> baked
<Keybuk> ooh, sushi!
<thom> sushi ftw.
<_ion> Eww.
<dholbach> heno: I just read your comments to the FutureOfGst spec... the at / keyboard properties are part of control-center, not gnome-system-tools
<heno> dholbach: ah, ok. does the control-center need some love as well? ;)
<sivang> hmm, future of gst?
<ogra> Keybuk, i just saw you have a boot-message-logging spec, there was a bootlogd spec from UDU you might probably look at
<sivang> does it say something about rewiritng the backends in pyhton? :p
<ogra> s/look/want to look/
<dholbach> heno: there are lots of modules which could do with some love
<sivang> heno: is the spec regsitered in Launchpad ?
<dholbach> sivang: FutureOfGst on the wiki
<heno> how many Paris specs does it typically make sense to subscribe to? ie. how many tracks is it sensible to follow?
<Keybuk> ogra: I think that spec varies a hell of a lot depending on replacement-init
<tseng> heno: there is a new bof every 45 minutes
<ogra> Keybuk, ok i just thought they could be related 
<Keybuk> ogra: what was the UDU spec?
<ogra> it think it was just called Bootlogd
<heno> tseng: but there are parallel sessions right, and some specs have several BOFs on different days
<Kamion> was probably looking at the sysvinit bootlogd code
<tseng> heno: yes.. scheduling is tricky
<Kamion> heno: yes, the scheduler tries to get you to as many of the ones you're subscribed to as it can, and will make sure you're at anything where you're the assignee or the drafter
<heno> I'm just looking for a round number. I guess signing up for 20 is too many and 5 is too few
<Kamion> at least that's how it's worked before
<ogra> Keybuk, https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/BootLogd
<heno> Kamion: ok, I've got almost 10 of those already :)
<Kamion> I'm subscribed to about 15 for this round which my gut feel says is about reasonable
<heno> cool, thanks
<Kamion> if you have a very large number of specs that you're drafting or being assigned to, you may find it difficult to get to many others
<heno> right
<Kamion> I had IIRC 8 assigned to me or that I was drafting last time round, and some of those were pretty chunky, so I didn't get round many of the others
<Kamion> I'm proposing 6 this time which I think will give me a more reasonable load
* sivang follows the same approach, although is still short of 2-3
<heno> I've got several that were basically drafted complete weeks ago that I just want other people to look at
<Kamion> ah, those will be much quicker then since they'll probably be a single session
<heno> including two SoC ones
* sivang goes to check on mdz's page for still unspec'd ideas.
<\sh> Ubuntus developer summits are not fun..it's hard work, even for community people :)
<eXistenZ> There is some wiki that includes the tools required for packaging
<eXistenZ> Can anyone direct me to that link?
<sivang> dholbach: nice spec, I'm in for it :) (FutureOfGst)
<Keybuk> Kamion: I'll set u-m-f-b as "implemented" then, shall I? :p
<Kamion> Keybuk: I just did :)
<Keybuk> Kamion: I mean uncheck "needs further discussioN"
<Kamion> Keybuk: oh, sure
<Keybuk> the thing that stops it appearing in the schedule
<Kamion> implemented should imply that :P
<Keybuk> Kamion: I recall having a "But it's implemented! ... you still need to write the spec" conversation before
<Kamion> also perhaps "basic direction approved"
<Keybuk> talking of which, niiiice empty spec <g>
<Keybuk> heh, TICK ALL THE BOXES!
<Kamion> unless you want to do a code review before that ;)
<Kamion> I can write a spec if you REALLY want
<Kamion> it might be shorter than the code, I guess
<Keybuk> I care not
<eXistenZ> anyone? :|
<Kamion> Keybuk: oh well, wrote a quick spec anyway
<Keybuk> Kamion: are you bored? :p
<ogra> heh
<Kamion> I'm lacking in things that will take four hours and that I can then drop for a week
<infinity> eXistenZ: http://www.debian.org/doc/manuals/maint-guide/
<ogra> eXistenZ, yelp has the ubuntu packaging guide
<eXistenZ> infinity, ogra, thanks ;-)
<pitti> G0SUB: ping
<eXistenZ> infinity, How can I edit my wiki page by the way? 
<Kamion> infinity: do you want gcc-4.1 NEWed on amd64?
<infinity> Kamion: If you feel the urge, sure.
<infinity> Kamion: I'm waiting on all arches before I publish it, but if you want to do the binaries as they roll in, that's cool.
<infinity> Kamion: I'm off for some dinner and wife time before I come back and keep going with the toolchain.
<infinity> Kamion: Oh, and i386 should have just showed up.
<Kamion> yeah
<Kamion> I'm sort of guessing at components, but there you go
<Kamion> ok, amd64 and i386 accepted
<bddebian> Howdy
<Kamion> infinity: set up britney output for edgy now
<Kamion> s/set/I've set/
<bddebian> Britney? I think we need a Jessica :-)
<Kamion> http://people.ubuntu.com/~cjwatson/jessica.txt
<Kamion> way ahead of you
<bddebian> W00t, rock on Kamion :-)
<Kamion> speaking of ...
* Kamion points that and anastacia at edgy
<highvoltage> is edgy open :)
<pygi> highvoltage, which time is that :P
<ogra> highvoltage, yes, but still missing the basics ... we'll have to wait 
<highvoltage> pygi: time for a dist-upgrade :)
<pygi> highvoltage, lol :)
<highvoltage> heh (just joking)
<Kamion> infinity: gcc-4.1/powerpc accepted
<iwj> pitti: My 1.5.0.4 for breezy built, btw.
<pitti> iwj: yay
<Kamion> BenC: btw, I figure we'll hold off on NEWing linux-source-2.6.17 until the toolchain is more or less together :)
<iwj> I'm currently trying to get this breezy chroot to a state where I can test it.
<pitti> iwj: 'dchroot -c breezy -d "bash -l"' works for me (this keeps environment stuff intact), and bind-mounting /tmp to get the X socket
<Keybuk> bind-mounting /tmp ... eww :p
<Keybuk> could be worse, at least you're not bind-mounting *into* /tmp
<Keybuk> I have a little evil chuckle every time someone does that in their fstab
<pitti> Keybuk: what's wrong with that?
<Keybuk> pitti: bind-mounting part of your filesystem into /tmp ?
<Keybuk> so you have /tmp/usr or something?
<pitti>  /tmp on /home/dchroot/breezy/tmp type none (rw,bind)
<pitti> Keybuk: just /tmp itself, so that I get the X socket and stuff in my chroots
<Keybuk> that's ok
<Keybuk> just a bit eww :p
<Keybuk> it's the other way around that's funny
<pitti> Keybuk: do you have a more elegant idea?
<Keybuk> no, it's just eww :p
<pitti> I can live with that :)
<iwj> pitti: Yes, yes, but I've just discovered that it didn't have ubuntu-desktop installed ...
<iwj> And I don't bind mount /tmp, just /tmp/.X11-unix
<Keybuk> (for those playing along at home, if you do it the other way around, and bind-mounts bits of your filesystem *into* /tmp ... you'll lose half your filesystem when you reboot)
<pitti> *cough* :)
<ogra> pfft, who cares, we all have backups, dont we ? :P
* pitti pats his pibackup automatic network backup
* _ion remembers to change the backup tape almost every day. :-)
<desrt> mjg59; pingage
<desrt> mjg59; i just got an email from a chap who owns a macmini who has been reading my dapper-on-macbook page and has the same problems with resume from sleep
<desrt> mjg59; specifically, the PCI thing and the IRQ9 thing
<desrt> mjg59; so we now have another example of an ICH7 machine with the SCI_EN bug
* pitti waves to desrt
<desrt> hello pitti :)
* desrt is laying in bed this morning with a macbook and julie doiron
* desrt is quite happy
<pitti> desrt: whoever this julie is, she isn't interesting enough to let you forget your computer? :-P
<desrt> well
<Hobbsee> desrt: hope your computer doesnt overheat!
<desrt> she's only here in vorbis form
<desrt> so i doubt she minds
<pitti> heh
<desrt> Hobbsee; it's odd
<desrt> Hobbsee; either my laptop has actually been getting cooler or i'm just not noticing it as much :)
* Hobbsee doesnt trust her laptop near anything flammable.  mind you, this model is *known* for overheating :(
<Hobbsee> heeh
<desrt> all of the new apple laptops are quite well known for that
<dholbach> ogra's laptop as well, right ogra?
* Hobbsee makes a mental note not to by an apple machine
<ogra> does julie warm you enough ?
<ogra> *warm you up
<desrt> apple has a knowledge base article basically saying "stop bitching.  we know it gets hot.  that's just how it is"
<Hobbsee> hehe
<desrt> ogra; it's very warm music
<desrt> Hobbsee; i'm actually really happy with this machine
<Kamion> desrt: s/new //; AlBooks use the case as a heatsink, effectively
<desrt> Kamion; my albook didn't get this hot
<desrt> Kamion; nor did the ibook which preceeded it
* ogra wonders why they seem to think that this also works for plastic ibooks 
<Kamion> it's ok as long as you keep it reasonably well-ventilated; can be a problem if you're in a hot environment and you have it on a desk
<ogra> my ibook gets very hot if i have it on my lap
* desrt had the 1.2GHz G4
<Hobbsee> ogra: but computers arent supposed to be on laps at all, are they?  :P
<jsgotangco> ouch don't let it stay on your lap too much
<ogra> Hobbsee, well, thats how i work most of the time :)
<jsgotangco> ouch
<Hobbsee> hehe
<Hobbsee> guess there are at least a couple of advantages of being female - i dont have to worry about such things :P
<Hobbsee> mind you, laptops do seem to stay cooler when on laps...
* desrt just puts a blanket or a pillow or some such between legs and laptop
<zul> not if they dont have a fan
<Hobbsee> true
<desrt> well
<desrt> apple has fans
<Kamion> Hobbsee: I find they make my thighs painfully hot, not other parts of my anatomy; not sure being female would help there
<desrt> they just don't run them enough
<Hobbsee> most laptops have fan, i would assume
<desrt> it's to the point where they'll do this *dumb* thing where the fan spins up for 1 second every 3 seconds
<iwj> No, this is no good, yelp is broken already before I install my test.
<Hobbsee> Kamion: yeah, that is a point.
<desrt> which (a) makes it louder and (b) probably consumes more power in the longrun and (c) doesn't cool as effectively
<pitti> iwj: we probably have to rebuild yelp, epiphany, etc. against 1.5
<pitti> iwj: I hope that it'll be just that, and not actually bump upstream version of yelp&friends
<iwj> Yes, but I wanted to check.
<Hobbsee> desrt: ah, you cant set that in the bios at all?
<desrt> pitti; did you find out if you're attending guadec yet?
<iwj> But this chroot is so broken it can't run yelp.
<desrt> Hobbsee; no.  closed-source firmware >:|
<Hobbsee> ah, darn it.
<desrt> y'all must be in france right now?  (or soon?)
<pitti> desrt: in two weeks
<Kamion> one and a bit week
<pitti> desrt: and no, I won't go to guadec, there are some large family events I have to attend to
<pitti> oh, indeed
<desrt> dude
<pitti> darn, time flies like an arrow
<desrt> guadec is a large family event if i've ever heard of one
<desrt> large event for a large family :)
<pitti> iwj: interesting, yelp in my breezy chroot displays the initial page (partly) and then just crashes with a 'glibc detected *** free(): invalid pointer'
<pitti> iwj: even if I stop all running firefoxes
<desrt> isn't iwj normally called something else?
* desrt tries to remember
<pitti> desrt: not any more, since he got a sane irc client :)
<iwj> pitti: Yes, that's what it does for me.
<iwj> And as previously discussed an actual breezy install doesn't, for me.
<pitti> same here
<desrt> O_o
<iwj> Oh, you've tried to install breezy without success ?
<HobbseePitchfork> desrt: hmm?
<desrt> doning a pitchfork?
<HobbseePitchfork> desrt: yes.
<pitti> iwj: oh, I thought you mean 'it doesn't crash in a real breezy install'
<HobbseePitchfork> it makes an excellent weapon.
<desrt> running bsd?
<iwj> No, I mean, I can't install breezy.  It crashes during boot.
<iwj> Well, if your chroot is broken too then I won't bother trying to make a new one with debootstrap.
<iwj> But I'm sort of running out of ideas.
<pitti> iwj: you could put the .deb somewhere (for amd64), or the source package, and as soon as I have bandwidth again, I could test it
<iwj> Sure.
<pitti> still odd that breezy doesn't boot
<pitti> iwj: the live CD fails as well?
<pitti> this would make an excellent testbed, too
<iwj> pitti: I haven't tried the livecd yet.  I'm not sure I have a breezy livecd floating around.
<iwj> No, it seems I don't have a breezy livecd and I'm not sure I want to put downloading one into the dependency chain here.
<iwj> pitti: My stuff is rsyncing and will be available eventually.
<iwj> I think if I'm going to be involved in security support for breezy I'm going to need a working install.
<pitti> iwj: what crashes on the installer CD?
<iwj> pitti: It gets through the install, but after the reboot it flashes up the grub and then crashes.
<iwj> pitti: Do you have a copy of the 1.5.0.4 orig.tar.gz from Debian ?  If so I can supply you with just the diff as soon as my computer has constructed it.
<iwj> That might be faster than waiting for the binaries to go up and down again.
<pitti> iwj: no, unfortunately not
<iwj> Oh, OK.
<iwj> Well, there goes my uplink I suppose :-).
<pitti> iwj: as soon as it's in dapper-security and my bw is back, I'll update my mirror and will have it
<pitti> iwj: yes, if you just upload diff.gz/dsc that'll be fine for me
<iwj> Oh, OK.
<iwj> I've told it not to sign it because I don't really think it should go into the archive right now :-).
<iwj> pitti: http://www.chiark.greenend.org.uk/~ian/d/, has binaries, .diff, .dsc, and pro-forma .changes.
<iwj> I haven't tested those _at all_ so it may crash on startup etc.
<iwj> But it does build.
<pitti> iwj: thanks; however, I'm afraid that I won't be able to test them before Monday
* pitti throws another curse at his ISP
<bddebian> heh
<Hobbsee> pitti: better not curse it too much, otherwise it might up and die on you :P
<iwj> pitti: Sure.
<iwj> Also, it's too hot here and I'm thinking very slowly.
<pygi> jdub, you have sec?
<\sh> ok..driving home from karlsruhe...cu later in the evening, hoping that germany will lose the first soccer match *eg*
<bddebian> Later \sh
<mdke> Kamion: I forgot to remind you about having a look at the Livecd customisation wiki page after dapper released, so consider yourself reminded
<mdke> oh, but he's gone on holiday hasn't he
<mdke> i _suck_
<Kamion> mdke: not quite but I'm in the "argh must finish packing" mode, so now's quite a bad time :)
<mdke> Kamion: ok, fair enough. It'll be for when you come back then, unless you can recommend someone else 
<mdke> recommend stroke delegate
<Kamion> Mithrandir's a good vict^Wcandidate for live CD stuff
<mdke> thanks
<mdke> have a nice holiday!
<bddebian> heh
<pitti> Kamion: enjoy the free days, see you in Paris!
<Kamion> yup, see y'all there
<LaserJock> \o/
<bddebian> Not me :-(
<bddebian> Though you are probably happy about that ;-P
<mdke> bddebian: we will sulk together
<bddebian> mdke: You aren't going?
<Mithrandir> Kamion: enjoy your vacation.
<mdke> bddebian: nope
<bddebian> Bummer :-(
<stuNNed> hi guys hope all is well which i'm sure it is :)  good work.
<mdke> Mithrandir: if you have a few moments, would you be able to have a look at https://wiki.ubuntu.com/LiveCDCustomizationHowToDapper and see if it is accurate?
<bddebian> Heh, hello stuNNed
<bddebian> mdke: Maybe we can attempt a coup de tat while they are in Paris.. ;-P
<stuNNed> hi bd
<mdke> bddebian: good thinking
<Mithrandir> mdke: looks ok to me.
<mdke> Mithrandir: ah, good news, thanks
<Mithrandir> mdke: I obviously haven't tested it, but it looks roughly equivalent to how I build custom CDs here.
<mdke> Mithrandir: great
<phanatic> mdke, Mithrandir: there is already an automated tool available for creating customized livecds
<neutrinomass> Are there any plans for Eagle USB firmware inclusion on the CD ? It's something in the order of 1 MB ... 
<madduck> Kamion: "Bug reassigned from package `mdadm' to `mdadm'." ?
<Kamion> madduck: two reassignments at roughly the same time
<madduck> ok. i just wondered what happened. thanks.
<madduck> i think i did reassign too.
<bddebian> Heya madduck
<G0SUB> pitti: hello!
<pitti> hello G0SUB 
<madduck> bddebian: gruezi
<bddebian> Anyone know when Xorg 7.1 is supposed to hit unstable?
<Keybuk> https://launchpad.net/people/ubuntu-core-dev/+branch/ubuntu-seeds/ubuntu.edgy
<Keybuk> ^ sweet
<Keybuk> we now have revision history
<Keybuk> bddebian: try #DEBIAN-devel :p
<bddebian> haha: 654 2006-05-30 shiny firefox theme IT HURTS OUR EYES, PRECIOUS!  
<Keybuk> oh, yeah
<Keybuk> we mayyyy have to stop being rude in the commit messages now
<bddebian> Keybuk: Well where I was going with that was when it was going to hit Edgy ;-P
<sivang> hmm, what a nice spam
<Keybuk> bddebian: is it in unstable?
<sivang> my HSBC bank account has been limited
<bddebian> Keybuk: Oh and they hate me more in #d-d then you all do :)
<bddebian> Keybuk: No, not yet, hence why I was asking :-)
<Keybuk> then we don't know
<Keybuk> The X SWAT TEAM doesn't want to touch X anymore
<bddebian> Yeah, so I have heard
<zul> that didnt last too long
<jsgotangco> we do?
<mjg59> Nobody wants to touch X
<mjg59> It's even more bizarro than the kernel
<bddebian> jsgotangco: You do what?
<bddebian> mjg59: I do but I don't think I have the skills :-(
<siretart> just take debian's xorg packages and blame them if they break
<mjg59> bddebian: I suspect you do because you've never had to do so :)
* siretart runs and hides
<bddebian> siretart: Exactly :-)
<bddebian> mjg59: Nah, I'm a glutton for punishment.  Hell I have 4 Hurd boxes, how bad could X be? ;-P
<Keybuk> wow
<mjg59> How do you feel about whips and large objects being inserted into your rectum?
<Keybuk> that's almost half the total Hurd boxes in existance!
<bddebian> Keybuk: touche
<zul> mjg59: i bet he loves it
<mdke> sfllaw: will you be around in maybe 3 hours or so?
<bddebian> mjg59: Define the context :-)
<mjg59> Because, when it comes to X, the large objects have spikes on
<Keybuk> mjg59: are the objects dull?
<sfllaw> mdke: Yes.  I'll be waiting for a delivery so I'm guaranteed to be in front of the computer.
<sfllaw> As opposed to in the shower or cooking something.
<mdke> sfllaw: splendid
<sfllaw> Because that's _obviously_ when the delivery would arrive.
<sivang> sfllaw: it's always like this
<bddebian> heh
<bddebian> mjg59: Well i'd like to to SOMETHING more substantial for Edgy :-)
<bluefoxicy> THAT IS NOT FRIENDLY.
<bddebian> bluefoxicy: ?
* bluefoxicy just installed today's updates.  New firefox.  He switches to firefox because it says it needs to be restarted FIREFOX HAS ALREADY BEEN CLOSED.
<bluefoxicy> Did.. did update-manager just KILL firefox?
<dholbach> it surely did not
<bluefoxicy> then I don't know wtf happened.
<Keybuk> firefox could have just crashed :p
<bddebian> Daniel!!
<bddebian> Keybuk: Not possible :-)
<dholbach> Barry!
<bluefoxicy> Keybuk:  it does that a LOT.
<Keybuk> bddebian: clearly you are using a different Firefox to the web browser I know ;)
<bddebian> heh
<bluefoxicy> Keybuk:  ubuntu needs a modified QFA for Firefox that spits back crash data :P
<bluefoxicy> to ubuntu
<iwj> bluefoxicy: Thanks for volunteering to handle the crash reports and do binary debugging on Flash and Java :-).
<bluefoxicy> (as an optional package of course)
<bddebian> iwj: :-)
<bluefoxicy> iwj:  I've already handled flash and java
<bluefoxicy> "Sorry, these plug-ins are not supported.  Thanks."
<bluefoxicy> iwj:  I'm going to try installing session saver and setting it to recover from crashes only though.
* Yagisan marvels at how stable his firefox is with flash and java. no flash & no java on amd64 makes flash and java look look little red "x" marks. that's very stable.
<bluefoxicy> ... session manager then.
<Yagisan> night all
<bddebian> Heya pygi
<pygi> thanks bddebian 
<eXistenZ> no cups developer here?
<pitti> eXistenZ: ivoks and I are the closest approximation of a 'cups developer'
<eXistenZ> pitti, ivoks is not here
<pitti> eXistenZ: although neither of us really knows the code
<pitti> eXistenZ: printing is seriously underloved unfortunately
<eXistenZ> pitti, We started talking about the bug
<eXistenZ> pitti, https://launchpad.net/bugs/48173
<Ubugtu> Malone bug 48173 in gs-esp "Printing on remote Windows shared printer doesn't work" [Medium,Confirmed]  
* pitti hears a loud cheering from the neighbor house, I guess there was a goal :)
<Burgwork> pitti, 2-1 germany
<pitti> Burgwork: 3:1 now 
<_ion> 32 sweden
* pitti thanks doko for doing the 3rd goal :)
<pitti> ... even if it was another Klose
<bddebian> heh
<bddebian> Holy crap postfix has a lot of bugs in BTS..
<jdub> Keybuk: did the final n-m in dapper include the workaround for atheros?
<Fjodor> Did something change recently in mozilla or cups?
<stuNNed> is there flash player 6 for ppc anywheres?
<bddebian> Sorry to ask in here, but we don't support desktop on Sparc do we?  Just server installs?
<Keybuk> jdub: which workaround?
<jdub> Keybuk: not scanning when associated
<jdub> Keybuk: something like that
<Burgwork> stuNNed, gnash might work
<Keybuk> jdub: oh, I didn't know there _was_ a workaround for that?
<Keybuk> do you have a reference to the patch?
<jdub> sec
<infinity> jdub: I thought there was no work around for that with madwifi-old, only with madwifi-ng...
<stuNNed> bugger, working on it, thanks!!!!
<stuNNed> who is elohim?
<lamont> bddebian: that's because I don't close them...
<jdub> infinity, Keybuk: hrm, i think that might be the case
<bddebian> lamont: ?
<keir> why is /etc/ld.so.conf gone-- i need to use shared libs in /usr/local/lib
<lamont> postfix bugs
<bddebian> lamont: Ahh :-)
<bddebian> lamont: Are they fixed?
<Keybuk> keir: create it.
<keir> aah, ok
<keir> will it override the defaults?
<keir> so i should keep /usr/lib in there first?
<Keybuk> keir: it does not override the defaults
<keir> cool thanks
<lamont> bddebian: depends... a fair chunk of them are people asking for stupid features that upstream has said 'hell, no' to.
<bddebian> lamont: Bug #19922
<Ubugtu> Malone bug 19922 in postfix "postfix: trivial-rewrite crashes with signal 11" [Unknown,Unconfirmed]  http://launchpad.net/bugs/19922
<lamont> ISTR that's something SASL-ish
<lamont> against what release is that filed?
<bddebian> postfix 2.2.4-1
* lamont bets it's not reproducible... was that breezy?
<bddebian> It's an imported Debian bug.  BTS #322602
<bddebian> Malone is a freakin' mess :-(
<lamont> and did we ever ship 2.2.4-1?
<bddebian> lamont: TBH I don't know.  I know we have 2.2.10 now
<bddebian> I was tempted to just reject it but I hate getting yelled at :-)
<bddebian> iwj: ping?
<bddebian> lamont: Still here?
<kermitX_> 1.5.dsfg+1.5.0.4-0ubuntu6.06 is the intended 'version' of firefox 1.5.0.4? instead of -ubuntu1 ?
* lamont ponders how to sync songs to an ipod using rhythmbox
* lamont runs gtkpod instead
* sivang wonders if there's something to send screen display to an external device on laptops
<bddebian> lamont: Sorry to keep bugging you but I'm trying to clean up Malone.  Do you think I can close/reject that bug on Ubuntu?
<lamont> bddebian: well, first thing to do is see if we shipped it in breezy... if we did, then we should see if it's still present in breezy (and tag it accordingly). If we never shipped 2.2.4, then we can probably close it
* lamont gets ready to take kids to the airport
<bddebian> lamont: OK, thx
<bddebian> Hmm, breezy: 2.2.4-1ubuntu2
<sivang> so, does anybody know how good is our support for the laptop buttons / other means in desktop to ootb allow users to conect their machien with video cards that support external devices, to the external devices and easily offer the option to transfer display there?
<Burgwork> sivang, the buttons are good but the external dispay is an X issue
<sivang> Burgwork: buttons seem sto be ignored for me on the t43, have you had better expreince with it?
<mvo> iwj: still around?
<Burgwork> sivang, my button works, but breaks if there is no external display attached
<mvo> iwj: well, we may want to talk tomorrow about your apt-improvements wiki additions
<Burgwork> sivang, file a bug, at any rate
<sivang> Burgwork: I actually found a spec proposal about that
<sivang> Burgwork: should also file a bug as wll :)
<bddebian> Later folks
<tritium> see you bddebian 
<infinity> Does anyone know where the Ubuntu Community myth that "build-essential" is the right package to install to "compile stuff" came from?
<Burgwork> infinity, mostly out of our docs, tbh
<tseng> infinity: I install build-essential on a new system to "compile stuff" generally
<infinity> I'm really curious about this one, since "build-essential" is a product of Policy, and is really about building Debian *packages*, but about building "random stuff from source".
<tseng> infinity: followed by apt-get build-dep foo
<infinity> tseng: Sure, I install it too, but then again, I always need dpkg-dev around.
<LaserJock> infinity: it's convenient
<Burgwork> infinity, is there a saner package we should be talking about? build-essential has the distinct advantage of being a single package
<infinity> s/but about/not about/
<infinity> Burgwork: Well, it's still useless on its own for most things anyway, with the exception of "the kernel" and "Hello World".
<infinity> Burgwork: Just about everything else will require more development headers and such.
<infinity> (And note that neither the kernel, nor Hello World, actually require g++ or dpkg-dev, pulled in by build-essential)
<infinity> build-essential is just "the base set of packages you can expect to be installed on a buildd, so your source package doesn't need to build-depend on them"
<infinity> Nothing more.
<infinity> So, yeah.  Was always a bit curious, that's all.
<Burgwork> infinity, I just read your email. Well said
<LaserJock> infinity: do you think a meta-pack for that sort of thing would be useful, or just let people do each individual package?
<infinity> If we want or need some cool metapackages for development tasks, we should perhaps dream some up.
<infinity> Anyhow, it's not a terribly huge pet peeve or anything, just something I've always wondered.
<infinity> "I can't compile stuff" doesn't translate to "install build-essential" in my mind, since I know that 5 minutes later the user will come back with "now ./configure fails, and I don't know why"
<infinity> ie: I've solved nothing, nor have I taught a man to fish, as it were, I just gave him an apt-get run to get rid of him, and now he's back for more.
<BenC> infinity: if I upload a new dapper-security kernel with an ABI bump, do I upload lrm and linux-meta to dapper-security too?
<infinity> BenC: Yes, but don't do LRM yet, I want to request a change to LRM other than just the ABI bump.
<infinity> BenC: (a quick dependency hack to try to do some better user-handholding through ABI changes)
<BenC> infinity: ok, I just uploaded the new kernel, you want to take care of lrm this time?
<infinity> BenC: How urgent is the kernel realease?  I'm off til Tuesday (long weekend, yay!), but if it's urgent, I can discuss the change with mdz and upload it tomorrow.
<BenC> infinity: well, it has about 15 CVE's in it
<BenC> and fixes a load of important bugs
<infinity> BenC: privilege escalation, or just random DoS stuff?
<BenC> I can wait till Tue, but I'm not sure pitti can :)
<BenC> not sure
<infinity> BenC: If there's privilege esacalation fixes, I'll be sure to get LRM sorted tomorrow.
<infinity> BenC: Oh, speaking of LRM, can you publish your lrm-2.6.17 work to chinstrap for me, so I can give it a once-over on Tuesday before I let the kernel into the archive?
<BenC> infinity: yeah, sure
<BenC> infinity: there are a few info leaks in these CVE's
<BenC> mostly crash type stuff, but the info leaks are kind of scary
<infinity> BenC: Alright, I'll look into it tomorrow, then.  I trust your judgement on the scariness. :)
<tritium> Is there any chance of 2.6.17 in dapper backports?  I suspect intsall on an iMac G5 might be possible with it.
<tritium> install, even
<BenC> tritium: Install on iMac G5 might be possible with the next dapper kernel
<BenC> likely hood of 2.6.17 kernel in dapper backports all depends on someone else besides me doing it...I don't have the time to maintain it
<tritium> BenC: but will there be a new install CD?
<BenC> tritium: I'll have to find that out...not sure at this point
<tritium> okay, thanks, BenC 
<BenC> since dapper will be around for 5 years, chances are we'll see on sooner or later :)
<tritium> true :)
<BenC> infinity: FYI, after fixing a small bug in the 2.6.17 kernel headers, everything in current lrm builds without change, except I have to disable fritz pcmcia drivers
<BenC> infinity: So in reality, there is no change to the current package for me
<infinity> BenC: Ahh, then I'll just work on my sources instead.
<infinity> (ie: We're scrapping madwifi-old and moving exclusively to madwifi-ng, and some other random changes too)
<BenC> the current linux-headers-2.6.17 are probably borken (.kernelrelease file contains the wrong value)
<BenC> so you'll get a failure in building a lot
<BenC> I'll get -2.2 uploaded soon though
<infinity> Well, the current one's still sitting in NEW, so feel free to keep uploading new revisions. :)
<infinity> (Also: -2.2?... You've had an ABI bump before we even had an initial release?  Is this a new record of some sort?)
<dholbach> have a nice weekend
<sfllaw> dholbach: Have fun!
<dholbach> sfllaw: you too
<mdke> sfllaw: nughe
<mdke> interesting word. I mean, nudge
<BenC> infinity: -1.1 is in the "special queue" for when edgy opens :)
<infinity> BenC: It's just in queue/NEW.  Nothing special.
<BenC> infinity: Oh wait, there are a couple of patches for ati/nvidia-legacy builds
<infinity> BenC: If you upload -1.2 before -1.1 builds, then I don't care if it breaks ABI.
<BenC> infinity: I'm going to follow my dapper initial upload policy, since every upload has to sync with upstream git, every upload is an automatic ABI bump :)
<BenC> 9 times out of 10, that was the case anyway
<hunger> BenC: Any chance of that upload fixing suspend on thinkpad T43p's?
<BenC> hunger: dapper or edgy?
<hunger> BenC: I am on edgy now...
<BenC> hunger: 2.6.17 may well fix it
<ajmitch> aren't you the crack addict?
<ajmitch> :)
<hunger> BenC: But that is not so much different from dapper so far:-)
<BenC> then again it may well destroy your laptop completely :)
<hunger> BenC: So it is a normal kernel switch ;-)
<BenC> complete with all the normal disclaimers, yes :)
<hunger> Too bad that this was broken in dapper. I wouldn't have minded staying with a stable system for a while.
<sivang> have a nice weekend all!
<profoXP> thanks, u too :P
<sivang> laters
<BenC> infinity: are we allowed to modify the source for the fritz stuff?
<infinity> BenC: Check debian/copyright.
<infinity> BenC: Oh, looks like the non-binary bits are LGPL, so "hellz yeah".
<BenC> infinity: Good, that need patches up just a small bit (.owner isn't a valid field any more for some device structs)
<mdke> sfllaw: no?
<sbartleylinux> Can someone tell me which package is responsible for the logout screen w/ dapper?
<mdke> sbartleylinux: gnome-session
<sbartleylinux> mdke: thx.
* mdke hopes he has got it right
<sbartleylinux> mdke: trying to figure out what to look at for removal of hibernate from the logout screen for remote users like freenx or ltsp clients.  Seems it has shutdown and restart set to only display if it is a local user but hibernate comes up on remote user connections.
#ubuntu-devel 2006-06-10
<sfllaw> mdke: Hi?
<mdke> sfllaw: free for a chat?
<sfllaw> mdke: Sue.
<sfllaw> Sure.
* mdke sues
<sfllaw> Eep!
<mdke> sorry, reflex
<LaserJock> hehe
<sbartleylinux> mdke: seems that w/ dapper, the gnome-session lougout changed.  Do you know who/where I should work to see about changes to it?
<mdke> sbartleylinux: yeah, lmanul in #ubuntu-desktop
<sbartleylinux> thx.
<profoXP> going to bed, bye
<mdz> mdke: are you a US attorney or something? :-P
<mdke> mdz: the next worst type of attorney
<mdz> mdke: canadian?
<mdke> heh
<Burgwork> mdke, worse, he is a bloody limey :)
<Burgwork> mdz, ^
<infinity> Gar, why do I always forget to set my From when replying to ubuntu-users?
<infinity> Does a moderator there feel like whitelisting adconrad@0c3.net, so I don't have to care anymore? :)
<mdke> infinity: you could just subscribe?
<infinity> mdke: I am subscribed, from adconrad@ubuntu.com.
<mdke> subscribe from the other one too?
<infinity> mdke: Hence the "why do I always forget to set my From when replying to ubuntu-users"...
<infinity> Subscribing from two addresses doesn't seem sane. :)
<mdke> yeah, happens to me, I subscribed them both
<mdke> well, it doesn't now that I use gmane, but it used to
<infinity> I think I need to write something for thunderbird that allows me to set per-folder From preferences.
<infinity> That would solve my headaches.
<mdke> I just moved to thunderbird myself.. it's nice. But it's weird that when you reply to mail, it doesn't maintain the From: address that received the email
<infinity> It keys off the To: address.
<infinity> So, if the mail is sent DIRECTLY to you, it picks the right address when replying.
<infinity> In all other cases, it doesn't.
<mdke> doesn't work for me
<infinity> I suppose maybe fixing that to try to guess the envelope-recipient would help, but that's not always visible.
<infinity> mdke: Whacky, it works for me.
<mdke> I get mail to my @ubuntu address, when I reply it uses the address that that redirects to
<Burgwork> infinity, ubuntu-users? I will do it
<infinity> mdke: If you send me a mail to adconrad@debian.org, that's where my reply will come from, etc.
<mdke> infinity: I'd like that behaviour. Maybe it's in a preference somewhere
<infinity> Burgwork: Someone already moderated my posts through... Either that, or I was already whitelisted the last time I screwed up.
<Burgwork> infinity, I autowhitelist everybody who is a legit poster and gets caught by the spam filter, so likely it has already been done (only a moderator, not an owner, or I would check)
<infinity> mdke: You have all your "identities" registered in Tbird, right?
<infinity> mdke: It will only pick them if they're known-valid (ie: registered in the identities widget)
<mdke> infinity: identities?
<mdke> oh i see
<infinity> mdke: Edit -> Account Settings -> Manage Identities (button on the bottom right of the window)
<mdke> doh
<infinity> mdke: With that populated, you get a drop-down box in the From line on all compose windows (and it will try to auto-guess the correct address to use on replies)
<mdke> yep, that's the problem
<mdke> thanks dude
<infinity> Alright, bootstrap back on course.  Feh.
<infinity> The next time the publisher crashes and I try to resurrect bits of the archive by hand, I may consider a career change.
<infinity> I think "drooling idiot" would be a lovely job description, for instance.
<infinity> I wonder who would pay me to do that.
<mdke> no comment
<infinity> mdke: If your comment was going to be something like "Doesn't Canonical already pay you to be a drooling idiot?", may I remind you that helping you with your software problem should have bought me at least an hour without antagonism? :)
<mdke> infinity: sorry, I'll give you an extra hour next time
* mdke hugs infinity 
<infinity> That's more like it.  Let the dholbach flow within you.
<crimsun_> on no sleep, nonetheless. A true trooper.
<infinity> "sleep"?
<crimsun_> yeah, that mystical thing...
<desrt> mjg59; ping
<mdz> infinity: what's breaking the publisher?
<infinity> mdz: A new code update crashed the publisher in some crazy fashion.
<infinity> mdz: That got fixed, but the crash happened at an inconvenient enough time that the DB and archive became hideously inconsistent and required all sorts of sketchy manual fixing.
<infinity> mdz: It's all better now.
<mdz> infinity: sorry I asked
* mdz plugs his ears and whistles loudly
<infinity> :)
<infinity> Also, SKETCHY.
<desrt> dollhouse.
<infinity> Did I mention that it was SKETCHY!
* desrt plays harmonica
<LaserJock> mdz: you probably want to close your eyes, unless you have a screen reader
<infinity> mdz: The last few hundred lines of ##soyuz1.0 (which you still appear to be on) would be either illuminating or very frightening, depending on your mood.
<infinity> mdz: If it would be the latter, I recommend killing that window and deleting any on-disk logs you may have.
<poningru> I had a question regarding the concern regarding eol of 1.0.x branch of firefox
<poningru> I havent looked at the different stuff but we are only concerend with backporting the 1.5.0.3-> 1.5.0.4 security fixes right? or is it all the patches?
<poningru> because there are some 'stability' patches in there
<bddebian> Heya
<infinity> poningru: Just the security fixes.
<infinity> poningru: Grabbing those from the references bug reports is generally reasonably trivial.  Backporting them to shoehorn them into the aviary-1.0 branch is much less trivial.
<mdke> wasn't there an option of releasing 1.5 with breezy?
<poningru> infinity: hmm true
<poningru> the latter I wasnt thinking about
<infinity> poningru: I spent a month(!) backporting patches to firefox 0.9 before we finally decided to just upgrade hoary to 1.0.x because it was too much of a pain.
<poningru> ouch
<infinity> poningru: And the structural and API changes between 0.9 and 1.0 were much less than between 1.0 and 1.5
<poningru> yeah, that was a pretty big update
<infinity> poningru: I pride myself on being able to backport just about anything anywhere (I maintained php3 for several years after upstream EOL'd it, backporting security fixes from php4 and php5), but the mozilla codebase is just pure evil, and the security fixes are always hideously intrusive.
<poningru> hehe too true
<poningru> regarding the moz stuff being evil
<poningru> problems of going from proprietry to open code
<poningru> well proprietry code has to be crappy, if you open up that stuff, its bound to be embarresing(sp?)
<neuralis> poningru: it's *FAR* less clear-cut than you're making it out to be.
<poningru> ...
* poningru doesnt wanna argue about something as stupid as that
<neuralis> poningru: i wasn't arguing.
<poningru> k
<infinity> Netscape's code was definitely scary.  I've seen some proprietary projects open up that were really quite clean and a joy to work with.
<ajmitch> and then there's OO.o
<infinity> Quake comes to mind. :)
<bddebian> Heya ajmitch
<infinity> (Yes, the fact that I understand the Quake source and can't wrap my head around Mozilla is saying somthing)
<ajmitch> hello bddebian 
<infinity> poningru: By the time I was done my backport-fest, I had 2MB of patches (seriously), with one bug left to hunt down (something about breaking right-click, IIRC)... I could have fixed that bug, but as I was hunting it, upstream released another dozen security fixes, and we decided that enough was enough.
<neuralis> infinity: ... and if you say you play doom2, you're *so* on in a week.
<infinity> I didn't want to be employed full-time to backport security fixes to Mozilla products, and my employer didn't want that either. :)
<infinity> neuralis: doom2, or doom3?
<neuralis> 2.
<infinity> neuralis: I don't play anything particularly ancient anymore, except the odd nostalgic romp in Quake1/QuakeWorld.
<infinity> neuralis: Otherwise, I'd rather have a rousing game of Q3, or D3/Q4.
<neuralis> infinity: me neither, but doom2 -- doom2 is like a fine red wine. only gets better with age.
<infinity> (QuakeWorld is still where it's at, though)
<poningru> so would it be better to wait till 1.5.0.5 to continue discussion about this?
<infinity> No, the discussion pretty much needs to happen now.
<infinity> We need a clear path for hoary/breezy, as well as a formal policy for WTF we're going to do in dapper when 1.5 ie EOL.
<poningru> hehe yeah
<poningru> that is gonna be the bitch
<infinity> s/ie/is/
<neuralis> infinity: quite frankly, given the complexity of the code involved, my personal take is that any backporting efforts are an enormous waste of time, even if they're a better solution in theory than introducing a new version.
<infinity> neuralis: See, and normally I disagree, except for the previously-mentioned wasted month of my life.
<poningru> yeah go with what mdke said, force 1.5 update
<neuralis> infinity: normally i don't think so either, hence the "given ..." disclaimer. on the other hand, i know (largish) deployments that have custom extensions for firefox installed that aren't compatible with 1.5. 
<neuralis> infinity: since these don't do centralized upgrades of any kind, i'm foreseeing a lot of cursing and swearing when users see that shiny new update in update-manager..
<infinity> Yeah, it's touchy.
<ajmitch> upgrading the myriad other applications that use firefox is doable, though messy
<infinity> But for large Win32 deployments, they'd just be rolling out the upstream builds at they come along, so most mixed environments should already know how to deal with this from their Win32 experience.
<poningru> 1.5.0.5 comes out on the 15 btw
<mgalvin> Riddell: any thing you would like to add to Issue2 if you have time?
<Hobbsee> mgalvin: this is for the newsletter?
<mgalvin> Hobbsee: yup
<Hobbsee> mgalvin: only that kde is better than gnome, of couse :P
<Hobbsee> *course
<mgalvin> :P
<Hobbsee> hehe
<Hobbsee> what else *would* you put in a newsletter, really... :P
<ajmitch> the truth?
<Hobbsee> heh
<Hobbsee> good morning ajmitch 
<ajmitch> hi
<Burgundavia> sivang: I imagine you are not awake, but ping
<Hobbsee> mgalvin: FYI - it's 3am there
<mgalvin> thanks, i just figured i would ping him and he will get back to me whenever
<desrt> Hobbsee; follower of mammon.
<Hobbsee> desrt: huh?
<Hobbsee> mgalvin: true.  i find that sometimes works.
<desrt> Hobbsee; random accusation
<Hobbsee> oh
<desrt> Hobbsee; mostly due to the pitchfork brandishing and the proclamations that kde is better than gnome
<Hobbsee> haha
<Hobbsee> pitchforks are useful
<Hobbsee> ! dont knock them!
<desrt> well, ya
<desrt> but those two things together?
* Hobbsee bans the enter key from existance
<desrt> you're clearly a satan worshiper
<jsgotangco> begone!
<Hobbsee> er...
<Burgundavia> dholbach!
* Burgundavia grumbles about intentionally breaking links to wiki pages
<darius_> Is there a "local" mirror server for Ubuntu where organizations can cache Ubuntu updates, etc locally and install on several systems from the local cache?
<darius_> w
<crimsun_> darius_: you can create your own mirror with rsync
<crimsun_> darius_: (http://www.ubuntu.com/download/mirror)
<darius_> but I assume that the Repositories list has to be changed on each workstation
<darius_> ?
<crimsun_> darius_: yes
<sladen> darius_: see apt-cache
<sladen> darius_: or a Squid proxy will do a similar job for you
<makko> why wasn't the above-mentioned fix implemented in dapper? url: http://www.ubuntuforums.org/printthread.php?t=32063&pp=40
<makko> s/above/below/
<siretart> makko: because it wasn't properly in launchpad? (just a gues)
<siretart> guess
<jsgotangco> fixes from forums cannot be implemented if not submitted as a patch
<fabbione> and bugs in lp
<fabbione> clearly people still do NOT understand that there is ONLY ONE bug tracking system
<fabbione> and forums is not it
<jsgotangco> and we've always said it in every milestone release :/
<makko> anyway, i wonder how come nobody *else* ever thought of this issue
<fabbione> because nobody reported it as such
<makko> btw, can it be submitted as a dapper update?
<fabbione> makko: file a bug with a patch and the people that cares of audio will look at it
<makko> fabbione: in malone?
<fabbione> yes
<makko> fabbione: how do i find out that it's not already submitted?
<fabbione> makko: search/look/read
<siretart> makko: there is a form 'search for existing bugs'
<makko> siretart: yes, i found it, thanks
<makko> and am i supposed to file send that bug report/fix again for edgy?
<sladen> wonder if we could get the forum guys to add a big "Please file bugs and solutions in the Launchpad bugtracker after you have found them2
<makko> s/file//
<makko> sladen: i think that's a good idea
<sladen> makko: add a comment to the bug saying that you're experiencing it and that it also exists in edgy
<sladen> and that here's the reference ... and this is the patch that will fix it
<makko> sladen: no, i mean, what if that is some setup which should be default in all future releases of ubuntu: how do i make sure it will become standard and i won't meet that issue again?
<makko> sladen: i hate to do things twice, you know
<jsgotangco> if it gets fixed for the next release, then it doesn't work again in the future, it's considered a regression and people *will* notice it
<martyvis> we are starting to get quite a few updates now in dapper-updates and dapper-security. I am doing a installfest next week. is there an easy way to create a "updates cd" which I can use in the machines on top of the desktop cd to allow me to make sure the new newbies walk away with a freshly updated machine? 
<sladen> makko: you make sure that things become standard by filing bugs or specifications
<pygi> martyvis, for now, not really
<sladen> martyvis: grab the dapper-updates Packages file and copy those .debs onto a CD
<jsgotangco> yeah
<makko> sladen: oh, i think i will file it as a specification then
<jsgotangco> then add them to your sources.list
<martyvis> OK, i figured that
<sladen> makko: woo!  yes please
<martyvis> is the plan then for say a dapper respin in 6 months (rather than installing edgy)?
<sladen> martyvis: don't know.  It's an LTS release, so that may well happen
<martyvis> sladen: i saw a post (for debian) about a update-cd script - anyidea if this would work with Ubuntu?
<jdub> martyvis: one sec
<martyvis> i think it might be a bit scary for my new users to let them go home knowing that there is maybe 20MB of updates already to download (firefox just got an update)
<martyvis> a lot will be on dialup
<jsgotangco> well
<jsgotangco> putting them on cd will work for them for sure
<sladen> martyvis: yes, it probably would
<sladen> we should make this really easy.  The infrastructure for recognising an Ubuntu upgrade disk in the machine is already there
<jsgotangco> that's true
<martyvis> I'll do a bit of research - maybe a wiki entry might come out of it
<jdub> martyvis: http://people.ubuntu.com/~jdub/2006/ubuntu-updates/
<jdub> it's very rough, but it'll do what you want
<jdub> you need debmirror installed
<jsgotangco> that's nice
<jdub> (it doesn't do *anything* pretty, but i should perk it up a bit and suggest we do something like it officially)
<jsgotangco> jdub sp1 disc
<jsgotangco> heh
<jdub> heh
<martyvis> jdub: thanks jeff, debmirror looks like the clue stick i needed. already was thinking of a neato script using Packages.gz
<jdub> wow, > 100MB updates now
<Fujitsu> !?
<lifeless> heh, 'released' == 'do more later'
<Fujitsu> Iiinteresting.
<jdub> martyvis: that script gives you a good guide for creating a simple mirror, plus will generate the CD image
<Fujitsu> I haven't got that many... But I haven't mirrored in about 3 days.
<jdub> a bunch of security updates went out over the last few days
<jdub> courier, dovecot, postgresql, not small things
<jdub> well
<jsgotangco> and of course, firefox
<jdub> not tiny anyway
<martyvis> jdub: thanks - i actually use apt-proxy at home (which is a bit buggy as it only allows half of my machines to connect - some bug in twisted that wants to check up ports from clients in /etc/services )
<imbrandon64> apt-mirror works well too
<jdub> i reckon we could do a slipstream CD too, at least for the alternate CD
<Fujitsu> It'd be a good idea.
<martyvis> jdub: slipstreaming would even be better - is there a standard debian way of doing that - or does need writing as well
<jdub> there's not a slap-your-head easy way
<jdub> well, there is for a local mirror
<jdub> but not for a CD
<jdub> oh man
<martyvis> i'm a great fan of jidgo - i was jigdoing the daily release every week or so using my previous download, and my ISP unmetered mirror. i only then had a few packages to grab from the official archive
<jdub> firefox-dbg is wonderful proof that we need debuginfo repos
<makko> sladen: i posted the specification, but nobody is evaluating it
<sladen> makko: when did you post it?
<hunger> My locales are all screwed up in edgy. Is that a known problem?
<pygi> hunger, in edgy? :)
<pygi> nice :P
<makko> sladen: just now
<sladen> hunger: please file a bug report if it is not doing what you're expecting
<makko> sladen: i mean, after we discussed
<sladen> makko: well, it might take, y'know, longer than 60 seconds to review it
<jsgotangco> lol
<sladen> makko: what's the URL?
<hunger> sladen: I will. I was just wondering whether that was already known.
<sladen> hunger: I am not aware of it yet.  If you file a bug, the releveant people will be alerted if they are not already
<martyvis> jdub: debmirror'ing ubuntu ubdate cd as we speak :-) - will test update process on a fresh dapper VM tonight
<sladen> "Service Pack" CDs, published once per month, with all the packages that have been upated since the dapper CD release
<makko> sladen: https://launchpad.net/distros/ubuntu/+spec/software-sound-mixing
<sladen> makko: can you  s/like, say,/such as/
<makko> sladen: yes, but can i still do it?
<jdub> makko: hopefully we'll ditch dmix for polypaudio :-)
<makko> jdub: why, are there any such plans??
<jdub> not as yet
<sladen> makko: I think we have dmix on by default already
<makko> sladen: i did that substitution. anyway, what is wrong with ", say, ", is it too slang?
<sladen> makko: how much of that suggestion still applies?
<makko> sladen: dapper doesn't seem to support multiple apps playing at the same time
<kmon> jdub: and what will use kubuntu? polipaudio is gnimish right?
<sladen> makko: yes, that's what I thought.  You need to pursuade lots of people, most of whom don't speak English as a first language.
<kmon> gnomish
<makko> sladen: for instance, when i use amarok, i can't use sound in vmware
<jdub> kmon: no, it is not
<kmon> jdub: thanks
<sladen> makko: because there isn't a multi-open /dev/dsp  I would guess that esd is grabbing /dev/dsp and not allowing any other (single, one of) application to use it
<sladen> makko: so the spec is basically  (a) make esd use ALSA
<makko> sladen: yes, i guess that is a better option
<makko> sladen: don't you agree?
* hunger hopes esd will be a thing of the past with edgy...
<jdub> we already ship libesd-alsa0 by default
<sladen> actually it's not even that.  it's "make GNOME use ALSA rather than esd"
<makko> sladen: at least as long as we don't implement a better solution
<makko> sladen: gnome only?
<jdub> sladen: gnome uses esd directly
<jdub> sladen: esd -> alsa
<sladen> makko: and also  "make esd terminate when not in use so that other applications can use /dev/sdp"
<jdub> we already do that
<TheMuso> /dev/dsp and sound services = PITA
<jdub> see /etc/esound/esd.conf
<TheMuso> servers even
<TheMuso> Is there a link for this spec yet? Or at least its name?
<jdub> for some reason the spec link goes to a forum page
<jdub> which basically discusses what was done for dapper
<TheMuso> ah got it
<jdub> and doesn't really map to what's going on in the world
<makko> sladen: so is it unnacceptable?
<jdub> makko: we've done all we can with esd and dmix in dapper
<makko> jdub: then why does the solution here http://www.ubuntuforums.org/printthread.php?t=32063&pp=40 work better?
* jsgotangco yawns too early
<jdub> a) libesd-alsa0 is already installed
<jdub> b) i believe a different alsa configuration is used; check with pitti
<TheMuso> Has anybody worked out how to reliably get /dev/dsp stuff mixed as well?
<jdub> c) changing the gstreamer setting to alsa is fine
<jdub> TheMuso: it totally depends on your app
<TheMuso> the alsa-oss package seems to be borked.
<jdub> TheMuso: skype, for instance, is pretty thoroughly broken
<TheMuso> jdub: Yeah I know.
<TheMuso> I'm just thinking in terms of software speech synthesis.
<makko> jdub: so could you please help me clean my specification?
<sladen> TheMuso: it keeps stalling because the kernel people are saying "no" to either of the solutions
<TheMuso> Particularly proprietary synths.
<jdub> makko: i can't see what your specification solves (also, why is it in the forums instead of on the wiki?)
<sladen> TheMuso: if you have a card that can do hardware mixing, then it works
<TheMuso> sladen: Yes, but that doesn't help the vast majority of users.
<makko> jdub: could you please give me an url of the wiki?
<makko> jdub: i will post it there
<jdub> wiki.ubuntu.com
<TheMuso> What are the two different solutions? Got a pointer to them?
<jdub> where everything lives
<sladen> TheMuso: agreed.  This might have to be something that we "get on with" and hammer it through the kernel upstream later.  They are currently blocking the solutions
<jdub> makko: if you want this spec to be relevant, look into what the red hat guys have done with dmix configuration in fedora
<sladen> TheMuso: bouncing /dev/dsp connections back to userspace;  or in-kernel software-mixing
<TheMuso> Right.
<TheMuso> Personally I prefer the bounce back to userspace.
<TheMuso> But thats just me.
<jdub> makko: but really, few people are really loving alsa or dmix, so i think it's unlikely that this is a long term solution
<sladen> TheMuso: start here:  https://lists.ubuntu.com/archives/sounder/2006-May/007009.html
<TheMuso> sladen: Thanks.
<sladen> jdub: my personal want would be to "just" accept that /dev/dsp needs fixing.  Do it.  And then have the other problems disappear.
<jdub> sure, but then we're still stuck with alsa and dmix :-)
<jdub> app -> /dev/dsp -> kernel -> (daemon, where daemon == polypaudio)
<jdub> would be fine
<jdub> but another way to go about it
<makko> jdub: there is no polypaudio in any ubuntu repo. why?
<jdub> would be to standardise on a library interface that application developers want to use, so they're not stuck using oss
<jdub> makko: the old versions were removed a while back
<jdub> makko: 0.9.x will end up in edgy some time
<TheMuso> "Fix the Apps" as stated by Lee Revell in that thread is not always possible.
<jdub> TheMuso: it is, oddly enough, but we are not making it easy
<jdub> (dsp should be fixed in the meantime, however)
<TheMuso> Perhaps, but trying to convince some proprietary synth developers ofthat probably won't be easy.
<jdub> sure it will
<jdub> "whoa, using that hopeless oss dsp crap? here's an api/abi stable library that will give you way more bang for your buck, and reasonable latency plus reporting to boot - rock on kids!"
<TheMuso> Its something I should look at pursuing anyway.
<jdub> oss is still used because it's a consistent interface and mostly just works
<jdub> that's why skype uses it (badly)
<jdub> standardise on something sane, we can bring them across
<jdub> because there'll be value
<jdub> TheMuso: look at libao :-)
<sladen> a -lsimpleaudio that was as simple and easy as OSS and using ALSA as a backend would be great
<TheMuso> I've heard of that library before.
<sladen> (OTOH, maybe that's way esd was supposed to be)
<TheMuso> Time to send some emails to synth developers me thinks.
<jdub> that's what ao is meant to be
<sladen> and polyp is an remplmentation of the say inteface
<sladen> of the same interface
<jdub> and polypaudio has an ao plugin
<jdub> wow, updates CD was 60MB when i first did it, now it's 193MB
<_ion> I wonder why unattended-upgrades didn't upgrade gdm (from ubuntu-security). Looking at the code, it seems like it would ignore any upgrades that depend on new stuff from a non-security repository, but the gdm package didn't.
<_ion> 2006-06-10 07:36:28,886 INFO package 'gdm' not upgraded 2006-06-10 07:36:35,507 INFO Packages that are upgraded: libxine-main1 binutils firefox libpq4 libnss3 libnspr4 binutils-static firefox-gnome-support
<sivang> Burgwork: pong
<sivang> hmm, now he's probably asleep
<tseng> only if he is lazy
<ajmitch> far too early to sleep
<sivang> ok, laters
<MagicFab_sleepin> hello
<MagicFab_sleepin> I don't know if this is the right place, but wanted to know if someone knows/has a way to confirm this:
<MagicFab_sleepin> http://fasmz.org/~pterjan/blog/?date=20060609#p01
<MagicFab_sleepin> I hate people assuming things and not asking, but I don't know how to handle to  this one
<HiddenWolf> here comes the great debate
<HiddenWolf> MagicFab_sleepin: best raise any concerns on the mailing list
<MagicFab> HiddenWolf, I did on #ubuntu-marketing, which one do u suggest ?
<HiddenWolf> MagicFab: devel or sounder
<HiddenWolf> MagicFab: mailing list, not irc
<MagicFab> sounder, yes. tx
<bddebian> Howdy
<MagicFab> sent to sounder
<MagicFab> gotta go
<mjg59> desrt: Hi?
<pianoboy3333> Can someone here help me with the python curses module? I need to know how to resize a curses window.
<dholbach> heya anselmolsm!
<anselmolsm> hi dholbach !
<dholbach> anselmolsm: care to join #ubuntu-soc?
<anselmolsm> ok
<bddebian> Heya Daniel
<dholbach> hey bddebian
<tseng> hi all
<karim> I have a problem on dapper ppc when I dist-upgrade it installs 24 packages, but then after that if I redistupgrade it against wants to installs them
<bddebian> Heya tseng
<bddebian> dholbach: still here?
<dholbach> bddebian: Yepa
<bddebian> dholbach: Mind if I /query you for a sec?
<dholbach> bddebian: not at all
<bluefoxicy> hey is it a bug or a feature that putting "alias ls='ls --color'" into ~/.profile makes it impossible to log in correctly?
<Treenaks> bluefoxicy: why does it make it impossible?
<bluefoxicy> Treenaks:  I have nfc.  It just says it can't start gnome-session in .xsession-errors; rm'ing the .profile fixed it.
<bluefoxicy> also manually starting gnome-session worked
<Treenaks> strange
<bluefoxicy> it doesn't matter, I'm happy anyway ^_^
* bluefoxicy found the root cause of four bugs he filed and like 20 he didn't file was a stray PT_GNU_STACK marking, and filed a bug with instructions to fix it, so the only thing left on a default ubuntu install with an executable stack should be anything playing FLAC :)
<tseng> bluefoxicy: where was the bad marking?
<bluefoxicy> tseng:  libgcrypt.so.11
<bluefoxicy> tseng: https://launchpad.net/distros/ubuntu/+source/libgcrypt11/+bug/49192
<Ubug2> Malone bug 49192 in libgcrypt11 "libgcrypt11 has an executable stack" [Untriaged,Unconfirmed]  
<bluefoxicy> tseng: http://rafb.net/paste/results/YnDGmj25.html One user process with w|x, too many root processes, but none of those are stack (and rhythmbox hasn't played a flac yet so I don't have a +X stack on that yet)
<bluefoxicy> ugh.. I can't find x86 .s or .S files in the flac source tree.  *tries disabling all assembly optimization crap* I have doubts this one is going to be so simple :(
<bluefoxicy> fixed it.
<marga> Hi! I'd like to get in touch with the people that develop/ed Rosetta... Does anyone here know who they are?
<pygi> marga, #launchpad
<marga> ok /join #launchpad
<marga> sorry. :)
<janimo> mdz: ping
<BenC> so when is the queue for edgy going to start processing?
<HiddenWolf> BenC: did you see that story about ubuntu being non-free?
<BenC> no
<BenC> got a url?
<HiddenWolf> http://fasmz.org/~pterjan/blog/?date=20060609#p01
<HiddenWolf> someone asked about it here in the channel
<desrt> BenC; more fun patches 4 u
<HiddenWolf> 16:02 CET
<BenC> HiddenWolf: eh, everyone will have an opinion on that...it's no surprise
<HiddenWolf> Does it have any merit?
<BenC> I can understand both sides of the argument, but what it boils down to is Ubuntu has take great strides in keeping it's promise of a free (as in beer) operating system that works on as many systems as possible
<Mirv> BenC: non-free stuff should still be in restricted always, if the case is as he says in the blog
<BenC> I really dislike the argument about "you give this to newbies without them knowing they have proprietary stuff on it", when any linux newbie will 1) Be used to proprietary, or not care, and 2) Wont understand the argument that their hardware doesn't work because the driver/firmware isn't free/open
<Mirv> unless there is a clear agreement that binary blobs that are not executed on the host machine can be included inside the main kernel
<HiddenWolf> That argument is somewhat fundementalistic.
* desrt quotes irc conversation and sends to osnews for their article on "ubuntu kernel maintainer hates your freedom"
<BenC> :P
<BenC> one good point is that perhaps all firmware should be moved to linux-restricted-modules
<BenC> but that's about all I get out of that article/rant
<desrt> i find funny: the reason that l-r-m is so damn annoying (with the 'volatile') is not because of ati/nvidia/atheros/anyone
<HiddenWolf> BenC: I guess he's pissed that he lost his "100-percent-open" bragging rights.
<Mirv> BenC: yes, the rant seems to be about Ubuntu being not Debian.. or actually, not even that.. it's clear that ubuntu has this "restricted" thing as well as Debian has non-free
<desrt> o
<desrt> so... i installed vmware-player today
<BenC> having l-r-m installed by default and on the CD is a question of "feedom of speech" vs. "make it work on my box, I don't care about your religous high ground"
<desrt> it works really great
<desrt> and i don't feel any dimished as a human being because o fit
<BenC> desrt: vmware-player is really nice
* HiddenWolf is still looking for opensuse images
<desrt> BenC; i like it better than the real thing
<desrt> it's fast and has a very very simple UI and boots directly into my VM on start and auto-suspends on close
<desrt> what else do i need?  nothing.
<BenC> desrt: the vmware-player image site pretty much makes vmware proper only useful to enterprise systems
<desrt> plus
<Lathiat> not really
<Lathiat> it does lots of cool stuff
<desrt> the modules taking care of themselves = big win.
<Lathiat> i use the virutal network stuff of workstation all the time
<BenC> Lathiat: well, I can just "cp image.vdk backup.vdk" to work around the need for snapshots :)
<Lathiat> heh
<Lathiat> yeh theyre handy too
<Lathiat> as is the ability to duplicate machines etc, and from snapshots
<Lathiat> but i guess in lots of cases
<Lathiat> player is quite usefull
<BenC> does player support shares?
<Lathiat> wonder how long til someoen makes a tool to create vmware projects
<Lathiat> or does one exist already?
<desrt> BenC; shares?
<jdub> Lathiat: vmx files?
<Lathiat> jdub: i guess?
<BenC> like windoes shares from your host to the client
<Lathiat> desrt: workstation has crack samba craziness
<jdub> Lathiat: google for 'vmware vmx' and you'll find a web based tool
<desrt> BenC; you don't need support in vmware for that
<Lathiat> jdub: heh
<desrt> BenC; just use samba...
<BenC> but vmware makes it so much easier :)
<BenC> true though, you don't need that built-in
<mgalvin> *cough*
<mgalvin> http://www.simplifiedcomplexity.com/downloads/blank_vmware_image.tar.gz
<Lathiat> slip of the paste button? ;)
<jdub> Lathiat: and you can create the vmdk with qemu-img
<Lathiat> i guess yoru supposed to distrebute those anyway
<Lathiat> jdub: nod
<mgalvin> in case that might be useful to anyone, it a blank vmware image with a default vmx
<desrt> BenC; http://desrt.mcmaster.ca/random/ich7-sci-en-hack.patch
<mgalvin> jdub: issue 2 for UWN is almost all set in case you want to take a peek before i mail it out tonight
<desrt> BenC; would you take something like this?
<Mirv> I'd like to see separation of firmwares from the rest of the restricted stuff.. like not being forced to install nvidia-common etc. if I just want the ipw2200 firmware
<BenC> desrt: Sure, but don't label it "hack" :)
<desrt> BenC; it's most definitely a hack :)
<BenC> desrt: Ok, but disable the KERN_WARNING, or make it sound less horrible :)
<desrt> ah.  right.  ok.
<BenC> KERN_INFO, and more pleasant...always getting complaints from users about scary dmesg output
<desrt> BenC; i'm copying a function in that file that does an equiv thing for toshiba notebooks and uses WARNING
<BenC> "I saw the word hack in my kern.log...have I been hacked?!?!?"
<BenC> ah
<jdub> mgalvin: when is 'tonight' in hours?
<desrt> BenC; how's 'quirk'?
<izm99> Hey, not sure if anyone will find it useful, but I wrote a substitute for the /usr/bin/gnome-volume-manager-gthumb script.  This is the script that is run when you insert a flash card containing DCIM folder (digital pics) or connect a digital camera.
<BenC> yeah, that's a good word
<desrt> k.
<izm99> I'm not an experienced dev, but details can be found on my blog: http://www.stevenbrown.ca/blog/archives/108
* desrt becomes concerned
<HiddenWolf> desrt: ?
<desrt> my laptop was failing to go to sleep, but then i remembered that i modified the sleep scripts :p
<eXistenZ> ivoks, hello
<ivoks> eXistenZ: hi
<eXistenZ> ok
<eXistenZ> any cups developer around?
<crimsun_> eXistenZ: fairly unlikely during the weekend.
<eXistenZ> crimsun_, sound/video/printing drivers are ones of the most undeveloped things in linux
<mjg59> eXistenZ: ?
<mjg59> For sound, I'm pretty certain that's not true
<eXistenZ> mjg59, I tried to duplicate my mp3 to all 5.1 stereo speakers, but unfortunately it made lots of noise.
<mjg59> eXistenZ: How did you try that?
<eXistenZ> mjg59, In windows it is duplicated without any problem
<eXistenZ> mjg59, By editing .asoundrc
<eXistenZ> mjg59, http://ubuntuforums.org/showthread.php?t=167986&highlight=surround
<crimsun_> mp3s are not native "5.1". You can only duplicate front to have a "surround effect".
<eXistenZ> crimsun_, I know. That's why one has to duplicate the speakers.
<crimsun_> the reason that .asoundrc won't work for you is because routing is chipset specific
<eXistenZ> crimsun_, Is it possible to customize it to my chipset?
<crimsun_> eXistenZ: sure, ask in #alsa
<tnks> Hi.  I don't mean to raise a lot of controversy, but I've always been interested in the fork of Ubuntu from Debian.  I've heard that restrictive licensing might have been an issue.  Was there other issues?  Is there a page that discusses this well?
<mjg59> tnks: Not really, no
<mjg59> Licensing didn't play a part in it
<tnks> mjg59: okay.  I'm interested in your explanation if you have the time.
<FunnyHat> Or if you have a URL that explains it??
<BenC> do uploads to *-security not show up in launchpad?
<mjg59> It's a fork because Mark decided that he wanted a Linux distribution that was aimed at the common user
<tnks> mjg59: I've used Ubuntu systems, but not administered them (although I have administered Debian systems).  Are are some key points of focus of Ubuntu?
<tnks> s/What/Are
<mjg59> Simplicity
<mjg59> (broadly)
<tnks> mjg59: Maybe you can help me understand what aspects of Debian were needlessly complex.  I've probably just gotten to used to the system, that I've become desensitized.
<mjg59> Including multiple programs that do the same thing would be an obvious one
<mjg59> Active involvement with upstream to work on UIs that make common tasks easier
<robertj> Also, remember alot has changed in Debian as a response to Ubuntu
<tnks> robertj: that's definately true.  I totally don't feel that Ubuntu has harmed Debian in any deep sense.
<tnks> If anything, it's been positive.
<tnks> I'm just trying to figure out if there are central differences between Ubuntu and Debian testing.
<BenC> tnks: Another thing with ubuntu is making things "work out of the box"
<tnks> The best I had before coming to the channel is that Debian needs to wrap up it's effort to make the installation process friendly.
<BenC> which Debian, in a lot of cases simply cannot due (which can be seen as a good or bad things, depending on your POV)
<BenC> s/due/do/
* BenC needs coffee
<Burgundavia> BenC: is this bunk? https://lists.ubuntu.com/archives/ubuntu-ca/2006-June/000621.html
<tnks> BenC: I see... so do you think this "works out-of-the-box" emphasis has a lot to do with the installer, or is it something more?
<Burgundavia> tnks: it pervades everything Ubuntu does, from installer to kernel and up
<BenC> right
<BenC> Debian out right refuses to allow firmware to be in the default/free install
<BenC> we on the other hand actually strive to make drivers work without any hassle, so we have firmware for things on the CD and installed by default
<tnks> BenC: cool.
<FunnyLookinHat> It comes down to a matter of different goals really...
<FunnyLookinHat> Ubuntu is for the newbie/desktop user.
<BenC> that's not to say that Debian is wrong, we just chose a different way
<FunnyLookinHat> Debian is for the highly customizable high-end user.
<tnks> That is defineately a convenience... so licensing seems to be somewhat of a component too.
<highvoltage> so is ubuntu?
<BenC> coming from Debian, and now working with Ubuntu, I can safely speak on both sides of the matter :)
<FunnyLookinHat> It's similiar to comparing, like Fedora to Gentoo.  Fedora = Easy Desktop Experience, Gentoo = Specifically compiled/built OS
<BenC> Debian and Ubuntu is for the same people, IMO
<BenC> but Ubuntu tried to make entry easier
<FunnyLookinHat> BenC, Unless you just want less hassle with drivers/hardware support
<BenC> right, if you have the right box, you can use Debian just as easily as Ubuntu
<tnks> By the way, the motivation of this discussion, is largely because I'm a long time Debian user, and far too many times people ask me, "Why don't you switch to Ubuntu?"  And I thought maybe you guys could help me get a better answer to that.
<hunger> When will the syncing of debian stuff start for edgy?
<highvoltage> #ubuntu might be the best place to discuss that though
<BenC> this is quickly moving off-topic for the channel I think
<hunger> tnks: I came from debian, too.
<hunger> tnks: It was great when I had the time to configure it.
<tnks> BenC: no problem... I came here from #ubuntu upon recommendation from there.
<hunger> tnks: Now that I do not have that luxury any longer I switched to ubuntu. Same solid base, way less hassle for me.
<BenC> tnks: No problem, I was just trying to keep the conversation from swinging into a philisophical debate :)
<LaserJock> Burgundavia: I think that is an interesting question
<Burgundavia> LaserJock: it is written in a very inflamatory way
<hunger> tnks: The debian devs are great... but they favour flexibility over simplicity IMHO.
<LaserJock> Burgundavia: I have wondered about that myself, can Ubuntu truely claim to only install free software?
<Burgundavia> LaserJock: we really shouldn't, if we
<BenC> some would argue that Ubuntu as a whole is free, as in beer, not as in free speech
<BenC> but we are 99.99% free as in speech, I think
<tnks> Okay, just a question or so and I'll let discussion resume as normal...  hunger: Benc: (or anyone that switched from Debian to Ubuntu), asside from firmware, was there anything that worked "out-of-the-box" that you remember having particular difficulties with in Debian?
<FunnyLookinHat> tnks, for me it was wireless/graphics mainly
<BenC> tnks: I didn't switch to Ubuntu, I got hired by Ubuntu/Canonical, so I'm not a good candidate to answer that
<FunnyLookinHat> I was tired of messing with my xorg.conf
<highvoltage> tnks: ipw2200 drivers
<BenC> my reason for switch was not because I found anything wrong in Debian :)
<LaserJock> Burgundavia: I guess http://www.ubuntu.com/ubuntu/philosophy has a specific exception for drivers
<Burgundavia> LaserJock: it does
<BenC> I will say that before Ubuntu, I _never_, and I mean _NEVER_ used a graphical interface for anything
<BenC> and now it's all I use because I've never seen one that allowed me to work as easily as Ubuntu's does
<hunger> tnks: Hardware of course, but then there are metapackages (ubuntu-desktop/kubuntu-desktop/etc) that give me a nicly preconfigured desktop.
<highvoltage> BenC: not even at an atm when you withdrew money? :)
<FunnyLookinHat> lol
<hunger> tnks: In debian I have to pick and choose all those apps myself...
* _ion uses a graphical interface to view movies at the theater.
<tnks> highvoltage: yeah... I need to install ipw2200 from the website.  Right now ipw2200 is an orphaned source package.
<BenC> highvoltage: hehe
<hunger> tnks: And I have to get all those apps to work together.
<tnks> hunger: so Ubuntu has some kind of hardware detection that sets that all up?
<apokryphos> "/j #ubuntu-doc
<apokryphos> ack
<hunger> tnks: With breezy my laptop worked completly out of the box (minus winmodem that has no linux drivers).
<highvoltage> tnks: it's more of a policy issue, debian has all the functionality and infrastructure, it just doensn't ship with the proprietary firmware
<hunger> tnks: dapper is not as nice a release IMHO, that has trouble with the box.
<LaserJock> hmm, I really felt (from my experience) that Dapper was better than Breezy about mid Janurary :-)
<hunger> tnks: I can get the same HW support in debian... but then I have to figure out the HW specs and look around for the apps I need to get the support. The stuff is all in the debian archives, but it is not installed by default.
<hunger> tnks: With ubuntu all I get all kind of HW support installed by default (OK, I get stuff installed that I might never need, but I do not care about the HD space).
<tnks> hunger: you but can always install a debian kernel image with all the drivers compiled in, right?  Couple that with discovery and hotplug, and is that close?  What more does Ubuntu do?
<hunger> tnks: sure. All the stuff is available in debian. but I have to install and configure bluetooth userspace apps, power management, etc.
<hunger> tnks: Ineed to find out which app supports the additional keys on my laptop. With ubuntu they just work. I have to configure X (graphics, touchpad), etc.
<FunnyLookinHat> tnks, Ubuntu basically has a large group of pre-setup config files for specific hardware profiles, that is one of the big changes.
<tnks> FunnyLookinHat: ahh... that's kind of cool.
<hunger> I need to find out how to turn of ipv6 support in konqueror to speed it up (which kubuntu has already done for me), I need to configure konqueror to get useable menus, etc.
<FunnyLookinHat> tnks, you should try the LiveCD on any desktop you have and see how it works, it might give you an idea of how well the hardware support it
<FunnyLookinHat> tnks, For example, a friend of mine has a GeForce card with a TV-Out section that worked perfectly on the liveCD, no config required
<hunger> tnks: ubuntu gives me nicer defaults to start my own configuration.
<FunnyLookinHat> Don't get me wrong, that's not ALL that ubuntu is ( a bunch of hardware profiles) but it's a major reason why people choose it as a Desktop Linux OS
<tnks> hunger: FunnyLookinHat: cool.  I think you've given me some good indications about pre-configuration of Ubuntu packages.
<hunger> tnks: It is not only the pre-configuration: It is the metapackages that get me a nice and consistent set of apps to get work done.
<tnks> I do spend a lot of time hacking around with Debian.  Perhaps at some level I've grown to enjoy it.  If I get tired of it, I'll defineately consider Ubunutu.
<HiddenWolf> tnks: this is definatly off-topic
<tnks> HiddenWolf: okay... I'll move this to #ubuntu.
<tnks> thanks for everyone's patience.
<hunger> tnks: Those contain one good app for a task... looking in apt-get I get douzends and have to find out which one is good.
<FunnyLookinHat> HiddenWolf, sorry I told him to come here initially from #ubuntu for his first question which was fairly related to this or motu...  I appreciate this channels help though : )
<HiddenWolf> :)
<tnks> If anyone wants to wrap some points, feel free to send some messages to me in #ubuntu.
<tnks> what does motu stand for/
<tnks> sounds like message of the unicorn.
<pygi> masters of universe :)
<HiddenWolf> tnks: the masters of the universe, the volunteer group that maintains universe packages in ubuntu
<tnks> I think there's some audio equipment with a name like motu where the otu stands for "of the unicorn".
<HiddenWolf> tnks: You could find the answers to most of these questions on the wiki.
<tnks> HiddenWolf: okay... I'll look there now, thanks.
* _ion has MOTU MIDI TimePiece AV
<bddebian> Howdy
<mjg59> jdub: It was very weird hearing your voice come from next door
#ubuntu-devel 2006-06-11
<aquarius> Not sure if this is the right place, and you possibly already know, but https://www.ubuntu.com/download/releasenotes/606 pops up an error about the SSL certificate having expired on 06/01/06.
<mdke> aquarius: the website uses http:// I think
<aquarius> mdke: I followed the "Release Notes" link from http://www.ubuntu.com/download.
<mdke> aquarius: I think that is an erroneous link.
<Burgundavia> aquarius: I will fix it
<aquarius> It also pops up another two errors; one because the CA isn't recognised for the certificate, and one because the certificate has the wrong name ("Canonical Ltd" rather than "www.ubuntu.com").
<mdke> Burgundavia: aww
<Burgundavia> aquarius: fixed, should replicate to the server in about 10m inutes
<aquarius> cool. The latter two errors have been around for a while on https URLs at ubuntu.com, but I figured someone already knew about it. 
<alchemist> fark. any of the ndiswrapper maintainers online?
<aquarius> Burgundavia: cool; I just thought it needed mentioning because /download is pretty high visibility.
<Burgundavia> alchemist: what is your issues
<Burgundavia> aquarius: thanks for pointed it out
<alchemist> Burgundavia: I'm hacking at the wpa-supplicant/networkmanager issue
<Burgundavia> aquarius: you can pm me (this nick or burgwork) if you seen any other issues
<alchemist> Burgundavia: I think one fo the issues is the 1.8 build of ndiswrapper
<aquarius> Burgundavia: will do; I didn't realise you were maintainer
<mdke> aquarius: you can also file bugs on the website in launchpad, in case you can't find Burgundavia 
<Burgundavia> aquarius: I can do minor edits
<alchemist> Burgundavia: so I'm hoping to find someone who could compile 1.10 for me on dapper so I cna try that
<aquarius> mdke: I was going to do that if no-one here could help :)
<mdke> aquarius: good plan
<alchemist> if that works, then I can start looking at backport fixes
<crimsun_> alchemist: ndiswrapper is in our kernel. Do you need a straight import, or ...?
<alchemist> crimsun_: 1.8 is in the kernel. I need to test 1.10 - there are some fixed pertaining to wpa-supplicant 
<alchemist> so prolly a straight import
<alchemist> s/fixed/fixes
<crimsun_> alchemist: do you have a dapper pbuilder? If not, I'll walk you through getting 1.17-1 in #trilug.
<alchemist> crimsun_: no pbuilder. a chroot anda xen session
<alchemist> crimsun_: we can hop to #trilug
<crimsun_> right.
<gentoo_helper> Sorry to bother you all, but I have an issue that I think might actually be a bug. I would like to verify this with you guys before I file. It is a problem concerning Xorg and my S3 Inc ProSavage graphics chip.
<Burgundavia> gentoo_helper: what is the issue?
<gentoo_helper> Burgundavia, Basically after an unspecified amount of time...
<gentoo_helper> Burgundavia, My screen locks up and I am unable to recover without a hard reboot.
<gentoo_helper> Burgundavia, The thing is, this issuse appears to be related to apt-get
<Burgundavia> gentoo_helper: that sounds more like a hardware issue to me. Have you tested with memtest86?
<gentoo_helper> Burgundavia, It is reproducible on my system: if you open an exterm and start apt-get (such as apt-get install ethereal) and then attempt to open any program that requires you to clock on a button (for instance open xchat and clock "connect") the machine will either lock up completely, or in rare instaces, do a soft reboot
<Burgundavia> gentoo_helper: lets move to #ubuntu-bugs
<gentoo_helper> Burgundavia, I have not tested with memtest86, but I can tell you that I do not have this issue in Windows. I assume that if it were a hardware issue I would have something similar happening there.
<gentoo_helper> Burgundavia, Ok.
<Burgundavia> mako: I am now permanently scarred by that picture :)
<mako> what can i say.. i'm sick
<mako> oh, you mean the second one :)
<Burgundavia> mako: yes the 2nd one. Get better soon
<mako> i'm not really sick :)
<mako> at least not physiologically ill
<Burgundavia> only in your head?
<Burgundavia> that is also quite a startling colour of blue in your eyes
<ajmitch> heh
<Burgundavia> ajmitch: how goes SoC?
<ajmitch> it goes well enough
<mako> Burgundavia: my eyes are very blue :)
<flyman_ubuntu> hola
<flyman_ubuntu> quick question ...yes/no...works/does not work
<flyman_ubuntu> ...i was getting an xorg.log error that /usr/lib/xserver/securitypolicy  could not be found.  has anyone here created the folder 'xserver' in /usr/lib/and placeed the file "/usr/share/doc/examples/SecurityPolicy" in the new folder?  it uses XC-QUERY-SECURITY-1 which is greek to me...
<flyman_ubuntu> quick question ...yes/no works/does not work
<Vaske_Car> How to check folder size from command line?
<_ion> See topic. (du(1))
<dieman> mako: your new record cover is awesome.
<mako> dieman: heh, glad you like it
<dieman> mako: you going to be in france too?
<bluefoxicy> Wh..
<bluefoxicy> I just tried to apt-get build-dep gnupg and it told me no I have to be more specific
<bluefoxicy> Evidently I have 50 MTAs to pick from, now do I want to install postfix or exim... wait, hold on
<bluefoxicy> why the heck do I need a mail server to compile gnupg?
<Burgundavia> jdub: you seen this http://computerdropoff.org/
<jdub> cool
<Burgundavia> going to be in New Orleans at the end of the month, should be interesting
<fabbione> PANTS OFF
<jsgotangco> well interestingly, some of north america's electronic junk also end up here sometimes sold in 2nd hand shops along with japanese and korean television sets
<Burgundavia> s/north america/united states
<Burgundavia> Canadian stuff almost never finds it away overseas
<Burgundavia> too bad we are 1/10 the pop...
<jsgotangco> that's how i got some cheap sun terminals
<Burgundavia> cool
<Burgundavia> I got a promising lead on some space, so it looks like my recycling project might become more than just a backburnered project
* hunger finds that there is nothing much happening in ubuntu during WE to be somewhat depressing. That is the only time in the week where I have the bandwidth to follow uploads:-(
<mdke> hunger: you can change it!
<sivang> hunger: right, by uploading stuff yourself and joining the MOTUs ;-)
<hunger> mdke: Only in theory:-)
<hunger> mdke: With the little time I have I can not change anything significantly.
<giftnudel> hunger: you can always break stuff, nobody will notice the difference
<sivang> hehe, depends where :p
<msikma> Ohh, pastebin is down.
<mdke> hunger: well, that's the same reason that you're not seeing any downloading during the weekend. No point finding it depressing
<mdke> uploading*
<hunger> giftnudel: Yeah, breaking stuff is easy:-) I do that a lot on my system.
<\sh> hmmm...is gcc4.1 not in essentials for egdy? ;)
<\sh> Kamion: could it be that you forgot the changes in debootstrap for edgy, but you mentioned it in the changelog?
<infinity> \sh: Could it be that deboostrap for edgy hasn't built yet?
<infinity> \sh: And neither has gcc-defaults (where the "gcc" metapackage comes from).
<infinity> \sh: Patience.
<\sh> infinity: oh yes, ubuntu3 and I have ubuntu2 .. need new glasses...sorry
<\sh> Kamion: my blindness :( forget about what I said
<\sh> any fridge admins online? ;)
<shaya> are there any instructions anywhere for redoing the dapper live cd?
<phanatic> shaya: https://wiki.ubuntu.com/LiveCDCustomization/Dapper
<jdub> jpatrick: ping
<\sh> jdub: if you are not too busy, would you add my blog back to p.u.c.?
<jdub> uh, ok
<jpatrick> jdub: yes?
<jdub> \sh: #[http://linux.blogweb.de/feeds/index.rss2] 
<jdub> ?
<\sh> jdub: http://linux.blogweb.de/feeds/index.rss2 yes
<\sh> jdub: thx :=
<jdub> jpatrick: the description on the package you just uploaded is *awesome*
<_ion> URL?
<_ion> *wanna see*
<jpatrick> I didn't touch it
<jpatrick> jdub: debian maintainer's choice: http://packages.debian.org/unstable/x11/kxdocker
<\sh> jdub: forget about kxdocker, most likley it will break with gcc-4.1 ;)
<jdub> jpatrick: i know - that makes you double the culprit ;)
<jpatrick> jdub: and upstreams
<jdub> well, that's just sad
<jdub> but still funny :)
<jpatrick> I'll say it again: "not my fault"
<jdub> you let it through (and brought this humour to my attention)! ;)
<\sh> jpatrick: now you see the liability of a package maintainer, or uploader ;)
<\sh> jpatrick: but it's just kxdocker
<jdub> and the exposure of the -changes lists... brown paper bags are always amusing
<\sh> jpatrick: but if it's "break my ipod, dude"...I'll tell you, you will get be blamed and bashed ;)
<jdub> there are some really amusing descriptions around
<\sh> jpatrick: but if you are drunk during the last 2 days of release time, it's fun .. try me :)
<jdub> i like all the packages that claim they are "powerful"
<jpatrick> \sh: Nop, can't drink
<jdub> or "featureful"
<\sh> jpatrick: right, you shouldn't :)
<jdub> $ apt-cache search powerful | wc -l
<jdub> 502
<jdub> RAW POWER.
<\sh> JDUB FOR PRESIDENT !
<jpatrick> 506 here
* \sh is listening to "Chris Rea - Fool" ...what a surprise :(
<jdub> ysm - A powerful ICQ console client
<\sh> ugh
* \sh goes and buy new beer ... hot weather and world soccer championships...
<mako> dieman: yes, i'm going to be in france
<dieman> mako: rock
<dieman> mako: see you then
<mako> absolutely, i'm looking forward to ti
<dieman> i'll be there a day early in the morning
<dieman> may run out to sightsee a little
<\sh> hmm...I can't attend UDS Paris and now mako is just coming to europe..what a pity
<dieman> depends on how much i sleep on the plane
<mako> i can't remember my schedule
<mako> but i am still trying to go to brazil from paris for the creative commons conf right after
<mako> but it looks like i might not get the visa in time
<mako> which means i'll probably hang around for 5 days or so afterwards
<mako> probably not in paris.. but i'm not sure where
<mako> i'd like to go to germany but with the world cup i think that might be both crazy and expensive
<\sh> mako: go to karlsruhe, I have a sleeping place for you..for cheap
<mako> \sh: i'll let you know :)
<\sh> mako: a hotel room with a bed, for 40 euros..which is cheap nowadays :)
<\sh> mako: and a clean shower :)
<\sh> mako: and congratulations to your marriage :) 
<mako> thanks! on all counts
<\sh> mako: really, to you and mika all my love
<sivang> anybody knows what differnet in a dapper chroot? I'm following https://wiki.ubuntu.com/DebootstrapChroot ,
<sivang> everything went fine during the bootstraping process
<sivang> but I can't install any other packages after chrooting into the chroot
<sivang> I get E: Package gnupg has no installation candidate
<sivang> for evry package I try to install
<\sh> sivang: just normal?
<sivang> \sh: yes, I haven't done anyhting wierd other then ln -s /home/sivan/chroot /var/chroot so I could use my home for storage
<sivang> when I try and udate, I get:
<sivang> Err http://security.ubuntu.com dapper-security Release
<sivang> Ign http://archive.ubuntu.com dapper Release
<sivang> Ign http://security.ubuntu.com dapper-security Release
<\sh> sivang: you can just use /home/sivang/chroot just adjust the paths in the howto..after that, gnupg is still complaining :)
<sivang> Ign http://archive.ubuntu.com dapper-updates Release
<sivang> \sh: I did this before, the symlink doesn't make any differnce
<sivang> \sh: gpg complains, but when I try to install it form the net it says "no installation candidiate"
<\sh> sivang: shermann@amd64-home:~/pbuilder/etc/dapper$ less apt.conf.d/allow-unauthenticated      
* sivang pokes
<sivang> hmm, is "not existant" a good answer? :)
<sivang> I don't have this file at all
<\sh> sivang: strange
<sivang> root@swirl:/# apt-get update --allow-unauthenticated
<sivang> still gives error in apt-get update
<sivang> *odd*
<\sh> sivang: but is it installing the package?
<sivang> \sh: no, dammit, I think I accidently wiped out the binary source line :-/
* sivang checks
<sivang> yep
<sivang> DOh, that was it.
<sivang> \sh: thanks :)
<\sh> sivang: no ways..come on. this must be an action fixable bug;)
<\sh> with some action ahead of us ;)
<sivang> \sh: heh
<\sh> sivang: no laugh ;)
<kagou> hi
<jdub> Keybuk: thanks for the kickseed fix
<HiddenWolf> edgy is open?
<sladen> HiddenWolf: esr kills a kitten everytime that somebody asks that
<HiddenWolf> sladen: I'll take a kitten from you, thanks. :)
<Keybuk> jdub: ah, it was you who found it?
<jdub> Keybuk: yeah; did Kamion's fix not fully fix it?
<Keybuk> there was another instance of the same bug a few lines above
<jdub> i promised to be his kickstart bitch after i found that
<Keybuk> he found it on Friday, and text me this morning asking me to fix it
<zyga> hello
<Amaranth> hey
<zyga> I'll see sabdfl tomorrow :)
<Keybuk> oh aye?
<phanatic> zyga: he's going to .pl right?
<Seveas> yeah
* highvoltage imagines sabdfl with a big marker changing all the .pl posters to .py
<bluefoxicy> ugh
<Seveas> HAHAHA
<bluefoxicy> screw this.  *steals the xvid no-exec-stack patch and textrel fix from Gentoo*
<Seveas> highvoltage, pyland 
<bluefoxicy> does anyone know who upstream xvid is so I can try to get libxvidcore4 patched upstream?
<zyga> phanatic: yes!
<zyga> :)
<zyga> I hope to get a signed disk tomorrow :)
<bluefoxicy> Patches submitted upstream.  I think.
<desrt> BenC; ping
<bluefoxicy> holy crap, gcj7 is STILL building
<highvoltage> for how long?
<Keybuk> bluefoxicy: it is?
<Keybuk> showing up as built to me
<bluefoxicy> Keybuk:  no, I mean I'm building it over here to try and track why it has a +X stack
<bluefoxicy> and correct it
<Keybuk> Date built:  	2006-06-11 15:04:03 BST
<Keybuk> Build duration: 	2 hours 20 minutes
<Keybuk> ahh
<bluefoxicy> oshit 2 hours?!
<Keybuk> that's on our buildd
* bluefoxicy tried to do qthreads and xvid in the interim, found them to be quick but .... take a little more work than a quick bash script :P
<Keybuk> always wondered, how does all this stack protection stuff play with gdb?
<bluefoxicy> Xvid I referenced the gentoo patches and also threw them at upstream, qthreads... well, time to hit gentoo cvs huh.
<bluefoxicy> GDB doesn't care
<Keybuk> doesn't it affect gdb's ability to make the process execute arbitrary code?
<bluefoxicy> no
<Keybuk> how comes?  that just sticks stuff on the stack, iirc
<bluefoxicy> gdb uses ptrace() IIRC, so it attaches to a running process-- or, loads a process stopped and executes it
<bluefoxicy> hmm
<bluefoxicy> sticks stuff on the stack?  How does it know what parts of the stack aren't in use
<Keybuk> right, but while under gdb you can run functions and change data
<Keybuk> it's one of gdb's more useful abilities
<Keybuk> "see what would happen if I run the function with different arguments, ah *that's* better"
<bluefoxicy> like write code, compile, and inject; or "call this function"
<Keybuk> both
<bluefoxicy> if you're just calling different code with different arguments there's no problem
<bluefoxicy> injecting new code sounds tricky.
<Keybuk> syndicate scott% echo "main() { }" > test.c
<Keybuk> syndicate scott% gcc -g test.c
<bluefoxicy> sounds like elfsh too
<Keybuk> syndicate scott% gdb a.out
<Keybuk> (gdb) break main
<Keybuk> Breakpoint 1 at 0x8048360: file test.c, line 1.
<Keybuk> (gdb) run
<Keybuk> Starting program: /home/scott/a.out
<Keybuk> Breakpoint 1, main () at test.c:1
<Keybuk> 1       main() { }
<Keybuk> (gdb) p printf ("hello world\n")
<Keybuk> hello world
<Keybuk> $1 = 12
<Keybuk> etc.
<bluefoxicy> I don't think that injects code
<Keybuk> has to, otherwise how else does is call the function? :p
<bluefoxicy> printf is a built-in gdb function that formats the given text
<Keybuk> no, that's "p printf"
<bluefoxicy> well, calling printf is easy enough.
<Keybuk> syndicate scott% echo 'test(int a) { printf("called with %d\n", a); }' >> a.c
<Keybuk> then
<Keybuk> uh, s/a.c/test.c/
<bluefoxicy> open up a stack frame (i.e. move %esp, doable when you're controlling a task's execution and registers), write a stack frame for printf in (i.e. write current %eip as retp, write in the data you want to send to printf()), move %eip to the prologue of printf()
<Keybuk> (gdb) p test(47)
<Keybuk> called with 47
<Keybuk> $1 = 15
<Keybuk> (gdb) p test(12)
<Keybuk> called with 12
<Keybuk> $2 = 15
<bluefoxicy> calling functions can be done without injecting code
<Keybuk> ah, so you can still do that
<Keybuk> that's what I was asking
<bluefoxicy> try writing a new function
<Keybuk> can't an exploiting process just do the same thing then?
* bluefoxicy shrugs
<Keybuk> it does seem to me that either it breaks gdb, or leaves a back door open
<bluefoxicy> If you're interested, go pick up a No Starch Press printed book, Jon Erickson's "Hacking:  The Art of Exploitation"
<bluefoxicy> it's not bad, it goes through the full exploit development process and shows how to inject code into the stack, and then shows how to evade non-executable stacks using ret2libc attacks
<Keybuk> I'm only interested from a "don't break existing stuff" pov.
<Keybuk> I know how to inject stuff into processes
<bluefoxicy> http://pax.grsecurity.net/docs/aslr.txt is how you break ret2libc attacks btw ;)
<bluefoxicy> well
<bluefoxicy> I highly doubt gdb executes code in the target process
<Keybuk> it does
<bluefoxicy> it'd be hard to figure out reliably what it can and can't do
<Keybuk> why?
<bluefoxicy> executing a function doesn't have to involve injecting new code anyway
<Keybuk> it can do a lot more than just executing functions, that's just the easiest example to demonstrate
<bluefoxicy> well, gdb has to debug the program, it can't interfere with it THAT much
<Keybuk> sure it can
<sladen> D'uh.
<bluefoxicy> the program has a non-executable stack, if you try to execute on the stack it dies.
<bluefoxicy> If you have a NX stack and try to execute a nested function, it crashes.
<bluefoxicy> Now what happens when you open your debugger and try to debug it if the debugger makes the stack executable?  :P
<bluefoxicy> "I dunno why, it works in the debugger..."
<zul> hey keybuk
<Keybuk> if it works in the debugger, then any exploiting process can do it
<bluefoxicy> i386 is the only architecture where the stack isn't typically non-executable.
<Keybuk> the debugger isn't a magic binary
<bluefoxicy> nope
<Keybuk> it's not even setuid root
<bluefoxicy> read what I said?
<bluefoxicy> <bluefoxicy> Now what happens when you open your debugger and try to debug it if the debugger makes the stack executable?  :P
<bluefoxicy> injecting code onto the stack when it's non-executable is fine; jumping to it will not work
<Keybuk> if a debugger makes the stack executable, then so can an exploit
<bluefoxicy> no, it can't.
<Keybuk> what's magic about a debugger?
<Keybuk> it's just a program that knows a little bit about how compilers make executables
<bluefoxicy> An exploit can't halt a process, skip over an instruction, randomly alter data, and produce a full back trace at will.
<Keybuk> sure it can
<Keybuk> the explot can ptrace the executable :p
<bluefoxicy> on Linux the debugger attaches to a process using ptrace()
<sladen> bluefoxicy: man ptrace
<bluefoxicy> which you need privileges to do to a higher privileged process.
<bluefoxicy> so if user Jackass tries to ptrace() firefox-bin run by user David, it says "no, fuck off"
<Keybuk> indeed
<Keybuk> but you can ptrace your own executables
<bluefoxicy> If you're already David, there's no need to hack your own executables.
<bluefoxicy> you already have the privileges you need.
<Keybuk> you can't write to the stack of higher privileged processes either
<Keybuk> so I'm not sure I'm following your point
<bluefoxicy> uh, yeah, right.
<sladen> good-oh.
* bluefoxicy picks up a slight bug in Gaim that's not yet been discovered, which causes certain IM messages to be copied to a 128 byte buffer on the stack even if they're 100000 bytes long, and gets on Keybuk's machine with it.
<Keybuk> yes ... congrats, your on my machine as "scott" ?
<Keybuk> how is that going to help you do anything
<bluefoxicy> who says you even need to be on the same machine to pull out an exploit?  You can fire them straight through firewalls in some cases.
<bluefoxicy> heh
<Keybuk> you could just buy me a very large drink, and I'd lend you my laptop for half an hour :)
<bluefoxicy> Well if I can get on your machine as scott, I can pull attacks like (for example) hitting postfix (if you have it installed, bound to 127.0.0.1 to mail root errors) or mysql (typically bound to localhost), or just yank down a new local root exploit (back in the day there was one that fucked up VMA and let you write to root process memory, by screwing with use_lib()...)
<bluefoxicy> or prod around on http://www.milw0rm.com/
<Keybuk> and then what would you do? :p
<bluefoxicy> of course if the stack's not executable it's kind of hard to execute code you just injected on it :)
<bluefoxicy> I dunno
<Keybuk> I'm always curious about the script kiddie mentality
<Keybuk> they're all "I'll h4x0r j00"
<bluefoxicy> format your hard drive?  use root access to ptrace() firefox and suck up your passwords?  Pick up your gpg key password and totally fuck up Ubuntu's repos with it?
<Keybuk> every password in firefox is usually "applejack"
<bluefoxicy> lol
<Keybuk> it's sufficiently public because I keep putting it in CVS code by accident
<bluefoxicy> ouch
<Keybuk> it's famously in the example dircproxy config file
<hunger> Keybuk: I had one guy ask for my IP so he could hack me... I gave him 127.0.0.1. The next day he told me I was lucky that whenever he tried to attack me his machine crashed:-)
<Keybuk> you couldn't get my GPG key from my laptop, it's on a separate device
<bluefoxicy> I've done the lmsg nickserv identify <my root password is the same as my nickserv password> thing :)
<Keybuk> there are far more interesting social engineering attacks to get that though
<hunger> Keybuk: I laughed my head of... and so did everybody else in that IRC chanel... he never dared come back.
<Keybuk> hacking people is MUCH more fun :p
<sladen> bluefoxicy: what you do, is you overflow the stack with the return address to another function, that takes parameters left on the stack, then you buffer-overflow that function, in the case of an executable stack
<_ion> Please hack infrared vision to my eyes.
<bluefoxicy> sladen:  Yep.  That works, that's how you evade the NX stack.
<bluefoxicy> sladen:  of course, if the mmap() base and stack base constantly move around, you have yet another task
<Keybuk> ya know
<bluefoxicy> sladen:  Locate the base of the stack (take a guess, that's about as good as it gets...) and of loaded libraries (yeah, good luck guessing that too...)
<Keybuk> a thought occurs
<Keybuk> prelink defeats randomised maps
<Keybuk> yet ANOTHER reason to dislike prelink
<sladen> bluefoxicy: yes, you already have to guess your way past 8-bit of mmap() base randomness and 19-bits of stack randomness
<bluefoxicy> sladen:  So what next?  ... okay, write your stack frames into the heap, that doesn't move.  Bounce to a call in the main executable with %esp pointed in the right place in the heap, it'll finish off the stack frame, call the function.  Congratulations, you defeated address space randomization.
<tseng> sigh
<sladen> bluefoxicy: what next?  Next you go to the pub and look for cute people to try and take home.
<Keybuk> heh, now there's how to hack the Ubuntu archive.
<bluefoxicy> sladen:  So this one's easy... build the main executable PIE, it moves with mmap(). Randomize the heap base too.  Bading.  :)
<Keybuk> hire really gorgeous people to seduce Ubuntu developers and get them to upload back doors to things like the kernel or sysvinit
<bluefoxicy> sladen:  Next order of business... give it time, someone will find something.  You probably left some daemon configured with a default root user and password or something.  ;)
<Keybuk> roofies may be involved
<bluefoxicy> tseng:  hi :)
<tseng> hi
<sladen> "hey there sexy, I'd like to exploit your backdoor"
<bluefoxicy> at any rate
<bluefoxicy> sladen:  ok that sounds really gay
<Keybuk> bluefoxicy: there is a really simple way to completely guarantee your computer will never be hacked
<zul> mmm...baddoors
<Keybuk> bluefoxicy: and what's wrong with being gay?
* Keybuk is gag
<Keybuk> uh, heh
* Keybuk is gay
<hunger> kkeybuk: scissors?
<bluefoxicy> Keybuk:  Dip it in molten iron and drop it down into that trench in the ocean.
<Keybuk> hunger: exactly!
<sladen> bluefoxicy: and what exactly would be wrong about that?
<bluefoxicy> sladen:  *shrug* Nothing, just pointing out
<Keybuk> there are several gay and bisexual Ubuntu developers on both Canonical pay roll and in the community
* sladen flutters his eyelids at bluefoxicy 
<Keybuk> not to mention *gasp* women
<bluefoxicy> sladen:  besides, I don't normally hear anyone talk about picking up guys at bars... usually they go to the GLBT center.
<sladen> Keybuk: women?  *gasp*.  Youcannotbeserious?!(!)(!)(!)(!)
<bluefoxicy> Keybuk:  There are females on the intarweb?
* hunger even works for a woman:-)
<bluefoxicy> sladen: There's also furries in #ubuntu *gasp* :O
<Keybuk> bluefoxicy: so I suggest at this point you read the "Be respectful to others" section of the Ubuntu Code of Conduct
<bluefoxicy> Keybuk:  First off, my user page still says I haven't signed any code of conduct; second, I was never disrespectful to anyone.
<Keybuk> bluefoxicy: by participating here you are agreeing to abide by the code of conduct
<bluefoxicy> Keybuk:  ad-hominem but okay
<tseng> this is highly entertaining
<bluefoxicy> tseng:  I'd imagine from your stance it would be :p
<Keybuk> bluefoxicy: if you do not feel you can participate without making insult to people different to yourself, I would ask that you leave
<bluefoxicy> Keybuk:  I never insulted anyone, unless (inadvertantly) pointing out someone's gay somehow became an insult.
<Keybuk> <bluefoxicy> sladen:  ok that sounds really gay
<Keybuk> <bluefoxicy> sladen: There's also furries in #ubuntu *gasp* :O
<Keybuk> etc.
<Keybuk> these things could be insulting to others
<Keybuk> both imply that you believe these kinds of people are not welcome here
<Keybuk> that is not true
<bluefoxicy> no, your brain implies that
<bluefoxicy> I never said any such thing.
<Keybuk> please be more aware of how things you say could be interpreted
<bluefoxicy> anyway how did we get here from discussing gcj and xvid executable stacks
<ChipX86> to be fair, the first was in response to "hey there sexy, I'd like to exploit your backdoor," and the second was a play on "there are *gasp* women"
<bluefoxicy> yes chip
<Keybuk> ChipX86: it was not a welcome response
<ChipX86> I think this was just blown out of proportion
<lifeless> iwj: heh, squid just picked up your patched version of Colin Pplumbs md5
<ChipX86> Keybuk: no, perhaps not, but in the context it didn't appear to be anything but playing along
<ChipX86> I think the best thing to do would be for everyone to move along
<Keybuk> I agree
<bluefoxicy> in context I figured a straight guy would go "uh" and try to recover face, and a gay guy would just shrug and not care
<bluefoxicy> neither of which is particularly damaging to person
<bluefoxicy> anyway what do I have to fix next
<bluefoxicy> qthreads... where is that
<lifeless> Keybuk: We're using the Claverly again for overflow :)
<Keybuk> lifeless: I liked the Claverly -- who's ended up there? :)
<lifeless> Keybuk: I *am* looking forward to breakfast next week :)
<Keybuk> heh
<Keybuk> the breakfast made up for the air-conditioning units
<lifeless> and possibly breaking in some Mao players ;)
<bluefoxicy> Running /tmp/x/gcj-4.1-4.1.0/src/gcc/testsuite/gcc.c-torture/compile/compile.exp  <-- awesome
<lifeless> indeed, I'm not looking forward to hat
<Keybuk> how did we end up overflowing a hotel?
<Keybuk> I didn't think anyone else was in London this week?
<lifeless> I think the hotel underflowed its spaces
<lifeless> the K&K is just booked out
<bluefoxicy> crap.
<Keybuk> weren't you booked in already ages ago?
<lifeless> yes
<lifeless> currently at the K*K.
<bluefoxicy> guile has no execstack patch on gentoo and fixing it is inordinately complex (fix some assembly files, rename some assembly files to .S instead of .s, fix the build system to recognize .s instead of .S, patch files calling the .s to use .S...)
<bluefoxicy> I'll do that one later.
<bluefoxicy> ok... liblzo1 is also complex but gentoo has a patch.
<bluefoxicy> Running /tmp/x/gcj-4.1-4.1.0/src/gcc/testsuite/gcc.dg/dg.exp ...
<bluefoxicy> FAIL: gcc.dg/20020122-2.c (test for excess errors)
<bluefoxicy> just flat apt-get source'd and dpkg-buildpackage -uc -us -rfakeroot'd it.
#ubuntu-devel 2007-06-04
<LaserJock> hi minghua 
<pygi> LaserJock, !!
<minghua> hello LaserJock
<LaserJock> hi pygi 
<etank> pygi: i came up with a question for you if you have a few moments.
<pygi> etank, oki, pm
<etank> sure
<pygi> if I know, I can answer ^_^
<pygi> LaserJock, did we backport deboostrap from gutsy to feisty-backports?
<LaserJock> I think it actually goes into -updates
<pygi> LaserJock, understood, thanks
<ubunt1> hi
<ubunt1> how can i program.
<ubunt1> c++
<ripl> where is hobbsee?
<Hobbsee> morning all
<racarr> Hello Hobbsee 
<Hobbsee> hi racarr :)
<racarr> How are you?
<Hobbsee> meh.
<Hobbsee> reading backscroll and such, thinking about actually going to uni today
<racarr> That might be a good idea.
<Hobbsee> yeah, maybe.
<racarr> In other news, I made nautilus crackful! http://www.rpi.edu/~carrr/woo.png
<racarr> (different wallpapers)
<Hobbsee> heh, nice :)
<nixternal> Mithrandir: GPL copyright holder seems to be using a pseudonym for his name, is this legal, or acceptable for a package that I want to get into Debian and Ubuntu? I am currently working on one now that is like that. thanks!
<Hobbsee> nixternal: he'll be asleep, FYI
<nixternal> ya, I kind of figured that...to bad I didn't have his phone number ;p
<Hobbsee> LaserJock!
<Hobbsee> nixternal: it'd still require actually claling the correct number, evenif you had it
<nixternal> any other archive admins awake or around?
<Hobbsee> unlikely
<Hobbsee> it's au day
<nixternal> hrmm, seems like pitti said g'nite 8 hours ago...about time he woke up :)
<Hobbsee> it was a weekend 8 hours ago in most countries, still
<nixternal> yes, but he needs to wake up and help me...I mean go to work ;p
<Hobbsee> hehe
<fabbione> morning guys
<Hobbsee> hi fabbione!
<fabbione> yo
<Burgundavia> hey jsgotangco
<jsgotangco> hi!
<Hobbsee> hi Burgundavia 
<pitti> Good morning
<Burgundavia> hey pitti
<Hobbsee> hi pitti!
<LaserJock> hi pitti and Hobbsee 
<Hobbsee> hiya LaserJock :)
<siretart> morning folks
<pitti> hi siretart 
<siretart> Mithrandir: can you please give back xine-lib on all archs? (again, this time it should work, since I fixed ffmpeg, again)
<siretart> hey pitti
<Hobbsee> hi siretart 
* siretart hugs Hobbsee 
* Hobbsee hugs siretart!
<siretart> :)
* nixternal hugs his pillow
<Mithrandir> siretart: given-back
<pitti> Riddell, LongPointyStick: Any idea about digikaminageplugins? It's uninstallable, but ISTR someone mentioning that it is obsolete?
<Adri2000> Mithrandir: should I ask you to review an upload for feisty-backports? or should I just find a core-dev to upload it? (because I believe I can't upload to -backports as a motu)
<Mithrandir> Adri2000: is there a reason it can't be done through the normal backports process?
<StevenK> Wah. Why does next doors band have to practice when I'm crabby, tired and have a headache?
<Adri2000> Mithrandir: yes, it requires a newer version of libgnutls than the one available in the feisty archive. the patch which fixes that is known to work because it is also used in the current package in feisty
<StevenK> A street-wide power outage appeals, but that doesn't fix the drum kit.
<Mithrandir> Adri2000: hm, ok.  You don't need pre-approval from archive to upload to backports, but you should have coordinated with the backports team.  As long as that's done, please feel free to find a core-dev sponsor
<Adri2000> ok
<mpt> hi StevenK 
* StevenK waves
<cjwatson> pygi: yes, we did backport it. use 'rmadison -u ubuntu debootstrap' on gutsy to see
<pygi> cjwatson, thanks
<mpt> StevenK, did you ever get about-window packaged?
<cjwatson> it goes into -backports
<Lure> pitti: digikamimageplugins is included in digikam now, I have opened bug to remove it from archive
<pygi> cjwatson, thought so. thanks :)
<Lure> pitti: ubuntu-archive is subscribed to bug
<pitti> Lure: ah, then I'll look at those right now; thanks
<pitti> it's gone
<pitti> doko_: any idea about the uninstallability of libgcj7-awt?
<pitti> doko_: it depends on an old version of gcj-4.1-base
<pitti> oh, it's NBS
<pitti> doko_: so, it seems we need to rebuild openoffice.org to have openoffice.org-officebean drop its libgcj7-awt dependency, then we can remove it
<pitti> right now, -officebean is uninstallable
<StevenK> mpt: Somewhat.
<dholbach> good morning
<pygi> morning dholbach 
<dholbach> hi pygi
<mvo> good morning dholbach!
<highvoltage> hello dholbach, pygi and mvo 
<pygi> hey highvoltage :)
<dholbach> hey mvo
<dholbach> hey highvoltage
<mvo> hey highvoltage
<doko_> pitti: correct, but the openoffice.org-officebean should be in universe anyway
<doko_> will have to update the OOo build today
<pitti> oh, ok, I can demote it
<pitti> doko_: it's not in anastacia, thus likely seeded
<pitti> doko_: shall I unseed it?
<pitti> doko_: it's currently in the 'development' section
<doko_> hmm, not now, let's see how this works with openJDK. put on my "things to remember for gutsy"
<StevenK> doko_: For a main merge, are -java-gcj packages still required?
<pitti> doko_: ok; FYI, I removed libgcj-awt since it is uninstallable anyway
<lool> doko_: Happy birthday!
<pitti> argh, vmware kernel mod doesn't build for 2.6.22; so back to 2.6.20, brb
<cjwatson> 15:22 <BenC> s/h/mac_header/
<cjwatson> 15:22 <BenC> s/nh/network_header/
<cjwatson> pitti: ^-- advice on fixing vmmon/userif.c
<cjwatson> er, vmnet
<pitti> oh, sweet, thanks
<fabbione> nah wait
<fabbione> it's not enough
<doko_> StevenK: yes, they speed up interpreted code quiet a lot
<doko_> lool: thanks :)
<fabbione> pitti: chinstrap:~bcollins/vmnet.tar
<fabbione> doko: hey old man
<StevenK> doko: Many happy returns!
<pitti> that's even better, thanks fabbione 
<mvo> doko: happy birthday from me too
<pygi> oh, birthday!
<pygi> doko, happy birthday ^_^
<Riddell> pitti: yes, it is obsolete, Lure will tell you if it can just be deleted now
<pitti> Riddell: thanks; I killed it already
<Riddell> cool
<glatzor> mpt: Hello, have you already found the time to look at the user interface of displayconfig?
<mpt> glatzor, yes, sorry I haven't replied yet
<mpt> I had a couple of questions
<mpt> * Is this intended to replace gnome-display-properties?
<mpt> (and if not, why not?)
<cjwatson> mpt: the spec discusses that
<glatzor> mpt: I would like to. Mdz would like to have it as an advanced button.
<cjwatson> displayconfig-gtk
<mpt> oh, there's a spec?
<cjwatson> yeah, a gutsy target
<glatzor> mpt: http://wiki.ubuntu.com/DisplayConfigGTK
<mpt> ah
<mpt> I did skim that page, but I was looking for the screenshots so I didn't even notice it was a spec :-/
<pitti> doko: FYI, I fix libbcel-java-doc not to depend on libxerces2-java-doc, since the latter does not exist; ok with you? 
<glatzor> mpt: I came up with a redesign here recently: https://lists.ubuntu.com/archives/ubuntu-desktop/2007-May/001057.html
<pitti> doko: alternatively I can move libbcel-java-doc to multiverse, so that it becomes installable; what do you prefer?
<mpt> glatzor, I think we can handle the cases of one screen, two screens, and three screens all in the same window without it getting complicated
<mpt> and that would be far preferable to having three different UIs for those three cases
<mpt> glatzor, what happens in the window when you plug in an extra monitor? Does it appear in the list automatically?
<doko> pitti: hmm, maybe make it a recommends instead of a depends
<pitti> doko: right, I dropped it to Suggests:
<mpt> oh, nm, I should just read the spec first
<glatzor> mpt: that is not supported on all cards (hardware side) furthermore it is also not supported by X
<Mithrandir> glatzor: (yet)
<Mithrandir> it will be soonish
<glatzor> Mithrandir: Do you know when there will be a dbus interface roughly?
<Mithrandir> glatzor: I think X hotplug is 7.3 material, but it might be later.
<mpt> glatzor, so how are you supposed to set it up? Is there supposed to be a "Detect" button somewhere? Or do you need to restart the computer?
<glatzor> Mithrandir: I thought you were talking about emitting a device change signal.
<Mithrandir> glatzor: *shrug*; that's utterly trivial once all the other bits are in place.
<glatzor> mpt: We still use the xorg.conf for the configuration. So you have to restart your X server. I already send a signal to gdm to do this if you made any corresponding changes. So logging off should be sufficient.
<mpt> Ok, there needs to be a sentence to that effect in this window
<mpt> Otherwise people will stand there staring at it waiting while nothing happens
<glatzor> mpt: you get a dialog depending on the changes.
<glatzor> mpt: we can apply some changes instantly using xrandr
<mpt> I'm not talking about having changed settings, I'm talking about plugging in another display
<glatzor> mpt: Oh, the available screens are tried to guess from the hardware.
<tepsipakki> x server 1.3 supports output hotplug (=randr 1.2), it's just that only the intel driver supports that properly
<glatzor> mpt: If there is no screen attached to the output we just show it as disabled.
<mpt> glatzor, what do you mean by "the output"?
<glatzor> mpt: the output jacket of your graphics card.
<pitti> Riddell: can you please unseed strigi from the Kubuntu seeds as long as it (and the plethora of build deps and deps) are still in universe? 
<pitti> Riddell: I can do it as well if you give me your ok
<Riddell> pitti: why?  I hope to get it into main soon and the seeds should reflect what is wanted 
<pitti> Riddell: it generates a lot of clutter in anastacia, but I can try to ignore it
<glatzor> mpt: For example ATI cards with dual head support are detected by their pci string: it contains the term "Secondary"
<pitti> but in general, things should be seeded when they have MIRs
<mpt> glatzor, does that mean that because I might one day plug a USB monitor into one of my USB ports, this window needs to contain one disabled item for each of my USB ports?
<tepsipakki> usb monitor?
<glatzor> mpt: if there are any USB monitors: yes.
<glatzor> mpt: but luckily that is not the case
<mvo> tepsipakki: do you know is xrandr will send a XRRNotifyEvent if a additional monitor is pluged in?
<glatzor> mpt: We are just limited by the available technologies
<Mithrandir> mpt: I'd argue no, since USB is a general interface while your display connectors are hardly useful for anything but plugging in monitors.
<Mithrandir> iwj: any chance I could grab a bit of your time today to get some bits of dpkg svn merged into our package?
<mpt> I was confused by http://computing.kelkoo.co.uk/b/a/cp_114401_filter_interface_usb.html
<mpt> It looks like it's selling USB monitors, but apparently not
<cjwatson> woo, usplash console font handling fixed
<cjwatson> there goes a big load of bugs
<tepsipakki> mvo: no idea..
<Keybuk> cjwatson: oh aye?
<persia> mpt: There are USB video interfaces (I have one), but not yet monitors.
<tepsipakki> mpt: ah, they could have usb hubs in the m :)
<mpt> yeah
<tepsipakki> -" "
<mpt> heh
<Mithrandir> mpt: however, if you have a USB video interface with no connected monitor, showing it as disabled is fine.  IMO, at least.
<iwj> Mithrandir: Sure.  I haven't looked at the svn changes in detail.  Did you have any particular things in mind \/
<cjwatson> Keybuk: if you switch to graphics mode and back, the kernel doesn't save the previous console font for you - so the console-setup initramfs business to set the font early wasn't working
<iwj> s,\\/,?
<Keybuk> cjwatson: ahh
<cjwatson> Keybuk: fix is to get usplash to save the console font before switching to KD_GRAPHICS, and restore it after switching back to KD_TEXT
<cjwatson> bug 91422 and friends
<ubotu> Launchpad bug 91422 in console-setup "FEISTY: ctrl alt f1 terminal doesn't work with special characters (, ..)" [Undecided,Needs info]  https://launchpad.net/bugs/91422
<Mithrandir> iwj: the changes needed for lpia are in svn; I'm not sure of the exact set of commits we want to merge, but I could find it for you
<mpt> glatzor, is the "primary screen" the one on which the panels appear?
<iwj> Mithrandir: If you know what you're looking for then yes, sure.  If you point me at it I'd be happy to merge it in.  (It might be trivial.)
<glatzor> mpt: I would recommend to look at this screenshot: http://glatzor.de/filesink/allinone.png
<iwj> Or alternative I'm happy to do the digging.
<iwj> s/ive/&ly
<glatzor> mpt: this is what I am planing to upload soon.
<glatzor> mpt: yes. the primary screen is the default/main screen
<Mithrandir> iwj: if you'd like, please.  It should be mostly limited to dpkg-architecture and is a week-ish old.
<Mithrandir> iwj: anything mentioning "lpia" is interesting
<glatzor> mpt: the displayconfig can already handle unplugged primary screens by showing a move displayconfig dialog to this screen buttons on every screen.
<iwj> Mithrandir: OK, I'll take a look.  Do you have a cutoff date before which it definitely won't be there ?
<mpt> glatzor, that would be no use if you couldn't launch it in the first place :-)
<Mithrandir> iwj: anything older than May 15th should be uninteresting.
<Mithrandir> that should leave you with 30-odd commits to go through, I think
<glatzor> mpt: Displayconfig will also be used in the failed x session
<iwj> Mithrandir: Thanks, that should be NP.
<glatzor> mpt: furthermore you have to relay on the Window manager to not open the dialog window on the correct screen.
<glatzor> mpt: to not open the dialog on the wrong screen
<StevenK> iwj: If you're going to do an dpkg upload, I've noticed update-alternatives throwing a Perl warning. I just can't recall more details at this point.
<iwj> StevenK: I'll check my diff.  I might have missed a `my'.
<iwj> (The merge from Debian included turning warnings on.)
<Mithrandir> there's a slew of commits in Debian which fixes warnings too
<iwj> (And a concomitant coding style change.)
<iwj> Maybe we should just merge from the SVN head.
<iwj> I'll see what it looks like and decide.
<Mithrandir> I wouldn't mind
<mpt> glatzor, if you could rely on the window manager to do that, then half this problem would go away: you wouldn't need a list of displays, because each display could have its own settings window.
<glatzor> mpt: that is definitely a cool idea.
<mpt> Can you rely on Metacity to get it right, at least?
<glatzor> mpt: oh, but how to enable screens?
<glatzor> mpt: could be a little bit tricky :)
<glatzor> mpt: not with metacity, but on a lower level.
<mpt> glatzor, ah, so that's where the auto-detection is required, hmm
<mpt> glatzor, what do you mean by "on a lower level"?
<glatzor> mpt: and that is also where you depend on the hardware again. there is no guarantee that the output on the screen is actually visible for a human.
<glatzor> mpt: we cannot detect jammed outputs from the software side.
<mpt> "jammed"?
<mdz> tepsipakki: yay, no more xlibs-dev
<glatzor> mpt: with not working/broken configurations.
<mpt> oh
* mpt wonders how OS X gets away with it
* pitti jumps for joy: deb http://people.ubuntu.com/~pitti/langpacks/daily/gutsy/ ./
<mpt> Supporting a limited subset of displays, perhaps
<pitti> carlos: ^ thank you
<carlos> pitti: :-)
<carlos> cool
<StevenK> pitti: Yay!
<iwj> #
<iwj> Oops.
<pitti> "Parlez vous francais" anyone?
<pitti> Riddell: could you please test the brand new gutsy langpacks for KDE? (French and English)
<ssam> mpt, you can plug almost any display/projector into mac os x, and it will automagically enable it (though there is a button to tell it to redetect monitors)
<glatzor> mpt: You cannot prevent that the user chooses the wrong CRT, since many monitors identify themselves incorrectly. So you have to allow enforcing a configuration.
<mvo> pitti: app-install-data-ubuntu is uploaded, I have a small fix for g-a-i as well, do you want it too? or should I wait until the freeze is over?
<mpt> ssam, right, I wasn't wondering about the detection (any more), I was wondering how OS X doesn't have the problem with (as glatzor says) choosing the wrong CRT
<pitti> mvo: freeze hasn't even begun yet, so feel free
<mvo> pitti: heh :) ok, looks like I haven't catched up yet :)
<StevenK> Oh, that's right. I ought to get Tribe 1 for my birthday.
<Mithrandir> I think we should delay it by a day so I'll get it for mine
<mvo> Riddell: the new kde-guidance b-depens on python-kde3 3.17.2-1ubuntu2, but that does not appear to be in the archive yet? 
<StevenK> Mithrandir: I think I get it for mine due to timezones.
<StevenK> Mithrandir: But it seems we share a birthday.
<Mithrandir> StevenK: yes, we do
<Riddell> mvo: yeah, getting to it now
<StevenK> Yay me for forgetting that.
<mvo> Riddell: cool, thanks (no pressure, I was just wondering if it was intentional or not)
<dholbach> pitti: did you find somebody speaking french already?
* mvo goes for lunch now
<dholbach> mvo: enjoy
<glatzor> Riddell: I cleaned up the patches folder in the displayconfig bzr repository. The pathces now have got better names and there is a STATUS file to keep track of merges
<pitti> dholbach: nope; any popular language will do, it's just testing the new gutsy langpacks a bit before uploading
<pitti> dholbach: German looks good here for Gnome
<Riddell> glatzor: ok , cool.  I havn't heard from sime for a while so not sure what the best way is to just merge those upstream
<dholbach> pitti: ah ok
<Riddell> glatzor: probably keep pinging him and just merge them if he doesn't show up
<Riddell> pitti: sure
<pitti> dholbach: I'll just test Russian myself, I think, that will be fine; if a KDE guy tests some KDE packages, that should suffice
<pitti> Riddell: merci :)
<pitti> Riddell: Russian, German, and English looks good for Gnome; let's hope the best for KDE, too :)
* Starting logfile irclogs/ubuntu-devel.log
<pitti> carlos: ah, I had a look
<pitti> carlos: so, e. g. gnome-panel-2.0.mo is in language-pack-gnome-de-base_6.06+20070129_all.deb
<pitti> carlos: and also in the later update
<pitti> carlos: s/the/a/
<pitti> carlos: so the latest language-pack-gnome-de replaced the files in -base, and now they are gone from installations
<pitti> carlos: that at least explains why there is no gnome-panel-2.0.mo *at all* on an updated dapper
<pitti> carlos: I'm not sure whether the presence of the mo is due to me not cleaning up the source packages on import (for various reasons), or due to Rosetta dropping the .po files at some point in the updates tarball
<mpt> glatzor, replied to your original message
<carlos> pitti: I'm working on the DB to see whether we removed them because the files don't have any update since our last base package update (Last January)
<carlos> pitti: in which case it means is correct
<pitti> carlos: DB-wise it would be correct, yeah, then I need to always build the packages against their previous version instead of from scratch
<pitti> carlos: so AFAICS this should only affect dapper, since for edgy we didn't do a base upgrade
<glatzor> mpt: I am writing on my reply
<glatzor> mpt: macos shows the config dialog on each display?
<glatzor> mpt: So it cannot providing cloning/duplicating of screens?
<tepsipakki> mdz: yep, about time to get rid of it :)
<glatzor> mpt: ah, there is a mirror checkbutton. but how does this work on more than two monitors?
<carlos> pitti: sorry, I don't get you. Aren't we already doing that?
<pitti> carlos: IOW, I cannot just build dapper langpacks from your tarball, but update the existing ones with your tarball
<pitti> carlos: it's pretty clear to me now
<carlos> pitti: I have two kind of language packs
<carlos> a full one
<carlos> and updates based on that one
<carlos> dapper is doing update based on latest full export for Dapper which was on 2007-01-15
<pitti> carlos: right; somehow e. g. gnome-panel-2.0.po landed in an update pack after the base refreshment
<carlos> s/dapper is doing/launchpad is doing for dapper/
<pitti> and due to that I *always* have to ship gnome-panel-2.0 in the update packs
<carlos> that was what we tried to solve with January update
<carlos> pitti: don't you remember that?
<pitti> carlos: of course I do
<carlos> we did a full base update to restore some removed packages that were being exported by mistake from Launchpad
<pitti> but somehow the affected .po files still landed in the update packages afterwards
<carlos> pitti: then, does it mean it happen again?
<carlos> once we fixed it, if it lands to the packages, it means they should remain there...
<carlos> or we have a bug...
<pitti> I'm not sure when and where that originated, and I guess we don't have those old update tarballs any more
<pitti> carlos: anyway, I'll build the new ones based on the current ones to ensure that files will not get lost
<mpt> glatzor, with OS X mirroring multiple screens is not obvious
<mpt> you Option+drag one display onto another in the Arrange tab
<carlos> pitti: my question is
<mpt> The Arrange tab appears only on the primary display, not any of the others.
<carlos> would that produce that we have some Dapper users that lost .mo files like we had before January's update?
<mpt> glatzor, more details and screenshots at http://www.macinstruct.com/node/78
<pitti> carlos: if I built update packages just from your tarball now, yes, it would
<carlos> pitti: hmm, are you completely sure you didn't add those .mo files manually?
<carlos> pitti: you said you did it in the past
<carlos> and I wonder whether would be possible that we disabled it too late
<pitti> carlos: that's what I said; I nuked the existing update packages after the base refreshment of course
<pitti> carlos: but at some point they crawled into the daily update packages again
<carlos> ok
<pitti> so I'd think that *at some point* they have been part of the updated tarballs from you
<pitti> but I cannot say when
<pitti> (at some point after the base refreshment)
<carlos> pitti: are you able to provide me with a list of missing files?
<glatzor> mpt: by the way the new XRandR hotplug thing does not support multiple graphics cards.
<pitti> carlos: I think I could do that if you need them, yes
<pitti> carlos: I'll build good ones over lunch and then debdiff them
<carlos> pitti: well, that's the only way I could 'force' to get those files exported again
<carlos> pitti: either that or do another base update...
<carlos> although I would like to see why did we get this regression
<carlos> s/see/know/
<pitti> carlos: I don't think we actually need to do that, but let's keep the list for the future anyway
<glatzor> mpt: what does the "gather windows" button?
<carlos> pitti: well, if we don't export missing files, people using Dapper will see again some applications in English
<pitti> carlos: no, because I will build them using the existing packages in -updates
<carlos> oh
<glatzor> mpt: and how do you disable a monitor again on MacOS?
<carlos> so you get previous source in Dapper and will add the ones provided by Launchpad?
<pitti> carlos: right
<carlos> I see
<carlos> ok
<pitti> carlos: that's how I build them normally
<pitti> carlos: because it easily allows me to avoid updating packages which did not change at all
<mpt> glatzor, you turn it off, I guess.
<pitti> I just nuked them today to clean up rookery, but I restored them
<pitti> carlos: at some point I either need to rewrite langpack-o-matic from scratch, or we can build the source packages straight from Rosetta...
<carlos> pitti: good trick
<carlos> pitti: I would like to build packages from Rosetta directlyu
<carlos> but we are not yet there
<mpt> glatzor, "Gather Windows" moves all windows that are on other displays onto the display in which you click the button.
<mpt> So if a display stops working for whatever reason you can get the windows back.
<mpt> oh wait, cancel that
<mpt> aha
<mpt> It moves only the display settings windows from the secondary displays onto the primary display.
<mpt> actually, no (I'll get this right eventually)
<glatzor> mpt: the other way would make more sense.
<mpt> It moves the display settings windows from the other displays onto the display where you click the button.
<glatzor> that makes sense.
<glatzor> mpt: it is a funny idea to put the dialogs on the devices.
<mpt> indeed
<glatzor> mpt: but how does this work with cloned monitors?
<mpt> It's called "direct manipulation" ;-)
<mpt> glatzor, I don't know. If I had to guess, I'd guess that the display is cloned *except for* the display settings windows.
<glatzor> mpt: I think that this could actually be done using XRandR.
<mpt> cool
<glatzor> AFAIK It allows to clone only a part of the screen. But I don't know if it allows to exlcude a part :)
<mpt> Yeah, "clone everything except this window"
<mpt> That's what Linux people call ... violation of ... something
<mpt> "rampant layering violation"
<glatzor> but it is really strange that there is no disable screen button
<glatzor> mpt: "If you move icons from your main monitor to your secondary and then disconnect the secondary monitor, those icons may disappear. They will still be there when you have one monitor connected, but the way to get them back would be to highlight everything and then select "Clean Up Selection" from the View menu in the Finder, or select an "Arrange By..." also in the View menu in the Finder."
<glatzor> mpt: so they cannot handle disabled devices at all :)
<mpt> That can't be true, because then you'd lose entire windows
<mpt> hmmmm
<mpt> I agree that rearranging icons when you lose a display sucks
<glatzor> mpt: Apple does not always to the things in the right way too :)
<glatzor> mpt: on GNOME the situation is even wore since the desktop is always oriented to the upper left.
<mpt> glatzor, I know, sometimes Apple does things very badly
<glatzor> mpt: so if you have got a screen left of your main screen, the icons would show up there
<mpt> oh, that's not good
<mpt> Nautilus bug?
<glatzor> mpt: I don't know.
<glatzor> mpt: perhaps intended.
<glatzor> mpt: by the way I replied on the list.
<mpt> Ah, I knew I'd read about this before: "Disconnect the external display, and the right thing will happen, where by 'right thing' I mean that any windows which were open on the no-longer-available display will be moved to the internal display, and resized, if necessary, to fit."
<mpt> So it moves+resizes the windows automatically, just not the icons
<glatzor> that is cool.
<glatzor> oh I haven't tested this with XRandR yet.
<pygi> pitti, around by any chance?
<pitti> pygi: just back from lunch
<pygi> oh, oki :)
<pygi> wanted to bug about sponsoring, but it seems pochu created the same package, and somebody is already sponsoring for him
<hunger> Just got this error upgrading: /var/lib/dpkg/info/xserver-xorg.postinst: 2197: Syntax error: "then" unexpected (expecting "fi")
* pygi will have more packages needing sponsors soon
<pitti> tepsipakki: ^
<StevenK> Twitch. Line 2197?
<asac> pitti: welcome back ... dapper build done?
<pitti> asac: yep
<asac> pitti: cool ... everything prepared for the diff.gz only arrival on edgy/feisty?
<pitti> asac: so, let me pre-publish this
<asac> pitti: sure ... let me know
<pitti> asac: hold on
<pygi> mvo, awake?
<mvo> pygi: hello, yes
<gnomefreak> hunger: it should be fine i dont think you will lose X even on restarting X
<pitti> asac: ready
<asac> pitti: k
<hunger> gnomefreak: I am not planing to do that;-)
<gnomefreak> hunger: i dont think it will hurt anything since your old versions are still installed ill try it in a bit ;)
<BenC> pitti: chinstrap:~bcollins/vmnet.tar can be dropped in place too
<pitti> BenC: great, thanks!
<BenC> pitti: that's for ws6
<pitti> BenC: btw, does linux-backport-modules still make sense, or is that merged into linux-ubuntu-modules?
<pitti> BenC: ah, I see; I still have 5.5 (no license for 6)
<BenC> pitti: it does, but I haven't updated it for 2.6.22 yet
<BenC> pitti: go ahead and grab ws6 with temp key, and I'll get you a perm one
<pitti> BenC: ok; the metapackages are currently uninstallable, that's why I wondered
<BenC> pitti: doh, right, guess I should get that uploaded today
<pitti> BenC: I'll shove it through NEW quickly once it arrived
<asac> pitti: all uploaded
<fabbione> cjwatson: what was the magic to boot an alternate cdrom and do a netinstall? I have a machine that cannot do PXE and the cdreader is.. hmmm flaky :)
<pitti> carlos: got it: http://people.ubuntu.com/~pitti/langpacks/dapper-updates-incomplete.txt
<pitti> carlos: I have a good set of dapper-proposed packages now
<cjwatson> fabbione: you'll need to boot /install/netboot/ubuntu-installer/i386/linux with /install/netboot/ubuntu-installer/i386/initrd.gz as the initrd; isolinux.cfg isn't set up to help you
<fabbione> cjwatson: ok thanks.. 
<pitti> BenC: hmm, the sparc metapackages are not installable either; any idea why?
<cjwatson> pitti: I don't think linux-ubuntu-modules built for sparc
<cjwatson> https://launchpad.net/+builds/+build/342882
<pitti> cjwatson: ah, that would be it
<carlos> pitti: that's a lot of files...
<carlos> pitti: thanks, I will take a look once I'm done with lunch
<Hobbsee> hi all!
<pitti> carlos: as I said, it's not particularly urgent
<carlos> pitti: sure, but i would like to know what's going on
<BenC> lum didn't build for ia64 or sparc
<BenC> missing header, I can reupload that today too
<cjwatson> Keybuk: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/118561 - is it possible that when 'modprobe loop' returns, /sys/block/loop* won't be there yet?
<ubotu> Launchpad bug 118561 in casper "[Gutsy]  Kubuntu liveCD 20070603 doesn't boot" [Undecided,Unconfirmed]  
<cjwatson> the earlier errors make me suspicious as well though
<Keybuk> cjwatson: it's both possible and likely
<Keybuk> it tends to bite dual-core systems more than single, obviously
<Keybuk> they race better
<cjwatson> evand: are you using dual-core?
<Keybuk> it also could be a sign of a missing udev, of course
<Keybuk> given the number of device errors
<evand> cjwatson: yeah, core 2 duo
<BenC> cjwatson: how many loop devs does livecd use?
<Mithrandir> BenC: one, typically.
<BenC> I recall a bug early in 2.6.22 where only one loop dev showed up, but I thought it was fixed
<cjwatson> BenC: glob expansion's failing, so there aren't any there at all in this case
<Arby> cjwatson: anymore info I can supply for that bug (I'm the reporter)?
<cjwatson> Arby: from the shell, if you wait for a bit, is /sys/block/loop0 there?
<cjwatson> whoa, here
<cjwatson> 'modprobe loop' on gutsy leaves no /sys/block/loop*
<evand> indeed, I just noticed that as well
<BenC> let me find this bug
<Arby> not that I've seen, it drops to an initramfs prompt and just sits there.
<Keybuk> looking
<Keybuk> confirmed
<Keybuk> loading the loop module creates no devices
<shawarma> What should it leave there? Loading the loop driver just provides the hooks for creating the device nodes.
<cjwatson> Arby: I meant if you run ls to check, but it looks like we've confirmed it outside the initramfs
<Keybuk> (nothing in sysfs, no uevent --> iz kernel boog)
<shawarma> Or should it create some that we bind to stuff afterwards?
<Keybuk> shawarma: historically it sets up 8 devices for use
<shawarma> Keybuk: Oh, I see.
<Arby> cjwatson: ah, OK /sys/block was there, beyond that I don't remember and I don't have the machine here
<Arby> (at work)
<Arby> this is all a bit beyond my skills to be honest but I do what I can.
<Keybuk> hmm
<shawarma> modinfo -p:
<shawarma> max_loop:obsolete, loop device is created on-demand
<Keybuk> max_loop:obsolete, loop device is created on-demand (int)
<Keybuk> heh, jinx
* cjwatson reassigns the bug to the kernel
<shawarma> :)
<cjwatson> er, seriously? how do I remand it? :)
<cjwatson> demand
<Keybuk> cjwatson: losetup
<Keybuk> losetup -f does indeed make a /dev/loop0 for me
<cjwatson> ouch
<BenC> yeah, lkml claims "not a bug" :)
<StevenK> Hrrm. How can I get make to report which rule it's jumping into? I'm trying to trace a build failure and want to know where in debian/rules to start shovelling.
<Keybuk> BenC: the workflow is not immediately obvious to me
<cjwatson> StevenK: make -d?
<Keybuk> LOOP=$(losetup -f)
<Keybuk> losetup $LOOP ...
<Keybuk> ?
<cjwatson> unfortunately busybox's losetup doesn't support -f, so this will take a bit of work
<Keybuk> hmm, this isn't working now
<Keybuk> now it says "could not find any device /dev/loop#"
* Mithrandir claims the kernel should stop breaking published interfaces.
* Hobbsee claims the kernel should stop breaking.  period.
* Hobbsee runs away from BenC 
<ompaul> Hobbsee, you can claim anything you want, you just can't substanciate your claims that is all ;-)
<BenC> Hobbsee you can't escape my next kernel upload :P
<Hobbsee> BenC: oh dear.
<Hobbsee> BenC: but my wifi appears to be broken on this one, so...
<Hobbsee> it may well be pebkac, i havent found the problem yet
* ShinyMonster wants some shiny to install....
<ShinyMonster> must...have...shiny....
<carlos> pitti: filed as https://bugs.launchpad.net/rosetta/+bug/118638
<ubotu> Launchpad bug 118638 in rosetta "Language pack export lacks some files that were exported before" [Undecided,Unconfirmed]  
<pitti> carlos: I'll subscribe, thanks
<ogra> StevenK, thanks for taking the fuse merge
<StevenK> ogra: No problem. It was ... fun. I have scars. :-)
<ogra> heh
<dholbach> did anybody experience a xserver-xorg postinst error in the last update?
<ShinyMonster> yes
<StevenK> I saw that here about an hour ago.
<pitti> <hunger> Just got this error upgrading: /var/lib/dpkg/info/xserver-xorg.postinst: 2197: Syntax error: "then" unexpected (expecting "fi")
<pitti> <pitti> tepsipakki: ^
<dholbach> ah ok
<dholbach> right
<pitti> dholbach: but no answer so far; if you feel like fixing that, go ahead :)
<dholbach> right :)
<tepsipakki> pitti: gah
* pitti hugs tepsipakki 
* tepsipakki hits himself
<siretart> Keybuk: you said last week that you have a mdadm merge in the pipe. do you have an ETA for that? c.f. bug 87745
<ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  https://launchpad.net/bugs/87745
<Keybuk> siretart: waiting on an LVM/devmapper patch from SuSE to fix known bugs there
<Keybuk> err, that bug appears to be entirely unrelated to mdadm, no?
<siretart> Keybuk: see https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/87745/comments/5
<ubotu> Launchpad bug 87745 in lvm2 "Root fs on LVM fails to boot" [High,Confirmed]  
<Keybuk> siretart: yeah, but since the bug was reported about feisty, that's probably not the problem here <g>
<Keybuk> (yes, lvm-on md won't work in gutsy right now)
<siretart> well, yes, thats the problem I'm experiencing with my workstation machine at home
<Keybuk> so mdadm
<Keybuk> the merge is pretty trivial, and won't help
<Keybuk> there's a patch from SuSE which is pretty trivial, that lets us have a 65-mdadm.vol_id.rules which will run vol_id on complete md devices
<Keybuk> (as apposed to partially assembled ones)
<Keybuk> so that solves the "lvm issue"
<siretart> well, why not upload that to let folks boot again?
<Keybuk> the non-trivial bit is working out what to do about running mdadm on block devices identified as linux raid
<siretart> hm
<Keybuk> because it wouldn't let them boot
<Keybuk> since mdadm would never be run :)
<Keybuk> right now, there's mdadm, mdrun, and a complicated initramfs script
<siretart> my raid devices are assembled correctly
<Keybuk> depending which way the neutrinos come in, you may get one or more in random orders
<Keybuk> I'd kinda like to understand this, and just have one that works
<siretart> sure
<tepsipakki> umm, how to find the "line 2197" from the postinst.. does it count commented/empty lines?
<Keybuk> help understanding how to run mdadm would be most welcome
<jdub> http://www.microsoft.com/presspass/press/2007/jun07/06-04XandrosPR.mspx
<jsgotangco> jdub: ick
<sn0> eep @ xandros
<jsgotangco> i guess that's why one of the people i know left recently heh
<glatzor> mpt: do you want a feisty package of the latest displayconfig?
<Keybuk> jsgotangco: they looking for jobs? :)
<jsgotangco> i can ask heh
<Keybuk> www.ubuntu.com/employment
<zul> heh its corel all over again
<Keybuk> isn't Xandros what's left of Corel?
<zul> yep
<jsgotangco> yep ming poon is still pretty much tech lead on it i believe
<BenC> So is bug #118561 really being considered a kernel bug, or is it something that d-i/ubiquity needs to handle?
<ubotu> Launchpad bug 118561 in casper "[Gutsy]  Kubuntu liveCD 20070603 doesn't boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118561
<BenC> this is the loop problem
<cjwatson> BenC: I punted it back to casper, sounds like it's our problem
<BenC> cjwatson: ok, thanks
<cjwatson> working on enhancing busybox's losetup now
<cjwatson> this is a bit weird, though, after a 'sudo losetup -f':
<cjwatson> $ sudo losetup /dev/loop0
<cjwatson> /dev/loop0: [3002e6bc] :268435508 0R) offset 805321200, undefined encryption
<cjwatson> loop: can't get info on device /dev/loop0: No such device or address
<cjwatson> maybe that's losetup's fault
<cjwatson> mm, looks like it should be zeroing loopinfo before it passes it in
<tepsipakki> pitti: I found the bug in xorg, it was an elif-line appended to the previous one :/
<tepsipakki> hunger: thanks for telling about the xserver-xorg postinst bug, and sorry
<cjwatson> BenC: actually, no, I don't get this. 'sudo losetup -f' works once, but after I losetup a file onto that, 'sudo losetup -f' doesn't work again
<BenC> cjwatson: that was the bug report, and according to the thread, it's userspace breakage...but I'm not sure yet where that is broken
<BenC> could be mount and losetup
<cjwatson> all losetup does is walk through /dev/loop* statting them
<cjwatson> if the device node isn't there, it won't worrk
<cjwatson> looks like you need to mknod the devices yourself now :-/
<cjwatson> some discussion in the thread seems to indicate that it's supposed to create one extra device though, so that you don't need to do that
<BenC> cjwatson: a work around might be to add "options loop max_loop=8" to get the old behavior
<BenC> but that sets a hard max limit on loop devices too
<cjwatson> yeah, tolerable on the live CD though
<Hobbsee> BenC: you wouldnt happen to know if intel 3945 cards were touched in the last kernel update would you?  I cant seem to modprobe it to get it flashing - modprobe ieee1394 comes back without errors, but doesnt seem to activate the card either.
<cjwatson> thanks, I think I might do that for now
<StevenK> I thought 1394 was Firewire
<BenC> Hobbsee: wasn't touched...are you sure you have lrm for -16 installed?
<BenC> cjwatson: ok
<Hobbsee> BenC: gutsy.  -6.  yes, both the ubuntu modules and the restricted modules
<Hobbsee> BenC:  i havent tried a reboot etc, yet - only modprobing the cards after the ubuntu modules came in
<BenC> has to be done when lrm is also installed, because it requires the ipw3945d-`uname -r`
<BenC> you could try "modprobe -r ipw3945; modprobe ipw3945" and see if that fixes it
<cjwatson> BenC: we don't seem to be up-to-date with the patch in http://lkml.org/lkml/2007/3/29/47; specifically we're missing the if (!loop_find_dev(lo->lo_number + 1)) loop_init_one(lo->lo_number + 1); in lo_open
<cjwatson> and the loop_find_dev function
<Hobbsee> BenC: okay, where's the duncecap.  
<Hobbsee> BenC: too many damned numbers.     loaded the wrong module.  sorry for the noise
<BenC> np :)
<BenC> cjwatson: there's a lot of back and forth about how to handle that patch among others
<BenC> I'm still digging through the thread
<Keybuk> it does seem a bit broken
<Keybuk> "mknod the device yourself" is very 1980s
<iwj> OK, here's a question: I want to merge dpkg from svn and it looks like pushing svn trunk into gutsy is the right thing.  I what form should my package take (particularly, which version number) to avoid confusing MoM and similar tools ?
<iwj> Actually constructing the package is easy - I can do that bit.
<Keybuk> iwj: it depends
<iwj> Go on ...
<Keybuk> if a new version is uploaded to Debian, do you want that to be sync'd or merge'd ?
<Keybuk> or do you want our dpkg to be a permanent fork, only merged from svn?
<iwj> Merged.
<Keybuk> then I would suggest something like
<Keybuk> dpkg 1.14.4+svn20070304-0ubuntu1
<iwj> We might later choose to either merge from somewhere in svn, or to merge from sid.
<Keybuk> where 1.14.4 is the last Debian release
<StevenK> svn20070604, surely?
<iwj> svn<whatever>, right :-).
<Keybuk> StevenK: I just made up a number without looking at the date :p
<StevenK> Keybuk: :-P
<Keybuk> you could also use
<Keybuk> 1.14.5~svn20070604-0ubuntu1
<Keybuk> where 1.14.5 is the next version to be released
<Keybuk> depending whether you want the version number to mean "1.14.4 and some more bits" or "the work towards 1.14.5 taken from svn at this date"
<Keybuk> both would work
<iwj> And single tarball is still fine ?  OK.
<iwj> .4+ or .5~> I don't think there's much of a distinction in this case.
<Keybuk> the -0ubuntu1 makes it clear to the sync and merge stuff that this is something done in ubuntu
<iwj> Right, OK.
<Keybuk> "the first ubuntu revision of an upstream version that's not packaged in Debian yet"
<pygi> dholbach, you have some time? I wanna bug you to try out something :)
<dholbach> pygi: a tiny little bit only
<pygi> dholbach, oh, I'll bug you later then :)
<dholbach> ok thanks :)
<iwj> StevenK: If you're still seeing warnings from dpkg-foobar please do c&p one and let me know.  Any remaining warnings that you see with 1.14.4ubuntu2 are not fixed upstream so it would be good to know about them.
<Hobbsee> iwj: (he's gone to bed)
<cjwatson> BenC: do you have any idea why keyboard input in gutsy when using vmware might be very much slower than in feisty?
<cjwatson> it takes something like half a second to a second to process each keypress
<iwj> Mithrandir: Let me know if dpkg 1.14.4+svn20070602r802-0ubuntu1 doesn't sort out your lpia problem.
<BenC> cjwatson: no idea why. I hadn't noticed that in my vmware install, but mine is just console
<pitti> tepsipakki: recent xorg upload introduced a dependency xorg-docs for xorg, but that's in universe; there needs to be either a MIR or dropping the depends to a suggests or so
<pitti> tepsipakki: NB that a MIR needs to be accompanied by one for xorg-sgml-doctools, since that's a build dep
<bryce> pitti, hmm, I don't think there's a reason we need xorg-docs as a depends for xorg.  
<geser> Mithrandir: please give-back tntdb on all archs. Thanks.
<iwj> bryce: It seems odd that Debian introduced it as a Depends.  Until we know why I'd be cautious - it might be something to do with the /usr/X11R6 transition.
<bryce> true
<pitti> bryce: we need to get xorg installable until tomorrow, so for the moment I'd prefer loosening the dependency (if it doesn't break anything)
<bryce> ok
<bryce> pitti, this appears to be the entry for when xorg-docs was added:
<bryce>  * Add xorg-docs to the xorg package dependencies. There's some very usefu
<bryce> l
<bryce>     manpages in there, among other things.
<bryce>  -- David Nusinow <dnusinow@debian.org>  Sun,  4 Mar 2007 15:38:57 -0500
<pitti> bryce: I looked at that changelog entry, that's why I'd prefer the 'drop to suggests' approach for now
<pitti> bryce: also in terms of CD size increase
<pitti> bryce: it's only one MB of course, but it still matters for us
<bryce> Suggests or Recommends?
<pitti> bryce: main Recommends: should be resolvable in main (since our tools install them by default), so Suggests:
<bryce> pitti, would you mind reviewing this change?  This is the first change I've done for the xorg package:  http://people.ubuntu.com/~bryce/Uploads/
<pitti> bryce: what's the change exactly? there's no new xorg package there
<pitti> bryce: also, can you please put a debdiff there for me to review? (for the packages you want to modify)
<pitti> bryce: oh, I see, you created xorg 1:7.2-3ubuntu2
<pitti> bryce: that already exists, though (tepsipakki uploaded it a few hours ago)
<bryce> debdiff posted
<pitti> bryce: looks fine, when you apply that to the -3ubuntu2 in the archive
<pitti> bryce: <nitpick>the changelog could give the rationale, something like 'because it is in universe and we need to save CD space' or so</nitpick>
<bryce> ok
<bryce> hmm, according to apt-cache madison, 1:7.2-3ubuntu1 is the latest, so 1:7.2-3ubuntu2 should be the next number, no?
<pitti> bryce: apt-get update :)
<mdz> shawarma: was it you who mentioned network-manager-openvpn to me at UDS?
<pitti>       xorg | 1:7.2-3ubuntu2 | http://archive.ubuntu.com gutsy/main Sources
<shawarma> mdz: I may very well have.
<mdz> shawarma: my impression was that we should Just Do It
<bryce> aha
<shawarma> mdz: yes?
<shawarma> mdz: I've got an long overdue update on my TODO list, but the current version should (mostly) work.
<mdz> shawarma: is there work to be done on the server side?
<shawarma> mdz: Well... If the server doesn't push DNS settings, the client acts... well, funny.
<mdz> what about -vpnc?
<shawarma> mdz: That's even better.
<shawarma> mdz: I'm working on updating the UI to work with some of the new features in vpnc 0.4.
<pitti> bryce: I need to go now, so I cannot sponsor this, sorry
<shawarma> mdz: (mainly being able to use the encoded passwords from Cisco's pcf files)
<mdz> shawarma: sounds like a project for a later date then
<mdz> openvpn seems like it might be a nice ubuntu server + ubuntu clients solution
<shawarma> Oh, definitely.
<shawarma> mdz: this Ebox thing does VPN, too.
<mdz> shawarma: what's the backend?
<shawarma> mdz: Openvpn.
<mdz> oh, neat
<shawarma> mdz: I've got an e-mail to you about that's almost done.
<shawarma> mdz: Give me a minute.
<mdz> shawarma: if it works in the version we ship, we should definitely consider shipping the client side as well
<shawarma> mdz: Sure, that makes perfect sense.
<mdz> shawarma: I'll read your email when it comes and then we can talk further tomorrowish
<shawarma> mdz: Oh, I've got tomorrow off.
<shawarma> mdz: Constitution day.
<mdz> aha
<mdz> I don't have dk holidays in my calendar yet
<shawarma> There. Added to my calendar.
<shawarma> mdz: Mail sent.
<tepsipakki> pitti, bryce, iwj: xorg depends on xorg-docs because "There's some very useful manpages in there, among other things."
<tepsipakki> but I can upload a new version
<tepsipakki> moving the dep to Suggests as in bryce's patch
<bryce> cool, thanks
<tepsipakki> we can sort that out later
<tepsipakki> xorg-docs, that is
<bryce> btw, I'm also looking at another recent issue reported
<tepsipakki> shoot
<bryce> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/118661
<ubotu> Launchpad bug 118661 in xorg "[gutsy]  xserver-xorg (1:7.2-3ubuntu1) configure error" [Undecided,Confirmed]  
<tepsipakki> that's fixed in -3ubuntu2 :)
<bryce> ahh, ok cool
<bryce> closing as fixed
<tepsipakki> uploaded
<tepsipakki> now home ->
<bryce> cya
<ashrack> hello! I was just wondering how come with the latest feisty kernel the NVIDIA NFORCE2 PATA driver has been disabled from the new Serial ATA (prod) and Parallel ATA (experimental) drivers' and the old ATA driver is now used again AMD and nVidia IDE support (BLK_DEV_AMD74XX).
<keescook> Keybuk: can you confirm bug 118164?  I'm shy to add any deps to udev, but it looks correct.
<ubotu> Launchpad bug 118164 in udev "Missing udev dependency: adduser" [Undecided,Confirmed]  https://launchpad.net/bugs/118164
<Keybuk> keescook: yup, seems reasonable
<keescook> Keybuk: okay, I'll commit it, thanks.
<Keybuk> commit?
<keescook> commit meaning "stuff it into the package and upload it"
<Keybuk> :)
<Keybuk> was just checking
<Keybuk> keescook: there are LP branches of udev that I've never been able to eradicate
<Keybuk> (which I don't use)
<keescook> heh.  yeah, I didn't think there was a vcs for it.  you scared me for a second.  :)
<Keybuk> I've not found a model of source-package-in-vcs that I'm happy with
<Mithrandir> iwj: thanks, I'll take a look.
<Mithrandir> geser: given-back
<sabdfl_> in a bash script, is it easy to read a word from the console?
<sabdfl_> i'd like to read a variable, and pre-seed it with a default
<sabdfl_> like:
<sabdfl_> What is your username? [mark]  _
<sabdfl_> enter would return "mark"
<Mithrandir> DEF="mark"; printf "What is your username? [$DEF]  " ; read FOO ; if [ -z "$FOO" ] ; then FOO="$DEF" ; fi
<pygi> sabdfl_, use read and see if input is empty?
<pygi> meh :P
<kylem> heh. Mithrandir is faster than i am.
<pygi> Mithrandir, :)
<sabdfl_> thanks Mithrandir, pygi
#ubuntu-devel 2007-06-05
<calc> is the alternate i386 image the easiest way to install gutsy at the moment, looks like the other images are oversized
<calc> i bought my laptop today, ended up getting a Toshiba A205-4577 Core 2 Duo 1.73/533, 1GB RAM, 160GB HD, Intel 950 Video, etc
<calc> was only $750 USD, not too bad
<calc> i'll probably upgrade it to 2 or 4GB ram
<calc> hmm $70 for 2GB vs $248 for 4GB, i'll probably stick to 2gb, lol
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Starting logfile irclogs/ubuntu-devel.log
<Hobbsee> morning pitti!
<pitti> Good morning
<thully> I'm interested in getting involved in the testing/development of Gutsy, but I only have one system.  What setup do the developers recommend for testing in this case?
<pitti> thully: then you should definitively run gutsy
<jsgotangco> yay
<pitti> thully: it's relatively tame right now
<thully> OK
<thully> I just see all the warnings on the website and fear major breakage of the "can't start X" or "can't use networking" variety...
<thully> What about virtualization?  Is that recommended or not as a test environment...
<Hobbsee> thully: doesnt pick up hardware bugs, often.  but it can be used
<Hobbsee> mmm...x breakage...
<thully> I actually have a MacBook, so I'm either thinking of doing either Gutsy in Parallels/VMware or a dual-boot w/OS X (need some kind of backup OS if running Gutsy as primary)
<Hobbsee> dual boot works fine.  or tripple...
<thully> I don't really want Windows - that's why I went Mac after I got frustrated w/ Ubuntu a long time ago...
<Hobbsee> i was thinking of dual booting with feisty - not windows
<thully> I see... I do have limited HD space, though...
<Hobbsee> how much?
<Hobbsee> it's only going to take <10gb per release
<Hobbsee> in fact, i think it's <5, iirc
<Hobbsee> hi Fujitsu 
<thully> Only a 60GB drive... 
<racarr> The worst breakage in gutsy for me is a new debug message in glib in regards to not calling g_thread_init before everything else glib
<racarr> so now everytime I go through a build process that uses gconftool I get spammed.
<racarr> :P
<Fujitsu> Hi Hobbsee.
<thully> does anyone know what group is dealing w/Mac Intel support for the release?  I know there are a few issues in Feisty I'd like to see fixed by gutsy final
<Hobbsee> anyone who's interested in it, i suspect
<jsgotangco> i use a macbook but only use it for stable releases so its osx+parallels
<thully> so, you're running in parallels?
<jsgotangco> on the macbook yeah, im currently using an x86 laptop
<jsgotangco> err toshiba rather
<doko> pitti: internal libwpd is temporary, fix is already submitted.
<Fujitsu> Is the new g-p-m doing crazy stuff for anybody else? It estimates that i have 10 minutes of battery life remaining all the time, and tells me that my battery is 'invalid' every time I log in.
<pitti> doko: ah, cool
<jsgotangco> Fujitsu: gutsy?
<Fujitsu> jsgotangco: Right.
<RAOF> Fujitsu: I might go and do a dist-upgrade with my coffee (via the "uniwide" wireless, which should really be named "unispotty"), I'll check if I see that.
<Fujitsu> RAOF: Heh. UNSW is huge; you can't expect them to have good coverage.
<jsgotangco> illknow in a minute (currently updating)
<RAOF> Fujitsu: Then they shouldn't call it "UniWide" :P.
<Fujitsu> RAOF: True.
<StevenK> They could call it UniWide, but only if they sprang for enough APs.
<thully> I thought of that (Parallels), as there are still quite a few annoying hardware issues running native on the MacBook (the trackpad+wireless signal probably the biggest issues)
<RAOF> Or maybe the maths department would let me actually connect the laptop to the network.  But that'd be asking too much, obviously :(
<StevenK> RAOF: But then it might do something evil, like send packets!
<RAOF> Grr.
* RAOF fumes of to Coffee on Campus for coffee & network connection.
<StevenK> At least your uni doesn't block outgoing port 22.
* Fujitsu laughs at StevenK.
<StevenK> You can't laugh, you aren't even at uni.
<Fujitsu> Mrh.
* StevenK keeps bending gluck.d.o to his will.
<pitti> doko: latest OO.o introduced some build deps, like portaudio; not good...
<pitti> doko: portaudio needs jack, jack needs type-handling and freebob, and we don't really want all of those
<doko> pitti: ok, building with the internal copy again
<pitti> doko: thanks
<pitti> doko: stlport4.6 build dep also seems to be new; could it also work with stlport5.1, which is in main?
<doko> pitti: not in feisty (crash after viewing a slide show in full screen mode)
<pitti> doko: ok; in this case, promoting 4.6 to main might be better, WDYT?
<tepsipakki> pitti: the xorg-docs dependancy will be changed to Recommends in Debian
<tepsipakki> not that it helps us
<doko> pitti: let me check this first, I'll need a new upload anyway
<pitti> tepsipakki: ah, good
<pitti> hi thekorn 
<tepsipakki> pitti: can Recommends packages be from universe?
<pitti> tepsipakki: no, they shouldn't
<pitti> tepsipakki: it just means that the -docs package really doesn't ship paths, files, etc. which xorg needs
<thekorn> hi pitti 
<tepsipakki> pitti: ok, so either we keep the delta or include xorg-docs in main?
<pitti> tepsipakki: having it in main is ok, but I'd really like to keep it off the CDs
<pitti> tepsipakki: and the set of Recommends: packages should be closed in a seed
<tepsipakki> pitti: ah, ok
<tepsipakki> so delta it is :)
<pitti> i. e. all packages that are recommended: in desktop etc. should be in desktop
<pitti> tepsipakki: it's most likely not the only delta in xorg anyway, I figure? :)
<tepsipakki> no, that can probably never be synced :)
<Nafallo> tepsipakki: and you smile? ;-)
<tepsipakki> although most of the changes should be merged in git.d.o eventually
<tepsipakki> Nafallo: always!
* Nafallo is a quite happy guy aswell :-)
<tepsipakki> Nafallo: btw, it was about xorg the metapackage :) Rest should be more or less syncable
<Nafallo> hehe
<Nafallo> nice
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy main frozen for Tribe-1
* Hobbsee waves
* RAOF waves at Hobbsee
<ajmitch> hi Hobbsee 
* Fujitsu waves at Hobbsee on the way to TAFE.
<Hobbsee> :
<Hobbsee> )
<glatzor> morning Riddell, could you please point me to your packaging repository for guidance? I would like to fix a patch and include another one.
<doko> pitti: OOo apparently needs your approval
<pitti> doko: ooh, stlport5.1 works? nice
<doko> pitti: I didn't test, but according to the changelogs this might be fixed
<mvo> Riddell: guidance-backends currently depends on python-kde3. I think that dependency is not required, AFAICS there is no gui-code in that package
<glatzor> hello mvo!
<mvo> hey glatzor
<pitti> cjwatson: do we have a bug about the broken gfxboot? I'd like to milestone it for tribe-2
<tepsipakki> pitti: its broken?
<pitti> tepsipakki: yes, the new syslinux doesn't get along with the current gfxboot
<tepsipakki> grrr
<pitti> so now we have the old syslinux screens again
<tepsipakki> I tested it
<pitti> (just parroting, cjwatson did the workaround yesterday)
<cjwatson> tepsipakki: yes, I told you about it the other day
<cjwatson> it doesn't work at all, even in the test suite for me
<cjwatson> are you sure you were using the new isolinux.bin?
<cjwatson> pitti: no, no bug
<pitti> cjwatson: ok, I'll create one
<cjwatson> pitti: ubiquity upload coming now to fix a few bits of critical breakage, and one tweak to stop mounted volumes being visible on the desktop
<pitti> oh, I just had ubiquity crash on me when pressing the 'advanced' button in the summary
<pitti> I didn't report it yet
<cjwatson> that would be one of the bits of critical breakage :)
<cjwatson> Evan fixed that, I believe; the fix looks plausible for that anyway
<pitti> yay :)
<cjwatson> if it was a crash mentioning get_summary_device
<cjwatson> btw, is it just me, or are fonts a little bit bigger in gutsy all of a sudden?
<pitti> cjwatson: you mean smaller?
<pitti> cjwatson: for many people they are too small, and I was just going to follow seb128's advice and bump the default font size
<Mithrandir> I think they might be back to normal size again, yes.
<cjwatson> they're noticeably bigger for me
<pitti> on the live system they are too small
<cjwatson> oh, yes, I've noticed that on different hardware too
<pitti> on my desktop I fixed them manually a while ago
<cjwatson> I assumed font selection had gone a bit nuts
<cjwatson> powerpc laptop upgraded from feisty => bigger, amd64 desktop running live CD => smaller
<tepsipakki> cjwatson: ok, I missed that then.. pretty sure I did try the new .bin :(
<tepsipakki> cjwatson: where were the tools again, I'll look at it asap
<cjwatson> http://people.ubuntu.com/~cjwatson/tmp/gfxboot-test.tar.gz
<cjwatson> tepsipakki: I was wondering if the new hooks in syslinux needed a new gfxboot package, and was looking at merging that from kanotix
<cjwatson> tepsipakki: it can wait until after tribe-1, imo - I can just tell cdimage to use the isolinux.bin from feisty
<pitti> tepsipakki, cjwatson: can I assign bug 118744 to either of you?
<ubotu> Launchpad bug 118744 in gfxboot "no gfxboot in gutsy with new syslinux" [High,Confirmed]  https://launchpad.net/bugs/118744
<cjwatson> sure
<tepsipakki> I'll subscribe myself too
<pitti> tepsipakki: I sub'ed you already
<tepsipakki> pitti: right, I wondered why it asked me if I wanted to unsubscribe from it :)
<pitti> cjwatson: according to seb128, gnome-settings-daemon uses the screen DPI now for the font points->pixels calculation; no idea what it used before, but this explains the hardware dependency
<cjwatson> pitti: gnome-settings-daemon seemed to crash on the live CD, which might explain something too
<pitti> hm, not for me
<glatzor> mvo: whoa. locations support is nearly complete
<mvo> glatzor: ROCK!
<glatzor> mvo: perhaps not nearly ... But I started coding :)
<glatzor> mvo: the guidance backend is really nice
<dholbach> hiya
<mvo> hey dholbach!
<dholbach> hey mvo
<glatzor> mvo: is pickle overkill for storing the locations?
<pitti> dholbach: any idea why the logout dialog needs 30 seconds to appear?
<dholbach> no idea
<glatzor> morning dholbach
<dholbach> hi glatzor
<Fujitsu> pitti: It's quietly telling you to use the CLI instead.
<dholbach> pitti: I'll try if downgrading gnome-session / gnome-power-manager makes it work and go from there
<dholbach> Fujitsu: great solution! :-)
<mvo> glatzor: no, that is probably fine. but its not human readable :)
<cjwatson> pitti: CD builds from now on will use feisty's syslinux to work around this
<pitti> cjwatson: ah, and enable gfxboot again? cool
* pitti crosses fingers that the current ubiquity upload will fix the eternal spinning on the last step
<pitti> dholbach: also, I lean towards applying the gconf workaround proposed by seb for bug 118745
<ubotu> Launchpad bug 118745 in libgnome "default desktop/panel menu font sizes too small" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118745
<pitti> dholbach: it seems to help for many people
<pitti> dholbach: WDYT?
<dholbach> pitti: yeah, I'm happy with that
<pitti> dholbach: ok; I just tested the change on the live CD; I can care for that if you can work on the logout dialog?
<dholbach> pitti: I'm looking into it now
* pitti hugs dholbach, thanks
<cjwatson> pitti: eternal spinning sounds like:
<cjwatson>   * Make sure the summary question regex gets split properly.
<cjwatson> (at a guess)
<cjwatson> pitti: right, should enable gfxboot again as a result
<pitti> cjwatson: the exception seemed to match that
<dholbach> pitti: downgrading gnome-power-manager helps - what I think happens is: gnome-power-manager is asked which capabilities are available (suspend, hibernate) do display on the gnome-session dialog - something goes wrong, 30 seconds timeout
<dholbach> pitti: I see what I can do
<dholbach> ogra: ^ (you did the update - can you help with that?)
<pitti> dholbach: is there a bug for it already? this should get one, with a milestone
<dholbach> pitti: right-o
<dholbach> pitti: I'll take a look
<jsgotangco> hey sabdfl
<pitti> cool, so this alternate install went fine
<dholbach> pitti: gnome-power-manager changed the dbus path and stuff like that, but I'm still missing something in the fix - I'll let you know how I progress on that
<pitti> dholbach: danke
<dholbach> pitti: ok to upload http://daniel.holba.ch/temp/gnome-session.debdiff ?
<dholbach> ogra: I fixed it
<tepsipakki> cjwatson: did you merge gfxboot already? I can do it now
<asac> pitti: doko is openoffice hunspell fixed? I saw new bugmail and just wanted to be sure for tribe-1
<cjwatson> tepsipakki: no - I'd like to do it myself, if you don't mind, as I want to be very careful about necessary theme changes at the same time
<pitti> asac: thanks, I milestoned it for tribe-1
<tepsipakki> cjwatson: sure, np
<cjwatson> I'm part-way through it
<cjwatson> thanks for the offer
<pitti> dholbach: ah, splendid. No bug# in the changelog? Well, if there isn't one, that's fine
<pitti> dholbach: please upload
<tepsipakki> cjwatson: ping me when it's ready ;)
<dholbach> pitti: done
<pitti> dholbach: so, that libgnome font size gconf change doesn't fix everything, but it's much better now; I'll keep the bug open, though
<dholbach> pitti: thanks a lot
<Lure> join #kubuntu-devel
* pitti hands Lure a slash
<ogra> dholbach, oops, sorry, i didnt notice that before 
<doko> asac: if the OOo build succeeds
<asac> doko: ah ok ... maybe it should be "fix committed" then, so RMs see this bug as being open for tribe-1?
<pitti> asac: it is already 
<asac> yes for libhunspell
<asac> ah ic ;)
<pitti> well, libhunspell is still 'confirmed'
<pitti> doko: is this actually a libhunspell bug? or can this task just be closed?
<asac> i think libhunspell can be closed as we will not deal with that
<pitti> that's what I got from the bug trail as well, but better asking :)
<pitti> Hobbsee: oh, kaffeine in new; kaffeine-gstreamer? yay :)
<dholbach> pitti: if I have less important uploads does it make you happier if I keep them in ~/upload or if I upload and they are queued?
<pitti> dholbach: feel free to upload them, I can ignore them
<dholbach> so there's nothing I can do to make you happier? :-)
<pitti> dholbach: a neck massage!
<dholbach> right :-)
* dholbach hugs pitti
* dholbach hugs pitti a lot :)
<StevenK> Strange sort of neck message, that.
<pitti> dholbach: anything amongst those uploads which unintrusively fixes some nasty wart?
<dholbach> just regular updates
<Hobbsee> pitti: hmm?
<pitti>          | N kaffeine-gstreamer/0.8.4-0ubuntu1/ia64 Component: main Section: kde Priority: OPTIONAL
<pitti> Hobbsee: ^
<Riddell> pitti: are you going to approve that?
<pitti> Riddell: not before the sparc buildd built it, and then it's your call, I think
<pitti> Riddell: Hobbsee said that this kaffeine version fixed an important bug in the konq plugin
<ogra> oh, all my isos seem to behave, wow ... i never started a release cycle without overzized images
<pitti> ogra: I was quite surprised as well
<StevenK> pitti: Quick, promote a bunch of stuff. :-P
<bhale> ogra: :D
<ogra> pitti, must be you ... i dont even have any uninstallable packages ...
* ogra rsyncs to see the real thing
<pitti> ogra: I spent some time to get gutsy_probs.html close to zero
* ogra hugs pitti 
<dholbach> ogra: mail moderated
* Hobbsee curses her isp.
<Hobbsee> if anyone feels like starting up a decent ISP in australia, please feel free!
<StevenK> Heh
<Mithrandir> "you can run IP over those rusted barbed wires, can't you?"
<Mithrandir> s/rusted/rusty/
<Hobbsee> haha
<StevenK> Mithrandir: That's far too advanced.
<Fujitsu> Heh.
<Hobbsee> Mithrandir: and carrier pigeons, yes.
<Fujitsu> Yay, RFC1149
<StevenK> Mithrandir: I swear Telstra have SmokeSignals interfaces on their core routers.
<Mithrandir> StevenK: BlueSmokeSignals?
<Hobbsee> pitti: i relayed what tonio_ had said about it.  but kaffeine tends to bring more fixes than it does bugs for their releases
<StevenK> Still far too advanced. :-P
<Fujitsu> Our international bandwidth is really great at times.
<pitti> Hobbsee: so if you want to test it right now, I can skip the sparc debs and NEW them later, and NEW the other 4 arches right now
* Hobbsee makes another mental note:  never do conference calls over VOIP if you dont have to
<Hobbsee> pitti: that'd be cool.
<Hobbsee> i'm not sure that it's not violating policy, but that'd be cool
<Mithrandir> Cisco has some special modules for the 6509s delivered in .au.  One has a pigeon feeder and such.  Another one has the cowboy interface where you plug in the rusty barbed wire and hang your cowboy boots.
<pitti> argh, that's the 10th thime I asked firefox not to download a 'bin' file from Launchpad
<Hobbsee> hehe
<StevenK> I've noticed that once or twice, but I can't reproduce it reliabily.
<pitti> Hobbsee: ohe buildd is busy with OOo, the other with glibc
<Hobbsee> pitti: ouch
<pitti> Hobbsee: I bumped the prio, so Kaffeine should come next, but it won't be there before next cron.daily
<Mithrandir> StevenK: it's one of the app servers just returning a zero-byte file, gzipped, which confuses firefox.
<Hobbsee> pitti: fair enough
<pitti> Hobbsee, Riddell: but you are aware that once I NEW this, it'll be very hard to roll back in case it breaks something?
<pitti> Hobbsee, Riddell: have you tested 0.8.4 locally before?
<Ng> (that 0 byte gzip bug is filed as bug 89194, fwiw)
<ubotu> Launchpad bug 89194 in launchpad "LP (regular and beta) sending gzipped binary files" [High,Confirmed]  https://launchpad.net/bugs/89194
<Hobbsee> tonio_ has, but hasnt had internet connection to upload it.  so no, i havent.
<pitti> Ng: ah
<Mithrandir> Hobbsee: you can grab it from the published NEW queue if you just want to test it
<pitti> Mithrandir: hmm, shouldn't there be sth. like http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/ ?
<pitti> Mithrandir: there's just 'unapproved'
<Mithrandir> pitti: there should be, yes.
<cjwatson> pitti: if you don't mind, I'd like to upload d-i to pick up last night's console-setup fix; makes the selected console setup actually apply
<pitti> cjwatson: buildds are hogged ATM, but sure
<cjwatson> I also have this in my tree:
<cjwatson>   * Remove fs-core-modules workaround, as the kernel has now been fixed.
<cjwatson> which is a workaround from like feisty herd 2 or something :)
<Mithrandir> pitti: you know you can adjust priorities of builds now?
<pitti> cjwatson: I'm not aware of that, what does it affect?
<pitti> Mithrandir: yes; <pitti> Hobbsee: I bumped the prio, so Kaffeine should come next
<pitti> Mithrandir: but we actually need that OO.o for tribe :)
<Hobbsee> Mithrandir: sorry, but where would hte published NEW queue for kaffeine be?
<cjwatson> pitti: now, it should just remove bloat from the cdrom initrd
<Hobbsee> Mithrandir: are you meaning sources, or binary?
<cjwatson> pitti: originally fs-core-modules was shoved in to work around isofs.ko being in the wrong udeb
<Mithrandir> Hobbsee: not or, and.
<cjwatson> -# This is wrong and a workaround for isofs not being in the correct udeb in the
<cjwatson> -# kernel.  To be removed post-herd-2
<cjwatson> -fs-core-modules-${kernel:Version}
<Hobbsee> Mithrandir: i dont understand.
<pitti> cjwatson: ah, sounds good then; i. e. it would instantly break everything if that would fail again, which would make us notice it pretty soon, right?
<cjwatson> yes
<cjwatson> it's a slight risk, but I think it's probably ok at this point
<pitti> cjwatson: sounds fine
<pitti> I agree, better than doing it later
<Hobbsee> Mithrandir: right, got you now, but where can i get them?
<Mithrandir> pitti: it was just a permission problem on rookery; fixed now
<pitti> cjwatson: current alternate installs fine for me, btw, that looks pretty good
<Mithrandir> Hobbsee: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/
<cjwatson> excellent
<cjwatson> pitti: uploaded
<Hobbsee> Mithrandir: ah right.  the one i didnt find before due to the 403.  thanks.
<pitti> Hobbsee: no Kaffeine there, though
<ogra> dholbach, thanks
<pitti> Hobbsee: FWIW, http://people.ubuntu.com/~pitti/tmp/kaffeine/
<pitti> Hobbsee: I'll wait for your "yay" or "nay"
<Mithrandir> pitti: given that the queue is less insane again, I've made it publish hourly now
<backblue> hi, i'm trying to make libwww-mechanize-perl-1.30, i'm using pbuild, but i get always this error, http://paste.ubuntu-nl.org/24204/ , anyone knows why?
<Hobbsee_> ooh!
<Hobbsee_> OOH!  OOH!  A CONNECTION!!!
* Hobbsee_ dies of shock
<heno> pitti: I've posted test cases for today's images: https://isotesting.stgraber.org/isotesting/iso/Ubuntu
* Mithrandir revives Hobbsee 
<Mithrandir> can't let you die now that we've finally gotten a community person to help with RM-ing. ;-)
<Hobbsee> heh
<Hobbsee> if only my connection holds...
<pitti> heno: ah, great; however, these images are still quite buggy
<Hobbsee> NEAT!!!
<heno> pitti: as they should be at this point :)
<Hobbsee> ~85% packet loss
<ogra> hey, that means 15% get through, isnt that great :)
<LongPointyStick> 97% now.  impressive
<Hobbsee> Mithrandir: it was hardly advertised that one was wanted, though :P
<Mithrandir> Hobbsee: I think we have realised that now.. shame we didn't see it earlier
<dholbach> hum... am I the only one who has trouble connecting to wiki.u.c?
<Keybuk> the Internet appears to have snapped
<ogra> yeah, some neuralgic point must have dies
<ogra> *died
<agoliveira> Hello all.
<agoliveira> I also can't connect to Canonical's email server, etc
<dholbach> same for revu.tauware.de
<ogra> well, my rsync from cdimage still runs fine
<glatzor> mvo: are we already frozen?
<mvo> glatzor: yes
<glatzor> mvo: :/
<pitti> glatzor: see topic
<glatzor> mvo: no locations and no video ram selection support 
<dholbach> works again
<dholbach> it seems
<LongPointyStick> !ping
<ubotu> pong
<LongPointyStick> !ping
<Hobbsee> !ping
<ubotu> pong
<Hobbsee> this connection is a bitch tonight.
<xxxxx1> heh
<Hobbsee> is this just au going down, or what?
<persia> Hobbsee: I think it's a little more widespread.  I've had some trouble with transpacific lines in general in the past while.
<Hobbsee> right
<Hobbsee> i'm getting up to 98% packet loss
<persia> Hobbsee: Not that bad here.
<Hobbsee> at least i'm ircing via ssh now
<Hobbsee> so it wont obviously drop, and spam you guys
<ogra> argh, where did libgl1-mesa-dri go ? ltsp is broken :/
<pitti> Hobbsee: shall I send you the kaffeine debs with a pidgeon?
<Hobbsee> pitti: i got them.  there's a file overwritten in there
<Hobbsee> it doesnt obviously die, but i havent had much of a chance to test
<Hobbsee> i've been attempting to stickytape the connection
<pitti> ogra: libgl1-mesa-dri | 6.5.3-1ubuntu1 |         gutsy | amd64, i386, ia64, powerpc, sparc
<ogra> hmm
<dholbach> heno: looks like colorblind will become more interesting now - if we had it in mind, the new gnome-mag would provide us with an applet to apply colorblind filters
<ogra> was it a dependency of something in X before ? 
<ogra> Paket libgl1-mesa-dri ist nicht verfgbar, wird aber von einem anderen
<ogra> Paket referenziert. ....
<ogra> Doch die folgenden Pakete ersetzen es:
<ogra>   libgl1-mesa-glx
<ogra> E: Paket libgl1-mesa-dri hat keinen Installationskandidaten
<ogra> (sorry for the german)
<heno> dholbach: yes, we are also doing a SoC project on it with compiz though
* ogra checks the iso
<dholbach> heno: seems we need a MIR for it
<ogra> hmm, libgl1-mesa-glx is there
<heno> we might still ship gnome-mag in as the default for gutsy, but the compiz one will be a better technology in the long run
<heno> dholbach: for libcolourblind?
<dholbach> heno: yes
* heno wonders if it's really main-material
<dholbach> heno: it's a small library that should be harmless - else we can't build gnome-mag against it
<ogra> uh, ah, i got both in the ltsp-client package selection ... 
<heno> dholbach: ok, let's do it than, shall I?
<dholbach> heno: that'd be nice - I'm happy to update the packaging once it's in main
<heno> ok, cool
<ogra> pitti, i sadly have two other commits in my ltsp bzr branch i havent uploaded yet, but they are non intrusive, mind if i upload to unbreak edubuntu ?
<ogra> pitti, http://paste.ubuntu-nl.org/24215/
<pitti> ogra: looks good; this is your playground anyway :) please upload
<ogra> ok
<ogra> ah, crap
* ogra kicks dch*s auto versioning
<ogra> indeed that shouldnt be 5.0.9ubuntu1 but 5.0.10
<ogra> grmbl
<pitti> yay dch :)
* ogra fixes
<Keybuk> ogra: dch -iU ?
<cjwatson> (or just dch -U)
<racarr> When is a good time to find seb128? Or would someone else be willing to look at two debdiffs for nautilus and libeel2-2.
<Mithrandir> when he's not on vacation; he'll be back next week, but you could poke dholbach about them.
<racarr> Ah, thanks.
<dholbach> racarr: I can do that - do they apply against 2.19.2 or 2.19.3?
<racarr> Mrgh, 2.19.2, when did 2.19.3 appear?
<dholbach> 10 hours ago :)
<dholbach> but it's not uploaded yet
<dholbach> the patches might still just apply
<dholbach> main is frozen at the moment anyway, so it's not that bad
<dholbach> did you submit the changes to the upstream bug tracker or are they ubuntu centric?
<racarr> Was going to submit to the upstream bug tracker in near future.
<dholbach> alrighty
<dholbach> that's what we generally prefer, because they know the code much better than we do
<dholbach> but I'm happy to look at them - if you can mail me links to them that'd be nice
<dholbach> or mail to ubuntu-desktop@lists.ubuntu.com
<racarr> Anyway, the idea is to check to a hint to let Compiz draw the wallpaper, and if so draw the wallpaper transparent. http://people.freedesktop.org/~racarr/nautilus.debdiff  http://people.freedesktop.org/~racarr/libeel.debdiff are the debdiffs
<dholbach> I'll moderate them through the queue if necessary
<racarr> Mail, ok.
<dholbach> I'm sorry, but I don't think we can accept the eel patch just like that :-/
<dholbach> it adds API
<dholbach> I'd really really really prefer to have it in upstream
<dholbach> it's the same as with the wnck patches
<dholbach> it's really hard to maintain API over upstream
<racarr> Ok. I'll poke upstream. I'm not sure if they would be interested given that it's only relevant to Compiz *shrug*
<dholbach> it'd be really nice to have it
<dholbach> let me know once you filed them and I'll subscribe to them and make sure to poke them every now and then
<dholbach> racarr: thanks for your work on that and sorry for saying 'no' for now
<racarr> No problem at all, thanks for briefly looking. I'll mail you the bug tracker link.
<dholbach> gracias!
<StevenK> I wonder if compiz can control mouse redraw. Like, have the desktop background stick to the mouse cursor and make it harder to move around the edges, but if a window is over the background, it's fine.
<racarr> I don't understand your example
<racarr> but we want to be rendering the cursor at some point.
* Hobbsee still wants beryl-weather.
<racarr> right after beryl-worms.
<Hobbsee> hehe
<Hobbsee> yep
<racarr> dholbach: Ok, done
<ogra> pitti, ltsp sits in the queue
<ogra> oh, wait
<ogra> i can bother Hobbsee with such stuff now, right ?
<Hobbsee> ogra: hmmm?
<Hobbsee> ogra: no, i dont have archive admin powers.  i'm not employed by you guys...
<ogra> Hobbsee, upload queue stuff ?
<ogra> ah, only RM then ... ok
<Hobbsee> ogra: i may be doign RM stuff, but i dont have access to those machines
<Mithrandir> release management, as opposed to release engineering.
<Mithrandir> carlos: we have a project which uses strings such as "sfil_li_folder_root" as their msgids, would it be possible to get rosetta to display the en_GB as a hint?
<Hobbsee> sorry, yes.
* Hobbsee has a tendancy to class them together.
<Mithrandir> Hobbsee: most people has, but it's useful to tell people about the difference so they know what's useful to ask from you and what you need to poke pitti or other REs for.
<Hobbsee> true that.
<Hobbsee> i see the logic perfectly well - it's that my brain hasnt updated yet.
<carlos> Mithrandir: not yet, but we are finishing some changes that will allow us to support that
<carlos> Mithrandir: which project is that?
<heno> dholbach: MIR is here: https://wiki.ubuntu.com/MainInclusionReportColorblind will take care of seeding and such?
<Mithrandir> carlos: maemo/hildon
<Mithrandir> carlos: do you have an ETA on it?
<carlos> Mithrandir: Firefox support is planed for the end of this month
<Mithrandir> ff do the same thing?
<Mithrandir> this is normal .po files, it's just that the msgid isn't human-consumable.
<carlos> Mithrandir: do all hildon applications use ids instead of English messages? didn't know that...
<Mithrandir> at least the core libs seem to do
<carlos> Mithrandir: yeah, although inside the .xpi with  multiple files
<carlos> Mithrandir: ugly :-(
<Mithrandir> yes, but that won't be fixed for gutsy, so if rosetta can't handle it in the gutsy timeframe, we will have to think of something else.
<carlos> Mithrandir: anyway, there are other projects that use also .po file format and ids instead of English strings as msgid
* Mithrandir nods.
<carlos> Mithrandir: that's doable for Gutsy
<Mithrandir> ok, great.
<Mithrandir> can you give me a guesstimate for when people can start using it?
<carlos> Mithrandir: having Firefox for July, we could get the remaining bits ready around August
* Mithrandir nods.
<Mithrandir> late-ish, but doable.
<carlos> Mithrandir: although if you start uploading packages in Ubuntu
<carlos> we will start showing them automatically
<carlos> in Launchpad
<Mithrandir> oh, cool
<Mithrandir> the packages are already hitting the archive, so that bit is going in the right direction.
<carlos> once the change is done, they will show English translations by default without needed any new import
<Mithrandir> great. :-)
<Hobbsee> pitti: how hard would it be to get requestsync to accept new-to-ubuntu packages?
<pitti> Hobbsee: not very, I guess
<Hobbsee> pitti: could you do the python-foo to do it, please :)
* Hobbsee doesnt grok python.
<Hobbsee> well, not to that degree, to be able to figure it out
* StevenK lalas quietly.
<Hobbsee> oh steve... :)
<Hobbsee> StevenK: were you offering?
<StevenK> Maybe.
<Hobbsee> StevenK: okay, please do :)
<Hobbsee> then pitti can go back to his RM'ing :P
<pitti> heh, great
<Fujitsu> Hobbsee: REing, you mean :P
<Hobbsee> no, he's RM'ing.
<Hobbsee> he has access to the DC and such
<pitti> Hobbsee: but it would require some more changes anyway, I guess
<pitti> Hobbsee: we automatically import new stuff from Debian already
<Hobbsee> pitti: such as?
<pitti> Hobbsee: pulling changelogs from a third-party source; I guess that's what you need?
<Hobbsee> pitti: true that - but after teh autosync gets turned off
<Hobbsee> yeah, i guess.
<Hobbsee> only from debian, really, so you could hardcode it
<Hobbsee> anything else is a corner case, really
<geser> Hobbsee: as I already want to look at requestsync to add an option to subscribe u-u-s, I could also look to get to file sync requests for new packages
<Hobbsee> i dont care who does it - as long as it gets done :)
<StevenK> My problem is that if requestsync is called incorrectly, like 'requestsync gutsy foobar', it will assume that gutsy is a new source package for Ubuntu since it doesn't exist in apt-cache madison.
<StevenK> geser: That's a one-liner.
<StevenK> Well, okay, like four lines.
<Hobbsee> unless you specified that a new package was used with -n or something
<StevenK> I was just thinking that.
<Hobbsee> most people wouldnt use the -n if they didnt know what it was
<StevenK> -s for sponsorship and ubuntu-%s-sponsors is subscribed as opposed to ubuntu-archive, and -n for new source package
<Hobbsee> and would have likely tried with the normal mode first
<Hobbsee> that would work.
<geser> StevenK: I intended to confirm it in such a case and it also needs to find the debian changelog
<pitti> Hobbsee: hm, so why doesn't it actually work right now? 
<ogra> pitti, ... NEW ?
<Hobbsee> pitti: if you request a new package that isnt in ubuntu yet, it tells you that it, rightfully, cant find it in apt-cache madison
<Hobbsee> everything else works brilliantly
<pitti> ogra: ?
<Hobbsee> oh, and the sponsors thing
<pitti> Hobbsee: but specifying the base version manually as 0 should work, no?
<ogra> pitti, ltsp sits in the queue and waits for a distro admin to approve it :)
<pitti> ogra: right, I'm at it, if drescher would finally allow me to login
<ogra> ah, k
* pitti beats his net connection
<ogra> i just dont want it to be forgotten :)
<StevenK> pitti: I should have a diff in about 5
<Hobbsee> pitti: it doesnt.
<Hobbsee>   File "/usr/bin/requestsync", line 23, in cur_version_component
<Hobbsee>     raise Exception('apt-cache madison does not contain %s/%s' % (sourcepkg, release))
<Hobbsee> Exception: apt-cache madison does not contain foobar/0
<pitti> Hobbsee: ah, right, for component
<pitti> ogra: accepted
<ogra> thanks :)
<StevenK> Okay, I think I'm done.
<StevenK> Hobbsee: Want to test?
<StevenK> Stupid Mc-stupid-ity stupid PyQT4 upstream!
<Hobbsee> StevenK: sure.  want to email?
<Hobbsee> anything else might break the spiderweb
<StevenK> You could scp it
<dholbach> heno: it will be enough if gnome-mag will build-depends on it - I'll take care of it, once it has been done
<dholbach> heno: thanks a lot
<Hobbsee> StevenK: true that.
<StevenK>   * Set both DESTDIR and INSTALL_ROOT when we run make install since upstream
<StevenK>     evidently can't decide. 
* StevenK twitches.
<wasabi> Geeze. Everytime I upgrade kerberos something get's worse.
<wasabi> debconf question asking me for my realm servers now. blah.
<j1mc> hello.  i notice no 2007-06-05 images for Xubuntu, but do see 06-05 images for ubuntu and kubuntu.  are the xubuntu ones in the process of being rolled?
<Riddell> j1mc: try looking at the CD build logs
<Riddell> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/xubuntu/gutsy/daily-live-20070605.log
<fabbione> cjwatson: what was the magic to switch the debconf fronted for alternate installer to pure text?
<Riddell> /srv/cdimage.ubuntu.com/ftp//srv/cdimage.ubuntu.com/ftp/pool/main/s/syslinux/syslinux_3.11-3ubuntu4_i386.deb: No such file or directory
<Riddell> j1mc: something not up to date in your seeds maybe?
<ogra> j1mc, looks like xubuntu-live is somewhat oudated
<ogra> *outdated
<j1mc> Riddell: thanks . . . it looks like there was an error in building, yeah.
<ogra> i assume a simple xubuntu-meta rebuild would fix that
<j1mc> ok.  any idea who i could direct this to?  i am just interested in regards to coordinating iso testing.
<ogra> jani probably
<j1mc> sounds good.  thanks...
<Riddell> j1mc: if you update that tell pitti to let it through into the archive, and he or I or tollef etc can set off new CD builds
<Riddell> pitti: I presume you got CD build powers?
* ogra has
<pitti> Riddell: I think I got them today, but no clue yet how to use them
<ogra> pitti, there are readmes on lithium 
<pitti> I saw them, but no time yet to actually read/exercise them
<j1mc> thanks again. i will contact jani, and if it's ok, ask him to get in touch with ogra once he's had a chance to do it.
<pitti> I guess I'll do that tomorrow, when I will start building CDs manually
<wasabi> *sigh*, and of course after upgrading I can no longer login.
<carlos> pitti: hi
<pitti> hey carlos
<carlos> pitti: I wonder whether is a valid use case that you decide to remove a package from PROPOSED pocket instead of move it to UPDATES one
<carlos> you == any ubuntu developer
<StevenK> pitti: Okay, I've hacked requestsync to add support for new source packages, and sponsorship.
<pitti> carlos: soyuz does not allow us to remove packages from -proposed
<pitti> carlos: the use case is pretty obvious: if the pacakge is broken, we want to remove it again
<carlos> remove or update ?
<pitti> carlos: the other use case was that we wanted to remove the older -proposed if we have a newer one in -updates or -security
<pitti> carlos: preferably update, of course :)
<pitti> carlos: but the second case has become sort of obsolete now
<geser> StevenK: is there are diff? I'm trying to teach requestsync to also fetch changelogs for packages not in Debian main
<carlos> pitti: ok
<StevenK> geser: There will be, when I've created it.
<StevenK> geser: Can you please remind me to create/e-mail you a diff when I re-surface? I need sleep at this point.
<geser> sure
<pitti> mvo: does python-apt provide an interface for fetching a source package?
<mvo> pitti: IIRC all the bits are in place, there is "just" no nice function that puts it together. but that is a SMOP
<pitti> mvo: ok, so I'll call apt-get source for now
<mvo> pitti: ok, if you file a whishlist bug and tag it later, I will be happy to look at it 
<pitti> mvo: bug 118788
<ubotu> Launchpad bug 118788 in python-apt "interface to download source code tree" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118788
<pitti> mvo: thanks
<mvo> pitti: thanks!
<cjwatson> fabbione: err frontend=text I think
<fabbione> cjwatson: ok thanks.. i will let you know tomorrow :) my hears were bleeding heavly from the Niagara noise.. had to poweroff for my own sake :)
<cjwatson> Riddell: oh, d'oh, that syslinux thing is a bug in the gfxboot workaround I installed on lithium; nothing to do with the seeds
<Riddell> cjwatson: ok, so how to fix it?
<cjwatson> Riddell: should be fixed now, and I've kicked off new xubuntu builds
<pitti> Riddell: kde-guidance -> is that important for tribe? 
<Hobbsee> pitti: file overwrites?  i believe so
<Riddell> pitti: yes, if we rebuild the CDs now the existing guidance package has file overlaps so it won't install
<pitti> Hobbsee, Riddell: kde-guidance accepted; wild debdiff, but sane enough
<Hobbsee> :)
<Riddell> thanks
<heno> === ISO TESTING === : We are currently testing 20070605 for tribe-1 (but will likely re-spin tomorrow. Please use the lovely new test tracker at https://isotesting.stgraber.org
<heno> (if you had registered for Feisty testing, you'll need to register again, sorry)
<ogra> or if you dont test todays images make at least sure to pull todays iso to speed up the rsyncing of tomorrows :)
<heno> indeed, I'm getting them all now
<heno> ogra: is this about what you want tested, or has it changed: https://isotesting.stgraber.org/isotesting/iso/Edubuntu ?
<ogra> heno, we should list the server addon CDs as well
<ogra> even tough testing them is only "pop it in the CD tray and check if g-a-i starts
<ogra> "
<TomaszD> pitti, ! pitti, hi. Do you know when a language pack rollup will happen for feisty?
<heno> ogra: ok, added
<ogra> thanks
<mrsn0> in gnome when you experience a crash ,where does the bug reporting information go? i dont see it added to bugs.launchpad.net
<Riddell> BenC, kylem: has there been an update recently to nvidia linux modules?
<BenC> nope, not since before feisty release
<Riddell> BenC: do you know what might have caused this complaint? http://paste.ubuntu-nl.org/24275/
<BenC> Riddell: sure do
<BenC> Riddell: They have locally installed nvidia, and it got broken because the last kernel upload changed the ABI
<BenC> since they installed it by-hand instead of using our packages, they'll need to re-install so that the kernel modules get rebuilt
<Riddell> BenC: oh, that could be it.  thanks, I'll poke them in to doing something more sensible
<Keybuk> http://people.ubuntu.com/~scott/pretty.ogg
<Keybuk> ^ racarr rocks :p
<ogra> compressed to death
<pygi> hey Zdra !
<Zdra> pygi: hello :)
<pygi> Zdra, how is empathy going? :)
<Zdra> It's improving every day :)
<pygi> nice :)
<Zdra> it rox :D
<pygi> I'm supposed to release fama 0.0.1 next week, but I have exams
<pygi> damn it :P
<Zdra> yeah me too
<pygi> I can't make any other connection manager (other then gabble) to work properly
<pygi> which sucks :-/
<Zdra> if you follow the spec everything should just work...
<Zdra> I get butterfly, gabble and idle to work with empathy
<Zdra> I didn't tested others
<pygi> butterfly works fine for you?
<pygi> I think I got serious problems with it
<pygi> ah, that's what you get when you can't code =)
* pygi is using tapioca for fama
<Keybuk> ogra: the effect should be evident though, no?
<Keybuk> ogra: since it's the desktop background that you're supposed to notice <g>
<ogra> well, totem runs it at 1024x786 in firefox (which is my browser size) most stuff i see are compression blocks
* ogra tries directly in totem
<Zdra> pygi: do you use MC in fama ?
<bhale> any chance of requiring english on Planet Ubuntu?
<bhale> as a rule of thumb at least
<pygi> Zdra, nop. 
<Zdra> pygi: you should work with me on empathy :D
<ogra> bhale, well, it looks sweet at least :)
<bhale> ogra: I agree, but most of us have no hope of reading it
<pygi> Zdra, why? :P
<pygi> Zdra, why would you want someone who can't code, and don't you have contributors already? :)
<Zdra> because it's the only project using MC
<ogra> right, that includes me
<Zdra> so the only useful project for desktop IM
<pygi> Zdra, haha :)
<pygi> let's not overreact, shall we :)
<pochu> bhale: Maybe add it here https://wiki.ubuntu.com/PlanetUbuntuEditorialPolicy
<pochu> bhale: btw, I entirely agree with it.
<Zdra> pygi: Do what you want, I'm just looking for contributors... I'm alone actually :-
<Zdra> :(
<pygi> Zdra, and what about answer to first question? :p
<Zdra> about butterfly ?
<Zdra> I fixed a bug in tp-python and now it works
<Zdra> tp-python head should be fixed
<pygi> nice that it works :)
<Zdra> don't know if it's released yet
<pygi> I meant "why would you want someone who can't code" :)
<pygi> but let's move to pm :)
<BenC> cjwatson, Keybuk: I just uploaded a new linux-ubuntu-modules that fixes the ftbfs on sparc
<bhale> pochu: edited, could you look?
<pochu> sure
<bhale> pochu: i dont want to offend anyone, but random languages seem to miss most people
<pochu> bhale: I agree with it. It's annoying.
<pochu> bhale: Also I think posts should be Ubuntu-related (or at least OSS related), but that's another story :)
<bhale> pochu: well, again.. 'rule of thumb'. I dont think people should be blatantly out in space
<pochu> bhale: From https://wiki.ubuntu.com/PlanetUbuntu: "[http://blog.example.com/~yourusername/feed?category=ubuntu-only] " :)
<pochu> But it looks like most people haven't read that part ;)
<pygi> haha :-D
<etank> pochu: i agree with you on the content of the posts to hit the planet.
<cjwatson> BenC: cheers
<BenC> cjwatson: thanks, btw, added that MIR for kexec-tools as well
<BenC> added to queue, but have not done seeds yet
<polopolo> Hello
<polopolo> How to upgrade form feisty to Herd1?
<polopolo> Tribe1 sorry
<BenC> bryce: ping
<bryce> hi BenC
<brunosch> hi
<shawarma> Shouldn't our firefox by default assume that a local html file is encoded in utf-8?
<ajmitch> morning
<pitti> hi ajmitch 
<ajmitch> how are you, pitti?
<pitti> ajmitch: good, thanks!
<ajmitch> well, I missed the freeze this time, had no time lately
<ajmitch> we need to have samba updated to 3.0.25a
<pitti> ajmitch: erm, for tribe?
<ajmitch> not critical, 3.0.25 just had a couple of problems
<ajmitch> it can wait until afterwards
<pitti> ajmitch: does it affect libsmbclient, or just the server?
<ajmitch> server
<pitti> ajmitch: if the latter, then later is the right answer, I think
<pitti> since people will install it off the net anyway
<pitti> BenC: l-ubuntu-modules upload looks harmless enough; do we need that for tribe-1?
<pitti> ogra: still awake?
<LaserJock> hi jono 
<jono> hey
<ajmitch> hello jono
<jono> heya ajmitch
<BenC> pitti: yeah, but I thought Colin had processed it
<pitti> BenC: ok, I'll do it
<BenC> pitti: thanks!
<pitti> BenC: so we'll leave sparc broken for tribe-1, I figure
<pitti> and linux-backports-modules, but that can be updated later, since it's not on the CDs, I figure?
<pitti> good night everyone
<PriceChild> Hey... I'm looking for an archive admin?
<pygi> ajmitch, ^^
<geser> PriceChild: bad timing
<etank> pygi: if an app is version -0.1pre1 what would the correct name of the deb be when packaging it?
<PriceChild> geser, yup :)
<ajmitch> pygi: what?
<pygi> I think PriceChild could use your help ^_^
<Kmos> etank: it's not a final release..
<ajmitch> I can't help him
<pygi> oh! /me thought you can
<ajmitch> no, it's not really about REVU
<pygi> oki then n:P
<geser> PriceChild: try again during european working hours
<PriceChild> geser, hehe I will do thanks :) Will idle just incase.
<ajmitch> pygi: I have no power :)
<pygi> ajmitch, haha =)
<etank> Kmos: nope
<Kmos> etank: try to ask at #ubuntu-motu
<etank> Kmos: sure thing
<mikmorg> hello
<mikmorg> i think my term is skrewed up.. brb
* pygi just commited eltorito and is happy now =)
#ubuntu-devel 2007-06-06
<mikmorg> I was in here last night, and think I asked a misleading question..
<mikmorg> although only slightly
<mikmorg> Is there any way I can re-master the Ubuntu desktop CD?
<mikmorg> I want to change initrd and stuff..
<mikmorg> I think it would be easiest to just get all of the tools together to do a complete remastering.
<LaserJock> I think it's quite a bit easier to start from an existing .iso
<mikmorg> hmm.. is it really that complicated?
<LaserJock> but perhaps some of the stuff at https://launchpad.net/ubuntu-cdimage/+branches
<mikmorg> thanks
<mikmorg> i'll see if i can do it without remastering
<mikmorg> but i like to have the option
<pochu> mikmorg: You might be interested in https://help.ubuntu.com/community/LiveCDCustomization
<mikmorg> pochu: thanks
<MrKeuner> hi, are the translations I make using launchpad shared with the actual projects themselves?
<MrKeuner> Or am i translating just for Ubuntu?
<LaserJock> MrKeuner: #ubuntu-translators might know better than I, but I think the actual projects are welcome to get the translations but Ubuntu is the primary user now.
<MrKeuner> what does primary user mean?
<LaserJock> the main one
<LaserJock> so the translations at this point are mainly used by Ubuntu
<bhale> hi LaserJock 
<LaserJock> but I think the actual projects can get them too if they want
<LaserJock> hi bhale 
<Riddell> tfheen: new kde-guidance not vital for Tribe but nice if you happen to be able to let it through before CDs get built (gives us back our power manager)
<elmo> ** (firefox-bin:5296): WARNING **: Owner of /tmp/orbit-james_test is not the current user
<elmo> why is it even looking there?
<elmo> and not /tmp/orbit-james
<calc> is there a way to do a feisty network install from a gutsy cd?
<calc> gutsy doesn't appear to work with the laptop that i tried to install it on, but feisty supposedly works
* calc hopes mini.iso works, downloading the dvd will take many hours
<fabbione> morning
<Burgundavia> hey fabbione
<wasabi> Hurm. At some point we need a clear policy on a direction with regards to evms. Either it's supported or not.
<spectre007__> ?
<sanmarcos> I have a .deb I created for debian unstable that requires absolutely no changes to run on Feisty or Gutsy. If I wanted it to be included in universe, I should get it added to the official debian repos first?
<crimsun> yes.
<Burgundavia> sanmarcos: that is the simplest
<sanmarcos> ok, thanks :)
<Hobbsee> well, the internet sure broke last night!
* highvolt1ge hates it when that happens
<Hobbsee> http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
<Amaranth> heh, broke a lot for me the last couple days too
<Amaranth> afaik it was broken most of the time i was sleeping and working over the past day
<Amaranth> arg
<Amaranth> no openoffice, don't crash on me now
<Hobbsee> hehe
<Hobbsee> gutsy?
<pitti> Good morning
<Hobbsee> pitti!!!
<pitti> hey Hobbsee!
<Hobbsee> pitti: why i had trouble last night:  http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
<Hobbsee> aka, the shoestring broke.
<pitti> hah
<StevenK> pitti: Morning
<pitti> hi StevenK 
<StevenK> pitti: I have a debdiff for scim-qtimm: http://wedontsleep.org/~steven/scim-qtimm.debdiff
<mneptok> Hobbsee: it's not some big truck!
<pitti> StevenK: looks harmless enough; is that dependency really necessary for tribe?
<StevenK> pitti: I'm classing it as nice to have for Kubuntu, but if you say no, you say no.
<pitti> StevenK: I mean, it does not look like if it would change any default behaviour on the CD, since skim is installed anyway
<pitti> StevenK: so, of course you can upload, but it doesn't look worth risking FTBFS and archive inconsistency again
<pitti> so I might leave it in the queue until the release
<Hobbsee> that doesnt look terribly tribe worthy
<Hobbsee> and we're getting enough kubuntu breakage already
<StevenK> pitti: In that case, I'll leave it until the freeze is lifted.
* StevenK chooses not to terrorise pitti with his python-qt4 debdiff. :-P
<pitti> StevenK: if it fixes really important stuff in an unintrusive manner, please do bug me :)
<pitti> StevenK: if it doesn't qualify for that, you'll owe me a beer instead
<StevenK> pitti: It doesn't, which is why I'm not sharing. :-)
* pitti dies of thirst then
<StevenK> Heh
<Fujitsu> Could [insert person who has rights to accept release nominations today]  (ubuntu-drivers at the moment, it appears) please accept the nominations on bug #118855
<ubotu> Launchpad bug 118855 in mplayer "Stack overflow in mplayer cddb handling" [High,In progress]  https://launchpad.net/bugs/118855
<Fujitsu> *?
<pygi> morning
<Hobbsee> hi pygi 
<Hobbsee> (fujitsu, done)
<pygi> hey Hobbsee ^_^
<tfheen> morning
<Fujitsu> Hi tfheen.
* StevenK waves to tfheen 
<Hobbsee> yay, tfheen!
<pitti> hi tfheen 
<StevenK> pitti: Any bugs for Tribe 1 I can throw myself at?
<pitti> StevenK: finding critical ones :)
<fabbione> is anybody having issues with loopback devices in gutsy?
<tfheen> fabbione: yes, the kernel has changed how they work
<fabbione> there has been a kernel module change that tells me that they are created dynamically
<fabbione> yeah
<fabbione> but i think userland doesn't know about it yet..
<fabbione> losetup spits errors everywhere
<fabbione> tfheen: is there a bug for it already?
<fabbione> (if you know of coursE)
<tfheen> unsure, I think userland just has to be changed to cope.
<Hobbsee> morning fabbione 
<fabbione> hey Hobbsee 
<cjwatson> fabbione: the kernel isn't quite right yet
* Hobbsee waves to cjwatson 
<cjwatson> the final version of the upstream patch (which always creates n+1 loop devices) doesn't require userland changes (at least theoretically)
<cjwatson> morrning
<cjwatson> morning
<fabbione> cjwatson: ah ok
* fabbione will wait
<cjwatson> but the patch that we have in the kernel at the moment only creates n loop devices, which makes getting at the n+1'th require manual mknod
<fabbione> yes i can see that...
<fabbione> thanks
<cjwatson> Fujitsu: trying, but LP's giving me an IntegrityError. Will chase that up in a bit
<Fujitsu> cjwatson: Hobbsee used a workaround to do it soon after I asked here.
<StevenK> Perhaps they should just be both declined?
<Fujitsu> Probably, yes. LP seems confused.
<dholbach> good morning
<pygi> hey dholbach :)
<dholbach> hiya pygi
<LaserJock> morning dholbach 
<dholbach> hiya LaserJock
<cjwatson> Fujitsu: https://bugs.launchpad.net/malone/+bug/118915
<ubotu> Launchpad bug 118915 in malone "IntegrityError trying to approve a bug nomination" [Undecided,Unconfirmed]  
<Fujitsu> cjwatson: Malone proves its reliability yet again.
<dholbach> Fujitsu: Seriously, how often do you have problems with it?
<Fujitsu> I guess not that often, but it's still annoying.
<dholbach> no, not that often
<pitti> doko: https://bugs.launchpad.net/ubuntu/+source/hunspell/+bug/111940 can be closed now, right?
<ubotu> Launchpad bug 111940 in openoffice.org "libhunspell-1.1-0 1.1.5-6: Incompatible ABI change" [High,Fix committed]  
<doko> pitti: done
<pitti> awesome
<Keybuk> gnargh
<Keybuk> now I have to remember how to use OpenSSL again
<pitti> hi Keybuk 
<StevenK> Keybuk: To do what?
<pitti> Keybuk: time for the yearly ssl cert re-signing?
<Keybuk> indeed
<Keybuk> a) figure out what parameters my certs had last year
<Keybuk> b) make new ones
<Mithrandir> Keybuk: why not just use cacert?
<Keybuk> whuh?
<shawarma> Keybuk: You can reuse your csr's.
<Mithrandir> http://www.cacert.org/ ; free CA
<thom> and they seem somewhat less awful than they used to be, too
<Keybuk> shawarma: how do I do that?
<ogra> pitti, you pinged last night ?
<cjwatson> pitti: except for powerpc, where OOo failed to build :-/
<shawarma> Keybuk: If you still have it, just use it again. AFAIR it has no timestamp, so you'd just be reusing the parameters.
<Keybuk> shawarma: assume that I know nothing about OpenSSL
<cjwatson> but I guess the bug's dead, sure
<shawarma> Keybuk: Heh.
<Keybuk> and the fact that I have managed to successfully generate things before is simply due to being able to cargo-cult enough commands to make it work
<Mithrandir> Keybuk: C-r openssl ca in your shell with a long enough history? :-P
<pitti> cjwatson: right :/
<shawarma> Keybuk: Well, last time you did it, you probably produced a .csr somewhere in the process. This time around, skip the tutorial you're using up until right after the csr generation and start there. :)
<Keybuk> shawarma: I don't remember that file, and don't have them
<pitti> ogra: hi
<Keybuk> I have certs/something.pem and private/something.pem
<shawarma> Keybuk: Ah. 
<shawarma> Keybuk: This time keep the .csr around.
<pitti> ogra: any tribe-1 relevant bugs from your side still?
<cjwatson> gar, and it looks like it was really close to the end
<pitti> cjwatson: at least I'm happy that it worked on amd64 this time
<shawarma> Keybuk: Oh,hang on. That might be enough.
<Keybuk> Mithrandir: I can't seem to make a cacert account
<Mithrandir> Keybuk: oh?
<ogra> pitti, not that i'm aware of, but i didnt do a test install yet, just starting the first one
<shawarma> Keybuk: openssl req -new -key private/something.pem -out req.pem
<pitti> cjwatson: very same problem with the previous build, so it might not just be a glitch
<shawarma> Keybuk: (I think)
<Keybuk> Mithrandir: crappy web form
<pitti> ogra: btw, current cd images are still not 100% good
<doko> pitti: please promote portaudio19-dev (the ubuntu1 build) to main, new upstream version of a library already in main
<pitti> ogra: publisher is running, afterwards I'll build candidates
<ogra> well, but i'll see if they die on any edubuntu specific stuff, virtualbox is cheap ;)
<pitti> right
<pitti> ogra: just mentioning it for a community CFT
<pitti> (call for testing)
<shawarma> Keybuk: The EXAMPLES sections of the various openssl man pages are very handy. req(1ssl) is your friend in this case. :)
<mvo> pitti: let me know when images are there, I will re-install my workstation with i386 as amd64 hates me and does not give me working DRI (I ignored that problem for the last year or so but now I have enough)
<pitti> sure
<pitti> doko: doesn't work, because it depends on jack, which build depends on type-handling and another weird thing
<doko> pitti: "(the ubuntu1 build)"
<doko> pitti: openoffice.org-voikko uploaded
<pitti> doko: ah, I see; that's still in unapproved, will do after tribe
<pitti> doko: merci
<pitti> Riddell: your new kde-guidance upload looks troublesome: http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<pitti> mvo: ubuntu alternates are up
<mvo> pitti: cool, thanks
<pitti> cjwatson: "mv: cannot stat `usr/lib/syslinux/isolinux.bin': No such file or directory" -> just to confirm, this error on the ubuntu-server CDs is already fixed by your adjustments from yesterday?
<cjwatson> pitti: yes
<heno> pitti: are we rolling right in to testing of 20070606 (shall I dump -05)?
<lool> Hmm could someone enlight me on what XSBC-Original-Maintainer means in the DebianMaintainerField wiki page: for example, would you use XSBC-Original-Maintainer for sources other than Debian?
<shawarma> lool: I'd say yes, unless the original maintainer explicitly has said that he/she would manage Ubuntu bugs.
<lool> Is there a way to avoid the header to turn up in Sources.gz and Packages.gz?
<lool> Or should one simply comment the field out?  e.g. #XSBC-Original-Maintainer
<sivang> hey people
<lool> Hmm XSBC seems to mean the header will be copied in Sources and Packages files while XS only makes it appear in Source; pehaps C stands for *.changes file
<LaserJock> I believe so
<pitti> heno: yes, 05 is obsolete in any case; 20070606.1 will be the good ones (ubuntu alternate is up, rest is building)
<lool> Right, dpkg-source looks for ^X[BC] *S[BC] *- and copies these headers, dpkg-genchanges looks for ^X[BS] *C[BS] *- and dpkg-gencontrol for ^X[CS] *B[CS] *-
<heno> pitti: thanks, I'll post -06.1 then
<lool> (So I simply need to use X-OriginalMaintainer if I don't want it anywhere; great)
<pitti> lool: we agreed on XSBC-, though
<pitti> lool: since we do not want to hide credit for the DDs
<lool> pitti: Do you know whether the Debian archive accepts the fields everywhere?
<lool> pitti: Credit is a good point indeed; there's the problem of Packages.gz file bloat (especially in Debian) too
<pitti> lool: no, I don't, but packages with this are not supposed to be uploaded to Debian
<lool> pitti: I'm grabbing Debian packages from Ubuntu itself grabbing them from maemo, and I thought I should follow the same DebianMaintainerField concept, except it's the other way around :)
<pitti> lool: ah, heh, I see
<iwj> lool: You should think about who might want want and whether they'll be offended.  I don't think Ubuntu guys will be offended whatever you do.
<iwj> So the question is whether the maemo people are likely to be offended or not.
<lool> iwj: So if I paint your cat in red you want be offended?
<iwj> Why not ask them ?
<lool> s/want/wont :-P
<iwj> lool: Feel free to paint all of my cats red.
<lool> iwj: haha :)
<iwj> -3s/want want/want what/
<pitti> iwj: I guess you have about zero of them, then?
<iwj> pitti: :-).
<lool> True, I should simply ask them; and the Debian archive not supporting these would also rule the question out
<iwj> Yes.  But it would be amusing in a way if maemo say `yes please keep our name in XSBC-Original-...' and Debian don't support it :-).
* lool . o O ( In which case I can still threaten all their cats )
<Mithrandir> lool: fwiw, I don't care if you don't have the Ubuntu people not mentioned in the control file as long as the changelog is correct.  (With my ubuntu mobile hat on)
<cjwatson> there's no technical barrier to using those fields in Debian
<cjwatson> in the archive
<cjwatson> (I make no comment on social issues)
<lool> Mithrandir: Was there some discussion to use XSBC-OM for maemo Maintainer:s already?
<Mithrandir> lool: not that I know of.  I can raise it on maemo-developers@ if you want?
<pitti> heno, all: ubuntu alternate and live are now up and good for testing: 20070606.1
<lool> Mithrandir: I was about to do that, but I'm still subscribing; please do for both Ubuntu x Debian if you like; thanks a lot  :)
<Mithrandir> sure
<fabbione> pitti: did you ever get around to accept multipath-tools in -proposed?
<fabbione> pitti: i can't find any mail from L
<fabbione> LP
<pitti> fabbione: not yet, sorry
<fabbione> pitti: ok thanks.. it's fine. i was just worried the upload got lost
<pitti> nope, it's in the queue
<fabbione> danke
<StevenK> pitti: Just noticed that openoffice.org-voikko has hit gutsy_probs. I'd like to bet it's due to the new upstream release of openoffice.org. Would you like me to upload a build1 of it?
<StevenK> pitti: (There no being no point showing a debdiff, it only being a changelog change.)
<Mithrandir> StevenK: there's a voikko in unapproved.
<pitti> StevenK: doko already did that, it's being published right now
<StevenK> Aww, someone beat me to it.
<doko> pitti: I see that main inclusion reports are outstanding for lp-solve and ufsparse
<pygi> jdong, poke
<pitti> heno, ogra, all: edubuntu alternatives up (20070606.1), xubuntu alternatives up (20070606)
<pitti> heno: can you set the xubuntu timestamp accordingly? there hasn't been a automatic daily build for it yet
<heno> pitti: right, so back to 2007606 (?)
<pitti> heno: for xubuntu, yes
<heno> indeed, ok
<pitti> heno: (for xubuntu live as well)
<ogra> great, i'm about 2/3 through the 20070606 install in my virtualbox
<ogra> i'll test the next one right afterwards
<heno> yes, all of https://isotesting.stgraber.org/isotesting/iso/Xubuntu
<pitti> heno: for server as well, please
<heno> pitti: ok, willdo
<heno> pitti: I only see *0605 for server is that right?
<pitti> heno: it's still building
<heno> ok IC
<pitti> I'll announce the images here as they arrive
<pygi> jdong, wake up, wake up ^_^
<pitti> -server is up
<fabbione> pitti: please remember to drop me a note when you plan to release Tribe-1 so we can start hw-cert process
<fabbione> pitti: cr3 is aware that you are about to deploy the nuke :P
<pitti> fabbione: yep, I'll do that (it's part of the documented process, so I won't forget)
<fabbione> pitti: perfect
<pitti> heh :)
<pitti> fabbione: can you test the server images a bit?
<pitti> fabbione: I'm not sure whether the d-i for kernel ABI -6 made it for sparc
<fabbione> pitti: that's kind of important, isn't it?
<pitti> fabbione: right, but the fix came veeeery late
<fabbione> actually i think d-i wouldn't build if the abi doesn't match
<pitti> so we already kind of agreed on skipping it for tribe-1
<pitti> fabbione: oh, it built this morning
<fabbione> pitti: well that will make impossible to do hw-cert
<pitti> fabbione: I accepted it and things and built cd images afterwards, but I'm not sure whether the latest version landed on the CD images
<fabbione> pitti: for sparc we only need -server
<fabbione> pitti: do if you built the server recently enough, it should be good
<pitti> fabbione: I built it some 20 minutes ago, yes
<fabbione> pitti: ok, let me update my rsync script to cope with gutsy and i will double check
<pitti> thanks
<fabbione> pitti: ETA 10 minutes
<fabbione> pitti: CD has abi 6 of kernel and udebs.
<fabbione> pitti: i think it should be good.. checking kernel md5sums
<pygi> damn, powerpc failed to build brasero :-/
<sabdfl> doko: what's our glibc roadmap look like? someone's asking about RT, and saying glibc2.5 has significant improvements
<fabbione> pitti: the md5sum for initrd.gz from last d-i and what's on cdrom matches... not sure why vmlinuz doesn't but we might mangle something there
<pitti> fabbione: hm, only linux-ubuntu-modules was FTBFS for quite some time; the actual kernel has worked
<fabbione> pitti: that should not change the vmlinuz md5sum but gimme a few minutes to burn it and i will test it directly
<fabbione> pitti: does BenC know about those failures?
<pitti> fabbione: yes, he fixed them last night
<fabbione> ok
<pitti> so I gave-back d-i on sparc this morning
<fabbione> i might as well do a test install.. quicker than just double checking
<pitti> heno: quick status update FYI: ubuntu/edubuntu/xubuntu alternates up, kubuntu still out of date (publisher is running for latest stuff), ubuntu live up, edubuntu live taking ages and block other lives
<cjwatson> sabdfl: feisty has glibc 2.5
<bhale> sabdfl: gutsy has 2.5
<cjwatson> (both!)
<bhale> :D
<fabbione> eheh
<fabbione> glibc war!
<cjwatson> pitti: I generally budget about 45 minutes for any livefs set
* pygi wonders why the ppc build failed :(
* pygi goes lookking
<pitti> cjwatson: edubuntu live build now runs for 1.5 hours
<cjwatson> wow
<pitti> cjwatson: livefs building finished on king about 20 minutes ago, now teststatus is empty
<cjwatson> that's a bit much
<pitti> cjwatson: but the ssh king@ still didn't finish
<cjwatson> sounds like it's hung
<heno> pitti: thanks I've just disabled test reporting on kubuntu for now
<pitti> cjwatson: shall I just kill it and try again, or poke the sysadmins about it? has this happened before?
<heno> pitti: you should register on https://isotesting.stgraber.org so I can give you admin super powers (everyone has to register again, sorry)
<pitti> heno: I did already, and submitted some amd64 reports (pitti)
<heno> ok, cool
<sabdfl> cjwatson, bhale: doh, thanks :-)
<cjwatson> pitti: http://king.buildd/~buildd/LiveCD/gutsy/edubuntu/latest/livecd-20070606.3-amd64.out still seems to be running
<cjwatson> it's in the middle of debootstrap
<cjwatson> seems to be progressing quickly enough
<cjwatson> pitti: I don't know, maybe it was waiting for a lock? did you try to run multiple livefs builds at once?
<pitti> I just killed it here
<pitti> so maybe it released a lock now
<pitti> cjwatson: it might be possible that I accidentally ran two livefs builds in parallel
<pitti> cjwatson: can I kill the current build on king somehow?
<Mithrandir> pitti: it's quite important you don't kill livefs builds midway through, if so you need sysadmin intervention
<pitti> Mithrandir: ok, noted for next time; sorry for the trouble
<Mithrandir> sorry for not telling you
* pitti asks a sysadmin to kill it
<Mithrandir> they just don't abort cleanly.
<fabbione> pitti: i am afraid something is borked on sparc cd... it can't find the cdrom
<fabbione> pitti: skip it for tribe-1. not worth fixing at this stage.
<pitti> fabbione: ok; any idea what the reason is?
<fabbione> pitti: not yet.. it just booted
<cjwatson> pitti: at this point would it not be better to just let it finish?
* fabbione sighs... 
<fabbione> the cdrom detect thingy is looping and i can't back to the main menu
<pitti> cjwatson: there's no process attached to that on lithium any more, so not sure whether it'll make sense; currently discussing that in #c-s
<fabbione> pitti: i can't debug it from the cdrom itself. i will have to do some manual digging..
<fabbione> cjwatson: do you happen to know if there is already a bug on cdrom detect looping forever if it can't find a cdrom?
* StevenK peers at rmadison.
<pitti> fabbione: ok, thanks so far; at least I know that the d-i rebuild/publish/CD image process worked, and I can kill the -5 kernels
<mdz> mvo: when do you expect to have an upgrader available for gutsy?  I have a system I'm going to upgrade and would be glad to test
<fabbione> pitti: it can be everything for now.. i need a bit more time to understand
<StevenK> cjwatson: It worries me a little that ~ubuntu-archive/madison.cgi can't find libc6 in Gutsy.
<fabbione> pitti: yeah the kernel is right on the cd..
<Keybuk> :'( why does rsync hate me so much?
<fabbione> cjwatson: never mind my bug request before. it happens only when booting with "check-cd". it works on normal install
<doko> sabdfl: glibc-2.5 is current in gutsy, preparing glibc-2.6, but not yet decided on an upload
<fabbione> pitti: it's a kernel bug.
<fabbione> pitti: i will have to talk to David about this
<fabbione> [   21.844794]  Can't get ranges for PCI-PCI bridge /pci@1f,0/pci@1/pci@1        
<fabbione> and after that bridge there is the IDE controller for the cdrom
<fabbione> that's missing even from lspci
<fabbione> no wonder it can't find it :)
<fabbione> pitti: netinstall might still work.. but i don't think it's worth spending too much effort into it. If the network interface is behind a non-initialized bridge you will hit the exact same problem
<fabbione> pitti: but it's your call if you want it in or out.. i am good both ways
<pitti> fabbione: let's declare it as broken for now and mention it in the release notes, shall we?
<fabbione> pitti: i am good with whatever decision you take.
<fabbione> pitti: personally i see little point in getting tons of reports when we know it's broken
<fabbione> i am pretty sure it works on Niagara, but really. not worth the pain
<pitti> right
<pitti> fabbione: can you please put some information about this problem in a bug report and toss me the number?
<pitti> fabbione: so that we have something to refer to in the notes
<pitti> (and to track for tribe-2)
<cjwatson> fabbione: sounds more like cdrom-checker than cdrom-detect?
<Mithrandir> mvo: what do you need from me to add an arch to apt?
<cjwatson> StevenK: odd
<cjwatson> StevenK: works now; weird
<cjwatson> I just ran madison-lite by hand on rookery ...
<cjwatson> I assume the cache was a bit buggered or something :-/
<StevenK> cjwatson: Yes, quite odd.
<mvo> Mithrandir: please check buildlib/archtable buildlib/sizetable
<StevenK> cjwatson: Got a sec for a PM?
<cjwatson> StevenK: sure
<Mithrandir> mvo: can you just do it if I ask you to add lpia?
<mvo> Mithrandir: sure, is it lpia lipia?
<Mithrandir> mvo: sizelib should be like i386, arch name is lpia
<Mithrandir> mvo: the triplet is gnulp-linux-i.86
<cjwatson> has the triplet ordering changed?
<cjwatson> it used to be i386-linux-gnu etc.
<Mithrandir> this is the debian triplet, not the gnu triplet
<Mithrandir> look at triplettable
<cjwatson> ah
<fabbione> cjwatson: the root of the problem is the kernel that doesn't init the cdrom. as result the cdrom-detect can't find one and loop. This happens only when checking the cd. I can go back to main-menu when using normal install. Not sure how checkcd preseed. i don't know that magic
<cjwatson> it sets MENU=/bin/cdrom-checker-menu which causes a cdrom-checker helper script to be run instead of main-menu
<cjwatson> it's not preseeding as such
<fabbione> oh ok..
<fabbione> not even sure if that's to be considered a bug
<fabbione> it just makes it more difficult to check an error in that stage
<cjwatson> an infinite loop is a bug ...
<cjwatson> it ought to at least error and give up
<fabbione> ok
* fabbione files in LP
<pitti> Riddell, heno: Kubuntu alternates are up; lives will still take a while until the mess on the buildd settled down
<pygi> who here would be ppc & sparc expert? I've got package failing to build in there :p
<Riddell> pitti: thanks
<fabbione> pygi: url to sparc build log?
<pygi> fabbione, http://launchpadlibrarian.net/8004481/buildlog_ubuntu-gutsy-sparc.brasero_0.5.90-0ubuntu1_FAILEDTOBUILD.txt.gz
<pygi> I've actually got the error, but it builds fine on three other archs
<pitti> heno: I enabled/disabled selections according to the current state
<heno> pitti: great!
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy main frozen for Tribe-1 | Please test the Tribe-1 candidates: https://isotesting.stgraber.org/
<fabbione> pygi: looks like broken include.. try to follow the dependencies backwards
<fabbione> pygi: and see why on sparc something is missing
<pygi> fabbione, yea, but it works on other arches. /me needs to look it
<heno> let me have feedback on the usability of that when you've used it a bit
<fabbione> even on != sparc you can still grab sparc.deb and unpack it manually somewhere to look
<pygi> I understand
<pygi> fabbione, will try to locate, but ... not sure how much users use brasero on sparc & ppc anyway
<fabbione> pygi: well up to you.. if it's in main it must be fixed
<mvo> Mithrandir: what is the gnutriplet? this looks like the one that apt is looking at
<pygi> fabbione, not main, but I'll see what I can do :)
<pygi> fabbione, thanks for the heads up :)
<fabbione> pygi: and if it is a system header that is broken, the error might hit other packages too.. still worth looking
<fabbione> afaik there is a sparc available for MOTU's somewhere
<fabbione> you might want to ask around
<pygi> and what if I'm not a MOTU? :)
<pygi> but sure, I'll see what I can do and fix it
<fabbione> pygi: ebay.....
<fabbione> :)
<pygi> hehe :)
<pygi> AFAIK, the error is weird. it doesn't seem to be related to any dependency, but rather to some weird "syntax error" ? 
<pygi> ./scsi/scsi-get-configuration.h:869: error: expected ',', ';' or '}' before 'uchar'
<pygi> this would be the error
<Amaranth> that means uchar is undefined
<Amaranth> or you broke something higher up in the code
<Amaranth> pygi: probably ./scsi/scsi-get-configuration.h:864: warning: no semicolon at end of struct or union
<pygi> I didn't broke it, the uptream might :P
<pygi> yea, I'll need to look into that =)
<Amaranth> i thought you were upstream
<pygi> of brasero? Nop, I just contribute and advise them here and there =)
<pygi> I'm the libburnia upstream :P
<pygi> (which builds fine everywhere btw :P)
<Amaranth> hehe
<Amaranth> i remember first seeing something about libburn in like 2004
<Amaranth> or 2005
<pygi> at that time, libburn could do nothing, and was dead :Pa
<Amaranth> thought 'ooh, no more cdrecord bullshit'
<Amaranth> the noticed it didn't do anything and forgot about it until brasero
<pygi> it can now do all cd and dvd variants, but you have to consider dual layer is heavily untested =)
<pygi> otherwise it works pretty fine :)
<pygi> for libisofs, 6000 lines changed last week, implemented eltorito and a lot of nice reworking ^_^
<Amaranth> yay
<pygi> oh well, we still gotta walk a long way
<pygi> Amaranth, I hope to get genisofs this year as well if all goes well :)
<Mithrandir> mvo: like i386, but gnulp instead of gnu
<slomo> mjg59: ping? (re gst-plugins-base alsa patch)
<pitti> ogra: did you trigger live fs builds recently?
<ogra> nope
<ogra> i'm still watching virtualboox ...
<ogra> its taking ages for the "please wait..." step in the end ... 
<pitti> ok; I wonder why king doesn't stop building livefses noone asked for
<pitti> I want to build ones that actually get published :/
<ogra> (sitting there sinc 1h or so but i need to see the ltsp setup after this so i'm still waiting)
<ogra> pitti, infinitys realm iirc
<pitti> ogra: yep, discussing with him
<PriceChild> Hey, are there any archive admins around?
<pitti> several
<pygi> PriceChild, you got not only one, but several :P
<PriceChild> (any that have a few minutes to help me? :P )
<Hobbsee> PriceChild: helps if you say what about
<Mithrandir> PriceChild: don't ask to ask, just ask your question.
<PriceChild> Managed to get "gizmod" through revu. Since then noticed a problem in the debian/rules get-orig-source that managed to repackage it twice into the new tar.gz Since been fixed on revu, but gizmod is sitting in the queue and wondering whether someone should remove it?
<Hobbsee> PriceChild: uploading the fixed version will tend to work
<Mithrandir> PriceChild: just upload with a newer version number
<Mithrandir> s/newer/higher/
<PriceChild> Hobbsee, Mithrandir, ok cool thanks, just didn't wanna waste your time if the new version would have to be looked over completely again.
<Mithrandir> mvo: so if that's all you need from me, please upload when the freeze ends
<Mithrandir> doko: do you need anything from me to upload a new gcc with lpia support?
<khaur> is there a valid reason for mozilla-mplayer package to depend on "mplayer", so that "mplayer-nogui" is not an alternative?
<pygi> jdong, around? :P
<fabbione> hmmmm
<fabbione> who is the archive admin in service today?
<Hobbsee> fabbione: pitti iirc
<fabbione> ok :)
<pitti> would be seb128, but he's on vac
<fabbione> pitti: could check where my system-config-cluster upload vanished?
<pitti> fabbione: I can do some quick things for you, but nothing really large
<fabbione> pitti: i did it yesterday i believe...
<pitti> fabbione: no, it's in unapproved
<pygi> pitti, he's on vac?! 
<fabbione> why unapproved?
* pygi makes evil plots to patch n-c-b to use cdrskin while he's away :)
<pitti> fabbione: noone pinged me about pushing it into tribe-1, so I didn't care (people upload all sorts of post-tribe main stuff)
<fabbione> pitti: oh sorry....
<pitti> fabbione: archive is frozen
<fabbione> my bad
<fabbione> yes that's fine
<fabbione> no need for it for tribe 1 and it's not on CD afair
<fabbione> sorry about that... it did slip from my mind
<fabbione> thanks for checking
<pitti> np :)
<pitti> fabbione: do you have some time for testing the other server CDs?
<fabbione> pitti: not for today... sorry. they will have to wait tomorrow morning
<pitti> ok
<fabbione> probably later this night if my wife crashes... but it's our 3rd anniversary so i doubt i will be back
<fabbione> or 4th..
* fabbione has lost the count already
<fabbione> anyway i am off for now
<fabbione> ttyl
<pitti> fabbione: oh, enjoy!
<doko> Mithrandir: no, but I would like to see the triplet changed to have i686 included by default
<ogra> pitti, hrm, i gave up on that test install now
<Mithrandir> doko: have you had any feedback from intel on that?
<pitti> ogra: what's wrong?
<mvo> Mithrandir: on the phone right now, but it may require some massaging into the build system
<doko> Mithrandir: that was proposed by an intel engineer
<ogra> pitti, no idea, was there a prob with pkgsel in 06 that was fixed in 06.1 ?
<Mithrandir> doko: can you just do it, then?
<ogra> it hung at pkgsel for more than 1h ... might be virtualboox slowness though
<doko> i386 is definitely wrong, when used unmodified for configuring packages.
<ogra> i'm retrying without network since thats usually faster 
<doko> Mithrandir: ok, will do after the freeze ends
<pitti> ogra: I doubt it
<ogra> then i blame virtualbox
<Mithrandir> doko: thanks.  Care to drop me a mail when it happens?
<ogra> lets see how this one goes 
<Mithrandir> mvo: it's going to require byhand bootstrapping, but that's fine
<ogra> the sad part is that i couldnt get to the ltsp stuff yet ... debian insisted that it has an installer prio of 7000 .... i'll have to change taht again, its taking way to long during testing
<pochu> Do we need transitional packages until the next LTS? If I set up conflicts/replaces/provides, the packages upgrades fine without them.
<pitti> pochu: that are two questions in one
<pitti> pochu: (1) if a transitional package applies to a transition started in dapper, it needs to stay until next LTS
<pitti> pochu: (2) if you merge two packages, or the obsolete one is a libray, then you usually don't need a transitional package at all
<pochu> Well, it's a engine for liferea, but now it's integrated in the liferea package, so the C/R/P should be enough, right?
<pitti> Hobbsee, Riddell: kubuntu desktop CDs are up and now enabled in isotesting; test away :)
<Riddell> thanks
<pitti> cjwatson: I am doing an expert install with LVM; the menu only offers me to install lilo, no grub; is that a bug, or doesn't grub know how to boot stuff on LVM?
<cjwatson> pitti: the latter, AIUI
<cjwatson> ogra: 7000 sounds correct
<cjwatson> ogra: all installer-menu-items are to be multiplied by 100 in gutsy (most already have been)
<ogra> cjwatson, not if i want it directly after base install
<ogra> as we had it before debian intervened
<cjwatson> ogra: base-installer = 6500
<cjwatson> next things are apt-setup and pkgsel at 7000
<ogra> and pkgsel ?
<ogra> aha
<ogra> so 6800 would be for me then
<cjwatson> admittedly if you set ltsp as 7000 then the ordering is probably undefined
<cjwatson> 6800 sounds fine
<ogra> its just silly to have to wait for the whole install to finish to find my errors ...
<ogra> burns a lot of time
<cjwatson> sure
<cjwatson> ogra: there's a known pkgsel hang with some network (mis?)configurations
<cjwatson> it sits there waiting for apt-setup
<Mithrandir> pitti: any chance for a NEW processing of osso-gwconnect (binary NEW)
<cjwatson> if the hang you're seeing is at 85%, that is; if it's right at the start of pkgsel, it might be a weird racy debconf-apt-progress/dpkg-preconfigure interaction that we're still trying to figure out
<ogra> cjwatson, heh, ok, then my guess was right 
<ogra> this insrtall should get through
<ogra> well, i had an interface up but no ip forwarding for the virtualbox i'm running
<ogra> so its not properly timing out
<cjwatson> yes, so apt-get update will hang
* ogra ponders to add a *buntu-desktop dependency to ltsp-server-standalone to overcome the probs ubuntu-server users have ...
<shawarma> I'm working on a package that wants to use a special dhclient-script, but our deroot-client magic makes it unable to do anything even remotely useful.. Has this been worked around before for some other package, perhaps?
<pitti> ok, amd64 desktop+alternate all PASS here
<pitti> can someone please test the i386 ubuntu images?
<pitti> Mithrandir: hmmkay
<Mithrandir> cheers
<pitti> Mithrandir: there's no init script and nothing in /etc/dbus/event.d (deprecated) either; is that right?
<Mithrandir> pitti: yes, AIUI
<pitti> Mithrandir: ah, nevermind me, it's a .service
<pitti> didn't notice those two
<Mithrandir> pitti: I must confess to not really having tested the package since I'm so far just using it as a build-dependency
<pitti> heh :)
<pitti> Mithrandir: accepted; do you want a publisher run for those, or is it not urgent?
<Mithrandir> a publisher run before tomorrow would be fine
<pitti> Mithrandir: alright, no problem that
<Mithrandir> so "yes, a publisher run would be good, but I don't need it right now"
<pitti> shawarma: not right now, since the path is hardcoded; if we need that, we need to hack it into dhcp-client itself
<pitti> Mithrandir: so, *shrug*, I don't need buildds and soyuz for anything else right now, so I just run it now before I forget
<shawarma> pitti: You mean like a hardcoded exception?
<pitti> shawarma: more like a sane way how to modify
<Mithrandir> pitti: or just turn it back on auto
<shawarma> pitti: Ah.
<pitti> Mithrandir: hmm as long as noone gives back packages in main etc. that shouldn't hurt
<Mithrandir> pitti: and worst case, the archive and the CDs don't match, which is not really a big deal.
<pitti> Mithrandir: well, I'm afraid of archive desync if we need to rebuild CDs
<shawarma> pitti: On my test installation I've hacked it to call its argv[1]  and hacked dhclient accordingly, but that renders a lot of the derooting useless, I think.
<pitti> but the only way that comes to my mind how to circumvent unapproved is give-back; do you know another one?
<pitti> shawarma: right :)
<pitti> shawarma: it's not actually that easy without hardcoding
<pitti> shawarma: OTOH, I don't really sit on the derooting patch; dhcp3 hasn't had many vulns in the past, and if it blocks development, we can revert it at least temporarily
<pitti> shawarma: I sent it to upstream years ago, but they don't seem to be too keen adopting it
<shawarma> pitti: Oh, I thought it was yours.
<pitti> shawarma: it was, right
<Lure> heno: bugs in iso tracker: just release critical should be listed or any (for example HW specific issue (but know workaround) that prevent install)
<shawarma> pitti: Ok. Hum... Well, my hack at least doesn't leave anything with root privs listening on an open socket. 
<shawarma> pitti: But still..
<pitti> shawarma: right, but the point is, if someone can execute code as dhcp user in the daemon and then can coerce the suid wrapper to execute an arbitrary script instead of the hardcoded client script, then the derooting doesn't help you
<pitti> shawarma: with the hardcoding, all he can do is to change the network configuration (which is something you cannot take away from dhcp client)
<shawarma> pitti: Well, dhclient.conf is root-writable only, so if the suid-wrapper could read the dhclient script from the config file, that would plug it somewhat.
<shawarma> pitti: :) Clearly.
<pitti> shawarma: right, that's what I tought as well
<shawarma> pitti: It doesn't solve the pass-an-alternative-dhclient-script-on-the-command-line use case, but it's good enough for my use.
<pitti> ogra: edubuntu live CD is up, but it is oversized by two bytes or so
<ogra> gah
<pitti> no idea why, the previous one was good
<pitti> ogra: can you please chop off a bit of them and update the seeds?
<ogra> +ohew
<ogra> *phew
<ogra> pitti, do you think 2M will suffice ?
<pitti> ogra: yes, i386 is 701 MB, amd64 700 MB
* ogra drops the arabeyes font ...
<pitti> heno: https://wiki.ubuntu.com/Testing/ReportingResults is now pretty much obsolete, right? we should direct people to the iso test tracker in the annoucement now, I think
<pitti> heno: however, that depends on whether the iso tracker will accept tests of dailies
<pitti> heno: erm, no; I mean, accept tests after tribe has been released
* heno phone
<pitti> ogra: done with the seed changes?
<ogra> just running the update script
<ogra> uploading in a second
<pitti> ogra: hm?
<pitti> ogra: oh, noo
<pitti> ogra: I thought you would only need to change live, not desktop
<pitti> ogra: can't we chop off a langpack?
<ogra> hmm, indeed .... 
<ogra> how do i uncommit remotely :P
* ogra tries to just revert with the next commit
<pitti> bzr diff -r -2 | patch -Rp1 :)
<ogra> well, that wont wipe the history :)
<Hobbsee> bzr has an uncommit function, too.
<Hobbsee> dunno where remotely fits in, though
<Hobbsee> heh
<pitti> ogra: there is bzr push --overwrite, but I wouldn't use it for such official repos
<ogra> right
<ogra> i'll just revert it in a new commit
<pitti> I used it in the past with --overwrite on LP branches, works fine, but only on private branches
<ogra> hmm, whom do i upset now ... 
* ogra decides for pt .... portugal is the most distant one in the list, so its unlikely they show up at my house :)
<pitti> xubuntu desktop CDs up
<Hobbsee> ogra: haha.  nice reasoning.
<ogra> pitti. ok, seeds fixed ...
<pitti> ogra: thanks, building livefs then
<Lure-live> pitti, Riddell: kubuntu desktop: ubiquity crashed on manual partitioning, followed by crash of apport
<Lure-live> apport crash is in bug 118965, I will submit ubiquity bug manually
<ubotu> Launchpad bug 118965 in apport "apport-qt crashed with IOError in get_module_license()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118965
<pitti> Lure-live: erk, apport itself crashed?
<Riddell> Lure-live: I just got the same
<Riddell> ubiquity doesn't actually crash though, it recovers fine
<Lure-live> pitti: right, I got ubiquity crashed (even though partitioner window is still up!), then selected to report and apport-qt crashed
<pitti> "IOError: [Errno 4]  Interrupted system call", WTF
<Lure-live> Riddell: exactly
<pitti> I thought I fixed that some months ago in Python
<Lure-live> Riddell: so no need to report as you are on it? ;-)
<Lure-live> pitti: maybe your patch was dropped by merge
<pitti> Lure-live: no, I see it now: I only caught this situation in subprocess itself
<pitti> Lure-live: please wait before filing manually
<Lure-live> pitti: no problem
<pitti> Lure-live: if you do 'sudo touch /var/crash/*ubiquity*', it should re-trigger apport; does it work then?
<pitti> Lure-live: I'll change the apport code to use the guarded subprocess functions, that should help
<pitti> but preferably not for tribe-1
<Lure-live> pitti: nothing happens after tounc
<pitti> Lure-live: hmm
<Lure-live> pitti: there is /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash though
<pitti> Lure-live: right, but *ubiquity* should match on that
<Lure-live> pitti: I think ubiquity "crash" (which is not actually) is more problematic, but could be also only documented for tribe1 I suppose
<pitti> Lure-live: right, but we want a proper bug report for it
<pitti> Lure-live: "sudo touch /var/crash/*ubiquity*; sudo /usr/share/apport/apport-qt" should re-process the crash in apport
<Lure-live> pitti: I can open that with apport files manually attached (if Riddell is not doing it already)
<Riddell> Lure-live: go ahead
<pitti> Lure-live: right, but with above command it might be easier
<Lure-live> pitti: ok, now I got it
* Lure-live reporting bug in LP...
<pitti> Lure-live: so ubiquity actually continues to work?
<Riddell> pitti: yeah, no problem actually visible to the user
<pitti> Riddell: cool, so we'll only release-note this
<Lure-live> pitti: yes - it passed the parition step, will try to complete install after I submit this bug
<Riddell> fine with me
<pitti> I did a manual-partitioning Ubuntu install without a problem here, hmm
<Lure-live> pitti, Riddell: bug 118967
<ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118967
<Lure-live> will continue installation now
<pitti> Lure-live: thank you! can you please add that to the bug list in the iso tracker as well?
<Lure-live> pitti: will do
<pitti> Lure-live: *hug*, thanks
<pitti> Riddell: seems KDE specific, I assing this to you if you don't mind
* Lure-live hugs pitti with his new RM hat ;-)
<Riddell> pitti: ok
<Riddell> although if evand fancies taking a look at it.. 
<pitti> Riddell: oh, sure :)
<pitti> Riddell: delegation is a chain with more than one element :-P
<Lure-live> pitti: ;-)
<evand> will do
<Lure-live> can somebody pass isotracker URL?
<pitti> Lure-live: see topic
<pitti> I just wrote some details to ubuntu-devel@, too
<Hobbsee> https://isotesting.stgraber.org/
<Lure-live> pitti, Hobbsee: thanks
* evand fetches kubuntu daily-live
* Hobbsee doesnt fetch any, already having been told off for bandwidth use thsi month.
* desrt hugs his ISP
<Lure-live> pitti, Riddell: https://isotesting.stgraber.org/isotesting/result/36/54
<Hobbsee> desrt: you live in a decent country.
<Hobbsee> desrt: the au shoestring broke last night.  au is not good for a tech place.
<pitti> Hobbsee: heh, I got the '80% of quota limit' mail a few hours back
<desrt> Hobbsee; is that a figure of expression or did something actually break?
<Hobbsee> desrt: oh it broke.
<desrt> like your cable that plugs you into the rest of the net?
<Hobbsee> desrt: http://www.smh.com.au/news/wireless--broadband/telstra-restores-service-after-broadband-meltdown/2007/06/06/1181089114356.html
<Hobbsee> the isp broke
* ogra is near to buy new hardware for install tests ... somehow virtualbox doesnt like me today hanging at random places ...
* Hobbsee can fix the cable easily enough
<desrt> ah
<ogra> and i only need to know if the ltsp step works, grumble 
<desrt> Hobbsee; no... i mean the big undersea cable from australia to [world] 
<desrt> Hobbsee; i imagine you can't fix that one very easily :p
* Lure-live loves his unlimited plan ;-)
<Hobbsee> hehe
<Hobbsee> true that
<desrt> a friend of mine works for my ISP
<desrt> they track badnwidth use... but don't do anything about it
<desrt> supposedly they have this guy that regularly pushes (sometimes exceeds) 1TB monthly use
<desrt> they called him up once
<desrt> he's like "ya.. i do a lot of downloading"
<desrt> they were like "cool.  just making sure it wasn't a virus or anything"
<desrt> it's really really unlimited.... even if you're an abusive prick :p
<Hobbsee> hehe
* Lure-live reboots to test Tribe1 install
<heno> pitti: yes, that's obsolete (cleaning up test pages in the wiki is on my list ...) We can take test feedback on the tracker under the name 'Tribe 1' after release
<pitti> heno: great, thanks
<pitti> heno: I announced a call for testing on ubuntu-devel@, now all images are complete
<ogra> grmbl
<heno> pitti: great, thanks
* ogra kicks virtualbox in the guts
<pitti> ogra: edubuntu live up now as well, but WTF? still oversized
<ogra> erm, dont i need to rebuild -meta ?
<pitti> ogra: seems it didn't actually pick up the branch changes
<pitti> ogra: no, not for live
<ogra> i'm always unsure about that at the start of a cycle ...
<ogra> according to LP its in the branch ... 
<ogra> so we'll likely only need another livefs
<pitti> ogra: you only dropped it for amd64
<pitti> ogra: well, 20070606.2 is the new livefs that was just built
<ogra> oh crap
<pitti> ogra: hm, tricky, on i386 you do not have any more language packages to drop
<ogra> i386 doesnt have any langpacks
<pitti> ogra: but still, amd64 is oversized too, so why didn't it pick up the branch changes...
<pitti> ogra: ok, then I guess we have to go through removing arabeyes and rebuild -meta *sigh*
* pitti sets publisher on manual again
<pitti> ogra: please upload edubuntu-meta, I'll shove it through publisher and buildds
<ogra> pitti. if you are sure amd64 will be fine i can easily drop all gcompris-sound packs for now
<ogra> they are i386 only 
<ogra> and only in live
<ogra> i dont care about that stuff for a first milestone
<pitti> ogra: I'm not
<pitti> ogra: the recent livefs build didn't pick up the seed change, no idea why
<ogra> ok, but since we'll have to convice iut somehow to do that, we can assume amd64 will be fine then ...
<ogra> dropping the sounds will save us the -meta rebuild
<pitti> ogra: ok, fine for me
<ogra> ok, pushing
<pitti> ogra: hmm, http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/edubuntu/gutsy/daily-live-20070606.2.log does have the removal of -pt, no idea
<pitti> ogra: ok, rebuilding fs
<cjwatson> Riddell: ubiquity> hmm, doesn't seem like that ought to be a new bug in gutsy
<cjwatson> Riddell: but go ahead and check it straight into trunk if you find a fix
<Riddell> cjwatson: evand seems to be having first shot at finding it
<cjwatson> good-oh
<evand> indeed, though the iso is taking its sweet time to download and it appears to be qt-specifc.
<cjwatson> about all I can say is that it looks like an empty list, but no idea why
<Keybuk> oh, wow
<Keybuk> Fedora hardcode the name of the root disk into their initramfs
<pitti> ogra: something is absolutely wrong here: http://cdimage.ubuntu.com/edubuntu/daily-live/20070606.3/
<pitti> ogra: still oversized
<pitti> *W* *T* *F* ??
<wasabi> Keybuk: Eh, how can you manage that?
<Keybuk> wasabi: ?
<pitti> ogra: oh, wait; I guess there is a second CD, and CDimage probably just cap'ed the first one too big as well?
<wasabi> hard coding the root disk name?
<wasabi> That seems impossible to actually make work
<Keybuk> wasabi: it's in their init script hardcoded
<wasabi> What is? /dev/hd or /dev/sd?
<Keybuk> /dev/VolGroup00/LogVol00
<wasabi> oh. Hah.
<wasabi> They use lvm by default?
<Keybuk> seems so
<wasabi> Nifty. We should do that. :0
<pitti> ogra: hmm, no; http://cdimage.ubuntu.com/edubuntu/daily-live/20070606.3/gutsy-desktop-amd64.manifest still has the pt langpack and gcompris-sound
<Keybuk> wasabi: I have zero objection to lvm-by-default
<Keybuk> it's evms that keeps me awake at night <g>
<wasabi> What about removing lvm and md and using evms by default? :)
<wasabi> That'd be my vote.
<Keybuk> wasabi: evms doesn't work with 2.6
<Keybuk> so BZZZT
<wasabi> Doesn't work without hacks anyways
<Keybuk> where hacks = patching out kernel features
<wasabi> Hey, why is that anyways?
<Keybuk> actually, evms-like-features should be in the kernel
<wasabi> Some new thing that only allows one subsystem to control a block device or something?
<wasabi> evms doesn't actually rally have any features. It does everything with md and lvm and devmapper
<Keybuk> only one thing may claim one block device at once
<Keybuk> e.g. you can't mount it twice
<wasabi> Okay, evms doesn't cause an issue with that.
<wasabi> Just... don't mount it with anything else
<wasabi> remove the kernel partition table support and you're golden
<Keybuk> it really screws over people who have evms installed and don't want to use it
<Keybuk> for anything
<Keybuk> you have to use it for *everything*
<Keybuk> even USB devices
<wasabi> Well, yeah, but that doesn't really *use* evms
<wasabi> alll evem does is construct devmapper nodes for the partitions
<wasabi> Which is arguably better done by evms using devmapper anyways
<wasabi> evms has no kernel presense.
<Keybuk> which doesn't work if the partition is being mounted
<pitti> ogra: seriously, I'm at loss with this; we should figure this out with cjwatson
<wasabi> Keybuk: Which partition?
<Keybuk> wasabi: on the USB stick
<Keybuk> wasabi: tbh, my absolute major concern with evms is that nobody appears willing to maintain it
<wasabi> Huh? 
<Keybuk> or fix some of its fundamental problems
<Keybuk> which means it's utterly out as a default option
<Keybuk> and shouldn't even be in main!
<wasabi> Yeah, that's my major problem too. It's not any sort of priority for anybody.
<wasabi> (ya'll)
<Keybuk> wasabi: that includes community members <g>
<wasabi> uh huh
<wasabi> You know that the kernel hack goes away if you use evms to construct all partition s(even for usb disks) from user space, right?
<wasabi> The problem is /dev/sda1 and /dev/evms/sda1 both existing.
<Keybuk> right
<wasabi> So simply remove /dev/sda1, and link it to /dev/evms/sda1
<Keybuk> the problem is also that /dev/evms/sda1 exists at all
<Keybuk> since that means evms is trying to manage /dev devices
<Keybuk> it should leave that to udev
<pitti> cjwatson: edubuntu live was oversized suddenly, so ogra first dropped the pt langpack off amd64 (in 20070606.2) and then gcompris-sound-* from i386 (in .3); yet, those packages still appear on the live systems
<wasabi> Yes, a bug that should be fixed. :)
<wasabi> You're not forced to usr /dev/evms though, you can use /dev/mapper
<pitti> cjwatson: does anything need to happen to the seeds (mirroring somewhere etc.) before cdimage picks them up?
<Keybuk> wasabi: it's just a general indication of its evilness
<wasabi> It's a general indication of it's less than well maintained-ness.
<wasabi> Didn't used to have udev
<wasabi> Do you think it sucks as a technology though?
<pitti> cjwatson: my guess is "no", since the the logs do show the diff of the seeds in "Checking for other task changes"; however, at the end the packages are still there
<Keybuk> wasabi: I think that evms should be un-necessary
<wasabi> Why?
<Keybuk> ie. the kernel should present "disks", and we should be able to allocate block devices on those however we want
<wasabi> I don't follow.
<Keybuk> ZFS style
<wasabi> Oh.
<Keybuk> evms is a huge amount of code to work around the fact that the kernel doesn't do it by default
<wasabi> I don't really think that. I think evms is just a pretty interface and API to what the kernel already does.
<iwj> Dammit, how long does it take libc to build ?
<wasabi> I don't really think pretty API and interface belong in the kernel...
<Keybuk> wasabi: it didn't seem that pretty to me
<wasabi> The API?
<Keybuk> devmapper seemed easier to understand
<wasabi> evms *is* devmapper
<wasabi> wait... let me rephrase
<wasabi> what about pumping mapping characters into devmapper do you find pretty?
<Keybuk> I don't need to, LVM seems to do taht
<iwj> Keybuk: Did you get a chance to look at my new disk full testing spec ?
<wasabi> So you think raid and lvm should be integrated?
<Keybuk> iwj: not yet, sorry
<Keybuk> wasabi: sure
<ogra> pitti. dinner time for me, i'll look through the logs afterwards, there must be something in there
<Keybuk> I just think we should have disks and filesystems
<pitti> ogra: I need to leave soon as well
<pitti> ogra: ok, will you care for this?
<Keybuk> "give me a 4GB mirrored filesystem" => then let the $something worry about how it gives it to you
<wasabi> I guess I'd agree.... I just don't think what you want is going to happen in the next 10 years.
<pitti> ogra: not sure whether you'd want to release edubuntu live oversized...
<wasabi> And I think evms is a much better solution to typing mdadm and lv* commands until then.
<cjwatson> pitti: live seed changes require edubuntu-meta uploads
<ogra> pitti. i'll care, dont worry, its not the end of the world to skip one flavor for one iso with the first milestone
<cjwatson> pitti: and then a livefs rebuild after that's been published
<pitti> cjwatson: erk, since when is that?
<cjwatson> pitti: since ages
<ogra> cjwatson. hah, damned, i'm always unsure if we start a new cycle
<cjwatson> there is a brief delay in seed propagation, but as you say it doesn't sound like that
<iwj> Keybuk: IWBNI you could at least skim it to see if it was the kind of thing you were after ...
<ogra> pitti. updating the package
<pitti> cjwatson: hm, I was never aware of rebuilding -meta whenever I dropped langpacks
<Keybuk> iwj: sorry, I've been swamped by a zillion things the last couple of days.  it is high on my priority list
<pitti> ogra: ok, if that helps; neither edubuntu-desktop nor -server sound matching for a change of the 'live' seed, so I wasn't sure
<wasabi> I sort of like EVMS's potential to allow commercial people to write plugins for it too... it's not just restricted to md and lvm... you can write a plugin to manage your... oh, Adaptec Card. And the abilities of hte card will integrate into the interface.
<iwj> Keybuk: Fair enough.
<wasabi> And expanding and shrinking operations will take everything into account, the file system, the adaptec card, the lvm stuff ontop of that.
<pitti> cjwatson: out of interest, how can the 'live' seed affect -meta?
<iwj> Oh well, I'll let this build go on overnight.
<pitti> ogra, cjwatson: as I suspected: 'no changes found' when updating edubuntu-meta, and the seed update propagated correctly
<pitti> ogra: this must be something else
<pitti> but I really gotta leave now, sorry
<Lure> pitti: btw, similar install on desktop (also manual partitioning) -> no false ubiquity crash reported
<Lure> pitti: I suspect that crash is related to same partition setup
<Lure> s/same/some/
<ogra> pitti. its fine, i'll deal with it
<pitti> ogra: thanks; I just hate to not understand the reasons for such things :/
* pitti -> really off now, cu tomorrow
* iwj goes too.  TTFN all.
<Keybuk> how do I change a gconf key default?
<ogra> Keybuk. add an override file
<ogra> add /usr/share/gconf/defaults/20-sottslittlesectres :)
<ogra> gah, cant type
<Keybuk> s'ok found it
<ogra> ogra@laptop:~$ cat /usr/share/gconf/defaults/20-edubuntu 
<cjwatson> ogra: (and pitti, but he's gone) oh, argh, I'm really sorry, I misremembered - we took live *out* of -meta a while back
<ogra>  /desktop/gnome/interface/icon_theme gartoon
<ogra> etc ertc
<dholbach> debian/gconf-defaults
<cjwatson> ogra: it could be that pitti forgot a livefs rebuild, I'm not sure
<ogra> cjwatson. hmm, i'll ask infinity for one then and do an iso rebuild
<ogra> or can somebody else trigger that too nowadays
<ogra> ?
<ogra> infinity. ping ? can you do an edubuntu livefs build for me ?
<alex-weej> does anyone know how to debug USB mass storage? it appears that two separate Nokia 5300s (exchanged by courier for another reason) are not playing nicely with Feisty
<alex-weej> they work fine when browsing with a file manager, but if you let Rhythmbox scan the whole volume (i.e. if you have Rhythmbox running when it connects) , it hangs for a minute or so and then eventually pops up an "unsafe device removal" warning
<cjwatson> ogra: you can
<cjwatson> ogra: cdimage@lithium$ buildlive edubuntu
<cjwatson> it's in the crontab there
<ogra> oh, great, since when is that ? 
<cjwatson> Date: Tue, 23 Jan 2007 12:04:31 +0000
<cjwatson> From: Colin Watson <cjwatson@ubuntu.com>
<cjwatson> To: Jonathan Riddell <jriddell@ubuntu.com>,
<cjwatson>         Oliver Grawert <ogra@ubuntu.com>
<cjwatson> Subject: Building live filesystem images
<cjwatson> since then ;-)
<ogra> oops
* ogra blushes
<pygi> hey folks!
<bryyce> heya
<tseliot> hi
* cjwatson blinks at apport
<cjwatson> NonfreeKernelModules: cdrom
<pygi> fabbione, have a sec?
<fabbione> pygi: 1
<fabbione> your time is up
<fabbione> :)
<pygi> fabbione, hehe :)
<pygi> fabbione, wanted to find out where can I find build log of i386, so I could compare if something's missing :)
<pygi> (build log for brasero i386 ofcourse :))
<fabbione> pygi: they should be on LP...
<pygi> fabbione, got that, don't know where tho o.O
* pygi goes looking
<fabbione> pygi: you are really begging me to send you to google... aren't you? :)
<pygi> fabbione, but my friend, I already used the google! :)
<elmo> I hate kernel modules - when they're elided they trigger my nick highlighting :-/
<pygi> ha, found it =)
<pygi> fabbione, sorry for taking your time ;)
<fabbione> http://launchpadlibrarian.net/8004448/buildlog_ubuntu-gutsy-i386.brasero_0.5.90-0ubuntu1_BUILDING.txt.gz
<pygi> fabbione, thanks, found it ^_^
<fabbione> pygi: do i get a beer? do i get a beer? :)
<pygi> fabbione, when I meet you, sure =)
<fabbione> ok cool... 
<pygi> just remind me, it might take a while :P
* fabbione wipes pygi's nick from the list of lazy guys
* fabbione puts it back
<fabbione> :)
<pygi> lol :)
* pygi doesn't think he's lazy :'(
<pygi> fabbione, why do you think I'm lazy? :P
<fabbione> pygi: dunno... my female instinct
<pygi> I wouldn't rework 6000 lines of code in a week if I was lazy :P
<Riddell> BenC: the MCE guy with the nvidia problem says he isn't using a hand made install but its down to the wrong module loading, does that seem plasuable? http://paste.ubuntu-nl.org/24459/
<pygi> fabbione, ha! Think I got it :)
<fabbione> pygi: i can change 6000 lines of code in 2 minutes... wanna bet? :P
<fabbione> while read line | sed....
<fabbione> ;)
<pygi> fabbione, I don't count indent, sorry :)
<pygi> meh, I reworked core components, and the way it works :(
<fabbione> just teasing...
<pygi> fabbione, do you have access to sparc/ppc? there's two lines fix I wanna try :)
<fabbione> sparc.. probably... ppc no
<pygi> yay :)
<fabbione> but not right now.. send me the patch and i will test it tomorrow
<pygi> oki doki ^^
<fabbione> it's evening and i don't feel like powering on a nuclear reactor
<pygi> sure, don't worry
<fabbione> the small one at the moment doesn't really boot...
<fabbione> did play a bit too much
<pygi> hehe
<pygi> isn't too important right now, don't worry :)
<pygi> I found lines that really don't have ";" at the end
<pygi> weird that other arches ignore it tho
<ogra> cjwatson. hmm, it doesnt get picked up, the iso is still oversized
<ogra> cjwatson. i see a lot moaning about duplicated seeds of gcompris-sound packages in edubuntu/daily-live-20070606.4.log
<ogra> which are supposed to be not in the livefs anymore ... could there be something wrong with the ship-addon hack ?
* ogra doesnt understand whats going on there
* ogra guesses the buildd didnt pick up the seed change ... the livefs buildlog still shows all gcompris packages
<cjwatson> ogra: it does need a publish run before you start the livefs build
<cjwatson> because it has to propagate into the Task headers in the Packages files
<cjwatson> ogra: which packages in particular?
<cjwatson> ogra: ship-addon has no effect on live
<cjwatson> unless somebody has been messing with STRUCTUE
<cjwatson> +R
<ogra> gcompris-sound-it gcompris-sound-pt gcompris-sound-ru gcompris-sound-sv gcompris-sound-es gcompris-sound-fr   gcompris-sound-de
<ogra> yeah, that was just a silly guess out of desparation
<ogra> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/edubuntu/20070606.6/livecd-20070606.6-i386.out still has all of them
<ogra> thats the last i386 build ...
<cjwatson> ogra: oh, argh, I see what's happened
<cjwatson> ogra: there were no packages to publish for gutsy (because we're frozen), so the publisher skipped it
<ogra> ouch
<cjwatson> which meant it didn't apply the germinate changes either
<cjwatson> ogra: I've worked around this by accepting a few universe uploads
<ogra> ok
<cjwatson> ogra: so in about an hour's time when the next publisher run has finished, you should be able to kick off YA livefs build
<ogra> so the next build should pick it up ?
<ogra> oki
<ogra> is that something pitti should know ? 
<cjwatson> be careful to wait that hour though; it definitely won't work before then
<cjwatson> yes, it's also something that should be fixed in soyuz
<cjwatson> I mean, it's something pitti should be told, not necessarily something he should have been expected to know
<ogra> well, thats what i meant
<cjwatson> I know, just realised it was ambiguous
<ogra> i didnt expect him to know :)
<ogra> it was rather a bad way of saying "that should be in the readme" :)
<bryyce> glatzor: heya
<cjwatson> it should be fixed
<glatzor> hello bryce
<cjwatson> I didn't know about it until now, actually
<mvo> hey glatzor!
* mvo hugs glatzor
<cjwatson> I knew about all the pieces and so could put it together once the idea occurred to me
* glatzor hugs mvo
<ogra> ah
<glatzor> mvo: even nurses don't work so late :)
<ogra> well, depends on he shift no ?
<ogra> *the
<mvo> glatzor: good point
<mvo> glatzor:  I should stop
<pygi> mvo, o no, not before you build :)
* pygi hides =)
<mvo> glatzor: I made some progress with xrandr1.2, I think it comes together (slowly)
<tseliot> hi all
<glatzor> mvo: whoa. cool
<bryyce> mvo, glatzor, I've been talking with tseliot about displayconfig-gtk and bulletproof-x
<mvo> glatzor: but I need to sit down and write a nice interface around it, currently its all a bit messy
<mvo> bryyce: great, more hands! 
<bryyce> mvo, glatzor, here is what he's been working on:  http://albertomilone.com/wordpress/?p=93
<tseliot> I saw you're using randr's C code
<tseliot> btw, a guy is helping me to change the UI
<mvo> tseliot: yes, I'm working on ctypes bindings so that the native C api can be wrapped
<tseliot> that's the best approach
<mvo> tseliot: are you the one behind the gui frontend for the xrandr binary?
<tseliot> yep
<mvo> nice work!
<tseliot> I don't know C yet
<mvo> I saw some screenshots on the planet 
<tseliot> the new interface looks much better
<tseliot> ;)
<mvo> :)
<tseliot> it already works
<tseliot> it only lacks a logger
<mvo> is your code available in some public repository?
<tseliot> not yet
<tseliot> you know I would like to clean it a bit
<mvo> maybe we can try to agree on a python interface so that we can have a backend based on calling binary and a backend based on the ctypes implementation  
* glatzor is a little bit sad that tseliot was faster :)
<mvo> haha
<bryyce> :-)
<tseliot> hehehe
<tseliot> I only used xrandr's output
<tseliot> then I manipulate the output
<glatzor> tseliot: you mentioned the current git version of xrandr? Does it contain a lot of improvements?
* pygi wonders how good parsing output is, as it might easily break :(
<bryyce> glatzor, btw, I found some errors in the code currently in bzr - I posted a patch to comment out the bits of code that were complaining
<bryyce> glatzor: wasn't sure how to fix them
<tseliot> I can't compile it
<tseliot> at least yesterday it didn't compile
<tseliot> Keith Packard told me that
<glatzor> bryyce: oh, I already rejected your bug. :)
<tseliot> the new randr allows you to select between PAL/NTSC
<bryyce> I trust that's because you had some real fixes? ;-)
<glatzor> bryyce: to use the glade file of the bzr repository you have to use the --data-dir=data option
* mvo needs to leave for 10min and water the garden
<mvo> bryyce: or build it with debian/rules arch-build and install the debs in debian/arch-build
* mvo will read scrollback
<bryyce> glatzor: hmm
<glatzor> bryyce: the DisplayCOnfig class is an inherit of SImpleGladeApp that makes all the glade widgets attribute of the class
<glatzor> oh awkward grammar :)
<tseliot> mmm
<glatzor> SimpleGladeApp provides all glade widgets as attributes of the class
<tseliot> yes, that was clear :-)
<tseliot> where's the gladefile?
<bryyce> ah ok.  perhaps a README would help.  before it ran out of bzr without needing that
<bryyce> tseliot: there's one in the data/ dir
<tseliot> ok, thanks
<bryyce> glatzor, with this I still get an error:  $ ./displayconfig-gtk --data=data/displayconfig.glade                                            
<bryyce>     from displayconfigabstraction import *
<bryyce> ImportError: No module named displayconfigabstraction
<glatzor> bryyce: sudo ./displayconfig-gtk --data-dir=data
<bryyce> same thing with ./displayconfig-gtk --data-dir=data/                                                         
<glatzor> bryyce: you need to install the guidance-backends
<tseliot> it works well here
<bryyce> ahh, right this is my feisty system, that's not available for it
<glatzor> bryyce: YOu can find feisty packages in my file repository that I mentioned in my last mail
<tseliot> but I'm using feisty
<tseliot> o_O
<glatzor> tseliot: bryyce: http://glatzor.de/filesink/displayconfig/feisty/
<tseliot> I mean that it's working on feisty
<bryyce> ok cool, got it up on my gutsy system
<tseliot> it's not fully functional but I guess it parsed my xorg.conf
<glatzor> tseliot: bryyce: I just pushed my today's train ride outcome. So perhaps worth to update your repositories
<bryyce> ok
<glatzor> tseliot: what problems do you have?
<glatzor> tseliot: by the way where is your bzr repository for the xrandr gui?
<tseliot> I didn't set up a bzr repository yet
<glatzor> bryyce: I hope that we will get a shared guidance repository soon
<glatzor> bryyce: then we can work more on the backend
* bryyce nods
<tseliot> glatzor: what's your bzr repo?
<glatzor> tseliot: every Ubuntu project needs a bzr repository :)
<cjwatson> ogra: ok, cprov and I have come up with a plan which I think I can write a patch for
<ogra> cool
<tseliot> Ok, I'll set up one then
<glatzor> tseliot: och, for displayconfig-gtk I merge changes of my local branches to the ubuntu branch
<pygi> glatzor, we should all use mercurial or git :P
* pygi hides
<tseliot> I'm getting the code with bzr
<bryyce> tseliot, glatzor, what do you think the potential is for joining forces, as opposed to having two separate xrandr gui config tools?
<tseliot> bryyce: it's a good question
<tseliot> we're using a different approach
<tseliot> therefore I don't know where I can help
<M_A_K> Sorry to bother here, but how / who do I tell that I think NIS is broken as of a recent feisty update?
<M_A_K> I've tried to ask in #ubuntu and #kubuntu, bot no answer.
<cjwatson> Lure: could you try to reproduce bug 118967 with 'ubiquity --debug', please?
<ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
<bryyce> glatzor: what do you think?
<cjwatson> actually, I'll put that in the bug
<Lure> cjwatson: I can try later tonight (as I am working on this machine currently)
<mvo> tseliot: what do you think about the "sharing a abstract interface to xrandr1.2" idea? this way we could share a lot of work. we could use the xrandr binary-calling backend initially and at some point switch to the c-based implementation
<mvo> and we could try to agree on a gui 
<mvo> I understand that the backend that uses the xrandr binary works already, whereas the ctypes implemntaiton in ~30%-50% done (at most)
<tseliot> ok
<mvo> bryyce, glatzor: what do you think about this?
<tseliot> I will definitely have to clean and comment my code a bit
<bryyce> mvo, I'm definitely a fan of working together as much as possible
<mvo> that is no problem :) my current xrandr ctypes prototype can be used to scare small children ;)
<tseliot> :-D
<glatzor> mvo: tseliot: bryyce: as tseliot already mentioned we have got different goals. But I think that it can still be very inspiring: for the user interface and the backend
<tseliot> ok :)
<tseliot> I have tried displauconfig from bazaar and installed guidance
<tseliot> I have a question for you glatzor
<tseliot> it seems to detect 2 displays on my laptop
<tseliot> however it says that screen 2 is disabled
<tseliot> the problem is that screen 2 doesn't exist
<tseliot> and the driver is detected as i810 but I'm using the intel driver
<glatzor> tseliot: the backend makes some assumptions that are perhaps not always the best :)
<glatzor> tseliot: 2 displays are regarded as a standard feature of laptops
<glatzor> tseliot: so all laptops have got a second display for guidance
<glatzor> tseliot: But I also tought about disabling this
<tseliot> you can see whether an app is connected through randr
<tseliot> I mean a device, not an app
<tseliot> sorry
<glatzor> tseliot: Think of the users: "Hey, my laptop has  got a second hidden device. The bad hardware vendor have included all the hardware but not a plug!"
<bryyce> glatzor, don't know if you saw it but I also sent in a patch to add --version support
<tseliot> LOL
<glatzor> bryyce: oh, it is already commited
<glatzor> bryyce: why do you want to change the usage info?
<glatzor> bryyce: I skipped this part
<bryyce> ah, didn't see it in the changelog
<glatzor> bryyce: It was some minutes ago :)
<bryyce> oh!
<bryyce> what was the usage info before?  I actually didn't look to see if it was already printing something
<glatzor> tseliot: one of our main problems is that we have got two resources of information: the xorg.conf and the live detected data
<tseliot> that's what I was going to ask
<tseliot> does displayconfig test whether the driver supports randr 1.2?
<glatzor> tseliot: so we guidance tries to detect the screens.  but we cannot make a clear connection between them.
<glatzor> tseliot: it is just hopping that the first detected device is also the first device in the config
<glatzor> tseliot: not yet.
<mvo> that is why we would need that abstract xrandr python interface ;) 
<tseliot> :-D
<glatzor> tseliot: there is already an instant apply infrastructure in guidance that e.g. applies resolution changes immediately.
<glatzor> tseliot: so this is the place where we can hook in.
<glatzor> tseliot: have you managed to get the desktop merging running?
<tseliot> I haven't tried it yet
<glatzor> tseliot: I always have got the problem that I am limited to resolutions that are not usable
<glatzor> tseliot: e.g. two 640x480 screens 
<tseliot> glatzor: did you set the virtual resolution
<tseliot> in your xorg.conf?
<glatzor> tseliot: nope.
<tseliot> glatzor: wait, did you mean something like Nvidia's twinview or distinct workspaces on 2 displays?
<glatzor> tseliot: mergedfb that is used by xrandr 1.2
<tseliot> glatzor: e.g. putting one screen beside the other?
<tseliot> if so then I did it
<glatzor> tseliot: the xinerama setup works like a charm to praise myself :)
<glatzor> bryyce: have you already tested the locations?
<glatzor> tseliot: right.
<bryyce> not yet
<bryyce> glatzor: xinerama still segfaults for me
<glatzor> bryyce: which chipset?
<tseliot> glatzor: it works, however KDE seems to mirror some windows on the 2nd screens
<tseliot> glatzor: there are some graphical corruptions
<glatzor> bryyce: on Saturday there will be our next LUG meeting. I hope that I can test some systems there :)
<bryyce> glatzor, radeon R350 + RV280
<glatzor> bryyce: two cards?
<bryyce> I just tried out the location bar, and got an error with it - "No such file or directory: '/var/lib/displayconfig-gtk/locations/home.conf'
<bryyce> yup
<glatzor> bryyce: have you compared the configs with the ones created by the ati tool?
<bryyce> well, one card plus one on-board
<bryyce> no I haven't used the ati tool
<glatzor> bryyce: please fill a bug and attach xconfig and pcitable
<tseliot> glatzor: back on the virtual resolution
<glatzor> bryyce: oh, you have to create the directory /var/lib/displayconfig-gtk/locations
<glatzor> bryyce: this is done by the package but it should also be done by the code
<tseliot> glatzor: you should set a virtual resolution which can contain both resolutions
<bryyce> glatzor: ahh, ok
<glatzor> tseliot: I get more and more the impression that xrandr will not avoid hacking on the xorg.conf :/
<tseliot> glatzor: it's only an option
<tseliot> glatzor: and I think it would be easy to set
<glatzor> tseliot: so easy to automate it?
<bryyce> glatzor: why are there two cards listed on the graphics card page?  It has i810 and vesa shown
<tseliot> glatzor: yep
<glatzor> bryyce: you are using the fallback xorg?
<tseliot> glatzor: I think that using the re module would be (almost) enough
<glatzor> tseliot: from data source do you want to calculate it?
<bryyce> glatzor: not intentionally
<glatzor> bryyce: the backend has got a problem with dual head cards
<glatzor> in the fallback mode, since it was not written for this use case :)
<tseliot> glatzor: it's not hard but it would require the user to restart the Xserver
<glatzor> but I think this could be fixed 
<tseliot> glatzor: or maybe displayconfig can do that
<glatzor> tseliot: and that is the point where we loose all the benefits of xrandr
<tseliot> glatzor: I don't think it's hard to implement
<glatzor> tseliot: are there any problems using a too large citural size?
<tseliot> glatzor: nope
<tseliot> glatzor: randr tailors a part of the buffer
<glatzor> bryyce: this is documented in the TODO file
<bryyce> glatzor: great
<glatzor> bryyce: I am unsure if the locations should also include the driver and videoram settings
<bryyce> I'd need to better understand the usage model for the locations bar
<glatzor> bryyce: I already tested the locations in real life situations today :)
<bryyce> heh cool
<glatzor> bryyce: except of a bug, that is already fixed now it worked without any problems
<glatzor> bryyce: I have got a location at home with a dual screen setup and a location "on the road" with only a single display
<glatzor> bryyce: So I see the major use case in switching dual settings, connected screens and resolutions
<glatzor> bryyce: but perhaps there are people like mvo who can only suspend their laptop using the vesa driver
<glatzor> bryyce: it would be nice if he was allowed to switch the drivers in a nice way.
* bryyce nods
<tseliot> glatzor: that would require restarting the xserver
<glatzor> bryyce: there are also some people who prefer the open source nvidia driver for their daily work
<glatzor> tseliot: we always require restarting x :)
<glatzor> tseliot: xrandr is only used on single head systems
<tseliot> glatzor: ???
<glatzor> tseliot: xrandr 1.0 tends to crash xinerama setups
<glatzor> tseliot: so if you enable your second monitor in displayconfig you have to log off
<tseliot> glatzor: I wasn't aware of that problem
<tseliot> glatzor: do you use "sudo pkill Xorg" to restart the Xserver from displayconfig?
<glatzor> tseliot: that is why we are interested in getting xrandr 1.2 support
<tseliot> glatzor: aaah
<glatzor> tseliot: no we just send the USR1 signal to gdm
<glatzor> tseliot: gdm will restart the xserver when all users logged off
<tseliot> glatzor: ok that would be better if more users are logged in
<glatzor> tseliot: I haven't looked into the kde frontend.
<glatzor> tseliot: you are a KDE user, right?
<tseliot> glatzor: actually I'm a GNOME user
<tseliot> glatzor: ok, I use both
<tseliot> glatzor: I use pyGTK
<glatzor> tseliot: you mentioned kde before.
<glatzor> tseliot: pygtk rocks :)
<tseliot> glatzor: yes, it does :)
<glatzor> tseliot: so you already have got a branch available?
<glatzor> tseliot: pyqt isn't as nice as pygtk.
<tseliot> glatzor: I have never tried to make a branch
<tseliot> glatzor: maybe pyqt4 is better
<glatzor> tseliot: no
<glatzor> tseliot: software-properties was written with pyqt4
<tseliot> glatzor: this is why I have to learn C++ and QT4 ;)
<Riddell> what's wrong with pyqt4?
<Riddell> or even pyqt 3
<tseliot> hehehe
<glatzor> Riddell: unicode crashes :)
<mvo> haha
<glatzor> Riddell: and the designer + gettext issue
<Riddell> oh aye, string handing sucks
<Riddell> that too
<Riddell> mvo: wheesht yerself
* mvo wonders what that means
<tseliot> Riddel: is wheesht = wished?
<mvo> the "haha" was because I was wondering if you have a hightlight on "qt" ;)
<glatzor> Riddell: but apart from that pyqt is ok 
* mvo likes the treeview/listview in pyqt
<mvo> *much* better than the one in gtk actually ;)
<tseliot> :-P
<Riddell> mvo: the treeview stuff is one of the few parts of qt I find to be badly documented
<Riddell> I have a highlight on "kde"
<mvo> Riddell: you should look at the gtk one, that rendering buisness you have to setup for a sinple listview is really a bit much
<Riddell> oh totally
<Riddell> qt 4 has very complex/advanced model-view listviews, but if you don't need it the plain one is simple to use
<ajmitch> morning
<persia> Good morning ajmitch.
<mvo> hey ajmitch
<ogra> yay, my isos look much better now
<Seveas> ogra, they're now green?
<ogra> Seveas. is green better ? 
<Seveas> ogra, depends on taste :)
<ogra> heh
<LaserJock> hmm, "the .iso is always greener on the other side"?
<geser> "super green"?
<Seveas> greensleeves
<ajmitch> ogra: you mean they fit on a cd?
<ogra> so green you want to bring your lawnmower 
<ogra> ajmitch, no, the CD was oversized by exactly 1M
<ajmitch> ouch
<ogra> and somehow the buildd dint pick up the seed change
<ogra> took half a day of poking ... now its fine ...
<cjwatson> Riddell: I think my problem with pyqt is that I find the interfaces a lot less obvious - I get the feeling it's good if you know Qt, but it just doesn't feel as pythonic somehow
<cjwatson> (not that I'm the greatest arbiter of pythonicity)
<cjwatson> all horribly subjective though
<cjwatson> ogra: glad it's working now
<ogra> cjwatson, thanks for finding and fixing :)
<Riddell> cjwatson: I feel quite the same about pygtk
#ubuntu-devel 2007-06-07
<cjwatson> Riddell: heh
<cjwatson> guess it's all about familiarity in one form or another
<Riddell> cjwatson: oh, can you let koffice into feisty backports?
<agraveley> hey, i just had an awesome idea.  i come here looking for someone to do it for me ;-)
<agraveley> what about altering ubuntu auto*/pkgconfig to automatically apt-get install missing requirements when trying to build something from source?
<mjg59> That would be... interesting
<agraveley> So I can avoid the ``No package 'mybutt-2.0' found'' spew whenever I download a tarball
<mjg59> I'm not sure it would make sense as the default
<agraveley> sure, it could prompt, and ask for sudo
<mjg59> Yeah
<crimsun> how well does auto-apt work with that?
<agraveley> you guys altered bash to do that for uninstalled binary names, right?
<mjg59> agraveley: It's a bash module rather than an altered bash
<agraveley> neat
<mbiebl> Have there been any changes to gnome-menu in gutsy?
<mbiebl> I just upgraded from feisty to gutsy and now all the KDE kcm modules show up in the gnome menu (under "Others/Unknown")
<Toxicity999> What's everyones take on ZFS/Fuse? Just reading up on it and thought I'd score some more insight.
<wasabi> Oops. OS X gets ZFS.
<wasabi> s/Oops/Ooh/
<Toxicity999> wasabi haha yep I was reading that earlier, which led me into this fuse style ZFS implementation for Linux. Interesting stuff.
<Spastic__teapot> Hello everyone.
<Spastic__teapot> Anyone know who K. Mandla is?
<Kioshen> https://launchpad.net/~k.mandla ?
<fabbione> morning
<LaserJock> morning
<Burgundavia> hey fabbione, LaserJock
<spasticteapot> Will Enemy Territory be added to the Repository?
<Hobbsee> spasticteapot: if someone puts the work in and adds it, sure.
<Hobbsee> !motu
<ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<spasticteapot> Nice.
<Hobbsee> feel free to be that someone
<jml> I really should learn how to make Ubuntu packages.
<RAOF> jml: I'll help :).  We should package up Joybot sometime.
<jml> RAOF: yes
<RAOF> Maybe next month, particularly if radix does some more hacking on it.
<evand> doesn't the Enemy Territory license prohibit redistribution?
<Burgundavia> I have no idea
<evand> http://liberatedgames.org/licenses/RTCW-ET_End_User_License_Agreement.txt - looks like it, but IANAL
<LaserJock> we could probably ask for an exception if people wanted it enough
<Burgundavia> http://www.ubuntu.com/getubuntu/releasenotes/704tour
<Burgundavia> not listed here
<Burgundavia> http://wiki.debian.org/Games/Unsuitable?highlight=%28game%29
<Burgundavia> make that there
<Burgundavia> section 4 nukes it
<mfedyk> crimsun: hi, can we talk about bug 119033?
<ubotu> Launchpad bug 119033 in control-center "gnome-sound-properties should call asoundconf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119033
<mfedyk> ahh, I'm the reporter. :)
<Burgundavia> crimsun: I believe that would be your queue
<mfedyk> is this the right channel for bug discussion?
<mfedyk> or should I go to #ubuntu?
<jml> RAOF: btw, I've confirmed that I'll be up in Sydney in July
<Hobbsee> jml: yay.  we should have a ubuntu meetup
<jml> Hobbsee: for sure.
<jml> Hobbsee: I'm not sure if I'll be there for SLUG though
<Hobbsee> neither
<Hobbsee> but there's a thought
<pitti> Good morning
<Hobbsee> morning pitti!
<pitti> hi Hobbsee
<Hobbsee> :)
<pitti> ogra: ah, the new edubuntu live images are good size-wise; what did you change?
<RAOF> Hobbsee, jml: Yay!  Ubuntu party at my new flat! :)
<Hobbsee> RAOF: depends where it is :)
<jml> pshaw
<jml> as if it matters
<RAOF> In the very centre of Sydney, Kensington ;)
<jml> it takes 35mins to get anywhere in Sydney
<jml> unless it takes longer
<RAOF> Profound.
<StevenK> The problem is, Kensington is dreadful to get to, public transport or otherwise.
<LaserJock> pitti: I believe there was an issue where his seed changes didn't get taken because the publisher wasn't run
<Lure> pitti: [Wed Jun 6 2007]  [21:32:49]  <cjwatson> ogra: there were no packages to publish for gutsy (because we're frozen), so the publisher skipped it
<LaserJock> pitti: cjwatson found something
<LaserJock> ah yeah, that's it
<Lure> pitti: [Wed Jun 6 2007]  [21:33:00]  <cjwatson> which meant it didn't apply the germinate changes either
<jml> RAOF: I try.
<RAOF> StevenK: Sorry, what?  It's on anzac parade, along which there's a bus every minute or so.
<Lure> pitti: [Wed Jun 6 2007]  [21:33:41]  <cjwatson> ogra: I've worked around this by accepting a few universe uploads
<pitti> Lure: oh, that's black magic;
<Lure> pitti: [Wed Jun 6 2007]  [21:34:57]  <cjwatson> I mean, it's something pitti should be told, not necessarily something he should have been expected to know
<pitti> Lure: I wasn't aware that live seed changes involve the publisher since cdimage seems to directly check out the bzr branch
* Lure hugs pitti ;-)
<Hobbsee> jml: maybe from inside the city, yes.
<pitti> Lure: right, I'll talk to cjwatson to have me enlightened
<StevenK> RAOF: Okay, public transport from where I live is 40 minutes to the city and 30 minutes from the city to Kensington.
<crimsun> mfedyk: -bugs for now.
<pitti> Lure: thanks for the heads-up
<crimsun> sorry, I was sleeping.
<RAOF> StevenK: Right.  As long as you're already in town, Kensington is a snap to get to :)
<dholbach> good morning
<Hobbsee> morning dholbach!
<Hobbsee> anyone know what time it is for stgraber at the moment?
<dholbach> heya Hobbsee
<dholbach> Hobbsee: it should be 09:12 for him iirc
<Hobbsee> right
<Hobbsee> thanks
<pitti> ogra: I fixed the edubuntu desktop CD versions and re-enabled testing for them in the tracker; go wild :)
<fabbione> pitti: i am testing a fix for the sparc kernel right now.... time between bug and fix = 27 minutes + email delivery time :)
<pitti> fabbione: amazing
<pitti> fabbione: can you please add this to a bug number, so that I have something to link to?
<fabbione> pitti: yes. once i verify the fix
<fabbione> it won't take too long
<keescook> I really should not be awake.  :)
<dholbach> keescook: good night!
<dholbach> :-)
<keescook> hi! just the person I was looking for.  :)
<keescook> did you see the changes I committed to python-lp-bugs?
<dholbach> no
<dholbach> I wondered where they went
<keescook> ah, I added the property "duplicate_of" to the Bug class.
<dholbach> did you push it to some place? or is it on your local disk?
<keescook> as well as subscriber lists and management, and set/clear of private and security flags
<keescook> should be pushed, I though.  perhaps I did something wrong?
<dholbach> normally we attach a patch to a bug report or link a branch to the bug, so somebody check it before it gets committed
<pitti> hey keescook 
<keescook> hiya pitti
<dholbach> but I can review it if you pushed it, that's fine
<dholbach> I just didn't find it
<dholbach> I don't think you're in the bughelper-dev team anyway, right?
<keescook> I think it was tied to bugsquad, not bh-dev, let me check
<dholbach> that branch is abandoned :-/
<keescook> oh, fantastic.  :P
<dholbach> because we had quite some people just committing to it
<dholbach> I'll add you to the team
<keescook> thanks.  yeah, I wonder where I found the only bzr path?
<keescook> s/only/old
<dholbach> http://code.launchpad.net/python-launchpad-bugs
<Fujitsu> Hum, gnome-terminal doesn't run on desktop-i386.
<keescook> dholbach: should I commit to the main branch or make my own?
<Fujitsu> Oh yay, that glib warning that has been floating around for a few days.
<dholbach> keescook: you can either attach a patch, or link a branch to the bug
<keescook> what's the best way for me to handle the merge?
<dholbach> you can try to branch the ~bughelper-dev branch and merge from yours
<keescook> can't I just do a "merge"?
<dholbach> merge from the bughelper-dev branch?
<keescook> right
<dholbach> you can try
<dholbach> or even try a pull first
<keescook> hm, it merged, but I only see a changelog diff
<dholbach> weird
<dholbach> let me check
<dholbach> oh right
<dholbach> that's fine
<dholbach> I just thought we had more commits to it since the move
<dholbach> it's just the changelog diff
<dholbach> *phew*
<dholbach> let me merge from the old branch and look at your patch
<keescook> okay
* dholbach hugs keescook
<keescook> :)
<keescook> so for future things like this, should I just make a branch on launchpad.net?
<dholbach> either that or attach the patch
<keescook> okay, cool.
<dholbach> we all do cross-review before pushing to the branch
<keescook> okay, sounds good.  I will use a branch then; I suspect I will continue to do more work on this.  :)
<dholbach> keescook: you ROCK
<keescook> thanks!!
<dholbach> I guess you'll be in touch with thekorn (#ubuntu-bugs) sometimes then
<dholbach> he's doing SoC project on it
<dholbach> and is currently re-working the API
<keescook> ah, cool.  I see he's got a branch.  what are his goals for it?
<dholbach> split the HTMLOperations file into separate files, make the API less bughelper centric, less arguments to constructors, more sense in general
<keescook> very cool
<dholbach> we worked too quickly on it in the beginning, now it's the time for refactoring :)
<dholbach> but I'm very happy with the progress in general
<dholbach> keescook: your patch looks very good
<keescook> for the security/private stuff I didn't want to have separate "set" routines since the LP interface is a single page.
<keescook> dholbach: great, thanks.
<dholbach> keescook: thanks again
<keescook> dholbach: sure! bdmurray talked about it a great deal when describing his workflow to me, so I figured I might try using it for security bug triage.  works great; much faster than clicking around in LP.  :)
<dholbach> ROCK
<dholbach> we need more of that on http://wiki.ubuntu.com/BugSquad/Diaries :)
<keescook> true.  I worry my bug workflow is rather specific.  *not security* *not security* *not private* :P
<dholbach> hehehe :)
<keescook> so, the BzrContributorHowto basically says I should make a new branch for every bug/feature that gets worked on.  that doesn't seem sane.
<dholbach> I haven't found the optimal workflow yet either
<keescook> seems like naming my branch "updates.kees" or something is better for an overall long-term branch
<dholbach> it has the advantage of just being able to use     bzr merge URL    to try a patch or to use codebrowse to look at it
<dholbach> I don't know if close-bug-by-commit-message already works
<dholbach> if so, that'd be another advantage
<keescook> true.  with apport, I've just used a separate branch (though my new branch got named poorly)
<dholbach> it'd be nice if the bzrlp could do a demo of that or something or explain their longterm vision of it, so we could adapt documentation and train people to make best use of it
<keescook> https://code.launchpad.net/apport  <-  hunh, it lists the bugs fixed by an assoicated branch if you link them in LP. neato
<pitti> keescook: yeah :)
<cjwatson> pitti: livefs images are built by the buildds, i.e. on separate machines from where cdimage checks out the seed branches
<pitti> cjwatson: right
<keescook> dholbach: I think I will just register a single branch for p-lp-b.  if that turns out to be wrong, I can start doing per-bug branches
<cjwatson> pitti: the code there does 'apt-get install minimal^ standard^ ubuntu-desktop^ ubuntu-live^ ...' which installs packages based on Task fields in the archive
<pitti> cjwatson: they are checked out straight from bazaar.lp.net?
<dholbach> keescook: rock on :)
<cjwatson> on cdimage? yes
<cjwatson> that only affects packages that go onto the .iso as .debs though
<cjwatson> maybe I should draw a honking big diagram at some point :)
<pitti> cjwatson: oh, ubuntu-live^ -- I guess that's where the publisher comes into play?
<pitti> cjwatson: My missing link was the need of the publisher to propagate live seed changes to the livefs builders
<cjwatson> right, exactly
<pitti> cjwatson: I still don't understand what and why it does, but at least I'm warned now :)
<cjwatson> it actually takes two publisher runs, which is very nasty
<cjwatson> the publisher consists of cron.daily which runs cron.germinate at the end
<cjwatson> germinate needs an archive to work off
<cjwatson> but its output also feeds back into the archive
<cjwatson> so it's a bit logically difficult
<cjwatson> germinate spits out (among other things) a file for each thing that turns into an archive task with a list of packages in that task
<pitti> cjwatson: ok, so whenever we change live seeds, we run the publisher twice and then rebuild the livefs, and live should be good again?
<pitti> ah, I see
<cjwatson> cron.germinate turns those into an extra override file
<cjwatson> which is then used as input to the next publisher run
<cjwatson> for the first publisher run, the seeds only need to be in place when cron.germinate runs, and in fact in a pinch you could probably even run cron.germinate independently
<pitti> cjwatson: clear now; this made me bite into the table yesterday, since it's rather non-obvious :)
<cjwatson> I think it sets all the environment variables it needs for itself
<cjwatson> the fact that the publisher does not spot that the extra overrides have changed and republish the affected suites as a result is a bug
<cjwatson> cprov and I came up with a plan to fix that, which is relatively straightforward (i.e. implementable by somebody like me)
<saispo> argh: d-bus problem in gutsy ?
<RAOF> saispo: Not for me?  What sort of dbus problem are you seeing?
<saispo> dbus-launch is missing
<RAOF> saispo: Deliberate.  It's now in dbus-x11
<saispo> RAOF: ok thanks, will relaunch my session
<saispo> brb
<shawarma> Just a thought: Maybe the installer shouldn't refer to /dev/sd* devices as SCSI harddrives anymore.
<fabbione> shawarma: SCSI is not just the hw bus but the protocol you use to talk to the device...
<cjwatson> shawarma: yeah, there's a bug about that
<fabbione> shawarma:  i see no problem to say we talk SCSI to some ATA devices when the translation is done transparently
<shawarma> fabbione: True. Nevertheless, it seems wrong.
<cjwatson> I think it should probably just say "storage device" now or something
<shawarma> fabbione: Users are going to be confused when their IDE drives are referred to as SCSI.
<cjwatson> they are, and they file bugs
<cjwatson> particularly when they have both IDE and SCSI, when they get lost and panic
<fabbione> shawarma: yeah true that
<stgraber> dholbach: it's right I'm at UTC+2, but was at school :(, Hobbsee is UTC+10 right ?
<pitti> hi stgraber 
<cjwatson> Lure: sorry for my screwup in bug 118967 - see my comment there
<ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
<Lure> cjwatson: no problem - will do later today (at work now)
<dholbach> stgraber: not exactly sure, but your estimation might be right, yes
<shawarma> cjwatson: Doesn't ata_id reveal what type of disk it actually is?
<shawarma> cjwatson: Hm.. No, it seems not.
<Kmos> pitti: hi! you see my mail ?
<Kmos> about gqview
<pitti> Kmos: I got it, but I don't have time for that right now, sorry
<pitti> no other reviewer/sponsor around?
<Kmos> pitti: i understand..
<Kmos> pitti: that's more hard to find
<Kmos> :)
<cjwatson> would anyone object to usplash's initramfs script clearing the screen before starting usplash? you can end up with weird cruft left behind otherwise
<crimsun> Kmos: I can look, but I'd rather wait til post-Tribe1 since it'd be queued regardless.
<pitti> cjwatson: would that also kill scrollback if usplash dies? messages are quite useful for those cases
<cjwatson> it would kill anything from before usplash started
<sladen> I'm sure the original spec had that usplash should ensure that it didn't destory any messages
<Kmos> crimsun: yes, i understand
<shawarma> Dear Father Christmas. Please send a faster CPU. kthxbye
<cjwatson> right now, when the final login prompt appears on one of my systems, "Kernel alive" is still there at the bottom of the screen
<Kmos> crimsun: but you can approve it, and it goes to merges.ubuntu.com, and after tribe1 you can just approve it, right ?
<pitti> cjwatson: right, here too
<cjwatson> I take sladen's point though. messy.
<crimsun> Kmos: if I'm going to go through it, I'd just upload it, but main is frozen for Tribe1.
<Kmos> crimsun: ok.. so you can check it and comment :) if it's all ok
<Kmos> i've also contacted debain maintainer to notice him about the new version and ubuntu one
<Kmos> *debian
<fabbione> pitti: #119057 for you as reference
<pitti> fabbione: splendid, thanks
<fabbione> pitti: it's probably the worst bug report i ever wrote... but enough for you to say it sucks :)
<pitti> fabbione: heh, but "itz b0rked, I'll fix it" is still much better than "itz b0rked, kthxbye" :)
<fabbione> BZZZZZZZZZT
<fabbione> why does mysql ask me for a "root password" at install time?
<StevenK> It's trying to hint that you shouldn't use it.
<shawarma>   * Bump the priority of the debconf prompt for the root password to high, to 
<pitti> <jedi wave>PostgreSQL!</jedi wave>
<shawarma>     ensure the question shows up in a default installation (closes: #418672).
<shawarma> fabbione: ^^ from 5.0.41-1 changelog.
<pitti> shawarma: bugger, that means we have to deviate again
<fabbione> and it asks for it only once
<fabbione> so that means if you type it wrong, you are doomed
<pitti> gosh, I was so happy when we could finally sync this beast again
<fabbione> anyway it's not a blocker for Tribe-1
<fabbione> shawarma: want to take care to fix it?
<shawarma> I just did a server install and it didn't ask me.. Is the installer threshold for questions perhaps critical?
<StevenK> pitti: <jedi wave>MySQL is not the database you are looking for.</jedi wave>
<shawarma> fabbione: Sure.
<fabbione> shawarma: did you install LAMP?
<shawarma> fabbione: Remember what it used to be? medium? 
<shawarma> fabbione: Yes.
<pitti> StevenK: right
<fabbione> shawarma: i did install clean LAMP.. no changes in the debconf priority
<shawarma> fabbione: Um... So did I.
<shawarma> fabbione: Well, lvm+lamp.
<fabbione> shawarma: gutsy.. you need to use gutsy install cd's.. not feisty :P
<shawarma> fabbione: But that *really* shouldn't matter. :)
<fabbione> yeah so did i
<ogra> pitti, testpage updated
<shawarma> Um... That's pretty odd. :)
<fabbione> BZZT
<fabbione> something did try to mount usbfs and failed.. on a server install... hmm
<cjwatson> shawarma: no, installer threshold is high
<fabbione> oh just details
<shawarma> cjwatson: Mkay...
<fabbione> the install looks good
<shawarma> Gah... VirtualBox won't boot the server kernel.
<cjwatson> unless you're using warty ;-)
<shawarma> cjwatson: :)
<Mithrandir> mjg59: any chance you could look at https://wiki.ubuntu.com/power-management-in-Ubuntu when you have the time?
<shawarma> fabbione: I can't imagine why it didn't ask me for that password. Any bright ideas?
<Kmos> tribe1 would have php 5.2.3 ?
<fabbione> shawarma: try to reinstall? did you return without noticing?
<shawarma> fabbione: I haven't tried reinstalling yet, and I suppose it's possible that I didn't notice.. I'd say it's unlikely, though. 
<Mithrandir> Kmos: no
<Kmos> which version ?
<Mithrandir>       php5 | 5.2.2-1ubuntu1 |         gutsy | source, all
<Kmos> :-)
<Kmos> thx
<pitti> fabbione: TBH I'd leave the prompt until we have a really good solution for this
<pitti> fabbione: right now, every user can log in as mysql root without a password, including exploits in webapps
<pitti> fabbione: I would prefer a pam user id matching and disabling the password entirely by default, but that doesn't seem to be possible with Mysql?
<StevenK> That's right, MySQL doesn't touch PAM.
<pitti> bugger
<asac> pitti: thunderbird_2.0.0.4~rc1-0ubuntu1 is uploaded now
<pitti> do you need the old password if you set a new one as root?
<StevenK> Just thinking about it, I can't come up with a solution that is elegant.
<pitti> setting it to an invalid value and documenting that you have to run 'sudo mysqladmin password blabla' first would be better
* StevenK ssh's to a machine with MySQL installed.
<shawarma> pitti: Yes, you need the current password to change it.
<pitti> shawarma: but, but, if you are root, there should be a way, right? :-)
<Kmos> pitti: i think with root you can reset it
<pitti> shawarma: what would be architecturally wrong with not requiring the old password if you change the passwd on the local server as root?
<shawarma> pitti: The workaround (e.g. if you forgot your password), you need to restart myql with some option to make it ignore the current password.
<pitti> shawarma: can you please file this as a bug so that we have a permanent record of the discussion? I'll milestone it appropriately
<shawarma> pitti: Will do.
<Kmos> http://www.tech-faq.com/reset-mysql-password.shtml
<StevenK> Ewww
<shawarma> --skip-grant-tables ftw!
<pitti> ouch++
<pitti> . o O { 'if (!geteuid() && host == 'localhost') auth=True; else auth=ask_password(); }
<pitti> there's nothing you can hide from root anyway
<StevenK> Except if the password is crypted...
<pitti> shawarma: maybe that should even be forwarded upstream
<pitti> StevenK: right, I don't mean showing the password in cleartext, but circumventing it
<pitti> shawarma: they might like a better solution to that hack as well
<StevenK> pitti: Oh, right.
<pitti> StevenK: it would only matter if the mysql tables were encrypted with the root password, which is not the case
<StevenK> pitti: It looks geser and myself have finished hacking requestsync. Shall I just throw it into devscripts and upload it?
<pitti> StevenK: sure, if you are happy with it, go ahead; won't make it to the archive before thawing gutsy, of course
<StevenK> pitti: I was pondering a bzr branch for devscripts.
<pitti> ogra: how happy are you with the current edubuntu CDs?
<ogra> i'm fie
<ogra> *fine
<pitti> ogra: amd64 CDs didn't get a single test so far; they should at least be checked for bootability
<ogra> ok, i can do that 
<ogra> i'll notify you 
<pitti> ogra: do you care about the server addon CD?
<ogra> not yet
<pitti> ogra: I just updated the image greenishness on the iso tracker, most is good now
<ogra> its fine to hear some respnse
<ogra> but it will change a lot before i want testing
<pitti> ogra: ok, they are not essential for installation, right?
<ogra> right
<pitti> ogra: ok, so let's not waste time on it now, shall we?
<ogra> they have only a package archive and app-install data
<ogra> right
<pitti> ogra: ok, so you'll care about edubuntu server/desktop amd64 quick test, I'll sort out the mirroring and pre-release preps, and then we pop the trunk?
<ogra> yup
<fabbione> pitti: i don't know mySQL auth code at all, but that's why we have a server team to ask to fix :)
<ogra> xubuntu and kubutu are good already ?
<pitti> fabbione: indeed, that's what my gentle comments suggested :)
<pitti> ogra: yep
<fabbione> pitti: ehehhe
<ogra> cool
<shawarma> pitti: #119075
* shawarma -> lunch
<pitti> shawarma: great, thanks
<pitti> fabbione: does the sparc CD work on at least some machines?
<fabbione> pitti: it might.. 
<fabbione> pitti: the problem is that the pci resource that is not init can be totally random
<fabbione> pitti: in my case was the bridge before the CD
<fabbione> pitti: for others might be something else
<fabbione> pitti: like.. dunno.. I/O controllers? network?
<StevenK> Random per boot, or per machine?
<fabbione> per machine/per OBP version
<fabbione> constant is that affects only PCI
<pitti> fabbione: ok; so let's publish it, maybe someone is lucky; thanks
<fabbione> pitti: really.. we agreed not to.. and it's probably best that way
<fabbione> and we don't want to be flooded for tha
<fabbione> that
<fabbione> it will take longer to close all the bugs than to just skip it
<pitti> fabbione: alright; I revert that image then
<StevenK> Hah.
<StevenK> pitti: I've got requestsync looking up the component in Debian, as well.
<StevenK> "Please sync flashplugin-nonfree (multiverse) from Debian unstable (contrib)."
<pitti> StevenK: cool
<talmid> hello
<talmid> anyone can help me with my apt-pinning problem? Unless I can ask in here? #ubuntu is too noisy and my problem has been buried.
<persia> talmid: This really isn't a support channel.  If #ubuntu is too busy, consider trying again at a less busy time, or opening a support request from https://answers.launchpad.net/ubuntu/.
<talmid> persia: I am not asking for support in here. I am asking if someone could contact me to help me. It must be doing something basic wrong and a second pair of eyes would fix the problem
<talmid> persia: well unless I get permission from the channel to ask for support in here
<gnomefreak> !pinning > talmid  ( please read the docs ubotu sent you and please ask in #ubuntu if you have further questions)
<pitti> ogra: so do you want the addon CD published at all? it looks as if we should just skip it for now
<talmid> gnomefreak: mind if I highlight you in #ubuntu. I have asked a few times and got no response?
<ogra> pitti, well, since its identcal to the feisty one i wouldnt mind publishing it either ... doesnt matter, do as you like
<pitti> ogra: ok, everything prepared for release, except copying the edubuntu CDs
<StevenK> pitti: Would you mind holding off for 2 hours and 10 minutes? Then I get Tribe 1 for my birthday. :-P
<shawarma> re
<Mithrandir> I think he should hold it off until tomorrow, or at least 00:01 :-P
* StevenK high fives Mithrandir.
<StevenK> 00:01 in which timezone? :-)
<Mithrandir> CEST
* Mithrandir bounces around StevenK 
<StevenK> Heh
* StevenK activates a personal forcefield, lest he get bounced into.
<StevenK>  1 file changed, 69 insertions(+), 38 deletions(-)
<StevenK> Poor requestsync.
<StevenK> pitti: It occurs to me that we should probably put a licence on requestsync.
<pitti> StevenK: might happen if you are lucky, and testing/website preps still take that long
<pitti> StevenK: heh, GPL or public domain, I figure
<StevenK> pitti: I'm happy with GPL if you are.
<pitti> sure
<pitti> ogra: I already prepare the publishing of the edubuntu CDs, btw, since it's likely that they work and it's easy to roll back (I didn't sync mirrors yet)
<StevenK> pitti: Can I PM you what I just added?
<pitti> StevenK: the entire diff? pastebin might be better than IRC flood
<StevenK> pitti: No, the 3 lines for licence stuff
<shawarma> pitti: Setting a bogus password on mysql-server is a bad idea, I think. The server's useless as long as it's set that way, so instead of being asked in a nice debconfy way for a password, the user will need to dig out the command line to change the password from some readme file or something.
<pitti> StevenK: oh, sure
<pitti> shawarma: *shrug* personally I think debconf is fine, but we have a certain policy for that; not sure whether we should be as strict for that server install, though
<shawarma> {rules,policies,laws} are meant to be broken :)
<StevenK> You could always randomly generate it, and store it in debconf.
<StevenK> Document how to get at it with debconf-communicate.
<StevenK> That neatly causes debconf-is-not-a-registry, though
<shawarma> Sounds nasty, if you ask me.
<pitti> shawarma: still, if someone doesn't see the debconf question, then it's better to RTFM how to set the password than to leave it wide open IMHO
<pitti> shawarma: and as soon as mysql doesn't ask your password any more when being run as root, it doesn't matter so much, right?
<pitti> shawarma: webapps shouldn't connect as admin user anyway
<shawarma> pitti: I suppose.
<StevenK> They shouldn't connect as root at all, IMO
<StevenK> I *much* prefer how PostgreSQL handles this.
<pitti> right, except for setting password and administering users, AFAICS
<pitti> StevenK: so do I :)
* StevenK grins and high fives pitti
<persia> pitti: While I agree with you, it does break separation of server administrator and database administrator, which may be a violation of some compliance policies.
<pitti> persia: how so?
<StevenK> persia: In large organisations, they are completly seperate.
<pitti> persia: if you are the server admin (root), then you can control the server daemons, no matter what passwords they user
<pitti> s/r$//
<persia> If mysql allows anyone with root access to access mysql without checking the password, the server administrator would not be prevented from adjusting the database.
<pitti> persia: you cannot prevent him from doing that anyway
<StevenK> persia: It does, it just needs to be started with '--skip-grant-tables'
<StevenK> persia: I know a guy who has an ssh key to the DB machines and sudo rights to postgres. Only.
<persia> pitti: I suppose.  root is fairly powerful.  Oh well, at that point it's just policy and auditing.
<pitti> persia: sure
<pitti> persia: and it's also pretty independent of the 'no password by default' problem
<persia> pitti: That's why I started with "I agree with you" :)  I'm only commenting on possible downsides of the proposed solution, but any solution is better than the current situation.
<shawarma> pitti: I'm not sure it's even possible to make it so that root doesn't have to authenticate. It's the client that would have to detect it, but the server that would have to enforce it..
<shawarma> I'll file an upstream bug..
<pitti> shawarma: true that
<pitti> shawarma: the server would need to check the credentials of the client; postgresql does that
<StevenK> 'ident trust' FTW
<shawarma> pitti: how?
<shawarma> Oh.
<pitti> shawarma: and this also ensures that it's a local connect, since you cannot do that with IP
<shawarma> So if it's a local connect, it checks if the connecting process is run by the same uid as the serveR?
<pitti> shawarma: with unix sockets there is a function to get the peer uid
* pitti looks
<pitti>         if (getsockopt(sock, SOL_SOCKET, SO_PEERCRED, &peercred, &so_len) != 0 ||
<pitti>                 so_len != sizeof(peercred))
<pitti>         {
<pitti>                 /* We didn't get a valid credentials struct. */
<shawarma> pitti: Oh, really? 
<pitti>         uid = getpwuid(peercred.uid);
<pitti> "struct ucred peercred", BTW
<pitti> shawarma: yep, that's pretty handy, used in e. g. dbus as well
<shawarma> pitti: *very* handy.
<pitti> shawarma: that's how postgresql does the PAM user/db user matching
<shawarma> Hm... I wonder where my trusty IPC book has gone.
<shawarma> pitti: Makes sense.
<pitti> shawarma: man unix(7) is pretty good
* pitti wonders where SO_PEERCRED is documented
<StevenK> pitti: In unix(7)
<StevenK> Under SOCKET OPTIONS
<shawarma> It says PASSCRED
<pitti> StevenK: right, PASSCRED, but not PEERCRED
<torkel> socket(7) ?
<StevenK> Oh right, sorry. I should learn to read at some point.
<StevenK> Yup, socket(7)
<Kmos> at my Acer 5633WLMi (https://wiki.ubuntu.com/LaptopTestingTeam/AcerAspire5633WLMi) the latest kernel for feisty, start with PCI: Failed to allocate memory
<Kmos> it works fine, but has that message
<Hobbsee> heya all
<Hobbsee> mmm...we have power!  :)
<coastGNU> Is there a way to get a preseed file as result of an oem-install? 
<coastGNU> cjwatson: Colin, ping
<Kmos> how to test Cpu frequency scaling on my laptop ?
<pygi> fabbione, you've got mail
<Hobbsee> Kmos: sounds like a #ubuntu type of questoin
<Kmos> Hobbsee: ok
<pitti> BenC: when I run /usr/share/apport/testsuite/test-apport kernel on 6.13, it immediately dies with 'does not leave core file behind'
<BenC> pitti: what does that message mean, that no core was read from stdin?
<pitti> BenC: the assert message is the wrong way around, it should be 'does leave core file'
<pitti> BenC: I get a 0-byte 'core' file in the dir I run this in
<pitti> BenC: not sure why; let me disable that test
<pitti> BenC: indeed, most stuff seems to work when I disable this (it breaks at a later stage with 'cannot access memory', but I need to investigate that)
<pitti> BenC: so it seems to open the core file already before diverting it to stdout?
<pitti> ogra: any update?
<cjwatson> coastGNU: same instructions apply as to the regular alternate install; see the installation guide
<pygi> Zdra, poke, did that thing work for you? :)
<Zdra> pygi: what thing ?
<pygi> Zdra, the conversion script?
<coastGNU> cjwatson: Hhhm, not exactly what Im looking for. What I would like to have is a preseed file to remaster the cd so that a user will only asked what is asked in the first boot after oem-config-prepare
<Zdra> didn't looked yet, I had an exam this morning and I'm studying the next one atm :)
<coastGNU> cjwatson: So my first idea was , It would be good to have somekind of logfile which may be used to set up a preseed file
<pygi> Zdra, ah, oki. 6 exams next week here :(
<pygi> how did it go?
<Zdra> was easy :)
<cjwatson> coastGNU: the way oem-config is intended to be used is that you install it once and clone the resulting disk image
<cjwatson> not the CD
<pygi> hehe, good for you Zdra :p
<pygi> I don't think 6 exams for me will be easy :p
<Zdra> pygi: good luck ;)
<pygi> thanks, I'll need it ;)
<coastGNU> cjwatson: I know about that. But what if there is need for a 'restore installation cd'? And thats what I like to have, and I bet a lot of oems also. :-)
<cjwatson> coastGNU: I'm afraid that's very much a roll-your-own at the moment :-(
<cjwatson> coastGNU: debconf-get-selections --installer after installation may provide a starting point though
<coastGNU> cjwatson: Ahh, used dpkg --get-selections so far, didn't know about debconf-get-selections so far. I will have a closer look. Thanks a lot so far. cu
<coastGNU> cjwatson: Arrgl, never wrote a sofar'ish sentence so far. Time to have a coffee...
<pitti> fabbione: tribe-1 images are up, so certification testing can begin; do you need a more formal notification?
<gnomefreak> is OO.o merged/synced from debian or is it something we build on our own?
<StevenK> Merged, if I recall correctly.
<gnomefreak> StevenK: we must drop thier changes than. they have a plugin built with OO.o that we seem not to have as i am hearing
<pitti> heno: do we actually want people to report tests on isotest after the tribe-1 release? or should we maybe just completely skip that paragraph and keep it for a later tribe or beta?
<StevenK> gnomefreak: File a bug/talk to doko.
<fabbione> pitti: no, just send out the announcement. That's the official trigger to start the timer
<heno> pitti: you can skip it and we'll make a more explicit process for tribe-2
<gnomefreak> im filing the bug for someone he will fill in the info after ;)
<pitti> heno: makes sense, thanks
<heno> I'll set up the tribe images there anyway, but will just encourage people who are already familiar with it to use it
<heno> It's good for developing the tracker itself if nothing else
<fabbione> pygi: got the mail.. will do tomorrow
<pygi> fabbione, oki
<pitti> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-June/000301.html
<pitti> *drums*
<ogra> \o/
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe-1 released
<StevenK> Oh yes! Tribe 1 for my birthday. \o/
<mc44> pitti: nice quote :) Next time you can use the lyrics from The Funky Gibbon :)
<pitti> StevenK: happy birthday!
<StevenK> pitti: Thanks!
<fabbione> pitti: congratulation on your first release
<fabbione> pitti: well done
<pitti> fabbione: thank you
<pitti> thanks to all of you who were involved
<pochu> Yay for the release! :)
<Hobbsee> pitti: have you recovered yet?  :P
<pitti> Hobbsee: sure, let's release tribe-2; should be fairly smooth ATM :)
<pochu> Oh, and StevenK and Mithrandir, happy birthay :)
<pitti> pochu: not yet for Tollef :)
<pochu> pitti: depends in what part of the world :p
<Hobbsee> when's Mithrandir's birthday?
<pochu> I guess tomorrow
<pitti> tomorrow, in 8-some hours
* persia thinks it starts in about 7 1/2 hours
<pochu> But today in Japan ;)
<StevenK> pochu: Thanks!
<Hobbsee> so today then
<pochu> Oh, Tribe 5 is on my Birthay :-)
<StevenK> Heh
<StevenK> I started a trend, it appears.
<Lure> cjwatson: added debug file to bug 118967 - hope it helps
<ubotu> Launchpad bug 118967 in ubiquity "ubiquity crashed with IndexError in child()" [High,Confirmed]  https://launchpad.net/bugs/118967
<pitti> mc44: thanks for that pointer
<pitti> hm, what's that old crap on -changes@
<elmo> I moderated them through
<elmo> they were incorrectly moderated before the X-Katie hack got applied
<elmo> seemed better to have them recorded for posterity/google, even if it is confusing having them turn up so late
<pochu> pitti: I've found a reproducible crash in xqf, but it's giving a backtrace and the memory map to stdout. Is there a reason why apport isn't taking it?
<pitti> pochu: apport frontend is still disabled by default in update-notifier
<ssam> are there tribe 1 for powerpc isos, i can't find them on the cdimage server
<Hobbsee> ssam: under /ports, probably?
<ssam> Hobbsee, thanks, but i have already tried there ports/releases/ only has up to feisty
* Hobbsee wonders if pitti actually built the ppc, etc
<cjwatson> may just not have released it
<cjwatson> it's certainly built and in ports/daily{,-live}/
<cjwatson> if you're desperate, you can grab it from there
<ssam> cjwatson, thanks
<statik> is it valid to try doing an upgrade to tribe1, or do I need to do a clean install?
* Hobbsee --> bed
<simira> good night, Hobbsee 
<simira> (seems like everyone left before you :p )
<Hobbsee> so it seems
* Hobbsee could just stay up and talk to you :P
<robertj> gnome-system-tools-2.18.1/src/shares/Makefile has CFLAGS = -g -Wall -O2, does that mean it should be compiled with debugging symbols? and if so, why does gdb complain that it doesn't have them when running the resulting executable
<geser> it's build with debugging symbols but they are split out during package build
<robertj> geser: i'm running it in-place in the shares directory
<DexterF> hi
<DexterF> I noticed for some reason subfs/submountd is not in 7.04. compiling it myself failed. where canI file a request?
<LaserJock> I need a core-dev to sponsor a merge of lintian, any volunteers?
<crimsun> LaserJock: url to debdiff?
<LaserJock> crimsun: http://tiber.tauware.de/~laserjock/lintian_1.23.31ubuntu1.debdiff
<LaserJock> crimsun: that's a debdiff from the Debian sid source. I've added in a piece that will get rid of NMU warnings for Ubuntu packages
<crimsun> LaserJock: but not *-security?
<LaserJock> crimsun: so I'd appreciate a check of my perl on that
<LaserJock> crimsun: hmm? Debian -security or Ubuntu -security?
<crimsun> the latter
<LaserJock> it just checks for "ubuntu" in the version and turns of NMU if that's the case
<LaserJock> it's simple
<LaserJock> I'm mostly just trying to get it so MOTU contributors don't always freak out over the NMU warnings
<crimsun> right, that part seems fine
<crimsun> I'm just wondering what the rationale for skipping Ubuntu's *-security (since *-{proposed,updates,backports} are covered)
<crimsun> is
<LaserJock> oh
<LaserJock> security is already in there
<LaserJock> from Debian
<crimsun> ok blarg, silly Web browser
<crimsun> no wonder, debdiff didn't finish loading due to local proxy
<crimsun> LaserJock: What do you plan to do with -build suffixes?
<LaserJock> nothing
<LaserJock> I wanted to keep low divergence and the idea was to minimize NMU warnings for us
<LaserJock> we don't do a lot of -build uploads
<crimsun> done.
<LaserJock> we can always tweak it later
<LaserJock> I just figured it was fairly straightforward to get rid of the bulk of those
<LaserJock> that's pretty much one of the first things people ask in #ubuntu-motu when they're learning to patch/debdiff
<LaserJock> is gfxboot installed by default in gutsy?
<cjwatson> LaserJock: gfxboot has never been installed by default, only used on the CDs
<LaserJock> cjwatson: interesting, thanks
<pochu> pitti: re: apport: but there's no crash in /var/crash, and it should be even if the frontend is disabled, right?
<pitti> pochu: right
<pochu> Might it be xqf? It's printing the traceback and the memory map into the terminal.
<pitti> pochu: the gutsy kernel still has problems with apport, that can be it, too
<pochu> Ok
<pitti> pochu: ah, right, it probably has its own crash handler then
<pitti> pochu: check /var/log/apport.log
<pitti> if it was called at all
<pochu> It wasn't, though some other apps were.
<pochu> I'll file a bug upstream then, with the terminal output.
<pochu> Thanks for the help :)
<nn-ds> hi
<nn-gentoo> hi
<joeamined> hi
<joeamined> was the linux kernel bug "pci failed to allocate mem resource"
<joeamined> that happends in linux-source-20 in many laptops
<joeamined> been fixed in linux-source-22 in gutsy ?
#ubuntu-devel 2007-06-08
<bdmurray> Is the How to request new packages part of the UbuntuBackports page current?
<Spastic__teapot> After switching to Ubuntu, I've noticed that my transfer rate on downloading files has increased by about 250%. 
<Spastic__teapot> I used to get 50-60kbps, now I'm getting maybe 250 on average.
<Spastic__teapot> How on earth did you pull THAT off?
<crimsun> magic.
<bdmurray> black magic
<Spastic__teapot> I assumed as much.
<Spastic__teapot> For a while I was pulling 500 kilobytes/second on a download. This is on a 3mbps maximum internet connection. Shared between two people. Over a wireless router.
<Spastic__teapot> Not that I'm complaining.
<crimsun> bdmurray: as opposed to BackportRequestProcess ?
<bdmurray> crimsun: I was looking at https://help.ubuntu.com/community/UbuntuBackports
<bdmurray> either way both seem sparse
<crimsun> bdmurray: presuming the source package exists in gutsy, I'd file a bug against it and sub u-b
<bdmurray> somebody wanted a hal fdi update for feisty bug I imagine it also applies for gutsy
* RAOF thought backports weren't for fixing bugs.
<crimsun> right, it's not
<crimsun> that likely should be a -proposed->-updates
<cjwatson> if it meets the SRU criteria
<cjwatson> sometimes the answer is just "gutsy"
<cjwatson> (like the console breakage in feisty. it does bite people, but there's a choice of two fairly simple workarounds, and the real fix is rather invasive and a little risky)
<calc> cjwatson: good evening :)
<cjwatson> hello
<cjwatson> about to go to bed though ;-)
<cjwatson> you were asking about something installer-related the other night?
<calc> oh if there is a way to install a different version of ubuntu with a cd
<cjwatson> calc: oh, you could try mirror/suite=feisty or whatever but it's very much not supported and unlikely to work
<cjwatson> it's possible you might be lucky
<cjwatson> hmm, I think cdrom/suite actually
<cjwatson> calc: it would be simpler to download the netboot mini.iso for the relevant release
<calc> oh ok
<calc> thats what i ended up doing
<cjwatson> http://archive.ubuntu.com/ubuntu/dists/DIST/main/installer-ARCH/current/images/netboot/mini.iso
<calc> mini.iso is only about 9mb so it was quick enough to download
<cjwatson> yeah, that's the simplest option
<calc> i had to go back to feisty because it appears intel wireless is broken on gutsy
<RAOF> People keep saying that, but I don't see it.
<calc> i saw a report of 2200 not working and 3945 didn't work for me
<calc> it saw the network but never connected
<cjwatson> calc: do make sure a bug's filed ...
<calc> so i don't know where the issue is actually
<RAOF> *My* 3945 works just fine.
<cjwatson> might be worth trying the new iwlwifi driver if you aren't already
<calc> i'll give that a try when i go back to gutsy (soonish)
<calc> i'm in the middle of a compile to see if the ALC268 patch works for sound on my laptop
<calc> got the laptop this past monday
<calc> i was so happy suspend to ram worked :)
<RAOF> What's this new iwlwifi driver?  Another intel wireless driver?  Why?
<calc> my old laptop could never wake back up
<cjwatson> RAOF: it comes from Intel
<cjwatson> gets rid of the binary daemon thin
<cjwatson> g
<calc> RAOF: the one based on the new 80211 layer (iirc)
<RAOF> Oooh.  Cool.
<cjwatson> RAOF: http://intellinuxwireless.org/?p=iwlwifi
<RAOF> Man, I'm glad I got an intel wireless chip.
<calc> grr trying to apply the patch i managed to do something wrong and it died compiling after 39m, heh
<calc> oh well, time for dinner, bbl
<wasabi> Is there a procedure for marking a bug in some fashion so that some more "important" people will look at it and perhaps offer suggestions on the fix?
<wasabi> Hmm. More specifically I want commentary on the suggested fix. And I really just want to hit a button and forget about it. ;)
<fabbione> morning
<LaserJock> morning fabbione 
<Hobbsee> hi all
<Hobbsee> mmm....updates
<fabbione> ./scsi/scsi-read-disc-info.h:147: error: stray \302 in program
<fabbione> wth does that mean?
<Hobbsee> symbol that's not supposed to be there, maybe?
<pygi> fabbione, thanks
<fabbione> pygi: i think that most of the errors you are getting is because you want to play smart with LITTLE/BIG ENDIAN
<pygi> fabbione, i'm not playing smart. Not my software =)
<fabbione> ppc and sparc are both endian... also remember that sparc must be 64 bit aligned
<fabbione> make that big endian
<pygi> got 
<pygi> got it*
<pygi> fabbione, will need to see what can I do about that (if anything)
<pitti> Good morning
<pygi> morning pitti, how are you? :)
<pitti> pygi: *yawn* good morning
<pygi> pitti, hehe :)
<Hobbsee> morning pitti!
<pitti> hi Hobbsee 
* Hobbsee hugs pitti 
<Hobbsee> hrm.  why are my openoffice fonts stuffed?
<Hobbsee> they show as boxes..
<StevenK> All of them?
<Hobbsee> ste
<Hobbsee> StevenK: http://wedontsleep.org/~sarah/snapshot8.png
<StevenK> Neat!
<Hobbsee> yes!
<StevenK> Beat doko about his person with that photo when he surfaces?
<Hobbsee> morning simira 
<Hobbsee> heh
<StevenK> s/photo/screenshot/
<Hobbsee> doko: do you know why i'd be getting http://wedontsleep.org/~sarah/snapshot8.png on any openoffice variant, under kde, in gutsy?
<Hobbsee> it's using OpenSymbol fonts, both in kde and gtk apps
<Treenaks> looks nice ;)
<doko> Hobbsee: looks like a font problem; KDE? did you install additional fonts?
<doko> is this the symbol font?
<Hobbsee> doko: not that i remember doing.  when changing it back to sans in the gtk section of kcontrol, it still comes up with that - seemingly for any font i use
<Hobbsee> no - it's a normal font
<Hobbsee> RAOF: your connection *sucks*.  you're really not inspiring me to go into uni
<ccm> Is there a form for "needs packaging" requests? 
<Hobbsee> !motu
<ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<Hobbsee> ccm: see ^
<RAOF> Hobbsee: Nah, that's actually me upgrading network-manager
<Hobbsee> i belive it's linked to there
<Hobbsee> RAOF: ahhh...
<ccm> Hobbsee: thank you
<Hobbsee> uh oh, pitti's back.  everyone behave!
* Treenaks cries, because upgrading to gutsy made sound not work :'(
* desrt misbehaves
<pitti> hey desrt 
<pitti> Hobbsee: just rebooting :)
* Hobbsee axe murders desrt.  gotta live up to my image!
<crimsun> argh, who pinged about sound?
<Hobbsee> crimsun: Treenaks.
<crimsun> I see.
<Treenaks> crimsun: me! :)
<desrt> Hobbsee; you fixate rather readily on an off-the-cuff remark that i'd have made about anybody given the context :p
<Hobbsee> desrt: *grin*
<crimsun> Treenaks: http://www.linux-sound.info/alsa/scripts/alsa-info.sh
<Treenaks> crimsun: bug #119266
<ubotu> Launchpad bug 119266 in Ubuntu "Intel HDA Sound device doesn't work in gutsy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119266
<Hobbsee> desrt: you never know, i might be an axe murderer anyway...
<desrt> Hobbsee; well!  you certainly look like one!
<desrt> ""
* Hobbsee does have the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!!! 
<Hobbsee> haha
<crimsun> well, let's see, LP seems to have gone on vacation.
<Hobbsee> it's the impending public holiday
<Hobbsee> sends all technology to hell.
<doko> Hobbsee: hmm, try to uninstall ttf-opensymbol?
<dholbach> good morning
<desrt> dholbach; hello.
<dholbach> hiya desrt
* Hobbsee hugs dholbach in greeting :)
<StevenK> crimsun: Seems to be working for me.
<Treenaks> crimsun: http://pastebin.ca/549772
<desrt> my eyes want to fall out
* dholbach hugs Hobbsee ... a lot
<Hobbsee> doko: wants to remove all of ooo
<Hobbsee> doko: (was that the plan?)
<doko> no
<doko> strange ...
<desrt> GString is a really poorly named class in terms of google searchability....
<Hobbsee> haha
<dholbach> haha
<Mithrandir> "I remember this diagram showing gstring and some other bits of G*, let's use the image search"...
<Hobbsee> morning Mithrandir 
<desrt> dirty dirty mithrandir 
<Mithrandir> morning little Hobbsee
<crimsun> Treenaks: easy, already fixed.  Missing SSID quirk entry.  Will push to upstream now.
<Hobbsee> desrt: you have seen the third result for "jono bacon" havent you?
<Treenaks> crimsun: yay! :)
<crimsun> Treenaks: you need model=ref
* Hobbsee towers over Mithrandir 
* desrt fears
<Mithrandir> Hobbsee: I got another penguin!
<crimsun> gotta love Dells.
<Mithrandir> Hobbsee: http://err.no/tmp/pingvin/
<Treenaks> crimsun: hmmm. dell. :)
<crimsun> or maybe hate Dells due to the utterly necessary quirks, but whatever.
<desrt> Hobbsee; cute kid.  he looks about 12 :p
<Hobbsee> Mithrandir: woo!!!  is this one going in the office, or at home?
* Hobbsee used to have a penguin like that, incidently
<Treenaks> crimsun: that worked
<Treenaks> crimsun: (at least.. the mixer bits did, testing audio now)
<Mithrandir> Hobbsee: it already seems to be very happy standing behind the scanner
<Hobbsee> Mithrandir: hehe, fair enough
<Hobbsee> desrt: maybe it's changed then :P
<RAOF> Surely it should go on the TV?
<Hobbsee> desrt: they were discussing it during the planet editorial spec
<desrt> weird
<desrt> searching "ryan lortie" on google image search gets you pictures of jeff waugh and seb128
<Hobbsee> haha
<Hobbsee> oh bugger it.  my blog now comes up
<StevenK> Comes up where?
<Hobbsee> 9 links in the first 2 pages on google search results for "sarah hobbs"
<Hobbsee> it used to be 0, for yeras
<Hobbsee> *years
<pitti> fabbione: hm, http://git.ubuntu.com/ doesn't exist; what was the actual host name again?
<Hobbsee> 13 in the first 3
<desrt> oh the vanity.
<StevenK> Heh
<desrt> you google yourself frequently enough to track the changes with respect to time :p
<Hobbsee> nothing in images searches
<pitti> fabbione: ah, got it
<Hobbsee> desrt: sure - i'm used ot keeping a very low profile, and keeping hobbsee and sarah hobbs completely separate, for obvious reasons.
<desrt> Hobbsee; you know that logs from this irc channel are published to the web, right? :p
<Hobbsee> desrt: true that.  but i only started using my real name online ~6 months ago...
<Hobbsee> ditto pictures and such
<desrt> ah
* desrt was like that for a while
<Hobbsee> mainly because at that point i knew i had a large probability of being sponsored to UDS, and knew that people would find out who she was that way.
<Hobbsee> s/she/i/
<desrt> a few projects had AUTHORS files with a big lists of fullnames and "desrt" randomly in the middle :p
<Hobbsee> hehe
* Hobbsee still went by hobbsee for the conference.  *shrugs*
<Hobbsee> for introducing, anyway.  answered to both.
* desrt not looking forward to writing a parser in C....
* RAOF wonders why desrt is even doing so.  Surely enough parsers-in-C have already been written.
<Treenaks> desrt: libperl is your friend ;)
<Treenaks> RAOF: there's even a parser-generator ;)
<StevenK> There's a few.
<RAOF> :)
<StevenK> Yapp and Rec-Descent
<desrt> Treenaks; :p
<crimsun> Treenaks: not to push, but it's nearly 3 A.M. here, and I'm waiting to send this hg changeset.
<Treenaks> crimsun: it works
<crimsun> thanks.
<fabbione> pitti: ehehe ok :)
<linnuxxy> how can i find the package which is display the first page of the LiveCD... the page of choosing from Start or Install Ubuntu.. Start Ubuntu in Safe mode ...etc?
<StevenK> gfxboot
<desrt_> looks like somebody at freenode tripped over a cable....
<Hobbsee> or you did ;P
<Treenaks> he did :)
<desrt> if you think my IRC is limited to one network, yr crazy.  all the other ones were fine :p
<pygi> hey dholbach_ 
<dholbach_> re
<desrt> looks like lots of people tripped over cables :p
<Hobbsee> it's just the internet breaking again
<Treenaks> Hobbsee: must be your internets then :)
<Hobbsee> Treenaks: i didnt drop
<Treenaks> yet
<Hobbsee> Treenaks: but i'm tempted to stick an extra client in for this weekend, which is based in the US
<Hobbsee> as we're getting major storms and such
* Seveas drops Hobbsee on the internets
* Hobbsee breaks
<Treenaks> Seveas: You broke her!
<Hobbsee> Seveas: what's your appeal in attempting to break me?
<Seveas> I attempted to break the internets, not you
<Treenaks> Seveas: try throwing something a bit heavier then
* Seveas drops Treenaks on the internets
* Treenaks floats away gently#
<Seveas> sure Arthur :p
<Hobbsee> Seveas: you've attempted to break me before, though.
<Treenaks> Hobbsee: He wants that confession!
<Seveas> That was an attempt to throw you in the pool
<Seveas> Treenaks, not needed, I know more than enough blackmail material already :)
<Treenaks> Seveas: ah, the true BOFH
<Seveas> Treenaks, indeed
<Hobbsee> Seveas: a stupid one, yes.
<Seveas> Treenaks, I broke my record of causing problems yesterday. Previous one was half the building not being able to log in. Yesterday it was the entire building :)
<Treenaks> Seveas: So you can say goodbye to your new contract? :P
<Seveas> neh
<Hobbsee> hah.  bad Seveas 
<Seveas> Hobbsee, bad Seveas breaks things for 2 buildings and about 10 branch offices. Didn't gt that far yet
<Treenaks> Seveas: that's next week
<Hobbsee> haha
<Seveas> Treenaks, could be
* desrt grumbles
<Hobbsee> poor desrt 
<desrt> :(
<desrt> poor me
<asac> hmmm there is a cvs import of gnash trunk in LP ... is it possible at all to update that without --overriding everything?
<cjwatson> asac: it should auto-update if it's in ~vcs-imports - is it not doing so?
<asac> cjwatson: last revision: "#
<asac> By strk on 2006-10-14 
<asac>  ... so no.
<asac> cjwatson: actually now gnash has finally branched development in cvs for 0.8 ... which I would need ... is there a form in lp to request synch for that?
<pygi> asac, file a bug
<cjwatson> whoa
<asac> to get a synch for branch 0.8? or for the "does not update branch" bug ?
<asac> pygi: ?
<cjwatson> asac: if you're the product registrant, you can edit it directly
<cjwatson> asac: otherwise, talk to ddaa
<pygi> asac, for sync
<cjwatson> usually a bug is not the correct answer IME
<cjwatson> they sometimes use the support tracker for that
<asac> pygi: yeah ... but first i would really like to be sure that cvs branches really auto-update; otherwise its not worth the effort imo
<cjwatson> they are supposed to automatically update, yes
<cjwatson> but perhaps e.g. the CVS details changed
<cjwatson> ah, hmm
<cjwatson> see https://launchpad.net/gnash/trunk
<cjwatson> "The Bazaar import has been suspended and is no longer updated. The source details for this series are locked and can only be modified by vcs-imports members and Launchpad administrators."
<cjwatson> talk to ddaa and find out what's going on
<asac> cjwatson: ok
* asac search for ddaa :)
<dholbach> mdz: mind to have a look at  http://wiki.ubuntu.com/MOTU/WikiCleanUp ?
<mdz> dholbach: ok
<mdz> dholbach: I would add explicitly that smaller documents should be merged into UbuntuDevelopment, while large documents should be linked
<mdz> if it's longer than, say, a few paragraphs, it should be considered for linking instead
<mdz> with a summary in UbuntuDevelopment
<dholbach> mdz: good idea - I'd like to use UbuntuDevelopment as a namespace to make easier them findable
<mdz> dholbach: if you find that the section layout in UbuntuDevelopment doesn't meet all your needs, we can expand/revise it
<dholbach> mdz: thanks for checking it out
<dholbach> persia: what do you think about http://wiki.ubuntu.com/MOTU/WikiCleanUp?
<persia> dholbach: If I were objective, I'd really like it, but currently it fills me with awe at your organisation and a renewed sense of time pressure to complete my review of all the documents in the wiki as sources to feed the UbuntuDevelopment documentation.
<dholbach> persia: I absolutely don't want to put any pressure on you.
<dholbach> persia: mdz suggested to write it up, so we can get more followers in tackling this problem
<carlos> pitti: hi
<persia> dholbach: Don't worry.  If I find more useful documents to apply after work is started, my delay just means more work for me later.  I'm driven by my laziness, not your effort.  Having a spec is a good thing, I completely agree with the goals, and like the idea of merging with UbuntuDevelopment.
<dholbach> excellent
<dholbach> persia: do you have a working list or some place where you made notes about your wiki review?
<pitti> hi carlos 
<dholbach> I mean... better working list than CategoryMOTU - if not, I'd copy it and we could have a MOTU/WikiCleanUp/WorkList or something
<persia> dholbach: At this point, it's still in my GNOME stickies and a firefox session, and I still have a couple thoulsand non-redirect pages to review.  I'll try to get something written up with lists of docs and ideas of what can merge and what can drop this weekend.
<carlos> pitti: When should I switch to export language pack updates instead of full exports for Gutsy?
<dholbach> persia: you rock - thanks SO much
* dholbach hugs persia
<persia> dholbach: I think CategoryMOTU is a good working list.  My wider search is more about linking to other namespaces (e.g. Bugs/) so that we don't duplicate things between teams.
<pitti> carlos: oh, good point. Why not do it right now
<dholbach> it'd be nice if we could announce our plans soon and get started on improving the wiki step by step
<dholbach> persia: right, that's perfect
<dholbach> persia: I'll start off MOTU/WikiCleanUp/WorkList then
<carlos> pitti: based on which language pack date? (I need to know the timestamp.txt content)
<persia> dholbach: There's still the identity question also.  Using the MOTU namespace maintains a separate (and perhaps interesting) MOTU identity, which isn't as strongly reflected with a more coherent and accessible documentation model under UbuntuDevelopment.  I'm not sure that's important from a documentation perspective, but I don't know if it may have morale effects.
<pitti> carlos: 20070603
<persia> dholbach: Great.  I'll catch up with you when I've finished looking at the list.
<dholbach> persia: we will keep the MOTU namespace, but more for team organisation
<carlos> pitti: ok
<persia> dholbach: Sounds good to me, but you might want to check with other interested parties as well.
<dholbach> persia: people will be able to find out what MOTU is, when the next meeting is, etc - but will be pointed to other process and other documentation elsewhere
<dholbach> absolutely, I want to announce the plan before
<sladen> cjwatson: is there a preferred spec for encrypted filesystems.  There seem to be able four in the specs system
<sladen> cjwatson: eg.  transparent-home-encryption, encrypted-filesystems, dm-crypt
<sladen> cjwatson: I'm now working for an employer were it's a requirement so I should get some time (and alsa at Debconf) to work on it, if there's a chosen direction that came out of hte Sevilla disccusions
<cjwatson> sladen: I think dm-crypt is the main one at the moment
<shawarma> Mithrandir: At some point, the "yay, you've succesfully installed apache2, etc."-page was removed in apache in favour of a file that just says "it works". Do you happen to know why?
<ajmitch> shawarma: it's a debian change, afaik
<ajmitch> though that hardly gives a reason
<shawarma> ajmitch: I know, but Mithrandir seems to be one of the Debian maintainers.
<fabbione> shawarma: probably somebody pointed out that it was not professional to say "yay"
<shawarma> fabbione: Now, someone is pointing out that it's not professional to say "it works". I shit you not. :)
<iwj> I imagine it'll be because that page was often seen by random people looking for some website, who would then end up bothering the software maintainers.
<shawarma> iwj: That's a good point.
<iwj> That certainly used to happen quite a lot.
<shawarma> bug 89364
<ubotu> Launchpad bug 89364 in apache2 "Apache2 default site contains only the words "It works!"" [Medium,Confirmed]  https://launchpad.net/bugs/89364
<fabbione> medium? :)
<shawarma> iwj: Sounds like a perfectly good reason to reject that bug.
<shawarma> fabbione: /me shrugs
<shawarma> iwj: Thanks!
<thom> shawarma: yeah, there's absolutely no content that someone doesn't like
<shawarma> thom: Yeah. I actually rejected another bug becuase it was resolved by only having "it works" there. :)
<geser> pitti: Hi, what's the status on the xvidcore SRU for feisty? There should now be packages uploaded to feisty-updates. (bug #84705)
<ubotu> Launchpad bug 84705 in xvidcore "[Feisty]  libxvidcore missing dependency for yasm for i386 arch : more than 3 times slower than in edgy" [Medium,Fix committed]  https://launchpad.net/bugs/84705
<Mithrandir> shawarma: we got tired of mails from users saying "You have hax0red my web server" or even better "You hax0red www.example.com, you evil bastards"
<pitti> geser: right, I'll go through SRUs today
<geser> thanks
<geser> the ubuntu-motu ML gets a weekly reminder about it already
<shawarma> Mithrandir: *g*
<Lutin> pitti: around ?
<pitti> hi Lutin 
<Lutin> hi
<Lutin> pitti: when you rejected my upload for cinepaint to proposed, you said I'd better upload the package which is in proposed first, I'd just like to know why :)
<pitti> Lutin: IIRC I didn't reject it for that reason, right?
<pitti> Lutin: otherwise we'd just stack new stuff in -proposed without ever releasing it, and testing of multiple changes is more difficult
<Lutin> pitti: that wasn't the only reason, yeah
<Lutin> pitti: without the 2nd fix, cinepaint will install but not even launch
<pitti> Lutin: oh, I see
<Lutin> would be kind of frustrating to upload it
<pitti> Lutin: well, then another -proposed one makes indeed sense; I wasn't aware of that, sorry
<Lutin> pitti: ok, fine, I'll do that? thanks
<Lutin> s/?/.
<fabbione> doko: did you notice #119110 ?
<doko> fabbione: didn't see that, although I don't have Core2 Duo hardware
<fabbione> doko: neither do i but i think Ben does
<fabbione> iwj: do you have any idea why hell of a lot of people end up with clvm installed?
<fabbione> at this point i think we should change the init script to be more stupid and a pain for sysadmins
<iwj> fabbione: No, I don't know why they have it installed.  But packages should in general be installable IMO :-).
<iwj> And being able to deinstall it again when it turns out to have been a mistake is I think essential.
<iwj> So yes please change it.
<fabbione> i see why it fails to install...
<fabbione> the changes we did in the SRU have been reverted
<fabbione> ok.. let me try to find something that can possible work without trashing user data
<fabbione> that package when configured become Essential: more than the other
<fabbione> iwj: ok let me fix it...
<iwj> fabbione: Thanks.
<fabbione> no problem
<fabbione> i just wonder when we lost the fix we did..
<fabbione> but well .. no big deal i guess
<shawarma> Who's got archive duty today?
<pitti> o/
<shawarma> pitti: I'm an idiot. Please nuke/reject/remove/whatever ebox-{openvpn,ca,network}.
<pitti> shawarma: uploaded to?
<shawarma> pitti: gutsy.. :(
<shawarma> pitti: Rather than my ppa. I can't spell, apparantly.
<pitti> shawarma: oh, those are NEW packages in gutsy; that's easy
<shawarma> pitti: Ah, yes, I suppose I should have pointed that out.
<pitti> otherwise I could only reject them out of accepted, which would generate some confusing noise :)
<pitti> shawarma: killed
<shawarma> \o/ 
<shawarma> pitti: Thanks!
<pitti> np
<fabbione> pitti: did you ever get around to accept multipath-tools ?
<pitti> fabbione: I'll do this today when I start SRU (after lunch, ETA an hour)
<pitti> fabbione: too busy with release stuff until yesterday, sorry
<fabbione> pitti: ok cool.. no rush please..
<pitti> I already asked for another archive admin to take my Friday shift
<fabbione> pitti: nothing to be sorry about. you have been busy for good reasons :)
<fabbione> Keybuk: i am preparing an lvm2 upload to fix some clvm stuff.. any idea why the init script for clvm was dropped from the merge? or just a simple mistake?
<Keybuk> I didn't think it was dropped?
* Keybuk still sees clvm.init in the package
<fabbione> can't be..
<Keybuk> there was no dh_installinit for it in the feisty package
<Keybuk> oh, hmm, maybe there was
<fabbione> dpkg -c /mirrors/ubuntu/pool/main/l/lvm2/clvm_2.02.24-6ubuntu1_i386.deb |grep etc | wc -l
<fabbione> 0
<Keybuk> that's probably what got dropped by accident
<fabbione> there was :)
<fabbione> yeah that's ok.. just making 100% sure
<Keybuk> yeah
<Keybuk> should be
<fabbione> i am readding it..
<Keybuk> dh_installinit -p clvm --no-restart-on-upgrade -- start 65 S . start 3 0 6 .
<fabbione> yeps.. i have it from feisty sources
<fabbione> thanks
<fabbione> hmmm we should also pull in the new upstream version for lvm2
<fabbione> it has an important fix when working with qdisk
<Keybuk> is that in Debian yet?
<dfeser> hi all!
<dfeser> some kernel-geeks here?
<fabbione> Keybuk: nope
<Keybuk> dfeser: #ubuntu-kernel
<pygi> hey sivang 
<sivang> hi pygi 
<Keybuk> fabbione: would make the next merge trickier
<pygi> sivang, how is it going?
<Keybuk> but then we're not carrying any major patchage to the source
<sivang> pygi: I'm not sure 
<sivang> pygi: managed to crash my feisty with some possibly ill written python threading code :)
<fabbione> Keybuk: it can wait up till UVF. The qdisk is nothing used in common configs or setups.. if debian doesn't make it by a week from UVF, we can just pull in new upstream
<fabbione> tho i would be happier to have it early to test the qdisk feature in full
<sivang> pygi: s/crash/halt/
<sivang> pygi: it was so bad that I couldn't do nothing to stop it but pull the plug / press the power button
<dfeser> can someone tell me what changed in the usb system from edgy to feisty? i have a script that boosts the usb power up to 500mA for my blackberry. with edgy this worked fine. but as I upgraded to feisty it stopped working
* pitti pokes ogra about bug 105709
<ubotu> Launchpad bug 105709 in ltsp "sound config not reset after thin client usage" [Undecided,In progress]  https://launchpad.net/bugs/105709
<ogra> oops, right
<pitti> mvo: bug 118815 approved; btw, feel freel to do similar uploads right away without prior approval in the bug; I can still reject it from the queue in the unlikely case of problems
<ubotu> Launchpad bug 118815 in app-install-data-commercial "SRU to add opera and arkeia " [Undecided,In progress]  https://launchpad.net/bugs/118815
<pitti> mvo: poke about gutsy fix for bug 109564
<ubotu> Launchpad bug 109564 in unattended-upgrades "README missing" [High,Fix committed]  https://launchpad.net/bugs/109564
<mvo> pitti: thanks, will look at them
<pitti> mvo: oh, seems you already uploaded a-i-d-commercial
<siretart> mvo: btw, any news about getting acroread in the commercial archive?
<cypherbios> mvo: will you merge the synaptic-set-reinstall.patch into the upstream?
<pitti> BenC_: good news! I did some debugging on the apport kernel issue and I think I pinpointed the bug in the fs/exec.c code; I created bug 119267 about that
<ubotu> Launchpad bug 119267 in linux-source-2.6.22 "apport patches for CORE_REAL_RLIM and limit overriding do not work any more" [High,Confirmed]  https://launchpad.net/bugs/119267
<BenC_> pitti: sweet, looks like a typo when I merged that patch (couple conflicts)
<pitti> BenC: the symptoms are perfectly consistent with that typo
<BenC> pitti: I'll get that fixed in next upload
<pitti> BenC: yay, thanks
<pitti> ShinyPointyStick...
<pitti> There is just *one* Sarah. *ONE* *nng*
<fabbione> ehhe
<Hobbsee> haha
<Hobbsee> pitti: no, three.
* pitti agrees to his evil twin brother
<Hobbsee> about?
<mvo> siretart: not yet, I talked to mdy about it and I will ping him again
<mvo> cypherbios: merged already
<mvo> :)
<Mithrandir> pitti: she just felt that having two of me was a bit on the high side, so she had to compensate.
<mvo> cypherbios: I plan a upload today
<StevenK> Mithrandir: Happy birthday!
<pitti> Mithrandir: perfectly understandable
<Mithrandir> StevenK: the same to you!
* StevenK grins
<pitti> Mithrandir: happy birthday!!
<Mithrandir> pitti: thank you :-)
<Hobbsee> Mithrandir: heh
<bhale> Mithrandir: hugs
<Mithrandir> bhale: thanks
* ShinyPointyStick attacks pitti 
<pitti> *eek*, why that?
* LongPointyStick joins in in the pitti attack
<dholbach> Mithrandir, StevenK: 
<dholbach>  _                               _     _      _   _         _             
<dholbach> | |__   __ _ _ __  _ __  _   _  | |__ (_)_ __| |_| |__   __| | __ _ _   _ 
<dholbach> | '_ \ / _` | '_ \| '_ \| | | | | '_ \| | '__| __| '_ \ / _` |/ _` | | | |
<dholbach> | | | | (_| | |_) | |_) | |_| | | |_) | | |  | |_| | | | (_| | (_| | |_| |
<dholbach> |_| |_|\__,_| .__/| .__/ \__, | |_.__/|_|_|   \__|_| |_|\__,_|\__,_|\__, |
<dholbach>             |_|   |_|    |___/                                      |___/ 
<ShinyPointyStick> double trouble!
<pitti> Shields up!
<dholbach> :-)
<StevenK> dholbach: Thanks!
* Hobbsee is sure that figlet and cowsay are kickable offenses
<Hobbsee> or does tha tonly apply during UDS?
<mvo> woooooooooooooahhhhhhhhhhhhhhhhhhhhh, hapy birthday!
<cypherbios> mvo: Thank you.
<Mithrandir> dholbach: thanks. :-)
<bhale> Hobbsee: cowsay -f ghostbusters
<Hobbsee>                                                      _ 
<Hobbsee>   ___ _____      _____  __ _ _   _    __ _ _ __   __| |
<Hobbsee>  / __/ _ \ \ /\ / / __|/ _` | | | |  / _` | '_ \ / _` |
<Hobbsee> | (_| (_) \ V  V /\__ \ (_| | |_| | | (_| | | | | (_| |
<Hobbsee>  \___\___/ \_/\_/ |___/\__,_|\__, |  \__,_|_| |_|\__,_|
<Hobbsee>                              |___/                     
<Hobbsee>   __ _       _      _          _           _                _ 
<Hobbsee>  / _(_) __ _| | ___| |_    ___| |__   __ _(_)_ __   ___  __| |
<Hobbsee> | |_| |/ _` | |/ _ \ __|  / __| '_ \ / _` | | '_ \ / _ \/ _` |
<Hobbsee> |  _| | (_| | |  __/ |_  | (__| | | | (_| | | | | |  __/ (_| |
<Hobbsee> |_| |_|\__, |_|\___|\__|  \___|_| |_|\__,_|_|_| |_|\___|\__,_|
<Hobbsee>        |___/                                                  
<Hobbsee>  _                   _   _                 _                            
<Hobbsee> | |_ ___   __ _  ___| |_| |__   ___ _ __  (_)___    _____   _____ _ __  
<Hobbsee> | __/ _ \ / _` |/ _ \ __| '_ \ / _ \ '__| | / __|  / _ \ \ / / _ \ '_ \ 
<Hobbsee> | || (_) | (_| |  __/ |_| | | |  __/ |    | \__ \ |  __/\ V /  __/ | | |
<Hobbsee>  \__\___/ \__, |\___|\__|_| |_|\___|_|    |_|___/  \___| \_/ \___|_| |_|
<Amaranth> oh god
<Hobbsee>           |___/                                                         
<mjg59> Hobbsee: ...
<Hobbsee>                                             _ _ 
<Hobbsee>  _ __ ___   ___  _ __ ___    ___ ___   ___ | | |
<Hobbsee> | '_ ` _ \ / _ \| '__/ _ \  / __/ _ \ / _ \| | |
<Hobbsee> | | | | | | (_) | | |  __/ | (_| (_) | (_) | |_|
<Hobbsee> |_| |_| |_|\___/|_|  \___|  \___\___/ \___/|_(_)
<Hobbsee> 
* mode/#ubuntu-devel [+o Mithrandir]  by ChanServ
<Hobbsee> oh shit, wrong way around.
* persia notes that this sort of thing word-wraps quite poorly.
<Hobbsee> apologies.
<pitti>  /kick_ban_lart Hobbsee 
<bhale> holy flood protection
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
<persia> Hobbsee: Is your connection especially slow, or are you typing by hand?
<mjg59> persia: Rate limiting
<Amaranth> client throttles so you don't flood out
<fabbione> my eyes
* mode/#ubuntu-devel [-o Mithrandir]  by Mithrandir
<LongPointyStick> oh dear...sorry guys.
<LongPointyStick> wow, that client is lagging.
<Amaranth> i bet
<Hobbsee> again, apologies
* Hobbsee goes and hides in the corner.
<pygi> that's good
* Hobbsee is really surprised she didnt get kicked off the network for that, actually
<pitti> Mithrandir: claws-mail is currently blacklisted, but only temporarily; can this be removed?
<Mithrandir> pitti: sure, if it doesn't make sync-source fail.
<pitti> Swap file "/srv/launchpad.net/dak/.sync-blacklist.txt.swp" already exists!
<pitti> hmm
<Mithrandir> pitti: if you feel like it, removing all the bits and doing a full automatic sync would probably be good
<Mithrandir> pitti: free now
<Hobbsee> pitti: that au connection may well drop, as we're supposed to have even more storms here over the weekend - so the power will likely go out from my prefered au connections.
<Hobbsee> pitti: hence, that's a backup for the backup and the primary.
* Hobbsee shrugs
<pitti> Mithrandir: seems to work; unblacklisted
<StevenK> afflux: Would you mind unsubscribing -archive from bug 119317?
<ubotu> Launchpad bug 119317 in empathy "Please sync empathy (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/119317
<afflux> StevenK: didn't you just say in -motu that I can't?
<StevenK> Bah
<StevenK> pitti: ^
<StevenK> I'm not doing well tonight, it appears.
<pitti> StevenK: what's wrong with that bug?
* Mithrandir hugs bzr uncommit
<Mithrandir> best command ever.
<Hobbsee> you can just reject it, too
<pitti> (I am doing syncs ATM anyway, I'll get to it soon)
<StevenK> pitti: It isn't ack'd by an motu
<pitti> Mithrandir++
<pitti> StevenK: hm, so it should be needsinfo or so?
<StevenK> I'll set it to needs info so you can ignore it for the time being.
* afflux hardcodes a "sponsorship=True" in the requestsync script
<StevenK> Heh
<Hobbsee> or someone can just ack the sync request
<StevenK> Hobbsee: Thanks for volunteering.
<Hobbsee> i'm not volunteering, i'm trying to avoid being killed by the irc police.
<Mithrandir> Hobbsee: view it as community service.
<StevenK> Heh heh.
<Hobbsee> Mithrandir: hah.
<StevenK> Here, wear this bright orange tracksuit while you do it.
<Hobbsee> mmm...orange...
* Hobbsee wants her orange jacket back in *unburned* state, please!
<pygi> pitti, question:
<pygi> bug #107499
<ubotu> Launchpad bug 107499 in brasero "Brasero will not burn " [Undecided,Fix committed]  https://launchpad.net/bugs/107499
<pygi> how could you add that brasero to feisty-proposed since we don't have libburn & libisofs there?
<StevenK> pitti: Yay you for the epydoc pointer, I'll prepare that merge and upload.
<pitti> pygi: it was uploaded to feisty-proposed by a MOTU
<pygi> pitti, mhm ... I do hope 0.5.2-0ubuntu2 was uploaded there
<pitti> StevenK: I'm not aware of doing anything about it, but you're welcome :)
<pygi> pitti, otherwise if it's 0.5.90 it'll fail to build
<pitti> pygi: 0.5.2-0ubuntu1.1
<pygi> (I have 0.5.90 in gutsy universe uploaded)
<StevenK> Oh damn, it was doko, not pitti.
<pygi> pitti, meh, ok then. That should work. thanks
* StevenK slams his head through the wall.
<StevenK> Damnit brain, work!
* Hobbsee repairs the wall
<Hobbsee> dont attack the wall!
<pitti> StevenK: so I don't sync epydoc yet, right?
<StevenK> pitti: Right.
* pitti rejects the bug then
<StevenK> pitti: Ahh, ta.
<afflux> StevenK: since you seem to be working on devscripts at the moment: can you have a look at bug 119313
<ubotu> Launchpad bug 119313 in devscripts "requestsync can't handle third parameter (basever) but advertises it in usage" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119313
<pitti> StevenK: hey, that worked with my version still :)
<StevenK> I managed to break it anyway. :-(
<pitti> I admit I haven't used it any more for a long time
<StevenK> ubuntu7 is on it's way up
<simira> Hobbsee: hey, what are you up to?
<Hobbsee> simira: i'm dying at the thought of work this weekend.
<simira> (and where did my glass of water go)
<Hobbsee> the water-drinking-gremlins came after it.
<simira> why, don't you have winter down under now?
<Hobbsee> simira: so if you could find a good reason for me to be able to call in sick for the entire weekend, please tell :)
<Mithrandir> simira: for once, I did not put it into the dishwasher.
<Hobbsee> ahha
<Hobbsee> *haha
<simira> Hobbsee: you need to go to this important conference in Europe?
<Hobbsee> simira: without having N/A'd for it?
<Hobbsee> simira: iv'e got this feeling that the boss would get rather abusive if i didnt have a very good reason.
<Hobbsee> like, being dead.  and that's a little over the top.
<Hobbsee> evening mdz 
<rpereira> Does someone knows if is there a developer packaging nprobe?
<mdz> Hobbsee: hi
<Hobbsee> :)
<Hobbsee> rpereira: have you checked on any bugs, either in ubuntu or debian, saying as much?
<fabbione> anybody here has a laptop with kubuntu / tribe 1 running?
<Lure> fabbione: yep
<sn0> not a laptop fabbione 
<fabbione> Lure: do you have "suspend/hybernate" options in your logout menu?
<Lure> fabbione: not on live-cd
<fabbione> Lure: i only need to know for an installed system
<Lure> fabbione: I have on installed system
<Lure> fabbione: this is detected by HAL
<Hobbsee> i do
<fabbione> https://bugs.launchpad.net/ubuntu/+bug/119326
<ubotu> Launchpad bug 119326 in Ubuntu "No hibernate nor sleep button in the quit menu of Gutsy Tribe-1" [Undecided,Unconfirmed]  
* fabbione scratches his head
<pitti> fabbione: gnome-session miscommunicates with hal ATM
<fabbione> pitti: ah ok.. known issue?
<pitti> fabbione: dup of bug 118537
<fabbione> i mean.. is there a bug open already?
<fabbione> ok coolness
<fabbione> thanks
<pitti> fabbione: I even mentioned it in the release notes
* pitti pokes ubugto
<fabbione> ok...
<ubotu> Launchpad bug 118537 in gnome-session "logout dialog does not offer suspend/hibernate" [High,Fix released]  https://launchpad.net/bugs/118537
* fabbione admits that 1) didn't read the release notes 2) does never suspend or hybernate
<mvo> hey racarr! I was wonering what is the best graphic card to play with compiz and compcomm. I currently use a r200 and that one like to freeze every now and then
<fabbione> there... 4 bugs less in clmv
<fabbione> clvm even
<Hobbsee> yay!
* Hobbsee hugs fabbione 
<fabbione> :)
* fabbione takes a short break
<pitti> gpocentek: ping
<gpocentek> pitti: hello
<pitti> gpocentek: shouldn't libgoffice-gtk-0-4 have a Provides: libgoffice-0-4 ?
<pitti> gpocentek: they ship the very same .so file after all
<dholbach> gpocentek: also pitti suggested to drop the -dbg packages
<pitti> gpocentek: (or put a copyright and changelog into -dbg)
<pitti> but we don't need -dbg
<gpocentek> sounds good
* dholbach hugs gpocentek and pitti
<slomo> mjg59: ping... you're aware that your gst-plugins-base alsa patch breaks ABI and API?
<Keybuk> keescook: basically we don't know what to run from a udev rule to activate mdadm partitions
<keescook> as in, we don't know when an mdadm-controlled partition is "finished"?
<Keybuk> no, that we have solved
<Keybuk> we just don't know how to invoke mdadm to make it assemble block devices as they come in
<keescook> this doesn't seem to be the problem, though; at boot my dm devices are fine.
<keescook> sorry, md
<slomo> mjg59: unping, nevermind... i just noticed that seb reverted it a week ago :)
<Keybuk> keescook: well, the problem is that it goes through a very messy shell script
<Keybuk> sometimes
<Keybuk> in fact
<Keybuk> there's three messy shell scripts
<Keybuk> which aren't touched outside the initramfs
<Keybuk> etc.
<Keybuk> so until we understand that, we haven't applied the fix for the lvm issue
<Keybuk> would rather not build a house on a shaky foundation
<Keybuk> type thing
<keescook> makes sense.  :)
<Keybuk> will be looking into it next week
<Hobbsee> !logs | StevenK 
<ubotu> StevenK: Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs
<carlos> pitti: hmm, language pack updates for Gutsy are pretty big already ...
<carlos> pitti: http://people.ubuntu.com/~carlos/language-packs/gutsy-updates/
<pitti> carlos: erk
<carlos> pitti: we just finishing all KDE translations for Gutsy
<carlos> and that's a lot of .po files
<carlos> s/finishing/finish importing/
<TeTeT> should the isotesting tests also contain 'works' entries, or only reports when it fails?
<pitti> TeTeT: also 'works' ones
<pitti> TeTeT: they are important for test coverage at pre-release times
<pitti> TeTeT: now the 'works' ones don't make much sense any more for tribe-1, of course
<TeTeT> pitti: ok, so the next useful time would be a day or two before the release of tribe-2?
<pitti> TeTeT: right
<pitti> TeTeT: if you test tribe-1, please do make sure that bugs are filed, though, and point them out to me if they are serious
<Mirv> mvo: hi... any plans when the 0.3.31 is going to migrate from feisty-proposed to feisty? it's been there for over a month now. after that I'd guess it'd be possible to translate the missing bits in Rosetta for the next translation update.
<Mirv> gnome-app-install, that is
<mvo> Mirv: do you have the bugnumber for it at hand? I will check immediately then
<Mirv> mvo: https://bugs.launchpad.net/ubuntu/feisty/+source/gnome-app-install/+bug/106756
<ubotu> Launchpad bug 106756 in gnome-app-install ""Search for suitable codec" dialog not translated/translatable" [Undecided,Fix committed]  
<pitti> mvo: poke me about copy-package please, my regular session is already over
<Mirv> or is it pitti's stuff, as he accepted it to feisty-proposed
<pitti> Mirv: no, I don't verify, since I already approve patches and so on; multiple-eyes principle
<Mirv> pitti: ok
<mvo> its still in verification-needed stage :/ I can't do a verification myself, I will prod bdmurray about it and write up some proper instructions how it can be verified 
<mvo> Mirv: thanks for pointing it out again and sorry that it takes so long sometime
<mvo> s
<Mirv> mvo: no prob
<pitti> mvo_: AYT?
<mvo_> pitti: hello
<mvo_> sorry, network is a bit bad today, my provider has upgraded me without asking 
<pitti> man, 'bzr shelve' is the best thing since slice bread
* Hobbsee wonders what that does
<pitti> Hobbsee: it moves hunks from bzr diff to a 'shelf' where you can retrieve it later; shelving and unshelving works per-hunk, per-file, or globally
<pitti> so you can selectively commit larger changes, or do 'bzr shelve --all', quick fix, bzr commit, unshelve
<Hobbsee> nice :)
<ion_> So, a bit like what darcs does. Thats very nice.
<Kmos> repo for gutsy isn't frozen anymore ?
<Hobbsee> nope
<cjwatson> pitti: yes, bzr shelve is fantastic
<cjwatson> ion_: I believe darcs is a bit different in that you choose to commit only particular hunks
<cjwatson> I think bzr is a bit nicer here since it's easier to test what you're committing if "shelve some hunks" and "commit the rest" are separate operations that you can slot something between
<Kmos> anyone have time to look at http://revu.tauware.de/details.py?upid=5396 (gqview latest stable version)
<Kmos> i think the package is ok for uplaod
<Kmos> *upload
<Kmos> https://launchpad.net/ubuntu/+source/gqview
<keescook> archive admins, can you check on a binary-NEW of "libmyth-dev"?  I don't see it listed at https://launchpad.net/ubuntu/gutsy/+queue but it's not been published yet.
<keescook> am I just looking in the wrong places?
<pitti> keescook: I NEWed it some hours ago
<keescook> pitti: ah! okay
<keescook> so I just happened to look at the wrong time.  :P
<pitti> libmyth-dev | 0.20-svn20070523-0.0ubuntu1 | gutsy/multiverse | amd64, i386, ia64, powerpc
<keescook> apt-get updating...
<keescook> yay! pitti: thanks, it has appeared.  sorry for the noise.  :)
<pitti> np :)
<Kmos> anyone have time to look at http://revu.tauware.de/details.py?upid=5396 (gqview latest stable version) ? pitti can't.. thanks
<Seveas> pitti, keescook: as 'ubuntu secrity dudes' you may appreciate ubotus latest feature
<Seveas> CVE-2007-1337
<ubotu> The virtual machine process (VMX) in VMware Workstation before 5.5.4 does not properly read state information when moving from the ACPI sleep state to the run state, which allows attackers to cause a denial of service (virtual machine reboot) via unknown vectors. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1337)
* keescook hugs Seveas 
<keescook> that's great!
<pitti> Seveas: yay!
<Kmos> that's my bug report :)
<Seveas> indeed
<Kmos> Seveas: fix released? 
<Seveas> Kmos, not until I commit the code :)
<Kmos> :)
<Kmos> Seveas: can you look at bug of "@" in .cgi (web interface), i've done a modification in the file with urllib.unquote
<Seveas> yeah, will do that later
<Kmos> Seveas: thx
<Kmos> !factoids
<ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://bots.ubuntulinux.nl - Usage info: http://wiki.ubuntu.com/UbuntuBots
<Kmos> !factoid nv
<ubotu> Sorry, I don't know anything about factoid nv - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Kmos> !nv
<ubotu> To install the Ati/NVidia drivers for your video card, see https://help.ubuntu.com/community/BinaryDriverHowto
<linnuxxy> is it possible to test gfxboot using qemu?
<linnuxxy> how can i create an iso test for gfxboot?
<linnuxxy> I'm building an Arabic Edition of K/ubuntu... the starting page of the LiveCD is rendering the arabic text incorrectly... I think it is gfxboot problem... how can I debug gfxboot using qemu?
<cjwatson> linnuxxy: http://people.ubuntu.com/~cjwatson/tmp/gfxboot-test.tar.gz is a very rough test harness for gfxboot with qemu; some assembly required
<cjwatson> linnuxxy: I'd be extremely surprised if gfxboot knew how to do Arabic shaping, and suspect a significant amount of code would be needed to make it do so
<keescook> cjwatson: can you look this over: https://wiki.ubuntu.com/UsingUUID
<keescook> I want to reference it in the kernel update USN
<keescook> (it's based on discussions with Keybuk)
<linnuxxy> cjwatson: in fact it isnt that far from render arabic text well
<linnuxxy> the font is loaded ok... but words are rendered in separate letters (instead of script ones) and in reverse direction 
<cjwatson> linnuxxy: yes, that's what I mean
<cjwatson> I don't think gfxboot knows about either RTL or joining the letters together, the way Arabic should be
<cjwatson> all it has is the font
<cjwatson> I might be wrong on RTL, but I'm pretty sure about the shaping :-/
<cjwatson> keescook: ok, will do later, dinner now
<linnuxxy> the package u gave doesn't simulate same thing 
<cjwatson> linnuxxy: it's not identical, but it's a functional gfxboot test case. You may have to put a number of bits and pieces together.
<cjwatson> it's just what I use to test newer versions of the theme
<linnuxxy> cjwatson: thnx
<slomo_> hrm
<slomo_> ghostscript is broken
<saispo> and gnome-power-manager is really silly on latest gutsy under a Dell Laptop :)
<saispo> it announce me 5 minutes... and shutdown...
<Burgundavia> there is a nasty bug
<saispo> yep :/
<saispo> all work fine under feisty
<saispo> it announce 100% fully charged and 5 minutes lifetimes :)
<cjwatson> keescook: best recommend just 'sudo update-grub' rather than using the absolute path; but otherwise looks good
<keescook> cjwatson: yeah, I debated about that one
<keescook> okay, great.
<keescook> one question I have is that /etc/fstab still has non-symlinks for things like cdroms.
<keescook> it seems that was only fixed in the installer?
<cjwatson> I think the upgrade tool had to munge that
<cjwatson> check with mvo?
<keescook> okay, thanks
<cjwatson> oh, hmm, the installer might use the physical devices actually
<cjwatson> can't remember what it prefers
<cjwatson> partman-target bug if so
<slomo_> cjwatson: can you give gstreamer0.10 back on x86? it builds fine locally...
<cjwatson> slomo_: no, I am not able to give back packages
<cjwatson> you want somebody in ~launchpad-buildd-admins
<slomo_> oh, i thought you could do it too... sorry
<cjwatson> nope
<saispo> Burgundavia: you have seen this bug ? under gutsy, hibernate don't work, just sleeping...
<saispo> all work fine before on feisty
#ubuntu-devel 2007-06-09
<YokoZar> What do I need to have the ability to post to ubuntu-devel without moderation?
<minghua> YokoZar: you need to be a ubuntu developer, see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<YokoZar> Are MOTUs developers for this purpose?
<crimsun> yes.
<Fjodor> Are the powertop patches for mixer_applet2 and knotify incorporated in gutsy sources, and would it be possible to get them into feisty?
<crimsun> Fjodor: I'm not sure they qualify as critical bugfixes or security errata.
<crimsun> (not my call, but I don't feel they do.)
<Fjodor> crimsun: You are most probably right. Just asked to get an opinion. I guess they will be applied upstream at some time, and then, naturally, get into gutsy or gutsy+1
<Fjodor> Would be neat to have them in feisty, though. Dell dk has decided to remove options from the configuration dialogues for buying systems, without mentioning that more options are available if you call them. Thus, my laptop has a 6-cell battery, and not a 9-cell one...
<Fjodor> Hence my interest in powertop
<oeoeoeo> http://www.gov-civil-leiria.pt/index.php?p=http://ikhlas.com.my/cmd.txt??
<mikmorg> hi
<mikmorg> If a package is listed in pool/main/source/Sources.gz, does it mean that it is preinstalled with Feisty gold?
<mikmorg> rather, dists/feisty/main...
<mvo> mikmorg: no, just that it is available and supported
<mikmorg> mvo: ah.. could you tell me where I could find a list of preinstalled packages?
<mikmorg> actually.. hmm, nevermind
<mikmorg> i just realized it wouldn't help me
<bryyce> mikmorg: see https://wiki.ubuntu.com/SeedManagement
<mikmorg> bryyce: thanks
<kylem> win 23
<nn-laptop> hi all
<calc> Hobbsee: hello :)
<Hobbsee> heya calc!  how's it going?
<calc> doing ok
<Hobbsee> :)
<calc> need to start getting everything ready for my start on monday
<Hobbsee> woo :)
<Hobbsee> simira: famous last words, i'm afraid...
<Fructose> I'm trying to use some kernel headers with existing code, but /usr/include/linux/init.h doesn't exist. The directory does and I have linux-headers installed, so what gives?
<mirob> mjg59, who are you to announce on the "debian-project" mailing list as part of many defacements, that "the Ubuntu Community does not want Patrick Frank"?
<mirob> sabdfl, is it possible to talk to you directly about community related things?
<Kmos> bug 3222
<ubotu> Launchpad bug 3222 in vim "gvim is hidden in menu" [Medium,Confirmed]  https://launchpad.net/bugs/3222
<Kmos> i think it's already fixed
<mrmonday> I was just wondering if any devs knew the password for the kubuntu liveCD
<elkbuntu> mrmonday, did you try just hitting enter?
<mrmonday> yes
<mrmonday> and I tried ubuntu, no pass
<mrmonday> and that just restarted X
<elkbuntu> hmm... try asking #kubuntu
<mrmonday> ok
<Riddell> mrmonday: there isn't one
<mrmonday> Riddell, how come I'm asked for one then?
<mrmonday> any other ideas?
<Hobbsee> hey all
<hunger> Why was my screen resolution changed again?
<Toxicity999> Wow, so... So sorry for my bouncer flipping out, apparently I spammed channels all night without knowing.
<Hobbsee> useful of it :)
<Toxicity999> Well, it was join/parting insanely. I must of left irssi running in the background then started xchat or something. Banned in a few of my channels, trying to take care of that ><
<Hobbsee> Toxicity999: which channels got banned?
<Toxicity999> Eh, Only #winehq that I've noticed, none others have come to mind to try.
<Toxicity999> or not, that got undone
<Toxicity999> nice.
<pygi> hey Zdra_ 
<Zdra_> hello pygi
<pygi> Zdra_, saw somebody changed the bug report
<Fjodor> Does anyone know how to get around bug 110585?
<ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
<Fjodor> Anyone?
<UnholyLegion> hm?
<Fjodor> UnholyLegion: Does anyone know how to get around bug 110585?
<ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Hobbsee> i suspect if they had, they'd respond on the bug report
<Fjodor> Strange part is that debian installer seems to work, so my solution, for now, is to use debian. Would like to use ubuntu on it, though...
<Fjodor> Hobbsee: Good point, however, I didn't report it. Only development seems to be reports from others that they see it. Thanks though
<Fjodor> Coming to think of it, it might actually be a kernel prob, since I would guess that the installer fails to see a valid entry in /dev
<Fjodor> And debian, which seem to work, is 2.6.18-something
<Fjodor> *seems
<Fjodor> I think I found another link stating that compaq smartarray can't be loaded from initramfs, and that it isn't compiled into the ubuntu kernels. Might that be the problem?
<Fjodor> ...and possible fix?
<Hobbsee> ask cjwatson or evand, on a weekday
<Fjodor> Hobbsee: Ok, thanks
<persia> Fjodor: If you're feeling confident, you might also want to leave a comment in the bug with the details (if they're not already there).
<Fjodor> persia: I might leave a link to that page (if I can find it again), but other than that, I think even the bug headline says it all... Thanks, though
<Fjodor> http://whocares.de/2006/07/07/ubuntu-and-the-compaq-smart-array-controller-cpqarrayko/ FWIW. It might be a good idea to compile cpqarray into the kernel on server builds...
<shawarma> Fjodor: No need.
<Fjodor> shawarma: Ok
<shawarma> Fjodor: Since Edgy we've included all drivers found under block/ in our initrd's.
<shawarma> Fjodor: Which likely solves that problem.
<Fjodor> shawarma: that might be so, and you probably logged on after I ranted about bug 110585
<ubotu> Launchpad bug 110585 in debian-installer "7.04 Server install fails on Compaq Proliant DL360" [Undecided,Unconfirmed]  https://launchpad.net/bugs/110585
<shawarma> I logged on 52d 2h 46m 6s ago. :)
<Fjodor> At any rate, it _is_ a problem, but not necessarily due to that
<Fjodor> Ah, ok :-)
<shawarma> Fjodor: Sorry, I'll try reading the article more closely. Hang on.
<shawarma> I just opened the bug, and I'm really confused.
<shawarma> The title says 7.04, the first version mentioned is 6.10 and the next one is 7.10..
<Fjodor> Anyways, I find it odd that the debian installer seems to see the array just fine, but the ubuntu one doesn't... Could be due to debian having kernel 2.6.18, and the problem being a recent kernel bug, though
<StevenK> The reason the installer sees it is because it loads the module.
<Fjodor> Yes, that is strange, but I hit it with 7.04 server installer
<Fjodor> StevenK: Might be a good idea for the ubuntu server installer to load it too, then...
<shawarma> Alright. I've read the bug now. Now for the article.
<shawarma> Fjodor: It does.
<shawarma> Fjodor: It sees the device, doesn't it?
<Fjodor> shawarma: To be honest, I only skimmed the article. It might mean nothing
<shawarma> Fjodor: For some reason it just can't figure out the geometry of it.
<Fjodor> shawarma: It sees the device (c0d0), but not the constituent drives (c0d0p1-4)
<shawarma> Fjodor: i forget the notation. c0 is controller 0, d0 is disk 0? p1-p4 are the partitions?
<Fjodor> Ah, that may be so. Wouldn't know, as it is my first time doing raid. However, it does indeed complain that it can't determine the geometry
<Fjodor> ...p1-4 is most probably the partitions, yes, but I could only make those during debian install
<shawarma> Fjodor: Sounds like a kernel bug, IMO.
<Fjodor> shawarma: indeed. Unfortunately, it's a showstopper for installing ubuntu on such servers...
<shawarma> ...which is more likely to be looked at on Monday.
<shawarma> Fjodor: Yes, I can understand.
<Fjodor> shawarma: Yes, that's the message I got. However, the initial bug report doesn't seem to have generated a lot of interest...
<shawarma> Fjodor: Would you mind testing with the Tribe CD?
<shawarma> Fjodor: *Only* for testing, though.
<shawarma> Fjodor: Do *not* use it in a production environment.
<shawarma> Fjodor: Just to see if it helps at all.
<Fjodor> shawarma: I'll be happy to dl it and have a go. As long as I don't commit any changes, it shouldn't affect the debian system that has just now finished installing, right?
<Fjodor> URL?
<shawarma> Fjodor: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-June/000301.html
<Fjodor> thanks
<shawarma> Fjodor: In particular: http://cdimage.ubuntu.com/releases/gutsy/tribe-1/gutsy-server-i386.iso
<Fjodor> Indeed
<shawarma> Fjodor: I'd say that if you make it all the way to the partitioner, the issue has been fixed in the new kernels.
<shawarma> Fjodor: You can just bail out when you get there, and nothing will have been changed on your running system.
<shawarma> Fjodor: That will be valuable info to put on the bug.
<Fjodor> shawarma: That's what I thought. I'm dl'ing now, and ETA is in 7 minutes
<shawarma> Fjodor: Alright. I'll be AFK for an hour or so.
* shawarma wanders off
<Fjodor> shawarma: Ok. Thanks so far
<forum2006> live cd question: in which script ubuntu mounts the overlay filesystem?
* Hobbsee waves to simira 
<simira> :)
<simira> was that a volunteer to fix our server?
<simira> (I don't usually go offline in the middle of the day like that)
<Hobbsee> simira: it's a bit hard if i'm not there...
<Hobbsee> simira: that's what i thought.  your connection's supposed to be better than mine!
<Fjodor> shawarma: gutsy installer also gives the error
<simira> Hobbsee: is not the connection, it's our server ;)
<Mithrandir> or it's the VPN endpoint.
<Mithrandir> I think I'll fetch a fan from the basement and point it at the poor box
<Hobbsee> heh
<Mithrandir> it's a G3, it's not used to summer
* Hobbsee shivers, looks forward to summer
<Hobbsee> er, there was supposed to be an "and" in there
<geser> Mithrandir: could you please give-back bfilter on all archs? thanks
<Hobbsee> geser: i believe you're not supposed to bug people on holidays :P
<Mithrandir> geser: given-back.
<geser> Hobbsee: will wait the next time till workdays (or do it when you don't watch :)
<Hobbsee> heh
<Mithrandir> Hobbsee,geser: I don't mind being asked for give-backs even when on holidays, if I'm not near the computer, I won't do them, and if people ask me to fix X, Y, Z and , I probably won't because it's too much work at that time.
<shawarma> Fjodor: Could you note that on the bug?
<Fjodor> shawarma: Sure
<shawarma> Fjodor: Coolness.
<geser> Is the upload queue processing stopped?
<Hobbsee> geser: which one?
<elmo> oh, meh
* Hobbsee waves to elmo 
<geser> the Ubuntu one
<geser> I've done two uploads but got no mail yet
<Hobbsee> mail is delayed - does it show up on launchpad?
<elmo> it'll be the LP outage earlier
<elmo> sorry I forgot to kick stuff on drescher
<elmo> doing so now
<Hobbsee> elmo: good way of doing sysadmin work - kicking objects or people.  next you'll be defenestrating them, i expect.
<elmo> Hobbsee: sure - whatever works
<elmo> geser: next upload run should happen as normal - thanks for mentioning it
<Hobbsee> elmo: hehe.  i wonder if i could convince people to write my specs that way...
<Hobbsee> or do what i want them to...
<Hobbsee> er, more than they have been already
<phanatic> Hobbsee: defenestrating from the 27th floor isn't funny :P
<ion_> phanatic: URL?
<Hobbsee> phanatic: sure, but from the 32nd it is!
<phanatic> ion_: what url?
<phanatic> Hobbsee: have you tried?
<ion_> phanatic: So that we can see whether its funny or not for outselves.
<Hobbsee> phanatic: i cannot answer on the basis that it may incriminate me
<phanatic> ion_: oh, sorry... i haven't tried it yet tbh
<phanatic> ion_: i've just been to the canonical office before, and believe me, it's pretty high :)
<Hobbsee> phanatic: sounds like fun.  worth a try, for defenestrating people
<geser> elmo: thanks. I got now the accepted mails.
<calc> 27th floor is pretty high, i had a window office on 9th floor at HP and it seemed high to me, heh
<linnuxxy> how to build a myspell dictionary from a large number of documents?
#ubuntu-devel 2007-06-10
<jordi> hey
<jordi> where should one tickle to get a package synced from Debian?
<jordi> apparently, ubuntu still has no openttd (contrib section)
<minghua> jordi: I believe you should ask an archive admin
<jrib> jordi: https://wiki.ubuntu.com/SyncRequestProcess I believe
<jordi> okay
<minghua> And I think Mithrandir is one.  But it's weekend, so I am not sure he is working on archives now.
<jordi> https://bugs.launchpad.net/ubuntu/+bug/119631
<ubotu> Launchpad bug 119631 in Ubuntu "Please sync "openttd"" [Undecided,Unconfirmed]  
<jordi> thanks minghua, jrib 
* persia updates the bug to get it applied
<persia> jordi: openttd?  I can't find that package.
<minghua> I think that's probably a relatively new package in Debian (and therefore has never been in Ubuntu before).
<persia> minghua: That makes sense.  I guess I just don't understand autosync then.  The part that is especially confusing is that Debian changelog goes back to 2004.
<minghua> persia: Oh.  Look at the Debian PTS page then, it shows all the official uploads.
* minghua checks himself
<persia> minghua: Right.  Only two.  Odd.  Anyway, test-build in gutsy has been underway for a bit, but I'm puzzled by the package.
<minghua> Three uploads, actually, and the first in April 2007: http://packages.qa.debian.org/o/openttd.html.
<minghua> persia: That's why I just point to the archive admins and leave such issues to more experience people. :-)
<jordi> minghua: what issue?
<persia> OK.  I think that should do it.
<jordi> yeah, the package had been maintained outside debian for a while
<minghua> jordi: "Syncing contrib packages from Debian", in this case.  Generally, anything involved with archive management (ftp-master work in Debian speak).
<jordi> and a few months ago I worked with the author to clean it up and get it ready for Debian
<jordi> ah, I see
<jordi> I didn't know contrib packages were tricky
<minghua> (probably archive admins act as the Debian RM role as well)
<jordi> persia: mm, does it need to go to multiverse?
<persia> jordi: Perhaps not.  I'll take another look at the license.
<jordi> persia: the code is GPL
<jordi> it won't run without some origianl, non-free data pack, though
<jordi> same case as Quake: the engine is free, but the data isn't
<persia> jordi: I think it does, because it depends on the non-free data pack, but I'm not an authority.
<persia> jordi: quake2 is in multiverse, so I think so (unless I misunderstand).
<jordi> quake2 would be a nice example to follow yes
<persia> jordi: OK.  Multiverse it is then.  Thanks for the bug.
<jordi> persia: thanks for acking
<octoberdan> I want my program to be alerted when a usb device is connected. How would I go about this? Is there a way other then to construct some sort of check loop?
<octoberdan> Would I have to write a kernel module?
<octoberdan> Is this the wrong place to ask?
<mjg59> This isn't really the right place to ask
<mjg59> But the easiest thing to do is probably to use hal
<mjg59> It'll notify you
<octoberdan> Thanks
<octoberdan> Where should I be asking a question like this?
<mjg59> #hal may be worth a go
<DARKGuy> Hey, if I want to submit a fix for Ubuntu for a file in /usr/lib/i18n/ for fixing a timezone, what would I have to do?
<DARKGuy> nevermind,I got answered in #ubuntu :Pp
<AAE> is ubuntu #1 ?
<AAE> for use base
<AAE> its a tossup between waiting for solaris 11 getting free bsd or keep on using suse
<AAE> or of course getting ubuntu
<Hobbsee> i believe you want #ubuntu or #ubuntu-offtopic
<Fructose> Is there a particularly good server/channel for asking questions related to kernel/driver development?
<Hobbsee> Fructose: #ubuntu-kernel i believe, but not on a weekend
<Fructose> Hobbsee: Hmm. OK. Know of any that aren't distro-specific?
<Hobbsee> Fructose: um....  maybe #kernel or something?  google should help you out there
<Fructose> Hobbsee: Well, I've been trying. Maybe those are weekday-only channels too.
<Hobbsee> well, at least for here, the guys employed to work on ubuntu dont tend to do weekends if there isnt a need 
<Fructose> I thought maybe the hobbyists might be around on the weekend.
<Hobbsee> true that
<Hobbsee> it's also european night
<Hobbsee> and going into US night
<Fructose> That's what caffeine's supposed to be for :-)
<Hobbsee> heh ;)
<Hobbsee> hi Burgundavia 
<Burgundavia> hey Hobbsee
<desrt> hello Capspeople
<desrt> Capspeoplewithnicksvaguelybasedonlastnames, even
<Burgundavia> desrt: actually, my nick is not based on my last name
<desrt> Burgundavia; i find your claims suspicious at best
<spasticteapot> I just switched from Xubuntu Feisty to Ubuntu Feisty.
<Burgundavia> desrt: the name is a bastardization of the place of Burgundy
<Burgundavia> hello spasticteapot
<spasticteapot> While there seem to be a lot of bugs with Xubuntu (everything keeps crashing), Ubuntu/Gnome seems to be running beautifully.
<spasticteapot> Even with my CPU throttled back to 600mhz!
<spasticteapot> Nice job!
<Burgundavia> spasticteapot: we urge you to report those bus
<Burgundavia> bugs, rather
<spasticteapot> I'm not quite sure how.
<spasticteapot> The biggest problem is that just about everything crashes a lot.
<spasticteapot> Oh, sweet!
<Hobbsee> desrt: heh
<spasticteapot> My cheapie PCMCIA CD-ROM drive works!
<spasticteapot> You guys kick ass!
<spasticteapot> Aside from bug reports, is there anything I can do to help the Ubuntu project?
<Hobbsee> desrt: hello lowercaseperson
<Burgundavia> desrt: are you high or merely high on life?
* Hobbsee is just plane insane.
<Hobbsee> er, plain insane.  due to planes, of cours.e
* desrt is up on lowercase
<pygi> jdong, poke
<pygi> hey mvo  ^^_
<pygi> ^_^
<mvo> hey pygi
<Kmos> http://wubuntu.weejewel.net
<Kmos> lol
<okaratas> hello
* Hobbsee waves to the disturbing jono 
<jono> disturbing?
<Hobbsee> jono: that blue shirt...
<jono> which blue shirt?
<StevenK> Oh, you didn't have to bring that up.
* StevenK twitches from the memory.
<Hobbsee> jono: the light blue meduxa one
<Hobbsee> sorry, guadalinux
<jono> oh, you been the GuadaLinex one
<jono> heh
<Hobbsee> (wrong derivative distro)
<Hobbsee> jono: how'd you go with the mentoring?  i never saw the results
<jono> I have been informed by more than a few people that I look "hawt" in it
<Hobbsee> haha
<Hobbsee> were they straight, though?
<jono> :P
<jono> Hobbsee: straight women
<Hobbsee> strange...
<jono> Hobbsee: thanks
<StevenK> Hmph! pbuilder, stop telling lies!
<Hobbsee> jono: anytime.
<StevenK> libwibble-dev *is* installable.
* persia recommends sbuild :)
<jono> right I am off
<jono> catch you later :)
<Hobbsee> heh, dont answer my question then.
<jono> Hobbsee: I am not at work, its Sunday
<jono> :)
<Hobbsee> oh, point.
<jono> later
* Hobbsee works weekends, so there's no true "weekend"
* jono wanders off
<Hobbsee> bye!
<jono> I work too many weekends, but not this one
* Hobbsee forgot about that...
<Hobbsee> heh
<StevenK> Ah! It is installable, it just doesn't meet the version requirements.
<pygi> mr_pouit, poke :)
<shawarma> Can any of you make any sense of this: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/30051 ?
<ubotu> Launchpad bug 30051 in linux-source-2.6.20 "Iptables or Kernel BUG" [Medium,Confirmed]  
<Fujitsu> shawarma: He seems to be disappearing some further hell things, but I can't make much sense of any of iti.
<shawarma> LOL
<shawarma> Fujitsu: I tried reading it some many times now, but I just can't make any sense of it.
<Fujitsu> Neither can I.
<fabbione> makes no sense at all and never seen that problem in my life
<fabbione> he is clearly mixing the concept of routing with the concept of firewall/nat
<fabbione> not a bug...
<fabbione> IME
<fabbione> and probably his rules are not injected in the proper order
<fabbione> so the packets don't hit the proper rule
<fabbione> and bang
* fabbione -> back to do nothing
<shawarma> fabbione: thanks for looking at it. 
<fabbione> shawarma: no problem... btw you need to visit the CPH office soon...
<fabbione> shawarma: now with swimming pool :)
<fabbione> small one.. but still good enough to lay inside and hold a laptop
<Hobbsee> fabbione! 
<shawarma> fabbione: Wicked!
* fabbione needs a floating mini table :)
* Hobbsee hates the thought of the laptop falling into the water, though.
<fabbione> shawarma: it's a 2.5m diameter circle, about 80cm deep
<fabbione> perfect for hacking with this weather
<fabbione> Hobbsee: yeah well.. you need a proper laptop ;)
<shawarma> fabbione: Man, I could really use a nice cool swimming pool right now.
<fabbione> anyway i am off.. back to the swimming pool
<fabbione> shawarma: why do you think i bought one and almost got divorced in less than 24 hours? :P
<fabbione> stop nerding
<fabbione> i am off
<fabbione> later
<shawarma> Right. Cheers.
<Hobbsee> fabbione: heh
* Hobbsee likes her laptop, tyvm.
<shawarma> Whenever the subject of questions during installation comes up, people (including myself) commonly refer to some Ubuntu policy about not asking a lot of questions during install. Is this the kind of policy that has never been written down, but we all sort of have a common understanding of or does it actually exist in writing somewhere?
<mr_pouit> pygi: pong
<pygi> mr_pouit, I'll fix it today
<mr_pouit> ok
<linnuxxy> where can I find a tutorial about creating a new gfxboot theme... i did googled but didn't found any!
<pygi> mr_pouit, I'll need to rebuild brasero because of that. Silly me =)
<mr_pouit> :>
<pygi> just you laugh :P
<mr_pouit> pygi: in libisofs, there's also an unneeded directory iirc
<pygi> mr_pouit, which one? :P
<mr_pouit> something like /usr/share/doc/libburn
<pygi> yea, yea, I'll fix =)
<mr_pouit> ;P
<pygi> I suck, I know :P
<mr_pouit> ^^'
<persia> shawarma: I've made a short summary at http://pastebin.ca/555714.  More vaguely, it was a design goal for Dapper, and is being maintained going forward.
<glisse_> hey mjg59 i found you :)
<shawarma> It still just refers to "the policy". What I'm actually interested in is a) the wording of said policy or b) an acknowledgmement that said policy has never actually been written down.
<glisse_> mjg59: i have uploaded a new r500 driver see the channel for url it works here on my mbp would like to know if it works for you too :)
<persia> shawarma: Sorry then.  I can't confirm b), and have not found an authoritative source for a).
<mjg59> glisse_: Sweet!
<shawarma> persia: Alright. Thanks for trying!
<persia> shawarma: I'm certain I saw discussion about it during the Dapper timeframe, but I can't find it now.  You might also try searching the ubuntu-devel archives during the late Breezy or early Dapper cycle.
<shawarma> persia: I thought it had been policy since the very beginning?
<persia> shawarma: Also, see Debian Policy 3.9.1, which is only a "should".
<Hobbsee> shawarma: have you asked colin about it?
<Hobbsee> shawarma: seeing as he's done a lot of work on the installer and such?
<persia> shawarma: It may have been general policy, but I don't think great effort was put into fixing it for everyone until Breezy/Dapper - before then was a lot of new upstream integration work, etc.  Then again, my memory could be faulty.
<shawarma> Hobbsee: No, I just assumed he'd be on weekend.
<Hobbsee> shawarma: true that - i meant on a weekday
<shawarma> Hobbsee: No, the question didn't pop into my head until late Friday night.
<Hobbsee> shawarma: just blame mneptok 
<Hobbsee> shawarma: and make mneptok find out for you.
* bhale blames Hobbsee 
* Hobbsee boots bhale into the middle of next week
* persia thinks a note about debconf priority being less than "medium" and a pointer to the policy belongs in https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<bhale> Hobbsee: *sad puppy face*
<Hobbsee> bhale: doesnt work.  you've got to be very good for those to work
<bhale> Hobbsee: I am!
<Hobbsee> heh
<Hobbsee> you'll have to try it in person, i guess
<geser> are the buildds on holidays?
<main2> https://bugs.launchpad.net/ubuntu/+bug/119696 :P
<ubotu> Launchpad bug 119696 in Ubuntu "System goes back into standby after it resumed" [Undecided,Unconfirmed]  
<pygi> sivang, you sleeping again? :)
<sivang> pygi: nope
<pygi> good, you're advancing :)
<EliasAmaral> Is there any way Ubuntu can have an open command like the one in Mac OS X? (It's described here: http://www.ss64.com/osx/open.html )
<EliasAmaral> basically, open would open any file "just as if you had double-clicked the file's icon."
<EliasAmaral> it could be integrated with gnome's "open with.." in ubuntu or kde's similar system in kubuntu. or, ubuntu could have a single open system, like mac os x..
<ion_> xdg-open
<EliasAmaral> !!
<EliasAmaral> ... why isn't this installed by default? :~
<josephus> I'm trying to generate the Packages file for a modified ubuntu-installer cd using dpkg-scanpackages with override.feisty.main but the Packages file will miss the Task fields and the installation will fail
<josephus> Is there any other way to do that?
<josephus> found it
<Keybuk> EliasAmaral: it, err, is?
<EliasAmaral> Keybuk, not in my feisty
<EliasAmaral> $ xdg-open
<EliasAmaral> The program 'xdg-open' is currently not installed.  You can install it by typing:
<EliasAmaral> sudo apt-get install xdg-utils
<Keybuk> it's a dep of evince, no?
<Keybuk> ahh, maybe it's gutsy it's installed by default
<EliasAmaral> $ apt-cache showpkg evince|grep xdg-open
<EliasAmaral> nothing
<EliasAmaral> Keybuk, hmmm, that's nice :)
<EliasAmaral> (well, the command would be $ apt-cache showpkg evince|grep xdg-info, but this returns nothing too)
<Keybuk> I just looked at the germinate rdepends output
<EliasAmaral> germinate?
<Keybuk> what we use to decide what's in main, universe, on the CD, etc.
<pochu> Removing xdg-open in Gutsy needs to remove xdg-utils too.
<pochu> But it's not a depend of any ubuntu meta package.
<Keybuk> not directly
<johanbr> ubuntu-desktop depends on evince which depends on libdjvulibre15 which depends on xdg-utils.
<Keybuk> it's useful enough though, and already an indirect depend
<Keybuk> I've made it a recommends anyway
<EliasAmaral> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2007-June/030835.html this has any relevance to ubuntu?
<Keybuk> no idea
<Keybuk> Linux uses ALSA
<main2> damn, feisty must have some nasty problems under the hood :X
<main2> when logging out, on a lot of systems -> the screen goes 'black'
<main2> weird problem on my system is that after the feisty installation, on the first boot
<main2> fsck always runs, and fails right away (cant see what errors etc > its going way to quick)
<main2> dnno... the UNiversal E-IDE Driver is used on my system (it gets a SDA node .......)
<main2> looks like the mount-point isnt released?
<main2> are there any reports of this?
<theCore> main2: you shouldn't ask here, btw. Read the /topic
<main2> theCore, sorry mate, but in #ubuntu i only hear
<main2> "i have these problems toooo"
<main2> and because there more then a handful of devs around here, i was like > maybe we can discuss these points
<main2> ..pro active attitude..
<main2> I also have the idea that there is an endless list problems going on with those proprietary video-card drivers, maybe i should open some threads on the ubuntu forums
<main2> already opened some reports on launchpad fyi
<hunger> Is X.org currently borked in gutsy?
<hunger> I got a really simple demo that just displays a table in a window and inserts rows into that... and all of a sudden this demo causes the X server to eat 100% CPU and it is *SLOW*.
<Arby> hunger: my kubuntu gutsy was fine earlier
<hunger> Arby: Hmmm... I'll try to investigate.
<Arby> I'd be happy to try your demo if you can put it somewhere i can get it.
<hunger> Arby: Sorry, that is not possible. It uses a proprietary lib.
<Arby> oh well, nevermind
<theCore> main2: what is the bug report number?
<main2> theCore, to what relation?
<main2> i summed up a few things..
<theCore> <main2> already opened some reports on launchpad fyi
<main2> > well, one of them is > https://bugs.launchpad.net/ubuntu/+bug/119696
<ubotu> Launchpad bug 119696 in Ubuntu "System goes back into standby after it resumed" [Undecided,Unconfirmed]  
<main2> but thats low priority..
<main2> let me get you another one..
<theCore> main2: no, I would like to get the one about fsck
<main2> o, i didnt create one for that issue yet -> because it went soooooo fast
<main2> i mean, i cant perform a reinstall to see one message over again..........
<main2> i had to reinstall feisty a few times on my system this week (went from 32bit to 64 -> back to 32)
<main2> and thats what i noticed > after rebooting properly (when the setup was fully done)
<main2> 3 times, a failed fsck ....... > the big red (blinking?) letters in my screen wake me up.. if you know what im saying
<main2> (im using original canonical cd's, on a system with good memory > tested with memtest86)
<main2> it reboots after the fsck fails, thats what makes it so hard for me to get the message..
<Arby> main2: fsck writes logs to /var/log/fsck/checkfs
<Arby> might be worth a look if you can get to it
<main2> nothing special in there?, well.. http://www.pastebin.ca/556850  
<main2> i think i do remember something about those messages:
<main2> it had to do with a 'date in future' 
<Arby> looking
<main2> (dnno on what level.. i guess file level, sinds blocks dont have a date? > or maybe a journal date)
<main2> if you see some text in a flickering....
<main2> Sun Jun 10 20:59:36 2007
<main2> on itself is a future date for me
<main2> its 19:54pm here, im dutch
<main2> and the date of my machine hasnt changed the last few days (definitly not)
<main2> its definitly some weird thing going on, which i would know more about WHAT exactly is going on
<calc> cjwatson: good evening
<simo1> hello!
<LaserJock> afternoon everybody
<pygi> or night LaserJock :)
#ubuntu-devel 2008-06-02
<emgent> morning
<TheMuso> /c/c
<emgent> heya TheMuso :)
<TheMuso> Hey mgolisch.
<TheMuso> gah typing
<TheMuso> hey emgent
<emgent> :)
<lifeless> codehosting is down to fix a regression cuased by the rollout
<Hobbsee_> afternoon all
<emgent> morning Hobbsee_ :)
<ion_> Good night
<emgent> lol
<ion_> Itâs 7:10 here, a good time to go to sleep.
<emgent> am ?
<ion_> I rather avoid the AM/PM notation. I have nothing against using a 12-hour clock, but having the time of each half go from 12 to 1 to 11 is just too bereft of logic. :-)
<ion_> So yes, 7, not 19. :-)
<emgent> yeah, i think so. good night ion_ :)
<ion_> :-)
<emgent> here 6.14 am
<lifeless> ion_: to disambiguate, use a leading 0
<poptones> hello. does anyone know where i would submit code for newspost? the newspost webpage hasnt updated since 2003
<poptones> ooook so much for that
<pitti> Good morning
<geser> pitti: Guten Morgen
<pitti> elmo: it's off by default in hardy-updates; if you manually turned it on in /etc/default/apport, you can disable it there again
<pitti> ion_: "prove pitti right" -> I made some joke about "go, keybuk, go! push it to -ubuntu20" :)
<geser> pitti: can you give the MIR for libpar-dist-perl a quick look if something is missing? bug #236298
<geser> https://bugs.edge.launchpad.net/ubuntu/+source/libpar-dist-perl/+bug/236298
<pitti> calc: ok, thanks; I was just wondering why both tasks are open; if you are working on the bug, all is fine
<Hobbsee_> pitti1
<pitti> bryce, cjwatson: I agree; it's generally better to have public bugs for SRUs; a second public one WFM if the primary bug has a good justification for being private
<pitti> arthur-: thanks; did you see the mail I wrote to the Debian BTS?
<dholbach> good morning
<pwnguin> A question about merges: the wiki on merges says to file a bug and assign it to yourself -- is it not okay to file a bug requesting a merge but not work on it?
<pitti> pwnguin: no, that's not ok
<pitti> pwnguin: there's not reason to file bugs for "plzmergekthxbye"
<pitti> pwnguin: since we already have MoM to remind us about it
<pwnguin> how does MoM get updated?
<pitti> s/not/no/
<emgent> morning people :)
<pitti> pwnguin: it automatically updates daily (or even more often, not sure)
<pitti> hey emgent
<pitti> hey dholbach
<dholbach> hi pitti
<pwnguin> pitti: well hrm. i dont see wacom-tools on it =(
<pitti> pwnguin: that's because Ubuntu's version is newer
<pitti> 1:0.7.9.8-0ubuntu3 >> 0.8.0
<pwnguin> huh
<pitti> no idea why we have an epoch, thouch
<pitti> though
<pwnguin> thats no good
<pitti> so right, in this case a merge bug would make sense
<pitti> wacom-tools (1:0.7.9.3-2ubuntu1) hardy; urgency=low
<pitti>    - Bump the epoch because of old Ubuntu packaging.
<pitti>  -- Timo Aaltonen <tepsipakki@ubuntu.com>  Sun, 30 Dec 2007 18:59:29 +0200
<pitti> tjaalton: ^ why did you do this? that'll stick forever, and we'll never have the chance to properly merge/sync with Debian?
<pwnguin> that second part doesnt really sound like a question ;)
<wgrant> pitti: It's been there since Dapper...
<wgrant>   * Bump epoch to make xserver-xorg-driver-wacom newer than the one in breezy.
<pitti> ah, then that bit got dropped from teh changelog; sorry, tjaalton
<pitti> wgrant: ah, ok; bah, there are less sticky ways to do that...
<wgrant> pitti: It does say 'Remaining changes
<pitti> right
<pwnguin> i wonder what can be done about that
<wgrant> Nothing.
<pitti> the only way would be to beg Debian to bump it
<pitti> but they most likely won't
<pitti> so we're stuck with it
<persia> Upstream could change the versioning scheme
<wgrant> I had a nice DD that bumped an epoch for us because we had another use for the name first.
<geser> Guten Morgen dholbach
<pitti> wgrant: right, but TBH, if I were only a DD, I wouldn't bump the epoch "just because"
<pwnguin> Ron's usually pretty cool
<pwnguin> im not sure if he'd do something quite that silly
<Chipzz> given the "destructive" nature of epoch's, I'ld say packages that gain an epoch would be ideal candidates for the NEW queue (or similar)
<pwnguin> what about renaming the package?
<pitti> pwnguin: that only makes it worse
<dholbach> hi geser
<pitti> Chipzz: yeah, indeed
<pwnguin> pitti: how so?
<Chipzz> pwnguin: can't sync from debian then
<pitti> pwnguin: then merging becomes even more difficult, and you have to additionally keep transitional packages for a while
<Chipzz> pitti: and by gain I mean gain or increase an existing epoch
<pwnguin> given that the software is "linux wacom" upstream and "wacom-tools" in debian/ubuntu
<Chipzz> s/gain or/acquire or/
<wgrant> Chipzz: I've always thought that would be a very good idea.
<pwnguin> there MIGHT be a chance at that
<pwnguin> clearly ubuntu wacom is in a bad spot at this point, just trying to brainstorm anything that might be better than the status quo
<dholbach> pitti: is subscribing fixed you in the newest bzr revision of py-lp-bugs?
<pitti> dholbach: in bzr main head, yes
<pwnguin> is MoM amenable to some sort of special casing wacom-tools?
<dholbach> pitti: I still get http://paste.ubuntu.com/16348
<dholbach> pitti: nevermind
<dholbach> pitti: it uses the system pylpbugs
<pitti> yes, it's not yet fixed in any ubuntu release
<pwnguin> i love it when people close bugs because i accidentally use the wrong terminology
<wgrant>   status invalid
<pwnguin> fortunately they went and did it three days later
<tjaalton> pitti: yes, I've asked the debian developer to bump it but got no response
<tjaalton> it's not maintained by the XSF
<pitti> tjaalton: right; I wouldn't put a lot of hope into Debian bumping the epoch; thanks for asking, though!
<pwnguin> tjaalton: well, in the mean time, is there something we can do to make wacom-tools updates more visible to Ubuntu developers?
<pwnguin> i have an RSS feed of versions moving around in debian
<wgrant> Maybe MoM could automagically drop epochs if they're higher in Ubuntu?
<wgrant> Or maybe not automagically.
<pwnguin> how many broken epochs does ubuntu have?
<StevenK> wgrant: That strikes me as prone to breakage
<tjaalton> pwnguin: we use this http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<pwnguin> okie
<wgrant> StevenK: More breakage than having a differing epoch in the first place?
<StevenK> wgrant: It isn't breakage, it's just ... different
<tjaalton> pwnguin: there were quite a few in the X packages, but most of them are now in debian too. most of the unsyncable packages are x11proto's which have a different tarball (and no hope of a new release :)
<tjaalton> (anytime soon)
<StevenK> \o/
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> itti, it is about the blueprint of the PDF printing workflow
<tkamppeter> pitti, you tell I did not mention what needs to be changed in CUPS.
<tkamppeter> pitti, In the second paragraph of the "Implementation"  part I told that nothing needs to be changed in the CUPS daemon itself, only filters need to be added.
<pitti> tkamppeter: right, I meant the filters
<pitti> they are shipped in the cups package
<tkamppeter> pitti, the extra filters can be shipped in the CUPS backage but they do not need to be shipped there necessarily.
<pitti> tkamppeter: right, but that doesn't matter much
<pitti> tkamppeter: so which filters do we still need? pstopdf?
<tkamppeter> pitti, probably as long as they are not official upstream part of the CUPS package, they will come in an extra package.
<pitti> tkamppeter: didn't Mike intend to switch to PDF internally for 1.4?
<tkamppeter> The filters are the following, AFAIK: pdftopdf, imagetopdf, texttopdf, pdftoraster, pstopdf, pdftoijs, pdftoopvp
<tkamppeter> I do not know whether Mike has this intention, this would be great. If he does it, he will grab the filters from OpenPrinting at SourceForge.jp, as these filters are not yet in the 1.4 SVN.
<tkamppeter> pitti, I have updated the spec now.
<pitti> tkamppeter: danke
<pitti> seb128: would you have some time to verify bug 152246? it's my upload, so I can't officially verify
<ubottu> Launchpad bug 152246 in gthumb "gThumb change date to exif date" [Undecided,Fix committed] https://launchpad.net/bugs/152246
<seb128> pitti: sure
<pitti> seb128: urgh, that bug isn't SRUish at all; fixing
<pitti> seb128: bug is ok now
<seb128> pitti: ok, going to try that in a few minutes
<seb128> pitti: I just have to upgrade before ;-)
<pitti> seb128: thanks
<Hewus> Does anyone know why myspell-en-au is in universe, while the other three myspell-en-* are in main?
<cjwatson> Hewus: language-support-writing-en depends on the others, but not myspell-en-au
<cjwatson> it's probably a bug
<Hewus> cjwatson: thank you, I'll try and take care of it
<tkamppeter> I am trying to get a consistent Intrepid installation onto a 32-bit PC and have a problem:
<tkamppeter> I cannot install KDE apps because of
<tkamppeter> The following packages have unmet dependencies:
<tkamppeter>   kdebase-kio-plugins: Depends: kdelibs4c2a (>= 4:3.5.8-1) but it is not going to be installed
<tkamppeter>                        Depends: kdesktop but it is not going to be installed
<tkamppeter> but I have kdelibs4c2a 4:3.5.9.dfsg.1 on this box, so the dependency should be fulfilled.
<cjwatson> tkamppeter: while apt's output is often suboptimal when this sort of thing happens, http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html indicates that kdebase-kio-plugins is entirely uninstallable in intrepid
<cjwatson> so you probably won't be able to get far until that's sorted out
<tkamppeter> cjwatson, thank you. I will keep Hardy on at least one box for now so that I can use digikam there.
<liw> it's pretty early in the cycle to start running the development version, isn't it?
<pitti> liw: why?
<pitti> without people running it we'll never know what stuff to fix
<RAOF> Probably because stuff like this happens all the time? :)
<liw> pitti, yeah, but things break so much that one runs the risk of not getting anything else done than bug reporting :)
<pitti> tkamppeter: what was the problem: I got disconnected, so I just got your "I have a problem" and then liw's comment
<cjwatson> pitti: uninstallable kdebase-kio-plugins
<pitti> hm, traditionally I upgraded to the dev release on the day we opened it
<pitti> I don't report all those bugs yet, since they usually shake out themselves without bug spam
<cjwatson> Keybuk: valgrind: I think you're right, looks like one of Kees' changes was responsible
<pitti> RAOF: uninstallable packages usually don't break your box; the upgrade should just hold them back
<cjwatson> I'll talk with him about it later
<RAOF> pitti: Yeah.  FWIW, *I'm* running intrepid.
<norsetto> pitti: I think we should proceed with bug 199190
<ubottu> Launchpad bug 199190 in libitpp "libittp fortran transition" [Undecided,Fix committed] https://launchpad.net/bugs/199190
<pitti> norsetto: ah, did anyone test it?
<norsetto> pitti: no, it runs a self test at the end
<pitti> that doesn't check if the package actually installs and works
<norsetto> pitti: installs it installs, wether it works or not, nobody has any idea. The package as is now doesn't install
<Riddell> tkamppeter: KDE is stuck half way between KDE 3 and 4 and will not be installable until the rest of the main inclusion reports get reviewed
<pitti> norsetto: if installation works, I'm good with it
<cjwatson> pitti: bug 221664 looks nasty
<ubottu> Launchpad bug 221664 in lilo "lilo loads wrong data for big initramfs (?)" [Undecided,New] https://launchpad.net/bugs/221664
<pitti> cjwatson: eww, indeed; the documentation of "large-memory" seems to indicate that this would break on 'older' systems, but not how old 'old' is here
<pitti> nothing that immediately jumps out on google
<tkamppeter> pitti, it was about trying to install a KDE app in Intrepid. KDE is a komplete mess currently, we need for the KDE 4 introduction to complete.
<pitti> tkamppeter: right; see Riddell's explanation above
<davmor2> sbeattie: Ping
<norsetto> pitti: dankeschoen!
<pitti> norsetto: what for? :-) I didn't do anything yet
 * norsetto hugs pitti 
 * pitti hugs norsetto back
<RicardoPerez> hi all
<pitti> hi RicardoPerez
<RicardoPerez> pitti: hi! one question...
<RicardoPerez> pitti: in which packages are the firefox translations in hardy-proposed?
<pitti> RicardoPerez: language-pack-XX-base
<pitti> RicardoPerez: I answered your mail, too
<RicardoPerez> pitti: yes, I saw it. I updated firefox, xulrunner & all the langpacks, but firefox is still in English... :(
<pitti> Riddell: dpkg -l language-pack-es-base|grep es-base
<RicardoPerez> pitti: there are directories inside language-pack-es-base, called /usr/lib/firefox-addons/extensions/langpack-es-ES@firefox-3.0.ubuntu.com and /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com, but they're empty...
<pitti> asac: ^ any idea?
 * pitti takes a look at the source package
<asac> hmm
<asac> i tested es.tar.gz at least
<RicardoPerez> pitti: correction: they contains a directory called chrome, which is empty, too
<pitti> hm, the mozilla.tar.gz looks fine here
<asac> source package is fine here too
 * asac installs langpacks
 * pitti downloads .deb
<RicardoPerez> pitti: ....langpack-en-GB@xulrunner-1.9.ubuntu.com/chrome CONTAINS a file called en-GB.jar
<asac> looks good here:
<asac> http://paste.ubuntu.com/16368/
<pitti> -rw-r--r-- root/root    157031 2008-05-29 10:52 ./usr/lib/xulrunner-addons/extensions/langpack-es-AR@xulrunner-1.9.ubuntu.com/chrome/es-AR.jar
<pitti> -rw-r--r-- root/root     57414 2008-05-29 10:49 ./usr/lib/firefox-addons/extensions/langpack-es-AR@firefox-3.0.ubuntu.com/chrome/es-AR.jar
<pitti> .deb looks fine here
<RicardoPerez> mmmmm.... I don't have too many files...
<pitti> asac: same here
<pitti> maybe something went wrong with the Replaces:
<RicardoPerez> http://paste.ubuntu.com/16369/
<RicardoPerez> ricardo@kadath:~$ dpkg -l language-pack-es-base | grep ^ii
<RicardoPerez> ii  language-pack-es-base                      1:8.04+20080527                                    translations for language Spanish; Castilian
<asac> RicardoPerez: try dpkg -S usr/lib/xulrunner-addons
<asac> err
<asac> :)
<pitti> RicardoPerez: I guess if you sudo apt-get install --reinstall language-pack-es-base, it'll work
<asac> pitti: how to figure what happened?
<RicardoPerez> pitti: mmmmmm.... strange.... the .deb file contains more files than I have installed... I'll try --reinstalling it
<RicardoPerez> sudo apt-get --reinstall install language-pack-es-base
<asac> RicardoPerez: can you keep the current state for a second?
<RicardoPerez> asac: sure, I wait
<asac> RicardoPerez: dpkg -S langpack-es-ES@xulrunner-1.9.ubuntu.com
<asac> ?
<asac> what does that give you?
<RicardoPerez> ricardo@kadath:~$ dpkg -S langpack-es-ES@xulrunner-1.9.ubuntu.com
<RicardoPerez> language-pack-es-base: /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com
<RicardoPerez> language-pack-es-base: /usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com/chrome
<RicardoPerez> ricardo@kadath:~$
<pitti> that looks correct
<asac> pitti: where is the replaces state tracked?
<asac> e.g. in /var/ ... ?
<RicardoPerez> the es-AR.jar & es-ES.jar files are missing
<pitti> I think what happened is that the upgrade order was done in a way that the Replaces: wasn't done properly
<pitti> asac: should be /var/lib/dpkg/info/<package>.list
<RicardoPerez> ... are missing in the installed, but not in the .deb...
<asac> RicardoPerez: grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*
<asac> err,
<asac> RicardoPerez: grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*.list
<RicardoPerez> ricardo@kadath:~$ grep langpack-es-ES@xulrunner-1.9.ubuntu.com /var/lib/dpkg/info/*.list
<RicardoPerez> /var/lib/dpkg/info/language-pack-es-base.list:/usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com
<RicardoPerez> /var/lib/dpkg/info/language-pack-es-base.list:/usr/lib/xulrunner-addons/extensions/langpack-es-ES@xulrunner-1.9.ubuntu.com/chrome
<RicardoPerez> ricardo@kadath:~$
<asac> RicardoPerez: did you ever had the language-pack-gnome-es-base installed?
<pitti> asac: -es was one of the packages where the gnome update packages had a newer version than -base, right?
<RicardoPerez> ricardo@kadath:~$ dpkg -s language-pack-gnome-es-base | grep Status
<RicardoPerez> Status: install ok installed
<RicardoPerez> ricardo@kadath:~$
<pitti> asac: that just affected three languages AFAIK (es, pt, and zh?)
<pitti> asac: so for those we have three different versions of translations
<asac> pitti: we have, but the packages are similar to the other packages
<asac> it was basically just a manual update that shipped a better chrome.manifest
<asac> dont see why it would make any difference over lets say -de
<asac> pitti: ah ... you mean because those were in language-pack-gnome-es
<asac> yeah. maybe dpkg has problems to deal with three replaces ;)
<pitti> right
<pitti> I didn't get reports for other languages about this kind of problem
<asac> yes, but -es is a popular language ... so maybe a quick catch
<pitti> asac: so maybe; (1) update language-pack-es-base (files), then (2) update language-pack-gnome-es{,-base}
<pitti> lp-es-base replaced lp-gnome-es-base, and that conflicted with lp-gnome-es (still in the old version)
<asac> yeah
<asac> so we have to put them into language-pack-es as a first measure? or are we brave enough to fix conflicts/replaces?
<asac> pitti: ? i could upload language-pack-es -zh -pt if thats what you like
<RicardoPerez> I can downgrade my langpacks and wait for new langpacks updates uploaded into hardy-proposed, if you want...
<pitti> asac: no idea how to solve it, I'm afraid, as long as we don't understand what's happening in the guts of dpkg
<asac> might mvo help?
<pitti> asac: we might need to add a Conflicts: to force upgrade ordering
<pitti> i. e. ensure that we don't install the new language-pack-es-base before upgrading language-pack-gnome-es{,-base}
<pitti> RicardoPerez: can you purge langpacks, install the ones from hardy, and then manually upgrade first -gnome-* and then language-pack-es{,-base}? that should work
<RicardoPerez> pitti: ok, i'll do that in a moment
<pitti> RicardoPerez: gracias
<RicardoPerez> pitti: works!
<pitti> RicardoPerez: great
<Hobbsee> cjwatson: when is supposed to be the accepted time that ppas will be able to build for intrepid?
<cjwatson> Hobbsee: I didn't know it was delayed
<pitti> RicardoPerez: just for confirmation, if you do the same, but first upgrade language-pack-es{,-base} and then *gnome*, it fails?
<cjwatson> should at most be a matter of chroots being set up? (i.e. -> infinity)
<Hobbsee> cjwatson: apparently it's delayed, because it's waiting on word from the distro team.
<Hobbsee> infinity: poke
<cjwatson> gar
<RicardoPerez> pitti: I'll do that in a moment, again :)
<cjwatson> ok, I'll go talk with them
<Hobbsee> cjwatson: cool, thanks
<pitti> RicardoPerez: thanks a lot; if that is the reason, we can add a Conflicts:
<RicardoPerez> pitti: as you say, if I do the upgrade in the reverse order, it don't work :)
<pitti> superm1, tseliot: I just tried to DKMSify http://linuxtv.org/hg/v4l-dvb (I want to provide a driver backport for hardy), but I have some trouble with upstream's Makefile; it doesn't build any modules when being called from /lib/modules/2.6.24-17-generic/build; do you have some experience with that and could help me?
<pitti> RicardoPerez: awesome; thanks a lot for testing!
<RicardoPerez> pitti: thanks to you :)
<pitti> asac: ok, so AFAICS we should add "Conflicts: language-pack-gnome-es (<< 8.04+20080527), language-pack-gnome-es-base (<< 8.04+20080527)" to language-pack-es-base? likewise for pt and zh?
<cjwatson> Keybuk: around? I think enabling PPAs for Intrepid requires a techboard member
<Keybuk> cjwatson: err, why?
<tseliot> ï»¿pitti: I have no experience with that driver however if you upload your code somewhere I think I can give you hand with DKMS
<Keybuk> is there a button that needs to be pushed?
<cjwatson> Keybuk: apparently it requires turning on 'support-virtualization' in each distroarchrelease
<Keybuk> ?
<RicardoPerez> now I must leave. see you!
<cjwatson> https://launchpad.net/ubuntu/intrepid/amd64/+admin, https://launchpad.net/ubuntu/intrepid/i386/+admin, https://launchpad.net/ubuntu/intrepid/lpia/+admin
<pitti> tseliot: that's the (essential part of) the Makefile: http://paste.ubuntu.com/16376/
<Keybuk> ENOPERM
<cjwatson> Keybuk: seriously? argh
<Keybuk> duckie required, I suspect
<Keybuk> or maybe infinity
<Keybuk> or my tech board membership expired already
<cjwatson> your techboard membership is still active
<cjwatson> though five days - shouldn't that be extended?
<Keybuk> dunno, ask sabdfl ;)
<pitti> tseliot: running "make" in /var/lib/dkms/v4l-dvb/0.20080328/build/ works, but running make KERNELRELEASE=2.6.24-17-generic -C /lib/modules/2.6.24-17-generic/build M=/var/lib/dkms/v4l-dvb/0.20080328/build (as dkms does) doesn't
<pitti> tseliot: dkms passes M=/var/lib/dkms/v4l-dvb/0.20080328/build to make
<asac> pitti: yes that makes sense
<asac> pitti: actually, shouldn't the language pack conflict all other lang packs with lower version anyway?
<pitti> tseliot: apparently the kernel upstream Makefile is supposed to handle M=, but that seems to need some support in the target Makefile, too
<pitti> asac: AFAIR we used Replaces: instead of a million Conflicts: to avoid confusing apt-get
<pitti> asac: and I have never seen it fail for the 'usual' case (just two versions)
<pitti> asac: this is a special kind of a three-way replaces:, which apparenlty has issues
<asac> pitti: yes, i think its a rare thing that translations migrate from gnome to normal and vv.
<tseliot> ï»¿pitti: what does your dkms.conf look like?
<pitti> asac: so, it's certainly worth testing to generally replace some Replaces: with Conflicts:, but we shouldn't overdo it
<asac> yep. lets please keep the solution as simple as possible for hardy
<asac> and review the conflicts/replaces in intrepid ;)
<asac> pitti: btw, could langpack-o-matic pass the lsb release version the package is targetted for?
<pitti> tseliot: http://paste.ubuntu.com/16378/ (just the first 5; there are 209 modules built from that)
<asac> i need to maintain different blacklists for different releases for instance
<pitti> asac: you mean the target? like gutsy-proposed, intrepid, etc? yes, that's no problem
<asac> yes
<asac> for me the lsb version would be better though ;)
<asac> but well.
<pitti> asac: like 8.04?
<asac> yes
<pitti> asac: no problem, you can have that as well
<asac> thats what i current use locally. but i can adapt my transformer if its easier for you
<pitti> I have a code name -> version mapping anyway
<asac> ah good
<pitti> asac: however, that will loose the distinction between release and -proposed; do you need that?
<asac> maybe <lsb_version> <purpose> => 8.04 updates (if things go to proposed)
<asac> but yeah. at best just pass the whole target ... ill take care of the rest
<pitti> asac: I don't have a meaningful lsb_release there, just 'hardy-proposed' and a mapping to '8.04'
<asac> ok ... Ill let you know when i have setup the code to deal with that. but after this update ;)
<pitti> asac: I think manually adding the three conflicts: is minimally invasive and the easiest solution I can think of; WDYT?
<tseliot> pitti did you add a line like the following to your dkms.conf? MAKE[0]="make module KERNDIR=/lib/modules/$kernelver SYSSRC=$kernel_source_dir"
<pitti> asac: I'll do that in langpack-o-matic, I have everything there already
<asac> i think they should be fine.
<pitti> tseliot: no, I didn't; I need to?
<asac> we should test the upgrade path for those three afterwards.
<pitti> yes, absolutely
<asac> let me know when they are in so i can test all combinations in a chroot
<asac> well ... all combinations i have in mind ;)
<tseliot> ï»¿pitti: yes, you should, so that DKMS can build the module
<pitti> tseliot: and that won't run make 209 times?
<pitti> tseliot: it just needs to run 'make' in the target dir, that's all
<pitti> s/target/dkms source directory/
<tseliot> ï»¿pitti: why should it run make 209??? DKMS is a sensible system
<asac> pitti: will you reupload all? if so we have to take care the the right fi.tar.gz is used ;)
<tseliot> pitti: yes, I picked that up
<asac> rookery should be fixed in case you want to recreate them for real
<pitti> asac: no, I was just going to upload -zh, -es, and -pt
<asac> ok good
<pitti> asac: I already put your -fi to rookery
<asac> pitti: what do you mean by "put my -fi" ? do you preserve the tar.gz ?
<pitti> asac: yes, I unpacked your sources to rookery
<asac> ah ok. didn't know that you use some kind of source caching. grewat
<pitti> it shouldn't actually matter, but just to be on the safe side
<asac> yep
<tseliot> ï»¿pitti: let me know how it goes ;)
<pitti> tseliot: I will, thanks for the hint! just fixing the langpack mess first
<doko> pitti: is it possible to a) add a new binary package to hardy-proposed, b) add a new source package?
<cjwatson> it is technically possible and sometimes also allowed by policy ;-)
<pitti> doko: technically yes, practically we did that only once or so
<pitti> it needs a really really good justification anyway
<doko> pitti: noticed that libmudflap0-4.1-dev is not built anymore, so -fmduflap doesn't work with gcc-4.1
<pitti> doko: do we care enough about 4.1 to fix that in hardy?
<doko> pitti: the other package would be ca-certificates-java (ca-certificates built for java); cannot be built from ca-certificates, because this is in main, and requires at least openjdk as a b-d
<doko> pitti: well, I don't care that much about 4.1
<pitti> java can't use /etc/ssl/certs/*?
<doko> no, has it's own format
<pitti> yay
<mgolisch> lib/security/cacerts or so is the file in the java installation directory
<pitti> mgolisch: well, a mere path could be worked around with a symlink
<pitti> but if it actually uses its own encoding of SSL certificates, that's more tricky
<mgolisch> yeah the certs are saved in a so called keystore file
<pitti> . o O { just gotta love the Sun guys for not using already existing platfom independent standard formats ... }
<pitti> mgolisch: do you know if it is possible to generate them on the client side?
<pitti> mgolisch: then we could just add that call to ca-certificate's postinst
<pitti> since ca-certificates itself can change, and the user can reconfigure which certificates he wants, that would then automatically apply to Java as well
<cody-somerville> woot woot
<cody-somerville> I isolated the Xubuntu black screen of death bug :]
<asac> pitti: do you have powers to proactively prevent xulrunner source package from being synched?
<pitti> asac: yes
<pitti> asac: we can add it to the sync blacklist
<asac> the new package is still in experimental, but once it reaches unstable the xulrunner source will ship the same package names we have in xulrunner-1.9
<asac> (+ some more)
<asac> not sure what would happen :/
<pitti> asac: but as long as our's has 'ubuntu' in the version, it won't get autosynced
<pitti> asac: and in principle, if Debian adopts our changes, we could sync; or is there a general reason why we will never ever do that?
<asac> pitti: well. they still have a package split we dont want
<asac> they ship a -common package and a libmozjs for which mike added so-versioning
<asac> (not sure why he kept that as afaik there is no standalone rdepends on libmozjs)
<asac> pitti: and the bad is that debian doesnt use a patch-system ... so no sync possible
<pitti> eww
<asac> yeah ... glandium rolled-back his opinion that it is sane to have a patch-system for mozillas
<asac> not sure why
<asac> now he has a private git archive
<doko> pitti: it doesn't help, I can't assume that openjdk is installed when ca-certificates is installed
<pitti> doko: sure, but you can test whether the conversion binary exists
<pitti> [ -x /usr/sbin/update-java-ssl ] && /usr/sbin/update-java-ssl || true
<pitti> something in that spirit
<pitti> doko: of course that only works if the client side actually has the means to update them
<pitti> if that needs a ton of programs that users don't usually have, that'd be bad
<pitti> (like the issue with tzdata)
<doko> pitti: sorry, this is insane. you can't assure that this exists. the alternative is to add this to openjdk, sun-java5, sun-java6, and generating duplicate copies. which is more insane
<doko> it won't be a problem if openjdk is in main
<pitti> doko: that was my question; I didn't know whether openjdk ships the tool to modify that keyring
<pitti> doko: it's not a question of "you can't assure"
<doko> ahh, yes. openjdk ships it
<pitti> it's a question of "does openjdk ship the tool or not"
<pitti> I'm just concerned that it needs the same debconfiscation as ca-certificates itself, and the user needs to configure it twice
<pitti> well, it could use ca-certificate's debconf values, I guess
<pitti> asac: all fixed, uploaded, tripe-checked, accepted
<Keybuk> mmm, tripe
<siretart> asac: do you happen to have an sunbird 0.8 backport for hardy in some ppa?
<asac> siretart: ~mozillateam
<siretart> awesome! thanks!
<cjwatson> mvo: should bug 235454 be an upgrade-fix target for 8.04.1?
<ubottu> Launchpad bug 235454 in perl "perl 5.10 file conflict with libarchive-tar-perl" [Undecided,New] https://launchpad.net/bugs/235454
<cjwatson> oh, sorry, ignore me, that's an intrepid bug
<mvo> cjwatson: aha, ok - maybe a 8.10 upgrade-fix then :) (/me reads the bug)
<cjwatson> nah, never mind, it's being sorted in Debian by the looks of things
<cjwatson> I misread it as a hardy problem
 * mvo nods
<a7p> hi everyone - I've got a rather complex bugreport and I could use some help - it involves a java-applet, compiz and may be cups - it causes either a reboot or an X11-restart.
<Keybuk> what's the standard way out of a PulseAudio wedge?
<lool> killall pulseaudio and relaunch it
<lool> At least that's how I do it, but make sure nobody grabs the alsa device in between
<lool> I think you want --log-target=syslog if you want the new one to behave like the autostarted one
<Keybuk> killing pulse kills most of the apps with it
<lool> (Not for me)
<lool> It does have trouble with flash if playing, but if e.g. I'm paused on a flash page such as youtube, killing pa will allow the page to play afterwards
<munckfish> pitti: I've just found this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399. Are you working PS3/Cell stuff then?
<ubottu> Debian bug 483399 in initscripts "initscript: Support Cell processor spufs" [Wishlist,Open]
<persia> munckfish: Ideally, although there are lots of outstanding bugs.
<munckfish> persia: Ok ... I think I see what you mean - I'm working on the PS3 Port of Ubuntu so I'm aware of the issues, I'm trying to find out if Martin is too.
<munckfish> I have a feeling there maybe too camps of dev effort working in parallel not aware of each other
<persia> munckfish: Chase the ubuntu-ppc team as a point of coordination
<munckfish> persia: I just tried to join #ubuntu-ppc but it kicked me said invite only do you know anything about that?
<persia> munckfish: Nothing, I'm afraid.
<liw> might be related to all the changes to freenode servers this past week
<cjwatson> munckfish: I think pitti was just doing the initscripts merge
<munckfish> cjwatson: ok thx. I just noticed Arthur Loiret has been putting libspe2 packages into debian
<munckfish> Just want to make sure that I'm aware of what is happening and where in relation to PS3 stuff
<munckfish> and that these folks know our Port project exists too
<munckfish> Who is working on the powerpc port? Is there any particular person I should speak to?
<cjwatson> I don't know of anyone who might be a powerpc port leader
<cjwatson> I think "just do it" comes into play
<munckfish> ok I thought that maybe the case
<munckfish> I noticed there was no mailing list
<munckfish> I'm beginning to wonder if the cell mailing list we have is not as useful as maybe just sticking to ubuntu-devel in terms of visibility
<seb128> calc: hi, could you look at bug #234532 when you have some time? that seems to be an annoying issue for some openoffice hardy users in corporate environments
<ubottu> Launchpad bug 234532 in openoffice.org "gvfs-sftp: openoffice can't open or save files " [Undecided,New] https://launchpad.net/bugs/234532
<emgent> morning dendrobates- :)
<pitti> munckfish: actually no, I'm just the messenger; I just sent our patch to Debian
<pitti> munckfish: I was told that arthur- was working on Cell in Debian, I CC'ed him
<munckfish> pitti: hi, ok I see. So where/who did our patch come from?
<pitti> munckfish: doko, I think
<munckfish> Arthur is also working on toolchain stuff for us I believe?
<munckfish> Ok I see, thx for the info
<pitti> I honestly don't know
<munckfish> us = ubuntu in general
<munckfish> ok pitti thx I'll speak with them
<pitti> munckfish: I know that doko and cjwatson were involved with it, but I don't know any details
<cjwatson> the patch in question is in hardy
<cjwatson> and I think was in gutsy as well
<pitti> munckfish: I'm just reasonably sure that nobody in Ubuntu is working on it right now
<munckfish> pitti: well I'm trying to
<munckfish> with cjwatson's help
<munckfish> and others ofcourse
<persia> pitti: Are you sure about that?  I thought there were still a few people on the ubutu-ppc team, and there was certainly discussion from a few forums folk in the last forums meeting
<munckfish> so the powerpc team are sort like a vapour-team
<pitti> persia: right, sorry; I meant "in Canonical's Ubuntu team"
<munckfish> ?
<munckfish> :D
 * persia encourages collective coordination, regardless of sponsorship
<cjwatson> persia: I haven't seen much in the way of patches; though I could be missing something
<munckfish> cjwatson: you mean from folk seeming to care about the ppc port?
<persia> cjwatson: True.
<doko> arthur broke his shoulder at rugby, so he may not respond quickly ...
<cjwatson> munckfish: right, with the exception of yourself
<cjwatson> doko: there, clearly hackers should avoid all physical activity for safety reasons
<munckfish> doko: doh, nasty. Rugby is a dangerous game :D
<pitti> well, then he might have gotten a tennis arm from too many mouse clicks in WoW
 * doko hits cjwatson (and hopes he doesn't get injured himself) ;-p
<munckfish> yeah I think devs have got to stick with non-contact
 * cjwatson blocks
<ogra> doko, point him to the a11y team, injured people make awesome testers :)
<munckfish> :D
<pitti> doko: consider Colin's Karate belt first :)
<pitti> cjwatson: so, no sparring contest on the next allhands then?
<cjwatson> I'm a bit rusty ...
<cjwatson> I might be better off tying somebody up with the belt
<pitti> lol
<ogra> lol
<\sh> ogra, was missing you at LT ;)
<ogra> \sh, yeah, no trains that could get me there :(
<Mithrandir> cjwatson: kinky. ;-P
<\sh> ogra, I heard it...sad you really missed a good party
<ogra> yeah
<ogra> well, i did some work instead :)
<pitti> \sh: too bad I missed the BBQ
<mvo> ogra: oh? no trains?
<\sh> pitti, I missed you, too :)
<ogra> mvo, well, trains with unpredictable schedules .... they told me the next northbound train *could* go in 90mins but no guarantee it goes at all and no guarantee that i get any connection in hanover
<mvo> oh, because of the thunderstorms at the weekend?
<ogra> i gave up after these 90min being told the same
<\sh> pitti, but we really had luck yesterday on our way back...really..
<ogra> mvo, yeah, broken tracks etc
<munckfish> cjwatson: in response your last comments on on LP 221647
<ubottu> Launchpad bug 221647 in base-installer "Kernel installation not working on ps3" [High,Confirmed] https://launchpad.net/bugs/221647
<munckfish> I don't think we're aiming at 8.04.1 anymore
<cjwatson> munckfish: oh
<munckfish> I didn't feel Ben C wanted to consider PS3 patches in the hardy kernel
<munckfish> He suggested it would be tough getting them in
<munckfish> So refocusing on Intrepid
<cjwatson> what is its current state? completely broken or only slightly broken?
<munckfish> Hardy?
<cjwatson> I gather you got X fixed
<cjwatson> yes, hardy
<munckfish> Without Ben H's vmemmap fix it's crippled with on ~80MB of RAM
<ogra> no kernel sounds slightly serious
<cjwatson> ogra: it has a kernel, it's just not very good
<ogra> ah
<munckfish> His patch will be in Geoff's 2.6.25 patch set
 * ogra didnt read the bug, only judged by description
<munckfish> and I think Geoff said it would be back ported
<munckfish> cjwatson: is there any point in cont. effort for Hardy?
<munckfish> is that what you're thinking?
<cjwatson> it's up to you, I just thought since we were partly there it might be worth a few tiny tweaks
<munckfish> Well me too
<cjwatson> we're basically past the deadline so no more substantial changes
<cjwatson> I was just wondering whether I should push for the trivial backport of base-installer so that it at least installs the right kernel!
<munckfish> Yeah, well, even if we fix the kernel, I've no idea what the installer/upgrade situation would be
<cjwatson> bear in mind that upgrades from gutsy are going to have to go through hardy
<cjwatson> so that will need to at least minimally work, or else people will have to reinstall
<munckfish> yes of course your right :(
<cjwatson> I suppose I can always do the base-installer thing for 8.04.2
<munckfish> Well, we have a couple of major issues with X which are now fixed in Intrepid they would need to be SRU'd
<munckfish> Then we have 2 problems with the kernel - the 80MB RAM thing
<munckfish> and it not being able to power off
<munckfish> Power off I've not explored much yet
<munckfish> but I saw some one said it was affected by the video mode chosen
<munckfish> so it could also be RAM related
<munckfish> If there's a chance of getting the vmemmap patch accepted into the kernel then I agree we should try for 8.04.1 or 8.04.2
<cjwatson> http://people.debian.org/~cjwatson/tmp/ssh-client-blacklist.diff <- prevent ssh from sending blacklisted keys. Anyone have a good reason for hating that idea?
<munckfish> I really need to get an opportunity to chat with Ben C directly at some point
<munckfish> our communication has bee via sporadic email so far
<Mithrandir> cjwatson: might lose you access to a system if your only access is through a broken key.
<persia> cjwatson: The need to get to a remote server insecurely to update the keys because you've been alseep for a month?
<Mithrandir> cjwatson: make it overridable with --yes-I-know-this-is-insecure or something.
<cjwatson> Mithrandir: it is, -o UseBlacklistedKeys=yes
<cjwatson> the ssh-add bit isn't overridable, but I don't think that's so big a deal
<Mithrandir> then it sounds fine to me
<cjwatson> at the moment any key already in the agent is used anyway
<cjwatson> not sure whether to bother with changing that
<cjwatson> inclined not to as agents have a finite lifetime anyway
<pitti> tseliot: nice! a simple "MAKE[0]=make" did the trick
<tseliot> ï»¿pitti: easy ;)
<pitti> tseliot: so, the thing won't actually respect KERNELRELEASE=2.6.24-17-generic that way, but for a first test that's pretty good
<calc> seb128: ok will look, about to be in an ooo meeting
<seb128> calc: thanks
<tseliot> pitti: DEST_MODULE_LOCATION[0] should be enough. Furthermore you can build a module for a specific kernel with "dkms add -m name_of_the_module -v version_of_the_module -k name_of_the_kernel", ï»¿"dkms build -m name_of_the_module ï»¿-v version_of_the_module  -k name_of_the_kernel", ï»¿"dkms install -m name_of_the_module ï»¿-v version_of_the_module -k name_of_the_kernel"
<pitti> tseliot: right, that's what I used; I just wonder whether there is a command "rebuild/install all dkms modules which are not built/installed for the current kernel"?
<tseliot> pitti: if such modules are installed as dkms packages and they have AUTOINSTALL="yes" in the dkms.conf it will all be done automatically
<pitti> tseliot: i. e. if DEST_MODULE_LOCATION[4] is not specified, it will fallback to DEST_MODULE_LOCATION[0]?
<pitti> tseliot: aah
<nxvl> seb128: can you please take a look at #182690, i'm experiencing the problem since the last upload
<nxvl> seb128: i have added a screenshot of the error
<seb128> nxvl: no clue about this one, I don't work on f-spot and the bug shows that's not a new version regressions, you would have better chance to get an useful reply by contacting the people who work on this code using bugzilla.gnome.org
<tseliot> pitti: the man page says that the number, say, 4, "must be the same for each of BUILT_MODULE_NAME, BUILT_MODULE_LOCATION, DEST_MODULE_NAME and DEST_MODULE_LOCATION". I don't think there's a fallback system.
<pitti> tseliot: right, I did't see that either; but you said "DEST_MODULE_LOCATION[0] should be enough"
<pitti> tseliot: well, MAKE[0] has this kind of fallback
<tseliot> pitti: sorry, I should have omitted the number
<nxvl> seb128: mm i think i'm having a different problem, the error i'm getting is different, are you able to open the image i have pasted?
<seb128> nxvl: yes, that's a standard png, eog open it fine, why?
<nxvl> seb128: also, i was able to upload my photos until the last upload
<seb128> or my web browser rather
<tseliot> ï»¿pitti: but "MAKE" is not included in the line which I quoted ;)
<nxvl> seb128: because here i'm getting Bad Gateway error
<pitti> tseliot: right, I understand; I was just misled to think that a similar [0] default exists for the paths as well
<seb128> nxvl: this bug has been opened months ago
<seb128> nxvl: I doubt that's a new version regression
<tseliot> ï»¿pitti: mdomsch is the right person to ask about this. He taught me a few things on DKMS
<nxvl> seb128: yep, but the error i'm getting is a different one i think i just reported my comment here and not in a new one
<nxvl> seb128: because the problems are similar
<pitti> tseliot: right
<pitti> tseliot: just testing teh AUTOINSTALL now
<pitti> yay, it works \o/
<nxvl> seb128: and as i have seend on the f-spot changelog you changed something on the flickr net thing of f-spot
 * pitti hugs dkms
<seb128> nxvl: hum, you should really not abuse an old bug if you have a different error, that's confusing for everybody
<nxvl> seb128: and something about it is on the error
<tseliot> ï»¿pitti: it's a great feature :-)
<pitti> tseliot: ah, except that the build failed
<nxvl> seb128: mm, maybe you are right, i will open a new bug for this
<seb128> nxvl: thanks
<tseliot> ï»¿pitti: what's changed?
<seb128> nxvl: your issue seems to be http://bugzilla.gnome.org/show_bug.cgi?id=533254
<ubottu> Gnome bug 533254 in General "flickr upload stopped working" [Normal,Resolved: invalid]
<pitti> tseliot: (just forgot to install a -headers-generic dependency, PEBCAK)
<tseliot> ï»¿ï»¿pitti: if you tried another kernel just make sure that the headers for that kernel are installed
<seb128> nxvl: the bug indicates the guy who had the bug had networking issues
<pitti> tseliot: I dpkg -i'ed  -16-generic , but not -16
<tseliot> pitti: LOL that's what I thought
<pitti> building now
<cjwatson> nxvl: re the libssh/libssh-2 conversation the other day, where I think you suggested getting in touch with me; I wouldn't bother if I were you, I only care about openssh not the other implementations
<tseliot> ï»¿pitti: I can't wait to tell you about my new project: X-Kit. I'll send you an email.
<ogra> argh
<ogra> another kit
<ogra> will we rename gnome to DesktopKit  ?
<tseliot> ï»¿ogra: no, it will be GNOMEKit
<ogra> heh
<tseliot> the "Kit" suffix makes it sound so original :-P
<ogra> "this app was originally invented in nightrider episode ...."
<Pici> Wouldnt it be kitt then?
 * pitti hands ogra a K
<ogra> Pici, pfft details
<nxvl> cjwatson: the guy was only asking for the difference of this 2 libraries, and i thought you where the person who should know
<ogra> pitti, K-Kit ? for KDE ?
<cjwatson> nxvl: I don't, I've been studiously ignoring those libraries
<pitti> ogra: I meant "Knight", not "Night"
<ogra> ah, right
<nxvl> cjwatson: oh ok
<ogra> its a while ago ... i'm getting old, you know :)
<nxvl> cjwatson: i just assosiate ssh* with you
<nxvl> cjwatson: sorry about thet
<nxvl> that*
<nxvl> seb128: Bug #236783
<ubottu> Launchpad bug 236783 in f-spot "f-spot shows error uploading to flickr" [Undecided,New] https://launchpad.net/bugs/236783
<nxvl> seb128: i will take a look at the bugzilla bug and try to fix it later
<seb128> nxvl: did you read my comment on the chan?
<nxvl> now i need to go to work
<seb128> nxvl: the one saying that's likely an network issue on your side?
<nxvl> seb128: not before filing the bug
<nxvl> seb128: the thing is that i have tried on different conections
<nxvl> seb128: well, i will read the bug report and try to discard networking problems
<nxvl> seb128: thanks for your help
 * nxvl HUGS seb128 
<seb128> you are welcome
<seb128> good luck with that, let me know if you figure something, maybe it's shocking on an image which takes a while to transfert or something
<nxvl> seb128: i have also tried with 2 different bunch of pictures :S
<nxvl> is really weird
<seb128> ok, weird
<nxvl> now need to run
<nxvl> see you later
<seb128> later
<ion_> mvo: http://heh.fi/tmp/recovery-mode-dpkg.patch
<ion_> mvo: Btw, how about using aptitude instead of apt-get there? It is more intelligent. One could use -o aptitude::Delete-Unused=false to prevent any unintended removals.
<mvo> ion_: let me check the diff
<mvo> ion_: looks good, thanks. aptitude> no real reason I'm just in the habit of using apt-get more
<superm1> pitti, tseliot looks like you solved the mess with dkms/v4l-dvb if i'm not mistaken?
<pitti> superm1: mostly, yes
<superm1> okay good :)
<pitti> superm1: thanks
<ion_> mvo: When thereâs something presumably broken and the user wants a program to Just Fix Itâ¢, aptitude is probably the way to go. :-)
<asac> ogra: how about joining #ubuntu-mobile ?
<pitti> zul: seems you didn't forward our openvpn patches to Debian? I did that now, but please do it in the future as well
<zul> pitti: sorry about that
<pitti> zul: no problem
<pitti> zul: we have just three easy things left (LSB init script, README.Debian, udev debconf), I changed the latter in a way to be Debian compatible; I hope they'll be applied soon, then we can sync again
<zul> pitti: cool with me
<pitti> argh, except that our orig.tar.gz is different; apparenty Debian rolled their own :/
 * pitti uploads again
<pitti> Keybuk: do you plan to do the devmapper merge soon, or shall I take it?
<Keybuk> pitti: feel free
<Keybuk> I thought you were already doing that one ;)
<sistpoty|work> bryce, soren: do you have any clue about bug #193323 (since I was told, that kvm suffered from the same bug once, but actually works in hardy)
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Undecided,Invalid] https://launchpad.net/bugs/193323
<soren> sistpoty|work: bryce put in a quirk in dexconf.
<sistpoty|work> soren: ah
<soren> sistpoty|work: ...It detects if we're running in a kvm instance, and then shoves cirrus in the xorg.conf.
<sistpoty|work> soren: ah, k... then I guess I don't need to dig through diffs between kvm and qemu any longer :)
<soren> sistpoty|work: Heh. No.
<soren> sistpoty|work: The cirrus driver really, *really* should just list the pci vendor/device id's.
<sistpoty|work> soren: actually I doubt, that the cirrus driver is to blame. imho what's going wrong is that the defaultdepth changed to 32 (and the real cirrus card) just doesn't support 32bpp, and so no valid modes are found
<soren> sistpoty|work: Maybe I'm getting things mixed up here. What I seem to remember is that the pci vendor/device id of the emulated cirrus card is not listed as one handled by the cirrus X driver, so we needed to poke stuff into xorg.conf to make it work.
<sistpoty|work> soren: no, that doesn't seem to be the case, as the attached log does show that qemu detects the correct cirrus card
<soren> sistpoty|work: Ah, right. I was thinking of vmware.
<soren> sistpoty|work: (the vmware X driver, that is)
<sistpoty|work> soren: heh, that would make sense (can you have a PCI id for a virtual device *g*)
<soren> Oh, yes, indeed.
<soren> Qumranet has bought a stack of them.
<sistpoty|work> heh
<soren> The virtio nic and block device have officially registered pci vendor/device ID's, for instance.
<sistpoty|work> cool
<soren> I would imagine VMWare has done the same for their graphics adapter.
<soren> At least it's uniquely identifiable by its pci id's.
<soren> I'm guessing we'd have heard about it, if the just squatted on those id's and didn't properly register them :)
<sistpoty|work> heh
 * Mithrandir steals soren's '
 * Hobbsee steals Mithrandir
 * ion_ substitutes ' with â
<soren> ion_: Aw. I *hate* that.
<cgregan> Does anyone know if there is a way to extract the symbol list from a library to a text file?
<pitti> cgregan: something like nm -D /lib/libm.so.6 ?
<pitti> cgregan: alternatively objdump -T /lib/libm.so.6
<cgregan> pitti: I can give that one a try....would then: nm -D /lib/libm.so.6 > symbols.txt?
<pitti> cgregan: yes
<pitti> objdump is slightly more verbose, but by and large they output the same info
<cgregan> pitti: Thanks! I'll give it a shot
<Mithrandir> pitti: the fix for 230716 can cause data loss, which is probably not what we want.
<slangasek> Mithrandir: can you elaborate? (and perhaps tag the bug as 'verification-failed'?)
<Mithrandir> slangasek: mounting file systems will always cause the journal to be replayed, something which can cause data loss if the file system is in use by a hibernated system.
<Mithrandir> so, hibernate, boot live cd, boom, instant file system corruption.
<Mithrandir> luckily only if you try to use it with persistence enabled, it seems.
<slangasek> Mithrandir: I guess I'm not seeing how this relates to the change in question; the only new reference to 'mount' there is a 'mount -o bind', which doesn't mount any filesystems that weren't already mounted?
<Mithrandir> slangasek: from the changelog it looks like the list of file systems has been extended.
<Mithrandir> https://bugs.edge.launchpad.net/ubuntu/+source/casper/+bug/230703 is the one I meant, sorry
<ubottu> Launchpad bug 230703 in casper "Casper only scans vfat filesystems for cow files" [Undecided,Fix committed]
<Mithrandir> there was a reason for it originally only being vfat. :-)
<Mithrandir> hm, and ext2 too, since that doesn't have a journal
<slangasek> ah, I see, so the "try_mount" is now run in more cases, gotcha
<slangasek> vfat|iso9660|udf|ext2|ext3|ntfs)
<sebner> pitti: hi, you may remember my boson sync where dpkg-source -x wasn't working. any news/updates/progress?
<pitti> Mithrandir: thanks for pointing out; I reopened the bug in intrepid, too, slangasek already added a comment
<pitti> sebner: not yet; if the package itself is fine, we can work around it with a manual upload
<sebner> pitti: should be fine, yes
<Keybuk> ==31654== Conditional jump or move depends on uninitialised value(s)
<Keybuk> ==31654==    at 0x400A62B: (within /lib/ld-2.8.90.so)
<Keybuk> ==31654==    by 0x400329C: (within /lib/ld-2.8.90.so)
<Keybuk> ==31654==    by 0x4013E60: (within /lib/ld-2.8.90.so)
<Keybuk> ==31654==    by 0x4000BFC: (within /lib/ld-2.8.90.so)
<Keybuk> ==31654==    by 0x40007F6: (within /lib/ld-2.8.90.so)
<Keybuk> *sigh*
 * ion_ notices libc6 is still upgraded before findutils when upgrading to intrepid, triggering the xargs problem.
<MacSlow> mvo_, ehm... got my reply via priv.-msg. ?
<MacSlow> njpatel, although I got these going http://people.ubuntu.com/~mmueller/authenticate-rgba.png http://people.ubuntu.com/~mmueller/logout-rgba.png I've not been able to fix the issues with GtkSpinButton and GtkComboBoxEntry.
<MacSlow> njpatel, they seem to draw their frames differently compared to GtkEntry
<MacSlow> njpatel, btw... take the "brushed metal"-look only as an example of a non-uniform parent-widget background... I don't intend to push that upstream :)
<ion_> macslow: Nice
<MacSlow> ion_, thanks
<njpatel> MacSlow: (sorry for late reply) have you seen what happens with different themes?
<njpatel> MacSlow: oh, and its looking very nice :-)
<MacSlow> njpatel, only the GtkEntry gets ugly... I'm using a slightly patched murrine... because Cimi does clear the background to the themes bg-color, which would be ok if GtkEntry would not be so "oddly" implemented
<njpatel> MacSlow: I see, that sucks
<MacSlow> njpatel, in order to get the background of GtkEntry cleared to full transparency, thus avoiding those nasty gliches with rectangles larger than the decorating frame, I've to redirect it offscreen, clear to transparency in the expose-handler of my GtkEntry and finally composite it onto to parent widget in the parents expose-handler
<MacSlow> njpatel, that currently the only approach that works to get the rendering clean
<njpatel> MacSlow: woah, that's not good at all
<MacSlow> njpatel, yeah that sucks
<njpatel> MacSlow: can we fix it by patching Gtk before the next release?
<MacSlow> njpatel, I've not very high hopes for the "spit-and-polish" spec... but I need to collect all that info myself in order to write proper documentation for the spec
<MacSlow> njpatel, I don't think gtk+-upstream would accept a patch where GtkEntry is implicitly redirected offscreen
<njpatel> MacSlow: no, I mean that there must be a correct fix for entry, so it works better in this situation
<MacSlow> njpatel, I've talked to people like Owen Tayler and they also suggested the "redirect to offscreen..."-approach
<njpatel> MacSlow: okay, thats that then :-)
<MacSlow> njpatel, I'm already loosing too much time on figuring out all the issues for something that does not have a high priority
<MacSlow> I honestly have not expected it to be so nasty
<njpatel> MacSlow: dude, as long as you can get it to work for your use-case, move on to the next problem :-)
<amikrop> How can I declare wxPython as a dependency (python-wxgtk does not have an installation candidate, so I am not sure how to handle this)?
<amikrop> So, any help, please?
<jpds> amikrop: you needn't ask two channels
<amikrop> jpds: Oh, OK.
<tkamppeter> Domeone knows a command line tool to check the integrity of HTML files? I need this two check a server-side cache for corrupted entries.
<mterry> tkamppeter: HTML Tidy should be able to validate (http://tidy.sourceforge.net/)
<tkamppeter> mterry, thanks. Is it already packaged for Ubuntu (the server runs Dapper AFAIR).
<geser> !info wdg-html-validator dapper
<ubottu> wdg-html-validator (source: wdg-html-validator): WDG HTML Validator. In component universe, is optional. Version 1.6.2-6 (hardy), package size 468 kB, installed size 1188 kB
<geser> mterry: ^^
<geser> it's also in dapper
<mterry> neat
<tkamppeter> Thank you very much. I am installing the package on the server now.
<tkamppeter> !info tidy
<ubottu> tidy (source: tidy): HTML syntax checker and reformatter. In component main, is optional. Version 20080116cvs-2 (hardy), package size 16 kB, installed size 96 kB
<jcastro> evand: Is there a plan for a slideshow during the installer for intrepid ala: https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-slideshow
<evand> jcastro: Yes.  The Art Team will be making a MNG that will play during the file copy process.
<jcastro> evand: is there a spec someplace or should I just bug kwwii?
<evand> jcastro: Drafting the specification falls on me, so bug me :)
<jcastro> evand: k, I was just cleaning up installer stuff on brainstorm
<evand> link?
<jcastro> http://brainstorm.ubuntu.com/idea/136/
<Amaranth> evand: What supports MNG?
<Lightkey> Mozilla M17-1.4 :->
<evand> Amaranth: argh, point taken.
<Amaranth> xulrunner 1.9 does support APNG
<jcastro> evand: ok, I'll just mark it as in development for 8.10 and then link the spec later
<evand> thanks
<Lightkey> or you could alternatively include the still maintained MNG patch into your gecko browsers builds ;-)
<mario_limonciell> why not just have a normal video that plays instead?
<evand> That would work.  I'm not particularly tied to a format.
<mario_limonciell> you figure if space ends up being a limitation, you pull out some of the example-content, and put this video in it's place
<mario_limonciell> hum.  since when do the buildd's not have lsb_release by default?  i  thought it was a dependency of ubuntu-minimal. take a look at http://launchpadlibrarian.net/14897107/buildlog_ubuntu-intrepid-i386.mythplugins_0.21.0%2Bfixes17416-0ubuntu1_FAILEDTOBUILD.txt.gz;  search the log for "lsb_release:"
<mario_limonciell> it built fine in an intrepid sbuild
<norsetto> mario_limonciell: are minimal packages in buildd? I thought just essential were.
<mario_limonciell> norsetto, well at least used to be for gutsy and hardy..
<mario_limonciell> norsetto, and still in my intrepid sbuild, so  i assumed so?
<norsetto> mario_limonciell: well, I always assumed only essential, I guess I erred on the safe side
<mario_limonciell> norsetto, i suppose i could just fix the failure by adding lsb-release to build-depends, but if something suddenly changed on the buildds that archive admins dont know about, it would be better to make sure they saw it and got it fixed
<Mirv> is there already something that prevents moving stable-proposed packages into stable-updates if the to-be-moved packages break main dependencies / packages?
<ScottK> Mirv: Hopefully they get tested and this is found out.
<ScottK> Nothing gets moved automatically.  It's only after testing.
<jfcgauss_> hi. i could not locate the page (and the changelog) of linux-image-2.6.24-17-generic from http://packages.ubuntu.com. i see that package installed on my machine and it is from hardy-updates. thx..
<shiyee> jfcgauss_: see /usr/share/doc/linux-image-2.6.24-17-generic/changeog.Debian.gz
<jfcgauss_> :D thx
<emgent> heya
#ubuntu-devel 2008-06-03
<kees> archive-admins: can someone please deNEW the linux-* binaries in hardy-security?
<kees> (linux, l-r-m, l-b-m, l-u-m)
<kees> slangasek: ^^
<kees> cjwatson: ^^
<slangasek> kees: poking
<kees> slangasek: cool, thanks.
<lifeless> pitti: thanks for doing the amd64 port
<lifeless> pitti: by the time I actually hit sydney I couldn't put two characters adjacent to each other; I figured it was going to be about as trivial as it was
<calc> anyone else having problems with the gnome calendar locking up panel completely anytime you click on it, in hardy-updates?
<superm1> try turning off the temperature grabbing
<calc> superm1: how do you actually turn it off?
<calc> superm1: it only has options to change if it is displayed afaict
<superm1> well i've had the freezes you talked about, and i unchecked the weather and pulled out the extra locations i didnt need
<superm1> well that temperature
<superm1> turned off both
<superm1> and then it didn't pull the data or freeze anymore
<calc> oh ok, i will try removing the locations, i already have the other options disabled
<calc> hmm turning off the other locations didn't help either :-]
<calc> er :-\
<superm1> well i guess i just got lucky then :(
<superm1> it was really annoying before though, so i fell your pain
<calc> anyone happen to know how to set the username for svn ssh?
<persia> calc: ~/.ssh/config : it's the same as setting a username for any other ssh service.
<pwnguin> isn't it just svn+ssh://username@url
<calc> ah ok
<persia> pwnguin: Well, if you like to type your username that often :)
<pwnguin> persia: well, i have a eclipse etc set up svn
<pwnguin> if i need a username at all
<pitti> Good morning
<pitti> lifeless: you're welcome; thanks for digging this patch out, it's highly useful
<ajmitch> hi pitti
<Hobbsee> pitti!
<pwnguin> ok, thats bizarre. firefox doesn't offer a subscription icon for planet.kernel.org
<pwnguin> donno if it's ff or the site's fault, but still kinda silly
<Treenaks> pwnguin: maybe they forgot to add a <link rel="alternative">
<pwnguin> Treenaks: if you know how such stuff works and care, maybe send the site maintainer a hint ;)
<Treenaks> pwnguin: http://www.petefreitag.com/item/384.cfm
<Treenaks> you send them that :)
<pwnguin> it seems like something planet outta do on its own
<EvanCarroll> Can anyone help me confirm a bug?
<EvanCarroll> ssh-add -D && gnome-terminal --hide-menubar --full-screen -e "ssh host-with-passkey"
<EvanCarroll> please replace host-with-passkey with an ssh box ip or name that uses keyauth
<EvanCarroll> I think this bug exists in hardy you might have to jump to a tty and kill gnome-ask-ssh
<EvanCarroll> I think this bug exists in hardy you might have to jump to a tty and kill gnome-ssh-askpass
<EvanCarroll> gnome-keyring-ask*
<paulproteus> kees, ping?  (sort of an emergency)
<dholbach> good morning
<thekorn> hey dholbach!
<dholbach> hi thekorn
<munckfish> Hi, I want to get a the ps3-kboot sources into the bazaar supermirror. I'm not motu/core, I presume am I going to have to get someone with perms to push the first version for me?
<mdke> cjwatson: please could you poke through my email to ubuntu-devel-announce when you get the chance
<TheMuso> munckfish: What bazaar super mirror are you referring to?
<munckfish> I'm trying to follow this https://wiki.ubuntu.com/BzrMaintainerHowto
<munckfish> I'd like to get our packaging stuff up there so it's easy to share changes
<munckfish> TheMuso: particularly now you've offered to help build stuff for us
<TheMuso> munckfish: Right. Is there already a bzr branch for ps3kboot or whatever its called?
<munckfish> There's no product registered (I just did that)
<munckfish> I'll look and see if a branch exists
<TheMuso> munckfish: If there is not, you can create a branch under the newly registered product. You can make it writable only by yourself, or the ps3-dev team.
<munckfish> under the product not the team (like it says in that tut)
<munckfish> ok
<munckfish> TheMuso: could you join the ubuntu-ps3-dev team on LP?
<TheMuso> munckfish: If you would like me to, ok.
<munckfish> I think that would have benefits
<munckfish> in terms of permissions etc
<TheMuso> Ok done waiting for your ACK.
<munckfish> TheMuso: ok will do.
<munckfish> There is no existing branch
<TheMuso> Ok, so create a new one.
<munckfish> Ok I'll upload the first version under the product
<munckfish> TheMuso: Ok I need to leave for work. Thanks for you help, I'll cont. with this later
<TheMuso> munckfish: No problem.
<Mithrandir> cjwatson: is it possible to set expiry dates for SSH keys?
<saispo> BenC: ping ?
<saispo> no one from the kernel team ? i can't clone from the git repository...
<soren> saispo: Which url are you using?
<saispo> soren: git-clone git://kernel.ubuntu.com/ubuntu.hardy.git ubuntu-hardy
<soren> It's git://kernel.ubuntu.com/ubuntu/ubuntu.hardy.git
<saispo> yes, excuse me but same error...
<soren> Did you mistype or is the documentation wrong somewhere?
<saispo> Initialized empty Git repository in /home/jsoyer/local/csm/git/ubuntu-hardy/.git/
<soren> Oh. Hehh..
<saispo> fatal: The remote end hung up unexpectedly
<saispo> fetch-pack from 'git://kernel.ubuntu.com/ubuntu/ubuntu.hardy.git' failed.
<soren> It's git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git
<soren> Again: Did you mistype or is the documentation wrong somewhere?
<saispo> i get the command on the gitweb
<soren> Where exactly?
<saispo> http://kernel.ubuntu.com/git
<soren> _exactly_? :) I don't see that url anywhere on that page.
<saispo> on the top
<saispo> To clone one of these projects, use "git-clone git://kernel.ubuntu.com/<project>" or "git-clone http://kernel.ubuntu.com/git-repos/<project>".
<soren> You seem to be missing the point.. Does it say "kernel.ubuntu.com/ubuntu.hardy.git" anywhere?
<soren> if you just mistyped, that's fine. If the documentation is wrong somewhere, though, we need to fix that.
<saispo> i don't see where i make a mistake... :)
<soren> It's git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git
<saispo> git-clone git://kernel.ubuntu.com/ubuntu/ubuntu.hardy ubuntu-hardy and git-clone git://kernel.ubuntu.com/ubuntu/ubuntu.hardy.git ubuntu-hardy give me the same result...
<saispo> yes i'm agree with you :)
<soren> No, you don't. :)
<soren>                                            ^^
<saispo> this two commandes does not work :)
<soren> Look...
<soren> Take the url  I sent you and use that.
<soren> Copy'n'paste style.
<saispo> yes
<saispo> and don't work...
<saispo> i have : fatal: The remote end hung up unexpectedly
<soren> Replace ubuntu.hardy with ubuntu-hardy.
<soren> Copy and paste ftw.
<saispo> oh excuse me...
<soren> Now... Did you mistype or is the documentation wrong somewhere?
<saispo> i must open my eyes widely next times !!!!
<saispo> mistyped, big excuse...
<saispo> thanks soren
<saispo> and excuse me :)
<soren> np
<cjwatson> mdke: done
<arthur-> pitti: I answered your mail for initscripts, sorry for the delay
<cjwatson> Mithrandir: I don't think so, no
<cjwatson> TheMuso: "supermirror" is an old term for what's now called the Launchpad codehosting service
<TheMuso> cjwatson: ah.
<cjwatson> I've edited BzrMaintainerHowto accordingly
<pitti> arthur-: oh, thanks!
<pitti> seb128: any luck with gthumb?
<Riddell> pitti: can I move kde4libs -proposed to -updates?  bug 218138
<ubottu> Launchpad bug 218138 in kde4libs "unable to launch atlantik in kde4" [Medium,Fix committed] https://launchpad.net/bugs/218138
<pitti> Riddell: looks good, I tagged it v-done
<pitti> Riddell: doing
<seb128> pitti: I did comment on the bug yesterday
<seb128> pitti: no?
<pitti> seb128: I don't see it in bug 153572?
<ubottu> Launchpad bug 153572 in gthumb "Merge 2.10.8-1 from debian unstable" [Low,Fix committed] https://launchpad.net/bugs/153572
<seb128> ahhh
<seb128> you pointed an another bug number
<pitti> seb128: ah, right, because I suck
<seb128> the one about the set timestamp to the exif data value
<pitti> I forgot to mention above bug in the changelog, sorry
<seb128> and I commented on this one
<pitti> seb128: right; nevermind me
 * pitti hugs seb128
<pitti> Riddell: done
 * seb128 hugs pitti
<seb128> pitti: otherwise the new version works fine, I can add a comment about that on the new version bug if you want
<pitti> seb128: nah, that's ok
<seb128> alright
<Riddell> pitti: thanks
<munckfish> arthur-: I notice you're maintainer of libspe2 in debian, are you going to be looking after that package in Ubuntu too? (btw sorry hear about your rugby accident hope you're ok)
<pitti> mvo: is bug 225900 already fixed in the intrepid version, or does it need an upload?
<ubottu> Launchpad bug 225900 in chillispot "chillispot configuration getting hung up" [High,Fix committed] https://launchpad.net/bugs/225900
<mvo> pitti: let me check
<geser> pitti: should pkg-create-dbgsyms be able to handle "export DH_COMPAT := 2" in debian/rules? Currently it assumes compat level 1 because of the : before the =
<pitti> geser: ah, indeed
<pitti> if grep -q '^[[:space:]]*\(export[[:space:]]*\)\?DH_COMPAT[[:space:]]*=[[:space:]]*[2-9]\>' debian/rules; then
<pitti> geser: so *= should become *:?=
<geser> more *:\?= but yes
<pitti> geser: is that the recent debian/tmp -> no such dir FTBFS?
<geser> yes
<pitti> ah, thanks for tracking this down!
<geser> should I file a bug for it?
<pitti> geser: I'll add a test case, fix, and upload
<pitti> geser: if you want; but I'll fix it right now
<geser> if you fix it right now then I don't see the need to file a bug for it
<pitti> exactly
<pitti> ok, can reproduce here in the test suite
<mvo> pitti: I'm uploading chillispot now, it is not fixed in intrepid yet and then sent the patch to debian
 * pitti hugs mvo, thanks
<seb128> mvo: apt is on crack in intrepid, it really wants to install recommends ;-)
<mvo> seb128: indeed :)
<pitti> seb128: yohoo!
<seb128> mvo: sudo apt-get remove evolution; sudo apt-get dist-upgrade
 * mvo runs away for lunch before seb can catch him
<seb128> it wants to reinstall evolution because some other packages recommends it
<pitti> oh, even for metapackages?
<seb128> pitti: not really "yohoo" no, users should be able to remove evolution which is a standard package if they want to
<seb128> I'm not sure to understand the logic
<pitti> sure, for that particular issue; but I mean in general
<seb128> I would expect recommends to be trigger when installing a new package, not all the time
<mvo> seb128: I have a look after lunch, I'm not sure why its dragged in, generally it should not re-add it (might be a bug or something strange)
<pitti> that's true
<seb128> pitti: yeah, just some cleaning to do now ;-)
<seb128> mvo: ok, let me know if you need extra informations, I just tried and the guy is right
<seb128> sudo apt-get remove evolution on intrepid and sudo apt-get dist-upgrade wants to reinstall it
<mvo> seb128: do you have a bugnumer for this?
<seb128> mvo: bug #236360
<ubottu> Launchpad bug 236360 in evolution "evolution requires spamassassin" [Low,New] https://launchpad.net/bugs/236360
<seb128> mvo: I'm reassigning to apt since apt-get dist-upgrade has a similar behaviour
<seb128> mvo: hum, this lunch things is actually a good idea ;-)
<pitti> apachelogger_: rejecting your kopete-plugin-thinklight; please reupload with a LP # bug reference in the changelog; thanks!
<apachelogger_> aye
<pitti> mvo: likewise for notification-daemon
<geser> pitti: could you give at quick look at bug #236298 and tell me if I missed something or if it's complete?
<ubottu> Launchpad bug 236298 in libpar-dist-perl "[MIR] Move libpar-dist-perl to main" [Undecided,New] https://launchpad.net/bugs/236298
<pitti> geser: looks great, thanks!
<pitti> geser: p-c-d tested and uploaded; thanks!
<pitti> doko: does Debian know about the tzdata java patch/
<pitti> ?
<pitti> I didn't see it in the BTS
<doko> pitti: yes, aurelian knows
<ogra> lool, if you say you dont see crashes with libflashsupport, is that on i386 or amd64 ? (note that the latter uses nspluginwrapper, that might hide the actual crashes)
<lool> ogra: it's on i386 and amd64
<lool> ogra: I'm using a custom install of libflashsupport on Debian/i386 (1.0~2219-1) and 1.9-0ubuntu1 on Ubuntu/amd64
<ogra> hmm
<ogra> but no ubuntu i386 there
<Keybuk> sabdfl: so, about ye olde tech board? :)
<sistpoty|work> hm... any chance we could get a fix for bug 193323 into the point release?
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Undecided,In progress] https://launchpad.net/bugs/193323
<mvo> pitti: thanks and sorry for the forgotten LP number
<pitti> mvo: no problem; I'm just anal about this, since absent bug # make SRUs a pain
<mvo> rightly so
<Mez> Hmm .... Why is Evince saying that it's Microsoft word?
<Riddell> lool:
<Mez> nvm - it's the document
<Riddell> lool, pitti: bug 127985, accept or reject for gutsy?
<ubottu> Launchpad bug 127985 in libgtk2-perl "gutsy/amd64: ftbfs / autopkgtest failure" [Undecided,Fix committed] https://launchpad.net/bugs/127985
<pochu> soren: hi :) gtk-vnc is dep-waiting on a universe package (for the scaling support I think), could you look into it? https://edge.launchpad.net/ubuntu/+source/gtk-vnc/0.3.6-2
<pochu> soren: otherwise we can remove the scaling support, but that wouldn't be cool ;)
<geser> Mez: check the title property of your pdf
<Mez> geser, I did - It'd be nice for evince to show a prefix though (or a suffix) to show that it isnt MS Word
<soren> Mez: "Not Microsoft Word - Microsoft Word - Financial report 2007"
<soren> Sounds great!
<soren> pochu: So... Feel like writing an MIR? :)
<pochu> soren: not really, I'm terribly busy with uni and exams :(
<soren> pochu: Ok, no worries. Maybe I can pursuade someone else to do it. I'm a bit busy, too :/
<mvo> seb128: I can reproduce the apt thing, I'm on it
<seb128> mvo: cool
<geser> pitti: could you please remove "gproftpd" again and blacklist it this time? I got synced to intrepid again and intrepid has now a lower version than hardy, see https://edge.launchpad.net/ubuntu/+source/gproftpd
<jdstrand> cjwatson: hi! I finally got around to using your irssi-notify scripts and it's working great! :)
<pitti> Riddell: I don't think it's worth the risk for a mere FTBFS; it should be fixed if there's an actual fix
<pitti> geser: urgh, how can this happen...
<\sh> scripts are evil...they are created by humans ,-)
<pitti> Source: gadmin-proftpd
<pitti> geser: ^ ah, because it's not built from that source any more
<geser> pitti: gproftpd got renamed to gadmin-proftpd, so you removed the old source package but Debian has it still and it got autosynced again
<pitti> geser: done; thanks!
<\sh> and now I have to check if our changes are in debian or fix it again
<wgrant> x/win 10
<wgrant> Gahhh.
<lool> pitti: The bug is also missing lpia binaries; this would be fixed
<pitti> lool: which bug?
<lool> Riddell: pitti told me it wasn't worth it but would be included if there's something additional to fix
<lool> pitti: The libgtk2-perl NBS
<pitti> lool: oh, I see; if you need that package, it would be worth it, yes
<lool> As already discussed, we don't need it /anymore/; technically you can still run image-creator and build gusty images in one of the configs, and they miss this binary
<lool> But hopefully nobody does that anymore
<seb128> does anybody here read japanese?
<ScottK> persia: ^^^
<dholbach> seb128: persia might be able to :)
<seb128> see current comment on bug #209520, it indicates that a japanese blog indicates that some of the samba issues in hardy are due to -Wl,-Bsymbolic
<ubottu> Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] https://launchpad.net/bugs/209520
<seb128> opinion from toolchain and samba guys would also be welcome
<zul> seb128: I think there is already a bug open about the -Bsymbolic flags
<zul> seb128: I also found a fix for #217137 as well
<seb128> zul: do you plan to sru it?
<zul> seb128: im in the middle of patching it now
<seb128> cool
<zul> but for the -Bsymbolic one I think you might slangasek's opinon as well
<pitti> Keybuk: can you please have a quick look at https://wiki.ubuntu.com/DesktopTeam/Specs/Intrepid/DevicePermissions ? Please search for "Scott"
<pitti> Keybuk: I'd like to write down why the hardy changes for the fingerprint reader can be dropped (and do so in hal, to get rid of a patch which didn't get accepted upstream)
<persia> seb128: My apologies, but the limitations of my Japanese combined with my limited understanding of library symbols conspire to block my understanding.  I'll try to either catch Hatena on IRC or get someone to help translate later, and get back to you.
<Keybuk> pitti: Epiphany's search is broken today :-(
<Keybuk> pitti: btw, do we care about saned?
<pitti> Keybuk: ^ for the pending merge of sane-backends?
<pitti> I haven't made up my mind yet, TBH (too much other stuff to do)
<Keybuk> just in general
<pitti> Keybuk: seems quite heavy for a corner use case, though
<Keybuk> it needs a sane user/group
<pitti> (picking up network scanners, etc; sounds like something avahi should handle)
<seb128> persia: thanks, did you spot any reference to a launchpad bug in the blog text?
<Keybuk> and it's not run out of the box anyway
<pitti> Keybuk: I think it is run now in Debian sid
<Keybuk> really?  urgh
<persia> seb128: Yes, but not the specific bug.
<seb128> ok, thanks
<Keybuk> pitti: Fingerprint readers
<calc> anyone know about the gnome calendar crashing when you select it issue in hardy-updates?
<pitti> Keybuk: nothing we couldn't disable again, I just didn't consider it urgent to re-merge so far
 * calc hasn't tried tracking down a bug number yet
<Keybuk> The current HAL patch and rules are to allow ordinary users to use the fingerprint reader device
 * ogra listens up hearing fingerprint readers 
<Keybuk> and thus authenticate and capture fingerprints
<Keybuk> which is wrong
<ogra> is there a fix for mine ?
 * calc doesn't know which desktop team member is in charge of that now
<Keybuk> use of the fingerprint reader device should be a privileged operation
<pitti> Keybuk: that was merely a workaround so that gnome-screensaver could use it, wasn't it?
<Keybuk> and both the registration of new fingerprints, and authentication of existing ones, should be done in the same manner as passwords
<Keybuk> basicaly, yeah
<Keybuk> the proper fix is that the pam_fprint module should have a chkpwd like helper it can call when it needs to
<persia> seb128: I'm pretty sure it's bug 234901
<ubottu> Launchpad bug 234901 in samba "Please apply upstream patch for dpkg-buildsource" [Undecided,New] https://launchpad.net/bugs/234901
<Keybuk> actually
<Keybuk> fprint shouldn't be done by PAM at all
<Keybuk> because fingerprints are not suitable for authentication
<Keybuk> they are simply suitable for identification
<soren> What's the difference?
<Keybuk> the right way it should work is that swiping your fingerprint should be equivalent to a fast user switch
<Keybuk> swiping your fingerprint at gdm equivalent to entering your username
<Keybuk> if you have no password, that would be sufficient
<Keybuk> but if you have a password, then you should also be asked for it
<pitti> soren: you can tell who the fingerprint belongs to, but you can't tell whether it's actually the right person which presents it
<Keybuk> soren: identification is something that is unique to you
<Keybuk> soren: authentication is something that is secret to you
<seb128> persia: indeed seems to be the issue, thanks again
<Keybuk> a fingerprint is a suitable medium to identify someone
<soren> Hm...
<pitti> soren: "I want to buy that shiny laptop with Soren's credit card"
<Keybuk> if it's swiped, then it's probably them
<Keybuk> or someone who's obtained their finger ;)
<seb128> slangasek: could you look at bug #234901?
<ubottu> Launchpad bug 234901 in samba "Please apply upstream patch for dpkg-buildsource" [Undecided,New] https://launchpad.net/bugs/234901
<Keybuk> but it's not suitable to authenticate someone
<Keybuk> since fingerprints are not secret
<persia> seb128: Anytime.  There's a lot of coders here, and I like to see their work shared :)
<Keybuk> in fact, using a fingerprint for authentication is morally equivalent to writing your password down on every single surface you touch
<pitti> soren: the CCC recently published the fingerprint of our Minster of the Interior :)
<Keybuk> pitti: that's a good example
<soren> pitti: Heheh :)
<Keybuk> the Credit Card (well, it's number) is unique to soren
<Keybuk> so it identifies him
<Keybuk> and his PIN number is secret to soren
<Keybuk> so it authenticates him
<pitti> soren: (in case you don't know, he has gone crazy and wants to turn Germany into an even worse surveillance country)
<soren> Right, ok. Got it.
<Keybuk> the right way to do fingerprint support is definitely as an alternative to entering your username
<pitti> Keybuk: ok, spec updated, set to "Review" state; anything else that I need to do about it now?
<pitti> like, getting it ack'ed by someone else than you first, or so?
<Keybuk> no, probably not ;)
<Keybuk> can you propose it as an intrepid release goal
<pitti> sure
<pitti> I set myself as an assignee, too
<pitti> uid=1000(martin) gid=1000(martin) Gruppen=4(adm),40(src),107(fuse),109(lpadmin),115(admin),1000(martin)
<pitti> that's already not too bad any more
<pitti> fuse will go away, too, teh rest more or less needs to stay for now
<pitti> lpadmin is the only thing that should eventually go away, AFAICS
<Keybuk> what's src?
<Keybuk> is that one of your own?
<persia> Gives write access to /usr/src
<jdstrand> zul: can you approve the 'nominate for release' for bug #235912 ?
<ubottu> Launchpad bug 235912 in samba "[CVE-2008-1105] Samba: boundary failure when parsing SMB responses" [Undecided,Fix released] https://launchpad.net/bugs/235912
<pitti> jdstrand, zul: ^ done
<jdstrand> pitti: thanks!
<zul> pitti: thanks
<pitti> Keybuk: as persia said; /usr/src is 2775 root:src
<pitti> Keybuk: it's not a standard group
<sabdfl> Keybuk: taipei time
<Keybuk> sabdfl: ah, how long until my tech board membership expires there? :p
<sabdfl> everything happens faster here ;-)
<ogra> heh
<Keybuk> ah, the anti-spain
<sabdfl> Keybuk: fixed!
<ion_> Funny, both of my intrepid boxes refuse to reboot or shutdown. /me goes to bugs.launchpad.net
<emgent> heya
<afflux> asac: can you please explain why you closed bug 131793? It was confirmed and I can't find any reason why it should be invalid.
<ubottu> Launchpad bug 131793 in firefox "firefox crashed" [Medium,Invalid] https://launchpad.net/bugs/131793
<slangasek> seb128: 234901> had seen it, it made me whimper.  I don't think it's related to bug #209520, but is SRU material nonetheless.
<ubottu> Launchpad bug 209520 in nautilus "SMB error: Unable to mount location when server configured with security=share" [Undecided,Confirmed] https://launchpad.net/bugs/209520
<seb128> slangasek: right, the bug is clearly a gvfs issue, I pointed it because it seems to be a good sru candidate
<StevenK> slangasek: Can you peer at the debdiff I just uploaded to bug 195260 when you have a moment?
<ubottu> Launchpad bug 195260 in mailscanner "MailScanner won't start due to variable $FIELD_NAME" [Undecided,Confirmed] https://launchpad.net/bugs/195260
<slangasek> StevenK: er, looks straightforward, but I'm not sure on what level you're asking me to peer at it - it's a universe package, so motu-sru should approve it
<StevenK> Ah ha. To high a level.
<StevenK> slangasek: Would you mind unsubscribing ubuntu-sru, then? :-)
<slangasek> right, done :)
<StevenK> slangasek: Thanks
<guysoft422> hey all, does anyone know here what html is opened when running: yelp ghelp:about-ubuntu
<saispo> BenC: ping ?
<sistpoty|work> slangasek: can you approve bug #193323 and accept the package into -proposed?
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Medium,In progress] https://launchpad.net/bugs/193323
<jdstrand> pitti: if a package is in -updates in soyuz, will I need to have it deNEWed in -security like in dak?
<jdstrand> pitti: hi btw :)
<Riddell> jdstrand: uploads to -proposed will get stuck in unapproved
<Riddell> they shouldn't when moving from -proposed to -updates
<BenC> saispo: pong
<jdstrand> Riddell: well, I had a bit of an odd case here where all this clamav stuff was added to -updates. I was then asked to get it into -security (usually its the other way around). So, I had to have a few packages deNEWed in dak, and was wondering if I needed to do the some thing in soyuz
<Riddell> BenC: what is linux-ports?
<pitti> jdstrand: yes
<pitti> jdstrand: unless it is already present in dak, too, obviously
<jdstrand> pitti: no, it wasn't
<pitti> jdstrand: then you need elmo (cjwatson is AFK today)
<jdstrand> pitti: dak is all set now
<jdstrand> pitti: I pushed to soyuz a minute ago
<jdstrand> pitti: so it's just the soyuz bits I was asking about
<pitti> jdstrand: if the same package name already exists in soyuz, it's fine
<jdstrand> pitti: perhaps specifics would help here
<jdstrand> pitti: clamav had a micro version update for dapper, feisty and gutsy
<jdstrand> pitti: pyclamd is a new package for feisty and gutsy, but happens to exist in -updates right now
<jdstrand> pitti: does anything special have to happen with clamav or pyclamd in soyuz? both needed to be deNEWed in dak
<pitti> jdstrand: no, they should just go straight through
<jdstrand> pitti: ok cool-- thanks :)
<pitti>    pyclamd | 0.1.1-0ubuntu1~dapper1 | dapper-backports/universe | source
<pitti> python-pyclamd | 0.1.1-0ubuntu1~dapper1 | dapper-backports/universe | all
<BenC> Riddell: It's the kernel source for non-supported architectures (IOW, anything not x86/x86_64 right now)
<jdstrand> pitti: I didn't do anything with pyclamd for dapper
<pitti> jdstrand: well, at least overrides for dapper automatically apply to all the pockets; I *think* that holds true for the reverse direction, too
<pitti> jdstrand: anyway, if it does land in NEW, just ping Riddell, seb128, or me
<jdstrand> pitti: ok
<Riddell> BenC: and i386 is non-supported?
<ogra> Riddell, its supposed to go to universe if i understood that right in prague
<ogra> -i386 vs -generic
<seb128> anybody using hardy-updates on amd64 who could get a stacktrace for bug #236025?
<ubottu> Launchpad bug 236025 in evolution-exchange "evolution-exchange-storage crashed with SIGSEGV in gconf_engine_unref()" [Undecided,New] https://launchpad.net/bugs/236025
<seb128> the retracers are broken but that could give informations for bug #236171 which annoys several users
<ubottu> Launchpad bug 236171 in gnome-keyring "gnome-keyring-daemon and Evolution cause 100% CPU usage" [Undecided,New] https://launchpad.net/bugs/236171
<saispo> BenC: i found the error :) it's about compiling lum under hardy for xen and alsa
<saispo> i fixed, it's ok :)
<pitti> BenC, mvo: I updated https://wiki.ubuntu.com/IntrepidImprovedLinuxMeta with the current discussion I had with mvo
<ogra> seb128, is the gdm-signal bianry supposed to work in any way ?
<jdstrand> Riddell: well, looks like clamav and pyclamd did end up in NEW. Can you deNEW them for feisty and gutsy?
<seb128> ogra: it used to work, I didn't try for a while
<ogra> seems it doesnt anymore
<Riddell> ok
<Riddell> jdstrand: accepted
<jdstrand> Riddell: thanks! I have a feeling clamav on dapper will also need it, but it isn't showing up yet
<seb128> ogra: that will most likely go away or need to be rewritten when we update to the new gdm anyway
<ogra> seb128, right, i just suggested it to someone in -mobile who tries to write a custom logout dialog not using gnome-session ... and we found it just exists silently
<Riddell> jdstrand: although there does seem to be a 16 week old linux-meta in there..
<ogra> *exits
<jdstrand> yeah, I just noticed that...
<Riddell> jdstrand: any idea if that should be accepted or rejected?
<jdstrand> Riddell: I'm checking
<ogra> seb128, hmm, the strace looks like its simply sending the wrong string http://paste.ubuntu.com/16599/
<bdmurray> pitti: did slangasek's e-mail clear up my intent with the proposed-pkg tag?
<jdstrand> Riddell: it should be accepted
<Riddell> jdstrand: ok, doing
<jdstrand> Riddell: thanks
<Riddell> done
<ScottK> jdstrand: Dapper shouldn't need it.
<seb128> ogra: right
<jdstrand> ScottK: nope it doesn't, just showed up as published
 * ScottK basks in the (momentary) warm glow of having the same clamav version in all supported releases.
<jdstrand> ScottK: take it in while you still can :)
<jdstrand> ScottK: good work!
<ScottK> Thanks.
<slangasek> zul: is bug #217137 fixed already in intrepid (samba 3.0.30)?
<ubottu> Launchpad bug 217137 in samba "[SRU] Hardy Heron: Nautilus fails to open directory with more than 140 subfolders" [Undecided,New] https://launchpad.net/bugs/217137
<zul> slangasek: I believe it is
<slangasek> care to mark it as such in LP? :)
<zul> slangasek: I can do that :)
<zul> slangasek: MoM has samba-3.2 do we want that as well?
<slangasek> er, no
<slangasek> 3.2 is only in experimental right now
<slangasek> and there are some licensing hang-ups with it
<zul> ah ok
<ion_> mvo: There are three suggested changes here: 0) rm -f to avoid an error message when there are no files matching the pattern, 1) no need to specify python versions to search for, just look up /usr/bin/python*, 2) use aptitude safe-upgrade instead of apt-get dist-upgrade, since itâs more intelligent in tricky situations. Feel free to discard any of them if they are not worthy. :-) http://heh.fi/tmp/recovery-mode-dpkg-2.patch
<kirkland> cjwatson: hey colin, got your note about using bzr instead of debdiff---that's fine by me, i'm happy to comply.  question, though, as this is the second time i've hit this in a week....  how do i tell before hand whether a maintainer is going to prefer debdiffs or bzr branches?
<jdstrand> zul: fyi: http://packages.debian.org/changelogs/pool/main/s/samba/samba_3.0.30-2/changelog (see changelog entry for 2:3.0.30-2)
<kirkland> cjwatson: something equivalent to "whatpatch" might be helpful...  "whatsourcecontrol" or the like
<kirkland> cjwatson: does such a beast exist?
<slangasek> kirkland: if the package correctly uses the Vcs-* fields in debian/control, then apt-get source will give you a notice
<slangasek> e.g.:
<slangasek> NOTICE: 'grub' packaging is maintained in the 'Bzr' version control system at:
<slangasek> https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<slangasek> Please use:
<slangasek> bzr get https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
<slangasek> to retrieve the latest (possible unreleased) updates to the package.
<kirkland> slangasek: oh, cool, i'll look for that
<kirkland> slangasek: i very nearly asked you this question after the grub work i did last week ;-)
<slangasek> :)
<Riddell> soren: E: virt-goodies: python-script-but-no-python-dep ./usr/bin/vmware2libvirt
<slangasek> there's also 'debcheckout', which you can use to check the package out of bzr directly
<Riddell> soren: accepted, but that should probably be fixed
<slangasek> sistpoty|work: bug #193323> always a little disturbing to see debdiffs where a patches/series file is added and no other build-dep machinery is needed...
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Medium,In progress] https://launchpad.net/bugs/193323
<slangasek> (which in this case is a variant on reasons I hate simple-patchsys, #27: you can never tell by looking at the debdiff whether the maintainer has added a patch right)
<Riddell> slangasek: how do other patch systems let you tell?
<ion_> mvo: Sorry, i decided that aptitude safe-upgrade handles what apt-get -f install does too soon. It doesnât in all situations. Patch updated.
<slangasek> Riddell: if you're using quilt or dpatch, there's some sort of patch list that you register the patch with; if the debdiff shows that the new patch is /added/ to that file, you can have a reasonable level of confidence that the patch system was in working order beforehand
<slangasek> Riddell: but if you only see the addition of a patch in a debdiff, without any series file, it's impossible to determine whether this is because the package uses simple-patchsys, or the uploader forgot to add the patch to the series file, or the uploader forgot to configure the package to use a patch system at all...
<sistpoty|work> slangasek: actually quilt was there before... so I just used that (and actually had some troubles with it... I prefer plain patches in .diff.gz myself)
<mvo> ion_: thanks, I have a look
<slangasek> sistpoty|work: right, I know quilt was there because I know that's how the X Strike Force packages are maintained - it was still disturbing to see that this was the only patch in the series until I remembered that :)
<sistpoty|work> slangasek: thanks for accepting it :)
<sistpoty|work> slangasek: no, it's not the only patch actually, there was another one there before ;)
<slangasek> oh, there was?  Hmm, the diff is misleading then
<slangasek> (it doesn't show the other line as context)
<sistpoty|work> indeed, that's quite strange
<siretart> sistpoty|work: as I mentioned in the bug report, the testpackage did work on my laptop using qemu!
<sistpoty|work> siretart: yes, I saw that... and it worked in FAUmachine for me :)
<ion_> mvo: And... Patch updated once again :-P. I dpkg --unpacked a package that had an uninstalled dependency. I initially tried just aptitude -f install, but it offered to remove the package that had been partially installed instead of satisfying the dependency. So i put apt-get -f install to the patch. Now i found out that aptitude --safe-resolver -f install handles it as expected, installing the dependency and finishing the install of the package.
<slangasek> seb128: should gnome-games-data 2.22.2.1 be copied from hardy-proposed to intrepid? (fixes bug #221781)
<ubottu> Launchpad bug 221781 in scrollkeeper "scrollkeeper crashes during upgrade and causes maintainer script failures for various packages" [Undecided,Confirmed] https://launchpad.net/bugs/221781
<siretart> it would be interesting to know if the dexconf quirk can be removed with that patch
<slangasek> siretart: intrepid-only, please ;)
<siretart> bryce: do you agree to remove the dexconf quirk for the cirrus driver now that bug #193323 has been fixed in intrepid?
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Medium,Fix committed] https://launchpad.net/bugs/193323
<siretart> bryce: at least on probation ;)
<seb128> slangasek: yes please
<stgraber> mvo: someone just reported bug 237111 that breaks gutsy => hardy upgrades when italc is installed
<ubottu> Launchpad bug 237111 in italc "package italc-client 1:1.0.7-0ubuntu2 failed to install/upgrade: tentata sovrascrittura di `/usr/share/pixmaps/italc.xpm', che si trova anche nel pacchetto italc-master" [Undecided,New] https://launchpad.net/bugs/237111
<seb128> slangasek: I though that was already copied
<stgraber> mvo: what's the best way to fix that ? (other than asking the user to remove the package and reinstall it afterwards to avoid the conflict)
<slangasek> seb128: evidently not, but I'll take care of it :)
<mvo> stgraber: checking
<slangasek> pitti: what do you like to do in a case like bug #221781, where a bug is fixed by a package in -proposed, but that wasn't known at time of upload so the bug number isn't in the changelog?
<ubottu> Launchpad bug 221781 in scrollkeeper "scrollkeeper crashes during upgrade and causes maintainer script failures for various packages" [Undecided,Confirmed] https://launchpad.net/bugs/221781
<mvo> stgraber: that looks like a missing "Replace: italic-master (<< $version-where-file-was-moved)" in itallc-client
<mvo> stgraber: we should do a sru for this. people running the release-upgrader are not affected because we run with --force-overwrite here
<stgraber> mvo: hmm, so he was doing a manual dist-upgrade ...
<stgraber> mvo: doing Replace: italc-master (<< x.y.z) will let dist-upgrade overwrite then install it ? because we can't just drop italc-master
<mvo> stgraber: yes, it means that italc-client is allowed to overwrite files of the italc-master package (if version << x.y.z is installed)
<mvo> stgraber: let me know if I can help further, but it should be safe to use the hardy version for the << (best is of course the exact version where the file was moved)
 * Surfer33 Visit http://www.FakeMagazineCover.com (upload pic make mag) - http://www.SillyWebcam.com (play with webcam online) - http://www.Is-A-Jerk.com (insulter/anon email) - http://www.ComedySearchEngine.com (fun) - http://www.BodySwitcher.com (put your face on funny body) - http://www.MedChecker.com (health) - http://www.Canuckster.com (Canada eh) - http://www.Nerdful.com (geeks)
* Surfer33 changed the topic of #ubuntu-devel to: -=[ www.WHAK.com ]=- Make Free/Fun Graphics Online At http://www.ImageGenerator.org =)
<Hobbsee> sigh
* Hobbsee changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | Ubuntu 8.04 LTS released! | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/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
<mkrufky> that's frac'd up -- isn't this channel registered?  you should require ops rights to change the topic
<Hobbsee> mkrufky: it's registered.
<mkrufky> you can restrict topic changes to ops
<Hobbsee> i know
<mkrufky> k
<Seeker`> /mode #ubuntu-devel +t
<Hobbsee> however, it's rarely abused, and non-ops tend to change it more often.
<mkrufky> gotcha
<ogra> and we have ops to change it back while immediately caring for the cause of the prob as well ;)
<ogra> thanks Hobbsee
<Hobbsee> np
<Hobbsee> ogra: nah, i can't kline.
<Hobbsee> although, killing all java clients is an option...
<Hobbsee> will try that.  it looks like a proper IP, not a proxy.
<mkrufky> oof... twcny is all dynamic IPs
<mkrufky> that guy will have a new IP tomorrow, and somebody ELSE will be banned
<mkrufky> (thats my isp, too)
<Hobbsee> actually, it's stayed constant in his last 3 hits (over a couple of mins)
<Hobbsee> so he's not power cycling or so.
 * calc wonders if forcing people to register nicks to join a channel would help, and make registering nicks require real email address, etc
<mkrufky> registered to change a topic is reasonable
<persia> calc: I'd not like that for when I am testing something in an image, and don't want to put a password, yet wish to speak here.
<Hobbsee> calc: possibly, although i've got a preference of blocking all anonymisers
<mkrufky> but registered to join a channel may be a bit much
<Hobbsee> calc: and the latter is enforced, now
<persia> Hobbsee: Well, kinda.  There are still ways around it, but they are harder to reach.
<Hobbsee> persia: yeah, true.
<slangasek> calc: we should just make spamming a capital crime, that's all
<Hobbsee> slangasek++
<calc> slangasek: heh yea :)
<calc> just send them to texas and we'll get rid of them ;-)
<slangasek> \o/
<bryce> siretart: sure, if the underlying problem is confirmed as fixed, I'd love to remove the dexconf quirk
<bryce> siretart: there's actually several qemu quirks in dexconf, and I'm not certain which can be removed
<bryce> siretart: it is specifying the driver, the depth, the horizzync/vertrefresh, and the resolutions
<greg-g> for an SRU which is in -proposed, should I write a "works for me" comment on the bug regarding the SRU? (eg: bug 235805 )
<ubottu> Launchpad bug 235805 in evolution "2.22.2 stable update" [Wishlist,Fix committed] https://launchpad.net/bugs/235805
<greg-g> I've been using the package for 3 days now
<bryce> siretart: I've commented on bug 193323 about what needs tested.  There'll need to be a new bug report filed.
<ubottu> Launchpad bug 193323 in xserver-xorg-video-cirrus "x fails to startup in qemu - no driver for Cirrus card" [Medium,Fix committed] https://launchpad.net/bugs/193323
<ogra> greg-g, positive comments usually help with SRUs, yes
<sbeattie> greg-g: yes, please write a works for comment, it's useful if you can briefly characterize how you've been using the software
<sbeattie> err a wroks for me comment.
 * sbeattie gives up on typing today
<greg-g> thanks ogra/sbeattie
<gmargo> What mailing list has info about kernel updates?  Today a new linux-source package came out (2.6.24-18.32) but no corresponding linux-image packages, except the -debug versions.  I can't find the mailing list archive that might talk about this.
<asac> afflux: you can reproduce? do you use the instructions in the bug?
<zul> slangasek: mind coming to the server-team meeting tomorrow I put openldap on the agenda
<slangasek> zul: what time is it?
<zul> slangasek: 15:00 UTC I believe mathiaz correct me if Im wrong
<afflux> asac: not sure if it's still possible, but the last time I checked it worked (as mentioned in the last two comments in the bug)
<slangasek> zul: well, assuming we're still on the same schedule for the platform team meeting, then yes, I mind doing anything at 1500 UTC tomorrow :)
<zul> slangasek: :)
<afflux> asac: right, I can't reproduce it anymore with firefox 3.0~rc1+nobinonly-0ubuntu0.8.04.1.
<slangasek> zul: so, trying to confirm with cjwatson on that point; if I can make it I will
<zul> slangasek: ok great thanks..
<ogra> slangasek, ah. you were on holiday last meeting, right ?
<ogra> we rotated
<slangasek> ogra: correct; I've poked the IRC log, it just says that cjwatson will send mail about it
<ogra> right
<slangasek> not that the time was confirmed changed, or am I overlooking something important later in the log?
<ogra> well the US and asia people that were there all said it would be ok
<ogra> i'd have counted that as confirmation
<saivann> ScottK : ping
<ScottK> Pong
<ScottK> saivann: ^^
<saivann> ScottK : Concerning bug 230350, you said "I think you'd be better off to call it 0.4.0.2-3build1 and not change anything
<saivann> but debian/changelog." I agree about the first part, but I still think that we should "merge" the debian packages since there is a lot of updates in the packaging, like you can see in the last patch that I attached
<ubottu> saivann: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/230350/+text)
<ScottK> saivann: My suggestion is use the Debian package, not ours as the basis for "only changing the changelog".
<saivann> ScottK : What would you think about keeping the current patch, but change the changelog entry for 0.4.0.2-3build1
<slangasek> hmm, does update-manager use sudo for authentication in hardy?
<slangasek> (IIRC it does)
<ScottK> Less the maintainer change I think that adds up to what I suggested.
<saivann> ScottK : Ok then we agree, my current debdiff is the differences between the debian package and our current package. All I would need to change is the version (0.4.0.2-3build1)
<ScottK> And drop the maintainer change.
<saivann> ScottK : And set the status to invalid for bug 230350?
<ubottu> Launchpad bug 230350 in chmsee "Missing Debian Maintainer field" [Wishlist,In progress] https://launchpad.net/bugs/230350
<ScottK> saivann: Yes.
<saivann> ScottK : Thank you
<siretart> bryce: see my follow up on bug #237164. none of the quirks discussed here are actually working with qemu
<ubottu> Launchpad bug 237164 in xorg "dexconf specific quirks for kvm should be dropped" [Undecided,Confirmed] https://launchpad.net/bugs/237164
<sistpoty> siretart: heh, looks like we simultanously commented on the dexconf quirks bug *g*
<siretart> sistpoty: oh,  nice :)
<siretart> sistpoty: as for bug status: it should be 'confirmed' since it is a genuie issue. if you want to express that it is valid, then 'triaged' is meant for that
<sistpoty> siretart: ah... I guess I'm not too used to the triaged status yet
<siretart> sistpoty: we had quite some discussion about the bugstatus 'confirmed' at UDS. kiko suggested to just remove it from launchpad because there is so much confusion about it
<norsetto> I would just remove triaged ...
<siretart> sistpoty: see https://wiki.ubuntu.com/Bugs/Status for the status definition
<siretart> norsetto: as long as 'confirmed' becomes restricted to developers, I wouldn't mind
<norsetto> siretart: thats even better then
<saivann> ScottK : If you have few minutes to review, here's the new fake sync : bug 235387
<ubottu> Launchpad bug 235387 in kasablanca "Please sync 0.4.0.2-3 from debian unstable" [Wishlist,New] https://launchpad.net/bugs/235387
<ScottK> saivann: I'm busy with $WORK currently, so just go with the normal sponsorship process.
<saivann> ScottK : Ok thanks again
<ScottK> No problem.
<joshwaitzkin> hi, I'm searching for a contributor (not with money but with knowledge) for my open source application, it's written in C and is a cd drive utility. More details here: http://odman.sourceforge.net/
<knix> oss spam
<andrew_sayers> joshwaitzkin: wouldn't it be better to contribute to a project like setcd?
<joshwaitzkin> andrew_sayers, I can't work on my app, and to work with other apps. too
<joshwaitzkin> because I have no time :(
<andrew_sayers> My point is, your app seems to overlap considerably with that one.
<andrew_sayers> If you merge your work into that, you can contribute more productively and be more likely to get your work reviewed.
<kantor> hi, I'm searching for a contributor (not with money but with knowledge) for my open source application, it's written in C and is a cd drive utility. More details here: http://odman.sourceforge.net/
<iGama> Hy all
<iGama> where can i find info about the packages in the Proposed repository?
<slangasek> what info are you looking for?
<iGama> like the Samaba package, for example
<iGama> *Samba
<iGama> whats the changes on it? why new package
<iGama> the description on the update manager gave me nothing
<iGama> its more about curiosity
<slangasek> the 'description of update' pull-down will retrieve the full changelog for the update
<iGama> theres nothing on it
<iGama> its says " Not available"
<slangasek> hmm, possibly the changelog for that particular update isn't published yet to the changelog server because of how recent it is
<iGama> true
<iGama> but isnt there a place where it says what packages are going in the rep?
<slangasek> well, https://lists.ubuntu.com/archives/hardy-changes/2008-June/
<iGama> that can help :) thanks
<geser> pitti: are the buildds chroot broken again?
<pitti> geser: eek?
<geser> WARNING: The following essential packages will be removed.
<geser> This should NOT be done unless you know exactly what you are doing!
<geser>   sysvutils
<geser> http://launchpadlibrarian.net/14967445/buildlog_ubuntu-intrepid-i386.libfile-sync-perl_0.09-4build1_CHROOTWAIT.txt.gz and others
<pitti> geser: oh, that might even be my fault; it was renamed to sysvinit-utils
<pitti> and sysvutils is now a transitional package
<pitti> I didn't see that when upgrading with dpkg -i *.deb
 * pitti checks
<pitti> geser: ah, I think I got it; fixing
 * pitti already feels infinity's wrath
<pitti> geser: fix uploaded; but it might not actually build, due to said problem :/
<jonathan_> Greetings.  I am new to Linux development (switching from .NET programming.)  I presume I am in the right place?
<slangasek> um... per the channel /topic, no, you aren't :)
<mterry> jonathan_: This is more for specifically-Ubuntu work, not general Linux programming
<pwnguin> development OF ubuntu, not ON ubuntu ;)
<jonathan_> Ah, thanks.  Thought someday I hope to join your ranks.  :-D
<pwnguin> though I do wish there was a channel or community for the latter -- then someone might fix eclipse ;)
<jonathan_> Yeah, I lament the fact that AVR32 Studio is built on Eclipse.
<pwnguin> lets be clear -- eclipse is far better than any embedded IDE before it. but this is all "off-topic"
<ScottK> jonathan_: Eclipse is in Universe, so #ubuntu-motu would be a better channel to discuss improving it for Ubuntu.
<norsetto> scottk: masochist
 * ScottK is a core-dev now.  I'll leave him to dedicated MOTU such as yourself. ;-)
<pwnguin> well then lets bring it back to main: where's the C++ ide in main?
<bryce> siretart: posted some debs to validate with; I can upload the xorg changes to intrepid once someone can do a quick smoke test
<pwnguin> we have vim, emacs and... ed?
<sistpoty> bryce: if I grab a daily and install the new x11-common inside the livefs, and then do a gdm restart, will that trigger the x autodetection, or will that pick up remains of the previous xorg.conf?
<bryce> sistpoty: after installing in the livefs, run `sudo dexconf`and that should regenerate the xorg.conf
<bryce> heh s/should/will/
<sistpoty> bryce: ok, thanks. will do a test tomorrow at work ;)
<bryce> awesome, thanks
<kirkland> evand: ping
<kirkland> evand: I have drafted a Blueprint and a Spec for the SwapfileAtInstallation item.  I'm hoping you'll give it a review?
<kirkland> cjwatson: you too :-)
<kirkland> evand: cjwatson: https://blueprints.edge.launchpad.net/ubuntu/+spec/swapfile-in-the-installer -> https://wiki.ubuntu.com/SwapfileAtInstallation
<evand> kirkland: will do
<pwnguin> kirkland: is swapfile really just as fast as swap partition?
<kirkland> evand: thanks, i'll send an email
<evand> kirkland: FWIW, Python is not available in d-i.
<evand> ok
<pwnguin> im not sure it really matters, but i donno, sometimes baldfaced assertions are wrong
<kirkland> pwnguin: supposedly, yes, in Linux 2.6.* kernels
<kirkland> evand: okay, i'll make that just shell
<kirkland> pwnguin: i linked that statement to an lkml post
<kirkland> pwnguin: i'll try to find something more authoritative, perhaps benchmarks
<pwnguin> kirkland: thats what im saying. he just says its so.
<pwnguin> cool
<kirkland> evand: python removed
<kirkland> pwnguin: how about http://lkml.org/lkml/2005/7/7/326 from akpm ?
<pwnguin> kirkland: so the kernel wont grow swapfiles automatically?
<kirkland> pwnguin: don't think so...  you dd some amount of disk space to a file, and mkswap to format it, and swapon to tell the kernel about it
<kirkland> pwnguin: i'll have to do some test/research to see if it can use sparse files
<kirkland> pwnguin: my gut says "no", but i've been surprised before ;-)
<pwnguin> the mail specifically said no, so unless it changed
<kirkland> pwnguin: right, mail is from 2005
<kirkland> pwnguin: part of what I'm suggesting are a couple of simple, command line userspace tools to do the swapfile resizing, and as those are verified for correctness and stability, potentially creating a userspace daemon to handle the auto resizing
<pwnguin> kirkland: alright. just thinking about some fun I had where i needed to resize swap for hibernate
<kirkland> pwnguin: right, well hibernate is one of the "outstanding issues" ....
<kirkland> pwnguin: ubuntu doesn't yet support hibernate-to-swapfile
<kirkland> pwnguin: that's a related item that needs to be solved
<kirkland> pwnguin: see Bug #83325, where BenC says that the kernel pieces are there, we just need the userspace bits
<ubottu> Launchpad bug 83325 in initramfs-tools "add support for software suspend with swap files" [Wishlist,Confirmed] https://launchpad.net/bugs/83325
<kirkland> BenC: speaking of, ping....
<Burgundavia> mdke: you around?
<BenC> kirkland: Hey...userspace bits are mostly done there, except the crash program to extract a stripped dump file for apport usage
<BenC> kirkland: what else was there?
<mdke> Burgundavia: i am now
<kirkland> BenC: oh, i was going to modify the description/title of the bug report https://bugs.edge.launchpad.net/ubuntu/+source/initramfs-tools/+bug/83325
<ubottu> Launchpad bug 83325 in initramfs-tools "add support for software suspend with swap files" [Wishlist,Confirmed]
<kirkland> BenC: I think it's actually *hibernate*, rather than *suspend* that's broken
<kirkland> BenC: I thought I'd run that by you first, though
<snikker> hi, someones can tell me if the repositories for edgy are broken?
<snikker> no one?
<Burgundavia> snikker: in what sense?
<slangasek> snikker: I can tell you that edgy is end-of-lifed; it hasn't been dropped from the archive centrally, but given that there's no longer any security support for it, it would be a good idea to upgrade
<snikker> Burgundavia: i'm unable to install from universe.... unable to get http://archive.ubuntu.com/ubuntu/pool/universe/m/mingw32/mingw32_3.4.5.20060117.1-1_i386.deb  404 Not Found [IP: 91.189.88.31 80]
<snikker> slangasek: yes i know... i've got edgy in chroot for testing...
<geser> looks like it vanished from the archive, it isn't listed in LP also anymore
<snikker> geser: so there are no way to install anything?
<geser> no, unless you find a mirror which has the needed files
<ScottK> launchpad's purging policy has gotten rather more agressive than it used to be ...
<Burgundavia> snikker: why do you need edgy? why are you not upgrading?
<geser> snikker: you can also dig in LP to download each needed deb manually (they are still there)
<snikker> Burgundavia: it's an old chroot that i use to test application, compile and so on... but maybe it's time to update... My real ubuntu version is hardy
<snikker> geser: in launchpad? ok i try... thank you
<geser> snikker: e.g. https://edge.launchpad.net/ubuntu/edgy/i386/mingw32/3.4.5.20060117.1-1 for the mingw32 deb
<snikker> geser: great! thank you!
<soren> What the..
<soren> infinity: I presume you're aware of the massive chroot problems on the buildd's?
<soren> infinity: E.g. https://edge.launchpad.net/ubuntu/+source/laptop-detect/0.13.6ubuntu1
<infinity> soren: I'm not entirely sure I want to blame the buildds on upstart suddenly wanting to be removed...
 * infinity wonders WTF is going on there...
<geser> sysvinit got renamed
<geser> pitti uploaded already a fixed package but it needs handholding now to get build
<infinity> *sigh*
<infinity> On it.
<LaserJock> anybody happen to know offhand if packages in -proposed can be removed?
<LaserJock> I assume they can be but I'm not positive
<infinity> LaserJock: Yes.
<LaserJock> infinity: thanks
<infinity> soren: Thanks for the heads-up, BTW.  Should be all better (and I'll give-back all the chroot-wait packages) shortly.
<cody-somerville> Changelogs for security packages should really be pushed to the changelog server immediately so people can see they are security updates
<cody-somerville> s/security packages/security uploads
<kees> there's a bug open somewhere for that
<kees> aptitude changelog is handy for avoiding that, though
<bryce> ogasawara: could you take a look at lp #213191?  He mentions that he can't ssh into the box, so I suspect it may be a kernel hang rather than X.
<ubottu> Launchpad bug 213191 in xserver-xorg-video-intel "855GME system freezes when switching to external monitor" [Unknown,In progress] https://launchpad.net/bugs/213191
 * bryce waves to kees
<soren> infinity: Lovely. Thanks for fixing!
<infinity> soren: Well, this all depends on drescher waking the hell up and finishing its publisher run.
<infinity> soren: But we can pretend it's fixed...
<soren> That's what I'm doing.
<infinity> Good man.
<kees> hi bryce :)
<emgent> morning people :)
#ubuntu-devel 2008-06-04
<Keybuk> kees: random thought of the day
<Keybuk> swap-on-RAID1 is insane, right? :p
<kees> insane? no, it's a good idea.
<Keybuk> really, why?
<kees> because if you lose a drive you don't eat your system?
<Keybuk> doesn't md have a performance penalty though?
<kees> people using raid1 generally either have a raid1 swap partition or put swap in a file in the raid'd root fs
<kees> *shrug*
<kees> if you're swapping that much, who cares?  :)
<Keybuk> lol
<Keybuk> a fair point
<kees> what's insane is swap over network block device.  but then lots of things are insane about LTSP.  ;)
<Keybuk> I'm being creative
<Keybuk> I'm setting this machine up so that its 1TB drive is divided into three RAID-1s
<Keybuk> a 256MB for /boot, a 2GB for swap and the rest for LVM
<Keybuk> but no second drive ;)
<kees> for testing, I assume?
<Keybuk> that and future proofing
<kees> if you don't intend to ever hibernate, just but your swap in the LVM
<kees> s/but/put
<Keybuk> it's a file server, so I might want to put a second disk in later and actually do RAID-1
<Keybuk> thus it's most logical to set it up as LVM-on-MD rather than just plain LVM
<kees> aaah, you're doing a degraded raid1?
<Keybuk> is it degraded?
<kees> if you only have 1 drive it is.  :P
<Keybuk> why?
<kees> uhm... because... there's... no mirror?  :P
<Keybuk> RAID-1 can be anything from 1..n drives
<Keybuk> it just happens that most people use 2 :p
<kees> well, I've never tried mdadm --grow -n 2  on a -n 1 array before
<Keybuk> it works
<kees> hah  -n: Setting a value of 1 is probâ
<kees>               ably  a mistake and so requires that --force be specified first.
<kees> cool, yeah, that'll fly.  I've never used it myself.
<Keybuk> I actually saw it on someone else's system
<kees> anyway, in that case, use 2 MDs, one for boot, one for LVM
<Keybuk> and though "damn, that's a _good_ default setup"
<kees> just make swap another lv within the LVM
<infinity> Keybuk: swap-on-raid is not only sane, but really the only way to go for the magical five-nines.
<kees> I tend to buy drives in pairs, so I can add/remove protected md arrays as pvs to my VGs
<Keybuk> kees: why swap-on-LV instead of swap-on-MD ?
<infinity> Keybuk: If your have non-raid swap, when a drive dies, your kernel panics.
<kees> Keybuk: because then it's easier to move around
<Keybuk> kees: but impossible to resume from?
<Keybuk> (in fact, why is it impossible to hibernate to/from it?)
<kees> well, you said file-server.
<kees> I said "if you never hibernate..." earlier somewhere
<infinity> Keybuk: Impossible to restore from an MD/LV swap because the kernel goes looking for hibernate signatures on swap partitions long before we load any MD/LV drivers.
<kees> it is possible, but you have to specify the allocation map
<Keybuk> if we did MD and LVM by default
<infinity> Keybuk: This isn't an unsurmountable problem.
<Keybuk> would you do swap-on-MD or swap-on-LV ?
<Keybuk> infinity: I didn't think the kernel looked at all these days?  we resume by hand in initramfs
<Keybuk> or is it the actual going down bit?
<infinity> (Likewise, hibernating to a swap file is just as doable, we just... Don't)
<kees> I would do swap-on-MD to handle the easy suspend/hibernate case.
<Robot101> I usually have boot on raid1, then the rest of space on LV on raidN, including swap, but then I don't hibernate such multi-disk servers
<kees> Robot101: yeah, that's my case for all the desktop machines in my house
 * kees needs to find a cheap laptop with 2 harddrives.  :)
<Robot101> and by boot, I usually just take 10GB for / and anything like /var or /home that gets big goes onto the LV
<Keybuk> Robot101: you have / rather than /boot ?
<infinity> Keybuk: Oh, indeed, we do go looking ourselves these days.  So it's more a question of load order and such.
<infinity> Keybuk: No reason we couldn't support resuming from crazy MD/LV setups, as well as from swapfiles read from a readonly root.
<infinity> Keybuk: Just would take a bit of code and thought.
<Keybuk> infinity: I'm not entirely sure it would require code anymore :p
<Keybuk> it might just require a busy loop
<Keybuk> or, better yet, a rethink of initramfs so that "mountroot" and "resume" aren't totally separate ways to go
<infinity> Keybuk: At the very least, we need a way for resume= to be slightly smarter than just "a partition identifier".
<infinity> (For the "suspend to swapfile" option, especially)
<infinity> And swap files tend to be the more elegant solution for a lot of interesting use-cases.
<infinity> (No one tell Microsoft I said that, though...)
<Keybuk> agree
<Keybuk> but then I'd say the same for root= ;)
<infinity> Keybuk: Well, given the amount of crazy logic we can stuff in initramfs, I suppose there's no reason root= couldn't be a pointer to a file on $random_filesystem.
<infinity> Keybuk: Not sure how often I'd use that feature, but if we write the code for resume-from-swapfile, we kinda get root-on-file for free.
<infinity> (ish)
<Keybuk> you should be able to say root= some magic string that defines a unionfs of two loop-mounted filesystems on a partition named by uuid
<Keybuk> then we wouldn't need to special case things like the live cd and wubi
<infinity> Voobee!
<infinity> Is it wrong that the only thing I took home from that presentation was the pronounciation?
<calc> so the platform meeting will be tomorrow at 5pm?
<calc> er 2200 UTC
<TheMuso> calc: If there is anything worth discussing. Your question is the first mention of it I've seen outside of what Colin said.
<Keybuk> I hate d-i
<Keybuk> "Failed to determine the codename for the release."
<nxvl> Keybuk: why?
<Keybuk> W. T. F.
<nxvl> heh
<nxvl> sometimes bugs happend
<calc> TheMuso: ok
<Keybuk> nxvl: this is the hardy release!
<nxvl> on a hardy instalation you mean?
<nxvl> i thought it was on intrepid tests
<nxvl> :S
<Keybuk> yeah hardy server i386
<Keybuk> it's probably my error
<Keybuk> in fact, I really can't see why
<Keybuk> others have reported it
<Keybuk> and cjwatson told them to follow the docs :-/
<Keybuk> which is what I thought I'd done
<Keybuk> evand: any ideas?
 * Keybuk cheats
<Keybuk> when in doubt, live edit the installer code to work around the issue
<nxvl> popey: ping
<Robot101> Keybuk: yeah I just take 10GB for /. once you split mail, home and service data out of /, the actual amount of space you need for the actual software on a server is very small
<persia> (unless it's a game server)
<Robot101> well, obviously anything you expect to be large you can allocate out of the LVs
<Robot101> like make a spacious /srv or something
<Keybuk> I just have / 1TB so I don't have to worry about it ;)
<Robot101> Keybuk: well, this pattern is flexible for varying workloads - hosting VMs whose root FSes are LVs anyway
<Robot101> Keybuk: and changing the RAID stuff around, adding more disks etc, growing with LVM is always easier
<Robot101> Keybuk: also I like the way I can shuffle the disks, or take any one of them, and boot the system still
<ogasawara> bryce: sorry for the delay, I've posted a comment to bug 213191
<ubottu> Launchpad bug 213191 in xserver-xorg-video-intel "855GME system freezes when switching to external monitor" [Unknown,In progress] https://launchpad.net/bugs/213191
<bryce> ogasawara: thanks
<MachinTrucChose> Hi. Can someone tell me why using Install New Language to install french-language support in Kubuntu downloads the Thunderbird package? Why would a language pack require you to download a mail client?
<wgrant> Erk, something went wrong in a dependency resolver somewhere.
<wgrant> language-support-fr pulls in thunderbird-locale-fr, which shouldn't need thunderbird unless language-support-fr isn't installed, which it is about to be.
<MachinTrucChose> well, it downloaded the full thunderbird-2.0.0.14 etc, took forever too :)
<MachinTrucChose> I guess the locale had the main program listed as a dependency?
<wgrant> thunderbird-locale-fr has a 'thunderbird | language-support-fr' dependency.
<calc> cody-somerville: ping
<wgrant> So the fact that you're installing language-support-fr should satisfy it.
<calc> cody-somerville: not sure if you saw my response about the xubuntu OOo bug
<wgrant> But it apparently decides it needs thunderbird too.
<cody-somerville> calc, link?
<MachinTrucChose> I see, thanks for the info
<calc> i forgot the bug number already
<calc> you responded to it a few hours ago its the one about openoffice.org-gtk needing to be installed under xubuntu
<cody-somerville> Yes
<cody-somerville> That isn't a Xubuntu-meta bug
<calc> i reassigned it to xubuntu-meta since xubuntu needs to seed that if it wants it
<calc> its not something wrong with OOo
<cody-somerville> That isn't the bug
<calc> oh?
<cody-somerville> He was installing from add/remove
<cody-somerville> You should read the bug description not just the bug title ;]
 * cody-somerville goes back to watching House. :)
<calc> ah he manually installed OOo
<calc> ok its not a bug at all then
<calc> i just marked it invalid
<cody-somerville> I wouldn't be so quick to dismiss it.
<cody-somerville> You should really mark it as a bug of the add/remove app
<cody-somerville> and mark it wishlist
<calc> the add/remove app autoinstalls things you don't request it to, that aren't depends?
<persia> It doesn't (although it will support Recommends: as well at some point)
<calc> i was under the impression it was just a slightly prettier package manager that lists per applications folder
<calc> so it would probably need some kind of ugly hack to support installing packages based on the flavor of *buntu
<cody-somerville> calc, It wouln't be the flavour of ubuntu
<cody-somerville> It would be based on the desktop environment
<calc> true, it is just normally they are linked :)
<persia> That's even harder to determine than the flavour.
<cody-somerville> persia, Lets let the add/remove folks figure it out
<cody-somerville> s/lot/worry
<cody-somerville> erm
 * calc thinks the user should just install what they want
<cody-somerville> It isn't clear
<persia> cody-somerville: Erm.  I've been looking at that code.
<cody-somerville> The user shouldn't have to install open office writer and then some other package to make it look integrated.
<persia> What's the bug number?
 * calc already deleted the email :-\
<cody-somerville> One second.
<cody-somerville> https://bugs.edge.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/236265
<ubottu> Launchpad bug 236265 in xubuntu-meta "[hardy] openoffice.org-gtk should be automatically installed in Xubuntu" [Undecided,Invalid]
<cody-somerville> calc, It is not a bug in xubuntu-meta and not a bug in "xubuntu in general"
<persia> It's an issue with the data contained in app-install-data.  Where that data comes from is different.
<persia> It's not a bug in xubuntu-meta, as it's not installed by default, so it oughtn't be seeded.
<persia> It may be a bug in OO.o, but only in the syntax of some of the .desktop files.
 * cody-somerville nods.
<cody-somerville> persia, My thoughts exactly.
<persia> Also, there likely ought to be a gtk-app-install, for xubuntu, as otherwise the gnome hints will apply.
<cody-somerville> I filed it against app-install-data-ubuntu since calc keeps removing it from OpenOffice
<persia> cody-somerville: I'm still looking, but I'm very much leaning towards the problem being a lack of a specialised app-install for Xubuntu, rather than an issue with OO.o.
<persia> Anyway, without such an app, it's *really* hard for calc to fix it.
<persia> Ah, no, it's not a bug in OO.o at all.
<persia> The OO.o install hints are hardcoded in app-install-data, because there are so many ,desktop entries.
<cody-somerville> ah.
<persia> So, there are two bugs: the lack of a gtk-app-install, and a minor patch to menu-data-additional in app-install-data once there is such a program.
<persia> Generating gtk-app-install ought be fairly easy, given gnome-app-install as an example.
<persia> Once that's in place, opening a bug against app-install-data to provide the right hints ought be fine (or they can be overridden in gtk-app-install, depending on the complexity of each task)
<persia> Bug 236265 is likely best set WontFix, unless Xubuntu plans to seek openoffice.org-gtk
<ubottu> Launchpad bug 236265 in app-install-data-ubuntu "[hardy] openoffice.org-gtk should be automatically installed in Xubuntu" [Undecided,New] https://launchpad.net/bugs/236265
<persia> s/seek/seed/
<persia> cody-somerville: Does that give you a roadmap, or do you need more information?
<ion_> Plain rebuild was enough for vim to get linked to libperl5.10.
<Hobbsee_> Afternoon all
<ajmitch> greetings
<ion_> Howdy
<wgrant> Evening.
<Hobbsee_> wgrant: no, it's not evening.
<ion_> Yes, it is.
<wgrant> It's close enough.
<calc> sorry for bouncing the bug around so much, but i'm glad someone who knew how it works saw it :)
 * calc hugs persia 
<ajmitch> wgrant: yet certain people in your timezone probably just woke up
<Hobbsee_> sigh, chroot problems.
<wgrant> ajmitch: Perhaps so.
<persia> calc: Mind you, I'm not happy about the fact that OO.o assumes it will be seeded.  Around half our derivatives don't, and it can be confusing when optimising for Ubuntu :)
<calc> persia: well the other option is to just force people to install everything, but then people complain it takes too much space, etc
<calc> because if you ask enough people they want all the features in OOo
<calc> but that is really large and definitely wouldn't fit on an install cd
<persia> calc: For those people who want OOo, I agree.
<persia> On the other hand, for mythbuntu or Ubuntu Studio, I'm less sure it makes sense.
<calc> it shouldn't be getting installed on ubuntu studio at all, there is a bug in the lang packs stuff though
<persia> I think it's a hard problem, and that it will take a while to find something that works.
<calc> but for users that want to install it on ubuntu studio they would currently have to know what to install for what they want of it
<persia> calc: Right, which is the hard problem.  app-install-data only provides a single hint, as OOo doesn't expose one cleanly.
<calc> eg you could install openoffice.org metapackage and it would recommend (depends on the package manager) ooo-kde and ooo-gnome, etc
<persia> As a result, it's tricky to later install OOo-kde or OOo-gtk, rather than OOo-gnome.
<calc> is there a way to expose a hint without forcing it to be installed eg a depends?
<persia> That gets into the parts of Add/Remove I don't know so well :)
<calc> if so i can modify OOo packaging to give hints, if there is a clear way to do this
<calc> ok
<persia> It has to do with special tags in the .desktop files.
<calc> well to use gtk/gnome/kde integration wouldn't be specific to a desktop file at least aiui
<persia> You might ask mvo later, if you have time.  On the other hand, right now it only really affects Xubuntu, and a hack in gtk-app-install might be good enough.
<calc> ok
<persia> calc: Well, it's the .desktop file for the app installer vs. the .desktop file for the application itself.  In many cases, these are the same.  It may not be possible to have these be the same for OOo.
<calc> oh ok
<persia> calc: If you want to dig, compare /usr/share/app-install/desktop/ooo-meta.desktop as an example of such a hint
<pitti> Good morning
<ajmitch> hi pitti
<pitti> Keybuk: oh, no Vcs-Bzr: for upstart? you do keep it in bzr, I take it? I'd like to fix the Pre-Depends: for sysvutils -> sysvinit-utils; or do you want to do that yourself?
<dholbach> good morning
<\sh> hey dholbach
<dholbach> hi \sh
<\sh> hmmm.wtf? temp removal of sysvutils during dist-upgrade...which breaks the upgrade path...was it a wish? :)
<pitti> \sh: I think we need to fix upstart's Pre-Depends: on sysvutils; see my ping to Keybuk earlier on
<\sh> pitti, no backlog...but if it's known everything is fine :)
<Hobbsee> Keybuk: ping?  :)
<Hobbsee> Keybuk: wait. you're techboard.  unping.
<Hobbsee> ah, darn, and htere was no CC quorum.
<PecisDarbs> hi people, could it be that AppArmor on 8.04 forbids to write to /sys with sudo command?
<pitti> PecisDarbs: not by default
<arthur-> munckfish: I'll be fine thanks. I don't know yet, I haven't contributed to Ubuntu for a while now
<PecisDarbs> damn then
<pitti> PecisDarbs: look at the output of 'dmesg' to see the AppArmor erros
<PecisDarbs> ok
<munckfish> arthur-: hi, glad to hear it, so you're primarily a debian guy?
<arthur-> munckfish: definitely yes
<munckfish> arthur-: ok cool. Well I'm happy to be responsible for these sorts of packages in Ubuntu it would be good if we could work together to make sure there's no wasted effort between the two projects
<arthur-> munckfish: sure, do you like git ?
<munckfish> arthur-: I love git. But I'm still at Git kindergarten really :D
<arthur-> munckfish: cool, we'll talk about all that later ;-)
<munckfish> arthur-: ok grab me whenever
<mohbana> hi
<pitti> tseliot: do you know what DEST_MODULE_LOCATION in dkms.conf is for? it seems to be ignored, and all .kos actually land in /lib/modules/`uname -r`/updates/dkms/ ?
<mohbana> hi i've got a question about fonts in unbutu
<tseliot> pitti: let me quote the man page "Currently,  DKMS  searches
<tseliot>        for  these  original  modules  with  first  preference going to modules
<tseliot>        located in /lib/modules/<kernelversion>/updates/ followed by $DEST_MODâ
<tseliot>        ULE_LOCATION  (as  specified in dkms.conf ).  If one cannot be found in
<tseliot>        either location, a find will be used to locate one for that kernel.  If
<tseliot>        none  are  found,  then  during a later uninstall, your kernel will not
<tseliot>        have that module replaced."
<tseliot>  If more than one is found, then the first one  located  (by  preference
<tseliot>        indicated  above)  will  be considered the "original_module".
<tseliot> pitti: the one in updates is what will be loaded
<mohbana> anyone here/
<pitti> tseliot: ah, so it is not actually the path for the kmod to be installed, but the older kmod to be *replaced*
<tseliot> pitti: yes, exactly. In this way DKMS knows where's the original
<tseliot> and can make a backup
<pitti> tseliot: aah; that might explain something; thanks!
<tseliot> pitt: I know that the fact that it's called "DEST" might suggest that it refers to the destination of the new module ;)
<pitti> right, that's what confused me; the man page section about this parameter isn't very helpful
<tseliot> pitti: I'll be your human man page :-P
 * pitti updates his dkms.conf autogeneration script for that
<mohbana> what exactly does ubuntu do to it's fonts  to make them look so good?
<mohbana> i am getting totally ignored
<mvo> pitti: have you seen #237276 ? I haven't investigated yet what the problem is exactly, I'm curious if you have seen it before?
<pitti> mvo: I can only guess that it is due to upstart's Pre-Depends:
<pitti> mvo: I pinged Keybuk about it (need to coordinate with him for bzr0
<PecisDarbs> hi people, where I can find patches for Ubuntu kernel? in debian directory of source?
<pitti> PecisDarbs: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary
<mvo> pitti: ok, I milestoned it for alpha-1
<pitti> mvo: assigned to me, thanks
<mohbana> i take it David Turner himself is maintaining freetype on the ubuntu repos?
<mohbana> :)
 * mvo hugs pitti
<Ademan> hey would i be ill-advised to use xorgconfig.py ?
<Ademan> /usr/share/python-support/guidance-backends/xorgconfig.py   to be specific
<tseliot> ï»¿Ademan: it's Guidance. What are you trying to do with it?
<Ademan> tseliot: not have to write my own code to parse xorg.conf
<Ademan> what do you mean it's guidance? i see it being used by displayconfig-gtk
<Riddell> seb128: how many gnome point releases are usually done?
<tseliot> Ademan: that file is part of Guidance i.e. a backend. I don't think it's maintained any longer.
<Riddell> Ademan: displayconfig-gtk is a gtk frontend to kde-guidance's displayconfig
<pitti> Ademan: it's shipped in guidance-backends, and used by other packages as well
<pitti> Ademan: it works, but the API is not very convenient nor robust
<Riddell> Ademan: these days you should probably be using xrandr rather than reading xorg.conf
<Ademan> pitti: hrm, well, considering i'd rather not get friendly with flex and bison right now... i think i'll use it
<Ademan> Riddell: not for display actually, for input
<pitti> Ademan: oh, yeah, it's miles ahead of writing your own :)
<Ademan> gonna see if i can't cook up something convenient for lots-o-button-mice
<seb128> Riddell: you mean during the unstable cycle? or stable updates?
<Ademan> well thanks guys, later
<Riddell> seb128: stable
<seb128> Riddell: 3
<seb128> until .3 rather
<Riddell> seb128: right, and those are monthly?
 * pitti fixes SpecTemplate to have a standard header again (UbuntuSpec:, contributors, affected packages, etc.)
<seb128> that's not a fixed monthly schedule but roughly yet
<seb128> yes
<seb128> 2.22.1 to 2.22.2 was 6 weeks
<Riddell> mm, interesting, thanks seb128
<seb128> they avoid having new stable and unstable in the same weeks so there is some flexibility
<seb128> you are welcome
<Keybuk> pitti: fix to what?
<pitti> Keybuk: sysvutils to sysvinit-utils
<Keybuk> pitti: did you get any explanation from Debian why they renamed the package?
<pitti> Keybuk: they didn't rename it within Debian; it has always been called like this in D
 * pitti goes to reproduce the bug in vmware, and test fixes
<Keybuk> pitti: they renamed it when they took the patch to separate it from us though
<Keybuk> we split it out first
<pitti> right
<Keybuk> I never understood why they didn't use our name?
<pitti> neither have I
<pitti> just cosmetical reasons, I guess
<Keybuk> "Not Named Here" :)
<bullgard4> "detlef@MD97600:~/gnome$ apt-get source apport" obtains 191kB but complains: "gpg: Signatur am Sa 17 Mai 2008 14:07:51 CEST mit DSA SchlÃ¼ssel, ID 5E0577F2, erfolgt; gpg: Unterschrift kann nicht geprÃ¼ft werden: Ãffentlicher SchlÃ¼ssel nicht gefunden." How can I make gpg to find the public key?
<pitti> ugh, apt-get source verifies signatures?
<Keybuk> pitti: what's the right way to do a XS-VCS-Bzr ?
<pitti> Keybuk: Vcs-Bzr: https://code.launchpad.net/~ubuntu-core-dev/upstart/ubuntu
<pitti> or so
<pitti> Keybuk: no XS- any more
<pitti> Keybuk: http://bazaar. works as well (that's the code browser)
<pitti> bzr get works with either
<Keybuk> hmm
<Keybuk> weirdly, the header is in bzr
<Keybuk> but doesn't show up in the source package
<pitti> Keybuk: I don't see it in the apt-get source'd upstart
<Keybuk> no, that's what I mean
<Keybuk> pitti: bug# for the sysvutils issue?
<pitti> Keybuk: bug 237276
<ubottu> Launchpad bug 237276 in sysvinit "hardy->intrepid upgrade fails because of sysvinit pre-depends loop" [High,In progress] https://launchpad.net/bugs/237276
<pitti> Keybuk: my vmware is still upgrading (ugh, 130 MB to download)
<Keybuk> ok, done
<pitti> Keybuk: cheers
<Keybuk> hopefully the bzr header should show up now
<Keybuk> OOI, how do you manage it?
<Keybuk> do you apt-get source the package, then checkout the debian directory wiping what's there?
<pitti> Keybuk: just debuild -S it and check the .dsc
<siretart> FYI, bzr-builddeb 0.95 is able to do this: `bzr bd -S https://code.launchpad.net/~ubuntu-core-dev/upstart/ubuntu`
<Keybuk> no, I mean, how do you handle debian-in-bzr ?
<pitti> Keybuk: usually debcheckout -a, and then unpack the orig.tar.gz, yes
<Keybuk> ah, and you put debian one-level-down ?
<pitti> learning bzr-builddeb is a long-standing TODO item of mine...
<siretart> Keybuk: just add the --merge option. done.
<pitti> Keybuk: right, I have .bzr/ in the top level dir
<Keybuk> my current recipe is:
<Keybuk>   apt-get source upstart
<Keybuk>   cd upstart-0.3.9
<pitti> Keybuk: erm, s/right,/no/
<Keybuk>   bzr checkout ~/co/upstart/debian
<pitti> (common practice on alioth)
<Keybuk> (for no readily apparent reason, if you checkout, it puts the .bzr into an existing working copy :p)
<Keybuk> I'd rather just put the whole source in, but bzr doesn't like that much
<siretart> in what way?
<Keybuk> siretart: it thinks it doesn't have to care about timestamps
<Keybuk> first time I tried it, it upset automake
<siretart> interesting
<Keybuk> I've proposed that bzr applies the same timestamp to all files modified by any operation
<Keybuk> ie. after checkout, the entire tree would have the same timestamp
<Keybuk> and after an update, only the changed files would have a new timestamp (and the same as each other)
<Keybuk> ?!
<Keybuk> now dpkg-buildpackage is randomly exiting on me
<Keybuk> tkamppeter_: interesting, on a completely fresh Hardy install, I just ran hp-setup and my printer appears to work
<Keybuk> it must be something left behind by it working on gutsy and before that's breaking it on hardy?
<sistpoty|work> bryce: can you also make x11-common available in your people dir? (iirc dexconf is in there, at least not in the both .debs that are in your dir)
<sistpoty|work> bryce: oh, and maybe you shouldn't publish the signed .changes file right next to the source package (that way everyone can upload that to ubuntu proper)
<Keybuk> tkamppeter_: hah! it works right up to the point I try and print from another machine
<siretart> sistpoty|work: ha, just upload it! :-)
<sistpoty|work> tststs ;)
 * Keybuk considers adding -Werror to package flags
<Keybuk> it'd be kinda nice to not even allow the buildds to accept warnings
<soren> For sufficiently mind-numbing interpretations of "nice", yes.
<persia> This ought be selectable, as the number of new FTBFS cases in universe may be large
 * soren thinks "large" is an understatement
<soren> Keybuk: You wouldn't happen to have any idea about the scale of the percentage of packages that would ftbfs with -Werror, would you?
<seb128> soren: too many
<soren> I'm guessing  at least 90%.
<seb128> not that bad
<persia> Well, maybe 80%.  Lots of code isn't actually C.
<soren> No?
<seb128> rather 10% I would say
<soren> Because they don't actually have warning, or because they'd override -Werror?
<seb128> but maybe I'm biaised and GNOME is much better than the rest of the world ;-)
<persia> That's still 1500 packages that need fixing: about the total size of maintained universe.
 * ogra is on the 10% side 
<Keybuk> soren: I was just thinking of doing it for one package
<seb128> soren: because they don't have warnings, I think many GNOME component have -Werror set when building from svn, they just turn it off for tarballs
<soren> Keybuk: Oh. :)
<persia> One package is a good idea :)
<persia> (Maybe even 10 or so)
<soren> seb128: I just picked two completely random gnome packages. Both have warnings (gnome-panel and libgnomeui).
<seb128> soren: weird, the libgnomeui build on my disk has no warning
<soren> http://launchpadlibrarian.net/13285398/buildlog_ubuntu-hardy-i386.libgnomeui_2.22.1.0-0ubuntu1_FULLYBUILT.txt.gz
<soren> Not a lot, though.
<seb128> weird
<pitti> calc: hm, no SRU bug in the OO.o changelog
<pitti> calc: where is it tracked?
<Hobbsee> on very small fragments of post-it notes
<Hobbsee> hence the lack of numbers
<pitti> Keybuk: hm, seems amd64 didn't like your PIC changes in upstart
<Keybuk> pitti: indeed
<Keybuk> I saw that
<Keybuk> I'll let kees cry about that when he wakes up ;)
<Keybuk> since it works fine on my amd64 here
<\sh> asac, bug #131793 -> why invalid when there is no real solution for gutsy users? :)
<ubottu> Launchpad bug 131793 in firefox "firefox crashed" [Medium,Invalid] https://launchpad.net/bugs/131793
<norsetto> is it just me or there is somethign wrong with libglib2.0-data?
<asac> \sh: i did a batch closing a bunch of crashers that had no dupes and appeared to not be reproducible anymore
<asac> \sh: you can reopen it if oyu provide a backtrace
<asac> is it just gutsy?
<\sh> asac, hardies ff3 crashing too...
<\sh> just tested
<asac> => update bug ... attach backtrace, reopen, confirm :)
<\sh> asac, you want apport stuff or just plain gdb bt full?
<ogra> its probably because spiegel wants you to buy the paper version :)
<\sh> ogra, lol
<ogra> secret intrigue between ff and spiegel ;)
<asac> \sh: the comment suggests that the apport retrace was invalid. so getting a backtrace locally with dbgsym installed should work
<seb128> norsetto: it's just you?
<\sh> asac, just trying to make it crash again running in gdb
<seb128> norsetto: but let say that your comment is not really descriptive about your issue
<pitti> soren: hm; if I accept the new u-vm-builder now, that'll reset the 7 days testing period of the current -proposed one
<pitti> soren: any chance you could collect some test results on the current one, so that it can move to -updates first?
<soren> pitti: That's ok.
<pitti> soren: otherwise testing will get messy
<soren> No.
<norsetto> seb128: dunno, in intrepid something seems to be dragging in 2.16.3-2 which doesn't exists
<soren> I don't want the one in -proposed to land in -updates.
<soren> I deliberatly didn't wait.
<seb128> norsetto: --verbose?
<norsetto> seb128: thats as much as I can say now
<soren> pitti: It causes a quite severe regression.
<pitti> soren: ok; any chance you could reupload with using -v then, to cover the previous changelog in the source.changes, too?
<asac> \sh: remember to install dbgsym for cairo and gtk and such things too
<pitti> soren: ok, understood
<soren> pitti: Oh, so it has the entries from 0.2 and 0.3? Sure, that makes sense.
<\sh> asac, you have a list? ,)
<pitti> soren: thanks
<seb128> norsetto: seems that the binary went to universe for some reason
<soren> pitti: What about 0.1? It was a -security upload, so I'm not sure how to treat that.
<pitti> soren: that's fine; just the previous -propsoed upload and your new one
<pitti> i. e. -v...0.1
<asac> \sh: good start is https://wiki.ubuntu.com/MozillaTeam/Bugs under crashes
<soren> pitti: Great. Gimme a few minutes.
<seb128> norsetto: oh, it's simply to universe, that's not new, but now recommends are installed and libglib2.0-0 recommends it
<\sh> asac, well...if I really have 5 lines with something like #1  0xb72931f2 in ?? () from /usr/lib/xulrunner-1.9b5/libxul.so and one libc line..
<seb128> norsetto: where does it create an issue?
<\sh> for the bt full ...
<norsetto> seb128: yes, but why 2.16.3-2?
<asac> \sh: maybe gdb doesnt find the xulrunner dbgsymbols?
<asac> maybe LD_LIBRARY_PATH tweak helps?
<seb128> norsetto: what do you do to get this version mentionned?
<\sh> asac, yes...because I need to install them...but I don't want to install the other crap...do you agree, that it could be xulrunner directly?
<asac> \sh: hard to say
<\sh> asac, ok...working the way down...:)
<asac> if here are other libs in the trace try them too
<asac> cool
<\sh> asac, libc and xulrunner only...
<Keybuk> pitti: so I was thinking
<Keybuk> how do we make it so you can plug USB storage devices into a server?
<norsetto> seb128: I'm just building a package in a pbuilder chroot, if I login and do "apt-get install libglib2.0-0" it also tryes to install that version
 * ogra hears pmount scratch on its coffin
<seb128> norsetto: what architecture?
<norsetto> seb128: amd64
<seb128> norsetto: apt-cache policy libglib2.0-0?
<pitti> Keybuk: you mean with automount?
<norsetto> seb128: Candidate: 2.16.3-2
<seb128> norsetto: your mirrror seems to be broken
<pitti> ogra: rather something that looks like gnome-mount -vbt
<seb128> norsetto: current is 2.17.0-1
<norsetto> seb128: well, its archive.ubuntu.com
<seb128> norsetto: you ran apt-get update?
<norsetto> seb128: yes, since about 3 hours
<\sh> norsetto, there are at least three servers behind a.u.c. could be that one is not updated properly yet
<norsetto> \sh: since 3 hours? Then there is something wrong with one of the 3
<\sh> norsetto, nslookup archive.ubuntu.com and check them manually
<\sh> norsetto, yes..we had that when hardy was released...could be that it comes back ;)
<norsetto> \sh: seems to be 91.189.88.45
<seb128> norsetto: using archive.ubuntu.com the current version on amd64 intrepid is 2.17.0-1 on my installation
<norsetto> seb128: which of the 3 are you pointed too?
<seb128> norsetto: dunno
<Keybuk> pitti: well, with New World Order stuff
<Keybuk> I can plug it in on a desktop, and it gets mounted
<Keybuk> but same doesn't apply when I plug it in on a server
<pitti> Keybuk: right; no ConsoleKit schema on servers, etc.
<Keybuk> nor user policy agent to actually do the mounting?
<pitti> I'm not sure about how automounting semantics should be on a server TBH
<pitti> or whether it's generally desired on a server in the first place
<Keybuk> me neither
<Keybuk> it's desired in some cases
<Keybuk> e.g. media server
<pitti> should it be read/writable for everyone? just for root?
<soren> Keybuk: In that case the "media" part of it should manage it. Like mythtv or whatever.
<Keybuk> soren: but there's no common component for them to depend on
<Keybuk> the "media" bit shouldn't NIH the same bit as "desktop" or "storage", etc.
<soren> Didn't hal grow these capabilites at some point?
<Keybuk> my case is that I have a nice squat file server which has some USB ports on the front
<\sh> asac, bug updated :) with the infos
<Keybuk> it'd be quite froody if I could plug a USB key, and have that automatically shared ;)
<ogra> soren, needs a mounter binary
<Keybuk> soren: I'm not sure I recall how it's split between HAL, gnome-mount, Nautilus and gnome-volume-manager
<ogra> soren, in case of the desktop its gnome-mount ... for server you need something else which doesnt exist
<pitti> soren: hal can do the mounting, etc, and knows when devices appear
<soren> Hm... I guess that for "real" filesystems (ones with uid's and stuff) they could just get mounted. There's no ownership settings to worry about since they're specified by the file system.
<pitti> soren: but you need something to "connect" the "new device" and "plz mount it for me with those options"
<pitti> soren: unix fses> right
<Keybuk> really? see I'd say unix fses are the bad ones because you can't squash the permissions
<Mithrandir> soren: though, that requires you to have the same UIDs around the place.
<soren> Mithrandir: Sure.
<soren> Mithrandir: The point is that there's nothing you can (currently) do about that anyway. You either mount it or don't.
<soren> There's no need to decide who gets to own it, what the permissions should be, etc.
<norsetto> seb128: ok, got the problem, pbuilder update is failing because of sysvutils
<soren> I think I still have a patch somewhere against linux 2.4 that actually adds some kind of squashing capabilities here.
<Mithrandir> Keybuk: squashing is easy-peasy, just use fuse to mount it.
<pitti> Keybuk: which is pretty much what I want if I use my home server which just has an USB hard disk :)
<seb128> norsetto: ah, that explains
<Mithrandir> soren: sounds easy enough to do.
<soren> You could provide a mappings file to mount that would translate UID's and GID's in the vfs layer.
<pitti> soren: however, what to do with vfat, ntfs, udf?
<asac> \sh: can you ttest the -proposed package too please?
<asac> e.g. 3.0rc1 (you have 3.0b5)
<asac> (sorry thought you were running proposed)
<\sh> na...I don't run proposed....:)
<soren> pitti: I don't think ubuntu server should do anything by default with those.
<norsetto> pitti: was the sysvutils problem solved? Apparently pbuilder update still fails because of it
<soren> I understand the media server use case, though.
<asac> \sh: for me it doesnt crash here on RC1
<pitti> norsetto: updated upstart was just uploaded about two hours ago, but still FTBFSed on amd64; it might be solved nowish for i386
<asac> so maybe its fixed
<asac> either test or lets wait till you get that to confirm
<norsetto> pitti: ahh ok!
<asac> before reporting upstream
<\sh> asac, preparing for -proposed :)
<asac> great
<soren> brb
<\sh> asac, right..it doesn't crash anymore with proposed version
<asac> cool
<\sh> asac, do you actually have an updated gutsy version available to test?
<asac> \sh: updated ? you mean in -backports? prod jdong about that. he usually did the backports
<asac> havent heard from him for this update yet.
<\sh> asac, na...ff2 :)
<asac> you mean 2.0.0.15pre?
<\sh> dunno what's latest in gutsy...but I can ask the guy who can test it ;)
<asac> \sh: ask him. we update on each and every upstream security release
<asac> current version should be 2.0.0.14 if i am not mistaken
<asac> thanks
<tkamppeter> Keybuk, what is your printer problem? I have seen something which you told about your printer.
<asac> \sh: ok added firefox-3.0 target as fixcommitted and kept firefox target at confirmed for now. usually i would put it back to incomplete when asking to test latest :)
<asac> doing that now ;)
<\sh> asac, well, people don't use -proposed in production environments ;) they are not as crazy as I am ;)
<asac> \sh: yeah. thats why its fixcommitted not released
<\sh> asac, I wonder if someone fixed it in rc1 if there is somewhere a upstream bug report...
<asac> \sh: most likely
<asac> we have hundreds of crashers. maybe there are even dupes in LP that have the right upstream bug
<Keybuk> tkamppeter: HP LJ 1018 barely working
<\sh> just found an old one from 2004 in bugz*.mz.o ;)
<Keybuk> nine times out of ten, it just doesn't print
<Keybuk> with the error that the printer isn't connectde
<asac> \sh: launchpad search for "crash print" that are either open or fixed upstream yielded bug 217032
<ubottu> Launchpad bug 217032 in firefox-3.0 "firefox crashed with SIGSEGV in __kernel_vsyscall() when I was printing" [Undecided,Confirmed] https://launchpad.net/bugs/217032
<asac> \sh: that one is fixed upstream, so maybe a good dupe for this ;)
<\sh> asac, na still open ;)
<\sh> and marked as crit ;)
<asac> \sh: he?
<asac> its fixed upstream
<asac> mozilla bug 429071
<ubottu> Mozilla bug 429071 in GFX: Thebes "firefox crashed [@ snprintf - _cairo_output_stream_vprintf][@ _cairo_surface_set_clip_path_recursive] when I was printing to file" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=429071
<calc> pitti: writing the bug report now, i had forgotten to do it when i got back from vacation
<soren> pitti: Ok, in the media server case... What would be the minimal e.g. mythtv would have to do to make it so that USB storage is automagically mounted and owned by it?
<calc> pitti: i think i have it targeted properly
<pitti> calc: could you upload a new diff.gz/dsc with the bugs referenced?
<pitti> calc: thanks
<asac> \sh: mozilla bug 429678 is similar. but both appear to be fixed in cairo. not sure if that is our bug
<ubottu> Mozilla bug 429678 in GFX: Thebes "Crash [@ _cairo_surface_set_clip_path_recursive] with failed printing of outset border with transparency" [Critical,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=429678
<tkamppeter> Keybuk, you are aware of the needed firmware?
<Keybuk> tkamppeter: yes
<pitti> soren: issue the dbus call to hal
<Keybuk> this time round, I've just run "hp-setup" to set it up, and that downloaded things
<calc> pitti: its a "Update OpenOffice.org to 2.4.1" bug
<tkamppeter> Setting it up with hp-setup loads the firmware from the internet
<calc> pitti: we are at rc1 already in proposed
<pitti> calc: oh, I see; it doesn't actually address existing ones in LP?
<pitti> calc: ok; we just need to have a bug to track it then
<soren> pitti: In that case, it doesn't seem at all unreasonable to require the media server solution to handle this, does it?
<calc> pitti: it probably does, but i would have to verify which bugs it fixes, not sure if LP has bugs for all of the bugs it fixes though
<calc> pitti: i made a master bug that i will be documenting what all it fixes and reference the bugs it fixes that are already in LP from it
<pitti> soren: I'm not entirely sure; what happens if two processes want to mount it?
<tkamppeter> Setting it up with s-c-p does not install the firmware, but should work if something else has set up the firmware before.
<soren> pitti: You tell me :)
<\sh> asac, hmmm...we use selfmade cairo right? so I didn't updated cairo
<calc> pitti: when i uploaded the first couple to proposed i was behind on bugmail so some of the bugs it fixes have already been fixed in older (2.4.1) uploads that weren't referenced in the changelog at the time
<pitti> soren: well, they would race against each other
<Keybuk> tkamppeter: the problem is that it gets detected fine, seems to work
<Keybuk> probably even get a test page or two out of it
<tkamppeter> Keybuk, when you turn the printer on you see whether it loads the firmware or not, by the blinking orange lights.
<Keybuk> then why you try and print something useful, like a web page, nothing happens
<\sh> asac, for hardy I just installed the firefox-3.0 packages + xulrunner-1.9 update...
<Keybuk> tkamppeter: solid green light
<soren> pitti: I guess this is something the hal people must have thought about?
<asac> \sh: ok makes sense. the trace doesnt look cairo related anyway
<tkamppeter> Keybuk, yes after the turn-on procedure it goes to solid green light.
<pitti> soren: well, it's not a technical problem really
<Keybuk> tkamppeter: so the firmware bit must be working ok
<\sh> asac, https://bugzilla.mozilla.org/show_bug.cgi?id=263229 <- reported 2004 , last mod: 2007 ;)
<ubottu> Mozilla bug 263229 in Layout "Mozilla locks up / crashes when printing via postscript/default OR xprint Senator Edwards web page" [Critical,New]
<soren> pitti: Depends on how you look at it. HAL could have had a locking mechanism of some kind that would offer the mount point to a list of subscribers in a specific order.
<pitti> Keybuk: can you please propose https://blueprints.edge.launchpad.net/ubuntu/+spec/consolidate-spell-checkers and maybe update the people? I can't propose that one as a goal (I wonder why)
<tkamppeter> Keybuk, for your printer are two drivers available, foo2zjs and hpijs, the latter only if you have set up the printer with hp-setup once (due to a closed-source plug-in, downloaded together with the firmware).
<tkamppeter> Keybuk, have you tried both drivers?
<pitti> soren: on the desktop this is solved by having a central mount agent and only allowing mounts to the foreground console
<Keybuk> pitti: you should be able to propose now
<pitti> but that concept doesn't work well for servers
<Keybuk> tkamppeter: I did try both yeah
<Keybuk> same problem
<pitti> Keybuk: right, works now; thanks
<soren> pitti: What if a another mount-agent came along?
<Keybuk> it feels like whatever makes the job gets it wrong somehow, in a way that the printer doesn't accept
<soren> pitti: Or could there be only one?
<Keybuk> if I fiddle with random things like shrinking the print by 50%, it works
<pitti> soren: in principle there can be several, but it wouldn't make sense to have more than one
<\sh> oh wow...who said that 16M memory for php5 is enough ? :)
<Keybuk> printing two pages to a side also seems to usually work
<tkamppeter> Keybuk, can it be that the USB is perhaps not stable?
<Keybuk> tkamppeter: "the USB" ?
<tkamppeter> Keybuk, I mean that perhaps something needs to be done on the kernel?
<Keybuk> tkamppeter: don't both things just use libusb?
<tkamppeter> Keybuk, even with libusb it goes through the kernel AFAIK
<pitti> seb128: please let me know if you disagree with https://blueprints.edge.launchpad.net/ubuntu/+spec/consolidate-spell-checkers (just assigned to you, since it boils down to sponsoring changes in GNOME packages)
<pitti> seb128: I can do it as well if you prefer
<Keybuk> tkamppeter: only barely
<asac> \sh: is the testcase fixed in that bug? :)
<Keybuk> if things were wrong enough that they broke libusb, most USB things wouldn't work
<soren> pitti: Right, ok.
<seb128> pitti: works for me
<Keybuk> since libusb is basically a pass-through out of the port
<tkamppeter> Keybuk, you can also try two CUPS backends, the "hp" one of HPLIP, which is based on libusb and the "usb" backend from CUPS which is based on the "usblp" kernel module.
<ogra> Keybuk, you have a LJ 1018 ?
<ogra> i have te same around, working just fine
<ogra> *the
<Keybuk> tkamppeter: the USB one with foo2zjs was basically working
<tkamppeter> ogra, you have one, too? How well does it work for you?
<\sh> asac, you mean this mozlogo on the page? when I click on attachment? well, print preview and print do work in rc1 but gives me two pages in the end ;)
<Keybuk> ogra: on hardy, set up automatically or by hp-setup ?
<ogra> tkamppeter, i only prited about five times with it but it worked flawless out of the box
<Keybuk> tkamppeter: I have a vague recollection I had to downgrade foo2zjs to gutsy's version
<ogra> it installed itself after plugging in
<\sh> zul, slangasek : can we discuss to inc the mem limit in php.ini for php5-apache2 module from 16 to something like 16*2?
<ogra> i havent changed anything manually
<ogra> Keybuk, auto ...
<pitti> mvo: if the two-dimensional package groups turn out not to work, do you see any chance to have something like an apt hook for marking additional packages for installation, based on the currently installed and available ones?
<tkamppeter> Keybuk, if you have to downgrade foo2zjs to the Gutsy version, it smells like a bug in foo2zjs.
<Keybuk> ogra: mine usually prints the first page or two after being turned on, then stops
<ogra> hmm, i havent printed books yet but the two three page prints i did this year all worked
<Keybuk> tkamppeter: that downgrade doesn't help with the hpijs method though
<Keybuk> tkamppeter: that simply doesn't work for me ;-/
<Keybuk> the only other piece of interestingness is that this is on amd64
<Keybuk> I might just try this on my i386 hardy box and see if it works
<Keybuk> ogra: are you on i386 or amd64?
<ogra> i386
<ogra> (my laptop)
<Keybuk> interesting
<Keybuk> because on my laptop, this is still working on i386
<ogra> hmm
<Keybuk> tkamppeter: ever heard of amd64-only bugs?
<\sh> Keybuk, HP LJ 1020 USB works like a charm on gutsy+hardy amd64 with cups
<\sh> Keybuk, even with sharing it with a windows os
<mohbana> what exactly does ubuntu do to it's fonts  to make them look so good?
<Keybuk> mohbana: ?
<Keybuk> mohbana: depends which settings you use
<Keybuk> (which reminds me to change the subpixel defaults <g>)
<mario_limonciell> kees, yeah there are two diffs on the bug.  one of them is an SRU for hardy (i already subscribed ubuntu-sru and that diff is to hardy proposed).  the other one is a lot more intrusive and is intended for intrepid
<mohbana> Keybuk: i am talking about the freetype settings, it's using something other than subpixel
<mohbana> i've tried enabling that in fedora but it still doesn't look like ubuntu
<jdstrand> pitti: hi!
<Keybuk> mohbana: right, I mean are you comparing with fonts set at "Best Shapes", "Best Contrast" or "Subpixel smoothing" ?
<mohbana> Keybuk: i just want to know the exact details of what ubuntu does to it's fonts
<jdstrand> pitti: sorry about the same version thing with ufw-- I thought this was allowed because of the new *-blacklist having the same versions. Of course, these were pocket copied. I'll know for next time
<jdstrand> s/these/those/
<Keybuk> mohbana: it depends a lot on which option you select, that's all ;p
<Keybuk> mohbana: in simple terms, we turn on all the patented stuff and apply patches to do LCD filtering when subpixel rendering
<LaserJock> pitti: could you remove the smstools upload in hardy-proposed? there's another SRU and I'd prefer to have everything in one upload
<mohbana> Keybuk: what patches please
<Keybuk> mohbana: http://david.freetype.org/lcd/
<Keybuk> but read http://david.freetype.org/cleartype-patents.html first
<mohbana> wow them patches are really old! does ubuntu still use them?
<Keybuk> mohbana: a better question would be "wow them patches are really old! why haven't upstream applied them?"
<Keybuk> :p
<kees> Keybuk: what exactly exploded with PIE?
<Keybuk> kees: http://launchpadlibrarian.net/14987481/buildlog_ubuntu-intrepid-amd64.upstart_0.3.9-4_FAILEDTOBUILD.txt.gz
<Keybuk> gcc -shared  .libs/alloc.o .libs/string.o .libs/list.o .libs/hash.o .libs/tree.o .libs/timer.o .libs/signal.o .libs/child.o .libs/io.o .libs/file.o .libs/watch.o .libs/main.o .libs/option.o .libs/command.o .libs/config.o .libs/logging.o .libs/error.o   -Wl,--version-script=./libnih.ver -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-O1 -Wl,-O1 -Wl,-soname -Wl,libnih.so.0 -o .libs/libnih.so.0.0.0
<Keybuk> /usr/bin/ld: .libs/alloc.o: relocation R_X86_64_PC32 against symbol `nih_free' can not be used when making a shared object; recompile with -fPIC
<Keybuk> /usr/bin/ld: final link failed: Bad value
<Keybuk> collect2: ld returned 1 exit status
<kees> Keybuk: doin' it wrong.  :P
<Keybuk> kees: -v
<kees> heheh
<kees> I assume either  a) some .o wasn't compiled with -fPIE, or  b) the final link lacked -pie
<kees> (the final link -pie tells the compiler which crt to link in)
<Keybuk> hmm
<Keybuk> libtool called it with -pie
<Keybuk> but that got eaten
<kees> however... you're making a shared object here.
<Keybuk> does it need to be -Wl,-pie ?
<kees> no
<kees> PIE is a PITA.  :)
<Keybuk> ?
<kees> (Pain In The reAr)
<kees> so, hm, if you're making a shared object, those need to all be -fPIC
<Keybuk> hmm
<kees> i.e. things going into a .so need -fPIC, things going into an executable need -fPIE (and a -pie at the end)
<Keybuk> I don't really want the shared object
<Keybuk> I just want the static one
<kees> and PIC > PIE, so you can link -pie against PIC or PIE objects.
<Keybuk> why does it work here and not on the buildds?
<kees> uhm.... that's a good question.
<kees> I hadn't really noted that issue until just now.  *head scratch*
<kees> it's the same toolchain isn't it?
<Keybuk> intrepid vs. hardy maybe?
<kees> you're doing compiles in an intrepid chroot, yes?
<Keybuk> no
<Keybuk> hmm
<kees> :P
<Keybuk> actually, I think I compiled this on i386
<Keybuk> where it apparently works fine
<Keybuk> if I do it on amd64, even on hardy, it fails
 * kees scratches his head even more
<kees> well, clearly one issue is the -fPIE of a shared object.  those should be -fPIC.
<Keybuk> I don't understand why the -static is getting lost
<Keybuk> hah, I bet setting LDFLAGS is overriding it
<zul> \sh: I dont have a problem with it lemme ask around
<kees> back in a bit...
<Awsoonn> hi all~ I'm new to Ubuntu development, working on potentialy fixing a bug in rhythmbox that ... bugs me
<Awsoonn> how can i find out if there are any patches applied to the ubuntu version of rhythmbox that are not applied to upstream?
<ogra> read the changelog, patches are listed in the upstream merges usually ... and you can grab the source package and look in debian/patches/
<stgraber> Awsoonn: apt-get source rhythmbox, then look at the debian directory and see if there is a patches/ subdirectory
<seb128> Awsoonn: there is only a patch to build using xulrunner1.9, a launchpad intregration change and an update to the radios list to use ogg
<iwkse> hi all, is this a good place for usplash questions?
<Keybuk> seb128: applied a trivial one-line patch to gnome-contol-center
<Keybuk> expect bugs from frothing-at-the-mouth loonies
<seb128> Keybuk: you are messing with fonts settings again, aren't you? ;-)
<ogra> a one line patch with half a novel in the changelog :)
<Keybuk> seb128: I've made the change I agreed to wait until the start of a non-LTS release cycle to make ;)
<Awsoonn> alright, if I want to fix something, generally speaking, should I work on the upstream truck, or the source I get from apt-get?
<seb128> ah ah
<seb128> Awsoonn: upstream is better but there is not a lot of difference currently
<Keybuk> seb128: it passed the njpatel test a few weeks ago
<Keybuk> "Wait! What are you doing! Leave my font settings alone! It took me ages to get those ri....ooh, that's much better!"
<njpatel> Keybuk: :-)
<njpatel> Keybuk: you changed my life
<seb128> Keybuk: btw, congrats, you just won the right the merge gnome-control-center now that you touched it ;-)
<seb128> s/the merge/to merge
<ogra> hehe
 * seb128 runs
<Keybuk> seb128: no problem, I'll just delegate it to one my team
<Keybuk> seb128: could you merge gnome-control-center, kthxbye
<Keybuk> :p
<seb128> doh ;-)
<Awsoonn> just curious, what do you guys use pro hackers use for a programing environment?
<geser> $EDITOR
<Awsoonn> like, Vim/grep, or eclipse, Kdevelop, etc
<Keybuk> emacs
<ogra> vim
<Keybuk> though I will gladly bear the first-born of anyone who writes a decent GTK+ IDE
<soren> Awsoonn: vim
<Awsoonn> what do you think of eclipse and Kdevelop and such IDEs?
<Keybuk> Awsoonn: Depends: java, pain ... Depends: kde, pain
<ogra> Keybuk, nothing for emacs fans, but i found pida quite intresting for pygtk development in the past
<ogra> (it embeds glade and vim)
<seb128> an d gedit rocks ;-)
<ogra> not sure its still under development though
<seb128> and gedit rocks ;-)
<ogra> it misses the vim mode yet :)
<Keybuk> seb128: gedit, with an integrated debugger and source analyser is starting to be along the right lines
<Keybuk> I don't know why, but Anjuta should be perfect
<Keybuk> yet it's so far off the mark
<ogra> oh, pida added an emacs mode :)
<ogra> but doesnt work :/
<persia> Keybuk: gedit + Nemiver goes a long way towards that
<LaserJock> zul: ping
<zul> LaserJock: hi!
<Keybuk> though I must admit, saying that, that anjuta 2.4 is a rather nice step in the right direction
<Keybuk> I might try using that for a bit and see how long it takes me to want to kill people
<Keybuk> so, about 5 minutes then
<ogra> heh
<persia> Is that a longer or shorter period than the last version?
<Keybuk> a bit longre
<ogra> more options to configure before you can use it ?
<pitti> Keybuk: does anjuta have gvim intregration? :-)
<pitti> (seriously, I got so addicted to the "handle complex objects" commands in vim that it would take a lot to convince me to abandon it again)
<Keybuk> pitti: probably not ;)
<Keybuk> it doesn't have C-x 4 a
<Keybuk> which is the single most fantastic emacs feature ever
<pitti> what does it do?
<pitti> eliza?
<Keybuk> adds a changelog entry
<ogra> pitti, http://picasaweb.google.co.in/arunchaganty/Anjuta/photo#5206317121142374866
<Keybuk> with your name, e-mail, the date, the filename and current function all filled in for you
<pitti> nice
<pitti> ogra: oooooh!
<pitti> Keybuk: see ogra's screenshot, that looks quite vimish
<ogra> pitti, SoC :)
<ogra> http://arunchaganty.wordpress.com/2008/06/01/vim-communication/#ref-1
<Keybuk> heh
<Keybuk> if I could find an anjuta add to changelog plugin, I might be happy
 * pitti doesn't write upstream changelogs; bzr log -v --log-format 'gnu' > ChangeLog FTW!
<Keybuk> I do the exact opposite
<Keybuk> I have a bzr-commit shell script that puts the new ChangeLog entries into the commit log
<Keybuk> (it occurs to me that it's possible to do that as a plugin to bzr commit)
<seb128> pitti: ah, right, 'gnu' which is a non standard thing, I still remember it from the time I tried to do a jockey rebuild upload ;-)
<pitti> Keybuk: I do that for debian/changelog (debcommit)
<pitti> yay me for consistency :)
<pitti> but with the current tools, those are the easiest, I think
<ogra> how do you get  --log-format 'gnu' working ?
<ogra> my bzr only knows long, line and short as options
<seb128> probably by installing something you find on the way
<Keybuk> ogra: there's a plugin
<ogra> ah
<ion_> "              This behavior is identical to how emacs handles ChangeLog
<ion_> "              files with the change-log-mode provided by C-x 4 a.
<ion_> gnuchlog.vim
<ion_> keybuk: â
<Keybuk> ion_: ref?
 * ion_ googles... http://www.vim.org/scripts/script.php?script_id=1631
<Keybuk> ion_: so not helpful for Anjuta then? :p
<ion_> keybuk: There was a discussion about having vim in anjuta. :-)
<Keybuk> ion_: and then why not just use vim? :p
<ion_> Well, i do. ;-)
<blueyed> Why does virtualbox-ose-modules does not show up in the NEW queue at https://edge.launchpad.net/ubuntu/hardy/+queue? (I've received an ACK 16 minutes ago). And, once if should show up, can an archive admin approve it please (version 24.0.3)?
<blueyed> well.. "waiting for approval" should land in NEW, shouldn't it?
<persia> blueyed: "waiting for approval" is in unapproved.  It goes to NEW once it gets approved (archive admins have to press two buttons)
<persia> blueyed: https://launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=
<slangasek> blueyed: what's the difference between 24.0.2 and 24.0.3?
<blueyed> persia: thanks, must be blind.. anyway, please approve.
<blueyed> slangasek: I've messed up the changelog in .2
 * persia is very much not an archive admin
<blueyed> (build the new module from the intrepid source package)
<blueyed> persia: I know.. wasn't meant to be in the same line/to you.
<slangasek> blueyed: mm, well, you don't have to increment the version number in that case when it's a -proposed upload, you can just ask the archive admin to remove the broken package from the unapproved queue
<blueyed> slangasek: ah, good to know. thanks. but it should be ok now as .3, isn't it?
<slangasek> blueyed: ... and -proposed has -19 now instead of -18; you may want to jump over -18 here and just get a version for -19 pushed into -updates at the same time
<slangasek> yes, .3 is ok otherwise
<slangasek> and if you think it's important to get a fixed modules package for -18 in, I can approve it as-is
<blueyed> slangasek: yes, it's important. a hell lot of users are complaining.. :/ I'll upload .4 for -19 then, too, yes?
<ogra> seb128, do you have any idea if there are python-wnck bindings anywhere out in the world ?
 * ogra cant imagine they dont exists
<slangasek> blueyed: you can only have one version in -proposed at a time
<seb128> ogra: python-gnome2-desktop has those
<ogra> oh
<ogra> i was looking for python-wnck :)
<ogra> sill yme
<blueyed> slangasek: well.. please go with -18 and hopefully it gets approved shortly.
<slangasek> blueyed: this does mean that pushing in a -18 version right now may make a fixed -19 version later due to the timeline; but .0.3 is accepted now
<emgent> someone have 05ca:1803 Ricoh Co., Ltd webcam ?
<blueyed> slangasek: I suppose virtualbox-ose-modules gets copied then to -security and -updates? So that it makes sense to have a version for -18, if somebody is only using -security, but not -updates, correct?
<shonen> does anyone know the minimum libpcap version is for usb capture support?
<shonen> never mind, I found it
<slangasek> blueyed: mm, I don't know about copying it to -security; I don't know if that works in practice
<slangasek> blueyed: normally the packages come in the other direction, and I believe we do have provisions for universe packages published as security updates even though they're not part of Canonical's security support
<kees> is there a kernel module we need to push through -security?
<kees> we've done this in the past for things like the external apache worker, etc
<slangasek> kees: virtualbox-ose-modules, which has been uploaded to -proposed
<fyrestrtr> hello -- does the 32bit hardy default kernel not have highmem support?
<fyrestrtr> on my 4GB ram laptop usable memory is only 2GB
<kees> fyrestrtr: you can either install the -server kernel for PAE mode, or you can run the 64bit kernel.
<kees> slangasek: er, so it needs to go through -security instead?
<slangasek> well, that would be the ideal
<fyrestrtr> will the -server kernel affect negatively on proprietary drivers? I have the nvidia driver set installed.
<fyrestrtr> I tried the 64bit kernel before, but I have run into some compatibility issues with things like oracle and enterprisedb.
<kees> fyrestrtr: I'm actually not sure about the nvidia bit, I think it's okay.  check in #ubuntu-server perhaps?
<tkamppeter> Keybuk, up to now I did not encounter a 64-bit-only bug, but I can imaging that they exist, when it comes to handling of bits and bytes, which is often done in printer drivers.
<fyrestrtr> can anyone point me to where I can find out about the differences between the Fedora 9 startup bootsplash and the Ubuntu one? I would like to find a way to integrate the Fedora splash with Ubuntu.
<pwnguin> apt-get source usplash
<pwnguin> no sudo
<fyrestrtr> they are the same thing, yes? Previous Ubuntu releases used to have text in addition to the progress meter. I would like the text option back, like with Fedora 9.
<pwnguin> you wanted to know what the differences are
<pwnguin> get the source and diff em
<pwnguin> not sure where to grab fedora's
<pwnguin> but there is text in ubuntu -- if you have a scheduled fsck it displays it
<pwnguin> along with instructions on how to cancel
<james_w> fyrestrtr: remove "quiet" from the kernel command line in grub to get the messages back.
<kees> fyrestrtr: remove "quiet" from your menu.lst
<pwnguin> i thought that dumped you out of usplash
<kees> pwnguin: no, that's removing "splash"
<pwnguin> alrighty
<pwnguin> fyrestrtr: and if you want that change to stick, make sure you hit the automagic lines in menu.lst too
<kees> or run "sudo update-grub"
<pwnguin> will that hit the kernel default options?
<pwnguin> (for kernel upgrades etc)
<kees> pwnguin: if you change the default lines, it will update the per-image lines, yes.
<fyrestrtr> two questions regarding tomcat5.5 -- why is there /etc/tomcat5.5/tomcat5.5 which points to /etc/tomcat5.5 -- leading to interesting but pointless things such as /etc/tomcat5.5/tomcat5.5/tomcat5.5/ and -- where are the shared libraries stored?
<Awsoonn> hi all, newb here. I want to do some bub work on Rythmbox and am wondering where the best place is to get the source from and best place to post patches?
<Awsoonn> bug work**
<mohbana> sorry back with freetype question
<mohbana> i just want to know the exact details of what ubuntu does to it's fonts
<_MMA_> Awsoonn: Maybe upstream?
<Awsoonn> _MMA_: i'm a bit confused really, when would I want to work on the source from apt-get or bzr then?
<_MMA_> I would think you would only use bzr if upstream uses it as their vcs.
<Awsoonn> and what about apt-get source?
<_MMA_> I think the only reason to grab it from apt is if you just want to build it yourself.
<Awsoonn> *Nods* and what might I want to do about patches applied to ubuntu's version and not the upstream version? just make sure the patch works in both places?
<_MMA_> Awsoonn: http://www.gnome.org/projects/rhythmbox/development.html
<Awsoonn> I'm sorry, I'm just currently working on rhythmbox, I'm trying to figure out how the bigger picture works with ubuntu and upstream with projects in general
<_MMA_> Im unsure about any "ubuntu-specific" patches. seb128 might be able to comment. I usually prefer to get things in upstream myself.
<seb128> _MMA_: usually if you work on changes better to use upstream as a base
<Awsoonn> I think I'v pestered seb128 more than enough for one day :)
<seb128> ups
<seb128> Awsoonn:: usually if you work on changes better to use upstream as a base
<seb128> you can get the svn or "bzr get lp:rhythmbox" which gives you a bzr import, nicer to work on
<seb128> the bzr import is equivalent to current svn
<seb128> once you have a patch attach it to bugzilla.gnome.org
<seb128> if you think that's an issue worth fixing on ubuntu look on launchpad
<Awsoonn> awesome, that is exactly the kinda of info I was looking for, Thank you.
<seb128> https://launchpad.net/ubuntu/+source/rhythmbox/+bugs
<seb128> if it's not opened there open a new bug
<seb128> otherwise use the currently open one
<seb128> add a task pointing to the gnome bugzilla bug
<seb128> and attach your patch
<seb128> you might want to subscribe the ubuntu-main-sponsors team too
<seb128> we are usually able to figure how to apply the patch ;-)
<seb128> if you want to do all the work you can apply the patch to the current ubuntu package and attach a debdiff (diff between the current package and the updated version you built) but that's not required
<Awsoonn> i'd like to do it so I know how to at least, have a link?
<seb128> Awsoonn: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff has a detailled example
<ScottK> pitti: Do you plan on continuing to use guidance-backends for jockey?  If so, is there a way I can talk you out of it?
<pgraner>  /msg NickServ identify intell
<pgraner> d /msg NickServ identify intell
<ScottK> pgraner: You'll want to change that password now.
<pgraner> yea
<tormod> bryce, if you're still in sponsor-mood, can you please look at bug 237266? Kind of follow up from yesterday (and no-brainer).
<ubottu> Launchpad bug 237266 in laptop-mode-tools "bashisms in laptop-mode cause it to fail" [Undecided,Confirmed] https://launchpad.net/bugs/237266
<bryce> tormod, sure, in a few minutes
<iwkse> hi all, i'm experiencing a problem with usplash. When i create the theme and i try it on my pc it works great, but in chroot (livecd) testing it with usplash -c it doesn't show it. Booting the iso give black screen. I also tried with the eft-example theme and it's still the same effect on the chroot. usplash -c says usplash: can't get console font: Invalid argument but i get the same also on my pc but it works. Why it wouldn't works in chroot?
<DktrKranz> any sponsors for main around to look at bug 226783?
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226783
<Keybuk> Mithrandir: around?
<\sh> Keybuk: the change to upstart didn't fix the sysvutils problem in intrepid it seems
<Keybuk> or infinity, or someone of equal crackfulness ;)
<tormod> hibernation is broken on many laptops due to bug 226069, can some pm-utils knowledgeable look at it please?
<ubottu> Launchpad bug 226069 in pm-utils "hibernation fails to power off and reboots because "platform" is inconditionally used instead of "shutdown"" [Undecided,Fix released] https://launchpad.net/bugs/226069
<\sh> anyways...no the time anymore to deal with this .... sleep is more valuable
<ScottK> \sh: Sleep is for the weak.
<impulze> um is there any channel not so heavily crowded as the main one? it seems my question gets scrolled out far too fast ;)
<ScottK> impulze: No.  That's it.  You might try the mailing list if you want something slower paced.
<impulze> ok
<MacSlow> In which package/patch is the logout-dialog hidden?
<ogra> MacSlow, gnome-session
<MacSlow> in sesssion... well :)
<MacSlow> I looked in gdm, gnome-panel, gnome-applets... just no in session
<MacSlow> ogra, thx
<iwkse> usplash -c wouldn't works in chroot...it's me or you can notice it too?
#ubuntu-devel 2008-06-05
<calc> is there a way to break a rules run via a command, eg exit 1 or something?
<calc> if it finds a problem to force the build to fail?
<Keybuk> calc: as in debian/rules ?
<calc> Keybuk: yea
<calc> so i guess something to throw an error for a makefile
<Keybuk> calc: then yes, you can just exit 1
<calc> ok thanks :)
<calc> i didn't know if there was a more correct way to do it
<emgent> heya
<calc> emgent: hi
<emgent> calc: heya :)
<calc> i'm adding a test to make sure i stop forgetting to apply the Desktop renaming patches for OOo
<calc> forcing it to kill the build if i do :)
<emgent> hard work for OOo :Ã§
<Keybuk> calc: at the beginning of the build, I assume? :p
<calc> yea
<Keybuk> you wouldn't want to wait a week to find out
<nixternal> mneptok: 1 hour 15 minutes, come and get your membership!
<nixternal> cgrega1: 1 hour and 10 minutes until membership meeting!
<nixternal> awalton__: same for you ^^ 1 hour 10 minutes
<cgrega1> nixternal: Yep.....
<awalton__> nixternal, thanks.
<nixternal> no prob
<daxro1> Hey all
<daxro1> Is there know problem with  Intel 82801G (ICH7 Family) HDA Controller (rev 02), it was working on a fresh install upgraded and now it fails , I have asked in #ubuntu but no answers , so off topic not funny
<daxro1> 2.24.16 used to work not after update to 2.24.18
<daxro1> Its a sony laptop , also suffering from the acpi problem
<mneptok> nixternal: yeah, i will if i can
<ffm> Any idea when we'll get FXrc(1|2) in proposed?
<Pici> fx?
<sladen> rc?
<ffm> Pici: Firefox.
<daxro1> I think the problem is the sony-pi module
<ffm> Pici: release candidate 1/2
<Pici> ffm: RC1 is in proposed.
<Pici> ffm: Also, someone just asked that on the sounder list, and got the reply that its undergoing testing, but may make it to -updates next week
<ffm> Pici: not on my mirror...
<ffm> Pici: cool.
<Pici> ffm: I am not a developer, but I know that not all the repositories have proposed, I had to move to the main server to get those
<mouz> I'm learning about packaging and I'm reading developer pages. Now I see a package (motion) not having 'ubuntu' in the version string in the changelog file. Is that wrong? Or is that right for some kind of packages? I asked on #ubuntu but there was no answer.
<TheMuso> mouz: If the changelog file has the word unstable next to the version number, this means that the package was imported from Debian.
<TheMuso> Whereever possible we use packages directly synced from Debian.
<pwnguin> its much easier that way ;)
<mouz> Is that an automated procedure then?
<mouz> TheMuso / pwnguin : so if there's something wrong with the package, and I want to do something about it: contact upstream?
<pwnguin> you know how dns works?
<TheMuso> mouz: If the fix can be made in Debian, yes is better to do it there, or even upstream from Debian if its not specific to Debian/Ubuntu packaging.
<pwnguin> mouz: start with ubuntu and work your way up; make sure it's not specific to ubuntu before pestering any upstreams ;)
<pwnguin> nobody likes hearing their openssl is broke when it's just debian and those who branched from them :_
<mouz> pwnguin: I think I need to create a debian environment: I *think* it is a problem upstream, but I'm not 100% sure.
<pwnguin> thats the challenge I run into. it seems silly to file bugs against debian without actually testing on a debian platform
<ScottK> pwnguin: That or knowing enough about Debian/Ubuntu differences to know if testing on Ubuntu is sufficient (it often is).
<ScottK> Virtual machines are easy enough to set up that testing on Debian isn't so hard.
<mouz> ScottK: would you have a suggestion what virtual machine?
<pwnguin> mostly i stick to the fun stuff -- x toys and the kernel
 * ScottK hands pwnguin https://help.ubuntu.com/community/KVM
<pwnguin> oh that sounds like oodles of fun
<pwnguin> fortunately, neither of my machines appears to support it
<pwnguin> ScottK: besides which, the kernel doesnt come from debian :P
<ScottK> If it's kernel, then it definitely doesn't go to Debian.
<pwnguin> that reminds me, im supposed to rebuild and test something for the sdchi guy
<ScottK> pwnguin: https://help.ubuntu.com/community/VirtualBox is also good.
 * wgrant uses a chroot in most cases.
<pwnguin> mouz: at any rate, you've got a couple vm suggestions now
<mouz> yes. thanks TheMuso, pwnguin, ScottK: I now can proceed :)
<wgrant> Ooh, new policy.
<ScottK> wgrant: Yes?
<ajmitch> wgrant: where?
<wgrant> There hasn't been a big new one in a while.
<wgrant> ajmitch: debian-devel-announce.
<ajmitch> ah
<ajmitch> nothing too major
<calc> how do i test for return code in a debian/rules file?
<calc> eg:
<wgrant> No, looks like formalisation of lots of common practices.
<calc> http://pastebin.ubuntu.com/17048/
<calc> the echo $? seems to return 'ooo-build/configure'
<calc> instead of the return code
<slangasek> because you have to escape the $ character in makefiles by doubling it
<calc> ah so $$? ?
<slangasek> yes
<calc> ok thanks :)
<pwnguin> heh
<pwnguin> so there wasnt a Homepage field before today?
<wgrant> Not in policy.
<calc> great that fixed the code to properly fail now :)
<ScottK> pwnguin: In Debian policy tends to define current practice, not lead it.
<calc> liw: ping
<iwkse> hi, i'm testing on some themes with usplash and with one strace shows a series of vm86old(0xb7d1cc8c)                     = -1 ENOSYS (Function not implemented)
<iwkse> what have to do usplash with vm86old?
<pwnguin> video routines i think
<pwnguin> if you check out the dependency chain of usplash, it goes to libx86, which is used to make "real mode" calls, probably to write to video hardware
<iwkse> yes..
<iwkse> there's a comment in lrmi.c about it
<iwkse> used to syscall 113
<TheMuso> Anybody got an idea whats going on here? This is building in an intrepid chroot: http://www.pastebin.ca/1039152 The function where the problem lies is here: http://www.pastebin.ca/1039154 The bits/socket.h file gets included at the top of the c file in question.
<StevenK> TheMuso: My guess is the C compiler can't figure out the length of ucred, perhaps the header file that the typedef'd struct is defined in needs to be shifted down
<TheMuso> StevenK: Yeah worth a shot, thanks for the idea.
<TheMuso> No good it seems. The fun part is that the file in question has code in it for at least Linux/Unix and Mingw32/Windows.
<TheMuso> So the include can't really be moved further down, if only a few lines, which makes no difference.
<TheMuso> As there are tons of #ifdefs etc.
<StevenK> TheMuso: Run the code through gcc -E (the pre-compiler) to see if you can resolve the struct by hand?
<TheMuso> StevenK: Ok.
<StevenK> TheMuso: That advice might send you over here with a bat
<TheMuso> StevenK: I don't know about that, it gives me something new to learn about at least. :)
<mdomsch> pitti, superm1, ping re dkms
<superm1> hi mdomsch
<superm1> what's up?
<mdomsch> superm1, #237358
<superm1> bug 237358
<ubottu> Launchpad bug 237358 in dkms "dkms_autoinstaller does not support install with --force" [Undecided,New] https://launchpad.net/bugs/237358
<mdomsch> I'm confused
<superm1> so i suppose it depends on how it was dkmsified
<mdomsch> say I have linxux-2.6.24-14.xx-generic installed
<mdomsch> and they bump the ABI
<superm1> but in any case, AUTOINSTALL=yes should handle this fine
<mdomsch> so new linux-2.6.24-15.xx-generic gets installed
<mdomsch> why wouldn't dkms autoinstall "just work" - why would --force be needed?
<mdomsch> and if it's _not_ an ABI bump
<mdomsch> so -14.xx -> .14.yy
<superm1> i think we need to see martin post his package here to see a little better what the situation is
<mdomsch> unless /lib/modules/2.6.24-14-generic gets deleted then re-created
<mdomsch> yeah, ok
 * mdomsch adds a note to the bug
<superm1> pitti, can you post it to a bzr branch and link it to the bug?
<superm1> honestly i still haven't used any of the mkdeb framework for doing dkms packages
<superm1> i still feel comfortable doing them by hand
<superm1> i should start using mkdeb instead
<mdomsch> and improve mkdeb then
<mdomsch> I put it together based on how we did it with RPMs
<mdomsch> not that I'm 100% happy with that - but it's worked fine for several years now
<superm1> well i'm not happy with the idea of storing a tgz inside the deb for the source stuff
<superm1> it seems unnecessary
<superm1> the deb itself can just house usr/src/blah-version
<superm1> that's mostly why i've done then by hand
<mdomsch> that came about because of a marketing requirement (much as I hated it) to be able to have source-less packages
<mdomsch> for a few big customers who were scared that "bad things could happen" if they even had the source
<mdomsch> I haven't heard that concern in quite a few years now though
<superm1> well sourceless packages are still possible without putting the tgz stuff in there, just take usr/src/ out of debian/install
<superm1> i'll sit down with you over lunch one day and you can explain to me more why it was like that
<superm1> and what's feasible to change
<mdomsch> most of it's feasible to change :-)
<mdomsch> especially on ubuntu
<mdomsch> as so few packages exist that have used mkdeb yet
<mdomsch> I'm completely open to any better way to do packaging
<ion_> It would be kind of nice if the chunk of common code in dkmsâ mkdeb postinst file were in a file provided by dkms and the postinst just sourced it.
<superm1> yeah that's a nice idea
<mdomsch> ion_, agreed
<impulze> hm
<impulze> could i make a proposal somewhere? ;p
<impulze> i'm currently setting up crypted root for a friend of mine and i created a hook which can be used to decrypt key-files with gpg
<impulze> seems to work pretty good though
<encryptz> are there any scripts run against the vanilla kernel to remove binary blobs, etc?
<encryptz> as debian does on there kernels?
<encryptz> if so, where can i find them? i'm looking to compile my own kernel
<TheMuso> Hrm seems the dmsetup command doesn't like the -18 kernel.
<TheMuso> Give me a sec and I'll get output.
<TheMuso> This is what I get with sudo dmsetup info, this is with 2.6.24-18-generic on amd64. http://www.pastebin.ca/1039227
<TheMuso> meh I  didn't have the damn driver loaded.
 * TheMuso slaps himself.
 * StevenK was about to ask ....
<doko> slangasek, pitti: time to move tcl8.5 and tk8.5 to main?
<pitti> Good morning
<pitti> doko: yes, think so
<ScottK> pitti: Do you plan on continuing to use guidance-backends for jockey?  If so, is there a way I can talk you out of it?
<pitti> ScottK: I'm happy to switch to something else; what would be better?
<pitti> ScottK: (I saw your scrollback)
<ScottK> tseliot is writing a new one.
<pitti> ScottK: right, I was going to look at that one
<ScottK> Fundamentally I xorg.conf parsing is on the way out.
<ScottK> I/I think
<ScottK> My goal is to kill Guidance as dead a possible in Intrepid.
<ScottK> Mythbuntu is the only other user and they'll follow your lead.
<pitti> superm1: I'll give some more details on the bug
 * ScottK notes the time in the US and decides to head for bed.
<superm1> pitti, if at all possible, can you publish a branch?
<superm1> it's be best to be able to experiment with the issue first hand
<pitti> superm1: I don't have one ATM, but I can post my dkms.conf generation script, and the tarball
<superm1> okay
<superm1> thanks
<pitti> superm1: odd, I thought I described the problem quite clearly
<superm1> yeah but it shouldn't be happening
<superm1> so something seems fishy about it
<pitti> superm1: well, then dkms shouldn't provide the --force option for install at all
<pitti> and just implicitly assume it, or so
<superm1> well it shouldn't be needing to force though is the thing
<pitti> either we need it in both places, or not at all
<pitti> superm1: but how can it not?
<superm1> it should be able to just "install" without the force
<superm1> that's what dkms_autoinstaller is supposed to take care of
<pitti> superm1: I can't avoid the improperly versioned modules
<pitti> I need the kmods from my package, and they need to replace the ones from linux-generic, even without having a new modversion
<superm1> right
<superm1> so if you use AUTOINSTALL=yes
<superm1> instead of AUTOINSTALL=smart
<pitti> thus I need install --force
<superm1> then they should take precendence without the force
<pitti> superm1: I don't use smart
<pitti> superm1: it's not a matter of precedence
<pitti> superm1: it's a matter of the installation failing, since the 'version sanity check' barfs and aborts
<superm1> oh hmm
<pitti> once I --force it through, it works just fine
<superm1> okay well post what you can here, i'll experiment when i get into the office in the morning and sort out a solution with matt
<pitti> (what's "smart", BTW? it's not documented)
<pitti> superm1: right, I will; thanks!
<pitti> superm1: oh, for bug
<pitti> bug 218955
<ubottu> Launchpad bug 218955 in lirc "upgrade to hardy breaks lirc 0.8.3pre1 kernel modules" [Undecided,Fix committed] https://launchpad.net/bugs/218955
<pitti> superm1: you need sponsoring?
<superm1> yes
<pitti> 'kay, will do
<superm1> great thanks :)
<pitti> superm1: for intrepid, is there a source pkg? or is it all in bzr, I just checkout and debuild?
<superm1> pitti, for intrepid grab the orig.tar.gz from lirc.org, and then debian/ is in bzr
<superm1> i haven't added a get-orig-source rule because it's very rare that upstream actually does releases, it's mostly been snapshots of different varieties
<superm1> hm so i thought AUTOINSTALL=smart was supported, but maybe i'm mixing something else up with it
<pitti> grep smart /usr/sbin/dkms doesn't give anything, neither in the manpage
<superm1> yeah that's what i was checking too
<superm1> i'll have to check with the colleague of mine who was referencing it in the first place tomorrow
<pitti> argh, /me radiates hate to that silly sf.net thing where you click on a .tar.gz link and it just saves a html page
<pitti> asac: which of the two epy's with identical changelogs should I accept for SRU?
<pitti> superm1: ok, all done
<pitti> Keybuk: argh sysvinit argh; still no luck, apt refuses to upgrade over it
<Mithrandir> Keybuk: I'm around now
<moquist> ogra: if you could take a look at my latest upload I'll appreciate it: http://revu.ubuntuwire.com/details.py?package=moodle
<pitti> asac: ah, the bug report makes it clear
<Hobbsee_> afternoon
<liw> calc, pong
<TheMuso> Afternoon Hobbsee_.
<Hobbsee_> TheMuso!
<Hobbsee_> how goes it?
<TheMuso> Hobbsee_: Not too bad. Yourself?
<Hobbsee_> TheMuso: uni's almost over for the semester.  \o/
<TheMuso> Hobbsee_: Awesome.
<RAOF> Hobbsee_: Yeah.  This is good.  Less tutorialising, more writing up.
<RAOF> Oh.  Wait. :(
<StevenK> RAOF: Less students ...
<pwnguin> jeebus, not done in june?
<pwnguin> i guess its winter down there
<RAOF> StevenK: Yeah, that's actually nice.  Lower average wait time for coffeee!
<RAOF> I seem to have shipped Hobart winter weather up to Sydney, though.
<StevenK> Yes, you bastard.
<StevenK> :-P
<RAOF> Well, except for the fact that the temperature is roughly double what it would be in Hobart :P
<RAOF> Here's an interesting question: do we want to sync nouveau from debian experimental?
<RAOF> Actually, now that I think of it, the answer is 'hell, no!'.
<pwnguin> aww
 * persia trusts RAOFs decision, but doesn't understand it: surely only very few would install such a thing
<RAOF> pwnguin: Sorry.  I don't want to maintain the 3d stack, thanks :P
<RAOF> persia: That's what _you_ think.  It's in experimental because it needs a git-snapshot of libdrm.  rdepend of * :)
<RAOF> For values of
<persia> RAOF: And this is why I trust you for all things nouveau: you actually have the answers :)
<RAOF> for values of * equal to anything X or 3d related.
<pwnguin> i didnt kno debian had gallium in experimental
<Hobbsee_> RAOF: hah.
<RAOF> It's possible that libdrm will see a release before Intrepid freeze; if so, I'll be asking to sync nouveau.
<RAOF> pwnguin: It doesn't.
<Hobbsee_> RAOF: don't you have to mark the exams too?
<pwnguin> then whats this 3d stack
<RAOF> pwnguin: libdrm contains the kernel modules and associated library for the direct rendering manager.
<pwnguin> which doesn't have 3d in particular
<RAOF> The 3d stack (or, technically, the usermode 3d DRI drivers) depend on libdrm, as does X.
<pwnguin> right
<RAOF> Almost all X drivers (aka DDX) do *not* require a drm component; nouveau does, because it's entirely new and all drivers are moving towards having a drm component.
<pwnguin> RAOF: i think we've talked about this before
<RAOF> Probably. :)
<pwnguin> i can certainly understand not wanting to handle libdrm2
<pwnguin> as part of ubuntu
<pwnguin> just thought it was wierd that you called it the 3d stack
<RAOF> It's the very bottom of the 3d stack :)
<RAOF> It also happens to not be entirely about 3d.
<pwnguin> computer stacks grow down ;)
<Mithrandir> depends on the architecture.
<pwnguin> actually, the next time someone decides to tell me that counting from 0 makes sense in C, i'll ask em to draw a stack
<pwnguin> take that "its more intuitive because its how the hardware works"
<RAOF> Arrays are a lie in C anyway.
<pwnguin> oh?
<RAOF> array[foo] <=> *(array + foo)
<pwnguin> yes...
<pwnguin> im not sure thats a "lie"
<RAOF> It is.  There is no "Array".  There's just a bunch of bytes, and a pointer to the bottom.
<RAOF> Or top.
<RAOF> Or, anywhere, really.
<Mithrandir> also array[foo] == foo[array]
<pwnguin> so what exactly is an array, do you think?
 * StevenK is reminded of "There is no spoon"
<pwnguin> Mithrandir: you'd have to have a pretty lenient typing to pull that off
<RAOF> I'd say an array is an object that contains a fixed number of indexable subobjects.
<RAOF> This makes it impossible for C to have an array, except by convention.
<pwnguin> it's all convention
<RAOF> Only in C.
<pwnguin> just some conventions are enforced by runtime and compilers ;)
<RAOF> Right.  There is no gravity, it's just a convention the universe enforces :P
<pwnguin> well, computer programmers are designers of systems; in a sense, we're determining whether gravity exists or not
<RAOF> That's probably enough semantics for now.  Is python-gnome2-extras installable yet?
<RAOF> Or should I actually ask to have various things deliberately rebuilt, rather than waiting for new versions to provoke a rebuild.
<Mithrandir> pwnguin: http://rafb.net/p/bKyL9r10.html compiles fine without warnings with gcc -Wall
<tjaalton> RAOF: what about the kernel modules, those should be updated too?
<pitti> mvo: CRACK ATTACK! https://wiki.ubuntu.com/IntrepidImprovedLinuxMeta
 * wgrant wonders why we are letting X servers loose.
<mvo> good morning pitti
 * mvo read
<Hobbsee_> wgrant: chain them up!
<Hobbsee_> mvo: no, you can't play crack attack.
<RAOF> tjaalton: Updated in what way?  The libdrm-snapshot in experimental provides a drm-modules-source package for module-assistant.
<tjaalton> RAOF: oh, ok
<RAOF> For Ubuntu I suppose I could look into DKMS, but it's not really a priority.
<tjaalton> right, and if 2.3.1 is enough, we should be able to pull the needed bits in the kernel
<tjaalton> unless the nouveau guys are constantly changing/breaking things ;)
<RAOF> I think it's been a while since the last drm/DDX incompatibility.
<tjaalton> that's good
<pwnguin> if they werent breaking things, wouldnt it be time to put drm into mainline kernels/
<RAOF> No; they're waiting for the great GPU memory manager wars to decay enough to have safe levels of radiation I think.
<tjaalton> pwnguin: it already is, but the stable version is 18 months old
<pwnguin> Mithrandir: does that snipped work out on a 64bit platform?
<dholbach> good morning
<tjaalton> morning, dj holbach ;)
<dholbach> hiya tjaalton :)
<RAOF> If worst came to the worst, we could posibly push the nouveau drm module into linux-ubuntu-modules.
<tjaalton> RAOF: I still have some optimism left ;)
<liw> tjaalton, hi there
<mvo> hey dholbach
<tjaalton> RAOF: how closely have you been following The Great Memomy Manager Wars?
<tjaalton> liw: howdy
<dholbach> hey mv
<dholbach> mvo :)
<RAOF> tjaalton: Not very much.  I basically trawled the archives a week or two ago for the burning remains.
<tjaalton> RAOF: I mean, it's like redhat/tungsten are doing a lot of ttm stuff lately..
<tjaalton> and isn't jesse barnes an intel guy? he's been doing that too
<tjaalton> so it's "only" anholt and keithp doing GEM
<RAOF> That's not an uninfluential "only", though.
<pitti> mvo: hm, the removal of aptitude, libept0, and tasksel in intrepid (in favor of new apt) is your bug, not related to my sysvutils mess, right?
<tjaalton> RAOF: hence the quotes ;)
<RAOF> Where's that list gone, again?  I feel the need to catch up ;)
<pwnguin> well, if intel can't decide what they want
<tjaalton> dri-devel
<RAOF> Aaaah, of course.
<tjaalton> the thread died a while ago
<pwnguin> do you really want to place a bet?
<tjaalton> apparently r6xx docs are about to be released
<pwnguin> Mithrandir: well, you've convinced me. there are no arrays in C. just collective delusions
<mvo> pitti: possible, I need to check, I think I didn't break the abi, I will investigate
<\sh> moins
<pitti> soren: when you merge dnsmasq, can you please stop using "multiuser" for update-rc.d? It's deprecated; please use sth. like "update-rc.d dnsmasq start 20 2 3 4 5 . stop 80 1"; this change can then be sent to Debian, too
<pitti> soren: that's our only change (LSB init script is in Debian now), so if they adopt it, we can sync again
<Mithrandir> pwnguin: 64-bit> yes, that's all I have those days.
<pitti> soren: same for rsync
<siretart> pitti: you like the game 'crack attack'? ;)
<pitti> siretart: it's all StevenK's fault
<pwnguin> <-- pwns at crack-attack
<dholbach> woohoo - crack-attack!
<dholbach> so what are the high-scores in here? :)
<pwnguin> i had a high score of 2500 or so. donno if that's subject to inflation
<StevenK> 7000 or so ...
<RAOF> jml pwns me at crack attack.
<dholbach> holy cow!
<pwnguin> it's all in the first few minutes
<pwnguin> get a huge combo at the start, and you can chain it while garbage transforms
 * dholbach realises that he's not going to win this contest and goes back to work ;-)
<StevenK> pwnguin: When my machine stops running something CPU intensive, I'll play you :-P
<pwnguin> heh
<pwnguin> 7000 seems unreal
<StevenK> Like most high scores, it can't be easily replicated
<pwnguin> still, its like 20 standard deviations away from my average
<StevenK> What's your average?
<pwnguin> somewhere in the 2000's
 * StevenK mostly plays the Medium AI
<pwnguin> huh
<pwnguin> i usually play none
<StevenK> pwnguin: Yeah. None means no AI. Try Medium
<pwnguin> thats not a score
<StevenK> Nope, since it simulates a network game
<asac> pitti: sorrry. cant you see the which was uploaded later ... otherwise the one with the smaller sized diff.gz :)
<asac> but isnt that important. the first one just contain an ununsed patch ;)
<pwnguin> StevenK: if you want a real challenge i have a set of colorfilters you can try ;)
<seb128> hey asac, thanks for fixing epiphany-browser ;*)
<StevenK> pwnguin: Try None set to Xtreme :-P
<asac> seb128: yeah ... another night thing. let me know if download is now as fixed as you want it ;)
<asac> pitti: did you accept midbrowser?
<asac> thanks
<asac> pitti: ok. have updated mails to be sure ... please let midbrowser in ;)
<pitti> asac: I got the right one (with the smaller patch), yes
<pitti> asac: mid> not yet, will do in a bit
<asac> gracias
<soren> pitti: Was update-rc.d's multiuser option's deprecation announced somewhere? I seem to have missed it :(
<pitti> soren: I just sent a mail to u-d-a@
<pitti> soren: I thought it would just affect 5 packages, but it's some more (26), thus I wrote an announcement now
<Hobbsee_> dholbach: you beat my hy score.
<Hobbsee_> if that makes you feel any better.
<soren> pitti: Ah, ok. The TearDown wiki page should probably be changed, too.
<pitti> soren: right, I'll do that once the announcement hits the ML archive
 * soren hugs pitti
<Hobbsee_> dholbach: (the latency in reply is due to the failing of the connection via wet string)
<pitti> argh, my mail queue is stuck
<pitti> piware.de [213.9.79.162] 25 (smtp) : No route to host
<pitti> WTF??
<soren> $ nc 213.9.79.162 25
<soren> 220 box79162.elkhouse.de ESMTP Postfix (Debian/GNU)
<soren> wfm
<pitti> right, and it works for other ports, too
<pitti> *#$(#$* ISP
<Hobbsee_> pitti: come to the land of wet string!
<dholbach> Hobbsee_: StevenK seems to be the master of crack-attack :)
<Hobbsee_> (90% packet loss here for you!)
<Hobbsee_> dholbach: yes, seems so.  then i should never play him.
<StevenK> pitti: Your ISP is now blocking outgoing port 25?
 * Hobbsee_ is not so much a fan of getting belted into the ground.
<pitti> there they go
<\sh> pitti, you need a reliable mail provider? ;)
<pitti> \sh: my server is fine
<pitti> \sh: I need a reliable ISP
<\sh> pitti, who is it for you? :)
<pitti> \sh: http://www.fbn-dd.de/
<\sh> pitti, use hosteurope or hetzner or someone else...those isp you can kick if they do something really stupid :)
<pitti> -ENODSL
<pitti> soren: changed Teardown wiki now
<pitti> \sh: again: I can't get DSL here
<pitti> \sh: two years ago they built a shiny VDSL node in the vicinity (to handle the fiber lines here), but now there are no ports left
<\sh> pitti, grmpf...mv pitti /dev/bw/au+rhein ; install -m 755 /usr/bin/cable /home/pitti/House ; convert pitti_sadness pitti_happyness
<pitti> :)
<\sh> hmmm...
<\sh> what is the default "make -j" counter inside the ubuntu build system?
<Mithrandir> 1
<\sh> hmm
<asac> pitti: do you need any infos for midbrowser?
<asac> the build was pre-QAed from https://edge.launchpad.net/~ubuntu-mobile/+archive
<\sh> any sane way to set global makeflags , without using the env?
<pitti> asac: no, should be fine; just accepted
<pitti> \sh: in the new world, "CFLAGS=-O3 dpkg-buildpackage", IIRC
<asac> pitti: rock! ... hope thats it for this run ;) thanks for your great work on this
<pitti> hm, not sure whether this has already been implemented...
<\sh> pitti, well, i was more thinking about a global conf file for this...but reading Dpkg::BuildOptions is just using ENV..grmpf I need to set it globally inside a chroot
<asac> please us -Os ;)
<pitti> \sh: you can install hardening-wrapper and modify it accordingly
<\sh> pitti, or misusing /etc/environment
<\sh> I just need to find a sane way to use all of the cores here
<pitti> TheMuso: can you please give me a quick heads-up about what will still happen to pulseaudio/alsa in hardy for 8.04.1?
<pitti> TheMuso: Steve and I need to know what we're still blocking on
<asac> pitti: btw, i am currently pushing moblin drop the whole xulrunner sources from their archive/tarball .. and do all their development against system xulrunner. So lets hope that in future the tarball will be smaller and thus easier for you to review
<pitti> TheMuso, jdong: can doko/I please get your yay or nay on bug 237083?
<ubottu> Launchpad bug 237083 in openjdk-6 "openjdk-6 SRU for hardy" [Undecided,New] https://launchpad.net/bugs/237083
<doko> ohh, that's universe ...
<pitti> Keybuk: hm, seems I don't have the power to set the status of duplicate specs to invalid; can you proxy some for me, or can I get it somehow?
<pitti> Keybuk: (guest-account, guest-login, and proper-guest-login-on-ubuntu-with-no-password should become obsolete, and gdm-guest-login should be the master spec)
<sistpoty|work> bryce: thanks for x11-common. kvm works with it, but uses only 800x600 as virtual screen now (probably because the defaults for the monitor vertrefresh/horizsync don't allow a higher resolution)
<\sh> WTF? make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
<hunger> Which version of the telepathy spec will the connection managers shipped by intrepid support (telepathy-gabble et al)?
<\sh> when passing -jN to usr/bin/sbuild for dpkg-buildpackage...regarding changelog, dpkg-buildpackage should know about -j
 * hunger wants to update decibel to a version that will work well with (k)ubuntu.
<DktrKranz> pitti, doko: regarding bug 237083, is there any available test case to check if proposed update is good?
<ubottu> Launchpad bug 237083 in openjdk-6 "openjdk-6 SRU for hardy" [Undecided,New] https://launchpad.net/bugs/237083
<DktrKranz> changes seems quite heavy
<doko> DktrKranz: what else do you expect from a new source drop?
<doko> DktrKranz: please look at the upstream changelog for a hint what did change
<DktrKranz> doko: sure. I'll have a look in a couple of hours, when I come back home. If it is a blocker for you, I can look at it right now.
<doko> no, looking at it today would be nice
<DktrKranz> ok, then. I'll review code and try to isolate some test cases to help testing process. thanks.
<pitti> seb128: I copied gtk-vnc, too, and reopen bug 206227
<ubottu> Launchpad bug 206227 in gtk-vnc "vinagre fails to connect" [High,Fix committed] https://launchpad.net/bugs/206227
<seb128> pitti: ah, good, thanks
<seb128> pitti: libgnomeui can probably be moved too
<pitti> seb128: hm, evo-exchange has no feedback yet
<seb128> pitti: the fixes are not easy to try because those are random crashers which have no testcases
<pitti> seb128: right; I'll add some comments and do some explicit testing
<ogra> and you likely need an exchange setup
<ogra> :)
<seb128> pitti: seems that exchange was quite broken, I doubt the update will be a regression
<seb128> and there was not so many changes
<Mez> Hmm - would cowdancer be valid for main? It'd make using it a lot easier (it requires itself to be installed under it's chroots to be used... which, because pbuilder is setup only to use main as a default - means cowbuilder cant create ubuntu chroots by default)
<TheMuso> pitti: The only thing I have really been able to prepare to be fixed is bug 221673 which is a 2-pronged SRU for alsa-lib and alsa-plugins. The flash stuff is somewhat out of our hands till flash 10 goes final.
<ubottu> Launchpad bug 221673 in alsa-plugins "ALSA failing with PulseAudio in Hardy" [Undecided,In progress] https://launchpad.net/bugs/221673
<jdstrand> ArneGoetje: what is the proper way to disable 'Ctrl-space' and SCIM? I don't see it in the preferences (I could be blind though)
<TheMuso> doko: ACK for 237083.
<pitti> seb128: I take it bug 18783 is fixed in hardy?
<ubottu> Launchpad bug 18783 in nautilus "Nautilus Properties incorrectly totals sizes of hardlinked files" [Medium,Fix committed] https://launchpad.net/bugs/18783
<pitti> seb128: erm, I mean, in Intrepid? in 2.23?
<seb128> pitti: yes
<pitti> seb128: cool; I just verified the rest, this can go, too
<seb128> cool
<ArneGoetje> jdstrand: language-selector: uncheck support for complex scripts.
<jdstrand> ArneGoetje: thanks!
<persia> ArneGoetje: Is there a way to turn it off, and still let one of the other Triggers (e.g. Hankaku/Zenkaku) activate it?
<persia> (where it means "Ctrl-space" and "SCIM" respectively)
<ArneGoetje> persia: scim-setup
<ArneGoetje> persia: after changing the Hotkeys, you'll need to restart your X session (i.e. logout and relogin) to get the changes into effect.
<persia> ArneGoetje: Aha.  It's the logging out that caught me.  Thanks :)
<pitti> TheMuso: right; I was especially concerned about the skipping
<pitti> TheMuso: which we thought would be worked around with increasing frame sizes; but if it can be patched properly in alsa, so much the better :)
<TheMuso> pitti: Thats not for the skipping.
<TheMuso> pitti: I uploaded a modified pulse to my PPA, some users said it helped, some said it didn't. However, more users are saying -18 kernel is helping more than anything else.
<TheMuso> Thats still up in the air unfortunately.
<pitti> ok
<pitti> TheMuso: but -18 didn't change anything there, did it? it's just a security update
<pitti> TheMuso: -19 changes a ton, though
 * pitti -> lunch, bbl
<TheMuso> pitti: Right, maybe the users who said it helped skipped 17.
<pitti> TheMuso: ok; please subscribe ubuntu-sru to that bug once you are sufficiently confident; we should get it to -proposed for wider-spread testing ASAP
<pitti> TheMuso: thanks!
<TheMuso> pitti: If I had a reliable fix, I would.
<Hobbsee> so, upgrade to intrepid.  good idea?  bad idea?  insane idea?
<persia> Hobbsee: http://people.ubuntu.com/~ubuntu-archive/NBS/libperl5.8 might bite you.  Check the rest of NBS as well
<Hobbsee> persia: hmmm
<Hobbsee> oh, lovely
<Hobbsee> even stuff like aptitude doesn't install, for some reason
<ogra> who uses that anyway
<Hobbsee> yeah, well.
<persia> Hobbsee: Therefore, everyone should upgrade right now :)
<ogra> its just dselect with some extra unctions
<ogra> *functions
<Hobbsee> it's more just a matter of wanting to keep the metapackages installed, so i don't miss packages.
<persia> ogra: I thought dselect was gone, so now we have to use aptitude
<ogra> i still see it in the archive
<RAOF> Hobbsee: This is Intrepid here, right now.  Now that upstart isn't broken, you might be able to upgrade :)
<ogra> (not that i'D use either)
<Hobbsee> RAOF: heh
 * Hobbsee looks for a cd
<RAOF> ?
<persia> ogra: Thanks!  I thought it was lost forever.
<ogra> :)
<Hobbsee> way cool.  this one already has a pre-burnt copy.
<RAOF> Oooh.  I wonder if my shiny new initramfs will actually unlock my crypt device next time I boot?
<RAOF> It's always fun to find out :)
<\sh> infinity, ping sbuild + dpkg-buildpackage -jN + why is it failing for me with N>1 but not with -j1? :)
<\sh> infinity, sorry...-j2 and N>2
<lamont> pitti: submission port is more love than 25...
<pitti> lamont: hm?
<lamont> MTAs now listen on two ports, you see.
<ScottK> pitti: Port 25 blocking is pretty common these days.
<lamont> generally
<pitti> right, I have it listen to 2525, too, and I use that now
<lamont> submission      587/tcp                         # Submission [RFC2476]
<ScottK> 587 is the standardized port
<pitti> I had just used 25 at home until this morning
<pitti> aah
<meta> Hi all, sorri if this is the wrong channel, but in #kubuntu/#ubuntu nobody knews the ansver for me as i see. So if i remember well, the livecds mounts automatically the local harddrives. My question is, what is this script's name?
<Nafallo> 25, 465 and 587 :-)
<Nafallo> three ports :-P
 * ScottK hands Nafallo a cookie for completeness
<pitti> ScottK: I think the point of that exercise (for hotel rooms/my #$# ISP) is to *not* use standardized ports :)
<ScottK> pitti: I've only run into a customer having port 587 redirected once.
<Nafallo> yay! cookie :-)
<ScottK> For your ISP, blocking anything but port 25 makes no sense for anti-spam measures as all they should do it block direct communication to remote MTAs.  Mail submission agents should be fine.
<ScottK> Nafallo: 465 is only needed if you're required to care about older Outlook versions and Outlook Express.
<Nafallo> SSL standard port :-)
<Nafallo> and force TLS on 25, for clients ;-)
<pitti> my postfix uses 465 for smtp/ssl
<ScottK> That's actually a bit of a misnomer.
<ScottK> Port 465 is smtps (wrapped port) SSL.  Port 587 is STARTTLS based and could be either SSL or TLS.
<ScottK> The only major mail clients I know of that didn't support the STARTTLS method are Outlook (until 2007 version) and OE.
<guysoft42> mvo, hello :) , are you here?
<mvo> guysoft42: yes
<guysoft42> mvo, i was wondering, if its possible to make the updater install extra packages from the ubuntu repository
<mvo> guysoft42: it is possible, what is your use-case for this?
<guysoft42> mvo, well i wanted to install a few packages we need in our release, for instance i need python-urlgrabber there, and a few other things
<mvo> guysoft42: the easiest way is probably to add a "yourDistroNameQuirks(self)" function to DistUpgradeCache.py and run "self["pkgs1]".markinstall()" there in a loop
<guysoft42> mvo,  i guess ill just add it to my wrapper script.. i just thought you might have hidden something there :)
<Keybuk> pitti: I seem to vaguely remember that I've had this problem before ;)
<Keybuk> which is why I never merged the package names
<guysoft42> mvo, ah.. i was just looking how to use python-apt, when i saw you are a developer in that too. so i guess i have now questions to you as a developer as that
<pitti> Keybuk: if that alluded to sysvutils, I fixed it now
<mvo> guysoft42: sure, I'm in a meeting right now, but I will answer when I'm back
<Keybuk> pitti: how did you fix it?
<pitti> Keybuk: drop the conflicts:, just rely on the replaces:
<pitti> Keybuk: that should be fine AFAICS
<Keybuk> pitti: you may also want to upload an empty sysvutils package that's not Essential
<guysoft42> mvo, ok, when shall i bug you then?
<Keybuk> that way you can remove it in jazzy
<pitti> no other way to fix the pre-depends/conflicts loop
<ogra> oh wow
<pitti> Keybuk: the first merge had that already
 * ogra looks at Keybuk 
<Keybuk> ah ok, missed that :)
<ogra> you recycled an old ltsp spec for gdm-guest-login ?
<ogra> funny :)
<pitti> ogra: well, I'm about to; if I'd ever get to actually writing it
<ogra> pitti, highvoltage will love you :)
<ogra> he drafted that originally (in paris i think)
<hunger> Anyone from the telepathy team around?
<zSoilworker> do you have a question about it?
<hunger> zSoilworker: Yeap.
<zSoilworker> then no.
<hunger> zSoilworker: Damn:-/
<hunger> Mithrandir: Which telepathy spec version will be supported in intrepid?
<Nilbus> Hello, I'm the president of NCSU LUG.  We've decided that we want to contribute to Ubuntu this summer as a special project.  We'd like to squash some bugs and contribute in other various ways. From reading the wiki, it looks like we ought to find a mentor and work under a MOTU.
<Nilbus> is that right?
<zSoilworker> Yes, it is.
<Nilbus> great
<persia> Nilbus: You don't need a specific mentor.  Just start from the wiki, and ask questions in #ubuntu-motu and #ubuntu-bugs, as appropriate.
<dholbach> Nilbus: I'd suggest you check out https://wiki.ubuntu.com/HelpingWithBugs and https://wiki.ubuntu.com/MOTU/GettingStarted
<Mithrandir> hunger: unsure; bigon might know.
<hunger> bigon: Which telepathy spec version will be supported in intrepid?
<hunger> Mithrandir: Thanks!
<hunger> Mithrandir: I'd like to update decibel to work well with the telepathy stuff in intrepid, but that damn spec keeps changing all the time.
<Robot101> well, you could ask us what we're planning to change and when :)
<Robot101> we could even make a recommendation of which spec version to aim for
<Robot101> when is intrepid?
 * lamont would still like to know why his hardy box has no ck-sessions
<lamont> Robot101: 8.10
<Robot101> more specifically, when is the UVF?
<hunger> Robot101: I do not really care about the spec version, but about the binaries shipped. Those will probably differ from what the spec says anyway.
<Robot101> well, I can comment on that too
<Robot101> hunger: which bits concern you?
<hunger> Robot101: Currently some of the CMs just coredump. They used to work a couple of weeks back. I need to debug that, but I do not want to waste time on debugging random versions;-)
<Robot101> hunger: hrm... they work here... :) when do they crash?
<Robot101> I'd not have expected spec changed to cause crashes in CMs
<Robot101> if they do we're doing something very wrong :D
<hunger> Robot101: gabble does coredump right after the first message is delivered. It could be something decibel specific, have not really looked into it yet.
<hunger> Robot101: I have some reports that other CMs behave similarly, but I have not verified that.
<Robot101> first incoming, or outgoing?
<hunger> Incoming.
<hunger> Robot101: I'll look into it once I find some time to do it and have some idea which CM versions will see some wider exposure;-)
<Riddell> zul: mysql is blocking kde 4 getting installed, any chance of a fix for that i386 fail to build?
<zul> Riddell: yes its on my plate for today
<Riddell> great
<Keybuk> so, I was chatting to an Ã¼ber-scientist friend of mine last night
<Keybuk> and for no readily apparent reason, we ended up briefly discussing the whole kilobyte vs. kibibyte thing
<Keybuk> and he expressed surprise it was considered a problem
<Keybuk> pointing out something that had never occurred to me before
<Keybuk> a byte cannot ever be an SI unit, and powers of 10 are inherently irrelevant for them
<Keybuk> SI units aren't just able to be multiplied, they must also be able to be divided
<Keybuk> a tenth of a byte is a nonsense unit
<Keybuk> as would be a millibyte, nanobyte, etc.
<Keybuk> bytes are only usefully divisible by powers of 2
<Keybuk> so must therefore also be multipled by powers of 2
<seb128> Keybuk: stop chatting there and look at #ubuntu-meeting ;-)
<Hobbsee> this isn't fair.
<Hobbsee> i'm still on hardy, and gnome is broken.
<Hobbsee> this machine doesn't even know about intrepid yet :(
<stgraber> Hobbsee: maybe this computer only like unstable softwares and crash with stable ones ? :)
<Hobbsee> stgraber: actually, i think this laptop hates getting gnome of any kind installed at all.
<Hobbsee> stgraber: i actually haven't had to have a war with the installer this time, which is new.
<Hobbsee> and i suspect that my gnome is broken due to part of an upgrade done
<stgraber> Hobbsee: what's broken ?
<Hobbsee> stgraber: gnome-panel - undefined symbol error
 * Hobbsee wills the update to go faster.
<seb128> Hobbsee: what version do you use? what symbol?
<Hobbsee> seb128: don't worry, i'm hoping it'll go away in a minute.  i'm just amused.
<seb128> Hobbsee: I'm not really amused, what symbol?
<seb128> Hobbsee: and what are you doing?
<seb128> Hobbsee: !!!
<ion_> keybuk: A lot of people use millibits. Also grambits. âThis video is 20mb in sizeâ, âI have a 200gb hard driveâ. :-)
<ogra> seb128, she's upgradng to intrepid and half way through
<Hobbsee> ogra: it appears that this is actually a pre-release hardy to an hardy_updates, but essentially, yes.
<seb128> ogra: ah, pfiou ;-)
<ogra> seb128, nothing to be concerned about on your side
<Hobbsee> seb128: if i thought you'd broken something, i'd yell directly at you.
<Hobbsee> seb128: so if i don't yell at you in the next 5 mins or so, you're OK.  if i do, then you have done something bad.
<seb128> Hobbsee: well, you mention undefined symbol during upgrade which is still a bit weird
<Keybuk> ion_: bit isn't divisible either :p
<Hobbsee> seb128: yeah, i'm not sure you're supposed to restart X during an upgrade.
<seb128> Hobbsee: no, you are supposed to use update-manager ;-)
<ion_> keybuk: But at least we have grambits, thanks to the VWBS technology.
<Hobbsee> seb128: oh yeah.  i did use that a few times.
<Hobbsee> seb128: that tends to annoy me, in how it always persists in stealing focus.
<seb128> Hobbsee: but in fact you should not get undefined symbols, the library should be unpacked first
<seb128> Hobbsee: it should not display any dialog once it has started downloading and installing things
<Hobbsee> for a dist upgrade, or the standard upgrader?
<seb128> any upgrade
<seb128> maybe there is a depends not strict enough
<seb128> that's why I'm asking what symbol error you get
<Hobbsee> ah.  unsure, tbh.  i can't seem to get a terminal inside x, due to the lack of gnome-panel.
<jkvd> who is on bash
<seb128> right click on the desktop and create a launcher there ;-)
<Hobbsee> no right click menu, either.
<seb128> so nautilus doesn't start either
 * Hobbsee is not that dumb.
<Hobbsee> yeah, i don't think so
<seb128> you can switch to a vt and look to .xsession-errors
<Hobbsee> mmm
<Hobbsee> seb128: you're in luck :)
<seb128> ?
<Hobbsee> seb128: it all works, when the update finished.
<seb128> good ;-)
<Hobbsee> ahhh, lovely X.
<MacSlow> mvo, pitti, seb128: regarding the three patched packages (libgksu, gnome-screensaver, gnome-session) sporting "blinged up" dialogs... I've tested them on GeForce/i965/R200 now on compiz (with and without blur) and metacity (with and without compositor)
<pitti> yay bling!
<MacSlow> mvo, pitti, seb128: always works never crashes :)
<ogra> MacSlow, from a classmatePC POV ... is ram usage affected without composite ?
<MacSlow> mvo, pitti, seb128: pending (and also wanting your feedback) is to use the currently used gradient nor no gradient (uses theme-colors)... also waiting for some artistic feedback from kwwii
<ion_> macslow: Screenshots, please? :-) I saw the WIP version, but what does the current thing look like?
<MacSlow> ogra, if there is not composite the old look will be used
<ogra> good :)
<ogra> i need to run my gnome in 100M :)
<ogra> every byte counts
<MacSlow> ion_, http://people.ubuntu.com/~mmueller/with-or-without.png
<MacSlow> ion_, the nasty "outter frame" of the GtkEntry is fixable (I've something locally here), but for large scale deployment of that some things in gtk+ and the used themes need to be fixed first.
<calc> liw: ponfg
<calc> liw: er pong
<ion_> macslow: The gradient is quite nice, but iâd rather it were brighter. Perhaps the normal background color on average.
<pitti> MacSlow: I prefer the slightly brighter version, better contrast
<Hobbsee> argh.
<Hobbsee> now, i need to upgrade xargs first, right?
<Hobbsee> er, findutils
<Hobbsee> yep, that's done it.
<ion_> macslow: Also, is the text intentionally not black?
<MacSlow> ion_, that's my theme (murrine)
<cgregan> mvo: Thanks for all of your help with VM builder and UME!
<pitti> tkamppeter: how can I get the ieee-1284 device ID of connected printers again? didn't that work with lpinfo -v somehow?
<ffm>  /part
<pitti> tkamppeter: cups has an API function backendGetDeviceID(), but that's inconvenient to call from a Python program
<pitti> tkamppeter: ah, nevermind me; lpinfo -l -v DTRT
<Hobbsee> ubuntu is depressingly dull at times.  there was only one piece of breakage in that hardy--> intrepid upgrade.
<emgent> ember: ping
<Hobbsee> i'm sure it should break my X, not boot, or something along those lines.
<Hobbsee> or break apt
<persia> Hobbsee: If you really want that, it can be arranged, but you might have to select some alternate packages...
<emgent> ember: is good ask first to work in some packages...
<emgent> ember: ASK to last uploader. remember please.
<ogra> Hobbsee, or give one of us ssh access ... we can quickly mees up your system remotely
<asac> ogra: my classmate hangs easily
<Hobbsee> ogra: *grin*
<asac> like starting firefox -> hang
<ogra> asac, doing what ?
<ogra> hmm
<ogra> which image ? the latest ?
<asac> its the final hardy version i installed month ago
<asac> ogra: no idea
<ogra> well, likely
<asac> i dont track your releases
<highvoltage> ogra: what did pitti do?
<ogra> i didnt build any images after that
<ogra> weird
<highvoltage> ah, gdm-guest-login :-D
<ogra> asac, the prob is that the HW is deprecated :P
<asac> ogra: thats bad. so should i downgrade to gutsy?
<ogra> the 1.0 is out of production
<asac> do you have a gutsy image with ffox 3?
<ogra> no
<ogra> i dont have a usable gutsy image at all
<asac> ogra: so there is no usable image?
<ogra> and i havent seen such stuff on the hardy image
<ogra> did you upgarde yours ?
<Hobbsee> oh, nice.  there is something else broken.  vim-gtk.
<asac> ogra: i dont think so ... i think i upgraded to get the latest fixes as you suggested at some point
<asac> but that was about the release time
<ogra> hmm
<ogra> what does the dskspace say ?
<ogra> *disk
<asac> have to boot again
<asac> was completely frozen
<ogra> thats really odd
<ogra> works fine here
<asac> ogra: unionfs is 100%
<asac> is that the rw disk?
<ogra> thats fine
<ogra> err, wait
<ogra> lemme check
<asac> running apt-get clean now
<asac> to seee
<asac> ogra: / is mounted on that
<ogra> right
<ogra> and you should actually see some free space
<ogra> gimme a sec to boot mine
<ogra> unionfs should have about 300M free
<ogra> and /var about 150
<ogra> plus ~ 400M for /home
<asac> ogra: / has 366m used ans 2.5m free
<ogra> well, thats the reason for your lockup then
<ogra> i'D love to know what fils it
<ogra> *fills
<asac> where the hell do i get the 300m from?
<ogra> the cow partition
<asac> i had  initrd.img.bak file for whatever reason
<asac> but that didnt help much
<ogra> squashfs and cow get merged in unionfs
<ogra> no
<\sh> ogra, you have cows on your partition? wasn't apt-get moo enough?
<ogra>  /boot is separate to enable kernel updates
 * \sh should go home after fighting with php crack
<asac> ogra: i dont see any boot partition here
<asac> ogra: /usr occupies 1.8G
<ogra> it gets bind mounted secretly by the initramfs
 * ogra runs du -hcs /usr ... might take a while 
<ogra> 1.7 here
<ogra> seems you installed any additional stuff that ate up your disk
<asac> i dont think it did
<asac> is there an initial package list so i can get back to defaulss
<asac> ?
<ogra> you could wipe /home and the /cow partition
<asac> i have no /cow
<asac> why would i want to wipe home? there is space on that one
<ogra> well, wipe /cow then, you need to boot from an external device for that
<ogra> its hidden by default
<ogra> asac, cat /proc/mounts
<asac> ogra: what is /cow ... why is it on there if its not used?
<ogra> to see the real world :)
<ogra> there is some hidden move and bind mounting going on
<asac> still dont understand what cow is
<asac> and whatfor that exists
<ogra> a copy on write filesystem
<asac> ill reinstall this thing, but i am sure that i didnt install anything new
<ogra> squashfs is readonly
<ogra> to get it into a writable state you use a copy on write partition and merge that through unionfs with the squashfs image
<asac> hmm ook ... anyay i think classmate desktop should have been much more sripped down ;)
<ogra> all data written will end up on the cow device
<asac> ok so it gets bigger
<ogra> will happen
<asac> because of diffs?
<ogra> ?
<ogra> the system on the cmpc has exactly 300M writable space
<asac> well ... if we have a ro fs and the diffs on top of that in cow, the space consumption increases over time without actually having more data
<ogra> and intel insisting that i put oo.o back in will cost another 100
<asac> ogra: yes, because you never changed anything in /cow :)
<ogra> well, i dont install apps
<asac> do one upgrade and /cow will fill up the 300
<asac> imo it makes no sense to allow writing at all then
<ogra> the device does only security updates
<asac> sure ... but still each ffox update brings 70m
<ogra> -updates updates need to come rolled in new images
<ogra> right thats why we will re-roll regular images with security and -updates packages
<asac> ogra: why not just distribute a live-usb stick and use the in-device disk just for data?
<ogra> thats the limitation of this compressed fs design
<asac> :)
<ogra> well, lets see
<ogra> apparently i'm not allowed/supposed to work on that level anyway anymore
<asac> sure
<ogra> the netbook image will heal the world i was told :P
<kirkland> pitti: you there?
<asac> ogra: still ... any hint how i can use your platform and put fluxbuntu on that?
<ogra> re-roll the image :)
<asac> ogra: netbook is still your business, isnt it?
<kirkland> pitti: i think we're talking past one another on Bug #235294
<ubottu> Launchpad bug 235294 in apache2 "[SRU] apache2 mpm-worker segmentation fault." [Undecided,Confirmed] https://launchpad.net/bugs/235294
<pitti> kirkland: highvoltage
<pitti> kirkland: hi, I mean
<kirkland> kirkland: :-)  hey martin.... so....
<kirkland> pitti: i agree with you, that Debian Unstable hasn't taken that fix
<highvoltage> pitti: me!
<kirkland> pitti: when I wrote "This fix is upstream in Apache2..." I meant upstream = apache.org
<kirkland> pitti: and that a sync/merge by Debian to an updated apache.org Apache2 would be desirable
<pitti> hi highvoltage :)
<pitti> kirkland: aah, ok
<highvoltage> hey pitti :)
<kirkland> pitti: what do you mean by "close the intrepid task"?
<pitti> kirkland: well, get it fixed in intrepid
<pitti> since that's a requirement of SRU
<kirkland> pitti: oh, right, okay, i can do that
<kirkland> pitti: sorry, i misunderstood, i'll do that today
<pitti> kirkland: well, it's not *that* urgent, but I was wondering about the path to get it fixed
<kirkland> pitti: well, i was sort of hoping that debian unstable would sync with apache.org's latest apache, and we'd merge that expediently
<kirkland> pitti: which has the fixes in it
<kirkland> pitti: but if that hasn't happened by now, i'll cherry pick and port the fix to intrepid
<pitti> kirkland: my primary concern with this is that we don't accitentally forget about the bug and ship intrepid with bugs which we fixed in SRUs for earlier releases
<pitti> kirkland: if it's more convenient to just wait for a new debian release, then making sure that they know about it (bug report?) and milestoning the bug for intrepid beta will work, too
<kirkland> pitti: gotcha, can do
<zul> pitti: once 8.04.1 I was going to go through the list for server related packages and make sure our patches are applied for intrepid
<mlind> calc: is there going to be another build for openoffice for hardy-proposed as openoffice.org-voikko needs a rebuild against the current version (bug #236248) ?
<ubottu> Launchpad bug 236248 in openoffice.org-voikko "Rebuild openoffice.org-voikko for the 2.4.1 upload of openoffice.org" [High,Confirmed] https://launchpad.net/bugs/236248
<calc> mlind: yep, next week
<tkamppeter> pitti, is  backendGetDeviceID() not also available via python-cups somehow?
<calc> mlind: the final release of 2.4.1 is june 10
<pitti> tkamppeter: might be too, yes
<mlind> calc: cool, probably makes sense to wait then
<MacSlow> mvo, for 8.04.1 what release-target needs to be in the changelog for a package? just "hardy"?
<persia> MacSlow: hardy-proposed, typically, as it would be an SRU, typically.
<mvo> MacSlow: what persia said, hardy-proposed
<mvo> MacSlow: also we could push it into a PPA first and blog about it or somesuch
<MacSlow> mvo, I'll go for the PPA then
<slangasek> MacSlow, mvo: uhm, what's this that's being pushed to a PPA that you still think to target for 8.04.1?
<MacSlow> slangasek, just background-UI tweaks like http://people.ubuntu.com/~mmueller/with-or-without.png
<MacSlow> http://people.ubuntu.com/~mmueller/logout-rgba.png
<MacSlow> minus the brushed-metal
<MacSlow> slangasek, and for the gnome-screensaver unlock
<slangasek> ok; why would this go through a PPA first?
<MacSlow> slangasek, testing is the main reason
<slangasek> -proposed is for testing
<slangasek> and you have to go through -proposed anyway, even if you do a PPA first
<MacSlow> slangasek, although I tested it on my i965- and GeForce-systems with compiz (with and without blur) and metacity (with and without compositor)
<slangasek> ... and the window for getting changes into 8.04.1 is closing :-)
<MacSlow> slangasek, I know that's why I don't sleep since tuesday
<slangasek> heh
<MacSlow> it's impressive how well coke still works on me
 * Hobbsee hands MacSlow a caffeine drip
<MacSlow> coke like in softdrink... just to avoid any wrong conclusion here :)
<cody-somerville> MacSlow, ;]
<Hobbsee> sure sure
<MacSlow> hey cody-somerville
<cody-somerville> Heya
<infinity> \sh: -ETOOVAGUE... What's failing, how, and how is this something I did? :)
<Keybuk> Mithrandir: I was wondering how we ejected the Live CD before calling reboot
<Keybuk> since reboot is on the CD
<Mithrandir> we try to cache everything by cat-ing it to /dev/null and then forcefully eject it, iirc.
 * slangasek giggles madly
<Keybuk> I know
<Mithrandir> I blame Kamion
 * danshearer is away: blah
<Mithrandir> danshearer: please turn off public away.
<Mithrandir> can we patch that "feature" of xchat?
<Keybuk> I'm arguing with Jeremy Katz who would like /sbin/reboot to call eject() :p
 * danshearer has found the switch; thanks
<Mithrandir> danshearer: thanks! :-)
<Keybuk> apparently Fedora have always just crossed their fingers and hoped the CD didn't eject _too_fast_ :)
<mario_limonciell> Keybuk, in "all" cases?  I would hate to have my drives eject everytime i'd reboot :P
<Mithrandir> Keybuk: that would make me very unhappy when I'm installing a server from CD.  And what Mario says.
<Keybuk> I agree
<Keybuk> thus the "arguing"
<Keybuk> I kinda want to get rid of /sbin/reboot entirely
<Keybuk> except as a handy wrapper to shutdown
<slangasek> I want eject to reboot my system
<Keybuk> slangasek: eject /sys/power
<slangasek> haha
<Mithrandir> that'd be an awesome easter egg.
<Keybuk> drag the computer in the trash </mac os>
<kees> hm, so what's the magic for dealing with the sysvutils update?
<kees> dist-upgrade is complaining
<zul> slangasek: any idea why openldap2.4.9 would be rejected in hardy-proposed the email Im getting back is the md5sums are mismatched but they look fine to me
<slangasek> zul: what's the exact wording of the error message?
<zul> slangasek: "MD5 sum of uploaded file does not match existing file in archive
<zul> Files specified in DSC are broken or missing, skipping package unpack verification."
<zul> I did a debuild -S -sa
<slangasek> zul: that means the openldap orig.tar.gz you've just tried to upload doesn't match the one already in the archive for intrepid
<zul> but its for hardy-proposed though
<zul> so I could just do a 1.1 and then do a debuild -S ?
<slangasek> it doesn't matter what it's for, you're not allowed to have two orig.tar.gz files in the archive with the same name and different checksums
<zul> ah ok
<slangasek> you need to grab the orig.tar.gz from intrepid and work from that
<zul> gotcha
<larsu> tkamppeter: Mike will not put my patch into CUPS 1.4, so it might not be there for intrepid ... he didn't say why, though
<geser> kees: it should be fixed in sysvinit 2.86.ds1-56ubuntu3, see bug #237276
<ubottu> Launchpad bug 237276 in sysvinit "hardy->intrepid upgrade fails because of sysvinit pre-depends loop" [High,Fix released] https://launchpad.net/bugs/237276
<kees> geser: ah-ha, my archive sync must not be done.  thanks.
<kees> or... it ran out of space.  oops
<lamont> slangasek: coreutils offends me
<slangasek> ...
<lamont> bug #237699
<ubottu> Launchpad bug 237699 in linux "hppa kernels need to have *FS_XATTR turned on" [Undecided,New] https://launchpad.net/bugs/237699
<lamont> slangasek: syscall (correctly) returns EOPNOTSUPP, ls decides that it should mention this, and builds fail.
<slangasek> heh
<tkamppeter> larsu, Mike simply closed the STR? Or what did he do?
<tkamppeter> larsu, seems that CUPS is already feature-frozen, seems better if you make a patch for system-config-printer (there I have upstream upload rights).
<larsu> tkamppeter: no, he said he didn't look at the patch yet, but it definitely won't be in before 1.5
<tkamppeter> larsu, for me it looks like he generally does not accept new features any more.
<tkamppeter> pitti, are you still there?
<larsu> tkamppeter: that's probably it ...
<larsu> tkamppeter: what did you have in mind for system-config-printer?
<tkamppeter> larsu, pitti, it seems that we must convince Mike to return to support the custom options with an Intrepid which fully supports them.
<tkamppeter> larsu, letting s-c-p support the custom options, letting the Common Printing Dialog support them and so making printer manufacturers using them ...
<larsu> tkamppeter: can't we just apply the patch for intrepid?
<tkamppeter> larsu, let's simply do that, if pitti has nothing against it.
<tkamppeter> I can upload into the CUPS SVN of Debian and also directly upload CUPS into the Ubuntu archives, but pitti is also working on the maintainership of CUPS ...
<tkamppeter> With the patch in Intrepid it will get intensively tested and so Mike will probably take it into 1.5 when custom options have turned standard and I am on the way to hammer them into LSB stone ...
<larsu> tkamppeter: great!
<Daviey> smurf: ping, are you free for a PM?
<philwyett> pedro_: You have just marked my bug report https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/237478 as invalid stating it is in our bug system. OK I will naturally assume that means gnome bugzilla, but when you mark invalid like this could you supply a link to the relevant bug in your system so others or myself can track it please.
<ubottu> Launchpad bug 237478 in gnome-applets "Deleted Items Panel Applet does not appear in Hardy + Updates also + Proposed  2008/06/04 (dup-of: 49594)" [Undecided,Invalid]
<ubottu> Launchpad bug 49594 in libbonobo "Bonobo-activation-server sometimes is not killed after session restart, leading to many unexpected problems" [Undecided,New]
<seb128> philwyett: no we don't do that
<pedro_> philwyett: you can fin the dup number at the top of your report btw
<seb128> or not always
<pedro_> s/fin/find
<philwyett> seb128: Just reading it now.
<seb128> philwyett: searching for the exact number can easily take some minutes, it's one time looking for you, if we do that for every duplicate we spend the bug searching for numbers for other people and don't get any work done
<seb128> philwyett: searching for the exact number can easily take some minutes, it's one time looking for you, if we do that for every duplicate we spend the day searching numbers for other people and don't get any work done
<philwyett> seb128: That's fine and understandable.
<pwnguin> heh
<seb128> philwyett: anyway in this case pedro find the number so it marked it as duplicate correctly
<seb128> but we sometime close bugs when we know it's a duplicate but can't find easily the number
<pwnguin> what i hate is finding stuff closed as a dup but not actually having a dup
<seb128> pwnguin: feel free to search the number for people who file duplicates and fix those bugs ;-)
<pwnguin> ?
<seb128> pwnguin: if you don't like bugs closed as dup but not having a dup number you can search for one and update the bug
<philwyett> seb128: Thanks to pedro_ for marking the dup. It gives me a good idea this is not going to be a quick fix.
<pwnguin> seb128: I do fix bugs. and it helps a great deal when dups are marked in LP, since there's more people to talk with for info
<seb128> pwnguin: often those bugs don't need informations
<seb128> philwyett: the duplicate number is probably wrong if you really rebooted
<pwnguin> it just saddens me a bit to see people with tens of thousands of related bugs yet too busy to find the duplicates
<seb128> philwyett: the other bug is about issue after login out and login in again
<philwyett> seb128: Yes there are some differences.
<seb128> philwyett: to be honest your bug is over one page of description, which is just too much, we get hundred of bugs every day, short descriptions and clear description make the job much easier
<philwyett> seb128: Well, I get it if they are short and sweet and get it if they are verbose - Can't win. :-)
<seb128> philwyett: if I understand correctly your bug, it's simply "the trash applet count is not updated correctly"?
<philwyett> Looks like something like that.
<seb128> philwyett: what doesn't help is that your use wrong words, I guess that "Deleted Items Applet" is the trash icon for you?
<seb128> philwyett: also describing several issues in a same bug doesn't work correctly
<seb128> philwyett: is your user directory on nfs or similar?
<philwyett> seb128: The 'About' for the bin in the bottom right hand corner of the bottom panel is 'Deleted Items Applet'. So that what I use.
<philwyett> seb128: This is a laptop and is a default install. I don't use nfs.
<seb128> and the file is on your local ubuntu directory?
<philwyett> Yes
<seb128> also you didn't change the icon theme?
<philwyett> Changed nothing, install then update. No settings changes at all.
<seb128> ok, dunno then, but the bug is of no use now since you reinstalled and you can't provide required details
<seb128> dunno about the icon issue
<seb128> the refresh count not updated seems to be a monitor issue
<seb128> the context menu being active is yet another bug and a duplicate
<seb128> some hints for next bugs you report:
<seb128> - try to have a short and clear description
<seb128> - describe easy steps to trigger the issue if you can
<seb128> - don't list several issues on the same bug
<seb128> if you look at the gnome-applets bugs there is several bugs about the icon and count not updating correctly
<philwyett> seb128: OK, will do.
<seb128> bug #34247 for example
<ubottu> Launchpad bug 34247 in gnome-applets "Trash always empty." [Medium,Confirmed] https://launchpad.net/bugs/34247
<philwyett> seb128: Search time is also an issue for me. Have customers too deal with. Will try to dig for dups the next bug I report.
<seb128> understable, that's an issue for the bug triagers too ;-)
<philwyett> :-)
<pwnguin> i kinda wish lp had a public dataset to train bayesian dupefinders on
<pwnguin> not sure if bayesian is really what is called for
<pwnguin> but some kind of intelligent search
<seb128> it does have some intelligent dups listing
<seb128> it lists bugs which have a title similar to the one you try to open when you create a bug
<pwnguin> do we have any way currently to evaluate how well that works?
<seb128> not that I know
<emgent> Security Meeting now on #ubuntu-meeting
<Ng> do we think seahorse gpg key password prompts appearing behind other windows is a bug in compiz or seahorse?
<seb128> Ng: we don't use seahorse but gnome-keyring by default and the focus goes correctly to the entry on my installations
<seb128> so if you use seahorse I would say it's a seahorse issue
<persia> Ng: I use seahorse, and it works properly for me, but I don't use compiz.
<Ng> seb128: hmm, even though seahorse is in ubuntu-desktop?
<seb128> Ng: seahorse manages the keys but doesn't ask for gpg passwords
<Ng> things like enigmail seem to be making it do so, because it acts as a gpg agent, but I'm prepared to believe that's my personal setup somehow :)
<seb128> or I'm being confused again
<seb128> wait
<Ng> (it actually seems to conflict with gnupg-agent, even though the packages don't conflict - if I have both running, neither works)
<seb128> gnome-keyring asks for ssh passphrases
<seb128> you are right, seahorse still do gpg
<seb128> ok, so I'm using it and compiz and I've no focus issue
<seb128> the dialog decoration is color in a way which would indicate the dialog doesn't get the focus but it's on the first plan and it gets whatever I'm typing
<Ng> hrm
<seb128> s/color/colored
<Ng> it steals keyboard input here, doesn't get focus and doesn't get raised
<Ng> i have some compiz window matching rules though, which might be confusing things
<seb128> right, try using a stock compiz config to see if that makes a difference
<persia> Ng: That sounds like a bug in the matching rules.
<Ng> they're supposed to just be putting things on specific workspaces, but maybe I have a z-axis specified/implied somehow
<Ng> on the subject of the gpg agent stuff - would it be reasonable to have seahorse conflict with gnupg-agent? either that or have the Xsession.d scripts be aware of each other so two agents don't try and start up
<seb128> Ng: http://packages.qa.debian.org/s/seahorse/news/20080511T014704Z.html
<Ng> aha
<Mithrandir> Ng: possibly if seahorse was demoted to recommends of u-d
<seb128> Ng: I think the "only start it for GNOME" is how debian addressed the issue
<Mithrandir> gpg-agent does stuff that seahorse doesn't, though.
<Ng> hmm
<ogra> can anyone explain why ports.u.c doesnt use the same paths as archive.u.c ?
<ogra> i.e. it doesnt use ubuntu/dists but only /dists
<ogra> looks quite inconsistent
<infinity> Hrm?
<infinity> "archive.ubuntu.com/ubuntu hardy main" versus "ports.ubuntu.com/ubuntu-ports hardy main" ... What's wrong with that?
<ogra> http://ports.ubuntu.com/dists/ vs http://archive.ubuntu.com/ubuntu/dists/
<ogra> ubuntu-ports ?
<ogra> ah
<ogra> hmm
<infinity> (Okay, so ubuntu-ports is an apache redirect back to / but whatever)
<ogra> yeah
<infinity> The canonical URI is /ubuntu-ports/ not /
<ogra> not really visible
<ogra> well, i'm playing with UME builder and it actually uses http://ports.ubuntu.com/ubuntu
<ogra> which indeed doesnt work
<persia> s/UME builder/simple-mobile-builder/
<ogra> right
<YokoZar> Hmm, I'm having a problem with Planet Ubuntu (it's not publishing my posts, but the settings I gave it seem fine).  Who can I talk to about that?
<persia> YokoZar: You might ask for direction in #ubuntu.  It's really crowded, but has a wider cross-section of the community.
<soren> YokoZar: I just checked...
<soren> The URL you put in config.ini only has one post in it, which is from April 1st.
<YokoZar> soren: Weird, I just made one today, and if I click the link on the right side of the page I can see it
<soren> http://yokozar.livejournal.com/data/rss?tag=ubuntu <--- See for yourself.
<YokoZar> soren: to me it looks like I made one today on june 6th
<YokoZar> Which is very very odd
<soren> YokoZar: I don't know livejournal, but perhaps you can see it, because you're logged in as yourself, but the rest of us don't because it's not properly published?
<YokoZar> I didn't think rss feeds could use logins
<YokoZar> But a security settings problem would certainly explain it
<soren> YokoZar: RSS feeds are carried over http. You can do whatever you want :)
<YokoZar> Whoa.  Open up top and go to System->Preferences->Appearence
<YokoZar> It's worse than that, you can't change the wallpaper from that dialog by clicking either
#ubuntu-devel 2008-06-06
<calc> http://www.engadget.com/2008/06/05/broadcom-co-founder-allegedly-spiked-tech-execs-drinks-had-wa/ <- interesting
<calc> maybe that's how they managed to convince companies to use their crappy wireless chips
<ion_> Ooh, new commits! :-) https://code.edge.launchpad.net/~felix-feyertag/apt-sync/main
<pwnguin> oh dear lord
<pwnguin> does apt-sync actually work?
<ion_> I donât know about the current state of the code, but the theory is solid.
<pwnguin> what theory?
<ion_> Use old version as a basis and zsync the new one over it.
<pwnguin> hmm
<pwnguin> how the hell does zsync handle compression?
<ion_> The same way rsync does.
<pwnguin> terribly?
<ion_> man gzip, see --rsyncable
<ion_> Not really.
<pwnguin> in my tests, rsync didn't make out well on .debs
<wgrant> pwnguin: They're already compressed, so of course not.
<wgrant> Oh, like that.
<ion_> They were probably compressed without --rsyncable, and additionally, apt-sync does something like storing the offsets of the tarballs within debs in the Packages file and handle the tarballs separately, repacking them to a .deb after syncing AFAIK.
<wgrant> I see.
<pwnguin> wgrant: if they're --rsyncable compressed it's okay. i was under the impression that it was no more than a patch not in gzip
<pwnguin> i mean, the challenge is getting the repos to support the compression hit
<ion_> Now that i think of it, i donât see how handling the tarballs separately would actually help. I just think iâve seen a discussion like that somewhere (apt-sync spec? Ubuntu wiki page? I donât remember).
<ion_> How big is the repo?
<pwnguin> i asked the mirrors guys once
<wgrant> The entire Ubuntu repo of all supported archs and series?
<pwnguin> with or without .isos?
<ion_> wgrant: Yeah
<pwnguin> 250GB
<wgrant> Is that including ports?
<pwnguin> donno
<ion_> If the overhead is as much as 1%, it would be just 2.5 GiB. I bet the mirror ownerd would be delighted with the huge bandwidth savings.
<ion_> s
<Hobbsee> Mithrandir: xchat doesn't have such a feature turned on by deafult.
<pwnguin> i really dont understand why the apt-sync spec doesn't ask for re compressed archives
<pwnguin> oh right, because even if it was rsync amenable, there's the CPU contention
<Mithrandir> Hobbsee: I know it's not on by default, but it's easily turned on.  I was suggesting nuking it completely.
<Hobbsee> Mithrandir: i wish...
<ion_> Nuking what?
<pwnguin> ion_: /me is away: blah
<dholbach> good morning
<pwnguin> Mithrandir: if you're on a rampage, how about universal greetings?
<pwnguin> or rather, broadcast greetings :)
<ion_> pwnguin: Such âfunctionalityâ should be killed indeed. :-)
<ion_> Hi dholbach
<dholbach> hi ion_
<Mithrandir> pwnguin: they bother me less.
<dholbach> thekorn, pitti: thanks a lot for the fixed py-lp-bugs
<ion_> Is there *still* no REST API or equivalent for launchpad? :-)
<Mithrandir> hmm, is it just for me opening the "appearance" (gnome-appearance-properties) control panel applet eats 100% cpu?
<Mithrandir> (in hardy)
<ogra> not here
<ogra> any special theme you use  ?
<Mithrandir> human
<ogra> same here
<tkamppeter> pitti, hi
 * thekorn hugs dholbach, you are welcome
<ShashankSingh> hi ,, everyone ,,, i have a ubuntu 6.0.6 dapper ,, how can i get qt 4.4 or 4.3 without updating  my system,, i thinking of compiling it but are there any repo arounf which could provide it ,,thanks for help :)
<RAOF> ShashankSingh: You'll need to build from source; the only other option would be if qt 4.4 was in the dapper-backports repository, but that's quite unlikely I think.
<RAOF> Also, not really a question about the development of Ubuntu, and hence off topic :).
<ShashankSingh> sorry for that:)
<dholbach> hey giskard
<tkamppeter> I want to set up a Debian package repository, from where one can download and update via apt-get. Someone knows any HOWTO or so where I can see how to arrange the packages on the server and how to index them?
<tkamppeter> [Resending, server connection seemed to be broken] I want to set up a Debian package repository, from where one can download and update via apt-get. Someone knows any HOWTO or so where I can see how to arrange the packages on the server and how to index them?
<wgrant> tkamppeter: If you want to do it for Ubuntu, you could use Launchpad's PPA service. Otherwise, there are quite a few options.
<tkamppeter> wgrant, I want to do it on the OpenPrinting server, to provide LSB-based printer driver packages for Debian and Ubuntu. If a printer manufacturer uploads an LSB RPM a script should alienize it and then index it for apt-get.
<wgrant> That sounds like pure evil.
<tkamppeter> wgrant, needed for https://blueprints.edge.launchpad.net/ubuntu/+spec/printerdriverautodownload and https://blueprints.edge.launchpad.net/ubuntu/+spec/jockey-printer-driver-support
<wgrant> Publishing alienised debs?
<tkamppeter> wgrant, these are LSB packages, designed for being alienised
<wgrant> Ah.
<tkamppeter> The intention of the LSB is to provide distro-independent packages.
<wgrant> Well, I don't have much experience with running my own proper repository - I normally only need a couple of packages so run dpkg-scan* myself.
<ion_> Also, falcon ftw.
<wgrant> falcon works.
<\sh> tkamppeter, we all know that LSB clean software distribution by ISVs is a dream...
<\sh> even when we are working hard on it...
<tkamppeter> \sh, let us not discuss whether LSB packages make sense or not, but rather tell me how to arrange .debs on a server and how to get them indexed. Is it simply running dpkg-scanpackages?
<\sh> tkamppeter, like a.u.c. or just simple ones?
<\sh> tkamppeter, https://help.ubuntu.com/community/LocalAptGetRepository e.g. simple ones
<\sh> tkamppeter, debian/ubuntu style ones with pool dir etc. http://debiananwenderhandbuch.de/apt-ftparchive.html
<Riddell> pitti: so archive day today, any chance of those MIRs?
<tkamppeter> \sh, thank you very much for the links.
<\sh> tkamppeter, were they helping? the apt-ftparchive thing is a bit theoretical with no real practical example...
<\sh> tkamppeter, https://help.ubuntu.com/community/InstallCDCustomization <- there is an example of how to use it (for tweaking the alternate cd, but you get the idea of apt-ftparchive)
<neil_d> tkamppeter: hi, I have been directed you way,  I have developed some scripts that create a CUPS printer that emails as a pdf what ever was printed.  How do I publish this so others can use/modify ?
<frafu> Hello, Anybody knows who added the ESC option to the automatic fsck at startup? I would like to ask him whether he could expand to also watch for mousetweaks to stop the fsch. In fact, pointer only users (that usually work with a software keyboard that is not available at that stage) don't have a way to stop it.
<ion_> mvo: It was nice to notice some new commits in ffâs apt-sync branch. :-) It would be really nice to have apt-sync in intrepid.
<mvo> indeed
<ion_> mvo: Do you think it would be possible to decide the final format for any apt-sync related changes to the archive and try to implement them for archive.u.c before the client side is âreadyâ? Adventurous people could begin testing apt-sync easily just by installing the development version and using their usual mirror, and when the client side gets mature enough, the mirrors would be ready for it.
<Kano> hi, whats the correct way to shutdown a running X in live mode?
<Kano> gdm stop does not work
<mvo> ion_: I wanted to setup a test repo on people:~mvo - but haven't managed yet
<tormod> Kano: if you're running 8.04 Desktop live, there is no correct way (there's a bug report). sudo killall gdm
<Kano> tormod: i thought that, well i made a workaround in my install script
<Kano> but it does not work correclty with killall gdm
<Kano> the only way to restart it is for a short time doing killall Xorg
<norsetto_> mvo: am I wrong, or recommends are also now installed by default in intrepid?
<mvo> norsetto_: you are right, they are
<norsetto_> mvo: ok, thanks
 * RainCT wonders about what program you are talking
<mvo> all of them
<Kano> tormod: is there a way to run an external script which is on the cd during startup?
<tormod> Kano: there are no hooks for it, you'll have to patch the initrd.gz
<tormod> Kano: or you (ab)use the OEM hooks
<Kano> good idea, what is executed then
<tormod> you've gotta check. if you're interested I made a small patch for casper in the initrd to run extra hooks from the cd, see https://wiki.ubuntu.com/SwissTeam/OpenExpo/2007-Bern/USBStick
<tkamppeter> I want to convert RPM packages to Debian with alien on my server. The server is amd64 and it converts amd64 packages happily, but it does not convert i386 package. Do I need one server for each platfor to offer a multi-platform repository?
<Silicium_> hi there
<Silicium_> iam searching for a postgresql maintainer
<Festor> tkamppeter, rpm 32 bits -> deb 32 bits   ;  rpm 64 bits -> deb 64bits
<Festor> tkamppeter, rpm 32 bits =! deb 64 bits   ;  rpm 32 bits =! deb 64bits
<Festor> or rpm 32 bits =! deb 32 bits and deb 64 bits
<tkamppeter> Festor, I have both 32-bit and 64-bit versions of each RPM and I simply want to make a 32-bit deb from each 32-bit RPM and a 64-bit deb from each 64-bit RPM. Only the generation of the 64-bit debs works.
<joaopinto> tkamppeter, and please make sure your target audience is aware you are providing alien(ed) packages
<Festor> O.S. 32 bits only use 32 bit packages
<Festor> But O.S. 64bits maybe use 32 and 64 bits packages
<emgent> morning
<tkamppeter> I want to provide Debian packages for as many architectures as possible (RPMs I have for each architecture) but I have only a 64-bit PC server. I do not want to install or run the packages on the server. Users should download them.
<tkamppeter> The packages are distro-independent LSB packages, designed to be alienised.
<ScottK> tkamppeter: If you want to provide Debian packages, I'd suggest making Debian packages and not depending on a tool to do it for you.
<Festor> Packages converted by alien do not have the same quality as the originals
<joaopinto> tkamppeter,you will probably need to setup a 32bits schroot for the 32bits alien
<sistpoty|work> bryce: do you happen to know where the int10 stuff, that tries to access the vesa bios can be found in xorg?
<sistpoty|work> bryce: never mind, found it already :)
<winkshark1122> hello
<BenC> pitti: So I think I'm understanding things better now...this proposal of yours is in conjunction with linux-meta, not replacing it
<BenC> pitti: but it probably means we can reduce the number of packages needed in linux-meta
<ion_> Get:22 http://fi.archive.ubuntu.com intrepid/universe nexuiz-data 2.4.2-1 [338MB]
<ion_> Now i wouldnât mind apt-sync. ;-)
<ion_> mvo: Btw, couldnât the pdiff functionality be just used as is until we get the full apt-sync? I take it it doesnât require huge changes at the archives?
<geser> ion_: isn't pdiff only diffs for the Packages files?
<ion_> geser: Yes
<ion_> They are relatively huge, and it would be nice to update quite often when running the development version of Ubuntu.
<geser> ion_: iirc from the last discussion that because Ubuntu updates the Package files hourly we would need to many pdiffs to make it usable
<ion_> Ok. :-\
<mvo> ion_: it could, but the archive u.c.c changes too often
<ion_> I wonder why Debian didnât go with zsync?
<ion_> Was it not available/mature enough back then?
<mvo> pdiff were implemented quite some time ago, I'm not sure if zsync was around then
<mvo> and pdiffs are relatively simple to implemnt
<sistpoty> tkamppeter: do I understand the PrinterDriverAutodownload spec right, that some app will download a .deb from openprinting and install it?
<impulze> http://www.flickr.com/photos/27373994@N02/2554310312/sizes/o/
<impulze> :O
<gsker> I'm having trouble getting preseed to answer a question during install.  It's starting to look like a bug.
<gsker> Any preseed experts around?
<sistpoty> tkamppeter: if so, (and I've just seen there are GPL'd drivers up there), can I after such a .deb was installed do apt-get source <nameofdriver> and get the source package?
<sistpoty> (as it's otherwise a GPL violation)
<mouz> I tried to introduce a (fake) dependency by expanding the Depends: entry in debian/control. I compiled using pbuilder. The package I added is not in the pbuilder cache (nor anywhere else on my system). I expected pbuilder to retrieve it, but that did not happen. How come? Does something somewhere understand there is no real dependency?
<ion_> pbuilder only installs build-deps. #ubuntu-motu is better for that area of questions.
<ion_> Assuming youâre learning to package stuff.
<mouz> ion_: yes. thnx
#ubuntu-devel 2008-06-07
<dsargeant> quit
<slangasek> cody-somerville: I see bug #220899 has been milestoned for 8.04.1; is someone working on this bug?
<ubottu> Launchpad bug 220899 in xubuntu-default-settings "[Hardy] Wrong default image browser" [Medium,Triaged] https://launchpad.net/bugs/220899
<cody-somerville> Not particularly at the moment.
<slangasek> cody-somerville: ok; I'm targeting it to hardy then, but dropping the milestone
<cody-somerville> Can using the power adapter for another laptop with the same volts and amp out damage my laptop?
<RAOF> cody-somerville:
<RAOF> cody-somerville: My thinking would be no.  And you only really need to care about the voltage (the ampage will take care of itself).
<RAOF> cody-somerville: But IANAEE
<cody-somerville> well, this used, apparently "almost never used" laptop has its battery in ubuntu reporting at 31% capacity.
 * cody-somerville is wondering if he caused it
<RAOF> Probably not
<pwnguin> laptop batteries go over time
<pwnguin> but i'd be careful about using adaptors across laptops
<pwnguin> if the wiring's backwards, dun dun dun
<danshearer> hello all
<danshearer> I'd like to know more about the server team in launchpad
<danshearer> https://launchpad.net/~ubuntu-server/+packages and https://launchpad.net/~ubuntu-server/+projects don't have anything listed
<danshearer> specifically, when I go to bugs.launchpad and want to report a server-specific bug, I 'Select one project' and then
<danshearer> look through every project for ubuntu-server or similar. There's nothing there. So what's the recommended way to do this?
<wgrant> danshearer: File it against Ubuntu, like any other Ubuntu bug,.
<JohnPhys> my apologies if this is better asked in #ubuntu, but part of the question is ubuntu development related.  Is there any way to use the kernel ntfs (read only) driver to mount ntfs partitions, without using ntfs-3g/fuse?  I ask because I would like to do so to rescue ntfs partitions that ntfs-3g cannot mount, but both /sbin/mount.ntfs and /sbin/mount.ntfs-3g point to /bin/ntfs-3g, and I cannot seem to find a command that
<pwnguin> a philosophical question: if you use a program to suggest ways to fill out a block of code, and it gets its ideas by reading tons of GPL'd code, is the code you wind up writing derivative of GPL?
<Mart> for some reason when i create a dynamic tunnel and then change firefox's socks config accordingly i can visit "what's my ip" sites and see expected result, but when i create a local tunnel (like: ssh -L 1080:myip.dk:80 me@server.com) I get unexpected results (usually error pages or blank pages) when i try to brows to localhost:1080
<lifeless> pwnguin: no
<pwnguin> lifeless: what if, say, you're after a sequence of steps to go from one object type to another, and google code search for results. would lifting any one result be derivative?
<lifeless> uhm
<lifeless> so this is basic copyright law right?
<lifeless> anything less than ~ a paragraph is usually not copyrightable anyway. call it 4-5 lines
<pwnguin> really
<pwnguin> so small patches have no copyright?
<lifeless> IANAL etc etc
<lifeless> they are derived works, but below a certain point its very hard to claim (c) on them, yes
<lifeless> like
<lifeless> "I am superhuman" (c) Robert etc
<lifeless> not copyrightable go away :)
<pwnguin> alright; if intepreted that a single liberation of code is fine, i wonder if you use such a tool repeatedly, whether you might cross the line
<lifeless> I would expect so
<lifeless> so
<lifeless> liberating a single line from a copyrighted work is different
<lifeless> because the whole work is copyright
<lifeless> its fair use that allows you to do that
<lifeless> rather than the content not being copyrightable
<pwnguin> its just a bit interesting because i just watched a google tech talk where a guy proposes a tool that basically does all this
<lifeless> and to add confusion, a patch has a dual, which is the entire derived work
<lifeless> say I have a 1000 line program
<lifeless> and you add 2 lines
<lifeless> you now have a 1002 line program
<lifeless> thats copyrightable
<pwnguin> im a bit curious whether lifting large blocks of code (smaller than a file, smaller than a function even) without caring about the origin is a good idea
<lifeless> but a patch describing just your work isn't. seriously confusing :P
<pwnguin> the speaker didnt say a word about copyright or license
<lifeless> bad idea
<lifeless> you might liberate bad code :P
<pwnguin> and nobody asked, so either it's obviously not a problem or obviously nobody cares =/
<pwnguin> their idea is really to poll lots of open source projects for use of APIs and let it do stuff like suggest exception handling or tranforming object types to meet api requirements etc
<pwnguin> many of which probably aren't GPL'd, some of which are probably poorly licensed period
<pwnguin> but its not too hard to imagine a distant future where larger portions of programs are written by agents trained on GPL'd software
<pwnguin> and suddenly I'm glad I'm mortal, because I'd hate to see the day where a copyright case comes down to whether or not a program intelligently synthesized ideas as an expert, or stole existing practice
<pwnguin> back to something productive, like tablet keys and xev
<pwnguin> the title of the talk though was data mining open source; quite strange that he never mentioned open source at all
<Hobbsee> woot.  <3 listadmin with filters
<wgrant> Hobbsee: Hm, I've not used filters with it before. How does one do that?
<Hobbsee> wgrant: they're documented on the manpage.
<wgrant> Ah, that would make sense.
<Hobbsee> oddly, yes.
<emgent> morning :)Ã¹
<sistpoty> lamont: could you take a look at https://answers.launchpad.net/soyuz/+question/34821 please? the build-depends-indep thingy is really puzzling me
<Le-Chuck_ITA> please someone take a deeper look at https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/152187
<ubottu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Medium,In progress]
<Le-Chuck_ITA> there is an user (Tom) who provided lots of patches for toshiba and looks like nobody is taking care of his work
<Le-Chuck_ITA> someone of the bug squad might perhaps try to convince developers to take a look
<Le-Chuck_ITA> thanks a lot and bye
<emgent> heya
#ubuntu-devel 2008-06-08
<LucaCappelletti> hello :)
 * Keybuk wonders why his first instinct when writing a document is still TeX
<DktrKranz> could a sponsor for main review scons merge ( bug 226783 ) ? thanks
<ubottu> Launchpad bug 226783 in scons "Merge scons 0.98.4-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226783
<Nikratio> ï»¿I would like to display a notification message in the system tray from a cron script, similar to the one presented after a kernel upgrade. How can I do that? I couldn't find any hint in the postinst script of the kernel images..
<laga> you're probabyl looking for the notification daemon
<Nikratio> laga: might be. So how can I connect to it / use it?
<RAOF> Actually, you're probably after update-notifier.
<laga> yeah, what he said. :)
<RAOF> Basically, you want to dump a file in /var/lib/user.d.  The kernel postinst should be doing this; that's what you're looking for.
<Nikratio> Is the format of the file documented somewhere? It seems there are some special headers in there
<RAOF> I don't believe that it is.  Or, at least, I don't recall finding such documentation when I was writing one for Xgl.
<Nikratio> I just dropped a file there and it didn't do anything
<stdin> in /var/lib/update-notifier/user.d/ ?
<Nikratio> yes
<laga> is update-notifier an ubuntu specific thing?
<RAOF> Yes.
<laga> that'd explain the lack of documentation :)
<Nikratio> I just downloaded the source. There seems to be some documentation in there
<Nikratio> Ok, one also has to touch /var/lib/update-notifier/dpkg-was-run
<Nikratio> but this is actually not the kind of message that I meant
<Nikratio> With update-notifier, one has to click on the small lamp icon and then the message is displayed in a window. I want to generate a message that directly pops up in the (default) lower right corner
<Nikratio> Ok, I got it. If someone else is interested: such messages can be generated with the libnotify-bin package.
<laga> cool, thanks
<brandonperry> is gdmsetup broken?
<brandonperry> never starts for me, just hangs
<brandonperry> hrm, nevermind
<brandonperry> just took forever to start
#ubuntu-devel 2009-06-01
<mohbana> ok i;ve got to go
<slangasek> Caesar: aha
<calc> hmm it didn't find any errors, i guess i will reinstall and see what it does
<calc> if my drive keeps getting weird errors after that i will ebay it since it likely is a miscommunication between the drive and the laptop (it has a drop sensor in the drive itself, plus the one in the laptop)
<calc> then i will just need to get a drive without the sensor
 * bluefoxicy waits 10 minutes for evolution to start
<TheMuso> c
<nixternal> bluefoxicy: 5 minutes to go
<nixternal> use Mutt, it is instant :)
<bluefoxicy> nixternal:  I started it 10 minutes ago, still waiting.
<bluefoxicy> is this ever gonna finish
<bluefoxicy> finally
<Caesar> slangasek: the patch to fix it is hilarious
<Caesar> I should update the bug with it
<lifeless> bluefoxicy: you're running karmic?
<bluefoxicy> lifeless:  no
<lifeless> bluefoxicy: jaunty?
<bluefoxicy> yep
<lifeless> hmm
<lifeless> well, file a bug upstream, keyword 'perf', and be sure to grab a strace or other analysis to be able to say broadly whats wrong
<slangasek> calc: OOo in karmic seems to have silently switched to using the system librdf0 again, pulling 500K of libs onto the CD - is this offset by a size decrease in the OOo packages themselves?
<slangasek> boo, what happened to the "how to version security updates" description from https://wiki.ubuntu.com/SecurityUpdateProcedures?
<slangasek> ah, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation now
<MacSlow> kenvandine, hey there
<MacSlow> kenvandine, were you able to get any of the laptops running with the projectors at the last plenary session at UDS on friday?
<bryce> pitti: I seem to have not escaped UDS without bringing ubuflu home with me.  I'm taking today off sick
<slangasek> eep
<slangasek> if bryce is sick with the ubuflu, I guess it's only a matter of time before I'm incapacitated
<bryce> slangasek: yeah you're the last pdx mafia left standing
<slangasek> maybe I acquired immunity by also being the only pdx mafia member to do karaoke
<bryce> ahh
<bryce> heya rickspencer3
<rickspencer3> hi bryce
<MacSlow> bryce, just everybody got it :/
<slangasek> bryce: so I guess I can't pester you about this sudden X behavior change where xrandr calls are crashing the server even though there've been no changes to the server packages in jaunty lately :)
<bryce> MacSlow: UDS=PetriDish
<slangasek> (that's ok, I seem to have a useful error message in gdm log, so I'll file a bug :)
<MacSlow> bryce, *g*
<rickspencer3> bryce: if you're sick, take a day off
<rickspencer3> ;)
<bryce> rickspencer3: yeah I think so
<rickspencer3> you don't want to get everyone in #ubuntu-devel sick, right
<bryce> hehe
<bryce> *cough* *cough*
<MacSlow> For everybody not seen yet, a quick screencast of the "cairo on the GPU"-proof-of-concept -> http://macslow.net/clips/gl-fragment-curves-1.ogg (still uploading though)
 * persia hands bryce a handy mask
 * rickspencer3 disinfects monitor
<MacSlow> agateau, salut
<agateau> MacSlow: guten tag!
<kenvandine> MacSlow: no, we didn't
<kenvandine> rickspencer3: your up early
<rickspencer3> kenvandine: yeah, couldn't sleep
<kenvandine> i am filling out my swap day form :)
<rickspencer3> (I'm not really here, I'm taking vacation until Thur ;) )
<bryce> mm jet lag
<rickspencer3> hehe
<bryce> yeah got that too
<rickspencer3> bryce: kenvandine: I actually like the Europe to Seattle Jet lag starting on day 2 (day 1 I am just whipped)
<kenvandine> i was too
<kenvandine> i felt exhausted by 3pm
<slangasek> oh wow, this is the worst rendering of 'ff' by firefox that I've ever seen
<mterry> slangasek: Oh, I realized over the weekend why the 'Copyright' field in the proposed debian/copyright spec is optional: for public domain items
<slangasek> mterry: right, I disagree with this interpretation - the 'Copyright' field is the right place to declare that a work *is* public domain :)
<mterry> slangasek: Ah, the examples use the license field.  OK, as long as you were aware of the use case
<ogra> hmm, shouldnt PCIID '8086:2a02' be unblacklisted in karmic ?
 * ogra was hoping for composite after the upgrade
<Tm_T> that is what exactly? (I'm curious)
<ogra> intel
<Tm_T> ah, roger roger
<ogra> i965
<Tm_T> ah, that beastie
<ogra> bryce, shouldnt 8086:2a02 be un-blacklisted in the karmic intel driver ?
<bryce> ogra: yes
<ogra> weird
<ogra> Blacklisted PCIID '8086:2a02' found
<ogra> aborting and using fallback: /usr/bin/metacity
<ogra> thats what i get in ~/.xsession-errors trying to switch to compiz
<bryce> the blacklisting is in compiz, not in the intel driver
<ogra> ah
 * ogra edits
<ogra> wow, decent alt-tab behavior is back ...
<maxb> Is it intentional that syncs from debian don't cause email to karmic-changes@ ?
<james_w> maxb: auto-syncs yes, manually requested syncs should
 * maxb was a bit surprised when a bunch of things showed up in update manager but not in changes email
<maxb> If that was an autosync, would that normally sync every eligible package? I was expecting a linphone update on the next autosync but it doesn't seem to have happened
<Tm_T> maxb: nice that you mentioned linphone... (:)
<james_w> maxb: it would do normally
<Tm_T> maxb: dunno if you need to know, but I mention, https://lists.ubuntu.com/archives/kubuntu-devel/2009-June/002901.html
<slangasek> it may not have been built yet?
<maxb> It's not build on ia64 or mipsel yet - that matters?
<slangasek> no, that doesn't matter
<slangasek> I mean that the source may be synced to Ubuntu and the binaries may not be built yet
<maxb> rmadison says no, but that could be out of date
<slangasek> it is
<slangasek> fwiw :)
<maxb> oh
<maxb> right, nothing to worry about then
<calc> slangasek: i think so, it should be anyway since when not using the system rdf it ships rdf in its own packaging
<calc> grr i somehow didn't manage to reinstall grub correctly when i restored my laptop, i can't get it to boot :(
<slangasek> calc: well, it also pulls in things like redland-utils as recommends, which I think might've been the reason we went this way for jaunty?
<calc> iirc one of the reasons i disabled it at least was due to thinking the internal copy worked better but i talked to rene and he said the system one worked as well (which he was already using at the time), i suppose we could demote its recommends(?)
<calc> did vol_id go away in karmic?
<ogra> calc, yes
<Kano> calc: how did you try
<calc> it claims i don't have it and that if i install udev it would be there... which udev is already installed
<ogra> use blkid
<calc> i'm trying to make sure my uuid's are correct
<calc> ogra: ok
<calc> doh i am using the wrong uuid in grub somehow
 * calc updates it and hopes it works
<calc> it worked, no idea where i got the previous uuid from, that was strange
<slangasek> what's the status of pulseaudio in karmic?
 * slangasek just dist-upgraded, and pulseaudio isn't working
<calc> slangasek: not sure i think TheMuso and crimsun were intending to fix it up soon after UDS
<slangasek> calc: what is it that needs fixing up? :)
<slangasek> I don't see any matching bug reports, and the error message is opaque as usual
<calc> slangasek: i don't remember the details, sorry
<calc> but i don't think it related to it not working at all, just to make it work better in some cases
<slangasek> TheMuso, dtchen: ping
<slangasek> Jun  1 07:42:24 dario pulseaudio[4693]: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0 name=pci_8086_27d8_sound_card_0 card_name=alsa_card.pci_8086_27d8_sound_card_0 tsched=0"): initialization failed.
<slangasek> 'swhat I get
<persia> slangasek, Does direct access through ALSA work?
<slangasek> persia: how can I trick GNOME into doing that, given the pulseaudio autospawn nonsense?
<persia> slangasek, aplay?
<calc> persia: we aren't routing alsa through pulse yet are we?
<persia> But more importantly, when you get that error, pulseaudio is failing to load the alsa module, so it's not grabbing the card.
<persia> calc, Hrm.  I don't think so, but I could be wrong (I'm still cleaning up some infrastructural issues before upgrading to karmic)
<slangasek> persia: well, yes, that much is clear; I don't find that this makes it particularly diagnosable, though
<slangasek> aplay doesn't throw errors; it also doesn't give me sound
<persia> slangasek, Hrm.  That's probably true.  Did I actually understand the deep stack, I'd probably be asking you questions about your kernel conf and comparing to that output line, but I'm not prepared to interpret the results if you gave them to me.
<persia> If aplay doesn't give you sound, you've very likely an issue loading your audio card driver.
<slangasek> the driver is loaded
<slangasek> and if I switch to OSS, I get sound
<loic-m> ogra: ping
<persia> I think I had that bug once.  I ended up disabling OSS.  Something about the device being captured by the OSS compatibility layer, I think, but I don't really understand it.
<persia> But I am sure that it's not pulse if aplay also doesn't work.  Doesn't really help explain the issue though.
<slangasek> eh, except my understanding is that alsa now autospawns pulse by default, so just running 'aplay' *is* pulse
<slangasek> if I try to point aplay at the sound card explicitly, I get a 'Sample format non available' error instead
<persia> That's more useful.  You can fiddle with -f, but it would depend on you having the right file.
<slangasek> "the right file"?
<persia> slangasek, A file in the format you specified.
<persia> (which you may be able to create with arecord, but not if it isn't working)
<slangasek> except I didn't specify a format
<slangasek> it's a .wav file, and it knows what format it's in and it refuses to play it.
<persia> Ah.  That usually indicates either that your sound card doesn't support the format or that there is a negotiation issue.
<persia> (one of the things pulse does is resample everything before submitting to the card to reduce these issues)
<slangasek> gives me no feedback about what format it wants, though
<persia> Unfortunately, I forget how to get that information :(  Maybe dtchen will come around at some point.
<slangasek> bug #382440 opened, in the meantime
<ubottu> Launchpad bug 382440 in pulseaudio "[karmic] Failed to load module "module-alsa-card": initialization failed" [Undecided,New] https://launchpad.net/bugs/382440
<slangasek> persia: nah - if I manually neuter alsa to not autospawn pulse, then alsa playback works fine
<persia> It's not supposed to do that.  Now I'm confused, and have all the more incentive to upgrade soon.
<persia> I wonder if pulse is trying to attach to the pulse pcm in a loop or something.
<slangasek> oh, that's interesting; now I've reset everything to permit autospawn again, and it still works
<slangasek> and pulse is running, and attaching successfully
<persia> Right.  Quick, before you lose it, save the entire history of what you've done.  You may need it again.
<slangasek> heh
<slangasek> TheMuso: bug #379092> hmm, from what I remember being discussed in February, that sounds like a regression to me, as adjtime shouldn't be used even if it does exist
<ubottu> Launchpad bug 379092 in powerpc-utils "Sync powerpc-utils 1.1.3-24 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/379092
<wip> hi sorry for the noise, but we need a new rt-kernel release. too many bugs in the actual release
<alex-weej> MacSlow: are you trying to make a Cairo backend like Glitz?
<alex-weej> i'm still a bit confuses as to what you are making
<mweichert> hello, I'm trying to learn how to create pam-auth-update packages. However, I see common examples of modules using key,value pair control-flags for modules, such as that appear here: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
<mweichert> I'm used to the following module control-flags: required, sufficient, optional
<mweichert> I've never come across something like this before, till now: [success=2 default=ignore]
<mweichert> where can I read about this format?
<mweichert> I've found a little info here: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html
<holoway> mweichert: that's where I remember learning about that syntax
<holoway> and the other extensions, like skip
<holoway> (which is good for ldap)
<mweichert> holoway: can I ask you to look at this brief example if you don't mind: http://www.pastie.org/496843
<holoway> mweichert: sure
<mweichert> is line 6, saying if this module succeeds, to go line 11
<mweichert> success=2, meaing skip the next two modules ?
<holoway> mweichert: exactly
<mweichert> holoway: ok, perfect - thanks
<holoway> it's a sneaky bit of pam magic
<holoway> but it's a very good idea, and that's a nice pam configuration, actually
<holoway> in the past, I've used that syntax to handle things like skipping the LDAP checks for local users, etc
<mweichert> holoway, yeah, I can see it's usefulness. I actually find it easier to read than using the other control-flags (now that I understand the syntax)
<holoway> oh yeah - it's the way to go if you are building a complicated pam structure
<holoway> once I started thinking about it like a kind of funky firewall syntax it made more sense - default policy is denial, success usually jumps you out of the control flow, etc.
<mweichert> holoway, I'm liking it. :)
<mweichert> holoway, is success=end the equivalent of success=ok or success=done ?
<holoway> mweichert: I think so, but it's been a while since I've dug around inside of pam
<holoway> mweichert: I believe the difference is that success=ok means you move on, and you are just contributing to success
<holoway> mweichert: wheras 'end' means 'I am the canonical answer - success has happened, stop processing the rest of this phase'
<holoway> and die is the same, only for failure ('I am the ultimate failure, don't ask any other modules in the stack')
<mweichert> holoway, ok - thanks.
<MacSlow> alex-weej, if I'll add my stuff to glitz or do it separately in the end I cannot tell yet
<MacSlow> alex-weej, it's too early
<mterry> It seems to be the case that --install-layout=deb isn't needed anymore for python2.6?  Without it, on a karmic-built package, the modules correctly get put in /usr/lib/python2.6/dist-packages.  Was that just a temporary necessity?
<aliciapg> was kdenlive removed from kde recently?
<Tm_T> removed from where exactly?
<aliciapg> i tried to submit a bug report for kdenlive upstream but it was no longer listed as one of their projects anymore in bugzilla
<Tm_T> aliciapg: ah, you might like to ask #kde and/or #kdenlive then?
<aliciapg> thanks i'll try that
 * Tm_T wonders why ask in here in first place anyway
<mterry> Tm_T: Because this room has such helpful people!  :)
<Tm_T> where?
<aliciapg> because kde was non responsive
<Tm_T> interesting
<mweichert> can someone help explain the differences to me between Primary, Additional, Initial types used in pam-auth-update packages please?
<mweichert> Primary vs Additional - I take it that the primary type is used if there is no other packages enabled?
<dtchen> slangasek: seems a lot like the dbus races that were floated about last cycle, will look in a bit
<dtchen> slangasek: in the meantime, disabling PA's autospawn is accomplished by echoing "autospawn = no" into ~/.pulse/client.conf and killing pulseaudio
<maxb> mweichert: I'm trying and failing to find actual documentation, but it looks to me that Primary ones provide an actual method of authenticating users, etc., whilst Additional ones are merely ones which hook into pam to provide additional functionality
<maxb> i.e. without a Primary one, PAM would be useless/crippled
<TheMuso> slangasek: but since adjtime won't exist, nothign will be done.
<TheMuso> slangasek: and pong re whatever youw atned to talk to me and dtchen about.
<slangasek> mweichert: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
<slangasek> TheMuso: right, point is whether it's wrong even *if* /etc/adjtime exists
<slangasek> TheMuso: the ping became bug #382440.
<ubottu> Launchpad bug 382440 in pulseaudio "[karmic] Failed to load module "module-alsa-card": initialization failed" [Undecided,Incomplete] https://launchpad.net/bugs/382440
<TheMuso> slangasek: ok thanks
#ubuntu-devel 2009-06-02
<Viper550> I know this has to do more with Ark and RPM than Debian, but bero did a write-up on package management. http://arklinux.wordpress.com/2009/06/02/another-look-at-linux-packaging-systems/
<YokoZar> slangasek: I recall you taking notes during this spec: https://blueprints.launchpad.net/ubuntu/+spec/desktop-mime-execution-policy   -- did you paste them somewhere?  there's no link at that page
<bluefoxicy> holy crap
<bluefoxicy> a kernelu pdate fixed busted GTK file picker?
<YokoZar> bluefoxicy: what kind of busted?
<YokoZar> GTK file picker was busted for other reasons...
<slangasek> YokoZar: they're still in gobby
<YokoZar> slangasek: ahh good, thanks
<YokoZar> I'll make a wiki page
<dholbach> good morning
<pitti> Good morning
<pitti> bryce: get well soon! didn't hit me too hard, just a cold, but fortunately it was Pentecost yesterday anyway :)
<TheMuso> Hey pitti.
<pitti> hey TheMuso, made it back in one piece?
<TheMuso> pitti: Indeed. Long flight, but after a good night sleep, I feel much better.
<soren> How do I find the version of the running system from a python script? Parsing /etc/lsb-release?
<dholbach> soren: run "lsb_release -rs" and parse the output? :)
<geofft> hm, /usr/bin/lsb_release is Python, and looks to do if __name__=='__main__' correctly. You could import it!
<soren> I don't think I'll be adding /usr/bin to my sys.path, though. :)
<soren> That seems like a recipe for disaster.
<ajmitch> "perfectly safe"
<juanje> soren: why don't you just use the function get_lsb_information() from the lsb_release? It's small and give you all you need
<juanje> soren: I meant to copy the function, instead of import the script
<pitti> copying code would defeat the idea of lsb_release
<pitti> e. g. it wouldn't work on Debian
<soren> pitti: How do you do it from apport? Parse the output from lsb_release?
<pitti> lsb_release is supposed to be executed, not sourced/copied/imported, so the only safe way is to call it
<pitti> soren: yes
<soren> Cool, thanks.
<pitti> soren: so if you care for portability, run lsb_release; if you don't, just read /etc/lsb-release
<pitti> (the latter is magnitudes faster, of course)
<soren> Portability isn't a great concern, but speed even less so :)
<Lutin> Riddell: ping about eet
<jamesh> soren: if you want speed, reimplement lsb-release in C :)
<jamesh> lsb_release, even
 * soren passes on that opportunity
<juanje> pitti: maybe, but probably the best is not to have to run the lsb_release, but have it as a lib, so you can use from python easily
<pitti> smb: jaunty-proposed queue has l-r-m which "Bump ABI to 13 for proposed kernel"; however, there is no -13 in jaunty-proposed
<smb> pitti, Let me check. I thought I had uploaded all three during uds
<pitti> juanje: agreed, but that needs to be defined in LSB then
<pitti> smb: there was a linux upload which reverts a previous change which introduced a regression
<pitti> smb: ah, indeed: http://launchpadlibrarian.net/27192879/linux_2.6.28-13.44_source.changes
<pitti> smb: that bumps the ABI
<pitti> smb: (ugh)
<smb> pitti, yeah that bump the abi again for the remove
<pitti> smb: ok, nevermind then
<jamesh> soren: feel free to pick another language that results in a fast to load binary
<smb> pitti, Ok, yeah sorry about that. The sound changes required another one
<smb> pitti, I'll follow up with meta in a bit
<pitti> smb: ok, thanks
<Riddell> Lutin: hi
<Lutin> heya Riddell
<Lutin> Riddell: I was curious about why you reverted eet to an older version with a 'new upstream version" changelog entry
<Riddell> Lutin: let me work out where I got that from
<Riddell> Lutin: it's from http://dev.openbossa.org/trac/qedje/
<Lutin> Riddell: well, qedje uses eet 1.1.0 in Debian and I haven't seen any bugreport so far
<Riddell> mm, and I'm pretty sure that page is out of date
<Lutin> (sure, the version in ubuntu was rev365xx)
<Lutin> Riddell: anyway, no big deal, just wanted to point it out
<Riddell> it's also linked on http://code.openbossa.org/projects/qedje/pages/Home
<Riddell> which is the new qedje page
<Lutin> Riddell: maybe they needed some bugfixe that happened right before, ot they just picked whatever SVN rev was at that time
<Lutin> anyway the interface sure didn't change
<Riddell> Lutin: there's also an eet 1.2
<Lutin> Riddell: I know, I actually uploaded it to experimental
<Lutin> but it depends on libeina, and I'd rather not have it in ubuntu unless there's a very valid reason for it
<Riddell> oh aye, I remember that now
<Riddell> now I just need to remember why I thought the 1.1 wasn't good enough :)
<Lutin> Riddell: you know you uploaded an /older/ version than 1.1, don't you ?
<Riddell> Lutin: well presumably I didn't at the time and I must have thought it was newer
<Riddell> Lutin: where can I find the svn revision of 1.1?
<Keybuk> thought of the day: PPAs have killed Backports
<lifeless> hallelujah?
<directhex> PPAs don't require paperwork
<Riddell> PPAs don't have a build score of 0
<directhex> build scores of 0 don't require paperwork
<Lutin> Riddell: by checking out the svn and having with svn log, or you can look at the git-svn-id associated to the upstream-vcs/1.1.0 tag here: http://git.debian.org/?p=pkg-e/libs/eet.git;a=tags
<lifeless> anyone up for some sponsoring?https://bugs.edge.launchpad.net/ubuntu/+source/pyrex/+bug/379754
<ubottu> Ubuntu bug 379754 in pyrex "deprecation warning in Errors.py" [Undecided,In progress]
<StevenK> lifeless: I'd rather a debdiff
<lifeless> StevenK: done
<Riddell> Lutin: I uploaded 1.1.0 again
<Lutin> Riddell: cool, thanks
<ogra> cjwatson, poke, could you merge https://code.launchpad.net/~ogra/debian-cd/ubuntu so we get armel images again ?
<cjwatson> ogra: done, and rolled out
<ogra> thanks
<ogra> do we really need the version check in there ?
<ogra> i would think we can just trust what lies in /srv/cdimage.ubuntu.com/ftp-ports/dists/karmic/main/installer-armel/current/images/imx51/cdrom/
<cjwatson> needs to be fixed properly with a kernel change
<cjwatson> it's not about trust
<ogra> indeed, but until thats there we'll have to bump the version for every ABI change
<cjwatson> yes.
<ogra> and given that the babbage2 patches will take some time to be sorted that might be a longer period
<cjwatson> incentive to get it fixed properly ...
<loic-m> ogra: hi
<seb128> does anybody known an easy way to replace a new line by a space? ie to change a file having a name by line to a "name1 name2 name3" etc, cat file | something
<seb128> tr -d '\n' deletes the new line but it lacks space between words
<StevenK> seb128: tr '\n' ' '
<ogra> loic-m, hey, the ubuntu-gettext domain changes in tuxtype were to please the langpack generation, i think they are still needed
<seb128> StevenK: ok, I was not far, thanks
<cjwatson> seb128: xargs
<loic-m> ogra: which langpack generation? I thought it was because the package was in main, and thus translated in Launchpad?
<cjwatson> (slightly creative option, but it's what I usually do for that task)
<cjwatson> though it does go wrong if the file has too many lines
<ogra> loic-m, right and it gets automatically picked up for langpacks through being in main
<loic-m> ogra: then what about tuxmath, who's also in main?
<ogra> same thing ... if that setting is missing thats a bug
<loic-m> ogra: I'm in touch with upstream, so I can ask them to put it (they already do something for Suse)
<ogra> good, make them do it and we can sync
<loic-m> ogra: Ok, now I can tell them about both .desktop files and we can sync
<ogra> when i maintained it the package had only a debian .menu file iirc (its quite a while ago)
<seb128> StevenK, cjwatson: thanks
<loic-m> ogra: we'll have to wait for tuxtype > 1.7.4 though, Debian still isn't using upstream .desktop file
<ogra> right, that was the prob i had back then as well
<loic-m> ogra: yes, I fixed the bug in U and contacted the DD
<loic-m> ogra: (before they didn't have a .desktop file)
<ogra> thanks for getting it sorted :)
<loic-m> ogra: thanks a lot
<ogra> the edubuntu guys will be happy to have less work
<loic-m> ogra: you're welcome. I was afraid you'd have forgotten about it, since nobody on #u-edu could tell me about the string
<loic-m> ogra: so direct contacting you was a good thing ;)
<ogra> to be honest i *had* forgotten about it ...
<ogra> its 1.5 years ago that i touched my last edu package actively
<ogra> though i probably did a dumb merge inbetween when LaserJock had no time
<StevenK> pitti: http://people.ubuntu.com/~ubuntu-archive/NBS/ is empty, and I don't believe it, could you check?
<pitti> StevenK: I wish!
<pitti> give me a minute
<lifeless> StevenK: so, was the debdiff ok?
<StevenK> lifeless: *cough* Got distracted
<Hobbsee> kirkland: in my "what was known as screen profiles", i've got a "49m".  What does it stand for?  :)
<Hobbsee> is it hte remaining time of my dist-upgrade, or something?
<Hobbsee> oh, uptime.  never mind.
<pitti> StevenK: archive-cruft-check.py -n /srv/launchpad.net/ubuntu-archive/
<pitti> ImportError: No module named ftpmaster
<pitti> cprov: ^ can you please look at this?
<StevenK> \o/
<lifeless> StevenK: so, how do I go about undistracting you?
<StevenK> lifeless: Visit?
<lifeless> mm, not still I'm less sinusy
<lifeless> I'll settle for nagging
 * lifeless nags StevenK 
<pitti> asac: shall I drop the modem fdi from hal-info for karmic, for better testing of the prober?
<asac> pitti: i would say no. the prober is always used anyway and there are other things like modemmanager and wader that still rely on that info. i will talk to dan if we can drop the code pieces that do something with hal
<asac> (to get even more testing of prober)
<pitti> asac: ah, I see; so it's not necessary for NM?
<pitti> asac: roger, thanks
<slytherin> if a package was in depwait in jaunty on a particular arch (hppa) and the depwait is now cleared in karmic, what is the best way to make the buildd try the package again?
<pitti> slytherin: hppa is no more in karmic
<slytherin> pitti: I thought since FTBFS page shows hppa, it was still a community supported architecture. Also doko made some hppa specific uploads to java tool chain.
<pitti> slytherin, doko: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-May/000571.html
<slytherin> pitti: thanks
<StevenK> pitti: Except it is still building stuff
<slytherin> One more question. Is there any problem with powerpc buildd? I am trying to analyse FTBFS of tuxguitar - http://launchpadlibrarian.net/27258462/buildlog_ubuntu-karmic-powerpc.tuxguitar_1.1-1_FAILEDTOBUILD.txt.gz
<cjwatson> slytherin: that does seem to be powerpc-specific but the cause is very unclear. I was just getting started on looking at that one ...
<cjwatson> (bug 372243; please don't add any more tasks to that bug!)
<ubottu> Launchpad bug 372243 in texlive-base "FTBFS of other packages due to dpkg-trigger bug in texlive-base" [Undecided,Confirmed] https://launchpad.net/bugs/372243
<cjwatson> I don't think texlive-base itself is likely to be the buggy thing, but it's hard to tell at the moment
<slytherin> cjwatson: Thanks. I am subscribing myself to that bug.
<cjwatson> I also find that in general betting *against* a bug being buildd-specific is wise
<slytherin> cjwatson: I will try to build tuxguitar locally on a powerpc machine and will see if that still fails for same reason.
<cjwatson> oh, I'm not asserting that it will necessarily fail in all cases; just that people are typically too quick to think "oh, must be a buildd bug"
<slytherin> cjwatson: right. I will make sure first.
<cjwatson> the code in both texlive-base and dpkg looks correct on the face of it
<cjwatson> dpkg's source has not changed relevantly since jaunty, and I believe this bug is new in karmic
<cjwatson> it might well be one of those things you can only reproduce if you're running an old kernel (say, dapper's)
<cprov> pitti: yes, I'm on it.
<pitti> cprov: cool, thanks
<kirkland> Hobbsee: uptime :-)
<kirkland> Hobbsee: cheers ;-)
<cprov> pitti: fixed.
<pitti> cprov: you rock
<infinity> cjwatson: Seems like an odd thing to be triggered by kernel/userspace skew, but certainly possible, given that PPC is the only arch still running dapper kernels. :/
<pitti> StevenK: cron.NBS running
<cprov> pitti: I wish ;)
<StevenK> pitti: Danke
<infinity> cjwatson: (And that's my two cents before I go back to not being here)
 * ogra shakes his head 
<ogra> infinity, go away !
<cjwatson> infinity: yeah, I don't get it yet
<siretart> TB meeting today?
<Hobbsee> karmic doesn't explode after dist-upgrade.  Please fix it!
<ogra> Hobbsee, i noticed that too yesterday ...
<ogra> we should do some broken uploads
<Hobbsee> heh :)
<Hobbsee> the only thing i'm not liking so much is that konversation has a new version, which is kde4-based.  That's not good enough!
<ogra> bump it to kde5 and break it heavily :)
<Hobbsee> haha
<Riddell> what's wrong with it?
<Hobbsee> nothing, apart from me not being sold on the aesthetics of it.  (how does one change kde4 themes, without having the rest of it installed?)
<Hobbsee> and the artefacts
<lifeless> Hobbsee: willpower
<ogra> lifeless, dont you need persia's cool brain input device for that ?
<tkamppeter> pitti, hi
<Hobbsee> lifeless: heh :)
<cjwatson> siretart: yes, 1400 UTC
<kirkland> Keybuk: ping
<ion_> ogra: OCZ NIA? :-)
<ogra> something similar, yes
<siretart`> cjwatson: ok. btw, I'm a bit unsure why ffmpeg is again on the meeting agenda. If I remember the meeting logs correctly, mdz wanted to confirm the course of action with sabdfl, but either that didn't happen or there were no objections. Do you know if there is actually something to discuss on that topic?
<ogra> he had it with him at UDS and demoed it
<ion_> ogra: Is there Linux support for such devices?
<ogra> i think it did something with plain xinput
<cjwatson> siretart`: it's on the agenda because we don't typically remove things from the agenda until they're actually done
<cjwatson> otherwise we forget about them entirely
<siretart`> ah, I see
<Keybuk> kirkland: hi
<siretart`> mdz: did you catch sabdfl to confirm the course of action wrt ffmpeg?
<cjwatson> siretart`: I haven't heard of any concrete progress but it would do no harm to poke people again; unless you're going to be around anyway, I don't know that you need to make any special effort to be there
<siretart`> okay, because I'd need to leave around 14 UTC here :-/
<kirkland> Keybuk: hey, just filed a wishlist bug against upstart, inotify dir watching
<kirkland> Keybuk: ideally, i'll get bugmail from LP when that gets fixed :-)
<Daviey> Bug Status, "You wish it, you fix it" :)
<mdz> siretart`: I haven't spoken to him about it recently, but he is here and will be at the meeting
<mdz> siretart`: if there's nothing to discuss, we can skip it.  is it resolved?
<siretart`> mdz: IIRC, you wanted to check with sabdfl if what we discussed (not munging the ffmpeg source anymore) was OK and if yes, to proceed so in karmic
<siretart`> I'm unsure if we discussed enabling the encoders, but TBH, the more interesting ones are in the multiverse package anyways..
<mdz> siretart`: I was pretty sure we resolved that in a meeting, that munging the source was unnecessary
<siretart`> though h263 would certainly be interesting to users of ekiga
<StevenK> pitti: Is cron.NBS running still, or did it die a horrid death?
<lifeless> StevenK: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-doc-utils/+bug/336882 too :)
<ubottu> Ubuntu bug 336882 in gnome-doc-utils "Deprecated module md5 with python 2.6" [Low,In progress]
<lifeless> StevenK: just upload, you know you want to
<StevenK> lifeless: Maybe applying for core-dev would be quicker
 * StevenK hides
<lifeless> StevenK: when people start whinging at me to do that, sure.
<StevenK> lifeless: I'll upload pyrex, subscribe the relevant sponsor team for the gnome-doc-utils bug
<lifeless> StevenK: isn't it just ubuntu-main-sponsors? its what I already subscribed
<StevenK> lifeless: It is, yes. I haven't looked.
<mterry> james_w: Is  --install-layout=deb still needed for python packages?  Building a deb without it seems to do the right thing in Karmic.
<lifeless> mterry: check closely, site-packages != dist-packages, and also python-support does evil magic that can in principle break
<mterry> lifeless: Modules get installed to /usr/lib/python2.6/dist-packages
<mterry> lifeless: I believe that's correct
<lifeless> mterry: I suspect python-support is moving from site->dist, I may be wrong.
<lifeless> but I certainly saw something like that in pyrex
<mterry> lifeless: So you're saying that python-support will shortly (or apparently already does) do the right thing without --install-layout=deb?
<mterry> lifeless: i.e. what I'm seeing is expected and good and loverly?
<lifeless> mterry: If I am remembering what I observed.
<mterry> lifeless: Alright, I love it
<lifeless> mterry: I think its wrong, because if the build process is encoding paths into the output files, python-support will be breaking things.
<lifeless> admittedly thats a corner case ;)
<pitti> StevenK: still running, seems to be a lot
<pitti> StevenK: hah, just finished
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ looks good now, enjoy
<StevenK> pitti: Right, so I just needed to be slightly more patient.
<pitti> Riddell, seb128: any chance I could cajole one of you to binary-NEW udev-extras? It's blocking a hal upload I'm about to do, and I'd like to get it into alpha-2
<StevenK> pitti: I think I prefered it when NBS was empty, just looking at the list
<pitti> seb128, Riddell: (oh, alpha-2 is next week, nevermind; but it's still a small blocker)
<seb128> pitti: I can do that, but you can do that yourself directly too no?
<Riddell> pitti: ok (I'm doing new queue now)
<pitti> seb128: well, I'm the uploader
<pitti> and I packaged the new binaries
<seb128> I tend to no bother finding somebody else for binary new-ing
<seb128> but usually I need those for soname changes and there is not a lot to verify in such cases
<al-maisan> mterry: I believe james_w is on vacation this week.
<mterry> al-maisan: Ah, kthx
<Riddell> pitti (seb128): accepted
<pitti> Riddell: cheers!
<tkamppeter> pitti, the CUPS BZR is OK now, the two wrong files I have reverted.
<pitti> tkamppeter: I saw, thank yuo!
<persia> ion_, There's kernel support, and userspace hiddev drivers, but nothing for X yet.
<ion_> persia: Which device is it you were demonstrating?
<persia> OCZ NIA
<ion_> Ah, right
<tkamppeter> For the filters in general I will return to Poppler for pdftops, GS is a good PS/PDF interpreter, but is not very good in creating PostScript.
<ion_> persia: Iâd love to type using NIA controlling Dasher. :-)
<pitti> tkamppeter: right, makes sense; poppler upstream didn't seem entirely averse to the patch either, so that should be okay
<tkamppeter> pitti: Is there already a reaction from upstream to the patch?
<pitti> tkamppeter: I just saw the initial followup
<persia> ion_, That's the idea :)  More hands welcome if you want to hack on stuff.  I should get some packages into Karmic for basic toying about sometime this month.
<ion_> persia: Perhaps iâll purchase one when i have extra money.
<persia> At least they are about 8% of the cost of the brainfingers devices :)
<tkamppeter> Problem is that we create a new dependency of CUPS on the patched Poppler, which will need that we have to wait for the patch to hit Debian.
<ion_> persia: Does the device provide the data for all the inputs the Windowsâ¢ software provides, or does the software do heavy analysis on the data?
<tkamppeter> pitti: And depending on the maintainer of Poppler it can take long. The Ghostscript maintainer for example did not answer yet to my fixes.
<persia> ion_, It needs analysis.  The device provides raw frequency data.  There is extant software that does the analysis.
<tkamppeter> pitti, fortunately, we will not need my last Ghostscript fixes for CUPS any more when we revert to Poppler.
<bryce> pitti: good to hear, yeah I'm feeling a lot better today, just a lingering cough
<joaopinto> will karmic be using packagekit-gnome as the default app installer ?
<pitti> joaopinto: no, it's too limited
<pitti> PK still has fundamental design problems with dpkg
<pitti> such as conffiles or debconf
<joaopinto> pitti, tks
<tkamppeter> pitti, WDYT, will the Debian maintianer of Poppler accept our patch quickly so that we can proceed with CUPS?
<pitti> tkamppeter: I don't know, but even if not, we'll just reintroduce the original "different papersizes" bug, right?
<pitti> tkamppeter: or do you introduce a new pdftops command line option which doesn't exist in current poppler?
<ogra> Riddell, you rejected ldm ?
<tkamppeter> There is a new pdftops command line option, "-origpagesizes" as I did not want to modify the behavior of Poppler for other programs.
<tkamppeter> pitt, see https://bugs.freedesktop.org/show_bug.cgi?id=19777
<ubottu> Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,New]
<tkamppeter> pitti: ^^
<tkamppeter> I can also modify the patch to not use this option, but this can break other programs which use pdftops of Poppler.
<pitti> tkamppeter: eww, I see
<pitti> tkamppeter: yes, in this case this would block on the patch being accepted
<pitti> tkamppeter: however, is the current behaviour really a feature?
<pitti> it sounds a bit like --unbreak
<Riddell> ogra: the themes stuff I did
<ogra> Riddell, they were in the archive for several years now
<ogra> its three plain colored rectangles
<tkamppeter> pitti, I do not know. Currently one supplies a paper size on the pdftops command line and all pages get fit into that given size.
<ogra> they were just split out from the main package
<pitti> tkamppeter: what happens if you don't submit a paper size?
<pitti> tkamppeter: I don't understand why pdftops needs a paper size at all; after all, a PDF file should already have a proper size?
<wip> any update on the rt-kernel for ubuntu 9.04?
<wip> when to expect a new release? anyone working on it?
<Riddell> ogra: ah, you want me to remove the old packages from the archive until you can get in a SRU with the copyright notice fixed? :)
<ogra> huh ?
<ogra> i doubt its even possible to copyright a color
<tkamppeter> pitti, if I do not supply a size I get all pages fit into the size of the first page.
<tkamppeter> So one-page documents always worked with Poppler's pdftops also documents with all pages having the same size, as long as the wrapper from CUPS does not supply the default size given in the PPD.
<tkamppeter> The default paper size in the PPD is also intended to give a paper size default for a document without paper size, like a JPG or a PostScript file without size definition (the CUPS test page for example).
<tkamppeter> pitti: A document defining a paper size is supposed to be printed in that size.
<pitti> tkamppeter: that behaviour sounds like a bug to me, not a feature
<tkamppeter> The user should supply the "fitplot" option if he wants to resize a PDF document to a given paper size.
<tkamppeter> pitti, according to upstream developer Albert Astals Cid's comment #1 in gs.freedesktop.org/show_bug.cgi?id=19777 it seems to be a feature ...
<tkamppeter> pitti, https://bugs.freedesktop.org/show_bug.cgi?id=19777
<ubottu> Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,New]
<directhex> cjwatson, so, um..... do those of us without access to secret cabal mailing lists get to find out what the "mono (open discussion)" thing was actually meant to be about?
<cjwatson> directhex: at the TB review at UDS (which was videotaped, I believe), various folks expressed a desire for the TB to hold free discussion on issues of the day, partly as agenda-fillers and partly to build up its profile
<cjwatson> not necessarily with the aim of issuing anything binding but just as part of a general TB aim of having good oversight of the project
<cjwatson> I think Mono (by which I assume he meant the patent position) was simply something Mark suggested off-the-cuff as something people frequently ask about and that it would be sensible to have a position on
<Riddell> stgraber: what channel are we talking on?
<stgraber> Riddell: the release one (probably not the best though)
<directhex> cjwatson, am i allowed to be a little concerned about said discussion being moved to ubuntu-secret-cabal@lists, where people who can actually answer the TB's queries, well, aren't allowed?
<Keybuk> directhex: I meant a public ML
<cjwatson> I'm actually a little concerned about starting YA mono discussion on a public list given the amount of heat that has been generated on the subject in the past; personally I had been planning to hold a discussion on technical-board@ and CC the maintainers
<cjwatson> there's nothing actually secret, since after all we were going to hold it on IRC, I'd just like to keep the noise down
<Keybuk> we could hold it on ubuntu-devel
<Keybuk> the noise doesn't go up to 11 there
<directhex> although it WILL go to 11 if certain sites catch wind and link to it. FYI.
<directhex> cross-posting between technical-board and debian-cli might work as another option?
<directhex> in the end i'm not fussy as long as people in a position to put forward rational points of view aren't excluded
<directhex> whatever those points of view may be
<directhex> (oh, and nutcases are in short supply)
<cjwatson> directhex: is debian-cli high-profile?
<cjwatson> I don't want to exclude people, but I also don't want to try to construct something resembling a project position in the teeth of a howling gale
<directhex> cjwatson, it's not particularly high profile, no. but it's the new official list for cli (.net if you're ignoring trademarks) related topics in debian. which generally means pnet and mono.
<evand> Riddell: I am afraid I don't agree with your rejection of parti-all on account of it containing two gzipped pdf files in the source tree.  The files are not part of any resulting binaries, they're MIT licensed, and they're not generated from an available source document.
<Elbrus> Can I see the logs of this channel somewhere?
 * Elbrus wonders if infinity responded to my ping last time
<Riddell> evand: how do you modify them?
<directhex> Elbrus, i think there's an irclogs.ubuntu.com
<directhex> Riddell, a hex editor, what else?
<Elbrus> directhex: thanks
<persia> Riddel: Is the preferred form for modification a requirement for MIT licensed material?
<evand> Riddell: They're X11 licensed, it doesn't have that clause.
<Riddell> evand: we're a free software distro, we require files to modifiable
<Riddell> at least for main and universe we do
<Riddell> persia: no it's a requirement for main and universe
<Elbrus> infinity: ping, you seem to be the one that could help with bug 67544
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Undecided,Confirmed] https://launchpad.net/bugs/67544
<persia> Well, there's always pdfedit, but hrm.
<Riddell> and "I saw sladen do it once" isn't a reasonable definition of editable :)
<Elbrus> fpc needs bootstrapping on ppc
<cjwatson> directhex: I meant high-profile enough for anything posted there to turn into a firestorm
<cjwatson> Riddell: PDFs are modifiable with a PDF editor; the things that require a *transparent* file format are the GPL/GFDL and friends, not our general principles
<ion_> It seems theyâve managed to make screen rotation work a bit better in the radeon driver.
<pitti> s/transparent/preferred form of modification/
<cjwatson> I think that's just wording; the GPL says "preferred form for modification" while the GFDL says "transparent", but the effect is similar
<pitti> well, I disagree
<cjwatson> our main/universe licensing policy says that the licence must permit modification, but says *nothing* about how
<pitti> if I produce a html file from a docbooc xml file, shipping only the html file would violate the GPL
<cjwatson> if you disagree, could you point me to where it says how?
<pitti> but if a html file is written from scratch, then this _is_ the source and preferred form of modification
<cjwatson> pitti: hm, ok, but nevertheless none of that is at issue here
<persia> I think we do have some restrictions though: we don't allow pq in universe, for example.
<cjwatson> persia: pq?
<pitti> cjwatson: right, just pointing out that transparency is not the main point of the GPL, as far as I understand it
<persia> cjwatson, Yes.  It's a windows binary that permits free redistribution and modification *of the binary*, for which we don't have source.
<cjwatson> persia: that arises from "The main and universe categories have a strict and non-negotiable requirement that application software included in them must come with full source code."
<cjwatson> "application software" does not include PDFs
<directhex> cjwatson, to the best of my knowledge that's unlikely to happen - however, an argument could be made that it's not an ideal place to post as it's "not neutral enough" as a list. in the end it's your call. i just want to avoid being talked about again without knowing after that time on debian-legal
<persia> Ah.  I understand the distinction at this point.  Thank you.
<evand> Riddell: So given the preceding discussion, are you comfortable with accepting that upload?
<sladen> cjwatson: interesting, what about a PDF with the non-edit bits set?
<Riddell> evand: I must admit I'm not confortable with accepting files which are not in preferred modifiable form into universe
<Keybuk> Riddell: do you ship any png files anywhere?
<Keybuk> or any ttf files?
<Keybuk> etc.
<Keybuk> in the parti-all case, common sense should prevail anyway
<Keybuk> since the files are not part of any resulting binary package, they aren't interesting
<cjwatson> Riddell: I don't believe there is any justification for this from the licensing policy, TBH
<Riddell> Keybuk: PNG files often are preferred modifiable form.  where they're not they should be accompanied by the files which are
<persia> Keybuk, arguably, for some applications, .png *is* the preferred form for modification.
<Keybuk> indeed, I'm pretty sure we specifically encoded into the licencing policy a get-out clause for documentation, graphics, fonts, etc.
<directhex> +dfsg !
<persia> (although your argument stands for .ttf)
<cjwatson> since the very beginning we've said that we'll decide on data case-by-case
<Keybuk> Riddell: PDF are often the preferred modifiable form
<cjwatson> if evand says that these files are actually edited as PDFs ...
<Keybuk> and in this case, these documents are in the source package simply because they're specifications that the author followed
<cjwatson> (and even if they aren't, I don't see a huge problem TBH)
<Keybuk> repackaging the source package just to remove them would be a ridiculous PITA
<cjwatson> sladen: #include <flamewar.h>
<Keybuk> especially since they aren't placed into a binary
<Riddell> ooh, New queue is empty
<Riddell> only took all day
 * pitti hugs Riddell
<pitti> Keybuk: right now the i915 module is loaded very late, even after mounting the root fs; this makes it quite impossible to do anything sensible with usplash
<pitti> Keybuk: do you think there is a chance to move modprobing to a much earlier point in the boot process?
<Keybuk> no
<pitti> s/i915 module/any video module providing KMS/
<pitti> right now it takes more time _before_ KMS gets enabled than between KMS and gdm
<Keybuk> I'd rather we simply got there faster
<pitti> readahead alone blocks for 5 seconds or more
<pitti> and I don't think we can significantly speed up this
<pitti> at most we can move it to a different time
<Keybuk> we can significantly speed up the time it takes to load drivers
<Keybuk> my every waking moment is currently consumed by that task
<Keybuk> I fully expect that we will have the KMS driver loaded at the same time after boot that we currently start usplash
<Keybuk> so chill out, relax, and let me worry about boot speed ;)
<pitti> Keybuk: I was just curious :)
<pitti> Keybuk: erm, don't we start usplash in the initramfs?
<Keybuk> yes
<pitti> you said that we wouldn't move the drivers into the initrd last week
<Keybuk> but I don't want to put the kms drivers in there
<Keybuk> in fact, I'm going to start ripping things *out* of the initramfs
<pitti> right, understandably
<Keybuk> we should spend as little time in there as possible
<Keybuk> budget looks a bit like
<Keybuk> kernel: 1.2s
<Keybuk> initramfs: 0.8s
<Keybuk> udev: 1s
<evand> Riddell: Are we at an impasse?  And if so, shall we take this to the TB for a formal clarification?
<Keybuk> that'll mean the kms driver is loaded *by* 3s
<ion_> keybuk: Will karmic have Upstart in initramfs?
<Keybuk> ion_: unlikely
<cjwatson> Keybuk: oh, you mentioned that you had a console-setup patch to make it use udev - if you can toss that over to me, I could push it up the hill towards upload
<Keybuk> evand: (TB hat) I don't see that it needs a formal clarification; the current licensing documentation is clear
<pitti> Keybuk: I just feel that we should do something to unbreak usplash for alpha-2
<pitti> right now it just turns into a black screen after KMS gets active
<Keybuk> pitti: *shrug* I'm not worried about it
<pitti> hm, I forget that we don't have that enabled by default yet
<Keybuk> if you're looking for something to do to help boot speed, that GNOME login really needs some work ;)
<Riddell> evand: I'm done archive admin for the day, if you upload maybe tomorrows archive admin will accept the tyranny of non-preferred modifiable forms, or you can repack without PDFs and I'll accept it
<evand> Keybuk: I just don't want to force anything.  If it's not clear, then perhaps it's worthwhile for the TB to make a statement?  But I defer to higher powers.
<pitti> Keybuk: that's on our plate already :-)
<evand> Riddell: okay
<Keybuk> Riddell: did you have any other objection other than the PDF?
<Keybuk> Riddell: was the source otherwise clear?
<evand> Riddell: I do appreciate you looking it over, and I do appreciate your concerns.
<Riddell> Keybuk: seemed ok, I didn't look at it in detail
<pitti> Keybuk: in particular, seb128 will look at nautilus, I'll look at gnome-panel, and I'll talk to mvo or Robert about some go-faster stripes for compiz startup
<Keybuk> pitti: remember that my plan is to only start usplash if we need a filesystem check or a passphrase
<Keybuk> and that in the normal case, it won't be
<pitti> yep
<pitti> Keybuk: passphrase, too?
<pitti> I don't think that's possible
<pitti> in your design usplash starts after mounting the root fs, I thought?
<seb128> Keybuk: I don't think the "no splash" idea is a good one
<Keybuk> pitti: no
<pitti> i. e. crytpsetup -> passphrase -> root fs -> big modprobe -> KMS gets active
<Keybuk> seb128: I'm not suggesting "no splash", I'm suggesting we start X where we currently start usplash and do the splash as an X window
<Keybuk> pitti: passphrase for root fs is a very special case that requires deliberately activation
<ion_> So, karmic will have usplash and not plymouth?
<Keybuk> pitti: that means we can repack the initramfs for it
<Keybuk> pitti: and put usplash and KMS modules and the whole world into the initramfs
<Keybuk> and inherently not care about boot speed because most of the time will be waiting for passphrases and decryption time
<seb128> Keybuk: I'm waiting to see how long it takes to start xorg on my 6 years old desktop with a slow disk
<seb128> Keybuk: I doubt it will be 3 seconds though
<Keybuk> seb128: it should be roughly the same time it currently takes you to start usplash
<seb128> Keybuk: xorg itself takes longer than 3 seconds to start on this box ...
<Keybuk> seb128: with KMS?
<Keybuk> and are you sure?
<pitti> Keybuk: ah
<Keybuk> because I bet X starts really fast
<seb128> no, normal xorg
<seb128> Keybuk: well bootchart have xorg ressource busy for at least 3 seconds
<seb128> Keybuk: in any case I will try on karmic to see how it works
 * pitti pats ecryptfs
<pitti> seb128: that's surprising
<pitti> X itself starts in no time here
<pitti> it's all background, gdm, etc. which takes time
<pitti> KMS helps a lot there, yes
<seb128> pitti: well that's a normal boot and I've several seconds on the bootchart between Xorg and gdmgreeter but it could be gdm before the greater or something
<Keybuk> eep
<Keybuk> brownout
<Keybuk> seb128: was just saying
<Keybuk> that I bet X starts pretty fast with KMS
<Keybuk> and instead gdm isn't noticing
<ion_> keybuk: UPS? :-)
<Keybuk> ion_: DSL lost sync, so I guess the exchange got knocked out too
<ion_> Ah
<Keybuk> seb128: new gdm appears to fix this bug
<Keybuk> indeed there are git commits which say that they directly fixed this exact bug I was looking for ;)
<Keybuk> though they don't backport to old gdm sadly
<Keybuk> I had a go myself for the stig image, and appeared to fix it
<hyperair> pitti: thanks for sponsoring =)
<pitti> Keybuk: we'll use the new gdm in karmic anyway
<pitti> meh, seems my DSL just got a hangover as well
<pitti> hyperair: thanks for the fix!
<seb128> Keybuk: good, we intend to switch to new gdm this cycle
<hyperair> pitti: no problem. it was bugging me. on the other hand, i don't get to enjoy my fix now because gpm doesn't seem to work well with KMS =(
<Keybuk> so we have two options really
<pitti> hyperair: ugh, what does gpm have to do with KMS?
<Keybuk>  a) spend time and effort getting KMS and usplash up early, just to have a throbber until X starts
<Keybuk>  b) spend time and effort getting X up just as early
<hyperair> pitti: brightness control things.
<pitti> hyperair: ah
<pitti> Keybuk: b)
<hyperair> pitti: the main reason i did that fix was to get the brightness thing working. but now my brightness keys are completely dead with KMS on
<hyperair> i can't exactly report a bug either; i'm running xorg-edgers' packages
<Keybuk> and when you think about it, what are X's dependencies?
<Keybuk> X depends on a mounted filesystem
<Keybuk> X depends on KMS driver
<Keybuk> mounted filesystem depends on drivers
<seb128> you need usb drivers to be loaded
<Keybuk> so really, X depends on udev
<pitti> seb128: not with input hotplugging any more, I think?
<Keybuk> udev depends on kernel
<pitti> Keybuk: in the past, X.org needed the hostname to be set as well
<Keybuk> pitti: probably still true, but that's a single syscall
<Keybuk> so boot looks like
<persia> pitti, What about output hotplugging: one might have the display on USB.
<Keybuk> 1) start kernel
<Keybuk> 2) find and mount root filesystem
<Keybuk> 3) set hostname
<seb128> pitti: well you don't want to get gdm there and mouse and keyboard not working for a while ...
<Keybuk> 4) load drivers
<Keybuk> 5) start X
<Keybuk> doing hardware clock sync, console setup, filesystem checks and mounting all under 4
<pitti> seb128: I think they will get loaded together with the video driver in the big udev modprobe call?
<Keybuk> seb128: you'll get them at the same time as the video driver modulo bus issues
<pitti> seb128: also, there should be a throbber between X and gdm, while the remaining boot stuff happens, AFAIUI
<cjwatson> if we can set the keyboard layout after X itself starts, then console-setup and dbus/hal/blah can move later
<seb128> pitti: could be, I'm not the expert there, just saying we need to get usb input devices working
<Keybuk> seb128: but they're dependencies of *gdm*
<Keybuk> not of X
<pitti> killall hal
<Keybuk> we can have X up earlier
<Keybuk> with an X window throbber
<Keybuk> while we wait for gdm's deps
<seb128> right
<cjwatson> pitti: pedant :-)
<cjwatson> YKWIM
<pitti> cjwatson: wasn't meant as correction, just as a plan :)
<Keybuk> kernel is up in 1.2s right now
<Keybuk> my minimal initramfs is 0.5s
<Keybuk> we have udev doing its thing in just 0.8s now
<pitti> in fact I don't have a clear idea yet how the future hal-less X.org will get the keyboard layout
<Keybuk> that leaves us a whole 0.5s to set the hostname ;)
<Keybuk> pitti: probably a udev rule instead of an fdi?
<pitti> maybe through udev device properties
<pitti> Keybuk: that would just transform /etc/default/console-setup into udev properties
<pitti> if /etc/default/console-setup is "less standard" than udev, that would work
<Keybuk> pitti: bit of luck it's in a form that udev can read already then ;)
<Keybuk> IMPORT{file}="/etc/default/console-setup"
<ion_> Btw, exactly how does e.g. magic sysrqâs text output behave with KMS+X? Paint in some point in the video memory, until X happens to paint over the same spot again?
<cjwatson> Keybuk: cunning
<seb128> do you do tests on slow disks too?
<Keybuk> ion_: it doesn't pain
<Keybuk> +t
<Keybuk> seb128: yes, I mostly test on my laptop
<Keybuk> which has the slow disk of death
<Keybuk> I'm hoping for faster results when I test on a mini9
<ion_> keybuk: Is there any hope of that changing?
<Keybuk> this stuff is mostly not disk though
<seb128> the d420 you mean, not the mini9 right?
<Keybuk> ion_: not really
<Keybuk> seb128: the d420, right
<seb128> ok
<seb128> because I always find my bootchart very different of you mini9 ones
<seb128> ie my disk seems much slower
<seb128> but cpu is faster
<Keybuk> seb128: the mini9 has an SSD
<Keybuk> that makes a massive difference
<Keybuk> the slow CPU though kills it in other ways
<Keybuk> for a truly awesome experience, steal jcastro's laptop
<seb128> right, which is why I'm trying to make sure slow disk owner will have something nice too ;-)
<Keybuk> X200+Intel SSD ... 12s boot to full logged-in desktop on jaunty
 * Keybuk wishes his next laptop refresh would hurry up
<pitti> Keybuk: *wow*
<Keybuk> seb128: sure
<Keybuk> seb128: which is why I'm putting the usplash option where I am ;)
<tormod> apropos Xorg startup try: time xinit -e '' (actually adds the shutdown time too)
<Keybuk> having it optional at the point we check disks means that we can also, maybe, start it if the disk is not SSD
<Keybuk> I'm hoping we don't have to
<Keybuk> but it's an option
<pitti> Keybuk: so it seems that the 5 second readahead block is really the biggest remaining chunk before KMS/X start?
<cjwatson> we could split up readahead to prioritise X
<Keybuk> right, there's a few options here
<hyperair> pitti: o noes. gpm ftbfs on hppa.
<pitti> hyperair: *shrug*
<Keybuk> hyperair: hppa EOL kthxbye ;)
<pitti> not that it ever had much of a life in the first place
<slangasek> everything ftbfs on hppa now, if I'm not mistaken
<slangasek> (due to aforementioned EOL)
<Keybuk> slangasek: buildd repurposed as a doorstop?
<cjwatson> re?
<slangasek> mterry: seen that quodlibet FTBFS on all !i386?  I guess there's a binary-indep/binary-arch mismatch in debian/rules somewhere
<mterry> slangasek: Ah yes.  I made a mental note to check that out.  I'll look into it
<highvoltage> where is ubuntu's calender these days? I heard it's in google somewhere?
<LaserJock> highvoltage: I think the fridge has a link
<slangasek> so, does anyone know where my gpg agent went on upgrade to karmic?
<ogra> it probably became a secret agent :P
<highvoltage> heh
 * slangasek grins
<slangasek> are others seeing the same issue?
<ogra> processlist here has nothing about gpg
<mterry> slangasek: I'm on karmic, and I still get the little dialog asking for my gpg passphrase
<highvoltage> who maintains the ubuntu google calender? I have some trouble adding an event
<slangasek> mterry: do you know which process is running it?  seahorse, or something else?
<mterry> slangasek: Nope.  seahorse is a good guess though
 * ogra would guess gnome-keyring-daemon
<slangasek> well, g-k-d doesn't appear to be handling gpg here
<slangasek> it does handle ssh
<slangasek> bryce: 382390> mutter, why doesn't ubuntu-bug xserver-xorg-video-intel dtrt there?
<bryce> slangasek: weird
<bryce> slangasek: near as I can tell if you filed it like that it should have pulled everything in
<slangasek> bryce: well, bah
<bryce> maybe a pitti question?
<slangasek> hmm, I think I got an LP error message around the time I filed that bug, maybe that's why it broke
<bryce> ah
<slangasek> well, time to try to reproduce the bug, then break everything with KMS
<bryce> kewl
<bryce> I'm working on the 2.7.99.1 update presently
<slangasek> of course now the bug is unreproducible
<slangasek> I probably need to have a projector on hand or something to reproduce it
<YokoZar> Do we have a daily USB stick image for Karmic?  Or was that just an idea...
<bryce> YokoZar: working on it.
<bryce> YokoZar: what we have so far is a livecd image with xorg-edgers here - http://people.ubuntu.com/~bryce/xorg-edgers-0.1-i386.iso
<YokoZar> bryce: I guess I can write that to the stick using the same tools and boot/install karmic from that right?
<bryce> YokoZar: presumably yes
<slangasek> bryce: another successful KMS test for you
<bryce> sweetness
<bryce> slangasek: any improvement in boot speed?
<slangasek> oh, pitti reports problems with external monitor on 945, hmm... guess I should check that myself
<slangasek> bryce: no, looked pretty much the same to me
<bryce> ok
<slangasek> OTOH, I have root on crypt-lvm, and it always seems like there's an unnecessary delay after decrypting... I should figure out what that is
<bryce> btw, what is your boot time total?
<slangasek> eh, haven't timed it, and as per above it wouldn't be representative :)
<bryce> my laptop takes 55s to boot, my ati box takes 25s
 * slangasek mutters at the shorter cable on his replacement AC adapter
<YokoZar> Is CPU time a limiting factor anywhere in the boot process?
<YokoZar> or is it mostly I/O stuff
<directhex> moar cores. it's the only option.
<slangasek> bryce: hmm, I do have a regression in the set of video output configurations that Fn+F7 cycles through for me
<bryce> YokoZar: looks like mostly I/O to me.  usplash is the only thing that seems to take significant cpu
<slangasek> I get "both on, high res", "internal on", "both on, low res"; missing is "VGA on, LVDS off"
<bryce> hmm
<bryce> slangasek: not sure if that is X, or whatever handles Fn+F7 now
<bryce> worth filing a bug in any case
 * slangasek nods
<slangasek> the only thing I changed was turning on KMS, so
<ion_> So, how does one test KMS and where to post results?
<slangasek> https://wiki.ubuntu.com/X/KernelModeSetting
<ion_> Thanks, was just about to click that search result. :-)
<slangasek> bryce: oh - in Settings -> Preferences -> Display, both outputs are now listed as 'unknown' instead of having names...
<ion_> Ah, ATI KMS is not available yet. I was under the impression the new Fedora release had it.
<slangasek> bryce: though that may be unrelated to turning on KMS
<bryce> slangasek: there's a lookup table local to gnome-display-properties that should have it
<bryce> you could doublecheck that xrandr --verbose lists your monitor's model code
<bryce> if it does, then gnome-display-properties may be bugged.  If it doesn't, then something's wrong with the edid stuff in X
<slangasek> what does a "model code" look like?
<bryce> like AUO, BNQ, SNY
<slangasek> hmm, I don't seem to have anything like that
<bryce> hmm actually it appears xrandr doesn't print that
<bryce> get-edid | parse-edid | grep ModelName
<bryce> assuming you're on x86
<slangasek> what package is get-edid in?
<bryce> read-edid
<slangasek> by x86 do you mean i386?
<bryce> slangasek: yeah
<slangasek> yeah, no help there
<persia> Also works on powerpc and lpia :)
<slangasek> clearly we need to get multiarch on its feet so that I can run get-edid
<bryce> :-D
<bryce> slangasek: alternatively, it may be displayed in your /var/log/Xorg.0.log
<bryce> (II) RADEON(0): EDID vendor "BNQ", prod id 30427
<persia> Erm, will that help?  Can one access real-mode x86 on x86_64?  If so, it's probably just a matter of recompilation.  If not, multiarch won't help.
<slangasek> EDID vendor "LEN"; so it at least knows the vendor for the LVDS
<bryce> ok, so X seems to be ok, now to check gnome...
<bryce>     { "LEN", "Lenovo" },
<bryce> that is 2.26, let me check latest too
<bryce> yep, there in 2.26.1 too
<bryce> (libgnome-desktop, display-name.c, vendors[])
<YokoZar> quick question: is it possible to add a tab to a Gnome right click->properties dialog with a separate package, or does that require modifying something inside gnome?
<YokoZar> (writing the spec for Wine integration)
<bryce> slangasek: best guess is that the API for getting monitor info has changed with the modesetting stuff moved to the kernel
<slangasek> bryce: yeah, that was my guess too.  Where should that bug get filed?
<bryce> gnome-display-properties probably
<slangasek> ok
<persia> YokoZar, #ubuntu-desktop may have more information, but I think you can do it with nautilus extensions.
<YokoZar> persia: If nautilus is extendable in a sane way, that should be enough
 * persia doesn't claim "sane", but doesn't have enough information to claim otherwise either
<persia> YokoZar, One package I know to create context is nautilus-open-terminal
<YokoZar> I'll put in the spec that it should be doable through an extension (and thus Gnome should be more extensible if it isn't), since this is exactly the kind of code that doesn't need to go in by default
<highvoltage> cjwatson, slangasek: are you around, LaserJock and myself would like to speak to you about Edubuntu releases
<slangasek> highvoltage: I'm around
<highvoltage> slangasek: great. I understand that there are limitations on hosting currently in the canonical datacenter, and that this is affecting how much we can ship in an iso?
<LaserJock> the basic thing is that Edubuntu would like to ship a full DVD or USB image
<LaserJock> the Addon thing just doesn't seem to work all that well
<highvoltage> slangasek: based on feedback from our users, we would very much like to expand our offering somewhat for karmic, and for karmic+1 we aim to be a full installation disc again, based on feedback from our users.
<slangasek> bryce: once again, ubuntu-bug only attached Dependencies.txt to my report (bug #382864), not anything else
<ubottu> Launchpad bug 382864 in xorg "xrandr cycling is all messed up with KMS" [Undecided,New] https://launchpad.net/bugs/382864
<LaserJock> but since our .iso got dropped off releases.ubuntu.com we were wondering if there is some way to get back on for Karmic or Karmic+1 with a DVD
<highvoltage> in short, we need to know that the infrustructure can support our images before we can commit to our users on this
<slangasek> LaserJock, highvoltage: limitations on hosting> not explicitly, that I'm aware of; though changes to the image type we're building for edubuntu would have to get blessed by someone above me in the chain, I believe
<slangasek> "get back on" - on releases.ubuntu.com?
<highvoltage> slangasek: such as the TB?
<LaserJock> slangasek: yep
<highvoltage> slangasek: edubuntu used to be hosted on releases.ubuntu.com
<slangasek> highvoltage: yes
<slangasek> LaserJock: I think there's zero chance of us shipping an Edubuntu DVD on releases.ubuntu.com
<LaserJock> ok
<highvoltage> slangasek: what's the limiting factors? if there's something we can do to help fix it we would want to do so
<slangasek> no, it's not a limit within the Canonical data center - it's that releases.ubuntu.com is the basis for all of the CD mirrors, and the more images we ship there the fewer mirrors we can get
<bryce> slangasek: does running 'apport-collect' cause them to be attached?
<bryce> slangasek: also check if 'ubuntu-bug xorg' produces the same behavior
<LaserJock> slangasek: so would it be possible to have it on cdimage.ubuntu.com and then come up with our own mirrors?
<slangasek> bryce: this time, I did run 'ubuntu-bug xorg'
<bryce> slangasek: ok really weird
<bryce> slangasek: let me try
<slangasek> LaserJock: I would still want to get that change blessed by the TB before making the change to the image building, but at least in theory that should be fine
<highvoltage> slangasek: thanks for your input, we'll add it to the agenda for the next TB meeting
<bryce> slangasek: broke for me too (lp: 382868)
<slangasek> bryce: ah, apport-collect also fails, with a traceback
<slangasek> oh, the same one you just reported
<slangasek> :)
<mterry> slangasek: I'm having a bit of trouble with quodlibet.  It seems that quodlibet-ext wants to install all the files from all 3 binary packages, not just the files in its .install file...  Let me know if/when you have a sec to talk about it
<slangasek> mterry: ok, let's take a crack at it
<slangasek> hmm, I still need to upload python-defaults to prune python 2.5, don't I
<slangasek> mterry: isn't the problem that it's looking for site-packages instead of dist-packages?
<mterry> slangasek: So that's the white rabbit that led me into a hole
<slangasek> can you post me a debdiff of what you currently have?
<mterry> slangasek: When I packaged that merge, I changed it back from dist-packages to site-packages, because that seemed to be what i386 needed (I assumed it was part of the general python changes to use site-packages and then rename it to dist-packages automatically)
<mterry> slangasek: But I assume that's not the case for other archs apparently
<mterry> slangasek: But this got me looking at the quodlibet-ext package and I noticed that it has way too many files
<slangasek> mterry: ah, heh, so it does
<mterry> slangasek: So, there may be two issues here
<mterry> slangasek: (I'm trying to find merge bug with debdiffs)
<mterry> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/quodlibet/+bug/373827 has debdiffs
<ubottu> Ubuntu bug 373827 in quodlibet "Please merge quodlibet 2.0-3 (universe) from Debian unstable" [Wishlist,Fix released]
<slangasek> mterry: a debuild -B seems to DTRT, after fixing quodlibet-ext.install
<mterry> slangasek: Interesting...  I wasn't getting that
<mterry> slangasek: Let me start with a fresh source checkout
<slangasek> well, it may *not* DTRT with debuild -b
<mterry> slangasek: ah, yes, I've been doing -b
<slangasek> the difference between the two is very salient here, since the package FTBFS only on !i386 :)
<elmo> cjwatson: hey
<elmo> cjwatson: can we fix our filesystems to have remount-ro in the FS by default?
<cjwatson> elmo: err, YM in the kernel or something?
<elmo> cjwatson: well, I was thinking mkfs, but I notice it doesn't have an option for that
<elmo> which is annoying
<cjwatson> elmo: well, you can tune2fs it, but yes
<cjwatson> elmo: you could ask Ted ...
<elmo> cjwatson: I was thinking a bug report ;-) I suppose I could do both
<elmo> 'continue' is just such an insane default
<elmo> "errors?  oh well, LET'S TRY HARDER"
<cjwatson> elmo: odd given http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg254037.html
<elmo> cjwatson: ah, ok, super
<elmo> I'm still in ext3 world
<cjwatson> elmo: but mke2fs's default still seems to be continue anyway
<cjwatson> elmo: I believe the installer always uses remount-ro for ext* though?
<elmo> cjwatson: yeah, it does
<elmo> cjwatson: I'm just in the position of adding a new drive, post install
<cjwatson> ah
<slangasek> which package should be bugged about the gnome-power-manager icons defaulting to the stock GNOME ones?
<themuse> hi, anybody with some Boost (dev libs) packaging experience here?
<persia> themuse, You might try #ubuntu-motu for that.
<themuse> persia: ok, thx for the hint
<calc> hmm win7 releases one week before karmic
<Tm_T> calc: perfect, so people get in the "this sucks lets try Ubuntu" mood just in time (;)
<calc> Tm_T: heh
<NCommander> slangasek, (or any other archive admin who's awake), am I correct in the assumption that for any package to enter the archive, it needs to contain the full text of its license in the tarball (in COPYING or another similar file; a link to a file outside the tarball isn't acceptable)
<slangasek> NCommander: there's no particular reason that the license has to be in the upstream tarball
<slangasek> unless that violates the terms *of* the license in question, rendering the tarball undistributable
<NCommander> slangasek, hrm, I vaguely remember getting a REJECT over this for a package under the GPL, but maybe my memory gone faulty :-/
 * soren is very confused..
<soren> Scripts in /usr/share/initramfs-tools/scripts/init-bottom should all unconditionally be copied to the initramfs, shouldn't they?
 * soren wonders if there's restrictions on the names of those scripts..
<slangasek> NCommander: in the case of the GPL, it's a condition of the license itself that the source be accompanied by the license; but that's not "for any package", that's "for packages whose license requires it"
<NCommander> slangasek, the license says "should", not "must", but that's a nitpick from my prelaw days
<slangasek> NCommander: which license?
<slangasek> GPLv2, Â§1 requires it as a condition of distribution
<NCommander> sladen, argh,y eah, sorry, I'm an idiot, I was reading something else, and my brain got a wired crossed
<NCommander> (and I found a goof on the FSF page on how to apply the GPL to your packages :-))
<dholbach> Mez: http://daniel.holba.ch/blog/?p=78
<Mez> what have I done now ? :P
<dholbach> Mez: 4000 mails in moderation
<Mez> :D
<NCommander> o___________o;
<ajmitch> dholbach: is that for the dholbach fanclub list?
<dholbach> ajmitch: no, just people not using listadmin :)
<cjwatson> mathiaz: could you deal with the openldap merge? although I'm TIL, that's only due to a no-change rebuild and I don't claim to know the package at all well
 * slangasek looks in amazement at bug #379537.  Why in the world is that on acpi-support?
<ubottu> Launchpad bug 379537 in acpi-support "Closing lid does not lock screen" [Undecided,New] https://launchpad.net/bugs/379537
<persia> Someone thought lid closure was an ACPI event, and picked a package with a likely name?
<Mez> dholbach: thank gods for "action discard" :D
<geofft> re-asking when more people are around... is there an MD5SUMS.gpg for the netboot installer?
<geofft> I only seem to be able to find GPG signatures for the ISOs
<cjwatson> geofft: no, sorry, no remotely straightforward way to arrange that AFAICS
<cjwatson> we'd have to special-case it in LP or something ...
<geofft> aww. Is there a reasonable way for me to get a trust path to the kernel/initrd?
<geofft> archive.ubuntu.com doesn't seem to do HTTPS. (Hm, how do mirrors get a trustworthy connection anyway?)
<cjwatson> the kernel is a copy of that stored in the archive
<cjwatson> the initrd ... hmm. you could fish the .changes file out of LP
<cjwatson> pain in the arse I realise
<elmo> geofft: the integrity is assured within the archive itself (signed indices that describe the packages and their expected contents)
<cjwatson> mirrors generally just use rsync and rely on the archive contents being authenticated, so this is a bit of a problem
<cjwatson> annoyingly the contents of custom uploads aren't accessible via the LP UI
<cjwatson> geofft: please do file a bug about this, BTW (on Soyuz, I suppose) - I don't think we can fix it very easily but it is a real problem IMO
<geofft> cjwatson: yup, will do soon-ish
#ubuntu-devel 2009-06-03
<TheMuso> nixternal: seems like no sound hardware was found on your system at all, re your bug 382968
<ubottu> Launchpad bug 382968 in alsa-driver "Sound works for system notifications through the PC speaker - no sound at all with multimedia apps" [Undecided,New] https://launchpad.net/bugs/382968
<nixternal> TheMuso: ya, dtchen has already fixed the issue :)
<TheMuso> oh?
<TheMuso> ok
<nixternal> ya, during upgrade from jaunty -> karmic, somehow my user was removed from the audio group
<TheMuso> ah
<nixternal> how I missed that is beyond me
<nixternal> haha
<dtchen> i'm not entirely sure, since i don't have a kubuntu jaunty live image, whether the default user is in @audio to begin with
<johanbr> I thought ubuntu didn't use the audio group anymore?
<TheMuso> It doesn't.
<dtchen> johanbr: correct for ubuntu jaunty, which uses pulseaudio alongside consolekit
<ajmitch> dtchen: I'm not in audio on my jaunty box here at work
<TheMuso> its all policykit driven.
<TheMuso> the only deriv that adds the user to the audio group is studio.
<cjwatson> intrepid too
<cjwatson> (user-setup 1.20ubuntu3)
<ajmitch> are there some differences with groups between kubuntu & ubuntu there?
<cjwatson> not as far as the installer is concerned
 * ajmitch would hope not
<cjwatson> expanding a little on what TheMuso said, ubuntustudio is the only derivative built on the main infrastructure that changes the default groups set by the installer *at all*
<cjwatson> (it sets them to 'adm audio cdrom dialout lpadmin plugdev sambashare' right now)
<ajmitch> alright
<cjwatson> which in fact just adds audio over the default
<cjwatson> ow, wrong side of midnight, bed
<ajmitch> g'night
<TheMuso> night
<dtchen> ugh, it's possible for pulseaudio to completely wedge the HDA controller, requiring an /sbin/alsa force-reload to restore functionality. :(
<TheMuso> eew
<ajmitch> dtchen: I'm not surprised, I was seeing a complaint of sound totally dying in another nz channel today
<Hobbsee> Keybuk: just reading the meeting logs now, but we do (IMO) need more ops in here, while europe is asleep.  slangasek would be a great start, but some more would be good.
<Hobbsee> although i agree with you on getting developers who are around, if possible
 * TheMuso watches IRC quite regularly during his work day at least.
<TheMuso> Particularly in here.
<Hobbsee> TheMuso: you would probably be a good candidate to be on the list, too, then
 * TheMuso needs to go and read the meeting log when he has time.
<TheMuso> hrm. ptlib supports esd/esound, yet we don't build support for that. That would be at least one way of getting better pulse support for ekiga...
<lifeless> TheMuso+1
<slangasek> cjwatson: I don't think we really reached a conclusion about how to handle gcc-multilib under multiarch; we could have a gcc wrapper that handles -m32/-m64, but that's fairly unsatisfactory IMHO, and still implies cross-arch build-dependencies for packages that really truly need to build 32-bit code on amd64 (and there are some), so I guess we need to have a way to handle that?
<slangasek> (at which point gcc-multilib can stay as it is, rather than needlessly shuffling the problem down the line)
<slangasek> also, I just noticed that we can't use the [arch] syntax to declare a cross-arch build-dep, because that syntax is already used for arch-specific build-deps...
<StevenK> {arch} ?
<StevenK> We're running out of brackets
<lifeless> StevenK: *smack*
<ScottK> {([arch])}
<lifeless> {arch} was a control dir for tla
<StevenK> Yes, and I was using it in the context of debian/control, not a directory name
<lifeless> all the same
<lifeless> don't propogate the scarin
<lifeless> g
<StevenK> It would be used like {i386}
<StevenK> lifeless: Or do you just twitch when you read {arch} ? :-P
 * lifeless twitches
<TheMuso> dtchen: When you get a minute, could you please have a look at the notes/whiteboard for https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-audio-experience and add anything I may have missed/incorrectly stated in the wiki page? I feel I got everything, but another pair of eyes is useful. Thanks.
<lifeless> TheMuso: if you have a minute, I'd appreciate some guidance on dmraid startup
<TheMuso> lifeless: if you are referring to your diffs in those bugs, I am about to get to those.,
<TheMuso> c
<TheMuso> woops wrong window
<lifeless> TheMuso: to the apparent way that udev is calling dmraid-activate four times with 'no' 'block' 'devices' 'found'
<lifeless> simply knowing that my patched dmraid-activate, with logging enabled, boots for other people would be good
 * TheMuso rechecks the udev rule.
<TheMuso> lifeless: I am stumped as to why udev returns no block devices found. The syntax for the rule looks correct. I will have to do a karmic dmraid install to see what the hell is going on.
<lifeless> TheMuso: When you can that would rock
<TheMuso> ok
<lifeless> TheMuso: The only theory I have at the moment is that the no block devices found array is coming from dmraid itself
<lifeless> or something linked to the same lib
<TheMuso> Right.
<lifeless> but I'm damned if I can see the freaking cause
<TheMuso> hrm a brain wave. It could be mkid/whatever vol_id's replacement was.
<TheMuso> vol_id had its own code to deal with dmraid arrays, and its replacement obviously doesn't know about your hpa stuff, same thing with jaunty and vol_id.
<TheMuso> WHich means more patching is needed.
<lifeless> \o/
<lifeless> is vol_id calledbefore dmraid ?
<TheMuso> Yes.
<lifeless> or after? if vol_id is called on the dmraid mapper device it would be fine
<TheMuso> Not in the dmraid rule, but in other rules.
<TheMuso> hrm not sure if this the problem now, but can't think of what else it is currently.
<TheMuso> sorry its blkid
<lifeless> thanks
<lifeless> I shall poke tomorrow
<TheMuso> ls
<TheMuso> woops
<TheMuso> ok
<TheMuso> in util-linux source package, you want libs/blkid/src/probers/isw_raid.c
<pitti> Good morning
<pitti> slangasek: 945 external monitor> Previously I had pipe underruns, which seem to have been cured by the extra 1 GB RAM which I plugged in during UDS
<pitti> slangasek: the other problem that I have is that suspend/resume is broken with external monitor (doesn't get switched on again)
<pitti> otherwise it's working quite well
<TheMuso> pitti: an upload for the intel driver was made today. You tried that yet?
<pitti> TheMuso: I have used the xorg-edgers PPA, I get updates practically daily
<TheMuso> pitti: ah ok.
<pitti> during UDS, karmic was totally broke for me
<pitti> broken
<pitti> 2.7.1 wedged everything
<pitti> bryce: thanks for the new -intel upload
<pitti> bryce: would you rather have people test xorg-edgers or karmic?
<lifeless> pitti: it fixes or fucks?
<pitti> lifeless: xorg-edgers makes everything work like a charm again
<lifeless> pitti: but bryces' upload to karmic?
<pitti> lifeless: didn't try that yet
<pitti> well, actually I did
<pitti> I have 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu0sarvatt
<pitti> and bryce uploaded 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu1
<pitti> so I guess they are by and large identical
<lifeless> ok cool
<pitti> the PPA also has a newer mesa etc., though
<lifeless> I won't avoid updating then ;)
<pitti> lifeless: BTW, it's pretty hard to entirely wreck the machine; if nothing else helps, blacklisting the i915 module is a pretty sure way to get it back up (without acceleration/compiz/etc. of course)
<cjwatson> TheMuso: IMO dmraid-activate should be checking the exit status of dmraid nowadays, now that dmraid exits non-zero if it can't find anything, rather than doing those dodgy tests on its output
<cjwatson> slangasek: in some ways I'd rather that build-dependencies were always native, which would seem to suggest that we would need to keep around a small number of biarch libraries as well. I wonder if it's just glibc in practice, or if there are more?
<cjwatson> slangasek: we didn't really discuss the problem of /usr/share/doc/<package>/ at UDS - I see there are several options for that in the spec but I don't recall us settling on something
<cjwatson> oh good, I see that dh_compress uses gzip -n nowadays - that should probably be a requirement for any multiarch package to avoid spurious differences
<dholbach> please help out with http://people.ubuntu.com/~dholbach/sponsoring - the list is growing! :-/
<ajmitch> growing to devour us all?
<pitti> dholbach++
<ajmitch> my excuse is that I was actually doing a couple of merges this week :)
 * dholbach takes a look at dx and *recordmydesktop
<lifeless> cjwatson: it does, in my patch
<lifeless> (dmraid--activate checking $?)
<ajmitch> dholbach: useful list, it shows me a bug I missed in the changelog
<ajmitch> and also some merge duplication, unfortunately
<dholbach> ajmitch: maybe our first impulse should always be "I'll check the sponsoring page and see if somebody else did it already and I just need to review it" :-)
<ajmitch> dholbach: to be fair, I'd left a comment on MoM that I was merging it before that bug appeared on the list :P
<seb128> dholbach: some people were away for uds and the week before that which might explain why they have been less activate on sponsoring ;-)
<dholbach> seb128: I said "please help out with sponsoring" and not "you guys suck and should all be replaced by staplers because you don't do sponsoring" :-)
<seb128> lol
 * seb128 hugs dholbach
 * dholbach hugs seb128 back :)
 * Hobbsee tries replacing dholbach with a stapler
 * Hobbsee watches people abstain from cuddling it.  Hmmm.
<seb128> dholbach: in an other way "I plan to do some but I've a lot of catchup to do this week and spec drafting", ie some people know they have to do sponsoring but are still after uds busy
 * dholbach staples
<dholbach> - -
<dholbach> - -
<dholbach> - -
<seb128> but agreed, we should tackle this list ;-)
<Hobbsee> haha :)
<seb128> hey Hobbsee
<Hobbsee> seb128: heya!
<dholbach> seb128: I'm sure you'll find it relaxing to review a few patches between writing one spec and the other
<juanje> dholbach: lol :-P
<seb128> dholbach: good idea, you should write a slogan "take a break, review a patch" kind of advertisement ;-)
 * iulian feels that he should start sponsoring.
<juanje> seb128: yeah, maybe it could be an option in your Typing Break from GNOME :-P
<seb128> locking the screen every hour "now it's time for doing some sponsoring"? ;-)
<iulian> Heh
<juanje> seb128: lol :-P
<ajmitch> or dholbach calling your house every hour to remind you
<StevenK> pitti: libgnomesupport0 got removed from the archive by you -- there are 4 packages that require the Gnome 1.x libraries -- shall we just boot them, or play the waiting game (IE: See what Debian does?)
<pitti> StevenK: check process-removals?
<pitti> Debian should have removed pretty much all gnome 1 rdepends
<pitti> apt-cache rdepends libgnomesupport0
<pitti> <libgnomesupport0>
<pitti> hmm
<pitti> StevenK: if you find some, just ditch them
<StevenK> I checked one, and it hasn't been removed in Debian
<StevenK> I suspect it will be
<pitti> Riddell: do you know whether KDE relies on hal's camera.libgphoto2.* properties?
<pitti> Riddell: or info.capabilities == camera?
<pitti> Riddell: in other words, if /usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi would go away, woudl anything break?
<Riddell> pitti: no idea, I can ask though
<Riddell> pitti: I'm told it relies on both
<pitti> meh, ok
<Riddell> pitti: what would replace it?  devicekit?
<pitti> Riddell: for PtP cameras you can just use libudev and ask udev
<pitti> for the ancient custom protocol ones we still need something like it
<pitti> we'll probably need to keep the list around, and just rewrite it as udev rules
<pitti> Riddell: I'll think about it, thanks for checking
<soren> Is there a way to query whether a given package was installed manually or pulled in as a dep? I know the info is in /var/lib/apt/extended_states, but does apt or aptitude expose it somehow (preferably in a scriptable manner)?
<directhex> soren, "aptitude show"?
<directhex> soren, there's this whole "Automatically installed:" line you might like
<soren> directhex: Blimey, there it is. *facepalm*
<soren> directhex: Thanks.
<Lutin> (aptitude search gives it, too)
<cjwatson> soren: it'd be nice if apt-mark let you query that state as well as set it ...
<soren> cjwatson: Hm.. Never heard of apt-mark before. Looks handy. Thanks.
<ion_> I use debfoster to handle the automatic/manual state and apt-mark-sync to sync its decisions to apt and aptitude, since they all still donât use a shared database for that.
<ion_> (btw)
<mvo> cjwatson: good point
<mvo> ion_: apt and aptitude use a shared database since some time for the auto flag
<ion_> mvo: âAllâ, as in debfoster as well.
<ion_> Perhaps aptitude gains debfoster-like functionality some day. That would be nice.
<mvo> ion_: aha, ok. debfoster should probably be modified to use the extended_states file as well
<ogra> mvo, could you drop the blacklisting for i945GM from compiz in karmic ?
<ogra> the new driver works just fine
<ion_> mvo: Oh, btw, since i finally manage to be online simultaneously with you: please check out the debdiff in LP #377065. :-)
<ubottu> Launchpad bug 377065 in command-not-found "zsh_command_not_found should use the pre*_functions arrays instead of overwriting the singular preexec/precmd functions" [Undecided,New] https://launchpad.net/bugs/377065
<mvo> ion_: thanks, I have a look now
<mvo> ogra: yes
<ogra> mvo, thanks :)
<mvo> ogra: GM965 you mean?
<ogra> mvo, 8086:2a02, yes
<mvo> ogra: fixed in bzr
<ogra> gracias :)
<cjwatson> kees: I'm merging shadow since I'm also merging user-setup; hope that's ok ...
<mib_i6x4ojh7> hi all
 * ogra sighs ... what the heck is a text/uri-list decoder plugin
<ion_> ogra: Perhaps something that parses various playlist formats?
<ogra> yes, apparently, but an apt search doesnt reveal anything
<ogra> i should have everything installed but RB still moans
<ogra> though i got one radio station working now on my arm board
<slangasek> cjwatson: it looks like it's just libc6 that gcc-multilib woud build-depend on for biarch.  So we can do that, though I think that would still be a blemish
<slangasek> cjwatson: /usr/share/doc/<package> - I discussed it with guillem after the session, and his plan is to have dpkg keep track of file checksums directly and only allow co-installability if overlapping files match
<slangasek> pitti: yeppers - I don't see that suspend/resume problem with my external monitor on my ThinkPad
<cjwatson> slangasek: my worry about that was always that it means that non-identical versions implicitly conflict, which seems to me to be a likely source of lurking difficulties for upgrades
<cjwatson> or was that the "implicit Replaces: same-binary (<< ${binary:Version}) [different-arch]" thing?
<cjwatson> I think I came in half-way through that
<slangasek> yeah, that was that one... I think that's effectively what guillem is doing, with the added constraint that two multiarch packages aren't allowed to be configured unless they're at the same version
<cjwatson> slangasek: I suspect we also have a number of packages that don't use gzip -n for one reason or another, so that will have to be a requirement for anything with Multi-Arch: set
<cjwatson> I fixed two of my own this morning ...
<slangasek> ah, ok
 * cjwatson vomits at the shadow merge. The chpasswd -S option just got a LOT more complicated
<ogra> asac, grmbl ...
<kees> Riddell: can you take a look at the libmsn merge?  I'm less familiar with this code, and since it's in Debian now, it's a "real" merge.
<asac> ogra: huh?
<Riddell> kees: can do
<ogra> asac, running firefox remotely through a ssh tunnel uses my local ~/.mozilla dir !
<kees> Riddell: thanks!
<ogra> i was just surprised how fast FF on the babbage2 runs remotely to then discover all my cache and bookmarks was used locally :/
<asac> ogra: only if you have a ff already running locally. yes
<ogra> oh, i have indeed
<ogra> so it pulls it from ram ?
<asac> ogra: but that would make FF run on your system and not on the remote machine
<asac> ogra: stop everything
<ogra> ok
 * ogra tries again
<ogra> oh, now i also dont get my prompt back on the babbage, that looks more sane
 * ogra hugs asac 
<ogra> thanks, seems to work
<asac> ogra: if you still need your ffox locally you can export MOZ_NO_REMOTE=1
<asac> on remote end and it will not find your locally running FFOX
<ogra> ah, good to know
<cjwatson> slangasek: james_w would know more precisely but the target is the next couple of months, I believe
<cjwatson> kees: fun, isn't it
 * soren is laughing on the inside
<kees> cjwatson: ah, so I'm late to this realization?
<kees> I was just poking at the merge...
<cjwatson> kees: see your mail ;-)
<cjwatson> I got blocked on it this morning so went ahead ...
<kees> d'oh, checking.  still a bit behind...
<cjwatson> (sorry if you duplicated work as a result!)
<kees> cjwatson: ah, only a few minutes of duplicated work.  I was actually thinking we could just drop all the Ubuntu-changes since everything else is in Debian now.
<kees> cjwatson: I was figuring we'd need something to replace "chpasswd -e" eventually.  it's just "now".
<kees> cjwatson: trouble is, more than just g-s-t uses chpasswd.  vmbuilder uses chpasswd -e, and I think, d-i, though I'm not sure if it calls it with -e.  (I think not)
<soren> d-i accepts encrypted passwords as well.
<soren> IIRC, that is.
<soren> (by way of preseeding, usually)
<cjwatson> yes, it does
<cjwatson> d-i is being fixed - that's why I found myself blocked on the merge
<soren> Template: passwd/root-password-crypted
<soren> Whoops..
<cjwatson> kees: chpasswd -S is still outstanding, as is the default to SHA512
<kees> cjwatson: well, -S was needed because of g-s-t
<cjwatson> (d-i is actually already fixed for this upstream)
<kees> the SHA512 default was only needed because of the lack of PAM integration
<cjwatson> indeed, and it's still needed until such time as -S is either dropped or converted to PAM
<kees> is anything left that reads ENCRYPT_METHOD in the shadow package?
<cjwatson> I haven't checked the rest of shadow to see if there's anything left
<kees> right
<cjwatson> if there was really nothing left, I'd have been sort of surprised if nekral hadn't nuked it with extreme prejudice :)
<cjwatson> compatibility with non-PAM systems perhaps
<kees> yeah, USE_PAM is in heavy use in the code.
<slangasek> lovely PAM, wonderful PAM
<kees> I'm all for the merge, which was precipitated (I like to think) by my "-S" patch being proposed.  :P
<kees> slangasek: is there a non-insane way to get an encrypted password hash out of PAM?
<slangasek> no
<slangasek> hth :)
<kees> wheee
<cjwatson> nekral suggested a custom conversation function of some kind
<cjwatson> said he had a patch but didn't elaborate, Fermat-style
<slangasek> haha
<kees> cjwatson: like, custom-to-the-PAM-stack?  errrg
<cjwatson> kees: no idea
<kees> I had taken it to mean "custom-to-shadow"
<cjwatson> so had I
<slangasek> the conversation function would be provided by the calling app
<kees> cjwatson: how was d-i fixed to avoid needing "-e" ?
<\sh> guys..is there any documentation how the kernel enumerates e.g. NIC interfaces?
<ogra> isnt that done by udev ?
* You're now known as ubuntulog
<kees> \sh: they all start as "eth0", and then udev renumbers them based on /etc/udev/rules.d/70-persistent-net.rules
<kees> (roughly)
<pitti> s/start as eth0/start in random order/
<\sh> kees: yes...that I know..and that's actually a problem...kernel finds e.g. external NICs first, and then the internals..udev enumerates then eth0...ethN which can cause really serious problems...e.g. I don't have the possibility to boot pxe/mount NFS from the external nics...but kernel + udev are telling me, my internal card is eth3
<kees> \sh: yeah, you'll want to adjust /etc/udev/rules.d/70-persistent-net.rules if you want to control how they're named.
<ogra> there is a kernel commandline option for ipconfig to enfoce a NIC being the first one
<ogra> kees, doesnt help with PXE
<\sh> kees: sure...that's what I would do when I'm already have an installed system..but using automation for deploying, that doesn't help
<kees> ogra: PXE is before the kernel though?
<\sh> kees: yes
<ogra> right
<\sh> kees: 1. pxe, 2. kernel booting via tftp, 3. /scripts/live-premount which does IPConfig: and then there is udev telling me your eth0 is not my eth0 and my eth0 is your eth3 ;)
<ogra> i cant remember it from the top of my head, but the guys in #ltsp use it often
<kees> \sh: what I did for this in the past was to either pre-populate the image with the NIC MAC I knew was in the machine (since I had that already for the PXE configs), or I wrote scripts in the target that checked interfaces for the right DHCP lease.
<kees> but, I'd do whatever ogra says since I've got only small experience with this.  :)
<cjwatson> kees: http://bazaar.launchpad.net/~ubuntu-core-dev/user-setup/ubuntu/revision/179 - look at the user-setup-apply bit
<\sh> kees: the problem is time ;) kernel boots and then /scripts/live-premount starts and somehow inside this initramfs script there is this IPConfig which takes udevs eth0 which suddenly is not the boot device...
<cjwatson> kees: i.e. it uses usermod --password - it can get away with this because d-i controls the entire system and doesn't have to worry about command line visibility in ps
<cjwatson> kees: I don't know if there's a better way ...
<slangasek> CDBS_REPLACES += , python2.3-moinmoin (<< 1.5.3-1.1), python2.4-moinmoin (<< 1.5.3-1.1)
<slangasek> Replaces: ${cdbs:Replaces}
<slangasek> Doing. It. Wrong.
<cjwatson> kees: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528610
<ubottu> Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528610;mbox=yes)
<directhex> poor ubottu
<soren> Does anyone know where HWCLOCKACCESS (used by /etc/init.d/hwclock) is supposed to be set? I was thinking /etc/default/rcS, but it's not mentioned in the rcS(5) man page.
 * ogra knew that once
<ogra> soren, /etc/default/rcS should be right, its just not in there by default
<kees> cjwatson: what a mess.
<soren> ogra: Thanks.
<kees> cjwatson: so... now usermod needs a "read stdin for the password" option.  :P
<cjwatson> kees: I suspect they might be amenable to restoring -e and making it force non-PAM, judging from bug logs I've seen
<cjwatson> but dunno
<kees> cjwatson: well, I support the PAM-integration -- but -e and -S are needed to "split" the halves of the PAM stack (select hash, store hash)
<ogra> \sh, you want IPOPTS=:::::eth0 (and change eth0 to whatever your device is)
<ogra> put that into your append line
<ogra> in pxelinux.cfg/default
<cjwatson> kees: yes
<\sh> ogra: will it tell IPConfig of udev to use this device?
<ogra> it will tell ipconfig ... its an ipconfig option
<ogra> \sh, http://codtech.com/wiki/index.php/Ipconfig might be helpful
<\sh> ogra: well...regarding this...the ipconfig inside initramfs does something wrong
<bryce> pitti: for -intel, at the moment xorg-edgers and karmic should be identical.
<ogra> how so ?
<bryce> pitti: for now, testing xorg-edgers is preferred.
<pitti> bryce: good, I'll continue to do so then
<bryce> pitti: probably makes sense to keep testing xorg-edgers up until beta or so
<\sh> ogra: forget it....I mis-readed the entry...
<\sh> and the source
<ogra> it doesnt help much with udev shuffling around the names but it helps with enforcing a device name for netbooting
<\sh> well...if you have HW which behaves always the same, this is not a problem :)
<ogra> right
<ogra> and otherwise its trial and error
<ogra> might just take multiple attempts
<kees> cjwatson: say, can you snag kbd if you're doing merges?  I don't really know that package very well.
<slangasek> cjwatson: would you mind doing a review of the lsb packages in {hardy,jaunty}-proposed?
<jcastro> bryce: do you have a wiki grid or something for the latest intel driver? or do I just tell you "much better after this upload"?
<bryce> jcastro: the latter is fine :-)
<bryce> we've gotten enough test results now, we're confident of the path forward now
<ogra> jcastro, "awesome in karmic" :)
<ion_> awesome in karmic: 3.3~rc4-1
<ion_> :-P
<ogra> well, stable for me ... and fast as in intrepid :)
 * mcasadevall feels like its getting to be the time I should upgrade to Karmic 
<ogra> you havent yet !?!
<ogra> youre a developer ... eat your own dogfood !!!
<mcasadevall> ogra, I won't upgrade until I can run a liveCD to make sure my system won't be hosed after upgrading
<mcasadevall> ogra, although I don't think I can put it off much longer
<pitti> mcasadevall: it's generally working fine
<pitti> mcasadevall: and if -intel should really totally break for you, you can always blacklist i915 to get back X with metacity
<mcasadevall> If -intel breaks, I flip the switch and use -nv :-)
<mcasadevall> Yay dual graphics cards.
<ogra> yeah, i use it day to day since uds
<kees> is MoM stalled?  It seems to be a bit behind.
<mcasadevall> Hrm, now the question is format and install, or upgrade
<cjwatson> kees: sure
<cjwatson> slangasek: ok
<tormod> mcasadevall: although there is no official live cd, we made an xorg-edgers live cd you can try: http://people.ubuntu.com/~bryce/xorg-edgers-0.1-i386.iso
<ogra> mcasadevall, sudo update-manager -d
<ion_> mvo: Btw, is posted some comments to https://wiki.ubuntu.com/AptSyncInKarmicSpec (at the end).
<cjwatson> BTW, if anyone desperately wants to debug what's happening to unionfs-fuse on the live CD at the moment, I wouldn't say no ...
 * ogra will take a look, but not today
<ogra> stgraber, did you test it with ltsp btw ?
<mcasadevall> cjwatson, what was the specific issue? (I did some debugging into it when working on UDS< but my setup was non-standard enough that I couldhave been seeing a different issue)
<cjwatson> mcasadevall: it falls over half-way through, manifesting as login not being able to start /bin/bash
<mvo> ion_: nice, have you done some benchmarks with zsync and lookinside gzip yet?
<mcasadevall> cjwatson, right, same issue I saw
<cjwatson> it basically manages to get most of the way up, so I think it's one specific fuse call that's hosing it
<mvo> ion_: as in "how much data will it still need to fetch" ?
<mcasadevall> cjwatson, I traced to getting as far as upstart coming up, it destablizes itself after one of the startup scripts, but I didn't isolate it
<ion_> mvo: Havenât got around to that yet.
<ion_> mvo: But the look-inside-gzip mode will most likely fetch less data even with gzip --rsyncable.
<mvo> ion_: that is my gut-feeling as well, I would love some data on it :)
<cjwatson> mcasadevall: I think the problem is with processes running as non-root, but I thought I'd fixed that!
<mcasadevall> cjwatson, no, the issue happens while root (which I tested being in single-user on the CD< then running scripts by hand)
<cjwatson> I'm definitely seeing symptoms that I know I fixed that way
<cjwatson> mcasadevall: the first thing that fails for me is klogd, and the failure is right after it drops privileges to the klog user
<cjwatson> I believed I had fixed this by using -o default_permissions -o allow_other -o suid
<mcasadevall> If the klogd script is removed, do you get a successful startup?
<cjwatson> there are lots of other things broken, I'm not going to waste my time on that kind of check
<cjwatson> it's clear that access from other ids is broken (I can reproduce similar things with sudo, for instance) and that's going to break stuff all over the show
<cjwatson> I've fixed this before, so I just need to figure out what went wrong with my fix
<\sh> ogra: this IPOPTS doesn't work...
<Nilbus> what license is ubuntu distributed under?
<cjwatson> Nilbus: a wide variety of licences; the basic requirements we place on them are described in http://www.ubuntu.com/community/ubuntustory/licensing
<Nilbus> thanks cjwatson
<Nilbus> looks like I could have found that googling. sorry to bug
<cjwatson> Nilbus: you redeem yourself by being the first person in months to say that, though :-)
 * Keybuk waits for the day someone says they could have found that by binging
 * ogra glares at the date
<Nilbus> cjwatson, ha thanks I guess
<Nilbus> :)
<slangasek> Keybuk: ...binging?
<Keybuk> slangasek: http://www.bing.com/
<ogra> slangasek, MS's new toy
<slangasek> I could've found that by purging
<Keybuk> Microsoft rebranded MS Live Search, and clearly asked for a word people could verb
 * rickspencer3 sigh
<Keybuk> Microsoft Bing Powered By Microsoft Live Search 3.11 for Workgroups NT
<robbiew> I "binged" you...heh
<slangasek> Microsoft Bing Seen 2000
<robbiew> sounds a bit "nasty" :P
<Keybuk> rickspencer3: it's ok, you escaped
<rickspencer3> Microsoft Windows Live Bing powered by Microsoft Windows Live Search Technology
 * mdeslaur thinks it should have been named "bong" based on the search results it generates
<rickspencer3> lol
<tedg> I like the pop-up previews on the right though.  That's a nice touch.
<maxb> Have you seen how pathetically biased the search results are, though?
<maxb> Hint: enter "linux" and look at the top autocompletions :-)
<Keybuk> that's awesome
 * Keybuk wants Linux Vista
<mdeslaur> didrocks: I published a security update for pidgin today. Were you planning on merging pidgin? Do you want me to?
 * slangasek wants Linux Olida
 * Keybuk wants a Linux Daiquiri
<Nilbus> cjwatson, so essentially, does ubuntu not put a license on the distribution as a whole?
<cjwatson> Nilbus: that's correct
<cjwatson> Nilbus: in many cases, we would actually be violating the licences on other people's code by attempting to do so - most licences don't allow relicensing
<slangasek> Keybuk: blech, with all those ground-up kernels in it?
<Nilbus> cjwatson, ok. right
<Nilbus> make sense
<stgraber> ogra: not yet
<mdz> it seems neither totem nor totem-gstreamer has the actual binary anymore, is it in some other package now?
<cjwatson> totem-gstreamer ships /usr/bin/totem-gstreamer and registers an alternative for /usr/bin/totem
<cjwatson> unless this changed since my mirror last pulsed
<mdz> perseus:[~] dpkg -L totem-gstreamer | grep bin
<mdz> zsh: done       dpkg -L totem-gstreamer |
<mdz> zsh: exit 1     grep bin
<pitti> mdz, cjwatson: this was discussed in #u-desktop an hour ago
<pitti> wrong alternatives cleanup in postinst
<mdz> pitti: thanks
<pitti> there's debian/lp bugs for it, too, on the way
 * slangasek mourns the channel fragmentation
<seb128> mdz: should be fixed in 0ubuntu3 which is building
<\sh> ogra: btw...this ipopts thing can be written as "ip" (standard kernel commandline as documented) the ubuntu initramfs can actually use it..the lenny one has some problems with it, it seems...
<seb128> mdz: sudo apt-get install --reinstall totem to fix it
<mdz> seb128: thanks
<mdz> seb128: I was just reading the scripts to see if that would fix it, thanks
<seb128> mdz: totem-gstreamer is a dummy package, there is only totem which is gstreamer now
<mdz> pitti: bug 383187 is the one referenced on #-desktop
<ubottu> Launchpad bug 383187 in totem "totem doesn't open" [High,Fix released] https://launchpad.net/bugs/383187
<ogra> \sh, we share the same initramfs code for netbooting, so thats surprising
<mdz> slangasek: indeed
<\sh> ogra: this lenny initramfs is using the /usr/share/initramfs-tools/scripts/live* infrastructure on jaunty I didn't see it...but in .../scripts/functions we (ubuntu) have now the configure_networking() bash func which handles the IP/IPOPTS stuff currectly...but the "scripts/live" of debian lenny just did an ipconfig -d ${DEVICE} without checking if there is something in ip/ipopts
<ogra> oh, then its actually changed ... we used to usew the  ipconfig -d ${DEVICE} line too before
<ogra> i guess sid uses configure_networking() too
<ogra> so might be because of the long freeze lenny had
<\sh> ogra: I think sid == yes, but lenny == no...I changed it now manually and had the wanted behaviour
<didrocks> mdeslaur: please do. If you don't have the time, I can do it
<slangasek> hrm, why is ubuntu-bug crashing now :(
<ogra> file a bug :P
<slangasek> already reported
<mcasadevall> cjwatson, I'm trying to understand whats gone wrong with this build failure: http://launchpadlibrarian.net/27284406/buildlog_ubuntu-karmic-ia64.debian-installer_20081029ubuntu39_FAILEDTOBUILD.txt.gz. I've already ruled out the possibility that hdparm-udeb and util-linux-udev have /sbin as a file, but this issue still happens when I tried it yesterday afternoon
<pitti> slangasek: on some assertion about the bug title?
<slangasek> pitti: yes, bug #383104
<ubottu> Launchpad bug 383104 in apport "Ubuntu-bug crashed with AssertionError" [High,Triaged] https://launchpad.net/bugs/383104
<pitti> ah, I fixed that this morning
<slangasek> pitti: I guess you already fixed this in -3, right :)
 * slangasek upgrades to confirm
<cjwatson> mcasadevall: but util-linux-udeb *does* have /sbin as a file
<cjwatson> $ dpkg -c ~/ubuntu/pool/main/u/util-linux/util-linux-udeb_2.15.1~rc1-1ubuntu1_ia64.udeb
<cjwatson> drwxr-xr-x root/root         0 2009-05-29 12:42 ./
<cjwatson> (not ia64-specific)
<cjwatson> -rwxr-xr-x root/root     24992 2009-05-29 12:42 ./sbin
<mcasadevall> o__o;
<mcasadevall> (argh, I'm an idiot, but thats a separate issue)
<mcasadevall> Now the question is how did that happen
<cjwatson> mcasadevall: I suspect debian/rules forgets to create a directory before using install(1)
<slangasek> pitti: yeesh, enough changelog symlink indirection in apport? :P
<pitti> slangasek: hm?
<slangasek> once again, changelog symlinks without strict versioned dep == bad
<pitti> oh, that
<slangasek> pitti: I tried to manually upgrade apport.  I'm having to manually upgrade two more packages to actually get the matching changelog.
<ion_> mvo: https://wiki.ubuntu.com/AptSyncInKarmicSpec updated.
<cjwatson> mcasadevall: http://paste.ubuntu.com/187511/ should fix it
<maxb> apt-sync? Interesting. Why not pdiff/rred ?
<cjwatson> (against the ubuntu/master branch of lamont's git repository)
 * cjwatson wanders off for the evening
<mcasadevall> Ow, git :-/
<cjwatson> I suggest making either lamont or Keybuk do the actual commit and upload ;-)
<mcasadevall> cjwatson, probably a good idea :-). Thanks for your assistance on my blind eye :-/.
<lamont> mcasadevall: which version of util-linux, I wonder?
<lamont> as in this is 2.15.1?
<cjwatson> lamont: current in karmic
<cjwatson> 2.15.1~rc1-1ubuntu1
<mcasadevall> lamont, its whatever is in karmic: util-linux-2.15.1~rc
<mcasadevall> ^1
<cjwatson> lamont: I think my original patch to add the udeb was correct, but it looks as if the new file debian/util-linux-udeb.dirs got lost somewhere along the way
<cjwatson> lamont: and because util-linux IMO unwisely uses install(1) without a trailing slash on the target directory name, rather than a build failure, this resulted in a busted udeb
<mcasadevall> lamont, if you could fix it, it should get up 90% of the way of d-i building, and once d-i builds, ia64 alternate and livecds should build.
 * mcasadevall suspects he'll still need to nudge d-i's scripts to get it a large enough partition to plop a kernel onto
<cjwatson> err, and indeed ln(1) etc.
<slangasek> pochu: it appears you're responsible for the change that causes seahorse gpg-agent to no longer be running by default - should seahorse-plugins be a Recommends: of seahorse instead of a Suggests:?
<mvo> ion_: sweet
<slangasek> (if we're not going to run the gpg agent, I can't see why we would want seahorse itself installed by default at all...)
<cjwatson> lamont: I'd recommend something like http://paste.ubuntu.com/187514/ for future robustness
<seb128> slangasek: seahorse is the tools you use to handle gnome-keyring passwords too
<cjwatson> ok, really gone
<seb128> slangasek: we had this discussion with pitti and he thinks that the gpg agent is not a standard user feature and cost some login time
<lamont> cjwatson: now I just need to figure out if it's me or keybuk that I need to thwap
<slangasek> seb128: which bit of this is used for handling gnome-keyring passwords, then?  I can't even find this in the GNOME menu
<seb128> slangasek: applications, accessories, seahorse
<slangasek> heh
<seb128> or "key and password" or whatever is the english wording
<slangasek> "accessories" - not intuitive :)
<slangasek> "Passwords and Encryption keys"
<elmo> pitti: do you know of any bugs to do with cups where printers you've seen announced once never go away and can't be deleted?
<pitti> elmo: not off-hand (I'm not really following the bug reports on cups)
<pitti> elmo: I guess they are stuck in /var/cache/cups/remote.cache ?
<elmo> pitti: yeah
<pitti> elmo: you can't delete those with lpadmin/web UI, since they aren't really "there" locally
<elmo> pitti: I guess I'm just surprised they don't time out of their own accord
<pitti> elmo: they should; they do here
<slangasek> seb128: the other thing I don't understand is why the Debian changelog moved the Xsession file in 2.24.1, saying "the agent is now in seahorse-plugins", but with 2.26 in jaunty it was working just fine for me, seemingly without seahorse-plugins installed
<ion_> mvo: Added a short summary to the bottom.
<slangasek> seb128: ah, n/m; I see now that seahorse-plugins was removed on upgrade
<seb128> slangasek: searhose-plugins was installed in jaunty
<slangasek> right
<seb128> we used a recommends where debian is using a suggests
<slangasek> should seahorse-plugins also Provides: gnupg-agent?
<slangasek> seb128: btw, do you know why the g-p-m icon theme is broken for me, before I go filing a bug?
<seb128> no
<slangasek> ok
<seb128> slangasek: no idea about gnupg-agent are those equivalent?
<slangasek> well, there's no defined virtual package for it - but it implements the gnupg agent protocol
<slangasek> and a Provides: would've been discoverabel
<slangasek> seb128: bug #383256 filed, anyway, so that there's at least a record in LP of why the desktop team thinks I'm wrong :)
<ubottu> Launchpad bug 383256 in seahorse "seahorse no longer running after upgrade to karmic, no gpg agent available" [Undecided,New] https://launchpad.net/bugs/383256
<seb128> slangasek: thanks
<mdeslaur> didrocks: actually, someone has already started it: LP #380806
<ubottu> Launchpad bug 380806 in pidgin "Please merge pidgin 2.5.6 (main) from Debian sid (unstable)" [Undecided,In progress] https://launchpad.net/bugs/380806
<pitti> good night everyone
<ion_> Night
<ion_> mvo: Updated the latest benchmark with what happens with method #3 if inputfile hasnât been packed with --rsyncable.
<stefanlsd> slangasek: do you know any packages using dep5 debian/copyright that I could see?
<dupondje> could somebody plz check https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/383271
<ubottu> Ubuntu bug 383271 in audacious "Please merge audacious 2.0.1-1 (universe) from Debian unstable (main)" [Undecided,Confirmed]
<dupondje> its my first merge, so hope its correct :)
<stefanlsd> dupondje: better to ask in #ubuntu-motu
<slangasek> stefanlsd: not yet; the dep5 is still in flux
<stefanlsd> slangasek: ok thanks! i was doing a package for revu - is it ok to use?
<slangasek> stefanlsd: I don't think *any* of the machine-readable copyright formats provide very good guidance about their use yet; whether or not it's ok for revu is not my call, but I would recommend using something that other people are already using
<slangasek> directhex: I see mono's on the merge list again; is that in a syncable state now?
<stefanlsd> slangasek: thanks
<pochu> slangasek: that makes sense, yes
<pochu> (bumping seahorse-plugins to a Recommends)
<slangasek> pochu: see subsequent discussion with seb128; turns out that this *was* a Recommends previously
<slangasek> in Ubuntu
<slangasek> and it's been dropped
<xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: âLDAP_OPT_X_TLS_PROTOCOLâ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
<xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: âLDAP_OPT_X_TLS_PROTOCOLâ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
<kees> pitti: I have some updates in lp:~kees/apport/apport.segv-analysis for you
<nxvl> slangasek: ping
<slangasek> nxvl: hi
<joaopinto> pitti, I have learned that kubuntu is going to use packagekit as the default installer for karmic, do you have any idea how they plan to address those limitations you described earlier ?
<nxvl> slangasek: about exim4 -> postfix mail on devel, i just made the list of the package depending on those two, don't you think it will be usefull to put a wiki page with those to make the change?
<nxvl> slangasek: or at least to make that information available for people that want to help
<lamont> nxvl: I'll be uploading postfix 2.6.2~rc1-1 to sid today, which will DTRT on ubuntu once synced to karmic
<nxvl> lamont: mmm, have you read the e-mail steve sended?
<slangasek> nxvl: no objections, but I'm not really looking to make a campaign out of this - just to let people know there's a way to get rid of existing deltas as they're doing merges
<lamont> nxvl: lalalala
<lamont> nxvl: the upload of postfix is to have it Provide: default-mta on ubuntu
<nxvl> slangasek: so, is not a goal for karmic?
<nxvl> lamont: ohh!! got it!
<lamont> nxvl: and no, haven't actually read the email, though I suspect the discussion I had with slangasek trumps it
<nxvl> lamont: i was confused about that :P
<slangasek> lamont: no, the email in question was letting ubuntu-devel know default-mta was open for the using
<slangasek> nxvl: <shrug> it's not a goal of *mine* for karmic :)
<nxvl> lamont: yup, that said now it makes sense, your first comment sounded off-topic to me, but now i get the full idea of why you said it
<lamont> slangasek: right.  trumped by our discussion (or confirmed, or whatever...)
<lamont> nxvl: postfix already knows whether it's building on ubuntu or debian
<lamont> so one more bit of abuse doesn't hurt, right?
<nxvl> lamont: really? awesome
<lamont> yeah - because no way I'm going to maintain a fork (for 5 years now) just to get the banner to be different between debian and ubuntu
 * slangasek NMUs postfix to Debian and builds it on Ubuntu, teehee
<lamont> gigglr
<lamont> if [ $(DISTRO) = Ubuntu ]; then echo postfix:Provides=default-mta >> debian/postfix.substvars; fi
<lamont> see... that's easy
<lamont> slangasek: please sync postfix 2.6.2~rc1-1 from sid kthx
<lamont> though if you wait until the next dinstall run, it'll be in sid instead of incoming...
 * slangasek will wait for dinstall
<lamont> lazy
<slangasek> yes
<lamont> though it wouldn't be any work to upload 2.6.2~rc1-0build1....
<lamont> though that should be -1~0build1
<slangasek> you can if you wish :)
<mweichert> is it possible to run gvfs outside of gnome or X?
<lamont> slangasek: the exim in karmic doesn't provide: default-mta, right?
<slangasek> lamont: right
<slangasek> (as of about the time I pinged you about this :)
<lamont> uploaded
<lamont> er, ing
<lamont> slangasek: and nothing from 2.5.5-1.1ubuntu1 I need to worry about, right?
<lamont> as in - I'm gonna totally ignore that ever existed
<slangasek> the only change was the default-mta bit
<lamont> yay
<lamont> and 2.6.2 will release sometime soonish, so I'm not too caring about the ~rc1 bit of that version
<lamont> that and Wietse is pedantically anal about stable updates
<calc> anyone else notice firefox seems more laggy than usual lately?
<calc> oh, in karmic
<cody-somerville> calc, My new P8600 and 4GBs of ram makes everything seem fast.
<calc> i have the same and its lagging badly for some reason
<calc> like pageup/pagedown even lags
<xenocampanoli> Subject:  trying to compile libldap-ruby I get ldap.c:424: error: âLDAP_OPT_X_TLS_PROTOCOLâ undeclared (first use in this function).  This is shown as a macro only in my /usr/include/ldap.h.  Another told me it is commented out in his /usr/include/openldap.h, but I do not have one of those.
<slangasek> xenocampanoli: this is not a help channel; but the libldap-ruby package in Ubuntu appears to be built just fine, perhaps you're using some ldap.h other than the one from Ubuntu?
<jelmer> tedg: hi
<tedg> jelmer: Hello.
<jelmer> tedg, jam and I managed to fix the bug you were hitting in bzr during UDS
<jelmer> tedg, I've just submitted the fix to PQM
<tedg> jelmer: Whoo!  Hooo!  Many thanks!
<jelmer> tedg, There was also another issue, caused by an early bzr-svn bug that has been fixed now.
<tedg> jelmer: So is there a snapshot that I can grab then?  I don't think that bzr-svn is in the bzr nightly PPA, right?
<jelmer> tedg: That bzr-svn bug has been fixed, but your bzr branches on launchpad seem to've been created with an older version of bzr-svn that had that bug so those branches are broken.
<jelmer> tedg: You'll need a nightly version of bzr, and probably to ditch and recreate your existing inkscape branches on Launchpad from svn
<tedg> jelmer: Ah, okay.  That's fine.  I'll recreate.  Can I merge the old ones in?  Will that create something useful?
<xenocampanoli> slangasek:  No, the libldap-ruby package has a bug (https://bugs.launchpad.net/ubuntu/+source/libldap-ruby/+bug/381791) on Ubuntu Server and I am trying to compile it in a standard environment to get diagnostics for that bug, and it won't for me.  Perhaps I am leaving out a step.
<ubottu> Ubuntu bug 381791 in libldap-ruby "LDAP::SSLConn from ruby fails, probably from not seeing cert" [Undecided,New]
<xenocampanoli> Oh yeah.  That's my bug.  See my name? ;^)
<xenocampanoli> slangasek:  I am using a standard environment.  Is there another place I should seek this help?
<jelmer> tedg: I'm not sure if that would do anything meaningful. If possible, it would be best to just keep the two separate.
<jelmer> tedg, And sorry this took so long.
<tedg> jelmer: No problem.  Happy that it's fixed.  I've been using SVN...  remember those days all too fondly now :)
<slangasek> xenocampanoli: ok, I can confirm the build failure in karmic
<slangasek> xenocampanoli: apparently libldap-ruby assumes LDAP_OPT_X_TLS_PROTOCOL is a constant, not a macro w/ arguments.
<slangasek> xenocampanoli: so I would say this is an upstream bug in libldap-ruby
<prefrontal> i need -fprofile-correction from gcc 4.4 but i'm using jaunty and its in karmic
<xenocampanoli> Thank you.  I haven't put the compiler in as a bug, only my other problems.  Do you want me to do so?
<xenocampanoli> slangasek:  Thank you.  I haven't put the compiler in as a bug, only my other problems.  Do you want me to do so?
<xenocampanoli> slagasek:  compiler error that is.
<slangasek> xenocampanoli: filing a bug report would be advisable :)
<xenocampanoli> slangasek.  I'll put a number here when I'm done.
<prefrontal> installing a package like gcc from a newer dist could be problematic. it likely requires libc etc...
<prefrontal> not advisable?
<prefrontal> or are jaunty/karmic still fairly binary compatible
<xenocampanoli> slangasek:  https://bugs.launchpad.net/ubuntu/+source/libldap-ruby/+bug/383371
<ubottu> Ubuntu bug 383371 in libldap-ruby "Compiler error trying to build libldap-ruby from source" [Undecided,New]
<xenocampanoli> slangasek:  Please I am open to suggestions on this bug environment and its standardsd.
<xenocampanoli> slangasek:  I know if you can formally confirm 383371 it will likely expedite it's handling.
<slangasek> xenocampanoli: realistically, expediting it means finding a developer who uses ruby; it seems this same bug has been open on the Debian package for over two months, and the Debian maintainer hasn't taken any action yet
<xenocampanoli> slangasek:  Well, I may not be competent to debug encryption stuff, but if I am allowed, and with help regarding the architecture, I can probably come up with the solution.  I've written near 100,000  lines of C in my life, though mostly over 10 years ago.
<slangasek> this particular build failure could be fixed by commenting out the lines referring to LDAP_OPT_X_TLS_PROTOCOL
<xenocampanoli> slagasek:  Trouble is, I will need to decide the intentions of the developer in charge for this macro.
<slangasek> I don't know if that's a correct fix
<xenocampanoli> slangasek:  Yes, I will need to study the code more.  How do we discover if the code has been orphaned?  I have an email into the maintainers listed in the README.
<slangasek> xenocampanoli: hopefully there's also accurate information in debian/copyright that can be used to contact upstream
<amitk> hmm.. I lost my gdm login screen after an upgrade to karmic on my 32-bit laptop
<xenocampanoli> slangasek:  I don't have an account in the Debian area, only on launchpad.  Perhaps I should do that...?
<slangasek> xenocampanoli: debian/copyright is the file in the source package.  And the Debian BTS doesn't use accounts, it's email-only
<YokoZar> Just uploaded the first branding-ubuntu package.  So far all it has is a new gnometris theme
<YokoZar> https://wiki.ubuntu.com/branding
<slangasek> amitk: KMS?
<xenocampanoli> slangasek: Oh, Yes, that's where I got Ian's and Akira's email addresses.  Sorry.  The copyright's in the readme were in fact what I got the emails from.
<xenocampanoli> slangasek:  So, presumably if I come up with a solution, I can post that on the bug and at least it is likely to get used at some point...???
<slangasek> xenocampanoli: if you find a solution, I suggest you follow https://wiki.ubuntu.com/SponsorshipProcess to get the fix included in Ubuntu
<amitk> slangasek: default upgrade. Haven't yet enabled KMS.
<slangasek> amitk: oh.  UXA? :)
<xenocampanoli> slangasek:  Thank you for confirming and all your help.
<amitk> slangasek: xorg.conf had a 'virtual' line that seemed to be causing the problem
<dtchen> TheMuso: WRT desktop-karmic-audio-experience: will do
<TheMuso> dtchen: thanks
<Riddell> joaopinto: we already have kpackagekit as our package manager in jaunty
<Riddell> its main limitation is not being able to install java, that's a pain but I can live with that with openjdk
<andre> hello... iam using ubuntu9.04 with gnome... anyone knows how to change from utf8 to iso8859-15? on console i already have changed. but it seems that nautilus is creating files with UTF8-names
#ubuntu-devel 2009-06-04
<joaopinto> Riddell, you mean java and any other packages requiring a prompt ?
<persia> andre, For assistance, you probably want #ubuntu (or #ubuntu-${country code}).  Aside from that, you really don't want to make that change, because all the files on your system are UTF-8, and you will encounter problems.
<andre> persia, with kubuntu i hadnt any bigger problems...
<Riddell> joaopinto: java is the only package which doesn't install without debconf that I know of
<Riddell> that's the biggest problem for users
<joaopinto> ok
<Riddell> joaopinto: do you know of other problems?
<joaopinto> well, no, but pitti mentioned this morning that those problems prevented it from getting adopted for Ubuntu (gnome)
<joaopinto> so it's a bit strange that it will work for Kubuntu
<Riddell> the other problems that come to mind are issues with signature authentication, we have problems syncing the repositories to the list of packages shown
<Riddell> and other packages use debconf and aren't ideally installed without it, mysql won't have a password set for example
<joaopinto> doesn't that bring support complixity increase ? e.g. we will need task if mysql was installed from ubuntu or kubuntu ;)
<Riddell> joaopinto: yes a wee bit, although most mysql admins should know how to set the root password anyway, but it's an issue
<joaopinto> well, I am looking a it from a general perspective, packages installs with different results based on the WM
<Riddell> WM!=desktop
<joaopinto> well, name it flavor, whatever :)
<persia> Also, desktop or flavour selection doesn't map perfectly to package manager.  While it's not default, there's no reason a user can't use a PackageKit solution in GNOME/XFCE or a non-PackageKit solution in KDE.
<Riddell> right, but for documentation you can assume the defaults get used
<joaopinto> I am not familiar with Kubuntu, doesn't it present a default Add/Remove menu item ?
<persia> Riddell, support != documentation, but for documentation, I completely agree.
<joaopinto> persia, documentation is a type of support IMHO
<persia> joaopinto, Perhaps a component, but I'm quibbling, rather than objecting.
<Riddell> joaopinto: yes, kpackagekit in jaunty
<Riddell> we're not arguing :)
<joaopinto> ok, I just hope it will work ok :)
<joaopinto> now I feel Kubuntu is ubuntu+2 :P
<TheMuso> wii dtchen
<TheMuso> dtchen: so what do we do with those power save bugs?
<TheMuso> How can be attempt to prevent popping etc?
<slangasek> pitti: you patched epiphany-extensions to build an epiphany-extensions-2.24.pot; is this still what we want it to be called, now that we're on to 2.26?  (apparently the auto-selection of the name based on ABI version was failing)
<nixternal> who is leading this whole Apt URL discussion? I am interested in getting in on it if possible. is it being documented somewhere?
<slangasek> pitti: it looks like the original bug is fixed, so I guess it's just a question of whether it's ok to have the name changed within rosetta
<dtchen> TheMuso: we add the missing HDA_AMP_MUTE/AC_VERB_SET_AMP_GAIN_MUTE calls
<TheMuso> ah ok.
<TheMuso> dtchen: what if there is not already a quirk for that piece of hardware?
<dtchen> TheMuso: more code to write ;)
<TheMuso> yay
<cjwatson> oho, I just figured out what the problem was with unionfs-fuse on the karmic live CDs
<cjwatson> and it's a one-liner in initramfs-tools
 * stgraber needs to look at unionfs-fuse for LTSP ...
<cjwatson> though it's still painfully slow
<cjwatson> it went faster than this in my tests on jaunty :-/
<StevenK> cjwatson: Awful early, isn't it?
<cjwatson> insomnia
<StevenK> Ugh :-(
<cjwatson> anyway, mostly up 'cos that problem was bugging me, so I'll go back to bed now
<StevenK> cjwatson: I'm about to accept -8 into karmic, shall I fix the platform seeds too?
<cjwatson> anyone who wants to figure out why it's stultifyingly slow is welcome
<cjwatson> StevenK: not unless you're also going to change d-i
<StevenK> cjwatson: I can do that too, but I've not done it before
<cjwatson> either (a) leave seeds and d-i alone and don't NBS-remove -6 which is what they're currently using or (b) change both seeds and d-i
<StevenK> I'll do (a), and wait for your all clear
<cjwatson> either's fine, if you do (a) then I'll do the changes in sync tomorrow
<cjwatson> actually
<cjwatson> right now (a) is best, because util-linux-udeb is broken in a way that hoses d-i builds
<StevenK> Oh, fun
<cjwatson> lamont: did that patch look ok?
 * cjwatson &
<billisnice> The update today seemed to fix the printer Samba?
<prefrontal> i need the latest gcc that is available in karmic and i'm a pretty experienced ubuntu user/packager
<prefrontal> is it safe to `update-manager -d' from jaunty to koala?
<prefrontal> i assume some of you guys are running it?
<geofft> If you just want gcc, you can add karmic to your sources.list and use apt preferences to pin everything else to jaunty
<prefrontal> i don't think its going to work. there is a bug.
<Hobbsee> i'm running it
<Hobbsee> it runs
<Hobbsee> it might explode tomorrow, but seems stable today
<prefrontal> i built the new gcc from source and it can't find GLIBCXX_3.4.11
<prefrontal> Hobbsee could you run this for me: strings /usr/lib/libstdc++.so.6 | grep GLIBC
<prefrontal> i'm looking for 3.4.11
<Hobbsee> sarah@pluto:~% strings /usr/lib/libstdc++.so.6 | grep GLIBC | grep 3.4.11
<Hobbsee> GLIBCXX_3.4.11
<prefrontal> ok i'm updating:)
<prefrontal> Hobbsee, tx
<Hobbsee> prefrontal: depending on what you want to do, a chroot may be helpful
<Hobbsee> if you don't wnat to fully upgrade
<Hobbsee> and you're welcome
<prefrontal> i also want to include a package in the next ubuntu so it makes sense for me to upgrade to karmic now
<Hobbsee> ahh
 * StevenK has two Karmic chroots for that
<prefrontal> StevenK, do you have a guide you follow for that?
<Hobbsee> !chroot
<ubottu> chroot is used to make programs believe that the directory they are running in is really the root directory. It can be used to stop programs accessing files outside of that directory, or for compiling 32bit applications in a 64bit environment (https://wiki.ubuntu.com/DebootstrapChroot)
<Hobbsee> StevenK: I find i find, and fix more bugs if i'm actually running it
<StevenK> prefrontal: https://wiki.ubuntu.com/PbuilderHowto
<StevenK> Hobbsee: Sure, because then they annoy you.
<Hobbsee> precisely
<StevenK> My netbook will getting Karmic thrust on it for alpha-2
 * ajmitch_ tends to upgrade piecemeal
<prefrontal> pbuilder is going to help me make a standards compliant package?
<prefrontal> or i still need to go through the manual and do it all by hand?
<ajmitch_> pbuilder just helps with building the binary packages
<prefrontal> have you guys ever tried downgrading? if i hate karmic, can i go back to jaunty? seems like it would work
<StevenK> Downgrading is not supported
<lamont> cjwatson: meh. didn't look at the util-linux thing - did you need it tonight?
<lifeless> prefrontal: the dpkg package manager doesn't reliably downgrade, as such we don't support downgrading
<StevenK> lamont: Are you going to stop hppa building karmic packages? :-)
<lamont> StevenK: no.  infinity is
<StevenK> Well, someone is, which is good.
<lamont> don't let the fact that something doesn't have hppa bits keep you from promoting it/etc
<prefrontal> well i think i borked my jaunty system by installing the latest gcc from source. jaunty does not provide GLIBCXX_3.4.11 and gcc does not have an uninstall target
<lamont> FTBFS on HPPA is now officially "so?"
<lamont> prefrontal: mucking about with toolchain is best done in a chroot, not in the real root
<slangasek> lifeless: s/the dpkg package manager/the package maintainer scripts/, really
<StevenK> Oh, I've been ignoring FTBFS on hppa for ... oh, three releases?
<lamont> StevenK: ^5
<ajmitch_> installing from source on top of packaged software tends to end in tears
 * StevenK grins at lamont 
<lamont> slangasek: yeah - the fact that package maintainers don't care so much about downgrading working doesn't mean that the package manager doesn't - just that it's largely untested and therefore "fraught with peril"
<lifeless> slangasek: sadly precision doesn't help answering all questions.
<lamont> cjwatson: happen to have the patches/pastebin links handy?
<lamont> otherwise I'll deal with it in the morning
<lamont> lifeless: I think he was more meaning "it's not apt/dpkg's fault that it's b0rked"
<StevenK> Hmm. I wonder if duplicated files are a REJECT reason
<lamont> ajmitch_: I think you mean s/tends to/nearly always/
<lamont> StevenK: nope.
<prefrontal> has anyone scripted all these DebootstrapChroot steps?
<lamont> that's just an install time failure
<lamont> prefrontal: beyond just running debootstrap?
<StevenK> Meh, I'll accept it and then file a bug
<lifeless> lamont: except that dpkg is not designed to support downgrades.
<lamont> lifeless: bullcrap
<lifeless> lamont: old version maintainer scripts by defintion don't have enough data
<lamont> dpkg fully supports downgrades.
<lamont> that's why it runs the new version too
<lamont> s/too//
<lamont> well, depending on what you hosed between versions, of course.
<lifeless> lamont: I thought it ran the current version on pre, then the unpacked version on post
<lamont> hence the "fraught with peril"
<lamont> I haven't read the docs recently
<lifeless> lamont: Last time I dug into this its theoretically possible to dtrt in maintainer scripts but actually very hard, especially given arbitrary version intervals
<slangasek> lifeless: which means that the maintainer scripts from the new version of the package need to detect there's a downgrade happening, and roll things back
<lamont> but yeah, there are some interesting situations where the downrev scripts aren't quite smart enough to deal with the downgrade
<slangasek> which is not unsupported by dpkg, it's just uninteresting and so almost no maintainer scripts do it
<lamont> lifeless: what he said
<slangasek> (I've written some that do, but then I'm crazy)
 * StevenK kicks Launchpad
<StevenK> "branding-ubuntu" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
<lamont> slangasek: and we all appreciate your largely never-tested-in-real-life support for downgrading
<StevenK> Sure it does, I just accepted it!
<lifeless> so, ack to all of that. And I know (you note I'm not arguing :)). But it doesn't make a good answer to prefrontal :)
<prefrontal> ok, i want to do a karmic chroot but first i need to fix my borked jaunty. all i did is compile gcc from source via ./configure && make && make install
<StevenK> Argh!
<prefrontal> problem is, how do i now get rid of the damn thing
<lamont> prefrontal: and therein lies great pain and suffering
<lamont> so once you've recovered from that, debootstrap karmic karmic karmic :-)
<prefrontal> which upgrading to karmic will fix...
<lamont> or even debootstrap --variant=buildd karmic karmic
<StevenK> prefrontal: If you're lucky, it's all over /usr/local
<prefrontal> it is all over /usr/local. gcc is kind of huge though
<lifeless> rm -rf /usr/local?
<lamont> that might be the simplest solution
<prefrontal> oh it looks like i don't have the nfs /usr/local..thank god too
<ajmitch_> possibly a bit of overkill there, but the alternative would be going through & cleaning up /usr/local{lib,bin} at the very least
<prefrontal> that means i can rsync --delete my buddies /usr/local
<lifeless> I wonder if autoconf should be taught to check for debian/redhat etc systems and refuse to run without a 'doing a package build' env variable ;)
<lifeless> ajmitch_: include, share, man
<StevenK> Eek
<ajmitch_> lifeless: depends on how much those bits of /usr/local would affect a packaged gcc, I guess, but it's a mess anyway :)
<lifeless> StevenK: consider that INSTALL for most upstreams says 'do X Y Z' which are precisely the instructions to wedge a binary package maintained system
<prefrontal> i can't believe gcc doesn't have an uninstall target. it uses autoconf
<lamont> cjwatson: you still awake?
<lamont> is the udeb thing just for ubuntu, or for debian too?
<lifeless> lamont: fairly sure its debian too, for d-i
<lamont> yeah - except for the part where there isn't a util-linux-udeb package
<lamont> except for the part where ubuntu _does_ have util-linux-udeb
<lifeless> yes, rmadison ftw
<lifeless> EOF for my knowledge here
<prefrontal> it worked..phew sudo rsync -av --delete me@eon:/usr/local/ /usr/local/
<prefrontal> bye bye gcc
<lifeless> another thing you could have done
<lifeless> find /usr/local -age {or whatever the flag is}
<prefrontal> ahh
<lamont> cjwatson: merged, and yeah - will upload in the morning unless y'all scream and make keybuk do it sooner
<lamont> Keybuk: pushed, if that helps any
<lamont> lifeless:  ! -mtime +1
<lamont> or ! -newer timestampfile
<lifeless> lamont: yeah, I always have to look it up
<lamont> clearly, you don't use find enough
<lifeless> I find I use it precisely often enough ;)
<lamont> find is love
<lifeless> but not sex
<lamont> no.  it's _NOTHING_ like sex
<lamont> sex is better.  much better.
<prefrontal> find is a PITA
<prefrontal> '{}' \;
<lamont> prefrontal: never use that
<StevenK> No, I agree with lamont, find is love. It's just love from the 1970's, and hasn't discovered -- yet
<lamont> use -print0 | xargs -0 :-)
<lamont> -- is for lusers
<lamont> on that note, time for this one to go to sleep
<prefrontal> thanks for help lamont
<prefrontal> (and others! StevenK etc.)
<prefrontal> how many hours will it take me to package our software for karmic? its using cmake but i don't think the `make deb' target from cpack is going to help me
<prefrontal> and do you guys script the whole process, or do it by hand every time?
<lifeless> prefrontal: #ubuntu-motu may give better answers
<lifeless> prefrontal: there is lots of tutorials on packaging software
<prefrontal> i'm just surprised that the process is so manual because ubuntu has an impressively wide array of software already packaged
<prefrontal> seems like a higher level tool could encapsulate this
<lifeless> its nearly entirely automated in the general case
<dholbach> good morning
<pitti> Good morning
<ajmitch_> morning dholbach, pitti
<pitti> kees: thank you! Merged into trunk
<pitti> slangasek: I guess it needs to be epiphany-extensions-2.26.pot then, but configure.ac should define the domain
<pitti> hey ajmitch_
<dholbach> hello everybody
<dholbach> I just tried calling mvo, to no avail... I hope he's OK still
<dholbach> shall we make this an impromptu Q&A session about Ubuntu Development and Packaging instead?
<dholbach> who's here for the session?
<ara> dholbach: wrong channel
<dholbach> narf
<dholbach> wrong channel
<dholbach> ara: thanks... not enough coffee :)
<prefrontal> how do i get my debootstrapped karmic to use both cores?
<cjwatson> lamont: thanks, the morning should be time enough
<robert_ancell> directhex: hey, pitti said you know about MOM - do you know why gnome-control-center doesn't show in it?  Is it because the debian source has a different name?
<StevenK> If the debian source package has a different name then MoM will probably ignore it
<pitti> robert_ancell: directhex is the Mono maintainer
<pitti> robert_ancell: MoM specialist is Keybuk
<pitti> robert_ancell: right, Debian's source is called control-center
<pitti> robert_ancell: if we merge, we should rename our source as well
<robert_ancell> pitti: ah, I have my IRC threads mixed up, I thought you were replying about MOM
<pitti> so that in the future it is covered by MoM
<robert_ancell> pitti: what are the implications of changing source name?
<StevenK> It has to go through NEW again
<pitti> robert_ancell: not much, it will just be stuck in NEW
<pitti> robert_ancell: but we'll just wave it through
<pitti> robert_ancell: binary package renamings are more painful
<pitti> but source basically doesn't matter
<robert_ancell> so practically I just change the debian/ file, and request and update on Launchpad?
<pitti> robert_ancell: update on launchpad?
<pitti> robert_ancell: oh, indeed; it means that bug reports should be moved from g-c-c to c-c, too
<robert_ancell> s/and/an/
<Keybuk>   $ time (udevadm trigger; udevadm settle)
<Keybuk>   real  0m0.558s
<Keybuk> wheee
<Keybuk> (of which 0.2s is just running path_id)
<Keybuk> pitti: I like the fact that the vcs-imports send mails for commits imported
<pitti> Keybuk: I guess you can subscribe to them just as any other branch?
<pitti> Keybuk: with that udev-extras import it's now so much easier to update the ubuntu package \o/
<Keybuk> pitti: right, I think I'm subscribed by default for asking for it
<Keybuk> indeed
<StevenK> Hmmm. Do I have to get a motu-sru ACK before an SRU is accepted?
<seb128> pitti: no no no, we renamed control-center to gnome-control-center for a reason, we are not renaming it back that creates a mess for all bugs, vcs, etc
<pitti> seb128: *shrug* okay
<seb128> thanks ;-)
<maxb> What was the reason, ooi?
<seb128> maxb: is that a question about g-c-c?
<maxb> yes
<seb128> having the same naming than the upstream product
<ogra> we could rename it to gnome-gauges-and-levers :)
<seb128> otherwise launchpad doesn't let you create a ubuntu bzr for example
<seb128> stupid limitation if you ask me, but now we switched to have the upstream product name and I'm not spending efforts migrating all the bugs back, watching 2 components, etc
<cjwatson> seb128: that limitation isn't one I recognise ...
<cjwatson> you do (currently) need to have a product to stash the branch in, but its name doesn't have to match the source package name
<cjwatson> (and of course we have proper source package branches now, but anyway)
<pitti> seb128: we should move them all to package branches now
<ogra> cjwatson, oh, does your recent initramfs-tools upload fix the issue you talked about yesterday ?
<seb128> cjwatson:
<seb128>  bzr push lp:~ubuntu-desktop/control-center/ubuntu
<seb128> bzr: ERROR: Invalid url supplied to transport: "lp:~ubuntu-desktop/control-center/ubuntu": No such project: control-center
<cjwatson> seb128: sure, that doesn't contradict what I just said ...
<pitti> seb128: FYI, I created mass-tag.py and subscribe-triagers.py scripts on ronne (now with launchpadlib)
<seb128> cjwatson: that's the issue we had
<seb128> pitti: excellent!
<cjwatson> seb128: my point was that, while the "control-center" bit there has to match an upstream product name in Launchpad, it doesn't have to be identical to the source package name
<pitti> seb128: lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu ?
<seb128> pitti: I was speaking about why we renamed the source one year ago
<seb128> pitti:  not sure how lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu is revelant to that
<pitti> seb128: that would be the package branch (not related to the renaming discussion)
<cjwatson> ogra: yes, but while it does now seem to more or less boot, it's *much* slower than when I tested on jaunty; I've yet to figure out why
<ogra> well, its a step forward at least :)
<tkamppeter> pitti, hi
<seb128> cjwatson: right, having the bzr matching the source name is handy though ... anyway we did that rename ago, that was perhaps not the best move but it's done now
<seb128> pitti: should be stop using ~ubuntu-desktop/source/ubuntu now then?
<seb128> pitti: can I push to lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu?
<pitti> seb128: it's not urgent, but we should eventually migrate to package branches; it's cleaner, and avoids having to register products, too
<geser> mvo: any idea what might have caused "E: Method http has died unexpectedly!"? I get this frequently from my karmic pbuilder (with an apt-cacher-ng proxy).
<pitti> seb128: yes, you can
<seb128> pitti: has that been announced somewhere?
<cjwatson> seb128,pitti: I suggest holding off on those a bit, james_w is still sorting out imports
<pitti> seb128: if we do that, we should update Vcs-Bzr: and delete the original branch
<seb128> pitti:
<seb128> $ bzr get lp:~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu
<seb128> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/ubuntu/karmic/gnome-control-center/ubuntu/".
<pitti> seb128: it was demo'ed on UDS
<pitti> hm, bzr+ssh://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ works for me
<cjwatson> specifically we haven't had final word that the importer will cope with other branches in those locations that it didn't import
<pitti> seb128: oh, "get"
<pitti> seb128: you need to push it there first
<pitti> cjwatson: I see
<cjwatson> james_w: if you're happy with people pushing to source package branches, maybe you could send a mail to ubuntu-devel-announce saying so?
<cjwatson> I do *not* think any branches should be pushed there unless they are full-tree
<tkamppeter> pitti, can you upload Poppler with my latest debdiff of bug 382379, so that I can continue to switch over CUPS?
<pitti> james_w: that would be nice; especially for the many packages which we already have in bzr, and thus we don't want people to use the auto-imported ones
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [Unknown,Confirmed] https://launchpad.net/bugs/382379
<pitti> hi tkamppeter
<seb128> pitti: ok, no hurry though, I think I will wait for an announce email saying things are ready to be used
<cjwatson> we want to shift over to a consistent model of the world
<pitti> tkamppeter: is that still a patch which needs to go to Debian's poppler first?
<pitti> seb128: okay, deal
<cjwatson> you can carry on using non-full-tree branches if you like, but please don't push them to the source package branch namespace
<cjwatson> (e.g. debian/-only branches)
<seb128> hum, full source ... I need to try again how fast bzr is for those nowadays
<pitti> cjwatson: so far I pushed apport and jockey, both of which are full-source
<pitti> and neither had an auto-import
<pitti> seb128: we could request an import of a GNOME package which we regularly work on, and use that as a playground
<pitti> (git imports FTW)
<tkamppeter> pitti, I got a lot of positive answers concerning the Poppler-based pdftops: bug 362186, bug 377011, bug 381788
<ubottu> Launchpad bug 362186 in cups "Spurious lines on print outs" [Medium,Triaged] https://launchpad.net/bugs/362186
<ubottu> Launchpad bug 377011 in ghostscript "Cannot print documents to Laserjet 4350, via network" [Medium,Fix released] https://launchpad.net/bugs/377011
<ubottu> Launchpad bug 381788 in cups "[jaunty] cups-pdf no longer embeds fonts in pdf file" [Undecided,Triaged] https://launchpad.net/bugs/381788
<seb128> pitti: yeah, I agreed on that during UDS, should I be making a list? where do we need to request those?
<cjwatson> pitti: for full-source branches, I think it makes sense to prefer something with history over the importer
<pitti> seb128: let's try it for one package for now
<cjwatson> seb128: https://launchpad.net/+code-imports/+new
<pitti> cjwatson: right (both history, and more fine-grained than uploads)
<seb128> cjwatson: thanks
<cjwatson> pitti: yes
<seb128> pitti: alright, nautilus?
<pitti> seb128: sure; it's reasonably big, so we can see how much slower it is
<seb128> pitti: doing the request now
<cjwatson> so, one thing to bear in mind here is:
<pitti> seb128: \o/
<cjwatson> do you more often merge from Debian or from upstream?
<tkamppeter> pitti, Poppler is not synced with Debian AFAIK, so if you upload it I can offer my test script on bug 310575, to check whether my Poppler fix really fixes this bug (this bug made me switching to Ghostscript originally).
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix released] https://launchpad.net/bugs/310575
<pitti> tkamppeter: right, I don't mean poppler but cups
<cjwatson> if you more often merge from Debian, you may find james_w's imports more useful than branches off git
<cjwatson> if you more often merge (or cherry-pick, I suppose) from upstream, then you'll want to be branched off the upstream git repository
<cjwatson> obviously we want to get everyone over to the latter model eventually, but the automatic package imports are not yet smart enough to link Debian package imports up with an upstream git repository
<cjwatson> or an upstream import in general
<cjwatson> that's a later phase in the plan
<Keybuk> plus the imports don't do git branches, which is pretty much a brick wall across the freeway ;)
<jpds> Keybuk: Launchpad imports? I thought they did now..
<cjwatson> https://code.launchpad.net/~ubuntu-branches lists a number of automatic package imports that exist now
<cjwatson> jpds: master only
<jpds> cjwatson: Oh, right.
<tkamppeter> For CUPS we must get the Debian maintainer to take Poppler 0.11.0 with my patch, or we need to make a Ubuntu exception in CUPS' debian/rules.
<tkamppeter> pitti: ^^^
<cjwatson> what we will have this cycle, and what was demoed at UDS, is the ability to do bzr get lp:ubuntu/karmic/blah; cd blah; bzr merge lp:debian/sid/blah
<pitti> tkamppeter: right, that was my concern
<tkamppeter> pitti, we could also use the test for the support of "pdftops -origpagesizes" which I use in my pdftops test script in debian/rules of CUPS.
<cjwatson> if the ability to cherry-pick directly from upstream git is more important to you then you may want to think a bit carefully about how this is going to work for you in the short term
<Keybuk> cjwatson: the debian ones are linked to the ubuntu ones?
<cjwatson> Keybuk: yes (or at any rate will be this cycle)
<Keybuk> how do we change where ubuntu/karmic/some-package points?
<cjwatson> (not certain whether they are *right* now)
<cjwatson> Keybuk: just push to it?
<seb128> ok, bzr is still slooooooooooooow
<Keybuk> cjwatson: it's owned by a team that only you and james_w are members of, no?
<Keybuk> quest tmp% bzr branch lp:ubuntu/karmic/module-init-tools
<Keybuk> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/karmic/module-init-tools": module-init-tools in karmic has no default branch.
<cjwatson> Keybuk: that namespace is supposed to be Magic
<pitti> seb128: even with the 1.9 format?
<pitti> Keybuk: missing the branch name
<cjwatson> you want the 1.14 format, really
<seb128> pitti: dunno what format is being used
<cjwatson> pitti: err, no
<seb128> I'm doing a "bzr get lp:gnome-control-center"
<Keybuk> pitti: "the branch name" ?
<pitti> Keybuk: s/$/ubuntu/ or something?
<tkamppeter> pitti, another thing I am thinking about is to apply my patch also to the Poppler of Jaunty and make the pdftops switchover a Jaunty SRU of the Poppler and CUPS packages, as it fixes nearly every printing problem of Jaunty.
<cjwatson> pitti: lp:ubuntu/karmic/module-init-tools is to lp:~owner/ubuntu/karmic/module-init-tools/branch-name as lp:module-init-tools is to lp:~owner/module-init-tools/branch-name
<Keybuk> pitti: james_w's demo did not have a branch name
<cjwatson> Keybuk: pitti is mistaken here
<pitti> tkamppeter: no, that's too intrusive for an SRU, I'm afraid
<pitti> cjwatson: ah, that's magic then
<Keybuk> cjwatson: if I push to lp:ubuntu/karmic-module-init-tools will the right thing happen?
<pitti> Keybuk: no
<pitti> Keybuk: for push you need the branch name, and your own branch, as far as I remember James
<cjwatson> Keybuk: it needs to have a binding set up, much like lp:module-init-tools needs to have a binding set up before you can push to it
<Keybuk> quest ubuntu% bzr push lp:ubuntu/karmic/module-init-tools
<Keybuk> bzr: ERROR: Invalid url supplied to transport: "lp:ubuntu/karmic/module-init-tools": module-init-tools in karmic has no default branch.
<Keybuk> "no"
<Keybuk> ;)
<pitti> these are import-only fornow
<tkamppeter> piiti, so better put appropriate Jaunty packages into my PPA and help everyone who complains personally? Note also that more people switch to another distro instead of complaining at us.
<Keybuk> cjwatson: where do we set up those bindings?
<pitti> tkamppeter: too bad that we didn't catch all those regressions before jaunty release :(
<cjwatson> pitti: no, they aren't
<pitti> cjwatson: hm, I asked james about them, and he said something like that in the session?
<pitti> well, maybe that was a misunderstandin then
<tkamppeter> pitti: So better forget about them and hope for better results in Karmic?
<cjwatson> I think that setting the binding may be API-only for now, and it's possible that it does require being a member of ~ubuntu-branches (but there is a bug filed about that, which may or may not be closed)
<cjwatson> http://paste.ubuntu.com/188101/ is the script I have from jml to do it
<pitti> tkamppeter: backports/ppa is certainly enough, but for an SRU of that magnitude we need a deeper discussion than 5 minutes on IRC
<pitti> tkamppeter: in particular, if this causes any other thing to regress again, it's out of scope for SRU
<Keybuk> cjwatson: which way round do the arguments go?
<pitti> tkamppeter: and since you did the switch to fix some bugs, they'd be reopened again if we switch back, no?
<cjwatson> Keybuk: you should be able to push to lp:~ubuntu-core-dev/ubuntu/karmic/module-init-tools/karmic (or similar) and then I can set up the binding for you; but I'd appreciate it if you talked to james_w as well since this is all very new
<Keybuk> cjwatson: ~ubuntu-core-dev/module-init-tools/ubuntu exists and has done for a while
<cjwatson> we are *not* recommending yet that people push to such branches in general, AFAIK
<cjwatson> Keybuk: yes, I know
<tkamppeter> pitti, WDYT about how to perform the discussion then? Schedule a meeting with the release team? Or should it go into next ubuntu-desktop meeting? IRC? Phone?
<cjwatson> so, you know, if the process seems pretty raw and unfinished it's because it is :)
<Keybuk> right
<Keybuk> but what I don't want happening is someone accidentally checking out a james_w import branch
<Keybuk> that's not the bzr branch we've been using all this time
<cjwatson> Keybuk: the plan is to deprecate branches in the upstream product namespace, in favour of the source package namespace
<cjwatson> Keybuk: so talk with james_w, please, and agree on a plan
<cjwatson> he's on holiday this week
<joaopinto> pitti, yesterday I was chatting with Riddell about packagekit  , it will be the default installer for Kubuntu
<pitti> joaopinto: hey
<pitti> joaopinto: s/will be/is in jaunty/
<pitti> tkamppeter: ubuntu-devel@ is a good start, I think
<joaopinto> ah, it is already ? despite those problems ?
<cjwatson> Keybuk: this general class of thing is certainly something we've discussed and (I believe) accounted for
<pitti> joaopinto: I raised these concerns at UDS Jaunty, but the Kubuntu team decided that it's "good enough"
<tkamppeter> pitti: Only reason for the switchover from Poppler to Ghostscript was bug 310575, so I only need to ask the reporter of that bug whether the problem still stays fixed with after the switch back.
<pitti> joaopinto: but I consider the lack of conffile handling a blocker for Ubuntu, so I don't want it to be the defautl installer for Ubuntu
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix released] https://launchpad.net/bugs/310575
<joaopinto> ok
<Keybuk> cjwatson: it'd also probably help to have some meta data along the lines of the current blacklist to say "this merge won't work"
<Keybuk> the ubuntu and debian module-init-tools packages are not related
<tkamppeter> pitti, can I post on ubuntu-devel@ unmoderated? Ore does one need to be core-dev and/or Canonical full-time for that?
<pitti> tkamppeter: you never posted to that?
<pitti> tkamppeter: someone will moderate you if not
<tkamppeter> No, I solved everything by IRC.
<tkamppeter> pitti, what is the policy of that list, can I get unmoderated posting right on the list?
<pitti> tkamppeter: no, you need to be a subscriber, as with any ubuntu list
<pitti> tkamppeter: but in general, please really think twice before doing any SRU, and even more so with such massive changes
<pitti> tkamppeter: in general it's better to document workarounds
<tkamppeter> pitti: I am probably subscribed, as I get all the spam posted to it.
<StevenK> My personal mail gets more spam than ubuntu-devel
<StevenK> I daresay we only see a small fraction that the list actually gets
<pitti> yeah, they are pretty well moderated
 * StevenK grins cheekily and actually looks the ubuntu-{telepathy,bluetooth} queues
<StevenK> bluetooth gets like nothing, and telepathy gets on average 10 or so a day :-/
<cjwatson> Keybuk: possibly; although that could easily be determined by the fact that the branches share no common revision-ids
<cjwatson> Keybuk: so it would only be needed for optimisation, not correctness
<cjwatson> tkamppeter: any member of ~ubuntu-dev (including you) is supposed to be able to post unmoderated; other people are often given unmoderated access if they repeatedly post sensible things
<tkamppeter> cjwatso, thanks.
<StevenK> cjwatson: Isn't it ubuntumembers, not ubuntu-dev?
<StevenK> (IE: @ubuntu.com)
<cjwatson> tkamppeter: I'm astonished that you get anything more than a negligible amount of spam genuinely to ubuntu-devel. Sometimes it might have "To: ubuntu-devel" in the headers, but remember that that doesn't mean that you actually received it through that list
<cjwatson> StevenK: that would be inappropriate, I think
<jerroome> hi
<cjwatson> StevenK: http://lists.ubuntu.com/ubuntu-devel says "posting moderated for people who are not Ubuntu developers"
<StevenK> Ahh, I sit corrected
<tkamppeter> cjwatson: With spam I mean general e-mails, not really unwished commercial postings.
<cjwatson> tkamppeter: please don't use that term to refer to both, then.
<cjwatson> it's horrifically confusing.
<jerroome> does anyone know why an apt-get install fails inside a startup script (runlevel 2) and it doesn't when logged in ?
<tkamppeter> sorry for inducing unneeded discussion here.
<cjwatson> jerroome: goodness me, why would apt-get install in an init script be a good idea?
<cjwatson> jerroome: there are all sorts of reasons that might fail, including needing interactivity for something
<jerroome> its a firstboot script
<cjwatson> jerroome: can't you do the package installation during the installer, rather than at first boot?
<jerroome> in order to install a pool of machine with different packages depending on the machine
<cjwatson> that's what nearly everyone else does ...
<jerroome> how can I during installation
<jerroome> I use preseed in order to install and install a few packages with d-i late_command
<jerroome> but I need specific info about the machine in order to install the right packages
<cjwatson> what sort of specific information? (also, perhaps move to #ubuntu-installer)
<jerroome> hardware information
<jerroome> specific own-made drivers
<cjwatson> you can do that during preseeding too
<cjwatson> aside from bringing up an X server and asking questions in it, there's almost nothing you can do in a firstboot script that you can't do in preseeding
<jerroome> during preseed, I'm inside a chrooted environment and I can't read on hubed usb-devices, or can I
<cjwatson> and the latter has better facilities for installing packages
<cjwatson> you're mistaken there
<jerroome> I first need to build my /dev tree to assign every device
<cjwatson> firstly, preseed/late_command actually runs *outside* the installation chroot, and you need to chroot in if you need to get at the installed system
<cjwatson> secondly, you have full access to /dev, /proc, /sys, etc.
<jerroome> ok, I will search a bit more for it
<jerroome> thank you for your advices
<cjwatson> it is possible to make this work in a firstboot script (setting everything to noninteractive, etc.) but you'll end up basically reinventing chunks of the installer, so ...
<pitti> seb128: I'll unseed ekiga from desktop, as a first step towards downsizing
<jerroome> ok, thanks to you cwatson
<seb128> pitti: thanks
<pitti> seb128: do you want to keep it in main?
<pitti> seb128: IOW, should it go to dvd, or drop at all?
<seb128> not especially
<StevenK> pitti: edubuntu-desktop also wants ekiga
<pitti> okay
<seb128> I'm not decided between easier maintainship for motu and dvd
 * pitti moves to DVD for now
 * seb128 wants archive reorganization
<lamont> Keybuk: I wonder... how well would 2.15.1~rc1-1ubuntu2 work with a hardy everything else?
<Keybuk> lamont: other than the blkid problems you mean?
<lamont> that was sort of the answer I was looking for, yes
<Keybuk> it should be ok
<Keybuk> even the blkid thing won't conflict with udev
<Keybuk> lamont: what was the util-linux issue colin was asking about?
<lamont> delivering a file called "sbin" :-p
<StevenK> Haha
<Keybuk> really, how?
<lamont> combination of lack of util-linux-udeb.dirs and install without trailing slashes
<Keybuk> oh, colin did the util-linux-udeb bit ;)
 * Keybuk cheerfully remains blameless
 * Hobbsee blames Keybuk anyway
<lamont> so we didn't create sbin, and then we successfully installed, uh, the wrong place
<lamont> Keybuk: your name on the commit .... :-p
<lamont> -rwxr-xr-x root/root     18720 2009-05-29 04:52 ./sbin
<lamont> -rwxr-xr-x root/root     18720 2009-06-04 04:14 ./sbin/blkid
<lamont> the second version is better (and newer)
<Keybuk> util-linux (2.15-1ubuntu2) karmic; urgency=low
<Keybuk>   * Add util-linux-udeb, containing blkid.
<Keybuk>   * Restore correct shlibs for libblkid1-udeb.
<Keybuk> Date: Tue, 12 May 2009 10:48:35 +0100
<Keybuk> Changed-By: Colin Watson <cjwatson@ubuntu.com>
<Keybuk> :p
<Keybuk> I think I just committed due to Colin's allergy to GIT
<lamont> and forgot --author, eh?
<Keybuk> --author?
 * Keybuk didn't know about that
<lamont> iz love
<TheMuso> SO are we moving to i586 compilation for x86?
 * StevenK is allergic to git too. Anything more than bran^Wclone, and I'm stuffed
 * pitti looks for his 4-semester git course voucher
<lamont> StevenK: one of these days, i'll learn how to have bzr let me do development with multiple branches in one directory tree (instead of tree-per-branch H9), and bzr might become useful for me
<StevenK> pitti: That was my joke :-P
<lamont> pitti: that was from before 1.5, I'm sure.  1.5 is when the UI people actually made it, um, usable.
<lamont> not perfect, mind you, just usable
<Keybuk> a punchbag to take out your frustrations on now suffices
<lamont> of course, if bzr-git won't let you branch from a git repo and push back to it, then it's b0rked
<lamont> and you get your pretty UI that way
<Keybuk> whereas before you needed effigies of the development team and katanas
<Keybuk> lamont: it does
<lamont> Keybuk: time for us to stop enabling them then, eh? :-)
<pitti> lamont: you mean usable as in "even people who defend it much can't explain you how to push a branch to a remote site"? :-(
<pitti> I RTFMed and tinkered for about an hour, and it still wouldn't work
<pitti> and merging/git apply are just plain broken/evil
<lamont> pitti: git push origin
<Keybuk> lamont: doesn't work if origin does not yet exist
<lamont> merging is _LOVE_
<Keybuk> the only way to push to a remote site is to ssh into the remote site and run clone there ;)
<pitti> the only thing I'm able to do is to push to a previously existing branch where I cloned from
<pitti> but after an hour of trying to get a branch on my server which would actually work I gave up
<pitti> Kay's recommendation after that was "oh, just do git gc; git prune, and rsync the .git tree"
<Keybuk> the thing about git's learning curve isn't that it's steep
<cjwatson> Keybuk: somewhere along the line, an added file got lost; I don't know whose fault that was
<pitti> (which still wouldn't work)
<lamont> pitti: well, one can always just go with 'rsync' :-)
<Keybuk> it's that it's a 1000ft sheer cliff
<Keybuk> and not only do you need someone at the top to help you
<pitti> lamont: see, that's what I mean :) (not that it would work)
<Keybuk> but you have to learn how to climb along the way
<cjwatson> Keybuk: could well have been that I forgot to add
<lamont> cjwatson: dropping an added file would be Keybuk's bad
<Keybuk> while meanwhile, some pesky prankster is greasing the ropes and breaking your crampons
<cjwatson> that depends on whether the 'git format-patch' output I sent actually included the added file
<cjwatson> or whether I did git format-patch rather than just a patch
<lamont> heh
<cjwatson> Keybuk: I'm not actually allergic to git, I was just lost in the util-linux branch structure
<pitti> cjwatson: format-patch should have added files (worked for me)
<cjwatson> I don't *like* it
<Keybuk> cjwatson: it is quite speial
<pitti> cjwatson: the trouble is that "git apply" doesn't bother to add them
<StevenK> cjwatson: git or util-linux in git?
<Keybuk> cjwatson: that's just lamont though, he's strange
<cjwatson> StevenK: the latter
<Keybuk> StevenK: util-linux in git
<cjwatson> pitti: doh!
<lamont> git has lots of specialness.  and no doubt that the bzr UI is much nicer
<TheMuso> How many of you now track projects that use git upstrea now? You will end up getting used to it.
<pitti> cjwatson: for me, git apply does nothing more than plain "patch"; it doesn't add files, it doens't write commit logs, it doesn't commit
<StevenK> I don't like git, I keep sliding down the cliff
<pitti> TheMuso: I have done it for some months now
<Keybuk> cjwatson: your format-patch does include util-linux-udeb.dirs
<cjwatson> TheMuso: people have been telling me that for years :-)
<Keybuk> why didn't git apply add that?
<pitti> TheMuso: I'm maintainer of hal/hal-info/udev-extras, and I can do the basic stuff; but anything off the most simple add/commit/pull freaks me out :(
<TheMuso> pitti: I know what you mean. I don't know all of git, and I don't hate it, but I don't love it either.
<directhex> git is a control station with a thousand unlabeled levers, half of which initiate self destruct
<StevenK> Haha
<cjwatson> I don't mind git too badly as long as somebody else has already set up the repository and all I need to do is push stuff to it
<directhex> cjwatson, even that freaks me out
<TheMuso> cjwatson: Yeah I know what you mean.
<directhex> and pristine-tar? brrr
<pitti> cjwatson: yeah, in that scenario I can live with it quite well, too
<directhex> there are 2 main problems
<Keybuk> cjwatson: the thing to remember with the util-linux repository is all the lines
<ion_> I donât care which VCS is picked as the standard for packaging as long as youâre able to do â$vcs get/clone/whatever URIâ and get a single working directory, within which there is a branch that tracks upstream, from which there is a single branch for each patch, from which thereâs the packaging branch. :-)
<cjwatson> pristine-tar is a really cool idea, and not just needed for git
<Keybuk> you merge from origin/master into master than into ubuntu/master, and push that, and it'll show up as lamont/master and lamont/ubuntu/master
<directhex> 1) git's commands overload (intentionally?) well-known commands from other VCSes. they do entirely different things to what you expect them to do
<Keybuk> unless of course you're merging from a stable branch
<Keybuk> in which case you then merge from origin/stable/v2.15 to stable/v2.15 and then into ubuntu/stable/v2.15 and push that so lamont will have lamont/stable/v2.15 and lamont/ubuntu/stable/v2.15
<directhex> 2) the docs are shit. they're essentially useless at defining real-world common useful scenarios, and instead drown you in twaddle
<Keybuk> of course, packaging changes should be made to both master and stable
<Keybuk> it's amazing how you can hear lamont's laugh in your head as you do this ;)
<lamont> heh
<lamont> anyway, time for me to do some work
<pitti> lamont: LOVE> certainly more of the S/M kind :)
<ion_> See how git://git.debian.org/git/perl/perl.git uses branches for example
<Keybuk> though things like the util-linux branch madness begin to persuade me that supporting easy in-tree switching between in-repo branches is not necessarily a good thing
<pitti> Keybuk: *nod* it's not just horribly confusing, it's also inefficient to constantly having to rewrite the working tree
<Keybuk> not necessarily
<Keybuk> there's a major killer reason for having that feature
<Keybuk> build your big tree
<Keybuk> make a branch
<Keybuk> commit your bug fix
<Keybuk> build, test, yup ok
<Keybuk> switch back to your development branch
<Keybuk> make now only needs to rebuild the diff
<Keybuk> in bzr, that'd be a "rebuild the entire thing *again*"
<pitti> why?
<pitti> bzr commit doesn't remove files?
<Keybuk> pitti: because a branch is a new directory
<wgrant> You can work around that with bzr
<Keybuk> if I have two bzr branches
<Keybuk> I have two directories
<Keybuk> which means two builds
<wgrant> Have a separate checkout, and use 'bzr switch' on that.
<pitti> right, but why would you build trunk/ if you are workign in mybranch/ ?
<wgrant> YOu can then have working-treeless branches.
<Keybuk> wgrant: it's not quite as nice
<wgrant> Keybuk: Sure.
<Keybuk> pitti: because mybranch is quick, and when I'm done and switch back to trunk, I don't want to have to rebuild the entire kernel again
<pitti> Keybuk: well, I'm not saying that there isn't a use case for it; I just find it confusing, and I don't want to think about this concept usually
<wgrant> Keybuk: FOr that I would normally unbind, commit commit commit, bind, up, commit.
<cjwatson> there really isn't a fundamental reason why you can't do this in bzr; I think it's just that nobody's done the UI plumbing for it
<Keybuk> cjwatson: right, bzr fundamentally supports it - there's just no UI
<cjwatson> well
<cjwatson> a branch is only a single head
<cjwatson> so you would need to remember the heads somewhere
<seb128> pitti: ok, takes 15 minutes to get gnome-control-center here, that's quite slow but I still workable
<Keybuk> even a tree on disk can have multiple heads
<Keybuk> cjwatson: bzr heads ;)
<cjwatson> I don't think a branch has any way to remember them, although they're certainly stored in the repository
 * pitti wonders if he is the only one who is a bit overwhelmed by all these different concepts of branches, heads, origins, indexes, and so on
<Keybuk> the difficulty is switching from one head to the other - that's the missing bzr command
<cjwatson> Keybuk: bzr heads looks at the repository
<wgrant> Keybuk: You can do that with
<pitti> seb128: that's a full git import?
<wgrant> Gar.
<wgrant> 'bzr pull -r somerevid'
<seb128> pitti: that's a "bzr get lp:gnome-control-center"
<Keybuk> cjwatson: right, heads go in the repository
<Keybuk> cjwatson: a repository can have multiple heads
<cjwatson> Keybuk: the missing bit is actually identifying the multiple heads
<seb128> pitti: git takes 9 minutes
<Keybuk> cjwatson: the commit log is usually a good sign
<Keybuk> cjwatson: they have revision-ids
 * Keybuk may be missing your point
<cjwatson> Keybuk: sure, I know this
<cjwatson> Keybuk: yeah, I think we're talking past each other, let me think and reword
<seb128> pitti: and svn less than 1 minute
<pitti> seb128: ah, it's an svn import
<Keybuk> cjwatson: it's quite easy in bzr to end up with multiple heads in your repo
<Keybuk> bzr heads --all will show them all
<cjwatson> yes, I *know*
<Keybuk> the bit that's missing is the command to say "right, so give me *this* head"
<pitti> seb128: it's not the most recent format, so it might be faster if it gets upgraded to 1.9
<cjwatson> Keybuk: .bzr/repository has all the revisions ever. .bzr/branch identifies a single head. 'bzr switch' lets you switch to a different head, by giving it a location; it looks up .bzr/branch in that location and uses that head.
<Keybuk> cjwatson: bzr switch only lets you work on checkouts, not full trees
<Keybuk> it's a deliberate limitation of that command
<pitti> seb128: but I guess the main reason is that the history is just so big?
<cjwatson> Keybuk: therefore the thing that is missing is not really a way to switch to a different head, but a way to *name* the head without having to have a .bzr/branch just for it
<Keybuk> cjwatson: heads can have tags
<Keybuk> but yes, I see your point ;)
<cjwatson> Keybuk: oh, well, that's just a consequence of the fact that you don't really want to disassociate the working tree from its branch if they're tightly-bound
<seb128> pitti: right, which is sort of my issue with those, I don't need 8 years of commit history to package a new version for karmic ;-)
<pitti> seb128: I thought GNOME switched to git now; surprising to still see recent commits in the svn branch
<cjwatson> if there were multiple heads stored in .bzr/branch, then that restriction wouldn't be necessary AFAICT
<Keybuk> cjwatson: looms obviously store this information in a different .bzr file
<pitti> seb128: yeah; for those, the debian/ only branches with bzr-buildpackage are quite nice
<seb128> pitti: they did switch to git, svn is read only now
<cjwatson> at the moment, running 'bzr switch' on a full tree runs the risk of horribly confusing you into losing a branch
<cjwatson> or would run that risk, if it were allowed
<pitti> seb128: for some projects, having upstream VCS is great, but I guess it doesn't apply to the majority of packages we maintain
<seb128> right
<cjwatson> seb128: almost the entire point of the branch format changes in 1.14 is to address this kind of problem
<cjwatson> so I think you will see a substantial difference there
<elmo> should I expect fairly modern intel gfx chipsets to be blacklisted?
<cjwatson> seb128: (look up "brisbane-core")
<elmo> someone here just upgraded a Dell XPS M1330 and it's 965 is blacklisted
<elmo> which is, uh, surprising to me
<Keybuk> elmo: jaunty? yes
<seb128> cjwatson: ok thanks
<elmo> Keybuk: awesome
<cjwatson> seb128: http://bazaar-vcs.org/Roadmap/BrisbaneCore
<elmo> (except not)
<Keybuk> elmo: you can unblacklist it if you like your X to hang in the morning
<pitti> elmo: bug 359392
<seb128> note that it might work fine
<pitti> elmo: there's a better solution now, but it's not yet inlinux-proposed/jaunty
<seb128> I never got a xorg freeze on my laptop i965
<pitti> elmo: getting there, though
<elmo> pitti: oh, so there is hope it may get fixed in jaunty-updates later?
<seb128> you can probably force the compiz use
<seb128> especially if you have a virtual settings
<ubottu> Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] https://launchpad.net/bugs/359392
<pitti> elmo: yes, that's the plan
<pitti> elmo: the jaunty-proposed compiz package already unblacklists i965 again
<elmo> seb128: it's someone else's laptop and they already have a technological anti-midas touch; I'm not sure I want to further enable that by risking X freezes
<elmo> pitti: awesome
<pitti> elmo: and jaunty-proposed -intel has a bandaid patch
<elmo> (really this time ;-)
<seb128> elmo: ok, makes sense
<Brent_Roth> quick new guy question: I'm a CS grad student focusing on security and am curious where I could be most useful
<cjwatson> Brent_Roth: https://wiki.ubuntu.com/SecurityTeam/GettingInvolved possibly?
<cjwatson> Brent_Roth: (also https://wiki.ubuntu.com/UbuntuDevelopment and https://wiki.ubuntu.com/ContributeToUbuntu for more general advice)
<Brent_Roth> cjwatson: thanks, I had traversed those last 2, somehow missed the first one (lack of coffee? ;-p )
<cjwatson> ... speaking of which
<Keybuk> sometimes I worry about the kernel
<Keybuk>  * This needs some heavy checking ...
<Keybuk>  * I just haven't the stomach for it. I also don't fully
<Keybuk>  * understand sessions/pgrp etc. Let somebody who does explain it.
<soren> ISTR hearing that we'll be using some new mount magic instead of aufs for Karmic. Where can I find more details about this?
<ogra> soren, currently its unionfs-fuse ... but that has speed issues
<soren> I can imagine. I just thought I heard someone speak about "--overlay" option to mount or something.
<soren> I *may* have been on crack at the time.
<ogra> soren, the plan actually is to switch to mount --union if thats inplemented in time
<soren> Aha!
<ogra> but its not there yet, so unionfs-fuse is our easiest option to have live images at all
<soren> Do we know when it's expected to land?
<Keybuk> ogra: it's been implemented
<Keybuk> just needs some testing
<ogra> oh, cool
<soren> Keybuk: Since when? 2.6.30?
<Keybuk> soren: oh, it hasn't been merged yet
<ogra> does our mount have it already ? i'm just setting up an ltsp vbox test server and could play with it
<Keybuk> the patches are on LKML
<ogra> ah
<soren> ah
<Keybuk> but that's a misnomer
<Keybuk> if we shake out the bugs, contribute patches and generally look interested
<Keybuk> it's more likely to be considered
<soren> Sure, sure.
<soren> It's just not yet something I can generally rely on being available.
<soren> Yet.
<cjwatson> is somebody actually working on getting it into our kernel?
<cjwatson> 'cos I'm well up for getting live CDs working on it about ten seconds after I have a kernel I can do that with
<Keybuk> cjwatson: andy had patches lined up
<ogra> ++
<Keybuk> but that got mixed in with the other kernel issues with -7
<Keybuk> there's one known issue with vfs union mounts atm
<Keybuk> rename()/link()
<soren> Keybuk: Any particular reason "blkid /dev/whatever" only includes the USAGE bit if also passed "-p"?
<Keybuk> soren: /
<Keybuk> soren: blkid's interface is a bit strange right now
<Keybuk> fixing it up is on the todo
<soren> So "no"? :)
<Keybuk> no particular reason, no ;)
<Keybuk> you shouldn't really use -p anyway
<Keybuk> that's for udev
<soren> Well... Since I sort of need the USAGE bit.
<Keybuk> right, so use blkid without -p
<Keybuk> blkid -o value -s USAGE /dev/whatever
<Keybuk> or does that not work?
<soren> No, that's the point.
<soren> The USAGE bit seems to nobe cached at all.
<Keybuk> heh
<soren> ..so unless I pass -p, I'm screwed.
<soren> "nobe" means "not be".
<Keybuk> and if you pass -p, you can't get the output in a useful form to you ;)
<soren> Hm?
<Keybuk> you could do eval $(blkid -o udev -p /dev/whatever) and read $ID_FS_USAGE after
<soren> Yeah, that's pretty much exactly what I'm doing now.
<Keybuk> improving blkid's api is on the todo
<Keybuk> cjwatson: ayt?
<cjwatson> Keybuk: just about to go out for lunch, but briefly
<Keybuk> cjwatson: if I have int foo[] = { 4, 8, 15, 16, 23, 42 }; in a.c, I put int foo[]; in a.h right?
 * Keybuk always manages to get this wrong ;)
<Keybuk> and C FAQ is being not-there again for me
<cjwatson> Keybuk: 'extern int foo[];', but yes, I believe that's right
<cjwatson> Keybuk: C99 6.7.5.2 has an example along those lines
<cjwatson> (if you omit 'extern', any other translation unit that includes a.h will define its own storage for foo)
 * cjwatson departs, being late
<ogra> hrm, so unionfs-fuse with ltsp doesnt work
<ogra> explodes with squashfs errors all over
<ogra> stgraber, around already ?
<stgraber> ogra: yeah
<stgraber> ogra: oh, you did some tests, good. Bad result though
<ogra> stgraber, remind me why we restart the nbd connection instead of using --persist from the beginning
<ogra> i got it working now
<ogra> but X takes ages to come up
<stgraber> because nbd is started from the initrd and for some reason it seems that whatever respawns nbd when it dies use the position from where it was started
<ogra> i would really like to know why ldm shows an edubuntu theme though
<stgraber> as we pivot_root, the old location is no longer available and so respawning it fails
<ogra> well, the restarting kills unionfs-fuse
<stgraber> killing and restarting it from the nbd itself workaround that
<ogra> though unionfs-fuse doesnt use move mounting which makes me think it should work fine without starting nbd
<jerroome> is it possible to build a package which executes a script on it's installation ?
<jerroome> if yes, how does it work ?
<stgraber> ogra: you could try by killing nbd-server on the server side and see if it reconnects
<ogra> i will
<ogra> for now it only works if i comment the nbd restarting in the initscript
<ogra> but it works at least
<ogra> apart from the wrong theme and slow X
<stgraber> wrong theme should be easy to fix, it's probably a side effect of the transition from one to multiple theme packages
<ogra> yep
<stgraber> in the end I don't plan to install all of them
<ogra> it should only select edubuntu if edubuntu-artwork (or -desktop) is installed on the server
<stgraber> it should only install the one corresponding to the current desktop on the server
<stgraber> probably using the same code as we use for the usplash theme
<ogra> they are small, and you have LDM_THEME to set them
<ogra> if someone installs kde afterwards its easier to set LDM_THEME
<stgraber> well, they are not that small no
<ogra> so i would install them all, but pick the right default
<stgraber> I had to tweak some of them to have them on the alternate CD last time
<ogra> ?? they were always on the alternate CD
<ogra> and the graphics are plain color squares
<ogra> i created them like that for a reason ;)
<stgraber> well, the gradient of Xubuntu is quite big and so is the ubuntu one
<ogra> ugh
<ogra> make it smaller then
<ogra> ldm scales the image
<ogra> there is no reason to make it bigger than 1024x768
<ogra> and with a plain gradient and pngcrush it shouldnt be more than 40-50k per pic
<stgraber> well, I deploy on 1680x1050 so I'd say there is a reason to have something bigger than 1024x768 ;)
<ogra> no
<ogra> ldm scales it
<ogra> you wont see a difference with a plain gradient
<ogra> which is the reason all themes only use a gradient
<stgraber> yeah but scalling something like the current ubuntu one from 1024x768 to 1680x1050 is really ugly
<ogra> its a gradient from light brown to dark breon
<ogra> *brown
<ogra> you wont see the difference
<stgraber> it's not
<ogra> huh ?
<stgraber> it changed in Jaunty
<ogra> to what ??
<stgraber> it's one done by the ubuntu-art team
<ogra> ugh
<ogra> thats very bad
<ogra> so you need to deply a huge pic that gets scaled down instead of a small one that gets scaled up :(
<ogra> which also means you eat a lot of client ram
<stgraber> well, other than the size (266k) it's pretty fast even on Geode thin clients with very few RAM memory
<ogra> we should change that back
<stgraber> though, currently the biggest is the xubuntu one ;)
<ogra> why is that ?
<stgraber> it's a gradient so doesn't compress well
<ogra> should be a blue gradient too ... did that change ?
<apw> dholbach, harvest ... doesn't seem to be tracking bugs as they move from one package to another ... see bug #373752 listed as linux-meta on your list
<ogra> hmm
<ubottu> Launchpad bug 373752 in linux-restricted-modules "linux-restricted-modules-generic unable to upgrade from 2.6.28.11.15 to 2.6.28.12.16" [Undecided,New] https://launchpad.net/bugs/373752
<stgraber> ogra: nope, didn't change, it just doesn't compress well
<ogra> meh
<ogra> we should make it a plain color then
<ogra> i still see the hang on logout btw
<dholbach> apw: I have to admit that harvest is a bit broken right now - I'll put some work into it this cycle to make it better to use and more maintainable
<stgraber> well, with the packages being split, I don't really care, I'd just put ldm-ubuntu-theme on the CD and the rest would stay in the archive
<apw> dholbach, no worries, just thought you'd want to know
<dholbach> thanks apw - i'll check if there's anything immediate I can fix now
<stgraber> that way we can have "prettier" backgrounds for some derivatives if someone wants to contribute some. 250k for something like the ubuntu one isn't that bad, it'd just become a problem if we have to ship 4 of them
<ogra> ok
<ogra> hmm, the ubuntu theme isnt installed at all
<stgraber> oh ?? I'll need to look at that ...
<ogra> only edubuntu and the ltsp one
 * ogra stopwatches a boot in vbox
<stgraber> hmm, that's weird, I must have broken something with that transition
 * ogra widdles thumbs
<ogra> 2min and no X yet
<stgraber> (with Jaunty it was like 20s or so)
<ogra> 4:15 and i see an idle cursor
<ogra> no ltsp theme yet
<ogra> ah, there we go
<ogra> 4:42
 * stgraber wonders how long a livecd will ake to boot ;)
<ogra> i think cjwatson tested that and said it was unbearable
<ogra> ok, trying the same thing with edubuntu theme (plain yellow wallpaper) and no lts.conf
<ogra> 2:11 with the edubuntu theme
<shtylman> for those people that were in the SSD session: http://www.linux-mag.com/cache/7345/1.html
<stgraber> ogra: I can drop ldm-themes from ldm's depends actually, right ? the ltsp theme is provided by the ldm package and I can then install the right theme in the artwork plugin.
<ogra> yep
<ogra> hmm, intresting, bg.png has 72k in the edubuntu theme and 2.6k in the ltsp theme
<ogra> still the edubuntu theme starts up 2min faster
<stgraber> do a "file" on theme just to check if that's png or jpg
<stgraber> because we had to do some ugly things so it'd enter on the alternate CD
<stgraber> ldm hardcodes the ".png" so there are some which actually are jpg but with a .png extension ...
<ogra> ah, right, edubuntu has a jpeg
<ogra> we should default to jpeg then
<stgraber> (that's one of the things I'll be able to revert now that they all have their own binary package)
<stgraber> and I want to fix ldm so it can use .jpg file
<stgraber> that way we won't need that kind of hack
<ogra> well, it already does :)
<ogra> its just a filename issue
<stgraber> gtkgreet/greeter.c:    rawpic = gdk_pixbuf_new_from_file_at_scale(ldm_theme_file("/bg.png"),
<stgraber> that's the issue ;)
<ogra> yeah
<ogra> just rip the hardcoding out there
<stgraber> we could probably get rid of the / and the file extension and have ldm_theme_file check for both png and jpg
<ogra> the / should move into ldm_theme_file
<ogra> i always wondered why ryan didnt add it there
<stgraber> ogra: http://paste.ubuntu.com/188255/
<ogra> can you make the addition of / a single line instead ?
<stgraber> not sure I understand what you mean ? like putting it directly in the theme variable when it's set ?
<ogra> instead of adding / to each line have a final line that prepends /
<ogra> and only one return
<stgraber> well, I need the / in the tests too, having it at the end of the function won't work
<ogra> right, put the prepneding code at the top
<stgraber> yeah but prepend to what ? it looks like replacing that / by a variable containing it ... not sure what's the gain there
<ogra> stgraber, http://paste.ubuntu.com/188262/ something similar to that
<stgraber> yeah, I actually just did something similar to that ;)
<ogra> better readability at least
<stgraber> http://paste.ubuntu.com/188265/
<ogra> yeah :)
<ogra> stgraber, btw, i havent had a sigle successfull logout yet
<ogra> oh, i take that back ... this one worked ... so one out of ten
<ogra> and it seems parsing lts.conf adds 2min to the boot, might not be the theme actually
<ogra> i just copied the edubuntu theme to the ltsp dir and had the same 4min boot
<robbiew> cjwatson: ping
<ogra> stgraber, http://paste.ubuntu.com/188284/ has the (very hackish) unionfs-fuse code
<ogra> stgraber, note that you need to drop configure_nbd from the initscript for now ... but at least that gets us booting (even though slow) clients for alpha2
<ogra> stgraber, oh, and ltsp-client needs a dep on unionfs-fuse indeed
<stgraber> ogra: thanks, I'll have to work on that for a bit as I'm backporting everything to jaunty and possibly karmic so I'll need to make that a bit conditional
<ogra> yeah, hackish as i said
<ogra> i just used it for testing the concept
<cjwatson> robbiew: hi
<robbiew> cjwatson: rickspencer3 is asking who should own bluetooth...I'm leaning towards desktop or mobile...but could be persuaded to take it (maybe)
<robbiew> any thoughts?
<cjwatson> robbiew: would be helpful to know who actually knows anything about it right now. It's had various owners (for some values of ...) in the past but I can't think of a current expert on the team
<robbiew> cjwatson:  https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bluetooth-stack
<robbiew> is in question
<ogra> the prob is that its split into three bits
<robbiew> yeah
<ogra> you have kernel/infarstructure/GUI parts
<ogra> *infra
<robbiew> superm1: any experience with bluez?
 * seb128 has no clue about bluetooth, no bluetooth devices and is not interested to work on that
<seb128> in case that's revelant to this discussion ;-)
<robbiew> seb128: thanks...lol
 * ogra sends seb128 some BT devices
<superm1> robbiew, yeah i've worked on a few areas around the stack
<superm1> robbiew, particularly killswitch and hid/hci switching
<seb128> I know it's not easy to find people to look at the bluetooth bugs in the desktop team but I guess we could learn about it if required
<robbiew> superm1: we're trying to find a home for it:  https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-bluetooth-stack
<robbiew> and I don't mind making it a foundations thing...but currently you are the only person with any sort of skill in it
 * robbiew realizes superm1 has a "day" job ;)
<superm1> robbiew, i seem to feel that a majority of it's deficiencies do end up being desktop bugs with the interface
<ogra> we have another community guy, i forgot his name but he was working quite a lot on it as well, persia might remember
<superm1> robbiew, :)
<superm1> and switching to gnome-bluetooth as the GUI tool is probably the first step in the right direction
<ogra> was it Celtiore ?
<robbiew> superm1: perhaps we agree to own the infrastructure part, but desktop owns the GUI stuff
<robbiew> seb128: ^?
<superm1> that sounds sane to me
<seb128> sounds a fair deal to me
<persia> crevette : Baptiste Mille-Mattias
<ogra> ah
<ogra> robbiew, ^^^
<seb128> crevette hangs on #ubuntu-desktop and tend to do some updates
<superm1> i especially feel that it's more of a desktop problem because bluez exports all of it's methods over dbus and is successfully used well in android and naemo
<seb128> he's not really a hacker though and not a bluetooth expert either
<ogra> yeah
<robbiew> rickspencer3: ^^^^^^^^^^^^^^^
<ogra> but he is keen to put time into BT
<persia> And he spends a fair bit of time attempting to triage BT bugs.
<rickspencer3> robbiew: is dbus not pat of foundations for karmic?
<seb128> right, he's a GNOME bug triager for some years
 * rickspencer3 cough cough
<superm1> well the frontend desktop tools talk to the backend daemon (bluetoothd) over dbus
<robbiew> rickspencer3: yes...we're saying that BT needs to be split
<rickspencer3> robbiew: ok
<seb128> ok, so clearly 99% of what standard users use are graphical part and some guy try to use graphical interface = desktop land to assign all the work on us ;-)
<rickspencer3> who would be the right person to define the split?
<robbiew> foundations takes the infrastructure stuff...desktop takes the GUI
<robbiew> rickspencer3: superm1
<rickspencer3> to be clear though, I don't expect the desktop team to have much bandwidth in this area
<robbiew> understand
<rickspencer3> I would expect to track upstream UI with a best effort to triage bugs and file them upstream
<seb128> that's what I was going to say, I agree it's desktopish but we don't cover our components already
<seb128> I don't think we will be able to take over new ones
<seb128> I can make sure we have gnome-bluetooth update though
<rickspencer3> seb128: I think BT has kind of not had a clear home, so at least this is a start
<seb128> and get it added to desktop bugsquad list
<rickspencer3> seb128: great
<superm1> well after switching from bluez-gnome to gnome-bluetooth, hadess is the one leading gnome-bluetooth, and has a tracker on the gnome bugzilla and what not
<rickspencer3> seb128: could you update the desktop blueprint to that effect
<seb128> I think we need somebody with a clue about bluetooth to look at issue though
<superm1> so bugs should be much more upstreamable and better to track
<seb128> rickspencer3: I can do that
<rickspencer3> thanks seb128
<robbiew> I believe superm1 has a "clue"
<rickspencer3> robbiew: will you guys have a blueprint for the foundations side?
<rickspencer3> or should we share a blueprint?
<robbiew> rickspencer3: just share it...i'll subscribe
<rickspencer3> k
<rickspencer3> thanks all: robbiew, seb128, superm1
<superm1> i've got a clue on a few pieces in the stack, but not everything
<robbiew> superm1: at this point..we'll take what we can get :P
<superm1> from the foundations side, someone needs to get upstream to open up a bug tracker that bugs can be upstreamed from too. last i remember looking, it was closed and marcel didn't want distro bugs being sent up to it
<robbiew> superm1: that's just great :/
<cjwatson> was that just in the sense that he wanted them to be reproduced against clean upstream code first?
<superm1> I'm not sure. jorge was looking some time back
<superm1> if that's all it was, setting up more frequent builds to PPAs isn't too difficult, especially since they do releases so frequently
<cjwatson> if it's in public revision control, we could do that by way of the daily upstream builds stuff
<cjwatson> bzr-builder et al
<superm1> yeah they keep it all in git on git.kernel.org
<cjwatson> james_w,al-maisan: ^-
<robbiew> cjwatson: good idea
<robbiew> man....pidgin is sucking up my CPU lately
<dholbach> Packaging Training with mvo in #ubuntu-classroom now!
<superm1> robbiew, yeah so this is upstream's "tracker": http://wiki.bluez.org/report/1 they haven't been using it at /all/ since last spring
<robbiew> superm1: hmm...okay, thnx
<ogra> bryce, playing youtube videos fullscreen with the new intel driver crashes my X server, do you have a bug about that already ?
<bryce> ogra: could be bug #383129 which is being widely reported, and which I'm about to upload a fix for
<ubottu> Launchpad bug 383129 in xserver-xorg-video-intel "x server dies with a SIGSEGV when gnome screen saver blanks the display" [Undecided,Confirmed] https://launchpad.net/bugs/383129
<cjwatson> *blink* why does the archive want to promote make to priority: important?
<ogra> bryce, i'll test if it goes away with the fix, though i dont see any libglx in my log
<bryce> ogra: ...fix uploaded.  Once it's built, give it a test again, and let me know if the problem still occurs (and file a bug)
 * al-maisan takes a look at git.kernel.org
<cjwatson> perl recommends: make for cpan. wow. I guess that actually sort of makes sense.
<slangasek> pitti: ok - so if dropping the patch works to get us an epiphany-extensions-2.26.pot, then in theory this can be a sync?
<pitti> slangasek: the patch was necessary because of http://bugzilla.gnome.org/show_bug.cgi?id=556153
<ubottu> Gnome bug 556153 in Build Infrastructure "intltool-update -p builds ill-named PO template" [Normal,Unconfirmed]
<pitti> slangasek: I don't see that fixed in the upstream source yet, but maybe something else fixed it
<pitti> slangasek: so if it builds a correct pot file, we can sync
<slangasek> pitti: hmm, why has the retracer just gone and marked bug #282844 invalid?
<ubottu> Bug 282844 on http://launchpad.net/bugs/282844 is private
<seb128> slangasek: for the reason explained in the comment
<slangasek> it's claiming it's an invalid bug because it didn't get around to retracing it for 6 months?
<slangasek> and the dependency libs have moved?
<seb128> yes
<seb128> it has been decided to close crash bugs where the retracing is useless
<seb128> we don't manage to keep up with those which are correctly retraced already and the retracing failed ones are mostly noise
<slangasek> hmm - I guess that's fair, if this was a real problem I would have a newer crash report with fresh libs
<seb128> right, that's the other thing, the user can update and send a new bug if that's still an issue
<seb128> working on outdated version is suboptimal
<pitti> slangasek, seb128: this morning I went through all the ancient failures
 * slangasek nods
<pitti> slangasek, seb128: and just retagged them for retracing; I fully expect most of them to be horribly out of date
<pitti> but maybe some are still good
<pitti> bdmurray gave me a list of all bugs which are just accessible for the apport user
<bdmurray> Maybe we should chart out the retracer's workflow
<bdmurray> Since it is getting rather involved / complicated
<bdmurray> pitti or mvo: any idea what's wrong with varlogdistupgrade file in bug 376390?  I've seen many 40 byte dist upgrade files like that.
<ubottu> Launchpad bug 376390 in linux "package linux-image-2.6.28-11-server 2.6.28-11.42 failed to install/upgrade: (dup-of: 269539)" [Undecided,New] https://launchpad.net/bugs/376390
<ubottu> Launchpad bug 269539 in ucf "package linux-image-2.6.27-3-generic failed to install/upgrade: "Conflicts found! Please edit `/var/run/grub/menu.lst' and sort them out manually."" [Undecided,Confirmed] https://launchpad.net/bugs/269539
<kirkland> jbernard: you here too?
<slangasek> pitti: intltool-update now DTRT on epiphany-extensions, so perhaps the upstream bug can be closed
<wip> update on the rt-kernel release date?
<slangasek> pitti: it looks like this was fixed by defining EPIPHANY_API_VERSION directly instead of referencing the m4 macros
<pitti> slangasek: ah, nice; thanks for checking
<pitti> slangasek: I closed the upstream bug
<slangasek> cheers
<Notch-1> hi all
<Notch-1> news about CONFIG_BLK_DEV_LOOP ?
<cody-somerville> gwibber is spammy.
<al-maisan> consider turning it off :)
<cody-somerville> I am
<cody-somerville> I'm just wondering how gwibber can be useful for people with hundreds of friends like me :P
<al-maisan> get rid of some of your friends ;)
<lajjr> hello pitti
<pitti> hi lajjr
<lajjr> I will work on the new bugs for apport that is what you meant in the e-mail right?
<pitti> lajjr: if you want, that would be nice
<pitti> lajjr: did you do some bug triage before?
<lajjr> great we are on the same page..
<pitti> lajjr: (i. e. check if the bug is complete, find reproducer, ask for more info, etc.)
<lajjr> yes some on inkscape and ubuntu...
<cody-somerville> holy crap
<lajjr> I will have to do alot more to make a good dent.
<cody-somerville> gwibber takes up 106mb of ram
<Notch-1> where the ubuntu kernel people will answer questions? how can i talk with them?
<cody-somerville> Notch-1, #ubuntu-kernel
<Notch-1> cody-somerville: they do not answer in there, i'm asking since 2 week, only silence in there...
<cody-somerville> Notch-1, What is your question?
<Notch-1> i have a huge problem with the new kernel configuration
<cody-somerville> Notch-1, well, thats not a question. Maybe thats why they haven't responded.
<Notch-1> CONFIG_BLK_DEV_LOOP=y is a big problem for enyone that uses loop-aes
<Notch-1> cody-somerville: you are very funny, but i have a real deal right here, i assure you i asked properly, but still no answer
<Notch-1> look here: https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902 and here http://archives.free.net.ph/message/20090524.121638.72482e0d.en.html
<ubottu> Ubuntu bug 342902 in loop-aes-source "Build error: âstruct bioâ has no member named âbi_hw_front_sizeâ" [Undecided,New]
<Notch-1> there are a lot of people with the same problem, but nobody taking care of it
<lajjr> I will do more pitti and thank you again.
<Notch-1> so my question is "why CONFIG_BLK_DEV_LOOP=y? and most of all: can you please get back to CONFIG_BLK_DEV_LOOP=m ?"
 * lajjr waves bye I have to get to it.
<cody-somerville> Notch-1, my suggestion would be to send a patch to the kernel-team's mailing list
<Notch-1> cody-somerville: they are not answering on the mailing list, is the second link i posted
<jbernard> kirkland: yep!
<cody-somerville> Notch-1, how long has it been since you sent your first e-mail?
<Notch-1> cody-somerville: and there is not so much to change, just m to y :D
<Notch-1> cody-somerville: 11 days on the mailing list, and 3 month on launchpad
<cody-somerville> Notch-1, Folks have been busy with UDS and what not over the last few weeks
<cody-somerville> Notch-1, I'm sure they'll reply to your mailing list post once folks get caught up with their e-mail
<cody-somerville> Anyhow, I have to run. Best of luck! :)
<amitk> Notch-1: I did ask a question on the kernel team ML regarding this.
<Notch-1> cody-somerville: i know, but still... no answer on the channel, nor in 3 month on launchpad... i think that's odd...
<Notch-1> amitk: well done, can you give me the url? i'll add it to the bug report...
<jbernard> kirkland: so how will upstart use inotify? and from that, how can we integrate update-motd? i assume we won't need an init script, we can just register with upstart? can you explain how this works?
<amitk> Notch-1: are you Alessandro?
<Notch-1> amitk: no, i am notch-1 :D i only posted on launchpad, on the mailing list i found other messages so it was useless to post a new one... oh, i see you, i already posted this link on launchpad
<Notch-1> amitk: anyway i don't know why this module is not in upstream, it works very fine for us all, i think they just don't want it
<amitk> Notch-1: Please ask the people on the bug who know about the history of the module to reply to this query. It is very easy for a module to go upstream into drivers/staging these days.
<Notch-1> amitk: and jari ruusu (the creator) is a very valid coder, but they don't like him :D
<amitk> Notch-1: we are not saying we won't do it. We just want a good reason why this module is still not upstream. That's all.
<Notch-1> amitk: i'm not talking about you, i just remember some conversation with strange peoples that do not like loop-aes and his creator
<Notch-1> i think that's the reason...
<amitk> Notch-1: ok :) Just reply to that query in the mailing list with a link to that discussion about loop-aes
 * amitk is out of here now
<Notch-1> amitk: thank you
<kirkland> jbernard: it's still being designed/implemented by Keybuk
<kirkland> Keybuk: around?  have a minute to discuss upstart inotify daemon?
<Keybuk> kirkland: sure
<kirkland> jbernard: from what I heard from Keybuk, basically we'll create an upstart config file that denotes a directory to watch (/var/run/update-motd perhaps), and an action to take when something in that dir changes (update-motd --force, perhaps)
<kirkland> jbernard: so we'll just need to make update-motd depend on upstart >= X where X is the version that implements this
<kirkland> jbernard: and the update-motd packaging will install that config file to be read by upstart
<kirkland> Keybuk: is that mostly accurate?
<Keybuk> yes
<Keybuk> why --force?
<kirkland> Keybuk: "perhaps"
<Keybuk> you'll probably have something like /etc/init/update-motd.conf
<Keybuk>     while $fhs_writable
<kirkland> Keybuk: right
<Keybuk>     watch /var/run/update-motd
<Keybuk>     exec /usr/sbin/update-motd
<Keybuk> --
<kirkland> Keybuk: cool
<Keybuk> /usr/sbin/update-motd will get run every time a file is added to/changed in/deleted from /var/run/update-motd
<Keybuk> you're responsible for your own locking
<kirkland> Keybuk: no problem, we have our own locking
<Notch-1> amitk: so you are kernel engineer, and you can't tell me why CONFIG_BLK_DEV_LOOP is now y?? and you can't also tell me why you can't get back to m ?!?
<Keybuk> Notch-1: because we often have no facility to auto-load the loop module when required
<Keybuk> Notch-1: and it's not exactly something you'd ever *not* want loaded
<Keybuk> that module doesn't contain a driver
<Keybuk> so it's not as if we'll ever need to backport a newer version
<Keybuk> or blacklist it for hardware issues
<Keybuk> it's just a kernel feature
<Keybuk> and it makes little sense to have kernel features *not* =y
<kirkland> Keybuk: /usr/sbin/update-motd:41:       # If /var/run/motd.new exists, another instance is running
<Notch-1> Keybuk: yes but there is another module, loop-aes that needs to replace the loop module, so with CONFIG_BLK_DEV_LOOP=y we need to recompile the whole kernel every update
<Notch-1> there are serveral people stucked on intrepid for this little change
<Notch-1> Keybuk: also the loop-aes-source package description is now wrong, cause it still says that we can install it with module-assistant, but right now it's impossibile (for this new kernel configuration)
<RicardoPerez> pitti: hi! I would like to ask you a question about a translation typo in netbook-launcher. There's a very big translation typo in Spanish language, but this app is in universe, so the translations aren't in any langpack and the typo could be here until a (possible) SRU for netbook-launcher. This is bug #358641.
<ubottu> Launchpad bug 358641 in netbook-launcher "Incorrect Translation in Spanish Network (ENG)->Red (SPA) Â¿?-> Rojo (red colour)" [Undecided,Fix committed] https://launchpad.net/bugs/358641
<RicardoPerez> pitti: the question is: can an SRU be done for netbook-launcher in order to get the latest updated translations and correct the typo?
<Notch-1> Keybuk: and amitk please don't make me ask for another month as always, answer me now, i'm tired
<mterry> vorian: ping, the kio-gopher debian maintainer asked you to pop into #debian-kde on OFTC
<vorian> meh, oftc
<mterry> vorian: :)
<elmo> Notch-1: I suspect you might get answers quicker if you tried being a little less demanding
<elmo> Notch-1: just a thought
<Notch-1> elmo: we are asking since 3 month, on 5 channels and launchpad and the kernel mailing list, and i got real answers only now that i spotted who is in the kernel team, asking directly by name... they just don't answer...
<Notch-1> elmo: i'm afraid that for the next answer i have to knok to them doors, that's why i insisted...
<jbernard> kirkland, Keybuk: awesome, that makes update-motd's job much easier
<jbernard> Keybuk: do you have a public branch where you're doing development, perhaps I can help?
<Keybuk> jbernard: nothing yet
<Keybuk> still working on the internals
<Keybuk> the inotify watch on top is the easy bit ;)
<jbernard> you're targeting karmic for the new upstart?
<Keybuk> yes, hopefully
<jbernard> awesome, any idea when you expect to have enough of the structure laid out that I can start integrating?
<Keybuk> by feature freeze ;)
<jbernard> perfect ;)
<cjwatson> you know, when testing the desktop CD to make sure my unionfs-fuse changes worked, it would have helped to give it enough memory, wouldn't it?
<cjwatson> like, not kvm's default of 128MB ...
<cjwatson> so yeah, desktop CD now boots fine
<yellabs> hi there
<yellabs> any one from canonical around?
<yellabs> when i go to the server webpage and click on download server edition i get the webpage of the desktop edition instead
<yellabs> http://www.ubuntu.com/products/whatisubuntu/serveredition
<yellabs> check it out,
<yellabs> click and see : http://www.ubuntu.com/getubuntu/download
<yellabs> will get you to http://www.ubuntu.com/getubuntu/download
<yellabs> wich is, yes strange enough , the desktop version
<ajmitch> that page has a tab saying server edition on it
<yellabs> then after looking around you use the tab on the left to really get the server edition
<yellabs> http://www.ubuntu.com/getubuntu/download-server
<yellabs> wich would be the correct url link in the first place..
<yellabs> dont you agree?
<yellabs> small issue thats true...
<ajmitch> you could file a bug against ubuntu-website on launchpad
<yellabs> yeah ok
<ajmitch> mostly because there's probably noone here responsible for the website
<yellabs> i was stupid enough not to notice, untill i ran the installer on the server...:P
<highvoltage> hey ajmitch! haven't seen you in a while!
<ajmitch> hey highvoltage
<yellabs> wasted two hour download and burn,... my own mistake afcuase should have been more carefull..
<yellabs> any how..started off on the right foot again...
<yellabs> all will be wel in a few hours again, thanks for your tolarence of my private rant...
<yellabs> :)
<ajmitch> highvoltage: what have you been up to lately?
<highvoltage> ajmitch: well, I don't know if you've been following, but impi was bought over by a big corporate who wouldn't let me do things like go to UDS's
<highvoltage> ajmitch: so I left later last year and started my own thing. freedom has been good so far :)
<ajmitch> yeah, so I heard from a former impi person in the NZ loco channel :)
<ajmitch> funny where you run across such people
<highvoltage> heh
<directhex> you can take our conferences, but you can never! take! our Freedom!!!
<ajmitch> directhex: but I thought you were leading the conspiracy to steal Freedom
<highvoltage> I heard that directhex secretly wants an iphone
<directhex> highvoltage, i wouldn't even touch one until i can do the first-run config without iTunes
<highvoltage> :)
<yellabs> ok off to install the server, bye bye
<directhex> highvoltage, android is a little more interesting, but only if it's any good. a Free platform doesn't guarantee awesomeness - merely makes it more achievable
<yellabs> have an nice night ( capre noctum )
<yellabs> carpe
<yellabs> ..
<highvoltage> directhex: *nod*
<calc> er is it safe for mktemp to be removed? or is karmic currently in a broken state?
<calc> seems that coreutils replaced it... except that mktemp was essential and coreutils isn't
<tkamppeter> calc, I also got such build failures on Poppler, seems that Karmic on the build servers is currently completely broken.
<calc> oh hmm no coreutils is essential also, so why does this show up
<calc> tkamppeter: ah
<calc> tkamppeter: yea removing an essential package requires the user to type a sentence stating they know they are breaking their system, heh
<calc> You are about to do something potentially harmful.
<calc> To continue type in the phrase 'Yes, do as I say!' ?] Yes, do as I say!
<calc> hehe
<maxb> aptitude has an even more emphatic sentence to type
<maxb> "Yes, I am aware this is a very bad idea"
<calc> heh
<arand> What is the reason for the xserver-xorg-video-intel 2:2.6.3-0ubuntu9.2 not having made it into recommended updates yet?
<chrisccoulson> arand - it's in jaunty-proposed - that's why
<calc> chrisccoulson: i think that might be his question... ;-)
<calc> chrisccoulson: as to why its in -proposed instead of -updates by now
<chrisccoulson> ah, ok, i misunderstood. thanks;)
<calc> otherwise he probably wouldn't know the version number of the package, heh
<cjwatson> arand: nobody's marked the bugs it fixed as verified yet
<cjwatson> (bug 371544, bug 370777)
<ubottu> Launchpad bug 371544 in xserver-xorg-video-intel "xserver-xorg-video-intel doesn't respect screen virtual resolution in xorg.conf (dup-of: 370777)" [Undecided,Fix released] https://launchpad.net/bugs/371544
<ubottu> Launchpad bug 370777 in xserver-xorg-video-intel "121_i965_default_virtual_to_2048_2048.patch overrides xorg.conf virtual setting instead of setting default (regression in 2.6.3-0ubuntu9.1)" [Undecided,Fix released] https://launchpad.net/bugs/370777
<cjwatson> bdmurray: 370777 has a couple of confirmations - should it be verification-done now?
<arand> cjwatson: I've helped several people install it and so far it seems to have worked for everyone... I was presuming the reason was that the patch was hacksish or something?
<cjwatson> arand: it *looks* like just lack of paperwork actually, should be possible to sort it out soonish
<chrisccoulson> it seems bug 371544 and 370777 were regressions caused by 2:2.6.3-0ubuntu9.1 in jaunty-proposed, and those are both fixed now. the bug that this version was originally meant to fix is bug 359392, which doesnt seem to be verified yet
<ubottu> Launchpad bug 371544 in xserver-xorg-video-intel "xserver-xorg-video-intel doesn't respect screen virtual resolution in xorg.conf (dup-of: 370777)" [Undecided,Fix released] https://launchpad.net/bugs/371544
<ubottu> Launchpad bug 370777 in xserver-xorg-video-intel "121_i965_default_virtual_to_2048_2048.patch overrides xorg.conf virtual setting instead of setting default (regression in 2.6.3-0ubuntu9.1)" [Undecided,Fix released] https://launchpad.net/bugs/370777
<ubottu> Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] https://launchpad.net/bugs/359392
<arand> Ok, good stuff :), btw the compiz un-blacklist patch would need to get through as well I think.
<cjwatson> chrisccoulson: hmm, http://people.ubuntu.com/~ubuntu-archive/pending-sru.html doesn't list that
<chrisccoulson> hmmmmm, how is that list generated? the bug report has a verification-needed tag
<bdmurray> cjwatson: yes the tag could change to verification-done in that bug
<cjwatson> some crazy script of pitti's
<sbeattie> it looks at the changelog for lp numbers; if the updated package didn't get generated against the original version, the bug gets overlooked by the script.
<cjwatson> oh, YM it looks at the .changes?
<cjwatson> no, that doesn't make sense
<cjwatson> oh, I suppose it does because it's scraping LP and LP has the .changes
<sbeattie> yes, e.g. here it looks at https://launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-intel/2:2.6.3-0ubuntu9.2
<cjwatson> yeah, I was just getting there :)
<cjwatson> maybe it ought to explicitly look for all the versions in between
<cjwatson> it'd have to walk the publishing history or something
 * cjwatson sticks an SEP field around it
<cjwatson> I might try to rewrite it with launchpadlib one of these days
<sbeattie> cjwatson: I looked at one point; unless things have changed I don't think the actual changelog entry is pullable from the api, but getting which versions were published to proposed is doable.
<bdmurray> I've a karmic update failing due to mktemp being marked for removal
<bdmurray> sbeattie: I just saw changes_file_url
<bdmurray> but haven't tested it
<cjwatson> right, I was about to say changes_file_url should be fine
<bdmurray> It'd be neat to know what was new in the API
<cjwatson> >>> launchpad.distributions['ubuntu'].main_archive.getPublishedSources(distro_series=launchpad.distributions['ubuntu'].getSeries(name_or_version='jaunty'), pocket='Proposed', source_name='xserver-xorg-video-intel')[0].changes_file_url
<cjwatson> 'https://edge.launchpad.net/ubuntu/+archive/primary/+files/xserver-xorg-video-intel_2.6.3-0ubuntu9.2_source.changes'
<cjwatson> (not that I'd actually write it like that, was just trying to cram it into one line
<cjwatson> )
<cjwatson> and that URL seems to have sensible contents
<seb128> are buildds known to be broken?
<cjwatson> what's up?
<seb128> http://launchpadlibrarian.net/27504925/buildlog_ubuntu-karmic-i386.poppler_0.11.0-0ubuntu3_CHROOTWAIT.txt.gz
<cjwatson> yum, that mktemp thing
<cjwatson> it's not buildd-specific
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531846
<ubottu> Debian bug 531846 in coreutils "coreutils: Upgrading to 7.4-1 makes apt-get ask for 'Yes, do as I say!' because of mktemp" [Important,Open]
<seb128> cjwatson: thanks
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 22:10 UTC to update document storage capacity | Archive: Open for development | Karmic alpha 1 released! | 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/H
<kirkland> cjwatson: i was thinking of changing kvm's default from 128 to 256
<kirkland> cjwatson: i've hit similar problems recently on vm's without swap space
<kirkland> cjwatson: 128 just doesn't cut it ;-)
<kirkland> cjwatson: mind you, i use a kvm alias
<kirkland> cjwatson: but i'm suspecting that others are hitting this too
<kirkland> fwiw: alias kvm='kvm -m 256 -net nic,model=virtio -net user -smp 2'
 * ogra used a 256M vbox for the ltsp tests tohday btw ... didnt really speed it up
<slangasek> cjwatson: there have been numerous claims in bug #359392 that the -intel in jaunty-proposed doesn't fix anything; OTOH, it's impossible to extract useful information from that bug report due to all the chatter
<ubottu> Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] https://launchpad.net/bugs/359392
<cjwatson> I couldn't even load the bug
<slangasek> there are 11 follow-ups to that bug report since I went to lunch :P
<slangasek> none of them useful
<bryce> slangasek: is that the one with the patch to increase the virtual resolution?
<slangasek> bryce: that's "X freezes starting on April 3rd"
<bryce> slangasek: I think the 4k offset patch is believed to be a better solution for that problem
<bryce> however there's also a bunch of kernel fixes that have solved various freeze issues, so hard to say
<slangasek> are those kernel changes in the pipe for jaunty?
<slangasek> damn; type "X freezes" and it obligingly does
<bryce> there's a few kernel changes in the pipe, I've lost track of exactly what's going in
<slangasek> -0ubuntu2 includes crasher fixes, you said?
<bryce> yes
<slangasek> crasher, but not freeze?  or both?
<bryce> I can confirm only it fixes crashes
<bryce> the fix handles a null pointer situation
<slangasek> losing track> what do we need to do to get a handle on this?  that bug is already noisy enough that I'm very wary of flip-flopping patches in -proposed
<bryce> well, there have been half a dozen different patches that have gone into karmic that fix different freeze issues.
<slangasek> so if I'm running karmic with KMS, do I have all the bits needed to provide a useful freeze report?
<slangasek> #       Option "MigrationHeuristic" "greedy"
<slangasek> #        Option "AccelMethod" "uxa"
<slangasek> #       Option "NoAccel"
<bryce> I think part of the problem is that you introduce one of those patches, and people with one of the other 5 freezes say "it doesn't help for me" so it's hard to get a positive confirmation on them
<slangasek> hmm, that's not what I selected. :P
<slangasek> INFO: task_events/1:23731 blocked for more than 120 seconds.
<bryce> also we've seen at least a couple instances where the same reporter had at least two distinct freezes, and it took two different patches to get everything resolved
<bryce> karmic with KMS, and also need the intel_gpu_dump tool from the x-freeze ppa
<slangasek> right, I think that's a lot of what's happened in that SRU bug in question.  We don't have good ways to distinguish the freezes, I guess?
<bryce> erf, I need to get that tool into the archive
<slangasek> intel_reg_dumper isn't enough?
<bryce> yes, it is usually sufficient
<slangasek> and apport xorg collection is still broken?
<bryce> if the dump for two freezes show it's stopped at the same gpu call, it's the same freeze, else have to assume it's a different freeze
<bryce> slangasek: should be fixed now; I uploaded a fix earlier today
<bryce> basically I just dropped the fglrx-loaded code; it's redundant anyway
<bryce> slangasek: oh hey btw good news - I got KMS working on -ati :-)
<slangasek> yay!
<slangasek> totally free of all freeze bugs, right? :)
<bryce> or I should say, apw got it working, I just did the testing :-)
<bryce> it's got totally more interesting bugs
<slangasek> heh
<bryce> actually, we just need to get the X side of things more up to date.  It doesn't have DRI, Xv, fast-vt-switch, etc. at the moment.  But the kernel boots KMS properly now.
<bryce> we might have the necessary bits in for alpha-2...
<slangasek> oh good; trying to install the updated xorg package has caused apt-get to hang in an uninterruptible disk wait
<bryce> ???
<slangasek> I assume KMS is to blame somehow :)
* mthaddon changed the topic of #ubuntu-devel to: Archive: Open for development | Karmic alpha 1 released! | 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> bryce: and the x-freeze-test ppa doesn't seem to be built for karmic?
<slangasek> I guess I can just use jaunty, then
<bryce> the jaunty deb should work fine
 * slangasek nods
<bryce> on my todo list to merge that into universe...  working on -ati merge first
<bryce> slangasek: regarding the freeze bugs, maybe what would help would be to just start cataloging all the freeze patches we know about into a table, indicating status for jaunty
<bryce> most of them are kernel patches, but iirc there's a few on the X side as well
<ion_> bryce: Btw, when the background image is loaded and rendered with early X during bootup, would it be a good idea to do the loading and rendering with something like nice 20 ionice -c 3 to avoid it slowing down startup?
<ion_> 19 even
<bryce> probably a bit time consuming to track down all the info, but probably more effective than dealing with those multi-hundred comment bug reports
<bryce> ion_: I don't know... test it out and see
<ion_> I will :-)
<bryce> my guess is that it won't make a difference, but I have no rationale for that guess ;-)
<slangasek> bryce: we also have people following up to that bug saying that karmic doesn't fix their problem... I guess we should point them through the freeze debugging guide?
<ion_> Loading and scaling a big JPEG *is* somewhat heavy on older computers.
<bryce> slangasek: right.  They need to file new bugs using those guidelines and NOT glom onto an existing bug report.
 * slangasek nods
<bryce> with freeze bugs we really need to insist on one bug report per person
<dtchen> not just freeze bugs - bugs with multiple causes that appear as similar symptoms
<dtchen> it's a complete PITA to have to open multiple tasks across multiple bugs when people abuse "me too"
<bryce> dtchen: totally agreed, it's just especially bad with the X freeze bugs
<bryce> users have a hard time identifying what causes their freeze, usually they say the freezes come on "randomly"
<bryce> they're not actually random, but the conditions that have to be met are pretty hard to spot as a user
<slangasek> hmm... rebooted, and now sound is gone
<slangasek> worse than last time :)
<dtchen> it'll probably get worse if you boot 2.6.30-8.9-generic
<dtchen> also, the "sound is gone" bug is often caused by PA writing to the wrong sink
<slangasek> no, it's gone even if I bypass PA.
<slangasek> this is with 2.6.30-7, which I just booted for the first time
<dtchen> corroborated by speaker-test -c2 -Dplughw:0 ?
<dtchen> gotta love the "throw a dart at the stack" bugs :/
<dtchen> TheMuso: possible regression for ALSA in 2.6.30-8.9-generic caused by commit 44ada1a147fa28ae15b83a031c48fc2b992cc3ef in linux-2.6.git
<dtchen> TheMuso: yeah, it seems to be a bogus commit that only works if CONFIG_PREEMPT is enabled. and karmic has it disabled.
<slangasek> dtchen: no sound with that command, even after switching back to the -6 kernel
<dtchen> slangasek: have you eliminated mixer settings as a possible cause?
<slangasek> dtchen: no, rather I just checked the mixer and found it muted ;)
<slangasek> the master mixer
#ubuntu-devel 2009-06-05
<milli> Is kvm known to be broken in Karmic with linux-image-2.6.30-X?
<hyperair> is mktemp going to be included in the new coreutils or something?
<hyperair> ah yes it is
<hyperair> either way all the PPA buildds are broken =(
<StevenK> So are the distro buildds
<hyperair> i can imagine.
<ghindo> That issue's been fixed upstream, right?  When are we gonna see the fix hit the repos?
<slangasek> when one of the buildd admins has a chance to manually build the fixed coreutils package
<pitti> Good morningt
<StevenK> Morning pitti
<dholbach> good morning
<pitti> slangasek: for https://answers.edge.launchpad.net/launchpad-code/+question/72999, do you still need your lp:~vorlon/hal/lp.277589 branch? If not, would you mind deleting it?
<pitti> hey dholbach
<dholbach> hiya pitti
<pitti> eww, new coreutils removes essential package mktemp
<pitti> which is most probably intended, but apt still doesn't like it
<wgrant> pitti: The fix is uploaded, but needs manual building...
<dholbach> wgrant: manual building?
<wgrant> dholbach: The buildds are broken because of this, so a buildd admin will need to manually build coreutils.
<dholbach> argh :-(
<slangasek> pitti: I guess it's been merged already, so deleting now
<pitti> slangasek: yes, it is; unfortunately branches have to be set to "merged" manually
<wgrant> pitti: Not any more they don't.
<wgrant> But I suppose the target branch wasn't the development focus.
<wgrant> So it wouldn't have set it.
<wgrant> Because it wouldn't make sense.
<wgrant> I guess package branches will fix that.
<pitti> tkamppeter_: https://bugs.freedesktop.org/show_bug.cgi?id=19777 -> good work!
<ubottu> Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,Resolved: fixed]
<pitti> tjaalton, bryce: I just filed bug 383837 against compiz, then I realized that it is most likely a regression in xorg-edgers mesa; should I still keep the bug in LP, or report it somewhere else?
<ubottu> Launchpad bug 383837 in mesa "crash on workspace change in intel_tex_validate.c:99 assertion" [Undecided,New] https://launchpad.net/bugs/383837
<pitti> cjwatson: live system> you rock! boots fine in kvm here
<pitti> . o O { gosh, my city is freaking out; and just because some American president is in town... }
<pitti> seb128: FYI, current retracer failure is due to mktemp failed dist-upgrade; let's just leave it until the archive gets fixed
<seb128> pitti: the bug has been fixed in debian I was going to do a sync now
<pitti> seb128: it's already synced, but it doesn't build
<seb128> pitti: right, just noticed, let's wait for infinity or something to sort that then
<dholbach> can doko do it too?
<seb128> dunno
<pitti> All builds fail right now due to coreutils, being worked on | Archive: Open for development | Karmic alpha 1 released! | 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
<pitti> http://wiki.ubuntu.com/HelpingWithBugs
 * Hobbsee hands pitti a /topic
* pitti changed the topic of #ubuntu-devel to: All builds fail right now due to coreutils, being worked on | Archive: Open for development | Karmic alpha 1 released! | 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
<pitti> Hobbsee: meh, thanks
<Hobbsee> :)
<wgrant> pitti: Do you want some more two-weeks-notice timezone change fun?
<cjwatson> pitti: live> yay
<cjwatson> dholbach: no, he can't
<dholbach> cjwatson: gracias
<pitti> wgrant: I just got poked about bug 383444, anything else?
<ubottu> Launchpad bug 383444 in tzdata "Timezone change for Bangladesh" [Undecided,New] https://launchpad.net/bugs/383444
<wgrant> pitti: That's the one.
<cjwatson> doing manual builds requires, basically, shutting down the buildds, constructing a faked-up chroot which will do what you want, poking that into the buildds, letting through the one package you want, and then setting the chroots back the way they were and restarting builds
<cjwatson> the actual technical privileges required are in the intersection of ubuntu-archive and launchpad-buildd-admins, but in the general case you need direct shell access to the buildds too in order to construct proper chroots
<cjwatson> in theory (e.g.) I could probably manage it, but I much prefer to leave it to Adam
<elmo> cjwatson: infinity's on holiday till Tuesday
<elmo> cjwatson: if this broken-distro rather than single-package-bootstrap, I'd better have someone else do it for you?
<pitti> elmo: right now all builds fail due to it, and Alpha-2 is due on Thursday, so it would be great if it could be fixed before Tuesday
<elmo> pitti: ok
<pitti> elmo: many thanks!
<cjwatson> elmo: oh, right - yes, please, thanks
<hile> hmmh, a question about old releases, I had /dev/scd0 in fstab from old install for cdrom - I guess this was added there by some older version of ubuntu?
<hile> I don't think I have added these myself, anyway there is a problem starting with jaunty with this
<hile> problem is that sound-juicer and some other CD applications process this line and fail to eject the cdrom, because now my /dev/cdrom symlink really points to /dev/sr0
<hile> changing the device name to sr0 fixed the problem...
<hile> so, is ubuntu supposed to fix this line during upgrades? maybe I have re-indented it or something and broken the change in upgrade if it's supposed to be done...
<cjwatson> update-manager probably ought to adjust it, but I didn't think the device name was meant to be sr0
<cjwatson> 50-udev-default.rules:SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom"
<tjaalton> pitti: upstream would probably want to know about the bug
<cjwatson> (so actually ignore my comment about update-manager, I typed that before checking the udev rules)
<tjaalton> pitti: so, bugs.fd.o
<cjwatson> I think you should investigate why /dev/scd0 is not present on your system. Have you changed udev rules?
<pitti> tjaalton: good, will forward it there then; thanks
<tjaalton> pitti: yep, thanks
<cjwatson> or is it just that applications refuse to handle it if it doesn't match the /dev/cdrom symlink? in which case perhaps it is a bug in those applications
<hile> I have scd0, but /dev/cdrom points directly to /dev/sr0
<hile> I was getting errors from gvfs regarding this, it was quite hard to track it the fstab :)
<cjwatson> I'd venture to suggest that it's an application bug if they don't like that then
<cjwatson> if it's the same device ...
<hile> basically gvfs was saying (without the device name) error 'this is not a volume'
<cjwatson> linux/Documentation/devices.txt says "The prefix /dev/sr (instead of /dev/scd) has been deprecated."
<cjwatson> so I don't think we should use it
<hile> but /dev/cdrom points to /dev/sr0 anyway
<hile> and yeah, nautilus and gnome-mount were happy to unmount /dev/cdrom, sound-juicer and brasero do not work
<n0yd> Any idea when this might be fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/350695
<ubottu> Launchpad bug 350695 in linux "Linksys WUSB100 not enabled by rt2870 driver." [Undecided,Confirmed]
<n0yd> I looked on the kernel bugzilla, couldn't find a bug there for it, so I added one.
<hile> i guess it really is application problem, just wondering how sound-juicer/brasero use gvfs differently from nautilus
<cjwatson> hile: sure, but it's all the same device (and it's probably much easier to write udev rules so that the symlinks come out that way). If I were you I'd be filing bugs on sound-juicer and brasero.
<hile> sure, I'll do that, just wanted to make sure it's not a screwup I have caused somehow myself
<cjwatson> hile: doesn't look like it, on the face of it
<n0yd> That bug I posted also han't been fixed in the karmic kernel either
<cjwatson> pitti: could you please not have https://code.launchpad.net/~ubuntu-core-dev/ubuntu/karmic/hal/ubuntu in the source package branch namespace? I pretty firmly believe that only full-tree branches should be in that namespace
<cjwatson> (and I said this yesterday and I didn't see you objecting then ...)
<cjwatson> pitti: if you give us some time, we may be able to come up with a way to glue your history into a full-tree branch; we discussed this at UDS
<pitti> cjwatson: okay, I'll move it back then
<cjwatson> thanks
<pitti> (not that it would be any more appropriate against the upstream project FWIW)
<cjwatson> no, but at least it's existing inappropriateness
<pitti> deleted
<cjwatson> once we have source package branches for everything I want it to be an invariant that we can point people at those branches and they can see all the code we ship
<cjwatson> even if those aren't the branches we actually develop against for the time being
<cjwatson> obviously it will take some shuffling to get there ...
<pitti> pushed to old location and updated Vcs-Bzr in bzr
<rcmorano> pitti: u around?
<pitti> rcmorano: hi
<rcmorano> yo :]
<rcmorano> im looking into a gdm-guest-session bug
<rcmorano> ive found that it applies a apparmor profile which disallows the guest user to execute files in /tmp/**
<rcmorano> so, for example, in my case, .desktops in Desktop/
<rcmorano> are not rendered (no icon, not trusted -> can not be executed)
<pitti> rcmorano: right
<rcmorano> well, i forgot to mention that guest user homedir is created in /tmp
<rcmorano> although i think u already know hehe
<rcmorano> so... i wanted to know if that's a security issue
<rcmorano> or just a deeper bug
<rcmorano> (guest user could not execute anything inside of his home)
<pitti> rcmorano: when I wrote the AA profile, I just included the minimum privs to get the session up and running, and use the installed programs
<pitti> running guests' own code wasn't amongst those
<rcmorano> aha
<pitti> but I guess it's easy to circumvent anyway, and guest doesn't have many privs, so I wouldn't mind adding /tmp/** x
<rcmorano> yeh, ive tried 'ix' and worked right
<rcmorano> just wanted to know if i should file a bug from the point of view of ".desktops are not rendered" or "guest user can not execute a shit"
<rcmorano> hehe
<rcmorano> if you think it's ok to allow guest user to execute things i can open a bug about this issue
<pitti> rcmorano: if you change /etc/apparmor.d/gdm-guest-session
<pitti> /tmp/** rwlkm,
<pitti> to
<pitti> /tmp/** rwlkmx,
<pitti> rcmorano: does it work then?
<pitti> rcmorano: right, please report a bug
<rcmorano> there is no 'x' flag
<rcmorano> ive tried 'ix'
<rcmorano> and 'ux' (which threw me a warning about security risks)
<rcmorano> im not very familiar to apparmor
<rcmorano> i just tried to add any +x permissions
<rcmorano> :]
<pitti> rcmorano: right, sorry; ix is fine
<rcmorano> oke :D
<pitti> ux is a no-no
<rcmorano> yeh i supposed hehe
<rcmorano> many thanks mate
<rcmorano> gonna report it :]!
<ogra> mmm, kms is noce :)
<ogra> *nice
<pitti> ogra: pure love, isn't it? :-)
<ogra> yeah, finally my gdm comes up in the right resolution on the external monitor
<rcmorano> it's so beatiful :]
<ogra> though i didnt see any change in usplash
<ogra> hmm, dropping the resolution settings from usplash.conf gets it right on shutdown, but not during boot
<ogra> i guess it first detects the internal display ...
<cjwatson> right, I was just about to try something similar
<pitti> I just disabled usplash, we can't start it in the initramfs any more anyway with KMS
<cjwatson> surely one needs to ensure that i915 is there before usplash starts - and that, I think, is sort of conditional on Keybuk's plans to move usplash out of the initramfs
<cjwatson> or at least sometimes out of the initramfs. I think we still need it in the initramfs for live CD boots
<ogra> my initramfs is still around for more than 10s
<cjwatson> well, considering that Keybuk hasn't started uploading work to slim it down yet ... :)
<ogra> there is no kernel driver for the builtin touchscreen, it always takes a while to notice
<ogra> which means udev hangs scanning for a while, i think we'll see that on other unknown devices too and should have a fallback for that case
<cjwatson> we are going to have a fallback for cases where a bigger initramfs with usplash is necessary
<cjwatson> that's already been discussed and agreed
<ogra> ah, good
<cjwatson> exactly when we do that fallback is I think less critical
<ogra> i sadly missed that session
<cjwatson> but we know that we need it for things like dm-crypt
<ogra> yeah
<ogra> hmm, /me thought Bug 365053 was fixed
<ubottu> Launchpad bug 365053 in initramfs-tools "On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is instructed not to install a bootloader" [Undecided,New] https://launchpad.net/bugs/365053
<ogra> ah, no, we only discussed the fix
<lamont> g;morning
<pitti> cjwatson: can you please revert the oo.o-l10n cdimage hack from alpha-1?
<pitti> hey lamont
<cjwatson> pitti: I already did
<cjwatson> timestamp: Mon 2009-05-18 10:36:18 +0100
<pitti> cjwatson: cheers
<pitti> Riddell: is someone working on bug 376396 by next Tuesday? (alpha-2 blocker)
<ubottu> Launchpad bug 376396 in kdebase "pulls in phonon-backend-null" [High,In progress] https://launchpad.net/bugs/376396
<Riddell> pitti: yeah I'll look at it
<pitti> cool, thanks
<seb128> directhex: hi, is there anything blocking us to update the gtk# stack to 2.4?
<directhex> seb128, mono you mean? i'd been holding off on requesting an update until an ourtstanding bug in -2 is fixed which forces user acknowledgement to upgrade using aptitude
<asac> siretart: hi. how are you? what do you think about opening up scanResults member to "default" in wpasupplicant dbus config?
* cjwatson changed the topic of #ubuntu-devel to: buildds on manual while coreutils is fixed | Archive: Open for development | Karmic alpha 1 released! | 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
<seb128> directhex: ok thanks
<directhex> seb128, there's a bugfix release, 2.4.2, due from upstream on monday, so we were gonna -1 that rather than -3 2.4.0
<seb128> directhex: ok, I was just wondering if we would get the new version before alpha2 next week
<directhex> seb128, if you're happy enough with the minor upgrade issue which only affects a non-default upgrade tool, then it's fine to pull it in
<seb128> the issue is only for aptitude?
<directhex> seb128, indeed. tested with update-manager and apt-get and synaptic as fine
<seb128> ok, so we can update, unstable users should not care about such details
<directhex> seb128, aptitude's super-advanced resolver fails to work out that an old package should be removed without the user agreeing to the proposed removal
<asac> TheMuso: would like to talk a bit about bluetooth + pulse in karmic, let me know when there/back.
<siretart> asac: hey there, I'm more or less fine, but caught a cold
<siretart> asac: regarding wpasupplicant, sorry, I have to admit that I haven't looked in that package for some month, and didn't look into the dbus interface at all
<asac> siretart: yeah. the idea is to allow user apps to look at current scanResults; afaik they can do that using iwlist anyway - but iwlist is more unreliable.
<asac> example: firefox 3.5 uses iw to get scan results for its geolocation stuff
<asac> feels like wpasupplicant could help to make this better
<Riddell> pitti: who should be approver for kubuntu specs I write?
<pitti> Riddell: someone else in the Kubuntu community, like ScottK, or me, as you wish
<siretart> asac: isn't that exposed already anyways by nm-tool?
 * wgrant is glad to see the buildds in manual mode.
<cjwatson> yeah, we probably ought to have done that earlier, sorry
<cjwatson> I'll do a mass give-back once this is all done
<wgrant> No, not really - it blocks all PPA builds too...
<cjwatson> yeah, but those were failing too (at least the ones for karmic)
<wgrant> Which isn't most of them.
<cjwatson> true, I guess
<wgrant> Last time this happened, a lot of PPA users were veeery confused.
<cjwatson> though we could have taken down all the distro builders and left the PPA ones up
<wgrant> That's true.
<cjwatson> buildds have to be down while chroots are being mangled manually, though
<cjwatson> them's the rules
<wgrant> Right.
<wgrant> I guess it could be a bit bad if a PPA Karmic build gets dispatched with the hacked up chroot.
<Riddell> pitti: how do we get our specs series goal to be accepted for katmic?
<Riddell> karmic
<pitti> Riddell: I can accept them for you
<pitti> just toss me the links
<Riddell> pitti: all the ones on https://wiki.kubuntu.org/KubuntuKarmicSpecs
<pitti> Riddell: done
<mterry> Under what circumstances does a give-back just fix stuff?  I've got a FTBFS that looks like that's all it needs (builds in my chroot), but I can't figure out why it failed in first place.  The buildd couldn't find dependencies that seem like they should have been built and ready for a month beforehand.  bug 383921
<ubottu> Launchpad bug 383921 in taglib "FTBFS in Karmic because of a broken librcc-dev dependency" [Undecided,In progress] https://launchpad.net/bugs/383921
<DktrKranz> mterry: if a no-change upload would fix a FTBFS, a give-back is good.
<cjwatson> mterry: apt isn't always very detailed about its uninstallability messages
<cjwatson> mterry: it probably wasn't actually the fault of the packages listed there, but rather of one of their dependencies
<cjwatson> mterry: if they're installable in karmic right now, I'd recommend a give-back
<mterry> cjwatson: OK.  Who do I ping about that?  Or subscribe to the bug?  main-sponsors?
<james_w> https://edge.launchpad.net/ubuntu/+source/librcc/+publishinghistory
<cjwatson> mterry: hardly seems worth the sponsorship queue, I'll just do it now
<james_w> it was the ogre model
<james_w> the package has been promoted in the meantime
<cjwatson> mterry: anyone who can upload the package can give it back
<mterry> james_w: I don't get that from your link
<mterry> cjwatson: OK, thanks
<james_w> the link shows that the same version of the package has been published twice in karmic, once in universe, and then later in main
<cjwatson> it's not very clear from the link, but when you see two publishing records for the same version like that, it's because its overrides changed
<james_w> also, bug 374997
<ubottu> Launchpad bug 374997 in librcc "main inclusion report librcc/enca" [Undecided,Fix released] https://launchpad.net/bugs/374997
<mterry> james_w: I see.  I did look at that link before, but the inclusion was on May 12, and the build failed on May 28
<cjwatson> but enca was never promoted
<mterry> Ah..
<cjwatson> so, actually, those builds might well still fail ...
<cjwatson> what you need to do to reproduce this is to try the build in a chroot with only main enabled, not universe
<LaserJock> anybody know anything about libgnet ?
<mterry> cjwatson: Ah!  That makes sense
<LaserJock> it looks like gnet was in Main through Hardy and then got demoted for Intrepid
<LaserJock> cjwatson: does ubuntu-archive keep track of why things are demoted?
<cjwatson> LaserJock: no, it's basically always just because nothing depends on it any more so there's not much to keep track of
<slangasek> right, the record is kept either in the seed commit log or in the changelog of the package that stopped depending on it
<LaserJock> cjwatson: right, makes sense. So do I need a full MIR to get it back in or is a simple bug enough?
<LaserJock> or can I just upload something that deps on it
<LaserJock> the latest Debian version of gcompris depends on libgnet-dev so I wasn't sure if I should just merge and fix the FTBFS later or try to get gnet promoted first
<cjwatson> I think a simple bug's probably enough, with a note that it used to be in main
<slangasek> LaserJock: that's for the MIR team to decide anyway, so simplest is to open a bug that just says "it was in main before and we want to bring it back", then subscribe ubuntu-mir and see what they say
<cjwatson> (subscribe ~ubuntu-archive)
<cjwatson> oh, opposite viewpoints :)
<slangasek> well, we agree on "simple bug" :)
<cjwatson> subscribing ~ubuntu-mir is the conservative approach and is definitely fine
<LaserJock> ok, cool, thanks guys
<lamont> cjwatson: can we turn the world back on?
<lamont> my karmic chroot upgraded to 7.4-2 without whining
<cjwatson> yep, mine too
 * ion_ tests... yeah, works </metoo>
<ion_> Do buildds have to do such automatic upgrades that may put them into a broken state? How about aptitude safe-upgrade, with an admin running a manual full-upgrade every once in a while? Iâm sure there are reasons that wouldnât work, though.
<cjwatson> I think it's best overall for them to be current, yes
<cjwatson> instances such as this are rare
<ion_> Yeah, thatâs true
<cjwatson> and in fact the last case where we had to recover manually wouldn't have been prevented by your scheme
<ion_> A snapshotting filesystem and automatic rollback if things break? :-)
<dholbach> mvo: ^ tell ion_ about your new idea :)
<LaserJock> james_w: around?
<wgrant> Couldn't 7.4-1 have been removed, the previous version copied back in, 7.4-2 uploaded, and everything resolved pretty quickly without nasty chroot mangling?
<james_w> LaserJock: yup
<cjwatson> ion_: I'd like to keep the buildds simple :)
<cjwatson> wgrant: maybe, but we'd have to circumvent strict rules about going backwards
<ion_> A snapshotting filesystem, an automatic snapshot before each upgrade, and a *manual* rollback by admin if things break? :-P
<cjwatson> ion_: you know that the buildd filesystem is unpacked afresh from a tarball for every build, right?
<wgrant> cjwatson: And you didn't have to circumvent strict rules about changing buildds to manual, altering chroots, and manually dispatching builds (assuming that the exception wasn't already made for this sort of case)?
<cjwatson> wgrant: the rules are in different places
<robbiew> cjwatson: i figured it was too late in our cycle to jump to eglibc...since I also don't recall any decision being made
<slangasek> and anyway, that wouldn't change the fact that the resulting snapshotted buildd would have other stale packages, which is something we want to avoid
<cjwatson> wgrant: the procedure for this sort of thing is pretty well-established
<ion_> cjwatson: Ah, ok.
<wgrant> cjwatson: I guess so.
<cjwatson> robbiew: hmm, ok
<robbiew> cjwatson: i'm happy to...if we feel it's reasonably safe, though
<cjwatson> well, I do, but I know there is disagreement
<slangasek> if maintainers wouldn't upload Essential packages in a broken state, we wouldn't have to worry about broken chroots so much anyway ;)
<robbiew> cjwatson: right...and I can't recall where that thread ended up
<slangasek> robbiew: down a rathole, as usual :)
<cjwatson> stalled, I think. I do have some sympathy for the view that with doko doing other things this cycle maybe it isn't the ideal time to switch over; I would like to make sure that we have some practical way to merge bug-fixes from Debian when we need to though
<robbiew> right....and doing it now, versus a potential LTS release makes sense
<slangasek> if the switch is what it's supposed to be, I don't see any reason release-wise to consider it "too late" to switch
<robbiew> hmmm
<slangasek> since it's effectively a packaging change, not pulling in a major new upstream version of a toolchain package or anything
<cjwatson> I see it much more likely to be a PR issue than an operational one, myself
<robbiew> well...hmm
<cjwatson> a lot of people are worried about things that (on investigation) I think have been accounted for
<cjwatson> but the eglibc upstream folks aren't great at describing what they're doing
<azeem> certainly being able to remove large parts of glibc for the installer might be nice
<azeem> but yeah, the way Debian communicated it wasn't perfect, combined with a low-profile upstream
<cjwatson> azeem: I'm not even bothered about that
<cjwatson> I mean, I don't hugely object, although I shudder slightly at the idea of some of the bug reports it might generate so actually I'd sort of rather the C library weren't stripped down for the installer
<calc> pitti: does using apport-collect on a bug append a bug tag 'apport-package' or something like that to it?
<robbiew> cjwatson: slangasek: we have the release meeting coming up...should we discuss the eglibc there?  or is that just making the rat hole bigger?
<calc> pitti: i'm trying to write a script that can automatically process my bug queue :)
<azeem> I thought Ubuntu sets the toolchain one release in advance; is this about karmic or karmic+1?
<slangasek> robbiew: I think that's just going to lead to bikeshedding
<slangasek> azeem: karmic
<azeem> k
<slangasek> as I said, I dispute that this constitutes a "toolchain" change that we need to worry about the impact of :)
<azeem> it might get some media attention though - even the Debian move got much more attention than aurel32 would've dreamt about
<azeem> (or wanted)
<azeem> like Canonical vs. RedHat or something
<robbiew> slangasek: yeah...figured
<slangasek> azeem: how naive of him ;)
 * robbiew considers making "the call"...
<pitti> calc: it doesn't right now, since it can't know what the problem is all about (crash, package failure, bug report, etc.)
<calc> pitti: ah ok
 * calc has 400 bug mail to process today, yuck
<pitti> NCommander, lool, seb128: there, an armel apport retracer!
<ogra> YAY !!!!
<pitti> elmo: thanks for fixing the firewall
 * ogra hugs elmo
<pitti> processing the huuuuge (erm, "3") backlog now
<ogra> heh
 * robbiew hits elmo...again :P
<bryce> pitti: bug reports about xorg-edgers are fine in x lp; just be sure the versions used are listed in the report so it's clear
<Riddell> do we have Section: debug in karmic?
<ogra> bryce, happy to report that youtube fullscreen works again with the latest fix
<pitti> bryce: yes, I did an apport-collect for mesa again
<pitti> bryce: didn't upstream it yet (release meeting, and then I need to run), will do later/monday
<ogra> cjwatson, do you bump debian-cd alongside (tools/boot-arm) the installer ?
<cjwatson> ogra: yeah, will do that now
<ogra> thanks
<cjwatson> asac: xulrunner-1.9 seems to have grown by a megabyte from .0.8 to .0.10 - do you know why?
<slangasek> I looked at the coreutils growth when I noticed it; turns out each of the umpteen million utilities grew in size by a block :P
<cjwatson> I can probably do something about man-d
<cjwatson> b
<cjwatson> though it's well down the list
<slangasek> bah, why is openoffice.org-l10n-en-za now 8.8MB instead of 384K?
<cjwatson> I was just about to say!
<cjwatson> calc: ^-
<cjwatson> Changed: openoffice.org-l10n-en-za                            8564K
<cjwatson>          3.0.1-9ubuntu2                                        378K
<cjwatson>          3.1.0-3ubuntu2                                       8942K
<calc> ah crap, looking into that now
<calc> looks like en-za has more stuff localized now, looking to see what was in 3.0.1 now
<calc> is there an easy way to do a file size comparison for a whole deb?
<calc> er side by side file size comparison
<calc> so en-za was installed size 5488 size 387750 for jaunty and is now installed size 16080 size 9157472 for karmic, the installed size roughly doubled but the compressed size went way up
<calc> for other langs such as -de it was already huge for the compressed size, so i am not sure what was going on with it being so tiny for the en-za on jaunty
<cjwatson> calc: easy way> if you find one let me know :-)
<calc> cjwatson: heh ok
<cjwatson> calc: there aren't any extra files in there then? it's just extra translations?
<calc> cjwatson: i think so, not quite sure what happened
<cjwatson> calc: how many of the localisations are just identical to the original text?
<calc> cjwatson: it doesn't look like there are things that shouldn't be there from just looking at dpkg -L
<cjwatson> calc: we had that problem for en_US once and instituted some specialised filtering
<calc> other languages like -de were already roughly the size en-za is now for compressed size
<calc> already in jaunty i mean
<cjwatson> specifically http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/annotate/head%3A/bin/msgequal.c
<cjwatson> for 8MB, it might be worth trying to see if e.g. it could depend on en-us and symlink ...
<cjwatson> or something like that
<calc> ah i think i see what the issue is
<slangasek> in fact, the en-us stuff appears to be in -common
<calc> yea i think whatever was doing the symlinks went away
<calc> so the templates caused the file size explosion
<cjwatson> aha
<calc> it probably got dropped due to the directory name changing, i'll have to dig around in the rules and see what happened
<calc> with each new release ooo changes its basis dir name
<calc> there is a link dir that i might be able to use to link to instead which if that is problem with cause it not to recur
 * calc bbl, lumch
<calc> er lunch
<mterry> Does bug 384012 need an InclusionReport wiki page too or is it self-obvious enough?
<ubottu> Launchpad bug 384012 in gnome-python-extras "Include all binary packages in Main" [Undecided,New] https://launchpad.net/bugs/384012
<calc> cjwatson: does en-za hit the cd? i assume this is an alpha 2 blocker?
<slangasek> it does hit the CD
<calc> cjwatson: if so i can try to get it done by monday night for a2 freeze
<calc> slangasek: ok
<slangasek> it may not be an a2 blocker, but it would be nice to have this done
<calc> slangasek: i'll get it done, if you haven't seen an upload by monday ping me again
<slangasek> ok, cheers :)
 * calc will be out most of the day tomorrow, but should have time to work on it on sunday
<calc> i can turn on l10n export to rosetta finally as well (i think), upstream fixed that issue shortly after my last upload
<calc> i'll make sure to actually test it works before uploading though, heh
<calc> it takes 2hr to do a build without l10n export vs ~ 6hr with it so i normally don't do l10n export testing
<slangasek> mterry: binary packages should not generally need MIRs at all; my understanding is that the MIR review is done source-wise
<mterry> slangasek: I asked in #ubuntu-motu and superm1 indicated that it is per-binary
<slangasek> hmm
<slangasek> as an archive admin, I don't believe that's true in practice :)
<mterry> slangasek: He gave lirc as an example.  And I'm giving python-gnome2-extras as an example.  :)
<slangasek> mterry: well, *especially* in this case, it's clear to me that no MIR is needed
<slangasek> since it's simply a binary package split of stuff already in main
<mterry> Right
<mterry> Sometimes ya'll like your formality though  :)
<slangasek> so this is already on the component-mismatches report under "binary only promotions", which I routinely act on without even looking for an MIR bug
<slangasek> as for the referenced build failure, I think deskbar-applet should be updated to not rely on the transitional dummy package
<mterry> Guh!  So you have a special "binary only promotions" page and you weren't sure if inclusion was per-binary?
<mterry> slangasek: Agreed
<slangasek> mterry: "weren't sure if"?
<mterry> slangasek: Ah.  You were talking about the *review* being source-wise
<slangasek> yes
<slangasek> so if the source is in main, as an archive admin I don't look for other paperwork before resolving the binaries on components-mismatches
<mterry> Alright, I'll see about filing a debian bug about the deskbar-applet thing I guess
<mterry> slangasek: Sure.  So I won't file binary-only inclusion bugs in future, I'll just poke you if it's urgent.
<slangasek> sounds good :)
<slangasek> binaries promoted, in this case
<slangasek> so I think you can close that bug
<mterry> k
<cjwatson> mterry: poke the archive admin of the day for preference, though; http://wiki.ubuntu.com/ArchiveAdministration
<mterry> slangasek: Hmm, curiously, deskbar-applet is requesting the python-gnome2-extras-dbg package which tries to pull in the rest.  The -dbg package seems to intentionally not be split up.  So I guess there's no work to do
<slangasek> mterry: ah, ok
<cjwatson> gah, somebody NBSed libdirectfb-1.0-0-udeb without checking for reverse-dependencies
<slangasek> cjwatson: would help if the NBS reports actually showed udeb revdeps :/
<cjwatson> though ... was just about to say that
<cjwatson> I can fix that one
<mterry> cjwatson: Fascinating wiki page.  That explains why jdstrand is pushing all my syncs in today
<slangasek> yes :)
<cjwatson> slangasek: fixed
<slangasek> yay
<stani> should an application use notifications when it is still visible?
<hyperair> no.
<stani> hyperair: do you mean when it is not active? as I don't know how to implement if it is not hidden behind another window.
<hyperair> stani: there should be a way to check if the window is active =\
<hyperair> i think as long as the window is not the active window, it's fine.
<stani> the active state I can check, but now how many overlap there is from other windows
<stani> ok thanks
<hyperair> keywords: i think
<siretart>  are the buildds still on manual? it doesn't look so to me...
<slangasek> siretart: no
* siretart changed the topic of #ubuntu-devel to: Archive: Open for development | Karmic alpha 1 released! | 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
<siretart> ok :-)
<superm1> mterry, oh I didn't realize you were talking about a package with it's source already in main :)
<mterry> superm1: I was asking in the abstract, but yeah.  :)
<cjwatson> siretart: oh, thanks, sorry my fault for not updating the topic
<milli> Is kvm known to be broken in Karmic with linux-image-2.6.30-{7,8}-generic?  Just wondering if I need to dig deeper or not...  I didn't find anything in LP for karmic.
<milli> kvm works fine with 2.6.28-11-generic (this is i386 if it matters)
 * slangasek considers making update-maintainer also mangle the names of Vcs-* fields
<bryce> pitti, slangasek, rickspencer3:  I've cataloged a bunch of X freeze fixes that have been suggested, that could be looked at for sru's to jaunty:  https://wiki.ubuntu.com/X/Bugs/IntelDriver#Fixes
<bryce> some are kernel patches, some X, most need some amount of work before they can be sru'd
<rickspencer3> hmm
<rickspencer3> I think Jaunty will be around for a long time, so we should probably SRU all that are reasonable ...
<rickspencer3> but it sounds like a lot of work to prepare, test, and roll out so many patches
<slangasek> best is to do them in large batches for each package, really, since the risk of regression is much smaller than the odds of false negative reports from people hitting different freeze bugs
#ubuntu-devel 2009-06-06
<calc> gwibber seems a bit crap :-\
<calc> i try to write comments and it seems to hang and not repaint and also not actually send to my accounts :\
<cody-somerville> calc, I can't use it. I get spammed.
<calc> oh
<calc> it just plain doesn't work for me at all, must not be properlyl threaded
<calc> and i think my net connection here might be a bit flaky so it ends up nearly crashing the app
 * calc is at a coffee shop with about 50-100 other geeks at a meeting, heh
<calc> tends to take down the little dlink ap here
 * calc thinks gwibber needs to be slightly less crap before we set it up during the installer
 * calc can load the various pages in web browser but gwibber can't set status on them for some reason
<ajmitch> calc: yeah, gwibber regularly hangs for me as well
<aSt3raL> anyone work with the arm kernel?
<maxb> Anyone wise in the ways of devicekit-power here? Since gnome-power-manager migrated away from hal, it no longer detects the existence of my battery, on the Acer Aspire One
<DreadKnight> updated intel video drivers recently and blender 2.49 started acting up again....can someone restore the drivers to an older commit?
<DreadKnight> ubunty keeps shitting on intel video card users ...
<directhex> DreadKnight, i'm sure it's part of a plot to punish intel owners, paid for by secretive AMD spies
<DreadKnight> awesome >_<
<maxb> If you're running Karmic you shouldn't be surprised about occasional breakage.
<maxb> and my intel video is working fine
<slangasek> cjwatson: hmm, looks like someone NBSed out 2.6.30-6 after all?
<slangasek> cjwatson: did you say there was something needing doing besides the usual reupload this time?
<slangasek> hmm, not according to scrollback; guess I'll pick that up then
<slangasek> or, it's already done but d-i isn't built yet
<slangasek> ah, the directfb problem
<DaedalusX> hey all
<DaedalusX> does anyone know how to fix the issue with apparmor blocking dhclient-script in Jaunty?
<DaedalusX> it's uhhh... rather irritating
#ubuntu-devel 2009-06-07
<Viper550> Does Ubuntu support debian-installer's new GUI frontend?
<directhex> Viper550, you mean the gtk version of d-i?
<Viper550> yeah, that
<directhex> as i understood it last time i saw the question asked, ubuntu lacks the requisite directfb patches to gtk
<Viper550> Can't we have the nessecary patches only on the alternate install disc?
<directhex> not easily
<Viper550> what's wrong?
<directhex> okay. first instance, there need to be up-to-date patches for whichever gtk+ is in use. this may involve sinking development effort in developing those patches
<Viper550> unless we get it added to upstream
<directhex> well, yes, there is that
<directhex> when all's said and done, what's the point? d-i is a poor fit for a gui, and ubuntu has its own livecd-capable gui installer. what's the use case you're after where you want d-i rather than ubiquity, but insist on gtk?
<Viper550> My computer doesn't have enough ram for the live CD desktop
<Viper550> bbut I'm tired of that Windows-esque blue screen installer.
<directhex> you can spawn ubiquity without the desktop
<Viper550> I know, that's new right?
<directhex> it's one of the options in the isolinux menu
<directhex> i know it;s been around for a few releases in some capacity, as xubuntu for ps3 had it
<Viper550> but, it doesn't seem to like my graphics card. it detects to the ati driver, but it doesn't work
<directhex> that's a different issue
<Viper550> I always have to put it to vesa now
<bluefoxicy> odd.
<bluefoxicy> thunderbird is suddenly misbehaving a lot
<robinp> why is there no mdnsresponder package ? is there some policy against it ?
<ScottK> robinp: No.  We have http://en.wikipedia.org/wiki/Avahi_(software) which is an implementation of the protocol.
<ScottK> But since you're in #avahi, I'm going to guess you knew that already ....
<robinp> but avahi is incomplete: it doesn't support wide-area DNS publishing (yet) and mDNSResponder has the Bind Extension Daemon
<robinp> so I guess I am going to have a crack at packaging the mDNSResponder task into multiple packages
<robinp> s/task/source
<robinp> i think historically debian had a dislike of Apple Public source licensed packages and so thats why it wasn't included - but it is now apache - so I don't think there should be any problems
<d1b> robinp: but one could just use bind / dnsmasq to do the dns no ?
<robinp> no
<robinp> as I understand the Bind Extension Daemon adds support for things such as DNS Long-Lived Queries and Dynamic DNS Update Leases
<robinp> how do i get debuild to use a Makefile within a dir - rather than the one on the root of the source
<loic-m> robinp: patch the one at the root of the source? or move the file prior to MAKE in debian/rules? or possibly an option to MAKE?
<loic-m> robinp: there's probably a more standard method, but if you're not planning to upload that to the repositories, it should work
<robinp> make -C did the job
<robinp> i was trying to cd beforehand in the rules files and it just didn't behave
<robinp> can someone suggest how i can fix this break in my 'sudo pbuilder build package.dsc' http://pastebin.ubuntu.com/190205/
<directhex> robinp, by not trying to write to /usr in your package built?
<robinp> directhex: how do i go about directing it to do that ?
<directhex> robinp, presumably by patching the build system to stop trying to copy build/prod/mdnsd to /usr/sbin/mdnsd
<geser> robinp: my guess is that upstream Makefile doesn't honour DESTDIR. check if that's the case and fix it
<robinp> yeah - thats what I have been doing
<robinp> i keep having to mkdir -p $(CURDIR)/debian/mdnsresponder/etc/init.d for every darn subdir that the installer wants to create - is there a shortcut around this ?
<robinp> grr - it doesn't have DESTDIR - instead its got 15 seperate ones for each install type
<nunod> hi everyone. I've been doing almost no coding at all for the last 3 years, but i want to resume my coding practice in C/C#/PHP/GTK. since i'm an ubuntu fan, is there a project where I can help?
<directhex> nunod, do you want to work on apps, or on distro packaging?
<directhex> it sounds like the former
<nunod> apps :)
<directhex> in which case, pick an upstream you like, and get hackin'!
<directhex> i'd suggest banshee, 'cos we need more good $GENDER working on it ;)
<nunod> hmm... i'll prefer to stay away from Mono until the on-going conflict is settled ;)
<directhex> yet you want to work in c#? your call
<nunod> I can.. but I give priority to C :)
<directhex> well, pick an app
<directhex> oh, i know an app written in c... mono ;p
<nunod> :D
<robinp> does someone have a more complex example of a debian/rules file, perhaps one that includes libs and daemons and startup scripts etc?
<maxb> I suggest you ask about the specifics that you are interested in, that question is too general for a useful response
<siretart> could anyone explain this FTBFS to me? http://launchpadlibrarian.net/27618143/buildlog_ubuntu-karmic-i386.mplayer_2%3A1.0%7Erc3%2Bsvn20090426-1ubuntu1_FAILEDTOBUILD.txt.gz
<siretart> what the heck is going on there?
<siretart> dpkg-gencontrol: internal error: field Section has blank lines >video
<siretart> Error: parsed ddeb section or priority is empty
<pochu> siretart: ddeb section -> could be pkg-create-dbgsym
<siretart> pochu: yeah, but what am I doing wrong in the package?
<hyperair> siretart: it seems to think that there's a blank line.
<hyperair> siretart: is there a blank line?
 * hyperair scratches his head
<siretart> hyperair: http://git.debian.org/?p=pkg-multimedia/mplayer.git;a=blob;f=debian/control
<hyperair> siretart: could you try it in a local buildd?
<hyperair> then check debian/mplayer/DEBIAN/control
<siretart> well, the build works fine locally for me and fine on PPA builders
<hyperair> try adding pkg-create-dbgsym to the build-dep
<hyperair> or install pkg-create-dbgsym in pbuilder and run the build
<geser> siretart: the log talks about mencoder-dbgsym but the control file you mentioned doesn't have a mencoder package
<geser> is it the right control file you look at?
<siretart> geser: sorry, I pasted the link to the wrong branch. this is the correct file:
<siretart> http://git.debian.org/?p=pkg-multimedia/mplayer.git;a=blob;f=debian/control;h=12b1cfef70c810853b228d1c0574e25b3a242273;hb=karmic
<siretart> the ubuntu version of mplayer does include mencoder
<wip> guess what... we need a new kernel-rt release :)
<wip> that is on ubuntu 9.04
<geser> siretart: the problem with the mplayer build is that pkg_create_dbgsym doesn't like multi-line Depends, Suggests, etc.
<geser> siretart: filed as bug 384597, workaround is to merge the multi-line Depends, Suggest, Replaces to a singe line
<ubottu> Launchpad bug 384597 in pkg-create-dbgsym "pkg_create_dbgsym doesn't cope with multi-line Depends, Suggests, etc." [Undecided,New] https://launchpad.net/bugs/384597
<siretart> geser: is that a recent change? we use that in many pkg-multimedia packages without any problems..
<geser> siretart: no, it seems to be old code (even hardy has the same code). I wonder why it worked on the other packages which came before that but not on this one.
<siretart> strange, indeed
<siretart> geser: what makes you think that multiline fields are at fault here?
<geser> from the look at the code how DEBIAN/control for -dbgsym packages is constructed, the script wants to filter out Depends and some other lines
<geser> which it succeeds it doing except on multi-line Depends and the output suggests that it isn't what it is expected to generate
<soren> Blank lines in control files are probably a bad idea.
<soren> ${misc:Depends} seems to evaluate to '', so you get a blank line.
<soren> It's not so much that you have multi-line fields, but rather that one of them is blank.
<geser> soren: the problem here is that pkg_create_dbgsym doesn't filter out multi-line Depends properly
<geser> it removes the first line (the one starting with Depends: ) but leaves the continuation lines in place
<soren> Ah, I see what you mean.
<geser> siretart: dpkg-gencontrol seems to ignore this false continuation lines but as mplayer-nogui has also a left over line from replaces you get an empty line in between after replacing ${misc:Depends} for -dbgsym package
<geser> soren: see the example in bug 384597
<ubottu> Launchpad bug 384597 in pkg-create-dbgsym "pkg_create_dbgsym doesn't cope with multi-line Depends, Suggests, etc." [Undecided,New] https://launchpad.net/bugs/384597
<soren> *nod*
<siretart> geser: oh, yeah, good catch!
<geser> looks like a small fix in the negative look-ahead assertation is what's needed to fix this. I'll wait now on pitti to confirm that it's really the right fix for it and uploads a fixed package.
#ubuntu-devel 2010-06-07
<CynthiaG> Ok
<CynthiaG> I was just getting ready for these tests now, I'll boot into the two dailies on all the computers I have access to
<slangasek> lifeless: well, the thing about that is that this particular error indicates there was a *previous* error on import; I don't know what caused the tag to fail to be set previously, or if that bug still exists.  Do you still want me to open a bug report against UDD for it?
<maco2> slangasek: i think james_w mentioned having fixed the bug that makes tags not get set on import the other day
<maco2> but that he hadn't found all the failed ones to go back and retroactively tag them
<slangasek> maco2: right, makes sense
<CynthiaG> cjwatson: results in table form  http://paste.ubuntu.com/445820/
<slangasek> nhandler: do you have a toshiba laptop that uses fnfxd?  I was trying to figure out why fnfx isn't simply in sync with Debian, and I see you last merged it
<lifeless> slangasek: I want bugs for everything that goes wrong
<slangasek> lifeless: I could just file a bug that says "http://package-import.ubuntu.com/failures/ is not empty"? :)
<lifeless> slangasek: yes, but also ones about the bits that aren't empty.
<lifeless> :)
<lifeless> ok -> into the wild
<funkyHat> How can I request that a package is rebuilt? mpd needs a rebuild for maverick
<micahg> funkyHat: open a bug w/a debdiff if you don't have upload rights
<funkyHat> micahg: there's no need for a debdiff, the package just needs to be rebuilt
<micahg> funkyHat: right, but it needs a version bump if it wasn't and FTBFS
<micahg> *an
<funkyHat> micahg: it isn't ftbfs either, it just won't start
<funkyHat> I can do that anyway though
<micahg> funkyHat: k, so file a bug w/a version bump and subscribe sponsors if you can't find someone to do it for you
<funkyHat> Ok. Thanks â¢)
<nhandler> slangasek: Nope, sorry. I don't have a toshiba laptop
<slangasek> nhandler: ok, no worries
<slangasek> I am inclined to drop the Ubuntu delta, it looks like it's meant for a bygone age
<slangasek> (before we started doing all acpi keys across input devs)
<reduz> hi guys, questio!!!n how do i report a bug in ubuntu itself and not in a package?
<reduz> well, question i meant
<CynthiaG> What would this elusive bug be? Are you sure it's in Ubuntu and not a package?
<reduz> yes it's in ubuntu, (or at lest in a core package), networking gets disabled in ubuntu after laptop suspends, if i edit /var/lib/NetworkManager/NetworkManager.state and enable it again, it works again
<CynthiaG> Then the bug is eiter in acpid or network-manager
<CynthiaG> Ask #ubuntu-bugs to tell you what they think is the best package to report under
<reduz> ok!
<RAOF> I'd probably start by filing it under network-manager (with ubuntu-bug network-manager), as that's likely to pick up the most interesting logs.
<pitti> Good morning
<CynthiaG> Hi there :)
<dholbach> good morning
<hrw> ~curse LP very badly
<atrefre34> hi
<rsajdok> #j warszawajug
<LucidFox> It's Mark!
 * LucidFox salutes
<ogra_cmpc> lamont, is there any reason why we use "apt-get -y --purge install" everywhere across livecd-rootfs ? the --purge doesnt seem to make any sense in connection with install
<lamont> ogra_cmpc: as much historical as anything else, I always use --purge so that anything that gets conflicted out gets purged instead of just removed
<ogra_cmpc> ah
<lamont> but yeah, there _shouldn't_ be any conflicts there
<ogra_cmpc> well, i was just irritated by using it with install
<lamont> ah, don't be irritated by it :-p
<ogra_cmpc> :)
<aretrfre34> where's ubuntu-games channel?
<aretrfre34> boom
<aretrfre34> !boom
<ansgar> aretrfre34: The Debian/Ubuntu Games Team has a channel on OFTC to discuss packaging (#debian-games).
<ogra> lamont, cjwatson, does that change look sane to you ? http://paste.ubuntu.com/446049/
<ogra> (i know its evil to do it in the kernel part, but i found it better than to introduce another subarch check somewhere else )
<dholbach> stefanlsd, james_w: bobbo just fixed bug 586787 (mvo will upload it later)
<ubottu> Launchpad bug 586787 in ubuntu-dev-tools (Ubuntu) "edit-patch should take an existing patch as an argument and apply it" [Wishlist,Fix committed] https://launchpad.net/bugs/586787
<lamont> ogra: which livecd images are being made for omap?
<lamont> because, um, ew
<ogra> lamont, netbook atm
<ogra> but it might be that we will also build base or something like that later
<lamont> I'd rather introduce another subarch check than magically post-edit LIVELIST
<ogra> ok
<lamont> on that note, afk for a few
<mvo> dholbach: I merged it into ubuntu-dev-tools already
<dholbach> mvo: awesome
<CynthiaG> cjwatson: ping
<Daviey> james_w: If i wanted to sign using a different GPG key using bzr-buildpackage, how would i do it?  Using debuild i'd just do -k$DEBEMAIL, but i can't see a logical way to do it using bzr-buildpackage.. Any pointers?
<Laney> you can pass arbitrary options to debuild
<Laney> I think it's bzr bd ... -- -kBLAH
<Laney> or DEBSIGN_KEYID=blah bzr bd ... might also work
<Laney> Daviey: ^
<Daviey> Laney: interesting, didn't see that in --help
<Laney> I could have just fabricated the whole thing but I hope not
<Laney> I could also be thinking of gbp
<Daviey> Laney: if not, i suppose i could overide "--builder="debuild -k$DEBEMAIL""
<RAOF> Laney: No, you're thinking of bzr-buiddeb
<Daviey> i thought they were the same.. :/
<Laney> aren't they?
<Laney> laney@chicken> tail -2 /usr/bin/bzr-buildpackage                                                                                              ~/dev/banshee
<Daviey> $ bzr-buildpackage --help | tail -n1
<Daviey> From:     plugin "builddeb"
<Laney> bzr builddeb "$@"
<Daviey> \o/ $ bzr bd -S --builder="debuild -k$DEBEMAIL"
 * Daviey ponders raising a bug to make it support -k natively
<mpt> If anyone knows how a computer program can tell the difference between a transitional Ubuntu package and a non-transitional one, please let us know in bug 526330
<ubottu> Launchpad bug 526330 in software-center (Ubuntu) "hide transitional packages" [Undecided,Confirmed] https://launchpad.net/bugs/526330
<seb128> mpt, it can't really I think
<seb128> check with mvo though
<seb128> mpt, seems we would need to add extra informations in the system somewhat
<mpt> seb128, how about "Depends on one other package and contains no files itself"?
<seb128> mpt, those have files, ie copyright, etc
<chrisccoulson> "no files itself" is normally incorrect
<mvo> mpt: not trivially, there is a idea to add a "transitional" section that would solve it nicely
<chrisccoulson> yeah ;)
<seb128> so it would be "no file out of the standard ones"
<seb128> but they are not the only one in this case
<mvo> and we don't know the filelist until we downloaded it
<seb128> like we have common packages stripped from translations matching as well
<mpt> mvo, is anyone/anything tracking the progress of the "transitional" section idea?
<Laney> there's a lintian tag empty-binary-package
<Laney> you could look how that works
<Laney> I think it looks at the description to decide to exclude transitional packages, so inverting that logic could fly
<mvo> mpt: not currently :( its something that ideally would be part of the debian policy and is useful for other things (like automatic dependency tracking). the best way forward is probably to start a discussion on debian-devel
<mpt> mvo, hello by the way. :-)
<mpt> mvo, anything in USC that urgently needs design?
<seb128> Laney, it would still catch things like common binaries stripped from translations
<seb128> Laney, so that's still not a solid way to do it
<Laney> no I don't think it would catch all cases, but it might go some way
<JontheEchidna> empty-binary-package + arch-all?
<JontheEchidna> assuming that all transitional packages have been properly set to arch-all ;)
<seb128> JontheEchidna, doesn't solve the translation case
<JontheEchidna> hmm, true
<mvo> mpt: not urgently afaics, it would be nice to know more about the presentation for new apps and for-pay apps, but not that urgent as a lot of the actual code is not done yet anyway
<mvo> mpt: hello to you too :)
<micahg> doko: ping re openjdk
<doko> micahg: ?
<micahg> doko: hi, how do you feel about backporting latest openjdk to hardy?
<micahg> doko: or rather me doing it
<doko> micahg: it's done. just regenerate debian/control
<doko> see https://edge.launchpad.net/~openjdk/+archive/ppa
<micahg> doko: k, thanks, as long as I have you here, what about for jaunty/karmic?
<micahg> doko: can we push to -security with the mozilla updates though?
<doko> micahg: jaunty/karmic: done as well, did you look at the URL???
<doko> mozilla updates?
<micahg> doko: yes, I know it can be done, but can we push it with this: https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
<micahg> doko: and do we have to then test every java app before we push this update?
<doko> micahg: no, just run the TCK (at least for jaunty)
<micahg> doko: k, thanks
<Keybuk> pitti: I'm going to need you to look over the udev update
<Keybuk> you've backported so many changes from trunk
<Keybuk> and introduced so many of your own changes that don't seem to be upstream
<Keybuk> that I'm not sure I'm not reverting fixes
<pitti> Keybuk: sure, np; I'm just aware of one non-upstream change, the other stuff should all be in trunk
<Keybuk> all of the rules changes
<Keybuk> e.g.
<Keybuk> <<<<<<< TREE
<Keybuk> ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*N130*|*N140*|*SR70S/SR71S*|*Q210/P210*", RUN+="keyboard-force-release.sh $devpath samsung-other"
<Keybuk> =======
<Keybuk> ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*N128*|*N130*|*N140*|*SR70S/SR71S*|*Q210/P210*", RUN+="keyboard-force-release.sh $devpath samsung-other"
<Keybuk> >>>>>>> MERGE-SOURCE
<Keybuk> it looks like you've removed N128 there?
<Keybuk> is the non-upstream change you're aware of adding hd[a-z] to cdrom_id.rules ?
<bjf> pitti, is it possible to add log collection to apport, things that have to be run as root?
<pitti> right; and it was just a workaround, TheMuso told me that newer powerpc kernels should work with scsi
 * pitti on phone, will answer in a bit
<bjf> pitti, thanks
<pitti> Keybuk: just checked the changelog, all other fixes were trunk backports
<Keybuk> pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/revision/2586
<pitti> bjf: only through gksu
<Keybuk> if you could review that though, I'd appreciate it
<pitti> bjf: /usr/share/apport/package-hooks/source_xorg.py has an example
<Keybuk> err
<Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/revision/2585
<Keybuk> :p
<bjf> pitti, I saw a "root_command_output" function in the utils but didn't see anything that used it,
<bjf> pitti, thanks
<pitti> Keybuk: so if there's any conflict, the upstream version should win
<pitti> Keybuk: I'm not aware of an Ubuntu change for the N128
<Keybuk> kk
 * pitti looks at bzr head
<Keybuk> I can't work out how to make bzr diff compare a given old revision
<james_w> bzr diff -r <old rev>
<james_w> to see the changes made in that rev from its first parent: bzr diff -c <rev>
<Keybuk> james_w: old rev is in a different branch
<Keybuk> how do I compare my current tree with a given rev of trunk?
<james_w> -r branch:lp:whatever:rev might work
<james_w> or "--old lp:whatever -r <rev>" might
<pitti> Keybuk: so there's a diff in extras/hid2hci/70-hid2hci.rules, is that intended?
<pitti> Keybuk: the lbm-drm change in 70-acl.rules looks Ubuntu specific, and fine to me
<Keybuk> pitti: I can't work that one out either
<Keybuk> james_w: revno:x:../trunk seemed to work
<james_w> ah, option number 3
<pitti> Keybuk: do you know why 78-graphics-card.rules isn't upstream?
<Keybuk> pitti: because kay doesn't like it
<pitti> Keybuk: ah, the hid change was 8b56bada9a9d9a73af06d27634e53648be0cc612
<Keybuk> everyone else builds fbcon in (and so do we as of maverick)
<pitti> Keybuk: I think we should revert our change too, and ask superm1 what breaks :)
<Keybuk> pitti: yeah, I've reverted that back to upstream
<pitti> Keybuk: ok, that also explains the modprobe fbcon change; so if those two will go away as well, then we are down to lbm-drm and powerpc cdrom hda, which seems fine to me
 * pitti is even inclined to drop the cdrom change as well
<quidam-> hi, can i disable the new question for "install / live system" on ubuntu 10.04?, i want to start the live system directly
<Keybuk> pitti: will leave that for now, can reevaluate later
<Keybuk> I ported the change to the new rules file
<pitti> ok
<cjwatson> quidam-: you mean the one at the boot screen, or the one in X?
<cjwatson> in fact I think you must mean the latter
<cjwatson> quidam-: just don't boot with the maybe-ubiquity boot option
<quidam-> cjwatson, hi! but that option is not include into the syslinux config file
<cjwatson> quidam-: it's done dynamically ... can you please back up and give me a bit more context?  are you remastering a CD, or are you just booting the Ubuntu CD?
<h0ar3> Hi guys.. any WUBI developers here?
<quidam-> cjwatson, im making a remastering, usually i justchange the options on isolinux/text.cfg file and thats all, i've seen the new option "maybe-ubiquity" on /proc/cmdline but i can't find it in any config file
<cjwatson> quidam-: you get it if the user just lets the splash screen time out rather than pressing a key at it and selecting "Try Ubuntu"
<cjwatson> quidam-: remove hidden-timeout=1 from gfxboot.cfg and you won't get the splash screen and hence you'll never get maybe-ubiquity
<quidam-> cjwatson, perfect, thanks! :)
<alkisg> Hi, tuxpaint got in universe in Lucid, and its translations are now stripped but they don't end up in a langpack. Is that a packaging problem or a launchpad problem? Where can I find the build log so that I can see why the translations got stripped?
<cjwatson> packages aren't automatically rebuilt when they're moved from main to universe.  somebody probably just needs to manually reupload it
<alkisg> Thank you. I'll mention that to the bug report.
<alkisg> https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/572994
<ubottu> Ubuntu bug 572994 in tuxpaint (Ubuntu) "Unable to change the language in Tuxpaint" [Undecided,New]
<h0ar3> Hi guys.. any WUBI developers here?
<cjwatson> you would do better to ask your question directly
<h0ar3> it is about wubi source.
<h0ar3> checked out the code and it does not work
<h0ar3> it seems there are missing things in v9.04
<h0ar3> when actual developers come here?
<cjwatson> no idea what the state of 9.04 is.  "does not work" does not constitute a bug report or anything that can really be replied to, though
<cjwatson> as far as I remember the version on the 9.04 CD images was tested
<h0ar3> cjwatson: they have migrated from NSIS to python in v9.04
<cjwatson> I'm aware of that
<h0ar3> however on windows I checkedout it.
<h0ar3> and I saw that import ...s were incorrect
<cjwatson> which ones?
<h0ar3> code was not completed.
<superm1> pitti, which change are you referring to?
<h0ar3> cjwatson: i.e. it says from win32.backend import WindowsBackend
<h0ar3> but there is no class named WindowsBackend etc.
<h0ar3> there is no part
<cjwatson> ./src/wubi/backends/win32/backend.py:43:class WindowsBackend(Backend):
<h0ar3> does the actual loopmounting job....
<h0ar3> ok try frontent
<h0ar3> end*
<cjwatson> ./src/wubi/frontends/win32/frontend.py:37:class WindowsFrontend(ui.Frontend):
<cjwatson> loop-mounting is done in partman-auto-loop
<h0ar3> now go to application.py
<cjwatson> separate source package, integrated in Ubuntu
<h0ar3> http://bazaar.launchpad.net/~ubuntu-installer/wubi/trunk/annotate/head:/src/wubi/application.py
<h0ar3> from wubi.backends.win32 import WindowsBackend
<h0ar3> from wubi.frontends.win32 import WindowsFrontend
<cjwatson> that seems fine
<h0ar3> oh
<cjwatson> src/wubi/backends/win32/__init__.py and src/wubi/frontends/win32/__init__.py sort out the symbol resolution
<h0ar3> does not it need ......frontends.backends.win32.backend imp..
<h0ar3> ?
<cjwatson> nope
<cjwatson> ./src/wubi/backends/win32/__init__.py:1:from backend import WindowsBackend
<h0ar3> hmm
<cjwatson> (same for frontend)
<h0ar3> does it run initially when we import from win32?
<cjwatson> yes
<h0ar3> interesting
<h0ar3> okay
<h0ar3> then I could not find the file where the grub4dos or lpvm things are done
<cjwatson> grub is handled in the grub-installer package
<cjwatson> I don't think lpvm is done at all at the moment
<cjwatson> (er you mean lvpm right?)
<h0ar3> where does it call grub-installer in python?
<h0ar3> lvpm yeah
<cjwatson> it doesn't call it directly - it preseeds the Ubuntu installer and sets it going, and the installer calls grub-installer as one of its many steps
<cjwatson> data/preseed.lupin is the skeleton preseed file
<ari-tczew> cjwatson: ping on e-mail's request
<h0ar3> actually I am trying to develop something like wubi
<h0ar3> for another linux distro which is not debian based
<cjwatson> ari-tczew: sorry, I have had no time yet.  What is the deadline?
<cjwatson> h0ar3: then you'll have to port wubi to use that distribution's automatic installation facilities
<cjwatson> (if it has any)
<ari-tczew> cjwatson: don't worry. enough time. just I ping you, I guess that you forgot about this
<cjwatson> indeed, I'm in meetings for much of this week too
<Sarvatt> pitti, Keybuk: the lbm-drm stuff has absolutely no use anymore even in lucid, by all means drop it :)
<Keybuk> Sarvatt: I thought that there was still a need to be able to backport nvidia driver updates?
<Sarvatt> nope, the nouveau userspace in lucid isn't compatible with kernels >= 2.6.34 anyhow
<Keybuk> ok
<h0ar3> cjwatson: thanks for helping. do you work at canonical?
<LucidFox> Is there any theme at the moment that uses GTK CSD?
<LucidFox> or any way I can force GTK to draw CSD?
<slangasek> has anyone written a script to turn a dep3 patch header into a debian/changelog entry automatically?
<cjwatson> h0ar3: yes (though that doesn't matter here, the main wubi author doesn't work for Canonical)
<mathiaz> kees: hi - is -updates enabled in the build chroot by default?
<mathiaz> kees: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment <- suggests to create sbuild chroot with --skip-updates
<slangasek> mathiaz: "the build chroot" - which one?
<slangasek> mathiaz: security is meant to apply cleanly w/o having to enable -updates
<slangasek> so the stacking is release < security < updates < proposed
<mathiaz> slangasek: the ones on the buildds
<slangasek> yes, *which* ones on the buildds :)
<slangasek> it depends on what you're building for
<mathiaz> slangasek: oh ok
<mathiaz> slangasek: so 1. for maverick (for now)
<mathiaz> slangasek: which components should be enabled for the maverick sbuild chroot?
<slangasek> that depends on whether you think you'll use it more for building for -proposed or for -security once maverick is released.  I would assume -proposed is more common if you're not on the security team, so would enable -updates (and that's what I do)
<mathiaz> slangasek: gotcha
<BlackZ> please, sponsor bug #590481
<ubottu> Launchpad bug 590481 in hostname (Ubuntu) "Please merge hostname 3.04 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/590481
<dobey> hi all
<dobey> is there any clear documentation on dealing with python module api breaking in the packages?
<ScottK> dobey: It's crazy talk to ever assume a python module doesn't break api with every release.
<ScottK> barry is working on fixing that though.
<dobey> huh?
<ScottK> It's pretty normal for python module authors not to have a strong focus on maintaining API compatibility.
<ScottK> (I'm assuming we're talking about something outside the core python distribution)
<dobey> so the answer is "we just ignore the problem for now"
<dobey> yes
<dobey> i don't see anything in policy for dealing with it, which is why i ask
<ScottK> We don't currently have a good way to deal with this.
<ScottK> There is work being done upstream to give us the tools to manage it better.
<dobey> and i figured "conflict with every package that depends on it" is not a great solution
<ScottK> It's more like port the reverse depends to the new API and version the depend/build-depend.
<dobey> well the problem comes when you upgrade the module but not those things that depend on it
<ScottK> I have a vague recollection of porting the old API forward into a new version of a package once because it was easier (lots of repends)
<ScottK> Agreed.
<ScottK> repends/rdepends
<ScottK> With the current technology we are pretty much at the mercy of module author's willingness to DTRT.
<dobey> sometimes TRT is breaking API (as is in this case)
<ScottK> In that case it would also involve some coordination with packages that use the old API.
<ScottK> Standard best practices of deprecating for a release or two before removing old API are also good.
<dobey> i think there's only one package that uses the api right now, and we maintain it, so that should be ok
<dobey> it's hard to 'deprecate' something that is 'stop shadowing a core python module' :)
<ScottK> dobey: What's the package?
<dobey> python-ubuntuone-storageprotocol
<dobey> i think ubuntuone-client is all that uses it so far :)
<ScottK> That's likely true given the subject.
<ScottK> dobey: You ought to check with the gsoc student that's doing the KDE client to make sure he's not using it in his project (he's normallly somewhat allergic to Python, so it's unlikely).
<ScottK> dobey: Actually he is.
<ScottK> So you've got another customer at least in development.
<dobey> hrmm, i thought he was writing all c++
<ScottK> dobey: "[16:15:06] <apachelogger> to do the pairing with desktopcouch"
<ScottK> That's all.
<dobey> well that's desktopcouch, which is a different module/package
<CynthiaG> cjwatson: one last ping, I think we have a timezone issue (you're here as I'm not; I'm here as you're not), but if you're here, please pong
 * apachelogger notes that there is no telling whether a organisation/company adopted the API internally
<dobey> well primarily i'm concerned with "stuff in ubuntu"
<dobey> if your stuff isn't in ubuntu, then it's up to you to keep it up to date with change to ubuntu if you want to support it
<ScottK> apachelogger: True, but OTOH since this is all about connecting to Ubuntu One, the Ubuntu One people can probably tell if other stuff is connecting to it.
<ScottK> apachelogger: Sounds like you ought to quick upload something.
<dobey> it doesn't matter because this doesn't break apachelogger's gsoc stuff
<apachelogger> aight
 * apachelogger delegates that stuff to the syncdaemon ;)
<dobey> and the gsoc stuff is supposed to be developed to be merged back into ubuntuone-client as i understand it anyway
<dobey> so i still win :)
<apachelogger> lol
<cjwatson> CynthiaG: sort of here, for the record it helps with timezone desync if you just say what's on your mind rather than doing the ping/pong thing
<CynthiaG> Well,  http://paste.ubuntu.com/445820/  These are the results of the benchmark you wanted, between June 4 and June 5 daily builds + your change to the mkisofs ordering
<cjwatson> thanks.  it seems like a net improvement
<CynthiaG> If you got it already on June 6, apologies
<CynthiaG> Because I did say "cjwatson: link" then
<cjwatson> I did, thanks
<CynthiaG> Ok
<cjwatson> I've been in meetings most of the time though
<cjwatson> I think that's enough for me to say keep that change, at any rate
<CynthiaG> Ah I see. Thanks a lot for your time :)
<cjwatson> thanks for the testing!
<CynthiaG> You're welcome
<apachelogger> dobey: btw, do you happen to know who I can blame for evolution not obeying the contact schema from fdo?
<dobey> apachelogger: i guess you could talk to rodrigo about evoultion issues
<apachelogger> dobey: will do that, thanks :)
<ScottK> apachelogger: Isn't this the same contact schema that breaks existing standards and requires the on disk format to be changed that there was an attempted SRU for a bit ago?
<apachelogger> yes
<apachelogger> well, breaking standards is a bit of a strong description there
<apachelogger> more like - does not use them
<apachelogger> which is rather weird IMHO
 * apachelogger would think that it is much easier to seralize to vcard instead of a essentially completely new format
<ScottK> So I think step zero would be align the FDO thing to existing stuff like vcard.
<ccheney> anyone know of a way i can set a binaries $0 from a script when running it? i need to convince lvm to run when i have a script inline logging its output
<ccheney> so i tried moving it to lvm.real and having a script lvm call it but that didn't work, and neither did replacing eg vgscan which is a symlink to lvm with my script
<ccheney> since when calling lvm it then knows its $0 is not vgscan
<ccheney> and thus refuses to work even when called eg:  lvm vgscan
<cjwatson> the only way I know of is to use 'exec -a NAME', although that isn't portable so you'll probably have to use #! /bin/bash
<ccheney> cjwatson, thanks
<soren> ccheney: Are you just testing something locally, or do you want a solution that can be packaged?
<ccheney> soren, testing bug locally
<soren> ccheney: lvm accepts being named lvm.static as well.
<ccheney> soren, oh ok
<soren> ccheney: So use that instead of lvm.real and I /think/ you'll be ok.
<ccheney> soren, ok thanks
<ccheney> exec -a also worked for me with bash :)
<soren> ccheney: Ok, cool :)
<playya_> is it possible to use multiple distributions in the changelog or do i have to upload a tarball for every distribution?
#ubuntu-devel 2010-06-08
<Chipzz> playya_: the changelog should be in the debian dir, and hence end up in the .diff.gz
<Chipzz> so you shouldn't have to upload multiple tarballs
<playya_> hmm. yes
<playya_> maybe is should just ask for a bzr import on launchpad
<playya_> is it possible to build multiple packages from one bzr repo on lp?
<slangasek> playya_: backing up here, what is it you're trying to achieve?  Is this for a ppa, an SRU, a backport?
<playya_> a ppa
<playya_> i want to package vala-dbus-binding-tool, cornucopia, libfso-glib and maybe zhone from http://git.freesmartphone.org/
<slangasek> playya_: https://help.launchpad.net/Packaging/PPA/Uploading, https://help.launchpad.net/Packaging/PPA/Copying
<slangasek> though PPA usage is more on topic for #launchpad than here
<playya_> ok
<slangasek> as for building multiple packages from one bzr repo... yes, that's possible, though one-repo-per-package is the recommended convention generally
<playya_> ok
<playya_> if i try to test my stuff with pbuilder(native build), i get the following error: configure: error: C compiler cannot create executables
<playya_> i only know the error from cross compiling
<slangasek> playya_: sounds like you haven't installed the 'build-essential' metapackage in your environment
<playya_> i did iirc
<playya_> i was my ccache setup :/
<SpamapS> when I use pbuilder to try and rebuild elinks, I get this: Dependency is not satisfiable: liblua50-dev
<SpamapS> but liblua50-dev is available.. do I need to re-create my maverick environment?
<james_w> SpamapS: you may not have universe enabled inside the chroot
<SpamapS> james_w: I added this to my .pbuilderrc: COMPONENTS="main universe"
<SpamapS> now do I need to re-create the chroot?
<arand> SpamapS: pbuilder --update --ignore-config    iirc
<samliu> hey there, I was wondering if someone could answer some questions about packaging on ubuntu for me?
<samliu> I'm trying to package a tomcat-driven web application
<samliu> so far I've read all of http://www.debian.org/doc/maint-guide/
<samliu> and I've managed to create a .deb
<samliu> but it has nothing inside it...
<samliu> am I supposed to have a makefile and install file?
<samliu> I dont have either
<samliu> my software takes like 240mb too
<samliu> but the .deb has only 1.7kb for some reason
<arand> SpamapS: sudo pbuilder update --override-config   rather.
<samliu> I guess my question is, how do I turn my application into a .deb package
<lifeless> samliu: the @ubuntu-packaging channel exists with a focus on helping people learn how to make debs
<lifeless>  you may get more success asking there
<samliu> oh thanks
<samliu> :D
<CynthiaG> What is DIF in Ubuntu terms? I try to Google 'Ubuntu DIF' and it asks me if I mean 'diff'.
<CynthiaG> It was used in this context, "If it's included before DIF we should be able to sync/merge it over", so I assume it must be some kind of time point/timeframe
<CynthiaG> Oh! Never mind. It's Debian Import Freeze.
<ccheney> anyone happen to know if there is a way to mess with lvm via a library instead of just the commands directly?
<ccheney> appears there is liblvm its just not packaged for some reason, part of lvm2 source
<spenguin[work]> hey anyone using kernel 2.6.33 on a thinkpad x201?
<spenguin[work]> Im refering to this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569
<ubottu> Ubuntu bug 554569 in linux (Ubuntu) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915)" [Medium,Triaged]
<spenguin[work]> Im still unable to have X running with KMS and the patch
<spenguin[work]> anyone using linux on a x201 laptop
<lifeless> I'm using an x201s which is similar
 * RAOF is using an x200, which is also similar, but with a different GPU
<lifeless> RAOF: and CPU
<RAOF> Well, yeah.
<RAOF> I like to think of CPUs as essentially interchangable.
<lifeless> ha
<lifeless> ha
<lifeless> ha
<lifeless> I know you *like* to think that
 * RAOF is aware that there's practically a whole kernel subtree dedicated to maintaining this illusion.
<lifeless> perhaps I should have said
<lifeless> you like to *think* that
<TheMuso> crimsun_: do you have your packaging for ossproxy anywhere?
<hyperair> hmm? cpus aren't interchangable?
<spenguin[work]> lifeless: oh what kernel?
<lifeless> spenguin[work]: lucid
<spenguin[work]> and could you post what libdrm version
<lifeless> lucid
<spenguin[work]> hrm
<lifeless> if you're encountering a problem
<lifeless> it might help to describe it, briefly.
<spenguin[work]> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554569
<ubottu> Ubuntu bug 554569 in linux (Ubuntu) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915)" [Medium,Triaged]
<spenguin[work]> Im on a vanilla kernel though
<spenguin[work]> 2.6.33
<spenguin[work]> tried 2.6.34 too
<spenguin[work]> but I dont get help for that do I? :p
<RAOF> You could concievably wait a couple of days and try a Maverick LiveCD.  That'll have 2.6.35 (which has a bunch of ironlake fixes in it), a new X server, and a new intel DDX.
<RAOF> Well, 2.6.35-rc1 :)
<spenguin[work]> hrm
<hyperair> ooh maverick's got .35?
<hyperair> i thought .35-rc1 had some issue with udev going 100% though?
<RAOF> Not in Maverick.
<hyperair> ah
<hyperair> it wasn't in lucid either, come to think of it.
<hyperair> Sarvatt did mention that there was an issue with the CPU not entering C4, though.
<RAOF> Well, there is that, yeah.
<lifeless> spenguin[work]: have you applied the new BIOS from lenovo ?
<lifeless> I know there was one for the x201s, I'm not sure if there was/wasn't for x201
<lifeless> spenguin[work]: and are you in 32 or 64 bit mode?
<spenguin[work]> 64but
<spenguin[work]> 64bit*
<spenguin[work]> and I havnet applied the bios
<lifeless> things got considerably better for me with the may bios fix
<spenguin[work]> www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-74984 ?
<lifeless> looks like it
<lifeless> and definitely try with lucid
<lifeless> not vanilla - I'm told there are platform things in the 6?0's that needed enablement
<lifeless> the might not be upstream yet
<spenguin[work]> hrm im on an old one -  (1.05 )
<spenguin[work]> lifeless: how did you update the bios
<spenguin[work]> burn the cd etc etc?
<lifeless> yeah
<lifeless> burn the cd
<lifeless> usb cd drive
<lifeless> power, blue key, alternate boot, boom-tish
<spenguin[work]> hrm
<lifeless> (the x201s has no builtin cd drive)
<spenguin[work]> yeah
<spenguin[work]> was thinking of getting the iso onto a usb stick
<spenguin[work]> with unetbootin
<spenguin[work]> what do you think?
<lifeless> no opinion
<spenguin[work]> hrm
<pitti> Good morning
<pitti> Sarvatt: ah, thanks for the heads-up; I thought it was introduced in lucid for supporting a slightly newer nouveau
<spenguin[work]> lifeless: its been my stupid mistake.
<spenguin[work]> was expecting the X pointer with a white screen
<spenguin[work]> startx works :s
<spenguin[work]> even ctrl+alt+backspace doesnt work in the latest xorg hence thought x was locking up
<dholbach> good morning
<apw> tseliot, you about ?
<tseliot> apw: yep
<tseliot> apw: I have to reboot. brb
<apw> tseliot, where do i find the current source for bcmwl, the links seem to be wrong
<apw> tseliot, where do i find the current source for bcmwl, the links seem to be wrong
<apw> tseliot, or is it just to use the apt-get source job ?
<tseliot> apw: what link are you looking at?
<apw> tseliot, when you apt-get source ...
<apw> NOTICE: 'bcmwl' packaging is maintained in the 'Bzr' version control system at:
<apw> https://code.launchpad.net/~broadcom-sta-hackers/broadcom-sta/ubuntu
<apw> Please use:
<apw> bzr get https://code.launchpad.net/~broadcom-sta-hackers/broadcom-sta/ubuntu
<apw> but that doesn't seem to match the real source
<tseliot> apw: it looks like someone forgot to commit his changes to the bzr branch...
<tseliot> apw: so, yes your best bet is either apt-get source or https://launchpad.net/ubuntu/+source/bcmwl
<apw> tseliot, man this bzr stuff just gets in the way, specially when people arn't using it :/
<apw> tseliot, i've got a fix for bcmwl for 2.6.35, is there a way to say 'this patch applied for 2.6.35 and later ?
<apw> tseliot, in the dkms.conf ?
<tseliot> apw: right, you can specify it there
<apw> tseliot, whats the syntax?  i found how to make it for exactly 2.6.35
<tseliot> apw: something like
<tseliot> PATCH[0]="vga_arbiter_workaround.patch"
<tseliot> PATCH_MATCH[0]="^2.6.35"
<apw> is that not just equal to though?
<tseliot> yes, let me find the proper syntax for that
<apw> tseliot, the manuals are awful for this thing :/
<tseliot> apw: you can bug superm1 about it :-P
<apw> heh
<apw>                 echo $1 | egrep -q "${PATCH_MATCH[$index]}"; then
<apw> tseliot, seems its checked that way, so i think you can only say 'for this version'
<apw> tseliot, i only need it because i would like the updated bcmwl packages to be installable on lucid, as a lot of us use the latest kernel in lucid this early in the cycle
<tseliot> apw: I'm pretty sure that something like either 2.6.3[5-6] or 2.6.3[5|6] was allowed
<apw> yeah i guess we could do something like that
<apw> tseliot, so if i get this built and tested in PPA would you be able to sponsor it for me
<tseliot> apw: sure
<tseliot> apw: I was right. Here's what I found in http://linux.dell.com/dkms/dkms-ols2004.pdf (mentioned in the man page): PATCH_MATCH[0]="2.4.[2-9][2-9]"
<tseliot> also make sure that the number that you use in both PATCH[0] and PATCH_MATCH[0] (i.e. 0 in this case) is not already in use
<tseliot> by some other patch in dkms.conf
<apw> '^2.6.(3[5-9]|[4-9][0-9])-' looks to be the thing
<apw> tseliot, yeah we already have 3
<tseliot> ok
 * ogra curses
<ogra> why the heck are dashes not allowed in initramfs script names
<highvoltage> ogra: that's weird :)
<Kano> hi cjwatson , why does the u grub2 package allow install into partitions and the debian one not with dpkg-reconfigure grub-pc
<Kano> also why does http://packages.ubuntu.com/search?keywords=grub-pc&searchon=names&suite=maverick&section=all find nothing
<mdz> dholbach: the countdown meter in your blog post is broken on planet ubuntu for some reason
<apw> Kano, the list of suites at the top does not appear to include maverick, so its possible there is no maverick data in there
<Kano> it is selectable
<apw> but the results list all series and its not included
<apw> (across the top as options)
<apw> tseliot, ok ... i've added the debdiff for bcmwl to bug #590924, i have also built the source packags (and diff) and put them on chinstrap:~apw/sign perhaps you could review them for me
<ubottu> Launchpad bug 590924 in bcmwl (Ubuntu) "Broadcom STA (bcmwl) driver fails to build with 2.6.35-1 kernel" [Medium,Triaged] https://launchpad.net/bugs/590924
<apw> robbiew, about ?
<tseliot> apw: ok, thanks, I'll have a look at it
<apw> tseliot, i built it in my 'blue' ppa and it seems to install and work too
<apw> https://edge.launchpad.net/~apw/+archive/blue/+packages
<tseliot> ah, even better
<mpt> pitti, hi, <https://wiki.ubuntu.com/ReleaseTeam/FeatureStatus> begins with two copies of <http://people.canonical.com/~pitti/workitems/maverick/all-maverick-alpha-2.svg>. Is that a mistake?
<mpt> hm, according to <https://launchpad.net/ubuntu/maverick>, Maverick doesn't have a release manager
<mpt> Should we be concerned? :-)
<didrocks> mpt: don't you know about autorelease mode? :-)
<alonswartz> cjwatson: where would be the appropriate place to file bugs against casper? The project on LP isn't configured for bug reporting.
<ogra> alonswartz, against the source package in ubuntu
<alonswartz> thanks ogra, will do.
<cjwatson> mpt: more true than you know
<cjwatson> (but technically this is just disconnect between LP's terminology and Ubuntu's)
<ogra> hmm, do we have any documentation how to write text on top of the plymouth splash ?
 * ogra knows how to do it with usplash. but there doesnt seem to be any docs for plymouth 
<ogra> resizing a partition on first boot takes 5-6min on a 4G SD card i'D like to tell the user that the system isnt hung :&
<cjwatson> plymouth --help
<ogra> heh, to simple :P
 * ogra tried man plymouth and google :)
<pitti> mpt: not sure why it's duplicated
<dholbach> mdz: the server went down for maintenance
<dholbach> mdz: it should be back up
<jussi> what is keybuk's normal timezone?
<Tm_T> jussi: in my lastlog he's been talking between 1500 and 2200
<Tm_T> or so
<jussi> right, thanks
<jussi> well if someone sees him, please prod him to pm me
<pitti> try email?
<mdz> dholbach: ah, ok
<mdz> dholbach: I clicked through and it looked fine on your site, but not on planet
<dholbach> mdz: humâ¦ weird
<dholbach> mdz: glad it works now :)
<ari-tczew> dholbach: did you saw my email?
<dholbach> ari-tczew: yes, but I'm quite busy right now
<dholbach> ari-tczew: I actually prefer if the archive admins take care  of it
<ari-tczew> dholbach: do you will change your prefer?
<tseliot> apw: is the final dash in PATCH_MATCH[3]="^2.6.(3[5-9]|[4-9][0-9])-" a typo?
<dholbach> ari-tczew: if syncs are not performed regularly enough this should be fixed
<apw> tseliot, the version numbers are the full kernel abi numbers so ... 2.6.35-1 etc
<apw> so i added the - to ensure i matched the entire number
<ari-tczew> dholbach: upload package by script reduces all time to waiting for archive admins
<dholbach> ari-tczew: the archive admins double-check stuff and know if there's other important builds going on, I don't want to override them if it's not super urgent and necessary
<tseliot> apw: I think it should be enough to match the kernel version
<apw> tseliot, am ambivalent either way, the version is the -k parameter which is always that full form right?
<tseliot> apw: yes, that's the full name. I was just worried about vanilla kernels
<tseliot> which may not have the -1
<apw> tseliot, ok i'll chop it off and regenerate it
<tseliot> apw: perfect, thanks
<Riddell> mvo: how come libxbase doesn't get packaging updates?  you seem to have given up on it years ago
<apw> tseliot, that should be it, in the same place
<tseliot> apw: ok, I'll sign and upload
<Riddell> mvo: reason for asking is bug 591239
<ubottu> Launchpad bug 591239 in libxbase (Ubuntu) "[MIR] libxbase" [Undecided,New] https://launchpad.net/bugs/591239
<mvo> Riddell: *cough* it was a bit underused in the past, if its now used for something like krita I shall resurrect it and/or find a (co)maintainer
<ogra> mumble mumble
<ogra> is there any way to tell ureadahead to not run ?
<amitk> apt-get remove ureadahead will tell it _very firmly_ not to run
<ogra> amitk, i'm not sure that works nowadays
<ion> Comment out the âstart on...â line probably.
<ogra> well, i have issues in initramfs
<ogra> wont help to fiddle with initscripts
<shtylman> what would be the best way to set the scaling governor to performance during certain times of the day?
<shtylman> a cron job? or would an init script be able to do something there?
<micahg> doko: how do I get openjdk to build w/the openjdk team as the maintainer?
<Kano> control
<lamont> NCommander: around?
<lamont> NCommander: did we decide that qt4-x11 actually needs a longer timeout, or just needs to be not-lzma-on-arm?
<mathiaz> pitti: slangasek: hi - I've a question related an sru
<mathiaz> there is currently a sru for eucalyptus in lucid-proposed, ubuntu30.1
<mathiaz> I'm planning to upload a new version to lucid-proposed (ubuntu30.2)
<mathiaz> that fixes more a bugs and revert a patch that went into 30.1
<mathiaz> so I'd like to have 30.1 marked as failed (as it will be superseeded by30.2)
<mathiaz> when I'm preparing the 30.2 upload should I include the changelog entry of 30.1 in the .changes file as well (given that 30.1 wasn't published in -updates)?
<mathiaz> slangasek: pitti: ^^
<slangasek> mathiaz: yes, you should
<mathiaz> slangasek: ok - what should be done with 30.1?
<mathiaz> slangasek: just leave it in -proposed?
<mathiaz> slangasek: or should it be rejected somehow?
<slangasek> mathiaz: it will be overwritten when 30.2 is accepted
<mathiaz> slangasek: ok - so nothing is required for 30.1
<slangasek> mathiaz: only if you were worried that it would be incorrectly copied to -updates before 30.2 is accepted; in that case you should take care to tag as 'verification-failed' whichever of the SRU bugs are causing you to reroll
<mathiaz> slangasek: right - I've already added the verification-failed tag to the SRU bug we're reverting in 30.2
<slangasek> mathiaz: then that's everything :)
<mathiaz> slangasek: great - thanks for helping out
<slangasek> n/p
<mathiaz> slangasek: eucalyptus 30.2 uploaded to lucid-proposed - if you could have a look at it it would be helpful as we'd like to start the verification process today
<mistery> hi all
<mistery> i'm investigating what is required for me to start contributing from a dev perspective.
<mistery> anyone I can chat to? thanks
<mathiaz> mistery: I'd start from http://www.ubuntu.com/community
<mathiaz> mistery: ^^ this page outlines different ways to get involved and provides links to ressources
<mistery> hi mathiaz.. been there and started reading some of the basic resources already
<mistery> that's where i got this channel from
<mistery> how do I actually find something to work on? Some small to start with :)
<mathiaz> mistery: which area are you interested in? desktop, server, mozilla?
<mistery> probably desktop for now
<mathiaz> mistery: I'd suggest to go over https://wiki.ubuntu.com/DesktopTeam/GettingStarted
<mistery> mathiaz: thanks, i'll start looking into that now.
<mathiaz> mistery: np - happy reading !
<mistery> mathiaz: thx :)
<Q-FUNK> doko: would you have any instructions for how to proceeed with bug #587186 ?
<ubottu> Launchpad bug 587186 in gcc-4.4 (Ubuntu) "libc6 upgrade fails: illegal instruction" [High,Triaged] https://launchpad.net/bugs/587186
<slangasek> mathiaz: accepted
<mathiaz> Daviey: ^^
<slangasek> mathiaz: eh, bug #579942 is marked private; SRU bugs need to be visible
<ubottu> Bug 579942 on http://launchpad.net/bugs/579942 is private
<mathiaz> slangasek: I've marked the bug public
<slangasek> mathiaz: thanks!
<Daviey> mathiaz / slangasek: Great, thanks
<Riddell> zul: bug 240519 is assigned to you, any progress or should we reject it?
<ubottu> Launchpad bug 240519 in php5 (Ubuntu Hardy) "sybase_* functions missing in php5-sybase for hardy" [Undecided,Fix committed] https://launchpad.net/bugs/240519
<Riddell> bug https://bugs.edge.launchpad.net/ubuntu/+source/php5/+bug/ is blocking
<zul> reject it...ill probably have another look at it later
<Riddell> Daviey: what are you expecting to happen with bug 583698 ? there's an upload in unapproved but no patch on the bug and sru aren't subscribed
<ubottu> Launchpad bug 583698 in apache2 (Ubuntu Hardy) "If /usr/sbin/apache2 is set -x, upgrades fail" [Low,Triaged] https://launchpad.net/bugs/583698
<Daviey> Riddell: good point!
<Daviey> Riddell: i will sort this today
<Chipzz> Riddell: I'ld say this is a user error
<Chipzz> iirc apache has an option in /etc/default/apache which can be used to disable it, no?
<Chipzz> hrrrrm it seems it doesn't
<Chipzz> although I remember it doing so
<Chipzz> maybe in an earlier version
<Riddell> cjwatson: what's the status of bug 591199 ?  there's an upload but ubuntu-sru aren't subscribed and I don't see a patch on the bug, there's no test case too (presumably fairly trivial for docs)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/591199)
<cjwatson> Riddell: ubuntu-sru subscribed, patch linked
<cjwatson> Riddell: I'm all for standard format but I don't see the point in writing a test case here, there's no way it can be anything other than "check that it now looks right"
<cjwatson> (I wouldn't require a test case if this were somebody else's SRU)
<Riddell> I'm impressed you didn't just accept it yourself :)
<Sarvatt> any chance for oprofile rebuild against the new binutils so llvm-dev is installable? one was just uploaded today to rebuild against last weeks binutils but there was another newer binutils released right after..
<Riddell> Sarvatt: already?
<Sarvatt> yep..
<Sarvatt> worst decision I ever made trying to package daily builds of something that needs llvm-dev, thats broken more than its not
<Riddell> Sarvatt: uploaded oprofile
<Sarvatt> \o/ thanks Riddell!
<Sarvatt> Riddell: your changelog message looks like mine, except its degenerated to "no change rebuild #15 for this @%!* package." now :)
<cjwatson> Riddell: I'm a good boy
 * maco gives cjwatson a cookie
<Riddell> imbrandon: what's the status of bug 537379 ?
<ubottu> Launchpad bug 537379 in libgda4 (Ubuntu) "Sync libgda4 4.0.8-1 (main) from Debian unstable (main)" [High,New] https://launchpad.net/bugs/537379
<imbrandon> Riddell: lemme check
<imbrandon> Riddell: still no fix from upstream or debian on x86_64 ftbfs
<imbrandon> so if we sync it we loose that build
<kees> weird, procps didn't show up on the "needs merging" list.
<pwnguin> a friend of mine suggested i386 support was being dropped in meerkat, but I can't find any official documentation for this assertion. the most ive found is a bug report within launchpad
<pwnguin> oh neat, i also found this draft blueprint
<pwnguin> https://wiki.ubuntu.com/FoundationsTeam/Specs/Maverick686DefaultCompile
<ajmitch> pwnguin: I thought I'd seen it on ubuntu-devel-announce, but I just checked & it's not there
<pwnguin> boy, the blueprint is very draft as in forked from a template unrevised
<lfaraone> Should SRU bugs that are waiting for approval be triaged, or fix committed?
<JFo> lfaraone, my money is on Triaged as they will not get committed until they are approved for the SRU
 * micahg thinks there's a script which sets status and comments for them
<cjwatson> lfaraone: makes no difference to SRU processing.  I tend to use In Progress personally but I wouldn't "correct" it if I saw something different
<ajmitch> darn, I just changed a bug away from 'in progress'
<geser> Riddell: in what way got bug 586509 fixed? LP doesn't list a git source package for maverick and I don't see it in the new queue either (or did I miss something)
<ubottu> Launchpad bug 586509 in git-core (Ubuntu) "Sync git 1:1.7.1-1 (main) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/586509
<lfaraone> cjwatson: ah, mk.
<Riddell> geser: hmm, the version number is too small
<ajmitch> with an epoch?
<Riddell> geser: hardy had 4.3.20-12  so syncing version 1.7.1 won't work
<geser> Riddell: 1:1.7.1-1 is bigger than 4.3.20-12
<Riddell> although.. it does have an epoch
<Riddell> there's also this error
<Riddell> E: git-core is in main but its source (git) is not.
<cjwatson> there's a sync-source option for that
<cjwatson> it requires a switch because that's a situation an AA should check manually (it'll probably involve making sure the new source is overridden to main)
<geser> git-core got renamed to git, so it has to be moved to main too (git-core was in main)
 * Riddell tries the --force-more switch
<geser> there was a different git in the archive in the past, therefore git (the VCS) got named git-core but as appararently enough time has passed it got renamed to git
<Riddell> that did it
<aganice> hey, i'd like to release this kobo ereader app thing to the multiverse repository, who should i talk to?
<lifeless> is it packaged? do you have upload rights?
<aganice> it's packaged as a .deb, and the project lead at the company asked me to find out how to offer their app in the repository, so yesish to upload rights?
<NCommander> lamont: I think it might just be easier to do a longer timeout as I keep not finding time to change the packaging, then test to make sure it will build
<lifeless> aganice: upload rights is an ubuntu thing
<geser> Riddell: as the new "git" source package builds the same binary debs as the current "git-core" will it be automatically picked up (by some script) that "git-core" can be removed or is a bug needed?
<aganice> lifeless, thanks. the answer is no, then, clearly :p
<lifeless> so, if you want it in multiverse, I'd start by putting it up on REVU and getting the packaging reviewed, then when its ready an Ubuntu developer can 'sponsor' it into the archive for you.
<Riddell> geser: git-core will appear in the NBS list soon and an archive admin will remove it one day
<aganice> lifeless, thanks very much!
<lifeless> aganice: alternatively, you can become a canonical partner (details on the website, I can find a link for you if you like), and it can be uploaded to the Canonical partner archive.
<cjwatson> it'll probably happen more or less as soon as it has no reverse-dependencies
<geser> Riddell: NBS lists also source packages without any binary debs left too? (all binary debs build from git-core (source) are now build by git (source))
<cjwatson> no, it doesn't
<aganice> lifeless, thanks very much, i'll do that.
<cjwatson> removal of obsoleted source packages does require a bug
<ari-tczew> Riddel: why do you sync package without information who has uploaded the package?
<geser> ok, will file one once git got build
<lifeless> aganice: http://www.canonical.com/about-canonical/partnerships - about partnerships
<slangasek> cjwatson: multi-catalog> oh; the usual problem is that PC BIOSes don't know to check the architecture field.  Have you made sure the BIOS boot image is first?
 * slangasek ran into this when trying to build multiarch i386+amd64+ia64 ISOs
<cjwatson> pretty sure grub-mkrescue puts it first
<lamont> NCommander: ok.  give me a source-package name and a timeout :p  I'll be rolling a new lp-buildd today or tomorrow and would love to put it in thene
<lamont> then, even
<slangasek> cjwatson: ok - then that solves the only problem I knew of at the time, which was PCs trying to boot the first el torito image regardless of architecture :)
<Riddell> ari-tczew: such as which?
<NCommander> lamont: qt4-x11, 10 hour timeout?
<Riddell> ari-tczew: tab completion advised on irc else I won't see your message if you misspell my nick
<cjwatson> slangasek: (I could be wrong, do you know an easy way to check?)
<lamont> NCommander: is that a WAG, or expected max?
<NCommander> lamont: WAG
<slangasek> cjwatson: my memory is fuzzy on that part, sorry.  I thought it was a matter of the ordering of the arguments to mkisofs
<lamont> NCommander: ok
<cjwatson> mm, well this is using xorriso at least in part because I think it permitted hybrid ISO/USB images
<cjwatson> we definitely put the BIOS options first though
<cjwatson> slangasek: I think the assertion in the Fedora wiki page was that some BIOSes just plain didn't like multi-catalog at all, but I couldn't find citations
<ari-tczew> Riddell: I forgot about tab, sorry. Today sync seems to be ok, but 18th May you did syncs without uploader information
<NCommander> lamont: disregard, qt4-x11 magically fixed itself it seems
<Riddell> bryceh: xf86-input-evtouch is blacklisted from sync, should I change that for bug 589535 ?
<ubottu> Launchpad bug 589535 in xf86-input-evtouch (Ubuntu) "Sync xf86-input-evtouch 0.8.8-4 (universe) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/589535
<bryceh> Riddell, yeah it needs fakesync
<cjwatson> (FWIW, the image I have boots in kvm both normally and with an EFI firmware image)
<cjwatson> ari-tczew: exactly what uploader information do you mean?
<Riddell> bryceh: ok, will you do that?
<lamont> NCommander: coolness
<ari-tczew> cjwatson: in launchpad "Uploaded by" and there person who has requested sync
<cjwatson> ari-tczew: do you mean that the person who requested the sync is there and shouldn't be, or that it shouldn't be there but is?
<slangasek> cjwatson: well... could be, but that would imply malice on the part of the implementor instead of just stupidity :)
<NCommander> lamont: maybe disregard the disregard ...
<bryceh> Riddell, is there anyone else that can do it?  it should be pretty trivial but I'm kinda tied up at the moment
<ari-tczew> cjwatson: lol, look, I requested sync in bug 579593 and I'm not as uploader of this. check then https://launchpad.net/ubuntu/+source/connman/0.48+dfsg-2
<ubottu> Launchpad bug 579593 in connman (Ubuntu) "Sync connman 0.48+dfsg-2 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/579593
<Riddell> bryceh: I'll subscribe ubuntu sponsors
<bryceh> thanks
<lamont> NCommander: heh.  I'll ping you before I do the upload.  not sure when that'll be, but hopefully before the next time all the i386 virtual builders faceplant
<lamont> since the upload is to specifically address that
<bryceh> in fact, there may be an open question if we should just drop -evtouch.  I think rickspencer3 was suggesting that course of action for maverick
<bryceh> but I'll leave that to RAOF to consider
<rickspencer3> was I?
<cjwatson> ari-tczew: assume accident rather than malice, then
<ari-tczew> I see language barrier
<cjwatson> hmm?
<cjwatson> slangasek: excessive assertions of what they mistakenly believed to be correct, perhaps - hard to tell with BIOSes
<slangasek> indeed :)
<cjwatson> I have to say I'm not sure how to make Intel Macs continue to use the BIOS boot loader
<cjwatson> presumably they'll notice that the EFI catalog entry is there and use it if they can
<slangasek> I would imagine so
<slangasek> though given that most of the El Torito spec was written for Apple's benefit, perhaps their implementation is smart enough that you can point it at a better option
<slangasek> (well - not most of the El Torito spec perhaps, but most of the multi-catalog support)
<slangasek> cjwatson: hah - I have a cdrkit patch on my hard drive from 2007 to add a -eltorito-efi option to permit setting the correct platform ID
<slangasek> cjwatson: perhaps it would be useful to you? :)
<cjwatson> slangasek: I'm not sure I want to rip out grub's use of xorriso at this point :)
<cjwatson> though it might not hurt for reference
<slangasek> right :)
<slangasek> "Mark El Torito boot image for use with EFI (Itanium)" - <chuckle>
<slangasek> cjwatson: http://people.canonical.com/~vorlon/cdrkit-eltorito-efi.patch
<slangasek> the other key part, as I said, is the ordering of the options to genisoimage
<slangasek> (which I have recorded here as well if it's useful)
<cjwatson> thanks, sure
<cjwatson> FWIW, the image I posted was generated by an *almost* vanilla grub-mkrescue from grub trunk
<cjwatson> the only thing I changed was a bit of brutalisation to get it to know where to find the BIOS and EFI modules at the same time, since those two grub packages aren't coinstallable yet
<cjwatson> which essentially meant running it from the build tree with a hacked prefix and copying some files about
 * slangasek nods
<slangasek> cjwatson: http://people.canonical.com/~vorlon/multiarch-cd.txt, then
<cjwatson> right
<cjwatson> FWIW I think the arguments here are coming out as -b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-info-table --embedded-boot embed.img --efi-boot efi.img
<cjwatson> or words to that effect
<cjwatson> where efi.img is a FAT filesystem image with /efi/boot/bootx64.efi and /efi/boot/bootia32.efi in it
<cjwatson> some of these are probably xorriso-specific options
<slangasek> what does the --embedded-boot do?
<cjwatson> I think it's an alias for -generic-boot
<cjwatson> :q
<cjwatson> dodh
<cjwatson> you know it's late when you can't spell doh
<CynthiaG> and when you type :q in the wrong window, 5 seconds in-between
<cjwatson> slangasek: source for this is http://lists.gnu.org/archive/html/grub-devel/2010-04/msg00000.html and thread, you may do better than I at deciphering it
<cjwatson> slangasek: oh, this is from the el torito spec I think
<cjwatson> slangasek: if you have it in front of you, there's a figure on page 6 labelled "Three types of CD-ROM configuration", and the one labelled "Multiple Boot-Image Configuration" has a bootable disk image in the first 16 sectors, which is normally unused in single-catalog configurations
<cjwatson> slangasek: that's what this is doing
<slangasek> ah, right
<cjwatson> slangasek: the effect of this, I think, is to make it bootable as a USB stick as well
 * slangasek nods
<cjwatson> or possibly a floppy
<cjwatson> I know that nowadays grub-mkrescue produces a single image that's all three at once
<cjwatson> barry: ooh, your MBP says i386-pc, that's interesting
<cjwatson> that implies that, given the choice between BIOS and EFI boot images, it picks BIOS
<cjwatson> barry: do you have some kind of special arrangement with refit or whatever, or is that all bypassed here?
<cjwatson> (BTW this is the desired situation!  it's just slightly unexpected)
#ubuntu-devel 2010-06-09
<barry> cjwatson: nothing special.  i run ubuntu in a fusion vm, so the underlying os is totally stock
<barry> cjwatson: but yeah that *is* interesting :)
<slangasek> does Ubuntu even see the hardware from within fusion?
<slangasek> (hardware/EFI)
<kees> hmpf, I can't compile gdb with sbuild.
 * kees scratches his head
<kees> dpkg-source: error: cannot fstat file ./gdb_7.1.orig.tar.bz2: No such file or directory
<kees> why is that "./" instead of ../ ?
<slangasek> kees: is that a dpkg-source -x or dpkg-source -b?
<barry> slangasek: how can i find out? :)  i doubt it though; vms probably see a bios from fusion.  however, this shouldn't enter into it because it was a host machine boot to cjwatson's test cd
<kees> slangasek: not sure how sbuild is calling dpkg-source
<slangasek> barry: cat /proc/cpuinfo inside the VM, maybe
<slangasek> barry: oh, you did a host machine boot - n/m
<slangasek> barry: in that case my questions are irrelevant :)
<barry> slangasek: :)
<slangasek> kees: well, if it were using dpkg-source to unpack (-x), it could be a bad path in the .dsc
<barry> slangasek: but it does see it as an intel core 2 duo T9900 @ 3.06GHz
<slangasek> kees: if it's when building the source package (-b), I don't know
<kees> slangasek: oh! that alone was enough to remind me about what I think the problem is.
<slangasek> kees: ok :)
<kees> I think my sbuild wrapper is doing the wrong thing about where it puts the source.
<kees> where I use "my" loosely given several other people wrote it too
<kees> hm, no
<cjwatson> barry: well, if I get a report from an EFI machine that's i386-efi or x86_64-efi (and that isn't my kvm testbed), then that's basic functionality confirmed and I just need to wait to see if I get reports of BIOS machines falling over
<cjwatson> I plan to ask for it to be run through the certification lab as well
<barry> cjwatson: +1
<TheMuso> cjwatson: If I boot that CD and let refit search for it, I get a lot of different options. Haven't looked at what each one is yet. When I boot the CD using teh C key, I get no farther than the "welcome to GRUB" message. I'll email you with more details when I test more.
 * barry -> away
 * kees kicks sbuild
<CynthiaG> What should I do if a package has unit tests that "succeeded" before, but now "fails" because of a fix that made things more true to a spec?
<CynthiaG> If that question is no good here, and depends on the package in question, please say so instead :)
<kees> CynthiaG: i'd say is depends on the spec, the package, and the test.  :)
<CynthiaG> kees: SVG, librsvg, all unit tests :\
<kees> CynthiaG: ah, in that case, I'd bring it to the attention of the upstream librsvg folks, since it sounds like the tests need fixing if you made it more strict to SVG, etc
<CynthiaG> sounds like a plan
<SpamapS> micahg: ping!
<micahg> SpamapS: pong
<SpamapS> micahg: do you have a moment to discuss couchdb?
<micahg> SpamapS: sure
<SpamapS> micahg: I'm working on merging 0.11.0-1 .. but this seems to be breaking the build: sed -i s,$(LIB)$$,$(LIB)/$(DEB_UPSTREAM_VERSION), configure
<SpamapS> micahg: I'm not sure why, but it causes an issue with AC_CHECK_CURL
<micahg> SpamapS: can you pastebin the error?
<SpamapS> micahg: standby
<SpamapS> http://paste.ubuntu.com/446894/
<SpamapS> micahg: if I remove the sed line, and re-run, it fails later (on the js library configuration, which makes sense).
<micahg> SpamapS: I'm not sure
<blue_anna> how can I get around dependency issues from having too recent of a version of a package (off of launchpad)
<blue_anna>   libxmu-dev: Depends: libxmu-headers (= 2:1.0.5-1) but 2:1.0.5+git20100604.af962b3b-0ubuntu0sarvatt~lucid is to be installed
<SpamapS> micahg: what is that sed line meant to do? Is there no way to fix that problem w/ LD_LIBRARY_PATH or a configure option?
<micahg> SpamapS: I'm not sure, it was there in the last version
<micahg> SpamapS: it seems to set up a specialized versioned path for the compiler
<SpamapS> micahg: ok well I must have done something weird because I backed up a bit and now I can't reproduce that problem
<SpamapS> dpkg-shlibdeps: warning: couldn't find library libmozjs.so needed by debian/couchdb-bin/usr/lib/couchdb/bin/couchjs (ELF format: 'elf64-x86-64'; RPATH: '').
<SpamapS> now I'm getting that one
<micahg> SpamapS: k, just a note, BTW, better to do a versioned xulrunner-1.9.2 GRE check in rules
<micahg> SpamapS: that's normal
<SpamapS> micahg: rules has been carried forward so should still be doing everything from before
 * micahg might have forgotten it :)
<micahg> SpamapS: ^^
<SpamapS> xulrunner_gre_version := $(shell xulrunner --gre-version)
<SpamapS> xulrunner_dep = xulrunner-$(shell echo $(xulrunner_gre_version) | cut -f1-3 -d.)
<micahg> SpamapS: right, so the first line should be xulrunner_gre_version := $(shell xulrunner-1.9.2 --gre-version)
<SpamapS> aha.. the AC_CHECK_CURL thing is back.. argh
<SpamapS> something to do with aclocal.m4
 * SpamapS 's heads start to spin when autoconf lets its magic smoke out
 * SpamapS has two heads, yes. ;)
<SpamapS> micahg: thanks for your help, I'll keep digging
<micahg> SpamapS: no problem, feel free to ping me if I can help
<artfwo> Hi! Would anyone care to sponsor bug 591528 (main)?
<ubottu> Launchpad bug 591528 in libraw1394 (Ubuntu) "FTBFS on all architectures (Maverick)" [Undecided,Confirmed] https://launchpad.net/bugs/591528
<RAOF> How do I get to attach gdb to compiz now that our security overlords have restricted ptrace?  Things I've tried which don't work: running âsudo gdb compizâ, and âecho 0 | sudo tee /proc/sys/kernel/ptrace_scope.
<lifeless> RAOF: see pitti's announcement
<lifeless> RAOF: there is a sysctl you can set
<lifeless> which he documented
<RAOF> Ok.  Re-reading that, i'm setting the sysctl to 0, and it's still not working.
<RAOF> Debugging compositors sucks.
<lifeless> RAOF: perhaps you need to set it to zero before anything starts up ?
<lifeless> it might be a process flag?
<lifeless> total speculation
<RAOF> Possibly it's inherited by children, so you need to set it before logging in.
<lifeless> yes
<lifeless> thts what I'm saying
<lifeless> so you want it in sysctl.d
<RAOF> I've set it there, so I'll see next time I log in.
<RAOF> I've got a usable backtrace by more devious methods anyway.
<lifeless> oh?
<RAOF> Well, the not terribly devious method of starting compiz under gdb and queuing up commands to run, of which the final one is âlet it actually die and start metacityâ
<kees> RAOF: "echo 0 | sudo tee /proc/sys/kernel/ptrace_scope" will disable the ptrace protection, so if you're hitting something else that's a different problem.  what is the error you're seeing?
<kees> lifeless: and which announcement by pitti?
<RAOF> kees: ptrace: operation not supported.
<RAOF> Bah, sorry.  Not permitted.
<lifeless> kees: by you. brain fail.
<kees> lifeless: oh! okay, thought I missed something.
<lifeless> kees: by your other other evil twin
<kees> lifeless: heh
<kees> RAOF: what's the action you're taking with gdb, exactly?
<RAOF> Ok.  Now I'm surprised.  That works now!
<kees> setting the sysctl in /proc should immediately revert the behavior.
<kees> RAOF: either "sudo gdb ..." or setting the sysctl should do it.
<RAOF> Hm, no it still doesn't work.  It works in the same VT as where I started compiz, but switching to VT1 gives operation not permitted, even with sudo gdb
<kees> what's the command exactly you're using?
<kees> (vt really should not matter)
<kees> are you restarting procps possibly?  is /proc/sys/kernel/ptrace_scope remaining 0 ?
<kees> RAOF: this works for me...
<kees> "pidof compiz" then "sudo gdb" then "attach PID" where PID is whatever pidof returned.
<kees> even tried different vts etc
 * kees has to hit the sack.  email me if you learn anything more.
<RAOF> Sleep well.
<pitti> Good morning
<jussi> Morning Martin!
<pitti> RAOF, lifeless: ptrace> rather kees' announcement, I figure? :-)
<pitti> RAOF: sudo gdb doesn't work ?!?
<RAOF> pitti: It didn't when I was trying it, but now it seems to work.
<RAOF> I'm not sure what was happening.
<RAOF> And I think I'll need a debug build of mesa to track the segfault down, anyway.  The optimisations appear to be doing strange things (like optimising out statements that would cause a null pointer dereference).
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<cjwatson> could an ubuntu-mir member have a look over bug 582189, please?  I'm approaching being blocked on a new grub2 package
<ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [Undecided,New] https://launchpad.net/bugs/582189
<pitti> superm1: wrt. bug 550288 and bug 444420, would it make sense to combine the rule to match KERNEL=="hiddev*|hidraw*", to cover both cases?
<ubottu> Launchpad bug 550288 in udev (Ubuntu Lucid) "bluez fails to discover mx5000 keyboard and mouse" [Undecided,Triaged] https://launchpad.net/bugs/550288
<ubottu> Launchpad bug 444420 in udev (Ubuntu) "USB logitech bluetooth doesn't work" [Undecided,Fix released] https://launchpad.net/bugs/444420
<pitti> superm1: or does it wreak havoc to apply it to the respective other device?
<superm1> pitti, unfortunately I don't have any of that logitech hardware to be able to verify myself
<superm1> so i'm not sure what happens if you use the other device in that scenario
<pitti> superm1: I asked in the bug for testing; I just wondered whether you'd know in general
<superm1> pitti, ah, no, not so sure, sorry
<jo-erlend> I'm exploring Quickly and I have some questions about it. Something tells me this might not be the proper channel for it, but what is?
<dholbach> jo-erlend: you could try #ubuntu-app-devel or #ubuntu-desktop
<jo-erlend> thanks. :)
<cjwatson> hm, another new kernel ABI, and I'd only almost got rid of 2.6.34-5 from the archive ...
<danigm> hello, I need to update ubuntu poppler package to upstream, what's the correct way to make that with launchpad?
<seb128> danigm, what do you mean there?
<seb128> danigm, you want to package a new version for maverick or for yourself?
<seb128> danigm, which version?
<danigm> both
<danigm> 0.14
<danigm> I want to package 0.14 for maverick and then I have a "unofficial" patch to add to my own package
<danigm> and then make a backport for guadalinexV6 (ubuntu jaunty)
<danigm> I see that there is a lp:ubuntu/poppler and a lp:poppler
<seb128> danigm, you can get the new poppler without new cairo
<seb128> danigm, lp:poppler is an upstream import
<seb128> danigm, lp:ubuntu/poppler is the ubuntu package, you want to use that to base your changes
<danigm> seb128: yep, and there's my question, what's the correct way to merge the package and the upstream?
<seb128> danigm, we don't want cairo 1.9 though
<seb128> danigm, so no new poppler for now
<seb128> danigm, I'm not sure about autoimports, I usually apt-get source poppler to work on it and copy the debian dir over to the new tarball
<seb128> danigm, then dch -v version and work there
<danigm> seb128: ah, ok
<danigm> seb128: then that's what I'll do
<seb128> you can probably bzr merge-upstream tarball in the import
<seb128> danigm, but as said don't bother for maverick the poppler update require an unstable cairo
<seb128> danigm, and cairo is stalling for a while, they should have got 1.9 stable in january and it didn't move since
 * ogra wonders if Keybuk is on vacation
<seb128> ogra: you have access to a calendar with those infos
<seb128> ogra: the said calendar says he is
<ogra> i do ?
<cjwatson> pitti: random thought - would it be worth looking at generating /usr/lib/locale/locale-archive?  it takes the syscall count of executing a trivial program (/bin/true) from 100 to 34
<pitti> cjwatson: I think we can; it'll increase the time to build/remove locales, but that's rather insignificant
<pitti> cjwatson: I actually did some boot charts with locale-archive, but I didn't get any measurable difference
<cjwatson> locale build time is a bit of a concern on low-memory systems because localedef is so memory-hungry
<pitti> shoudl just be a matter of setting ARCHIVE=yes in /usr/sbin/locale-gen
<cjwatson> what sort of increase are we talking about?  just running 'localedef --add-to-archive /usr/lib/locale/*' doesn't seem to take too long here
<pitti> and cleaning up the unarchived ones in postinst
<cjwatson> I was wondering if there were compatibility implications; I seem to recall the odd bug when the broken-out dirs were missing
<pitti> cjwatson: ah, good; removing a locale used to require rebuilding all other ones, but as I said that should not be a common use case
<pitti> cjwatson: I have that running in a VM for some days, but I didn't test it extensively; just standard desktop bits
<pitti> cjwatson: so perhaps we should switch it early in maverick for testing?
<cjwatson> --delete-from-archive seems to take negligible time
<pitti> cool
<pitti> seems that didn't exist back then (in belocs age)
<cjwatson> I suspect it doesn't make a huge boot difference because everything is LANG=C
<cjwatson> it's only once you reach a session that it starts making any difference at all
<pitti> the desktop bits do use the locale, though
<pitti> right
<pitti> and I didn't notice any difference there
<cjwatson> should we have *only* locale-archive, or the broken-out dirs as well?
<pitti> but still, it's fewer syscalls
<pitti> cjwatson: they do take a nontrivial amount of space, so I'd vote for either-or, not both
<pitti> Debian has used locale-archive only forever, I think
<pitti> (and Fedora, too)
<cjwatson> ok, if you're comfortable with either-or then I am too
<cjwatson> shall I file a bug somewhere?
<pitti> cjwatson: against langpack-locales, I guess
<cjwatson> shall I just paste this conversation?
<pitti> sure
<pitti> I don't know whether I'll have time to implement logic to use --delete-from-archive (since I only have limited time this cycle), but using archive in general sounds easy
<cjwatson> done, bug 591676
<ubottu> Launchpad bug 591676 in langpack-locales (Ubuntu) "switch locale-gen to ARCHIVE=yes" [Undecided,New] https://launchpad.net/bugs/591676
<cjwatson> if you need me to do part of it then feel free to lob it over
<pitti> ok, thanks
<didrocks> cjwatson: hey, did you apply the same changes from the desktop seed to the netbook seed (seeing one of your commit on 2010-06-01) or should I check?
<cjwatson> didrocks: I don't remember - probably best to check
<didrocks> cjwatson: ok, thanks, I will :)
<ItalicBold> hi all, I heard sysv init is being replaced by another method in the future with ubuntu, can anyone advise what this is so i can look it up further?
<stanley_robertso> hi all
<stanley_robertso> iam new to this ubuntu stuff and going through the ubuntu wiki page
<stanley_robertso> Want to contribute as a developer.... Any suggestions/pointers in that direction would be of great help
<micahg> stanley_robertso: have you seen this wiki page: https://wiki.ubuntu.com/UbuntuDevelopment/
<apw> ItalicBold, that sounds like upstart
<ItalicBold> apw: ta
<stanley_robertso> yes micahg .. iwent through it.. but could not get a sgtarting point
<stanley_robertso> *starting
<didrocks> pitti: can I refresh a lucid metapackage from a maverick machine? Don't know how germinate works on that kind of setup
<micahg> stanley_robertso: you can fix bugs and/or work on build failures
<pitti> didrocks: sure, it downloads everything it needs by itself
<pitti> didrocks: there's a .cfg file which defines the release
<didrocks> pitti: ok, I was wondering about checking packages that are in main and so on depending on the apt cache, but it's done in a smart way, sweet :)
<didrocks> pitti: thanks
<pitti> didrocks: yes, it downloads all seed branches and Packages.gz indexes by itself
<didrocks> pitti: that seemsâ¦ way safer than relying on something local, thanks for the anwser, better to ask before regretting :-)
 * popey wonders if cjwatson could please let my mail to ubuntu-devel mailing list through
<pitti> didrocks: why do we need bug 588723 in netbook-meta as well? the bug just talks about ubuntu
<ubottu> Launchpad bug 588723 in ubuntu-meta (Ubuntu Lucid) "kubuntu-desktop / kubuntu-netbook / ubuntu-netbook should Depends ttf-liberation due to poor font fallback otherwise" [Undecided,Triaged] https://launchpad.net/bugs/588723
<didrocks> pitti: it's already fixed in ubuntu-meta, I guess the report was for netbook-meta
<didrocks> changing affected package
<pitti> ah, indeed; but still, pointing out why it's necessary for netbook would be nice
<pitti> or giving a test case why/where the current one looks bad
<pitti> didrocks: mind that the first point release will need to fit into a CD image again
<didrocks> pitti: it's ccheney who pinged about this issue, I think he's more aware about a real testcase than I
<didrocks> pitti: yeah, I'll have a look at CD size then, that's why I'm doing that now
<didrocks> ccheney: if you can provide a testcase, that will be good
<cjwatson> popey: done
<popey> cjwatson: thanks
<didrocks> pitti: I'll soon have a document using a New Times Roman font for testing if the ttf-liberation font is rendering it better than the default. If you do an apt-cache show ttf-liberation, you will see that this package is included in almost all seed already
<pitti> didrocks: right, noted
<didrocks> pitti: ok, added a testcase
<mpt> kees, hi
<kees> hello mpt
<mpt> kees, that grep of the archive you did for gtk_status_icon, could you please do the same for use of either KSystemTrayIcon or QSystemTrayIcon?
<mpt> kees, I guess you could make it much quicker by looking only in packages that depend on Qt
<kees> mpt: sure; which packae specifically would indicate a qt dep?
<JontheEchidna> kees: libqtgui4, since qsystemtrayicon is in the QtGui module
<mpt> kees, either libqtgui4 or kdelibs5 [sic]
<JontheEchidna> ^in maverick kdelibs5 was split up, and the appropriate kde library is now libkdeui5
<seb128> kees, so it's SystemTrayIcon in rdepends for libkdeui5 and libqtgui4 I guess
<kees> JontheEchidna, mpt: cool. i'll get it kicked off
<seb128> kees, thanks
<mpt> thanks kees
<kees> seb128: no problem
<mpt> and thanks JontheEchidna :-)
<JontheEchidna> yup, no prob
<agutierr> hello, someone usings 10.04 preseeds?
<agutierr> Is there any way to see packages sources during ubuntu install (on busybox)?
<ccheney> didrocks: hi
<didrocks> ccheney: hey
<didrocks> ccheney: I've added info on the bug report concerning the ttf-liberation font, do not hesitate to correct it :)
<ccheney> didrocks: ok will take a look
<didrocks> ccheney: thanks
<ccheney> didrocks: yea your comment looks correct
<didrocks> ccheney: sweet, thanks
<ccheney> didrocks: i think this would occur with pdf viewing as well, so not just in the OOo case
<ccheney> didrocks: at least for pdf's where the fonts aren't embedded
<didrocks> ccheney: can you add a comment about that?
<ccheney> didrocks: ok just followed up
<didrocks> ccheney: seems fine, thanks
<nigelb> Is there a way to know if a package has an apport hook without installing or looking into the source?
<pitti> nigelb: check file list on packages.u.c.?
<nigelb> pitti: err file list? or dependency list?
<pitti> nigelb: file list (/usr/share/apport/package-hooks/*)
<pitti> it's got nothing to do with dependencies
<nigelb> pitti: I'll tell you my problem.  I hvae a list of 1000 packages in descending order of number of bugs filed, I have to filter them for pckages wihtout apport hook so I can lead an activity on writing the hooks.  Any easy way to do the entire thing in one go?
<nigelb> (number of bugs filed for each month - I have data for 2 months)
<pitti> nigelb: http://archive.ubuntu.com/ubuntu/dists/maverick/Contents-i386.gz is your friend, I think
<pitti> you can grep it for ^usr/share/apport-package-hooks/.*/$PKGNAME$
<nigelb> oh, yay!
<pitti> nigelb: caveat: those are binary package names, not source
<pitti> but with some grep-dctrl magic this is easy to map
<nigelb> pitti: ok, I'm going to have to do a lot of work, but still worth if you ask me.  Better than apt-get x1000
<nigelb> Thank You!
<pitti> yep, Contents.gz gets the heavy lifting
<pitti> nigelb: I'd suggest to write a script which wgets contents.gz and all Packages.gz, and iterate over all Package: to check if it's got an apport hook
<pitti> nigelb: then this can spit out a list of packages without hooks, and you could even cron that somewhere
<pitti> nigelb: but you certainly don't want to look at 1000 packages?
<jpds> I suggest downloading said files off the user's mirror in sources.list to balance out the load.
<pitti> seems like adding sensible and well thought-out package hooks to the top ten is better than adding minimal ones to 50 just to make the stats look better?
<nigelb> pitti: I'm not sure how to go about all that you've said, but one step at a time.  when I get stuck I'll ask here.  I'm sure someone will know
<nigelb> Yes, I'll probably only look at ones with 30+ bugs
 * pitti dinner &
<SpamapS> anybody know what the policy would be on a package that contains a sources.list.d file pointing to a set of "blessed" PPA's? Would such a thing ever be acceptable in main?
<nigelb> oh, wait.  I have to hug brian.  He got it sorted on the list he gave me :)
<ScottK> SpamapS: No.
<ScottK> SpamapS: Such a thing did get through once and it got reverted before release.
<SpamapS> ScottK: how are the updates to things like mozilla being done?
<ScottK> SpamapS: In the normal -updates or -security pockets.
<SpamapS> ScottK: ah. We're trying to figure out how to keep up with projects like Cassandra and Hadoop on the server side, where the upstreams are releasing and deprecating old releases faster than 6 months.
<ScottK> SpamapS: You need an exception from the tech board for this.
<cjwatson> mvo: would it be useful for --print-uris to print URIs useful for other applications, rather than mirror:// URIs which can only be understood by apt?
<SpamapS> ScottK: yeah I think we're trying to make sure we gather enough information to ask for something reasonable once we know what we want. :)
<mvo> cjwatson: yes, absolutely
<cjwatson> want a bug?
<mvo> a bug is fine, otherwise I will just make a note
<ScottK> SpamapS: https://wiki.ubuntu.com/ClamavUpdates is an example of one that got approved.
<SpamapS> ScottK: That makes sense. :) I'm hesitant to relate this issue to clamav though. For instance, Cassandra (a distributed database engine) releases binaries at almost the same clip (4-6 times per year), the software itself is far less useful for most users.. so I am not sure its worth as much attention as clamav warrants.
<SpamapS> s/binaries/major releases/
<ScottK> SpamapS: You'd have to have your own rationale.
<ScottK> I provide the example to give you an idea of the type of documentation needed.
<ScottK> Particularly the issues around package qualification and testing.
<SpamapS> ScottK: at this point, I think its just going to have to be a team-hosted PPA that people can trust.
<SpamapS> ScottK: I really do appreciate the example. :)
<kees> seb128: http://people.canonical.com/~kees/search-qt-systemtray.txt
<seb128> jcastro, ^
<seb128> kees, thanks!
<kees> seb128: welcome!
<kees> 108 hits fwiw
<jcastro> ta!
<kees> where do the stdout and stderr of upstart jobs go?
<cjwatson> kees: man 5 init /console
<cjwatson> (so by default, /dev/null)
<kees> cjwatson: well that's kinda suboptimal.  it should go somewhere in /var/log
<cjwatson> plymouth, perhaps
<kees> plymouth stops running after a certain point.
<cjwatson> mm
<cjwatson> still, it should tie into that while plymouth is running
<kees> sure, that's fine by me, but I'd like to be able to find my stdout/stderr somewhere.  perhaps if I run "start" from a command line it could go there...
<saycheeze> any of you guys not AFK? haha
<saycheeze> damn, guess not
<CynthiaG> saycheeze: hi
<saycheeze> ahh Hi, Cynthia! How are you?
<CynthiaG> If you have a question to ask, don't ask if you can ask it; just do :)
<saycheeze> haha Well I do!
<saycheeze> This thread I posted yesterday pretty much sums it up.. http://ubuntuforums.org/showpost.php?p=9432432&postcount=1
<CynthiaG> not so bad, not so good; I'm trying to understand what "make a unit test, but don't make a test file" means, for a program that has image rendering as its test
<saycheeze> I just wanted to get some answers straight for the source
<saycheeze> haha I hear ya. Well, at least you're alive I guess! :)
<Chipzz> saycheeze: /join #ubuntu-server I would say
<CynthiaG> well, I'm not a real Ubuntu developer, like a core developer, so I can't answer your calling out about your experience
<saycheeze> Thanks guys. I've read through the Wiki stuff but I'm wanting to actually talk it out with someone
<Chipzz> kees: I wonder if having it go to a file even makes sense (in a way)
<saycheeze> I'll stick around here but I'm about to join the server channel as well
<Chipzz> kees: since upstart jobs run in parallel, you would need some kind of mechanism to order the output
<CynthiaG> however, what you can do is hang out around here and answer requests for packaging, handle bugs with patches available to review on Launchpad (those bugs have patch files in them, or the tag 'patch'), have several USB drives and CD-Rewritables ready for testing ISOs and USB images of Ubuntu builds, have a few computers ready or one beefy computer + VMs to test bugs
<Chipzz> or you might end up with half lines of process' A output intermangled with lines of process' B output
<saycheeze> Ahh gotcha. Yep, I've got a few PCs I can use and VMWare running on 3 boxes so that shouldn't be an issue
<CynthiaG> Some bugs are hardware-specific, like the Broadcom wireless bugs and modemmanager + Huawei modems cropping up recently, so you might not be able to test everything, but that's what the rest of the community is for
<saycheeze> Yeah, I gotcha. Alright, well that's a good start! haha
<ogasawara> superm1: wanted to get your comments on a kernel patch of yours we've been carrying.  do you prefer I use your @dell.com or @ubuntu.com email address?
<superm1> ogasawara, i have a feeling i know what patch you're referring to, @dell.com is better
<CynthiaG> [me @ saycheeze]+  You also said you would need to get up to speed on open source development; here are some tools you need: 'patch' (man patch, look at tutorials of the patch tool), 'bzr' (#bzr, #launchpad on this network), 'git', 'svn', a text editor (you should be familiar with that), and getting familiar with how bug trackers work, Ubuntu being based on Debian you'll need to know how to forward bugs to Debian etc. And finally there's #ubuntu-packag
<CynthiaG> ing
<CynthiaG> + sorry, truncated. #ubuntu-packaging
<smoser> james_w, or anyone, have an idea how i could convert something (cloud-init) that was not a native package into a native package ?
<saycheeze> Ahh gotcha. Yep, I went ahead and grabbed everything yesterday. Thanks! I'm just trying to figure out where to start after that, ya know?
<ScottK> smoser: What are you trying to do that?
<CynthiaG> Start by triaging bugs on Launchpad, testing them out, seeing if they occur on your systems, trying to find out why. The natural next step will be to delve into the code to see what's doing it. While you may not be able to change the code like you want at first, you'll get valuable experience in reading others' code. Then you can package patches, and finally be a coder yourself. The steps in-between are kinda cloudy to me. :)
<smoser> ScottK, because i'm the upstream developer and I don't see a lot of value in maintaining a release tarballs and separate debian packaging branch.
<saycheeze> Haha It's all a bit cloudy to me ATM, but I think it's starting to get a little bit clearer
<ScottK> smoser: So every time you change something in the packaging you're good with doing a new upstream release?
<kees> Chipzz: right, that's what plymouth should be doing.  but without plymouth, it should still go *somewhere*
<kees> I will bug Keybuk about it :)
<saycheeze> I'm going to check out the documentation and everything one more time, I'll stop back by in a bit. Thanks for the help Cynthia.
<smoser> ScottK, i'm not sure i understand.  I basically dont see a reason to make upstream releases. at this point the package is sufficiently ubuntu specific (dependent on certain boot characteristics).
<CynthiaG> You're welcome, and thanks in advance for the help you're going to be providing to Ubuntu :)
<ScottK> smoser: With a native package there's no distinction between upstream and Ubuntu releases, whereas with non-native you can have revisions of upstream releases separately.  Unless the package will only ever be useful on Ubuntu, it's probably better to leave it non-native.
<saycheeze> My pleasure!
<ScottK> If you want to make it native, make a new version with no "-" in the version number.
<smoser> i'm generally aware of what a native package is. i was only wondering if there was any bzr magic that i would have to revert due to previous use of merge-upstream
<ScottK> No idea about the bzr implications.
<ScottK> For the packaging bit, you just need to not have a dash in the version.
<kees> oh, neat.  "dpkg-dev provides a new script called dpkg-mergechangelogs"
<kees> double-neat.  "dpkg-dev provides a new script called dpkg-buildflags"
<slangasek> kees: yep, now we just need dpkg-mergechangelogs integrated into bzr-builddeb :)
<ajmitch> it certainly helps in doing those merges without using bzr
<jcolei64> lamont: hello sir... im looking for a packages.ubuntu.com for ia64.. does that exist?
<offy> I'm working on modifying gnome-terminal 2.3 but I can't find where the username@host file is
<CynthiaG> offy: you mean the file in which the prompt is set to username@host? the file defining the username? or the file defining the host?
<offy> prompt
<cjwatson> jcolei64: there's a contact address at the bottom of http://packages.ubuntu.com/
<CynthiaG> offy: that's in .bashrc, the line setting PS1=
<cjwatson> or /etc/profile
<CynthiaG> or you may want to look in the process' environment from within gnome-terminal and grab the value of PS1
<CynthiaG> but I don't know about how reliable that is
<offy> well, i'm trying to add a string to display infront of the prompt
<offy> oh, .bashrc can do that
<offy> Thank you
<jcolei64> cjwatson: well, im looking to see if ubuntu ports has a searchable package database via web (similar to packages.ubuntu.com)
<cjwatson> jcolei64: https://launchpad.net/ubuntu/
<cjwatson> not the same interface, but it should have pretty much all the information, aside from maybe Contents files searching
<cjwatson> jcolei64: anyway, what I'm saying is that if you want packages.ubuntu.com to work for ports, it's probably just a matter of mailing the contact address at the bottom of its front page
<jcolei64> cjwatson: thanks.. for example, im looking to see which ubuntu releases have qemu for ia64 (and the qemu versions)
<olmari> hello... I know mine opinion won't propably weigh much but I'd still like to say...
<olmari> that please, no CSD... that's in essential
<olmari> instead focus on improving window decorator and/or manager to make it happend what is meant to be done with CSD
<olmari> this is just an (advanced??) user opinion, but still...
<olmari> afaik CSD isn't something that REALLY would be the answer.. it's rather circumventing the issues of GTK and/or rest of the subsystem flaws...
<olmari> now otherwise I am not by any means undermining general ubuntu development, but with Client Side Decoration I really think it's not right direction
<olmari> so... please take a note from mine humble opinion too :)
<CynthiaG> I'm not really an Ubuntu dev, but I can see the bad things that having each application draw its own decorations would give. Mainly, each application developer would be reinventing the wheel, possibly hindering localisation (by e.g. not supporting multi-byte characters or UTF-8 in the decorations) along the way
<olmari> CynthiaG: indeed... and more generally, I think CSD would be circumventing flaws of backend by bad way..
<gord> CynthiaG, thats not how CSD works. all the decoration drawing is still handled globally, but instead of metacity or compiz or mutter drawing the window decoration, its drawn in the gtk window
<CynthiaG> I thought CSD was akin to how programs in Windows can draw their own title bar if they're not happy with what Windows gives them
<olmari> gord: but is it still a GOOD way to do things?
<gord> CynthiaG, they can if they want, chromium will prolly end up doing that. but 99.9999% of apps won't
<CynthiaG> gord, true
<gord> olmari, yup, it is :) lots of benefits and it lets window managers concentrate on what they should be doing, ala: managing the windows. rather than having to do trivial things like draw pretty things on the screen
<james_w> smoser: you can set the config to be explicit that it is native.
<james_w> echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
<olmari> gord: but does it work on every "place"?
<gord> no new tech works flawlessly from the get-go olmari, that is why bug reports and patches are so vital. there is a lot of time left to get it right
<olmari> gord: I'm still not sure that CSD is the real way to go... but I'm all in for 'turnaround' :p
#ubuntu-devel 2010-06-10
<JontheEchidna> CSD will actually prevent window managers from effectively managing windows: http://blog.martin-graesslin.com/blog/2010/05/technical-limitations-of-client-side-decorations/
<RAOF> Well, unless you're sensible and extend the EWMH spec.
<RAOF> It'll only prevent window managers which don't understand CSD from managing windows, and CSD will only be turned on when the WM says âhey, I support CSDâ!
<JontheEchidna> This thread is also a good read: https://lists.launchpad.net/ayatana/msg02576.html
<olmari> so... what inherently would be the _profit_ from CSD?
<RAOF> Making it easier for applications to do interesting things with the decorations while remaining coherent with the rest of the desktop.
<olmari> RAOF: but why not make window decorator and/or rest of subsystem better instead of "show anything you want and break compliance in the way"?
<olmari> now I'm not saying rewamping, say, GTK would be easy task butwhen it has been
<RAOF> Applications can *already* âshow anything you want and break complianceâ - see chromium and xmms, for examples.
<RAOF> CSD allows them to show anything they want and *not* break compliance.
<olmari> RAOF: why not make window decorator (and/or related subsystems) work more better?
<RAOF> Because then you're still left with two theming engines which need to cooperate, rather than one.
<RAOF> I mean, you can go one of two ways - you can extend the window manager so that application and window manager themes can be better integrated, or you can extend the application themes to also draw the window theme.
<slangasek> because you would still have two separate processes handling the rendering of the window decorations vs. the application, and that's always going to put some (artificial) limits on what you can do
<slangasek> the classic example is setting an alpha channel for the window; but in general any compositing that has to be coordinated across drawing regions managed by two different processes is going to give Problems
<olmari> wouldn't making a decorator "more flexible" be better solution than "let the app draw whaeva"
<slangasek> s/processes/X clients/, that is
<RAOF> olmari: Why?
<olmari> RAOF: afaik, more coherent way to draw windows, rather than a app confined "space" to do SOME stuff it may like...
<RAOF> What's more coherent about having two separate processes draw different parts of the window?
<RAOF> Apps that want to do crazy things _already_ can do crazy things - xmms and chromium for two examples - they just can't do them in a way which integrates nicely.
<slangasek> olmari: a) we've already answered why it's necessary, you're just repeating yourself b) it's always been possible for applications to declare themselves "unmanaged" anyway and avoid getting window decorations; the point of CSD is to do it *consistently* and in coordination with the WM instead of ad-hoc
<olmari> RAOF: they do that "on their own" because there is no "window decorator way" to do it?
<olmari> slangasek: well... that's first reasonable argument I've heard s9 far :)
<olmari> still I'd like more to way of telling window decorator that "I wanna fancy tab with earth moving wrong way as IE in there" rather than "gimme sÃ¥ace to draw bubkiss I want in that area" :p
<RAOF> So now every interesting feature you want to implement in your app's decoration requires you to (a) add a new WM spec, then (b) get the WM to implement it?
<olmari> now... as said I'm no developer, I might not understand all of the aspects involved.. but still it sounds like most best thin in long term would be to improve window decorator and/or related stuff instad of "give prgram a area that doesn't follow specs and let it draw whaeva it wants"
<olmari> RAOF: not directly that way either (your a and/or b)
<slangasek> the more fancy you get in the window manager protocol, the more the interprocess communication would become a bottleneck
<RAOF> I note that Sam Spilsbury's post in the ayatana mailing list appears to be essentially equivalent to CSD - you draw the app at 0,0 in the window and trust that it doesn't draw over the rest of the decorations, so it can draw whatever it wants.
<RAOF> Well, actually it has all of olmari's objections but without some features that CSD allow.
<RAOF> Wow, xserver-xorg-video-savage is unloved.
<olmari> RAOF: does CSD allow for example that "kill app" question when dead app
<RAOF> Sure, with a WM hint extension.
<olmari> RAOF: hmm.. okay... is that "hint" a standard? I mean does it work allways? as in "any dead app in ubuntu" as is currently
<RAOF> I don't think the hint is a standard yet.
<olmari> mm well.. then I hope it will be as in CSD will be "normal"
<olmari> don't get me wrong... I'm all in for improvement, but we do need a really standard way of doing _at least_ what we are doing now...
<RAOF> CSD isn't going to suddenly make unicorns dance along your decorations.  It's going to look almost exactly the same as now.
<slangasek> olmari: only applications using a toolkit that implements CSD would have the application-provided decorations, and only when the WM supports CSD, and the toolkit implementation would be expected to use that WM hint
<slangasek> anything else is a (trivial) bug
<olmari> slangasek: well.. would that window then be, say, "wobly"?
<RAOF> Yes
<RAOF> olmari: In *exactly* the same way that the rest of the window is wobbly.
<RAOF> olmari: With the added benefit that there's not an annoying aliased line between the titlebar and the rest of the app.
<slangasek> right :)
<RAOF> In fact, isn't the radience theme in Maverick *already* using CSD?
<olmari> hmm... I can 'accept' CSD as in when it provides benefit... and TNH, slangasek is pretty convincing actually
<RAOF> He's a convincing dude.
<RAOF> :)
<olmari> TNH = TBH
<olmari> still I "need" to ask... is it window decorator failure that no such thing is possible "as is" nowadays
<olmari> personally (most OSS peoples hate me because of this) I like Opera 10.6 (or so) way or drawing windows in Windows
<olmari> all in for opensource to draw similar things, if working any good
<olmari> now, slangasek has really said some convincing arguments, most deeply I jsut hope there will be a standard way to do things
<CynthiaG> While that may be true, if Opera's buttons are any good and make sense, there still remains the issue of customisation, because Ubuntu's theme in Lucid+ moves buttons to minimise, close and maximise a window to the left
<RAOF> CynthiaG: And?
<CynthiaG> I'm all in favor of an "area" like the "close" area that the application can extend and draw icons onto
<CynthiaG> RAOF: Do you know how Windows applications that need custom title-bar drawing do so?
<olmari> CynthiaG: opera dev already doesn't care about buttons or ubuntu themes "as is"... I mean that part works at least in dev-version of opera
<RAOF> CynthiaG: No.  It's been ages since I touched the Win32 API
<CynthiaG> RAOF: The application draws on the "non-client" portion of the window. In Windows XP, if done carelessly, it can revert the window to the classic theme. In Vista, it reverts the window to the non-Aero theme without question.
<olmari> CynthiaG: opera "next" version already drops need of QT
<CynthiaG> But the problem is that the application needs to perform all sorts of calculations of title bar widths and heights, button widths and heights (if it doesn't want to overwrite the buttons)
<olmari> I like opera in windows that tabs are drawn in the "title bar" or such
<CynthiaG> I'm not up to speed on the proposals in Ubuntu; would the CSD proposal already be like an 'area' of the title bar that the application can draw onto, without needing to know about the order of the buttons and things?
<olmari> but I like a standard way to do stuff in linux too... now.. if CSD _is_ the way to do it, then okay, bring it on, but if it instead is to more like need of improve GK and such, then bring that too ;)
<RAOF> CynthiaG: Because *all* the decorations, including the buttons, are being drawn by the toolkit it's trivial to do that.
<CynthiaG> Ah. Not so bad then.
<banished> What are the chances that we'll ever see cdrtools in ubuntu again?
<un214> what happened to it in the first place?
<banished> it got replaced by wodim, which is rather dead and buggy
<un214> the cdrecord main page carries a warning do not use the debian packages
<banished> since it does not contain the original software but a fork
<RAOF> As soon as cdrtools is distributable by us it can come back into the archive.
<banished> wel, technically you already distribute it via ppa ;-)
<un214> the code is under OSI licences, plain and simple
<un214> and in fact it is wodim that is violating the licence
<LaserJock> I thought the Technical Board already discussed it and decided it wasn't OK for Ubuntu
<un214> banished: where's the ppa for the original cdrtools
<RAOF> LaserJock: Yes.  As has debian-legal, and fedora-legal :)
<banished> un214: https://launchpad.net/~brandonsnider/+archive/cdrtools and https://launchpad.net/~ubuntu-burning/+archive/ppa
<un214> and its stunts like this one that drive me to not use do-release-upgrade
<banished> suse does, too: http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/i586/
<jcastro> stunts?
<un214> you know full well do-release-upgrade will override any outside packages with ubuntu ones
<ScottK> un214: That's not exactly how it works.
<un214> it happened to me when I had a local version of a package -- do-release-upgrade replaced it
<ScottK> It will disable any outside repositories and then upgrade packages to the newest version.
<ScottK> It doesn't matter where the old version came from.
<un214> ScottK: yeah, that's the mistake
<ScottK> There are ways to override it.
<jcastro> that's not a stunt, it's designed to do that.
<RAOF> For those still interested in why cdrtools isn't in Ubuntu, here's the Debian removal bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109
<ubottu> Debian bug 377109 in ftp.debian.org "RM: cdrtools -- RoM: non-free, license problems" [Serious,Open]
<un214> how about the fact that's just plain old wrong
<ScottK> un214: It's not.  That's the way the package management system works.  Apt or aptitude would do the same.
<un214> ScottK: i tested apt-get upgrade beforehand. If do-release-upgrade hadn't tampered with the sources.list the package would not have been replaced
<ScottK> Ah.  I see.
<un214> there was a newer version in my local repository
<ScottK> There is a way to include additional repositories in the ones it thinks are OK to leave in place.
<un214> how about we just leave all of them and let apt bail if it can't resolve a conflict rather than do-release-upgrade going out of its way to remove conflicts (yes I read the code after seeing it do it)
<LaserJock> you can always just not use do-release-upgrade
<banished> RAOF: still opinions vary if this is a valid concern - e.g. suse, solaris and ark have them included. Ubuntu also includes packages that debian rejects for simmilar reasons, like the firefox or some audio codecs
<ScottK> LaserJock: That's where this started.
<RAOF> Because apt bailing during an uprade is unfriendly.
<un214> and a non-booting system is more unfriendly
<un214> that's why I overwrote the package
<RAOF> banished: No, those are different issues.  I don't believe we have any packages that Debian have rejected due to copyright problems.  Firefox isn't in Debian over trademark issues, and codecs aren't in there because of differing policies regarding patents.
<RAOF> banished: If you'd like to see the issue done to death, http://www.mail-archive.com/fedora-legal-list@redhat.com/msg00463.html is a relatively recent Fedora-legal discussion.
<un214> after seeing obviously unnecessary packages that essential ones depend on it's time somebody forked ubuntu to put an end to this madness
<RAOF> un214: I'm guessing you mean plymouth?
<un214> yes. chmod -x /sbin/plymouthd still results in a booting system
<RAOF> Well, as long as you don't need any multiplexing, obviously.
<un214> what are you talking about?
<banished> RAOF: actually in this post jÃ¶rg is remarking licence issues with cdrkit
<RAOF> banished: Right.  The rest of the thread is fedora-legal explaining their rationale for not shipping cdrtools because the CDDL is incompatible with the GPL.
<RAOF> Well, and fedora-legal asking for specifics about what JÃ¶rg thinks cdrkit infringes.
<ScottK> un214: plymouth also handles IO serialization in addition to display things.
<RAOF> un214: Which is necessary in a parallel boot situation.
<un214> I can't imagine what mistakes of architecture would make such a beast necessary
<RAOF> un214: You're not aware of various attempts to parallelise the boot process for speed?  They've been going on for many years.
<ion> un214: chmod -x /usr/sbin/cupsd also results in a booting system. That is, until you need to print something. :-P
<un214> yeah and I should expect to boot without that package but trying to apt-get remove plymouth decides to remove e2fsprogs
<ion> Why would you want to remove the way for startup programs to interact with the user?
<un214> I had to break it anyway -- bad drivers
<un214> you're probably wondering why I do many crazy things
<un214> truth is I don't have time to figure what they did to X architecture these days so I can rebuild kernel and X server to get the right drivers for my system
<un214> and then run the whole rest of ubuntu from a chroot jail with no kernel or X server packages installed
<stanley_robertso> hi all
<stanley_robertso> anyone online ?
<stanley_robertso> need help in ubuntu
<CynthiaG> this is not a support channel, please see #ubuntu for this
<slangasek> RAOF: no, firefox isn't in Debian because of copyright issues, not trademark issues
<slangasek> RAOF: the copyright license on the artwork is restrictive; Mozilla maintains that this is ok because it's needed to protect trademark-like rights, but that still doesn't pass muster with Debian
<RAOF> Aah.  _That's_ where I'm getting confused.
<pitti> Good morning
<ajmitch> good morning pitti
<CynthiaG> Good morning!
<dholbach> good morning
<CynthiaG> What's a good benchmark of seek distance reduction for the Ubuntu LiveCD?
<CynthiaG> Recording the CD-ROM drive's seeking noise with one of those dictaphone things they market to university students?
<CynthiaG> (or equivalent)
<spm> CynthiaG: wag'ing; but could you proxy that by benching times to do "X"? where X may be sheer startup of common tools?
<CynthiaG> wag'ing?
<spm> wild guessing
<CynthiaG> to me waging is like wagging a dog's tai-- oh
<spm> I leave the 'a' undefined :-)
<CynthiaG> spm: I did that for cjwatson's improvement of file placement within the .iso
<CynthiaG> shall I do it again for the file placement within the .squashfs then?
<ogra> there was support for sort lists in unionfs back in the days that speds up seeking inside the squashfs a lot
<ogra> but i'm not sure thats still used or supported
<CynthiaG> bug 589629
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<ogra> have a look at livecd-rootfs
<ogra> thats the wrong package
<ogra> debian-cd only cares for bootability and assembling of the iso, you want to improve the squashfs, thats created by livecd-rootfs
<apw> CynthiaG, could you perhaps use the same techniques ureadahead uses to record the informaiton during boot?
<ogra> right, but use them during build :)
<CynthiaG> [processing replies from 3 people, plus typing one]
<CynthiaG> I posted a patch to livecd-rootfs (which is marked as an affected package too) to use a broad list of folders used in order at boot; read that bug report, it's an interesting read I think. Also look at the CD layout image, you might have a laugh
<CynthiaG> ogra: per above, I also reported it against  livecd-rootfs
<ogra> ah, i didnt open the bug
<ogra> silly me trusted the bot :)
<CynthiaG> apw: that would only work if the build server has access to a VM of sorts to boot the ISO into and deconstruct+reconstruct the filesystem after reading-ahead
<CynthiaG> apw (+) Unless it's remade manually before "release" ISO builds (i.e. Lucid RC, Lucid release, Maverick RC, Maverick release...)
<apw> CynthiaG, i am assuming the files that are read and the order is probabally relativly static over time, might be something we can at least get an approximation for ... just an idea though
<CynthiaG> my file order list for the squashfs just relies on the Linux kernel booting first, and the init scripts being read next, and then the X server starting, and etc.
<CynthiaG> so /bin/, /lib/modules and /etc/ are first
<CynthiaG> and /usr/share/doc is last
<CynthiaG> + src, include
<CynthiaG> so then, at least the seeks are over less of the CD
<ogra> apw, i think thats what tollef initially did with the implementation, we had a .sort file
<ogra> but it was dropped at some point and required patches to the unionfs module to even generate it iirc
<apw> ogra, yeah i suspect the techniques that ftrace let us do without modification might allow that to be reinstated
<CynthiaG> livecd-rootfs currently generates the squashfs file using mksquashfs and its sort file option
<ogra> wll, the url mentioned in the squashsort variable is long dead
<CynthiaG> yeah it's dead, that patch in the bug report instated an inline list
<ogra> the "using a blank list" condition is the default atm
<CynthiaG> So then, shall I benchmark the CD using a blank sort list and using the sort list from that bug? And then you can add your input
<ogra> did you do speed measurements i.e. with bootchart installed ?
<CynthiaG> Using a readahead-like program would be best I agree, but can this be automated well from a chroot?
<ogra> talk to JamieBennett once he is around, he did such benchmarks in lucid
<CynthiaG> ogra/bootchart: no; this needs to be installed in the CD per /wiki/LiveCDCustomization right?
<ogra> CynthiaG, well, you could just ask that we include it in the daily builds by default during development ;)
<CynthiaG> Ah :) Then I shall do exactly this!
<CynthiaG> Could you please include bootchart by default in development builds of the LiveCD?
<ogra> indeed it will slow down booting a bit i guess
<ogra> file a bug ;)
<CynthiaG> Aw :P
<CynthiaG> Against what?
<ogra> hmm
<ogra> good question, its essentially a seed change so probably against ubuntu-meta
<CynthiaG> Easier said than done hm? :D I'd file it against Ubuntu itself, but that's not recommended
<CynthiaG> I could also deconstruct+reconstruct the CD using LiveCDCustomization, unless other people would see benefits from including bootchart
<CynthiaG> I've done it to test the PNG/SVG/XML optimisations I put forth on -devel-discuss, so it's not a problem.
<ogra> right, dont forget that you need to respin the initramfs for bootchart though
<CynthiaG> Ah, thanks for the info
<CynthiaG> !info bootchart > CynthiaG
<CynthiaG> !info boot-chart > CynthiaG
<CynthiaG> Ah. JamieBennett: good <appropriate greeting for your timezone>
<JamieBennett> hey CynthiaG
<CynthiaG> It appears that you did boot speed benchmarks for Karmic and Lucid, and that you could both tell me how much faster Lucid's LiveCD is to boot, and more optimisations related to mksquashfs file sorting
<CynthiaG> Could you tell me more? I'm trying to optimise stuff for Maverick's CD, and it seems that the mksquashfs ordering was lost
<JamieBennett> CynthiaG: http://www.linuxuk.org/2010/02/ubuntu-live-cds-now-33-faster/
<CynthiaG> So it was debconf's fault I see. But there's another thing I see in the LiveCD, and it's that it has insufficient locality for seeking
<CynthiaG> JamieBennett:  http://launchpadlibrarian.net/49656420/cdrom-proposed.png  Could you look at this and tell me if you think that it will increase locality for the boot process? I actually already did this for a CD of mine (LiveCDCustomization) and saw a speed improvement + much quieter-running disc while opening programs
<JamieBennett> CynthiaG: yes, there are other improvements to be had
 * JamieBennett looks
<CynthiaG> this is part of bug 589629, in which I describe the ordering in more detail
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<CynthiaG> ignore that package, it's actually livecd-rootfs in Ubuntu
<JamieBennett> CynthiaG: from looking at that I couldn't tell TBH. You would have to try it and see the exact numbers to determine if its worth it
<CynthiaG> Ok, then I shall try it with bootchart mixed into the CD with more LiveCDCustomization
<CynthiaG> But it's awesome that Lucid was 33% faster than Karmic to boot the LiveCD
<JamieBennett> CynthiaG: the theory is sound, but the boot works in misterious ways ;)
 * ogra was rater pointing to JamieBennett because CynthiaG asked how to benchmark best :)
<JamieBennett> CynthiaG: It was closer to 35% when I finished but :)
<CynthiaG> Aye ogra :)
<JamieBennett> CynthiaG: there is a wiki page on exactly the process I used to determine the slowness, you could look at that if you need any help
<CynthiaG> I just used wall-clock time from the ISOLINUX screen to the first appearance of the Try Ubuntu 10.04 button
<CynthiaG> because I'm not acting on any single program; just on the boot sequence in general
<CynthiaG> Is that timing methodology also sound?
<JamieBennett> CynthiaG: wall clock is OK for approximations
<JamieBennett> https://wiki.ubuntu.com/ARM/ModifyCasper is how I modified the live-cd boot sequence for timestamping and for bootcharting
<CynthiaG> actually wall-clock time is just an expression, and I have a wristwatch precise to the hundredth of a second
<CynthiaG> and would that ARM page be useful for x86 anyway?
<NCommander> CynthiaG: yes
<JamieBennett> CynthiaG: yes, all the speed-up work benefitted x86 too but I was on the ARM team at the time :)
<CynthiaG> ah
<CynthiaG> JamieBennett: with all due respect, I think I'll just start wall-clock tests right away and benchmark with bootchart and timestamps etc. only if I see a non-statistically-insignificant improvement :)
<CynthiaG> I'll also have my ears listening out for my laptop's very loud CD seeks
<JamieBennett> CynthiaG: sure
<cjwatson> happy to add bootchart to the live CD for a while, up to maybe a bit before beta
<ogra> ++
<JamieBennett> cjwatson: thats what we did to the ARM live-cd last cycle, actually helped quite a bit
<CynthiaG> cjwatson: thanks - I'll use that in tomorrow's daily build if I see a sizeable improvement between these two modded Lucid LiveCDs
<CynthiaG> (took Lucid release + shuffled its files only on the .iso, then on the squashfs too)
<CynthiaG> the iso shuffling is specified to be identical on both, so I can just get the improvement from the squashfs. scientific enough, yes? and I took your improvement as part of the iso shuffling, cjwatson
<cjwatson> bootchart will of course slow down wallclock time
<CynthiaG> equally on both tests
<cjwatson> hopefully
<CynthiaG> yeah :\
<CynthiaG> I just jumped because of Ubuntu's login sound :\
<mdz> dholbach: buxy asked on ubuntu-devel who reads debian@ubuntu.com. can you confirm where that alias goes currently?
<Chipzz> pitti: are core files removed after they
<Chipzz> have been retraced by the retracer?
<pitti> Chipzz: if the retrace was successful, then yes
<Chipzz> there was a discussion on #debian-devel couple of days ago about their debugging symbols debs, and this came up as a privacy issue
<seb128> Chipzz, crash bugs are not made public by default
<Chipzz> seb128: I know
<seb128> Chipzz, some bugsquad member needs to review them and flag them as public after checking they have no private information
<seb128> ie no crashdump or informations in the stacktrace
<Chipzz> seb128: but there's still the privacy issue of storing the core dumps on launchpad, where presumably someone with access to where they're stored could access them
<Chipzz> (at least that's what I assume they were alluding too)
<seb128> Chipzz, well, when you send a dump you access that somebody will have access to it to debug
<seb128> that wouldn't make sense otheriwse
<seb128> "you accept that"
<Chipzz> errrr
<Chipzz> actually no
<seb128> so why do you send it if you think nobody will be able to receive it?
<Chipzz> because the dump is used by an automated program to resolve stack symbols
<seb128> same difference
<seb128> your password can land in clear text is that stacktrace
<seb128> is -> in
<Chipzz> which is very different from the hypothetical situation of someone abusing his privileges to access the core dump
<Chipzz> pls note that I'm not accusing anyone of doing that; but that seemed to be the concern in the discussion on #debian-devel
<seb128> well somebody will have access
<seb128> the somebody being the retracer admins
<Chipzz> yes
<seb128> I'm not sure how you can design a system where nobody will ever have access
<pitti> Chipzz: sure, that's a fundamental problem that we can't solve; we show the information in advance and ask the user to not send it if he was doing anything confidential; but I realize that this is sometimes hard to tell
<pitti> Chipzz: but for reasons like that we disable apport on stable releases, so that it's mainly developers who are exposed to this
<Chipzz> but I assume the time frame between when the core dump is uploaded, and when the retracer runs is sufficiently small to eliminate most of that concern in case the core dumps are automatically removed
<seb128> well the issue is rather whether you trust or not the retracers admin
<pitti> Chipzz: stack traces and stuff from package hooks stay, though
<seb128> but I think the concern is rather leak of infos
<seb128> not especially the crashdump themself
<seb128> ie having your password in clear in a stacktrace on the bug
<pitti> or in gconf
<Chipzz> seb128: but there's also a difference between having the password in the stacktrace, or the password previously being stored in memory, and not having been (securely) zeroed out, and the possibility of inspecting the core dump to find said password
<Chipzz> the latter could happen if the core dumps are not removed, and a retracer admin abusing his powers
<seb128> why would somebody bother to do that if the password is in clear text in the stacktrace in a bug comment?
<Chipzz> like I said, what if it isn't?
<seb128> well it seems you are concerned about a very specific corner case there
<Chipzz> s/me/some ppl in the discussion/
<seb128> ignoring the common case which is that your password will show in clear
<pitti> Chipzz: if we aren't concerned about "rescuing" failed retraces, we can change the retracer bot to always remove core dumps, not just on successful ones
<seb128> why are those people not concerned about the common password being clear case and are concerned about the corner case?
<Sarvatt> has anyone ever once seen a password in a stacktrace in the clear?
<seb128> Sarvatt, yes
<pitti> seb128: I'm not sure it's such a corner case
<seb128> quite often
<pitti> having your password in memory doesn't mean that most of the crashes go through a path with passing it around functions
<Chipzz> Sarvatt: it's not just stacktraces; say you're browsing a porn site and firefox crashes
<seb128> pitti, well I often see passwords in clear in stacktrace, I don't see why it would be less a concern than having it in the crashdump
<Chipzz> the url may be in the stacktrace too
<pitti> seb128: it's not less of a concern
<Sarvatt> really? i only look at X bugs usually and have never seen anything worse than porn in xsession-errors
<Chipzz> pitti: exactly
<seb128> pitti, it comes down to whether you trust people who have access to private bugs or not
<pitti> it's just that while we can't do much about the case wehre the pwd is in the stack trace, we can improve the case where it's not in the stacktrace, but in memory
<seb128> if you don't just don't send crashdumps on the internet
<pitti> right
<Chipzz> seb128: not just private bugs
<seb128> Chipzz, no public bugs has crashdumps
<pitti> it's the main reason why I don't ever want to see this enabled in releases
<Chipzz> also admin access to the retracer, or, which is why I asked in the first place, the case where core dumps are not removed
<Chipzz> (which they are)
<seb128> Chipzz, if you don't trust admins of a server don't use this server
<pitti> right, seb128 and me potentially have access to all reported coredumps
<seb128> Chipzz, it's true for any service
<Chipzz> 11:20 < Chipzz> s/me/some ppl in the discussion/
<seb128> Chipzz, if you don't trust google don't use gmail for your emails
<seb128> Chipzz, well "you" being whoever has concerns
<Chipzz> personally, I trust the launchpad ppl to dtrt
<seb128> Chipzz, I'm not sure what we are discussing now ;-)
<seb128> if those people don't trust the ubuntu or launchpad admins they should not send crashdumps there
<pitti> with Debian it's a trickier case
<pitti> since the BTS is absolutely not suitable for apport in various ways
<seb128> does the bts has a private bug notion?
<pitti> they could set up a bugzilla or LP instance for crashes, of course, or implement a new crash database thing
<pitti> no
<pitti> and neither a sensible way of reporting bugs
<pitti> or removing attachments
<pitti> frankly it's easier to implement a crash database from scratch than trying to implement a CrashDatabase backend for the Debian BTS :-(
<dholbach> mdz: I'm afraid I don't - I think it's jono
<stanley_robertso> hi all
<stanley_robertso> any Ubuntu developer online here ?
<BlackZ> stanley_robertso: do your question instead
<stanley_robertso> BlackZ, iam new to this ubuntu development group and want a startup for it.. need pointers.. i went through the ubuntu website.. but could not get any pointers
<stanley_robertso> Also, iam searching for command line option to upgrade my ubuntu release.. not sure how to do that
<pitti> stanley_robertso: it depends on what kind of work you want to do; https://wiki.ubuntu.com/ContributeToUbuntu is a very good start page to give you further directions
<popey> !upgrade | stanley_robertso
<ubottu> stanley_robertso: For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes - see also http://www.ubuntu.com/desktop/get-ubuntu/upgrade
<stanley_robertso> thanks pitti/ubottu
<stanley_robertso> ubottu ...the ubuntu iam working is behind a proxy.. will there be ay problem in that ?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<stanley_robertso> becaz.. when i ran the respective command for upgrade release
<stanley_robertso> the system/console just hanged
<stanley_robertso> and not progressing any further
<popey> stanley_robertso: #ubuntu is the right place for these kinds of support questions
<cjwatson> is somebody working on fixing X's installability?
<pitti> cjwatson: yes, RAOF
<cjwatson> (in maverick.)  the packages still on old ABIs appear to be: xserver-xorg-video-fbdev xserver-xorg-video-geode xserver-xorg-video-siliconmotion xserver-xorg-input-wacom
<pitti> geode and wacom were uploaded already
<cjwatson> anything I can do to help?  live CD builds have been broken for a couple of days now
<RAOF> All of which are in the build queue.
<cjwatson> ok, cool
<cjwatson> fbdev isn't
<cjwatson> oh unless you mean your private build queue
<RAOF> fbdev isn't?
<pitti> RAOF: want me to sponsor http://cooperteam.net/Packages/xserver-xorg-video-fbdev_0.4.2-2ubuntu1_source.changes ?
<RAOF> pitti: Let me check.  I thought mvo had sponsored that yesterday.
<pitti> no, just checked
<pitti> https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-fbdev/+changelog
 * pitti hovers over enter key and waits for RAOF's "go!"
<RAOF> Ah, ok.  It got rejected due to lack of .orig.tar.gz
<pitti> RAOF: ok, uploading with -sa
<pitti> [done]
<RAOF> Ta.
<cjwatson> siliconmotion also isn't in the build queue
<seb128> cjwatson, btw how did you list the ones not rebuilt yet?
<pitti> RAOF: want me to sponsor http://cooperteam.net/Packages/xserver-xorg-video-siliconmotion_1.7.4-0ubuntu1_source.changes ?
<seb128> cjwatson, I did showpkg on the virtual pkg with some sort, awk and diff for both abi version
<seb128> cjwatson, but I was wondering if there is an easy way
<RAOF> pitti: Yes, please.
<Sarvatt> it just got uploaded to experimental about 30 minutes ago
<pitti> RAOF: done
<pitti> cjwatson: ^
<cjwatson> seb128: grep-dctrl
<cjwatson> -nsPackage -FProvides xserver-xorg-video-6
<cjwatson> that kind of thing
<seb128> cjwatson, oh, seems a nice way to do it indeed, thanks
 * pitti grrs at recent javascript email viruses and deletes another metric ton of them
<nmvictor> first i wanna thank you guys for what you are doing. i think my issue is beyond ordinary support in #ubuntu so im gonna put it up for the real geeks behind ubuntu,  i get this message during boot up: [/build/buildd/linux2.6.32/drivers/rtc/htcosys.c : unable to open rtc device], whats up and how do i fix it?
<nmvictor> first i wanna thank you guys for what you are doing. i think my issue is beyond ordinary support in #ubuntu so im gonna put it up for the real geeks behind ubuntu,  i get this message during boot up: [/build/buildd/linux2.6.32/drivers/rtc/htcosys.c : unable to open rtc device], whats up and how do i fix it?
<nmvictor> please someone help with my problem up their
<lag> Does this help you: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59434
<mdz> barry: is there any prescriptive advice available for choosing names for Python modules to fit into the global module namespace?
<mdz> barry: I'm looking for something a bit more specific than PEP 8, which says roughly "short lowercase names"
<barry> mdz: not really ;)  i do think if it makes sense, start using a namespace package, e.g. zope.* or lazr.*.  what package are you trying to name?
<Q-FUNK> would anyone happen to have an answer for bug #587186 ?
<ubottu> Launchpad bug 587186 in gcc-4.4 (Ubuntu) "libc6 upgrade fails: illegal instruction" [High,Triaged] https://launchpad.net/bugs/587186
<Q-FUNK> doko asked if I could figure out exactly which instruction was illegally called, but still hasn't said how I should narrow it down.
<cjwatson> Q-FUNK: gdb should let you stop on the illegal instruction and disassemble, shouldn't it?
<cjwatson> I assume something like that is how whoever it was tracked it down to a NOPL in the first place ...
<cjwatson> (if necessary, dump core and run gdb on it elsewhere)
<Q-FUNK> cjwatson: the main problem is how to do that on a package that is in the process of being unpacked
<Q-FUNK> cjwatson: more to the point, how to do that on the package that is the lowest in the library recursiveness, namely libc6 itself.
<kido> hi everybody
<kido> I'm sorry if my english is bad because I'm french
<kido> please can you tell me where i can find the ubuntu source code? (git?, cvs?, svn?)
<dholbach> one possibility is https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource (in bzr)
<dholbach> the other one is to run        apt-get source <packagename>      in the running distro (if you're not interested in the history)
<kido> thank you :)
<arand> cjwatson: What is the rationale for removing aptitude from standard (this meaning it wont be on a normal ubuntu-standard/desktop/server install?)
<cjwatson> arand: (a) size (not inconsiderable!) (b) the original reason we included aptitude was so that the installer could use it, and I've now made it install it only when it needs it
<cjwatson> arand: and (c) it is FALSE that it won't be on a normal server install
<cjwatson> arand: since d-i's "Select and install software" stage always installs it - it's only ubiquity that doesn't - any installation performed using d-i will have aptitude
<arand> cjwatson: Ok.
<cjwatson> arand: I'm quite happy with desktop installations not having aptitude there - its usefulness doesn't justify its size, and those who can use it can quite easily install it
<cjwatson> this was part of the foundations-m-spring-cleaning specification, agreed at UDS
<arand> cjwatson: Yes, I can fully see that point, although I disagree, based on the usefulness and that for example in documentation it is often used interchangibly...
<arand> (Although that is a bug in the doc, heceforth, I guess)
<cjwatson> you're entitled to disagree, but we don't have room for luxuries in the desktop CD - it is perpetually tight on space, and this change gained us 2MB
<cjwatson> I'm prepared to bet that all that documentation can quite easily be changed to use apt-get (or, in some cases, synaptic or other desktop tools) instead
<cjwatson> and the effort involved in changing docs was why I made this change early in the release cycle
<arand> cjwatson: So the dependency of ubiquity-frontend-debconf on tasksel, which in trun depends on aptitude, which seems to have aptitude on the liveCD anyways, currently. That is something that should not be?
<cjwatson> ubiquity-frontend-debconf is not on the Ubuntu live CD
<cjwatson> it's intended only for the server CD
<cjwatson> tasksel is still winding up there somehow, and I'll need to look at that
<arand> Ah, yes, I was just following the dependency chain. but tasksel, is there indeed in the latest daily.
<cjwatson> I think that may just be a reflection of the fact that the last successful live filesystem build was on the 5th
<cjwatson> that's a short enough time after my ubuntu-meta change that it may not have stuck
<cjwatson> 'apt-cache show tasksel' on current maverick doesn't show any of the live tasks, so I think the next live filesystem build should make that go away
<cjwatson> the next one that actually works, anyway
<arand> Ah, right, well thanks for the info, although it made me a bit sad.. :)
<smoser> james_w, thanks
<sivang> how odd, hardy's subversion source pkg misses both XS-Python-Version in debian/control and debian/pyversion, how would one go about building it anyways?
<sivang> (I'm trying to rebuild with --with-ssl)
<sivang> which is lacking in the original package
<ScottK> sivang: If both are missing it will  fall back to using the list of supported versions.
<sivang> ScottK: that's what it tried to do, but it failed.
 * sivang recheks
 * ScottK guesses that isn't why it failed.  Feel free to pastebin the log.
<sivang> ScottK: the build log or the configure log?
<ScottK> sivang: wherever it failed.
<sivang> ScottK: how can I figure why it faileD? and yes, this does not look now the reason for the failure
 * ScottK has a vague recollection of trying to build with ssl around then and getting segfaults, but that may be kwallet support I'm thinking of.
<sivang> ScottK: you with for subversion?
<ScottK> sivang: Yes.
<ScottK> But it was over two years ago, so who knows.
<sivang> ScottK: I hope the hardy repo is up to shape
<sivang> we use it for some production stuff
<sivang> ScottK: ah, so it says rules clean faild
<sivang> ScottK: odd
<sivang> ScottK: could it be related to fakeroot issues?
<sivang> I did install once it yelled at me for needing it
<sivang> and I have devscripts
<ScottK> sivang: Pastebin the error and several lines before.
 * sivang does that
<sivang> ScottK: http://paste.pocoo.org/show/223946/
<ScottK> sivang: I'm going to guess you changed something in line 72 or 73 of debian/rules.
<sivang> ScottK: geez, I apologize so much. I miss a /
<sivang> for line continuation
<ScottK> sivang: No problem.
<sivang> ScottK: in configure...
<sivang> rooky's mistake
<sivang> :-)
 * sivang blushes
<sivang> ScottK: its building, thank you so much!
<ScottK> sivang: You'll also need to take care with hardy about if you want subversion 1.4 or 1.5 (which is in backports).  1.4/1/5 client and server are not interoperable.
<sivang> ScottK: we use the same versions, just need the SSL but thanks for the tip!
 * sivang tomboys this for further issues when upgrading
<sivang> ScottK: I'm out. thanks a lot.
<RoAkSoAx> pitti: I was wondering why is the .manifest-daily file of cdimage does not contain the other daily ISO's besides the Ubuntu Desktop ones?
<kees> hm, there's no https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes yet.  where's the right place to add release notes?
<arand> kees: There is https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview
<kees> arand: ah-ha thanks
<CynthiaG> posted some stopwatch results in bug 589629, I think it'll be worth the while to use cjwatson's Maverick daily build with bootchart in it
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<CynthiaG> looks like my spacing got eaten by Launchpad
<CynthiaG> it no longer looks like a table
<pitti> RoAkSoAx: hm, I don't know? so far I wasn't even aware that it exists
<didrocks> pitti: it seems there is no CD build from last Saturday, is it on purpose?
<pitti> didrocks: they kept failing on uninstallability
<pitti> first gnome, now X
<pitti> X should finally be fixes
<didrocks> pitti: oh right, the X transition, make sense :)
<pitti> s/s$/d/
<didrocks> pitti: thanks for the info :)
<Sarvatt> any chance someone could take a look at xserver-xorg-video-fbdev? it's stuck in NEW, cd's probably will still fail without it
<psusi> when is the 10.04.01 respin again?
<CynthiaG> psusi: I think it's meant to coincide with Maverick
<psusi> ohh, I thought it was only supposed to be like 2 months out
<pitti> no, it's 3 months after lucid release
<pitti> so halfway into the cycle
 * micahg thinks in july
<micahg> https://wiki.ubuntu.com/MaverickReleaseSchedule
<psusi> yea, that's about what I thought... need to try and get the dmraid fix in bug #568050 uploaded to -updates as an SRU and into the respin
<ubottu> Launchpad bug 568050 in parted (Ubuntu) "Ubuntu 10.04 can't create partition on fakeraid" [High,In progress] https://launchpad.net/bugs/568050
<pitti> Sarvatt: can do
<pitti> Sarvatt: I suppose the udeb can go to universe
<Sarvatt> not sure if anyone is planning on using it in ubuntu, its for the X11 based d-i
<pitti> well, we can still promote it later on if necessary
<pitti> I sent it to universe for now
<pitti> good night everyone!
<Sarvatt> \o/ thanks pitti, night!
<psusi> is there anything else I need to do to get the fix for bug #568050 SRU'd?  a tag perhaps?
<ubottu> Launchpad bug 568050 in parted (Ubuntu) "Ubuntu 10.04 can't create partition on fakeraid" [High,In progress] https://launchpad.net/bugs/568050
<fqh> Hi all, I found that command "hdparm -B 128 /dev/sda"  depend on gnome-power-manager. If gnome-power-manager is not running, "hdparm -B 128 /dev/sda" will not take effect. So if I close X and live only in pure-tty, I can't set 128 for /dev/sda. Is it a bug?
<netshine> hey all!
<netshine> im developing with two other guys the project "gnome-paint", i have uploaded him yesterday to launchpad.
<netshine> http://launchpad.net/gnome-paint, if someone want to look, and i think its important project, and should be considered to be default in ubuntu
<psusi> fqh: hdparm -B has nothing to do with g-p-m... it talks directly to the drive
<netshine> (instead of GIMP, that out now)
<netshine> who should i talk with about this subject.
<fqh> psusi: Yes, I think so too. But running "sudo hdparm -B 128 /dev/sda" under icewm or pure-tty , it can't take effect.  "sudo hdparm -B  /dev/sda" shows that the setting will return to 254 soon.
<psusi> fqh: let's discuss this in #ubuntu+1
<fqh> ok
<cjwatson> pitti: no no, I put the fbdev udeb in main deliberately, I just forgot to accept
<cjwatson> pitti: I'll move it back
<samgee> Hi, where can I get some hints on patching openoffice.org's source package? A big chunk of its code seems to be wrapped in a tar.bz2 file.
<CynthiaG> samgee: looks like you'll have to extract the file, it's a bzip2'ed tar archive
<CynthiaG> tar xjf FILE.tar.bz2, and 'man tar' for more information
<samgee> if I extract the tar file, make a change to its contents, wrap it back up and dpkg-buildpackage then dpkg-source complains about not being able to handle binary diffs.
<netshine> lol,  http://microsoft.co.il/ was hacked and whats hidden there? "Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at microsoft.co.il Port 80"
<netshine> :-0
<SpamapS> http://hezmatt.org/~mpalmer/blog/general/ETOOMUCHMAGIC.html
<SpamapS> haha.. best error constant ever
#ubuntu-devel 2010-06-11
<jcgs> hi, does anyone know what to do if i think i've found that a package in the repositories is unusable?
<lifeless> you should file a bug
<jcgs> i already did
<jcgs> in march
<lifeless> great
<jcgs> lifeless: i was just wondering if i could try and help get some progress on it
<lifeless> if you want to work on it, that would be great.
<jcgs> apparently there is a perfectly good package available from another repository
<jcgs> i wondered if it would be possible to do a swap
<jcgs> lifeless: i don't think it's so much a problem with the code, as the specific package available in the repositories
<RAOF> jcgs: Working out precisely what the problem is is a great first step :)
<jcgs> i've filed a bug report already, how would i go about decoding the information in that, and related bug reports
<jcgs> is there a source package available i could recompile from?
<RAOF> Yes, of course.
<RAOF> âapt-get source $PACKAGENAMEâ
<jcgs> RAOF: that generated some errors
<jcgs> apaprently public key not found
<RAOF> That's a warning, not an error.  You're good to go.
<jcgs> RAOF: where did it put it? sudo find / -name "pango-graphite" returned nothing
<RAOF> It puts it in a subdirectory of your current directory.  $PACKAGENAME-$UPSTREAM_VERSION
<RAOF> So, it's likely to be in the pango-graphite-0.9.2 directory.
<cjwatson> note that that find command returns only directory entries named exactly "pango-graphite" - you have to do a bit more to make it be a substring search
<CynthiaG> "*pango-graphite*"
<CynthiaG> what cjwatson said
<RAOF> Hm.  Looks like an interensting package, too.
<ajmitch> that package looks like a good candidate for removal
<ion> Yay, maverickâs kernel has an automatic workaround for an ACPI bug i had to work around manually in lucid. (Thermal sensor wouldnât work, thus CPU throttling wouldnât work, thus the laptop would overheat.)
<jcgs> ajmitch: why? is it beacuse it is broken?
<ajmitch> jcgs: broken, and hasn't seen an update for quite awhile in debian
<ajmitch> though it doesn't look entirely dead upstream
<jcgs> ajmitch: apparently upstream are maintaining their own ubuntu repo
<jcgs> i was wondering if someone could just swap their package into the ubuntu repositories?
<ajmitch> if it's as severwly screwed up as it looks (crashing firefox, etc), then it's possible it could be updated in lucid after being tested for a bit in maverick
<ajmitch> someone would need to spend time to do so
<ajmitch> it'd depend on whether it needs other libraries to be upgraded as well
<jcgs> erm, sorry to waste your time so much, but what do i do with the file now that i've got them
<jcgs> i seem to have two tarballs, i'm not quite sure why
<jcgs> i think i'm ok now, but when i run the configure script, it seems to want three packages that don't exist: pango pangoft2 and glib-2.0
<jcgs> these don't seem to be in the repositories
<CynthiaG> jcgs: (sudo) apt-get install libpango-dev libpangoft2-dev libglib2.0-dev
<CynthiaG> or similar names, see Synaptic or Aptitude for the real names or press Tab to check the names
<RAOF> And, for future reference, install apt-file and try âapt-file search pango.pcâ
<jcgs> CynthiaG: thanks
 * ajmitch really doesn't like tarball-in-tarball packages
 * micahg wonders what ajmitch has against firefox :P :)
<jcgs> it fails to make with error "memmove is not a member of std"
<jcgs> and adding #include <string.h> hasn't remedied the situation :(
<jcgs> aha! it meant what it said. std::memmove has become memmove
<psusi> k, so I'm reading the autoconf manual and managed to use the AC_CHECK_LIB macro to test for glib-2.0... how do I get the include path added to CFLAGS though for the glib headers?
<psusi> AC_CHECK_HEAEERS tests if it works, but doesn't seem to have a way to specify the include path
<antileet> Hi, is this the right place to ask for help with pbuilder?
<pitti> Good morning
<ddecator> morning pitti
<ajmitch> morning
<dholbach> good morning
<CynthiaG> Good morning
<ttx> pitti: could you reject etckeeper from the lucid-proposed queue ? I'll upload a better fix.
<netshine> hey all..
<pitti> ttx: *flush*
<ttx> thanks!
<pitti> de rien :)
<ericm> pitti, ping
<pitti> hello ericm
<ericm> pitti, I saw your name at https://launchpad.net/libusb, just wondering who's still maintaining this libusb-0.1 package?
<ericm> pitti, there is a bug 427805, which I found a fix and many else reported working, just wondering what is the right way to go
<ubottu> Launchpad bug 427805 in libusb (Ubuntu) "usb_find_devices() crashed with SIGSEGV in free()" [Medium,In progress] https://launchpad.net/bugs/427805
<pitti> it's abandoned upstream
<ericm> pitti, yeah - looks like will be replaced by the new libusb, yet it looks still used somewhere
<pitti> libusb-1.0-0 is the current version, so it'd be better to port stuff over to that one
<pitti> but if you have a patch for this, that's great!
<pitti> ericm: just subscribe ubuntu-sponsors
<ericm> pitti, link?
<pitti> https://wiki.ubuntu.com/SponsorshipProcess
<ericm> pitti, ok - I'm reading, will let you know if I have further questions, sorry to bother
<pitti> ericm: no need to be sorry, thanks; as I said you just need to subscribe ubuntu-sponsors
<pitti> to the bug
<ericm> pitti, ok
<ericm> pitti, done
<_rene_> no mvo here? hrmpf ;)
<pitti> he's on vacation today
 * _rene_ will then write a mail. sorry for disturbing ;)
<asac> cjwatson: i have someone who is scared about his complex multiboot setup and wonders if alternative installer asks before he wipes any bootloader
<asac> cjwatson: he found bug 337957
<ubottu> Launchpad bug 337957 in grub-installer (Ubuntu) "alternate installer doesn't ask where to install GRUB and overwrites MBR which may contain other bootloaders (dup-of: 47135)" [High,Triaged] https://launchpad.net/bugs/337957
<ubottu> Launchpad bug 47135 in grub-installer (Ubuntu) "Installation of GRUB to MBR should always be confirmed" [Medium,Fix released] https://launchpad.net/bugs/47135
<cjwatson> I changed it in lucid to ask
<cjwatson> hence that fix-released
<cjwatson> see the changelog for grub-installer 1.49ubuntu9
<stefanlsd> world cup kickoff parties here in south africa. stuff is going crazy
<pitti> stefanlsd: hey, how are you? heh, enjoy the next three weeks :)
<Chipzz> stefanlsd: as someone who doesn't give a rats ass about soccer, I was hoping this channel would be spared of the nonsense. guess not :)
<ScottK> pitti: Would you please rescore kdepimlibs (just affects powerpc).
<pitti> ScottK: sure, rescored to 1 :)
<pitti> j/k
<ScottK> Thanks.
 * pitti pushes it to the queue front
<sebner> pitti: immer diese vetternwirtschaft :P  hi btw :)
<pitti> hey sebner
<pitti> *pfft* :-)
<pitti> yes, we do have some bureaucracy these days, but rescoring doesn't yet need a written contract in triplicate :-P
<sebner> :D
<Chipzz> pitti: a single contract signed with blood will do? ;)
<pitti> barely
<Chipzz> btw, is it just me or are a lot of the core developers on vacation this week?
<Chipzz> mvo & keybuk
<Chipzz> coincidence?
<Chipzz> hrrrm probably taking a break post-lucid
<ScottK> Maybe they are football fans.
<pitti> well, at least mvo is rather a wedding fan :)
<sebner> lol
<sebner> ScottK++
<LucidFox> Speaking of which, C++ really should have been named ++C. ;)
<soren> LucidFox: Or Java--.
<LucidFox> LOL
<soren> srsly
<soren> I don't look at C++ and think, "wow, this is a much better C than C."
<LucidFox> Java isn't a much better C than C, either ;)
<soren> Certainly not.
<LucidFox> it's a completely different language that just happens to use curly brackets syntax
<soren> *nod*
 * psusi remains convinced that Java was created by engineers in the field for schools to teach students so that they would learn to be bad programmers, thus insuring job security for the older engineers
<LucidFox> ...
<LucidFox> psusi> You realize I earn, like, money from Java programming?
<psusi> I hadn't, no... and that was half tounge-in-cheek ;)
<Chipzz> psusi: I have similar thoughts on Java tbh
<Chipzz> LucidFox: my condolences :P
 * LucidFox hisses
 * soren recently stumbled upon his Java 1.4 Certified Programmer certificate :)
 * psusi often does miss having destructors and proper stack unwinding in C, that's for sure
<pitti> vala! vala! vala!
<pitti> (hey, it's Friday afternoon, some trolling should be tolerated by now)
<psusi> hehe ;)
 * psusi passes out copies of e2defrag for everyone to review, test, and have eat their data over the weekend ;)
<pitti> psusi: oh, new ureadahead goodness?
<psusi> pitti: yea, I have some of that too I need to have keybuck review and merge
<ion> Awesome
<psusi> but I uploaded a new e2defrag release last night.... it burns up a good deal of cpu at the start... room for optimization there... but it works now on a 1.5 tb drive with only 2 gigs of ram
<psusi> I modified it to use an extent based block relocation map instead of two paralell arrays of block pointers, which needed 666 megs of ram for a 320 gig drive
<ion> Btw, did you manage to fix the problem of readaheaded device blocks not being considered by the filesystem code when reading files etc?
<ion> psusi: (It was you who mentioned encountering that problem, wasnât it?)
<psusi> sort of... had to split the reading into two passes to do it... first read all the directory blocks via the dev node, then read the normal file data the usual way
<psusi> I also want to get a patch applied I made to e2fsprogs so we can turn on lazy_itable_init by default and vastly speed up mkfs on large volumes... very frustrating to have Ubiquity sit at 5% complete for 20 minutes while it formats a 1.5tb disk with no apparent progress
<bdrung> jdstrand: why did you upload arc-colors? we had it removed from lucid.
<jdstrand> bdrung: it was sitting in maverick's NEW as part of a sync I assumed. I figured since it wasn't blacklisted we would try again in maverick
<bdrung> jdstrand: can we remove and blacklist it?
<jdstrand> bdrung: sure. can you file a bug listing why it should be removed and it should be blacklisted, and assign my to it?
<bdrung> jdstrand: bug #550306
<ubottu> Launchpad bug 550306 in arc-colors (Ubuntu) "Please remove arc-colors from lucid" [Wishlist,Fix released] https://launchpad.net/bugs/550306
<jdstrand> bdrung: k, I tasked it and assigned it to me
<bdrung> thanks
<jdstrand> mdz: fyi, fta pointed me to http://googlechromereleases.blogspot.com/2010/04/dev-channel-update_08.html regarding font changes
<mdz> jdstrand: thanks
<jdstrand> sure, np
<mdz> jdstrand: I guess we can all look forward to our browsers changing in random and unexpected ways in SRUs from now on :-/
<jdstrand> mdz: *sigh*, yes, unfortunately. That is the new world order starting with chromium and mozilla following suit...
<jdstrand> mdz: but, on the plus side, the experience is more like Windows now :P
<mdz> jdstrand: hooray for matching user expectations :-)
<jdstrand> hehe
<crimsun_> TheMuso: I'll push it to bzr after flight-hell
<hallyn> jinkeys:  bzr: ERROR: Cannot lock LockDir(lp-69481744:///~ubuntu-branches/ubuntu/maverick/qemu-kvm/maverick/.bzr/branchlock): Transport operation not possible: readonly transport
<mathiaz> hallyn: did you try to bzr co lp:ubuntu/qemu-kvm?
<hallyn> i had started with bzr co lp:ubuntu/maverick/qemu-kvm qemu-kvm-serge
<hallyn> then did bzr merge-upstream
<mathiaz> hallyn: right - so bzr co will do a checkout which means you're bound to the branch in LP
<mathiaz> hallyn: if you commit locally it will try to commit directly to LP as well
<hallyn> oops
<hallyn> so i should branch first
<mathiaz> hallyn: yeah - try to bzr branch instead
<mathiaz> hallyn: this may be the reason why you've ran into the error above
<smoser> hey all, i've a question. cloud-utils (https://launchpad.net/ubuntu/+source/cloud-utils) is a native package.
<smoser> i believe that the numbering is wrong 0.11-0ubuntu1
<smoser> i think that should be just 0.11. right ?
<SpamapS> am I the only one who thinks cdbs *.mk files just look like spaghetti in a blender?
<mathiaz> hallyn: could you use the same branch for your qemu-kvm update?
<mathiaz> hallyn: that way when creating another merge proposal the comments of the existing merge proposal will be kept
<mathiaz> hallyn: it makes the review easier as the comments I made in the review are still around
<mathiaz> hallyn: IIRC you need to use the same branch to do so
<cjwatson> smoser: native packages should indeed not generally contain a dash in their version
<hallyn> mathiaz: ok.  i've got a new branch i'm developing it, but i'll update the old branch when i've tested
<cjwatson> SpamapS: just use dh instead then :)
<smoser> cjwatson, thank you.
<cjwatson> hmm - from the trend lines, dh should have overtaken cdbs in popularity in unstable by DebConf
<SpamapS> cjwatson: unfortunately, debian-maven-helper is tied to cdbs pretty heavily. ;)
<hallyn> mathiaz: so to be clear, when you say a single changelog entry, you mean debian/changelog, not bzr changelog, right?  I guess I wasn't quite sure whether you wanted a 1-1 relationship between those, but your comment above makes it clear that you don't.  (good)
<mathiaz> hallyn: right
<mathiaz> hallyn: I usually use debcommit instead of bzr commit
<mathiaz> hallyn: as debcommit will actually use debian/changelog to infer the commit message for the bzr commit message
<mathiaz> hallyn: you can test what would be done by using debcommit -n
<mathiaz> hallyn: but I definetely don't require to have a 1-1 mapping between changelog entries and bzr commit messages
<mathiaz> hallyn: on the contrary
<hallyn> bzr ci seemed to base on debian/changelog as well
<mathiaz> hallyn: you meant by looking at the bzr log for the existing branch?
<hallyn> <shrug>
<hallyn> i assumed it just took the top debian/changelog entry
<hallyn> and pasted that into my editor to start
<hallyn> i'll play more in  a toy branch later
<hallyn> so is it safe to say that every package has a corresponding lp:ubuntu/package-name branch, which corresponds to what you get from 'apt-get source package' ?
<hallyn> or did i just get lucky?
<mathiaz> hallyn: nope - that's the plan
<hallyn> i see
<mathiaz> hallyn: almost all packages have a corresponding bzr branch
<mathiaz> hallyn: I think there is a minor number of packages that are not imported yet
<mathiaz> hallyn: https://code.launchpad.net/ubuntu/+source/qemu-kvm
<mathiaz> hallyn: ^^ gives a good overview about the branches that are available for a package
<mathiaz> hallyn: I have it set as a shortcut in my firefox
<mathiaz> hallyn: so that I can easily lookup the state of src package
<statik> hi SpamapS, thanks for working on the couchdb 0.11 merge
<RoAkSoAx> pitti: hi there! I was wondering why http://cdimage.ubuntu.com/cdimage/.manifest-daily is not showing others flavors besides ubuntu desktop isos?
<RoAkSoAx> other isos besides ubuntu desktop*
<uga> Hi there, I hope this is the right place for asking, after an unhelpfull google search...
<uga> have there been big changes in the intel graphics drivers in maverick? after my upgrade I managed getting up to a 200frames in 5s in glxgears...
<cjwatson> RoAkSoAx: that's probably more my thing, let me look
<uga> either I'm missing important configs or something is pretty weird
<RoAkSoAx> cjwatson: ok :)
<marcococos> hello. can anyone please tell me why is gcc installed on ubuntu by default?
<cjwatson> because getting online to fetch more packages sometimes involves compiling a driver (which you got on a CD or whatever)
<cjwatson> it's a compromise
<cjwatson> RoAkSoAx: heh, if you look closely at the file sizes it's actually a mislabelled xubuntu manifest
<marcococos> oic
<micahg> cjwatson: is there any follow up I need to do with you WRT the mozilla package set?
<marcococos> maybe one would need to compile wireless drivers... i see
<marcococos> well, thanks for the info
<cjwatson> RoAkSoAx: fixed now
<cjwatson> micahg: no, I think I still have the action
<micahg> cjwatson: k, thanks
<cjwatson> I just suck
<RoAkSoAx> cjwatson: thank you :). And would it be possible to haven such manifest for older Ubuntu releases?
<micahg> cjwatson: ?  I wasn't complaining :)
<cjwatson> RoAkSoAx: I'd rather not, the point of that manifest is to measure how well daily builds are being mirrored
<cjwatson> RoAkSoAx: http://releases.ubuntu.com/ has its own manifest
<cjwatson> and the dailies built for older releases are unreliable and mostly stale
<RoAkSoAx> cjwatson: this one then: http://releases.ubuntu.com/.manifest (but it shows only 10.04 and not older ones)
<cjwatson> I guess I'd rather let our mirroring folk decide on that - that originally had the older releases too but it was stripped back for release
<cjwatson> why do you need it?
<cjwatson> jpds: ^- do you care if the releases.u.c manifest grows older releases again?
<elmo> cjwatson: it should, please
<elmo> cjwatson: it's only meant to be stripped down during release to make the mirror prober run faster
<RoAkSoAx> cjwatson: for testdrive. TO be able to add support for testdriving old isos, such as hardy
<cjwatson> ok, sure, I can change that then
<RoAkSoAx> cjwatson: awesome. Thank you :)
<cjwatson> ok, I've moved .manifest.full back over the top of .manifest
<elmo> RoAkSoAx: I wouldn't recommend relying on that file for anything
<elmo> RoAkSoAx: it's going to change around every major release on releases.ubuntu.com (i.e. beta, rc and final)
<the-fallen> hello
<RoAkSoAx> elmo: At first, TestDrive kinda used a hardcoded list of ISOs, but we decided to use the manifests to parse the available ISOs and add them to the list given the preferences desired
<cjwatson> maybe testdrive should look for .manifest.full first, and only .manifest if that fails
<cjwatson> when we prune the manifest back for release, we put a full version on .manifest.full
<RoAkSoAx> cjwatson: yeah than can also be done. The only thing I need the manifest for is to be able to grab the location of the ISO per each release/flavor
<RoAkSoAx> it caches it and updates it daily
<cjwatson> that sounds like the correct fix, then
<the-fallen> I'd like to build my own kernel from vanilla sources and create a deb-package from it. I am following several howtos (even if I did it many times) but after installing the kernel-image and the kernel-headers, the link "build" unter /lib/modules/.../ points to the original source dir, not to the headers
<RoAkSoAx> and from that cache, I generate the ISO list
<RoAkSoAx> cjwatson: indeed :)
<the-fallen> or -at least- does someone know if the maverick kernels do have the cpufreq driver as module again?!
<crimsun_> CONFIG_X86_ACPI_CPUFREQ=y
<crimsun_> and CONFIG_X86_PCC_CPUFREQ=m
<the-fallen> damn
<the-fallen> thanks
<RoAkSoAx> jcastro: Are yu using the latest release of TestDrive?
<jcastro> RoAkSoAx: I'm using what's in lucid
<RoAkSoAx> jcastro: use the one in ppa:testdrive/ppa. THat one has support for older ubuntu releases, which isos are in cdimage.ubuntu.com. Later on I'll add the support for ISO's that are on releases.ubuntu.com
<jcastro> RoAkSoAx: oh I had no idea, thanks for the help!
<RoAkSoAx> jcastro: np :)
<vish> ScottK: :D  neat! "Could we leave the fanboi stuff off and just deal with the actual issues"
<ScottK> Would a buildd admin please rescore kdebindings kdebase-workspace kdepimlibs (only affects powerpc and ia64)
<cjwatson> ScottK: done
<ScottK> cjwatson: Thanks.
<ScottK> cjwatson: If you wouldn't mind, I accidentally left kdegraphics off my list.  Can haz too?
<psusi> oh boy... I just found a bug in the kernel device mapper... addresses over the  2 tb mark get quietly wrapped back ground to zero
<cjwatson> ScottK: done (on powerpc)
<ScottK> cjwatson: Thanks.  That's the one I needed.
<jono> are the X issues fixed now in Maverick?
<jono> safe to upgrade?
<arand> jono: I upgraded a whole slew of things today, and nothing broke too badly at least, this was on a kvm though.
<jono> cool thanks arand
<barry> is keyserver.ubuntu.com unhappy?  add-apt-repository for a ppa is timing out :(
<didrocks> barry: same here
<barry> didrocks: okay, at least it's not me :)  i'll see if there are any is folks around. since warsaw's 2nd law is in effect, it might just be time to call it a week :)
<didrocks> right, same here, and getting late :)
<barry> didrocks: seems to be back now, but it definitely s flakey
<CynthiaG> Good evening
<CynthiaG> cjwatson: A daily build of the LiveCD must have been done with bootchart included by now, correct?
<CynthiaG> If so, I'll deconstruct it and reconstruct it using my ready-made mksquashfs ordering script + post results in bug 592485
<ubottu> Launchpad bug 592485 in Scour "Convert polylines and polygons into paths" [Undecided,New] https://launchpad.net/bugs/592485
<CynthiaG> ... wrong bug
<CynthiaG> bug 589629
<ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
<andersk> A few packages in maverick are older than lucid (e.g. apt, brasero, language-pack-en), even though the lucid packages arenât numbered like SRUs. Whatâs up with that?
<slangasek> andersk: SRU numbering isn't mandatory; and when the package is intended to be forward-copied from -updates to the next dev release early in the cycle, sometimes devs don't use the SRU versioning
<cjwatson> CynthiaG: yes, today's daily has it
<CynthiaG> cjwatson: cool, I'll download it right now! :D
<cjwatson> you can look in the .list and .manifest files to check
<cjwatson> (sometimes it's in one or the other depending on details)
<CynthiaG> >> maverick-desktop-i386.manifest:  bootchart 0.90.2-7
<JanC> can somebody familiar with udev & hdparm please have a look at bug #568120 ? -- there is no init-script for hdparm anymore in lucid, and because of that some (documented!) parts of hdparm.conf aren't used anymore, causing all sorts of regressions for people... (and people are getting pointed to using packages from Debian and other recipes for possible future disaster)
<ubottu> Launchpad bug 568120 in hdparm (Ubuntu) "[Lucid] hdparm.conf change doesn't have effect" [Undecided,Confirmed] https://launchpad.net/bugs/568120
<slangasek> JanC: the "command_line" is a horrible misfeature which is deliberately omitted from the udev script, and it's not documented in the manpage.  What documentation points at this?
<JanC> slangasek: it is (or was) at least documented in the default hdparm.conf
<JanC> and lots of on-line docs about fixing hard disk related stuff uses it too
<JanC> and it is actually documented in the manpage too
<slangasek> no, it's not
<slangasek> on-line docs> well, it's hard to stop the Internet from giving people bad advice
<JanC> see the paragraph just below the options...
<slangasek> it is still present in the default hdparm.conf, yes; that's something we can fix
<JanC> it's in the manpage in Lucid
<slangasek> JanC: oh, sorry - it wordwrapped, making it impervious to my search command
<slangasek> right, there's a documentation gap here we should fix
<CynthiaG> and there's a bug in 'man' too :)
<JanC> and probably include a warning about it no longer working
<CynthiaG> searches shouldn't be affected by wordwrap
<JanC> it might be a cludge from the past, but people want their stuff to keep working, or at least know why it doesn't  ;)
<cjwatson> CynthiaG: not much man itself can do about that
<SpamapS> "Nobody ever upgrades. They just buy new computers when they want new features." -- Steve Jobs (paraphrased, from a lifetime of behavioral patterns)
<cjwatson> it's the pager that handles most searches
<CynthiaG> oh, didn't know that
<CynthiaG> so basically it's 'less' handling the search?
<cjwatson> yes
<CynthiaG> bah :(
<CynthiaG> anyway, sorry about interrupting the discussion about udev and hdparm
<cjwatson> if anyone in the MIR team is still awake, I'd really appreciate a review of bug 582189
<ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [Undecided,New] https://launchpad.net/bugs/582189
#ubuntu-devel 2010-06-12
<mathiaz> kees: hi - could you confirm that libpam-ccreds can be moved to main (bug 523354)?
<ubottu> Launchpad bug 523354 in libpam-ccreds (Ubuntu) "[MIR] libpam-ccreds" [Wishlist,Triaged] https://launchpad.net/bugs/523354
<psusi> damn.... the 2tb wraparound happens on lucid amd64 too
<psusi> with device mapper targets
<nigelb> kees: Is the gcc task on bug 534459 valid since the orginal bug seems to be fixed
<ubottu> Launchpad bug 534459 in gcc-4.4 (Ubuntu) "2.6-2 FTBFS on sparc (bus error in test cases)" [High,Confirmed] https://launchpad.net/bugs/534459
<ghostcube_> hmmm, has there been any change from 9.10 to 10.04 about the nvidia drivers. cause in 10.04 my x3 game isnt starting anmore claiming not finding any working driver for grafic
<ghostcube_> it needs 32 bit support but this worked fine in 9.10
<ghostcube_> iam on 64 bit ubuntu 10.04
<un214> anybody know how to replace the entire set of boot scripts?
<LucidFox> Why is REVU so stagnant, I wonder
<LucidFox> it has packages from more than a year ago
<LucidFox> in the "needs review" section
<nigelb> LucidFox: because we dont have too many people interested at doing the hard work of a thorough review
<nigelb> LucidFox: if you have a new package, my suggestion would be to try to get it to debian and then sync'd to ubuntu
<sebner> nigelb: don't worry, he can upload by himself ;=
<sebner> *;)
<LucidFox> she :)
<sebner> LucidFox: haha, never noticed that for years :D
<LucidFox> sebner> And well, I need the package reviewed by another developer first, right?
<sebner> LucidFox: good but not a requirement
<LucidFox> ...Really? I can upload new packages straight to NEW?
<sebner> LucidFox: Aren't your MOTU for months/years now? O_o
<nigelb> sebner: aha, she's awesome, I forget
<sebner> *you
<LucidFox> I am
<LucidFox> But the REVU policy has always stated that packages by MOTUs need one more MOTU to review before they can leave REVU
<sebner> LucidFox: you are missing a lot then :P
<sebner> LucidFox: nah, in general it's adviced to do a peer review regarding improving quality but it's not a requirement, never was
<LucidFox> I'm not sure MOTU even exists as a separate team now, though - I've noticed there were some merges, like with the sponsors and SRU teams.
<nigelb> LucidFox: MOTU exists, but there are a few changes
<LucidFox> I knew I always *could* upload packages to NEW in the sense that there was no technical restriction on that, but I assumed there was a policy restriction.
<ScottK> LucidFox: MOTU still exists and will continue to exist.
<LucidFox> apachelogger> I read your gmail address as "sister.harald" at first o_O
<lifeless> pitti: ping
<lifeless> pitti: why did you drop the vcs-bzr header from the pm-utils-powersave-policy package ?
<geser> lifeless: apt-get source informs if it sees a Vcs-* header that the package is maintained in that vcs and changes should be made there. it this isn't the case anymore than the field should get updated or dropped to not misguide.
<lifeless> geser: yes, I know.
<lifeless> geser: that doesn't explain why pitti removed it, and thats why I'm asking him why!
#ubuntu-devel 2010-06-13
<CynthiaG> looks like the latest librsvg2-2 introduced a regression, I see bad rendering in my Lucid VM
<CynthiaG> http://img.photobucket.com/albums/v390/Looce/img-launchpad/ubuntu1004-badrendering.png
<apachelogger> LucidFox: seems like a likely enough thing to happen ^^
<ikorm> I would like to know if anyone is up to date with ati drivers on ubuntu. Proprietary ones
<ikorm> They keep freezing my laptop, and a lot of people have troubles with them on ubuntu.
<ikorm> Where should I adress this, here or do I need to take it to Ati website?
<Gryllida> ikorm: !ATI <ubottu> https://help.ubuntu.com/community/BinaryDriverHowto This guide and its subpages describe how to install the proprietary binary/restricted drivers provided by video card manufacturers.
<Gryllida> ikorm: I think take to ATI support, not to here.
<Gryllida> ikorm: unless it is a request to update a driver in the repo
<rlameiro> anyone in here worked with python-apt?
<rlameiro> i needex to know how to add a ppa with it
<froud> Hi everyone. where is the file that holds the setting for session type GNOME | BLACKBOX. I want to be able to edit this setting via bash shell script, not via the login screen session drop list.
<Q-FUNK> doko: could you check something with gas?
<Q-FUNK> doko:  https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/587186
<ubottu> Launchpad bug 587186 in gcc-4.4 (Ubuntu) "libc6 upgrade fails: illegal instruction" [High,Triaged]
<geser> rlameiro: you could look how apt-add-repository does it.
<rlameiro> thanks geser, i will
<fmuellner> my apologies if this is not the appropriate channel for these kinds of questions
<fmuellner> i'm looking for the most graceful manner to disable app-indicators in order to resolve https://bugzilla.gnome.org/show_bug.cgi?id=621382
<ubottu> Gnome bug 621382 in general "Ubuntu Lucid - indicators need to be killed before starting gnome-shell" [Normal,Unconfirmed]
<fmuellner> killing seems like a pretty rude solution - i'm not using ubuntu myself, so any help would be very much appreciated
<kklimonda> fmuellner: killing indicator-application-service
<kklimonda> should be enough
<fmuellner> kklimonda: thanks!
<fmuellner> kklimonda: would that process be restarted with gnome-panel?
<kklimonda> fmuellner: hmm.. let me see.
<kklimonda> fmuellner: yes, killing gnome-panel, then killing indicator-application-service and starting gnome-panel again does restart indicator-application-service itself.
<fmuellner> kklimonda: cool, thanks a lot!
<BlackZ> pitti: are you working to the cdbs merge?
<jdong> Hmph. I wish there existed a timezone aware ssh hack :)
<jdong> e.g. Based on source IP geolocation set the timezone in the session
<un214> it's time for plymouth to go.
<un214> it can't even do its job without specific drivers anymore
<hyperair> o rly?
<un214> https://bugs.launchpad.net/bugs/593408
<ubottu> Launchpad bug 593408 in plymouth (Ubuntu) "nothing is visible on screen during boot sequence with fbcon disabled -- really annoying when the system decided to run a periodic fsck" [Undecided,New]
<un214> fbcon has always been broke on this system so don't get any bright ideas
<hyperair> so get it fixed.
<hyperair> fbcon isn't a "specific driver"
<hyperair> it's a generic one.
<hyperair> fyi, i'm not using nouveau on my desktop, and it displays the terrible looking lowres splash, but still works.
<un214> I got tired of the crashes
<un214> fbcon-vesa is misaligned
<CynthiaG> fbcon-vesa is probably displaying at 640x480
<hyperair> how about filing a real bug report about that? i'm sure the nouveau people will like more information.
<CynthiaG> which you can perform a (separate) monitor auto-adjustment for
<un214> monitor auto-adjust isn't going to work in this case
<hyperair> what you're saying is that "X technology doesn't work without Y technology, which should work for everyone, but due to a few bugs can't work for me. so let's remove X technology instead of fixing Y technology"
<hyperair> i'm sure you understand what's wrong with what i just highlighted.
<CynthiaG> nouveau is in active development yes, and they need hardware dumps
<jdong_> hyperair: I think "plymouth uses fbcon which is more than the old bootsys that just needed a VGA text console, which causes regressions" is fairly valid of a complaint.
<jdong_> of course, "we should remove plymouth" isn't a solution
<un214> well since the hardware is actually bad
<un214> nouveau isn't going to be able to fix it
<CynthiaG> Does Nouveau work while in X/GNOME/whatever?
<un214> it's unstable
<CynthiaG> If the hardware is bad... what are the Nouveau guys to do about it, in software?
<CynthiaG> *boggles*
<hyperair> jdong_: oh how i wish we can take such an outlook on everything new on ubuntu that causese regressions. but yes i agree.
<un214> the motherboard designers put two devices on the same address and wrote special windows drivers to make it work
<hyperair> jdong_: in particular, i'm annoyed that plymouth doesn't give me my usual verbose initialization messages.
<CynthiaG> the nouveau project can implement that split too, even if not right now
<un214> I can't afford to wait
<un214> seriously I have so few services that I don't need the parallel boot sequence
<un214> how hard would it be to check [ -x /sbin/plymouthd] || run each boot service attached to the console in turn
 * CynthiaG thinks she misunderstands Plymouth versus Upstart, or that you do
<CynthiaG> Plymouth is just the splash screen that messages get written onto, and Upstart handles the parallel booting... at least Upstart did that in Karmic
<un214> CynthiaG: In karmic that was right
<un214> in lucid it doesn't seem to be
<hyperair> can't you apt-get purge plymouth, though?
<un214> I tried.
<un214> it wants to remove e2fsprogs
<hyperair> huh
<CynthiaG> e2fsprogs depends on plymouth? :|
<CynthiaG> sounds like a very ugly kludge
<hyperair> e2fsprogs doesn't depend on plymouth
<hyperair> however, mountall does
<CynthiaG> Ah
<un214> e2fsprogs depends on sysvinit-tools which depends on upstart which depends on plymouth
<hyperair> so the bug should be on mountall.
<hyperair> er no
<hyperair> upstart doesn't depend on plymouth
<CynthiaG> Confusing dependency chain is confusing? :(
<hyperair> upstart depends on mountall
<hyperair> mountall depends on plymouth
<hyperair> mountall is the buggy one
<hyperair> it should function without plymouth
<hyperair> so file a bug
<CynthiaG> hyperair @ un214 or me?
<hyperair> whoever
 * hyperair isn't really interested in the issue.
<hyperair> whoever's interested, file a bug.
<CynthiaG> I wouldn't be such a great source of information on the issue because I'm not having it :\
<hyperair> heh
<un214> CynthiaG: you can force the issue by adding alias fbcon off to /etc/modprobe.conf
<hyperair> or blacklist fbcon
<CynthiaG> un214: even in a VM, you think?
<CynthiaG> a VM of the LiveCD
<un214> hyperair: I have another bug for blacklist fbcon doesn't work
<hyperair> huh
<un214> believe me I tried that one
<hyperair> weird.
<CynthiaG> actually, never mind, I've just created a virtual hard drive and will try what you say
<un214> I was talking to some others earlier and they say the dependency is reall -- w/o plymouth no boot program can talk to the console
<un214> I really wish they had bolted the parallel init on top of sysvinit -- it'd make it a lot easier for me to find out what scripts run at boot time in what order
<jdong_> what order... in a parallel init system? :)
<psusi> that statement hurts my head
<un214> I need to know the critical ones bucause if you can't fix this I get to replace all the bootscripts
<psusi> like saying I want different process contexts, but they all share the same memory
<un214> besides, there exists a partial order (http://en.wikipedia.org/wiki/Topsort)
<psusi> the only ordering is between jobs that depend on each other... which you can see in the init script
<CynthiaG> un214: creating /etc/modprobe.conf with the line "alias fbcon off" in it does absolutely nothing
<un214> oh that's right they moved it
<CynthiaG> create a file in /etc/modprobe.d instead?
<un214> I actually ended up adding it to /etc/modprobe.d/blacklist.conf
<jdong_> psusi: don't say depend on each other or keybuk is gonna come in here screaming at you ;-)
<psusi> jdong, hey... care to sponsor the defrag package? ;)
<jdong_> psusi: whoa, where's this defrag package??
<un214> jdond_: there is such a thing as co-depends
<psusi> lol... it may not be 100% accurate, but still a useful generalization concept ;)
<jdong_> un214: I'm not arguing with that, it's not proper terminology for Upstart :)
<jdong_> but yes, you can do a topological sort by Upstart events :)
<psusi> jdong, didn't see my post the other day to the motu mailing list?  launchpad.net/e2defrag is the project.... has link to bzr repo and source tarball for the release I made the other day... binary build in my ppa
<jdong_> I used to have a script that did that
<jdong_> psusi: neeeeat; no unfortunately I've been swamped with work lately
<psusi> and I've even tested it on up to 2tb disks
<jdong_> sweet
<psusi> made some changes to allow that without needing 6gb of ram
<CynthiaG> un214: /etc/modprobe.d/blacklist.conf +alias fbcon off still does absolutely nothing for me, in the VM
<un214> CynthiaG: did you run update-initramfs afterwords
<psusi> and in the process ran into a kernel bug... I was trying to go over 2tb and found that lvm snapshots silently wrap around at 2tb
<CynthiaG> un214: oh, no I didn't
<CynthiaG> I'll do that
<psusi> you can use snapshots of a zero target to create a virtual disk of huge size with a smaller backing store... was going to use that to try making a 4tb disk to defrag, but it's all hosed up because of the wraparound
<CynthiaG> aha un214, now it did something! the boot screen was green, and I can see absolutely nothing instead of the login screen
<un214> ok you hit the situation but not the bug
<psusi> that reminds me... I need to poke Keybuck about merging my ureadahead changes
<un214> hit Alt-F1 to get login
<CynthiaG> I heard the drum-like thing that serves as the login ready indication
<CynthiaG> Ubuntu 10.04 LTS abra tty1 || abra login:
<un214> somehow I got that green screen broken
<psusi> and I still haven't heard from Ted about my e2fsck patch....
<CynthiaG> that's what virtual terminal 1 says
<un214> CynthiaG: my bug is somehow I'm no longer getting the green screen
<CynthiaG> hmm
<CynthiaG> What are you getting instead?
<un214> blackness until login prompt
<CynthiaG> well, in any case, it's not the Ubuntu logo and the five circles
<CynthiaG> which is to be expected since blacklisting fbcon
<un214> I'll bet that if I got fsck to ask me any questions during boot it hangs forever
<CynthiaG> However, I only get a login prompt for GNOME (vt7) after I do like you said and switch to vt1
<un214> I run KDE and don't have the problem
<un214> (*dm login not working)
<CynthiaG> it would probably hang forever if fsck needed to ask you anything, yes
<CynthiaG> but I think the on-boot fsck is non-interactive
<CynthiaG> until it needs to boot you to a maintenance shell, that is. And then I don't know what it does, but it should switch to a sane terminal
<un214> CynthiaG: last I checked maintenance boot doesn't use plymouth
<CynthiaG> I don't mean a maintenance boot (single-user), I mean fsck having unrecoverable errors and throwing you into a maintenance shell from a normal boot :)
<un214> who knows what that's gonna do
<CynthiaG> Errors such as "mount time in the future" from Karmic
<un214> My money's on wrong console acrtive
<CynthiaG> Those threw me to a maintenance shell during the alphas
<un214> that shouldn't be an error -- it means the system clock is off until it can sync to network
<CynthiaG> I know, but they were still considered unrecoverable in Karmic
<un214> ewww
<CynthiaG> Aye
<CynthiaG> Off-topic fun fact: Apparently a Lucid install needs to read 157 MB of data between boot and the GNOME desktop.
<un214> I'm gonna play a hunch and see if I get usable feedback with chmod -x plymouth
<un214> test will take awhile
<jdong_> what does marking plymouth non-executable do?
<CynthiaG> prevents it from being run, without necessarily removing the package
<CynthiaG> because removing plymouth the package would also delete e2fsprogs because of a dependency
<jdong_> and how will that help him see messages that otherwise plymouth is unable to print??
<CynthiaG> s/he is testing a bug that is making plymouth unable to print things anyway
<CynthiaG> https://bugs.launchpad.net/bugs/593408
<ubottu> Launchpad bug 593408 in plymouth (Ubuntu) "nothing is visible on screen during boot sequence with fbcon disabled -- really annoying when the system decided to run a periodic fsck" [Undecided,New]
<CynthiaG> and with fbcon enabled, it's apparently misaligned enough that still nothing is visible, or something
<jdong_> well not allowing plymouth to run isn't gonna cause the boot system to print anything either
<CynthiaG> *boggles* :)
<CynthiaG> I wonder what that person wants to achieve now
<un214> well chmod -x /sbin/plymouthd resulted in the boot feedback showing up again
<CynthiaG> In a console?
<CynthiaG> Er. Text console.
<un214> yup, right on tty1
<jdong_> I was unaware of such a fallback except for init scripts
<CynthiaG> So that's what you wanted to achieve.
<un214> not quite
<jdong_> stuff like mountall IIRC directly called plymouth APIs to output
<un214> I've got to go find the options being used to call fsck and change them
<psusi> CynthiaG, sounds about right... that's why I've been working on using defrag to pack all that data in order at the start of the disk so it gets pulled in faster ;)
<CynthiaG> psusi: So e2defrag is also a boot-sequence optimiser?
<jdong_> CynthiaG: psusi is combining it with ureadahead to make it such :)
<psusi> if you don't want a gui boot console, just pass "text" on the kernel command line and it will remain in 25 line mode
<CynthiaG> Oho! That sounds awesome
<un214> jdong: looks like I get to go break mountall then
<un214> I'll bet he's the one calling fsck anyway
<jdong_> or probably just find the 9.04 version anyway :)
<psusi> CynthiaG, not exactly... but you can give it a list of files that should be given priority when packing... such as a list pulled from the ureadahead pack file ;)
<un214> psusi: tried that doesn't work
<CynthiaG> psusi: Sounds even more awesome :D
<un214> ugh goodbye mountall
<un214> replacing it with fsck -a && mount -a
<psusi> you mean fsck -p
<un214> no actually I mean fsck -A
<psusi> boot time fsck is run in prone mode... not to mention that the rest of the system won't boot without mountall
<psusi> s/prone/prune
<un214> preen
<psusi> err, yea, that one ;)
<psusi> shit... I'm getting old.
<un214> you want to fix mountall to not depend on plymouth?
<psusi> no
<un214> remember, plymouth is broken for me
<psusi> you should probably fix it then
<un214> can't determine why its broken
 * psusi watches defrag do its thing
<lifeless>  \o/
<un214> anyway reading the plymouth source made the problem obvious
<un214> /bin/plymouth was damaged
<un214> I'm still probably gonna make a mountall-noplymouth as this thing's bloody stupid
<psusi> cjwatson, have you seen my e2fsck patch in bug #556621?  Wondering if you had any thoughts on it.
<ubottu> Launchpad bug 556621 in e2fsprogs (Ubuntu) "lazy_itable_init not on by default" [Wishlist,In progress] https://launchpad.net/bugs/556621
<psusi> cjwatson,  also could you possibly help move bug #568050 along by uploading the fix to lucid-proposed?  This was a serious regression that prevents installation for effected users so I'd like to see it make it in for the 10.04.1 respin
<ubottu> Launchpad bug 568050 in parted (Ubuntu) "Ubuntu 10.04 can't create partition on fakeraid" [High,In progress] https://launchpad.net/bugs/568050
#ubuntu-devel 2011-06-06
<poolie> bryceh: don't suppose you're here?
<RAOF> poolie: Could a fellow Xer help instead?
<poolie> hi
<poolie> RAOF: i'm trying to localize the change that fixes bug 745112
<ubottu> Launchpad bug 745112 in xserver-xorg-video-intel (Ubuntu) "[arrandale] desktop is messed up (goes black) when laptop is docked with two external 1920x1200 monitors (x86_64)" [Medium,In progress] https://launchpad.net/bugs/745112
<poolie> i was hitting a snag that there is no single git revision chain between the natty and oneiric kernels
<poolie> afaics
<poolie> so you can't bisect between them and build packages all the way
<poolie> i was just going to go back to building with a plain 'make'
<TheMuso> /c/c
<RAOF> Yeah.  That's one of the awkwardnesses of the kernel team's git usage.
<RAOF> I'd do what you're doing; nab the upstream kernels, build with the oneiric configuration, and run a âgit bisect drivers/gpu/drmâ
<RAOF> If Sarvatt were up you could possibly farm the job of building kernels off to him, what with his 10 minute kernel build machine and all :)
<poolie> something seems sad with ecryptfs on my laptop now anyhow
<poolie> so you're pretty sure bisecting just the changes on that directory will be enough?
<RAOF> That's where all the GPU driver code is; it's where all the modeswitching code is.
<RAOF> It's possible that the code was broken by an change elsewhere in the tree, but drm is moderately well isolated from the rest of the kernel.
<LLStarks> siretart, what's the best way to request packaging updates that full under your jurisdiction for both ubuntu and debian?
<LLStarks> *fall
<LaserJock> anybody know a wiki page or something that describes how to get a bzr branch of debian packages?
<StevenK> LaserJock: bzr branch lp:debian/<sourcepackage> ?
<LaserJock> ah, that would maybe work :-)
<LaserJock> I tried lp:debian/unstable/<sourcepackage> and that didn't work
<StevenK> debian/sid/<sourcepackage>
<LaserJock> ahhh
<LaserJock> I thought there was a way to do it, but I'm a bit rusty
<pitti> Good morning
<poolie> hi pitti
<StevenK> Hai pitti
 * pitti waves to Australia, how are you?
<StevenK> Cold! Send warmth!
<RAOF> StevenK: Hah!  *You* think you're cold? :)
<StevenK> RAOF: But 14 is cold!
<RAOF> You and your double digit centigrade temperatures
<StevenK> RAOF: It's what, 7, down there?
<RAOF> My phone thinks it's 9.
<bryceh> poolie, heya
<bryceh> it got suddenly too hot here today.  I'll box some heat up and send down to you StevenK
<StevenK> bryceh: <3
<poolie> hi bryceh
<poolie> bryceh: i'm trying to  narrow down that bug
<poolie> i hit bug 793367 on the way, which was a bit distressing
<ubottu> Launchpad bug 793367 in linux (Ubuntu) "ecryptfs corruption during make -j" [Undecided,New] https://launchpad.net/bugs/793367
<bryceh> poolie, icky
<bryceh> poolie, RAOF's advice is pretty much what I'd suggest.  git bisects are sometimes quite a slog, sorry
<poolie> is bisecting just on that directory pretty sure to find the problem?
<poolie> at the moment i'm doing it over the whole tree which is obviously going to be longer
<RAOF> I, obviously, think it's quite likely to find the problem; it'll probably save you 2 or 3 kernel builds, too.
<bryceh> I would agree; these types of bugs are generally drm
<bryceh> or I should say, I don't think I've ever seen one that was in some area of the kernel other than drm
<slangasek> bryceh: nooo I was using that heat
<RAOF> Oh, yeah.  The problem of âmy monitor turns black when trying to attach the second displayâ is certainly drm.  The only concern is whether it's drm+some change outside there, like to the VM code or acpi.
<poolie> you know the last time i rebuilt a kernel to try to get hardware working was probably before i installed warty
<poolie> in fact that was the main reason i did install warty
 * slangasek chuckles
<bryceh> yeah, when do we teach Launchpad how to do bisection searches for us?
<poolie> wow
<poolie> you know, if it could populate a ppa-like thing with the relevant packages
<poolie> and collect the feedback
<bryceh> yep
<poolie> that would be pretty cool
<bryceh> poolie, ppa's can only have one version of a package though
<StevenK> So you create multiple PPAs and switch between them
<poolie> well
<RAOF> That's not strictly speaking true.
<StevenK> It would be messy, but doable
<poolie> i think the limitation to a single version is an implementation limit, not an essential limit
<RAOF> You *can* have multiple versions of a package, they'll just get pruned after a while.
<poolie> deb archives can have multiple versions
<poolie> i think ppas prune a bit too aggressively
<poolie> there is a bug about this
<poolie> it would be useful if people could get old versions, either to satisfy dependencies or by explicitly asking
<bryceh> poolie, it'd be way awesome
<lifeless> so does the primary archive
<lifeless> anyhow, there are bugs
<lifeless> and it would be nice to permit select ppas to be more flexible
<bryceh> I did a prototype a while ago, just for xserver, and had users use it to bisect things.  Didn't solve many bugs but the users found it real keen
<bryceh> I just pre-built .debs for every version in git and tossed it in a web directory; was pretty easy
<bryceh> but git history can be non-linear, which tripped me up at transition points.  Someone better versed in VCS logic could probably do something cleaner
<poolie> it's especially nonlinear here because, in line with typical git rebasing practice, there is no real relation between the natty and oneiric kernels
<bryceh> right
<poolie> oh thanks for being the lp stakeholder btw
<bryceh> poolie, sure thing
<bryceh> aha there's the scripts http://people.canonical.com/~bryce/xorg-bisect/
<bryceh> lifeless, what are "select ppas"?
<tjaalton> poolie: you could just try the mainline kernels, there are builds for all the rc-versions too
<tjaalton> and "bisect" using them first
<poolie> bryceh: that's an idea
<poolie> bryceh: my first build of it has hung with a flashing caps lock
<poolie> should i just skip that one?
<bryceh> yep
<poolie> tjaalton: from http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?
<StevenK> That's a panic, isn't it?
<bryceh> poolie, yep
<tjaalton> poolie: yep
<bryceh> yes, it's a panic
<poolie> well
<poolie> i suppose i'm wondering if it's likely to be actually broken, or misinstalled/misconfigured
<bryceh> unfortunately not uncommon when bisecting
<Sarvatt> it sure was nice having months of daily mainline builds available to "bisect" with
<tjaalton> poolie: though .39-rc2 failed to build, but the diff between it and rc3 was small, drm-wise
<bryceh> poolie, it's not unlikely that you just lucked out on picking a git version that was severely broken
<bryceh> RAOF, would he need to rebuild initrd?
<StevenK> Yes, the modules would have changed
<RAOF> Yes.
<poolie> i did do update-initramfs and modules_install
<bryceh> ah ok
<StevenK> In that order?
<poolie> no :)
<StevenK> Right :-)
<poolie> hm, i think no
<siretart> LLStarks: I'd prefer a wishlist bug in debian, but launchpad would work equally well.
<poolie> i'll try some of the builds timo suggested
<tjaalton> poolie: so the bug is fixed in some known version?
<LLStarks> siretart, gotcha
<poolie> yes it seems fixed in 2.6.39-3
<tjaalton> try .39-rc1 first, it got >80 commits to gpu/drm/i915..
<poolie> k
<poolie> ok, rc1 works better but not completely
<poolie> rc4 seems to work completely
<lifeless> bryceh: as opposed to all ppas
<bryceh> lifeless, ah gotcha.  yes agreed.
<poolie> and rc3 also seems ok, hooray
<poolie> bryceh: so eventually is this going to need to come down to one patch(set) to be backported into 2.6.38?
<bryceh> poolie, ideally yes
<RAOF> That's the plan.  If you can find a single patch, hurray!  It sounds like it might require a bunch, though, which is less hurray.
<poolie> ftr yes, i did modules_install before building the initramfs
<poolie> so now git bisect skip?
<bryceh> sometimes though you will get it down to some odd revision number that seemingly has nothing to do with your problem, but then we tell one of the upstream devs and it gives them a clue into what's really wrong
<RAOF> If that one's panicking, yeah.
<bryceh> or, like RAOF says, it'll point to one of a set of patches that'd all need backported, which can get messy
<bryceh> but the kernel team usually can help us out if that happens
<tjaalton> there are already eight patches for sandybridge under evaluation, but looks like they are not quite enough
<tjaalton> from .39
<lifeless> how good/bad is sandybridge in natty?
<lifeless> (I have a new sandybridge desktop coming...)
<RAOF> I understand that it's pretty good, generally.
<RAOF> Better in many respects than arandale in Natty.
<StevenK> Which one is Arandale?
<bryceh> i'm on sandybridge (but with ati gfx) for my main desktop.  has been pretty solid
<RAOF> (Suggesting that it is perhaps better to skip on the first generation of any intel hardware)
<RAOF> Arandale is the GPU on the first Core iX chips.
<RAOF> So, like lifeless' x201.
<lifeless> bryceh: cool; I've ordered an nvidia card, will see how it goes
<bryceh> lifeless, sandybridge gfx seems to be a little hit or miss; there's upstream fixes that seem important but came out too late for natty inclusion
<tjaalton> with .39 it's better
<tjaalton> as always
<bryceh> yeah
<cdbs> Did someone mention SandiBridge
<cdbs> *Sandy
<cdbs> I'm running X from xorg-edgers on Oneiric, and the SandyBridge GPU issues are fixed
<cdbs> bryceh: ^
<cdbs> lifeless: ^
<lifeless> thanks guys
<cdbs> lifeless: Well with the X in Natty, its nearly perfect
<lifeless> I shall wait with bated breath to nuke the windows install and drop on natty ;)
<cdbs> lifeless: there's some lag when you type in OpenGL text fields
<cdbs> lifeless: but if you use xorg-edgers all those are fixes
<cdbs> *fixed
<lifeless> cdbs: thats with the onboard graphics option though, right ? which I won't be using.
<poolie> lifeless: what did you buy?
<cdbs> lifeless: hmm yeah, that's with the integrated thing
<cdbs> and I'm unlucky enough to have an nvidia card in my laptop but being unable to use it
<lifeless> poolie: a dell desktop, i7-2600, 16GB, couple of disks for mirroring
<cdbs> because of the optimus switching thing which works only on windows, and gives ubuntu only the integrated sandybridge GPU
<cdbs> lifeless: So make sure you don't end up with an Optimus configuration, in case :)
<lifeless> poolie: so 2GB of ram per hardware thread, and 8 threads.
<RAOF> cdbs: You can't get an optimus desktop :).  Or, rather, I don't believe the windows drivers will let you optimus-ify a nvidia+intel desktop; it'd be entirely possible to do, though.
<cdbs> RAOF: Ah yeah, he said *desktop*. Okay then. But still, Optimus is a hell to play with
<RAOF> cdbs: The switcheroo code can't turn on your nvidia chip?  Sucks.  Hybrid graphics is a swamp of per-laptop madness.
<cdbs> RAOF: Its a mess because in Linux, the nvidia card is on, draws power from the battery, but can't be used, not even with the official drivers
<cdbs> RAOF: switcheroo does work, but the end result is a dark screen. Why? lemme tell
<RAOF> If switcheroo works it should at least be able to power *off* your discrete card.  Maybe :)
<cdbs> RAOF: In an Optimus configuration, the GPUs are arranged like: nVidia -> Intel -> Monitor. The nvidia card doesnt have a graphics controller. If you use switcheroo, the driver talks to the nvidia card, writes to the intel card, which gets turned off by switcheroo, hence resulting in nothing coming to the monitor, except for a black screen
<cdbs> RAOF: yes, I'm able to power off, that's all that can be done.
<RAOF> cdbs: Correction: in *your* Optimus configuration :)
<RAOF> Other laptops differ :)
<cdbs> RAOF: Nope. in *AN* optimus configuration
<cdbs> RAOF: Its common amongst all optimus laptops. If its in some other way, its other hybrid technology and not Optimus. there's an article on the nouveau wiki about this
<cdbs> RAOF: http://nouveau.freedesktop.org/wiki/Optimus
<RAOF> cdbs: Well, there are some optimus laptops where the nvidia is hooked up to HDMI out & the intel is hooked up to the internal display; there are others where both the intel & nvidia card can drive any display, and there's a hardware mux between them.
<RAOF> If you're lucky enough to have a hardware mux, then switcheroo will actually be able to switch between your graphics cards.  As long as you kill X in between.
<RAOF> If you don't have a hardware mux, sucks to be you.
<cdbs> Or switch to Wayland and avoid all the X switching trouble :)
<RAOF> Laptops are made of madness.
<cdbs> RAOF: no, there's no mux here :(
<RAOF> Yeah.  You're outta luck.  Although switcheroo *should* be able to turn off the nvidia card, leaving your intel card to do the output.  That's probably worth a bug report if it doesn't work.
<StevenK> RAOF: But usually, the madness is so little and cute.
<cdbs> "the madness is so little and Qt" :D
<StevenK> RARGH, I forbid my quotes to be twisted that way.
<dholbach> good morning
<LLStarks> morning.
<LLStarks> does the desktop team have any recommendations for how the x team should handle fallback? i'm wondering about the appropriateness of uniy2d for failsafex sessions as well using gnome-panel as a user-chosen fallback.
<RAOF> What's the problem with unity2d for fallback?
<didrocks> LLStarks: FYI, I answered to your email on the desktop ML
<seb128> hum, libcanberra depending on the fdo sound theme, that seems wrong
<pitti> and a + .5 MB CD hit :/
<Daviey> mvo: What is the correct way to add a package to Unattended-Upgrade::Package-Blacklist ?
<poolie> RAOF, bryceh, rc4 shows some visual corruption coming out of suspend, but switching to vt1 and back fixes it
<mvo> Daviey: just on a local system? or as part of a package install (if part of a packages its best to add via e.g. /etc/apt/apt.conf.d/75_blacklist_foo
<poolie> so, what's next?
<poolie> if bisecting will help you a lot i can do it
<ohsix> poolie: intel?
<poolie> yes
<mvo> Daviey: depending on what package I can also add to unattended-upgrades itself (if its a package that is known to be problematic)
<Daviey> mvo: a package asks for confirmation via debconf before removing via prerm, and blocks u-u.
<RAOF> poolie: corruption out of suspend sounds likely to be a different problem.
<RAOF> poolie: So, the bisection thus far has said âsomewhere between -rc3 and -rc4 is where it starts working reliablyâ?
<Daviey> mvo: bug 791522
<ubottu> Launchpad bug 791522 in quagga (Ubuntu) "Debconf really_stop default value break unattended upgrades" [Low,Confirmed] https://launchpad.net/bugs/791522
<mvo> Daviey: hrm, what package is that? u-n sets the debconf frontend to noninteractive
<poolie> no, between rc1 and rc3
<mvo> Daviey: ok, thanks, let me have a look
<Daviey> mvo: thanks!
<RAOF> poolie: With rc2 failing to build.  Ok.  rc1-rc3 should be enough to narrow commits down a bit.  If you *want* to bisect that would be useful, but this might be the point where some patches could be plausibly implicated by inspection.
<poolie> can you tell me which repo has the source most closely corresponding to them?
<poolie> repo and or tags
<RAOF> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git , sadly.
<RAOF> I believe the kernel mainline builds are built from throw-away git branches, which are then promptly thrown away.
<poolie> hm
<poolie> and i could just copy their config into .config?
<RAOF> Yeah.
<pitti> tkamppeter: FYI, rejecting your two cups uploads to natty-proposed; please merge them into one upload or use -v to include the topmost two changelogs
<RAOF> I think Andy's awake, and hasn't had his mouth filled with bees yet.  You could probably ask him in #ubuntu-kernel whether he can spin up some builds for you.
<pitti> SpamapS: would you have time for some SRU processing today? I'm doing some as well, but I put a hard stop after 90 minutes to not eat up too much of my daily time
<poolie> RAOF: how do i bring the tags from that into my existing git repo?
<poolie> i thought git fetch would do it
<poolie> but no?
<poolie> oh nm
<RAOF> You need to âgit fetch -tâ?
<RAOF> *may* need to.
<poolie> so for this i should mark the ones that _do_ show the bug as 'good', and the working ones as bad?
<poolie> since 'good' is really hardcoded to mean 'too early'?
<TLE> pitti: hey, my apologies for not notifying you last week when we decided to postpone the lang pack update, I forgot :(
<pitti> maco: rejecting your mini-dinstall natty-proposed upload; can you please reupload with proper LP: #XXXX syntax?
<pitti> TLE: which update?
<TLE> pitti: the second natty lang pack update
<pitti> TLE: we need one now, for the firefox update
<TLE> yeah, so it turned out all right anyway. We pushed the update that was supposed to start last week to start this week
<cjwatson> kees: I updated ubuntu-meta to match your platform.oneiric/standard change
<cjwatson> smoser: merging rsyslog> my thoughts are that somebody who iss't me should do it, carefully
<cjwatson> *isn't
<infinity> cjwatson: There are a whole lot of people who aren't you.
<RAOF> poolie: Yup.
<soren> sed -e 's/Dave Chapelle/Colin Watson/' http://www.thebestpageintheuniverse.net/images/chappelle_graph2.gif
<soren> infinity: Can't argue with graphs.
<poolie> RAOF: should i clean between builds, or can i count on the makefile deps being safe enough?
<cjwatson> micahg: MoM disregards blacklisted packages; but if a package was previously in MoM, then blacklisted, MoM won't remove it.  ask me or file a bug on merge-o-matic if you have a package that's stale in that way
<RAOF> poolie: I believe that kernel developers bisect enough to make not-cleaning a safe operation :)
<infinity> soren: The Internet scares me.
<geser> more scaring is that soren has found such a graph
<cjwatson> soren: hah
<pitti> cjwatson, soren: rsyslog> ah, this version is still utterly broken :/
<pitti> I know I have a bug assigned to it, I didn't get to doing this yet, sorry
<debfx> cjwatson: would it be possible to change ownership of the kubuntu seed branches from core-dev to kubuntu-dev?
<jfi> Hello, the package sync from debian is not automatic except for the first version? or it takes more than 2 weeks? I wonder if this is normal that a package has not been synced since the 22may or if there is an issue
<cjwatson> debfx: when I last asked about that, the consensus was that core-dev was still more appropriate; if that's changed, I'd like confirmation from a couple of other Kubuntu people (ScottK, Riddell?)
<cjwatson> jfi: it's generally automatic, but it depends slightly; what package are you talking about?
<tkamppeter> pitti, I will continue collecting CUPS SRUs, bringing it on par with Oneiric, then add a comment to all four bugs telling that the SRU is for all these four bugs. I have also found that one bug is still not completely fixed. When I have found this remaining fix I will add it to the BZR and ask you to upload it. After that I will put up the collected SRU.
<jfi> cjwatson, package in LP: https://launchpad.net/ubuntu/oneiric/+source/psensor
<jfi> cjwatson, package in debian: http://packages.qa.debian.org/p/psensor.html
<cjwatson> jfi: it's been modified in Ubuntu, and therefore needs to be merged manually
<jfi> cjwatson, yes, I need a specific build-dep for ubuntu
<cjwatson> jfi: in fact, it looks like you modified it?
<cjwatson> jfi: I'm not sure what you expect to happen automatically, then
<cjwatson> the automatic systems aren't artificially intelligent - once stuff has been changed intentionally on both sides, they defer to human judgement
<jfi> cjwatson, well it could be merged
<cjwatson> you'll find https://merges.ubuntu.com/universe.html lists psensor as an action for you to merge
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
<jfi> cjwatson, ok, so for each version, I open a bug and request the sync and the merge of the control file?
<cjwatson> syncing and merging are two different things - you only do one
<infinity> jfi: No bugs or syncing required, you just merge the new version with the changes and upload.
<cjwatson> syncing is for when you want to throw away Ubuntu changes and use the Debian change - https://wiki.ubuntu.com/SyncRequestProcess
<cjwatson> I don't think jfi has upload privileges
<jfi> infinity, unfortunely I cannot upload, I need to request it
<cjwatson> in which case you need to open a bug, yes.  https://wiki.ubuntu.com/UbuntuDevelopment/Merging has details
<tkamppeter> Any Avahi expert here?
<jfi> cjwatson, ok thanks for the hint, I am going to read
<debfx> cjwatson: aha, I didn't know about that. I'll discuss it with the other kubuntu devs
<tkamppeter> Anyone knows how to check whether a DNS-SD service emits a service subtype?
<pitti> tkamppeter: sounds good
<pitti> hmm, I thought last week's desktop dailies were at 715 MB
<pitti> now it's back to 722 :/
<pitti> ah, we added libwebkitgtk-3.0-0
<pitti> (7.1 MB)
<seb128> pitti, joy of a dual gtk stack...
<pitti> seb128: rsyncing today's CDs to check the remaining rdepends of libwebkitgtk-1.0-0
<pitti>  
<seb128> pitti, libubuntuone for the music store, shotwell
<seb128> shotwell will not likely go to gtk3 this cycle
<seb128> pitti, software-center as well I guess
<pitti> and webkit 3.0 for empathy apparently?
<seb128> yes
<seb128> will be used in yelp as well once we build it with gtk3
<pitti> I have no idea at all how to free yet another 7 MB :-(
<seb128> drop spanish from the CD...
<pitti> we could perhaps build empathy with gtk2 as well
<infinity> I was going to suggest English...
<janimo> is there a wikipage with which shipped apps still need to transition to gtk3 ?
<seb128> pitti, no way
<seb128> pitti, the nautilus-sendto integration needs to be on the same version that nautilus
<janimo> pitti, would building empathy with gtk2 result in smaller footprint?
<seb128> pitti, we are trying to move things away from gtk2 not to go backward
<seb128> janimo, well it mean it would not break a second webkitgtk on the CD
<janimo> ouch
<seb128> break->bring
<janimo> did not realize both webkits are there too
<seb128> that's what bring <pitti> ah, we added libwebkitgtk-3.0-0
<seb128>  (7.1 MB)
<janimo> right, I did not know webkit-2 was there
<pitti> we have had webkit/gtk2 for quite a while (lucid or so?)
<seb128> webkit is used by the music store (libubuntuone), the software-center, yelp
<seb128> empathy
<seb128> shotwell
<seb128> gwibber (but that will be fixed)
<seb128> ubuntu-sso-client
<pitti> apturl
<janimo> I did not realize those were not ported to a newer one. Seems very much work. Is Fedora and other GNOME 3 shipping distro in this same position?
<seb128> yes
<seb128> pitti, realistically we will need to have both versions on the CD, the rdepends will not be all ported this cycle
<pitti> ok
<seb128> downporting empathy would be quite some work and it would hit issues for desktop integration parts like nautilus
<pitti> so our remaining fallback is to drop Spanish and Portugese, and just keep English and Simplified Chinese
<janimo> seb128, porting an app to gtk3 and webkit 3 must happen in a single step ?
<seb128> janimo, there is no webkit-3 there, it's webkit-gtk2 or webkit-gtk3
<seb128> i.e same code but built with different gtk version
<janimo> ok
<seb128> you can't use 2 gtk version sin the same process
<seb128> so the webkit version you use needs to be using the gtk that your application
<tkamppeter> pitti, I have found the solution for the remaining problem. I will do another commit to the CUPS BZR later today and after that prepare one SRU (with one version number advance) for all outstanding bugs.
<tkamppeter> pitti, is there a CUPS still in the -proposed queue? If yes, which version? So that I know the next free one.
<pitti> tkamppeter: I rejected them all; you can use 1.4.6-5ubuntu1.2
<pitti> tkamppeter: as 1.4.6-5ubuntu1.1 is in natty-updates at the momemt
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, Oneiric part done, you can upload the CUPS package from the Debian BZR.
<Laney> could someone please score haskell-quickcheck up?
<Laney> I may have accidently uploaded some stuff which depends on it being built
<infinity> Laney: Done.
<Laney> cheers
<tumbleweed> any archive admins planning to look at new packages from Debian any time soon? Someone was asking me when golang will appear (there isn't an explicit sync request)
<pitti> tumbleweed: golang is sync-blacklisted, it won't appear
<pitti> tumbleweed: Gustavo said that the Debian package should not be released, as it's contrary to how upstream would like to ship this
<tumbleweed> pitti: ah, thanks
 * tumbleweed wishes blacklisting was more visible on LP
<pitti> tumbleweed: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<tumbleweed> yes, I know, but I can't keep its contents in my brain :)
<ScottK> debfx: I don't recall why Kubuntu branches are owned by core-dev.  I think it would be good if you could start a thread on kubuntu-devel so we can discuss this if you want it changed.
<debfx> ScottK: I've added it to the meeting agenda
<ScottK> debfx: I think it's more of a kubuntu-dev question than a kubuntu-council question, so I think some advance discussion would still be good.
 * cjwatson wonders if he can find IRC logs about that discussion
<ScottK> That would be useful.
<cjwatson> hmm, discussion from #ubuntu-devel on 2009-12-10 seems to indicate that you guys already said you wanted the seeds to be owned by kubuntu-dev, and I acknowledged
 * cjwatson tries to see if there was something later that countermanded that
<cjwatson> ScottK: http://irclogs.ubuntu.com/2009/12/10/%23ubuntu-devel.html#t21:17
<cjwatson> ScottK: should I consider that an old todo item and Just Do It?
 * ScottK reads
<cjwatson> the bit about LP was a red herring
<ScottK> cjwatson: I think so.
<ScottK> debfx: ^^^ Looks like you can take it off the agenda.
<ScottK> No wonder I couldn't remember a reason why it should stay core-dev.
<cjwatson> I think my memory may have been from the predecessor to kubuntu-dev
<cjwatson> which was sort of a general packagers team rather than an upload-privileges team
<ScottK> Makes sense as we have one of those.
<cjwatson> ScottK,debfx: pushed lp:~kubuntu-dev/ubuntu-seeds/kubuntu.oneiric - can you let committers know to start using that instead?
<ScottK> cjwatson: Thanks.
 * cjwatson goes round updating references
<ScottK> debfx: Would you please mail kubuntu-dev about this?
<cjwatson> how about kubuntu-mobile?
<ScottK> Yes.  That one too.
<debfx> ScottK: can do
<cjwatson> ScottK: kubuntu-dev as well, or some other team?
<ScottK> I think kubuntu-dev.
<chrisccoulson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: chrisccoulson
<cjwatson> pushed, will update references to that too
<cjwatson> ScottK,debfx: ^-
<ScottK> Thanks again.
<cjwatson> FWIW, the references I know about are in the cron job on people.canonical.com that updates the seeds mirrors (~ubuntu-archive/bin/update-seeds), cdimage/bin/run-germinate, and tasksel/ubuntu-seeds.pl
<cjwatson> ScottK,debfx: should be all done now
<apw> pitti, something is odd with lucid and maverick proposed for linux
<apw>      linux | 2.6.38-10.44 | lucid-proposed | source
<apw>      linux | 2.6.38-10.44 | maverick-proposed | source
<apw>      linux | 2.6.38-10.44 | natty-proposed | source
<apw> and linux-meta for that matter
<pitti> apw: err, WTF
<pitti> hmm hardy seems to have worked
<smb> pitti, Question is whether it is unf**ble
<pitti> we can (and should) certainly remove the faulty 2.6.38 versions from  l/m-proposed, doing now
<pitti> question is, how did that happen in the first place
<smb> pitti, Good that it can be undone. Then investigation can be done a bit more relaxed
<apw> pitti, you might want to check the linux-meta on maverick and natty as well
<pitti> apw: you mean s/natty/lucid/?
<apw>      linux | 2.6.38.10.24 | maverick-proposed | amd64, i386
<apw>      linux | 2.6.38.10.24 | natty-proposed | amd64, i386
<apw> pitti, i mean those two they look wrong in rmadison output
<pitti> apw: isn't 2.6.38.10.24 what is meant to be in natty? *confused*
<smb> pitti, Just checked at least for lucid and there is only a 2.6.32 package of linux there
<apw> pitti, heh yes probabally sorry getting jumpy :)
<smb> pitti, I mean checked in the canonical-kernel-team ppa
<pitti> yes, it was the copying which went wrong, not the PPA
<smb> pitti, Right, it seemed unlikely but I wanted to make sure
<pitti> l-b-m looks ok
<pitti> linux-ports-meta is wrong in lucid
<pitti> oh, I bet it's how copy-proposed-kernel.py calls syncSources
<pitti> https://launchpad.net/ubuntu/+source/linux looks better now
<tkamppeter> pitti, the SRU (5 at a time) is ready now.
<tkamppeter> pitti, bug 711779, bug 782309, bug 790378, bug 792309, bug 793265.
<ubottu> Launchpad bug 711779 in cups (Ubuntu Natty) "AirPrint support in the Avahi patch for CUPS does not work" [Medium,Fix committed] https://launchpad.net/bugs/711779
<ubottu> Launchpad bug 782309 in cups (Ubuntu Natty) "Printing encrypted PDFs on a non-PostScript printer gives a blank page" [High,Fix committed] https://launchpad.net/bugs/782309
<ubottu> Launchpad bug 790378 in cups (Ubuntu Natty) "Very high memory consumption by pdftopdf" [Medium,Fix committed] https://launchpad.net/bugs/790378
<pitti> tkamppeter: thanks
<ubottu> Launchpad bug 792309 in cups (Ubuntu Natty) "cups announcing wrong port numbers on avahi" [Medium,Fix committed] https://launchpad.net/bugs/792309
<ubottu> Launchpad bug 793265 in cups (Ubuntu Natty) "If the service name is too long, printer does not get advertized via DNS-SD" [Medium,Fix committed] https://launchpad.net/bugs/793265
<pitti> https://launchpad.net/ubuntu/+source/linux-meta cleaned up
<pitti> https://launchpad.net/ubuntu/+source/linux-ports-meta cleaned up
<pitti> smb, apw: ^ I think all faulty versions are removed nwo
 * pitti now goes to copy the correct versions and fix copy-proposed-kernel.py
<cjwatson> can it actually be undone properly?  wouldn't we need LP assistance to wind versions backwards later?
<smb> pitti, Thanks. Right and find out whether you are allowed to do those copies now
<cjwatson> (which, for the record, I'd approve of doing in -proposed)
<pitti> that's what I'm afraid of as well; let's check
<pitti> copy-package.py for lucid linux succeeded, anyway
<pitti> https://launchpad.net/ubuntu/+source/linux will take some 20 minutes to actually make it appear, though (it only shows published versions)
<smb> So we'll look back in 20min or so
<ScottK> Shows right away on https://launchpad.net/ubuntu/+source/linux/+publishinghistory
<pitti> ah, nice
<zyga> is there a way to have per-dist .pbuilderc?
<zyga> I'd like to have a feedback loop where I can feed my repository with new packages
<zyga> and do this per-distribution with pbuilder-dist
<zyga> or should I scrap the concept and script this with pbuilder + custom configs + appropriate options to load them
<ScottK> siretart: If you have a moment, would you please have a look at https://bugs.kde.org/show_bug.cgi?id=274666 - We're suffering from this problem in Ubuntu as well and could use a bit of help with porting to the current libav.
<ubottu> KDE bug 274666 in general "ffmpegthumbs-4 6 3 fails to build with libav-0 7_beta2 (Gentoo bug #369515)" [Normal,Unconfirmed]
<pitti> apw, smb: all copies done; https://launchpad.net/ubuntu/+source/linux/+publishinghistory etc. look good now
<apw> pitti, do you think we'll have problems uploading to the PPA now with a 'lower' version number or is that ok
<pitti> apw: none of this affected the PPA at all, so no
<pitti> the problem was that the PPA's natty versions accidentally got copied to lucid-/maverick-proposed
<smb> Looks good so far. Thanks.
<pitti> I fixed copy-proposed-kernel.py now, my bad *brown paperbag*
<pitti> so far this apparently worked because we had one release staged up only
<apw> pitti, thanks sounds good
<pitti> I sent a mail to u-d-announce@ about that (how to check and recover from the situation)
<stgraber> bdrung, cody-somerville, persia, geser: ping (DMB meeting in #ubuntu-meeting)
<siretart> ScottK: that enum has been renamed. use AVMEDIA_TYPE_VIDEO instead of CODEC_TYPE_VIDEO
<ScottK> siretart: Thanks.  I'll try that.
<siretart> ScottK: in 0.6, the type CodecType was already deprecated. 0.7 now removes quite a number of types that were already deprecated in 0.6. The AVMediaType seems to be the most often used one
<ScottK> siretart: Is there some handy list I can look at if we hit other issues?
<siretart> ScottK: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=doc/APIchanges - that files is also installed in the libavcodec53 package in usr/share/doc...
<ScottK> siretart: Thanks.
<siretart> ScottK: if you find some other API breakage that was not deprecated in 0.6, then I'd cosider it as a bug in libav and would fix that in the 0.7 series
<ScottK> siretart: I'll let you know.
<siretart> thanks
<didrocks> doko: hey, it seems that we have an issue with Qt and gcc 4.6 making unity-2d crashing at when showing an expose-like event (places, scale, worspace switcherâ¦): https://bugs.launchpad.net/ubuntu/oneiric/+source/qt4-x11/+bug/791213 do you have any idea how we can help debugging that?
<ubottu> Ubuntu bug 791213 in qt4-x11 (Ubuntu Oneiric) "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall()" [Critical,Confirmed]
<hallyn> question on ubuntu's gcc and FORTIFY_SOURCE.  The manpage says that to disable the default (=2), use -D_FORTIFY_SOURCE=0.  But when I (or actually, configure) do that, gcc complains that it is redefined.
<saamm> hello, I am having a weird problem in Ubuntu 11.04. I disabled Automatic login and now 'Ubuntu' logs me into classic gnome. Earlier I was getting Unity interface.
<hallyn> saamm: after choosing a username you should be able to select the window manager at the bottom
<hallyn> saamm: after you choose 'Ubuntu' once, it'll redefault to that
<saamm> hallyn, you mean at gdm?
<hallyn> yes
<cjwatson> hallyn: -U_FORTIFY_SOURCE
<hallyn> kees: ^ (re FORTIFY_SOURCE)
<saamm> hallyn, I did that, but it always logs in to classic mode. I must have tired it 10 times. Also ccsm shows unity plugin enabled
<hallyn> cjwatson: yes, that's listed as another option.  lemme try that, but manpage claims both should work?
<hallyn> cjwatson: thanks, and welcome back :)
<smoser> someone is reporting to me that 'apt-get upgrade' failed for them on 11.04.  What is the best way to collect more infomration?  (I think there is a way to get dpkg failure logs, right?)
<smoser> user said the 'apt-get update' then 'apt-get upgrade'
<saamm> hallyn, also doing a --compiz replace gets me unity but then both top and bottom panels from classic gnome stays as well
<hallyn> saamm: i used to just to "unity --reset' when that happened to me
<doko> didrocks: looking ...
<saamm> hallyn, yep I also did that, same thing happens --top and bottom panel stays. Also when I logout and come back, I again get classic mode :(
<hallyn> saamm: think you'll want to ask on #ubuntu-desktop
<saamm> ok
<hallyn> why is configure trying to use '-Rlib' ?
<dholbach> micahg, regarding bug 793567: do you think anarcat tried to subscribe ubuntu-sponsors?
<ubottu> Launchpad bug 793567 in aegir-provision (Ubuntu) "remove from ubuntu" [Undecided,New] https://launchpad.net/bugs/793567
<tumbleweed> dholbach: we were discussing this in #ubuntu-motu
<dholbach> ah ok
<dholbach> nm then
<dholbach> I just saw it pop up on the sponsors mailing list
<micahg> dholbach: it's already been removed from Ubuntu, so we're good
<tumbleweed> yeah, package is already removed in oneiric. He wants removal in stable releases, though...
<dholbach> yoohoo
<dholbach> oh ok
<ScottK> siretart: That fixed it and seems to be the only issue in kdemultimedia.
<ScottK> Thanks again.
<micahg> tumbleweed: are you sure, it wasn't removed from squeeze, it just doesn't exist in squeeze
<tumbleweed> micahg: it was removed from testing before squeeze froze
<micahg> tumbleweed: exactly
<micahg> so, I guess it never was in a stable release in Debian :-/
<tumbleweed> sucks to be us :)
<micahg> unfortunately, I'm sure we have 100s of apps like that
<siretart> ScottK: Cool! Great to hear
<ScottK> I sent the patch upstream too.
<tumbleweed> micahg: yeah, the corner of the archive that rots quitely. Unless this thing causes real damage, that's the best answer
<tumbleweed> *quitely
<tumbleweed> gr@sp twice
<mateusz> HI
<mateusz> apt-build is not respecting my optimization parameters
<mateusz> what's wrong ?
<mateusz> I seleted O3 and core2 while it does -O2 in compilation process
<maco> pitti: fixed
<seb128> kees, jdstrand, mdeslaur: hey, could somebody from the security team review the accountsservice mir (and maybe the apg one as well) some day, it's required for the new gnome-control-center user account dialog
<jdstrand> seb128: sure
<seb128> jdstrand, thanks
<seb128> jdstrand, the bugs are assigned to the security team (bug #785680, #785682)
<ubottu> Launchpad bug 785682 in apg (Ubuntu) "[MIR] apg" [Undecided,New] https://launchpad.net/bugs/785682
<ubottu> Launchpad bug 785680 in accountsservice (Ubuntu) "[MIR] accountsservice" [Undecided,New] https://launchpad.net/bugs/785680
<SpamapS> pitti: yes I had some other pressing matters last week, I'll get through some SRU's today for sure.
<kees> chrisccoulson, kirkland: did you mean to be expired from ubuntu-sponsors?
<chrisccoulson> kees, no, i just never asked anyone to renew my membership ;)
<chrisccoulson> kees, can you do that?
<kees> yup
<kees> chrisccoulson: done!
<chrisccoulson> kees, thanks :)
<kees> np :)
<cjwatson> jelmer: do you think switching to samba4 (at least the clients) in oneiric is likely to be feasible?
<jelmer> cjwatson: hmm, that's a tough call
<jelmer> the clients are in relatively good shape compared to the server (which is nowhere ready yet in terms of file serving in samba 4)
<cjwatson> I'm mostly just comparing the enormous size of smbclient with the tiny size of samba4-clients
<jelmer> however, there are still inconsistencies in the options in the configuration file that is used by both samba 3 and samba 4 (/etc/samba/smb.conf) - and these configuration files are used by both the clients and the servers
<cjwatson> and wondering what I'm missing :)
<jelmer> cjwatson: samba 4 uses shared libraries, samba 3 doesn't (and links pretty much everything into every binary)
<bdrung> lool: please unsubscribe ubuntu-sponsors once you sponsored a bug
<cjwatson> jelmer: is that at all fixable in samba 3?
<kees> chrisccoulson: btw, why is 784542  a dup of 548866 ?  548866 is about "on update", and 784542 is about "on firefox restart"
<chrisccoulson> kees, it's all part of the same problem
<kees> okay
<jelmer> cjwatson: in practice, it's very hard (requires moving code around, changing function signatures, etc). upstream everybody is focussing on getting samba 4 to rock - we've betted on two horses for way too long already.
<kees> is there hope to get the on-restart part fixed? it's very annoying. :)
<jelmer> (betted? bet? bat?)
<chrisccoulson> kees, i'm not sure. it's a pretty hard problem to solve properly (in a way that doesn't break the preferences system)
<chrisccoulson> perhaps we could stop setting default preferences in an extension ;)
<chrisccoulson> that would work around it
<jelmer> cjwatson: is this about the cd size?
<cjwatson> jelmer: yeah, I was hoping that some of that juicy 14MB might be recoverable
<cjwatson> though I understand if it's infeasible for now
<jelmer> cjwatson: is there a list of packages that are meant to be included in the cd image somewhere?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/{required,minimal,standard,desktop-common,desktop,live}
<cjwatson> oh and ship-live
<jelmer> thanks
<cjwatson> eek, why is build-essential in ship-live?
<kees> chrisccoulson: well, I don't understand the details of it. why is the "middle" pref reset at all?
 * cjwatson nukes that
<micahg> cjwatson: is that what pulls in the compiler or is that in separately?
<cjwatson> micahg: partially - see the seeds, there's a comment
<jelmer> cjwatson: my guess is that we might be able to make samba4's smbclient ready for inclusion (a bit of work to finish the reconciliation of the configuration files). However, I'm not sure if fixing a mix of samba3 and samba4 will actually help. samba4-clients has a couple of shared library packages it depends on; unless the other samba packages use that (or if we start including evolution-mapi on the main cd) I don't think it will make a significant
<jelmer>  difference.
<cjwatson> ok
<ScottK> cjwatson: Don't we need build-essential for building restricted drivers?
<infinity> ScottK: No.
<ScottK> OK.  We need something.
<infinity> ScottK: Notably, build-essential pulls in dpkg-dev, which you don't need for compiling.
<stgraber> the drivers seem to depend on both make and dkms, dkms has "gcc, make | build-essential | dpkg-dev" in its Depends, so we should only end up with drivers + make + gcc on the CDs
<infinity> Which seems reasonable.
<ScottK> stgraber: Thanks.
<jelmer> cjwatson: actually, related to this; I was wondering if it was possible to have ubuntu-desktop depend on "smbclient | samba4-clients" but I can't figure out how to do that in ubuntu-meta. Is that possible?
<infinity> jelmer: See xubuntu-meta from hardy, notably the "s/gnumeric-gtk/gnumeric-gtk | gnumeric/" on debian/xubuntu-desktop.substvars in debian/rules.
<infinity> jelmer: Basically, you can't make the task have ORed depends (cause tasks don't work that way), but that's fine, cause we only use tasks for the initial install, but you can make the metapackages have ORed depends to give users post-install flexibility.
<jelmer> infinity: that's the sort of thing I was looking for - thanks!
<cjwatson> ScottK: gcc is in desktop for that; build-essential was annotated with a comment saying that it was for building packages
<micahg> cjwatson: Ubuntu Installer no longer seems to show up in the -changes mailing list as the from for syncs, is this a permanent change?
<ScottK> cjwatson: OK.  stgraber's explanation cleared it up for me.
<cjwatson> micahg: that only ever happened when the sync requestor didn't have a public e-mail address on lp
<micahg> cjwatson: istr mine showing up as Ubuntu Installer as From with my address in the e-mail
<micahg> cjwatson: https://lists.ubuntu.com/archives/oneiric-changes/2011-May/001686.html
<slangasek> jelmer: fwiw, one reason samba4-clients might help despite the added sharedlib dependencies is that there are more programs in the clients package than there are shared libraries...
<cjwatson> micahg: not aware of anything having changed there
<micahg> cjwatson: ok, is there someone I should poke or somewhere to file a bug?
<cjwatson> jelmer: also, the point of the metapackages is to pick preferred alternatives for things; all the business with putting ored deps in them kind of misses the point IMO
<infinity> micahg: Is it a bug?
<cjwatson> micahg: if it's showing up with your name now, that's intended behaviour
<micahg> cjwatson: well, it was showing before that it was sync'd vs looking like I uploaded it
<infinity> micahg: It just depends on how the person driving the sync does it.  If they give your LP username as an argument, it comes "from you", if they give none, it comes from archive@
<infinity> micahg: Coming from archive@ just means "sync with no one to blame".  Syncs *should* ideally all look like they were uploads from the requestors.
<micahg> oh, hmm, it showing up differently in LP now, maybe that explains it
<micahg> infinity: before in LP ISTR it showing up like a sponsored upload
<jelmer> slangasek: that's a good point
<jelmer> cjwatson: the main reason for this is that smbclient and samba4-clients conflict - I currently can't have ubuntu-desktop installed because it explicitly requires smbclient
<slangasek> why does it do that, anyway? :)
<slangasek> smbclient isn't the sort of thing the desktop should depend on directly
<infinity> slangasek: I suspect it's because some nautilus feature depends (or depended?) on it, but not strongly enough to justify a recommends, but we wanted it functional out of the box.
<slangasek> nope
<infinity> slangasek: And that's my recollection from, like, 5 years ago.
<slangasek> nautilus always used libsmbclient
<infinity> Something called smbclient in ugly ways.  But danged if I recall what.
<jelmer> slangasek: didn't some gnomevfs thing once use smbclient, for licensing reasons?
<infinity> ^
<slangasek> I really don't think so
<infinity> If that's no longer the case, and provably so, you'd make a lot of people happy by removing it from the CDs. ;)
<slangasek> I recall that it always used libsmbclient, and gnomevfs integration was one of the problem areas identified when Samba was relicensing to GPLv3
<jelmer> maybe it's that cups uses smbspool from the smbclient package for smb printing?
<infinity> jelmer: Possibly.
<slangasek> well, that would make me sad then
<infinity> I could have sworn it was something related to gnome filesystemy stuff though.
<slangasek> in actual fact, the /reason/ for the dependency on smbclient is "hysterical raisins"
<slangasek> because it's in version 1 of the seed
<ohsix> hi, where should i, or who should i talk to to make a suggestion for a test to be added to fwts
<infinity> slangasek: I imagine doing a reverse-suggests search on all of ship-live and lesser would get you a good hint at what package might want it?
<infinity> (And if that comes up empty, let it burn?) :P
<micahg> ohsix: I think you can just file a bug, I think cking looks at those
<slangasek> infinity: cups-client does Recommend smbclient, so ultimately I guess we have to keep it for this
<slangasek> but I still don't think it belongs directly seeded in platform/desktop-common
<ohsix> micahg: okie dokie
<infinity> If it's recommended, I see no reason to seed it at all.
<slangasek> and that would fix jelmer's conflicts problem
<ohsix> micahg: it's the lack of data from /sys/class/power_supply/*/current_now if you're curious; leads to the ui for the battery never showing an estimate (upower no longer calculates it when energy-rate/current_now is 0, hal did)
<infinity> I suspect that recommend probably used to be a suggests, hence the seed kludge.
<slangasek> the comment in the seed suggests printing wasn't even on the radar at the time it was added :)
<infinity> (Or, rather, seeds pre-date install-recommends-by-default, which would be the real issue)
<slangasek> anyway, excising it
<infinity> But I *still* seem to recall it being gnome-network-filesystem-related.  So, I'm probably reaching that part of old age where you just start randomly making up history.
<jelmer> slangasek: that indeed seems like a better solution; thanks!
<slangasek> seed changed
<lool> bdrung: I couldn't unsubscribe ~ubuntu-sponsors as I am not a member -- I got poked directly to sponsor this because I had touched the package in the past
<bdrung> lool: then i invite you to join the sponsors team
<bdrung> :)
<lool> bdrung: Eh I was a member in the past
<lool> I think I expired and opted not to renew as I wasn't really doing much sponsoring  :-/
<bdrung> lool: the correct fix is to do more sponsoring instead of expiring ;)
<lool> Eh
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: chrisccoulson, bryceh
<broder> could someone accept the sru nomination for bug 778615 for me please?
<ubottu> Launchpad bug 778615 in grub-gfxpayload-lists (Ubuntu) "gfxpayload-lists should blacklist VMware virtual VGA adapters" [Undecided,Fix released] https://launchpad.net/bugs/778615
<hallyn> pitti: hey, is there a particular reason why ubuntu's udev doesn't do 'modprobe scsi_wait_scan'' in extra/initramfs.top like debian's does?
<hallyn> (i assume there is, and vaguely recall asking you before, but maybe it wasn't you I asked)
<SpamapS> hallyn: probably to avoid a delay when there aren't any scsi devs?
<SpamapS> hallyn: anyway, I'm satisfied having taken a look at what scsiwait_scan does ... I'm going to accept the upload
<hallyn> SpamapS: ok, thanks
<hallyn> SpamapS: maybe i should have mentioned redhat does it in multipath-tools pkg
<hallyn> pretty sure ppetraki pointing out that rh does it is what led me to try it
<SpamapS> hallyn: initramfs is special.. kind of like the kernel.. sometimes we have to do stuff that looks a bit daft on the surface
<hallyn> yup
<SpamapS> hallyn: so the versions for the lucid/maverick updates are really, really close.. 0.4.8-14ubuntu11.2 and 0.4.8-14ubuntu11.2   ... I'm concerned because the next update will then require ~'s to keep them in the appropriate sequence.
<SpamapS> err
<SpamapS> 0.4.8-14ubuntu11.1 for lucid
<SpamapS> hallyn: In this case I'd change the maverick upload to 0.4.8-14ubuntu11.10.10 .. this way it will always be higher than any lucid updates
<hallyn> what happens if a lucid update has higher version?
<SpamapS> on upgrade to maverick, the new package isn't installed
<hallyn> i thought that didn't matter - that it only mattered that it be higher than any previous upload for that version
<SpamapS> no you always have to be superceded by the next release's packages
<SpamapS> superseded even
<hallyn> ok, is that something you can change in-flight?
<SpamapS> no I'd need to reject and then re-upload
<hallyn> all right
<micahg> SpamapS: hallyn, here's the guide we in the security team use for versioning in these situations: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
<hallyn> you want me to re-upload, or were you going to?
<hallyn> micahg: yeah, i *thought* i was following that guide...
<SpamapS> yeah, the sec team has it down to a science. :)
<hallyn> maybe i should re-read
<SpamapS> 2.0-2 in two releases         2.0-2ubuntu0.5.04.1 and 2.0-2ubuntu0.5.10.1
<hallyn> yeah i see, bc i'm rereading
<hallyn> :)
<SpamapS> hallyn: do you have upl rights for m-t ?
<hallyn> yeah
<SpamapS> ok cool.. I'll reject and you can upload again with 0.4.8-14ubuntu11.10.10.1
<SpamapS> that way we can make the next lucid update (if there is one) 0.4.8-14ubuntu11.10.04.1 and all will be in line with those guidelines.
<SpamapS> BTW, somebody should really build this into dch
<hallyn> true
<SpamapS> and maybe even into lintian
<SpamapS> or dpkg-buildpackage
<SpamapS> hallyn: otherwise it looks good for maverick too so I'll accept the new version as soon as you upload it.
<hallyn> have you rejected already?  (haven't gotten the email)
<SpamapS> just did
<hallyn> SpamapS: dput'ed
<hallyn> and NOW I think I"ll go look at kernel  (though i've got some blogging to do, too,  hmm)
<hallyn> oh,
<micahg> SpamapS: hallyn, that's not good, that version in lucid-proposed is now ahead of natty
<micahg> and oneiric for that matter
<micahg> SpamapS: hallyn, for oneiric, you can just merge from Debian, but for maverick/natty, you'll need a new version in proposed and updates before the lucid one can go out
<micahg> SpamapS: hallyn: the correct way to have done that if all those changes are SRU worthy was to either collapse all the changes under a single changelog targeted to $RELEASE-proposed or to add a changelog on top of all the changes targeted to $RELEASE-proposed with a proper -proposed version, changing all the changelog entries to $RELEASE-proposed is wrong
<SpamapS> hm
<SpamapS> damn
<SpamapS> hallyn: ok, so can you please a) upload the fixes to oneiric as 0.4.8-14ubuntu13 (or as micahg suggests, merge from debian) .. then upload to natty-proposed as 0.4.8-14ubuntu12.11.04.1
<SpamapS> I'll go flog myself with 20 lashes
<SpamapS> This is the one step I think is most frustrating about preparing SRU's.. checking the published versions
<micahg> SpamapS: rmadison is your friend :)
<micahg> SpamapS: at this point, I'd just suggest making sure everythings in the proper succession by the time that the -proposed uploads hit -updates
<SpamapS> micahg: you know.. I've known about it for a while.. why don't I use it more? :-P
<cody-somerville> Whats the bug # for this SRU?
<SpamapS> there are 6 bug #'s ...
<SpamapS> 488285 644481 660597 686832 713237 789229
<micahg> cody-somerville: https://launchpad.net/ubuntu/lucid/+source/multipath-tools/0.4.8-14ubuntu11.1
<hallyn> 'or merge from debian' -> just cause i f'd up doesn't mean i woudln't punch you if you were in range
<micahg> hallyn: ?
<hallyn> micahg: (that was at SpamapS :)  i've had a few attempts at debian merge already, and one is awaiting test
<micahg> hallyn: ah, ok :)
<hallyn> but not having the hardware makes it always, in teh end, too scary to upload
<hallyn> micahg: thanks for the tips.  I gather you're saying do an empty version bump for natty and oneiric, right?
<SpamapS> hallyn: that should be fine yes
<micahg> hallyn: well, natty is missing the ubuntu11 change, so idk if it needs it
<hallyn> eh what?
<SpamapS> it does and should get it.. as 0.4.8-14ubuntu11.11.04.1
<micahg> hallyn: for oneiric, if you can't merge from Debian before the natty upload hits updates, then yeah, an empty version bump would be good
<hallyn> ok, i'll put a note in my tickler for next week to
<hallyn> haha
<hallyn> that won't work
<hallyn> i'll just bump the oneric one now, else it won't likely happen for > 2 weeks
<SpamapS> yes please do that. :)
<hallyn> SpamapS: yo'ure saying i never pushed a natty fix?
<SpamapS> hallyn: you did, w/ the wrong version
<hallyn> ok
<SpamapS> which I'm rejecting right now. ;)
<hallyn> right-y-o
<hallyn> should i then collapse the changelog entries while i'm at it, or leave it as is for symmetry with the other releases?
<SpamapS> hallyn: meanwhile the maverick one looks fine, but I'm holding off until the natty/oneiric bumps are done
<SpamapS> I personally don't see a problem with multiple unreleased versions.. but maybe wiser people do.
<SpamapS> In this case, I'd say maintaining symmetry w/ the update is probably better.
<cody-somerville> SpamapS, Have you already accepted all the uploads or can you still reject some of the incorrectly versioned uploads to -proposed?
<micahg> SpamapS: the maverick one should be rejected I think and the non-maverick changelog entries restored to what they should be IMHO
<micahg> cody-somerville: only one accepted w/the bad version so far is lucid-proposed
<micahg> cody-somerville: you have an idea?
<cody-somerville> So basically whats happened here is that the version currently in oneiric was 'backported', correct?
<micahg> cody-somerville: yep
<hallyn> minus one intermediate change, yes
<ohsix> uhohbig problem with 2.6.38-10, picture forthcoming
<ohsix> (same problem i was getting with mainline .39 a week ago)
<ohsix> http://img847.imageshack.us/img847/2017/dscn0955v.jpg
<ohsix> er wrong chanel :O
<micahg> hallyn: if something's been removed, you might want to collapse all the included entries into one changelog crediting the appropriate individuals since it's not a true backport
<cody-somerville> indeed.
<cody-somerville> Lets reject the uploads to maverick and natty.
<cody-somerville> It doesn't look like multipath-tools has made it into http://archive.ubuntu.com/ubuntu/dists/lucid-proposed/main/binary-i386/Packages.bz2 yet. If you hurry, you might be able to delete the bad versioned upload and then we could do things correctly for lucid
<cody-somerville> SpamapS, ^^
<cjwatson> broder: nomination> done
<broder> thanks
<hallyn> micahg: and if SpamapS catches that soon enough, then i should call the lucid version 0.4.8-14ubuntu4.10.04.1 with a single collapsed changelog entry?
<micahg> hallyn: yep
<broder> cjwatson: although apparently i might have imagined gfxpayload=keep not working, or maybe it got fixed since the last time i tested...
<SpamapS> cody-somerville: I've not done anything like that before. How does one delete an upload that has been accepted and built?
<cody-somerville> cjwatson, Can you advise how to best resolve this situation? An SRU has been uploaded and accepted into lucid-proposed whose version is greater than maverick, natty, and oneirc.
<sbeattie> hallyn: even 0.4.8-14ubuntu4.1 would be fine, you'd only need the release version embedded if the version strings up to that point would be the same (e.g. 0.4.8-14ubuntu11)
<micahg> sbeattie: no, maverick has the same version
<cody-somerville> cjwatson, there are also similarly versioned SRUs in the queue not yet accepted for maverick-proposed and natty-proposed.
<sbeattie> micahg|hallyn: ah, right, I missed that, sorry. micahg is correct.
<cjwatson> cody-somerville: ask #soyuz or #launchpad-ops or something for help - I'm too tired to make judgements, and I still have a washing machine to fix before I go to sleep
<cjwatson> in principle, winding versions backwards in -proposed for this kind of situation has my approval providing that some kind of message goes out to users about it
<cody-somerville> cjwatson, Thanks. Thats what I was looking for.
<ScottK> See pitti's u-d-a message about the kernel from earlier today for a template.
<micahg> it just hit archive.u.c
<micahg> for some reason, I thought this stuff hit almost right away...
<SpamapS> At this point, isn't the simplest solution to just update natty/maverick/oneiric to also be higher than this proposed update?
<cjwatson> micahg: takes until the publisher runs, which starts at :03 and takes a substantial fraction of the hour to complete
<SpamapS> The *only* reason this is troublesome is for upgrades. This will not be troublesome on upgrade if the updates are available on those releases.
<cody-somerville> SpamapS, No. The more changes we make, the greater the risk. Its safer to just delete this package from -proposed all together and halt processing this SRU.
<micahg> cody-somerville: I think an update was planed for all the releases anyways, the only problem is the versioning
<SpamapS> The risk right now, is that a lucid -> maverick upgrade will not regress
<SpamapS> that seems like a risk we should be comfortable with
<SpamapS> The risk becomes zero if we accept the maverick/natty updates and serge bumps oneiric.
<Laney> are users required to continue having -proposed/-updates enabled when they upgrade?
<micahg> SpamapS: well, the changelogs should be fixed for maverick/natty
<SpamapS> Laney: that I don't know.
<cody-somerville> Nothing has made it to -updates
<SpamapS> micahg: "fixed" or "done the way we prefer" .. ?
<cody-somerville> We should remove the version currently in -proposed
<SpamapS> To avert what risk?
<cody-somerville> send an e-mail out to let folks know what to do if they happened to grab that update
<micahg> SpamapS: it's disingenious at the moment sincce it's not really a backport, also, changing the release target for previous entries is just bad
<SpamapS> cody-somerville: I'm sorry if I'm being obtuse here.. but I still fail to see the danger.
<Laney> it ties all of the SRUs together
<SpamapS> checking now, so far all symbols are the same on all dependent libraries
<cody-somerville> SpamapS, Every update has risk. Every change made has a risk. Introducing more changes now hastily to work around mistakes and lack of adherence to the SRU policy introduces additional risk whereas deleting an update from -proposed is bringing us back to where we were before and acceptable for -proposed.
<micahg> Laney: it would make sense that if you have updates enabled, the only upgrade path is with updates enabled
<micahg> cody-somerville: the only change that shouldn't have been in the upload was a bad changelog AFAIK
<SpamapS> cody-somerville: I see your point. To bring a counterpoint to bear, the change thats in lucid, is going into maverick, and natty as well, and the source packages in maverick and lucid release pockets are identical ... so.. this is just changelogs and builds as micahg suggests..
<SpamapS> cody-somerville: to me, if we fix the versions in the later -proposed and -updates to be after this one, we leave any users who might have been exposed to this problematic version in a better place... we kind of have to do this anyway.
<sbeattie> micahg: I think Laney's point is that it now ties the promotion from proposed to updates of all the SRUs together, in that in order for lucid's version to be published, all the newer releases have to have already been verified and published first (or at the same time).
<Laney> right, you get the exact same problem at -updates time again
<cody-somerville> I want to fix the versioning. The current versioning in lucid is misleading and wrong. Not fixing it could impact future SRUs we do for this package. Reverting and following the established policies and practices is safer in my opinion then just trying to massage the mistake into working.
<Laney> whereas with the proper versioning it can be done independently
<micahg> cody-somerville: all versions were being SRUd already
<sbeattie> micahg: given that multipath is a bit special (see hallyn's comments about not wanting to publish the merge due to not having the hardware to test) means that it's going to be hard to dredge up testers for these SRUs.
<Laney> also, ahem, don't we have to get the update blocked before the mirror push?
<sbeattie> and so it's very likely that we might get someone willing to test on lucid, but not on a non-LTS release.
<cody-somerville> Furthermore, I have concerns about if some of the changes qualify under the SRU policy.
<cody-somerville> sbeattie, great point.
<cody-somerville> Lots of uncertainty here.
<cody-somerville> Which is why I think we should delete the upload to -proposed so that we have time to make sure we do this right.
<SpamapS> cody-somerville: 50% of the changes that go into our SRU's do not qualify under the strictest letter of the SRU policy. Anything below High really shouldn't be SRU'd.
 * micahg is beginning to agree with cody-somerville 
<micahg> SpamapS: core packages should be held to a different standard than most
<SpamapS> I agree with cody too. I only bring up the alternative because it seems that we have to update the later releases anyway.
<SpamapS> <sigh>
<SpamapS> I am sorry for the mistake guys. If you need me to do anything ping me. Otherwise I think I'll just step back from the discussion.
<ScottK> SpamapS: You're the one with the access needed for fixing, whatever that turns out to be, so don't step too far back.
<SpamapS> I may not be able to do that, as I don't have direct queue access, only LP queue access.
<SpamapS> But understood.
<hallyn> SpamapS: no no, *I*'m sorry for the mistake.  let's follow cjwatson's advice about where to go ask
<cody-somerville> lamont, Are you around?/Have the necessary permission bits to remove a package from lucid-proposed?
<SpamapS> Laney: there's no commandline option to disable carrying them forward in do-release-upgrade
<SpamapS> Laney: since you asked earlier. :P
<Laney> I wonder what it actually does in its sources.list munging
<Laney> anyway, shawshank redemption time
 * Laney waves
 * cody-somerville waves back to Laney.
<SpamapS> cody-somerville: I don't want to duplicate effort. Are you asking around in #launchpad-xxx channels?
<cody-somerville> SpamapS, Just pinged the LOSA team. No response as of yet.
<cody-somerville> oh, there we go
<SpamapS> ok, I'll be around for the next 90 minutes if you need me for anything
<cjwatson> I tend to agree with Cody here, I must say - let's not hack around later releases to cope with an SRU mistake that hasn't been released to -updates yet
<ScottK> SpamapS: Oh.  I thought you had shell access.  You'll want to look north for a archive admin in your TZ that has shell access.
<cody-somerville> Chex, Hi. An incorrectly versioned SRU was uploaded and accepted to lucid-proposed. The consensus is that the package should be removed.
<cody-somerville> Chex, Are LOSAs able to help with that?
<lamont> cody-somerville: the power, probably.  the knowledge?  I'd be flying blind
<Chex> lamont: ah ok, I wasn't sure myself
<sbeattie> pitti periodically deletes packages from -proposed that haven't received testing/feedback in a reasonable; I'm not sure where/how he does this.
<sbeattie> s/reasonable/reasonable amount of time/
<SpamapS> Heh.. it usually has instructions on http://people.canonical.com/~ubuntu-archive/pending-sru.html but there are no packages to clean up ATM
<broder> slangasek: out of curiosity, how far are we from being able to install a 64-bit kernel on a 32-bit userland with multiarch?
 * SpamapS digs in the tools
<micahg> broder: umm, don't you mean the other way around?
<slangasek> broder: well, wasabi popped into #multiarch the other day and worked through the necessary package changes to do so... libbz2 -> Multi-Arch: same, and three other util packages Multi-Arch: foreign, and you're there :)
<SpamapS>             print 'lp-remove-package.py -y -u $SUDO_USER -m "moved to -updates" -s %s-proposed %s' % (
<lamont> micahg: a 32-bit kernel won't support 64-bit userspace
<micahg> lamont: oh, I guess this is assuming 64 bit hardware...
<SpamapS> I believe that has to be done w/ shell access
<lamont> micahg: what else is there?
<slangasek> broder: frankly I completely forgot about that use case because I've been running 64-bit for so long, else I would've done it in natty
<cjwatson> SpamapS: what's the package name?
<SpamapS> cjwatson: multipath-tools
<broder> slangasek: every once and a while i want to do it for random small things. at the moment, i'm screwing around with a bitcoin miner for random entertainment value, but it only runs on 32-bit
<slangasek> broder: well, it's straightforward for you to make these changes in oneiric now if you want to do it
<cjwatson> SpamapS: removed, pending the next publisher run
<cjwatson> SpamapS: whether this will let you later upload a lower version, I don't know
<cjwatson> that may or may not require assistance from a Soyuz expert
<SpamapS> cjwatson: thanks very much. I'll send out the "oops" email once the archive is updated.
<cjwatson> at least it wasn't there for very long
<ohsix> how do these numbers map to something i can read the changelog of in git? 2.6.38-9.43
<cody-somerville> cjwatson, Kudos for your help.
<ohsix> (the next is -10.44)
<micahg> ohsix: you might want to ask in #ubuntu-kernel
<SpamapS> indeed, and in fact, I've tested the binaries on maverick and natty VM's, they actually work fine... its not the end of the world if somebody with -proposed enabled accidentally keeps them.
<ohsix> micahg: ok, a bit dead, thought someone might know offhand
<micahg> ohsix: yeah, it's EOD in half the US and Eurpoe
<broder> slangasek: do i just need to change all of linux-image-`uname -r`'s dependencies to be multi-arch: foreign?
<SpamapS> Hopefully with the reverted messages that I'll post in the bug reports, and a message to u-d-a .. it should be enough for users to find and respond accordingly.
<ohsix> micahg: i see things in the changelog for .4 to .6, that might be enough
<hallyn> SpamapS: what is u-d-a?
<EagleScreen> should new users in admin be able to install updates with packagekit and polycikit?
<ohsix> micahg: just to be sure this channel is for packaging and other development right?
<SpamapS> hallyn: ubuntu-devel-announce .. or maybe its just ubuntu-devel.. I haven't looked again at the earlier mail from pitti
<micahg> ohsix: for stuff in main for the archive, yes
<slangasek> broder: the ones that provide only interfaces in /usr/bin to their revdeps, yes
<micahg> SpamapS: he sent it to u-d-a
<ohsix> micahg: ok thanks
<slangasek> broder: oh, the bzip2 thing didn't apply to the kernel at all, that was when wasabi decided to cross-grade his system from i386 to amd64 for kicks :P
<broder> slangasek: and bzip2 was the only unconverted library blocking it?
 * broder boggles
<slangasek> yep
<slangasek> at least for changing dpkg itself :)
<broder> crazy
<hallyn> SpamapS: thanks.  guess i'm not on that list!
<hallyn> oh.  no.  now i remmeber the msg
<EagleScreen> new created useres in admin group cannot use policykit, it ask for root password instead of user password, is this behavior a bug??
#ubuntu-devel 2011-06-07
<wgrant> SpamapS: It may take a few hours, but you should be able to upload an older version later today.
<SpamapS> wgrant: excellent, thanks for the clarification
<lamont> so if I have a "read-only" pdf, and I want to edit it.......  what's the simplest approach?
<micahg> lamont: pdfedit?
<lamont> that politely tells me that the document is read-only
<lamont> I want it to understand that I AM THE BOSS HERE
<lamont> s/HERE/OF IT/
<ohsix> strip the signing cert that says it's read only? i don't know of an open source tool that does it :\
<lamont> ohsix: ah.  yeah, that'd be what I'm after
<micahg> lamont: I assume it's o+w?
<micahg> lamont: there's also apparently an option in pdfedit to override the read only option (which may or may not work)
<lamont> hrm. /me will try that option
<lamont> micahg: where did you find that
<micahg> lamont: random blog post
<micahg> actually, a comment in a random blog post
<broder> can pdftk do that?
<broder> slangasek: an arch: all package should satisfy a dependency for a foreign architecture package......right?
<slangasek> broder: you'd think that, but no ;)
<broder> ...really
<broder> ?
<slangasek> broder: https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages
<broder> ugh
<broder> slangasek: hmm...the package i have in front of me has no dependencies. it would be nice of dpkg/apt were clever enough to special-case that, but *shrug*
<slangasek> broder: yes, that came up in one of the discussions on debian-$mumble - I think that'd be fine, if someone wrote the patch for it
<broder> slangasek: sweet. so i rebuilt coreutils, initramfs-tools, module-init-tools, and linux-firmware with multi-arch: foreign, and after hammering really hard on dpkg, am now running an arch: amd64 kernel on an arch: i386 userland
<broder> thanks for the tips
<slangasek> broder: hmmm, what had to be hammered?
<broder> slangasek: i think it was just that i was installing the packages with dpkg -i and not out of a PPA or something, so apt was confused
<slangasek> hmm
<broder> and i didn't bump the version numbers out of laziness, which probably also didn't help
<slangasek> oh, yes
<broder> i'll try to do it more correctly at some point
<slangasek> not bumping the version numbers means apt can't figure out they're multi-arch: foreign
<broder> that's what i figured
<bdrung> broder: remember bug #703099?
<ubottu> Launchpad bug 703099 in ubuntu-dev-tools (Ubuntu) "[backportpackage] support backporting packages from Debian" [Wishlist,New] https://launchpad.net/bugs/703099
<broder> bdrung: yes, and i was lame this weekend. it's at the top of my todo list the next time i actually do ubuntu stuff
<jdstrand> hallyn: fyi, feel free to check out test-qemu.py in qrt. it is only tested on natty atm. I'll be verifying lucid and later tomorrow along with a few more tests
<jdstrand> hallyn: heading out now. talk to you later :)
<SpamapS> so.. this "no packages can be uploaded that supersede later ones.. this is quite easy to prevent in dput...
 * SpamapS is almost done prototyping a change to do so
<hallyn> jdstrand: cool, i'll take a look
<micahg> SpamapS: no, that's not true
<SpamapS> micahg: sometimes you may want to right?
<micahg> SpamapS: in most cases it is, but it's not appropriate all the time
<SpamapS> --override-99percent-behavior
<SpamapS> ;)
<micahg> SpamapS: since this is something that requires approval anyways, you might want to just add it to the tool you use to accept SRUs
<SpamapS> micahg: I'd rather users are told when they try to upload
<hallyn> i'd prefer that too
<hallyn> micahg: the reason is, the user will be less offended
<micahg> hallyn: anyone uploading an SRU should know better
<SpamapS> A simple "Hey you're doing something that is almost always wrong. If you think its right anyway, pass --supersede-later-release
<mdeslaur> bdrung: I see there's a new vlc out with a security fix. Are you planning on taking a look?
<micahg> there are 180 people w/upload rights to Ubuntu ATM
<hallyn> micahg: there's another reason, which is once i dput something, i tend to immediately dump the info and move on
<hallyn> when ithen get an email saying 'something got rejected', i need to go find the info again
<SpamapS> "Fail early" is a widely accepted paradigm
<micahg> hallyn: I think that's a bad policy until it's actually accepted, you should keep the "info" around
<micahg> SpamapS: ok, maybe as a warning, I wouldn
<SpamapS> there are only a handful of us on the SRU team, and 180 uploaders ... the burden of iteration and learning should be pushed back to the uploaders as much as possible
<hallyn> it's not a policy
<micahg> SpamapS: it should actually warn in debuild -S, not in dput
<hallyn> that'd be fine with me
<SpamapS> GOOD POINT
 * SpamapS is lucky he sort of almost remembers some perl
<cody-somerville> micahg, +1
<micahg> SpamapS: and *warn*, not fail :)
<SpamapS> fail, with an available override is my preference
<micahg> SpamapS: then you break every PPA upload :)
<SpamapS> like the reminder to update-maintainer
<SpamapS> hmm, thats where I think maybe warn in debuild, and be more forecful in dput
<hallyn> i'll let those with more experience argue about this :)
<SpamapS> forceful even
<micahg> SpamapS: if you really want, add a conf file setting or env variable that makes it required
<micahg> but by default, it should just warn
<cody-somerville> lintian would be a good place for policy checks ;)
<hallyn> that seems to make sense
<cody-somerville> I'm also a huge +1 to adding checks to whatever tool archive admins use
<SpamapS> sure so lintian for the debuild step would be a big jump forward
<micahg> cody-somerville: +1 :)
<SpamapS> cody-somerville: yeah I'm looking into that as well.
<SpamapS> the tool we use is "launchpad"
<micahg> SpamapS: there's an sru-accept script which could be modified :)
<cody-somerville> SpamapS, According to the wikipage, there is a bzr branch with some scripts
<SpamapS> micahg: that is run after the damage is done
<SpamapS> cody-somerville: yes, I'm adding a warning to the queuediff script
<micahg> I thought the scripts accepted the upload too...
<SpamapS> I already added one which warns when there is already a version in -proposed..
<SpamapS> micahg: nope
<micahg> ah, it's queuediff :)
<SpamapS> ok multipath-tools is no longer in lucid-proposed, will send email out in a bit.
<slangasek> I wouldn't like dput to be trying to query the archive to figure out whether an upload supersedes a later release :/
 * micahg thinks Laney would go crazy with all the GHC rebuilds
<slangasek> er, debuild I mean
<hallyn> SpamapS: if you prefer i send the email, since it's primarily my fault, let me know.  (i'd mainly parrot the earlier one i guess)
<slangasek> I don't think I'd like dput to do it either, but I really wouldn't like debuild to
<micahg> slangasek: on source package creation?
<slangasek> yes
<slangasek> debuild (and dpkg-buildpackage) is an offline tool - it really shouldn't have any interaction with launchpad or the mirrors
<chihchun> utnu-kernel
 * ScottK +1's slangasek.
<ScottK> SpamapS: I think in sru-accept.py is the right place for such a check.
<SpamapS> sru-accept is not at all the right place unfortunately, but queuediff is
<pitti_> Good morning
<StevenK> pitti: O hai
<pitti> maco: congrats for fixing a four-digit bug :)
<speakman> hi folks. Looks like pressing S or M when mount fails on boot doesn't work. And one gets pretty stuck when it doesn't continue.
<SpamapS> pitti: re the multipath-tools SRU's .. I think those may have to be closed as Won't Fix. The people who did all the fixes don't seem very confident that we'll be able to get adequate testing.
<pitti> SpamapS: ah, good to know
<SpamapS> pitti: its really just a big mess. :-/
<pitti> oh, today is world IPv6 day?
<micahg> pitti: I think that's tomorrow
<SpamapS> tomorrow yes
<SpamapS> Google sent me a warning about my google sites that they might not work. :)
<pitti> ah, yes
<speakman> "alloc magic is broken at 0x....." from grub2
<pitti> seems some pages already activated ipv6 DNS
<SpamapS> well isn't it 6/8 on the bits just west of the date line?
<SpamapS> I guess not quite, but maybe TTL screwups
<bdrung> mdeslaur: i am working on getting 1.1.10 into the archive. it contains a security fix?
<speakman> Any idea how to make Ubuntu halt prior to mountall?
<speakman> Or just skip any nfs mounts?
<SpamapS> speakman: noauto on the fstab lines would do that
<speakman> SpamapS: thanks, but I'd like then to mount on boot (it should work). Now I can't even reach my own system since it hang in plymouth and there's nothing one can do.
<dholbach> good morning
<speakman> morning
<didrocks> good morning
<poolie> hi bryceh
<pitti> mdeslaur, cjwatson: nice, the latest apparmor got us rid of quite some perl modules: http://paste.ubuntu.com/620662/ (that's the delta between yesterday's and today's alternate CD)
<pitti> cjwatson: build-essential is still on today's alternate, though; seems it didn't pick up the "ship" seed change for some reason?
 * pitti wonders if "lsb-cxx" pulls in build-essential somehow; it certainly pulls in at least g++
<pitti> ah no, just libstdc++6
<pitti> ah
<pitti> lsb-core -> alien -> debhelper -> dpkg-dev -> build-essential
<pitti> cjwatson: ^ so we might need to drop that as well if it becomes tight?
<pitti> I don't think it's that vitally important to be able to install RPM packages just with an alternate CD
<slangasek> pitti: dates back to 2006, not consistent with handling of lsb packages on other install types; looks fair to drop
<pitti> we have the full lsb on the DVD, so let's use that
<cjwatson> pitti: I'm not immediately worried about the alternate CD, though
<cjwatson> pitti: but whatever, either way
<pitti> cjwatson: nice, today's desktops just trickled in; down to 712 MB
<pitti> and this didn't yet catch my gnome-icon-theme split (minus 5.8 MB)
<cjwatson> yeah, definite progress
<cjwatson> I have a bit shaved off ubiquity in bzr
<pitti> gdm->lightdm will remove ~ 0.7 MB
<pitti> (tomorrow's image)
<cjwatson> pitti: as far as I can see, getting rid of libgnome and libgnomeui would only involve configuring gbrainy with --disable-gnome and adding some equivalent libgnome-avoidance to tomboy
<seb128> cjwatson, it's not that easy for tomboy :-(
<cjwatson> so that looks like not too much work for somebody for another few hundred KB at least (haven't hunted through the dependency graph to see what all would fall out)
<cjwatson> oh?
<cjwatson> oh, Gnome.PanelApplet, hmm
<seb128> cjwatson, they use gconfpeditor which is in libgnome2.24-cil which depends on libgnome libgnomeui etc
<seb128> cjwatson, no, we turned the applet off previous cycle
<seb128> cjwatson, they want to switch from gconfpeditor to gsettings but they are blocking on getting mono gsettings binding to do it...
<cjwatson> ah, I was looking upstream
<cjwatson> right ...
<seb128> rodrigo said he would help them doing the port once they get the bindings
<seb128> the issue is to get those...
<cjwatson> would be nice to do the gbrainy change so that it's clear that that's the only blocker
<seb128> cjwatson, right, thanks for pointing it, I though we were down to at-spi (pending on the at-spi2 switch which just happened) and then tomboy
<seb128> cjwatson, btw do you know if gparted is going to be ported to gtk3 this cycle?
<seb128> cjwatson, pitti: if,when we update gnome-system-monitor we will get a duplicate binding stack for those 2 on the CD which is a bit ridiculous, I'm pondering not updating gnome-system-monitor maybe this cycle if gparted is not ported
<pitti> for gtkmm you mean?
<seb128> yes
<seb128> it would be another 1mb to add
<pitti> could we get away with noth whipping gparted?
<pitti> argh, "shipping"
<seb128> I think we already discussed that in the past and cjwatson said no
<cjwatson> seb128: I'll have a look
<cjwatson> pitti: gparted is a really popular and useful recovery tool on the live CD ...
<pitti> we have gnome-disk-utility for simpler partitioning
<seb128> we were pondering just porting g-s-m to vala to get ride of the bindings from the CD
 * cjwatson has never heard of anyone firing up GDU
<pitti> cjwatson: yeah, it's certainly more powerful than gparted
<pitti> erm, gdu
<pitti> I only use gdu, but that might be just me because I package it..
<seb128> $ palimpsest
<seb128> Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
<seb128> hum
<seb128> pitti, do you get that as well?
<pitti> ah, bugger
<seb128>         libavahi-ui.so.0 => /usr/lib/i386-linux-gnu/libavahi-ui.so.0 (0x00e37000)
<seb128>         libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00fdf000)
<pitti> no, works fine here
<pitti> $ ldd /usr/bin/palimpsest |grep gtk
<pitti> libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f2311ad5000)
<seb128> that box is not uptodate, I should really dist-upgrade rather than apt-get install what I need
<pitti> libgdu-gtk.so.0 => /usr/lib/libgdu-gtk.so.0 (0x00007f2310b6c000)
<pitti> libavahi-ui-gtk3.so.0 => /usr/lib/x86_64-linux-gnu/libavahi-ui-gtk3.so.0 (0x00007f230c295000)
<pitti> ah, so not my fault :)
<seb128> it was my libgdu-gtk0 being outdated
<seb128> sorry for the nosie
<seb128> noise
<pitti> of course it would be nice to support partial upgrades, but with all these gnome/gtk 2->3 bits the breaks: would become a mess
<cjwatson> so is anyone packaging gtkmm 3.0?
<seb128> cjwatson, it's waiting for sponsoring in the debian pkg-gnome svn
<pitti> cjwatson: it's in debian's pkg-gnome already, waiting for review/sponsoring
<tkamppeter_> pitti, thanks for your uploads. I have already confirmation of a user that AirPrint works for him on Natty.
<seb128> cjwatson, so it's just a matter of getting it reviewed and uploaded
<pitti> tkamppeter: nice! and thanks for all the fish^wfixes
<tkamppeter> Anyone with an iPad, iPhone, or iPod Touch (min iOS 4.2, update if needed), can you please test whether bug 711779 is fixed? Set your printer(s) to shared with system-config-printer and try to print from your Apple device. Please report in said bug. Thanks.
<ubottu> Launchpad bug 711779 in cups (Ubuntu Natty) "AirPrint support in the Avahi patch for CUPS does not work" [Medium,Fix committed] https://launchpad.net/bugs/711779
<tkamppeter> You will need Natty with -proposed or up-to-date Oneiric.
 * apw is soooo confused by these bzr branches with quilt patches applied/not applied
<apw> in the debian imports with 3.0 (quilt) patches they seem to not be applied in those imports
<pitti> yeah, applied patches and .pc/ is so utterly utterly wrong
<\sh> micahg, I'll take zf 1.11.7 ...
<apw> so when i commit should i commit with them unapplied, and to make a source package do i need them applied or not
<micahg> \sh: cool, thanks, hope I did 1.11.6 ok
<micahg> \sh: and welcome back :)
 * apw is seriously close to bursting a blood vessle in his head over this
<pitti> apw: I think they are meant to be committed as debian/patches plus applied, i. e. the bzr diff has the change twice
<\sh> micahg, thx and yes everything is ok with zf :) thx for it
<apw> yet the debian branches they seem to not be applied
<pitti> but I haven't touched one of these branches in a while, as in deskop we don't use them
<pitti> so I'm not very up to date
<apw> and if i do that i presumably need to commit the .pc else you cannot get them off, and that is poor at best
<apw> this new format is a massive barrier to entry ... dammit
<pitti> last time I tried to touch a branch like that I gave up and did the old style
<pitti> I quickly got into a situation where the branch was completely damaged
<apw> if you can't figure it out the i may as well give up
<pitti> and after I reverted and re-applied my changes three times I gave up
<apw> pitti, i am quickly coming to the conclusion you cannot use any of the tools to do merges once they are in .pc form ... i want to cry
<pitti> yes, merge-upstream is broken with this, too
<Laney> echo unapply-patches >> debian/source/local-options :-)
<apw> Laney, what will that do for me, i am liking the sound of it
<Laney> lets you keep the patches unapplied in the VCS
<Laney> specifically it unapplies the patches after a build
<apw> Laney, problem is am merging in a debian upstream which has them applied so i am still in trouble
<Laney> ah yeah :-(
<Laney> best I can think of is to add it to both branches
<apw> i suppose i can bzr branch lp:debian and then add it there
<Laney> not exactly friendly to the history though
<apw> Laney, so i can quilt pop -a, add that option and make a source tarball and it'll work ?
<Laney> should do
<Laney> you might have to commit the initial .pc removal too
<apw> won't the history still make sense just there is always a 'unpatch' commit on the debian branch
<Laney> it just means that the debian history isn't exactly what was uploaded to debian
<apw> Laney, i didn't mean commit the file to the debian real branch, just to my copy
<Laney> it's not a big deal
<apw> and merge just my copy
<apw> so the debian mainline is virgin and i merge a sidebranch of it with the removal
<Laney> should be ok then
<Laney> the question of 'is this all worth it?' remains though
<pitti> that's why we still use our old ~ubuntu-desktop debian/ only branches
<pitti> (not the only reason, but part of it)
<apw> Laney, well someone has to work out how to handle 3.0 (quilt) hell with our wonderful bzr solves the universes problems approach
<apw> we can't tell people this is how to do it, when it doesn't actually work, and mostly breaks intelligent people when they try
<Laney> working with them like this isn't the long term solution anyway
<apw> Laney, and what is the long term solution
<Laney> bzr looms
<Laney> let me find the uds notes ...
<pitti> http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt ?
<Laney> right that's the implementation
<Laney> http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-planning/ http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-onramp/
<apw> Laney, pitti well just tired the non-applied way of mergeing and it seems to work pretty well
<Laney> cool
<Laney> I just remembered that the problem raised in the session is that breaks attribution (bzr blame)
<Laney> but I think that's a small price to pay to actually make the tools work :-)
<apw> Laney, now that i can live with
<Laney> I'd quite like it if .pc was .bzrignored by the importer and then recreated on checkout using cjwatson's snippet
<apw> Laney, pitti, i wonder if one of you could look at lp:~apw/module-init-tools/resync2 and see if that looks sensible... we have been divergant for a long time and i am trying to get us back to a bzr merge-package being feasable
<pitti> quite surprising that we have accumulated so much delta there at all -- it doesn't seem like a package we want to customize to death
<apw> pitti, no and i've compromised for now on not trying to merge back to the install scripts to risk the regression potential
<apw> i am sure they could be merged back with work but i am on a tight schedule right now as 3.0 kernels require this update
<Laney> apw: http://bazaar.launchpad.net/~apw/module-init-tools/resync2/view/head:/debian/source/local-options
<apw> Laney, doh ...
<pitti> that's the way to say --really-i-want-it :)
<ScottK> SpamapS: OK.  Depends on if you run sru-accept.py before or after you accept a package.  As long as you find a good spot is the main thing.
<Laney> apw: you might want to remove and .bzrignore .pc completely
<Laney> don't think that breaks anything
 * Laney runs
<apw> Laney, i was unsure, the stuff still in there seemed to be the sort of thing which would be static
<ohsix> can i run jobs locally that work like the apport retracing service?
<pitti> ohsix: by and large yes; install apport-retrace and man apport-retrace
<apw> and would otherwise have to be removed from debian every time, right now i only need to actuall unapply the patches in the debian side branch
<ohsix> pitti: kudos
<pitti> ohsix: the retracing service uses that, but in a chroot
<pitti> ohsix: be careful, as if you use it without -u on a production system it might confuse your packaging system a bit
<ohsix> noted, thanks again
<pitti> without -u, apport-retrace will permanently instlal the -dbgsym pacakges, which might or might not be what you want
<ohsix> i've installed some of those manually before to try and get some of the same information but apport retrace seems much more effective
<ohsix> hah that compiz update that just landed is making one of my windows really flip out
<ohsix> it does not like snapping to 3 edges duringn a drag
<apw> Laney, otherwise does the bzr history look sane, with the upstream merge
<cjwatson> pitti,seb128: damn you, you've made me work on removing deprecated interfaces from gparted
<cjwatson> I hate C++
<tseliot> :D
<mdeslaur> bdrung: apparently, what's new says "Security update regarding an integer overflow in xspf demuxer"
<mdeslaur> bdrung: I was wondering if you were going to work on debdiffs for the earlier releases...I don't want to step on your toes if you are
<seb128> cjwatson, ;-)
<Laney> apw: didn't look in depth, but yeah it looks fine
<Laney> generally I check the standard debdiff to see if anything crazy happened
<apw> yeah good point
<jibel> pitti, when you have a minute, could you please remove bcmwl-kernel-source from natty-proposed , it's uninstallable see bug 793890
<ubottu> Launchpad bug 793890 in bcmwl (Ubuntu Natty) "package bcmwl-kernel-source 5.100.82.38+bdcom-0ubuntu3.1 failed to install/upgrade: /var/lib/dpkg/info/bcmwl-kernel-source.postinst: 53: Syntax error: "fi" unexpected (expecting ";;")" [Critical,Triaged] https://launchpad.net/bugs/793890
<outsidecontext> hi. what is the normal procedure to get a patched package for lucid uploaded? especially if there is no response to launchpad bugs?
<evfool> mvo: ping
<apw> outsidecontext, perhaps you could point us at the bug in question and we can figure out whats next
<outsidecontext> apw: https://launchpad.net/bugs/455461
<ubottu> Ubuntu bug 455461 in sound-juicer (Ubuntu) "Sound Juicer depends on deprecated libmusicbrainz4" [Undecided,Confirmed]
<mvo> hey evfool
<apw> outsidecontext, ok overall someone needs to lead this through the SRU process (https://wiki.ubuntu.com/StableReleaseUpdates). the first step for that really is to get the patch which fixes the issue attached to the bug with the patch attribute; someone must have made such a thing to do the PPA build
<pitti> jibel: on it
<evfool> mvo: in the Software-center axi plugin i keep getting an AttributeError (see bug 793896), could you please check my branch there to see if that's a good fix?
<ubottu> Launchpad bug 793896 in apt-xapian-index (Ubuntu) "update-apt-xapian-index crashed with AttributeError in index(): class CustomKeys has no attribute 'CATEGORY'" [Undecided,New] https://launchpad.net/bugs/793896
<mvo> evfool: thanks, let me have a look
<pitti> jibel: removed
<outsidecontext> apw: ok, thanks. the PPA upload was done by me, and I have the branch linked to the bug. thanks for pointing me to SRU, I had looked for something like that.
<jibel> pitti, thanks
<apw> outsidecontext, np
<mvo> evfool: thanks a bunch, the fix looks fine
<evfool> mvo: one-liner, but I did not know whether it'll be a name clash somewhere, as theres a Category enum value in the navbuttons also, and thought somebody had renamed it to avoid confusion
<mvo> evfool: its a oversight when the enums were reorganized
<mvo> evfool: your approach is the right one
<evfool> mvo: ok then, thanx
<cjwatson> pitti,seb128: I got as far as https://bugzilla.gnome.org/show_bug.cgi?id=652044, but probably need to go and do other things now
<ubottu> Gnome bug 652044 in application "uses deprecated APIs" [Normal,Unconfirmed]
<pitti> nice! let's see what the gparted guys do with that
<seb128> cjwatson, thanks for working on that, that's a good start, let's see if somebody replies with the upstream plans for gtk3
<cjwatson> I think I should have used cairo surfaces in the pixmap-avoidance part of that patch
<seb128> ups
<seb128> cjwatson, yes, http://developer.gnome.org/gtk3/stable/ch25s02.html#id1221236 has some hints
<cjwatson> yeah, I only found that after running out of time :-)
<seb128> well let's see if they pick it up and what they do
<lynxman> ping mvo
<x-ip> hi, i would like to use the installer from ubuntu, is it free (as in freedom) software ?
<x-ip> i think it's done in python with pygtk, but not sure
<Chipzz> x-ip: the package you're looking for is ubiquity
<mvo> hey lynxman
<x-ip> thanks Chipzz :)
<Chipzz> (debian-installer is for the text-mode installer)
<lynxman> mvo: hey *waves*
<lynxman> mvo: I've been working with squid-deb-proxy to integrate it into orchestra these last weeks
<mvo> lynxman: aha, nice!
<Chipzz> x-ip: there's #ubuntu-installer btw
<lynxman> mvo: I've sent your way a merge request for the changes we've implemented, it's just a couple of debhooks in order to be able to programatically modify the conf files :)
<lynxman> mvo: let me know what you think :>
<x-ip> thanks Chipzz :)
<Chipzz> yw :)
<lynxman> mvo: we're trying to have orchestra working out of the universe repo in Oneiric
<mvo> lynxman: thanks for your work on this ! I replied to a very similar branch a couple of days ago with some concerns about the current approach, let me have a look at the branch to see what changed since then (mail was from 25 May 2011 15:36:59 +0200 and I'm happy to forward it to you again or put it into the merge proposal)
<mvo> lynxman: I think the goal is great, just some bits and pieces that needed fixing last time I looked, but let me look again for the updated version :)
<lynxman> mvo: cool :)
<lynxman> mvo: could be that its' the same branch, I did the request a couple days ago
<lynxman> mvo: but I couldn't catch you online
<mvo> lynxman: yeah, I was away for a long weekend
<lynxman> mvo: hope you enjoyed it!
<mvo> I did, it was very nice :)
<lynxman> mvo: schweet
<bdrung> mdeslaur: no i am not working on those. please go ahead. i will then have to prepare a sru for natty.
<mvo> lynxman: I answer in the merge proposal now
<lynxman> mvo: cool!
<lynxman> mvo: if there's any changes or proposals I'll get to them right away
<mvo> lynxman: I'm happy to work with you on the bits and pieces, I added my comments now. this is pretty much what I wrote in the original mail I got about this. some stuff is really trivial to fix, the conffile question is a bit more tricky, I can have a look at this now
<lynxman> mvo: okay :) didn't get the original mail, sorry
<lynxman> mvo: I'll get to it right away
<mvo> lynxman: no problem
<janimo> infinity, around?
<infinity> janimo: Yep, but not "at work" for another 22 minutes, so running off to grab some breakfast. :)
<infinity> janimo: And around now.
<ogra_> infinity, not on the right channels yet :P
 * dholbach hugs infinity
<speakman> so - am one supposed to use "bootwait" or "nobootwait" on NFS mounts? the fstab(5) isn't very clear imop.
<speakman> -p
<janimo> infinity, indeed, was wondering if you're in the arm channels for blueprint discussions, but no hurry at all :)
<infinity> janimo: Not just yet.  But talking with Oliver.
<SpamapS> ScottK: yeah, I think in queuediff is the appropriate place, and I already have the framework in it for checking versions in the targetted -proposed .. very easy to also look for lower versions in all other higher releases.
<hallyn> Q:  I'm looking at a package which says it conflicts with an earlier version of itself (well, of a derivitive package).  So it refuses to install with dpkg -i, but if I dpkg -r the offending package, then I can proceed.  My q is, would adding a 'Replaces:' be the right thing to do?  Or hwo do we normally warn users about that?  (or woudl apt-get just do the right thing if the packages were int he archive?)
<hallyn> cmagina: great news, the multipath merge (apart from the Conflicts ^ ) appears to work great!  with one scm :)
<SpamapS> hallyn: thats how apt knows to replace the old one
<Laney> Conflicts means you have to remove the conflicted-on package indeed.
<Laney> and apt does that for you
<hallyn> SpamapS: Laney: awesome, thanks :)
<SpamapS> hallyn: usually Breaks + Replaces is enough
<hallyn> SpamapS: merging from debian so i didn't want to touch it if i didn't have to
<SpamapS> ScottK: would you accept a backport of multipath-tools ?
<hallyn> say huh?
<SpamapS> Well.. of the 6 bugs you tried to SRU, only 2 were High...
<hallyn> yeah i'm not sure those are right...
<SpamapS> I wonder if the other 4 are fixed in the new version. If so, a backport would be a way for users to get them.
<hallyn> or, i may ask someone (dannf?) to look at the priorities and let me know if they think they should be high
<hallyn> anyway, first step is to get that bear into oneiric :)
<hallyn> 12.04 has to be top priority at this point
<cmagina> hallyn: woot!
<SpamapS> indeed
<hallyn> cmagina: i may go ahead and push, unless you think you'll have time to test this week?  (I dont' want to take too much of your time...)
<cmagina> hallyn: i don't know about having time this week, currently at a sprint
<hallyn> cmagina: ok, i'll push then
<hallyn> thanks
<cmagina> i'll still test if i find time, just for a data point :)
<hallyn> we'll  pound the snot out of it in london :)
<hallyn> ok
<hallyn> thx, ttyl
<cmagina> ttyl
<Daviey> SpamapS: Hmm.. Are you sure backports should be used that way?
<Daviey> Fixing bugs in -backports, rather than -updates?
<SpamapS> Daviey: I'm not sure. I am sure that SRU should not be used for low priority bugs.
<SpamapS> But it is currently, because otherwise users are kind of up a creek.
<hallyn> SpamapS: if some users are up a creek without it, then it's not low prio
 * Daviey screams.
<hallyn> Daviey: sshhhhh  :)
<SpamapS> I suppose thats Medium.
<SpamapS> Which we also should be careful about fixing in the stable release..
<Laney> backports has been used in the past for non-sru-worthy bugs
<RoAkSoAx> mvo: ping
<mvo> RoAkSoAx: hello, I'm on my way for dinner currently, is it something very urgent?
<RoAkSoAx> mvo: not really it can wait ;)
<DktrKranz> mvo: hi! I haven't heard people complaining about gtk3 support in GDebi, so it seems quite good already. Would you be OK for an upload in experimental, to give it broader testing?
<mvo> RoAkSoAx: sure, testing is always good, I think the port should be pretty good indeed. it needs vte 2.90 though
<brendand> anyone know how to find if a gtkwidget is shown or hidden?
<brendand> if i try to call set_size_request on a hidden widget it locks up...
<smoser> pitti, you are last-touched for rsyslog, are you opposed to me opening a bug and attempting a merge (which i'd request you to review)
<hallyn> cmagina: I spoke too soon, later reboots are failing.  but now i'm angry.  i'm gonna get this thing licked and then push :)
<bdmurray> pitti: somehow bug 610351 became unassigned from you.  should I assign it back to you and set it to in progress?
<ubottu> Launchpad bug 610351 in casper (Ubuntu) "scripts/casper-bottom/32disable_hibernation sets /apps/gnome-power-manager/general/can_hibernate" [Medium,Triaged] https://launchpad.net/bugs/610351
<cmagina> hallyn: try a bigger hammer ;)
<zyga> I'm trying to create a pbuilder for etch on natty, I have debian-keyring installed yet pbuilder claims that release is signed by unknown key, any hints?
<cjwatson> debian-archive-keyring is more likely to help
<cjwatson> although the key has probably been expired and might need some manual fiddling
<cjwatson> debian-keyring => developers, debian-archive-keyring => archive signatures
<zyga> cjwatson, that's the one I have
<zyga> cjwatson, E: Release signed by unknown key (key id B5D0C804ADB11277)
<zyga> cjwatson, which keyring is pbuilder using, some system-wide keyring?
<cjwatson> it's in /usr/share/keyrings/debian-archive-removed-keys.gpg
<cjwatson> dunno
<hyperair> micahg: ping.
<micahg> hyperair: pong
<hyperair> micahg: regarding libnotify transition, where aer the new libnotify packages?
<micahg> hyperair: in natty and oneiric
<micahg> hyperair: sorry, it's libnotify4
 * micahg might have forgot that in the bug
<hyperair> micahg: and the -dev?
<hyperair> oh
<hyperair> libnotify4-dev
<hyperair> i see.
<micahg> hyperair: no, libnotify-dev
<hyperair> O_o
<micahg> libnotify4-dev was natty only
<hyperair> hm okay
<micahg> hyperair: seb128 posted to multiple lists about the GNOME3 changes and the libnotify changes are listed in there
<hyperair> ah, transition's already done.
<hyperair> i just need a sponsor to debian.
<micahg> cool :)
<hyperair> =)
<SpamapS> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: chrisccoulson, SpamapS, bryceh
<SpamapS> whoa we have 3?
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: chrisccoulson, SpamapS
<bryceh> SpamapS, chrisccoulson probably forgot to log out too
<chrisccoulson> oops
<chrisccoulson> :)
<chrisccoulson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: SpamapS
<chrisccoulson> profit!
<hyperair> heh
<pitti> smoser: I actually have a merge here, but it's broken -- it doesn't log anything but ever-repeating error messages about rsyslog itself
<pitti> bdmurray: ah, please do
<pitti> smoser: please feel free to steal bug 775703 from me, I'm not attached to it
<ubottu> Launchpad bug 775703 in rsyslog (Ubuntu) "Please merge rsyslog 5.8.0-1 (main) from debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/775703
<pitti> smoser: seems I accidentally deleted my source package anyway; but it had been a rather simple merge anyway, I just didn't get to debugging it
<slangasek> pitti: that error condition makes me giggle
<slangasek> pitti: btw, I have multiarch patches for cups; now that eglibc multiarch support has landed in unstable, should I push them straight to Debian as a bug report?
<pitti> error condition?
<slangasek> pitti: "it doesn't log anything but ever-repeating error messages about rsyslog itself"
<pitti> ooh! that means we can now push all these to Debian
<pitti> ah yes, it's indeed quite useless :/
<slangasek> yes, we can push them... I'd like to send a mail to debian-devel-announce first, fwiw
<pitti> slangasek: bug report, debdiff, or branch against http://bzr.debian.org/pkg-cups/cups/debian-trunk/, whichever is most convenient for you
<pitti> I'll commit it to bzr right away then
<slangasek> pitti: cool.  I think my current branch is against lp:ubuntu/cups instead, but I can, er, "rebase"
<alexbligh> Vital question of the day: how is "reprepro" pronounced?
<Laney> rep reap row
<Laney> ...
<alexbligh> We didn't think of that. We thought re-PREP-ro would be the most likely. We keep calling it rep-REPPo or rep-REEPO, and are puzzled about the third r :-)
<Laney> dunno, it's like reading a book â you just make it up in your head
<RoAkSoAx> mvo: You might be able to help me with this: I was wondering if it is possible to determine the apt mirror to use (programatically) based only on the timezone/location of the server
<DktrKranz> mvo: ok then, I'll merge gtk3 branch into trunk, I'll probably add another feature then I'll prepare experimental upload
<mvo> DktrKranz: cool, thanks!
<mvo> RoAkSoAx: you can use the apt mirror method for this, http://mvogt.wordpress.com/2011/03/21/the-apt-mirror-method/
<RoAkSoAx> mvo: and is there another way to do it without having to depend on apt?
<mvo> RoAkSoAx: you can use  curl http://mirrors.ubuntu.com/mirrors.txt to get the recommended mirror list
<RoAkSoAx> mvo: and what about the ones that are ubuntu mirror's themselves, such as it.ubuntu.com us.ubuntu.com etc etc
<RoAkSoAx> mvo: cause programatically, I'm doing this with python-apt: http://paste.ubuntu.com/621149/ however, I'd also like to find a way without having to depend on apt, if possible
<mvo> RoAkSoAx: that will work as well, python-apt has a mirror list embedde
<mvo> d
<RoAkSoAx> mvo: ok, thanks!
<mvo> RoAkSoAx: /usr/share/python-apt/templates/Ubuntu.mirrors <- thats the one
<RoAkSoAx> mvo: cool! Thanks for the help
<mvo> yw
<hallyn> jdstrand: bug 787091, would you mind taking a look if you get a chance?  I'm at a loss.
<ubottu> Launchpad bug 787091 in qemu-kvm (Ubuntu) "Unable to use USB device in KVM quest" [Medium,Incomplete] https://launchpad.net/bugs/787091
<jdstrand> hallyn: k. I commented in the bug
<jdstrand> hallyn: though I wonder if this could be causing it: 'deny capability setpcap,'
<hallyn> jdstrand: thx
<jdstrand> hallyn: that is an explicit deny, so it won't be logged
<jdstrand> (the user could prepend with 'audit deny capability setpcap,' and try again)
<hallyn> but why would setpcap be involved?
<jdstrand> I wouldn't think it would, but that is the only 'deny' rule we should have
<jdstrand> well, besides kill
<hallyn> is there a 'audit all' statement we can use?
<jdstrand> hallyn: you know, that is interesting-- he could be hitting kernel rate limiting
<jdstrand> hallyn: to disable that, the user could do: sysctl -w kernel.printk_ratelimit=0
<hallyn> let's ask him immediately to try that (i'll post)
<jdstrand> hallyn: but everything is already logged by default. after the user supplies the information, we can see if there are additional explicit deny rules, then prepend 'audit' in front of them and try again
<hallyn> right
<jdstrand> hallyn: (last comment assumes rate limiting isn't dropping stuff)
<jdstrand> hallyn: dude, I figured out a way to do in guest tests in test-qemu.py
<soren> kees: Have you looked at the Google authenticator pam module?
<hallyn> oh?
<jdstrand> hallyn: this script is coming along
<hallyn> i've finally gotten the whole tree re-fetched (it wasn't updating for me), but haven't looked yet
<jdstrand> hallyn: yeah, I use -net user with hostfwd, then forward host port 4422 to guest port 22. then I can ssh in. I am adding ssh keys to a new lucid qatest-virtio.tar.bz2, and do a bunch of glue
<jdstrand> hallyn: it works awesome so far :)
<jdstrand> hallyn: http://paste.ubuntu.com/621224/
<hallyn> cool
<kees> soren: haven't yet; it's on my mental list, though
<soren> kees: I'm liking it. Quite a bit.
<hallyn> cmagina: looks like the reliable fix for me was just to get rid of the timeout debian specifies for udevadm settle
<cmagina> hallyn: well that was easy ;) good to hear it turned out to be an easy fix
<hallyn> i don't trust it though,
<hallyn> bc as i mentioned elsewhere :), it's loading three modules that don't exist, and not loading the one which does exist
<cmagina> hmmm...that doesn't sound good
<lifeless> bryceh: hi
<lifeless> bryceh: you asked for a screenshot of my graphics corruption
<lifeless> bryceh: it keeps happening when I have private data on screen.
<lifeless> bryceh: what should I do ?
<slangasek> lifeless: I believe you're meant to post it to your twitter account, then immediately delete it and claim you were hacked
<lifeless> heh
<broder> ha!
<EagleScreen> could you please take a look at this bug? -> https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/793792
<ubottu> Ubuntu bug 793792 in user-setup (Ubuntu) "New users in admin group cannot use policykit" [Undecided,New]
<bryceh> lifeless, some people will take the screenshot or photo and then use gimp to smudge out or black box out the sensitive parts.  That seems to usually work.
<bryceh> lifeless, other times just snipping out the portion of the screen that is corrupted is sufficient
<lifeless> k
#ubuntu-devel 2011-06-08
<ScottK> SpamapS: For what releases?
<ScottK> (multipath-tools backport)
<SpamapS> ScottK: lucid thru natty
<SpamapS> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<ibook_powerpc> Hello, I am interested in Ubuntu testing and creating bug reports. could you help me/
<ScottK> ibook_powerpc: You probably ought to ask in #ubuntu-bugs.
<ibook_powerpc> thank you, I will head over there now.
<ScottK> SpamapS: As long as kpartx rdepends get tested, sure.
<hallyn> ok there's definately a toolchain problem here
<hallyn> when I take the lucid ipsec-tools sources and try to compile them in oneiric, it fails with:
<hallyn> gcc-4.6.real: error: unrecognized option '-R'
<hallyn> (I get the same with other versions, including the debian one i was trying to sync)
<hallyn> fwiw i get the same error in debian sid.
<hallyn> (that is, compiling sid's own ipsec-tools inside a debian sid VM)
<hallyn> all right, got a test case for a workable bug.  Suspect i'tll be called a bugfix rather than regression, but i'll file anyway
<pitti> Good morning
<hallyn> good evening :)
<hallyn> all right, filed bug 794373 on it.  have low hopes
<ubottu> Launchpad bug 794373 in gcc-defaults (Ubuntu) "gcc now returns -1 when passed -R" [Undecided,New] https://launchpad.net/bugs/794373
 * hallyn checks the bzr branch for an obvious clue
<hallyn> history suggests doko_ is the one i should talk to tomorrow :)
 * hallyn out
<dholbach> good morning
<didrocks> good morning
<bryceh> pitti, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/774978/comments/38
<ubottu> Ubuntu bug 774978 in xserver-xorg-input-synaptics (Ubuntu Natty) "xserver crashes in RecordAReply when XRecord is enabled in syndaemon" [Undecided,Fix committed]
<bryceh> pitti, ^^ root cause analysis for bug
<pitti> bryceh: ah, finished reading -- "oops"
<pitti> so XRecord has been a kind of mis-feature, and dropping it shouldn't cause much disruption indeed?
<bryceh> pitti, yep that's my take
<bryceh> XRecord is a dumbass
<bryceh> looks like it's not going to be a regression from maverick at the least
<smb> Hi, a while ago I had been adding two debdiffs to a bug report against ifenslave. Since then nothing changed there and I am pretty sure I missed a step in getting any attention. (bug 714904)
<ubottu> Launchpad bug 714904 in ifenslave-2.6 (Ubuntu Natty) "/etc/network/if-up.d/ifenslave is missing (installed under if-pre-up.d)" [High,Triaged] https://launchpad.net/bugs/714904
<bryceh> pitti, what is needed next before we can roll it out to -updates?  Do you need folks doing testing on natty-proposed?
<geser> smb: don't forget to subscribe the sponsors team (~ubuntu-sponsors) if you need sponsoring for an upload
<smb> geser, Oh, that was it then...
<smb> Doing that
<smb> geser, Thanks
<bryceh> smb, aren't you core dev?
<smb> bryceh, No. I maybe want at some point. But currently only package uploader for kernel
<smb> Still need to learn a few things for the "normal" package world
<bryceh> smb, ahh.  Well you got my +1 for core dev if/when you need it
<smb> bryceh, cheers. :)
<pitti> bryceh: right, to check for regressions and that the patch fixes it
<tkamppeter> pitti, WDYT about deprecating the "usblp" kernel module? It causes too many uglinesses and Mike Sweet wants to have it deprecated, too (instead of taking our patch on the "usb" CUPS backend)?
<tkamppeter> pitti, ping
<tkamppeter> Someone had already the problem of one free software project working actively against another, like for example if emacs would do "rm -f ~/.vimrc" on startup?
<bryceh> tkamppeter, ahh that would be awesome!
<bryceh> WAR
<pitti> tkamppeter: cups itself only speaks to the raw USB nodes now?
<tkamppeter> pitti, in CUPS upstream one has to decide whether to let it speak to libusb or usblp at build time.
<pitti> tkamppeter: that is, drop usb-backend-both-usblp-and-libusb.dpatch and drop usblp from our kernel?
<tkamppeter> pitti, that is what I always wanted and what Mike Sweet wants, too.
<pitti> as cups is pretty much the only thing talking to USB printers, I'm fine with that
<pitti> is that CONFIG_USB_PRINTER=m?
<pitti> apw: ^ do you think we could just disable it?
<tkamppeter> I only created the patch as there were drivers depending on the kernel module. The only free driver doing that is foo2zjs and that only for uploading firmware into HP cheapo lasers.
<tkamppeter> pitti, but it is no problem for me to patch that out in our package.\
<apw> pitti, for oneiric ?
<apw> pitti, and could we just blacklist it for testing ?
<pitti> hm, thinking in broader Debian terms, shipping a blacklist file in cups might be more appropriate
<tkamppeter> pitti, more a problem but less for us is that foo2zjs upstream will probably not accept it, but this author is really "dickkÃ¶pfig" (pitti, I do not know it in English). There is also a second issue (see my talk with bryceh
<pitti> as in Debian you also have other kernels, and you can also use other spoolers
<tkamppeter> before my talk with you.
<pitti> tkamppeter: which patch will foo2zjs not accept?
<pitti> tkamppeter: "stubborn" seems close
<tkamppeter> pitti, thx.
<pitti> apw: so on second thought, cups should perhaps just blacklist it
<smb> pitti, stubborn. :)
<tkamppeter> pitti, the patch which I will introduce to make foo2zjs' firmware upload script independent of the "usblp" kernel module.
<apw> pitti, ok
<pitti> tkamppeter: and blacklisting usblp would mean we don't need the patch?
<tkamppeter> pitti, then we can drop the patch on CUPS' "usb" backend, but we will have to introduce a patch on the firmware uploader script of foo2zjs. I am much more comfortable with this.
<pitti> tkamppeter: ok
<pitti> tkamppeter: I'm fine with dropping the patch and adding a blacklist file
<pitti> tkamppeter: will that cause problems on upgrade?
<pitti> tkamppeter: i. e. folks who currently have a printer set up through usblp and then get it blacklisted -- will the URIs differ?
<tkamppeter> pitti, especially there are several segfault bugs on the "usb" backend of CUPS and I fear they are from our patch.
<tkamppeter> pitti, there are differences in the URIs when a printer reports its serial number only via libusb and not via device ID, but here we could perhaps write some migration script. I can do the appropriate investigation with my bunch of HP printers.
<tkamppeter> pitti, but please do already the switchover (remove usb backend patch and add usblp blacklist) ASAP, so that testing by Oneiric users start and bug reports of non-HP users help to make the migration script (to be added later by me) covering everything.
<pitti> sure
<pitti> tkamppeter: btw, do you know the status of the cups-avahi patch? will Mike take it eventually?
<tkamppeter> pitti, in addition, the "usb" backend is a core piece of the OS, used by everyone, the firmware upload script is only a second-class application, as the default application for that is the implementation in HPLIP.
<tkamppeter> pitti, I had some personal mail exchange with him, and he finally got a copyright agreement with Red Hat, so the patch will go in, but not with 1.5.0, but with 1.5.x with x > 0.
<pitti> ah, nice
<tkamppeter> He does not like the usblp/libusb hybrid patch for the usb backend, he wants usblp deprecated, as I said, so go ahead ...
<tkamppeter> pitti, he also said that he will provide Ghostscript patches for IPP Everywhere printer support in time for Ghostscript 9.03 and so for Oneiric.
<pitti> tkamppeter: did he ever mention an opinion about the PDF filters?
<pitti> that's probably the biggest change that we have
<tkamppeter> pitti, yes, he wants them, but he needs copyright agreements of the Japanese authors and this seems to be not yet completed.
<pitti> ah, thanks
<tkamppeter> piiti, the other issue I want to talk about with you is a violation of etiquette between free software prrojects.
<tkamppeter> pitti, perhaps you have seen my talk about emacs and vi before we started our longer talk now.
<tkamppeter> Someone had already the problem of one free software project working actively against another, like for example if emacs would do "rm -f ~/.vimrc" on startup?
<pitti> I've seen that line, but no other discussion
<tkamppeter> pitti, it got overrolled by our talk about CUPS.
<tkamppeter> pitti, it is the foo2zjs project with its stubborn author.
<tkamppeter> pitti, if you look into the file /usr/sbin/hplj1000, you find the following lines:
<tkamppeter> #
<tkamppeter> #       Remove HPLIP proprietary rules!
<tkamppeter> #
<tkamppeter> model=` echo "$MODEL" | tr 'A-Z' 'a-z' `
<tkamppeter> rm -f /etc/udev/rules.d/*hpmud*laserjet_${model}*
<tkamppeter> rm -f /etc/udev/rules.d/*hpmud_support.rules
<tkamppeter> Once it solve the problem we discussed earlier, about the mysterious disappearing of UDEV rule files.
<pitti> tkamppeter: *tsk*
<pitti> so that's what removed your rules?
<pitti> this belongs patched out indeed
<pitti> not that the hplip rules generator would make any more sense, though
<pitti> it's two badly architectured programs fighting each other..
<tkamppeter> pitti, and second, it is a violation against the etiquette of making free software.
<tkamppeter> pitti, it should be even SRUed urgently.
<tkamppeter> pitti, but HPLIP is not actively fighting against other projects.
<tkamppeter> pitti, I will patch this out and SRU it. I will tell you when the SRU is up so that you can accept it quickly.
<pitti> ok, thanks
<pitti> tkamppeter: right, but hplip's "create rules on the fly which then create other rules" is not exactly state-of-the-art as well
<tkamppeter> pitti, HPLIP is installing an additional package triggered by UDEV rules. The package contains additional rules.
<tkamppeter> pitti, this can theoretically happen also if a piece of hardware triggers a driver download via Jockey.
<apw> does anyone know if we have branches for anything other than 'stable' in debian and if so what the url form is for those?
<debfx> apw: debian branches on launchpad?
<geser> apw: yes, LP has Debian packaging branches for stable, testing, unstable and experimental
<apw> debfx, yeah am trying to find the name of the y
<pitti> tkamppeter: pushed to bzr, but I can't test it here (no printer)
<apw> unstable version of iscsitarget, and lp:debian/unstable/iscsitarget doesn't seem to work
<RAOF> apw: lp:debian/sid/iscsitarget should work.
 * apw tries that
<geser> apw: lp:debian/iscsitarget
<smb> both give us a version that according to the debian page is not unstable
<apw> geser, that version is actually only the version in debian stable
<apw> geser, as does the /sid/ version
<apw> i suspect the package importer is broke
<apw> i wonder who owns that now
<geser> apw: you are right: http://package-import.ubuntu.com/status/iscsitarget.html#2011-05-24%2007:35:18.166059
<geser> apw: LP uses the Debian codenames to differentiate between the branches (see https://code.launchpad.net/debian/+source/iscsitarget)
<apw> geser, ahh thats a handy view, i should have guessed at the form, doh
<apw> geser, any idea if the fact there is a bug number in the error report means its being dealt with or should i whine as it suggests
<smb> So https://bugs.launchpad.net/udd/+bug/714622  sounds like some manual intervention is needed for now. Who would be doing that?
<ubottu> Ubuntu bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed]
<geser> apw: no idea, but I guess pinging some UDD folks won't hurt. At least you know then what's the current status of that bug is
<pitti> !?! I try ssh and all it does is fail with "get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported"
<ubottu> pitti: I am only a bot, please don't think I'm intelligent :)
<pitti> that still worked an hour or so ago, but I might have dist-upgraded
<apw> pitti, well the kernel didn't change :)
<pitti> hm, I'll just try a reboot, I guess
<apw> pitti, welcome to M$
<pitti> the only dpkg thing I did in the last hour was purging the old 2.6.39-2 kernel, so I doubt that's it
<pitti> so, M$ it is, rebooting helped
<saamm> One of my friend bought Braid from Software Center, but sound is not working. Where should I report this?
<saamm> is there an irc channel for paid apps support?
<pitti> mvo: ^ would you know?
<seb128> pitti, they are discussing it on #ubuntu-desktop it seems
<mvo> pitti: just replied in #ubuntu-desktop
<saamm> braid has no support forum, page or anything...just an email :(
<p0s> hi. i'm having trouble configuring the keyboard layout on ubuntu server = console keyboard layout (ubuntu server has no X). /etc/default/keyboard is ignored, dpkg-reconfigure console-common is ignored. any developer around who wants to help investigating?
<p0s> bugtracker entry = https://bugs.launchpad.net/ubuntu/+bug/780085
<ubottu> Ubuntu bug 780085 in Ubuntu "Keyboard language detected during netboot setup is ignored after installation" [Undecided,New]
<p0s> nevermind, "dpkg-reconfigure keyboard-configuration" worked. however the bug that the keyboard configuration during setup is not stored is still ignored.
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, did you give your Samsung away?
<pitti> tkamppeter: for a fair while now it has printed very poorly, so we have have pretty much stopped using it; it's still somewhere in a box in the cellar, we didn't unpack it yet after moving
<tkamppeter> pitti, OK, you switched to the perfect paperless office (cell phone tickets, ...).
<pitti> right
<tkamppeter> What is update-apt-xapi good for?
<mvo> tkamppeter: it udpates the apt xapian index that is used for quick searching in software-center
<tkamppeter> mvo, thx, it is taking 100% CPU currently.
<mvo> tkamppeter: it should finish soon, usually takes only a minute or so
<tkamppeter> mvo, OK, it finished already.
<ohsix> pitti: should i just run apport-retrace -u as root or is it easy to setup fakechroot
<pitti> ohsix: it's not that easy, I'm afraid
<ohsix> hm
<hrw> morning
<hrw> cjwatson: according to wiki you are archive admin today - can I ask for passing gcc-4.6-armel-cross binary packages though NEW queue?
<cjwatson> hrw: OK, will look shortly
<hrw> cjwatson: thanks
<apw> cjwatson, there was a bzr command for 'releasing' a branch that at least tagged it, what was that called again
<pitti> poolie: oh, thanks for the ecryptfs warning -- I guess I'll downgrade the kernel then..
<ogra_> apw, debcommit -r ?
<apw> ogra_, ahh that might be the one
<ogra_> (requires a proper debian/changelog and tags accordingly)
<apw> it is _so_ confusing that half the stuff is debfoo and the other half is bzr foo
<apw> it makes one feel so stupid
<ogra_> we should have an alias ;)
<ogra_> bzr debrelease :)
<ogra_> or some such
<poolie> pitti: glad it helped somebody
<poolie> it gave me a nasty feeling
<poolie> does not seem to have damaged anything, touch wood
<cjwatson> apw: you can use 'bzr tag' too if you prefer
<apw> cjwatson, i thought there was something which took you from UNRELEASED to oneiric and commited it and tagged it in one, seems not
<cjwatson> not AFAIK.  dch -r && <build> && <review> && debcommit -r && debsign -S && debrelease -S ubuntu  # is my usual workflow
<cjwatson> (bzr-builddeb installs a hook that causes 'bzr tag' to automatically use the top version number from debian/changelog if not given another argument)
<cjwatson> hrw: accepted
<hrw> cjwatson: thanks!
<apw> cjwatson, i've finished up the module-init-tools merge back with debian, had it reviewed to death, tested it to death, and am about to upload it... did you want to look it over as it was your suggestion
<cjwatson> nah, don't block on me
<cjwatson> if other developers have reviewed it, that's fine
<apw> cjwatson, ack
<cjwatson> I'll just complain about it if it's wrong.  Deal? :-)
<apw> cjwatson, yep, i have tested it as much as i can without it being in the archive, even ppad it but only natty as we don't have oneiric ones yet
<cjwatson> we don't have oneiric PPAs?  I wonder why not
<apw> i was told they wern't enabled yet, though that may be old new now
<cjwatson> when was that?
<cjwatson> they should have been enabled as part of bringing up the new series
<soren> I've been useing Oneiric PPA's for a long time.
<apw> late last week i think it was ... hmmm ...
<soren> I'd say well over oa month.
<apw> oddness
<cjwatson> that's more like what I'd expect.  just try them?
<apw> yep
<soren> We build for all of lucid, maverick, natty and oneiric for every commit to trunk in OpenStack. I seem to remember adding Oneiric to that list shortly after oneiric was installable.
<cjwatson> https://launchpad.net/builders/ shows oneiric PPA builds in progress
<cjwatson> so I think you were misinformed
<apw> cjwatson, seems so, thanks, i did all my manual builds against up to date oneiric chroots so i am happy
<tkamppeter> pitti, SRU for foo2zjs is on its way, see bug 783389.
<ubottu> Launchpad bug 783389 in foo2zjs (Ubuntu Natty) "HP LaserJet 1020 (on USB) stopped working in 11.04, worked in 10.04" [High,In progress] https://launchpad.net/bugs/783389
<OdyX> tkamppeter: can you prepare this in the Debian git repository ? ^ I can upload in short time if needed.
<pitti> tkamppeter: ah, thanks
<pitti> http://cdimage.ubuntu.com/daily-live/20110608/ \o/ -> almost there size-wise
<seb128> pitti, \o/
<seb128> pitti, how "almost"? cjwatson said we can count on 703mb isos so they are under
<didrocks> excellent :)
<didrocks> hum, compiz-plugins and compiz-plugins-main, let me see what brings them
<pitti> seb128: ah, so much the better
<pitti> next CDs will drop gdm, thus another -600 kB
<didrocks> argh, I forgot one rdepends in compiz itself(done for -plugins, not for -plugins-main)
<didrocks> one sec, doing the change
<seb128> don't tell chrisccoulson though, he will try to get tb in ;-)
<chrisccoulson> lol
 * chrisccoulson grins
<didrocks> hum, no it deps on compiz-plugins-main-default
<cjwatson> probably built with compiz 1:0.9.4+bzr20110606-0ubuntu2, which depended on compiz-plugins-main
<cjwatson> hm, no
<didrocks> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/compiz-plugins-main/compiz-plugins-main seems to tell this
<cjwatson> that's only generated every four hours FWIW
<didrocks> but yeah, compiz is ubuntu3 in the manifest
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/latest/livecd-20110608.1-i386.out looks odd; I think it may just be Task field skew or something, not worth immediately worrying about
<didrocks> cjwatson: ok, let's wait for further build then. Why do you find it weird btw?
<cjwatson> it's odd that it's showing up in "The following extra packages will be installed" - except for the kernel stuff (which is done in a different way), that indicates that dependencies and the Task fields are out of sync, since normally any dependencies should be included in the task that's being installed
<cjwatson> hence my tentative diagnosis
<didrocks> oh ok, thanks for the explanation :)
<Daviey> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: Daviey
<tkamppeter> pitti, the SRU for foo2zjs is ready, can you accept it? Thanks.
<seb128> cjwatson, did you see the gparted guy comment on your patch from yesterday? he's asking what distribution you recommend to work on that
<cjwatson> seb128: yeah, I saw, in my queue to reply
<seb128> cjwatson, ok, thanks
<mvo> lynxman, Daviey: squid-deb-proxy trunk should be in good shape now (debconf, udeb, pkg blacklist). would be nice if you could give it a critical look before I upload
<Daviey> mvo: super, where is it?
<mdeslaur> slangasek: I want to document in our CVE tracker why we're going to ignore CVE-2010-4708 (pam_env reading user dirs by default). Your commit that reverts the change mentions that it's "under discussion". Where has it been discussed? I've looked at the pam list archives, but couldn't find it.
<ubottu> The pam_env module in Linux-PAM (aka pam) 1.1.2 and earlier reads the .pam_environment file in a user's home directory, which might allow local users to run programs with an unintended environment by executing a program that relies on the pam_env PAM check. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708)
<mvo> Daviey: lp:squid-deb-proxy and there bzr-buildpackage
<Daviey> mvo: okay, thanks.. Do you want me to test the udeb?
<mvo> Daviey: that would be cool
<Daviey> mvo: okay.. will have to do that later today then.. Patch piloting at the moment.
<Daviey> mvo: okay.. will have to do that later today then.. Patch piloting at the moment.
<Daviey> bah..
<mvo> Daviey: no rush
<lynxman> mvo: having a look right now :) thanks for your effort ^
<lynxman> mvo: looks good to me :) let me know when you're building the new one for oneiric
<pitti> cjwatson: I'm currently looking at my "mailing out component-mismatch deltas" work item
<pitti> cjwatson: I'm a bit confused how that output is actually generated -- I don't see a cron job nor a script for that on lillypilly nor cocoplum?
<cjwatson> pitti: cocoplum:~lp_archive/dak/cron.sync etc.
<pitti> cjwatson: I suppose it does something like > component-mismatches.new && mv c-m.new c-m.txt
<cjwatson> cronned as lp_archive@cocoplum
<pitti> so we could slide in a diff and mail it out to the last uploader of that source package, and/or the release team
<pitti> cjwatson: ah, thanks
<pitti> cjwatson: there's uncommitted changes there (for natty->oneiric) -- is this branch supposed to be committed to directly?
<pitti> bzr info at least doesn't have any pull location
<Daviey> cyphermox: Hey.. are you watching bug 794010?
<ubottu> Launchpad bug 794010 in liferea (Ubuntu) "[oneiric] FTBFS with libnotify 0.7" [High,Confirmed] https://launchpad.net/bugs/794010
<cyphermox> I wasn't subscribed, no
<cyphermox> Daviey: but I was just bringing it up because I had looked at liferea already
<Daviey> cyphermox: Okay.. should i upload his fix, or hold out :)
<cjwatson> pitti: yeah, it is.  committed, thanks
<cyphermox> Daviey: ah, upload, no need to hold on for that
<mvo> lynxman: I will probably upload later today then to oneiric
<Daviey> cyphermox: ok, thanks :)
<lynxman> mvo: cool, ty
<apw> if one has a package which will be uploaded to oneiric and backported to lucid, but there will be a depedancy on a specific version of a support package, which will be each at different versions in the two releases ... is there a sane way to represent those dependancies?
<pitti> apw: you mean like depends: support (>= 1) [lucid] | support (>= 2) [oneiric]?
<pitti> (that doesn't work)
<apw> pitti, yeah thats the sort of thing, or perhaps
<pitti> apw: if the earlier version of the support package is sufficient, why do we need a newer depends in oneiric then?
<cjwatson> apw: just change the dep in the backport
<apw> pitti, cause the support will have to be fixed there too
<cjwatson> pitti: sufficient in lucid-updates, not in lucid release pocket
<pitti> ahh
<pitti> yeah, manual backport it is
<apw> so there is no range operators, shame
<pitti> there is <=
<cjwatson> there kind of are but it isn't worth the hassle
<pitti> but with dependencies you can only do "and" outside and "or" inside, and no negation
<cjwatson> yeah, you end up applying de morgan's laws all over the place
<pitti> so you can't do ( (>= 1.1) & (< 2) || (>= 2.1))
<apw> pitti, a
<apw> and that is what i'd want ... sigh
<cjwatson> you can, you just have to unpack it
<cjwatson> but as I said, not a lot of fun
<cjwatson> and I think it's ultimately less clear and maintainable than a manual backport
<pitti> support (>= 1.1) | support (>= 2.1), support (< 2) | support (>= 2.1)
<pitti> but that's rather unreadable
<apw> pitti, gurgle
<pitti> apw: ... manual backport :)
<debfx> or use lsb_release to generate the dependencies in debian/rules
<apw> heh yeah
<pitti> ^ if you are going to need to backport it 20 times per cycle, that might be worth it
<apw> pitti, its the LTS backport kernels so ... for every upload to oneiric
<tkamppeter> pitti, the SRU for foo2zjs is ready, bug 783389, can you accept it, so that the SRU gets quickly into the updates? Thanks.
<ubottu> Launchpad bug 783389 in foo2zjs (Ubuntu) "HP LaserJet 1000/1005/1018/1020/P1005/P1006/... (on USB) stopped working in 11.04, worked in 10.04" [High,Triaged] https://launchpad.net/bugs/783389
<pitti> tkamppeter: yes, I saw it; I'll get to it
<tkamppeter> pitti, about CUPS, the postinstall is not doing "rmmod usblp", it should do, as otherwise many printers will disappear.
<pitti> ah, until the next reboot, right
<tkamppeter> pitti, yes, and some machines like servers (or my desktop PC) reboot rarely.
<pitti> tkamppeter: pushed
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, I will add a script to migrate the USB URIs. I will tell you when this is done. Before that you should not upload. CUPS.
<pitti> right
<tkamppeter> pitti, ping
<pitti> hi tkamppeter
<Laney> mdz: I think you meant oftc in your blog post
<mdz> Laney, good catch, will fix
<Laney> np
<tkamppeter> pitti, I have found out that /usr/lib/cups/daemon/cups-deviced is broken. This program is called by CUPS when running commands like "lpinfo -v" and it segfaults most of the time, perhaps due to too long input strings.
<Laney> btw I am working at getting Ubuntu upload history into UDD
<tkamppeter> pitti, input strings from the CUPS backends which it calls without arguments.
<Laney> an all-changes list would be useful for this ...
<mdz> Laney, cool!
<Laney> :-)
<pitti> tkamppeter: can foo2zjs please be fixed in oneiric as well? without that, it can't progress into -updates
<pitti> tkamppeter: deviced crash> ugh, how come that this hasn't been discovered before? usblp URLs are shorter?
<tkamppeter> pitti, no. Some time before I have already seen that "lpinfo -v" was incomplete but did not find the time to investigate more deeply.
<tkamppeter> pitti, so I will now upload the foo2zjs as I have uploaded it as SRU, also to Oneiric, simply to unblock the process. The libusb support in foo2zjs will come after finishing CUPS.
<RoAkSoAx> mvo: howdy! I have a quick question... I'm using python-apt and getting a server list with aptsources and the get_server_list(). When I run a small script that solely does that, the function returns "[['Main server', 'http://archive.ubuntu.com/ubuntu', False], ['Server for United States', 'http://us.archive.ubuntu.com/ubuntu/', True]]" however, when I run exactly the same in another application on which I've integrated my script, it returns "[['M
<RoAkSoAx> any ideas why?
<mvo> RoAkSoAx: I'm in a meeting currently, but if you could push your script somewhere I can have a look later
<mdz> RoAkSoAx, your message was truncated, try putting it all in a pastebin
<tkamppeter> pitti, foo2zjs for Oneiric uploaded, bug 783389 should close soon.
<ubottu> Launchpad bug 783389 in foo2zjs (Ubuntu Natty) "HP LaserJet 1000/1005/1018/1020/P1005/P1006/... (on USB) stopped working in 11.04, worked in 10.04" [High,Fix committed] https://launchpad.net/bugs/783389
<RoAkSoAx> mvo: script: http://paste.ubuntu.com/621822/ result of running script: http://pastebin.ubuntu.com/621824/ Result of the same code integrated in application applitcation: http://pastebin.ubuntu.com/621823/
<RoAkSoAx> mdz: ^^
<RoAkSoAx> I'm integrating this in cobbler
<lynxman> RoAkSoAx will we have some time today to talk about cobbler+orchestra?
<pitti> tkamppeter: thanks
<RoAkSoAx> lynxman: sure, just let me get this done
<lynxman> RoAkSoAx: cool :)
<RoAkSoAx> lynxman: ok testing now
<RoAkSoAx> lynxman: what's up :)
<lynxman> RoAkSoAx: cobbler, did you have time to give it a look?
<Laney> could someone please score up haskell-src-exts?
<lynxman> RoAkSoAx: want your feedback, badly :)
<cjwatson> Laney: done
<cjwatson> er
<cjwatson> all builds are either success or failed, not needs-build
<RoAkSoAx> lynxman: yeah been reviwing it these couple of days
<RoAkSoAx> lynxman: what are your concerns
<RoAkSoAx> do you wanna take this elsewhere?
<lynxman> RoAkSoAx: just make sure that all is solid
<cjwatson> oh, blasted ubuntu-build
<lynxman> RoAkSoAx: as you want :)
<lynxman> cjwatson: *wink*
<RoAkSoAx> lynxman: u tell me :P
<lynxman> RoAkSoAx: okay let me PM you
<cjwatson> Laney: done
<Laney> cheers
<broder> cjwatson: ooc, are you planning to merge initramfs-tools 0.99 anytime soon? i want to get the fix for debian bug #625224 (i.e. our bug #565047), and get it sru'd too, and was wondering if i should wait for the merge, try to do the merge myself, or cherry-pick the patch
<ubottu> Debian bug 625224 in initramfs-tools "xhci-hcd has the wrong module name" [Important,Fixed] http://bugs.debian.org/625224
<ubottu> Launchpad bug 565047 in initramfs-tools (Ubuntu) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Confirmed] https://launchpad.net/bugs/565047
<cjwatson> broder: I think I was waiting to hear where Keybuk had got to with /run
<broder> ah, ok
<cjwatson> if it's urgent, feel free to cherry-pick
<broder> i don't think it's super-urgent - i've already worked around it locally
<hallyn> oh ffs
<hallyn> Daviey: are you around?
<hallyn> oh what am i thinking
<hallyn> RoAkSoAx: around?
<hallyn> RoAkSoAx: do you mind sponsoring ipsec-tools merge for me?
<RoAkSoAx> hallyn: sure... where do you have it at?
<hallyn> http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1
<hallyn> RoAkSoAx: ^ thanks
<hallyn> that is, dget http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/ipsec-tools_0.8.0-3ubuntu1.dsc
<RoAkSoAx> hallyn: btw.. is ti building now? I tried to merge it before but it FTBFS due to not being able to find a required library
<hallyn> and http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/ipsec-tools_0.8.0-3ubuntu1_source.changes
<hallyn> RoAkSoAx: yeah, see the DEP3 in last patch in series
<maco> ev: can i get a review on https://code.launchpad.net/~maco.m/ubiquity/791446/+merge/63197 ?  slangasek had suggested making a custom widget for qt that implements the same api as the gtk one, but it turns out the .ui compiler for qt cant handle custom widgets and barfs, making this the-way-that-actually-works (tested by charlie-tca and JontheEchidna)
<hallyn> RoAkSoAx: problem wasn't not finding a library, but configure got confused bc gcc changed its behavior wrt unknown arguments
<RoAkSoAx> hallyn: ahh I see now
<hallyn> highlights a culture diff between gcc and kernel...
<hallyn> but i digress
<Daviey> hallyn: always
<ev> maco: looking :)
<hallyn> Daviey: thx, but then i remember RoAkSoAxwas looking to exercise his newfound superpowers :)
<hallyn> remembered
<RoAkSoAx> hallyn: if you don't mind I'll point it to bug #787114
<ubottu> Launchpad bug 787114 in ipsec-tools (Ubuntu) "Please merge ipsec-tools 0.8.0-3 (main) from debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/787114
<Daviey> hallyn: ah, super
<hallyn> RoAkSoAx: oh, yeah.  i shoulda looked for that.  thanks!
<RoAkSoAx> ;)
<hallyn> RoAkSoAx: now, one thing we might consider,
<RoAkSoAx> hallyn: which one?
<hallyn> RoAkSoAx: as you see i fwded the patch to a debian bug.  i've not heard back from the debian maintainer in two days of emailing him, but are we supposed to wait for debian to get the fix, and then sync that?
<maco> ev: thanks. i'll try to figure out what check_returncode does
<ev> maco: cool, thanks!
<RoAkSoAx> hallyn: not necessarily... I personally upload to Ubuntu most of the times and still fw to debian
<RoAkSoAx> and if there's something else to merge/sync I do it later
<hallyn> RoAkSoAx: ok, cool
<hallyn> thanks again, ttyl
<RoAkSoAx> no prob ;)
<maco> ev: er, check_returncode looks like its all about wget. is that what im supposed to be looking at?
<slangasek> mdeslaur: CVE-2010-4708> was being discussed on the pam upstream committers list
<ubottu> The pam_env module in Linux-PAM (aka pam) 1.1.2 and earlier reads the .pam_environment file in a user's home directory, which might allow local users to run programs with an unintended environment by executing a program that relies on the pam_env PAM check. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4708)
<lynxman> ping mvo
<ev> maco: yes, but it calls UI-specific code
<ev> so you'd want to factor that out
<ev> into a separate function
<ev> which each UI class provides
<maco> oh bleh sorry my ubiquity branch on this machine is out of date
<ev> :)
<slangasek> mdeslaur: the argument from my side was: don't break compatibility with a feature in a security update, all the actual documented cases where this is exploitable involve coupling pam_env with other modules we don't use by default
<slangasek> mdeslaur: I'm not wedded to keeping it enabled by default indefinitely, however, and am happy to consider disabling by default or (perhaps better) dropping the feature entirely
<RoAkSoAx> hallyn: may I ask why the changes to the init script were dropped?
<_Groo_> hi/2 all
<_Groo_>  could anyone tell me why nspluginwrapper is segfaulting in nautty?
<_Groo_> natty*
<hallyn> RoAkSoAx: oh i meant to revisit that.  But the changes would have beceom more intricate; were not applied to the racoon.init;  and should be sent to debian IMO.  Otherwise on every sync we introduce needless chance for regression in init script
<hallyn> RoAkSoAx: so IMO the thing ot do is push it as is; open a bug for the init scripts (which patches attached);  and try to get it in through debian
<RoAkSoAx> hallyn: ok since I';ve seen those changes have been carried over most of the releases
<_Groo_> i make a 1.4.2 nspluginwrapper package, but its segfaulting too
<RoAkSoAx> hallyn: did you fw that to debian already?
<_Groo_> something is dead wrong, but i cant point my finger at what it is
<hallyn> RoAkSoAx: no
<RoAkSoAx> hallyn: cause I think if we want to do that... we still need to carry the diff in Ubuntu so it don't get lost
<RoAkSoAx> s/don't/doesn't
<hallyn> well it has to be a new diff in any case
<RoAkSoAx> and then fw the change as "we applied this in Ubuntu please consider using it"
<hallyn> RoAkSoAx: my assumption was that it's not very important (since, again, the racoon init script wasn't converted)
<hallyn> i can make that change if i have time this afternoon;  if not this afternoon, then it won't happen (by me) for two weeks.
<hallyn> (but again, i don't understand the urgency)
<RoAkSoAx> hallyn: right, but AFAIK, the diff makes the init script LSB compliant, which I think we should keep
<RoAkSoAx> hallyn: I guess I'll have to consult to a higher power for input on it :)
<RoAkSoAx> zul: ^^
<zul> context?
<RoAkSoAx> zul: should we keep or drop the changes to the init script: http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/
<zul> submit it to debian but i would keep it for now
<RoAkSoAx> zul: k thanks for the inpout
<hallyn> (again we can't 'keep' it, it needs some tweaking.   tweaking leads to bugs.)
<hallyn> ok, when i finish up with libcap bug i'll roll a new version, and submit debian bug
<RoAkSoAx> hallyn: I think that'd be the best cause that way we ensure that we keep the diff, and that we can forward it to debian, without having to lose the change overtime
<RoAkSoAx> hallyn: so, if the maintainer accepts it, we can just sync
<RoAkSoAx> i wonder why it hasn't been forwarded before though
<RoAkSoAx> since the diffs seems to have being carried over from breeze
<RoAkSoAx> breezy*
<maco> ev: i see set_download_updates() is already defined in both PageGtk and PageKde, so im adding a similar function for enable..., but when i call them from check_returncode, will it magically pick the one from the right page?
<mdeslaur> slangasek: I don't have a preference, I just want to fill in the info so we know what to say when people ask why we chose to ignore that particular CVE. Is the pam commiters list a public one?
<slangasek> mdeslaur: http://sourceforge.net/mailarchive/forum.php?thread_name=20101019215007.GB15393%40altlinux.org&forum_name=pam-patches
<mdeslaur> slangasek: ah, cool. Thanks for that.
<slangasek> mdeslaur: actually, it looks like I already concluded in that thread that the upstream should default to off, but this never went into effect
<mdeslaur> slangasek: ok, mind if I revert it to off in oneiric?
<slangasek> mdeslaur: I should probably get that change made upstream first, so we don't get flamed for turning off a feature locally that we pushed into upstream in the first place ;)
<slangasek> mdeslaur: do you think this behavior change warrants a mention in the oneiric release notes?
<slangasek> if not, I'd say it should at least go in the debian/NEWS file
<mdeslaur> slangasek: ok, I'll let you handle it. Honestly, I don't know what pam_env is actually used for in our case, so I don't think I can answer that.
<slangasek> I have never seen ~/.pam_environment in the wild
<slangasek> Tollef wrote the original patch IIRC; there was never a corresponding example added to /etc/skel
<hallyn> RoAkSoAx: can you think of any good reason not to also convert racoon.init?
<RoAkSoAx> hallyn: no not really, maybe it has been previously but lost throughout the years... maybe it was introduced at a later stage and was never looked at
<hallyn> RoAkSoAx: ok, i'll re-add it.  pls do double-check my logic :)
<RoAkSoAx> hallyn: will do :)
<jcastro> jhunt: DBO says that the "scale addons" plugin will do what you want (for bug 787643); I have no idea how it works though, but might help you find what you need.
<ubottu> Launchpad bug 787643 in unity "provide ability to select window by partial name/title" [Undecided,Opinion] https://launchpad.net/bugs/787643
<jtaylor> that bug is set to opinion not wishlist, mistake?
<hallyn> RoAkSoAx: new version at http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1 seems to work for me
<RoAkSoAx> hallyn: thanks! I'll take a look at it after lunch
<Keybuk> archive.ubuntu.com has no AAAA record
<Keybuk> sadface
<savid> Hi, I'd like to make my appindicator show dynamic text instead of an icon.  All of the code examples I can find just show how to do an icon.  How do I make it so that it shows text instead?
<savid> (I'm using python, btw)
<ScottK> savid: You might have more luck in #ayatana.
<savid> Thanks.
<sladen> savid: http://askubuntu.com/questions/40918/how-do-i-create-a-dynamic-quicklist
<broder> sladen: quicklist is different from an indicator
<sladen> savid: apt-get source indicator-datetime
<hallyn> RoAkSoAx: meanwhile I opened bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629828
<ubottu> Debian bug 629828 in ipsec-tools "LSB-ify ipsec init scripts" [Normal,Open]
<sladen> savid/broder: if you still can't find an answer;  I'll try and figure out an example and pop up it up on the design blog highlighting your example
<Laney> directhex: yo, seb128 is asking about uploading 2.10 - think we can do that any time soon?
<tkamppeter> pitti, hi
<tkamppeter> pitti_, hi
<jhunt> jcastro: awesome, thx!
<jhunt> jcastro: only 1 problem - enabling it kills unity. I'll update the bug...
<jhunt> jcastro: done.
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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
<directhex> Laney: are we ready on that? i'd love to get 2.10 in
<directhex> Laney: i've been away for 2+ weeks, dunno if anything changed in the last 16 days
<Laney> there's a few failures
<Laney> http://wiki.debian.org/Teams/DebianMonoGroup/Mono210TransitionTODO
<directhex> oh, wow, progress
<Laney> might be alright to do though
<directhex> Laney: imho yes. good enough for main, anyway
<directhex> Laney: worth mentioning to meebey, or will he freak out?
<directhex> ubuntu-as-exp argument, of course
<Laney> haha
<Laney> you try it...
<cnd> anyone know how to get past the "oh no! something has gone wrong!" window?
<cnd> it pops up when I log in no matter what session I choose
<cjwatson> Keybuk: fortunately, gb.archive does, thanks to datahop :-)
<cjwatson> (as a result, I suspect a majority of my incoming traffic might actually be IPv6; I should measure that sometime ...)
<Daviey> cjwatson: Because i get faster connection over ipv4, i actually fudge my dns to ignore the AAAA record :{)
<cjwatson> v6 is often marginally faster here
<cjwatson> despite being tunnelled
<cjwatson> I guess HE's peering is a bit better than my own ISP's
<stgraber> I usually get similar speed but strangely, lower latency using IPv6 (tunnelled using HE) than IPv4 here
<alexsn> hey guys, is there a bug with unity where super+1-9 keys doesn't work?
<cjwatson> yeah, there's usually not much in it between the two for me
<Daviey> maybe it has improved since i added my fudge..  i should test it again
<sebner> cnd: I'll file a bug later. Thanks for your help anyway!
<Daviey> cjwatson: although, lack of AAAA on security.ubuntu.com is less than stellar.
<cnd> sebner, huh?
<sebner> cnd: I'm the touchpad guy :)
<cnd> sebner, can you be more specific?
<stgraber> http://pastebin.com/Ej52Qsit (ipv6) vs http://pastebin.com/tyexLSrC (ipv4) for transatlanic latency, only 2ms of diference today, though I've seen it being up to 10ms faster on ipv6 :)
<sebner> cnd: We communicated over email about my touchpad problem (not being able to enable/disable it)
<cnd> ahh
<cnd> I communicate with a lot of people about their touchpads :)
<stgraber> as for speed, I have around 9.8MB/s on IPv6 and 10MB/s on IPv4, so not too big of a difference ;)
<sebner> cnd: I figure, I'm sorry
<cnd> sebner, no problem!
 * sebner hugs cnd :)
<Keybuk> cjwatson, Daviey: 6 is faster here
<Keybuk> since it's native
<Keybuk> whereas 4 goes through NAT :(
<Daviey> Keybuk: residental or work connection?
<Keybuk> work
<Daviey> Interesting, /me stops his OT chatter.
<RoAkSoAx> hallyn: ping
<hallyn> RoAkSoAx: yo
<RoAkSoAx> hallyn: alright looks good to me... though the only minor change is in nthe changelog for: debian/ipsec-tools.setkey.init: LSB init script is it is no longer a remaining change but rather/ you've rewritten differently the LSB implementation
<RoAkSoAx> hallyn: so I'm gonna go ahead and just change that if that's ok with you (the changelog)
 * hallyn flexes his bicepts - that's right, baby
<hallyn> RoAkSoAx: cool, thanks much
<hallyn> i *would* say i should go follow up on core-dev, but given the little multipath SRU fiasco earlier this week, i think i'll hold up :)
<RoAkSoAx> hallyn: hehe I think that you should just give it a try
<RoAkSoAx> hallyn: it's been a year already since you've first starting working with packages
<hallyn> i'll probably try after dublin
<RoAkSoAx> hallyn: btw... quilt as a Build-Dep is not necessary cause the source formain is already 3.0 (quilt) :)
<smoser> ok...
<smoser> so i'm looking at merging rsyslog
<hallyn> RoAkSoAx: hm?  don't think i added that
<smoser> i'm running an amd64 system (on ec2).
<smoser> if i install the debian package (from the debian archive build), version 5.8.1-1
<smoser> and switch out its config with ours, everything is fine.
<smoser> but if i build that 5.8.1-1 inside oneiric sbuild, and try those binaries, then rsyslog will restart on every message it receives.
<smoser> i believe that its all the same source, just a different compiler /build environment
<smoser> i'm looking for suggestions on how to continue debugging.
<smoser> i believe that the final comment bug 775703 was pitti_ seeing this same behavior
<ubottu> Launchpad bug 775703 in rsyslog (Ubuntu) "Please merge rsyslog 5.8.0-1 (main) from debian unstable (main) (dup-of: 794230)" [Wishlist,In progress] https://launchpad.net/bugs/775703
<ubottu> Launchpad bug 794230 in rsyslog (Ubuntu) "Please merge rsyslog 5.8.1-1 (main) from debian unstable" [Low,Confirmed] https://launchpad.net/bugs/794230
<smoser> when you see it, it *looks* like rsyslog just keeps complaining about the /dev/xconsole, but really, its getting restarted by upstart each time it gest a message
<broder> smoser: that sounds like
<broder> yeah, upstart restarting it
<broder> have you tried attaching a debugger?
<broder> oh, i see
<smoser> no. thats the next step i suppose.
<RoAkSoAx> hallyn: uploaded!! thanks!
<smoser> hm... broder so if i try to attach to the process , it dies.
<smoser> ie: gdb -p 27200
<smoser> ...
<smoser> Attaching to process 27200
<smoser> ptrace: No such process.
<smoser> ah... well that make sense now.
<smoser> i'd run 'sudo -p PID', which would generate a syslog message from sudo, which woudl cause it to crash.
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 22:00-23:30 UTC for a code update | Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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, Da
<kees> slangasek: btw, I've committed a fix for LP: #794531 to the debian PAM repo, if you want to take a look.
<slangasek> kees: w00t
<slangasek> kees: oh, you only suppressed the error message, I was going to fix it to actually know about RTTIME :)
<kees> slangasek: ah, sorry, yeah. my original intention was to suppress it, so I still want to get that in. fixing to know about RTTIME is an additional nice-to-have.
#ubuntu-devel 2011-06-09
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Launchpad down/read-only from 22:00-23:30 UTC for a code update | Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: Da
<carif__> lear
<broder> bdrung: ping? opinions on whether it would be too magical to have backportpackage -s squeeze to pull from debian and backportpackage -s maverick to pull from ubuntu, with no additional options?
<broder> (the alternative would be to add a --debian or something, but i actually think that automagically choosing would be slightly easier to implement)
<ScottK> I think if you don't know squeeze is Debian and maverick is Ubuntu more obvious options are unlikely to save you.
<persia> Namespacing only becomes important if there are multiple debian derivatives that have a common suite name without direct inheritance.  It's probably worth waiting until this happens before worrying about it unduly.
 * ScottK thinks such a situation would be 'not our problem'.
<Keybuk> fortunately I can't think of a Toy Story character name that is also an adjective
<persia> Welll, http://wiki.ubuntu.com/Derivatives/Census implies there are more schemes, but in practice, whoever commits the name to backportpackage second needs to sort out why there is an issue.
<ScottK> Keybuk: Wheezy Walrus?
 * ScottK expects it's a long shot candidate.
<cody-somerville> I don't suppose there is any X experts around, eh?
<persia> Just ask the question.  Maybe a non-expert ran into it before, or an expert is around...
<cody-somerville> My X server is currently using 2.2GiB of RAM of which 1.9GiB of it is private dirty memory on the heap. I'm wondering what information I can gather that would be helpful to an xorg developer as I don't think its likely I'll be able to reproduce so would like to get what useful information I can before attempting to use valgrind.
<RAOF> cody-somerville: Oooh, that doesn't sound good.
<bryceh> cody-somerville, list of processes running and their memory usage.  dmesg.  capture any memory related files in /proc.  Xorg.0.log.
<RAOF> cody-somerville: So, that's going to somewhat depend upon what driver you're using.  However, xrestop will give a fair idea of whether it's a runaway client.
<RAOF> cody-somerville: Also âpmap -x $(pgrep X)â output can sometimes be useful in identifying what part of the process is claiming that memory.  Chances are that it's drm mappings, though.
<bryceh> cody-somerville, most of the time with X memory errors it's due to a client going nutty with too many X requests.  So documenting the gui apps you've been running can be valuable.
<persia> `lsw` from suckless-tools is handy to generate that list
<RAOF> It's time for some dueling X advice!  Call and response! :)
<Sarvatt> RAOF: it's pretty much guaranteed he's using the nvidia binary blob with that much memory usage :)
<cody-somerville> No.
<cody-somerville> Nouvea.
<cody-somerville> or however its spelled
<bryceh> persia, sweet, didn't know about lsw
<bryceh> persia, wmctrl -l gives a similar listing
<cody-somerville> And I've already looked at the memory map for the process - 1.9GiB private dirty on the heap.
<bryceh> well, not similar; looks like lsw includes some daemons and services too
<RAOF> cody-somerville: Not in card0 mappings?  Hm.
<RAOF> cody-somerville: How long has this system been up?
<cody-somerville> RAOF, 5 days.
<RAOF> (And have you been doing anything particularly with it)
<cody-somerville> RAOF, No.
<persia> bryceh, From looking at the manpages, I suspect that discrepancies between the two are bugs.
<RAOF> cody-somerville: Has it been idle & displaying the screensaver or something?
<cody-somerville> RAOF, The extreme memory usage just occurred today (I wouldn't have noticed except I had swap disabled so my machine started being really slow).
<cody-somerville> RAOF, Yes. It was only a few days ago I discovered a massive memory leak in gltext.
<RAOF> cody-somerville: I fixed that, damnit!  What release are you on?
<cody-somerville> RAOF, 11.04.
<RAOF> Ok.  It's clearly got unfixed at some point then.
<cody-somerville> RAOF, gltext memory leak is LP #768032
<ubottu> Launchpad bug 768032 in xscreensaver (Ubuntu Natty) "gltext seems to leak memory eventually causing oom-killer to run" [Undecided,New] https://launchpad.net/bugs/768032
<RAOF> cody-somerville: Ah, yes.  I did fix that in natty, but it apparently didn't get uploaded for some reason.
<RAOF> cody-somerville: Would you have noticed if this were a slow memory leak, and it just went over the threshold today, or is this most probably a big memleak trigerrable in a shortish period?
<cody-somerville> RAOF, Its entirely possible thats its a slow memory leak. The heap hasn't grown (at least more than 0.1GiB) since I noticed.
<cody-somerville> RAOF, Unless you have anything for me to try, I'm going to reboot.
<RAOF> cody-somerville: No, go ahead.
<broder> persia: theoretically at least, we can handle the imaginary future problem of non-derived derivatives with shared codenames using dpkg's vendor awareness. but i'm not going to write the code to do so
<persia> broder, Write the code to have internal suite->vendor translation.  Commit it to Debian.  Expect extension.  In the event that someone wants to have a conflicting suite (e.g. "Wheezy Walrus"), the developers for that vendor (us in the contrived example) can write that code.  It's a future problem.
<persia> But please don't assume that {debian,ubuntu} is the universe, or we'll end up with a mess.
<lifeless> s/a/more of a /
<lifeless> :P
<pitti_> Good morning
<bdrung_> broder: both. magically if you specify -s otherwise get the current behaviour with --ubuntu (or unstable with --debian)
<broder> bdrung_: hmph. i was afraid you'd say something like that
<broder> what if i make it key off of DEB_VENDOR instead?
<broder> (i.e. DEB_VENDOR=Debian backportpackage -d maverick pkg would use sid as its source)
<persia> broder, What's the use case for that?
<broder> persia: use case for what?
<persia> DEB_VENDOR=Debian backportpackage -d maverick
<broder> well, on its own, it wouldn't do anything, but if you add ppa:broder/ppa ...
<broder> or alternatively, --build
<persia> Right.  My questions is why one would ever want to process a backport except within a distribution.
<persia> I think anything else is probably an unhealthy sign.
<broder> sid has a newer version of a package that hasn't been synced yet, and i want to put it in a lucid PPA for personal use
<broder> such a backport would be unacceptable in the real archive, certainly
<persia> And I can't say "just sync it then" because maybe it's beta-freeze.  OK.
<bdrung_> persia: the xul extension PPA is one usecase
<broder> backportpackage can already take either a local .dsc file or a package from the ubuntu archive and mangle them appropriately, so this is just providing another source for packages
<persia> bdrung_, I don't think you want me to write my thoughts on the xul extension PPA :)
<persia> broder, Right.
<bdrung_> broder: DEB_VENDOR is sufficient (no --ubuntu or --debian needed). "DEB_VENDOR=Debian backportpackage" should have the same result than "backportpackage -s unstable"
<bdrung_> persia: if you want, you can write them.
<persia> What happens if someone runs `DEB_VENDOR=Debian backportpackage -s oneiric`?
<broder> bdrung_: yeah, agreed. i'll probably switch backportpackage to use the *DistroInfo classes instead of lplib, and i think it might just turn out to be almost elegant
<persia> bdrung_, In summary, I don't think it ought exist.  I think that declaring that we weren't going to support N extensions in the archive and then deciding to support them in a PPA indicates a fundamental failure in our software delivery model, which saddens me.
<bdrung_> persia: then -s wins
<persia> -s winning sounds good.
<broder> hmm...actually, i don't think that will work
<broder> at least not as i was planning to do things
<broder> because if you set DEB_VENDOR=Debian, then i wasn't going to have it recognize Ubuntu as a distribution in your genealogy
 * cody-somerville isn't closely following along but would the information in /usr/share/python-apt/templates/ be helpful?
<bdrung_> persia: the ppa is unofficial. so it can lag behind if a new FF hits the archive.
<bdrung_> i have to leave now.
<persia> bdrung_, Yes.  This is the failure, which saddens me.
<broder> bdrung_: do you really feel that DEB_VENDOR=Debian backportpackage -s oneiric needs to work? because i don't think i think it should
<persia> cody-somerville, It's incomplete, but yeah, that's probably a better source of suite->vendor mapping than an independent implementation.
<bdrung_> broder: yes it should, because you will use dpkg-vendor to determine your basis
<broder> bdrung_: and if you set DEB_VENDOR, that will affect how dpkg-vendor works
<bdrung_> yes
<broder> so if you set DEB_VENDOR=Debian, and i start querying for your current and parent distributions, i'll never see Ubuntu and never know to look up the Ubuntu codenames
<broder> note that i'm not planning to add any validation of the destination releases at the moment
<broder> so DEB_VENDOR=Debian backportpackage -d oneiric -s sid would still work
<bdrung_> yes
<broder> but DEB_VENDOR=Debian backportpackage -s oneiric would not
<hyperair> pitti: ping.
<hyperair> pitti: could you ack my message to technical-board@lists.ubuntu.com?
<pitti> hey hyperair
<pitti> ah, sure
<pitti> hyperair: done
<pitti> meh, is there any LP operation that doesn't time out?
<lifeless> pitti: see the launchpadstatus feed or #launchpad topic
<lifeless> pitti: http://identi.ca/launchpadstatus/all
<pitti> ah, thanks
<lifeless> OTOH https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-tags-content which was an 11+second page is now pretty snappy ;)
<hyperair> pitti: thanks.
<didrocks> good morning
<dholbach> good morning
<didrocks> ev: for bug #794556, have you upgraded anything else in the same time? unity 3.8.14-0ubuntu2 is just a dependency field change on compiz in debian/control
<ubottu> Launchpad bug 794556 in unity "Unable to load icon text-x-preview at size 48 in a loop" [Undecided,Confirmed] https://launchpad.net/bugs/794556
* mthaddon changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: Da
<Satoris> We are releasing a new version of libgrip, transitioning from GTK2 to GTK3. Currently the version is 0.1.7 and the Ubuntu package is called libgrip-0.1.
<Satoris> I'm told that the version numbers should somehow be connected to GTK versions.
<Satoris> What's the correct way to bump version numbers and packages?
<Satoris> Having both the GTK2 and GTK3 versions parallel installable would be nice but not absolutely necessary.
<RAOF> Satoris: I believe a correct thing to do here is to bump SONAME, which will (a) be easy and (b) make them parallel-installable.
<RAOF> I presume that you're a member of the upstream developers?
<Satoris> Yes.
<cjwatson> we also have a few libfoo-gtk3-$(SONAME) packages - whether that's worth it probably depends on the extent of dual-running that's expected
<kingmilo> Hi Gents.
<Satoris> Should the package name then be updated to libgrip-0.2?
<kingmilo> With regards to network-manager package and the applet, which file manages the layout of the applet when you click on network-manager from within the Gnome desktop?
<cjwatson> if you're not proposing to support the new version on GTK3, or at any rate not for long, it wouldn't be worth a -gtk3 package
<Satoris> Wait, you mean support the new version on GTK2?
<cjwatson> sorry, yes
<kingmilo> or how can I determine which file manages it etc.
<cjwatson> kingmilo: it'll be one of those listed in 'dpkg -L network-manager-gnome'
<cjwatson> 'apt-get source network-manager-applet' if you want to inspect the source
<kingmilo> thanks cjwatson , much appreciated.
<RAOF> Satoris: What's your current SONAME?  The libgrip-0.1 package nomenclature suggests that the library doesn't currently have one.
<Satoris> I'm not exactly sure, as I just got to working on it.
<Satoris> configure.ac has this: m4_define([grip_interface_age], [0])
<Satoris> I'm not familiar with the intricacies of library versioning and related things. :)
<RAOF> Yeah, it's non-obvious.
<kingmilo> Gents, the top right hand panel in the gnome desktop, ie. battery icon, network-manager date/time etc, where are the files located to edit those icons/text for those applets?
<RAOF> In their respective source packages; gnome-power-manager, network-manager-gnome, indicator-datetime, etc.
<kingmilo> For example i looked through the entire Network Manager applet code for the text "Connect to Hidden Wireless Network..." as an example and I cannot find it anywhere so i am certain that I must be looking in the wrong place?
<kingmilo> RAOF, i did # 'apt-get source network-manager-applet' and looked within the respective packages displayed for that text but I cannot find it.
<kingmilo> I found the XML for the network-manager configuration but not for the applet.
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<tkamppeter> pitti, it is about the URI migration script for CUPS. To make it working with best reliability one needs to have the user's printers turned on while updating the CUPS package.
<pitti> tkamppeter: if they are off, wouldn't the autoconfiguration magic just re-add them if the URI changed?
<tkamppeter> pitti, I have to investigate this. I have saved the old URIs which CUPS had given to my printers with usblp, can hand-edit them into printers.conf and then check the system behavior.
<tkamppeter> pitti, one problem of re-detection of printers is that the user gets left with old queues which do not work any more and new queues which do not contain the user's individual default settings.
<pitti> right
<tkamppeter> pitti, by the way, I have fixed the segfault in cups-driverd. The problem was in our patch.
<pitti> tkamppeter: it just seems weird to me that they wouldn't have the same IEEE1284 ID?
<tkamppeter> pitti, there are the following problems:
<pitti> manufacturer, model, etc. certainly shouldn't change?
<tkamppeter> 1. SOME of the new URIs have an added &interface=1 at the end when libusb is used.
<tkamppeter> 2. For some printers the new URIs have a serial number and the old not, as the libusb interface does not only search for the serial number in the device ID but also in the raw USB communication, to widen the range of printers from which two of the same model can be on one computer.
<tkamppeter> 3. My tests have shown that for some HP printers the model name in the new URI starts with "HP " and in the old URI not.
<tkamppeter> pitti, these are the discrepancies which I have observed with a sample of 8 HP printers (inkjet and laser, wide range of price classes, 40 EUR to 3000 EUR).
<pitti> tkamppeter: do we actually know the device ID of already configured queues? or just the URI?
<tkamppeter> pitti, only the URI, see also the fuzzy matching of URIs which I had to do in /lib/udev/udev-configure-printer. So I am very happy that we deprecate usblp, to reduce to one standard access channel.
<pitti> ah, too bad
<pitti> otherwise we could match the old and new URIs via the device IDs
<tkamppeter> pitti, I need to try to read out my printer's device IDs not using CUPS. With this I could probably spot some problems.
<tkamppeter> pitti, I have read the device URIS with usblp and the stand-alone tool usb-printerid now and the MDL entries correspond with the URIs of libusb.
<tkamppeter> pitti, CUPS does always s/Hewlett-Packard/HP/ which is reducing the mess somewhat.
<pitti> oh, fun -- that seems pretty arbitrary?
<pitti> but as long as that replacement list is short and fixed, we might duplicate it?
<tkamppeter> pitti, for me it looks like that the URI building code in the two versions of the USB backend of CUPS is out of sync.
<pitti> tkamppeter: but now we just have one left, right?
<pitti> cjwatson: would you agree that we should limit the mail spam about component-mismatch to newly added "source/binary promotion"? the other sections seem like something the AAs/release team can usually deal with themselves
<pitti> and having timely notifications for those is not that interesting
<tkamppeter> pitti, I am currently looking into "lsusb -vvv", but there are no device IDs. I have to find out how device IDs are read via libusb.
<cjwatson> pitti: yeah
<cjwatson> pitti: perhaps also source-only promotions (which are usually due to some mistake, but even so)
<OdyX> tkamppeter: what has been the outcome of the "color management" discussion on the Ubuntu side ?
<tkamppeter> OdyX, on Ubuntu they principally want color management, but they do not have the time for implementation, so this ends up in either me to introduce the new packages, like colord or someone at Debian.
<OdyX> tkamppeter: is the scope of "colord" broader than just printing ? (Core question being "would it have a logical place in pkg-printing or should we rather create another packaging team?"
<tkamppeter> OdyX, it is broader, color management covers also monitors and scanners.
<OdyX> tkamppeter: okay; and what number of packages would that be ? 1-3; 10 ?
<tkamppeter> I think 1-3 new packages and around 10 updates of existing packages (enable color management support).
<OdyX> okay, I think we have two options: a) do it "team-less" b) do that in pkg-printing. I'd go for b), with git packaging on alioth.
<tkamppeter> OdyX, see https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management, the "Related bugs" are the work items of the Blueprint, and to implement the Blueprint they all need to be fixed, preferrably in both Debian and Ubuntu.
<OdyX> tkamppeter: the other possibility is to get your packages first in Debian through sponsoring (two of us DDs offered help in that domain) and then sync, no matter where the packaging is VCS-maintained. alioth/git is my prefferred horse, but I can live with anything else.
<tkamppeter> OdyX, OK, so I will do the two "needs-packaging" items and commit them to a GIT on Alioth. Can you prepare these gits and tell me how to correctly commit?
<tkamppeter> OdyX, if someone comes up to Debian and volunterrs, he is naturally welcome.
<OdyX> tkamppeter: as you have collab-maint rights, you can create the repositories yourself: http://wiki.debian.org/Alioth/Git#Collab_Maint_project
<tkamppeter> OdyX, thanks.
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: dholbach, Da
<dholbach> Daviey, can you "/nick Da" and "@pilot out"? ;-)
<dholbach> (I assume that was you :-))
<Laney> does the bot break if you just change the topic?
<dholbach> no idea
<dholbach> james_w, cjwatson: can one of you please mark https://code.launchpad.net/~abone/ubuntu/natty/procps/fix-for-753124/+merge/58905 and https://code.launchpad.net/~akkzilla/ubuntu/natty/gmemusage/gmemusage-fix-370735/+merge/61171 as "work in progress" please? they have both been reviewed already and it'd be good to get them out of the queue
<Daviey> dholbach: oops
<Daviey> @pilot out
<Da> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: dholbach
 * dholbach hugs Da
<dholbach> ;-)
<dholbach> james_w, cjwatson: same for https://code.launchpad.net/~chalet16/ubuntu/natty/xorg-server/fix-for-518132/+merge/60297 please
<dholbach> incidentally, is there anybody else I should be pinging about this?
<cjwatson> LP, so that we don't have to do it any more :-)
 * dholbach hugs cjwatson
<cjwatson> (I'll look when I'm not on my phone which doesn't know my new LP password)
<dholbach> sure sure - take all the time you need - I'm happy to give you a collated list once you're back
<lynxman> ping Daviey
<zyga> how can I make pbuilder --create reuse existing apt cache in some directory, passing --aptcache does not seem to affect this
<cjwatson> dholbach: marked those three branches WIP now
<geser> zyga: as debootstrap is used to create the base.tgz for pbuilder, I don't know if pbuilder passes --aptcache to it or if debootstrap supports some sort of cache (besides a proxy)
<zyga> geser, yeah, I can see that now, I'm using apt-cacher-ng to see if I can speed things up
<hrw> zyga: http://paste.ubuntu.com/622496/ may be helpful
<ogra_> you could use a wrapper that makes a backup of the debs on first run ... and on subsequent ones you can use the file:// protocol to pull from the backup
<tkamppeter> pitti, hi
<hrw> zyga: or tell pbuilder that OTHERMIRROR=http://apt-cache-nghost:3142/archive.ubuntu.com/ubuntu
<zyga> hrw, yeah, that will work too! thanks
<zyga> hrw, I hope that pbuilder reuses global apt configuration
<hrw> zyga: you can configure each base system of pbuilder: "pbuilder --save-after-exit login"
<zyga> hrw, yeah but that's now what I'm after
<zyga> hrw, I want automated stuff
<ogra_> but but ... that will make you jobless one day !
<hrw> zyga: on my machine pbuilder unpacks base tarball, do apt-get update/upgrade in it, then builds. after build installs lintian and runs it. then copy results to /var/cache/pbuilder/result/DIST-ARCH/
<zyga> hrw, I'm doing something that may be interesting for you
<hrw> zyga: and ~5:00 cron job updates each pbuilder base ssytem to newest packages
<zyga> hrw, I'll show it to you in person in dublin
<hrw> zyga: ok
<hrw> zyga: nice to know that you will get there
<zyga> hrw, you don't have to build packages for earlier systems do you?
<hrw> zyga: I do lucid/maverick/natty/oneiric/sid here
<zyga> hrw, oh good
<zyga> hrw, so you feel my pain :)
<zyga> hrw, I'm working on something to make it easier
<hrw> zyga: pain? "DIST=lucid ARCH=i386 pdebuild"
<zyga> hrw, but my use case also has many interdependent packages in the mix
<zyga> hrw, yes, pain
<zyga> hrw, it's not just that
<zyga> hrw, you want to test while developing and release for all easily
<zyga> hrw, and not just one package but many
<hrw> zyga: inter builds dependencies can be solved by hook which adds results into local apt repo
<zyga> hrw, some of which may be required backports, not your own stuff
<hrw> zyga: ok
<zyga> hrw, I have the same hook but you don't want to go and build each one by hand (even with dozen packages x 4 systems it's already messy)
<zyga> hrw, and one more thing: after all this works for you you'd like to be able to reproduce the same setup on another system easily
<zyga> hrw, (to do another QA, migrate your workstation, etc)
<hrw> for dsc in *dsc;do for dist in lucid natty maverick oneiric sid;do for arch in amd64 i386;do DIST=$dist ARCH=$arch pbuilder --build $dsc;done;done;done
<zyga> hrw, ok, which of those failed, why? can I have the logs please? ;-) what is the proper build order to get the interdependent packages to work?
<zyga> hrw, can I tag the stuff that works and publish it please?
<zyga> hrw, and so on :)
<hrw> zyga: build logs are kept for each of them
<hrw> zyga: ok, so you make pbuilder/sbuild/buildd in other way?
<zyga> hrw, it's a higher-level system
<zyga> hrw, it uses pbuilder
<Daviey> cjwatson, Is a recently introduced (new) package in Debian sync'd using the same process or the normal incremental sync's?
<Daviey> s/or/for
<zyga> hrw, I'm still polishing it for my work but I'll gladly share it
<zyga> hrw, how many source packages do you make?
<cjwatson> Daviey: we have a tool to report which new packages in Debian haven't been synced into Ubuntu yet, and while I do garden that list more or less daily it's a while since it's been at zero.  What package are you interested in?
<Daviey> cjwatson, There are a few that jamespage are watching, they've only been in Debian a few days. I suspected it was treated as a sync, so was confused why it hadn't appeared yet.
<Daviey> No hurry on them tho.
<cjwatson> it's no work to expedite them, just tell me the package names
 * Daviey dig
<Daviey> s
<dholbach> cjwatson, thanks a lot!
<jamespage> Daviey, cjwatson - I just double checked and most of them have now appeared; guava-libraries is the only one I can't see ATM
<Daviey> jamespage, what about txw2, tiger-types, sezpoz, maven-antrun-extended-plugin  ?
<Daviey> maven-antrun-extended-plugin is there actually
<Daviey> bah, no it's not.
<cjwatson> Daviey: I did all four of those recently
<jamespage> Daviey: all there "Ubuntu Archive Auto-SyncÂ 30 minutes ago"
<jamespage> cjwatson: think that may have been when Daviey and I where discussing where they had got to...
<Daviey> cjwatson, Ah!  I guess they haven't been published yet then.
<cjwatson> jamespage: synced guava-libraries now
<jamespage> cjwatson: thankyou!
<cjwatson> np
<cjwatson> in fact, looks like you can have binaries for the bulk of those too *clickety*
<Daviey> cjwatson, allowing just the source packages through sounds like a fun tease.
<cjwatson> Daviey: they inevitably hit NEW at separate times
<ogra_> cjwatson, when porting to live-build, can you take into account that armel switches to ubuntu-desktop ?
 * ogra_ is wondering if it makes any sense to do that switch in livecd-rootfs at all
<cjwatson> I shouldn't need to.  you can just start building for the ubuntu project rather than ubuntu-netbook in cdimage
<cjwatson> if you're having to take account of that explicitly in either livecd-rootfs or live-build, you're doing it wrong
<cjwatson> (is there a spec for this I can go and read?)
<ogra_> cjwatson, no, no spec, we just want to drop netbook in favour of the desktop seed
<ogra_> looking at the code though it should just work
<cjwatson> then the right thing to do is switch to the ubuntu project - most package selection depends on the project (aka flavour) you're building, not on the architecture
<ogra_> yes
 * ogra_ thought we had something hardcoded in livecd-rootfs, apparently we dont, sorry to have pinged you before finishing to read the code :)
<ogra_> i thought the jasper switch was tied to the flavour, but we tied it to the filesystem type
<hrw> zyga: now I have 12 source packages
<sladen> 12 little source packages, sitting on the wall...
<james_w> ddebs.ubuntu.com expiry is controlled by some process external to LP that looks at the Packages files on archive.ubuntu.com or similar?
<pitti> james_w: correct
<james_w> pitti, is that code public somewhere?
<pitti> it's meant to be, but just on people.c.c; hang on
<pitti> james_w: lp:~pitti/+junk/ddeb-retriever
<james_w> pitti, thanks
<james_w> pitti, it seems that some ppas now build debug symbols and the refcounting doesn't take them in to account. Would it be a problem in principle to change that so that they aren't expired if the ppa still uses the package?
<pitti> james_w: http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/view/head:/archive_tools.py#L356 in particular
<pitti> james_w: ddebs.u.c. doesn't count PPAs
<james_w> perhaps we should just leave this up to the LP project which is likely to move this to be part of LP
<pitti> s/count/handle/
<pitti> and frankly, handling the ubuntu archive alone is already way more fragile than I'd like to be :/
<pitti> this really should just go into LP, and AFAIUI it's 90% there
<james_w> apparently it does pick up some ddebs from ppas though
<pitti> well, yes
<pitti> it downloads all ddebs from the buildds
<pitti> as it doesn't know/check which builders are for PPAs and which for ubuntu
<james_w> right
<ScottK> That's not good.
<james_w> I'll likely wait for LP to do it then
<pitti> but as they don't appear in Packages.gz, they wither away quickly
<ScottK> Ah.
<pitti> otherwise I'd need to not just apt-ftparchive one archive, but umphteen thousand
<jdstrand> pitti: hey, so I noticed that the regression-alert alerts various people (it seems like mostly tech leads?), but I think it might need to be updated
<james_w> yeah
<pitti> jdstrand: ah, if only I'd remember who is responsible for programming ubottu's brain
<pitti> ubottu: who is your father?
<jdstrand> hehe
<pitti> "Your edit request has been forwarded to #ubuntu-ops."
 * didrocks would have love for an answer to be computed :-)
<pitti> heh, that might actually do it
<pitti> jdstrand: if you join #ubuntu-ops, there might be people to help out?
<jdstrand> pitti: yeah, thanks!
<pitti> didrocks: at least it didn't say "Anakin"
<didrocks> pitti: heh, right :)
<smb> pitti, I am not sure the same will happen to the latest packages moved, but rmadison is telling me some of the previous images would be in *-proposed/universe. Could this be some other copy issue?
<smb> linux-image-2.6.35-30-server | 2.6.35-30.53 | maverick-proposed/universe | amd64
<pitti> smb: hm, I can't actually specify a component during copying
<pitti> I'll just move it to main for now
<pitti> smb: might be fallout from today's LP rollout?
<smb> pitti, I am wondering whether that had been before... I noticed uninstallable kernels yesterday but thought it might be delays
<smb> It seems meta was going to the right place...
<pitti> strange
<pitti> moved to main, anyway
<smb> pitti, This seems to affect at least lucid and maverick, but I would suspect any of the recent proposed uploads
<pitti> smb: right, it seems to have affected all of today's package copies; seems LP changed behaviour there, even for packages which already existed in ubuntu before :/
<pitti> *just* when you think you got everything sorted out
<pitti> StevenK: ^ do you happen to know about this? package copies from PPAs to ubuntu now land in universe, even if they exist in main already?
<smb> You know that has to happen when the universe is about to be understood
<pitti> yeah
<highvoltage> heh, nice.
<doko> pitti: https://launchpadlibrarian.net/73256289/buildlog_ubuntu-oneiric-i386.eglibc_2.13-5ubuntu1_FAILEDTOBUILD.txt.gz
<doko> pitti: ahh, wait, that not the error
<Laney> pitti: can you set a header on those mails so that I can filter them reliably?
 * apw is upgrading a box to oneiric and being asked if they want to use gdm or lightdm, does lightdm work ?
<didrocks> apw: I have been able to log this morning, not sure it's the case for everyone :)
 * apw watches libc fail to install ... oh dear
<pitti> Laney: sure, any preference?
<Laney> nope
<Laney> X-UbuntuRelease: component-mismatches or something
<Laney> you might consider sending to the list too
<Laney> :-)
<pitti> Laney: hm, good point, I'm subscribed
<pitti> Laney: changed to ML now
<Laney> cool
<Laney> thanks for doing this - will be useful
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<DoctorPepper> hi guys !!!
<dpolehn> hello!
<DoctorPepper> chrisccoulson:  how  do  build  firefox global menu extension  ?
<chrisccoulson> DoctorPepper, why would you want to do that? we already provide binaries
<chrisccoulson> unless you're hacking on it of course ;)
<DoctorPepper> actually   i am trying to create a package for  fedora
<chrisccoulson> DoctorPepper, it won't work in fedora will it?
<chrisccoulson> unless there are also packages for the other bits of the unity stack
<chrisccoulson> i don't know if that's the case though ;)
<DoctorPepper> actually i was  told  that  i would work  with gnome2-globalmenu
<chrisccoulson> DoctorPepper, hmmm, i'm not sure about that
<chrisccoulson> i've certainly never tried it ;)
<DoctorPepper> so how to generate the makefile so as to build this exention
<chrisccoulson> DoctorPepper, well, you need to run autoconf2.13 in the source directory first
<chrisccoulson> then ./configure --enable-application=extensions --enable-extensions=globalmenu --with-libxul-sdk=<path_to_firefox_sdk> --disable-libnotify --disable-crashreporter --disable-tests --disable-webm --disable-ogg --disable-alsa --disable-strip --disable-strip-libs
<chrisccoulson> then make ;)
<chrisccoulson> you just need to point it to whereever your firefox SDK is
<chrisccoulson> note that this extension uses a lot of volatile interfaces in firefox, so it will probably need rebuilding for each new firefox version
<DoctorPepper> build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES
<DoctorPepper> chrisccoulson:  running autoconf i get this message : ' build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES '
<chrisccoulson> what version of autoconf?
<DoctorPepper> 2.68
<chrisccoulson> you need 2.13
<chrisccoulson> it uses the firefox build system, which only works with 2.13
<kees> @pilot
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<kees> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: kees
<kees> @pilot in
<dholbach> kees, testing the bot? ;-)
 * dholbach hugs kees
<kees> dholbach: hehe, well, I'm doing a double-shift, and that made me wonder if it would append me twice. :)
<dholbach> haha :)
<SpamapS>  linux 3.0-0.1 (Accepted) ....
<SpamapS> Thats just.. weird..
<SpamapS> ;)
<ion> heh
<cjwatson> I'd better go fix the installer soon, now that I have example packages to work from :-)
<jdstrand> hallyn: hey, fyi I am back to testing libvirt. attach-disk also fails in a similar as the 'phy' vs 'qemu' thing you fixed. eg, this used to work:
<jdstrand> attach-disk vmname /tmp/foo.img sdc --driver=file
<jdstrand> that now has to be:
<jdstrand> attach-disk vmname /tmp/foo.img sdc --driver=qemu
<jdstrand> hallyn: I don't know how that might affect openstack or euca, but it is worth noting
<hallyn> Daviey: zul:  I'm basically out as of this afternoon, can you two llok at uec and openstack wrt jdstrand's comment?  i'd assume openstack folks would have noticed...
<jdstrand> hallyn, Daviey, zul: fyi, this is 0.9 specific, which I plan to upload later today
 * jdstrand needs to double-check natty
<hallyn> jdstrand: thanks
<Daviey> hallyn: ack
<zul> hallyn: afaik openstack doesnt use libvirt to attach disks
<Daviey> zul: I suggest we run the test suite.. and see if anything breaks :)
<zul> Daviey: well duh :)
<hallyn> heh
<jdstrand> zul: ok, then I'll ping you after I've uploaded
<DoctorPepper> chrisccoulson:  i manage  to buid firefox globalmenu  extesion  but  in  i found  that  there is no make install command  so  where should i put the compiled files
<zul> jdstrand: thanks, there is an open mir to get libxen3-dev replaced with libxen-dev so we can use xen 4 with libvirt and therefore dropping xen-3.3 from the archive
<chrisccoulson> DoctorPepper, there will be an extension in dist/xpi-stage
<jdstrand> cool
<zul> jdstrand: i need to bug/bribe kees about it though
<DoctorPepper> yes  so i only install the xpi  everything should be in the right place
<chrisccoulson> yep
<DoctorPepper> chrisccoulson:  i havent  found  any  xpi extension package in dis/xpi-stage
<chrisccoulson> DoctorPepper, it will be there if it built successfully
<kees> zul: what's the bug #?
<zul> kees: 790854
<kees> cool
<slangasek> cjwatson: do you have the bandwidth to tackle bug #597673 this cycle, by chance?  Or maybe this is a 'bitesize' bug that you could mentor someone on? :)
<ubottu> Launchpad bug 597673 in console-cyrillic (Ubuntu Oneiric) "console-cyrillic changes settings on consoles it doesn't own, causing crashes with plymouth + X" [Critical,Triaged] https://launchpad.net/bugs/597673
<zul> jdstrand/hallyn: nova test suite passes with the new libvirt
<seb128> jhunt, hi
<seb128> jhunt, comment following something you said the other day, "unity --reset" is to reset the config, when using ccsm break it you just usually need to restart compiz or to run "unity" which will not reset the config
<smoser> are debian build logs available anywhere ?
<seb128> smoser, https://buildd.debian.org
<smoser> thank you seb128
<seb128> yw
<cjwatson> slangasek: wow, what a bug.  it probably isn't realistically bitesize, but I think I can take care of it ...
 * cjwatson assigns/milestones
<slangasek> cjwatson: great, thanks :)
<calc> finally updated my maverick system to natty and it won't let me use more than 1024x768 on my 1920x1080 lcd with mobility radeon 4200
 * calc wonders if that is some sort of kernel regression, going to try fglrx
<calc> it actually even worked until i removed my user dir, it was low res in gdm but switched to high res afterwards, very strange
<calc> fglrx works in any case :)
<jdstrand> zul: I have not uploaded it yet. I didn't ping you yet :)
<jdstrand> zul: uploaded just now
<zul> jdstrand: cool thanks
<jdstrand> hallyn, zul, Daviey: there is a regression I need to file a bug on the apparmor driver not updating the profile with 'save', but that is relatively minor and I figured it more important to get it uploaded than block on the bug
<Daviey> jdstrand, in oneiric?
<jdstrand> Daviey: yes, in the new libvirt I just uploaded
<jdstrand> 0.9.1
<jdstrand> Daviey: it's hallyn's merge
<Daviey> ah!
<Daviey> jdstrand, Are you driving a fix for it today?
<jdstrand> and the thing that changed attach-disk
<jdstrand> Daviey: I uploaded ubuntu1 with the regression. I plan to investigate today, and possibly tomorrow have a fix-- it might be monday
<Daviey> jdstrand, okay, if we can help in any way - please let us know. :)
<jdstrand> Daviey: thanks there is a commit that I am investigating, otherwise I know exactly where to look-- it might take a bit, but I'm pretty familiar with the code, so I'll get it going
<Daviey> jdstrand, i suspect you are a little more familiar than me :P
<jdstrand> hehe
<smoser> doko, around ?
<smoser> well, maybe someone else can speak up.  i've been trying to get us caught up with debian on rsyslog. (bug 794230).
<ubottu> Launchpad bug 794230 in rsyslog (Ubuntu) "Please merge rsyslog 5.8.1-1 (main) from debian unstable" [Low,Confirmed] https://launchpad.net/bugs/794230
<smoser> if the build is done with LDFLAGS="-Wl,-Bsymbolic-functions" (the default in the Ubuntu build environment), then rsyslog segv's on first message
<smoser> debian's build does not suffer this problem as their default build has empty LDFLAGS.
<smoser> i'm wondering if it is acceptable to build with LDFLAGS=""
<smoser> pitti, ? you were last-touched for rsyslog, i wonder if you have comments.
<cjwatson> smoser: acceptable as a temporary workaround at least
<cjwatson> sounds like plugin loading trouble
<smoser> right.
<smoser> ok, so i'll go on with testing the build a bit more and then propose for merge. thank you.
<smoser> cjwatson, would there be a better way to do that than this:
<smoser> http://bazaar.launchpad.net/~smoser/ubuntu/oneiric/rsyslog/merge-debian-5.8.1-1/revision/41
<cjwatson> smoser: I normally just do 'unexport LDFLAGS' somewhere near the top of debian/rules
<cjwatson> (with a comment explaining why)
<smoser> that'll do.  i'd not seen that before. thanks.
<cjwatson> the explanatory comment needs to be in the source as well as in revision control log
<cjwatson> s
<smoser> right.
<kees> slangasek: are you working on 742017 already? I see you assigned it to yourself last week.
<slangasek> kees: hmm, don't even remember now why I assigned it to myself - certainly not working on it now
<slangasek> (probably because I knew there had been noise already about the popcon problem on debian-dpkg and I meant to follow through
<slangasek> )
<slangasek> kees: upstream thread, upstream bug: http://lists.debian.org/debian-dpkg/2011/05/msg00047.html http://bugs.debian.org/622322
<ubottu> Debian bug 622322 in popularity-contest "popularity-contest: popcon tries to access dpkg internal files and fails with multiarch: same packages" [Important,Open]
<slangasek> (so, nack on the "Forwarding patch to Debian is likely inappropriate")
<kees> slangasek: hehe
<kees> yeah, I ignored that bit. :)
<chrisccoulson> siretart, there?
<chrisccoulson> actually, NM, i think i just answered my own question ;)
#ubuntu-devel 2011-06-10
<directhex> when is a good time to break the world?
<sebner> directhex: just before weekend!
<directhex> i.e. when's the nearest alpha or whatevs being spun?
<RAOF> directhex: Uploading 2.10?
<RAOF> directhex: The next alpha's some weeks away.
<directhex> RAOF: scheduling it, yes
<directhex> RAOF: it means rebooting my bitcoin miner away from windows though. or i could use the work laptop
<RAOF> 7th of July is alpha 2.
<RAOF> If you want to break the world, now's a pretty good time.
<directhex> agreed
<cjwatson> yeah, it's OK
<cjwatson> I expect Linux 3.0 will be breaking random bits of the world for a while too
<directhex> cjwatson: the CDs will be oversize until the 2.10 transition is over, FYI
<cjwatson> OK
<directhex> no turning back now :o
<directhex> cjwatson: it seems i (and i guess the mono group) lack the rights to upload cli-common. can it be added to the packageset?
<stgraber> hmm, indeed, for some reason it's in the "core" package set
<RAOF> directhex: If you need a sponsor for now, I'm happy to help.
<directhex> RAOF: well, feel free to syncpackage it yourself from exp
<RAOF> Will do.
<directhex> s' largely your work anyway isn't it?
<RAOF> Quite a lot of the changes will be, yeah.
<kees> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<TheMuso> /c/c
<broder> when did the patch pilots become unfriendly?
<broder> ...huh. apparently a couple of months ago
<lifeless> thats not the intent
<lifeless> so perhaps raise that for discussion
<pitti> Good morning
<pitti> smoser: so that's the reason for it re-starting over and over? not the /dev/xconsole warning?
<pitti> smoser: that would at least be a more appropriate behaviour of rsyslog :)
<pitti> smoser: fine for me
<stgraber> morning pitti
<TheMuso> broder: How have they become unfriendly?
<TheMuso> Hrm seems oneiric has some LVM troubles, and seems that logging out of any GNOME session is broken, at lesat for me.
<TheMuso> broder: I'm interested because if I am appearing less friendly, I want to do something about it.
<ajmitch> TheMuso: I think the topic used to have room for mentioning the friendly patch pilots
<TheMuso> ah ok.
<ajmitch> so I don't think it's any change in attitude, just in what fits in the channel topic :)
<TheMuso> ah ok.
<broder> TheMuso: yeah, sorry - what ajmitch said
<broder> the people themselves are fantastic
<TheMuso> ok then thats good.
<broder> let's see...if i go and twiddle with...
* broder changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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 | Current Friendly Patch Pilots:
<broder> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: broder
<broder> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<broder> lame
<didrocks> good morning
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, about CUPS, I have found out something about the problems with the USB URIs.
<tkamppeter> pitti, the device IDs are absolutely the same when read out via usblp or via libusb.
<pitti> tkamppeter: right, that's good (expected though); but I thought we don't have the original device IDs?
<tkamppeter> pitti, the two usb backend versions have an inconsistency. The usblp backend removes a repetition of the manufacturer name in the MDL field of the ID, the libusb backend does not do so.
<tkamppeter> pitti, this is a bug and can be fixed with a simple patch in the libusb backend.
<tkamppeter> pitti, this would solve one of the three causes of differences which I showed to you yesterday.
<tkamppeter> pitti, the other two, having no serial number with usblp and having a serial number with libusb and also having the "interface=1" in the URI are additional features of the libusb approach.
<tkamppeter> pitti, dropping them would make the URIs absolutely equal, but we should not remove these features.
<tkamppeter> pitti, a solution which does not require the user to have his printer turned on while updating CUPS would be to let the libusb-based backend be able to use the old URIs and this is not complicated to code, as the  code for that is in the patch which we dropped. I can create a simpler patch with only that code and the code also somewhat improved, to remove a possible cause for a segfault.
<pitti> tkamppeter: I think making this work for printers which are turned on should cover most cases indeed
<pitti> tkamppeter: right, I don't like dropping the interface=1 either, as it would again be an inconsistency with how upstream handles that, and also more error prone
<tkamppeter> pitti, with the new patch the old URIs will simply be accepted by the new USB backend, allowing the user to print without URI migration. This will help all migrating users, as with using usblp before they could not have two printers of the same model connected when usblp did not reveal the serial numbers and they also could not have used all the interfaces of a multi-interface printer.
<tkamppeter> pitti, warnings in error_log could tell that the URIs could be improved.
<pitti> that sounds good
<pitti> so new printers would use the full URIs, but the old ones keep working
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: didrocks
<dholbach> good morning
<tkamppeter> pitti, exactly that, new printers will use the full URIs, but the old ones keep working
<tkamppeter> pitti, I have updated CUPS now with the new patch. Can you upload it, so that it gets more testing? Thanks.
<pitti> tkamppeter: sure; thanks!
<real_ate> hi all! I was hoping someone here could give me a bit of advice when it comes to shipping packages around into remote repositories
<real_ate> our company is using ubuntu as a base for our next web application and we're building packages for the update/distribution/installation
<real_ate> and we are using an automated build machine to build the packages... all this works... the problem is when we are trying to "ship" the packages
<real_ate> our "repository" is located the VPS that is hosting our website
<real_ate> but that machine is CentOS
<real_ate> and is not likely to change. (bummer)
<real_ate> and we can't make use of reprepro on that server so we are kinda stuck on how to get the packages up to the server and still maintain different "releases" on the server
<real_ate> we have been building the repo every time from scratch on our build machine and then using scp to *overwrite* the repository. This works ok but because we are not using reprepro to get the packages in there and to maintain the lists and stuff it doen't clean up any unused packages
<real_ate> and we are starting to get package sprawl, taking up too much disk space.
<real_ate> Can anyone suggest a better way?  thanks in advance :D
<geser> real_ate: can't you use reprepro on the build machine and rsync the "result" to your VPS?
<real_ate> geser: no because we are dynamically provisioning the build machine on Amazon
<seb128> if somebody wants to look at the cairo ftfbs that would be nice, I've no clue about it
<seb128> https://launchpadlibrarian.net/73205652/buildlog_ubuntu-oneiric-i386.cairo_1.10.2-6ubuntu1_FAILEDTOBUILD.txt.gz
<real_ate> geser: and for that to work it would have to be : Build Packages -> Copy old repo to the EC2 instance -> use reprepro -> copy back
<real_ate> and we would be paying for transfer on both ends ;)
<geser> real_ate: and the reason for not being able to use reprepro on the VPS are missing "debian" tools?
<real_ate> geser: yes
<real_ate> geser: we have found that there is debmirror in CentOS, but that has just the same problem
<geser> real_ate: can't you create a small debian (or Ubuntu) chroot on your VPS to run reprepro?
<seb128> hum, got sidetracked
<seb128> so cairo fails on
<seb128> "ccQQ5PqR.ltrans1.o:(.text+0x724): undefined reference to `pow'
<seb128> collect2: ld returned 1 exit status"
<seb128> but it has a -lm
<seb128> it builds on a natty builder or in oneiric with gcc-4.5, not with gcc-4.6
<real_ate> geser: eh...
<real_ate> *thinks about this one*
<seb128> changing the -lm order or adding some -L... to the libm.so directory doesn't make it build, not sure what's wrong
<seb128> so if somebody has a clue of what is wrong I'm not saying no to know why ;-)
<real_ate> geser: so that would mean that we would be runing the ubuntu binaries/libs under the centos 5.6 kernal right?
<geser> yes
<mjr> are there instructions for making alternate install disks (or more spesifically just the PXE kernel/initrd pair would suffice) for 10.04 LTS, or prebuilt ones with backported kernels from later releases?
<real_ate> geser: ... its an interesting suggestion i have to hand it to you! :D real out of the box thinking
<real_ate> geser: but we probably won't gain very much on space improvements
<slangasek> seb128: I believe I have a bug report open against gcc-4.6 already for that
<real_ate> we would have to dedicate a chunk of the disk to the ubuntu chroot, which we can't afford on this machine.
<slangasek> seb128: bug #778292
<ubottu> Launchpad bug 778292 in gcc-4.6 (Ubuntu) "undefined reference to `pow' when building with -flto" [Medium,Confirmed] https://launchpad.net/bugs/778292
<seb128> slangasek, oh, thanks!
<seb128> should -flto be turned off or something?
<slangasek> seb128: best to ask doko; I only triaged the bug, I don't know what it means :-)
<seb128> doko_, hey, what do you recommend for that gcc bug breaking cairo? should we wait a gcc fix or workaround it and how?
<geser> real_ate: hmm, can you host your reprepro on one of your workstations and rsync the repository to your VPS?
<geser> real_ate: how much disk space do you have available on the VPS?
<real_ate> geser: we can't host the reprepro on any of our workstations. This is exactly the problem we are trying to get aroud
<real_ate> :D
<real_ate> geser: we have quite a large amount of stuff that needs to be built and uploaded
<real_ate> and have a terrible (i mean really terrible) upload speed from the office
<real_ate> we're talking about 1GB for a full upload of packages, which was taking about 6-12 Hours a pop, depending on the reliability of our connection
<real_ate> geser: and its not a matter of not having enough disk space on the VPS, the problem is that we always deal with large files like this and if the repo can't be cleaned things will get out of control very quickly
<doko_> seb128: either disable lto, or don't use --as-needed
<seb128> doko_, ok, I will turn off --as-needed for now I think, it's the easier to do, thanks
<cjwatson> directhex: I've added cli-common to the cli-mono set
<cjwatson> broder: topic space is very limited, perhaps not the ideal place to express friendliness
<directhex> cjwatson, ta
<directhex> cjwatson, need to isolate the armel build failure now. sigh
<didrocks> Amaranth: your 07_* patch didn't apply in c-p-m (no -p1 for your patch)
<tkamppeter> "sudo lsusb -vvv" hangs on a built-in USB hub on my laptop, can one fix this without rebooting?
<micahg> hi doko, I was wondering if you ever saw my question about a libreadline transition
<cjwatson> doko_: I'd appreciate a quick look at http://bugs.debian.org/630006, if you have a moment; it's blocking d-i builds
<ubottu> Debian bug 630006 in libffi "libffi: please add a udeb" [Wishlist,Open]
<pitti> tseliot: want me to look at bug 756163 ?
<ubottu> Launchpad bug 756163 in xorg-options-editor-gtk (Ubuntu Oneiric) "xorg-options-editor-gtk version 0.2ubuntu2 failed to build on i386" [High,Triaged] https://launchpad.net/bugs/756163
<tseliot> pitti: yes, please, I really don't know what's going on there
<pitti> ok
<chrisccoulson> directhex, how familiar are you with the moonlight plugin? and do you know what the mozilla-specific parts of that plugin are used for? (ie, everything in plugin/firefox in the source tree)
<directhex> chrisccoulson, i believe that stuff is largely obsolete nowadays, given the steady abandonment of the xpcom apis used by that code, in modern firefox
<directhex> chrisccoulson, best bet is to speak to shana on gimpnet for a sane explanation
<chrisccoulson> directhex, ok, thanks. i'm not sure if you saw https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033229.html , but i'm trying to figure out whether we can keep moonlight but just drop the mozilla-specific parts
<chrisccoulson> as it's not really much code at all
<chrisccoulson> i'll find shana and ask though. thanks!
<directhex> chrisccoulson, i didn't see that. i'd definitely talk to andreia though. let me know what she says
<chrisccoulson> thanks
<directhex> chrisccoulson, relatedly, i know she did some work on gluezilla which is also affected by xulrunner removal. worth bringing that up too.
<chrisccoulson> directhex, ok, will do. thanks
<directhex> i think gluezilla was updated to work okay with ff4, but segfaults on garbage disposal due to some threading problem. personally i wanted a move to use webkit-sharp for the system.windows.forms.webbrowser control emulation (which is what gluezilla does) since it tends to break less frequently for embedding circumstances than moz
<chrisccoulson> directhex, yeah. and mozilla embedding is going to be break quite frequently in the future. do you know if gluezilla uses gtkmozembed?
<tkamppeter> pitti, thanks for the upload.
<directhex> chrisccoulson, historically? probably. hence the desire to dump it for webkit-sharp.
<chrisccoulson> directhex, ah, ok. the reason i asked is that gtkmozembed has actually been removed entirely now - https://groups.google.com/forum/#!topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
<tkamppeter> I have a problem with USB, seems that my Lenovo laptop is not compatible with the Oneiric kernel. Even directly after reboot "sudo lsusb -vvv" hangs and on the system console I get several message "usb 7-1: device descriptor read/64, error -110" and after some minutes I get "hup 7-0:1.0: unable to enumerate USB device on port 1". Anyone has an idea what happens?
<real_ate> geser: turns out we can use reprepro over a mounted ssh, and moves happen server side! rockin! ;)
<real_ate> we're currently investigating/testing
<didrocks> dholbach: hey, seems I'm marked as "community" in most of merges and not in bold in http://reports.qa.ubuntu.com/reports/sponsoring/. However, I'm in the sponsor team, any idea what's missing?
<dholbach> didrocks, the sponsoring overview does not know anything about "Community" AFAIK
<dholbach> didrocks, ah
<didrocks> hum, not sure why I'm not an Ubuntu Developer (neither in italic) :p
<dholbach> it's "gedit (upstream)"
<dholbach> at least that's the sponsoring overview understands it
<didrocks> dholbach: oh ok :)
<didrocks> weird: Merge into:lp:~ubuntu-desktop/gedit/ubuntu
<dholbach> yes, that's an upstream branch
<dholbach> it's not a source package branch
<didrocks> not really :)
<dholbach> well, in launchpad terms it is
<didrocks> it's our desktop team branch :)
<didrocks> right
<didrocks> I'll add that as well in my report
<dholbach> it's not ~<person>/ubuntu/<release>/<pkg>/<title>
<seb128> the sponsoring queue only really understand udd merge requests
<dholbach> I would prefer not to have to teach the sponsoring overview how the desktop team handles things in a special way
<seb128> it doesn't even list other ones if you don't subscribe the sponsors
<seb128> dholbach, that's fine, our version page lists our desktop merge requests ;-)
<dholbach> great, thanks :)
<seb128> it's better than your sponsoring page :p
 * seb128 hugs dholbach
 * dholbach hugs seb128 back
<doko_> cjwatson: ok, looking at it today
<mjr> was there instructions somewhere on building a 10.04 alternate installer kernel/pxe-initrd pair with a newer kernel (or prebuilt install images with later backported kernels)?
<cjwatson> doko_: thanks
<cjwatson> mjr: is this an Ubuntu kernel from -proposed or -updates or something, or a custom one?
<mjr> an lts-backport kernel would be fine
<mjr> just need a bit of extra hardware support at install-time
<mjr> (extra as in supported in newer kernels out of the box)
<cjwatson> mjr: basically you need to get the debian-installer source package, change build/config/<architecture>.cfg to have the kernel version + ABI number you want to use, and debuild -b
<mjr> okay, sounds like a proper starting point, thanks
<cjwatson> if it's not in one of the sources d-i looks in by default, you might need to run 'util/gen-sources.list.udeb' in build/, then copy sources.list.udeb to sources.list.udeb.local and edit it
<cjwatson> is somebody other than me processing syncs?  I was in the middle of some
<cjwatson> didrocks: ^-
<didrocks> cjwatson: yeah, I was as well, sorry
<cjwatson> I flushed the ones I was doing individually, so you can go ahead now
<didrocks> cjwatson: ok thanks, finishing those I was heading to :)
<cjwatson> (I did agda-bin and nautilus-dropbox)
<didrocks> oh ok, removing agda-bin then
<didrocks> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<TLE> pitti: Hallo. Thanks for the email. I was wondering.
<siretart> chrisccoulson: yes?
<TLE> pitti: Is there any special kind of testing that should be done, now that there has been this infrastructure change for firefox?
 * dholbach hugs didrocks
<TLE> testing l10n-wise I mean
 * didrocks hugs dholbach back :)
<dholbach> :)
<pitti> TLE: just that translations still work; the new langpacks should pull in firefox-locale-*
<TLE> pitti: ok thanks
<doko_> cjwatson: libffi udeb in NEW
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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: kenvandine
 * dholbach hugs kenvandine
 * kenvandine hugs dholbach
<dholbach> :)
<cjwatson> doko_: thanks, will look
<cjwatson> doko_: I'm afraid that's wrong - Pre-Depends: multiarch-support is unsatisfiable in d-i
<cjwatson> doko_: installing to /usr/lib/$(DEB_HOST_MULTIARCH)/ is fine, but you need to drop the Pre-Depends
<cjwatson> (for the udeb)
<brendand> mvo - i just put this branch for review https://code.launchpad.net/~brendan-donegan/update-manager/bug791548_networkmanager0.9/+merge/64185
<ubottu> Ubuntu bug 64185 in moc (Ubuntu) "application hangs with an error" [Undecided,Fix released]
<brendand> ignore ubottu
<mvo> brendand: its reviewed and merged already, many thanks!
<brendand> mvo - perhaps you're thinking of a different one?
<brendand> mvo - this one is for the NM problem in O
<seb128> hum, kvm sit on the plymouth logo eating cpu when trying to boot isos in oneiric and usb-creator keeps spinning on disk erase and doesn't offer the create a disk on start
<seb128> that's going to be interesting to try an iso :p
<brendand> mvo - thanks. lp just took a bit :)
<mvo> brendand: great!
<doko_> cjwatson: hmm, lintian complains about it
<doko_> and this is a check, which is enforced by ftp-master
<dholbach> if somebody has a bit of time to review pad.lv/mps/ubuntu-sponsoring that'd be nice :)
<cjwatson> doko_: totally a lintian bug.  it's overridable, so override it for now and I'll get it fixed in lintian
<doko_> ok
<doko_> cjwatson: hmm, how is the override file called for an udeb?
<cjwatson> oh, that's annoying
<cjwatson> same as usual, but it's cruft that shouldn't be in a udeb :-/
<cjwatson> /usr/share/lintian/overrides/libffi6-udeb
<cjwatson> doko_: alternatively, just don't make the udeb multiarch
<cjwatson> there's no particular need for it
<cjwatson> that might be better for the momeent
<cjwatson> *moment
<cjwatson> doko_: fixed in lintian.git, anyway, but it'll take a while for that to be deployed on ftp-master so I think just not making the udeb multiarch is the most straightforward answer
<DktrKranz> cjwatson: if that turns to be a blocker, we could see to speed things up. It requires a lintian upload, though.
<abhinav-> dholbach: your blog is timing out while loading. cannot open the links posted on fb and twitter
<cjwatson> DktrKranz: shouldn't be a blocker, I hope; no udeb ever actually needs to be multiarch
<cjwatson> (at least at the moment)
<cjwatson> (but thanks)
<dholbach> abhinav-, it works for me
<dholbach> abhinav-, nigelb had a similar problem yesterday - can you traceroute it and see how far you get?
<abhinav-> dholbach: sure
<abhinav-> dholbach: it times out after 10 hops. would you like to see the output of traceroute ?
<dholbach> abhinav-, what's the last hop?
<abhinav-> dholbach: so-1-3-0.0.pjr01.ldn001.flagtel.com (85.95.25.114)  340.677 ms  341.246 ms  342.055 ms
<dholbach> for nigelb yesterday it was "so-1-3-0.0.pjr01.ldn001.flagtel.com (85.95.25.114)"
<dholbach> aha, interesting - seems you have a similar route and something goes wrong there :-/
<nigelb> abhinav-: airtel?
<abhinav-> yes
<nigelb> dholbach: Our ISPs are the same.
<dholbach> I'm sorry, there's not a lot I can do about it
<stgraber> well, I guess that blog post will appear on Planet Ubuntu if it's not already there
<stgraber> so you can probably read from there instead
<stgraber> though you'll be missing the comments
<nigelb> stgraber: I just socks proxy through my VPS :-)
<stgraber> that works too :)
 * stgraber wonders how many people know of ssh's "-D" parameter ;)
 * nigelb uses is every so often :D
<doko_> cjwatson: re-uploaded, now afk
<cjwatson> doko_: thanks
<cjohnston> !regression-alert  bug 795520  <-- I was told to do that ;-)
<ubottu> Error: Launchpad bug 795520 could not be found
<ubottu> cjohnston: I am only a bot, please don't think I'm intelligent :)
<jdstrand> cjohnston: fyi, that bug is private, which is why ubottu can't deal
<jdstrand> cjohnston: afaict, there is nothing in the bug that should be kept private...
<cjohnston> jdstrand: I wasn't sure, so when I started attaching things, I marked it private
<cjohnston> its not private anymore
<jdstrand> cjohnston: feel free to use regression-alert again
<cjohnston> !regression-alert  bug 795520
<ubottu> Launchpad bug 795520 in bcmwl (Ubuntu) "Error processing bcmwl-kernel-source" [Undecided,New] https://launchpad.net/bugs/795520
<ubottu> cjohnston: I am only a bot, please don't think I'm intelligent :)
<cjohnston> now what did i do wrong
<cjohnston> no pioe?
<cjohnston> pipe
<cjwatson> cjohnston: there's no such version of bcmwl published in any Ubuntu release
<cjwatson> 5.100.82.38+bdcom-0ubuntu3, but not 5.100.82.38+bdcom-0ubuntu3.1
<cjwatson> ah, it was already deleted from natty-proposed
<charlie-tca> maybe without the bug? or since it is a bot command, with the | between the command and bug
<cjwatson> "bad SRU"
<jdstrand> charlie-tca, cjohnston: I think !regression-alert should be on it's own. then describe it after.
 * jdstrand updates wiki
<cjohnston> I was just given the first part in a PM, so I was trying to make it work.. I guess I got attention anyway.. heh
<seb128> cjwatson, pitti, hum, the new lsb version built with python3 witll had an almost 6mb to the cd tomorrow :-(
<pitti> ah, it's hte first package to pull in python 3?
<cjohnston> cjwatson: is there anything I can do to fix my system with it being deleted?
<seb128> pitti, yes
<cjwatson> cjohnston: 'sudo apt-get install bcmwl-kernel-source/natty' ought to do it
<cjwatson> seb128: hmm, I wonder if this is doko committing to python3 for oneiric.  Let's not worry too much about it immediately
<seb128> cjwatson, ok
<cjohnston> no errors...
<cjohnston> That worked.. I have wireless again.. Thanks cjwatson
<jelmer> cjwatson, hi, still there?
<cjwatson> jelmer: hi
<jelmer> cjwatson: I proposed an SRU for bzr, with ~ubuntu-sru subscribed to the merge proposal
<jelmer> cjwatson: Is that sufficient, or should I find a related but and subscribe ~ubuntu-sru to that as well?
<cjwatson> I have no idea how the tracker will cope with that
<cjwatson> you want pitti for that
<jelmer> cjwatson: ah, thanks
<jelmer> pitti: hi
<seb128> jelmer, they work the reverse way
<seb128> jelmer, ubuntu-sru doesn't do sponsoring, they review things in the queue and go back to the bug to read it and accept the upload
<seb128> jelmer, so if you need your work to be uploaded you should subscribe ubuntu-sponsors
<seb128> jelmer, ideally you would need a bug with the merge proposal also, the sru tracking list bugs and you need a place where testers can comment on whether the update works or not
<cjwatson> apw: so, notwithstanding your comments in -meeting, I think at least fixing eglibc would be a pretty good plan.  how about http://paste.ubuntu.com/623518/?  tested out of context ...
<cjwatson> (in particular I think we should resolve eglibc problems before accepting the kernel through NEW)
<apw> cjwatson, absolutly on the NEW thing
<apw> cjwatson, i am not sure that $(( works with 0NN as i think that switches it into octal
<jelmer> seb128: bzr has a microrelease exception; there will usually be zero or more bug reports related
<apw> i t
<cjwatson> apw: I'm not relying on that
<apw> s/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/;
<cjwatson> the effect of the added first sed statement is to transform 3.0-0.1 into 3.0.0-0.1
<apw> does that not take 2.6.39 -> 2.6.039 ?
<cjwatson> no, because [^.0-9] doesn't match in the relevant place there
<seb128> jelmer, ok, well pitti left for the w.e already he will be back on tuesday, but from what I can say usually they need at least one bug to list on the tracker, so if your update close no launchpad bug you should open one about the new version
<apw> ahh misses the ^, re's suck for reading
<cjwatson> I did test that bit :)
<seb128> jelmer, so you have at least one bug reference in the changelog for the tracker
<cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "2.6.39-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
<cjwatson> 20639
<cjwatson> <cjwatson@sarantium ~>$ echo $(($(echo "3.0-1" | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/; s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\?.*/\1 \* 10000 + \2 \* 100 + \3/')))
<cjwatson> 30000
<apw> cjwatson, that look sane then yes, though there is another place it errors due to format
<cjwatson> ok, where's that?
<cjwatson> oh yes, I see
<apw> cjwatson, about line 286 of the preinst
<seb128> cjwatson, "  * desktop-o-gtk3-gnome3: ubiquity mostly converted to PyGI, though blocked on porting a custom widget (timezone map)"
<jelmer> seb128: I have that, but do I subscribe ubuntu-sru to all the related bugs, to just the MP?
<cjwatson> I wonder where the built-in assumptions in glibc it's referring to are
<seb128> ev, cjwatson: dunno who is working on that but did you talk to mterry about it? he wanted to do a C library for that widget and has been discussing that upstream with the GNOME guys
<cjwatson> seb128: I was just reporting what ev said
<seb128> ev, cjwatson: if that's done the lib could probably just build a gir to use
<apw> cjwatson, i was trying to find them, but ... not found as yet
<cjwatson> apw: sysdeps/unix/sysv/linux/dl-sysdep.c
<seb128> cjwatson, ok, I will check with ev, thanks
<ev> ah yes, I hadn't considered that
<ev> stupidly
<ev> will go down that road instead
<ev> thanks seb128
<mterry> ev, cjwatson, seb128: upstream is going to do some sort of map library, but it likely won't have our geonames timezone completion logic.  So we can patch it in when they have something
<cjwatson> so that looks to me as though glibc will treat 3.0 as 3.0.0
<apw> cjwatson, that would be appropriate
<apw> cjwatson, yeah concur that it does assume all and any part is 8 bits max, but the build only checks that 3rd
<apw> cjwatson, so are you going to fix those two in the package ?  so i don't need to look any more ?
<cjwatson> right.  I think it's reasonable enough for it to only check the last one, which is the only one people typically fiddle with
<cjwatson> yeah, I think I can deal if that's OK with you, but review is good
<apw> cjwatson, yep let me have the changes and i can review np
<cjwatson> can't easily test it here but don't want to have to fix it twice
<apw> i can cirtainly test it if i can figure out how to un-half install the broken version on my machine here
<cjwatson> er, you might need to fiddle the new preinst into place in your .deb using ar and tar
<apw> i upgraded with a 3,0-0.1 kernel installed on my oeniric and its half installed and refusing due to that change
<apw> cjwatson, ouch ... ok
<cjwatson> I can provide instructions once I'm finished
<apw> where is the .deb its using in archive ? ... ok will await those :)
<cjwatson> http://paste.ubuntu.com/623531/
<cjwatson> make a temporary directory, cd to it, 'cp /var/cache/apt/archives/libc6_* .'
<debfx> how do we deal with ppa packages that cause issues likes file overwrite conflicts? e.g. bug #748715
<ubottu> Launchpad bug 748715 in keepassx (Ubuntu) "package keepassx not installed failed to install/upgrade: Versuch, Â»/usr/share/keepassx/icons/keepassx.pngÂ« zu Ã¼berschreiben, welches auch in Paket faenza-dark-extras 0.9 ist" [Undecided,Invalid] https://launchpad.net/bugs/748715
<james_w> charlie-tca, hi, I hear that you get blank pages on status.ubuntu.com. Is that correct?
<ogra_> james_w, do you own that ?
<cjwatson> ar x libc6_*; gunzip control.tar.gz; tar xf control.tar; apply patch to preinst; tar rf control.tar ./preinst; ar r libc6_* control.tar.gz
<james_w> ogra_, I'm involved
<cjwatson> then dpkg --unpack libc6_*; dpkg --configure -a
<cjwatson> I think that should work
<cjwatson> WARNING NOT GENERALLY SANE
<ogra_> james_w, do you know if there is a particular reason the arm team isnt on there ?
<james_w> ogra_, nope
<james_w> ogra_, in the teams list?
<ogra_> yeah, how do i get ubuntu-armel added ?
<james_w> ogra_, ask cjohnston for now
<apw> cjwatson, ok on it
<ogra_> k
<cjwatson> apw: (this results in a control.tar.gz with two preinst files, but dpkg uses the second which is what we need here)
<apw> cjwatson, well its progressing
<apw> here goes nothing
<apw> cjwatson, ok those fixes look fine to me, test fine in isolation and worked to allow me to finish the package installation
<cjwatson> excellent, forwarding to Debian and will upload
<apw> cjwatson, i will go look at PS which is producing much vile whining
<cjwatson> PS?
<cjwatson> ah, procps
<apw> yeah, ps and top are both whining same message
<apw> any idea where the lightdm/gdm choice is made ?
<apw> ahh found it /etc/X11/default-display-manager
<apw> anyone got working networking on oneiric ?
<tumbleweed> yes
<apw> cjwatson, procps seems to be easy to fix, simple one line change.  I've pushed a bzr branch with it on, but as its a 3,.0 (quilt) we're back to the question as to whether one should have the .pc etc in there; perhaps you could review: lp:~apw/procps/kernel-version-fix
<cjwatson> apw: there's no question, you match whatever the branch currently does
<apw> cjwatson, well its the importer, so it does what it wants
<cjwatson> yes.  so match it.
<cjwatson> I think your commit matches its behaviour except that it doesn't normally add the .timestamp file, IIRC
<cjwatson> (for better or worse)
<cjwatson> and actually it doesn't add .pc/.quilt_patches or .pc/.quilt_series either
<apw> ahh ok, i'll delete those
<cjwatson> I think that's a discrepancy between what happens when you apply patches with quilt and what happens when dpkg-source unpacks the package on a system without quilt installed
<montaj> hey guys
<montaj> i have a question regarding bug #791467
<ubottu> Launchpad bug 791467 in ubuntustudio-meta (Ubuntu Oneiric) "gcdmaster not built on Oneiric: breaks ubuntustudio installation with additional software" [High,Triaged] https://launchpad.net/bugs/791467
<montaj> it appears that gcdmaster is needed to build cdrdao
<cjwatson> apw: otherwise looks fine
<montaj> what is the way to procees in this case, attach a patch of the control file to the bug or build a new package and ask somebody to sponsor it?
<montaj> I would very grateful if somebody could point me on how to proceed to fix the regression
<apw> cjwatson, ok updated with those removed, perhaps you could do the honours if it looks ok
<ScottK> montaj: If you know how to fix it, attach a patch and then subscribe the ubuntu-sponsors team to the bug and someone will review it.
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #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:
<cjwatson> apw: merged, thanks, uploading (eglibc also uploaded a while back)
<cjwatson> binaries will take a bit
<cjwatson> apw: heh, you forgot to add debian/patches/ubuntu-handle-short-kernel-versions.patch - I'll fix it up
<cjwatson> and the change to debian/patches/series too
<cjwatson> apw: fixed up and uploaded now
<apw> cjwatson, i am hopless sometimes, thanks
<chrisccoulson> directhex, i just tried building moonlight here, and it fails right at the end. not sure if you can provide any insight for this error:
<chrisccoulson> dh_clideps: Could not resolve moduleref: moon for: mscorlib.dll!
<chrisccoulson> or anyone else for that matter :)
<directhex> chrisccoulson: hm. probably a use-case we didn't consider for cli-common 0.8
<ohsix> hm is something else being done with firefox this (natty) cycle? ff5 beta just showed up
<micahg> ohsix: that's in -proposed and natty will follow the new mozilla release cycle immediately
<ohsix> ok cool
<cjwatson> ohsix: http://askubuntu.com/questions/48035/why-is-natty-proposed-suggesting-an-upgrade-to-a-beta-version-of-firefox
<ohsix> will it leave proposed after the release or is it just going to soak a bit like most things in -proposed
<micahg> ohsix: yes, it will actually be replaced with the release build next week sometime and migrate to -updates/-security on release day (hopefully)
<ohsix> ok cool ya that's what the post said; thanks guys
#ubuntu-devel 2011-06-11
<ohsix> down the broken extension rabbithole again; i hope they eventually sort that stuff out :[
<micahg> ohsix: any non-binary extensions should be updating from addons.mozilla.org (not all extensions in the archive have been updated yet, that will be staged next week in -proposed), but there shouldn't be many at all left in the archive
<ohsix> yar i meant a.m.o; extension authors haven't really even caught up with 4 yet; and if they have they didn't also add 5 like they were supposed to at the time, so there will be more adjustment
<ohsix> i just hope eventually it all catches up; not having tabkit and bartab is giving me fits
<micahg> ohsix: the compatibility rate is ~76% ATM
<ohsix> ya i read it's pretty good
<ohsix> but it's a big bummer when it's not the ones you use :D
<micahg> extension authors will probably move to the technologies which are less likely to break over time
<ohsix> nod
<ohsix> i've read about all the developer changes since 3.5 and why they were made and whatnot
<ohsix> wouldn't need tabkit if there was ui for the new delayed browser tab loading :]
<ohsix> you can pretty much see the situation in the last update dates https://addons.mozilla.org/en-us/firefox/addon/tab-kit/ https://addons.mozilla.org/en-US/firefox/addon/bartab/
<[lan3y]> Hi i have a question about a feature on the brainstorm do i ask here?
<bdrung_> mdeslaur: should i take a look at the vlc security fix later this day or are someone else working on it?
<cjwatson> directhex: mono 2.10.1-4 binaries accepted through NEW; I punted all the new binaries into main for now, but expect to drop some of them back out to universe depending on what component-mismatches tells me
<cjwatson> doko__: libffi6-udeb accepted now, thanks
<mdeslaur> bdrung_: I haven't had time to look at it yet, sorry. I think this is the fix: http://repo.or.cz/w/vlc.git/commitdiff/cd929923ff49175a501bb3e9553a683bc42ff61c
<asac> anyone else has problems with ubuntu SSO? seems it doesnt like my pass anymore :/
<doko__> slangasek: the debian cmake sync did break the build on armel
<directhex> cjwatson: thanks. i'm still chasing the armel build failure, personally. i'll alert people to start transition management
<ImDexter> hi
<ImDexter> it seems there is not any option to allow users to estabkish as a default the opening of plugged in external HD in a new tab, instead of a new window, as is the current action permorfed. are you developing a tool or option that would enable users to, everytim an user opens his home folder to see several predetermined tabs?
<ImDexter> and, of course, to choose to open ny plugged in external HD in a new tab, instead of window
<ImDexter> any
<bdrung_> mdeslaur: bug #795410
<ubottu> Launchpad bug 795410 in vlc (Ubuntu Natty) "VLC XSPF integer overflow" [Undecided,New] https://launchpad.net/bugs/795410
<broder> i'm trying to get the most recent version of a package in a given suite of the debian archive. is rmadison the best tool i get?
<cjwatson> that or the source package publishing history tables in LP
<cjwatson> oh, you said Debian
<cjwatson> well, you could still use the LP import I suppose :-)  I can't remember if the dak db is exported to non-DDs
<broder> it's seemed in the past that the LP's import of history tends to have gaps
<broder> although maybe information about tip is consistently current?
<cjwatson> it's usually not too far off
<cjwatson> you could also just grab and parse Packages/Sources files
<cjwatson> that's essentially what rmadison is doing, remotely
<broder> actually, i guess i could just use rmadison for everything
<cjwatson> broder: it's not ideal for machine-parsing, but not dreadful
<broder> cjwatson: i just realized that u-d-t actually has a helper function that does the parsing for me :)
<cjwatson> hah
<broder> bdrung: ping? right now backportpackage lets you specify --version without --source, in which case it searches the entire publishing history for all releases to find a given version of the package
<broder> this is annoying to implement consistently with the debian support, and i think it's something of a mis-feature to grab a non-current version anyway
<broder> are you strongly opposed to punting that, and making --version purely for verifying that the package you get is a specific version?
<bdrung_> broder: no, because if you upload a new version you can backport it with specifying the version, but not specifying the version would backport the previous one
<bdrung_> if you fix this lag, you can make the change :)
<broder> i don't understand...
<bdrung_> broder: there is a delay between the upload and the recognition of pull-lp-source
<bdrung_> s/upload/an upload to the main archive/
<broder> what about between the upload and rmadison? i'm using rmadison for looking up all version numbers now
<broder> (i don't know what sorts of delays it exhibits)
<bdrung_> broder: it takes some time for the information to hit rmadison
<bdrung_> it takes minutes or hours
<broder> :(
 * broder sighs
<bdrung_> it takes too much time if you want to do a backport directly atfer an upload
<broder> ok, i'll go work something out
<bdrung_> that's when i need to specify the version
<broder> why not just backport from the dsc file you have locally in that case?
<bdrung_> would be possible in most cases. sometimes someone else is doing a team upload.
<broder> and if you specified the version, you'd be able to pull it out of the lp publishing history?
<bdrung_> specifying the version works, but i don't know if the lp publishing history is used for it.
 * broder goes to see which particular rabbit hole in the current code you go down when you specify a version
<bdrung_> broder: in doubt ask tumbleweed
<broder> ah, i see. it doesn't hit the lp publishing history at all in that case, and just assumes that https://launchpad.net/ubuntu/+archive/primary/+files/package_version.dsc exists
<broder> i can make that work
<broder> yeah, got it...i think. merge proposal will be inbound as soon as i update the manpage
<bdrung_> broder: i plan to split distro_info into a separate library
<bdrung_> broder: your merge proposal makes that harder
<broder> the stuff i added could conceivably live in ubuntutools.misc instead
<broder> let me push an update with it moved there
<bdrung_> broder: you may want to add a "exists" method to the distro_info class
<broder> instead of doing "in .all"?
<bdrung_> yes
<bdrung_> the question is what to do with "unstable"?
<broder> hmm...do we not handle that correctly?
<bdrung_> .all will give you only the codename
<broder> but distro_info knows about unstable?
<bdrung_> it maps unstable to sid
<broder> hmm...it looks like i might need to check both .all and .codename()
<bdrung_> i think a valid(codename) check would be the solution.
<broder> ok, that seems reasonable
<broder> would you be willing to make that change, though? i've got some other backlogged stuff i want to get to
<bdrung_> yes, i can do that
<bdrung_> but first i go to bed :)
<broder> heh
<slangasek> doko: hmm.  I don't know why (cmake on armel); the same thing succeeded in Debian
#ubuntu-devel 2011-06-12
<broder> slangasek: speaking of cmake, do you know what happened with bug #773062? it wasn't closed with an lp closer or anything
<ubottu> Launchpad bug 773062 in cmake (Ubuntu) "cmake does not work well with ccache" [Undecided,Fix released] https://launchpad.net/bugs/773062
<broder> i'm trying to figure out how to handle bug #784409, which sounds like it should be an sru and not a backport, but i can't tell
<ubottu> Launchpad bug 784409 in natty-backports "cmake natty-backport needed to fix ccache compatibility" [Undecided,New] https://launchpad.net/bugs/784409
<slangasek> broder: Debian maintainer redid the patch to not use dpkg-architecture
<broder> ok, that doesn't really sound sru-worthy :(
<broder> i guess i'll have to look for another way
<slangasek> well, you should probably wait until the patch is *reliable*... there are still smatterings of build failures turning up
<slangasek> but I don't see why replacing the old patch with the new one would be inappropriate in SRU
<broder> slangasek: i guess. unfortunately i also don't see how the new patch would keep the ccache failure from happening
<mdeslaur> bdrung_: cool, thanks, I'll get that built and released ASAP
<hyperair> mdeslaur: ping.
<mdeslaur> hyperair: yes?
<hyperair> mdeslaur: regarding https://bugs.launchpad.net/ubuntu/+source/evince/+bug/651931, should i include the -13 changelog entry, or should i just merge everything into a -12.2 changelog entry?
<ubottu> Ubuntu bug 651931 in evince (Ubuntu Natty) "evince crashed with SIGSEGV in clear_job_selection()" [Undecided,Triaged]
<hyperair> er sorry, i mean -0ubuntu13, and -0ubuntu12.2
<mdeslaur> hyperair: no, just include the patch in the appropriate patch system, and add a changelog entry for -12.2
<hyperair> it's already part of the existing patch system afaik
<hyperair> so i'll just merge the -0ubuntu13 entry into -0ubuntu12.2?
<mdeslaur> yes, change 0ubuntu12 into 0ubuntu12.2
<mdeslaur> and add the bug number (LP: xyz)
<hyperair> 13 to 12.2 you mean
<mdeslaur> oh, yes, sorry :)
<mdeslaur> typo
<hyperair> okay
<mdeslaur> hyperair: thanks. re-subcribe "ubuntu-security-sponsors" after you've attached the updated debdiff, and whoever's on patch piloting duty tomorrow will sponsor it
<hyperair> security?
<hyperair> but that's not a security bug though?
<mdeslaur> argh, sorry...It's early here..:)
<hyperair> heh :)
<mdeslaur> hyperair: so, please subscribe "ubuntu-sponsors" is what I meant :)
<hyperair> mdeslaur: alright, thanks =)
<mdeslaur> hyperair: thanks!
<bdrung> mdeslaur: thanks.
<bdrung> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/796189
<ubottu> Ubuntu bug 796189 in vlc (Ubuntu) "package vlc-data 1.0.6-1ubuntu1.7 failed to install/upgrade: corrupted filesystem tarfile - corrupted package archive" [Undecided,New]
<mdeslaur> bdrung: thanks for the debdiffs!
<slangasek> cjwatson_: finally getting around to attempting a fix-up of the debconf branch history here, and I can't find any upstream VCSes that can be merged into lp:~ubuntu-core-dev/debconf/ubuntu (no common ancestor)... any suggestions on how to proceed?
<micahg> slangasek: are you still around?  can you pocket copy something for me?
<slangasek> micahg: sure
<micahg> slangasek: can you pocket copy chromium-browser, lucid only, from lucid-proposed to lucid-security
<slangasek> micahg: to lucid-updates as well?
<micahg> slangasek: sure
<slangasek> micahg: done
 * micahg thinks there's a cron job that does that, but getting it in -updates soon lightens the load on security.u.c
<micahg> slangasek: thanks!
<micahg> slangasek: will you be around later this evening, I hope to have maverick and natty done in a few hours
<slangasek> micahg: I'm going to be out for the next few hours, possibly back after
<micahg> slangasek: ok, no worries, I'm sure I can find someone later
#ubuntu-devel 2012-06-04
<bernie> hey, i think i've hit a bug in software-center with installing commercial software after it has been paid for.
<bernie> where could i report it?
<micahg> bernie: ubuntu-bug software-center
<bernie> micahg: i ended up filing this https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1008289
<ubottu> Launchpad bug 1008289 in software-center (Ubuntu) ""Failed to download repository information" for purchased application" [Undecided,New]
<bernie> micahg: and i also sent a note to pay-support@canonical.com
<micahg> bernie: ok, someone should be looking at it tomorrow then
<bernie> micahg: it's just $9.99, but i'm very curious to see what the customer experience is like.
<micahg> bernie: indeed, I think it's something that should work :) (I just don't work on that), sounds like you already took the proper steps
<bernie> micahg: hey, i found another workflow that triggers bugs in the software center: 1) purchase the humble indie bundle 2) you get an email with a key and a link 3) click on "Download for Ubuntu" to get to software-center.ubuntu.com with the key in the url 4) click on one of the apt:// links and Software Center opens 5) Software Center offers you to buy the game once again :-(
<bernie> micahg: i'll report another bug
<micahg> bernie: ok, thanks
<bernie> micahg: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1008309
<ubottu> Launchpad bug 1008309 in software-center (Ubuntu) "Can't download purchased Humble Indie Bundle with Ubuntu Software Center" [Undecided,New]
<pitti> Good morning
<ajmitch> morning pitti
<ion> Hmm, Psychonauts doesnât seem to be available yet.
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/libdvdnav/+bug/934471 be nominated for oneiric and precise?
<ubottu> Launchpad bug 934471 in libdvdnav (Ubuntu) "vlc crashed with SIGSEGV in dvdnav_describe_title_chapters()" [Medium,Fix released]
<dholbach> good morning
<larsduesing> good morning
<tjaalton> dholbach: hey, could you test the kernel from precise-proposed to see if it fixes bug 906269 for you?
<ubottu> Launchpad bug 906269 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,Incomplete] https://launchpad.net/bugs/906269
<tjaalton> it did work for dovercash
<dholbach> tjaalton, the lockup only happened very rarely, so it'll be a bit hard to test it, but AFAIK I didn't have any video lockups for a longer while now
<dholbach> sorry for the very unspecific feedback
<tjaalton> dholbach: ok, I'll mark it as a dupe of the other one then. there are a couple of other commits I'll propose to be added to v3.2-stable if the testing goes well..
<dholbach> ok cool
<dholbach> thanks a bunch
<tjaalton> np, thanks
<ahasenack> good morning! Can a sponsor please take a look at #1004678? Thanks
<tumbleweed> ahasenack: that bug has no ubuntu tasks. It's also worth mentioning that you need a core-dev when asking for sponsorship :)
<ahasenack> tumbleweed: right, let me add one, and change ours to fix committed
<ahasenack> tumbleweed: do I need to subscribe some other team too?
<tumbleweed> no, it should appear on the sponsorship queue
<ahasenack> tumbleweed: ok
<kendfinger> Hello
<kendfinger> Any events today?
<dobey> what sort of events?
<dobey> an ELE is unlikely today, at least
<seb128> could somebody reject https://code.launchpad.net/~penguin359/ubuntu/precise/network-manager/fix-for-1005091-precise/+merge/107545
<seb128> (it's a request against the wrong branch, the contributor also submitter other ones)
<stgraber> seb128: done
<seb128> thank
<seb128> thanks
<dobey> can someone accept the ubuntuone-client and ubuntuone-control-panel packages into precise-proposed?
<kendfinger> Like meetings.
<kendfinger> Is there a buildbot or something for the Quantal Cd images?
<seb128> stgraber, could you reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/activemq/sid-merge/+merge/106539 as well?
<kendfinger> Is it true apport is being replaced?
<stgraber> seb128: done
<seb128> thanks
<stokachu> Daviey: ping
<stokachu> or xnox ping :)
<xnox> ?
<xnox> =)
<xnox> stokachu: what's up?
<stokachu> xnox: hey, im trying to patch autofs5 in lucid, but dpatch-edit-patch new old fails with no rule to make unpatch
<stokachu> xnox: is there something special i need to be doing for the patch system in autofs
<xnox> stokachu: not in the new autofs. Let me grab lucid's autofs and see how that acient package was done =)
<stokachu> xnox: ok thanks, i believe its pretty ancient
<xnox> stokachu: are you trying to add a patch, or edit / modify an existing one?
<xnox> I would do
<stokachu> yea a new patch
<xnox> ./debian/rules clean
<xnox> add a patch file to ./debian/patches/
<xnox> add the name of the patch to ./debian/patches/00list
<xnox> make sure the patch starts with #! /bin/sh /usr/share/dpatch/dpatch-run
<xnox> and then do a test build
<stokachu> ah ok -- a more manual approach
 * micahg suggest edit-patch
<xnox> micahg: if you know how to operate it, go ahead =)
 * xnox only used dpatch the way I described about 3 times in my lifetime =)
<stokachu> micahg: i tried dpatch-edit-patch but that failed with no makefile rule to unpatch
<stokachu> is edit-patch better to work with?
<xnox> stokachu: the packaging is very old-school, so it does not have upatch targets.
<micahg> edit-patch is an abstraction on dpatch-edit-patch, not sure of all the pitfalls
<stokachu> ah ok
 * micahg defers to xnox
<stokachu> they both break in the same way
<stokachu> manual way it is then
<stokachu> thanks xnox
<xnox> stokachu: I usually do $ bzr commit & bzr dep3-patch -c-1 > debian/patches/newpatch.patch
<dholbach> bryceh, tjaalton: did we have any xvfb segfaults any time recently? it might be a problem with bug 1008537 - not confirmed yet
<ubottu> Launchpad bug 1008537 in sphinx (Ubuntu) "[FTBFS] Segmentation fault during tests" [Undecided,New] https://launchpad.net/bugs/1008537
<stokachu> xnox: ok cool ill test that
<pitti> bryceh, tjaalton: FWIW, I get crashes in xvfb in apport's test suite, too
<xnox> stokachu: and then edit the series/00list & top line for the dpatch stuff.
<stokachu> ok
<tjaalton> dholbach, pitti: there have been no xserver updates to quantal other than one bugfix early May..
<tjaalton> so it could be something else triggering it
<dholbach> tjaalton, for a test, I could upload the sphinx merge to a precise ppa and see what happens
<tjaalton> dholbach: yeah
<dholbach> do we have some docs on how the buildd chroots are configured?
<dholbach> it'd be good to be able to reproduce this somewhere outside LP
<xnox> dholbach: the buildd tarball is accesible to download & then you can run it with sbuild
<xnox> should be very close to LP setup
<xnox> chroot tarball
<dholbach> xnox, I think I'd better leave that to somebody who knows how to debug xvfb better :)
<dholbach> but it's good to know
<xnox> =))))
<xnox> true
<tjaalton> dholbach: from the buildlog you can see that it actually managed to pass the first iteration of the tests, but the second one failed
<dholbach> https://launchpad.net/~dholbach/+archive/ppa/+build/3547669 will start in 6h
<tjaalton> the precise build log shows it'll run the tests three times
<tjaalton> ah, the old version was built on oneiric
<tjaalton> hum no
<tjaalton> that was the kernel version :)
<tjaalton> the one on precise-proposed built fine
<bdmurray> mvo: bug 902603 is still receiving duplicates because people are release upgrading without the new version of dpkg.  can something be done about that?
<ubottu> Launchpad bug 902603 in taglib (Ubuntu Precise) "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix released] https://launchpad.net/bugs/902603
<kendfinger> Today's quantal build is very unstable! I can't connect to wifi. it freezes alot, and it just is flat out slow.
<ogra_> kendfinger, we didnt even release alpha1 yet, what would you expect :)
<kendfinger> I know. Just wanted to help by submiting bugs. :)
<ogra_> yeah, thats a good plan :)
<mvo> bdmurray: one not very user friendly way would be to put it into DistUpgrade.cfg as "BadVersions=dpkg_1.16.0.3ubuntu5"
<mvo> bdmurray: this would mean people without it get a error, better of course is to simply install the update first
<bdmurray> mvo: and is there a way to accomplish that?
<seb128> could somebody reject https://code.launchpad.net/~nathwill/ubuntu/precise/gnome-control-center/fix-lp-978118/+merge/103784
<seb128> (wrong serie, need tweaking, should go to Debian)
<stgraber> seb128: done
<seb128> stgraber, thanks
<mvo> bdmurray: I think this needs a bit of code to be written, let me double check
<mvo> bdmurray: not, not trivially, we would have to write some code
<bdmurray> mvo: okay, its only received 7 duplicates in the past 2 weeks so may not be worth it
<seb128> could somebody set https://code.launchpad.net/~sacridex/ubuntu/precise/unity-greeter/purple-background-on-startup-fix/+merge/102679 to needs fixing or rejected?
<stgraber> seb128: done
<seb128> thanks
<jtaylor> what should be done with fftw3? it now depends on mpi in debian, I guess thats not suitable for main?
<slangasek> seb128: hi, where did the number 800MB come from on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-one-iso-for-q ?  My understanding was that it was supposed to be 750 MB for this cycle
<slangasek> then at UDS I suggested we bump it to 750MiB instead because we were already at 736MB
<slangasek> now we're bumping again :)
<Riddell> it seems pretty arbitrary
<Riddell> Kubuntu is hopeing for 1GB which is arbitrary but nicer and round :)
<seb128> slangasek, hey, I'm a bit out of the loop on the topic, not sure if there was an UDS discussion if there was I missed it, please fix whatever I had wrong in the blueprint, jasoncwarner_ suggested I open it so we have an "official" place to track the change
<seb128> slangasek, I got the 800mb number from https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001303.html
<slangasek> Riddell, seb128: two cycles ago we had a discussion about dropping the CDs in favor of USB-sized images which would grow slowly each cycle, and it's my understanding the agreement was 750
<slangasek> for this cycle
<slangasek> pitti: hi, where'd the number 800MB come from in https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001303.html ?  I know we had a hallway discussion in Oakland about doing 750MiB instead of 750MB, but I didn't remember anyone saying 800 :)
<seb128> slangasek, well, as said I missed the discussion if there was one at UDS so you might be right
<seb128> slangasek, btw since you are around, do you see any issue multiarching libbonoboui without doing libbonobo? from reading bug #977947 the libbonobo one is non trivial
<ubottu> Launchpad bug 977947 in libbonobo (Ubuntu Quantal) "Please transition libbonobo to multi-arch" [Medium,Triaged] https://launchpad.net/bugs/977947
<slangasek> seb128: they can be multiarched in any order, but we do need to get the whole stack to get any real benefit to users
<seb128> slangasek, I'm trying to look at bug #1003964 for precise SRU
<ubottu> Launchpad bug 1003964 in libgnomecanvas (Ubuntu Precise) "libglade2-0 can't find libbonobo.so or libcanvas.so (those need to be multiarched)" [Low,Confirmed] https://launchpad.net/bugs/1003964
<seb128> slangasek, libglade got multiarched and load its .so from /usr/lib/i386-linux-gnu/libglade and those libs install a .so in /usr/lib/libglade
<slangasek> seb128: I don't think I've looked at libbonoboui in depth... I certainly wouldn't *SRU* libbonoboui before libbonobo is sorted
<seb128> slangasek, the other option would be to add a fallback loader to libglade
<seb128> that might be a safer solution for precise
<roaksoax> 4
<slangasek> erm... yes, there should be loader fallbacks for such things
<seb128> slangasek, ok, I will look into that, thanks ;-)
<slangasek> thank you :)
<slangasek> stokachu: ^^ were you still looking at finishing up some of these multiarch SRUs for precise?
 * micahg thinks he took a precise multiarch SRU and forgot to upload it
<infinity> micahg: It's the thought that counts, right?
<micahg> heh, I just need to go dig it up and upload later in the week
<infinity> jdstrand: Care to have a quick look at bug 993658?
<ubottu> Launchpad bug 993658 in latex2html (Ubuntu) "[MIR] latex2html" [Undecided,New] https://launchpad.net/bugs/993658
<jdstrand> infinity: ok. it'll be a bit, but I'll get to it this afternoon
<infinity> jdstrand: Sure.  Seems mostly like a no-brainer to me, at least.
<seb128> slangasek, could you have a look to bug #987502? the patch submitter asked for your input
<ubottu> Launchpad bug 987502 in libxml2 (Ubuntu) "libxml2-dev: /usr/bin/xml2-config isn't identical across all arch" [Medium,Triaged] https://launchpad.net/bugs/987502
<slangasek> seb128: it's in my queue, yes
<seb128> slangasek, thanks
<slangasek> seb128: btw, should libbonoboui2-0 have a versioned dep on the version of libglade2-0 that looks in the multiarch directory?  (currently it doesn't)
<seb128> slangasek, it should maybe breaks libglade << multiarch version rather?
<slangasek> seb128: well, it already depends on libglade
<slangasek> so it should depend on the right version of libglade :)
<dobey> is there an sbuild equivalent of pbuilder-dist?
<seb128> ok, I will fix that with the next upload, thanks for pointing it
<slangasek> seb128: thank you!
<jbicha> dobey: I don't think so, I just follow http://wiki.debian.org/sbuild to set it up
<dobey> jbicha: ok, i'll check it out. thanks
<dobey> do packages in quantal show up on errors.ubuntu.com now?
<geser> dobey: take a look at "mk-sbuild - creates chroots via schroot and sbuild" (ubuntu-dev-tools), perhaps the script does what you are looking for
<agrimm> hi, all.  I'm trying to figuring out how dpkg orders things during package upgrades.  I have a package A that depends on an exact version of package B, and I would expect that on upgrade, package B's "preinst" script for the new version would run before the new version of package A is unpacked... but this isn't what seems to happen.  is the ordering not that strict?  am I forced to use pre-depends if I need this behavior?
<tumbleweed> correct, that's what Pre-Depends is for
<tumbleweed> we try and avoid Pre-Depends whenever possible
<tumbleweed> err sorry misread
<tumbleweed> if A depends on B, A will be configured before B's postinst. If Pre-Depends, A will be configured before B's preinst runs
<tumbleweed> http://www.debian.org/doc/debian-policy/ch-relationships.html
<slangasek> agrimm: if you want unpack ordering, you have to use pre-depends, yes
<agrimm> slangasek, tumbleweed : thanks, I'll see how that goes
<slangasek> in general we discourage people from doing this however ;)
<slangasek> as it makes the dependency calculations more brittle overall
<cr3> for a python3 project in quantal, should the debian/control file specify something like: Depends: ${python3:Depends}? does that even exist?
<agrimm> slangasek, I did see that in the guidelines... I really just need preinst script to run before unpacks ... it's strange to me that they don't
<slangasek> the preinst script runs before the unpack of the package shipping it
<agrimm> slangasek, understood
<agrimm> but if that package _depends_ on another
<slangasek> but there's no guarantee of unpack ordering *except* via pre-depends, because it is actually useful for the package manager to unpack things out of order in some cases
<slangasek> usually when trying to resolve conflicts/breaks elsewhere in the dependency graph
<slangasek> cr3: yes
<slangasek> cr3: https://wiki.ubuntu.com/Python/3 should have the deets
<agrimm> slangasek, I understand.  I'm just spoiled by package managers which have solved this problem
<slangasek> cr3: actually, not that page, but on the linked http://wiki.debian.org/Python/LibraryStyleGuide
<infinity> agrimm: As a result of the unpack ordering oddities, it's often recommended that preinsts not use anything outside of Essential.
<slangasek> dpkg/apt have solved this too, just not with the same semantics as others ;)
<infinity> agrimm: (Which is generally good advice anyway, preinsts shouldn't be where one does complex things)
<slangasek> pre-depends are the correct way to enforce what you want
<slangasek> we just recognize (probably better than others) that there's a cost to using pre-depends
<cr3> slangasek: thanks, exactly what I needed!
<agrimm> infinity, if this were for the install case, I'd agree with oyu, but my use case is strictly for upgrades, where I already know what's on the system
<slangasek> one might note that Debian/Ubuntu actually support full release upgrades, whereas distros using certain other package managers do not
<agrimm> slangasek, FWIW, I'm talking about conary as the "other package manager", not RPM
<agrimm> :)
<slangasek> ah ;)
#ubuntu-devel 2012-06-05
<kees> infinity: any chance you can upload those eglibc patches? I'd like to commit changes to the qa regression test suite
<infinity> kees: Oh, you actually wanted people to run that code?
<infinity> kees: (I just got home from HK, and today's been a PlusOneMaint firefighting day, I'll toss you feedback and/or an upload by tomorrow)
<TheMuso> D/c
<bkerensa> cyphermox_: anything I can do to get this bug looked at and perhaps fixed? https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/972063
<ubottu> Launchpad bug 972063 in bluez (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Confirmed]
<nemo> Sooo, just FYI, libcairo2-1.11 completely broke libreoffice on my SO's computer. menus unreadable
<nemo> forcing install of 1.10 seems to have fixed things
<nemo> lost some of my cairo dev libs in the process, ah well
<nemo> I tried forcing 1.12 - that did not seem to help though. as screwed up as ever. perhaps due to some related deps, dunno.
<nemo> anyway. 1.10, all better.
<bernie> micahg: is there a specific channel where i could find compiz developers to help diagnose a bug interactively?
<bernie> oh, i found #compiz
<bernie> and #ubuntu-unity
<kees> infinity: sweet, thanks! let me know if I can help further. :)
<pitti> Good morning
<pitti> slangasek: hm, perhaps I misremembered then; although 750 MiB and 800 MB isn't too far apart anyway
<pitti> slangasek: 750 MiB seems fine, too
<vibhav> micahg: Confragtulations!
<vibhav> Congratulations*
<micahg> vibhav: what did I do?
<infinity> micahg: You know, but whatever it was, you obviously did it well.
<infinity> s/You know/Who knows/
<infinity> Brain:finger disconnect.
<vibhav> micahg: You are in the Membership Board, right?
<micahg> vibhav: ah, yes, thanks
<infinity> Hasn't that been true for a while?
<micahg> infinity: non-devs this time :)
<vibhav> I only came to know about it today
<infinity> Oh.  Too many boards.
<infinity> So confusing.
<micahg> well, the RMBs were collapsed into a single team now
<TheMuso> /c/c
<slangasek> pitti: yeah... see ubuntu-release@ for my follow-up question :)
<slangasek> one way or the other we should lock this down so nusakan stops telling us our images are oversized ;)
<pitti> slangasek: right, already replied there
<slangasek> ok cool :)
 * pitti votes for 700 Ububytes and Kububytes, units which will grow by 50 MB every year
<pitti> which are shamefully missing from http://xkcd.com/394/
<slangasek> heh
 * infinity nearly has a beverage->monitor incident over "kububytes".
<ScottK> xnox: pyopencl both needs a rebuild for the boost transition and a merge from Debian.  I'm technically TIL on the merge due to a previous rebuild, but don't anticipate getting to it, so if you could do it or find someone, that'd be great.
<dholbach> good morning
<seb128> RAOF, slangasek, SpamapS, bdmurray: is there anything blocking the unity SRU to move to -updates?
<seb128> the bugs are all verified and it's in proposed for 11 days
<seb128> the bamf one should be verified as well, the one non-green bug can't be opened, launchpad timeout on it
<RAOF> seb128: Bug #772063 seems to show a regression during testing? Specifically, https://bugs.launchpad.net/unity/+bug/772063/comments/29
<ubottu> Launchpad bug 772063 in unity-2d "App icon on the Unity Launcher lost track of running instance" [Low,Confirmed]
<ogra_> "resolvconf: Error: /etc/resolv.conf isn't a symlink, not doing anything."
 * ogra_ wonders why thats an error ... should be a warning 
<ogra_> (or even "info")
<morphis> ogra_: heyho, do you mind if I ask you something in private?
<ogra_> well, is it something the community shouldnt see ?
<ogra_> :)
<seb128> RAOF, hum, I doubt that's a regression, that's the only user who mentioned something like that and there was no change around the super handling code nor the dash
<seb128> RAOF, seems rather a local random issue for that user
<seb128> RAOF, he also didn't reply to my comment asking to open a new bug
<RAOF> Ok. I'll give that a shove.
<RAOF> Ah, right.  And didrocks is currently fighting -0ubuntu2 to get it to build.
<seb128> RAOF, correct
<seb128> RAOF, thanks!
<seb128> ;-)
<seb128> could somebody set https://code.launchpad.net/~gunnarhj/ubuntu/precise/ubuntu-docs/missing-links/+merge/103121 to merged?
<seb128> (it was targetting the wrong vcs, the fixes got merged into the correct one)
<matanya> why do I get : bzr dh-make hello-2.7 hello-2.7.tar.gz  bzr: ERROR: command 'dh-make' requires argument TARBALL
<ahasenack> hello, good morning/afternoon/evening!
<ahasenack> could someone from the sponsors team take a look at my upload please? #1004678
<ahasenack> thanks!
<geser> ahasenack: the Standards-Version field is pure documentatory and doesn't get use anywhere. So you can update it (after checking the changes between the policy versions and if they apply to your package) to a current version (instead of adding a useless lintian-override)
<ahasenack> geser: isn't the right thing to do to keep it at the lower version I need? Lucid, in this case?
<geser> no need to
<ahasenack> geser: the same debian source package builds on lucid all the way up to quantal
<ahasenack> geser: adjusting dependencies at build time when needed
<geser> the Standard-Versions is used at build (or anywhere, perhaps only for statistics)
<geser> you could take a package from quantal with current Standard-Versions and backport it to lucid if you wanted (and only care about build-dependencies and build tools like dh_python)
<ahasenack> geser: where do I find the differences in the standards, and what they mean?
<Adri2000> ahasenack: /usr/share/doc/debian-policy/upgrading-checklist*, debian-policy package
<ahasenack> geser: so your review point is to bump that and get rid of the override, right?
<ahasenack> Adri2000: thanks
<geser> yes
<ahasenack> geser: anything else or still looking?
<ahasenack> geser: that's a lot of versions to check, do you have a suggestion? That document is long and is full of details
<geser> ahasenack: it's nothing urgent, so you can leave it for now at that versions and review it for the next upload. Most of the changes of that new policy versions probably don't affect your package at all
<ahasenack> geser: ok, I'll file a bug for it
<geser> ahasenack: another small upgrade for the furture: as lucid has already debhelper7 you could upgrade debian/compat (and the build-dependency on debhelper) to 7 if you want
<geser> otherwise the changes to debian/* look ok
<ahasenack> geser: yeah, and I would love to have a simpler rules file too, but I inherited that package as is and am proceeding carefully with the debian/* changes
<ahasenack> I personally prefer to use override targets in the rules file when I have an exception
<ahasenack> geser: not too long ago that package had to build on dapper, I guess that was the main reason
<ahasenack> geser: ok, that's done in our trunk branch (debhelper 7)
<ahasenack> so next upload will have it
<ScottK> geser: Since compat 5 is not deprecated, there's really no reason not to leave it.
<ahasenack> right, but we don't have reason to keep 5 anymore since we don't build this for old releases anymore
<geser> ScottK: true, but is there a reason to not slowly upgrade the package to current "versions" (if possible)?
<ScottK> As long as you don't need features from newer debhelper, it seems like not a very productive use of time.
<ScottK> There's no reason not to, but there's no particular benefit either.
<ahasenack> I plan to move this rules file to more dh 7 features
<xnox> ScottK: I will get to it =) I'm doing it in alphabetical order, NMUs/uploading patches etc =)
<ScottK> xnox: OK.  I'll leave it to you.
<ScottK> ahasenack: In that case, have at it.
<xnox> stop of Debian Imports stalls it a bit, due to alpha 1
<ahasenack> geser: so, what happens now?
<ahasenack> geser: are you a sponsor, or did you just take a look?
<geser> ahasenack: I just took a look, can't sponsor it as I'm not a core-dev (can't upload to main)
<ahasenack> geser: ok, thanks even so
<cr3> hi folks, I use mk-build-dep to generate a package for the build dependencies when working on the source of a project. might there be a way to also generate a package for the run dependencies, not just for the build but to actually run the project?
<ScottK> geser: You should fix that.
<tseliot> pitti: any ideas about this? http://paste.ubuntu.com/1025080/
<pitti> tseliot: are you running this straigth out of trunk?
<pitti> tseliot: without building the pacakge first?
<pitti> tseliot: my bet is that "./setup.py egg_info" will fix it
<tseliot> pitti: yep. I'm doing PYTHONPATH=.. ./run from master
<pitti> tseliot: I guess run should check if the egg is present and point that out
<tseliot> pitti: yes, that wouldn't be such a bad idea
<tseliot> pitti: all of the tests passed. I had to test my changes to the xkit code. I'd like to fix the other packages before uploading my new xkit
<tseliot> pitti: shall I push my changes without uploading?
<tseliot> (leaving it UNRELEASED)
<pitti> tseliot: sure, as we are currently frozen
<sconklin> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: sconklin
<tseliot> pitti: ok then
<rdz> hi all. there is a package that a team of which i am a member of host in debian, that is currently broken in ubuntu 12.04. what's the best way to get fix pushed to ubuntu? i'm not familiar with the ubuntu processes, but i am a ubuntu user myself
<rdz> the package in question is pd-readanysf
<rdz> there is wrong linking order in the Makefile which unfortunately leads  to totally broken binary in ubuntu 12.04
<rdz> (unfortunately it works in debian unstable), otherwise we would have captured the error earlier
<geser> rdz: see https://wiki.ubuntu.com/StableReleaseUpdates
<rdz> geser, thanks
<rdz> "Check that the bug is fixed in the current development release" <- this would be ubuntu 12.10, right?
<rdz> geser, so if I apply to the changes to debian, they would automatically "drop" to the current development release and then the process could be proceeded to include the fix in ubuntu 12.04?
<jwendell> hi, folks. why does the precise kernel have the 3.2.0 numbering instead of follow upstream 3.2.x schema?
<Adri2000> rdz: yes, fixed in the development release currently means fixed in quantal, and if a working package is in debian it should get synced automatically (though I'm not sure if we are auto-syncing from unstable or testing now). that is a prerequisite for uploading a fix in ubuntu 12.04
<Adri2000> jwendell: maybe ask in #ubuntu-kernel
<jwendell> Adri2000, thanks
<bdmurray> dobey: bug 981255 is missing some SRU information
<ubottu> Launchpad bug 981255 in Ubuntu One Client stable-2-0 "string leak in syncdaemon_daemon_is_folder_enabled()" [Medium,Triaged] https://launchpad.net/bugs/981255
<bdmurray> dobey: otherwise the other bugs look good
<dobey> bdmurray: added, though it makes no sense for that bug really. :)
<bdmurray> dobey: a couple of the ubuntuone-control-panel bugs don't have fix released quantal tasksâ¦ did they just not get updated?
<dobey> bdmurray: oh?
<bdmurray> dobey: bug 966283
<ubottu> Launchpad bug 966283 in ubuntuone-control-panel (Ubuntu) "Widget highlight on Windows obstructed by buttons" [Undecided,New] https://launchpad.net/bugs/966283
<bdmurray> and bug 865688
<ubottu> Launchpad bug 865688 in ubuntuone-control-panel (Ubuntu Precise) "Minimized window not restored (but yes if closed)" [Undecided,New] https://launchpad.net/bugs/865688
<dobey> bdmurray: looks like maybe the ubuntu task on those was added after the upload to quantal, so they didn't get automatically marked
<dobey> bdmurray: fixed it now anyway so they are fix released in q
<bdmurray> dobey: okay thanks.  by the way could you look at my new lptools merge proposal?
<dobey> bdmurray: as soon as i can.
<Bluefoxicy> where do core dumps go
<Bluefoxicy> Segmentation fault (core dumped)
<nemo> depends on whether you have core dumps enabled
<Bluefoxicy> oh
<nemo> ulimit
<Bluefoxicy> because VLC crashes constantly on trying to play dvd
<nemo> Bluefoxicy: although if you can reproduce it. just use gdb
<nemo> much easier
<Bluefoxicy> bluefox@icebox:~$ ulimit
<Bluefoxicy> unlimited
<nemo> man ulimit
<nemo> gdb vlc
<Bluefoxicy> nemo what do I do with gdb
<nemo> run
<nemo> I'm surprised that wasn't trapped though, and submitted using ubuntu's error reporting dÃ¦mon
<nemo> well. dÃ¦mon or widget or whatever it is :)
<Bluefoxicy> Program received signal SIGSEGV, Segmentation fault.
<Bluefoxicy> [Switching to Thread 0x7ffff1efe700 (LWP 21354)]
<Bluefoxicy> 0x00007fffedbbc76c in dvdnav_describe_title_chapters ()
<Bluefoxicy>    from /usr/lib/libdvdnav.so.4
<Bluefoxicy> well then :)
<nemo> Bluefoxicy: bt for backtrace - but you'll get more useful backtrace by installing -dbg versions of the libraries
<Bluefoxicy> it's a bug in libdvdnav4 :)
<nemo> Bluefoxicy: then, file a bug w/ the appropriate project
<nemo> Bluefoxicy: I suspect if you are using a very old ubuntu version, they'll want you to test w/ a more recent version of their lib
<bdmurray> seb128: might you know anything about the sru for bug 1006701?
<ubottu> Launchpad bug 1006701 in oneconf (Ubuntu Precise) "oneconf-query crashed with ImportError in _get_distro(): No module named CaixaMagica, LinuxMintâ¦" [Undecided,Confirmed] https://launchpad.net/bugs/1006701
<Bluefoxicy> i'm on 12.04 amd64
<Bluefoxicy> and just updated evrytihng a few hours ago
<Bluefoxicy> nemo:  more interesting, I'm trying to watch a DVD and the default movie player (Totem) is horrible.
<Bluefoxicy> The DVD appears interlaced, as alternate scanlines flicker one pixel up and down constantly
<Bluefoxicy> VLC has a "deinterlace" feature that fixes this, while Totem just stabs you in the eyes for 2 hours D:
<Bluefoxicy> (yes it's extremely noticeable looking at the ripped copy pulled from the DVD with Thoggen)
<nemo> I've never found Totem's DVD playing adequate
<Bluefoxicy> well, most people aren't stupid enough to encode their content interlaced
<Bluefoxicy> Disney obviosuly doesn't share in this collective intelligence
<Bluefoxicy> oh
<Bluefoxicy> I thought you said 'annoying,' not 'adequate' :P
<Bluefoxicy> nemo:  http://sphotos.xx.fbcdn.net/hphotos-ash3/521345_3614750160740_372269247_n.jpg btw :3
<nemo> ah. I have that
<nemo> Bluefoxicy: if you want to play, and vlc is being annoying.
<nemo> Bluefoxicy: you might be able to navigate the chapter structure in vlc without triggering the bug. otherwise, you can always do mplayer dvd://1
<seb128> bdmurray, what about it?
<seb128> bdmurray, the launchpad page seems to have all the details I would provide, do you have a specific question?
<bdmurray> seb128: the diff contains a change I'm not clear on
<bdmurray> --- oneconf-0.2.8/oneconf/version.py    2012-04-10 13:11:34.000000000 +0000
<bdmurray> +++ oneconf-0.2.8.1/oneconf/version.py  2012-06-04 11:48:14.000000000 +0000
<bdmurray> -RELEASE='12.04'
<bdmurray> +RELEASE='12.10'
<seb128> bdmurray, hum, I'm unsure about it, can you ask on the bug for Didier?
<bdmurray> seb128: yes, thanks for looking
<seb128> yw!
<Bluefoxicy> nemo:  it doesn't even start.
<Bluefoxicy> nemo:  vlc that is
<Bluefoxicy> tbh Totem wouldn't be terribly terrible if it would de-interlace
<Bluefoxicy> sure it's not the most awesome DVD emulator ever, but it'll get you to the feature film with no real trouble.
<Bluefoxicy> but when the feature film *vibrates*?
<Bluefoxicy> nemo: mplayer interrupted with signal 11 in open_stream when trying to open dvd with menus
<Bluefoxicy> I assume that means libdvdnav4 is broken o_o  mplayer dvd://16 works but I can't seek through the video etc.  No UI
<nemo> Bluefoxicy: figured.
<nemo> Bluefoxicy: that's why I was suggesting by number as a workaround
<nemo> Bluefoxicy: you can still seek in the video using keyboard nave in mplayer
<nemo> left/right pageup/pagedown
<nemo> nav
<Bluefoxicy> oh, update manager is telling me VLC crashed
<seb128> slangasek, could you review https://code.launchpad.net/~nathwill/ubuntu/precise/pam/lp-110287/+merge/100282 if you have some free time (I see you were piloting yesterday, not sure if you saw it or not but it's in the queue for a while)
<seb128> zul, could you review https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989241? it's in the sponsoring queue for a while
<ubottu> Launchpad bug 989241 in nova (Ubuntu) "Give nova group read permissions nova files / directories" [Low,Triaged]
<zul> seb128: yep
<seb128> roaksoax, hey, you sponsored https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/959218, could you get the fix in q?
<ubottu> Launchpad bug 959218 in lvm2 (Ubuntu Quantal) "[SRU] clvm start error missing /var/run/lvm" [Undecided,Confirmed]
<seb128> zul, thanks
<stgraber> seb128, roaksoax: though after alpha1 please, we're in softfreeze and lvm2 is seeded :)
<seb128> stgraber, skaet email suggested uploads could happen as usual to proposed during the freeze, what happened to that?
<stgraber> seb128: proposed is fine indeed
<seb128> stgraber, ok, so when you mean "after alpha1 please" you mean "don't forget to use proposed"?
<roaksoax> seb128: sure
<seb128> roaksoax, thanks
<roaksoax> :)
<stgraber> seb128: right, I should have said, don't upload anything seeded to the release pocket until post-alpha1 (unless it's release critical and #ubuntu-release is aware of it)
<seb128> stgraber, there should be no need to say that, people know we are frozen and read the announce email, but thanks for watching what happens... ;-)
<stgraber> seb128: haha, good one :) you'd be surprised how many people we have to remind to subscribe and READ -announce during the DMB meetings...
<seb128> stgraber, well anyway let's not spend too much time on whether you need to remind others what they need to do or not and assume those who didn't notice it was a1 week know now ;-)
<seb128> zul, https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989242 as well ;-)
<ubottu> Launchpad bug 989242 in nova (Ubuntu) "Add adm group to /var/log/nova" [Low,Triaged]
<zul> seb128: ack
<seb128> thanks ;-)
<slangasek> seb128: well, I was scheduled to pilot yesterday but never got a chance :(  I will look at that merge, yes
<seb128> slangasek, thanks
<seb128> slangasek, yeah, lot of people seem to be scheduled and get busy with other things, I still use the opportunity that they were supposed to pilot to bounce stuff at them :p
<slangasek> heh :)
<seb128> it's only fair ;-)
<seb128> especially in a week where dholbach called for helped because we had a backlog > 100 items in the queue
<seb128> -ed
<barry> pitti: are you still around?
<ahasenack> hi, could someone review/sponsor my proposed upload to quantal? #1004678? Thanks
<kees> stgraber: I've uploaded the first pass of libseccomp to debian. it'll be in NEW soon...
<stgraber> kees: cool!
<bdmurray> hyperair: all the bugs associated with alarm-clock-applet in precise-proposed (bug 977110 for example) are missing SRU information
<ubottu> Launchpad bug 977110 in alarm-clock-applet (Ubuntu Precise) "sound_repeat option not working" [Undecided,Confirmed] https://launchpad.net/bugs/977110
<sconklin> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* Laney changed the topic of #ubuntu-devel to: Archive: soft freeze (use proposed if necessary) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> james_w: ping
<bdmurray> any ideas about what is going on in bug 1001904?
<ubottu> Launchpad bug 1001904 in sysvinit (Ubuntu) "package sysvutils (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/mesg.1.gz', which is also in package sysvinit-utils 2.88dsf-13.10ubuntu11" [Undecided,Confirmed] https://launchpad.net/bugs/1001904
<bdmurray> dpkg: error processing /var/cache/apt/archives/sysvutils_2.86.ds1-14.1ubuntu45_amd64.deb (--unpack)
<bdmurray> why would that be tried to install?
<infinity> bdmurray: On the one hand, it looks like there's a missing Replaces there, on the other hand, I have no idea why he's trying to install hardy packages on precise.
<infinity> bdmurray: Ah-ha.  His DpkgHistoryLog gives a hint.
<infinity> bdmurray: He added hardy sources to install ancient versions of java.
<infinity> bdmurray: And then his next dist-upgrade pulled in hardy Essential packages.
<infinity> bdmurray: I'm going to go out on a limb here and say that's really not a supported configuration.
<bdmurray> infinity: how do you see that he added hardy sources?
<infinity> bdmurray: I don't, per se, but the previous two commands (apt-get install sun-java5 and sun-java6) pulled in a version of sun-java5 that's only available in hardy.  Indeed, we haven't shipped it *since* hardy, which is likely why he added the sources.
#ubuntu-devel 2012-06-06
<infinity> Someone could perhaps educate him about the sun-java in partner, which is current.
<infinity> Current, as in packaged for precise. :P
<micahg> infinity: sun-java hasn't been in partner for 3 months
<infinity> micahg: Oh.
<bdmurray> hmm, the two duplicates are from different reporters
<infinity> Nevermind, then.
<infinity> bdmurray: Doing the same thing?
<micahg> infinity: FYI, https://lists.ubuntu.com/archives/ubuntu-security-announce/2012-January/001554.html
<infinity> bdmurray: Yeah, hardy on precise and hardy on oneiric.  Not sure if it was for the same REASON, but they've all done the same thing.
<bdmurray> infinity: weird
<infinity> micahg: Check, I missed that.
<infinity> bdmurray: (The apport hook could, perhaps, include "cat /etc/apt/sources.list /etc/apt/sources.list.d/*"... Not everyone's quite as bizzarely log-parsing intuitive as I am)
<skunk> i have a question about the linux kernel. When we write drivers.. do we write then to the kernel? Im confused.
<infinity> skunk: Drivers can be external to the kernel or (ideally) committed upstream and included in the kernel sources.  Either way, they're "kernel code", and loaded into the kernel's address space.
<infinity> skunk: Does that more or less answer your question?
<skunk> kinda.. is that the reason why on alot of hardware ubuntu linux works out of the box??
<skunk> hardware running ubuntu linux** i mean
<infinity> It's the reason why Linux doesn't generally need you to download third-party drivers, right.
<infinity> Except in the annoying case of binary-only 3D drivers.
<infinity> (Though, we take care of doing that for you too)
<skunk> yea lol.. makes sense.. I have a multi gesture touchpad that being run by a generic touchpad driver
<infinity> bdmurray: Unless we intentionally don't do that because we think sources.list is an information leak... (Which I guess it is, if it has http://user:pass@hostname/ style entries in it)
<skunk> i dunno how to improve it though, multitouch touchpad + ubuntu pixel perfect scrolling = mac like usability @ < $200
<infinity> skunk: Talk to cnd for all your touchpad needs.  He LOVES talking about touch.
<cnd> infinity, :)
<skunk> ok thanks,. i think he has an email.. ill check the canonical website
<skunk> oh
<cnd> skunk, please describe your issue more?
<infinity> (PS: By "mac like usability", do you mean "crashes when applying 11 fingers"?)
<skunk> hello cnd, i have a acer aspire one D255 with a multigesture touchpad. But theres a generic driver running it. So i could only scroll on the right edge
<skunk> i kin
<cnd> infinity, I'm going to let that one slide...
<infinity> skunk: Oh, edge versus two-finger scrolling is just a preference in settings.
<cnd> infinity, not always
<cnd> skunk, please pastebin the output of xinput
<infinity> cnd: Well, not if multi isn't detected at all, I suppose.  But it's also set to edge by default, which I suspect confuses some people. :P
<cnd> infinity, some touchpads actually send real scroll events when they are in "generic PS/2 mouse" mode
<cnd> which they are by default, unless a Linux driver tells them to switch into a better mode
<cnd> that's probably what is happening here
<infinity> cnd: By "real scroll events", you mean buttons 4/5?
<infinity> cnd: Or something extra special?
<skunk> i really would like utilize the touchpad's abilty at the best possible. I did check the settings lol.. but it's not just that.. it would be nice to have things like zoom, rotate, switch between workspaces.
<cnd> infinity, no, I mean the hardware device acts like a PS/2 mouse
<cnd> and sends PS/2 scroll wheel events when you touch on the right edge
<infinity> cnd: Yeah, and my PS/2 mouse used to send button events on scroll up and down. ;)
<cnd> yeah, basically like that, but I thought you were implying at the X level
<cnd> rather than at the hardware level
<skunk> cnd: thats makes sense.. it's like a mouse emulator
<infinity> Nah, I caught your meaning.
<skunk> cnd: but ur gonna have to walk me through pastebin the output of ximput
<cnd> skunk, install pastebinit
<cnd> $ sudo apt-get install pastebinit
<cnd> then install xinput
<cnd> $ sudo apt-get install xinput
<cnd> then pipe the output of xinput into pastebinit
<skunk> cnd: wait.. can this still work on ubuntu 10.04?? or should I boot to precise?
<cnd> $ xinput | pastebinit
<cnd> skunk, uhhh... 10.04 was a *long* time ago :)
<cnd> there wasn't any multitouch or gestures in 10.04
<infinity> Chase was 11 when lucid came out.
<cnd> you need to be on 12.04 :)
<skunk> cnd: sorry.. ill boot to 12.04...
<skunk> brb
<cnd> :)
<RAOF> cnd: While you're here - is the fact that Unity fails to recognise any gestures if I connect a magic touchpad after Unity loads a geis limitation or a Unity limitation?
<cnd> RAOF, it's likely a geis bug
<cnd> please file a bug and we'll take a look
<RAOF> cnd: Is there a particular package to file against for maximum apport-hookage?
<cnd> RAOF, not really, but utouch-geis is probably the real culprit
 * infinity wonders what happens if one runs sru-release while something is ACCEPTED, but not yet published.
<infinity> And as much as I'd like to test the theory, I don't feel like cleaning the mess.
<cnd> so xserver-xorg-input-evdev really is getting compiled in a way that causes it to pass a bad address to an X server function
<cnd> but only when compiled with optimizations...
<cnd> and only on x86
<RAOF> cnd: Have a fresh bug #1009270
<ubottu> Launchpad bug 1009270 in utouch-geis (Ubuntu) "Unity fails to use multitouch gestures if magic touchpad is connected after Unity has launched" [Undecided,New] https://launchpad.net/bugs/1009270
<cnd> RAOF, thanks :)
<RAOF> cnd: That's wonderfully obscure.
<cnd> I think I'm going to have to pester doko about it
<RAOF> cnd: So just a rebuild won't fix that. Huzzah!
<cnd> yeah
<cnd> I thought a rebuild would fix bug 973297
<ubottu> Launchpad bug 973297 in xserver-xorg-input-evdev (Ubuntu Precise) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Triaged] https://launchpad.net/bugs/973297
<cnd> because I had rebuilt and it went away
<cnd> but I rebuilt without optimizations
<cnd> the odd thing is that it only occurs in one area of the code
<cnd> in other areas of the code, the function is called and behaves properly
<cnd> hmm... skunk needs to come back soon
<cnd> I need to go make dinner
<infinity> Maybe rebooting set his laptop on fire..
<RAOF> Speak of the devil!
<skunk> cnd: im back with my pastebin, it turns out i do have a "ps/2 mouse"
<skunk> Ã¢Å½Â¡ Virtual core pointer                    	id=2	[master pointer  (3)] Ã¢Å½Å   Ã¢â Â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)] Ã¢Å½Å   Ã¢â Â³ PS/2 Mouse                              	id=12	[slave  pointer  (2)] Ã¢Å½Å   Ã¢â Â³ AlpsPS/2 ALPS GlidePoint                	id=13	[slave  pointer  (2)] Ã¢Å½Â£ Virtual core keyboard                   	id=3	[master keyboard (2)]     Ã¢â Â³ Virtual core X
<cnd> skunk, I was hoping you could copy and paste the link you got from pastebinit :)
<skunk> sorry again.. give me a few seconds
<cnd> np :0
<cnd> at least it wasn't an Xorg.log file
<skunk> http://paste.ubuntu.com/1026027/plain/
<cnd> ugh, why do I have to log in to see a public pastebin?
<cnd> skunk, so most likely you have a trackpad that the Linux kernel doesn't have a driver for yet
<skunk> yeah.. thats why i was wanting to make one. its very challenging tho
<cnd> :(
<cnd> you probably will have to reverse engineer it
<cnd> which requires having a kvm setup and using passthrough ps/2 techniques
<skunk> kvm??
<cnd> and *then* figuring out how to modify the existing alps linux driver for your new device
<infinity> cnd: You have to log in because he linked the /plain/ URL.
<cnd> skunk, kvm is the open source version of vmware or parallels
<cnd> infinity, what difference does that make?
<infinity> cnd: /plain/ is password-protected due to some belief that people use pastebins to distribute teh sw33t w4r3z.
<cnd> skunk, basically, I want to warn you that getting a driver for your trackpad working is a very non-trivial task
<infinity> cnd: I have no comment beyond that. :P
<cnd> ugh
<cnd> skunk, if you want to attempt it though, sforshee has already done it once for alps trackpads :)
<cnd> I don't know the kvm magic he did to get the raw packets, but he could tell you
<skunk> when you say "non-trivial" what do you mean?? it sounds like its very trivial lol
<cnd> skunk, you have to run windows in a virtual machine
<cnd> inside of a kvm instance
<cnd> then get the PS/2 packets from the virtual machine as it talks through linux to the real hardware
<cnd> I don't know if you need special kvm patches for that step
<cnd> then you need to reverse engineer the actual protocol of the trackpad
<infinity> No special patches required if you don't mind running kvm in gdb.
<infinity> (don't do this if you value your sanity)
<skunk> gdb??
<cnd> skunk, based on your questions, it sounds like you may not be ready to take on the task yet without a large amount of effort and work
<cnd> you can use this to learn about all the tools and how to develop on linux
<cnd> that would be a great teaching task
<cnd> but this isn't trivial by any stretch
<skunk> yes i know..but successfully doin it will teach alot about linux development.. embarassingly enough ive been a linux user since 06
<cnd> skunk, that's not embarassing at all :)
<cnd> everyone transitions from user to developer at some point :)
<cnd> well, I mean, every developer went through a "just a user" phase
<skunk> cnd: but you were saying that i could use what?? i mean to learn
<skunk> .. and yes i know.. it;s nice to see how much has changed with ubuntu since 6.06. and im still here :)
<cnd> skunk, you need to use many tools along the way
<cnd> kvm is a key tool here that will help with reverse engineering
<cnd> gdb is a debugger that you will likely use at some point, but probably not for the reverse engineering
<cnd> skunk, however, I have to go make dinner now :(
<skunk> ok.. is there something you could point me to? you know.. to get started?
<cnd> skunk, have you developed programs on linux before?
<cnd> using c?
<skunk> yes.. but for school
<skunk> no java
<skunk> lol i know where this is going.. but yes.. it looks like i need to know something lower lever
<skunk> level**
<RAOF> You will indeed need to learn C.
<skunk> looks like tomorrows a long trip to the library lol..
<skunk> but thanks guys. ive beenwaiting for this conversation for weeks
<cnd> skunk, yeah, the first step will be to learn how to develop a program with C
<cnd> and get used to the toolchain and tools
<cnd> gcc, gdb in particular
<RAOF> Which is ok, because it's pretty easy - almost all of your knowledge will translate across, you'll just need to learn some different syntax, pointers, and manual memory management.
<skunk> yeah.. you think i should review java first?/
<cnd> ok, I'm out, good luck skunk!
<skunk> kk thanks cnd
<skunk> RAOF: you think i should review java first?? i mean.. wouldnt it be good for things like recursion and that??
<RAOF> I don't think there's any particular reason to review java first; it's not *that* much easier.
<skunk> kk
<skunk> thanks
<YokoZar1> Are the cloud.ubuntu.com ami images "official" ?  There's a bit of a regression in them related to the grub update that just went out
<ScottK> !regression-alert
<ScottK> YokoZar1: Yes.  What's up.
<ScottK> !regression
<ScottK> !regression-alert
<ScottK> Yes, that's supposed to be the alert.
<ScottK> RAOF: I guess you're likely awake and on the SRU team ... ^^^ not sure what's up though.
<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
<ScottK> Ah.  There it goes.
<ScottK> That list should get updated.
<skaet> YokoZar1,  has someone opened a bug?
<RAOF> YokoZar1: You're talking about the https://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.1 update?
<YokoZar1> RAOF: skaet: just opened it, LP: #1009294
<YokoZar1> ScottK: ^^
<skaet> thanks YokoZar1,   RAOF,  I'll start off the incident report,  can you start figuring  out what our best path forward is?
<RAOF> skaet: Ok.
 * skaet notes that the notification list on ubottu probably needs changing.
<ScottK> It does.
<YokoZar1> It's worth noting that the /etc/default/grub appears to be modified on the cloud.ubuntu.com AMIs (which are official I guess)
<skaet> smoser, utlemming ^ if either of you are around, can you help us look into this?
<vibhav> seb128: ping
<TheMuso> vibhav: He is offline atm.
<RAOF> Ok, so it's a ucf managed conffile.
<vibhav> ah, fine
<RAOF> Which is why you don't see it in dpkg -S
<YokoZar1> Ahh, learn something new every day
<RAOF> Workaround: setting the environment variable UCF_FORCE_CONFFNEW (or UCF_FORCE_CONFFOLD) should bypass that, and silently install the new (or leave the old) file.
<RAOF> I'm not entirely sure what we should do about it at this point. It's not *really* a regression, but it is exposing an annoyance.
<micahg> why is the file showing as modified though?
<YokoZar1> micahg: probably cause it is (on the Ubuntu AMIs at least)
<YokoZar1> micahg: if I click the diff button there are actual differences
<YokoZar1> RAOF: this will happen with just about every UCF managed conffile then won't it?  (Why do we have something managing conf files other than dpkg?)
<RAOF> YokoZar1: Yes, it will.
<RAOF> We have ucf because dpkg's conffile handling doesn't extend far enough to handle things like /etc/default/grub.
<YokoZar1> RAOF: what does that env variable need to be set to?
<RAOF> Other things use it because it can eg: do a 3-way merge on package upgarde.
<YokoZar1> RAOF: ahh, reasonable (though having two separate places to configure this sort of option is a pain now)
<RAOF> Yes.
<YokoZar1> UCF_FORCE_CONFFOLD=1 sudo apt-get dist-upgrade?
<RAOF> Yeah; I've added that as an answer on the askubuntu question.
<RAOF> Now we merely need to work out what to do about this.
<RAOF> We can revert, but that'll prompt *again* for anyone who has already upgraded. And obviously re-introduces the dist-upgrade bug.
<RAOF> Incidentally, I've forgotten what set of environment variables get stripped out by sudo.
<RAOF> We can't unconditionally replace /etc/default/grub for everyone, and it's probably not a good idea to try to special-case the AMIs.
<RAOF> YokoZar1: Do you have any idea why the AMIs have a different /etc/default/grub? Do you have any idea how that's generated?
<YokoZar1> RAOF: not really, no.  My suspicion is it has something to do with booting quicker since it's always unprompted (indeed those are the two options changed)
<RAOF> In which case, I *think* that should be handleable with a 3-way merge; ucf is just prompting to make sure users get an option. I wonder what would happen if you set a noninteractive debconf?
<YokoZar1> RAOF: how do I test that?
<YokoZar1> UCF_FORCE_CONFFOLD=1 sudo apt-get dist-upgrade  didn't seem to work btw
<mwhudson> swap the sudo and the env var ?
<mwhudson> sudo strips most environment variables by default i think
<YokoZar1> bbialb
<RAOF> Setting noninteractive debconf also works.
<pitti> Good morning
<pitti> barry: hello
<RAOF> Good morning pitti!
<RAOF> I see it's time for my lunch!
<RAOF> pitti: I'd value your evaluation of the grub/AMI situation YokoZar/ScottK/skaet and I have been discussing above - bug #1009297
<ubottu> Launchpad bug 1009297 in Ubuntu "Ubuntu 12.04 Screen Problems" [Undecided,New] https://launchpad.net/bugs/1009297
<RAOF> Urgh, 7 is not 4
<RAOF> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1009294
<ubottu> Launchpad bug 1009294 in grub2 (Ubuntu) "Grub update breaks automated dist-upgrade scripts on AMI images" [Critical,New]
<RAOF> It's not strictly-speaking a regression, and it is a flaw in those scripts, but it seems sufficiently annoying to do something about. I just don't really know *what*.
<pitti> RAOF: so an SRU changed a non-dpkg config file into a conffile?
<pitti> that sounds like a serious no-no
<RAOF> No, an SRU changed a ucf-managed conffile.
<RAOF> It's not a conffile in either case.
<pitti> is that from http://launchpadlibrarian.net/105151158/grub2_1.99-21ubuntu3_1.99-21ubuntu3.1.diff.gz ?
<pitti> ah, ok
<RAOF> Yup.
<skaet> https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images <-- Incident Report Started
<pitti> so the problem is that the AMI scripts change the grub configuration locally in a way ucf doesn't know about?
<pitti> sorry, I don't know anything about how the AMI images work
<RAOF> I think that the problem is (a) the AMI scripts change the grub configuration locally, and (b) we've pushed an update that changes the grub configuration, so ucf is going to prompt.
<RAOF> I think that both of those behaviours are individually correct, but the combination is going to be frustrating.
<RAOF> At least until the AMIs get grub from precise-updates in the base images (will they? I don't know how the AMIs are spun or really anything about them).
<pitti> I don't think that (a) is correctr
<pitti> changing any automatically managed conffiles in scripts is a disaster waiting to happen
<pitti> regardless of dpkg or ucf
<pitti> but oh well, there's little we can do about it for the precise images now
<pitti> so there is no way to tell ucf "consider this the new pristine conffile"?
<pitti> i. e. something which the AMI script builders could call after modifying grub's default?
<pitti> RAOF: not knowing either well, my best advice is to revert the grub SRU and replace it with an SRU that only modifies the grub configuration if it is not locally modified
<RAOF> They could do that, but then I think this update would have silently overwritten their grub configuration.
<pitti> so that the fix for bug 978464 does not affect the AMI images at all
<ubottu> Launchpad bug 978464 in grub2 (Ubuntu Quantal) "After LTS->LTS (lucid2precise) upgrade, upon reboot drops into grub recovery shell" [Critical,Fix released] https://launchpad.net/bugs/978464
<RAOF> That would work. Let's see how hard that would be.
<RAOF> u
<RAOF> ...quite easy.
<RAOF> Ok.
<skaet> pitti,  its getting late here for me,  can I hand off the tracking on this issue to you until Daviey comes on line?   I think he'll need to weigh in.
<pitti> skaet: seems RAOF is already on a fix?
<skaet> pitti,  yeah,  but incident report started needs explicit handoff.
<RAOF> pitti: Yeah. I can upload the revert directly to precise-updates, right, and then upload a fixier fix to precise-proposed?
<pitti> RAOF: I'd start with a -proposed upload, give it a quick test (upgrade, reboot, to guard against misbuilds)
<pitti> RAOF: and then copy to -updates immediately after
<RAOF> That is indeed a better plan.
<pitti> RAOF: that'll delay things by half an hour, but that seems acceptable to me
 * ScottK thinks the explicit handoff requirement is one of the best features of the process.
<pitti> skaet: acknowledging, I'll update the report as events happen until Daviey comes online
<skaet> Thanks pitti.   Appreciate it.
 * skaet --> zzz
<RAOF> grub2 revert accepted into -proposed
<pitti> noted so in the report
<RAOF> Now to find a precise system to upgrade...
<pitti> RAOF: I can help testing on my wife's computer
 * pitti updates that to the latest packages, so that testing the two grubs in -proposed will be faster
<vibhav> Why is https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/pcb/lucid in "Development" ?
<vibhav> wait, all lucid branches are in development, why?
<maco> vibhav: two theories: 1) lucid is still supported so development is still happening to fix bugs and such 2) nobody ever gets around to changing branch status away from "development"
<pitti> RAOF: my wife's machine is fully upgraded, currently at grub ubuntu3.1; waiting for 3.2 to get published
<RAOF> Ta.
<RAOF> Bah. ubuntu-vm-builder doesn't want to cooperate, it seems.
<slangasek> RAOF: sorry, but this analysis is wrong.  The ucf prompt is about /etc/default/grub; the SRU does *not* change /etc/default/grub, it only changes /boot/grub/grub.cfg
<slangasek> I don't know why it results in a prompt when there's no change to /etc/default/grub in this SRU, but whatever it is would probably have happened on *any* update to grub
<RAOF> ...
<slangasek> which means a second SRU would also trigger the same issue...
<RAOF> Hm. So how is the /etc/default/grub prompt generated?
<slangasek> by ucf in the grub-pc postinst
<RAOF> Well, I know that. I guess what I mean is *why* is the /etc/default/grub prompt generated.
<slangasek> yeah, I'm not sure yet
<slangasek> looking
<RAOF> Oh.
<RAOF> If the AMI build process changes /etc/default/grub but doesn't update ucf's checksum of /etc/default/grub, ucf should notice that at next update, right?
<pitti> oh, so it'd happen whenever you update grub, regardless of what that update actually does?
<slangasek> so the postinst calls ucf thusly:ucf --three-way --debconf-ok --sum-file=/usr/share/grub/default/grub.md5sum ${tmp_default_grub} /etc/default/grub
<slangasek> that's *supposed* to not prompt *at all* if the 'base' and 'other' versions of the file are identical
<slangasek> so either this has to do with the --sum-file argument (which I've never seen used before)
<slangasek> or the AMI has badly mangled the ucf database
<slangasek> or it's a bug in ucf
<pitti> seems we should remove that grub from -proposed then?
<slangasek> yes please
<pitti> removing binaries from accepted queue; they never got published
<pitti> and removed source from precise-proposed
<StevenK>  /usr/share/grub/default/grub.md5sum seems to be very strange on my machine.
<pitti> I guess/hope it only really considers the possible md5sums, not the identifiers after them?
<RAOF> None of the md5sums in /usr/share/grub/default/grub.md5sum match this freshly-installed grub-pc in my precise chroot.
<pitti> 038c1c68801ef42ad81fa4d00f67fbc1  /etc/default/grub
<pitti> here
<pitti> right, not in my grub.md5sum file
<RAOF> Likewise.
 * slangasek nods
<slangasek> pitti, RAOF: I have a modified /etc/default/grub here and can't reproduce the issue.  I think something in the AMI build is tampering with /var/lib/ucf.
<RAOF> I can't seem to get an ucf upgrade prompt for /etc/default/grub at all.
<RAOF> Time for me to get some actual lunch.
<skunk> RAOF: what part of the world are u from??
<slangasek> oh; I bet you can get one by running dpkg-reconfigure grub-pc and mucking with the timeout settings
<slangasek> hmm, no, because I don't get a debconf prompt for that either ;P
<skunk> anyways.. does anyone notice how the scrolling in the ubuntu software centre is no good?
<skunk> like kipping over itself??
<skunk> skipping**
<pitti> slangasek: OOI, how would that behave differently than manually modifying the file?
<pitti> I tried that here, and reinstall grub2-common; no prompt here
<slangasek> pitti: because 'dpkg-reconfigure grub-pc' changes the *package's* version of the config file
<slangasek> i.e., the one to be proposed for merging
<pitti> urgh, it modifies the one in /usr/share/ ?
<slangasek> no, it creates a temp file
<slangasek> and merges from that
<skunk> i guess not?? should just report as bug?
<pitti> ah, "package's version" == what ucf considers "distro default"
<slangasek> skunk: sounds like it should be a bug report, yes
<slangasek> pitti: yep - which may be postinst-generated, as in this case
<slangasek> RAOF, pitti: so I've done some analysis and posted it to the bug; this is a bug in the cloud image, not in grub-pc, and any grub update would trigger it
<pitti> slangasek: thank you
<pitti> slangasek: so fixing the AMI build process is the way forward, and for this one upgraders just need to deal with the prompt or set DEBIAN_FRONTEND?
<slangasek> yep
<RAOF> slangasek: Thanks for that.
<slangasek> no prob
<slangasek> I'm off to bed now :)
<dholbach> good morning
<dholbach> Laney, done
<pitti> Daviey: good morning
<apw> pitti, do we have UDD branches for clean debian, for when they are ahead of us ?  /me thought we did
<Daviey> hola, pitti o/
<pitti> Daviey: hey
<pitti> Daviey: I kept track of https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images until now; did you see it in scrollback?
<Daviey> i have, yes.
<Daviey> So.. this is fallout from bug 759545
<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
<Daviey> Still catching up on comments for this incident
<Daviey> I hoped another avenue for resolving it would have been via bug 901600
<ubottu> Launchpad bug 901600 in grub2 (Ubuntu) "Allow /etc/default/grub overriding via /etc/grub.d/" [Medium,Triaged] https://launchpad.net/bugs/901600
<Daviey> is slangasek still around?
<micahg> he said he was going to bed ~2hrs ago
<pitti> Daviey: no, he went to sleep
<pitti> Daviey: I'm OTP right now, sorry for lagging
<Daviey> pitti: ok, thanks
<Daviey> infinity: around?
<pitti> Daviey: by now it's clear that the bug is in the AMI build scripts
<Daviey> pitti: I don't see how this is a new bug...
<pitti> it's not
<pitti> it just got exposed by that grub update
<Daviey> pitti: i mean, it's a known issue.. we've constantly been hitting this, as decalred in bug 759545.
<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
<pitti> Daviey: ah, ok; so this is a duplicate?
<pitti> Daviey: anyway, can I hand over https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images to you now?
<Daviey> pitti: I believe it is a duplicate, but still catching up.  Sure, i can take it from here.
<Daviey> Thanks for driving it so far.
<pitti> thanks
<xnox> stgraber: cjwatson: do you remember a bug in grub/grub2 about adding extra checksums for the /etc/default/grub ? because it looks like it's affecting server this time around in bug 759545
<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
 * Laney snuggles dholbach 
<apw> can someone remind me where the package importer hides its logs
<xnox> apw: somewhere in package-import.ubuntu.com?
<micahg> apw: http://package-import.ubuntu.com/status/
<apw> thanks :)
<pitti> apw: yes, we should; lp:debian/package ought to work
<apw> pitti, ahhh ... i was trying debian/unstable/xxx doh
<pitti> apw: that actually ought to work, too; but I haven't tested it
<pitti> at least lp:ubuntu/precise/foo works
<apw> pitti, hmmm, seems its /sid/ ...
<pitti> ah
<dholbach> Laney, \o/
<ion> I wonder what is the right channel for questions about the commercial PPAs?
<apw> ion, hmmm ... thats a good one ... i know there is an email address
<czajkowski> aloha
<apw> ion, czajkowski may be able to answer your question
<czajkowski> ion: hiya how an I help?
<ion> Iâm just curious about when Psychonauts from the Humble Bundle is going to become available in the PPA. :-)
<ion> The page has said âcheck back soonâ for a while now. :-P
<czajkowski> ion: let me find out
<czajkowski> ion: no definate time but it will happen as soon as they get it ready
<ion> Alright, thanks. It might be nice if the software-center.ubuntu.com page was less ambiguous about that, itâs unclear whether one should check back in an hour or in a month. :-)
<apw> maxb, i am seeing issues with automake1.11 package imports, definatly for ubuntu and i think for debian as well, i wonder if you could cast an eye and tell me if thats something we can fix or we should be pushing over it
<maxb> apw: acknowledged, I have some time later today when I can look at it
<apw> maxb, puuurfect thanks
<cjwatson> xnox: no specific bug comes to mind, but we've certainly added checksums before ...
<xnox> cjwatson: ok. i think it was  https://launchpad.net/bugs/759545
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged]
<apw> pitti, it seems cups has ftbs'd on ubuntu due to a new interface in a library (at least thats my interpretation of the log) is that something we might expect to allow, and if so is that something we carry as delta when it occurs ?
<apw> pitti, this is on arm* only
<pitti> apw: no, that shouldn't be a delta IMHO; I guess we could add it as an optional symbol into the .symbols file?
<apw> pitti, ok will test and make sure that works as expected
<apw> pitti, is this your master vcs branch: http://bzr.debian.org/pkg-cups/cups/debian-trunk/
<pitti> right
<apw> pitti, there is an incantion for packaging only branches to 'instantiate' the source into them isn't there ... can you remind me
<pitti> apw: ah, that's "bzr bd-do"
<pitti> that'll throw you into a "working tree" with the source
<apw> pitti, our naming is somewhat terse :)
<pitti> you can edit and test there
<pitti> and if you exit 0, the changes will be written back to your checkout
<pitti> exit != 0 and they will be thrown away
<pitti> apw: well, it's something we have to type over and over every day, it better be short :)
<pitti> apw: "bzr builddeb-do" if you prefer
<apw> pitti, so should i be filing a bug in LP for this FTBS to include in any fix
<pitti> apw: if you prefer a bug, sure; I'm also happy to just commit a patch if you have one, or merge a branch
<apw> pitti, if you don't need a bug i don't need one either, will prepare a branch, its good for me
<pitti> apw: we can't upload it during the freeze anyway, but then it's at least there for the next Debian/ubuntu upload
<pitti> apw: many thanks for working on this!
<apw> pitti, heh np, whats the incanation to get any package source at a specific version ...
<pitti> apw: if you checked out "trunk", something like "bzr branch -r tag:1.2.3-4 trunk cups-1.2.3-4
<pitti> apw: if you merely want to check a particular file at a particular version, you can also use bzr cat -r tag:1.2.3-4 debian/foo
<apw> pitti, isn't there a ubuntu-devel type command for it, to get the uploaded dsc etc
<apw> pitti, though thats useful to know too :)
<pitti> apw: ah, sure; I thought you meant from bzr
<cjwatson> apw: pull-lp-source
<pitti> apw: pull-lp-source
<apw> thanks :)
<xnox> Got my quad HDD usb 3.0 docking station for RAID testing. Win! Discover bug #966248. Fail!
<ubottu> Launchpad bug 966248 in linux (Ubuntu) "USB3.0 Ports Not Working" [Medium,Confirmed] https://launchpad.net/bugs/966248
<Daviey> xnox: i'm using a machine atm with 3 ports, 2 of them do not work.. but the yellow one does.. So i might have the same issue.
<matttbe> Hello
<matttbe> I have (maybe a stupid) question for chrisccoulson: why I see that Mozilla Firefox 14.0 beta 6 is currently building? I thought the 14.0 version was still in alpha, no?
<doko> Sweetshark, ping
<chrisccoulson> matttbe, surely the fact that it exists in the archive is enough to answer your question, isn't it?
<matttbe> (sorry, I guess I'm wrong because this web link exists: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/14.0b6-candidates/ but there is no other beta)
<chrisccoulson> and the release calendar is public too https://wiki.mozilla.org/RapidRelease/Calendar
<matttbe> chrisccoulson: yes, sorry, it was just strange to see a beta 6 but without any previous beta versions
<chrisccoulson> oh, that is to align the version numbers with mobile, which already had several release from the current ff14 branch
<matttbe> chrisccoulson:  ok, thank you for this explanation. I thought it was a typo even if I know it's quite imposible :)
<xnox> Daviey: I don't have a yellow one, only the blue one. I will try my housemate's yellow, when he comes back. This needs following up with kernel team =) cause I do want usb3.0 for raid testing across all four of my drives.
<gogo_> Hello, I think there is a regression in latest Unity update
<nemo> libcairo2 1.11? :)  'cause. that's why I'm hanging out here.  Ok, that's not exactly Unity.
 * xnox and Daviey are not talking about skittles
<nemo> hrm. you know... how *did* I end up w/ 1.11 - checking launchpad, precise is still on 1.10.  You know. n/m - maybe I'd just somehow installed some test version of some repo
<nemo> and thus deserved any probs I got
<nemo> righto. l8r
<apw> maxb, it looks like fonts-nanum is in the same state when you get there
<Daviey> xnox: generally, having only one working usb port on modern laptops is bad karma, right? :)
<xnox> Daviey: I have 2 working USB2.X and 1 non-working USB3.X =(((( yeap it is bad karma =)
<ogra_> does it get substracted then from your launchpad account ?
<Daviey> dputblame should be a new tool that does just that.
<ogra_> haha
<Daviey> I fear i'd end up with negative karma.. :)
<smoser> YokoZar, /etc/default/grub is modified by default in the images.
<smoser> that is by design (known) causes config file change prompt on upgrade.
<smoser> if you're aware of a way in which we can make the needed changes (http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/vmbuilder-cloudimg-fixes) I'm more than interested in knowing.
<smoser> skaet, ^
<Daviey> smoser: Are you following the incident log?
<TobsCorre> Hey Guys. After getting a lot from Ubuntu I'd like to give something back.
<TobsCorre> So I'd like to translate some programs, or some of the interface. Is there a website that manages some of the programs, so I could apply some translations?
<lynxman> tumbleweed: ping :)
<smoser> Daviey, incident log?
<smoser> i'm missing something.
<Sweetshark> doko: pong
<Daviey> smoser: https://wiki.ubuntu.com/IncidentReports/2012-06-05-grub-in-cloud-images
<pitti> smoser: slangasek pointed out in the bug how to do that
<smoser> so what am i missing.
<maxb> apw: So, the automake1.11 problem appears to be that pristine-xz is failing to identify the compression options for the .orig.tar.xz. I've sent a mail to ubuntu-distributed-devel@l.u.c to discuss upgrading pristine-xz on the importer
<smoser> is there some solution in bug 1009294? I do not see one. only "AMI image build probably needs to inject the grub settings via debconf preseeding, so that ucf as shipped in the image knows the intended answers to the debconf questions."
<ubottu> Launchpad bug 1009294 in grub2 (Ubuntu) "Grub update breaks automated dist-upgrade scripts on AMI images" [Critical,In progress] https://launchpad.net/bugs/1009294
<apw> maxb, ahh probabally the same same on fonts-nanum then, thats xz using
<smoser> i've asked more than once how i could fix this, and never been given an answer.  grub configuration has caused more than a little bit of pain for me.
<pitti> smoser: the workaround for the already existing updates seems to be to update with DEBIAN_FRONTEND=noninteractive
<pitti> but I guess the build process should be changed to use debconf instead of manually changing the file
<smoser> pitti, and how do i do that with debconf?
<smoser> note, i've asked this for 2 years
<smoser> (and also note, cloud-init does the right thing with debian_frontend=noninteractive and force-confold
<pitti> I had assumed that this works by poking the changed variables with db_set and dpkg-reconfigure grub2-common
<Daviey> pitti: I seem to remember we were going to put the updated hashsum into debconf but was advised there was a better way to do it.
<infinity> Daviey: Oh hey, if this is a bug in the AMI build scripts, that would explain why I could never make it happen manually. :/
<Daviey> infinity: Then why the heck didn't you tell us that?
<Daviey> I thought it just fell off your plate...
<infinity> It did.
<infinity> "Couldn't reproduce" didn't mean "I then gave up", I means "I ran out of time to try harder".
<Daviey> ah, ok :)
<infinity> I do find it midly amusing, though, that a config file prompt is now considered worthy of an incident report and escalation.
<infinity> It's a bug.  We have lots of bugs.
<smoser> infinity, THANK YOU!
<dobey> is there no tool to check which files from a package have been modified?
<smoser> i did find that mildly amusing also
<Daviey> infinity: I think the incident report was started because it was considered an SRU regression initially
<smoser> i look forward to the day when we have so few bugs that all are worth of incident reports.
<smoser> s/worth/worthy/
<Daviey> well, SRU regressions *should* have Incident Reports...
<geser> dobey: like debsums?
<Daviey> so yes, i look forward to that day :)
<infinity> Daviey: I don't agree with that statement either.  SRU regressions of high impact should have a stop-the-pressed effect.  Low impact ones should be fixed with... Another SRU.  Which happens all the time.
<vibhav> Could anybody see https://bugs.launchpad.net/ubuntu/+source/zerofree/+bug/1009412 ?
<ubottu> Launchpad bug 1009412 in zerofree (Ubuntu) "Please merge zerofree from debian unstable" [Undecided,New]
<geser> vibhav: the version should be 1.0.1-4ubuntu1 and you should close the merge bug in your changelog entry
<vibhav> ah
<vibhav> let me take a look
<dobey> geser: thanks. searching the interwebs wasn't so helpful :)
<geser> and it's usually preferred to have a debdiff against the Debian version you merged
<tumbleweed> lynxman: hi
<Daviey> infinity: I'm not part of the SRU team, and perhaps it's best handled by their process.  However, as a product leader.. any SRU regression i'd like bloody well documented.. and i don't think a bug is enough.
<cjwatson> Daviey: It's debatable whether this is a regression, though.
<Daviey> cjwatson: No, i'm saying that it wasn't incorrect to start an incident report when it was thought it was.
<cjwatson> Fair enough
<pitti> barry: just uploaded my first apport crash data blob with python3 apport :)
<barry> pitti: \o/
<s-fox> Hey nigelb :)
<nigelb> hey s-fox!
<pitti> barry: it says this now when you actually need the lplib functionality: http://paste.ubuntu.com/1026903/
<pitti> barry: so I'll wiggle the dependencies accordingly
<barry> pitti: i like your plan.  anything to reduce desktop dependencies is a win. :)
<s-fox> nigelb, Thanks for the channel name and contact. Looking to get this in for 12.10 - https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/602265/comments/19
<ubottu> Launchpad bug 602265 in firefox (Ubuntu) "The defaut firefox bookmarks could do with updating." [Wishlist,Triaged]
<barry> pitti: can i help in any way?
<pitti> barry: you could cross fingers that https://staging.launchpad.net/ comes back online soon :)
<pitti> barry: I just wasted an hour debugging a HTTPError which suddenly appeared after I changed stuff from string to bytes
<barry> pitti: fingers, toes *and* eyes!
<lynxman> tumbleweed: hey, I just updated the mcollective merge request, thank you so much for your review :)
<barry> ouch
<pitti> barry: it turned out that it was actually working, just staging went down underneath me :)
<barry> :-D
<pitti> I can run it against production just fine
<nigelb> s-fox: aha
<s-fox> I mean we have even supplied a file to drop in. Just need to get it replaced now. haha
<tumbleweed> lynxman: I get the feeling that you were preparing the merge in an unusual way, considering how many undocumented ubuntu changes were left
<pitti> barry: just committed to trunk, including setup.py changing the hashbangs of the installed scripts to sys.executable (i. e. python3 when you run setup.py with python3)
<pitti> barry: I'll do an upstream release now and then convert the packaging branch
<pitti> barry: but might need to wait for next week; need to start packging and then Taekwondo soon..
<pitti> barry: is the twisted build dep a problem?
<barry> pitti: not a huge problem since we have other twisted ubuntu-desktop dependencies, but reducing unneeded deps is always a win
<lynxman> tumbleweed: I'm trying to keep track of too many sheeps at the same time I'm afraid, I'm working with the debian maintainer to reduce our delta as much as possible but we still got some stuff unmerged that some other packages depend on
<barry> pitti: unless it really is a dep and i missed it
<pitti> barry: it's only a build dep, not a binary one
<pitti> just for the test suite
<tumbleweed> lynxman: you now have entries in the changelog as "remaining ubuntu changes" when they aren't, they are changes that debian made that you had reverted in your earlier proposal
<barry> pitti: how do you test w/py3 if twisted is a b-d?
<lynxman> tumbleweed: gah, need to fix that as well
<pitti> barry: I just need the twistd program
<pitti> barry: I might do away with that even, but I think I added it because the exectuable needs to exist for the _check_interpreted() logic
<tumbleweed> lynxman: I suggest comparing your branch against sid and checking that the changelog matches the diff
<barry> pitti: what's odd id that i grepped all the files and couldn't find a reference to 'twisted'
<pitti> barry: grep for "twistd" :)
<lynxman> tumbleweed: will do that, thanks :)
<barry> pitti: pesky 'e' ;)
<pitti> barry: let me try without
<s-fox> Ping micahg , nigelb said you might be someone to talk to about the default firefox bookmarks and getting them updated.
<pitti> barry: so, I do need the twistd build dep for now, but it shoudl not be too hard to remove it; but it's not that urgent, I presume
<barry> pitti: nope, not urgent.  thanks!  i'm going to respond to your email in more detail, but getting rid of lplib is *huge*
<barry> (getting rid as a dep for task:ubuntu-desktop
<vibhav> geser: You there?
<geser> vibhav: yes, but only short, have to leave in a few
<vibhav> geser: If you have any free time, could you check the merge (bug 1009412) ?
<ubottu> Launchpad bug 1009412 in zerofree (Ubuntu) "Please merge zerofree from debian unstable" [Undecided,New] https://launchpad.net/bugs/1009412
<vibhav> I uploaded a revised debdiff
<geser> will do when I'm home
<vibhav> thanks!
 * vibhav waits for a patch pilot
<basti> mvo, geser told me in #ubuntu-de that you are an developer of apt-get. i cant update the sources anymore ( http://nopaste.info/f6616a4b02.html). both apt-get and aptitude dont work anymore. is there any fix?
<smoser> @pilot-in
<udevbot> Error: "pilot-in" is not a valid command.
<smoser> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze (use proposed if necessary) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser
<mvo> geser: hi, for basti, I don't know what is going on there, it should not try to fetch the uncompressed file
<smoser> vibhav, where you looking for a pilot?
<pitti> barry: ooh, python3-pykde4? nice
 * pitti installs and tries PYTHON=python3 test/run ui_kde
<barry> pitti: yep, though i didn't do the port (cjwatson did i think)
<cjwatson> I just packaged it
<cjwatson> Upstream had already done it by the time I got there
 * pitti scratches head about
<pitti>     programName = ki18n('Apport KDE')
<pitti> TypeError: ki18n(): argument 1 has unexpected type 'str'
<cjwatson> It wants bytes
<pitti> urgh, it needs to be called with bytes
<cjwatson> cf. ubiquity r5463
<cjwatson> There's kind of some logic to it, ish
<vibhav> smoser: Yes I was
<smoser> whats up?
<vibhav> smoser: Could you take a look at https://bugs.launchpad.net/ubuntu/+source/zerofree/+bug/1009412  ?
<ubottu> Launchpad bug 1009412 in zerofree (Ubuntu) "Please merge zerofree from debian unstable" [Undecided,New]
<jamespage> vibhav, do you think you could verify bug 1000678?
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Fix committed] https://launchpad.net/bugs/1000678
<smoser> sure, vibhav i'll take a look. thank you.
<jamespage> (I don't like checking my own work and its blocking the other SRU for munin its grouped with)
<pitti> barry: yay, got apport-kde working with py3 now, too \o/
<barry> pitti: rock!
<micahg> s-fox: pong, not right now, in a rush, can we chat tomorrow?
<s-fox> micahg,  sure thanks for the pong. what sort of time works for you?
<micahg> s-fox: not sure right now (18:00 UTC should be ok)
<s-fox> Okay, cool :)
<s-fox> Speak to you tomorrow micahg
<smoser> vibhav, before i dig further you want to reply to bhavi's comments?
<vibhav> smoser: I took the diff's from zerofree 1.0.1-2ubuntu1 (quantal) and zerofree 1.0.1-4 (sid)
<smoser> yeah, is saw comment. looking now.
<vibhav> Also, The changlog entry is less that 80 lines
<geser> mvo: are there any debug options which might help to find out why apt does it? I've a few users in the german support channel with this problem in the last weeks, or is the german mirror to blame?
<vibhav> smoser: how does the #2 debdiff look?
<smoser> vibhav, looking. sorry.
<vibhav> smoser: How does it look?
<smoser> vibhav, i'm sorry, still poking at other things... sorry for slow
<vibhav> ah fine
<smoser> vibhav, do you know if debian/patches/01_fix-as-needed-linking.diff is still relevant?
<smoser> unfortunately, theres basically no context onto why you want to move the -lext2fs
<geser> smoser: the context is "ld --as-needed"
<smoser> i assumed something like that.
<smoser> seems like we should at least forward that to upztream.
<smoser> (and to debian)
<smoser> so we dont have this delta for that.
<vibhav> looks fine to me
<geser> this depends on how friendly the DD towards Ubuntu is, as this an Ubuntu-only "problem" as Debian doesn't use --as-needed by default
<infinity> It's technically correct, regardless of how one calls their linker
<infinity> It just accidentally works without --as-needed.
<mvo> geser: yes (sorry, long meeting) -o Debug::acquire::http=true
<maxb> *blink*
<maxb> *wtf*
<maxb> lp:~ubuntu-core-dev/ubuntu/hardy/apport/hardy contains a packaging of hal, not apport
<vibhav> smoser: So, Is it worth forwarding to debian?
<infinity> vibhav: Yes.
<infinity> vibhav: We forward as-needed patches to Debian all the time.
<smoser> vibhav, its worth forwarding to debian.
<vibhav> fine
<vibhav> Ill do it later
<vibhav> (Since I have to sleep)
<smoser> and its worth forwarding to zerofree upstream (if that is not debian)
<smoser> vibhav, i'll go ahead and upload, but please then fill in the debian bug as reference.
<adam_g> anyone know the cause of this bzr error? i seem to be able to branch fine from another machine: http://paste.ubuntu.com/1027173/
<smoser> adam_g, i just hit the same thing.
<adam_g> hmmph
<maxb> adam_g, smoser: It's a bug in following stacked branches properly
<adam_g> saw it for the first time yesterday, with the same branch
<adam_g> ah
<smoser> when i moved my ~/.bazaar out of the way, it seemed to work.
<maxb> It's only being triggered from the thing which checks whether the branches are up to date, so one option is to turn that off
<maxb> launchpad.packaging_verbosity = off in your bazaar.conf
<smoser> maxb, is there a bug?
<maxb> I think there's a bug about the underlying stacking sillyness somewhere
<maxb> I don't know if there's one specifically about it affecting the uptodateness checker
<smoser> vibhav, interestingly, upstream (assuming http://intgat.tigress.co.uk/rmy/uml/index.html is upstream) does not even have a makefile in their source tree (git clone http://intgat.tigress.co.uk/rmy/git/zerofree.git)
<smoser> ivoks, ok. so i'm good to upload bug 887946, but it needs SRU information.
<smoser> could you add taht?
<ubottu> Launchpad bug 887946 in glib2.0 (Ubuntu Lucid) "Deadlocks in main loop" [Undecided,New] https://launchpad.net/bugs/887946
<ahasenack> hi, can someone from the ubuntu-sponsors team please take a look at my quantal upload? #1004678 thanks!
<infinity> cjwatson: So, uhm.  This API version of remove-package isn't particularly performant with a monstrous set of arguments, is it?
 * infinity wonders if he should have done this in a for loop instead.
<slangasek> infinity: I believe that was mentioned in the release notes ;)
<slangasek> (which may have been a one-off comment on #ubuntu-release, fwiw)
<infinity> slangasek: Oh, I remember him mentioning it.  I didn't expect a kernel removal to still be grinding after several minutes, that's all. ;)
 * infinity waits longer.
<infinity> Kinda curious if it'll time out at some point, or actually complete.
<maxb> The misguided inventiveness of users knows no bounds :-(.  /me unsubscribes the package import robot from a random dpkg postinst failure bug
<infinity> slangasek: Heh.  12 minutes, and counting.
<infinity> slangasek: See, I think I misread his "poor performance" note slightly.
<slangasek> :)
<smoser> smb, around?
<smoser> anyone want to give me a reason not to upload the debdiff at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353/comments/50
<smoser> ?
<ubottu> Launchpad bug 415353 in initramfs-tools (Ubuntu Lucid) "karmic/lucid installation slow on "detecting network hardware" with bnx2x" [Medium,In progress]
<infinity> smoser: Is that code in precise?
<infinity> smoser: If so, I'd say it's fairly well-tested, and seems a sane SRU candidate for lucid.
<smoser> infinity, yes. the 'hidden_dep_add_modules' is in precise.
<smoser> the failure case to me would seem to be inclusion of crc32c module in an initramfs when it wasn't needed.
<infinity> smoser: Which, given the size of our initrds, isn't world-ending.
<smoser> well, another 6240 bytes !
<infinity> Oh noes.
<smoser> (uncompressed)
<smoser> ok. well, i'm gonna upload then.
<slangasek> bdmurray: bug #511463> do you think we should close this as resolved, then?
<ubottu> Launchpad bug 511463 in grub2 (Ubuntu) "grub-pc failed to install/upgrade: exit status 1 - frontend: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0." [Medium,Confirmed] https://launchpad.net/bugs/511463
<ahasenack> hi, can someone from the ubuntu-sponsors team please take a look at my quantal upload? #1004678 thanks!
<hyperair> bug #1004678
<ubottu> Launchpad bug 1004678 in landscape-client (Ubuntu) "Release 12.05" [Wishlist,Confirmed] https://launchpad.net/bugs/1004678
<hyperair> it helps to add the "bug" for a clickable link
<hyperair> hmm landscape-client's in main, so i can't sponsor it
<ahasenack> hyperair: :(
<hyperair> well sit and wait patiently =)
<hyperair> someone will come
<smoser> anyone ever seen this:
<smoser>  http://paste.ubuntu.com/1027436/
<smoser> thats a fresh ubuntu instance in ec2. i install pastebinit, and it decides it should re-create my initramfs
<stgraber> ahasenack: having a look at it now, please not that it'll be uploaded to quantal-proposed as it's a seeded package and we're currently in freeze
<ahasenack> stgraber: when is the freeze lifted?
<stgraber> ahasenack: likely at some point tomorrow
<ahasenack> stgraber: what happens then if the package is in proposed? Do I need to ping someone to move it to main?
<stgraber> ahasenack: -proposed will be pocket copied to the release pocket, nothing you have to do
<ahasenack> stgraber: ah, ok
<ahasenack> stgraber: so are you taking a look at it now?
<stgraber> ahasenack: yep, test building here before uploading
<ahasenack> stgraber: thanks a lot
<stgraber> ahasenack: right, builds fine and doesn't seem to be pulling any universe package in the process, so should be fine.
<ahasenack> stgraber: thanks
<stgraber> ahasenack: I see you've done a good job at cleaning up any lintian warning for the source, but not for the binaries: http://paste.ubuntu.com/1027450/
<stgraber> ahasenack: nothing critical in there but certainly a list of nice to fix for the next few releases :)
<ahasenack> stgraber: that's a nice output
<stgraber> ahasenack: that's "lintian -iI *.dsc *.deb" after a binary build
<ahasenack> stgraber: how did you get it? I only get the single line output for each warning
<ahasenack> stgraber: thank, I will address those in the next upload indeed
<ahasenack> stgraber: is the procedure of adding an override + comment ok, if that's the case?
<ahasenack> stgraber: i.e., if I think the warning doesn't apply
<stgraber> ahasenack: yes, if the warning doesn't apply, overriding it + commenting is the right thing to do
<ahasenack> stgraber: ok, thanks for the review
<stgraber> uploaded
<Qasaur> hey guys
<smoser> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze (use proposed if necessary) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Daviey> ahasenack: ah, sorry - didn't realise you had a new candidate
<bdmurray> slangasek: I'm double checking regarding 511463 but will close it out if I find no duplicates
<ahasenack> Daviey: np :)
<ahasenack> stgraber: I filed bug #1009707 to check/address those lintian warnings
<ubottu> Error: Launchpad bug 1009707 could not be found
<ahasenack> weird, it exists
<ahasenack> oh, private
 * ahasenack fixes
<ahasenack> bug #1009707
<ubottu> Launchpad bug 1009707 in Landscape Client "Address lintian warnings in the binary packages" [Low,New] https://launchpad.net/bugs/1009707
<ahasenack> ok
<stgraber> ahasenack: cool, thanks!
<slangasek> bdmurray: great, thanks :)
<tumbleweed> barry: given up on launchpadlib?
<barry> tumbleweed: it has defeated me.... for now
<tumbleweed> :)
<barry> (really more its dep stack)
<tumbleweed> yeah, there is quite a bit of that
<tumbleweed> and they all use doc-tests which isn't that py3k-porting friendly
<barry> tumbleweed: that's not even the hardest part (but yeah, the repr of bytes can be a pain).  the thing that defeated me was 1) huge test deps that were unported; 2) deps made different choices about bytes v strings so the higher up libraries (like lazr.restfulclient) couldn't win because either choice caused crashes in some different lower lib
<lifeless> it doesn't help that python core has gone slightly insane
<lifeless> claiming various headers are strings, when they are defined by a wire encoding, and folk care about performance
<barry> lifeless: in this case, i think it's more that lazr.* needs a holistic approach
<lifeless> if python itself wasn't so dog slow, it wouldn't be an issue :)
<lifeless> barry: sure, but some of the rot goes all the way down to python3 mime/httplib
<barry> ah well
<YokoZar1> RAOF: ping
<lifeless> barry: I have great sympathy for the issue; I posted to python-dev about various bits a few times
<barry> lifeless: yep.  i have hope that rdm is finally untangling the email/mime ball of yarn
<RAOF> YokoZar1: Pong.
<barry> lifeless: so maybe by 3.4 :)
<lifeless> barry: maybe :)
<barry> lifeless: well, even 3.3 perhaps if he gets email6 landed in time
<YokoZar1> RAOF: DEBIAN_FRONTEND=noninteractive; sudo apt-get -y dist-upgrade     isn't working for me :/
<RAOF> YokoZar1: sudo su; DEBIAN_FRONTEND=noninteractive sudo apt-get -y dist-upgrade?
<lifeless> barry: I keep getting tempted to just write something bottom up that is lean, no compat, but horribly usable.
<lifeless> barry: then I wake up screaming.
<tumbleweed> :)
<RAOF> YokoZar1: You could also dpkg-reconfigure debconf; that'll guarantee that sudo doesn't strip out the environment variable ;)
<YokoZar1> RAOF: DEBIAN_FRONTEND=noninteractive; sudo echo $DEBIAN_FRONTEND   outputs noninteractive though
<Daviey> hang on
<RAOF> Is your shell replacing $DEBIAN_FRONTEND before spawning the command? (I believe so)
<Daviey> YokoZar1: before updating grub2.. please run DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc
<YokoZar1> ahh maybe it will work in the script and not in the shell then
<Daviey> then dist-upgrade
<cjwatson> YokoZar1: you want sudo DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc
<Daviey> YokoZar1: Please can you confirm ?
<cjwatson> infinity: Yeah, it has to get a lot of BPPHs.  Some optimisation should be possible though; in particular being able to pass more than one status to Archive.getPublishedBinaries would make a big difference.
<cjwatson> And maybe some cleverer searching in general.
<infinity> cjwatson: It took 51m52.453s to remove two out-of-date kernels.  I was impressed.
<infinity> cjwatson: Given that that's arguably the most frequent use of remove-package, it'll be entertaining. ;)
<cjwatson> infinity: Pretty sure it wasn't anything like that bad for me.  It's probably somewhat RTT-sensitive ...
<cjwatson> infinity: But yeah, worth improving.
<YokoZar1> Daviey: cjwatson's reconfiguration works as noninteractive, which makes a subsequent sudo DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade work, however if I just do the latter command it doesn't work
<Daviey> YokoZar1: Maybe i'm tired and missing it, but cjwatson and myself said the same thing?
<Daviey> YokoZar1: fresh instance pre grub update, sudo DEBIAN_FRONTEND=noninteractive dpkg-reconfigure grub-pc ; sudo apt-get -y dist-upgrade ... Note, NO DEBIAN_FRONTEND=noninteractive on the upgrade.
<YokoZar1> Daviey: what I'm saying is the dpkg-reconfigure on grub-pc is necessary
<YokoZar1> I can't just do it on the dist-upgrade step
<slangasek> there's no reason I can conceive of for that
<slangasek> DEBIAN_FRONTEND=noninteractive means "do not show me any debconf prompts"; and the ucf prompt is a debconf prompt
<YokoZar1> let me just recheck that I'm doing this properly then
<YokoZar1> (spinning up new instances)
<YokoZar1> Ahh I seemed to have slipped in two sudos there
<Daviey> cheeky.
<YokoZar1> ie sudo DEBIAN_FRONTEND=noninteractive sudo  ==> fail
<YokoZar1> so yeah it works as expected, thanks
<Daviey> YokoZar1: ok, thanks.  We will make it so the latest AMI's are fixed, but the ones currently out in the field will have this issue, until something smarter comes along.
<YokoZar1> Daviey: Yeah that sounds reasonable.  The root cause might be bug 759545, which would be a good target to get in before the point release
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [High,Triaged] https://launchpad.net/bugs/759545
<Daviey> YokoZar1: Nope, that isn't the issue.
<YokoZar1> Daviey: ahh right, cause our grub is modified
<Daviey> For the entire Precise cycle, the issue was being tracked as that bug - but it's not that issue.  Which caused confusion, causing it not to be resolved.
<Daviey> However, 12.04.1 will include a resolution regardless.. but the daily images will also start showing the resolution even sooner.
#ubuntu-devel 2012-06-07
<vsingh165> hi, is it possible to have multiple computers registered on your Launchpad acct?
<hallyn> say, is http://paste.ubuntu.com/1027991/ (dpkg-shlibdeps warning) something I should worry about?  the symbol (sem_post) is provided by -lrt (according to manpage anyway), in libc...
<stgraber> strange it's complaining about it...
<hallyn> yeah..  it doesn't stop the build there, at least
<hallyn> anyway (since you're here :) lp:~serge-hallyn/+junk/lxcwithapi now has the debian/ to build a set of lxc2* packages.  builds, haven't installed/tested it yet :)  will try it out tomorrow
<hallyn> (surely it'll fail spectacularly)
<hallyn> (so if i do it now, i'll stay up for hours enjoying the magnificance ofthe failure)
<stgraber> hallyn: right, sounds like I should have a look at that tomorrow
<stgraber> if I start poking at it, I might end up doing the python work tonight and not sleep at all...
<hallyn> heh, we'll poke it with a stick tomorrow.  good night!
<stgraber> good night!
<RAOF> hallyn: Does it actually *link* to librt?
<vibhav> smoser: ping
<vibhav> Could any body nominate https://bugs.launchpad.net/ubuntu/+source/postgis/+bug/967162 for oneiric and lucid?
<ubottu> Launchpad bug 967162 in postgis (Ubuntu) "Incorrect binary location in 1.5.3-1" [Undecided,Fix released]
<micahg> vibhav: only oneiric appears to be affected
<vibhav> micahg: Ah yes, It was stupid of me
<vibhav> s/stupid/foolish/
<vibhav> micahg: Could you nominate it for oneiric?
<micahg> vibhav: task given
<vibhav> thanks!
<ihashacks> long-time Linux junkie here, fairly recent bug fix contributor - not sure if I even did this right:
<ihashacks> https://code.launchpad.net/~ihashacks/ubuntu/precise/atftp/fix-for-383761_972834
<ihashacks> Would this be the place for validation? heh
<vibhav> micahg: Could you also set the importance to high\medium ?
<micahg> vibhav: nope, I'd say that's low
<vibhav> why?
<micahg> easily worked around
<vibhav> By creating symlinks, right?
<micahg> that or updating $PATH
<vibhav> but users expect these tools to be in their default
<vibhav> $PATH, and scripts/cron jobs/etc using them will break after upgrading
<vibhav> from 1.5.2 to 1.5.3.
<vibhav> </quote
<vibhav> >
<micahg> https://wiki.ubuntu.com/Bugs/Importance -> Low -> Bugs that have a moderate impact on a non-core application
<micahg> vibhav: I'd consider it SRUable for the reason give, just still low importance
<micahg> but IANA SRU team member
<vibhav> fine
<vibhav> micahg: Set the Importance to low then
<micahg> done already
<vibhav> thanks
<rickspencer3> nice, another day of beer in http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
<rickspencer3> and it's a1 today :)
<rickspencer3> thanks infinity
<testi> Where does unity calculate transparency? GPU or CPU? For example the transparency of the Dash-Help that appears when you keep pressing the Super-Key.
<dholbach> good morning
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze (use proposed if necessary) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<vibhav> woo!
<seb128> vibhav, you are still using oneiric? I'm not sure all those SRUs to it make sense, there is a new LTS out and users who have been using it for over 6 months probably worked around the issues
 * dholbach hugs seb128
 * seb128 hugs dholbach
<vibhav> seb128: Some of my friends still use oneiric, and are not planning to upgrade for some time
<vibhav> s/upgrade/fresh install/
<seb128> shrug, users are weird :p
<seb128> why would use oneiric when precise is so much better ;-)
<seb128> vibhav, still as said, I'm not sure it make sense to SRU minor issues after 6 months, users either worked around or move on to something else
<vibhav> only if you could convince them :(
<seb128> vibhav, the issue is also that nobody verifies uploads to old version, see the natty and oneiric lists on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<vibhav> seb128: :O
<seb128> ":0"?
<seb128> ":O"?
<vibhav> "surprised"
<vibhav> at the number of packages
<seb128> well, not very surprised, most people run either the current unstable or current stable or current lts
<vibhav> ah
<seb128> so we have very few contributors still running old stables and doing verifications for those
<vibhav> yeah, but in the bug report the reporter only requested a SRU
<vibhav> <quote>Can the fix be applied to 11.10 ocelot too please?</quote>
<vibhav> hence the SRU
<seb128> vibhav, yeah, that was before precise was released though, i.e when oneiric was current stable
<vibhav> ah yes
<seb128> I'm a bit unsure what to do there
 * vibhav should have seen the date
<seb128> I feel like uploading it is wasting SRU team time
<xnox> seb128: reply to the user: this is not a security update please upgrade to precise *evil laugh* ? =)
 * xnox hides
<seb128> xnox, ;-) well the contributor is vibhav which is why I'm discussing it here
<xnox> ah =)
 * vibhav winders what to do
<seb128> but I neither like unsuscribing sponsors, not letting it in the queue sitting there, nor uploading it because I think it will be never verified and just waste SRU team time
<vibhav> Or wait, Ill verify it
<vibhav> on a friends machine
<seb128> ok, deal
<vibhav> Is that fine?
<seb128> yes
 * vibhav hugs seb128 
<seb128> ;-)
<seb128> vibhav, but please do oneiric SRUs only for things really worth it
<seb128> there is no real point to spend lot of efforts fixing small issues for it
<vibhav> sure :)
<xnox> Can somebody please accept tasks for Precise 12.04.1 milestone and Quantal for the bugs in this launchpad bug search query http://tinyurl.com/bv3avz6 I am going to run these through the 12.04.1 release team and hopefully land those for 12.04.1, this is an action item from me from the last 12.04.1 meeting.
<xnox> If release team decides on the change the scope I will be amending those bugs as appropriate.
<hippiehacker> curl http://ftp.utexas.edu/ubuntu/dists/precise/main/binary-amd64/Packages.gz | zgrep Task: # how are Tasks defined?
<hippiehacker> I'm looking at https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/574287 and wanted to see how tasks are created
<ubottu> Launchpad bug 574287 in tasksel (Ubuntu) "tasksel: forcefully removes packages when tasks overlap" [Undecided,In progress]
<seb128> xnox, bug like #1006509 seem weird for a SRU?
<seb128> xnox, bug #1006509
<ubottu> Launchpad bug 1006509 in autofs (Ubuntu Quantal) "Please merge from debian autofs 5.0.6-2" [Wishlist,In progress] https://launchpad.net/bugs/1006509
<xnox> seb128: yes it is weird, but it has bugfixes. I need to explain all of them. Some of them should have happened before precise release.
<xnox> seb128: potentially autfs one will be split out just to get the bugfixes from the stable upstream branch of upto June.
<seb128> xnox, ok, I accepted them, can you set the settings and assigned as appropriate?
<xnox> seb128: ok.
<xnox> seb128: thank you =)
<seb128> xnox, yw ;-)
<hallyn> RAOF: well it.s a library.  So no.
<hallyn> it is in the LDADD, and binaries linked against it show the right output for ldd
<vibhav> Where does pbuilder generate the debs?
<cyphermox> vibhav: ~/pbuilder/results or something IIRC ?
<tumbleweed> pbuilder-dist uses ~/pbuilder/results. The default is /var/cache/pbuilder/results
<cyphermox> ah, my bad :)
<vibhav> thanks!
<mterry> When moving (renaming) a conffile in the same package, I know to use "dpkg-maintscript-helper mv_conffile".  Is there anything different I should do when moving and renaming a conffile between source packages (besides the Replaces stuff in debian/control)?
<seb128> mterry, use a .maintscript rather than calling dpkg-maintscript-helper manually
<didrocks> mterry: to answer your question, I guess you don't have anything different to do
<seb128> mterry, otherwise for your question I'm not sure, mvo or cjwatson probably knows better about that
<mterry> seb128, k, thanks for the hint though, will look at those
<seb128> mterry, you can take avahi as a package which does use a .maintscript to move conffiles
<mterry> seb128, yup.  man dh_installdeb also talks about them
<seb128> mterry, it's cool because with them you don't need to remember which one of the maintainer scripts you need to add calls to
<seb128> i.e prerm, postinst, ...
<cjwatson> It used to be excruciatingly difficult
<cjwatson> to transfer conffiles between packages
<mterry> I like the word "used" there
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335276 has a bunch of gory details, and you can still see the madness in openssh-server.preinst
<ubottu> Debian bug 335276 in openssh-client "openssh-client: unnecessary prompting about conffile" [Important,Open]
<cjwatson> But I think nowadays you can just use Replaces
<vibhav> smoser: ping
<smoser> vibhav, hi
<vibhav> smoser: Did you upload the merge?
<vibhav> Or do you want a more revised version?
<cjwatson> If you're just transferring package ownership rather than changing the filename as well, then you shouldn't need .maintscript
<mterry> cjwatson, I see, so conffiles act like normal files when transitioning between packages.  What if I want to move/rename it at the same time?  Do I do Replaces+.maintscript in new package?
<smoser> vibhav, i did not.
<cjwatson> mterry: [fx: runs]
<smoser> vibhav, i wanted to give you a chance to do address the things i brought up
<mterry> I guess there wouldn't need to be replaces, since it wouldn't be at the same location...?
<cjwatson> mterry: Er, maybe pass a package name to dpkg-maintscript-helper?  I'm not sure - you may just have to try it.
<vibhav> smoser: fine, Ill upload a better debdiff
<vibhav> thanks, though
<smoser> vibhav, i can then take a quick look and upload
<mterry> cjwatson, OK, thanks!
<cjwatson> mterry: Make sure that you try it both with an unmodified conffile and with a modified one
<mterry> cjwatson, k
<hippiehacker> I'm looking at https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/574287 and wanted to see how tasks are created... basically what files/process results in the Task headers in  'curl http://ftp.utexas.edu/ubuntu/dists/precise/main/binary-amd64/Packages.gz | zgrep Task:'
<ubottu> Launchpad bug 574287 in tasksel (Ubuntu) "tasksel: forcefully removes packages when tasks overlap" [Undecided,In progress]
<cjwatson> hippiehacker: They're written automatically by the Launchpad archive publisher, based on germinate output
<cjwatson> hippiehacker: I don't know if that's desperately relevant to that bug though; we don't consider overlapping tasks to be a bug, if that's what you're wowndering
<cjwatson> *wondering
<vibhav> smoser: Ill file the Debian Bug later, is that fine?
<hippiehacker> I'm somewhat looking into the bug, but mostly trying to understand how to create tasks and make them available
<smoser> vibhav, sure.
<cjwatson> hippiehacker: If you're generating test archives for yourself, you probably want apt-ftparchive extra overrides; our input to apt-ftparchive is in /ubuntu/indices/ on mirrors
<cjwatson> hippiehacker: Adding new tasks requires changing /usr/share/tasksel/ubuntu-tasks.desc
<hippiehacker> I see that file, but the Packages: header only lists 'task-fields'
<hippiehacker> where would one set the packages for a custom task?
<hippiehacker> looks like we can drop a file into /usr/local/share/tasksel/
<cjwatson> hippiehacker: "task-fields" causes the packages to be implicitly set by the Task fields you're looking at
<cjwatson> in Packages
<hippiehacker> I'll look at apt-ftparchive + /ubuntu/indices.
<hippiehacker> cjwatson: thanks heaps!
 * vibhav looks for final changes
<hallyn> Ok, what on earth.  Trying again to figure out why fcntl.h doesn't give me AT_EMPTY_PATH.  I find ./debian/patches/any/submitted-bits-fcntl_h-at.diff in eglibc source, which expliclty removes the definition!
<vibhav> smoser: done!
<hallyn> yay, bugs.debian, here i come
<smoser> vibhav, thanks.
<hippiehacker> cjwatson: https://gist.github.com/2889140 is my attempt to understand where the dns-server task is defined before the generation of Packages.gz with apt-ftparchive
<cjwatson> hippiehacker: bzr co lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal, look at ubuntu.quantal/dns-server
<cjwatson> that's the ultimate source, not dependency-expanded
<cjwatson> germinate (see package) is responsible for expanding out dependencies in the seeds
<cjwatson> http://bazaar.launchpad.net/+branch/launchpad/files/head:/lib/lp/archivepublisher/scripts/generate_extra_overrides.py takes the output and turns it into extra overrides
<cjwatson> That's run as part of the Launchpad publisher and isn't something you can run standalone, but the mapping from germinate output files to Task fields is merely tedious rather than anything magic
<hippiehacker> quite the process
<cjwatson> It's designed to minimise the number of manual changes we have to make as packages' dependencies shift around
<cjwatson> Which is the sort of thing you care about rather more at large scale
<hippiehacker> what are your thoughts on where Debian went with task-* meta-packages rather than updating the Packages.gz in wheezy and beyond?
<hippiehacker> it likely fixes the auto-removal problem, as the meta-packages bascially just have dependencies (I think)
<hippiehacker> http://wiki.debian.org/tasksel#Sample_use : "Note that in DebianWheezy and beyond tasksel provides and uses dummy packages (known as meta packages) to pull required dependencies."
<cjwatson> hippiehacker: I haven't looked into that much as yet; it's a reversion to an earlier approach, basically
<cjwatson> We could do much the same with our existing metapackages, presumably
<cjwatson> Well, in those cases where they exist, which isn't all
<seb128> ev, hey
<ev> hi seb128
<seb128> ev, is whoopsie client or server side ever recommending to use ask ubuntu?
<seb128> ev, I'm trying to figure where to reassigned https://bugs.launchpad.net/ubuntu/+source/launchpad-integration/+bug/991602
<ubottu> Launchpad bug 991602 in launchpad-integration (Ubuntu) "Apport's recommendation of Ask Ubuntu is vague" [Undecided,Confirmed]
<hippiehacker> If a wanted to allow a closer-to-end-user to create a list of packages, similar to a task would a good approach be to streamline the dynamic generation of a new metapackage.deb based on a tasklike name and a list of packages?
<seb128> ev, seems "apport" sometimes suggest "Ask Ubuntu is the best place to get free technical support" ... which jcastro complains about because it's creating issue on the askubuntu side
<ev> seb128: the user never ever sees whoopsie - it's a daemon. Server side there's no reference to Ask Ubuntu
<seb128> ev, ok, that was a random shot, I grepped locally without success and google is not very useful either
<seb128> ev, thanks
<ev> seb128: sure thing
<seb128> oh, found it
<seb128> ev, for the record it's coming from the xorg hook
<ev> ick
<hippiehacker> at the end-user-level: https://help.ubuntu.com/community/MetaPackages#Creating_Metapackages
<hippiehacker> cjwatson: thanks for the info, I'll be looking deeper into all this very soon
<cjwatson> hippiehacker: OK, no problem
<Sweetshark> seb128: do you see any reason my mail to the TB ML wrt to LO MRE hasnt been moderated yet?
<Sweetshark> ^ wonder how Joe Average would parse 'TB ML wrt LO MRE'
<seb128> Sweetshark, your response to pitti you mean?
<seb128> Sweetshark, try pinging cjwatson
<seb128> pitti is off today, not sure who else is moderation it
<stgraber> Sweetshark: btw, easiest way to avoid moderation is simply to subscribe to it
<Sweetshark> stgraber: my inbox already has digestion trouble ..
<cjwatson> Sweetshark: Largely because listadmin hates me
<cjwatson> You can subscribe and turn off delivery
<cjwatson> fetching data for technical-board@lists.ubuntu.com ... Died at /usr/bin/listadmin line 1310.
<cjwatson> Ah, there we go, works eventually
<cjwatson> Sweetshark: Moderated now
<Sweetshark> cjwatson: thx
<cnd> argh, I just uploaded to quantal instead of quantal-proposed
<cnd> can I get someone to delete my upload to quantal, and then I'll reupload?
<stgraber> cnd: unliekly, we're not in hard freeze, anything you upload will hit the archive directly
<cnd> stgraber, oh... well, it is a crasher fix
<cnd> so I guess it should actually go to quantal directly
<stgraber> cnd: we're very unlikely to respin at this point anyway (not a reason to push more stuff to the release pocket though ;))
<cnd> ok
 * vibhav hugs smoser 
<micahg> smoser: -v when uploading merges please :)
<Daviey> micahg: if you want to improve on, http://pb.daviey.com/pOI1/
<Daviey> more than welcome :)
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: soft freeze (use proposed if necessary) | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<smoser> micahg, i realized that. thank you.
<smoser> :-(
<smoser> it does seem like bzr bd could be smarter there
<smoser> but i guess its non-trivial when which version to determine to show against.
<Daviey> smoser: see my hacky script above
<Daviey> (althought i sponsored a merge recently forgetting to run it.. *sigh*)
<smoser> Daviey, right. yo uneed rmadison data to tell you.
<smoser> or som eother source of "what is current"
<micahg> if you use grab-merge, it provides a ../merge-buildpackage script
<james_w> smoser, "bzr bd --package-merge" might do what you want
<james_w> it requires a flag, as you can't detect it reliably without hitting e.g. Launchpad
<seb128> could somebody set https://code.launchpad.net/~kroq-gar78/ubuntu/precise/visualvm/fix-start/+merge/108089 to merged?
<james_w> seb128, done
<seb128> james_w, thanks
<seb128> yofel, could you look to bug #998179? it seems that https://launchpad.net/ubuntu/+source/kdepim/4:4.8.3-0ubuntu0.1 that you sponsored has a regression compared to 4.8.2
<ubottu> Launchpad bug 998179 in kdepim (Ubuntu) "sync of groupdav contacts fails with "unknown error code 0"" [Undecided,Confirmed] https://launchpad.net/bugs/998179
<slangasek> james_w: remind me why we can't look for the previous package tag that's on the main branch, without hitting LP?  since any tags for merged versions will be on the different branch that's being merged in
<seb128> ScottK, ^
<james_w> slangasek, hmm, maybe that would work
<james_w> it looks at the changelog currently
<yofel> seems fixed in 4.8.4 which we are currently preparing
<james_w> we don't currently do anything based on "latest tag", but I don't see why we can't
<seb128> yofel, can you comment on the bug and unsubscribe the sponsors if sponsoring is not needed?
<slangasek> james_w: for maximum robustness it should make sure it's using a tag that corresponds to a version number that exists in debian/changelog
<micahg> slangasek: it doesn't work for the case in -proposed
<slangasek> yes, I'm not trying to solve all the world's problems :)
<slangasek> sometimes you still need to pass -v
<yofel> slangasek: commented, but I can't unsubscribe the sponsors team, insufficient permissions
<micahg> yofel: done
<yofel> thanks
<seb128> yofel, thanks (I guess it was for me and not slangasek)
<yofel> oh right, sorry
<seb128> np ;-)
<infinity> cjwatson: Thoughts on SRUing for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533 ?
<ubottu> Debian bug 676533 in openssl "please enable arm assembler code in openssl" [Wishlist,Open]
<infinity> cjwatson: It's clearly a feature, not a "bugfix", except that I'd consider "openssl is really slow, and we can make it more than twice as fast" a pretty big bug in our LTS server offering.
<cjwatson> infinity: I kind of thought about doing that pre-release, but there was too much else going on.  Given recent history, can we get it thoroughly exercised in quantal first?
<cjwatson> (There's a corresponding Ubuntu bug somewhere reasonably obvious)
<slangasek> s/exercised/exorcised/ I think, based on recent experience with openssl
<cjwatson> There's that
<infinity> Heh.
<infinity> Are there good openssl stress-test (and correctness-test) suites?
<seb128> infinity, cjwatson: (you seem to be the closest from a live-build maintainer for Ubuntu): could you review the patch from https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/975861 when you have some time?
<ubottu> Launchpad bug 975861 in live-build (Ubuntu) "E: Unable to locate package console-common" [Undecided,Confirmed]
<seb128> jamespage, zul: is ubuntu-sponsors needed on https://bugs.launchpad.net/ubuntu/+source/modsecurity-apache/+bug/988819 or are you guys on it?
<ubottu> Launchpad bug 988819 in modsecurity-apache (Ubuntu Precise) "wrong path to libxml2.so.2 in mod_security" [High,Triaged]
<zul> seb128: i thnk jamespage and racb are on it
<jamespage> seb128, zul: yes
<seb128> jamespage, should I unsubscribe sponsors then?
<jamespage> seb128, +!
<jamespage> or +1 even
<seb128> jamespage, zul: thanks ;-)
<infinity> seb128: Hooray for using live-build in a mode where it duplicated debootstrap (poorly)?
<infinity> seb128: We should probably just merge, rather than cherry-pick.  And I'm not sure if it's worth SRUing for that.
<seb128> infinity, your call, can you write that on the bug? ;-)
<cjwatson> infinity: qa-regression-testing has some stuff for openssl.  It's not brilliant.
<kees> who's the best person to ping about LP: #1010141 ?
<kees> "gvfs-gdu-volume-monitor automounts loop devices, preventing them from being unmounted"
<hallyn> i realize we're in freeze now, but for the benefit of dropping the qemu-kvm workaround, could someone look at 1010069 ?
<Daviey> bug 1010069
<ubottu> Launchpad bug 1010069 in eglibc (Ubuntu) "bits/fcntl.h does not define AT_EMPTY_PATH" [Medium,Triaged] https://launchpad.net/bugs/1010069
* stgraber changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> Daviey: oops, i thought i typed that :)
<stgraber> hallyn: no more freeze ;)
<hallyn> oh??  i thought it was until tuesday or somehing!
<hallyn> heh, i see :)
<kees> seb128: can you look at bug 1010141? this is causing problems for image creation, etc.
<ubottu> Error: Could not gather data from Launchpad for bug #1010141 (https://launchpad.net/bugs/1010141). The error has been logged
<seb128> kees, is that the one where I just added a comment saying to upstream it?
<seb128> kees, it's eod for me but I will have a closer look tomorrow
<kees> seb128: ah, whoops, sorry.
<seb128> kees, no worry, I wouldn't be on IRC if I was done working, but it's close enough that I will look at it tomorrow not today ;-)
<kees> seb128: heh, okay, thanks.
<seb128> yw!
<mhall119> YokoZar: ping
<hippiehacker> If want to automate the creation a metapackage (https://help.ubuntu.com/community/MetaPackages#Creating_Metapackages) that includes packages from other ppas.... ie the way the google-chrome.deb adds googles own repos
<hippiehacker> how would I get the package cache updated from the new ppas and then install the desired dependencies from those ppas (from within the metapackage)?
<infinity> seb128: Aww, crap.  Was I meant to leave the gnome* stuff in proposed until someone had finished a libgnome-desktop transition?  Did I miss a memo?
<infinity> popey: unity has been FTBFS for 2 weeks now.  Do you know what's being done?
<seb128> infinity, the libgnome-desktop thing is unknown to me, what's the issue?
<broder> ooc, did anybody look at https://github.com/twitter/zipkin ?
<broder> seems vaguely interesting
<broder> though presumably only if we spent a bunch of time instrumenting
<seb128> infinity, oh, soname change, well I guess we will deal with it now that a1 is over
<broder> oof, wrong channel, but whatever :)
<infinity> seb128: Yeah, SOVER bump.  It's probably just a question of rebuilds for a eog, evo, and a few others.
<infinity> seb128: Except that unity is now uninstallable, and it's FTBFS in quantal, so someone needs to get around to fixing that too. :/
<seb128> infinity, yeah, popey's team is supposed to be on that for 2 weeks, dunno what they are doing...
<seb128> popey, ^
<infinity> seb128: I already pinged popey a few lines up. ;)
<infinity> seb128: Anyhow, I can do all the !unity rebuilds, but if you guys had new versions staged or something, go ahead.
<seb128> infinity, is there any hurry to do the rebuilds?
<infinity> seb128: Just that people like to see beer on quantal_probs?
<seb128> infinity, we have for sure updates coming soon so things will get rebuild in the next week
<infinity> seb128: (And everything is uninstallable)
<infinity> seb128: But thanks to unity being broken, fixing the rest won't help. :/
<seb128> oh, the different sonames are no co-installable?
<seb128> that's an issue for sure
<seb128> why so?
<infinity> seb128: Sure they are, but the old lib had a hard dep on the arch:all data package. :/
<seb128> :-(
<seb128> hate the common binaries
<seb128> infinity, I will get it sorted tomorrow
<infinity> seb128: For future reference, if libfooSOVER has a hard dep on libfoo-data (and maybe that's legit), you should probably version the data name too (ie: libfooSOVER-data)
<infinity> seb128: Then nothing would have broken. :/
<seb128> imho we should just >= on -data
<infinity> Or that.
<infinity> But not up to me to decide without looking if the dependency is legitimate. ;)
<infinity> (I see no reason why it wouldn't be sane to want data from the same version)
<seb128> well, because in practice the next version often works and it avoids such issues :p
<infinity> Heh.
<infinity> Well, and you'd have to version the data paths and stuff too, if you versioned the package names.
<infinity> So, a bit messier.
<seb128> like in this case the -data has documentation and icons
<infinity> Anyhow.
<seb128> and neither of those changed
<seb128> but unity is being worked for some time
<infinity> seb128: Given the timezone skew between me and most of the people who do unity things, can you be annoying to them tomorrow for me?
<seb128> it got bitten by "need to migrate to new boost to build with gcc 4.7"
<seb128> infinity, well I've been pushing them for a week, it's a bit of a mess
<infinity> Fun.
<seb128> infinity, unity needs to be migrated to new boost, but then it segfaults
<seb128> so they are down to searching for toolchain regressions
<seb128> but that's taking a bit of time
<slangasek> is there a backtrace posted somewhere that we could throw our eyeballs at?
<seb128> I will see if they can build with gcc4.6
<infinity> (Time to revert to unity-2d instead?)
<infinity> seb128: That could be the path of least resistance for now, yeah.
<seb128> slangasek, the segfault is in nux, it's not clear it's a toolchain issue, out of the fact that the same code works on precise
<seb128> slangasek, I will do a status update with didrocks tomorrow morning and see what solutions we have
<slangasek> ok
<infinity> seb128: Actually, if CC=gcc-4.6 works, I might just upload the current quantal version with that.  And they can keep working on fixing trunk.
<infinity> seb128: I'll test locally.
 * infinity just wants to clear up the SOVER skew oops for now.
<infinity> seb128: And I'll get the other libgnome-desktop stragglers with rebuilds today too, you guys can just focus on your 3.5.x uploads.
<seb128> robert_ancell, ^
<seb128> infinity, see with robert_ancell to not dup work on rebuilding the rdepends
<robert_ancell> infinity, let me know if you want me to help on the rebuilds
<popey> infinity: seb128 i understood unity in quantal was building fine now?
<seb128> popey, where is the branch?
<seb128> popey, it didn't get uploaded for sure
<popey> hmm
<ScottK> seb128: Thanks.
<popey> I'll speak to lukasz in the morning..
<ScottK> I guess yofel took care of it.
<seb128> ScottK, he did, thanks
<infinity> robert_ancell: I should be able to manage; I have the technology.
<micahg> infinity: you do realize that most of those desktop packages are managed in ~ubuntu-desktop VCS branches, right?
<infinity> micahg: I also realise that I don't care if my changes are dropped, since they're all no-change rebuilds.
<infinity> micahg: The extra step of comitting that to several different VCSes is busy work with no discernable win for anyone. :/
<micahg> changelog isn't authoratative and someone might try to upload the same version again
<infinity> "changelog isn't authoratative"?
<micahg> doesn't have the full histroy
<infinity> But yes, someone might try to upload the same version again.
<infinity> And yes, the branches aren't authoritative, news at 11. :/
<infinity> Maybe I'll go on a commit-fest later today.
<infinity> Fixing the archive was more important that not offending people's sensibilities.
<Bluefoxicy> I don't understand something.
<Bluefoxicy> ~$ jigdo-lite http://cdimage.debian.org/debian-cd/6.0.5/kfreebsd-amd64/jigdo-cd/debian-6.0.5-kfreebsd-amd64-CD-1.jigdo
<Bluefoxicy> 1: 'Debian GNU/Linux 6.0.5 "Squeeze" - Official kfreebsd-amd64 CD Binary-1 20120512-17:38 (20120512)' (debian-6.0.5-kfreebsd-amd64-CD-1.iso)
<Bluefoxicy> The jigdo file refers to files stored on Ubuntu mirrors.
<Bluefoxicy> ...  Ubuntu mirrors?
<Bluefoxicy> it really does go searching through Ubuntu stuff, too.
<Bluefoxicy> Specifically it's using the mirror list at https://launchpad.net/distros/ubuntu/+archivemirrors
<Bluefoxicy> ... when given a Debian distribution .jigdo
<Bluefoxicy> is this a bug or a feature?
<infinity> If it's jigdo on Ubuntu, I'd call it a feature.  I suppose.
<infinity> Though, no.
<infinity> I guess more of a bug. :P
<slangasek> "The jigdo file refers to files stored on Ubuntu mirrors. Please choose a Ubuntu mirror as follows:" <-- that's a bug
<infinity> Since we rebuild everything, there's no chance of finding the correct files on an Ubuntu mirror.
<slangasek> the text is wrong
<slangasek> however, there's probably not enough information available to get it right
<Bluefoxicy> Ubuntu mirror [http://us.archive.ubuntu.com/ubuntu/]: us
<Bluefoxicy> http://mirror.anl.gov/pub/ubuntu/        # US United States
<slangasek> I like this part though:
<slangasek> Ubuntu mirror [[arch=amd64]]:
<slangasek> misparsing sources.list ftw
<Bluefoxicy> slangasek:  yeah I'm thinking it may be a limitation of Jigdo that it can't actually tell what's being asked for?
 * infinity hasn't jidone in ages.
<infinity> jigdone*
<Bluefoxicy> Does Ubuntu even use Jigdo to distribute?
<infinity> Bluefoxicy: We do, for alternates.
<Bluefoxicy> like 6 releases ago there was a huge buzz about writing an even MORE advanced system that used bittorrent AND http to download chunks of ISO images in parts
<infinity> I don't think we widely advertise that we do, but we generate the jigdo files.
<Bluefoxicy> like it would use bittorrent, but also pick a dozen mirrors and HTTP GET with resume from an offset, download some KBs, then close the connection
<infinity> That said, we're looking to dump the alternates anyway.
<slangasek> infinity: or if you're from the rural midwest, "jigdid"
<slangasek> as in "has jigdid"
<infinity> slangasek: I ain't done jigdid nuttin' in forever.
<Bluefoxicy> but then there was also talk about binary upgrades where if you made a 1 line change in OpenOffice.org you'd get a debian patch .deb that was only a few kilobytes, instead of redownloading 600MB of packages >:|
<Bluefoxicy> but I still see updates that fix a Depends: or Recommends: and require re-downloading and re-installing the whole package >:|
<Bluefoxicy> I'm assuming this is either hard or there's too many ways to do it and people can't pick one that does everything they want
<infinity> Bluefoxicy: Some day, someone might make binary diff distribution work sanely, but I suspect that every year, well care a little less, as bandwidth increases.
<infinity> s/well/we all/
<Bluefoxicy> infinity:  I care a little less because I have an SSD and the changes go through faster.
<micahg> and binary compression improves as well (transition to xz debs)
<Bluefoxicy> That said, it still takes time for me to download 600-800 megs of stuff without an OC-48 here
<Bluefoxicy> I mean I only get 500-800k/s
<Bluefoxicy> anyway.  I should file a bug about that Jigdo behavior, just to put it on the record.
<infinity> popey: Still around?
<popey> infinity: just
<infinity> popey: Was curious if you know the state of the nux glew1.7 transition as well.
<infinity> popey: But I suppose I'll just assume that's happening in tandem with boost.149 and gcc-4.7
<popey> not off the top of my head, no, will check in in my AM (8 hours)
<infinity> popey: Mmkay.  Go sleep. :P
<popey> âº
<infinity> Checking out unity crashed bzr.  SPECIAL.
<infinity> ... reproducibly.
<infinity> micahg: And this is why I won't be committing my unity change. :P
<micahg> hehe
<bdmurray> cnd: can you elaborate on bug 973297 being verification-failed?
<ubottu> Launchpad bug 973297 in xserver-xorg-input-evdev (Ubuntu Precise) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Fix committed] https://launchpad.net/bugs/973297
<cnd> bdmurray, it was failed before I reuploaded a new package
<infinity> So, it should have been set back to needed?
<bdmurray> cnd: so it should be verification-needed now?
<cnd> I figured the SRU team would move it back to verification-needed after approving the new package for precise-proposed
<cnd> yeah
<bdmurray> okay, I updated the tags
<bdmurray> well maybe not due to a timing out bug tracker!
<bdmurray> okay now fixed
<cnd> :)
<cnd> thanks
#ubuntu-devel 2012-06-08
<infinity> robert_ancell: Your gnome-icon-theme-symbolic wants a new gnome-icon-theme, which you didn't upload...
<infinity> robert_ancell: (Causing an uninstallible cascade)
<RAOF> Whee! 'tis the season for GNOME breakage, apparently.
<infinity> AKA: Friday?
<infinity> robert_ancell: Pls fix, thx. ;)
<RAOF> There's also the new libgnome-desktop3, which broke soname but isn't parallel installable.
<infinity> RAOF: Yeah, I know, I rebuilt the world to fix that already.
<RAOF> Ah. That world-rebuild apparently hasn't made it all the way out to archive.ubuntu.com :)
<infinity> Has too.
<infinity> apt-get update harder.
<infinity> Of course, you still can't upgrade smoothly because of the above icont-theme issue.
<infinity> icon-theme, too.
<RAOF> Oh! I don't have a.u.c in my sources on this install. That'd be why.
<infinity> RAOF: Just some horribly lagging AU mirror of doom?
<RAOF> Indeed.
 * infinity used to have a love/hate relationship with iinet's mirror.
<infinity> Loved that I got 24Mb/s from it.  Hated that it was always about 3.5 months out of date.
<infinity> (That may be hyperbole)
<RAOF> Internode's *generally* reasonably up to date.
<infinity> Well, I only just fixed everything.  Being out by 30-60m seems acceptable.
<ajmitch> 3.5 months sounds a lot like some NZ mirrors
<infinity> My ISP's mirror here is lousy too, which is (one reason) why I just run my own.
<mwhudson> i just use a.u.c :(
<infinity> GigE to an internal mirror versus transatlantic link of ick that goes through a tiny router driven by a sickly hamster in the Netherlands...
<infinity> I'll take the local mirror.
<mwhudson> how quickly you forget the southern hemisphere :)
<infinity> mwhudson: Thankfully, yes. ;)
<infinity> robert_ancell: *poke, poke, poke, poke*
<superm1> SpamapS: curious on your thoughts.  what about adding a dpkg trigger when new tzdata packages get installed to load the time zone data into mysql?  eg http://dev.mysql.com/doc/refman/4.1/en/mysql-tzinfo-to-sql.html
<robert_ancell> infinity, hey
<robert_ancell> infinity, so are we updating to quantal or quantal-proposed now?
<ihashacks> Where might one go to report an error in the release blog? http://release-blog.ubuntu.com/?p=213
<ihashacks> "Ubuntu 12.04 (Quantal Quetzal) Alpha 1 now available"
<RAOF> Man. It took me three goes to work out what was wrong there :)
<psusi> the numbers do sort of blurr together when you've been around for a while ;)
<ihashacks> I guess since this next one isn't a "Pixel Perfect" release, details like that are negligable :-P
<psusi> jesus... seems like a long way from 6.06 to 12.04, but feels like it was only yesterday
<ihashacks> But, seriously, given that the blog isn't even "Ubuntu branded" I'm not sure anyone will even notice (although I did).
<ihashacks> I just wanted to see who/how to notify so that it could be fixed.
<cody-somerville> lol
<cjwatson> ihashacks: I have access to that blog, but I don't seem to be able to edit other people's posts, so can't fix it directly.
<cjwatson> skaet: ^- Please fix http://release-blog.ubuntu.com/?p=213 to say 12.10 rather than 12.04
<cjwatson> (Both heading and body text)
<SpamapS> superm1: seems like a pretty cool idea
<SpamapS> superm1: Will have to think of what the ramifications might be, but all in all I think it would be a nice feature
<skunk> cnd: are you there?
<dholbach> good morning
<didrocks> infinity: thanks for the unity upload. We are still fighting for a week on unity. I tried to port to boost, fix the build issues with gcc4.7, same code base, rebuilt libsigc++ with the quantal stack, and we still get some random crash at runtimeâ¦
<dholbach> StevenK, happy birthday! :)
<jamespage> Sweetshark, ping re libreoffice and switching dependencies from openjdk-6 to openjdk-7
<Sweetshark> jamespage: pong, huh?
<jamespage> Sweetshark, so I've been gradually shuffling through all of the dependencies on openjdk-6 in main
<jamespage> libreoffice is one of the last two :-)
<vibhav> Can anybody have a look at https://bugs.launchpad.net/ubuntu/+source/rofs-fuse/+bug/1010357 ?
<ubottu> Launchpad bug 1010357 in rofs-fuse (Ubuntu) "Please merge rofs-fuse from Debian Unstable" [Undecided,New]
<Sweetshark> jamespage: well, im doing a libreoffice-3.6.0~beta1 upload (to ppa only right now). I guess there is enough trouble in a beta in itself to not mix in a java update. we could then upload a package just with the java update to see how much fun it breaks.
<jamespage> Sweetshark, that would be great!
<Sweetshark> jamespage: that being said, I cant do ~anything on quantal right now because of bug 1007616
<ubottu> Launchpad bug 1007616 in gcc-4.7 (Ubuntu) "gcc internal compiler error in force_move_args_size_note, at combine-stack-adj.c:419" [High,New] https://launchpad.net/bugs/1007616
<micahg> Sweetshark: you can build with gcc 4.6 until that's fixed (and should)
<micahg> jamespage: is there a release goal for quantal to drop openjdk-6 entirely?
<jamespage> micahg, hmm - I'd like to but I think it more likely it will reside in universe for 12.10
<jamespage> I think there will be some packages in universe we simply cannot transition at this point in time
<micahg> jamespage: depending on what and how many, we could just drop and backport from R
<jamespage> micahg, I think we can make a call on that later in the cycle depending on progress
<micahg> yep
<micahg> jamespage: if you have a guide for openjdk 7 porting, that might be good for MOTU opportunistic tasks
<Sweetshark> micahg: oh, it seems I do now. I magically appeared in my rebase on debian after I told _rene_ about it ...
<jamespage> micahg, emailed wed - https://lists.ubuntu.com/archives/ubuntu-motu/2012-June/007250.html
<micahg> jamespage: ooh, thanks (I must have missed that)
<vibhav> jamespage: Could you link me to the munin bug that I had to test?
<jamespage> vibhav, sure - https://bugs.launchpad.net/ubuntu/+source/munin/+bug/1000678
<ubottu> Launchpad bug 1000678 in munin (Ubuntu Precise) "[SRU] munin-memory plugin doesn't work on 64-bit 12.04 LTS" [Medium,Fix committed]
<jamespage> much appreciated
<jamespage> vibhav, as you seem to be very active with SRU's you might like these reports - http://people.canonical.com/~jamespage/server-sru/
<vibhav> sure
<vibhav> jamespage: Im getting http://paste.ubuntu.com/1030072/ , is that fine?
<jamespage> vibhav, for a restart yes - but you need to check that the memory graph appears in the web interface to verify the SRU as per the test plan
<vibhav> jamespage: From where can I reach the web interface
<jamespage> vibhav: you should be able to see it on http://hostname/munin
<vibhav> jamespage: would my.ip/munun work?
<jamespage> vibhav, should do yes
<doko__> Sweetshark, I would appreciate a bit more cooperation with issue 1007616, more than trowing mismatching bits over the fence
<Sweetshark> doko__: what exactly do you need?
<doko__> Sweetshark, do didn't build with 4.7, but with 4.6
<Sweetshark> doko__: right, I have no quantal host right yet, as it is madness to try building LO on it at this point. But does the (4.6)-preprocessed stuff magically work now? If not, why cant you go hunting with it?
<doko__> Sweetshark, so this neither built with 4.7 nor on quantal? what are you reporting then?
<doko__> 1) On quantal
<doko__> 2) with gcc-4.7-base i386 4.7.0-11ubuntu2
<doko__> and no, I don't think it's madness after alpha1
<Sweetshark> doko__: no, it doesnt build on 4.7 on quantal. It does build on 4.6 on precise. Thats it so far. Couldnt you do me the favour of throwing the (4.6/precise)-preprocessed input at 4.7/quantal quickly and see if it suicides gcc?
<doko__> Sweetshark, it doesn't work this way. I need the preprocessed source with the 4.7 headers, not the 4.6 ones. sorry if that wasn't clear
<Sweetshark> I will start to get my quantal pbuilder ready soon, but right now, I am still at getting 3.6.0~beta1 to build at all ...
<Sweetshark> doko__: doh, I ignored that the headers are also compiler-dependant, yeah. ignorance is a bliss.
<Sweetshark> doko__: I will try to get you a 4.7-preprocessed source one ASAP. Might take a while to get the pbuilder up though ...
<xnox> Sweetshark: spin up a beefy machine on amazon cloud with quantal's alpha1 image and do a build there?
<xnox> just to get the preprocessed source which fails
<Sweetshark> hm, interesting something of starting virtualbox and unplugging the AC under some load was not appreciated by this machine ...
<Sweetshark> OOM killed itself with a load average of >2000.
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox
<xnox> there are a couple of merge proposal's for usb-creator which are acient =)
<ogra_> merge them into an ancient branch then :P
<xnox> ogra_: haha =) I have lp:usb-creator commit rights so I will merge them into bleeding-edge branch =)
<ogra_> evil, that might scare them :)
<seb128> xnox, did you pick up usb-creator maintenance?
<xnox> seb128: well ev is still the usb-creator overlord. Do you have anything in particular, that I can do as usb-creator's minion?
<ogra_> seb128, well, after today he might be the last uploader :) we just need to make sure it stays that way
<ev> xnox: I'm more than happy to pass the baton on that one
 * xnox baton! baton!
<ev> I've got way too many error tracker work items to give usb-creator any attention beyond code review
 * xnox is reminded of Up!
<seb128> xnox, no, mostly curious, we (desktop) were wondering if there was still any work going on it, especially that we go out of the CD size this cycle usb-creator might get an increased importance ... we were wondering if there was any design or tech work planned on it
<seb128> ev, ^
<xnox> I needs a refresh, yes =) but it does do the job out the box
<xnox> s/I/it/
<seb128> xnox, still it could do with some ui tweaks and some work
<superm1> a few UDS's ago there was a session with discussion about things to improve with it that didn't all happen
<ev> seb128: I didn't have anything planned. If there are specific needs, best to raise them with slangasek and then he can delegate
<superm1> maybe brussels?
<seb128> xnox, I was mostly wondering if anyone planned on that to not dup work if we plan to look at helping on it
<ev> oh, that would be ace
<seb128> ev, having design input would be nice, then we could probably help
<ev> superm1: I vaguely recall that being the location
<seb128> but I guess that's rather a mpt's question
<ev> seb128: yeah, Matthew would be excellent for that when he's back from holiday
<ev> as he designed the initial UI
<seb128> ev, ok, so nothing done yet, I will check with him when he's back, thanks
<ev> seb128: sure thing!
<superm1> so if that old gobby doc is somwhere on the interwebs that might be a good starting point too
 * ev lunches
<xnox> superm1: please find it, it's before my time =)
<seb128> xnox, you are supposed to get the knowledge of everything that happened in the past when joining!
<xnox> seb128: I'm doing my best =) i have already picked up a lot, just not everything yet.
<seb128> ;-)
<xnox> I still get a twich when people mention 'oh yeah we fixed that in dapper'
<superm1> xnox: actually you were in the IRC that day it looks: http://ubottu.com/uds-logs/archives/uds-m/%23ubuntu-uds-cocobolo-3.log
<xnox> lol =)
<superm1> gobby.ubuntu.com doesn't seem to respond to me
<superm1> but http://paste.ubuntu.com/433382/ was captured before it crashed at some point during the IRC log
<xnox> superm1: I think that got super-seeded by the amd64+mac iso
<ogra_> seb128, we sadly forgot to give him the usual "La fusion mentale vulcaine" for new team members in SF when he joined
<ogra_> -La i guess ...
<seb128> lol
<xnox> ogra_: "sometimes the recipient is supposed to be consenting if the merger may be experienced as a rape ."
<xnox> http://fr.wikipedia.org/wiki/Fusion_mentale
 * xnox *shrug*
 * xnox moving on...
<ogra_> you didnt read the fineprint in your contract, eh ?
<xnox> ogra_: it does say "If ogra_ is speaking about you, using french terms, imediately report to your line manager."
<ogra_> lol
<xnox> superm1: https://wiki.ubuntu.com/DmitrijsLedkovs/usbcreatornotes#preview
<ev> wow, and xnox is already speeding through usb-creator merge proposals. Rock on.
<ev> xnox: on the automated tests front, do check out the usb gadget module in the kernel. It will let you write system tests without having to plug in a physical usb device.
<ev> in response to your wiki page
<xnox> ev: this ^^^ =) amazing, will look into that.
<ev> awesome
<vibhav> jamespage: ping
<jamespage> vibhav, hey!
<vibhav> jamespage: getting http://paste.ubuntu.com/1030293/ Is that fine?
<jamespage> vibhav, not sure - is that coming from munin-node?
<vibhav> No idea
<vibhav> I cant browse to 192.168.1.243/munin
<vibhav> /window/window 28
<scientes> DinstallException: 'Unknown distribution "unstable" in "/var/cache/archive/mini-dinstall/incoming/kyotocabinet_1.2.76-1_amd64.changes"'
<scientes> im trying to use mini-dinstall
<scientes> for cowbuilder
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<vibhav> Murphy's Law :(
<seb128> could somebody reject https://code.launchpad.net/~mattmollett/ubuntu/oneiric/inkscape/fix-for-807861/+merge/109318 ?
<Sweetshark> doko__: bug 1010468 now has everything you need.
<ubottu> Launchpad bug 1007616 in gcc-4.7 (Ubuntu) "duplicate for #1010468 gcc internal compiler error in force_move_args_size_note, at combine-stack-adj.c:419" [High,Incomplete] https://launchpad.net/bugs/1007616
<vibhav> what does ld --as-needed exactly do to fix FTBFSes?
<xnox> vibhav: it adds extra libraries to complete the linking
<xnox> vibhav: http://wiki.debian.org/ToolChain/DSOLinking
<vibhav> xnox: Is it applicable in debian too?
<xnox> yes.
<ogra_> (given the doc is on the debian wiki... )
<xnox> it's not enabled by default, as far as I know, but the bugs themself are RC
<xnox> vibhav: we want to use ld --no-as-needed by default =)
<xnox> or the gold linker
<vibhav> xnox: But why do some packges have a ubuntu delta which use ld --as-needed ?
<vibhav> Instead of forwarding them to debian?
<ogra_> slackish developers ?
<xnox> vibhav: because we needed the package to build and adding --as-needed is not a proper fix
<xnox> you generally have to modify autoconf/autotools/makefiles to add/remove required libraries in the correct order for the --no-as-needed link to succeed.
<cjwatson> Uh, generally the Ubuntu delta is to tolerate a linker that defaults to --as-needed
<cjwatson> Not to change ld's options to use --as-needed
 * xnox says listen to cjwatson =)
<cjwatson> We don't want to use --no-as-needed by default - that's backwards
<cjwatson> See https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
<cjwatson> Or better, http://wiki.debian.org/ToolChain/DSOLinking
<cjwatson> (Ah, which xnox linked to above)
 * xnox got the --no-as-needed and --as-needed backwards. --no-as-needed is bad as it's a workaround to revert to old/classic behaviour.
<xnox> sorry
 * xnox use gold, gold rocks =)
<cjwatson> Shouldn't really need to nowadays
<cjwatson> I was under the impression most of the gains there had been got by our default linker option changes
<cjwatson> vibhav: The answer to why we have these as Ubuntu deltas is indeed generally just that nobody's got round to forwarding them yet, or they've been forwarded and not yet applied upstream of us
<vibhav> ah
<vibhav> ^^ was the answer I wanted
<vibhav> thanks cjwatson
<rbasak> "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" - is there a way to override this? I'm preparing an SRU so presumably I want to leave that alone.
<cjwatson> rbasak: Temporarily set DEBEMAIL to something that isn't @ubuntu.com when you run debuild -S
<rbasak> cjwatson: interesting! Thanks :)
<cjwatson> (You'll still get a warning, but it'll be downgraded from an error)
<rbasak> That worked. But I just realised that this SRU is for a package without a previous ubuntu delta, so actually the error is right and I think I do want to run update-maintainer on it.
<cjwatson> Agreed.
<Sweetshark> cjwatson: since you raised your head on "--as-needed", could you shed some light on http://nabble.documentfoundation.org/make-check-problem-in-libtest-smoketest-building-master-td3902404.html#a3905049 ?
<rbasak> Thanks. I'll pay more attention to the changelog in future.
<didrocks> bdmurray: hey, are you running a script for dup detection? There are some wrong test cases in bug #1010239. In addition, if I deduped, your script reduped it
<ubottu> Launchpad bug 1010239 in oneconf (Ubuntu) "oneconf-service crashed with OSError in _get_current_wallpaper_data(): [Errno 2] No such file or directory: '/usr/share/backgrounds/Floorboards_by_Dawid_Huczy%C5%84ski.jpg'" [High,Fix released] https://launchpad.net/bugs/1010239
<Sweetshark> cjwatson: esp. with regards to "Fedoras implicitDSO is sane, what Debian/Ubuntu does is not" ...
<didrocks> bdmurray: but the first dup was wrong: it's crashing calling the same functions, but the stack is different and the first bug was "fixed released" in september 2011. So dupping it shouldn't happen for regressions anyway
<cjwatson> Sweetshark: Not really, -> doko
<cjwatson> Though from that thread it sounds like you probably just want to add --no-as-needed to LDFLAGS or similar and get on with your life
<cjwatson> We're not going to revert the toolchain change again, AFAIK
<Sweetshark> cjwatson: ;)
<cjwatson> We reverted it for natty because it broke too many things, but enough of them were fixed for oneiric that we were able to leave it on; it has substantial global benefits and it makes sense for us to have it as a default and for the small minority of packages that can't cope to deal with it
<Sweetshark> cjwatson: I dont have a problem with release builds (I reordered some lib or did --no-as-needed), but it is highly annoying for new contributors who cant compile an unpatched LibreOffice once in a while ...
<cjwatson> If LO assumes --no-as-needed I don't see why they can't just add that
<cjwatson> Having it on by default in the distribution makes it much easier for us to avoid problems with excessive indirect linking
<cjwatson> And in any case I don't believe we're the only ones - OpenSUSE did this before us, I think
<Sweetshark> cjwatson: LO depends on --no-as-needed being the default, but locks down to --as-needed in some places IIRC.
<cjwatson> It's silly of them to depend on that but refuse to be explicit about it.
<Sweetshark> cjwatson: having said that, it currently works, but some unsuspecting commit from other distro might break it again once in a while causing some useless discussion then ...
<seb128> could somebody reject https://code.launchpad.net/~mattmollett/ubuntu/oneiric/inkscape/fix-for-807861/+merge/109318 ?
<jamespage> vibhav, can you take me through what you have done so-far?
<vibhav> jamespage: Are you talking about munin?
<jamespage> vibhav, yes - sorry - a bit async + lag today
 * xnox_ smuxi fail =(
<vibhav> jamespage: I still cant get to 192.168.1.243/munin
<vibhav> And the log is the same
 * vibhav suspects its something to do with his desktop
<vibhav> Could you try it on your computer?
<jamespage> vibhav, I can - are you following the test case in the SRU?
<vibhav> jamespage: yeah
<jamespage> vibhav, OK - lemme take a look
<vibhav> thanks
<jamespage> vibhav, OK I tweaked the test plan slightly - all you should need todo is install the packages - just tried it on a fresh install and it worked fine
<jamespage> can see memory data and everything
<bdmurray> didrocks: it was an old bug pattern that was causing the duplicate detection.  I'll look at cleaning up old ones.
<\sh> moins
<didrocks> bdmurray: thanks!
<vibhav> jamespage: So the verification is done?
<vibhav> Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/rootskel/+bug/1010506 ?
<ubottu> Launchpad bug 1010506 in rootskel (Ubuntu) "Please merge rootskel from debian unstable" [Undecided,New]
 * xnox hates bug 762193
<ubottu> Launchpad bug 762193 in xchat (Ubuntu) "No launcher icon or Alt+Tab entry for xchat/xchat-gnome windows" [High,Triaged] https://launchpad.net/bugs/762193
<cjwatson> vibhav: You should ask the person who touched the package last before merging stuff
<cjwatson> vibhav: In the case of rootskel it's much harder to apply a debdiff than to just do the merge in our bzr branch
<cjwatson> And your changelog is wrong - would you mind awfully if I just did this myself? :-)
<cjwatson> vibhav: FWIW I hadn't bothered to merge rootskel because the changes in that Debian upload have precisely zero effect on Ubuntu
<jamespage> vibhav, not really - I did the fix :-) I want someone else to check my work....
<seb128> xnox: do you get that bug often? I never saw it and I use xchat-gnome every day
<seb128> xnox: do you use the SRU version of unity?
<xnox> seb128, i am enjoying it *right now* on quantal =) with xchat-gnome with the xchat-gnome-indicator
<seb128> xnox: i.e did you restart since 5.12-0ubuntu1.1
<seb128> xnox: quantal didn't have the SRU fixes until recently, it was failing to build with the new toolchain, then they did hit a segfault due to c0xx behaviour change with signal they just tracked down today
<xnox__> seb128, so xchat & xchat-indicator work like a charm. xchat-gnome & xchat-gnome-indicator are borked for now. Let me upgrade 200 packages (3 minutes)
<seb128> ok
<seb128> xnox__, you probably have an unity update in those packages?
<vibhav> cjwatson: Sure! Go ahead
<ritz> xnonx_ seb128 will probably roll in the indicator into the main package itself
<ritz> wrt xchat-gnome
<seb128> ritz, you will do that upstream for it?
<ritz> yes, need to rewrite the converstaion panel into something more modern. Will be checking up on webkit this weekend
<seb128> ok
<ritz> once this is done, plan to ensure a higher degree of ubuntu integration
<xnox> ritz: yes please =) and no assumptions that 'minimise to tray' is (a) available (b) is the right thing to do
<ogra_> ++
<ritz> no more minimise to tray
<ritz> not a valid concept in gnome shell
<ritz> and for unity, I prefer the close window to hide the client
<ritz> xnox , again , this is my belief . If you feel otherwise, feel free to post to https://live.gnome.org/Xchat-Gnome
<ritz> pretty much a very rough draft
<xnox> ritz: hiding is fine =) as long as the icon stays in the unity dash and the alt-tab
<ritz> hmmm
<ritz> interesting. I was thinking more along the lines of emapthy
<xnox> ritz: i see. close to hide and no icon in dash. minimise to hid and have icon in the dash. would work for me. but's it's just me. I have IRC full screen and open anyway and I switch between  different apps
<dobey> not cool
<ogra_> warm then ?
<barry> stgraber: i'd like to upload the pydbus fix for bug 1008898 now.  will you revert the ubiquity workaround once that lands?
<ubottu> Launchpad bug 1008898 in ubiquity (Ubuntu Quantal) "crash after inserting wireless password" [High,Fix released] https://launchpad.net/bugs/1008898
<dobey> ogra_: trolls are proabbly cold blooded. and don't know why else you'd get that many Excess Flood kills :)
<ogra_> heh
<ogra_> well, your client should allow you to ignore join/part if it really annoys you
<stgraber> barry: yep, I can do that. Having the fixed python3-dbus won't break ubiquity anyway but we certainly shouldn't keep the hardcoded signature :)
<barry> stgraber: :)
<barry> stgraber: uploaded
<dobey> ogra_: i'm sure it does, but then i'd also miss seeing the ones i care about :)
<ogra_> heh, yeah
<ogasawara> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara, infinity
 * infinity hopes ogasawara doesn't push him out of the topic.
<ogasawara> infinity: heh, it wouldn't be the first time I've pushed you
<infinity> ogasawara: That was my point entirely.  Meanie. ;)
<ogra_> infinity, well, at least she doesnt steal your pings !
<ogasawara> man, rough crowd today! :)
<ogra_> :)
<infinity> ogra_: That kinds seems like a feature.
<infinity> ogasawara: You're welcome to steal my pings anytime.
<ogra_> its also the "thank you " ones !
<infinity> ogra_: No one ever says that to me.
<ogasawara> heh
<ogra_> ogfinity, thank you !
<ogfinity> ogra_: Note that "gee, thanks" isn't actually the same as "thank you".
 * Sweetshark lols at backlog.
<cr3> is there a plan to remove perl from the desktop image during the quantal cycle?
<slangasek> cr3: no... are you expecting there to be?
<cr3> slangasek: I thought I'd heard something to that effect, just checking whether it was my imagination :)
<slangasek> cr3: you may have misheard 'python2' as 'perl'?
<cr3> slangasek: nah, that one is already well underway on my side. by the way, I vaguely recall there being a 2to3 sprint of some sort either next week or the week after, is that my imagination again?
<slangasek> we're having a virtual sprint next week in #pyjam
<slangasek> Mon-Wed
<cr3> slangasek: cool, most of checkbox was converted to python3 this week. would it help if I pushed those changes in ubuntu as early as possible?
<slangasek> cr3: in the general release-early-and-often sense, yes
<slangasek> we're certainly ready to receive python3 apps on the desktop in quantal
<cr3> slangasek: I was wondering more in the pyjam sense. there are a few standalone scripts that haven't been converted yet, but all the core of the project has been converted. so, perhaps being able to calculate the overall dependencies of the desktop image with one more app converted might be useful
<cr3> s/overall dependencies/overall python 2 dependencies/
<slangasek> cr3: the list of todos is still long enough that it's unlikely to register :)
<cr3> slangasek: ok, I'll try to push the changes in the release-early-and-often sense then :)
<cr3> someone in the core devs is not going to be happy reviewing the mega changes :0
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara
 * infinity stops maintaining the fiction that he's piloting, when the piloting he's doing will go into the weekend with glibc upstream...
<xnox> infinity: well done =)
<infinity> xnox: Yeah, I do so love it when I pick bugs to work on that make me don a community hat over the weekend. :P
<infinity> xnox: At least I won't be bored, right?
<xnox> true =)
<hippiehacker> Is there anything newer than https://help.ubuntu.com/community/LiveCDCustomizationFromScratch for creating 12.04 iso's from scratch? Is it still pretty much the same process?
<xnox> hippiehacker: better suited for #ubuntu-installer but yeah I believe that still more or less the same.
#ubuntu-devel 2012-06-09
<hippiehacker> xnox: thanks
<fastway> where can I find info about isolinux.cfg used on live cd (12.04)? Mainly how "maybe-ubiquity" is appended on boot parameters. Thanks
<ogasawara> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<vibhav> cyphermox: ping
 * vibhav marvels at dget
<pp7> how do i change the color of my panel (not launcher)?
<erappleman> slangasek, what's the best way to get around the lack of "co-installable -dev packages"? i'm not familiar with chroot or pbuild. would a 32-bit vm suffice for building stuff like wine?
<RAOF> erappleman: That'd work fine, but is a bit of overkill.
<RAOF> Installing ubuntu-dev-tools and running âmk-sbuild --arch=i386 quantalâ will net you an i386 schroot.
<erappleman> hmm thanks
<vibhav> jamespage: ping
<vibhav> infinity: ping
<vibhav> Any idea why libvoikko was built with dh_python2 in ubuntu?
<vibhav> doko__, doko_ : ^
<cjwatson> vibhav: We don't want either of the old python helpers (-central or -support) in main - we went to some effort to consolidate on one
<vibhav> ah wait, libvoikko is built with dh_python2 in debian too. We could have a sync now
<vibhav> cjwatson: https://bugs.launchpad.net/ubuntu/+source/libvoikko/+bug/1010907
<ubottu> Launchpad bug 1010907 in libvoikko (Ubuntu) "Sync libvoikko 3.4.1-1 (main) from Debian sid (main)" [Undecided,New]
<cjwatson> Sure
<vibhav> thanks!
<vibhav> micahg: you there?
<vibhav> cjwatson: Thanks! (again)
<vibhav> cjwatson: If you are not busy, could you have a look at https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/1010920 ?
<ubottu> Launchpad bug 1010920 in libvdpau (Ubuntu) "Please merge libvdpau (main) from Debian Unstable (0.4.1-6)" [Undecided,New]
<_pants> How do you programmatically make something run at login in Ubuntu (preferably both in Gnome and Unity)? I tried searching docs first and didn't turn anything up.
<_pants> mdz: do you know, by chance? ^
<maxb>  /etc/xdg/autostart/ ?
 * _pants looks
<_pants> Thanks, maxb. That's odd though, I'd expect these to be defined per-user.
<maxb> _pants: ~/.config/autostart/
<_pants> ah, that's the ticket
<_pants> thanks
<_pants> maxb: So to have a setting in my application the user can toggle to launch it on startup, is all I have to do to add or remove a corresponding .desktop file in the user's ~/.config/autostart directory?
#ubuntu-devel 2012-06-10
<hippiehacker> https://gist.github.com/2903267 # any further direction on how to build the official live/install ... I'm generating an iso that's missing a few files
<vibhav> https://launchpad.net/debian/+source/libao/1.1.0-2 <-- I did not get this changelog
<elky> vibhav, looks like someone's taking over the maintenance for it and being cute about it.
<vibhav> haha
<vibhav> I still did not get "accept the only sensible course of direct action that remains to preserve sanity."
<elky> probably an in-joke
<elky> some people do funny things in changelogs and significant commits. it makes the game more fun.
<vibhav> ah
<elky> i think it's openwrt that puts a cocktail recipe in the changelog at each release
<vibhav> Yes
<vibhav> elky: It displays a cocktail recipe even when I log into my router
<vibhav> via ssh
<SpamapS> there was a great haiku in one changelog
<vibhav> SpamapS: where?
<benonsoftware> One Canonical dev I think once put what song they were playing in their bzr commit
<elky> There needs to be a website to catalogue epic commit messages. I could have sworn there was one, but I cannot find it now :(
<micahg> vibhav: now I am
<vibhav> micahg: YOu still there?
<micahg> vibhav: yeah
<vibhav> micahg: AFAIK, you were the last person to touch libav-extra in Ubuntu,  Can I prepare A merge for it?
<micahg> vibhav: no need
<vibhav> micahg: why?
<micahg> vibhav: it's gone from Debian and there hasn't been a libav update
<vibhav> ah
<vibhav> fine
<micahg> we're discussing what to do with libav now that gegl needs it
<vibhav> Can anybody have a look at https://bugs.launchpad.net/ubuntu/+source/bogl/+bug/1011081 ?
<ubottu> Launchpad bug 1011081 in bogl (Ubuntu) "Please merge bogl (0.1.18-8) (main) to Ubuntu quantal (main)" [Undecided,New]
<vibhav> jamespage: ping!
<jtaylor> can a package be split between universe and main?
<vibhav> like?
<debfx> jtaylor: a source package in main can have binary packages in main and universe (but not the other way around)
<vibhav> Do you mean, a part of the package in main and other in universe?
<jtaylor> yes
<jtaylor> the issue is fftw3
<jtaylor> it now depends on mpi in debian which is not in main
<jtaylor> build-depends
<jtaylor> people want the mpi in ubuntu too
<jtaylor> but that would require some splitting
<jtaylor> or moving mpi to main (which I guess is not likely)
<penguin42> fftw3 gets used by a whole bunch of things which is unfortunate
<jtaylor> yes moving it out of main is probably unfeaseble too
<jtaylor> would it make sense to build a second source package from the original in universe
<penguin42> jtaylor: So what's the problem with moving libopenmpi to main?
<jtaylor> convincing people to support it?
<jtaylor> also mpich2 might also be needed in future
<jtaylor> moving two mpi implementations to main because a *library* needs it is quite weak reasoning
<jtaylor> afk 15 min
<penguin42> jtaylor: Does fftw3 use mpi in normal cases or is it just that it *can* use mpi?
<jtaylor> penguin42: it can use mpi
<jtaylor> or pthreads or omp or none
<jtaylor> the new package also adds avx and neon support
<jtaylor> something we definitely want in ubuntu at some point
<penguin42> jtaylor: If you had two versions, one that used MPI and one that didn't would the programs that used it have to be linked differently or would they just pick up whatever it used?
<jtaylor> it are separate libraries
<jtaylor> the mpi ones are basically thin wrappers around the main one
<penguin42> and how do you choose which to use?
<jtaylor> by linking against it
<jtaylor> -lfftw3{,f,l} for the normal one -lfftw3{,l,f}-omp for omp etc
<penguin42> oh that's annoying, if it was that apps just used which ever was the best-for-the-system then you could just have 2 package versions
<jtaylor> it is such an app
<jtaylor> but its not applicable to mpi and stuff
<jtaylor> it uses sse or avx depending on the system
<penguin42> yeh
<penguin42> are there many packages dependent on the MPI version yet?
<jtaylor> none
<jtaylor> its new in debian
<jtaylor> there is one needing threads
<jtaylor> and one optionally using omp
<jtaylor> (also new)
<penguin42> omp?
<jtaylor> openmp
<penguin42> ah
<penguin42> yeh so it does sound like you want a split where the mpi bits are in a separate package
 * vibhav waits for jamespage 
<Daviey> ScottK: Hey, are you looking into pyyaml's dep wait?
 * micahg wonders if Daviey reads ubuntu-devel
<Daviey> micahg: not since 14:58:50 UTC 2012
<micahg> Daviey: that's when the message was sent with no responses yet :)
 * Daviey leaves it on his todo to respond tomorrow
<apachelogger> siretart: https://bugs.launchpad.net/ubuntu/+source/kdegames/+bug/1011310/+activity did you change that manually?
<ubottu> Launchpad bug 1011310 in kdegames (Ubuntu) "package kdegames-card-data-extra 4:4.8.3-0ubuntu0.1 failed to install/upgrade: trying to overwrite '/usr/share/kde4/apps/carddecks/svg-oxygen-air/11.png', which is also in package kdegames-card-data 4:4.8.3-0ubuntu0.1" [Undecided,New]
#ubuntu-devel 2013-06-03
<TheLordOfTime> you guys treat this like any feature request bug, right?  https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1186754
<ubottu> Launchpad bug 1186754 in ubuntu-themes (Ubuntu) "Use icon theme for starred icons" [Undecided,Opinion]
<TheLordOfTime> it came up in privmsg with someone asking if it should be marked as "wishlist" / "triaged" as a feature request
<infinity> TheLordOfTime: The triager who decided it wasn't a bug seems a bit overzealous.
<infinity> TheLordOfTime: jbicha made some fair points as to why this change might be a good thing (consistency, reduced complexity).
<TheLordOfTime> infinity:  agreed on the overzealousness we're addressing that now
<TheLordOfTime> infinity:  my main question was whether you'd treat it as a feature request :)
<TheLordOfTime> at least, as the devs.
<infinity> TheLordOfTime: Wishlist certainly seems more valid than Opinion.
<TheLordOfTime> infinity:  that's what i thought, but i don't want to tweak "upstream project" statuses.
<TheLordOfTime> infinity:  no harm in setting the upstreams back to "new" as they were and let upstream change those bugs' statuses, right?
<infinity> TheLordOfTime: Seems fair.
<infinity> I'm not even sure why "opinion" exists, except to make people not feel bad by setting bugs to "invalid".
<TheLordOfTime> i agree
<TheLordOfTime> TBH i think 'Opinion' should be bugcontrol only
<TheLordOfTime> because i see it occasionally abused :/
<infinity> I might start filing all my bugs as "opinion" and starting all the descriptions with "It is my opinion that..."
<infinity> eg: "It is my opinion that this shouldn't segfault when I start it."
<TheLordOfTime> heh
<TheLordOfTime> infinity:  objections to Wishlist/Triaged which is afaict the usual standard for feature requests in the ubuntu packages?
<TheLordOfTime> since i specialize in server packages, i like double checking on packages outside that specialization before messing with em :p
<infinity> TheLordOfTime: Nope, seems fine to me.  If the desktop team or s-c hackers decide it should be something else, they can change it.
<TheLordOfTime> infinity:  indeed, done btw.
<TheLordOfTime> i'm going to go back to facedesking over the fact that nginx FTBFS on centos with the same command line options as nginx-full has in ubuntu >.<
<pitti> Good morning
<pitti> slangasek: what was broken in particular about 0010-Add-back-support-for-Debian-specific-config-files.patch ? all the {time,hostname,locale}ctl commands were working, now timedated is broken (see failing autopkgtest)
 * pitti checks the difference
<slangasek> pitti: missing support for /etc/default/keyboard, which is where our keyboard settings are stored
<pitti> ah, thanks
<slangasek> pitti: hadn't seen the failing autopkgtest yet, sorry - are you going to sort that today, or should I have a look in the morning?
<pitti> slangasek: I can sort it out today
<slangasek> ok
<pitti> slangasek: I'd rather restore Debian's patch and do our's as a new patch on top of it if you don't mind, for easier merging
<pitti> and I have a proposed fix for smb's crash
<slangasek> pitti: as you prefer.  any sign yet of mbiebl's branch being pushed to the official packaging branch?
<pitti> not yet :(
<slangasek> strange that timedated would be failing, I thought the patches I changed only touched localed
<pitti> no, also src/timedate/timedated.c
<pitti> hm, I'm not sure whether Debian also uses /etc/default/keyboard; mbiebl, do you know?
<pitti> we did quite some work on that on the ubuntu side AFAIR
<slangasek> I haven't checked to be sure, but I'm almost positive that's in sync with Debian
<smb> pitti, Moin. I will be in a state to test things (or even look at them) in a min or so
<pitti> smb: ah, the amd64 systemd build in my PPA should finish in a few mins, too :)
<smb> heh :)
<pitti> smb: thanks for your investigations; I think I see the race condition with 0024-avoid-exit-deadlock-for-dm_cookie.patch, which also explains why it doesn't crash without that patch
<smb> pitti, Ah ok. I did not get to a good explanation last week. There was (or is) a difference in the way that "force" was able to raise the number of childs but then I never remembered having seen messages about that
<pitti> that patch basically keeps the worker running for a DM_COOKIE event, despite having been told to stop
<pitti> I still don't quite understand why we need this, but you confirmed that you are still missing /dev/mapper/ devices without the patch
<pitti> in theory, this hack of a patch shouldn't be necessary, as /etc/init/udevtrigger.conf should re-trigger all devices (for non-root partitions), and the initramfs already waits for the root partition to appear
<smb> Yeah, the missing links seem independant, but as you said in the bug report (which I am slowly reading) lets first fix the crash and then look for the rest
 * smb reached the bottom and prepares to boot the noisemaker
<pitti> smb: I think missing the links is exactly what that patch was supposed to fix?
<pitti> smb: https://launchpad.net/~pitti/+archive/ppa/+build/4637729 -> done :)
<smb> It should, but strangely I got the missing links also when booting non-xen which most of the time did not run into the crash
<pitti> smb: but after that, perhaps we can boot your version without the patch again, and see why /etc/init/udevtrigger.conf doesn't create the missing devices
<smb> sure we can
<dholbach> good morning
<infinity> pitti: BTW, ddebs are very close to landing now.  Could you have a chat with wgrant to nail down what you'll need to change in your mirror scripts to make ddebs.u.c love the new world order?
<pitti> \o/
<pitti> wgrant: I guess I primarily need some API to retrieve the (links to the) recent ddebs, where "recent" should mean something like "from the last day" or "from the last 6 hours"
<infinity> pitti: I was thinking you might want to do something more clever like backtrack from current Packages/Sources and scrape (and keep a cache, so you don't keep retrying ones that don't have ddebs attached).
<pitti> wgrant: but I guess that might actually be similar/the same one as for the static translation tarballs?
<pitti> such as in http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/lib/static_translations.py
<wgrant> pitti: They're not custom uploads, so not quite the same as that
<pitti> infinity: yeah, or that; mapping a source plus version to a set of ddeb links then
<wgrant> I'd either scrape from Packages or just follow getPublishedBinaries
<pitti> wgrant: so they are part of getPublishedBinaries(), they just don't appear on archive.u.c.?
<StevenK> RIght.
<infinity> pitti: Well, more likely Packages than Sources, I guess, since ddebs are attached to binaries.
<wgrant> lp.distros['ubuntu'].main_archive.getPublishedBinaries(created_since_date=last_check_etc)
<smb> pitti, Ok, I need to do more reboots for a qualified result. This first one with the ppa udev version at least had no crash and all 31 lvs of the second vg but none of the first one.
<wgrant> pitti: Exactly
<wgrant> pitti: They're published like normal binaries, except that they don't actually hit disk or appear in the indices.
<StevenK> pitti: And then you can filter by .is_debug
<pitti> ok, then mapping by published ones seems fine
<infinity> pitti: This should have the positive effect of ddebs.u.c no longer carrying cruft from PPAs, too.
<pitti> exactly
<infinity> pitti: Anyhow, we plan to do a soft transition where we upload via .changes and keep publishing tarballs to public_html, but I want the latter to go away as quickly as it can.
<shadeslayer> infinity: :O ... we're going to get ddebs? :O
<StevenK> We've had ddebs for a while? This is ddebs actually being handled properly by Soyuz rather than the hacky band-aid we've had for far too long.
<wgrant> (but still not on archive.ubuntu.com, for space reasons)
<infinity> pitti: To be clear, you now have space to publish ddebs for all arches, right?  You're not pruning anymore?
<infinity> pitti: I know vorlon had a bit of a grump about retracing being completely useless on powerpc due to missing ddebs.
<shadeslayer> ah
<pitti> infinity: /dev/mapper/ppa_vg-ppa  2.8T  685G  2.2T  25% /srv
<pitti> infinity: should be fine indeed
<StevenK> Haha, I thought that LV name was familiar
<infinity> pitti: Yay.  Though, I know there was also a plan to make retracers fall back to the librarian if ddebs didn't have the file, so that'll also be helpful if ddebs fills up somehow.
<infinity> StevenK: Yeah, ddebs is germanium, all repurposed-like.
<infinity> And apparently not wiped..
<StevenK> infinity: Change the hostname in apache, delete most of /srv, call it done?
<pitti> infinity: indeed, and I think that's the better mid-term solution even as we can also retrace crashes from earlier package versions
<pitti> infinity: but I guess we still want an actual archive for ddebs, for people who use it with apt
<infinity> pitti: Yeah, I like the apt archive existing and, ideally, that should be "published" in a sane fashion, but a bit of shoestring and bubblegum between A and B works.
<infinity> pitti: And absolutely, retracers being able to retrace old versions will be great.
<zyga> good morning
<pitti> slangasek: hm, I tried "localectl set-x11-keymap pc101 et" and that only wrote /etc/X11/xorg.conf.d/00-keyboard.conf, didn't change /etc/default/keyboard
<pitti> slangasek: I'm writing a complete autopkgtest now, and will fix this (also for reading)
<jamespage> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<jamespage> mdeslaur, re bug 1184223
<ubottu> bug 1184223 in openvpn (Ubuntu Raring) "CVE-2013-2061: use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt" [Low,Confirmed] https://launchpad.net/bugs/1184223
<jamespage> will the security team be picking up the fixes for < saucy?
<pitti> slangasek: ah, ignore me; screw you, autogenerated debian/patches/debian-changes
<didrocks> pitti: mind if I join to the complaint from past similar experiences? ;)
<pitti> smb: would you say that 11pitti1 generally improves things (maybe not completely fix it yet)?
<pitti> smb: I'm pondering an upload to re-fix timedatectl, and that crash fix
<pitti> smb: if/when you would like to debug again, perhaps we can mumble?
<smb> pitti, So I got a few more reboots (takes a bit on that machine) but at least those are consistent and look like an improvement at least
<smb> sure
<dpm> morning all. Is there an archive admin around who could upload qreator on https://launchpad.net/ubuntu/saucy/+queue ? It's been sitting there for a while, and it'd be great to have it in Ubuntu. Thanks!
<Laney> doko: around? Can you look at this calligra no-change rebuild log and tell me if you think it's a gcc-4.8 issue please? http://paste.ubuntu.com/5728708/
<Laney> It builds alright with 4.7
<infinity> Laney: Can you crank up the verbosity on that and try again?
<infinity> Laney: It just shows the command line and exits, that's not helpful. :P
<Laney> infinity: look further up, sorry
<Laney> it's a parallell build
<Laney> line 9291
<infinity> Oh, I missed the earlier exit.  It seems to cascade a few times. :/
<Laney> Probably would have been kinder to rebuild it without parallel=9 when sharing the log :P
<infinity> Laney: It could be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279
<ubottu> gcc.gnu.org bug 57279 in c++ "[C++11] alias declaration fails to declare function types with cv-qualifiers" [Normal,Assigned]
<Laney> I did come across that
<Laney> didn't seem to be a 4.8.1 package in the usual place that I could test with though
<infinity> Or it could be bad C++.  My C++ skills aren't stellar.
<infinity> Laney: It's not fixed in 4.8.1 anyway, hence the milestone bump to 4.8.2
<Laney> ah, I misunderstand the last comment then
<Laney> indeed
<Laney> would it be bad to upload a build with 4.7?
<infinity> Wouldn't be world-ending, but it would be nice if you also filed a bug in LP, mention that upstream bug that may or may not relate, and keep an eye on things.
<infinity> When doko uploads a new gcc-snapshot, that should have the upstream bugfix in it (the current one is three days too old to...)
<Laney> right
<Laney> This should get us to migrating poppler, AFAICT
<seb128> Laney, do you know why update_output.txt lists libreoffice-mysql-connector ?
<Laney> seb128: entangled with mysql-connector-c++
<seb128> ah, ok
<seb128> Laney, ok, I see they both should be fine with the uploads you did + calligra
<Laney> seems fine - the autohinter picks it up if you look near the end of the file
<xnox> seb128: Laney: i'm looking into gdcm build failure rabbit hole, so far I am down to patching vtk to rebuild against updated python2.7....
<seb128> xnox, did the upload Laney just did failed to build?
<xnox> hm.
<xnox> seb128: hm. it works. =) oh well, vtk does need rebuilding anyway.
<Laney> I did briefly look at new vtk and bashed its rules about a bit
<Laney> it assumed python and tcl were in non-multiarch directories
 * xnox suspects my machine is polluted with local builds.
<Laney> xnox: http://paste.debian.net/8208 was my WIP before I stopped because mitya57 had a sponsoring request up that didn't need it
<Laney> feel free to carry it on
<xnox> Laney: so calligra is the last one for poppler to transition?!
<Laney> think so
<hrw> can someone with core-dev permissions take http://pastebin.com/n1TLE7rU and upload libwps? fixed ftfbs
<infinity> hrw: Sure.
<hrw> infinity: thx
<cjwatson> pitti: Re the ddebs discussion above, did anyone happen to mention that ddebs doesn't seem to be picking up saucy-proposed?
<cjwatson> i.e. http://ddebs.ubuntu.com/dists/saucy-proposed/main/binary-i386/ has an elderly timestamp
<pitti> not to me
<pitti> ooh, I know why
<pitti> traditionally I have generated the pockets for the devel release once after opening the series only
 * pitti updates cronjobs
<pitti> we don't let the LP retracers run against saucy-proposed so far, though
<cjwatson> pitti: Yeah, I was trying to figure out something manually.  Thanks
<pitti> cjwatson: fixed, thanks
<cjwatson> (I fell back to a local build, successfully)
<pitti> (it's currently running, so it'll take some 4 hours to become effective)
<pitti> I wish apt-ftparchive wouldn't be so abysmally slow
<infinity> Laney: export CPP=gcc-4.7?  ITYM CC?
<infinity> Laney: Though, I'm sure the CXX export will get what you wanted anyway.
<Laney> oops, but yeah
<Laney> it was test-built, so that's enough
<infinity> (curious that exporting CPP=CC doesn't make something explode, but whatever)
<pitti> cjwatson: http://ddebs.ubuntu.com/dists/saucy-proposed/main/binary-i386/ is current now, FYI
<pitti> s/current/up to date/
<cjwatson> pitti: Great, thanks
<Sargun> Saucy = 13.10?
<cjwatson> Yes
<Sargun> Almost out of letters
<pitti> unicode has a loooot of letters left :)
<Sargun> nooo
<mlankhorst> lets start with glyphs
<cjwatson> Sargun: We reused our first initial letter five years ago
<maxb> But that was a bit of a special case
<cjwatson> Sure, but nevertheless
<cjwatson> It demonstrates that the universe will not end when we reuse a letter
<jamespage> please could someone with the right permissions
<jamespage> mark https://code.launchpad.net/~sdeziel/ubuntu/raring/mysql-5.5/fix-for-lp1185573/+merge/166379
<jamespage> as merged.
<mdeslaur> jamespage: yes, the security team will be doing them (LP: 1184223)
<ubottu> Launchpad bug 1184223 in openvpn (Ubuntu Raring) "CVE-2013-2061: use of non-constant-time memcmp in HMAC comparison in openvpn_decrypt" [Low,Confirmed] https://launchpad.net/bugs/1184223
<jamespage> mdeslaur, great - thanks for confirming.
<mdeslaur> jamespage: we've rated it as "low" though, so it may take a while
<mdeslaur> hrm, since someone has a tree, we'll sponsor that and do the others
<jamespage> mdeslaur, great - thanks
<jamespage> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> infinity: So, I'm getting pretty bored carrying on with merging your generalisation to all arches of the perl = TRUE stuff in r-base (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679180).  I agree that your version is saner, but it looks like the Debian maintainer ignored it, and since raschsampler appears to build just fine with current r-base on Debian arm* these days, I'm sort of inclined to drop the patch and ...
<ubottu> Debian bug 679180 in r-base-core "arm* builds fail: SHLIB_LIBADD: No such file or directory" [Serious,Fixed]
<cjwatson> ... call it good.  Any thoughts
<cjwatson> ?
<stokachu> xnox: if you get a chance today could you re-upload sosreport for me?
<stokachu> ive fixed the non native thing
<stokachu> xnox: thanks man
<xnox> stokachu: =)
<hallyn> the sgabios package is currently in debian's NEW queue.  When it clears, will it be automatically pulled into universe?  Or does a switch need to be toggled?
<mlankhorst> the wiki has instructions on how to get packages in universe
<hrw> hallyn: man requestsync
<hallyn> mlankhorst: what i saw only said "if you can, get it in through debian' but didn't say how to get it into universe from there
<hallyn> hrw: ok, thanks.  i'm not motu, but if that needs to be done i'll get it done - thanks
<tumbleweed> hallyn: it'll be automatic (as in you don't need to ask), but will need an archive-admin to review it
<hallyn> cool, thanks.  Just need to wait on that before qemu 1.5-3 goes into saucy
<cjwatson> hallyn: it's automatic
<cjwatson> ah, tumbleweed said
<hallyn> great - thanks
<cjwatson> if it happens before DebianImportFreeze, it doesn't really require much in the way of archive admin - it goes straight past source NEW (we trust Debian ftpmasters enough for that) and binary NEW is pro-forma
<dholbach> mfisch, congratulations! :)
<hrw> is it normal that launchpad assumes that maintainer==uploader when package is synced from debian?
<hrw> https://launchpad.net/ubuntu/+source/vboot-utils/0~20121212-2 lists Antonio as uploader...
<tumbleweed> hrw: yeah, look at publishing history for the details
<tumbleweed> the UI never really learned about syncs
<hrw> tumbleweed: thanks
<mfisch> thanks dholbach
<Versable> Hey, can someone help me with bzr?
<Versable> I have copied a branch into my own bzr branch, changed a couple of files, added a recipe and pushed it into my PPA
<Versable> but it only build an i386 build, even though in the control file Architecture: all is specified
<Laney> hmm
<tumbleweed> Versable: you want Architecture: any
<Laney> what's responsible for creating the XDG_RUNTIME_DIR?
<tumbleweed> Versable: Architecture: all is for architecture-independant packages
<Versable> tumbleweed: Thanks, the package might be architecture independant, I'll check before changing the control file
<Laney> some tests in glib now expect to be able to write there but nothing creates it apparently
<Versable> tumbleweed: Doh! It was, thanks though ;)
<cjwatson> If it really is architecture-independent, then you would only expect an i386 build (since it builds arch-indep binaries), but it would still publish for all arches
<bdmurray> kirkland`: did you say you could verify bug 1173209?
<ubottu> bug 1173209 in ubuntu-release-upgrader (Ubuntu Raring) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Fix committed] https://launchpad.net/bugs/1173209
<infinity> cjwatson: The r-base hack is just a hack anyway, regardless of if it's arch-specific or not, it doesn't fix the real bug, just works around it.
<infinity> cjwatson: If the Debian maintainer's hackish workaround works as well as mine, I'm not emotionally attached to mine.
<infinity> cjwatson: iz synced now.
<quadrispro> hi there
<cjwatson> infinity: Ta
<bdmurray> robru: would you have a look at bug 1164302?
<ubottu> bug 1164302 in webapps-greasemonkey (Ubuntu Quantal) "Firefox crash during gc" [Undecided,New] https://launchpad.net/bugs/1164302
#ubuntu-devel 2013-06-04
<pitti> Good morning
<pitti> infinity: is there some amount of merges you would trade against taking initramfs-tools from me?
<pitti> infinity: hm, it seems texinfo, apr, and vim are all comparatively simple
<dholbach> good morning
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<dholbach> cyphermox, what do you think about https://code.launchpad.net/~jbicha/ubuntu/saucy/network-manager/depend-on-valac/+merge/166626?
<dholbach> to me it seems to be a bit of a matter of preference - I'll leave it up to you :)
<infinity> pitti: Oh, I'll take initramfs-tools back anyway, since I'm upstream.  My bad for forgetting about it.
<pitti> infinity: thanks; I'm happy to take off texinfo and apr from you anyway if you want
<infinity> pitti: I have no great love for texinfo.  I should probably keep apr until I figure out a cleaner way to make crossing happy upstream.
<infinity> pitti: Oh, actually, my texinfo cross hacks are vile too.  I should probably keep that and sort out something less disgusting.
<infinity> pitti: I forgot that was the package I did *that* to.
 * infinity finds his lunch returning upon re-reading that diff.
<geser> sounds like forgetting as a good idea in this case :)
<dholbach> Mirv, so I merged your touch merge proposal for ubuntu-seeds - are you going to upload another -meta?
<dholbach> Mirv, there's a bunch of changes since the last time - does http://paste.ubuntu.com/5731925/ look all right to you?
<dholbach> Mirv, I can put your email address into it if you like ;-)
<Laney> you might want to check with ogra
<Laney> "Removed powerd" seems suspicious
<Laney> but maybe that's pulled in another way
<ogra> erm, the touch seeds are special
<dholbach> ogra, ok, so I just merged https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.add-qt-accounts-friends-plugins/+merge/166223 and did nothing else
<Mirv> dholbach: thanks! looks good for the sdk related changes, although I can't do the uploads.
<dholbach> I'll leave the rest to you then
<ogra> you need to manually hack them until things are in the archives, germinate cant use PPAs
<dholbach> aha
<dholbach> nevermind then
<cjwatson> mm, been meaning to figure that out ...
<ogra> i'll take care later
<dholbach> thanks ogra!
<Mirv> (I haven't done any touch meta related changes)
<ogra> cjwatson, nah, we better get that stuff into the archive
<cjwatson> Well, sure, but I consider it a germinate bug anyway
<cjwatson> Probably
<infinity> germinate can't use PPAs?
<infinity> Can't you just feed it another -m?
<infinity> I would think that should Just Work.
<cjwatson> Well, this is germinate-update-metapackage, so it all needs to go in update.cfg.  But apparently shoving in more archives didn't do the trick, and I haven't had a chance to investigate yet.
<infinity> Yeah, I was just following that code now to see how or why that's more special than a by-hand invocation.
<cjwatson> It does even go and fetch the relevant Packages files
 * cjwatson attacks germinate-update-metapackage with pdb
<cjwatson> ogra: So, wait.  Now that I've actually updated my seed checkout, I don't see anything wrong with germinate-update-metapackage's output.  What parts of http://paste.ubuntu.com/5732062/ do you think are wrong?
<ogra> cjwatson, looks like it removed everything under the debug section ... weird
<ogra> and powerd
<ogra> though i'm not sure it is seeded
 * ogra looks
<cjwatson> ogra: "debug section"?
<ogra> in the touch seed
<cjwatson> ogra: It only removed powerd on i386
<cjwatson> Where, I'm guessing, it doesn't exist
<ogra> ah, that might be
<cjwatson> ogra: All the entries in the debug section are duplicated from ubuntu-minimal
<ogra> iputils-ping
<ogra> from the debug section
<ogra> oh
<ogra> sorry, typed to fast
<cjwatson> ogra: Your STRUCTURE file says "touch: minimal", so germinate intentionally prunes those
<ogra> well, then it looks perfect
<cjwatson> ogra: And, indeed, your livecd-rootfs config installs ubuntu-minimal as well, so they are indeed redundant
<ogra> yeah
<ogra> thats how it is supposed to be
<ogra> i'll drop it from the seed
<cjwatson> OK, I'll double-check powerd and if that's right then I'll upload
<ogra> yeah, i think it is intentionally not built for x86 yet
<ogra> iirc it wants to talk to android devices
<cjwatson> Indeed, https://launchpad.net/%7Ephablet-team/+archive/ppa/+sourcepub/3241512/+listing-archive-extra concurs
<cjwatson> That was against 1.009, BTW, so a bit laggy.  I'll update against 1.015
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> (I'll do the rest of my shift tomorrow. Got to take care of some other bits first.)
<cjwatson> ogra: OK, uploaded ubuntu-touch-meta.  Could you use the ./update script for future changes?
<ogra> cjwatson, with pleasure !
<ogra> thanks a lot !
<cjwatson> np.  didn't really do much other than observing it worked :-)
 * cjwatson holds his breath and uploads a debhelper merge
<cjwatson> Let me know if you notice any resulting weirdness
<jibel> pitti, is there any limitation to upgrade udev/systemd in an lxc container ? upgrade from 202-0ubuntu12 to 204-0ubuntu1 hangs on configure
<pitti> jibel: not known to me at least; can you please file a bug?
<pitti> jibel: I tested the upgrade on a normal system, which went fine
<jibel> pitti, sure, it's is blocked on "stop udev"
<pitti> jibel: I guess I should be reproducible in otto? :-)
<pitti> jibel: oh, it's the *old* udev which fails to stop?
<jibel> pitti, yes, that's the problem :) I was provisioning a fresh saucy
<pitti> postinst does "invoke-rc.d udev restart", that shoudl call "stop udev"
<jibel> pitti, bug 1187375
<ubottu> bug 1187375 in systemd (Ubuntu) "upgrade of udev from 202-0ubuntu12 to 204-0ubuntu1 hangs on configure in LXC container" [Undecided,New] https://launchpad.net/bugs/1187375
<pitti> jibel: thanks; I'll stop my "fix autopkgtest" vendetta now and look at this
<jibel> pitti, thanks!
<Riddell> stgraber: anything I should look out for in this user upstart kde-plasma session?  seems to work fine
<stgraber> Riddell: with unity we had some problems around accessibility, input methods and some environment variables being missing. That last one should be fine for KDE as it's using a single upstart job and so that problem shouldn't be possible. Input methods and accessibility are probably worth checking though.
<Riddell> gpg: problem with the agent - disabling agent use
<Riddell> stgraber: might that be caused by it?
<Riddell> ^^
<pitti> jibel: indeed, booting today's iso in otto, "sudo stop udev" works, but "sudo start udev" hangs (that's with 202 only, no upgrade)
<stgraber> Riddell: maybe, though we do ship a gpg-agent.conf upstart job that should avoid that. Does KDE ship its own gpg agent (similar to gnome-keyring in gnome)?
<stgraber> Riddell: either way, "initctl status gpg-agent" and "env | grep GPG" may help figuring out what's going on there
<stgraber> Riddell: oh, and "grep use-agent ~/.gnupg/gpg.conf" too
<Riddell> >initctl status gpg-agent
<Riddell> gpg-agent start/running
<Riddell> GPG_AGENT_INFO=/tmp/gpg-cTlh4g/S.gpg-agent:24776:1
<Riddell> use-agent is set in my ~/.gnupg/options
<Riddell> and I have pinentry-qt4 installed
<pitti> jibel: hm, I can manually stop and start udevd just fine, just the upstart command hangs; I wonder if it's somehow interfering with the host system
<pitti> and ^Cing it and re-tryign "start udev" causes upstart to lie "job has already been started", although udevd isn't running
<jibel> pitti, but upgrade from ubuntu11 to ubuntu12 went just fine on the same system. Shouldn't it have been affected as well is it was something with the host?
<stgraber> Riddell: what do you get if you run "gpg-connect-agent"?
<Riddell> stgraber: a > prompt character
<stgraber> Riddell: ok, so it managed to connect to the agent...
<stgraber> Riddell: that suggests the agent is running as expected, not sure what that error message is about then...
<ogra> hmm, no infinity in #ubuntu-touch ... so i'll ask here ...
<ogra> infinity, we need to find some way to exclude the /etc/init.d/ondemand script on ubuntu-touch
<infinity> ogra: Why?
<ogra> cpu frequency stuff is full in the hands of the android side
<ogra> and my phone starts to glow after the script forced ondemand here
<ogra> i was wondering if we could move it to its own package and just make it a recommends
<infinity> interactive, surely.
<infinity> If it's an Android kernel.
<infinity> And all we're doing it poking some /proc bits, which I assume Android is setting similarly.
<infinity> Can you see what all those bits are set to before ondemand runs?
<infinity> ogra: Just how much Android userspace are we running, anyway?  And why don't we pare it down more?
<pitti> jodh, xnox: if "sudo start udev" just hangs (in lxc), there is no udevd process, no log in /var/log/upstart, but I can manually start udevd just fine, how would I go to debug that?
<ogra> well, over the years we might be able to pull over HW configs for each and every ubunt-touch port ... just not yet i guess
<ogra> doing this part relibable in the same way android does it will be hard
<ogra> and the android settings should usually get us the best setup for power saving
<infinity> ogra: Eh?  What does this have to do with hardware configs?  If there's a frequency-twiddly daemon running, stop that.  Setting interactive should work fine.
<jodh> pitti: looks like udevd has a --debug option - you could try adding that to /etc/init/udev.conf to see if you get any output.
<infinity> ogra: Assuming the Android setup is what we want is probably not true.  Our userspaces are wildly different.
<pitti> jodh, xnox: oh, of course -- just after I asked i got it
<pitti> jodh, xnox: there was a "start on starting udev" job which failed; where would/should I have seen that?
<pitti> jibel: ^ we need to auto-destruct or fix /etc/init/lxc-udev.conf :)
<ogra> infinity, right, and currently our userspace doesnt have anything HW related at all we talk to HW through the platform-api
<jodh> pitti: boot with --debug or "initctl log-priority debug" and check dmesg/syslog, or look at the /var/log/upstart/ log if the failing job produced any output.
<pitti> jodh: there was no /var/log/upstart/udev.log; I guess it didn't even get to that yet, as it tried the depending lxc-udev.conf first
<pitti> jodh: ah, thanks for "log-priority debug"
<infinity> ogra: Yes, but we don't need to "talk" to anything WRT frequency scaling.  It's set-and-forget in the kernel, unless there's a daemon running that does weird things.
<infinity> ogra: And if there is, I don't see how we're getting in its way.
<ogra> no, it isnt ... that was long ago
<ogra> with interactive governors the user actions are monitored all the time
<infinity> By the kernel.
<infinity> Hence my "set and forget" comment.
<infinity> This is true of all governors except powersave and performance.
<ogra> well, the interactive governor on the nx4 has like 20 settings or so
<ogra> and they differ for every exynos
<ogra> s/exynos/exynos device/
<infinity> ogra: Instead of trying to outsmart the kernel and set fiddly bits (like you did in the upload after mine), you could just let the defaults get used.
<ogra> not with ubuntu-touch ... the defaults are set from androids init
<ogra> so we need to leave it to the container to set them up
<ogra> and not force ondemand
<infinity> We don't force ondemand.
<jibel> pitti, Oh, I see the problem. I'll create an override on first run. Why does it fail now and in previous upgrade?
<jibel> pitti, thanks for finding this
<infinity> ogra: What order do these scripts get run in?  Ours first, then Android's, or the inverse?
<infinity> ogra: And what do the settings look like when Android's done with it?
<pitti> jibel: I'm working on a fix
<infinity> ogra: I contend that if we remove all those little hacks and tweaks from your 2.88dsf-13.10ubuntu15 upload, it'll all work fine.
<pitti> jodh: hm, I did the initctl log-priority, but I still don't see anything at all in dmesg and /var/log/syslog when I do "sudo start udev"
<infinity> ogra: Cause if Android's setting up tweaks, and all we're doing is setting it to interactive, everyone wins.
<jodh> pitti: did you "sudo initctl log-priority"? If not, you'll just have changed the log priority for your session init if this is saucy ;)
<ogra> infinity, we force ondemand if we do find it
<ogra> (and the system uses one of its own governors nobody knows about ... like on three of my foud devices here)(
<ogra> *four
<infinity> ogra: No, we force ondemand if we *don't* have interactive.
<ogra> yes
<infinity> ogra: So, what are these other governors?
<pitti> jodh: yes, it's today's saucy image, and I ran it with sudo
<ogra> inevnted by the vendors
<infinity> ogra: Their names. :P
 * ogra doesnt have the names here 
<ogra> not std kernel ones
<infinity> ogra: Sure, interactive isn't standard either.
<ogra> hmm, i thought it was since a while
<ogra> on arm at least
<infinity> No, it's Android-specific.
<jodh> pitti: confused then. try starting/stopping another job and seeing if you get output. Presumably "logger foo" does the expected on that system?
<ogra> well, in any case, android will set them on container start
<pitti> jodh: sudo stop/start whoopsie also doesn't log anything; logger foo works
<pitti> jodh: might be because that's inside a container?
<infinity> ogra: Sure.  So, we can make our script just exit silently if it finds any of these other fancy governors.
<ogra> so we are setting them twice ... with the non flipped container pretty harmfulk *after* android comes up ... with the flipped one we just have a redundant call before the android container sets it again
<jodh> pitti: maybe rsyslog isn't running?
<jodh> pitti: unsure - stgraber?
<infinity> ogra: And I'm not sure flipping matters, given that the init script sleeps for 60s, it's probably always run last.
<ogra> infinity, i would at least make it fail if it finds the android upstart job
<ogra> oh, right
<pitti> jodh: it is running, I get log messages from other stuff just fine (e. g. dbus tells me spawned services)
<ogra> still redundant though
<infinity> ogra: What's this Android upstart job?  We can certainly just exit 0 if that exists.
<ogra> lxc-android-container.conf
<jodh> pitti: hmm - I'm actually getting the expected output to the console on my raring lxc container. Maybe boot with 'lxc-start -L /tmp/console.log' or similar?
<ogra> if it wouldnt be a sysvinit script that would be easier :)
<pitti> ls -l /var/lib/lxc/
<pitti> argh
<pitti> jodh: anyway, I have a job "start on starting udev and started mounted-run" "task" "script" "true" "end script" (i. e. doing nothing); that completely blocks "start udev"
<infinity> ogra: Out of curiosity, where did all these interactive tweaks come from?
<ogra> infinity, the ones we ship atm ?
<ogra> androids nexus7 init scripts
<pitti> jodh: I guess it doesn't consider lxc-udev (that job) as started (status lxc-udev says "unknown job"), so I guess that wait condition is busted somehow?
<infinity> ogra: Ahh.  Kay.  I'll just tear them out, I think, since I can't imagine they're ideal for any interactive-using device, and kernel defaults seemed good enough.
<ogra> infinity, loading interactive with its defaults made the device crawl
<ogra> yeah, tear themm out
<ogra> nexus7 desktop is done
<infinity> ogra: That's the opposite of the reports I got from others when I enabled it...
<ogra> the load was constantly around 2.x
<ogra> with interactive properly configured it was normal
<ogra> feel free to try it if you still have an nx7 desktop around :)
<infinity> I don't.
<ogra> it was a quite noticeable difference
<ogra> (like switching from beagle to panda)
<jodh> pitti: suggests the mounted-run job isn't running which will indeed block any follow-on jobs. Try booting with "lxc-start -L /tmp/console.log -- /sbin/init --debug" and looking in /tmp/console.log for the mounted-run job.
<jodh> pitti: you could also create a job that specifies "start on mounted\n exec env \n", boot and check the log again to see which mounted events you are actually getting.
<pitti> jibel: ^ can I pass this option to lxc-start from otto start?
<pitti> jodh: right, mounted-run is a signal, not a job
<pitti> jodh: it'll only happen on boot AFAIK (it works there, i. e. during bootup udev is getting started just fine)
<pitti> jodh: ok, I'll probably just redesign that job to disable itself
<jodh> pitti: mounted-run is a job.
<jibel> pitti, if it is supported by the python binding yes
<infinity> ogra: http://paste.ubuntu.com/5732832/ <-- Verify that path is right?
<ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
<infinity> 08:47 < ogra> lxc-android-container.conf
<infinity> 08:59 < ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
<infinity> This is what I get for trusting people. ;)
<ogra> haha, sorry
<pitti> jodh: ah, close enough; it's a task, i. e. it's usually stopped
<infinity> ogra: Uploaded with that correction.
<pitti> jibel: I have the upstart job create an .override file now, but that's broken if we keep deltas -- you can't ever boot this container twice then
<pitti> jibel: so I'd rather not use anythign file system based, except /run
<pitti> do we have a /run/init/ for jobs?
<ogra> infinity, thx !
<pitti> jibel: ah, easier I think: udev starts on "virtual-filesystems", which sounds like including /run; so I don't think we need to repeat that condition in lxc-udev; I'll just drop it
<xnox> pitti: i don't think we do. but we could add it, e.g. upstart does support multiple locations in priority order correctly.
<xnox> (as used in user sessions for example)
<stgraber> xnox: didn't we explicitly decide not to support this in system mode?
<pitti> jibel: ok, that works fine
<jibel> pitti, otherwise we could delete the override in the pre-mount
<jibel> pitti, ok
<pitti> stgraber: it would be similar to /run/udev/rules.d/
<xnox> stgraber: correct. but it wouldn't be hard to enable.
<stgraber> xnox: sure, it's just that in a recent MP we agreed this would likely be confusing and cause some weirdness if one of the paths doesn't exist. That's why jodh made a change to allow the option be passed multiple times but discard all but the last instance (and added matching tests to ensure that doesn't change)
<xnox> stgraber: thinking about it yeah... it might be weird. does mountall mount /run or is it mounted in initramfs?! it would be confusing not to have conf-source on boot, as we might fail to start tracking it with inotify.
<xnox> and initctl reload-configuration would be needed.
<stgraber> xnox: /run is usually mounted by the initramfs, so that's fine (so long as you have one), but we'd still hit that kind of problem if you were to pass a /var directory or something under /usr
<xnox> sure.
<cjwatson> ah, phablet-flash is still looking at ubuntu-touch-preview - if I want to try the ubuntu-touch (saucy) images do I need to do that by hand somehow?
<xnox> cjwatson: yes. https://wiki.ubuntu.com/Touch/Install#Manual_Installation
<xnox> using the matching/correct saucy files. push first one, reboot into recovery, push second one, reboot into recovery again and you should be good to go.
<cjwatson> k, thanks
<cjwatson> I got my hopes up when I saw stuff in the changelog about pulling from cdimage, but of course that was ubuntu-touch-preview
<pitti> jibel: hm, seems we need the "mounted-run" after all, so I don't commit my changes
<pitti> jibel: so we need to remove the override in the pre-mount script
<pitti> jibel: I'll commit that
<pitti> jibel: (done)
<jibel> pitti, many thanks, I'll do a run with the fix.
<pitti> slangasek: err -- how come that I was just about to do a test build/upload of binutils to fix exactly the same issue that you did 5 mins ago? :-)
<pitti> slangasek: thanks
 * pitti goes on to the next one
<pitti> slangasek: do we still need the "Breaks: libiodbc2" in odbcinst1debian2 (from bug 901638)?
<ubottu> bug 901638 in soprano (Debian) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [Unknown,New] https://launchpad.net/bugs/901638
<pitti> slangasek: I'm looking at the psqlodbc autopkgtest which doesn't work in ubuntu as one cannot install its dependencies due to that
<Laney> xnox: are those saucy images supposed to work currently?
<Laney> I just pushed them and I got into a reboot loop
<xnox> Laney: I had more success upgrading and/or using the custom saucy image from someone's blog post.
<Laney> I think I'll go back to the normal ones for now
 * Laney fablet-phlash
<pitti> slangasek: it was an upgrade fix to precise, but I'm not sure whether it still makes sense semantically
<Laney> wait, might have pushed the wrong thing the second time
<ev> bdrung: hi. Are you still unable to access errors.ubuntu.com?
<ev> we've had another report of this today via dpm, so this could be a bug
<pitti> barry: hey, how are you?
<barry> pitti: hi!  good, and you?
<pitti> barry: are you interested in fixing oneconf's autopkgtest? it outputs a lot to stderr (which could be a redirection), but several tests fail, too
<pitti> barry: I'm fine, thanks!
<barry> pitti: i could take a crack at it, but it probably won't be today.  is there a bug open on it?
<pitti> barry: I can open one if it helps for scheduling/reminding
<barry> pitti: it definitely would :)
<pitti> barry: nah, doesn't need to be today, I'm just trawling through our stack of failures, fixing some (mostly the debian imports), and nagging some people to fix "theirs"
<pitti> barry: cheers, will do
<barry> pitti: sounds good
<infinity> pitti: Does eglibc still fail?  I haven't looked in a while.
<infinity> pitti: Interestingly, after we went and blamed qemu/kvm, eglibc passed its testsuite with flying colors on the new kvm openstack buildds.
<infinity> pitti: And it's not the raring/saucy kernels, cause that's what I test on at home.
<pitti> infinity: hah, good to hear
<infinity> pitti: So, if it's still broken, I'm a bit stumped.
<pitti> barry: filed bug 1187460 with all links and an excerpt of the failures
<ubottu> bug 1187460 in oneconf (Ubuntu) "autopkgtest has several failures" [Undecided,New] https://launchpad.net/bugs/1187460
<infinity> pitti: And I really don't want to go randomly disabling tests because the autopkgtest rig is less reliable than the buildds, that would be moving in the wrong direction.
<pitti> yes, it still fails
 * pitti downloads the 57 MB log
<cjwatson> You could selectively disable them in autopkgtest if you were really stuck
<cjwatson> (env variable, filtering, whatever)
<pitti> infinity: the host that we are running this on is probably still precise
<infinity> cjwatson: I could slap in a different set of expected results, yeah.  But ew.
<barry> pitti: thanks
<infinity> pitti: precise host and saucy guests, I assume?
<pitti> infinity: saucy guest definitively (we use the daily servercloud image); let me double-check the host
<cjwatson> pitti: Ha, I fixed the haskell-yesod one in darcs just before I saw the IRC notification of your bug
<infinity> pitti: I don't see how that would be any weirder than any of the setups where it's all gone fine, but I dunno.
<pitti> cjwatson: oh, awesome!
<infinity> pitti: Anyhow, I need a bit of a nap, so I'll have to ponder it a bit later.
<cjwatson> Ah, apparently not quite, hadn't realised yesod was genuinely exiting non-zero too
<pitti> badpkg: dependency install failed, exit code 2
<pitti> cjwatson: ah, "yesod test" exiting with 127 is actually expected?
<cjwatson> I don't think so
<cjwatson> I'll look
<pitti> infinity: so it's something else now; let's look tomorrow, it's getting late for me, too
<infinity> pitti: Oh yay for "something else". :)
 * pitti crosses fingers that binutils will succeed now
<pitti> infinity: /usr/lib/pbuilder/pbuilder-satisfydepends-classic fails now
<pitti> i. e. some bad or uninstallable dependencies
<infinity> pitti: Curious.
<pitti> Passed regression testing. No new failures, no changed error values.
<pitti> infinity: ^ that bit looks good, though :)
<infinity> pitti: Shiny.
<infinity> pitti: So, apparently, ignoring failures is the best way to fix them.
<pitti> oh wait, I think that might not be the whole story
<infinity> pitti: Where can I find this log again?  Jenkins and I don't love each other.
<pitti> infinity: http://paste.ubuntu.com/5733066/ is the "interesting" excerpt
<pitti> infinity: does that look like a test pass or fail? (not sure whether these "make check" errors are expected)
<pitti> infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-eglibc/17/ARCH=amd64,label=adt/
<infinity> pitti: That's a pass.
<pitti> infinity: "log" is the full log
<infinity> pitti: It prints out the output of the XFAILs just to remind you. :P
<pitti> infinity: ok, then it's just some bogus with test depends or something; I'll have a look tomorrow
<infinity> pitti: Well, locales-all doesn't exist.
<infinity> pitti: Probably my fault for allowing it to be in the .dsc
<pitti> ah, was just trying this with apt-get, indeed
<pitti> infinity: we could just add a "Depends: libc-dev" to debian/tests/control
<pitti> infinity: the default is "Depends: @" which means "all binaries from that source"
<pitti> infinity: but as the important part is the "needs-build", and the actual test is just a "true", the Depends: doesn't matter and it can be a dummy
<pitti> infinity: so "libc-dev" or "coreutils" or something like that should do fine
<infinity> pitti: Ahh, that would do.
<pitti> infinity: do we have a Vcs-* on the Ubuntu side to commit that?
<pitti> might not be worth an upload just for this
<infinity> pitti: I'll commit it to Debian, the test lives there.
<pitti> ah, great; just to stow it away and not having to remember all this again next time
<infinity> pitti: I'll just do "Depends: build-essential", seems appropriate for a needs-build.
<pitti> infinity: yep, that's what we have in binutils
<pitti> (although it's also just a dummy, Depends: is installed after building, FYI)
<infinity> pitti: *nod*
<infinity> pitti: Is there a bug for this?
<pitti> infinity: I can create one if you want to
<infinity> Nah, I'm good.
<cjwatson> pitti: ah, yesod is just a missing test dep
<pitti> cjwatson: oh, is it? I was running this in a VM, and the "yesod" command seemed to exist
<cjwatson> it needs cabal-install too
<cjwatson> after that it's fine
<pitti> ah, nice
<cjwatson> (was clear-ish from strace)
 * infinity really naps now.
<pitti> now, after the efforts of the last three days, let's see how long it takes until the failures are a screenful again :)
<pitti> this should get quite a bit better with britney integration in the future, though
<pitti> jibel: OOI, any news about the RT about sending the notifications to the uploader?
<jibel> pitti, yes, I received an update this morning, and IS is setting up a relay for the lab and "it should be ready in the next couple of days"
<pitti> jibel: nice
<seb128> pitti, hey, do you plan to deal with the packagekit transition? seems it's in proposed since over a month and that you uploaded it?
<Laney> jbicha was talking about that earlier
<pitti> seb128: oh sorry, I wasn't aware it's stuck in -proposed
<pitti> seb128: yes, can do tomorrow
<seb128> pitti, it's not going to be a "tomorrow" thing afaik, we didn't do the transition last cycle because abis changed quite a lot and aptdaemon and stuff need to be ported
<seb128> pitti, but we should probably start organizing that (or revert the update)
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", hmm
<seb128> skipped: packagekit (35 <- 26)
<seb128>     got: 172+0: i-172
<seb128> with a load of packages
<slangasek> pitti: binutils> great minds? ;)
<pitti> seb128: yes, there is bug 1175972 at least
<ubottu> bug 1175972 in aptdaemon (Ubuntu) "aptdaemon packagekit compatibility layer broken" [Undecided,Fix released] https://launchpad.net/bugs/1175972
<seb128> pitti, see https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407
<ubottu> Launchpad bug 1022407 in packagekit (Ubuntu) "Update to 0.8.x" [Wishlist,Triaged]
<seb128> pitti, do you think that update is worth the work involved?
<seb128> pitti, I'm pondering if we should just revert to the old version...
<Laney> they're not all direct depends
<slangasek> pitti: the libiodbc2 breaks can be made Breaks: libiodbc2 (<< 3.52.7-3).  Why does psqlodbc reference iodbc, though?  It should only be using unixodbc
<pitti> seb128: I don't have a strong opinion yet before looking at how much needs porting
<seb128> Laney, right, but I though we didn't go for it in raring because porting aptdaemon and stuff is not trivial
<cjwatson> pitti: update_excuses is package-local checks, update_output is global checks
<seb128> pitti, right, we should have a look at the work involved
<cjwatson> pitti: (as in Debian)
<pitti> slangasek: it's a test dependency, debian/tests/isql has tests for both unixodbc and iodbc
<pitti> slangasek: so if we cannot make them co-installable, we can split the test or disable the iodbc one
<cjwatson> Reverting to the old version isn't a "just", since it has the potential to screw up library dependencies, surely
<pitti> slangasek: but versioned breaks sounds great
<slangasek> pitti: disable the iodbc test, iodbc is irrelevant
<cjwatson> (I think the pressure to decide whether to revert quickly is off, FWIW, given that this is only in -proposed; yes, I realise it impedes development in the medium term but it's not breaking users so we have some time)
<slangasek> pitti: we don't need two ODBC DMs, and the only reason I haven't shot iodbc in the head in Debian is because the Debian KDE folks refuse to let it die
<pitti> slangasek: ack, thanks
<seb128> cjwatson, right, it's not a "just", but I'm not wanting to spend efforts in porting/fixing aptdaemon/software-center etc for no benefit out of being on the current upstream version of packagekit, at least not this cycle where we have been asked to focus efforts on phone and other things
<pitti> seb128: urgh, that's a sizable stack indeed
<pitti> seb128: so, I have no particular urgency with the new PK
<seb128> pitti, we stayed away from it for a reason...
<pitti> it's not even supported
<cjwatson> ask somebody like glatzor if he can help, maybe?
<seb128> pitti, did you want the new one for a reason or did you overlook that the abi changed so much?
<seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407/comments/6
<pitti> cjwatson: yes, I was talking to him quickly about porting aptdaemon
<ubottu> Launchpad bug 1022407 in packagekit (Ubuntu) "Update to 0.8.x" [Wishlist,Triaged]
<seb128> cjwatson, he said he would work on it, but it has been over 6 months
<seb128> cjwatson, I'm sure that will happen at some point, but he seems quite busy atm
<Laney> might as well ask
<Laney> the transition is pretty well advanced in saucy-proposed as far as archive reverse dependencies go
<seb128> glatzor, ^
<cjwatson> or Matthias Klumpp might be willing to help out with aptdaemon, perhaps?
<pitti> seb128: I wasn't aware it changed so much; I thought some rebuilds would do; but I didn't really spend that much time on it TBH
<seb128> ok
<pitti> cjwatson: I doubt that, given that Matthias heavily advocates to drop aptdaemon and move to PK proper
<seb128> is Matthias Klumpp on IRC?
<cjwatson> incidentally, if you do get to the point where you decide the best option is to revert, please talk to me first; it may well be better to simply remove the affected packages from -proposed than to upload a mangled-version thing
<pitti> seb128: ximion AFAIR
<seb128> pitti, thanks
<seb128> cjwatson, noted
<seb128> we will wait to hear back from glatzor
<seb128> we for sure don't have anyone in Desktop with the free slots to do non trivial aptdaemon porting this cycle
<cjwatson> or some combination of removals and rebuilds-against-old-library, or similar.  Just thought I'd say because mangled versions are hard to undo later
<Laney> I might manually block it then
<Laney> since AFAICT it's in danger of transitioning when stuff builds
<cjwatson> If stuff builds then we're golden, surely
<pitti> doing it now sounds like lots of pain for little gain then, as long as it's still in Debian experimental
<seb128> are stuff likely to build if they are not ported?
<Laney> I thought the problem was in python-aptdaemon
<seb128> they also changed the dbus apis I guess?
<Laney> (or whatever the exact package name is)
<pitti> but I didn't expect the API to change that much really; my feeling is that it's mostly aptdaemon
<cjwatson> I'd have thought aptdaemon's build-time tests would fail
<pitti> they do
<pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-aptdaemon/
<pitti> they fail in the PK compat bits
<Laney> it's not an rdep of the C library though
<seb128> pitti, if you see bug #1022407 (which has the NEWS entry), it says "We've broken a lot of API in this release. A LOT"
<ubottu> bug 1022407 in packagekit (Ubuntu) "Update to 0.8.x" [Wishlist,Triaged] https://launchpad.net/bugs/1022407
<seb128> Laney, yes, please put a manual blocker on it
<cjwatson> ah, aptdaemon isn't in the broken list
<cjwatson> so yeah, agree with seb128
<Laney> right, so britney isn't helping out
<Laney> doing
<seb128> Laney, thanks
<seb128> do we need an archive grep for the users of the dbus api if that changed?
<pitti> we should do that, yes (start with codesearch.d.n?)
<Laney> sounds good
<pitti> but most stuff really ought to use the library or the gir, not talk to dbus
<pitti> (aside from the fact that the d-bus API is really hard to use)
<seb128> pitti, right, I guess the main user is aptdaemon which implements the same apis
<seb128> Laney, pitti: http://codesearch.debian.net/search?q=org.freedesktop.PackageKit lists stuff like libreoffice and nautilus using directly the dbus api
<seb128> g-c-c yelp
<Laney> I'm guessing a lot of stuff will be ported based on the comment in the bug
<cjwatson> Do autopkgtests have network access?
<cjwatson> Guess it's better not to rely on it ...
<jbicha> g-c-c should be fine since 3.6; I believe we actually disable yelp's PK integration since aptdaemon didn't support that feature
<seb128> g-c-c is not fine no
<pitti> cjwatson: through a proxy, but not very reliably indeed
<seb128> jbicha, it's broken the other way around, https://git.gnome.org/browse/gnome-control-center/commit/?id=5366d1188e212d472905ac325df9a4c03eb711a9 ... it will turn off the feature at runtime
<seb128> jbicha, which probably means the current archive version has that feature broken :/
<jbicha> it's not a very useful feature since we have a dedicated app for checking & installing updates
<seb128> right
<Laney> I found https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-package-kit
<Laney> which links a branch to port aptdaemon but it would likely need more work
<Laney> I guess we can revisit in a little while as long as things aren't blocked on it
 * Laney goes away
<seb128> Laney, right, thanks, have fun
<seb128> Laney, yeah, that vcs didn't have any commit for 8 months
<pitti> seb128: so tomorrow, should we review how many rebuilds in -proposed we'd need when we drop 0.8 from -proposed?
 * pitti needs to make dinner now and has a meeting at 8, can't spend much time on that any more today, sorry
<seb128> pitti, I would still like to have an estimate of the aptdaemon port work and a reply from glatzor
<seb128> pitti, no worry, we will not sort it out today
<seb128> pitti, enjoy your evening, let's look to it a bit more tomorrow
<dobey> what's the expected TTL to go from proposed to release pocket on saucy at the moment?
<stgraber> dobey: should still be a week for saucy-proposed => saucy-updates, assuming that all the bugs have been verified
<seb128> stgraber, ?
<stgraber> seb128: ?
<seb128> stgraber, saucy is the current active serie, why would proposed to archive take a week?
<stgraber> seb128: oops, brain not working today ;) I parsed that as raring...
<seb128> dobey, should take a publisher run (less than an hour)
<stgraber> dobey: so the real answer is 30min if it's not stuck because it's braking the world
<stgraber> *breaking even
<seb128> stgraber, ;-)
<dobey> oh
<seb128> dobey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt to see if it's blocked by a transition or something
<stgraber> dobey: if you give me the name of the source I can tell you why it's stuck?
<seb128> dobey, what source are you looking at?
<dobey> ubuntu-sso-client. i guess it's blocked due to the breaks/replaces on python-ubuntuone-storageprotocol i added
<seb128> dobey,     * i386: deja-dup-backend-ubuntuone, gir1.2-syncdaemon-1.0, libsyncdaemon-1.0-1, libsyncdaemon-1.0-dev, magicicada, python-ubuntuone-control-panel, ubuntuone-client, ubuntuone-client-gnome, ubuntuone-client-proxy, ubuntuone-control-panel, ubuntuone-control-panel-qt
<stgraber> dobey: yep, looks like it'll prevent a whole bunch of packages from being installable, so britney refuses to promote it
<dobey> right, ok.
<arges> hallyn: hi. Is the qemu-kvm_1.0 package based on the qemu-kvm.git repo tagged qemu-kvm-1.0? or is from another source/tag? thanks
<doko> infinity, did you sync llvm-toolchain-3.2? looks like not all patches were migrated from llvm-3.2
<slangasek> pitti: hmm, I don't understand why jenkins still shows the binutils autopkgtest as failed, because when I drill down I see "no failures" on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-binutils/12/
<hallyn> arges: yes, qemu-kvm.git
<arges> hallyn: thanks
<slangasek> cjwatson_: if parted fails with a given GPT, but the kernel and gdisk are both happy with it, is this worth a bug report on parted?
<slangasek> cjwatson_: http://paste.ubuntu.com/5733851/
<dobey> any archive admin around that can take care of bug #1187554 real quick?
<ubottu> bug 1187554 in ubuntuone-couch (Ubuntu) "Archive removal" [Undecided,New] https://launchpad.net/bugs/1187554
<ev> kees: can you try logging in to errors.ubuntu.com for me?
<ev> I think we've fixed it
<kees> ev: sure, one sec
<ev> cheers
<kees> ev: hm, same thing
<ev> damn
<slangasek> dobey: yes - though why the urgency?
<ev> oh, my mistake
<ev> fixing
<dobey> slangasek: not really urgent. just want to see it gone :)
<slangasek> dobey: ok, well, done then; but removals are normally batch-processed
<ev> kees: if you could try once more, I'd appreciate it
<dobey> slangasek: thanks
<cjwatson_> slangasek: yep
<slangasek> cjwatson: ok.  What data should I attach?
<cjwatson> dd of the relevant chunks of disk
<slangasek> cjwatson: can you hint me which bits are "relevant"? :)
<cjwatson> first 4KB should do
<cjwatson> at a guess
<slangasek> ok
<cjwatson> (IIRC it's actually in sector 1)
<cjwatson> Make it 16KiB just in case it has a funny block size or something
<slangasek> cjwatson: bug #1187560
<ubottu> bug 1187560 in parted (Ubuntu) "parted rejects GPT as corrupt, kernel + gdisk think it's ok" [Undecided,New] https://launchpad.net/bugs/1187560
<kees> ev: sure, one sec
<kees> ev: yay! works.
<ev> woohoo!
<kees> ev: so, is it possible to search based on apport fields?
<ev> kees: can you give me an example, or otherwise elaborate on the use case?
<ev> the short answer is no, but perhaps it's something we should be doing :)
<kees> ev: for example: all packages that crashed with 'Signal' == 11
<kees> or, better, all package that have 'SegvReason' containing the string 'executing writable'
<ev> there's a few things we could do here
<ev> the easiest would be to start tracking the type of crash at the problem level (group of instances of errors matched with the same signature) and keep an index of these
 * tedg__ thinks it's nice that kees is making "big data" rootkits  ;-)
<kees> generally being able to fish out specific apport fields would be great, but for me personally, I'd like to see the SegvReason and likely things like ProcMaps, Disassembly, and Registers
<ev> for the latter case of doing text based searches, we have Hadoop coming this cycle
<ev> hopefully
<kees> tedg__: yeah, I used to mine launchpad for this stuff. it's great
<ev> making a note of all this to explore it in more detail tomorrow and see if we can't come up with a plan
<kees> ev: cool, thanks. in the meantime, I'll continue to poke around.
<ev> kees: let me know if you break anything ;)
<kees> ev: sure thing :)
<tedg__> kees, That would be a great defcon talk: "Using Big Data for Evil"  ;-)
<ev> tedg__: surely this is adorable-sized data compared to the stuff Google is running :)
<tedg__> ev, yes, but Google's not allowed to be evil ;-)
<kees> tedg__: I proposed that. they didn't take me up on it. :)
<kees> ev: are kernel crashes being reported into this too?
<ev> it's quite hard to be when you have a quiet room filled with teddy bears
<ev> kees: yes, but it's forever on my list to figure out why we're not getting any
 * tedg__ imagines that defcon just rejects all talks and expects you to hack the database and change your talk to accepted if you really want it.
<thegatta_> hahaha it could work
<sarnold> kees: what?!? You said, "hey guys, wouldn't it be more fun if we _could_ be evil?" and they said _no_??
<tedg__> ev, Hmm, now you've left me wondering whether teddy bears are cheaper than sound foam for my office.
<ev> tedg__: it'd surely make the property tax inspector give you a good rate
<ev> right! I'm getting out of here before you lot create any more work for me
<tedg__> 'night ev!
<ev> if you desperately want any more features while I'm sleeping, lp:errors is place to go ;)
<ev> night!
<kees> sarnold: hah, no defcon rejected it
<kees> ev: cya!
<tedg__> kees, I'm kinda curious if we could track segfaults on system services along with geoip based data to discover botnets looking for vulnerable systems.
<sarnold> kees: ah. :)
<tedg__> kees, Unfortunately we don't have apport on by default in server.
<sarnold> tedg__: ooo
<kees> ev: btw, getting kernel crashes showing up would be more interesting than the apport fields for me, if you want to priority on those requests. :)
<kees> tedg__: heh. too bad!
<kees> it's safe to do suidcoredump=2 thing now, too.
<kees> er, fs.suid_dumpable=2  rather
<kees> that was a fun fix, inspired by some discussion with ev a while back...
<bdrung> ev: no. i can access errors.ubuntu.com again.
<xnox> slangasek: can we please have your libpam-runtime back?! =) I believe it's so much better. bug 1187579
<ubottu> bug 1187579 in systemd (Ubuntu) "Upgrading systemd to 204-0ubuntu1 clears running XDG_RUNTIME_DIR ?!" [High,New] https://launchpad.net/bugs/1187579
<slangasek> xnox: hmm, you mean libpam-xdg-support?
<xnox> yes.
<slangasek> preferably not :)
<xnox> slangasek: thanks for volunteering to fix the above bug =) did you notice similar? or shall I wait to see what pitti thinks about it =)
<slangasek> yes, pam_xdg_support uses a simpler method of managing sessions, but
<slangasek> xnox: I haven't upgraded to 204-0ubuntu1 yet
<xnox> hm. ok.
<slangasek> I think the person who uploaded it should get to fix this ;P
<xnox> solomon's decision - invoke the TIL rule
<infinity> doko: I didn't, no.
#ubuntu-devel 2013-06-05
<pitti> Good morning
<pitti> xnox: I'll look at the xdg runtime dir bug ASAP, thanks
<pitti> slangasek: looking at binutils
<pitti> I didn't notice anything weird after upgrading udev yesterday (and I did it a lot of times), hmm
<pitti> slangasek: binutils> ah, same problem as with libc; an absent "Depends:" field means "Depends: @" which means "all binaries from this source
<pitti> slangasek: but adt-run parses debian/control and then tries to install binutils-hppa64
<pitti> slangasek: I'll upload a fix
<pitti> meh,  I just got the new qemu, and it seems to be totally broken for me now
<pitti> key/mouse grabbing doesn't work any more, I cannot start anything from the dash nor press alt+f2 (due to missing screen grab), and when I change the resolution it crashes
<pitti> and with default vga it's losing my mouse cursor *sigh*
<pitti> xnox: followed up to the bug with some questions which might help with debugging
<dholbach> good morning
<Versable> Hey, I am trying to package a little script but get complie errors when I try to debuild
<Versable> libwnck/libwnck.h not found
<Versable> I have got it in the cmakelist though set(DEPS_PACKAGES     glib-2.0     granite     libwnck-3.0 )
<geser> have you also the -dev package for it installed?
<Versable> yes, it compiles fine when I do it manually
<Versable> valac --pkg libwnck-3.0 -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE showdesktop.valaÂ 
<Versable> with that
<Versable> http://pastebin.com/E3EbQp3k
<geser> are you building with pbuilder/schroot or similar? then you also need to have the package listed in Build-Depends so it get installed for the build
<Versable> Also in thereIt's also in there
<Versable> Build-Depends: cmake (>= 2.8),                debhelper (>= 8.0.0),                valac-0.16 | valac (>= 0.16),                libgranite-dev,                libwnck-3-dev,
<geser> Versable: looking at your pastebin it's not the valac call failing but the following gcc call, there seems to be a -I/usr/include/libwnck-3.0 missing
<dholbach> I have a funny problem with (I believe) resolvconf - etc/resolv.conf is a link to /run/resolvconf/resolv.conf - my wifi seems to have 192.168.1.1 set as its primary DNS, but resolv.conf says it's 127.0.1.1 - and I can't get it to change it (and don't want to edit resolv.conf manually) - did anyone else ever run into this?
<Versable> Where/how do I define it, my cmakelist.txt: http://pastebin.com/q9r8PSUK
<geser> Versable: I'm not very familiar with cmake but try to add "libwnck-3.0" to DEPS_PKG (those get passed to pkg-config and I hope cmake passes all those CFLAGS in ${DEPS_CFLAGS})
<Versable> geser: That almost worked, it's giving me "#error "libwnck should only be used if you understand that it's subject to frequent change, and is not supported as a fixed API/ABI or as part of the platform"
<Versable> geser: I think I have to pass  -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE to gcc too
<Versable> geser: where would i define global gcc compiler options/arguments
<seb128> dholbach, hey, /etc/resolv.conf isn't a symlink for me
<seb128> but I didn't update/restart yet this morning
<dholbach> this machine is still on raring
<dholbach> hum... for some reason it wasn't auto-updated for me in the past and I think in some manpage I read that it was supposed to be (or can be) a symlink - either way it's not updated
<pitti> seb128: oh, you don't have resolvconf installed?
<seb128> pitti, no, I don't
<dholbach> or rather /run/resolvconf/resolv.conf was updated when I reconnected to my wifi, but it still has 127.0.1.1 instead of 192.168.1.1 as the nameserver
<seb128> dholbach, seems like your config is normal then, not mine ... not sure why you have a wrong DNS in there though
<seb128> did that start recently?
<pitti> Task: minimal
<dholbach> seb128, in the last few weeks I noticed problems - at the sprint too
<seb128> dholbach, it might be that the dns info is sent by the dhcp, are you on a new network?
<dholbach> seb128, no, my home network
<pitti> seb128: missing ubuntu-minimal then?
<dholbach> and I rebooted the machine last night
<seb128> pitti, indeed, that install is over 3 years, I probably got it removed at some point ... installing, thenks ;-)
<geser> Versable: try changing the add_definitions line to : add_definitions(${DEPS_CFLAGS} -DWNCK_I_KNOW_THIS_IS_UNSTABLE)
<seb128> pitti, do you have any idea about how resolvconf works otherwise? dholbach gets a wrong DNS info in there
<pitti> roughly
<dholbach> in the past I would have just edited resolv.conf manually and put a nameserver I know in there, but I figured it's be good if it just worked and took the information from DHCP :)(
<pitti> so, NM calls dhclient, dhclient calls some script when it's done
<Versable> geser: Awesome, that did it, you are my hero of the day :D
<pitti> and /etc/resolvconf/update.d/*
<pitti> /etc/resolvconf/update.d/libc writes the new nameserver to /run/resolvconf/resolv.conf
<dholbach> pitti, /run/resolvconf/resolv.conf seems to have been updated when I reconnected to the wifi
<pitti> or rather, to /run/resolvconf/interface/ first, and update-resolvconf then builds /run/resolvconf/resolv.conf
<pitti> dholbach: ah, so /run/resolvconf/resolv.conf is fine?
<dholbach> no, it has the wrong dns
<pitti> dholbach: /etc/resolv.conf -> ../run/resolvconf/resolv.conf
<dholbach> pitti, yes
<pitti> dholbach: do you have that?
<dholbach> ah, where's update-resolvconf from?
<seb128> dholbach, forums suggests that 127.0.1.1 is dnsmasq
<pitti> dholbach: sorry, resolvconf -u
<seb128> dholbach, do you have that installed?
<dholbach> seb128, dnsmasq is not installed
<seb128> k, not that then :p
<pitti> dholbach: you can check /var/log/syslog for the NetworkMangaer log which address dhclient got from your router
<pitti> dholbach: dnsmasq-base
<dholbach> Jun  5 09:22:57 daydream NetworkManager[877]: <info>   nameserver '192.168.1.1'
<pitti> and that's required by NM, you ought to have it
<pitti> hmm
<pitti> dholbach: so what's actually wrong?
<pitti> /etc/resolv.conf is supposed to only have 127.0.1.1
<dholbach> ahhhh ok
<pitti> dholbach: so your computer cannot resolve DNS names?
<pitti> i. e. what is the actual problem?
<pitti> dnsmasq isn't working?
<dholbach> I thought it was supposed to be what dhcp told it to be
<dholbach> a red herring then - it might be some other networking problems
<pitti> I think NM moved to dnsmasq to better support things like tethering (but I don't know details -> cyphermox)
<dholbach> ok
<seb128> dholbach, is your system failing to resolv names to ips?
<dholbach> strange, I just did a "wget http://reqorts.qa.ubuntu.com/reports/sponsoring/" which worked fine, but loading the page in firefox seems stuck at the "looking up ...." stage
<dholbach> it works fine in chromium
<dholbach> sorry for all the confusion
<seb128> dholbach, ok, that's when you go find chrisccoulson ;-)
<dholbach> thanks everyone
<seb128> dholbach, yw ;-)
<dholbach> thanks pitti as well
<pitti> kein Problem
<dholbach> and I learned a few more new things now - great :)
<chrisccoulson> my ears are burning
<chrisccoulson> firefox is nothing to do with me now ;)
<pitti> xnox: FTR, I tried to open extra sessions after the upgrade, and none of them killed my runtime dir
<xnox> pitti: yeah, tested same quickly here. I'm not sure anymore what else I had going on at the time.
 * pitti reads the user_stop() code which calls user_remove_runtime_path()
<pitti> but that would kill your whole session, cgroup etc, too
<pitti> and ther are no other relevant unlinks/rmdir/rm_rf
<pitti> (and even then, logind isn't even supposed to restart during dist-upgrade, I disabled that as the cgroup layout changed in 204)
<pitti> xnox: so what could happen: you dist-upgrade, then you or something kills systemd-logind, then you start some new session, the new logind gets spawned
<pitti> and that doesn't have any sessions (due to the changed cgroup layout); but then I still don't see why it should call user_stop() as it doesn't have any sessions
<pitti> but perhaps something along that line
<pitti> xnox: perhaps that upgrade to 204 should just trigger a reboot notification?
<seb128> bdmurray, slangasek: I restored the "auto-launch" key in the update-notifier schemas (just there, not the feature in the code), it's being used by update-manager and it was aborting on start with the new update-notifier (gsettings abort on broken schemas/missing keys)
<seb128> bdmurray, slangasek: that's a FYI
<seb128> bdmurray, slangasek: update-manager should probably be taught about not using that key if it's deprecated
<xnox> pitti: That seems reasonable. Given that we only have people who reboot when asked, and otherwise keep their sessions suspended.
<pitti> xnox: ok, doing that then; do you think you can squeeze out anything else from this bug?
<xnox> pitti: don't think so.
<pitti> xnox: ok, doing that then; thanks!
<OdyX`> tkamppeter_: It would be very nice to have you comment on http://bugs.debian.org/711169 as I'm really at loss in all that change.
<ubottu> Debian bug 711169 in cups-daemon "cups-daemon: ipp printer browsing support removed" [Normal,Open]
<pitti> xnox: hm, I called /usr/share/update-notifier/notify-reboot-required, and /var/run/reboot-required is there now, but I don't get an actual reboot notification
<pitti> seb128: ^ do you know whether that moved from update-notifier to the indicator, and might not actually work?
<seb128> pitti, update-manager is supposed to have a reboot required banner
<pitti> oh, we don't make the session indicator red for that any more? ISTR that this was the case
<seb128> pitti, let me check for the indicator, I'm not sure if they didn't drop the feature
<mitya57> do we want new git in saucy? (bug 1187662)
<ubottu> bug 1187662 in git (Ubuntu) "Sync git 1:1.8.3-1 (main) from Debian experimental (main)" [Undecided,New] https://launchpad.net/bugs/1187662
<anon^_^> pitti, sorry to bother you
<anon^_^> Has there been any movement internally to bring ubiquity up to parity with manual partitioning features lost by discontinutation of alternate cds?
<anon^_^> As of Ubiquity 2.14.6 (raring release) it is still not possible to manually create/configure lvm within an encrypted physical volume
<infinity> mitya57: autosync would pick it up anywya.
<anon^_^> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1187660
<ubottu> Launchpad bug 43453 in ubiquity (Ubuntu) "duplicate for #1187660 manual ("something else") live cd partitioner doesn't understand lvm properly" [Medium,Triaged]
<pitti> infinity: not from experimental
<infinity> Oh.
<infinity> Right.
<infinity> Just saw that.
<infinity> Then yes, I want a new git, and I'm syncing it. :P
<pitti> anon^_^: hm, I'm not working on ubiquity; I haven't heard of plans to extend that, maybe xnox or stgraber know
<xnox> anon^_^: there are wireframes done, and I did start implementing it, but it wasn't finished and it isn't a priority to complete at the moment.
<pitti> seb128: ah right, u-m tells me to reboot; but that doesn't really help for apt-get
<xnox> anon^_^: thus I marked your bug as a duplicate of an earlier one.
<anon^_^> xnox any sort of timeline?
<anon^_^> sorry i just noticed, logged out awhile back
<seb128> pitti, the indicator is still supposed to turn red afact but better to check with larsu/ted/charles
<seb128> pitti, src/dialog.c:	return g_file_test("/var/run/reboot-required", G_FILE_TEST_EXISTS);
<pitti> -rw-r--r-- 1 root root 42 Jun  5 11:06 /var/run/reboot-required
<pitti> yep, definitively
<pitti> seb128: err, is that from the indicator? it's hardly a dialog
<seb128> pitti, if you pick shutdown, does the dialog tell you that restart is needed?
<pitti> no
<seb128> it should
<pitti> also, why would I pick shutdown
<seb128> oh, but we replaced those dialog by unity ones
<tkamppeter> OdyX, the only way to replace the removed broadcasting/browsing in CUPS is to use avahi-daemon and cups-browsed and use package dependencies to get the smooth transition for the user.
<pitti> well, I would, but it seems xnox doesn't, he always just suspends
<seb128> pitti, sorry, logout
<pitti> seb128: same thing though; it's the other way around, people wouldn't log out until they see that they need to reboot
<pitti> hence the nice "turn indicator red for reboot"
<seb128> pitti, to check with larsu/ted/charles, I'm sorry but I'm unsure of the details, I seem to remember that mpt/design told them to drop the red entry but I'm not sure now
<pitti> ack
<seb128> pitti, well, update-manager tell you to reboot after upgrade
<seb128> so users should see it
<infinity> I'm not sure the red was all that intuitive, but we need *something* to inform people who aren't using update-manager.
<seb128> it even don't let you a choice, they removed the close button from that dialog
<pitti> yeah, that's nasty, too
<infinity> My motd doesn't even seem to be yelling at me about /var/run/reboot-required anymore.
<infinity> Hrm.
<seb128> infinity, if people are smart enough to not use our provided tools they should be smart enough to know when to reboot :op
<infinity> Maybe.
<infinity> I like the nag.  I forget after a while.
<infinity> Like, I'll upgrade and know I needed to reboot, but then work for another two days and forget. :P
<pitti> yeah, that's why I liked the red indicator
<infinity> The following packages have been kept back:
<infinity>   gcc-4.8-base:i386 libgcc1:i386 libstdc++6:i386
 * infinity looks sideways at apt.
<seb128> infinity, pitti, xnox: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.10/revision/275
<seb128> ok, found it back
<pitti> *sniff*
<infinity> Sadness.
<pitti> slangasek: yay, binutils succeeds now \o/
<pitti> (the autopkgtest)
<infinity> hallyn: Grr.  You dropped my qemu change.  Again.
<infinity> hallyn: Are you merging in a way that ignores the archive?  Should I be committing somewhere magical?
<OdyX`> tkamppeter: IPP doesn't work anymore ? Also, could you comment on the bug, it would be very helpful.
<Laney> mardy: hey, subscribed you to a couple of uoa/eds bugs that I found if you've time to look at them some time :-)
<ogra> pitti, slangasek, uuuh ... with bug 1187616 you need to be super duper careful, we already load all firmware in android, some devices really dont like if it gets loaded twice
<ubottu> bug 1187616 in systemd (Ubuntu) "udev firmware handler needs to support multiple firmware sources for Ubuntu Touch" [Undecided,Fix committed] https://launchpad.net/bugs/1187616
<dholbach> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<pitti> ogra: do drivers issue a firmware uevent if they already have the fw loaded?
<pitti> ogra: if this gets in the way, it's fine to revert of course; it just sounded to me like something which is needed
<ogra> (preferably you leave it to the binary driver to use it's hardcoded path (which means you need to have the right mountpoints) and dont have udev intervene at all here)
<ogra> pitti, well, it will help for some drivers, but definitely break some too
<pitti> ogra: OK, I leave it to you and slangasek to figure out what needs to happen :)
<pitti> ogra: but drivers definitively shouldn't ask for firmware if they already have it
<ogra> normally the android driver has a hardcoded firmware path and probably a fallback ... that is the reason why we need to have the android mountpoints in ubuntu at the right places
<ogra> pitti, well, depends, the drivers load their stuff inside an lxc container we probably dont have the info that it is loaded outside of that container
<pitti> lxc containers don't have their own drivers/kernels
<ogra> preferably we dont want to handle drivers under ubuntu at all if they are alreayd set up in the container ... *but* we want udev to provide the same interfaces in /dev that the container has
<ogra> no, but their own userspace that acts completely different from ours
<pitti> firmware information isn't in /dev, it's in /sys (and uevents); those should be shared across all containers
<ogra> theoretically all deviCes should be handled in the container and our userspace only talks to them through the platform-api sockets and /dev
<pitti> ogra: alright; as I said, if you figure out how it ought to be, feel free to upload or poke me to upload
<ogra> yeah, i'lll need to talk to steve for sure ... and i guess that needs some deep testing
<ogra> i think we ratrher want an option to ignore device initialization and just some rules that mimic the android /dev for us
<pitti> ogra: would be interesting to see if there is actually a driver which we need to handle that way
<ogra> lxc-android-config already ships a bunch of rules ...
<pitti> ev: https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=martin.pitt@ubuntu.com&period=month says "no such user", and https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=pitti&period=month has "no data to display"; is that not the LP user ~pitti, but something else perhaps?
<pitti> ev: or not the packages I'm subscribed to in LP?
 * ev looks
<ev> user=pitti is definitely correct, by the way
<pitti> ev: well, in the very best case there just are no crash reports in my packages, but I wouldn't trust that yet :)
<ev> no, there should be
<ev> if you take your name out, there are apport crashes in that list
 * pitti tries https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=seb128&period=month
<ev> and I would assume you're at least subscribed to that :)
<ev> bdmurray: ^ thoughts? The API call is definitely returning the empty set: https://errors.ubuntu.com/api/1.0/most-common-problems/?format=json&limit=100&release=Ubuntu%2013.10&user=pitti&period=month
<pitti> yes, I'm sub'ed to like two dozen
<seb128> pitti, is that a "pitti haz no bog but seb does"? ;-)
<pitti> "An error occurred while trying to load the most common problems"
<pitti> seems seb128 is oversubscribed and over-bugged :)
<seb128> lol
<seb128> works here
<seb128> but 13.10 has very few users
<seb128> those stats are not very useful
<ev> filed https://bugs.launchpad.net/errors/+bug/1187723 to track it
<ubottu> Launchpad bug 1187723 in Errors "Martin Pitt's subscribed packages view returns the empty set" [Undecided,Triaged]
<ev> bdmurray: if you don't have time for that one, let me know and I'll have a look
<pitti> https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=cjwatson&period=month
<pitti> that just has one bug
<pitti> presumably wrong, too
<seb128> pitti, well, as said the numbers are low, see https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=month
<seb128> pitti, entry 16 is down to 4 reports in a month
<pitti> yeah, that's right
<seb128> that seems buggy low though
<pitti> yes, I meant "right, it's too low and looks wrong"
<seb128> ev, how long does it take between submit and datas supposed to be listed on e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day ?
<ev> seb128: it's instantaneous
<ev> well
<ev> if it's Python :)
<ev> for binary crashes that haven't already been retraced, it needs to go through that process first
<ev> and that can take some time - we're having issues at the moment around the Swift backend storage we use for the core dumps
<ev> in that it's not accepting them
<seb128> ev, pitti and Laney reported some issues earlier today on evolution-data-server and signon-ui and the report has 0 entry for those components today, is that normal?
<ev> but we're also in the middle of a move to oops.canonical.com, which makes debugging that tricky
<seb128> ok
<ev> yes, because e-d-s is a binary and the retracers are having difficulty due to the problem mentioned above
<ev> working to resolve it as quickly as I can
<seb128> no worry
<seb128> it's not a today problem, but the 13.10 number of reports seem low (that's not new) and I was wondering if that's just low number of users or if there is a bug and we loose datas on the way
<ev> seb128: sure, and thanks for making me aware of it. I suspect it's a combination of the two. We don't get a lot of users this early in the release, but there's also the bug preventing retracing from happening. We're not losing data per-se, as we're just dropping core submissions on the ground. We still have all the metadata for each crash that comes in, and when a matching core file is submitted from a different user and its finally retraced, those
<ev>  crashes will be bucketed.
<seb128> ev, ok, good to know that the datas are not lost, thanks for the status update
<ev> seb128: yeah, it's a big thing of mine that we try as hard as we can to never drop the actual reports or ever remove them from the DB
<ev> we often need to iterate back over them as we learn how to do things better or add new features
<ev> and big gaps would make future calculations of "are we doing better?" look weird
<ev> sure thing though. As always, let me know if anything else is broken
<mardy> Laney: thanks! I asked help from the Evolution maintainer, in turn :-)
<Laney> :D
<mardy> Laney: did you try killing evolution-calendar-factory?
<Laney> mardy: for the indicator one?
<Laney> (no, but can do)
<mardy> Laney: I'd say for both
<Laney> ok, let me re-add the account and try
<mardy> Laney: I guess they are very strictly related
<Laney> yes, I think so
<Laney> hm, straight after adding it I get told it's not authorised and then "Grant access" takes me to a page with standard Username/Password entries instead of the usual webview
<mardy> Laney: weird... you are talking about the Google account?
<Laney> yes
<mardy> Laney: ah, maybe it's not that weird; I think that for the calendar EDS is using a plain username/password authentication
<Laney> so it could be choking on my 2fa then?
<Laney> killing the calendar factory made me get the same not authorised thing
<Laney> mardy: didn't make it work though
<Laney> but I suppose this is more information
<mardy> Laney: yes, it looks like the username/password is invalid, or anyway not enough to authenticate
<mardy> Laney: is that a 2-factor-auth enabled account?
<Laney> yep, both are (canonical and personal)
<Laney> well, canonical is 2 factor through Ubuntu SSO; don't know how that interacts with this
 * Laney tries adding that one
<dholbach> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * Laney remembers that he has an old google account without 2fa
<Laney> now, what are the details for that?
<xnox> Laney: despite 2fa/SSO on the google-account, for e.g. plain access (webdav, ical, smtp, imap, etc) you need "normal bog-standard google password" for canonical accounts or the "static application specific" passwords for personal accounts.
<xnox> Laney: if you don't remember it, #is can reset it for you. (there is no web ui to do it)
<Laney> I have the Google account password, but giving that on the "plain" page didn't make it succeed
<xnox> =(
<ogra> the touch images need all android groups in the system on the ubuntu side with fixed GIDs ... currently we create them at build time with a live-build hook script, i'm planning to move all this into a postinst of the lxc-android-config package, does anymone know what happens if a group with a GID i need already exists ?
<Laney> mardy: Aha â I added another, non 2fa, account and that seems to work beautifully.
<cjwatson> ogra: If you need fixed GIDs then you must coordinate with the Debian base-passwd maintainer
<cjwatson> ogra: (i.e. me)
<Laney> at least email and calendar in evo, and I got loads of spam friend requests on empathy
<cjwatson> ogra: Send mail to base-passwd@packages.debian.org with your requirements and we can talk through them
<ogra> cjwatson, i think they are all above 1000, i'm just wondering
<Laney> so it seems like the altenate authentication workflow needs more work (even if that's to fail better for now)
<cjwatson> ogra: Please send me mail since it sounds like you're doing bad things and I want to help you do good things instead. :-)
<ogra> and i dont have a complete list yet ... only know the wones we use already ... perferably we want them alll though
<ogra> cjwatson, well, we dont have much choice ... the GIDs are hardcoded in the kernel
<ogra> android is doing bad things here
<ogra> but yeah, let me get a full list and i'll mail
<cjwatson> Oh, they're specific fixed GIDs forced on you by external forces
<cjwatson> That's ... not ideal
<ogra> yeah
<ogra> thats android :)
<ogra> and binary daemons might rely on it
<cjwatson> Still, I'd like to have a mail record of what's going on here, even if we can't do anything about it
<ogra> right, i'll first discuss that with rsalveti
<ogra> in any case i want it in a package postinst instead of having a build script
<asac> ogra: dont do bad things - i told you before :-P
<ogra> haha
<asac> not sure why the good ogra is always doing such things
<tkamppeter> OdyX`, I have commented on the bug now.
<cjwatson> I don't suppose there's any hope of libhybris doing whizzy GID mapping for us so that we don't have to know about the Android GIDs on the Ubuntu side?
<cjwatson> For that matter, shouldn't this be handled by running the Android binary daemons in a container?  Container GIDs don't have to match the host ones
<ogra> the issue is that the kernel refuses device access for some bits if the GID doesnt match exactly
<cjwatson> Mm.  I thought this was the kind of thing libhybris was supposed to be able to help with.
<ogra> i.e. network access is only allowed for GID 3002 3003 3004
<ogra> so if we access devices on the ubuntu side they need to be owned by the right group and the user needs to be part of them
<ogra> radio is similar ...
<ogra> live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot has the current list we use
<ogra> (but there are a lot more)
<ogra> aha
<ogra> found the mapping in the android tree
<ogra> http://paste.ubuntu.com/5735451/ should be the full list
<ogra> seems to be all above 1000
<cjwatson> The whole thing is based on fundamentally different assumptions about how things are laid out though; e.g. the system user at 1000
<ogra> yeah, well
<ogra> dont tell me :)
<cjwatson> I kind of think we're going to get ourselves into trouble if we assume that the only way to address this is to create matching groups on the Ubuntu side
<ogra> we cant hack binary daemons ro drivers that are linked against this
<ogra> we could change thee kernel, but that wont fix bianry blobs
<ogra> *binary
<cjwatson> We could, for example, punt certain kinds of device access behind the scenes through the Android container
<ogra> depends if you access stuff directly through a socket or not
<cjwatson> You use the C library to create the socket, so ...
<ogra> i.e. ofono attaches to the binary vendor rild via a socket
<ogra> which has to be the original one from android
<ogra> (linked into /dev from the android /dev)
<ogra> might be possible to have a wrapper or some such
<ogra> but i dont think anyone even throught about GID remapping yet
<cjwatson> Somebody might have to :)
<ogra> definitely ...
<cjwatson> Anyway, if you do create these groups, please create only the minimal set you absolutely need so that any future cleanup is kept to a minimum and there's the lowest probability of clashes
<ogra> yeah, indeed
<ogra> the above live-build script has the minimal set we need atm
<ogra> (only 10 groups with fixed GID in there atm)
<cjwatson> You'll have to just use 'getent group GROUP_NAME >/dev/null || addgroup --gid NEW_GID GROUP_NAME', I think, or similar, and if it fails there's nothing you can do
<cjwatson> You can't even use --system since these aren't in the system range
<ogra> yeah
<cjwatson> Do please use addgroup rather than the low-level groupadd stuff you're doing right now though
<cjwatson> And OMG what is all that madness adding global static groups
<cjwatson> Most of that script desperately needs to be deleted
<ogra> will do, i need to discuss that with sergiusens  and rsalveti anyway before i do anything ... looking at the script it seems to not care about GIDs at all if for example a group already exists
 * doko watches cjwatson's blood pressure going up ...
<cjwatson> Heh
 * mlankhorst puts cjwatson in AID_UNUSED1
 * ogra points out that he is just the messenger ... not my script 
<ogra> i just want to clean that up and not have it in the build scripts
<cjwatson> Sure, I know, but you can be a messenger in the other direction too :P
<ogra> thats what i plan
<cjwatson> There might be an argument for it creating admin (but it MUST use 'addgroup --system' to do it, if it does); there is absolutely no justification for it creating any of the groups listed in /usr/share/base-passwd/group.master
<cjwatson> Especially not in that invalid way
<ogra> i consider sanitizing this part of the container flip
<ogra> which as i said above, has no real planning at all yet
<cjwatson> And it should use adduser to add the user to that set of groups, not usermod
<ogra> yeah
 * cjwatson attempts to haul this up to saner levels of the stack
<ogra> let me discuss with our android heads first, before we take any action ...
<ogra> i think *if* we have such s script it definitely belongs into the android container package though ... not in the build scripts (i.e. on x86 you most likely would want that stuff at all)
<ogra> *wouldn't
<hallyn> infinity: I woulda held off but there was a cve fix in there too.  As for the sources, I keep them at github.com/hallyn/qemu, and I rebase against debian-unstable from git://anonscm.debian.org/pkg-qemu/qemu.git
<hallyn> infinity: if you prefer i can ping you before a next update - though i'm hoping i'm done for awhile
<hallyn> infinity: i swear i checked for later updates!  but i guess i did that before rebasing - sorry
<hallyn> won't happen again
<hallyn> (pushing your change to github for good measure0
<ogra> bug 1187750
<ubottu> bug 1187750 in livecd-rootfs (Ubuntu) "system group creation for android container device access needs to move out of the build scripts" [Undecided,New] https://launchpad.net/bugs/1187750
<ogra> cjwatson, ^^^
<cjwatson> ogra: Independent of that, can I just go ahead and delete the spurious attempts to create global static groups (the ones base-passwd ships on all systems)?
<ogra> cjwatson, definitely
<cjwatson> Whoa, what the heck is that stuff with the audio gid :-(
<cjwatson> That's going to break as soon as base-passwd is upgraded
<ogra> yeah
<ogra> thats why the touch images are not officially supporting apt based upgrades i guess :)
<cjwatson> Well it's just plain wrong
<cjwatson> If you need a fixed gid for audio handling that doesn't match the one in base-passwd then it must be called something else
<ogra> android_audio then ... though that will obsolete the normal audio group
<cjwatson> Better to obsolete it than to screw it over
<ogra> indeed
<ogra> asac, you might want to monitor the ablve bug too probably
<ogra> *above
 * ogra ponders to file the same thing about the environemnt setup ... live-build currently overwrites /etc/environment and fills it with a ton of stuff
<ogra> (in live-build/ubuntu-touch/hooks/48-setup-env.chroot )
<cjwatson> mm, that seems like it should be set by a session script or something
<cjwatson> SHLVL=1 ???
<cjwatson> Did somebody run env and copy and paste, or something?
<ogra> could be
<sergiusens> cjwatson: ogra I already removed some gid checking which you never saw, like access to surfaceflinger or sensors
<ogra> i have no idea how these scripts were developed initially
<ogra> it predates my involvement
<sergiusens> for audio, I'm guessing most of it will go away once jim finishes up his native ubuntu audio integration
<ogra> sergiusens, well, the question is what do we really need
<sergiusens> rild is a pain though
<ogra> i assume for everything that talks directly to an android socket like rild we wont get around having the groups
<ogra> yeah
<ogra> but for all other stuff we might be able to find a better solution
<cjwatson> depends, as I say, what interface android is using to find out the group id of its peer, and whether that can be fooled
<ogra> or even have a wrapper on the ubuntu side that does some re-mapping or so
<ogra> cjwatson, well, android obviously uses its header files ... but i know that the kernel also uses some of this
<ogra> the prob are really the binary bits we dont have contol over ... though only if we talk to them directly
<sergiusens> cjwatson: ogra I'll take this one and start on Monday if rsalveti isn't eager to (I'm off tomorrow and the day after)
<ogra> sergiusens, whats your solution ?
<sergiusens> ogra: let me look at it first and then propose something ;-)
<ogra> is anything else but ofono talking directly to rild ? we might be able to have a wrapper in there that does the remapping
<sergiusens> ogra: so gps creates an IPC socket on manta on /data
<sergiusens> the binary blob that is
<sergiusens> so let me consolidate all the cases we have and see if I can factor something common for all
<infinity> hallyn: S'all good, was just mildly annoyed when I saw component-mismatches explode again.
<ogra> though i dont know if there is more than rild .... i guess there is a reason why we have 10 groups already ... they are definitely not all rild related
<cjwatson> mitya57,seb128,xnox: the insighttoolkit4 build failure isn't making a lot of sense to me, partly because I don't know cmake that well.  Can any of you help?  At first glance I thought it was basically a missing build-dep on libvtkgdcm2-dev, but I don't think that's right - insighttoolkit4 doesn't really need it, and if you compare with e.g. ...
<cjwatson> ... https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4&arch=sparc&ver=4.3.2-1&stamp=1367450169 (yes, it fails later, but ignoring that), there's the same message about /usr/lib/libvtkgdcm.so.2.2.3 but it's non-fatal
<cjwatson> indeed even building insighttoolkit4 on current unstable seems to succeed, or at least get well past the configuration step
<cjwatson> so I don't understand what's different between Debian and Ubuntu here
<cjwatson> cmake is identical, and neither the gdcm nor insighttoolkit4 changes seem relevant
<zul> cjwatson: hi can you promote python-mimeparse python-testtools is in dep wait because of it (mir https://bugs.launchpad.net/ubuntu/+source/python-mimeparse/+bug/1187527)
<ubottu> Launchpad bug 1187527 in python-mimeparse (Ubuntu) "[MIR] python-mimeparse" [High,Fix committed]
<cjwatson> zul: done
<zul> cjwatson:  thanks
<ion> mvo: Hi. Are you around?
<mvo> hey ion, yes
<ion> mvo: Does this look okay? ttps://github.com/ion1/apt/commits/debian/sid
<ion> Err. https://github.com/ion1/apt/commits/debian/sid
<wzssyqa> doko: hi, any idea about howto get multilib bootstrap?
<doko> context?
<mvo> ion: from a first look yes, thanks! will you propose it for merging?
<seb128> mvo, hey, how are you?
<ion> mvo: Do i need to do something special to get it merged or can you just do it?
<seb128> mvo, do you plan to merge apt on the current Debian version at some point?
<mvo> seb128: can do, sure! I'm well, thanks
<seb128> mvo, thanks ;-)
<seb128> mvo, glatzor: do you know if anyone is porting aptdaemon to the pkgkit 0.8 interfaces?
<mvo> ion: I can just do it, there is a small "send pull request" or something that you can use to make it easier for me to not forget about it
<glatzor> hello seb128, mvo. Actually yes: me :)
<seb128> glatzor, hey, how are you?
<glatzor> seb128, mvo I am currently on vacations and hopefully will find some time tomorrow or the day after to continue the work. I already started the port. But the interface changed really a lot.
<seb128> glatzor, great, are you still working on it (the vcs pointed on the blueprint we found didn't get any commit this year) ... do you have an estimate on how much work that is/when it will be ready?
<glatzor> seb128, I am fine!
<glatzor> seb128, perhaps end of month to get it stable.
<glatzor> seb128, do you need the packagekit 0.8 client library?
<seb128> glatzor, I'm asking because we got the new packagekit uploaded and we were wondering if we should revert that or try to go through the transition
<glatzor> seb128, revert it for the moment
<seb128> glatzor, it's currently blocked in saucy-proposed
<seb128> Laney, pitti, cjwatson: ^
<glatzor> seb128, that is my suggestion
<pitti> right, so same conclusion that we had yesterday
<pitti> hey glatzor, wie gehts?
<seb128> cjwatson, btw saw your ping about cmake, I'm not really fluent in cmake either but I can try having a look a bit later if mitya57/xnox don't ping back/have a clue about the issue
<glatzor> pitti, supi! could not be better. The sun is shining here in Bavaria!
<glatzor> pitti, and even in Scotland we only had one hour of rain in a whole week
<pitti> glatzor: I know, at last! I'm enjoying it since yesterday, too (Augsburg)
<doko> wzssyqa, context?
 * rsalveti checking backlog
<ion> mvo: I actually tried making a pull request to you when i noticed you have a github account, but since my repo isnât already a fork of yours, github doesnât seem to allow that. Let me delete the repo, fork yours and push again, a momentâ¦
<wzssyqa1> doko: I am working on mips64(el) ports, and the system can bootstrap now, while I have no idea about how to break the cycle of eglibc and gcc to enable multilib
<rsalveti> cjwatson: ogra: sergiusens: I believe we can come up with a mix of disabling group/user id checking and handling weird setups (and binary blobs) via libhybris
<rsalveti> in a way we could indeed have a better setup than just matching user and group ids
<rsalveti> it's just that we never really spent any time on that
<ogra> rsalveti, yeah, i was guessing so, but waht about stuff that talks directly to i.e. rild ?
<rsalveti> I can take a better look in more details later today and see what can be done on the android side
<ion> mvo: mvo5, correct?
<mvo> ion: yeah
<rsalveti> ogra: that's fine, we just need to change the permission for the sockets
<rsalveti> for sockets we'd need a script or something anyway as we'd need to either link or bindmount the /dev/socket from android
<ogra> well, we only get the sockets by linking the /dev/socket dir from android to /dev
<rsalveti> as that's created by android
<ogra> if we chjange them on our side it might break
<rsalveti> right, and we can probably do something smart there to change the default permission as well
<rsalveti> I don't think so
<doko> wzssyqa, is this for Ubuntu?
<ogra> lxc-android-config already links /dev/socket
<rsalveti> ogra: also, we might need to create a group for modem or such anyway (if we don't have it already)
<ogra> but indeed doesnt change any permissions yet
<ogra> we have dip and dialout iirc
<rsalveti> I'm not worried about that at all, after all they are just sockets
<ogra> well, if rild gets along with it
<rsalveti> and we can hook up functions to check group and user id in hybris
<wzssyqa1> doko: ubuntu and debian share the same eglibc and gcc, right?
<ogra> tony got mew scared with his complaining over the last weeks :)
<rsalveti> and do the matching there if really needed
<rsalveti> ogra: well, I believe we should be fine, I'll be checking ril/ofono support with todays image later today
 * ogra reboots into todays flipped image and prays the shell will come up automatically 
<rsalveti> with the flip container, just to be sure it works
<ogra> sigh
<ogra> seems it doesnt :(
<mitya57> cjwatson: "internal compiler error: Segmentation fault" on powerpc? not a pleasure to debug...
<rsalveti> ogra: I can easily test ofono without the shell :-)
<ogra> hah, but having adbd use bash is so much cooler ... thanks stgraber
<ogra> hmm, seems everything butt the shell came up
<ogra> bah ... was just missing an rm
<doko> yes
<ogra> sigh
 * mitya57 realized that he was looking at wrong log
<teolemon> Hi, I was wondering in which channel I could contact somebody from the ubuntu.com infrastructure (to install a webapp on ubuntu.com)
<cjwatson> mitya57: meh, I was thinking of the i386 failure
<mitya57> cjwatson: "* mitya57 realized that he was looking at wrong log"
<cjwatson> ah
<wzssyqa1> doko: then, I tried to cross build eglibc with clang. I also tried to build it with the gcc-multlib from mipsel.  all of them failed
<doko> wzssyqa1, sorry, can't help you with that. bootstrapping, not much time. you may want to look at the powerpc-cross-toolchain-base and gcc-4.8-powerpc-cross packages in ubuntu
<wzssyqa1> doko: thanks
<ev> bdmurray: https://oops.canonical.com/reports/WHOOPSIE-PROD/
<ev> ^ that's the new home of the OOPS reports. /oops-local is dead.
<ev> (though it's remains for hysterical raisins
<mitya57> cjwatson: GDCMTargets.cmake hasn't changed since raring, so it looks like new CMake made missing files cause an error instead of warning
<mitya57> cjwatson: does it build in sid with new CMake?
<mitya57> Let me test myself
<cjwatson> it builds in current sid
<cjwatson> with whatever's default there
 * xnox is somehow guessing that vtk needs rebuild against python2.7.5 and I'm not sure how gdcm managed to build correctly without a rebuilt vtk.
<cjwatson> may be true but I'm not sure how it relates to this cmake weirdness?
<xnox> (that rebuild needs to happen regardless, but it might not help insighttoolkit at all)
<mitya57> cjwatson: yes, it is really a change in cmake: http://paste.ubuntu.com/5735889/
<mitya57> so my suggestion will be to add that B-D
<xnox> mitya57: but with that b-d installed, it still FTBFS.
<mitya57> it adds: 'message(FATAL_ERROR "The imported target \"${target}\" references the file \"${file}\"'
<Laney> what's that a diff of?
<mitya57> Laney: a diff between usr/lib/gdcm-2.2/GDCMTargets.cmake in sid and saucy
<mitya57> xnox: with the same error?
<xnox> mitya57: hm? the diff between saucy-proposed and sid is none: http://paste.ubuntu.com/5735895/
<xnox> damn, nothing in saucy-proposed.
<xnox> i mean between: libgdcm2-dev_2.2.3-1_amd64.deb in sid, and        libgdcm2-dev_2.2.3-1ubuntu2_amd64.deb in ubuntu
<Laney> actually it seems it is different
<Laney> the first change in the diff is probably the clue
<xnox> Laney: hmm. true.
 * xnox thought debdiff did recursive diff as well, I guess not.
<bdmurray> seb128: ah, thanks I'll have a look
<Laney> doesn't diff the files inside, no
<mitya57> xnox: do you have a build log of that in saucy with the b-d added?
<bdmurray> ev: the oops report is great
<xnox> Laney: gdcm should get binNMU in Debian then.
<seb128> bdmurray, hey, thank you
<bdmurray> ev: oh, but the links don't work?
<ev> bdmurray: the ones up top don't yet, but the ones on the far right do
<ev> and then there are the urls in the middle for the request itself which will never work (though maybe we can fix that, even though it doesnt make sense clicking them for daisy.ubuntu.com)
<ev> it would for errors.u.c though
<mitya57> there's something wrong with freenode today...
<Laney> mitya57: CMake Error at /usr/lib/gdcm-2.2/GDCMTargets.cmake:155 (message):
<Laney>   The imported target "php_vtkgdcm" references the file
<Laney>      "/usr/lib/vtkgdcm.so"
<Laney>   but this file does not exist.  Possible reasons include:
<cjwatson> right, but the same thing is a warning in an unstable build
<Laney> yes, we established that gdcm's rebuild in Ubuntu caused it to regenerate its .cmake file which upgraded such things to errors
<pitti> cjwatson: with just the two removals and two rebuilds in -proposed for reverting PackageKit, do you think we need any particular magic there? (the rebuilds will just be -0ubuntu2)
 * pitti bbl
<mitya57> ... because we have only /usr/lib/libvtkgdcm.so.2.2
<Laney> libvtkgdcm.so -> that, yes
<cjwatson> pitti: I think that's OK - just make sure the removal has been published before uploading the reverts
<mitya57> Laney: should we add that symlink?
<cjwatson> pitti: and you might want to sync-blacklist or something so it stops showing up on merges.u.c
<Laney> I don't know
<Laney> why is it looking for the wrong file?
<bdmurray> pitti, ev: re bug 1187723 it works for releases other than 13.10
<ubottu> bug 1187723 in Errors "Martin Pitt's subscribed packages view returns the empty set" [Undecided,Triaged] https://launchpad.net/bugs/1187723
<ev> hmm
<bdmurray> https://errors.ubuntu.com/?user=pitti&period=month
<cjwatson> Laney: I think it's a cmake file that has basically a bunch of optional imports
<cjwatson> use these if they're here
<Laney> see mitya57's earlier pastebin
<Laney> it's the diff of the relevant .cmake file between sid and saucy showing that some things were upgraded to errors
<Laney> at least that's how my cmake-stupid brain reads it
<slangasek> seb128: update-manager gsettings> ack
<slangasek> bdmurray: will you take care of fixing update-manager too, then?
<slangasek> pitti: binutils> sweet :)
<bdmurray> slangasek: yes
<mitya57> Laney: err, libvtkgdcm2-dev does ship that symlink (proof: http://packages.ubuntu.com/raring/i386/libvtkgdcm2-dev/filelist), how can it happen that that file is missing?
<Laney> note the 'lib'
<mitya57> oh
<cjwatson> and libgdcm2-dev doesn't depend on libvtkgdcm2-dev, but vice versa
<Laney> php5-vtkgdcm installs -rw-r--r-- root/root    748680 2013-06-03 09:27 ./usr/lib/php5/20100525+lfs/vtkgdcm.so
<Laney> xnox is trying his best to get this stuff removed from testing ;-)
<mitya57> :)
 * mitya57 's cmake knowledge ends here
 * Laney glares at freenode
<xnox> slangasek: what's your value of /proc/sys/vm/dirty_ratio ?
<mitya57> I think it's a bad idea to have /usr/lib/vtkgdcm.so -> /usr/lib/php5/20100525+lfs/vtkgdcm.so symlink, as it's a php-specific library and shouldn't be exposed to the system
<mitya57> so we need to add more search paths to cmake instead
<slangasek> xnox: so based on that side conversation... I guess you don't have /tmp on tmpfs?
<xnox> slangasek: no, since I was affected by "it takes to long to clear /tmp" bug which you weren't affected by.
<Laney> mitya57: gdcm's rules file manually moves it out of /usr/lib/ to that location
<mitya57> ... so we can't blame upstream
<Laney> At this point you probably need some cmake to get php5-vtkgdcm to leave the right trail behind for its consumers
<Laney> Might just be sensible to take these findings to debian-med and let them deal with it...
<mitya57> Let's file a bug then?
<slangasek> xnox: ah right :)
<Laney> please do
<Laney> maybe confirm it breaks rdeps after a rebuild though
<doko> infinity, https://launchpadlibrarian.net/141721049/buildlog_ubuntu-quantal-amd64.gcc-4.8_4.8.1-2ubuntu1~12.10_FAILEDTOBUILD.txt.gz
<doko> In file included from /usr/include/fenv.h:58:0,
<doko>                  from ../../../../src/libquadmath/math/ccoshq.c:23:
<doko> ../../../../src/libquadmath/math/ccoshq.c: In function 'ccoshq':
<doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
<doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
<doko>     ^
<doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
<doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
<doko>     ^
<doko> didn't we fix that in eglibc? or is it not yet there?
<infinity> doko: SRU not uploaded for that yet, I should do that this week.  Was waiting to queue up a few things in one go.
<bdmurray> barry: were you still going to have a look at bug 1094218?
<ubottu> bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [Medium,Confirmed] https://launchpad.net/bugs/1094218
<slangasek> barry: yeah, meeting ended ;)
<kenvandine> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<smoser> slangasek, around ?
<smoser> i'm guessing that jodh is not
<smoser> so you're the next best thing :)
<slangasek> smoser: ohai
<smoser> we're seeing an issue on raring upstart
<smoser> cloud-config is not running
<smoser> but it is : start on (filesystem and started rsyslog)
<smoser> and rsyslog *is* started (rsyslog start/spawned, process 1656)
<smoser> and it's start on is: start on filesystem
<smoser> so it would appear to me that cloud-config should have started.
<smoser> slangasek, ^
<slangasek> smoser: ok; so is mountall still running?
<smoser> stop/waiting
<slangasek> smoser: and is there any chance this is still another problem with upstart getting re-execed or config-reloaded and dropping in-flight events?  The fix for that is just about to land in raring SRU, but it's not there yet
<smoser> slangasek, i dont think so. as cloud-config would be the thing that would do an upgrade.
<slangasek> hmm
<smoser> and i dont see anything that cloud-inti woudl have done to initcitl reload
<smoser> i can let you in
<slangasek> ok
<sil2100> jamesh: ping!
<seb128> sil2100, it's like 2am for him, probably not the best time to have a pong
<sil2100> seb128: ACK, thanks
<smoser> slangasek, jamespage opened as bug 1187876
<ubottu> bug 1187876 in rsyslog (Ubuntu) "rsyslog stuck in 'spawned': Error in `rsyslogd': malloc(): memory corruption: 0x00000000007b2930" [Undecided,New] https://launchpad.net/bugs/1187876
<slangasek> smoser: and this failure is frequently reproducible on the affected machine?
<smoser> http://lists.adiscon.net/pipermail/rsyslog/2012-January/029268.html maybe relevant.
<smoser> jamespage, ^
<smoser> how frequent is this ?
<smoser> bah. that is reported fixed in 5.8.7 and we're 5.8.11 there.
<smoser> slangasek, i say give it a try (reboot) and see.
<jamespage> smoser, slangasek: 11/12 of the last first boots on the effected hardware
<sil2100> barry: ping!
<slangasek> smoser: rebooted, it seems to be taking its sweet time coming back up
<slangasek> smoser, jamespage: ok, reproduced on reboot
<smoser> slangasek, those systems take like 2 minutes to post
<slangasek> cute
<ion> Awesome, someone has made libappindicator bindings for Haskell.
<infinity> ion: I'm not sure you're using that word correctly.
<slangasek> because what indicators needed was greater uncertainty about how long things will take to display correctly
<ion> infinity: âhasâ? âbindingsâ? âsomeoneâ?
<infinity> ion: "awesome". :P
<ion> infinity: Ok, let me rephrase it: âExcellent!â
<slangasek> smoser: regression in the SRU from bug #1022545, which has an off-by-one error in its string handling.
<ubottu> bug 1022545 in rsyslog (Ubuntu Raring) "Backport upstream bugfix "$PreserveFQDN on" not working properly" [Undecided,Fix released] https://launchpad.net/bugs/1022545
<slangasek> smoser: not sure yet this is the cause of the malloc failure, but it looks probable as this is the only complaint out of valgrind
<cjwatson> ion: I think it would be a bad idea to upload Ubuntu-specific Haskell bindings, given how much we rely on Debian to keep that subsystem at all workable.
<cjwatson> Although I see libappindicator is in Debian - but an old version I think
<ion> Iâm actually not using the system packages at all for Haskell development, i also cabal installed happindicator under ~. Seems to work fine.
<slangasek> smoser: right, confirmed here that unapplying that patch fixes it.  So, critical SRU regression. :P  Thanks for raising this.
<infinity> slangasek: Added precise and raring tasks to https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1187808 due to your above conversation.
<ubottu> Launchpad bug 1187808 in rsyslog (Ubuntu) "PreserveFQDN fix introduces regression that might cause rsyslog not to start" [Undecided,Confirmed]
<slangasek> infinity: ack.
<Laney> ion: Since you only got negative comments - COOL! :-)
<ion> heh
<infinity> slangasek: Want to prep the 1-char fixes, or review them if I do it (I'd rather not be on the hook for verification, since I haven't bothered to reproduce).
<slangasek> caribou: please see above wrt the recent rsyslog SRU.  Do you happen to have the upstream git to hand, and is there a follow-up fix that we should take?
<infinity> slangasek: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff_plain;h=9c54bf41d02ba236137859ea5f12d6f048647349
<infinity> slangasek: Referenced in the bug.
<slangasek> ok
<slangasek> infinity: I'll take care of the uploads
<infinity> slangasek: Alright.  If you do 'em quick, I'll review before I head out for the afternoon.
<infinity> slangasek: And this seems like a valid case for expediting the accept/verify/release turnaroud, if you can find someone to verify.
<slangasek> I can verify it directly
<dobey_> is there no easy way to fix broken package import branches?
<slangasek> no.
<slangasek> barry: ^^ do you know who, if anyone, is still minding the store on those?
<cjwatson> slangasek: wgrant and xnox are the people I go to for those
<slangasek> ok
<slangasek> dobey: ^^ maybe that helps?
<cjwatson> It has to some extent been borged into LP maintenance
<dobey> hmm, ok
<barry> slangasek: you can perhaps beg someone on #udd but otherwise, you will have a sad
<barry> (maybe the udd mailing list too)
<barry> but in general, nobody is
<cjwatson> barry: I think it's better than that.  William in particular has been fixing a fair few problems AIUI.
<barry> cjwatson: that is *great* news!  wgrant ftw
<seb128> bdmurray, what's the need of dropping that key from the update-notifier schemas rather than marking it deprecated? did you grep the archive in case anything else is relying on it?
<seb128> bdmurray, it's just 5 lines of text in a .xml, I though it would have been easier to keep it flagged as deprecated than dropping it, especially when missing key is abort() reason for gsettings
<seb128> it's sort of an "abi" break for no real benefit
<slangasek> infinity: rsyslog uploaded for saucyraringprecise
<infinity> slangasek: Yeahp, queuebot told me.
<slangasek> k
<ogra> saucyraringprecise ? is that the new name for the rolling dev release ?
<slangasek> seb128: well, nothing should be using that setting; the fact that things fail in its absence may have come as a surprise to us, but it's better to root out any references to that key and fix them all at once
<ogra> :)
<seb128> slangasek, ok, so you are archive greping for other users of the key if there is any?
<infinity> I prefer presaucing.
<dobey> infinity: one must sauce precisely.
<infinity> Trying so hard to not say "that's what she said" right now.
<slangasek> seb128: the likelihood of anything other than u-m and u-n using this key is so small that I'm not sure it's worth the time of doing that, vs. just letting any bugs be found and reported
<seb128> slangasek, ok, wfm
 * seb128 checks software-center and aptdaemon in case
<seb128> slangasek, btw I tagged/pushed your upload to the vcs of update-notifier to be able to add my fix on top, hope it's ok ;-)
<bdmurray> I'll check the archive just in case
<glatzor> seb128, aptdaemon doesn't use it
<seb128> glatzor, saw that, thanks
<glatzor> seb128, but I don't know about s-c
<seb128> neither does s-c
<glatzor> ok
<slangasek> seb128: which upload?  I think bdmurray did the last u-n upload
<seb128> slangasek, the one from yesterday that dropped the key
 * barry returns to the porch for some quality time with gpg
<bdmurray> seb128: what branch are you using?
<seb128> slangasek, oh, sorry, bdmurray uploaded it seems, I saw your name at the top of the changelog...
<seb128> bdmurray, ~ubuntu-core-dev/update-notifier/ubuntu/
<slangasek> ok, seriously, who broke 'bzr info'?
<seb128> bdmurray, the one listed in debian/control
<bdmurray> seb128: we've been using
<bdmurray> er nevermind
<seb128> bdmurray, well, this morning it was UNRELEASED, maybe you forgot to push the commit where you flagged it as a release?
<seb128> everything else was current
<bdmurray> seb128: yeah, I fixed that and merged your 0.137 changes
<seb128> hum
<seb128> I had pushed my changes to the vcs
<seb128> did you overwrite?
<seb128> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<seb128> Use the merge command to reconcile them.
<seb128> shrug
<bdmurray> hmm, I did an updated before pushing...
<seb128> or maybe I forgot to push as well :p
<seb128> anyway no worry
<doko> seb128, on raring:
<doko> Setting up libgtk2.0-0:armhf (2.24.17-0ubuntu2) ...
<doko> /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: 1: /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: Syntax error: word unexpected (expecting ")")
<seb128> seems to be alright now
<seb128> bdmurray, thanks
<doko> is this expected?
<doko> armhf is the foreign arch
<seb128> doko, no, and not seen before ... is that consistent or a one time error? the arm builders tends to have corrupted datas sometimes it seems
<doko> no, that's a local install
<slangasek> doko: that's the postinst trying to exec the foreign-arch indexer
<slangasek> there's a || true after it in the postinst, but it'll still spit out errors
<slangasek> I've never seen that particular error before fwiw
<doko> ahh, yes I see
<slangasek> but if you don't have armhf qemu support in place, errors of /some/ kind are expected
<infinity> slangasek: Alright, acceptiferated, and I'm heading off for a bit.  Give me a nick highlight nudge when you're satisfied it's all verified.
<smoser> cjwatson, are you around ?
<cjwatson> smoser: not really, e-mail?
<cjwatson> Unless it's really quick
<smoser> sure.
<xnox> dobey: i'm not an expert, but which package are you after? I can take a look.
#ubuntu-devel 2013-06-06
<straemer> Hey, I'm trying to build ubuntuone-android-music, and am getting a build error
<straemer> BUILD FAILED
<straemer> /home/stephen/.android-sdk-linux/tools/ant/build.xml:574: ../../ubuntuone-android-sso/ubuntuone-android-sso resolve to a path with no project.properties file for project /home/stephen/Programs/ubuntuone-android-music
<dobey> xnox: software-center pkg import has been broken for quite some time.
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 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 -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<fdfdfd> HI ALL
<fdfdfd> anyone here
<sarnold> fdfdfd: 300+ .. though who is awake and around may vary.
<fdfdfd> sarno;d may i quayr you please it a lot earier for me
<sarnold> fdfdfd: it'd be best to ask questions in the channel, that way other people can learn, or correct me if I'm wrong :)
<fdfdfd> i got a quick question sence i reinstall windows xp on to my computer will and from linux be on my computer now
<fdfdfd> STILL
<fdfdfd> opps caps on still LOL
<fdfdfd> sorry
<straemer>  fdfdfd: I think you want the #ubuntu channel
<fdfdfd> ths is unbuntu channle
<straemer> no, this is #ubuntu-devel
<fdfdfd> you cant get help from here
<straemer> well the ubuntu channel is dedicated to support, so you'd have better luck there
<fdfdfd> in this room youall just caht about bull s ****
<fdfdfd> and talk about what ever
<fdfdfd> ok thank you streamer
<pitti> Good morning
<mlankhorst> gday!
<dholbach> good morning
<caribou> slangasek: infinity: thanks for expediting the rsyslog regression fix
<jdoles> How can I backport a package?
<maxb> jdoles: Need more context - to build locally, to build in a PPA, or the process for getting something into raring-backports etc.
<jdoles> maxb: locally
<Versable> Hey, vala troubles
<Versable>  Package `webkitgtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories
<Versable> I know to cp webkit-1.0.vapi to webkitgtk-3.0.vapi  and  webkit-1.0.deps to webkitgtk-3.0.deps
<Versable> But I am trying to package, what's the workaround
<jdoles> maxb: I installed backportpackage, but that doesn't do anything useful when used in the obvious way.
<maxb> jdoles: Well, that's a very very broad question. It's easy to answer "modify the package source appropriately and build it", but that's not very helpful to you
<maxb> Ah, you mean in reference to a specific helper scirpt
<jdoles> maxb: https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport
<jdoles> maxb: I am just following instructions.
<jdoles> maxb: and they don't work.
<maxb> I think they work, they just aren't as detailed as you'd like
<jdoles> maxb: I don't see why I can't just run a tool which downloads the right source package, drops me in a directory where I can run make buildpackage and then get a deb out.
<jdoles> maxb: as detailed? The program tells me that I need to specify an upload target or something else.
<jdoles> maxb: both options are not applicable.
<jdoles> maxb: hence, the program has a bug.
<jdoles> maxb: since the wiki is wrong, I ask here.
<maxb> I get that you're frustrated, but it doesn't help to claim the instructions are wrong when they're not
<maxb> They identify a specific helper script, with the expectation that users will refer to its help and/or manpage
<jdoles> Usage: backportpackage [options] <source package name or .dsc URL/file>
<jdoles> Source package name: I choose bc.
<jdoles> backportpackage bc
<jdoles> backportpackage: error: Please specify either a working dir or an upload target!
<jdoles> Documentation is simply wrong.
<jdoles> maxb: why do you make up excuses?
<maxb> So now you actually go read the help message and specify one of those things (-w or -u options)
<jdoles> maxb: it's -U
<maxb> No it isn't
<jdoles> maxb: and the USAGE doesn't say I need to specify it.
<jdoles> maxb: ok, so indeed it's -u, but still irrelevant.
<jdoles> maxb: so, whoever wrote USAGE was plain unambiguously WRONG.
<jdoles> maxb: you should talk to whoever wrote that script, because it wastes the time of people.
<jdoles> maxb: you should *not* point at me saying that I did something wrong.
<maxb> You say "wrong" I say "omitted a small detail which you easily discover via a reasonably helpful error message on first use"
<jdoles> I frankly don't get why you even endorse such broken programs.
<jdoles> But then again, you also developed Unity.
<maxb> I frankly don't get why you seem to think it's worth typing this diatribe.
<jdoles> maxb: the error message is *not* helpful.
 * maxb stops feeding the troll
<jdoles> maxb: I have no idea what to do, because I matched the required inputs.
<jdoles> maxb: I read USAGE, gave valid values and the program returns an error.
<jdoles> That means that the problem is on the side of the author of said program.
<Versable> Ouch
<jdoles> I am now doing it via a different method, a less high-level approach such that I don't need to work with this broken sh*t.
 * maxb wonders if ubuntu-dev-tools really needs to recommend debian-keyring (what with it being a 42MB .deb)
<jdoles> I managed to get the broken program to sort of work, but I don't want to upload anything.
<jdoles> maxb: yes, it does.
<maxb> Hmm, Move debian-keyring from Suggests to Recommends (LP: #717245)
<ubottu> Launchpad bug 717245 in ubuntu-dev-tools (Ubuntu) "[pull-debian-source] Please recommend debian-keyrings" [Wishlist,Fix released] https://launchpad.net/bugs/717245
<pitti> yolanda: FYI, the squid3 autopkgtest keeps timing out; it's accessing some network sites, which mostly doesn't work from the DC
<pitti> yolanda: would be better to rewrite it using a local apache/ftp server or something like that
<yolanda> hi pitti
<yolanda> ok, i'll take a look
<pitti> yolanda: accessing www.ubuntu.com is probably okay (jibel?), but not the more elaborate stuff
<yolanda> pitti, i just took the code from QA there, is ok if i modify that only in the package then?
<pitti> yolanda: sure
<pitti> yolanda: I guess it's still worth keeping the current tests somewhere, though
<pitti> they can run on a local box without a restrictive firewall/proxy in front of it
<pitti> and with that it's more useful for actually testing security updates and the like
<jibel> yolanda, *.ubuntu.com,  *.canonical.com, *.launchpad.net and few others are ok
<yolanda> great
<pitti> jibel: but only http, right?
<pitti> the test also uses ftp and perhaps other
<pitti> s
<jibel> pitti, right http and https. I used ftp and smb servers  inside the lab for JDK testing, we could setup one for autopkgtest
<yolanda> jibel, pitti, so it's better to enable ftp and leave the tests like that?
<yolanda> the other tests under http or https are just under ubuntu.com
<pitti> yolanda: the ftp or some other test makes the whole test hang forever, and adt kills it
<pitti> I can't say for sure as I don't get logs from these
<yolanda> mm, how can we confirm it?
<pitti> yolanda: I'll try running it in the DC, to see what's hanging
<yolanda> ok
<pitti> yolanda: oh, I get http://paste.ubuntu.com/5738082/
<pitti> yolanda: I'm not sure why the test is hanging forever, that seems to be a bug in our adt scripts
<yolanda> pitti, and you also get this error locally?
<pitti> yes, I do
<pitti> and the hang, too
<pitti> run-adt-test -s squid3
<pitti> /etc/init.d/squid3 â this doesn't exist
<pitti> yolanda: ah, it was converted to an upstart script, so the tests need to be adjusted to use "start squid3" and the like
<pitti> yolanda: I'll check why run-adt-test hangs forever in the meantime, ok?
<yolanda> mm, i tested that locally before pushing anything and that worked, is that a recent change?
<yolanda> ok
<pitti> I was fairly sure I tested it as well (always do when sponsoring)
<pitti> I don't see it as a recent change
<yolanda> i'll test it again
<sil2100> jamesh: ping
<jamesh> sil2100: pong
<ogra> hmm, is /etc/fstab.d supposed to work ?
 * ogra sees it in saucy, but files i put there done seem to be respected at all
<ogra> oh, upstream removed it from mount .... how helpful
<pitti> removed? perhaps it's in a less ancient util-linux?
<ogra> sadly it has no reference to the discussion http://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fstab-d
<ogra> the answer is from 2012 ... i dont really want to roll back that far :)
<ogra> (on the phone where we ship fstab snippets it would be extremely helpful to have it working)
<xnox> dobey: lp:ubuntu/software-center is now up to date.
<apw> pitti, yo ... we have a boot speed regression and we think udevd is to blame
<apw> pitti, (the systemd version) ... having poked it a bit the initrd seems to have bloated by likr 14Mb
<pitti> apw: oh? it's actually supposed to be faster now, as it drops all those external programs
<apw> pitti, 16104k freed -> 30508k freed
<apw> pitti, yeah i don't doubt it is quicker in the real world but the initrd has become massive and loading and unpacking it is eating a lot more time
<apw> pitti, i am assuming it is not meant to be 14M of new code
<pitti> apw: certainly not
<pitti> sounds like a new dependency crept in or so
<apw> in better news, QAs boot charts found it, in not so better news we only noticed the regression by luck
<pitti> I'm still fighting with vala, will look after that
<apw> pitti, oh and i think it may have gotten a bit better a couple of days ago
<apw> pitti, will confirm for you
<xnox> apw: where are the bootcharts?
<apw> xnox, reports.qa.ubuntu.com, and hit the Bootspeed tab
<apw> pitti, ok confirmed, two days back it dropped back from 30m to 23m which has recovered about 1/2 the regression
<pitti> hm, 202-0ubuntu10 was the last thing to really change the initramfs, but that was from May 29 already
<pitti> apw: anyway, I'll dissect the initramfses and compare
<apw> pitti, i have both here, so while you are looking at vala, i'll see what i can see
<pitti> apw: indeed, my initrd.img-3.9.0-2-generic is 31 MB, initrd.img-3.9.0-3-generic is 23
<pitti> initrd.img-3.9.0-2-generic is from May 28, thus before udev 202-0ubuntu10
<apw> pitti, that was the shrink which gives us back half of it
<pitti> apw: 14 MB was from raring?
<apw> pitti, hmm that is hard to tell with qa's stuff
<xnox> apw: so in my -2, there is icu added, which was an unwanted temporary dependancy of harfbuzz & pango. But that was fixed. (harfbuzz build without icu)
<pitti> apw: filed bug 1188108 to track, FYI
<ubottu> bug 1188108 in systemd (Ubuntu) "saucy initramfs ballooned, causing bootspeed regression" [Undecided,New] https://launchpad.net/bugs/1188108
<apw> pitti, thanks
<xnox> apw: the regression was noted by d-i team, since sudently icu-udebs were required.
<apw> xnox, yeah ... good
<xnox> 1/2 the regression is revert of extra icu baggage.
<xnox> (recovery)?!
<xnox> cause icudata is ~19MB unpacked.
<apw> pitti, oh yeah so locally my 16M ones are raring yes, so that is likely true for QA
<apw> pitti, so ... we have an initial delta 16->30 from raring->saucy, and 30->23 from fixing icu
<apw> ugg
<pitti> $ diff -Nur <(zcat initrd.img-3.9.0-2-generic | cpio -t | sort -u | sed 's/3.9.0-2/3.9.0-3/') <(zcat initrd.img-3.9.0-3-generic | cpio -t | sort -u)
<pitti> indeed, that's the removal of icu and libstdc++.so.6
<pitti> but it added +usr/lib/x86_64-linux-gnu/libgraphite2.so.3
<apw> pitti, by the looks of it we have a heap more kernel modules in the new ones, like possibly all of them
<pitti> apw: I think libgraphite2-3 is a dep of libharfbuzz0a is a dep of libpangoft2-1.0-0 is a dep of plymouth
<apw> pitti, i think we have a modules issue primarily
<pitti> so at least there isn't anything udev-ish between -2 and -3
<pitti> apw: yeah
<apw> 5.2MAc/lib/modules
<apw> 31MBc/lib/modules
<apw> pitti, not good
<apw> pitti, so not all of them, but a heck of a lot more of them
<pitti> apw: so is that due to udev somehow?
<apw> pitti, seems unlikely to me
<apw> pitti, you were fingered cause the one which was small was udev, and the one which was big was systemd-udev, but actually that might be raring -> saucy cut over ..
<apw> pitti, let me poke it for a bit, and update the bug while you vala yourself to death
<pitti> heh; effing buildds..
<apw> what did the eff ever do to you :)
<pitti> not reproduce in sbuild or debuild
<pitti> so I keep banging new versions onto the buildds until they submit
<apw> pitti, so if i rebuild an old kernel it expands, kmod, initramfs-tools and the kernel (in that case) are all identicle ... this is going to be 'fun'
<apw> pitti, ok my 16M ones are actuall made with MODULES=dep in /etc/initramfs-tools/initramfs.conf
<apw> pitti, can you confirm whether you have like /etc/initramfs-tools/initramfs.conf.dpkg-old on the machine you checked
<apw> pitti, as my other raring machine they are all 31M
<apw> pitti, did your machine by any chance have the kmod stuff installed on it, the early kmod testing we did
<apw> pitti, and the problem with that is i cannot account for how the initrd on a virgin install would be 16M on raring
<apw> (in the QA scenario
<pitti> apw: re
<pitti> so with "if i rebuild an old kernel it expands,.." you mean that if you build raring's kernel in current saucy you get a big (23 MB) or small (16 MB) initrd?
<apw> pitti, i get a 23 M one now indeed
<pitti> apw: ok, so it's not the new kernel then
<apw> pitti, and that is because i got a new initramfs-tools, which switched my conf from =dep to =most
<apw> pitti, now that was cause i had a test kmod one on, on this other machine i have it was =most all the time, and is 30M for raring as well
<pitti> /usr/sbin/mkinitramfs:# MODULES=most is default
<pitti> /usr/sbin/mkinitramfs:echo "W: mkinitramfs: Falling back to MODULES=most."
<apw> pitti, so the confusing thing is how this test box was _ever_ 16M
<apw> pitti, right ... i know, and that worries me about the machine which did the testing
<apw> pitti, in reality i think we have had 31M initrd's for raring, and your recent fix for ics has made it 23, win
<apw> and there is no regression, but i am going to chat to QA to confirm the older results
<apw> pitti, but you have a 16M one as well and want to confirm you got that with =dep somehow
<pitti> on that note, what happened to the really useful automatic creation of initramfs .bak files by update-initramfs ?
<apw> that your machine is a poor example as mine is
<pitti> apw: 9554231 Jun  6 12:23 initrd.img-3.9.0-3-generic
<apw> pitti, i don't recall ever seeing those, though it does sound useful
<pitti> that's with "dep" in /etc/initramfs-tools/initramfs.conf
<pitti> but I just changed that
<apw> yep so nice and small
<pitti> apw: I didn't have a 16 MB one on my machine; it's all saucy
<pitti> apw: I was just quoting your number
<apw> ok, so 16M in the bug, was my number, ok, so that is a false number, just happening to match nearly exactly QAs
<apw> but i am now suspicious of
<pitti> apw: so either /etc/initramfs-tools/initramfs.conf really had "dep" at some point, or someone poked that into the QA machine?
<apw> their number ... right ... so ... off to qa to ask
<pitti> apw: you had manually configured that as well?
<apw> pitti, yeah seemingly when i was doing the kmod testing
<apw> i probabally change it to confirm i had done the right thing in the merge i did for initramfs tools for that
<apw> (one we didn't use in the end) and tested both modes, and left it in the wrong one, sigh
<pitti> well, "dep" doesn't seem exactly "wrong", but it might indeed not be enough if you use root on a network fs
<pitti> (but yuck)
<pitti> having all those HID and network drivers in initramfs seems like a waste
<pitti> at least if update-initramfs sees that the root fs is on a local disk
<apw> pitti, is is so concidentally similar (the size in the testing) and the size my machine has for =dep that i am deeply suspicious of the results on this machine
<apw> pitti, yeah this is the disk portability problem, i have long argued (and probabally should implement) that we should build two, one thin (=dep) and one fat (=most) and use the thin for 'normal' boots and 'fat' for recovery
<apw> so you can recover in a disk moved to different h/w scenario
<pitti> apw: I was just speaking about the network drivers, but indeed we could downsize the block drivers, too
<apw> pitti, ahh i see what you mean, make the decision that the disk is only portable as a disk
<apw> which makes a lot more sense
<pitti> apw: I was thinking to not include any network stuff if your root dev is on any /dev/
<pitti> as opposed to some nfs device or so
<apw> pitti, yeah i think that makes sense, and doesn't break the main point, unscrew disk move to new machine screw in disk
<pitti> (I have no idea how that would look like; the whole idea of having your system partition on a network device seems crazy and utterly slow to me)
<pitti> apw: yes, I fully support having at least the most common disk drivers in the initramfs
<pitti> lib/firmware/matrox/g200_warp.fw
<pitti> lib/firmware/r128/r128_cce.bin
<pitti> lib/firmware/radeon/PITCAIRN_mc.bin
<pitti> wow, we have a lot of stuff in our initramfs
<pitti> (for KMS, I guess)
<pitti> apw: so we ship 9.9 MB of network drivers
<pitti> that's a third of the size of drivers/net
<hrw> does someone here use saucy? pulseaudio (in pauvcontrol) lists no sound cards
<xnox> does for me on saucy/amd64
<hrw> xnox: saucy/amd64 here as well but no cards ;(
<hrw> xnox: heh.. I am not in audio group
<ogra> hrw, the audio group shouldnt be used unless you dont use a DM
<ogra> i assume there is a bug in systemd-logind
<ogra> (or in pluse talking to it)
<hrw> ogra: DM?
<zul> cjwatson:  ping is it possible for you to de-binary new python3-mimeparse please?
<ogra> displa/login manager
<hrw> ah
<hrw> ogra: kdm is broken, lightdm+kde-greeter not yet work for me - working on it now
<cjwatson> zul: done
<zul> cjwatson:  thanks
<ogra> so i have this  upstart job http://paste.ubuntu.com/5738554/
<alexbligh1> If a package I am installing requires the en_GB locale to be installed (always), then should it Depend: on language-pack-en or language-pack-en-base?
<ogra> it doesnt start on boot at all, even though syslog shows
<ogra> Jun  6 12:00:11 ubuntu-phablet upstart-file-bridge[460]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofon
<ogra> does anyone have an idea why ?
<ogra> the file is there (and the syslog entry actually reacts to it)
<ogra> running "start ofono" manually works fine too
<ogra> i have the feeling that "on started dbus" doesnt do what it should
<xnox> ogra: can you increase debugging, to get the full log of all events? that way it should be easier to see why it's not starting.
<ogra> hmm
<xnox> add "--debug" to kernel command-line
<ogra> that needs cmdline changes
<ogra> thats fiddly
<xnox> or add a very early job to "exec initctl log-priority debug"
<ogra> ah, it seems the file i wait for is created twice in a row
<ogra> (which is weird
<ogra> )
<xnox> start on (starting file-bridege and starting dbus) or something like that.
<ogra> additionally to file FILE= ?
<xnox> upstart-file-bridge emits event if the file added event, and then again if it's changed/added/removed.
<xnox> ogra: no, that was start on condition for a job that does "initctl log-priority" tweak.
<ogra> oh, i could look for the added event
<xnox> ogra: yeah, so there is FILE= which is path to file and EVENT= which is create|modify|delete
<ogra> right ...
<ogra> i'm not 100% that i dont have a dangling file there before it gets newly created
<ogra> so lets see if that helps
<ogra> sigh ...
<ogra> if rebooting would only work reliably
<xnox> ogra: does /dev/socket exist when file-bridge starts? see limitations on recursive inotify watches in upstart-file-bridge manpages....
<ogra> oh, it might not
<ogra> not sure when the file bridge starts, let me take a look
<ogra> ah. well, "emits file"
<ogra> so i should be starting before it
<ogra> *shouldnt
<ogra> sigh
<ogra> so now i see it starting and then stopping
<xnox> ogra: did "stopping dbus" kick in?!
<ogra> i dont see why it woould on boot
<ogra> i removed it
<ogra> heh, now it doesnt start at all
 * xnox is not sure why you have "stop on stopping dbus" there at all though.
<ogra> because ofonod needs dbus
<ogra> if thats gone we want to go away as well
<xnox> ogra: but when dbus comes back, ofono will not come back.
<ogra> thats true for the file too ... i added a stop sequence for it
<xnox> ogra: since a file event for the socket will not be emitted ever again.
<ogra> let me drop the on stop line
<ogra> hmm, nope
<ogra> doesnt start at all anymore
<ogra> even if it cant find dbus it should just respawn ... i dont see it doing that either
<ogra> all i get is
<ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/ofono
<ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/ofono
<ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono
<ogra> Jun  6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono
<ogra> why does it have that "_2fdata_2fubuntu/ofono"! thing there ?
<xnox> ogra: i really want "--debug" output from upstart =) can you divert init -> init.real and make init a shell script "/sbin/init.real --debug" ?
<ogra> well, let me fiddle with the cmdline
<ogra> just takes a bit
<xnox> ogra: above are just funny upstart-file-bridge logs which are "things that file-bridge is tracking / watching / emited / finished dealing with"
<ogra> well, i dont get why there seems to be a proper "ofono" job but also the two others
 * ogra wonders why pastebinit hangs
<ogra> ah, well, 200000 lines was probably a bit much
<ogra> http://paste.ubuntu.com/5738646/
<xnox> ogra: i see dbus running, yet no starting nor started dbus events?!
<ogra> weird
<xnox> init: Error while reading from descriptor: Bad file descriptor
<xnox> looks scary.
 * ogra wonders where that might come from
<xnox> ogra: can I see output of `dmesg` ?
<ogra> hmm, thats filled with trash already ... i can get you /var/log/dmesg
<xnox> ogra: | grep init
<ogra> http://paste.ubuntu.com/5738654/
<ogra> there is no init: in it anymore ...
<ogra> if the ringbuffer is full dmesg deletes
<xnox> ogra: create a "custom logger" =))) http://paste.ubuntu.com/5738665/
<xnox> ogra: and then /var/log/upstart/customlog.log will have just the events we are interested in, and we will notice if ofono started or not.
<xnox> ogra: also add "or started/starting/stopped/stopping ofono" if you want to notice those as well.
<xnox> ditto dbus.
<ogra> ugh
<ogra> /bin/sh: 0: Can't open /proc/self/fd/9
<ogra> all over the place
<ogra> http://paste.ubuntu.com/5738679/
<jbicha> should packagekit-qt be removed also? (it unfortunately migrated out of -proposed)
<ogra> i see 4 create events for the file
<xnox> ogra: weird, but the ofono job should be running then. Was that booted two times? as dbus/file-bridge are started twice.
<ogra> yeah
 * ogra tries something els 
<ogra> e
<tedg> mardy, Hey, is there a way to turn off UOA in Evolution?
<mardy> tedg: open the account in the System Settings, there should be switches next to the various services
<tedg> mardy, With Google I have photo search, shotwell, empathy and Google Drive plugin.  But no Evolution.
<seb128_> tedg, mardy: not sure if you got that before
<seb128_> mardy, that's not listed evolution, Laney mentioned that there was an error about no matching .desktop yesterday iirc
<Laney> eds should supply a .desktop file for it
<tedg> Yeah, I also just did a dist-upgrade and I'm getting an account-plugin-google.
<tedg> Curious if part of my problems were that I didn't have the right provider.
<Laney> it's basically broken with accounts that require 2fa
<Laney> https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1187699
<ubottu> Launchpad bug 1187699 in evolution-data-server (Ubuntu) "Timeout retreiving Google calendar" [Undecided,New]
<ogra> xnox, so dropping the file stuff and instead depending on the job that creates the file makes it work reliable
<ogra> the file is a symlink to a socket which originally lives in /proc ... i guess the file bridge doesnt really get along with that
<xnox> ogra: ah. there is a socket bridge as well, but it's reverse, to start a job when something starts talking to the socket.
<ogra> xnox, yeah, that wont help, the thing talking to the socket is the thing i'm starting :)
<xnox> ogra: to be honest i'd only use file-bridge to track _regular_ files on _normal_ filesystems, and not things in /dev, /proc and etc. But I guess that's not everyone's prerogative.
<ogra> well, ofono needs the link to be there to start properly
<ogra> else it cant talk to the daemon inside the container
<xnox> i see.
<zul> how long does it take to get somehting out of -proposed?
<tumblewed> it needs to be installable
<jdoles> Does anyone know how the cc_version is determined in this string (avahi output for distcc)? txt = ["cc_machine=x86_64-linux-gnu" "cc_version=4.7" "gnuhost=x86_64-pc-linux-gnu" "distcc=3.1" "cpus=2" "txtvers=1"]
<xnox> zul: fully build on all arches, it previously managed to build on. + does not cause more packages to be uninstallable. See http://people.canonical.com/~ubuntu-archive/proposed-migration/
<jdoles> In particular why does it select just one number when multiple compilers are installed on the system?
<xnox> jdoles: my guess it comes from the compiler it self. and whichever one is the "cc" or "gcc" compiler?!
<jdoles> xnox: the compiler being?
<jdoles> xnox: (there is no 'the')
<xnox> jdoles: type $ cc --version
<jdoles> xnox: unless you mean that it has been hardcoded to use cc.
<xnox> jdoles: that's the default c-compiler on any system (hence "cc") you can update that symlink if you wich.
<xnox> wish.
<xnox> and I'm sure distcc can be configured to use alternative compilers.
<jdoles> xnox: after apt-get install gcc-4.7, I don't have a gcc-4.7 on my path. Why not?
<xnox> jdoles: i do. what's your path?! =)
<xnox> zul: unless you are talking about SRUs verification from $stable-proposed -> $stable-updates ?!
<zul> xnox:  nah im good thanks
<jdoles> xnox: the default PATH + some site specific ones.
<jdoles> xnox: actually I only have gcc-4.7-base.
<jdoles> xnox: and that is a very small package which doesn't seem include an actual compiler.
<ev> pitti: is there a historical reason why we don't include a timestamp in the apport report path? Otherwise we're replacing whatever crash already existed every time, even if they're crashes in different places.
<ev> tedg is running into this right now with recoverable problems
<ev> why this didn't occur to me sooner, I have no idea
<ev> I noticed that bzr does the right thing here for its crashes
<xnox> jdoles: dlocate /usr/bin/gcc-4.7 tells me you want: gcc-4.7: /usr/bin/gcc-4.7
<xnox> jdoles: as in $ apt-get install gcc-4.7
<jdoles> xnox: I did that.
<jdoles> xnox: Note, selecting 'gcc-4.7-base' for regex 'gcc-4.7'
<jdoles> xnox: alternatively, how can I make distcc use an older compiler?
<dobey> xnox: thanks for fixing the software-center package branches!
<jdoles> xnox: is your other nickname nox?
<xnox> jdoles: no.
<xnox> (not for more than 12 years now anyway)
<apw> pitti, ok after much poking, we seem to have gotten the right initrds off the machine.  the 16m size is right becuase that machine has no plymouth, and indeed when it jumps to 23 it is plymouth appearing in there that did it
<pitti> aah
<pitti> apw: so cryptsetup and the like
<pitti> that would drop a lot indeed
<apw> pitti, there is also some cryptsetup in there, so it seems that something in the recent image is pulling that in
<apw>                                                               > lib/libcryptsetup.so.4
<apw> is added in the later image
<apw> (in its initrd)
<xnox> jdoles: install whichever compiler you want, and adjust your path appropriatly for it to be called as "cc" and distcc will use that. if there are problems, try googling. I don't use distcc at all myself.
<apw> pitti, how the heck would one figure that out
<xnox> pitti: apw: whilst images have cryptsetup, the default unencrypted/lvm-less desktop shouldn't have cryptsetup in the initramfs.
<dobey> does distcc not support doing "CC=/usr/bin/foo-cc distcc" or something?
<apw> xnox, as soon as cryptsetup is installed we will add plymouth and junk into the initramfs
<xnox> dobey: i mostly saw it use wrappers & diverts everytime I had to use distcc.
<apw> xnox, regardless of whether it is used for root or not
<xnox> apw: sure. which I was meant to fix, and only add it if "/" and/or "/usr" is encrypted.
<apw> xnox, ok but as things are has cryptsetup been added to the default images
<apw> as in the last two weeks the sizes of the initrd's have jumped
<xnox> apw: in quantal we added full-disk encryption to the desktop image, but it should be removed from the installed system at the end of installation if one chose defaults and is not using encrypted rootfs.
<apw> xnox, ahhh, so this could be a bug in the bit which removes it then
<xnox> apw: .... if for example initramfs is last regenerated before and not after removing packages.
 * apw goes find something to scratch install
<cjwatson> jdoles: If apt falls back to regex search, it must be because gcc-4.7 isn't available.  'apt-cache policy gcc-4.7' does a lower-level check
<xnox> apw: but i don't think we touched that code since.... quantal. So it doesn't explain regression from a few weeks ago.
 * xnox is checking daily saucy.
<apw> xnox, nope, but i should scratch this test box and see if it stays on, and eliminate it
<jdoles> cjwatson: that only shows the base (this is precise-updates)
<apw> and if it is there find out what is holding it on
<jdoles> cjwatson: I think it's simply not in precise.
<xnox> jdoles: yeah, quantal and up.
<cjwatson> Indeed.  GCC 4.7.0 was released in March 2012, only barely before precise released.
<cjwatson> gcc-4.7-base is there because there was a gccgo-4.7 source package in precise that built it, because people wanted to experiment with the Go compiler early.
<pitti> rbasak: ugh, that became a loong reply :)
<ev> tedg: give this a bash: http://paste.ubuntu.com/5738948/
<tedg> ev, Sorry, catching up.  I figured that that's what the "1000" was for.
<ev> that's the uid
<tedg> Ah, I thought it was a counter :-)
<ev> I *think* the intent was to keep the reports to a minimum, back in the day
<ev> but with errors.ubuntu.com, it seems like we're just potentially overwriting some problems (assuming an application can crash twice before the first report is processed)
<ev> which would be fairly easy with recoverable_problem. Harder with Crash ProblemTypes
<tedg> ev, Can you just send me the whole file?  I've hacked it too much for debugging... diffs won't apply :-)
<ev> tedg: sure
<ev> http://paste.ubuntu.com/5738958/
<tedg> ev, Hah, was trying to figure out what happened.  It wrote multiple files, but in my home directory :-)
<ev> :)
<ev> any idea why?
<tedg> ev, I'm guessing reportfile there needs an "/var/crash" in front of it.
<ev> hmm, so it does :)
<ev> os.path.join(report_dir, reportfile)
<tedg> ev, Woot! I can make lots of crash files ;-)  http://paste.ubuntu.com/5738984/
<ev> heh, I'm working on a variant that uses a short hash of the crash/duplicate signature
<ev> which would at least not break "ignore future problems of this type" box
<tedg> That makes more sense.  Each type once.
<ev> yeah
<barry> bdmurray: ping
<bdmurray> barry: hey
<didrocks> barry: hey, do you know why python-support is in universe?
<barry> didrocks: it's deprecated in debian.  ubuntu is a little farther ahead in switching to dh_python2, but we really don't want anyone using py-support or (even worse) py-central any more
<barry> didrocks: it's usually pretty easy to switch to dh_py2
<barry> didrocks: http://wiki.debian.org/Python/TransitionToDHPython2
<cjwatson> die die die python-support
<didrocks> barry: ok, I need gtester2xunit in main
<didrocks> barry: which build-dep on python-pyruntest
<cjwatson> didrocks: somebody needs to convert it then
<didrocks> which build-dep on subunit
<didrocks> cjwatson: yeah, but for sure, everything is melt down and it seems people don't care about that to have touch and unity 7 in distro
<cjwatson> we very carefully went to the effort of converting everything in main that used python-central or python-support to dh_python2
 * didrocks *sigh*
<cjwatson> they have to care, python-support is not going back into main :)
<didrocks> I know, why I'm asked
<didrocks> asking*
<cjwatson> python-pyruntest doesn't build-dep on subunit here though
<didrocks> cjwatson: wrong line copied: python-junitxml,
<cjwatson> Nor does subunit use python-support
<cjwatson> Right, python-junitxml needs to be converted
<didrocks> cjwatson: yeah, I copied the wrong line when pasting here :)
<cjwatson> It's usually about a 15-minute job.  Want me to have a look then?
<Laney> I heard the maintainer's a nice guy
<cjwatson> He is, but he might also like to take patches rather than doing it himself :)
<didrocks> cjwatson: seeing the christmas period that is my IRC right now, I'll greatly appreciate :)
<didrocks> (thanks for the offer)
<Laney> was suggesting that he'd probably be quite willing to take them :P
<apw> xnox, ok a clean install with todays saucy iso, selecting a normal install, leave cryptsetup installed
<apw> xnox, whats the best way to find out why it is still on
<dobey> anyone have any idea why the branch import of a package would have succeeded for saucy-proposed, but doesn't seem to have gotten copied to saucy, even though the package has already been copied over, and there's nothing on the branch imports status page for it?
<xnox> apw: it's installed because it gets copied across like everything else. It is left on the install either because it's in whitelist, dependancy of something in whitelist, explicetly "marked" to be install with apt-install.
<apw> xnox, ok so this was a default install all options defaulted, and its still on there, so is the information on why still on the system so i can find out
<xnox> apw: I can take from here, and hunt it down. Also it's a good excuse to simply implement "do not pull cryptsetup+plymouth+friends into initramfs, unless root partition is encrypted".
<apw> xnox, i would love to see that for my purposes as i use cryptsetup in that mode, not for /
<apw> xnox, ok thanks, there is a bug out there, which is currently against, systemd
<apw> xnox, LP#1188108
<apw> bug #1188108
<ubottu> bug 1188108 in Ubuntu "saucy initramfs ballooned, causing bootspeed regression" [Medium,Incomplete] https://launchpad.net/bugs/1188108
<slangasek> caribou: just doing our duty ;)
<jdoles> Are you also switching to systemd now?
<jdoles> Switching initialization system every release seems like not so fruitful idea.
<jdoles> +a
<seb128> jdoles, we don't plan to use systemd init no
<cjwatson> The mention of systemd above is because we're using some pieces of systemd (e.g. udev is built out of that tree now), but not the actual init daemon
<barry> bdmurray: actually, let me ask cjwatson and/or slangasek if they know whether update-motd scripts can generally write to stderr.  the manpage is a bit silent on that although it does say: "MOTD fragments must be scripts in  /etc/update-motd.d,  must  be  executable, and must emit information on standard out."
<cjwatson> I think that would be up to pam_motd
 * cjwatson punts to slangasek
<barry> slangasek: context is bug #982082
<ubottu> bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged] https://launchpad.net/bugs/982082
<Laney> h
<barry> what we think is happening is that something mysterious is breaking lsb_release causing it to exit non-zero.  not sure what that is, but if that *does* happen, then check-new-release will write an error message to stderr, but stderr doesn't exist and we get the IOError.  that gets run under an update-motd.d script so the guess is that stderr isn't available to those scripts
<slangasek> barry: the pam_motd integration doesn't capture stderr to the motd (which it shouldn't); it also doesn't redirect it anywhere, which may be a bug since it means the scripts can pollute the stderr of the invoking service
<slangasek> barry: so arguably, pam_motd should redirect stderr to /dev/null unconditionally, but I'm not sure if that helps you
<cjwatson> didrocks: pyjunitxml done
<barry> slangasek: it does somewhat.  the question is whether to fix this bug we should really install a more general fix to pam_motd.  the other options are narrower, e.g. either redirect stderr to stdout in this specific motd.d script, or fake stderr in the python bits that get invoked
<jdoles> I managed to get distcc --show-hosts to show proper output, but when I run a compilation it doesn't actually use multiple hosts :/
<jdoles> Anyone with an idea what can still be wrong?
<didrocks> cjwatson: thanks a lot! we're doing sphinx on the same base right now :)
<barry> slangasek: the narrower fixes are safer for an sru, and also probably easier to test and complete ;)
<bdmurray> barry: I'd imagine saucy is still affected though
<barry> bdmurray: could be, yes.  probably the easiest/quickest fix is to redirect stderr in the motd script
<slangasek> barry: wasn't there some suggestion in the other master lsb_release bug that invoking lsb_release itself with stderr closed was causing failures?  Maybe fixing lsb_release to handle that case kills two birds with one stone?
<barry> slangasek: i don't think this is directly related to lsb_release writing to stderr.  the problem happens because lsb_release exits non-zero and it's the do-release-upgrader code that then tries to write a message to stderr in that case.
<barry> slangasek: we have seen cases where lsb_release can exit non-zero, which is why we sru'd the -Es shebang line fix.  i am requesting more information in the bug about that, which would be the root cause (and about the only reason why lsb_release would exit non-zero)
<slangasek> ok
<slangasek> well, except if lsb_release is raising an unhandled exception because stderr is closed (which is the reported symptom in that bug), wouldn't that also translate to exiting non-zero?
<slangasek> and if do-release-upgrader's stderr is closed, that obviously triggers this path
<barry> slangasek: for precise, lsb_release will only write to stderr if it crashes or gets bogus command line options.  in the context of the tracebacks i've seen, the latter isn't happening, so it has to be the former, which leads to the guess that they don't have the -Es fix.
<barry> lsb_release will obviously write to stdout in normal usage, but that's okay
<caribou> slangasek: I was a bit annoyed to let that regression in; never saw any issue with my own tests
<pitti> apw: so should we move #1188108 to ubiquity/confirmed then?
<slangasek> barry: are we talking about bug #1094218 here (or rather, https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Flsb_release%3AIOError%3A%3Cmodule%3E%3Amain%3Acheck_modules_installed%3Agetoutput%3Agetstatusoutput)?  that bucket clearly shows that lsb_release *does* have the -Es fix, and the invocation is a correct one; so this all adds up to "lsb_release crashes reliably when stderr is closed".  Have you tried to run lsb_release with stderr
<ubottu> bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [Medium,Confirmed] https://launchpad.net/bugs/1094218
<slangasek> ... see what happens?
<barry> slangasek: let's try it! :)
<barry> slangasek: okay, so yes, this will crash:
<barry> lsb_release -a exec 2>&-
<barry> slangasek: but here's the difference: in the context of the original bug, it's only running `lsb_release -c -s` which *doesn't* crash when stderr is closed
<barry> slangasek: so i'll claim this is two different bugs :)
<barry> hmm, actually, no i ran this in two different ways.  maybe it does crash
<barry> okay, so that explains the root cause
<apw> pitti, perhaps so for the moment, xnox is in the frame right now; it may move somewhere else when we figure out what it really is but yes i think so
<slangasek> barry: ok :)
<barry> slangasek: so, short of doing $something w/stderr in pam_motd, perhaps we should just redirect stderr to stdout in the update-mod.d script
<barry> slangasek: anyway, i'm going to get some lunch and ponder some more :)
<slangasek> barry: lsb_release needs to be fixed to not fail when stderr is closed, because that's a legitimate way to invoke it and the cause of our *top* crasher on errors
<slangasek> barry: if we fix lsb_release to not fail in this case, does that fix all the knock-on effects?
<barry> slangasek: it probably will, although there will still be a lurking bug here because if for some other reason lsb_release fails, check-new-release will still try to print to stderr under update-motd
<slangasek> right
<rbasak> pitti: np. Thanks :)
<slangasek> barry: so I think pam_motd redirecting 2>/dev/null, and fixing lsb_release, should cover us
<cjwatson> I'm not arguing against making lsb_release robust against this, but I don't think that "stderr closed" is a legitimate way to invoke any process, maybe with some special-purpose exceptions between cooperating processes
<cjwatson> (as opposed to "stderr redirected to /dev/null", of course)
<barry> cjwatson: you have a point, in that we can't expect to make every command robust against stderr being closed
<slangasek> cjwatson: well, ok.  In practice, this seems to be the environment teamviewer is giving us, leading to that top crash in question :P
<cjwatson> Is pam_motd actually closing stderr itself, or is that the fault of something further up the stack?
<cjwatson> teamviewer
<cjwatson> Christ
<stgraber> barry: wow, so you finally managed to track that bug down? that took a while ;)
<slangasek> cjwatson: pam_motd doesn't close stderr, but even if stderr *isn't* closed, I don't think we want these scripts' output leaking to the pam service's stderr
<cjwatson> slappity slap buggy proprietary software :-/
<cjwatson> We should let the teamviewer people know about this, since we have no way to fix it - I don't think we should omit that part since it might bite some other innocent process later
<slangasek> how do you mean, no way to fix it?
<cjwatson> no way to fix teamviewer
<slangasek> lsb_release can simply reopen stderr as /dev/null to work around
<slangasek> oh
<cjwatson> we can fix the collateral damage
<cjwatson> but this is definitely teamviewer doing an invalid thing
<slangasek> well, AFAIK lsb_release is the only tool it's invoking
<slangasek> ok
<barry> but wait.  teamviewer might be the culprit in bug #1094218 but i don't think it is in bug #982082
<ubottu> bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [Medium,Confirmed] https://launchpad.net/bugs/1094218
<ubottu> bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged] https://launchpad.net/bugs/982082
<slangasek> barry: correct
<slangasek> so I don't know how do-release-upgrade is being invoked there
<barry> slangasek: from update-motd
<slangasek> barry: there's no top-level tool called update-motd any more
<slangasek> the question is, who closed stderr :)
<barry> slangasek: on precise, what runs /etc/update-motd.d/* scripts?
<slangasek> barry: pam_motd
<slangasek> so some /service/ must invoke it
<slangasek> and the only obvious candidates are login and sshd
 * slangasek bounces the bug back to cjwatson ;)
<cjwatson> pam_open_session doesn't do any generalised fd fiddling?
<barry> slangasek: so i think i misunderstood your earlier comment about pam_motd and stderr.
<cjwatson> I'm reasonably sure that sshd never closes stderr - it would make its own debug output unusable which would be a pretty obvious thing
<cjwatson> and do_pam_session is post-auth, ruling out the really weird stuff that goes on with the pre-auth network monitor
<barry> i think this is happening at login not ssh
<barry> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/982082/comments/3
<ubottu> Launchpad bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged]
<cjwatson> login doesn't seem to close much of anything
<cjwatson> Shame we don't have a process tree here
<rbasak> Do we have any kind of policy of when we move a Debian package to upstart by adding an upstart job in our delta?
<rbasak> Whenever anyone's prepared to write one? Only when we have a reason and a delta anyway? Etc.
<cjwatson> Mostly when it's possible and somebody's prepared to write one
<cjwatson> But we should be forwarding all those deltas now :)
<rbasak> So we'd prefer to an upstart job for all daemons, even when we have to maintain deltas just for that?
<rbasak> (including universe?)
<cjwatson> I'm finding it really unlikely that 982082 is sshd, based on the bug description.  Are we sure there's no desktopy thing that would be using pam_motd there?
<cjwatson> Well, it's been a tradeoff of benefit vs. cost of maintaining the delta
<cjwatson> Now that we have a way to get such jobs into Debian, hopefully the tradeoff will tilt
<barry> cjwatson: i concur about sshd.  no clue about the desktop thing
<cjwatson> Or something that's running update-motd in some other way?  It used to be a bit more ad-hoc ...
<rbasak> I'm not sure I understand the benefit for random daemons in universe that don't need to interact with anything else for startup (ie. there's no other enumerated reason)
<cjwatson> Management (upstart will keep it running more reliably); consistency across the system
<rbasak> OK, thanks
<barry> slangasek, cjwatson well, wouldn't this pastebin be a stupidly horrible way to at least verify whether stderr-being-closed is the problem?  http://paste.ubuntu.com/5739278/  maybe that's even A Fix (if not a particularly good one)
<cjwatson> It would avoid that particular problem.  I think the only thing that qualifies as a true fix is not starting the process in that state, though :)
<cjwatson> (As I say, given that it's a top crasher, I don't object to workarounds)
<barry> cjwatson: agreed on both counts ;)
<slangasek> cjwatson: pam_open_session() definitely doesn't fiddle fds
 * cjwatson evilly wonders how much he could confuse everyone by writing something that launches processes with an envp pointing out of their mapped memory space
<slangasek> rbasak: why should you have to maintain a delta for an upstart job now?  These should all be upstreamable to Debian
<cjwatson> Or maybe just one of the pointers in argv
<yolanda> pitti: https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/squid3/fix-squid3-startstop/+merge/167804
<barry> cjwatson: that sunny disposition never fooled me.  i knew you had an evil streak. :)
<cjwatson> O:-)
<rbasak> slangasek: I was asking in response to review a debdiff to introduce an upstart job in our delta, to override an init.d from Debian. bug 1187742. mvo doesn't appear to be here right now.
<ubottu> bug 1187742 in freeradius (Ubuntu) "[patch] upstart job for freeradius" [Wishlist,Triaged] https://launchpad.net/bugs/1187742
<rbasak> slangasek: I can ask that he send this up to Debian, of course.
 * barry -> lunch
<slangasek> rbasak: right, it should definitely be sent there in parallel
<cjwatson> It's a pretty recent development that it's possible to upstream these; mvo may just not be aware of it
<cjwatson> (Well, possible sanely, as opposed to the crazy thing openssh used to do)
<rbasak> yolanda: ^^ led me to look at your dep8 test. Would it be an idea to package and include testlib.py somewhere, rather than include it in every test individually? Or are we intentionally duplicating the code here in every test for some reason?
<yolanda> rbasak, we were talking about that with jdstrand, we agreed that at the moment we will pack it in every file
<rbasak> yolanda: OK, fair enough. Good to know - thanks.
<yolanda> because testlib.py wasn't intented to be a production code
<yolanda> and to package it, more tests and verification is needed
<rbasak> slangasek, cjwatson: thanks. I'm much clearer on what do with upstart jobs now.
<cjwatson> Is there some kind of main promotion or something needed for http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html ?
<slangasek> cjwatson: hmm, the maas SRU seems to have been published before its dependencies
<slangasek> these were SRUs of new packages
<slangasek> so... let's see about getting celery published
<slangasek> cjwatson: ok, celery promoted to -updates; python-pyparsing and freeipmi-tools look like they need a copy to precise-updates & promotion to main?
<jcastro> slangasek: cjwatson: thanks for sorting this, maas has been a real pain point for users
<slangasek> roaksoax: can you please remind me what the expected outcome for the maas SRU was wrt python-pyparsing, python-txtftp, freeipmi-tools?  Did we have agreement to retroactively promote these to main for 12.04 and have them security supported?
<slangasek> these are each obviously in main in quantal and later, but I don't see that these were explicitly discussed as part of the maas SRU... I want to make sure the security team knows about this before I pull the trigger on promoting
<slangasek> mdeslaur: ^^
<mdeslaur> uh...what now? is there a bug# for that SRU?
<slangasek> mdeslaur: this is wrt bug #1109283
<ubottu> bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix released] https://launchpad.net/bugs/1109283
<roaksoax> slangasek: howdy! it was my understanding that these were discussed long ago and agreed upon
<roaksoax> mdeslaur: more specifically, bug #1020267
<ubottu> bug 1020267 in python-redis (Ubuntu Precise) "[MIR] celery, pyparsing, python-cl, python-gevent, python-mailer, python-pytyrant, python-redis" [Undecided,New] https://launchpad.net/bugs/1020267
<slangasek> roaksoax: it's possible that this was all discussed, I just want to make sure I know where since it's the security team picking up the tab here, not me ;)
<roaksoax> IIRC, we initially intended to do this for precise, but since we were not gonna be able to release maas as fast, we re-targetted to quantal
<mdeslaur> ok, since it gets rid of cobbler, I'm ok with those being promoted
<mdeslaur> I'll comment in #1020267
<roaksoax> mdeslaur: thanks! :)
<mdeslaur> slangasek, roaksoax: ok, commented in 1020267. I'm ok with promoting them since it gets rid of embedded cobbler code. Thanks for the ping.
<smb> infinity, <pester>Could you have a look (and sponsor) at chinstrap:~smb/4infinity for saucy</pester>
<infinity> smb: Maybe.  I'm trying to salvage some kernel PPA messes right now.
<smb> infinity, Ok, yeah. Just remembered that yesterday I forgot your/my daily pester-ilence
<smoser> xnox, ping
<smoser> bug 1124384
<ubottu> bug 1124384 in cloud-init (Ubuntu Saucy) "Configuration reload clears event that others jobs may be waiting on" [High,Confirmed] https://launchpad.net/bugs/1124384
<smoser> never mind
<shadows> How to fix a kernel panic when Bluetooth DUN disconnects?
<shadows> is there a procedure to bisect for Ubuntu...  what do I do
<infinity> shadows: -> #ubuntu-kernel
<infinity> jbicha: I take it you didn't test-build your gdm FTBFS fix? :P
<shadows> thanks infinity
<shadows> infinity: topic fail btw, http://bit.ly/lv8soi is 404
<dobey> wgrant: ping. are you around now? wondering if you could take a quick look at some udd branch import weirdness for me. thanks
<wgrant> dobey: What needs fixing?
<dobey> wgrant: lp:ubuntu/ubuntuone-control-panel doesn't seem to have been updated, though saucy-proposed branch was updated. and there is nothing on the import status page about it
<bdmurray> mpt: could you have a look at bug 1186376 again?
<ubottu> bug 1186376 in software-properties (Ubuntu) "should support setting of whether or not to include phased updates" [Medium,Triaged] https://launchpad.net/bugs/1186376
<wgrant> dobey: That's fixed.
<slangasek> cjwatson, infinity: so with this maas stuff, it seems that copying these packages from precise to precise-updates and change-override'ing them to main is insufficient.  I guess we need no-change SRUs?
<wgrant> slangasek: What's insufficient about it?
<infinity> slangasek: Hrm, what?
<infinity> slangasek: Did I miss something exploding?
<infinity> E: Package 'freeipmi-tools' has no installation candidate
<infinity> E: Package 'python-celery' has no installation candidate
<infinity> Oh, that. Fun.
<wgrant> Ah, promoting stuff post-release?
<wgrant> That usually works fine...
<infinity> Why wouldn't it work?
<wgrant> Exactly.
<infinity> slangasek: Where's the evidence that this doesn't work?
<wgrant> AFAIK it works.
<wgrant> Don't see why it wouldn't.
<infinity> slangasek: It just looks to me like none of it's been promoted, that's all.
<infinity> slangasek: I'd fix, but not if you've been mucking with overrides in the same publisher cycle.
<infinity> slangasek: Let me know if your finger's removed from the pie, and I'll fix it.
<straemer> anyone here have experience getting ubuntuone-android-music to build?
#ubuntu-devel 2013-06-07
<xnox> smoser: yes?!
<slangasek> infinity: it hasn't been in the same publisher cycle; if you want to smack it again with change-overrides, go ahead
<pitti> Good morning
<pitti> wgrant: hey William, how are you?
<pitti> wgrant: who should I ask to enable saucy translations in launchpad?
<wgrant> Hm, we didn't already do that?
<wgrant> Maybe we didn't.
<wgrant> Let's see if I can remember how.
 * infinity wonders why that doesn't happen as an artifact of opening a new series.
<wgrant> It's very early on NRCP
<pitti> wgrant: https://translations.launchpad.net/ubuntu/saucy/+language-packs is empty
<infinity> wgrant: Yeah, odd that we missed it.  But that's why checklists are worse than something just doing the right thing.
<pitti> wgrant: but I got a mail from some contributor who wants to start translating saucy in LP
<StevenK> We're not building langpacks, because that happens later, I think
<wgrant> pitti: It's not done, yeah
<wgrant> And we can't really test it beforehand like we normally do
<wgrant> So let's live dangerously :)
<pitti> well, with a rolling release thingy, as well as for people who start translating in LP it would actually be nice to have langpacks early as well, but opening saucy translations is indeed a bit more important
<wgrant> The plan was to have langpacks from the start, AIUI, but that didn't actually happen
<infinity> mlankhorst: So... Whoever NEWed all your lts-raring stack did so to universe, and thus you missed out on noticing that xorg-server-lts-raring has a build-dep on libaudit-dev that needs to be dropped (it's in universe in precise, and we're not likely to promote it, since the condition for promoting it in raring was a bunch of code cleanups)
<infinity> mlankhorst: I suspect they NEWed everything to universe, now I get to go hunt them down and clean up.  Unless you have a quick list of all the source packages involved, so I can mindlessly promote the lot? :P
<versable> Hey, a package won't build for me in lp. Package "webkitgtk-3.0 missing". libgtk-3-dev is in the build-depends though
<versable> log: https://launchpadlibrarian.net/141838690/buildlog_ubuntu-precise-i386.etube_0.2-0~2~precise1_FAILEDTOBUILD.txt.gz
<versable> bzr code: http://bazaar.launchpad.net/~versable/elementary-community/eTube/files
<versable> It builds fine lokally
<versable> local*
<infinity> versable: Missing build-dep on libwebkitgtk-dev, I'd assume.
<infinity> Oh, wait, wrong webkit.
<infinity> libwebkitgtk-3.0-dev
<versable> infinity: Right, that's probably it. Thanks.
<dholbach> good morning
<mlankhorst> infinity: feel free to kill the audit dependency for now
<mlankhorst> if it still builds
<mlankhorst> infinity: xorg-pkg-tools has the list
<mlankhorst> sec let me generate it
<infinity> mlankhorst: I was thinking that killing the audit dep was something you'd have to do in your fancy scripts, so it doesn't come back.
<mlankhorst> sure I'll do that too
<infinity> mlankhorst: But yeah, let me test-build quickly here.
<sarnold> why kill the audit dep? I thought audit had been promoted to main?
<mlankhorst> not in precise yet
<sarnold> ah
<infinity> sarnold: And the one in main won't ever be promoted, since it needs a ton of work to be acceptable.
<infinity> s/main/precise/
<infinity> Brain.  Hurting.  Long day.
<lifeless> infinity: isn't it 0800 for you? Or have you moved. Again.
<kiru> i'm a beginner,like to contribute to ubuntu please help
<infinity> lifeless: It's 1am.
<infinity> lifeless: It'll be 8am for me in a month when I'm in the UK, close enough. :P
<mlankhorst> but I've added /libaudit-dev/d for xorg-pkg-tools, next version should upload correctly
<lifeless> :)
<infinity> mlankhorst: Oh, hrm.  Dropping the build-dep isn't enough.
<infinity> mlankhorst: Oh, wait, I remember adding this.  It was also adding some selinux thing.
 * infinity checks the changelog.
<infinity> http://launchpadlibrarian.net/130794589/xorg-server_2%3A1.13.2-0ubuntu1_2%3A1.13.2-0ubuntu2.diff.gz
<infinity> mlankhorst: Needs to be the inverse of that.
<infinity> mlankhorst: Are your scripts smart enough to mangle 'selinux = --disable-xselinux' in debian/rules?
<mlankhorst> it's sed, i can just do it quickly
 * infinity rebuilds again.
<mlankhorst> -e "s/--enable-xselinux/--disable-xselinux/" \
<infinity> Should do.  It passed confugre with that, at least.
 * infinity waits for it to, like, build.
<mlankhorst> ok I'll bbl, weather is really nice so it's a crime not to bike :)
<infinity> mlankhorst: Heh.  Enjoy.  I'll just upload this as precise2, and if you ever have to respin, your scripts will DTRT?
<infinity> mlankhorst: http://paste.ubuntu.com/5741156/ <-- My debdiff, so you can check and see if your script produces the same change.
<smb> infinity, Hmmm... is this just broken by my reading? [ubuntu/quantal-proposed] linux_3.5.0-34.55_amd64.tar.gz - (Accepted)
<infinity> smb: You don't pay attention to -changes much, if that's the first time you've noticed that. :)
<infinity> smb: That's the uefi custom upload.
<smb> infinity, I probably do not do that much
<smb> It required this to be in a smaller quantity of updates for me to notice. :-P
<smb> Thanks for the explanation
<pitti> xnox: wrt. cryptsetup uninstall/plymouth in initramfs: is it possible that this is related to cryptswap?
<pitti> xnox: I use ecryptfs, so ubiquity set up a cryptswap device and thus kept the full cryptsetup package
<pitti> xnox: but (1) I doubt whether we really need swap that early (in intramfs), and (2) at least in the past we didn't set up cryptswap for non-ecryptfs; perhaps we do now?
<pitti> xnox: (I haven't checked anythign in ubiquity, it just came to my mind)
<xnox> pitti: correct. ecryptfs does pull in cryptsetup for encrypted swap. But default unecrypted (neither full, nor homedir) install shouldn't pull in cryptsetup.
<xnox> ecryptfs does encrypted swap for a few releases now (not sure when it started)
<pitti> yes, and that makes sense; I just wonder whether we need to set up/mount swap in initramfs already
<pitti> xnox: but that's actually unrelated; I guess (2) is the more interesting question in terms of initramfs size with all defaults
<xnox> we shouldn't, indeed.
<xnox> I'd like to still find out why/how we are regressed, instead of simply implementing conditional logic (do not include ecryptfs in initramfs, unless '/' or '/usr' are encrypted)
<pitti> yes, sure; ecryptfs and cryptswap just came to my mind as possible things which might have changed
<xnox> 20130521 saucy daily correctly removes cryptsetup & ecryptfs-tools in a default install, whilst 20130523 and later do not.
<xnox> pitti: so it seems like cryptsetup via ecryptfs-utils via adduser moved from "d-i-requirements" to "minimal" on 20130521, while on 20130520 it was not.
<xnox> and indeed in raring, cryptsetup was not in Task: minimal.
<pitti> eek
<pitti> indeed, only cryptsetup-bin is supposed to be installed by default
<pitti> that's why we split it out in the first place
<pitti> xnox: dropping adduser's ecryptfs-utils recommends to suggests?
<xnox> pitti: but it was there in raring as well, so how come it _now_ moved up?
<pitti> or ecryptfs-utils ought to recommend cryptsetup-bin only (but I'm not sure whether that's sufficient)
<pitti> perhaps that changed
<xnox> but versions of adduser, ecryptfs-utils nor crypsetup have not changed since raring yet.
<pitti> hm; I don't see how cryptsetup would not have been in minimal in raring then
<xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130520.log
<xnox> vs
<xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log
<xnox> Resolving minimal dependencies ...! Promoted ecryptfs-utils from d-i-requirements to minimal to satisfy adduser
<pitti> but indeed it wasn't
<om26er> i have a local repository, how can I increase its priority ?
<om26er> not sure what to put infront of "pin:" in the .pref file
<xnox> om26er: https://help.ubuntu.com/community/PinningHowto but please note if the packages have identical version number, the "first" repository wins.
<wgrant> pitti: saucy's translations are copied and imports are happening now
<pitti> wgrant: splendid, thank yoU!
<om26er> xnox, and if its a separate repo in /etc/apt/sources.list.d/ ?
<xnox> om26er: check with $ apt-policy package what "won"
<pitti> xnox: we didn't rebuild d-i or anythign like that on that day -- perhaps on that day someone processed priority-mismatches?
<om26er> xnox, here http://paste.ubuntu.com/5741445/ my repo is indeed getting higher priority, but I want to set it to 600 or 1000 just to be sure, but seems my pref file is broken ?
<xnox> pitti: should I upload adduser lowering ecryptfs-utils from recommends -> suggests?
<cjwatson> pitti,xnox: https://launchpad.net/ubuntu/saucy/i386/ecryptfs-utils says no
<cjwatson> Indeed there's a bunch of priority-mismatches I'd been deliberately not processing until I had a chance to think about it :)
<xnox> cjwatson: any idea how ecryptfs-utils got into minimal?
<xnox> but wasn't before...
<pitti> the more interesting question is how it was not in minimal in raring yet?
<cjwatson> A Recommends from adduser would be sufficient
<xnox> that was also present in raring.
<cjwatson> one moment
<xnox> i see that it moved into minimal on 20130521 http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log
<cjwatson> adduser wasn't in minimal in raring for some reason
<cjwatson> Ah, it was in required, which is really where it belongs IMO
<cjwatson> But required doesn't follow Recommends
<cjwatson> So I guess something in required dropped a Depends: adduser
<cjwatson> Well, I dunno, adduser in minimal vs. required is OK actually
<pitti> xnox: my gut feeling is that adduser should only suggest ecryptfs-utils
<cjwatson> TBH this is basically that the Recommends was incorrectly not noticed in raring
<cjwatson> So I'd say adduser should be left where it is and drop the Recommends to Suggests
<xnox> ack. will upload.
<cjwatson> (required doesn't process Recommends because it corresponds to debootstrap and debootstrap doesn't; but this does mean that there are some corner cases where Recommends kind of get lost)
<pitti>  xnox: ÑÐ¿Ð°ÑÐ¸Ð±Ð¾!
<Koterpillar> Where do I find documentation (ideally, examples) for implementing a host for Application Indicators? Not an indicator itself, but something that would show them?
<xnox> apw: i think you can still blame pitti and systemd for bootspeed regression, as it was udev that dropped adduser dependency when moving from udev->systemd source package thus triggering an unfortunate series of seed changes and promoting cryptsetup into minimal.
<xnox> =)
<pitti> fun -- making things bigger by *dropping* dependencies..
<pitti> TGIF!
<apw> xnox, heh :)  pitti TGFT
<apw> xnox, fixable without adding spagetti to the seeds ?
<xnox> apw: yeah, uploaded adduser that moves ecryptfs-utils from recommends to suggests. But it's kind of hilarious that adduser is now not required =)
<apw> heh yeah, it is a bit of a scarey thought all told
<pitti> well, there's always useradd, for really mini-minimal systems
<apw> so i shall look at the new boot charts on monday, fingers cross
<pitti> adduser is perl
<pitti> (perl-base only, so you can't get rid of that anyway, but still)
<rbasak> pitti: got time to talk about locales and postgres?
<pitti> rbasak: sure (didn't I talk enough yet on devel@? :-) )
 * xnox pretends to speak only ASCII based languages
<pitti> rbasak: that's where apw's spaghetti come in
<rbasak> pitti: I have a really long reply for you too. I was hoping to shorten it by talking on here :)
<rbasak> pitti: I think my objection lies in postgres' postinst behaviour
<rbasak> pitti: that if the *user* locale is bad, then the postinst's behaviour changes
<pitti> rbasak: that it fails in an invalid locale? I can change that (as I said in my mail)
<rbasak> pitti: I'm trying to verify this. I'd like the postinst to ignore the user's locale (ie. the environment) and use /etc/default/locale instead, if it is there.
<pitti> i.e . go from "fails to install" to "installs, but doesn't create any cluster"
<rbasak> pitti: I'm not sure that it does actually fail. I think it already has that behaviour. But I'm struggling to fire up a cloud instance to test at this moment.
<pitti> rbasak: you also need to check at least /etc/environment then, and quite possibly /etc/profile, /etc/profile.d/, and whereever else admins might drop locale definitions in
<rbasak> pitti: I'd like it to install *and* create a cluster by using /etc/default/locale.
<pitti> rbasak: no, the package installation does fail if pg_createcluster fails
<rbasak> pitti: the user's locale shouldn't matter.
<rbasak> It's confusingly inconsistent if the way a package is set up depends on the user's environment at the time of the dpkg run
<pitti> rbasak: well, it's the locale in a root context; the problem is that in that pathological case ssh + sudo carry the remote locale all the way into a root context where it is totally invalid
<rbasak> Even without ssh, if the user sets a valid locale in ~/.profile or ~/.bashrc or whatever and uses sudo, then it'll work but there's still an inconsistency
<pitti> rbasak: I share the feeling about inconsistency; I just don't know a good answer to it
<rbasak> What's wrong with using /etc/default/locale if it exists, falling back to /etc/environment?
<pitti> rbasak: in the bug report case there is no /etc/default/locale nor /etc/environment
<rbasak> Then that solves the ssh carry through an invalid locale problem too
<pitti> rbasak: the problem is that nothing specifies that locales must be defined in those two filese only
<rbasak> pitti: I think the bug would still exist if there is; I'll verify.
<rbasak> pitti: then in that case only, default to C.UTF-8 but prompt with debconf?
<pitti> rbasak: in my experiments, if /etc/default/locale actually does set a locale, that overwrites the one ssh is passing on
<rbasak> In the majority of cases, the installer would have fixed it in /etc/environment (old) or /etc/default/locale (new), and there will be no prompt.
<rbasak> For users with unusual systems, they'll be asked.
<pitti> rbasak: I really want to avoid debconf (for various reasons, see mail); using C.UTF-8 would be acceptable then
<rbasak> I'd be happy with C.UTF-8 with no prompting.
<rbasak> OK
<rbasak> Does that mean you agree with me? No using the environment at all; use /etc/default/locale, fall back to /etc/environment; fall back to C.UTF-8.
<pitti> then, what do we do about those people who actually want C (I got several reports there)
<pitti> rbasak: no, as I said these are not the only files where you can set the locale
<pitti> as the primary definition of "locale" is in terms of environment variables, there are a gazillion places to define them
<rbasak> How about an extra fall back to the environment but iff /etc/default/locale and /etc/environment doesn't set the locale?
<rbasak> I'm trying to pin down using the "system" locale here, rather than the user locale. Only the user locale is available from the environment.
<pitti> rbasak: ^ I don't know what you mean by this
<pitti> i. e. use /e/d/locale, if that doesn't define anythign, use /e/environment, if that doesn't define anything use the environment?
<rbasak> Or how about a debconf prompt with low priority for those who really need an override?
<pitti> that's exactly what leads to the curretn bug
<pitti> those who really need to change it can just specify it at pg_createcluster
<pitti> a debconf prompt is ridiculously expensive (given translations etc.) for such a small corner case IMHO
<rbasak> So fall back to C.UTF-8 then.
<pitti> rbasak: I'd actually fall back to C
<rbasak> OK, fine.
<rbasak> I just want /etc/default/locale used in preference to the user's environment.
<pitti> if a server does not define any system locale, then presumably the admin actually means it; not sure?
<rbasak> I think that'll fix the bug.
<rbasak> I understand that you don't think it will.
<rbasak> I will verify.
<pitti> rbasak: but.. there IS no /e/d/locale for the bug you reported/commented on
<pitti> the bug precisely happens on those systems which don't define a system locale
<doko> Riddell, how stable/good is kde in saucy (wanting to do a test rebuild)
<doko> seb128, didrocks , how stable/good is gtk/gnome in saucy (wanting to do a test rebuild)
<Riddell> doko: pretty good, I just uploaded all of KDE SC 4.10.4 which is due to start compiling right about now
<rbasak> pitti: I'm not sure that's the case. I believe the system I reproduced on did have /etc/default/locale set.
<pitti> rbasak: so what this would need is to find a way to tell whether a defined locale from the env that isn't in /e/d/l nor in /e/env comes from someplace else in the system or from sudo
<seb128> doko, it should be good/stable enough to have a rebuild, we are on the stable serie for both and have no update planned soon
<rbasak> pitti: I can't seem to reproduce right at this moment, because I can't get an available instance on a private cloud I have access to.
<doko> Riddell, well, if it starts compiling, then it's still in proposed?
<Riddell> doko: yes
<doko> so *not* ready
<pitti> rbasak: FYI, I use "run-adt-test -sl" for those; they are cloud-image based, and perfect for quick throwaway VMs
<pitti> (and all local)
<rbasak> Postgres is a very special case here.
<rbasak> Normally a locale setting doesn't cause any persistent changes to the system
<rbasak> I don't think it's safe for the environment to specify a locale for this purpose.
<rbasak> We should define where a system locale is defined, and use that
<rbasak> Or use C, and require people to override template1 when they need to.
<rbasak> Or use the locale of the user who runs createdb when he runs createdb to do it for him.
<pitti> ^ that already happens, I think
<rbasak> In that case, why does the postinst need to use anything but C?
<pitti> so perhaps a middle ground would be for the postinst to clean up its entire locale environment (LANG, LANGUAGE, LC_*), then source /etc/environment, then source /etc/default/locale, and then run pg_createcluster
<pitti> that'll break use cases where the admin defines a system locale in a different place, but these seem rather small to me (we have to compromise somewhere)
<cjwatson> You can't source /etc/environment safely.  It may look mostly like a shell file, but it has a formally different syntax; it's a pam_env configuration file.
<rbasak> That works for me
<pitti> cjwatson: ah, too bad
<cjwatson> Unfortunately pam_getenv is broken, or that would be the right answer.
<cjwatson> I think the above may be true for /etc/default/locale too, technically, although it's in practice safer since its key set is more restricted
<pitti> I've seen plenty of places which source /e/d/l, though
<cjwatson> Might be worth seeing how hard it is to fix pam_getenv ...
<pitti> /etc/init/mountall.conf
<cjwatson> I wouldn't get too upset about sourcing /etc/default/locale
<cjwatson> It might even be formally permitted, I forget
<pitti> so mountall will fail if sourcing /etc/default/locale fails
<pitti> I thought that was one of the reasons why it got moved out of /e/env
<cjwatson> But the locale hasn't been written to /etc/environment for years
<rbasak> Would it be OK to attempt to source /etc/environment, and ignore failures? Or is that unsafe too?
<cjwatson> Yeah, could be
<cjwatson> You have to go to considerable lengths to avoid that killing the calling shell
<pitti> cjwatson: right, but I still think it's a legitimate place for defining it
<cjwatson> . /etc/environment || true  <- not sufficient
<pitti> not wanting to be too selfish, but even my own server has that, and that was a debian install from a few years back
<rbasak> I only became aware of /etc/default/locale recently, when something broke. I've been using /etc/environment for a long time. But note that something broke (can't remember what).
<cjwatson> pitti: pam_getenv was meant to be the safe answer to this.  I'm not sure how long it's been broken for
<pitti> probably something like $(source /etc/environment  && locale |grep LC_CTYPE || true)
<cjwatson> Failing that, I guess you could source in a subshell and pass out the answers you care about, or something
<cjwatson> Yeah
<cjwatson> But . not source
<cjwatson> (source is a bashism)
<pitti> and with an actually correct || true'ing (not applying that to grep), etc., but something along that lines
<rbasak> Have we agreed with this as a solution then?
<rbasak> I still need to check that /etc/default/locale is actually set on the use case that generated the maas bug.
<rbasak> But I think it's reasonable to demand that it is set, even if the ssh session has a broken locale
<rbasak> Though with pitti's solution, it'd use C without a system locale defined, right?
<pitti> rbasak: well, in the cases where it isn't set, it would use C then
<pitti> rbasak: right
<rbasak> Great
<pitti> that still leaves the broken locale for everything else, of course
<rbasak> Right. I need to track down why Julian didn't get the cloud-init warning. Perhaps that's not the final solution but it should have worked for him.
<rbasak> Perhaps he wasn't using a cloud instance, thinking about it.
<rbasak> So no cloud-init.
<rbasak> I'll track that down with him.
<rbasak> For other things, the warnings about the locale being broken are fine, I think. At least no other functionality other than displayed messages are broken, AFAIK.
<mlankhorst> infinity: yeah it will be fine
<mlankhorst> thanks
<pitti> rbasak: I updated bug 969462 with a summary
<ubottu> bug 969462 in postgresql-common (Ubuntu) "fails to start after install if invalid locale is set" [Low,In progress] https://launchpad.net/bugs/969462
<rbasak> pitti: thank you! And for sticking it out with me on this.
<pitti> rbasak: heh, you're welcome; locales are messy :/
<pitti> rbasak: oh, actually, package installation does not fail in that case any more; that got changed a while ago
<pitti> sorry about that (but you wanted that behaviour anyway)
<rbasak> Right, OK, thanks. But the maas postinst will still fail without this new behaviour, right?
<pitti> there still wouldn't be a DB cluster to talk to, yes
<cjwatson> didrocks: Did you notice that a few bits of today's autolanding are stuck in -proposed because python-ubuntu-platform-api and uoa-integration-tests don't exist?
 * xnox tried to set C.UTF-8 locale & purge langpacks from my server. I'm still stuck with en_GB.utf8, en_US and en_US.iso88591 in locale -a output.
<didrocks> cjwatson: ah, I was waiting for still 30 minutes to see if things are wrong (now that all main promotion are done)
<didrocks> cjwatson: uoa-integration-tests is in NEW
<didrocks> part of my review list
<cjwatson> Oh, it is?  Ah, I missed it
<didrocks> python-ubuntu-platform-api? I need to look at it
<didrocks> cjwatson: does the migration tool tells you about Main/Universe as well?
<cjwatson> No
<didrocks> ok, as the migration is quite complex, I hoped I didn't miss anything
<didrocks> one sec for python-ubuntu-platform-api
<didrocks> hope*
<pitti> oh, I thought we were moving away from python
<pitti> ah, for tests?
<didrocks> pitti: probably for those
<didrocks> cjwatson: argh ok, autopilot-touch
<cjwatson> Right
<pitti> didrocks: btw, this was a nice read! https://launchpad.net/ubuntu/+source/autopilot-gtk/1.3daily13.06.05-0ubuntu1
<didrocks> pitti: heh, glad you like it :)
<pitti> didrocks: does uploading the package auto-close the upstream bugs, OOI?
<didrocks> it's matching any bugs related to the commit if there are, but keep the commit message (there is a list of commit message and a tag to not display some though)
<didrocks> pitti: no, long debate, nobody agrees, even between the different upstreams
<pitti> didrocks: autopilot-gtk doesn't have any ubuntu bugs, but a lot of upstream ones which were addressed by that
<didrocks> ok, for autopilot, let's do a manual upload removing the dep, we don't use autopilot-touch in the distro anyway
<didrocks> (downgrading to suggests)
 * cjwatson clears the broken lplib cache that'd broken component-mismatches
<didrocks> cjwatson: for daily release, I'm using a separate cache per process
<didrocks> only way to not have this issue
<didrocks> (that I found)
<cjwatson> I'm using separate caches for a lot of things but not quite everything :-/
<wgrant> I thought that fix was SRUed recently.
<cjwatson> I don't see it in python-launchpadlib/+changelog
<cjwatson> I think I asked for it ...
<didrocks> cjwatson: it's in lars.restful IIRC
<cjwatson> oh, python-lazr.restfulclient
<wgrant> lazr.restfulclient probably
<cjwatson> Apparently not to precise though
<wgrant> Ah
<cjwatson> bug 459418
<ubottu> bug 459418 in lazr.restfulclient (Ubuntu Precise) "Cache is not safe for concurrent use (by processes or threads)" [High,In progress] https://launchpad.net/bugs/459418
<cjwatson> cyphermox: ^- are you still planning on uploading that to precise?  it's been a few months
<cjwatson> and you could help make our archive reports more robust :)
<didrocks> and less emails because of the script being broken \o/
<rbasak> Any objections if I fix https://wiki.ubuntu.com/StableReleaseUpdates#Procedure? The "If you can't upload" section looks like it's got lost at the end of a bullet point; I think it needs to be clearer since people who can't upload may just assume that they can't do anything.
<cjwatson> rbasak: Go for it
<cjwatson> I agree that wants to be out a level
<rbasak> Done. Sorry, just realised after I hit submit that I left the changelog blank :-/
<cjwatson> *shrug*
<seb128> cjwatson, hey, is there a component mismatch report for packages in proposed?
<cjwatson> seb128: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<cjwatson> (thanks to Ursinha)
<seb128> cjwatson, ah, nice, thanks
<cjwatson> it's an hour or two out of date for reasons discussed above - should update at the next publisher cycle
<seb128> k
<Yud_Zroc> Is there a compiling guide for ubuntu?
<didrocks> cjwatson: thanks for the pocketsphinx upload :) I asked sil2100 to disable the powerpc tests and he was working on that this morning
<didrocks> sil2100: stop, not needed anymore :)
<sil2100> Ah, ok ;)
<sil2100> Well, it was just a quick fix anyway
<cjwatson> Heh, yeah, was just trying to clear a bit of component-mismatches
<cjwatson> And the sight of python-support offends me :)
<didrocks> cjwatson: does the migration to the main release pocket still don't retain the components in main?
<didrocks> ahah :)
<cjwatson> I don't understand the question
<didrocks> (I'm seeing the scopes in universe, I'm sure I NEWed them in main)
<didrocks> like https://launchpad.net/ubuntu/+source/unity-scope-devhelp
<cjwatson> There may be some LP bugs there
<didrocks> ok
<didrocks> I'll repromote them then
<cjwatson> https://launchpad.net/ubuntu/+source/unity-scope-devhelp/+publishinghistory definitely suggests a bug
<didrocks> no worry, it's a good "end of crazy week" monkey work I can do :p
<cjwatson> Probably YA stupid ancestry bug
<wgrant> cjwatson, didrocks: Copies don't do binary overrides
<wgrant> Well, they respect existing ancestry, but you can't specify overrides
<wgrant> Only for sources :/
<didrocks> wgrant: ah, ok, makes sense then :)
<didrocks> thanks for the explanation
<cjwatson> wgrant: But even the source was copied from proposed/main to release/universe
<wgrant> cjwatson: But the copy to -release was a cross-suite ancestry lookup
<wgrant> I don't think that works in many cases.
<wgrant> Hmm
<wgrant> But you're right about the source
<wgrant> So it's not binary-specific
<wgrant> Blargh.
<cyphermox> cjwatson: yes, I'll upload in a minute
<cjwatson> cyphermox: Great, thanks
<cyphermox> done, it will be in the queue
<cyphermox> has anyone besides me tried the packages?
<cyphermox> seems to work properly here, but maybe I'm not testing it right
<cjwatson> I think bits of the reports on lillypilly run with a similar local patch
<cjwatson> Just not all of them
<cjwatson> It might be worth upgrading lillypilly to a -proposed package by way of verification, once we confirm it basically works at all
<cyphermox> ok
<dobey> wgrant: thanks for the branch fixing
<cjwatson> arges: Could you merge iptables, or tell somebody else they can do it (you're touched-it-last so it defaults to you)?  There's some stuff in saucy-proposed blocked on that.
<arges> cjwatson: hi. Ok not really sure what you mean by merge, should i just try to reformat my patches to work on top of a fresh debian version?
<cjwatson> arges: https://merges.ubuntu.com/main.html
<cjwatson> Yours is only the most recent patch - there's a large stack of Ubuntu patches that need to be ported forward.  You might want to just ask jdstrand to do it since he did the last big chunk of work :)
<cjwatson> But we default to assuming that the person who uploaded it last will do it
<arges> cjwatson: well i'd love to learn and don't mind doing it
<cjwatson> arges: also https://wiki.ubuntu.com/UbuntuDevelopment/Merging, perhaps more helpful
<arges> thanks, answered my next question
<didrocks> cjwatson: pyruntest build-dep (for gtester2xunit) and julius-voxforge (recommended by hud) are the 2 we missed I guess. We filed the MIRs, but that won't block the iso building if it's not treated today (as being build-dep and recommends only), right?
<xnox> arges: there is also a UDD / bzr workflow. When branches are up to date... and when bzr manages to merge sensibly.... http://developer.ubuntu.com/packaging/html/udd-merging.html
<arges> xnox: ok thanks
<cjwatson> didrocks: shouldn't, from that description
<didrocks> ok, thanks :)
<cjwatson> platform-api will be a blocker though
 * cjwatson moves unity-scopes-runner and the various hud binaries to main
<cjwatson> oh, maybe somebody had done the latter already
<arges> xnox: so i should be merging from debianlp:squeeze/iptables (in this case) which seems to be at an older version, or bzr merge-upstream seems to be at a newer version that whats reported on the merges.u.c page
<xnox> arges: usually one merges from lp:debian/iptables (aka sid) or from lp:debian/experimental/iptables (if that's what needed/wanted)
<cjwatson> You should certainly not be merging from squeeze, which is oldstable :)
<cjwatson> Ever
<arges> cjwatson: xnox: ok should the wiki be updated then?
<arges> http://developer.ubuntu.com/packaging/html/udd-merging.html
<xnox> hmm.... it's a bzr branch somewhere.
<cjwatson> I don't think that's a wiki - but yes, that's completely wrong, merge frmo sid
<cjwatson> *from
<arges> i'm guessing its meant to be more of a generic guide
<arges> ok
<cjwatson> No point being generic since package merging is basically for one purpose
 * xnox found a branch and will update in a sec.
<mterry> cjwatson, thanks for fixing the pocketsphinx build on powerpc.  I was considering disabling, but hadn't researched the failure yet
<mterry> We have a similar problem on sphinxbase, but it also fails on i386 as well as powerpc
<arges> cjwatson: do i need to be filing a merge bug before working on this btw?
<cjwatson> I thought it was probably more urgent to get the python-support dep out of main than to worry about the test failure
<cjwatson> arges: no
<arges> ack
<cjwatson> arges: you're touched-it-last, it's yours by default
<cjwatson> merge bugs are weird things anyway imo :)
<arges> ok next question: so i merged with bzr merge lp:debian/iptables into lp:ubuntu/iptables, and the conflict doesn't match whats here : https://merges.ubuntu.com/i/iptables/REPORT
<arges> the versions match what the merge tool did btw
<stgraber> oh, nice, Debian has iptables 1.4.18 now, that means that once arges is done with the merge I'll be able to stop using my locally packaged 1.4.18!
<stgraber> (1.4.18 introduces IPv6 NAT which I need to provide easy IPv6 to containers and VMs)
<cjwatson> you shouldn't necessarily expect bzr and MoM to produce the same results; you're meant to use judgement
<arges> ok
<cjwatson> they're differently smart in different ways
<cjwatson> for the most part MoM is likely to be cruder
<xnox> mterry: hello, I had a ping from you yesterday but i was gone, and then you were gone. What's up?
<mterry> xnox, hi~
<pitti> oh, hud now pulling in the voxforge stuff?
<pitti> are we getting speech recognition into the desktop now?
<pitti> (just seen the new universe â main mail)
<pitti> didrocks: ^ FYI, this will block propagation, in case you aren't aware
<pitti> so we all need to become much more careful what we yell at our #$#@)*# machines during debugging -- it might land right in the amazon online search!
<pitti> (I'm more scared that it might actually find something)
<cjwatson> pitti: component mismatches don't block propagation to release
<xnox> cjwatson: but the iso will fail to build?!
<pitti> cjwatson: uh?
<pitti> cjwatson: it should, though, as it will make hud uninstallable?
<cjwatson> xnox: didrocks and I established they won't
<cjwatson> pitti: it's just a recommends
<pitti> aah
<xnox> pitti: well there is no such concept in debian, hence britney doesn't have such feature... yet.
<cjwatson> furthermore educating britney about components would be hard so I haven't :)
<cjwatson> it's a rare-ish problem anyway
<pitti> i. e. we rely on "the daily iso doesn't build" indicator to revert cases which break stuff in a major way
<pitti> xnox: Debian has a policy that main packages mustn't depend on contrib or non-free; isn't that exactly the same thing?
<cjwatson> pitti: with the exception of platform-api, I believe it's all sorted
<tjaalton> what's up with llvm-3.2?
<pitti> nice
<cjwatson> pitti: they do, but britney doesn't enforce it
<pitti> cjwatson: ah, good to know; I (dangerously) assumed it would
<pitti> thanks
<tjaalton> mesa ftbfs due to " llvm-3.2-dev : Depends: llvm-3.2 (= 1:3.2repack-7) but it is not going to be installed"
<cjwatson> tjaalton: new llvm-toolchain-3.2 needs clang in main.  I haven't checked what's going on there, whether it's a dropped Ubuntu patch or genuine
<cjwatson> there's been some reorganisation there
<tjaalton> ah, ok
<pitti> oh, wow! seb128, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wants to demote gnome-desktop to universe at last \o/
<seb128> pitti, \o/ (what was still using it?)
<cjwatson> hm, maybe it's just trivial component-swapping actually
<pitti> seb128: not sure, I just saw it; I don't often look at c-m these days
<seb128> pitti, great in any case ;-)
<cjwatson> tjaalton: next publisher run might sort it out
<tjaalton> cjwatson: ok, thanks!
<DktrKranz> pitti: is source for c-m published somewhere? I'd like to have something similar for Debian too
<cjwatson> DktrKranz: lp:ubuntu-archive-tools.  It's very very very Ubuntu-specific though - it's reliant on germinate output
<cjwatson> I'm not TBH sure how it would be useful for Debian
<cjwatson> (It specifically doesn't handle free vs. non-free moves)
<DktrKranz> ah, pity
<cjwatson> It's just for the supported vs. not distinction
<cjwatson> But feel free to pull something out of it if you find it useful, obv
<DktrKranz> thanks!
<infinity> Speaking of components.  I'm trying to sort out why julius, which is in multiverse, claims to be in the ubuntu-desktop task.
<infinity> That doesn't seem right...
<infinity> Oh, hud.
<infinity> Lolz.
<cjwatson> Recommends from julius-voxforge
<cjwatson> Probably needs to be dropped to Suggests
<cjwatson> Assuming julius does actually belong in multiverse
<didrocks> yeah, we need to discuss with the touch guys
<cjwatson> OK, seriously confused about llvm, actually.  Trying to disentangle
<didrocks> infinity: cjwatson: no more julius for the next daily release (Monday)
<infinity> cjwatson: Isn't it just that llvm-toolchain-3.2 replaced llvm-3.2, *and* it now pulls in clang?
<didrocks> as it doesn't break the iso, I won't rush an upload :)
<cjwatson> infinity: except there's something weird going on with clang vs. llvm-defaults
<infinity> Oh, wait, it now GENERATES clang, rather than pulling it in.
<infinity> They've merged the sources upstream, I guess.
<cjwatson> Debian has llvm-defaults 0.17 which seems to have vanished from Ubuntu
<infinity> That can't be a bad thing, maybe clang won't be such utter crap.
<infinity> So, yeah, we definitely need the new llvm-defaults.
 * cjwatson tries explicitly syncing it
<infinity> And I think we need to suck up clang in main, cause splitting this back out will probably be more effort than it's worth...
<infinity> Maybe.
<infinity> Well, at least libclang.
<infinity> We might be able to keep the compiler frontend out.
<xnox> smoser: Hello, you around? =)
<cjwatson> Ah, auto-sync wouldn't have wanted to sync it because clang was modified in Ubuntu
<cjwatson> Of course
<cjwatson> infinity: Did you ever check over the llvm-3.2 / clang Ubuntu deltas to see if anything needs forward-porting?
<infinity> cjwatson: I haven't yet, I should do today.
<cjwatson> If you could, that would spook me less, yeah
 * infinity nods.
<infinity> This whole thing took me rather by surprise, I assume llvm-thingee got autosynced and blew up our carefully-crafted house of cards.
<infinity> If we still have patches, they're probably one or two tiny ones I can forward-port and forward.
<infinity> Will check after I've rebooted, filed a kernel bug, and had breakfast.
<cjwatson> No, it didn't get auto-synced.  Sylvestre filed a sponsorship request or similar and dholbach processed it.
<cjwatson> auto-sync was rightly holding off until somebody had a chance to manually resolve the whole stack.
<cjwatson> So it's possible we've actually synced a version with the wrong vendor ID, missing support for saucy, and such.
<cjwatson> Depending on how clever the latest source is.
<pitti> didrocks: reading your "landed" mail, congratulations! that was a big chunk
<didrocks> thanks pitti! Happy it's done :)
<pitti> didrocks: and nice timing on a Friday afternoon :)
<didrocks> isn't it? :)
 * pitti resists the temptation to upgrade now, otherwise I'll spend my Saturday fixing my machine
<pitti> j/k
<xnox> pitti: you are _not_ running saucy?
<infinity> Clearly, I should never have rebooted.
<infinity> Now compiz is segfaulting on every run.
<infinity> \o/
<pitti> xnox: of course I do, but I only upgrade in the mornings usually
<xnox> pitti: I see.
<pitti> xnox: I don't have a raring machine :)
<pitti> in fact, it seems I don't even have a raring schroot yet; must be less than three months, i. e. I didn't yet have to do a postgresql update for stables
<infinity> Mirv: Did anyone every get a chance to look into that compiz-versus-glib segv?
<xnox> pitti: my irc-proxy was upgraded to raring this week. Not sure if I should go for saucy or not.
<cjwatson> I think gtk+3.0 needs a rebuild against new wayland ...
<infinity> Mirv: It's driving me batty.
<cjwatson> mesa too
<Laney> cjwatson: seb128 is doing it
<Laney> well, gtk, don't know about mesa
<barry> yikes, how dead is the latest compiz?
<infinity> Oh, I thought that was Colin's impression of Jar Jar.
<cjwatson> ok, long as somebody's on it, it makes p-m output giant
<infinity> barry: It hatses me.
<cjwatson> infinity: that's the segfault-for-fun-and-profit thing?
<barry> infinity: it is teh crashez
<infinity> cjwatson: Neither fun nor profit.
<cjwatson> I've had 'unity --replace &' running on tty1 for a while ...
<infinity> cjwatson: Considering high velocity introcution of laptop to wall.
<infinity> introduction*
<cjwatson> Well, DISPLAY=:0 that, but
<infinity> Well, I win some sort of prize for this.
<infinity> I now have a classic X cursor on my tty1.
<barry> one small silver lining is that the nsa is now being deluged by crash reports
<cjwatson> infinity: ha
<infinity> kms, you make me giggle.
<Laney> so I shouldn't hit go on this dist-upgrade then?
<cjwatson> xnox: thanks for merging gdcm
<barry> Laney: only if you want to take an early weekend
<cjwatson> Laney: compiz has been crashy for a while now ...
<infinity> This is still the same compiz/unity from raring.
<infinity> But every new glib update seems to make it worse. :P
<Laney> oh, alright
<Laney> Doesn't seem particularly bad here
<barry> hmm, both my saucy desktops are totally useless now
<seb128> segfaults should be fixed in today's version
<infinity> I seriously can't get it to log me in now...
<cjwatson> Laney: I think the pattern is glib cleans up memory leaks => things that failed to increment refcounts properly died
<infinity> Maybe a by-hand run will work for now.
<xnox> cjwatson: no problem, retried insighttoolkit4 as well.
<cjwatson> xnox: I noticed, thanks
<infinity> Nope.
<infinity> *sigh*
<cjwatson> seb128: I hope so :)
<infinity> seb128: When can I haz this version?
<Laney> gdcm actually got fixed?
<seb128> infinity, it's in saucy ?
<infinity> seb128: I literally can't log in anymore.
<cjwatson> Laney: apparently
<seb128> infinity, since when ?
<Laney> wowzers
<smoser> xnox, here.
<infinity> seb128: Wait, today's version of what?
<barry> seb128: nope. i *just* dist-upgraded and compiz is completely useless
<smoser> i 'never minded' my ping of you yesterday
<seb128> infinity, unity; sorry I didn't follow the backlog
<seb128> barry, backtrace?
<infinity> I got no new unity today.  Has it made it out of proposed?
<infinity> Oh, hah, it must have JUST promoted.
<infinity> barry: Try again?
<barry> seb128: yeah, i'm trying to get a bug report filed, but have to do it remotely
<jbicha> infinity: I have the new Unity; it just won't run here :(
<infinity> Oh joy, I get a bunch of new scopes forced on me.
<barry> infinity: trying...
<infinity> Oh, just recommends.
<seb128> was any package let on hold of the upgrade or removed?
<jbicha> infinity: but no unity-lens-shopping; see, Ubuntu does listen to its users ;)
<seb128> can pastebin your dpkg.log?
<infinity> jbicha: Heh.
<Laney> hah, yeah, compiz segfaulted immediately after the upgrade
<Laney> seems to have respawned itself alright though
<xnox> smoser: oh. ok. What was it though? Anyway, I'd wanted to say that I did cherry-pick all relevant fixes, and the delta as part of last upload is what we are planning to SRU into Raring to fix all of issues with forgotten events.
<jbicha> seb128: the only removals were appmenu-gtk, appmenu-gtk3, and the shopping lens
<xnox> smoser: we hope it's sufficient for cloud-init case. Ideally one would still need to refresh raring images, after sru is published, given the caveats outlined in the bug report.
<seb128> jbicha, nothing on old?
<seb128> hold
<jbicha> no
<seb128> can you get a stacktrace?
 * barry has the same experience as jbicha 
<xnox> smoser: do you have any questions about upstart fixes? or you still need to try them first?
<smoser> xnox, well i haven't tried them.
<smoser> but the reproduce case was pretty straigt forward.
<smoser> my ping was complaining about not restarting
<jbicha> my ~/.xsession-errors or ~/.cache/gdm/session.log doesn't seem to have any useful info
<xnox> smoser: ack. jodh is on holiday, feel free to ping me if anything comes up.
<smoser> (on upgrade)
<smoser> i guess you're only doing that if its the old version though.
<smoser> which is sane.
<smoser> and wont really be a problem.
<smoser> the images will get refresshed and have this new udev in thm and then that will be that.
<xnox> smoser: well, it will restart on upgrade, if the upgrade is done at runlevel 2. If one is in early boot, the upgrade will not restart. (e.g. not yet fully initialised cloud-init instance)
<smoser> er.. s/udev/upstart/
<seb128> jbicha, what if you run unity from a vt?
<barry> infinity, jbicha, seb128 good news.  another dist-upgrade and my desktop is happy again
<smoser> xnox, yeah, i had thought you could restart after reaching runlevel 2 in that case.
<smoser> but that adds complexity
<xnox> smoser: we could hint that reboot is required instead if the upgrade was done in early boot, but I remember you said you don't want to reboot.
<smoser> ie, youcould add a job that would run on rc 2 and then it would delete itself.
<smoser> right. you could mark the 'reboot-required'
<infinity> Huzzah, I'm in a unity session!
<smoser> it would seem that you probably should mark that, dont you think?
<smoser> as a reboot *is* required.
<seb128> barry, cool
<xnox> smoser: reaching runlevel 2 is outside of dpkg control, so I'd rather not have ethermal jobs to do that. pitti was also asking for "ethermal" configuration location e.g. /run/init/
<pitti> ("ephemeral"?)
<smoser> :)
<xnox> smoser: yeah, we should mark reboot-required. I'm now not sure why in the end we didn't add it in. I'll check my notes from the sprint.
<smoser> but ethermal sounds good too
<xnox> pitti: smoser: yes =) my big words should usually be filtered through fuzzy match by context.
<smoser> xnox, all in all, i think its sufficient, and soon enough we'll have fully owrking images.
<xnox> true.
<mlankhorst> soon we'll have eternal configuration locations
<smoser> i have to remove the work around in cloud-init also. as to avoid breakage, it does not reload-configuration after writing an upstart job
<smoser> (that is required for the case where /etc is overlayfs or some other non-inotify friendly fs)
<smoser> and wasn't supposed to hurt anything :)
<xnox> =)))) true.
<infinity> Aww, crap.  I must have closed firefox twice in a row at some point and lost my several-hundred-tab session.
<xnox> smoser: to be honest, I'm of an opinion reload-configuration should live in upstart-file-bridge or upstart itself. E.g. one puts inotify watch on '/' which will get a create event, as soon as anything is written on to overlayfs top level dir, and if it happens to be a "create /etc folder" we should reload.
<seb128> jbicha, does another dist-upgrade fix it for you like for barry?
<infinity> Grr.
<infinity> I blame compiz.
<Laney> Ahh, mesa is caught up with llvm
<cjwatson> infinity: might still be in one of the sessionstore.* files in your profile
<Laney> So I guess wayland is stuck until then
<infinity> seb128: I seem to be back in business after another dist-upgrade but, then again, I'd been able to run it in the past too, so I dunno.
<infinity> cjwatson: Timestamps and sizes on those don't look promising.
<infinity> Yeah, I think it's lost for good.
<seb128> infinity, if you have an issue please try to get a backtrace, or ping me and I will help to get debug infos
<cjwatson> infinity: backups?
<smoser> xnox, i'm confused. i what is different currently than what you're saying ?
<smoser> oh. i see.
 * Laney restarts session with some trepidation
<xnox> smoser: upstart should be resiliant against hostile fs, instead of cloud-init lending a helping hand ;-)
<infinity> cjwatson: I don't backup that frequently.  I'm sure I'll live with a fresh firefox start.
<infinity> cjwatson: Those tabs just end up being a depressingly long TODO-that-never-gets-TODONE anyway.
<infinity> seb128: If it explodes again, I'll be sure to yell.
<cjwatson> My backups sucked until I made it a daily cron job.
<cjwatson> Although I do need to get a secondary backup disk again.
<infinity> cjwatson: My laptop isn't really all that critical to me, which is why I don't backup often.
<infinity> cjwatson: Other than PGP and SSH keys, the rest of this data is meaningless to me.
<infinity> And those don't change often. :P
<cjwatson> It's more minimal-hassle-of-recovery than meaningfulness for me, I think.
 * xnox wiped openssh-server keys of my machine the other day..... happens. couldn't be bothered to restore from backup. plus got a new shiny ecdsa key.
<barry> doko: ping
<doko> barry, ?
<barry> doko: hi.  i want to work on sru'ing lp: #1058884 today.  just wanted to check with you so i don't step on your toes if you're planning anything else
<ubottu> Launchpad bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [Undecided,Confirmed] https://launchpad.net/bugs/1058884
<doko> barry, there are still some packages in proposed, I think. but I would have to recheck
<barry> doko: i saw that proposed is a bit ahead.  would you rather i wait until they clear or should i just go ahead and backfill them?  (fwiw the bzr branches should be current w/the proposed backlog)
<bdmurray> cjwatson: could you have a look at bug 1187233?
<ubottu> bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [Critical,New] https://launchpad.net/bugs/1187233
<cjwatson> bdmurray: I punted that over to shim since it doesn't seem to be a GRUB problem; if slangasek has a chance to look, he knows rather more about shim than I do
<cjwatson> (It's reminiscent of the problem stgraber reported just before the last physical UDS, FWIW)
<cjwatson> Might just be an our-shim-is-too-old problem
<doko> barry, weill, you can add the patch on top, but make sure to correctly generate the changelog
<infinity> xnox: I don't care about host keys at all, but losing ssh user IDs is a pain, I do keep those in more than one place.
<barry> doko: will do, thanks
<jbicha> Unity is working now here but I'm not sure what changed :|
<bdmurray> cjwatson: okay, thanks
<infinity> Aww, crap.
<infinity> seb128: Remember when I lost detached menus in some applications but not others?
<infinity> seb128: Do you remember why that was?
<infinity> seb128: Cause it's back. :)
<seb128> infinity, no
<infinity> Oh.
<infinity> Poo.
 * infinity tries to remember WTF caused that.
<infinity> seb128: Ahh, the upgrade installed unity-gtk2-module unity-gtk3-module, which removed appmenu-gtk appmenu-gtk3
<infinity> seb128: Was that intentional?
<seb128> infinity, yes
<seb128> infinity, did you restart your session?
<infinity> seb128: Kay, well.  I no longer have global menus in pidgin.
<infinity> seb128: I rebooted after the upgrade, so yes.
<seb128> infinity, do you have unity-gtk2-module?
<seb128> oh yes, you said that
<seb128> infinity, I'm about to do an upload of gtk2/gtk3, let me know if those fix your issue
<infinity> seb128: Mmkay.
<pitti> wow, dist-upgrade will use 48.5 MB additional space
<infinity> pitti: All the new lenses?
<pitti> infinity: yeah, and the voxforge stuff presumably is quite heavy
<infinity> I admit, I dist-upgraded with --no-install-recommends
<pitti> yeah, I'm pondering that
<infinity> pitti: Which would also cull out voxforge stuff.
<pitti> infinity: cf. my statement above about yelling crap at my computer during debugging, and then finding amazon search results for that in the dash..
<infinity> pitti: Hahaha.
<pitti> unity-scope-guayadeque, urgh
<pitti> do we really need to install and run all these scopes by default?
<pitti> I mean, how many people are going to use all those?
<Laney> haha, that package's long description is ex-ce-llent
<seb128> pitti, we don't run them
<Laney>  This package contains the "guayadeque" scope which allows Unity
<Laney>  to search for guayadeque content.
<seb128> pitti, we activate them on demand when the server says to use them
<pitti> infinity: ah, but even without recommends it's still +35 MB, as the sphinx/voxforge stuff is apparently required
<seb128> it's voice stuff for the hud
<pitti> right, I know
<pitti> let's see how well this machine will understand me
<pitti> seb128: est-ce qu'il peut comprendre franÃ§ais ? :-)
<seb128> je ne sais pas ;-)
<tedg> pitti, We need more data, basically for each language we need 100hrs of samples.  Unfortunately English is the only one there.
<pitti> j/k
<pitti> yeah, I saw, it's just -hmm-en for now
<infinity> pitti: Curious, I was able to remove the voxforge stuff post-upgrade.
<tedg> I figure next sprint that is in a non-English country we should sit at Starbucks for a day and get samples from people in line :-)
<infinity> pitti: Can't be THAT required.
<jbicha> I don't see guayadeque in the Filter Results list; I think Unity is smart enough to not show it if guayadeque isn't installed
<pitti> Laney: yeah, seems all scopes have the exact same description with just the name changed
<jbicha> there's a QueryBinary=guayadeque field in /usr/share/unity/scopes/music/guayadeque.scope
<pitti> tedg: perhaps we shouldn't pull in the -en voxforge bits through direct dependencies, but through our "install language support" magic
<pitti> tedg: (at least in teh future, when we actually do have multiple languages)
<tedg> pitti, That would make sense to me.  We need to make HUD smarter to handle those languages, but yes.
<tedg> pitti, I'd really like to set that up as a way that Loco's could help out.
<tedg> pitti, Submit language data to voxforge
<tedg> We might be able to get to 100hrs for major languages then.
<Laney> how do I try that stuff out?
<tedg> Laney, The voice recognition?
<Laney> yeah
<tedg> Laney, You can get hud tools and use the hud-gtk frontend, or else with Unity 8.
<Laney> tedg: ** (hud-gtk:11375): ERROR **: hud-gtk.vala:139: Failed to open file 'share/hud-gtk/hud-gtk.ui': No such file or directory
<Laney> ;-)
<tedg> Uhg
<tedg> cd /usr/share/hud :-)
<Quintasan> Laney: I believe I sent you a mail asking if you would sign my new GPG key as I did a transition, do you respect those or I have to catch you on some conference?  :P
<Laney> Probably not, sorry
<Laney> come to debconf :-)
<Quintasan> Laney: I see. Switzerland it is. Never been there, might attempt to get there :P
<ogra> oh, debconf is in ch ?
<Laney> sure is
<ogra> hmm
<infinity> cjwatson: So, looks like this only dropped one of our llvm-3.2 patches, the rest made it back to Debian or upstream, I believe.
<infinity> cjwatson: Checking clang patches now.
<cjwatson> Could be worse then
<infinity> cjwatson: Testbuilding before upload, but it looks like this is our remaining delta: http://paste.ubuntu.com/5742432/
<infinity> cjwatson: I need to rethink the "list every release ever" madness, and try to simplify that for upstream for all distros, it's borderline insanity.
<cjwatson> Distro-specific version comparison would be less bad
<cjwatson> infinity: BTW your changelog is wrong, s/Raring/Saucy/
<infinity> cjwatson: Picky, picky.
<infinity> cjwatson: The queue would have told me ALL about that. :)
<infinity> cjwatson: It would have said "dude, that's in unapproved", and I would have jumped on #launchpad-ops and screamed "WHO FROZE MY ARCHIVE?!" and then felt like a right git when I realized I just can't read.
<infinity> cjwatson: Oh.  You mean the description of the patch, not the upload target.
<infinity> cjwatson: La la la.
<cjwatson> I did :)
<infinity> cjwatson: That's okay, it was wrong in the patch header too.
<cjwatson> Capitalisation hint and all.
<infinity> cjwatson: I suspect I cargo-culted it from the last time I'd done the same thing. :P
 * infinity wonders what the ratio of cargo-culting programmers to historical cargo-cultists is.
<cjwatson> I hardly ever even write new changelog entries when I can copy-and-paste the last similar one I wrote
<menace> is there any point in removing all read-privileges for /etc/sysctl.conf or /etc/syslog.conf in terms of security in an standard installation? just stumbled over that in a installation procedure...
<sarnold> menace: won't a user still be able to dump all the settings via sysctl -a ?
<sarnold> .. or read values out of /proc ?
<arges> jdstrand: hi
<sarnold> arges: he's out-of-office this week..
<arges> sarnold: ah... was going to have him review my iptables merge
<arges> i'll ping him next week then
<sarnold> arges: okay :)
<slangasek> pitti: hey, have you seen bug #1181810 on upower, and do you have any idea what might be causing it?
<ubottu> bug 1181810 in upower (Ubuntu) "After upgrade to saucy, lid close policy is not being respected" [High,Confirmed] https://launchpad.net/bugs/1181810
<slangasek> pitti: I'm not sure if it could be related to the changes made to acpi-support
<slangasek> (though probably not, I guess, since there's now nothing in acpi-support which handles lid close events)
<josepht> slangasek: that looks like a dupe of bug 1180513
<ubottu> bug 1180513 in gnome-settings-daemon (Ubuntu) "lid close actions are ignored laptop always suspends" [Medium,Triaged] https://launchpad.net/bugs/1180513
<slangasek> josepht: ah, ok
<slangasek> josepht: thanks for the pointer, that does indeed look like the same issue - and I see I was pinging the right person, as pitti assigned the bug to himself ;)
<arges> cjwatson: so i did a iptables merge that installs, runs. whats the best way to post it so that others can review? I could not get the bzr merges working properly, so I used the grab-merge.sh script.
<infinity> doko: Can you avoid retrying the armel gcc-4.8 build in toolchain-r after I kill it?  It seems to be taking out pandas left and right.
<slangasek> armel?
<infinity> slangasek: quantal.
<slangasek> hmph :)
<kees> sarnold: not all of them, actually.
<kees> $ ls -la /proc/sys/fs/*prot*
<kees> -rw------- 1 root root 0 Jun  7 11:33 /proc/sys/fs/protected_hardlinks
<kees> -rw------- 1 root root 0 Jun  7 11:33 /proc/sys/fs/protected_symlinks
<kees> an attacker has to trip the warning to find out if they're set ...
<kees> so, it's an interesting point about /etc/sysctl.*
<kees> though it's no secret what a distro's settings are.
<lifeless> kees: zomg people know what we build our binaries with?
<Mirv> infinity: I believe you should have gotten the fix around ~now with today's updates
<infinity> Mirv: Indeed, I seem to be more stable now.
<infinity> Mirv: Fingers crossed.
<kees> lifeless: they do indeed! :)
<sarnold> kees: oh, neat :) I've not noticed the tripwarning before :) hehe
<kees> sarnold: yeah, if you trigger the link protections, and audit notice is generated
<cjwatson> arges: best thing to post is a debdiff from current Debian
<bdmurray> slangasek: could you have a look at bug 1187233?
<ubottu> bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [Critical,New] https://launchpad.net/bugs/1187233
<slangasek> bdmurray: well, I suppose I'll need to, yes; this isn't going to be a bug we can fix quickly, there's minimal debugging capabilities here
<slangasek> more precisely, getting a debug build of shim will require fiddling the secureboot settings in ways that may prevent the problem from being reproducible anyway... but I'll see what I can do - next week
<bdmurray> slangasek: okay, sounds good.
<cjwatson> pitti: Please stop dropping the devpts mount from the d-i udev startup script; /usr/share/initramfs-tools/init is not used for d-i
<cjwatson> pitti: I'm putting it back to unbreak the server images
<cjwatson> (debian/extra/udev.startup is used nowhere else than d-i)
#ubuntu-devel 2013-06-08
<maxiaojun> anyone taking care of add-apt-repository ?
<j`ey> I'm getting the following error: mk-build-deps: Unable to find package name in `apt-cache showsrc debian/control
<cjwatson> Can you pastebin your debian/control?
<j`ey> when running "mk-build-deps --install --tool "apt-get -y" --build-dep debian/control", anyone know how to solve it?
<j`ey> cjwatson: where does that live>?
<cjwatson> In your source tree ...
<cjwatson> I mean, relative to whatever your current directory is
<j`ey> ahhhh
<j`ey> sorry, I see
<j`ey> I thought debian/control was a package name or something
<j`ey> my bad, it works now :P
<cjwatson> Oh, indeed, build-dep debian/control makes no sense, that's a file name :)
<cjwatson> Although mk-build-dep is supposed to be able to operate on a debian/control file
<j`ey> I was just in the wrong directory
<ricotz> jamespage, hi, libunwind8-dev is missing the pkg-config file
<g25d554gf> HI
<g25d554gf> im mehdi
<g25d554gf> BYE
<infinity> Riddell: kdev-python ships a lot of libraries that looks suspiciously more like plugins: libkdev4pythonduchain.so, libkdev4pythonparser.so, etc.
<infinity> Riddell: Are you sure those shouldn't perhaps be in /usr/lib/kde4 instead of /usr/lib?
<infinity> Riddell: Also, ./usr/lib/libpython2.7-kdevelop.so.1.0 and ./usr/lib/libpython2.7-kdevelop.so both being real files instead of one being a symlink seems a bit suspect.
<Riddell> infinity: I'll ask upstream
<Riddell> infinity: upstream says..
<Riddell> 23:15 < scummos_> probably all of that is right
<Riddell> 23:16 < scummos_> I'll report a bug to myself and take care of it before the 1.6 release
<infinity> Riddell: http://paste.ubuntu.com/5746560/ <-- Being the full contents of /usr/lib, for reference.
#ubuntu-devel 2013-06-09
<OdyX> tkamppeter_: Hi. Can you enlighten us on Debian's #698141 ? As I understand it, 2) is the answer, right ?
<tkamppeter> OdyX, 1, 2, 4 is corect, 3 is wrong.
<OdyX> tkamppeter: great, thanks
<tkamppeter> OdyX, 1 needs BrowseLocalProtocols cups, 2 needs BrowseRemoteProtocols cups, 4 needs BrowseRemoteProtocols dnssd and avahi-daemon.
<OdyX> tkamppeter: ah, fantastic; will add that to the package description then.
<OdyX> tkamppeter: does it really work on Cups < 1.6 ?
<tkamppeter> OdyX, I did not test, but the requests it sends to CUPS are only creating and removing queues. This should not have changed between CUPS 1.5 and 1.6. So it should work with old CUPS when appropriate legacy CUPS broadcasting ot browsing is activated as I described above.
<OdyX> tkamppeter: besides there's no real interest in doing that, no? (unless we'd provide backports)
<tkamppeter> OdyX, yes, there is really no necessity of using it with 1.5 as you say, as all distros with 1.6 contain it.
<tkamppeter> OdyX, so in the bug 4) principally works, but in this situation one would use cups-browsed on the remote server instead.
<ubottu> bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4
<infinity> Does anyone else find GCC's '-mcmodel=large' option hilarious?  Or am I just suffering lack of sleep?
<penguin42> infinity: You need some sleep
<mzaza> Hello, I just finished learning C++ and I was looking to contribute to a C++ project to master the language and extend my skills. Any recommendation for small scale project someone with almost no experience could start working on?
<mzaza> Is that the right place to ask such question?
<penguin42> it's a bit general here - but there are lots of C++ based projects; Qt is heavily C++
<JanC> often the best way to get started in a project is to investigate & fix some bugs in the bug tracker of the project
<infinity> `reverse-depends libstdc++6` is a lovely list of C++ projects.
<jbicha> could someone mark https://code.launchpad.net/~darkxst/ubuntu/raring/gnome-contacts/lp1033262/+merge/167876 as merged
<stgraber> done
<infinity> Wouldn't the importer have caught that on its own anyway?
<infinity> Well, once it was accepted, I guess.
<stgraber> not sure, in my experience the only reliable way to get one of those closed is to have them properly merged in the UDD branch or have a TB member manually mark them as such.
<stgraber> I'm not sure how the importer would notice that this specific branch has been merged, short of trying to merge every pending branch and see if the result matches the current state of the world
<infinity> stgraber: It seems to do an okayish job if you upload something pretty close to identical and then it's imported into the branch.
<jbicha> what would I need to do if I wanted to properly merge it?
<infinity> (But it's certainly not foolproof)
<infinity> jbicha: Merge to the branch, then upload from that, though I never do that either.
<jbicha> I tweaked the description and the version number so I don't know if it would catch that they're the same
<stgraber> jbicha: bzr merge into the branch, commit and push. That should mark the branch as merged (or we have some other bug on LP)
<infinity> Frankly, it's fundamentally broken if you can upload to something, but not commit or mangle MPs.
<jbicha> or I could ask darkxst to kill it I guess
<stgraber> anyway, pinging on IRC to have a TB member change the status is fine too, most people do that and it's the advantage of being effective immediately (so the entry disappears on the sponsoring list)
<stgraber> infinity: yes, the ACL or lack thereof has been annoying for a long time, mangling those MPs is pretty much restricted to the TB at the moment
<stgraber> (well, ~ubuntu-branches which is TB + James Westby + the package importer role account)
<stgraber> it'd make a lot more sense to have those use the upload ACLs instead, but I guess that needs quite a few changes to LP and it's never been high priority
<infinity> Any reason to not add, at least, core-dev to that group?
<infinity> (But yes, they should have finer-grained upload ACL mappings, but that's Real Work)
<infinity> core-dev seems sane, though.  They can upload to everything in Ubuntu, so why not also be able to mangle MPs for ubuntu branches?
<infinity> And that's as simple as adding them to the ubuntu branches group.
<stgraber> I'd be fine with adding coredev and think that'd make sense, though it may be best to ask one of the folks who setup that stuff to confirm that doesn't give some very weird rights as well
<jbicha> stgraber: thanks
<infinity> wgrant: Do you know, off-hand, if ~ubuntu-branches confers any weird/fancy privs that would be inappropriate to give to ~ubuntu-core-dev?
<infinity> james_w: ^
<infinity> jbicha: Accepted.
<jbicha> infinity: ooh that was fast :)
<stgraber> infinity: do you know if someone is supposed to be able to commit to the release pocket branch of a released series? I thought that wasn't possible but apparently I can, so that may be a difference between ~ubuntu-branches members vs non-members
<infinity> stgraber: I suspect anyone *can*, there's just no point.
<infinity> stgraber: And there's no real harm in letting people do so either, it's not like we build from bzr or anything, so it would just be a lame revision.
<Laney> Yeah, it denies the push for me
<infinity> Curious.
<stgraber> ok, so that's indeed a difference then
<infinity> A difference that's probably meaningless, as above.
<Laney> Maybe. Hopefully.
<infinity> Cause, really, who cares if someone pushes to a dead branch?
<stgraber> indeed
<infinity> Now, if we ever want to move to a build-from-VCS model, we need to get sane ACLs on all of this, but we're laughably nowhere near such a utopia.
<stgraber> outside of that, ~ubuntu-branches members can obviously do stupid things like removing the branches, or changing which is the master branch, both tend to confuse the importer a fair bit, but are sometimes necessary and difficult enough to do (requires API) that it's unlikely to happen by accident
<infinity> (Though, actually, to be fair, I could write the VCS->dpkg-souce->upload bot over a weekend... I just kinda don't want to force such a shift with things in such a shambles on that side of the world, while source uploads Just Work)
<Laney> Can they do non-stupid things like fixing the importer?
<mzaza> penguin42: What exactly could I start working on in Qt, because Qt is big project and bigger than my level I think...
<Laney> 'cause that would be good
<stgraber> so yeah, until wgrant or james_w can think of something else, it should be safe to add coredev to the team
<infinity> Laney: If they can remove branches and change the master, then they could also fix a stuck/confused importer, since I think that's the general fix...
<stgraber> Laney: kinda, we can run the scripts on our own machines, do the import and push the new one on top of the other. I've been doing that for a few stuck branches.
<penguin42> mzaza: I don't know the Qt guys well, but try looking at their own mailing list - they'll have bugs and features they want to add
<stgraber> Laney: though the real way of fixing the importer needs ssh access to a box in the DC and mangling its database to unblacklist the branch.
<Laney> Yeah, wouldn't know anything about what's good to do there
<penguin42> mzaza: Similarly KDE, and I think Unity
<Laney> but "try this thing, it might work but won't make it worse" could be useful in the right hands
<infinity> stgraber: I guess if we ever decided to swap to build-from-VCS, that would fix all the importer bugs in one go.
<mzaza> penguin42: Yes, It's just do you think I can get enrolled in such projects. When I looked at the KDE's source code I felt lost :D
<stgraber> infinity: sure, it'd guarantee we'd be in sync, you just wouldn't be able to "upload" instead of having an out-of-sync branch post-upload :)
<infinity> stgraber: Well, there would be no "uploading", just pushing a tag.
<infinity> Or a pair of tags, in the case of a new upstream.
<stgraber> infinity: sure, though what usually confuses the importer are some of the weird merges done in the bzr branch, those would likely make the source package building part of the process explode in a similar way
<penguin42> mzaza: Pick a project that you use, then go and ask at that project - they often have starter projects; e.g. small bugs and things
<stgraber> infinity: so just moving the problem, though we'd indeed safe ourselves from all the problems related to .dsc imports for Ubuntu (we'd still need that for Debian)
<infinity> stgraber: The source package part is just "build orig from upstream tag" then "build source package from Ubuntu tag".  That can't go "wrong" unless what you pushed is unbuildable.  In which case, you push a new version.
<jbicha> I wouldn't mind so much if the UDD branches were debian/ only
<infinity> stgraber: For Debian sync --force, if people aren't attached to obsolete Ubuntu history, you just wipe the packaging branch and import a fresh copy with no history.
<infinity> jbicha: The way I did this in git with maemo, the packaging branches were essentiall just debian, in that they were a topic branch on top of an upstream import.
<infinity> jbicha: So, you had the full source there, but only the debian bits were represented in the branch, in reality.
<infinity> Import a new upstream, tag foo_1.2.3, switch to packaging branch, fix, fix, test, tag foo_1.2.3-1, push, rejoice.
<jbicha> I meant like the ~ubuntu-desktop branches with bzr-builddeb merge mode or something similar
<infinity> jbicha: But, in a 'build-from-VCS' world, you need to get your orig from somewhere, it can't just magically appear.
<infinity> jbicha: So, you need that upstream branch.
<infinity> And, if we're being anal about it, we also need pristine-tar.
<jbicha> I don't trust 'bzr mu' to do the right things in a full-source branch as I've had problems before
<stgraber> infinity: hmm, yeah, I guess building the source package should always work unless you messed the branch to the point of having it unreadable (but then you should just re-create it). The usual problems are imports and merges so we'd just hit those points for the Debian UDD branches (on the importer), during merges from Debian (on the developer's machine) and for syncs (unless we wipe the history).
<infinity> stgraber: To my mind, wiping history on syncs would be an acceptable compromise, I suspect people who hate losing history EVAR would disagree.
<infinity> stgraber: But we already lose history on syncs in the source-package-centric world.  We drop all changelog deltas, etc.  So, it's analogous.
<infinity> But you could also just do a shallow force overwrite on syncs.
<stgraber> well, I suppose some will argue that anything we can pull from the archive or LP (through pull-lp-source) should also be available as tag in the branch, I don't really care much myself though
<infinity> Preserve all history up until then, wipe the top revision clean, replace with Debian's contents, have an icky huge diff that might be nonsensical.
<infinity> The key being that if the top revision matches bit-for-bit with your sync, it doesn't really matter if you preserved history or not.
<infinity> You just can't be silly and try to MERGE a sync in.
<infinity> (ie: a sync -f would assume you want the tip to match Debian, even if you had staged commits that post-date the last tag)
<infinity> I hate when I start talking about this and think I should start implementing it.  Cause I pretty much refuse to implement it on top of bzr, and I don't want to have the cost-analysis-of-switching-to-git argument this week.
<stgraber> ;)
<infinity> Ultimately, I think build-from-VCS (but publish source packages to the archive, on CDs, and to buildds) is the right answer.  And not actually a *ton* of work.  It's the bzr-vs-git argument that's the soul-draining bit.
<infinity> And, coming from someone who likes working with source packages, and never uses UDD, that's saying something. :P
<stgraber> well, that's because you currently can't trust UDD, doing things with UDD, then producing a debdiff with what's in the archive because you don't trust it isn't terribly efficient :)
<infinity> stgraber: To be honest, I still used that workflow even in a build-from-VCS that I trusted.
<infinity> stgraber: I want to know what the bot's going to do to my tag, so I'd still dpkg-buildpakage and debdiff before I pushed the tag.
<infinity> (Which also saves on angry emails when the build fails)
<infinity> But it's nice when the lack of trust is only in myself, and not also in my tools.
<stgraber> right, build-from-VCS is no excuse to stop test building locally so yeah, doing an extra debdiff on top of that isn't really time consuming
<infinity> bzr doesn't do signed tags, does it?
<infinity> That's another argument for git in this sort of workflow, cause the tag signature is what you check on "upload".
<stgraber> infinity: that sounds right, so in the bzr world we'd have to required a signed commit containing some indication that we want a build
<infinity> Well, my neighbor just invited me over for beer, I'm saved from having to think about this any more this afternoon.
<stgraber> yeah, doesn't sound like the kind of thing you should be spending your Sunday afternoon thinking about. Have fun!
<infinity> Laney: What have you got against girraffes anyway?
<Laney> They're so tall. It's creepy.
<jbicha> "We collect hundreds of thousands of error reports daily from millions of machines." really? https://errors.ubuntu.com/
#ubuntu-devel 2014-06-02
<Noskcaj> To fix https://launchpadlibrarian.net/176326322/buildlog_ubuntu-utopic-ppc64el.libsigc%2B%2B-2.0_2.2.11-3_FAILEDTOBUILD.txt.gz should i just mark that symbol as not of ppc64el?
<Logan_> infinity: are you still around?
<Noskcaj> cjwatson, Are we able to sync ntfs-3g? The only remaining diff is to keep compatibility with ancient versions of ubuntu. How long till they are too old?
<pitti> Good morning
<ion> that
<infinity> Logan_: Am now, ish..
<infinity> Noskcaj: Understanding why a symbol went away is usually a good idea before blindly applying the change.
<infinity> Noskcaj: Investigated, fixed, and bug filed in Debian.  Thanks for the heads-up.
<pitti> xnox: ah, we forgot to look into bug 1316804 last week; I take it you still get this?
<ubottu> bug 1316804 in systemd (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Confirmed] https://launchpad.net/bugs/1316804
<xnox> pitti: yeap.
<Noskcaj> infinity, ok, thanks.
<Noskcaj> I'll just stay away from stuff like that unless i learn C
<pitti> xnox: good morning
<brendand> should 'sudo click chroot -a armhf -f ubuntu-sdk-13.10 begin-session saucy' work?
<pitti> xnox: so which tasks do we still need to fix?
<brendand> provided i create'd with the same options previously
<xnox> brendand: looks correct.
<xnox> pitti: i have comment from steve about giving "task" jobs a free pass in startpar.
<brendand> xnox, http://paste.ubuntu.com/7571426/
<xnox> brendand: (a) that doesn't look like complete paste (b) E: 10mount: mount: unknown filesystem type 'overlayfs' -> what system are you running this on?
<brendand> xnox, utopic
<pitti> xnox: ok; I'm not quite sure how to interpret slangasek's reply, but if that meant "ok", fine for me
<xnox> brendand: also saucy is end-of-life, not much use building using it.
<brendand> xnox, well there's a warning before that about the location field being depreccated but that's in relation to a different chroot
<pitti> xnox: note that this also needs to be applied to the split-out startpar source in utopic-proposed
<xnox> pitti: he wants me to rework the patch. such that we don't wait for tasks to start, but do wait for tasks to stop.
<pitti> ah
<brendand> xnox, ok fair enough. i'm having a different problem with 14.04 though
<pitti> xnox: so we keep tasks as they are (your list of 6 affected packages)
<brendand> xnox, it won't let me create it due to it appears some existing file
<pitti> xnox: and I should revert the udev-finish one
<xnox> pitti: yeah, we still want to fix those (with or without fixing startpar as well)
<brendand> xnox, but it won't let me destroy it either because it "doesn't exist'
<brendand> FileExistsError: [Errno 17] File exists: '/var/lib/schroot/chroots/click-ubuntu-sdk-14.04-armhf'
<xnox> pitti: i gathered we want to keep changes we did, e.g. to udev-finish.
<brendand> should i just delete that?
<xnox> brendand: yeah.
<brendand> xnox, so i still get the same error with trusty
<xnox> brendand: can paste all messages it prints?
<xnox> brendand: it did say before that overlayfs not supported, which sounds like either the kernel is borked or non-ubuntu kernel is used.
<brendand> xnox, http://paste.ubuntu.com/7571612/
<brendand> xnox, it's an rc kernel
<cjwatson> Noskcaj: No, the problem with ntfs-3g is that there's no way to upgrade the relevant bit of configuration.  I'll merge it; please leave it alone.
<BluesKaj> 'Morning folks
<seb128> Noskcaj, can you please test those GNOME components under Unity before filing update requests? Some of those you filed just don't work (like they don't even get decorations)
<ev> can someone reject whoopsie 0.2.27 from trusty? I'm a muppet. Should've sent it to utopic
<pitti> ev: done
<ev> yay, thanks
<pitti> ev: (FAOD, you can re-use the version number for utopic)
<ev> yup, already done :)
<pitti> ev: did that build for you? the buildds say otherwise (syntax error)
<ev> yeah, looking into it
<ev> fixed
<pitti> hm, what is wrong with libsmbclient? seems uninstallable in -proposed
<seb128> pitti, https://launchpad.net/ubuntu/+source/samba/2:4.1.6+dfsg-1ubuntu4
<seb128> pitti, that ftbfs as well
<pitti> Laney, Riddell: ^ that's causing the dbus-test-runner / ubiquity failures, in case you wonder
<pitti> seb128: yes, but that shouldn't affect installability?
<seb128> indeed not
<pitti> oh
<pitti>  samba-libs : Depends: libldb1 (< 1:1.1.17~) but 1:1.1.17-1 is to be installed
<pitti> so it indeed seems to need a rebuild, and that "missing krb5.h" bug prevents that
<pitti> Debian has:
<pitti> * Add build-dep on libkrb5-dev, no longer pulled in by libcups2-dev.
<pitti> * Build-depend on heimdal-dev instead of libkrb5-dev.
<pitti> but our package already b-deps on heimdal-multidev
<xnox> brendand: i see what you mean now. it appears that utopic kernel might be causing above issues.
<brendand> xnox, i have 3.13
<pitti> slangasek, zul: does either of you plan to merge samba?
<pitti> slangasek, zul: current version is FTBFS and uninstallable
<Laney> bdmurray: will you be at DMB today?
<Laney> ev: Looks like the source package wasn't clean
 * Laney goes away
<mapreri> pitti: isn't running autopkgtest in pbuilder as easy as https://gitlab.com/mapreri/settings/blob/master/pbuilder/hooks/B10autopkgtests ? (The only "issue" I saw so far is that in this way you run the tests always as root) (wrt #750137 you reply 50 minutes ago)
<zul> pitti:  yeah i can do it
<pitti> mapreri: yes indeed, it shuold be easy; that script looks good (some refinements perhaps, like for the grep, but that's the general idea)
<pitti> zul: great, thanks
<mapreri> pitti: what's up with the grep? do you think would be far better checking for '^XS-Testsuite: autopkgtest$' ?
<pitti> mapreri: something like grep -q 'Testsuite.*autopkgtest' debian/control
<pitti> mapreri: i. e. -q to avoid printing the result (but nitpicks)
<pitti> mapreri: I suppose an sbuild hook would look fairly similarly, I'm just not sure how to enable/disable it per run
<pitti> I wouldn't want *all* pbuilder/sbuild runs to run tests
<mapreri> pitti: a way could be asking the user if they want to (echo/read/if/then) but I don't want to be bothered during the build phase :) another way could be changing the x flag of the script but I prefer let pbuilder run some minutes longer than this...
<pitti> mapreri: right; I mean if we ship such a hook by default, it needs an on/off switch; for personal hooks that's fine of course
<ScottK> With pbuilder hooks they get used or not based on what's in --hookdir, so it's easy enough to control.
<mapreri> pitti: looks like environment variables reaches hooks, so you can use a variable as a switch.
<mdeslaur> xnox: what's the status of the gnutls migration? are we planning on demoting gnutls26 before u releases?
<cjwatson> xnox: Are you likely to be able to fix libavg for libav 10 soon?
<mlankhorst> cjwatson: hm you seem to be famous ;-) with your name on the airplane evacuation news article
<cjwatson> Yeah, I noticed :)
<cjwatson> 15 minutes of fame and all that
<pitti> where do we put our source/binary click apps for download? I'm interested in looking at a few while I read the click docs, to see how to autopkgtestify them
<pitti> cjwatson: ^ do you know?
<beuno> pitti, I don't think there's a good place to download them from the store at the moment. They get built from source by an uploader and pushed directly to the store.
<beuno> downloads are authenticated, so until we release the web ui for the store, there's no good place to download random click apps
<pitti> beuno: ah, but we certainly keep "our" (Canonical's) click apps somewhere in LP/bzr?
<beuno> pitti, not the binaries, surely
<pitti> beuno: I'm happy with downloading the source, I should be able to build the .click(s) myself
 * beuno nods
<mdeslaur> pitti: look here, on the right: https://launchpad.net/ubuntu-phone-coreapps/
<mdeslaur> pitti: the links are all there
<pitti> mdeslaur: perfect! that's what I was looking for, thanks!
<mdeslaur> yw
<pitti> cjwatson: unping
<pitti> beuno: thanks
<cjwatson> pitti: ok :)
<mardy> cjwatson: hi! Can one have multiple versions of the same click app installed at the same time?
<cjwatson> mardy: yes, although you should only expect one to be active and older ones may be GCed
<cjwatson> mardy: (for any given user, that is)
<pitti> so I'm still a bit puzzled by this: https://click.readthedocs.org doesn't talk about how to build packages, and man click only briefly explains "click build"
<cjwatson> mardy: so I guess "sort of" is a better answer
<mardy> cjwatson: how do I find which is the active one?
<cjwatson> mardy: clicklist
<cjwatson> er click list
<cjwatson> pitti: click build is the only entry point provided by click itself; there's intentionally no source package format
<pitti> I tried it on lp:ubuntu-calculator-app; "click build ubuntu-calculator-app/" complains about a missing manifest.json, and indeed there's only a click/manifest.json.in
<cjwatson> pitti: so building is project-specific
<pitti> so I suppose there is some pre-build magic to be run somehow
<cjwatson> probably cmake for most of the core apps
<pitti> aah; so perhaps I should try dpkg-buildpackage first (which will invoke cmake etc. in the right way, then click build
<mardy> cjwatson: just to give a bit of background: Online Accounts requires apps to ship an .application file; the hoot pattern copies them in ${home}/.local/share/online-accounts-hooks/${id}.application, and then we have an "Exec" line to process these files and copy them (with slight modifications) into ~/.local/share/accounts/applications/
<mardy> s/hoot/hook/ :-)
<cjwatson> you only get one version of any given package as far as hooks are concerned
<cjwatson> that's very much intentional
<cjwatson> well, user-level hooks anyway, which yours is
<pitti> hm, no, that got me .debs, but didn't build click/manifest.json
<cjwatson> system-level hooks can have multiple versions since we expect multiple users to possibly be at different versions
<mardy> cjwatson: yes. Cool, so it means that click removes the uninstalled/inactive files from ${home}/.local/share/online-accounts-hooks/${id}.application?
<cjwatson> right
<cjwatson> the hook will only see whatever is appropriate/current
<cjwatson> including (nowadays) not seeing any packages that don't have their framework dependencies satisfied
<mardy> cjwatson: excellent!
<cjwatson> hooks should just make sure to sync up completely with the current state of the symlink farm each time they're run
<cjwatson> a good general approach for that seems to be to make their generated files have timestamps matching those of the symlink given them by click, and then regenerate on any symlink mismatch
<cjwatson> on any timestamp mismatch, I mean
<cjwatson> and of course handle additions/removals
<pitti> dpm: hey David! I'm trying to build a click package from an ubuntu app, like lp:ubuntu-calculator-app; how do I get click/manifest.json generated, so that I can run "click build"?
<ogra_> pitti, is there any known issue with dbus-test-runner atm ? https://launchpadlibrarian.net/176785648/buildlog_ubuntu-utopic-i386.unity8_7.87%2B14.10.20140530.1-0ubuntu2_FAILEDTOBUILD.txt.gz i cant get unity8 to build
<pitti> ogra_: yes, same for ubiquity; libsmbclient is uninstallable (and FTBFS)
<pitti> ogra_: I asked earlier about merging, zul said he'll do it
<dpm> hi pitti, I generally use Qt Creator to build them, but you can also use click-buddy to create the .click for calculator
<ogra_> pitti, ugh ... that upload was an emergency fix ... pretty urgent to get it somehow through to make landing possible again for touch ... do you know a way around ?
<pitti> ogra_: I suppose the release team can ignore the test
<cjwatson> temporarily disable proposed in the archive dependencies for the relevant silo ppa?
<cjwatson> we can't ignore a build failure :)
<pitti> or that
<ogra_> pitti, FTBFS :)
<dpm> pitti, calculator is arch-independent, so 'click-buddy --dir $PATH_TO_CALC_SRC' should do
<cjwatson> I'm assuming this is only broken in -proposed
<pitti> dbus-test-runner itself (probably) builds, it's samba which is FTBFS and uninstallable
<pitti> cjwatson: samba is only uninstallable in -proposed, yes (ldb sync), but FTBFS in utopic release
<ogra_> cjwatson, emergency fix ... silos are broken as well :) ... this was a direct upload
<ogra_> its "murphys monday" today :)
<ogra_> what can fail fails
<cjwatson> oh, err, well you can't tell the archive to not build -proposed against -proposed
<pitti> ogra_: err .. there is no dbus-test-runner in -proposed
<pitti> oh, in the silo, sorry
<ogra_> there are no silos atm
<ogra_> jenkins had issues ...
<ogra_> not sure how far the infra is fixed yet
<cjwatson> could upload a new version to a suitably configured PPA and copy back, but it might actually be easier and less risky to fix libsmbclient
<pitti> dpm: ah, I'd really like to stick to CLI tools; for doing something like "build this bzr branch into a click and run its tests" we can't use interactive tools :)
<pitti> dpm: where can I find click buddy?
<seb128> hum
<seb128> ubuntu-desktop-next daily build failed with
<seb128> "Using ISOLINUX boot-disks image on CD1
<seb128> W: Unable to read /srv/cdimage.ubuntu.com/scratch/ubuntu-desktop-next/utopic/daily-live/apt/utopic-i386/apt/preferences.d/ - DirectoryExists (2: No such file or directory)
<seb128> cp: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu-desktop-next/utopic/daily-live/tmp/utopic-i386/CD1/../syslinux/usr/lib/syslinux/isolinux.bin': No such file or directory"
<seb128> does anyone know what's the issue/where to look?
<pitti> samba> it seems our pacakge uses heimdal-multidev while Debian's uses heimdal-dev; TBH I have no idea about the details about that, hence I pinged slangasek first instead of uploading a quickfix I don't fully understand
<dpm> pitti, it's in the phablet-tools package in universe
<pitti> dpm: ah, how odd :)
<pitti> dpm: splendid, thanks!
<dpm> pitti, cool, let me know if I can help with anything else. For other core apps such as reminders, file manager and terminal, you'll just need to specify the arch parameter, as they contain C++ QML plugins that are shipped with the .clicks
<zul> pitti:  im not sure about it either..so if you want to upload a quick fix that would be fine for me and ill merge samba when i get a chance (im on a cricitical path here for a project)
<cjwatson> seb128: oh, that'll probably be syslinux 6, will sort it out
<seb128> cjwatson, thanks
<cjwatson> surprised I don't have lots of mail about that
<seb128> cjwatson, there is no iso since thursday but I didn't get build failure emails either...
<pitti> dpm: so in general: apt-get install phablet-tools, bzr branch lp:whatever, apt-get install <build dependencies of that branch>, click-buddy --dir checkout-dir/ ?
<dpm> pitti, essentially, yes, with a couple of caveats:
<dpm> - You'll probably want to specify the --framework parameter, as the click-buddy help says that the default is still ubuntu-sdk-13-10
<pitti> dpm: oh, why doesn't it read that from click/manifest.json.in? That says "framework": "ubuntu-sdk-14.04-qml-dev1",
<dpm> - For file manager, terminal, reminders, you'll need to specify --arch
<dpm> pitti, ah, good point, it probably does
<dpm> so the help from click-buddy probably needs to clarify that
<pitti> dpm: an automated test system could probably use --arch $(dpkg --print-architecture) to test on the native arch?
<pitti> WARNING:root:Ignoring missing framework "ubuntu-sdk-14.04-qml-dev1"
<pitti> dpm: oh, I got that from click-buddy output after package build
<pitti> dpm: which at least confirms that it's trying to use the 14.04 one from the manifest.in :)
<pitti> the warning updates when I change the .in file
<dpm> ok, cool. Strange that that framework is missing. lool, any ideas? ^
<pitti> dpm: well, I'm not currently using a click chroot; I figure I ought to
<cjwatson> dpm,lool,pitti: it's a cosmetic click bug that it issues that warning on build
<smoser> anyone seen this: http://paste.ubuntu.com/7573205/
<cjwatson> you aren't required to have the framework present at build time
<pitti> cjwatson: ah, thanks
<dpm> ok, thanks cjwatson
<pitti> dpm: ok, I think I know enough for now; thanks for your help!
<dpm> ok, cool!
<smoser> pitti, you touched sysvinit since i last upgraded, have you seen that failure above?
<cjwatson> pitti,dpm: you need to pass -f to click-buddy if the package contains native code; IMO it's a bug that it doesn't pick that up from the package
<cjwatson> it's indeed not required for architecture-independent packages
<pitti> smoser: not that particular one, although it looks fairly similar to the fix from https://launchpad.net/ubuntu/+source/systemd/204-10ubuntu7; which udev version do you have?
<smoser> 204-10ubuntu8
<pitti> that seems fine
<cjwatson> seb128: should be fixed now, and at least worked for Ubuntu; I've triggered a -desktop-next rebuild
<pitti> smoser: can you pastebin the output of "sudo /usr/lib/insserv/insserv -vn"?
<pitti> smoser: -vns even
<smoser> http://paste.ubuntu.com/7573248/
<pitti> smoser: uh, no error there?
<seb128> cjwatson, thanks!
<smoser> note the udev version is the new udev version. as upgrade failed. (iU state)
<pitti> smoser: ah, so you still have the previous udev init.d file installed?
<smoser> pitti, that returns zero
<smoser> pitti, well.. http://paste.ubuntu.com/7573255/
<pitti> smoser: so you might still be in that "my system fails" trap situation from last week :/ we had to apt-get download libudev1 udev and sudo dpkg -i those manually
<pitti> i. e. if you upgraded when we had a broken udev init.d script and switched to startpar (doesn't affect trusty -> utopic, just utopic last week -> utopic today)
<smoser> k. that seems to get me out of it. thanks pitt. will everyone hit that ?
<smoser> ah. ok.
<pitti> smoser: most people who upgraded every day last week, I'm afraid
<pitti> smoser: good, thanks
<pitti> smoser: I just did a trusty -> current utopic upgrade in a schroot, and that went fine, FTR
<smoser> pitti, thanks.
<seb128> ev, whoopsie build seems still unhappy, I guess you noticed?
<ev> yeah, trying to deal with it in the background
<ev> I'll start throwing it at a PPA to reduce the noise
<seb128> k
<seb128> ev, seems like you are shipping some amd64 .so in the tarball,
<seb128> ev, src/test/test_logging.test.o
<ev> hm
<seb128> .so -> .o
<ev> yeah, so I am
<ev> fixing
<seb128> great
<seb128> Riddell, apachelogger: is it normal that non kubuntu systems have pam errors about pam_kwallet.so?
<Riddell> mm, I'm not sure, I don't run a non-kubuntu system :)
<seb128> like "PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory"
<Riddell> seb128: where's that?
<seb128> Riddell, in /var/log/auth.log on utopic isos (tested ubuntu-desktop-next and now xubuntu which has the same one)
<seb128> well, I first noticed because ubuntu-desktop-next fails to log in
<Riddell> seb128: is it listed in /etc/pam.d/lightdm ?
<apachelogger> seb128: as normal as it is for pam_gnome_keyring.so anyway  ;)
<seb128> apachelogger, that throws warnings as well?
<seb128> Riddell, yes, but not installed
<apachelogger> when it's not installed, sure
<seb128> hum, k
<seb128> apachelogger, "sure" like it was obvious
<seb128> if those are optional they could do nicer warnings (or none)
<apachelogger> yeah, not sure why pam insist on warning about missing optionals
<apachelogger> then again, I guess the warning would help with debugging why a pam modules is not working
<seb128> Riddell, apachelogger: the issue is probably something else then, thanks for the reply, I keep debugging
<cjwatson> zul,pitti: I'm attempting a local quick fix for samba
<zul> cjwatson: ack
<cjwatson> slangasek: ^-
<alexbligh1> If I have package A and package B, then modify package A to package A' so that it does the work of Package B (and B should no longer be installed when I upgrade A), then I think I should mark A as Provides: B, and Conflicts: B, right? Do I also need Replaces: B? IE all 3?
<cjwatson> that sounds like a good case for all three
<cjwatson> Conflicts+Replaces => "that other package should go away"
<cjwatson> Provides is gold-plating so that dependencies on package B still work; not always necessary
<alexbligh1> cjwatson, thanks
<seb128> cjwatson, ubuntu-desktop-next built, but it boots on an empty screen with a grey square in the bottom left corner instead of the list of languages
<rbasak> alexbligh1: https://wiki.debian.org/PackageTransition is a handy reference
 * seb128 downloads ubuntu daily to see if that has the same issue
<rbasak> (for the future)
<alexbligh1> rbasak, handy, thx
<alexbligh1> rbasak, that says "Breaks/Replaces/Provides" for my scenario, not "Conflicts/Replaces/Provides", but I think I need "Conflicts/Replaces/Provides" if A and B have the same file in.
<rbasak> alexbligh1: I think Breaks would suffice, rather than Conflicts, in that case.
<alexbligh1> rbasak, it's a bit confusing. I was going from https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts 7.4, "in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages) or that must prevent both packages from being unpacked at the same time, not just configured."
<rbasak> alexbligh1: Debian policy 7.4: Normally, Breaks should be used instead of Conflicts since Conflicts imposes a stronger restriction on the ordering of package installation or upgrade and can make it more difficult for the package manager to find a correct solution to an upgrade or installation problem. Breaks should be used ...when moving a file from one package to another
<alexbligh1> rbasak, well at least we are reading the same text then!
<alexbligh1> I don't want them both unpacked at once (indeed I think having a file moved from B to A is sufficient reason for that)
<alexbligh1> though the DPM doesn't agree with me on that it seems. For reasons I don't quite understand.
<pitti> dpm: where does click buddy build the source? I see no built files in the original tree, so I still can't see a generated manifest.json
<dpm> pitti, it runs cmake and IIRC it builds the files outside of the source tree. You can use the --no-clean argument to see the results of the build. It will point you to a directory in /tmp where it does the build IIRC
<pitti> dpm: ah, thanks
<pitti> dpm: do you see click-buddy as something which we can/should use in production testing, or does it change its behaviour often? (for once, it has a gazillion dependencies which are unnecessary for click-buddy and only needed for adb/phone bits)
<pitti> this seems to me like the kind of tool which should be in "click" itself (perhaps with a more formal name) or in a separate package, it is very unrelated to the other bits in phablet-tools
<pitti> ah, so this really just uses "cmake", "make install", and "click build"
<pitti> I suppose that's easier to call directly than relying on click-buddy and parsing its output
<dpm> pitti, I think probably cjwatson and sergiusens can probably better answer the question. I generally don't use it, as I tend to dogfood the graphical tools to make sure I use the same tools as app devs, but click-buddy is quite convenient when I need to use it and provision click apps to the phone quickly. However, it is indeed another layer on top of the click tools, so I agree that either having its functionality in click or using click for production
<dpm>  testing might make more sense
<xnox> cjwatson: libavg fix for libav 10 -> no, not soon. Best to demote to -proposed (similar to how it is/was removed from testing in debian)
<xnox> mdeslaur: it's moving slowing, i'm pushing for it on debian side though. Will be done before utopic FF.
<xnox> mdeslaur: if not completed, demoted to universe the least.
<xnox> pitti: "cmake -DCLICK_MODE=on; make" is the typical way to build ubuntu core-apps into a click
<pitti> xnox: right, I used something like that now (with extra -DINSTALL_TESTS=off -DBZR_REVNO=...)
<pitti> all working now
<pitti> with just click, ubuntu-sdk-libs, and the build deps
<xnox> pitti: yeap, looks about right way to do it.
<pitti> hah, and there I can run ubuntu-calculator-app with qmlscene from my install --root /tmp/c com.ubuntu.calculator_1.3.12_all.click
<pitti> so I think I have all the building blocks now
<cjwatson> seb128: right, will try to get a chance to look soon ...
<pitti> cjwatson: ah, thanks for the samba fix; it sounded like heimdal-dev and heimdal-multidev would be alternatives, not being used together
<pitti> (and meh @ i386 FTBFS)
<pitti> anyway, gotta run, time for Taekwondo; good evening everyone!
<seb128> cjwatson, thanks! (the iso boots, so the menu not showing is not blocking testing from our side, so no worry if it takes some days to resolve it)
<seb128> pitti, enjoy!
<cjwatson> pitti: mm, I saw that locally but had hoped it was cosmic rays :-/
<cjwatson> just on 32-bit little-endian architectures, apparently; wonder if that's relevant
<mdeslaur> xnox: cool, thanks
<slangasek> xnox, pitti: right; I'm ok with the general thrust of that MP, but didn't mark it as an approval because of the unneccessary race on shutdown
<slangasek> pitti: samba> no plans to merge that, no
<xnox> slangasek: i'm trying to think of a case of a hanging/long-running task with no "stop on" which would cause a startpar hang on shutdown, but can't think of any, as all upstart task should well be task that complete.
<xnox> *tasks
<slangasek> xnox: it could be a task that runs only on shutdown?
<infinity> cjwatson: Oh.  Haven't dug yet, but that xsltproc sigbus could be faketime, not xsltproc.
<mhall119> hello everyone, I would like to get somebody to provide a session on how to get a new package into Ubuntu's archives, both directly and via Debian, we've had a request for that on Google+
<infinity> cjwatson: debian/bin/xsltproc is a wrapper that wraps the real xsltproc in faketime.
<infinity> Though, maybe not.
<mhall119> slangasek: mdeslaur: please register for uos-1406 in summit so I can add you as track leads
<mhall119> http://summit.ubuntu.com/uos-1406/registration/
<mdeslaur> mhall119: done
<slangasek> mhall119: done
<mhall119> thanks guys
<cjwatson> infinity: I checked in strace and the sigbus is from xsltproc proper
#ubuntu-devel 2014-06-03
<mwhudson> hey uh, do we make an armhf image that contains a kernel that can work on midway?
<infinity> mwhudson: Yes.
<infinity> mwhudson: If by "image" you mean "d-i netboot images".
<infinity> mwhudson: http://ports.ubuntu.com/ubuntu-ports/dists/trusty/main/installer-armhf/current/images/generic-lpae/netboot/
<mwhudson> infinity: yeah, i think i was being confused
<mwhudson> have i mentioned my deep and abiding love for uboot recently
<infinity> mwhudson: I sense sarcasm.
<mwhudson> very perceptive of you
<mwhudson> argh!
<mwhudson> midway just has broken uEnv.txt support
<mwhudson> ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt...
<mwhudson> that explains the Unknown command 'Executing' - try 'help'
<mwhudson>  message
<infinity> mwhudson: Hrm, I've never had any issues on the midways I've played with.
<infinity> mwhudson: Maybe I don't use uEnv?  I dunno.
<mwhudson> probably not
<mwhudson> maybe this one has out of date firmware, i dunno
<mwhudson> just means i need to re-remember how to use boot.scr
<nathaneltitane> hello amigos
<nathaneltitane> i've set up a build dir to generate my first deb package (from source), after running  dpkg-buildpackage -rfakeroot i get an error message. it complains that the Package field is missing in the control file
<nathaneltitane> any idea?
<infinity> slangasek, xnox: heads up, lennart plans to remove udev's netlink interface, effectively breaking udev on all !systemd without people fixing things: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
<lifeless> yay?
<pitti> Good morning
<dholbach> good morning
<ogra_> pitti, thanks for the suggestion !! ... do you know if we have a tool for editing thises options or should i "just sed from postinst" ?
<pitti> ogra_: no, we can't change it in a package, it's a conffile
<pitti> so at most during an image build
<ogra_> thats what i feared
<pitti> certainly not ideal
<pitti> ogra_: i. e. I was mostly suggesting that as a quick fix if you want to unbreak images, not as a long-term solution
<pitti> should have mentioned that in the mail, sorry
<ogra_> well, the only "proper" longter solution is to create a single package for a single file i think
<pitti> ogra_: perhaps an even better thing to do would be to change /etc/X11/Xsession.d/75dbus_dbus-launch to not run $DBUSLAUNCH if [ -n "$DBUS_SESSION_BUS_ADDRESS" ]
<ogra_> which is ugly as well but less intrusive
<pitti> ogra_: i. e. if there already is a session bus, started from upstart or whatever
<ogra_> well, this one seems to be actually get started by the first gdbus call
<pitti> ogra_: gdbus runs dbus-launch if there's no $DBUS_SESSION_BUS_ADDRESS, that seems like a separate issue
<pitti> ogra_: what is supposed to start "the" session bus on the phone?
<pitti> it obviously wasn't 75dbus_dbus-launch as we didn't install that until yesterday
<ogra_> pitti, no idea how it looks like in the new split greeter world ... usually we have an upstart job starting it
<ogra_> but i dont think lightdm processes a full session startup in upstart
<ogra_> at least not in our setup
<ogra_> (in our new setup)
<pitti> ogra_: so I think the first thing to do is to get some agreement what starts the session bus -- lightdm, 75dbus_dbus-launch, 00upstart (through a session upstart job), or something else
<ogra_> mterry did a lot of complex things to make the lightdm dbus have access to the user dbuses it seems
<pitti> ogra_: aside from that, I think changing 75dbus_dbus-launch to not do anything if there already is a session bus is a sensible and safe thing to do
<ogra_> yeah
<ogra_> we definitely dont want to have two per session :) (two for lightdm, two for the phablet user)
<pitti> ogra_: yes, absolutely; two session buses will break $world
<ogra_> right
<pitti> if different processes use differetn addresses (otherwise it's just a waste)
<ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/ .... it happens pretty visible since image 59 :)
<ogra_> but as i said, mike does some trickery to get the buses talk to each other it seems
<ogra_> so that phone calls get through etc
<pitti> ogra_: can you easily test http://paste.ubuntu.com/7578684/ ?
<ogra_> will do ... i dont have my test device near ... but in 10min or so
<ogra_> pitti, doesnt seem to help
<pitti> you still get two buses?
<ogra_> root@ubuntu-phablet:~# ps aux|grep dbus |grep session|grep -v upstart|wc -l
<ogra_> 4
<pitti> ogra_: that means that 75dbus_dbus-launch comes first and the second one is started after that
<ogra_> which is weird
<ogra_> pitti, i see the same socket twice as well http://paste.ubuntu.com/7578759/
<pitti> ogra_: right, one for lightdm, one for phablet
<ogra_> look at the two phablet ones
<ogra_> they are identical and use the same address
<pitti> ogra_: yeah, I know, looks odd; can you grep for dbus-launch?
<ogra_> not there
<pitti> ogra_: was it there without the Xsession.d change?
<ogra_> yes
<pitti> if yes, that change at least helped a bit; if no, dbus-x11 wasn't the reason
<ogra_> and before split greeter we had exactly one dbus-daemon per session
<pitti> I have three in my desktop session, presumably it forks internally
<pitti> martin    1648  0.0  0.0  39240   324 ?        Ss   07:18   0:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
<pitti> martin    1660  0.0  0.0  41444  4008 ?        Ss   07:18   0:04 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-4jEVwkHdJv
<pitti> martin    1806  0.0  0.0  39504  3492 ?        S    07:18   0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
<ogra_> oh. ok
<pitti> ogra_: but not two with the same --address thing
<ogra_> right
<pitti> ogra_: on the phone we probably don't have the a11y bus, so we can ignore that
<ogra_> right
<pitti> 1660 is started by session upstart (lightdm -> init -> dbus-daemon (1660)
<pitti> 1648 isn't, not sure where that comes from, but the --print-address sounds like it's coming from dbus-launch
<ogra_> pitti, could you upload the dbus-x11 fix in any case ?
<pitti> ogra_: sure
<ogra_> (since i dont see dbus-launch it seems to have worked)
<pitti> ogra_: was that tracked as a bug, or just on u-phone@ so far?
<ogra_> just the ML
<pitti> ack, thanks
<pitti> ogra_: test-building now, will test on desktop before I upload
<pitti> (just to make double-suree)
<ogra_> ok
<pitti> I still wish we could avoid all teh Xsession.d/ legacy and shellery on the phone
<pitti> it's not even running X :)
<ogra_> we will at some point :)
<xnox> pitti: i did remove dbus-launch from ubuntu-touch images. it shouldn't be seeded on touch images at all...
<xnox> pitti: any clue as to why it was pulled back in?
<xnox> sorry, i mean dbus-x11
<pitti> xnox: no, I don't know why it came in there
<ogra_> xnox, split greeter uses gdbus ... which needs dbus-launch
<ogra_> xnox, but sadly also ships the Xsession.d script that fires up a second session bus
<pitti> no, gdbus doesn't *need* dbus-launch
<ogra_> well, *uses*
<ogra_> :)
<pitti> it really shouldn't
<pitti> our session should already have a bus
<pitti> if a process doesn't have $DBUS_SESSION_BUS_ADDRESS, that's a bug in passing the env variables or starting the bus too late
<ogra_> well, lightdm seems to spawn one thats not upstart driven
<ogra_> xnox, so its a new dependency of the new greeter session implementation
<pitti> so the dbus-x11 Xsession.d/ change is a cheap and harmless help for that, but it in no way address the actual bug
<ogra_> if it even is a bug
<xnox> ogra_: that dependency is black-listed from the seed =)
<ogra_> we verified yesterday that it fixed the AP issues
<xnox> ogra_: I guess we didn't enforce it.
<ogra_> xnox, talk to the greeter team ...
<xnox> ogra_: i'm talking to landing team / person in charge of the seed =)
<xnox> ogra_: dev teams will always try to use haskell & what not =)
<ogra_> xnox, split greeter is the base for a ton of other features, feel free to work with mterry on improving it (and file a bug) but we need to land this if any possible so others can move on with their dependant work
<xnox> ogra_: is there no featureflag to run split greeter in non-split mode?
<ogra_> not that i know of
<ogra_> and it is also pretty complicated ... making sure phone calls to the users get handled by the greeter, you can start apps in the user session from the locked greeter etc ... the feature set is huge and scary :)
<sil2100> ogra_: btw. do you remember who robru poked to ACK all the crazy packaging changes of the greeter landing?
<ogra_> xnox, if you like getting scared in the morning ... https://code.launchpad.net/~mterry/unity8/split/+merge/213149 (there are about ten other packages with changes but this is the core)
<ogra_> sil2100, no, probably me ... doesnt the train record that ? i know rob always puts my name into the lander field or some such when i ack something
<ogra_> (i have seen him putting it in a jenkins form)
<ogra_> xnox, my theory is that dropping dbus-launch would need a re-org of the unity8-greeter-wrapper script (so that the first gdbus --session call happens after upstart ran init --user for lightdm ...) but i wont touch that code with the author not around
<sil2100> ogra_: let's hope mterry will be around today
<ogra_> xnox, Saviq, pitti, sil2100 bug 1325882 ... i think thats our final solution
<ubottu> bug 1325882 in unity8 (Ubuntu) "unity8-greeter-wrapper needs a re-org to not use dbus-launch" [Undecided,New] https://launchpad.net/bugs/1325882
<ogra_> (but mterry needs to agree)
<pitti> ogra_: yes, sounds good to me (i. e. fix the startup ordering)
<Saviq> ogra_, yeah, I thought that's what was happening..
<ogra_> great :)
 * ogra_ likes agreement
<ogra_> i see dbus already hit proposed
 * ogra_ prepeares the accompanying unity8 upload
<pitti> ogra_: FWIW, you don't really need that dbus on a new image, it's mostly to make debugging less confusing
<pitti> and it'll be stuck in -proposed until I fix the tests for udisks2 in -proposed (which broke due to enabling logind session tracking)
<Saviq> ogra_, if I agree, do you still need mterry's agreement? shall I push an MP?
<ogra_> pitti, crap
<ogra_> Saviq, well, given the above comment from pitti it is unlikely that we can make our 12:00UTC deadline ... so yes, go ahead ... cant become worse, can it ?
<Saviq> ogra_, ;)
<ogra_> sil2100, keep a silo ready for Saviq ^^^;)
<pitti> ogra_: why do you need that fix urgently? (if so, release team can fast-track it)
<ogra_> pitti, we are in TRAINCON-0 mode ... which means nothing can land (except some select bits) until we have resolved the major issue ... if we cant fix it in a given timeframe we have to roll back the whole landing
<ogra_> the timeframe we have set ourselves for this one is 12:00 UTC ...
<ogra_> so that we can be sure we can drop TRAINCON-0 in any case tonight
<pitti> ogra_: ok, but I still don't understand how that dbus change actually fixes the bug, or why fixing the ordering in bug 1325882 would need that dbus fix
<ubottu> bug 1325882 in unity8 (Ubuntu) "unity8-greeter-wrapper needs a re-org to not use dbus-launch" [Undecided,New] https://launchpad.net/bugs/1325882
<ogra_> by either having a proper fix or by rolling back all packages that make up this landing
<ogra_> pitti, the re-ordering wont since we drop all deps on dbus-x11 with that
<ogra_> pitti, if we would keep dbus-x11 and *not* re-order we would need your fix though
<sil2100> o/
<ogra_> pitti, with Saviq offering to take the risk of the re-order we get around using dbus-x11 at all ... and make xnox happy too ;)
<pitti> ah, ok; it seems a bit curious that this dbus-x11 fix would actually fix things
<ogra_> well, the dbus-launch call for gdbus makes things currently work
<ogra_> s/for/from/
<pitti> hm, "work"
<ogra_> yeah
<pitti> it still means that this spawns another bus which no othe process wants..
<ogra_> well, "not fail" is probably better :)
<ogra_> no, it spawns *the* session dbus ... the upstart job wont fire if there is one allready
<ogra_> but that session dbus wont use the upstart defined options for the daemon etc
<pitti> urgh :) yes, then Houston we have a problem
<pitti> because no other processes will know about that one
<ogra_> right
<ogra_> well, the indicators do ... they dont start without dbus-launch available
<ogra_> (and other weird things happen)
<pitti> so we should not install dbus-x11 so that we actually see which processes try to call dbus-launch (and then LART them)
<pitti> DON'T *spank" START *spank* A NEW *spank* BUS! *spank*
<ogra_> right, thats what Saviq will now implement ...
<ogra_> in the hope that it works
<Saviq> ogra_, https://code.launchpad.net/~unity-team/unity8/resync-distro-split/+merge/221845 + https://code.launchpad.net/~unity-team/unity8/fix-split-dbus/+merge/221847
 * sil2100 keeps his fingers crossed
<ogra_> if not we'll have to roll back and leave it to mterry to come up with a proper solution
<ogra_> Saviq, both acked ... (with a comment on the second)
<Saviq> ogra_, yeah, added telepathy-ofono test plan to the landing
<Saviq> sil2100, line 36 is ready for you
<sil2100> Saviq: excellent! The reorder seems ok...
<sil2100> Let me assign
<sil2100> Saviq: silo 20 for you
<sil2100> Let's get it building and tested o/
<ogra_> ++
<Saviq> builds
<ogra_> and then get an image that fixes our world ;)
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc
<sil2100> ogra_, Saviq: let's hope that it does!
<Saviq> ogra_, hmm... so without dbus-x11 it's upstart that will start dbus, and indicators in greeter should then work again, 'cause the gdbus âÂ dbus-launch *before* upstart caused things to mess around?
<ogra_> it should
<Saviq> ok it's an easy thing to check on 61, /me tries
<ogra_> let me quickly try your change on my flo
<Saviq> but yeah, in any case, the fact that gdbus just launches dbus... nasty
<Saviq> ogra_, looks legit!
<ogra_> yay
 * ogra_ reboots with the change 
<pitti> well, it does that if tehre is no $DBUS_SESSION_BUS_ADDRESS -- not having that is the actual bug
<ogra_> Saviq, no indicators for me ... are you sure you removed dbus-x11 ?
<ogra_> (i purged it)
<Saviq> ogra_, I just have 61, so no dbus-x11, never installed it
<ogra_> hm
<Saviq> oh wait
<ogra_> let me reflash then :/
<Saviq> ogra_, no, I have it here
<ogra_> aha
<Saviq> somehow
<ogra_> so that doesnt really fix it
<rbasak> mitya57: for https://code.launchpad.net/~chris-good/ubuntu/trusty/netkit-rwall/fix-for-1277981/+merge/216563, it looks like the source package isn't version 3.0, so how would you expect a dep3 patch in that case? I don't see any patch system in use.
<Saviq> :|
<rbasak> I was looking at https://bugs.launchpad.net/ubuntu/+source/netkit-rwall/+bug/1277981 but just realised it's the same bug.
<ubottu> Launchpad bug 1277981 in netkit-rwall (Ubuntu Precise) "rwall adds \377 bytes to short messages" [Undecided,New]
<ogra_> Saviq, trying something ...
<Saviq> ogra_, so yeah, no dice here either :|
<mitya57> rbasak: He could switch to 3.0, or use dh_quilt, or just add the patch to debian/patches to indicate that it is a patch
<mitya57> also, three changelog entries for one upload looks like an overkill
<popey> is there an easy way for me to do "apt-get source libdbus-cpp3=utopic" for example where I am on trusty?
<popey> (i.e. I want to get the source package from utopic version of a package, on my trusty system)
<Saviq> popey, download off of launchpad easiest probably, otherwise you'd need to add utopic repos to your system
<popey> yeah, figured it was going to be that way, thanks
<maxb> popey: use pull-lp-source from ubuntu-dev-tools
<popey> neat!
<popey> thanks
<sil2100> ;/
<sil2100> ogra_: what are you trying now?
<ogra_> sil2100, a few other things ... gimme a bit
<ogra_> Saviq, so even when adding "initctl start dbus" to the script (and actually getting a proper dbus) i dont get indicators ... looks almost like greeter-started never gets emitted
<Saviq> ogra_, well, don't they crash for you?
<ogra_> Saviq, they do
<Saviq> ogra_, so they are getting triggered, but their env doesn't have the dbus details, I'd say
<rbasak> mitya57: he's not the DM for the package though. Isn't adding a patch system in an Ubuntu delta a little invasive? I agree that he should send the patch upstream or get it in through Debian though. No need to introduce an Ubuntu delta for this.
<ogra_> Saviq, right, looking into that atm
<rbasak> mitya57: I agree about the excessive changelog, though I assume that he's just unfamiliar with tooling. I'd have just fixed that up had I uploaded (which I won't)
<Saviq> ogra_, it's like upstart a) never started dbus or b) didn't put their details into its global env
<rbasak> mitya57: (also, he needs to fix Utopic first now. Easier to just fix Debian)
<mitya57> I agree.
<ogra_> Saviq, right, i have code in place here that calls initctl start dbus now ... pulls the address from it and exports
<ogra_> lets see
<ogra_> \o/
 * ogra_ got indicators 
<ogra_> that looks good !
<sil2100> \o/
<Saviq> ogra_, just push under my MP
<Saviq> ogra_, it's ~unity-team, so you should be able to
<Saviq> ogra_, or well, gimme a diff and I will
<Saviq> (test and push)
<ogra_> Saviq, paste.ubuntu.com/7579305/ ... preparing an MP
<Saviq> ogra_, I'll just add it to mine, let's not break things up in multiple MPs
<ogra_> ok
<sil2100> Damn, hackish
<Saviq> ogra_, wonder if we should use set_greeter_var for it, though
<BluesKaj> 'Morning folks
<Saviq> ogra_, or erm, put it on the upstart env
<ogra_> sil2100, i'll leave the proper cleanup to mterry :P
<sil2100> ogra_: +1 ;p
<Saviq> ogra_, or does "start dbus" take care of it already?
<ogra_> Saviq, well, calling start dbus is the first wrong thing ... the rest is just fallout :P
<ogra_> Saviq, it doesnt give us the address and doesnt export it either ... but luckily stores in that file that i source
<ogra_> its a hack on top of a hack
<ogra_> but seems to work fine at least
<Saviq> mhm
<ogra_> this needs some serious re-work to be right
<ogra_> in fact i think much of it should move into proper upstart jobs and get the right ordering
 * ogra_ looks if it is possible to pull the address more elegantly out of the upstart session global vars instead
<Saviq> ogra_, well, upstart get-env?
<ogra_> right
<ogra_> thats what i'm trying here
<ogra_> but iits a bit fiddly
<ogra_> Saviq,
<ogra_> /sbin/initctl start dbus
<ogra_> export DBUS_SESSION_BUS_ADDRESS="$(/sbin/initctl get-env DBUS_SESSION_BUS_ADDRESS)"
<ogra_> drop the file ... this works too
<ogra_> one hack less
<ogra_> hmm
<xnox> Saviq: i've updated https://wiki.ubuntu.com/Touch/CrossCompile with some notes from the session. Is there anything missing? And where should I circulate it, such that people from the session see it?
<xnox> Saviq: also, I didn't yet find where unity-scope-go bindings in cgo are, and trying to cross-compile those. Can you please remind me who can point me to them?
<Saviq> xnox, jamesh
<Saviq> xnox, and ubuntu-phone@ would definitely be a place to post this
<Saviq> xnox, there's some common data in https://wiki.ubuntu.com/SimpleSbuild too, maybe we should combine those
<Saviq> grr
<Saviq> ogra_, kicked another build in the silo with your fix, then
<ogra_> yay
<sil2100> Saviq: \o/
 * Saviq tries to repro the split bug
<ogra_> let me re-flash my device so i can test on a virgin install
<sil2100> Now it looks so much nicer - although still a bit hackish :)
<ogra_> sil2100, yeah, the starting of dbus should not be needed ... but init is started with --no-startup-event which makes the dbus upstart job not being called
<Saviq> ogra_, does mtp-server respawns here constantly :|
<ogra_> (since it is "start on startup")
<Saviq> -does
<ogra_> not for me
<Saviq> under the greeter session (where it should probably never start in the first place)
<ogra_> yeah
<ogra_> why doesnt it do that here
<ogra_> do you have a porper cable in use ? i'm not sure this is related
<ogra_> (sadly i'm flashing now so my device is taken for the next 12-15 min)
<Saviq> ogra_, I can access it fine
<Saviq> ogra_, but there's the user one running (working), and then the greeter one respawning and crashing in a loop
<Saviq> which kind of makes sense
<Saviq> given it's
<Saviq> start on :sys:android-mtp-on or :sys:android-usb-connected
<ogra_> hmpf
<ogra_> how can i uniquely know i'm in a lightdm session now ...
<ogra_> Saviq, "start on :sys:android-mtp-on or :sys:android-usb-connected and not unity8-greeter-started"
<ogra_> Saviq, try chaning it like that and see if the user mtp-server still starts fine
<ogra_> hmm, i think that needs some brackets to group the old arg
<ogra_> Saviq, "start on (:sys:android-mtp-on or :sys:android-usb-connected) and not unity8-greeter-started"
<ogra_> more like that i guess
<Saviq> ogra_, ok, I'm starting to feel like we're not progressing at all...
<ogra_> the unity8-greeter-started shouldnt be in the users env
<ogra_> Saviq, why is that ?
<sil2100> There's still some time, we can push the revert if this doesn't work
<ogra_> right
 * sil2100 upgrades his phone
 * ogra_ gets some breakfast while teh flo downloads 62 ... 
<ogra_> Saviq, wht i dont get is why mtp didnt start before for you but now does ... it isnt related to dbus in any way
<ogra_> its not like we changed anything else
<ogra_> execpt for the dbus bits
<Saviq> ogra_, no mtp at all now
 * Saviq doesn't get how that could work... they're events, not states, or am I dumb?
<ogra_> Saviq, well, i dont get why you have it all of a sudden
 * Saviq reflashes
<xnox> Saviq: correct, upstart only has events. There is a separate job which emits yeah/nay events (android-mtp-on & android-mtp-off events)
<xnox> Saviq: on system level, which are re-emitted into session init as "sys:android-mtp-on" for example
<ogra_> right
<Saviq> xnox, sure
<Saviq> start on (:sys:android-mtp-on or :sys:android-usb-connected) and not unity8-greeter-started
<Saviq> that I don't get
<xnox> Saviq: it's a fake approximation of the state =)
<ogra_> there is another system job that emits android-mtp-on if the android property is set
 * ogra_ wrote both these jobs 
<xnox> Saviq: the first two are emitted, however, I don't know who/where/what emits "unity8-greeter-started" or how "not" works.
<xnox> Saviq: i don't think that's valid job.
<ogra_> it just hands through the porperty to upstart
<ogra_> xnox, "unity8-greeter-started" is emitted by the new greeter
<Saviq> ogra_, oh so it's a property or an event?
<ogra_> which should only spawn inside the lightdm session
<xnox> ogra_: you apear to be waiting for event called "not" though.
<ogra_> Saviq, we have an upstart property watcher ... the property is watched ... on change it emits the event
<xnox> ogra_: well not you, but that job.
<xnox> start on condition
<ogra_> eeek
<ogra_> indeed
<Saviq> so that explains why it didn't start at all
<ogra_> xnox, well, we only want mtp if that event doesnt even exist
<xnox> ogra_: not possible =)
<ogra_> or rather if the greeter doesnt run in our session
<ogra_> right
<ogra_> :/
<xnox> ogra_: pre-start script
<ogra_> there must be sommething we can check for thoush
<ogra_> *though
<xnox> ! status unity8-greeter-started || {stop; exit 0}
<xnox> end script
 * ogra_ idly waits for his device to finish flashing
<xnox> ogra_: if that's a job.
<xnox> ogra_: but it's not a job.
<ogra_> well, an event
<xnox> ogra_: check for the job presence instead.....
<ogra_> it has a sub-job we could look for
<doko> barry, what is the status of Debian #749692?
<ogra_> right
<ubottu> Debian bug 749692 in python-pip-whl "python-pip-whl is missing dependencies on dependent wheels" [Serious,Open] http://bugs.debian.org/749692
<ogra_> that was my initial idea
<xnox> ogra_: we don't at all store state, thus one has no idea if an event fired in the past and is now gone. Nor one can negate, future events.
<ogra_> right, i think your pre-start thing will work
<Saviq> â yeah, that's why I didn't understand it...
<ogra_> Saviq, add a pre-start script
<ogra_> ! status unity8-greeter-started || {stop; exit 0}
<Saviq> let's see, flashing now
<pitti> jodh: hey James, thanks for the procenv fix; need a sponsor for Debian?
<xnox> ogra_: is unity8-greeter-started an actual job?
<Saviq> no
<ogra_> err, no, one sec ...
<xnox> ogra_: status can only be run on jobs, not events....
<ogra_> there is an actual job though
<xnox> ogra_: see upstart cookbook on how to make mutually exclusive jobs.
<ogra_> unity8-greeter-init
<jodh> pitti: thanks for the offer, but I have upload rights for procenv (it's currently building on their buildd's).
<xnox> ogra_: there is a snippet
<ogra_> Saviq, use that
<pitti> jodh: FYI, I have some improvements for the sbuild test to automatically use the host's apt proxy, so that it runs much much faster locally; I'll test/upload this once procenv actually becomes buildable again
<pitti> jodh: ah, sweet; thanks
<xnox> Saviq: ogra_: once you have a merge proposal, I'd offer to review it.
<ogra_> my prob is that i cant reproduce it at all ... and dont get how Saviq got to that state
<Saviq> ogra_, it does make sense, though - there's only one usb cable, who gets it?
<ogra_> the system first of all :)
<Saviq> (well, the active session, probably)
<jodh> pitti: thanks. I'd like to understand a bit more about why 3.15 dropped that feature, but I plan to add extra procenv guards to avoid such a problem happening again.
<ogra_> right
<ogra_> it seems to be a race i dont see on flo
<Saviq> yeah, I'm on mako
<ogra_> right
<ogra_> phablet@ubuntu-phablet:~$ initctl status unity8-greeter-init
<ogra_> unity8-greeter-init stop/waiting
<ogra_> so there we go
<Saviq> ogra_, that's a task :|
<ogra_> Saviq,  ! status unity8-greeter-init  || {stop; exit 0}
<ogra_> thats what you want in pre-start
<ogra_> in the mtp-server job
<ogra_> try it
<Saviq> k
<ogra_> hmm, probably we dont want the negation
 * ogra_ is confused 
<Saviq> I don't really think this will help, it's a task, it just goes to stopped straight away
<ogra_> sigh
<ogra_> Saviq, haha ...
<ogra_> how about "and started unity8" ;)
<ogra_> lightdm should never start that
<ogra_> since the greeter is its shell
<Saviq> ogra_, USER != lightdm?
<ogra_> oh !
<Saviq> that sounds about right
<ogra_> yeah, that should work too
 * ogra_ tests silo 
<Saviq> what am I doing wrong?!? http://pastebin.ubuntu.com/7579709/
<Saviq> /bin/sh: 1: [: lightdm: unexpected operator
<Saviq> ah sh?
<ogra_> yeah
<ogra_> POSIX ... drop one =
<Saviq> ok good
<ogra_> silo confirmed to work fine
<Saviq> ogra_, on that note http://paste.ubuntu.com/7579717/
<Saviq> the list of things running in the greeter session, we should probably strip some of the
<Saviq> m
<Saviq> but yeah, not necessarily now
<ogra_> yeah, looks ok for now
<ogra_> xnox, http://paste.ubuntu.com/7579742/
<ogra_> please take a look
<ogra_> Saviq, i guess i need to upload that, right ?
<ogra_> (core dev ... etc)
<sil2100> hm, I wonder why I can't upgrade to the unity8 from the silo PPA
<ogra_> sil2100, i just pulled the debs and did a dpkg -i *.deb
<ogra_> worked fine
<sil2100> Yeah, will try that as well then
<sil2100> A bit strange though
<ogra_> you need unity8-common from the i386 build ...
<Saviq> ogra_, that broke user mtp for me (pre-start needs exit 0 always?)
<ogra_> Saviq, err
<ogra_> no, the code is wrong
<ogra_> needs to use curly brackets
<ogra_> sorry, fixing
<ogra_> another bashism :)
<ogra_> Saviq, xnox http://paste.ubuntu.com/7579772/
<ogra_> that should work
<ogra_> hi mterry btw ...
<mterry> ogra_, hello!  I just read the thread
<sil2100> mterry: !
<mterry> Am responding to some of the bugs
<sil2100> mterry: FINALLY!
<ogra_> hehe, yeah ... the world fell apart as expected :)
<mterry> ogra_, sil2100: the dbus thing doesn't make any sense
<ogra_> mterry, we have it fixed now
<Saviq> ogra_, can't say that it does...
<Saviq> ogra_, job failed to start
<ogra_> mterry, but another issue with mtp showed up
<sil2100> mterry: ogra_ and Saviq are doing a nice job of trying to workaround/fix the issues, but I guess someone knowledgable in the very core would be helpful
<mterry> ogra_, sil2100: /usr/lib/lightdm/lightdm-greeter-session launches dbus for the greeter, upstart does it for the session
<ogra_> Saviq, sigh
<ogra_> mterry, only if youhave dbus-x11 installed which spawns multiple session dbuses becaause Xsession.d scripts get processed too
<ogra_> (and drags in X11 deps ... )
<Saviq> ogra_, http://pastebin.ubuntu.com/7579797/ works for me
<ogra_> Saviq, hmm, k
<Saviq> +/- ;
<ogra_> Saviq, can you try without the exit 0
<ogra_> that should be a no-op
<mterry> ogra_, why does the Xsession.d script do that in Mir?  And why didn't we see that in testing I wonder
<Saviq> mterry, that's a great question indeed
<ogra_> mterry, locally run AP tests work fine ... in the lab AP somehow connects to the extra spawned dbus it seems
<mterry> woah
<ogra_> so you didnt see that ... but in any case running multiple session buses is wrong
<ogra_> and for that we have a fix
<mterry> But I've also done plenty of ps aux | greps in my testing.  I feel like I would have noticed a whole extra dbus, not to mention the problems that would cause the greeter session
<ogra_> mterry, what i find more interesting is why didnt you see the mtp issue
<ogra_> your desktop should have been plastered with mtp errors
<mterry> ogra_, what's the mtp issue?
<ogra_> mterry, it starts for lightdm
<ogra_> and when the user one starts it clashes
<ogra_> and crashes
<Saviq> ogra_, no, no errors on desktop
<ogra_> Saviq, oh ?
<Saviq> ogra_, it crashes in the *lightdm* session
<ogra_> ah, k
<Saviq> ogra_, not in user
<ogra_> so just a .crash file
<Saviq> so anyway, it works fine, connects fine, *just* apport dumping your battery down the drain
<ogra_> Saviq, anyway, does dropping exit 0 still work ?
 * ogra_ would liek to get rid fo that 
<Saviq> ogra_, worse than that, I just lost indicators again :|
<ogra_> oh my
<ogra_> Saviq, with no changes to the greeter stuff and using the silo packages ?
 * ogra_ reboots his flo 10 times ... lets see
<Saviq> ogra_, no, patched manually, will flash again and get the silo now
<mterry> but I would have seen the crashes in /var/crash then...
<Saviq> mterry, yeah, I do have the feeling that something moved under our feet :|
<mterry> ogra_, and why was it only flo that had the dbus problem?
<ogra_> mterry, http://ci.ubuntu.com/smokeng/utopic/touch/
<ogra_> not only flo
<ogra_> i just dont have a mako for hacking
<ogra_> Saviq tests mako, i test flo atm
<xnox> ogra_: that pastebin is good.
<mterry> ogra_, on the mailing list only flo was listed as having the black-boot problem
<mterry> ogra_, all had it?  (We also tested flo in Malta...)
<ogra_> mterry, black boot ?
<Saviq> mterry, yeah, no black boot
<mterry> ogra_, people were saying there was a boot problem getting any session on flo
<ogra_> mterry, that was with the half done landing ... unrelated
<mterry> ogra_, I don't think it was the half done landing
<ogra_> mterry, unity8 didnt land til sunday late afternoon
<ogra_> all other bits from the silo did
<Saviq> ogra_, I don't think the exit 0 is a noop
<Saviq> ogra_, if USER != lightdm
<Saviq> ogra_, it will exit with ['s retcode
<mterry> ogra_, (A) I'm not sure the half done landing caused any problems.  I *thought* I set all the dependencies correct -- in this case, ubuntu-touch-session woudln't have landed until unity8 did, so no split boot would be enabled.
<mterry> (B) people reported same black boot after unity8 landed
<ogra_> Saviq, which either triggers stop or not ...
<Saviq> ogra_, yeah, and when not
<ogra_> Saviq, the exit 0 is after the "if"
<Saviq> ogra_, pre-start exits with 1
<Saviq> ogra_, so job fails
<xnox> Saviq: did you test it.
<ogra_> i dont get why the curly brackes we use everywhere else didnt work for you
<xnox> "[foo] && bar" construct is considered guarded, and works correctly under `set -e`
 * mterry re-reads thread to see which symptoms were from the second dbus
<ogra_> mterry, the half done landing was an infra prob ... unity8 was stuck somewhere
<ogra_> mterry, not your fault
<Saviq> xnox, I did
<xnox> Saviq: ogra_: it can be changed to ' [ "$USER" != "lightdm" ] || { stop; exit 0; }
<sil2100> mterry: right, it wasn't on your side
<ogra_> mterry, the double dbus caused http://ci.ubuntu.com/smokeng/utopic/touch/ to regress heavily
<mterry> ogra_, oh, so if ubuntu-touch-session got through then without unity8, yeah that could cause problems
<Saviq> xnox, ok let me try that
<ogra_> mterry, which doesnt show up when testing locally
<Saviq> not sure why || would behave differently than &&?
 * mterry has to run real quick for 15m, be back
<sil2100> In 15 minutes we will commence the big revert ;p!
<ogra_> Saviq, 10 reboots in a loop ... i always had indicators here
<xnox> Saviq: it shouldn't. maybe -1 exit is comming later? also you do need to fully stop the job, for the new config to take effect on next start. (restart is not enough, one needs stop&start)
<ogra_> sil2100, thanks for telling us ... :P
<ogra_> sil2100, the silo looks fine for me, did you try ?
<Saviq> xnox, yeah yeah, I had it stopped and went "start foo", it barfed
<Saviq> xnox, I'll try in a sec, flashing
<sil2100> ogra_: rebooting and looking, but what about that adb problem? Is the pre-start hack working?
<Saviq> sil2100, mtp, not adb, and yes, we're almost ther
<Saviq> e
<ogra_> sil2100, it should ... waiting for Saviq for a final test, then i'll upload to the silo
<sil2100> s/adb/mtp
<sil2100> ACK
<sil2100> ;)
<ogra_> sil2100, we use the same code xnox pointed to above in a ton of other scripts ... should definitely work
<sil2100> \o/
<sil2100> Ok, I like how it works
<ogra_> got indicators ?
<sil2100> Yep!
<ogra_> great
<sil2100> Nice greeter indicators indeed on my mako
<ogra_> now just mtp ...
<sil2100> Trying the fix outlined above
<ogra_> sil2100, check if they opertes right
<ogra_> *operate
<ogra_> sil2100, battery should look different in the greeter than in the session
<ogra_> clock too
<ogra_> if you expand them
<sil2100> So far so good, they look different indeed + disabling/enabling wifi works
<ogra_> good
<ogra_> then all should be fine with that landing
 * sil2100 tries to run some AP tests to see if all is ok
<ogra_> ++
<ogra_> good idea
<ogra_> perferably some of the ones we know did fail
<ogra_> sudoku is a good one for that
<ogra_> xnox, Saviq, final version that works fine here ... no crashes and mtp still starts fine for the user http://paste.ubuntu.com/7579893/
<ogra_> sil2100, feel free to try that too (and check if there are crashes in /var/crash for the 111 user after applying it )
<Saviq> ogra_, http://paste.ubuntu.com/7579899/
 * Saviq had some network weirdness
 * mterry is back
<ogra_> Saviq, yeah, identical to mine http://paste.ubuntu.com/7579893/
<mterry> Is there anything I can help with or did you heroes already just solve something?
<ogra_> Saviq, works fine for me ... did you verify on mako ?
<Saviq> ogra_, yes, have mtp for user, no crash
<ogra_> mterry, i think we are fine for now ... but read the rest of the thread there are more regressions
<ogra_> mterry, i guess bfiller would appreciate if you could help with these
<ogra_> Saviq, good, dputting to the silo ... then a final test of the package, then lets publish and fire off an image
<Saviq> ogra_, yeah, I'll do some telephony stress-testing in the mean time
<sil2100> mterry: some regressions might have been fixed by ogra_'s and Saviq's fixes, but some others might still be a problem
<mterry> ogra_, all the telephony ones?  Yeah, I saw that.  Some were known, but some are surprises yeah
<ogra_> Saviq, ++
<pmcgowan> mterry, btw shouldnt the indicators only show different behavior when the phone is locked
 * sil2100 runs sudoku-app tests
<sil2100> pmcgowan: they do right now, right?
<ogra_> sil2100, but we have no actual "locking" enabled atm
<mterry> pmcgowan, no they have a slightly different UI even in no-password mode to my knowledge
<pmcgowan> sil2100, they are aways reduced features from greeter - without lock
<mterry> pmcgowan, they export differences via phone vs phone_greeter profiles
<pmcgowan> mterry, thats different than android and ios afaik
<pmcgowan> more a question for design
<ogra_> and surely not a blocker for now
<mterry> pmcgowan, right.  We have the information available to indicators to show what they wish on the greeter
<Saviq> pmcgowan, indeed, and then we're the first doing that kind of thing on a phone AFAICT
<mterry> pmcgowan, we export current user, whether they need a password, and that we are in a greeter
<pmcgowan> not a blocker, just noticed in 59
<pmcgowan> mterry, ok
<ogra_> mterry, the boot animation is really really tiny ... is that wanted ? its only like 1-1.5cm on the flo screen
<pmcgowan> mterry, I also looked at the memory overhead for all the additional processes, its not terrible but not great either
<ogra_> pmcgowan, huh ? it doubled
<mterry> ogra_, I don't know about the scaling...  Mirco wrote the actual gl code.  It probably should scale bigger on flo
<pmcgowan> ogra_, its around 40MB more
<ogra_> and causes issues with app lifecycle ... apps dies way eralier
<mterry> pmcgowan, yeah.  We double the shell memory
<ogra_> pmcgowan, not what i see
<pmcgowan> ogra_, oh, perhaps I mssed something
<sil2100> From what I saw it was much higher than before
<mterry> pmcgowan, and some of the extra telephony processes etc
<Saviq> pmcgowan, mterry, but a lot of that mem should be shared, no?
<pmcgowan> mterry, see https://docs.google.com/a/canonical.com/spreadsheets/d/1kBNHXCh941rcl7ZUbpjpRlyMtNAZmqCRhEy0jOM4Izo/edit#gid=0
<Saviq> same libs etc.
<pmcgowan> Saviq, yeah I counted PSS
<Saviq> oh k
<ogra_> pmcgowan, bug 1325580
<ubottu> bug 1325580 in unity8 (Ubuntu) "after split greeter landing unity8 and the greeter consume a lot more memory" [Undecided,New] https://launchpad.net/bugs/1325580
<ogra_> pmcgowan, will definitely need improvements ...
<Saviq> yeah, that's to be fixed for sure, shell should have reduced, greeter shouldn't be that big
<ogra_> right
<mterry> ogra_, pmcgowan: are you saying that unity8 RSS got bigger by itself after split landing?
<Saviq> and well, we can probably strip the greeter session (there's mediascanner running, for example)
<sil2100> ogra_: all sudoku tests passed locally \o/
<Saviq> hud
<ogra_> and there are a lot upstart jobs we dont want in the greeter ...
<mterry> Or just that having an extra greeter process is causing problems?
<ogra_> sil2100, yay
<sil2100> ogra_: let me revert and see if I had those failures before actually...
<pmcgowan> mterry, I was saying the latter
<mterry> ogra_, we don't start most of them -- we have a custom startup event in greeter shell
<ogra_> mterry, well, we have two full sessions atm
<sil2100> As per smoketesting
<ogra_> right
<ogra_> we dont start most of them but still too many
<ogra_> the greeter itself shouldnt eat 90M+ either
<Saviq> we should not start maliit in the greeter until it's needed, that's for sure
<mterry> ogra_, mediascanner is an interesting one -- wonder why it starts
<ogra_> might need the same change we used for mtp
<Saviq> hud, should be gone, too
<pmcgowan> we need to fix maliit to begin with
<mterry> Yeah, maliit probably shouldn't be the biggest RSS consumer anyway
<ogra_> ++
<pmcgowan> thats already known issue
<sil2100> +1
<ogra_> anyway ... lets see that we get out of TRAINCON-0 now
<Saviq> that, too
<ogra_> then we can look into optimizations
<mterry> ogra_, so what fixes do we have lined up?
 * ogra_ is also curious about boot time 
<ogra_> mterry, silo 20
<ogra_> proper dbus handling and dropping of dbus-x11
<mterry> ogra_, boot probably suffered.  I remember doing some testing and it got slightly worse, but surprisingly not as bad as I expected
<ogra_> and mtp suppression in lightdm sessions
<mterry> ogra_, but I don't have those numbers
<ogra_> mterry, i'll produce bootcharts once w ehave a proper image
<ogra_> one step at a time :)
<ogra_> currently we are around 30sec
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-49.png
<Saviq> mterry, I don't seem to get dialer when accepting a call
<ogra_> thats the last one i did
<mterry> ogra_, Saviq, sil2100, others: thanks for taking care of this yesterday/today.  I owe you all beers and hugs.  I would have been able to help a little last night, but my flight got delayed 3h because someone died on it(!)
<ogra_> OH GOD !
<sil2100> mterry: oh crap...
<Saviq> maan
<Saviq> mterry, I mean it doesn't unlock
<mterry> Saviq, that's new...
<mterry> Saviq, you press the button, does it launch dialer in session and just fail to unlock?
<Saviq> mterry, yes
<Saviq> mterry, when I launch from launcher, unlocks fine
<mterry> Saviq, they come from different places...  notification is via us pretending to be url-dispatcher
<mterry> Saviq, but if it launches in session, we are seeing the event
<Saviq> mterry, yeah, so by then it's greeter that should unlock itself, that's what fails
<Saviq> mterry, btw, I wrote on one of the bugs... I feel like we need to converge on just one notification UI
<ogra_> Saviq, mtp has built in the silo ... can you test the deb
<ogra_> sil2100, ^^^
<Saviq> ogra_, doing
 * ogra_ does too on flo 
<mterry> Saviq, yeah.  I just looked at code, and we are doing a hide right after telling session.  Odd
<sil2100> Saviq: I'm ready to publish anytime
<mterry> Saviq, one process can't currently draw on each session -- I suppose we could make a system daemon that talked to USC and overlayed a notification
<Saviq> mterry, well, greeter can, can't it
<mterry> Saviq, not on user session when you're in it
 * ogra_ reboots with the mtp-server deb
<Saviq> mterry, oh thought greeter is just a layer on top
<mterry> Saviq, it's its own Mir session -- can we interleave Mir surfaces and sessions?
<Saviq> mterry, understood it's a complete session that hides, now
<Saviq> mterry, they get composited are they not
<Saviq> mterry, as you swipe the greeter away
<Saviq> mterry, anyway... LATER
<mterry> Saviq, yeah but that's just one session on top of another.  But you're right, I think we could interleave if we wanted.  But we'd have to proxy notifications that only session sees through the greeter in that case
<mterry> Saviq, sure.  :)
<Saviq> mterry, yeah, some smarts need to happen
<Saviq> mterry, but yeah, it reliably does not unlock for me
<mterry> Saviq, reliably.  OK.  Let me get a phone hooked up with latest image
<Saviq> mterry, can you start looking into that?
<Saviq> great
<ogra_> mtp is fine here
<Saviq> ogra_, sil2100, should I run AP locally or are we going for fur smoke test
<Saviq> ?
<ogra_> i think sil2100 tested a few
<Saviq> ogra_, +1 on mtp
<Saviq> dialer and messaging would be most useful
<sil2100> Saviq: I ran sudoku app which was said to be failing
<Saviq> but I don't want to delay
<sil2100> Saviq: and it passed
<ogra_> and given that we were never able to reproduce the AP failures locally anway i would go for smoke
<Saviq> +1 then, let me just run through manual tests for ofono
<sil2100> Saviq: but those passed with the old unity8 from #62 as well...
<ogra_> they always passed locally
<ogra_> and failed in the lab
<ogra_> except when plars did the hackery of removing Xsession.d ..
<ogra_> this part should be fine now so AP should pass in the lab
<ogra_> lets probably take that to the -ci-eng channel now
<sil2100> I would say, let's get this released and check the image results
<ogra_> ++
<barry> doko: i'm working on this whole stack today, so i will verify that particular bug
<GunnarHj> rbasak: Hi Robie!
<rbasak> GunnarHj: hi!
<GunnarHj> rbasak: Thanks for looking at bug 1314402! How would you suggest that we ask for input from other developers?
<ubottu> bug 1314402 in Ubuntu "Please upload skype-translation to the archive" [Wishlist,In progress] https://launchpad.net/bugs/1314402
<rbasak> GunnarHj: np, thank you for your work! ubuntu-devel or ubuntu-motu maybe?
<rbasak> (as in, mailing lists)
<rbasak> Or if somebody experienced on here can answer, I'd be happy with that too - I would just copy and paste into the bug for future reference in that case.
<rbasak> Others: the issue is that GunnarHj's proposed package provides extra translations for Skype, so sort of integrates with that package but without being able to change that package.
<rbasak> And Skype could in future provide new translations which would need to override the skype-translations package without breaking anything.
<rbasak> So GunnarHj has arranged for the skype-translations binary package postinsts to insert symlinks, but only if regular files don't exist in their place. Then a future skype package would just overwrite those symlinks.
<rbasak> I think we all accept that this is hacky, but don't have a better solution. Is this acceptable for upload to universe?
<rbasak> GunnarHj: is that an accurate summary? Anything to add?
<GunnarHj> rbasak: Thanks, yes I think that's pretty much it. Let's see if someone chimes in. Otherwise I can try one of the lists.
<GunnarHj> seb128, Laney: A while ago you provided some input wrt bug 1314402 and my symlink idea to avoid future conflicts with the Skype package, and I made a minor change. Now rbasak is sponsoring the request, and is asking whether the idea is a reasonable approach that could be accepted for uploading to universe. Please see rbasaks questions above (13:19 UTC). Would appreciate your input (again).
<ubottu> bug 1314402 in Ubuntu "Please upload skype-translation to the archive" [Wishlist,In progress] https://launchpad.net/bugs/1314402
<seb128> GunnarHj, Laney is on vac today, and I've no strong opinion, I feel it's hacky and it's going to bite us back, but I have too much to do to argue against it, so if somebody wants to upload just go for it
<rbasak> GunnarHj, seb128: well, that's what makes me reluctant :-/
<GunnarHj> seb128, rbasak: Ok, thanks seb128 (I think). ;) All I can say is that my intention is to monitor it to prevent that anything goes wrong (even if I currently don't see what it could be).
<seb128> GunnarHj, creating symlinks in postinst that are meant to be overwritten by other debs is just a weird hack, sorry
<rbasak> seb128: everything in the partner archvie is a hack though :)
<GunnarHj> seb128, rbasak: I don't claim it's not. It's just that it's the only way I could come up with to make it possible to package those translations.
<rbasak> slangasek: I see that you've done most/all of skype uploads to partner. Do you have any comment on this, please? ^^
<seb128> GunnarHj, hacks create unreliability in the system and whats makes our upgrades fragile
<rbasak> (going back ~40 minutes)
<seb128> GunnarHj, to me the proper solution there seems to work with upstream to have them include the translations, or check a different paths in addition to their
 * rbasak wonders if there's a better approach here, such as adding support into the partner skype package.
<rbasak> I don't know what form that might take though.
<GunnarHj> seb128, rbasak: Well, admittedly I haven't tried to approach upstream. As regards doing something in the partner repository, I think that would be difficult since people may alternatively install Skype directly from the Skype web site.
<rbasak> Pragmatically I think that having something community-maintained and in universe that makes for a better i8n experience for something in partner is something we should support, since Ubuntu is supposed to be for everyone and the community is volunteering translations.
<rbasak> But I'm not sure it makes sense to go the step further and have packages in universe support an even more third party source than the partner archive is.
<rbasak> If users are installing Skype directly from the web site, then they can install translations directly from the other source.
<GunnarHj> rbasak: Well, that's a valid point indeed. Actually, in the proposed package I refer to the partner repository in the descriptions in debian/control.
<rbasak> GunnarHj: I'm trying to think of how we might make this work with less of hack assuming that we could make a change to how the partner repository's skype package handles it.
<GunnarHj> rbasak: Yeah.. This is something I haven't thought much about so far.
<rbasak> GunnarHj: what if the skype package's postinst installed the symlinks instead, and the preinst removed them?
<rbasak> skype-translations would still provide the actual translations, and the skype package would them hook into them if present.
<rbasak> One catch is that removing skype-translations would lead to a tree of broken symlinks.
 * rbasak doesn't know
<rbasak> I think a mailing list thread is appropriate at this point :)
<GunnarHj> rbasak: Maybe you are right. I'll think a little more about it, and then start a thread. Thanks for your thoughts so far.
<rbasak> GunnarHj: no problem. Thank you for working on this. It's a tough situation and I appreciate you persevering to improve Ubuntu.
<pmcgowan> mlankhorst, can you take a quick look at https://bugs.launchpad.net/qt/+bug/1318584
<ubottu> Launchpad bug 1318584 in Next Generation Checkbox (GUI) "checkbox-gui crashed when switching video out mode to external only mode" [Medium,Confirmed]
<shadeslayer> pitti: poke
 * pitti does a jump to the left
<shadeslayer> :D
<shadeslayer> pitti: is there any advantage to running package tests on the builder vs on the autopkgtest setup?
<pitti> shadeslayer: in general, if a package has "make check" like upstream tests, run them during package build
<pitti> shadeslayer: that'll cover all architectures and we also have more hardware for it, and failures should cause FTBFS which is more "obvious'
<shadeslayer> right
<pitti> shadeslayer: if you can run an upstream test suite against the installed packages, then the autopkgtest can do that
<pitti> shadeslayer: for some test suites that's easy (some projects have a "make installcheck"), for others it's hard/impossible
<pitti> shadeslayer: in the latter case it's usually better to come up with a simple smoke test that ensures that the package works at all (has exectuables/includes/files etc. at the right place and enough dependencies)
<pitti> shadeslayer: so in short: upstream tests during build -> check the fine details; smoke tests during autopkgtest -> ensure that the package is by and large right
<shadeslayer> roger
<slangasek> rbasak: what's the gist of your question?  I guess you're not asking me to comment on whether everything in the partner archive is a hack ;)
<rbasak> slangasek: so GunnarHj wants to add a new skype-translations package to universe, which will augment the skype package by providing translations not available upstream.
<rbasak> slangasek: the awkward thing is that skype looks for translations in one place, so I'm not sure how to technically do this without skype-translations messing with the directory that skype ships.
<rbasak> slangasek: GunnarHj has a solution with symlinks that appears to work, but it is definitely a hack. I wonder if a better way is to add support to the skype package somehow.
<rbasak> Or, if not, then is the mechanism GunnarHj has come up with acceptable for upload to universe. I'm reluctant to upload without a +1 from someone else on the approach.
<rbasak> (that first sentence should have been a question)
<slangasek> rbasak: what's wrong with skype-translations shipping files in the same directory as skype itself?  This seems perfectly reasonable to me
<GunnarHj> slangasek: For the case you have time to take a closer look, the skype-translation package that rbasak has reviewed is built in utopic at
<GunnarHj> https://launchpad.net/~gunnarhj/+archive/skype-translation/+packages
<slangasek> as for adding it to the skype package itself, I would say no unless it gets upstreamed
<GunnarHj> slangasek: The problem is possible conflicts if later Skype versions are bundled with the same translations.
<slangasek> GunnarHj: so use a pre-emptive "replaces"?
<GunnarHj> slangasek: Err.. What's that in English? ;)
<slangasek> have skype-translations declare Replaces: skype, so that the skype-translations versions of the files will always be used without complaints from the package manager
<seb128> slangasek, the issue is in the other way
<seb128> slangasek, new skype might includes translations that are in skype-translation
<rbasak> slangasek: I did not know that would be acceptable. Thanks! I wonder if it's possible to do it the other way round though then? So a new skype will replace older translations in skype-translation?
<seb128> slangasek, so skype would fail to install
<slangasek> seb128: not with a Replaces it wouldn't
<seb128> unless upstream skype add the proper replaces
<slangasek> no, there would be no failure to install
<slangasek> you can always install a "replaced" package, it just doesn't get all of its files unpacked
<seb128> hum?
<seb128> skype 6 would start shipping de.po which is in skype-translation
<slangasek> now, if this is not acceptable because we must prefer the upstream translations over the ones in the skype-translations package, then this doesn't solve the problem
<seb128> how would that not fail on a file conflict
<slangasek> because that's what Replaces means
<seb128> (if skype doesn't add the Replaces)
<seb128> well, that means having skype to add a Replaces to their package
<seb128> which they didn't do yet
<infinity> No...
<slangasek> no, it does not!
<slangasek> Replaces tells you /which package wins/ in the case of a file conflict
<infinity> seb128: If skype-translation replaces skype, it always wins.  Install order doesn't matter.
<GunnarHj> slangasek: But that would mean that if there is a skype-translation translation installed, it would take precedence over the translation bundled with Skype. Would that be an acceptable solution?
<infinity> The only minor bug there is that if you remove skype-translation, you'll have files "missing" from skype.
<seb128> oh, ok
<slangasek> GunnarHj: it's acceptable from an archive perspective; it just puts the burden on the maintainer of skype-translations to make sure the package is kept up to date
<seb128> learning every day ;-)
<seb128> I though replaces was unidirectional
<GunnarHj> slangasek: Well, I'm ready to assume that role...
<infinity> seb128: It is.  It's just that install order doesn't matter.  An installed package can Replaces a package you're about to install, and the new one just won't have all its files installed.
<infinity> And, of course, the real problem here is that if there's an overlap, then skype-translations is updated to remove the overlap, peole who already upgraded skype just won't have that translation anymore.
<infinity> (translations installed, includes de.po, new skype installed, its own de.po is replaced, new translations installed, de.po removed)
<infinity> Which is why unconditional replaces is generally a bad idea.
<GunnarHj> infinity: What if you just drop a translation from skype-translation, if it gets bundled via a new Skype version? Then it wouldn't be removed.
<infinity> GunnarHj: That depends on upgrade order.  If your new translations is upgraded BEFORE the new skype, all is well.  If the new skype is upgraded first, the file goes missing.
<infinity> This isn't to say that this hack isn't preferable to having no translations at all, perhaps, just that there's a limitation here that can't be solved without upstream interaction.
<infinity> Having skype read from a secondary location is much cleaner, in that it avoids this hack.
<GunnarHj> infinity: There is just a tiny detail... How to get Microsoft listen to such a request?
<infinity> How does skype do translations?
<infinity> Is it just gettext?
<infinity> Or something fancy?
<infinity> Cause our glibc is already patched to read secondary locations (this is how langpacks work)
<infinity> If you used the langpack location for your translations, maybe it would Just Work?
<infinity> ie: /usr/share/locale-langpack/*
<GunnarHj> infinity: Nothing fancy. Special .ts XML files that are converted to .qm files.
<infinity> Oh.  So, yes.  Fancy, from my POV. ;)
<infinity> So, the much messier, but won't-cause-disappearing-files-or-conflicts option is to dpkg-divert every one of the files you ship.
<infinity> So that if skype ships the same file, it gets diverted, but exists.
<infinity> And then when you remove it from yours, the skype one is moved back to where it should live.
<GunnarHj> infinity: That's something new to me. Sounds interesting.
<infinity> GunnarHj: The manpage can be a bit daunting, as is getting the right syntax.  But in plain english, a dpkg-divert says "if another package tries to install $file, please install it to $file.otherlocation instead", and then when you remove $file from your package, you also remove the diversion, so the other owner's file gets moved back to where it belongs.
<GunnarHj> infinity: Can you think of a package where that feature is made use of?
<GunnarHj> infinity: (as an example)
<infinity> pkgbinarymangler has the scariest diversion in the entire archive. :P
<infinity> (utopic-amd64)root@cthulhu:/home/adconrad# dpkg -S /usr/bin/dpkg-deb
<infinity> diversion by pkgbinarymangler from: /usr/bin/dpkg-deb
<infinity> diversion by pkgbinarymangler to: /usr/bin/dpkg-deb.pkgbinarymangler
<infinity> dpkg, pkgbinarymangler: /usr/bin/dpkg-deb
<infinity> (do not try that one at home, kids)
<infinity> GunnarHj: There's hackish stuff in pkgbinarymangler's preinst to make sure dpkg-deb always exists, obviously that doesn't matter much for diverting a translation, so you can ignore that bit.
<GunnarHj> infinity: Ok.. I will take a look, and try to figure out if and if so how this could be applied to my simple package.
<GunnarHj> infinity: Thanks for the tip!
<infinity> GunnarHj: In the case of a package diverting multiple files (and potentially removing some), I'd probably do it with variable and shell loops.
<GunnarHj> infinity: Sounds reasonable.
<infinity> GunnarHj: ie: CURRENT_TRANS="de kr jp"; OLD_TRANS="es fr", and make sure you're removing diversions for OLD_TRANS on upgrade.
<GunnarHj> infinity: Think I get the picture. Have some reading and testing to do now. ;)
<ogra_> pitti, ugh ... is there any way to not make ofono-phonesim-autostart pull dbus-x11 into the test env ?
<hallyn_> ok it's gotta be pulseaudio.  crashing my utopic laptop anytime i've played, let's say, about 10 mins of audio
<hallyn_> hard crash though, nothing in syslog, alt-sysrq doesn't work, have to hold down power button
<chrisccoulson> mlankhorst, who can I ping about nouveau-specific issues? I could do with some help on bug 1309044
<ubottu> bug 1309044 in xserver-xorg-video-nouveau (Ubuntu) "Unity webapps crash Ubuntu 14.04 LTS on my computer" [Undecided,New] https://launchpad.net/bugs/1309044
<hallyn_> serge    11285 26898  0 13:15 ?        00:00:01 /bin/bash /usr/bin/pomigrate2 --use-compendium --pot2po --quiet tmp.Cvh7SoRbeB/af /home/serge/po/af /home/serge/po/templates
 * hallyn_ purges translate-toolkit for lack of better idea
<brendand> More utopic trouble anyone?
<brendand> Stuck on 'Started Accounts Service'
<brendand> Strange thing is i don't even remember upgrading
<brendand> Now it's colord.service
<brendand> Ahh - it was fsking unity8-greeter at it again
<brendand> Managed to install itself behind my back
<stgraber> GunnarHj: hey there, were you the one requesting the svtplay-dl sync for trusty? Seems likely to be a mistake (trusty instead of utopic), if so, I'll reject it from the New queue.
<GunnarHj> stgraber: Yes, it was me, and no, it was no mistake.
<stgraber> GunnarHj: ah, ok, what's the rationale for getting that new package into the archive post-release?
<GunnarHj> stgraber: It's already in utopic; this is a SRU, sort of...
<GunnarHj> stgraber: The rationale is to make it more easily available to users already in 14.04.
<stgraber> GunnarHj: ok, sounds more like something for trusty-backports than for the trusty-updates
<stgraber> (which to a user wouldn't make any difference since both are enabled by default)
<GunnarHj> stgraber: Is backports enabled by default these days?
<stgraber> GunnarHj: it is, yes
<GunnarHj> stgraber: Ok, didn't know. Well, in that case a backport would be just as good, I suppose. But I also thought that since this is a standalone package, that can't break anything existing, it didn't matter...
<stgraber> GunnarHj: we usually only allow new packages in stable releases for post-release hardware enablement. Backport from new releases (whether the package already exists in a past release or not) should go through -backports.
<stgraber> GunnarHj: ok, so I'll reject that upload. Please run "requestbackport svtplay-dl" on your machine to automatically file the backport request, then a member of ubuntu-backporters will process it for you.
<stgraber> rbasak: hey there, can you add the SRU paperwork to bug 1309991 please?
<ubottu> bug 1309991 in dict-st (Ubuntu) "crashes when install comodo free antivirus for linux" [Undecided,Invalid] https://launchpad.net/bugs/1309991
<GunnarHj> stgraber: Ok, will do. Thanks for letting me know.
<stgraber> pitti: hey, your util-linux upload is missing the usual SRU paperwork, though the bug is sufficiently obvious that I'll accept it anyway (the title pretty much being the testcase anyway)
<stgraber> bdrung: can you update both the bugs referenced in that audacity upload with the SRU paperwork stuff? they both seem to be lacking testcases at least.
<bdrung> stgraber: i can quickly add a test case for the libav bug
<stgraber> lool: can you update bug 1310715 with SRU information (rational, testcase, regression potential, ...)?
<ubottu> bug 1310715 in ubuntu-touch-meta (Ubuntu Trusty) "Provide final 14.04 frameworks" [High,New] https://launchpad.net/bugs/1310715
<bdrung> stgraber: 1076928 updated
<bdrung> stgraber: paperwork for both audacity bugs done.
<stgraber> bdrung: cool, thanks. Re-reviewing now
<stgraber> bdrung: both of those have been fixed in utopic right? (LP says that's not the case but I suspect it's wrong)
<bdrung> stgraber: audacity should migrate in utopic
<bdrung> stgraber: audacity is still stuck in proposed due to libav
<jdstrand> mdeslaur: will we have something equivalent to the apparmor status in upstart jobs when we move to systemd?
<jdstrand> s/status/stanza/
<stgraber> bdrung: ah ok, that makes sense then
<bdrung> stgraber: do you know why libav didn't migrate?
<stgraber> bdrung: no, but I can look it up for you
<infinity> bdrung: libav is a pretty involved ongoing transition.
<bdrung> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libav
<bdrung> that page says that libav is a valid candidate
<infinity> bdrung: Sure, and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows how many dozens of packages break if it migrates.
<stgraber> bdrung: right, in which case you need to also look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<infinity> bdrung: You need to read both pages as a whole, it's two steps in the process.
<stgraber> http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html seems relevant too
<bdrung> that page is easier to understand than the update_output.txt
<stgraber> yeah, update_output.txt isn't the most readable thing ever, it assumes you know how britney works quite well (or that your brain somehow adapted to make sense of that file)
<psusi> cjwatson, bug #1326143 the user has no efi system partition, yet grub-install failed to fall back to grub-pc for some reason... any clue as to how that could happen?
<ubottu> bug 1326143 in grub-installer (Ubuntu) "fatal error installing grub to USB HDD when installing system to USB HDD" [Undecided,New] https://launchpad.net/bugs/1326143
#ubuntu-devel 2014-06-04
<mbiebl_> jdstrand: there is a AppArmorProfile= stanza
<mbiebl_> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
<mbiebl_> is that what you are looking for?
<mbiebl> (v204 doesn't have that yet, though)
<mbiebl> needs at least v211 iirc
<mbiebl> actually, it's v210
<pitti> stgraber: util-linux> ah, I'll add a pointer to the patch; I asked the reporter before whether he'll test it on stable
<pitti> ogasawara: phonesim-autostart> sorry, no, it does need dbus-launch; but that fixed Xsession.d/ script has been in utopic since yesterday, so it should be harmless now?
<pitti> Good morning
<RAOF> pitti: Good morning!
<ScottK> pitti: Do all programs that we switched to use an upstart job need their sysvinit script restored?
<RAOF> pitti: Would you be able to run a colord build on a mips porter box? I'd like to know whether some changes fix the build.
<pitti> ScottK: at least all which are dependencies of other init.d scripts
<ScottK> OK, but not leaf packages then.
<pitti> ScottK: right; it often lowers the delta to Debian to put it back anyway, but it's not required
<pitti> and of course it'll make things work under systemd
<pitti> RAOF: yes, can do
<ScottK> The package I'm worried about is already forked, so no rush.
<RAOF> pitti: If you'd kindly run a arch-dependent only build of the tip of colord.git that'd be aces.
<RAOF> pitti: Oh, also, does autopkgtest set an environment variable containing the build path anywhere? ADTTMP is not what I'm after; I want to be able to cat the test logs so that the automake test runner can output marginally useful messages.
<pitti> RAOF: that should just be pwd; if you change directory in your test you could just save the original dir?
 * RAOF goes to check the location of the logs.
<RAOF> Hm, no.
<RAOF> pitti: Running âmake -C lib/colord check; cat lib/colord/test-suite.logâ in a normal build tree works fine, but in the adt test can't find test-suite.log?
<pitti> hmm, no immediate idea; this should certainly work
<pitti> RAOF: btw, why is this 'build needed' *and* you call make check again?
<pitti> oh, the build-needed would also run ./configure
<RAOF> pitti: Because make check isn't run during the build?
<pitti> *nod*
<pitti> RAOF: so you get failures, but no test log written? I have no idea whre they'd go, given that you call "make check" in the cwd where the package is
<RAOF> Oh.
<RAOF> You know what? I should try --shell-fail and see where they are!
<pitti> but the ones in jenkins succeed
<RAOF> The ci.debian.org ones don't.
<pitti> (I'm not sure whether automake's test runner also writes the logs on success)
<pitti> See lib/colord/test-suite.log
<pitti> yeah, it should indeed be just there
<pitti> RAOF: build deps installing on the mips porter box, btw; this just takes rather long
<RAOF> pitti: Well, the 1.2.0-3 *build* seems to time out after 300 minutes, so I'm perfectly prepared to believe that installing the dependencies is also slow :)
<pitti> urgh
<pitti> I should have started that in screen
<RAOF> As long as you don't build the arch:all packages it should no longer take that long.
 * pitti restarts the whole thing, better now than wasting half a day :)
<RAOF> :)
 * pitti NEWs ubuntu-app-launch to untangle the autopilot uninstallability
<pitti> RAOF: debuild started now
<RAOF> With just binary-arch, right?
<pitti> RAOF: dpkg-buildpackage -us -uc -B -j8
<RAOF> Sweet.
<RAOF> Just making sure. Otherwise you get wait for the process that consumes gigabytes of memory and takes ages :)
<pitti> ah, this box only has 2 GB
<pitti> but 16 cores :)
<richardus> so i want to make an upload to debian of a package that fixes an ubuntu bug.  do i make a changelog entry to close it or will the ubuntu people/ubuntu changelog do that? and what is the format for the entry?
<richardus> i should add that debian also exhibits the ubuntu bug, i'm not completely crazy
<RAOF> richardus: If you add (LP: #bugnumber) to the changelog it'll get automatically closed when the package is imported.
<RAOF> Or when it's merged manually, if we've got Ubuntu-local changes to it.
<Unit193> xnox: The systemd beep seems to be related to brltty, when I purged that the beep sounded.
<pitti> indeed, I don't have brltty installed
<pitti> Unit193: where "sounded" means "stopped", or "it sounded differently"?
<Unit193> pitti: Sounded = the system made the beep.
<pitti> Unit193: interesting; so I don't have brltty installed and don't hear a beep; but that might also be because my notebook might not have a PC speaker (or whatever beeps there)
<pitti> Unit193: so you get this as well?
<Unit193> pitti: Yes I do, but I can't technically comment as I'm using trusty and a slightly custom setup.  Might get it on the netbook, I don't remember.
<pitti> Unit193: so if you install brltty the beep goes away? that'd be a very interesting data point indeed
<pitti> would be interesting to compare boot/syslogs with and without brltty, etc.
<RAOF> Bah! Why does --shell-fail never actually spawn a shell on failure :(
<richardus> ls
<pitti> RAOF: it's certainly supposed to, I'm using it all the time; except for bug 1317078, are you using --output-dir?
<ubottu> bug 1317078 in autopkgtest (Ubuntu) "--shell does not work with --output-dir" [Medium,Triaged] https://launchpad.net/bugs/1317078
<RAOF> pitti: Maybe it doesn't work with the lxc container method?L
<pitti> adt-run:  - - - - - - - - - - running shell - - - - - - - - - -
<pitti> root@adt-virt-lxc-wpfpjv:/tmp/adt-virt-lxc.shared.mXhWW7/downtmp/ubtree0-build/real-tree#
<pitti> RAOF: hm, works here; can you please file a bug with the exact command you are calling?
<RAOF> pitti: Sure.
<pitti> $ ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -es adt-utopic
<pitti> RAOF: I used that
<pitti> RAOF: sorry, where ./run-from-checkout  == adt-run
<RAOF> Hm. You don't need root?
<pitti> I'm aware of --output-dir messing things up (need a better way to find the real stdout/err with output redirection)
<pitti> RAOF: lxc's -s switch calls lxc through sudo
<RAOF> Ah.
<pitti> $ sudo ./run-from-checkout --shell -B ~/ubuntu/tmp/testpkg// --- lxc -e adt-utopic
<pitti> works as well, though
<pitti> RAOF: does it have any error message, about /dev/stdout blabla not found, or similar?
<pitti> you should at least get the "- - running shell" bit
<RAOF> pitti: I'll try that command again and get some clean logs.
<Unit193> pitti: Nono, if I *purge* brltty, the system will beep because it's stopping the service before removal.
<pitti> Unit193: do you also get it beeping when rebooting if you have brltty installed?
<Unit193> Yep.
<pitti> Unit193: nice, that sounds exactly like bug 1316804 then
<ubottu> bug 1316804 in systemd (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Confirmed] https://launchpad.net/bugs/1316804
<Unit193> My point exactly.
<pitti> brltty has a systemd unit, I wonder if this behaves any different than the init.d one; it does not have an upstart job
<pitti> brendand: could you try rebooting or purging with removing /lib/systemd/system/brltty.service ?
<pitti> sorry, Unit193 ^
<pitti> Unit193: this might even be something semi-deliberate, like indicating to the blind user that brltty  is starting/stopping/etc.
<pitti> but certainly not supposed to happen on reboot
<TheMuso> pitti: In the init.d script for brltty, we set thigns up via /etc/default to disable brltty by default way back, as it leaked memory. Not sure if it does any more, but most people do not need it running by default, and it runs sytem wide so is a security issue, which really needs fixing anyway.,
<pitti> aah!
<pitti> RUN_BRLTTY=no
<pitti> we don't start it by default
<TheMuso> No.
<TheMuso> Scripts were written for the installer to enable it explicitly if a user requests it.
<pitti> TheMuso: right, that'd explain it then -- brltty is causing the beep as a kind of notification, and as we never started it in the past few people noticed
<TheMuso> Longer term, brltty needs to become a user session service.
<TheMuso> But thats a whole ball of wax.
<Unit193> pitti: Added brltty back, and service brltty stop does make the beep.
<pitti> TheMuso: so in the short term, the systemd unit should probably read the /etc/default file?
<pitti> Unit193: thanks for confirming
<TheMuso> pitti: Or however is best to implement stuff. I am happy to change things elsewhere to tweak things however they need to be for systemd units...
<Unit193> pitti: No problem!
<TheMuso> pitti: i.e if we want to move away from /etc/default, now is as good a time to do so.
<pitti> TheMuso: I mean, it is intended to not run brltty by default?
<TheMuso> pitti: Correct, we do want to keep that behavior.
<pitti> TheMuso: yeah, enabling/disabling services with default files works really badly with the unit model, so we need some hacks if we want to continue using default files that way
<TheMuso> Debian runs it if brltty is installed, so this is an Ubuntu change which I am happy to keep.
<TheMuso> pitti: I am happy to adopt whatever better method for systemd units there is.
<pitti> TheMuso: the usual way is to enable/disable services using "systemctl enable" (or disable)
<TheMuso> pitti: Ok, sounds clean enough.
<pitti> TheMuso: I'm interested in why we install brltty by default but not enable it; most packages are enabled on installation
<pitti> TheMuso: do we have that so that you can enable/disable brltty in the live environment, i. e. the package shoudl be installed always?
<pitti> TheMuso: anyway, I'll adjust the unit file; we do the same in whoopsie
<TheMuso> pitti: If the user has a USB display, brltty is also activated via udev.
<TheMuso> The only time the user needs to explicitly enable brltty is if they use a serial or bluetooth display. Mind you the bluetooth setup is not done through the GUI...
<pitti> it looks odd in systemctl status as brltty will appear as "failed" when disabled, but can't help that for now
<pitti> TheMuso: ah, thanks for the heads-up
<pitti> xnox: so, mystery solved for bug 1316804 :)
<ubottu> bug 1316804 in brltty (Ubuntu) "loud pc-speaker like beep when rebooting under systemd" [Undecided,Triaged] https://launchpad.net/bugs/1316804
<TheMuso> pitti: Thanks. Long term brltty needs to be beaten into submission as a user session service.
<TheMuso> Too much stuff still runs as root for blind/vision impared users.
<TheMuso> And that needs to change.
<pitti> TheMuso: *nod* until then we'll just need to live with the unit appearing as "failed" when it's disabled; mostly cosmetical
<TheMuso> If it weren't for users demanding braille, I'd chcuck brltty out of main... I dare say an audit would find many a security hole...
<TheMuso> Its one of those packages thats been in main from the beginning, and probably really hasnt' had a proper going over, and has changed internally a fair bit over the years.
<pitti> TheMuso, xnox, Unit193: I uploaded https://launchpad.net/ubuntu/+source/brltty/5.0-2ubuntu3 which ought to fix the beep (more precisely, respect the /etc/default/brltty file)
<dholbach> good morning
<TheMuso> pitti: Ok thanks.
<mardy> cjwatson: hi! Do you know if the user click hook "Exec"'d processes have access to the D-Bus session? Looks like that when I run them with "sudo click install..." they don't, but I wonder if they do when an app is installed via the UI
<pitti> RAOF: so each ../../client/cd-create-profile takes some 20 minutes or so; I wish they'd parallelize :)
<RAOF> They're trivially parallelisable, but if you --enable-print-profiles each one takes over a GiB of memory, so upstream disabled parallel building there :)
<pitti> ah, makes sense
<RAOF> On the basis that eating ~20GiB of RAM isn't going to be particularly conducive to exploiting your cores :)
<brendand_> pitti, i myself have the problem with bltty
<brendand_> pitti, i was ignoring it so far
<pitti> brendand_: oh, are you also already running with systemd?
<brendand_> pitti, at least the symptoms match xnox's
<brendand_> pitti, i am
<pitti> brendand_: wow
<pitti> brendand_: I mean, I sometimes get the wrong addressee in IRC pings, but I never actually happened to pick someone who was affected by the very same topic :)
<pitti> brendand_: you are running it because you are interested, or still a leftover from last week's sysvinit debacle?
<Unit193> pitti: Netbook thinks it's a good idea to make a loud beep when you unplug it or plug it in. >_<
<brendand_> pitti, leftover - i guess i can remove it now?
<pitti> brendand_: well, not remove in the package sense, but disable again if you want
<brendand_> pitti, yeah - i mean remove the init= from grub
<pitti> yes
<pitti> brendand_: make sure you are fully updated, though :)
<brendand_> pitti, yeah i thought of that :)
<pitti> RAOF: OOI, are the color profiles arch dependent?
<RAOF> pitti: No, they're not. I've picked the low-hanging fruit there (--enable-print-profiles is only passed when building arch-indep), but with a little extra work I could not build the rest when building arch-indep.
<pitti> RAOF: they are so small, it almost seems like an upstream  release ought to ship them pre-generated, similarly to HTML documentation :)
<RAOF> pitti: They get translations merged in at build time. Otherwise, yeah.
<pitti> with appropriate .icc : .xml rules so that they are rebuilt on modifications
<pitti> RAOF: ah, ok
<pitti> they are just 4 KB, didn't look like they'd have much stuff in them
<RAOF> I mean, they still could be generated at release time, but then we'd need to do some magic if we wanted to do translation bugfixes...
<pitti> RAOF: ideally they should depend on the .po files too, so if you patch those the profiles should just get rebuilt; but yes, theory :)
<LocutusOfBorg1> xnox, you there?
<LocutusOfBorg1> may I know if this package is suitable for debian? https://launchpad.net/ubuntu/+source/mediascanner
<LocutusOfBorg1> also this one https://launchpad.net/ubuntu/+source/lucene++
<LocutusOfBorg1> is needed in the new poedit upstream release
<LocutusOfBorg1> we might benefit from uploading directly in debian and then autosync, right?
<ekarlso> apw: u around boss ? :)
<dholbach> salut didrocks - Ã§a va?
<didrocks> dholbach: Ã§a va bien, et toi ?
<dholbach> didrocks, trÃ¨s bien, merci! :-)
<dholbach> didrocks, t'as un petit peu de temps la prochaine semaine de parler un peu de "how contributions make it into Ubuntu"? :-)
<lool> stgraber: Added SRU information to LP #1310715, thanks
<ubottu> Launchpad bug 1310715 in ubuntu-touch-meta (Ubuntu Trusty) "Provide final 14.04 frameworks" [High,New] https://launchpad.net/bugs/1310715
<dholbach> didrocks, I was thinking we could do a session together at Ubuntu Online Summit - I could talk a bit about "getting a fix for a package in" and you could talk a bit about how a fix for some touch project makes it onto an image?
<didrocks> dholbach: I'm not in charge of the touch project CI process anymore. I can still talk about it, but I would prefer just to "participate" to the session to not bringing confusions on who is now in charge :)
<didrocks> dholbach: sil2100, robru are the ones leading this now
<dholbach> ok cool - thanks didrocks :)
<didrocks> yw ;)
<dholbach> didrocks, any other session you'd like to give? either demo or discussion sessions are fine (http://fridge.ubuntu.com/2014/05/28/calling-for-ubuntu-online-summit-sessions/) :-)
<didrocks> dholbach: I need to think about it, having filed and abused the schedule a lot in the past, not sure I have anything valuable to discuss (yet). I'll follow and participate mostly to the cloud devops sessions at least
<ricotz> hello :), is there a reason why there are no trusty daily iso-builds? (like it is done for precise)
<dholbach> didrocks, ok cool
<mlankhorst> chrisccoulson: that would be me, but that bug seems hard :P
<chrisccoulson> mlankhorst, yeah. I have absolute faith in you though :)
<pete-woods> mardy: hi, was wondering if you'd heard anything regarding the Vimeo API bug?
<mardy> pete-woods: yes, they acknowledge the bug, and said they'll fix it soon
<pete-woods> mardy: cool, thanks :)
<mardy> pete-woods: I'll forward you their email
<pete-woods> cheers
<mardy> pete-woods: done
<xnox> LocutusOfBorg1: lucene++ probably yes, but it FTBFS in ubuntu at the moment. I don't think mediascanner would be useful in Debian, as development has moved on to mediascanner2 and it is at the moment Ubuntu specific package (needs unity scopes/gallery to consume scanned media)
<dholbach> sil2100, how are you doing? do you think you'd have some time during UOS next week to give a demo session together with me? (I talked about it with Didier above already) :)
<sil2100> dholbach: hey! Let's have a chat in some moments :)
<dholbach> sil2100, rock and roll :)
<pete-woods> mardy: as a further question, now I've upgraded to utopic, I just get a black pane instead of the embedded browser in the online accounts settings, is this something you're aware of?
<mardy> pete-woods: on the desktop?
<pete-woods> mardy: yes
<pete-woods> hmm, I don't seem to have signon-ui installed
<mardy> pete-woods: yes, that's certainly the issue
<pete-woods> mardy: bit strange that it's not installed by default
<pete-woods> installing it makes all happy again, though :)
<seb128> pete-woods, what is not installed by default and where?
<pete-woods> seb128: I just had to manually install signon-ui to get online accounts to work
<mardy> pete-woods: the last ubuntu-system-settings-online-accounts version can't be installed at the same time as signon-ui
<seb128> pete-woods, desktop or touch?
<pete-woods> this is on a pretty recent utopic desktop (last week)
<seb128> mardy, why not?
<seb128> pete-woods, http://cdimage.ubuntu.com/daily-live/current/utopic-desktop-i386.manifest
<seb128> signon-ui	0.16+14.04.20140304.is.0.15+14.04.20140313-0ubuntu2
<mardy> seb128: because on touch we merged the functionality of signon-ui into online-accounts-ui,
<seb128> pete-woods, it's installed by default ... maybe you got it uninstalled when you tried to install some touch component?
<mardy> seb128: and we would have a conflict when installing the d-bus service file
<seb128> mardy, how is that going to work for people who install unity8 on their desktop next to unity7?
<mardy> seb128: I'm afraid it will break online accounts on unity7 :-(
<pete-woods> seb128: could well be possible, I do have unity8 installed
<seb128> mardy, we need to fix that
<rbasak> stgraber: ah, it should be bug 1300991, sorry. I just copied the changelog straight from Debian. I should have checked it.
<ubottu> bug 1300991 in auto-apt (Ubuntu Trusty) "auto-apt update and updatedb commands fail on 0.3.23" [Undecided,Triaged] https://launchpad.net/bugs/1300991
<rbasak> stgraber: do you want to reject and I'll re-upload with a fixed changelog?
<seb128> mardy, otherwise pete-woods is going to be the first of a long serie of unhappy users
<mardy> seb128: I don't see an easy way to fix it... both packages want to install /usr/share/dbus-1/services/com.nokia.singlesignonui.service
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc
<rbasak> oops
<seb128> mardy, you could split that .service in its own binary and have both ui depending on it
<mardy> seb128: maybe we could make the service file launch a shell script, that decides which binary to launch based on environment variables
<Laney> is the service somehow linked to the frontend?
<seb128> mardy, right, or you can do that check in the .service itself, we used to do that for notify-osd
<mardy> Laney: yes, the service implementation is a UI component
 * mardy goes and has a look at notify-osd
<mardy> seb128: "used to do that", means you don't do that anymore?
<mardy> seb128: found it in version 0.33, thanks
<seb128> mardy, yw!
<seb128> mardy, yeah, I think we dropped that logic, we just use notify-osd when installed now
<mardy> seb128: OK, that sounds like a viable solution; I'll work on that
<seb128> mardy, thanks
<apw> ekarlso, hi ?
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Utopic boot fixed in sysv-rc 2.88dsf-41ubuntu15, boot with init=/lib/systemd/systemd until then | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patc
* pitti 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch pilots: pitti
<mardy> seb128: how would you detect that we are running on unity8? I see "QT_QPA_PLATFORM=ubuntumirclient" in the env variables, would it be OK to use that?
<seb128> Saviq, ^ do you know?
<seb128> mardy, I guess that works, or you could just check for XDG_CURRENT_DESKTOP=Unity and assumes that's unity7
<mlankhorst> why do you want to detect it?
<mardy> mlankhorst: to know whether the D-Bus service should popup the desktop UI or the touch one
<Laney> it's =Unity on touch too
<mardy> Laney, seb128: I'll use the QT_QPA_PLATFORM then
<Laney> mardy: You could check DESKTOP_SESSION is ubuntu-touch or unity8*
<mlankhorst> mardy: but can't you try to pop up the touch one, if that fails fall back to desktop one?
<infinity> mardy: If you're using unity8 == touch, that's going to end in tears when unity8 is the default on the desktop too...
<seb128> infinity, depends what you call "touch"
<seb128> we want the new UI in unity8-desktop as well
<mardy> mlankhorst: the problem is that the touch one will run on the desktop, but it can't be embedded in the unity-control-center (using XEMBED)
<ogra_> we'll just ship touchscreens with the images
 * infinity mumbles something about convergence.
<seb128> infinity, well, "touch" is going to be used on desktop as well
<infinity> seb128: But not the same UI, obviously.  Is it all screen-size/form-factor autodetecty yet?
<mardy> infinity: the point is not about convergence; it's that we have two different implementations, for unity7 and unity8, and from the D-Bus .service file we need to decide which one to pop up
<ogra_> infinity, far from that ...
<Fudge> running Mangler in gdb, if it dies like it has been do I just run bt to give to you guys?
<mardy> infinity: eventually, we'll use the unity8 one on all form factors
<Fudge> oops sorry wrong channel
<ogra_> infinity, but as i understood the lightning talk about it it should anyway be use-case driven ... based on available input/output devices
<Laney> the QPA_PLATFORM thing seems like it might be an implementation detail which might not be reliable
<ogra_> that will only tell you you are running Mir
<ogra_> (or X11 or surfaceflinger)
<ogra_> wont tell you anything about what device you are on
<seb128> infinity, well, we have a "new UI" and "legacy UI", ideally the legacy UI is going away, but we still need it for Unity7 because that doesn't have Mir, etc
<pete-woods> tvoss: as my go-to C++ guy, do you have a recommendation for doing base64 encoding in C++? doing it with boost seems really unweildy
<seb128> infinity, so that's not a case of detecting form factor, just a case of keeping something working for unity7 until our desktop has the techs needed to run the new UI
<infinity> pete-woods: http://stackoverflow.com/questions/342409/how-do-i-base64-encode-decode-in-c
<infinity> pete-woods: Might have a few decent pointers.
<infinity> pete-woods: If you happen to already have openssl or glib in your dependency tree, both have base64 functions.
<pete-woods> I was hoping to avoid implementing my own encoder, glib is sounding like the best option so far, as the C++ ones aren't in main
<cjwatson> mardy: No, I wouldn't expect them to have access to it, and design-wise I think I'd prefer that they didn't assume that
<mardy> cjwatson: OK, that's fine
<infinity> pete-woods: Or just snag a copy of the coreutils one from the source or something.  It's not lkike base64 is complicated, any mature codebase will have had a bug free implementation for ages that you can steal and run with if you want to avoid pulling in a whole library just for it.
<cjwatson> ricotz: I've been holding off on switching on trusty builds because there's only a single builder per architecture at the moment and so it's easy for contention to get pretty bad; I'm hoping that I'll be able to land the livefs-in-LP work before we desperately need trusty image builds in preparation for 14.04.1
<pete-woods> infinity: part of the purpose of what I'm writing is to provide an example scope, I really don't want to say, hey you're going to have to implement your own base64 encoder just to do OAuth in your scope
<infinity> pete-woods: Oh.  Perhaps an oauth library that does all the heavy lifting is what's wanted here, if it's something more than one scope is likely to want.
<pete-woods> infinity: I already have an OAuth lib doing the basic case, but this API also needs a header encoding in a specific way
<infinity> Ahh, indeed, liboauth is in main.  I guess it doesn't do the base64 stuff you need, though.
<infinity> Oh, but it depends on libnss, which is also likely to have a base64 implementation hiding in it.
<infinity> Cause pretty much every crypto library has to.
<infinity> pete-woods: /usr/include/nss/base64.h from libnss3-dev looks promising.
<infinity> pete-woods: (Assuming you're using liboauth anyway, you already have libnss3... But maybe you're using a different oauth lib)
<shadeslayer> mhall119: btw you're working with the SDK team right?
<infinity> pete-woods: Oh, nssb64.h is more complete (same source)
<pete-woods> infinity: cool, thanks, right now I'm happy to take just about any library in main that doesn't involve introducing a big lump of boilerplate code
<infinity> pete-woods: Well, my usual M.O. there is to check your current dep tree and see if something in it can solve the problem.
<infinity> pete-woods: So, if you're using liboauth, libnss is a slam dunk.  If you have glib for some other reason, same argument.  Etc.
<infinity> pete-woods: But it's pretty hard to write something meant to talk to the intertubes that doesn't use NSS, OpenSSL, or GnuTLS, and all three should have base64 goop to abuse.
<pete-woods> yep
<LocutusOfBorg1> thanks xnox
<LocutusOfBorg1> are you working on fixing the FTBFS?
<LocutusOfBorg1> I would like to upload in debian, just to pass the new queue
<LocutusOfBorg1> otherwise poedit won't be uploaded
<xnox> LocutusOfBorg1: go ahead with uploading to Debian, but check if it builds there.
<ricotz> cjwatson, hi, thanks for the clarification, looking forward to them to be available
<xnox> LocutusOfBorg1: i'm not working on resolving bugs in lucene++ at the moment, as the plan was to remove it from the archive, once mediascanner is dropped.
<LocutusOfBorg1> xnox, mmm and for poedit?
<LocutusOfBorg1> it needs lucene++
<xnox> LocutusOfBorg1: if it's reintroduced, that's fine.
<LocutusOfBorg1> sil2100, you there?
<LocutusOfBorg1> agreed xnox I understand
<LocutusOfBorg1> so I would like to know if sil2100 would like to maintain in debian too
<sil2100> Hi!
<LocutusOfBorg1> Hi sil!
<LocutusOfBorg1> I think you already got some mails to the poedit adopter
<LocutusOfBorg1> :)
<LocutusOfBorg1> do you mind uploading in debian?
<sil2100> LocutusOfBorg1: so, hm, I need to browse through my mailbox since I can't remember this well enough, but I could pick up maitaining the packaging for lucene++ in Debian if anything
<sil2100> If that's needed
<LocutusOfBorg1> yes, would be nice
<LocutusOfBorg1> just put the version on mentors and sync on ubuntu
<LocutusOfBorg1> you will simplify a LOT the packaging of the new poedit
<LocutusOfBorg1> sil2100, Timur is the person who wants to adopt poedit
<sil2100> LocutusOfBorg1: ok, will try doing that this week :)
<LocutusOfBorg1> wonderful :)
<LocutusOfBorg1> great thanks!
<Timur> yes, thanks a lot
<GunnarHj> rbasak: Did you see the dpkg-divert idea for skype-translation that infinity mentioned yesterday?
<rbasak> GunnarHj: I saw it but haven't had a chance to read it yet. If infinity says it's reasonable though, that's good enough for me.
<rbasak> GunnarHj: if you do exactly what infinity wants and he says it's good then I'm happy to upload it :)
<seb128> hum
<seb128> does anyone see an issue with that mountall translation?
<seb128> msgid "Checking disk %1$d of %2$d (%3$d%% complete)"
<seb128> msgstr "VÃ©rification du disque %1$d sur %2$d (avancementÂ : %3$d%%)"
<seb128>  
<seb128> I wonder why the % doesn't display in french on the plymouth screen
<GunnarHj> rbasak: Ok. I checked it out last night, and it seems to do the trick. Then I'll go on and make a new version and also addressing your questions on the bug report. Will ping you when done. :)
<rbasak> GunnarHj: great. Thanks!
<GunnarHj> rbasak: Thank _you_ for great sponsoring work!
<tseliot> seb128: hey, I've just made a merge request for the touchscreen issue, which I assigned to you (feel free to reassign). This is for 14.10. When we're done, I'll do the same for the SRU in 14.04: https://code.launchpad.net/~albertomilone/unity-settings-daemon/lp1287341-14.10/+merge/222011
<seb128> tseliot, thanks
<tseliot> yw
<Mirv> mitya57: qtwebkit finally building at https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+packages - I just needed to update ppc64el and arm64 symbols. dbarth has still some apparmor change brewing that will get to the same silo in addition to the already approved webbrowser-app branch, hopefully it'll be ready soon.
<dbarth> Mirv: well,apparently i can't change apparmor :/
<dbarth> Mirv: so it means i could switch to qtwebkit 5.2 for old webapps
<jjohansen> dbarth: what needs changed?
<dbarth> Mirv: but i can't transparently migrate them to oxide
<dbarth> the 1.0 webapp policy group
<dbarth> this one prevents oxide from being used, to ensure only qtwebkit is
<jjohansen> ah
<dbarth> so apparently no choice but to force (or wait for) eveyone to switch to 14.04 before i can turned down qtwebkit support
<Mirv> dbarth: can't as in won't be done? so then the only result is that we need slightly more testing and maybe some help to parse a list of apps not switched to 14.04 framework but using webkit
<dbarth> Mirv: so we can only get 1 of the 2 goals here: ie unblock qtwebkit 5.2, but i can't remove the dependency just yet (to help with the image size)
<jjohansen> dbarth: are we not phasing out the 1.0 webapp policy group?
<cjwatson> well, we probably needed a reason for somebody to work on deprecating the 13.10 framework anyway
<Mirv> qtwebkit 5.2 was tested to be quite good when Qt 5.2 landing was being made, so I don't expect huge problems unless some old webapp is using WebGL site
<dbarth> Mirv: jamie seemed to think that it was an interface change, so not acceptable for a framework meant to be all sealed by now
<Mirv> dbarth: ok
<BluesKaj> Hiyas all
<jjohansen> dbarth: hrmmm, I was actually thinking more along the lines of, if its deprecated how bad would it be to add oxide permission to it. But I will defer to jdstrand
<dbarth> jjohansen: and jdstrand was not so keen on doing that
<jjohansen> dbarth: right, I'll poke him in the morning so I can better understand his reasoning, thanks
<dbarth> jjohansen: i guess it's because it's not just changing one line in the webapp policy group (the one that says deny)
<dbarth> it's probably adding a whole lot in templates, to let the whole oxide process family be authorized
<jjohansen> right, I expected it would be more than that
<dbarth> something that only happened when 1.1 was designed
<jjohansen> ah
<dbarth> and the new webview policy group
<dbarth> cjwatson: yes, i'm happy to be that extra reason really
<mardy> seb128: I want to rename signon-ui to signon-ui-x11, and make both signon-ui-x11 and u-s-s-o-a "Provides: signon-ui"
<mardy> seb128: and both of them will depend on a new signon-ui-service package which installs the D-Bus service file
<mardy> seb128: does this sound reasonable? (I have another question after this :-) )
<seb128> mardy, yes, sounds reasonable
<seb128> mardy, be careful though, provides are not versioned, so if you have things depending on signon-ui (=> version) that's not going to work (you need an empty/dummy binary in that case)
<mardy> seb128: actually, this is my next question: signon-ui-service replaces a file from signon-ui (<< 0.17) and u-s-s-o-a (<< something), but I'm not sure how to encode this information
<mardy> seb128: for u-s-s-o-a I could add a Conflicts, I guess
<rbasak> mardy: https://wiki.debian.org/PackageTransition is a helpful reference for this sort of stuff, if that helps.
<mardy> seb128: but for signon-ui, will dpkg be able to handle it correctly, since the newest version will be a virtual package (unversioned)?
<rbasak> AIUI, Breaks+Replaces is preferred over Conflicts where possible, as it's less constraining on upgrade ordering.
<mardy> rbasak: that's useful, I'm reading it now
<seb128> mardy, I was going to point the url rbasak just shared
<mardy> rbasak: cool, I think that mine is case #5
<mardy> seb128: can I add you as a reviewer for the changes I'm about to propose about signon-ui and u-s-s-o-a?
<evfool> hey all, do we know about Gnome apps in utopic? I know apps using headerbars have been rejected for trusty LTS, will this change for utopic?
<seb128> mardy, sure
<seb128> evfool, we don't know yet, larsu and Trevinho are working on making those work under Unity
<mardy> seb128: done: https://code.launchpad.net/~mardy/signon-ui/signon-ui-service/+merge/222017 and https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/signon-ui-service/+merge/222016
<seb128> once GTK and Unity are improved, we need to revisit the impact on the usability
<evfool> seb128: ok, thanks
<seb128> evfool, it's fine to update things that are not the ubuntu-desktop, knowing that you are making some user experience miserable on the way
<seb128> but that's an upstream issue, not a lot we can do for those who care only about gnome-shell users
<seb128> mardy, the changes look fine technically but there is an issue that u-s-s-o-a is in universe so you can't make signon-ui-x11 depends on a binary built from it, you are going to need to do it the other way around and build the service from signon-ui
<mardy> seb128: uh, OK
<seb128> evfool, it would be nice, if as an upstream, you would support non gnome-shell environments for your software ;-)
<seb128> (just saw your comment on the bug)
<evfool> seb128: I don't want to start philosophical discussions here, I run system monitor 3.13.1 on Unity, and I'm satisfied, so System Monitor supports non-gnome-shell environments
<seb128> evfool, it's using GtkHeaderBar? Can you move/resize the window?
<seb128> I can't here
<seb128> not sure what is different in your session though
<evfool> seb128: I'll have to check when I get home though, but I'm almost sure I would've noticed if I couldn't
<seb128> because not having decoration/borders, not being able to resize or move the dialogs is the known state under several non shell environments, including Unity (which we are working on fixing)
<evfool> seb128: I was only aware of some XFCE issues, which I don't understand, as I am also able to run System Monitor with headerbar under XFCE
<seb128> evfool, the xfce issue is the inverse, you would likely get double decorations
<seb128> the headerbar and a wm bar
<mardy> seb128: about your remark on Conflicts/Replaces/Provides: I think that my case is very close to #5 here: https://wiki.debian.org/PackageTransition
<seb128> evfool, like https://lh4.googleusercontent.com/-YlXpA1jR3O0/UpMsjN5c_OI/AAAAAAAAAXo/ZKPUsRLr-5s/w480-h500-k/xfcecalc.png
<evfool> seb128: btw, I have spent quite a few hours trying to figure out a solution for a UI working both with and without a headerbar, but it turned out that I would have to duplicate lots of code
<seb128> evfool, yeah, GNOME put developers in a tricky situation, basically you have different platforms there so you can't do well with one simple codebase
<seb128> mardy, oh, so you keep an empty "signon-ui" binary as transitional?
<mardy> seb128: yes, because we have some packages depending on it, and I'll make both signon-ui-x11 and u-s-s-o-a provide "signon-ui"
<seb128> mardy, provides != transitional package
<seb128> transitional would be a binary listed in debian/control with no content but a Depends: new-binary
<mardy> seb128: ah, no, then it's not a transitional package
<mardy> seb128: I guess I confused transitional with virtual
<seb128> mardy, so you are not in case 5, use C,R,P then
<mardy> seb128: OK, thanks
<seb128> yw
<evfool> seb128: yup, everyone has their ideas, GNOME had an idea, and the first implementation had some rough edges, but we've all been through this, I hope eventually GNOME and Ubuntu will be able to go down the road hand in hand, even with this convergence madness involved
<seb128> evfool, I doubt the GNOME solution is ever going to work great for other desktops, they are making design choices that are meant to integrate with their "OS"
<xnox> evfool: cinnamon, mate, lxqt started in part due to GNOME coding against gnome-shell only. How to achieve working hand in hand?
<seb128> evfool, you can't really assume that GNOME UI = Ubuntu UI and that you can do well on both environment without at least runtime checks and tweaks
<evfool> seb128: yes, that's true, runtime checks and tweaks would be fine for me, but last time I checked, it involved serious code duplication
<evfool> and I wanted to avoid that
<seb128> well, you can't get your cake and eat too there...
<seb128> you have 3 choices
<seb128> 1- don't use GtkHeaderbar, and work everywhere (though being less integrated in the GNOME look)
<seb128> 2- use GtkHeaderBar and care only about gnome-shell users
<seb128> 3- duplicate code to support the different environments
<mardy> seb128: I updated those two MPs
<seb128> mardy, looking
<evfool> ok, if these are the only choices i choose 3, I don't like the first two, 1. because for me the headerbar is not only about the gnome look 2. because I'm also using ubuntu on several computers
<evfool> seb128: thanks for the discussion, I'll take another look at supporting non-shell environments, and hopefully will manage to improve the situation (resulting in system monitor 3.xx.xx upload in the utopic archives)
<seb128> evfool, 3 is a good option, I think that's mostly where we are heading anyway
<seb128> evfool, thanks for looking at the issue, sorry that those design decisions from GNOME/us is making things more difficult for you as an app writer
<seb128> we are looking at making header bars working better under Unity
<seb128> but they are still going to feel inconsistant and different from others using the wm decorations
<evfool> seb128: I saw the progress from the initial implementation (from only close button to supporting the buttons set in gsettings), so I feel like the situation is improving, and yes, the headerbar apps will look different compared to other apps, just like skype does, or acrobat, or eclipse, or firefox
<seb128> none of those look different from the menubar perspective atm
<seb128> but yeah, which is why I said earlier that it's up to the app writer to have their app looking different or not
<seb128> we are just blocking the ones in the default unity set atm
<evfool> seb128: yes, the menubar is the same, but look at theming widget looks, etc.
<seb128> because we don't want inconsistency in our default installation
<evfool> seb128: ok, I understand that
<seb128> where we can avoid it
<seb128> (like we need it for e.g firefox or libreoffice)
<jdstrand> dbarth, jjohansen: the one line change isn't the issue per se. it is the 'webview' policy group that no 13.10 webapp currently has because it didn't exist at the time which all 14.04 and higher webapps have
<jdstrand> dbarth, jjohansen: the webview policy group is actually fairly extensive. just adding the policy group to the policy isn't enough, because the 13.10 framework webapps won't already have it so would have to be adjusted anyway
<jjohansen> okay
<jdstrand> dbarth, jjohansen: I could technically add it to the ubuntu-webapp template, but then it is likely that an app running on an actual 13.10 device won't work. plus, I would need to update the ubuntu-sdk template for apps that use ubuntu webviews)
<jdstrand> dbarth, jjohansen: this is extremely disruptive from a policy point of view, and one of the reasons why we have frameworks in the first place. if we are just going to retroactively fix everything going forward, there is little point in having a framework
<jdstrand> dbarth, jjohansen: finally, apparmor-easyprof-ubuntu is currently backported into at least one (if not more ppas) for the sdk and these changes could be problematic there if people are using the ppa on a 13.10 system and testing the 13.10 framework
<jdstrand> could this be done? yes, but it would be a distraction and throwaway work
<jdstrand> (imo)
<jdstrand> if we really want to continue supporting the 13.10 framework, then let's actually do it-- ship the qtwebkit 5.1 somewhere where the webapp container can find it. if not, obsolete the framework and get the framework definition off the device. the webapp authors will update their webapps so the webapps show up ion the store and on the device again
<jdstrand> and as Colin pointed out, that is work that we need to figure out how to do anyway. IMHO it is wise to do it now when we can afford to make mistakes/learn things when there are no shipping phones
<mardy> seb128: thanks a lot for the reviews!
<seb128> mardy, yw, thanks for the fixes!
<shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kapptemplate/1/ARCH=amd64,label=adt/console fails just because no tests were found?
<pitti> shadeslayer: right
<shadeslayer> huh
<pitti> shadeslayer: this usually indicates some packaging error (wrongly copy&paste'd XS-Testsuite, or typo in debian/tests/control, etc.)
<pitti> we treat this as error to detect these
<dbarth> jdstrand: ok, nw; i'll keep qtwebkit support for now
<mlankhorst> chrisccoulson: good news, I know what's wrong with webapps, bad news, it's hard to fix
<dbarth> jdstrand: the problem will solve itself since we don't accept 13.10 apps anymore
<shadeslayer> pitti: ok
<dbarth> mlankhorst: what's up with webapps?
<mlankhorst> I'm guessing the different places that use opengl
<mlankhorst> simultaneously
<mlankhorst> I'll try something dumb first, maybe I'll get lucky
<cjwatson> Noskcaj: expat sync: best to actually check the diff, as in this case the Debian maintainer said they'd applied the dh-autoreconf patch in the changelog but did not in fact do so.  I'm fixing it up for you
<cjwatson> dholbach: ^- cc as the sponsor
<dholbach> cjwatson, urgh... sorry about that
<cjwatson> have also reopened the Debian bug
<dholbach> thanks a lot for taking care of all of this
<cjwatson> np
<mlankhorst> hm hack works
<mlankhorst> by not calling flush in swapbuffers
<mlankhorst> and doing something even more evil
<nectarys_> I'm trying to abitye myself with the linux environment (am a developper). what kind of distribution do you advice me to abitye myself with, please?
<cjwatson> (abitye isn't a standard English word.  Google suggests Haitian for "cope", which wouldn't quite fit but I think I know what you mean ...)
<cjwatson> If you ask in an Ubuntu development channel then I think you can expect people to suggest that you use Ubuntu :-)
<pitti> "appetite"? :)
<brendand> Arch, arch, arch!
<ogra_> lol
<brendand> cjwatson, 'familiar' is also suggested
<brendand> cjwatson, which makes sense
<brendand> almost
<ogra_> familiar was a nice distro :)
<brendand> ogra_, not what i meant
<ogra_> might have become hard to find the matching hardware for it nowadays though :P
<ogra_> brendand, i know ;)
<brendand> just googled it
<brendand> interesting
<brendand> ubuntu touch for 20 years ago :)
<ogra_> yeah :D
<cjwatson> ah yes, familiarise would fit
<nectarys_> brendand, why Arch :p ?
<brendand> nectarys_, because i'm being facetious
<brendand> which is mostly why anyone suggests arch
<nectarys_> brendand, doesn't it take too long to configure ?
<brendand> nectarys_, yes!
<brendand> nectarys_, ignore us all and just use ubuntu
<chrisccoulson> mlankhorst, yay \o/ ;)
<mlankhorst> it has the nasty side effect of breaking other things that worked before, though..
<mlankhorst> hm i might be able to make things work, but it would require updating libdrm :/
<Laney> @pilot in
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch pilots: pitti | Patch Pilots: Laney
<seb128> woot, between dholbach pitti and Laney the sponsoring queue is going to be empty tonight ;-)
 * pitti ^5s dholbach
<pitti> but will have to stop soon :/
 * dholbach hugs Laney, rbasak, seb128 and pitti
<Laney> ha
<dholbach> I just did a very few entries today :)
<Laney> I'm not the fastest sponsor ever
<pitti> but it just lost some 20 entries, I think that's a glitch
<pitti> I've seen the sponsoring queue missing two dozen entries at times, and some minutes later they came back
<pitti> last time I reloaded we had 65
<pitti> oh, and now it's indeed back to 63, nevermind
<Laney> I'm looking at the grilo branches
* pitti 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney, pitti
 * Laney nods Mirv 
 * pitti fixes the duplicate patch pilot topic entry, seems I didn't get it quite right this morning (it got truncated)
<seb128> xnox, hey, could you push https://code.launchpad.net/~xnox/unity-control-center/utopic/+merge/216962 manually to trunk?
<mlankhorst> Laney: hm didn't you file a bug about webapps too?
<Laney> umm did I file it?
<seb128> what about those?
<seb128> oh, nouveau issue
<Laney> yeah
<Laney> mlankhorst: I think you told me it was https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1300411
<ubottu> Ubuntu bug 1300411 in xserver-xorg-video-nouveau (Ubuntu) "Xorg crashed with SIGSEGV in pushbuf_flush()" [Medium,New]
<pitti> @pilot out
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<mlankhorst> Laney: ah right, there seems to be a webapps bug now, but the fix is not going to be fun :p
<xnox> seb128: in-progress
<xnox> seb128: done.
<seb128> xnox, thanks
<mhall119> shadeslayer: yes I work with the SDK guys, why?
<shadeslayer> mhall119: I wanted to get an update on the Qt 5.3 status, but it was posted on the ML a few minutes ago, so it's all good :)
<mhall119> shadeslayer: great
<rbasak> Do I need to run update-maintainer on an SRU with no Ubuntu changes (but with an ubuntu version number since it's an SRU)?
<rbasak> It's a straight rebuild of a more recent version from Debian, since the only thing changed in sid is a fix for the bugs being SRUd
<shadeslayer> rbasak: why not a sync then?
<shadeslayer> unless that's not possible
<rbasak> shadeslayer: I didn't think that's possible because the version is already published in Utopic, and we presumably want a rebuild for Trusty.
<rbasak> Since publishing binaries in Trusty built on Utopic would probably not be a good idea (I'm guessing)
<rbasak> So I've modified the changelog (and only the changelog).
<mdeslaur> cjwatson: I'm stealing the chkrootkit merge from you
<shadeslayer> rbasak: hm, I am unsure how that could be handled, best to ask someone in -release I guess
<cjwatson> mdeslaur: ah, yeah, be my guest
<cjwatson> rbasak: I don't personally think it's necessary to run update-maintainer, but wouldn't reject it if you did
<cjwatson> And yeah, we generally wouldn't copy backwards like that
<cjwatson> The only exceptions are when rebuilding is hard for some reason and we can be sure that the result doesn't depend on anything interesting from the host system - so the only case I'm aware of is shim/shim-signed
<cjwatson> In that case not so much that rebuilding is hard but that it's expensive when the checksum changes
<rbasak> cjwatson: OK, thanks!
<rbasak> stgraber: auto-apt re-uploaded to trusty-proposed with the LP bug reference fixed. Sorry about that.
<stgraber> rbasak: np
<cjwatson> doko: hm, is it a bug for the compiler to pollute the built-in namespace with "#define bool bool"?
<niemikorpi> what do you think about an idea of creating an own, chromium-based browser with npapi-support?
<cjwatson> doko: that is, "gcc -xc -E -dD /dev/null | grep -w bool" returns non-empty on powerpc but empty on amd64
<cjwatson> doko: this is the root cause of the haskell-gio build failure on powerpc/ppc64el; I can work around it but am interested in whether it's a compiler bug
<doko> cjwatson, from altivec.h:
<doko>    'pixel' and 'bool' as context-sensitive AltiVec keywords (in
<doko>    non-AltiVec contexts, they revert to their original meanings,
<doko>    if any), so we do not need to define them as macros.  */
<doko> #if !defined(__APPLE_ALTIVEC__)
<doko> #define vector __vector
<doko> #define pixel __pixel
<doko> #define bool __bool
<doko> #endif
<doko> so looks like intent =) however that wouldn't explain why you see it on powerpc
<seb128> xnox, do you see anything wrong in ""VÃ©rification du disque %1$d sur %2$d (avancementÂ : %3$d%%)"" (that's a mountall translations for "Checking disk %1$d of %2$d (%3$d%% complete)")
<cjwatson> doko: I'm seeing it defined to bool rather than __bool
<cjwatson> doko: It looks like the effect of /usr/lib/gcc/powerpc64le-linux-gnu/4.8/include/stdbool.h, but I wouldn't expect that to be included without asking for it?
<doko>   if (TARGET_EXTRA_BUILTINS)
<doko>     {
<doko>       /* Define the AltiVec syntactic elements.  */
<doko>       builtin_define ("__vector=__attribute__((altivec(vector__)))");
<doko>       builtin_define ("__pixel=__attribute__((altivec(pixel__))) unsigned short");
<doko>       builtin_define ("__bool=__attribute__((altivec(bool__))) unsigned");
<doko>       if (!flag_iso)
<doko>         {
<doko>           builtin_define ("vector=vector");
<doko>           builtin_define ("pixel=pixel");
<doko>           builtin_define ("bool=bool");
<doko>           builtin_define ("_Bool=_Bool");
<doko>           init_vector_keywords ();
<doko>           /* Enable context-sensitive macros.  */
<cjwatson> Hmm, maybe not, __bool_true_false_are_defined isn't there
<doko>           cpp_get_callbacks (pfile)->macro_to_expand = rs6000_macro_to_expand;
<doko>         }
<doko>     }
<xnox> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<xnox> seb128: seems resonable. Unless %%) is somehow parsed incorrectly whilst "%% " does the right thing
<seb128> xnox, let me try that, because the % part is missing in plymouth for some reason
<doko> cjwatson, $ gcc -E -dM - </dev/null | grep bool doesn't show anything on powerpc
<cjwatson> doko: oh, sorry, I'm testing on ppc64el after all
<cjwatson> identical haskell-gio failure on powerpc though ...
<doko> cjwatson, so yes, then I think this is expected. otoh, maybe we can raise it ...
<cjwatson> doko: I could probably just use --std=c89 then
<doko> yes
<Laney> stgraber: https://code.launchpad.net/~rcj/ubuntu/precise/libdumbnet/sru/+merge/221919 could you confirm/deny that you asked for this?
<stgraber> Laney: I can confirm but it's already been uploaded and is currently in precise-proposed
<Laney> oh okay
<Laney> let me get that merge proposal off the queue then ;)
<cjwatson> or maybe there's some way I can glue in cpphs
<doko>  * Adjust watch file to new hackage layout
<doko> ^^^ do you trust such packaging? ;-P
<seb128> xnox, no, adding a space doesn't fix it
<cjwatson> what's wrong with that?
<doko> "hackage" layout
<cjwatson> doko: http://hackage.haskell.org/
<cjwatson> not a typo
<doko> ahh
<doko> cjwatson, on powerpc I get the define only, if I explicitly add -maltivec
<cjwatson> doko: I think I'll just whack in --std=c89 for now and see if that fixes things across the board
<doko> cjwatson, or does ghc turn on altivec by default?
<cjwatson> er with one -
<cjwatson> doko: checked, doesn't seem to
<cjwatson> though who knows what lurks in the depths of that build system
<doko> yes, like all -f and -m options
<seb128> xnox, so, it doesn't like the ":" in the string
<cjwatson> oh for goodness' sake I can't pass in -std=c89 through the .cabal file.  Will have to hold nose and use -Ubool I think
<tseliot> seb128: shall I merge and upload the code myself now that you have approved it?
<seb128> tseliot, no, that's going through CI train, it's in https://launchpad.net/~ci-train-ppa-service/+archive/landing-014/
<tseliot> seb128: oh, nice, I had no idea that's how it works. Thanks
<seb128> tseliot, yw, thanks again for working on that!
<tseliot> seb128: yw. BTW shall I do the same for the SRU for 14.04?
<seb128> tseliot, did you want some feedback from utopic first?
<xnox> seb128: there is non-breaking space before ":" in your paste above (at least that's how it came through to me)
<seb128> xnox, of course, that's french :p
<xnox> seb128: sounds very weird though, as ":" isn't a special character in gettext.
<tseliot> seb128: not really, we have already done the testing on the limited use cases that we support. It was more of a matter of landing things in 14.10 first
<seb128> tseliot, ok, I can do the SRU upload as well
<xnox> seb128: is the trailing ) always printed? e.g. to eliminate the case where the translated string is simply much longer than "C" translation.
<tseliot> seb128: ok, I'll prepare the SRU then, thanks
<seb128> xnox, I did tweaks to the translations, like I changed it for "done %3$d%%" and it works "done : %3$d%%" and it stops working
<xnox> *sigh*
<seb128> tseliot, don't bother, I'm going to go through the CI landing as well
<seb128> tseliot, but if you could make the bug SRU compliant that would be nice (impact, test case, regression potentiel)
<tseliot> seb128: sure
<seb128> tseliot, thanks
<tseliot> :)
<dpm> pitti, could you enable the utopic langpack cron job? The export schedule in LP has now been updated
<tseliot> seb128: ok, the description should be fine now. Thanks again
<seb128> tseliot, yw!
<infinity> doko: Your binutils upload dropped my multiarch fix.
<nectarys_> i'm trying to connect a open my usb via virtualbox where i've launched Windows 7, but I wasn't able to find how. Does anyone know how to deal with, please ?
<Laney> @pilot out
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<rbasak> schroot can't remove /var/lib/schroot/mount/<session>. Any ideas?
<rbasak> Doing it by hand gives me "Device or resource busy", but I don't see it mounted, and lsof doesn't see anything inside it.
<rbasak> This might have happened because I forgot about the session and updated the chroot underneath it
<rbasak> Nothing in /proc/mounts that I can see.
<CodePulsar> Can I have two versions of Boost Libraries installed on the system?
<CodePulsar> i.e.  Boost 1.54 and 1.55 ?
<CodePulsar> I see if I try to install 1.55 it tries to uninstall 1.54 and all the application that depend on it including Ubuntu SDK
<brendand> anyone hitting a similar problem to this? http://paste.ubuntu.com/7590314/
<brendand> luatex : Depends: texlive-binaries (>= 2014) but 2013.20130729.30972-2build4 is to be installed
<brendand> is the gist of it
<ScottK> brendand: Probably a stale mirror.
<brendand> ScottK, i just have archive.ubuntu.com and gb.archive.ubuntu.com in my sources.list
<ScottK> Dunno.  The newer texlive-binaries is in uptopic.
<ScottK> utopic even
<ajmitch> at a glance, luatex was removed from utopic a couple of days ago
<nottheoilrig> i just launched an ubuntu ec2 image and ran aptitude install git
<nottheoilrig> Err http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ utopic/main git amd64 1:2.0.0-1
<nottheoilrig>   403  Forbidden
<nottheoilrig> what am i doing wrong?
<nottheoilrig> please let me know if theres a more appropriate irc channel for this
<sladen> nottheoilrig: you're not doing anything wrong; that archive mirror appears to be currently down
<sladen> nottheoilrig: you can edit /etc/apt/sources.list  to select another mirror
<nottheoilrig> okay thanks is there a web page with the status of the various ubuntu infrastructure?
<nottheoilrig> like https://status.github.com/
 * sladen traies to find it in https://launchpad.net/ubuntu/+archivemirrors
<nottheoilrig> status.ubuntu.com is a thing...
<mterry> Laney, you set bug 1325505 to won't fix?
<ubottu> bug 1325505 in ubuntu-system-settings (Ubuntu) "[regression][#60] cannot change greeter's background" [Undecided,Won't fix] https://launchpad.net/bugs/1325505
<sladen> nottheoilrig: I've reported that one machine being 403 to the sysadmin's tracking system;  There are several hundred more available though!
<sladen> nottheoilrig: see  https://launchpad.net/ubuntu/+archivemirrors
<sladen> nottheoilrig: or just change to to plain 'archive.ubuntu.com' for the moment
<sladen> nottheoilrig: status.ubuntu.com is actually for tracking bug process across the whole OS and application stack
<nottheoilrig> sladen: awesome thanks did you find a webpage with the status of eg http://us-east-1.ec2.archive.ubuntu.com
<sladen> nottheoilrig: https://launchpad.net/ubuntu/+archivemirrors
<sladen> nottheoilrig: probably https://launchpad.net/ubuntu/+mirror/us.archive.ubuntu.com-archive
<sladen> nottheoilrig: but I suspect that is served by several machines; one of which happens to be this one
<sladen> nottheoilrig: it says (in general) "last checked 15 hours ago"
<rbasak> sladen: #ubuntu-mirrors is the right place to ask this I think
<rbasak> I don't see anything in that channel topic though
<brendand> anyone running utopic can tell me what ' systemctl status cgmanager.service' returns for them?
<stgraber> root@lantea:~# systemctl status cgmanager.service
<stgraber> Failed to get D-Bus connection: No connection to service manager.
<stgraber> brendand: which is the expected result since we haven't switched to systemd yet and systemd obviously isn't running on that system
<brendand> stgraber, oh - but i am running systemd
<brendand> stgraber, i tried switching back earlier today and it messed everything up
<brendand> stgraber, like network-manager didn't start and lot's of other weirdness
<stgraber> brendand: then you're pretty much on your own then, we don't support doing that yet (pitti is working on it but it's very much work in progress)
<brendand> mterry, set it back to in progress. people should comment on status changes
<mterry> brendand, yeah...  I'll ask in bug for clarification too
<Laney> I blame the gremlins
<smoser> anyone know how
<smoser>  http://archive.ubuntu.com/ubuntu/pool/main/m/maas/maas_1.5.2+bzr2282.orig.tar.gz
<smoser> differs from
<smoser>  https://launchpad.net/ubuntu/+archive/primary/+files/maas_1.5.2%2Bbzr2282.orig.tar.gz
<smoser> (second is seen at https://launchpad.net/ubuntu/+source/maas)
<smoser> ugh.
<smoser> ugh. no it doesnt. ignore that
<lifeless> smoser: full marks :)
<sarnold> xnox,pitti, this seems like one for you guys, even though it says 14.04: 1326412
<RAOF> pitti: Huh, I seem to have lost backscroll. How did mips go?
<xnox> sarnold: hey, what's up?
<sarnold> xnox: bug 1326412 looks like it might be related to something you guys were working on in malta; I wanted to aim it your way in case you were working on a pile of these sorts of issues all at once :)
<ubottu> bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade" [Undecided,New] https://launchpad.net/bugs/1326412
<acrilex> hello, I just created my PPA on launchpad, and the package fail to compile with deps errors. can someone help me plz?
<acrilex> Here is the build log, it is long, but the most important should be at the end: https://launchpadlibrarian.net/176941630/buildlog.txt.gz
<sarnold> acrilex: this line looks most important: dpkg-source: info: fuzz is not allowed when applying patches  dpkg-source: info: if patch 'opengles' is correctly applied by quilt, use 'quilt refresh' to update it
<xnox> sarnold: looking at the package i'd think it's mvo or bmurray. Oh, wait. nah you can't do that yet.
<xnox> sarnold: we don't support a whole bunch of stuff when booted with systemd at the moment. One can't dist-upgrade, or even just install/upgrade a bunch of packages yet.
<sarnold> xnox: ah :)
<xnox> sarnold: hence all of us working on bringing systemd support flip between booting upstart & systemd at the moment (by tweaking init=/lib/systemd/systemd vs init=/sbin/init)
<acrilex> do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command)
<xnox> sarnold: i've added a tag "systemd-boot" which is what we use to track everything. and will comment in a second.
<sarnold> xnox: thanks!
<acrilex> do you think there is a fix I can apply to fix compile issue (this is launchpad buildbot, can't send him command)
<sarnold> acrilex: what does 'quilt pop -a ; quilt push -a' report in your local tree?
<acrilex> wait 1 sec, doing it
<acrilex> oh no! need to pull back project, it will take 1 minute
<acrilex> Patch opengles does not exist
<acrilex> who can I clean the patch from project and recreate it?
<acrilex> how*
<sarnold> acrilex: I don't know much about this end of things.. does 'bzr status' show anything unexpected?
<acrilex> I will repull the original one and redo my job! will be easier
<xnox> wgrant: barry: in lazr.restfulclient's test-suite, i think it should be possible to still use wsgi_intercept, but instead of serving lazr.restful test-app, serve a WSCGIProxy.spawning app (aka shim). That shim would fork python2 interpreter, and server lazr.restful using python2. But it should allow running a full python3 test-suite in the lazr.restfulclient.
<xnox> there are a few python3 compat things left unported in lazr.restulclient, so i'll tackle those first.
<barry> xnox: what are still left unported?
<xnox> and then work on the frankenstein (six) runner.
<xnox> barry: in your branch: still a few "except Exception, e" & it uses oauth, instead of oauthlib.
<xnox> barry: one can run a partial (non-lazr.restful dependant) test-suite under python3 and those things show up.
<xnox> (oh and a few import statements compats)
<xnox> I'll propose my work in progress branch to clean up those.
<barry> xnox: sounds great!
<xnox> Haven't done authlib port yet though. Should be easy (following your notes)
<barry> yep
 * barry -> dinner
<xnox> barry: the documentation on WSCGIProxy.spawn is sparse though. I hope it will work.
<xnox> (should be more straightforward than cjwatson's mock C functions in python via reverse python-gi)
#ubuntu-devel 2014-06-05
<cjwatson> xnox: Almost anything is more straightforward than that
<wgrant> xnox: Oh, nice, WSGIProxy is exactly what I thought we'd have to implement.
<pitti> Good morning
<Unit193> Howdy, pitti.
<RAOF> pitti: Aloha!
<pitti> RAOF: ah, I forgot to check again yesterday
<pitti> RAOF: so, it built fine
<pitti> RAOF: it took over 2 hours, and at some point it just dropped off my brain
<pitti> RAOF: do you want the debs/log/etc., or is "it builds" enough?
<RAOF> It builds is good for me.
<RAOF> Let me push a tag for you to upload.
<RAOF> pitti: debian/1.2.1-1 should be good to go to unstable. Let's get this transition on the road!
<pitti> RAOF: ah, soname bump?
<pitti> RAOF: hm, gbp-pull gives me nothing new
<RAOF> To git+ssh://git.debian.org/git/collab-maint/colord
<RAOF>    3045b6b..3719f1b  master -> master
<RAOF>  * [new tag]         debian/1.2.1-1 -> debian/1.2.1-1
<pitti> ok, so I was just blind, or gbp-pull didn't show me the new tag
<RAOF> pitti: Yeah, a bunch of deprecated symbols got dropped in the 1.2 series, making it libcolord2 et al.
<pitti> RAOF: quite impressive that on my box creating a profile takes ~ 20 seconds where on mips it takes about half an hour; I wasn't aware that these mips boxes were *that* slow..
<RAOF> It turns out that you can do a lot of computation with billions of transistors!
<infinity> pitti: Which mips box is that?
<pitti> infinity: gabrielli.debian.org (the porter box)
<infinity> pitti: The Cavium machine is pretty peppy, except for crappy I/O.
<pitti> ah, I stopped at the first "mips porterbox" on the db.d.o. page
<infinity> pitti: And gabrielli is the machine I was thinking of.
<infinity> pitti: Maybe I only think it's peppy, cause I build with -j16
<pitti> infinity: I built with -j8, but doesn't help much with colord as it doesn't parallelize the calculation
<infinity> The individual cores certainly aren't screamers (they're not meant to be, it's essentially a switch in a desktop case)
<pitti> it has 16 cores
<RAOF> infinity: Yeah, profile generation is explicitly serial, as each profile takes over a GiB of memory to compute.
<pitti> infinity: yeah, I used to have one of these d-link linux routers, they were quite nice to hack on
<infinity> RAOF: Ow.
<pitti> RAOF: uploaded
<RAOF> So the relevant performance indicator is IPC :)
<RAOF> Times clockspeed, obviously.
<RAOF> pitti: Much ta.
<infinity> pitti: I'd love someone to talk me into doing an Ubuntu MIPS port some day, but we'd need a whole lot of gabrielli-sized machines to make it go, I suspect.
<infinity> At least, to provide the same SLA people are currently used to in LP and whine about when it degrades. :P
<RAOF> Virtualise it on prodstack! :P
<pitti> the internet of ubuntus!
 * RAOF loves how his copyright line doesn't fit in 80 characters
<infinity> RAOF: Get a shorter name.
<Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/libgweather/3.12.2
<Noskcaj> cjwatson, Mind if i take the unzip merge?
<dpm> hi wgrant, pitti is currently working on generating utopic langpacks for the phone, but as per the schedule we set up in LP, the next export is not due until Wednesday next week. In order not to have to wait until then, would it be possible to run a one-off export of translations for utopic today?
<dpm> We've done this in the past, e.g. when we needed exports outside of the crontab for a release, but I don't know the procedure for requesting these nowadays
<pitti> hey dpm
<dpm> morning pitti :)
<pitti> dpm: I refined the script to calculate source packages shipped on touch now, just committed to langpack-o-matic; now I'll work on generating langpacks based on that
<dpm> excellent!
<pitti> dpm: I think we don't do the -base/update split for touch
<pitti> it makes little sense with image based updates
<dpm> yes, I agree
<dpm> pitti, do we have to change all universe packages in the list to be imported to LP? Can we determine beforehand which ones we need to import translations for?
<pitti> dpm: not necessary for building langpacks; they'll just contain the bits from main and with X-Use-Ubuntu-Langpacks (or whatever that magic key was)
<pitti> dpm: I suppose we could download all binaries from that pastebin, check if they have anything in /usr/share/locale; all which have mo files are candiates for importing
<dpm> pitti, yes, but ultimately to have meaningful langpacks, well need the X-Use-Ubuntu-Langpacks (can't remember the exact name, either :) for their .mo files to be in the export to be fed to langpack-o-matic. So at some point, we'll either have to mark all the universe ones with X-Use-Ubuntu-Langpacks or do an initial filtering (e.g. with your latest suggestion) and only mark those that make sense to be imported
<pitti> right
<pitti> dpm: but then we should also strip them
<pitti> otherwise langpacks wouldn't have much effect
<pitti> (only for new languages)
<dpm> pitti, yes, but that's what X-Use-Ubuntu-Langpacks does already, IIRC - it strips them, imports the translations and then LP exports those
<dpm> or were you suggesting something else?
<pitti> dpm: ah right, just checked; I thought we also had something like "export translation tarballs, but don't strip"
<pitti> but I think we export tarballs for all builds
<dpm> pitti, ah, no, I don't think we have a "don't strip" option
<dpm> pitti, what do you mean by "all builds" in this context?
<pitti> dpm: I mean, I think we export _translations.tar.gz for all universe packages, we just don't strip them or export them from LP
<dpm> pitti, ah, I didn't know that. Where are these universe translations tarballs exported to?
<pitti> dpm: to LP translations, as usual
<dpm> oh, you mean they're generated as part of the package build, right? So you're saying you could use that to feed to langpack-o-matic instead of the big weekly Launchpad export?
<pitti> dpm: no, not at all; I'm saying we merely need to mark these packages as X-Use-Ubuntu-Langpacks:, and it should be all good then
<dpm> ok, gotcha
<pitti> dpm: so your web app shows that we have some 20 languages with coverage >= 70%; that might be a good set to start with?
<dpm> pitti, yeah, once we get this up and running, I think I'd like to set the percentage to 80 or even 90%, but right now, 70% should be good to initially get some more languages in. Can langpack-o-matic do this calculation and filtering based on coverage %?
<pitti> dpm: not at the moment, but I'll teach it
<dpm> :)
<pitti> dpm: not that simple to get the absolute number of translatable strings though, so it might need some handholding
<pitti> dpm: i. e. if I just look at a set of .po files, then I don't see the ones which don't have any translations at all
<pitti> dpm: I suppose your web app compares with the .pots ?
<dpm> pitti, yes, I use the .pots to get the total, but currently all apps in that list are checked out to a local branch to calculate the stats, so I have access to the .pot files. However, langpack-o-matic could have some other options if it cannot access the .pot files directly
<pitti> dpm: I need to check whether the LP exports contain the pots
<dpm> - Read the template stats from the daily LP translations data dump in JSON at http://people.canonical.com/~dpm/data/ubuntu-l10n/
<dpm> - Use the LP Translations API - It's not complete, but the templates part is available. I can't recall if it does more than just listing template names per source package, though
<pitti> dpm: ah, nice
<pitti> dpm: i. e. in http://people.canonical.com/~dpm/data/ubuntu-l10n/trusty-potemplate-stats.json
<dpm> pitti, exactly
<pitti> dpm: that would mean that accounts-service has 10 translatable strings?
<dpm> I've got an RT open to get the utopic stats
<pitti> and apt 624
<dpm> pitti, indeed
<pitti> ok
<pitti> dpm: so the stats will be skewed a bit as we ship e. g. apt and gdb on the phone although they aren't "visible"
<pitti> dpm: implementing that will take some time, perhaps we start with a fixed list of language codes
<pitti> based on your web app
<pitti> it won't change every other week anyway
<dpm> +1
<wgrant> dpm, pitti: Export is running.
<pitti> wgrant: cheers
<dpm> awesome, thanks wgrant
<debfx> ScottK, Laney: do we still need to enforce that trusty->precise backports end up in saucy too? is precise->saucy a supported upgrade path?
<dpm> pitti, I'd use only the totals for the packages that we're considering as part of the UI. I've ran my stats webapp for source packages to calculate the distro translation coverage in the past, and I use the "priority" field to determine if it's a template whose translations are visible. E.g. anything with a priority <= 100 I'm not counting towards the total number of strings
<dpm> and those priorities are set in LP, generally I go through the templates when we open translations and set them all up and tweak them afterwards if needed
<dpm> pitti, a third option would be for me to add an API to my web stats to return the language coverage for each language
<dpm> s/language/translation/ coverage
<pitti> dpm: downloading a single .json file sounds fine to me
<dholbach> good morning
<dpm> pitti, yes, whatever works best for you. I've also checked that you can get the string count from the LP API, so just to confirm, this is also an option you could use. https://launchpad.net/+apidoc/devel.html#translation_template
<dpm> "message_count"
<mitya57> Mirv: Good to know that!
<Laney> debfx: nope, indeed not
<cjwatson> Noskcaj: Would prefer to do it myself, thanks.
<Noskcaj> ok. I'll cancel my merge proposal then
<cjwatson> In general I don't need help with my merges unless explicitly requested
<Noskcaj> ok
<infinity> doko: Did you see my binutils ping?  You dropped my delta from http://launchpadlibrarian.net/173790298/binutils_2.24.51.20140425-0ubuntu1_2.24.51.20140425-0ubuntu2.diff.gz
<infinity> doko: Which is why the lintian testsuite is failing again.
<infinity> doko: You may also have dropped it from Debian, I didn't check.
<doko> infinity, ouch. will reapply it
<infinity> doko: Ta.
<infinity> doko: Should probably add an autopkgtest that does the same thing as the lintian test (attempt to link -lm to a simple test program using ld directly) to make sure it doesn't regress.
<ogra_> xnox, seeing your mail exchange with janimo ... didnt we say the non RTM devices will keep loop mounting ? so for these a proper image name definitely makes sense
<pitti> infinity, cjwatson: do you know, do we still need pre-depends: for packages using xz compression? (it's the default now, but I'm also wondering about precise)
<pitti> ${misc:Pre-Depends} ought to take care of that?
<cjwatson> I think it was lucid-to-precise updates that needed that
<pitti> ok, thanks; these days dpkg doesn't generate any misc:Pre-Depends, but I guess it can't hurt to add it anyways
<pitti> context: langpack builds (so far they've been using bzip2, but that's now marked as deprecated)
<cjwatson> dpkg wouldn't anyway, it was debhelper
<cjwatson> I think it dropped them a little while back
<cjwatson> But yeah, for anything at all recent there's no need to keep them now
<pitti> ack, thanks
<cjwatson> Maybe for precise it's simplest to leave them as bz2
<pitti> I just tested it under precise, seems to work just fine
<pitti> build/install/lintian/etc.
<infinity> lucid didn't support xz.
<infinity> So the pre-depends is needed on packages in precise.
<infinity> It's not needed in trusty.
<infinity> pitti: ^
<pitti> infinity: thanks
<cjwatson> Right, even for packages in -updates, because otherwise we break lucid-to-precise upgrades which will likely have -updates enabled during the upgrade.
<cjwatson> If dh_installdeb or whatever it was DTRT in precise then ${misc:Pre-Depends} would be simple enough.
<pitti> no, it doesn't seem to do that, it just sets it to empty
<pitti> so I bumped the existing manual pre-dep now
<cjwatson> I guess it can't know since the compression method is set in options to dh_builddeb, which is too late to do anything to the control file.
<dpm_> pitti, it seems that the langpack export was pretty quick this time. We've now got the first full langpack available at: https://translations.launchpad.net/ubuntu/utopic/+language-packs :)
<pitti> dpm_: oh, wow! that's just the *perfect* timing
<dpm_> :)
<pitti> dpm_: I just started downloading the latest trusty langpack for testing my recent langpack-o-matic stuff on real data :)
<dpm_> aha!
<pitti> (so far I've just written test cases with the mini-tarballs in tests/)
<pitti> dpm_: cool, so utopic langpack time, too :)
<dpm_> \o/
<pitti> wgrant: and yes, that was mighty fast -- whatever you did, rock!
<pitti> ouch -- the whole unpack and import of the full translation tarball takes ~ 15 s on my machine, ~ 2 h on germanium; yay tmpfs..
<pitti> dpm_: http://paste.ubuntu.com/7594256/
<pitti> ogra_: ^ FYI: first iteration of -touch langpack is ~ 800 kB for German (which should have fairly good coverage), whereas the regular langpack is 3.6 (not including -gnome)
<pitti> 3.6 MB, I mean
<ogra_> wheee !!!!
 * ogra_ hugs pitti 
<pitti> ogra_: and dpm determined we'll need some 20 or so (all languages with >= 70% coverage)
<ogra_> well, as many as we can ship ...
<ogra_> but that will reduce our size massively ... awesome news
<pitti> ogra_: there's still room for optimization here -- e. g. this ships translations for gdb, apt, etc. (see http://paste.ubuntu.com/7594256/)
<pitti> and OTOH it does'n yet have many apps (we need to mark those in universe which we want to get included in langpacks and stripped)
<pitti> but it's a first ballpark figure
<pitti> anyway, time for lunch :)
<dpm_> pitti, that's awesome, thanks! I think that's good for the initial ones, but do you think we could do some further filtering in the next iteration? I see things such as colord, gdebi, libgweather-locations and others that we could probably drop.
<ogra_> ah, well, we want to get the devices in the hands of developers ...
<ogra_> i think it makes sense to keep that stuff in for now
<ogra_> (gdb, apt etc)
<pitti> dpm_: yes, absolutely
<mlankhorst> chrisccoulson: I've added a hack to the bug report in case you want to use nouveau, but I think it's too ugly to even propose it as a sru :P
<dpm_> cool. pitti, also, could you add 'ca' to the list of langpacks generated? It's the locale I'm testing on (apart from zh_CN), but I'll make sure it gets to 70% before the stats are updated tomorrow :)
<pitti> dpm_: I currently built all, I still need to add a --languages feature
<dpm_> ah, perfect
<pitti> or implement --min-coverage etc.
<chrisccoulson> mlankhorst, oh, it doesn't support gl from more than one thread. that kinda sucks :/
<mlankhorst> chrisccoulson: the hack I wrote probably works though :P
<mlankhorst> but yeah I'd have to make things thread-safe in a cleaner way
<chrisccoulson> mlankhorst, I also need to implement the missing bits to make chromium's GPU blacklist work in oxide, so that we could disable the GL compositor and webgl
<chrisccoulson> that would mean the only thread accessing gl would be the rendering thread for the qml scenegraph
<mlankhorst> chrisccoulson: the hack makes nouveau thread safe enough not to crash
<chrisccoulson> but that's a fair bit of work and I was hoping not to do it yet :/
<chrisccoulson> yeah, the issue is that it's not me with the crash (I don't have nvidia hardware)
<mlankhorst> Laney: can you test?
<Laney> test what?
<mlankhorst> Laney: hack from https://bugs.launchpad.net/nouveau/+bug/1309044
<ubottu> Ubuntu bug 1309044 in xserver-xorg-video-nouveau (Ubuntu) "Unity webapps crash Ubuntu 14.04 LTS on my computer" [Undecided,Triaged]
<mlankhorst> but it requires libdrm 2.4.54 first, just grab it from debian or utopic
<Laney> i'm on utopic already
<Laney> do you have a package?
<mlankhorst> no, just the diff, let me build one..
<Laney> it's okay
<Laney> assuming it applies
<Laney> i thought you could reproduce this yourself though
<mlankhorst> yeah :p
<mlankhorst> but no idea if this breaks other things or not
<Laney> mlankhorst: erm what is this a patch to? :(
<mlankhorst> mesa
<mlankhorst> but I'm upgrading my chroot, just give me a bit
<Laney> it's okay, building now
<pete-woods> sil2100: hi, I've done the testing for the HUD stuff in silo #9, I don't think and landing folks want to hit the publish button, though, because the status still makes it look like the build failed
<Laney> mlankhorst: trying ...
<chrisccoulson> mlankhorst, is there an easy, reliable way to detect that nouveau is being used?
<mlankhorst> yes, but I would rather not add blacklists
<sil2100> pete-woods: hey! Let me take a look at that, maybe it needs a small push from our side
<chrisccoulson> mlankhorst, as a stop-gap, making the webbrowser-app abort is probably better than the whole machine locking up :)
<mlankhorst> chrisccoulson: though in that case I would prefer only adding certain nouveau versions, not blacklist newer nouveau entirely
<Laney> mlankhorst: I had some weird flickering when I logged in
<Laney> WHAT HAVE YOU DONE
<mlankhorst> no idea
<Laney> actually I have it all the time
<mlankhorst> yeah I've noticed, no idea about it yet :/
<Laney> haha
<Laney> why did you get me to run it if you knew?
<mlankhorst> might be that flush I removed on swapbuffers, but hey i told you it was hacky :P
<Laney> oh god
 * Laney babbles
<pete-woods> sil2100: thanks :)
<jdstrand> jamesh: hey, for bug #1303962, does this policy look reasonable:
<ubottu> bug 1303962 in apparmor-easyprof-ubuntu (Ubuntu) "please integrate mediascanner2 and media-hub with apparmor" [High,In progress] https://launchpad.net/bugs/1303962
<jdstrand> # Allow communications with mediascanner2
<jdstrand> dbus (send)
<jdstrand>      bus=session
<jdstrand>      path=/com/canonical/MediaScanner2{,/**},
<ScottK> debfx: I'd say no.
<jdstrand> the {,/**} specifies an alternation such that both path=/com/canonical/MediaScanner2 and path=/com/canonical/MediaScanner2/<something else> matches
<pitti> ogra_: TBH, repeating where things changed in the changelog seems pretty obsolete to me; after all, that's all in the individual commits?
<pitti> ogra_: of course, the commit logs need to be useful; i. e. explain *why* something was done, not just *how*
<ogra_> pitti, i just want somethig descriptive so that one of the landers can understand the change
<pitti> ogra_: yeah, summaries still help to find affected packages, of course; but I think having all the details in debian/changelog is too noisy
<ogra_> ist fine to have a caption referring to the feature across the ten packages it spans
<pitti> ogra_: or did you actually mean bzr changelogs?
<pitti> if these suck, then yes, big fail
<ogra_> pitti, i mean debian changelogs ...
<pitti> (but they always implicitly have the "where")
<ogra_> well, bzr changelogs are usually not much better
<ogra_> the debian changelog is assembled from them in CI
<pitti> ogra_: ah right, with CI train debian changelog == MP "commit changelog", meh
<ogra_> pitti, my mail is more towards the upstream devs that arent familiar with packaging ... i havent seen malformed changelogs from experienced packagers yet
<ogra_> if your MP commit mesage only says "hey, new feature added !!!! i rock" ... thats not helpful
<pitti> ogra_: heh, I don't think it's inherently related to packaging; more like "did that developer ever have to go through the pain of researching commits from some years ago" :)
<pitti> yes
<pitti> so in git terms, the one-line summary should be in the debian/changelog, the detailled 20-line description shouldn't
<pitti> but right, we don't have the detailled 20-line description with our approach (at most in the individual commits of each merge)
<ogra_> well, even a *proper* one liner would help
<ogra_> most of the time its not even that
<jamesh> jdstrand: currently everything is hanging off a single object path, so the /** bit isn't strictly necessary.  You could also lock it down by the interface name too if you want.
<jamesh> jdstrand: it looks like that policy would work though.
<jdstrand> jamesh: I'll lock it down more like you said. if we need to refine, it is easy enough to do
<jdstrand> jamesh: thanks!
<shadeslayer> pitti: wut https://jenkins.qa.ubuntu.com/job/utopic-adt-kapptemplate/3/console
<mlankhorst> Laney: so no crashes then?
<Laney> mlankhorst: it didn't crash
<mlankhorst> :D
<Laney> but
<Laney> I couldn't really interact with it
<mlankhorst> why?
<Laney> because it was flickering so much
<mlankhorst> ai
<mlankhorst> ok so needs more thought then
<pitti> shadeslayer: yep, will restart; we had to reboot the ppc64el boxes, and jenkins as the pain that it is vomits on that for the x86 boxes too
<shadeslayer> heh
<pitti> this affected some 5 other tests too, all restarted now
<Laney> is that why I got a failure for a test which actually passed?
<pitti> le sigh, *want jenkins go away*
<pitti> Laney: yes
<Laney> nod
<xnox> pitti: not only i get shutdown-hang, a basic lxc container fails to boot as well *sigh*
<pitti> xnox: darn; the code looks rather correct to me, so I guess it's hanging someplace else now? :-(
<xnox> pitti: let me go the traditional route and upload remaining fixes for tasks & try concurrent boot without changing sysv-init at all.
<xnox> cause that suppose to work (or at least did in limited sense)
<xnox> and the fact that startpar is not producing any logs anywhere is annoying. (and even it's stdout/stderr is slurrped up by the rc script)
<pitti> dpm_: actually, with http://people.canonical.com/~dpm/data/ubuntu-l10n/utopic-potemplate-stats.log the percentage cutoff is not that hard to do; how reliable/up to date are these json files in general?
<pitti> dpm_: with that file I'll add the numbers of all templates that we have in the package list, and with msgfmt --statistics I can add the number of translated strings, the rest is simple division and comparison
<dpm_> pitti, they're pretty good, and they are updated once a day. As an alternative, you can use the LP API to get instant stats if we need it to be more frequent.
<pitti> dpm_: nah, that's totally fine
<pitti> thanks
<dpm_> pitti, that sounds good to me. If you're looking for a pure python solution, you might want to use polib instead of the cli gettext tools
<bdmurray> mvo: bug 1309447 failed the verification for the SRU. I posted the traceback I received.
<ubottu> bug 1309447 in apt-clone (Ubuntu Trusty) "Unicode decode error during upgrade to 14.04 if sources.list contains non-ascii characters and locale is non-US" [High,In progress] https://launchpad.net/bugs/1309447
<pitti> dpm_: not installed on macquarie, I guess I'll just keep the existing msgfmt call (it's already calling that anyway for normalization)
<dpm_> ok, sounds fine, then
<mvo> bdmurray: thanks, let me have a look
<mlankhorst> pmcgowan: oh btw, i checked and bug https://bugs.launchpad.net/checkbox-gui/+bug/1318584 is not a regression from trusty
<ubottu> Ubuntu bug 1318584 in Next Generation Checkbox (GUI) "checkbox-gui crashed when switching video out mode to external only mode" [Medium,Confirmed]
<shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kate/ < doesn't seem to have actually run the tests?
<shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-kate/ARCH=i386,label=adt/2/console
<pmcgowan> mlankhorst, hmm? meaning its busted on earlier stuff?
<pitti> shadeslayer: it could certainly do with some more verbosity..
<shadeslayer> kbuildsycoca4 running... < kdeinit starts, but then nothing
<mlankhorst> pmcgowan: yeah, trusty crashes in the same way, and I diffed the qplatformscreen.cpp file against 5.2.1, didn't find any changes
<shadeslayer> klauncher: Exiting on signal 1 < that's from shutdown I kdeinit4_shutdown think
<shadeslayer> pitti: btw locally my hook seems to run them
<pitti> shadeslayer: perhaps this is missing some xvfb-run etc. magic?
<shadeslayer> http://paste.ubuntu.com/7595244/
<pmcgowan> mlankhorst, I assume the concern is trusty since thats what is used for preinstalls
<mlankhorst> it looked to me like the concern was it being a regression that prevented 5.3.0 from landing..
<pitti> mkdir failed: : No such file or directory
<pitti> trying to create local folder /home/shadeslayer: Permission denied
<pitti> shadeslayer: ^ something seems wrong in your hook?
<mlankhorst> pmcgowan: from the qplatformscreen.cpp documentation
<mlankhorst>     Reimplement in subclass to return the pixel geometry of the screen
<mlankhorst> \fn QRect QPlatformScreen::geometry() const = 0
<shadeslayer> pitti: http://paste.ubuntu.com/7595266/ < afaict that comes from kdeinit
<pmcgowan> mlankhorst, no the concern aiui is validating trusty images with the test tool
<pitti> shadeslayer: ah, this probably still keeps your $HOME although it runs as user pbuilder
<shadeslayer> most likely
<pitti> shadeslayer: btw, adt-run has a -s/--shell-on-fail option which you might want to use
<pitti> shadeslayer: ah no, it's currently broken with --output-dir, so not yet :/ (and --tmp-dir is obsolete)
<shadeslayer> pitti: the hook gives me a shell on fail :)
<shadeslayer> see lines 31-33
<pitti> shadeslayer: anyway, I suppose this needs to be checked in schroot or qemu to see what's going on
<pitti> shadeslayer: right, that's what I was looking at
<mlankhorst> pmcgowan: hm might be found with valgrind..
<mlankhorst> if object was already destroyed
<shadeslayer> uf :P
<shadeslayer> seems like so much work
<pitti> shadeslayer: well, what is this test supposed to do?
<pitti> shadeslayer: the essence is that it calls dh_auto_test
<shadeslayer> yep
<pitti> shadeslayer: you really want to do that during build instead
<pitti> that doesn't test the installed pacakges at all
<pitti> and also explains why nothign is being tested in CI as there is no built tree
<pitti> shadeslayer: (it doesn't have build-needed); but you really shouldn't run tests against the built tree in an autopkgtest anyway :)
<pitti> shadeslayer: so that same appraoach in debian/rules override_dh_auto_test seems just fine
<pitti> (and dropping the autopkgtest, or replacing it with something that actually tests the installed package)
<shadeslayer> so I wonder why debian does it this way
<pitti> shadeslayer: I know, it's a rampant error which apparently keeps spreading via copy & paste :(
<pitti> shadeslayer: may I point to https://lists.debian.org/debian-devel-announce/2014/05/msg00004.html ?
 * shadeslayer looks
<shadeslayer> pitti: cheers, I'll collaborate with debian
<pitti> shadeslayer: many thanks!
<xnox> stgraber: https://launchpadlibrarian.net/177016056/buildlog.txt.gz this looks odd (during recipe build now)
<stgraber> xnox: hmm, yeah, that's weird... I did put a breaks + replace in there didn't I?
<xnox> stgraber: you did, but it's unpacking a weird upstart at the same time.
<stgraber> xnox: ah, yeah, I guess that may break if using the upstart from the PPA maybe, if it has a version higher than the break but still has 01-upstart-lsb
<xnox> stgraber: right, let me fix that. However, that shouldn't have happened as we use latest packaging.... which has the right commit dropping the hook.
<cjwatson> Yeah, it'll always dist-upgrade from the archive in question first
<xnox> right, last build of upstart into ppa for utopic used packaging revision 1562 and thus still has the hook, which now prevents building new upstart into ppa via recipe.
<xnox> will delete upstart from PPA, check the recipe and re-trigger the build.
<pitti> dpm_: so I implemented the "count number of translated strings" in langpack-o-matic now; turns out that we ought to remove quite a number of really poor langpacks for regular Ubuntu, too: http://paste.ubuntu.com/7595543/
<pitti> dpm_: even with a really low cutoff like 5% we can get rid of a lot of noise (where there are only 5 strings translated in the whole Ubuntu..)
<xnox> stgraber: cjwatson: ha, recipe uses trusty packaging instead of utopic.
<xnox> which i think happens on each distro-series branch. lp:ubuntu/upstart recipe branches become lp:ubuntu/(devel-1)/upstart
<dpm> pitti, that'd work for me if that helps managing language packs. I'm not too worried about it, as for me the priority would be to get more languages in the CD rather than reducing the number of langpacks in the archive. But if it helps removing cruft, wfm, yes
<pitti> dpm: yeah, I implemented it for the 70% threshold for the touch packs, but it has that nice side effect :)
<pitti> if we reduce the buildd load and archive overhead from 800 to 600 packages that's already something
<dpm> :)
<cjwatson> pitti: it's much more manageable with cross-architecture builder pooling now, anyway
<pitti> cjwatson: right, but it's also Packages.gz size etc.
<cjwatson> so we can build 16 language packs at a time in parallel and *blam*
<cjwatson> Yeah
<pitti> certainly not a huge saving, but we'll get that for free
<pitti> and with that, good bye everyone! see you on Tuesday (swap day tomorrow, Pentecost on Monday)
<bdmurray> mvo: do you have any plans to upload aptdaemon? bug 1324833
<ubottu> bug 1324833 in aptdaemon (Ubuntu) "crash handler does not include package version" [High,In progress] https://launchpad.net/bugs/1324833
<mvo> bdmurray: I had no plans, but I can do it tomorrow
<hallyn> BenC: sorry on bug 1321365, i'll be testing a 1.2.5 candidate with that fix today
<ubottu> bug 1321365 in libvirt (Ubuntu) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Triaged] https://launchpad.net/bugs/1321365
<BenC> hallyn: Thanks. Iâm working on testing libvirt fully. Tryign 1.2.5 right now (if you have wip src package, please let me try it too)
<BenC> hallyn: Iâll let you know if I run into any other issues
<BenC> hallyn: But please backport that fix to trusty too
<hallyn> BenC: zul will push it to ppa:zulcss/libvirt-testing momentarily
<hallyn> BenC: yes, will do.  i was going to wait for 1.2.5 but at this point forget that.  lemme check check other pending srus,
<hallyn> yeah that's the only one i have listed for trusty
<hallyn> say is saucy eol yet?
<zul> BenC:  just doing a local test build first
<hallyn> stgraber: hey, if you're around, would you midn looking at the libvirt pkg i pushed to trusty-proposed?  it's urgent for ben, a 2-line fix;  it's not in utopic yet only bc we're still testing the huge and painful 1.2.5 merge there.
<hallyn> stgraber: and BenC is blocked without it
 * hallyn shoulda just pushed the two-line fix originally, instead of trying to save the build farm some effort :)
<stgraber> hallyn: ok, I'll take a look
<stgraber> hallyn: minor nitpicking, why did you use ubuntu13.1.1 instead of ubuntu13.2? :)
<hallyn> stgraber: bc ubuntu13.1 is still in utopic for a day <shrug>  i bikeshedded for 2 mins then figured this seemed safest
<hallyn> happy to change it back :)
<hallyn> will look neater in the end
<stgraber> hallyn: nah, I'll accept it as is, the version is not wrong, it's just unusual ;)
<stgraber> hallyn: accepted
<hallyn> stgraber: thanks
<BenC> error: Failed to create domain from vir1.xml
<BenC> error: internal error: cannot load AppArmor profile 'libvirt-ffcc0d49-cf2d-48f7-bb59-fb60731b3c59'
<BenC> hallyn: Any ideas on that?
<BenC> This is using the 1.2.5 in zulâs  ppa
<BenC> zul: ^^
<zul> BenC:  no thats new to me
<BenC> zul: This references an lp bug http://stackoverflow.com/questions/12069297/create-virtual-machine-using-libvirt-error-related-to-apparmor
<BenC> zul: The workaround doesnât apply to my xml though. Itâs already raw
<zul> BenC:  that version didnt have the device-tree fix since I havent uploaded it to my ppa yet hallyn is uploading a new fix
<BenC> zul: I have that fixed locally, so thatâs not the issue
<zul> BenC:  then its another issue
<hallyn> BenC: i've pushed the fix against 1.2.2 to both utopic and trusty-proposed.  you can grab the binaries from trusty-proposed
<BenC> hallyn: Thanks
<BenC> hallyn: Thanks
<BenC> zul: No messages from apparmor in syslog when this happens
<BenC> I even disabled apparmor and it still errors the same
<hallyn> BenC: you get this with the 1.2.2 version as well?
<BenC> hallyn: I canât use 1.2.2 because it doesnât configure the pci correctly, but no, I didnât see this error there
<BenC> It showed that it successfully loaded/removed the apparmor profiles for the guest too
<hallyn> what patch do you need to configure teh pci correctly
<bdmurray> pitti: have you seen the updated comments in bug 1259829 regarding some other models?
<ubottu> bug 1259829 in linux (Ubuntu) " htree_dirblock_to_tree:920: inode #53629599: block 214443464: comm rm: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=1667681412, rec_len=45654, name_len=39" [Low,Triaged] https://launchpad.net/bugs/1259829
<BenC> zul: If I set security_driver = "none" in libvirt/qemu.conf, and teardown apparmor, I can start vms with no issue
<jamespage> gaughen, btw firefly is in -updates now
<BenC> zul: When that error happens, virt-aa-helper isnât even being called, so it fails even before that point in the code
<zul> hallyn: ^^^
<BenC> zul, hallyn: Something in virDomainDefFormatInternal() is erroring out (and it isnât printing an error to syslog, so that limits the possibilities)
<gaughen> jamespage, excellent
<BenC> zul, hallyn: Hereâs a FAQ: Not having a <uuid></uuid> in the xml causes that error
 * hallyn mumbles something about xml
<Unit193> henrix: Hello, are you alive there?
#ubuntu-devel 2014-06-06
<TheMuso> @pilt in
<udevbot> Error: "pilt" is not a valid command.
<TheMuso> @pilot in
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<mwhudson> is there a guide somewhere for "how to build an ubuntu kernel with this extra patch i want to test"?
<infinity> mwhudson: Apply patch, build package.
 * mwhudson finds that the link to https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel was purple already
<mwhudson> infinity: so easy
<infinity> mwhudson: If you want a different version number and don't want to futz with ABI check ignore stuff, just change the top version in debian.master/changelog and debian/changelog instead of adding a new entry, and voila.
<mwhudson> i guess i need to find out if the patch set i care about applies to 3.13
<mwhudson> unless utopic has a newer kernel already i supose
<infinity> mwhudson: utopic is 3.15
<mwhudson> oh shiny
<infinity> Way to keep up. ;)
<mwhudson> is 3.16 out yet?
<infinity> 3.15 isn't out yet...
<mwhudson> haha
<mwhudson> ok
<mwhudson> but it's well into rcs?
<infinity> Yeah, rc8.
<mwhudson> hm i wonder if it has the patch i want already
<mwhudson> (psci support in kvm)
<infinity> Do you have the commit?
<mwhudson> not to hand no
<mwhudson> last i heard it was in kvm-next
<mwhudson> it was queued on apr 30 http://www.spinics.net/lists/kvm-arm/msg09229.html
<mwhudson> but doesn't seem to be in linus' tree yet
<mwhudson> i guess it's waiting for 3.16
<mwhudson> gruh, patch series doesn't apply
<mwhudson> (to linus tip even)
<mwhudson> i hope i don't have to understand this!
<mwhudson> woop i have some hacked up kernel debs of my very own
<TheMuso> If any SRU reviewers are around, mind having a look at bug 1308771, and its lack of a specific test case, given a language specific bug, and the difficulty in possibly finding someone to test the fix who knows the language in question?
<ubottu> bug 1308771 in openoffice.org-hyphenation (Ubuntu) "Update Swedish spellcheck and hyphenation dictionaries" [Medium,In progress] https://launchpad.net/bugs/1308771
<TheMuso> I guess my question is would you let that fix through?
<TheMuso> @pilot out
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jamespage> @pilot in
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<jamespage> cjwatson, infinity: please could one of you take a look at the debdiff on https://bugs.launchpad.net/ubuntu/+source/finish-install/+bug/1320327
<ubottu> Ubuntu bug 1320327 in finish-install (Ubuntu Trusty) "configure getty properly on serial consoles using hardware flow control" [High,In progress]
<jamespage> it looks reasonable to me - but wanted someone with better knowledge of this package to review before I sponsor
<rbasak> In a shell script wrapper, I need to get from the line: "$@" to the equivalent line inside: su -c '...' ...
<rbasak> ie. shell quote the whole "$@" into a single thing that the shell will then interpret as normal, if that makes sense.
<rbasak> Is there a standard way to do this?
<cjwatson> jamespage: looking
<cjwatson> rbasak: I'm sure it is possible but su's interface is dreadful for this.  Is there any way you can use a different tool that doesn't require requoting?
<cjwatson> rbasak: (and doesn't involve creating a new PAM session, etc.)
<cjwatson> rbasak: if you're just trying to switch from root to some other user in a maintainer script or something, then there's a pattern in man-db.postinst that you could use
<cjwatson> jamespage: looks fine, matches the fix that went upstream
<jamespage> cjwatson, indeed - thanks for the second pair of eyes!
<rbasak> cjwatson: thanks. Are you referring to the Perl invocation in run_mandb? I can use that I think. I'm in a dep8 test, and I need to switch from root to another user, set a new HOME but maintain PWD and call another script that runs as a normal user.
<rbasak> On a second look, I'm not sure I see the bit in man-db.postinst you mean
<xnox> rbasak: is this not appropriate "HOME=/bar sudo -E -u user cmd --cmd-args" ? no quoting for target command, can change env variables, and preserves PWD, doesn't do login shell.
<cjwatson> rbasak: The perl invocation, yes.
<cjwatson> That's simpler than sudo.
<cjwatson> And fewer things can go wrong.
<rbasak> Re-reading the Perl guessing what $(, $), $< and $> might mean I understand it now - thanks.
<cjwatson> I do wish we had something in coreutils or util-linux or something that *just* did user-switching (and maybe group-switching) without any of the other gubbins, for use as a primitive operation.
<rbasak> Is there anything that won't be switched, but might be in a login shell that hit PAM?
<rbasak> I want to test juju as a normal user here, but need the test to run as root for some setup. I'm just concerned that I'm testing exactly what a local user would get.
<rbasak> So I was going for a login shell that then called juju, but having to change PWD made it awkward.
<rbasak> (because PWD is where the dep8 test resources are)
<cjwatson> 
<xnox> reading perlvar manpage, that perl invocation is very nice. =) would be less cryptic, if expanded var names would be used e.g. $REAL_USER_ID instead of $<. I guess I didn't do any amount of perl to learn about those vars to date.
<rbasak> xnox: I think there's a "use English;" thing (or something like that). But it's been many years since I touched Perl
<rbasak> It would make the whole snippet quite a bit longer though
<xnox> rbasak: as per spec, you also have $ADT_TMP which should be used. So you can e.g. change directory to $ADT_TMP and set $HOME to that location as well and run anything you like.
<rbasak> Yeah I'd have to do some refactoring though.
<rbasak> What I have are a couple of different wrappers, and multiple test definitions. Some use the wrappers, and some don't.
<rbasak> So the wrappers need to find the original test files currently, and AFAICS the only way to know the location of those are with the PWD.
<xnox> "use English;" -> reminds me of Pulp Fiction "do you speak it"
<rbasak> So the thing that is called on the "other side" needs to be handed the directory somehow. If it's one of my tests directly, then I'll need to refactor the test to pick it up from a different environment env or something
<rbasak> Or some kind of "sh -c 'cd /... && ...'" type thing, and that's when the quoting starts getting horrible.
<rbasak> I've ended up doing:
<rbasak> sudo -iu jujutest sh <<EOT
<rbasak> cd "$PWD"
<rbasak> $@
<rbasak> EOT
<rbasak> This gives me the login shell I wanted. It doesn't quote $@ properly I don't think, but in my case I don't think I need it.
<jamespage> @pilot out
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<cjwatson> doko: Mind if I sync perl?  It has a different fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746890 than the one you applied, but apparently one preferred by upstream
<ubottu> Debian bug 746890 in src:perl "perl: ftbfs with GCC-4.9" [Important,Fixed]
<doko> cjwatson, sure
<cjwatson> thanks
<mdeslaur> @pilot in
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<rbasak> mdeslaur: hi! While you're piloting, I noticed bug 1189939 in my bugmail this morning that I think needs another look, and noticed you sponsored it last time. Would you mind? Else I'm fine to look at it - I flagged it in my mail already.
<ubottu> bug 1189939 in libjpeg-turbo (Ubuntu Precise) "Initialization leaks file descriptors to /prox/self/auxv" [High,Fix committed] https://launchpad.net/bugs/1189939
<mdeslaur> rbasak: sure, I'll handle it, thanks
<rbasak> Thanks!
<nectarys> How do I get the Skype status icon on the main bar of ubuntu?
<Chipaca> nectarys: I think you want to ask in #ubuntu; this channel is more for app devs
<Chipaca> sorry, i meant for ubuntu dev questions
<GunnarHj> rbasak: Hi Robie
<rbasak> GunnarHj: pong. Sorry I haven't had a chance to look yet - I did see that you updated the bug.
<GunnarHj> rbasak: Ok, I just wanted to make sure that you saw it. Please take your time.
<caribou> Q: with a list of packages & versions, which would be the most effective (and network inexpensive) way to confirm that all those package/version tuple are on official archives ?
<caribou> for a given release
<caribou> I mean, I could do apt-cache on the package & compare versions, but there might be a more cost effective way of doing this
<caribou> my goal is to identify packages that would not be part of our official archives
<cjwatson> rmadison
<cjwatson> or "apt-cache policy" to check the candidate URL
<caribou> cjwatson: I'm talking about a list of more then 1000 packages, so rmadison on each one of them would be radical
<caribou> maybe there is no way of doing it without querying the remote archive
<caribou> just for a bit of context, I'm investigating a problem on a system & just found out that one of the libraries doesn't come from one of our archives
<cjwatson> well I gave two answers so you could try the other one :)
<cjwatson> (also fwiw rmadison can take multiple packages in one go)
<cjwatson> (you'd have to write a script to correlate/compare the output though)
<cjwatson> apt-cache policy is probably better though in that it will introduce less confusion with out-of-date packages and the like
<caribou> cjwatson: ok, I'll check that one out
<caribou> cjwatson: thanks
<rbasak> caribou: I would download the packages files and process them with grep-dctrl, sort, uniq, comm, etc.
<caribou> rbasak: I had that in mind too; my problem will be to deal with various versions of the same package
<rbasak> Hmm.
<rbasak> Maybe apt-cache policy like Colin says then? chdist is useful to do that on multiple releases at once.
<rbasak> And some xargs-fu to speed it up.
<rbasak> I'm wondered about some tooling around this kind of task before. Two jobs ago I had a Postgres db with a debian version number comparison function I wrote
<caribou> rbasak: hmm, chdist is interesting
<rbasak> Then SQL provides a more powerful query language to that.
<cjwatson> tbl-dctrl + join is worth considering too, by way of poor man's SQL
<caribou> rbasak: my idea is to have some tools to process the output of sosreport & identify potential problems
<caribou> rbasak: that's the big picture
<rbasak> Oooh. I didn't know about tbl-dctrl. Thanks!
<mvo> caribou: python-apt should be up for the task as well, it sounds pretty straightforward (sorry for being a bit late to the reply-party :)
<caribou> mvo: that would be even better !
<mvo> caribou: so you have a given release (say trusty) and want to feed it a list of (pkgname, ver) and see if that is a version that is in the archive?
<caribou> mvo: exactly
<caribou> mvo: but the ver value may not be the latest version available in the archive, but one that was officially published
<cjwatson> xnox: Could you merge emacs24, please?  It needs to be rebuilt for libgnutls-deb0-28 anyway, I have somewhat limited internet here so it'd be nice to avoid downloading its .orig.tar.bz2, and I see that the latest Debian upload fixes several security issues
<cjwatson> xnox: (I've uploaded all the rest of the libgnutls-deb0-28 transition BTW; guess we'll see whether it all builds)
<mvo> caribou: http://paste.ubuntu.com/7602161/ - a very quick sketch what I have in mind, run: "printf '2vcard 0.5-3\napt 1.0'" | python checker.py" for a quick demo you certainly want to improve plus the fallback to changelogs.u.c
<caribou> mvo: thank you so much! that will get me started !
<mvo> caribou: your welcome, let me know in what way you get the data and I can look at the changelogs.u.c stuff too
<mdeslaur> @pilot out
* udevbot 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<rbasak> infinity, jamespage: so I uploaded juju-core 1.18.4, which FTBFS on powerpc. But it hasn't changed much since Trusty in theory, and I can't reproduce on our porters.
<rbasak> Any hints?
<rbasak> Could this be a toolchain regression of some sort?
<rbasak> https://launchpad.net/ubuntu/+source/juju-core/1.18.4-0ubuntu1/+build/6076908
<rbasak> I have retried once.
<rbasak> I guess I'll worry about it on Monday
 * rbasak EODs
<infinity> rbasak: You can't reproduce on an up-to-date porter chroot?  That's a bit suspect.
<infinity> rbasak: That might point to gccgo doing something POWER7-specific that sulfur can't deal with.
 * infinity gives it a retry on sagari to see.
<rbasak> Thanks
<rbasak> Oh one catch. I didn't think to dist-upgrade the porter.
 * rbasak does that now
<rbasak> It succeeded on the porter again. I didn't see the dist-upgrade pull in anything relevant anyway. Some perl and python.
<rbasak> Failed on sagari
<rcj> When marking verification as failed for an SRU and pushing a new change for sponsorship, do I need to rev the version or can it stay the same?
<ScottK>  rcj: if it was in proposed you need to bump the version.
<rcj> ScottK, thanks, that's exactly what I needed to know.
#ubuntu-devel 2014-06-07
<Chipzz> question about https://www.debian.org/doc/debian-policy/footnotes.html#f3 : how does ubuntu refer to these? as areas or as components?
<highvoltage> Chipzz: I think the word you're looking for is 'pockets'
<Chipzz> hmmm. heh. yay consistency :)
<Chipzz> related question:
<Chipzz> https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
<Chipzz> are the subsections in ubuntu the same as in debian?
<Chipzz> and does the naming of the section work the same as in debian or different?
<Chipzz> (prepending the area/component/pocket to the section if it is not 'main'?)
<cjwatson> highvoltage: no
<cjwatson> Chipzz: we refer to them as "components"
<cjwatson> pockets => release, proposed, updates, security, backports; different axis
<cjwatson> Chipzz: we have the same (sub)sections and use that same naming
<Chipzz> cjwatson: so the prefered nomenclature (considering both debian and ubuntu) would be component?
<cjwatson> yes
<cjwatson> "area" is extremely old terminology and predates all the current archive management software
<Chipzz> I'm guessing the omission of the component in the Section when the component is main is why main in ubuntu is called main, and not something else?
<cjwatson> kind of; why bother changing it
<Chipzz> well restricted has a different name :)
<cjwatson> *shrug*
<Chipzz> but different axis too I guess :)
<cjwatson> main is indeed special-cased enough that it would be troublesome to change
<Chipzz> not arguing; more like trying to understand why things are the way they are :)
<cjwatson> well sometimes the answer is just "because"
<Chipzz> :)
<cjwatson> stuff like this was set up very early
<cjwatson> and to start with there was nothing but "main"
<Chipzz> in debian I assume?
<cjwatson> I meant in Ubuntu
<Chipzz> ubuntu has had restricted etc for like forever, right?
<cjwatson> depends on your definition of forever
<cjwatson> the very early (well before going public) archive started out with just main IIRC
<Chipzz> ah k :) but it's not very important anyway, merely curious :)
<cjwatson> when it was just "we need something we've built to run our machines on"
<Chipzz> (well the initial question I did ask for a reason, the latter not so much)
<cjwatson> (I think "pocket" is terrible terminology, as it really doesn't tell you anything about their semantics; something like "stream" or "channel" maybe would have been better; but it's far too late to change now)
<Chipzz> cjwatson: anyway, thanks for your time, I'm gonna get back to hacking now :)
<cjwatson> np
<highvoltage> cjwatson: ah ok, I misunderstood what was meant by 'area'
<metaphysician> In 14.04, there is a bug in /usr/lib/pm-utils/power.d/wireless script at line 23. It should "enabled" at the end of path /sys/class/net/$1/device/enable. Wireless power saving does not get applied
<metaphysician> where $1 is the interface
<metaphysician> I always get an ENOENT error in /var/log/pm-powersave.log when that hook runs, inspite of active wlan0.
#ubuntu-devel 2014-06-08
<hjd> Hi, I found that the ubuntu delta can be dropped for the moodle packge if the latest version is synced from Debian (http://packages.qa.debian.org/m/moodle.html). However, I notice it has some Release Critical bugs open. At least one of these is affecting the version already in Ubuntu, but the other two might not. Is this a potential concern or should I just file a sync request either way?
<michagogo> Hello, everyone
<michagogo> Could I maybe get some attention on bug 1314616?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<michagogo> What's the next step at this point in moving this forward?
<jackarius86> hi how can i get involved with developing for ubuntu?
<mitya57> jackarius86: https://wiki.ubuntu.com/ContributeToUbuntu
<jackarius86> thnks mitya57
<soreau> I am wondering if kernel.ubuntu.com kernels have all the commits that upstream (linus/kernel.org) has or if the commits are conglomerations of upstream commits
<kees> soreau: ubuntu kernels start from a common branch point (a specific Linus release), then add a small number of changes/features, and then regularly merge back the upstream stable branches.
<kees> soreau: you made learn more specifics asking in #ubuntu-kernel too
<soreau> kees: oh ok, thanks
<michagogo> Hi, I don't see a link in the topic regarding policy or rules or guidelines for this channel, so I'm sorry if I shouldn't be repeating this from 3-4 hours ago.
<michagogo> What needs to happen for bug #1314616 to move forward? How does the process work and get advanced from here?
<ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<gry> Hello. https://packages.debian.org/wheezy/octave does not depend on Java but the Ubuntu's version does. Is that intended?
<gry> Java is only needed for https://www.gnu.org/software/octave/doc/interpreter/Java-Interface-Functions.html - I found it is on by default in the configure, so if it bothers you, I can ask them to  probably adjust the default. But I don't know whether this is the real reason or not - please confirm.
<Noskcaj> gry, octave in debian does depend on java
<Noskcaj> The only current diff is a change to the "breaks", which might be droppable
<gry> Noskcaj, I don't see a Java or jdk or jre word on the page I linked.
<Noskcaj> because you linked the page from debian stable
<Noskcaj> rather than unstable (what we sync from)
<ari-tczew> xnox: could you please take a look on bug 1327909 ? there is one patch added by you. is it forwardable to Debian?
<ubottu> bug 1327909 in usbmuxd (Ubuntu) "Merge usbmuxd 1.0.8-5 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1327909
<Logan_> hey try
<Logan_> and gry
#ubuntu-devel 2015-06-01
<pitti> rbasak: init-system-helpers shouldn't have apparmor-profile-load, it should go back to upstart; see bug 1432683
<ubottu> bug 1432683 in upstart (Ubuntu) "apt-get install lxc doesn't load required apparmor profiles" [Critical,Triaged] https://launchpad.net/bugs/1432683
<pitti> rbasak: but of course the breaks/replaces are missing, that was a merge error; thanks for pointing out! fix uploaded
<FourDollars> Hi, is anyone able to review my patch of https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/260676?
<ricotz> doko__, hi, jfyi, happing on wily as well: https://bugzilla.redhat.com/show_bug.cgi?id=1155273
<ubottu> bugzilla.redhat.com bug 1155273 in automake "ar: `u' modifier ignored since `D' is the default (see `U')" [High,Assigned]
<dholbach> good morning
<seb128> hey dholbach
<dholbach> hey seb128
<rbasak> pitti: "as it's only being used in upstart jobs" I'm not sure this is true. That's why we moved it.
<rbasak> pitti: it belongs in something generic as it's not upstart-specific.
<pitti> rbasak: IMHO it belongs into (and is in) apparmor
<rbasak> pitti: the problem with it being in apparmor is that apparmor is optional.
<pitti> how is that a problem?
<rbasak> pitti: so we can't depend on apparmor for the wrapper to exist if we want to unconditionally call the wrapper.
<rbasak> hallyn_: ^^
<pitti> right, you shouldn't unconditionally call the wrapper :)
<rbasak> IIRC hallyn wanted a way to unconditionally call *something*, so that had to go somewhere generic that can be depended on.
<pitti> init.d scripts/systemd units always need to check for that, as this wrapper is ubuntu specific
<pitti> and if they need to check for it anyway, they can just as well work on other distros and call the apparmor loader right away
<pitti> rbasak: LXC checks for it (and checks for the apparmor scirpt, not the i-s-h helper)
<pitti> https://github.com/lxc/lxc/blob/master/config/init/systemd/lxc-apparmor-load
<infinity> pitti: I'm down with the argument that perhaps all references to the sciprt/wrapper should be conditionalised to avoid the dep altogether, but it's still probably true that we need to ship the wrapper and keep the breaks/replaces for 14.04->16.04 upgrades.
<rbasak> pitti: if everyone is fine to always [ -x /lib/apparmor/profile-load ] first, then I'm fine with the wrapper going away.
<pitti> infinity: right; I added back the breaks/replaces for the time being, until that gets cleaned up
<infinity> The only way to make sure people always call it right, though, is to turn it into a debhelper snippet or something.
<pitti> and we only ever called /lib/init/apparmor-profile-load in upstart jobs, so let's clean this up over time
<infinity> (Well, for the maintainer script invocations, people are on their own for init jobs)
<infinity> bdmurray: Oh, and regarding your comment in LP: #1458630, I wouldn't discourage people filing bugs on current-LTS to current-non-LTS upgrades, since even if we don't officially support that, they're beta-testing current-LTS to next-LTS for us.
<ubottu> Launchpad bug 1458630 in init-system-helpers (Ubuntu) "broken package init-system-helpers: attempt to rewrite other package files" [High,Fix committed] https://launchpad.net/bugs/1458630
<cjwatson> seb128: I was on vacation.  Merged now
<seb128> cjwatson, hey, thanks ;-)
<seb128> wb!
<cjwatson> Anyone know why there's unmerged azure.device.tar.gz stuff on nusakan's cdimage deployment?
<FourDollars> Hi, does anyone have time to review my patch of https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/260705 ?
<FourDollars> There are some OEM projects blocked by https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1460521. :-(
<ubottu> Ubuntu bug 1460521 in efibootmgr (Ubuntu) "UEFI BootOrder is not empty after I removed the last boot entry." [Undecided,New]
<pitti> uh, what kind of disaster struck our buildds?
<cjwatson> pitti: Not clear what happened, perhaps some kind of network blip.  Re-enabling
<pitti> cjwatson: cheers
<smoser> teward, slow response to ping
<smoser> but here now
<pitti> hallyn: ah, I followed xnox's unified hierarchy work on the upstream ML
<bdmurray> infinity: I thought the recommended path in this case was from T-U-V-W or T->X not T->W.
<pitti> hallyn: that's also nice work, it should allow us to simplify/drop the unpriv LXC hacks/patches, right?
<pitti> bdmurray: right, but ideally we want last LTS -> today's devel series upgrade to always work
<pitti> bdmurray: as we need that for last LTS -> next LTS anyway
<xnox> pitti: i'm trying for it to work with name=systemd mount and unified mount at the same time.... e.g. do runtime detection. cause we will need that for live upgrade / re-exec.
<pitti> bdmurray: so it's true that we don't officially support it, but we appreciate bug reports anyway
<bdmurray> pitti: understood
<hallyn> pitti: we'll see :)
<hallyn> pitti: which unpriv lxc hacks?
<pitti> hallyn: this one mostly: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/core-Put-session-scopes-into-all-cgroup-controllers.patch?h=ubuntu
<hallyn> xnox: but i haven't looked closely yet - were you saying you were able to mount freezer in both unified and non-unified hierarchy at the same time?
<hallyn> pitti: oh, not at all.
<xnox> hallyn: that is possible with extra kernel command line which might not be desirable.
<hallyn> xnox: that's a step up - i thought the docs said it wasn't possible at all
<pitti> hallyn: it's what caused that cpu hotplug "I need my cpuset controller back" bug report, and it generally seems unfriendly to have to pre-allocate all controllers for upriv LXC that way
<xnox> hallyn: what i was doing so far is, mount legacy controllers where they are. mount unified hierchy in /sys/fs/cgroup/systemd and get benefit of the cgroup.populated file
<pitti> hallyn: i. e. that still smells like an userspace workaround for "we want proper cgroup namespaces" to me?
<hallyn> pitti: well there's more to it than that.  cgroupns may let us drop cgmangaer, but unpriv users still would need for systemd to set them up so that they can create a new cgroupns inthe frest place
<hallyn> i think
<hallyn> xnox: if we're going to support 12.04 and 14.04 containers under 16.04, we'll need all current controllers mounted non-hierarchy (along side hierachical)
<hallyn> uh, non-unified that is
<hallyn> pitti: but i think we can work together to make it all more seamless (for unpriv containers).
<hallyn> of course, the stumbling block will be lxc using systemd's api
<pitti> hallyn: right, that'd be nice; aside from that "I stomp over all controllers" unfriendliness didn't cause much trouble, but it's a bit of a tech debt
<hallyn> anyway first i'll look at xnox's patchset :)  and by first i mean first by way of systemd stuff, not first thing i'm working on :)
<pitti> hallyn: hehe
<hallyn> pitti: couldn't quite parse that
<pitti> hallyn: anyway, I'm happy to give you a tour through the debian git, how we maintain patches etc., if/once you want; just let me know if/when you want to start with something
<hallyn> (missing comma somewhere?  or i'm misreading)
<hallyn> pitti: thanks, sounds good!
<pitti> hallyn: ... unfriendliness "the patch" didnt' cause much trouble
<pitti> hallyn: eek :) -- (but it's time to make dinner anyway, bbl)
<hallyn> \o
#ubuntu-devel 2015-06-02
<pitti> Good morning
<pitti> arges, bdmurray: can I somehow bribe you to process the systemd SRU in vivid? people keep asking for the fixes
<dholbach> good morning
<seb128> hey dholbach
<dholbach> salut seb128
<pitti> smoser, infinity: wolfe-* are all AWOL; can you please hit the magic reboot button?
<jamespage> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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: jamespage
 * dholbach hugs jamespage
<jamespage> cyphermox, hey - are you intending on sponsoring the SRU's for bug 1401141 ?
<ubottu> bug 1401141 in isc-dhcp (Ubuntu Vivid) "DHCP server does not work for IPoIB (Infiniband)" [Undecided,Confirmed] https://launchpad.net/bugs/1401141
<jamespage> I took a look through but I'm not competent enough to assess them from a regression potential perspective.
<popey> Is there any way to debug long shutdown times? My desktop takes anything up to 30 minutes to shutdown
<mgedmin> popey, for me it was swapoff -a taking AGES
<mgedmin> but anyway /usr/share/doc/systemd/README.Debian has a section titled "Debugging boot/shutdown problems"
<mgedmin> (AGES = ~25 minutes to free up 4 gigs of swap space from my SSD)
<popey> interesting!
<popey> mgedmin: I just manually did a "sudo swapoff -a" then "sudo reboot" and it rebooted instantly!
<xnox> popey: reboot != shutdown... in systemd...
<xnox> it does tricks.
<popey> ah
<popey> I may have fixed it! Removed bootchart.
<doko> pitti, https://jenkins.qa.ubuntu.com/job/wily-adt-python2.7/lastBuild/ retry?
<xnox> popey: horum, old or new one?
<xnox> we probably should remove the old one.
<popey> uh
<popey> I'm on wily
<popey> so I'd hope it's "new"?
<xnox> popey: systemd-bootchart or bootchart =)
<popey> bootchart
<xnox> popey: it got rewritten and merged into src:systemd
<xnox> ack.
<popey> Fancy that.
<popey> ok, so during the upgrade, why didn't bootchart get removed?
<ogra_> systemd has builtin bootchart
<popey> and replaced?
<xnox> pitti: we should probably make bootchart not do anything when booting systemd.... if that can be detected. ^
<ogra_> sadly the most important info (iowait) is missing from that
<popey> my pc has been slow to boot up/down for months, didn't realise it was this.
<xnox> popey: because we need old bootchart for upstart. new one is only usable with systemd as pid1.
<ogra_> the only actual useful info you get in bootchart are the graphs at the top
<popey> right, so it shouldn't run when systemd is in use then?
<popey> (ideally)
<ogra_> the rest is just shiny shiny
<popey> yeah, and it doesn't even generate images anymore
<popey> you have to post-process
 * ogra_ hopes someone extenbds the systemd tool to that one day
<popey> last bootchart I have is 2 months ago.
<popey> ah well, fast boot time and shutdown trumps charts telling me it's slow :)
 * ogra_ notes popey doesnt seem to read ubuntu-users anymore 
<popey> nope
<ogra_> popey, https://lists.ubuntu.com/archives/ubuntu-users/2015-May/280956.html
<cyphermox> jamespage: I was, but you can sponsor it if you want, that was blocked by another trusty SRU as I recall
<cyphermox> (no longer is)
<pitti> doko: running
<pitti> doko: succeeded now (that is, until we switch back to running tests in the cloud :) )
<doko> quick, quick, migrate ...
<jamespage> cyphermox, ack - so from your perspective the proposed changes looks sane?
<cyphermox> jamespage: yup
<jamespage> cyphermox, ok
 * jamespage puts pilot hat on
<pitti> xnox: does it anything? I thought it just had an upstart job
<xnox> pitti: i believe it has init scripts as well, and initramfs hooks no? for popey it delays shutdown.
<pitti> xnox: ah, then this should indeed be fixed :)
<jamespage> tinoco, hey - dealing with your IB dhcp updates now
<tinoco> jamespage: awesome. let me know if you need anything
<tinoco> tks
<smoser> pitti, looking
<smoser> pitti, all should be back up
<pitti> smoser: great, thank you!
<pitti> smoser: what was it, OOI?
<smoser> there was (apparently announced) power downtime
<smoser> and that system only has single power
<smoser> so it went down this wekeend.
<pitti> smoser: ah, so good old mundane "real physics" problem, not another one of these pesky kernel hangs that used to haunt us :)
<attente> hi, i just did a dist-upgrade, but my machine is no longer passing the boot stage
<attente> wondering if anyone else has this problem? this is my boot.log: http://paste.ubuntu.com/11521041/
<smoser> pitti, yeah, the wireless power in that lab is flakey
<pitti> smoser: wireless .. power? AKA "everyone who walks through gets their brain fried"? :-)
<pitti> attente: err, a phone with systemd? or a desktop with powerd? (both is rather unusual)
<attente> pitti: it's a desktop
<pitti> attente: that powerd.service will time out after 90s, then it should continue to boot, doesn't it?
<seb128> pitti, desktop with powerd is not un-usual if you work on unity8
<pitti> attente: and please do purge powerd -- it doesn't work without android
<attente> pitti: it times out but doesn't continue on
<attente> pitti: i had to manually start lightdm
<pitti> Reached target Graphical Interface
<pitti> hmm
<pitti> attente: then something else is wrong, too -- systemctl status lightdm?
<smoser> pitti, it was a bad joke.
<pitti> (that's only a partial log, complete "journalctl" would be more helpful)
<pitti> smoser: (I figured, hence the smiley)
<attente> pitti: http://paste.ubuntu.com/11521648/
<pitti> attente: ah, you manually started it now?
<attente> pitti: yep
<pitti> attente: so, would like to see that before you do that
<attente> sure
<pitti> attente: can you "sudo systemctl disable powerd" for now to get that pesky 90s timeout out of the way, and reboot and check lightdm's status?
<pitti> we should probably modify the unit to not start on a desktop
<attente> pitti: http://paste.ubuntu.com/11521786/ journalctl
<attente> pitti: http://paste.ubuntu.com/11521794/
<pitti> attente: looks fine?
<pitti> systemd[1]: lightdm.service: main process exited, code=exited, status=1/FAILURE
<pitti> oh, indeed -- I didn't read far enough
<pitti> attente: anyway, that's a SEP from my point of view :) I suppose the greeter session crashes?
<attente> SEP?
<attente> i'm not sure
<pitti> 10:15:50 attente systemd[1294]: pam_unix(systemd-user:session): session opened for user lightdm by (uid=0)
<pitti> 10:15:50 attente lightdm[1290]: pam_unix(lightdm-greeter:session): session closed for user lightdm
<pitti> so yes, that session didn't last very long
<attente> oh
<pitti> attente: anything in /var/log/lightdm?
<pitti> attente: "somebody else's problem"
<attente> lol
<attente> pitti: is it a bit strange that the greeter works when i manually start it though?
<pitti> attente: yes, for sure; maybe lightdm starts too early, and it's depending on something else to be up first? hard to say without knowing why the session crashed
<attente> pitti: ok, thanks for the pointers :)
<jamespage> tinoco, all in the proposed queue for SRU team review - thanks!
<jamespage> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily 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:
<tinoco> jamespage: nah, tku!!
<pitti> cjwatson, wgrant: how can we change the import source of https://code.launchpad.net/~registry/systemd/master ? It's https://github.com/systemd/systemd.git now
<cjwatson> pitti: Is that just a straightforward repository move?
<pitti> cjwatson: yes, it was imported to github for using pull requests mostly
<pitti> cjwatson: but the same branch in spirit (just a bunch of newer commits since yesterday)
<cjwatson> pitti: Changed
<pitti> cjwatson: danke
<pitti> cjwatson: import finished, looks good
<cjwatson> cool
<pitti> slangasek, jodh: do you plan to merge Debian's systemd with Ubuntu? in particular, the split-out upstart-sysv package, so that this becomes usable as an "alternative" init system?
<seb128> pitti, systemd?
<seb128> you mean upstart?
<pitti> seb128: erk, of course I do
<pitti> slangasek, jodh: s/systemd/upstart/ of course -- gah :)
<seb128> ;-)
<pitti> ogra_: dude, you are all over G+ and you are making me dizzy!
<pitti> ogra_: https://plus.google.com/u/1/+AlanPope/posts/UN9HYBM6B4c :)
 * pitti hugs ogra_, fantastic loading image!
<pitti> popey: ^ ++
<ogra_> pitti, lol, yeah
<popey> haha
<slangasek> pitti: no plans for any work on the upstart packages.  Do you mean enabling upstart as an alternative in Ubuntu?
<barry> doko: are you looking at the promotion blocks for python3.4 and 3.5?  if not, i will spend some time on the test failures, but i don't want to duplicate effort
<LocutusOfBorg1> how is going libjsoncpp MIR?
<LocutusOfBorg1> I see this bug https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1218220
<ubottu> Ubuntu bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix]
<LocutusOfBorg1> should I open another one?
<LocutusOfBorg1> (needed for cmake 3.2.*)
<slangasek> LocutusOfBorg1: does the library now have sane soname versioning?
<slangasek> that was the reason for the reject before.  If that hasn't been addressed...
<LocutusOfBorg1> slangasek, sorry I don't get the question, it has a soname https://packages.debian.org/sid/amd64/libjsoncpp0/filelist
<LocutusOfBorg1> 0.6.0
<LocutusOfBorg1> I don't know if it is enough
<LocutusOfBorg1> (moreover there is a new package in debian NEW queue)
<LocutusOfBorg1> maybe you mean https://github.com/open-source-parsers/jsoncpp/issues/147
<LocutusOfBorg1> seems that they are fixed if I read correctly
<rbasak> Is someone handling the nettle transition? I want to upload a squid3 merge soon that'll get stuck in it, but it looks like it'd be needed for the transition anyway
#ubuntu-devel 2015-06-03
<mwhudson> is there a package in the archive that uses symbol versions that is less complicated than glibc?
<sarnold> mwhudson: if I've understand what you want correctly, the apparmor source package provides a libapparmor: http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/view/head:/libraries/libapparmor/src/libapparmor.map
<mwhudson> ah yeah, that seems to be what i mean
<mwhudson> thanks
<sarnold> I can't promise it's perfect but it's probably esaier than glibc :)
<mwhudson> is the format documented somewhere?
<mwhudson> man ld says "see VERSION for more" or something
<mwhudson> but i don't see where it means
<mwhudson> ah it all seems to be in http://www.akkadia.org/drepper/dsohowto.pdf
<mwhudson> some light reading for when insomnia is a problem
<sarnold> heh I was just wondering if that'd be the best source :/
<sarnold> I thought forsure I'd seen something "more official", but can't find what I was thinking of.
<infinity> mwhudson: I would have recommended zlib, but apparmor seems like a decent example too.
<infinity> mwhudson: Also, for docs: apt-get install binutils-doc && info ld
<infinity> mwhudson: Section 3.9 is VERSION.
<mwhudson> omg info
<sarnold> ha! I forgot info loads manpages if youdon't have the info pages loaded.
<sarnold> I checked there for VERSION but .. of course didn't have the binutils-docs loaded.
<infinity> Yeah, an annoying misfeature.
<sarnold> one of many.
<infinity> I imagine info makes sense to emacs users, to me it's always been vile.
<sarnold> next time I find an emacs user I'll ask :)
<sarnold> (I wonder if 'vile' can make info less terrible?)
<infinity> Oh, wow, vile - VI Like Emacs - vi work-alike
<infinity> WHY IS THAT A THING?
<sarnold> I ran that on dos back in the day :)
<infinity> sarnold: Telemate's built-in editor was all the editor I ever needed on DOS.
<sarnold> infinity: haha :)
<infinity> Given that DOS only existed to play video games and run Telemate to dial into my UNIX shells at the university...
<jrwren> i heard pinfo is a nicer info reader
<infinity> Huh.  This youtube video is basically my early teens: https://www.youtube.com/watch?v=nOx9fLBJO1w
<infinity> Except that I wasn't a scrub with [UNREGISTERED] flashing in the corner.
<mwhudson> oh, so the man page thing is a poor translation from texinfo or whatever
<sarnold> I thought there was a nice gui info viewer, like xman, but I can't find the thing now
<jrwren> xinfo?
<infinity> There's tkinfo, but I wouldn't call it "nice".
<infinity> pinfo is definitely nicer than the GNU client, though.
<infinity> curses based, and kinda usable by normal humans.
<sarnold> maybe it was tkinfo I was thikning of. I would have sworn just xaw widgets but maybe it was tk..
<mwhudson> pinfo is like pouring a nicer kind of vinegar in your eye
<infinity> Arguably, the sanest modern info viewer would be a web browser frontend for the rendered and some info2html magic.
<infinity> s/rendered/renderer/
<sarnold> and if we're really lucky, we'd burn the info backend once the conversion was done once :)
<infinity> sarnold: Well, much like LaTeX, the info format isn't a terrible way to write/maintain documentation, it's just that you need to render it sanely to read it.
<infinity> sarnold: In the case of LaTeX, rendering it sanely is entirely the point, for info, that's been a WIP for 20 years. :P
<sarnold> hahaha
<infinity> sarnold: But, given than no modern OS is complete without about 20 HTML rendering engines, and info node cross-referencing should map 1:1 with hyperlinking, conceptually, I figure it wouldn't be rocket surgery to build an info browser into, say, yelp.
<infinity> sarnold: Or build an info browsing local web service that you could hit from any browser.
<infinity> I'd actually be surprised if someone hasn't done the latter, and I just can't find it.
<sarnold> I never liked the fact that the information was broken into multiple pages; I always liked manpages putting all the information in one simple pager
<sarnold> I'm pretty sure I've run one of those info-to-html servers before :)
<infinity> Yeah, I tend to prefer manpages too, but whenever I'm using a GNU tool, I have to suffer the pain of info.
<infinity> And, to be fair, for some it would be amazingly unwieldly to have one giant manpage.
<infinity> The glibc docs come to mind.
<pitti> slangasek: in ubuntu we already have a split upstart-sysv binary; I meant if that will go into Debian as well, to have the same binary package layout in both
<pitti> Good morning
<slangasek> pitti: it probably should at some point, but again, not something I'm committing any time to right now
<pitti> slangasek: ack; I was just wondering
<dholbach> good morning
<mitya57> infinity, I think yelp already has an info browser
<Noskcaj> sil2100, Are we ok to sync libgit2-glib and gitg? The only delta is -glib's breaks on gitg < 3.15
<sil2100> Noskcaj: I would say it should be fine to sync it
<Noskcaj> ok, can you sync them or should i file sync bugs?
<sil2100> I'll try doing that today, but it might slide a bit since I still have a few other things to finish up :)
<Odd_Bloke> I don't think I've ever used info; perhaps this explains some of my past confusion. :p
<pitti> arges, bdmurray: I'd appreciate if you could process bug 1450009 soon -- this fixes a regression in the previous round of postgresql updates
<ubottu> bug 1450009 in systemd (Ubuntu) "suspends on closed lid, does not recognized external monitors/dock" [High,Confirmed] https://launchpad.net/bugs/1450009
<pitti> arges, bdmurray: erk, I meant bug 1461425 (just a formality, postgresql has an MRE)
<seb128> pitti, wrong bug number? ;-)
<ubottu> bug 1461425 in postgresql-9.1 (Ubuntu Precise) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [High,In progress] https://launchpad.net/bugs/1461425
<seb128> hehe
<pitti> seb128: -ETOOMANYTABS
<seb128> seems like pitti has systemd autofingers nowadays :p
<pitti> seb128: yeah, I cannot even write the word <tries very hard> "system" any more :)
<seb128> :-)
<Silentlord> hi, i want an email to contact someone regards application reviewing
<pete-woods> hi, I seem to be unable to modify bugs on the indicator-network source package (which I maintain / develop)
<pete-woods> https://launchpad.net/ubuntu/+source/indicator-network
<pete-woods> can someone tell me how to become a member of "Ubuntu Developers
<pete-woods> (you'd think I'd already be a member, given I'm employed by Canonical) :p
<cjwatson> Ubuntu Developers relates to direct upload access and is a community process, not a Canonical process
<highvoltage> hey pete-woods, http://fridge.ubuntu.com/2011/01/27/becoming-an-ubuntu-developer-a-short-guide/ is slightly dated but still mostly good
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers
<cjwatson> But there are other ways to get what you want: https://wiki.ubuntu.com/UbuntuBugControl
<pete-woods> cjwatson: thanks. I think that's more what I'm after :)
<pete-woods> highvoltage: seems like I don't want to actually become an "ubuntu developer"
<larsu> pete-woods: someone needs to set the maintainer of that project to indicator-applet-developers
<larsu> which is what all the other indicator projects have
<pete-woods> larsu: that sounds like a more sensible value to me
<larsu> pete-woods: wait, you are already in ~pspmteam, so this should work
<larsu> ah my bad. You want to be able to change *ubuntu* bugs
<pete-woods> larsu: the others (source packages here) look to be maintained my Ubuntu Desktop
<pete-woods> yeah
<pete-woods> we're supposed to have all our bugs on the source package now
<larsu> right, you won't get into ubuntu desktop
<pete-woods> indeed
<larsu> UbuntuBugControl is what you want
<pete-woods> cool
<pete-woods> I just need to get a
<larsu> it's fairly easy to join if you're a developer
<pete-woods> "showcase of my best 5 bug triages"
<pete-woods> I'm not sure I've done much other than merge branches to fix bugs, though
<pete-woods> kinda feels like my whole team "unity api team" should be in the bug control group
<pete-woods> instead of us each having to apply manually
<pete-woods> oh, it says to contact jcastro if you are an upstream developer? does that mean I don't have to go through the full application process?
<rbasak> pete-woods: you can have a team membership to the bug control group: https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams
<rbasak> The Canonical Server Team has one.
<pitti> rbasak: thanks for pinging the biosdevname bug!
<rbasak> pitti: no problem. Sorry I hadn't followed up on this before.
<rbasak> pitti: I've also asked internally to see if we can find a Dell contact.
<rbasak> (well, delegated that to my manager at least)
<pitti> rbasak: cool, thanks
<pete-woods> rbasak: yeah, I think I'll have to put in an application for one :)
<rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
<jcastro> pete-woods: just have someone from your team send me a mail and I'll add you today
<jcastro> that page is mostly for 3rd party developers who have a package in universe or something and want to triage their own bugs
<pete-woods> jcastro: okay, cool, will send you a mail now :)
<LocutusOfBorg1> doko, ping :)
<LocutusOfBorg1> I hope you read there, I would like to know if it is ok for you to upload casablanca with CXX=g++5 in unstable (the ABI problem)
<rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
<seb128> rbasak, slangasek or pitti might help you there, unsure if we still want to support booting with upstart
<caribou> Q: Would adding an upstart job to an existing package in trusty acceptable for an SRU ?
<caribou> rbasak: I'm facing the same upstart question in Wily wrt my Trusty SRU question
<caribou> rbasak: I need to add an upstart job for kdump-tools for Trusty but should I also worry about adding it to Wily, as Wily uses the systemd service
<caribou> In short, do we consider Wily + upstart a supported option ?
<pitti> rbasak: I think we should still keep upstart working until at least 16.04 LTS
<pitti> rbasak: now, if squid3 has an init.d script which essentially does the same as the upstart job, it's fine to drop
<pitti> rbasak: but if it does ubuntu specific things, we should keep it (or adjust the init.d script instead)
<rbasak> pitti: it has an init.d script from Debian and we were previously adding the upstart job. There'd the odd reported bug with the upstart script and so I think the init.d script is of higher quality. So I'll just drop the upstart job - thanks.
<pitti> rbasak: ack
<slangasek> rbasak: no, for 15.04 and beyond I don't think there's any reason to carry a delta for an upstart job.  it's reasonable and appropriate to submit that upstart job for upstream inclusion in Debian, though, where upstart is still an option
<hallyn> infinity: hi - any newer thoughts on bug 1454862 ?
<ubottu> bug 1454862 in lxcfs (Ubuntu) "[SRU][MRE] merge 0.9 (which is currently in wily) to vivid" [Undecided,Confirmed] https://launchpad.net/bugs/1454862
<infinity> hallyn: I'm not big on thinking in the morning, but I'll get back to you.
<hallyn> thx
<infinity> pitti: Can you confirm for me that all new ddebs are coming via the librarian and if I flatten a buildd (thus losing public_html), we won't lose anything?
<cjwatson> infinity: ddebs.u.c has had its direct buildd retrieval switched off for at least a couple of weeks now
<pitti> infinity: yes, I disabled all the apache polling
<pitti> I should actually commit that, thanks for the reminder
<infinity> cjwatson, pitti: Excellent.  Then, in the name of d-i testing, today might finally be the day the arm64 buildds get reinstalled with a distro kernel.
<cjwatson> Just in time to replace them with Moonshot </not-really>
<infinity> cjwatson: Yeah, I noted the same irony.
<infinity> cjwatson: But realistically, I'm sure these Mustangs will be in service for a couple/few more months still, unless we really get our ducks in a row.
<cjwatson> Yeah
<infinity> They've treated us remarkably well.  I kinda want one in my house.
<infinity> After we squished the worst issues, they've since been clocking uptime in the months, and the only interruptions for the last year have been DC power maintenance.
<cjwatson> Let's hope the distro kernel isn't worse.  Is this for page size changes?
<pitti> arges: what was wrong with the utopic/vivid postgresql-9.4?
<pitti> arges: I'll sync wily from unstable once it hits, but that won't happen until Friday or so
<infinity> cjwatson: No.  Mostly, it's cause I need to test trusty's d-i, but it's also just an excuse to be running our own code, get SRU updates, etc.
<infinity> cjwatson: But it might also fix some longstanding bugs, like hangs in the gdb testsuite, etc.
<cjwatson> Fair enough
<infinity> cjwatson: I also have a sneaking suspicion that the combination of new firmware and new kernel might fix the abysmal I/O and suddenly make those buildds quite a bit speedier.  But that's hard to know for sure without trying.
<cjwatson> Try one or two at a time, I guess
<infinity> cjwatson: Yeah, I'm only killing one today.  See how it holds up under load, then I can do the other 4.
 * cjwatson nods
<pitti> arges: https://launchpad.net/ubuntu/+source/postgresql-9.3/9.3.8-0ubuntu0.4.04 -> erk, version typo
<pitti> arges: should have been 14.04; but it doesn't matter actually, there's no other release with 9.3, so *shrug*
<infinity> pitti: 4.04, though?  Well done on inventing a release before warty.
<pitti> infinity: right, it's the 404 release -- not found :)
<infinity> :)
<infinity> pitti: And now I realize that Mark missed a great opportunity to use HTTP responses as version numbers instead of using dates.
<infinity> Those release would have been self-naming too.
<infinity> Might have even been vaguely appropriate for the first release (100) to be "continue".
<arges> pitti: yikes sorry about that
<pitti> arges: no worries
<pitti> arges: oh, you were able to re-accept the old utopic package? I thought that wouldn't work
<pitti> arges: anyway, if it works, we can reject the 14.04.1 package from the queue, and otherwise use that
<pitti> arges: thanks!
<pitti> arges: nevermind, I mis-looked
<arges> ah pitti's gone
<menace> Hi, i want to use /etc/cron.daily/apt to download the current/new debian packages. but i only want to install them from the local cache at boot or shutdown. is this possible with unattended-upgrades. I'm not sure if the modes/variables for /etc/cron.daily/apt and unattended-upgrade are the same, so both would only download OR download and install in one step, but i want to have it in two separate steps...
#ubuntu-devel 2015-06-04
<hallyn> ok so just as lxc ships one lxc-net script which is called by all init scripts, i'd like to do the same for qemu
<hallyn> but where should that script go?
<hallyn> lxc places it into /usr/lib/x86-64-gnu/lxc/
<dholbach> good morning
<LocutusOfBorg1> hi dholbach :)
<dholbach> hi LocutusOfBorg1
<mardy> diwic: hi! It's about the front jack detection in my GA motherboard, we exchanged a couple of mails some week ago; please tell me when you have a minute
<diwic> mardy, pong
<mardy> diwic: so, after all it seems that the jack detection is fuzzy even in my machine
<diwic> mardy, okay
<mardy> diwic: more often than not, when I insert the headphones in the front panel, the headphones do not appear in the system settings -> sound panel
<mardy> diwic: I need to run some more tests, but I've the feeling that if I boot my PC with the headphones in, then they are detected (but if I then remove them and reinsert them, they might go undetected again)
<diwic> mardy, IIRC in some state some people have seen the jack detection go on and off repeatedly, but I'm not sure if that is when the headphone is plugged in or unplugged
<mardy> diwic: also, I feel that the headset detection starts working rather reliably sometimes, probably if I play with the card/alsa in a certain way
<mardy> diwic: well, my problem is that sometimes the headphones are in but they are not detected; it never happened to me that it detected non-existing headphones
<mardy> diwic: do you have a bug #, for the issue your patch fixed?
<diwic> mardy, pad.lv/1248116
<mardy> diwic: so, my problem is that while I insert the headphones, I see them quickly appearing and disappearing a few times in the System Settings -> Sound panel
<mardy> diwic: sometimes the final state is that they are correctly detected, sometimes they aren't
<mardy> diwic: it seems to be rather random
<diwic> mardy, so your jack detection is not reliable, and therefore the original patch makes sense to keep for you as well?
<mardy> diwic: but the flakyness is only while I insert the headspeakers: once the card/driver has decided if it wants to see them or not, the state won't change
<mardy> diwic: no, I prefer to run with model=nofixup, and if the headphones are not detected, I pull them out and try again
<mardy> diwic: because I get the annoying audio clicks only while inserting the jack; before and after that, the sound is always stable
<diwic> mardy, ok. Maybe this behaviour is varying between individual motherboard units of the exact same model and revision
<mdeslaur> FYI, I've just uploaded dash to wily with a privilege dropping patch. If anyone gets some sort of regression with it, let me know.
<hallyn> stgraber: ok for qemu's kvm init script i intend to put the body of it under /usr/share/qemu/init (calling it from the sysv, systemd, and upstart jobs).  is thatan ok place?
<hallyn> (lxc places them under /usr/lib/x86-64-linux-gnu/ but that seems a little unorthodox)
<hallyn> (and hard to get right in the qemu build system)
<hallyn> do we assume that /usr/share is mounted by runlevel2?  i assume so...
<stgraber> hallyn: yep, that seems fine.
<hallyn> cool, thanks.  bunch of testing of course required (as i'm also merging the two scripts)
<hallyn> hm, i wonder if i should move the init script to qemu-system-common, since it should error out cleanly on other arches anyway
<teward> hardware-kernel interaction question for someone if you've got a few moments.  A question on Ask Ubuntu was created saying they want to enable "USB Charge While Off" on their laptop that supposedly supports it.  As I understand the feature, that's controlled at the hardware / BIOS level, not the kernel.  Am I wrong on that?  Sorry if the wrong location for this...
<teward> o
<teward> i'm not a kernel expert, nor a hardware expert, hence the question
<dobey> teward: yeah, that is a hardware thing.
<teward> dobey: mind if I link you to the bug and the question and the discussion then for your two cents?
<teward> since i'm obviously not an expert
<teward> dobey: because apparently Sony says its enabled via "Windows Power Management" so thereby the equivalent would be the kernel in Ubuntu
<dobey> i mean, i'm not a kernel developer/expert either, but it doesn't take a PhD to see that the kernel can't control hardware while the kernel isn't running
<teward> but as I understand that kind of hardware feature that's a hardware-control-level feature, NOT something that can just be toggled by the kernel.
<teward> dobey: indeed.
<teward> dobey: would anyone on the kernel team have any ideas on this?
<teward> (and should I go poke them)
<dobey> well, maybe sony implemented it in such a way that they require you to configure it within windows itself
<dobey> which would mean that you could theoretically chagne the same setting in ubuntu, if sony provided the driver to do so
<dobey> teward: you can ask in #ubuntu-kernel i guess
<teward> i might, thanks
<teward> (doesn't take a kernel expert, though, to determine the hardware has to control things when the system is off xd)
<dobey> my guess is sony won't support ubuntu, and you'll need to dual boot to be able to change that setting in windows
<teward> dobey: that's my guess as well
<bdmurray> seb128: Your ubuntu-settings upload to vivid seems to remove a previous fix. https://launchpadlibrarian.net/208087396/ubuntu-settings_15.04.2_15.04.3.diff.gz
<seb128> bdmurray, ok, thanks for spotting it, can you reject it? I'm going to fix it
<bdmurray> seb128: done
<seb128> bdmurray, thanks
 * hallyn peeks in looking for doko
<Riddell> who knows why this test failure happened? https://jenkins.qa.ubuntu.com/job/wily-adt-kio/ARCH=amd64,label=adt/15/console
#ubuntu-devel 2015-06-05
<dholbach> good morning
<zyga> good morning
<seb128> is anyone around with cdimage build knowledge that could help with
<seb128> https://launchpadlibrarian.net/208330071/buildlog_ubuntu_wily_i386_ubuntu-desktop-next_BUILDING.txt.gz
<seb128> that's the buildlog from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next
<seb128> it fails on "mv: cannot stat 'device.tar.gz': No such file or directory"
<seb128> k, seems like a bug in livecd-rootfs
<seb128> thanks Laney ;-)
<seb128> Laney, cjwatson, https://code.launchpad.net/~seb128/livecd-rootfs/desktop-next-duplicate/+merge/261182
<seb128> cjwatson, seems like that didrocks forgot to remove the duplicated code when he did the tweaks you asked on https://code.launchpad.net/~ubuntu-desktop/livecd-rootfs/desktop-next/+merge/257056
<Laney> seb128: np, will you upload?
<seb128> Laney, yes :-)
<Laney> cool
<seb128> sru team, is there anything that blocks the gvfs/gtk+3.0 trusty SRUs to be copied to updates? http://people.canonical.com/~ubuntu-archive/pending-sru.html shows jenkins regressions but those don't seem issues with those updates/new ones, trusty autopkgtest have never been working on those
<seb128> bdmurray, ^
<FourDollars> Hi, https://code.launchpad.net/ubuntu/+source/udisks2 for trusty is not up to date.
<Noskcaj> mitya57, Can you please merge gnome-flashback and metacity some time soon?
<cjwatson> FourDollars: Unlikely to be fixed, please fall back to source packages.
<FourDollars> cjwatson: I see. Thx.
<cjwatson> FourDollars: (Or at least unlikely to be fixed in the bzr world.)
<mitya57> Noskcaj: Not before gtk+ 3.16 lands in wily-release
<mitya57> I don't want to make the transition even more complicate
<seb128> Laney, https://launchpadlibrarian.net/208356435/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
<seb128> :-(
<seb128> still the same error
<seb128> cjwatson, ^ do you know if there is any page with hints on how to debug cdimage build issues?
<Laney> hmm
<cjwatson> seb128: not really
<cjwatson> echo "I: Moving kernel into device tarball"
<cjwatson> that message never fires
<cjwatson> which suggests to me that that hook isn't run
<cjwatson> perhaps because it's not executable?
<cjwatson> in fact there are a whole bunch of non-executable hooks in there, which looks pretty dubious
<seb128> cjwatson, thanks for pointing that out
<seb128> let me try to chmod +x and see if it's better
<cjwatson> seb128: one sec
<cjwatson> seb128: actually I don't think that's it - it's not exec for ubuntu-core either but https://launchpadlibrarian.net/208332282/buildlog_ubuntu_wily_armhf_ubuntu-core-system-image_BUILDING.txt.gz shows that hook being run
<cjwatson>         ubuntu-touch:*|ubuntu-core:system-image|ubuntu-cpc:*)
<cjwatson>                 cp -af /usr/share/livecd-rootfs/live-build/${PROJECT}/* \
<cjwatson>                         config/
<cjwatson>                 ;;
<cjwatson> seb128: ^- there's your problem, that needs to include ubuntu-desktop-next:* otherwise none of the hooks are run
<cjwatson> live-build/auto/config
<seb128> cjwatson, ah, good catch!
<cjwatson> seb128: actually probably ubuntu-desktop-next:system-image instead
<seb128> cjwatson, right, that's what got used in e.g https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build#L339
<cjwatson> yup
<cjwatson> seb128: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html has advice on running builds locally (would need SUBPROJECT in this case too), but it takes a while so it's often worth a bit of thought to do zen debugging irst
<cjwatson> *first
<seb128> cjwatson, great, thanks
<hrw> hi
<hrw> does someone know which format of keyboard remapping udev from 14.04 understands?
<seb128> cjwatson, Laney, can you retry the desktop-next image build? updated livecd-rootfs is in wily
<cjwatson> seb128: done
<cjwatson> (damn, forgot to do it in screen, oh well)
<seb128> cjwatson, thanks
<seb128> cjwatson, bah, that didn't pick the new livecd-rootfs version it seems :-/
<seb128> I guess the "ubuntu/wily accepted" are sent before it's actually available? :-/
<ogra_> seb128, rmadison is usually pretty reliable for that
<seb128> ogra_, yeah, should have verified
<seb128> I though that the email/launchpad showing in wily on the summary view was enough
<seb128> seems it's not
<ogra_> no, there is usually one publisher run after this mail that does the actual copying
<infinity> seb128: LP will show it in wily at the beginning of the publisher run when it changes its internal state, but then it still needs to do all the publishy things to it and move dists.new->dists, which can be anywhere from a couple of minutes to dozens of minutes, depending on what work the publisher needs to do.
<infinity> seb128: One could argue (and I have in the past) that the UI "published" state should be disconnected from the internal "published" state and only committed at the end of a publisher run, but that's probably unnecessary added complexity for a problem that amounts to "just wait a bit longer".  Especially since even if it was made 100% accurate for ftpmaster's disk, it's still a laggy lie for mirrors.
<seb128> infinity, yeah, going to teach me to use rmadison next time
<infinity> seb128: Patches welcome for speeding up rmadisong when using it frustrates you. ;)
<infinity> rmadison, too.
<seb128> hehe, noted :-)
<seb128> barry, does your system boot after a 90s timeout? do you have powerd installed?
<seb128> attente, did you resolve your recent systemd non  booting issues?
<attente> seb128: yep it's fixed now. but all i did was a dist-upgrade :/
<seb128> k...
<barry> seb128: it doesn't seem to.  i'll let it run for a while.  checking on powerd.
<barry> seb128: powerd is not installed
<seb128> barry, k, dunno then
<seb128> barry, but it's for pretty sure not a lightdm issue
<barry> seb128: i'm bisecting the dist-upgrade.  it's either x or unity8
<barry> seb128: i'll rehome the issue when i know for sure
<seb128> k
<barry> x
<smoser> hey. random question, not sure how this works or where the change occurred.
<smoser> with wily, recently updated yestereday and logged out and back in. gnome-terminal is visually different (light color scrollbars now showing)
<smoser> that doesnt bother me, but the change that is annoying is that when i double click on a url (http://example.com/path)
<smoser> it only selects the portion after the :
<smoser> which means i keep pasting people urls that look like
<smoser>  /paste.ubuntu.com/11591324/
<smoser> rather than
<smoser>  http://paste.ubuntu.com/11591324/
<Riddell> who's looking after jenkins these days? I seem to have quite a few false negatives
#ubuntu-devel 2016-06-06
<teward> would anyone be kind enough to run `apt-cache rdepends python-myssql` for me on a Xenial or Yakkety box, please?
<teward> I would, except I'm IRC-ing from phone again... so I can't reach my Xenial or Yakkety VMs
<teward> (dead internet at home is dead)
<karstensrage> starting up my vm teward
<teward> karstensrage: thank you kindly
<teward> trying to figure how depended-upon python-pymssql is relied on, given that it's not working (so if it doesn't work and hasn't been updated in Debian for years, maybe it should be removed)
<karstensrage> udo apt-cache rdepends python-myssql
<karstensrage> E: No packages found
<karstensrage> hmm you meant mysql
<karstensrage> not myssql right?
<karstensrage> sudo apt-cache rdepends python-mysql
<karstensrage> E: No packages found
<teward> karstensrage: python-mssql
<karstensrage> nothing
<teward> yes i mistyped
<teward> erm
<teward> python-pymssql I think it is
<teward> fat-fingering on a mobile keyboard >.<
<karstensrage> there we go
<karstensrage> sudo apt-cache rdepends python-pymssql
<karstensrage> python-pymssql
<karstensrage> Reverse Depends:
<karstensrage>   python-sqlalchemy
<karstensrage>  |pyrit
<teward> so no difference then from Trusty
<teward> karstensrage: thank you kindly!
<karstensrage> my pleasure
<karstensrage> :)
<teward> betcha a dollar that nobody depends on it because it's broken and you can't get anything from executed SQL queries)
<teward> eww
<teward> nevermind, that's a very painful removal
<teward> at least.... jesus, a huge amount of python-* things depend on sqlalchemy it looks like
 * teward gives up :p
<teward> forget i said anything about package removal :)
<JanC> teward: isn't there also another python module for MS SQL?
<teward> is there?
<teward> JanC: MSSQL is what's in use at the workplace
<teward> that was a migration hurdle recently until I discovered the StackOverflow post about the version of pymssql being old being the cause
<teward> JanC: problem being the rdepends for the removals, though, unless you're saying there's an alternative for python-sqlalchemy to rely on, it has a depends on python-mssql, and AFAICT the rdeps for python-sqlalchemy extend to a large # of python-* packages
<JanC> right
<teward> JanC: i'd rather see it updated, but it looks like upstream in Debian nobody cares
<teward> ("It doesn't work" bugs have been there for at least 3 years)
<JanC> I'm sure Debian as a whole cares
<teward> JanC: the maintainer probably doesn't care, there's been no movement on 'updated versions'
<teward> which makes me think they don't care it doesn't work, because they haven't reported that it's not fixable
<teward> when there's been a patch submitted already
<JanC> there are procedures to handle that AFAIK
 * teward shrugs
<teward> as i said, I don't care anymore, I have my workaround
<teward> :p
<JanC> you need a 2.1 version, I guess?
<JanC> maybe just get a pymssql2 package into Debian  ;-)
<cpaelzer> good morning
<b4r> moin
<pitti> Good morning
<pitti> teward: how are non-ascii bytes choking up the hooks? UTF-8 should be fine and things will end up as str, for binary data you get byte arrays
<pitti> teward: i. e. if there's a particular hook that doesn't get along with that, that hook should be fixed; it's certainly not limited by design to ascii
<bdrung_work> pitti, hi. did you have time to look at https://github.com/bdrung/systemd/commit/2b824ccae61142cbcdaf251c2d3c996f933e217a
<pitti> bdrung_work: yes, I answered in #u-desktop; looks good to me, thanks!
 * bdrung_work should connect his personal and professional IRC client.
<bdrung_work> pitti, one open question: what value will testing/sid use?
<bdrung_work> (unstable)root@konstrukt:~# cat /etc/debian_version
<bdrung_work> stretch/sid
<bdrung_work> should the specification allow this value?
<pitti> bdrung_work: no, I don't think so
<pitti> either we can determine whether we are running unstable or testing, or it should not be set, or it should be one of the two
<pitti> "stretch/sid" is a rather useless and confusing value IMHO
<bdrung_work> should we enhance the specification to make that clear?
<pitti> but I wouldn't allow things like "or" (/) in that spec
<pitti> it already is -- '/' isn't allowed?
<bdrung_work> yes, '/' isn't allowed
<pitti> bdrung_work: lsb_release -a says "sid", and IMHO os-release should agree to that
<bdrung_work> other question: should we restrict the allowed characters even more? e.g. no underscore, dot, etc?
<pitti> bdrung_work: I don't know a reason why it shoudl be restricted further
<bdrung_work> underscore is not allowed in the distribution name in Debian and derivatives
<rbasak> cjwatson: do you have an opinion on bug 1588457 please?
<ubottu> bug 1588457 in openssh (Ubuntu) "UseDNS default changed to no, locking out authorized_keys from="hostname" users when upgrading to Xenial" [Undecided,New] https://launchpad.net/bugs/1588457
<cjwatson> rbasak: I don't think it would be wise to try to restore the old behaviour on upgrade; upstream made the change for a good reason.  IMO this is release notes kind of material
<rbasak> cjwatson: thanks. Do we change release notes post-release?
<cjwatson> Sure
<rbasak> I'll do that then and mark the bug Won't Fix. Thanks!
<cjwatson> Almost (but not quite) by definition - many release-notes-worthy issues are only discovered post-release
<cjwatson> I would consider adding a NEWS.Debian entry if that would be helpful
<cjwatson> (I did call it out in the changelog at the time)
<rbasak> I'm not sure how many users look at that nowadays but it does seem like the right thing to do.
<cjwatson> rbasak: https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=79139a04a0183cd47f3e837fa76fe5d51e62fcc9
<rbasak> Thank you!
<rbasak> pitti: may I have your opinion on bug 1588915 please?
<ubottu> bug 1588915 in openvpn (Ubuntu) "network dependent services starting before network is up" [Undecided,New] https://launchpad.net/bugs/1588915
<pitti> rbasak: followed up
<rbasak> pitti: thank you!
<pitti> yw!
<xnox> today is evil day
<teward> pitti: I swear there's at least six bug reports on it
<teward> I'll have to dig up bugs, I know sarnold filed several against packages which have had issues
<teward> though they problaby should have been dual-filed against Apport as well
<teward> since they were in the 'generic' apport hooks that apport runs for most bugs
<teward> pitti: here's one such bug that looks similar
<teward> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1582950
<ubottu> Launchpad bug 1582950 in ubiquity (Ubuntu) "broken apport hook: TypeError: a bytes-like object is required, not 'str'" [Undecided,New]
<teward> that one's for Ubiquity, yes, but the error string is one I've seen in many hooks
 * teward digs in nginx bugs
<teward> pitti: here's one, https://launchpadlibrarian.net/257302123/HookError_ubuntu.txt on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1577059 shows the hook error I'm referring to
<ubottu> Launchpad bug 1577059 in nginx (Ubuntu) "package nginx-core (not installed) failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurÃ¼ck" [Undecided,Incomplete]
<teward> and here (https://launchpadlibrarian.net/260081000/HookError_ubuntu.txt) - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1582954
<ubottu> Launchpad bug 1582954 in nginx (Ubuntu) "package nginx-light 1.10.0-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete]
<teward> in some cases my hooks get choked up, in others they don't
<teward> i'm more concerned about the "AttributeError: 'bytes' object has no attribute 'encode'" issue which appears to crop up most
<teward> and that's in general apport hooks, not package-specific
<caribou> ginggs: Are you working on merging clamav ?
<ginggs> caribou: no
<caribou> ginggs: ok fine, I'm taking care of it
<rbasak> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<cyphermox> howdy
<sil2100> !
<sil2100> Uh oh, sorry guys
<nacc> ogasawara: did you ever find out about the mainline builds for xenial?
<bjf> apw, ^ ?
<apw> nacc, ?
<nacc> apw: this page: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D shows mainline builds (4.6-rc6, e.g.) for wily and yakkety, but not xenial
<nacc> apw: a user was asking waht version to use to test on xenial for a possible mainline fix
<apw> nacc, those -<series> things tell you the config used not where it is suitable for
<nacc> apw: oh!
<nacc> that is ... confusing
<nacc> given the wiki page referring to it, i think
<apw> yea, i suspect we should remove the suffix completely
<nacc> apw: ok, so the user could use the -yakkety one ok on xenial? or would we not recommend that? i was worried about dependencies
<tjaalton> it's fine
<apw> nacc, mostly you should be ok, except when you arn't
<nacc> heh
<nacc> tjaalton: apw: ok, thanks!
<nacc> rbasak: around?
#ubuntu-devel 2016-06-07
<nacc> rbasak: i pusehd an updated to the tooling, `usd-merge` now exists as a 3-operation tool (tag, reconstruct, commit). Updated https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow heavily
<nacc> Still working on it, now will cross-ref with the other wiki page
<nacc> barry: --^ you may want to refer to that, i'm working on putting everything i know on there
<nacc> cpaelzer: are you ok if i use your graph as an example on the public wiki?
<barry> nacc: cool, thanks.  i'm planning on digging intot hat tomorrow
<nacc> barry: sure, i'm all ears on feedback, that wiki page is definitely WIP, i'll have more details in our merging process tmrw (but the references to the importer are pretty complete as much as i ahve them :)
<cpaelzer> good morning
<pitti> Good morning
<pitti> nacc: new php-defaults has been stuck in proposed because it makes php-imagick uninstallable apparently; is that on your radar by any chance? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults)
<FourDollars> Hi, does anyone know how to see the debug messages of indicator-bluetooth in Unity desktop environment?
<pitti> FourDollars: try .cache/upstart/indicator-bluetooth.log ?
<FourDollars> pitti: There is no such file.
<pitti> FourDollars: (that's relative to the home dir)
<pitti> FourDollars: do you have other indicator-*.log files there?
<FourDollars> pitti: Yes, I know.
<FourDollars> pitti: Yes, there are other gzip files.
<pitti> ah, so maybe check their timestamps, they might just have gotten rotated?
<FourDollars> There is no debug messages in those gzip files.
<pitti> FourDollars: ah, you probably need to restart the indicator process with G_MESSAGES_DEBUG=all
<pitti> and while you are at it, stop the upstart process and start it in a shell
<FourDollars> pitti++
<FourDollars> G_MESSAGES_DEBUG=all works!
<FourDollars> pitti: Thx a lot.
<pitti> works? nice
<FourDollars> I mean I can see the debug messages now. :D
<FourDollars> G_MESSAGES_DEBUG=all is what I need.
<jamespage> ok so I've forgotten how todo this:
<jamespage> I need to update /etc/default/ceph/ceph -> /etc/default/ceph for upgraders (note the double ceph in the current version)
<rbasak> pitti: regarding https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=0122291bfd445ad4afcdb4d59342e4bd009d526b, it is really useful to be able to hack a backend and have adt-run use it instead of the installed one. Will that still be possible if you're assuming path and prefix?
<jamespage> is that a mv_conffile /etc/default/ceph/ceph /etc/default/ceph ?
<rbasak> jamespage: yes but there might be an issue for directory -> file.
<rbasak> Since the maintscript helper expects to be able to leave files around in the same directory as the old conffile location.
<jamespage> yeah that's what I thought
 * jamespage scratches his head...
<rbasak> You might need to manually do what dpkg-maintscript-helper does but manually and tweak for the directory situation.
<rbasak> jamespage: another hack is to manually mess with the files it leaves behind in between steps
<jamespage> urgh
<rbasak> How about: on preinst, run dpkg-maintscript-helper as normal (manually, without debhelper), but then straight after rename /etc/default/ceph to /etc/default/ceph.renamed
<rbasak> Then in postinst, call dpkg-maintscript-helper but pretend you're renaming /etc/default/ceph.renamed/ceph to /etc/default/ceph.
<rbasak> Not sure about postrm abort-upgrade/abort-install handling. Ideally rename things back and then call dpkg-maintscript-helper with the old case again.
<pitti> rbasak: yes, it is; you just have to specify it with a path, i. e. it needs to have a '/' in it
<rbasak> pitti: ah good, thanks.
<pitti> rbasak: I'm waiting until tomorrow when 3.20.9 goes into testing, then upload 4.0, and when it's available in y and backports I'll write a blog post about the changes, as they are quite large
<pitti> (all backwards compatible, though)
<rbasak> Sounds good. I'd appreciate xenial-backports if that's the plan.
<pitti> rbasak: yes, I regularly backport new releases to t, w, and x
<pitti> check rmadison
<rbasak> Otherwise I was going to suggest SRUing the adt-buildvm-ubuntu-cloud yakkety URL change and the Python hashing workaround.
<rbasak> I was completely unaware of this! Will follow backports from now on. Thank you!
<pitti> xnox, infinity, tinoco: 10.100.0.13 has been AWOL since the weekend again, could you please prod it back into existence? thanks!
<tinoco> pitti: is this DEVACxx ?
<pitti> tinoco: I don't know what that means, but it's the aupkg02 s390x instance
<tinoco> ah ok
<tinoco> let me check
<pitti> tinoco: not sure why aupkg01 is fairly stable and 02 falls over every third day now, do they differ in something significant?
<tinoco> pitti: checking that right now
<tinoco> pitti: machine looks frozen
<tinoco> have u seen anything in kern.log/dmesg ?
<tinoco> ops
<tinoco> got it
<pitti> tinoco: I don't have any serial console or anything, just ssh
<tinoco> [430664.069248] INFO: rcu_sched detected stalls on CPUs/tasks:
<tinoco> [430664.069253]         (detected by 6, t=41022434 jiffies, g=7602, c=7601, q=66
<tinoco> 60)
<tinoco> [430664.069265] All QSes seen, last rcu_sched kthread activity 41022434 (4338003
<tinoco> 568-4296981134), jiffies_till_next_fqs=1, root ->qsmask 0x0
<tinoco> [430664.069290] rcu_sched kthread starved for 41022434 jiffies! g7602 c7601 f0x2
<tinoco>  s3 ->state=0x0
<tinoco> rcu detected a stall
<pitti> tinoco: I think that's what xnox saw the last time too
<tinoco> pitti: i could start this guest in another lpar
<tinoco> but.. do you mind if we get a dump ?
<pitti> tinoco: no, I don't urgently need the machine, we don't have a long queue ATM
<pitti> tinoco: so if you want to take this down for some investigation, that's fine
<tinoco> pitti: i wanted for you to enable kdump (-c 11,31)
<tinoco> and get me a dump on lockups
<tinoco> is that ok ?
<pitti> tinoco: sure, how does one do that?
<tinoco> (i dont have access to the machine and clearly some workload being generated is causing this)
<tinoco> pitti: i'll ask xnox to enable kdump on this machine
<pitti> tinoco: ack, thanks
<tinoco> pitti: tku
<tinoco> pitti: for now i'll reboot it
<pitti> tinoco: btw, I also have notes how to set up the partitioning, and a script to set up a fresh instance for autopkgtesting, so nothing on this thing is precious in any way
<tinoco> pitti: do you know what specific test caused this ? (as a reproducer ?)
<pitti> tinoco: no, I don't; I can check the journal what ran last, but it happens pretty often as I said
<tinoco> pitti: gotcha, yep.. let me check this.. i might ask you to start the test with kdump enabled for us to get a dump
<tinoco> pitti: im leaving for ~1h now.. ill get back to you on this
<pitti> tinoco: we can just let it run normally, something will trigger it very soon again, I'm sure :)
<pitti> tinoco: ok, thanks; no ssh yet, but as I said not urgent
<tinoco> im rebooting it
<tinoco> for now
<tinoco> pitti: i IPLed dasd 0200 again
<tinoco> i hope your OS was in there
<xnox> tinoco, pitti - sure enable kdump
<pitti> oh, it now says "No route to host", sounds like rebooting
<pitti> I'm in
<pitti> xnox: apt-get install kdump, and then?
<xnox> pitti, check that "crashkernel=196M" is in /etc/zipl.conf it should be
<xnox> and well reboot.
<tinoco> caribou: ^^ s390 kdump enablement for pitti, could u help ?
<tinoco> caribou: i have to leave for about 1h .. bbs
<pitti> "Should kexec-tools handle reboots?" -> I suppose "no" for now
<xnox> pitti, yes
<pitti> "Should kdump-tools be enabled by default?", I suppose "yes"
<xnox> otherwise you will not get kdump....
<pitti> xnox: installed; now I edit zipl.conf to add this to parameters=?
<pitti> done, how to enable this now?
<pitti> or is the boot process reading zipl.conf directly?
<xnox> $ sudo zipl
<cpaelzer> nice, launchpad auto recognizes that a git branch got merged as well
<cpaelzer> just curious is that based on a "Merge branch..." statement in a merge commit that is processed on a git push?
<cpaelzer> or asked otherwise - what has to be in the right form so that this works (it did for me aparrently)
<cpaelzer> rbasak: you remember we discussed that last week - approve does nothing as we expected and the merge got instantly autodetected
<cpaelzer> so just the way one wants it :-)
<pitti> tinoco, xnox: last test was apparently php-horde-imp, that doesn't sound particularly scary
<rbasak> cpaelzer: nice!
<rbasak> nacc: I just did a manual "reconstruct" for MySQL, and noticed that we might need special behaviour for new upstream versions imported into Ubuntu.
<rbasak> I'm not sure though.,
<pitti> xnox: rebooting, crossing fingers :)
<pitti> xnox, tinoco: it came back, and crashkernel=196M is in /proc/cmdline; so now let's wait unti it crashes again?
<xnox> pitti, ... yeah, and then a dump should be somewhere in /var/ after it next crashes and we reboot it.
<xnox> pitti, possibly next time it crashes we need to be on the cmdline to check that.....
<xnox> i guess we should have some monitoring for it.
<xnox> i wonder if i should just bring up openstack on two lpars for you, and just give you an openstack instead.
<xnox> however, that is slightly harder to maintain =/
<pitti> xnox: what's the status of getting z into bos02?
<pitti> that seems like a more maintainable way foward?
<sil2100> pitti: hey! So I seem to be experiencing the LP: #1453738 cryptswap bug as well right now after installing 16.04 cleanly on my new/old machine here
<ubottu> Launchpad bug 1453738 in ecryptfs-utils (Ubuntu Trusty) "installer in LVM mode sets up broken encrypted swap, using duplicate unencrypted swap" [Medium,Triaged] https://launchpad.net/bugs/1453738
<sil2100> pitti: should I attach my details to the same bug or fill in a separate one as you recommended?
<sil2100> (since I see people are just using the same bug still for it)
<pitti> sil2100: if you are sure it's the same bug, you can attach it there, of course
<pitti> I tried to repro it with LVM, no luck so far
<pitti> die, swap partitions, die!
<pitti> :/
<rbasak> pitti: in bug 1588915, the reporter responded that using network-online.target doesn't work either. Please could you take a look?
<ubottu> bug 1588915 in openvpn (Ubuntu) "network dependent services starting before network is up" [Undecided,New] https://launchpad.net/bugs/1588915
<rbasak> It seems a bit odd. I don't see why the NIC would drop the link.
<sil2100> pitti: not sure if that's the same, I didn't do anything special besides just using default installation settings + encrypted home directory
<sil2100> pitti: now on each boot I get that stupid prompt, same when installing certain packages
<sil2100> pitti: it annoys me greately ;)
<pitti> rbasak: yeah, that's weird indeed; can't do much if the link goes down again, I'm afraid
<pitti> sil2100: I guess just manually fix up/remove the broken swap partition for now?
 * pitti bbl
<caribou> xnox: pitti: crashkernel=196M is only needed until the new kdump-tools lands in yakkety
<nacc> pitti: it is now, will investigate
<shadeslayer> Is it possible to separate the accounts-plugins from the unity packages?
<nacc> rbasak: ack, i will look at that today
<shadeslayer> at the moment it depends on the gnome-control-center-signon source which depends on further unity packages ( unity-control-center, unity-settings-daemon, etc )
<shadeslayer> surely I don't need all of that to use the accounts-plugins?
<nacc> cpaelzer: asked last evening my time, but might have been missed -- are you ok if i re-use your ASCII graph from the wiki for the public documentation?
<nacc> shadeslayer: what's the package name? 'accounts-plugins' turns up no hits
<shadeslayer> https://bazaar.launchpad.net/~online-accounts/account-plugins/trunk/files
<nacc> account-plugins
<shadeslayer> right :)
<cpaelzer> nacc: yes I missed, but you are totally fine to use it
<shadeslayer> nacc: it needs libaccount-plugin-1.0-dev which comes from gnome-control-center-signon
<shadeslayer> though it seems I can build without libaccount-plugin support
<nacc> shadeslayer: but that's a source package, what binary package are you referring to of the ones it builds?
<nacc> shadeslayer: or do you mean for building, specifically?
<nacc> cpaelzer: np, thanks!
<shadeslayer> nacc: I mean for building specifically, it doesn't make sense to me that a package like account-plugins needs unity bits to work
<shadeslayer> for eg. KTP uses these plugins, but in order to build them I need to also build unity stuffs now :(
<shadeslayer> though I'll probably try to build it without libaccount-plugin support to see what happens
<shadeslayer> KTP ( KDE Telepathy )
<nacc> ah interesting
<nacc> i'm guessing that the build is specified with those deps so that it builds as-is (one or another binary target presumably fails)
<nacc> unless you do the configuration step you suggest, which would be a change
<nacc> i'm not sure, though
<nacc> rbasak: did you import mysql? want me to?
<rbasak> nacc: no thanks. I'd like to leave MySQL separate for now, because I also push commits to Debian.
<nacc> rbasak: ah ok, let me import locally and reproduce then
<shadeslayer> nacc: yeah, i'll probably have to fork the package because I'd rather not rebuild so much stuff :/
<shadeslayer> I'll see tomorrow
<nacc> shadeslayer: there are notions of build profiles, but i'm not sure it would apply here
<shadeslayer> I doubt it
<rbasak> nacc: I didn't actually try to use "usd-merge reconstruct" at all BTW. I just did it manually and thought that it might cause it to break. Something to think about, but it wasn't intended to be a bug report and I don't expect you to spend time fixing it right now :)
<shadeslayer> ( the entire problem being that I need that package on Debian and Debian does not have any of the unity bits )
<nacc> rbasak: ack
<nacc> rbasak: to be sure, mysql-5.7 is the src pkg?
<rbasak> nacc: yes
<rbasak> nacc: I pushed my tree to ~racb if you're interested. This contains the merge I just did manually in ubuntu/wip
<nacc> rbasak: thanks, will compare against it
<dannf> slangasek: i've pushed some changes to the installation guide that i'd like to SRU back into xenial, so i'd like to do a yakkety upload w/ those first. all the other queued changes are yours - are you good w/ that? and did you have other things you wanted backported to xenial?
<slangasek> dannf: hmm I was unaware I had anything queued
<dannf> oh - maybe bzr was just out of date - let me check
<dannf> slangasek: looks in sync (at least by version) - various changes about dropping "desktop" OS text
<slangasek> ah
<slangasek> I didn't upload those? ok :)
<dannf> slangasek: ok - will push. did you want those SRU'd? if you do, would you mind filing a bug for 'em?
<slangasek> dannf: fwiw I think all of those changes are appropriate for SRU; and I think the right way to SRU the installation-guide, being documentation, is a single metabug
<dannf> slangasek: ok - cool, that'll make my life easier :) i'll handle that
<slangasek> (SRU Test Case: do these words match the words we said they would match? okie-day)
<slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 12
<mdeslaur> ack
<bdrung_work> pitti, you opinion on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233466/comments/26 ?
<ubottu> Launchpad bug 1233466 in linux (Ubuntu) "Hot-Add Memory failing for lack of udev rule" [Medium,Confirmed]
<nacc> rbasak: ah i see what you mean -- also for that package, mysql-5.7 doesn't exist in debian, so our merge process doesn't work anyways (afaict)?
<jackdpeterson> Is this the appropriate channel to discuss livecd packaging issues?
<jackdpeterson> or, I suppose it would be an issue with the current release(s) of xenial64 and vagrant.
<rbasak> nacc: yeah I've been merging from Debian VCS (to which I've been pushing), which ends up being a bit hacky wrt. debian/changelog etc. I will upload to Debian experimental soon but am still working on it.
<rbasak> nacc: so I merge from there, which is a little confusing.
<rbasak> jackdpeterson: if you're wearing a developer hat then yes, I think this is probably the most appropriate place, unless there's some other channel I don't know about.
<jackdpeterson> Well, I'd be happy to attempt a pull request against whatever repository currently exists for performing the packaging for vagrant instances. https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1589721
<ubottu> Launchpad bug 1589721 in livecd-rootfs (Ubuntu) "vagrant username is incorrect" [Undecided,Confirmed]
<nacc> rbasak: right, and launchpad doesn't see any publishing hsitory
<nacc> rbasak: in theory, one could add a new remote pointing to debian vcs after the import is done
<rbasak> jackdpeterson: I'm not sure about the Vagrant side but Odd_Bloke may know.
<nacc> rbasak: and it might be able to work then
<rbasak> nacc: we do occasionally pull from some VCS somewhere over something in the Debian archive. It is pretty rare though. In this case I'm doing it because I wear both hats, but uploading to Debian is still painful for me (because we're not quite in sync yet but working on it)
<nacc> rbasak: won't spend more time on it now, but it's definitely not a use-case we had considered generally
<rbasak> nacc: I think it's safe to ignore for now.
<Odd_Bloke> jackdpeterson: Can you give basic reproduction instructions for the bug?
<nacc> rbasak: and i think most of the tooling is happy to try and use 'commitish' regardless of source
<jackdpeterson> Sure thing :-) i'll attach as a comment.
<Odd_Bloke> jackdpeterson: (I've marked the one you filed as a duplicate of the one you reference, so put it in there :)
<jackdpeterson> Okay, will do.
<Odd_Bloke> jackdpeterson: Uh, where "there" == "the older bug". :p
<rbasak> nacc: but more generally, there is much more common use case we might need to consider - what happens when Ubuntu pulls in new upstream versions ahead of Ubuntu. Does our merge process work correctly in that case with the new data structure?
<jackdpeterson> Yeah, made sense. I just wanted to file one under the right project so it could get appropriate visibility. But i'll add the comments to the older bug report.
<nacc> rbasak: i think i can test that with openipmi, will look
<jackdpeterson> Odd_Bloke: added comment -- https://bugs.launchpad.net/cloud-images/+bug/1569237/comments/8
<ubottu> Launchpad bug 1569237 in vagrant "vagrant xenial box is not provided with vagrant/vagrant username and password" [Undecided,New]
<Odd_Bloke> jackdpeterson: How long does that error show for?
<Odd_Bloke> jackdpeterson: (Because I would expect to see that until the machine is booted and SSH is up)
<Odd_Bloke> jackdpeterson: (Also, lets move this to #ubuntu-server; we're more likely to be in front of other Vagrant users there :)
<jackdpeterson> One moment, I'm running the same process but on the ubuntu/trusty64 one for compare/contrast. Effectively, performing vagrant ssh -- even after the vagrant up completes requests authenticaiton.
<jackdpeterson> compared to trusty64, which simply accepts a ssh username of vagrant and works with the private key autogenerated by vagrant.
<jackdpeterson> The ubuntu/xenial64 box, on the other hand fails to authenticate using the vagrant username and the autogenerated private key. This prevents next steps of provisioning using whatever provisioners are used (e.g., puppet or otherwise).
<Odd_Bloke> jackdpeterson: So I'm downloading the latest box to test; let's take this over to the #ubuntu-server channel though.
<jackdpeterson> Cheers, and switched channels.
<GunnarHj> bdmurray: Hi Brian, I got a couple of "increase in crash rate" mails due to the latest language-selector update in xenial:
<GunnarHj> https://errors.ubuntu.com/?release=Ubuntu%2016.04&package=language-selector&period=day&version=0.165.3
<GunnarHj> However, I don't seem to have access to see the nature of the issue. (Doubt it's really related to the latest change.)
<bdmurray> GunnarHj: I agreed its not related to the change. To be able to see crashes at the Error Tracker one must be a member of a specific Launchpad team, which you can join by filling out this form. https://forms.canonical.com/reports/
<GunnarHj> bdmurray: Thanks for confirming. Just requested access for l-s. (Is that kind of access package specific?? Assuming that at least core devs have access to everything...)
<rbasak> pitti: see bug 1588915 again please.
<ubottu> bug 1588915 in openvpn (Ubuntu) "network dependent services starting before network is up" [Undecided,New] https://launchpad.net/bugs/1588915
<bdmurray> GunnarHj: just like bug control its not package specific
<GunnarHj> bdmurray: Aha, I see. Thanks again.
<nacc> rbasak: just sent you a git MR for a very simple merge with our process, using only our helper tools (and git-rebase -i)
<nacc> rbasak: i think what we'd do upon 'approval' is the final step would be for the uploader/pusher (presuming the MR submitter not having rights) would need to run `usd-merge commit ubuntu/<series>` to parent the HEAD commit into the right place
<nacc> pitti: i think we can sync php-imagick, but let me verify that and i'll submit the request
#ubuntu-devel 2016-06-08
<Logan> hyperair: FYI, arm64 needs to be added to the architecture list for libgpod-cil(-dev) as well to fully make it a mono arch :)
<Logan> (I was looking at syncing, but 0.8.3-7 doesn't include that change we have in Ubuntu)
<hyperair> oops
<hyperair> wait a sec, does mono work on arm64 in debian?
<hyperair> Logan: ^
<Logan> hyperair: it's in the architecture list, so I guess so :P
<hyperair> hm
<sarnold> add an autopkgtest and find out if it fails on http://autopkgtest.ubuntu.com/packages/m/mono/  later? :)
<sarnold> oh :/ no arm64 there either
<hyperair> https://packages.debian.org/sid/mono-runtime-sgen does have arm64 though
<sarnold> pitti: hey, sys-kernel-debug.mount feels like a mistake. I don't think debugfs is robust enough to justify auto-mounting everywhere..
<pitti> bdrung_work: as I wrote in the bug, my opinion is that this should be fixed in the kernel and working around it in userspace is silly :)
<pitti> bdrung_work: followed up
<pitti> rbasak: followed up
<pitti> smoser: do you know why http://cloud-images.ubuntu.com/yakkety/current/ points to 0529 while there are thee newer images from June?
<seb128> bdmurray, hey, is there possible to have a recent bt of a report from https://errors.ubuntu.com/problem/590ab412d186298ada0ae288838a0256fe6e76e4 ?
<seb128> mdeslaur, hey, unsure if you saw but bug #1580597 started with the 1.8.16 sudo update, unsure if it's an important issue but it has some thousands report and sudo is kind of an important component, so I'm just pointing it out
<ubottu> bug 1580597 in sudo (Ubuntu) "/usr/bin/sudo:11:kill:main" [Undecided,New] https://launchpad.net/bugs/1580597
<Odd_Bloke> pitti: The current symlink doesn't get updated until the end of the publication process; I believe that we were having issues with MAAS image stream generation, and now the ProdStack outage is blocking us. :)
<pitti> Odd_Bloke: oh, is PS still out? my part of it seems to work
<pitti> Odd_Bloke: thanks for the heads-up, so this is "known"
<pitti> Odd_Bloke: but the PS outage was yesterday, first non-current image was already a week ago
<Odd_Bloke> pitti: Yeah, the MAAS issue got fixed just before the outage, so there hasn't been a successful build since then due to the outage.
<Odd_Bloke> pitti: (I've just kicked one off :)
<pitti> smoser: ^ unping
<pitti> Odd_Bloke: hah, go timing :)
<Odd_Bloke> Anyone around who installed a desktop from a xenial ISO who could pastebin their sources.list for me?
<pitti> infinity: any idea how I find out what still keeps "initscripts" as "priority: required"? none of its rdepends are required, and it's not in the "required" seed
 * pitti wants it gone from a default install
<pitti> and I can purge it without any complaints
<cjwatson> pitti: nothing
<cjwatson> <cjwatson@niejwein ~>$ ssh -t snakefruit sudo -iu ubuntu-archive chdist apt-cache yakkety-amd64 show initscripts | grep ^Priority:
<cjwatson> Priority: optional
<pitti> cjwatson: hmm, shouldn't it be in http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt then?
<cjwatson> pitti: no, because it's already optional
<pitti> whee, why does it say "Priority: required" here
<pitti> aah, old cloud image, I suppose
<pitti> cjwatson: *brown paperbag*, thanks
<cjwatson> :)
<pitti> cjwatson: I'm considering dropping Vcs-Bzr: from cdebconf when merging; the overhead of merging from git into bzr is not justified IMHO, and there hasn't been any Ubuntu development on this package for years; just applying the MoM debdiff is so much easier; WDYT?
<cjwatson> pitti: don't care :)
<pitti> what I thought, thanks
<pitti> kirkland, tyhicks: who is looking into ecryptfs these days? bug 1447282 has a new case (fails for NVME partitions), but I keep not having enough time for this
<ubottu> bug 1447282 in ecryptfs-utils (Ubuntu Yakkety) "Does not use encrypted swap when using GPT partitioning + encrypted home directory (ecryptfs)" [High,Triaged] https://launchpad.net/bugs/1447282
<pitti> I might get to it eventually, but it keeps getting pushed down the list
<pitti> i. e. any chance someone might get to this earlier than me?
<seb128> mdeslaur, hey, sorry I screwed my session and was out of IRC while at lunch ... I saw you commented on one of the sudo segfault bugs, thanks ;-)
<mdeslaur> seb128: yeah, not sure what the fix is though, needs an upstream bug
<seb128> mdeslaur, I looked a bit at the cmd used in the different report, nothing special
<mdeslaur> yeah, not exactly sure what's going on, I think sudo tries to kill itself, hangs, then gets an abort....or something.
<sil2100> pitti: hey! Since I don't have the knowledge/power to help here, could you take a look on why https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html i386 test seems to be in progress but not visible on http://autopkgtest.ubuntu.com/running.shtml ?
<pitti> sil2100: supposedly fallout from the PS outage, re-queued
<sil2100> pitti: thank you!
<ChrisTownsend> pitti: Hey, did the i386 test for https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html run?
<pitti> ChrisTownsend: yes it did, see sil2100's ping from half an houru ago
<pitti> ChrisTownsend: you can check at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051?format=plain&prefix=xenial/i386/c/content-hub
<pitti> ChrisTownsend: (totally obvious URL, isn't it? :-)
<pitti> next britney run will pick this up
<ChrisTownsend> pitti: Oh, ok, thanks.  Nice URL, btw:)
<pitti> and it passed: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051/xenial/i386/c/content-hub/20160608_130942@/log.gz
<ChrisTownsend> pitti: Awesome\o/
<rharper> rbasak: bug 1491406 , I nominated for trusty; who would be able to add that task ?
<ubottu> bug 1491406 in augeas (Ubuntu) "augeas-lenses-1.2.0 - NagiosCfg lens broken for /etc/nagios.cfg due to spaces" [Undecided,Invalid] https://launchpad.net/bugs/1491406
<rbasak> rharper: added. It needs an uploader or someone on the bug control team AIUI. The community process is to ask in the #ubuntu-bugs IRC channel. I watch that too so will happily do it.
<rharper> rbasak: awesome, thanks
<pitti> rharper: good morning, how are you?
<rharper> pitti: good, and you ?
<pitti> rharper: quite okay, cold is getting better, thanks
<nacc> rbasak: did my logic in the MR make sense (for what the 'uploader' would do?)
<mvo> arges: hi, do you think you could check #1589534 ? we need a snapd  2.0.8 with a store refresh fix over the current 2.0.7 into xenial-proposed. sorry for the trouble, let me know if anything is missing in that bugreport (iirc you are today on sru call, if not my appolgizes)
<arges> mvo: ok looking
<arges> mvo: assuming this is fixed in yakkety?
<mvo> arges: yeah, yakkety has 2.0.8+16.10 which is identical to the sru except for version in the changelog
<arges> mvo: ok i'll mark the development task as fixed
<mvo> arges: please let me know if there is anything I can do to make your life easier, I know we are a bit of a burden with the amount of srus right now
<arges> mvo: reviewing it now
<rbasak> nacc: yes, that makes sense.
<rbasak> nacc: it would be magic if the uploader could itself create the merge commit, but I'm not sure that's possible.
<rbasak> nacc: also, although proposing the MP against debian/sid seems to work, it "feels wrong" as the result is not that debian/sid will end up with the branch as an ancestor. I might experiment and see what happens if I submit an MP against ubuntu/devel (or ubuntu/yakkety for now).
<arges> mvo: ok accepted
<mvo> arges:  \o/
 * mvo hugs arges
<arges> heh
<pitti> smb, arges: grep xenial-updates was a little premature
<pitti> verification instructions said "wait on the archive rebuild on x or y" which didn't happen yet (doko has planned to do it RSN, though)
<arges> pitti: it was 7 wasnt it?
<pitti> not much immediate harm, it could at most be that we now rendered some packages in xenial FTBFS
<pitti> but we'll still find them during the test rebuild and fix in y if needed
<infinity> pitti: We probably fixed more than we broke. ;)
<pitti> (and backport those along)
<pitti> yeah, I agree, just saying that this was originally agreed on waiting for the test rebuild
<infinity> Yep.
<pitti> not an alarm bell at all
<pitti> anyway, time for dinner :)
<arges> pitti: thanks for letting me know sorry about that
<rbasak> nacc: I just uploaded your SRU debdiffs for bug 997172 while I was there. Did you actually want them uploaded now? It just occurred to me that you hadn't subscribed ~ubuntu-sponsors again and did upload to a PPA.
<ubottu> bug 997172 in smbldap-tools (Ubuntu Xenial) "[SRU] smbldap-config.pl not installed" [Undecided,New] https://launchpad.net/bugs/997172
<nacc> rbasak: should be fine, was about to subscribe sponsors and request the sru officially anyways
<nacc> rbasak: thanks
<teward> if a package in Ubuntu is version 1.0.2+dfsg-2, and needs fixed in both Yakkety and Xenial (via SRU), would the versions become 1.0.2+dfsg-2ubuntu1 (Yakkety) and 1.0.2+dfsg-2ubuntu0.16.04.1 (Xenial)?
<cjwatson> that sounds right
<nacc> seems to agree with the wiki page
<teward> cjwatson: nacc: that's what I thought, wasn't sure if the dfsg was going to throw anything off :P
 * teward is mass-preparing debdiffs for a High bug he's gunning to fix right now.
<teward> (though, not in anything major :P)
<cjwatson> the +dfsg isn't relevant here, no
<teward> cool :)
<teward> cjwatson: nacc: thank you both for the sanity check on my brain :)
<teward> definitely appreciated :)
<nacc> slangasek: question re:dh-php for you. Debian has introduced another dep for dh-php (xml2). Rather than MIR dh-php, would it make sense to make dh-php a Suggests in php7.0-dev and thus demote dh-php to universe?
<nacc> (right now dh-php is a recommends)
<nacc> slangasek: another question re: php-imagick. Debian decided to go with the MAGICK_THREAD_LIMIT=1 in debian/tests/control rather than setting the resource limit via a patch to the source. Would you prefer we keep the latter delta and not set the environment variable? Or drop the delta and use the same workaround that Debian does?
<infinity> nacc: If it's required to make the tests pass, does that not imply that it's also required to make it work right at runtime?
<infinity> nacc: If so, Debian's solution is incorrect, and you should tell them as much.
<infinity> The goal of testsuites isn't to make the testsuite pass at all costs, it's to test the runtime functionality. :P
<nacc> infinity: yep, I get that
<nacc> infinity: the issue is, it's not somethign that's 100% repeatable
<nacc> afaict
<nacc> there is a raciness somewhere
<nacc> but it doesn't necessarily happen on everyone's system
<mwhudson> infinity: purist
<nacc> infinity: i agree with your sentiment, i'll keep the delta for safety's sake and send it to debian
<nacc> infinity: they should take the rest of our delta too and we should be able to sync after that
<infinity> nacc: Upstreaming the patch wouldn't be a terrible idea.
<nacc> infinity: upstream consider it a workaround, have it documented on their page, but won't take a patch to chagne the source
<nacc> infinity: as it's distro-specific (apparently) where it's necessary
<nacc> Logan: fyi, i have my merge for phpunit-mock-object done, but it's going to fail due to needing phpunit to update (and phpunit is currently failing to build) -- i'm investigating that now
<nacc> Logan: phpunit fails to build because php-codecoverage fails to build ...
<nacc> Logan: hrm, the php-codecoverage may just need to be a manual rebuild, as it does build now for me in a sbuild (although it fails the tests), investigating that
<nacc> and the tests fail becasue they need the newer phpunit...
<nacc> slangasek: --^ sound familiar :/ ... reviewing my notes now
<slangasek> nacc: hmm does not sound familiar
<nacc> slangasek: was mostly joking, we went through this w/ 16.04
<nacc> it's the same bootstrap stuff
<slangasek> ah
<slangasek> but we didn't actually have to bootstrap anything! :)
<nacc> will just use my old algorithm, hopefully it still applies
<nacc> yeah, we got lucky :)
<nacc> slangasek: would appreciate your feedback on the two merge queries from a few hours ago, but no urgency. I think the imagick one is clear to me now after infinity's feedback, just wanted to verify.
<slangasek> nacc: oops, missed them - looking now
<nacc> slangasek: np, thanks!
<slangasek> nacc: dh-php> yes, that seems ok to drop from Recommends to Suggests
<slangasek> nacc: the php-imagick one, I agree with infinity :)
<nacc> slangasek: perfect, thanks on both counts!
#ubuntu-devel 2016-06-09
<nacc> slangasek: so php7.0.7 has grown a new binary package (php7.0-dba), which is trying to live in main. It has a build and runtime dependency that live in universe, though, so excuses doesn't like that. Do we need to provide a hint somewhere that php7.0-dba should be in universe?
<infinity> nacc: Nope, just needs to be demoted.  Doing now.
<lifelong0811> Can anybody tell how to attend a develop project of ubuntu
<Logan> nacc: what a mess, lol
<Logan> the FTBFS page is starting to fill up with PHP packages :X
<Logan> and a lot of them won't transition to release because of failing autopkgtests...because of phpunit :'(
<cpaelzer> good morning
<pitti> Good morning
<smb> pitti, morning. Man, there one tries to be helpful and actually verify the grep thing and of course that's some kind of wrong again. :)
<smb> cpaelzer, morning
<pitti> smb: sorry, don't take this as a "you did wrong" (thanks for helping!), I just wanted to explain why this didn't get v-done for so long
<smb> pitti, Oh no worries. I thought you knew me well enough to know I don't feel blamed here
<mwhudson> pitti: i saw the docker.io autopkgtests running earlier, i thought they got blacklisted?
<mwhudson> pitti: i see that docker migrated but i can't tell if they failed normally or you readded them to the blacklist or maybe they even passed
<pitti> mwhudson: they didn't run, and I didn't hint it; I suppose it migrated because the tests are "always failed"?
<pitti> http://autopkgtest.ubuntu.com/packages/d/docker.io/
<mwhudson> pitti: huh guess so
<pitti> and they did run+succeed on armhf/s390x (i. e. in LXC)
<mwhudson> pitti: pretty sure i saw it on running.shtml though
<pitti> mwhudson: presumably on the LXC platforms?
<mwhudson> pitti: yeah, they don't really do anything in LXC though :-)
<pitti> integration          SKIP Test requires machine-level isolation but testbed does not provide that
<mwhudson> i thought it was i386 but well
<pitti> heh, yes
<mwhudson> not going to worry overmuch about it
<mwhudson> oh wait, it did run on i386
<mwhudson> http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/i386/
<pitti> mwhudson: ah right, I only blacklisted amd64
<pitti> fails to install
<mwhudson> yeah, that actually looks potentially interesting
<pitti> but as it's alwaysfail, the tests don't protect against regressions
<mwhudson> yeah, happens on amd64 too
<mwhudson> whoops!
<mwhudson> pitti: huh -s doesn't work for uninstallable packages?
<pitti> mwhudson: that sounds fixable
<pitti> mwhudson: untested, but should work: http://paste.ubuntu.com/17138812/
<pitti> (brb)
<Skuggen> Nice. My control file caused apt-get to segfault
<mwhudson> well i no longer know how docker works
<bdrung_work> pitti, I agree. it should be fixed in the kernel
<rbasak> pitti: are you dealing with NIC renaming fallout? Bug 1519120 has a patch for vlan.
<ubottu> bug 1519120 in network-manager (Ubuntu) "Xenial: VLAN interfaces don't work until after a reboot" [Undecided,Confirmed] https://launchpad.net/bugs/1519120
<rbasak> (but I wouldn't be comfortable considering it without your review)
<pitti> rbasak: looks straightforward enough to me; I've never used the vlan package though, but this looks plausible
<dosaboy> bdmurray: hey, is 1524989 good to land in -updates anytime soon?
<cpaelzer> rbasak: RAOF: hey, I took a look at bug 1524526 and after some analysis I came up with a fix that (maybe) wan't anticipated - drop the lucene-plugin completely
<ubottu> bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526
<cpaelzer> rbasak: RAOF: I've given detailed reasons in the bug, but that certainly is worth a discussion if you would second that approach
<cpaelzer> rbasak: RAOF: therefore pinging you in IRC about it
<cpaelzer> TL;DR: it never worked + is deprecated by the upstream project - so why going for a potentially complex and error prone fix
<cpaelzer> there surely is some darkness to removing packages I don't (want to) know that bites me with that suggestion :-)
<rbasak> cpaelzer: thank you for the analysis. Your suggestion seems reasonable. Do we know what Debian think of this?
<rbasak> And does this affect Debian too?
<cpaelzer> rbasak: forgot to mention ... checking debian on this
<lundmar> Hi, can I suggest that Ubuntu 16.04 add/enables completion support for installed snaps?
<ogra_> lundmar, i think there is a bug already (and there is the #snappy channel too ;) )
<lundmar> ogra_: thanks, I'll go #snappy
<mdeslaur> xavigarcia: any idea why xenial shows a muted volume notification when I get to lightdm, and right after logging in?
<cpaelzer> rbasak: Debian has the dependency that is in question enabled, since they don't have to care abotu main/univese
<cpaelzer> I updated the bug so that all information is in one place
<cpaelzer> We removed that build dependency on our merges
<cpaelzer> not realizing it is breaking things
<xavigarcia> mdeslaur, hhmm no idea. I should take a look myself...
<mdeslaur> xavigarcia: has anyone reported that before?
<xavigarcia> mseslaur: I don't think so... at least that I remember
<xavigarcia> mdeslaur: does it only happen in Xenial?
<mdeslaur> xavigarcia: it didn't happen in wily, and I upgraded my laptop to xenial last week and that's when it started
<cpaelzer> rbasak: If we all agree on the approach, dovecot could by my first more complex merge also trying the importer
<xavigarcia> mdeslaur: ok... then maybe it should be good to fill a bug
<cpaelzer> rbasak: how would "dropping" a package being done as SRU (would it?)
<cpaelzer> rbasak: the old broken ones will be always in the archive right
<mdeslaur> xavigarcia: against what package, indicator-sound?
<seb128> mdeslaur, if you restart the indicator does it display the notification as well?
<xavigarcia> mdeslaur: yep
<mdeslaur> seb128: yes, if I kill it, it respawns and displays it
<seb128> mdeslaur, k, so it gets some sort of event on start, might make easier to debug
<seb128> mdeslaur, is there anything in .cache/upstart/indicator-sound.log?
<mdeslaur> (process:15411): indicator-sound-WARNING **: volume-control-pulse.vala:744: Unab
<mdeslaur> le to connect to dbus server at 'unix:path=/run/user/1000/pulse/dbus-socket': Co
<mdeslaur> uld not connect: No such file or directory
<seb128> mdeslaur, I don't have that socket either but neither I get the warning
<seb128> xavigarcia, ^ is that something you saw before?
<xavigarcia> mdeslaur:mmmm nope... it seems pulse is not running properly
<seb128> xavigarcia, I don't have that socket either on my system though?
<xavigarcia> seb128: let me check mine
<mdeslaur> sorry, my network died
<mdeslaur> did I miss anything?
<seb128> mdeslaur,
<seb128> <seb128> mdeslaur, I don't have that socket either but neither I get the warning
<seb128> <xavigarcia> mdeslaur:mmmm nope... it seems pulse is not running properly
<mdeslaur> huh
<seb128> <seb128> xavigarcia, I don't have that socket either on my system though?
<seb128> internet suggests that we don't load the pulseaudio dbus module by default on Ubuntu
<seb128> unsure if that's true
<seb128> mdeslaur, you don't have a weird pulse config like by-session mode or something
<seb128> just in case
<xavigarcia> seb128: Me either, but I remember the socket is used only at a certain point
<mdeslaur> Hrm, whatever I have is the default
<seb128> mdeslaur, I guess you can try to restart pulseaudio in debug and share the log
<mdeslaur> or at least was the default when I installed a few releases ago
<mdeslaur> let me file a bug first, one sec
<seb128> no weird security-snappy version
<seb128> or confinement? ;-)
<seb128> of pulseaudio
<ogra_> werid ?
<ogra_> what do you mean by that ?
<ogra_> :P
<seb128> lalala
<seb128> ;-)
<ogra_> *grin*
<mdeslaur> nothing weird, just a standard xenial desktop
<mdeslaur> no snappy anything, no non-default confinement
<mdeslaur> ok, filed bug 1590769
<ubottu> bug 1590769 in indicator-sound (Ubuntu) "muted notification is displayed when indicator is started" [Undecided,New] https://launchpad.net/bugs/1590769
<xavigarcia> mdeslaur: cool, I'll take a look to the bug, thanks!
<mdeslaur> xavigarcia: let me know if you need anything, or want me to try anything
<xavigarcia> mdeslaur: sure, thanks
<seb128> mdeslaur, can you get the pulseaudio log?
<seb128> mdeslaur, https://wiki.ubuntu.com/PulseAudio/Log
<rbasak> cpaelzer: I'm not sure it's worth doing an SRU to remove the package. It's unusable now and it'd be unusable after the SRU so I'm not sure it's worth any regression risk.
<rbasak> cpaelzer: I'm open to opinions on that though.
<mdeslaur> seb128: sure, adding to bug
<RAOF> cpaelzer: I'm happy with dropping the lucene plugin. At the point I started playing with this upstream hadn't deprecated the plugin :)
<cpaelzer> RAOF: hi, didn't expect you around yet - thanks for the feedback
<RAOF> cpaelzer: I'm in MontrÃ©al :)
<cpaelzer> rbasak: RAOF: you are right it is broken before and after - but before (like now) installing and configuring it can break the other parts of dovecot
<cpaelzer> RAOF: ah directory told me something mroe around the globe - sry
<cpaelzer> RAOF: temporary?
<RAOF> cpaelzer: Oh, I *live* in Hobart; I'm at a sprint.
<cpaelzer> things make sense now :-)
<cpaelzer> rbasak: I'm not voting for an SRU in any way, especially not for a complex one, but bumping it by one version and adding a breaks dovecot-core might prevent more fallout
<cpaelzer> and inY it can be still dropped
<seb128> mdeslaur, thanks, I don't see anything talking to be but let see if the audio guys have more clue ;-)
<rbasak> cpaelzer: that's a good point. If we're going to add a Breaks though, might as well remove it.
<smoser> doko, around ?
<rbasak> cpaelzer: maybe we should get someone from the SRU team to weigh in.
<cpaelzer> rbasak: I didn't know if removing is possible
<smoser> i'm looking at bug 1584147 .
<ubottu> bug 1584147 in cloud-images "cloud-init hangs on boot as Python waits for sufficient randomness to start" [High,Confirmed] https://launchpad.net/bugs/1584147
<rbasak> cpaelzer: it isn't, but we can make it an empty package.
<cpaelzer> rbasak: ok, that is kind of removed
<smoser> i will verify that the debdiff at http://paste.ubuntu.com/17143030/ fixes it, but would you want to do that in debian ?
<cpaelzer> rbasak: I agree that we need the SRU team to share their opinion on it, but IIRC we need to do it in the devel release first (I wonder if that applied here as well)
<cpaelzer> rbasak: so one would need to do the merge to .24 and change the behaviour in Y and THEN push to the SRU Team for their preferred approach into X
<cpaelzer> rbasak: does that sound right?
<rbasak> cpaelzer: yeah that sounds right. I wonder if we need to do anything for an upgrade path in Yakkety.
 * rbasak examines https://wiki.debian.org/PackageTransition
<rbasak> Perhaps case 11, but I'm not sure. I would consult Adam or Colin or someone :)
<cpaelzer> rbasak: there are no special conffiles to the pludin, and since nobody ever was able to enable it we can't hurt somebody
<rbasak> cpaelzer: yes but I want to ensure it gets removed on upgrade rather than an old one hanging around.
<rbasak> cpaelzer: unless the existing relations would force that anyway
<cpaelzer> rbasak: let me nnote that in the bug, modify it that it becomes a merge bug, and ask them on the real case then
<cpaelzer> rbasak: probably easier to discuss that on the prepared real example then right?
<rbasak> cpaelzer: yes
<rbasak> cpaelzer: also we'll want to do what Debian wants to do to save any future merge pain
<cpaelzer> rbasak: Debian hasn't an issue with the main/universe - so they do nothing
<cpaelzer> rbasak: the plugin isn't deprecated enough yet that they would drop it
<rbasak> cpaelzer: oh - lucene isn't broken on Debian?
<cpaelzer> rbasak: our merges always dropped the dependency
<rbasak> Sorry, I missed that.
<rbasak> OK, sounds like you're more on top of this than I am :)
<cpaelzer> rbasak: about 1:10 back in the log
<rbasak> I did miss that, sorry.
<cpaelzer> rbasak: I'll try to go on on this and you feel free to interrupt or help whenever you think so - thanks for the support already
<rbasak> cpaelzer: great. Thanks for driving!
<clivejo> is there anyone here would sponsor uploads?
<rbasak> clivejo: I suggest you specify what it is. People don't like committing to an unbounded amount of reviewing time, and different devs will take different amounts of time to review something depending on their familiarity in the area.
<clivejo> Im trying to get KDE software packaged and into the archive
<rbasak> clivejo: do you know about the sponsorship queue?
<rbasak> clivejo: https://wiki.ubuntu.com/SponsorshipProcess and http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
<clivejo> is there anyone here working on Qt?
<dobey> clivejo: mirv is our main qt person, but he's away until mid july
<clivejo> who is Timo?
<ogra_> he is mirv
<Saviq> pitti, hey, when trying to recycle https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html mterry got "You submitted an invalid request: Unknown release vivid" - is that known/expected?
<pitti> Saviq: probably fallout from the debci reconstruction; I'll look at it ASAP (meeting prep first)
<pitti> die, vivid, die :)
<pitti> Saviq: fixed and retried
<nacc> infinity: thanks!
<nacc> Logan: yep, i'm pushing that to the top of my list
<doko> smoser, I'd like to wait for the final upstream patch
<smoser> doko, well, it went in
<smoser> and i assume we'll grab 3.5.2 when it releases end of June.
<smoser> so this is very short time, right ?
<doko> yep
<smoser> but its very painful for cloud images
<smoser> like 6 minute boots rather than 10 seconds.
<smoser> doko, i was just about to uplaod http://paste.ubuntu.com/17144867/
<smoser> verified it fixes our issues in a patched vm.
<smoser> i dont want to step on your toes, but i dont want to wait 3 weeks for a fix either.
<pitti> yeah, huge pain on the autopkgtest side too
<rbasak> Please add the Ubuntu delta. I think it's too painful to wait.
<rbasak> If it's only the delta, it should be trivial to sync once Debian is fixed, right?
<smoser> right. its our only delta from debian, and can just be dropped at 3.5.2 release.
<smoser> http://paste.ubuntu.com/17144921/ <-- no longer includes the hashset named patch that was unused.
<doko> smoser, well, the patch isn't yet final. the discussion continues on the ML. not sure why you can't fix cloud-init to set the env var at this point
<rbasak> How about we just revert the upstream commit that broke it then until they have committed a final fix?
<rbasak> We can't commit stuff that everyone agrees breaks things and then sit on it for weeks. That's hardly continuous quality.
<doko> there will be a final fix this Monday. why rush this now?
<smoser> i can change cloud-init, but carrying delta in that one package (using PYTHON_HASHSEED=99) just pushes it off to the next consumer
<smoser> why a final fix this monday ?
<rbasak> doko: because the longer we wait, the bigger the fallout because we blocked development and QA for longer.
<smoser> i'm not aware of python developmetn process. i assumed its incorporation into trunk  and then also into the 3.5 branch meant final.
<rbasak> What's the fallout in just reverting the broken upstream commit?
<smoser> what did you mean by 'final' ?
<doko> because 3.5.2 final will have this fix
<smoser> you mean the release candidate.
<smoser> dueo Sunday June 12.
<smoser> doko, if you're going to pick that up and have it in debian and ubuntu on Sunday/Monday, then i'm ok to wait. but even then all we have to do to revert my 4 day patch would be to sync from debian.
<smoser> (release schedule https://www.python.org/dev/peps/pep-0478/ )
<doko> see the thread starting at https://mail.python.org/pipermail/python-dev/2016-June/144939.html
<pitti> smoser: I thought PYTHONHASHSEED wasn't sufficient?
<pitti> because of "import random"?
<pitti> I already added the workaround to autopkgtest, if that workaroud would work for cloud-init, then we could apply it, but I thought it doesn't
<smoser> pitti, right. it is not sufficient.
<pitti> the only other known victim so far is systemd-cron, but that's not that interesting/urgent
<smoser> i was working on a change yesterday to work around that too. but *still* all that does is push it off to the next consumer.
<pitti> indeed, so we don't have a workaround, and applying the fix or reverting the original commit are our only options
<smoser> and honestly, me changing cloud-init for 5 days to work around a bug seems worse than fixing the package for the interim time.
<smoser> https://mail.python.org/pipermail/python-dev/2016-June/144939.html is a good read.
<rbasak> doko: why do you want to defer fixing the python package right now?
<rbasak> (whether it's reverting the original commit or applying an intermediate fix I don't care)
<doko> rbasak, I'd like to avoid a differing behaviour in the Ubuntu package. I escalated this as a release blockerlast weekend, and with a fix promised for this weekend
<rbasak> doko: why would a differing behaviour in the Ubuntu package be a problem if it only lasts for four days? Surely the differing behaviour that unblocks people is a good thing?
<ddellav> can someone please promote these py3 packages to main? their py2 counterparts have already been included: http://paste.ubuntu.com/17145451/
<doko> rbasak, why does it block you now, and not two weeks ago?
<pitti> it has been a real nuisance/blocker for all that time :)
<pitti> I just wouldn't like to wait three more
<pitti> at least for me this essentially causes half a cloud to not work for testing (why it's working on the other is related to another issue, it's complicated)
<Saviq> pitti, thanks
<ddellav> coreycb jamespage monascaclient MIR submitted, please review and I'll add the ubuntu-mir team subscriber: https://bugs.launchpad.net/ubuntu/+source/python-monascaclient/+bug/1590836 also I dropped a message in #ubuntu-devel for someone to promote these packages for the MIR: http://paste.ubuntu.com/17145451/
<ubottu> Launchpad bug 1590836 in python-monascaclient (Ubuntu) "[MIR] python-monascaclient" [Undecided,New]
<doko> mehh ... well, updating to the branch then ...
<ddellav> I also need python-microversion-parse & python-yaql to be promoted, MIRs are complete and approved: https://bugs.launchpad.net/ubuntu/+source/python-microversion-parse/+bug/1586061 https://bugs.launchpad.net/ubuntu/+source/python-yaql/+bug/1586069 respectively.
<ubottu> Launchpad bug 1586061 in python-microversion-parse (Ubuntu) "[MIR] python-microversion-parse" [Undecided,Fix committed]
<ubottu> Launchpad bug 1586069 in python-yaql (Ubuntu) "[MIR] python-yaql" [Undecided,Fix committed]
<coreycb> ddellav, python-monascaclient bug looks good. I subscribed our team to bugs for it.
<ddellav> coreycb ok, subscribed the mir team
<pitti> cyphermox: can NM be told to create bridges and bonds?
<pitti> (I thought it could)
<cyphermox> yeah, it can
<cyphermox> you in fact have two different ways to do bonds, using the standard method, or using libteam
<cyphermox> part of it we may have disabled because it was slightly broken in the past, but it's worth looking at again
<smoser> doko, it did block us painfully 2 weeks ago just as it does today. the difference is there is an upstream incorporated fix now.
<smoser> well, BDFL responds at https://mail.python.org/pipermail/python-dev/2016-June/144953.html
<smoser> i could respond to him and say i should get the prize
<smoser> as cloud-init would hit that warning all the time.
<pitti> cyphermox: thansk
<rbasak> smoser: I think you should reply :)
<pitti> smoser: heh, so does autopkgtest :)
<pitti> (without the workaround)
<nacc> elbrus: do you have any idea what this might be: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/c/cacti/20160609_124337@/log.gz (cacti regression on armhf with the latest php7.0)
<nacc> elbrus: might be a transient timeout, it's hard for me to tell immediately
<nacc> rbasak: fyi, i sent a PR to you on github for ubuntu-git-tools: https://github.com/basak/ubuntu-git-tools/pull/2 which will be needed to use the importer
<rbasak> nacc: ah yes. I want to just move that all into the importer tree.
<rbasak> nacc: sorry I forgot about that. I meant to mention it.
<nacc> rbasak: yeah, are you ok if i import it directly (i'll replay the history)
<rbasak> nacc: sure. I suggest you create a commit to rename or move it to a subdirectory as necessary, then create a merge commit that pulls in both trees.
<rbasak> nacc: no need to replay then.
<nacc> rbasak: ack
<rbasak> nacc: git-write-tree(1) might help
<rbasak> (and then git-commit-tree)
<nacc> rbasak: yep
<bdmurray> pitti: Do you know why http://autopkgtest.ubuntu.com/packages/t/tgt/wily/armhf/ might have failed?
<dosaboy> bdmurray: ping
<bdmurray> dosaboy: it's happened already
<dosaboy> bdmurray: \o/
<dosaboy> bdmurray: sorry to nag but i'm keen to see 1524989 land so I can submit another sru against that package
<dosaboy> bdmurray: thanks for taking care of that
<bdmurray> dosaboy: you could still upload one and have it wait in the queue until the other one ages
<dosaboy> bdmurray: according to https://launchpad.net/ubuntu/+source/python-os-brick it has not yet been copied to -updates
<dosaboy> am i missing something?
<slangasek> pitti: so AFAICS, your force-skiptest of qtbase-opensource-src/5.5.1+dfsg-17ubuntu2~2 means that plasma-workspace's autopkgtest has been allowed to regress on armhf
<bdmurray> dosaboy: I did the right things on my end. http://pastebin.ubuntu.com/17148377/
<dosaboy> hmm weird
<dosaboy> bdmurray: how long ago was that (assuming you're in a far flung tz)
<slangasek> dosaboy: 13 minutes ago (https://launchpad.net/ubuntu/+source/python-os-brick/+publishinghistory)
<slangasek> cf "Status: Pending"
<dosaboy> slangasek: 10-4 that makes sense then
<dosaboy> thanks guys
<bdmurray> elbrus: there are no Launchpad-Bugs-Fixed in the .changes file produced by your upload of cacti for xenial.  Is that something you can easily fix?
<nacc> rbasak: apologies for my ignorance, is there a good reason I can't just add my fork as a remote, fetch and just merge in my master? It will put everythin in the root directory, but that's ok, right? I can rename some files after the merge so it's clear what they are for (e.g., README -> README.workflow)
<rbasak> nacc: I didn't think that would work. If it works then that's great ;)
<nacc> rbasak: ok :) it seems to and gitk shows basically shows a git-merge with two histories (one from each master)
<rbasak> nacc: that's exactly what I wanted. Thanks!
<nacc> rbasak: yep, sounds good, i'll commit
<nacc> oh i also found another corner-case bug
<nacc> and possibly a conceptual issue for `usd-merge reconstruct`
<nacc> i'll send you an e-mail
<rbasak> OK
<rbasak> nacc: or send to the ML maybe? Up to you.
<nacc> rbasak: good point
<nacc> rbasak: i'll send to ML and update on the current status (incl. the github -> lp transition).
<elbrus> bdmurray: ouch, I made a typo "Lauchpad-Bugs-Fixed: 1588813"
<elbrus> I made it on Debian, so I manually change the .changes file
<elbrus> bdmurray: can I just reupload?
<rbasak> elbrus: I believe you can, and bdmurray can pick up the second upload and reject the first later.
<elbrus> rbasak: will try then
<elbrus> nacc: yes, I believe that is transient
<nacc> elbrus: ok, i'll ask someone to retry that one
<elbrus> nacc: but also I can't say from here
<elbrus> nacc: the wget command does take a while (downloads ~1500 pages)
<rbasak> nacc, elbrus: retry button pressed.
<elbrus> rbasak: bdmurray: reuploaded
<nacc> rbasak: thanks! we'll ee
<elbrus> nacc: looks more like a real regression (or something else going wrong with the server..)
<elbrus> nacc: in the artifacs, there is a log.txt.
<nacc> elbrus: ok, will look wheni get back from lunch
<elbrus> it contains stuff like: HTTP request sent, awaiting response... No data received.
<elbrus> 2016-06-03 15:42:44 ERROR 500: Internal Server Error.
<elbrus> even serving a simple gif fails (has nothing to do with php (or cacti)
<elbrus> eh, ignore my last line, not reading well (too tired I guess)
<dannf> doko: wanted to check that you're good with this since it drops a patch you had added: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808626#55
<ubottu> Debian bug 808626 in src:boost1.58 "boost1.58: ships empty binary packages on some archs" [Normal,Fixed]
<elbrus> infinity: ginggs: regarding bug 1562480, this may be related to Debian bug 695547 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695547
<ubottu> Debian bug 695547 in fpc "fpc does not set EABI tags to distinguish armel and armhf object files." [Important,Open]
<ubottu> bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
<doko> dannf, sure, looks fine
<dannf> doko: thx
<ginggs> doko: hi, do you think can we drop boost1.58 in yakkety? http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.60.html i don't think those two build failures are due to boost1.60
<dannf> doko: oh, i'll also grab your fix for #819090
<bdmurray> elbrus: thanks!
<infinity> elbrus: I don't see how they would relate.
<nacc> elbrus: hrm, it seems like it started to regress with the older version of php7.0 as well (so not related to php7.0 directly): http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf/
<nacc> what is my best method for reproducing a armhf test failure?
<doko> nacc, you should have access to the canonical internal porter boxes
<nacc> doko: ack, wasn't sure if that was my best next step or if folks use qemu or anything
<doko> nacc, before using qemu, buy a RaspberryPi ;)
<nacc> doko: lol
<teward> I have an rpi, I'd be happy to flash it, plug it in somewhere, and give you SSH
<teward> since this is my parents' net I don't care about lol
<nacc> teward: appreciate, let me see if i can figure out how to use the porter boxes first and then i'll get back to you :)
<teward> nacc: ack, in the interim I'm flashing Xenial to the thing, but let me know if you need it :)
<teward> nacc: assumption: you just need armhf, not specific RPI hardware :P
<nacc> teward: yeah, it's a cacti test failure only on armhf (in yakkety)
<mwhudson> nacc: two other options, the arm64 porter has armhf chroots on it (and is much faster and more reliable in my experience)
<teward> ^
<mwhudson> nacc: or spend a few cents with scaleway
<nacc> mwhudson: ack, thanks for the tip!
<mwhudson> although you can't install yakkety on scaleway so maybe that's not so useful here
<nacc> pitti: fyi, i have php-imagick merged, but it will fail to build until I can dh-php installable, which is blocked by php7.0 breaking cacti
#ubuntu-devel 2016-06-10
<nacc> elbrus: yeah the 500s seems to be something (i'm guessing it's a php error?) -- but i'm not sure i can find the apache logs to see
<nacc> slangasek: would you have any advice for debugging the armhf regression in cacti? it's causing php7.0 to not update currently and I really don't know how to reproduce it (the tests need root)?
<slangasek> nacc: pointer?
<nacc> slangasek: http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf/
<nacc> slangasek: started failing about a week ago, it seems
<nacc> symptomatically, timeouts are occurring (I think), but the logs indicate the webserver is getting 500s ... but I don't think autopkgtest stores the apache logs (cmiiw) so I'm not sure how to verify if it's something obvious
<slangasek> nacc: this regressed without any relevant changes to the dependencies; so it's currently a badtest and we should mark it as such to remove the migration blocker
<nacc> slangasek: ack, that makes sense to me :)
<nacc> slangasek: is that something you can do for me?
<slangasek> yes (already done)
<nacc> slangasek: great, thanks! this should allow dh-php to demote to universe (once php7.0 propogates to release), which will remove a component mismatch and let dh-php update as well
<slangasek> pretty unhelpful that none of the output goes into the test log :P
<nacc> slangasek: yeah :)
<nacc> slangasek: i was at quite a loss on how to figure out what was going on
<slangasek> nacc: I'm assuming you care about cacti not blocking php7.0's migration, and that you don't particularly care about the cacti in -proposed right now
<nacc> slangasek: ack
<slangasek> ok. then I'm leaving the cacti in -proposed blocked by its own test failure, and someone who does care about that package can figure it out
<nacc> yep, that'd be elbrus --^ presumably :)
<nacc> slangasek: feel free to ignore my question until it's convenient for you, but phpunit in yakkety-proposed currently fails to build (https://launchpadlibrarian.net/263777009/buildlog_ubuntu-yakkety-amd64.phpunit_5.4.2+dfsg-1_BUILDING.txt.gz) because the Debian package is not properly versioning the deps on php-codecoverage (so what could be a build-dep failure is instead expressed as a build failure).
<nacc> But the dep in question (php-codecoverage) will fail to build if resubmitted currently because it depends on a newer phpunit than is in yakkety (in fact, I think the version that is currently not building). I am really not sure how these two packages got into this state, and if Debian did manually overriding knowing it would be overcome once they were both built
<nacc> slangasek: but my question is: are you ok if i submit a patch like was done in 16.04 to add a build profile that disables the tests (and we possibly use that to bootstrap this tight loop)?
<nacc> alternatively, if it's possible, we could pass DEB_BUILD_OPTIONS=nocheck to the builder for php-codecoverage and it builds fine
<nacc> using that .deb file (--extra-package), phpunit also now builds
<slangasek> nacc: if DEB_BUILD_OPTIONS=nocheck is sufficient to let us bootstrap, we can reasonably do that and shove it into the bootstrap archive
<slangasek> easier than having to change packages
<nacc> slangasek: ack, i'm just verifying both build successfully afterwards
<nacc> slangasek: ok, this process worked for me locally: http://paste.ubuntu.com/17162006/
<nacc> note that the php-mock-object build is a needed merge (reviewed by rbasak already)
<sergiusens> slangasek still around? is this a known issue https://launchpadlibrarian.net/264431731/buildlog_ubuntu-yakkety-amd64.snapcraft_2.11+16.10_BUILDING.txt.gz ?
<slangasek> sergiusens: nothing that's known to me, but I see there's been a new version of python3.5 synced to yakkety-proposed today
<sergiusens> ah that can explain it
<sergiusens> slangasek I guess this would block my SRUing
<slangasek> sergiusens: no reason that it should
<sergiusens> ah, I thought we always had to push to the devel series first :-)
<slangasek> sergiusens: you did push it to the devel series; it's not required that it migrate out of -proposed when it's been blocked by an unrelated bug...
<sergiusens> fair enough
<slangasek> fwiw I can't see any reason something is looking for a Makefile at that path... it might be a python3.5 regression, but that file doesn't exist in the previous version of the python3.5 package either
<sergiusens> slangasek it does on xenial $ dpkg -S /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/Makefilelibpython3.5-dev:amd64: /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/Makefile
<slangasek> ah
<slangasek> only in libpython3.5-dev, which I didn't have installed :-)
<slangasek> sergiusens: ... and which is not a build-dep of snapcraft either
<sergiusens> slangasek yeah, I wonder how it ever worked...
<slangasek> probably by the previous version not unnecessarily requiring that Makefile :)
<slangasek> doko: ^^ python3.5 3.5.1-15 in -proposed is definitely broken wrt pybuild; I'm going to drop it out of -proposed to unblock package builds until a fix is available
<sergiusens> at least I know the same package built fine on xenial https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/9896202
<slangasek> sergiusens: ^^ and having removed that, snapcraft can be retried in about an hour
<sergiusens> thanks, I'll be in bed by then, but I'll make sure to retry in the morning, in the meantime I'll leave the upload on xenial ;-)
<nacc> slangasek: can you demote dh-php to universe?
<nacc> slangasek: php7.0-dev should now only suggest it, and that's the only revdep in main
<slangasek> nacc: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed claims it's still used in main; until it shows up on that report I won't fiddle with it, that just encourages archive admins to get into accidental revert wars
<nacc> slangasek: ack, sorry
<nacc> slangasek: hrm, when i look at that page it says it wants to move xml2 to main (since dh-php depends on it and dh-php is in main). I'm suggesting we demote dh-php to universe -- did I misunderstand? Also, i'm really confused, the debdiff rbasak uploaded for me and diff at https://launchpadlibrarian.net/264339273/php7.0_7.0.7-4_7.0.7-4ubuntu1.diff.gz indicate dh-php is now in Suggests (or should be).
<nacc> But my chdist apt-cache does not?
<nacc> argh, i know why, nm
<nacc> control.in vs. control
<slangasek> nacc: right, so if all the changes were done and dh-php would be ready to drop, you would see dh-php under "move sources from main to universe" instead of a dependency of dh-php under "move sources from universe to main"
<mwhudson> when SRUing something directly from yakkety to xenial, do i just stick a xenial changelog on the top of whatever's in yakkety?
<mwhudson> slangasek: ^
<slangasek> mwhudson: that's usually ok
<pitti> bdmurray: tgt> I'll look
<pitti> slangasek: plasma-workspace> rather looks like the uninstallability of -proposed is locked up with the other KDE packages; http://autopkgtest.ubuntu.com/packages/p/plasma-workspace/yakkety/armhf/ just succeeded in current y-release
<pitti> slangasek: so I don't think the "force-badtest plasma-workspace/armhf/4:5.5.5.2-0ubuntu1" is justified actually
<pitti> slangasek: and consequently, I don't think we should ignore the failure for 4:5.6.4-0ubuntu1 either
<pitti> slangasek: it didn't promote as it's still blocked by dependencies
<pitti> but I tried with --all-proposed often enough, that's not it -- something in y-proposed is really missing
<pitti> nacc: so php7.0 landed, nice work! so I take it your php-imagick merge can land now?
<ginggs> morning pitti! sorry, i didn't see your question on LP: #1556685 Is my answer reasonable, or do i need to dig deeper?
<ubottu> Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<pitti> ginggs: ok, you now said it's cosmetic and has no actual impact on its rdepends; but a test case is still necessary, i. e. how can someone verify that the update still works
<pitti> infinity: the glibc FTBFS on amd64, is that known? (hidden symbol `__stack_chk_fail_local' isn't defined)
<pitti> http://autopkgtest.ubuntu.com/packages/g/glibc/yakkety/amd64/
<ginggs> pitti: well, i did check that freecad and gmsh still open and after upgrading, but not being familiar with the applications did not do extensive testing
<pitti> ginggs: but these wouldn't use cmake files at runtime, right?
<ginggs> correct
<pitti> ginggs: i. e. "test that freecad and gmsh still start" is a good part of the test and should be mentioned
<pitti> but e. g. "test that they still build" might be another?
<pitti> (sorry, I have absolutely no idea what oce is)
<ginggs> ok, i'll expand on that.  they *only* build after the upgrade
<ginggs> pitti: so when i'm done with that, do i need to upload the same version again?
<pitti> ginggs: I didn't reject it, just held it in the queue
<pitti> oh, but vorlon did
<pitti> ginggs: yeah, easiest to just reupload the same thing
<ginggs> pitti: danke!
<pitti> ginggs: thanks
<pitti> ginggs: so, put yourself into the position of someone not knowing oce who is supposed to decide "is that an update which does not cause regressions and actually fixes the bug?"
<pitti> ginggs: and formulate the test case and regression potential accordingly
<pitti> xnox: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libseccomp is blocked as it regresses on i386 and s390x
<ginggs> ginggs: i tried doing that in the SRU bug LP: #1556680, but i see i should have been more explicit in LP: #1556685
<ubottu> Launchpad bug 1556680 in oce (Ubuntu Xenial) "[SRU] Wrong library path in CMake file for 64bit system" [Undecided,Fix committed] https://launchpad.net/bugs/1556680
<ubottu> Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<pitti> ginggs: ah, the joy of SRU bugs; never do that, please
<ginggs> pitti: never do what, exactly?
<pitti> ginggs: open a separate bug #2 that says "SRU for bug #1"
<ubottu> Error: Launchpad bug 2 could not be found
<ubottu> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
 * pitti smirks at ubottu
<pitti> just adding a trusty/xenial/etc. task to the actual bug is much preferred
<pitti> it avoids smearing out the info between the two, and the originally affected people can help testing, etc.
<pitti> and the tasks don't need to be kept in sync manually
<ginggs> pitti: understood, https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload says to avoid creating meta-bugs, but that's not what happened here
<pitti> ginggs: ah, maybe they are different issues, sorry then; (they sound similar)
<ginggs> LP: #1556680 is the real bug
<ubottu> Launchpad bug 1556680 in oce (Ubuntu Xenial) "[SRU] Wrong library path in CMake file for 64bit system" [Undecided,Fix committed] https://launchpad.net/bugs/1556680
<ginggs> pitti: but i agree that the way it was done is confusing for someone trying to review, and i will fix that by being more explicit in LP: #1556685
<ubottu> Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<pitti> ginggs: thanks muchly for cleaning up!
<brendand> if i run some tests via adt-run with nose, and i have logging.info statements (using logging module) in them, and the logging level set to INFO, should i see that output in the adt log? right now i just see the test names, no more detail than that
<mgedmin> nose suppresses logging output by default and only shows it if a test fails
<mgedmin> you can ask nose not to do that with a command-line switch
<mgedmin> -s, IIRC
<brendand> --nocapture, great - thanks
<doko> slangasek, hmm, I don't see the issue yet
<pitti> doko: many thanks for uploading py3.5, much appreciated!
 * pitti feeds the Launchpad hamsters to import it
<doko> pitti, hmm, see above, slangasek claims that -15 is broken. still investigating why
<pitti>  linux | 4.4.0-24.43   | xenial-updates   | source
<pitti>  linux | 4.4.0-23.41   | yakkety          | source
<pitti> apw: ^ apparently there's some forward copying missing?
<pitti> apw: or is that on purpose somehow?
<infinity> pitti: Yeah, I just didn't have any overwhelming urge to fix it until I had a better reason (like new upstream version) for an upload.
<infinity> pitti: And I did all the kernel forward copies just now.
<pitti> infinity: ok, thanks; I ignored the  failure as it didn't seem triggered by the new cdebconf
<infinity> https://launchpad.net/ubuntu/+source/linux/4.4.0-24.43/+publishinghistory
<pitti> infinity: so I'll add a force-badtest for amd64 for that version, to avoid asking you again next time :)
<pitti> bdmurray: tgt/wily was a spurious failure apparently, succeeded now
<apw> pitti, no not on purpose, it was on my list to confirm done this morning, and it seems infinity has beat me to it
<pitti> apw: ack, thanks
<infinity> apw: Heh, yeah, it was on my "when I wake up" list too, and we seem to have woken up at the same time.
<apw> infinity, which is wrong on so many levels :)
<xnox> pitti, huh, that looks weird... I'll check if I dropped or reordered patches... unless upstream renumbered things which is abi break....
<xnox> also no clue why these syscalls are negative =/
<ogra_> just turn the around ;)
<ogra_> *them
<pitti> xnox, slangasek: so poppler/gdal/gp2ls/tinyxml2 transition all hinge on suitesparse, which built because we now build against universe deps, but is not installable because its new libmetis5 dep is in universe
<pitti> xnox, slangasek: that's one of the hairy scenarios that I was afraid of.. :-(
<pitti> "someone will fix it eventually"
<ginggs> pitti: i thought slangasek promoted libmetis5 already
<ginggs> pitti: LP: #1588407
<ubottu> Launchpad bug 1588407 in metis (Ubuntu) "[MIR] metis" [Undecided,Fix released] https://launchpad.net/bugs/1588407
<pitti>  libmetis5     | 5.1.0.dfsg-4 | yakkety/universe | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti>  metis         | 5.1.0.dfsg-4 | yakkety/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti> ginggs: thanks, I missed the MIR as it was already closed
<bdrung_work> pitti, whom can i poke to get the cpu+ram hotplug into the kernel?
<pitti> bdrung_work: my favourite go-to kernel person is apw, he should know whom to give this to
<pitti> apw: sorry Andy
<apw> heh, i ahve many fine victim^Wpeople to pass this on to
<pitti> ginggs: hm, so if this was promoted and demoted later on, I wonder why it still didn't land then
<pitti> well, let's find out at the next publisher/britney run
<pitti> ginggs: thanks
<apw> bdrung_work, you might want to ask on #ubuntu-kernel so we can discuss
 * pitti joins too
<bdrung_work> pitti, btw, do you know whom to talk to about the cloud images? i like to have consoleblank disabled there.
<rbasak> bdrung_work: bug 869017
<ubottu> bug 869017 in kbd (Ubuntu) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Medium,Triaged] https://launchpad.net/bugs/869017
<bdrung_work> thanks rbasak
<rbasak> bdrung_work: Wesley (an intern on the Canonical Server team) was looking into it, mainly to scratch his own itch I think. I still have him down as driving the bug. Looks like it needs an updated patch.
<rbasak> bdrung_work: might be worth coordinating with him. He's not in here but is magicalChicken in #ubuntu-server.
<rbasak> bdrung_work: but feel free to take the bug and patch it :)
<elbrus> nacc: do you know of any changes in the armhf autopkgtest setup, because the same version of cacti that passed in the past, now fails...
<elbrus> nacc: so it is either a real regression due to php (and very weird also cdebconf) or the testing framework is borking for whatever reason
 * elbrus will copy more logs to the artifacts; nacc do you have suggestions next to the cacti.log and apache2/access.log & error.log?
<ginggs> pitti: regarding suitesparse, if i understand update_output.txt correctly, it is the missing arm64 build of gammaray that blocking things.  Can we kill that?
<bdrung_work> pitti, rbasak: is there any package or project that I should assign #1591166 to?
<jamespage> apologies if I'm duping existing question but is there something wonky with the proposed migration for dependencies on python-cffi (and its versioned backends)
<jamespage> python-oslo.privsep is wedged with
<jamespage> python-oslo.privsep/amd64 unsatisfiable Depends: python-cffi-backend-api-min (<= 9729)
<jamespage> python-oslo.privsep/amd64 unsatisfiable Depends: python-cffi-backend-api-max (>= 9729)
<jamespage> but its quite installable afaict
<pitti> ginggs: wow, you were able to decipher that?
<pitti> ginggs: hm, it failed on i386 too
<pitti> ginggs: gammaray has zero rdepends, so I'm just going to remove it from yakkety, keeping the y-proposed version
<ginggs> pitti: i could be completely wrong
<pitti> we might just retry the builds
<pitti> ginggs: not sure if it's the only cause, but it's certainly *a* cause
<pitti> ... done
<pitti> bdrung_work: assigned to cloud-images
<bdrung_work> thanks
<pitti> apw: want a bug for the missing python-yaml test dep? (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/l/linux/20160610_110617@/log.gz)
<pitti> apw: such things are a bit hard to spot as the kernel tests have failed for quite some time (but differently)
<cjwatson> jamespage: It's conceivable that the britney instance here doesn't understand versioned Provides; that was only added upstream in April
<cjwatson> jamespage: somebody in ~ubuntu-release will have the exciting job of sorting out a merge
<jamespage> cjwatson, the comment in the newer python-cffi would indicate that might be required as well
<apw> pitti, yeah lets have a bug, as i will need to SRU that i assume
<pitti> apw: filed bug 1591189, with hopefully quiescing the bot
<ubottu> bug 1591189 in linux (Ubuntu) "missing python-yaml autopkgtest dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1591189
<apw> pitti, thanks, i'll get that sorted out
<pitti> cheers!
<Odd_Bloke> I have a machine running a DNS server, and /etc/resolv.conf points at localhost.  When cloud-init runs on reboot, it does a getaddrinfo('my.metadata.service.', None) _before_ the DNS server is up (note the trailing dot).  'my.metadata.service' is defined in /etc/hosts, but that isn't found (because the trailing dot isn't stripped off before looking in to /etc/hosts), so cloud-init errors out.
<Odd_Bloke> Is the fact that the un-dotted form is not found in /etc/hosts a bug?
<rbasak> That's a good question.
<rbasak> I have "127.0.0.1	localhost.localdomain	localhost
<rbasak> in /etc/hosts
<rbasak> getent hosts localhost.localdomain.
<rbasak> fails to find anything.
<rbasak> I'm not sure DNS semantics applies at nsswitch/hosts file level.
<rbasak> I'm struggling to answer the question though, in part because "my.metadata.service." is a hack.
<Odd_Bloke> rbasak: A hack how?
<rbasak> Odd_Bloke: I don't believe you have service. registered :)
<rbasak> Odd_Bloke: the more I think about it, the more I think that it isn't defined that you're speaking DNS, so you can't expect DNS semantics. I'm not sure though.
<Odd_Bloke> rbasak: Yeah, it's a slightly weird interface.
<rbasak> Odd_Bloke: you could be using NIS :)
<rbasak> (what's this "DNS" think you speak of?)  :-)
<rbasak> thing
 * rbasak can't type today
<ginggs> pitti i think you did it - suitesparse is through \o/
<pitti> ginggs: ooh! not yet on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, I was watching it
<pitti> but indeed https://launchpad.net/ubuntu/+source/suitesparse/1:4.5.3-1 is landing
<ginggs> i'm getting mails of all the packages being accepted
<pitti> \o/
<infinity> pitti: Yo, what's the deal when britney claims a test is running, but it hasn't shown as running for hours?  Do things sometimes just get lost?
<pitti> infinity: which test?
<infinity> pitti: (linux-raspi2)
<pitti> infinity: there's a few blacklisted ones which can't run, and a corner-case bug which sometimes causes lost  requests
<infinity> pitti: It ran and broke 4h ago, but there's no indication that it was restarted.  Doesn't show as failed, though, shows as running.
<pitti> ah, this one: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/l/linux-raspi2/20160610_095800@/log.gz
<pitti> it didn't get as far as deciphering a version number, so britney can't match it
<infinity> pitti: Ahh, hence "version: n/a" on the result list.
<infinity> Seems to have happened fairly regularly.  Weird.
<pitti> so, that's an interesting question
<pitti> shoudl we somehow get this across to britney as a (failed) test result; but then, how *do* you define an approriate version number
<infinity> pitti: Well, if it never even grabbed the source to get a version, shouldn't that be an auto-give-back?  Looks like it's the infra's fault, not the package.
<infinity> Or, put another way, if you can blame the package, you surely have a version number.
<ginggs> update_excuses.html shows supercollider - old binaries left on armhf: supercollider-supernova (from 1:3.7.0~repack-1)  - what needs to happen there?
<pitti> infinity: yeah; I need to run this with --debug to understand what's going on
<pitti> infinity: I actually did have that as "tmpfail" for a fair while, but that then caused eternal tmpfail loops/worker killing sprees on packages that were actually not existing or broken
<pitti> apt really only gives you one exit code 100 for both transient and permanent issues
<pitti> so that needs some more error message parsing fine-tuning
<infinity> pitti: Fair enough.  In this case, I can requeue it.  Unless you already have?
<pitti> infinity: no, let me first do a manual run to see what's going on
<infinity> pitti: Or that.  Go for it.  I'll leave it.
<infinity> pitti: The other security kernels got through, I'm less fussed about raspi2 on yakkety.
<pitti> infinity: ... and of course this totally works when run manually
<infinity> pitti: Of course it does.
<infinity> pitti: I mean, historically, it works some of the time. :P
<infinity> pitti: But it also seems to fail a lot.
<infinity> So, whee.
<pitti> infinity: I guess I'll add some logging verbosity then
<pitti> oh, it's not exit code 100
<pitti> and stderr is already shown
<pitti> so, apt fails with !100 with an error on stdout or nonexisting
<ginggs> i think singular, supercollider and openms need to be decrufted, please
<pitti> ginggs: what does that mean? not on http://people.canonical.com/~ubuntu-archive/nbs.html
<ginggs> sorry, maybe wrong term
 * pitti wasn't aware that we need to remove NBS from -proposed
<pitti> they should just become NBS in -release
<pitti> assuming of course that  all remaining reverse dependencies get dropped
<pitti> but ICBW
<pitti> ginggs: for e. g. singular that just means that it's not built on armhf, and indeed https://launchpad.net/ubuntu/+source/singular/4.0.3-p1+ds-2build2/+build/9804780 is depwwait
<pitti> I can't explain the supercollider-supernova thing, I'm afraid
<ginggs> ok so for singular then, can we remove the armhf binaries so it can migrate, and it will build when python-polybori becomes available again?
<cjwatson> we need to remove NBS from -proposed in the corner case where a source package drops binaries that were previously part of another publication to yakkety-proposed since the last version in yakkety
<cjwatson> may not be relevant here, haven't checked
<pitti> infinity: ah, found a way to reproduce
<pitti> fixing this needs to wait until Monday I'm afraid, I need to run soon; but I take that's  enough
<nacc> elbrus: that's what i would start with for sure (re: cacti logs). But note the first regression point happened w/o any change to php proper (afaict) ... so it's hard for me to debug why :)
<infinity> ginggs: Erk, who removed polybori on armhf in the first place? :/
 * infinity looks.
<infinity> Oh, Colin. :P
<cjwatson> I imagine I had a reason
<infinity> FTBFS on armhf; also removed in Debian
<cjwatson> ah yeah, I reckoned that if Debian had given up on it then there was no sense trying *too* hard
<infinity> The part where no code changed and it started failing, though, leads one to wonder if polybori is really the problem or if we just papered over something worse.
<infinity> (ie: I'd assume it's libpng's fault somehow)
<infinity> Or boost.
<nacc> rbasak: i made a thinko in my php7.0 upload so it didn't actually change anything (d/control.in vs. d/control). Would you be willing to re-sponsor the debdiff in LP: #1590623
<ubottu> Launchpad bug 1590623 in php7.0 (Ubuntu) "Drop dh-php from Recommends to Suggests" [Undecided,In progress] https://launchpad.net/bugs/1590623
<nacc> pitti: yes, once that is done --^ and goes through, php-imagick can go in (i can actually test it once dh-php updates) and that will unblock php-defaults
<rbasak> nacc: yep, looking.
<nacc> rbasak: thanks!
 * pitti waves good bye and happy weekend
<infinity> pitti: See you soon
<infinity> pitti: Oh, what's the deal with that raspi2?  Is it handled, or do I need to do things to it?
<ginggs> bye pitti
<rbasak> nacc: I have to run (early EOD to catch a train) but I think there's a bug in usd-merge.
<rbasak> It's quite confusing. I tried to "undo" a "usd-merge commit" while experimenting.
<rbasak> I've ended up with a .git/ubuntu/yakkety "ref", which seems to override .git/refs/heads/ubuntu/yakkety.
<rbasak> So when I reset the ubuntu/yakkety branch back to its original hash, "git-rev-parse ubuntu/yakkety" and thus "usd-merge commit" both don't see it, which causes a bunch of extra merge commits as I redo each time, IYSWIM.
<rbasak> I think the problem is that the call to "git update-ref" needs to be "refs/heads/ubuntu/yakkety" rather than just "ubuntu/yakkety".
<nacc> rbasak: hrm, i'll re-read the man-page
<nacc> and test locally
<rbasak> Thanks!
<nacc> rbasak: i know there's also a bug with `usd-merge reconstruct` and upload/ tags
<nacc> as those can't be cherry-picked the same
<nacc> rbasak: ack, you're right, fixing it and pushing
<nacc> barry: fyi, we've combined that gh repository with the lp one. And i've updated the wiki references as well
<barry> nacc: cool.  did rbasak land pr#2 yet?
<nacc> barry: i just pulled it in to our combined repository. I think rbasak will close the gh one eventually. So since i have write access to the lp one, i was able to commit the changes directly :)
<barry> nacc: cool :)
<bdmurray> pitti: How did you restart it tgt/wily?  I forget how to do that.
<anaran> hi, will firefox be available on ubuntu phones soon, without external display connected (similar to firefox for android)?
<nacc> i think rbasak wasn't able to get to it before he left, but could someone help sponsor the latest debdiff in LP: #1590623 ? Needed to help unblock one set of php* in excuses
<ubottu> Launchpad bug 1590623 in php7.0 (Ubuntu) "Drop dh-php from Recommends to Suggests" [Undecided,In progress] https://launchpad.net/bugs/1590623
<rbasak> nacc: I did upload it, sorry I didn't say. I guess you don't get the email? Anyway, it's in proposed :)
<nacc> rbasak: interesting, yeah, i wasn't notified and i hadn't seen it yet in excuses
<nacc> rbasak: ah probably because it's still building, got it
<nacc> rbasak: tahnks! i can see the proposed builds have the right deps now
<rbasak> No problem :)
<dobey> anaran: an external display isn't required, but it's not particularly useful to run firefox on a phone. if you want to know if mozilla is going to ship a version of firefox suited for use on phones/tablets, in the ubuntu store, you'd have to ask mozilla.
<ogra_> dobey, you just need a mouse,keyboard and a good looking-glass :P
<dobey> ogra_: well, when the keyboard integration is fixed, you won't need an external keyboard
<slangasek> pitti: as ginggs said, metis was already promoted, so somebody else re-demoted it without looking at component-mismatches-proposed
<elbrus> does anybody here no a good example of autopkgtest tests that add log files to the artifacts?
<elbrus> s/no/know/
 * elbrus has "set -e" so can't just do it at the end of the test
<kees> doko: any chance you can take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826786 ? I'm really not sure how it's best solved, but it's blocking upstream kernel testing of the new gcc plugin infrastructure
<ubottu> Debian bug 826786 in src:gcc-6-cross "gcc-6-cross: No gcc plugin headers for cross compilers" [Wishlist,Open]
<nacc> slangasek: would you be able to assist me with the bootstrap for phpunit? I've verified the steps needed, and I think this will unblock the majority of the stuck php packages (as phpunit will be updated and installabe)
<slangasek> nacc: I'm not going to get to it today; maybe infinity could help
<nacc> slangasek: ok, np
<nacc> infinity: if you're around, i need to bootstrap build 3 packages with DEB_BUILD_OPTIONS as they all interdepend (but the end-result, which we'd want to copy to the archive doesn't require any DEB_BUILD_OPTIONS and builds successfully in my testing)
#ubuntu-devel 2016-06-11
<nacc> pitti: i've sent the php-imagick merge to rbasak to review, it builds fine with dh-php (once demoted to universe). I'm working on testing it now
<nacc> autopkgtest'ing it, that is
<nacc> looks like the tests pass
<doko> kees, send a patch? I haven't looked yet at this
<infinity> nacc: I can have a look in a bit, if you can point me to what needs bootstrapping.
<nacc> infinity: yep, let me provide you a set of clean steps (it's short)
<infinity> nacc: Sure, just pastebin it or something, and I'll have a gander after I eat dinner.
<nacc> infinity: http://paste.ubuntu.com/17193377/
<nacc> just real tight loop of deps that is preventing phpunit from updating
<jhenke> Hi, I would like to get bug 1585928 nominated as SRU for xenial, on #ubuntu-bug I was not able to reach someone doing it for a week now, can anybody here help? It is fairly trivial change, but helps a log.
<ubottu> bug 1585928 in llvm-defaults (Ubuntu) "[SRU] llvm-defaults 0.33ubuntu4 [was: lldb package does not provide a lldb-server symlink to the current default version]" [Undecided,Fix released] https://launchpad.net/bugs/1585928
<ginggs> jhenke: done
<jhenke> ginggs thanks!
<jhenke> so I hope it will go into xenial soon, maybe next week
<ginggs> jhenke: are you going to attach a debdiff to the bug?
<jhenke> I don't know how to
<ginggs> jhenke: https://wiki.ubuntu.com/MOTU/Contributing
<jhenke> but I can't update the changelog for the SRU yet?
<ginggs> jhenke: sorry, i don't follow
<jhenke> the page says you should update the packge's changelog with dch
<jhenke> but I think the changelog should be done by the person uploading?
<pitti> infinity: raspi2> I can reproduce the bug, retries don't help; if it's urgent, hint it, otherwise I'll fix the bug and retry afterwards
<ginggs> no, you can prepare the complete upload including the changelog.  The person doing the upload is essentially just sponsoring what you have prepared
<pitti> bdmurray: restart tgt> recycle icon on http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html
<ginggs> jhenke: ^
<pitti> nacc: yay
<jhenke> okay, so something like "no change upload to xenial"?
<pitti> slangasek: ack; seems it's all good now, after the gammaray demote-to-proposed it all landed \o/
<ginggs> jhenke: no, i think you should start at 0.33ubuntu3 and apply just the fix you need.  call it 0.33ubuntu3.1 or similar (it has to be lower than what is in yakkety)
<jhenke> okay
<ginggs> jhenke: see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure point 5 - 1
<jhenke> ginggs thanks, I'll try to do it
<slangasek> pitti: curious, why did gammaray need demoted to proposed? (it's certainly made it back into yakkety now)
<ginggs> slangasek, pitti: i think the gammaray's arm64 and i386 binaries needed to be removed
<ginggs> at least update_excuses explicitly mentioned arm64
<nacc> infinity: were you able to get to the bootstrap? just checking in, if the instructions were ok
<slangasek> ginggs: but I had removed those already :)
<slangasek> ginggs: and it looks like they are gone so all is well
<LocutusOfBorg> does anybody have experience about ocaml transition?
<LocutusOfBorg> I can't figure out what needs rebuilding for that
<slangasek> LocutusOfBorg: you might want to mine the history of lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/ for past examples
<slangasek> LocutusOfBorg: or maybe http://people.canonical.com/~ubuntu-archive/transitions/ which points to ocaml will already tell something :)
<LocutusOfBorg> slangasek, I know the permanent transition, but I don't know how the ABI changes propagate :)
#ubuntu-devel 2016-06-12
<hallyn> ...  apt purge gnupg-agent, it wants to remove mutt and totem
<mwhudson> docker appears to be stuck on autopkgtests on http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html but it is not running on http://autopkgtest.ubuntu.com/running.shtml (and i think it's blacklisted)
<mwhudson> can someone hit it with a stick?
<LocutusOfBorg> slangasek, can we have botch demoted or testsuite ignored? I see the one you uploaded already have it disabled, but it isn't building, and testsuite is running on the -release version
<LocutusOfBorg> pitti, ^^^
<Umeaboy> Hi!
<Umeaboy> https://wiki.ubuntu.com/ARM/RootfsFromScratch is outdated.
<Umeaboy> Which page should I use?
<Umeaboy> I have installed live-build and qemu along with debootstrap.
<mwhudson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mwhudson
#ubuntu-devel 2017-06-05
<Mirv> Mirv: hi! I started with dropping the Ubuntu (touch) specific changes in the ubuntu branches of Qt in Debian's git, but other than that it's up to the community to package it (of which I may or may not be part of depending on if I have time). Debian is working on it. Qt 5.8 was skippped altogether since upstream dropped support for it early.
<Mirv> mardy: ^ that was to you of course :)
<Mirv> there's a volunteer from Kubuntu people (oh well, who's from where originally, it doesn't matter) helping Debian with the 5.9
<mardy> Mirv: cool!
<Mirv> the big thing will be merging it to Ubuntu and getting everything to build against it or drop. there are still AFAIK more Qt using packages in Ubuntu than in Debian.
<Mirv> the migration to release pocket might hold a surprise or a hundred, also thanks to the gles twin packages that should be dropped at the same time
<Mirv> s/Qt using packages/Qt private ABI using packages/ (requiring rebuild)
<Mirv> mardy: re: ubports, I thought they used xenial with stable-phone-overlay, which has Qt 5.6 LTS at least
<Mirv> as my last paid feat I landed also Qt Quick Controls 2 backport (from 5.7) made to work with Qt 5.6's qtbase/qtdeclarative in there
<Mirv> granted, if not planning to ship actual end-user products then it does not make too much sense to stick to even LTS release of Qt. it's only once it's tried to stabilize things that one needs to select a version.
<Mirv> Qt Quick Controls 2 was supposed to gain Ubuntu theme (UITK2) and a couple of new features, that'd been the future of UX building. even though a version of it is in overlay PPA it's still just 5.7, and eg some of our Ubuntu changes were contributed to QQC2 5.9
<jbicha> mardy: Oxide is being removed from 17.10 which means that Unity's Online Accounts panel will stop working
<jbicha> do you have any objections about removing UOA completely from 17.10?
<mardy> jbicha: oh, sorry, forgot to reply to your e-mail
<mardy> jbicha: no objections; will be packages still be available in the universe?
<cjwatson> not much point keeping something in universe if it doesn't work
<jbicha> mardy: oxide will not be in Ubuntu at all (not universe) and we're talking about removing UOA completely too
<mardy> jbicha: no objections if you mean removing unity-control-center-signon, but signon-ui can work without oxide, and is still used by KDE
<jbicha> what does KDE use signon-ui for?
<jbicha> without u-c-c-signon, I think it makes sense to drop UOA support from evolution-data-server too
<mardy> jbicha: KDE has its own online account integration, using signon-ui
<mardy> jbicha: about UOA+eds I don't know, whether it's used by KDE or others
<jbicha> it seems very unlikely for Kubuntu to care about e-d-s
<jbicha> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<jbicha> meeting today?
<cyphermox> technically, there is, but a lot of us are at a sprint and maybe not available. it's kind of early
<mwhudson> morning
<sergiusens> slangasek: hey, mind looking at https://bileto.ubuntu.com/#/ticket/2790 for me?
<luis30> anyone know if there is going to be a kernel update for ubuntu 17.04 today?
<slangasek> sergiusens: https://bileto.ubuntu.com/#/ticket/2790 what are you wanting me to look at?  Are you asking for me to click 'publish'?
<sergiusens> slangasek: my first time using bileto... I think I need someone to do that... I wouldn't particularly ask you aside from the fact that you are familiar with what this solves
<sergiusens> so, yes, long sentence to say, can you click publish?
<sergiusens> if that indeed is the next step in this process
<sergiusens> actually, you are probably one of the few still familiar with bileto too :-P
<slangasek> sergiusens: sil2100 is also familiar with it :)
<sergiusens> ah, good
<sil2100> https://wiki.ubuntu.com/Bileto <- this is always the first place when in doubt
<sil2100> But yeah, feel free to poke me as well
<sergiusens> sil2100: well I just need that ticket I mention above in :-)
<sergiusens> as in someone to click on "publish"
 * sil2100 looks
<sil2100> Ok, looks goodish, let me do the buttonz
<luis30> where is this kernel update that was supposed to happen today? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691146
<ubottu> Launchpad bug 1691146 in Kernel SRU Workflow "linux: 4.10.0-22.24 -proposed tracker" [Medium,In progress]
<sergiusens> sil2100: goodish, I'll tell Colin you said that :-P
<sergiusens> thanks btw
<luis30> is this the dev channel?
<wxl> luis30: as the topic says, yep.
<luis30> great know anything about that bug i posted or any kernel update today particularly for ubuntu 17.04
<wxl> i know nothing about a bug that you posted.
<wxl> a bug number would be helpful.
<luis30> i just posted the link
<luis30> it goes right to the page
<wxl> ah didn't notice
<luis30> its fine
<nacc> luis30: it's in zesty-proposed and artful right now (it seems)
<luis30> seth had a project release date of today but that was not set in stone..
<nacc> luis30: are you asking why it's not in zesty release yet?
<luis30> yes it was scheduled for today assuming no major issues
<nacc> luis30: might be better to ask in #ubuntu-kernel
<luis30> good idea
#ubuntu-devel 2017-06-06
<luis30> wxl, well ubuntu-kernel is pretty...you by chance have any info on this bug fix and when it maybe released on the regular release...https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691146...im trying to decide if i want to turn on proposed or not..because if its going to be weeks and weeks and weeks...i think i will probably turn on proppose...
<ubottu> Launchpad bug 1691146 in Kernel SRU Workflow "linux: 4.10.0-22.24 -proposed tracker" [Medium,In progress]
<luis30> ubuntu-kernel is pretty slowi mean
<luis30> it was scheduled for today not sure what happened.
<luis30> https://lists.ubuntu.com/archives/kernel-sru-announce/2017-May/000096.html
<luis30> june 05 release to updates
<Unit193> !info linux zesty-proposed
<ubottu> Package linux does not exist in zesty-proposed
<Unit193> !info linux zesty
<ubottu> Package linux does not exist in zesty
<sarnold> what a relief :) largest source of cves..
<Unit193> Ah right, source packages, etc.
<luis30> does seth have a nick on here?
<mitya57> mardy: our goal is to minimize the Qt packaging differences between Debian and Ubuntu, so we (tsimonq2 and I) are working mostly in Debian pkg-kde git.
<mitya57> I donât know yet if I want 5.9.0 in Artful early, or itâs better to wait for 5.9.1. But in any case help is appreciated, please join #debian-qt-kde on OFTC if you want to help.
<luis30> mitya57, any new kernel release for ubuntu 17.04 today?
<mitya57> luis30, I am not kernel maintainer, please ask in #ubuntu-kernel
<luis30> mitya57, what is seth's nick do you know?
<luis30> he apparently was the one handing this particular big
<luis30> bug
<mitya57> Are you looking for sarnold?
<luis30> i just found him
<luis30> his nick is the same as on here for launchpad
<luis30> not is not sarnold but i found him
<klebers> luis30, zesty kernel 4.10.0-22.24 is scheduled to be promoted from -proposed to -updates today.
<LocutusOfBorg> hello developers, does anybody have any clue about this issue?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/libf/libffi-platypus-perl/artful/amd64
<LocutusOfBorg> stack smashing detected, the program is simple and around 10 LOC
<luis30> thanks klebers :)
<klebers> luis30, yw :-)
<slangasek> stgraber, kees, infinity, mdeslaur: TB meeting in 6min
<mdeslaur> slangasek: ack
#ubuntu-devel 2017-06-07
<sergiusens> slangasek how do I get autopackage tests running for a bileto ticket?
<sergiusens> cjwatson: hey, sorry to bother about click, but does "E: 10mount: mount: unknown filesystem type 'overlayfs'" ring a bell? (from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/click/20170607_053103_91658@/log.gz)
<cjwatson> sergiusens: A new and exciting failure mode I haven't seen before!
<cjwatson> sergiusens: Might just be that the armhf autopkgtest nodes don't support that; possibly worth checking with Laney regarding what's sensible there
<sergiusens> great, I haven't checked the armhf logs yet, this is amd64, but thanks for the pointer
<cjwatson> err
<cjwatson> yes, that one
<cjwatson> if necessary we could disable the click chroot tests
<sergiusens> cjwatson: that sounds good as regression testing of click for perl seems to have the same failures
<cjwatson> or check whether overlayfs is available before running them, perhaps
<Laney> Huh
<cjwatson> overlayfs is probably needed by the schroot tests too though?
<cjwatson> or sbuild or something like that
<sergiusens> under perl on update_excuses -> autopkgtest for click/0.4.45.1+16.10.20160916-0ubuntu1: amd64: Ignored failure, armhf: Always failed, i386: Ignored failure, ppc64el: Ignored failure, s390x: Pass
<cjwatson> or possibly it should just be "modprobe overlayfs" or whatever at the start of the test ...
<sergiusens> cjwatson: sorry for being obtuse, but modprobe overlay or overlayfs; also after that maybe an equivalent in the test code to `grep -qw overlay /proc/filesystems` ?
<Laney> I don't have a thing called overlayfs in /proc/filesystems, or a module called overlayfs on my 17.04 laptop here
<Laney> do have 'overlay' though
<Laney> didn't get renamed, did it?
<sergiusens> which is why I ask -> /lib/modules/4.11.0-3-generic/kernel/fs/overlayfs/overlay.ko
<cjwatson> click.chroot has union-type=overlayfs in schroot
<cjwatson> so if there's a compat problem here then it's surely also a compat problem for some real users
<sergiusens> cjwatson: so what would your suggestion be then?
<cjwatson> I don't have one, just trying to bound the problem
<sergiusens> cjwatson: seems stgraber already ran into this (2 years ago) https://github.com/lxc/lxc/issues/389  and they treat it as just a name change
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808387 is loosely related
<ubottu> Debian bug 808387 in src:schroot "[schroot] Add support for overlay mounts." [Wishlist,Open]
<cjwatson> suggests there's some extra work needed in schroot
<cjwatson> hmm, sbuild-createchroot just does union-type=overlay though
<cjwatson> sergiusens: maybe just try http://paste.ubuntu.com/24800036/ ?
<cjwatson> sergiusens: (will at best only work for >= yakkety, so probably don't SRU that bit if you can avoid it)
<sergiusens> cjwatson: are you ok with something like http://paste.ubuntu.com/24800080/ + the debian/control change?
<cjwatson> sergiusens: yeah, I guess so
<sergiusens> cjwatson: I created https://code.launchpad.net/~sergiusens/click/schroot_configuration_overlay_detection/+merge/325234
<cjwatson> sergiusens: approved.  fix your bzr configuration :)
<sergiusens> oh, not again...
<sergiusens> I have a darn test that break my bzr config
<cjwatson> you want that fixture that sets a separate bzr home
<cjwatson> actually even just something like this should work fine:
<cjwatson>     bzr_home = self.useFixture(TempDir()).path
<cjwatson>     self.useFixture(EnvironmentVariable('BZR_HOME', bzr_home))
<cjwatson>     self.useFixture(EnvironmentVariable('BZR_EMAIL'))
<cjwatson>     self.useFixture(EnvironmentVariable('EMAIL'))
<cjwatson> (from launchpad-buildd)
<sergiusens> oh, thanks, will bring that in
<gQuigs> vtapia: can we get sssd back to phasing of 0 so no one else gets it? (re: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508)
<ubottu> Launchpad bug 1566508 in sssd (Ubuntu Trusty) "autofs races with sssd on startup" [Medium,In progress]
<gQuigs> (regression bug: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1695870)
<ubottu> Launchpad bug 1695870 in sssd (Ubuntu) "[regression] sssd won't start if autofs is not installed" [Undecided,Confirmed]
<sergiusens> slangasek: any idea who can help me with https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/c/click/20170607_145035_9dff8@/log.gz ? is overlay loaded at all in the testbed and should I just modprobe it in? This has been failing since zesty closed/artful opened
<vtapia> gQuigs: yes. The fix is in verified in -proposed, but it still has to wait 6 more days
<gQuigs> vtapia: don't we usually pull the previous update when it's a clear regression?
<gQuigs> (and critical..)
<vtapia> gQuigs: first regression I had to deal with, so I just created a patch thinking it would bypass the 7 days wait
<jbicha> vtapia: you can ask in #ubuntu-release for an exception, the 7-day rule is a guideline not a mandatory rule
<vtapia> ah, ok, thanks jbicha
<mwhudson> jbicha: congrats
<jbicha> thank you
<nacc> xnox: if you have some cycles, could you look at the journal just posted at LP: #1569925 -- it feels like open-iscsi.service After=iscsid.service is not resulting in open-iscsi.service being shutdown before iscsid.service?
<ubottu> Launchpad bug 1569925 in systemd (Ubuntu) "Shutdown hang on 16.04 with iscsi targets" [High,Confirmed] https://launchpad.net/bugs/1569925
<xnox> nacc, *sigh*
<xnox> nacc, i claim there are ordering bugs in systemd in xenial.
<ginggs> any ideas why gcc would recently start warning about stuff changing in GCC 7.1 on armhf only? it trips up autopkgtests that don't expect output on stderr. e.g. glbinding, ciftilib, fast5
<infinity> ginggs: I assume because that incoming change is only on ARM.
<nacc> xnox: yeah :)
<ginggs> infinity: ah, so what's the solution here?  ignore the test failures, or patch the packages to allow output on stderr?
<ginggs> or shut gcc up?
<infinity> ginggs: I imagine the right answer is to not produce the warning, or rebuilds with gcc 7.1 will fail.  But doko's looking into it right now.
<infinity> doko: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/fast5/20170603_001528_9d44b@/log.gz
<infinity> ginggs: Not looking into fixing the packages, but what the warning is all about. :P
<ginggs> infinity: thanks. doko: o/
<doko> ginggs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
<ubottu> gcc.gnu.org bug 77728 in target "[5 Regression] Miscompilation multiple vector iteration on ARM" [Normal,New]
<doko> ginggs: it's an architecture specific warning
<ginggs> doko: so the actual issue is fixed in 7.1 and the gcc 6 just prints the warning?
<doko> yes
<infinity> Which means the code needs to be fixed to not throw the warning before we switch to gcc-7.
<ginggs> infinity: i thought it was warning of an abi change
<ginggs> the bug was in gcc
<infinity> Oh, perhaps just that.  Yes.
<infinity> Well, "just".
<ginggs> ok, so what can we do about packages built with gcc 6 that are failing tests now because of the warning?  can we make gcc not warn about that?
<infinity> -Wno-psabi
<infinity> Or we can skip the tests for now, if that's the only failure.
<infinity> Which might be preferable to reuploading to ignore warnings.
<ginggs> could we pass -Wno-psabi from dpkg?
<infinity> ginggs: A) Ick, B) It wouldn't fix the one I'm looking at, which doesn't use dpkg-buildflags.
<doko> -Wno-psabi covers more than that
<infinity> Yeah.
<infinity> I think identifying the failing tests and skipping them for now is the answer for today.
<infinity> As in hinting them, not uploading changes.
<infinity> Well, or fix the code in question to not trip the warning in the first place, so it won't have an ABI change between 6 and 7.  But that would likely just change its ABI today instead. :P
<ginggs> infinity: ack. p.s. have you looked at my mail about archive admin, do you need me to send it again?
<ginggs> infinity: i still don't see that the packages need to be fixed.  i read it that the caller and the callee both need to be compiled with 7.1
<infinity> ginggs: Not saying they need to be "fixed", just that if they were changed, they could avoid the issue.
<infinity> ginggs: But indeed, the sanest plan of action is to find all of the packages in this state, record them, and make sure we do ABI transitions for them when 7 is the default.
<infinity> ginggs: As for the AA thing, I've spent a long time waffling on it.
<ginggs> but as you say, they can avoid an ABI change with gcc 7.1, by having an ABI change now
<infinity> ginggs: For now, I think if you've spotted packages with this issue, I should just hint some badtests and move on.
<ginggs> is there a good place on the wiki to record these packages?
<infinity> ginggs: Not currently.  Could create an ArmGcc7AbiTransition page or something if you want.
<nacc> xnox: do you have any hints of where to look? I'd be happy to help try and resolve it -- and also in that bug, we have two people hitting (at least related issues), and are very responsive to test
<xnox> nacc, does it work in artful correctly?
<nacc> xnox: i'm not sure -- i'll ask if they can test
<sergiusens> slangasek: if you have a minute I need someone with access to click here: https://bileto.ubuntu.com/log/2790/finalize/
<slangasek> sergiusens: clicked
#ubuntu-devel 2017-06-08
<tsimonq2> jbicha: Congrats on becoming a Core Dev :)
<LocutusOfBorg> jbicha, congrats!!!
<Unit193> mdeslaur: I presume you saw https://bugs.debian.org/864400 / CVE-2017-9469 / CVE-2017-9468?  I prepped the artful upload, but it's a simple merge there (https://sigma.unit193.net/source/irssi_1.0.3-1ubuntu1.dsc)
<ubottu> Debian bug 864400 in src:irssi "irssi: CVE-2017-9468 CVE-2017-9469" [Important,Fixed]
<ubottu> In Irssi before 1.0.3, when receiving certain incorrectly quoted DCC files, it tries to find the terminating quote one byte before the allocated memory. Thus, remote attackers might be able to cause a crash. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9469)
<ubottu> In Irssi before 1.0.3, when receiving a DCC message without source nick/host, it attempts to dereference a NULL pointer. Thus, remote IRC servers can cause a crash. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9468)
<mdeslaur> Unit193: I've got irssi packages in the security team ppa for publishing on monday
<mdeslaur> Unit193: did you upload to artful, or do you need sponsoring or something?
<Unit193> mdeslaur: Figured you'd be quick on it, but didn't see it either.  Sounds good.  That was just in case you hadn't gotten to it yet, I didn't push it (well, can't anyway, not a core dev.)
<nacc> mwhudson: have you ever seen: LP: #1568902 ?
<ubottu> Launchpad bug 1568902 in golang-github-coreos-go-systemd (Ubuntu Xenial) "Bump go-systemd in Ubuntu Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1568902
<roaksoax> does anyone know what will the default python3 be for 17.10 ?
<roaksoax> nacc: ^^ you mabe ?
<roaksoax> maybe*
<nacc> roaksoax: i don't know officially, but i think we're in the middle of the python3.6 transition
<roaksoax> nacc: thanks!
<Logan> xnox: are we bumping OpenSSL in Artful?
#ubuntu-devel 2017-06-09
<xnox> Logan, we are discussing it right now. There is a list of questions we have and how we gonna do it.
<Unit193> That might be surprising since openssh, bind9, and apache2 don't support it as-is.
<xnox> there are dependencies and security considerations
<xnox> also ruby2.4
<Unit193> Right, didn't mention that one.  Ruby 2.5 supports, but I'm presuming that's why do ko was asking #debian-ruby.
<Unit193> (Err, fixed in 2.4, they're skipping directly to .5)
<xnox> yes
<Unit193> mapreri: Danke.
<mdeslaur> Unit193: do you want me to upload your irssi merge to artful?
<Laney> Odd_Bloke: hey, is there any chance of arm64/artful cloud images (in SS bos01)?
<elopio> stgraber: hey, the failure on the snapcraft autopkgtest that's blocking your lxd SRU was a problem with the launchpad proxy
<elopio> a re-run should help.
<stgraber> elopio: ok, cool, thanks
<abeato> infinity, hey. there has been no response yet for the patch submitted to debian for lp: #1692494 , which should be the curse of action? Should I ping anybody about this?
<ubottu> Launchpad bug 1692494 in klibc (Ubuntu) "klibc does not support reboot arguments" [Undecided,New] https://launchpad.net/bugs/1692494
<mdeslaur> Unit193: I uploaded your irssi merge, hope you don't mind
<mwhudson> nacc: let's go with "no"
<mwhudson> nacc: wait what?
<mwhudson> nacc: distribute fleet as a snap kthxbye ?
<Odd_Bloke> Laney: We're building them; I think you'd have to bug IS to get them synced in.
<nacc> mwhudson: yeah, that might be a fine response :)
<mapreri> Unit193: anytime (for syncs I react right after I see the mails, don't really have time to go hunt more complex sponsorships these days, but if you need please poke me)
<elopio> tjaalton: hello. Can you help us putting snapcraft 2.31 in xenial, yakkety and zesty -proposed?
<elopio> slangasek: Sergio is asking why click was not dput-ed. Are we missing something there?
<slangasek> elopio: we are sprinting this week so hitting time constraints.  I will try to make time today
<elopio> slangasek: ok, it would be nice if we can spend
<elopio> the weekend testing.
<elopio> but I understand. Please ping me if I can help with something.
<Skuggen> elopio: Does it have snapcraft-specific users!? :P
<elopio> Skuggen: sorry, I don't understand.
<Skuggen> We are a bit blocked from making "proper" MySQL snaps because we can't change file ownership and drop process privileges
<elopio> Skuggen: yes, I know :( That's still on discussion in the forum.
<elopio> Skuggen: https://forum.snapcraft.io/t/snappy-and-users-and-groups/331
<Skuggen> elopio: Right, primarily #1619888
<mwhudson> nacc: did you look at celery yet?
<nacc> mwhudson: i'm working on it now, but about to travel home
<mwhudson> nacc: cool
<mwhudson> nacc: where are you guys?
<nacc> mwhudson: it needs several updated deps too (billiar, sphinx-celery)
<nacc> *billiard
<mwhudson> nacc: hooray
<nacc> mwhudson: so i'm having to iterate a bit :)
<mwhudson> nacc: want help? (i'm travelling today to though so....)
<mwhudson> *too
<nacc> mwhudson: i'm happy to churn on this for a bit -- if i don't make much progress on monday, i'll ping you -- if that's ok by you schedule wise?
<mwhudson> nacc: sure
<hallyn> huh, chan is locked down now?
<hallyn> bug 1697043 - is there a known bug in debconf right now?
<ubottu> bug 1697043 in lxcfs (Ubuntu) "package libpam-cgfs 2.0.7-0ubuntu1~16.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1697043
<Unit193> mdeslaur: No that's quite alright, thanks very much!
<Unit193> mapreri: And thanks, will do.  What do you feel about ruby?
<tdaitx> pitti, regarding adding the pid to apport reports, I forgot to ask if the way I proposed is good enough... I wonder if it would be better to do that from somewhere else? for example, add_proc_info seems to set it from other means (os.getpid) but I'm not sure we need to cover those other code paths
#ubuntu-devel 2017-06-11
<juliank> Tried installing 16.04.2 for a friend today. Wanted to have LVM on UEFI with separate home. Started with netboot image - did not work with UEFI (what's going on there); then switched to an Xubuntu image (because XFCE seems like a good fit), and got completely confused - the installer apparently was creating mbr partition tables, and we could not configure logical volumes ourself.
<juliank> In the end, I used cfdisk and pvcreate, vgcreate, lvcreate from the commandline and then selected the partitions in ubiquity.
<juliank> But boy, that was unnecessarily complex.
<juliank> (Lost about half an hour or so)
<juliank> I guess the UEFI thing https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1429030
<ubottu> Launchpad bug 1429030 in debian-installer (Ubuntu) "netboot mini.iso doesn't support UEFI boot" [High,Triaged]
<juliank> If anyone knows what I did wrong, please let me know :)
<juliank> (He previously had an Arch on there, with 150GB allocated to / and 250GB to /home, I thought that looked ridiculous, and his Arch friends did not appear today, so he runs xubuntu now...)
<juliank> We also got hit by bug 1581713 which he was not really happy about
<ubottu> bug 1581713 in Ubuntu GNOME "Ubuntu Software always asks for an Ubuntu Single Sign-On account when installing or removing a snap package" [High,Triaged] https://launchpad.net/bugs/1581713
<tsimonq2> juliank: Yesterday I did something similar with my laptop, encrypted LUKS partition on top of an ext4 root partition and I got secure boot working and everything with just a debootstrapped install and chroot.
<tsimonq2> juliank: If you want any info from me, let me know.
<juliank> tsimonq2: Oh we got it working, I just wonder why the installer did not let us configure it and I had to go to the console
<juliank> We were in manual mode after all, shouldn't we be able to freely configure logical volumes there?
<tsimonq2> juliank: I've had similar problems with Ubiquity on a Kubuntu Artful image but I assumed it was a hardware-specific thing because I could do it on every other computer.
<tsimonq2> I couldn't configure it either.
<tsimonq2> But I know exactly what you're talking about.
<tsimonq2> (because I've had that problem too)
<juliank> That's actually the first thing I installed on LVM I think. While my Debian runs on LVM, I actually migrated that on the command line after a few years, and never used an installer for the LVM part.
<juliank> tsimonq2: There was also weirdly enough an option to choose where to install the bootloader on, which I thought was ridiculous on an EFI system.
<tsimonq2> Well before I just said "f*** it, I'm doing this with the Arch wiki and debootstrap," I did try encrypted LVM
<tsimonq2> juliank: I agree
<juliank> Oh the arch wiki, what would you need that for?
<juliank> Half of the install guide stuff there does not work here, does it?
<tsimonq2> juliank: I had no idea what I was doing and it was the first thing that came to mind :P
<tsimonq2> https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Simple_partition_layout_with_LUKS
<tsimonq2> juliank: And we have that as part of our install guide?!?!? :O
<juliank> I guess it's partitioning (ESP + LVM + pvs + vgs + lvs), then debootstrap to /target, and then edit /etc/fstab mount /proc and /sys and /dev in the chroot, install grub-efi, run update-grub, run adduser to add a user
<juliank> + cryptsetup before the LVM of course :)
<tsimonq2> juliank: Well I just put /boot/efi on sdb1, /boot on sdb2, and / on sdb3
<tsimonq2> I was in #ubuntu yesterday figuring out how to do this because this is my first EFI system I've ever had :P
<juliank> I put /boot/efi on sda1, and LVM PV in sda2, and just /, /home, and /swap in there - why maintain a separate /boot, makes no sense to me, really
<tsimonq2> I didn't know what I was doing lol
 * juliank is happy hibernate works with swap-in-lvm. At first it did not, Xorg crashed on resume, but installing the updates fixed that :)
<juliank> tsimonq2: It's mostly a matter of preferences, really
<juliank> (where to have a separate /boot or not)
<juliank> Heck, my own system has a separate /var
<tsimonq2> juliank: Yeah, I usually have a separate /home but I decided against it.
<tsimonq2> (on the laptop)
<juliank> tsimonq2: May I ask why?
<tsimonq2> juliank: Why the separate /home in the first place or why I decided against it?
<juliank> More the latter
<tsimonq2> Because I didn't have confidence my root on LUKS would work, let alone multiple partitions :P
<tsimonq2> tsimonq2> I didn't know what I was doing lol
<juliank> I see
<juliank> For future reference: If you want multiple partitions on LUKS, you usually put an LVM PV on top of the LUKS, then you add add logical volumes in there.
<tsimonq2> Ah, ok.
<juliank> And LVM is useful, really useful. You can start out with small partitions and increase sizes based on demand :)
<tsimonq2> When I reinstall it next, I'll probably just do that :)
<tsimonq2> juliank: Thanks for the advice
<juliank> and you could do snapshots with lvm, although there are two types and I'm not sure how that works :)
<juliank> Oh, that's actually quite easy it seems
<juliank> (Take a snapshot of my Debian partition in my linux volume group, with 1GB CoW data storage: lvcreate -L1G -s -n rootsnap /dev/linux/Debian)
<tsimonq2> Interesting.
<juliank> tsimonq2: I guess this guide works for the LVM stuff: https://wiki.archlinux.org/index.php/LVM#Installing_Arch_Linux_on_LVM
<juliank> tsimonq2: In your case, obviously instead of /dev/sda2, you'd run pvcreate on your /dev/mapper/<crypt device>
<tsimonq2> juliank: Ah, ok.
#ubuntu-devel 2018-06-04
<CyberManifest> Sorry to bother, but I'm curious about which version of Debian that Ubuntu 18.04 (Bionic Beaver) is predominately "based" off of?
<cjwatson> We routinely sync/merge from unstable up to a couple of months before release (and sometimes less than that in selected cases)
<CyberManifest> cjwatson: thank you so very very much
<cjwatson> So it's not based off a particular Debian stable release
<CyberManifest> cjwatson: you've answered my question satisfactorily, thank you, and thank you for your time and consideration; forgive my interruption, please carry on.
<sil2100> apw: this should interest you I guess: https://code.launchpad.net/~sil2100/ubuntu-archive-tools/retry-and-manual/+merge/347395
<apw> sil2100, yeah :)
#ubuntu-devel 2018-06-05
<slangasek> stgraber, kees, mdeslaur: hmm as we are sprinting this week, I am uncertain infinity and I will be attending the TB meeting, it's right over the lunch block
<mdeslaur> slangasek: ack, let's skip it
<stgraber> fine with skipping
<slangasek> oh I lose at calendaring
<slangasek> lunch doesn't start here until 12:30 :P
<slangasek> soooo we could still meet? :)
<mdeslaur> we could
#ubuntu-devel 2018-06-06
<jamesh> Trevinho: what plans do we have about updates to mutter/gnome-shell going forward in bionic?
<rbasak> sil2100: do you have an opinion on the current SRU for ebtables in the Xenial queue in bug 1774120? I ask because of your comment https://bugs.launchpad.net/ubuntu/+source/ebtables/+bug/1774120/comments/14
<ubottu> Launchpad bug 1774120 in ebtables (Ubuntu Bionic) "ebtables cannot be upgraded from 2.0.10.4-3.5ubuntu2 to 2.0.10.4-3.5ubuntu2.18.04.1 on WSL" [Low,In progress]
<rbasak> Perhaps the SRU should be deferred until everyone is happy with the development fix?
<rbasak> ddstreet: looks like bug 1761442 is missing SRU information?
<ubottu> bug 1761442 in sosreport (Ubuntu Bionic) "sosreport: AttributeError: 'str' object has no attribute 'decode'" [High,In progress] https://launchpad.net/bugs/1761442
<ddstreet> rbasak thnx will add it
<Trevinho> jamesh: not many so far, waiting for upstream dot releases mostly
<Trevinho> jamesh: while I think we've to fix some of our patches too, though
<jamesh> Trevinho: okay.  I ran into this mutter bug while working on portal support: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1774560 -- if we're likely to pick up the fix with a regular update then it might not be worth trying to backport the fix
<ubottu> Launchpad bug 1774560 in xdg-desktop-portal-gtk (Ubuntu) "xdg-desktop-portal-gtk malfunctions on Wayland: wl_display@1.error(zxdg_imported_v1@36, 0, "set_parent_of was called with an invalid child")" [Undecided,New]
<Trevinho> jamesh: both are in 3.28 so, we'll get them
<coreycb> sil2100: we've decided not to upload python-pylxd to artful. would you mind rejecting those?
<sil2100> coreycb: hey! Ok
<coreycb> sil2100: thanks!
<sil2100> coreycb: done!
<coreycb> sil2100: great thanks again :)
 * sil2100 goes AFK for a bit
<Trevinho> sil2100: when your're back, could you please reapprove https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1766137 ?
<ubottu> Launchpad bug 1766137 in gdm3 (Ubuntu Bionic) "[regression] Password accepted but login fails (blank purple screen and mouse pointer only)" [High,In progress]
<Trevinho> I mean the pkg standing in the SRU queue
<boboma> xnox, hello. you were working on https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1351267
<ubottu> Launchpad bug 1351267 in partman-auto (Ubuntu Xenial) "partman-auto prefers to give disk to swap, leaving root too small" [Critical,Fix released]
<boboma> but your fix unfortunately created another bug
<boboma> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1767299
<ubottu> Launchpad bug 1767299 in ubiquity (Ubuntu) "Ubuntu 18.04 Installer creates swap partition too small" [Undecided,Confirmed]
<boboma> Could you look into that?
<boboma> or your fix didn't solve all the problem. Either way, it would be nice to have your attention on this.
<LocutusOfBorg> Laney, please upload modemmanager from costamagnagianfranco/locutusofborg-ppa?  libmbim libqmi modemmanager
<LocutusOfBorg> I can do it if you want :)
<Laney> LocutusOfBorg: not clear why you're asking me, sorry
<Laney> my merge or something?
<LocutusOfBorg> yeah
<LocutusOfBorg> "don't steal merges" policy :)
<Laney> alrighty, then feel free
<LocutusOfBorg> thanks!
<Laney> I think I had hoped they'd become syncable again
<LocutusOfBorg> they aren't :/
<LocutusOfBorg> libqmi has just one flag in rules file, don't know if you forwarded it
<Laney> dunno, maybe I forgot, was release week
<Laney> if you have time to do that it would be nice :(
<LocutusOfBorg> modemmanager delta should be upstream now
<LocutusOfBorg> maybe on next release
<Laney> still need to pass the flag though I think
<LocutusOfBorg> ack yeah
<LocutusOfBorg> let me open a bug
<Laney> thanks â¥
<LocutusOfBorg> opened two bugs!
<LocutusOfBorg> [17:36:15] <BTS> Opened #900907 in modemmanager 1.7.990-1 by Gianfranco Costamagna (locutusofborg) Â«please enable verbose warning buildÂ». https://bugs.debian.org/900907
<ubottu> Debian bug 900907 in modemmanager "modemmanager: please enable verbose warning build" [Normal,Open]
<LocutusOfBorg> [17:39:19] <BTS> Opened #900909 in libqmi 1.20.0-1 by Gianfranco Costamagna (locutusofborg) Â«please enable verbose warning buildÂ». https://bugs.debian.org/900909
<ubottu> Debian bug 900909 in libqmi "libqmi: please enable verbose warning build" [Normal,Open]
<xnox> slangasek, infinity - lynx is better at plain-text dumping of html to txt; such that it is useful for html emails with URLs https://paste.ubuntu.com/p/z2BfZ3XHJM/
<xnox> note the [1] references [1] http:/// url
<slangasek> xnox: why do I care about that in this context?
<xnox> or are there more options to do that with w3m?
<xnox> slangasek, mailman3 recommends lynx to dump html emails to text; for text delivery for distribution
<slangasek> xnox: I understand, but why is that interesting at all?  I think the Recommends is simply wrong
<xnox> slangasek, drop to suggests, and move on with my life?
<slangasek> why should your mailing list manager edit the messages in the middle?
<slangasek> xnox: that's my current view
<xnox> slangasek, it's in the default config, to do this. no idea how common it is to receive html-only emails; i though most crazy things send dual emails these days.
<xnox> slangasek, ok.
<slangasek> xnox: even if someone does send an html-only email, it seems bizarre to me for the mailing list manager to modify that in-band, /by default/
<xnox> slangasek, it's a user option in mainmal when one subscribes to opt-into mailing list do that. as far as i remember =)
<xnox> anyway, that's fine.
<slangasek> xnox: ideally the option would not be presented when lynx is not available, but
<andyrock> bdmurray: can you take a look https://code.launchpad.net/~azzar1/software-properties/fix-lp-1770686/+merge/345437 ?
<bdmurray> andyrock: I'm at a sprint but will try and have a look.
<andyrock> kk
<andyrock> thx
<andyrock> bdmurray: fixed thx
<doko> jamespage: please could you have a look at LP: #1108935, if that one is still needed, and if yes, seed it, or add a dependency?
<ubottu> Launchpad bug 1108935 in websockify (Ubuntu) "[MIR] websockify, spice-html5" [High,New] https://launchpad.net/bugs/1108935
#ubuntu-devel 2018-06-07
<doko> dpb1, cpaelzer: please could you have a look at LP: #1262290. it's an approved MIR, but I don't know the history ... would need seeding, or a dependency somewhere
<ubottu> Launchpad bug 1262290 in The Dell-poweredge project "[MIR] wsmancli" [Undecided,New] https://launchpad.net/bugs/1262290
<rbasak> infinity: do you want to reject debhelper from the SRU queues then?
<doko> rbasak, jamespage: please could you comment on LP: #1273865, if that is still needed?
<ubottu> Launchpad bug 1273865 in websocket-client (Ubuntu Utopic) "[MIR] juju-quickstart, python-jujuclient, urwid, websocket-client" [Undecided,Won't fix] https://launchpad.net/bugs/1273865
<infinity> rbasak: I mean, backporting that commit isn't particularly "wrong", but if the goal is to fix the rsyslog-versus-systemd bug, that's not how it should be done.
<infinity> rbasak: So, rejecting it on the basis that it's not necessary to fix said bug seems reasonable.
<infinity> rbasak: On the other hand, it's not incorrect that ignoring /etc overrides is wrong. :P
<infinity> rbasak: (But we don't really want to rebuild everything in the archive with a tmpfiles.d snippet to fix that)
<infinity> rbasak: Or maybe we do.  But that's a much larger bugfix than first proposed.
<infinity> rbasak: xnox's take is that it's a systemd-tmpfiles bug that it's processing that snippet on --create at all, though.
<infinity> rbasak: Note that it gets it half right by not "fixing" the ownership while it does "fix" the permissions.
<karstensrage> hi infinity
<karstensrage> were  you the one that was going to help  me get my libnss modue into apt?
<karstensrage> module
<karstensrage> it was quite some time ago, and i took a little break, but maybe in the next 2 months im going to work on it again
<karstensrage> i already have two modules in apt, and they work great
<karstensrage> i was planning on mimic'ing that structure for the libnss package
<xnox> infinity, rbasak specific rsyslog vs systemd case can be fixed in systemd postinst; ubuntu is different from debian
<xnox> infinity, rbasak the feature of supporting /etc & /run (NB!) overrides in postinst is good, but I don't believe justifyable under SRU policy.
<tjaalton> LocutusOfBorg: virtualbox-hwe doesn't seem to build on cosmic
<LocutusOfBorg> tjaalton, it does :)
<tjaalton> my rebuild didn't
<tjaalton> ah, there's a new one, cool
<nav__> From remote login, how do i find out whether installed version is ubuntu desktop version or server version?
<doko> tjaalton: is LP: #1412441 still relevant? could you follow-up on that?
<ubottu> Launchpad bug 1412441 in libclc (Ubuntu) "[MIR] libclc" [Wishlist,Confirmed] https://launchpad.net/bugs/1412441
<doko> coreycb, jamespage: please could you follow-up on LP: #1420028, LP: #1420021 and LP: #1420017 ? they are not seeded anywhere
<ubottu> Launchpad bug 1420028 in openstack-nose (Ubuntu) "[MIR] openstack-nose" [Undecided,Fix committed] https://launchpad.net/bugs/1420028
<ubottu> Launchpad bug 1420021 in python-nose-exclude (Ubuntu) "[MIR] python-nose-exclude" [Undecided,Fix committed] https://launchpad.net/bugs/1420021
<ubottu> Launchpad bug 1420017 in python-nosehtmloutput (Ubuntu) "[MIR] python-nosehtmloutput" [Undecided,Fix committed] https://launchpad.net/bugs/1420017
<doko> xnox: LP: #1522003  claims that there is no copyright file. Please could you follow-up on this one?
<ubottu> Launchpad bug 1522003 in s390-dasd (Ubuntu) "[MIR] s390-dasd" [Undecided,Incomplete] https://launchpad.net/bugs/1522003
<doko> xnox: same for LP: #1522004
<ubottu> Launchpad bug 1522004 in s390-netdevice (Ubuntu) "[MIR] s390-netdevice" [Undecided,Incomplete] https://launchpad.net/bugs/1522004
<doko> bdmurray: please could you follow-up on LP: #1588558?
<ubottu> Launchpad bug 1588558 in pocl (Ubuntu) "[MIR] pocl" [Undecided,Incomplete] https://launchpad.net/bugs/1588558
<doko> jamespage: please could you follow-up on LP: #1592465 ?
<ubottu> Launchpad bug 1592465 in swift-plugin-s3 (Ubuntu) "[MIR] swift-plugin-s3" [High,Fix committed] https://launchpad.net/bugs/1592465
<coreycb> doko: jamespage: i've updated those bugs, all invalid at this point
<doko> jamespage, coreycb: please could you follow-up on LP: #1643608
<ubottu> Launchpad bug 1643608 in python-pyldap (Ubuntu) "[MIR] python-pyldap" [Undecided,Incomplete] https://launchpad.net/bugs/1643608
<doko> coreycb: ta
<coreycb> doko: 1643608 done
<infinity> karstensrage: That may have been me, yes.
<GunnarHj> slangasek: Saw your action on bug #1701047. How is fonts-guru-extra special in this respect?
<ubottu> bug 1701047 in fonts-orya-extra (Ubuntu) "Renaming of conf file fails" [Undecided,New] https://launchpad.net/bugs/1701047
<slangasek> GunnarHj: I don't know, I haven't looked at the version history to understand.  But fonts-guru-extra is definitely the only one where the bug affected me in practice.
<slangasek> GunnarHj: it's possible that for the other packages, the buggy version was never in a release
<GunnarHj> slangasek: Ok. My understanding is that the issue is present in the same manner for those who have installed the other packages.
<slangasek> GunnarHj: sure, but if it doesn't affect users of stable releases, it is a much lower priority to fix
<GunnarHj> slangasek: True. It was a while, will take a closer look. (I'm surprised that they haven't fixed it in Debian.)
<karstensrage> infinity, so are you up for it?
<ahasenack> does anybody here recall why ubuntu has had -Wl,-Bsymbolic-functions in LDFLAGS for about 10y now, and debian does not?
<ahasenack> I just came across a delta in autofs because of that option
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1470687
<ubottu> Launchpad bug 1470687 in autofs (Ubuntu Vivid) "Not working properly with compile options "-symbolic-functions"" [Undecided,Fix released]
<infinity> GunnarHj: I think the difference is just that only fonts-guru-extra is in ubuntu-desktop, I suspect the same bug exists in all that maintainer's packages.
<infinity> GunnarHj: (Since he "fixed" them all at the same time)
<infinity> karstensrage: Potentially.  I'm at a sprint this week, so limited time to pay attention to the outside world.
<karstensrage> ok well it will take me more than a week
<GunnarHj> slangasek: Right; I just saw that fonts-guru (which depends on fonts-guru-extra) is in desktop-common in Xenial. So yes, that particular package affects everyone unlike the other.
<karstensrage> i have to page in the context for how to do it again
<karstensrage> but at least i can ping you and let you know when i think its ready for a look?
<GunnarHj> slangasek: So I suppose it means that if "someone" finds the time to fix the others, that would be helpful. ;)
<GunnarHj> infinity: ^ pinged slangasek instead of you...
<infinity> GunnarHj: fonts-guru is a metapackage that doesn't have files (and, thus, doesn't have the bug)
<infinity> GunnarHj: But yes, I'm positive the bug exists in several other packages, as per the debian bug number where the bug was introduced.
<infinity> Debian bug #853848 references a bunch of packages from the same maintainer with the same issue.
<ubottu> Debian bug 853848 in fonts-deva-extra "fonts-deva-extra: unneeded directory in /etc/fonts/conf.avail/" [Normal,Fixed] http://bugs.debian.org/853848
<GunnarHj> infinity: Right, understood. Personally I find it worth fixing all of them, even if fonts-guru-extra is most important since it affects everyone. Will triage the bug report accordingly.
<infinity> GunnarHj: Yeahp, I absolutely agree they should all be fixed the same way, Steve was just scratching his own itch after I pointed out the issue and it gave him an aneurysm.
<doko> jamespage, coreycb: please could you follow-up on LP: #1737989?
<ubottu> Launchpad bug 1737989 in ujson (Ubuntu) "[MIR] ujson?" [Undecided,Incomplete] https://launchpad.net/bugs/1737989
<doko> cpaelzer: looking at LP: #1744072, why are there tasks for cloud-init and maas, they are already in main. If there needs something to be done, could you file a separate issue, so that we can close the MIR?
<ubottu> Launchpad bug 1744072 in maas (Ubuntu) "[MIR] Chrony in 18.04" [Critical,In progress] https://launchpad.net/bugs/1744072
<GunnarHj> infinity: ;)
<doko> xnox: please could you follow-up on LP: #1766451 and 1746680?
<ubottu> Launchpad bug 1746680 in xe-guest-utilities (Ubuntu) "[MIR] xe-guest-utilities" [Medium,Triaged] https://launchpad.net/bugs/1746680
<ubottu> Launchpad bug 1766451 in xe-guest-utilities (Ubuntu) "remove the shell script for 18.10" [High,Confirmed] https://launchpad.net/bugs/1766451
<tjaalton> doko: I don't think that bug matters anymore, now that build-deps can be from universe
<tjaalton> doko: libclc that is
<cpaelzer> doko: I closed th ebug tasks
<cpaelzer> doko: thanks for spotting it
<cpaelzer> TL;DR: that was for both tools to adapt their ntp service config to chrony for >=Bionic
<GunnarHj> slangasek: Still there? I posted a reply on the bug report.
<slangasek> GunnarHj: ok, you're probably right that it impacts any users that did have the old version of the package installed outside of the stock desktop dependencies
<GunnarHj> slangasek: Then we are agreed, good. I'll proceed with the other packages. (Tomorrow or this weekend.)
<doko> pjdc: about anope: we need to add that to some seed ... any proposal which one?
<xnox> doko, https://bugs.launchpad.net/debian/+source/s390-netdevice/+bug/1522004
<ubottu> Launchpad bug 1522004 in s390-netdevice (Ubuntu) "[MIR] s390-netdevice" [Undecided,Fix released]
<xnox> doko, i hope my update on that one, is enough / appropriate.
<pjdc> doko: sorry, i don't even know what a seed is. typically we're interested in things being in main so that they gain security support, if that helps
<pjdc> doko: although i don't know that was the entirely of lamont's motivation
<pjdc> doko: assuming i'm looking at the page, i guess "supported"?
<sarnold> "it's a C binary compiled into `postinst`" .. wha? :)
<pjdc> doko: supported-misc-servers perhaps
<Unit193> Anope IRC services?
<doko> pjdc: right, but I'd like to have the server team to do the seeding. could you chase them down?
<pjdc> i can try!
#ubuntu-devel 2018-06-08
<lamont> pjdc: doko: +1
<cpaelzer> doko: hi, one question about tracking syncs
<cpaelzer> doko: I saw you asked jbicha about brotli - I always wondered how one could/would track who did a sync
<cpaelzer> did you derive that from the changes file that was generated on the sync?
<cpaelzer> or what are your usual steps to determine who has done a particular sync?
<Unit193> cpaelzer: Eg, https://launchpad.net/ubuntu/+source/brotli/1.0.4-1/+publishinghistory expand the proposed one.
<cpaelzer> Unit193: yeah, thanks
<cpaelzer> I was expecting to see it anywhere on https://launchpad.net/ubuntu/+source/brotli/1.0.4-1 as well
<cpaelzer> but from publishing history is fine, this isn't an info you need very often anyway
<Unit193> Can be useful though.
<cpaelzer> absolutely
<GunnarHj> wgrant: Can you please look at bug #1758684. LP fails to import some (randomly determined?) strings over and over again. Manual uploads work.
<ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
<wgrant> GunnarHj: Hm, where did you get the POT that you manaully uploaded?
<wgrant> GunnarHj: Pretty sure LP is in the right here; compare the sizes of the top six tarballs on https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=snapd
<wgrant> snapd seems to product different POTs depending on the arch it's built on, which is certainly innovative.
<wgrant> wgrant@lamuella:/tmp$ diff -u {arm64,i386}/source/po/snappy.pot | diffstat
<wgrant>  snappy.pot | 1622 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
<wgrant>  1 file changed, 1620 insertions(+), 2 deletions(-)
<wgrant> Never seen anything quite like that.
<GunnarHj> wgrant: Hmm.. That's an aspect I haven't even noticed. Always looked at the amd64 tarballs.
<GunnarHj> wgrant: But I'm aware of the fact that the snapd template generating is fragile. That's a separate snapd issue. But it would be good if we could make LP behave as expected given the templates which are generated.
<wgrant> GunnarHj: Yeah, I only thought to check because it made literally no sense at all otherwise.
<wgrant> GunnarHj: LP is behaving as expected. The most recently uploaded template wins.
<wgrant> Unioning the templates isn't sensible.
<wgrant> LP's doing all it can.
<GunnarHj> wgrant: Ah, is that it. That may explain it then. Thanks for valuable input!
<wgrant> GunnarHj: Thanks for looking at this.
<wgrant> Hopefully snapd people have some idea on this bug.
<wgrant> i'll certainly be following it just because the bug has to be pretty entertaining to have this result...
<GunnarHj> wgrant: Wouldn't use the word "entertaining" ... :(
<GunnarHj> wgrant: The are using something called xgettext-go:
<GunnarHj> https://github.com/snapcore/snapd/blob/master/update-pot
<wgrant> GunnarHj: Hm, that uses "go install" so it's probably not the thing that's run during the build on LP
<wgrant> Unless something weird is going on
<wgrant> Oh though xgettext-go is from snapd itself
<wgrant> because of course it is
<wgrant> Though I can't see what runs update-pot
<wgrant> i18n/i18n.go://go:generate update-pot
<wgrant> unless it's that
<cjwatson> Yes, that comment isn't a comment
<cjwatson> /o\
<cjwatson> https://blog.golang.org/generate
<wgrant> Do I want to know
<cjwatson> No
<GunnarHj> wgrant, cjwatson: If you see something weird there, I'm sure the snapd team would appreciate a hint.
<cjwatson> I'm just remarking on the ridiculous Go overloading of comments; I have nothing particularly useful to contribute
 * wgrant is firing up a VM to run update-pot and see what happens
<Skuggen> Does anyone have an overview of the configuration of autopkgtest used in Ubuntu? I'm working on some MySQL 8.0 packaging, and get some dep8 failures because the test suite need more ram and test timeout than the default setting
<sil2100> Laney: I just accepted all your gstreamer packages for bionic - just make sure that the few 1.14.1 packages that are still stuck in cosmic-proposed migrate
<sil2100> Since there were a few that were still sitting there
<Laney> sil2100: thanks!
<sil2100> yw!
<Laney> they're stuck in the migration of hell
<Laney> which I saw people were working on; so, hopefully when that moves on a bit they'll go in
<Laney> or at least we'll see if there's anothe rproblem
<doko> cpaelzer_: usually I get this from the changes emails (I'm subscribed to these)
<xnox> slangasek, when upstart chroot sessions are disabled; initctl version still responds inside a chroot, when the host system has upstart. Do you think that is correct symantics? or a bug, which we should have fixed...?!
<xnox> sladen, balint and I discovered this yesterday, in the context of building trusty images
<slangasek> xnox: seems like correct semantics to me
#ubuntu-devel 2019-06-03
<raghu_> hi
<raghu_> i'm new to open source and would like to contribute to ubuntu os,can some one help me out with the getting started page
<raghu_> hi
<amurray> hi raghu_ - have you seen this page yet? https://wiki.ubuntu.com/ContributeToUbuntu
<raghu_> hello amurray  - i am just checking it out to contribute to the main repository,thanks for sharing the link
<smoser> xnox: you see an obvious reason for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831258 ?
<ubottu> Launchpad bug 1831258 in systemd (Ubuntu Eoan) "journalctl --list-boots does not recognize boots in a container" [Undecided,New]
<xnox> smoser:  hmmm looks odd. in a meeting now, will get to it.
<smoser> xnox: i agree it seems odd ;) . thanks
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
#ubuntu-devel 2019-06-04
<xnox> slashd:  when uploading d-i please commit to vcs lp:~ubuntu-core-dev/debian-installer/ubuntu and there are branches for stable series too.
<cpaelzer> hi, I'm trying to use a launchpad build recipe but I need to "fuse" d/p/series and various ways I tried failed me so I wanted to ask for best practise
<cpaelzer> I tried a d/p/ dir with custom patches and a commit that extend d/p/series - but that fails on git auto-merge (even thou it is trivial)
<cpaelzer> next I provided a d/p/myseries, and in the recipe ran like "run cat d/p/myseries >> d/p/series"
<cpaelzer> that seemed to work, but after applying all patches the package already brings, the extra patches fail to apply
<cpaelzer> but not with a actual "failed to patch"
<cpaelzer> I get gitbuildrecipe.deb_util.NoSuchTag
<cpaelzer> I also tried to patch things myself with run commands that do like "run patch ..." those worked, but since buildpackage later on cleans and applies things fell apart
<cpaelzer> hence I'm looking for best practise or examples of lp recipies "fusing" a full debian package (content + debian dir) with another repo that has "more" patches to add on top
<cpaelzer> any hint welcome
<cpaelzer> the no such tag is the code path for non-native packages (trying to get a tarball)
<cpaelzer> from there it falls back to consider building from the local tree, and there quilt bails out (to the NoSuchTag is a red herring)
<cpaelzer> if only quilt would have any error message, it applies things (withotu error) until it ends and then complains "Command '['quilt', 'push', '-a', '-v']' returned non-zero exit status 1."
<cjwatson> I think the right answer is a commit that extends debian/patches/series, and so I would suggest trying git-build-recipe locally and seeing if you can work out why git is failing to do the trivial merge
<cpaelzer> I already try it locally with git-build-recipe
<cjwatson> And you may find that things work better if you arrange for either pristine-tar to work or for one of the repositories involved to have an upstream/<version> or upstream-<version> tag
<cpaelzer> it just isn't very verbose to tell me what fails
<cjwatson> Sure, but I have now told you what I think the right option to pursue is
<cjwatson> So that may narrow things down
<cjwatson> The "run" option is useless because LP won't honour that
<cpaelzer> the patch I'm currently on already extends d/p/series which works, just the quilt push later fails atm
<cpaelzer> I might adapt the git-build-recipe code to be more verbose at those places, maybe I find what breaks it atm
<cjwatson> The quilt push bit only happens if you don't have a way for it to get an upstream tarball
<cjwatson> Fix that and you will avoid that problem
<cjwatson> i.e.
<cjwatson> 12:03 <cjwatson> And you may find that things work better if you arrange for either pristine-tar to work or for one of the repositories involved to have an upstream/<version> or upstream-<version> tag
<cpaelzer> interesting
<cjwatson> So NoSuchTag is NOT a red herring
<cpaelzer> the remote I clone from has another branch with pristine-tar content (git-ubuntu) but since there are two such branches I need to make that known
<cjwatson> I mean maybe git-build-recipe should do better on that path, but you want to avoid being on that path
<cpaelzer> that might need to fetch ubuntu/pristine-tar and then set it as the local pristine-tar branch
<cpaelzer> Thanks for the hint cjwatson, I'll try to make it somehow recognize the pristine tar that I have
<cjwatson> I'm not sure why anyone would expect a branch called ubuntu/pristine-tar to work, given that pristine-tar doesn't consider such a branch name
<cjwatson> And in any case the upstream tarball is not logically connected to a distribution
<cjwatson> I would just rename ubuntu/pristine-tar to pristine-tar
<cpaelzer> well I don't expect it to work until I have created a local branch with the right non prefixed name
<cjwatson> pristine-tar fetches remote branches
<cpaelzer> that is the structure of git-ubuntu creating those branch names
<cpaelzer> which I'm not going to change atm :-)
<cjwatson> So weird
<cjwatson> But you could always have the repository that you're layering on top just have a pristine-tar branch
<cpaelzer> very true, thank you
<cpaelzer> that might be a way out
<cjwatson> Or a suitable tag
<cpaelzer> actually I just got it working to recognize the pristine-tar
<cpaelzer> that comes from git-ubuntu
<cpaelzer> no more NoSuchTag
<cjwatson> (I guess I can see why git-ubuntu does that: the tarballs might disagree and then what would it do?  But it's hard to see how that cooperates well with actual pristine-tar)
<cpaelzer> but still failing to apply quilt push -a
<cpaelzer> ah no here is my NoSuchTag, ok I'm considering adding it to the repo that I'm layering on top
<cjwatson> I am absolutely certain that quilt push -a is not called unless you get a NoSuchTag
<akik> what's ubuntu's policy on using NOPASSWD in sudoers? i'm asking because cloud-init is still doing it for the default user and cloud-init is originally a ubuntu project
<cjwatson> Ah, now I see https://bugs.debian.org/895377 which I guess is basically for this
<ubottu> Debian bug 895377 in pristine-tar "/usr/bin/pristine-tar: add support for specifing branch name to pristine-tar cli" [Normal,Open]
<cpaelzer> cjwatson: agreed as  i said "... here is my NoSuchTag" - it was just hidden in all the output
<cjwatson> Sorry, you were writing so many lines on IRC so quickly that I was having some difficulty keeping up :)
<ddstreet> tdaitx i notice the openjdk-8 (and other versions) autopkgtests have been failing for, well, ever...have you looked at the failure logs and/or are you working on fixing the tests?
<tdaitx> ddstreet: yeah, it is a known issue, the testsuite has thousands of tests, some of those are unstable tests, anyhow any of them need to be either ignored (by adding them to a blacklist in the testsuite itself) or fixed, there's a long term plan to get all of them fixed
<ddstreet> tdaitx ok cool - since they aren't useful now (I assume?) could you maybe disable them?  I would suggest hinting britney to ignore them, but it seems like you update them often enough that just hinting the latest version would still result in some annoying failures after each update...
<ddstreet> plus that will save time and energy re-running them when we know they aren't going to pass :)
<cpaelzer> cjwatson: I got a pristine-tar set up and have it working through the git-build-recipe steps
<cpaelzer> thanks for the hint
<cpaelzer> yet now I wonder about launchpad permission management. I'd expect that I can select owner/target-ppa for a group that I'm admin in
<cpaelzer> the group is private, maybe that makes it not present it to me on the UI of "new-recipe"
<cjwatson> cpaelzer: Recipes cannot use private components; the builder doesn't have permissions to fetch them
<cpaelzer> ok, good to know
<cjwatson> cpaelzer: (this is in theory fixable but would be a fair chunk of work)
<xnox> smoser:  commented on the list-boots bug. it's funny!
<smoser> wow. yeah.
<smoser> it really sucks though for using the journal
<xnox> smoser:  What can I say, your welcome! =)
<xnox> smoser:  i wonder, if journal should be assking for app specific bootid, under containers.
<smoser> i'll just reboot my host every time
<xnox> but then one would get a new bootid on every journald restart
<xnox> i guess we could stash it into /run/systemd/journal or something
<xnox> i would prefer lxd to fake boot_id though
<xnox> as it should be managing the container lifecycle
<smoser> yeah. it does do that with uptime
<xnox> smoser:  please open a bug at https://github.com/lxc/lxd/issues ?
<smoser> i think it'd be https://github.com/lxc/lxcfs
<smoser> and looks like it'd be pretty straight forward to put a random number
 * smoser learns something today
<xnox> smoser:  i'm not sure if there is any other way. cause at the moment containers know if the host has been rebooted or not.
<xnox> smoser:  and i'm not sure if journald has logs from containers... for a particular host... queried from the host.
<xnox> smoser:  maybe check if any other container solutions handle this at all or not
<smoser> here i'd been using the 'uuidd' service to get myself uuids.  but i could have just read from /proc/sys/kernel/random/uuid all along.
<smoser> but that would not have been as cool as using a dbus service.
<smoser> :)
<xnox> smoser:  https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn.c#L1841
<xnox> smoser:  so at least nspawn does things
<xnox> you can read /proc/sys/kernel/random/boot_id ;-)
<xnox> ah, wait that's the static one
<xnox> smoser:  please open a bug against lxcfs if that's where the code is, and do use the pointer to the nspawn's setup_boot_id code
<smoser> https://github.com/lxc/lxcfs/issues/285
<smoser> thank you xnox. i'll watch for your lxcfs pull request later today.
<xnox> hahahaha
<xnox> smoser:  you were already told now =)
<xnox> smoser:  and meh, i don't code in github.com/lxc* =)
 * xnox diehard C coder only
<smoser> xnox: that is C
<smoser> excuses--
<TJ-> is there some voodoo to understanding where to find the actual, meaningful, git commit logs for package git repos? All I see to find is "Import patches-unapplied ..."
<Odd_Bloke> TJ-: For the git-ubuntu repos, you mean?  AIUI, the uploader has to go through a specific process for their git history (if there is any!) to be included in those imports.
<Odd_Bloke> But rbasak could probably tell you more.
<TJ-> Odd_Bloke: specifically I'm looking at the grub2 git repo, but I've hit this several times with other packages and given up!
<ahasenack> TJ-: the import commits will really just record the change as a big chunk, like a debdiff. To preserve git history, an upload tag must be pushed to the repo together with the dput upload. Then, when the importer sees the new package to import, if its contents match the tree associated with that upload tag, the git rich history will be preserved
<ahasenack> so far only the server-owned packages have been following that, and when a member of the server team does the upload (because he can push said tag)
<TJ-> ahasenack: hmmm, so there's no way to easily see the real project history unless the developer takes care of it?
<ahasenack> it really depends what tooling the developer used, we need to remain compatible with people who prefer debdiffs and plain dputs
<TJ-> right. hmmmph! makes it really challenging to discover where a regression lives
<TJ-> right now seems like 19.04 grub2 has regressed and broken GRUB_ENABLE_CRYPTODISK so was hoping to quickly parse the recent commits in search of candidates
<TJ-> cyphermox: maybe you could cast your eye over Bug #1813126
<ubottu> bug 1813126 in grub2 (Ubuntu) "[19.04] GRUB_ENABLE_CRYPTODISK=y ignored" [Undecided,Confirmed] https://launchpad.net/bugs/1813126
<cyphermox> TJ-: right now I don't have time to look at that; but I suspect it will have something to do with the change in LUKS format
<cyphermox> you might want to have a look at what 'sudo grub-probe --device /dev/mapper/<your crypto device> --target=abstraction' reports, but I think it won't be a regression so much as something that has never been supported yet
<cyphermox> (though I am, admittedly, just guessing)
<cyphermox> TJ-: if you want to have a look on your own before I can get to this though; you'll want to look at https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/log/?h=ubuntu
<cyphermox> it's a git-dpm tree, that means it's a fairly straightforward tree where one can relatively easily do bisection against the package or against the patched (or unpatched) tree ('git-dpm checkout-patched' will get you a patched tree, and if you rebase you can get to just before any patches are applied)
<TJ-> cyphermox: thanks, that's perfect
<TJ-> cyphermox: you nailed it; LUKS2 in my test case, despite I used "cryptsetup luksFormat --type luks ..." hmmph
<TJ-> cyphermox: aha, cryptsetup semantics have changed since 18.04, 19.04 --type=luks == luks2, need to use --type=luks1
<vorlon> infinity, stgraber, kees, mdeslaur: TB in 7?
<mdeslaur> ack
<xnox> vorlon:  kenvandine: rcj: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1831675
<ubottu> Launchpad bug 1831675 in livecd-rootfs (Ubuntu Bionic) "core18 snap missing from bionic desktop, snaps fail to seed offline" [Undecided,New]
<vorlon> xnox: is this a daily desktop image you're talking about?
#ubuntu-devel 2019-06-05
<xnox> vorlon:  yes.
<xnox> vorlon:  bionic daily; eoan is fine.
<vorlon> so we just need to sru back the snap base handling
<xnox> vorlon:  well.... bionic snap seeding in desktop is kind of by-hand; whilst eoan uses ./snap-tool and is nicer.
<xnox> vorlon:  i don't know what is the plan with backporting ./snap-tool to bionic.....
<akik> what's ubuntu's policy on using NOPASSWD in sudoers? i'm asking because cloud-init is still doing it for the default user and cloud-init is originally a ubuntu project
<cjwatson> I'm not sure there's a policy on it.  cloud-init probably does so because there's no point in requiring a password in environments where users typically don't have a password set at all.
<cjwatson> (For cloud guests the default user usually only authenticates using an SSH key)
<akik> i mean it lessens security if there's a user account on the system that can get root access without password
<akik> and there's not warning about it
<cjwatson> You should ask the cloud-init people specifically
<akik> they didn't see any problem with it
<cjwatson> You aren't going to get anywhere looking for a policy stick to hit them with
<cjwatson> IMO anyway
<akik> i don't want to hit anybody, just want to make systems safer
<akik> :)
<cjwatson> ("policy isn't a stick to hit people with" is an old catchphrase in the Debian policy-authorship community)
<cjwatson> You could also discuss it with the Ubuntu security team I suppose.  No guarantee they'll agree with you of course
<odc> akik: that's pretty much how it works on all "cloud" distros. It's a sane default. You can modify it if you want, but using passwords is very impractical on a large scale.
<akik> odc: no it's not a sane default
<maswan> I think it is a sane default
<akik> cloud-init creates a default sudo NOPASSWD: user with no warning
<maswan> yes, which is exactly what I'd expect, managing passwords is hardly something you want to deal with by default
<odc> akik: in typical cloud deployments, we do not make a distinction between users and administrators. If someone has the ssh key to connect on a machine, then they can do anything they want. It has been like that for many years now.
<akik> that's no excuse for keeping it that way
<odc> well what would you do?
<akik> security > convenience
<akik> remove the NOPASSWD: from the sudo config
<odc> and? what would be the password?
<akik> whatever you set it as
<akik> i'm not concerned about that
<odc> and where was the password defined? in cloud-init? in clear-text?
<akik> i'm not talking about getting rid of the ssh pki setup
<maswan> just hardcode the password to "ubuntu"?
<akik> just removing the default NOPASSWD: sudo config
<akik> well now you're just being silly
<odc> akik: you're just used to the old model. If you don't want someone to be root, just don't let him login to the machine at all. If you want to make sure an application cannot have root rights, run it in a container. That's pretty much ho it works now.
<akik> it's not about "the old model". it's about obeying the normal system security practices
<akik> ubuntu desktop doesn't do that, why should cloud-init do it?
<akik> i'm sure if i suggested adding it to ubuntu desktop, it would be rejected
<odc> because that's what people expect. Servers and desktop are managed in a different way. You don't do passwords when you manage hundreds or thousands of machines
<odc> unless your server will be used by people you don't trust
<akik> i'm sure you don't login to the shell with ssh if you "manage hundreds or thousands of machines"
<akik> or you're doing it wrong then
<odc> no, but ansible does
<odc> also for debugging :(
<odc> but i agree that immutable deployments are usually the best ^^
<sladen> xnox: was there some intermediate discussion that was missed?
<xnox> sladen:  no. it's been discussed for a while on-and-off for 1 year plus.
<xnox> sladen:  do you have some concerns? literarly all of our installer are dog slow to boot, compared with installed systems and it's bad.
<xnox> sladen:  i guess some flavours may be concerned about size. but we are talking about 11M difference in the age of booting of USB sticks, as nobody has floppies anymore.
<xnox> sladen:  and it pisses me off that a faster create & boot exists, and we are not using it =)
<sladen> xnox: if I understand correctly, there's only a single metric (1:+1.14 space gzip:LZ4) LZ4 14% larger than gzip?
<sladen> xnox: decompression should be +/- the same.
<sladen> xnox: if not, there's something sub-optimal in the I/O stage.  Like flushing/read size/blocking
<sladen> xnox: ie. using a different, but near identical hammer, doesn't help if it's a screw, not a nail
<TJ-> who's responsible for  manpages.ubuntu.com ?
<xnox> sladen:  lz4 decompression with lz4 is 4x faster than gzip
<xnox> sladen:  lz4 compression is 20% faster than gzip
<xnox> sladen:  so update-initramfs -u speed inprovement is noticable, and speed boot is blazing fast.
<xnox> sladen:  decompression speed is not +/- the same.
<xnox> it's like 1.6s vs 0.1s
<xnox> sladen:  the larger than gzip, is the only downside, with upsides in compression/decompression time
<juliank> heh, launchpad lost another upload yesterday
<juliank> I uploaded lvm2 for xenial and newer, and the bionic upload was never accepted into unapproved; but re-uploading it worked fine
<juliank> :)
<sladen> xnox: don't think the +/-20% is much to care about.   gzip/zlib and LZ4 use the same tech which is string matching.  Only real difference is that gzip has a Huffman coder on the front to squeeze the bits) ... which is where the extra 15% size reduction comes from, at the cost of doing bit shuffling to unpack those variable length symbols
<sladen> xnox: however, the difference between 1.6s and 0.1s is *so* dramatic (for the same tech) that something /else/ is likely broken
<sladen> xnox: (it should be the case that a 14% I/O saving is easily wiped out by the processing)
<sladen> xnox: so, by all means go ahead; but the solution still appears to be trying alternative hammer, rather than understanding the problem
<ogra> xnox, please take also into account that on Core the initrd is created off-device (being readonly at runtime), there the smallest size (uboot loading and moving the file in ram can be very slow with bigger initrd's) and decompression time are indeed more essential ...
<sladen> xnox: with chunking + parallelisation (decoding while streaming), the overall time *should* trend to the time for the pure read() from the block-device.  Which *should* mean that a 15% I/O saving results in a 14% start->finish timing
<sladen> xnox: with further optimisations to order the CPIO, and returns files/chunks as soon-as-ready, it should be possible to get a boot time /faster/ than the pure decompression speed (because unused data is never even uncompressed!)
<xnox> sladen:  re:cpio ordering => i was pondering about that. But i'm not sure what the right order is, or if it matters. How do we get the file-listing of the full initrd? and stream things? or is it just a matter of putting init first?
<xnox> sladen:  i don't believe kernel can do chunking and parallelisation for decoding while streaming for the initrd. but i might be wrong.
<xnox> sladen:  ie. for lz4 we must use '-l' legacy format.
<xnox> sladen:  also, for the public cloud workloads we do want to trade size & IO for cpu time. Typically clouds have fast ssd/nvme storage, but overcommitted cpu. Thus 14% larger size, and 400% faster decompress is a win there, unlike bare metal.
<sladen> xnox: yeah, latter is complete opposite of ogra's boot-off-serial-EEPROM example :-)
<ogra> well, more SD/eMMC ... :)
<sladen> xnox: chunking/parallelisation code would likely need writing.  It might be possible to do that as a pure userspace ... minimum initramfs.cpio that unpacks an initramfs2.cpio
<ogra> actual flash got rare nowadays ... to expensive
<sladen> xnox: think the conclusion is that for /many/ use cases (perhaps even quite a lot), it's a cheap win (time taken to change a flag)
<sladen> xnox: and that with specific, clearly defined use-cases; and spending 3 months testing+writing code where required, pretty much anything is optimisable/betterable.  Probably by quite large percentages
<rbasak> TJ-: the best general answer is to use the Vcs-* fields from debian/control. That tells you what the maintainer considers to be the normative VCS source.
<rbasak> TJ-: however that field isn't currently maintained well in the case of Ubuntu packages that have deltas against Debian, unfortunately.
<xnox> sladen:  looking forward, we may be booting initrd-less in many cases. But then the question will come down to as to what i/o speed we get at the boot-protocol vs bootloader support - ie can grub/uboot/aboot/etc. boot lz4 compressed kernel image. and that is actually probably more interesting than initrd.
<rbasak> Usually though if an Ubuntu delta exists and Vcs-* seems to point to Debian, that means that Ubuntu developers aren't maintaining the delta in a VCS.
<xnox> sladen:  i hope you do agree that using lzma makes no sense at all in the cloud or bare-metal installers.
<TJ-> rbasak: what's that in relation to? I'm confused?
<xnox> sladen:  and it is a massive step up to use either gzip or lz4 for those.
<sladen> xnox: LZMA is nuts for all use cases except one-time compress and TFTP/serial/EEPROM booting were I/O is the bottleneck
<rbasak> 17:35 <TJ-> is there some voodoo to understanding where to find the actual, meaningful, git commit logs for package git repos?
<rbasak> From above
<TJ-> rbasak: oh! blimey, wasn't that yesterday? I thought you were on about manpages.ubuntu.com :D
<rbasak> Essentially what I'm saying is that the git-ubuntu imports are guaranteed to reflect publication history in apt, and not necessarily what the developers of those packages actually use (Vcs-* is for that)
<TJ-> rbasak: right; now I've got the context it makes sense :)
<TJ-> rbasak: fortunately I didn't need to deep-dive the source after-all, turned out to be a simple LUKSv2 instead of LUKSv1 confused poor GRUB :)
<sladen> xnox: gah.  Forgot the actual reason for LZMA.  It was CD-ROM booting
<sladen> xnox: it was deployed for the Live-CD were CD-ROM I/O to boot was the overriding bottleneck
<xnox> sladen:  also size, we had to fit on 700MB and lzma gave us half the size than gzip
<Laney> xnox: can you recommend a python binding to systemd that's in the archive and lets me list / enable / disable / start / stop units?
<Laney> python3-systemd looks quite limited
<Laney> or should I talk dbus?
<xnox> Laney:  and you want it for the user or system units?
<gamester> Is ubuntu dev not receiving regular gnome updates? Is it just sitting on gnome 3.32?
<Laney> xnox: system
<Laney> gamester: it will do, we usually pick it up a bit later on
<xnox> Laney:  so list / start / stop / restart is doable over dbus.
<Laney> xnox: yeah I know, just wondering if there are some handy bindings
<Laney> I found 'psystemd' which looks nice but doesn't seem to be packaged
<xnox> Laney:  oh, and on the manager there is now EnableUnitFiles DisableUnitFiles MaskUnitFiles UnmaskUnitFiles nice. it wasn't used to be there.
<xnox> Laney:  maybe check what snapd uses...
<ogra> dh_systemd ?
<xnox> Laney:  but also curious what you doing .
<Laney> xnox: autopkgtest-cloud charm in python
 * Laney eyes ogra with suspicion
 * ogra grins
 * xnox will start using snapd out of context, to get out of context responses from ogra from now
<xnox> on
<xnox> =))))))
<Laney> xnox: need to enable the right number of template instances per the config
<ogra> \o/
<xnox> Laney:  arghuhghh
<Laney> I'm trying to move all of the things that admins do by SSHing into the machine out into the charm
<Laney> probably will end up at 'most' rather than 'all' though
<Laney> https://paste.ubuntu.com/p/6RWj9j8wdT/
<Laney> not too hard
<ahasenack> question, when I override dh_gencontrol, for the purpose of using a substvars file, when I call dh_gencontrol at the end, do I need to pass $@ or something like to it, preserving whatever command line arguments debhelper was going to give it?
<ahasenack> ilike https://pastebin.ubuntu.com/p/TKC5t9CnRh/
<ahasenack> or just dh_gencontrol?
<vorlon> ahasenack: just dh_gencontrol is sufficient, dh puts all the relevant information in environment vars so you don't have to repeat
<ahasenack> vorlon: thanks
<infinity> ahasenack: Also, $@ probably isn't what you think it is.  It would call "dh_gencontrol override_dh_gencontrol".
<ahasenack> heh, quite the loop
<ahasenack> but somehow it avoided it, when I tested
<infinity> Not a loop.  Just a nonsensical argument to dh_gencontrol
<infinity> $@ being a variable that substitutes in the current target.
<ahasenack> I see
<ahasenack> snapd's d/rules is sourcing /etc/os-release to check the ubuntu release the package is being build on, is that ok/stable?
<ahasenack> specifically
<ahasenack> "include /etc/os-release"
<ahasenack> and then it decides on VERSION_ID
<ahasenack> which seems to not change with point releases, i.e., trusty is 14.04.6, and VERSION_ID is 14.04 still
<infinity> It's no worse than people build-depending on lsb-release and calling that, which is pretty common.
<infinity> It's not meant to change with point release.
<ahasenack> yeah, that is what I was reviewing, and I recently saw a debian package changing to os-release to avoid the build-dep on lsb-release
<infinity> And why would knowing which point release you're building on be useful?
<ahasenack> we need a certain libapt-pkg<abi> minimum version, and the automatic dependency via shlibs doesn't catch the specific version that has a bugfix we need
<infinity> Point releases aren't a real thing anyway.  It's just a snapshot in time of the parent release.
<infinity> Uhh, wat?
<infinity> If you need a minimum version of a build-dep, you have a versioned build-dep.
<infinity> Not a hack in rules.
<ahasenack> I'm using substvars in rules to construct the depends (not build-dep)
<ahasenack> https://github.com/CanonicalLtd/ubuntu-advantage-client/issues/520#issuecomment-498417459
<infinity> Okay.  Still not following how you'd need to care about the point release version.
<ahasenack> I don't, I wanted to be sure VERSION_ID wouldn't incorporate the point release number, and break my series if ifeq
<ahasenack> of* ifeq
<infinity> Versioned build-dep on the version you want, versioned dep on the version you want.  Don't really even need substvars there, unless you're trying really hard to build the same source on all releases.
<ahasenack> I would check for 14.04, for example, not 14.04.N
<ahasenack> the latter
<ahasenack> same source on all releases
<infinity> A fun goal, but don't be married to it either.  Things get messy in a hurry sometimes. :)
<ahasenack> and this is the first time we have such a variable dependency
 * infinity glances at all the m4 in gcc's rules.
<ahasenack> yeah, keeping an eye on it, very carefully
<ahasenack> python differences are annoying enough already between trusty and something more modern
<infinity> And okay, if you wanted to make sure it WON'T incorporate the point release, as the man who updates that, I can assure you that it won't. ;)
<infinity> It did once when someone else did it for me, and I fixed it in a hurry. :P
<ahasenack> heh
<ahasenack> infinity: and is /etc/os-release ok to source, or does it have to be parsed like /etc/lsb-release?
<ahasenack> specifically, use "include /etc/os-release" in d/rules, like I've seen snapd do
<infinity> https://www.freedesktop.org/software/systemd/man/os-release.html
<ahasenack> aha, even better
<infinity> ahasenack: The "spec" claims it should be okay to source.
<infinity> ahasenack: And since I don't see any reason why we'd deviate from said spec, I think you're good to go.
<ahasenack> thx
<infinity> Hrm.
 * infinity notes the addition of VARIANT and VARIANT_ID to the spec.
<infinity> Which are completely useless without a .d mechanism.
<infinity> Cause I'm not letting every flavour overwrite os-release.
<infinity> Oh well.
<infinity> It was almost useful.  Well job, systemd people.
#ubuntu-devel 2019-06-06
<Wimpress> xnox: Do you have a few minutes to help me understand what my expectation for blacklisting package in seeds should be?
<Wimpress> The context is this.
<Wimpress> I would like to seed gnome-mpv. It has a Recommends: youtube-dl
<Wimpress> youtube-dl has deep requirements that end up in libqt5* getting pulled in.
<Wimpress> Is blacklisting a means by which I can prevent youtube-dl from getting on the Ubuntu MATE iso image?
<cjwatson> I can answer that: no.  Blacklisting in seeds doesn't affect what apt does
<cjwatson> See "man germinate" where I discuss this a bit
<cjwatson> "The purpose of a blacklist is to make it obvious when a package that is not supposed to be installed ends up in germinate's output, so that package relationships can be fixed to stop that happening.  It is not intended for the purpose of working around buggy package relationships, and attempts to do so will not work because apt has no way to know about blacklist entries in seeds."
<cjwatson> To avoid that Recommends taking effect, you would need to put gnome-mpv in a seed that has the follow-recommends feature disabled, *and* you would need to ensure that anything that installs the corresponding task/metapackage/whatever does so in a way that tells apt not to follow recommends
<cjwatson> The latter requirement is impractical in most cases, so this entire approach is IMO probably impractical
<cjwatson> The only way to do this kind of thing is usually to adjust the package relationships themselves
<Wimpress> cjwatson: That is a brilliant suggestion about using an alternate seed!
<Wimpress> Thank you :-)
<Wimpress> Oh, I do want to follow-recommends in the desktop seed however.
<Wimpress> So, as you say, probably not a solution.
<cjwatson> Right, people have tried this in the past and it has nearly always turned out to be painful or unworkable in practice.
<Wimpress> I have talked to the Debian package maintainer. They are not interested in change the youtube-dl Recommends: to a Suggests:
<cjwatson> I wonder if changing youtube-dl's recommendation of mpv | mplayer to also include gnome-mpv would help?
<Wimpress> Is the the phantomjs Depends that is the issue.
<Wimpress> It has requirements for libqt5*
<cjwatson> Installing mpv on its own also pulls in libqt5*
<Wimpress> Yes
<cjwatson> So it may be both
<Unit193> The problem lies mostly in apt, as it would be pretty simple (though overkill in most cases) to create another seed in the structure for not following recommends.  His problem mostly likes in phantomjs, I'd imagine.
<Wimpress> Because youtube-dl is a Recommends of mpv also.
<cjwatson> Oh right
<cjwatson> Can youtube-dl's Recommends on phantomjs be reduced to a Suggests?  (I don't know this package at all)
<Wimpress> cjwatson: From the research I did, no.
<cjwatson> Unit193: Fairly simple in seed terms but in practice prohibitively complex in the rest of the system, indeed.
<Wimpress> It will break the ability for youtube-dl to work with many of the sites it supports.
<cjwatson> Sounds like you may be out of luck ...
<Wimpress> Yes, sadly I think you are right.
<Unit193> Based on how quickly youtube-dl has releases, we should not create a long-term delta.  As far as how youtube-dl is useful without that?  I use it all the time and do not have phantomjs.
<Wimpress> youtube-dl is not a hard requirement for gnome-mpv, which is why I was hoping it could be changed to Suggests.
<Wimpress> But the maintainers don't want to introduce inconsistent behaviour between mpv and gnome-mpv.
<cjwatson> Maybe both mpv and gnome-mpv could be changed then?
<Unit193> So: out of the 1K+ sites, it looks like only one or two uses phantomjs, that looks just fine to move it to suggests.
<Wimpress> Interesting.
<Wimpress> So, perhaps I change tack a discuss changing phantomjs to a Suggest in youtube-dl with its maintainer.
<Unit193> Note: That's only a quick grep of `grep -Ri phantom` and checking to see if that looks right.
<Wimpress> Upstream youtube-dl are considering using chromium-headless instead of phantomjs.
<Unit193> In fact, I would appreciate the drop of phantom to suggests too. :P
<ahasenack> hi, I found an old piece of delta in an ubuntu package (backuppc, https://pastebin.ubuntu.com/p/cGNsW7BqJs/), which says it's implementing this old spec: https://wiki.ubuntu.com/Teardown
<ahasenack> does this still apply in our systemd world?
<ahasenack> there is no systemd service file provided in this package
<alkisg> xnox: hi, I just read https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html "In all other places, our performance profile is in favor of lz4."
<alkisg> ...and I wanted to add "netbooting" into consideration; loading a kernel/initrd via tftp might need 10 secs; so lz4 would add 1.4 secs to boot time; dunno if it would save some from the decompression time
<alkisg> I'm not saying it's important, I just thought to mention that loading the kernel/image via tftp (instead of disk) is one of the affected use cases...
<xnox> alkisg:  tftp, not http?
<xnox> *sigh*
 * xnox should start making public notes about thigns people told me.
<alkisg> xnox: yes normally in netbooting tftp is used; some people can "afford" a web server and use both tftp for ipxe and http for kernel/initrd
<alkisg> Sorry I wasn't on that list, to properly reply, and I thought "better do a quick ping, even if it gets lost, than be silent". /me shrugs
<xnox> alkisg:  this is fine, and very welcomed.
<alkisg> ty :)
<tmhoang> how does Ubuntu detect available tty ? In terms of code.
<xnox> tmhoang:  we run systemd generators for gettys and serial consoles.
<tmhoang> xnox: thanks, so systemd takes care of discovery
<tmhoang> I think this thing happens somewhere during initramfs phase. Checking ...
<xnox> tmhoang:  initramfs is different....
<xnox> tmhoang:  we read console= arg and magic
<xnox> tmhoang:  d-i is different again
<xnox> tmhoang:  core is different too... but only slightly.
<tmhoang> xnox: well systemd is your /init. if tty discovery happens in system, it happens in initramfs, correct ?
<xnox> tmhoang:  no......
<xnox> tmhoang:  we don't use systemd in the initramfs, we use a different init there, and later exec systemd to replace pid1 with it......
<tmhoang> hah interesting
<xnox> tmhoang:  and systemd does rediscovery again and can setup more consoles. E.g. initramfs may, or may not load/use serial consoles, but systemd will generate units for them.
<tmhoang> understood. I just assumed systemd is /init. cool
<kyrofa> Hey, anyone around who knows more than I do about mokmanager?
#ubuntu-devel 2019-06-07
<vorlon> kyrofa: regrettably yes
<vorlon> kyrofa: but afk for a bit, so I'll reply async if you ask a followup question :)
<sarnold> pity it wasn't pre-followed-up :)
<TJ-> can someone remind how dput > launchpad PPA does auth? I have it working here but its been so long since I configured it I'm struggling to figure out where the client gets the auth? is 'sftp' method using the SSH local id_rsa ?
<tyhicks> TJ-: that's correct
<TJ-> tyhicks: thanks; can't find that spelled out anywhere on the LP Help PPA pages :)
<TJ-> tyhicks: needing to move the config/keys to another system and didn't know what is needed
<infinity> TJ-: Although, the only reasons to use the sftp method are either Very Broken Networks, or because you're uploading Very Private Bits.
<infinity> (or cause you're weird and like things to be slow, I guess)
<sarnold> I never found ftp package uploads to be all that quick :)
<TJ-> infinity: I'm just moving a config that I've had for years
<kyrofa> vorlon, just installed 18.04 on a new XPS 13, checking the "please install updates" box. It surprised me by asking for a password, but nicely explained that it was because I had secure boot enabled and it would be required on the next boot to ensure components were authorized. Sure enough, mokmanager showed up on the next boot, but it was entire unclear what I was supposed to do. There were a few options, the first being "boot now" and the
<kyrofa> second being something like "enroll a key". The others looked less valid. I wasn't interested in enrolling a key, so I said "boot now" and no password was prompted. I later found https://wiki.ubuntu.com/UEFI/SecureBoot which implies that I should have enrolled a key
<kyrofa> I don't seem to be missing functionality, but now it's nagging at me. Rod filled me in on how it works, but he wasn't sure how the installer was getting the key into mokmanager so he wasn't sure if it was recoverable
<kyrofa> The way the installer made it sound, I was just expecting a simple "Hey yo, you installed new stuff, enter the password you used" and I'd be off to the races. Is there a reason it needs to be more complicated than that?
<infinity> kyrofa: The reason it needs to be more complicated is because userspace can't write to your firmware's key databases, all it can do it queue up a request to enroll a key and let mokmanager DTRT on reboot.
<infinity> kyrofa: There's no reason, however, for it to be as confusing as it is, except that mokmanager's UX was designed by someone who lives in 1972, apparently.
<plongshot> I don't want to ask this in the main channel cause it's somewhat sensitive. I accidentally pastbinned a file that contains some perosonal info I dont' want out.  Address, phone number, etc.   Is there any way to remove a pastbinit once it's been created?
<plongshot> Is this information still relevant? https://askubuntu.com/a/406279
<plongshot> I've gone ahead and changed the ip of the compromised mahcine and reconfigured. I would still like to see if I can get that paste deleted. Thanks
<tenplus1> hi folks
<tenplus1> anyone know why libleveldb1v5 was removed from repos ???
<sladen> https://packages.ubuntu.com/search?keywords=libleveldb1v5  https://packages.debian.org/search?keywords=libleveldb1v5
<sladen> tenplus1: what version of Ubuntu?
<tenplus1> soryr, am on 19.10 and wondering why it was missing... couldn't install something
<tenplus1> I had to download it from an earlier release to get things working... just found it weird...  (was installing Minetest 5.0.1, repo is outdated with 0.4.16)
<sladen> https://flossexperiences.wordpress.com/2018/04/19/getting-libleveldb1v5-fixed/  ->  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877773
<ubottu> Debian bug 877773 in src:leveldb "libleveldb1v5: breaks ABI without SONAME bump" [Grave,Fixed]
<tenplus1> fixed by removal, ouch!
<sladen> 19.10 is not out yet.  https://launchpad.net/ubuntu/disco/+package/libleveldb1v5  it is in 19.04
<tenplus1> true, am testing it out for now... was hoping someone in here would have an answer :P
<tenplus1> thanks for the help :P
<cjwatson> The newest version of the source package builds libleveldb1d instead, and packages that depend on it should migrate
<cjwatson> Not fixed by removal, fixed by rename
<ahasenack> is it ok to use this style of globbing in postrm to remove the logs when purging the package? rm -f /var/log/foo.log*
<ahasenack> I expect it to purge foo.log, foo.log.1, foo.log.2.gz, etc
<ahasenack> or even just foo.log.2, if the admin changed the config to not gzip
<ahasenack> but I wonder if someone would ever save backups there like /var/log/foo.1.bak and expect them to remain
<vorlon> I'm not sure there's a strong precedent one way or the other
<ahasenack> I checked some packages, heimdal-kdc does that. Many others have their own log directory, but also just remove everything
<ahasenack> I'll do it this way for now
<juliank> ahasenack: certainly sounds ok to me
<ahasenack> cool
#ubuntu-devel 2019-06-08
<TJ-> Is there a packaging guide for NEW packages that a) have an upstream repository-only publishing scheme (no tarballs),  b) doesn't assume upstream does tagged releases (got to pick HEAD at a point in time), and c) using git tooling (not bzr). I've looked at Ubu Packaging Guide which assumes tarball or bzr, and the Debian guide that assume tarballs
<TJ-> What I need is an example, or confirmation, that it is OK to start from an already git clone X working directory)
<TJ-> Or whether the debian/rules needs to do a source git clone operation itself
<valorie> TJ-: acheronuk could give you some good tips
<acheronuk> TJ- valorie all I can mostly do is point at http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html#gbp.import.upstream.git.notarball
<TJ-> valorie: I thnk I've almost got there but still struggling with precise instructions. Been trying to use gbp-buildpackage but I think that's the wrong one
<TJ-> I've got an sbuild env set up but struggling to figure out how to generate the orig.tar source package from the git; gbp-buildpackage --git-pristine-tar also seems to want to build the binaries, which is not what I want
<TJ-> acheronuk: Yes, been reading that but seems to miss out things that for regular Debian devs are obvious :)
<TJ-> hmmm, found somewhere else that recommends "git archive master | gzip > ../${package}_${version}.tar.gz"
<valorie> well, I've built stuff from source, but never packaged
<valorie> although I think I could manage to make a tarball
<valorie> perhaps
<TJ-> it's a very confusing mess of changing processes tools and methods unfortunately. 10 years ago I found it easy, now I get lost just trying to figure out which instructions are the correct ones!
<acheronuk> the trick is reliably automating that with packaging and tags
<TJ-> I'd settle for just having the Ubuntu docs kept current; so much is about bzr or working with tarballs
<TJ-> e.g the Getting Set Up page still tells us to install pbuilder
<acheronuk> TJ-: kubuntu's old tooling used to use: https://paste.ubuntu.com/p/PskbkKKdGQ/
<TJ-> acheronuk: did that default to using sbuild?
<TJ-> hmm, am I correct setting source/format to "3.0 (git)" if upstream + packaging is all using git ?
<acheronuk> that just built the source package for upload. no sbuild
<TJ-> oh?is the final -S being passed to dpkg-buildpackage then?
<TJ-> I didn't spot that initially
<TJ-> looks like I may have gbp buildpackage working; now I've got to solve why there are loads of mounts inder  /run/schroot/mount and the build now runs out of memory!
<TJ-> hmm, that needed "schroot --all-sessions --end-session" to close them all
#ubuntu-devel 2019-06-09
<TJ-> When using sbuild, and a package with source/format "3.0 (git)" do we have to manually add 'git' as a Build-Depends ?
<alkisg> cyphermox: hi, while developing ltsp-next, I noticed that in 19.04 initramfs, ./etc/dhcp/dhclient-enter-hooks.d/config writes:
<alkisg> echo "IPV4DNS0=$new_domain_name_servers" >> /run/net-$interface.conf
<alkisg> I.e. all DNS servers (in my case 3) in IPV4DNS0; this makes netplan show some errors
<alkisg> Sorry for not filing a bug report as it's a little complicated where the issue is (dhclient or netplan) and I'm not using netplan; just thought I'd ping here even if it's lost
<cjwatson> TJ-: I really wouldn't use source format 3.0 (git).  It was experimental and never got much adoption
<cjwatson> TJ-: Pretty much everyone is using 3.0 (quilt) for your sort of use case, often with the quilt patches actually being automatically generated from git commits (using gbp pq or git-dpm or possibly others)
<TJ-> cjwatson: hmmm, can you tell me what I should use for working from pure git from upstream? When it was set to quilt I was getting failures due to missing tarball, and couldn't figure out the correct process to create it!
<cjwatson> I just did :)
<cjwatson> Oh, missing tarball
<TJ-> cjwatson: but the debian/ directory isn't done with that, and I've made no changes to the upstream, I'm just trying to get the initial package correct!
<cjwatson> Do upstream not make releases?
<TJ-> cjwatson: no, and no tags in git either
<cjwatson> Well then you do need to produce one, but that's not really a Debian question
<cjwatson> No make dist or equivalent?
<TJ-> cjwatson: its network-manager-wireguard https://github.com/max-moser/network-manager-wireguard
<cjwatson> I am not going to look
<cjwatson> Other things to do
<TJ-> cjwatson: from what I can tell he copied the build system from network-manager-openvpn
<cjwatson> I know nothing of the specifics
<cjwatson> You basically just want a tarball that has say network-manager-wireguard/ at the top level
<TJ-> I can't find any docs on how to deal with this when there is no upstream release/tarbal/tags
<cjwatson> Exact naming doesn't really matter
<cjwatson> You could try git archive
<TJ-> right, actually, I did use that (!!) last night but that a long time after I'd switched from quilt to git... maybe I should switch back!
<cjwatson> But is it an autoconfy upstream?  It probably has a perfectly good make dist if so
<cjwatson> Anyway, as long as it's a tarball that pretty much unpacks to what you get from git, it should do
<cjwatson> (except for the .git itself)
<TJ-> My main problem though as been the debhelper autoreconf invocation is NOT calling intltoolize and as result (in sbuild) config.status rails due to missing po/Makefile.in.in - intltool is a build-dep and I've been into the schroot chroot and checked the intltoolize is there
<TJ-> Yes, it has an autogen.sh, and configure.ac
<cjwatson> If there's an autogen.sh then you should tell dh_autoreconf to run that
<cjwatson> dh_autoreconf -- ./autogen.sh
<cjwatson> In an override_dh_autoreconf rule
<TJ-> If I build locally, calling ./autogen.sh it's fine (because that specifically calls intltoolize ) but couldn't figure out why dh_autoreconf wasn't doing likewise, from its man-page it implied it would do that for me :)
<TJ-> ahhhh, specific call?
<TJ-> thanks
<cjwatson> man dh_autoreconf says no such thing
<cjwatson> It says that it calls autoreconf -f -i
<cjwatson> Which is not necessarily the same thing as a custom autogen.sh if a package has one of those
<TJ-> it does
<cjwatson> See the bit under OPTIONS starting with "program -- params"
<cjwatson> grub2 uses "dh_autoreconf -- ./autogen.sh" in its debian/rules because the autogen.sh is a specialised custom thing
<TJ-> it says "export LIBTOOLIZE = true" - I thought that would include the intltoolize :)
<cjwatson> Er no
<cjwatson> Not even a little bit
<TJ-> cjwatson: OK, now it makes sense !
<TJ-> let me try your override command, there is already one in place but not with that on it
<cjwatson> autoreconf(1) doesn't have any integration for intltoolize
<cjwatson> So no simple environment variable setting will do what you're looking for
<TJ-> cjwatson: thanks, it's been a weekend of confusion heaped on confusion so far
<cjwatson> (Also, slightly confusingly, "export LIBTOOLIZE = true" actually means "run 'true' instead of 'libtoolize'", i.e. *disable* libtoolize)
<TJ-> cjwatson: yeah, I got that nuance
<TJ-> I was surprise it wasn't 'false' :)
<cjwatson> I imagine that would cause autoreconf to run false and then bail out because its exit code is non-zero
<TJ-> I thought likewise ... return codes do turn binary/bool results on their head :)
<cjwatson> Lots of ways to fail, only one way to succeed
<cjwatson> is perhaps an easy way to remember it
<TJ-> indeed, and I've failed in every way possible this weekend!
<TJ-> In my shell scripts I do a lot of if $VAR; then ... and setting VAR to /bin/true or /bin/false
<cjwatson> Sure, I use that sort of idiom as well
<cjwatson> (Though I omit the path prefix)
<TJ-> cjwatson: I don't trust myself not to have at some time created a true or false somewhere else in the PATH :P
<TJ-> well, it sees the change in debian/rules :D " checking build system type... Invalid configuration `./autogen.sh': machine `./autogen.sh' not recognized"
<cjwatson> What exactly did you type in debian/rules?
<cjwatson> Oh, blah, sorry, I meant dh_autoreconf ./autogen.sh
<cjwatson> Drop the --
<cjwatson> I was confused by an unrelated thing in grub2's code
<TJ-> aha! thanks, I dropped into the chroot and noticed in config.log "$ ./configure --enable-maintainer-mode ./autogen.sh"
<TJ-> cjwatson: thanks - I've got past the packaging errors now, on to the upstream problems :)
<cjwatson> Cool
<TJ-> sbuild on/for 18.04, getting a Lintian warning "appstream-metadata-in-legacy-location usr/share/appdata/..." -- but looking at "dpkg -S" seems like that is the place for appdata. Do I need to change this or figure out how to add a lintian override (I've seem people talk about those but never done one) ?
<TJ-> 20:06 <TJ-> grrr, asked in the wrong channel and only just realised!
<alkisg> TJ-: https://lintian.debian.org/tags/appstream-metadata-in-legacy-location.html
<alkisg> All lintian tags have excellent documentation
<TJ-> alkisg: thanks
<alkisg> np
#ubuntu-devel 2020-06-01
<waveform> ogra, no - they require a re-spin with an updated firmware if I recall correctly. Same goes for bionic (which requires an SRU of the firmware); 20.04 is only current release that works on the 8Gb
<ogra> waveform, well, meanwhile i just rolled my own gadget from the latest upstrream, works good enough for the moment ð
<ddstreet> Laney the systemd-upstream tests all seem to have stopped being run sometime this morning, do you know if something happened on our end?
<Laney> ddstreet: hmm, looking
<Laney> not seeing anything in the queue
<ddstreet> ack, thanks, maybe someone disabled it on the upstream side
<Laney> are they being triggered?
<Laney> eg https://github.com/systemd/systemd/pull/16031 doesn't have a request
<Laney> however it does separately look like bos02 is a bit sad for us...
<Laney> so, good that I looked
<ddstreet> Laney it looks like github is getting timeouts trying to submit systemd-upstream tests https://github.com/systemd/systemd/pull/16031#issuecomment-636858816
<ddstreet> could that be due to whatever is going on with bos02?
<Laney> ddstreet: that would be weird
<Laney> can you try using the retry script and see what happens for you?
<ddstreet> unfortunately i don't have access to the retry script, only the upstream systemd admins do AFAIK
<ddstreet> maybe xnox does
<Laney> hmm, you probably should
<Laney> I think you should get them to share the key with you
<ddstreet> yeah would probably be useful
<Laney> or access to press that redeliver button
<Laney> hmm
<ddstreet> yeah, i think that would require giving me systemd membership access
<Laney> something does look wonky, I can't run autopkgtest
<Laney> and that just connects to rabbitmq directly
<Laney> did rabbitmq die?
<Laney> that was unfortunate timing for an access point to die
<Laney> ddstreet: okay I restarted rabbitmq and it worked for me now
<Laney> :/
<ddstreet> thanks!
<xnox> ddstreet:  Laney: i'm getting timeouts trying to retrigger autopkgtests using the cgi script too
<xnox> (well, i did this morning)
<xnox> didn't try since the restart
<Laney> try now
<xnox> it worked =)
<xnox> tah
<zyga> popey, Wimpress: who is the best person to talk to about Ubuntu desktop on a Pi 4 with 8GB of ram?
<Wimpress> zyga: Probably me.
<ogra> zyga, the kernel team ð we dont have working drivers yet
<ogra> pi4 uses a new VC and only half of that is in our pi kernels yet
<ogra> zyga, https://bugs.launchpad.net/ubuntu/focal/+source/linux-raspi/+bug/1876862 and https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880125
<ubottu> Launchpad bug 1876862 in linux-raspi (Ubuntu Bionic) "Missing v3d driver disables 3D support on RPi4" [Undecided,Confirmed]
<ubottu> Launchpad bug 1880125 in linux-raspi (Ubuntu) "v3d driver clock problem forces OpenGL to use software rendering" [Undecided,Confirmed]
<zyga> ogra: interesting, thanks!
#ubuntu-devel 2020-06-02
<cpaelzer> sil2100: I see you are on +1 duty today as well - are we syncing on work items here or in any other channel (+1 , -release, ...)?
<sil2100> cpaelzer: I think there was some discussion to use -release for any coordination, if anything :)
<cpaelzer> ok, thanks sil2100
<xnox> @patchpilot in
<udevbot> Error: "patchpilot" is not a valid command.
<xnox> !patchpilot in
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: xnox
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<ogra> that was a short session
<xnox> ogra:  hahhahhahhahahhahahaha
<rbasak> bryce: FYI, https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/384974 is trivial and I'm going to "self-land" it once CI passes on the basis that it doesn't need a code review. If you object to this sort of thing in principle, please let me know.
<bryce> rbasak, ok
<cpaelzer> sil2100: I have updated the wiki with my ongoing items
<sil2100> cpaelzer: excellent! I had a few meetings now, but now I'm looking at pycryptodome - will be promoting the unsatisfiable dependency to main
<sil2100> cpaelzer: just hope us updating the wiki-page won't clash and we won't overwrite eachothers changes! This is this one thing I like in discourse more than the wiki
<coreycb> RAOF: bdmurray: hi, the openstack ussuri SRUs should be ready to release to focal-updates.
<cpaelzer> sil2100: yeah, I'm even pro-trello on this, but we can settle the "how and which tool" after we settled on which content shall be in mails vs some semi-static-page
<cpaelzer> OTOH I understand some people find trello noisy (so many thing on the screen - and I agree in some cases
<cpaelzer> we will see
<cpaelzer> sil2100: updates on the wiki (as long as that is what we use) have to be edit, change, save asap - not click edit in the morning and try to save in the evening
<cpaelzer> :-)
<bdmurray> coreycb: ack
<gpiccoli> Hi folks, do you know if Scott Remnant is here?
<gpiccoli> I don't know his nick
<sil2100> cpaelzer: exactly ;)
<cpaelzer> sil2100: if it turns out that the wiki is too mcuh pain on update-conflicts or getting outdated we can then think about alternatives
<gpiccoli> pitti, Hi Martin, I'm studying the eait-for-root code, I was looking to talk to original developers. I see Scott was the original devel, but you worked a lot on it, right?
<gpiccoli> I'm trying to understand what is the exact problem it was meant to solve...it seems to me, it's potentially "innocuous" now
<zyga> ogra: who's the best person to talk to about https://bugs.launchpad.net/ubuntu/focal/+source/linux-raspi/+bug/1876862 ?
<ubottu> Launchpad bug 1876862 in linux-raspi (Ubuntu Bionic) "Missing v3d driver disables 3D support on RPi4" [Undecided,Confirmed]
<ogra> zyga, RAOF
<zyga> RAOF: I'm interested in raspberry pi as a desktop system
<ogra> zyga, or well ... for the kernel side juergh
<ogra> zyga, it is already fixed in the tree i think
<zyga> in mainline?
<zyga> does it need backports?
<ogra> but i think the next kernel release is only scheduled for end of the month
<zyga> I wonder if there's anything I can do to help
<ogra> mainline ?
<ogra> we'Re talkng about rpi !
<ogra> in mainline it is probably ready in a few months ... who knows ð
<ogra> the tree at kernel.ubuntu.com has the moduke enabled ... but i doubt thats enough ... there are likely additional patches needed plus some dtb changes
<ogra> and such patches usually only live in the raspberrypi.org kernels ... typically it takes a while til they make it into mainline
<cjwatson> gpiccoli: Scott hasn't been around in Ubuntu for a long time
<ogra> zyga, waveform should have the broader overview though, he's "pi-dude" ð
<zyga> mmmm
<cjwatson> gpiccoli: Probably best to assume he wouldn't remember anything about it even if you did contact him :)
<gpiccoli> cjwatson, so I heard..but maybe he was here, in freenode
<zyga> waveform: is there anything I can do to help with the effort of making ubuntu a great desktop OS for pi 8GB?
<gpiccoli> But I agree hehe, maybe he doesn't remember anymore
<cjwatson> gpiccoli: (also, if you do contact him, IME he'll be quite irritated if you call him Scott Remnant rather than Scott James Remnant)
<gpiccoli> Oh, thanks for your hint, I wasn't aware of this!
<ogra> zyga, also ... the desktop team is likley looking into arm64 images eventually (i heard it mentioned during the vienna sprint a few times)
<juliank> but like proper arm64 uefi images, not rpi weirdness?
<waveform> juliank, no no no - not uefi :)
<waveform> (sorry, in meeting - will comment more in a bit)
<ogra> juliank, ahah wishful thinking
<juliank> ogra: Well I don't know, all I know about arm64 desktops is the WOS devices
<ogra> as londg as the DSP/GPU is your bootloader i doubt you'll see UEFI
<juliank> but sure it makes sense to pop out rpi4 ones too
<ogra> you *can* chainload u-boot from the GPU loader ... and then chainload grub and have UEFI on a pi though
<juliank> I meant that people were interested in playing with desktop on UEFI arm devices, and I thought we might want images for that
<ogra> but thats a lot of chainloading
<juliank> not that we'd want UEFI on rpi
<juliank> Arguably, desktop on rpi is probably more useful than desktop on uefi arm64 devices
<juliank> but it'd sure be nice to have that :)
<ogra> desktop on an 8GB pi4 is surely as powerful as one of my older laptops
<ogra> as long as you add a speedy USB 3.1 SSD
<ogra> (you really dont want to use the SD card for more than bootloader stuff on such a system)
<waveform> zyga, desktop on the pi is certainly of interest here - the biggest thing on my plate with regard to that is ditching uboot (which is what currently breaks ... so many things!)
<zyga> waveform: I see, so that we don't use intermediate bootloader?
<waveform> zyga, precisely - ideally we want to do the same as raspbian: gpu bootloader, kernel, optional initrd
<waveform> zyga, unfortunately that is more complex than it sounds (in particular with regard to ubuntu core) and is at least partly dependent on the goodwill of the pi foundation adding certain things to their bootloader (unpacking arm64 kernels and more importantly some mechanism to handle fallback for A/B booting)
<waveform> as it stands you can boot ubuntu armhf (*not* arm64) from an SSD without any SD card without much issue (the kernel cmdline and /etc/fstab were updated to use label-based partitions in eoan)
<waveform> but I've still got a ton of other stuff to add - current priority is camera module support, and the pi4 EEPROM utilities after that
<ogra> yeah
<ogra> the images are fine as they are for the moment really
<ogra> UEFI is a nice to have eventually but there is so much other pressing stuff forst
<ogra> *first
<zyga> waveform: do you think we could use somethnig like raspi-config tailored for ubuntu
<zyga> even with the same name but different backend?
<ogra> nah
<zyga> I'm really personally interested and would love to help
<ogra> we have something way cooler !!
<zyga> ogra: why? I think it has tremendous usage muscle memory
<ogra> made by waveform ð
<waveform> actually I wouldn't call it "more awesome" as "slightly broken" at the mo after I discovered an undocumented "feature" in the pi bootloader ... but I'll come back to that
<zyga> hehe
<zyga> ok
<zyga> waveform: my offer to help stands
<waveform> zyga, many thanks - let me see if I can dig out the post I made for this and see if it answers your query sufficiently
<waveform> zyga, here we go: https://waldorf.waveform.org.uk/2020/introducing-pibootctl.html
<zyga> waveform: more than queries, I'd liek to help with coding if you have something simple
<waveform> zyga, well - it's all open-source and the code's there for people to hack on but despite the code being relatively simple, the difficult bit is that you need to be *really* familiar with the fine details of the bootloader's configuration
<zyga> mmm
<waveform> zyga, by way of example (and this is what tripped me up last week); activating the camera module can be done with "start_x=1" in the config.txt (amongst a couple of other ways, but that's the common one)
<waveform> zyga, the bootloader also permits inclusion of files via, for example, "include syscfg.txt" - as we use in ubuntu
<zyga> yep
<zyga> I am familiar with it to a small degree
<waveform> zyga, but ... guess what ... start_x doesn't work in included files :)
<ogra> fun
<zyga> must be really reliable ;)
<waveform> now, if you know a bit about the bootloader mechanisms this actually makes sense; start_x=1 implies start_file and fixup_file getting set to start_x.elf and fixup_x.dat respectively
<waveform> that means it implies launching a *different* tertiary stage of the bootloader
<waveform> so, the parsing of that bit of config.txt is *not* done by start.elf (unlike all the rest); it's being done by bootcode.bin (or the EEPROM on the pi4)
<waveform> which almost certainly doesn't know about includes (or probably conditional sections though I haven't tested that yet)
<zyga> waveform: any chance to work closely with the foundation to at least document that bit better
<zyga> do you know why that part is not open source? is there some broadcom-likely-NDA or is there something deeper?
<waveform> zyga, it's partly that it's broadcom owned code but there's more complex bits. For instance, start_x.elf includes the camera firmware. That's largely based on threadx (a closed source RTOS) and includes things like a hardware-accelerated H264 encoder (under patent)
<zyga> that feels like firmware blob we could include if it was available as a blob
<zyga> I'm faimilar with threadx
<zyga> though I last used it really long time ago
<waveform> zyga, in other words, don't hold your breath on that being opened - I'm sure they'd like to but there's a whole pile of closed-source fun tied up in that .elf
<zyga> I think 90% of the benefit would be from being able to implement a better start.elf
<zyga> that's just loading the big blobs
<zyga> so that boot logic is less weird
<zyga> and can do things that people are using the PI for more than before
<ogra> well, you'D lose acceleration ... but you could surely revers engineer it
<zyga> ogra: why?
<ogra> not sure how useful a pi without graphics is though
<zyga> ogra: I didn't mean not to use the blobs
<waveform> anyway, at the moment I'm putting together a doc loosely titled "everything Dave knows about the pi bootloader but you were afraid to ask ... in case he started going on about it" - I'll stick it in as part of pibootctl's docs when it's done
<zyga> just to load them with different helper that is open
<ogra> because the GPU (well actually its a multi purpose DSP) is your bootloader
<zyga> ogra: that's great
<ogra> the boot process fires up the GPU first ... the GPU then starts the ARM
<zyga> I can keep that part even if not open, I think you misinterpreted my comments above
<ogra> this is wh you also dont really need a GPU driver ...
<ogra> it is already in RAM when the ARM starts
<zyga> my point was that a open source start.elf that contains blobs that are not open source (as today0 is better than what we have today
<waveform> zyga, that would be a wonderful step forward (if only so I could figure out logic like the inclusion process without actually having to manually test all the possibilties - as I've done for pibootctl!)
<waveform> anyway, I need to run off to another meeting - many thanks for the offer of help - do feel free to have a play with pibootctl and I'll see what I can add to the docs in the near future
<zyga> o/
<zyga> thanks for the time and info
<AsciiWolf> kenvandine, hi, I have found another Ubuntu-related Snap Store issue... it seems that Snap Store/GNOME Software does not work properly with apps from PPAs: https://bugs.launchpad.net/snap-store/+bug/1881487
<ubottu> Launchpad bug 1881487 in gnome-software (Ubuntu) "Apps from PPAs with AppStream metadata cannot be uninstalled" [Undecided,New]
<kenvandine> AsciiWolf: so both deb and snap.  Must be something else that has been fixed upstream since we last rebased
<AsciiWolf> I did not try compiling upstream GS on Ubuntu, however I don't have this issue on Fedora with apps from various third-party repositories
<AsciiWolf> only on Ubuntu with apps from PPAs that have AppStream metadata
<kenvandine> does gnome-software on fedora use packagekit?
<AsciiWolf> yep, it does
<kenvandine> ok
<AsciiWolf> btw. I am not sure if GS/PackageKit handles PPAs differently than regular (third-party) repositories
<bdmurray> coreycb: Is comment #97 in bug 1877642 all the verification information?
<ubottu> bug 1877642 in zaqar (Ubuntu Focal) "[SRU] OpenStack Ussuri final release" [High,Fix committed] https://launchpad.net/bugs/1877642
<coreycb> bdmurray: yes it is
<bdmurray> coreycb: okay
<bdmurray> coreycb: all the panko verifications don't seem to be done
<coreycb> bdmurray: do you know which bug, is it 1848519 ?
<bdmurray> coreycb: and 1859422
<coreycb> bdmurray: I see, panko must have been stuck in focal-proposed at release time
<coreycb> bdmurray: those bugs should be all set now
#ubuntu-devel 2020-06-03
<Crimson_Rogue> Hello. I need access o ubuntu-touch-dev channel, please!
<Crimson_Rogue> thanks in advance
<mwhudson> does anyone know how this page is created or deployed? https://help.ubuntu.com/lts/installation-guide/index.html
<cpaelzer> doko: seb128: good mornign +1 crew of the day - unfortunately the tests queue grew even bigger
<cpaelzer> so we have even more delay between action and being processed :-/
<cpaelzer> In a world were the queues would have been drained by now I'd have restarted the perl regressions cobined with the triggers for the four rebuilds that formerly had a dependency on <<5.30.3 - this seems to be the majority of the issues that I can see
<cpaelzer> but this isn't perfect and I feel bad for letting a) remaining architectures run into a known test-fail due to these dependencies and b) let them run into these fails just to restart them (could use the extra triggers right away)
<cpaelzer> doko: seb128: does one of you have the powers (or someone else around) to cancel autopkgtests from the queue so that we can re-insert them with the right triggers and only run them once?
<doko> cpaelzer: sorr, no
<cpaelzer> doko: do you know who could?
<cpaelzer> with about 26k tests in the queue I really would want to avoid throwing more tests on top without aborting the old (liekly to fail) ones
<doko> counting tests across architectures doesn't make sense. but yes, the load is high, but less than yesterday
<cpaelzer> more than yesterday aroudn the same time :-)
<cpaelzer> anyway, there is not much we can do for the queue other than wait and not fill it when we could do better
<Laney> cpaelzer: if you can work out which tests need to be cancelled I can do that
<Laney> it's a regex which matches on the strings you see in the queue so that form is preferred
<cpaelzer> Laney: hi and thanks in advance
<cpaelzer> Laney: with line you mean the entries like 'libdatetime-format-w3cdtf-perl {"triggers": ["perl/5.30.3-1"], "submit-time": "2020-06-02 08:57:21"}'
<Laney> indeed
<cpaelzer> ok, that should be doable - but I'll do some safety checks before I pass it to you ...
<cpaelzer> Laney: will they then be listed as failed (or any other defined state) as I'd like to use retry-autopkgtest-regressions to resubmit the list with the right triggers?
<cpaelzer> and finally, IIRC pitti once said there is ajson output of the lists at http://autopkgtest.ubuntu.com/running - do you know where that is?
<Laney> cpaelzer: They will be RUNNING or RUNNING-ALWAYSFAIL
<Laney> and /queues.json is probably what you want
<pitti> cpaelzer, Laney: o/
<Laney> hey pitti
<pitti> wow, nice to look at autopkgtest.u.c. again -- still looks very familiar :)
<cpaelzer> hiho pitti
<pitti> and I see the queues are as long as they used to be
<Laney> perl is very thouroughly tested!
<pitti> http://autopkgtest.ubuntu.com/statistics takes a lot of time
<cpaelzer> Laney: the json is what I wanted thanks. Do you need the regex to match against the json, the text output in the browser or the HTML-escaped text that is transferred?
<Laney> cpaelzer: if you unescape the quotes, that is the raw contents of the queue item which we're matching against
<cpaelzer> ok
<Laney> per queue, it's like filter-amqp user:pass@host queue_name regex
<cpaelzer> hmmm, I just realized that the rate of the tests running into the known dependency issue got much better
<cpaelzer> yesterday it was about 1/5th of the tests, so I wanted to abort all and restart with the right triggers
<cpaelzer> but all the tests that got added since then didn't run into the same
<cpaelzer> so I might be good with just re-scheduling the failed cases
<cpaelzer> sorry Laney for the noise then, I think we are good without mass-cacnel+mass-restart then
<cpaelzer> if the ratio changes I'll let you know
<Laney> ok
<cpaelzer> and I'll still come up with a list to cancel, just not all 16k - more like a few dozen or so
<doko> cpaelzer, seb128: I'm currently working on ftbfs starting from the archive opening. I'm skipping ubuntu-app-launch, would be nice if someone with desktop experience could look at that
<doko> RikMills: could you have a look at the qt-gstreamer ftbfs?
<cpaelzer> ok doko
<cpaelzer> doko: I was this morning also looking at excuses bottom-up for things not needing autopkgtests as the queue is so full - that is how I got to plinth that I asked about before
<cpaelzer> doko: just ping here with the cases you grab so seb128 and I are aware - ok ?
<doko> cpaelzer, seb128: working on rapmap
<cpaelzer> ok doko, I'm about to reschedule the perl tests that are known to need extra triggers
<cpaelzer> Laney: my regexp would be complete, it would be just 44 to cancel, probably not worth the hassle. When you do that do you get something like a confirmation which were effectively removed so that I can use the list to restart exactly the right set?
<cpaelzer> and avoid e.g. update latency of update-excuses and such
<Laney> cpaelzer: 44's probably not worth worrying about, I'd say optimise human time and take a bit of duplication there
<RikMills> doko: qt-gstreamer is RC buggy in debian with that FTBFS, unmaintained upstream, and retired in fedora and probably other distros. I think we should look at the last rdeps in preperation to ditch it
<doko> RikMills: do you volunteer? ;p
<RikMills> doko: I can have a look. its only rdep has none itself. libreoffice recommends it, but that could well be legacy leftover
<RikMills> who is good to ping for libreoffice now?
<doko> hellsworth: ^^^
<RikMills> right. I think they are is the US. I'll have a look at the last actual rdep in the meantime
<cpaelzer> agreed Laney
 * cpaelzer is happy that it won't be the hundreds/thousands of retries that it seemed to be yesterday
<cpaelzer> doko: seb128: I'll take a look at php-horde-*
<LocutusOfBorg> seb128, hello, please network-manager-applet merge? it might be good the one I did in my ppa if you want https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa
<LocutusOfBorg> sil2100, hello it would be awesome to unblock initramfs-tools from focal unapproved queue. People are hit by this bug, I get report on telegram and somewhere else...
<Crimson_Rogue> Hello.
<Crimson_Rogue> i'm needing access to the ubuntu touch development channel.
<Crimson_Rogue> Thanks in advance.
<xnox> Crimson_Rogue:  the one from canonical is i guess here.
<xnox> Crimson_Rogue:  the community ubports effort => i don't know where
<Crimson_Rogue> it is now an invite-only channel
<Laney> I think they don't use IRC: https://ubports.com/join-us
<Crimson_Rogue> #ubuntu-touch
<xnox> Crimson_Rogue:  the only active thing is ubports thing that Laney pointed out. If you are after historic ubuntu-touch development by Canonical & the Ubuntu Project, it's here. But the most we can say is that well, we ceased developing it.
<seb128> LocutusOfBorg, hey, sorry but I don't have the free slot from a nm library change/transition atm, why do you need it?
<xnox> jibel:  sorry, i have invalid email address for you in my address book.
<xnox> jibel:  i hope you are subscribed to the ubuntu-installer mailing list
<xnox> jibel:  hm but it is your launchpad-id and it should work
<xnox> jibel:  do you have your launchpad sso or ubuntu sso set to invalid default email address? or is there a loop?
<sil2100> LocutusOfBorg: hey! Ok, I'll look at it tomorrow for sure during my shift, or later today if I have a few cycles
<LocutusOfBorg> thanks sil2100
<LocutusOfBorg> seb128, there is an annoying auto sync issue with the binary takeover for it...
<LocutusOfBorg> it should be a trivial thing to do, modulo MIRing the new libnm promoting
<seb128> LocutusOfBorg, "modulo MIR' :p
<Crimson_Rogue> I'll be back later. thank you for the info.
<seb128> LocutusOfBorg, what's the autosync issue? it just didn't sync because it takes over binaries no?
<RikMills> doko: is qt-gstreamer blocking anything? I found a patch to fix the ftbfs, but am not keen to apply it to something basically dead, unless it is a blocker for something
<LocutusOfBorg> yes seb128
<seb128> LocutusOfBorg, so it's practice it's some debt but not creating an active problem?
<LocutusOfBorg> there are few fixes in the new network-manager and libnma, as usual, but nothing too serious
<seb128> LocutusOfBorg, I'm opened https://bugs.launchpad.net/ubuntu/+bug/1881906
<ubottu> Launchpad bug 1881906 in Ubuntu "[MIR] libnma" [Undecided,New]
<seb128> launchpad is buggy, https://launchpad.net/ubuntu/+source/libnma exists and includes a 'report a bug' but that just ooops
<LocutusOfBorg> thanks, can I maybe just do it then?
<LocutusOfBorg> I mean, I can merge network-manager
<LocutusOfBorg> and that library will auto sync
<seb128> LocutusOfBorg, if you want to do the merge feel free yes
<seb128> I can review/upload if you wish
<wgrant> seb128: well it's oopsing because the package doesn't exist in Ubuntu!
<wgrant> The package should probably have 404d
<wgrant> MIRing something that doesn't exist seems weird.
<wgrant> Oh autosync failed, I see.
<seb128> wgrant, well, launchpad gives me a working  https://launchpad.net/ubuntu/+source/libnma  page and let me open the 'file a bug' screen and enter all the details, so that's confusing
<wgrant> Absolutely.
<cjwatson> https://bugs.launchpad.net/launchpad/+bug/1635118
<ubottu> Launchpad bug 1635118 in Launchpad itself "Submitting bug for non-existent distro source package triggers OOPS on submission, should not allow you to start" [Critical,Triaged]
<seb128> cjwatson, thanks
<seb128> wgrant, while I've you around ... :) did you use any sort of magic to build pulseaudio on riscv64 before focal? it has a test consistently failing there is focal/groovy, which security bypassed and published without the arch, but it's blocking other fixes now and I'm unsure how to deal with it
<wgrant> seb128: Nothing special, I'm afraid.
<seb128> I wonder if the SRU team would be open to publish with that arch missing
<seb128> since the current security update is already not built there...
<seb128> SRU team,opinion on ^?
<wgrant> seb128: Can you just disable that test on that arch?
<seb128> wgrant, I guess I could, it means doing another round of upload/getting the SRU approved/verified/etc
<seb128> which would set us back again for landing an important fix
<seb128> (which already happened once since the SRU was superseeded by a security update)
 * jdstrand notes that riscv64 is considered a 'bonus architecture' for security updates and we'll publish without it
<jdstrand> I mentioned this before, but neither the security update nor the SRU fixes introduced the failing test case
<jdstrand> it is the act of rebuilding. iirc, the particular test demonstrates it is non-functional. if that is true, I suggest not papering over it and letting it fail and ignoring the failure in the sru
<jdstrand> s/failing test case/failure in the test case/
<cpaelzer> doko: seb128: azure-cli is green in proposed-migration now
<cpaelzer> doko: seb128: looking at python-azure now which is part of the same set
<seb128> ack
<rbasak> Why is vala in universe if desktop stuff in main (eg. simple-scan) build-depends on it? As a preprocessor/generator type thing, doesn't it need to be in main for security support?
<doko> RikMills: sure, we can remove it instead
<juliank> rbasak: it technically works
<juliank> rbasak: this could make sense, but the same argument would apply to any header-only library
<juliank> it's a bit hard to figure out which those are I suppose
<rbasak> juliank: indeed, but I thought the relaxation of the build-depends-drags-into-main rule came with this condition?
<juliank> rbasak: possibly, but you don't necessarily notice it if you happen to include code generated by universe components
<rbasak> Right, but I noticed, and it's trivial to check everything that build depends on valac. So does this now need to be fixed?
<juliank> which is why I don't like the rule relaxation, as it works only sensible for dynamically linked libraries :)
<juliank> I'm not super sure about this, because you don't want to support valac for 3rd parties
<juliank> just because we need it at build-time for some packages, does not mean we should provide security support for the entire thing
<rbasak> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html documented the change
<rbasak> "If you have a build-dependency which does not result in a runtime dependency, but *does* result in code being copied into the final package, you must ensure that this code copying is declared using the Built-Using header"
<rbasak> vorlon: ^ what's your opinion on how that applies to vala?
<rbasak> juliank: I understand that concern, but that is just the regular consequence of things in main.
<juliank> the same also applies to other packages, like triehash
<juliank> (triehash is APT's perfect hash function generator)
<juliank> (it generates C code)
<juliank> (but it's just generating switches, so meh)
<hellsworth> RikMills: what's up with libreoffice (i see the ping from the middle of my night)
<rbasak> mdeslaur is TB and security so might also have a useful opinion on this? ^
<juliank> Apart from the policy question, it's basically a question of whether security team can do security maintenance on code generators in universe to the extend they pertain to our own uses of them
<juliank> and if they are aware of that thing
<mdeslaur> hrm, yeah, stuff like that is complicated
<cpaelzer> doko: seb128: I'm going to look at the haskell related FTFBS, but no promise I can do anything but stare at them with an angry face
<cpaelzer> 1179 hits in update-excuses is worth a look fur sure ...
<rbasak> I just became aware of it because the other day I processed an SRU for some package that regressed and needed a rebuild following a vala SRU, so was quite aware of this - and just now processed a vala SRU and was surprised to see it in universe.
<seb128> cpaelzer, ack
<mdeslaur> I don't think vala actually copies code, its processes it...but I guess it could introduce a security issue that needs to be fixed in vala
<rbasak> Right...and then would require a rebuild of everything that build-depended on it
<mdeslaur> but a CVE would be assigned to the application in most cases, not to vala itself, even if ultimately the issue is vala
<mdeslaur> yes, a rebuild
<rbasak> Anyway
<rbasak> I don't mind what you decide
<rbasak> I just wanted to make sure it wasn't falling into a gap.
<rbasak> It's between security and the TB I guess :)
<mdeslaur> well, I'm not really deciding anything :)
<mdeslaur> but I don't feel strongly enough to escalate it
<rbasak> Well, you sit on both teams, so your problem now :-P
<doko> cpaelzer, seb128: looking at sleef and rdeps
<seb128> cpaelzer, doko, I'm looking at pygame
<mdeslaur> rbasak: haha, "thanks"
<mdeslaur> :)
<rbasak> Not feeling strongly enough to escalate it is also a decision. That you're making. Which I'm also fine with :)
<cpaelzer> doko: seb128: in case you miss my pings I usually also live update https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status when I pick new things
<seb128> cpaelzer, sounnds like a good idea, I should do the same
<RikMills> hellsworth: libreoffice-qt5 recommends qtgstreamer-plugins-qt5 which is currently ftbfs and unmaintained/dead upstream. removed from distros like opensuse, fedora etc. so I wondered if libreoffice got any benefit from that any more, or if it might be some legacy recommends that could be dropped
<RikMills> or at least if not kn own, could be looked into
<hellsworth> ah ok cool thanks for the backstory. my guess is that it is a legacy recommends that could be dropped but i dont know for sure :)
<hellsworth> i'l try building/testing it without qtgstreamer-plugins-qt5 and get back to you
<hellsworth> takes forever for it to build so maybe a day or two...
<RikMills> ok. ty :)
<doko> hellsworth: why do you need a rebuild to check for a recommendation?
<hellsworth> well recommended gets installed when you install libreoffice
<seb128> jdstrand, ack
<hellsworth> so is there a runtime problem if that dep doesn't get installed? that's what i figured i'd answer with a rebuild
<hellsworth> well i could just uninstall that dep and hope things are fine.. but there's still room for a runtime issue to crop up
<seb128> slyon, hey, I wonder if the netplan.io/arm64 autopkgtest failure on groovy with the new n-m is something you looked at yet?
<seb128> slyon, http://autopkgtest.ubuntu.com/packages/n/netplan.io/groovy/arm64
<seb128> it keeps failing so it's looking a real issue
<slyon> hey seb128. I had a short look at it but it's non-obvious what's happening there... I have it on my list and will have a closer look in the next couple of days
<seb128> slyon, thanks
<rbasak> didrocks: I'm looking at your docker.io focal SRU. May I have some help understanding the issue please?
<rbasak> I think I follow what's going wrong, but not what a user is doing that causes it to go wrong.
<rbasak> What's the user story associated with this bug?
<rbasak> For example: does this break all docker.io users with ZFS on root on Focal? Or just some? And if just some, what are they doing (if anything) to trigger it?
<doko> hellsworth: yes, so why the rebuild?
<didrocks> rbasak: it breaks all docker.io users with ZFS on root on Focal is they donât docker rm <container>
<didrocks> if*
<didrocks> which I guess most of users seem to do seeing the bug reports we are getting
<didrocks> (basically, creating tons of datasets)
<didrocks> which are then backed up
<didrocks> creating even more datasets
<rbasak> didrocks: ah - so if users don't clean up their own containers and end up with a large number of them, then zsys starts to time out?
<LocutusOfBorg> seb128, better move here :)
<didrocks> rbasak: yeah, also native zfs commands start to be really slow
<seb128> LocutusOfBorg, right
<didrocks> the idea to is thus to move them outside of the backup realm to not create snapshots
<didrocks> which reduces greatly the number of datasets
<rbasak> That makes sense for Groovy. I have a concern about doing is in Focal though.
<rbasak> about doing this in Focal
<didrocks> rbasak: well, I donât see any alternative TBH, otherwise they whole system will stop functionning at some point
<rbasak> Most importantly, you'll be changing users' systems to stop backing up what they were previously backing up?
<LocutusOfBorg> seb128, it worked
<LocutusOfBorg> meh the conflicts were related to debian stuff
<rbasak> That's a pretty severe change in behaviour I think!
<didrocks> rbasak: right, but those are containers themselve
<rbasak> Is zsys packaged in Ubuntu?
<didrocks> itâs seeded by default
<LocutusOfBorg> I pushed, if you can have a look, it would be really nice
<seb128> LocutusOfBorg, well, that's what a merge is about, resolving conflicts :)
<didrocks> and again, it doesnât only impact zsys
<seb128> LocutusOfBorg, k
<didrocks> but zfs commands as well
<didrocks> with very greatly increased boot time
<LocutusOfBorg> seb128, I resolved them with MoM stuff
<rbasak> I appreciate the problem and that it needs to be fixed somehow.
<didrocks> (like up to a minute to import the pool if you go to the extreme)
<LocutusOfBorg> but I thought they were related on upstream changes, not debian packaging bits, this is why I gave up
<LocutusOfBorg> lol, when I looked better, it was trivial
<seb128> :)
<rbasak> I'm just not sure that this is the right way for Focal.
<rbasak> didrocks: I have a meeting now. Let me ponder this.
<seb128> LocutusOfBorg, seems fine to me, please just undo the gbp.conf branch name change (or change to ubuntu/master and push there)
<seb128> -debian-branch = master
<seb128> +debian-branch = debian/master
<LocutusOfBorg> done thanks!
<seb128> thanks!
<didrocks> rbasa: ack, keep me posted :)
<LocutusOfBorg> I still need to learn something on the ubuntu git vcs stuff VS MoM
<hellsworth> RikMills: doko: libreoffice-qt5 seems fine if qtgstreamer-plugins-qt5 is removed.. this change will need to go into the next release of libreoffice
<doko> ta
<bdmurray> marcustomlinson: Can you help with SRU info for bugs 1880987 (saying look at the error tracker is fine) and bug 1874591? I'll prepare the 20.04 upload
<ubottu> bug 1880987 in update-manager (Ubuntu) "/usr/bin/update-manager:TypeError:_on_finished:_action_done:get_deb2snap_dups:_on_finished:_action_done:get_deb2snap_dups" [High,Fix released] https://launchpad.net/bugs/1880987
<ubottu> bug 1874591 in update-manager (Ubuntu) "[SRU] AptUrl GTK window stuck on screen after install completed" [High,Fix released] https://launchpad.net/bugs/1874591
<marcustomlinson> bdmurray: k done
<bdmurray> marcustomlinson: great, thanks!
<vorlon> rbasak: I certainly don't think vala is any sort of exception to that rule
<rbasak> vorlon: (not an) exception in which direction?
<vorlon> rbasak: if packages build-depend on vala things which results in vala code being copied into the target binary package whose source package is the build-dependency rather than the binary package's own source package, then that package should be listed in built-using
<vorlon> because the whole point of the exercise is to be able to have metadata that we can use to track the source of the binary package, for both licensing and security
<rbasak> vorlon: does code generation count as being copied?
<vorlon> what's the source of the code being generated?
<rbasak> AIUI, code written in vala is converted by valac to C and then goes through the normal toolchain
<rbasak> So vala is essentially part of the toolchain, and a security vulnerability in vala would require vala to be updated before a rebuild to fix the issue
<vorlon> ok, I don't see why that would be different from gcc or binutils
<vorlon> which don't get put into built-using
<rbasak> And if it doesn't get put into built-using you don't mind vala being in universe as a build dependency in this fashion?
<vorlon> or bison or flex or
<vorlon> I don't
<rbasak> OK, thanks
<vorlon> in principle
<rbasak> Yes flex is closer to my understanding of what vala is doing
<vorlon> doko might disagree and want it in main
<vorlon> but that would be an argument for explicitly seeding it rather than expecting it to be in built-using
<xnox> another example is dbus-bindinding-tool which is quite similar to valac too
<xnox> (it takes xml, and spits out C code, that gets compiled into the final binary)
<xnox> or like any of our documentation toolchains, like pandoc
<xnox> To me built-using is about static linking or vendorisation; i.e. copy the binary from another .deb and ship it again, in a different path or form
<hellsworth> there is a new libreoffice 6.4.4 package being built for proposed but the s390x builds are failing
<hellsworth> It looks like the builder had some issue installing
<hellsworth> 'sbuild-build-depends-libreoffice-dummy' from apt. Rightfully so because
<hellsworth> this package is nowhere to be found in the archive. I don't know what is
<hellsworth> prompting the install of this package..
<hellsworth> we've relaunched the buidl and it it still fails the same way
<hellsworth> here is the current log: https://launchpad.net/ubuntu/+source/libreoffice/1:6.4.4-0ubuntu1/+build/19401810
<hellsworth> there's nothing in the s390x build log in a ppa that tries to install sbuild-build-depends-libreoffice-dummy
<hellsworth> any thoughts on this? Maybe the s390x has some sort of broken deps or this is accidentally being attempted to be installed
<vorlon> xnox: agreed
<cjwatson> hellsworth: sbuild-build-depends-<foo>-dummy is a package that sbuild synthesises based on all the build-depends
<cjwatson> hellsworth: You should be able to reproduce the same thing in a local sbuild installation
<cjwatson> hellsworth: Well, not on s390x I guess ... try chdist then
<RikMills> sbuild-build-depends-libreoffice-dummy : Depends: fontforge-nox but it is not installable or
<RikMills>                                                    fontforge but it is not installable
<cjwatson> hellsworth: That's basically sbuild's way of saying that your package's build-dependencies aren't installable
<cjwatson> Right, so focus on that not on the sbuild-build-depends-<foo>-dummy bit
<cjwatson> ubuntu-archive@snakefruit:~$ chdist apt-get groovy-proposed-s390x install fontforge
<cjwatson> ...
<cjwatson>  fontforge : Depends: fontforge-common (= 1:20190801~dfsg-4) but 1:20190801~dfsg-5 is to be installed
<RikMills> fontforge 1:20190801~dfsg-5 ftbfs on s390x
<cjwatson> IOw the problem is https://launchpad.net/ubuntu/+source/fontforge/1:20190801~dfsg-5/+build/19377545
<cjwatson> Right, that
<cjwatson> It depends on an Architecture: all package from the same source, so stuff gets sad if they aren't in sync
<RikMills> tests failed on s390x it seems?
<cjwatson> I dunno, not going to dig further :)
<RikMills> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961841
<ubottu> Debian bug 961841 in src:fontforge "fontforge FTBFS on 64bit big endian: test failures" [Serious,Open]
<hellsworth> cjwatson: RikMills: thanks for putting me on the right path of fontforge
#ubuntu-devel 2020-06-04
<cpaelzer> oSoMoN: seb128: doko: xnox: (wow +1 pinigng is a nice long list today) - I updated https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status again as I was checking my ongoing +1 activities. That should be fine for initial coordination
<cpaelzer> once I start something else after breakfast (all current things are waiting on something/someone) I'll let you know
<cpaelzer> six and python-azure things are fully completed and migrated
 * tsimonq2 loves all of the +1 maintenance activity
<cpaelzer> thanks tsimonq2
<cpaelzer> I'm afraid if I send my mail at the end of my double week it will be a book and no one will read it
<cpaelzer> maybe I should send at the end of each week ...
<tsimonq2> cpaelzer: Was speaking generally, but each person makes up a chunk of that, so you're welcome.
<tsimonq2> If only there was a more centralized way to provide an audit log of sorts.
<tsimonq2> So e.g. on a daily basis, interested people could just look there.
<tsimonq2> Â¯\_(ã)_/Â¯
<cpaelzer> we (all) need to find which way of commuication works best to a) do not feel like a burden/pain but b) gets out to the people so everyone can see and is aware what is going on
<tsimonq2> That's agreeable.
<eoli3n_> Hi
<eoli3n_> i don't get what changed about netboot : http://cdimage.ubuntu.com/netboot/focal/
<eoli3n_> can't i get focal netboot image ?
<eoli3n_> ok found : http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-arm64/current/legacy-images/netboot/
<cpaelzer> oSoMoN: seb128: doko: xnox: there is a test fail in lintian for the new libclass-xsaccessor-perl, I'll look at that next since this eventually will be needed for the overall perl things to complete
<seb128> hey cpaelzer, k
<eoli3n_> arm... not amd
<eoli3n_> so where can i get focal netboot please ?
<eoli3n_> http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
<cpaelzer> eoli3n_: that is the legacy build like you were used to it - alternatively you might follow http://cdimage.ubuntu.com/netboot/ to http://cdimage.ubuntu.com/netboot/focal/ which will lead you to https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510
<cpaelzer> worth a read to consider this going forward
<eoli3n_> i have my own netboot server since many years with a kickstart file etc...
<eoli3n_> don't stop to provide legacy netboot for next releases
<LocutusOfBorg> seb128, I think a better pulseaudio/riscv64 would have been this patch https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/commit/?h=ubuntu&id=40db304aba4f2258edfb3d524787b1e0f22baacb
<LocutusOfBorg> what is your opinion?
<seb128> LocutusOfBorg, the test does work on other archs but maybe yes, ideally that would be upstreamed
<seb128> LocutusOfBorg, it does sound similar to https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/619 , they fixed it by disabling the ffmath option but that's on for us it seems, maybe the patch to the test there would still make sense
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: xnox
<xnox> I am here working on +1 maintenance = meaning all things groovy. If you have anything not in groovy or stuck in groovy-proposed, ask me to help getting it moving!
<Unit193> \o/
<oSoMoN> xnox, this is my first +1 maintenance shift, I'm not familiar with good practices yet, am I supposed to also @pilot in/out when IÂ start/end my day?
<oSoMoN> or are you doing both +1 maintenance and patch piloting today?
<xnox> oSoMoN: I think we came up with idea of (ab)using pilon in on Tuesday for patch piloting.
<xnox> oSoMoN: i.e. if there are any other +1 maintenance people without upload rights they know, that I am around to click autopkgtest retires for them, or like sponsor uploads.
<oSoMoN> ack
<xnox> *retries
<LocutusOfBorg> cpaelzer, any timeline for qemu 5.0 in groovy? :)
<cpaelzer> LocutusOfBorg: ~August
<LocutusOfBorg> thanks :)
<cpaelzer> sil2100: this week you looked at ntirpc/nfs-ganesha
<cpaelzer> did you (or someone else) make nfs-ganesha a sync while doing so?
<cpaelzer> because there is a component mismatch left, so one old delta at least needs to get back
<cpaelzer> I can do that, but I wanted to know the intention/plan to not make things worse by making this a merge again
<cpaelzer> oSoMoN: seb128: doko: xnox: I'll ping the NFS-ganesha merge that is needed to make ntirpc migrate
<cpaelzer> s/ping/take/
<xnox> working on removal of ubuntu-app-launch & url-dispatcher without breaking anything that depends on it for the DE we actually ship
<cpaelzer> ok,t hanks for the info xnox
<doko> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950404 is awaiting feedback
<ubottu> Debian bug 950404 in src:ndpi "ndpi FTBFS on arm64, i386, ppc64el and s390x due to test failures" [Serious,Open]
<doko> RikMills: https://launchpad.net/ubuntu/+source/nootka/1.2.0-0ubuntu4/+build/19239722 any idea? otoh the package could be removed, no rdeps
<doko> not in Debian either
<xnox> doko:  i'm sorry that's out of scope for +1 maintainance in Ubuntu atm. ndpi is not blocked in groovy, is it?
<RikMills> doko: nootka? had not heard of that. very out of date (1.2 vs latest 1.4.7), and their website supplies ubuntu debs. I guess I could work to update it, but have zero motivation to do so and maintain/support it
 * RikMills guesses removal bug is required
<RikMills> if people want it, looks like a snap candidate
<RikMills> \o/ they have a flatpak and an android version in the play store as well
<doko> RikMills: could you file one?
<RikMills> LP: #1880630
<ubottu> Launchpad bug 1880630 in nootka (Ubuntu) "Please remove nootka from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1880630
<doko> ta
<RikMills> looks like already done. I have commented with context
<doko> ahh, there already was one
<juliank> Make experts! How do I write ".man.8: Makefile" correctly?
<juliank> because this triggers "warning: ignoring prerequisites on suffix rule definition"
<juliank> making it "%.8: %.man Makefile" makes automake complain that's gnu make stuff
<juliank> Ah I see I need to get all explicit .8 targets and add depends for those
<juliank> nasty
<juliank> So, flatpak-builder says
<juliank> echo Building
<juliank> make: echo: Operation not permitted
<juliank> on s390x
<juliank> what am I supposed to do with that?
<juliank> with make 4.3
<juliank> seems fine with older make
<doko> waveform: is this supposed to build? https://launchpad.net/ubuntu/+source/linux-raspi2-5.4/5.4.0-1001.1build1
<doko> sforshee: ^^^
<cpaelzer> oSoMoN: seb128: doko: xnox: for ntirpc/nfs-ganesha this will be needed https://code.launchpad.net/~paelzer/ubuntu/+source/nfs-ganesha/+git/nfs-ganesha/+merge/385106 - I'd appreciate if one could take a look for a sanity check
<xnox> juliank:  is it shell builtin, or /usr/bin/echo, what's stdout connect to?
 * juliank probably should have tested the dpkg makefile & autoreconf upload before uploading it
<xnox> juliank:  for example, normally there is no tty1 on s390x
<juliank> xnox: I have no idea really, but this must have changed between make 4.2 and 4.3
<xnox> cure
<juliank> probably could find out by recreating a stdout that is not writable?
<xnox> *cute
<xnox> juliank:  where is it a problem?
<xnox> it seems to build fine (i.e. dpkg is built now?!)
<juliank> xnox: flatpak-builder autopkgtest
<xnox> juliank:  all we care is for make to be in groovy-proposed =) cause it's used to build all the things ;-)
<juliank> looking at the log, this seems a real regression: http://autopkgtest.ubuntu.com/packages/f/flatpak-builder/groovy/s390x
<juliank> because it only fails in the make 4.3 runs, but works in the ones betwee nthose
<juliank> GNU make will now use posix_spawn() on systems where it is available.
<juliank> ^ this?
<xnox> juliank:  ack. I can take a look into that on s390x box later today.
<xnox> with like strace on fds
<xnox> plus autopkgtests have multiple indirections of what stdout is
<doko> RikMills: kopete was removed in Debian testing, because linphone was removed (ftbfs). can we remove it in Ubuntu too?
<doko> or build it without libphone support
<juliank> xnox: I could actually just investigate this on the autopkgtest infra directly with a --shell-fail rerun
<juliank> ok, other cross-toolchain-base-* uploads to do, and then that's the remaining blocker for make-dfsg
<juliank> :)
<waveform> doko, no - we renamed linux-raspi2 to linux-raspi for focal, so it's only relevant on bionic at this point
<doko> waveform: can we remove the package?
<doko> if yes, please file a bug report and subscribe ubuntu-archive
<waveform> doko, it's still used in bionic so I don't we can just yet
<waveform> doko, (linux-raspi2 generally that is, not that particular version which only appears to be built for focal and groovy where it definitely isn't used)
<doko> waveform: I'm talking about groovy
<waveform> doko, in that case definitely - I'll file the issue
<doko> ta
<doko> waveform: so you filed a bug for linux-raspi2, but I asked for linux-raspi2-5.4. can both be removed?
<seb128> xnox, fftw3 i386 autopkgtest are still red with your fixes, did you notice?
<xnox> seb128:  i have
<xnox> seb128:  my next plan is to skip them.
<seb128> k
<xnox> seb128:  because i fail to comprehend how come cross compiler is installed, i386 library is installed, and yet it fails to use i386 search paths for libs.
<xnox> seb128:  but also, we only do native i386 building & testing cross-buildability of fftw3 is outofscope for i386-on-amd64 cross-autopkgtesting i think
<oSoMoN> I have added a force-badtest for metis/i386, can someone from the release team please review/merge https://code.launchpad.net/~osomon/britney/hints-ubuntu-i386-badtests/+merge/385113 ?
<cpaelzer> oSoMoN: seb128: doko: xnox: there is abunch of tests in excuses on ppc64 that failed with a infa error like "Creating nova instance ...ERROR: autopkgtest"
<cpaelzer> oSoMoN: seb128: doko: xnox: I'd have gone for scanning test status for those cases and re-queue them
<cpaelzer> or is anyone of you already on this?
<oSoMoN> I'm not
<seb128> cpaelzer, I clicked some I saw on the by team excuse
<seb128> we really need those improvements to not requeue things already queued
<cpaelzer> seb128: only on the Desktop "by team" ?
<seb128> cpaelzer, mostly, but I glanced over the foundations section as well and clicked a few there
<waveform> doko, ah apologies - didn't realize that was a separate "project" in launchpad; linux-raspi2 itself should be removed at some point but I'm assuming we need to keep it alive whilst bionic is still supported
<waveform> doko, I'll re-file
<cpaelzer> seb128: ok you had gnutls28 but sepia and pinto are not in the per team view and not currently queued
<cpaelzer> so I restarted those two
<seb128> cpaelzer, thanks
<cpaelzer> oSoMoN: seb128: doko: xnox: FYI I'll be looking at jinja2/oca-core test fails
<seb128> k
<RikMills> doko: kopete does not build depend on linphone any more as far as I can see. the previous linphone build depends are now provided with a higher version by the ortp and mediastreamer2 source packages
<cpaelzer> oSoMoN: seb128: doko: xnox: lintian tests all passed as well now (one more peice in the perl puzzle)
<RikMills> plus
<RikMills> reverse-depends src:linphone
<RikMills> No reverse dependencies found
<doko> $ reverse-depends -b src:linphone
<doko> Reverse-Build-Depends
<doko> * kopete                        (for libmediastreamer-dev)
<doko> * kopete                        (for libortp-dev)
<doko> RikMills: ^^^
<doko> hmm, ok
<cpaelzer> oSoMoN: seb128: doko: xnox: jinja case resolved - it is indeed broken and should not migrate - I filed an updateexcuse bug so the next one looking at the queue is aware without re-debugging it
<cpaelzer> I'm in meetings from now on, probably no more +1 cases for me today
<eoli3n_> what do i see ?? apt embeed snap packages now ?
<eoli3n_> does snap packages still doesn't work when home is not local..?
<juliank> ddstreet: did you see me approving your software-properties branch?
<juliank> (last thu)
<juliank> seb128: you committed  a change to software-properties repo middle of April, are you going to follow up on that? https://git.launchpad.net/software-properties/commit/?id=e375293fd8787f8a40b6eded51dde808f9d9cb09
<juliank> because it's not uploaded
<seb128> juliank, there was no hurry that's why I didn't upload, I though other changes would come at some point and it could wait for the next upload
<juliank> seb128: ok
<juliank> It's a small change anyway
<oSoMoN> cpaelzer, seb128, xnox, doko : I went through all the rdeps of ttf-dejavu* that are blocking the migration of fonts-dejavu and I filed bugs/attached patches
<xnox> oSoMoN:  oooh nice!
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
 * xnox is finishing up for the day, but i will be back tomorrow!
<ddstreet> juliank yes thanks, i'll try to get time to push it (if i have acl...)
<juliank> it's ~ubuntu-core-dev owned iirc?
<oSoMoN> I'm looking into the fontforge s390x build failures (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961841)
<ubottu> Debian bug 961841 in src:fontforge "fontforge FTBFS on 64bit big endian: test failures" [Serious,Open]
<oSoMoN> that's encouraging: https://launchpad.net/~osomon/+archive/ubuntu/fontforge-bigendian-groovy/+build/19408615
<ahasenack> in focal, we have both golang 1.13 and 1.14, with 1.13 being the default
<ahasenack> golang-defaults creates the symlinks from /usr/bin/go to the 1.13 binary somewhere in /usr/lib
<ahasenack> is there sometihng that does the same for golang 1.14? Create the symlinks and such? Or should I do it by hand, if I want to use 1.14 in focal?
 * ahasenack wonders if it's managed by alternatives
<ahasenack> no, looks like alternatives was used once upon a time, but not anymore
<sarnold> ahasenack: it's my understanding that 1.14 is there for riscv64 -- I don't know if that's any help to you or not :) but I'm not sure the intention is to use 1.14 for non-riscv64 architectures
<ahasenack> that's unexpected reasoning :)
 * ahasenack tries the manual symlinks
<ahasenack> the thing built, so far so good
#ubuntu-devel 2020-06-05
<mwhudson> is it possible to tell launchpad which architecture to build a particular architecture: all package on?
<sarnold> I've not seen that mentioned anywhere
<sarnold> afaik it's fixed per release
<wgrant> mwhudson, sarnold: XS-Build-Indep-Architecture works in LP and dak
<wgrant> (it's a space-separated list of architecture tags, but usually just one)
<slyon> hey LocutusOfBorg! I was just looking into the netplan.io autopkgtest failure on arm64, blocking network-manager 1.24 proposed migration... Seems like you got it working â was it a flaky test after all?
<eoli3n_> Is there any post which explains what's going on with snaps ?
<eoli3n_> i deploy my hosts with a kickstart install then i use ansible in "post" section. It fails installing chromium-browser because snap can't reach snap store. I think that's because i'm in a chroot
<eoli3n_> a package manager which needs a daemon ? is that docker who wrote that tool ?
<eoli3n_> https://bugs.launchpad.net/snappy/+bug/1609903
<ubottu> Launchpad bug 1609903 in Snappy "Enable the installation of snaps in a classic chroot" [High,Triaged]
<eoli3n_> is there a way to completly disable snapd without breaking anything ?
<eoli3n_> as i use ansible, i would be able to seperate snap tasks to not run in a chroot. But then, it is IN apt, what a choice ??
<eoli3n_> should i test each of my 450 packages to know if it installs snap version or not ?
<eoli3n_> if i remove snapd package, then i try to install chromium for exemple, snapd comes as a dep to be able to install chromium
<eoli3n_> is that serious?
<eoli3n_> ubuntu isn't only used by geek teenagers who wants to rice gnome...
<LocutusOfBorg> slyon, I just retried it...
<LocutusOfBorg> flaky is the right wording I guess
<andrewsh_> eoli3n_: thatâs because chromium is a snap package in Ubuntu
<eoli3n_> i noticed that andrewsh
<andrewsh_> if you want a non-snap package, you can install one from bionic-{updates,security} or Debian
<andrewsh_> I use the Debian one since the package from bionic doesnât work with UberConference for some reason
<eoli3n_> andrewsh what i mean i that i need to be able to completly disable snap packages
<andrewsh_> I have snap completely disabled, yes
<slyon> LocutusOfBorg, okay thanks! It was the first time it behaved this way.. It was re-tried many times before and now it suddenly works
<eoli3n_> because, if i add a new package to my playbook which requires snap, it will break my deployments
<LocutusOfBorg> slyon, meh, I know, but some big migration happened before I retried it
<LocutusOfBorg> we might meld the last two runs to see if something in toolchain made it pass
<slyon> LocutusOfBorg, yes. I will investigate a little bit, trying to understand what was going wrong.
<zyga> hello
<zyga> my thinkpad x240 running groovy daily had some issues this morning - when I tried to log in via gdm I got kicked out of the session instantly
<zyga> looking at the logs I noticed that X could not get /dev/dri/card0
<zyga> the file on my system is owned by root:video but my user account did not belong to the video group
<zyga> I temporarily resolved this by adding my account to said group but I'm not sure this is right
<zyga> it feels like something logind would ACL me into
<zyga> seb128: ^ reported here
<wgrant> Yeah, you'd normally get u:$USER:rw- on /dev/dri/card0 from logind, hm.
<zyga> journal from this boot https://paste.ubuntu.com/p/TFJ6dqJzFK/
<zyga> line 4042 has: cze 05 08:58:04 x240 /usr/lib/gdm3/gdm-x-session[2867]: (EE) modeset(0): drmSetMaster failed: Permission denied
<seb128> zyga, thanks
<zyga> hmm, my system has a 2nd user account for various tests
<zyga> and it's possible that account has linger enabled
 * zyga chceks
<zyga> yes
<zyga> the 2nd account does have linger
<eoli3n_> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1782873
<ubottu> Launchpad bug 1662552 in snapd (Ubuntu) "duplicate for #1782873 snaps don't work with NFS home" [Medium,Fix released]
<eoli3n_> who manage snapd integration ?
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: xnox
<zyga> eoli3n_: hey
<zyga> I should probably have a look
<zyga> can you tell me how to replicate your setup?
<zyga> I'm not a nfs user
<eoli3n_> Hi zyga
<zyga> hi
<eoli3n_> is there a way to completly disable snaps ?
<zyga> eoli3n_: remove snapd
<zyga> eoli3n_: but if you tell me how to replicate the nfs setup I'm sure I can fix that bug
<eoli3n_> nop, if i install a package which requires snap install, it installs snapd as dep
<eoli3n_> my main problem is not NFS one, i didn't check yet if its still a problem, i will tell you for sure
<zyga> what is the problem then?
<eoli3n_> apt purge snapd -y && apt install chromium-browser -y
<zyga> chromium is not packaged as a deb anymore, nobody wanted to maintain it
<zyga> it's a mess and pain to do
<eoli3n_> zyga, i use kickstart install, in %post i use ansible to install packages. As snaps requires snapd daemon, and i'm in a chroot it breaks my install
<zyga> I see
<zyga> perhaps file a bug on the chromium package to handle that case better (defer the install)
<eoli3n_> for now i only have the problem with chromium-browser, but what's fears me is that ubuntu will use more and more snaps packages
<eoli3n_> my concern isn't mainly about chromium-browser
<eoli3n_> it is about "how to massive deploy ubuntu with snap packages now integrated in apt"
<zyga> I think there are ways to do that
<zyga> but I'm not the best person
<eoli3n_> i need to use ansible in chroot, i always did and it works well
<eoli3n_> ubuntu just need to provide a way to disable snap packages
<eoli3n_> snaps are buggy still, force it will cause lots of problems
<zyga> you can configure a seed to preinstall snaps
<zyga> but I think you should not mix many problems at once
<eoli3n_> my problem is this : i use a playbook in a post kickstart chroot and that same playbook during host live : if i add a new package which is handled by snap, i will never see that and it will break my deployments
<eoli3n_> i don't want to test each packages i add
<eoli3n_> i'm really sad about ubuntu's choice, isn't docker a good light for "what you should not do" ? Why force snap to use a daemon, when flatpak shows you it is useless ?
<zyga> perhaps someone else can help you, I can only help you with specific snapd topics
<zyga> eoli3n_: I think you are wrong but I'm not sure you want to discuss it
<zyga> you are unhappy about it and that's not something I can help with
<eoli3n_> yes you're right, lets don't talk about that point
<zyga> snapd did not have a daemon, inititally it was just snappy, it was a huge mistake that took a year to fix
<zyga> and there's a lot of really good reasons why
<zyga> there are some ways to configure a system to install snaps on first boot (seeding)
<eoli3n_> ok ok, but you will face a lots of deployments problem as mine
<zyga> we use it in ubuntu
<eoli3n_> hmm
<zyga> perhaps, stuff will adjust though
<eoli3n_> but my concern isnt about "how to preseed a snap package"
<zyga> we will help where we can
<zyga> I know, you want things to work
<zyga> I'm not familiar with ansible so I cannot really help you with that part
<eoli3n_> yes, for now i just need to find a way to "don't break my deployments" when adding a random package
<zyga> perhaps someone else here could
<eoli3n_> ansible isn't the problem, consider it as a "apt install package" in a chroot
<eoli3n_> lets recenter
<zyga> I think the package responsible for conversion should be fixed to detect this
<zyga> and instead drop some hooks/triggers that go off when the system really boots
<eoli3n_> making snap installations offucated by apt is a bad choice
<eoli3n_> i will open an issue, can you tell me on which package i should open it ?
<eoli3n_> snapd ?
<zyga> I think the way to make progress is to file a bug on the package to report that it misbehaves in a chroot
<zyga> and carry on the discussion there
<eoli3n_> so chromium-browser ?
<zyga> I think so
<eoli3n_> lets do this, thanks zyga
<xnox> eoli3n_: for daemons we have policy-rc.d stuff. Which allows to download install, but not start, daemons. And it works in chroots.
<xnox> eoli3n_: I guess for chroot based stuff we should have similar i.e. "download and add snap to seed.yaml / pending transaction" but do not try to start snapd or mount the snap.
<xnox> eoli3n_: instead of installing Chromium package, you may want to call snap prepare-image to seed Chromium => that can be done in a chroot without snapd Daemon running.
<eoli3n_> xnox i don't get all you said
<eoli3n_> my main concern is "how to install a package without problem in chroot"
<eoli3n_> as apt wrap snaps and debs, i don't want the need to "do something to make it work"
<eoli3n_> i just want it to work
<eoli3n_> chromium is identified here, but my concern is about all existent packages.
<xnox> eoli3n_: you may not realise, but installation of majority of packages in chroots already has detection code in maintainer scripts to not do things that break.
<xnox> eo
<eoli3n_> oh ok, so that's a chromium-package issue
<eoli3n_> i didn't open issue yet
<eoli3n_> coffee time :)
<xnox> eoli3n_:  i.e. we make a lot of work, on every package, one by one, to ensure they install fine in chroot, lxd, container, vm, baremetal, WSL1, WSL2, over the network, on various filesystems, kernels, selinux confimenet, apparmor, etc.
<xnox> eoli3n_:  i am happy that for you it is perceived as "apt installs always work" =)
<xnox> in general, and that we are doing things so good, that it is expected as normal =)
<xnox> eoli3n_:  but yeah, it feels like a bug against chromium-browser (or whatever the package is). To somehow do something sensible.
<eoli3n_> but shouldn't it be snap process which needs to catch chroot env ?
<xnox> eoli3n_:  i think installing lxd package should work in chroot. And i think that install creates stub scripts, that if invoked later, offer to install snap and run it, if snapd is running.
<eoli3n_> xnox: i didn't know about the work you talked about : so yes, great work :)
<xnox> eoli3n_:  right, that would be ideal if "snap install" would realise that it's in a chroot, that snapd is not running, and somehow "schedule to install this thing later, when snapd is operational"
<xnox> eoli3n_:  but that sounds like a separate bug/issue type of thing.
<eoli3n_> i will open it in chromium-browser package and see where it goes
<xnox> (well feature)
<oSoMoN> eoli3n, ping me with that bug once you've filed it, I'll be looking at it
<eoli3n_> nice, thanks to all of you ;) i'm kickstarting to paste error
<eoli3n_> oSoMoN https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232
<ubottu> Launchpad bug 1882232 in chromium-browser (Ubuntu) "install chromium-browser in a chroot fails" [Undecided,New]
<eoli3n_> xnox: do you really want that i run in noninteractive ?
<eoli3n_> i'm on it , i will paste logs
<dupondje> https://bugs.launchpad.net/ubuntu/eoan/+source/wireguard/+bug/1870293
<ubottu> Launchpad bug 1870293 in wireguard-linux-compat (Ubuntu Focal) "Resync wireguard/wireguard-linux-compat with development" [Undecided,Fix committed]
<dupondje> Forgot to push it to -updates on Focal?
<ahasenack> hi, focal has golang-go 1.14, but defaults to 1.13 via golang-defaults. Is there an "official" way to have 1.14 be the default, or should I create the symlinks that golang-defaults has manually?
<ahasenack> I would like to use 1.14 in a package build, and I can't change the symlinks in the system in that build (not root), nor should I
<ahasenack> I was hoping for some environment variables, like java
<ahasenack> I can of course update PATH
<xnox> eoli3n_:  what you are experiencing, and reporting, does not sound like a bug.
<eoli3n_> why that ?
<eoli3n_> its normal that i can't install a package in a chroot ?
<xnox> eoli3n_:  many package installations pop-up debconf prompts upon installation, or upgrades, and require user input or acknoledgement by default.
<eoli3n_> xnox please read my answer
<xnox> eoli3n_:  this is not a failure to install. as apt didn't fail to install anything.
<eoli3n_> that's not a debconf issue
<eoli3n_> anyway, i'm running right now it in noninteractive mode
<eoli3n_> i'm waiting for timeout to break to be able to paste
<xnox> eoli3n_:  "-y" is not enough
<eoli3n_> i understood that
<eoli3n_> xnox...
<eoli3n_> please wait a min
<xnox> eoli3n_:  one has to either preseed debconf answer, or ask ansible to run in non-interactive mode
<eoli3n_> ansible runs defaulty in non-interactive mode
<eoli3n_> anyway as said, i'm facing that issue with DEBIAN_FRONTEND=noninteractive
<eoli3n_> if i'm reporting it, that's because there is a problem
<xnox> eoli3n_:  if install does not complete even with DEBIAN_FRONTEND=noninteractive => then there are bugs in maintainer scripts yes.
<LocutusOfBorg> tjaalton, hello you there?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1876882
<ubottu> Launchpad bug 1876882 in libclc (Ubuntu Bionic) "Backport packages for 18.04.5 HWE stack" [Undecided,New]
<LocutusOfBorg> looks like vbox is broken by new mesa?
<xnox> eoli3n_:  i'm sorry, but the bug report as was written was not clear at all.
<eoli3n_> the debconf pop up is clear
<eoli3n_> but i will add what you want
<xnox> eoli3n_:  the fact that there is debconf pop-up is valid and ok. Unless it is impossible to bypass them, when trying to do so.
<xnox> which is what you seem to be reporting
<eoli3n_> did you read the pop up ?
<eoli3n_> "fails" means recturn code is 1
<eoli3n_> anyway
<eoli3n_> sorry knox, but your answer has no sense
<eoli3n_> "-y" is not enough to install non-interactive under ansible.
<eoli3n_> ansible doesn't use -y or something
<eoli3n_> it has his own module
<eoli3n_> and it wraps a real noninteractive install
<xnox> hang on
<xnox> eoli3n_:  the code in the template expects that dialog to have 3 options / answers
<xnox> Retry Abort Skip
<xnox> yet in your screenshot it's just "OK"
<xnox> eoli3n_:  which release / package version is this?
<eoli3n_> xnox i understand that you need to be sure that i don't say something wrong. But it would help if you help me to make you understand what's going wrong
<eoli3n_> the msg is clear
<eoli3n_> the problem is clear to
<eoli3n_> snapd is not running in chroot
<eoli3n_> and it make the package install fails
<eoli3n_> which release / package of what ?
<eoli3n_> i use netboot
<eoli3n_> so latest
<eoli3n_> which package ? apt updated so latest too
<eoli3n_> the problem is "Unable to contact the store, trying every minute for the next 30 minutes"
<eoli3n_> in debconf OR in text logs
<eoli3n_> you seems saying that i do something wrong: please reproduce then you will see :)
<xnox> eoli3n_:  and you expect to be able to use the chromium-browser in the chroot? or do you plan to boot that choot in a VM / bare mchine later
<xnox> eoli3n_:  let me attach my screenshot
<xnox> eoli3n_:  because it is different to yours
<xnox> eoli3n_:  which release of ubuntu are you using?
<eoli3n_> xnox i manage 800 ubuntu nodes for a university, so here i'm trying to migrate my deployment method
<eoli3n_> i install my whole system with kickstart then ansible in chroot
<eoli3n_> but why is that important
<eoli3n_> please try docker commands i gave you
<eoli3n_> and you will face that same issue
<eoli3n_> xnox: latest netboot
<eoli3n_> so 20.04
 * ogra thought latest netboot uses a livefs ... how does a chroot come into play here 
<eoli3n_> you seriously guys don't get what i do here ? aieaieaie ok lets explain more
<eoli3n_> im a sysadmin in a university
<eoli3n_> i deploy 800 ubuntu nodes on physical hosts for courses
<eoli3n_> i automated the whole process with kickstart
<xnox> eoli3n_:  https://launchpadlibrarian.net/482972565/debconf-prompt-groovy.png
<eoli3n_> kickstart deploys my system, then in %post section of kickstart i use ansible, to configure the whole system
<eoli3n_> then it reboots and the host is ok and working
<xnox> eoli3n_:  so i am confused how come I am offered "retry abort skip ok" and you are only offered "ok"
<xnox> eoli3n_:  and you will need to preseed the answer to Skip with debconf preseed (aka automatic ahead-of-install answers to package questions)
<eoli3n_> xnox ansible wrap it
<ogra> xnox, different debconf priority settings ?
<eoli3n_> it does what you say
<xnox> eoli3n_:  what ansible settings do you have for the debconf module in your playbook? https://docs.ansible.com/ansible/latest/modules/debconf_module.html
<eoli3n_> i don't use the debconf module
<xnox> eoli3n_:  you must, if you want ansible to answer the debconf questions for you
<eoli3n_> didn't even know it exists
<tjaalton> LocutusOfBorg: yes?
<eoli3n_> xnox that's strange : i use that method since 5 years
<eoli3n_> never had to use debconf module
<xnox> eoli3n_:  https://paste.ubuntu.com/p/2N78xNW2m8/
<xnox> eoli3n_:  it means your installations are extremely trivial.
<xnox> (despite however complicated they are)
<xnox> from dpkg / debconf point of view at least
<eoli3n_> so your solution, is to wait for that long timeout
<eoli3n_> then tell to install package later ?
<xnox> eoli3n_:  no
<xnox> eoli3n_:  if you use debconf, ansible will preseed that answer for you, and the timeout will not even be attempted.
<xnox> eoli3n_:  it will instantly skip and carry on.
<eoli3n_> so package will not be deployed ?
<xnox> eoli3n_:  this is what debconf preseeding is for, to answer things ahead of time.
<tjaalton> LocutusOfBorg: where's the full log
<xnox> eoli3n_:  the package will be installed.
<xnox> eoli3n_:  the snap will not be, until later when users boot the system
<eoli3n_> sorry, i think the part i don't get is "what snap is trying to do with that timeout ?"
<xnox> eoli3n_:  also why are you installing the package at all?
<xnox> eoli3n_:  this has nothing to do with snap
<eoli3n_> because an OS is to run packages ??
<xnox> eoli3n_:  Ubuntu runs on snaps and debs.
<eoli3n_> i don't get what you mean
<eoli3n_> so ?
<eoli3n_> xnox: eoli3n_:  also why are you installing the package at all?
<xnox> eoli3n_:  i.e. chromium-browser deb is there for convenience. When preparing Ubuntu Studio images with chromium-browser, instead of isntalling it as a deb, we preseed it as a snap using seeded snaps functionality.
<eoli3n_> any link about that ?
<eoli3n_> that snaps start to bored me
<xnox> it's easier to preseed snaps on first boot, directly from the store without trying to use debconf + apt modules of ansible to take three detours to install a snap.
<eoli3n_> what a mess
<eoli3n_> seriously
<eoli3n_> KISS powa
<xnox> eoli3n_:  https://docs.ansible.com/ansible/latest/modules/snap_module.html
<xnox> - name: Install browser
<eoli3n_> xnox my concern is : how to know a package IS a snap if its wrapped by apt
<xnox>   snap:
<xnox>     name:
<xnox>       - chromium-browser
<xnox> and done
<eoli3n_> so at each new package i install : i need to verify that that's a deb or snap package
<eoli3n_> that's your solution ?
<eoli3n_> so why integrated snaps in apt if its better to keep them separated ?
<xnox> eoli3n_:  majority of things only exist in one form. (i.e. only a deb, or only a snap). And we try to minimise number of things that are available as wrappers.
<xnox> eoli3n_:  because it is confusing.
<eoli3n_> ubuntu: "cool, we integrated snaps in apt" me: "there's an issue" ubuntu: "separate your installs then"
<xnox> eoli3n_:  however, we must provide them for upgrades and to transition people off a deb into a snap.
<xnox> eoli3n_:  chromium-browser is not intended to be installed on fresh machines. It is only intended to support upgrades and conversions.
<xnox> eoli3n_:  so far in the archive we have 3 packages that are wrappers around snaps, for upgrades: maas lxd chromium-browser
<eoli3n_> ok, but so what about my issue ? https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232/comments/6
<ubottu> Launchpad bug 1882232 in chromium-browser (Ubuntu) "install chromium-browser in a chroot fails" [Undecided,Incomplete]
<xnox> eoli3n_:  interractively we do guide people to the right tool.
<xnox> eoli3n_:  and grpahically snap-store UX is clear, it is a one stop place that installs either snaps or debs.
<xnox> eoli3n_:  your issue is valid. The experience is bad, frustrating and confusing.
<eoli3n_> i can confirm that
<xnox> eoli3n_:  and requires a lot of details explaining as to what is happening, why, and how to do things better.
<eoli3n_> i'm trying to debconf solution
<xnox> eoli3n_:  and we must improve it. given that there is too much information out there that says "apt install chromium-browser"
<eoli3n_> xnox so write a post about that somewher
<xnox> eoli3n_:  let me rephrase/rewrite that bug report and keep it open.
<eoli3n_> ok thanks for your help
<eoli3n_> add the deconf workaround please
<eoli3n_> and "chromium-browser-l10n" should be installed as package yes ?
<eoli3n_> but it has chromium-browser as dep in apt
<xnox> chromium-browser-l10n => is empty
<xnox> Description: Transitional package - chromium-browser-l10n -> chromium snap
<xnox>  This is a transitional dummy package. It can safely be removed.
<xnox>  .
<xnox>  chromium-browser-l10n is now replaced by the chromium snap.
<eoli3n_> ok thanks
<xnox> eoli3n_:  on fresh installs you only want to "snap install chromium-browser" on first boot
<xnox> (with ansible module, or with a cron job or etc)
<xnox> eoli3n_:  or if you must be able to complete it offline there is a way to populate /target/var/lib/snapd directory with files there to do it for
<eoli3n_> but will i face the same issue in chroot if i use snap module ?
<LocutusOfBorg> tjaalton, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/19411432 https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/19411433
<xnox> eoli3n_:  let me finish typing update to the bug report.
<eoli3n_> ok
<LocutusOfBorg> here some detail https://bugzilla.redhat.com/show_bug.cgi?id=1765930
<ubottu> bugzilla.redhat.com bug 1765930 in mesa "recent mesa / libglvnd changes break mutter + mutter328 builds" [Unspecified,Closed: currentrelease]
<eoli3n_> i'm trying the snap module in chroot
<xnox> eoli3n_:  not sure. I do not quite know how that ansible snap module works. Ideally, it would be smart and either does "snap install" or "snap prepare-image" (for cached offline install)
<xnox> eoli3n_:  if it does the first thing, then it will fail too =/
<eoli3n_> lets try, just to know
<xnox> eoli3n_:  what is your full installation? do you already have anything that stores things on disk (in that choot) and is executed on first boot?
<eoli3n_> i don't get what you mean?
<eoli3n_> my playbook in 500 tasks
<eoli3n_> so yes
<xnox> but all of them run in a choot, and later you reboot into that chroot?
<xnox> after the install is done / all the tasks are done / machine deployed?
<eoli3n_> i never reboot in the chroot, as the chroot is just the post install script
<eoli3n_> let me paste something
<xnox> eoli3n_:  but like it's not possible to run desktop or browser from a chroot. without X, etc.
<xnox> eoli3n_:  so what is the point of it? (i kind of want to know the full picture of what you are doing)
<eoli3n_> xnox i don't get what you think, but seriously that's strange
<eoli3n_> do you know how kickstart works ?
<xnox> no
<eoli3n_> that's the main problem
<ogra> its just a debconf frontend in ubuntu ...
<eoli3n_> i pxe netboot ubuntu installer
<eoli3n_> i provide a "answer file"
<eoli3n_> which install in non interactive way ubuntu
<xnox> i know that people boot kernel+initrd, run installer to provision the hard-drive which during install is a mounted chroot, and at the end the said machine is rebooted, from disk, and people get a graphical desktop.
<eoli3n_> that's what i do yes
<eoli3n_> expect that at the end of install
<eoli3n_> i use %post kickstart to run ansible in chrooted env
<eoli3n_> then i reboot
<eoli3n_> and i get a full deployed host as you said
<xnox> eoli3n_:  hence my question, when that machine boots for the first time for the end user is there something running on first boot only? i.e. connect / enroll to ldap, configure printer, generate ssh keys, etc?
<xnox> or are they all "golden" and pristine?
<eoli3n_> the same playbook runs at each reboot
<eoli3n_> so yes
<xnox> do they enroll into master puppet / ansible / etc to be remote controleld administered.
<eoli3n_> but it has nothing to do because it freshly ran
<eoli3n_> no nothing of that
<eoli3n_> when the host first boot, it is fully configured
<xnox> eoli3n_:  but when it re-runs on the reboot, it still operates the same way from chroot, or does it run from rootfs?
<xnox> right, i see.
<xnox> thanks.
<eoli3n_> xnox: read this -> http://ix.io/2olM
<eoli3n_> everything after "%post" key runs in freshly installed chroot
<eoli3n_> that complete file is passed to pxeboot env
<eoli3n_> so it automates the whole process
<eoli3n_> then it reboots, and everything is working at first boot
<oSoMoN> I am looking at r-cran-gwidgetstcltk test failures, and IÂ think I have a fix which I'm going to submit to Debian in a moment
<xnox> eoli3n_:  by the way, all the things that start with "preseed " word are debconf questions answered.
<xnox> eoli3n_:  i.e. preseed chromium-browser/blah-blahs select Skip => should be usable there. but let me read it in full
<xnox> eoli3n_:  you are doing a lot of interesting things there! it is very neat!
<tjaalton> LocutusOfBorg: why does it import both..
<tjaalton> LocutusOfBorg: you could sync the internal header to match mesa
<tjaalton> LocutusOfBorg: like this https://gitlab.freedesktop.org/mesa/mesa/-/commit/3dd299c3d5b88114894ec30d1fac85fba688201f
<xnox> cpaelzer:  vorlon: i remember somebody somewhere asked before how to reproduce i386-amd64 autopkgtest builders
<xnox> and i'm failing to find instructions again
<xnox> was it you? do you remember where it was posted on how to do it?
<xnox> https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+ref/i386-as-amd64-cross ?
<Eickmeyer> xnox: Just for reference, we don't seed chromium in Ubuntu Studio in any way, but I hope the example still got across. :)
<LocutusOfBorg> tjaalton, will try to fix thanks
<eoli3n_> thx xnox
<xnox> Eickmeyer:  yeah, i know. hence using studio images is no problem. but trying to do, what studio iso is doing, is hard. because it is impossible to discover that one must do "snap ack --remote model:generic..... >model ; snap prepare-image model --snap core18 --snap snapd --snap chromium-browser"
<eoli3n_> lets drink a bear and continue monday morning :) have a nice we
<eoli3n_> a beer
<eoli3n_> not a bear :D
<Eickmeyer> xnox: Oh, yeah, totally.
<Eickmeyer> xnox: I also need to bug #ubuntu-release to figure out what is going on with our Focal images, it seems to be installing two kernels at once and livecd-rootfs is freaking out and failing.
<sarnold> wgrant: oh wow, cool, I've never seen XS-Build-Indep-Architecture before :) thanks
<xnox> it's quite new
<xnox> wgrant:  is it fully supported in lp now?
<sarnold> after reporting it to #debian-til, I got back a suggestion that it's not really in debian; they said something along the lines of, dak doesn't manage the buildds..
<xnox> sarnold:  yeah, that's what i thought it was more or less work in progress to support that
<cpaelzer> xnox: I was the one who asked i386 autopkgtest
<cpaelzer> xnox: it comes down to an amd64 image + extra arch
<cpaelzer> xnox: I put the info on https://wiki.ubuntu.com/i386 which is AFAIK the one place i386 info is supposed to be
<xnox> cpaelzer:  thanks
<xnox> i hate fftw3 and somehow i fail at autopkgtest
<xnox> i should give up on it
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<cjwatson> xnox: It's been fully supported in LP since 2015.
<wgrant> xnox: since 2014 or so I think
<xnox> ooooh nice
 * xnox ponders if i can use it for cd-boot-images then!
#ubuntu-devel 2020-06-06
<xnox> cjwatson:  wgrant: did I do it wrong? or do i still need something arch:any?
<xnox> https://launchpadlibrarian.net/483047067/cd-boot-images_2.dsc
<xnox> i'm trying to build "firmware" i.e. natively compiled on three arches, each building a unique cd-boot-image-$arch package which themselves are arch:all
<wgrant> xnox: Ah, that's not possible
<xnox> it got scheduled on just amd64
<wgrant> It will still only build arch-indep on a single arch.
<xnox> right =(
<wgrant> You can't use it to build arch-indep from multiple arches at once from one source.
<wgrant> It's designed for things like firmware that can only build on a single arch
<xnox> yeah, but often enough it's the same firmware over and over again =)
<xnox> aka src:qemu that needs to build on every arch, to produce unique arch all packages.
<xnox> cause one cannot build _all_ of them on any one arch, in one go.
<xnox> wgrant:  i wonder what will happen if in .dsc i declare them as arch=amd64 but produce an arch=all packages during the build....
<xnox> i.e debian/control != .dsc
<wgrant> xnox: LP will reject that
<wgrant> Well
<wgrant> LP will reject arch-indep coming from a build that it didn't tell to be arch-indep.
<xnox> but i did in Build-Indep-Architectures
<xnox> it is a list right?! or implementation reduces it to be a single value?
<xnox>     :param indep_hint_list: a string of the architectures this source package
<xnox>         specifies it can build architecture-independent packages on.
<xnox> ah
<wgrant> xnox: It's a list, but your interpretation of the semantics is wrong
<wgrant> It means if there are arch-indep packages, build them on one of these arches.
<xnox> right, yeah. reading the comment.
<wgrant> Rather than on nominatedarchindep.
<wgrant> LP will choose one of those, if possible, on which to invoke sbuild with -A
<wgrant> (I know LP will reject if sbuild disobeys that, because focal's sbuild defaults to -A, so I got a lot of riscv64 rejects when I first started using focal buildds!)
<wgrant> Hm or were those just from dupe binaries? I don't remember, but it should violate the fit check I'd expect.
<wgrant> Regardless, it is rude to build arch-indep when not asked to :)
<xnox> so source package per arch then? if i want them arch-all?
 * xnox thinks about it.
<wgrant> Yep
<mwhudson> i guess in one way that's ugly but in another they are pretty unrelated
<Crimson_Rogue> I'm having issues connecting my vnc server to my vnc viewer in android. Can someone point me in the left direction?
